メインコンテンツへスキップ
ブログ一覧

Claude Advisor Tool実践ガイド — Sonnet×Opus二層構成でコスト80%削減しつつOpus級品質を実現する実装パターン

(更新: 2026年04月18日)
Claude APIAdvisor Toolコスト最適化AIエージェントTypeScript

「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" の指定だ。

typescript
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コールを行う必要はない。

typescript
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_useadvisor_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 フィールドを活用する:

typescript
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回/リクエストが推奨値だ。

typescript
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 が返される:

typescript
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 を判定する必要がある:

typescript
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性能もさらに向上しているので、エージェント系ワークロードを運用しているなら、今すぐ検証を始める価値がある。


参考リンク:

もっと読む他の技術記事も読む