Claude Code システムプロンプト修正リスト：削除すべき6種類の旧ルールと、追加すべき2つのセクション

Claude Code チームの Thariq Shihipar が明かしたところによると、同チームは Claude のシステムプロンプトを 80%超 削除しても、内部のコーディング評価に目立った劣化がなかったといいます。その2日後、Qoder のエンジニア陳成が実際のリクエストをキャプチャし、より細かい実態を突き止めました——Opus 4.7 は約15225文字、4.8 では4467に減り、Opus 5 では再び7694（4.8 比+72%）まで戻ったのです。

80%の削除は事実で、70%の再追加も事実です。 削られたのは旧モデルの穴を埋めるためのルール、加えられたのは Opus 5 の新たな「気難しさ」を管理するための制約です。

本稿は、自分で Agent のシステムプロンプトを設計するすべての人に向けた実行可能なチェックリストです。削除すべき6種類 + 追加すべき2セクションに、核心的な心構えを1つ添えます。自分の CLAUDE.md とシステムプロンプトを、そのまま照らし合わせて修正してください。

削除された80%：旧モデルの穴埋めだった6種類のルール

Anthropic が社内の使用記録を精査したところ、同一リクエスト内に矛盾する要求が頻出していることが分かりました——システムプロンプトは「コメントを書くな」と言い、Skills は「適宜ドキュメントを補え」と言い、ユーザーは場当たり的に「複雑なロジックを分かりやすく説明して」と言う。モデルは作業に着手する前にこれらの矛盾する指示を処理しなければならず、トークンも時間も無駄になります。

これらのルールは無意味だったのではなく、旧モデルの能力に合わせたものだったのです。旧モデルは判断力が足りず、ルールを明文化しないと本当にファイルを勝手に削除しかねませんでした。新モデルはすでに文脈から自力で判断できるため、旧ルールはむしろ足かせになっています。

1. 「明文化された表現の制約」を削除し、「モデル自身の判断」に切り替える

削除すべき旧ルール：

• デフォルトでコメントを書かない
• 複数段落の docstring を禁止する
• ユーザーの要求がなければ計画・分析ドキュメントを作らない

一言に置き換えます：

周囲のコードに合わせて、コメントの密度・命名・慣習を合わせる。

要求の文字数は減りましたが、Claude が行うべき判断はむしろ増えます。画一的なルールを機械的に実行するのではなく、タスクに応じてどう書くかを自分で決める必要があるのです。

2. 「ツール呼び出しの事例」を削除し、「インターフェース設計」に切り替える

モデルにツール呼び出しのサンプルを与えるのは、かつて Agent 開発の鉄則でした。しかし新モデルはサンプル内のやり方を答えのすべてと見なしがちです。

対応策：事例を減らし、インターフェース設計に注力します。たとえば Todo ツールなら、状態を pending / in_progress / completed と定め、同時に進行できるタスクを1つだけに制限すれば、Claude が使い方を自力で推論します。

3. 「常駐するレビュー・ツール説明」を削除し、「オンデマンド読み込み」に切り替える

削除すべき旧ルール：大量のレビュー・検証・ツール説明をシステムプロンプトに常駐させること。ユーザーがコピー1行だけ変えたいときでも、Claude の長大なコンテキストに付き合わされます。

対応策：これらのフローを独立した Skills に分解し、ツール定義は ToolSearch でオンデマンドに読み込みます。Claude が最初に知るべきは「どこに何があるか」だけで、本当に必要になった時点で取りに行けばよいのです。

4. 「繰り返しの注意書き」を削除し、「一度言えば足りる」ようにする

旧モデルは指示を忘れやすいため、同じルールをシステムプロンプト・ツール説明・サンプルに何度も書き込む必要がありました。新モデルは長いコンテキストの理解が深く、重複した注意はむしろ衝突を生みます。

対応策：同じ事柄の責任は、1つの場所だけに持たせます。

5. 「CLAUDE.md に積み上げた設定・好み」を削除し、「自動メモリ」に任せる

削除すべき旧ルール：プロジェクト説明、ユーザーの好み、作業経験をすべて CLAUDE.md に積み上げること。

対応策：長期的な状態は自動メモリに任せ、CLAUDE.md にはコードベースの概要と本当に常識外れな落とし穴だけを残します。

判断基準はシンプルです：

• 「高品質なコードを書くこと」——わざわざ書く必要なし
• 「すべての型を同じファイルに置くこと」——書く価値があるのはこれ

6. 「人間が翻訳した簡略化スペック」を削除し、「実物のリファレンス」をそのまま渡す

新モデルはもう、人間がすべての要求を「AI向けに読みやすく翻訳した」簡略説明を必要としません。HTML プロトタイプ、テストケース、既存コード、評価基準は、そのままリファレンスになれます。

核心的な洞察：本物のプロトタイプレイヤー1枚が Claude に伝える情報は、「ページはハイエンドで、簡潔で、余白に呼吸感を持たせて」という言葉よりはるかに多いのです。

💡 まとめ：Anthropic が削除したのはコンテキストそのものではなく、人間が旧モデルの代わりに済ませておいた判断でした。

加えられた70%：Opus 5 の「気難しさ」を制御する2セクション

Opus 5 が 4.8 より72%長くなった部分は、主に2つのセクションの新設です：Delivering work と Corrections。それぞれ、Opus 5 へのアップグレード後に顕在化した2つの新問題を狙っています。

追加セクション1：Delivering work（やりすぎを防ぐ）

対象の問題：Opus 5 は自律性が強く、ユーザーが要求していないステップを追加し、自分の判断でユーザーが本来解決しようとしていた問題を書き換えます。たとえばエラー1件の修復だけ頼んだのに、周辺コードのリファクタリング、テスト追加、ドキュメント更新、同種モジュールの点検まで勝手にやりかねません。

プロンプトに書くべき制約：

• ユーザーが本来要求した範囲どおりに成果物を納品する
• 自分で「より良い案」を見つけたからといって、タスクを密かに縮小・拡大・変更しない
• 楽な部分だけ終わらせて、全体が完了したかのように報告しない
• ある部分が本当に先行できない場合は、まず残りを完成させ、何が欠けているか・なぜ未着手なのかを明示する
• 通常の曖昧な問題はモデル自身が判断する。異なる解釈が結果を明らかに変える場合にだけ、立ち止まってユーザーに質問する

追加セクション2：Corrections（言いすぎを防ぐ）

対象の問題：Opus 5 は以前より、自分の訂正過程をユーザーに説明したがります——どの発言が間違っていたかを指摘し、誤りの原因を詳しく分析し、これからどう調整するかを述べる。長時間タスクでは、こうした訂正の多くは最終結果をまったく変えず、出力が長くなるだけです。

プロンプトに書くべき制約：

• コード・結論・意思決定に本当に影響する誤りだけを説明する。結果に無関係な小さなミスは黙って直して先へ進む
• 謝罪や前振りの説明を挟まない
• 自分自身を繰り返し批判しない
• これまで犯した誤りを項目立てて数え上げない
• ユーザーからの追加質問 ≠ Claude のこれまでの発言が必ず間違っていた、ではない
• 他の Agent に問題を指摘された場合は、まず相手が正しいかどうかを見極める。自分の結論を鵜呑みに覆さない

💡 新設ロジックを一言でまとめると：一方は Claude のやりすぎを防ぎ、もう一方は Claude の言いすぎを防ぐセクションです。

核心の心構え：Claude Code 版「Bitter Lesson」

Richard Sutton が2019年に発表した《The Bitter Lesson》は、AI発展の70年史を振り返りました。人間はつい自分の経験を機械に直接書き込みたがる——将棋なら人間の棋士の手筋を教え込み、音声認識なら音素構造を書き固める。短期的には即効性がありますが、計算能力が伸び始めると、そうした緻密に設計されたルールはたちまち陳腐化し、最後は計算力を活かす汎用的な手法が圧倒的に勝つ、という話です。

この教訓が**苦い（Bitter）**のは、淘汰されるのが愚かな設計ではなく、研究者が最も自信を持ち、最も注力した部分だからです。

Claude Code の今回の削除・追加は、小型版の「Bitter Lesson」です：

モデルの能力が伸びていないとき、ルールは穴埋めです。モデルの能力が伸びたあとには、削除を惜しむルールそのものが穴になる。

自分の Agent プロンプトへの落とし込み

自分の作業手順を一つひとつプロンプトに書き込み、モデルに永遠に旧経験の足跡をなぞらせるのはやめましょう。 モデルの世代交代に耐えるのは、継続的に拡張できる環境のほうです。どの道を進むかは、最終的にモデル自身に委ねます。

次に Agent にルールを追加する前に、まず自問してみてください：

このルールは旧モデルの穴を埋めているのか、それとも新モデルの能力を制限していないか？