この記事で分かること
- AIシステムの要件定義で最初に整理する業務と利用者
- 精度を数値や判定条件へ変換する考え方
- 学習・検索・入力に使うデータの準備と管理方法
- AI、開発会社、現場担当者の責任範囲と合意の作り方
AIシステムの要件定義は「何を作るか」から始めない
最初に決めるのは、AIの種類よりも改善したい業務です。問い合わせへの回答案を作りたいのか、社内文書を探したいのか、帳票の内容を分類したいのかで、必要なデータと画面は変わります。AIチャットを作るという言葉だけでは、利用者が何を入力し、どの結果を確認し、どこで業務を完了するのかが分かりません。
現在の業務を一件の流れとして書き出します。受付、確認、検索、判断、承認、登録、通知のどこに時間がかかっているかを示すと、AIに任せる範囲を絞れます。人の判断を残す工程と自動化する工程を分けておくと、誤回答が起きたときの対応も設計しやすくなります。
| 整理項目 | 記載する内容 | 未整理だと起こる問題 |
|---|---|---|
| 対象業務 | 開始条件、手順、完了条件、例外 | AIを入れる場所が決まらない |
| 利用者 | 部署、役割、人数、利用環境 | 画面や権限の不足が起こる |
| 入力 | 文章、ファイル、音声、数値、連携データ | 実際のデータで検証できない |
| 出力 | 回答、分類、要約、候補、通知 | 完成したか判断できない |
| 成果 | 削減時間、件数、品質、利用率 | 費用対効果を測れない |
要件定義で精度を決める方法
「高精度」を業務上の合否へ置き換える
精度という言葉は人によって意味が違います。質問に対する回答が正しいこと、根拠となる文書が示されること、分類先が合っていること、数字の転記ミスがないことは、それぞれ別の評価です。まず、間違えると業務へ大きな影響が出るケースを洗い出し、合格条件を定義します。
社内文書検索なら、正しい回答だけでなく、参照元の文書名や版を示せるか、回答できない質問に無理に答えないかを確認します。問い合わせ対応なら、回答候補の正確さと、担当者が修正して送信できるかを分けて見ます。AIの出力をそのまま確定しない業務では、人の確認時間も成果指標に含めます。
評価用データを先に用意する
評価用データは、AIへ渡す文書のコピーだけではありません。質問、期待する回答、参照すべき根拠、回答できない場合の扱いを組み合わせたテストケースです。よくある例だけでなく、誤字、表記ゆれ、古い情報、長文、空欄、権限外の質問も含めます。
現場の担当者に「正しい答え」を判定してもらいます。判断が分かれる場合は、どの回答なら合格かを話し合い、評価基準に注記を残します。評価者が毎回変わると結果がぶれるため、担当部署と確認期限を要件定義書へ書きます。
精度と速度、費用のバランスを決める
高い精度、短い待ち時間、低い利用費をすべて最大化できるとは限りません。業務によっては、回答に数秒かかっても根拠確認を優先します。逆に、受付の一次分類では多少の確認を残しても速さを重視する場合があります。許容時間、利用量、予算を同じ表で比較しましょう。
開発会社から方式を提案されたら、採用理由を質問します。検索と生成を組み合わせるのか、既存のデータベースから定型回答を返すのか、モデルを追加学習するのかで、必要な費用や保守は変わります。方式の名前より、業務条件にどう適合するかを確認します。
AIシステムで扱うデータを要件に含める
データの所在と利用権限を一覧にする
データは「社内にある」と書くだけでは不十分です。ファイルサーバー、クラウド、Excel、Access、基幹システムなど、保管場所と管理者を確認します。更新頻度、ファイル形式、件数、古い版の扱い、削除時の処理も記載します。
資料を使える人と、AIへ登録できる人は同じとは限りません。部署ごとに閲覧できる文書が違うなら、検索結果にも権限を反映させます。全社公開の資料と管理者限定の資料を混ぜる場合は、アクセス制御の方式を設計段階で決めます。
データ品質の責任を分ける
文書の誤りや古い情報をAIだけで直すことはできません。発注側は正しい資料の管理者と更新ルールを決め、開発会社は取り込み、検索、変換、削除の仕組みを設計します。どちらか一方だけの責任にすると、品質低下の原因を調べにくくなります。
入力データの欠損や重複をどう扱うかも決めます。欠損をエラーにするのか、空欄として処理するのか、担当者へ差し戻すのかを定義します。CSVの列名が変わった場合、取り込みを止めるのか、警告を出して続けるのかも運用上の重要な要件です。
外部サービスへ送る情報を確認する
AI APIやクラウドサービスを利用するなら、どのデータが外部へ送られるか、保存されるか、ログに残るかを確認します。個人情報や営業秘密が含まれる場合は、匿名化、マスキング、送信対象の限定を検討します。契約や社内規程で利用できないサービスがある場合は、要件定義の初期に共有してください。
削除要求に対応できるか、バックアップに残る期間はどれくらいか、アカウントを誰が管理するかも確認します。セキュリティの詳細は専門部署や法務の判断が必要な場合があるため、開発会社だけで結論を出さず、社内の承認者を決めます。
責任範囲を要件定義書へ書く
| 担当 | 主な責任の例 | 合意しておく事項 |
|---|---|---|
| 発注側の業務責任者 | 目的、優先順位、業務上の合否 | 誰が最終判断をするか |
| 発注側のデータ管理者 | 正しい資料、更新、公開範囲 | データをいつ誰が更新するか |
| 開発会社 | 設計、実装、技術テスト、説明 | 対象外、前提、納品物 |
| 運用担当 | 利用者対応、品質確認、改善依頼 | 受付窓口と対応時間 |
| 承認者 | 本番化、例外処理、公開判断 | 進行・停止の条件 |
責任範囲は、担当者の名前だけでなく、作業と判断を対応させます。例えば、AIの回答が間違ったときに、利用者が報告し、運用担当が分類し、データ管理者が資料を確認し、開発会社が検索やプロンプトを調整する流れです。連絡期限と記録場所も決めておくと、問題を放置しにくくなります。
要件定義の成果物と受け入れ条件
要件定義で残す資料には、業務フロー、機能一覧、画面ラフ、データ項目表、権限表、連携仕様、AI評価計画、運用体制、未決事項一覧が考えられます。すべてを最初から詳細に作る必要はありませんが、開発へ進む前に、未決のままでは困る項目を明示します。
受け入れ条件は「動くこと」ではなく、「担当者が業務を完了できること」にします。指定したテストケースで合格する、根拠を表示する、権限外の情報を返さない、失敗時に再処理できるなど、確認できる文章にします。評価結果と残課題を保存する場所も納品範囲に含めます。
要件定義を進める七つの確認手順
- 困っている業務と現行の手順を一件の流れで書く
- 利用者、管理者、承認者を分ける
- 入力データの場所、形式、更新者、利用範囲を確認する
- AIへ任せる処理と、人が確認する処理を分ける
- 正常系と例外系の評価用データを作る
- 精度、待ち時間、利用費、利用率の合格条件を決める
- 未決事項、責任者、判断期限を一覧にして承認する
この順番で進めると、モデル選定や画面の議論が先行しにくくなります。すでに使いたいAIサービスがある場合も、業務条件とデータ条件を確認してから採用可否を判断します。
要件定義で起こりやすい失敗を防ぐ
よくある失敗は、デモ画面を見てから業務を合わせようとすることです。画面がきれいでも、入力データが毎回違う、担当者が確認する場所がない、既存の台帳へ戻せないなら、利用は続きません。最初の打ち合わせでは、実際の一件を最初から最後まで説明し、AIの出力後に誰が何をするかまで確認します。
次に、例外を後回しにする失敗があります。正常な文書だけで試すと、空欄、重複、古い版、表の崩れ、権限外の質問で困ります。例外は発生頻度が低くても、顧客対応や発注など影響が大きい場合があります。代表例を最初からテストケースへ入れ、処理を止めるのか人へ戻すのかを決めます。
責任者が不在のまま進めることも危険です。現場は使い方を知っていても、正しい回答や公開範囲を決められないことがあります。業務責任者、データ管理者、情報システム、法務やセキュリティの確認者を早く集め、決定事項を議事録と要件定義書へ残します。会議で決まらなかった項目は未決のまま記録し、期限と担当者を置いてください。
小さな検証を行う場合も、本番で必要になる運用条件を確認しておきます。PoCでは対象資料を限定しても、権限、ログ、削除、評価者の役割を考えておくと、本番化の差分を把握できます。検証の目的を「AIが動くこと」ではなく、「担当者が業務を早く正確に終えられるか」と書くと、要件の優先順位が明確になります。
また、要件定義書を一度作って終わりにせず、テストや運用で得た判断を追記できる形にします。変更理由、決定日、決定者を残せば、後から仕様が変わった理由を説明できます。AIの改善では、モデルを変える前にデータや利用方法を見直すこともあるため、評価結果と対応策を結び付けて記録します。
社内承認では、作る機能の一覧だけでなく、作らない機能と次に判断する条件も示します。対象部署やデータを絞る理由、確認者を置く理由、将来拡張の前提を共有すると、現場の期待と開発範囲がずれにくくなります。
この合意があると、見積もりの比較でも「安いか」だけでなく、含まれる検証や運用の違いを確認できます。社内説明も容易です。担当者の判断も揃います。変更にも対応しやすくなります。安全に計画的に確実に進められます。運用も。
AIシステム要件定義のFAQ
精度は何％と決めればよいですか？
一律の数値では決められません。回答、分類、抽出など処理ごとに、間違った場合の影響と人の確認方法を整理し、実データに近いテストケースで合否を決めます。
データが整理されていなくても要件定義できますか？
できます。保存場所、形式、件数、管理者、代表的なサンプルを確認し、整理作業を要件定義やPoCの範囲に含めるか決めます。
AIの回答を誰が保証しますか？
AIが無条件に正しさを保証するのではなく、業務上の合否を発注側が定義し、開発会社が実装と技術テストを担当します。重要な回答は人の確認を残します。
要件定義書は発注側で作る必要がありますか？
業務の目的やルールは発注側が情報を出し、文書化や技術的な整理を開発会社へ依頼できます。誰がどの資料を作るかを見積もりに明記してください。
途中で要件を変更した場合はどうなりますか？
未決事項と変更履歴を残し、費用、納期、評価条件への影響を確認します。変更を無制限に含めず、再見積もりの条件を契約前に決めます。
AIシステムの要件整理を相談する
マクティズムのAI開発サービスでは、仕様が固まっていない段階から、業務課題、利用データ、必要な機能、運用イメージを整理する相談に対応しています。社内文書検索、問い合わせ対応、文書作成、既存のExcelや業務システムとの連携など、目的に応じて実現範囲を検討します。
相談時は、現在の業務フロー、困っている件数や時間、利用者、データのサンプル、希望時期を共有してください。要件定義から始めるのか、小さな検証で不確かさを減らすのかを比較し、社内で承認できる計画へ落とし込みます。
まとめ｜精度・データ・責任を同じ要件に書く
AIシステムの要件定義では、AIの種類より先に、対象業務、利用者、入力、出力、成果を整理します。「高精度」を業務上の合否へ変え、正常系と例外系の評価用データを準備し、利用権限と外部サービスへの送信範囲を確認します。
さらに、発注側の業務判断、データ管理、開発会社の実装、運用担当の改善、承認者の判断を分けて書くことが重要です。未決事項と期限を残したままでも、責任者と次の判断を明確にできれば、現実的なAIシステム開発へ進みやすくなります。
