Claudeの仕組みと使い方8選｜effort・OpusとSonnetの使い分け

Claudeを毎日使っていても、仕組みの部分って意外と知らないままだったりしますよね。しかも最近、モデルの構成そのものが大きく動いています。

今回は、調べていて「ほぉー」となったものを8つ集めました。モデルの構造から、指示の出し方まで。1つでも知らなかったら儲けものです。異論・追加も大歓迎です。

① 同じ前置きを繰り返すほど、安く速くなることがあります

これはAPIを使っている方向けですが、知らないと損しているやつです。

長い前提を毎回送っていると、そのぶん費用も待ち時間もかかりますよね。ところがプロンプトキャッシュという仕組みがあって、同じ前置きを繰り返す場合はキャッシュが効くんです。2回目以降は、その部分の読み込みが大幅に安く、速くなります。

ポイントは、変わらない部分を先に、変わる部分を後ろに置くこと。社内のルールや長い仕様書を毎回渡すような使い方をしているなら、順番を整えるだけで効いてきます。

② 「考えている時間」も、トークンを消費しています

これも仕組みを知ると納得するやつです。

Claudeには、答える前にじっくり考えさせるモードがありますよね。難しい設計判断のときに効くやつです。この考えている部分も、トークンとして計上されているんです。出力として表に出る文章だけでなく、思考の過程そのものにコストがかかっている。

だから、簡単な作業に深く考えさせるのはもったいないんですよね。定型作業は浅く、複雑な判断は深く。Claude Codeなら /effort で切り替えられます。この使い分けだけでも、上限に当たるまでの余裕がだいぶ変わります。

③ 高リスクな話題では、別のモデルが答えています

これ、気づいている方は少ないかもしれません。

いま一般提供されている最上位モデルには、安全対策が組み込まれているんです。サイバーセキュリティ・生物・化学・健康に関する危険なプロンプトだと判断されると、別のモデルからの応答にフォールバックする仕組みですね。

つまり、同じ画面で会話していても、話題によっては答えているモデルが変わっているということなんですよね。ちなみにこの安全機構が発動するのは、平均でセッション全体の5%未満とされています。

「なんか今日は答えの感じが違うな」と思ったとき、実際にモデルが違っていた可能性もあるわけです。

④ ベンチマークが「動くか」から「通るか」へ進化しています

これは技術者として、いちばん唸ったところです。

これまでコーディング能力の評価は、SWE-benchのように「バグを直せたか」が中心でした。動けば正解、という考え方ですね。そこに、FrontierCode Diamondというベンチマークが出てきたんです。こちらは、動くかどうかだけでなくプロジェクトにマージできる品質かどうかを評価します。

テストの品質。変更範囲の適切さ。既存コードへの影響。可読性。プロジェクトの作法に従っているか。……これ、人間のコードレビューでチェックする項目そのものですよね。

AIの評価軸が「実装できるか」から「チームに受け入れられるか」へ移っている。この変化、すごく象徴的だと思います。

⑤ Opusに切り替える判断ラインが、実はあります

「Sonnetでいいのか、Opusにすべきか」。ここ、迷いますよね。私も基準がないまま何となく選んでいました。

実務的な目安として、こういう考え方が紹介されています。Sonnetで2〜3往復しても収束しないと感じたら、Opusに切り替える。逆に言えば、それ以外でOpusを使う理由はほぼない、ということなんですよね。

最初から一番賢いモデルを選ぶのではなく、詰まってから上げる。この順番だと、上限に当たるまでの余裕がまったく変わってきます。

そしてClaude Codeには、さらに気の利いた仕組みがあるんです。

/model opusplan

設計や方針を決めるフェーズだけOpusを使って、実装や修正のフェーズはSonnetに切り替える。この使い分けをしてくれるモードですね。しかもモデルを切り替えても、会話履歴はそのまま引き継がれます。ここが地味にすごいところで、設計の文脈を持ったまま実装フェーズに入れるんですよね。

番外編：じゃあSonnetって、どういう位置づけなの

⑤の続きで、モデルの性格も整理しておきますね。

Sonnetは「Opusほどの知能は不要だけど、Haikuでは物足りない」領域の受け皿なんです。チャット画面のデフォルトになっているのも、この守備範囲の広さからですね。そして意外と知られていないのが、Sonnetは1Mトークンのコンテキストを標準単価で扱えること。大量のログや大きなドキュメントを読ませるとき、コンテキストの単価が跳ねる心配をしなくていいんです。

APIで業務を組む場合は、3層構造が定石とされています。Haikuで振り分け、Sonnetで本処理、重要な判断だけOpus。この構成にすると「全部Sonnet」より3〜4割コストが下がる、という試算もあるんですよね。

面白いのが、この3階層（最高性能・バランス型・軽量型）という構成は、他社も採用している業界標準だということ。つまりClaudeで使い分けを覚えると、他のモデルを選ぶときにもそのまま応用が効くんです。

⑥ 会話が長くなるほど高くなるのは、毎回読み直しているからです

ここからは、使い方の話ですね。

AIとの会話って、前の内容を覚えてくれているように見えますよね。でも仕組みとしては、記憶しているわけではないんです。新しいメッセージを送るたびに、それまでの会話全部を一緒に送り直しているんですよね。だから前の話が通じる。

つまり、会話が長くなるほど毎回送る量が増えて、そのぶん時間もコストもかかる。話題が変わったら履歴をリセットする、長くなったら圧縮する。これが効くのは、そういう理由なんです。

⑦ 長い資料は「先に貼って、あとで聞く」

これ、順番を変えるだけなので、すぐ試せます。

長いドキュメントについて質問するとき、多くの人は質問を先に書いてから資料を貼ると思うんです。でも、資料を先に置いて、質問を最後にする方が精度が上がるとされています。Anthropicの公式ガイドでも、長文データはプロンプトの上部に置くことが推奨されているんですよね。

理屈としては、質問が最後にあることで「何を探すか」を持ったまま全体を読み返せるから、ということかなと思います。順番を入れ替えるだけなので、コストゼロで試せるやつです。

⑧ 構造を付けて渡すと、解釈がぶれません

最後は、地味だけど効くものを。

長い指示を出すとき、文章をそのまま並べていませんか。タグで囲んで構造を付けると、解釈が安定するんです。前提はここ、守ってほしいルールはここ、参考にする例はここ。境目がはっきりするので、混ざらなくなるんですよね。

「この部分は例であって、指示ではない」といった区別も伝わりやすくなります。長いプロンプトを書く人ほど、効果を感じやすい工夫かなと思います。

番外編：実務で気をつけたいこと

いいことばかり書いてきたので、注意点も。

Fable 5とMythos 5には30日間のデータ保持が適用され、ゼロデータ保持では利用できませんでした。5.1からは対象顧客向けにデータ保持ゼロでの利用が提供されていますが、適用条件があります。機密性の高い案件では、契約条件を確認してから使うのが安心ですね。

高性能なモデルほど、こうした運用条件がついてくることがあります。性能だけでなく、扱いの条件もセットで見ておくと安心です。

RJCでも、Claudeを実務で使っています

Techチームでは、Claude Codeを使った開発の型を検証して、社内で共有しています。判断は人、たたき台はAI。この線引きを大切にしながら、うまくいった方法もいかなかった方法も持ち寄っているんですよね。

無料のオンラインセミナーでも、実務での使い方をお話ししています。参加費無料・顔出し不要・90分です。

よくいただくご質問

Q. どれから試すのがいいですか？
A. ⑦かなと思います。順番を入れ替えるだけなので、今日すぐできます。⑤の切り替え基準も、迷いが減るのでおすすめです。

Q. モデルの階層とか、覚える必要ありますか？
A. 全部は要らないです。ただ「同じ会話でも答えているモデルが変わることがある」は知っておくと、挙動の違いに戸惑わなくて済みます。

Q. 未経験でも、こういう使い方ができるようになりますか？
A. なります。ただ順番があって、まず自分の手でやってみることが大事なんです。自分でやったことがあるから、AIの答えの良し悪しが見えてくるんですよね。

Q. 話だけ聞くのはアリですか？
A. アリです。まず知るところから。

仕組みを知ると、使い方が変わります

今日の8つ、どれも難しい理屈ではないですよね。でも、仕組みを知っているかどうかで、指示の出し方が変わってきます。

なぜ会話が長いと重くなるのか。なぜ順番で精度が変わるのか。理由が分かると、応用が効くようになるんですよね。

みなさんの「これも知っておくといいよ」も、ぜひ教えてください。