CLAUDE.mdの見直しどきは、指示がじわじわ増えて重くなってきたと感じた瞬間です。長く使っていると、誰でもそこに行き着くと思います。Qiitaに投稿された「CLAUDE.mdをそろそろ見直す時期かも」という記事を読み、そこで勧められている見直し方を、私が普段使っているCLAUDE.mdに実際に当ててみました。確認できたことと、まだ確認できていないことを、ここであきらかにします。
確認できたこと・できなかったこと
この記事は10軸で独立検証しています。
✅ 確認できた事実
- Claude Code公式ドキュメントは、CLAUDE.mdを1ファイル200行以下に収める目安と、特定のファイルを読んだときだけ読み込まれるパス指定つきのルールファイル（
.claude/rules/）を案内しています（出典：Claude Code公式ドキュメント「Claudeがあなたのプロジェクトを記憶する方法」）。 - 公式ドキュメントには「各プロジェクトは
~/.claude/projects/<project>/memory/に独自のメモリディレクトリを取得します」「同じリポジトリ内のすべてのワーキングツリーとサブディレクトリは1つの自動メモリディレクトリを共有します」と書かれています（出典：同上）。さらに原文には「自動メモリはマシンローカルです」「ファイルはマシン間またはクラウド環境全体で共有されません」とも書かれています。 - 公式ドキュメントには、パス指定のないルールは無条件に読み込まれ、パス指定つきのルールは「パターンに一致するファイルを読むときにトリガーされる」と明記されています（出典：Claude Code公式ドキュメント）。この見立てを実際に手を動かして検証した記事が2本あります。metalels86氏はReadなら適用・Write単体の新規作成は非適用・Read→Writeなら適用と確認し、odacchi氏はBashのcat・sed -n等で読んだときは発火しないことを確認しています（詳しくは後述）。
- さらに重い話として、odacchi氏の記事は、Claude Codeの「auto mode（自動操作モード）」や「bypassPermissionsモード」ではシステムプロンプト自身が「Bashで読め」と指示するため、この発火経路そのものが丸ごと切れると報告しています（詳しくは後述）。
- Anthropic公式ブログ本体「The new rules of context engineering for Claude 5 generation models」（著者Thariq Shihipar、2026年7月24日公開）の原文を確認しました。“We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.”という一文が実在します。ただし同じページを読む限り、どの評価セットか・タスク数・母数・指標・公開ベンチマーク名の記載は一切ありません。
- Qiitaの元記事「CLAUDE.mdをそろそろ見直す時期かも」は2026年9月5日に公開され、確認した時点でいいね（LGTM）77件が付いています（出典：元記事）。
❓ 現時点で確認できていないこと
- 削減の具体的な比較データ（どの評価セットか・タスク数や母数・性能が「測定できなかった」の測定方法）は、公式ブログ自体に記載が無いため確かめようがありません。非公開なのは事実として確認できましたが、中身そのものは分かりません。
- 「Read単体・Read→Writeでは発火するがWrite単体の新規作成では発火しない」（metalels86氏）、「Bashのcat・sed -n等で読むと発火しない」「auto modeがBashを優先する」（odacchi氏）という見立ては、それぞれの記事の著者自身が自分の環境で検証したものであり、私自身の環境では再現・実測していません。
- 参照したZenn記事の中で触れられているGitHub Issueの番号や現在の状態（open・closed）は、この記事では根拠として使っていません。今回の環境からGitHubへの到達を検証していないためです。
何が起きたか：Qiita記事の主張
「CLAUDE.mdをそろそろ見直す時期かも ── Claude 5世代向けの最適化手順・スキル・プロジェクト種類別の例」というタイトルの記事を、Qiitaで見つけました。投稿したのはnogataka氏、投稿日は2026年9月5日で、この記事を書いている時点でいいね（LGTM）77件が付いています。元記事はこちらです。
元記事の主張の骨子
元記事は、Anthropicが2026年7月24日のブログで、Claude Opus 5とFable 5向けにClaude Codeのシステムプロンプトを8割以上削り、社内のコーディング評価で性能低下が測定できなかったと公表した、と紹介しています。理由として挙げられているのは、制約の多くが最悪の場合を避けるために書かれたもので、いまのモデルは周りの文脈から判断できるようになった、という認識です。ここから元記事は「あなたのCLAUDE.mdも同じように見直せる」と論を進めます。なお原文自体は「社内の」ではなく「自社の（our）」コーディング評価と書いており、この違いは後の節で扱います。
この主張の出どころは、元記事によれば”The new rules of context engineering for Claude 5 generation models”というタイトルのAnthropicブログ記事で、筆者はThariq Shihipar氏とされています。この題名で改めて探したところ、Anthropic自身のドメイン（claude.com）上に原文が実在することを確認できました。原文はこちらです。該当の一文は英語で次のように書かれています。
We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.
Thariq Shihipar「The new rules of context engineering for Claude 5 generation models」（2026年7月24日）
元記事の「社内のコーディング評価」という言い回しは、この”our coding evaluations”（自社のコーディング評価）を意訳したものです。「自社」と「社内」は近い言葉ですが、原文が言っているのはあくまでAnthropic自身が使った評価であって、業界標準のベンチマークとは書かれていません。そしてページ全体を読んでも、その評価セットの名前・タスク数・母数・指標・公開ベンチマーク名は一つも出てきません。「8割削っても損失が測定できなかった」という結果だけが公開され、中身は非公開のままです。
見直しの7ステップと、棚卸し用のスキル
元記事は、CLAUDE.md見直しの手順として次の7つの段階を挙げています。
- ファイルの量と構成を把握する棚卸し
- 設定ファイルを読めば分かる記述の削除
- 禁止の書き方を判断の基準に書き直すこと
- 手順をスキルへ移すこと
- 覚え書きと仕様を分けること
- 矛盾の洗い出し
- 見直し前後でタスクを実行して品質と使用量を比べる効果確認
棚卸しの段階では、ファイルサイズの一覧・見出しの一覧・強い言い切りの語を含む行・重複行を自動で拾うスキルが紹介されています。「手順をスキルへ移す」という考え方は、NULLPOINT.NEWSでも別記事で検証しています。
プロジェクト種類別の7つの例と、残すべきもの
元記事はさらに、全体用・Webアプリケーション・ライブラリ・調査リサーチ・技術記事執筆・インフラ・AIエージェント運用という7種類のプロジェクトごとに、短いCLAUDE.mdの例を示しています。そのうえで「残すべきもの」として2つを挙げています。1つは、削除・履歴の書き換え・本番反映・外部への送信・課金が発生する操作を実行する前に必ず確認を挟む仕組みです。もう1つは、リポジトリのファイルを見ただけでは分からない背景知識、たとえば「このフォルダは移行中なので触らない」といった事情です。
各ソースはどう伝えているか
元記事の主張のうち、私が自分で確かめられた部分と、確かめられなかった部分を分けて示します。
Claude Code公式ドキュメントの記述
Claude Code公式ドキュメントの「Claudeがあなたのプロジェクトを記憶する方法」というページには、CLAUDE.mdは1ファイルあたり200行以下を目安にすること、それより長いファイルはコンテキストを多く使い指示への追従が下がる可能性があること、が書かれています。パス指定つきのルールファイル（.claude/rules/）についても、Claudeが指定したパターンに一致するファイルを読むときだけ適用される、と説明されています。原文はこちらです。
📌 ここで伝えたいこと：200行という目安そのものは、今回のAnthropicブログを待つまでもなく、以前から公式ドキュメントに書かれています。元記事の新しさは目安の数字ではなく、見直しの手順を7段階に整理したところにあります。
パス指定つきルールが発火する条件
公式ドキュメントには、パス指定つきのルールファイルについてこう書かれています。
`paths` フィールドのないルールは無条件に読み込まれ、すべてのファイルに適用されます。パススコープルールは、すべてのツール使用時ではなく、パターンに一致するファイルを読むときにトリガーされます。
Claude Code公式ドキュメント「Claudeがあなたのプロジェクトを記憶する方法」
つまり、ファイルを読まずにプログラムを実行するだけの使い方では発火しない可能性があります。移す前に自分で確かめる必要があります。実際に手を動かして確かめた記事が2本あります。
metalels86氏の検証では、既存ファイルをReadツールで読んだときはルールが適用され、Read→Writeの順で操作したときも適用される一方、Writeツールだけで新規ファイルを作成した場合は適用されなかったと報告されています。回避策として、先にtouchコマンドで空ファイルを作り、Readを1回挟んでからWriteする、という手順が紹介されています。つまり、新しく作ったファイルには、paths付きのルールがそのままでは効かないことがある、ということです。
これとは別に、odacchi氏の検証では、Bashのcatコマンドやsed -n等でファイルの中身を取得したときはルールが発火しないことを、フックのログを取って確認したと報告されています。
📌 さらに重い話があります：odacchi氏の記事は、Claude Codeの「auto mode（自動操作モード）」や「bypassPermissionsモード」では、システムプロンプト自身が「Bashで読め」と指示する作りになっていて、この指示が入るとpaths付きルールの発火経路そのものが切れる、と報告しています。これが起きると、CLAUDE.mdからpaths付きの.claude/rules/へ移しても、CLAUDE.mdに書いていたときと同じ「読まれない」リスクがそのまま残ることになります。「置き場所を分ければ解決する」という前提そのものが崩れかねない話です。
ここは私自身では実測・再現していません。metalels86氏・odacchi氏それぞれが、自分の環境でツールのログやアクセス制御の実機テストを取って確かめたと書いている内容です。移す前に、自分の使い方（Readで読ませているか、Writeだけで新規作成しているか、Bashで読ませているか）を一度確かめたほうがよさそうです。
同じ課題に取り組む別の記事
CLAUDE.mdの肥大化と.claude/rules/の使い方は、今回のQiita記事だけが扱っているテーマではありません。同じくQiitaに、この仕組みの使い方を扱った別の記事があります（tomada氏の記事）。また英語圏では、Anthropicの8割削減という発表を受けて「自分のCLAUDE.mdまで同じように削るべきではない」と論じるMedium記事もあります（Addo Zhang氏の記事 ※英語サイト）。どちらも詳しい中身までは読み込んでいませんが、「Anthropicの数字をそのまま個人の設定に持ち込んでいいのか」という同じ疑問が複数の書き手から出ていることは、確認できました。
確認できなかったこと・不明な点
Anthropic公式ブログの原文（前回の下書きからの訂正）
前回の下書きでは、Anthropicが本当に「8割以上削って性能低下が測定できなかった」と書いているのかという一次資料に行き着けなかった、と書いていました。改めて探し直したところ、Anthropic自身のドメイン（claude.com）上に原文が実在することを確認できました。出典は”The new rules of context engineering for Claude 5 generation models”というタイトルのブログ記事（著者Thariq Shihipar氏、2026年7月24日公開）で、該当の一文はこの記事の前段にすでに引用したとおりです。行き着けなかったのは検索の仕方の問題で、原文が存在しないわけではありませんでした。
削減の中身と算出方法は、原文にも書かれていない
原文が見つかったことで分かったのは、「8割」がどの母数に対する割合か、どのコーディング評価を使ったか、性能が「測定できなかった」というときの測定方法が何か、評価セットの名前や公開ベンチマークとの対応は何か、といった中身が、Anthropic公式ブログそのものにも書かれていないという事実です。原文が未確認だから確かめられなかったのではなく、原文を読んでも確かめようがない、という結論です。数字だけが独り歩きしやすい主張だと改めて感じます。
背景・文脈
なぜCLAUDE.mdは太っていくのか
CLAUDE.mdは、同じ説明を繰り返さずに済むように書く場所です。Claude Codeが同じ間違いを2回したとき、コードレビューで指摘されたとき、前のセッションで打ち込んだ説明をまた打ち込んだとき。そういう出来事のたびに1行足していくと、ファイルは自然に厚くなっていきます。1行を足すときの判断は毎回正しくても、積み重ねの結果を後から見返す機会は少ないので、気づいたときには全体が重くなっている、というのが実感です。
「常に読む・ときどき読む」という発想の来歴
Claude Codeには、常にセッション開始時に読み込まれるCLAUDE.mdと、必要になったときだけ読み込まれるスキル、そして特定のファイルを開いたときだけ読み込まれるパス指定つきのルールファイルという、複数の置き場所がもとから用意されています。今回のQiita記事は、この複数の置き場所を「削る」ではなく「使い分ける」道具として捉え直した点に価値があると感じました。次の章で、その使い分けを自分の環境で試した結果を書きます。
4つの置き場所を、読み込まれるタイミングで分けた図。公式ドキュメントの記述にもとづく（未実測の部分は本文にも明記のとおり）。
読者への考察ポイント：どこまで自分に持ち込めるか
ここからは、元記事の主張を自分のCLAUDE.mdに当ててみて分かった、そのまま使える部分と、使うと壊れる部分の線引きです。5つの論点にまとめました。表にした後、それぞれ詳しく書きます。
色棒の色は目安です。緑にあたる論点はありませんでした（赤＝そのまま使うと危ない／橙＝条件つき）。
①行数の目安は、重さを測れていない
元記事は「1ファイル200行以下」を目安として挙げています。これは公式ドキュメントにも書かれている目安で、根拠のない数字ではありません。ただ、実際に手元のファイルを見返すと、200行以下に収まっていても、1行が長く書き込まれていれば中身は分厚いままでした。行数だけで測ると、長い1行を残したまま短い5行を削るという、狙いと逆の動きが起きます。
測るなら行数ではなく文字数のほうが実態に近く、さらに言えば「そのファイルが毎回本当に読まれているか」のほうが効きます。行数は、測りやすいというだけの理由で選ばれた物差しかもしれません。
②本当の価値は「削れ」ではなく「置き場所を分けろ」。ただし発火条件は自分で確かめる
元記事を読んで最も効くと感じたのは、削る量の話ではなく、常に読ませる文と、必要なときだけ読ませる文を分けるという考え方でした。道具ごとの注意書きは、その道具を触るときにしか要らないのに、CLAUDE.mdに書くと毎回読み込まれてしまいます。元記事はその移し先として、pathsを書いた.claude/rules/*.mdを挙げています。指定したファイルを読んだときだけ読み込まれる仕組みです。
📌 ここに落とし穴があります：この仕組みは「Claudeがそのフォルダのファイルを読んだとき」に発火する作りです。公式ドキュメントには「パターンに一致するファイルを読むときにトリガーされる」と書かれています。
先に書いたとおり、Readで読んだときと、Bashのcat・sed -n等で読んだときとで、発火するかどうかが変わる可能性があります。さらに見落としやすいのが、新しくファイルを作った直後です。metalels86氏の検証では、Writeツールだけで新規ファイルを作成した場合、そのファイルに対するpaths付きルールが適用されなかったと報告されています。つまり、CLAUDE.mdの内容をpaths付きルールへ移す作業そのものは書けても、その直後にその移した先のルールが自分の新しい編集作業で一度も発火しないまま気づかない、ということが起こり得ます。回避策として、先にtouchで空ファイルを作りReadを1回挟んでからWriteする手順が紹介されています。私自身が実測していない点も含め、前の節で書いたとおりです。
③禁止形を消してよいかは、その1行の出どころで決まる
元記事は「禁止形を判断基準に書き直せ」と勧めています。ここで見落としやすいのは、元記事は「Anthropicが『多くは削除できる』と言っていて、『すべて』とは言っていない」と指摘している点です。「多くは削除できる」と言ったのは元記事自身ではなく、元記事が引用しているAnthropicです。ここで効く見分け方は、その行が入った理由が、想像上の最悪の場合を防ぐためだったのか、それとも実際に起きた出来事があって足された行なのか、という違いだと思います。
実際に何かが起きてから足した行を消すと、同じことがまた起きます。だから消す前に、いつ・何があって足された行なのかを追えるようにしておくことのほうが先です。元記事も「削る前に、その行が入った経緯を確認してください」と書いています。行を書くときに、なぜ書いたかを一緒に残しておく習慣が、後で削るかどうかを判断するときにそのまま効いてきます。
④クラウドで動かしているなら、自動メモリに任せてはいけない
元記事は、個人的な好みや一時的な学びを自動メモリに任せることを勧めています。公式ドキュメントには、各プロジェクトが専用のメモリディレクトリを持ち、同じgitリポジトリの複数の作業ツリー・サブディレクトリでは1つの自動メモリディレクトリを共有する、と書かれています。そして原文は「自動メモリはマシンローカルです」「ファイルはマシン間またはクラウド環境全体で共有されません」と、はっきり書いています。
使い捨てのクラウド環境の上で作業する使い方だと、その環境ごと片づけられたときに自動メモリも一緒に消えます。ここは元記事の前提（手元の1台のパソコンで使い続ける）と、読者の環境が食い違いうる点です。消えては困ることは、自動メモリではなく、バージョン管理された普通のファイルに書いたほうが安全です。
⑤「Anthropicが8割削ったから、自分も8割削る」は成り立たない
元記事が引く8割という数字は、Claude Code本体の、全世界の利用者に共通のシステムプロンプトから削られた量です。今回、原文にあたって確認できましたが、これは”our coding evaluations”（Anthropic自社のコーディング評価）による結果で、業界標準の公開ベンチマークではありません。しかも評価セットの名前・タスク数・母数・測定方法は原文にも書かれておらず、外部からは検証しようがありません。一方、各利用者のCLAUDE.mdは、その人が自分の環境で実際に踏んだ地雷の記録です。同じ「削る」という言葉を使っていても、削る対象の性質も、根拠の検証しやすさも違います。
共通の指示文は、最悪の場合を一律に避けるために厚く書かれがちで、モデルの性能が上がれば削れる余地も大きいはずです。対して個人のCLAUDE.mdは、すでに一度困って足した行の集まりであることが多く、同じ比率で削れる保証はありません。中身を検証できない「8割」という数字ではなく、①〜④で見てきたような分類のほうが、自分のCLAUDE.mdには効くと感じました。
体系的に押さえたい人へ：CLAUDE.mdの前提を書籍で知る
ここまで見てきた「置き場所を使い分ける」という考え方は、Claude Codeというコーディングエージェントが、要求の整理から実行・検証までをどう回しているかへの理解が前提にあります。CLAUDE.mdの1行だけを見直すより、コーディングエージェントとしての基本的な動き方を一通り押さえておいたほうが、次にどの行をどこへ移すかの判断がしやすくなると感じます。体系的に学び直したい方には、書籍で一度整理するという選択肢もあります。
この節にはAmazonアソシエイトのリンクを含みます。リンク経由で購入があった場合、当サイトに紹介料が入ります。
西見公宏氏・吉田真吾氏・大嶋勇樹氏の共著『実践Claude Code入門―現場で活用するためのAIコーディングの思考法』（技術評論社）は、Claude Codeの基本的な使い方からスペック駆動開発までを扱う書籍です（Amazon商品ページで確認。2026-09-09時点）。私自身はまだ読んでいないため、内容の当否はここでは判断しません。CLAUDE.mdの前提を体系的に押さえたい方への選択肢として挙げます。
まとめ
元記事は、タイトルどおり「削る」ための記事に見えます。ただ、実際に自分のCLAUDE.mdへ当ててみると、最後に残ったのは「どこに何を置くか」を考え直す作業でした。行数を減らすことよりも、常に読ませる場所と、必要なときだけ読ませる場所を分け直すこと、そして分けた先が本当に機能するかを自分の目で確かめることのほうが、効果として大きかったです。
Anthropicの公式ブログ本体は、今回原文にあたって実在を確認できました。ただし「8割削っても損失が測定できなかった」の中身（評価セット・測定方法）は原文にも書かれておらず、非公開のままです。そして「置き場所を分ければ発火条件は心配ない」という前提そのものにも、実際に検証した人たちから疑問が出ています。CLAUDE.mdからpaths付きのルールへ移す作業は、移して終わりではなく、移した先が本当に発火するかを自分の環境で確かめるところまでが一続きの作業だと感じました。
私たちはニュースの真実を保証しません。ただし、真実を追求し、何を確認できて、何を確認できなかったか、そのプロセスをすべてあきらかにします。
多角検証スコア（Claude × Grok 独立評価）
| 検証軸 | Claude評価 | Grok評価 |
|---|---|---|
| 1. メディア報道（資金源・国籍が異なる独立したもの） | E（対象外） | B |
| 2. 一般人の投稿（現地目撃者など） | B | C |
| 3. 公式文書（政府・企業IR等） | B | A |
| 4. 人間心理的分析 | E（対象外） | D |
| 5. 統計データ | D | D |
| 6. 歴史的文脈 | E（対象外） | B |
| 7. 地理的・地政学的文脈 | E（対象外） | E |
| 8. 宗教的・文化的背景 | E（対象外） | E |
| 9. 経済的利害関係 | D | B |
| 10. 時系列的整合性 | B | A |
評価基準：A＝複数の独立したソースで確認済み矛盾なし B＝一部確認できたが全ては確認できていない C＝確認できたソースと矛盾するソースが混在 D＝ほぼ確認できていないソース不足 E＝確認不可または信頼できるソースなし。Claudeの評価にある「E（対象外）」は、この記事の主題ではその軸が成り立たないと判断したものです。
Claudeの評価は1・4・6・7・8を「技術記事には成り立たない検証軸」として一括で対象外（E）にしていました。Grokの評価はこのうち1・4・6に実際に確認できる材料（各国のテック媒体による転載、過剰制約への解説、旧世代向けガードレールが新世代で負債化する時系列のつながり）を見つけ、B〜Dを付けています。ただしGrokの評価自身も「独立した再現検証や体系的な分析としては薄い」としており、高い評価ではありません。それでも成立しうる軸まで一括して除外したのは、Claudeの評価が甘かったと考えます。7（地政学）・8（宗教文化）はGrokの評価もE（確認不可）で、ここは対象外のままで妥当です。
逆に、両者がそろってDを付けた軸が1つあります。5の統計データです。Anthropicは「測定可能な損失はなかった」と書いていますが、母数も指標も評価セットも公開していません。数字の裏づけを確かめようがない、という一点で、Claudeの評価とGrokの評価が一致しました。この記事の中心にある「8割という数字をそのまま持ち込めない」という話は、ここに立っています。
とくに1（メディア報道）で注意したいのは、米・日・台の複数媒体が同じ主張を報じていても、出典をたどるとほぼ同一のAnthropic公式ブログを要約転載しているだけで、内部評価を独自に再現した調査報道ではない、という点です。報道した媒体の数を、それぞれが自分で再現した検証の数と取り違えないほうがよいと考えます。
2（一般人の投稿）はClaudeの評価がB、Grokの評価はC（確認できたソースと矛盾するソースが混在）でした。CLAUDE.mdを削って混乱が減ったという投稿と、制約を薄めると指示からの逸脱や元の書き方への揺り戻しが起きるという投稿が、同時に存在するためです。9（経済的利害関係）はClaudeの評価がD、Grokの評価はBでした。「新しいモデルほど指示が少なくて済む」という筋は、Anthropicの上位モデル販売や、移行需要を商材化する周辺の解説・講座と整合します。ただしGrokの評価自身も「評価結果を歪めたという直接の証拠はない」と述べており、相関はあっても因果は確認できていません。
3（公式文書）・10（時系列）はGrokの評価がA、Claudeの評価はそれより一段厳しいBでした。いずれも公式ブログ・著者本人の発信・製品ドキュメントの記述が矛盾なく並ぶ点を重く見た評価で、Anthropicの非公開の評価データそのものを検証したわけではありません。
