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

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

概要

エージェントとチャットボットの根本的な違いは、モデルがより賢いことではなく、⁠ループが追加されている点にあります。チャットボットは「入力→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 を設定し、無限ループを防ぐ。
• 予算: タスク予算 / 累積トークンの監視を行い、上限に達したら優雅に終了する。
• Human-in-the-loop: 危険または不可逆なアクション（メール送信、データ削除、git push）は人間の承認を経る。各ツール実行前に承認プロセスを挿入する手動ループを使用するか、そのツールに「常に確認する」権限ポリシーを設定する。
• 権限/サンドボックス: bash などのツールのコマンドは信頼できないモデルの出力であるため、隔離された環境で実行し、実行可能ファイルのホワイトリストを使用し、タイムアウトを設定し、ログを記録する。ブラックリストだけでは不十分である。

なぜアクションを専用ツールとして昇格させ、すべてを bash に委ねないのでしょうか？ bash はホストに対して不透明なコマンド文字列しか提供しませんが、専用ツール（例: send_email）は型付きパラメータを持つフックを提供するため、ホストはインターセプト、確認、レンダリング、監査、並列スケジューリングを行うことができます。経験則として、⁠まずは bash で広範囲な対応を行い、検証/レンダリング/監査/並列処理が必要な場合にのみ、専用ツールとして昇格させる。

ワークフローかエージェントか？焦ってエージェントを使わないで

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

エージェントを導入する前に、以下の4つの関門を通過してください（いずれかでも「No」であれば、よりシンプルなレイヤーに戻ってください）。

ベストプラクティス

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

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

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

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

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

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

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

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

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

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

アーキテクチャと訓練

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

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

AgentWorldBench は、フォーマット/事実性/一貫性/現実味/品質の5つの次元でスコアリングし、環境ドメインごとに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: エージェントループ, think-act-observe, ツール使用, function calling, ツールschema, tool_result, stop_reason, end_turn, 並列ツール呼び出し, is_error, human-in-the-loop, ワークフロー vs エージェント, Managed Agents, エージェントツールセット, world model, Qwen-AgentWorld, AgentWorldBench, MoE