LLMエージェントとツール使用

エージェントとは：LLMを行動の制御ループに埋め込む

素の大規模言語モデル（LLM）は、文脈を受け取って次トークンの確率分布を出すだけの関数です。外界を観測することも、計算を実行することも、状態を持ち越すこともできません。LLMエージェントとは、このモデルを 「観測 → 推論 → 行動」を繰り返す制御ループ の中核に据え、外部ツールを呼ばせて環境に働きかけさせる仕組みの総称です。

決定的に重要なのは、モデル自身はツールを実行しないという点です。モデルは「この関数をこの引数で呼べ」という構造化された指示をテキストとして生成するだけで、実際にAPIを叩き結果を文脈に書き戻すのは、モデルの外側にいる**オーケストレータ（制御コード）**です。この分業を取り違えると設計を誤ります。

オーケストレータのループ（擬似コード）:
  state = 初期プロンプト + ツール定義
  while ステップ数 < 上限:
      out = LLM(state)                 # モデルは行動指示 or 最終回答を生成
      if out が最終回答:
          return out
      call    = parse_tool_call(out)   # 関数名と引数を抽出
      result  = execute(call)          # ← 実行するのはオーケストレータ
      state  += out + format(result)   # 観測を文脈へ書き戻す
  return 打ち切り                       # 上限到達で強制終了

このループがエージェントの実体です。モデルは各反復で「まだ情報が足りない→ツールを呼ぶ」か「十分揃った→回答する」かを判断し、オーケストレータが実行と状態管理を担います。

関数呼び出し：スキーマで行動空間を定義する

エージェントの土台が関数呼び出し（function calling / tool use）です。仕組みは三段構えです。第一に、利用可能なツールをJSONスキーマ（関数名・説明・引数の型と必須性）としてモデルの文脈に与えます。第二に、モデルはユーザー要求を読み、必要なら関数名と引数を埋めた構造化出力を生成します。第三に、オーケストレータがそれを実行し、戻り値を文脈へ返して次の生成へ回します。

{
  "name": "get_weather",
  "description": "指定都市の現在の天気を返す",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "都市名" },
      "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
    },
    "required": ["city"]
  }
}

モデルはこのスキーマに沿って get_weather(city="東京", unit="celsius") に相当するJSONを吐きます。なぜ機能するのかは学習に由来します。モデルは事後学習で、スキーマ提示に対し妥当な呼び出しを生成するよう調整（ファインチューニング）されており、スキーマの enum や required が出力分布を制約します。構造の逸脱を防ぐには、生成側で文法制約デコード（値域をトークン単位で強制する手法）を併用します。呼び出しの根拠となる要求理解は インコンテキスト学習はなぜ起きるのか の枠組みで、文脈内の指示とスキーマから振る舞いが決まります。

ReAct：推論と行動を交互に積む

ReAct（Reasoning + Acting）は、エージェントの推論と行動を一つの文脈で交互に織り込む枠組みです。各ステップでモデルは、次の三要素を順に生成・受領します。

• Thought（思考）：今の状況を言語化し、次に何をすべきかを推論する。
• Action（行動）：呼ぶべきツールと引数を出力する。
• Observation（観測）：オーケストレータがツールを実行して返す結果。

質問: 「A社の昨年度売上を円で。ドル建て資料しか無い」
Thought: 売上のドル額を検索する必要がある
Action:  search("A社 昨年度 売上 決算")
Observation: 売上は 12.0 billion USD
Thought: 円換算に当時の為替が要る
Action:  get_fx_rate("USD/JPY", "昨年度末")
Observation: 150.2
Thought: 12.0e9 × 150.2 を計算する
Action:  calc("12.0e9 * 150.2")
Observation: 1.8024e12
Thought: 円建ての答えが出た
Answer:  約1兆8024億円

ReActの本質は、思考というトークン列を文脈に積むことで、次の行動選択を思考に条件づける点にあります。Thoughtを挟まず行動だけを連ねると、モデルは一手ごとの逐次計算を1回の前向き計算に押し込むことになり、多段の段取りで破綻しやすい。Thoughtは中間状態を外部化する作業メモリとして働き、これは 思考の連鎖（Chain-of-Thought） を行動と結合した拡張にあたります。同時に、Observationが実データでThoughtを裏打ちするため、CoT単独より幻覚に強くなります。

計画と反省：ループで自己修正する

ReActが逐次的な「一手ずつ」であるのに対し、複雑なタスクでは**計画（planning）と反省（reflection）**を明示的に回します。

計画は、ゴールをサブゴールへ分解し実行順を決める工程です。前もって全手順を立てる方式（plan-then-execute）と、状況を見て逐次立てる方式（ReAct的）があり、前者は見通しが良い反面、途中で前提が崩れると硬直します。反省は、実行結果をモデル自身に批評させ、失敗や不足を言語化して次の試行へフィードバックする工程です。Reflexionのように、失敗の要因を要約して文脈に残し、次ラウンドの方針を書き換える手法が代表的です。

計画・反省ループ:
  plan     = 分解(ゴール)                    # サブゴール列
  for attempt in 1..N:
      result   = 実行(plan)                  # ReActで各サブゴールを遂行
      if 成功条件(result): return result
      critique = 反省(ゴール, plan, result)   # 何が悪かったかを言語化
      plan     = 改訂(plan, critique)        # 批評を反映して計画を更新
  return 最良の試行

マルチエージェント：役割分担と協調

単一エージェントで抱えきれないタスクは、複数のエージェントに役割を分けて協調させます。典型構成は、統括役（オーケストレータ／プランナ）が仕事を分割し、専門役（コーダ・検索役・批評役など）に割り振り、結果を統合する階層型です。ほかに、対等なエージェントが議論して合意形成する討論型、生成役と批評役が交互に磨く生成・批評型があります。

マルチエージェントの利点は、関心の分離（各エージェントの文脈とツールを絞れる）と並列化です。一方で代償が重い。エージェント間の伝言は自然言語なので情報が欠落・変質しやすく、累積誤差が段数に応じて増幅します。呼び出し回数が増えればコストとレイテンシも跳ね上がります。分けるほど良いわけではなく、分割が生む伝達損失と管理費が、分業の利得を上回らない範囲で使うのが鉄則です。

失敗と暴走：エージェント特有のリスクと制御

エージェントは行動する分、素のLLMより危険です。主要な失敗モードを押さえます。

制御の基本は多層で敷きます。第一にステップ上限とコスト上限でループを必ず有限化する。第二に最小権限——各ツールに必要最小の権限だけ与え、破壊的操作（削除・送金・外部送信）は人間承認（human-in-the-loop）を挟む。第三に観測の検証——ツール出力をスキーマや妥当性でチェックし、不正なら訂正を促す。第四にサンドボックス化——コード実行やファイル操作は隔離環境に閉じ込め、副作用の波及を断つ。

まとめ：モデルは頭脳、安全は外側の設計

LLMエージェントは「賢いモデルに道具を持たせれば自律する」という話ではありません。要点を一枚に整理します。

結論として、エージェントの知能はモデルに宿りますが、堅牢さと安全はモデルの外側の制御設計に宿ります。ツールをどう定義し、ループをどう有限化し、観測をどう検証し、権限をどう隔離するか——この設計の質が、実用に耐えるエージェントと暴走する試作品を分けます。行動を人間の選好に沿わせる学習側の枠組みは RLHF と DPO を、入力側の組み立ては プロンプトエンジニアリング を併読すると、エージェント設計の全体像が線でつながります。