Claude Opus 4.7、SWE-bench Verifiedで87.6%——1Mコンテキストがコーディングの勝負どころを変えた
新機能・リリース 2026年04月21日
#Claude #Opus #4.7 #SWE-bench #Anthropic #コーディング

Claude Opus 4.7、SWE-bench Verifiedで87.6%——1Mコンテキストがコーディングの勝負どころを変えた

ニュース

Claude Codeで「複数ファイルまたぐ修正、10回に1回は読み違えるなぁ」と感じてた方、けっこういると思います。
実装→テスト→配線、みたいに3ファイル以上を同時に触る作業で、たまにAIが"別の文脈"に寄っていく瞬間。
あれが、今月のリリースで一段改善されました。
数字でそれが見えるようになったのが今回のニュースです。

Anthropicが2026年4月16日にリリースした最新モデル「Claude Opus 4.7」が、AIコーディングエージェントの標準ベンチマーク「SWE-bench Verified」(AIが実際のGitHubイシューを解決できるかを測る500問のテスト)で**87.6%**を記録しました。
4月20日時点のLLM-Statsの集計では、限定プレビュー版のClaude Mythos Preview(93.9%)に次ぐ2位。
一般ユーザーが使える範囲のモデルではトップに立っています(※他社モデルのスコアは同集計基準のLLM-Statsランキング表で後述)。

同時に、OpenAIが「検証したフロンティアモデル全てでVerifiedの学習データ汚染が見つかった」としてVerifiedスコアの報告を停止し、より難しいSWE-bench Proへの移行を推奨したことも波紋を広げています。

SWE-bench Verified leaderboard snapshot

これはつまり、AIコーディングの勝負どころが"長い文脈を保ったままミスなく動くか"に移ってきた、ということだと思います。

3行まとめ

  • 4/20時点のSWE-bench Verified(LLM-Stats集計)で、Claude Opus 4.7(4/16リリース、1Mトークン対応)が一般向けトップの87.6%
  • Gemini 3.1 Pro、GPT-5.2、オープン勢(MiniMax M2.5、Kimi K2.6、Qwen3.6)が80%前後で大混戦
  • OpenAIがVerified報告を停止してSWE-bench Proへ誘導、評価指標の見直しが業界横断で進んでいる

ポイント

Claude Opus 4.7の「1Mコンテキスト×マルチファイル強化」が、2ファイル以上触る実装で明確に効きます。
ランキングは2ポイント差の団子状態で、オープンウェイト勢もすぐ後ろにいます。
OpenAIの撤退は"負け"ではなく、ベンチマーク基準そのものを作り直す動き。


用語の整理(最初に2語だけ)

用語 ざっくり説明
SWE-bench Verified AIが本物のGitHub Issue(バグ報告)500問を自力で解決できるかを測るテスト。数字が高いほど実務のコーディングに近い力がある
コンテキスト(ウィンドウ) AIが一度に読める情報量。1Mトークンだと、小さめのリポジトリ全体を一気に渡しても覚えていられる

詳細

1. なぜ重要か——「長く覚えておける」が効く時代

2024〜2025年のコーディングAIは、「関数単位の生成」「1ファイル内の修正」には強かったものの、複数ファイルをまたいだ修正や、既存コードベースの規約に沿わせる作業はどうしても苦手でした。
1ファイル読み込んだ時点で情報がパンクして、2ファイル目を読む頃には1ファイル目の細部を忘れている。
このジレンマが、SWE-bench Verifiedのスコア伸び悩みの正体だったと言われています。

前はこうでした:

  • 8Kトークンで1ファイルをギリ保持→2ファイル目で1ファイル目の詳細が曖昧に→"それっぽい"修正が入る

これからはこう変わります:

  • 1Mトークンで10ファイル以上を同時保持→修正対象・呼び出し元・テストを全部覚えたまま編集→ブレにくい

Claude Opus 4.7の1Mコンテキスト×マルチファイルパッチ強化訓練は、この"忘れ問題"を物量で解決する設計です。

「マルチファイルパッチ」は短く言うと、「関数名を変える→それを呼んでいる全箇所を修正→関連するテストまで更新」の3点セットをまとめて正確にこなせるかどうかの話。
関数名変更/呼び出し元追従/テスト修正の連携がズレずに入るかが、実務で効く/効かないを分けます。

2. ランキングの中身——団子状態を正確に読む

2026年4月20日時点のSWE-bench Verifiedトップ10がこちらです。

順位 モデル名 スコア 提供元 備考
1 Claude Mythos Preview 93.9% Anthropic 限定プレビュー、一般利用不可
2 Claude Opus 4.7 87.6% Anthropic 4/16リリース、1Mコンテキスト
3 Claude Opus 4.5 80.9% Anthropic 前世代
4 Claude Opus 4.6 80.8% Anthropic Claude Code推奨
5 Gemini 3.1 Pro 80.6% Google
6 MiniMax M2.5 80.2% MiniMax オープン勢
6 Kimi K2.6 80.2% Moonshot AI オープン勢
8 GPT-5.2 80.0% OpenAI
9 Claude Sonnet 4.6 79.6% Anthropic
10 Qwen3.6 Plus 78.8% Alibaba Cloud オープン勢

ランキング全体の平均スコアは0.640(64.0%)。
これはあくまで集計値なので、ここに並んでるモデルが全部そのまま実戦投入可能、という意味ではありません。
実際に使える/使えないは、自社コードでの失敗率やPoC結果で判断するのが本筋かなと思います(本稿は出発点としての指標の読み方を紹介する立ち位置)。

注目ポイントが3つあります。

  • **Claude Opus 4.7だけが頭ひとつ抜けた87.6%**で、一般利用できるモデルでは2位以下に6ポイント差
  • 3位以下が80%前後に団子で、モデル選びの差は"スコア1%の違い"より"エコシステム"で決まる時期
  • オープン勢(MiniMax、Kimi、Qwen)が80%台に入ってきた——自社ホストできる選択肢が現実的に

Claude Code(Claudeをコマンドライン型で操作するツール)でOpus 4.7を切り替えられる環境だと、マルチファイル修正の体感が明確に変わります。
研修の題材で「レガシーコードのリファクタリング」をやってもらうと、4.6→4.7の差は初学者でも感じ取れるレベルです。

3. OpenAIがVerifiedから降りた理由——ベンチマーク戦争のターン終わり

もうひとつの重要な動きが、OpenAIがSWE-bench Verifiedスコアの報告を停止したこと。
「フロンティアモデル全てで学習データ汚染が見つかった」というのが公式理由で、SWE-bench Proへの移行を推奨しています。

ざっくり言うと、Verified(500問)はAIモデルの訓練時にテスト問題が"バレて"いた可能性があり、スコアが実力を正確に反映していないかもしれない、という懸念です。

Proについては評価設定(使うスキャフォールドや公開/非公開セットの違い)によってスコアレンジが大きく変わる点に注意が必要です。
mini-SWE-agentなど制約付きの評価構成では現状トップでも20〜40%台という数字が報じられている一方、別の評価構成では上位モデルがより高スコアを出すケースもあります。
同じ「Pro」でも、評価条件が違うと同列比較はできない、というのがここでの押さえどころ。

これは"OpenAIが負けたから撤退"ではなくて、ベンチマーク基準そのものを作り直したいという動き。
AIコーディングの評価軸が、1つ次の世代に進んだ節目かなと思います。

4. Claude Opus 4.7の具体的なメリット——現場で何が変わるか

ここは「公式発表ベース」と「第三者集計ベース」を分けて読むのがおすすめです。

① Anthropic公式発表ベース

項目 詳細
コンテキストウィンドウ 1Mトークン(日本語換算は文字種や内容で大きく変動するため参考値)
マルチファイルパッチ "同時修正"の訓練を強化、変数名や型の一貫性を保ちやすい
リリース日 2026年4月16日

② 第三者集計(ベンチマーク)

項目 詳細 出典
SWE-bench Verified 87.6%(4/20時点) LLM-Stats
SWE-bench Pro 評価構成により上位スコアは変動(本稿では具体値の一次ソース未確認のため記載せず) 複数集計サイト

ベンチマークの数値は「誰がどういう条件で測ったか」で変わるので、Anthropicの公式仕様第三者の集計スコアを分けて読むのが確実かなと思います。
Proの具体スコアを使いたい場合は、必ず一次の評価ページで最新値を確認してください。

実務で効くのは以下のような場面だと思います:

  • リファクタリング(関数名変更が呼び出し元まで正しく伝播)
  • 新機能追加(既存モジュールの規約を尊重したコードが出てくる)
  • バグ調査(複数ファイルのスタックトレースを追える)
  • コードレビューの下書き(PR全体の差分を読んで変更意図を整理できる)

Claude Code上で普通に動かす分には、モデル指定をclaude-opus-4-7に切り替えるだけです。
課金は前世代と同じ体系という話なので、触ってみて違和感がなければそのまま常用で問題ないかなと思います(料金の詳細は公式で確認してください)。

5. 影響(誰にどう効くか)

会社員エンジニアのあなた
「複数ファイルをまたぐ修正」をClaude Opus 4.7でやってみるのが一番わかりやすいテストです。
いきなり本番コードではなく、社内の個人プロジェクトや過去の自分のリポジトリで試してみてほしいです。
「あ、ブレなくなった」が短時間で体感できるケースも多いです。
逆に、単一ファイルの小規模修正だけならOpus 4.6でも十分なので、モデルをタスクで使い分けるのが現実的。

副業・フリーランスのあなた
クライアント側の「AIで開発速度を上げたい」ニーズに応える場合、Claude Opus 4.7はデフォルトの提案に入れていい水準です。
オープン勢(MiniMax、Kimi)もコスト面で強いので、**"高精度ならOpus 4.7、ボリューム捌きはオープン"**の使い分け提案をパッケージ化しておくと、見積もりに説得力が出ます。
SWE-bench Proの存在も覚えておくと、"ただスコア高いAIを使ってる"ではなく"難問に強いAIを選んでる"という説明ができます。

経営者・技術意思決定者のあなた
この数字は、エンジニア1人あたりの生産性が「モデル選定」によって変わり得る段階に入った可能性を示唆しています(具体の伸び幅は社内タスクとの相性で変わるので、PoCで実測するのが安全)。
チームにClaude Pro / Max / Claude Codeのライセンスを配布するか、オープンモデルを自社ホストするか、の経営判断のタイミングが近づいてきた、という見立てです。
Verified→Proへの基準シフトは、将来のベンダー選定にも影響するので、"今のスコア"ではなく"どの基準で評価しているか"を問う視点を持っておくと安心かなと思います。

6. Claude Code × Opus 4.7で最初に試したいこと

Claude Codeを使っている人向けの具体的な最初の一歩として、以下のプロンプトを紹介します。

  • プロンプト: 「このリポジトリの関数名 fetchUserDataretrieveUserData に変更して。呼び出し元もすべて追従してね。影響するテストも一緒に更新してください。」

このタスクは、単純に見えて"全ファイル検索→呼び出し元修正→テスト追従"の3段階をAIに任せる典型例です。
Opus 4.6とOpus 4.7で同じプロンプトを流して、失敗の"見逃し箇所"の数を比べてみるのがおすすめ。
数字で改善が見えるので、チーム内で共有するときの説得材料になります:)

今日の1アクション

Claude Codeを使っている方は、モデルをClaude Opus 4.7に切り替えて、直近のPull Requestを1本だけレビューしてもらってみてほしいです。
「マルチファイルの文脈を保てているか」を自分の目で確認するのがいちばん早い評価方法かなと思います。
Claude Code未導入の方は、今週の自分の作業で"3ファイル以上触った修正"を1つ思い出して、それをAIに任せたらどう変わるか想像してみるだけでも判断材料になります。

出典

画像の引用

著者

neco. 🐈‍⬛
AI活用コンサル/ITエンジニア歴20年。会社員として400人規模のAIリスキリング研修を統括しつつ、副業で経営者・個人事業主向けにAI導入〜実装をサポート中(経営3年目)。
毎月AIの仕事活用をテーマに勉強会も開催しています。
「AIを"知ってる"から"使える"へ」がモットー。
プロンプト700本以上を無料公開中 → ai-neco