TL;DR
- 2026年4月16日にClaude Opus 4.7がGA。モデルIDは
claude-opus-4-7 - 価格は据え置き（$5 / $25 per MTok）、コンテキストウィンドウも1Mトークン据え置き
- 新機能:
xhigheffort、task budgets（public beta）、/ultrareviewコマンド、高解像度ビジョン - 既存プロンプトは「過剰な足場」を外した方が性能が出る方向に変わっている
- トークナイザー更新で同じ入力でも1.0〜1.35倍のトークンを消費するため、コスト再試算が必要
本記事はOpus 4.7で増えた機能・変わった挙動・今後の開発スタイルで変えた方が良さそうな点を整理する。
1. 新しく増えた機能・特徴
1.1 xhigh effort level
highとmaxの間に新しい推論強度が追加された。Anthropic公式は「コーディングとエージェント用途ではhighかxhighから始めるべき」と推奨している。Claude Codeでは、初回Opus 4.7起動時に自動でxhighが適用される仕様。
Anthropicのベンチマークでは、xhighの100kトークン消費時点で、Opus 4.6のmax（200kトークン）を超えるスコアを出している。つまり同じ認知予算でより深く考える設計になった。
1.2 task budgets（public beta）
単一ターンではなく、エージェントループ全体に対してトークン予算の上限を設定できる仕組み。
# Claude Code内での使用例
/config task_budget 50000
予算に近づくとモデルは停止してユーザーに確認を求める。従来のmax_tokensが「1ターンの上限」だったのに対し、task budgetsは「タスク全体の上限」。暴走防止のガードレールとして機能する。
1.3 /ultrareviewコマンド（Claude Code）
変更差分を読み込み、慎重なレビュアーが見つけるような問題をフラグする専用レビューセッション。実態は「クラウドで複数のサブエージェントが並列にコードを調べ、別レイヤーで検証する」マルチエージェント型レビューシステム。
- デフォルトで5エージェント、最大20まで対応（Enterprise想定）
- 信頼度スコア8/10以上の問題のみ報告する厳格なfalse-positiveフィルタ
- Pro/Maxは請求サイクルごとに3回まで無料。以降は通常のOpus 4.7レートでトークン消費
/ultrareview 123 # 特定PRのレビュー
/ultrareview # 現在のブランチをレビュー
1.4 高解像度ビジョン
画像の最大解像度が1.15MP（1,568px）から3.75MP（2,576px）へ約3倍に拡大。コンピュータユースの視覚精度は98.5%まで改善。回路図、UML、設計モックアップ、スクリーンショットが実用解像度で読めるようになった。
1.5 ファイルシステムベースのメモリ強化
長時間・複数セッションにまたがる作業で、モデルが重要なメモをファイルに書き出して参照する能力が向上。次のタスクに移る際、前提コンテキストを毎回大量投入する必要が減った。
1.6 セルフ検証能力
Opus 4.7の最大の特徴は「報告前に自分の出力を検証する手段を考案する」こと。内部テストではRustでTTSエンジンを書いた後、自分で生成した音声を別の音声認識器に通してPython実装と突き合わせる、といった自律的な検証を実行した例が報告されている。
1.7 auto modeのMaxプラン拡張
従来Teams/Enterprise/API限定だったauto mode（多段階実行で都度許可を求めない運用モード）がMaxプランでも利用可能になった。
2. 前から変わったこと（破壊的変更と挙動変化）
2.1 API破壊的変更
- Prefill削除: Assistantメッセージのprefillは400エラー。structured outputsまたはsystem prompt指示に移行する必要あり
-
サンプリングパラメータ削除:
temperature、top_p、top_kは使用不可。プロンプトで挙動を制御する方式へ -
extended thinking budgets廃止:
thinking: {type: "enabled"}とbudget_tokensは非推奨。adaptive thinkingとeffortパラメータに統一 -
thinking内容のデフォルト非表示: thinkingブロックは空で返る。
"display": "summarized"でオプトインする形式に
2.2 挙動の変化（プロンプト調整が必要になりうる点）
- 指示の文字通り解釈が強化: 1項目に対する指示を他項目に暗黙に一般化しなくなった
- 応答長が複雑さに応じて変動: 従来の固定verbosityから、タスク複雑度に応じたスケールへ
-
デフォルトでツール呼び出しが減る: 行動より推論を優先。ツールを多用させたい場合は
effortを上げる - トーンがより直接的・断定的に: 絵文字や共感表現が減り、意見を持った応答が増える
- デフォルトで生成されるサブエージェントが減少
2.3 トークナイザー変更
同じ入力テキストでも、コンテンツタイプによって1.0〜1.35倍のトークンを消費する。価格は据え置きでも、実効コストは最大35%増える可能性がある。/v1/messages/count_tokensで自分のワークロードへの影響を測定すべき。
2.4 高effortでの思考量増加
高effortレベルではより多く考える設計になった。特にエージェント用途の後半ターンで顕著。難問への信頼性は上がるが、出力トークン数は増える。
3. エンジニアとして開発方法を見直したい点
3.1 プロンプトから「過剰な足場」を外す
Opus 4.6時代、モデルの挙動を矯正するために書いていた以下のような指示は、Opus 4.7では不要になっている可能性が高い。
- 「ステップバイステップで進めてください」
- 「進捗を都度報告してください」
- 「実装前にプランを立ててから進めてください」
- 「出力を再チェックしてください」
Opus 4.7はこれらのパターンをネイティブに処理するため、既存プロンプトからまず足場を外して挙動を確認し、必要な分だけ戻すアプローチが良さそう。過剰な指示は「指示の文字通り解釈」と相性が悪く、むしろ悪化するリスクすらある。
3.2 CLAUDE.md / プロンプトの再点検
指示の文字通り解釈が強まったため、曖昧な指示や「なんとなく汲み取って」的な書き方は誤読される可能性が上がった。CLAUDE.mdやシステムプロンプトは以下の観点で見直すと良さそう。
- 暗黙の前提を明文化する
- 「例外時の挙動」を明記する（触らない条件、停止する条件、確認を求める条件）
- 過剰なネガティブ指示（「〜しないでください」の羅列）を、ポジティブな例示に置き換える
3.3 harnessやエージェント設計における認知リソース配分
task budgetsの登場で、フェーズごとの認知リソース配分を明示的に設計できるようになった。以下の配分が基本形として有効だと考えている。
-
設計・プランニングフェーズ: 予算多め +
xhigheffort（ここで誤ると下流が全部汚染される） -
実装フェーズ: 予算少なめ +
medium〜higheffort（planに忠実に実装させる） -
レビューフェーズ: 予算多め +
xhigheffort（浅いレビューは意味がない）
特にPlanner→Generator→Evaluatorのような構成では、Evaluator部分に/ultrareview相当の「発見と検証の分離」を組み込むと、false positiveが減らせる。
レビュー層を2段構えに分ける
レビューフェーズ自体も、性質の異なる2層に分離するとさらに効率が上がる。
-
Layer 1: plan準拠チェック（effort低め・予算少なめ）
- 実装がplanの指示通りに行われているかを機械的に照合
- 触るべきでないファイルに変更が入っていないか、想定外のAPIが追加されていないか、等
- 深い推論は不要なので
low〜mediumeffortで十分
-
Layer 2: 深いレビュー（effort高め・予算多め）
- 論理的欠陥、エッジケース、セキュリティ、パフォーマンス、命名・設計の妥当性
-
xhigheffortで、planに書かれていない観点も含めて吟味させる -
/ultrareview相当のマルチエージェント並列レビューもこの層で使う
1層目を先に通すことで、planからの逸脱という「単純だが致命的な問題」を早期に弾ける。2層目に到達するコードは既にplan準拠が保証されているので、レビュアーは設計・品質の観点に集中できる。これはCI/CDでlintと型チェックをユニットテストの前段に置くのと同じ思想で、軽い検査で落とせるものは軽く落とし、重い検査の対象を絞り込むアプローチになる。
この2層構成は、Opus 4.7のeffort粒度とtask budgetsが組み合わさって初めて実用的になる設計と言える。単一レビューで全部やらせると、plan準拠チェック程度の軽い判定にもxhigh相当のトークンが消費されるため、コスト効率が悪い。
3.4 planをOpusで作り、実装をSonnetに任せるハイブリッド運用
Opus 4.7はplan立案時の推論が深くなった分、「高品質なplanをOpusで作り、実装を安価なモデルに任せる」というハイブリッド運用の効果が一段上がっている。Claude Codeにはopusplanというエイリアスが用意されており、まさにこのパターンを自動化してくれる。
-
plan mode: 複雑な推論とアーキテクチャ判断に
opusを使う -
execution mode: コード生成・実装は
sonnetに自動で切り替わる
設定は/model opusplanで有効化できる。思考コストが重いplanフェーズだけOpus 4.7のxhighで走らせ、ルーチン的な実装はSonnet 4.6で捌く構成になるため、品質とコストのバランスが取りやすい。
有効なユースケースの例:
- 大規模リファクタリング: 影響範囲の洗い出しと段取りはOpus、各ファイルの実際の書き換えはSonnet
- 新機能の設計〜実装: アーキテクチャ決定とインターフェース設計はOpus、実装はSonnet
- フレームワーク移行: 依存関係の解析と移行順序の立案はOpus、機械的な置き換えはSonnet
- 仕様書からのスキャフォールド生成: 設計の解釈と分割はOpus、ボイラープレート生成はSonnet
さらにtask budgetsと組み合わせると、ループ全体の予算設計まで可能になる。opusplan + task budgets + xhighの組み合わせは、Opus 4.7世代で初めて成立する運用パターンと言える。
opusplanを使わずに手動で切り替える場合も、以下のような使い分けが有効。
- planだけOpus 4.7で作成 →
plan.mdに永続化 → Sonnetに実装させる - ArchitectとExecutorをCLAUDE.mdで役割分担させ、モデルも分ける
- 一人harness構成でPlannerのみOpus、Generator/EvaluatorはSonnetで回す
3.5 plan結果をファイルに永続化する運用
ファイルシステムベースのメモリが改善されたので、planをplan.mdのようなファイルに明示的に吐き出させ、実装フェーズで参照させる運用が有効になる。セッションが分かれても文脈が引き継がれやすく、Ralph Loop的なパターンとの相性も良い。
3.6 /ultrareviewの使いどころを切り分ける
/ultrareviewはクラウド実行型のマルチエージェントレビューである点を踏まえ、扱うコードの性質で使い分ける必要がある。
- 有効な場面: OSS、公開予定のコード、複数観点のチェックが必要な変更
- 要検討の場面: 機密度の高いコード、第三者サービスでの処理が制限されているコード
Anthropicの隔離VMで動作しセッション後に破棄される設計になっており、学習への利用もConsumer Termsではオプトインしない限り発生しない。それでも扱うコードのポリシー次第で使い分けは必要になる。
3.7 トークンコストの再試算
トークナイザー変更で実効コストが増える可能性があるので、以下を必ず実施する。
- 本番に投入する前に
count_tokensAPIで典型的なプロンプトを測定 -
max_tokensにヘッドルームを追加（コンパクション発動の閾値も含め） - task budgetsを活用してループ全体のコスト上限を設定
3.8 マイグレーションの自動化
Claude Codeには/claude-api migrateコマンドが用意されており、モデルIDの切り替え、破壊的変更の対応、prefillの置き換え、effortのキャリブレーションを一括で処理してくれる。
/claude-api migrate this project to claude-opus-4-7
既存プロジェクトがある場合はまずこれを実行し、変更サマリーを確認してからデプロイするのが効率的。
4. 結論
Opus 4.7は「モデルが賢くなった」というより「モデルに任せられる範囲が広がった」アップデートと捉えている。従来プロンプトやharnessで補っていた挙動がモデル側でカバーされるようになり、逆に過剰な足場は害になる可能性が出てきた。
当面は以下の順で検証を進めるのが良さそうだ。
- 既存プロンプトから「ステップ指示」「進捗報告指示」「自己チェック指示」を外してA/B検証
- harness構成を「task budgetsでフェーズ別予算配分」する設計に変更
-
/ultrareviewと自作レビューharnessの比較実験 -
opusplanによるplan/実装モデル使い分けの効果検証
Opus 4.7は小さくない変更を含むので、「モデルIDを書き換えるだけ」で済ませず、ワークフロー全体を棚卸しするきっかけにすると良さそうだ。