この記事で分かること
- AIシステムの要件定義で最初に固定する業務目的と対象範囲
- 正答率だけに頼らず、業務で使える精度を決める方法
- データの種類・更新・権限・品質を要件へ落とし込む観点
- AIの出力を誰が確認し、誤りや障害へどう対応するかの責任分担
要件定義の出発点はAIではなく、変えたい業務を一つに絞ること
「社内でAIを活用したい」「生成AIを業務に組み込みたい」という方針は、プロジェクトを始める理由にはなりますが、そのまま開発要件にはなりません。要件定義では、対象となる業務を一つ選び、現状の手順と改善後の状態を対比させます。たとえば、問い合わせ回答支援なら、受付、資料検索、回答案作成、上長確認、送信のどこを短くするのかを分けて考えます。
同じ「自動化」でも、AIが回答案を作るだけなのか、担当者の承認後に送信まで行うのかで、必要な権限、画面、ログ、評価基準が変わります。対象業務の開始条件、終了条件、例外、関係者を書き出し、「AIが担当する部分」と「人が判断する部分」を線で区切ると、要件の議論が機能一覧に流れにくくなります。
対象範囲を決めるときは、最初から全社展開を目指さないことも重要です。部署、帳票、問い合わせ種別、対象期間などを限定し、検証で確認できる単位にします。既存のExcelやAccessが業務の一部を担っている場合は、置き換えるのか、当面は連携するのかも選択肢に含めます。現行環境の確認には、開発前診断・ロードマップのような現状整理の考え方が役立ちます。
業務目的を測れる言葉へ変換する
目的は「効率化」だけで終わらせず、何を測るかまで記述します。問い合わせ対応なら一件あたりの担当者作業時間、回答案の修正回数、初回返信までの時間が候補です。文書検索なら必要な規程へ到達するまでの時間、根拠確認にかかる時間、検索を諦める件数などを確認します。数値目標を仮置きしても構いませんが、測定方法と対象期間を併記し、後から都合よく変更できないようにします。
売上や利益を目的にする場合は、AI以外の影響も整理します。季節性、人員配置、キャンペーン、価格変更が同時に起きるなら、導入前後の差だけでAIの効果を断定しない設計が必要です。AIが直接動かす指標と、結果として期待する経営指標を分けることで、検証の段階で確認すべきことが明確になります。
精度要件は「何％」ではなく、失敗の種類と業務の許容範囲で定める
AIの精度を一つの数字だけで契約や受入条件にすると、実務で困る失敗が見えなくなります。全体の正答率が高くても、重要な顧客区分だけ誤る、根拠のない回答を断定する、権限のない資料を参照する、といった問題が残る可能性があるからです。最初に出力の種類を分け、どの誤りが重大かを業務担当者と決めます。
| 出力の種類 | 主な評価 | 確認したい失敗 |
|---|---|---|
| 分類・判定 | 分類ごとの適合、見逃し、誤検出 | 重要な案件を対象外へ送る、確認が不要な案件を過剰に止める |
| 数値・予測 | 誤差の大きさ、期間別の偏り | 繁忙期や特定の商品だけ予測が外れる |
| 文章・回答案 | 必須事項、根拠、読みやすさ | 存在しない規程を示す、条件や例外を落とす |
| 要約・抽出 | 重要情報の再現、抜け漏れ | 期限、金額、担当者などの業務上重要な項目を欠落させる |
「誤りを人が発見して直せるか」も精度要件の一部です。回答の横に参照文書やページを表示する、信頼度が低い場合は保留にする、入力不足を知らせて再確認へ回すなど、誤りを前提にした安全策を決めます。人が確認する前提なら、確認に何分かかるか、どの項目を見ればよいか、承認者が不在のときどうするかまで要件に含めます。
通常ケースだけでなく、境界例を受入条件に入れる
評価データは、よくある正常例だけでは不十分です。入力が空欄の案件、表記が揺れている顧客名、複数の条件にまたがる依頼、古い規程に関する質問など、現場が迷う例を含めます。境界例を試すと、AIの問題に見えていたものが入力ルールや資料管理の問題だと分かることもあります。
受入条件は、次のように具体化すると確認しやすくなります。「回答には参照した文書名と版を表示する」「金額が入力されていない場合は計算結果を返さず、確認を促す」「対象外の質問には対応範囲外と表示する」といった動作条件です。単に「高精度であること」と書くより、テストケースの期待結果と結び付けられます。
精度の測定方法も忘れてはいけません。誰が採点するのか、文章の完全一致を求めるのか、意味が合っていれば合格とするのか、意見が割れたときに誰が裁定するのかを決めます。モデルやプロンプトを変えた場合に同じデータで再評価できるよう、入力、出力、判定理由、実施日、バージョンを記録します。
データ要件は、ファイル形式より正しさ・更新・利用権限を定義する
AI開発で「Excelを渡せばよい」「社内文書を全部読み込めばよい」と考えると、後で大きな手戻りになります。データ要件では、データの所在、所有者、正本、項目の意味、更新頻度、保存期間、閲覧権限、欠損や重複の扱いを確認します。ファイル形式は技術的な入口にすぎず、業務で信頼できる情報かどうかが本質です。
表データなら、一行が顧客なのか注文なのか明細なのかを明記します。金額の税込・税抜、日付の基準、コードの意味、空欄とゼロの違いも定義します。文書なら、最新版の識別方法、廃止文書の扱い、改訂履歴、章やページの情報を残せるかを確認します。これらが曖昧なままでは、AIに渡す前の整形処理で判断が入り、結果の責任を追いにくくなります。
データを外部のAIサービスへ送る構成では、入力してよい情報の範囲、保存条件、アクセス権、削除方法を社内ルールと照合します。不要な個人情報を取り除く、識別子を置き換える、権限に応じて検索対象を分けるなどの対策を、後付けではなく要件として記載します。AI受託開発・生成AIシステム開発の検討でも、データの扱いと運用まで含めて相談すると、構成の比較がしやすくなります。
データの品質問題をAIの責任にしない
AIの誤答を減らすために、開発会社へ「データをきれいにしてほしい」とだけ依頼するのは危険です。どの値が正しいかを判断できるのは、通常、業務を管理している側だからです。開発側は整形や検査の仕組みを作れても、古い規程を現行ルールとして採用するか、重複した顧客を同一人物とみなすかまでは自動で決められません。
そこで、データごとに「提供者」「内容の責任者」「整形を実行する担当」「利用可否を承認する担当」を分けて記録します。原本を変更する人とAI用データを更新する人も、同じとは限りません。責任者が不在のときの代替や、更新が期限に間に合わない場合の停止条件まで決めておくと、本番運用で判断が止まりません。
機能要件と非機能要件を、利用場面から漏れなく整理する
機能要件には、入力、処理、出力、検索、修正、承認、通知、履歴の確認を含めます。たとえば社内文書検索なら、質問入力、検索結果、回答、根拠文書、再質問、回答の評価、管理者による文書更新が一連の機能です。生成された回答だけを画面に表示し、根拠や修正履歴を残さない設計では、誤りの確認と改善が難しくなります。
非機能要件は、AIではない一般的なシステム要件も含みます。応答時間、同時利用者数、稼働時間、障害時の復旧、バックアップ、権限、監査ログ、API利用料の上限、モデル変更時の確認手順などです。特にAIでは、同じ入力に毎回完全に同じ文章が出るとは限らないため、結果の保存方法や再現できる材料を決めておきます。
権限は、画面を開けるかだけでなく、検索対象、参照できる根拠、出力を保存できる場所、管理機能の実行可否まで分けて検討します。一般社員が見られない評価資料を、検索用の複製データ経由で回答してしまうなら、画面側の制御だけでは不十分です。利用者の役割ごとに、許可する操作と禁止する操作を表にします。
既存システムとの境界を図にする
AIシステム単体の仕様書では、既存システムとの接続責任が抜けがちです。どこからデータを受け取り、どのタイミングで処理し、結果をどこへ戻すのかを図にします。API、CSV、手動アップロード、データベース接続では、エラーの検知方法や再実行の手順も変わります。
システム間の項目名が違う場合は、対応表を作成し、変換できない値の扱いを決めます。連携元が停止した場合にAIを止めるのか、最後に取得したデータで限定的に動かすのかも、現場と合意が必要です。ここを「開発会社が調整する」と曖昧にせず、各システムの管理者と承認者を要件一覧に記載してください。
既存環境を残すか刷新するかで迷う場合、AI機能の開発だけを切り出さず、現行業務の制約と将来の変更予定を並べて比較します。新規開発の前提が適切かを確認したいときは、予算500万円からのAIシステム開発でできることの記事も、費用と範囲を考える材料になります。
責任範囲はRACIのように、作業単位で名前を付ける
「AIの回答は利用者が確認する」という一文だけでは、責任分担として不十分です。誰がデータを更新し、誰が評価ケースを作り、誰が本番反映を承認し、誰が誤回答を調査するのかを作業単位で決めます。発注者、開発会社、業務責任者、情報システム担当、現場利用者の役割を分け、最終判断者を一人に定めます。
| 作業 | 発注側で決めること | 開発側に依頼すること |
|---|---|---|
| 目的・対象範囲 | 改善したい業務と対象外 | 実現方法と制約の整理 |
| 正解・評価 | 業務上の合格条件と重大な失敗 | テスト環境、評価記録、再実行方法 |
| データ更新 | 正本、更新担当、承認者 | 取込処理、検査、エラー通知 |
| 本番運用 | 利用ルール、承認範囲、停止判断 | 監視、ログ、障害対応、改善提案 |
契約や見積書には、成果物だけでなく、発注側が準備するものと判断する期限も書きます。実データの提供、業務担当者のレビュー、接続先の利用許可、受入テストの実施は、開発会社だけでは完了できません。依頼側の作業が明示されていれば、遅延が起きたときに原因を分けて対処できます。
誤回答や情報漏えいが起きた場合の初動も確認します。利用停止の権限、ログの保全、社内への報告、原因調査、再開条件を決め、緊急連絡先を最新に保ちます。AIを完全自動化するほど、例外時に人へ戻す経路が重要になります。
セキュリティと受入の確認を別の担当にも見てもらう
業務担当者が正しさを確認できても、情報管理の条件まで確認できるとは限りません。受入前には、利用者の役割ごとに見えるデータ、ログへ残る情報、保存場所、削除手順、外部サービスへ送信される項目を確認します。テスト環境に本番データを置く場合は、利用期間と削除確認の担当も記録します。
受入テストの結果は、合格・条件付き合格・不合格だけでなく、残課題と対応期限を残します。条件付きで開始するなら、対象部署を限定する、重要な判断には二人の確認を付ける、未解決の連携を手動に戻すなど、制限の内容を利用者へ知らせます。未解決事項を「運用で注意する」とだけ書かず、具体的な手順と責任者へ変換することが大切です。
こうした確認を要件定義の終盤で一度に行うのではなく、データ、画面、連携、評価の設計ごとに小さく実施します。早い段階で制約が分かれば、作り込んだ機能を後から捨てるリスクを抑えられます。要件定義は開発を始めるための許可証ではなく、関係者が同じリスクを理解するための判断記録です。
要件定義書は、開発会社との会話を合わせるための判断記録
要件定義書は、長い機能一覧を作ることが目的ではありません。目的、対象範囲、現状フロー、データ、画面・連携、評価、セキュリティ、運用、責任者、未決事項を、第三者が読んでも同じ判断になる形で残す文書です。決まっていないことを空欄にせず、「誰がいつまでに決めるか」を記録します。
レビューでは、業務担当、システム担当、情報管理、決裁者がそれぞれの視点で確認します。業務担当は出力の正しさ、システム担当は連携や障害、情報管理は権限や保存、決裁者は費用と効果を見る役割です。全員がすべての技術詳細を読む必要はありませんが、自分の判断が必要な箇所を明示して回覧します。
要件変更は避けるものではなく、管理するものです。変更理由、影響する画面・データ・評価、費用・期間の差分、承認者、反映日を一つの台帳に記録します。PoCで初めて分かった制約を本番要件へ反映するときも、元の判断を消さず、なぜ変えたかを残してください。
要件定義の段階で不明点が多い場合は、いきなり本番開発へ進まず、対象業務の診断や小さな検証を挟みます。AIに向かない処理を通常のシステムや業務フロー改善で解決できることもあります。AIありきで進めるのではなく、現実的な選択肢を比較することが、発注側にとってのリスク管理になります。
よくある質問
AIのモデルが決まっていなくても要件定義を始められますか？
始められます。先に業務目的、入力、期待する出力、許容できない失敗、利用者、データの条件を整理します。モデルはその条件に対して、精度、速度、費用、セキュリティ、連携のしやすさを比較して決める方が、選定後の手戻りを抑えられます。
精度を何％と決めれば、受入テストはできますか？
数字だけでは足りません。評価対象のデータ、分類ごとの分母、重大な失敗、人による確認の方法、対象外の入力時の動作を決めます。回答系のAIでは、根拠の有無や必須情報の抜けも合格条件に含めると、業務上の判断に使えるテストになります。
データの準備は開発会社に任せられますか？
整形や取込の仕組みは依頼できますが、業務上の正しさや利用可否の最終判断は発注側が持つことが一般的です。正本の管理者、内容を確認する担当、更新の承認者を決め、開発会社の作業範囲と分けて記載してください。
要件定義書に書き切れないことが残ったらどうしますか？
未決事項として残し、判断者、期限、判断に必要な材料、決まらない場合の仮置きを記録します。未決のまま開発を進める範囲と、決定しないと着手できない範囲を分けると、プロジェクト全体が止まりにくくなります。
精度・データ・責任を決めてから、開発の大きさを選ぶ
AIシステムの要件定義は、AIの機能を増やすための作業ではなく、業務で安全に使える境界を決める作業です。対象業務を絞り、評価する失敗を定義し、データの責任者と更新方法を決め、誤りや障害のときに人へ戻せる仕組みを要件へ落とし込みます。
要件がそろえば、PoCで確かめる範囲と、本番開発で作り込む範囲を分けられます。現状が複雑で判断材料が足りないときは、要件定義そのものを相談の対象にして構いません。最初の合意を丁寧に作ることが、費用・期間・責任の見通しを持ってAI開発を始める近道です。
