システムプロンプトを8割削除 Claude 5世代の「指示を減らす」設計術

AIへの指示書は、細かく書いた方が安心。私たちも長くそう考えてきました。その常識が、作っている本人たちの手で覆されました。

Anthropicのエンジニアが7月25日に公開した解説記事によると、同社はOpus 5やFable 5といったClaude 5世代のモデル向けに、Claude Codeのシステムプロンプト(AIに常時渡している基本指示)を8割超も削除したそうです。それで性能はどうなったか。社内のコーディング評価では、測定できる劣化はなかったとのこと。この記事はClaude Code周辺の実務者にも大きく読まれています。

指示を8割捨てても、結果は変わらない。昨日の記事がAIへの「教え方」の話だったのに続いて、今日は「教える量」の常識が変わった話です。

何が起きたか 「縛りすぎ」が性能の足かせになっていた

前提を少しだけ。AIの出力を左右するのは、その場で打つプロンプトだけではありません。システムプロンプト、スキル、CLAUDE.mdのような設定ファイル、過去のメモリ。こうした「AIに渡る情報一式」の設計をコンテキストエンジニアリングと呼びます。6月の記事で「入れすぎにも落とし穴がある」と書きましたが、今回の発表はその落とし穴を、開発元が自分たちの製品で実証した形です。

記事によると、削除の理由は明快で、AIを縛りすぎていたから。社内の利用記録を読み返すと、システムプロンプトの「コメントを書くな」と、別の指示の「適切に文書化せよ」のような矛盾する指示が1つのリクエストに同居していて、モデルはどちらに従うか余計に考え込まされていたそうです。

かつてのモデルには、この縛りが必要でした。放っておくと的外れなコメントを量産したり、頼んでもいない文書を作ったりしたからです。ただ、モデルの判断力が上がった結果、細かいルールはリスク回避の保険から、判断の邪魔へと役割が変わってしまった。耳が痛い話です。AIに任せている私たちの指示書にも、きっと同じことが起きています。

ルールで縛るから、判断に任せるへ

象徴的な例が記事に載っています。コードのコメントについて、旧システムプロンプトは「原則コメントを書くな、複数行のコメントブロックは禁止、1行までにしろ」といった細かい禁止則を並べていました。新しいシステムプロンプトは、たった一言です。

周囲のコードになじむように書け。コメントの密度も、命名も、周囲に合わせろ。

禁止のリストではなく、判断の基準を1つ渡す。これは新人教育に似ています。優秀な中途社員に、分厚い禁止事項マニュアルを渡す会社と、「うちの流儀はこの資料の通り。あとは現場を見て合わせて」と言える会社。後者の方が力を引き出せるのは、人もAIも同じということのようです。

では、何も書かなくていいのか。そうではありません。記事も、重要度の高い領域では今も明確な縛りを残すとしています。間違えたら取り返しがつかない箇所は厳格に、それ以外は基準だけ渡して任せる。全部を縛るか全部を任せるかではなく、縛る場所を選ぶのが新しい流儀です。

全部先に読ませるから、必要な時に読める棚へ

もうひとつの柱が、プログレッシブディスクロージャー(必要になった時に、必要な分だけ読み込ませる)です。

以前のClaude Codeは、コードの検証手順やレビュー手順まで基本指示に全部詰め込んでいました。いまは、それらを個別のスキルに切り出して、Claudeが必要な場面で自分で読みに行く方式に変えたそうです。設定ファイルやスキルを「知っていることを全部書き込む中央倉庫」にするのは、よくある誤解だとも書かれています。

例えるなら、入社初日に全マニュアルを読み聞かせる会社と、1枚の案内と整理された棚を渡して「必要な時にここを見て」と言う会社の違いです。前者は聞いた側の頭があふれます。AIも同じで、関係ない指示が大量に載っているほど、いま重要な指示の効きが薄まる。だから入口は軽く、詳細は棚に。この構造が、賢いモデルの力を最も引き出すというわけです。

見本は「文章で説明」より「実物を渡す」

細かい発見の中で、業務利用にいちばん効きそうな話がこれです。記事は、AIに何かを作らせるとき、言葉での説明より実物の参照物を渡す方が良い結果になるとしています。デザインなら、文章の説明やスクリーンショットより、HTMLで作ったモックそのもの。仕様書の代わりに、合格条件を書いたテスト一式でもいい。

これは非エンジニアの仕事でも同じです。「丁寧かつ簡潔なトーンで」と形容詞を並べるより、理想に近い過去のメール1本を渡す。「見やすい資料で」と言うより、社内で評判の良かったスライドを1枚添える。説明の言葉を磨くより、お手本の実物を探す方が早い。私たちの導入支援でも、AIの出力が安定しない相談の多くは、この「お手本添付」だけでかなり改善します。

ちなみに例を渡すことにも一応の注意があって、記事は「使い方の例を細かく見せすぎると、モデルの探索がその型に縛られる」とも指摘しています。お手本は方向を示すもので、檻にしない。ここでも「縛りすぎない」が通底しています。

中小企業のAI運用に当てはめる3か条

このブログの制作も、調査から公開前チェックまでをスキルにして毎日回しているので、今回の内容は他人事ではありません。実際、45本書いてきて指示書は増える一方でした。うまくいかないことがあるたびにルールを1行足す。すると別の場面でそのルールが邪魔をする。今回の記事は、その悪循環への処方箋として読めます。社内のAI指示書に当てはめるなら、この3か条です。

1. 禁止事項を数えてみる: 自社のプロンプトやガイドラインの「〜するな」を数え、それぞれ「本当に毎回正しいか」を問う。半分は「基準を1つ渡せば済む話」のはずです
2. 1枚に全部書かない: 常に読ませる部分は目的と方針だけの軽い1枚にして、詳細な手順は用途別の別ファイル(スキル)に分ける。やって見せて作る方法も出てきた今、スキルの置き場はもう整っています
3. 形容詞よりお手本: 出力がぶれる仕事には、指示の言葉を足すのではなく、理想形の実物を1つ添える

注意点もひとつ。この話は判断力が上がった最新世代だからこそ成り立つ設計です。古いモデルや小型モデルに同じことをすると、縛りを外したぶんだけ暴れることがあります。乗り換えと指示書の見直しは、セットでやるのが安全です。

まとめ: 指示書の厚さは、信頼の薄さ

振り返ると、分厚い指示書とは「AIの判断を信頼していない」という宣言でもありました。モデルの判断力が上がった今、厚さはコストに変わりつつあります。プロンプトの上手さで差がついた時代から、何を任せて何を縛るかの見極めで差がつく時代へ。道具が賢くなるほど、問われるのは使う側の設計です。

すぐ試すなら、いつも使っている定型プロンプトをひとつ選び、禁止事項を3つ外した版を別に作って、同じ仕事で比較してみてください。結果が変わらなければ、その3行はもう要らなかったということ。悪くなったら、そこが本当に縛るべき場所だったということです。どちらに転んでも、自社の指示書の「効いている行」が分かります。