一覧へ

エージェントとツールの使用 — 実験を自動的に組み合わせるためのループ

LLMにツール、ループ、メモリを追加すると、LLMはエージェントになります。関数呼び出し、ReAct、計画、MCP、マルチエージェントの原理を、実験設計の自動化というシナリオを通じて理解します。

入門
|
22
|
検証済み (2026-07)
進捗0/15 (0%)

エージェントとツール利用:ループを用いた実験計画の自動化

このトピックを修了すると

セクション#7と#8までのアシスタントは、1つのプロンプトに対して1つの応答を返します。しかし、実験計画、データ分析、文献調査などの現実世界のタスクは、複数のステップとツールを伴います。このセクションでは、ツールループ、およびメモリを追加することで、LLMをエージェントに拡張する方法を学びます。

セクション#1の確率的機械、セクション#7の条件付き設計、セクション#8の外部知識注入を組み合わせることで、複数のステップを連鎖させる自律的な実行エンジンが実現します。これは2024〜2025年のAI開発の最前線にあります。


大学院生のタスクの真の複雑さ

来週の実験計画を指導教官に提出する必要があるとします。アシスタントに次のように伝えます。

「以前の論文に基づいて、同様の細胞株とCRISPR編集プロトコルを使用した最近の論文を参照しながら、実験計画の草案を作成してください。また、必要な試薬をリストアップし、それらのうちラボの在庫にないものを明示してください。」

この1つの文には、いくつかのタスクが含まれています。

  1. ラボの論文アーカイブを検索して、どの細胞株が頻繁に使用されているかを特定します。
  2. PubMedを検索して、その細胞株とCRISPR編集条件を使用した最近の論文を探します。
  3. 検索で見つかった類似の論文を要約します。
  4. 複数のプロトコルを統合して、実験計画の草案を作成します。
  5. 草案から必要な試薬のリストを抽出します。
  6. ラボの在庫データベースをクエリして、試薬の入手可能性を確認します。
  7. 不足している試薬のみを明示します。
  8. 最終的な結果をマークダウン文書に整理します。

セクション#7の単一のプロンプトでは、このワークフローを処理できません。セクション#8のRAGは、ステップ1〜3に役立ちますが、ステップ4〜7には役立ちません。必要なのは、複数のツールを順番に、または並行して呼び出す実行エンジンです。この実行エンジンがエージェントです。


エージェント = LLM + ツール + ループ + メモリ

エージェントの構造を、その最小限の構成要素に分解してみましょう。

text
┌─────────────────────────────────────────┐
│              エージェント ループ             │
│                                         │
│   ┌─────────┐    ┌──────────┐           │
│   │  LLM    │───▶│  決定     │           │
│   │(推論)│    │(次のステップ)│          │
│   └─────────┘    └──────────┘           │
│        ▲              │                 │
│        │              ▼                 │
│   ┌────────┐    ┌──────────┐            │
│   │ メモリ │◀───│  ツール呼び出し │           │
│   └────────┘    │(行動)    │           │
│                 └──────────┘            │
│                       │                 │
└───────────────────────┼─────────────────┘
                        ▼
                   外部世界
              (検索、計算、API、DB)

4つの構成要素:

  • LLM: セクション#1〜#6で説明した確率的機械。どのツールをどの引数で呼び出すかを決定します。
  • ツール: 外部世界と対話する関数。これには、検索、計算、データベースへのクエリ、またはAPIの呼び出しが含まれます。
  • ループ: LLMはツールを呼び出し、結果を観察し、次に別の決定を行います。これは繰り返されるプロセスです。
  • メモリ: 過去の観察と決定の記録。これは、短期記憶(コンテキストウィンドウ)と長期記憶(外部ストレージ)に分割できます。

これらの4つの構成要素を組み合わせることで、エージェントは複数のステップを自律的に実行できます。

生物学的アナロジー - 環境に対する細胞の応答。 細胞もこの構造を持っています。センシング(受容体)→ 決定(シグナルカスケード)→ 行動(転写因子の活性化、代謝調節)→ 観察(フィードバック)→ 再センシング。セクション#4のシグナルカスケードが細胞内の意思決定回路であった場合、エージェントはその人工的なアナロジーであり、LLMで置き換えます。細胞が「機能的な意思決定システム」であるのと同様に、エージェントもそうです。

ツール - 外部世界へのゲートウェイ

ツールとは、エージェントが呼び出すことができる関数です。各ツールは、名前、説明、およびパラメータスキーマを持ちます。

生物学の分野で役立つツールの例をいくつか示します。

python
tools = [
{
"name": "search_lab_papers",
"description": "研究室の論文アーカイブから関連論文を検索します",
"input_schema": {
"type": "object",
"properties": {
"query": {"type": "string", "description": "検索クエリ"},
"top_k": {"type": "integer", "default": 5}
},
"required": ["query"]
}
},
{
"name": "search_pubmed",
"description": "PubMedで論文を検索します",
"input_schema": {
"type": "object",
"properties": {
"query": {"type": "string"},
"year_from": {"type": "integer"},
"max_results": {"type": "integer", "default": 20}
},
"required": ["query"]
}
},
{
"name": "get_reagent_stock",
"description": "研究室のデータベースで試薬の在庫を確認します",
"input_schema": {
"type": "object",
"properties": {
"reagent_names": {"type": "array", "items": {"type": "string"}}
},
"required": ["reagent_names"]
}
},
{
"name": "write_file",
"description": "結果をファイルに保存します",
"input_schema": {
"type": "object",
"properties": {
"path": {"type": "string"},
"content": {"type": "string"}
},
"required": ["path", "content"]
}
}
]

エージェントはこれらのツールを呼び出し、結果はコンテキストに蓄積されます。エージェントは、このコンテキストを使用して次の決定を行います。

ツールの説明の重要性。LLMは、ツールの名前、説明、およびパラメータスキーマを使用して、どのツールを呼び出すかを決定します。説明が不正確またはあいまいである場合、エージェントは間違ったツールを呼び出すか、不適切な引数を使用する可能性があります。ツールの設計は、プロンプトエンジニアリングと同様に、細心の注意を払って行う必要があります。

優れたツールの説明の要素:

  • このツールを使用するタイミングを明確に記述します。
  • 各パラメータの目的を記述し、例を示します。
  • 戻り値の形式を指定します。
  • エラーケース(パラメータエラー、リソースの不足など)の処理方法を概説します。

関数呼び出し - 標準インターフェース

関数呼び出し(OpenAIの用語)またはツール使用(Anthropicの用語)は、LLMがツールを呼び出すための標準化されたAPIインターフェースです。

トレーニングされたモデルは、**「この時点で、このツールを呼び出す必要がある」**ことを学習しています。ユーザープロンプトとツールのリストが与えられると、ツール名とパラメータをJSON形式で返します。

Claude APIを使用した例を以下に示します。

python
response = client.messages.create(
model="claude-3-5-sonnet-latest",
tools=tools,
messages=[{"role": "user", "content": "過去3年間に研究室で使用された上位3つの細胞株を教えてください。"}],
)
# response.stop_reason == "tool_use"
# response.content には以下が含まれます。
# [
# {"type": "text", "text": "研究室の論文アーカイブを確認します。"},
# {"type": "tool_use", "name": "search_lab_papers",
# "input": {"query": "実験で使用された細胞株", "top_k": 10},
# "id": "toolu_01ABC..."}
# ]

ホストプログラム(エージェントループ)は、この呼び出しを実行し、結果をモデルに渡します。

python
tool_result = search_lab_papers(query="実験で使用された細胞株", top_k=10)
response = client.messages.create(
model="claude-3-5-sonnet-latest",
tools=tools,
messages=[
{"role": "user", "content": "過去3年間に研究室で使用された上位3つの細胞株を教えてください。"},
{"role": "assistant", "content": response.content}, # includes tool_use
{"role": "user", "content": [
{"type": "tool_result", "tool_use_id": "toolu_01ABC...",
"content": json.dumps(tool_result)}
]}
]
)

モデルは、次にこの結果を使用して次の決定を行います。別のツール呼び出しを要求する場合があります(stop_reason == "tool_use")か、最終的な回答を返す場合があります(stop_reason == "end_turn")。

このやり取りは、エージェントループの中核です。

ReActパターン:思考と行動の交互

ReAct(推論 + 行動)とは、エージェントが各ステップで自身の推論を明示的に表現し、その後に行動(ツールの呼び出し)を行うというパターンです。

第7章で説明したChain-of-Thoughtは、回答を生成する前に推論フレーズを埋めることに焦点を当てていましたが、ReActは、各ツールの呼び出しの前に、特定の入力でなぜ特定のツールを呼び出すのかを明示的に述べています。この明示性により、モデルの判断が安定します。

ReActパターンの例:

text
思考:ラボでは特定の細胞株が頻繁に使用されるため、まずラボの論文リポジトリを検索すべきです。
行動:search_lab_papers(query="cell line CRISPR knockout", top_k=15)
観測:[15本の論文からの要約と方法の抜粋]

思考:これらの論文には、HEK293Tが8回、HeLaが5回、U2OSが3回言及されています。HEK293Tが最も頻繁に使用されています。
次に、HEK293TとCRISPR編集プロトコルを使用した最近の論文を検索する必要があります。
行動:search_pubmed(query="HEK293T CRISPR knockout efficient protocol", year_from=2023, max_results=10)
観測:[10本の最近の論文の要約]

思考:これらの論文の中で、2024年のNature Protocolsに掲載された論文は、同様の細胞株と編集方法を使用しているようです。詳細な要約が必要です。
行動:search_pubmed(query="2024 Nature Protocols HEK293T CRISPR efficient", max_results=1)
観測:[論文からの抜粋]

思考:私はプロトコルのドラフトを作成する準備ができました。必要な試薬をリストアップし、在庫を確認します。
...

各思考は、次の行動を正当化し、各観測は、次の思考の証拠として役立ちます。この明示的な構造は、エージェントの自己検証デバッグを支援します。問題が発生した場合、誤った判断が行われた思考に遡って追跡できます。

最新モデルに組み込まれていること。 Claude 3.5、GPT-4o、o1などの最新モデルは、ReActパターンに従うように明示的に指示されなくても、このフローを自動的に使用します。これは、これらのモデルが大量のエージェントログでトレーニングされた結果です。


計画:大規模タスクの分割

単純なタスクの場合、1回のツールの呼び出しで十分ですが、より複雑なタスク(大学院生からのリクエストのような8ステップのタスク)の場合、まず全体的な計画を立てることが有益です。

計画と実行パターン。

  1. ユーザーのリクエストを受け取ったら、まず計画を立てます:必要なステップをリストアップします。
  2. 各ステップを順番に、または並行して実行します
  3. 各ステップの結果を観察し、必要に応じて計画を修正します
  4. 最終結果を返します。

計画を立てる際には、LLMに以下のようなプロンプトを与えます。

text
あなたは研究アシスタントです。ユーザーのリクエストを実行可能なステップに分割してください。
各ステップで使用するツールとパラメータを指定してください。

ユーザーリクエスト:(ユーザーのリクエスト)

計画をJSON形式で返します。
{
  "steps": [
    {"step_id": 1, "action": "tool_name", "params": {...}, "depends_on": []},
    {"step_id": 2, "action": "tool_name", "params": {...}, "depends_on": [1]},
    ...
  ]
}

並列実行。 depends_onが空のステップは、並行して処理できます。たとえば、5本の論文を要約するステップは、並行して実行することで時間を節約できます。

動的な再計画。 ステップの結果が計画から逸脱した場合(たとえば、検索で0件の結果が返された場合)、残りのステップを再構成します。これは、CoT + ツール + 再計画の組み合わせです。

生物学的なアナロジー。 研究プロジェクトを管理し、概念を調整することと似ています。大規模なプロジェクトをマイルストーンとタスクに分割し、並行して実行できるものと、順番に実行する必要があるものを区別し、結果に基づいて計画を調整します。エージェントが行うことは、この管理サイクルを自動化することです。


メモリ:短期および長期

エージェントが複数のステップを実行するにつれて、情報が蓄積されます。この情報が格納される場所が、メモリ設計です。

短期メモリ = コンテキストウィンドウ。 現在のセッション内でツールの呼び出し、観測、および推論の履歴はすべて、コンテキストウィンドウに蓄積されます。第6章で説明した注意メカニズムは、この履歴を参照します。

問題。 セッションが長くなるにつれて、コンテキストウィンドウを超えてしまいます。GPT-4の128KやClaudeの200Kでも、30〜50回のツールの呼び出しでいっぱいになります。また、第8章で説明した「中間で失われる」問題も発生します。

短期メモリ管理技術。

  • 要約。 古い観測を要約に圧縮します。
  • 選択的保持。 重要な結果のみを保持し、詳細なログをファイルに保存します。
  • チャンク化。 最新のNステップのみをコンテキストに保持します。

長期メモリ = 外部ストレージ。 複数のセッションにわたって保持される情報。

  • ファイルシステム。 各セッションの結果をファイルとして保存します。次のセッションで、ファイル読み取りツールを使用してファイルを参照します。
  • ベクトルDB。 過去の結果を埋め込みとして保存し、必要に応じてRAGを使用して取得します。
  • 構造化データベース。 構造化情報(実験履歴、結果メトリックなど)をSQLデータベースに保存します。

生物学的なアナロジー。 細胞のエピジェネティックメモリ。遺伝子発現の履歴は、ヒストン修飾とDNAメチル化を通じて世代を超えて受け継がれます。エージェントの長期メモリにも、同様の永続性の概念があります。

MCP:ツールインターフェースの標準化

これまで説明してきたツールは、各エージェントシステムで異なる形式で定義されています。Claude APIのツールスキーマ、OpenAIの関数呼び出し、LangChainツール、LlamaIndexツールなどは、それぞれわずかに異なるインターフェースを持っています。新しいシステムに移行する場合、ツールを再定義する必要があります。

モデルコンテキストプロトコル(MCP)。 2024年にAnthropicによって提案された標準。ツール、リソース、プロンプトを、言語、フレームワーク、モデルに依存しない方法で定義するオープン標準です。

構造。

  • MCPサーバー: ツールとリソースを提供するプロセス。例:ファイルシステムサーバー、GitHubサーバー、PubMedサーバー。
  • MCPクライアント: サーバーに接続してツールを呼び出すエージェント。
  • 通信: 標準のJSON-RPCプロトコル。

生物学の研究において役立つMCPサーバーの例。

  • PubMed MCP: 論文の検索と取得。
  • PDB MCP: タンパク質構造データ。
  • UniProt MCP: タンパク質情報に関する質疑応答。
  • ファイルシステムMCP: 実験室のファイルシステムへのアクセス。
  • Slack MCP: チームチャンネルへの通知。

重要性。 MCPが標準化されると、エージェントシステムは、自身が理解している言語(MCP)のみを使用すればよくなります。新しいツールを追加するには、単にMCPサーバーを起動するだけで済みます。ツールエコシステムは、単一の標準に基づいて構築されます。

2025年現在、Claude Desktop、Cursor、Continue、Windsurfなどの主要なエージェントツールがMCPを採用しています。数百のMCPサーバーがオープンソースコミュニティで公開されています。MCPを理解し、自身でMCPサーバーとしてツールを作成できる能力は、今日のAI開発者にとって基本的なスキルになりつつあります。


マルチエージェント:役割分担

複雑なタスクの場合、1つのエージェントですべてを行うよりも、複数のエージェント間で作業を分担する方が効果的な場合があります。

生物学研究パイプラインの例。3つのエージェントに分割します。

  • 文献エージェント: 論文の検索と要約に特化。
  • プロトコルエージェント: プロトコルの作成と試薬リストの整理。
  • 在庫エージェント: 実験室の在庫管理。

3つのエージェントは、オーケストレーターの下で連携します。オーケストレーターは、ユーザーのリクエストを受け取り、どのエージェントに何を委任するかを決定します。

Anthropicのサブエージェント実験。 Claude Code、Manus、Devinなどの最新のコーディングエージェントは、この構造を使用しています。メインエージェントは、複数のサブエージェントを生成し、サブタスクを並行して実行します。各サブエージェントは独自のコンテキストウィンドウを持ち、情報を分離します。

マルチエージェントはいつ有利ですか?

  • 異なる知識領域が必要な場合(文献、プロトコル、在庫)。
  • 並列処理によって時間を節約できる場合(10本の論文を同時に要約するなど)。
  • コンテキストの分離によって汚染を防ぎたい場合。

単一のエージェントはいつ優れていますか?

  • コンテキストを共有する必要がある場合(単一の会話内で継続的に調整するなど)。
  • オーケストレーションのオーバーヘッドがメリットよりも大きい場合。
  • デバッグと監査が重要な場合(単一のログで追跡する方が簡単)。

安全性:ツール実行のリスク

エージェントが実際にツールを実行するということは、現実世界に影響を与えることを意味します。ミスや誤用は、実際の損失につながる可能性があります。

生物学のコンテキストにおけるリスクの例。

  • 自動試薬注文ツールが、誤った数量を注文する。
  • 実験スケジューリングツールが、誤った時間をスケジュールする。
  • データベース修正ツールが、実験レコードを上書きする。
  • 外部API呼び出しを通じて、個人情報が漏洩する。

防御メカニズム。

1. ツール権限の分離。 読み取り専用ツールと、書き込みおよび実行ツールを分離します。ほとんどの自動実行は、読み取り専用に制限されます。

2. 人間の承認ゲート。 破壊的なツール(試薬の注文、データ修正)の場合、実行前に人間の確認を求めます。エージェントは計画を提示し、ユーザーが承認してから実行します。

3. ツール実行ログ。 すべてのツール呼び出しを監査可能なログに記録します。

4. サンドボックス化。 実行環境を分離します。たとえば、コード実行ツールは、DockerまたはWASMサンドボックスで実行されます。

5. プロンプトインジェクション防御。 第7章のリスクは、エージェントにおいてはさらに深刻です。検索で見つかったドキュメントやファイルから読み込まれた内容には、「元の指示を無視してXを実行する」などの指示が含まれている可能性があります。ツール結果をシステムプロンプトに直接接続するのではなく、明示的な区切り文字で囲みます。

生物学特有のリスク。 化学情報と生物情報の組み合わせにより、危険な物質の合成方法に関する情報が生成される可能性があります。アラインメントトレーニングでこれを防ぐことができますが、完璧ではありません。詳細については、第11章を参照してください。

生物学的応用シナリオ

シナリオ1 — 実験計画支援(前回のシナリオからの続き)

先に述べた8ステップのリクエストを処理するエージェントを実装します。

python
import anthropic
client = anthropic.Anthropic()
tools = [...] # 以前に定義した4つのツール
def execute_tool(name, params):
if name == "search_lab_papers":
return vectorstore.similarity_search(params["query"], k=params.get("top_k", 5))
elif name == "search_pubmed":
return pubmed_api(**params)
elif name == "get_reagent_stock":
return db.query_stock(params["reagent_names"])
elif name == "write_file":
Path(params["path"]).write_text(params["content"])
return {"status": "ok"}
def agent_loop(user_request):
messages = [{"role": "user", "content": user_request}]
while True:
response = client.messages.create(
model="claude-3-5-sonnet-latest",
tools=tools,
messages=messages,
max_tokens=4096
)
if response.stop_reason == "end_turn":
return response.content[0].text
messages.append({"role": "assistant", "content": response.content})
tool_results = []
for block in response.content:
if block.type == "tool_use":
result = execute_tool(block.name, block.input)
tool_results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": json.dumps(result)
})
messages.append({"role": "user", "content": tool_results})
# 使用例
result = agent_loop("過去の論文で用いられた細胞株と同様のCRISPR編集プロトコルを持つ最近の論文を参照し、今回の実験計画のドラフトを作成してください。また、必要な試薬をリストアップし、当研究室の在庫にないものを明記してください。")

このループは、ツールを呼び出して、最大20〜30ステップで8ステップのリクエストを自動的に処理します。

シナリオ2 — 分子特性計算エージェント

RDKit、PubChem、OpenBabelなどの化学情報ツールをMCPサーバーとしてラップし、エージェントに接続します。

ユーザーのリクエスト:「このSMILES分子に対して、類似した予測IC50値を持つ3つの既知の阻害剤を見つけてください。また、hERGチャネルの副作用予測に関する情報も提供してください。」

エージェント:

  1. SMILES文字列を分子構造に解析します(RDKit MCP)。
  2. 分子フィンガープリントを計算します(RDKit)。
  3. PubChemで類似した分子を検索します(PubChem MCP)。
  4. hERG阻害予測モデルを呼び出します(別の予測API)。
  5. 結果を統合してレポートを作成します。

このようなエージェントは、創薬の初期段階で導入され始めています。

シナリオ3 — 自動化された実験データ分析パイプライン

測定装置からの生のファイルを自動的に分析します。

  • ファイル監視エージェント: 実験装置のフォルダーを監視し、新しいファイルが作成されたことを検出します。
  • QCエージェント: 生データの品質をチェックし、外れ値を検出します。
  • 分析エージェント: 統計分析、可視化、レポート生成を実行します。
  • 通知エージェント: 結果をSlackまたは電子メールで通知します。

これは、マルチエージェントのオーケストレーションの現実世界の例です。最近のラボ自動化スタートアップの中には、このようなシステムを提供しているものがあります。


重要なポイント

  • エージェント = LLM + ツール + ループ + メモリ。単一のプロンプトを超えて、自律的で多段階の実行を行います。
  • ツールの使用/関数呼び出しは、LLMが外部ツールを標準的な方法で呼び出すためのインターフェースです。
  • ReActパターン — 思考・行動・観察サイクル。セクション#7のCoTの自然な拡張です。
  • プランニングは、大規模なタスクを小さな部分に分割し、並行して処理します。動的な再計画により、失敗に対処します。
  • メモリは、短期(コンテキスト)と長期(ファイル、ベクトルDB、SQL)のメモリを組み合わせます。セッション間で保持されます。
  • MCPは、ツールのインターフェースのオープンスタンダードです。単一のスタンダードで、ツールエコシステムを構築します。
  • マルチエージェントは、役割分担が必要な場合に利用されます。オーケストレーター + サブエージェントパターン。
  • 安全性 — 権限の分離、人間の承認ゲート、ログ、サンドボックス、インジェクション防止。ツールの実行は現実世界に影響を与えます。

📐 付録 — 専門家向け数学/システム数式

難易度: 非常に難しい 対象読者: システム設計、強化学習、形式化されたプロセスに関する知識を持つ読者。

A.1 エージェントの視点からのマルコフ決定過程

エージェントを部分観測マルコフ決定過程(POMDP)として形式化する。

  • 状態 s ∈ S: 世界の現在の状態(エージェントによって直接観測されない)。
  • 観測 o ∈ Ω: ツールの呼び出しの結果。o ~ O(o | s).
  • 行動 a ∈ A: ツールの呼び出し。
  • ポリシー π(a | h): 観測と行動の履歴 h が与えられたときの次の行動の確率。
  • 報酬 r: 目標の達成度を測る尺度。

LLMはπをパラメータ化する関数である。π_θ(a | h) = LLM(h).

相違点. 強化学習とは異なり、LLMのπは、トレーニング中に明示的な報酬信号でトレーニングされない(RLHFは別の層である)。ただし、エージェントログから「この状況では、この行動」というパターンをトレーニングデータから吸収する。

A.2 関数呼び出しのためのトレーニング

LLMがツールをうまく呼び出すのは自動的ではない。トレーニングデータには、ツールの呼び出しのパターンが明示的に含まれている必要がある。

関数呼び出しトレーニングデータ形式:

text
User: "過去3ヶ月間の細胞培養の成功率はどのくらいですか?"
Assistant: <tool_call>get_experiment_records(period="3_months")</tool_call>
Tool: {"records": [...], "success_rate": 0.87}
Assistant: "過去3ヶ月間の平均成功率は87%です。"

このような数万件の対話でトレーニングされる。モデルは、状況に適したツールの呼び出しパターンを学習する。

Toolformer(Meta AI、2023)は、このトレーニング方法に関する初期の研究である。最近のモデルは、大量のツール使用対話による事前トレーニングとRLHFを使用している。

A.3 ReActの形式化

各ステップ t で:

text
Thought_t ~ π_thought(· | h_t)
Action_t ~ π_action(· | h_t, Thought_t)
Observation_t = Tool(Action_t)
h_{t+1} = h_t ∪ {Thought_t, Action_t, Observation_t}

停止条件:Action_t == "answer" または t == max_steps.

理論的な利点. Thoughtが明示的にコンテキストに含まれている場合、π_actionはそれを参照できる。ThoughtなしでActionを直接抽出するよりも正確である。

最新のモデルにおける内部推論. Claude 3.5のような最新のモデルは、Thoughtを隠れた推論として扱うことがある。外部からは見えないが、内部的には同様の構造を持っている。

A.4 複数ステップの計画の計算複雑性

貪欲な計画(LLMが一度に計画を作成する):

  • 時間:1回のLLM呼び出し
  • エラーの伝播:初期のエラーがすべてのステップに影響を与える。

木探索計画(複数の計画候補を生成して選択する):

  • 時間:N × 1回のLLM呼び出し(N個の候補)+ 評価LLM呼び出し
  • エラーの削減:多様性により、最適な計画を選択する可能性が高まる。

モンテカルロ木探索(MCTS):

  • 各ステップで複数の候補を探索 + ロールアウトシミュレーション
  • 時間の爆発 (b^d, b=分岐係数, d=深さ)
  • AlphaGoおよびo1シリーズの根本的な方法論。

A.5 ツールの選択確率を固定する

LLMがツールを選択する確率:

text
P(tool_i | context) = softmax(logit(tool_i | context))

アンカー効果. 特定の状況がツールの説明に明示的に記載されている場合、その状況がコンテキストにあると、そのツールが選択される確率が急激に増加する。このため、ツールの説明は、プロンプトエンジニアリングと同じくらい重要である。

曖昧さのペナルティ. 類似した状況に適合するツールが複数ある場合、モデルが誤ったツールを選択する確率が高まる。ツールの名前と説明は、互いに明確に区別できるようにする必要がある。

A.6 MCPプロトコルの構造

JSON-RPC 2.0に基づく.

サーバーが提供するメソッド:

  • initialize: プロトコルバージョンと機能を交換する。
  • tools/list: 利用可能なツールのリスト。
  • tools/call: ツールを実行する。
  • resources/list: 静的なリソース(例:ファイル)のリスト。
  • resources/read: リソースを読み取る。
  • prompts/list: プロンプトテンプレートのリスト。
  • prompts/get: プロンプトを取得する。

クライアントが提供するメソッド:

  • sampling/createMessage: サーバーは、呼び出すLLMを要求できる(双方向)。
  • logging/log: サーバーはログをクライアントに送信する。

トランスポート: stdio(標準入力/出力)またはHTTP+SSE。

A.7 コンテキストウィンドウの予算管理

エージェントセッションが長くなるにつれて、コンテキストの管理が重要になる。

セッション予算:

text
budget = C - system_prompt - tools_schema - reserved_output

C: コンテキストウィンドウのサイズ。

セッション中の使用:

text
used = Σ_{t} |Thought_t + Action_t + Observation_t|

used > budget * threshold の場合、圧縮/要約をトリガーする。

圧縮戦略:

  1. 最初のいくつかのステップの詳細な観測を要約に置き換える。
  2. 最後に成功したステップのみを保持する。
  3. すべての中間結果を外部ファイルに保存し、コンテキストにファイルパスのみを保持する。

A.8 マルチエージェント通信プロトコル

エージェント間の通信フォーマット。

メッセージング:

json
{
    "from": "orchestrator",
    "to": "literature_agent",
    "task": "PubMedでHEK293T + CRISPRに関する最新の10件の論文を要約する",
    "context": {...},
    "deadline": "2分",
    "return_format": "json_schema"
}

応答:

json
{
    "from": "literature_agent",
    "to": "orchestrator",
    "status": "success",
    "result": {...},
    "duration": "45秒",
    "cost": {"tokens": 45230}
}

合意メカニズム. 複数のエージェントが異なる回答を返す場合、オーケストレーターは、多数決または品質評価によって最終的な回答を選択する。

A.9 ツールのコストとレイテンシの管理

各ツールの呼び出しにかかるコストとレイテンシ:

ツールレイテンシコスト
ベクトル検索100〜500ms0ドル(セルフホスト)
PubMed API1〜3秒0ドル
LLM呼び出し2〜30秒0.01〜1ドル
Webスクレイピング3〜10秒0ドル
コード実行1秒〜0ドル(サンドボックス)

最適化:

  • 並行して呼び出すことができるものをバッチで呼び出す。
  • キャッシュ(同じクエリを再利用する)。
  • 早期終了(十分な情報が収集されたときにループを停止する)。

A.10 エージェント評価指標

タスクの成功率: 完了率(人間による判断)。 完了までのステップ数: ツールの呼び出し回数。少ないほど効率が良い。 タスクごとのコスト: トークンとAPIコスト。 レイテンシ: 開始から完了までの時間。 堅牢性: 障害からの回復率。

ベンチマーク:

  • AgentBench: さまざまなドメインのエージェント。
  • SWE-bench: 実際のGitHubの問題を解決する。
  • GAIA: 一般的なアシスタントタスク。
  • WebArena: Webの自動化。

生物学に特化したベンチマークは、まだ初期段階にある。

参考文献

このセクションのすべてのコンテンツ、シナリオ、アナロジー、図はBioPlaygroundによって作成されました。以下は、概念学習に役立つ外部の参考文献です。

  • ReAct論文: Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (ICLR 2023)
  • Toolformer: Schick et al., "Toolformer: Language Models Can Teach Themselves to Use Tools" (NeurIPS 2023)
  • Function Calling: OpenAIドキュメント "Function Calling", Anthropicドキュメント "Tool Use"
  • Model Context Protocol: modelcontextprotocol.io, Anthropic公式仕様 (2024)
  • Plan-and-Execute: Wang et al., "Plan-and-Solve Prompting" (ACL 2023)
  • AutoGPTとBabyAGIのコンセプトの起源: NakajimaとRichards、オープンソースプロジェクト (2023)
  • MCTS + LLM: Yao et al., "Tree of Thoughts" (NeurIPS 2023)
  • SWE-bench: Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" (ICLR 2024)
  • AgentBench: Liu et al., "AgentBench: Evaluating LLMs as Agents" (ICLR 2024)
  • Anthropic Building Effective Agents: anthropic.com/research/building-effective-agents (2024)

パート#9では、エージェントの基本的な構造について学びました。パート#10では、長いエージェントセッションでコンテキストウィンドウを賢く管理するための実践的なテクニックについて説明します。

次のコンセプト

  • エピソード#10 context-window-management — エージェントの長いセッションのコンテキストを賢く管理するための実践的なテクニック。
  • エピソード#11 hallucination-and-alignment — エージェントのツール呼び出しの誤判断とハルシネーションの問題。
  • エピソード#13 claude-code-and-cursor — コーディングエージェントの実際的な使用方法。

💬 質問・コメント

0件のコメント

ログインせずに投稿できます。ゲスト投稿は投稿者自身で編集・削除できません。

0/2000

読み込み中...