AWSに学ぶ！AIエージェントの「プロンプト陳腐化」を防ぐ継続的改善サイクル
AIエージェントの「プロンプト陳腐化」とは？
AI開発・Web制作に携わる皆さん、AI導入後に「あれ？なんか挙動がおかしいな」と感じたことはありませんか？実はこれ、「システムプロンプトの陳腐化」という課題かもしれません。AWSがAIコーディングエージェント「Kiro」の運用で直面したこの問題は、AIエージェントを自社で運用する上で避けて通れないテーマです。
システムプロンプトは、AIエージェントがモデル、ツール、コードベース、タスク、ユーザーのあらゆる組み合わせにわたって適切に動作するための重要な指示書です。しかし、基盤となるLLMの性能向上や、新しいツール・ワークフロー、ユーザーの利用パターンの変化によって、プロンプトが古くなり、意図しない挙動を引き起こすことがあります。単独では妥当に見える指示が、特定のシナリオで悪影響を及ぼしたり、ある改善が別のシナリオを悪化させたりすることも珍しくありません。AWSは、「ベンチマークだけでは日々の開発業務で現れる全ての挙動を捉えることはできない」と指摘しています。
AWSの試行錯誤に見る「自社AIエージェント」運用のポイント
AWSは、この「プロンプト陳腐化」問題に対し、社内開発者が利用するKiroにおいて、実会話データとLLMによる採点（LLMジャッジ）を組み合わせた独自の評価フレームワークを導入しています。これは、数千件規模の会話セッションを自動分析し、タスク完遂率やツール利用の適切さを継続的にモニタリングする仕組みです。私たち開発者やWeb制作者が自社AIエージェントを運用する上で、非常に参考になるアプローチです。
診断から評価までを回す4段階の改善サイクル
AWSのプロンプト評価手順は、以下の4段階で構成されています。
- 診断: 社内トラフィックにジャッジを実行し、繰り返し現れる不満パターンを分類。原因となっているシステムプロンプトの指示や、不足している指示を特定します。
- 設計: 安全性、検証、トーン、挙動に対応する変更候補を作成。意図する挙動とリグレッションのリスクを明示します。
- テスト: 候補をコントロール（対照群）と、分離されたコホート（比較する集団）に割り当ててAB比較を行います。
- 評価: 同一のルーブリック（評価基準表）を各コホートに適用し、不満率と挙動品質の問題の発生率から採用、修正、却下を判定します。
このサイクルを、システムプロンプトやユーザーの挙動、モデルの能力が変化するたびに繰り返し実行することで、AIエージェントの品質を継続的に向上させています。
LLMジャッジと2つの計測シグナル
評価フレームワークの中核を成すLLMジャッジは、社内の会話セッションを15の挙動品質の観点でスコアリングします。これには、タスクの完遂度、主張の正確性、コードスタイルの順守、失敗し続けているアプローチの認識、破壊的アクションのフラグ付け、ツール利用の適切さ、検証の挙動などが含まれます。曖昧な会話はどちらの構成案にも不利に数えず、過剰な偽陽性の判定を避ける工夫がされています。
測定するシグナルは主に2つです。
- 明示的な不満: ユーザーによる直接的なクレーム発言や会話の放棄、作業のやり直しなど、テキストに残された明示的なフィードバックから判定されます。
- 挙動品質の問題: コードを事前に読み込まずに結論を述べたり、プロジェクト既存のパターンを無視したりするといった、15の品質基準を満たさなかったケースをカウントします。
AB比較で得られた成果と教訓
AWSは、システムプロンプトの変更を適用する際、社内開発者をハッシュ値によって機械的に割り振り、厳格なAB比較を行っています。過去の検証では、27個の変更候補を一括でスクリーニングし、悪影響を示した候補を即座に排除した実績があります。この仕組みにより、Kiro CLIでは明示的な不満シグナルが5％、挙動品質の問題が32％、タスク完遂の問題が10.6％それぞれ減少しました。Kiro IDEでは挙動品質の問題が20％、タスクを未完了のまま返すケースが21％、失敗し続けているアプローチが36％、スタイルの不一致が54％減少しています。
また、高性能な新モデルへの更新後、プロンプト変更による挙動品質の改善幅が4％にとどまったことも注目すべき点です。これは、プロンプトの変更効果が落ちたわけではなく、新モデル自体が最初から高い解釈力を持っていたため、プロンプト側で改善できる余地が小さくなったことを意味します。このことから、LLMの進化とプロンプトの最適化は常にセットで考えるべきだという教訓が得られます。
試すならどこから始めるか
自社でAIエージェントを運用している、あるいはこれから導入を検討している開発者・Web制作者の皆さんは、まずAWSのこの評価サイクルを参考に、小規模なプロンプトの継続的評価システムを構築してみるのが良いでしょう。特に以下の点から着手してみてはいかがでしょうか。
- 実利用データの収集: ユーザーとの会話ログやフィードバックを積極的に収集する仕組みを整えましょう。
- LLMジャッジの導入: 比較的小規模なタスクから、LLMに評価基準を与えてプロンプトの出力品質を採点させる試みを始めてみましょう。
- AB比較の実施: プロンプトの変更を行う際は、必ずAB比較を行い、変更前後の効果を客観的に評価する体制を構築しましょう。
この取り組みは、AIエージェントの性能を維持・向上させるだけでなく、ユーザーエクスペリエンスの改善にも直結します。AWSの事例を参考に、皆さんのAI開発・Web制作プロジェクトにも「継続的改善サイクル」を取り入れてみてください。
