💻 VS Code DevContainerを使わなくなった私の、LLMエージェント向け開発環境

TL;DR

なぜDevContainerから離れたのか

開発スタイルの変化

以前はDevContainerが最高だと思っていたが、LLMエージェントに実装や調査を任せるようになって、「自分がVS Codeでコードを書く」ことが激減。 そうなると重要なのは：

• agentが動作する環境があること
• 複数のagent terminalを並行して動かせること
• agentの状態が一目でわかりやすいこと（通知もくる）
• 必要なportを簡単に確認できること

VS Code + DevContainer を中心に据え続けるのは、これらの要件に対してだんだん合わなくなってきた。

worktree × DevContainerのつらみ

LLMエージェントを使うと git worktree を多用する（タスクごとに切ってagentを走らせる）が、DevContainerと組み合わせると：

• worktreeごとにコンテナが増える
• 同じportを使うアプリが衝突する
• DBやRedis等の周辺サービスをどう共有するか問題
• 初期化や後片付けが増える

新しいアプローチ：長生きする開発マシン

1プロジェクト1コンテナをやめる

代わりに組織のドメイン（顧客・契約・事業・権限の範囲）ごとに1つの開発コンテナを持つ：

• 同じ組織内なら技術スタックが違っても同じコンテナに入れる
• 顧客や契約が違う仕事は別コンテナ
• 本番権限や強いsecretを扱うものは分ける

判断基準は「同じshell history、同じgh認証、同じpackage cache、同じLLM agentの実行権限を共有してよいか」

コンテナをSSHできるマシンとして扱う

OrcaというADE（Agent Development Environment）を使用。Orcaの SSH worktrees機能でSSH targetを登録すると、remote host上にgit worktreeを作り、agentもremote host上で動かせる。 エディタ、diff、browserは手元に残しつつ、実行環境だけSSH先に寄せる。

• port forwardingもOrcaのPorts タブからGUI操作（VS CodeのPortsと同じ感覚）
• ブラウザ内の要素に直接コメントを書いてAgentに渡せる
• コードへのフィードバックをLLMにまとめて渡せる
• Agentが作業を終わると通知がくる

secret管理

物理ファイルにsecretを残さず、基本的に1Passwordの op CLI経由で必要なときに注入。

まとめ：マインドシフトの核心

「プロジェクトごとに毎回作られる開発環境」から「LLMエージェントが安定して入れる、自分用の開発マシン」へ。 これが、DevContainerから離れる根本的な理由。 コンテナを隔離された作業ディレクトリではなく、操作履歴・キャッシュ・生成ファイルが溜まる開発マシンとして扱う思想への転換。