AI開発の要件定義｜通常のシステム開発と違う決め方と、精度の目標・評価データ・人の確認の入れ方を解説

「AIを使ったシステムを作りたいが、要件定義で何を決めればよいかわからない」「開発会社に『精度はやってみないとわからない』と言われて、発注の判断ができない」。AIを組み込んだシステムの開発では、通常の業務システムと同じ感覚で要件を決めようとして、つまずくことがよくあります。

この記事では、AI開発の要件定義が通常のシステム開発とどう違うのかを整理し、発注者が決めておくべき4つのこと（精度の目標、評価データ、人の確認の入れ方、失敗したときの扱い）を、具体的な決め方とあわせて説明します。

AI開発の要件定義とは

AI開発の要件定義とは、AIを組み込んだシステムで「何を、どの程度の正しさで、どのような運用のもとで実現するか」を、発注者と開発会社のあいだで決める作業です。画面や機能を決める点は通常の要件定義と同じですが、それに加えて、AIの出力の正しさと、間違いへの備えを決める必要があります。

通常のシステムは、決められたルールどおりに動きます。「この条件ならこの金額を表示する」と決めれば、毎回その通りに動き、動かなければ不具合です。一方、AI、特に生成AI（文章などを作り出すAI。中心にあるのはLLM＝大規模言語モデルと呼ばれる仕組み）は、学習した内容から確率的に答えを作るため、同じ質問でも答えが少し変わることがあり、一定の割合で間違えます。

経済産業省の「AIの利用・開発に関する契約チェックリスト」（2025年2月）でも、AIモデルはデータに基づいて帰納的に作られるため、完成の基準を決めたり性能を保証したりすることが必ずしも容易でないこと、出力の不確実性を踏まえた設計が求められることが指摘されています。要件定義は、この「不確実さ」を前提に組み立てる必要があります。

関連記事要件定義とは？目的・流れ・要件定義書の書き方を解説

通常のシステム開発との違い

画面、権限、既存システムとの連携、性能や可用性などの非機能要件（機能以外の品質の要件）は、通常の要件定義と同じように決めます。違うのは、AIが担う部分について「正しさ」と「間違いへの備え」を加えて決める点です。以下、その4つを順に説明します。

決めること1：精度の目標

「精度の高いAIがほしい」では要件になりません。業務のどの単位で、何を正解とし、何％以上なら使えるかを決めます。

業務の言葉で決める

AIの評価には専門的な指標がいろいろありますが、発注者は業務の言葉で決めれば十分です。たとえば次のような形です。

• 帳票の読み取り：「注文書の品番・数量・納期の3項目が、すべて正しく読み取れた件数の割合が9割以上」
• 社内文書の検索・回答：「よくある質問100問のうち、根拠の文書が正しく示され、内容に誤りがない回答が8割以上」
• 分類・振り分け：「問い合わせメールを担当部署に振り分けたとき、間違った部署に送る割合が5％未満」

間違いの「重さ」も決める

同じ1件の間違いでも、業務への影響は違います。金額や数量の誤りは重大でも、表記の揺れは軽微かもしれません。「これだけは間違えてはいけない項目」と「多少の誤りは許せる項目」を分けて目標を決めると、現実的な要件になります。

決めること2：評価データ

評価データとは、AIの精度を測るための「問題と正解のセット」です。たとえば、実際の注文書100枚と、それぞれの正しい読み取り結果。よくある質問100問と、それぞれの正しい答えと根拠の文書。これがないと、精度の目標を決めても、達成したかどうかを確かめられません。

1. 実際の業務から集めるきれいなサンプルだけでなく、手書き、かすれ、例外的な書式、言い回しの違う質問など、現場で実際に起きるものを含めます
2. 正解をつける業務を知っている担当者が正解を決めます。判断が分かれるものは、そのルールも書き残します
3. 使い方を分ける開発中の調整に使うデータと、最終確認（受け入れ）に使うデータを分けます。同じデータで調整と確認をすると、実際より良い結果に見えてしまいます
4. 件数の目安を決める業務の種類の多さによりますが、少なすぎると結果が偶然に左右されます。試行では数十〜数百件程度から始めるのが一般的です

評価データの準備は、発注者側の作業になる部分が多く、要件定義の段階で「誰が、いつまでに、何件用意するか」を決めておかないと、開発が止まる原因になります。個人情報を含む書類を使う場合は、マスキング（伏せ字）の要否や、開発会社への提供方法もあわせて決めます。

関連記事「データがないとAIは使えない」の誤解｜生成AI時代に本当に必要なデータと、小さく始める準備の進め方

決めること3：人の確認の入れ方

AIの結果をそのまま使うのか、人が確認してから使うのか。この設計が、業務での使いやすさと安全性を大きく左右します。

要件定義では、どのパターンにするかに加えて、確認画面に何を表示するか（元の書類の画像と読み取り結果を並べる、回答の根拠となった文書を示すなど）も決めます。確認しやすい画面かどうかで、確認にかかる時間が大きく変わり、導入効果に直結します。

最初は全件確認から始め、精度が安定していることを確かめてから条件つき確認に移る、という段階的な進め方も有効です。その場合、「どの数字が出たら確認を減らすか」も要件として決めておきます。

決めること4：失敗したときの扱い

AIは一定の割合で間違え、外部のAIサービスが一時的に使えなくなることもあります。失敗したときにどうなるかを決めておくことが、通常のシステム以上に重要です。

• AIが答えられないとき：「わかりません」と返す、担当者に引き継ぐ、手入力の画面に切り替えるなど、代わりの流れを決めます
• AIが間違えたとき：誤りに気づいた人が報告する方法と、修正の手順を決めます。報告された誤りは評価データに加えて、改善に使います
• AIサービスが止まったとき：外部のAPIが応答しない場合に、処理を待たせるのか、手作業に切り替えるのかを決めます
• 責任の範囲：AIの出力を最終的に確定するのは誰か、誤りによる損害をどう扱うかを、契約もあわせて整理します
• 記録：AIへの入力と出力、人が修正した内容を、どの程度の期間残すかを決めます。改善と原因調査に必要です

責任の範囲や契約の条項は、法律の判断を含むため、最終的には弁護士など専門家に確認してください。

AI開発の要件定義の進め方

AIの部分は、開発前にすべてを確定できません。そのため、試行（PoC：本格導入の前に小さく試して効果や実現性を確かめること）で確かめてから、本開発の要件を確定する段階的な進め方が向いています。

1. 業務の整理対象業務の流れ、件数、作業時間、AIに任せたい範囲を整理する
2. 仮の要件と評価方法を決める精度の目標、評価データ、人の確認の入れ方、失敗時の扱いを仮決めする
3. 試行（PoC）評価データで精度を測り、確認にかかる時間や費用も確かめる
4. 要件の確定試行の結果を見て、目標の数字やAIに任せる範囲を見直し、本開発の要件を確定する
5. 本開発・受け入れ受け入れ用の評価データで目標を満たすかを確認する

契約も、試行と本開発を分けて結ぶことが多く、試行は成果の完成を約束しない準委任契約、本開発は範囲によって請負契約や準委任契約を組み合わせる、という形がよく使われます。

関連記事PoC（概念実証）の進め方と失敗しないポイント

関連記事RAGの精度が出ない原因と改善策｜社内文書AIのつまずきどころと「探す・答える」の切り分け方・評価方法

発注者がやること、開発会社に任せること

発注者にしかできないのは、「業務上、何が正解で、どこまでの誤りなら許せるか」を決めることです。ここを開発会社に任せきりにすると、完成したのに現場で使えないシステムになりがちです。

関連記事要件定義の失敗例と防ぐためのポイント

よくある質問

まとめ

AI開発の要件定義では、画面や機能に加えて、精度の目標、評価データ、人の確認の入れ方、失敗したときの扱いの4つを決めます。AIは間違いをゼロにできないため、業務全体として必要な正しさを、人の確認や代わりの流れと組み合わせて確保する考え方が大切です。要件は一度で固めず、試行で確かめてから確定する段階的な進め方をおすすめします。

関連記事AIのPoCが本番にならない理由｜PoC止まりを防ぐ進め方と、合格ラインの決め方・計画書に入れる項目

参考：経済産業省「AIの利用・開発に関する契約チェックリスト」（2025年2月）、経済産業省「AI・データの利用に関する契約ガイドライン」（2018年公表、2019年改訂）。