← 機械学習テキスト 一覧

🎓 レベル:発展 | 重要度:B(標準)

📎 前提:プロンプティングとIn-context learning | 関連:検索拡張生成

要点(BLUF)


なぜツールが要るのか:LLM 単体の限界

LLM は次トークン予測の塊なので、得意・不得意がはっきりしています。

苦手なことなぜ苦手かツールで補う
厳密な計算算術を「確率的に」生成するため桁が増えると崩れる電卓・コード実行
最新情報学習時点で知識が凍結している(パラメトリックな知識)検索・データベース
外界への作用テキストを出すだけで、メール送信・予約・ファイル操作はできないAPI 呼び出し
検証・再現出力が本当に正しいか自分では確かめにくいテスト実行・外部照合

要するに、LLM を「推論・判断のレイヤー」に置き、実際の作業は信頼できる外部システムにやらせるという分業です。LLM は API に直接触れず、「呼びたい」という意図だけを出します。

これは 検索拡張生成(RAG)の発想の一般化です。RAG は「検索ツールを1回呼んで結果を文脈に足す」特殊形。ツール使用は検索に限らず、計算・コード・任意の API へ拡張し、しかも何回でも・条件分岐しながら呼べるようにしたものと捉えられます。


ツール使用 / 関数呼び出し(function calling)

仕組み:LLM は「呼び方」を出す、実行はしない

中心となる誤解しやすい点を先に書きます。LLM はツールを実行しません。 LLM が出すのは「この関数を、この引数で呼んでほしい」という構造化された指示(典型的には JSON)です。実行とその結果の差し戻しは、外側のプログラム(オーケストレータ)の仕事です。

流れは4段です。

  1. ツール定義を渡す:使えるツールの一覧(名前・用途・引数のスキーマ)をプロンプトに与える。これは プロンプティングとIn-context learning の in-context そのもの。「こういう道具があるよ」と文脈で教えるだけで、追加学習は要りません。
  2. LLM が呼び出しを生成:ユーザーの要求を読み、必要なら「search(query="…") を呼びたい」という構造化出力を返す。自然な文章ではなく、機械が確実にパースできる形である点が肝心です(実運用のプログラムは文章ではなく検証済みデータを必要とするため)。
  3. 外部で実行:オーケストレータがその関数を実際に走らせ、結果(検索ヒット・計算値・API レスポンス)を得る。
  4. 結果を文脈に戻す:得られた結果を**観測(observation)**として文脈に追記し、LLM をもう一度動かす。LLM はその観測を踏まえて、最終回答を作るか、次のツールを呼びます。
flowchart TD
    U["ユーザーの要求"] --> M["LLM:推論し<br/>ツール呼び出しを生成"]
    M -->|"構造化出力(例:JSON)"| O["オーケストレータ<br/>(外部プログラム)"]
    O -->|"関数を実行"| T["外部ツール<br/>(検索・計算・API)"]
    T -->|"実行結果"| O
    O -->|"結果を観測として文脈に追記"| M
    M -->|"観測で十分なら"| A["最終回答"]
    M -.->|"まだ足りなければ次のツールへ"| O

ポイントは、ツール使用で in-context に「観測」という新しい種類の情報が足されることです。プロンプト(指示)と例示に加えて、「実際に外界を触って得た事実」が文脈に入る。これがエージェントの土台になります。

命名の混乱(要最新確認)

同じ仕組みでも提供元で呼び名が違います。ある社は function calling、別の社は tool use、と呼びます。概念は同じ「構造化出力でツールを呼ぶ」です。⚠️ 具体的な JSON スキーマの形・対応モデル・呼び出し方法・並列呼び出しの可否・ツール接続の標準プロトコルは頻繁に変わります。実装時は必ず最新の公式仕様を確認してください。本ノートで覚えるのは「構造化出力 → 外部実行 → 観測を戻す」という不変の骨格だけで十分です。


エージェント:推論と行動のループ

1回呼ぶだけでは足りない

「東京の明日の天気を調べて、傘が要るか判断して」程度なら、検索を1回呼べば終わります。しかし「複数サイトを調べ、矛盾を確かめ、要約してファイルに保存する」のような複数ステップのタスクは、1回の呼び出しでは無理です。途中の結果を見て次の手を決める必要があります。

そこで、ツール使用をループにします。これがエージェントです。LLM が司令塔となり、「考える → 行動する → 結果を見る → また考える」を、ゴールに達するまで繰り返します。

ReAct:Reason + Act

最も基本的で廃れにくいパターンが ReAct(Reason + Act) です。各ステップで LLM は3つを順に出します。

この Thought → Action → Observation を、ゴール達成(または上限回数到達)まで反復します。

flowchart LR
    G["ゴール"] --> THINK["Thought<br/>(考える:次の一手を推論)"]
    THINK --> ACT["Action<br/>(行動:ツールを呼ぶ)"]
    ACT --> OBS["Observation<br/>(観察:結果を文脈へ)"]
    OBS --> CHK{"ゴール達成?"}
    CHK -->|"いいえ"| THINK
    CHK -->|"はい"| FIN["最終回答"]

ReAct の効きどころは、推論と行動を交互に挟むことです。考えるだけ(思考の連鎖だけ)だと事実に基づかず外しやすく、行動だけだと無計画に道具を叩いてしまう。両方を絡めると、外界からの観測で推論を補正しながら進められます。研究では、推論と行動を組み合わせると、片方だけより複数ステップ課題の成功率が明確に上がることが報告されています(具体的な数値・ベンチマークは⚠️要最新確認)。

計画・実行・観察・自己反省

ReAct を土台に、より凝った構成も使われます。これらは原理のレベルで押さえてください(実装名は古びます)。

要するに、外界からの観測自分の出力への内省という2種類のフィードバックで、LLM が自分の行動を逐次補正していく構図です。

メモリ:複数ステップを支える記憶

ループが長くなると、文脈に入りきらない情報をどう保持するかが問題になります。エージェントの記憶は 書く → 管理する → 読む(write–manage–read) のループとして整理でき、内容で次のように分けられます。

記憶の種類中身
短期(作業)記憶いま進行中のやり取り直近の Thought / Observation の履歴
エピソード記憶過去の具体的な経験前回このタスクをどう解いたか
意味記憶一般的な事実知識ドメインの定義・ルール
手続き記憶やり方・手順うまくいったツール使用の型

長期記憶は外部ストア(多くは 検索拡張生成 と同じ検索の仕組み)に置き、必要なときだけ読み出して文脈に足します。⚠️ 記憶の持ち方・要約圧縮・忘却の戦略は研究が活発で標準化されていません

自律性と強化学習との近さ

エージェントが「状態(観測)を見て、行動(ツール)を選び、結果を受けてまた選ぶ」という構図は、強化学習(強化学習 目次)の枠組みとそっくりです。観測=状態、ツール呼び出し=行動、ゴール達成度=報酬、と対応づけられます。

違いは、ReAct の素朴な形では方策を学習せず、LLM が in-context の指示と観測だけを頼りに、その場の推論で行動を選んでいる点です。一方で、エージェントの行動選択そのものを試行錯誤の報酬で学習させて方策を改善する研究も進んでいます(自己反省を学習に組み込む系統など)。発想として、エージェント設計と強化学習は地続きだと押さえておくと見通しが良くなります。


⚠️ よくある誤解・落とし穴・要最新確認(最重要)

この節がこのノートで一番大事です。エージェント領域は機械学習で最も急速に動いており、安全性・信頼性の面で未解決問題が多いからです。


まとめ

ツール使用は「LLM を推論レイヤーに据え、苦手な計算・最新情報・外界作用を外部ツールに分業させる」発想で、構造化出力で呼び・外部で実行し・観測を文脈に戻すのが骨格です。これをループにしたのがエージェントで、ReAct(考える→行動する→観察する)が基本形。計画・自己反省・メモリで複雑なタスクを多段で進めます。ただし標準が定まらず、信頼性・暴走・コストが未解決の最前線領域なので、具体は常に要最新確認し、原理と人間の監督を軸に据えてください。


関連ノート