Claude Opus 4.6・4.7・4.8 の違いと使い分け — 世代別の強みと移行時の注意点

結論｜3 世代の違いを 3 行で

先に要点だけ整理します。

1. 料金はどの世代も同じ。入力 100 万トークンあたり 5 ドル、出力 25 ドル。コストを理由に古い世代を選ぶ意味はありません
2. 4.6 から 4.7 への移行はコードの修正が要る。budget_tokens とサンプリング設定 (temperature など) が削除され、残っているとエラーになります
3. 4.7 から 4.8 への移行は修正不要。API の破壊的変更がなく、モデル ID を差し替えるだけで動きます

つまり、いま 4.7 を使っているなら 4.8 へ上げない理由はほとんどありません。4.6 に留まっている場合だけ、移行の作業が発生します。以下でその中身と、世代ごとに何が伸びたのかを整理します。

Claude Opus 4.6・4.7・4.8 をまず一望する (4.6 vs 4.7 vs 4.8)

Claude Opus は 2025 年 11 月の 4.5 から、4.6・4.7・4.8 と短い間隔で世代を重ねてきました。ポイントは、どの世代も通常利用の料金が据え置きだということです。入力は 100 万トークンあたり 5 ドル、出力は 25 ドルのまま、性能だけが上がっています。

この前提があるので、4.6・4.7・4.8 の話は「コストで世代を使い分ける」ものではありません。同じ値段なら、できることが多い新しい世代を選ぶのが基本です。そのうえで、何がどう伸びたのかを知っておくと、自社のタスクに合うかどうかを落ち着いて判断できます。

仕様の比較

まず数字で並べます。

料金・コンテキスト長・最大出力はどの世代も同じです。差が出るのは、effort の段階数、画像の扱い、キャッシュが効き始める長さ、そして後述する API の互換性です。

世代ごとの進化点

世代ごとの違いを押さえる

4.6 — 文脈と段取りを広げた土台の世代

4.6 は、Opus クラスで初めて 100 万トークンの文脈にベータ対応した世代です。長いコードベースや資料をまとめて読ませても、前半を忘れにくくなりました。あわせて Claude Code でエージェントチームを組めるようになり、API では文脈を自分で要約して長く走り続ける仕組みや、思考量を調整する effort 制御が入りました。

ベンチマークでも、エージェント型コーディングの Terminal-Bench 2.0 で当時の首位、分野横断の難問テストでもトップ水準と公表されています。派手さよりも、長く・安定して走るための土台を広げた世代という位置づけです。

API の面では、この世代がひとつの区切りになっています。思考量をトークン数で直接指定する budget_tokens が使える最後の Opus であり、temperature などのサンプリング設定も残っています。次の 4.7 でどちらも削除されるため、4.6 のまま止まっているコードは移行時に手を入れる必要があります。

4.7 — 難所のコードと視覚を伸ばした世代

4.7 は、4.6 の土台の上で、特に難しいソフトウェア工学のタスクを伸ばしました。指示追従の正確さが上がり、視覚も強くなって、長辺 2576 ピクセルまでの大きな画像を扱えるようになっています。Anthropic は、これまで人の細かな監督が必要だった難しい問題でも、自律的に長く走らせる用途を想定していると説明しています。

実タスク寄りの評価でも伸びが見えていて、たとえば CursorBench は 4.6 の 58% から 70% へ上がったと公表されています。一方で、この世代は応答が短めになり、ツールの呼び出し回数が増える場面があるといった指摘もあり、出力の長さや手数を前提に組んでいたフローは少し調整が要りました。

3 世代のなかで API の変更がもっとも大きいのがこの世代です。 詳細は次章にまとめます。

4.8 — 判断力と正直さが軸の現行世代

4.8 は、賢さの数字を伸ばすより、協働相手としての質を上げた世代です。Anthropic は、自分の書いたコードの欠陥を見逃す確率が、ひとつ前の世代と比べておよそ 4 分の 1 になったと説明しています。聞かれていない前置きが減り、無理な計画には押し返してくる、といった判断の質も上がりました。

エージェント用途も強く、ブラウザやコンピュータを操作する評価の Online-Mind2Web では 84% と、Anthropic は検証時点で最も高い水準だと公表しています。さらに Claude Code には dynamic workflows が加わり、Claude が作業を計画して数百の並列サブエージェントを 1 つのセッションで走らせ、結果を自分で検証してから返す、という大きな仕事に踏み込めるようになっています。

API では、会話の途中でシステム側の指示を差し込める仕組みが加わりました。従来は先頭のシステムプロンプトを書き換えるしかなく、書き換えるとキャッシュが丸ごと無効になっていましたが、この世代からは会話の途中に追記できるため、キャッシュを保ったまま前提を足せます。

FIXIT

同じ値段なら、いちばん新しいのを選んでおけばいいんじゃないの？

Hayate

基本はそれで正解です。同じ価格で判断力もコード品質も上ですから。

FIXIT

じゃあ、古い世代をあえて使う理由ってあるの？

Hayate

運用でバージョンを固定したいときですね。再現性を取りたい現場はあります。

FIXIT

ふーん。コスパ重視なら、何を見て選ぶの？

Hayate

使い分けの目安は、世代よりも effort と速度です。そこが効きます。

API の互換性｜移行でコードを直す必要があるのはどこか

世代を上げるときに実際の手間になるのは、性能差ではなく API の互換性です。ここは世代によって差が大きいので、分けて整理します。

4.6 から 4.7 へ｜削除されたパラメータがある

4.7 で 2 つのパラメータが削除されました。残したままリクエストを送るとエラーになります。

1 つ目は thinking の budget_tokens です。 思考量をトークン数で直接指定する書き方が使えなくなりました。{"type": "adaptive"} に置き換え、思考量は effort で調整します。

// 4.6 までの書き方 (4.7 以降はエラー)
{ "thinking": { "type": "enabled", "budget_tokens": 8000 } }
 
// 4.7 以降
{
  "thinking": { "type": "adaptive" },
  "output_config": { "effort": "high" }
}

2 つ目は temperature・top_p・top_k のサンプリング設定です。 こちらは代替のパラメータがなく、削除してプロンプト側で挙動を誘導する形になります。temperature を 0 にして出力を安定させていた場合は、effort を低めにしたうえで指示を具体的に書く方向へ切り替えます。逆に表現に幅を持たせたかった場合は、その旨をプロンプトで伝えることになります。

あわせて確認したいのが thinking.display です。 4.6 では思考の要約が既定で返っていましたが、4.7 からは既定が「返さない」に変わりました。エラーにはならないため気づきにくいのですが、思考の過程を画面に出している場合は表示が空になります。要約を出したい場合は明示的に指定してください。

{ "thinking": { "type": "adaptive", "display": "summarized" } }

トークナイザが変わったので見積もりが変わる

4.7 で文字をトークンに分割する方式が変わりました。同じ文章でも 4.6 より多いトークン数として数えられます。 目安はおおむね 1 倍から 1.35 倍で、内容によって振れ幅があります。

単価は据え置きなので、同じ処理でも請求額が変わる可能性があります。エラーにならない変化なので、移行後に費用が想定と合わなくなって初めて気づく類の落とし穴です。

対処は 2 つあります。1 つは、倍率を当てずに実際のプロンプトでトークン数を数え直すこと。もう 1 つは、max_tokens に余裕を持たせておくことです。4.6 の感覚でぎりぎりに設定していると、同じ内容でも出力が途中で切れることがあります。

プロンプトキャッシュの最小長も世代で違う

見落としやすい差として、プロンプトキャッシュが効き始める最小のトークン数があります。4.6 は 4096、4.7 は 2048、4.8 は 1024 です。世代が新しいほど短いプロンプトでもキャッシュが効きます。

ここもエラーにならないのが厄介な点です。最小長を下回るプロンプトにキャッシュの指定を書いても、静かに無視されるだけで警告は出ません。4.6 の時点で「短すぎてキャッシュが効かない」と判断して諦めたプロンプトが、4.8 では効くようになっている可能性があります。移行のタイミングで見直す価値があります。

4.7 から 4.8 へ｜コードの修正は不要

4.8 は 4.7 と同じリクエスト仕様を保っています。削除されたパラメータも、既定値が変わった項目もありません。モデル ID を claude-opus-4-8 に差し替えるだけで動きます。

ただしプロンプトの調整は検討する価値があります。4.8 は 4.7 と比べて次のような傾向があります。

• 作業中の説明が増える。ツールを呼ぶ合間に状況を書くようになったため、4.7 向けに「3 回ごとに進捗をまとめて」といった指示を入れていた場合は外せます
• 細かい判断で確認を挟む。変数名や既定値のような小さな選択でも聞いてくることがあり、自律的に進めてほしい場合はその旨を書き足します
• 検索やサブエージェント、メモリへのリーチが控えめになる。使ってほしい場面がはっきりしている場合は、いつ使うかを明示すると挙動が揃います

いずれも品質の問題ではなく、好みと用途に合わせる調整です。まず ID だけ差し替えて動かし、気になる挙動が出たらプロンプトで整える、という順番で問題ありません。

4.6 から 4.8 へ移行する手順

4.6 に留まっている環境から一気に 4.8 へ上げる場合の手順です。エラーで止まる項目と、静かに挙動が変わる項目を分けて確認するのが要点になります。

まずエラーになる項目から潰します。 ここを直さないとリクエストが通りません。

1. thinking の budget_tokens を探して削除し、{"type": "adaptive"} に置き換える。思考量は output_config の effort で指定する
2. temperature・top_p・top_k をリクエストから削除する。決定性を求めていた場合は effort を低めにしてプロンプトを具体化し、表現の幅がほしかった場合はその旨を指示に書く
3. モデル ID を claude-opus-4-8 に差し替える。日付のサフィックスは付けない

次に、エラーにならないまま挙動が変わる項目を確認します。 ここが移行後のトラブルの発生源になりやすい部分です。

4. 思考の要約を画面に出している場合は thinking.display に summarized を明示する。指定しないと本文が空になる
5. 代表的なプロンプトでトークン数を数え直し、費用の見積もりを更新する。倍率での換算はしない
6. max_tokens に余裕を持たせる。4.6 の感覚でぎりぎりに設定していると出力が途中で切れる
7. プロンプトキャッシュを使っている場合は、最小長が 4096 から 1024 に下がったことを踏まえて対象を見直す

最後に挙動を合わせます。 品質の問題ではなく好みの調整なので、動かしてから判断すれば十分です。

8. 「N 回ごとに進捗をまとめて」のような、進捗報告を強制する指示があれば外す。4.8 は既定で状況を書く
9. 自律的に進めてほしい場合は、細かい判断で確認を挟まない旨を書き足す
10. 検索やサブエージェント、メモリを積極的に使ってほしい場合は、いつ使うかを明示する

1 から 3 が済めばまず動きます。4 から 7 は動いたうえで数字と表示がずれる箇所、8 から 10 は好みの調整です。段階を分けておくと、問題が出たときにどこを見ればよいかがはっきりします。

effort の選び方｜4.7 で 5 段階になった

effort は思考の深さと全体のトークン消費を制御するパラメータです。4.6 では 4 段階でしたが、4.7 で high と max の間に xhigh が加わり 5 段階になりました。既定値はどの世代も high です。

コーディングやエージェント用途では xhigh が推奨されており、Claude Code でも既定として使われています。一方で max は必ずしも最良ではなく、簡単なタスクでは考えすぎて時間と費用が増えることがあります。

実務では、世代を上げるより effort を調整するほうが費用と速度への影響が大きい場面が多くあります。世代の比較に入る前に、いま使っている effort が用途に合っているかを確かめる価値があります。

なお xhigh や max を指定する場合は、max_tokens を大きめに取ってください。思考とツール呼び出しで出力の枠を使うため、枠が足りないと回答が途中で切れます。

用途別の使い分けの目安

世代の違いがわかったら、次は自社のどの場面でどう選ぶかです。料金が据え置きである以上、基本線は「最新を使い、足回りで調整する」になります。

ここで効くのは、世代の番号より 2 つの軸です。1 つは effort と速度モードの調整で、難所は思考量を増やし、待ち時間が効く場面は Fast mode で速くします。もう 1 つはモデルクラスの選択で、重いタスクは Opus、軽い反復は下位クラスへ振ると、コストが素直に下がります。世代を 4.6 から 4.8 へ動かすより、この 2 軸のほうがコストと速度の振れ幅は大きいです。

Fast mode や effort、dynamic workflows を 4.8 で実際にどう動かすかは、Opus 4.8 を使いこなす要点 で手順に寄せて整理しています。Opus の上をいく Mythos クラスの使いどころは Claude Fable 5 が Claude Code に登場 も参考にしてください。

料金と速度の考え方

料金は、4.5 から 4.8 まで通常利用が据え置きです。入力は 100 万トークンあたり 5 ドル、出力は 25 ドルで、世代が新しくなっても変わりません。だからコストの観点では、古い世代を選ぶ動機は基本的に生まれません。

速度を上げたいときは Fast mode を使います。4.8 では出力の速度がおよそ 2.5 倍になり、Fast mode の料金も従来世代より 3 倍ほど安くなりました。速さに対する追加コストなので、待ち時間がそのまま体験や生産性に効く場面に絞って使うのが、損得の合う使い方です。

注意点が 2 つあります。1 つは、Fast mode が 4.7 では提供されていないことです。4.6 と 4.8 にはありますが、4.7 で一度なくなっています。もう 1 つは、Fast mode に通常とは別のレート制限が割り当てられることです。上限に達した場合は、待つか通常モードへ落とすかの判断になります。

前述のとおり、トークンの数え方は 4.7 で変わっています。単価が同じでも同じ処理の請求額が変わりうるため、単価ではなく実測のトークン数で見積もるのが確実です。

4.8 だけを詳しく知りたい場合

この記事は 3 世代の違いと選び方に絞っています。4.8 単体の新機能や、4.7 から何が変わったかをより詳しく知りたい場合は Claude Opus 4.8 とは — 4.7 から何が変わったか にまとめています。実際の設定手順は Opus 4.8 を使いこなす要点 が実務寄りです。

fixit はこう見ている

私たちは、世代の番号を追うこと自体が目的にならないように気をつけています。料金が据え置きで性能が上がる以上、基本は最新を使い、タスクの難しさと待ち時間に応じて effort と速度を調整する、という原則で AI 駆動開発を進めています。

移行の実務で効くのは、性能の比較より互換性の確認です。4.7 から 4.8 なら ID の差し替えだけで済みますが、4.6 に留まっている環境では削除されたパラメータの整理とトークン数の再見積もりが要ります。世代を上げる判断をする前に、いま自社がどの世代にいて、何が引っかかるのかを洗い出しておくと段取りが崩れません。

大事なのは、モデルが賢くなることそのものより、何を任せて何を人が保証するかを設計できるかどうかです。判断力が上がった 4.8 でも、テストと人のレビューを外す理由にはなりません。むしろ自律性が増したぶん、任せる範囲とレビューの仕組みを先に決めておくことが、本番で効いてきます。

AI エージェントを業務へ組み込む設計の考え方は AI エージェントの設計パターン で、Claude Code をチームへ広げる進め方は Claude Code を実務に導入する完全ガイド で整理しています。どのモデルをどの業務にどこまで任せるかを一緒に決めたい場合は、AI 駆動開発サービス のページや 無料相談 からご相談ください。

まとめ｜押さえるのは 3 点

整理すると、次の 3 点です。

1. 料金はどの世代も同じ。入力 5 ドル・出力 25 ドルで据え置きのため、コストを理由に古い世代へ留まる意味はありません
2. 4.7 から 4.8 はモデル ID の差し替えだけ。API の破壊的変更がないため、移行の手間はほぼありません
3. 4.6 に留まっている場合だけ作業が要る。budget_tokens とサンプリング設定の削除、トークン数の再見積もりが必要です

そのうえで、費用と速度を動かしたいときに見るのは世代ではなく effort と Fast mode、そしてモデルクラスの選択です。ここを整えたほうが、世代を 1 つ上げるより効きます。

おすすめ参考リソース

• Anthropic 公式: Introducing Claude Opus 4.8
• Anthropic 公式: Introducing Claude Opus 4.7
• Anthropic 公式: Claude Opus 4.6