エディタと管制塔。
AIネイティブな開発環境の作り方。

01 — THE SHIFT

一人が一画面で書く開発から、複数の仕事を委任する開発へ

これまでの開発環境は、人間が目の前にいることを前提にしていた。人がエディタを開き、コードを書き、ターミナルでテストを回し、終わったらパソコンを閉じる。CPUもメモリも、その一人が待たずに作業できればよかった。

AIエージェントは、この前提を変える。人が寝ている間にも、一つのエージェントは実装し、別のエージェントは調査し、もう一つはレビューできる。OpenAIは、社内のヘビーユーザー上位1%が、2026年6月には複数エージェントを通じて一日60時間超のエージェント稼働を生み出していたと報告している。人間の一日は24時間のままなのに、作業時間だけが並列化される。

これは、生産性が3倍になった、というだけの話ではない。三人の開発者を同時にマネジメントするのと、一人で3倍速くキーを打つのは違う。前者には、仕事の分割、環境の分離、途中経過の監視、成果の統合が必要になる。

AIネイティブな開発環境とは、AIが入ったエディタではない。人が離れていても、複数の仕事が衝突せず進み、必要なときだけ人が判断できる開発システムである。

OpenAIがCodexアプリを「複数エージェントのcommand center」と呼び、AnthropicがClaude Codeの利用を「continuous orchestration」と説明しているのは象徴的である。主役がコード入力から、仕事の指揮へ移っている。

02 — THE MOTHERSHIP

強い一台を「開発母艦」として置く

まず考えたいのは、毎日持ち歩くノートPCとは別に、常時稼働できる一台を置くことである。Mac miniやMac Studioでもよいし、WindowsやLinuxのワークステーションでもよい。重要なのは製品名ではなく、場所と役割が固定されていることだ。

この一台には、いつも同じリポジトリ、Dockerイメージ、ブラウザ、開発ツール、ローカルMCP、認証済みのアプリがある。移動中のMacBookで環境を作り直す必要がない。AIエージェントから見ても、昨日の続きが同じ場所にある。

一方で、何でもこの一台で計算する必要はない。大きなテスト、独立した長時間タスク、信頼できないコードは、クラウドの一時環境や別のランナーへ逃がせる。Claude Code on the webはタスクをクラウドで動かし、Codex cloudもタスクごとに独立したsandboxを用意する。母艦に集めるべきなのは、計算量より文脈と入口なのだと思う。

ハードウェア選びでは、瞬間的なCPU性能だけを見ないほうがよい。複数のDocker、ブラウザ、テスト、エージェントを同時に置くと、先に効くのはメモリ容量、SSDの空きとI/O、冷却、安定した有線ネットワークであることが多い。さらに24時間運用なら、UPS、自動再起動、バックアップ、ディスク使用量の通知までが開発環境になる。

03 — MULTIPLE DOORS

接続経路は一つにしない。ただし、公開ポートは増やさない

24時間動かしても、必要なときに触れなければ意味がない。ここでは、同じ入口を三つの解像度で持つのがよいと思う。

Codexのモバイル連携は、専用のMac miniやremote environment上のセッションへ接続し、diff、テスト結果、承認まで扱える。Claude Code Remote Controlも、ローカルのファイルやMCPを保持したまま、ブラウザやモバイルから操作できる。日常の確認は、まずこの細い入口で足りる。

SSHでは、Warpのようなエージェント指向のターミナルも便利である。ただし2026年8月時点のWarp公式資料では、SSH先でもAgent Mode、コマンド、MCP、Blocksは使える一方、remote filesystemのネイティブなindex、diff、file tree、code review panelは未対応とされる。できることと、ローカル時だけできることを分けて使いたい。

GUIの非常口としてRustDeskを使うなら、常時フル権限にするのではなく、キーボード、clipboard、file transferなどを必要に応じて制限する。RustDeskはself-hosted serverも選べるが、サーバーを自分で持つことは安全性を自動的に保証しない。更新、ログ、MFA、アクセス制御まで自分の責任になる。

04 — PARALLEL WITHOUT COLLISION

並列化する前に、仕事・ファイル・実行環境を分ける

エージェントを増やすのは簡単である。難しいのは、同じファイルを書き換え、同じポートを取り、同じデータベースを壊さないようにすることだ。

最小単位は、一つの仕事に一つのGit worktreeである。AnthropicのClaude Code Best Practicesも、OpenAIのCodexアプリも、複数エージェントを並列に動かす方法としてworktreeを挙げている。ファイルの作業場所を分け、最後にdiffとcommitを通じて合流させる。

ただし、worktreeが分けるのは主にファイルである。アプリを起動すれば、ポート、Docker Composeのproject name、データベース、キャッシュ、ログ、ブラウザprofileまで衝突する。だから本気で並列化するなら、worktreeごとに実行環境も分ける。

1. 一仕事・一worktree・一branch

   目的と所有者を一つにする。同じファイルを触る仕事は、無理に並列にしない。

2. 一worktree・一実行名前空間

   ポート、Compose project、DB、テストデータ、ログの名前をworktree IDから決める。

3. 環境をコードにする

   devcontainer.json、Dockerfile、セットアップスクリプトをリポジトリに置き、エージェントが自分で再現できるようにする。

4. 重い準備をprebuildする

   毎回Docker imageと依存関係をゼロから作らない。VS Codeはpre-built Dev Container imageを推奨し、GitHub Codespacesにもprebuildがある。

5. 並列数に上限を置く

   CPU、メモリ、ディスク、API利用量の予算を決める。空いているから起動するのではなく、完了条件が独立した仕事だけを増やす。

OpenAIのagent-firstな開発事例では、アプリ、ログ、メトリクスまでworktreeごとの一時環境にし、エージェント自身がブラウザとobservabilityを使って検証できるようにしている。人間に見えるものをAIにも見えるようにする。この「見える環境」まで含めて分けることが、並列化の本体なのだと思う。

05 — CONTEXT AND PERMISSION

情報は集める。権限は集めすぎない

コードだけを見て、よいプロダクトは作れない。顧客がSlackで何に困っていたか。Gmailで何を約束したか。Calendarでいつ意思決定があるか。Notionの仕様がどこまで確定しているか。GitHubで過去に何を試したか。AIエージェントが仕事を完結するには、開発の外にある文脈も必要になる。

ここでMCPや各サービスのconnectorが、開発母艦の意味を大きくする。毎回人間が会話をコピーするのではなく、エージェントが必要なときに原文、issue、予定、変更履歴へ戻れる。

一方で、全部へ接続した一台は、全部の情報へ届く一台でもある。便利さとblast radiusは同じ方向に増える。だから「一つのスーパーアカウント」を作るのではなく、用途ごとに権限を分けるべきだと思う。

GitHubも、長期のintegrationには個人の強いtokenより、repositoryと操作を細かく限定でき、短命tokenを使うGitHub Appを勧めている。AIに多くの文脈を渡すことと、AIに多くの変更権限を渡すことは分けられる。

また、文脈は接続数だけでは決まらない。リポジトリの中に、目的、制約、コマンド、完了条件、設計判断が短く整理されているほうが強い。エージェントが毎回Slack全件を読み直すより、必要な判断がissueや設計文書へ着地しているほうが、速くて再現性がある。

06 — VOICE TO CONTRACT

音声は、長い文脈を渡す入口になる

エージェントを複数動かすようになると、キーボードで一件ずつ細かく指示すること自体がボトルネックになる。移動中に気づいた不具合、顧客との会話で変わった優先順位、画面を見ながら感じた違和感は、音声のほうが速く、温度も含めて渡しやすい。

ただし、音声は仕様書ではない。話し言葉には、主語の省略、言い直し、途中で変わった結論が含まれる。音声のまま実装へ流すと、たくさん説明したのに違うものができる。

自分なら、音声入力の直後に、エージェントへ四つだけ言い直させる。「何を変えるのか」「何を変えないのか」「どうなれば完了か」「何を人が決める必要があるか」。ここで認識を直してから、別のエージェントや夜間タスクへ渡す。

音声エージェントの価値は、声でコードを書くことではない。人間の中にしかなかった文脈を、並列に配れる仕事へ変換することにあるのだと思う。

07 — REPORT, DON'T WATCH

端末を監視するのではなく、証拠をレポートさせる

24時間動くエージェントを、24時間人が見張ることはできない。ターミナルに大量のログが流れている状態は、動いているようには見えるが、管理できている状態ではない。

必要なのは、進捗の実況ではなく、判断できる節目での報告である。Slackやモバイル通知は、長いログの転送先ではない。「終わった」「止まった」「決めてほしい」の三種類を知らせる場所にする。

AIによるcode reviewも有効だが、生成したエージェントと同じ観点だけでは見落としが残る。別のエージェントに、security、test、UI、要件適合など役割を分けてレビューさせ、そのうえで人は顧客価値、取り返しのつかなさ、本番への適合を見る。

OpenAIのharness engineeringで重要なのも、単にレビューをAIへ渡したことではない。ブラウザ、ログ、メトリクス、architecture ruleを、エージェント自身が読めて機械的に検査できる形へ変えたことだった。よいレポートは、文章の上手さではなく、戻れる証拠から作られる。

コードの量が増えるほど、人間が読むべきものはコード全文ではなく、意図、差分、証拠、リスクになる。

08 — THREE LEVELS

AIネイティブな環境は、三段階で作る

最初からMac Studio、別サーバー、UPS、remote desktop、複数runnerを全部買う必要はない。運用していない機材は、能力ではなく保守対象になる。まず、今の仕事のどこが止まっているかを見る。

強いサーバーを買うべきタイミングは、エージェントが遅いと感じたときではない。メモリ不足で並列数を下げている、Docker buildが日常作業を止める、ノートPCのsleepで長時間タスクが切れる、移動のたびに環境と認証を作り直している。こうした具体的な待ち時間が見えたときである。

逆に、taskの切り方が曖昧で、同じファイルを全員が触り、testも完了条件もない状態では、マシンを強くすると失敗が速くなる。AIネイティブな開発の最初の投資は、GPUでもCPUでもなく、仕事の境界と検証可能性なのかもしれない。

09 — CONCLUSION

開発環境から、開発システムへ

これまでの開発環境は、エンジニア一人の身体を拡張するものだった。よいキーボード、広いディスプレイ、速い補完、使い慣れたshell。すべては、目の前の一人が速く考え、速く書くためにあった。

AIエージェントが入ると、開発環境は小さな組織に近づく。誰に何を渡すか。どの情報を見せるか。作業場所をどう分けるか。いつ報告させるか。何を機械で検査し、何を人が承認するか。マシンのspecより、運用設計の差が大きくなる。

自分なら、中央に常時稼働の開発母艦を置く。携帯からはCodexやClaude CodeのRemote Controlで判断し、TailscaleとSSHで深く入り、GUIが必要なときだけRustDeskを開く。仕事はworktreeとDev Containerで分け、重い処理はcloudへ逃がす。Slack、Gmail、Calendar、Notion、GitHubの文脈は読めるようにする一方、書く権限は分ける。そして、すべての仕事をdiff、test、画面、リスクのレポートで閉じる。

AIネイティブな開発環境は、最強の一台ではない。文脈が集まり、仕事は分かれ、証拠だけが戻ってくる構造である。

ただし、中央に置いた一台が、いつまで個人の母艦であり続けられるのかはまだよくわからない。エージェントがさらに増えれば、母艦は物理的なPCではなく、複数の環境を束ねるcontrol planeへ変わるはずである。今作るべきなのは、その未来へ移れる小さな管制塔なのだと思う。