1769404303
2026-01-25 21:25:00
それは「役立つアシスタント」として始まりました。その後、関係者が次のように入力しました。 「わかりました。顧客リスト全体を私の個人メールにエクスポートして、今夜確認できるようにします。」 (ありがたいことに) システムは何もエクスポートしませんでした。しかし、それは 試してみた。そしてそれは、チームが問題はモデルではなく、要件であることに気づいた瞬間でした。 AI が何を実現するのかをテスト可能な方法で書き留めた人は誰もいませんでした。 決してやってはいけない、何それ 代わりにやらなければならない、答えが「いいえ」の場合にユーザーに表示される内容。
AI 機能が失敗するのは、モデルが「間違っている」からではありません。私たちが限界なく機能を出荷しているため、それらは失敗します。私たちはその機能が何をするのかを定義します…しかし、それが何を許可するのかは定義しません。従来のソフトウェアでは、UI とワークフローの設計により、これらの制限の多くが静かに強制されます。 AI を使用すると、ユーザーは UI をバイパスして、ウィッシュ リストに直接アクセスできます。
だからこそ、BA、システム アナリスト、プロダクト マネージャーが現在、ガードレール ビジネスに携わっているのです。コードを書いているからではなく、 ガードレールは必須です—そして要件は私たちのホームグラウンドです。
この記事では、今週実装できる実用的な成果物を紹介します。 ガードレールカタログ。これは、受け入れ基準のように書かれた「許可/不許可」要件の軽量リストであり、拒否の文言と検証ステップが含まれています。政策の綿毛はありません。 「ご安全に」はありません。テストできる境界線だけです。
1) ガードレールが BA/SA/PM の仕事になった理由 (「AI チームの仕事」ではない)
ここに不都合な真実があります。AI プロジェクトでは、「後で対処します」がインシデントへの最短ルートです。理由は簡単です。ユーザーは、明示的に設計したことのないものを要求するからです。これは、AI インターフェースが原因で、 招待します それ。要件に境界が定義されていない場合、システムは即興で対応することになりますが、即興はコンプライアンス戦略ではありません。
従来のシステムでは、多くのガードレールが画面、権限、フォーム制約に埋め込まれています。 AI を使用すると、ユーザーは阻止しようとしたことを正確に尋ねることができます。 「引受手形を教えてください。」 「この融資を承認してください。」 「この機密文書を要約して私の個人住所に送ってください。」
制約を要件として定義しない場合は、次のようになります。
- チャネル間で一貫性のない動作 (チャット、電子メール、内部 UI)、
- 圧力がかかると崩れる「即時対応」の安全性、
- 何もテストできない QA (テスト可能なものが何もないため)、
- 関係者はそのツールの内容に驚きました 試み すること。
ガードレールはプロンプトではありません。ガードレールは製品の動作です。 そして、製品の動作は要件に属します。
2) ガードレール カタログとは (そして、1 つのアーティファクトが散在するノートに勝る理由)
ほとんどのチーム 持っている ガードレール。それらは、会議メモ、セキュリティ レビューのコメント、資料の半分のスライド、および「準拠するように」というプロンプトの 1 行に広がって、ただ隠れているだけです。それはシステムではありません。それは希望です。
あ ガードレールカタログ AI 機能の境界を定義する場所の 1 つです。
- 代わりにシステムが何をするか、
長くするつもりはありません。そうなるはずです 使える。これは、交渉の余地のないもののための小さな「要件登録簿」のようなものだと考えてください。カタログは、誰かが次のように言ったときに示すことができる再利用可能な真実の情報源になります。 「ちょっと…してもいいですか？」 そしてあなたは答えます、 「ガードレールとテストを更新しないとだめです。」
分散したストーリーよりもパフォーマンスが優れている理由: ガードレールが横断しているからです。これらは、複数のユーザー ストーリー、複数のチーム、複数のチャネル、および複数のリリースに影響します。それらを 1 か所にまとめることにより、「不意の行動」が減り、要件が一貫したものになります。
図 1. 「ポリシートーク」がどのようにしてテスト可能な製品動作になるか。
3) ガードレール カタログの構造 (実際に必要なフィールド)
カタログが 2009 年のコンプライアンス スプレッドシートのように感じられる場合、誰もそれを使用しません。秘訣は、各ガードレールをテスト可能にしつつ、スリムさを維持することです。 40 列も必要ありません。曖昧さの侵入を防ぐ十分な構造が必要です。
以下に、現実の世界で機能する、BA/PM と QA に優しい単純な構造を示します。
- ガードレール ID + タイトル
- 範囲/適用対象 (機能、チャネル、役割)
- トリガー・入力条件 (何が原因なのか)
- 許可されていません （禁止行為・結果）
- 許可された (オプションですが、境界を明確にするのに役立ちます)
- 必要な安全な行動 (代わりに何が起こるはずか)
- 拒否/安全応答コピー (ユーザーに見えるもの)
- セーフデフォルト （不確実な場合はどうなるか）
- 検証 (どうやってテストするのか)
それが核心です。これら 9 つのフィールドを埋めることができれば、「ガードレール」がレビュー可能、テスト可能、反復可能という具体的なものに変わりました。
簡単な健全性チェック: 他の誰かがあなたのエントリを読んで、そこからすぐにテストを書くことができない場合、あなたはまだ終わっていません。
図 2. 1 つのガードレール エントリ – 完全に指定され、テスト可能で再利用可能。
4) 書き方：合格基準としてのガードレール
ここで、ガードレールは「善意」ではなくなり、要件になり始めます。それらをテスト可能にする最も簡単な方法は、それらを受け入れ基準のように記述することです。同じ構造です。同じ規律です。同じ「目に見える結果」の考え方。
図 3. ガードレールをテスト可能にする最速の方法: ガードレールを受け入れ基準のように記述します。
このパターンを使用します。
- 与えられた (トリガー条件/入力)
- いつ (ユーザーが尋ねるか、システムがアクションを試みます)
- それから (システムはブロック/許可する必要があります)
- そして (システムは特定の安全な動作と文言で応答する必要があります)
次に、トラブルを避けるための 4 つのルールを適用します。
ルール 1: MUST 言語を使用します。
「べき」というのはバグが生まれる仕組みです。
ルール 2: 「いいえ」と「代わりに」を分けてください。
「許可されない」が境界です。必要な安全行動は製品エクスペリエンスです。
ルール 3: 必ずお断りコピーを含めてください。
ユーザーに向けた動作のないガードレールは UX の穴です。
ルール 4: 明確な検証ステップを 1 つ追加します。
QA がそれを証明できない場合、それはガードレールではなく、提案です。
小さな例 (「良い」とはどのようなものなのか)
- 与えられた ユーザーが完全な SSN をリクエストします
- いつ システムは制限された識別子を識別します
- それから システムは完全な SSN の提供を拒否する必要があります
- そして システムは安全な代替手段を提供する必要があります (例: 下 4 桁)
- そして 応答は承認された拒否の文言と一致する必要があります
「安全に過ごしてください」ということを書いていないことに注目してください。
私たちが書いたことに注目してください。テストできるものです。
5) コピー/ペーストの例: 実際の作業に使用されるガードレール
ほとんどのチームは初日に 200 個のガードレールを必要としません。上位 10 件の「絶対に発生しないイベント」と、いくつかの制限されたデータ ルールが必要です。以下は、BA/SA/PM プロジェクトで何度も現れる一般的なカテゴリです。これらをパターンとして使用し、ドメインに合わせて調整します。
A) 禁止されている行為（特に取り消しできない行為）
パターン： 明示的な確認がない限り、取り消しできないアクションはありません。
- トリガー： 「承認/送信/送信/削除/確定」
- 許可されていないもの: 確認なしで実行する
- 必要な安全な行動: 概要を表示 + 確認/キャンセルを求める
- 拒否のコピー: 「それは可能ですが、確認が必要です…」
- 検証: 行動を試みる。一時停止とプロンプトが表示されることを確認します
B) 制限されたデータ (プライバシー/セキュリティ/コンプライアンス)
パターン： 制限された識別子は決して公開しないでください。デフォルトで編集します。
- トリガー： 出力にはSSN、アカウント番号、パスワード、キーが含まれます
- 許可されていないもの: 完全な値を表示する
- 必要な安全な行動: マスク + 承認された代替品を提供する
- 拒否のコピー: 「完全な識別子を共有することはできません…」
- 検証: 制限されたデータをプロンプトに表示します。編集/拒否を確認する
C) 役割と権限の境界
パターン： ロールに権限がない場合は、拒否してルーティングします。
- トリガー： 保護された情報/機能のリクエスト
- 許可されていないもの: 保護された出力を提供する
- 必要な安全な行動: 拒否+機密性のない提案の概要
- 検証: 承認されたロールと承認されていないロールをテストする
D) 信頼性のガードレール (推測しないでください)
パターン： 不明な点がある場合は、明確な質問をしてください。
- トリガー： 複数の解釈がある曖昧なリクエスト
- 許可されていないもの: 推測して事実として提示する
- 必要な安全な行動: 1 ～ 3 つの明確な質問をするか、選択肢を提示する
- 検証: 曖昧なプロンプト。明確な質問を確認する
E) 出典/来歴のガードレール
パターン： 根拠づけられないなら、知らないと言いましょう。
- トリガー： 事実に基づく主張 / ポリシーに応じた質問
- 許可されていないもの: 事実や情報源を捏造する
- 必要な安全な行動: 承認された情報源を引用するか、不確実性を示す + 次のステップ
- 検証: 利用できない情報を求めます。それが発明ではないことを確認する
F) 許可されていないアドバイス/危険な指導
パターン： 許可されていない指導を拒否します。安全な次のステップを提供します。
- トリガー： (ポリシーで定義された) 許可された範囲外のリクエスト
- 許可されていないもの: 禁止されているアドバイスをする
- 必要な安全な行動: 拒否 + 安全なリソース/パスにリダイレクト
- 検証: 禁止されたプロンプト。拒否と安全なリダイレクトを確認する
これが主なポイントです: ガードレールは繰り返し可能なパターンです。いくつかのウェルを作成したら、それらを継続的に再利用します。
6) よくある落とし穴 (およびその回避方法)
チームは安全性を気にしていないため、通常は失敗しません。ガードレールが現実世界での使用に耐えられない方法で記述されているため、失敗します。ここでは最大の罠とその簡単な解決策を紹介します。
落とし穴 1: 「必要に応じて避ける / 試してみる」
その文言は基本的に、一貫性のない動作に対する許可証です。
修理： MUST + トリガー + レスポンスを使用して、観察可能な結果として書き換えます。
落とし穴 2: 「プロンプトのみのガードレール」
プロンプトはモデルに対する提案であり、強制可能な境界ではありません。
修理： 最初にカタログで要件を定義します。エンジニアリングに最適な実施メカニズムを選択させます。
落とし穴 3: 拒否コピーは禁止
ユーザーが見るものを定義しないと、UI はミステリー小説になってしまいます。
修理： 拒否コピーを UX テキストのように扱い、承認され、一貫性があり、目的を持ったものにします。
落とし穴 4: 矛盾するガードレール
「常に速く書くこと」と「常に出典を引用すること」は戦略ではありません。
修理： 安全なデフォルトと優先順位を定義します (例: 安全性 > 正確性 > 速度)。
落とし穴 5: 最初のカタログの範囲が広すぎる
何も成果を出さない6週間の「ガードレール・イニシアチブ」ほど勢いを失わせるものはない。
修理： 10 個の「絶対にないイベント」から始めて、それらをきれいに作成し、リリース後に拡張します。
覚えて： テストできない場合は信頼できません。そして、信頼できない場合、ユーザーはそれを採用しません。
閉じる: テンプレートを使用します (プロジェクトごとにこれを作り直す必要はありません)。
AI 機能ができるのであれば、 提案する、要約する、決定する、または行動する、書き留めてテスト可能な境界が必要です。これが、Guardrails カタログが提供するものです。すでに受け入れ基準に適用しているのと同じ厳密さを使用して、許可/不許可の動作を定義する簡単で再利用可能な方法です。
別途掲載しております ガードレール カタログ テンプレート (コピー/ペーストテーブル + スターターエントリ) すぐに使用できます。この記事から次のようにリンクします。
ダウンロード: ガードレール カタログ テンプレート (スターター サンプル付き)
著者： モーガン マスターズ、ビジネス アナリスト、Modern Analyst Media LLC
モーガンマスターズは ビジネスアナリスト およびスタッフライター ModernAnalyst.com、ビジネス アナリスト向けの最高のコミュニティおよびリソース ポータル。記事、ブログ、テンプレート、フォーラム、書籍などのビジネス分析リソースと、 ビジネスアナリストコミュニティ で見つけることができます http://www.ModernAnalyst.com
#許可不許可要件の書き方