Claude Advisor Tool実践ガイド — Sonnet×Opus二層構成でコスト80%削減しつつOpus級品質を実現する実装パターン
「Sonnetの速度とコストで、Opusの判断力が欲しい」——エージェント開発者なら誰もが抱えるこのジレンマに、2026年4月リリースのAdvisor Toolが明確な解を出した。SWE-bench Multilingualで+2.7pt、BrowseCompではHaiku単体比2倍超の性能を叩き出しながら、Haiku+Opus構成ではSonnet単体比でコスト最大85%削減。本記事では、executor+advisorの二層アーキテクチャを本番ワークロードに組み込むための実装パターンを、動くコードとコスト計算付きで解説する。
Advisor Toolとは何か — 30秒で掴む全体像
従来のモデル選択の限界:速度・コスト・品質のトリレンマ
Claude APIでエージェントを構築する際、モデル選択は常にトレードオフだった。Opusは賢いが遅くて高い。Sonnetは速くて安いが、複雑な判断で取りこぼす。Haikuはさらに安いが、マルチステップの推論で精度が落ちる。この「速度・コスト・品質のトリレンマ」に対し、従来は用途別にモデルを切り替えるか、品質を妥協するかの二択しかなかった。
二層アーキテクチャという新パラダイム
Advisor Toolは、この構造を根本から変える。executorモデル(Sonnet/Haiku)が通常タスクを高速処理し、判断に迷った時だけOpus advisorに相談するという二層構成だ。重要なのは、advisor呼び出しはexecutorが自律的に判断するという点。開発者がif文で分岐ロジックを書く必要はない。
ベンチマーク結果は説得力がある:
| ベンチマーク | 構成 | スコア | コスト効果 |
|---|---|---|---|
| SWE-bench Multilingual | Sonnet + Opus advisor | Sonnet単体比 +2.7pt | コスト11.9%削減 |
| BrowseComp | Haiku + Opus advisor | 41.2%(Haiku単体19.7%) | Sonnet単体比コスト85%削減 |
Advisor Toolは2026年4月9日にパブリックベータとしてリリースされた。利用にはベータヘッダーの付与が必須となる。
最小構成で動かす — TypeScript実装
ベータヘッダーとツール定義の設定
まず、Anthropic SDK TypeScriptで最小構成を組む。ポイントは2つ。ベータヘッダー advisor-tool-2026-03-01 の指定と、ツール定義での type: "advisor_20260301" の指定だ。
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
const advisorTool = {
type: "advisor_20260301" as const,
name: "advisor",
model: "claude-opus-4-7",
max_uses: 3,
};
advisorモデルは Opus 4.7(claude-opus-4-7) が利用可能だ。通常のツールと異なり、input_schema の定義は不要だ。executorが自律的に呼び出しタイミングを判断し、サーバー側でコンテキストが自動的に供給される。
advisortoolresultブロックの処理フロー
エージェントループ内での処理フローは以下の通り。advisor呼び出しは 単一の /v1/messages リクエスト内で完結する ため、開発者側で追加のAPIコールを行う必要はない。
async function agentLoop(userMessage: string) {
const messages: Anthropic.MessageParam[] = [
{ role: "user", content: userMessage },
];
while (true) {
const response = await client.beta.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 4096,
tools: [advisorTool, ...yourCustomTools],
messages,
betas: ["advisor-tool-2026-03-01"],
});
// end_turnならループ終了
if (response.stop_reason === "end_turn") {
return response.content;
}
// tool_use の場合、自前ツールのみ処理
// server_tool_use(advisor)はサーバー側で自動処理済み
if (response.stop_reason === "tool_use") {
const toolResults = [];
for (const block of response.content) {
if (block.type === "tool_use") {
const result = await executeYourTool(block.name, block.input);
toolResults.push({
type: "tool_result" as const,
tool_use_id: block.id,
content: result,
});
}
}
messages.push({ role: "assistant", content: response.content });
messages.push({ role: "user", content: toolResults });
}
}
}
正直、最初は「advisorの呼び出しをどうハンドリングするのか」と身構えたが、server_tool_use と advisor_tool_result はサーバー側で処理されてレスポンスに含まれる形なので、開発者が意識する部分は少ない。通常のツール呼び出しループをそのまま使える。
モデルペアリング選定 — Haiku+Opus vs Sonnet+Opus
タスク特性別の推奨ペアリング
executor として利用可能なモデルは Haiku 4.5、Sonnet 4.6、Opus 4.6、Opus 4.7 の4つ。advisorは Opus 4.7だ。実用上の選択肢は主に2パターンに絞られる。
| ペアリング | 向いているタスク | 特徴 |
|---|---|---|
| Haiku + Opus | 大量バッチ処理、分類、ブラウジング | コスト最小化優先。簡単なタスクではadvisor未呼び出し |
| Sonnet + Opus | コード生成、複雑な推論、マルチステップエージェント | 品質優先。Opus単体に迫る品質を大幅に低いコストで |
コスト試算:1,000リクエストあたりの実コスト比較
advisor出力は通常400〜700テキストトークン(extended thinking含めて1,400〜1,800トークン)で、Opusレートで課金される。ただし、advisorが呼ばれる頻度はタスクの難易度に依存する。簡単なタスクではadvisorが一度も呼ばれないため、コスト増加はゼロだ。
コスト追跡には、レスポンスの usage フィールドを活用する:
function trackAdvisorCost(response: Anthropic.Message) {
const usage = response.usage;
// executorトークン(トップレベルのusage)
const executorInputTokens = usage.input_tokens;
const executorOutputTokens = usage.output_tokens;
// advisorトークン(usage.iterations内のadvisor_message)
let advisorInputTokens = 0;
let advisorOutputTokens = 0;
if ("iterations" in usage) {
for (const iter of (usage as any).iterations ?? []) {
if (iter.type === "advisor_message") {
advisorInputTokens += iter.input_tokens;
advisorOutputTokens += iter.output_tokens;
}
}
}
console.log(`Executor: ${executorInputTokens}in / ${executorOutputTokens}out`);
console.log(`Advisor: ${advisorInputTokens}in / ${advisorOutputTokens}out`);
}
本番運用の必須パターン — max_usesとコスト上限管理
max_usesによる呼び出し頻度制御
max_uses パラメータは、1リクエストあたりのadvisor呼び出し上限を設定する。公式ドキュメントのコード例では max_uses: 3 が使われており、本番運用では3〜5回/リクエストが推奨値だ。
const advisorTool = {
type: "advisor_20260301" as const,
name: "advisor",
model: "claude-opus-4-7",
max_uses: 3, // 1リクエストあたり最大3回まで
};
max_uses を設定しない場合、複雑なタスクでadvisor呼び出しが際限なく膨れ、コストが予測不能になるリスクがある。本番では必ず設定すること。
会話レベルのバジェットガードレール
ターン単位の制御に加え、会話全体でのadvisor累積コストを追跡し、閾値を超えたらadvisorツール自体を除外する仕組みが有効だ。なお、advisorツールを除外する際は、tools配列からの除外に加えて、会話履歴内のすべての advisor_tool_result ブロックも除去する必要がある。これを怠ると400 invalid_request_error が返される:
let totalAdvisorTokens = 0;
const ADVISOR_BUDGET = 50_000; // 会話全体のadvisorトークン上限
function getToolsForTurn(): Anthropic.Tool[] {
const tools = [...yourCustomTools];
if (totalAdvisorTokens < ADVISOR_BUDGET) {
tools.push(advisorTool);
} else {
console.warn("Advisor budget exceeded — running without advisor");
}
return tools;
}
// advisorを除外する場合、会話履歴からadvisor関連ブロックも除去
function stripAdvisorFromMessages(
messages: Anthropic.MessageParam[]
): Anthropic.MessageParam[] {
return messages.map((msg) => {
if (!Array.isArray(msg.content)) return msg;
return {
...msg,
content: msg.content.filter(
(block: any) =>
block.type !== "server_tool_use" &&
block.type !== "advisor_tool_result"
),
};
});
}
// 各ターン後にadvisorトークンを加算
function updateBudget(response: Anthropic.Message) {
if ("iterations" in response.usage) {
for (const iter of (response.usage as any).iterations ?? []) {
if (iter.type === "advisor_message") {
totalAdvisorTokens += iter.input_tokens + iter.output_tokens;
}
}
}
}
Prompt Cachingとの併用も効果的だ。executorへのシステムプロンプトやツール定義をキャッシュすることで、executor側のinputコストをさらに削減できる。
なお、extended thinkingとadvisorを併用する場合、advisor側でもthinkingが走るためトークン消費が増える点には注意が必要だ。
ハマりポイント5選 — 公式ドキュメントだけでは掴めない落とし穴
1. ベータヘッダー忘れ
ツール定義に advisor_20260301 を書いても、リクエストヘッダーに betas: ["advisor-tool-2026-03-01"] がないとバリデーションエラーになる。ツールのtype値はアンダースコア(advisor_20260301)、ヘッダーはハイフン(advisor-tool-2026-03-01)と表記が異なる点も紛らわしい。
2. advisortoolresultの位置
会話履歴を自前で管理している場合、advisor_tool_result は必ず server_tool_use の直後に配置する必要がある。順序がずれると会話コンテキストが壊れる。ただし通常のSDK利用では、レスポンスの content をそのまま会話履歴に追加すれば自動的に正しい順序になる。
3. ストリーミング時のservertooluse検出
ストリーミングを使う場合、content_block_start イベントで type を判定する必要がある:
const stream = client.messages.stream({
model: "claude-sonnet-4-6",
max_tokens: 4096,
tools: [advisorTool, ...yourCustomTools],
messages,
betas: ["advisor-tool-2026-03-01"],
});
for await (const event of stream) {
if (event.type === "content_block_start") {
if (event.content_block.type === "server_tool_use") {
// advisor呼び出し中 — ユーザーにプログレス表示
console.log("Consulting advisor...");
}
} else if (event.type === "content_block_delta") {
// テキスト差分をストリーム出力
}
}
4. レイテンシー増加 advisor呼び出し1回あたり2〜5秒の追加レイテンシーが発生する。ユーザー向けアプリケーションでは、advisor呼び出し中であることを示すプログレス表示が事実上必須だ。
5. clear_thinking制約 advisorがextended thinkingを使用した場合、thinking部分はexecutorに渡されない仕様になっている。advisorの重要な判断根拠がthinkingブロックにしか含まれていないと、executorがそれを活用できない。advisorのシステムプロンプトで「重要な情報はテキスト出力に含めること」と明示的に指示するのが有効だ。
まとめ — いつadvisorを使い、いつ使わないか
advisorが有効なケース:
- エージェントループで複数ステップの判断が必要なタスク
- コード生成・レビュー・リファクタリング
- 情報収集と分析を伴う複雑な推論
advisor不要なケース:
- 単発の質問応答やテンプレート的な生成
- レイテンシーがクリティカルなリアルタイム処理(advisor呼び出しで2〜5秒追加される)
- タスクが十分に単純で、Sonnet/Haiku単体で品質が足りている場合
Advisor Toolは「安いモデルか賢いモデルか」という二択を過去のものにする。Sonnet executorが日常の処理を高速にさばき、本当に判断が必要な局面だけOpus advisorに相談する——この二層構成により、Haiku+Opus構成ではSonnet単体比でコスト最大85%削減とOpus級品質の両立が現実的になった。
ベータ段階ではあるためAPI仕様の変更可能性には留意が必要だが、max_uses によるコスト制御と advisor_tool_result の正しいハンドリングさえ押さえれば、本番投入のハードルは低い。2026年4月16日リリースのOpus 4.7でadvisor性能もさらに向上しているので、エージェント系ワークロードを運用しているなら、今すぐ検証を始める価値がある。
参考リンク:
