Noteees.ai
LLM / 生成 AI (更新: )

Claude Opus 4.7 の概要 — 何が変わったのか

Anthropic の最新フラッグシップ Claude Opus 4.7 の位置づけ、Sonnet 4.6 / Haiku 4.5 との使い分け、第三者ベンチマークが示した改善と回帰、絶対価格、採用前チェックリスト、私自身の三層運用方針までを整理します。

anthropic claude llm model-comparison agentic-workflow

TL;DR

  • フラッグシップ・推論特化モデル: Claude Opus 4.7 は Anthropic の最上位ティアで、複雑推論と長時間エージェント挙動を主戦場としています（出典: Anthropic Docs）。
  • コーディング系の大幅改善: SWE-bench Pro が 53.4% → 64.3%（+10.9pt、出典: Vellum / TNW）と一段上がり、競合 GPT-5.4（57.7%、出典: Vellum）を抜いた点が第三者レビューで注目されています。
  • エージェントの完走率向上: マルチステップタスクの tool エラーが約 1/3 に削減（Notion Agent ベンチ、出典: Anthropic 公式 news）、フォロースルーとループ耐性が改善（出典: Vellum）と報告されています。
  • 三層運用が現実解: 「設計判断・横断リファクタリング・長文構造化は Opus、通常開発は Sonnet 4.6、量産処理は Haiku 4.5」という使い分けが、コストと品質のバランスを取る最も素直な戦略です。

要点サマリ表

項目内容
何の話Claude Opus 4.7 の主要変化点と他モデルとの使い分け
結論全部 Opus は過剰投資。設計判断・長時間エージェント に絞れば費用対効果が立つ
影響範囲Claude Code 利用者・LLM API でエージェントを組む開発者
注目改善SWE-bench Pro +10.9pt、tool エラー約 1/3、長コンテキスト 1M トークン維持
注意点BrowseComp は -4.4pt の回帰。Web リサーチ主体の用途では別モデル併用も検討
評価の前提リリース直後（2026-04-16）の二次評価のみ。長期運用評価は今後待ち

背景: Claude モデルラインの整理

Anthropic は Claude モデルを 能力 × コストのトレードオフ で 3 ティアに分けています。世代ごとに Opus / Sonnet / Haiku が刷新されますが、世代番号は揃っていません。2026 年 5 月時点の現行は Opus 4.7（2026-04-16 リリース）/ Sonnet 4.6 / Haiku 4.5 です（出典: Anthropic Docs）。Sonnet 4.7 / Haiku 4.7 の公式アナウンスは現時点で確認できません（要検証）。

ティア性格主な役割現行モデル
Opus最高性能・高コスト複雑推論・設計判断・長文の構造化Opus 4.7
Sonnet性能とコストの中庸通常開発作業の主力Sonnet 4.6
Haiku最高速・低コスト大量バッチ処理・分類・要約Haiku 4.5

Opus 4.7 はこのピラミッドの頂点に位置し、「Sonnet で精度が足りないとき・タスクが長時間に渡るとき・失敗コストが高いとき」に投入される想定です。

flowchart TD
A["Opus 4.7<br/>$5 / $25 per Mtok<br/>複雑推論・長時間エージェント"]
B["Sonnet 4.6<br/>$3 / $15 per Mtok<br/>通常開発・QA の主力"]
C["Haiku 4.5<br/>$1 / $5 per Mtok<br/>分類・要約・量産処理"]
A --> B
B --> C
style A fill:#fde68a,stroke:#b45309,stroke-width:2px,color:#0f172a
style B fill:#bbf7d0,stroke:#15803d,stroke-width:2px,color:#0f172a
style C fill:#bfdbfe,stroke:#1d4ed8,stroke-width:2px,color:#0f172a

Opus 4.7 の主な特徴

公式 news / Docs と第三者ベンチマーク（Vellum / The Next Web、いずれも 2026-04-16 付け）で強調されているのは次の 4 点です。

1. 複雑推論・コーディングの安定性

数学・コーディング・複数ステップ推論で Opus 4.6 比の精度向上が報告されています。コーディング系では SWE-bench Verified が 80.8% → 87.6%（+6.8pt）、SWE-bench Pro が 53.4% → 64.3%（+10.9pt）、CursorBench も 58% → 70%（+12pt） と一段上がりました（出典: Vellum / TNW）。

「途中で前提を取り違える」失敗パターンが減ったという定性的記述も両者で一致しています。

2. 長コンテキストでの注意散漫低減

コンテキストウィンドウは 1M トークン が維持されています（出典: Anthropic Docs / TNW）。終盤の指示や中盤の重要情報を見落とすケースが減少したとされています。

ただし Opus 4.7 では 新トークナイザー が導入されており、同一入力テキストでも 最大 35% トークン数が増える と Finout が指摘しています（出典: Finout）。価格は据置でも 実費は増える可能性 があるため、本番投入前の見積もりは必須です。

3. エージェント挙動の安定性（tool エラー削減）

Anthropic 公式 news は Notion Agent ベンチで 「Opus 4.6 比 +14% 精度・少ないトークン・tool エラー約 1/3」 と報告（出典: Anthropic 公式 news）。Vellum も「fewer tool errors, better follow-through, loop resistance」と定性的に追認しています（出典: Vellum）。

Claude Code のような長時間タスクでは、この差が「最後まで走り切るか・途中で破綻するか」の差になります。

なお「タスク放棄率 60% 低下」「persistence deficit」という初期メディア由来の数値・呼称は一次裏付けが取れず本稿では採用しません（要検証）。

4. ナレッジカットオフと弱点（BrowseComp 回帰）

学習データのカットオフは Jan 2026（reliable knowledge cutoff、出典: Anthropic Docs）まで更新されました。一方で BrowseComp は -4.4pt の回帰（83.7% → 79.3%、出典: Vellum）が観測されており、Web リサーチ主体のエージェントでは GPT-5.4 Pro（89.3%、出典: Vellum） 等の併用も検討余地があります。

最新の API 仕様や論文は WebFetch / WebSearch を併用すべきで、モデル単体で十分という訳ではありません。

比較・代替手法（Sonnet 4.6 / Haiku 4.5 との使い分け）

判断軸 + 絶対価格（出典: Anthropic Docs、2026-05 時点）を併記します。価格は USD per 1M tokens（in / out）。

判断軸Opus 4.7Sonnet 4.6Haiku 4.5
API 入力単価$5 / Mtok$3 / Mtok$1 / Mtok
API 出力単価$25 / Mtok$15 / Mtok$5 / Mtok
Sonnet 比コスト倍率約 1.67x（in / out 同じ）1.0x約 0.33x
タスク複雑度高（多段推論・設計判断）中（通常コーディング・QA）低（分類・抽出・要約）
コンテキスト1M トークン1M トークン200k トークン
出力上限（出典: Anthropic Docs）128k tokens64k tokens64k tokens
エージェント長時間タスク◎○△（短いタスクのみ）
失敗コストが高いタスク◎（第一候補）○×
バッチで数千件処理×（コスト過大）△◎

注: バッチ処理では 50% 割引、プロンプトキャッシュ活用で最大 90% 割引が適用可能（出典: Anthropic Docs / Finout）。

Opus が活きる場面

  • アーキテクチャ設計判断: 選択肢比較・トレードオフ言語化・根拠明文化
  • 横断リファクタリング: 影響範囲を読み切る必要があるタスク
  • 長文の構造化: 数万字の議事録・仕様書の論点抽出・章立て再構築
  • 失敗コストが高い 1 ショット: 提案資料の最終仕上げ、契約レビュー

Opus が過剰な場面

  • 単発の短い QA（→ Sonnet / Haiku）
  • ボイラープレート生成（→ Sonnet）
  • 大量ログの分類・タグ付け（→ Haiku）
  • 単純な翻訳（→ Haiku、品質要件が高ければ Sonnet）

私の考察

Opus 4.7 で個人的に注目しているのは 「エージェント長時間タスクの完走率」 です。Claude Code のような環境では、1 タスクが 30 分〜数時間に渡ることも珍しくありません。

途中で破綻するモデルは、たとえベンチマーク数値が高くても 実用上は使い物にならない という体感があります。Anthropic が公表した 「tool エラー約 1/3」 という具体数値は、ベンチマーク数値以上に効く改善だと考えています。

ただし現時点での評価は リリース直後（2026-04-16）の二次評価が中心 で、長期運用での回帰やエッジケースは今後の検証待ちです。自分の手元の本番タスクで A/B するのが結局一番早い ことに変わりはありません。

もう一つ気になるのは コスト管理 です。Opus は Sonnet 比 約 1.67 倍、Haiku 比 入出力ともに約 5 倍。新トークナイザーで実トークン数も膨らむため「とりあえず Opus」では予算が膨らみます。私の運用方針は以下です。

  1. デフォルトは Sonnet 4.6、月次課金の Opus 比率は 30% 以下 を目標
  2. 設計判断・横断リファクタ・長文整理のみ Opus（複雑度高 × 失敗コスト高 × 30 分超のうち 2 つ以上）
  3. 月次レビューで「Sonnet で足りた事例」を洗い出し、投入基準を四半期更新

加えて、BrowseComp の回帰 は無視できません。Web リサーチ主体のエージェントを組むなら、Opus 単独に固執せず別系統モデルとの組み合わせを検討すべきです。

このサイト自体も Opus 4.7 を使った Claude Code で生成しているので、運用しながら どのタスクで Opus 投入が割に合ったか を別記事で振り返るつもりです。

参考リンク

関連する記事

方法論

LLM のコンテキストウィンドウとは何か — トークン制約と 1M 時代の判断軸

LLM が一度に処理できる『記憶の窓』であるコンテキストウィンドウについて、トークンの定義・入出力共有予算の実態・2026 年時点の主要モデル比較を整理します。1M トークン時代の選び方と落とし穴を、業務サイドにも分かる粒度で図解します。

llm context-window tokens cost-management +2
方法論

生成AI開発のセキュリティ：どこで何を守るか

生成AIを使った開発（Claude CodeやCursor等）でどこに何のセキュリティリスクが潜むかを、データフロー図で整理しました。プロンプトインジェクションや企業秘密の漏洩を、入力・出力・権限・量の4観点で多層に防ぐ設計をOWASP LLM Top 10とAWS IAM条件キーを交えて解説します。

security llm prompt-injection ai-agent +3