TITLE

AIエージェントの中核「ループ」を作り込む――ループエンジニアリングとは何か

投稿日：2026.06.22

チャットボットとエージェントは、何が違うのか

「AI エージェントを導入したい」という相談が増えています。その一方で、すでに使っているチャットボットと何が違うのか、この差を整理しておく意味は大きいと感じています。

一言で言うと、差は「ループの有無」にあります。

チャットボットは 1 問 1 答の構造です。あなたが質問を送ると、AI がテキストを返す。それで完結します。AI は自分で次の行動を考えたり、外部のシステムに触ったり、結果を確かめたりはしません。

エージェントは違います。ひとつの指示を受け取ったあと、AI が自分で「次に何をすべきか」を判断しながら行動を繰り返します。ファイルを読む、コマンドを実行する、外部 API に問い合わせる。その結果をまた自分で確かめ、必要なら方向を修正して続ける。この繰り返しの仕組みが「エージェントループ(agentic loop / agent loop)」です。チャットボットは「答えを教えてくれる道具」で、エージェントは「仕事を進める仕組み」です。この差がループの有無によって生まれます。

本記事では、このループを実務で信頼できる形に作り込む工程を「ループエンジニアリング」と呼びます。業界で確立した正式名称ではありませんが、ループの設計・制御・検証を積み上げる工程を指す言葉として、以降この記事で使います。

エージェントループの基本構造

ループの 1 サイクルはおおよそこう動きます。指示を受け取った AI は、テキストを返すか、ツールを呼び出すかを判断します。ツールを呼んだ場合はその結果が戻ってきて、AI は再度判断します。ツール呼び出しを伴わない応答が出た時点で終了し、最終結果を返します。

エージェントループの基本サイクル(収集→行動→検証→繰り返し)を表す図

Claude Agent SDK はこのサイクルを「コンテキスト収集(gather context)→ 行動(take action)→ 検証(verify work)」と表現しています。実際にはこの 3 つが截然と分かれるのではなく、1 回の判断のなかで混在しながら進みます。

ここで重要なのが「ツール」の役割です。ツールが無ければ、AI はテキストを返すだけです。ツールが加わることで初めて、ファイルの読み書き、コマンドの実行、Web 情報の取得、外部サービスとの連携といった実際の行動が可能になります。エージェントの「賢さ」はモデルの性能だけで決まるのではなく、どんなツールを与え、どう組み合わせるかによっても大きく変わります。

ループの源流――ReAct という考え方

現在のエージェントループの設計思想の土台のひとつに、2022 年に発表された論文「ReAct: Synergizing Reasoning and Acting in Language Models」(Yao et al., arXiv:2210.03629)があります。

ReAct が提案したのは、推論(Reasoning)と行動(Acting)を交互に生成する手法です。AI が「考える→行動する→観察する」を繰り返すことで、計画を随時更新しながら例外にも対処できる。

行動によって外部の情報源(Wikipedia API 等)に接続できるため、モデルが知識を内部だけで完結させる場合に起きがちな幻覚(hallucination)や誤りの連鎖を抑えられる、というのが論文の主張です。論文内の実験では、質問応答タスク(HotpotQA・Fever)で Wikipedia API と組み合わせることで、Chain-of-Thought 単体よりも誤り伝播を減らす効果が示されています。ALFWorld・WebShop の行動タスクでは、模倣学習・強化学習に対して成功率で絶対値 34%・10% の改善を記録しています。

この「考える→行動する→観察する」の反復というアイデアが、現在のエージェントループの設計に引き継がれています。

「作り込み」の勘所――これがエンジニアリング

エージェントはループを自律的に回すことができます。それは強みである一方、「放っておくと止まらない」というリスクでもあります。実務で信頼できるエージェントを作るには、ループに明確な「設計」が必要です。

(a) 停止条件

ツール呼び出しが無い応答が出た時点で終了する、が基本の停止条件です。ゴールの定義が曖昧だと、AI はループを回し続けます。何をもって「完了」とするかを明確に定義することが出発点になります。

(b) ターン上限

Claude Agent SDK には max_turns というパラメータがあります。ツール使用のターン数に上限を設け、超えた場合は error_max_turns で停止します。意図しない無限ループへの基本的な防護です。

(c) コスト(予算)上限

max_budget_usd で API 呼び出しのコスト上限を設定できます。上限に達すると error_max_budget_usd で停止します。エージェントが複雑なタスクを処理する場合、想定外のコストが発生することがあります。予算上限はコスト管理の実務的な安全弁です。

(d) 各ステップでの検証

ループの途中で「前のステップの結果は正しいか」を確認するステップを入れることが重要です。エージェントは前のステップの出力をそのまま次の入力として受け取る構造になっているため、誤りがあっても検知されずに後のステップへ連鎖します。これは ReAct の論文でも指摘された誤り伝播の問題です。検証ステップを設計に組み込むことで、この連鎖を断ち切ります。

(e) コンテキストの肥大化への対処

ループを重ねるごとに、会話の文脈(コンテキスト)は蓄積されていきます。コンテキストが上限に近づくと、Claude Agent SDK は古い履歴を自動で要約する仕組み(compaction)で空きを作ります。メインのエージェントから小タスクをサブエージェントに切り出すことで、メインの文脈を軽く保つ設計も有効です。

ここまでをまとめると、エージェントの「作り込み」とは、停止条件・上限・検証・コンテキスト管理を組み合わせて「信頼できるループ」を設計することです。停止条件が未定義のままモデルを高性能に換えても、ループが収束しないという問題は解消されません。ループの設計は構造的な問題であり、モデル交換では埋まらない。この設計の質が実務上の成果を左右します。

フレームワークの現在地(2026年6月時点)

エージェントループを実装するためのフレームワークはいくつかあります。ただし、この分野の動きは速く、半年前の情報が既に古くなっている場合があります。以下は 2026 年 6 月時点の状況です。

**LangGraph(LangChain)**は、エージェントを「サイクルを持つ有向グラフ」として設計するフレームワークです。State(共有状態)、Nodes(状態を受け取り更新を返す関数)、Edges(条件分岐を含むルーティング)の 3 要素で構成します。線形チェーン(非循環)を扱う LCEL と異なり、循環を許容するため、ループ・リトライ・リフレクション・人間の介入(human-in-the-loop)を柔軟に組めます。暴走対策として recursion_limit(既定 25 ステップ)が組み込まれており、超えると例外を投げます。

OpenAI Agents SDK は、組み込みのエージェントループを持ちます。エージェントが実行され、指定した型の最終出力(ツール呼び出しを伴わないテキスト応答)が出たら終了。ハンドオフがあれば別のエージェントに処理を引き渡し、それ以外はツール呼び出しを実行して再ループする、という流れです。

Claude Agent SDK は Anthropic が提供するエージェント構築のための SDK です。前述のループ構造(コンテキスト収集→行動→検証)、max_turns、max_budget_usd、compaction の仕組みを実装する基盤となります。

Microsoft 系については、現時点でやや複雑な移行期にあります。AutoGen はマルチエージェントの会話(ConversableAgent)パターンを切り開いたフレームワークとして広く知られています。一方、2026 年 4 月 3 日、Microsoft は Semantic Kernel と AutoGen の双方の「直接の後継」として Microsoft Agent Framework 1.0 を Python / .NET 向けに公開しました。同じチームが開発し、production-ready と位置づけられています。AutoGen の原著者(Chi Wang, Qingyun Wu)が主導する独立コミュニティ版 AG2 が、会話型 ConversableAgent モデルを継続していますが、これは Microsoft のロードマップ外のガバナンスで維持されているものです。

AutoGen のオリジナルコードベースは Microsoft のロードマップ外になりました。新規プロジェクトでの採用は、現時点では推奨しません。新規に検討するなら、まず Microsoft Agent Framework 1.0 を確認するのが現時点での選択肢です。どのフレームワークを選ぶかはチームのスタック次第で変わります。Python を主軸にしているなら LangGraph か OpenAI Agents SDK が入りやすく、Microsoft スタック(.NET)なら Agent Framework 1.0 が自然な選択肢です。AutoGen 系のコードを持っているチームは、Migration Guide を確認して移行コストを見てから判断する順序が現実的です。

エージェントを始める前に決めておくこと

エージェントを業務に取り込む検討をしているなら、最初に問うべきは「どのモデルを使うか」ではありません。前のセクションで整理した停止条件・ターン上限・検証の設計が決まっていなければ、高性能なモデルを使っても動作は信頼できません。これらが欠けているエージェントは、コストをかけても結果が安定しない。

最初のスコープの絞り方も、成否を分けます。複数のツールを組み合わせた段階からスタートすると、ループが止まった時に原因がモデルの判断ミスなのか、ツールの応答形式の問題なのか、コンテキストの肥大化なのかを切り分けられません。ツール 1 本・ターン数を絞った状態で動作を確かめ、問題を再現できる最小構成を持っておく。これが拡張を速くします。

モデルを替えてもループの設計が甘ければ結果は変わりません。逆に言えば、停止条件と検証を地道に作り込んだエージェントは、高価なモデルを使った雑なシステムより安定して動きます。内製化の費用対効果は、最終的にここで決まります。冒頭で「ループエンジニアリング」と呼んだのは、この設計を積み上げる工程のことです。