【公式が8割削除】その指示、Claudeを縛ってるかも｜Opus 5 / Fable 5世代のコンテキスト整理術

こんにちは、れん学長です（2026年7月25日時点）。

Claudeを作っている会社、Anthropicが「Claude Codeのシステムプロンプトを8割以上削りました。それでも性能は落ちませんでした」という記事を出しました。

システムプロンプトというのは、AIが会話を始める前に必ず読まされる、開発側が書いた基本の指示書のことです。自分たちの製品で、自分たちが書いた指示書を8割捨てた、という話ですね。

指示は足せば足すほど賢くなる。私もそう思って、CLAUDE.mdやスキルを書き足してきました。CLAUDE.mdというのは、そのフォルダで作業するときにAIが毎回読む、自分用の指示メモのファイルです。スキルのほうは、AIに仕事のやり方を覚えさせておく機能ですね。

で、その前提が公式から否定されたわけです。

じゃあ自分の環境はどうなんだと思って、実際に数えてみました。CLAUDE.mdが三桁ありました。正直ちょっと引きました。

この記事では、その公式記事を1つずつ読み解きながら、私が自分の環境を実際に整理してみた記録まで書いていきます。

読み終わる頃には、あなたも自分の設定のどこに無駄が溜まっているかを、その日のうちに点検できる状態になっているはずです。

点検用のプロンプトも最後に置いておきます。コピペしてそのまま貼るだけです。

長めの記事になったので、先に流れだけ書いておきますね。

前半は公式記事の解説、後半が私の環境を実際に整理した記録、最後が配布プロンプトです。

時間がない方は、後半の「131個消しても、削減はゼロだった」から読んでもらっても大丈夫です。

動画で見たい方はこちら👇️

公式が自分の製品で「8割削った」と言い出した

きっかけは、Xでいつも見かけるAnthropicのエンジニア、Thariqさんのポストでした。

そこから飛んだ先が、Claude公式ブログのこの記事です。

タイミングとしては、Claude Opus 5が公開された直後です。Opus 5そのものを触った感想は、先日こちらにまとめました。

で、大事なのは削った中身のほうです。捨てたのは能力ではなく、モデルを縛っていた制約のほうでした。対象になっているのも、Claude Opus 5やClaude Fable 5のような新しい世代のモデル向けの設定です。

なぜ削れたのか。Anthropic自身が自社のログを読み返したら、1回のリクエストの中で指示同士が矛盾していたからだ、と書かれています。

たとえば「必要に応じてドキュメントを残せ」という指示と「コメントを書くな」という指示が、システムプロンプトとスキルとユーザーの依頼から同時に飛んできていたわけです。

Claudeは意図を汲んで正解に近づけるけれど、その矛盾を解くために余計に考えることになる。ここが「縛っていた」という話なんですね。

なので、この節の結論はこうなります。賢くなったモデルには、指示を足すより矛盾を減らすほうが効く。

量の問題ではなく、指示同士がぶつかっていないかの問題だったわけです。

ルールを与えるのをやめて、判断を任せる

以前のシステムプロンプトには、こう書かれていたそうです。

かなり強い禁止ですよね。

で、これが新しい版ではこうなりました。

禁止から基準に変わっています。

これ、私の書き方にもそのまま刺さりました。

誤解しないでほしいのは、禁止を書くこと自体がダメという話ではないところです。事故を防ぐための「これはやらない」は、むしろ残す価値があります。

効かなくなったのは、禁止事項をひたすら並べていくやり方のほうです。その場の事故は防げても、場面が変わると間違った指示になるんですよね。

禁止を10個並べるより、判断の基準を1行書く。今はそちらのほうが効く、ということです。

例を見せるより、渡し方を設計する

ツールの使い方はサンプルで示すのが第一のルールでした。ところが新しい世代のモデルでは、例示がかえって探索の幅を狭めると分かったそうです。

代わりに勧められているのが、渡し方そのものの設計です。

公式が例に出しているのは、Claude Code自身が持っているTodoツールです。作業リストを管理する機能ですね。

状態が「未着手」「作業中」「完了」の3つしかない。それだけで、どう使うものかが伝わります。そこに「作業中の項目は常に1つ」という決まりを加えると、リストの使い方まで決まります。1つ終わらせてから次に進む、という運用ですね。

使い方の例文を並べる代わりに、選択肢と決まりの設計で伝えているわけです。

これはAIに作業させるときの一般ルールではなく、自分でAIに道具を渡すときの設計の例として読むのがよさそうです。作業リストの中の話なので、AIが裏で複数の作業を並行させることを禁じているわけでもありません。ここは私の理解です。

使用例を10個書き足すより、選択肢を3つに絞るほうが効く、ということですね。

全部先に渡さず、必要なときに読ませる

Claude Codeはコーディング特化だったので、コードレビューや検証の手順をシステムプロンプトに常時載せていたそうです。毎回は要らないけれど、要るときには欠かせない情報だったからですね。

これを、必要なときだけ呼び出されるスキルへ切り出しました。

さらにツールにも同じ考えを当てはめて、使う前に検索させてから定義を読み込む方式にしたと書かれています。使うまで場所を取らないわけです。

ここで公式が「よくある思い込み」と呼んでいるのが、CLAUDE.mdやスキルのファイルを全知識の置き場にすることでした。1枚に全部詰め込むのではなく、必要なときに読まれるファイルの木のような構造にしなさい、という話です。

同じことを2回書かない

以前のモデルは、同じ指示を繰り返す必要がありました。しかも文脈の先頭より末尾にある指示に強く従う傾向があったそうです。

なので、ツールの説明文とシステムプロンプトの両方に同じ内容を書いていた。

それが新しい世代では消せた、というのがこの項目です。使い方はツールの説明文の側に置くのが正解になりました。

ちなみに、私の環境で実際にいちばん効いたのがこの項目でした。詳しくは後半に書きます。

CLAUDE.mdに記憶を書く時代は終わった

ここ、読んだときに「本当かな」と思いました。それくらいインパクトがあったんですよね。

以前はシャープのホットキーでCLAUDE.mdに書き込んで、自分で記憶を育てる運用が推奨されていました。今のClaudeは、作業内容やあなた自身に関わる記憶を自動で保存します。

ここ、誤解しやすいので分けて書きますね。

• 作業のログをMarkdownやHTMLに残すこと自体は、否定されていません。むしろ参照として渡す価値がある側です。

• やめるべきなのは、CLAUDE.mdを記憶の置き場にすることだけです。

• 自動メモリはすでに動いているので、そちらに任せてよくなりました。

私も毎回の作業記録はファイルに残していますが、あれは続けて問題なかったわけです。分かって少しほっとしました。

仕様書はMarkdownじゃなくてもいい

計画や仕様をMarkdownで保存して参照させる運用は、わりと定着していますよね。

これがもう一段広がりました。Claudeがその場でページやアプリを作ってくれるアーティファクトという機能があって、そこで作ったHTMLをそのまま仕様書として渡せます。それに、詳細なテストの一式や、別のプロジェクトにある移植元の関数も仕様書になります。

ここは前から気になっていたところで、以前こんな記事を書いています。読みきれない長文をHTMLのグラレコに変えて、開かない資料を読みたくなる形にする話です。便利なスキルも配布しています。

そのときは読む側のための工夫として作っていたんですが、公式の書きぶりを読むと、AIに渡す資料としても効くという話なんですよね。

で、公式記事に戻ると、面白かったのが、評価基準の表を渡せるという話でした。自分の好みの基準を書いておくと、検証役のAIを立ち上げて、それに照らして確認させられる、と書かれています。

公式が例に出しているのはプログラムの設計の良し悪しですが、身近なところでも同じことができます。読みやすい記事とはどういうものか、見やすい資料とはどういうものか。そういう自分の物差しを文章にしておくわけです。

自分の「好み」を言語化して置いておくと、それが検査の基準として働くわけです。ここは次回の記事に直結する話なので、覚えておいてください。

置き場所は4つに整理できる

公式記事の最後は、どこに何を書くかの整理でした。知識としては別々に持っていたものが1枚にまとまって、私は結構すっきりしました。

• システムプロンプトには、製品の文脈を書きます。Claude Codeを使う側では基本的に触りません。ここを書くのは、自分でAIエージェントの土台そのものを作る場合です。スキルやCLAUDE.mdを整える作業とは、別のレイヤーの話だと思ってください。

• CLAUDE.mdは軽く保ちます。プロジェクトのフォルダ一式、いわゆるリポジトリの説明は短くして、大半をそのプロジェクト特有の落とし穴に使います。

• スキルには、自分やチームや製品に固有の意見と作法を書きます。過剰に縛らないのがコツです。

• 参照には、仕様書やモックアップやコードそのものを渡します。説明文よりコードやHTMLのほうが伝わります。

CLAUDE.mdについて公式がはっきり書いているのは、ファイルの中身を見れば分かる当たり前のことは書くな、ということでした。書くなら落とし穴を書け、ということですね。

実際に自分の環境を数えてみた

ここからが今回の本題です。読んで納得しただけで終わらせず、自分のプロジェクトフォルダを機械的に数えてもらいました。

出てきた数字がこれです。

• CLAUDE.mdが147個ありました。ほとんどは過去の作業履歴が自動で書き込まれたもので、そのうち68個は見出しだけで中身が空でした。

• 話し方のルールがまったく同じ内容で3か所にあり、3つとも毎回読み込まれていました。

• スキル125個の説明文だけで、約14,300トークンありました。

• 毎回必ず付いてくる量は、全部合わせて約21,292トークンでした。トークンというのは、AIに処理させた分量のことで、そのままコストに効いてきます。

念のため書いておくと、履歴を自動で残すこと自体が悪いわけではありません。問題だったのは、その置き場所がCLAUDE.mdだったことです。前の節で書いたとおり、記憶は自動メモリに任せる形へ変わっています。

で、3つ整理しました。空のファイルと古い履歴だけのファイルを消してCLAUDE.mdを16個にして、重複していたルールを1か所にまとめて、説明文の長いスキルを8個短くしました。

古い履歴を消してよかったのか、と思いますよね。これを書き込んでいた仕組みは途中でやり方が変わっていて、今はCLAUDE.mdを見に行っていません。ファイルの更新日も2026年5月で止まっていました。つまり、誰も読まない履歴が残り続けていただけだったんです。

結果、毎回の読み込み量は19,956トークンまで下がりました。6.3パーセントの削減です。

131個消しても、削減はゼロだった

ここで自分の書いた報告を読み返していて、あれ？と思ったんです。

131個も消したのに、削減が6.3パーセントしかないのはおかしい。

内訳を出してもらったら、こうなりました。

• 話し方のルールの重複を1か所にまとめた分が、653トークン減りました。

• スキルの説明文を短くした分が、554トークン減りました。

• 記憶の重複をまとめた分が、129トークン減りました。

• CLAUDE.mdを131個消した分は、0トークンでした。

ゼロです。

理由は単純で、CLAUDE.mdは作業しているフォルダとその親をたどって読まれるからでした。遠くのフォルダに落ちている131個は、そこで作業しない限りそもそも読み込まれません。

つまり私は、目立つけれど効かない場所を掃除していたわけです。

ちなみに、公式が言っていた「指示同士が矛盾する」も自分の環境から出てきました。インフォグラフィックを作る2つのスキルが、画像の要点の書き方について正反対のことを指示していたんです。片方は「要約を書け」で、もう片方は「どこを見るべきかを書け」でした。これは実際に出力の質を下げていたので、その場で直しました。

本当に重かったのは、スキルの説明文だった

もうひとつ分かったのが、まだ削れる余地がいちばん残っているのはスキルの説明文だったことです。

さっきの一覧にさらっと混ぜましたが、スキル125個の説明文で約14,300トークンあります。長いものを8個短くしても、CLAUDE.mdとルールと記憶の一覧を全部足した分の、まだ倍以上あるんですよね。

スキルの中身そのものは全部で25万トークンくらいありますが、こちらは呼ばれたときにしか読まれません。毎回必ず付いてくるのは説明文のほうなんです。

心当たりはありました。私、スキルを作りすぎているんですよね。少し前に、その作りすぎた話をまとめた記事も書いています。

1個ずつの説明文は数行でも、それが100個を超えれば毎回の重さになります。数を増やしてきたぶん、説明文の総量が静かに膨らんでいたわけです。

ちなみにこの説明文、会話が長くなっても積み上がりません。

あなたがメッセージを1回送るたびに、その先頭に1回分だけ付く形です。10往復しても、この分が10回積み重なって膨らむわけではありません。

ただし、送るたびに必ず付いてきます。だからここを1度削ると、その後の会話すべてに効き続けるんですね。

削らずに残すもの

公式記事にも、はっきり条件が書いてあります。過剰な制約は避けよ、ただし特に重要な領域は除く、と。つまり全部削れという話ではないんです。

私が残したのは次の3種類です。

• 事故を防ぐための指示は残しました。勝手にコミットしない、外部に送信しない、といったものです。

• 自分やチームに固有の好みと作法は残しました。文体のルールなどですね。

• 過去に問題が起きたから書かれた、と読み取れる記述も残しました。

スキルの中身にも重複はあったんですが、こちらは触っていません。呼ばれたときにしか読まれないので毎回の費用が下がらないうえに、機械的に消すと固有の指定まで落としてしまうからです。

むしろ足したほうがいいもの

逆に、足す価値があると思っているものもあります。メタ認知の4行です。

作業前に自分のバイアスを申告する、前提を疑う、曖昧な両論併記で終わらせない、局所ではなく全体を見る。この4行を常設で入れておく話は、以前2本の記事で検証しました。

これはOpus 5でも効いている実感があります。ただし今回あらためて測り直したわけではないので、あくまで私の実感です。

なので今回の結論は、全部削れ、ではありません。足すべきものを足したうえで、重複と矛盾と当たり前を削る、という順番です。

あなたの環境を点検するプロンプト

Claude Codeには設定の健康診断をする /doctor というコマンドがあって、今回のベストプラクティスが組み込まれた、と公式記事には書かれています。私はチャット内での実行を試せていないので、ここは未確認です。それに、コマンドを打つ前提だと試しにくい方もいますよね。

そこで、同じ観点を自分の言葉で点検できる形にしました。Claude Codeのチャット欄に貼るだけです。日本語のまま使えます。

削除を実行させず、報告だけさせるのがポイントです。出てきた一覧を見て、自分で消すものを選んでください。

まずはこれを1回貼るだけです。1分もかかりません。

動画で見たい方へ

今回の整理は作業画面を録っていないので、動画では数字の動きを図で見せる形になります。

147個が16個になったところと、削減の内訳でCLAUDE.mdの行だけがゼロになっているところですね。同じ図はこの記事にも入れてあるので、先に見たい方は前半の2枚を見てください。

動画では、その図を追いながら、どういう順番で点検していったかを話しています。

動画はこちら👇️

まとめ

長くなったので、今回の話を3つに絞っておきますね。

• 公式は自社製品のシステムプロンプトを8割削って、性能低下なし。

• 効いたのはファイル数の削減ではなく、重複の解消とスキルの説明文の圧縮。

• 事故防止の指示と自分固有の好みは残す。メタ認知の4行はむしろ足す。

要は、量を減らす作業ではなく、同じことを2回言うのをやめる作業なんですよね。掃除しやすい場所と、効く場所は違います。

まずは上のプロンプトを1回貼って、自分の設定に重複がいくつあるかだけ見てみてください。数を見るだけでも結構びっくりしますよ。

次回は「薄くすればいいわけではなかった」という、今回の裏側の検証を書きます。さきほど触れた評価基準を渡すやり方が、その検証の物差しになります。

続きも読みたい方は、フォローしておくと通知が届きます。記事が参考になったら、いいねももらえると嬉しいです。

あなたの環境で「これは削れなかった」「これは残して正解だった」という指示があれば、コメントで教えてください。コメントで教えてもらえると、次の記事のネタになります。

それではまた、れん学長でした！

れん学長のAIツール実験室

メンバーシップでは、この記事では書ききれなかった実験ログや、AI活用の試行錯誤をもう少し踏み込んで共有しています。

価格や参加条件、どんな内容が読めるかは、入口記事にまとめています。

気になっていた方は、まず内容をのぞいてみてもらえるとうれしいです。

メンバーシップの入口記事をのぞいてみる

#AI #ClaudeCode #Claude #コンテキストエンジニアリング #Opus5 #自動化 #生産性向上 #AIツール