AI導入の要件定義は、ツールを選ぶ前に「目的・入力・出力・権限・例外・評価基準」の順で決めます。本記事では、AIで要件定義書を作る方法ではなく、AIを業務へ導入するプロジェクトを対象に、業務の切り出し、人との責任分界、PoCから本番導入までの判断手順を解説します。
AI導入の要件定義とは何を決める作業か
AI導入の要件定義は、AIに任せる範囲と、人が判断・承認する範囲を文書化する作業です。モデルやツールの性能だけを検討するのではなく、業務上の目的、利用データ、責任、例外時の動線、評価方法までを一体で定義します。
CREATREE編集部では、AI導入時に決める内容を次の6要素に整理しています。この分類と順序は公的ガイドラインの項目を転記したものではなく、経営・現場・IT部門が同じ枠組みで検討するための実務上の整理です。
- ①目的：解決する業務課題、対象利用者、改善したい指標を決める
- ②入力：使用するデータ、その取得元、品質、利用権限、送信先を決める
- ③出力：期待する成果物、形式、必須項目、禁止事項を具体例で示す
- ④権限：AIが提案・作成・実行できる範囲と、人の承認が必要な範囲を決める
- ⑤例外：誤り、判断不能、遅延、想定外入力が起きた場合の停止先と戻し先を決める
- ⑥評価基準：評価データ、測定方法、合格条件、未達時の対応を決める
6要素のうち、権限・例外・評価基準が空欄なら、PoCや製品選定へ進む前に業務設計を続ける必要があります。「AIがすること」と同時に「AIがしないこと」を書ける状態が目安です。
6要素を要件定義のたたき台にする手順
- 対象業務と利用者を一つに絞る：「問い合わせ対応全般」ではなく、「社内規程に関する一次回答の下書き作成」のように処理単位まで狭めます。
- 6要素の記入欄を用意する：最初から完成させようとせず、不明な欄を可視化するために空欄のまま作成します。
- 現場・IT・管理部門で記入する：現場は業務ルール、IT部門はデータとシステム、法務・情報セキュリティ部門などは利用条件とリスクを確認します。
- 埋まらない項目を課題化する：未確認のデータ権限、曖昧な承認者、用意できない評価データなどを、担当者と期限のある課題に変えます。
誤りが重大な損害、権利侵害、法的影響につながり得る業務では、自動実行を前提に要件定義を進めないことが重要です。AIを補助・支援に限定し、人の承認を必須にする案から検討してください。具体的な法的判断は所管部門または専門家へ確認します。
現状業務を分解してAIの適用範囲を切り出す
要件定義の前に、現状業務を「入力・処理・判断・出力・例外」に分解します。判断基準や例外を説明できない業務は、AIの適用範囲や評価方法も決められないため、まず現場業務の可視化が必要です。
業務分解シートの作り方
業務名だけではなく、実際の1件が開始して完了するまでを追います。担当者へのヒアリングでは「通常はどうするか」に加え、情報不足、形式不備、判断が割れるケースなども確認してください。
- 入力：受け取る文書、画像、申請内容、顧客情報、参照データ
- 処理：転記、検索、分類、要約、計算、照合などの作業
- 判断：担当者が基準に照らして選択、承認、優先順位付けを行う箇所
- 出力：回答文、登録データ、判定結果、報告書、次工程への指示
- 例外：情報不足、重複、矛盾、対象外、期限超過、システム障害への対応
AI適用の可否を判断する4つの観点
AIを使えるかどうかは、作業量や技術的な実現性だけでは決まりません。次の観点を一つずつ確認し、リスクが高い部分は人の判断として残します。
- 誤りの影響：修正可能な下書きの誤りか、顧客・契約・会計処理などへ直接影響する誤りか
- 説明責任：判断理由を社内外へ説明する必要があるか、必要な記録を残せるか
- データ利用可否：対象データを予定するAI環境へ入力・送信・保存できるか
- 人による確認可能性：担当者が妥当性を判断できるか、確認工数を運用へ組み込めるか
AIの適用範囲を切り出す手順
初回の対象には、一定の繰り返しがあり、判断基準を言語化でき、現状値を測定できる業務が向いています。複数部門をまたぐ大きな業務よりも、担当者と成果を特定できる一つの処理を選ぶほうが、効果と問題点を切り分けやすくなります。
- 現場担当者に実際の処理を1件実演してもらい、使用データと操作を記録する
- 判断が入る箇所に印を付け、判断理由を担当者の言葉で書き出す
- 各判断基準を第三者が再現できる文章や条件に変換する
- 言語化できた範囲をAIの候補とし、説明できない範囲は人の判断として残す
- 処理時間、件数、手戻り件数など、導入前の状態を測定する
暗黙知が中心の業務を対象にしたい場合は、先に熟練者が判断した事例と理由を記録します。評価用の正解例を用意できない段階では、本番導入を急がず、判断記録の収集を要件に含めるべきです。
対象業務、利用者、導入前の状態、判断基準、代表的な例外を説明できない場合は、AIの方式や製品を比較する段階ではありません。先に現状業務の記録と分解を進めます。
入力・出力・権限を定義する
入力要件はデータ名だけでなく、取得元、利用根拠、送信先、保存、アクセス権限まで定義します。出力は良い例と不可例で具体化し、権限はAIが提案するだけなのか、システム上の処理まで実行できるのかを段階で決めます。
入力データ要件を定義する
入力データを一覧化し、業務上必要だから利用できると即断しないことが重要です。個人情報、顧客秘密、営業秘密、著作物などを含む可能性がある場合は、利用目的、契約、社内規程、AIサービスのデータ取扱条件を確認します。
- データの名称、形式、取得元、更新頻度が記載されている
- 欠損、重複、表記揺れ、古い情報をどのように扱うか決まっている
- 入力・送信できない情報が明文化されている
- 外部サービスへ送信する場合の利用条件を確認している
- 保存期間、削除方法、閲覧者、アクセス権限が決まっている
- 入力・出力・操作ログに残す情報とマスキング対象が決まっている
外部の生成AIサービスへ個人データを入力する場合は、提供者が入力情報を機械学習へ利用するかどうかなど、サービスの取扱条件によって確認事項が変わります。利用規約やデータポリシーは更新される可能性があるため、確認した日付と対象プランも要件定義書へ記録します。
期待する出力をサンプルで定義する
「正確な要約」「自然な回答」といった形容詞だけでは、発注者、利用者、開発者の解釈が一致しません。実際の入力に対して、少なくとも良い例、判断が分かれる境界例、使用できない例を作ります。
- 良い例：必須情報、形式、文章量、根拠の示し方を満たす出力
- 境界例：人による追加確認や修正があれば利用できる出力
- 不可例：根拠のない断定、禁止表現、情報欠落、規定外の処理を含む出力
出力要件には、必須項目、文字数、形式、参照可能な情報源、禁止事項、判定不能時の表現を含めます。AIが回答できない場合に、無理に推測せず「確認が必要」と返す形式も定義してください。
AIの権限と人の責任を分ける
権限は「AIを使うか使わないか」の二択ではありません。CREATREE編集部では、業務リスクと検証結果に応じて、次のように委ねる範囲を段階的に広げる方法を提案しています。
| 段階 | AIの役割 | 人の役割 |
|---|---|---|
| 提案 | 候補、要約、分類案などを提示する | 採用する案を選び、内容を確定する |
| 下書き作成 | 回答文や登録内容の下書きを作る | 内容を確認・修正し、承認する |
| 段階 | AIの役割 | 人の役割 |
|---|---|---|
| 承認付き実行 | 人の承認後にシステム上の処理を実行する | 実行前に対象と内容を確認する |
| 条件付き自動実行 | 定められた条件と権限の範囲内で処理する | 監視、停止、例外対応、最終責任を担う |
実行権限を与える場合は、対象システム、操作可能なデータ、金額や件数の上限、実行可能な時間帯、禁止操作を具体化します。「担当者が確認する」ではなく、承認者、運用責任者、障害時の連絡先を役割名で特定する必要があります。
AIの出力が確認なしで次工程へ進むなら、誤処理を止める技術的な制御と、停止を判断する運用責任者の両方が必要です。どちらか一方だけでは責任分界が成立しません。
例外処理とフォールバックを設計する
AI導入では、正常に動く場合よりも、誤りや判断不能が起きた場合の動線を先に決めることが重要です。「迷ったら止まる」「判定不能を返す」「人へ引き継ぐ」の3点を、業務フローとシステムの両方へ組み込みます。
例外を4類型で洗い出す
- 誤出力：事実と異なる回答、誤分類、計算間違い、業務ルール違反が発生した
- 判断不能：情報不足、複数解釈、参照情報の矛盾により結論を出せない
- 応答不能・遅延：外部サービス、ネットワーク、連携システムの障害で処理できない
- 想定外入力：未対応形式、対象外の依頼、破損データ、禁止情報が入力された
各例外には、検知方法、停止条件、差し戻し先、代替手順、記録項目、再発防止を担当する役割を紐づけます。AIの内部的な確信度だけに頼らず、必須項目の欠落や数値の不一致など、業務ルールによる検知も併用します。
停止・エスカレーション条件を決める
- 過去事例や現場ヒアリングから、例外4類型の具体的なシナリオを作る
- システムで検知できるものと、人が確認すべきものを分ける
- 処理を停止する条件と、継続してよい条件を明文化する
- 差し戻し先となる担当者と、AIを使わない代替手順を決める
- 発生日時、入力、出力、判断、修正内容を記録する範囲を決める
- 例外件数や重大な誤りを再点検する頻度と責任者を決める
人の確認を前提にする場合は、その工数も要件に含めます。確認作業が現場の処理能力を超えると、未確認のまま利用される、あるいはAI導入前より作業時間が増える可能性があります。
AIの出力を人が確認する設計でも、確認者が内容を無批判に受け入れれば安全性は確保できません。確認基準、参照情報、差し戻し条件を明文化し、承認操作だけが形式的に残る状態を避けてください。
運用後の変化を監視する
入力データ、業務ルール、利用者、外部モデルの仕様が変われば、導入時の評価結果がそのまま維持されるとは限りません。エラー率、判定不能率、手修正率、処理時間、例外の種類を継続的に記録し、基準を超えた場合は自動化範囲を縮小するか、要件定義へ戻ります。
評価基準は精度だけでなく業務の合否条件として設計する
AIの評価を一つの「精度」にまとめると、業務で使えるか判断できません。正確性、網羅性、安定性、業務適合性を分け、評価データ、測定方法、合格ラインを検証開始前に決めます。
評価軸を4つに分ける
- 正確性：出力内容や判定が、正解例または参照情報と一致しているか
- 網羅性：業務に必要な項目や重要情報が欠けていないか
- 安定性：同一または同等の入力に対して、許容範囲内の出力が得られるか
- 業務適合性：形式、必須項目、禁則、承認フローなどの業務ルールを守っているか
業務によって評価指標は変わります。例えば、見落としの影響が大きい分類業務では、全体の正解率だけでなく、見落としてはいけない対象をどの程度検出できたかを確認する必要があります。ベンダーから「精度」の数値を提示された場合は、指標の定義、評価対象、使用データ、失敗事例の内訳を確認してください。
評価データと合格ラインを先に決める
- 実運用を代表する事例を選ぶ：通常事例だけでなく、情報不足、境界事例、誤りの影響が大きい事例を含めます。
- 正解と許容範囲を決める：正解が一つでない場合は、許容できる表現や人へ回すべき条件を定義します。
- 評価担当者を決める：業務知識を持つ担当者と、プロジェクトの最終判断者を分けて明記します。
- 軸ごとの合格条件を定める：平均値だけでなく、重大な誤りが一件でもあれば不合格とする条件などを設定します。
- 未達時の処理を決める：再設計、対象縮小、追加検証、中止のどれを選ぶか、期限とともに定義します。
形式、文字数、必須項目、禁止語、参照元との一致など、ルールで判定できる項目は機械的に確認できます。人の評価は、文脈上の妥当性、伝わりやすさ、業務上のニュアンスなどに絞ると、評価の再現性と運用負荷を管理しやすくなります。
合格ラインは「高い精度を目指す」という目標ではなく、誤りが発生した場合の影響と、人が修正・復旧できる範囲から逆算します。平均値が高くても、重大な誤りを許容できなければ本番条件は満たしません。
PoC・限定導入・本番導入を段階的に判断する
PoCの目的はAIを成功させることではなく、続行・再設計・中止を判断する材料を集めることです。技術的に出力できるだけでは本番へ進まず、データ、運用、例外対応、責任、費用を含めて段階ごとに判定します。
| 段階 | 主な目的 | 次段階へ進む条件 |
|---|---|---|
| PoC | 限定したデータと範囲で、実現可能性と評価方法を検証する | 評価データ、合否条件、主要な例外、現場の確認工数を把握できた |
| 限定導入 | 実際の利用者と業務環境で、運用負荷、安全性、効果を確認する | 権限制御、確認手順、停止、代替運用、責任者が機能した |
| 段階 | 主な目的 | 次段階へ進む条件 |
|---|---|---|
| 本番導入 | 対象範囲を定めて継続運用する | 監視、復旧、費用管理、定期評価、要件見直しの体制が整備された |
PoC開始前の確認事項
- 解決する業務課題と対象利用者を一文で説明できる
- 対象範囲が一つの業務または処理単位に絞られている
- 必要なデータを取得・利用できることを確認している
- 良い出力、境界例、不可例を用意している
- 現場担当者、技術担当者、最終判断者が決まっている
- 評価軸、合格条件、検証期限、中止条件が決まっている
限定導入から本番へ進む確認事項
- 実運用に近いデータで評価基準を満たしている
- 人による確認・修正を含めても業務上の効果が見込める
- 入力禁止情報、アクセス権限、ログ、保存・削除方法が定義されている
- 誤出力、判断不能、障害、想定外入力の処理フローがある
- 停止、代替運用、復旧、関係者への連絡手順がある
- 運用責任者、最終責任者、定期レビューの担当者がいる
- 利用量の増加を含む費用と、保守・確認工数を把握している
要件を満たさない場合は、AIの調整だけを続けるのではなく、対象業務の縮小、権限の引き下げ、入力データの見直し、評価基準の再設計へ戻ります。評価データを用意できない場合は、本番導入ではなく、データと判断記録を収集する限定運用から始めるのが適切です。
まとめ
AI導入の要件定義は、ツールの仕様を決めるだけでなく、AIと人の役割を業務として設計する作業です。目的・入力・出力・権限・例外・評価基準を一つの資料にまとめ、未確定項目を解消してから段階的な検証へ進みます。
最初に行うべきことは、対象業務を一つ選び、「入力・処理・判断・出力・例外」に分解することです。そのうえで、利用可能なデータ、期待出力の具体例、人の承認範囲、停止と差し戻しの動線、複数軸の合格条件を記入します。
6要素のいずれかを説明できない場合は、ツール選定や本番稟議を急がず、業務整理へ戻る必要があります。要件を満たした後も、PoC、限定導入、本番導入の各段階で権限とリスクを見直し、問題があれば自動化範囲を縮小できる状態を維持してください。
対象業務を分解できない、評価基準や例外処理を社内だけで決められない、複数部門の合意形成が進まない場合は、CREATREEへAI導入の要件整理からご相談ください。
よくある質問
- AI導入の要件定義は、通常のシステム要件定義と何が違いますか？
-
AIの出力には一定の不確実性があるため、期待する機能だけでなく、評価データ、許容できる誤り、判断不能時の動作、人の確認範囲、運用後の監視まで定義する点が異なります。通常の機能要件・非機能要件に加え、AIへ任せる権限と例外時の責任分界を業務フローとして設計します。
- AIの精度要件はどのように決めればよいですか？
-
一律の目標値ではなく、誤りの影響と人が修正できる範囲から逆算します。正確性だけでなく、情報の欠落、出力の安定性、業務ルールの順守を分け、重大な誤りに対する個別の不合格条件も設定してください。
- PoCを始める前に最低限決めるべき項目は何ですか？
-
対象業務と利用者、入力データの利用可否、期待出力の例、AIの権限、人の承認者、主要な例外、評価データ、合否条件、検証期限です。これらを決められない場合は、PoCより先に業務分解とデータ確認を行います。
- AIの誤回答や判断不能が発生した場合はどう設計しますか？
-
誤りや判断不能を検知する条件、処理を止める条件、人へ引き継ぐ条件、差し戻し先、代替手順、記録項目を決めます。重大な影響がある業務では、AIから直接実行させず、人の承認を必須にします。
- 自社だけで要件定義できる場合と、外部支援を検討すべき場合の違いは何ですか？
-
対象業務を分解し、データの利用可否、評価基準、例外処理、責任分界を社内で決められる場合は、自社主導で進められます。これらを処理単位まで具体化できない場合や、複数部門の合意形成が進まない場合は外部支援を検討してください。外部へ依頼しても、業務上の最終判断を担う社内オーナーは明確にする必要があります。
著者プロフィール
この著者の記事一覧へ
著者
藤村 隼人
CREATREE合同会社 代表社員／NSJAPAN CDO
HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。