技術的概要：PRISM – 反復シミュレーションと監視によるプロンプトの信頼性

1. 問題定義

エンタープライズ環境における大規模言語モデル（LLM）駆動の対話エージェントの導入は、既存のプロンプト最適化フレームワークが同時に解決できない、2 つの明確かつ重要な課題に直面しています。

1. 作成時の正しさ（Creation-Time Correctness）: エンタープライズエージェント向けのフロントエンドプロンプトの作成は、一般的なプロンプトエンジニアリングとは根本的に異なります。これらのエージェントは、認証、特定のツール呼び出し、条件付きルーティングなど、正確な多段階のビジネスロジックを逸脱することなく実行する必要があります。失敗モードは、事実誤認ではなく、しばしば手続き的なものとなります。具体的には以下の通りです。

   • ツール呼び出しのスキップ: 必要なワークフロー呼び出しの省略。
   • ルールの違反: 明示的な制約（内部状態の露呈など）の無視。
   • 手順の順序入れ替え: 手順の順序を誤って実行すること。
   • 手順の縮約: 中間手順をスキップして最終状態に到達すること。
     現在のフレームワーク（DSPy、OPRO、APE など）は、固定されたデータセットとターゲットを前提とした、一度きりのコンパイル時タスクとしてプロンプト最適化を扱っており、多ターンかつツール統合環境の動的な性質を無視しています。

2. ランタイムの行動ドリフト（Runtime Behavioral Drift）: 「ピン留め」された LLM バージョンでさえ、サンプリングのばらつき、温度設定、またはプロバイダレベルでの非公開の推論層の変更により、時間とともに非決定的な行動ドリフトを示します。起動時に正しく動作したプロンプトでも、数日または数週間で静かに劣化し、体系的な監視なしでは検出が困難な本番環境での回帰を引き起こす可能性があります。既存の文献は、エンドユーザーに影響を与える前にこのドリフトを検出・修復するというメンテナンス問題の多くを無視しています。

2. 手法：PRISM フレームワーク

PRISM（Prompt Reliability via Iterative Simulation and Monitoring）は、プロンプトエンジニアリングを継続的な信頼性エンジニアリングの問題として扱う、閉ループ型のフレームワークです。これは 5 つの機能段階を通じて動作します。

段階 1：要件駆動型テスト生成

PRISM は、自然言語のビジネス要件、戻り値スキーマを備えた一連の構成済みツール、メモリ変数、および初期ドラフトプロンプトを受け入れます。LLM は、以下の要素を含む構造化されたテストスイート（$Q$）を生成します。

• 会話スクリプト: 現実的な多ターン対話シナリオ。
• 合格基準: 客観的に検証可能なアサーション（例：「エージェントはキャンセル理由を尋ねる前に getProductDetails を呼び出す」）。
• モックオーバーライド: 特定の条件分岐に合わせて調整された、ツール名からモック戻り値へのマッピング。これにより、ライブワークフローを実行することなく決定的なテストが可能になります。
  ジェネレーターは、ハッピーパス、境界条件、エラーパス、およびコンプライアンスケースを網羅します。

段階 2：プラットフォーム忠実なシミュレーション

このフレームワークは、ライブボットに触れることなく、本番環境（具体的には Yellow.ai V3 の 2 層プロンプトアーキテクチャ）をシミュレートします。

• システムプロンプト（$P = P_b \oplus P_f$）を構築し、会話スクリプトをターンごとに再生します。
• LLM のツール呼び出しを傍受し、モック応答に置換します。
• ボットテキスト内の特定のマーカーを介してルーティングイベントを検出します。
• ツール呼び出しやルーティングの決定を含む完全なトランスクリプトを記録し、シミュレーションが決定的であることを保証します（評価時は温度を 0 に設定）。

段階 3：LLM によるジャッジ評価

ジャッジ LLM（GPT-4.1）は、定義された合格基準に基づいて、各シミュレーショントランスクリプトを評価します。

• ジャッジは、テキストから意図を推測するのではなく、ツール呼び出しログを検証するなど、厳格で客観的な評価を行います。
• 各基準に対して、理由付きの構造化された判定（PASS/FAIL）を返します。
• すべての基準が満たされた場合にのみ、テストは合格となります。

段階 4：診断と外科的修復

テストが失敗した場合、PRISM は完全な書き換えではなく、標的を絞った修復メカニズムを採用します。

• 診断: LLM が失敗トランスクリプト、判定、およびプラットフォームガイドを分析し、根本原因とプロンプトの特定のセクションを特定します。
• 修復: LLM は、観察された失敗の原因となったセクションのみを変更し、他のテストを合格させるロジックを保持する新しいプロンプト（$P^{(k+1)}_f$）を生成します。この「外科的」アプローチは、完全な書き換え戦略で見られる振動を防ぎます。
• このループは、すべてのテストが合格するか、最大反復回数に達するまで繰り返されます。

段階 5：継続的監視

プロンプトが検証されると、それがデプロイされます。PRISM は、スケジュールに基づき（毎日）、本番プロンプトに対して完全なテストスイートを実行します。

• 以前合格したテストが失敗した場合、PRISM はこれを行動ドリフト事象として識別します。
• 自動的に修復ループに再進入し、パッチ適用済みプロンプトを生成し、24 時間以内にオペレータのレビューに提示します。

3. 主要な貢献

本論文は、5 つの主要な貢献を主張しています。

1. 2 段階の問題定式化: 作成時の正しさとランタイムの信頼性を区別し、統一されたフレームワーク内で両方に対応すること。
2. 要件駆動型テスト生成: 自然言語の要件から直接、実行可能な多ターンテストケースとモック応答を導き出す手法。
3. プラットフォーム忠実なシミュレーション: 決定的で再現性のあるテストのために、本番プロンプトアーキテクチャとツール相互作用を再現する環境。
4. 外科的修復メカニズム: 失敗トランスクリプトに基づき、失敗したプロンプトセクションのみを変更し、合格した行動を保持する修復戦略。
5. 継続的監視プロトコル: 24 時間以内に LLM の行動ドリフトを検出・修復するように設計された、毎日の回帰テストシステム。

4. 実験結果

PRISM は、3 週間の期間にわたり、Yellow.ai V3 プラットフォーム上の35 社のエンタープライズ対話エージェントで評価されました。

• 作成効率: PRISM は、プロンプト作成の中央値時間を、手動ベースラインの2.1 日から27 分に削減しました（約 98% の削減）。これは主に自動テスト生成とシミュレーションによって実現されました。
• 本番信頼性: このフレームワークは、99.0% の本番信頼性率を達成しました。735 回の毎日の回帰実行のうち、728 回でゼロの失敗が見つかりました。
• ドリフト検出: PRISM は、4 つのエージェント間で7 つの行動ドリフト事象を正常に特定しました。すべてが 24 時間の検出ウィンドウ内で修復されました。
• 収束: テストスイートが 60 件未満のエージェントの場合、PRISM は平均 4.2 回の反復で 100% のテスト合格を達成しました。より大規模なスイートの場合、拡張反復により 89% のケースで収束が達成されました。
• 失敗分析: 初期の未最適化プロンプトは、主に「ツール呼び出しのスキップ（34%）」と「手順の縮約（28%）」に苦しんでおり、エンタープライズエージェントにおける手続き的コンプライアンスが支配的な失敗モードであることを確認しました。

5. 意義と主張

本論文は、エンタープライズ対話 AI における信頼性のギャップは、主にモデルの能力の限界ではなく、プロンプトエンジニアリングにおける手法のギャップであると仮説を立てています。現在の慣行には、多段階のエージェントの行動を検証、監視、維持するための体系的なツールが欠けています。

PRISM は以下を実証しています。

• 継続的でシミュレーション駆動型のプロンプト最適化は、スケーリングにとって実行可能かつ必要である。
• LLM の行動ドリフトを第一級の信頼性課題として扱い、自動ループを通じて検出・修復することは可能である。
• 複雑な多ターンエージェントの安定性を維持する上で、「外科的」修復は完全な書き換えよりも優れている。

著者らは、PRISM が初期プロンプト作成と継続的な本番メンテナンスの両方に対する統一された解決策を提供し、関数呼び出しとプロンプトルーティングをサポートする他のプラットフォームに適応可能な、信頼性の高いエンタープライズ AI の基盤を提供すると結論付けています。このフレームワークは、継続的なプロンプト信頼性に関するさらなる研究を促進するために、オープンソースツールとしてリリースされています。