Step by Token

チャプター 11 · エージェント · 10 min

返答するモデルから行動するモデルへ

ツール使用、ReActループ、マルチステップタスク。LLMが世界で行動できるエージェントになる方法。

応答するモデルから行動するモデルへ

これまでのすべての章では、LLMは受動的な役割で描かれていた。プロンプトを受け取り、応答を生成し、終わり。モデルは世界で何もしない——テキストを生成するだけだ。

しかし、何かが変わった。LLMは今やツールを呼び出せる：ウェブを検索し、コードを実行し、ファイルを読み込み、メールを送ることができる。この能力によって、まったく異なるアーキテクチャが可能になった。

ツールなしモデルの限界

インターネットにアクセスできないLLMに「今のAppleの株価は？」と尋ねてみよう。

もっともらしい何かをでっち上げるか、分からないと言うだろう。どちらにせよ、正しく答えることはできない——その情報はモデルのパラメータに存在しないから。

リアルタイムの株価APIというツールを与えれば、答えは自明になる。モデルはこの情報を訓練中に学習する必要はない。必要なときに取得できる。

ReActループ

エージェントの標準的なアーキテクチャはReAct（Reasoning + Acting）と呼ばれる。3つの繰り返しフェーズで動作する：

思考（Think） — モデルは状況を分析する。推論の連鎖を書き出す。「この質問に答えるにはXが必要だ。これらのパラメータでツールYを呼び出す」

行動（Act） — モデルは構造化されたツール呼び出し——ツール名とそのパラメータ——を生成する。システムが呼び出しを実行し、結果を取得する。

観察（Observe） — ツールの結果がコンテキストに注入される。モデルは何が起きたかを確認し、次に何をすべきかを決定する。

これを繰り返す。モデルが応答するのに十分な情報を得たと判断するまで。

ステップごとに見てみよう

ループを観察しよう：モデルは考え、ツールを選び、結果を読み、また始める。それぞれのサイクルは新しいトークン予測である——「エージェント」は新しいアーキテクチャからではなく、関数呼び出しを学んだ LLM から立ち現れる。

ツールの定義方法

ツールはモデルが「魔法のように理解する」コードの断片ではない。それはコンテキストの中でモデルが目にする構造化された定義——名前、説明、パラメータ——だ：

{
  "name": "web_search",
  "description": "ウェブで最新情報を検索する。",
  "parameters": {
    "query": "string — 検索クエリ"
  }
}

モデルは訓練中に、このフォーマットでツール呼び出しを生成することを学んだ。「ツールを使うことを選択する」とき、モデルはAPIコールのようなテキストを単に生成しているに過ぎない。

システムはこのテキストを検出し、実際の呼び出しを実行し、結果をコンテキストに返す。

膨らんでいくコンテキスト

ループの各イテレーションは、コンテキストにトークンを追加していく。推論、ツール呼び出し、結果。5回のイテレーションが必要な複雑なタスクは、簡単に数千トークンを消費する。

これがエージェントが単純な質問と回答のやり取りよりも遅くコストがかかる傾向がある理由だ。また、コンテキスト管理——何を残し、何を要約し、何を捨てるか——がエージェントシステム設計における未解決の問題である理由でもある。

ツール使用 対 ファインチューニング

自然な疑問：なぜ情報を直接モデルに教えるのではなく、ツールを使わせるのか？

いくつか理由がある：

データは変わる。 株価、天気、データベースの状態——この情報は常に変化する。どんな訓練もそれを捉えることはできない。

精度。 計算、SQLクエリ、単位変換——ツールは決定論的で正確だ。LLMはそうではない。

モジュール性。 モデルに新しいツールを与えるには数行で済む。新しいスキルを統合するためにモデルを再訓練するには、数週間と何百万ドルものコストがかかる。

計画とタスク分解

最も有能なエージェントは線形ループに満足しない。複雑なタスクをサブタスクに分解し、いくつかを並行して実行し、結果を組み合わせる。

例えば、「3社の競合他社を比較したレポートを書いて」は次のように分解できる：各競合他社の情報を検索する（3つの並行呼び出し）、そして結果を統合する。

これはまだ活発な研究分野だ。現在のLLMは短いタスクの計画はそれなりにできるが、長く複雑なタスクでは容易に迷走する。

エージェントのリスク

行動する能力には、害を引き起こす能力も伴う。

取り消せない行動。 メールボックスにアクセスできるエージェントはメールを送れる。取り消しは不可能だ。良いエージェントアーキテクチャは読み取りアクション（無害）と書き込みアクション（確認が必要）を区別する。

無限ループ。 ガードレールがなければ、エージェントはループにはまり込む可能性がある：情報を探し、見つからず、言い換えて、また探す……際限なく。

報酬ハッキング。 目標の定義が不十分だと、エージェントは期待する行動をとらずにスコアを最大化する抜け道を見つける可能性がある。

MCP：ツールの標準化に向けて

初期、各ベンダーは独自のtool useフォーマットを定義していた：OpenAIはfunction calling、Anthropicは内部プロトコル、各エージェントフレームワークは車輪を再発明していた。結果：互換性のなさ、モデルごとに作り直される統合、断片化したエコシステム。

2024年11月、AnthropicはModel Context Protocol（MCP）を発表した：ツール、リソース、プロンプトをモデルに依存しない方法で記述するためのオープンな標準だ。MCPサーバーはツールのセット（例えば「このファイルを読む」、「このデータベースに問い合わせる」）を公開する。MCP互換のクライアント——Claude Desktop、Cursor、VSCode拡張、エージェントフレームワーク——なら何でも接続できる。

よく出てくる例え：MCPはLLMにとって、USB-Cが周辺機器にとってそうであるようなものだ。共通のポート。

採用は速かった：OpenAI、Microsoft、そしてほとんどの主要ベンダーが2025年にMCP対応を発表した。事実上、tool useの標準プロトコルになった。

コードインタープリタ、サンドボックス、コンピューターユース

特に重要なツールのクラスをいくつか挙げる：

コードインタープリタ。 モデルが任意のコードを実行できるPythonサンドボックス（時にJavaScript）。精密な計算、データ操作、グラフ生成——LLMがネイティブには苦手なことを、すべてPythonに委譲できる。OpenAI、Claude、Googleで利用可能だ。

ブラウザ／ウェブ自動化。 モデルがウェブページ上でクリック、スクロール、フォーム入力できるようにするツール。Anthropicはこれをcomputer useと呼び、OpenAIはOperatorを提供する。まだ脆弱だが、進化は速い。

ファイルシステム＆シェル。 仮想ディスクとターミナルへのアクセスを与えるツール。Cursor、Cline、Aider、Claude Codeのような「コーディングエージェント」の中核だ。

長期記憶

エージェントのコンテキストは膨らむが、限界はある。アシスタントは次の会話であなたをどうやって認識するのか？外部の長期記憶だ。

いくつかのアプローチがある：

  • ベクトル記憶 — 重要な対話ごとに要約して埋め込みとして保存する。新しい会話のたびに、関連する記憶を取得する（記憶版のRAG）。
  • 構造化されたユーザープロファイル — エージェントがユーザーに関するファイル（好み、進行中のプロジェクト、履歴）を更新していく。
  • 手続き記憶 — エージェントがうまくいったレシピ（「論文を要約するには、これらのステップに従う」）を記録しておく。

ChatGPTは2024年に、Claudeは2025年にメモリ機能を導入した。エージェント設計で最も活発な領域のひとつだ。

マルチエージェント：複数のLLMの協調

最近のトレンド：単一のエージェントではなく、複数の専門化したLLMを協調させる。

オーケストレーターエージェントがタスクを受け取り、分解して専門化されたエージェント（コードの専門家、ウェブ検索の専門家、チェッカー）に委託する。結果がオーケストレーターに返り、組み合わせられる。

このアーキテクチャは人間の組織に似ており——同じ利点（並列化、専門化）と同じ問題（コミュニケーション、調整、エージェント間での情報の損失）を持つ。

何が変わるか

LLMはもはや問い合わせのためのオラクルではなく——腕を接続する脳だ。

この移行はまだ最近のことだ。現在のエージェントはよく定義されたタスクには印象的で、長く曖昧なタスクには脆弱だ。しかし変化のペースは速く、根本的なアーキテクチャ——ReAct、ツール使用、膨らんでいくコンテキスト——を理解することが最良の出発点だ。

更新日

LLM エージェント：応答する LLM から行動する LLM へ · Step by Token