Skip to Content
Docs02. 設計ループエンジニアリング
上級agent-loopharnessplanning更新: 2026-10-04この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

ループエンジニアリング

この記事の目的

Agent ループLLM が「観測 → 思考 → 行動」のサイクルを繰り返し、完了・失敗・上限のいずれかの停止条件まで自律的に処理を続ける制御構造。の制御 — いつ考えさせ、いつ行動させ、いつ立ち止まらせ、いつ止めるか — を設計対象として扱い、迷走せず・止まりすぎず・予算内で収束するループを設計できるようになります。Agent ループが示す「1 周で何が起きるか」の先にある、ループの型・停止条件の詳解・堂々巡りへの介入・バックトラック・入れ子までを扱います。

対象読者

  • 最小の Agent ループは動かせるが、長いタスクで迷走・空回り・早すぎる打ち切りに悩んでいるエンジニア
  • 自律度の高い Agent を、暴走させず予算内で完了させる制御を設計したいエンジニア

前提知識

本文

概要: ループは「空間」ではなく「時間」の設計

ハーネスエンジニアリングが「モデルの外側に何を置くか」という空間的な構成だとすれば、ループエンジニアリングはその時間軸 — いつ考え・いつ動き・いつ止まるか — の設計です。Agent ループは 1 周の構造と最低限の停止条件を扱いました。本記事は、そのループを長く回しても破綻させない制御に踏み込みます。

対象正本本記事
ループ 1 周の構造・基本の停止条件Agent ループ—
計画・推論のパターンプランニングと推論—
エラー分類とリトライの一般論エラー処理・リトライ・フォールバック設計—
中断・再開の永続化非同期・長時間タスクの設計(耐久実行)—
複数 Agent の構成オーケストレーションパターン—
暴走時の運用対応インシデント対応—
ループの制御設計本記事型・停止条件の詳解・再計画・迷走介入・バックトラック・入れ子

ループの型を選ぶ

すべてを 1 種類の自由ループで回す必要はありません。タスクの性質に応じて、制御の強さが異なる 3 つの型から選び、組み合わせます。自律性スペクトラム(AI Agent とは何か)とおおむね対応します。

ループエンジニアリング: ループの型を選ぶの図ループエンジニアリング: ループの型を選ぶの図
ループエンジニアリング: ループの型を選ぶの図
図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

ループエンジニアリング: ループの型を選ぶの図ループエンジニアリング: ループの型を選ぶの図
型向く場面代償
自由ループ探索的・手順が事前に決まらない迷走・堂々巡りのリスクが最も高い
フェーズ制(計画 → 実行 → 検証)中〜長タスクで、段階に分けられるフェーズ境界の設計が要る
状態機械(遷移をコード固定)手順が既知・失敗が高くつく柔軟性を失う(想定外に弱い)

指針は、必要な最小限の自由度だけをモデルに与えることです。手順が決まっている工程まで自由ループにすると、迷走の余地を無駄に広げます。逆に探索が要る工程を状態機械で縛ると、モデルの強みを殺します。多くの実務は「大枠はフェーズ制、各フェーズ内は自由ループ」の混成に落ち着きます。

停止条件の設計

Agent ループで挙げた 4 系統(正常完了・上限・エラー・人間の介入)を、設計の粒度まで詳解します。要点は、「完了」の判定をモデルの自己申告だけに委ねないことです。

再計画のリズム

計画は立てた瞬間から陳腐化します。どのタイミングで見直すかが、迷走と硬直の分かれ目です。

  • 毎ステップ再計画: 柔軟だが、方針がふらつき往復が増える。短く探索的なタスク向き
  • 節目で再計画: フェーズ完了・大きな失敗・新情報の獲得時にだけ計画を見直す。長いタスクで安定します
  • 計画の陳腐化を検知する: 「計画の前提がまだ成り立っているか」を節目で確認します。前提が崩れたのに古い計画を実行し続けるのが、長時間タスクの典型的な失敗です

原則は、行動のリズムより粗い頻度で計画を見直すことです。毎周方針を疑うと収束しません。計画の作り方そのものは プランニングと推論 が正本です。

迷走の検知と介入

長いループの最大の敵は、同じところを回り続ける堂々巡りです。放置するとコストだけが増えて完了しません。検知と介入をループに組み込みます。

  • 検知シグナル: 同一ツール・同一引数の反復、成果物が変化しないままのステップ増加、同じエラーの繰り返し、進捗指標(残タスク・テスト通過数)の停滞。これらはコード側で機械的に監視できます(可観測性とトレーシング)
  • 介入の段階: 軽いものから、(1) ヒント注入(「同じ方法を 3 回試している。別の手段を検討せよ」)、(2) 仕切り直し(汚染したコンテキストを外部化状態から作り直す。コンテキストの圧縮と隔離)、(3) エスカレーション(人間へ引き継ぐ。Human-in-the-Loop 設計)
  • 早めに介入する: 堂々巡りは時間とともに悪化します。「3 回同じ失敗を繰り返したら介入」のような閾値を先に決めておきます

エラーそのものの分類と回復(リトライするか・フォールバックするか)は エラー処理・リトライ・フォールバック設計 が、本番で暴走が起きた際の運用対応は インシデント対応 が正本です。本記事は「ループ内で迷走をどう検知し介入するか」の制御設計を扱います。

バックトラックとやり直し

前進だけがループではありません。失敗を認めて戻る設計が、行き詰まりからの回復を可能にします。

入れ子と分割

長いタスクを 1 本の巨大なループで回すと、コンテキストが肥大し迷走しやすくなります。ループを入れ子にして分割します。

コードで制御するか、プロンプトで促すか

ループ制御にも ハーネスエンジニアリングの原則 — 「指示はお願いにすぎない」— がそのまま効きます。

  • コードで固定すべき制御: 上限(ステップ・コスト・時間)、危険な操作の前の停止、堂々巡りの検知と強制介入。これらは破られては困るので、プロンプトの指示ではなくループのコードに書きます
  • プロンプトで促す制御: 「行き詰まったら別の手段を検討する」「節目で計画を見直す」といった、柔らかい振る舞いの誘導。効くこともありますが、確実ではありません
  • 併用が現実的: 柔らかい誘導をプロンプトで与えつつ、破綻を防ぐ硬い上限はコードで担保する二重化が実務の定石です

実務での注意点

アンチパターン

  • 完了をモデルの自己申告だけで判定する → 「できました」を鵜呑みにして、未完成・誤った成果物を完了扱いする → 検証器、別呼び出しの judge、人の確認を順に検討し、裏付けがなければ未検証と明記する
  • 予算を 1 次元でしか持たない → ステップ上限は守られても、トークンや時間が別次元で暴走する → ステップ・トークン・時間・コストを別々に上限化する
  • 迷走を検知せず自由ループを回し続ける → 同じ失敗を繰り返してコストだけ増え、完了しない → 反復・停滞のシグナルを機械的に監視し、閾値で介入する
  • 毎ステップ計画を疑う → 方針がふらついて収束しない → 再計画は行動より粗いリズム(節目)で行う
  • 戻る設計がない → 行き詰まっても前進し続け、傷を深くする → チェックポイントを置き、失敗した経路の記録を残してバックトラックする
  • 1 本の巨大ループにすべてを詰める → コンテキストが肥大し迷走しやすくなる → フェーズ分割と子ループで入れ子にする

チェックリスト

  • 完了基準をプロンプトだけの保証にせず、裏付け手段または「未検証の完了」の扱いがある
  • バックトラック前に外部副作用を列挙し、補償・冪等キー・人への引き継ぎを決めた
  • タスクに対してループの型(自由 / フェーズ制 / 状態機械)を意図して選んでいる
  • 完了判定を自己申告だけに委ねず、検証器・別呼び出しの judge・人の確認で裏付け、なければ未検証と明記している
  • ステップ・トークン・時間・コストの上限を別々に設定している
  • 上限超過時に途中経過と未完了理由を構造化して返す
  • 堂々巡り(反復・停滞)の検知シグナルと、段階的な介入を用意している
  • 再計画のリズムが行動より粗く、計画の前提を節目で確認している
  • チェックポイントとバックトラック(失敗経路の記録を含む)を設計している
  • 破られては困る制御(上限・危険操作の停止)がコード側にある

関連トピック

参考資料

TODO・未確認事項

なし

ハーネスエンジニアリング非同期・長時間タスクの設計(耐久実行)