継続的なプロンプト評価: LLM ジャッジとライブシグナルを使って Kiro エージェントの品質を高める方法

本記事は「Continuous Prompt Evaluation: How We Use LLM Judges and Live Signals to Improve Kiro Agent Quality」を翻訳したものです。

課題: システムプロンプトの挙動は予測が難しい

プロンプトの挙動を網羅的に検証するのは困難です。システムプロンプトは、モデル・ツール・コードベース・タスク・ユーザーのあらゆる組み合わせにまたがって動作しますが、どんなテストスイートでもそれをすべてカバーすることはできません。単独で見れば妥当に思える指示が、プロンプトの作成者が想定していなかったケースで意図しない挙動を引き起こすことがあります。また、あるシナリオを改善する変更が、別のシナリオを悪化させることもあります。

プロンプトの陳腐化（staleness）は、この広範な問題の一例にすぎません。ある指示は、すでにまれで観測しにくい問題を引き起こしているかもしれませんが、新しいモデルがその指示をより厳密に守るようになると、より明確に有害なものになります。新しいツール、ワークフロー、ユーザーの利用パターンも、同じ潜在的な欠陥を表面化させることがあります。

ベンチマークは引き続き重要な品質シグナルですが、日々の開発業務で現れるすべての挙動を捉えることはできません。私たちに必要だったのは、実際のワークフロー上で問題を検出し、繰り返し現れるパターンを分類し、それをプロンプトの指示までたどり、モデルや利用状況の変化に合わせて修正を検証する仕組みでした。

システムの全体像

本記事は、人手で作成されたシステムプロンプトや設定の変更を評価することに焦点を当てています。自動的なトラジェクトリマイニング、変更の自動生成、ハーネス全体の自己改善については扱いません。このワークフローは、ベンチマーク結果と、社内の開発者による数千件の Kiro との会話を LLM で分析した結果を組み合わせ、タスク完遂・検証・ツール利用における改善機会を特定します。以下の 4 つのステージからなります。

診断（Diagnose）: 頻度の高い不満カテゴリを特定し、それをプロンプトの指示までたどる
設計（Design）: 分離して評価できるよう、狙いを絞ったプロンプト変更を設計する
テスト（Test）: 社内トラフィック上で、統制されたコホートに対して変更をテストする
評価（Evaluate）: 各コホートを LLM ジャッジで評価し、不満や挙動品質の問題の変化を測る

図 1: プロンプト評価の 4 ステージのサイクル。プロンプト・ユーザーの挙動・モデルの能力が変化するのに合わせて繰り返す。

4 ステージのプロンプト評価サイクル

上の図は、以下で説明する 4 つのステージをまとめたものです。プロンプト・ユーザーの挙動・モデルの能力が変化するたびに、このサイクルを繰り返します。

1. 診断（Diagnose）。 現在の社内トラフィックにジャッジを実行し、繰り返し現れる不満パターンを特定・分類します。そのうえで、頻度の高いクラスタごとに、原因となっているプロンプトの指示や、欠けている指示までたどります。たとえば、繰り返し現れる「タスクが未完了」という不満は、エージェントに対して計画を実行するのではなく説明するよう促していたガイダンスに起因していました。

2. 設計（Design）。 診断された問題に対して、狙いを絞った変更候補を作成します。候補は多くの場合、安全性・検証・トーン・挙動のいずれかに対応するもので、各候補はテスト前に、意図する挙動とリグレッションのリスクを明示します。

3. テスト（Test）。 候補をコントロール（対照群）と、分離したコホートで比較します。有用な場合には、相互作用が見えてくる可能性のある「候補を組み合わせたコホート」でも比較します。実験の設計とサンプルサイズによって、その結果が方向性を示すだけのものか、より広い結論を支持できるものかが決まります。

4. 評価（Evaluate）。 同一の LLM ジャッジのルーブリックを各コホートに適用し、不満率と挙動品質の問題の発生率を比較します。得られた証拠にもとづいて、各候補を採用（ship）・修正（revise）・却下（reject）します。

LLM-as-judge: 重要なものを測る

私たちは、社内の会話を 15 の挙動ディメンションでスコアリングする評価フレームワークを構築しました。たとえば以下のようなものです。

タスクの完遂度（Task completeness）
主張の正確性（Claim accuracy）（エージェントは断定する前に検証したか？）
コードスタイルの遵守（Code style adherence）
失敗し続けているアプローチの認識（Recognition of repeated unsuccessful approaches）
破壊的アクションのフラグ付け（Destructive-action flagging）
ツール利用の適切さ（Tool use appropriateness）
検証の挙動（Verification behavior）（テストの実行、コンパイルの確認）

このジャッジは、会話からの明示的な証拠を必要とします。すなわち、修正・不満・放棄されたタスク・確認などです。曖昧な会話はどちらのバリアントにも不利に数えないことで、比較の一貫性を保ち、過剰な偽陽性（false positive）の判定を避けるために保守的な設計にしています。

図 2: LLM ジャッジが会話を読み取る仕組み。左にチャットのやり取り、中央に不満の判定基準、右に分類された挙動品質の出力が並ぶ。

図中に示したジャッジのプロンプトは、あくまで最小限の説明用の例であり、実際の評価で使われているものではありません。

ジャッジは主に 2 つのシグナルを測定します。

明示的な不満（Explicit dissatisfaction）: ユーザーは明確に不満を表明したか、会話を放棄したか、あるいはエージェントの作業をやり直したか？これは会話中の明示的なフィードバックからのみ推定され、ツールの結果が示唆するものやアンケートのスコアからは推定しません。
挙動品質の問題（Behavioral quality issues）: エージェントは 15 の品質基準のいずれかを満たさなかったか？例としては、コードを先に読まずに主張する、タスクを完遂する前に止まる、プロジェクトの既存パターンを無視する、などがあります。

両方のメトリクスは、コントロール群とトリートメント群で同一のルーブリックを用いるため、同じ評価設計の中で構成どうしを一貫して比較できます。

図 3: 会話はストレージからコホートごとのバケットを経て不満ジャッジへ流れ、ジャッジはコホートごとの不満率と挙動問題の件数を出力する。

A/B 実験のインフラ

プロンプトの変更をリリースする前に、社内トラフィック上で構成どうしを別々のコホートで比較します。これらの実験では、サービスが、対象となる社内開発者を、ユーザー識別子の決定的なハッシュを使って安定的なユーザーバケットに割り当てます。この割り当ては、観測された会話の結果とは独立しています。各バケットは、ある実験において 1 つのプロンプトバリアントに対応します。

ジャッジのパイプラインは、記録された実験の割り当てにもとづいて会話を分析し、すべてのコホートに同一のルーブリックを適用します。安定的な割り当てはプロンプト実験内のコホート選択を統制しますが、ライブトラフィックにおけるすべてのバイアスや相互作用の要因を取り除くわけではありません。正確な割り当てとサンプルサイズは実験ごとに異なるため、結論の強さはその比較で得られた証拠に依存します。分離された小さな候補コホートは、本番への影響を精密に推定するものというより、方向性を示す診断（directional diagnostics）にとどまります。

ある迅速に進めた社内デプロイでは、安全性・検証・トーン・挙動の 4 カテゴリにわたる 27 個のプロンプト変更候補をスクリーニングしました。安定したコントロールを、分離した候補コホートと、候補を組み合わせたコホートと比較しました。小さな分離コホートは、起こりうるリグレッションを局在化させるための方向性の診断であって、個別に影響を推定できるだけの検出力を持つものではありませんでした。悪化を示した候補は修正または削除し、組み合わせたコホートや、より大規模な追試の比較によって、より広い結論を支持しました。

ジャッジのパイプラインは会話の結果をスコアリングするため、ユーザーから見える設定の選択肢どうしを比較することもできます。私たちはこれを使って、デフォルトの reasoning effort レベルを評価しました。コード修正やデバッグといった一般的なタスクでは、より高い effort レベルで改善が見られました。reasoning effort レベルの設定について詳しくは、reasoning effort のドキュメントを参照してください。

直近サイクルの結果

以下の数値は、社内の実験レベルの比較で観測されたデルタ（差分）です。これらは今回の評価サンプルを説明するものであり、普遍的な本番効果の推定値として読むべきではありません。

初回のモデル＆プロンプト実験

Kiro CLI（最初に評価したモデル＆プロンプト構成）:

明示的な不満シグナル: 5% 減少
挙動品質の問題: 32% 減少
タスク完遂の問題: 10.6% 減少

Kiro IDE（最初に評価したモデル＆プロンプト構成）:

挙動品質の問題: 20% 減少
タスクの未完了配信: 21% 減少
失敗し続けているアプローチ: 36% 減少
スタイルの不一致: 54% 減少

より新しいモデルでの再検証

再検証は、初回の実験とは別の問いに答えるものです。初回の実験は、最初に評価したモデル＆プロンプト構成に対するプロンプト変更の効果を測りました。再検証は、モデルをアップグレードした後でも同じ変更が依然として役立つかどうかをテストします。

より新しいモデル＆プロンプトのベースラインは、同じルーブリック (評価基準表) のもとですでに挙動品質の問題が少なく、プロンプトが上乗せできる余地（headroom）が小さくなっていました。したがってここでの改善幅が初回サイクルより小さいのは設計上の想定どおりであり、リグレッションではありません。その難しいベースラインに対してさえ、同じプロンプト変更は依然として両方のシグナルを正しい方向へ動かしました。挙動品質の問題をさらに 4% 減らし、明示的な不満を 2.6 パーセントポイント改善しました。私たちはこの結果を、モデルアップグレード後も変更が依然として役立つという方向性の確認であって、精密な本番推定値ではない、と読んでいます。

より新しいモデルは、一部の指示をより文字どおりに守るようにもなりました。特に低い effort レベルでその傾向が顕著で、以前のモデル向けにチューニングされたガイダンスが、あらゆるケースでそのままきれいに引き継がれるわけではありませんでした。そこで私たちは、モデルアップグレードのたびにそれを新しいモデル＆プロンプト構成として扱います。既知の不満ケースを再現し、過去にうまくいったケースをリグレッションチェックとして使い、挙動品質・不満・リグレッション・効率を測定し、ロールアウト前に再チューニングします。

自前のエージェントシステムを評価するチームへの示唆

ライブ利用の評価はベンチマークを補完する。 標準的なベンチマークは引き続き有用です。社内フィードバックは、実際のユーザーセッションからシステムプロンプト改善の機会を明らかにします。そうしたセッションには、標準的なベンチマークが同時には捉えないディメンションがしばしば含まれます。たとえば、ユーザー固有のワークスペースのコンテキスト、実際の本番サービスとのやり取り、別々の作業セッションをまたいで再開される会話、その他の現実世界のノイズなどです。

方向性のスクリーニングには分離コホートを使う。 小さな候補コホートはリグレッションの局在化に役立ちますが、より広い結論を導く前には、組み合わせたコホートと、十分な検出力を持つ追試の比較が必要です。

プロンプトの効果はモデル依存である。 同じ変更が、あるモデルバージョンでは挙動品質の問題を 32% 減らし、別のバージョンでは 4% 減らしました。モデルをアップグレードするたびに再検証のパスが必要です。

不要になったガイダンスは廃止する。 最も大きな改善のいくつかは、古くなった制約を取り除くことから生まれます。行数の上限や、非推奨になったツールの回避策などです。プロンプトはシンプルなほうが、モデルの挙動と整合させ続けるのが容易になります。

これが Kiro ユーザーにとって意味すること

これらの変更によって、Kiro はタスク全体を完遂し、うまくいっていないアプローチを軌道修正し、プロジェクトの既存のコードスタイルに従う可能性が高くなります。また、次に進む前に変更がコンパイルできてテストが通ることを検証し、リスクのあるアクションの前には確認を取りつつ、安全な作業はそのまま進めるようにもなります。私たちはこのプロンプト評価を、プロンプトとモデルが変化するたびに繰り返し行い、デプロイ前に更新を検証しています。

Amazon Web Services ブログ