AI開発で失敗しない要件定義の書き方｜通常のシステム開発との3つの違い

AI開発を外注しようとして要件定義書を書き始めると、「通常のシステム開発と同じやり方でよいのか？」という疑問を抱く発注者は少なくありません。

実は、AI開発の要件定義には通常のシステム開発と大きく異なる3つのポイントがあります。この3点を要件定義書に明文化しておかないと、開発が完了した後に「こんなはずじゃなかった」という認識のズレや、「精度が低い」「学習データで問題が起きた」といったトラブルに発展するリスクがあります。

本記事では、AI開発特有の3つの要件（精度要件・学習データ要件・ハルシネーション対策）を発注者がどう仕様書に記載すればよいかを解説します。また、すぐに使えるチェックリスト形式のテンプレートも提供します。

なお、要件定義の基本的な進め方（ステップ・発注者の役割・よくある失敗）については、システム開発の要件定義を成功させる完全ガイドを合わせてご覧ください。

Contents — 目次

AI開発の要件定義が通常と異なる理由
違い①：精度要件はビジネス言語で書く
違い②：学習データ要件を明文化する
違い③：ハルシネーション対策を要件に入れる
AI開発要件定義書チェックリスト
まとめ
画像指示

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

AI導入を検討しているが、何から始めればよいか分からない
ベンダーの選び方や費用感がつかめず、判断できない
社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

入力いただいたメールアドレスにPDFをお送りします。

AI開発の要件定義が通常と異なる理由

通常のシステム開発は「ルールベース」で動きます。「○○の場合は××する」という条件分岐を事前に決め、その通りに動くシステムを作ります。仕様書に書いた内容がそのまま実装されるため、「仕様通りに動いているか」を確認するテストで品質を保証できます。

一方、AIシステムは「確率的」に動きます。大量のデータから学習したパターンに基づいて判断するため、同じ入力に対して必ずしも同じ結果を返すとは限りませんし、学習データの質によって精度が大きく変わります。また、特定のケースでは事実と異なる情報を出力する（ハルシネーション）リスクもあります。

このような特性から、発注者にとっての具体的なリスクが3つ生まれます。

精度リスク: 「○○の分類精度を○%以上にする」という要件を適切に定義しないと、開発完了後に「思っていた精度と違う」という認識のズレが生じる
データリスク: 学習データの権利・品質・量を事前に決めておかないと、開発途中でデータ不足や権利問題が発覚し、プロジェクトが遅延する
ハルシネーションリスク: AIが誤った情報を出力した場合の動作を要件化していないと、実運用でトラブルが発生した際に責任の範囲が曖昧になる

この3つのリスクを事前に要件定義書で明文化しておくことが、「言った・言わない」トラブルを防ぐ最大の対策です。

違い①：精度要件はビジネス言語で書く

AIの「精度」は複数の意味を持つ

AIの精度を表す指標には「正解率」「適合率」「再現率」「F値」など複数の概念があります。開発会社と要件を合意する際、「精度90%以上」とだけ書いてしまうと、どの指標を指しているのかが不明確になります。

しかし発注者がこれらの技術用語をすべて理解する必要はありません。代わりに、ビジネス上の判断基準として精度要件を言語化する方法が有効です。

たとえば、メール自動振り分けシステムを作る場合:

❌ 「分類精度は正解率95%以上」（何の指標かが不明確）
✅ 「メール1,000件を処理した場合、950件以上を正しいカテゴリに分類できること。誤分類が50件以下の場合は許容範囲とする」

このように「何件中何件が正しくできればよいか」という形で表現すると、開発会社との合意がとりやすくなります。

精度要件の書き方で押さえるべき2点

①精度未達の場合の対応を決めておく

「開発完了後に精度目標を達成していなかった場合、何回まで修正対応を行うか」を要件定義書に明記します。修正回数・修正期間・精度未達の判定基準を事前に合意しておくことで、リリース後のトラブルを防げます。

②運用後の精度劣化対応を定義する

AIは学習時のデータに基づいて動くため、時間の経過とともに現実のデータと乖離し、精度が下がることがあります（「ドリフト」と呼ばれます）。定期的なモデルの再学習や精度の評価サイクルを要件として定義しておくと、長期的な運用リスクを低減できます。

違い②：学習データ要件を明文化する

発注者が提供するデータの仕様を決める

AI開発では、発注者が学習データを提供するケースが多くあります。「データはこちらで用意します」とだけ伝えると、開発会社は「どんなデータが来るか」を事前に設計できず、プロジェクトが遅延する原因になります。

要件定義書には以下の項目を明記します。

項目	内容の例
データ形式	CSV形式、1行1レコード、文字コードUTF-8
ラベル（正解データ）の有無	あり（社内でアノテーション済み）/ なし（ラベル付け作業を開発会社に依頼）
データ量（目安）	学習用：5,000件以上、テスト用：1,000件以上
データ品質基準	欠損値は全体の5%以内、ラベルの一致率は95%以上

SCROLL→

データの権利・個人情報の扱いを明記する

自社の顧客データや業務データを学習に使う場合、以下の点を仕様書に明記します。

著作権・データ所有権の確認 「学習データに使用するデータの著作権・所有権は発注者に帰属しており、開発会社への提供は本プロジェクト内での利用に限定される」という旨を契約・仕様書に明記します。

個人情報の扱い 顧客情報を含むデータを使用する場合は、個人情報保護法に基づき、目的外利用の禁止や匿名化処理の要件を定義します。

開発完了後のデータ削除 開発完了後に提供したデータを開発会社のサーバーから削除するよう、削除確認の手続きを要件として定義します。

データ準備スケジュールを要件化する

学習データが計画通りに提供されないと、AI開発のスケジュールは大きくずれます。「データ提供完了：○月○日まで」という形でスケジュールを要件定義書に記載し、プロジェクト計画に組み込みます。

違い③：ハルシネーション対策を要件に入れる

ハルシネーションとは何か

ハルシネーションとは、生成AIが学習データから推論した内容をもとに、事実と異なる情報を自信を持って出力する現象です。たとえば、存在しない会社名・法律・統計数値を正確そうに答えるケースがあります。

AIを顧客対応や情報提供に使う場合、ハルシネーションによる誤情報の拡散が問題になります。通常のシステム開発では「バグがなければ正しく動く」ですが、AI開発では「バグがなくても誤った情報を出力する可能性がある」という前提で要件を組む必要があります。

ハルシネーション対策の要件化：フォールバック動作を決める

「AIが低確信度の回答を返した場合」の動作を、要件定義書に具体的に記載します。

フォールバック動作の例

「AIの確信スコアが○%未満の場合、回答の代わりに『担当者に確認します』というメッセージを表示する」
「AIが回答できないと判断した質問は、人間のオペレーターに転送する」
「AIの回答には必ず情報ソースのURLを付記する（事後検証を可能にする）」

フォールバック動作を定義しておくことで、AIが誤った情報を出力した際の影響範囲を最小化できます。

Human-in-the-Loop（人間の確認フロー）を要件化する

医療診断支援・法律解釈・金融判断など、ミスが重大な結果につながるユースケースでは、AIの判断を人間が最終確認する工程を業務フローとして要件化します。

「AIが分類した結果は、最終的に担当者が確認してから実行する」というフローを要件定義書に記載することで、AIの誤判断による被害を防ぐ運用設計ができます。

AI開発要件定義書チェックリスト

要件定義書を作成・レビューする際に使えるチェックリストです。

精度要件チェックリスト

精度目標がビジネス言語（「○件中○件以上」）で表現されているか
精度の測定方法・測定タイミングが定義されているか
精度未達の場合の修正対応回数・期間が定義されているか
運用後の精度劣化への対応（再学習サイクル等）が定義されているか

学習データ要件チェックリスト

データ形式（ファイル形式・文字コード・構造）が定義されているか
ラベル（正解データ）の有無と品質基準が定義されているか
必要なデータ量（学習用・テスト用）が定義されているか
データの著作権・所有権が確認・記載されているか
個人情報を含む場合、保護措置が定義されているか
開発完了後のデータ削除・返却が明記されているか
データ提供スケジュールがプロジェクト計画に組み込まれているか

ハルシネーション対策チェックリスト

AIの低確信度時のフォールバック動作が定義されているか
AIが回答できない場合のユーザー向け表示が定義されているか
誤情報を出力した場合の責任範囲・対応フローが定義されているか
人間の最終確認フロー（Human-in-the-Loop）が必要か検討されているか

まとめ

AI開発の要件定義で通常のシステム開発と異なる3つのポイントをまとめます。

要件の種類	通常のシステム開発	AI開発
精度要件	バグゼロ＝品質保証	ビジネス言語で目標値を定義し、精度未達時の対応も明記
データ要件	データの仕様は最小限	学習データの形式・量・権利・スケジュールを明記
誤出力対策	基本的に定義不要	フォールバック動作とHuman-in-the-Loopを要件化

SCROLL→

この3点を要件定義書に明文化しておくことで、「言った・言わない」のトラブルを防ぎ、AI開発プロジェクトを成功に導く確率を高めることができます。

秋霜堂株式会社では、AI開発の要件定義フェーズから発注者に伴走し、技術的な要件をビジネス言語に翻訳する支援を行っています。AI開発の要件定義でお困りの場合は、お気軽にご相談ください。