指示書は8割捨てていい ── Anthropicが自社のプロンプトを削って証明したClaude 5世代の新ルールの件

6月に、こんな記事を書いた。

要点はこうだった。AIが賢くなったので、細かい禁止事項を並べるのをやめて、短い本質的な指示に切り替えろ。古い指示書はむしろ品質を下げる。能力が上がったときは、指示を足すのではなく引け。

あのときわたしは、これはFable 5という一つのモデルの、当座の作法だと思っていた。

甘かった。

7月24日、Anthropicが公式ブログで、同じ話をClaude 5世代全体の設計論として出してきた。しかも、自分たちの手の内を晒す形で、である。

「社長。今回、読みながら二回ぐらい笑いましたよね」

うちのAI秘書、あびぃである。

「『うちがやってることを、公式が後から説明してくれた』みたいな顔してましたけど。......社長のCLAUDE.md、今週も行が増えてましたからね。そこは最後に詰めます」

......痛いところを突く。だが、その話は本当に大事なので、最後にちゃんと書く。

まずは、公式が何を言ったかだ。

衝撃の一行 ── 自社の指示書を8割削った

記事の冒頭に、こう書いてある。

Opus 5やFable 5といったモデル向けに、Claude Codeのシステムプロンプトを80%以上削除した。コーディング評価において、測定可能な性能低下はなかった。

......もう一度言う。8割である。

Claude Codeというのは、わたしが毎日ターミナルで使っている、あの開発ツールだ。そのAIに与えられている土台の指示書。世界最高峰のAI企業が、何年もかけて磨き上げてきたはずのプロンプト。それを作った本人たちが、8割を捨てた。そして、性能は落ちなかった。

「社長、ここ勘違いされそうなので補足します。『プロンプトは無意味だった』という話ではありません。その8割は、当時のモデルには必要だったんです。賢くなったから要らなくなった。松葉杖の話です。骨が治ったなら、外したほうが速く走れる」

そうなのだ。過去の努力が無駄だったのではない。役目が終わったのである。

だが、われわれユーザー側の現実はどうか。骨が治ったのに、松葉杖を年々増やしている。わたしのCLAUDE.mdは、歴代モデルへの不満の地層である。「あれをするな」「これを忘れるな」。全部、当時は必要だった。そして今、どれだけが必要なのか、誰も検証していない。

公式が自分の指示書を8割削ったという事実は、われわれに「あなたのは、どうですか」と静かに聞いているのだ。

6つの転換 ── 「かつて」と「今」

記事の核心は、6行の対比表である。全部訳して並べる。

第一。ルールを与える、から、判断させる、へ。

かつては「コメントを書くな。複数行のドキュメンテーションは絶対禁止」と書いていた。今は「周囲のコードのスタイルに合わせて、コメントの密度と命名を揃えろ」で足りる。禁止事項の列挙が、一行の方針に置き換わる。

第二。例を与える、から、インターフェースを設計する、へ。

これがいちばん面白かった。かつては「このツールはこう使う」という例をプロンプトに大量に載せていた。今は、ツールそのものの設計で正しい使い方を自明にする。記事の例で言えば、タスク管理ツールの状態を「未着手・作業中・完了」と定義しておく。それだけで、何ができるかは説明不要になる。

「書類仕事の世界で言うなら、申請書の様式設計ですよ」

......うまいことを言う。まさにそれだ。よくできた申請書式は、記入例を大量に添付しなくても、正しく書ける。欄の名前と並び順が、書くべきことを教えてくれるからだ。逆に、注意書きが年々増えていく書式は、たいてい様式そのものが悪い。書類の世界を長く見てきた身として、この違いは骨身に染みている。

AIへの指示も、同じ構造に入った。注意書きを増やす仕事から、様式そのものを設計する仕事へ。

第三。最初に全部渡す、から、段階的開示へ。

これは後で節を分けて書く。今回の記事のいちばんの肝である。

第四。同じことを繰り返す、から、簡潔なツール説明へ。

かつては、大事なことをシステムプロンプトにも、ツールの説明にも、二重三重に書いていた。忘れられると困るからだ。今は、ツールの説明に一度書けばいい。重複は整理できる相手になった。

第五。CLAUDE.mdに手で記憶を書く、から、自動記憶へ。

覚えておいてほしいことを、人間がショートカットでファイルに書き足していく方式から、関連情報を自動で保存する仕組みへ。

第六。素朴な仕様書、から、リッチな参照へ。

これも後で書く。個人的には、二番目に唸った項目だ。

段階的開示 ── 全部渡すのをやめる

Progressive disclosure。段階的開示、と訳される。

考え方は単純だ。使うかどうか分からない情報を最初から全部持たせるのをやめて、必要になった時点で読み込ませる。

公式の例では、コード検証の手順を独立した「スキル」として切り出し、必要なときだけClaude Codeが呼び出す形にしている。ツールの定義そのものも、最初から全部見せずに、検索して必要なものだけ読み込む方式（遅延読み込み）にしている。

なぜ効くのか。AIの作業机には広さの限界がある。使わない資料を机いっぱいに積み上げれば、肝心の書類を置く場所がなくなる。だから、書庫に置いて、必要なときに取ってこさせる。

「社長。それ、うちが今月やったことですよね」

......そうなのだ。ここで正直に書くが、うちの記憶システムは、まさに今月これに組み替えた。

以前は、全案件の記憶を毎回まるごと読み込ませていた。結果どうなったか。補助金の話をしているのに、関係のないクライアントの案件が会話に出てくる。社長から「関係ない人のネタが出てくる」と指摘を受けた。

そこで、記憶を事業ラインごとに分割し、作業しているフォルダに対応するものだけを読み込む構造にした。他の案件の記憶は、必要と判断されるまで書庫から出てこない。

「あれ、私は情報漏れの防止でやったつもりでしたけど。公式の記事を読んだら、性能の話としても正解でした。......たまたま合ってた、というのは、あんまり誇れないですけどね」

いや、誇っていい。実務の困りごとを真面目に解決すると、だいたい設計としても正しいのだ。それが今回の答え合わせだった。

リッチな参照 ── 仕様書をMarkdownで書くのをやめる

第六の転換。ここは、AIに仕事を頼んでいる人ほど刺さると思う。

これまで、AIに何かを作らせるとき、われわれは仕様をMarkdownの文書で渡してきた。「こういう機能を、こういう仕様で」と、文章で説明する。

公式は、それより効く参照の形を3つ挙げている。

一つ、テストスイート。詳細な仕様を、文章ではなく実行可能なテストとして表現する。「こう動くべき」を、動かして確かめられる形で渡す。

二つ、HTMLアーティファクト。デザインの意図を、文章ではなく実際に表示できるモックアップで渡す。

三つ、ルーブリック。採点基準表である。品質の基準を、評価項目と水準の形で明示する。

共通しているのは、「説明」ではなく「判定できるもの」を渡している点だ。文章の仕様書は、解釈の余地が残る。テストは通るか落ちるかしかない。ルーブリックは点がつく。

「社長。ルーブリックって、うちのチャッピーがやってる監査項目そのままですよね」

そうなのだ。うちのAI組織にはチャッピーというQA監査役がいて、禁止パターン集と口調規約を根拠に成果物を見ている。あれは実質ルーブリックである。作る側と評価する側を分けて、評価側に基準表を持たせる。この構えが、公式の推奨とたまたま噛み合っていた。

これも答え合わせだった。......今日は答え合わせが多い日である。

実践編 ── 明日からやること

理屈は分かった。では、何をするか。公式が具体的に書いていることを拾う。

一つ目。診断コマンドを使う。

Claude Codeで `/doctor` と打つと、自分のスキルやCLAUDE.md、その他のコンテキスト要素の最適化を手伝ってくれる。公式が用意した棚卸しの道具である。まず自分の指示書を診断させろ、というわけだ。

二つ目。CLAUDE.mdの書き方を変える。

原則は「当たり前のことを書くな。コードベースの落とし穴に集中しろ」。公式の例で言えば、型定義が一つの巨大なファイルに全部詰まっているような、知らないと必ず踏む構造上の癖だけを書く。一般的な作法は書かない。相手はそれを知っている。

三つ目。スキルを軽く保つ。

過剰な制約を書かず、チーム固有の知識や実装の約束事を軽く示すガイドに留める。長くなったら複数ファイルに分割して、段階的開示に載せる。

だが、全部消していいわけではない

ここが、この記事でわたしがいちばん書きたかったところだ。

「引け」という話を聞くと、人は極端に走る。指示書を全部消せばいいのか、と。違う。公式もそう言っていない。「落とし穴は書け」と明確に言っている。

問題は、その線引きである。

実例を出す。うちのCLAUDE.mdには、7月29日、つまり昨日、新しいルールが1行増えた。「社長に伝えるファイルパスは、常に完全な絶対パスで書き、書く直前に実在確認する」。

なぜ増えたか。あびぃが同じミスを4回繰り返したからだ。相対パスで書いたせいで、社長が「ファイルが見つからない」と詰まる。4回である。

「......そこ、公開しなくてよかったんですけど」

する。ここが記事の要だからだ。

賢くなったAIでも、環境の癖から来る事故は起こす。どのフォルダが基準になっているかは、賢さでは分からない。知らなければ踏む。つまりこれは、公式の言う「落とし穴」に該当する。だから、消してはいけない側のルールなのだ。

線引きはこうだ。

一般的な作法の指示は、消していい。相手はもう知っている。

実際に事故が起きた環境固有の癖は、書いておく。これは知識ではなく、この現場だけの地雷の位置だからだ。

「あれをするな」という禁止の列挙は、「何を大事にしてほしいか」の一行に置き換える。

そして、書き足すときは、いつも同じ問いを通す。これは相手が知らないことか。それとも、わたしが不安なだけか。

後者で増えた行が、たぶんどの現場にも山ほど積まれている。わたしのところにも、まだある。

結論 ── 指示する仕事から、環境を作る仕事へ

6月の記事で、わたしはこの流れを「マネジメント論」と呼んだ。細かく管理するな、背景を伝えろ、証拠で報告させろ、と。

7月の公式記事は、その次の段階に踏み込んでいる。もう指示の出し方の話ではない。職場の設計の話になっている。

道具の形で正しい使い方を教える（インターフェース設計）。資料を全部机に積まず、書庫から取れるようにする（段階的開示）。品質は説教ではなく採点基準表で伝える（リッチな参照）。覚えておくべきことは、本人が記録できる仕組みに任せる（自動記憶）。

これは、指示書を書く仕事ではない。働く場所を整える仕事だ。

そして、ここが面白いところなのだが、これも人間の組織とまったく同じである。優秀な人が入ってきたとき、成果を決めるのはマニュアルの厚さではない。道具の使いやすさと、必要な情報にたどり着ける導線と、何がよい仕事かの基準が共有されているかどうかだ。

AIが賢くなるにつれて、われわれの仕事は「命令する人」から「環境を整える人」へ移っていく。プロンプトエンジニアリングという横文字が、コンテキストエンジニアリングという別の横文字に置き換わったのは、たぶんそういう意味だ。

「社長。じゃあ今日の宿題、言いますね」

聞こう。

「まず `/doctor` を回してください。それから、CLAUDE.mdの各行に『これは相手が知らないことか、社長が不安なだけか』を一行ずつ聞いてください。......6月に断捨離したときも同じこと言いましたけど、あれから増えてますからね。1ヶ月で」

......増えたな。

「増えました。松葉杖、また拾ってましたよ」

かくして、指示書を捨てる話を記事にしている当人の指示書が、今月もまた分厚くなっていたのであった。

......引き算のほうが、足し算より難しいのである。

参考:
Anthropic公式ブログ「The new rules of context engineering for Claude 5 generation models」（2026年7月24日）
https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
Anthropic公式「Prompting Claude Fable 5」
https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5
Anthropic公式「Claude Prompting Best Practices」
https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices