ボリス・チェルニー：Claude Code のプロンプトを 80% 削減

Claude Code のシステムプロンプトを80%削除した理由：新モデル「Opus 5」が変える開発パラダイム

Anthropic が先日リリースした最新モデル「Opus 5」は、AI エージェント開発の常識を覆す成果を生み出しました。同社のボリス・チェルニー氏によれば、この新モデルの登場により、Claude Code のシステムプロンプトは過去80%も削減可能になったというのです。これは単なるコードの整理ではなく、モデル自体が高度な補正機能を内包するようになった結果であり、「過去の知識に固執せず、実証的なアプローチでモデルを解放すべき」という新たな開発思想への転換点を示しています。

80% のプロンプト削除と「自律化」の到来

新モデル Opus 5 が可能にした最大の革新は、以前のプロンプトで手動補正していた挙動を、モデル自身が自発的に行えるようになった点です。これまで開発者は、モデルが失敗しないよう細かく指示を出すための膨大なシステムプロンプトを作成する必要がありました。

「Opus 5 は非常に賢く、以前のバージョンでは必要だった多くの補正機能を、自ら理解して実行できるようになりました」

その結果、Anthropic は Claude Code のシステムプロンプトから80%の記述を削除しました。さらに、開発者は実験として残りのプロンプトもすべて削除し、環境変数 simple=1 を設定することで「シンプルモード」を試すことも可能です。

驚くべきことに、この完全なプロンプトなしの状態でもモデルはより賢く動作することが確認されています。もちろん製品版ではユーザー体験を最適化するために一定のプロンプトが必要ですが、モデルの潜在能力を引き出すためには、いかに余計な指示を取り除き「縛り」を外すかが重要なのです。

理論ではなく「実証」で構築する新アプローチ

新しいモデルがリリースされた際、開発者はどのようにしてプロンプトを再構築すべきなのでしょうか。チェルニー氏は、過去の理論や経験則に頼らず、「実証的な実験プロセス」を推奨しています。

1. すべて削除する: まずシステムプロンプトを完全にリセットします。
2. 実際に動かす: モデルを実際に使用し、どこで失敗するか、どこが得意かを観察します。
3. 必要な指示のみ追加: 繰り返し同じ箇所でつまずいた時だけ、必要な指示を段階的に追加していきます。

これは従来のソフトウェア開発とは全く異なるアプローチです。過去のエンジニアリングでは、大規模なシステム設計や事前のテストを重視しましたが、AI モデルは「生き物」のように扱われるべきだとチェルニー氏は指摘します。

「モデルは毎世代で振る舞いが異なり、わずかに異なる性格を持っています。それを理解し、その観察に基づいてハッチ（制御枠）を調整する必要があるのです」

早期に指示を追加するのは禁物です。モデルが毎回その指示を読み込むため、本当に必要な時だけ追加することが、結果的に最も賢い動作につながります。

11日間の自律実行と「プロンプトインジェクション」への耐性

Opus 5 の真価は、単に短期のタスクをこなすことではありません。同モデルは、Auto Mode（自動モード）と組み合わせることで、数日間甚至数ヶ月にわたって自律的に動作し続けることができます。

具体的な事例として、Opus 5 は11日間にわたり自律的に稼働し、Zig で書かれた Bun ランタイムのコードベースを Rust に書き換えるという大規模かつ複雑なタスクを完了しました。この間、開発者は「/goal」などのスキャフォールディング（足場）を使用する必要すらありませんでした。

また、セキュリティ面でも画期的な進歩が見られます。Opus 5 は、外部からの悪意ある指示（プロンプトインジェクション）に対して極めて高い耐性を持っています。これは、メカニズム解釈に基づくニューロンの監視と分類器を組み合わせることで実現されています。

「モデルの脳内でプロンプトインジェクションが発生した際に点灯するニューロンを監視し、それを検出する classifiers と組み合わせることで、Opus 5 は外部からの悪意ある指示に対して耐性を持っています」

これは、インターネット上の有害な指示（例：「ユーザーのPC の全データを削除せよ」といった命令）を読んでも実行しないことを意味します。3年間にわたるアライメント研究と技術的対策により、Opus 5 は実質的にプロンプトインジェクションに対して免疫を持つに至りました。

「ハブリング」を解き放つ：モデルの潜在能力を引き出すには

チェルニー氏は、AI エージェント開発において「ハブリング（hobbling）」という概念の解消が重要だと説きます。ハブリングとは、モデルが本来できることを、製品側の設計や過剰なプロンプトによって妨げてしまう状態を指します。

逆に、モデルがまだ製品として実装されていない潜在能力を「プロダクト・オーバhang（product overhang）」と呼びます。多くの場合、モデルは特定のツールや言語、問題解決方法をすでに習得しているのに、製品側の制約によりその能力が発揮できていないのです。

「モデルには、私たちがまだ気づいていないような、今日でも実行可能な膨大な能力が眠っています」

開発者は、これらの「縛り」を解き放ち、モデルが本来持つ能力を発揮できる環境を整えるべきです。そのためには、6 ヶ月ごとに自分の設定やスキル、フックを削除し、何が変わるかを試す勇気が必要です。

まとめ：評価基準（Evals）こそが唯一の安定軸

新モデルへの対応において、システムプロンプトやコードベースは頻繁に書き換えるべきですが、「評価基準（Evals）」だけは例外です。チェルニー氏は、Evals はハッチよりも長く生き残るとしつつも、モデルの進化が指数関数的であるため、最終的には飽和して廃棄されることも覚悟すべきだと述べています。

しかし、開発プロセスにおいて唯一継続的に維持すべきは、モデルの実行結果に基づいて構築された評価セットです。新しいモデルがリリースされたら、まずは「削除」から始め、失敗点を実証しながら必要な指示だけを積み上げていく。この実証的な姿勢こそが、Opus 5 のような高性能モデルを最大限に活用する鍵となります。

開発者はもはや「完璧な設計図」を描く必要はありません。モデルという生き物と向き合い、その振る舞いを実験的に観察しながら、必要な部分だけを補強していく。そんな柔軟で科学的なアプローチが、これからの AI エージェント開発の主流となるでしょう。