図解ウォークスルー · スクリーンショット 13 枚
Claude Code の利用上限：1 タスクあたりのコストを下げる
プランの残量が想定より早く消えるとき、最も効くレバーは「どのモデルに作業させるか」です。この図解は、Sonnet 4.6 を実行役に固定し、強い判断が必要なときだけ Opus 4.6 を呼ぶ実際のセッションを追います。
約 5 分 · 13 ステップ、各ステップは元動画の該当秒へリンク
短くまとめると
プランを削るのは、打ち込んだプロンプトの数よりも「高いターン」です。この動画では、制作者が Sonnet の実行役にアドバイザーモデルを接続します。/advisor は Opus 4.6 をサーバー側で動く相談役に設定し、/model opusplan は「同時に 1 モデルだけ」という以前のやり方です。動画で解説される SWE-bench Multilingual のチャートでは、Sonnet 4.6 High に Opus アドバイザーを付けた構成が 74.8%・agentic タスクあたり $0.96、Sonnet 4.6 High 単体が 72.1%・$1.09 となっています。同じ分割は Message API でも使え、Anthropic の Monitor Tool はバックグラウンドで問題を監視し、発火したときだけトークンを消費します。
元動画について
本ページのスクリーンショットはすべて「Software Engineer Meets AI」の 3 分間の Claude Code アドバイザー解説動画から取得しています。VS Code 上の alldevneeds リポジトリで、Claude Code v2.1.104・Sonnet 4.6・Claude Pro プランの実セッションです。
スクリーンショットは出典を明示して使用し、各ステップは元動画の該当秒へディープリンクしています。モデル価格・ベンチマーク数値・コマンド出力は動画画面そのものの内容です。実際の判断は Anthropic の最新ドキュメントで確認してください。
3 つのレバー、1 つのセッション
コストを削る前に、どの操作が何を決めるのかを押さえます。
- 1
戦略は一行で言える
冒頭のカードが取引の全体を語ります。Opus をアドバイザーに、Sonnet か Haiku を実行役に据えれば、Opus 並みの知能をわずかなコストで得られる。以降の動画は、その一行を実際のセッションに配線していく過程です。
Opus 並みの知能を、必要なときだけ支払う。0:08 から視聴 - 2
Sonnet 4.6 がコンテキスト 0% で開始
セッションは Claude Pro プランの Sonnet 4.6 で始まり、まだ何も送っていないためステータス行は ctx 0% です。Sonnet は実行役なのでターンを処理し、アドバイザーは温存される側のモデルです。
VS Code の Claude Code v2.1.104：Sonnet 4.6、Claude Pro、ctx 0%。0:16 から視聴 - 3
請求額を動かす 4 つのコマンド
/model と入力するとコマンド一覧が開きます。コストに関わるのは 4 つです。/model は AI モデルの設定（この時点では Sonnet 4.6 と表示）、/effort はモデルの effort レベル、/advisor はアドバイザーツールの設定、/status はバージョン・モデル・アカウント・API 接続の状態を示します。
同じショートカット一覧に、モデルと effort とアドバイザーが並ぶ。0:49 から視聴
アドバイザーを組み込む
スラッシュコマンド、選択パネル、確認の 3 手で 1 分未満。
- 4
アドバイザーコマンドを打つ
/advisor が入口です。インラインの説明が、このページ全体の前提となるルールを示します。タスクの重要な局面で、より強いモデルに助言を求める。強いモデルは毎ターン呼ばれるわけではありません。
「タスクの重要な局面で、より強いモデルに助言を求めるようアドバイザーツールを設定する」。0:24 から視聴 - 5
どのモデルに助言させるか
パネルはコストについて率直です。アドバイザーはサーバー側で動作し、追加のトークンを消費する。Sonnet をメインモデル、Opus をアドバイザーとして組み合わせると、使用量を抑えつつ Opus に近い性能が得られる。選択肢は Opus 4.6、Sonnet 4.6、No advisor の 3 つで、変更するまでは No advisor にチェックが入っています。
3 つの選択肢と、アドバイザーはトークンを余分に使うという注意書き。0:32 から視聴 - 6
アドバイザーは Opus 4.6 に確定
選択を確定すると、コマンドの下に Advisor set to Opus 4.6 の行が残ります。隣の入力欄はまだ空で、ステータス行も ctx 0% のまま。まだ何も消費しておらず、実行役も Sonnet 4.6 のままです。
「Advisor set to Opus 4.6」——最初のプロンプトの前に分割は準備完了。0:40 から視聴
アドバイザーと旧来の Opus plan
強いモデルを、毎ターン支払わずに使う 2 つの方法。
- 7
以前のやり方が従っていたルール
この大きな文字が、アドバイザーが置き換える習慣を語ります。計画は Opus、実行は Sonnet。同時に 1 モデルだけを手動で切り替える方法で、次のフレームがその違いを明確にします。
計画 → Opus、実行 → Sonnet。考えるのは強いモデル、打ち込むのは安いモデル。0:47 から視聴 - 8
2 つの構成を並べて見る
2 つの結果が同じターミナルに並びます。/advisor は Advisor set to Opus 4.6 と報告し、/model opusplan は Set model to Opus 4.6 in plan mode, else Sonnet 4.6 と報告します。動画自身の説明では、アドバイザー構成は実行役がタスク途中でアドバイザーを呼べ、同じコンテキストを共有します。一方 Opus plan は同時に 1 モデルだけです。
2 つのコマンド結果、問いは 1 つ。同じ結果に、どちらがトークンを使わないか。0:56 から視聴
分割はどう動くのか
共有コンテキスト 1 つ、モデル 2 つ、その間のツール呼び出し。
- 9
実行役は毎ターン、アドバイザーはオンデマンド
図が役割を具体化します。Executor は Sonnet で、メインループの毎ターン実行されます。Advisor は Opus で、ツール呼び出しを通じてオンデマンドに呼ばれます。アドバイザーはユーザー向けの出力を一切出さず、助言を返すだけです。
メインループに Sonnet、ツール呼び出しの奥に Opus。1:12 から視聴 - 10
2 つのモデルが 1 つのコンテキストを共有する理由
丸で囲まれた枠がこの機能の要点です。Executor は会話・ツール・履歴からなる Shared context を読み書きし、Advisor は同じコンテキストを確認して助言を書き戻します。だから引き継ぎのたびにタスクを説明し直す必要がありません。
動画が丸で囲んだ共有コンテキスト。アドバイザーは実行役と同じものを見ています。1:28 から視聴
動画のチャートが示すもの
スコアは上がり、タスクあたりのコストは下がる——API でも同じ形。
- 11
スコアは上げて、タスクあたりのコストは下げる
これが動画に登場する SWE-bench Multilingual のチャートで、横軸は agentic タスクあたりのコストです。Sonnet 4.6 High に Opus アドバイザーを付けると 74.8%・$0.96、Sonnet 4.6 High 単体は 72.1%・$1.09。制作者はこれを「約 3 ポイント向上し、約 12% 安い」と読み、ナレーションでもそう述べています。
74.8%・$0.96 対 72.1%・$1.09——動画のチャートであり、当サイトの実測ではありません。2:00 から視聴 - 12
Message API でも同じ分割
この戦略は Claude Code 専用ではありません。Message API の例では実行役が model: “claude-sonnet-4-6” で、アドバイザーはツール項目として現れます。type は “advisor_20260301”、name は “advisor”、model は “claude-opus-4-6”、max_uses は 3。その下のコメントがメーターを見る理由です。アドバイザーのトークンは usage ブロックで別途報告されます。
アドバイザーのトークンは別途報告——usage ブロックで見えるままに。2:20 から視聴
メーターを見張る
バックグラウンドの監視もトークンを消費します。
- 13
監視役も無料ではない
動画は Anthropic の Monitor Tool のスライドで締めくくられます。バックグラウンドで何かを監視し、変化したときに主会話を止めずに反応します。比較表はコストについて率直です。Monitor Tool は発火時にトークンを消費し、/loop は実行のたびに消費します。
Monitor Tool 対 /loop。発火時に使うか、毎回使うか。2:32 から視聴