Opus 5.5で指示書から削る6行、CLAUDE.mdとスキルの棚卸し

手元のCLAUDE.md、最後に頭から読み返したのはいつでしょうか？指示書は足すだけだと、そのうち誰も読まない説明書になるんですよね。Opus 5.5の解説ブログと公式ガイドを読み比べて、旧モデル向けに足しがちな行から削る候補を6つ選び、削る前に残す記録と戻す合図をセットにしました。

CLAUDE.mdを削る前に、入れた理由を1行残す

Claude Codeのベストプラクティスは、各行に「これを消したらClaudeは間違えるか」と問い、間違えないなら消すよう勧めています。答えるには、その行を入れた理由が要ります。

Best practices for Claude Code - Claude Code Docs

Tips and patterns for getting the most out of Claude Code, from configuring your environment to scaling across parallel sessions.

code.claude.com

そこで消す前に、4つの項目を台帳に書いておきます。

行: IMPORTANT: 最後に必ずもう一度確認すること
入れた時期と当時のモデル: YYYY-MM / 旧モデル名
防ぎたかった失敗: テストを走らせずに完了と報告した
戻す合図: 同じ失敗が2回続いたら戻す

台帳はCLAUDE.mdの外に置きます。中に書けば、削るはずの指示書がまた太るからです。理由を思い出せない行は git log -p CLAUDE.md で追加時のコミットをたどり、それでも出てこなければ、それ自体が削る候補だと思います。

戻す合図を削る日に決めておくのは、あとで考えると、たまたまの失敗までその行のせいにしたくなるからです。

あなたの指示書に、入れた理由を説明できない行は何行ありますか？

Opus 5.5の公式文書は、どこまで削れと言っているのか？

根拠は、claude.devのブログでAddy Osmaniさんが書いた解説と、開発者向けのOpus 5.5プロンプトガイドです。

Getting the most out of Opus 5.5 in Claude and Claude Code / claude.dev Blog

How to prompt Opus 5.5, steer a long run, and check your results in Claude apps and Claude Code.

claude.dev

Prompting Claude Opus 5.5

Behavioral differences from Claude Opus 5 and the prompting and harness patterns that address them: effort calibration, thinking behavior in API integrations and chat, progress updates, unattended and multiagent tasks, safeguard refusals, frontend design, complex visual inputs, multi-app workflows, and pasted text in user messages.

platform.claude.com

ガイドは「Opus 5のパターンは出発点として妥当」としているので、5.5のページに再掲がない項目はOpus 5の文書で補いました。ここは僕の読みです。

6つのうち、あなたのファイルに残っていそうなのはどれでしょう？候補探しには、Claude Code v2.1.283以降の /doctor prompt-audit が使えます。CLAUDE.mdからスキルやコマンドまで、旧モデル向けの指示や矛盾を探して修正案を出し、頼むまでファイルは書き換えません。

How Claude remembers your project - Claude Code Docs

Give Claude persistent instructions with CLAUDE.md or AGENTS.md files, and let Claude accumulate learnings automatically with auto memory.

code.claude.com

CLAUDE.mdから削る3行

1. IMPORTANTの連発と「迷ったら使え」

モデルにルールを素通りされた時期に、IMPORTANT や YOU MUST で念を押した行です。開発者向けのベストプラクティスはOpus 4.5や4.6向けの項で、「CRITICAL: You MUST use this tool when...」を普通の言い方に弱め、「If in doubt, use [tool]」はツールの使いすぎを招くとしています。

Prompting best practices

Comprehensive guide to prompt engineering techniques for Claude's latest models, covering clarity, examples, XML structuring, thinking, and agentic systems.

platform.claude.com

Claude Codeのベストプラクティスも、強調は無視される1行だけに付けるよう書いています。Opus 5.5のガイドには出てこない、根拠が一番古い項目です。戻す合図は、強調を外したルールが同じセッションで2回破られたとき。戻すのはその1行だけです。

2. 「最後にもう一度確認して」の再確認指示

テストを走らせずに完了と言う、が続いた時期の名残りですね。Opus 5のガイドは、Opus 5は言われなくても自分の作業を検証するとして、「最後に検証ステップを入れる」「サブエージェントで検証する」といった指示の削除を明記しています。「ダブルチェックして」型の念押しも、結果は良くならずコストだけ増えるそうです。

Prompting Claude Opus 5

Behavioral differences and prompting patterns for Claude Opus 5, covering response verbosity, agentic narration, task scoping, subagent delegation, self-correction, and output artifacts when thinking is disabled.

platform.claude.com

ただ、ここは公式の中で言い分が分かれます。Claude Codeのベストプラクティスは完了前にサブエージェントで差分をレビューする手順を勧め、ブログも大きな監査をサブエージェントに分けて結果を確かめるよう書いています。決着していないので、僕は念押しの文言だけを削り、テストのように走らせて確かめるコマンドは残します。戻す合図は、完了報告のあとに見落としが続いたときです。

3. 理由のない禁止リストと番号付きの手順

失敗を1つ塞ぐたびに「〜しないこと」が増えた行です。AnthropicのThariq Shihiparさんは、Opus 5やFable 5向けにClaude Codeのシステムプロンプトを80%超削っても、コーディングの評価で測れる低下はなかったと書いています。例は、コメントの細かい禁止を「周りのコードに合わせ、コメントの密度や命名をそろえる」という1文に置き換えた変更でした。

The new rules of context engineering for Claude 5 generation models / claude.dev Blog

We removed over 80% of Claude Code's system prompt for more advanced models. How to apply the lessons we learned to your own context engineering in Claude Code and with your own agents.

claude.dev

Anthropicが公開している監査の基準も、理由のない禁止は意図の文に直し、番号付きの手順は順番に意味があるものだけ残す扱いです。業務や規約上の理由がある禁止は残すので、装置制御の「実機にコマンドを送る前に確認する」は残す側ですね。戻す合図は、外した禁止の失敗が実際に再現したときです。

プロンプト集とスキルから削る3行

4. 「よく考えて」とステップバイステップ

考えさせると精度が上がった時代の名残りです。ブログは「think carefully」「think step by step」などの行を、プロンプトと保存した指示から消すよう書いています。Opus 5.5は返答前に必ず考え、量も自分で決めるからです。一方でプロンプトガイドは、チャットアプリのシステムプロンプトについて「削除を検討して」止まりで、根拠は社内のチャット製品で消したら返信が早く始まり、質に明確な低下はなかったというテストでした。

Claude Codeでは think や think hard は普通の文として渡るだけで、キーワードとして認識されるのは ultrathink だけです。そのターンに深く考える指示が足される仕組みなので、プロンプト集の ultrathink は意図して使っているかで残すかを決めます。消したあと答えが浅いと感じたら、戻す先は文言ではなく /effort で、Opus 5.5の既定は medium です。

Model configuration - Claude Code Docs

Configure which model Claude Code uses, effort levels, extended context, and the auto-compact window

code.claude.com

5. 推論を書き出させる指示

「答える前に、考えた過程を全部書いて」と頼んでいた行です。Opus 5.5のガイドは、本文に推論を書き出させる指示を削り、要約された思考ブロックから読むよう書いています。こうしたプロンプトは reasoning_extraction という区分で拒否されることがあるからです。

例として、回答前に埋めさせる <thinking> 欄やJSON出力の reasoning フィールドが挙がり、スキルやツールの説明に潜むこともあるそうです。答えの短い説明や根拠の要約は頼めるので、戻すより、その依頼に置き換えるほうが筋がいいと思います。

Refusals and fallback

How Claude Fable models, Claude Opus models, and Claude Sonnet 5.5 return classifier refusals and how to retry refused requests on a fallback model.

platform.claude.com

6. ツール3回ごとの進捗報告

作業が黙って進むのが不安で、「ツールを3回呼ぶごとに進捗をまとめて」と書いた行です。移行ガイドは、Opus 4.7から途中報告をモデル自身がより定期的に出すようになったとして、こうした足場は外してみるよう書いています。監査の基準でも、固定頻度の報告は語数の上限とまとめて外す扱いです。

ただし、ここはAPIの話です。Opus 5.5の途中報告は thinking ブロックで返り、既定の表示設定では中身が空なので、text ブロックだけを描画する自作ハーネスでは黙って見えます。Claude Codeの画面での見え方は、公式文書では確かめられませんでした。戻す合図は、途中経過が分からず困る時間が続いたとき。そのときはガイドの例のように、「最初に一言、最後に要約」と欲しい場面を書く手があります。

Migrating to Claude Opus 5.5

Migrate to Claude Opus 5.5 from earlier Opus models or Claude Sonnet 5: request settings that return errors, thinking blocks in every response, and a checklist for each starting model.

platform.claude.com

指示書に残す行と、1行だけ足すもの

残すのは、ビルドやテストのコマンド、コードを読んでも分からない事情、データ削除や強制プッシュのような破壊的な操作の前の確認です。毎回例外なく守らせたいものは、指示書よりフックに移すほうが確実ですね。

代わりに足すなら、完了条件の1行です。ブログは「テストが通る」のようにゴールを名指しするよう勧めています。解析スクリプトなら「pytest が通り、既存の出力CSVと数値の差分がないこと」くらいまで書けます。

あなたの指示書の完了条件、1行で言えますか？

台帳の戻す合図は、次にモデルが替わる日にもう一度開く場所になります。足す文化から削る文化へ移る手すりとして、残しておいてください。