問題はプロンプト債務

本記事はDrew Breunigのブログに掲載されたもので、著者の許可を得て転載しています。

自然言語インターフェースのおかげで、AIアプリケーションのプロトタイピングは驚くほど速くなりました。英語でやりたいことを書き、最先端モデルに渡せば、午後には動くプロトタイプが完成します。これは一発屋のタスクには極めて強力で最適です。しかし、信頼性のあるシステムを構築する方法としては、自然言語プロンプトは罠です。

プロトタイプを簡単にする平易な英語のプロンプトは、システムの動作を指定する方法としては貧弱であり、その代償は普通の進歩に偽装されてゆっくりと訪れ、アプリケーションがほとんど動かなくなるまで続きます。問題は個々のプロンプトではありません。自然言語がエンジニアリングの仕様言語として意図されたことがなく、それを仕様として扱うと構築できるものに静かに制限がかかることです。

プロンプト債務の罠

プロンプト債務の最初の症状は反復の鈍化です。ユーザーがエラーやエッジケースを報告するたびに、指示に追加のガイダンスを加えてモデルを矯正します。望ましくない動作が続けば、指示を繰り返し、語気を強めます。やがてプロンプトは簡潔でなくなり、クイックフィックスが以前の指示を破壊します。エラーは一行の「ホットフィックス」で処理できなくなり、開発サイクルは遅々として進みません。

例えば、Fableのシステムプロンプトは著作権ガイダンスを最大6回繰り返しており、search_instructions、search_usage_guidelines、mandatory_copyright_requirements、hard_limits、self_check_before_responding、critical_remindersというセクションに分散しています。

次に、プロンプト債務はチームを機能不全にします。エッジケースと大文字の脅威でいっぱいの脆いプロンプトはあなたにもほとんど読めず、同僚には完全に理解不能です。多くのチームはこの問題を緩和するために、プロンプトを実行時に組み立てる複雑なテンプレートに分割し、各テンプレートを特定の関心事に隔離します。しかし、これらのプロンプトセグメントも進化し、条件の藪に成長します。

最後に、プロンプト債務はあなたを単一のモデルに縛り付けます。GPT-4oで動作したホットフィックスは、推論呼び出しをGPT-5.4-miniに切り替えると全く新しい方法で失敗します。そのため、4oに留まり、推論プロバイダーからのますます頻繁になる非推奨メールが空の脅威であることを願い、より安く、より速く、より良いモデルの可能性を諦めます。Datadogの最近のレポートによれば、これは一般的な状況です。彼らが観測したトラフィックで最も使用されたモデルはGPT-4oでした。

これらの問題はどれも単独では厄介ですが、まとめると、飾られたプロトタイプと、あなた、顧客、ビジネスと共に成長できる製品との違いを生みます。あなたの輝く新しいAI機能は凍結され、完全な再構築によってのみ改善可能であり、古くなったモデルに固定されています。

プロンプト債務が発生する理由

自然言語インターフェースは素晴らしい。一発屋のタスクや広範な会話のスレッドには適切なメカニズムです。持続的なシステム動作を定義するために自然言語に依存するときに問題が発生します。

自然言語の不正確さと確率的言語モデルの組み合わせにより、同じ意図を表す異なる言葉が異なる出力を生む可能性があります。最近の研究では、患者の声で尋ねられた臨床質問を、同じ事実で医師の声で再質問すると、Opusが10回全て拒否から10回全て回答に変わりました。

言葉の選択だけが問題ではありません。同じプロンプト内の無関係と思われる文が結果に影響することがあります。ハーバードの研究では、ユーザーが応援するNFLチームを述べるだけで、モデルが敏感なトピックに関する質問を拒否する頻度が変わることがわかりました。無関係な記述が、予測不可能な方法で推論パスに影響を与えます。これが、修正を加えるほどプロンプトが脆くなる理由です。しつこいエラーを抑えるための追加指示が、昨日は機能していた別の指示の解釈に影響を与える可能性があります。

指示の繰り返しはプロンプト債務へと突き進ませますが、望む動作がモデルのトレーニングと相反する場合には必要です。これは「重みとの戦い」であり、一度認識するとシステムプロンプトの至る所で見られます。例えば、ChatGPTの画像プロンプトは、生成画像が返されたときに返信しないようLLMに8回指示していました。なぜなら、会話を続けるように訓練されていたからです。

私たちが分析したすべてのコーディングエージェントのシステムプロンプトには、繰り返しの指示、厳しい警告、大文字の要求が含まれていました。Claude CodeはOpusに、単一の応答で複数のツールコールを返すよう7回指示しています。そして最も先進的なモデルでさえ、プロンプト作成者に重みとの戦いを強います。Fableの流出したシステムプロンプトは、特定の著作権ルールを6回繰り返しています。

これらの例はどれも孤立していません。私たちが調査したシステムプロンプトには、複数の繰り返しルールが織り込まれています。しつこいエラーはプロンプトを急速に成長させ、編集のたびに脆さと後退のリスクが増大します。

さらに悪いことに、これらの修正は単一モデルの動作に合わせて調整されています。バークレー主導の最近の研究では、企業は新しいモデルが既存のエージェントを壊すため、古いモデルに留まることがわかりました。これは、モデルがきれいにバージョン管理されたソフトウェアではないためです。異なる重みが予測不可能で文書化されていない方法で異なる動作を生み出します。GPT-4oで美しく動作するプロンプトがGPT-5.5で失敗する可能性があります。Anthropic自身のFableリリースノートでは、以前のモデル用に開発されたスキルが「出力品質を低下させる」可能性があると警告しています。

プロンプト債務はアプリケーションを単一モデルに固定します。モデルを簡単に交換できないのは、フロンティアラボが巧妙な堀を考案した結果ではありません。いや、確率的モデルに対して損失の多い自然言語仕様を進化させた結果です。

プロンプト債務の予防

ありがたいことに、プロンプト債務を軽減する方法を理論化する必要はありません。一つの分野が既に道を示しています。コーディングエージェントを使用するプログラマーは、モデルができることの最先端に位置し、モデル能力のギザギザのフロンティアの外れ値です。過去数年、彼らはモデルにより多くのコードを書かせつつ、保守可能でモジュール化されたソフトウェアを提供するベストプラクティスを進化させてきました。

第一の原則は、システムの動作を散文ではなく測定値で指定することです。モデルの出力が確率的で言語が不正確な場合、私たちはハードエッジを構築して制約します：評価、メトリクス、型指定。これらは可読で共有可能な成果物であり、同僚が読んで貢献でき、脆いプロンプトが妨げていたコラボレーションを可能にします。

優れたエンジニアは現在、テストにより多くの帯域を費やしています。テストはもはや安全網ではなく、モデルが力を発揮するための手段だからです。

第二の原則は、プロンプトを手書きするのをやめることです。候補をスコアリングできるメトリクスがあれば、プロンプトは職人芸ではなく探索対象になります。自然言語が許容する潜在的な単語、フレーズ、構造の表面積は広大で、人間の時間を費やすには大きすぎます。これはLLMが探索するために作られた地形であり、すでにこの作業を管理してくれるシステム（DSPyやGEPAなど）が存在し、プロンプトをあなたの設計に責任あるものにします。

プロンプトが生成され、プログラムの動作が測定値で定義されれば、特定のモデルに縛られることはなくなります。新しいモデルの評価には数時間しかかかりません。より速く、より安いモデルが登場すれば試せます。非推奨メールが届けば、一日で代替オプションを確保できます。規制上の理由でモデルが引き揚げられても（AnthropicのFableで見られたように）、または老朽化で非推奨になっても（Groqが先週Llama-3.1-8bで発表したように）、修正は日常業務であり、緊急事態ではありません。

成熟したエンジニアリング分野はすべて、かつて手作業で行っていたことをいつかはやめます。アセンブリはコンパイラに取って代わられ、手動チューニングのクエリはプランナーに取って代わられ、手動メモリ管理は（ほとんど）それをより良く行う機械に取って代わられました。プロンプトライティングも同様です。

適切な言葉でモデルを巧みに導くことは本当のスキルであり、一発屋のタスクにはしばしば最適です。しかし、信頼性があり、改善可能で、移植可能なシステムを構築するには、プロンプトを手動でチューニングすべきではありません。

脚注：Datadogの統計は今年3月のものであり、GPT-4oの集中度はおそらく少し低下しています。しかし、複数の大規模推論プロバイダーから、GPT-4oおよび同程度の年代のモデルの使用が全呼び出しの50%以上に達することがあると聞いています。