第2章：要件定義の認知プロセス - AI を含む要求境界の設計
AI ネイティブな実務における要件定義は、顧客の言葉を技術仕様へ翻訳するだけでは足りない。 AI を含む業務、プロダクト、社内ツールでは、何を自動化するかだけでなく、どのデータを使うか、誰が承認するか、失敗時にどう止めるか、何をもって受け入れるかを先に決める必要がある。
要件定義の失敗は、実装の遅れとして表面化することが多い。しかし根本原因は、問題設定の誤り、評価不能な要求、権限境界の未定義、禁止情報の混入、失敗時挙動の欠落にある場合が多い。 本章では、AI を含む要求を、評価可能で、監査可能で、運用へ引き渡せる要求境界として定義する方法を扱う。
この章で扱う判断
本章で扱う判断は、次の5つである。
- 本当に解くべき問題は何か、AI を使う前にどこまで問題設定を確認するか。
- AI を含む業務・プロダクト・社内ツールの要求を、どの成果物へ落とすか。
- 利用データ、アクセス権、利用禁止情報、承認者をどう明文化するか。
- Human-in-the-loop / Human-on-the-loop / Full automation をどう切り分けるか。
- 受入条件、KPI、guardrail metric、fallback、manual override をどう定義するか。
誰向けか
- IC / Senior Engineer: 曖昧な要求を、検証可能なチケット、acceptance criteria、open question へ分解したい人。
- Tech Lead: AI 機能や社内 AI ツールの作業範囲、承認境界、レビュー責任をチームで揃えたい人。
- PM / Product Owner: 利用者価値、失敗時挙動、KPI、リスク許容を、実装可能な要求へ変換したい人。
- Security / Compliance: データ分類、権限、禁止情報、監査証跡、承認条件を要件段階で固定したい人。
- SRE / DevOps: fallback、manual override、rollback、運用負荷を要件から外さずに扱いたい人。
章末に残るもの
この章を読み終えた時点で、次の成果物を作れる状態を目指す。
- requirements brief
- acceptance criteria
- assumption & open question log
- data / permission boundary table
- automation boundary table
- stakeholder alignment checklist
よくある失敗
| 失敗 | 何が起きるか | 防止策 |
|---|---|---|
| 「精度が高い」を要件にする | 何を測ればよいか分からず、PoC が終わらない | タスク、評価データ、許容誤差、失敗時挙動を分ける |
| 問題設定がずれている | AI 機能はできたが、現場の業務負荷が減らない | 利用者、業務イベント、意思決定点を requirements brief に書く |
| データ利用境界を書かない | 個人情報、契約情報、機密情報が入力に混ざる | data / permission boundary table を要件に含める |
| 誰が承認するかを書かない | 本番化直前に法務・セキュリティ・監査で止まる | decision rights と approval gate を先に定義する |
| 失敗時挙動を書かない | 誤回答、誤操作、過剰自動化を止められない | fallback、manual override、rollback を受入条件に入れる |
| KPI だけを見る | 利用率や処理件数は伸びても事故リスクが増える | guardrail metric を KPI と同じ表で管理する |
本章と AI 協働の標準手順（SOP）
本章は、AI 協働の標準手順（SOP） のうち、特に次の工程に対応する。
- Issue 化: 問題、利用者、判断点、成功条件、非目標を明文化する。
- 情報分類: 入力できる情報、入力禁止情報、匿名化・マスキング条件を定義する。
- Plan 作成: stakeholder、decision owner、reviewer、approval、escalation を決める。
- 入力設計: requirements brief、前提、open question、出力 schema を定義する。
- 評価設計: acceptance criteria、guardrail metric、fallback、manual override を決める。
- 記録: 変更理由、採否、承認者、検証結果を後から追跡できる形で残す。
本章の目的は、AI を要件定義で使うことではない。AI を使う場合でも使わない場合でも、実装・運用・監査に耐える要求境界を残すことである。 要求境界には、security / privacy / compliance / approval / audit / rollback を後工程へ先送りしないという前提を含める。
2.1 問題設定と要求境界を分ける
要件定義で最初に確認すべきことは、「どの機能を作るか」ではない。「どの問題を、誰の責任範囲で、どの失敗条件を許容して解くか」である。 AI を含む提案では、問題設定が曖昧なまま「AI で自動化する」「チャットボットにする」「agent に任せる」という解決策が先に出やすい。 しかし、解決策が先に決まると、評価不能な要件、過剰な自動化、不要なデータ利用、承認不能な運用が生まれる。
2.1.1 問題設定の4層
問題設定は、次の4層に分ける。
| 層 | 問うこと | 悪い書き方 | 良い書き方 |
|---|---|---|---|
| 業務問題 | どの業務イベントで困っているか | 問い合わせ対応を AI 化したい | 月次締め前の経費規程問い合わせが集中し、担当者確認が2営業日遅れる |
| 利用者判断 | 誰が何を決めるために使うか | 社員が質問できるようにする | 申請者が入力前に規程該当箇所を確認し、不明時は経理担当へ escalation する |
| システム境界 | どこまで自動化し、どこから人が判断するか | 自動回答する | 規程引用と候補提示まで自動化し、例外判断と承認は人が行う |
| 失敗条件 | 何が起きたら止めるか | 精度を上げる | 引用なし回答、規程版数不明、個人情報混入時は回答を止める |
この4層を分けると、要求が実装指示ではなく、判断可能な境界になる。
2.1.2 非目標を先に書く
AI を含む要求では、非目標が重要である。非目標がないと、期待が膨らみ、PoC と本番運用の境界が崩れる。
非目標には、次を含める。
- 法務判断、監査判断、リスク受容を AI に代替させない。
- 最新価格、UI 手順、モデル比較を本文または固定仕様に埋め込まない。
- 個人情報、契約情報、秘密情報を外部 AI に入力しない。
- 本番操作、権限付与、削除、送信などの不可逆操作を自動承認しない。
- PoC の評価結果を、そのまま本番利用可能性の証明にしない。
非目標は、機能を小さくするためだけに書くのではない。承認不能な期待を早期に外し、関係者の合意を取りやすくするために書く。
2.1.3 要求境界の確認質問
要求境界を確認する質問は、次の形で使う。
- その要求は、誰の業務判断を支援するのか。
- AI が失敗した場合、誰が気づき、誰が止めるのか。
- その判断には、個人情報、契約情報、機密情報が必要か。
- AI は回答するだけか、tool を実行するのか。
- 失敗時に、業務を止める、手動へ切り替える、前の状態へ戻す手順はあるか。
- 正しいことを、誰が、どのデータで、どの頻度で確認するのか。
- 受け入れない条件は何か。
この質問に答えられない要求は、まだ実装に渡してはいけない。まず open question として記録し、確認者と期限を付ける。
2.2 requirements brief を作る
requirements brief は、要求定義を長い仕様書にする前の最小成果物である。 目的は、問題、利用者、境界、受入条件、未確定事項を1つの判断単位として揃えることである。
2.2.1 requirements brief の最小 schema
| 項目 | 書くこと | 確認観点 |
|---|---|---|
| 背景 | なぜ今対応するか | 事業、業務、運用、リスクのどれに効くか |
| 利用者 | 誰が使い、誰が判断するか | 利用者、運用者、承認者、影響を受ける人を分けたか |
| 現状の問題 | どのイベントで何が起きているか | 事実、推測、希望が混ざっていないか |
| 期待する成果 | 何が改善されれば成功か | 成果が測定可能か |
| スコープ | 今回含める範囲 | PoC、本番、特定部門、特定データなどを明示したか |
| 非目標 | 今回含めない範囲 | AI に判断させない領域を明示したか |
| データ | 利用する情報、禁止情報、保存条件 | data / permission boundary table に接続しているか |
| 自動化境界 | HITL / HOTL / Full automation のどれか | 承認者と停止条件があるか |
| 受入条件 | 品質、再現性、説明可能性、フェイルセーフ | テストまたはレビューで確認できるか |
| 未確定事項 | 判断を保留する理由 | owner、期限、確認方法があるか |
requirements brief は、すべての詳細を固定するものではない。むしろ「まだ分からないこと」を安全に見える化するために使う。
2.2.2 例: 社内ナレッジアシスタント
次は、requirements brief の簡略例である。
| 項目 | 記載例 |
|---|---|
| 背景 | 社内規程に関する問い合わせが月末に集中し、経理・人事の回答待ちが業務遅延になっている |
| 利用者 | 一般社員、一次回答を確認する経理担当、例外判断を行う部門責任者 |
| 現状の問題 | 規程の該当箇所を探せず、同じ質問が繰り返される。例外判断は担当者に属人化している |
| 期待する成果 | 規程の該当箇所と関連 FAQ を提示し、例外は担当者へ escalation できる |
| スコープ | 経費精算規程、旅費規程、FAQ。初期対象は国内出張のみ |
| 非目標 | 申請承認、法務判断、最終的な支払可否判断は行わない |
| データ | 公開社内規程、FAQ、匿名化済み問い合わせ分類。個人申請データは入力しない |
| 自動化境界 | Human-on-the-loop。通常回答は自動提示、例外・引用不足・高リスク回答は人へ回す |
| 受入条件 | 引用付き回答、規程版数表示、引用なし回答の停止、担当者への escalation |
| 未確定事項 | 部門別アクセス制御の要否、ログ保存期間、監査閲覧権限 |
この粒度であれば、実装チームは設計へ進める。Security や Compliance も、確認すべき境界を見つけやすい。
2.2.3 assumption & open question log
未確定事項を本文の注釈に埋め込むと、後で追跡できない。 assumption & open question log は、前提、質問、決定を分けるための表である。
| ID | 種別 | 内容 | 影響 | owner | 期限 | 状態 |
|---|---|---|---|---|---|---|
| A-01 | 前提 | 初期対象は国内出張規程のみ | 対象データと FAQ 範囲 | Product Owner | 2026-06-05 | 確認済み |
| Q-01 | 質問 | 部門別アクセス制御が必要か | 権限設計、ログ設計 | Security | 2026-06-07 | 未確認 |
| D-01 | 決定 | 申請承認は AI 対象外 | 非目標、UI 表示 | 経理責任者 | 2026-06-03 | 決定 |
前提は、正しければ要件を支える。誤っていれば設計を壊す。したがって、前提は確認タスクとセットで管理する。
2.3 data / permission boundary table を作る
AI を含む要求では、データ境界と権限境界を要件段階で定義する。 後から設計で補うと、既に作った機能やワークフローが前提を満たせないことがある。
2.3.1 データ分類
データ分類は、最低限次の粒度で行う。
| 分類 | 例 | AI 入力 | 保存 | 追加確認 |
|---|---|---|---|---|
| 公開情報 | 公開マニュアル、公開 FAQ | 可 | 通常ログ可 | 出典と版数を記録する |
| 社内限定 | 社内規程、運用手順 | 条件付き可 | アクセス制御付き | 利用目的、閲覧権限、保持期間を確認する |
| 個人情報 | 氏名、住所、社員番号、申請内容 | 原則不可またはマスキング必須 | 最小化 | privacy、法務、社内規程を確認する |
| 契約情報 | 顧客契約、価格条件、SLA | 原則不可 | 監査対象 | 契約条項と外部送信可否を確認する |
| 秘密情報 | 認証情報、秘密鍵、未公開脆弱性 | 不可 | 保存しない | 入力遮断と検知を要件化する |
この表は、法務判断やセキュリティ判断の代替ではない。要件定義の段階で、確認すべき論点を漏らさないための入口である。
2.3.2 権限と操作の境界
データだけでなく、操作の権限も分ける。
| 操作 | AI に許可するか | 人の承認 | 監査ログ | 例 |
|---|---|---|---|---|
| 検索 | 条件付きで可 | 不要または事後レビュー | 必須 | 規程検索、FAQ 検索 |
| 要約 | 条件付きで可 | 不要またはサンプリングレビュー | 必須 | 検索結果の要約 |
| 提案 | 可 | 採用前レビュー | 必須 | 申請区分候補、問い合わせ分類 |
| 更新 | 原則不可 | 必須 | 必須 | FAQ 更新、チケット更新 |
| 送信 | 原則不可 | 必須 | 必須 | 顧客通知、承認依頼 |
| 削除 | 不可または厳格承認 | 必須 | 必須 | データ削除、権限削除 |
| 外部連携 | 個別審査 | 必須 | 必須 | SaaS connector、MCP tool 実行 |
AI が tool を使う場合、要件には「何を実行できるか」ではなく、「何を実行してはいけないか」も書く。 禁止事項が明文化されていない connector は、便利さより先に統制不備を生む。
2.3.3 利用禁止情報を要件に含める
利用禁止情報は、注意書きではなく要件である。
要件には次を含める。
- 入力フォーム、API、ログ、prompt に混入してはいけない情報。
- 混入した場合に、保存しない、処理しない、管理者へ通知する条件。
- マスキング、匿名化、要約化の責任者。
- 外部 AI、外部 SaaS、外部 connector へ送ってよい情報の境界。
- 学習利用、二次利用、ログ保存、監査閲覧に関する扱い。
「利用者が気をつける」だけでは要件にならない。検知、遮断、記録、教育、例外承認まで含めて初めて運用可能な要求になる。
2.4 Human-in-the-loop / Human-on-the-loop / Full automation を切り分ける
AI を含む要求では、自動化レベルを明示する必要がある。 自動化レベルが曖昧なまま実装すると、開発側は「自動で進む機能」を作り、運用側は「人が確認する前提」で受け取るという齟齬が起きる。
2.4.1 3つの自動化境界
| 境界 | 意味 | 適した対象 | 必須要件 |
|---|---|---|---|
| Human-in-the-loop | 実行前に人が確認し、承認しないと進まない | 高リスク操作、外部送信、権限変更、本番影響 | 承認者、承認条件、拒否時の扱い、監査ログ |
| Human-on-the-loop | 通常は自動で進むが、人が監視し、異常時に止める | 低〜中リスク分類、候補提示、内部検索、一次回答 | 監視指標、停止条件、サンプリングレビュー、escalation |
| Full automation | 人の個別確認なしで実行する | 影響が限定され、失敗時に自動回復できる処理 | 明確な許容範囲、rollback、異常検知、監査証跡 |
Full automation は「人が不要」という意味ではない。設計時に人が責任を持ち、運用時に監視と改善を行うという意味である。
2.4.2 自動化境界の判断表
| 判断軸 | Human-in-the-loop に寄せる条件 | Human-on-the-loop にできる条件 | Full automation にできる条件 |
|---|---|---|---|
| 影響範囲 | 顧客、契約、支払い、本番、法務に影響 | 社内限定で影響を検知できる | 個人・顧客・本番への影響が限定的 |
| 可逆性 | rollback が難しい | rollback は可能だが手順が必要 | 自動 rollback または再実行で回復可能 |
| データ感度 | 個人情報、契約情報、秘密情報を扱う | 社内限定情報を扱う | 公開情報または低感度データのみ |
| 説明責任 | 個別判断の説明が必要 | サンプリング説明で足りる | ルールとログで説明可能 |
| 失敗検知 | 人でないと検知困難 | 指標で異常検知可能 | 自動検知と自動停止が可能 |
この表は、実装方式を決めるためではなく、要求段階で承認者と責任境界を揃えるために使う。
2.4.3 approval と escalation
自動化境界を決めたら、approval と escalation を書く。
- 誰が承認できるか。
- どの条件なら承認不要か。
- どの条件なら Security、Legal、SRE、経営へ escalation するか。
- 承認ログはどこに残すか。
- 承認後に条件が変わった場合、誰が再承認するか。
承認は、進行を遅くするための儀式ではない。責任ある自動化を継続するための統制である。
2.5 acceptance criteria を評価可能にする
受入条件は、要件を実装可能にするだけでなく、AI 出力を採用してよいかを判断する基準である。 「精度が高い」「使いやすい」「自然に回答する」は、単独では受入条件にならない。
2.5.1 4種類の受入条件
AI を含む要求では、受入条件を最低限4種類に分ける。
| 種類 | 問い | 例 |
|---|---|---|
| 品質 | 期待する結果が出るか | テストケース30件中、必須ケースで引用付き回答を返す |
| 再現性 | 同じ条件で説明可能に再確認できるか | 評価データ、prompt、モデル設定、検索対象版数を記録する |
| 説明可能性 | なぜその回答・操作になったか説明できるか | 回答に引用、根拠、前提、未確定事項を含める |
| フェイルセーフ | 失敗時に安全側へ倒れるか | 引用なし、権限不明、個人情報混入時は回答しない |
この4種類が揃うと、AI の出力品質だけでなく、運用・監査・説明責任も確認できる。
2.5.2 悪い受入条件と良い受入条件
| 悪い受入条件 | 問題 | 良い受入条件 |
|---|---|---|
| 回答精度が高い | 精度の定義、評価対象、失敗時挙動が不明 | 評価データ50件に対し、必須 FAQ は引用付きで回答し、不明時は「回答不可」と返す |
| 自然な文章で回答する | 文章品質しか見ていない | 回答には根拠リンク、規程版数、適用範囲、例外時の問い合わせ先を含める |
| セキュリティに配慮する | 確認方法が不明 | 個人情報を含む入力は保存せず、検知時は処理停止し、監査ログに分類結果のみ残す |
| 必要に応じて人が確認する | 誰がいつ確認するか不明 | 例外判断、引用不足、契約関連質問は担当 reviewer の承認後に回答する |
| 問題があれば手動対応する | fallback が未定義 | AI 回答停止時は既存問い合わせフォームへ誘導し、SLA と担当窓口を表示する |
受入条件は、開発者だけのものではない。利用者、運用者、Security、Compliance、SRE、監査が同じ条件を見て合意できる必要がある。
2.5.3 eval plan への接続
第2章では eval plan の詳細設計までは行わない。ただし、要件段階で eval plan に渡す材料を揃える。
最低限、次を残す。
- 評価対象の業務シナリオ。
- 必須ケース、代表ケース、禁止ケース、境界ケース。
- 正解または期待出力を誰が定義するか。
- 評価データの作成、匿名化、更新責任者。
- 誤回答、回答不可、escalation、manual override の評価方法。
- 合格条件と、合格しても本番化できない条件。
この材料がなければ、第3章の eval plan や threat model は成立しない。
2.6 KPI と guardrail metric を分離する
AI 施策では、利用率、処理件数、回答時間、問い合わせ削減率などの KPI が注目される。 しかし、KPI だけで進めると、速く処理できるが誤回答が増える、問い合わせは減ったが監査できない、現場確認が増えて総コストが増えるという状態になりやすい。
2.6.1 KPI と guardrail metric の違い
| 区分 | 目的 | 例 | 意思決定での使い方 |
|---|---|---|---|
| KPI | 価値や成果を測る | 問い合わせ削減率、一次解決率、平均応答時間、申請差戻し率 | 継続投資、優先順位、改善効果を判断する |
| guardrail metric | やってはいけない状態を検知する | 引用なし回答率、個人情報検知数、approval rejection rate、fallback rate | 停止、縮退、再評価、承認見直しを判断する |
| operational metric | 運用負荷を測る | manual takeover rate、レビュー待ち時間、ログ確認工数 | 運用体制、SLA、担当者配置を判断する |
| learning metric | 改善可能性を測る | 未回答カテゴリ、FAQ 不足、問い合わせ分類の偏り | データ整備、UX 改善、教育を判断する |
KPI は加速するための指標であり、guardrail metric は止めるための指標である。両方がなければ、責任ある運用にはならない。
2.6.2 指標設計の例
社内ナレッジアシスタントの場合、指標は次のように分ける。
| 指標 | 種類 | 目標または閾値 | 判断 |
|---|---|---|---|
| 一次解決率 | KPI | 対象カテゴリで40%以上 | 価値があるかを見る |
| 平均回答時間 | KPI | 既存問い合わせより短縮 | UX 改善を見る |
| 引用なし回答率 | guardrail | 0% を目標。発生時は回答停止条件を確認 | 安全側に止める |
| 個人情報検知数 | guardrail | 1件でも検知時はログと入力経路を確認 | データ境界を見直す |
| escalation rate | operational | 高すぎる場合は要件または FAQ 不足を確認 | 自動化範囲を見直す |
| reviewer 待ち時間 | operational | SLA 超過時は体制見直し | 承認負荷を調整する |
指標は、実装後にダッシュボードへ置くだけでは遅い。要件段階で「どの指標で継続、停止、縮退、拡張を決めるか」を合意する。
2.6.3 指標の悪用を防ぐ
AI 施策では、見栄えの良い KPI が誤った行動を誘発することがある。
- 回答率を上げるために、回答不可を減らして誤回答が増える。
- 問い合わせ削減率を上げるために、利用者が諦めた件数を成功扱いする。
- 自動化率を上げるために、承認や監査を省略する。
- 平均値を良く見せるために、少数の重大失敗を隠す。
これを防ぐには、KPI と guardrail metric を同じ意思決定表に置き、guardrail 違反時は KPI が良くても停止または縮退するルールを作る。
2.7 fallback / manual override / rollback を要求に含める
AI を含む要求では、正常系よりも異常系が重要になる。 要件定義で fallback、manual override、rollback を書かないと、運用段階で「止めたいが止め方が分からない」「人が介入したが記録が残らない」「元に戻せない」という状態になる。
2.7.1 fallback
fallback は、AI 機能が使えない、または使ってはいけない状態で、利用者を安全な経路へ戻す設計である。
要件には次を含める。
- 回答不可にする条件。
- 既存業務、問い合わせ窓口、手動手順への誘導。
- fallback 時の表示文言と責任者。
- fallback 発生件数の記録方法。
- fallback が多い場合の改善判断。
例:
引用が1件も取得できない場合、AI は推測回答を返さない。
「該当規程を確認できません。経理問い合わせフォームへ進んでください」と表示し、問い合わせカテゴリ、検索語、規程版数をログへ残す。
個人情報を含む入力本文は保存しない。
2.7.2 manual override
manual override は、人間が AI の処理を止める、修正する、または別経路へ切り替える手順である。
要件には次を含める。
- 誰が override できるか。
- override の条件。
- override した場合、利用者へ何を表示するか。
- override 理由をどこへ記録するか。
- override 後に再開する条件。
manual override は、UI のボタンだけではない。権限、ログ、説明、再開条件まで含む運用要件である。
2.7.3 rollback と縮退運用
AI 機能は、モデル変更、検索対象変更、prompt 変更、connector 変更で挙動が変わる。 そのため、要件段階で rollback と縮退運用を定義する。
| 変更 | rollback 対象 | 縮退運用 |
|---|---|---|
| prompt 変更 | 前版 prompt、出力 schema | 旧 prompt へ戻す。高リスクカテゴリは回答停止 |
| 検索対象変更 | document index、版数 | 前版 index へ戻す。更新文書のみ一時除外 |
| tool 権限変更 | connector 権限、approval 設定 | tool 実行を停止し、検索・要約のみへ縮退 |
| モデル変更 | model / provider 設定 | 前版設定へ戻す。回答不可条件を強める |
| データ分類変更 | 入力許可範囲、保存条件 | 高感度データを入力不可に戻す |
rollback を「設計で考えること」として後回しにしない。rollback できない要求は、本番化前の承認条件を厳しくする必要がある。
2.8 成果物として合意する
要件定義の成果は、会議で合意した雰囲気ではない。後工程が参照できる成果物である。 本章では、最低限次の5つを残す。
2.8.1 requirements brief
requirements brief は、要求の核を1つにまとめる。
Title:
Background:
Users / stakeholders:
Problem statement:
Expected outcome:
Scope:
Non-goals:
Data sources:
Data not allowed:
Automation boundary:
Acceptance criteria:
Guardrail metrics:
Fallback / manual override:
Open questions:
Decision owner / reviewers:
この形式は、Issue、ADR、PR 本文、設計レビュー資料へ転用できる。
2.8.2 acceptance criteria
acceptance criteria は、実装完了の条件ではなく、要求が安全に受け入れられる条件である。
Given: 社内規程と FAQ が検索対象に登録されている
When: 利用者が経費精算の対象可否を質問する
Then: 回答は規程名、版数、引用箇所、適用範囲、例外時の問い合わせ先を含む
And: 引用が取得できない場合は推測回答を返さない
And: 個人情報を検知した場合は処理を停止し、本文を保存しない
And: 例外判断が必要な場合は担当 reviewer へ escalation する
この粒度であれば、テスト、レビュー、運用確認へ接続できる。
2.8.3 assumption & open question log
open question は、曖昧さを放置するためではなく、確認責任を明確にするために残す。
ID: Q-02
Question: 部門別の規程閲覧制限は必要か
Impact: access control、検索対象、監査ログ、利用者表示
Owner: Security
Due: 2026-06-07
Decision needed before: 本番化判定
Current status: 未確認
未確認事項が残っていても、PoC は進められる場合がある。ただし、その場合は「本番化判断前に必要な確認」として明記する。
2.8.4 data / permission boundary table
データと権限の境界は、要件の中心成果物である。
| Data / action | Classification | Allowed use | Not allowed | Approval | Audit |
|---|---|---|---|---|---|
| 社内規程 | 社内限定 | 検索、引用、要約 | 外部公開、学習利用 | Product Owner | 検索・回答ログ |
| 問い合わせ本文 | 個人情報を含む可能性 | 分類のみ。本文保存なし | 外部 AI 送信、長期保存 | Security | 分類結果のみ |
| FAQ 更新 | 社内限定操作 | 草案作成 | 自動公開 | 担当 reviewer | PR / 変更ログ |
| 本番 connector | 高リスク操作 | 検索のみ | 更新、送信、削除 | SRE / Security | tool 実行ログ |
この表は、第3章の tool approval matrix、threat model、AI system ADR へ接続する。
2.8.5 stakeholder alignment checklist
要求を実装へ渡す前に、関係者と次を確認する。
- 利用者、運用者、承認者、影響を受ける部門を分けた。
- 問題設定、期待成果、非目標を合意した。
- データ分類、入力禁止情報、保存条件を確認した。
- Human-in-the-loop / Human-on-the-loop / Full automation の境界を決めた。
- acceptance criteria に、品質、再現性、説明可能性、フェイルセーフを含めた。
- KPI と guardrail metric を分け、停止条件を決めた。
- fallback、manual override、rollback を定義した。
- decision owner、reviewer、approval、escalation 先を明記した。
- open question に owner と期限を付けた。
- 次章で ADR、eval plan、threat model へ渡す論点を整理した。
チェックリストは、完璧な合意を保証しない。しかし、合意不足を早く見つけるための実務的な境界線になる。
まとめ
要件定義は、AI 機能を作る前に、問題、データ、権限、自動化、受入条件、失敗時挙動を揃える工程である。 AI を含む業務・プロダクト・社内ツールでは、要求が曖昧なままでも、AI がもっともらしい画面や回答を作れてしまう。 だからこそ、requirements brief、acceptance criteria、assumption & open question log、data / permission boundary table、stakeholder alignment checklist を成果物として残す必要がある。
要点：
- 問題設定、非目標、要求境界を分け、解決策先行の要件定義を避ける。
- データ分類、アクセス権、利用禁止情報、approval、audit を要件段階で定義する。
- Human-in-the-loop / Human-on-the-loop / Full automation を、影響範囲、可逆性、説明責任で切り分ける。
- acceptance criteria は、品質、再現性、説明可能性、フェイルセーフを含めて評価可能にする。
- KPI と guardrail metric を分離し、KPI が良くても guardrail 違反なら停止または縮退する。
- fallback、manual override、rollback は設計ではなく要件として扱う。
次章では、これらの要求境界をもとに、通常機能、検索付き機能、workflow / agent の選択、AI system ADR、threat model、eval plan へ進む。
次に読む： 第3章：アーキテクチャ設計の意思決定 / 目次（トップ）
この章のまとめとチェックリスト
この章のまとめ
- AI を含む要件定義では、顧客言語から技術仕様への翻訳だけでなく、データ、権限、自動化、失敗時挙動、説明責任を同時に定義する必要がある。
- 問題設定の誤り、評価不能な要件、データ境界の欠落、承認者不明、失敗時挙動の欠落が、AI 施策の典型的な失敗原因になる。
- 要件は、requirements brief、acceptance criteria、assumption & open question log、data / permission boundary table、stakeholder alignment checklist として残す。
この章を読み終えたら確認したいこと
- 最近扱った AI 機能または社内ツール要求について、requirements brief を1つ作成したか。
- 「精度が高い」「便利にする」ではなく、評価データ、合格条件、回答不可条件を書けたか。
- 利用データ、入力禁止情報、権限、ログ、承認者を表にしたか。
- Human-in-the-loop / Human-on-the-loop / Full automation のどれに該当するかを説明できるか。
- fallback、manual override、rollback を要件として書けたか。
関連する章・付録
- 問い、根拠、判断責任の整理は、第1章：エンジニアの思考 OS を参照する。
- 要件から設計判断へ進む場合は、第3章：アーキテクチャ設計の意思決定 で AI system ADR、threat model、eval plan に接続する。
- 成果物テンプレートは、付録A：実務成果物テンプレート集 を参照する。
- 要求境界を実例で確認する場合は、付録B：ケーススタディ の社内ナレッジアシスタントを参照する。
- 変化しやすい価格、UI、API 細部、モデル名を要件へ固定しすぎない基準は、付録D：更新方針と更新履歴 を参照する。
- AI 協働の成果物連鎖は、AI 協働の標準手順（SOP） を参照する。