はじめに

2026年4月16日、Anthropic が Claude Opus 4.7 を一般提供（GA）しました。2月にリリースされた Opus 4.6 から約2ヶ月での更新です（Anthropic 公式発表）。

料金は $5 / $25 per 1M tokens で 4.6 から据え置きです。ここで悩ましいのは「料金が同じなら、何も考えずに切り替えてよいのか？」という点です。

結論から書きますと、切り替え自体は勧めますが、脳死で model 指定だけ書き換えるのはもったいないです。4.7 では effort レベルや 1M コンテキストの扱いが変わり、使い方次第で成果もコストも変わります。

筆者は個人プロジェクトのリポジトリと個人のエージェント基盤で Opus 4.6 を約2ヶ月運用してきました。今回の移行で実際に引っかかった点、設計を見直した点を、10 項目のチェックリストにまとめて共有します。

この記事の前提:

読者はすでに Claude Code または Anthropic API を日常的に使っていること
Opus 4.6 をベースに運用を組み立てていること
チーム運用の場合は .claude/settings.json を共有管理していること

なお、Anthropic が社内運用している未公開モデル「Claude Mythos」については、2026-04-07 の Project Glasswing で既に公表済みで、4.7 の発表時にも改めて言及されました（CNBC 報道）。これは一般提供外なので本記事では扱いません。公開モデルとして「現時点で触れる最強の汎用モデル」という立ち位置で 4.7 を評価します。

性能差分サマリ

まず数値で 4.6 と 4.7 の差分を整理します。以下は Anthropic 公式発表と VentureBeat による比較から拾った主要指標です。

指標	Opus 4.6	Opus 4.7	他社比較
SWE-bench Pro	53.4%	64.3%	GPT-5.4: 57.7% / Gemini 3.1 Pro: 54.2%
SWE-bench Verified	80.8%	87.6%	Gemini 3.1 Pro: 80.6%
Rakuten-SWE-Bench（本番タスク解決数）	1x	約3x	─
エージェント推論（マルチステップ）	基準	+14%	ツール誤用は約 1/3
画像入力最大解像度	1.15MP	3.75MP（長辺 2,576px）	─
1M コンテキスト	標準 API 価格（4.6 時点で対応済み）	標準 API 価格・取り回し改善	─
金融業務（General Finance）	0.767	0.813	─

出典: Anthropic "Introducing Claude Opus 4.7" / VentureBeat / SWE-bench Pro 公式ランキング

数値だけ見ると「コーディング用途では再度リードを奪還した」と読めます。ただし筆者の実感ではベンチマーク数値と実業務の体感はズレることもあり、「2倍ラクになった」という感覚は正直ありません。ツール誤用が減った、長時間のエージェント運用が止まりにくくなった、という形で効きます。

新要素の 5 点

1. xhigh effort level の追加

これまで effort は low / medium / high / max の 4 段階でしたが、4.7 では high と max の中間に xhigh が追加されました。

筆者の使い分けの初期案はこうです:

high: 通常のコーディング、コードレビュー
xhigh: 複数ファイルにまたがる設計変更、長めのデバッグ
max: 本当に詰まったときのアーキテクチャ再設計、重要判断

max は推論コストがかさみやすく、ログを見ると思考トークンが一気に増えます。xhigh は max の7〜8割程度の思考量で、実用タスクの多くをカバーできるというのが初動の印象です。ただしまだ 1 週間の運用なので、この比率はタスク種別でブレが大きい点は留意しておきたいところです。

2. `/ultrareview` コマンド

Claude Code 内で使える新スラッシュコマンドです。「ベテランレビュアーのようにバグと設計課題を洗い出す」レビューセッション専用モードで、通常の対話よりも指摘が踏み込みます。

筆者が試した限り、自分が書いた PR 草案に /ultrareview を当てると、ロジックの穴だけでなく「この命名は 3 ヶ月後の自分が読んで意味が取れない」といった設計観点まで指摘が入ります。いわゆる普通のコードレビューの 1.5 倍くらいの粒度で返ってきます。

後述しますが、毎回使うとコストが跳ねます。PR マージ前の最終チェックに絞るのが運用しやすいです。

3. 1M コンテキストの取り回し改善

1M トークンのロングコンテキスト自体は 4.6 時点で標準 API 価格として提供されていましたので、「4.7 で新たに標準価格化された」というのは誤解です。4.7 では新しい tokenizer により同じテキストでもトークン数が体感で約 35% 増えるケースがあり、実入力量のカウントには注意が必要です。

一方で、長文入力時のツール誤用や指示崩れが減ったため、1M コンテキストの「実用域」は広がったと感じます。長大なログ解析や、リポジトリ全体を読ませて設計提案させるような用途で運用しやすくなりました。ただし後述する通り、1M を常時使うとキャッシュ戦略が崩れるので、使い所は選ぶ必要があります。

4. ファイルシステム記憶の精度向上

エージェントがファイルシステム（memory ディレクトリや CLAUDE.md など）に書き込み、後のセッションで参照する機能の精度が上がったと公式が述べています。

筆者の運用では docs/memories/ のような専用ディレクトリに preferences.md / decisions.md / context-log.md を置いています（名前は好みで構いません）。4.6 では「書いたはずの方針を忘れて毎回確認してくる」ことがありましたが、4.7 では減りました。ただ、これは気持ちレベルの評価で、定量化は別途必要です。

5. 視覚自己検証

自分で生成した成果物（.docx の赤入れ、.pptx の編集、UI スクリーンショット）を視覚的に検証し、崩れがないかをエージェント自身が確認する挙動が標準化されました。

筆者は Qiita 記事の公開後に表示崩れを自分で確認する運用（playwright でスクショ → Claude に見せる）をしていますが、4.7 ではこの往復でエージェントの突っ込みが具体的になり、「この表のセル 3 が折返しで読みにくい」といった粒度で返ってきます。

移行チェックリスト 10 項目

ここからが本題です。移行時に順番に確認していく 10 項目を紹介します。

[1/10] model 設定の切替方針

まず決めるのは「一気に 4.7 に切り替えるのか、段階的にロールアウトするのか」です。筆者は次の順で切り替えました。

検証用リポジトリで 3 日間、日常タスクを 4.7 で回す
副業プロジェクトで 1 週間、本番投入
本業・重要プロジェクトに展開

.claude/settings.json で model を指定している場合、環境別に分けます。

{
  "model": "claude-opus-4-7"
  // 注: `fallbackModel` は現時点で公式の settings.json 仕様に存在しません。
  //      以前の記述で同フィールドを紹介していましたが、公式に確認が取れないため削除しました。
}

API 側では環境変数 ANTHROPIC_MODEL=claude-opus-4-7 を staging / production で段階展開するのが無難です（ANTHROPIC_MODEL は Claude Code / 各 SDK で参照される環境変数で、挙動は利用側の SDK 実装に依存します）。

[2/10] effort レベルの再設計

4.6 時代に effort を high 固定で回していたチームは、ここで再設計の機会です。xhigh が増えたことで 5 段階になったため、タスク種別ごとに割り当て直すのが良いです。

筆者の初期マッピング:

タスク種別	effort
定型タスク（ログ整形、ファイル移動）	low or medium
通常のコード修正	medium or high
複数ファイルのリファクタ、テスト追加	high
アーキテクチャ設計、長時間デバッグ	xhigh
本当に困ったときの最後の砦	max

後述する3月の劣化騒動があったため、デフォルト effort がいつの間にか medium に落ちていないかは、必ず claude --verbose または環境変数で明示的に確認しておきます。

[3/10] Adaptive Thinking の扱い

これは 4.7 移行と直接関係はないものの、ここで合わせて整理しておきたい項目です。

2026 年 2 月 9 日に Adaptive Thinking（思考量の自動調整）が強制有効化されていた時期があり、Anthropic の Boris Cherny 氏が「一部のターンで推論トークンをゼロに割り当てていた」とバグを公式に認めました（Fortune 記事）。

重要: CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING は公式ドキュメント上 Opus 4.6 / Sonnet 4.6 専用の環境変数で、Opus 4.7 では "no effect"（効果なし）と明記されています。つまり 4.7 ではこのフラグによる無効化はできません。

4.7 で「思考ゼロ」を避けたい場合は、effort レベルを明示指定して挙動を固定する方針に切り替えます。

# Opus 4.7 での推奨: effort を明示して挙動を固定する
export CLAUDE_CODE_EFFORT_LEVEL=high

Opus 4.6 系を引き続き併用する場合は、従来どおり adaptive thinking 側のフラグも組み合わせます。

# Opus 4.6 / Sonnet 4.6 を使う場合のみ有効
export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1
export CLAUDE_CODE_EFFORT_LEVEL=high

筆者の運用では .zshrc に effort 明示を入れっぱなしにし、4.6 系を使うプロジェクトでだけ .env.local で DISABLE_ADAPTIVE_THINKING を上書きしています。

[4/10] 1M コンテキストの使い所

標準価格になったとはいえ、1M トークン × 入力単価を計算すると 1 セッションあたりのコストは普通に高いです。1M を使うべきケースを限定しておきます。

筆者の基準:

リポジトリ全体を読んで設計提案させる（最初の 1 回だけ）
長いログ（数十MB のエラーダンプなど）の原因分析
議事録・長文資料の要約

逆に、以下は 1M に入れない方がいいです。

日常のコード修正（必要なファイルだけ読ませる）
対話型のブレスト（長くなっても自然と compact される）

[5/10] プロンプトキャッシュ設計

1M が安くなっても、プロンプトキャッシュを効かせた方が圧倒的に安いです。Claude Code 4 月アップデートで cache 制御（1時間 / 強制5分）が追加されました。

具体的には、CLAUDE.md の内容は長文でも差分が出ないようにするのが効きます。1 時間以上セッションが続く運用（Routines や長時間エージェント）では、1 時間 TTL のキャッシュを明示指定します。

API 側で書くなら、Anthropic SDK の cache_control を CLAUDE.md 相当のブロックに付けて、ユーザーメッセージ側は付けない、というのが基本形です。

messages = [
    {
        "role": "user",
        "content": [
            {
                "type": "text",
                "text": long_system_context,
                "cache_control": {"type": "ephemeral", "ttl": "1h"},
            },
            {"type": "text", "text": user_prompt},
        ],
    }
]

キャッシュヒット率はログで確認できます。筆者は 70% 以上をキープするチューニングをしています。

[6/10] サブエージェント推論強化の恩恵

マルチステップ推論が 14% 改善、ツール誤用が 1/3 に減ったということは、サブエージェントに仕事を任せても迷子になりにくいということです。

4.6 までは「深い階層にサブエージェントを積むと指示が崩れる」と感じることがあり、1 階層までに抑えていました。4.7 では 2 階層（統括PM → プロジェクトPM → 実行エージェント）でも挙動が安定します。

ただし、これは定性的な印象なので、チームで採用する前に代表的なタスクで before / after のログを比較することをおすすめします。

[7/10] `/ultrareview` の運用ルール

筆者のチーム運用ルール（暫定）:

PR を出す前に、作成者自身が /ultrareview を 1 回実行する
指摘は全件対応ではなく、「3 ヶ月後の自分が読んで困らない」観点でフィルタする
人間レビュアーの代替ではなく、前段フィルタとして扱う

/ultrareview は effort 消費が高めなので、差分が 500 行を超えるような PR では分割実行を検討します。毎日使うのではなく、週 2〜3 回の中量〜大量変更に絞るのが費用対効果は良いです。

[8/10] 画像入力解像度の見直し

3.75MP（長辺 2,576px）まで扱えるようになったので、4.6 時代に「画像を小さくリサイズしてから渡す」前処理を入れていたなら、見直せます。

筆者の実感では、スクリーンショット分析や UI レビュー系のタスクで以下が実用域に入りました。

フル解像度の Figma 画面 1 枚を丸ごと解析
複数ページの PDF（文字が小さい契約書）を1ページずつ解析
ダッシュボードのスクショを分割せずに見せる

ただし画像トークンも消費するため、大量の画像を投げるパイプラインではサイズ指針を再設計します。3.75MP 相当を 10 枚投げると、それだけでしっかり予算を食います。

[9/10] Auto mode（権限承認の自動化）

ここで扱う Auto mode は、Claude Code の permission mode の 1 つで、ツール実行時の権限承認を自動化するモードです。effort（推論量）を自動で上下させる機能ではない点に注意してください。以前の記述で「effort 自動調整」と説明していたのは誤りでしたので訂正します。

permission mode の位置づけを整理します。

default: 都度承認を求める従来動作
acceptEdits: ファイル編集系の承認を自動化
plan: 実行せず計画のみ提示
Auto mode: 許可済みツールの実行承認を自動で通し、エージェントの停止を減らす

Auto mode は長時間エージェント運用や Routines と組み合わせると、承認ダイアログで止まらず走り続けられる点で効きます。一方、意図しないコマンドまで自動承認される可能性があるため、許可ツールの allowlist 設計と併用するのが前提です。

筆者の暫定運用:

信頼できるサンドボックス環境（個人リポジトリ、ephemeral 環境）でのみ Auto mode を有効
本番ブランチ・顧客データを触るセッションでは default のまま
Auto mode 併用時は .claude/settings.json の permissions.allow を明示的に絞る
推論量を上げたい場合は別途 CLAUDE_CODE_EFFORT_LEVEL などで effort を指定する（Auto mode とは直交した設定）

Auto mode はあくまで「承認を自動化する」ための仕組みで、品質（推論量）の保証ではありません。重要タスクで effort を固定したい場合は、前述の effort 明示指定と組み合わせます。

[10/10] Routines との組み合わせ

2026 年 4 月 14 日にプレビューが出た Routines（PCを閉じても動く自動実行ワークフロー、ITmedia 記事）は、Opus 4.7 のエージェント推論強化と相性が良いです。

筆者のテスト運用例:

毎朝: トレンド収集（/trend-check）→ 要約メール
毎晩: 経理入金確認（/update-finance）
週次: 活動レポート生成（/weekly-activity-report）

Routines で effort を xhigh に固定しておくと、「夜間に 50 記事草稿生成 → 朝レビュー」のような長時間運用が現実的になります。ただし次のコスト観点は読み飛ばさないでください。

コスト観点の注意

xhigh 常時 ON の罠

xhigh が便利だからといって、全タスクのデフォルトを xhigh にするとコストが跳ねます。筆者の短期実測（3 日間、同じタスクセット）では次の通りでした。

デフォルト effort	1 日あたりの推論トークン	月換算想定
medium（4.6 時代）	基準	基準
high	約 1.4x	約 1.4x
xhigh	約 2.1x	約 2.1x
max	約 3.3x	約 3.3x

注: これは筆者個人のタスク構成による数値で、コード修正中心です。リサーチ中心の業務ではブレます。

xhigh 常時 ON にすると、実感として「作業は速くなる」「コストは2倍」になります。作業時短の価値と天秤にかけて判断することになりますが、少なくともデフォルトを medium または high に戻し、タスクごとに上げる運用が無難です。

1M コンテキスト使いすぎの罠

1M が標準価格になったといっても、入力 100 万トークンを 1 回入れるだけで $5 です。キャッシュが効かない状態で雑に使うと月額が膨らみます。

長文資料を毎回頭から読ませるのではなく、初回で要約を作り、2 回目以降は要約＋差分を渡す、という設計を挟むのが実用的です。

アンチパターン

ここまでの内容を踏まえて、やりがちな失敗を整理します。

設定を変えずに model 指定だけ書き換える: 恩恵の半分しか得られない
全部 xhigh で回す: コストが 2 倍になるが品質向上は限定的
/ultrareview を毎回使う: 人間レビューを置き換えるつもりになると粒度が合わなくなる
1M を脳死で使う: 必要な文脈だけ選ぶ設計力が落ちる
Auto mode を信頼しすぎる: 重要タスクでは effort を明示
Adaptive Thinking を黙認: 挙動の変化に気づきにくくなる。env で明示制御
画像を高解像度のまま大量投入: 画像トークンで予算を食い潰す
サブエージェント階層を無闇に深くする: 4.7 でも 3 階層以上は破綻しやすい
キャッシュ設計を後回し: 月末の請求で慌てる

まとめ

Claude Opus 4.7 は、半年の実運用ノウハウが反映された長時間エージェント実用化バージョン、という位置づけが筆者にはしっくりきます。

Opus 4.6 は「エージェント初期世代」でした。ベンチマークは良くても、長時間走らせると指示が崩れる、ツールを誤用する、思考をサボる、といった課題が残っていました。4.7 はこの辺りが総じて底上げされています。SWE-bench Pro 64.3% という数値よりも、「ツール誤用 1/3、推論 +14%」という実務寄りの改善の方が効きます。

一方で、料金据え置きだからといって脳死切り替えはもったいないです。xhigh / 1M コンテキスト / プロンプトキャッシュ / Adaptive Thinking の扱いを見直してはじめて、このバージョンの恩恵を取りに行けます。

筆者自身は、本記事のチェックリストをベースに運用を組み直しています。3 ヶ月後に「実運用ログから見る Opus 4.7」という続編を書く予定です。

本記事で紹介した数値や挙動は 2026 年 4 月 17 日時点の観察に基づきます。Anthropic の今後のパッチや、内製モデル Mythos の部分公開など、数ヶ月単位で状況は変わります。最新情報は Anthropic 公式と Claude API Docs をあたってください。

参考文献