生成AI導入の要件定義とは？決めるべき5つの項目

著者 藤村 隼人 CREATREE合同会社 代表社員／NSJAPAN CDO CREATREE合同会社の代表社員。生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。

著者

藤村 隼人

CREATREE合同会社 代表社員／NSJAPAN CDO

HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。

生成AI導入の要件定義では、製品選定より先に、①業務、②データ・安全、③システム・非機能、④運用・ガバナンス、⑤評価・受入の5領域を定義します。本記事では、AIに任せる範囲と人間の承認点、PoCの合否・停止条件、条件付き導入や見送りまでの判断方法を整理します。

生成AI導入の要件定義とは何か｜「要件定義書をAIで作る」話と混同しない

生成AI導入の要件定義とは、対象業務、利用データ、システム構成、人間の関与、運用責任、受入条件を事前に合意する工程です。生成AIを使って要件定義書の作成やレビューを効率化する方法とは、検討対象が異なります。

検索時には「生成AIを自社へ導入するための要件定義」と「生成AIを使ってシステム開発の要件定義書を作る方法」という2つの意図が混在します。後者ではプロンプトやレビュー方法が中心になりますが、本記事が扱うのは前者です。どの生成AIを、誰が、どの業務で、どの条件なら利用できるかを決めることが主題であり、プロンプト集は対象外とします。

生成AIは、同じ入力でも具体的な出力が変わることがあり、個々の回答を事前に決定論的に予測することが困難です。事実と異なる内容や期待した形式と異なる回答を生成する可能性もあるため、従来のシステムで重視されてきた機能要件や性能要件だけでは十分ではありません。どの程度の誤りを許容するか、誤りを誰が発見するか、回答できない場合にどう処理するかまで受入要件として定義する必要があります。

製品比較やPoCを先行させると、デモでは高品質に見えても、実データを入力できない、担当者による全件確認が必要で費用対効果が合わない、監査ログが不足して本番利用できないといった手戻りが起こります。要件定義は製品を選ぶための前提であり、選んだ製品を正当化するための後付け資料ではありません。

本記事が扱う5つの要件領域の全体像

要件の抜け漏れを防ぐには、業務上の目的から本番運用までを同じ枠組みで確認します。各領域の主管部門を固定するのではなく、最終判断者とレビューに参加する部門を分けておくことが重要です。

要件領域	定義する内容	主に関与する部門	未定義のまま進めた場合の失敗
業務要件	導入目的、対象業務、利用者、入力・出力、例外処理、AIへ任せる範囲	事業部門、業務責任者、経営層	AIを使うこと自体が目的となり、業務効果を判定できない
データ・安全要件	入力可能な情報、学習利用、保存・削除、処理地域、権利、禁止事項	情報システム、セキュリティ、法務	機密情報の不適切な入力や既存契約との不整合が発生する

要件領域	定義する内容	主に関与する部門	未定義のまま進めた場合の失敗
システム・非機能要件	認証、権限、ログ、連携、可用性、応答性、費用、障害時の代替手段	情報システム、開発・運用部門	本番環境の統制や既存システムとの連携が成立しない
運用・ガバナンス要件	責任者、承認経路、教育、監視、変更管理、事故対応、規約確認	経営層、情報システム、法務、各事業部門	導入後の問題が担当者任せになり、利用実態を把握できない

要件領域	定義する内容	主に関与する部門	未定義のまま進めた場合の失敗
評価・受入要件	評価データ、品質指標、測定方法、合格条件、停止条件	業務責任者、利用部門、開発・品質管理部門	PoCの結果を都合よく解釈し、本番導入を判断できない

この5分類は、公式ガイドラインの項目をそのまま転記したものではなく、生成AI導入の意思決定に使いやすいようCREATREE編集部が整理したものです。実際の要件定義では、自社の業種、適用法令、既存のセキュリティ基準、契約条件に合わせて項目を追加してください。

要件定義に入る前に決める「導入目的と対象業務」

最初に決めるのは製品名ではなく、誰のどの業務課題をどこまで解決するかです。候補業務ごとに利用者、入力、出力、例外処理を可視化し、生成AIを使わない場合も含めて比較します。

「全社で生成AIを活用する」「業務を効率化する」といった表現だけでは、必要な品質も安全性も決まりません。例えば問い合わせ対応に利用する場合でも、担当者向けの回答案作成と、顧客への自動回答では、誤回答の影響、人間による確認、必要なログの水準が異なります。

初期整理では、「何の業務に」「どのような生成AI機能を」「誰が使うか」の3軸で利用シナリオを書き出します。そのうえで、現行業務の開始条件、参照情報、入力データ、期待する出力、後続処理、頻出する例外を確認します。正常な業務フローだけでなく、情報が不足している場合や担当者の判断が分かれる場合も対象にすることが重要です。

生成AIを導入しない判断も比較対象です。人間が短時間で処理でき、AI出力の検証に同程度の時間がかかる業務や、誤りによる損失が大きいのに根拠確認ができない業務は、見送りが合理的な場合があります。一方、過度な一律禁止には生産性向上や知見獲得の機会を失う側面があるため、低リスク業務から限定的に始める選択肢も検討します。

対象業務の優先順位を決める判断軸

優先順位は、期待効果の大きさだけで決めません。便益、誤りの影響、データの機密性、検証可能性、運用負荷を組み合わせ、導入後も組織として管理できる業務を選びます。

• 業務効果の見込み：処理時間の短縮、品質の安定、対応量の増加など、解決したい課題とのつながりが説明できるか
• 誤りの許容度：誤回答や不適切な出力が発生した際、顧客、従業員、事業へ与える影響を許容できるか
• データの機密性：個人情報、顧客秘密、未公開情報、ソースコードなどを入力する必要があるか
• 人間による検証可能性：担当者が妥当性を確認でき、検証に必要な知識と時間を確保できるか
• 根拠の確認可能性：回答の参照元を追跡し、一次情報と照合できるか
• 代替手段の有無：障害や品質低下が起きたとき、従来手順へ戻せるか

各軸の重みは業務によって異なるため、一律の合格点は設けません。社内のアイデア出しは誤りの影響が限定的ですが、契約判断や顧客への確定回答では、期待効果が大きくても厳格な検証と承認が必要です。

対象業務を「AIで実行できそうか」ではなく、「誤りが起きても人と運用で管理できるか」という観点から選ぶと、PoC後の本番移行を判断しやすくなります。

データ・安全要件｜入力してよい情報と、ベンダー規約で確認すべき項目

入力情報の可否は、サービス名だけでは判断できません。入力データの学習利用と、ログや会話履歴としての保存を分けて確認し、利用プラン、契約、設定を特定したうえで判断します。

生成AIへ入力した情報が外部へ渡る経路は一つではありません。モデルやサービスの改善に入力データが利用される問題と、学習には使われなくても事業者側のログや会話履歴として保存される問題は別です。「学習に利用しない」という説明だけを確認しても、保存期間、削除方法、事業者内のアクセス権限が分からなければ、自社の安全要件を満たすとは限りません。

個人データを本人の同意なく外部の生成AIサービスへ入力し、その情報が回答生成以外の目的で取り扱われる場合などには、個人情報保護法上の検討が必要になる可能性があります。委託に該当するか、外国にある第三者への提供に関する確認が必要か、どの安全管理措置を講じるかは、利用形態や契約内容によって変わります。実際の適用可否は、自社の法務・個人情報保護担当者や、必要に応じて専門家へ確認してください。

顧客から預かった情報を扱う場合は、法令だけでなく既存契約との整合も確認します。秘密保持、第三者提供、再委託、クラウド利用、国外移転に関する条項と、AIサービスの利用規約やデータ処理条件が矛盾していないかをレビューします。要件定義書には、単に「機密情報は禁止」と書くのではなく、どの情報分類を、どのプランへ、どの設定で入力できるかを記載します。

契約前に確認するデータ取扱い項目

同じサービス名でも、個人向け、法人向け、APIでは適用規約やデータ利用条件が異なる場合があります。「どのサービスか」に加えて、「どの契約主体が、どのプランと機能を、どの規約の下で使うか」まで特定してください。

• 入力データがモデル学習やサービス改善に利用されるか、オプトアウトできるか
• 会話、ファイル、操作ログの保存期間と削除手段
• ログの取得範囲、管理者の閲覧権限、エクスポート可否
• データを処理・保管する国や地域、再委託先の取扱い
• 管理者によるアカウント統制、アクセス制御、監査の可否
• 入力情報と出力物の知的財産権、利用権の帰属
• 第三者の権利を侵害した場合の責任分担と補償範囲
• 禁止用途、商用利用の可否、利用量や機能に関する制限

確認結果は、規約名、対象プラン、確認日、確認担当者とともに記録します。モデル追加、メモリ機能、外部ツール連携などによってデータの流れが変わる可能性があるため、導入時だけでなく変更時にも再確認できる要件にします。

個人アカウント利用とシャドーAIを要件段階で塞ぐ

組織が承認していない個人アカウントや外部ツールの利用は、入力情報、適用規約、保存先、利用者を把握できない状態を生みます。要件定義の段階で、利用可能なツール、プラン、アカウント、端末、申請方法を限定することが必要です。

「生成AIを全面禁止する」だけでは、現場の必要性が残り、把握できない利用を招く場合があります。禁止事項と同時に、承認済みツールで入力できる情報、安全な匿名化・マスキングの方法、例外申請の経路を提示してください。

退職・異動時のアカウント停止、外部共有設定、利用ログの確認責任者も要件に含めます。個人の判断へ依存させず、技術的な制御と利用ルールを組み合わせることがシャドーAI対策の基本です。

人間の関与設計｜AIに任せる範囲と確認・承認を必須にする範囲

生成AIの出力を常に正しいとみなさず、人間が確認できる業務フローを設計します。誤りの影響が大きい業務では、確認者、確認対象、参照する根拠、承認後に実行できる処理まで明文化します。

人間による確認を「必要に応じて行う」とだけ書くと、繁忙時に省略されたり、確認範囲が担当者ごとに変わったりします。要件定義書には、「AIが回答案を生成し、担当者が一次情報と照合した後、承認者が確定する」のように、AIの処理と人間の責任を業務フロー上で分けて記載します。

確認工程を設けるだけでなく、人間が実際に検証できることも条件です。大量の出力を少人数で全件確認する設計では、期待した時間短縮を得られない可能性があります。確認時間をPoCで測定し、全件確認、サンプリング確認、特定条件でのエスカレーションのどれが妥当かを判断します。ただし、重大な誤りを見逃せない業務では、サンプリングだけで十分かを慎重に検討する必要があります。

社内のアイデア出しや文章の表現案など、出力がそのまま意思決定や外部対応に使われない用途は、比較的簡易な要件から開始できます。一方、法務、人事、医療、金融、安全に関わる判断、顧客への確定回答、個人情報を用いた処理では、専門部門の確認と、影響度に応じた厳格な人間承認を原則とします。AIによる自動実行を検討する場合は、実行権限と影響範囲を限定し、停止手段を用意する必要があります。

要件定義書に書き込む「AIが答えられない場合」の挙動

生成AIが適切に答えられない状況は、例外ではなく通常運用の一部として設計します。未定義のまま本番へ進むと、無理に回答を生成するのか、処理を停止するのかが担当者判断に依存し、事故時の初動も遅れます。

• 情報不足や根拠不足など、所定の条件に該当した場合のフォールバック動作
• 回答不能時に利用者へ表示する内容と、再入力を求める条件
• 誤情報や不適切な出力が判明した場合の訂正、影響確認、報告フロー
• 担当者、管理者、法務、セキュリティ部門などへのエスカレーション条件
• 外部公開や自動実行を停止するための権限と操作方法

「分からないと回答する」「人間へ引き継ぐ」「参照元を提示できない場合は確定回答しない」といった挙動を、テスト可能な形で記載します。責任分界はAIと人間の間だけでなく、利用部門、システム管理者、ベンダーの間でも定義してください。

システム・非機能要件と提供形態の選び方

SaaS型、API利用、自社・専用環境の選択は、機能数ではなくデータ、安全性、連携、運用能力から決めます。採用前に権限、ログ、可用性、費用、モデル変更への対応を同じ条件で比較します。

非機能要件では、SSOや多要素認証、利用者・部署単位のアクセス制御、監査ログ、データ暗号化、障害時の復旧方法を確認します。業務を止められない場合は、可用性やSLAだけでなく、サービス停止時に従来業務へ戻れるか、代替環境へ切り替えられるかも要件になります。

既存の業務ツールと連携する場合は、API仕様、認証方式、レート制限、データ形式、タイムアウト時の処理を定義します。生成AIへ社内データを参照させる場合は、元システムのアクセス権が検索結果や回答にも引き継がれるかを確認し、権限のない情報が回答へ混入しないようにします。

費用はライセンス単価だけでは決まりません。APIの従量課金、データ検索や保存に使う周辺基盤、開発・監視、利用者教育、人間による確認、障害対応まで含めて継続費用を見積もります。モデルの更新によって出力品質や料金、利用可能な機能が変わる場合に、誰が変更を検知して再評価するかも決めておきます。

提供形態別の要件適合を比較する

提供形態にはそれぞれ異なる統制方法と運用負荷があります。機密性が高いという理由だけで自社構築を選ぶのではなく、自社が継続的に保守・監視できるかまで比較してください。

比較軸	SaaS型の法人プラン	API利用	自社・専用環境での構築
データ取扱いの制御	提供プランと設定の範囲で制御する	アプリ側で入力制御や保存方針を設計しやすい	構成に応じて高い制御が可能だが、自社責任が広い
権限・ログ管理	管理者機能の充実度に依存する	自社の認証・監査基盤へ統合しやすい	設計と実装を自社側で行う必要がある

比較軸	SaaS型の法人プラン	API利用	自社・専用環境での構築
既存システム連携	標準連携機能の範囲に限定されやすい	業務フローへ組み込みやすい	自由度は高いが開発・保守負荷も大きい
初期構築負荷	比較的小さい	アプリ開発と安全対策が必要	基盤、モデル、監視を含む構築負荷が大きい

比較軸	SaaS型の法人プラン	API利用	自社・専用環境での構築
継続費用の性質	利用者数に応じた固定費が中心になりやすい	利用量に応じた従量費と保守費が中心になりやすい	インフラ、保守、専門人材の費用が発生する
向く業務	文章作成や情報整理などの共通業務	既存アプリへの組込みや定型フローの自動化	独自要件や高度な隔離・制御が必要な業務

表は一般的な傾向であり、特定製品の仕様を示すものではありません。同じ提供形態でも、ベンダー、契約プラン、提供地域、管理機能によって条件が異なります。採用時には公式の規約、セキュリティ資料、API仕様、SLA、料金、更新履歴を要件ごとに照合してください。

評価・受入要件｜PoCの合否と停止条件を先に言語化する

PoCは性能を試すだけのイベントではなく、本番導入を判断するための検証です。開始前に評価項目、測定方法、成功条件、停止条件を決め、正常例だけでなく境界例と禁止例でも確認します。

結果を見てから評価基準を決めると、期待に合う回答だけを採用したり、未達項目を「今後改善できる」と解釈したりしやすくなります。PoC計画には、検証対象の業務範囲、テストデータ、比較対象、担当者、期間、予算、合否を決める責任者を記載します。

評価は、出力の正確性、処理時間、応答性、利用量当たりの費用などの定量面と、現場が使いこなせるか、確認作業が過重でないか、エラー原因を特定できるかといった定性面を組み合わせます。モデル性能が高くても、確認時間や運用負荷を含めると現行業務より非効率になる場合があります。

テストデータには、通常業務を表す正常例に加え、情報が不足した境界例、表記揺れ、長文、矛盾する情報、回答してはいけない質問、入力禁止情報を含む想定などを入れます。ただし、PoCで実際の機密情報を無断入力するのではなく、安全に加工したテストデータや承認済み環境を使用します。

合格数値は、誤りの影響と人間の確認方法を踏まえて業務ごとに設定するものです。本記事では一律の正答率や時間削減率を提示しません。品質目標を決める際は、「どの母集団から選んだ何件を、誰がどの正解基準で判定するか」まで定義してください。

要件定義からPoC判定までの意思決定フロー

製品比較へ進む前に、業務とリスクに関する判断を終えることが重要です。次の順序で進めると、要件に合わない製品を詳細評価する手戻りを抑えられます。

1. 導入目的と業務課題を定義する：AI導入によって変えたい業務状態と、効果を判断する指標を決めます。
2. 現行業務を整理する：利用者、入力、出力、参照情報、後続処理、例外処理を可視化します。
3. 影響度を評価する：誤回答、情報漏えい、権利侵害、停止が起きた場合の影響を確認します。
4. 人間の関与を決める：AIへ任せる処理と、人間が確認・承認する地点を定義します。
5. データ・非機能・運用要件を定義する：入力可否、権限、ログ、可用性、費用、責任者を決めます。
6. 候補サービスと照合する：公式仕様、規約、セキュリティ資料を要件単位で確認します。
7. PoCを実施する：正常例、境界例、禁止例を使い、同じ条件で候補を検証します。
8. 定量・定性評価を行う：品質、安全性、業務効果、確認負荷、運用性、総費用を評価します。
9. 導入可否を判断する：本番導入、条件付き導入、追加検証、見送りのいずれかを選びます。

特に、人間の関与を決める第4段階まで完了しないまま製品照合へ進むと、必要なログや出力品質を判断できません。先にモデルを選び、その仕様に業務を合わせるのではなく、許容できる業務条件に合うサービスを選びます。

「条件付きで使う」を選ぶ場合に明文化すること

実務では、全面利用と全面禁止の間にある「条件付き導入」が有力な選択肢になります。例えば、特定の法人プランに限定する、個人情報は入力しない、外部公開前に責任者が承認する、特定部門だけで利用するといった条件です。

条件付き導入では、対象業務と利用者、利用可能なアカウント、入力禁止情報、人間の確認方法、利用量の上限、ログ監視、例外申請を明文化します。条件を技術的に強制できない場合は、教育と定期監査を組み合わせ、違反や事故が起きた際の停止条件も設定します。

PoCの合否は「高品質な回答が出たか」だけでなく、安全な条件を守りながら継続運用できるかで決めます。条件を維持できない場合は、本番導入を見送る判断が必要です。

運用・ガバナンス要件｜導入後に誰が判断し続けるか

生成AIの要件定義はリリース時点で終わりません。責任者、監視、変更管理、教育、インシデント対応を定め、モデルや規約、業務の変化に応じて要件を更新します。

運用責任を「情報システム部門」や「プロジェクトチーム」とだけ書くと、具体的な判断者が不明になります。業務利用の承認者、アカウント管理者、ログ確認者、品質責任者、法務・セキュリティへのエスカレーション先を役割単位で定義します。AIの出力をどのように業務へ利用するかについて、社内の最終判断者と説明責任を明確にすることが必要です。

監視対象には、利用者数や費用だけでなく、誤回答、不適切出力、回答不能、禁止情報の入力、承認差し戻し、障害、規約・モデルの変更を含めます。問題が起きてからログを探すのではなく、どの記録を誰がどの頻度で確認し、どの条件で利用停止するかを決めます。

また、プロンプト、参照データ、評価セット、判定基準を個人の端末や記憶だけに残さないことが重要です。変更履歴と承認者を記録し、担当者が異動しても同じ条件で評価・運用できる状態を作ります。生成AIへの依存によって人間側の検証能力が低下しないよう、一次情報を確認する教育や定期的なレビューも組み込みます。

本番導入前後の運用チェック

本番移行の直前には、要件定義書の完成だけでなく、担当者が実際に運用できる状態かを確認します。次の項目は、リリース判定と定期点検の双方で利用できます。

チェックできない項目がある場合は、残課題として期限と責任者を設定します。安全性に直結する要件や停止手段が未整備であれば、利用範囲を限定するか、本番移行を延期してください。

生成AI導入の要件定義で避けるべき失敗

典型的な失敗は、目的や責任分界が曖昧なままツール検証を始めることです。PoCだけを完了条件にせず、本番運用でも要件を守れるかまで確認します。

正常なサンプルだけで精度を評価する

整った入力や回答しやすい質問だけを使うと、デモに近い結果しか得られません。本番で発生する情報不足、曖昧な依頼、誤記、矛盾、禁止質問を含め、失敗時の挙動を確認します。

平均的な正答率だけでなく、重大な誤回答がどの条件で発生したかを記録してください。少数でも許容できない誤りがある業務では、平均値が高くても採用できない場合があります。

PoCと本番で利用条件が変わる

PoCでは匿名化した少量データを担当者が手動入力し、本番では個人情報を含む大量データを自動連携するなら、リスクと非機能要件は同じではありません。利用者数、データ種類、連携方法、権限、確認工程が変わる場合は、追加の評価が必要です。

PoCの成功をそのまま本番の受入とせず、本番構成に対する移行判定を設けます。特にAPI連携や自動実行を追加する場合は、誤処理の影響範囲と緊急停止方法を再確認します。

プロンプトや評価基準が担当者に属人化する

特定の担当者だけが良い回答を引き出せる状態では、組織導入の再現性がありません。使用したプロンプト、参照データ、モデル、設定、評価結果を記録し、別の利用者でも同等の業務結果を得られるかを確かめます。

モデル更新後も同じ品質が維持されるとは限らないため、代表的な評価セットを保存し、変更時に再テストします。再評価で受入条件を下回った場合の利用制限や切り戻しも決めておきます。

まとめ

生成AI導入では、モデル性能より先に、対象業務、データ、安全性、人間の関与、運用責任、受入条件を定義します。要件を満たす製品がない、または検証負荷とリスクが便益を上回る場合は、条件付き導入や見送りも妥当な結論です。

まず候補業務について、利用者、入力・出力、例外処理、誤りの影響を整理してください。その後、入力可能なデータ、人間の承認点、権限・ログ、障害時の代替手段、運用責任者、PoCの合格・停止条件を関係部門で合意します。これらが決まらない段階で製品比較へ進まないことが、手戻りを抑える基本です。

要件定義のチェック項目がそろっても、対象業務の選び方、安全要件の水準、PoCの評価・停止条件、サービス比較を社内だけで決めにくい場合があります。自社の業務、データ、運用体制に合わせて生成AI導入の要件を整理したい場合は、CREATREEへご相談ください。

よくある質問

生成AI導入の要件定義では、最初に何を決めるべきですか？

最初に「誰のどの業務課題を解決し、どこまでAIへ任せ、人間がどこで確認・承認するか」を決めます。製品名やモデルは、その業務要件とリスク要件を定義した後に選びます。

機密情報や個人情報を生成AIへ入力できるか、何を確認すればよいですか？

対象プランを特定し、学習利用、保存期間、削除方法、ログ、管理者権限、処理・保管地域、再委託先を確認します。さらに、自社の情報分類、個人情報の取扱い、顧客との秘密保持契約やクラウド利用条項との整合を法務・セキュリティ部門が確認してください。

PoCの精度や品質は、どのようなデータと指標で評価すべきですか？

実業務を代表する正常例に加え、情報不足や曖昧な入力を含む境界例、回答してはいけない禁止例を使います。正確性、重大な誤り、処理時間、費用、人間の確認時間、運用負荷を組み合わせ、業務ごとに合格条件を設定します。

AIの回答を人間が確認・承認する工程は、どの業務で必須ですか？

法務、人事、医療、金融、安全に関わる判断、顧客への確定回答、個人情報を扱う処理など、誤りの影響が大きい業務では、専門部門による確認と厳格な人間承認を原則とします。影響が限定的な社内アイデア出しでも、外部公開や重要な意思決定へ利用する段階では確認が必要です。

SaaS型、API利用、自社環境での構築は何を基準に選べばよいですか？

データの機密性、必要なアクセス制御とログ、既存システムとの連携、初期構築能力、継続的な保守体制、総費用を基準に選びます。提供形態だけで安全性を決めず、候補サービスの契約プランと公式仕様を個別に照合してください。

著者プロフィール

この著者の記事一覧へ

著者 藤村 隼人 CREATREE合同会社 代表社員／NSJAPAN CDO

HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。