「生成AIで問い合わせ対応を効率化したい。ベンダーに見積もりを頼んだら、要件定義書を出してくださいと言われた」——生成AIの導入相談で、いちばん多く止まるのがこの場面です。通常のシステムなら画面や機能を並べれば形になりますが、AIは「どこまで当たればよいか」「間違えたら誰が直すか」を決めないと、作る側も見積もれません。
AI開発の要件定義とは、通常の機能・非機能要件に「精度」「データ」「誤り時の運用」「人の介在（HITL）」の4つを足し、業務のどこをAIに任せて、どこを人が確定するかを決める作業です。出発点は機能ではなく業務で、業務をタスクに分けてAIの向き不向きを判定するところから始めます。
本記事では、当社が業務改善の現場で使っている「AI化適性の判定フレーム」と、要件定義そのものをAIで支援する社内ツールを試作した所感をもとに、業務から要件へ落とす6つの手順と、HITL（人が判断に入る仕組み）の設計方法を整理します。
この記事の監修：大槻 伸夫（キュリオシティ株式会社 代表取締役CEO）。業務改善・PMI・生成AI導入の現場支援に携わり、「現場主義 × AI」で業務の可視化から生成AIの試作・定着までを支援。
AI開発の要件定義は、普通のシステム開発と何が違うのですか？
違いは「答えが毎回ぶれる前提で決める」ことです。 通常のシステムは同じ入力に同じ出力を返しますが、AIは確率で答えるため、100%正しい状態を要件にできません。そのため、どこまでの誤りを許すか・誤ったときに誰がどう直すかを、要件として書く必要があります。
| 観点 | 通常のシステム開発 | AI開発 |
|---|---|---|
| 出発点 | 画面・機能の一覧 | 業務とタスク（どこをAIに任せるか） |
| 品質の決め方 | 仕様どおり動くか | 精度の目標値と測り方 |
| データ | 入出力の項目定義 | 学習・検索に使うデータの所在・量・機密区分 |
| 誤りへの備え | バグとして修正 | 誤りを前提にした確認・差し戻しの運用 |
| 進め方 | 要件確定→開発 | 簡易要件→PoC→要件の再確定→本開発 |
IPA（情報処理推進機構）の『ユーザのための要件定義ガイド 第2版』は、「システム開発の遅延の過半は要件定義の失敗にあると言われる」と書いています。AIはこれに「精度が出るか分からない」という不確実性が加わるため、要件定義の段階でPoC（試作検証）で何を確かめるかまで決めておくのが通常の開発との大きな違いです。
業務からAIの要件に落とす手順は？6つのステップ
業務を「タスク」に分け、タスクごとにAIの向き不向きを判定してから要件を書きます。 いきなり「AIで〇〇したい」から要件を書くと、全部AIに任せるか全部人がやるかの雑な判断になり、PoCで必ず行き詰まります。当社では次の6ステップで進めています。
- 前提を確認する：予算・体制・期限、データの機密区分（クラウドで扱えるか、閉域が必要か）、つなぐ既存システム
- タスクに分解する：施策を「誰が・何を・どの順で」の単位に分ける
- AI化の向き不向きを判定する：5つの軸で評価し、4つの手段に振り分ける
- 技術を選ぶ：AIに任せるタスクに、RAG・分類・抽出・生成などを当てる
- 要件定義書を書く：機能・データ・非機能・連携・HITLを、施策や課題に紐づけて書く
- PoC計画を作る：成功KPIと撤退基準を数値で決める
前段の業務の洗い出しがまだの場合は、先に業務可視化のやり方で業務の流れと件数・工数を押さえておくと、ステップ2以降が速くなります。
ステップ2：タスクに分けないと「全部AI」になる
例えば「社内ナレッジを使って問い合わせ回答を速くする」という施策は、次のように分かれます。
- T1 過去のメール・マニュアルを集める
- T2 中身を分類・タグ付けする
- T3 検索できる形で格納する
- T4 問い合わせに対して回答の候補を出す
- T5 回答を確定して送る
施策のままでは「AIで回答する」と一括りになりますが、分けてみるとT5（送信の確定）だけは人が持つべきことがすぐに見えます。
AIに任せる仕事と人が持つ仕事は、どう見分けますか？
5つの軸で評価し、「自動化」「生成AI」「予測・分析」「人」の4つに振り分けます。 当社が業務改善の工程で使っている「AI化適性の判定フレーム」です。
| 軸 | 問い | AI向き | 人向き |
|---|---|---|---|
| 定型度 | 毎回ほぼ同じ手順か | 定型 | 毎回違う |
| 判断の複雑さ | ルールで書けるか | ルールが明確 | 経験・勘が要る |
| データ | デジタルで揃うか | デジタルで潤沢 | 紙・口頭・暗黙知 |
| 件数・頻度 | 量が多いか | 高頻度・大量 | まれ |
| 誤りの影響 | 間違えたときに取り返せるか | 影響が小さく戻せる | 影響が大きく戻せない |
| 振り分け先 | 条件 | 主な手段 |
|---|---|---|
| 自動化 | 定型 × ルール明確 × デジタル | RPA・API連携・自動集計 |
| 生成AI | 非定型だが文章を扱う（要約・分類・抽出・下書き・検索） | LLM・RAG |
| 予測・分析 | データから予測・可視化する | 予測モデル・BIダッシュボード |
| 人（HITL） | 判断・責任・関係性・例外・高リスク | 人が主導し、AIは下書き・候補提示 |
ポイントは、人に振り分けたタスクには「AI化しない理由」を必ず書くことです（例：誤回答が顧客に直接届くため、送信の確定は人）。AI化しない判断も成果物として残すと、過剰なAI化を防げるうえ、後から「なぜここは手作業なのか」と聞かれたときに答えられます。実際の案件でも、多くのタスクは「AIが下書き→人が確定」の形に落ち着きます。
業務全体のどこから手をつけるかの優先順位づけは、業務改善にAIを活用する進め方で詳しく解説しています。
AI要件定義書には何を書けばよいですか？
通常の要件定義書の項目に、精度・データ・誤り時の運用・HITLの4点を足します。 当社が使っている構成は次のとおりです。
| 項目 | 書く内容 | AI開発で特に注意する点 |
|---|---|---|
| 目的・背景 | 解決する課題、効果の目標 | 施策・課題に紐づけ、なぜ必要かを辿れるようにする |
| スコープ | 対象業務・対象外 | 「AIに任せない範囲」を明記する |
| 機能要件 | 入力→処理→出力 | 人が確認・確定する場所（HITLポイント）を書く |
| データ要件 | 必要なデータ・所在・量・形式・前処理 | 機密区分と、AIに渡してよい範囲 |
| 非機能要件 | 精度目標・応答速度・セキュリティ・可用性 | 精度は「何件を・誰が・どう測るか」まで書く |
| 連携要件 | つなぐシステム・API | 書き込みを伴う連携は確認ステップを挟む |
| 誤り時の運用 | 誤答の検知・差し戻し・改善の流れ | 誤りの記録を次の改善に回す仕組み |
精度目標は「精度90%」と書くだけでは測れません。「事前に渡していない検証用データ200件で、正しく分類できた割合が90%以上。測定は発注者が立ち会う」のように、件数・指標・測り方まで書くと、PoCの合否で揉めなくなります。
トレースを要件に埋め込む
当社の要件定義では、すべての要件を「施策番号→課題ID→業務・議事録」に紐づけます。業務→課題→施策→要件の連鎖がつながっていれば、PoCで要件を削るときに「この要件を外すと、どの課題が残るか」をすぐに判断できます。要件だけが一人歩きして、業務の痛みとずれていく事故を防ぐための仕掛けです。
HITL（人の介在）はどこに、どう設計しますか？
入口・出口・例外の3か所で、人が入るかどうかをタスクごとに決めます。 HITL（Human-in-the-loop）は、AIの処理の途中に人の確認や判断を入れる設計です。
| 介在点 | 何をするか | 例 |
|---|---|---|
| 入力ゲート | AIに渡す前に人が確認する | 機密情報・個人情報が混ざっていないか確認 |
| 出力ゲート | AIの出力を人が確定する | 回答案はAI、顧客への送信は担当者が確定 |
| 例外エスカレ | AIの自信が低い・想定外のときに人へ回す | 規程にない問い合わせは担当部署へ回付 |
公的な指針も同じ方向です。総務省・経済産業省の『AI事業者ガイドライン』は、AIに単独で判断させるだけでなく、適切なタイミングで人間の判断を介在させる利用の検討を求めています。2026年3月の更新（第1.2版）では、AIエージェントのように自律的に動くAIについて、人間の判断を介在させる仕組みの構築や、外部システムとの連携を絞る最小権限の考え方が追記されました。ガイドラインの全体像はAI事業者ガイドラインとは？で整理しています。
HITLを要件に書くときは、「誰が」「どの画面で」「何秒で判断できる形で」見るかまで決めるのがコツです。確認する人の負担が重すぎると、結局ノールックで承認され、HITLが形だけになります。PoCでは精度と同時に「人の確認にかかった時間」も測ります。
要件定義そのものをAIで支援すると、何が変わりますか？
下書きと抜け漏れ点検はAIが速く、優先順位と採否は人にしか決められない、という分担がはっきりします。 当社は、議事録から要求を抜き出し、要件に展開して、抜け漏れを点検する社内ツールを試作しました。設計で守ったのは3つの原則です。
- 根拠の引用を必須にする：AIが出した要求には、議事録のどの発言が根拠かを必ず付ける。根拠が議事録に実在しない場合は、自動で確度を下げる
- トレースはAIでなくデータベースで保証する：要求と要件の紐づけはAIに任せず、仕組みで重複や孤立を検出する
- 各工程の最後に人の関所を置く：要求の採否、要件の優先順位、矛盾の調整は人が決める
架空の議事録1本で試したところ、要求16件はすべて根拠の引用が議事録と一致し（作り話はゼロ）、要件17件はすべていずれかの要求に紐づきました。さらに抜け漏れ点検では、個人情報の同意管理・多要素認証・データ移行といった、議事録で誰も口にしていない要件の欠落を指摘しました。一方で、どの要求を今回は見送るか、部署間で食い違う要求をどう裁くかは、AIには決められません。ここが冒頭の「人が確定する」部分で、AI開発の要件定義そのものにも同じHITLの考え方が当てはまります。
現場の所感：要件定義で時間を取られるのは「書く」ことより「漏れに気づく」ことです。AIに抜け漏れの点検役を任せると、人はヒアリングの場と、採否の判断に時間を使えるようになります。ただし試作はサンプル1本での検証にとどまり、実案件での取りこぼし率は引き続き計測中です。
PoCの成功KPIと撤退基準は、要件定義の段階でどう決めますか？
PoCで確かめるのは「いちばん分からないこと」だけに絞り、合格ラインと撤退ラインを数値で先に決めます。 要件定義の最後にPoC計画を作るのは、要件の中に「やってみないと分からない」部分が必ず残るからです。
| 項目 | 決めること | 書き方の例 |
|---|---|---|
| 検証の目的 | 最大の不確実性 | 過去の回答文書から、正しい回答候補を出せるか |
| 成功KPI | 合格の数値 | 回答候補の採用率70%以上、1件あたりの対応時間30%短縮 |
| 評価方法 | 正解との比べ方 | 熟練者が作った正解データとの比較、確認時間の記録 |
| 撤退基準 | やめる条件 | 2回の改善後も採用率50%未満なら、検索対象の整備に切り替える |
| 期間・体制 | 期間と担当 | 6〜8週間、現場担当1名・情報システム1名・開発側 |
撤退基準があると、PoCが「もう少しで良くなりそう」と延々続く事態を防げます。撤退は失敗ではなく、AIでなく業務の側（データの整備や手順の見直し）を先に直すべきだと分かったという成果です。KPIの立て方は生成AIのPoCの進め方、費用の見積もりは生成AI導入の費用相場もあわせてご覧ください。
AI開発の要件定義でよくある失敗は？
多いのは「機能から入る」「精度を数値で書かない」「誤りの運用を決めない」の3つです。
- 機能から入る：「チャットボットを作る」から始めると、業務のどの手間が減るのかが曖昧なまま進む。→業務とタスクから入る
- 精度を数値で書かない：「高精度」「実用的な精度」は測れない。→件数・指標・測り方まで書く
- 誤りの運用を決めない：誤答が出たときの差し戻し先がなく、現場が使わなくなる。→出力ゲートと例外エスカレを要件に入れる
- 機密区分を後回しにする：PoCの途中で「このデータはクラウドに出せない」と分かり、構成からやり直しになる。→ステップ1で確認する
誤答を減らす具体的な設計は生成AIのハルシネーション対策で解説しています。システム導入全体の進め方は業務システム導入の進め方も参考になります。
よくある質問
Q. AIの要件定義は、発注者とベンダーのどちらが書くものですか？
業務の目的・対象範囲・人が確定する場所は発注者が決め、技術の選定や精度の見込みはベンダーと一緒に詰めるのが現実的です。少なくとも「どの業務の、どのタスクを、どこまでAIに任せたいか」は発注者側で書いておくと、見積もりの比較がしやすくなります。
Q. 要件定義の前にPoCをやってもよいですか？
簡易な要件（目的・対象タスク・成功KPI・撤退基準）を決めてからPoCを行い、結果を見て要件を確定させる順番がおすすめです。目的のないPoCは、技術的に動いたかどうかしか分からず、本番化の判断材料になりません。
Q. HITLを入れると、AIを入れる意味が薄れませんか？
人が確認するのは最終判断の部分だけで、収集・整理・下書きはAIが担うため、多くの場合で手間は大きく減ります。むしろHITLがないと、誤りへの不安から現場が使わなくなる方が損失は大きくなります。
まとめ：要件は業務から、判断は人に残す
- AI開発の要件定義は、通常の要件に精度・データ・誤り時の運用・HITLの4点を足す作業
- 出発点は機能ではなく業務。タスクに分けて5軸で判定し、自動化・生成AI・予測分析・人に振り分ける
- 要件は施策・課題に紐づけ、精度は件数と測り方まで書く
- HITLは入力・出力・例外の3か所で設計し、確認する人の負担も測る
- PoCは成功KPIと撤退基準を先に数値で決める
当社では、業務の可視化から課題の抽出、AI化の向き不向きの判定、要件定義・PoC計画までを一気通貫で支援しています。要件定義の書き方に迷ったら、まずはPoC企画の型を使って「何を確かめるか」を1枚にまとめてみてください。
▶ 生成AI PoC企画テンプレートを無料でダウンロードする（目的・対象タスク・成功KPI・撤退基準を1枚で整理できる型です）
業務改善の全体像は業務改善コンサルティング、開発支援の内容は生成AI開発・PoC支援をご覧ください。
参考資料
– 独立行政法人情報処理推進機構（IPA）『ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ』（2019年12月）
– 総務省・経済産業省『AI事業者ガイドライン（第1.1版）』（2025年3月）、同「令和7年度更新内容」（2026年3月、第1.2版で公表）
– キュリオシティ株式会社「AI化適性の判定フレーム」（業務改善の工程④AI化要件定義で使用する社内フレーム）
