Claude Opus 4.5 → 4.6 移行期 - ゲーム開発者が体感した性能、トークン、ワークフローの変化

はじめに

2026年2月5日、AnthropicがClaude Opus 4.6をリリースしました。以前の記事（実戦データで見るゲーム開発者のAI活用法）で47日間の使用データを共有しましたが、その期間の前半はOpus 4.5、後半はOpus 4.6で作業したことになります。

この記事では、ベンチマークの数字と実際のゲーム開発現場での体感の違いを共に扱います。マーケティング資料の「画期的な性能向上」が 私のUnityプロジェクトで実際にどのような違い として現れたのか、率直に整理します。

---

1. 数字で見る Opus 4.5 vs 4.6

主要ベンチマーク比較

ベンチマーク	Opus 4.5	Opus 4.6	変化
ARC AGI 2 (新しいタイプの推論)	37.6%	68.8%	+31.2pp
OSWorld (エージェンティックなコンピュータ使用)	66.3%	72.7%	+6.4pp
Terminal-Bench 2.0 (ターミナル作業)	59.8%	65.4%	+5.6pp
SWE-bench Verified (実際のコーディング)	80.9%	80.8%	-0.1pp
Long-Context Retrieval (MRCR v2)	18.5%	76.0%	+57.5pp

アーキテクチャの変化

スペック	Opus 4.5	Opus 4.6
コンテキストウィンドウ	200K トークン	1M トークン
最大出力	8K トークン	128K トークン
Adaptive Thinking	なし	あり
Agent Teams	なし	あり
価格 (入力/出力)	$5 / $25 per M	$5 / $25 per M

二つの点が目立ちます：

1. SWE-bench（実際のコーディング）では差がほとんどない — コード作成能力自体は4.5と4.6が事実上同等です。
2. 推論（ARC AGI 2）と長文コンテキストでは圧倒的な向上 — 複雑な分析と大規模コードベースの探索で真価を発揮します。

---

2. 実際の体感差：Insightsデータが語ること

私のClaude Code Insightsデータで二つの時点を比較すると、興味深いパターンが見えます。

区間別使用量比較

指標	前半期 (1/5-2/12)	後半期デルタ (2/12-2/20)
期間	38日	8日
メッセージ	1,246	919
セッション	172	133
1日平均メッセージ	47.9	114.9
1日平均セッション	4.5	16.6
追加コード行数	+28,556	+27,767
修正ファイル数	188	208

8日間の1日平均メッセージが前半期比2.4倍に急増しました。 もちろん、これが全面的にモデルのアップグレードによるものではありません。プロジェクトが実装段階に突入した時点でもあり、ツールの熟練度が上がった効果もあります。しかし、体感上最も大きな違いを生んだのは 1M コンテキストウィンドウ です。

体感差 1：長文コンテキストの圧倒的改善

Opus 4.5の200Kコンテキストでは、長いセッションの後半でClaudeが 前で議論した内容を忘れる 現象が頻繁にありました。特にメモリリーク調査のように数十個のファイルを順次読む作業で、セッション中盤以降に序盤で読んだファイルの内容を不正確に参照する場合がありました。

Opus 4.6の1Mコンテキストに転換した後、同じタイプの大規模コードベース調査で 脈絡の消失が体感できるほど減りました。MRCR v2（長文コンテキスト検索）のスコアが18.5% → 76.0%に跳ね上がったのは誇張ではありません。

Opus 4.5 時代：
  "先ほど分析したGameResultLayer.csで..." → (すでにコンテキストから消失)
  → 再リクエストが必要 → 時間の無駄

Opus 4.6：
  30個のファイルを分析した後でも、最初のファイルの具体的な行を参照可能
  → 一つのセッションで全体調査を完結

体感差 2：Adaptive Thinkingの二面性

Adaptive ThinkingはOpus 4.6の核心的な新機能です。プロンプトの複雑さに応じて思考の深さを自動調節します：

Effort レベル	動作	適した作業
low	簡単なクエリで思考をスキップ	素早い確認、簡単な修正
medium	適切なレベルで思考	一般的なコーディング作業
high (デフォルト)	常に深く思考	複雑な分析、設計
max	無制限の深さで思考	極めて複雑な推論

実務での体感：

肯定的な側面 — メモリリーク分析やアーキテクチャ設計のような複雑な作業で出力品質が向上しました。特に「なぜこのアプローチが問題なのか」を説明する能力が向上しました。ARC AGI 2スコアが37.6% → 68.8%に跳ね上がった推論能力の向上が実際に感じられます。

否定的な側面 — トークン消費が目に見えて増加しました。Artificial Analysisによると、Opus 4.6は標準ベンチマークで 約5,800万出力トークンを生成しますが、Opus 4.5は2,900万でした。2倍の差です。Claude Codeは無制限使用ですが、APIを直接呼び出す場合はコストに直接影響します。

体感差 3：Agent Teams

Opus 4.6で公式導入されたAgent Teamsは、並列エージェント作業をサポートします。以前の記事で言及した通り、私のマルチエージェントセッションは 92回の並列オーバーラップイベント、111セッション に達します。

率直な評価： 概念は革新的ですが、安定性はまだ実験的レベルです。

✅ うまくいく場合：
   4つの領域のファイルを同時に修正（22ファイルを1セッションで完了）
   独立した調査タスクを並列実行

❌ 問題がある場合：
   エージェントがidleループに陥り無応答
   チームリードの状態リクエストにエージェントが応答しない
   エージェント間のファイル競合（同時修正時にnamespace import漏れ）

シングルエージェントセッションの完全達成率が〜80%であるのに対し、マルチエージェントセッションは体感で50-60%レベルです。AnthropicのInsightsレポートも「マルチエージェントより順次的なサブタスク分割が現在のところより安定的」と助言しています。

---

3. Opus 4.6 vs Sonnet 4.6：役割分担戦略

2月17日にSonnet 4.6もリリースされました。現在、私は2つのモデルを 役割に応じて分離 して使っています。

ベンチマーク比較

ベンチマーク	Opus 4.6	Sonnet 4.6	差
SWE-bench Verified	80.8%	79.6%	1.2pp
OSWorld	72.7%	72.5%	0.2pp
GDPval-AA (知識業務)	1606 Elo	1633 Elo	Sonnet 優勢
エージェンティック金融分析	60.1%	63.3%	Sonnet 優勢

衝撃的な事実： コーディングベンチマークでSonnet 4.6はOpus 4.6の97-99%レベルに到達しました。さらに一部の実務ベンチマークではSonnetがOpusを上回っています。

私の役割分担戦略

┌─────────────────────────────────────────────────┐
│            Plan / Design 段階 (Opus 4.6)           │
│  • アーキテクチャ設計および技術的意思決定                │
│  • 大規模コードベース分析（1Mコンテキスト活用）          │
│  • Gap Analysis および品質検証                        │
│  • メモリリーク調査（数十ファイルを巡回）                 │
│  • 複雑なマルチファイルリファクタリング設計              │
└─────────────────┬───────────────────────────────┘
                  │ 分析結果/設計ドキュメント伝達
                  ▼
┌─────────────────────────────────────────────────┐
│            Do 段階 (Sonnet 4.6)                    │
│  • 具体的なコード実装                                │
│  • バグ修正（明確なスコープ）                          │
│  • 単一/少数ファイルの修正                           │
│  • 反復的コード作業（ローカライゼーションなど）           │
│  • 素早いイテレーションが必要なデバッグ                 │
└─────────────────────────────────────────────────┘

この戦略が効果的な理由

1. コスト効率

Opus 4.6: $5 / $25 (入力/出力 per M tokens) Sonnet 4.6: $3 / $15 (入力/出力 per M tokens)

SonnetはOpusの60%のコストで97-99%のコーディング性能を提供します。コード実装段階でOpusを使うのは お金を燃やすこと に近いです。

2. 速度差

SonnetのレイテンシがOpusより著しく速いです。エージェンティックワークフローではセッションごとに数十回のAPI呼び出しが発生しますが、毎回の呼び出しごとの速度差が累積すると 体感生産性に大きな差 を生みます。

3. Opusの本当の強みは「思考」にある

SWE-benchのようなコーディングベンチマークでは互角ですが、 ARC AGI 2（推論）でOpus 4.6が68.8%と圧倒的 です。複雑なアーキテクチャ決定、全体コードベースを把握した後の設計判断ではOpusが確実に優位です。

---

4. トークン経済学：知っておくべきこと

Opus 4.6のトークン消費増加

最も重要な変化の一つです。Adaptive Thinkingが基本的に high レベルで動作するため、 出力トークンがOpus 4.5比で約2倍増加 しました。

モデル	標準ベンチマーク出力トークン	相対コスト
Opus 4.5	~29M	1x
Opus 4.6 (high)	~58M	~2x

Claude Codeユーザーへの直接的な影響：

• Pro/Max 購読：トークンクォータがより早く尽きます。以前は一日中使えていたとしたら、Opus 4.6では同じ作業でクォータがより早く減ります。
• API ユーザー：同じ作業に2倍の出力トークンコストが発生します。
• 対応戦略： /effort コマンドでeffortレベルを調節できます。簡単な作業では medium や low に下げる習慣が必要です。

実用トークン節約ガイド

# Claude Codeでeffortレベル調節
/effort low     # 簡単な修正、確認作業
/effort medium  # 一般的なコーディング
/effort high    # 複雑な分析（デフォルト）
/effort max     # 極めて難しい推論

私の使用パターン基準の推奨：

作業タイプ	推奨モデル	Effort
アーキテクチャ設計	Opus 4.6	high/max
メモリリーク調査	Opus 4.6	high
Gap Analysis	Opus 4.6	high
一般コード実装	Sonnet 4.6	-
単純バグ修正	Sonnet 4.6	-
ファイル検索/確認	Sonnet 4.6	-
ローカライゼーション作業	Sonnet 4.6	-

---

5. 1M コンテキストウィンドウの実務的影響

以前 vs 以後

200Kから1Mへの拡張は単に「より長い対話が可能だ」だけではありません。 作業方式自体が変わります。

Opus 4.5 (200K) 時代のワークフロー：

セッション 1：GameResultLayer.cs 分析 → レポートA出力
セッション 2：関連ファイル5個追加分析 → レポートB出力
セッション 3：レポートA+B統合 → 最終分析

3つのセッションにまたがる必要がありました。コンテキストが不足して1セッションですべてのファイルを分析できず、セッション間のハンドオフ時に情報損失が発生しました。

Opus 4.6 (1M) 現在のワークフロー：

単一セッション：関連ファイル30個全体分析 → 総合レポート出力

MRCR v2スコアが18.5% → 76.0%に跳ね上がったのはこの差です。コンテキストウィンドウ内にある情報を 実際に活用できる能力 が劇的に改善されました。

128K 出力の意味

以前は最大8Kトークン出力制限のため、大規模レポートを一度に生成できませんでした。「続けて」を繰り返したり、セクション別に分けてリクエストする必要がありました。

128K出力に拡張された後は、 数十個のファイルのメモリリーク分析レポートを一度の応答で完成 させることができます。ファイル別イシューリスト、優先順位分類、修正推奨事項まで一つの応答に含まれます。

---

6. ゲーム開発でOpus 4.6が輝く瞬間

事例 1：DOTweenシーケンスリーク全数調査

リクエスト："プロジェクト全体でDOTween Sequenceを生成しているがKill()を
           呼び出していないパターンを見つけてP0/P1/P2に分類して"

Opus 4.5：ファイル15個まで読んだ後コンテキスト限界 → セッション分割必要
Opus 4.6：関連ファイル全体巡回後、単一レポートとして出力

1Mコンテキスト + 向上した推論能力のシナジーが最もよく表れる事例です。

事例 2：ノード組み合わせシステムリデザイン

Skill Studioのノード組み合わせシステムをリデザインする際、既存コード全体を読んで新しいアーキテクチャの提案を受けました。Opus 4.6のAdaptive Thinkingが high で動作し、単に「こう変えてください」ではなく 「なぜ現在の構造が問題なのか、どのようなトレードオフがあるのか」 まで含んだ分析を提供しました。

事例 3：22個のファイル同時修正

Agent Teamsを活用して4つのタスク領域で22個のファイルを同時に修正したセッションがありました。このような規模の並列作業はOpus 4.5では事実上不可能でした。結果は完璧ではありませんでしたが（namespace import漏れなど）、 1セッションでこの規模の作業を試みることができること自体がパラダイムシフト です。

---

7. 率直な評価：アップグレードする価値はあるか？

Opus 4.5 → 4.6

観点	評価
コード作成能力	ほぼ同一 (SWE-bench 0.1pp差)
分析/推論能力	大幅向上 (ARC AGI +31pp)
長文処理	革新的改善 (MRCR +57.5pp)
トークン効率	悪化 (出力 ~2倍)
マルチエージェント	新機能、しかし不安定
総合	分析中心のワークフローなら必須アップグレード

単にコードを書く用途なら体感差は大きくありません。しかし 大規模コードベースを分析し、構造化されたレポートを生成し、複雑なアーキテクチャ決定を下す 私のような使用パターンでは確実なアップグレードです。

誰に推奨するか

✅ Opus 4.6が効果的な場合：
   - 大規模コードベース（数万行）分析が多い開発者
   - メモリリーク、クラッシュのような複雑な調査作業
   - アーキテクチャ設計および技術的意思決定にAIを活用する場合
   - Gap Analysis、コードレビューなど体系的検証ワークフロー

⚠️ Sonnet 4.6の方が良い場合：
   - 日常的なコード実装とバグ修正
   - 素早いイテレーションが重要なデバッグ
   - コスト制約がある環境
   - 単一/少数ファイル作業

---

8. 今後の展望

Opus 4.5から4.6まで わずか2ヶ月 でした。この速度なら4.7や次世代モデルも遠くないでしょう。現在の限界点を基準に期待すること：

1. マルチエージェント安定性改善 現在最大のpain pointです。エージェント無応答、idleループ、import漏れ問題が解決すれば並列作業の生産性が劇的に上がるでしょう。

2. トークン効率最適化 Adaptive Thinkingの思考の深さがより精巧になれば、簡単な作業での不必要なトークン消費が減る可能性があります。現在は high がデフォルトなので単純作業でも過度な思考をする場合があります。

3. 最初の試みの精度向上 私のInsightsデータで「Wrong Approach」が21件で最多摩擦原因でした。推論能力（ARC AGI 68.8%）はすでに大きく上がりましたが、 開発者の意図を把握する能力 はまだ改善の余地が大きいです。

---

おわりに

Opus 4.5から4.6への転換は 「より賢いAI」ではなく「より広く見るAI」 への変化です。コードを書く能力はほぼ同じですが、大規模コードベースを理解し構造化された分析を提供する能力が明らかに変わりました。

ゲーム開発者として最も価値ある変化は 一つのセッションでプロジェクト全体を鳥瞰できるようになったこと です。メモリリーク調査、リファクタリング設計、Gap Analysisのような作業がセッション分割なしで完結し、作業の流れがはるかにスムーズになりました。

ただし、トークン消費2倍増加は無視できない変化です。 Opusは設計と分析に、Sonnetは実装に — この役割分担が現在のところ最も合理的な戦略です。

---

参考資料

• Anthropic 公式 - Introducing Claude Opus 4.6
• Anthropic 公式 - Introducing Claude Sonnet 4.6
• What’s new in Claude 4.6 - Claude API Docs
• Claude Opus 4.6 Benchmark Analysis - Vellum
• Claude Opus 4.6 Performance Analysis - Artificial Analysis
• Sonnet 4.6 vs Opus 4.6 Comparison - NxCode