エージェントのループとツール使用

エージェントとチャットボットの本質的な違いは、モデルがより賢いことではなく、1つ追加されたループ（モデルの意思決定→ホストの実行→結果の観察→再意思決定）にあります。モデル自体は何も実行せず、セキュリティ境界、権限、監査はすべてホスト側で処理されます。

概要

エージェントとチャットボットの根本的な違いは、モデルがより賢いことではなく、⁠ループが追加されている点にあります。チャットボットは「入力→1回の出力」ですが、エージェントは「入力→意思決定→ツール呼び出し→結果の観察→再意思決定→…→完了」というプロセスを踏みます。モデル自体は変わっていません。重要なのは、ホスト（harness）がモデルの周りに観察結果を繰り返しフィードバックするループを設けていることです。この仕組みを理解すれば、Claude Code、Cursor、そして各種「AI エージェント」の裏側にある共通の骨格が見えてきます。

この概念の歴史は長くありません。2023年に function calling / tool use が登場し、モデルがテキストだけでなく構造化されたツール呼び出しを生成できるようになりました。ReAct などの研究は「推論」と「行動」を交差させる手法を示し、2024年から2026年にかけて Anthropic はこのループを段階的に製品化しました。Claude Code はそのコマンドライン版であり、Managed Agents はこのループ全体をサーバー側でホスティングします。特定のフレームワークを覚えるよりも、このループを理解することが重要です。

直感に反するが重要な事実があります：⁠モデル自体は決して実行しません⁠。ファイルを読んだり、コマンドを実行したり、API を呼び出したりはしません。モデルが行うのは「read_file を呼び出したい、引数は {path: ...} です」という「発言」だけです。実際に実行するのはホストプログラムです。モデルは脳であり、ホストは手足です。セキュリティ境界、権限、監査はすべてホスト側で処理されます。この点が、その後のすべてのエンジニアリング上のトレードオフを決定づけます。

核心: think → act → observe ループ

flowchart TD
    M["モデルの意思決定 think<br/>構造化された tool_use を生成"]
    H["ホストがツールを実行 act"]
    O["結果をモデルにフィードバック observe<br/>tool_result"]
    E["最終回答"]
    M -->|tool_use| H
    H -->|tool_result| O
    O --> M
    M -->|"stop_reason = end_turn (ツール呼び出しなし)"| E

1回の API 呼び出しで起こること:

1. ホストはモデルに対してツールの定義⁠(schema)と現在の会話履歴を送信します。
2. モデルは応答を返します。ツールを使用したい場合、応答には tool_use ブロックが含まれ、stop_reason: "tool_use" となります。
3. ホストはそのツールを実行し、出力を tool_result として包み（対応する tool_use_id を付与して）messages に戻します。
4. モデルに再度リクエストを送信します。stop_reason: "end_turn"（モデルがツールを必要としなくなる）までこれを繰り返します。

停止条件は stop_reason によって与えられ、ホストはこれに応じて分岐処理を行う必要があります。

ツールはエージェントが世界とつながる API

ツールの定義 = 名前 + 説明 + JSON schema:

{
  "name": "get_weather",
  "description": "Get current weather for a location. 現在の天気を尋ねられた場合に呼び出す。",
  "input_schema": {
    "type": "object",
    "properties": { "location": {"type": "string", "description": "都市名、例: 北京"} },
    "required": ["location"]
  }
}

ツールの名前、説明、schema は想像以上に重要です。これらがエージェントが世界を理解するための唯一のインターフェースとなります。モデルは説明に基づいていつ呼び出すかを判断するため、説明には「何をするか」だけでなく、「どのような状況で使用するべきか」を明確に記載する必要があります。最近の Opus モデルはツールに対してより「抑制的」になっており、説明にトリガー条件を明記することで、適切なタイミングでの呼び出し成功率が大幅に向上します。

get_weather は最小限の例に過ぎません。実際のエージェントのツールは多岐にわたりますが、骨格は同じです（名前 + トリガー条件の説明 + 型付けされた schema）:

Claude Code 自体が read/write/edit/bash/grep/glob という一連のツールで構成されています。このセッションで接続されている context7 や code-review-graph(MCP) も、モデルからは同様の形態で表示されます。⁠ドメインは千差万別ですが、モデルが目にするのは「型付きパラメータを持つフック」に過ぎません。これが、アクションを専用ツールとして昇格させる価値です。

実際に触るとすぐに陥りやすい原則:

• エラーは観察としてフィードバックし、例外としてクラッシュさせない。 ツール実行に失敗した場合は、tool_result を返し、is_error: true を設定し、人間がわかるエラーメッセージ（「都市 xyz は存在しません。有効な都市名を入力してください」）を返します。モデルはこれを読み取り、経路を修正します。これにより、ループ全体が停止するのを防ぎます。
• 並列ツール呼び出し: 1つの assistant メッセージに複数の tool_use が含まれる場合があります。並列実行後、⁠すべての tool_result を1つの user メッセージにまとめて返す必要があります。複数のメッセージに分割すると、モデルが並列処理を行わないように学習させてしまうことになります。
• 少而精: ツールが多すぎるとモデルが間違った選択をする可能性があります。ツールセットが大きい場合は、一度にすべてを詰め込むのではなく、tool search を使用して必要に応じてロードしてください（これにより、プロンプトキャッシュの保護にもつながります。コンテキストエンジニアリング を参照）。

ループの制御: 暴走させない

裸のループはすぐに問題が発生します。本番環境では、以下のゲートを追加する必要があります。

• 反復上限: max_iterations を設定し、無限ループを防ぐ。
• 予算: タスク予算 / トークンの累積を監視し、上限に達したら優雅に終了する。
• ヒューマン・イン・ザ・ループ: 危険または不可逆なアクション（メール送信、データ削除、git push）は人間の確認を経る。各ツール実行前に承認プロセスを挿入する手動ループを使用するか、そのツールに対して「常に確認する」権限ポリシーを設定する。
• 権限/サンドボックス: bash などのツールのコマンドは信頼できないモデルの出力であるため、隔離された環境で実行し、実行可能ファイルのホワイトリストを使用し、タイムアウトを設定し、ログを記録する。ブラックリストだけでは不十分である。

なぜアクションを専用ツールとして昇格させるのか、bash だけを使わないのか？ bash はホストに対して非透過的なコマンド文字列しか提供しませんが、専用ツール（例: send_email）は型付きパラメータを持つフックを提供するため、ホストはインターセプト、確認、レンダリング、監査、並列スケジューリングを行うことができます。経験則として：⁠まずは bash で網羅性を確保し、制御/レンダリング/監査/並列処理が必要な場合に専用ツールとして昇格させる。

ワークフローかエージェントか？ エージェントを急いで導入するな

すべてのタスクにエージェントが必要というわけではありません。固定されており、完全に事前に記述可能なプロセスには、⁠決定論的なパイプライン（ワークフロー）⁠を使用してください。コードで各ステップを制御し、必要に応じてモデルを1回だけ呼び出す方が、エージェントよりも安定しており、コストが安く、制御しやすいです。

エージェントを導入する前に、以下の4つの関門を通過してください（いずれかに「いいえ」がある場合は、より単純な層に戻ってください）。

ベストプラクティス

• モデルは実行せず、ホストが実行することを忘れない。 セキュリティ境界、権限、監査はすべてホスト側で処理されます。この点がその後のすべてのエンジニアリング上のトレードオフを決定づけます（セキュリティと保護 を参照）。
• ツールの説明には「何をするか」だけでなく「いつ使うか」を明確に記載する。 モデルは説明に基づいて呼び出しのタイミングを判断するため、トリガー条件を明記することで、適切なタイミングでの呼び出し成功率が大幅に向上します。
• エラーは観察としてフィードバックし、例外としてクラッシュさせない。 失敗した場合は tool_result + is_error: true + 人間がわかるメッセージを返し、モデルが経路を修正できるようにする。
• 並列結果は1つの user メッセージにまとめて返す。 複数のメッセージに分割すると、モデルが並列処理を行わないように学習させてしまうことになります。
• 少而精。ツールが多い場合は tool search を使用して必要に応じてロードする。 間違った選択を防ぎ、プロンプトキャッシュ を保護する。
• 裸のループにはゲートを設ける。 反復上限、トークン予算、危険なアクションへのヒューマン・イン・ザ・ループ、bash のサンドボックスホワイトリスト。
• まずは bash で網羅性を確保し、制御/レンダリング/監査/並列処理が必要な場合に専用ツールとして昇格させる。
• ワークフローで記述できる場合はエージェントを導入しない。 複雑さ/価値/実現可能性/エラーのコストの4つの関門を通過してから着手する。

トレードオフと失敗パターン

• 無限ループ: モデルが同じツールを繰り返し呼び出して収束しない → 反復上限を設定し、tool_result でより明確な次のステップを提示する。
• 幻覚的なツール呼び出し: 存在しないツールを呼び出すか、パラメータを捏造する → 厳格な schema (strict: true)、明確な説明、tool_choice による制約を適用する。
• 観察によるコンテキストの溢れ: 特定のツール出力が数万行に及び、ウィンドウを埋め尽くす → ホスト側でツール出力を切り捨て/要約するか、context editing を使用して古い結果をクリーンアップする（コンテキストエンジニアリング を参照）。

これは日常で使われているループだ

Claude Code はまさにこのループです。read/write/edit/bash/grep/glob などをツールとして扱い、モデルが意思決定し、Claude Code が実行し、結果をフィードバックします。OMC (oh-my-claudecode) はこのループの上にマルチエージェントオーケストレーションを実装しています。探索、計画、実行、レビューを異なるエージェントに分散させるのです。ループを理解すれば、これらの上位フレームワークは単なる「ループ + スケジューリング戦略」に過ぎないことがわかります。

もう一つの形態は Managed Agents です。Anthropic がループ全体をホスティングし、各セッションに対してワークスペースとしてコンテナを提供します（bash/ファイル/コードはコンテナ内で実行され、ループは Anthropic のオーケストレーション層で実行されます）。その鉄則は以下の通りです。

各実行のたびに agents.create() を行わないでください（孤児エージェントが蓄積されます）。Agent はバージョン付きの永続オブジェクトであり、1回作成して繰り返し参照します。

最前線: エージェントを訓練するための「シミュレータ」 —— Qwen-AgentWorld

上記で説明したエージェントは、⁠リアルな環境でループを実行します。実際に API を呼び出し、実際にコマンドを実行します。一方、ある最先端の研究は逆の問いを投げかけています。モデルを訓練して、その環境を扮演させることはできないだろうか？ エージェントモデルと相互作用させることで、あたかもリアルな環境と対話しているかのように振る舞わせることはできないだろうか？

アリババの Qwen-AgentWorld-35B-A3B はこのことを実現しています。注意してください：⁠これはエージェントではありません。 ツールを呼び出したり、コマンドを実行したり、最終的な回答を生成したりしません。これは world model（世界モデル）です。環境の役割を扮演し、エージェントのアクションを受け取り、環境がどのような観察結果を返すべきかを予測します。役割の例えをすると、強化学習における gym のシミュレータのようなものです。シミュレータ内で訓練されるポリシーではありません。

アーキテクチャと訓練

Qwen3.5-35B-A3B-Base をベースにした MoE 構造: 総パラメータ数は35B、専門家は256個、トークンごとにルーティングされた8個と共有の1個がアクティブになります（アクティブパラメータ数は約3B）。40層で、混合アテンションを採用しています。10個の繰り返しブロックがあり、各ブロックは 3×(Gated DeltaNet→MoE)→1×(Gated Attention→MoE) で構成されています。Gated DeltaNet は線形アテンションの一種で、長系列アテンションの O(n²) をほぼ線形にまで削減し、256K のコンテキストをサポートします。

3段階の訓練により、⁠ネイティブな world model となっています（汎用 LLM に後付けされた能力ではなく、事前学習の段階から環境モデリングを目的としています）。CPT（環境知識の注入）→ SFT（next-state 予測の推論を活性化）→ RL/GSPO（シミュレーションの忠実度を向上）。

7つの環境をシミュレート

MCP (tool calling)、Search、Terminal、ソフトウェアエンジニアリング (SWE)、Android、Web、OS をカバー。テキストと GUI の相互作用環境が1つのモデルで統一されています。エージェントがアクションを投げかけると、<think> ブロック内で環境の状態遷移を推論し、観察結果を応答として出力します。これこそが、エージェントのループにおける「observe（観察）」の段階に相当します。

なぜ価値があるのか

エージェントの訓練と評価は「環境」でつまずきます。リアルな環境は遅く、高価で、副作用があり、再現不可能です。world model は言語を使ってこれらの環境を制御可能にシミュレートできます。⁠リアルなシナリオを再現できるだけでなく、リアルな環境には存在しないシナリオ（制御可能な摂動、架空の世界）を構築することも可能です。これにより、エージェントはリアルな環境では実験不可能な条件下で、試行錯誤、RL の実行、評価を行うことができます。また、ゼロショット汎化能力も示しており、訓練中に未見の環境（OpenClaw など）に対しても意味のあるシミュレーションを提供できます。

なぜ 3B のアクティブパラメータで world model は可能だが、エージェントには向かないのか

AgentWorld が行っているのは単ステップの next-state 予測です。アクションを受け取り、環境がどのような観察結果を返すかを予測します。これは単ステップの推論であり、「私は1番目に何をしたか、2番目に何をするべきか」という直列的な連鎖を頭の中で維持する必要はありません。一方、エージェントのツール呼び出しは多ステップの直列推論です。各ステップの意思決定は、前のステップの結果と初期の意図に依存します。3B のアクティブパラメータの単ステップ推論能力は next-state 予測には十分ですが、意図の一貫性を維持する必要がある多ステップのエージェントループを支えるには不十分です。詳細はモデルアーキテクチャのアクティブパラメータと推論深度の議論を参照してください。

world model の良し悪しをどう測るか

AgentWorldBench は、5つの次元（Format / Factuality / Consistency / Realism / Quality）で環境ドメインごとにスコアを量化し、0〜100点で評価します。全体の平均は 56.39 です。参照値: GPT-5.4 は 58.25、Claude Opus 4.8 は 56.59。アクティブパラメータ数がわずか3Bの言語用 world model が、シミュレーションの忠実度において最強の汎用モデルとほぼ同等であり、同サイズのベースラインである Qwen3.5-35B-A3B (47.73) を大幅に上回っています。これは、world model のアプローチにはデータセンタークラスのコンピュートリソースが必要ないことを意味します。コンシューマーグレードのハードウェアで、まともなエージェントのシミュレーション環境を実行できるということです。

参考

• Anthropic 公式ドキュメント⁠: Tool Use Overview、Building Effective Agents、Managed Agents (platform.claude.com)
• 研究⁠: "ReAct: Synergizing Reasoning and Acting in Language Models" (Yao et al., 2022)
• 最先端モデル⁠: Qwen-AgentWorld-35B-A3B

Keywords: agent loop, think-act-observe, tool use, function calling, tool schema, tool_result, stop_reason, end_turn, parallel tool use, is_error, human-in-the-loop, workflow vs agent, Managed Agents, agent toolset, world model, Qwen-AgentWorld, AgentWorldBench, MoE