ループエンジニアリングとは何か・エージェントに「もう一周」させる設計

コンテキストエンジニアリングの記事では、AIに何を見せ続けるかという設計を見てきました。ここではさらに一歩進んで、AIエージェントに「1回で終わらせず、もう一周させる」という設計、ループエンジニアリングを扱います。Claude Codeの記事で見た「計画を立ててツールを実行し、結果を確認して修正する」という一連の動きは、AIエージェントが自分の中で勝手に回してくれる1つのループだと思うかもしれませんが、実際には性質の異なる2階層のループが存在します。

エージェントの中で回る「内側ループ」と、それを呼び出す「外側ループ」

AIエージェントのループというと、AI自身が試行錯誤を繰り返してくれる、たった1つの仕組みだと思うかもしれませんが、実務でエージェントを組み込んだシステムを作るときには、これを2階層に分けて考える必要があります。1つは「内側ループ」で、Claude Codeのようなエージェントが1つのセッションの中で自律的に行う、計画→ツール実行→結果確認→修正、という反復です。もう1つは「外側ループ」で、開発者側が組む、そのセッション全体が完了したかどうかを客観的に判定し、未完了ならもう一度エージェントを呼び出す、受発注のような仕組みです。内側ループはエージェント自身に任せればよい部分ですが、長時間かかるタスクを複数の呼び出しにまたがって継続させたり、複数の案件をキューとして順番に処理したりする問題は、外側ループを自分で設計しないと解決できません。実際に組んだ夜間バッチ処理のエージェントでは、1件のタスクが平均1〜2回のCONTINUEで完了することが多く、5回を超えて終わらないケースだけを「要確認」として人間に回す、という運用にしていました。

# 外側ループの骨格のイメージ(実際に組んだことのあるパターン)
1. プロンプトの末尾で完了報告の形式を義務付ける:
   「作業が終わったら『STATUS: DONE』、続きがあるなら
    『STATUS: CONTINUE <残作業の要約>』を最後の行に出力して」

2. エージェントをプロセスとして起動し、応答を受け取る

3. 応答末尾のSTATUS行を正規表現で判定する:
   /STATUS:\s*(DONE|CONTINUE)\s*(.*)/i
   ・DONE     → 完了として次の案件へ
   ・CONTINUE → 残作業を添えて、同じセッションを維持したまま再度呼び出す
   ・マーカー無し → 安全側に倒してCONTINUE扱いにする(モデルが指示を忘れて
                  STATUS行を出し忘れただけの可能性があり、未完了を完了と
                  誤認する方が危険なため。無限に呼び出しが続かないための
                  歯止めは、後述の最大反復回数の上限で確保する)

🎯 読み解きポイント：現場の職人の腕とは別に、現場監督が全体の進行を管理する

内側ループは、現場で実際に手を動かす職人の腕そのものです。1つの作業の中でどう工具を使い、どう手直しするかは職人自身の裁量に任せます。外側ループは、その現場を俯瞰する現場監督の仕事です。監督は職人の手元に口を出しませんが、「この作業は今日中に終わるか」「終わらないなら明日も同じ職人に続きを頼むか」「次はどの現場に回すか」を判断します。エージェントの腕(内側ループ)が優れていても、現場監督(外側ループ)がいなければ、複数の現場をまたぐ長期の管理はできません。

完了判定を「自己申告」だけに任せると、偽陽性が起きる

エージェントが「完了しました」と報告してきたら、そのまま素直に信じて次に進めばよいだろうと思うかもしれませんが、自己申告だけに頼った完了判定には偽陽性のリスクがあります。実際にはテストが通っていないのに「STATUS: DONE」と出力してしまう、といった食い違いが起こり得るためです。重要な作業ほど、自己申告に加えてテストの実行結果のような客観的な指標を組み合わせて完了を判定する設計が安全です。また、いきなり実作業に入らせず、要件をまとめた段階で一度立ち止まらせ、人間の承認を待ってから先に進める「確認ゲート」を同じ仕組みで作ることもできます。

# 客観指標を組み合わせた完了判定のイメージ
応答: 「修正が完了しました。STATUS: DONE」

  → この自己申告だけでは信用しない
  → tests/ 配下のテストを実行し、実際に全部パスしているか確認
  → パスしていれば本当に完了、パスしていなければCONTINUE扱いで差し戻す

# 人間の承認を待つ確認ゲートのイメージ
応答: 「要件をまとめました。実装はまだ行っていません。STATUS: CONFIRM」

  → 外側ループはここで一旦停止し、人間に要件を提示する
  → 承認が得られたら、その内容を踏まえて実作業を再開させる

🎯 読み解きポイント：見積もりも取らずに工事を始める業者と、先に見積書を出す業者

いきなり工事を始めてしまう業者よりも、先に見積書を出して依頼主の承認を待ってから着手する業者の方が、後々のトラブルが少なくなります。確認ゲートは、この「先に見積もりを提示する」という段取りをエージェントの外側ループに組み込んだものです。承認を待っている間はエージェント自体を止めておけるので、確認待ちの時間だけ無駄にトークンを消費することもありません。

よくあるはまりポイント：最大反復回数を決めておかないと、堂々巡りでコストが膨らむ

エージェントは十分に賢いのだから、終わらない作業を延々と繰り返し続けることはないだろうと思うかもしれませんが、実際には堂々巡りに陥ることがあります。ある修正を加えては元に戻し、また別の修正を加えては元に戻す、というサイクルを繰り返し、STATUSがいつまでもCONTINUEのまま完了しない、という状況です。外側ループには必ず最大反復回数の上限を設け、上限に達したら「要確認」の状態として人間にエスカレーションする設計を組み込んでおく必要があります。この上限が無いと、堂々巡りに気づかないまま呼び出しが重なり、想定外にコストがかさみ続けます。

あわせて知っておきたい用語

内側ループ / 外側ループ: 内側ループはエージェント自身が1セッション内で行う計画・実行・確認の反復。外側ループは開発者が組む、セッション全体の完了判定と再呼び出しの仕組み
ヒューマンインザループ: 自動化された処理の途中に人間の確認・承認を挟む設計。ループの仕組みを流用して「確認ゲート」として実装できる
最大反復回数: 外側ループが同じセッションを再呼び出しできる上限。堂々巡りによる無制限のコスト増加を防ぐための安全装置

💡 ワンポイントアドバイス：完了判定は自己申告+客観指標の組み合わせ、反復には必ず上限を

外側ループを設計するときは、STATUSマーカーのような自己申告だけに頼らず、テストの実行結果など客観的に確認できる指標を1つ以上組み合わせてください。あわせて最大反復回数(例えば3回)を必ず設定し、上限に達したら自動で止めて人間に判断を委ねる設計にしておくと、堂々巡りによる想定外のコスト増加を防げます。

ループの設計という視点が掴めたら、複数の分岐を扱う「グラフエンジニアリング」も見てみると理解が深まります。(シリーズ一覧・プロンプトエンジニアリング・コンテキストエンジニアリング・グラフエンジニアリング)