Claude 5 Opusの思考停止を打破する：システムプロンプトの「空白」を埋める技術

エンジニアとして、長年丹念に育て上げたCLAUDE.mdや常時ロードされるルールファイルが、ある日突然「無力化」されるという事態ほど、背筋が凍る瞬間はない。まるで、完璧にチューニングしたCI/CDパイプラインが、依存ライブラリのメジャーアップデート一つで、理由もわからずデッドロックを繰り返すようになった時のあの絶望感に近い。今回、Claude CodeのモデルをOpus 5に切り替えた直後に発生した「思考の浅さ」という現象は、まさにその典型だった。構造化された回答は影を潜め、見出しも区分もないフラットな散文が垂れ流され、議論を深めようとしても「なぜ」を掘り下げない。まるで、優秀なペアプログラマーが突然、思考停止したジュニアエンジニアに入れ替わったかのような違和感だ。

この現象の恐ろしい点は、ルール（rules）側には一切の変更を加えていないにもかかわらず、モデルの出力品質が劇的に劣化して見えることにある。多くのエンジニアはここで「モデルの知能が下がった」と短絡的に結論づけがちだが、それは大きな誤りだ。真の原因は、モデルの背後で暗黙のうちに更新されていた「本体システムプロンプト」にある。Anthropicが導入した「lean system prompt」という設計思想は、新世代モデルが行動を内在化しているという前提に立ち、旧来の冗長な指示を約8割削減した。しかし、この「削減」こそが、我々が長年積み上げてきたルールとの間に致命的な不整合を生んでいたのだ。

具体的には、Opus 5に配られるシステムプロンプトから、応答形式を規定する文言が完全に消失している。旧世代のプロンプトには「構造化せよ」「見出しを使え」「簡潔にせよ」といった明示的な制約が刻まれていたが、Opus 5ではそれらが消え、代わりに「十分な情報があれば動け」「網羅より推奨を」という自律的な行動指針が優先されている。つまり、我々が「ルール」として記述していた指示は、かつてはシステムプロンプトという「強固な土台」の上に立っていたが、その土台が消滅したことで、モデルの素の出力傾向（散文的で即断即決な傾向）が剥き出しになったのである。これは、フレームワークのデフォルト設定が変更されたことに気づかず、アプリケーションコードの挙動に首を傾げている状態に等しい。

では、この「空白」をどう埋めるべきか。単に「構造化して書け」とルールに追記するだけでは、Opus 5の強固な「即行動」という訓練済み既定には勝てない。我々エンジニアが取るべき対策は、本体システムプロンプトの原文を名指しで引用し、優先順位を明示的に上書きすることだ。例えば、"If you are weighing a choice, give a recommendation, not an exhaustive survey"という本体指示に対し、ルール側で「複数案を出す際は評価軸を付けろ」と対抗させる。この際、単なる禁止事項の羅列は無意味だ。禁止は違反を検知するだけで、代替案を提示しないからだ。代わりに「望ましい動き」を具体的に定義し、発火条件を「観測可能な事実」に落とし込む必要がある。

さらに重要なのが、指示を「どの層で届けるか」というレイヤーの選定だ。Claude Codeには、本体システムプロンプト、output style、UserPromptSubmit hook、そして常時読み込まれるrulesという4つの経路がある。実測の結果、最も強力なのは「行動の直前に、短く、毎回届ける」ことである。特に、UserPromptSubmit hookを用いて毎発話の直後に「ツール実行より先に返答せよ」という指示を注入する手法は、コスト対効果が極めて高い。1発話あたり約50トークンという微々たる消費で、200Kコンテキストの海に埋もれがちなルールを、モデルの短期記憶の最前線に引き戻すことができる。

以下の表は、指示の伝達経路と、その効力・特性を整理したものである。エンジニアは、自身のルールがどの層で処理されているかを常に意識しなければならない。

この切り分けを理解した上で、ルールを「禁止の列挙」から「到達すべき状態の定義」へと書き換えること。これが、新世代モデルと共存するための唯一の道である。モデルの更新は、単なる性能向上ではなく、開発環境の前提条件そのものの書き換えであると認識すべきだ。

今回のOpus 5における「思考の浅さ」問題は、単なるプロンプトエンジニアリングのトラブルシューティングに留まらない。これは、我々エンジニアが「AIの自律性」と「人間の制御」のバランスをどう取るかという、より根源的な問いを突きつけている。Anthropicが目指す「lean system prompt」は、AIが人間を介さずとも最適解を導き出す未来を志向している。しかし、その「最適解」が、我々が求める「論理的で構造化された思考プロセス」と乖離している場合、我々はAIを「道具」として使いこなしているのか、それともAIの「出力傾向」に自らの思考を合わせるよう強制されているのか、その境界は極めて曖昧だ。

明日から我々が取るべき対策は明確だ。まず、自身の開発環境における「AIの挙動」を、ブラックボックスとして放置しないこと。モデルの更新履歴（changelog）を読み込み、システムプロンプトがどう変化したかを実測し、自身のルールセットとの矛盾をコードのデバッグと同じ熱量で解消すること。そして、AIに「思考」を丸投げするのではなく、AIがどのようなロジックで回答を生成しているかという「メタ認知」を常に働かせることだ。AIが「十分な情報がある」と判断して即座にツールを実行する時、それは本当に正しい判断なのか、それとも単にモデルの学習データが推奨する「効率化」の罠に陥っているだけなのか。

我々エンジニアは、AIという強力なレバレッジを手に入れた。しかし、そのレバレッジが大きければ大きいほど、支点となる「人間の判断基準」が揺らげば、システム全体が崩壊するリスクも高まる。AIの出力が浅いと感じた時、それはAIの限界ではなく、我々がAIに与えている「指示の解像度」の限界ではないだろうか。あなたは、AIというブラックボックスを制御し続ける覚悟があるか。それとも、AIが提示する「効率的な散文」に安住し、思考の深さを手放す道を選ぶのか。この問いに対する答えこそが、これからのAI時代におけるエンジニアの価値を決定づけるはずだ。