※「ChatGPTと育てる、自分専用AI基盤」Season 1 最終回です。
第1回を書き始めた時、この連載が12回まで続くとは思っていませんでした。
そもそもの始まりは、かなり地味です。
ChatGPTとの会話で決めたことを、別のChatでも覚えていてほしい。
それだけでした。
モデルそのものへ長期記憶を追加することはできないので、VPSにMarkdown Vaultを置き、ChatGPTから読めるようにKnowledge MCPを作りました。
そこから、「コードも直接直してほしい」「Dockerの再起動までやってほしい」「AIが作った変更を安全にmainへ入れたい」「記事を書くだけでなくWordPressとSNSまで出したい」「毎回、次の作業を私が指定するのもやめたい」と、一つ前の不便を消すたびに次の不便が見えてきました。
気づけば、記憶を作っていたはずのVPSには、Development MCP、Runner、Publishing MCP、Loop Engine、Worker、Workspace、Authorityまで増えていました。
一人のChatGPTにメモを覚えさせたかっただけなのに、途中から小さな開発チームのようなものを作っていました。
Season 1の最後なので、今回は新しい機能を追加する話ではありません。
何を作ったかより、なぜここまで増えたのか。
そこを一度振り返ります。
最初に欲しかったのは「記憶」ではなく、仕事の継続性だった
第1回ではKnowledge MCPを作りました。
当時は「ChatGPTに長期記憶が欲しい」と考えていました。でも後から見ると、欲しかったものは少し違いました。
会話が終わっても、判断理由が残っている。別のChatへ移っても、前の続きができる。古い情報で上書きしない。間違えたらHistoryへ戻れる。
つまり欲しかったのは、Chatより長く続く状態でした。
この考え方は、その後ずっと残ります。
VaultではSHA-256を確認してから更新する。Gitではexpected HEADを確認する。PublishingではPublication revisionを確認する。LoopではRunとCheckpointを残す。
対象は変わっても、やっていることはかなり似ています。
前に見た状態を、今も同じだと思い込まない。
Season 1で一番繰り返した原則かもしれません。
「考えてくれるAI」から「実際に作業するAI」へ
Knowledge MCPの次にDevelopment MCPを作りました。
ChatGPTにコードを書いてもらえても、人間がSSHでVPSへ入り、ファイルを開き、貼り付け、テストし、結果をまたChatGPTへ返していたからです。
当時の私は、AIにコードを書いてもらいながら、かなりの時間をコードの運搬係として使っていました。
Development MCPで、その中継作業を減らしました。
でも、コードを直接触れるようになると、今度は権限が怖くなります。Dockerまで触らせれば便利です。ただしDevelopment MCP自身もDockerの中にいます。
そこで強い実行権限をDevelopment Runnerへ分けました。
そして実際、一度はComposeの依存関係でRunner自身まで再作成し、再起動を担当する仕組みが自分自身を止めました。
便利にしたら事故が増えた。事故が起きたから、--no-depsや自己restart拒否を入れた。
この連載は、だいたいずっとこの繰り返しでした。
できるようになったら、「採用してよいか」が問題になった
AIがコードを直し、テストまでできるようになると、次に怖くなったのはmainです。
できることと、採用してよいことは違います。
そこでGitHub Pull Requestを境界にしました。
AIは変更案を作る。branchへpushする。PRを出す。そこで初めて「正式な変更として入れるか」を判断する。
この「生成と確定を分ける」という考え方は、その後Publishing MCPにもそのまま使いました。
記事を書けることと、公開してよいことは別です。WordPress下書きを作る。previewする。公開後には外部から読み戻す。Xだけ成功してInstagramが失敗したら、全部をやり直さずInstagramだけ直す。
APIが200を返したことではなく、本当に目的の状態になったかを見るようになりました。
MCPを増やしたら、自律化した気になった
Knowledge、Development、Publishing。できることが増えてくると、かなり「AI基盤」らしく見えてきます。
当時は私も、かなり自動化されたと思っていました。
でも、実際には毎回、私が次の仕事を指定していました。
「このコードを直して」「記事を書いて」「SNSに出して」。言えば動く。言わなければ止まる。
ここで初めて、Capabilityが増えることと、Autonomyが生まれることは別だと気づきました。
そこで第6回でLoop Engineを作りました。
Goalを持つ。Planする。Capabilityを使う。Evidenceを見る。Evaluateする。次のActionを決める。
ここから、個々の道具ではなく仕事の流れを作り始めます。
Loopを作ったら、今度はChatより仕事を長生きさせる必要が出た
一回のループが回っても、長い仕事では足りません。
CIを待つ。人間の承認を待つ。ブラウザを閉じる。サービスを再起動する。
そこでRun、Event、Checkpoint、pause / resumeを作りました。
実際にLoop EngineのCoreとGatewayを再起動し、同じRun IDから続きを進める試験もしました。
この頃から、考え方がかなり変わっています。
最初は「ChatGPTが長く動いてほしい」と思っていました。でも必要だったのは、AIを何時間も止めないことではありませんでした。
AIが止まっても、仕事を失わないこと。
Chatは操作画面です。仕事のidentityはRun側へ移りました。
自動化と自律化も、分けないと無駄が増えた
Loop Engineを作ると、今度は何でもLoopへ入れたくなります。
でも、決まったQuality Gateの結果を待つだけなのに、毎回AIが考える必要はありません。
決められた手順を繰り返す仕事はAutomation / Workerへ。複数の仮説があり、Evidenceによって次の一手が変わる仕事だけLoopへ。
第8回では、ここを分けました。
そしてAutonomous Loopにも、無制限の権限は渡しません。
Goal、Success Criteria、Capability、risk、budget、approval boundaryの中でだけ次を選ぶ。
自律化とはAIを自由にすることではなく、安全に選べる範囲を作ることでした。
一つのAIが動いたら、次は複数同時に動かしたくなった
ここまで来ると、次に考えるのは並列化です。
Chat AでLoop Engine。Chat BでPublishing MCP。別のWorkerでQuality Gate。同時に進めれば速い。
実際、速くなりました。
そして普通に衝突しました。
同じworking treeを使う。mainが途中で進む。別Chatのworkspaceが見える。技術的には触れるから、別Chatの仕事まで進めそうになる。
第9回では、Workspace isolation、component lease、shared mutation serialization、live state、workspace ownershipまで増えました。
ここでAI基盤は、単に一人のAIを強くするものではなくなります。
複数の作業主体を調整するcontrol planeが必要になりました。
人間のチームと少し似ています。机を分ける。担当を決める。共有物は順番に触る。他人の仕事は勝手に引き継がない。
AIを増やしたら、組織のような問題が出てきました。
そして最後に、私自身がボトルネックになった
並列化すると、AI側は速くなります。でも安全のために毎回「承認してください」で私へ戻ってくる。
そこでStanding Delegationを作りました。
戻せるordinaryな仕事は、既存guardの範囲でそのまま続ける。本当に人間が必要な境界だけ残す。
さらにCapabilityをA0 / A1 / A2 / A3へ分類し、Authorityを機械的に狭めました。
そして最後に、その人間境界の入力を楽にするため、Approval UIと開発を続けてボタンを作りました。
ただし、ボタンにはAuthorityを持たせません。
UIは人間の意思を入力する。現在状態の再確認や、実行してよいかの判断はサーバー側に残す。
Season 1の最後に作った大きな仕組みは、AIの新しい能力というより、AIと人間の境界でした。
困りごとを消すたびに、新しい困りごとが生まれた
Season 1を一本につなぐと、かなり単純な構造になります。
覚えてほしい
↓
Knowledge MCP
↓
コードも触ってほしい
↓
Development MCP
↓
強い実行もしてほしい
↓
Runner
↓
勝手にmainへ入ってほしくない
↓
PR / Guarded Merge
↓
発信までやってほしい
↓
Publishing MCP
↓
次の仕事も考えてほしい
↓
Loop Engine
↓
途中で止まっても続けたい
↓
Run / Checkpoint / Resume
↓
本当に考える仕事だけAIへ回したい
↓
Autonomous Loop
↓
もっと同時に進めたい
↓
Parallel Chat / Workspace
↓
承認待ちで人間に詰まりたくない
↓
Standing Delegation / Authority
↓
人間の判断も楽にしたい
↓
Interactive Control UI最初にこの図を描いてから作ったわけではありません。
ほぼ逆です。
一つ困る。直す。使う。次の問題が出る。また直す。
後から並べたら、こうなっていました。
「完成した」と言うには、かなり未完成だった
この時点でも、やりたいことは山ほどありました。
Media Production Loop。Knowledge-Centric Content。Search ConsoleやGA4を使ったサイトGrowth。Contextual BanditやReward。もっと賢い自律化。バックアップや運用の改善。
なので、客観的に「完成したシステム」ではありません。
でも、自分の中では一つ大きな区切りがありました。
記憶できる。作業できる。長い仕事を継続できる。次の一手を限定された範囲で選べる。複数の仕事を並列に動かせる。人間は、本当に必要な境界だけを見る。
最初に欲しかった「ChatGPTと会話した続きを、もっと長く、もっと実際の仕事につなげたい」という目的に対して、一度かなり形になったと思えました。
だからSeason 1は、ここでいったん完成とします。
これは再現マニュアルではなく、開発記だった
この連載を書きながら改めて思ったのですが、私は誰かに同じ構成をそのまま再現してほしいわけではありません。
同じVPS。同じMCP。同じLoop Engine。同じWorker数。数年後には、もっと簡単な方法があるかもしれません。
技術そのものは変わります。
それでも残るのは、「便利にしたら、何が新しく壊れたか」という記録だと思います。
長期記憶を作ったらstale updateが怖くなった。実行権限を増やしたらself-restartが起きた。PRを増やしたらstale baseが問題になった。自律化したらAuthorityが必要になった。並列化したらownershipが必要になった。人間を減らしたら、人間をどこに残すかを考える必要が出た。
この因果の方が、具体的なtool名より長く残る気がします。
Season 1は、ここで終わります
Knowledge MCPを作ったところから始まったSeason 1は、ここで一区切りです。
ChatGPTに長期記憶を持たせたい、という小さな不満から始まって、最後は複数のAI作業系と人間のAuthority境界まで考えることになりました。
振り返ると、かなり遠くまで来ました。
でも、この時点で分かっていたのは、まだ「動かせるようになった」ところまでです。
システムが大きくなれば、別の問題も出てきます。
機能が存在することと、本当に全体として機能していることは同じなのか。今のChatGPTが見えている範囲で提案する最短ルートは、巨大になったシステム全体でも本当に最短なのか。誰が全体構造を理解して、どの実行方法を使うべきか決めるのか。
その話は、Season 2で続けます。
Season 1では、自分専用AI基盤を作った。
次は、一度作ったその基盤を疑うところから始まります。
Season 1 連載ナビ
- 第1回：ChatGPTに長期記憶が欲しくて、Knowledge MCPを作った
- 第2回：ChatGPTにコードを書かせるだけでは足りなかった。Development MCPを作った
- 第3回：AIに自分自身を再起動させたら止まった。Development Runnerを分離した
- 第4回：ChatGPTからPRを作り、安全にマージできるようにした
- 第5回：記事を書くだけでは自動化にならなかった。Publishing MCPを作った
- 第6回：MCPをいくつ作っても、AIは自律化しなかった。そこでLoop Engineを作った
- 第7回：AIが途中で止まっても、続きを再開できるようにした
- 第8回：作業自動化と「自律するAI」は何が違うのか
- 第9回：複数のChatGPTに同じシステムを開発させたら、普通に衝突した
- 第10回：AI開発のたびに「承認します」と打つのをやめた
- 第11回：AIに「承認」ボタンを作った。でも、ボタンに権限は渡さなかった
- 第12回：記憶から並列開発まで。自分専用AI基盤は、いったんここまでできた ← Season 1 Finale
- 連載一覧
コメント