第2章 要件と成功基準

学習目標

• 「うまく機能する」という曖昧な要求を、データ、指標、基準値、測定方法を備えた判定可能な成功基準へと変換します。
• 正確度だけでなく、一貫性、トーン、個人情報の取り扱い、レイテンシ、コストといった多角的な基準を併せて策定します。
• 機能が受け取る入力と返す出力を入力・出力契約として定義し、想定外の入力や形式エラーに対する処理ルールを定めます。
• 品質とレイテンシ・コストのバランスを取る設計の選択肢（モデル、出力長、ストリーミング、バッチ処理）を選択します。
• ユーザーに見える失敗体験を要件として記述し、リリース遮断基準と改善目標を区別します。

はじめに

ある企画書の要件欄に、次のように書かれていました。「AIによる要約は正確かつ自然で、迅速に応答しなければならない。」リリースの1か月前、開発チームは「正確度91%なら正確と言えますか？」と尋ね、営業チームは「クライアント企業が求めているのは99%です」と言い、デザイナーは「迅速とは何秒のことですか？」と尋ねました。誰も間違っていません。要件が判定不可能な言葉で書かれていただけなのです。

AI機能は確率的に動作するため、「間違えない」と約束することはできません。その代わりに、「このデータにおいて、この方法で測定したとき、この割合以上」という約束をします。Claudeのドキュメントでは、成功するLLMアプリケーションは成功基準を明確に定義することから始まり、その基準を測定する評価を設計するサイクルが核心であると説明されています。本章では、そのサイクルの前段階、すなわち何をもって成功とみなすかを決める作業を扱います。

まず、判定可能な基準の条件と多様な側面を学び、曖昧な要求を数値へと変換する手順を練習します。次に、入力・出力契約と品質・レイテンシ・コストのバランスを扱い、ユーザーに見える失敗体験を要件として記述する方法を確認します。最後に、すべての基準をリリース遮断基準と改善目標に分類し、1枚の要件定義書としてまとめます。

重要な概念

AI機能の要件は何が異なるのか

既存の機能における要件は、「ボタンを押すと決済画面へ遷移する」のように真偽が明確です。一方、AI機能の要件は、「問い合わせのタイプを当てる」のように大半は正しく一部は間違っているという性質を持ちます。そのため、AIの要件にはさらに3つの要素が必要です。

1. 割合で書かれた基準。 「当てる」ではなく「1,000件の評価セットで95%以上当てる」。
2. 測定方法。 誰が、何と照らし合わせて、どのように判定するのか。
3. 間違えたときの約束。 間違えた5%がユーザーにどのように表示され、どのように処理されるのか。

例えるなら、既存の要件が設計図であるのに対し、AIの要件は品質検査の規格書に近いと言えます。工場は不良品をゼロにはできないため、不良率の上限と検査方法、不良品の処理手順をあらかじめ定めておきます。

判定可能な成功基準

Claudeのドキュメントでは、優れた成功基準の条件として4つを挙げています。具体的であり（specific）、測定可能であり（measurable）、達成可能であり（achievable）、目的に関連している（relevant）必要があります。「優れた性能」の代わりに「正確な感情分類」のように具体的に記述し、数値や明確に定義された尺度で測定し、業界標準、過去の実験結果、専門知識に基づいて目標を設定し、ユーザーのニーズと合致していなければなりません。

同ドキュメントの例が、その違いをよく示しています。

優れた基準には、4つの要素が必ず含まれます。何を（指標）、どこで（データ）、どれくらい（基準値）、どのように（測定方法）。1つでも欠けると、会議で数値を巡って再び議論が紛糾することになります。ここに、何と比較した数値なのか（ベースライン）を併記すれば、基準値がなぜその数値なのかまで説明できます。上記の表の感情分類の例が、ベースライン（現在より5%改善）まで備えた形です。

成功基準のさまざまな次元

Claudeのドキュメントでは、大半の機能は複数の成功基準で評価すべきであると述べられており、一般的な次元として次が挙げられています。

正確度だけを基準にすると、他の次元での失敗を見逃してしまいます。正確度を上げようとして大きなモデルを採用するとレイテンシとコストが悪化し、回答を長く書かせると関連性が低下することがあります。次元ごとに個別の基準を設けてこそ、何をトレードオフにしているのかが見えてきます。

適合率と再現率

何かを「検知する」機能（不正の疑い、スパム、緊急リクエストの検知など）では、正確度よりも適合率と再現率が重要になります。Google PAIRガイドの定義によれば、適合率は陽性と判定したもののうち実際に陽性である割合であり、再現率は実際の陽性のうち陽性として検知できた割合です。

PAIRガイドは、偽陽性と偽陰性のコストを比較検討することはユーザー体験を左右する決定であり、両者を機械的に同じ比重で扱おうとする姿勢を戒めています。この2つの指標を同時に高めることは難しいため、機能ごとにどちらを死守すべきかを要件に明記しなければなりません。両者を1つにまとめて確認したいときに用いる指標が、F1スコア（適合率と再現率の調和平均）です。

曖昧な要求を基準へと変換する手順

「要約が意図を適切に捉えていなければならない」といった要求を受けた場合、次の手順で変換します。

1. 意味を分解する。 「意図」とは解決の約束なのか、次のアクションなのか、語り口なのかを、要求元と一緒に分類する。
2. 観察可能な行動へと変換する。 「次のアクション（誰が、いつ、何を）が要約に漏れなく含まれている」。
3. 測定方法を定める。 正解が存在する場合は突き合わせ（コード）、判断が必要な場合はルーブリック（項目別の判定基準と評語・評価尺度を定めた採点基準表）と採点者（人間、または人間とすり合わせたLLM採点機）。
4. データを定める。 実際のログから抽出した評価セットの規模と構成。
5. ベースラインと基準値を定める。 現在の水準（ベースライン）を測定し、その根拠を確認したうえで達成可能な基準値を設定する。

Claudeのドキュメントでは、倫理や安全性のような「曖昧な」テーマであっても数値化が可能であり、定性的な尺度であっても定量的な指標と併せて一貫して運用すれば価値があると説明されています。変換のプロセスにおいて、要求元と合意を形成することが数値そのものよりも重要です。

入力契約

入力契約とは、機能が何を受け取るのかを定めた取り決めです。言語、ファイル形式、長さ、必須情報、受け取らない情報を記述します。入力契約が存在しないと、機能は検証されていない入力まで処理してしまい、結果が悪くてもユーザーはその理由が分かりません。

形式や長さのようにモデルへ送信する前に検証できる範囲もあれば、「サポート対象外の業務に関する質問」のように内容を読まなければ分からない範囲もあります。前者は事前バリデーションで、後者は意図分類やモデルの判断で選別して所定の案内ルートへ誘導し、その判定も評価セットで確認します。入力の範囲は、評価によって検証された範囲と一致していなければなりません。評価していない言語や長さをサポートするには、その入力を評価セットに追加して基準をクリアしてから範囲を広げます。Google PAIRガイドは、エラー状態を活用して、AIがどのような入力を必要としているかをユーザーに知らせることを推奨しています。

出力契約

出力契約とは、機能が何をどのような形式で返すのかを定めた取り決めです。人間が読む画面であれば長さや構成、他のシステムが受け取って利用する結果であればフィールド、データ形式、空の値の処理方法を記述します。

他のシステムに渡す出力は、特に厳格でなければなりません。Claudeのドキュメントでは、構造化出力（structured outputs）が制約付きデコーディング（スキーマに適合するトークンのみが生成されるよう制御する方式）によって、大半のケースでJSONスキーマに準拠した応答を保証すると説明されています。ただし、拒絶（stop_reasonがrefusal）された場合や出力長の上限（max_tokens）に達した場合には、出力がスキーマと一致しないことがあり、文字列の列挙値（enum、const）の大文字・小文字は保証されないため、エラーなく正常終了した応答であっても大文字・小文字だけが異なる値が出力される可能性があると明記されています。そのため、列挙値は大文字・小文字を区別せずに比較し、大文字・小文字の違いしかない値を別々に定義することは避けます。したがって出力契約には、スキーマとともに「検証に失敗した結果は使用せず、再処理するか人間へエスカレーションする」というルールを定めます。

[出力契約の例]
形式: JSON {"item": 文字列, "quantity": 整数, "unit_price": 整数}
空の値: 読み取れないフィールドはnullとし、推測で埋めない
検証: スキーマ検証失敗、拒絶、長さ制限到達 → 下位システムへ渡さず再処理キューへ
失敗通知: 再処理キューが1時間に20件を超えた場合は担当者へ通知

正確度が高くても、形式が崩れていれば下位システムはダウンしてしまいます。正確度と形式は、全く別の要件です。

品質・レイテンシ・コストのバランス

品質、レイテンシ、コストはトレードオフの関係にありますが、調整レバーは複数存在します。Claudeのドキュメントでは、まず制約を設けずに適切に動作する構成を見つけたうえで、レイテンシを削減していくアプローチを推奨しています。過度に早い段階でレイテンシを削ろうとすると、達成可能な最高性能がどこにあるのかが分からなくなるためです。

レイテンシを測定する際は、応答全体が完了するまでの時間と、最初のトークンが出力されるまでの時間（TTFT、Time To First Token）を区別します。ユーザーが画面の前で待機する機能ではTTFTが、他のシステムへ結果を受け渡す機能では全体の時間が重要となります。コストは「1件あたりのコスト × 月間処理量」として記述し、予算と比較します。

ユーザーに見える失敗体験

AI機能は一定の割合で失敗します。その瞬間にユーザーが何を目にするかが要件となります。Google PAIRガイドは、ユーザーが認識するエラーはシステムに対する期待と深く結びついていると述べており、エラーをシステム限界、コンテキストエラー、バックグラウンドエラーに分類しています。そして、失敗後にユーザーができる行動に焦点を当て、失敗した際にはユーザーが作業を引き継げるようにすることを推奨しています。

ストリーミングを使用する場合、応答の途中でも失敗が発生します。Claudeのドキュメントでは、ストリーミング応答においては正常な応答（200）が開始された後であってもエラーが発生する可能性があると説明されています。そのため、「途中まで生成された回答」をどのように表示するかも要件に含めます。「回答できません」とだけ表示する画面は、誤答の割合にはカウントされませんが、ユーザーの作業を完全に止めてしまいます。利用ログから失敗画面の次の行動（離脱、再試行、電話での問い合わせなど）を併せて確認することで、失敗体験に伴うコストが浮き彫りになります。

リリース遮断基準と改善目標

すべての基準が同等の重みを持つわけではありません。リリース遮断基準は、それを満たせなければ他の指標がどれほど優れていてもリリースしない基準であり、改善目標はリリース後に引き上げていく水準です。

遮断基準が多すぎるとリリースは延々と先送りになり、少なすぎるとインシデントが発生します。NIST AI RMFは、組織のリスク許容度を定めて記録するよう求めています（MAP 1.5）。遮断基準とは、その許容度を数値に落とし込んだものです。また、もう1つの選択肢もあります。特定の類型のみが基準に満たず、その類型を人間へエスカレーションする経路が存在する場合、その類型を対象範囲から除外する条件付きリリースが、遮断と改善の間の現実的な解となります。

基準値の根拠

基準値は交渉によって決める数値ではありません。Claudeのドキュメントでは、業界標準、過去の実験、AI研究、専門知識に基づき、現在の最新モデルの能力から見て非現実的にならないように設定すべきであるとされています。実務で用いられる根拠は主に3つあります。

1. 現在の水準（ベースライン）。 現在、人間や既存システムが達成している水準。人間のオペレーターの分類正確度が93%であるなら、AIの目標を99%に設定する根拠は希薄です。
2. エラーのコスト。 1件間違えたときの損害。損害が大きいほど基準を高く設定するか、人間による確認プロセスを挟みます。
3. 小規模な実験。 50〜100件のサンプルで検証した結果。基準が達成可能かどうかを事前に確認します。

競合サービスの宣伝用数値は測定方法が分からないため、根拠として採用するのは困難です。

要件定義書の構成

AI機能の要件定義書は、次の構成で記述するとレビューや判定が容易になります。

1. 目的とユーザー: 誰が何のために利用するのか
2. 入力契約: 受け取るもの、受け取らないもの、範囲外の処理
3. 出力契約: 形式、空の値、検証失敗時の処理
4. 成功基準: 次元別の指標・データ・基準値・測定方法（ベースラインを含む）
   4-1. リリース遮断基準
   4-2. 改善目標
5. 失敗体験: 失敗の瞬間ごとの画面と次のアクション
6. レイテンシ・コスト: TTFT／全体の所要時間、1件あたりのコスト × 処理量
7. 法的要件: 告知・明示、個人情報の取り扱い条件
8. 未定事項: 定義が必要な要求と担当者、期限

さらに深く

指標を一つに絞り込みたい誘惑

経営陣は往々にして1つの数字を求めます。「それで何点なのですか？」複数の次元を加重平均した総合スコアは報告には都合が良いものの、危険です。個人情報の漏洩といった遮断基準が、他の次元の高いスコアに埋もれてしまうためです。正確度95点、トーン90点、個人情報40点の加重平均が80点だった場合、その80点はリリースしてもよいというシグナルのように見えてしまいます。

遮断基準は平均に含めず、個別に判定します。総合スコアが必要な場合は、遮断基準をすべてクリアした機能に限り、改善目標の推移を示す用途として使います。レポートの1行目は「遮断基準5項目すべて合格」でなければならず、総合スコアはその次です。

エラーの大きさも基準になる

すべてのエラーが同じ重みを持つわけではありません。Claudeのドキュメントにある多次元基準の例には、「エラーの90%は深刻なエラーではなく不便を与えるレベル」という項目があります。正確度が同じ2つの機能であっても、誤った回答が「別の表現で聞き直せば済むレベル」なのか、「誤った金額を約束してしまうレベル」なのかによって、リリースの判断は異なります。

そのため、成熟した要件定義ではエラーを深刻度別に分類して基準を設けます。例えば、深刻なエラー（誤った金額・期限・資格の案内）は0.5%以下とし、軽微なエラー（表現の不自然さ）は改善目標に設定します。深刻度の定義自体も要件であるため、具体例とともに記述します。

一貫性はいつ要件になるのか

同じ質問に対して毎回異なる回答が返ってくると、ユーザーは信頼を失います。特に規定の案内、価格の説明、資格の判定のように「同じ条件であれば同じ回答」が当然とされる領域では、一貫性が正確度と同じくらい重要になります。Claudeのドキュメントでは一貫性を成功基準の1つの次元として挙げ、同じ質問を2回行ったときに意味の近い回答を得ることがどれほど重要かを問いかけるよう勧めています。

一方で、アイデアの発想やキャッチコピーの候補出しのように多様性が価値となる機能において一貫性を求めると、かえって有用性が損なわれます。一貫性の要求は機能の目的から導き出されるべきであり、一貫性が高いことが正確であることを意味するわけではないという点に留意してください。同じ誤答を一貫して出力し続ける可能性もあるのです。

実務の場面

月暈ゲームズの通報分類

ゲーム会社「月暈ゲームズ」は、1日2万件のプレイヤー通報（暴言、不正プログラム、決済問題など）をAIで分類し、担当部署へ送ろうとしています。最初の要件は「通報を正確に分類する」でした。

企画担当者はまず、次元を分けました。分類正確度、緊急通報（現金詐欺・個人情報の流出）の検知、レイテンシ、コストです。正確度は先月人間が分類した通報3,000件を評価セットとし、「11種類の類型における完全一致率92%以上」と記載しました。人間の担当者の現在の一致率が94%であったため、100%を求める根拠はありませんでした。

緊急通報は個別に扱いました。緊急通報は全体の0.3%にすぎませんでしたが、見逃せば実際の金銭被害につながるためです。分類された緊急通報は担当者がすべて再確認するため、誤検知は許容できました。そこで「緊急通報の再現率98%以上」をリリース遮断基準として記載しました。適合率は担当者の1日の確認余力である300件から逆算しました。実際の緊急通報は1日約60件であるため、緊急と分類される件数が300件を超えないようにするには、適合率が20%以上でなければなりません。この「適合率20%以上」を運用条件として記載しました。棄却した案は「全体正確度95%以上のみを遮断基準とする」というものでした。0.3%の緊急通報は全体の正確度に埋もれて見えなくなってしまうからです。

出力契約も盛り込みました。分類結果は11種類の類型コードのうち1つのみを許容し、それ以外の値やフォーマットエラーは「未分類キュー」に送って人間が処理します。最後に「分類理由の文章の自然さ」は改善目標としました。担当部署は理由を読まずに原文を確認するため、リリースを止める理由にはならなかったためです。

野の花便りのカード文面

フラワーギフト配送サービス「野の花便り」は、注文者が受取人とシチュエーションを選択すると、AIがメッセージカードの文面を3つ提案する機能を企画しました。最初の要件は「感動的な文面をすばやく」でした。

企画担当者は「感動的」を細分化しました。注文者へのインタビューから挙がったのは、「シチュエーションに合っている（弔事に祝いの表現が含まれていない）」、「受取人の呼称が正しい」、「長すぎない（カードに収まる）」でした。前の2つは遮断基準となりました。弔事の場面でお祝いの表現が混ざるというエラーは、たとえ1件であっても大きなクレームにつながるため、「弔事における祝いの表現0件（禁止表現リストを用いてすべての文面をコードで検査）、その他のシチュエーション不一致0.5%以下」と記載しました。カードの長さは出力契約（1文面あたり80文字以下）とし、文面の温かみはルーブリック採点による改善目標としました。

「すばやく」はTTFT基準に変更しました。注文者は画面の前で待つため、最初の文面が2秒以内に表示されるようストリーミングを採用することにしました。評価において小型モデルが遮断基準をすべてクリアしたため、大型モデルの代わりに小型モデルを選択して1件あたりのコストも削減しました。棄却した案は「max_tokensを低く設定して長さを合わせる」というものでした。文章が途中で切れてしまい、カードに使えなくなるためです。

間違えやすいポイント

1. 「正確度さえあれば十分だ。」 レイテンシ、コスト、トーン、個人情報の処理は正確度とは別個に動きます。次元ごとに基準を設けます。
2. 「数値があれば良い基準だ。」 測定方法の信頼性が低かったり（生成モデルによる自己評価）、目的と無関係であったりする場合（短ければ短いほどよいなど）は、数値があっても悪い基準です。
3. 「すべての基準をリリース遮断基準にしておけば安全だ。」 利用に支障のない品質まで遮断してしまうと、リリースが際限なく先送りになります。実害につながる基準のみを遮断基準とします。
4. 「正確度が高ければフォーマットの検証は不要だ。」 フォーマットは正確度とは異なる要件です。構造化出力であっても、拒否や長さの上限によって崩れることがあります。
5. 「max_tokensを減らせば回答が短くすっきりする。」 長さの上限に達すると、文章の途中で途切れてしまいます。長さはプロンプトと出力契約で定めます。
6. 「速度が問題なら小型モデルに変更する。」 品質基準を満たすモデルが1つしかない場合は、ストリーミングや出力長によって体感レイテンシを短縮します。
7. 「回答できないときに拒否さえすれば安全だ。」 次のアクションが示されない拒否はユーザーを行き詰まらせ、コストを別の窓口へ転嫁させるだけです。

ひと目でわかるまとめ

• 良い基準 ＝ 指標 ＋ データ ＋ 基準値 ＋ 測定方法、そして基準値の根拠となるベースライン。他者が判定できなければならない。
• 成功基準は複数の次元（正確度、一貫性、関連性、トーン、個人情報、コンテキストの活用、レイテンシ、コスト）で設定する。
• 検知機能では、適合率と再現率のうちエラーのコストが大きいほうを死守する。
• 入力契約は評価で検証した範囲と一致させ、範囲外の入力は処理前に案内する。
• 出力契約にはスキーマとともに、検証失敗・拒否・長さ上限の処理ルールを記述する。
• レイテンシはTTFTと合計時間を区別し、ストリーミング・出力長・モデル・バッチ処理で調整する。
• 失敗の瞬間ごとに、ユーザーの次のアクションを要件として記述する。
• 遮断基準は法律・契約・実害につながるもののみとし、残りは改善目標とする。定義がなければ定義から始める。

公式ドキュメントで確認する

• Claude Docs — Define success criteria and build evaluations: 優れた成功基準の条件、悪い基準と良い基準の例、一般的な成功基準の次元。
• Claude Docs — Structured outputs: スキーマ遵守の保証と例外（拒否、max_tokens）。
• Claude Docs — Reducing latency: 基準レイテンシとTTFT、モデル選択、出力長、ストリーミング。
• Claude Docs — Batch processing: 非リアルタイムの大量処理におけるコストと処理時間。
• Google PAIR Guidebook — User Needs + Defining Success: 適合率と再現率、偽陽性と偽陰性のコスト。
• Google PAIR Guidebook — Errors + Graceful Failure: ユーザーが認識するエラー、エラー状態、失敗後の次のアクション。
• NIST AI RMF — Core: MAP 1.5（リスク許容水準の決定と記録）。

セルフチェック

2-1. 優れた成功基準に必ず含めるべき4つの要素を挙げ、基準値の根拠として併記すべきものを記述してください。

2-2. 「回答が速くなければならない」を判定可能な基準に変換し、ユーザーが画面の前で待機する機能である場合はどのレイテンシ指標を用いるべきか説明してください。

2-3. 適合率と再現率をそれぞれ1文で定義してください。

2-4. 病院の予約SMSから「予約キャンセルのリクエスト」を検知して自動的に予約を削除する機能があります。検知された案件は人間の確認なしに実行されます。どの指標をリリース遮断基準として死守すべきか、またその理由を説明してください。

2-5. 構造化出力を使用する場合であっても、出力契約に検証失敗時の処理ルールを記載しなければならない理由を、2つの状況を挙げて説明してください。

2-6. 次の各項目をリリース遮断基準と改善目標に分類してください：（ア）相談の要約に顧客の口座番号が残る割合、（イ）要約文の簡潔さのスコア、（ウ）返金期日を誤って記載する割合。

2-7. （設計）普段よく使うAI機能を1つ選び、失敗の瞬間を3つと、それぞれの瞬間にユーザーへ提示すべき次のアクションを表形式で記述してください。

実習課題