はじめに
サーバーワークスの池田です。
2026年4月16日に Claude Opus 4.7 がリリースされてから1か月、SNS や開発者コミュニティでは「Opus 4.7 が扱いづらくなった」という声が止みませんでした。Reddit には「Opus 4.7 はアップグレードではなく重大な後退だ」というタイトルのスレッドが立ち、48時間で 2,300 upvotes を集めています。
これを受けて Anthropic は 2026年4月23日に 公式の事故報告書（ポスト） を公開し、「3つの独立した変更が原因。すべて v2.1.116 で解決済み」と発表しました。ところがポストモーテム後も体感は止みません。本記事では、その理由を 二層構造 で整理し、現場で取りうる対処を5パターンにまとめます。
この記事で分かること
- 公式ポストモーテムが特定した3つの原因と、その仕組み
- v2.1.116 アップデートで「直る不満」と「直らない不満」の境界
- Opus 4.7 自体に残る4つの挙動変化
- 現場で取りうる対処5パターン
「扱いづらい」体感は2つの層が重なってできている
「Opus 4.7 が扱いづらい」という体感は、原因の違う2つの層が重なって生まれています。
| 層 | 内容 | v2.1.116 で直る？ |
|---|---|---|
| 第1層 | Claude Code 側のバグ／設定ミス（3件） | 直る |
| 第2層 | Opus 4.7 自体のモデル特性変化（4件） | 直らない |
体感別に発生源を整理すると以下のとおりです。
| 体感 | 発生源 | v2.1.116 で消える？ |
|---|---|---|
| 推論が浅くなった | 第1層 | 消える（4/7） |
| 直前のやり取りを忘れる | 第1層 | 消える（4/10） |
| ツールコール間の発話が短い | 第1層 | 消える（4/20） |
| トークン消費が増えた | 第2層 | 消えない |
| 暗黙の意図を汲まない | 第2層 | 消えない |
| 健全な依頼まで拒否される | 第2層 | 消えない |
| 出力が冗長 | 第2層 | 消えない |
第1層は アップデートすれば直る 不満。第2層は 使い方を変える必要がある 不満です。この区別が出発点です。
第1層 公式が直した3つのバグ
Anthropic 公式ポストモーテム は、品質低下を 3つの独立した変更 にトレースしました。注目したいのは、本文に「これは誤ったトレードオフだった」「これは Claude Code に期待される体験ではない」という、自社の判断ミスを認める表現が含まれていることです。
3つの原因と修正タイムラインは以下のとおりです。
| # | 原因 | 影響開始 | 修正 | 影響モデル |
|---|---|---|---|---|
| 1 | reasoning effort のデフォルトを high から medium へ |
3月4日 | 4月7日 | Sonnet 4.6 / Opus 4.6 |
| 2 | アイドルセッションの thinking 履歴消去バグ | 3月26日 | 4月10日（v2.1.101） | Sonnet 4.6 / Opus 4.6 |
| 3 | tool call 間の発話文字数を制限するシステムプロンプト | 4月16日 | 4月20日（v2.1.116） | Opus 4.7 を含む全モデル |
すべて v2.1.116（4月20日）で完了しました。公式は API は影響を受けなかった と明記しており、Anthropic API・Amazon Bedrock・Google Vertex AI 経由で同モデルを直接呼び出していたチームは3バグの影響範囲外です。加えて Anthropic は 2026年4月23日に 全サブスクライバーの利用制限（rate limit）をリセット しました。
原因1 reasoning effort のデフォルト変更（3/4〜4/7）
reasoning effort（推論努力）とは、モデルがどれだけ深く考えるかを決める設定です。Anthropic は遅延を減らすため、デフォルトを high から medium に下げましたが、副作用としてモデルの賢さが大きく落ちました。
ポストモーテムでは「これは誤ったトレードオフだった」と認め、4月7日に元に戻しました。修正後の現在のデフォルトは Opus 4.7 が xhigh、その他は high です。
原因2 thinking 毎ターン消去バグ（3/26〜4/10）
3月26日、Anthropic は「1時間以上アイドル状態のセッションを再開するとき、古い thinking（モデルの思考履歴）を一度だけ消す」最適化を投入しました。ところがバグにより、「一度だけ消す」はずが、その後セッションが終わるまで毎ターン消し続ける 動きになっていました。
その結果モデルは「なぜそうしているのかの記憶を徐々に失った状態」で動作することになり、利用者からは「直前に決めたことを忘れる」「同じ質問を繰り返す」という声が出ました。2026年4月10日リリースの v2.1.101 で修正されています。
原因3 tool call 間の文字数制限プロンプト（4/16〜4/20）
Opus 4.7 のリリース日と同じ 4月16日、Anthropic はシステムプロンプトに「ツールコール間のテキストは25語以下、最終応答は100語以下」という指示を追加しました。冗長性削減が狙いでしたが、事後評価で コーディング品質を約3%押し下げる ことが判明し、4月20日（v2.1.116）でリバートされました。
3つの原因のうち、Opus 4.7 にも直接影響した唯一の変更がこれ です。Opus 4.7 はツールコール間で意図を整理する習性が強く、その「考える隙間」を圧縮された結果、本来の能力が出にくくなっていました。
第2層 Opus 4.7 自体に残る挙動変化
公式ポストモーテムが扱ったのは Claude Code 側のバグだけです。一方で Opus 4.7 というモデル自体が Opus 4.6 から変わったことに起因する摩擦 は、v2.1.116 にしても解消されません。Anthropic 公式の What's new in Claude Opus 4.7 と Migrating to Claude Opus 4.7 に沿って、4つに整理します。
変化1 tokenizer 変更で実質コストが上がった
Opus 4.7 は新しい tokenizer（テキストをトークンに分割する仕組み）を採用しています。公式 What's new ページ には「同じテキストでも従来モデル比 1〜1.35倍のトークンを使う可能性がある」と明記されています。
トークン単価自体は Opus 4.6 と同じ（入力 $5 / 出力 $25 per Mトークン、Anthropic 公式発表 に記載）ですが、tokenizer 変更により同じタスクの実質コストは増加します。サードパーティの計測ではコードや CLAUDE.md のような テクニカル系コンテンツでは 1.45〜1.47倍 という報告も出ており、Opus 4.6 比で 30〜35% のトークン増を見込んでおく必要があります。
変化2 指示の文字通り解釈
公式 What's new ページ には「特に低 effort 設定では指示をより文字通りに解釈する。明示されていない要求を勝手に推論したりしない」と明記されています。Opus 4.6 が「察して補完」してくれていたタスクでは、4.7 が 字義通りの最小限 で止まる現象を生みます。
つまり プロンプト品質に対する感度が上がった のが Opus 4.7 の特徴です。暗黙の意図を排除して明示的に書き下す運用に切り替えるかどうかで、体感が大きく分かれます。
変化3 refusal / safety filter の強化
公式 What's new ページ には behavior changes として「リアルタイムのサイバーセキュリティセーフガード。禁止された／高リスクのトピックに関わるリクエストは refusal（拒否）を生む可能性がある」と明記されています。
実際に開発者コミュニティでは、サイバーセキュリティ分野の教科書校正、教育目的でのセキュリティ解説、防御側の脆弱性検証など、正当な業務で意図せず refusal が発生する ケースが報告されています。Anthropic 自身が同ページで Cyber Verification Program への申請窓口 を用意しており、refusal で止まる場合はまずこの窓口を確認するのが公式に示された経路です。
変化4 出力長がタスク複雑度に応じて伸びる
公式 What's new ページ には「応答長は固定の冗長度ではなく、タスクの複雑度に応じて変動する」と明記されています。難しいタスクほど出力トークンが増え、長時間のエージェント駆動では「途中から品質がブレる」と感じる場面が出てきます。
長時間運用では セッションを適切に区切る・要所で要約を取る といったハーネス（呼び出し側の仕組み）の工夫が以前より重要になっています。
対処5パターン
ここまでの整理を踏まえ、現場で取られている対処を5パターンにまとめます。
| # | 対処 | 効く層 | 向く場面 |
|---|---|---|---|
| 1 | v2.1.116 以上に更新する | 第1層 | 全員 |
| 2 | effort 設定を確認する | 第1層（再発防止） | 意図せず effort が下がっていないか確かめたい |
| 3 | プロンプトを書き直す | 第2層（指示文字通り化） | Opus 4.7 を本格運用したい |
| 4 | 4.6 / Sonnet にピン留めする | 第2層（refusal） | 既存ワークフローを維持したい |
| 5 | ハーネス側で工夫する | 第2層（応答長・出力ブレ） | 長時間エージェント運用 |
対処1 v2.1.116 以上に更新する（公式推奨）
最優先かつ唯一の必須対処 です。これより古いバージョンを使い続ける限り、第1層の3バグの影響が残ります。
$ claude --version $ claude update
加えて、Anthropic は 2026年4月23日付けで 全サブスクライバーの利用制限をリセット しています。品質低下期間に意図せず利用枠を消費していた場合も、この時点で枠は回復しています。
対処2 effort 設定を確認する
第1層の「扱いづらい」体感の中核は、意図しないタイミングで effort が下がっていた ことでした。値そのものではなく「意図ズレ」が問題です。
v2.1.117 以降、effort はモデルごとに対応が異なります（公式 — Adjust effort level）。
| モデル | 利用可能なレベル | デフォルト |
|---|---|---|
| Opus 4.7 | low / medium / high / xhigh / max |
xhigh |
| Opus 4.6 / Sonnet 4.6 | low / medium / high / max |
high |
各レベルの位置づけは公式 Migration Guide に明記されています。
| レベル | 公式の推奨用途 |
|---|---|
max |
真に難しい問題のみ。過剰思考の傾向あり、常用は非推奨 |
xhigh |
コーディング・エージェント用途のベスト |
high |
知能重視タスクの最低ライン |
medium |
コスト重視で知能を多少犠牲にできる場面 |
low |
短く・限定的・遅延に敏感なタスク |
max は全モデルで利用可能ですが、CLAUDE_CODE_EFFORT_LEVEL 環境変数経由を除き、現在のセッション限定で適用されます。
設定方法は /effort <level> のほか、--effort 起動オプション、CLAUDE_CODE_EFFORT_LEVEL 環境変数、settings.json の effortLevel、Skill / subagent frontmatter の effort でも可能です。
なお Opus 4.7 は adaptive reasoning（必要に応じて思考量を自動調整する仕組み）が強制で、MAX_THINKING_TOKENS などで思考量を固定する運用は使えません。
対処3 プロンプトを書き直す
第2層の「指示の文字通り解釈」に対する最も効果が大きい対処です。Anthropic 公式の Migration Guide には、Opus 4.7 で プロンプト側の調整が必要な挙動変化 が具体的に列挙されています。
| 公式が指摘する挙動 | 公式が推奨するプロンプト側の対応 |
|---|---|
| 出力長がタスク複雑度で変動 | 簡潔さを求めるなら明示指示を追加。「不要な前置きは省き、簡潔で焦点を絞った応答を返す」のような ポジティブな具体例 が、否定形より効きやすいと案内されている |
| 指示を文字通りに解釈 | 暗黙の前提を排除し、目的・制約・受け入れ条件を明示する |
| トーンが直接的に変化 | 既存のスタイル指定プロンプトを再評価する |
| 進捗報告がデフォルトで丁寧 | 「3ツールコールごとに要約せよ」のような 古い足場プロンプトは削除 |
| サブエージェント生成が控えめ | サブエージェントを起こす条件を明示的に書く |
| ツール呼び出しが控えめ | ツール使用条件を明示するか effort を high / xhigh に上げる |
low で浅い推論 |
プロンプトで回避するより effort を high か xhigh に上げる |
公式は加えて、既存の長さ制御プロンプトを一旦すべて外し、再評価してから明示的にチューニングする ことを推奨しています。Opus 4.6 時代の緩和策がそのまま 4.7 では逆効果になりうるためです。
対処4 4.6 / Sonnet にピン留めする
既存ワークフローを温存したい場合、Opus 4.6 に明示的にピン留め する選択肢があります。公式 Setting your model は4つの設定方法を案内しています。
| 方法 | 用途 |
|---|---|
/model <alias|name> |
セッション内で切り替え（ユーザー設定に保存） |
claude --model <alias|name> |
起動時に1回だけ指定 |
ANTHROPIC_MODEL 環境変数 |
シェル環境で固定 |
settings.json の model |
プロジェクト/ユーザー単位で永続化 |
$ ANTHROPIC_MODEL="claude-opus-4-6" claude
{ "model": "claude-opus-4-6" }
公式は注意点として、2026年4月23日以降、Enterprise pay-as-you-go と Anthropic API のデフォルト が Opus 4.7 に切り替わったと明記しています。明示ピン留めしないと自動で 4.7 に上がるため、コスト管理の意味でも明示指定が有効です。
組織全体でモデルを制限したい場合は、公式の Restrict model selection で案内されている availableModels を managed/policy 設定で使うと最優先で適用されます。
{ "availableModels": ["claude-opus-4-6", "sonnet"] }
対処5 ハーネス側で工夫する
第2層の「応答長変動」「品質ブレ」には、モデル設定だけでは対応できません。ハーネスの工夫 が必要です。
公式 Migration Guide — Recommended changes は、ハーネス側で着手すべき改善として次を案内しています。
max_tokensを再評価する: tokenizer 変更で同じテキストでもトークン数が増えるため、コンパクション閾値を含めて余裕を持たせるxhighまたはmaxeffort ではmax_tokensを 64k 以上にする（公式の推奨スタート値）- task budgets（beta）を採用する: エージェントループ全体に対する advisory な予算。
output_config.task_budgetで指定（最小 20k トークン） - 画像をダウンサンプリングする: 高解像度が不要な場合、フル解像度画像はトークンが約3倍になる
加えて、Claude Code 内では以下のハーネス工夫が現場で繰り返し採用されています。
- セッションを区切る: 長時間駆動でブレが出る前に
/clearでコンテキストを切る - 要約スナップショットを挟む: タスクの節目で「現在地・残り・決定事項」を要約させる
- CLAUDE.md でコンテキスト固定: 暗黙のルールを明示してプロジェクト直下に置く
- MCP・スキルで制約を構造化: プロンプトに毎回書く代わりにツール定義側に組み込む
opusplanエイリアスでモデルを使い分ける: Plan モードは Opus、実行は Sonnet を自動切り替え（公式 — opusplan）
ポストモーテム後の議論では、モデル単体の優劣よりも ハーネスの設計品質で最終的な体感が決まる という見方が繰り返し指摘されています。
まとめ
「Opus 4.7 が扱いづらくなった」体感は、Claude Code 側の3つのバグ／設定ミス（第1層） と Opus 4.7 自体のモデル特性変化（第2層） が重なって発生していました。前者は v2.1.116 で完全解決し API は無影響、後者はアップデートでは消えないため運用側の対処が必要です。
具体的な手順は以下のとおりです。
- まず v2.1.116 以上にアップデート する
/effortで 設定が意図どおり最大（xhigh / high）か を確認する- Opus 4.7 を本格運用するならプロンプトを目的・制約・受け入れ条件の形に書き直す
- 既存ワークフロー温存なら Opus 4.6 や Sonnet 4.6 にピン留めする
- 長時間エージェント運用ではハーネス側で区切りや要約を入れる
LLM のリリースは「モデル本体」と「ハーネス（CLI / 環境）」の両方が同時に動きます。品質低下が起きたとき、発生源を切り分けるのは利用者側にも課題が残ります。今回の二層構造は今後も繰り返し起こる構図と捉え、自社の運用テンプレートに落とし込んでおくことをおすすめします。
