Claudeの開発チームが、Claude Codeのsystem promptを80%以上削った、と聞くと少し驚きます。
ふつうは「安全のためにルールを増やす」方向に行きがちだからです。でもこの記事は、その逆をやっている。モデルが賢くなったなら、人間側が細かく縛りすぎないほうがいい——そんな発想の転換をかなりはっきり示しています。
この文章でまず大事なのは、話題が単なるprompt術ではないことです。
Claudeに何を指示するか、という一回きりの話ではなくて、どういう文脈を日常的に持たせるか、という設計の話になっています。これを記事では context engineering と呼んでいます。
ざっくり言うと、AIに渡る情報は「今この場の入力文」だけではありません。
system prompt、Skills、CLAUDE.md、memory、参照ファイルなどが積み重なって、AIの“考える前提”になります。人間でいえば、目の前の指示文だけでなく、社内ルール、過去の会話、マニュアル、空気感まで含めて判断している感じです。
で、Claude 5世代では、この前提づくりの常識がかなり変わった。
Anthropicは、Claude Codeのsystem promptを大幅に削っても、コーディング評価で目立った悪化はなかったと述べています。ここはかなり象徴的です。つまり「長くて細かい指示 = 高性能」ではない、ということです。
記事の中で印象的なのは、昔のベストプラクティスが今では“神話”になっている、という言い方です。
たとえば以前は、Claudeがファイルを消したり変なコメントを書いたりしないように、「コメントは原則書くな」「多段のdocstringはだめ」「計画書を勝手に作るな」といった強いルールを置いていたそうです。
これは当時としては理にかなっています。
モデルが今ほど賢くないなら、余計な事故を防ぐためにガチガチに縛るのは当然です。けれど、そのルールは万能ではない。ユーザーが丁寧な説明文を求める場合もあるし、複雑なコードでは長めの説明が必要なこともある。つまり、強い禁止は“だいたい正しい”けど“いつでも正しい”わけではなかったわけです。
Claude 5世代では、そのへんをモデル自身の判断に任せられるようになった。
記事では、今のsystem promptでは「周囲のコードに合わせて、コメント密度や命名、流儀を揃えろ」という方向に変えたと説明しています。これ、かなり自然です。人間でも、既存のコードがコメントまみれなのに自分だけ無言、みたいなのは変ですから。
ここも面白いところです。
以前は「どうツールを使うか」を例で見せるのが重要だと考えられていました。ところが新しいモデルでは、例を増やすことが逆に探索範囲を狭めることがある、と言っています。
これはちょっと直感に反します。
例が多いほど親切に見えますよね。でもAIにとっては、例が「これ以外のやり方はダメ」という見えない柵になりうる。だから今は、例を足すよりも、toolやscriptやfileの設計を良くするほうが効く、と。
たとえばTodo toolなら、status を pending / in_progress / completed のように整理しておくと、AIがどう使うべきか自然にわかる。
つまり、命令で細かく縛るより、UIやデータ構造を賢くするほうが強い。これはAI設計というより、ソフトウェア設計そのものの話にも見えます。個人的にはかなり筋がいいと思います。
記事が強く押している考え方のひとつが progressive disclosure です。
日本語にすると少し堅いですが、要は「必要になった情報だけ、その時に開く」というやり方です。
昔は、重要なことは全部system promptに詰める、という発想になりがちでした。
でもそれだと、今すぐ使わない情報まで毎回背負わせることになる。人間でも、分厚い社内規定を最初から全部読むのはしんどいですよね。AIも同じで、使う場面に応じて適切な場所から適切な情報を引っ張るほうがよい。
Claude Codeでは、コードレビューや検証の手順を独立した Skills に分け、必要なときだけ呼び出すようにしているそうです。さらに、一部のtoolは deferred loading、つまり使う前に検索して定義を取ってくる方式になっている。
この考え方は、CLAUDE.mdやSkill.mdを作る側にもそのまま当てはまります。「全部のベストプラクティスを1ファイルに詰め込む」のではなく、木の枝のように分けて、必要なタイミングで読ませる。これ、地味ですがかなり本質的です。
ここは実務でかなり役立ちそうです。
CLAUDE.md には、リポジトリが何のためのものかを短く書きつつ、もっとも大事なのは「このコードベースの変なクセ」だと記事は言います。
たとえば、型定義が1つの巨大ファイルにまとまっている、とか、独特の命名ルールがある、とか。
逆に、ファイルを見ればわかる当たり前のことを長々と書くのは無駄です。これは人間のREADMEでも同じですよね。読めばわかることを説明されると、だいたい読む気がなくなります。
さらに、検証方法が特殊なら、その手順をSkillsとして切り出して、CLAUDE.mdから参照する。
ここには「文脈の圧縮」があります。すべてを書き込むのではなく、必要なときだけ展開できるようにしておく。私はこの感覚がかなり大事だと思います。AIの性能を引き出すというより、AIが迷子にならない現場づくりに近いです。
記事では、参照の形もアップデートされています。
昔はmarkdownのplanファイルや簡単なspecを置いておくのが定番でした。でも今は、HTML artifact、コード、テストスイート、別のコードベースの関数、さらには rubric まで参照にできる、と説明しています。
rubric は少し聞き慣れないかもしれません。
簡単に言うと「良し悪しを判断するための基準表」です。たとえば「いいAPI設計とは何か」を、評価の観点ごとに整理したもの。Claudeはそれを使って、別の verifier agent に評価させるような動きもできるそうです。
これ、地味にすごいです。
ふつう、AIに“良さ”を説明するのは難しい。でもHTMLやコードやテストのように、すでに具体的な形を持つものなら、AIはかなりうまく扱える。要するに、ふわっとした説明より、触れるものを渡したほうが強い。ここは人間同士の仕事でも同じで、耳が痛い話です。
「AIが賢くなったなら、雑に縛るより、必要なときに必要な情報が出るように設計せよ」です。
この方向転換は、単なるAnthropic社内のテクニックにとどまらないと思います。
今後のAIエージェントは、巨大なルール文を読み込む機械というより、適切な文脈にたどり着ける機械になっていくはずです。だから重要なのは、長い禁止事項を積むことではなく、情報の置き場所を設計することになる。
個人的には、ここにかなり未来を感じます。
人間の“厳密な指示”に依存する時代から、“賢い判断ができるように環境を整える”時代へ。AIの進化って、指示を増やすゲームではなく、むしろ減らす勇気のゲームなのかもしれません。
参考: The new rules of context engineering for Claude 5 generation models | Claude by Anthropic
