AI駆動開発

AI開発 要件定義の進め方|決めるべき項目・精度要件・役割分担

編集・執筆 熊木 CMO/執行役員

  • #AI開発 要件定義
  • #AI開発 要件定義書
  • #精度要件
  • #データ要件
  • #AI開発 PoC
  • #AI開発 発注側 役割分担
  • #AI開発 要件定義 失敗
  • #AI開発における要件定義の重要性
フリップボードに書かれた「AI開発 要件定義の進め方|決めるべき項目・精度要件・役割分担」の文字

生成AIや機械学習を業務やサービスに組み込もうとすると、最初の要件定義で「何をどこまで決めればよいのか」が分からず、委託先との打ち合わせが進まないことがあります。AI開発では、通常のシステム開発のように機能を並べるだけでは要件が固まりません。AIの出力は毎回同じとは限らず、使うデータによって結果が変わり、試してみるまで判断できない項目も残るためです。

この記事では、BtoB企業のマーケティング・DX推進の担当者に向けて、AI開発の要件定義の進め方、決めるべき項目と精度要件の置き方、発注側と委託先の役割分担、失敗しやすい点と対処を順に解説します。社内で要件をまとめる際のチェックリストとしても使えるように、判断基準を表にまとめています。

AI開発の要件定義とは|通常のシステム開発との違い

要件定義とは、開発するシステムが「何のために、誰が、どの業務で、何をできればよいか」を言葉にして、発注側と委託先が合意する工程です。AI開発でもこの位置づけは変わりませんが、決め方には次の違いがあります。

出力が揺れることを前提にする

通常のシステムは、同じ入力に対して同じ結果を返すように作ります。一方でAIは、同じような入力でも出力が少しずつ変わり、一定の割合で誤りも含みます。そのため「正しく動くこと」を要件にするのではなく、「どの程度の誤りまでなら業務として受け入れられるか」「誤りをどこで見つけて直すか」を要件として書く必要があります。

データが要件の一部になる

AIの性能は、学習や参照に使うデータの量・質・鮮度に左右されます。どのデータを使えるのか、誰が用意するのか、外部のサービスに渡してよいのかが決まっていないと、設計も見積もりも進みません。AI開発では、データの扱いを機能要件と同じ重さで定義します。

試してみないと決まらない項目がある

「この業務データでどこまでの精度が出るか」は、実際に試すまで誰にも分かりません。最初からすべてを確定させようとすると、根拠のない数字を書くか、要件定義がいつまでも終わらないかのどちらかになりがちです。決められることと、検証してから決めることを分けて扱うのがAI開発の要件定義の特徴です。

要件定義を始める前に整理しておくこと

委託先に相談する前に、発注側で次の点を整理しておくと、最初の打ち合わせから具体的な話ができます。

目的を業務の言葉で書く

「AIを使って業務を効率化したい」だけでは、委託先は何を作ればよいか判断できません。「問い合わせへの一次回答を作る時間を減らしたい」「営業資料の下書き作成を担当者ごとのばらつきなく行いたい」のように、対象の業務と、何が変われば成功なのかを業務の言葉で書きます。AIを入れること自体を目的にしないことが出発点です。

決める人と関わる部門を決める

AI開発では、業務部門、情報システム部門、法務やセキュリティの担当、経営層など、判断に関わる人が多くなります。要件の最終判断を誰が行うのか、どの項目を誰が決めるのかを最初に決めておくと、後から要件が覆ることを防げます。

今の業務の流れと課題を書き出す

対象業務の始まりと終わり、関わる人、使っている資料やシステム、時間がかかっている箇所、例外的な対応が発生する場面を書き出します。AIに任せる部分と人が担う部分を切り分けるための材料になります。

AI開発の要件定義の進め方(5つのステップ)

AI開発の要件定義は、一度で固めるのではなく、検証の結果を見ながら段階的に詰めていく進め方が現実的です。基本的な流れは次のとおりです。

  1. 目的と成功の定義を決める:対象業務、達成したい状態、評価に使う業務上の指標を決めます。
  2. 変えた後の業務の流れを描く:AIがどこで使われ、誰がその結果を受け取り、どこで人が確認するかを流れとして書きます。
  3. 入力・出力・データを定義する:AIに何を渡し、何を返してほしいのか、そのために使うデータの所在と扱いのルールを決めます。
  4. 合格ラインと評価方法を仮置きする:精度要件と、それをどの評価データでどう測るかを仮の基準として置きます。
  5. 検証で確かめる項目を整理する:決まっていないこと、試してから決めることを一覧にして、PoC(概念実証)の範囲と判断基準を決めます。

ステップ4とステップ5が、通常のシステム開発との大きな違いです。合格ラインは「仮置き」とし、検証の結果を踏まえて本番の要件として確定させます。この順序を発注側と委託先で共有しておくと、「最初に決めた精度が出ない」という行き違いを減らせます。

委託先の選定前に要件を文書にまとめる場合は、AI開発のRFPに書く項目と要件の粒度もあわせて確認すると、提案依頼の段階で伝えるべき内容が整理しやすくなります。

要件定義で決めるべき項目チェックリスト

AI開発の要件定義書に盛り込む項目を、決める内容と主に決める側に分けて整理しました。すべてを最初から確定させる必要はありませんが、「未定」の項目も一覧に載せ、いつ誰が決めるかを書いておくことが重要です。

AI開発の要件定義で決めるべき項目
項目決める内容主に決める側
目的と成功の定義対象業務、達成したい状態、評価に使う業務上の指標発注側
対象範囲業務の始まりと終わり、対象外とする業務や例外発注側
利用者と利用シーン誰が、いつ、どの画面や業務の中で使うか、権限の範囲発注側
入力と出力AIに渡す情報の形式、返してほしい結果の形式と粒度発注側と委託先で協議
精度要件合格ライン、誤りの種類ごとの許容度、評価データと評価方法発注側が基準を決め、委託先が実現性を示す
データ要件データの所在、品質、取得方法、権利、外部に渡してよい範囲発注側と委託先で協議
非機能要件応答時間、利用規模、停止時の許容範囲、セキュリティ発注側と委託先で協議
人の確認と例外対応人が確認する箇所、確認する人、AIが判断できない場合の扱い発注側
運用・保守精度の監視、データやプロンプトの更新、問い合わせ窓口発注側と委託先で協議
受入条件検証・本番それぞれの段階で何を確かめれば完了とするか発注側と委託先で合意

表のとおり、目的や対象範囲、人の確認といった業務に関わる項目は発注側でなければ決められません。一方で、入力・出力の形式やデータの扱い、非機能要件は技術的な実現性と切り離せないため、委託先と協議しながら決めます。

精度要件の置き方

AI開発の要件定義で最も揉めやすいのが精度要件です。「精度を高く」「人と同等の品質で」といった書き方では、合格かどうかを判断できません。次の考え方で具体化します。

「精度」をビジネス指標に置き換える

まず、AIの精度が業務の何に効くのかを考えます。たとえば問い合わせ対応であれば「担当者が修正せずに使える回答の割合」、文書の分類であれば「人の再確認が必要になる文書の割合」のように、業務の成果に結び付く形で定義します。技術的な評価指標は委託先が提案できますが、それが業務上どの程度の効果につながるかを判断するのは発注側です。

誤りの種類ごとに許容度を分ける

AIの誤りには、「本来拾うべきものを見逃す誤り」と「拾うべきでないものを拾ってしまう誤り」のように種類があります。業務によって、どちらの誤りが重いかは異なります。見逃しが大きな損失につながる業務では見逃しを抑えることを優先し、誤検知が業務負担を増やす業務では誤検知を抑えることを優先する、といった優先順位を要件として書きます。

合格ラインは割合だけでなく「数」で書く

合格ラインを割合だけで書くと、評価に使ったデータの数や中身によって受け止め方が変わります。「評価用に用意したデータの総数のうち、修正なしで使えたものがいくつあったか」のように、母数と結果の数を明示して書くと、発注側と委託先で認識をそろえやすくなります。具体的な水準は、検証の結果と業務上の許容度を見て決めます。

評価データと評価方法を先に合意する

精度は、どのデータで測るかによって大きく変わります。評価に使うデータを誰が用意するのか、実際の業務を代表するものになっているか、例外的なケースをどの程度含めるのか、正解を誰が判定するのかを、開発の前に合意しておきます。評価方法が決まっていないと、検証の結果を見ても合格かどうかを判断できません。

出力を確定情報として扱うか、候補として扱うか

AIの出力をそのまま顧客や社外に出すのか、担当者が確認する前提の「候補」として扱うのかで、求められる精度は大きく変わります。候補として扱い、人が最終確認する設計にすれば、精度要件を現実的な水準に置きやすくなります。その場合は「誰が、何を見て、どの範囲を確認するか」まで要件に書いておきます。

データ要件と運用要件の整理

精度要件と並んで、データと運用の要件は後回しにされやすい項目です。ここが曖昧なまま開発を進めると、検証では動いたのに本番で使えない、という状況になりやすくなります。

データの所在・品質・取得方法を合意する

AIに使うデータがどのシステムに、どの形式で、どれだけあるのかを確認します。データが部門ごとに分散している、形式がそろっていない、古い情報が混ざっているといった状態であれば、整備の作業と担当を要件に含めます。継続的に新しいデータを取り込む必要がある場合は、取得の方法と頻度も決めておきます。既存の業務システムとデータを連携させる場合は、既存システムとAIを連携する方式の選び方で整理しているように、改修範囲と連携方式もあわせて検討が必要です。

データの権利とセキュリティの取り扱いを明記する

顧客情報や社外秘の情報をAIに渡してよいか、外部のAIサービスを使う場合にどの情報を送信してよいかは、作り始める前に決める必要があります。また、開発の過程で作られた学習済みのモデルやプロンプト、評価データの権利を誰が持つのかも、契約とあわせて整理しておきます。

運用ルールと本番化の条件を決める

AIは導入して終わりではなく、業務やデータの変化に合わせて精度を監視し、必要に応じて調整を続けます。精度が下がったときに誰が気づき、誰が対応するのか、プロンプトや参照データの更新を誰が行うのかを決めておきます。運用にかかる費用の考え方は、生成AIの運用保守費用の内訳と見積もりの読み方も参考になります。あわせて、「どの条件を満たせば本番として使い始めるか」を本番化の条件として書いておくと、検証から本番への判断がぶれにくくなります。

発注側と委託先の役割分担

AI開発では「専門家である委託先に任せれば要件も決めてくれる」と考えがちですが、業務の目的や許容できる誤りの範囲は、発注側にしか決められません。一方で、技術的な方式や実現性の判断は委託先の役割です。主な役割分担を次の表にまとめます。

AI開発の要件定義における発注側と委託先の役割分担
領域発注側の役割委託先の役割
目的と優先順位解決したい課題、成功の定義、必須と後回しの判断目的に対して実現可能な範囲と代替案の提示
業務の流れと例外現状の業務、例外ケース、人が確認する箇所の整理AIを組み込んだ後の流れの設計案の提示
データデータの提供、権利と社外提供可否の確認、正解の判定必要なデータの条件提示、整備方法の提案
精度要件業務上の許容度と合格ラインの決定評価指標と評価方法の提案、達成見込みの説明
技術方式制約条件(セキュリティ、利用環境、予算)の提示モデルや構成の選定、方式ごとの長所と制約の説明
検証と受入検証結果の確認、次の段階に進むかの判断検証の実施、結果と課題の報告
運用社内の運用担当と問い合わせ窓口の決定監視・改善の仕組みの提案と保守対応

要件定義そのものを委託先に支援してもらうことは可能ですが、その場合でも、目的・許容度・データの提供可否といった判断は発注側に残ります。委託先には「決めるための材料と選択肢を出してもらう」、発注側は「材料をもとに決める」という分担を意識すると、議論が前に進みやすくなります。

PoCから本番までの段階設計と契約の考え方

試してみないと決まらない項目がある以上、AI開発は段階を分けて進めるのが一般的です。代表的な段階は次のとおりです。

  • 構想・要件整理:目的、対象業務、データの有無を確認し、検証する範囲を決めます。
  • PoC(概念実証):限られたデータと範囲で、目的の精度に届く見込みがあるかを確かめます。
  • 本開発:検証の結果をもとに要件を確定させ、業務で使える形に仕上げます。
  • 運用・改善:実際の利用状況を見ながら精度や使い勝手を改善します。

段階ごとに「何を確かめれば次に進むか」を事前に決めておくことが大切です。PoCの段階では、精度の数字だけでなく、データの準備にかかる手間、人の確認作業の負担、既存業務への組み込みやすさも判断材料に含めます。検証の結果、目的に届かないと分かった場合に、範囲を絞って進める・方式を変える・中止するといった判断の基準も決めておくと、検証が長引くことを防げます。

また、段階によって成果物の確定度が異なるため、契約形態や検収条件も段階ごとに考える必要があります。詳しくはAI開発の契約形態の選び方と段階別の検収条件で整理しています。帳票の読み取りのように精度検証が特に重要になるテーマでは、AI-OCRの精度検証とPoCの進め方も具体的な検討の参考になります。

AI開発の要件定義で失敗しやすい点と対処

AI開発の要件定義でつまずきやすい点を、起きやすい状況と対処に分けて整理しました。自社の検討状況と照らし合わせて確認してください。

AI開発の要件定義で失敗しやすい点と対処
つまずき起きやすい状況対処
AI導入自体が目的になる「AIで何かできないか」から検討が始まっている対象業務と成功の定義を業務の言葉で書き直す
「精度を高く」としか書いていない合格ラインと評価方法が決まっていない業務上の指標、誤りの種類ごとの許容度、評価データを決める
PoCと本番の差を考慮していない整ったデータで検証し、本番のデータや利用規模を想定していない本番に近いデータと条件で評価し、本番化の条件を別に定める
データの準備を後回しにするデータの所在や社外提供の可否を確認しないまま設計に入る要件定義の初期にデータの棚卸しと権利確認を行う
人の確認工程を設計していないAIの出力をそのまま使う前提で業務を組んでいる出力を候補として扱い、確認する人と範囲を決める
要件が決めた後も変わり続ける決める人が不明確で、関係部門から後で要望が追加される決める人と変更の手続きを決め、変更は次の段階で扱う
運用の担当が決まっていない開発の完了をゴールにしている精度の監視、更新作業、問い合わせ窓口の担当を要件に含める

これらのつまずきの多くは、「決められないこと」を未定のまま放置するか、根拠なく決めてしまうことから生じます。未定の項目は一覧にして、いつ・誰が・何を根拠に決めるかを書いておくだけでも、後工程での手戻りを抑えられます。

特に要件の変更は、AI開発ではある程度避けられません。検証の結果を見て要件を見直すこと自体は正しい進め方ですが、変更のたびに範囲が広がると、期間と費用が膨らみます。「変更は決める人の承認を経る」「今の段階で扱わない要望は次の段階の検討事項として記録する」といったルールを、要件定義の段階で合意しておくことをおすすめします。

よくある質問

AI開発の要件定義は通常のシステム開発と何が違いますか?

AIの出力は揺れや誤りを含むため、「正しく動くこと」ではなく「どの程度の誤りまで許容し、どこで人が確認するか」を要件として定義する点が大きな違いです。また、データの所在や権利が要件の一部になり、試してみないと決まらない項目を検証で確かめながら詰めていきます。

精度要件はどのように決めればよいですか?

まず精度を「修正せずに使える割合」のような業務上の指標に置き換え、誤りの種類ごとの許容度を決めます。そのうえで評価データと評価方法を発注側と委託先で合意し、合格ラインは検証の結果を踏まえて確定させます。

要件定義の前にPoCは必要ですか?

目的の精度に届くかどうかが分からない場合は、要件をすべて確定させる前に、範囲を絞ったPoCで見込みを確かめるのが現実的です。ただし、PoCの前にも目的、対象業務、評価方法、次の段階に進む判断基準は決めておく必要があります。

要件定義は自社だけで完結できますか?

目的や対象業務、許容できる誤りの範囲、データの提供可否は自社で決められますし、決めるべき項目です。一方で、技術方式や実現性、評価方法の設計は専門的な判断を伴うため、委託先や外部の支援者と協議しながら進めるほうが確実です。

まとめ|決められることと検証で決めることを分けて進める

AI開発の要件定義では、出力が揺れること、データが要件の一部になること、試さないと決まらない項目があることを前提にする必要があります。押さえておきたいポイントは次のとおりです。

  • 目的を業務の言葉で書き、決める人を最初に決める
  • 精度要件は業務上の指標に置き換え、誤りの種類ごとの許容度と評価方法を合意する
  • データの所在・品質・権利と、運用の担当を早い段階で整理する
  • 業務の判断は発注側、技術の判断と選択肢の提示は委託先という分担を意識する
  • PoCから本番までの段階ごとに、次に進む条件を決めておく

ハイ・ヴァーチュ・ラボは、AI駆動開発・システムインテグレーション・マーケティングを一気通貫で提供するテクノロジーパートナーです。AI開発の要件整理や開発・保守の体制について検討している場合は、システムインテグレーション(開発・保守)のページもご覧ください。

また、AI活用の目的がマーケティングや営業の成果向上にある場合は、まず現状の課題を整理することが要件定義の出発点になります。どこに課題があり、何から着手すべきかを確認したい方は、無料マーケティング診断をご活用ください。

コラム一覧へ戻る

CONTACT

AI駆動開発・システム開発・Webマーケティングのご相談を承ります

課題の整理からご一緒します。まずはお気軽にお問い合わせください。

無料相談はこちら