Claude の Advisor tool を活用して性能とコストのバランスを最適化する
Claude に新たに追加された advisor tool を使用すると、通常のタスクは軽量モデルに任せつつ、必要に応じて高性能モデルに相談することで、性能とコストのバランスを最適化できます。この記事では Claude Code 内で advisor tool を活用する方法について紹介します。
コーディングエージェントを使用した開発はもはや珍しいものではなくなってきましたが、それに伴うコストの話も欠かすことはできません。性能の高い AI モデルは、より複雑なタスクをこなすことができますが、その分コストも高くなります。簡単なタスクには Haiku や Sonnet といった軽量モデルを使用し、複雑なタスクには Opus といった高性能モデルを使用するという使い方が理想的ですが、どのタスクをどのモデルに割り当てるかを設計すること自体が複雑な課題となります。
Claude に新たに追加された Advisor tool は、性能とコストのバランスに関する課題を解決します。これは通常のタスクの実行は Haiku や Sonnet といった軽量モデルに任せつつ、実行者が解決できないような複雑な問題に直面したときに、Opus といった高性能モデルに「相談」して解決策を得ることができる機能です。Opus は実行者から相談を受け取ると、共有コンテキストにアクセスしたうえで計画・修正・停止シグナルを返すことができます。これは大規模なエージェントのオーケストレーションにおいてサブエージェントにタスクを委任するという発想を逆転させたものです。高性能モデルはそれが必要な場合のみに呼び出されるため、コストを抑えつつも性能を最大限に活用できます。
Claude Code においても v2.1.101 以降で /advisor コマンドが利用可能になっています。このコマンドを使用することで Claude Code 内で Advisor tool を活用できます。この記事では Claude Code における Advisor tool をどのように活用できるかについて紹介します。
Claude Code での Advisor tool を試してみる
Claude Code 内で Advisor tool を試すには、/advisor コマンドを使用します。このコマンドを実行すると、どのモデルを advisor として使用するか選択肢が表示されます。ここでは Opus を選択しましょう。通常のタスク実行には Sonnet を使用しつつ、必要に応じて Opus に相談する形になります。

advisor を選択すると、Claude Code は advisor ツールを使用できるようになります。Claude Code 自身に advisor ツールについての説明を求めたところ、以下のような使用上のルールが定められているとのことでした。
- 実質的な作業の前に呼ぶ — ファイルを読む程度の「調査」は先にやってOK。書く・編集する・答えを宣言する前が最適
- 完了前に成果物を保存する — advisor の呼び出し中にセッションが終わっても成果物が残るように
- アドバイスを真剣に受け取る — アドバイスに従ったが実証的に失敗した場合、または手元の証拠と矛盾する場合は、再度 advisor を呼んで矛盾を解消する
- 長いタスクでは複数回呼ぶ — アプローチ確定前に1回、完了宣言前に1回が目安
advisor ツールを有効にした状態で、通常通りタスクを実行してみましょう。ここでは Card.svelte コンポーネントに 3 つの責務が混在しているので、これをリファクタリングして単一責務の原則に従うように改善するというタスクを実行してみます。
Card.svelte には 3 つの独立した onMount に以下が詰め込まれています
- コードブロックコピーボタン挿入
- 画像モーダル処理
- baseline-status 読み込み
Card.svelte に責務が混在する問題を修正してください。このタスクを実行すると、実装計画を立てるために Opus に相談している様子がわかります。ここで advisor ツールが呼び出されています。

advisor ツールには引数がなく、単に呼び出すだけです。advisor ツールを呼び出すと会話履歴全体が自動的に転送されるため、Opus はこれまでのやりとりを踏まえた上で、実装計画に対してフィードバックを返してくれます。実行者である Sonnet がこのタスクを依頼された段階では、以下のように思考していたようです(日本語に翻訳しています)。
構造を理解しました。既存のactionsディレクトリはありません。2つの複雑なonMountブロックに対してSvelteアクションを作成します:
app/src/lib/actions/codeBlockCopy.ts— コードブロックのコピーボタン用Svelteアクション
app/src/lib/actions/imageModal.ts— 画像クリックで拡大表示するモーダル用Svelteアクションbaseline-statusのインポートは単純な1行なので、Card.svelteにそのまま残します。 Svelteアクションについて:
第1引数として適用先のノードを受け取る
クリーンアップ用の
{ destroy() }オブジェクトをオプションで返すコードブロックアクションは指定ノード内の
pre要素をクエリする画像モーダルアクションは指定ノード内の
img要素をクエリする 現在のコードをより詳しく確認すると:コードブロック:
document.querySelectorAll("pre")— グローバルにクエリ画像:
document.querySelectorAll("#contents img")—#contents内をクエリ また、$paraglide/messagesからのmインポートはコードブロックのコピーアクションで使用されています。対応方法は2つあります:
- アクションファイル内で
mを直接インポートする- アクションへのパラメータとして渡す アクションをシンプルに保つため、直接インポートする方針にします。
Opus はこれまでの会話履歴を踏まえた上で、実装計画に対して以下のようなフィードバックを返してくれます。Opus の回答は advisor_tool_result ブロックとして実行者に返されます。Opus の思考プロセスは結果を返す間に破棄されるため、結果だけが返される形になります。
計画は妥当です。実装時に押さえるべき3点:
$paraglide/messagesを.tsアクションファイルで使う場合 —.svelteコンポーネント外でこのインポートが解決されるか確認が必要。SvelteKitのエイリアスやViteプラグインの問題で解決されない場合は、mをアクション内でインポートする代わりに、アクションの第2引数として{ copyLabel: string, copiedLabel: string }を渡す方が安全。パラメータ化を推奨。クエリはdocumentではなくnodeにスコープする — 現在のコードは
document.querySelectorAll("pre")やdocument.querySelectorAll("#contents img")でグローバルにクエリしている。アクション内では代わりにnode.querySelectorAll(...)を使うこと。これがリファクタリングの本質であり、誤ってグローバルクエリを残さないよう注意。
codeBlockCopyのクリーンアップ — 現在のコードはinsertAdjacentElementでpreの兄弟要素としてボタンやポップアップを挿入している。destroy関数ではイベントリスナーだけでなく、挿入した要素も削除する必要がある。そうしないとHMRやSvelteKitのナビゲーション時に古いコピーボタンが残留する可能性がある。セットアップ時に配列で追跡し、destroy時に削除すること。
baseline-statusの1行はCard.svelteにインラインのまま残す — 1行のonMountを切り出しても冗長なだけ。
Sonnet が思考していた時には見落としていた以下の 3 つのリスクを Opus が指摘してくれています。
.tsファイルでの$paraglideエイリアス解決の不確実性 → パラメータ渡しに変更documentグローバルクエリ →node.querySelectorに変更destroyでの DOM 要素削除漏れ →inserted配列で追跡して削除
まとめ
- Claude の Advisor tool を活用することで、性能とコストのバランスを最適化できる。これは通常のタスクは軽量モデルに任せつつ、必要に応じて高性能モデルに相談するという使い方ができる設計です
- Claude Code 内で
/advisorコマンドを使用することで、advisorツールを有効にする。これにより、実行者がタスクを実行する際に、必要に応じて高性能モデルに相談してフィードバックを得ることができるようになる - Claude Code において Advisor tool を活用する際のルールとしては、実質的な作業の前に呼ぶこと、完了前に成果物を保存すること、アドバイスを真剣に受け取ること、長いタスクでは複数回呼ぶことが挙げられる
advisorツール自体には引数はなく、呼び出すだけで会話履歴全体が自動的に転送されるため、Opus はこれまでのやりとりを踏まえた上で、実装計画に対してフィードバックを返してくれる



