Claude Opus 4.7は4.6から何が変わったのか

結論

Claude Opus 4.7は、Claude Opus 4.6の小さな修正版ではない。名前だけを見ると、4.6から4.7への変更は、単なるマイナーアップデートのように見える。しかし実際には、AnthropicがClaudeを「会話がうまい高性能モデル」から「長時間の仕事を任せられるエージェント型モデル」へ寄せていくうえで、かなり重要な転換点になっている。^[1]

最も大きな変化は、単発の回答能力ではなく、複雑な作業を途中で崩さず進める能力である。Opus 4.6もすでに優秀なモデルだったが、長いコード修正、複数ファイルにまたがる設計判断、ツール実行の失敗からの復旧、スクリーンショットや図表を読みながらの作業では、まだ人間が細かく監督する必要があった。Opus 4.7は、その監督コストを下げる方向に進化している。

Anthropicは、93タスクの社内コーディング評価でOpus 4.7がOpus 4.6より解決率を13%引き上げ、4.6やSonnet 4.6では解けなかった4つのタスクも解いたと説明している。外部まとめの比較でも、SWE-bench Proは53.4%から64.3%、SWE-bench Verifiedは80.8%から87.6%、Terminal-Bench 2.0は65.4%から69.4%へ上がったとされる。数字だけで見れば、特にコーディングとエージェント作業で明確な上昇がある。

ただし、これは「すべての人にとって快適になった」という意味ではない。Opus 4.7は、より直接的で、より文字通りに指示を解釈し、より多く考え、より多くのトークンを使う傾向がある。4.6の柔らかい会話、曖昧な依頼をうまく補ってくれる感じ、創作や壁打ちでの扱いやすさを好んでいた人にとっては、4.7は少し硬く、重く、時には融通が利かないように見える。^[2]

したがって、この記事の結論は単純である。Claude Opus 4.7は、4.6から大きく進化している。ただし、その進化は「雑談が気持ちよくなった」方向ではなく、「難しい仕事を任せられるようになった」方向である。日常的な文章作成や軽い相談では差を感じにくいかもしれないが、複雑なコード、長い作業、画像や図表を含む分析、専門文書のレビューでは、4.7は4.6より明らかに強い。

4.7は何を目指したモデルなのか

Claude Opus 4.7は、2026年4月16日に公開された。Anthropicはこれを、一般に利用できるClaudeの中で最も高性能な汎用モデルとして位置づけている。API、Claude製品、Claude Code、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundryで利用でき、価格はOpus 4.6と同じく、入力100万トークンあたり5ドル、出力100万トークンあたり25ドルである。^[1]

ここで重要なのは、価格が同じでも、体感コストは同じとは限らないという点である。Opus 4.7は新しいトークナイザーを使っており、同じテキストでも4.6より約1.0倍から1.35倍のトークンになる可能性がある。さらに、高いeffort設定では、モデルがより深く考えるため、出力トークンや推論関連の消費も増えやすい。したがって、Opus 4.7のコストを語るときは、価格表だけでは足りない。1つの仕事を終えるまでに、どれだけ試行錯誤が減るか、どれだけ人間の手戻りが減るかまで見なければならない。

Anthropicの狙いは、単に「もっと賢いチャットAI」を出すことではない。Claude Code、Claude Agent SDK、Claude Cowork、MCP、ツール利用、ファイルシステム記憶、長時間作業を含む、エージェント型の仕事全体を強くすることにある。Opus 4.7は、単体モデルというより、エージェント時代のClaudeエコシステムに合わせて調整されたモデルと見るほうが正確である。

この方向性は、初期利用企業のコメントにも表れている。CursorのMichael Truellは、CursorBenchでOpus 4.7が70%をクリアし、Opus 4.6の58%を上回ったと述べた。NotionのSarah Sachsは、複雑なマルチステップワークフローで4.6比14%改善し、ツールエラーが3分の1になったと評価した。RakutenのYusuke Kajiは、Rakuten-SWE-Benchで本番タスクの解決数が4.6の3倍になったと語っている。これらはすべて、短い会話ではなく、現実の業務フローの中で4.7がどう振る舞うかを示す証言である。

最大の進化はコーディングではなく「長く崩れないこと」

Opus 4.7の目立つ成果はコーディングにある。しかし、単にコードを書く能力が上がったと見ると、本質を見誤る。重要なのは、長い作業の途中で自分の目的を失いにくくなったこと、失敗したときに立て直しやすくなったこと、そして完了前に検証しようとする傾向が強くなったことである。

Opus 4.6も、単発のコード生成や小さな修正では非常に強かった。しかし、長いセッションになると、最初の制約を忘れる、別の実装方針へ流れる、同じエラーに何度も引っかかる、ツール結果の解釈が浅くなるといった問題が起きやすかった。これはClaudeだけの問題ではなく、エージェント型AI全般の弱点である。モデルは一見すると自然に会話しているが、長い作業では、過去の判断、途中の失敗、暗黙の制約を維持し続けなければならない。

Opus 4.7では、この長期一貫性が改善されている。VercelのJoe Haddadは、4.7がシステムコードに取りかかる前に、証明のような検討をする新しい挙動を見せたと評価している。CodeRabbitは、コードレビューのリコールが10%以上改善し、複雑なPRの中でも発見しにくいバグを拾えるようになったと述べている。WarpのZach Lloydは、Opus 4.6でも解けなかった厄介な並行性バグを4.7が解いたことを、実務上の強いシグナルとして挙げている。

ここで浮かび上がるのは、4.7が「実装者」だけでなく「レビューアー」に近づいたという点である。コードを書く前に前提を検討し、書いた後に検証し、失敗すれば修正する。もちろん人間のレビューを不要にするわけではないが、少なくとも4.6よりも、作業の最後まで責任を持とうとする傾向が強くなっている。

この変化は、個人開発や業務開発にとって大きい。AIに小さな関数を書かせるだけなら、4.6でも十分な場面は多い。しかし、仕様の整理、実装、テスト、ログ確認、再修正、レビューまでを一つの流れで進めるなら、4.7の価値は一気に高くなる。単発性能ではなく、作業完走率の改善こそが、4.7の中心的な進化である。

視覚理解の強化は、見た目以上に大きい

Opus 4.7のもう一つの大きな変化は、高解像度画像への対応である。従来のClaudeモデルでは、画像の長辺は最大1568ピクセル程度、約1.15メガピクセルが上限だった。Opus 4.7では、長辺最大2576ピクセル、約3.75メガピクセルまで扱えるようになった。単純に言えば、より細かい文字、表、図、UI、設計図、スクリーンショットを読めるようになった。^[2]

これは、単なる画質の話ではない。AIエージェントが実際に仕事をする場合、入力はきれいなテキストだけではない。管理画面のスクリーンショット、エラーダイアログ、グラフ、契約書の画像、PDF内の図表、UIデザイン、建築図面、化学構造式、特許図面など、現実の仕事には画像化された情報が大量に含まれる。4.6では読み取れなかった細部を、4.7では扱える場面が増えた。

XBOWのOege de Moorは、同社の視覚精度ベンチマークでOpus 4.6が54.5%だったのに対し、Opus 4.7は98.5%だったと述べている。Solve IntelligenceのSanj Ahilanは、化学構造式や複雑な技術図面の理解で大きな改善があり、生命科学分野の特許業務に役立っていると評価している。これは、視覚理解が単なる便利機能ではなく、専門業務の入口になりつつあることを示している。

一方で、高解像度化にはコストがある。画像1枚あたりのトークン消費は、従来の上限約1600トークンから、最大4784トークン程度まで増える可能性がある。つまり、スクリーンショットを大量に投げるワークフローでは、4.7のほうがはるかに多くのトークンを使うことがある。追加の精度が不要な場合は、画像を事前に縮小する必要がある。

この点も、4.7らしい進化である。できることは増えた。しかし、何でも高解像度で投げればよいわけではない。4.7は、情報量の多い画像を扱う仕事には強いが、運用者にはコスト設計を求めるモデルでもある。

指示追従は強くなったが、曖昧さには厳しくなった

Opus 4.7は、Opus 4.6よりも指示を文字通りに解釈する傾向が強い。これはAnthropicの移行ガイドでも明確に説明されている。4.6では、ユーザーが少し曖昧に書いても、モデルが意図を補ってくれることがあった。4.7では、特に低いeffort設定において、書かれていないことを勝手に一般化せず、依頼された範囲に作業を絞る。^[2]

これは、業務システムでは大きな利点になる。構造化抽出、契約書レビュー、仕様チェック、コンプライアンス文書、APIパイプラインでは、モデルが勝手に補完することは危険である。指示された範囲を守り、曖昧な点を曖昧なまま扱い、知らないことを捏造しないほうが信頼できる。

HexのCaitlin Colgroveは、Opus 4.7について、データが欠けているときにもっともらしい代替情報を作るのではなく、欠損を正しく報告すると評価している。これは、地味だが非常に重要な能力である。AIの失敗は、分からないことを分からないと言えないところから始まることが多い。4.7は、4.6よりもこの点で慎重になった。

しかし、個人利用では短所にもなる。曖昧な依頼を気持ちよく汲み取ってほしい人には、4.7は少し融通が利かないように見える。従来の4.6向けプロンプトで、「この流れでいい感じにやって」と書いていた場合、4.7では期待通りに動かない可能性がある。曖昧さを補う能力がなくなったのではなく、意図しない補完を避けるように調整されている。

この変化は、いわば「曖昧さ税」である。4.7をうまく使うには、依頼の範囲、出力形式、優先順位、やってはいけないことを、4.6より少し明確に書く必要がある。その代わり、明確に書いた指示はより忠実に守る。4.6が気の利く相談相手だとすれば、4.7は仕様書を重視する実務者に近い。

口調と文体の変化

Opus 4.7は、4.6より直接的で、意見をはっきり出しやすい。Anthropicの移行ガイドでも、長文執筆のスタイルが変わり、4.6の温かい文体よりも、検証を重視した直接的な表現が増える可能性があると説明されている。^[2]

この変化は、ユーザー体験の評価を大きく分けた。ReplitのMichele Catastaは、4.7が技術議論で押し返してくれるため、より良い判断を助ける「より良い同僚」のように感じると述べた。一方で、Pragmatic EngineerのGergely Oroszは、4.7を驚くほど戦闘的に感じ、Opus 4.6に戻ったと報じられている。どちらも矛盾していない。同じ「押し返し」が、ある人には有益なレビューに見え、別の人には扱いにくい態度に見える。^[4]

この文体変化は、創作や記事作成にも影響する。4.6は、柔らかく寄り添う文章や、ユーザーの意図を広げる文章に向いていた。4.7は、論点を絞り、曖昧な前提を指摘し、必要なら反論する方向に寄る。したがって、4.7で文章を書く場合は、「落ち着いた説明調」「読者に寄り添う」「断定しすぎない」など、文体の条件を明確にしたほうがよい。

これはモデルの劣化ではない。性格の変更に近い。Opus 4.7は、友好的な会話相手としてより、仕事を進める共同作業者として設計されている。そのため、4.6のような柔らかいClaudeを期待すると違和感が出る。しかし、技術レビューや設計判断では、この直接性がむしろ武器になる。

トークン消費とコストの現実

Opus 4.7の価格は4.6と同じである。しかし、価格が同じであることと、実際の支払い感覚が同じであることは別である。

第一に、新しいトークナイザーによって、同じ入力が4.6より多くのトークンに分割される可能性がある。Anthropicは、約1.0倍から1.35倍と説明している。つまり、プロンプトの文字数が同じでも、トークン数は増える場合がある。特に、多言語、構造化データ、長い仕様書、コード混在文書では、事前にトークンカウントを測り直す必要がある。

第二に、4.7は高いeffort設定でより深く考える。特に長いエージェント作業では、後半のターンでより多くの推論を使い、出力トークンも増えやすい。難しい問題で賢くなるためには、より多くの計算を使う。この関係は避けられない。

第三に、高解像度画像のトークン消費が増える。画像1枚で数千トークンを使う可能性があるため、UIスクリーンショットを何十枚も渡すような作業では、4.7の利用量は一気に膨らむ。

ただし、コスト増だけを見るのは片手落ちである。もし4.7が4.6より少ない試行回数でタスクを完了し、人間の修正回数を減らし、ツールエラーを減らすなら、最終的な「1タスクあたりのコスト」は下がる可能性がある。Hexは、low effortのOpus 4.7がmedium effortのOpus 4.6に近い品質を出すと評価している。Notionも、複雑なワークフローで改善しつつツールエラーが減ったと報告している。

したがって、4.7のコスト判断は単純ではない。軽い質問を大量に投げるなら、4.7は過剰で高く感じる。難しい仕事を完了させるなら、4.6で何度もやり直すより安くなる可能性がある。Opus 4.7は、単価で選ぶモデルではなく、完了率で選ぶモデルである。

effort、task budget、xhighの意味

Opus 4.7では、effortの扱いがより重要になった。effortは、モデルにどれだけ深く考えさせるかを調整する仕組みである。Opus 4.7では、新たにxhighが追加され、highとmaxの間で、より細かく推論量を調整できるようになった。Claude Codeでは、Opus 4.7のデフォルトeffortがxhighに引き上げられている。^[1]

この変更は、4.7の本質をよく表している。簡単な質問に最大限考えさせる必要はない。しかし、複雑な設計、長いコード修正、曖昧なログ解析、複数資料の統合では、浅い推論では足りない。4.7は、低いeffortでは依頼範囲に厳密にとどまり、高いeffortではより多く考え、ツール利用も増えやすい。

また、task budgetという新しい考え方も導入された。これは、長時間のエージェント作業に対して、思考、ツール呼び出し、ツール結果、最終出力を含む総予算をモデルに知らせる仕組みである。人間で言えば、「この作業にはここまで時間を使ってよい」と伝えることに近い。モデルは予算を見ながら、どこに力を使うかを調整する。

これも、AIが一問一答から仕事単位へ移行している証拠である。従来は、プロンプトを投げて回答をもらうだけでよかった。しかし、エージェント作業では、どこまで調べるか、どこで止めるか、何を優先するかが重要になる。Opus 4.7は、こうした作業管理の概念をより前面に出したモデルである。

Claude Code品質低下騒動は何だったのか

Opus 4.7を語るうえで、リリース前後の反発を避けることはできない。Business Insiderは、Opus 4.7について、RedditやXで「4.6からの後退だ」という声が広がったと報じた。あるReddit投稿には2300件以上のアップボートが集まり、Xでも4.7は改善ではないという趣旨の投稿が1万4000件のいいねを集めたとされる。^[4]

不満の内容は多様だった。簡単なスペル問題で間違える、履歴書の書き換えで学校名や姓を作ってしまう、反応が遅い、考えていないように見える、攻撃的に感じる、トークンを消費しすぎる。Gergely Oroszのように、モデルを戦闘的に感じて4.6に戻ったユーザーもいた。一方で、Jeremy Howardは、4.7を「自分が作業していることを理解してくれる初めてのモデル」と評価したと報じられている。つまり、評価は極端に割れた。

その後、Anthropicは4月23日にClaude Code品質問題のポストモーテムを公開した。そこでは、ユーザーが感じた品質低下の原因として、3つの製品レイヤーの問題が説明された。^[3]

1つ目は、3月4日にClaude Codeのデフォルト推論effortをhighからmediumへ下げたことだった。これはレイテンシを下げ、使用制限に当たりにくくするための判断だったが、ユーザーからは知能が落ちたように感じられた。Anthropicはこの判断を誤りだったとし、4月7日に戻した。

2つ目は、3月26日のキャッシュ最適化バグだった。本来は、1時間以上アイドルだったセッションを再開するときに古い思考を一度だけ整理する設計だった。しかしバグにより、その後の各ターンで古い思考履歴が落ち続けた。結果として、Claudeは自分がなぜその編集やツール呼び出しを選んだのかを失い、忘れっぽく、反復的で、奇妙なツール選択をするように見えた。

3つ目は、4月16日に追加された簡潔化のシステムプロンプトだった。ツール呼び出し間の文章を25語以下、最終応答を100語以下に抑える指示が入り、これがコーディング品質を落とした。Anthropicは、より広い評価で約3%の性能低下を確認し、4月20日にこのプロンプトを戻した。

重要なのは、AnthropicがAPIと推論レイヤーは影響を受けていなかったと説明している点である。つまり、ユーザーが感じた「Claudeが劣化した」は、モデル本体だけの問題ではなかった。effort設定、キャッシュ、システムプロンプト、Claude Codeの製品設計が絡み合っていた。これは、エージェント時代のAI品質が、モデル単体ではなく、周辺システム全体で決まることを示している。

4.7は安全性も少し変わった

Opus 4.7では、サイバーセキュリティ関連のセーフガードも強化された。Anthropicは、禁止または高リスクのサイバー利用を検出してブロックする仕組みを導入し、正当な脆弱性研究、ペネトレーションテスト、レッドチーミングに使いたい専門家にはCyber Verification Programへの参加を案内している。^[1]

これは、Opus 4.7が単に強くなっただけでなく、危険な用途にも使われうる段階へ進んだことを示す。高度なコード理解、ツール利用、長時間の自律作業、スクリーンショット理解が強くなると、防御にも攻撃にも使える。Anthropicが4.7に追加したセーフガードは、より強力なMythos級モデルの広範な展開へ向けた実験台という意味も持っている。

安全性評価では、Opus 4.7は全体として4.6と似たプロファイルを持ち、正直さやプロンプトインジェクションへの耐性では改善がある一方、一部の有害領域ではやや弱い面もあるとされている。ここでも、4.7は単純な全方位改善ではない。能力が上がるほど、安全性の調整は複雑になる。

実務では、この変化にも注意が必要である。セキュリティ関連の正当な作業をしていても、4.7では以前より拒否が出る可能性がある。逆に、一般的な業務では、より強いセーフガードが安心材料になる。特に企業利用では、4.7の能力だけでなく、どのようなリクエストが止められるかを事前に検証する必要がある。

4.6から4.7へ移行すべき人

Opus 4.7へ移行すべきなのは、まず複雑なコード作業をClaudeに任せている人である。複数ファイルにまたがる修正、テストの失敗解析、ログやトレースからの原因調査、レビュー、設計判断を含む作業では、4.7の改善は実感しやすい。

次に、Claude Codeやエージェントワークフローを使っている人である。Notion、Rakuten、CodeRabbit、Cursor、Vercel、Warp、Replitなどの評価が示すように、4.7の価値は、ツールを使いながら長く作業する場面で出やすい。短い回答より、途中でエラーが起きても粘る力に価値がある。

また、画像、図表、スクリーンショット、UI、技術図面、特許文書、複雑なPDFを扱う人も、4.7の恩恵を受けやすい。高解像度画像対応によって、これまで読み落としていた細部を拾える可能性がある。特に、ソフトウェアの画面解析、ドキュメント分析、データ抽出、ライフサイエンスや法務の図表処理では大きい。

専門文書の分析にも向いている。Harveyは、BigLaw BenchでOpus 4.7が高い実質的正確性を示し、曖昧な文書編集や条項の識別で賢くなったと評価している。金融、法務、契約、研究資料のように、正確性と慎重さが求められる領域では、4.7の「分からないことを捏造しにくい」傾向が価値を持つ。

一方で、4.7へ急いで移行しなくてもよい人もいる。軽い雑談、短い要約、翻訳、柔らかい文章作成、創作の壁打ち、既存プロンプト資産が4.6で安定しているワークフローでは、4.7の差は小さいかもしれない。むしろ、直接的なトーンやトークン消費の増加が気になる可能性がある。

つまり、4.7は万能の置き換えではない。重い仕事には4.7。軽い相談や文体重視の作業には4.6。この分け方は、2026年春時点では十分に合理的である。

「たいした差はない」と感じる人がいる理由

Opus 4.7を使っても、あまり差を感じない人はいる。それは不思議ではない。理由は、4.7の改善が、短い会話では見えにくい領域に集中しているからである。

たとえば、1つの質問に答えるだけなら、4.6もすでに十分に強い。短いコードを生成するだけなら、4.7との差は目立ちにくい。文章を少し整えるだけなら、4.6のほうが柔らかく、好ましく感じることすらある。4.7の強みは、20分、1時間、数時間と続く作業、複数回の失敗を含む作業、画像やツールやファイルをまたぐ作業で見えてくる。

また、4.7は曖昧なプロンプトに厳しい。4.6ではいい感じに補ってくれた依頼が、4.7では文字通りに処理されることがある。そのため、プロンプトを変えずにモデルだけ変えると、「前より気が利かない」と感じる。

さらに、トークン消費の増加が心理的な印象を悪くしている。使用制限に早く当たる、出力が重い、考える時間が長い、画像でトークンが増える。これらが重なると、能力向上よりストレスのほうが先に見える。

したがって、Opus 4.7を評価するときは、単に「答えが良いか」ではなく、「どれだけ長い作業を完走したか」「どれだけ人間の介入が減ったか」「どれだけツールエラーから復旧したか」「どれだけレビューで有用な指摘をしたか」で見る必要がある。4.7は、短距離走より長距離走で評価すべきモデルである。

Opus 4.7をうまく使うための実務的な考え方

Opus 4.7を使うなら、まずプロンプトを4.6向けのままにしないことが重要である。曖昧な依頼を減らし、目的、制約、優先順位、出力形式、完了条件を明確に書く。特にコーディングでは、「何を変更してよいか」「何を変更してはいけないか」「どのテストを実行すべきか」「不明点があればどうするか」を書いたほうがよい。

次に、effortを作業に合わせる。軽い質問にxhighを使う必要はない。しかし、設計、レビュー、バグ調査、複数ファイル修正、長い調査ではhighまたはxhighを使う価値がある。4.7はeffortをより厳密に尊重するため、低いeffortで難しい仕事をさせると、本来の強みが出ない。

画像を使う場合は、必要な画像だけを渡す。高解像度画像は強力だが、トークン消費も大きい。UI全体を見せる必要があるのか、該当部分の切り抜きで十分なのかを考える。これは細かい節約ではなく、長い作業を安定させるための設計である。

最後に、4.7を「何でも察してくれる存在」として使わないことだ。4.7は、明確に任せると強い。曖昧に丸投げすると、意図しないほど厳密に動くことがある。人間のマネージャーが優秀なエンジニアに仕事を頼むときと同じで、成果物の条件をはっきり渡したほうがよい。

末尾補足 GPT-5.5と比べるとどう見えるか

ここまで見てきたように、Claude Opus 4.7の主題は、Opus 4.6からの進化である。ただ、同時期にGPT-5.5も登場したため、読者としては「結局、GPT-5.5と比べるとどうなのか」が気になる。

大まかに言えば、Claude Opus 4.7は、実リポジトリの修正、コードレビュー、仕様理解、視覚理解、慎重な専門文書分析に強い。一方、GPT-5.5は、ターミナル作業、Web調査、長文コンテキスト、データ分析、複数ツールをまたぐ実行力に強い。

数字で見ると、OpenAI公式の比較では、Terminal-Bench 2.0でGPT-5.5は82.7%、Claude Opus 4.7は69.4%で、コマンドライン上の複雑な作業ではGPT-5.5が大きく上回る。一方、SWE-Bench ProではClaude Opus 4.7が64.3%、GPT-5.5が58.6%で、実GitHub issue解決に近い評価ではClaudeが上回る。BrowseCompではGPT-5.5が84.4%、Claude Opus 4.7が79.3%で、Web調査系はGPT側が強い。MCP AtlasではClaude Opus 4.7が79.1%、GPT-5.5が75.3%で、ツール連携の一部ではClaudeが強い。^[5]

したがって、GPT-5.5とClaude Opus 4.7の関係は、単純な上下ではない。GPT-5.5は、作業を進めるエンジンとして強い。Claude Opus 4.7は、複雑な作業の意味を読み、設計やレビューの質を上げるモデルとして強い。

ただし、ここで注意したいのは、作業の途中でモデルを頻繁に切り替える運用である。Claudeで設計し、GPTで実装し、Claudeでレビューし、GPTで修正するという細かい往復は、理屈では強そうに見える。しかし実際には、文脈が割れる。途中で何を試したか、なぜその設計にしたか、どの失敗を避けたか、どの制約を優先したかが、モデル間で失われる。

そのため、実務では、メインモデルを1つ決めて作業を完走させるほうが安定しやすい。Claude Opus 4.7で始めたなら、設計、実装、レビューまでClaudeに文脈を持たせる。GPT-5.5で始めたなら、調査、実装、検証までGPTに文脈を持たせる。別モデルを使うなら、途中で雑に切り替えるのではなく、節目で差分、仕様、ログ、テスト結果をまとめて外部レビューとして渡すのがよい。

GPT-5.5は強い。Claude Opus 4.7も強い。しかし、AIエージェント時代の実務では、どちらが賢いか以上に、どちらに文脈を預けるかが重要になる。

最終判断

Claude Opus 4.7は、Opus 4.6から明確に進化している。特に、複雑なコーディング、長時間のエージェント作業、ツール利用、スクリーンショットや図表の理解、専門文書の慎重な分析では、大きな差がある。

しかし、4.7は4.6の完全な上位互換ではない。柔らかい会話、創作の壁打ち、軽い文章作成、既存プロンプトの安定運用では、4.6のほうが好まれる場合がある。4.7は、より厳密で、より直接的で、より重く、より仕事向きのClaudeである。

一言でまとめるなら、Opus 4.6は「よく分かってくれるClaude」だった。Opus 4.7は「最後まで仕事を進めようとするClaude」である。

この違いを理解して使えば、4.7は非常に強い。理解せずに4.6の延長として使うと、硬い、重い、気が利かない、トークンを食う、という印象になる。Claude Opus 4.7の評価が世界中で割れた理由は、まさにここにある。

Claude Opus 4.7は、単なる性能向上ではない。AIとの付き合い方を、会話から仕事の委任へ一段進めるモデルである。

参考文献・出典

1. [1]Introducing Claude Opus 4.7（Anthropic） ↩
2. [2]Migration guide - Claude API Docs（Anthropic） ↩
3. [3]An update on recent Claude Code quality reports（Anthropic） ↩
4. [4]Claudeの最新モデル「Opus 4.7」、トークンを消費しすぎると批判を集める（Business Insider Japan） ↩
5. [5]Introducing GPT-5.5（OpenAI） ↩