※「ChatGPTと育てる、自分専用AI基盤」第6回です。
前回は、ChatGPTに記事を書いてもらうだけでは残っていたWordPress入力、画像設定、SNS投稿までを一つにつなぐため、Publishing MCPを作ったところまで書きました。
→ 第5回：記事を書くだけでは自動化にならなかった。Publishing MCPを作った
ここまでで、かなりいろいろなことがChatGPTからできるようになりました。
Knowledge MCPで、過去の記録を探せる。
Development MCPで、コードを読んで直し、テストできる。
Development Runnerで、Docker操作や長時間処理を走らせられる。
GitHub Pull Requestで、変更案と正式採用を分けられる。
Publishing MCPで、記事をWordPressへ出し、SNSまでつなげられる。
一見すると、かなり「自動化されたAI」に見えます。
でも、実際に使っていると大きなことが一つ変わっていませんでした。
次に何をするかを決めるのは、毎回自分だった。
「開発を続けて」
「この記事を作って」
「次はこの問題を直して」
と私が指示すれば、AIはかなり先まで進めます。
でも、指示しなければ止まります。
MCPを増やして「できること」は増えたのに、「次に何をすべきかを自分で決める仕組み」はまだありませんでした。
そこで作り始めたのがLoop Engineです。
MCPは「できること」を増やす道具だった
ここまで作ってきたMCPを振り返ると、それぞれ役割はかなり明確です。
Knowledge MCP
→ 知識を読む・残す
Development MCP
→ コードを調べる・直す・テストする
Development Runner
→ 強い実行・長時間処理を行う
Publishing MCP
→ WordPress・SNSへ届けるつまり、どれもCapability＝できることを増やす仕組みでした。
これは非常に役に立ちました。
以前は人間がやっていたファイル操作、テスト、投稿準備などを、ChatGPTから直接進められるようになったからです。
ただ、Capabilityが増えたからといって、それらをどう組み合わせるかまで自動的に決まるわけではありません。
たとえば、ある開発作業で、
- Vaultから過去の判断を読む
- Gitの状態を確認する
- コードを修正する
- テストする
- 結果を評価する
- 失敗なら別の修正を試す
- 成功したら記録を残す
という流れを回したいとします。
個々の道具はすでにあります。
でも、今どの段階なのか、次に何を呼ぶべきなのか、結果が十分なのかを決める役はまだChatGPTとのその場の会話と私に残っていました。
ここで初めて、「道具を増やす」だけでは自律化にならないことがはっきりしました。
欲しかったのは、MCPの上にある「司令塔」だった
2026年8月8日に作り始めたLoop Engineの目的は、既存MCPを置き換えることではありませんでした。
むしろ逆です。
すでにあるKnowledge MCP、Development MCP、Publishing MCP、n8nなどをそのまま残し、その上に汎用Orchestratorを追加する方針にしました。
概念的には、こうです。
Goal
↓
Loop Engine
┌─────────┼─────────┐
↓ ↓ ↓
Knowledge MCP Development Publishing MCP
MCP / Runner
↑ ↑ ↑
└──── Evidence ─────┘
↓
Evaluate
↓
Next Action
↺Loop Engine自身がKnowledgeを管理するわけではない。
Loop Engine自身がコードを書くわけでもない。
Loop Engine自身がWordPressへ投稿するわけでもない。
目標を見て、次にどのCapabilityを使うかを決め、結果を評価し、次の一手へ進む。
この役割を別レイヤーとして作ることにしました。
最初に決めたのは「Goal」と「Success Criteria」だった
Loop Engineを作るとき、単に「自動で動き続ける仕組み」にすると危険です。
何をもって終わりなのか分からないまま処理を続ける可能性があるからです。
そこで、Runの出発点に、
- Goal
- Success Criteria
- Constraints
- Budget
を置きました。
つまり、
何を達成したいのか。何を確認できれば成功なのか。どこまでやってよいのか。
を最初に定義します。
たとえば「Pythonで42を出す」だけなら、stdoutに42が出たかというEvidenceを見れば成功と判定できます。
実際、最初期のlive rehearsalではSandbox Workerで6 * 7 = 42を実行し、stdoutと生成ファイルの両方をEvidenceとして確認しました。
かなり地味なテストです。
でも重要なのは計算結果ではありません。
Goalを受け取る
↓
必要な情報を読む
↓
実行する
↓
Evidenceを集める
↓
Success Criteriaと照合する
↓
成功なら終了、失敗なら次を考えるというループが、実環境で一周したことでした。
PlannerとEvaluatorを分けた
Loop Engineでは、次の一手を考える役と、結果を評価する役も分けました。
Plannerは、現在のGoalと状態から、次に何をするかを提案します。
Evaluatorは、その結果がSuccess Criteriaを満たしているかを見ます。
この分離はかなり重要でした。
同じAIが「これをやります」と決め、その直後に「うまくいきました」と自己申告するだけでは、評価が甘くなります。
そこで、少なくともシステム上は、
Plan
↓
Execute
↓
Observe / Evidence
↓
Evaluateを別段階として扱いました。
そして、Evidenceなしに成功扱いしないことを基本原則にしました。
第5回で「APIが200 OKを返したから成功」ではなく、WordPressやBufferから読み戻して確認したのと同じです。
対象は変わっても、ここでも「実際の状態を見る」考え方が繰り返されています。
Loop Engineに強い権限を集めなかった
ここまで読むと、Loop Engineを最上位に置くなら、全部の権限を持たせればよいようにも見えます。
でも、それはやりませんでした。
Development RunnerにはDocker socketがあります。
Publishing MCPには外部公開の経路があります。
Knowledge MCPには長期記憶があります。
それらをLoop Engineへ直接まとめると、また「万能で強い一つのサービス」へ戻ってしまいます。
そこでLoop Engine側も、Capability RegistryとPolicy Engineを持たせ、使える操作を明示的に制限しました。
riskも、たとえば、
- read_only
- reversible_write
- externalsideeffect
- privileged
のように分けます。
Autonomous modeがあっても、何でも自由に実行できるわけではありません。
許可されたCapability、risk、budget、stop conditionの範囲だけで動く設計にしました。
ここまでの連載で繰り返してきた「強い権限を一か所へ集めない」という原則を、Loop Engineでも維持しています。
最初から有料AI APIを前提にしなかった
Loop Engineという名前から、サーバー側でLLM APIを常時呼び続ける仕組みを想像するかもしれません。
でも初期実装では、それを必須にしませんでした。
すでにブラウザのChatGPTと各MCPが使えています。
なら、最初はChatGPTをPlanner / Evaluatorとして使い、Loop Engineは状態機械とCapabilityの受け渡しを担当すればよい。
そこでHOST_DRIVENという経路を作りました。
概念的には、
Loop Engine
↓ 次にplanが必要
ChatGPT
↓ planを返す
Loop Engine
↓ 外部actionが必要
ChatGPT / MCP
↓ 結果を返す
Loop Engine
↓ evaluationが必要
ChatGPT
↓ 評価を返す
Loop Engineという形です。
これなら、Loop Engineを作った瞬間から新しい有料APIコストを発生させる必要がありません。
後にserver-side Reasonerも追加できるように設計しましたが、paid APIはRun単位の明示authorizationとcost capを必要とする方針にしました。
自律化したいからといって、費用の境界まで自動で開けない。
これも一つの安全境界でした。
Vaultは記憶、SQLiteは「いま何をしているか」
Loop Engineを作ると、もう一つ重要な区別が必要になりました。
Knowledge MCPとVaultには長期記憶があります。
では、Loop Engineの現在状態も全部Vaultへ書けばよいのか。
そうはしませんでした。
Vaultは、あとから人間やAIが読む長期知識に向いています。
一方、Loopの途中には、
- 今何iteration目か
- 次のaction待ちか
- approval待ちか
- evaluation待ちか
- どのEvidenceを得たか
といった、細かく変化する実行状態があります。
この実行状態はSQLiteへ持たせました。
Vault
→ 長期記憶・lesson・判断
SQLite
→ Runの現在状態・event・実行履歴この分離によって、Chatが閉じても「どこまで進んでいたか」を外部状態として持てるようになっていきます。
ただし、このRun / Checkpoint / Resumeの話は、次回の主題です。
第6回では、まず「MCPの上に次の行動を決める層が必要になった」ことが大きな転換点でした。
最初のlive loopが一周した
2026年8月8日の初期candidateでは、Loop EngineとSandbox Workerを実環境へ統合しました。
最初のE2E rehearsalでは、
- Loop Runを作る
- Knowledge MCPからVaultのplanning contextを読む
- Sandbox WorkerでPythonを実行する
42をEvidenceとして確認する- Success Criteriaを判定する
- Runを
succeededにする - lessonをMemory Outboxへ入れる
- Knowledge MCP経由でVaultへ残す
ところまで完走しました。
さらに、Knowledge MCPのread-only操作はLoop Engineからserver-sideで呼び、Development MCPのような強い操作はChatGPT側へhandoffするという境界も確認しました。
つまり、全部を一気に自律化したのではなく、
安全なread-onlyは内側で、強い操作は外側で。
という段階的な構成から始めています。
「自律するAI」を作ったというより、ループを作れる土台を作った
ここは少し言葉を慎重にしたいところです。
第6回の時点で、AIが完全に自律して何でも勝手に進めるようになったわけではありません。
むしろ最初に作ったのは、
- Goalを持つ
- 次のActionを選ぶ
- Capabilityを使う
- Evidenceを見る
- Success Criteriaで評価する
- 必要なら次のActionへ進む
という閉じた仕事の形です。
これまでのMCP群は、一つ一つの作業を強くしてきました。
Loop Engineは、それらをどう順番に使うかを扱う層でした。
Capabilityを増やす
≠
Autonomyが生まれるこの違いに気づいたことが、Loop Engineを作った一番大きな理由だったと思います。
振り返ると、初めて「AIの仕事の流れ」を設計し始めた回だった
Knowledge MCPでは記憶を作りました。
Development MCPでは手を作りました。
Runnerでは強い手を別の場所へ置きました。
GitHub PRでは確定境界を作りました。
Publishing MCPでは外へ届ける経路を作りました。
そしてLoop Engineでは、初めて、
「次に何をするか」そのものをシステムとして扱い始めました。
それまでは、私が毎回ChatGPTへ次の一手を与えていました。
Loop Engineを作ったことで、GoalとEvidenceの間を、Plan → Execute → Evaluateのループとして扱えるようになった。
ここからPersonal AI Platformは、便利なMCPの集合から、少しずつ「仕事を回す基盤」へ変わり始めます。
ただし、仕事を回し始めると、次の問題がすぐに出ます。
一回のChatや一回の処理で終わらない仕事を、途中で止まっても続けられる必要があります。
ブラウザを閉じても、サービスが再起動しても、どこまで進んだかを失いたくない。
そこで次に重要になったのが、Run、Event、Checkpoint、pause / resumeです。
次回：AIが途中で止まっても、続きを再開できるようにした
第7回では、Loop Engineを「その場で一周するループ」から、長時間の仕事を途中で止めても再開できるdurableな仕組みへ変えていった話を扱います。
ChatではなくRunを仕事のidentityにし、Checkpoint、lease、pause / resumeを持たせた理由を振り返ります。
連載ナビ
- 第1回：ChatGPTに長期記憶が欲しくて、Knowledge MCPを作った
- 第2回：ChatGPTにコードを書かせるだけでは足りなかった。Development MCPを作った
- 第3回：AIに自分自身を再起動させたら止まった。Development Runnerを分離した
- 第4回：ChatGPTからPRを作り、安全にマージできるようにした
- 第5回：記事を書くだけでは自動化にならなかった。Publishing MCPを作った
- 第6回：MCPをいくつ作っても、AIは自律化しなかった。そこでLoop Engineを作った ← 今回
- 連載一覧
- 次回予定：AIが途中で止まっても、続きを再開できるようにした
コメント