Agent Loopとは何か

Agent Loopは、AIエージェントが一回のmodel callで仕事を終えるのではなく、状況を見る→次の行動を決める→実行する→結果を見る→続けるか判断するという反復を行うcontrol structureです。

OpenAIは、agentのrunを、termination conditionへ達するまでLLMを繰り返し動かすloopとして説明しています。Anthropicも、agentが自分でprocessとtool useを方向づけ、environmentからのfeedbackを受けながら反復することを中核に置いています。Googleの用語集ではagentic loopを、Observe、Reason、Act、Feedbackの4段階として整理しています。^[1][2][3]

一周で何が起こるのか

典型的なAgent Loopは次のように動きます。

Observe

user goal、現在state、前回tool result、error、file contentなどを受け取ります。

Decide / Reason

次に何をするべきかをmodelが決めます。検索、file read、code execution、別agentへのdelegation、userへの質問、final answerなどです。

Act

選んだtoolやactionを実行します。

Feedback

toolのresultやenvironment changeをmodelへ戻します。

その結果を見て、loopをもう一周するか、終了するかを決めます。この「行動の結果を次の判断へ戻す」部分が重要です。単に同じpromptを繰り返すだけでは、environmentへadaptするagentにはなりません。

Termination Conditionが必要

Agent Loopは、放っておけば無限に続く可能性があります。そのため実装にはtermination conditionが必要です。

OpenAIのguideでは、final output、特定tool call、error、最大turn到達などをexit conditionの例として挙げています。Googleも、goal達成、resource limit、human-in-the-loopによるstopなどをtermination conditionとして示しています。

実際のagentでは、goal achievement、最大step、token/cost budget、tool errorの連続、安全rule、人間確認などを組み合わせます。

ReActとの関係

ReActは、reasoningとactingを交互に行う代表的なagent patternです。modelが状況を考え、tool actionを選び、そのresultをobserveして次へ進みます。

そのためReActはAgent Loopを実装する一つの考え方ですが、Agent Loopと完全な同義ではありません。Agent Loopはより一般的なcontrol structureで、planner-executor、manager-worker、verification loopなど多くの実装があります。

Chain-of-Thoughtとは別

Agent Loopを「AIの思考の連鎖」と混同することがありますが、別概念です。

Chain-of-Thought（CoT）は、問題を解く際の中間推論を段階的に扱うpromptingやreasoning methodを指します。一方Agent Loopは、modelの外側で、tool call、environment result、state update、terminationを含むexecution controlです。

Agentが内部推論をuserへ表示しなくても、Agent Loopは成立します。監査では、内部推論文より、どのtoolを呼んだか、何を入力したか、何が返ったか、どのstateが更新されたか、なぜ停止したか、といったobservable execution traceが重要です。

具体例：コード修正

「このtest failureを直して」とcoding agentへ依頼したとします。

1. error logを読む
2. related fileを検索する
3. 原因候補を判断する
4. codeをeditする
5. testを実行する
6. failureならlogを読む
7. 別の修正を行う
8. testが通れば終了する

これがAgent Loopです。一回目の修正が外れたとき、resultをobserveして次のactionを変えられる点が、単発code generationとの大きな違いです。

Agent Loopの失敗

loopは柔軟性を生みますが、失敗も反復させます。

• 同じtoolを何度も呼ぶ
• 誤った仮説へ固執する
• failure resultを正しくinterpretできない
• stateが大きくなりcontextが溢れる
• termination conditionを満たしても続ける
• goal達成前にcompleteと判断する

そのため、最大turn、重複検出、verification、checkpoint、human approvalなどが必要になります。

元の文脈で確認すること

• loopの一周は何を含むか
• どんなtool/actionがあるか
• feedbackはmodelへどう返るか
• stateはどこにsaveされるか
• termination conditionは何か
• 最大turnやbudgetはあるか
• failure recoveryはあるか
• human-in-the-loopはどこに入るか

Agent Loopはagentの「自律的な仕事」の中心構造ですが、それだけで正確性や安全性を保証しません。何を反復し、何を観察し、何をもって止めるかが実際の品質を決めます。

Agent Loopは「model call」と「environment step」を分けて考える

Agent Loopを理解するうえで、modelが考えるstepと、environmentへactionするstepを分けることが重要です。

modelが「検索toolを使う」と出力しても、その時点ではsearchは実行されていません。harnessやruntimeがtool callを受け取り、実際にsearchを実行し、resultをmodelへ返します。

つまりloopは、

model decision → runtime execution → environment result → next model decision

という複数componentの協調です。

この境界を理解すると、tool error、permission error、network errorなどがmodel reasoningとは別のfailureであることが分かります。

Loopのgranularity

一周の大きさは実装によって違います。

細かいloopでは、1 tool callごとにmodelへ戻ります。大きいloopでは、modelが複数action planを出し、runtimeがまとめて実行することもあります。

細かいloopはenvironment変化へ適応しやすい一方、model callが増えてcost/latencyが高くなります。大きいloopは効率的ですが、途中failureへ対応しにくくなります。

Agent Loopのdesignでは、このgranularityも重要です。

Loopとstate

loopが一周するたびに、何らかのstateが更新されます。

• conversation history
• completed task list
• retrieved documents
• file changes
• tool result
• budget usage
• error count

このstateが正しく管理されなければ、agentは同じactionを繰り返したり、すでに完了したtaskを忘れたりします。

long-running agentでは、context windowに全部詰め込むのではなく、external state storeやsummaryを使うことがあります。

Stopをmodelだけに任せる危険

modelが「もう終わった」と判断したら終了する設計は簡単ですが、false completionが起こる可能性があります。

そのためdeterministic terminationを組み合わせます。

coding agentならtest pass、data pipelineならschema validation、business processならrequired fields completedなど、外部criterionでcompleteを確認できます。

反対に、creative writingのように客観的なcomplete conditionがないtaskでは、model judgmentやuser confirmationが必要です。

task typeに応じてtermination設計を変える必要があります。

Budgetは安全装置でもある

max turn、max token、time limit、tool call limitはcost controlだけでなく、安全装置でもあります。

agentが同じsearchを繰り返す、retryを続ける、subagentを増殖させる、といったrunaway behaviorを止めるためです。

ただしlimitが低すぎると正常taskを途中で切ります。そのためtask complexityに応じたbudgetingが必要です。

Human-in-the-Loopはloopの一部になれる

agentがuncertainなとき、loopをpauseしてhumanへ質問し、そのanswerをstateへ入れて再開できます。

たとえば「このfileを削除してよいですか」とapprovalを求め、yesならactionし、noなら別planへ進む構成です。

HITLはagent loopを壊す外部処理ではなく、一つのobservation/actionとして設計できます。

RetryとReplanの違い

toolが一時的にtimeoutしただけなら、同じactionをretryすればよいかもしれません。

一方、searchで必要情報が見つからないなら、同じqueryを繰り返すのではなくreplanして別sourceや別queryを選ぶ必要があります。

Agent Loopのqualityは、failureをretryable errorとstrategy failureへ区別できるかでも変わります。

Traceからloopを読む

agent logを見るときは、次のsequenceを追います。

1. state
2. decision
3. action
4. result
5. state update
6. termination check

このtraceがあれば、failureがmodel decision、tool execution、state management、terminationのどこで起きたかを切り分けやすくなります。

「agentが間違えた」という一言では、改善方法は分かりません。

Agent Loopという用語は単純に見えますが、実際にはagent systemのtime axisを定義する重要な構造です。何を一stepとし、結果をどう戻し、stateをどう更新し、いつ止めるかが、cost、reliability、安全性を決めます。

関連するAI用語

• AIエージェント（G191）
• Autonomous Agent（G193）
• Agent Harness（G197）
• Agentic Workflow（G200）

注・出典

1. OpenAI, Unrolling the Codex agent loop ↩
2. OpenAI, From model to agent: Equipping the Responses API with a computer environment ↩
3. Google for Developers, Machine Learning Glossary: Agentic ↩

AI協働制作について

本記事は、著者が独自に設計した指示、参照資料、出典確認規則、著作権確認および監査工程を組み込んだChatGPT等の生成AIを、情報収集の補助、資料整理、構成検討、草稿作成、文章校正および監査補助に使用して制作しました。記事の対象範囲、情報源の採否、構成、解釈および最終表現は著者が判断し、最終稿を承認しています。著者は、本記事の正確性、独自性、引用、著作権処理および公開内容について責任を負います。制作工程の詳細は「AI協働制作方針」をご覧ください。