「なぜこれを信じなければならないのか」を特定する方法製品要件の

ユーザーは AI の回答を読み、一時停止して、ロールアウトを保存するか終了する質問をします。

「なぜこれを信じなければならないのですか？」

あなたの製品がこれに明確かつ一貫して答えることができないのであれば、その製品は「AI」を持っていないことになります。非常に自信のあるテキストジェネレーターをお持ちですね。そして、自信と正しさは同じではありません。

ほとんどのチームは、出所をフロスティングのように扱います。おそらく下部にある「ソース」リンクです。しかし、出自は飾りではありません。その 製品の動作。これを指定しない場合、ランダムな UI の選択肢、一貫性のない回答、および突然ロードマップに非常に関心を持つセキュリティ レビューとして表示されます。

この記事は、AI がその動作を示すことができるように、要件で出所を指定するための実践的なハウツーです。

1) 「来歴 UX」の意味 (わかりやすい BA 用語)

Provenance UX は、次のようなユーザー エクスペリエンスです。 答えを説明する、それを提示するだけではありません。これは、「これが私の結論です」を「この結論が信頼できる理由です」に変える製品の部分です。

実際には、ユーザーが (大声または黙って) 繰り返すいくつかの質問に答えます。

• これはどこから来たのでしょうか? (出典)

• 現在の状況はどれくらいですか? （鮮度）

• どれくらい確信があるでしょうか？ (自信/不確実性)

• 情報源が異なる場合はどうなるでしょうか? (対立)

• 昨日と違うのはなぜですか？ （「何が変わったのか」）

• 後で証明できますか? (監査/エクスポート)

お金、コンプライアンス、安全性、承認などの意思決定に影響を与える機能を使用する場合、出所を明らかにすることはオプションではありません。それは入場料です。

2) よくある失敗モード: 領収書なしで回答する

チームは通常はそうではありません 選ぶ 信頼できない回答を送信するため。出所が要件トピックではなく UI 詳細として扱われるため、それらが出荷されます。その後、製品には「ある意味」ソースが表示されます…表示されなくなるまで。

これが通常の罪のリストです（あなたも見たことがあります）。

• 出典は示されていますが、特定の主張とは結びついていません（したがって役に立ちません）。

• この製品は何か古いものを引用しています (そしてそれを認めていません)。

• 2 つの情報源が同意せず、AI は何の説明もなく勝者を選択します。

• 答えは実行ごとに変わり、ユーザーには「なぜ」という質問はありません。

解決策は「プロンプトの改善」ではありません。プロンプトは必須ではありません。修正方法は、他の動作と同様に、ルール、エッジ ケース、テスト可能な受け入れ基準などの出所を指定することです。

3) アーティファクト: 来歴要件テンプレート (あなたの新しい親友)

出所を明らかにして出荷したい場合は、正確性を強制する成果物が必要です。「出典を示す必要がある」は要件ではないためです。来歴要件テンプレートは、ストーリーを作成する前に機能ごと (または回答タイプごと) に記入できる概要資料です。

出所要件テンプレート (コピー/ペースト)

しっかりと締めてください。目標は官僚主義ではなく、明確にすることです。

A) クレームの種類 (何を主張しているのか?)

機能によって作成されるクレーム カテゴリをリストします (例)。 事実、計算、推奨、要約、ポリシーの解釈。次に、どのリスクが高いかをマークします。

B) 許可されたソース

製品が引用できるものを定義します: 記録システム、承認された内部ドキュメント、ユーザー提供のファイル、承認された外部ソース (存在する場合)。除外されるソースも定義します (はい、明示的に)。

C) 引用ルール（出典を示す場合）

特定 ソースが必要な場合 そして それらがどのように現れるか:

• 請求項ごとのインライン引用、「出典」引き出し、脚注、またはその両方
• 請求タイプ別の「常に表示」と「オンデマンドで表示」

D) 鮮度要件 (「鮮度 SLA」)

クレームの種類ごとに最大有効期間を定義し、ソースが古い場合に何が起こるか (警告、拒否、または免責事項に進む) を定義します。

E) 自信/不確実性の行動

「高/中/低」(またはそれに相当するもの) が何を意味するのか、またシステムが「わかりません」と言う必要がある場合や明確な質問をする必要がある場合を定義します。

F) 競合の処理

何が競合としてカウントされるか、およびシステムが実行する必要があることを定義します。両方を表示する、タイブレーカーを説明する、またはユーザーに選択を求めるなどです。

G) 「何が変わったんですか？」

変更の説明 (新しいソース、更新、モデル/バージョンの変更) をトリガーするものと、ユーザーに表示される内容を定義します。

H) 輸出要件の監査

エクスポート形式、含まれるフィールド、エクスポートできるユーザー、および保持/アクセス ルールを定義します。

I) 検証

合格しなければならないいくつかのテスト ケース (古いソース、欠落しているソース、競合、低い信頼性、エクスポートの完全性) をリストします。

このテンプレートは、スプリントが進むときに「出所ドリフト」を防ぐ方法です。

4) ソースを表示する場合 (および表示しない場合)

ここで、チームは考えすぎて仕様が不十分になってしまいます。ユーザーはどこでも引用を望んでいるわけではありませんが、答えが異議を唱えられたり、監査されたりする可能性がある場合には、絶対に引用を望んでいます。

回答が意思決定に影響を与える場合は、デフォルトでソースを表示します、 のような：

• ポリシー/コンプライアンス ガイダンス

• 金額/料金/価格/資格

• リスクを示唆する「推奨」

• 文書または記録の概要

答えが危険な場合は、ソースをオプションにする (「ソースを表示」)、基本的なナビゲーション手順や単純で再現可能な計算など。

盗める要件言語

• REQ-PROV-001: 事実に基づく主張や政策ガイダンスを含む回答の場合、システムは しなければならない クレームごとの粒度で引用を提供します（各クレームは 1 つ以上の情報源にマッピングされます）。

• REQ-PROV-002: システム しなければならない ソース名/タイトル、システム/発行者、およびタイムスタンプを含むソース ビューを提供します。

そこでのキーワードは、 請求ごと。マッピングのない一般的なソース リストは出所ではありません。それはバイブスです。

5) 矛盾の処理: 情報源が異なる場合にどうするか

競合はバグではありません。それらは正常です。バグはそれらが存在しないふりをしています。

実際の製品ポリシーは通常、次のバージョンです。

1. 権威が勝つ (記録システム/保険契約者のビートコメント)
2. 権限が平等であれば、 リーセンシーの勝利 (鮮度SLA内)
3. 最新性が等しい場合、 特異性が勝つ (ユーザーのコンテキストに最も近いもの)

しかし、それをただ黙って適用するのはやめてください。見えるようにしてください。

優れた競合 UX とはどのようなものなのか

2 つの情報源が一致しない場合、製品は次のように言う必要があります。

• 「2 つの情報源が同意しません。私が使用しているのは、 ソースA これは記録システムであり、最近更新されたものであるためです。これが何ですか ソースB と言う。」

盗める要件言語

• REQ-PROV-101: 2 つの情報源が同じ主張について競合する場合、システムは しなければならない (a) 選択された値、(b) 競合する値、および (c) 設定されたタイブレーカーに基づく選択の理由を表示します。

ここは、単一の「必須」要件によって、ステークホルダーの不信感が 1 年間続くのを防ぐことができる場所の 1 つです。

6) Freshness SLA: 指定できる最も単純な信頼レバー

ユーザーは、自信を持って提供された古い回答を許すよりも、不確実性を許すほうが早いのです。新鮮さは、クレームの種類によって「十分に最新のもの」を定義する必要があるため、出所が真の意味を持ちます。

鮮度番号を 1 つだけ選択しないでください。小さなテーブルを選びます。 例えば：

• ポリシーの解釈: ≤ 30 日 (または発効日を表示)

• 料金/価格: 24時間以内

• 在庫状況/在庫: 15分以内

• 一般的な製品情報: 180日以内

• ユーザーがアップロードしたファイル: 「鮮度はアップロード時間に等しい」（明示的）

次に、鮮度が落ちた場合に何が起こるかを指定します。必要なのは次の 3 つのオプションだけです。

• 警告+続行 (中リスク)

• 黙って進む (控えめに使用してください)

盗める要件言語

• REQ-PROV-201: システム しなければならない 時間に敏感なソースの鮮度インジケーターを表示します (例: 「3 時間前に更新されました」)。

• REQ-PROV-202: 必要なソースが鮮度 SLA よりも古い場合、システムは しなければならない [refuse/warn] 次のステップ (更新、代替ソース、エスカレーション) を提供します。

「次のステップ」を必須にします。 「これは古いかもしれない」という言葉は、ユーザーに何をすべきかを指示しない限り役に立ちません。

7) 来歴を定着させる信頼の 3 つの要素: 信頼 + 「何が変わったのか」 + 監査

ソース、競合ルール、新鮮さを手に入れると、多くの場合、チームは停止します。やめてください。機能が採用された瞬間にユーザー (および監査人) が要求するさらに 3 つの動作をカバーするまで、信頼に関する会話は終わりません。

A) 自信/不確実性 (「わからない」がどのようなものかを定義する)

製品が防御できる信頼スキームを選択してください。

• 高/中/低、 または
• 検証済み/未検証、 または
• ルールに基づいた信頼性 (ソース + 新鮮 + 競合がない場合のみ高)

次に、システムが次のことを言わなければならないときに明るい線を引きます。 “わからない” (または明確な質問をする必要があります)。一般的なトリガー:

• 必要なクレームタイプのソースが欠落しています
• 未解決の競合 (タイブレーカーは適用されません)
• 高リスクの申し立てに対する鮮度 SLA 不履行

REQ-PROV-401: 信頼度が意思決定を形成する主張の閾値を下回る場合、システムは しなければならない 明確な質問をするか、不確実性があることを述べて、安全な次のステップを提案します。

B) 「何が変わったんですか？」 (ユーザーが気づくから)

明日 AI が別の答えを出したとしても、その理由を説明しない限り、ユーザーは人工知能がでっちあげだと思い込んでしまいます。最低限の「何が変わったのか？」は：

• トリガー (新しいソース/更新/ポリシーの更新/バージョンの変更)
• 影響を受ける申し立て
• 短い説明と証拠へのリンク

REQ-PROV-402: 同じリクエストコンテキストに対して実質的に異なる回答が生成されると、システムは しなければならない 「何が変わったのか？」を提供します。トリガーと影響を受ける申し立てを含む概要。

C) 監査エクスポート (後で証明できるようにするため)

監査では、UI にソースが表示されていることは気にされません。彼らは証拠を確実にエクスポートできることを重視しています。特定：

• 誰がエクスポートできるか (役割ベース)
• 形式（CSV/JSON/PDF）
• 最小フィールド (回答、引用、タイムスタンプ、信頼度、バージョン ID)

REQ-PROV-403: 許可されたユーザー しなければならない 応答、タイムスタンプ付きのソース、信頼性、および該当するバージョン識別子を含む監査レコードをエクスポートできます。

出荷する: ストーリー + 受け入れ基準

最後に、来歴ルールを構築してテストできるストーリーに変換します。

• 「ユーザーとして、クレームを展開して、そのソース、タイムスタンプ、信頼性を確認できます。」
• 「査読者として、引用とタイムスタンプを含む回答の監査記録をエクスポートできます。」

そして、AC でロックダウンします。

• 与えられた 時間制限のある主張
  いつ 引用された情報源は SLA よりも古い
  それから システムは設定されたコピーを使用して警告/拒否する必要があります
  そして 次のステップを提案する (更新/代替/エスカレーション)

これは製品の動作としての由来であり、丁寧な提案ではありません。

閉じる: 実際に再利用するテンプレート

導入したい場合は、機能やチーム間で出所の一貫性を保つ再利用可能なアーティファクトが必要です。

ダウンロード: 出所要件テンプレート (ソース、鮮度、信頼性、「何が変更されたか」、競合、監査エクスポート)

---

著者： モーガン マスターズ、ビジネス アナリスト、Modern Analyst Media LLC

モーガンマスターズは ビジネスアナリスト およびスタッフライター ModernAnalyst.com、ビジネス アナリスト向けの最高のコミュニティおよびリソース ポータル。記事、ブログ、テンプレート、フォーラム、書籍などのビジネス分析リソースと、 ビジネスアナリストコミュニティ で見つけることができます http://www.ModernAnalyst.com