エージェントフレームワークの基本的な考え方

一言でいうと：エージェント = 考える頭脳（大規模モデル）+ 手を動かす身体（ツールと環境）。エージェントフレームワークとは、その「頭脳」に「身体」を組み合わせるための足場のことです——ツール、権限、メモリ、マルチエージェント連携といった雑務をすべて引き受け、開発者は「エージェントに何をすべきかをきちんと考えさせる」ことだけに集中できます。

---

1. エージェントはどうやって動くのか？

すべてのエージェント（どんなに複雑でも）は、シンプルなループの上で動いています：

認識（何が見えるか）→ 思考（何をするか決める）→ 行動（実行する）→ 結果を観察 → 再び思考 → …

例として、「航空券予約アシスタント」を考えてみましょう：

1. 認識：「来週の水曜日に上海行きの航空券を予約して」という指示を受け取る
2. 思考：便を検索し、価格を比較し、予約する必要がある
3. 行動：便検索ツールを呼び出し、予約ツールを呼び出す
4. 観察：「発券成功、¥880」という結果を見る
5. 再思考：もっと安い選択肢をユーザーに伝えるべきか？

このループ自体はシンプルです——難しいのは「行動」のステップを実際に起こさせること、しかも安全かつ制御可能にすることです。

---

2. 大規模モデルは「頭脳」にすぎず、「身体」が必要

大規模モデル（LLM）自体ができることは一つだけです：入力されたテキストから、出力テキストを生成すること。

実際には以下のことはできません：

• ❌ HTTP リクエストを送る
• ❌ あなたのファイルを読み書きする
• ❌ データベースを操作する
• ❌ 前回の会話以外のことを覚えている

大規模モデルを「動かす」には、ツールを接続しなければなりません。この「ツールを接続する」プロセスこそが、エージェントフレームワークの中核的な仕事です。

例え話：レゴ

大規模モデルは最高に優秀なレゴパーツの山です（理解でき、推論できる）。 エージェントフレームワークは説明書 + 収納ボックスです：説明書はパーツの組み立て方を教え（ワークフロー）、収納ボックスは分類と保管を担当します（ツール管理、権限、メモリ）。 説明書と収納ボックスがなければ、どんなに優秀なパーツでも、床に散らばったブロックにすぎません。

---

3. フレームワークは結局何を管理するのか？

完全なエージェントフレームワークは、通常以下の問題を解決する必要があります：

一つずつ見ていきましょう：

3.1 ツールはどう渡すか（Tool Calling）

フレームワークは各ツールを「説明書」として大規模モデルに見せます：

{
  "name": "get_weather",
  "description": "查询某个城市的天气",
  "parameters": {
    "city": { "type": "string", "description": "城市名，例如 北京" }
  }
}

説明書を読んだ大規模モデルは、「get_weather をパラメータ city=北京 で呼び出したい」と言います。フレームワークはこの呼び出しを実際に実行し、結果を大規模モデルに返す責任を負います。このプロセス全体で、開発者はツールを登録するだけでよく、大規模モデルに使い方を教える必要はありません。

3.2 何に触れられるか（権限とサンドボックス）

エージェントは信用できないのか？そうではありません——しかしその能力の境界は明確でなければなりません。フレームワークが提供するもの：

• 権限宣言：このエージェントは /data ディレクトリの読み取りのみ可能で、システムファイルには書き込めない
• サンドボックス：隔離された環境に閉じ込め、「暴走」しても外の世界に影響を与えないようにする

3.3 覚えていられるか（メモリとコンテキスト）

大規模モデルは会話のたびに「記憶喪失」になります。フレームワークの役割：

• 短期：複数ターンの会話をコンテキストとして整理する
• 長期：重要な情報をデータベース／ベクトルストアに保存し、次回も思い出せるようにする

3.4 一人で回せるか（マルチエージェント）

一つのタスクを複数のエージェントに分割して協力させられます：一つは調査担当、一つはコーディング担当、一つはレビュー担当。フレームワークはそれらをオーケストレーションし、誰が先で誰が後か、結果をどう集約するかを決定します。

3.5 世界とどう接続するか（MCP などのプロトコル）

異なるシステム間の接続には標準プロトコルが必要です（例：MCP——Model Context Protocol、モデルコンテキストプロトコル）。フレームワークはこれらのプロトコルを実装し、エージェントが外部ツールと「プラグアンドプレイ」でつながれるようにします。

---

4. 具体例：「お天気アシスタント」を作る

フレームワークなしだと、次のように書くことになるでしょう：

// 疑似コード：フレームワークがない世界
const text = "北京天气怎么样";
const intent = llm.analyze(text);           // モデルに意図を理解させる
if (intent.action === "query_weather") {
  const data = await fetch(`/api/weather?city=${intent.city}`);
  const answer = llm.generate(data, text);   // 結果を自然な言葉にまとめる
  return answer;
}

フレームワークを使った場合（DSH/Cordis スタイルでの例示）：

// 疑似コード：フレームワークがある世界
ctx.set('weather', weatherApi);      // ツールを登録（副作用の供給）

// 「天気プラグイン」をコンポーネントとして登録
ctx.use({
  inject: ['weather'],               // 天気サービスが必要だと宣言
  apply(ctx) {
    ctx.commands.register('天气 <city>', async (city) => {
      const data = await ctx.weather.query(city);   // そのまま使う
      return `☀️ ${city} 今天 ${data.condition}`;
    });
  },
});

違いはどこにあるのでしょうか？

• フレームワークなし：すべてのステップを手書きする必要があり、ツールが増えるとすぐに混乱する
• フレームワークあり：「何が必要か、何を提供するか」を宣言するだけで、接続・スケジューリング・クリーンアップはフレームワークが担当する

---

5. 「アシスタント」から「自己進化」へ

従来のエージェントフレームワークでは、コンポーネントは開発時に書き込まれ、実行時には変わらないものでした。

しかし将来（この論文の中核的な動機の一つでもありますが）、エージェントは次のように動くようになります：

1. エージェントが自分に特定のツールが足りないことに気づく
2. 新しいツールを自分で書く（あるいは別のエージェントに書かせる）
3. 新しいツールを実行中のフレームワークに動的にインストールする
4. しばらく使ってみて使いにくいとわかったら、動的にアンインストールし、より良いものに交換する

これが「自己進化エージェント」です：実行中のシステムが自分自身を書き換える。

かっこよく聞こえますが、危険でもあります——インストールしたものが取り外せなかったり、取り外すときに他のものを壊してしまったりすれば、システムはクラッシュします。この問題を解決するために必要なのが、第 1 章第 3 節のテーマである動的コンポジションです。

---

要点の振り返り

• エージェント = 認識 → 思考 → 行動 のループ
• 大規模モデルは「頭脳」にすぎず、「身体」を用意するのはフレームワークの仕事
• フレームワークの 5 つの責務：ツール、権限、メモリ、オーケストレーション、接続
• 将来のエージェントは自分のコンポーネントを自己改変する → 「動的コンポジション」が必須となる

🚀 次のセクション：「なぜ動的コンポジションが必要なのか」——今のソフトウェアがなぜ「再起動せずに装着・取り外し」できないのか、そしてそれがどれほど重要かを見ていきます。