Claude Opus 5で常識崩壊！プロンプトの「おまじない」が技術的負債になる日

かつて我々エンジニアは、LLM（大規模言語モデル）の「ハルシネーション（嘘）」や「詰めの甘さ」に幾度となく泣かされてきた。本番環境にデプロイしたAIエージェントが、一見すると完璧な、しかし致命的なバグを含んだコードを出力したときのあの冷や汗。それを防ぐために、我々はシステムプロンプトに「出力前に必ず自己検証を行ってください」「ステップバイステップで考えて、もう一度答えを確認してください」といった、いわば『おまじない』のような指示を書き連ねてきた。これは、レガシーシステムに眠る『なぜ動いているか分からないが、消すと動かなくなるコード』と全く同じ精神性である。しかし、Anthropicの最新モデル「Claude Opus 5」の登場によって、この長年のプロンプトの定石が、一瞬にして牙をむく技術的負債へと変貌した。私はこの変化を、単なるモデルのバージョンアップではなく、プロンプトエンジニアリングにおける『パラダイムシフト』であると確信している。

Opus 5において最も衝撃的なのは、モデルが「言われなくても自分で確認作業を行う」という極めて高い自律性を獲得した点だ。これまでのモデルでは、自己検証を促すプロンプトは精度向上のための必須テクニックだった。しかし、すでに自律的に検証を行っているOpus 5に対して「最後に検証して」と指示すると、モデルは愚直にその指示に従い、すでに完了している確認作業をもう一度やり直す。つまり、二重検証が発生するのだ。我々が直面するのは、無駄なトークン消費によるAPI利用料金の高騰と、レスポンスを待つ間の不毛な遅延時間である。品質が上がるわけでもないのに、コストとレイテンシだけが倍増する。これは、すでにデバッグが完了して正常に動作している関数に対して、無駄なアサーションコードを何重にも追加して実行速度を低下させているようなものだ。

さらに、タスクの並列化や分担を促す「もっと分担して」「サブエージェントに作業を委譲して」という指示も、Opus 5では牙をむく。前世代のOpus 4.8などでは、複雑なタスクを自ら分割することを嫌がる傾向があったため、背中を押す指示が有効だった。しかし、Opus 5は放っておいても自分からタスクを細分化し、サブエージェントを立ち上げて分担する。そこに「もっと分担しろ」というアクセルを踏み込むと、必要以上にエージェントが乱立し、子エージェントの起動、状況説明、報告の受け取りといったオーバーヘッドが爆発的に増加する。マイクロサービスを過剰に分割しすぎて、ネットワーク遅延と管理コストで自滅するシステムと全く同じ構図が、プロンプトの中で起きているのだ。

開発現場で「最近、AIの回答がやたらと長くて冗長だな」と感じたとき、あなたならどう対処するだろうか。多くのエンジニアが、APIの「effort（思考の深さ）」パラメータを下げて調整しようとするはずだ。しかし、これはデータベースのパフォーマンスが悪いからといって、インデックスを貼らずにメモリ割り当てだけを削るような致命的な誤解である。Opus 5において、effortパラメータが制御するのは「考える量（思考プロセス）」であり、出力される「文章の長さ」ではない。effortを下げると、モデルは深く考えることをやめるが、出力する文章の長さは変わらない。結果として、中身がスカスカで質の低い長文が返ってくるという、開発者にとって最も避けたい最悪の結果を招くことになる。出力を短くしたいのであれば、パラメータをいじるのではなく、プロンプトの最後に「回答は簡潔に。前置きと要約の繰り返しを避ける」と素直に記述するのが、最も効果的かつ確実なアプローチなのだ。

そして、私が最も強い技術的懸念を抱いているのが、コードレビュー自動化における「重大な問題だけ報告して」という指示の逆転現象だ。ノイズを減らし、重要なバグだけに集中したいという開発者の意図は理解できる。しかし、Opus 5はこの指示を「言葉通りに」完璧に守ってしまう。モデルはバグを検出しているにもかかわらず、「これは重大ではない」と自ら判断したものを容赦なく切り捨てる。結果として、報告件数は劇的に減るが、その裏で重大なバグが見逃され、ログにも残らずに本番環境へ素通りしていくという「サイレントバグ」の温床となる。これは、例外処理でキャッチしたエラーをすべて握りつぶし、何事もなかったかのように正常終了（HTTP 200）を返す極悪なコードを書くのと同じ行為だ。

この「サイレントな破壊」は、APIレベルの仕様変更でも顕著に現れている。Opus 5では、thinking（思考機能）を明示的に指定しない場合、デフォルトで「考える」ようになった。これにより、max_tokens（最大出力トークン数）の設計が崩壊する。max_tokensは「回答の長さの上限」ではなく「出力全体（思考プロセス＋回答）の上限」であるため、モデルが深く考えた結果、思考プロセスだけでトークン枠を使い果たし、肝心の回答が途中で途切れてしまうのだ。しかも、リクエスト自体はHTTP 200（成功）で返ってくるため、従来の try-catch によるエラーハンドリングでは検知できない。さらに、安全性チェックによる拒否（refusal）が発生した際も、例外を投げずにHTTP 200で返り、stop_reasonが “refusal” になるという仕様に変更された。これらは、エラーログを監視しているだけの運用監視チームを完全に欺く、極めて厄介な挙動と言える。

我々は今、プロンプトエンジニアリングという過渡期の技術が、急速に「技術的負債」へと変化していく歴史的な瞬間に立ち会っている。昨日までのベストプラクティスが、今日のシステムを破壊するバグになる。この冷酷な現実を前に、我々エンジニアが取るべき具体的な処方箋は、プロンプトの「引き算」と「制約の具体化」である。まずは、社内のシステムプロンプトや共有テンプレートを検索し、かつて良かれと思って埋め込んだ「検証」「分担」を促す指示を徹底的に削除することから始めよう。モデルの進化に伴い、我々が用意すべきなのは「補助輪」ではなく、暴走を防ぐための「ブレーキ（上限値）」なのだ。

しかし、ここで立ち止まって考えてみてほしい。モデルが賢くなるたびにプロンプトを書き直さなければならないのだとしたら、我々はAIをコントロールしているのではなく、AIの気まぐれな仕様変更に振り回されているだけではないだろうか。プロンプトという「曖昧な自然言語によるコード」に依存し続けるアーキテクチャそのものが、本質的なリスクを孕んでいるのではないか。今後、GPTやGeminiの次世代モデルが登場するたびに、同じような「常識の逆転」は確実に発生する。我々エンジニアに課せられた真の問いは、プロンプトの微調整という目先のハックではない。モデルの進化に対して、いかにして疎結合で、堅牢で、テスト可能な「AI統合システム」を設計できるかという、ソフトウェアエンジニアリングの本質的な挑戦なのだ。あなたのシステムのプロンプトは、次のアップデートに耐えられるだろうか？