はじめに
先日、自社システムで利用しているLLMを次世代モデル（Opus 5）へ移行する作業を行っていました。その際、公式のプロンプト移行ガイドラインを読んでいて、ある「逆転現象」にハッとさせられました。
公式が推奨していたのは、プロンプトの「足し算」ではなく「引き算」だったのです。
本記事では、LLMの世代交代に伴って発生する「プロンプトの技術負債化」と、それを防ぐためのプロンプト設計・運用のベストプラクティスについて、実体験をベースに共有します。
プロンプトの「サイレント劣化」という罠
Opus 5の移行ガイドでは、これまでプロンプトに仕込んでいた「検証してください」「ダブルチェックをお願いします」「再確認して」といった指示を明示的に削除するよう求められていました。
また、推論レベル（effort）の指針も反転しており、前世代でコーディングタスクのデフォルトとされていた xhigh ではなく、Opus 5では high をデフォルトとし、low や medium をメインに使うよう推奨されていました。
ここで重要なのは、削除を求められたこれらの指示は「当時は正解だった」ということです。
前世代のモデルは検証ステップをスキップする癖があったため、「検証して」と書き添えるのは理にかなったハックでした。当時の出力精度を考慮すれば、xhigh をデフォルトにするのも合理的な判断です。誰も間違った最適化はしていませんでした。
しかし、この「正しさ」はモデルの世代交代とともに賞味期限を迎えます。しかも厄介なことに、エラーを吐いて落ちるわけではなく、サイレントに逆効果（マイナス）へと転じるのです。
古い最適化はエラーを出さずに足を引っ張る
賞味期限切れの最適化がもたらす症状は極めて検知しにくいです。
- プロンプトがエラーになるわけではない
- テストコードはグリーンのまま（Passする）
- 出力結果も一見それっぽく見える
しかし内部的には、不要な検証ターンが回ることでレイテンシが悪化し、無駄にトークンを消費し、指示の重みが分散して肝心のプロンプトの意図が希釈されています。
これは「エラー」ではなく「劣化」です。A/Bテストを組まない限り、まず気づけません。「最近、なんかモデルの挙動がポンコツになった？」と感じたとき、その真犯人は自分たちが過去に仕込んだ「当時のベストプラクティス」かもしれないのです。
使わなくなったnpmパッケージなら package.json を見れば分かりますが、プロンプト内にベタ書きされた一文は、誰の目にも「現在有効な設定」として映ってしまいます。これがプロンプトにおける技術負債の恐ろしさです。
最適化における「深さ」という設計変数
では最適化はすべきではないのか？ 結論から言うと、最適化の「深さ」を意識的に選択・管理することが必要になります。
1. 浅い最適化（モデル非依存）
- ドメインの専門用語の定義
- タスクの完了条件の明確化
- 自社コードの優れた実装例のFew-shot
- 使用禁止APIのブラックリスト
これらはモデルの世代が変わっても価値が落ちません。相手がどのモデルであれ有効な「業務仕様書」だからです。
2. 深い最適化（特定モデルへの密結合）
- 「『検証して』と書けば検証ステップを踏んでくれる」という行動パターンの悪用（ハック）
- 推論レベル（effort）の微細なパラメータチューニング
- モデルの暴走を抑えるための特定の「おまじない」の横展開
これは効果絶大ですが、適合するモデルが存在する期間内でしか機能しません。ソフトウェア工学における「密結合」の問題が、プロンプトとエンジニアリングの境界に現れている状態です。
投資回収期間は「モデルの寿命」より短いか？
深い最適化を行うかどうかの基準は、シンプルなROI（投資対効果）で判断できます。
その最適化の回収期間は、モデルの世代サイクル（数ヶ月〜半年）よりも短いか？
2週間かけてプロンプトフレームワークを特定のモデル向けにゴリゴリにチューニングし、半年でペイする計画を立てても、3ヶ月後に新モデルが出たら前提ごと消滅します。これは投資ではなく浪費です。
逆に、1日で実装できて翌日から毎日数万回叩かれるホットパスであれば、次世代で捨てることになっても十分に元が取れます。
つまり、すべてのプロンプトに「深い最適化」を横展開するのは、解体コストが指数関数的に膨れ上がるためアンチパターンと言えます。
解決策：対策は世代とともに死に、課題は世代を超える
深い最適化を実装した場合、次世代への移行（マイグレーション）コストをどう下げるか。ここが本記事の核心です。
残すべきは「対策（How）」ではなく、「その対策が解決しようとした課題（Why）」です。
❌ アンチパターン（ルールベースの記録）
プロンプトの変更履歴やコメントに、ルールだけを残してしまうケースです。
# 202X-XX-XX
プロンプトの末尾には必ず「ステップバイステップで検証してください」と記載すること。
移行当日、このコメントを見たエンジニアは「この一文、Opus 5でも残す？」という問いに直面します。判断材料がないため、「デグレが怖いから残す（＝負債化）」か「直感で消す（＝必要な対策の誤検知・削除）」の二択を迫られます。
✅ ベストプラクティス（課題ベースの記録）
私たちがMemoryLake（記憶層・ナレッジベース）で実践している書き方です。
# 課題管理表 / プロンプト調整記録
- **対象モデル:** 前世代モデル (v4)
- **課題:** 複雑なロジック生成時に、検証ステップをスキップしてハルシネーションを起こす事象が◯%発生。
- **対策:** プロンプト末尾に検証を促す指示文を追加し、精度を確保。（2026-05実装）
- **最小再現テストケース:** `tests/prompts/reproduce_skip_validation.json`
このように書いてあれば、移行時の問いは「この課題は、新モデル（Opus 5）でもまだ存在するか？」に変わります。
これならエンジニアとして検証可能です。新モデルで最小再現テストケースを回し、課題が解消されていれば対策（プロンプト）を削除。まだ存在していれば残すか、新世代に合わせて再調整します。「考古学」が「リグレッションテスト」へと変わる瞬間です。
移行作業を「勘の棚卸し」から「再テスト」へ
このアプローチをとることで、マイグレーション作業の形が明確になります。
- 記録された「課題リスト」を抽出する
- 各課題の最小再現ケースを新モデルで実行（テスト）する
- Pass（解消済）: 該当するプロンプトのハック（対策）を削除する
- Fail（未解消）: 対策を維持、または新モデル用にチューニングする
作業量が「なんとなく全プロンプトを読み直して調整する（工数不明）」から、「記録された課題数分のテストを実行する（工数見積もり可能）」へと劇的にスリム化されます。
そして、この再テストの結果（例: Opus 5ではこの課題は再現しなかったため対策を削除）が、さらに次世代モデルへ移行する際のベースライン（台帳）となっていきます。
まとめ
公式ガイドラインの「『検証して』を削除してください」という一文は、単なるプロンプトのTipsではありません。
「モデルと深く噛み合った巧みなハックは、その世代のなかでしか生きられない」という、LLMアーキテクチャの構造的な真理を突いています。
皆さんのリポジトリにも、誰が・いつ・何の目的で入れたのか分からない「おまじない」のようなプロンプトが眠っていないでしょうか？
次にプロンプトを調整するときは、新たなハックを闇雲に付け足すのではなく、その隣に「それがどんな課題を解決するためのものなのか」をコメントで一行残してみてください。
対策（プロンプトの小技）は次の世代の訪れとともに死を迎えますが、課題の記録はそれよりも長く生き残り、未来の移行作業で必ずあなたを助けてくれるはずです。