Claudeシステムプロンプト公開 — Claude Codeは80%削減、CLAUDE.mdの書き方はどう変わったか

はじめに

Anthropic が公開している「Claude のシステムプロンプト」のリリースノートが、Hacker News で 373 ポイントを集めた。モデルがどんな前提・制約・優先順位で動いているかを一次情報で読める、という点で確かに価値がある。

ただし、このページを「Claude の隠し設定が漏れた」という文脈で読むと本質を取り逃す。Anthropic はこれを 2024年7月から継続的に公開しており、今回が初出ではない。そして今、システムプロンプトをめぐって実際に起きている変化は、公開そのものではなく 中身が急速に短くなっている ことのほうだ。Anthropic は Claude Opus 5 / Fable 5 向けに Claude Code のシステムプロンプトの 80% 以上を削除している。

本記事では、公開されているシステムプロンプトが何であって何でないのかを整理したうえで、「なぜ削るほうが効くのか」という設計思想の転換と、それが CLAUDE.md や Skills を書く手にどう跳ね返るかを解説する。

公開されているのは「どの Claude」のプロンプトか

まず前提を正確にしておきたい。混同されやすいが、公開対象は限定されている。

リリースノートに掲載されているのは、claude.ai およびモバイルアプリで使われる、消費者向けプロダクトのシステムプロンプトである。API 経由でモデルを叩く場合、これらのプロンプトは付与されない。つまり自分でアプリを組んでいるエンジニアにとって、ここに書かれた内容は「自分のリクエストに混入している何か」ではなく、Anthropic 自身がモデルをどう御そうとしているかのお手本として読むべきものだ。

掲載されているモデルと日付は以下のとおり。

Claude Opus 5（2026年7月24日）
Claude Fable 5（2026年6月9日）
Claude Opus 4.8（2026年5月28日）
Claude Opus 4.7（2026年4月16日）
Claude Sonnet 4.6（2026年2月17日）

ドキュメントには「4.6 世代以降、各モデル ID は単一の固定スナップショットであるため、それらのモデルのエントリは1つだけ」という趣旨の注記がある。以前はモデル名が同じまま中身が更新され、日付違いの版が積み上がっていたが、現在はモデル ID とプロンプトが一対一で対応する。挙動の再現性を気にする立場からは、この変更のほうが実務上は効いてくる。

内容の領域は広い。トーンと書式（「Claude は温かみのあるトーンを用い、相手の判断力や能力について否定的な前提を置かずに親切に接する」/ Opus 5）、書式の抑制（「Claude は太字、見出し、リスト、箇条書きといった要素で応答を過剰に装飾することを避ける」/ Sonnet 4.6）、児童保護、拒否の扱い、利用者のウェルビーイング、法務・財務での断定回避、知識のカットオフ（Opus 4.8 では「2026年1月末」と明記）、ツールの遅延読み込み、政治的トピックでの公平性、そして誤りを認める際に過剰に謝罪しないこと──といった具合だ。

なお、2025年5月には「ツール込みで約 24,000 トークン」とされるシステムプロンプトのリーク情報が話題になった。公開版はこれと同一ではないが、プロンプトが長大化していた時期があったという傍証にはなる。そしてここからが本題だ。

反転 — 「増やす」から「削る」へ

2026年7月24日、Anthropic の Thariq Shihipar 氏が公開した記事「The new rules of context engineering for Claude 5 generation models」が、この流れを明確に反転させた。

主張はシンプルで、Claude Code のシステムプロンプトの 80% 以上を削除したが、社内のコーディング評価で計測可能な性能低下は出なかったというもの。同記事では、自分たちが Claude Code を過剰に制約していたと認めている。システムプロンプト・Skills・ユーザーの指示それぞれに指示が散らばった結果、「適宜ドキュメントを残せ」と「コメントを書くな」のような相互に矛盾するメッセージが衝突していた、という自己診断だ。

記事が挙げる転換は6つある。

ルールから判断へ — 最悪ケースを防ぐガードレールを明示列挙するのをやめ、モデルの判断に委ねる
例示からインターフェース設計へ — ツールごとに使用例を並べるより、パラメータと説明自体を表現力の高いものにする
事前投入から漸進的開示へ — 全部を冒頭で読ませず、Skills や遅延読み込みツールで必要時に読ませる
重複から単純な記述へ — システムプロンプトとツール説明の両方に同じ指示を書かず、ツールの使い方はツール説明にだけ置く
手動メモリから自動メモリへ — ユーザーが手作業で CLAUDE.md に書き溜める方式から、Claude が自動で記憶を拾う方式へ
単純な仕様から richer な参照へ — 計画を素朴な Markdown で書くより、コードやテストスイート、ルーブリックを参照させる

1つ目の具体例が分かりやすい。旧プロンプトは「デフォルトでコメントを書かない。複数段落の docstring を決して書かない……ユーザーが求めない限り、計画・意思決定・分析のドキュメントを作らない」と禁止事項を積み上げていた。新プロンプトはこれを一文に畳んでいる。

Write code that reads like the surrounding code: match its comment density, naming, and idiom. （周囲のコードと同じように読めるコードを書け。コメント密度、命名、イディオムをそれに合わせよ。）

禁止の列挙ではなく、判断基準を一つ与えている。周囲のコードがコメント過多ならそれに合わせるし、無ければ書かない。前者は文脈に適応できないが、後者はできる。

2つ目の指摘はやや直感に反する。使用例を足すとモデルの能力が広がりそうに思えるが、記事の観察は逆で、例示はむしろ探索空間を例の周辺に狭めてしまうという。少数例に引きずられて汎化を止める、という現象だ。

ただし、この 80% という数字の扱いには注意が要る。これは Anthropic が自社の評価セットで測った自社の数字であり、評価方法の詳細は公開されていない。第三者による独立検証があるわけではない。「削っても大丈夫」を一般則として鵜呑みにするのではなく、後述するように自分の環境で確かめる話として受け取るのが妥当だ。

エンジニアへの影響 — CLAUDE.md と Skills をどう書き直すか

では手元の設定ファイルをどうするか。記事のガイダンスは具体的だ。

CLAUDE.md に書くべきものは、リポジトリの軽い説明、そのコードベース固有の「落とし穴」や変わったパターン、そして複雑なトピックについては漸進的に読ませる Skills への参照。書くべきでないものは、ファイルシステムを見れば分かる自明な情報、Skills に置くべき指示の再掲、そして網羅的なプラクティス集だ。

Skills についても「軽量に保ち、過剰に制約しない」「長い Skill は複数ファイルに分割して漸進的開示にする」「チーム固有の意見・知識・ベストプラクティスを書く」「詳細な制約は本当に重要な領域だけに留める」とされている。

この方針を実際に適用した記録が、同日のダイジェストにも入っていた Zenn の実践記事だ。5ヶ月かけて育てた設定を Claude 自身に棚卸しさせた結果の数字が生々しい。

元の構成: CLAUDE.md 308行、Skills 40個、コマンド 6個、カスタムサブエージェント 2個、意思決定記録 7個
結果: Skills 40個 → 6個、Skill の説明文が 23,218文字 → 3,194文字、常時ロードされる総量が 32,694文字 → 9,465文字（72%削減）

注目したいのは、この著者が引き出した教訓のほうだ。Claude は既存の指示を 微調整するのは得意だったが、そのフレームワーク自体がまだ必要かを自発的に疑わなかったという。「どう現代化するか」と尋ねるのと、「そもそも新しい Claude Code の機能がこのやり方を丸ごと不要にしていないか」と尋ねるのとでは、返ってくる答えが違った。実際、生成させていた要件定義ドキュメントは、その後どこからも参照されていなかった。

これは棚卸しを依頼するときのプロンプト設計そのものへの示唆になる。「使われているか」と「もう要らなくなっていないか」を明示的に別々に聞く必要がある、ということだ。なお Claude Code には設定を適正サイズに調整するための /doctor（claude doctor）コマンドが用意されている。

実務的な進め方としては、削減幅の大きさに引きずられて一気に消すより、まず「常時ロードされる文字数」を測り、矛盾する指示のペアを探し、参照実績のない生成物を特定する、という順で観測してから削るのが安全だ。80% も 72% も他人の環境の結果であって、目標値ではない。

まとめ

Anthropic が公開しているシステムプロンプトは claude.ai / モバイルアプリ向けであり、API 利用時には付与されない。2024年7月から継続公開されている一次情報で、今回が初出ではない
Claude 4.6 世代以降はモデル ID が固定スナップショットになり、プロンプトとモデルが一対一で対応するようになった
Anthropic は Opus 5 / Fable 5 向けに Claude Code のシステムプロンプトを 80% 以上削除し、社内コーディング評価で計測可能な低下は出なかったと報告している（自社評価・方法非公開という留保付き）
設計思想は「ルール列挙 → 判断の付与」「事前投入 → 漸進的開示」「例示 → インターフェース設計」へ転換した
実践例では Skills 40個→6個、常時ロード量 72%削減。ただし棚卸しでは「使われているか」と「もう不要になっていないか」を別々に問う必要がある

新しい世代のモデルに対しては、指示を足すことが安全策ではなくなりつつある。矛盾した制約はモデルの判断を狭め、例示は探索を縮める。自分の CLAUDE.md が「保険」として膨らんでいないか、一度文字数を測ってみる価値はある。

今日のその他のニュース

Cloud Run のキャッシュ保持は課金モードではなく min-instances — 「常時 CPU 割り当てにすればインメモリキャッシュが残る」という理解を実験で否定し、実際に効くのは最小インスタンス数だと示した記事。コンテナのライフサイクルを誤解したまま課金モードだけ変更すると、コストが増えてキャッシュはヒットしないという典型的な落とし穴。（Qiita）

Defender 有効下で開発機が5日間マイニングされていた — Windows Defender が動作している状態でクリプトマイナーの常駐を5日間検知できなかったインシデント報告。開発機はビルド系プロセスや除外設定が多く検知が甘くなりやすいという構造的な問題を突いている。ローカルで外部ツールを多用する環境では他人事ではない。（Qiita）

デスクトップ UI フレームワーク15種のメモリ実測 — Electron / Tauri / Flutter Desktop など15種で同等のアプリを作り、メモリ使用量を横並びで計測した比較。常駐型の自作ツールを作る際のフレームワーク選定に使える実数が揃っている。（Zenn）