生成AIや機械学習を業務やサービスに組み込もうとすると、最初の要件定義で「何をどこまで決めればよいのか」が分からず、委託先との打ち合わせが進まないことがあります。AI開発では、通常のシステム開発のように機能を並べるだけでは要件が固まりません。AIの出力は毎回同じとは限らず、使うデータによって結果が変わり、試してみるまで判断できない項目も残るためです。
この記事では、BtoB企業のマーケティング・DX推進の担当者に向けて、AI開発の要件定義の進め方、決めるべき項目と精度要件の置き方、発注側と委託先の役割分担、失敗しやすい点と対処を順に解説します。社内で要件をまとめる際のチェックリストとしても使えるように、判断基準を表にまとめています。
要件定義とは、開発するシステムが「何のために、誰が、どの業務で、何をできればよいか」を言葉にして、発注側と委託先が合意する工程です。AI開発でもこの位置づけは変わりませんが、決め方には次の違いがあります。
通常のシステムは、同じ入力に対して同じ結果を返すように作ります。一方でAIは、同じような入力でも出力が少しずつ変わり、一定の割合で誤りも含みます。そのため「正しく動くこと」を要件にするのではなく、「どの程度の誤りまでなら業務として受け入れられるか」「誤りをどこで見つけて直すか」を要件として書く必要があります。
AIの性能は、学習や参照に使うデータの量・質・鮮度に左右されます。どのデータを使えるのか、誰が用意するのか、外部のサービスに渡してよいのかが決まっていないと、設計も見積もりも進みません。AI開発では、データの扱いを機能要件と同じ重さで定義します。
「この業務データでどこまでの精度が出るか」は、実際に試すまで誰にも分かりません。最初からすべてを確定させようとすると、根拠のない数字を書くか、要件定義がいつまでも終わらないかのどちらかになりがちです。決められることと、検証してから決めることを分けて扱うのがAI開発の要件定義の特徴です。
委託先に相談する前に、発注側で次の点を整理しておくと、最初の打ち合わせから具体的な話ができます。
「AIを使って業務を効率化したい」だけでは、委託先は何を作ればよいか判断できません。「問い合わせへの一次回答を作る時間を減らしたい」「営業資料の下書き作成を担当者ごとのばらつきなく行いたい」のように、対象の業務と、何が変われば成功なのかを業務の言葉で書きます。AIを入れること自体を目的にしないことが出発点です。
AI開発では、業務部門、情報システム部門、法務やセキュリティの担当、経営層など、判断に関わる人が多くなります。要件の最終判断を誰が行うのか、どの項目を誰が決めるのかを最初に決めておくと、後から要件が覆ることを防げます。
対象業務の始まりと終わり、関わる人、使っている資料やシステム、時間がかかっている箇所、例外的な対応が発生する場面を書き出します。AIに任せる部分と人が担う部分を切り分けるための材料になります。
AI開発の要件定義は、一度で固めるのではなく、検証の結果を見ながら段階的に詰めていく進め方が現実的です。基本的な流れは次のとおりです。
ステップ4とステップ5が、通常のシステム開発との大きな違いです。合格ラインは「仮置き」とし、検証の結果を踏まえて本番の要件として確定させます。この順序を発注側と委託先で共有しておくと、「最初に決めた精度が出ない」という行き違いを減らせます。
委託先の選定前に要件を文書にまとめる場合は、AI開発のRFPに書く項目と要件の粒度もあわせて確認すると、提案依頼の段階で伝えるべき内容が整理しやすくなります。
AI開発の要件定義書に盛り込む項目を、決める内容と主に決める側に分けて整理しました。すべてを最初から確定させる必要はありませんが、「未定」の項目も一覧に載せ、いつ誰が決めるかを書いておくことが重要です。
| 項目 | 決める内容 | 主に決める側 |
|---|---|---|
| 目的と成功の定義 | 対象業務、達成したい状態、評価に使う業務上の指標 | 発注側 |
| 対象範囲 | 業務の始まりと終わり、対象外とする業務や例外 | 発注側 |
| 利用者と利用シーン | 誰が、いつ、どの画面や業務の中で使うか、権限の範囲 | 発注側 |
| 入力と出力 | AIに渡す情報の形式、返してほしい結果の形式と粒度 | 発注側と委託先で協議 |
| 精度要件 | 合格ライン、誤りの種類ごとの許容度、評価データと評価方法 | 発注側が基準を決め、委託先が実現性を示す |
| データ要件 | データの所在、品質、取得方法、権利、外部に渡してよい範囲 | 発注側と委託先で協議 |
| 非機能要件 | 応答時間、利用規模、停止時の許容範囲、セキュリティ | 発注側と委託先で協議 |
| 人の確認と例外対応 | 人が確認する箇所、確認する人、AIが判断できない場合の扱い | 発注側 |
| 運用・保守 | 精度の監視、データやプロンプトの更新、問い合わせ窓口 | 発注側と委託先で協議 |
| 受入条件 | 検証・本番それぞれの段階で何を確かめれば完了とするか | 発注側と委託先で合意 |
表のとおり、目的や対象範囲、人の確認といった業務に関わる項目は発注側でなければ決められません。一方で、入力・出力の形式やデータの扱い、非機能要件は技術的な実現性と切り離せないため、委託先と協議しながら決めます。
AI開発の要件定義で最も揉めやすいのが精度要件です。「精度を高く」「人と同等の品質で」といった書き方では、合格かどうかを判断できません。次の考え方で具体化します。
まず、AIの精度が業務の何に効くのかを考えます。たとえば問い合わせ対応であれば「担当者が修正せずに使える回答の割合」、文書の分類であれば「人の再確認が必要になる文書の割合」のように、業務の成果に結び付く形で定義します。技術的な評価指標は委託先が提案できますが、それが業務上どの程度の効果につながるかを判断するのは発注側です。
AIの誤りには、「本来拾うべきものを見逃す誤り」と「拾うべきでないものを拾ってしまう誤り」のように種類があります。業務によって、どちらの誤りが重いかは異なります。見逃しが大きな損失につながる業務では見逃しを抑えることを優先し、誤検知が業務負担を増やす業務では誤検知を抑えることを優先する、といった優先順位を要件として書きます。
合格ラインを割合だけで書くと、評価に使ったデータの数や中身によって受け止め方が変わります。「評価用に用意したデータの総数のうち、修正なしで使えたものがいくつあったか」のように、母数と結果の数を明示して書くと、発注側と委託先で認識をそろえやすくなります。具体的な水準は、検証の結果と業務上の許容度を見て決めます。
精度は、どのデータで測るかによって大きく変わります。評価に使うデータを誰が用意するのか、実際の業務を代表するものになっているか、例外的なケースをどの程度含めるのか、正解を誰が判定するのかを、開発の前に合意しておきます。評価方法が決まっていないと、検証の結果を見ても合格かどうかを判断できません。
AIの出力をそのまま顧客や社外に出すのか、担当者が確認する前提の「候補」として扱うのかで、求められる精度は大きく変わります。候補として扱い、人が最終確認する設計にすれば、精度要件を現実的な水準に置きやすくなります。その場合は「誰が、何を見て、どの範囲を確認するか」まで要件に書いておきます。
精度要件と並んで、データと運用の要件は後回しにされやすい項目です。ここが曖昧なまま開発を進めると、検証では動いたのに本番で使えない、という状況になりやすくなります。
AIに使うデータがどのシステムに、どの形式で、どれだけあるのかを確認します。データが部門ごとに分散している、形式がそろっていない、古い情報が混ざっているといった状態であれば、整備の作業と担当を要件に含めます。継続的に新しいデータを取り込む必要がある場合は、取得の方法と頻度も決めておきます。既存の業務システムとデータを連携させる場合は、既存システムとAIを連携する方式の選び方で整理しているように、改修範囲と連携方式もあわせて検討が必要です。
顧客情報や社外秘の情報をAIに渡してよいか、外部のAIサービスを使う場合にどの情報を送信してよいかは、作り始める前に決める必要があります。また、開発の過程で作られた学習済みのモデルやプロンプト、評価データの権利を誰が持つのかも、契約とあわせて整理しておきます。
AIは導入して終わりではなく、業務やデータの変化に合わせて精度を監視し、必要に応じて調整を続けます。精度が下がったときに誰が気づき、誰が対応するのか、プロンプトや参照データの更新を誰が行うのかを決めておきます。運用にかかる費用の考え方は、生成AIの運用保守費用の内訳と見積もりの読み方も参考になります。あわせて、「どの条件を満たせば本番として使い始めるか」を本番化の条件として書いておくと、検証から本番への判断がぶれにくくなります。
AI開発では「専門家である委託先に任せれば要件も決めてくれる」と考えがちですが、業務の目的や許容できる誤りの範囲は、発注側にしか決められません。一方で、技術的な方式や実現性の判断は委託先の役割です。主な役割分担を次の表にまとめます。
| 領域 | 発注側の役割 | 委託先の役割 |
|---|---|---|
| 目的と優先順位 | 解決したい課題、成功の定義、必須と後回しの判断 | 目的に対して実現可能な範囲と代替案の提示 |
| 業務の流れと例外 | 現状の業務、例外ケース、人が確認する箇所の整理 | AIを組み込んだ後の流れの設計案の提示 |
| データ | データの提供、権利と社外提供可否の確認、正解の判定 | 必要なデータの条件提示、整備方法の提案 |
| 精度要件 | 業務上の許容度と合格ラインの決定 | 評価指標と評価方法の提案、達成見込みの説明 |
| 技術方式 | 制約条件(セキュリティ、利用環境、予算)の提示 | モデルや構成の選定、方式ごとの長所と制約の説明 |
| 検証と受入 | 検証結果の確認、次の段階に進むかの判断 | 検証の実施、結果と課題の報告 |
| 運用 | 社内の運用担当と問い合わせ窓口の決定 | 監視・改善の仕組みの提案と保守対応 |
要件定義そのものを委託先に支援してもらうことは可能ですが、その場合でも、目的・許容度・データの提供可否といった判断は発注側に残ります。委託先には「決めるための材料と選択肢を出してもらう」、発注側は「材料をもとに決める」という分担を意識すると、議論が前に進みやすくなります。
試してみないと決まらない項目がある以上、AI開発は段階を分けて進めるのが一般的です。代表的な段階は次のとおりです。
段階ごとに「何を確かめれば次に進むか」を事前に決めておくことが大切です。PoCの段階では、精度の数字だけでなく、データの準備にかかる手間、人の確認作業の負担、既存業務への組み込みやすさも判断材料に含めます。検証の結果、目的に届かないと分かった場合に、範囲を絞って進める・方式を変える・中止するといった判断の基準も決めておくと、検証が長引くことを防げます。
また、段階によって成果物の確定度が異なるため、契約形態や検収条件も段階ごとに考える必要があります。詳しくはAI開発の契約形態の選び方と段階別の検収条件で整理しています。帳票の読み取りのように精度検証が特に重要になるテーマでは、AI-OCRの精度検証とPoCの進め方も具体的な検討の参考になります。
AI開発の要件定義でつまずきやすい点を、起きやすい状況と対処に分けて整理しました。自社の検討状況と照らし合わせて確認してください。
| つまずき | 起きやすい状況 | 対処 |
|---|---|---|
| AI導入自体が目的になる | 「AIで何かできないか」から検討が始まっている | 対象業務と成功の定義を業務の言葉で書き直す |
| 「精度を高く」としか書いていない | 合格ラインと評価方法が決まっていない | 業務上の指標、誤りの種類ごとの許容度、評価データを決める |
| PoCと本番の差を考慮していない | 整ったデータで検証し、本番のデータや利用規模を想定していない | 本番に近いデータと条件で評価し、本番化の条件を別に定める |
| データの準備を後回しにする | データの所在や社外提供の可否を確認しないまま設計に入る | 要件定義の初期にデータの棚卸しと権利確認を行う |
| 人の確認工程を設計していない | AIの出力をそのまま使う前提で業務を組んでいる | 出力を候補として扱い、確認する人と範囲を決める |
| 要件が決めた後も変わり続ける | 決める人が不明確で、関係部門から後で要望が追加される | 決める人と変更の手続きを決め、変更は次の段階で扱う |
| 運用の担当が決まっていない | 開発の完了をゴールにしている | 精度の監視、更新作業、問い合わせ窓口の担当を要件に含める |
これらのつまずきの多くは、「決められないこと」を未定のまま放置するか、根拠なく決めてしまうことから生じます。未定の項目は一覧にして、いつ・誰が・何を根拠に決めるかを書いておくだけでも、後工程での手戻りを抑えられます。
特に要件の変更は、AI開発ではある程度避けられません。検証の結果を見て要件を見直すこと自体は正しい進め方ですが、変更のたびに範囲が広がると、期間と費用が膨らみます。「変更は決める人の承認を経る」「今の段階で扱わない要望は次の段階の検討事項として記録する」といったルールを、要件定義の段階で合意しておくことをおすすめします。
AIの出力は揺れや誤りを含むため、「正しく動くこと」ではなく「どの程度の誤りまで許容し、どこで人が確認するか」を要件として定義する点が大きな違いです。また、データの所在や権利が要件の一部になり、試してみないと決まらない項目を検証で確かめながら詰めていきます。
まず精度を「修正せずに使える割合」のような業務上の指標に置き換え、誤りの種類ごとの許容度を決めます。そのうえで評価データと評価方法を発注側と委託先で合意し、合格ラインは検証の結果を踏まえて確定させます。
目的の精度に届くかどうかが分からない場合は、要件をすべて確定させる前に、範囲を絞ったPoCで見込みを確かめるのが現実的です。ただし、PoCの前にも目的、対象業務、評価方法、次の段階に進む判断基準は決めておく必要があります。
目的や対象業務、許容できる誤りの範囲、データの提供可否は自社で決められますし、決めるべき項目です。一方で、技術方式や実現性、評価方法の設計は専門的な判断を伴うため、委託先や外部の支援者と協議しながら進めるほうが確実です。
AI開発の要件定義では、出力が揺れること、データが要件の一部になること、試さないと決まらない項目があることを前提にする必要があります。押さえておきたいポイントは次のとおりです。
ハイ・ヴァーチュ・ラボは、AI駆動開発・システムインテグレーション・マーケティングを一気通貫で提供するテクノロジーパートナーです。AI開発の要件整理や開発・保守の体制について検討している場合は、システムインテグレーション(開発・保守)のページもご覧ください。
また、AI活用の目的がマーケティングや営業の成果向上にある場合は、まず現状の課題を整理することが要件定義の出発点になります。どこに課題があり、何から着手すべきかを確認したい方は、無料マーケティング診断をご活用ください。