MCPでつくる自作AIサーバー #3｜Loop Engine――MCPをつなぐだけではAIエージェントは動き続けない

第1回：Development MCPでは、AIに安全に開発を任せるための制御面を紹介しました。

第2回：Knowledge MCPでは、Chatやモデルが変わってもプロジェクトの状態を再構成できる外部知識基盤について書きました。

これでAIは、必要なツールを使えます。過去の仕様や判断も読み直せます。

では、これだけで「仕事を任せられるAI」になるのか。

実際に使ってみると、まだ一つ大きな問題が残りました。

一回の指示が終わると、AIも止まる。

たとえば開発なら、コードを確認する。原因を考える。修正する。テストする。失敗したら原因を考え直す。もう一度修正する。成功したか評価する、という流れがあります。

一度のTool Callでは終わりません。

そこで作ったのが、今回紹介するLoop Engineです。

ただし、現在は少し重要な言い方をするようになっています。

Loop Engineは「すべての仕事をAIに自律実行させる司令塔」ではありません。

必要な仕事を、観測・判断・実行・評価のサイクルとして安全に繰り返すための実行基盤です。

この違いは、実際にシステムを作り続けてから分かりました。

Tool CallingとAgent Loopは同じではない

MCPを使えば、AIからさまざまなツールを呼べます。

たとえば、Gitの状態を読む。その結果が返る。これは非常に便利ですが、それだけなら基本的には、

Prompt → Tool → Result → Answer

です。

ところが現実の仕事には、

Observe → Plan → Act → Evaluate → Continue

という反復があります。

現在状態を観測し、次の行動を考え、実行し、結果を見て、成功したか評価する。駄目なら次の行動を変える。

この「結果を見て次を変える」という部分がないと、複雑な仕事は安定して進みません。

私がLoop Engineで作りたかったのは、単なる連続Tool Callingではなく、この反復を状態を持った仕事として扱う仕組みでした。

最初に必要だったのは「成功条件」だった

Loopを作るとき、意外に重要だったのが「何をするか」よりも、いつ終わるかです。

たとえば「このバグを直す」だけでは曖昧です。

そこでRunを開始するときは、ObjectiveだけでなくSuccess Criteriaを持たせます。

たとえば、原因が特定されている、修正がisolated workspaceに入っている、対象テストが通っている、既存テストを壊していない、PR-readyな状態になっている、といった条件です。

Loopは、この成功条件に対して現在の結果を評価します。

つまり、何回繰り返したかではなく、目的を達成したかで止めます。

10回Loopするよう設定してあっても、5回目で成功したなら終わるべきです。逆に10回やっても成功条件を満たさないなら、「10回実行したから成功」にはなりません。

Loop Engine自体が「考えるAI」ではない

ここも、作り始めた頃より整理された部分です。

Loop Engineという名前だけを見ると、内部にAIがいて全部考えているように見えるかもしれません。

しかし、私のシステムではReasoningとLoopの状態管理を分離しています。

現在の基本的な流れをかなり単純化すると、

Run ↓ Planning boundary ↓ AIが次のActionを考える ↓ Loop EngineがAuthorityや状態を確認 ↓ Capabilityを実行 ↓ Resultを保存 ↓ AIがSuccess Criteriaに対して評価 ↓ 成功 / 次のPlan / Stop

となります。

初期の構成では、Browser版ChatGPTがPlannerやEvaluatorの役割を担うHOST-drivenな方式を中心にしていました。

つまり、Loop EngineはAIモデルそのものというより、AIの判断を、壊れにくい実行サイクルとして保持する側です。

現在のLoop EngineにもHOST-driven、autonomous、hybridなど複数のexecution modeがありますが、モデルに判断させることと、Runの状態を保持することは別の責務として扱っています。

会話ではなくRunを状態の単位にする

これは第1回、第2回とも共通する設計思想です。

AIとのChatを仕事の状態そのものにしない。

Loop Engineでは、一つの仕事をRunとして保存します。さらにその過程で起きたことをEventとして残し、必要な地点ではCheckpointも持ちます。

そのため、Browserを閉じる、Chatが変わる、AIとの接続が一度切れる、途中で人間の承認待ちになる、といったことがあっても、仕事そのものまで消える必要はありません。

Run IDから現在状態を読み直し、continueしたり、一旦pauseして後からresumeしたりできます。失敗した仕事をcancelした場合も、それまでの履歴は残します。

このあたりから、AIとの会話ではなく「サーバー上の仕事」を扱っている感覚がかなり強くなりました。

無限ループをどう防ぐか

Loopを作ると、当然ながら次の危険が出てきます。

AIが「もう一度調べます」「別の方法を試します」「さらに確認します」を永遠に続けたらどうするのか。

そこで、Runには複数のBudgetを持たせています。

たとえば、最大iteration数、最大action数、最大failure数、最大wall time、model token上限、API cost上限です。

重要なのは、これらをAIの自主性だけに任せないことです。

AIが「もう少し調べれば分かりそう」と思っていても、システム側のbudgetを超えれば止められる。逆に、成功条件を早く満たしたならbudgetを使い切る必要はありません。

AIは次に何をすべきかを考える。システムは、どこまでやってよいかを決める。

この役割分離は、Loop Engineを作る上でかなり重要でした。

「実行したい」と「実行してよい」も別

Loopが次のActionを考えたとしても、そのActionが自動的に実行できるとは限りません。

ファイルを読む、テストを実行する、WordPressへ公開する、productionをdeployする、ではリスクがまったく違います。

そのため、Loop EngineではAuthorityを別に持っています。

AIは「次はproductionへdeployすべき」と判断できます。しかし、だからdeployできるとは限りません。必要ならapproval boundaryで止まります。

これもDevelopment MCPと同じで、Reasoning authorityとExecution authorityを分けるという考え方です。

Loopを自律化するほど、この境界はむしろ重要になります。

そして、一度大きな勘違いをした

Loop Engineを作り込んでいくと、非常に便利になります。

状態が残る。失敗から復旧できる。AIが結果を見て次を考えられる。承認も管理できる。

そうすると、自然にこう考え始めます。

「全部Loop Engineを通せばいいのでは？」

実際、Personal AI Platformの初期設計には、その方向へ寄った時期がありました。

しかし、これは違いました。

たとえば「現在のサーバー状態を見て」という依頼、既にやることが完全に決まっている単純な操作、一回だけのread-only query、人間が明示的に指定した既知のAction。

これらまで毎回、Run作成 → Plan → Action → Evaluation → Completionとする必要はありません。

むしろ遅くなります。状態も増えます。reasoningも余計に使います。実装も複雑になります。

Loopが強力だからといって、すべてをLoopにする必要はない。

これはかなり重要な設計変更でした。

Direct pathとLoop pathを分ける

現在は、仕事の性質によって経路を分ける方向へ整理しています。

Directが向いている仕事

• status確認
• 明示されたread
• 単純な既知Action
• 一回で完結する処理
• 意思決定がほぼ不要な操作

こうした仕事は直接Capabilityを呼べばよい。

Loopが向いている仕事

• 原因が最初から分からない
• 結果によって次のActionが変わる
• test → repair → retestが必要
• 外部結果を観測しながら進める
• 成功条件を満たすまで数回試す必要がある

こちらはLoopに向いています。

つまり、Direct = 既知の仕事を実行する、Loop = 不確実性を結果で減らしながら進めるという分け方です。

ParallelもLoopとは別だった

さらに開発を進めると、もう一つ分かりました。

LoopとParallelは対立するものではありません。

たとえば、ある問題について原因A、原因B、原因Cの調査を独立に実行できるなら、3つを並列化できます。

そのうち原因Aは一回のDirect調査で終わるかもしれません。原因Bは何度か試行錯誤するLoopになるかもしれません。原因Cは途中で不要になるかもしれません。

つまり、Parallelの中にDirectとLoopが混在することがあり得ます。

ここまで来ると、「Loop Engineが全部を管理する」という名前のイメージでは足りなくなってきました。

CLI化でLoop Engineの役割がはっきりした

現在、Personal AI PlatformではCodex CLI / App Serverをサーバーに常駐させる次世代構成を開発しています。

この設計を詰めているとき、Loop Engineの役割についてかなり重要な整理が入りました。

次世代構成では、Root Codexが、この仕事はDirectでよい、これはLoopが必要、これはParallelに分ける、Parallelの一部だけLoopにする、と仕事全体の実行戦略を考える側になります。

一方でLoop Engineや既存Control Planeは、Run、Event、Checkpoint、Authority、Budget、Scope、Recoveryといったdurableな制御を担います。

つまり、AI Orchestrator ≠ Loop Engineです。

Loop Engineは重要です。しかし「すべてをLoopで包む司令塔」ではありません。

必要な場所に差し込める反復実行プリミティブと考えた方が、現在の設計には合っています。

MCPにも長時間処理のTasksが入った

2026年7月28日のMCP仕様では、長時間処理を扱うTasksが @@INLINE0@@ extensionとして導入されています。Serverは@@INLINE1@@の最終結果の代わりに非同期task handleを返すことができ、clientは後から状態や結果を取得できます。

The 2026-07-28 MCP Specification

これはCI、batch job、人間の承認待ち、長時間APIなどに非常に有用です。

ただ、私がLoop Engineで必要としていたものとは少し階層が違います。

MCP Tasksは、「この長い処理をどう非同期に保持するか」を解決します。

Loop Engineは、「その結果を見たあと、次に何をするべきか」まで扱います。

したがって、Task handleがあることとAgent Loopがあることは同じではありません。

むしろ今後は、Loopの一つのActionがMCP Taskとして長時間実行されるという組み合わせも自然だと思います。

Implementation snapshot ― 2026年9月5日

この記事を公開する2026年9月5日時点で、Loop Engineには323 Runs / 7,598 Events / 121 Checkpointsが保存されています。

runtimeはLoop Engine 0.69.0-candidateです。

Runにはiteration、action、failure、wall time、API costなどのbudgetを設定でき、pause / resume / cancel / continueといったdurableな状態操作も持っています。Authority、API budget、recovery workerなども別レイヤーとして動いています。

一方、現在進行中のCodex CLI化では、Loop Engineを「全タスクのparent」から明確に外し、Direct / Loop / Parallelを組み合わせるDynamic Task Graphへ移行する設計になっています。

その意味で、この第3回は成功した仕組みの紹介だけではありません。

一度作ったLoopを、どこまで使わないかが分かるまでの記録でもあります。

Loop Engineを作って分かったこと

Loop Engineを作り始めたとき、私は「AIを止まらずに働かせる仕組み」が必要だと思っていました。

それ自体は間違っていませんでした。

ただ、実際に使い続けて分かったのは、もう少し違うことです。

重要なのは、AIを長く動かすことではない。必要なときだけ、結果を見ながら次の判断を繰り返せること。

そして、止まれることです。

成功したら止まる。budgetを超えたら止まる。Authorityがなければ止まる。前提が変わったら止まる。人間の判断が必要なら止まる。

そのうえで、必要なら後から再開できる。

「自律AI」という言葉からは、止まらず動き続けるシステムを想像しやすいですが、実運用ではむしろ正しく止まれることの方が重要なのかもしれません。

Development MCPで「作る」。

Knowledge MCPで「知り直す」。

Loop Engineで、必要な仕事だけを「続ける」。

そして、仕事が終われば成果物を現実世界へ出す必要があります。

次回は、このシリーズ最後のPublishing MCPです。

AIが文章を書けても、WordPressへの投稿、画像、予約、多言語化、SNS、二重投稿防止、部分失敗の復旧まで考えると、「公開」はまた別のシステムになりました。

---

「MCPでつくる自作AIサーバー」シリーズ

• #1 Development MCP――AIに「開発そのもの」を任せるために作った仕組み
• #2 Knowledge MCP――AIに「記憶」ではなく知識基盤を持たせる
• #3 Loop Engine――MCPをつなぐだけではAIエージェントは動き続けない（この記事）
• #4 Publishing MCP――ChatGPTからWordPressとSNSまで公開する仕組み（予定）

シリーズ一覧を見る