生成AI導入の要件定義｜5つの要件領域と実装手順

生成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の適用範囲を切り出す

要件定義の前に、現状業務を「入力・処理・判断・出力・例外」に分解します。判断基準や例外を説明できない業務は、AIの適用範囲や評価方法も決められないため、まず現場業務の可視化が必要です。

業務分解シートの作り方

業務名だけではなく、実際の1件が開始して完了するまでを追います。担当者へのヒアリングでは「通常はどうするか」に加え、情報不足、形式不備、判断が割れるケースなども確認してください。

• 入力：受け取る文書、画像、申請内容、顧客情報、参照データ
• 処理：転記、検索、分類、要約、計算、照合などの作業
• 判断：担当者が基準に照らして選択、承認、優先順位付けを行う箇所
• 出力：回答文、登録データ、判定結果、報告書、次工程への指示
• 例外：情報不足、重複、矛盾、対象外、期限超過、システム障害への対応

AI適用の可否を判断する4つの観点

AIを使えるかどうかは、作業量や技術的な実現性だけでは決まりません。次の観点を一つずつ確認し、リスクが高い部分は人の判断として残します。

• 誤りの影響：修正可能な下書きの誤りか、顧客・契約・会計処理などへ直接影響する誤りか
• 説明責任：判断理由を社内外へ説明する必要があるか、必要な記録を残せるか
• データ利用可否：対象データを予定するAI環境へ入力・送信・保存できるか
• 人による確認可能性：担当者が妥当性を判断できるか、確認工数を運用へ組み込めるか

AIの適用範囲を切り出す手順

初回の対象には、一定の繰り返しがあり、判断基準を言語化でき、現状値を測定できる業務が向いています。複数部門をまたぐ大きな業務よりも、担当者と成果を特定できる一つの処理を選ぶほうが、効果と問題点を切り分けやすくなります。

1. 現場担当者に実際の処理を1件実演してもらい、使用データと操作を記録する
2. 判断が入る箇所に印を付け、判断理由を担当者の言葉で書き出す
3. 各判断基準を第三者が再現できる文章や条件に変換する
4. 言語化できた範囲をAIの候補とし、説明できない範囲は人の判断として残す
5. 処理時間、件数、手戻り件数など、導入前の状態を測定する

暗黙知が中心の業務を対象にしたい場合は、先に熟練者が判断した事例と理由を記録します。評価用の正解例を用意できない段階では、本番導入を急がず、判断記録の収集を要件に含めるべきです。

対象業務、利用者、導入前の状態、判断基準、代表的な例外を説明できない場合は、AIの方式や製品を比較する段階ではありません。先に現状業務の記録と分解を進めます。

入力・出力・権限を定義する

入力要件はデータ名だけでなく、取得元、利用根拠、送信先、保存、アクセス権限まで定義します。出力は良い例と不可例で具体化し、権限はAIが提案するだけなのか、システム上の処理まで実行できるのかを段階で決めます。

入力データ要件を定義する

入力データを一覧化し、業務上必要だから利用できると即断しないことが重要です。個人情報、顧客秘密、営業秘密、著作物などを含む可能性がある場合は、利用目的、契約、社内規程、AIサービスのデータ取扱条件を確認します。

• データの名称、形式、取得元、更新頻度が記載されている
• 欠損、重複、表記揺れ、古い情報をどのように扱うか決まっている
• 入力・送信できない情報が明文化されている
• 外部サービスへ送信する場合の利用条件を確認している
• 保存期間、削除方法、閲覧者、アクセス権限が決まっている
• 入力・出力・操作ログに残す情報とマスキング対象が決まっている

外部の生成AIサービスへ個人データを入力する場合は、提供者が入力情報を機械学習へ利用するかどうかなど、サービスの取扱条件によって確認事項が変わります。利用規約やデータポリシーは更新される可能性があるため、確認した日付と対象プランも要件定義書へ記録します。

期待する出力をサンプルで定義する

「正確な要約」「自然な回答」といった形容詞だけでは、発注者、利用者、開発者の解釈が一致しません。実際の入力に対して、少なくとも良い例、判断が分かれる境界例、使用できない例を作ります。

• 良い例：必須情報、形式、文章量、根拠の示し方を満たす出力
• 境界例：人による追加確認や修正があれば利用できる出力
• 不可例：根拠のない断定、禁止表現、情報欠落、規定外の処理を含む出力

出力要件には、必須項目、文字数、形式、参照可能な情報源、禁止事項、判定不能時の表現を含めます。AIが回答できない場合に、無理に推測せず「確認が必要」と返す形式も定義してください。

AIの権限と人の責任を分ける

権限は「AIを使うか使わないか」の二択ではありません。CREATREE編集部では、業務リスクと検証結果に応じて、次のように委ねる範囲を段階的に広げる方法を提案しています。

段階	AIの役割	人の役割
提案	候補、要約、分類案などを提示する	採用する案を選び、内容を確定する
下書き作成	回答文や登録内容の下書きを作る	内容を確認・修正し、承認する

段階	AIの役割	人の役割
承認付き実行	人の承認後にシステム上の処理を実行する	実行前に対象と内容を確認する
条件付き自動実行	定められた条件と権限の範囲内で処理する	監視、停止、例外対応、最終責任を担う

実行権限を与える場合は、対象システム、操作可能なデータ、金額や件数の上限、実行可能な時間帯、禁止操作を具体化します。「担当者が確認する」ではなく、承認者、運用責任者、障害時の連絡先を役割名で特定する必要があります。

AIの出力が確認なしで次工程へ進むなら、誤処理を止める技術的な制御と、停止を判断する運用責任者の両方が必要です。どちらか一方だけでは責任分界が成立しません。

例外処理とフォールバックを設計する

AI導入では、正常に動く場合よりも、誤りや判断不能が起きた場合の動線を先に決めることが重要です。「迷ったら止まる」「判定不能を返す」「人へ引き継ぐ」の3点を、業務フローとシステムの両方へ組み込みます。

例外を4類型で洗い出す

• 誤出力：事実と異なる回答、誤分類、計算間違い、業務ルール違反が発生した
• 判断不能：情報不足、複数解釈、参照情報の矛盾により結論を出せない
• 応答不能・遅延：外部サービス、ネットワーク、連携システムの障害で処理できない
• 想定外入力：未対応形式、対象外の依頼、破損データ、禁止情報が入力された

各例外には、検知方法、停止条件、差し戻し先、代替手順、記録項目、再発防止を担当する役割を紐づけます。AIの内部的な確信度だけに頼らず、必須項目の欠落や数値の不一致など、業務ルールによる検知も併用します。

停止・エスカレーション条件を決める

1. 過去事例や現場ヒアリングから、例外4類型の具体的なシナリオを作る
2. システムで検知できるものと、人が確認すべきものを分ける
3. 処理を停止する条件と、継続してよい条件を明文化する
4. 差し戻し先となる担当者と、AIを使わない代替手順を決める
5. 発生日時、入力、出力、判断、修正内容を記録する範囲を決める
6. 例外件数や重大な誤りを再点検する頻度と責任者を決める

人の確認を前提にする場合は、その工数も要件に含めます。確認作業が現場の処理能力を超えると、未確認のまま利用される、あるいはAI導入前より作業時間が増える可能性があります。

AIの出力を人が確認する設計でも、確認者が内容を無批判に受け入れれば安全性は確保できません。確認基準、参照情報、差し戻し条件を明文化し、承認操作だけが形式的に残る状態を避けてください。

運用後の変化を監視する

入力データ、業務ルール、利用者、外部モデルの仕様が変われば、導入時の評価結果がそのまま維持されるとは限りません。エラー率、判定不能率、手修正率、処理時間、例外の種類を継続的に記録し、基準を超えた場合は自動化範囲を縮小するか、要件定義へ戻ります。

まとめ

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

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

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

よくある質問

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

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

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

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

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

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

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

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

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

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

著者プロフィール

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

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