※「ChatGPTと育てる、自分専用AI基盤」第2回です。前回は、ChatGPTとの会話をその場限りにしないために、VaultとKnowledge MCPを作ったところまで書きました。
→ 第1回：ChatGPTに長期記憶が欲しくて、Knowledge MCPを作った
Knowledge MCPができると、過去の記録を探し、読んで、必要なら新しい文書を残せるようになりました。
次に気になったのは、開発です。
ChatGPTに「こういう機能が欲しい」と相談すると、コードを書いてくれます。エラーを貼れば、原因を考えて修正版も出してくれる。これはかなり便利でした。
でも、そこで仕事は終わりません。
出てきたコードをコピーする。SSHでVPSへ入る。ファイルを開く。貼り付ける。テストを実行する。エラーが出たら結果をChatGPTへ戻す。新しいコードをまた貼る。
AIがコードを書いているのに、私はずっとコードの運搬係をしていました。
それなら、コードを考えるところだけでなく、その先の開発作業までChatGPTから直接できないだろうか。
そこで作ることになったのがDevelopment MCPです。
「答える」だけでなく、実際に作業してほしかった
2026年7月29日に残した構想では、最優先目標をかなり直接的に書いていました。
ブラウザ版ChatGPTから、
- ファイルやディレクトリを調べる
- コードを作成・修正する
- テストする
- 動作状態を確認する
- Git差分を見る
- 問題があれば戻す
ところまで進めたい。
要するに、
ChatGPTで相談
↓
人間がコードを運ぶ
↓
VPSで実行
↓
結果をChatGPTへ戻すという往復を、
ChatGPT
↓
Development MCP
↓
開発領域を調査・変更・テスト
↓
結果をそのままChatGPTで確認へ変えたかったわけです。
いまなら自然に見えますが、当時はこれがかなり大きな境目でした。
ChatGPTが「こう直してください」と答えるのと、実際にサーバー上のファイルを書き換えるのとでは、必要な権限がまったく違います。
Knowledge MCPを強くするのではなく、別のMCPを作った
一番簡単そうなのは、すでに動いていたKnowledge MCPへ開発機能を追加することでした。
でも、それはやりませんでした。
Knowledge MCPが扱うのは、主にMarkdownの記録です。Development MCPが扱うのは、コード、Git管理領域、テスト、ログなどです。
さらに将来的には、サービスの再起動やDocker操作まで必要になる。
同じ「ファイルを触る」でも、失敗したときの影響が違いすぎます。
そこで、Knowledge MCPは知識管理の道具として残し、開発は別のMCPへ分けました。
これは、その後のPersonal AI Platformでも繰り返し使うことになる考え方です。
便利だから一つにまとめるのではなく、必要な権限が違う仕事は分ける。
Development MCPがないので、Development MCPを作れない
ただし、ここで少し面白い問題がありました。
Development MCPを作る目的は、ChatGPTからサーバー上の開発をできるようにすることです。
でも、そのDevelopment MCPはまだ存在していません。
つまり最初の一回だけは、Development MCPなしでDevelopment MCPを作る必要があります。
そこで初期実装には、GitHubのprivate repositoryとCodex Cloudを使いました。
先に仕様を文章でまとめ、Codex Cloudにリポジトリ上で初期コードを書いてもらう。それをVPSへ持ってきて起動し、ChatGPTから接続できるところまで作る。
最初から完成版を作ったわけではありません。
初期実装で用意したのは、たとえば次のような機能でした。
- ディレクトリ一覧
- ファイル読取
- ファイル作成・変更
- Git status / diff
- pytest
- ログ読取
- health check
Docker操作やサービス再起動、長時間ジョブなど、強い機能はまだ入れていませんでした。
まずは「ChatGPTから安全に開発領域を見て、書いて、テストできる」ところを通す。それから能力を増やす方針です。
何でも触れるようにはしなかった
Development MCPを作るときに気にしていたのは、何ができるか以上に、何をできなくするかでした。
初期実装には、次のような制約を入れています。
- 書き込み可能なルートを限定する
- パストラバーサルを防ぐ
.env、SSH鍵、credential、tokenなどの秘密情報を読ませない- 出力中の秘密値をマスクする
- VaultはDevelopment MCPからread-onlyにする
- MCP本体はlocalhostで待ち受ける
- Docker socketをDevelopment MCPへ直接渡さない
- 監査ログを残す
AIへサーバー全体のshellを丸ごと渡した、という構成ではありません。
感覚としては、万能な管理者権限を渡すのではなく、開発に必要な専用工具を一つずつ作ったに近いです。
この違いは、その後かなり重要になりました。
最初から普通に動いたわけではない
当然ですが、初回からきれいには動きませんでした。
最初の分かりやすい失敗は、ポート番号です。
Development MCPの初期構成も8000番ポートを使う想定になっていました。しかし、その8000番ではすでにKnowledge MCPが動いていました。
新しいサービスを作ったのに、既存サービスと同じ住所を指定していたようなものです。
そこでDevelopment MCPを18080番へ変更し、さらにbootstrap時にポート競合を検査するようにしました。
単に今回だけ別の番号へ変えるのではなく、一度起きた失敗を次回は仕組みで止めるようにしたわけです。
既存Knowledge MCPを壊さないことも、bootstrapや構成上のチェックとして明示しました。Compose project、Tunnel、systemdも別にします。
「既存環境を壊さないで」とAIにお願いするだけではなく、壊しにくい構造へ寄せていく。この考え方も、ここから強くなっていきました。
ChatGPTからVPSへ、初めて直接書けた
2026年7月30日、Development MCPをSecure MCP Tunnel経由でChatGPTへ接続し、実際の書き込み試験をしました。
ブラウザ版ChatGPTからDevelopment MCPを呼び、VPS上の許可領域 /srv/lab にMarkdownファイルを作成する。そして、そのファイルをもう一度読み返す。
結果は成功でした。
経路としては、
ChatGPT
↓
Secure MCP Tunnel
↓
Development MCP
↓
VPSの許可された開発領域です。
いま見ると、作ったのはMarkdownファイル1枚です。
かなり地味です。
でも私にとっては、この試験が一つの境目でした。
それまでは、ChatGPTが出したコードやコマンドを自分がサーバーへ運んでいました。
ここからは、
「このファイルを直して。テストして。結果を見せて」
という会話から、実際の変更までつながるようになったからです。
AIが相談相手から、少しずつ開発環境の操作主体へ変わり始めました。
成功すると、すぐに次の要求が出る
接続試験が通ると、当然もっとやらせたくなります。
ファイルを読むだけでなく移動したい。不要なテストファイルは消したい。限定したコマンドを実行したい。Git commitもしたい。
そこで、move、delete、git commit、制限付きcommand executionなどを追加し、Ruff、mypy、pytestを通しながら能力を広げました。
ただし、その先にはさらに強い作業が残っていました。
- Docker Composeでサービスをbuildする
- コンテナを再起動する
- 長時間のテストや処理を走らせる
- 失敗したらrollbackする
ここをDevelopment MCP自身に持たせようとすると、別の問題が出ます。
Development MCP自身もDockerコンテナとして動いているからです。
自分を更新するために、自分自身を再起動する。
しかもDocker socketを直接渡せば、Development MCPの権限は一気に強くなる。
ここで、「Development MCPの中に全部入れる」のはやめることになります。
次に作ったのが、強い実行処理を外側で担当するDevelopment Runnerでした。
振り返ると、人間の役割を一つ消した回だった
Development MCPを作ったことで、ChatGPTが急に優秀なプログラマーになったわけではありません。
変わったのは、AIと実環境の間にいた人間の仕事です。
以前は、
AIが考える
↓
人がコピーする
↓
人がVPSを操作する
↓
人が結果をコピーする
↓
AIがまた考えるでした。
Development MCPの後は、かなりの部分が、
AIが考える
↓
許可された範囲で実行する
↓
結果を読む
↓
次の修正を考えるへ変わりました。
私が完全に外れたわけではありません。どこまで権限を渡すか、何を作るか、結果を採用するかは人間が決めます。
それでも、コードの運搬係という役割はかなり減りました。
そして、この「人間がやっていた中継作業を一つ消す」という考え方が、その後のPublishing MCPやLoop Engineにもつながっていきます。
次回：強い実行権限を外へ出す
Development MCPで、ファイル、テスト、Git周辺の作業をChatGPTから進められるようになりました。
でもDocker操作や再起動、長時間ジョブまで同じ場所へ入れると、Development MCP自身を巻き込むうえ、権限も強くなりすぎます。
この続きとして、Development Runnerを外側へ分離した経緯を第3回にまとめました。
連載ナビ
- 第1回：ChatGPTに長期記憶が欲しくて、Knowledge MCPを作った
- 第2回：ChatGPTにコードを書かせるだけでは足りなかった。Development MCPを作った ← 今回
- 第3回：AIに自分自身を再起動させたら止まった。Development Runnerを分離した
- 第4回：ChatGPTからPRを作り、安全にマージできるようにした
- 第5回：記事を書くだけでは自動化にならなかった。Publishing MCPを作った
- 第6回：MCPをいくつ作っても、AIは自律化しなかった。そこでLoop Engineを作った
- 連載一覧
コメント