Claude Codeはモデル選びで化ける｜Opus 4.7で規約を整備しSonnet 4.6で量産する2フェーズ運用

2026年5月16日

みなさん、Claude Codeでこんなことありませんか？

Opus 4.7をずっと使ってたら月のクレジットがゴリゴリ減って焦った、とか。逆にSonnet 4.6に切り替えたら、なんかブロック構造が崩れた記事を量産しちゃった、とか。私はどっちもやらかしました（笑）

最近わかってきたのは、Claude Codeはモデル単体じゃなくて、「モデル選択 × 規約整備」の組み合わせで化けるっていうことです。

やまと

副業3案件を平日夜2〜3時間で回してる私が、半年かけて辿り着いた使い分けの話です。Anthropic公式の数字と、自分のリポジトリで起きた事故をベースに書きます。

結論から書いていきます。

結論：Opus 4.7で規約を作り、Sonnet 4.6で量産する2フェーズ運用

📌 私が辿り着いたシンプルな答え

Opus 4.7とSonnet 4.6は「上位下位」じゃなく、フェーズ別の役割分担で使うほうが効きます。

Opus 4.7（規約整備フェーズ）：CLAUDE.md / スキル / 検査スクリプトを設計、AIにガードレールを敷く
Sonnet 4.6（量産フェーズ）：その規約に従って日々のコード・記事・デバッグを高速で回す
Haiku 4.5（サブエージェント）：定型処理に回して、メインモデルのトークンを温存

ここに辿り着いてから、月のクレジット消費が体感3〜4割減ったうえに、出力の精度はむしろ上がりました。なんでそうなるのか、順に書いていきます。

モデルを意識しないと起きる、地味に痛い2つのこと

まず私がやらかした失敗を、正直に2つ書きます。Claude Codeを触ったことがある人なら、片方は心当たりあるんじゃないでしょうか。

失敗①：Opus常用で月のクレジットが想定の倍溶けた

Opus 4.7はAPI料金で 入力 $5 / 出力 $25（100万トークンあたり）。Sonnet 4.6は 入力 $3 / 出力 $15 です。出力料金の比だと Opusが約1.67倍。

「1.67倍くらい大したことないでしょ」と思ってたんですけど、現実にはセッションが長引くほど比は効いてきます。長文ログを読ませたり、何時間も同じ案件を掘ったりすると、入出力両方が積み上がっていくので。

Anthropicの公式ドキュメントによると、開発者1人あたりの平均は 稼働日1日あたり約$13、月150〜250ドル、ユーザーの90%は1日$30以下に収まるとのこと。私の最初の月は$30/日のラインを軽く超えてました。Opusをずっとオートで使ってたからです。

やまと

「副業の収益がクレジット代で消える」みたいなしょうもない事故、本気で起きるんですよ。これだけは避けたい。

失敗②：Sonnet常用でSWELLブロック記事の構造が崩れた

逆方向の事故もあります。「節約しよ」と全部Sonnetに切り替えた時期があって、その時はGutenbergブロックコメント（wp:loos/...）の属性が微妙に間違った状態でDBに投入される事故が地味に増えました。

原因は明確で、Sonnet 4.6が劣ってるからじゃなく、私の側でブロック生成のルールを明文化してなかったからです。「既存記事から雛形をコピーして差分修正する」というシンプルな規約を作る前は、Opusの推論力でなんとなく正しく書けてただけだった、ということです。

ここで気づきました。規約がないままモデルだけ下げると、AIは”らしく書ける範囲”でしか書けない。逆に言うと、規約があれば下位モデルでも崩さない、ということです。

Claude 各モデルの公式仕様を整理しておく

使い分けの前に、まず公式仕様を整理しておきます。これは2026年5月時点のAnthropic公式ドキュメントから引用した数字で、私の主観は入ってません。

項目	Opus 4.7	Sonnet 4.6	Haiku 4.5
Model ID	claude-opus-4-7	claude-sonnet-4-6	claude-haiku-4-5
コンテキスト窓	1M tokens	1M tokens	200K tokens
最大出力	128K tokens	64K tokens	64K tokens
入力料金（1Mトークン）	$5	$3	$1
出力料金（1Mトークン）	$25	$15	$5
位置づけ（公式）	複雑な推論・エージェント型コーディング	速度と知性の最適バランス	準フロンティア級の最速
応答速度	普通	速い	最速
知識カットオフ	2026年1月	2025年8月	2025年2月

出典: Anthropic公式 Models overview

注目してほしいのが 「位置づけ」の行 です。Anthropic自身が「Opus = 複雑な推論用」「Sonnet = 速度と知性の最適バランス」と書いてるんですよね。Sonnetは劣化版Opusじゃなく、用途が違うモデルだと公式に明言されています。

料金の差は出力で $25 vs $15、Opusが1.67倍。コンテキスト窓は両方とも1Mトークン同等です。つまり「長い文脈を扱える能力」では差がないので、本当に深い推論が必要なフェーズだけOpusを使うのが合理的になります。

Opus 4.7を投下すべきフェーズ：規約とガードレールを作る

結論セクションで書いた「規約整備フェーズ」とは、具体的に何をするのか。私のリポジトリで言うと、Opus 4.7に集中投下するのは下の3つです。

CLAUDE.md（プロジェクト憲法）の設計・更新
カスタムスキルの新規作成（記事生成・装飾ルール・SEOチェックなど）
検査スクリプト（コミット前にAIの出力が規約を破ってないか自動チェック）

例として、私のしごとえらびブログでは、AIが過去にアフィリエイトリンクのURLを捏造して記事に貼っちゃう事故がありました。よくある「A8.netの正規パラメータを4ブロック構造で書けない」ってやつです。

これを再発防止するために scripts/check-affiliate-urls.sh という検査スクリプトをOpus 4.7で設計しました。「A8.netの正規mat IDは XXXXXX+XXXXXX+XXXX+XXXXXX の4ブロック必須」「a8ejpredirect= パラメータは本物には含まれない」みたいなルールをコード化して、コミット時に違反があれば exit 1 で止まるようにしてあります。

ガードレールはコードに落とせば、後から下位モデルが触っても破られない。これがOpus 4.7に投資する一番の理由です。

やまと

「未来の自分への投資」ってカッコつけすぎですけど、実際そういう感覚です。今ここでOpusで丁寧に規約を組んでおけば、来週からの量産はSonnetで安心して回せます。

opusplan という公式の使い分けモード

もうひとつ知っておいてほしいのが、Claude Codeに opusplan という公式のハイブリッドモードがあること。

セッション中に /model opusplan と打つと、Plan Mode（設計フェーズ）ではOpus、実装フェーズに入ったらSonnetに自動で切り替わる動きをしてくれます。私が手動でやってる「設計はOpus、コードはSonnet」をそのまま自動化してくれる感じですね。

これはAnthropicが公式ドキュメントのModel configurationページで「Opusの推論力とSonnetの実行効率の良いとこ取り」と明記している運用パターンです。フェーズ別運用は私が思いついたんじゃなく、Anthropic自身が推している方法なんですよ。

Sonnet 4.6で十分回せるフェーズ：規約に従って量産する

規約が整ったら、ここから先はSonnet 4.6でほとんど困らなくなります。私が実際にSonnetで回している作業はざっとこんな感じです。

SWELLブロックを使った記事の 下書き生成（雛形コピーのルールが効くから崩れない）
既存記事への 装飾追加（マーカー位置・密度ルールが効くから過剰装飾にならない）
AIOSEOの meta description・内部リンク補完（評価4項目の数値ルールが効く）
テストファースト or 仕様書ベースの 機能実装
WordPressコンテナの 定型デバッグ（プラグイン衝突・キャッシュ問題など）

Anthropic公式のコスト管理ページでも「Sonnet handles most coding tasks well and costs less than Opus. Reserve Opus for complex architectural decisions or multi-step reasoning.（Sonnetはほとんどのコーディングタスクをこなせて、Opusより安い。Opusは複雑な設計判断や多段推論にだけ取っておけ）」と明言されています。

私の感覚も同じです。Sonnet 4.6で困るのは 「初めての構造を設計する瞬間」 だけで、それ以外の 「既に決まった型に流し込む作業」 ならほぼ気になりません。

やまと

ソフトウェアエンジニアのキャリアで言うところの「設計はシニアが、実装はジュニアが」みたいな分業に近いかもしれません。AIにも同じ役割分担を持ち込むイメージです。

Haiku 4.5はサブエージェントの仕事

3つ目のモデル、Haiku 4.5の使いどころも書いておきます。これは サブエージェント専用と割り切るのがおすすめです。

Haiku 4.5は出力料金 $5/M でSonnetの 3分の1、Opusの 5分の1。コンテキスト窓も200KとSonnet/Opusより狭いので、メインのコーディング用には向かないんですけど、「grep結果から特定の行を抽出するだけ」「テスト出力を整形するだけ」みたいな 「短く・単機能」 なサブエージェント仕事には十分です。

Claude Codeでは CLAUDE_CODE_SUBAGENT_MODEL=haiku という環境変数で、サブエージェントだけ切り替えられます。これでメインのSonnet/Opusのトークンを温存できる仕組みです。

意思決定フロー：今のタスクはどっち？

朝の作業開始時に /model で迷う時間自体がもったいないので、私は判断基準を1枚にしてます。

真ん中の opusplan ルートが私の主力です。設計フェーズだけOpusで深く考えて、実装に入ったら自動でSonnetに渡してくれる。手動切替の判断疲れがゼロになるので、夜の作業時間が削られないんですよ。

無自覚運用 vs フェーズ別運用：何が変わったか

具体的に「フェーズ別運用に変えて何が変わったか」を、ビフォーアフター形式でまとめます。

観点	As-Is（モデル無自覚運用）	To-Be（フェーズ別運用）
主力モデル	Opusをほぼ常用	Sonnet中心、要所だけOpus
月のコスト	$30/日を頻繁に超える	$10〜$20/日のレンジに収束
出力品質	規約がないので生成のたびにブレる	規約に沿うので再現性が出る
ガードレール	頭の中にしかない	CLAUDE.md・スキル・検査スクリプトに分散
切替コスト	毎回 `/model` で迷う	`opusplan`で自動化
レビュー時間	出力をいちいち精査	規約違反は検査スクリプトが先に弾く

表のなかで一番効いたのは 「ガードレールが頭の中にしかない」→「コードに分散」 の部分です。頭の中のルールはAIに伝わらないし、自分も忘れます。CLAUDE.md・スキル・検査スクリプトに分散しておけば、どのモデルが触っても同じ品質になります。

この運用が合う人／合わない人

「全員にこの運用がおすすめ」とは正直思ってません。合う人と合わない人を両方書きます。

👍 合う人

同じ作業（記事生成・ブログ運用・特定の実装パターン）を何度も繰り返す人
個人 or 小チームで運用していて、規約を自分で書ける裁量がある人
月のコストを意識する必要があるフリーランス・副業勢

👎 合わない人

毎回違うリサーチタスク・調査が中心で、繰り返しが少ない人（規約を書くコストが回収できない）
チームの規約整備権限がない人（自分のスキル・ローカルmemoryでカバーするしかない）
Maxプラン契約で「Opusを使い倒すこと自体」が元を取る条件になっている人

3つ目のMaxプランの話だけ補足すると、Claude公式の Default model setting ではMaxとTeam Premiumのデフォルトが Opus 4.7、Pro と Anthropic API のデフォルトは Sonnet 4.6 になってます。Maxユーザーは「Opusを使うほど元を取れる」設計なので、フェーズ別運用の節約メリットは薄まります。それでもガードレール整備の意味は残るので、Maxユーザーでも「規約整備の章」だけは応用できると思います。

よくある質問

Q1. モデル切替の一番ラクなやり方は？: セッション中なら /model と打つと選択画面が開きます。直接指定するなら /model sonnet /model opus /model opusplan のように alias を渡せばOK。起動時に固定したい場合は claude --model sonnet や ANTHROPIC_MODEL=sonnet でもいけます。私は /model opusplan をデフォルトにして、必要な時だけ /model sonnet で純粋なSonnetに落とすことが多いです。
Q2. Haiku 4.5って、メインで使っちゃダメ？: ダメじゃないんですが、メインのコーディング用としてはコンテキスト200Kがネックになりやすいです。Sonnet/Opusの1Mに対して5分の1の窓なので、長いCLAUDE.mdとプロジェクト全体を読みながら作業する用途には不向き。一方、grep結果の整形やテスト出力のフィルタみたいな 「短く・単機能」 なサブエージェント仕事には最適です。CLAUDE_CODE_SUBAGENT_MODEL=haiku でサブエージェントだけ切替えるのが現実解です。
Q3. opusplanって、つまり何が嬉しいの？: 「Plan Modeに入ったらOpus、抜けたらSonnet」を自動でやってくれます。Plan Modeはコードを書かずに調査・設計だけする読み取り中心のフェーズなので、ここでOpusの推論力が活きる。実装に移ったら作業の8割は型通りなのでSonnetで十分です。手動の /model 切替を1回減らせる のが地味に大きくて、1日に5回切り替えてた人なら、それだけで判断疲れが消えます。
Q4. 既存プロジェクトに規約を入れる時、何から手をつける？: 私の経験上、最初に書くべきは 「禁止事項リスト」 です。「これだけはやらないで」をCLAUDE.mdに5〜10行書くだけで、量産フェーズの事故率が一気に下がります。逆に「こう書け」型のガイドラインは、書きすぎるとAIが守れなくなるので最初は最小限で。検査スクリプトは余力ができてから足せば間に合います。

まとめ：モデル選択は”運用設計”の話

長くなったので最後に振り返ります。Claude Codeで精度とコストを両立させる鍵は、モデル単体じゃなくて 「規約整備フェーズと量産フェーズの分業」 でした。

Opus 4.7 → CLAUDE.md・スキル・検査スクリプトの設計
Sonnet 4.6 → 規約に従って日々の量産
Haiku 4.5 → サブエージェントで定型処理
切替判断は opusplan に任せれば自動化できる

「モデルが弱いから出力が崩れる」と感じたとき、たいてい問題は 規約側にある ことが多いです。下位モデルでも崩さないだけのガードレールが整ってるか、自分のリポジトリを見直してみる価値はあると思います。

Claude Code の関連トピックは別の記事で深掘りしてるので、興味があれば合わせて読んでみてください。

あわせて読みたい

【3ヶ月の遠回り】Claude Code Desktopを試したら作業能率が爆あがりした話｜VS Codeとの使い分け Claude CodeをVS Codeのターミナルだけで3ヶ月使い続けた私が、MacにClaude Desktopを入れたら作業能率が爆上がりした体験。並列セッション・Plan→実装・定期実行の3機能、/sandboxの誤解、会社コードで使わなかった理由まで正直に書きました。

あわせて読みたい