シナリオ設計
ページをコピー
プロダクトのユースケースを、文脈・ツール仕様・測定可能な成功基準を持つタスクに落とし込みます。
シナリオは、プロンプトだけでは決まらない
まず、お客様のユーザーがエージェントに任せたいタスクを選びます。成功の条件を先に決めておくことで、プロダクトを正しく使えたか、どの使用例や説明を補うべきかを判断できます。
有用なシミュレーションケースには、ユーザーの依頼と、評価器が成功をどう判定するかの両方が必要です。FloviaのPromptCaseは、自然言語のタスクと、対象プロバイダー、許可するツール計画、引数の意味的な期待値、必要な事実、回答基準を結び付けます。
意図、言語、難易度、ペルソナ、プロンプトファミリーといった属性により、どのタスクが、どのような利用者の条件で失敗したかを分析できます。ペルソナはシナリオ上の文脈であり、実測した人間のユーザー集団を再現するものではありません。
| 層 | 定義する内容 |
|---|---|
| ユーザーのタスク | 具体的な情報要求、制約、ユーザーが指定する識別子 |
| 候補の提示条件 | 候補を与えるかどうか、候補のメタデータと順序 |
| ツール仕様 | 許可する操作、入力スキーマ、引数の意味的な期待値 |
| 結果の仕様 | 必要なフィールド、型、該当する場合は期待値 |
| 完了の評価基準 | 最終回答が満たすべき事実と制約 |
ペルソナと目的をシナリオ行列で比較する
現行の診断分析には、ペルソナ×目的の全要因計画が含まれます。定義した3つのペルソナと5つの目的を掛け合わせた15セルを対象に、モデル別の結果を保持したまま、同じ目的の中でペルソナを比較し、その差を集計します。これは特定の診断経路の設計で、PromptCaseのファネル実行はそれぞれに定義した設計を使います。
この構造により、選択の傾向が一つのユースケースに集中するか、複数の文脈に共通するかを調べられます。探索的な比較から、次に再検証するオンボーディングの使用例やドキュメントの変更案を選べます。
例：指定日の為替レートを取得する
架空の為替レートAPIを例にします。ユーザーは、特定の日付のEUR→USDレートを知りたいとします。このケースでは、エージェントが過去データの操作を選び、基準通貨と相手通貨を正しく指定し、結果と整合する回答を返すかを検証します。
タスク：2026-01-15のEURからUSDへの為替レートを取得する
許可する操作：get_historical_rate
引数：base=EUR, quote=USD, date=2026-01-15
必須の結果：base, quote, date, rate
完了基準：返されたレート、通貨の方向、日付を回答する
環境：実際のモデル呼び出し＋準備済みのツール応答ユーザーの依頼には、引数を導くのに必要な情報を含めます。評価器側の期待回答は、エージェントに与えるタスクとは分けて管理します。最新レートの操作を呼び出したモデルは、最終回答の文章がもっともらしくても、Tool Resolutionで失敗になり得ます。
改善につながる失敗を見つける設計
- プロダクトが対応できる、具体的な対象適合タスクを含めます。
- 競合の方が適切なタスクや負の対照を含め、常に自社プロダクトを選ぶ動作を良い結果と取り違えないようにします。
- 操作、対象エンティティ、日付範囲、言語、曖昧さ、ユーザーの文脈など、意味のある次元でタスクを変化させます。
- プロンプトファミリーと反復を使い、表現の違いへの感度と、同じ依頼に対する一貫性を分けて見ます。
- 選択だけを評価する対照ケースと、実行ファネル全体の評価対象になるタスクを分けます。
反復を増やすと、既存タスクでの動作のばらつきをより詳しく見られます。シナリオの範囲を広げると、別の問い、つまり結果がより多くのユースケースで成り立つかに答えられます。レポートでは、この二つを区別して示します。
実行前に比較条件を固定する
評価計画には、タスク集合、モデル設定、候補の提示条件、実行経路、反復、採点規則、測定期間を記録します。変更の効果を調べる場合は、変更を許可するフィールドも明示します。これにより、試してみたい案を、条件が定義された実験に変えます。