「システムプロンプト陳腐化」をどう防ぐか AWSの試行錯誤に見る「自社AIエージェント」運用のポイント：AI導入後に訪れる「挙動悪化」の課題をどう解消？

AWSは、AIコーディングエージェント「Kiro」のシステムプロンプトを継続的に評価する仕組みを公開した。社内の実利用データをLLMに採点させ、システムプロンプト変更の効果を比較しているという。

[＠IT]

　Amazon Web Services（AWS）は2026年8月25日、AIコーディングエージェント「Kiro」のシステムプロンプトを継続的に評価する取り組み事例を明らかにした。ベンチマークの結果と、社内の開発者による数千件のKiroとの会話を大規模言語モデル（LLM）で分析した結果を組み合わせ、タスク完遂や検証、ツール利用における改善機会を特定しているという。

「プロンプト陳腐化」　システムプロンプト評価における課題

　AIエージェントにおけるシステムプロンプトはモデル、ツール、コードベース、タスク、ユーザーのあらゆる組み合わせにまたがって動作する。そのため、事前に用意したどのようなテストスイートであっても全ての挙動を網羅的に検証することは困難とされる。

　単独で見れば妥当に思える指示が、作成者が想定していなかったケースで意図しない挙動を引き起こしたり、あるシナリオを改善する変更が別のシナリオを悪化させたりすることもある。

　「システムプロンプトの陳腐化」はその一例だ。基盤となるLLMの性能向上によって指示がより厳密に解釈されるようになると、旧モデル向けに調整されたプロンプトがかえって悪影響を及ぼすケースがある。

　新しいツールやワークフロー、ユーザーの利用パターンの変化によっても同じ潜在的な欠陥が表面化する。AWSは「ベンチマークは引き続き重要な品質のシグナルであるものの、日々の開発業務で現れる全ての挙動を捉えることはできない」と指摘している。

診断から評価までを回す4段階の改善サイクル

　AWSはこれらの課題に対し、社内開発者が利用するKiroにおいて、実会話データとLLMによる採点（LLMジャッジ）を組み合わせた評価フレームワークを導入している。

　数千件規模の会話セッションを自動分析し、タスク完遂率やツール利用の適切さを継続的にモニタリングする仕組みだ。

　プロンプトの評価手順は次の4段階で構成されている。

1. 診断：社内トラフィックにジャッジを実行して繰り返し現れる不満パターンを分類し、頻度の高いクラスタごとに原因となっているシステムプロンプトの指示や、不足している指示を特定する
2. 設計：安全性、検証、トーン、挙動のいずれかに対応する変更候補を、意図する挙動とリグレッションのリスクを明示した上で作成する
3. テスト：候補をコントロール（対照群）と、分離されたコホート（比較する集団）に割り当ててAB比較する
4. 評価：同一のルーブリック（評価基準表）を各コホートに適用し、不満率と挙動品質の問題の発生率から採用、修正、却下を判定する

　システムプロンプトやユーザーの挙動、モデルの能力が変化するたびに、このサイクルを繰り返し実行しているという。

システムプロンプト評価のサイクル（提供：Amazon Web Services）

15の観点で評価するLLMジャッジと2つの計測シグナル

　評価フレームワークの中核を成すLLMジャッジは、社内の会話セッションを15の挙動品質の観点でスコアリングする。これには以下のようなものが含まれる。

• タスクの完遂度
• 主張の正確性（Kiroは断定する前に結論を検証したかどうか）
• コードスタイルの順守
• 失敗し続けているアプローチの認識
• 破壊的アクションのフラグ付け
• ツール利用の適切さ
• 検証の挙動（テストの実行、コンパイルの確認）

　ジャッジは修正や不満、放棄されたタスク、確認といった会話からの明示的な証拠を必要とし、曖昧な会話はどちらの構成案にも不利に数えない。過剰な偽陽性の判定を避けるためだ。

　測定するシグナルは主に2つある。

　1つ目のシグナルは「明示的な不満」だ。ユーザーによる直接的なクレーム発言や会話の放棄、作業のやり直しなど、テキストに残された明示的なフィードバックのみから判定される。

　2つ目のシグナルは「挙動品質の問題」だ。コードを事前に読み込まずに結論を述べたり、プロジェクト既存のパターンを無視したりするといった、15の品質基準を満たさなかったケースをカウントする。

LLMジャッジが会話を読み取る仕組み（提供：Amazon Web Services）

AB比較で得られた成果と教訓

　システムプロンプトの変更を適用する際、AWSは社内開発者をハッシュ値によって機械的に割り振り、厳格なAB比較を行っている。過去の検証では、27個の変更候補を一括でスクリーニングし、悪影響を示した候補を即座に排除した。また、推論の度合い（Reasoning Effort）の設定評価にもこの仕組みが採用されており、レベルを高く設定することでデバッグなどのコード修正タスクにおいて顕著な改善が見られることを突き止めているという。

コホートごとに不満率と挙動問題の件数を出力するジャッジのパイプライン（提供：Amazon Web Services）

　最初に評価したモデルとシステムプロンプトの構成では、「Kiro CLI」で明示的な不満シグナルが5％、挙動品質の問題が32％、タスク完遂の問題が10.6％それぞれ減少した。「Kiro IDE」では挙動品質の問題が20％、タスクを未完了のまま返すケースが21％、失敗し続けているアプローチが36％、スタイルの不一致が54％減少している。

　高性能な新モデルへの更新後、プロンプト変更による挙動品質の改善幅は4％にとどまった。これはプロンプトの変更効果が落ちたわけではなく、新モデル自体が最初から高い解釈力を持っていたため、プロンプト側で改善できる余地が小さくなったことを意味する。

　一方で、新モデルは指示をより文字通りに捉える傾向が強まり、旧モデル向けに書いた過剰な制約がボトルネックになるケースも確認された。このためAWSでは、モデル更新を単なる差し替えとは捉えず、新しいモデルとプロンプトの組み合わせとして一から再チューニングしている。

自社でプロンプト評価をする際のポイント

　AWSは、自社でエージェントシステムを評価・運用するチームに向けた示唆も示している。

　1つ目は、標準的なベンチマークテストだけでなく、ユーザー固有のコンテキストや外部サービス連携といった本番環境のノイズを含んだデータで評価をする重要性だ。2つ目は、基盤モデルを刷新する際、既存プロンプトの単純な引き継ぎを避け、指示解釈の変化を踏まえた全件の再検証とチューニングを前提とすべき点だ。

　AWSは「プロンプトの改善においては不要になった指示を取り除くことが重要だ。行数制限の指定や旧バージョンのツール向けの回避策など、古くなった制約を廃止してプロンプトをシンプルに保つことが、モデルの挙動と整合させ続けるための有効な手法だ」と結論付けている。