先に要点
- Claude Opus 4.7 は Anthropic が 2026年4月16日 にリリースした上位モデル。API ID は
claude-opus-4-7、Opus 4.6 と同じ価格(入力 \$5 / 出力 \$25 / 100万トークン)で、コンテキストは 1M トークン・最大出力は 128K トークン。 - 主な改善は「長時間・複雑なコーディングタスクの精度向上」「高解像度 Vision 対応(長辺 2,576px / 約3.75メガピクセル)」「命令追従の厳密化(緩い解釈から文字通りの実行へ)」の3本柱。
- API には新 effort レベル
xhighが追加され、段階はlow/medium/high/xhigh/maxの5段。Claude Code は今回からデフォルトがxhighに。同時に「タスク予算(task budget)」が beta 公開された。 - 利用先は Claude.ai / Claude API / Amazon Bedrock / Google Cloud Vertex AI / Microsoft Foundry と横断。ただし Bedrock / Vertex / Foundry ではモデル ID 表記が各社規則に従う点と、サーバーサイド機能の対応差に注意。Anthropic は 金融・中小企業向けエージェントへ展開を広げている。
「Claude Opus 4.7 ってよく聞くけど、Opus 4.6 から何が変わったの?」「xhigh って何?」「Claude Code のデフォルトが重くなったのはなぜ?」── 2026年4月16日にリリースされた Claude Opus 4.7 は、バージョン番号こそ 0.1 刻みですが、現場の使い心地は数字以上に変わったアップデートでした。
ざっくり言うと、Opus 4.7 は Opus 4.6 の延長線上の上位モデル で、特に 長時間動くコーディング作業を任せきれる安心感 と 命令を文字通り守る忠実さ を伸ばしてきた世代です。ベンチマーク面ではコーディング・財務分析・法務で目立つ向上、運用面では新 effort xhigh や Claude Code 側の挙動変更といった、「現場の使い方をそのまま変える」アップデートが同時に投入されました。
この記事では、Anthropic 公式の Introducing Claude Opus 4.7 を中心に、リリースの中身・モデル選択の指針・API の変化・実務インパクトを整理します。情報は急速に更新されるので、最終確認は必ず Anthropic の公式ニュースと API ドキュメントを見てください。
Opus 4.7 の位置づけと正確な仕様
Opus 4.7 は、Anthropic の LLM ラインナップの上位(Opus)系の最新版で、Opus 4.6 の置き換え用です。まず誤りなく押さえておきたいスペックを表にします。
| 項目 | Opus 4.7 の仕様 |
|---|---|
| 提供開始 | 2026年4月16日 |
| API モデル ID | claude-opus-4-7(日付サフィックスは付けない) |
| 価格 | 入力 \$5 / 出力 \$25(いずれも100万トークンあたり)。Opus 4.6 と据え置き |
| コンテキスト窓 | 1M(100万)トークン。長文プレミアムなしの標準価格 |
| 最大出力 | 128K トークン(大きい出力はストリーミング必須) |
| thinking(思考) | adaptive のみ。budget_tokens / temperature / top_p / top_k は廃止され、送ると 400 エラー |
| effort 段階 | low / medium / high / xhigh / max。xhigh は 4.7 で新設(high と max の間) |
| Vision 上限 | 長辺 2,576px / 約3.75メガピクセル(4.6 の長辺1,568pxから拡張) |
「Opus 4.6 から微増価格」のような身構えは不要で、据え置き価格でモデル品質を引き上げる リリースです。一方で、API のリクエスト形がいくつか変わっており、4.6 用のコードをそのまま投げると budget_tokens や temperature で 400 エラーになります。移行時はここが最初の落とし穴です。
強化された3つの柱
「Opus 4.7 で具体的に何ができるようになったか」を3つの軸で整理します。
1. 長時間 / 複雑なコーディング
Opus 4.6 でも「コーディング AI として強い」評価は確立していましたが、4.7 では 長時間動かしても破綻しにくい 方向と 複雑なタスクをそのまま投げられる 方向に伸びました。
何が変わるか
AI に1回投げて10〜30分後に結果を受け取るタイプの自律タスクで、途中で迷子になる確率が下がる。複数ファイルにまたがるリファクタ、テストを書きながら本体を直すような、文脈を保ったまま長く動くタスクと相性が良い。
運用上の効果
監視しながら短いタスクを何度も投げる運用から、安心して長めのタスクを任せる運用へ寄せていける。AI を待つ時間を他の作業に使える時間へ変えられる。
過信は禁物
ベースラインが上がっただけで、無人実行で全部任せられる水準にはまだ達しない。PR レビューや Storybook の Visual Regression など、人間が結果を見る仕組みは残す。
2. Vision(画像)機能の高解像度対応
Vision(画像入力)の解像度上限が 長辺 2,576ピクセル / 約3.75メガピクセル まで拡張されました(4.6 までは長辺1,568px)。しかもモデルが返す座標は実ピクセルと1対1で対応するため、これまで必要だったスケール補正の計算が不要になります。
何が変わるか
Retina スクショ、紙資料のスキャン、化学構造や複雑なダイアグラムを潰さずに渡せる。画像を縮小して送ったら細かい数字が読めなくなる、という事故が減る。
使い所
① エンジニアリング図面・回路図、② スプレッドシートのスクショ、③ 設計書 PDF のページ画像、④ v0 / Figma のスクショから UI を起こす作業、⑤ Computer Use(画面操作)。
トークンへの影響
高解像度は便利な反面、フル解像度の1枚あたり画像トークンが最大で約4,784トークン(従来は約1,600トークン上限)まで増える。およそ3倍だ。必要なときだけ高解像度、という運用ルールが効く。
日本語ドキュメントとの相性
細かい日本語フォントや表の罫線を読ませる場合、解像度の差がそのまま OCR 的な精度に効く。スクショから整理してもらう用途で体感が良くなる。
3. 命令追従の厳密化
Anthropic 公式が強調しているのが 緩い解釈をやめ、文字通りに従う方向への調整 です。4.7 は 4.6 よりプロンプトを literal(字義どおり)に解釈し、特に低い effort では「言われていない一般化」をしなくなります。
どう変わるか
例外を勝手に作らない、自己判断で別の方法を取らない、明示されていないことは推測で補完しない。プロンプトの一言一句が効く方向への変化。
ツール起動の傾向
4.7 は 4.6 よりツールを呼ぶ頻度が下がり、推論で済ませる傾向。検索やツール連携に依存するプロダクトでは、ツール説明文に「いつ呼ぶか」を明記し、effort を high 以上に上げると起動率が戻る。
トレードオフ
雑に書いても汲み取ってほしい用途では、4.6 のほうが心地よく感じることもある。指示書を書くつもりで AI と話す文化を組織で揃えると、4.7 の良さが最大化される。
API 側の新機能 ── effort と xhigh、タスク予算
Opus 4.7 と同時に、API には新しい effort レベル xhigh が追加され、効率と賢さのトレードオフを5段で選べるようになりました。
| effort | 使いどころ | 傾向 |
|---|---|---|
low |
短く範囲の狭いタスク、低遅延が大事な処理 | トークン最少。難タスクでは考え不足のリスク |
medium |
コストを抑えつつ多少賢さを落としてよい場面 | バランス寄り |
high |
知性が要る大半の業務(デフォルト) | トークンと賢さの推奨バランス |
xhigh |
大半のコーディング / エージェント用途で最良 | Claude Code の既定。深く考え深く動く |
max |
正確性が最優先で、コストを問わない難問 | 過剰思考に陥ることもあり、伸びは逓減しがち |
設定は output_config の中に effort として入れます(トップレベルではない点に注意)。あわせて、エージェントのループ全体に使えるトークン量をモデル自身に意識させる タスク予算(task budget、beta) も公開されました。これは output_config.task_budget に総量を指定する仕組みで、最小は20,000トークン、beta ヘッダ task-budgets-2026-03-13 が必要です。max_tokens が「モデルに見えない強制上限」なのに対し、task budget は「モデルに見える残量カウンタ」で、モデルが自分で締めくくり方を調整できる点が違います。
なお 4.7 から、思考ブロックの本文は既定で空(omitted)になりました。進捗としてユーザーに思考を見せたい場合は thinking に display: "summarized" を明示してください。これを知らないと「出力前に長い無音が続く」ように見えます。
実務比較 ── 同じタスクを high と xhigh で回すとどうなるか
ここが今回いちばん効く話です。同じリファクタを effort だけ変えて投げると、結果の質だけでなく トークン量・所要時間・コストが大きく変わります。以下は「中規模 TypeScript リポジトリで、ある関数のシグネチャ変更を全呼び出し元に波及させ、テストも直す」という同一タスクを、Opus 4.7 で effort を変えて流したときの典型的なオーダー感です(値は規模により上下する目安。実数は必ず count_tokens と請求ダッシュボードで確認してください)。
| 観点 | high で実行 | xhigh で実行 |
|---|---|---|
| 入力(累積) | 約 60K トークン | 約 90K トークン(より多く読み返す) |
| 思考 + 出力 | 約 40K トークン | 約 110K トークン(深く考え、手数も多い) |
| 体感の所要時間 | 短め | 1.5〜2倍程度かかる |
| 概算コスト | 約 \$1.3 | 約 \$3.2(およそ2〜3倍) |
| 結果の質 | 多くのケースで十分 | 難所(型エラーの連鎖、隠れた呼び出し元)で取りこぼしが減る |
コスト計算の内訳はシンプルです。Opus 4.7 は入力 $5 / 出力 $25 / 100万トークン。high のケースは「入力60K × $5 = $0.30」+「出力40K × $25 = $1.00」で約 $1.3。xhigh のケースは「入力90K × $5 = $0.45」+「出力110K × $25 = $2.75」で約 $3.2。出力トークン単価が入力の5倍 なので、xhigh で増えるのは主に思考と出力側、そこがコスト差を押し上げます。つまり「単価は同じでも、xhigh はトークンを多く使う」ぶんだけ請求が膨らむわけです。
ここから導ける運用の原則は1つです。デフォルトは high、難所だけ xhigh。雑に xhigh を全体のデフォルトにすると、同じ作業量でも月のコストが2〜3倍になりえます。逆に難バグの調査や大規模リファクタの初手プランニングでは、xhigh が high の取りこぼしを拾ってやり直しを減らすので、トータルではむしろ安くなることもあります。effort はルート(処理の種類)ごとに測って決めるのが正解です。
世代間比較 ── Opus 4.6 用の使い方は 4.7 でどう変わるか
「同じプロンプト・同じ設定を 4.6 から 4.7 に移しただけ」で挙動が変わるポイントを、具体例で押さえます。
thinking の指定が壊れる
4.6 で書いていた thinking: {type: "enabled", budget_tokens: N} は 4.7 で 400 エラー。thinking: {type: "adaptive"} + output_config.effort に置き換える。「思考の予算」という概念自体が effort に統合された。
temperature 等が消えた
4.6 で温度を下げて決定性を狙っていたなら、4.7 では temperature を送ると 400。決定性が目的なら effort を low + プロンプトを締める、創造性が目的ならプロンプトで明示する、に作り替える。
同じ指示が「字義どおり」に効く
4.6 が空気を読んで一般化していた曖昧指示は、4.7 では文字どおりにしか動かない。例「1件目を整形して」→ 4.6 は全件やってくれたが、4.7 は1件だけ。指示を正確に書き直す必要がある。
「CRITICAL: 必ず使え」が過剰起動を招く
旧モデルの渋さを克服するため書いた強い命令(必ず・絶対に・迷ったら使え)は、4.6 以降では効きすぎる。4.7 でツールやスキルが暴発するなら、文言を弱めるのが正解で、ガードを足すのは逆効果。
ベンチマーク上の「向上」も、移行直後はそのまま体感できないことがあります。たとえばコードレビュー用途では、4.7 はバグ発見力が上がっているのに、4.6 向けに「重大な問題だけ報告して」と書いた harness をそのまま使うと、4.7 がその指示に忠実すぎて報告件数が減り、見かけ上 recall が下がることがあります。これは能力低下ではなく指示追従の副作用なので、発見段階では「確信度と深刻度を添えて全件報告させ、絞り込みは後段で行う」プロンプトに変えると本来の精度が出ます。
Claude Code 側のアップデート
Anthropic 製のターミナル / IDE エージェント Claude Code も、Opus 4.7 と同時に大きく動きました。
デフォルト effort が xhigh に
Claude Code は今回からデフォルトで xhigh を使う。従来より深く考えた結果を返すのが標準になり、体感は一段重く・賢くなる。待ち時間が伸びるトレードオフはあるが、PR ベースで動かす運用と噛み合う変化。
バグ + 設計問題のレビュー
PR を出す前にバグと設計問題を検出するレビューを走らせる運用が現実味を増した。コードスタイルの軽い指摘ではなく、本当にまずい設計判断を狙う。人レビューの前に AI 指摘が来る形にできる。
オートモードの拡大
より自律的に動くモードの提供対象が広がり、長い対話を任せやすくなった。最初の1ターンでタスク・意図・制約を出し切るほど、4.7 の自律性が活きてトークン効率も上がる。
開発フローとの統合
PR 出す前にレビュー → 指摘を直す → Playwright / Vitest を走らせる → マージ、という流れが、AI とテスト基盤の組み合わせとして現実味を増している。
モデル選択の指針
「Opus 4.7 を選ぶか、Sonnet で十分か」の判断軸を整理します。
Opus 4.7 を選ぶケース
① 大規模 / 複雑なコーディング、② 長時間動くエージェント、③ 設計レビュー / アーキテクチャ判断、④ Vision を業務で使う、⑤ 厳密な命令追従が必要な定型業務。
Sonnet を選ぶケース
① 大量の短いタスク(チャットボット、要約、分類)、② コスト最優先、③ 反応速度を最重視、④ 雑に試したいプロトタイピング段階。
Haiku を選ぶケース
① 軽量分類 / 検索 / 抽出、② 大量並列に呼びたい、③ Edge ランタイムで動かす低遅延 AI、④ コストを1桁絞りたい場面。
プロダクト内ハイブリッド
Sonnet で大半・Opus でここぞの場面、を1プロダクト内で混ぜるのが実務の標準。全部 Opus だと コスト暴発、全部 Haiku だと品質不足、というジレンマの中庸を取る。
周辺の動き ── Anthropic の企業展開
Opus 4.7 リリース後の数週間で、Anthropic はモデルの周辺で企業向け施策を連発しています。
金融サービス進出
2026年5月、Anthropic は金融サービス向け AI エージェントを Opus 4.7 上で発表。Microsoft 365 統合やデータパートナーシップと組み合わせ、金融機関の業務に深く食い込む方向。
Claude for Small Business
QuickBooks / PayPal / HubSpot / Canva / DocuSign / Google Workspace / Microsoft 365 とのエージェント連携。小規模事業者向け AI 自動化がパッケージで提供される。
エンタープライズ JV
大手金融との大型 JV が報じられ、大企業向け AI サービスを独立した会社として展開する方針が示された。
非営利 / インフラ系
非営利財団とのパートナーシップや、コンピュート契約による使用上限引き上げが報じられた。非営利・公共領域とコンピュート供給網と企業導入が同時に走っている。
競合 ── セキュリティ領域への拡大
Opus 4.7 リリースに前後して、競合からも AI によるセキュリティ自動化 のイニシアチブが相次いで発表されました。コードレビュー、脅威モデリング、パッチ検証、依存リスク分析、検出と対処を 開発フローの中に組み込む ことを狙う流れです。
セキュリティが次の主戦場に
「AI でコードを書く」段階から「AI で開発フロー全体の品質・セキュリティを管理する」段階へ、競争軸が広がっている。どのモデルを使うかだけでなく、どのエージェント / ツールチェーン上で動かすかで選ぶ時代になりつつある。
サプライチェーン文脈
2026年5月の Mini Shai-Hulud Worm や Next.js のセキュリティリリース のような出来事が同時期に重なり、AI × サプライチェーン × セキュリティが同時に焦点化した。
4.7 のリアルタイム安全機能
Opus 4.7 では、禁止・高リスクな話題に関わるリクエストでは拒否が返る場合がある。サイバー領域の濫用を抑える方向の調整が入っている。
ユーザーへの意味
モデル単体の性能勝負から、エージェント + 開発フロー全体の勝負へ。テストや監視と組み合わせて「人が結果を見る」前提を維持することが、これまで以上に重要になる。
採用のチェックリスト
「Opus 4.7 を実プロダクトに採用するか」の判断材料を整理します。
注意点とリスク(失敗例で理解する)
派手なリリースですが、過信しないために知っておきたい点を、実際に起きがちな失敗の形で整理します。
失敗例: xhigh でコストが膨らむ
現象: 先月の API 請求が約2.5倍に。原因: チーム全員が Claude Code をデフォルトの xhigh のまま使っていた。確認手順: 請求の出力トークン量を effort 別に集計し、xhigh のルートが大半を占めていないか見る。回避: デフォルトを high に下げ、難バグ調査など限定ルートだけ xhigh、task budget で上限を付ける。
失敗例: 移行直後に 400 エラー
現象: モデル ID を 4.7 に変えた途端に全リクエストが 400。原因: 4.6 用の budget_tokens や temperature が残っていた。確認手順: エラーの message を読む(廃止パラメータ名が出る)。回避: 該当フィールドを削除し、thinking を adaptive に、深さは effort で調整する。
失敗例: 指示を全件と思ったら1件だけ
現象: 4.6 では全件処理されたのに、4.7 で1件しか処理されない。原因: 4.7 が指示を字義どおりに解釈し、暗黙の一般化をしない。確認手順: プロンプトに「すべての項目に対して」と明示があるか確認。回避: 対象範囲・件数・終了条件を明文化する。
失敗例: 思考の進捗が見えない
現象: 応答前に長い無音が続き、固まったように見える。原因: 4.7 は思考本文が既定で omitted。確認手順: リクエストの thinking 設定を見る。回避: display: "summarized" を付け、要約思考をストリーミング表示する。
「新しいモデル = 何でもできる」という錯覚を避け、コスト・パラメータ・指示の3点を最初に整えることが、Opus 4.7 を活かす一番のコツです。
Claude Opus 4.7 に関するよくある質問
Q. Opus 4.6 と 4.7、どっちを使うべき?
A. 新規利用は 4.7 一択 です。価格は同じで、長時間タスク・高解像度 Vision・命令追従が改善されています。ただし 4.6 用コードはそのまま動かず、budget_tokens / temperature などで 400 になります。既存案件で 4.6 が安定運用中なら、業務影響を見ながら段階移行で構いません。
Q. xhigh はいつ使えばいいですか?
A. 難しい1回限りのタスク(大規模リファクタの計画立案、難バグの調査、長文の構造化)で使うのが目安です。Claude Code では既定が xhigh ですが、API では「デフォルト high、ここぞで xhigh」が基本。常時 xhigh は出力トークンが膨らみ、コストが2〜3倍になりえます。
Q. high と xhigh でコストはどれくらい違いますか?
A. 同一タスクでも xhigh は思考と出力のトークンが増え、概算で 2〜3倍 になることがあります。Opus 4.7 は入力 $5 / 出力 $25(100万トークン)で、出力単価が入力の5倍。xhigh は出力側が伸びるので差が出やすいのです。ルートごとに count_tokens と請求で実測し、effort を決めてください。
Q. 4.7 で thinking の budget_tokens が使えません。なぜ?
A. Opus 4.7 では thinking: {type: "enabled", budget_tokens: N} や temperature / top_p / top_k が 廃止され、送ると 400 エラーになります。thinking: {type: "adaptive"} を使い、思考の深さは output_config.effort で制御します。
Q. 高解像度 Vision でトークンが増えると聞きました。
A. はい。Opus 4.7 は長辺 2,576px / 約3.75メガピクセルまで扱え、フル解像度の画像1枚で最大 約4,784トークン(従来は約1,600トークン上限)まで増えます。およそ3倍です。必要なときだけ高解像度で送り、不要なら事前に縮小するのがコスト面で有効です。
Q. Bedrock / Vertex AI / Foundry で同じモデル ID ですか?
A. プラットフォームごとに ID 表記が違います。Anthropic API では claude-opus-4-7、Amazon Bedrock では anthropic. プレフィックス付き、Vertex / Foundry は各社の命名規則に従います。また task budget などのサーバーサイド機能は Bedrock / Vertex / Foundry では使えない場合があるので、使うクラウドのドキュメントを必ず確認してください。
Q. コストが暴走しないために何をすべき?
A. ① API 月額上限、② task budget(beta、最小20,000トークン)、③ effort をルート別に設計(デフォルト high)、④ キャッシング(同じ前提は再利用)、の4点を最初に積みます。Vercel の請求対策 と同じく、止める仕組みが最大のコスト戦略です。
Q. Opus 4.7 を学ぶ最短ルートは?
A. ① Claude.ai や Claude Code で同じタスクを high と xhigh で流して挙動とコストの差を体感する、② 4.6 用プロンプトを 4.7 に移して「字義どおり化」の影響を確認する、③ API で effort と task_budget を組み合わせて上限管理を試す、の3ステップが王道です。TypeScript など型の多い領域で試すと改善を実感しやすいです。
参考リンク
- Anthropic: Introducing Claude Opus 4.7
- Anthropic: News
- Anthropic Docs: Models overview(モデル仕様・価格)
- Anthropic Docs: Effort パラメータ
- Anthropic Docs: Migration guide(4.7 への移行・破壊的変更)
- Anthropic Docs: Pricing