AIにコードを書かせること自体は、もうそれほど難しくありません。
「この機能を追加して」「このエラーを直して」と頼めば、かなりのところまでコードを書いてくれます。では、その先もAIに任せようとするとどうなるのか。どのリポジトリを触るのか。現在のmainはどこなのか。別の開発と競合していないか。テストは通ったのか。Pull Requestを作ってよいのか。マージしてよいのか。本番へ反映してよいのか。途中で失敗した仕事はどうするのか。
私が実際にAIを使って開発を続けていく中で問題になったのは、コード生成能力よりも、こちらでした。
そこで作ったのがDevelopment MCPです。
この連載では、MCP（Model Context Protocol）を使いながら構築してきた私の自作AIサーバー「Personal AI Platform」を、実際に動いているコンポーネントごとに紹介します。第1回は、その中でも開発を担当するDevelopment MCPです。
なお、ここでいう「自作AIサーバー」は、LLMそのものを自宅やVPSで動かしているという意味ではありません。ChatGPTなどのLLMを推論役として使いながら、開発、知識管理、継続実行、Web公開といった実際の仕事を自分のサーバー側で処理できるようにした実行基盤を指しています。
AIにコードを書かせるだけでは「開発」にならなかった
最初に考えれば、AI開発は単純です。
LLMにターミナルを触らせて、Gitを使わせて、コードを書かせればよい。実際、小規模な作業ならそれでもかなり進みます。
問題は、それを何十回、何百回と繰り返し始めたときです。
一つの変更だけをしている間は、AIが「いま何をしているか」を会話の中で把握していれば何とかなります。しかし、複数の開発を同時に進めたり、一度中断した仕事を再開したり、別のChatから続きを始めたりすると、会話だけを状態管理に使う方法は急速に苦しくなります。
さらに、本番で使っているシステムをAI自身に改修させるようになると、「コードが書けるか」よりも「どこまで変更してよいか」の方が重要になります。
mainを直接変更してよいのか。テストに失敗したコードを残してよいのか。他の開発が使っているworkspaceを触ってよいのか。GitHub上のPull Requestを作ることと、それをマージすることは同じ権限でよいのか。production deployまでAIが勝手に進めてよいのか。
ここまで来ると、必要なのは「AIが使えるターミナル」ではありませんでした。
AIが開発を進めるための制御面そのものが必要でした。
Development MCPは「開発用の万能シェル」ではない
MCPの公式アーキテクチャでは、MCP Serverは特定の機能に集中し、Host側がオーケストレーションやセキュリティ境界を担当するという分離が基本思想になっています。
Model Context Protocol – Architecture
この考え方は、実際に自分のシステムを作ってみても非常に重要でした。
AIにbashを一つ渡して「好きに開発してください」とする方が、実装は簡単です。しかし、それではAIから見える操作範囲が広すぎます。「ファイルを読む」「コードを変更する」「Dockerを再起動する」「GitHubでマージする」「本番環境を書き換える」が、すべて同じ実行面に載ってしまいます。
Development MCPでは、逆にこれらを分けました。
LLMは、何をすべきかを考えます。しかし、実際に何ができるかはDevelopment MCP側で決まります。さらに時間のかかる開発処理はDevelopment Runnerへ渡し、jobとして状態を残します。
概念的には、現在の構成は次のようになっています。
ChatGPT / AI reasoner ↓ Development MCP ― 開発操作と安全境界 ↓ Development Runner ― 実行とjob管理 ↓ workspace / Git / test / GitHub / candidate ↓ 承認されたものだけproductionへ
AIを強くするというより、AIと現実のシステムの間に「関所」を作った、と考えた方が近いかもしれません。
なぜworkspaceを分ける必要があったのか
一つの開発だけを順番に進めている間は、Gitのbranchがあれば十分に見えます。
ところがAIを使うと、人間が一つずつ作業するより簡単に並列化できます。すると今度は、並列化した開発同士が同じファイルや同じGit状態を触る問題が出てきます。
AIを増やせば開発が速くなるとは限りません。共有状態をそのままにしてworkerだけ増やすと、むしろ競合が増えます。
そこでDevelopment MCPでは、「どの開発が、どのworkspaceを所有しているか」という境界を重要視するようになりました。別の作業が使っている場所を勝手に変更しない。共有リソースを変更するときには競合状態を確認する。Gitへのmutationも無制限に並列実行しない。
これはAI開発をしていて得たかなり大きな学びでした。
並列化の前に、分離できる状態を作らなければならない。
AIは作業者を増やすコストを劇的に下げますが、共有状態の競合までは消してくれません。
「PRを作る」と「マージする」を分ける
もう一つ重要だったのが、実行権限の分離です。
コードを書けるAIが、そのまま本番まで変更できる必要はありません。
Development MCPでは、コード変更、検証、Pull Request作成、マージ、本番反映を一続きの「開発」という言葉で扱わず、それぞれ別の境界として考えています。
例えばAIは変更を作り、テストし、PRを準備できます。しかし、マージには別の条件があります。さらにproductionへの反映は、マージできることとは別問題です。
この分離によって、
Reasoningできること ≠ 実行できること ≠ 本番を変更できること
という関係を保てます。
これはLLMの性能とは関係ありません。どれだけ賢いモデルを使っても、システム側の権限が「全部できます」になっていれば、判断ミス一回の影響範囲は大きくなります。
逆に、操作ごとに境界があれば、AIが間違えても被害を限定できます。
candidateとproductionを分ける
自分でAIサーバーを作り始めた当初は、「コードを修正した」「テストが通った」という地点が完成に見えました。
しかし、本番で使うシステムではそれでは足りません。
コード上は正しい。コンテナも起動する。テストも通る。それでも、現在のproductionとcandidateの構成が一致しているとは限りません。ソースコードだけ新しくても、実際に動いているruntimeが古ければ、本当に利用している機能は古いままです。
そのため、Development MCPではGitの状態だけでなく、candidate releaseやruntimeとの整合性も観測対象になっていきました。
これは地味ですが、AI開発との相性が非常に重要です。
LLMは「さっき修正したコード」を知っています。そのため、そのコードがすでに実環境で動いているように話してしまうことがあります。しかし、コード上の真実と、現在動いているシステムの真実は別です。
だから、AIの記憶ではなく、実際の状態を観測して判断する必要があります。
長い処理を「会話」に持たせない
開発作業には時間がかかるものがあります。
テスト、build、containerのrefresh、複数段階の検証などです。これらをChatGPTとの一回のtool callだけで完結させようとすると、処理中なのか、失敗したのか、どこまで進んだのかが曖昧になります。
そこでDevelopment Runnerでは、開発処理をjobとして扱います。
jobには状態があります。AIとの会話が切れても、処理自体の状態はサーバー側に残ります。別のChatからでも、現在どうなっているかを観測できます。
ここで初めて、「AIとの会話」と「開発処理」が分離しました。
これは小さな変化に見えますが、私のPersonal AI Platformではかなり大きな転換でした。
会話が状態なのではなく、サーバー上の状態をAIが読みに行く。
この形にすると、LLMを交換しても、Chatが変わっても、開発状態そのものは残ります。
Implementation snapshot ― 2026年8月31日
この記事の設計を確定した2026年8月31日時点で、Development Runnerには2,474件のjob履歴が保存されていました。
つまりDevelopment MCPは、「こんなMCPを考えてみた」という段階ではありません。実際のPersonal AI Platform開発で繰り返し使い、その過程で必要になった機能を追加し続けた結果、現在の形になっています。
その中で、特に重要になったのは次の点でした。
- AIのreasoningと実際のmutationを分離する
- workspaceを明示的に分け、並列開発の競合を管理する
- Gitの変更、PR、merge、production deployを別の権限境界にする
- long-runningな処理をdurableなjobとして残す
- source codeだけでなくruntimeの状態を観測する
- privileged operationを通常の開発経路から分離する
- 失敗や中断を前提として、再開できる状態を残す
振り返ると、Development MCPの主要機能の多くは「AIにもっとたくさんのことをさせるため」ではなく、AIができることを細かく分け、安全に繰り返せるようにするために増えてきました。
MCPが解決したのは「接続」であって、「開発」そのものではなかった
ここは、この連載で重要な点です。
MCPは非常に便利です。ChatGPTのようなHostから、自分のサーバーにある機能を標準化された形で呼び出せます。2026年7月28日の仕様更新でも、stateless coreへの移行、Authorizationの強化、長時間処理向けのTasksなど、本格的なagentic workflowを意識した方向への拡張が進んでいます。
Model Context Protocol – 2026-07-28 specification update
しかし、MCPを導入しただけでAIエージェントのシステム設計が完成するわけではありません。
MCPは接続方法です。
「どの状態を正とするか」「何をAIに許可するか」「並列処理をどう衝突させないか」「失敗からどう復旧するか」「どこから人間の承認を必要とするか」といった問題は、その上に自分で設計する必要があります。
Development MCPを作って得た最大の知見は、むしろここだったと思います。
そして、Development MCP自体も最終形ではない
現在、私のPersonal AI Platformは次の段階へ移ろうとしています。
これまではBrowser版ChatGPTをHostとして、そこからMCPを経由してDevelopment MCPや他のMCPを呼び出す構成が中心でした。これは現在も実際に動いている経路です。
一方で、開発量が増えるにつれて、ブラウザ上の一回一回の会話を起点にする構成にも限界が見えてきました。そこで現在は、CLIを常駐させ、より持続的にreasoningと実行を続けられる構成への移行を進めています。
そうなると、将来的には「ChatGPT → MCP → Development MCP」という現在の見た目は変わるかもしれません。
しかし、不思議なことに、そのためにDevelopment MCPが不要になるわけではありません。
変わるのは入口です。
workspaceを分けること。reasoningとmutationを分離すること。権限境界を作ること。jobをdurableにすること。candidateとproductionを区別すること。こうしたDevelopment MCPを作る過程で得た設計原則は、そのまま次のCLI構成にも必要です。
このため、この連載では将来の構成に合わせて過去を書き換えるのではなく、MCPを中心に自作AIサーバーを組み上げた時点のアーキテクチャとして残しておこうと思っています。
後から見れば、これはPersonal AI Platformの第1世代になるのかもしれません。
Development MCPを作って分かったこと
最初は、「AIに開発させたい」と考えていました。
今なら、少し違う言い方をします。
AIが安全に開発を続けられる環境を作りたい。
コードを書く能力はLLM側がどんどん改善していきます。モデルも入れ替わります。しかし、どのモデルを使っても、リポジトリ、権限、状態、並列実行、検証、承認、本番環境という現実側の問題は残ります。
Development MCPは、その現実側を担当するために作った仕組みです。
そして、この仕組みを作ると次の問題が出てきます。
AIが安全に開発できるようになっても、「前回何を決めたのか」「現在の正しい仕様はどれなのか」をAIが知らなければ、長期間の開発は続けられないのです。
そこで必要になったのが、次回紹介するKnowledge MCPでした。
次回は、なぜChatGPTの会話履歴やMemoryだけでは足りず、AIの外側に2,000件を超える文書を持つ知識基盤を作ることになったのかを書きます。
「MCPでつくる自作AIサーバー」シリーズ
- #1 Development MCP――AIに「開発そのもの」を任せるために作った仕組み（この記事）
- #2 Knowledge MCP――AIに「記憶」ではなく知識基盤を持たせる（準備中）
- #3 Loop Engine――MCPをつなぐだけではAIエージェントは動き続けない（予定）
- #4 Publishing MCP――ChatGPTからWordPressとSNSまで公開する仕組み（予定）
コメント