Claude Codeで全部Opusは溶ける|/modelと/effort切替でトークンを抑える

はじめに

副業のアイデアを検討していたときの話です。自分がよく分かっていない領域だったので、「未知のことだから一番性能のいいモデルにやらせよう」と思い、検討も計画も作業も全部Opusに任せました。

結果、2日でほぼ週次リミットを食い尽くしました。「今週もう何もできない」と落ち込んだ翌日にリセットが入って命拾いしたのですが、これがきっかけで自分がモデル選びをまったく意識していなかったことに気づきました。

今回は、/model/effortを使ってトークン消費を抑える考え方を、実際にどう切り替えているかも含めて整理します。

/model|基本はSonnet、Opusは指針がはっきりしている場面だけ

今の方針は、メインの作業はSonnetを使うこと。コードを書く、修正する、確認するといった大半の作業はSonnetで十分です。

Opusに切り替えるのは、設計判断や影響範囲が広い計画など「これは検討作業だ」と自分でも分かっている場面に限っています。新しい仕組みの方針を決めるとき、複雑な不具合の原因を一から洗うとき、といった場面です。Opusはトークン消費が激しいと理解しているからこそ、ここだけ絞って使うようにしています。

あの「全部Opus」事件の後は、検討作業以外でOpusを使うことはほぼなくなりました。週次リミットの消費ペースがまったく違います。

一方で、Haikuへの切り替えは正直まだ上手くできていません。理由は、スキルやカスタムコマンドのように作業の流れがあらかじめ決まっている場面なら「これは単純作業だからHaiku」と判断できるのですが、普通にチャットでやり取りしているときは次にAIが何をするのか自分でも分からないことが多いからです。Opusのように「これは検討作業」という分かりやすい合図がチャットの中にはなく、Haikuが適切かどうかの判断自体が難しいというのが実情です。

/effort|考える深さを作業に合わせる

/effortは考える深さのレベルを調整するコマンドです。単純な修正なのに深く考えさせてしまうと、その分だけ余計にトークンと時間を使います。文字の打ち間違いの修正や、決まったパターンに沿った軽い変更であれば、考える深さを下げて早く返してもらった方が効率がいいです。

逆に、複雑な不具合の原因調査や、前提が絡み合っている設計の検討では、考える深さを上げた方が結果的に手戻りが減ります。浅く考えた結果が外れて何度もやり直すより、最初から深く考えてもらう方がトータルのトークン消費は少なくなることが多いです。

自分はまだ/effortを使ったことがないのですが、/modelと同じ「作業の重さに応じて設定を変える」という考え方がそのまま当てはまるはずなので、次に試してみようと思っている設定です。

/contextで消費の変化を確認する

前回の記事で紹介した/contextは、モデルやeffortの切り替えが実際に効いているかを確認するときにも使えます。同じような作業を続けているのに消費のペースが速い、と感じたら、その作業をOpusでやっていないか、深く考えさせすぎていないかを見直すきっかけになります。

まとめ

「未知の作業だから一番強いモデルに任せよう」という発想は、一見正しそうに見えて、週次リミットを2日で溶かすという結果につながりました。基本はSonnet、検討作業だけOpus、という切り分けに変えてからは消費のペースが安定しています。

Haikuへの切り替えはまだ上手くできていませんし、/effortも使ったことがありません。全部を最初から完璧に使い分けられているわけではないですが、「全部最強設定」をやめるだけでも体感できる差はありました。残りは今後の課題として、引き続き試していこうと思います。

最後まで読んでいただきありがとうございました。

追記|AIが自分でモデルを切り替えてくれるわけではない

「チャットのやり取りの中で、作業内容に応じてAIが自分でモデルを選んでくれたら楽なのに」と思って調べたのですが、これはできない仕様でした。/modelはあくまで自分で実行するコマンドで、Claude自身が会話の流れの中で「これは検討作業だからOpusにしよう」と判断して切り替えることはありません。

ただ、近い効果を出す方法はあります。/agentsで作るサブエージェントには、それぞれ個別のモデルを固定して設定できます。「設計レビュー専用エージェントはOpus固定」「単純な確認作業専用エージェントはHaiku固定」のように役割ごとにモデルを決めておき、本流の会話から該当する作業をそのエージェントに振る、という形です。

会話の中でAIが自分の頭脳を動的に切り替えるのではなく、役割ごとにモデルを固定したエージェントを用意して適材適所に振り分ける。Haikuの切り替えタイミングが分からないという今回の悩みは、この仕組みで解決できそうなので、次に試してみようと思います。