Claude Opus 4.7|4.6との違いと注意点

AI業務効率化

※ この記事にはアフィリエイトリンクが含まれています。リンク経由で購入しても読者の皆さんに追加費用は発生しません。収益は本サイトの運営費に充てています。

Claude Opus 4.7が2026年4月16日に公開されました。「価格据え置きの小さなアップデート」と思って移行すると、既存のプロンプトがかなりの確率で壊れます。僕はClaude Codeでこのブログの自動化を運用していて、更新直後にいくつかのスクリプトで挙動が変わるのを体感しました。この記事では、Claude Opus 4.7のすごいところ、Opus 4.6との違い、そして移行前に必ず知っておくべき注意点を整理します。

こんな方に読んでほしい

  • Claude Opus 4.7への移行を検討しているエンジニア
  • Opus 4.6向けのプロンプトやエージェントを本番運用している方
  • APIの料金とトークン消費を正確に把握したい方
  • 「ただのマイナーアップデート」と油断したくない方

Claude Opus 4.7とは|リリース概要と位置づけ

結論から言うと、Claude Opus 4.7は「性能は上がったが、同時に挙動が厳格になった」モデルです。Opus 4.6のドロップイン後継として設計されています。ただし、Anthropic自身が「より文字通りに指示を解釈する」と明示しています。既存のゆるいプロンプトは素通しで動きません。

リリース日と提供プラットフォーム

Claude Opus 4.7は2026年4月16日にGA(一般提供)となりました。Claudeアプリ、Anthropic API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundryで同時に利用可能です。API model IDはclaude-opus-4-7。1Mトークンのコンテキストウィンドウ、128kの最大出力トークン、adaptive thinkingに対応します。

価格は4.6から据え置き

料金は入力100万トークンあたり5ドル(約750円、2026年4月時点)、出力100万トークンあたり25ドル(約3,750円)。Opus 4.6と完全に同じ設定です。ただし、後述するトークナイザーの変更により、同じ入力でもトークン数が1.0〜1.35倍に増えます。実質コストは微増すると考えておいた方が安全です。

ベンチマーク上の立ち位置

SWE-bench Verifiedで87.6%を記録しました(Opus 4.6は80.8%)。SWE-bench Proも64.3%。Anthropic公称では、報告された14ベンチマーク中12で4.6を上回っています。コーディングは4.6比で13%の改善。本番相当のタスクを人間介入なしで解けた件数は3倍という数字が示されています。

Opus 4.7のすごいところ|4.6から実感できる進化

ここからは、Opus 4.6との比較で「確かに変わった」と思える進化点を3つに絞ります。

高解像度画像サポート(2576px / 3.75MP)

Claude Opus 4.7はClaude初の高解像度画像対応モデルです。画像の最大解像度が2,576ピクセル(3.75MP)まで引き上げられました。従来のOpus 4.6は1,568ピクセル(1.15MP)だったので、約3.3倍の解像度差です。

もうひとつ重要な変更があります。モデルが返す座標が画像のピクセルと1対1で対応するようになったため、スケールファクターの換算計算が不要になりました。Computer useやスクリーンショット解析、ドキュメント理解の精度が上がります。僕がPlaywrightで取得したフルHDスクリーンショットをそのまま投げても、小さなUIテキストまで拾えるようになった体感があります。

新しいエフォートレベル「xhigh」とタスクバジェット

Opus 4.7では、effortパラメータにxhighが追加されました。コーディングやエージェント用途ではxhighを、知的負荷の高い他の用途では最低でもhighを使うことが推奨されています。

さらに、task budgets(ベータ)という新機能が登場しました。これはエージェントループ全体でのトークン消費の目安をモデルに伝える仕組みです。従来のmax_tokensは「1リクエストあたりの出力上限」というハードキャップでした。一方task budgetは「ループ全体で使えるトークンの目安」という柔らかい指示です。使い方の例はこうです。

response = client.beta.messages.create(
    model="claude-opus-4-7",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 128000},
    },
    messages=[...],
    betas=["task-budgets-2026-03-13"],
)

モデルは残り予算を見ながら作業を優先付けし、予算が尽きる前にタスクを着地させようとします。最低値は20,000トークン、これを下回ると「タスクをやり切れない」または「タスクを拒否する」ことがあると公式に記載されています。

コーディング自己検証とメモリ活用の改善

Opus 4.7は「計画段階で自分の論理的欠陥に気づき、そこから実行を加速する」と公式ドキュメントに書かれています。長時間のエージェントタスクで途中成果を自己検証する動きが増えました。また、ファイルベースのメモリ(スクラッチパッドやnoteファイルの書き込み・読み返し)の扱いも改善しています。

Claude Codeで大きめのリファクタを任せると、途中で「このアプローチは〜の点で問題があるので方針を変える」と自ら修正する挙動を以前より頻繁に見ます。この辺りは使い込むほど差が出る部分です。

Opus 4.7と4.6の違い|移行前に押さえる5つの破壊的変更

ここが本題です。Opus 4.7は4.6のドロップイン後継を謳っていますが、Messages APIで5つの破壊的変更が入っています。油断すると本番環境で400エラーが出ます。

1. Extended thinking budgetsが削除された

Opus 4.6で使えていたthinking: {"type": "enabled", "budget_tokens": N}は、Opus 4.7では400エラーになります。thinking-onモードはadaptive thinkingのみに一本化されました。移行時は以下のように書き換えます。

# Opus 4.6(旧)
thinking = {"type": "enabled", "budget_tokens": 32000}

# Opus 4.7(新)
thinking = {"type": "adaptive"}
output_config = {"effort": "high"}

さらに注意したいのは、adaptive thinkingはデフォルトでオフである点です。thinkingフィールドを明示的に指定しないと、一切思考せずに応答します。「なんか4.7にしたら回答が浅くなった気がする」と感じたら、まずここを疑うべきです。

2. temperature・top_p・top_kが使えなくなった

Opus 4.7では、temperaturetop_ptop_kをデフォルト以外の値に設定すると400エラーが返ります。これらのパラメータは完全に削除されたと考えて、リクエストから外してください。

「temperature=0で決定性を担保していた」というケースも諦めが必要です。もっとも、temperatureが0でも同一出力は保証されていなかったので、本来プロンプト設計で吸収すべきところだったとも言えます。

3. thinking contentがデフォルトで非表示に

Opus 4.7ではthinking contentがレスポンスからデフォルトで省略されます。ストリームにはthinkingブロックが流れますが、thinkingフィールドの中身は空です。エラーは出ないサイレントな変更なので、ログや可視化ツールで思考過程を表示している場合は要確認です。

thinking = {
    "type": "adaptive",
    "display": "summarized",  # デフォルトは"omitted"
}

ユーザーにthinkingをストリーム表示しているプロダクトでは、「長い沈黙のあとに答えが出る」体験になります。display: "summarized"を明示的に指定して、進捗を見せるのが無難です。

4. トークナイザー変更で1.0〜1.35倍の増加

Opus 4.7は新しいトークナイザーを採用しています。同じテキストを処理しても、Opus 4.6比でトークン数が1.0〜1.35倍になるとAnthropicが明示しています。コードや日本語混在文など、コンテンツタイプによって増加率は変わります。

/v1/messages/count_tokensも旧モデルとは異なる値を返すので、事前にベンチマークを取らないと予算超過に直結します。max_tokensとコンパクション閾値には余裕を持たせてください。

5. 指示追従が「文字通り」になった

これが一番怖い変更です。Opus 4.7は指示を字句通りに解釈します。特に低いエフォートレベルでは顕著です。

  • 「JSONで返して」と書けば、JSONだけを返します。説明文は付きません
  • 「関数を3つ書いて」と書けば、4つ書いた方がエレガントでも3つしか書きません
  • 明示していない要望を勝手に推測しません

4.6ではある程度「空気を読んで」補完してくれた部分が、4.7では全く補完されなくなります。既存プロンプトの「簡潔に」「余計なことは省いて」といった表現が、想定以上に厳密に適用されるケースが出ています。

Opus 4.7を使う上で気を付けるべきこと

破壊的変更に加えて、挙動の変化で踏み抜きやすい落とし穴を4つ挙げます。

既存プロンプトの「再ベースライン」が必要

4.6向けに「スライドレイアウトを返す前にダブルチェックして」のような足場(scaffolding)を足したプロンプトを使っているとします。4.7ではその足場が逆効果になるケースがあります。4.7はもともと自己検証を強化しており、冗長な指示を文字通り受け取って過剰に実行してしまうからです。

公式ドキュメントでも「足場を外して再ベースライン(再評価)せよ」と明記されています。プロンプトは書いたまま動かし続けるものではなく、モデル更新ごとに検証するものだと改めて認識する必要があります。

ツール呼び出しが減る=ワークフロー前提が崩れる

Opus 4.7はデフォルトではツール呼び出しが減り、推論で解決しようとします。effortを上げるとツール使用が増えます。「必ずwebサーチを叩いてから答える」前提のワークフローを組んでいた場合、サーチが呼ばれず古い情報で答えるリスクがあります。

サブエージェントの生成もデフォルトで減りました。並列処理前提のエージェント設計では、プロンプトで明示的に「サブエージェントを〇個立ち上げて」と書く必要が出てきます。

応答の口調と長さが変わった

4.7は4.6よりも「直接的で意見を持ったトーン」になりました。validation-forward(共感や同意から入る表現)が減り、絵文字も減っています。応答長はタスクの複雑さに応じて動的に調整されます。

ユーザー向けの表示でトーンを指定していた場合、意図した温度感と食い違う可能性があります。プロダクトの「声」を守るには、プロンプトでトーンを明示する必要があります。

サイバーセキュリティ関連のリフューザル

Opus 4.7はリアルタイムのサイバーセキュリティセーフガードが強化されました。禁止・高リスクなトピックに関わるリクエストはリフューズされる可能性があります。正当なセキュリティ業務で利用する場合は、Cyber Verification Programへの申請が必要になります。

Opus 4.7への移行チェックリスト

踏み抜きを防ぐため、僕が実際に使っている移行手順を共有します。一気に切り替えず、段階的に検証するのが安全です。

1. 代表プロンプトの出力差分を取る

本番で流れているプロンプトのうち、トラフィックが多い上位10件を選びます。同じ入力でOpus 4.6と4.7の出力を並べて比較し、「意図と違う出力」がないかを見ます。特に「JSONだけ返して」「〜してから〜する」のような手順指示は差が出やすい部分です。

2. トークン消費のベンチマーク

/v1/messages/count_tokensで同一入力のトークン数をモデル別に測定します。1.0倍に収まるのか、1.35倍寄りなのかで月次コストが大きく変わります。max_tokensと自作のコンパクション閾値も、この数値を踏まえて引き上げが必要です。

3. thinking設定の見直し

Opus 4.6でbudget_tokensを使っていたコードは、adaptiveeffortに置き換えます。思考過程をUIに出しているならdisplay: "summarized"を明示します。adaptive thinkingをそもそも有効化していないと、応答品質が下がって見えるので注意します。

4. カナリアデプロイで段階的に切り替え

100%切り替えは避けます。5%→20%→50%と段階的にトラフィックを流し、実ログでエラー率とレスポンス品質を比較します。Anthropic自身も「急がず、トークナイザー影響をベンチマークし、リテラル解釈の変化を再テストし、実トラフィックで検証せよ」と書いています。

Playwright自動化やスクレイピングでの使用注意

僕はClaude Codeで記事生成を自動化しています。Opus 4.7の高解像度画像サポートは、スクリーンショットを大量に処理するスクレイピング用途と相性がいいです。ただし、自動化の文脈では以下を必ず守ってください。

  • 対象サイトの利用規約とrobots.txtを都度確認する
  • リクエスト頻度を抑える(各操作間に数秒のウェイト)
  • 自分のアカウントのデータ取得に限定する
  • 「技術的にできる」と「やっていい」を区別する

Opus 4.7の解像度が上がったことで、より細かいUI要素をAIが判別できるようになりました。これは便利である反面、意図せず過剰な情報取得につながる可能性もあります。モデルの性能が上がるほど、自動化の倫理的な設計責任は重くなります。

まとめ|Opus 4.7は「性能向上と厳格化」をセットで受け取る

Claude Opus 4.7は、コーディング性能、画像理解、エージェント自律性のいずれも大きく進化したモデルです。同時に、指示を字句通り受け取り、パラメータ指定が厳格になり、トークン消費が変動するという挙動上の変化を伴います。価格は据え置きですが、「同じプロンプト・同じ設定」で動かすと壊れることが前提です。

僕自身は、段階的な切り替えと代表プロンプトの差分検証を経由して移行を進めています。本番サービスで4.7に切り替えるなら、最低でもトークン消費のベンチマークとthinking設定の見直しはセットで実施してください。

Anthropic APIやClaude Codeをこれから本格的に学ぶなら、AI・プログラミング系のカリキュラムが揃ったデイトラが入り口に使えます。実務寄りの内容を扱うDMM WEBCAMPも候補です。API従量課金のコストを抑える設計は、AIコードツールのコスト最適化の記事も参照してください。

Opus 4.7を実運用で使い込んでいく中で、新しい落とし穴が見つかったら追って報告します。進展あれば面白そうです。

参考リンク

コメント

タイトルとURLをコピーしました