Claude Opus 4.7に切り替えたら"手順書"が機能しなくなった話

ごきげんよう。
 AIモデルの更新通知は期待より不安が先に来るAsellus（あせるす）です。

前回の記事で「Claude MAXに主軸を移した経緯」を書きました。
今回はその続きです。

2026年4月16日、Anthropic社がClaude Opus 4.7をリリース。コーディング性能のベンチマーク（SWE-bench Verified）が80.8%→87.6%に向上、エージェント信頼性も大幅改善と、公式発表だけ見れば順当なアップグレードと言えます。

私もすぐに切り替えて試したところ…結果、自分が1か月かけて構築した運用基盤が正常に機能しなくなってしまいました。

前提："Skills"で何をしていたか？

前回記事で紹介したProjects×Memory×Skillsの3層運用。この中のSkillsに、私は10本の"手順書"を登録していました。

• note記事を書く時の文体ルール・構成手順・禁止事項

• YouTube切り抜き動画をnote記事に変換する手順

• Xポストの文案を生成するルール

• 攻略記事のHTML制作手順

…といった内容で、1本あたり数千字。これらを読み込んだ上で指示通りに動いてもらう設計です。

Opus 4.6（旧モデル）では、この仕組みは概ね期待通りに動いていました。手順書に書いた禁止事項を守り、チェックリストを通し、フォーマットに沿った出力を返してくれる。完璧ではないにしろ、校正の手間は許容範囲と言える水準に仕上げてあります。

『Opus 4.7』切替直後に起きたこと

切り替えた翌日、いつも通りnote記事のX向け長文記事を生成させたところ…手順書に明記してある禁止事項を5件同時に破りました。

具体的にはこういう内容です。

• 本文中に使ってはいけない記号を使った：ダッシュ記号「——」は動画導線テンプレの冒頭1行だけに限定

• AI臭い定型表現が混入した：「構造」「核心」等のワードは禁止指定

• note記事専用のクロージングをX記事流用：媒体別の文体境界ルール違反

• 文体モードの混在：「です/ます」と「だ/である」の使い分け無視

• 出力前のチェックリストを通さずに提出

5件とも、Skillsの手順書に書いてある規則なんですが…
Opus 4.6では守れていた内容が4.7では全滅。指摘して修正させると、今度は過剰な分析文を長文で返してくるばかりで肝心のファイル修正を後回しにされてしまう。

原因："長い文脈を覚えておく能力"の崖落ち

最初は「たまたま調子が悪かったのか？」と思いましたが、調べてみると構造的な問題が浮き彫りになってきました。

Opus 4.7のベンチマーク（公開されている性能指標）を確認すると、コーディング関連の数値は軒並み向上しています。ところがMRCR（Multi-Round Context Recall）という指標だけが、78.3%→32.2%に崖落ちしていました。

MRCRとは？

「長い会話や大量のファイルを読み込んだ状態で、過去に読んだ情報をどれだけ正確に思い出せるか」を測る指標です。

たとえば10本のSkillsファイル（合計数万字）を読み込ませた状態で、「3本目のファイルに書いてあった禁止事項」を出力にどれだけ反映できるか。MRCRが高ければ正確に反映されるし、低ければ"読んだはずの内容"が出力に活かされない。

Opus 4.6のMRCRは78.3%。Opus 4.7は32.2%。半分以下です。

Skillsルール違反の原因

私の運用は「10本のSkillsを同時参照→複数ルールを守りながら出力」させる設計です。1本だけ読ませるなら、4.7でも問題なく動きます。実際、note記事の単独生成（clip-to-note skill 1本だけ発火）はOpus 4.7でも概ね成功していました。

壊れたのは「複数のSkillsを同時に発火させるタスク」です。X記事生成は x-post skill ＋ text-humanizer skill ＋ note-article skill の3本を同時参照する必要があり、ここでMRCRの崖落ちが直撃したことがわかります。

"読んでいるのに反映できない"理由

ここが一番厄介なポイントで、Opus 4.7は"Skillsを読んでいない"わけではありません。

手順書を読み込んだかどうか確認すると、ちゃんと「読みました」と答えてくる。STEP 1からSTEP 5まで手順通りに宣言もするが、実際の出力を見ているとSTEP 3あたりで制約が抜け始める。

Opus 4.6なら①読んで②覚えて③最後まで守るまでをある程度できていた。 Opus 4.7は①読んで②覚えて③途中から忘れる…

これは使っている側からすると非常にタチが悪い。「読み飛ばしている」なら指摘できますが、「読んだけど途中で抜けている」だと、出力をゼロから全チェックしないと違反が検出できません。

トークナイザ変更の影響

もう一つ、見落としがちな変化があります。

Opus 4.7ではトークナイザ（文章を内部的に分割する仕組み）が変更されています。同じ文章を入力しても、4.6と4.7では内部的な"長さ"が異なる。公式発表では、同じ入力が1.0〜1.35倍のトークン数にマッピングされると説明されているんですね。

これが実運用で何を意味するか？

Claude MAXには使用量の上限があります。トークナイザが変わって同じ作業でも消費量が増えると、1日にこなせる作業量が減る。特に私のように毎セッションでSkillsファイル10本＋ナレッジファイル数本を読み込ませる運用だと、入力だけでトークンを大量に消費します。

多少性能が上がった分で燃費が結構悪くなったという表現が、遠からず近からずかもしれません。

対処：モデルを使い分ける

結論として、現在はタスクの種類によってOpus 4.6とOpus 4.7を使い分ける運用に落ち着いています。

• Opus 4.6：note記事制作、X記事生成、攻略記事HTMLなど「複数Skillsの同時参照が必要なタスク」

• Opus 4.7：Claude Code（ローカルファイル操作・サーバーデプロイ）など「エージェント的に自走させるタスク」

4.7のコーディング性能向上とエージェント信頼性は本物で、Claude Codeでの作業効率は確かに上がっています。ただし問題としているのは長い文脈を保持しながら複数の制約を守るタスクで、ここは4.6の方が信頼できる。

Skillsの設計で対策可能？

4.7のMRCRが改善されるまでの暫定措置として、Skillsの設計側でも対処が可能です。

• 1回のタスクで同時発火するSkills数を減らす

• 長い参照チェーンを短くする（全量参照→該当部分だけ読ませる）

• 文体チェックをClaude任せにせず、スクリプトで機械検証する

ただし、これらは「モデルの弱点を回避するための設計変更」であって、本来不要だった工数と言えます。

"最新モデル＝最強"ではない

今回の経験で再度学んだのは、AIモデルのアップデートは全方位的な改善ではないということでしょう。

Opus 4.7はコーディングとエージェント用途で確かに4.6を上回っています。しかし、長い文脈の保持力（MRCR）は大幅に後退しました。Anthropic社も公式に「コーディング外の劣化ポイント」として認めています。

新しいモデルが出たら即座に切り替えるべき、という風潮がありますが…少なくとも自分の運用に組み込む前に自分のワークロードで何が変わるかを検証すべきでした。ベンチマークの数字だけ見て切り替えた私の判断ミスでもあります。

あとがき

今回のnote記事はほぼOpus 4.6生成で執筆しています。4.7がSkills通りに動かなかった問題を、4.6に相談して経緯を記事化…。若干シュールな構図ですけど、これがAI運用のリアルと言えばそうかもしれません。

約1か月かけて構築したSkills群は壊れていなかったようだが、モデル相性問題により4.7だとまともに機能しない。道具は同じでも、使い手が変わると結果も変わってしまう。

AIサブスクの話もそうですが、「これが正解」で止まれる時代ではない。情勢は変わるし、モデルも変わる。変化に合わせて設計を更新し続ける工数まで含めて、AI運用の実態だと思っています。

それでは、また。