見出し画像

AI開発の要件定義とRFP｜発注前に決める項目と提案依頼書の書き方【2026年8月最新】

株式会社AIworker

「社内データを使ったAIを作りたいので、数社から提案をもらおう」

そう考えて開発会社へ相談しても、各社から出てくる提案の範囲や金額が大きく違い、比較できないことがあります。原因は、会社ごとの技術力や価格だけではありません。発注側が示した条件が曖昧なため、各社が別々の完成形を想定している可能性があります。

AI開発では、最初からすべての仕様を固定する必要はありません。試して初めて分かる精度や使い勝手もあります。しかし、目的、対象業務、利用者、データ、合格条件、責任分界まで未定のままでは、PoCの成否さえ判断できません。

この記事では、生成AIやAIエージェントの開発を外部へ依頼する企業に向けて、要件定義の進め方、RFP（提案依頼書）に書く項目、提案を比較する基準を実務の順番で整理します。

この記事の要点

✅ AI開発の要件定義は、欲しい機能ではなく、現在の業務・解決したい課題・人とAIの役割分担から始める
✅ RFPには、目的、対象範囲、データ、非機能要件、成果物、評価方法、契約条件を同じ粒度で記載する
✅ 提案は開発費だけで比べず、前提条件、対象外、PoC後の費用、運用保守、内製移管まで含めて比較する


AI開発の要件定義とRFPの違い

要件定義とRFPは似ていますが、役割が違います。

要件定義は、自社が必要とする状態を整理する作業です。 RFPは、その内容を候補企業へ伝え、同じ条件で提案を依頼するための文書です。

IPAはRFPを、システムを導入する企業が開発会社へ提案を依頼するために作成する文書と説明しています。背景、目的、解決したい課題、求める内容、提案手続きなどを記載し、業務フローや要件一覧を補足資料として添付する構成です。詳しくはIPA「ストーリーで学ぶ要件定義実践入門」で確認できます。

RFI、RFP、要件定義を使い分ける

実現方法や市場にある選択肢が分からない段階では、RFPの前にRFI（情報提供依頼）を行う方法があります。

進め方は4段階です。

  1. 技術やサービスの選択肢が分からなければ、RFIで実現方法、事例、概算、制約を集める

  2. 解決したい課題が見えたら、要件定義で必要な状態、対象範囲、合格条件を整理する

  3. 候補企業から正式な提案を受ける段階で、RFPに共通条件、提案依頼事項、評価方法を書く

  4. 発注先と範囲が決まったら、契約で成果物、責任分界、変更、検収、権利を合意する

デジタル庁の実践ガイドブックでも、RFIは技術動向や参考事例など、要件定義に必要な情報を事業者から収集する活動として整理されています。分からないことを無理にRFPへ書くより、先に情報を集めて要件を更新する方が提案の質をそろえやすくなります。

最初に「作りたいAI」ではなく対象業務を整理する

要件定義の出発点は、「チャットボットを作る」「RAGを導入する」「AIエージェントを開発する」ではありません。これらは手段です。

最初に、現在の業務を次の順番で整理します。

  1. どの場面で仕事が発生するか

  2. 誰が何を受け取るか

  3. どの情報を確認しているか

  4. どんな判断をしているか

  5. どのシステムへ何を登録・送信しているか

  6. 誰が最終確認するか

  7. どこに時間、ミス、属人性があるか

1,000件を超える商談データを分析した傾向では、生成AIについて「何に使えばよいか分からない」という課題が28.0%で見られます。これは機能を知らないからだけではありません。業務を一連の作業に分けていないため、AIへ渡せる部分が見えていないことも原因です。

業務定義シートを1枚作る

最初は、対象業務ごとに次の表を埋めます。

対象業務が決まっていない場合は、開発の前に業務棚卸しが必要です。AIエージェントの作り方でも、業務の分解から小さく検証する流れを解説しています。

最初の対象は狭くする

「営業部門全体を効率化する」では範囲が広すぎます。「営業担当が、提案前に過去事例を検索する」のように、利用者、場面、成果物を1つに絞ります。

最初の対象に向くのは、次の条件を満たす業務です。

  • 繰り返し発生する

  • 現在の件数や所要時間を測れる

  • 入力と成果物を説明できる

  • 正解または良し悪しを担当者が判定できる

  • 誤りを人の確認で止められる

  • 1部署で試してから横展開できる

全社共通AIから始めると、利用者、データ、権限、例外が一気に増えます。1部署・1業務・1つのKPIから始める方が、失敗原因を切り分けやすくなります。

人とAIの役割分担を決める

AI開発では、「できるか」だけでなく「任せてよいか」を決めます。同じ機能でも、AIが候補を出すだけなのか、システムへ登録するのか、社外へ送信するのかで必要な統制が変わります。

検索ではAIが関連情報を探し、人が参照元を確認します。下書きではAIが文案を作り、人が内容を直して確定します。判断を伴う業務では、AIは選択肢と根拠の整理までにとどめ、意思決定は人が行います。

システムへの登録や社外への送信まで任せる場合は、実行前の承認と実行後の確認が必要です。データ削除、契約、決済、権限変更など、誤ったときに戻しにくい処理は、AIだけで完了させず権限者が実行します。

設計の基本は、下準備はAI、最終判断は人です。ただし、人が毎回すべてを作り直すなら効率化になりません。人の確認箇所、承認方法、差し戻し、例外時の停止まで要件にします。

要件を7つの領域に分ける

「回答できること」だけを要件にすると、本番運用で抜けが出ます。AI開発の要件は、次の7領域に分けて整理します。

特定製品を使う場合には、製品固有の要件も加わります。Copilot Studio導入の要件定義では、Copilot Credits、環境、データポリシーなどを整理しています。機密情報を扱う構成なら、オンプレ生成AIの要件定義ガイドも参考にしてください。

機能要件はMust、Should、Couldへ分ける

要望をすべて必須にすると、費用も期間も膨らみます。機能は最低でも3段階に分けます。

  • MustはPoCまたは本番に不可欠な要件です。たとえば、承認済み事例だけを検索し、参照元を表示する機能が該当します。

  • Shouldは重要ですが、代替や後続対応が可能な要件です。類似度や利用者評価を管理画面で確認する機能などです。

  • Couldは効果を確認してから追加する要件です。CRMへの自動登録や多言語対応が該当します。

「将来ほしい機能」と「今回作る機能」を分けるだけで、提案会社は見積もりやすくなります。RFPには、各機能がPoC、本番初期、将来拡張のどこに属するかも示します。

データ要件はファイル数ではなく管理方法まで書く

生成AIの品質は、モデルだけでは決まりません。どのデータを使い、誰が正式版を管理し、いつ更新するかが重要です。

データ台帳に必要な項目

  • データ名と内容

  • 所有部署と更新責任者

  • 保管場所と形式

  • 件数・容量・増加量

  • 機密区分と利用可能者

  • 正式版、施行日、失効日

  • 個人情報や顧客情報の有無

  • 外部サービスへの送信可否

  • 登録、更新、削除の方法

  • PoCへ提供できる時期と方法

RAGを作る場合も、文書を入れれば完成ではありません。検索、権限、出典表示、更新、評価まで要件に含めます。実装全体は社内AI（社内GPT・RAG）の作り方、精度問題の切り分けは公開後の「RAGの回答精度が上がらないときの見直し手順」で詳しく扱います。

まだデータを渡せない場合

RFPの段階で実データを複数社へ渡せないこともあります。その場合は、形式、件数、サンプル、機密区分、提供時期を示し、必要に応じて秘密保持契約を結びます。

データの内容が分からないまま固定見積もりを求めると、提案会社は大きな安全余裕を載せるか、後から追加費用を求める可能性があります。不明点は隠すのではなく、「未確定事項」として扱い、いつ誰が確定するかを決めます。

AI開発の対象、データ、PoC範囲を整理するための資料をご用意しています。

▶️ AIworkerのサービス資料をダウンロードする


AI特有の非機能要件を決める

通常のシステムと同じ可用性や性能に加え、生成AIには出力の揺らぎ、根拠、禁止回答、モデル変更などの要件があります。

RFPには、次の確認方法まで書きます。

  • 回答品質は、正確性、根拠性、必要項目の網羅を固定テストケースで採点する

  • 答えがない質問を試し、情報不足や対象外では推測せず保留できるか確認する

  • 権限の異なる利用者で境界テストを行い、元データの閲覧権限が回答へ反映されるか確認する

  • 通常時とピーク時の目標時間を決め、同時利用を想定した負荷試験を行う

  • 同じ条件で複数回実行し、結論が大きく変わらないか確認する

  • 入力、出力、参照元、実行、承認をログから追跡できるようにする

  • モデルやプロンプトの更新後に、同じ評価データで回帰テストを行う

  • PoCで1件あたりの利用量を測り、月間費用と利用上限へ換算する

NISTの生成AI向けAI RMFプロファイルは、生成AIのリスクを組織の目的、法的要件、許容できるリスク、保有資源に合わせて管理する考え方を示しています。すべてのリスクをゼロにするのではなく、対象業務ごとに許容範囲と対策を決めることが重要です。NIST AI 600-1は、AIの調達・利用を含むリスク整理の参考になります。

入力データの区分、外部送信、保存、学習利用、ログの扱いを整理する際は、生成AIの情報漏えい対策も参考にしてください。

PoCと本番を分けて依頼する

PoCと本番では目的が違います。

RFPでは、PoCだけの見積もりなのか、本番まで含むのかを明記します。本番費用が未確定なら、想定構成、費用の増減要因、再見積もり条件を求めます。

PoCは成功を演出する場ではありません。本番へ進む条件と、進まない条件を決める場です。 正常な質問だけでなく、曖昧な質問、古い文書、権限外の依頼、連携失敗なども試します。

RFPに記載する12項目

RFPは長ければよいわけではありません。候補企業が、同じ範囲と条件で解決策、体制、費用、リスクを提示できることが重要です。

1．背景と目的

なぜ取り組むのか、何が起きているのか、導入後にどの状態を目指すのかを書きます。「AI活用を推進する」ではなく、「営業担当が承認済み事例を探す時間を減らし、提案の根拠をそろえる」のように具体化します。

2．対象業務と現行フロー

利用場面、担当者、入力、参照情報、判断、成果物、現在の工数と問題を書きます。現行業務フローを別紙にすると、提案会社が作業の前後関係を理解しやすくなります。

3．対象範囲と対象外

PoC、本番初期、将来構想を分けます。社外送信、最終判断、基幹システム更新など、今回実施しない範囲も明記します。

4．利用者と利用環境

部署、役割、人数、同時利用、端末、ネットワーク、認証方式、利用場所を書きます。PoC人数だけでなく、本番時の想定も示します。

5．データ

情報源、形式、容量、更新、権限、機密区分、提供方法を書きます。実データを共有しない段階でも、データの特徴は提示します。

6．機能要件

検索、生成、連携、通知、承認、管理画面などを、Must、Should、Couldへ分けます。画面数ではなく、利用者が完了したい仕事を基準にします。

7．非機能・セキュリティ要件

回答品質、応答時間、同時利用、可用性、認証、権限、暗号化、ログ、バックアップ、データ保管場所、外部AIへの学習利用、再委託を含めます。

8．PoCと評価方法

テストデータ、評価者、指標、合格基準、重大な不合格条件、期間、本番移行の判定方法を書きます。

9．体制と役割分担

発注側と受注側の責任者、業務担当、データ担当、情シス、セキュリティ、意思決定者を決めます。発注側が用意するデータやレビュー時間も明記します。

10．成果物

動くシステムだけでなく、要件定義書、設計書、ソースコード、設定、プロンプト、評価データ、テスト結果、運用手順、障害対応手順などを列挙します。

11．スケジュールと提案条件

質問期限、回答方法、提案締切、選定、契約、PoC、判定、本番開始の予定を書きます。提案書の形式やページ数、デモの要否もそろえます。

12．契約・費用・知的財産

見積範囲、支払条件、追加費用が発生する条件、検収、保証、再委託、秘密保持、データの扱い、成果物の権利、契約終了時の返却・削除・移管を確認します。個別契約は法務や専門家へ確認してください。

そのまま使えるRFPの基本形

次の基本形を、自社の業務に合わせて埋めてください。未確定の項目は空欄にせず、「提案を求める事項」「PoCで確定する事項」と書き分けます。

AI開発 提案依頼書（RFP）

1．プロジェクト概要
・背景：
・解決したい課題：
・目的：
・期待する業務成果：

2．対象業務
・利用者：
・利用場面：
・現在の業務フロー：
・入力情報：
・期待する成果物：
・人が確認・承認する箇所：

3．対象範囲
・PoCで実施する範囲：
・本番初期で実施する範囲：
・対象外：
・将来の拡張候補：

4．データ
・参照するデータ：
・形式、件数、容量：
・機密区分：
・利用者ごとの閲覧権限：
・更新、削除の方法：
・提供時期と提供方法：

5．要件
・Must：
・Should：
・Could：
・応答時間、同時利用、可用性：
・認証、権限、ログ、暗号化：
・外部サービス、再委託、データ保管場所：

6．PoCと評価
・テストケース：
・評価指標：
・評価者：
・合格基準：
・重大な不合格条件：
・本番移行の判断方法：

7．役割分担
・発注側の担当と提供物：
・受注側へ求める体制：
・会議、報告、意思決定方法：

8．成果物
・システム、ソースコード、設定：
・設計書、評価データ、テスト結果：
・操作手順、運用手順、障害対応手順：

9．提案依頼事項
・提案する構成と選定理由：
・前提条件と対象外：
・PoC費用と本番費用：
・費用が増減する条件：
・スケジュール：
・体制と実績：
・想定リスクと対策：
・運用保守と内製移管：

10．提案手続き
・質問期限：
・回答方法：
・提案締切：
・選定方法：
・連絡先：

11．契約条件
・契約形態：
・検収：
・秘密保持、再委託：
・知的財産、データ、成果物の扱い：
・契約終了時の返却、削除、移管：

複数社の提案を同じ条件で比較する

提案を受け取った後に評価項目を決めると、印象や説明の上手さに引っ張られます。RFPを出す前に評価表を作り、重要度を決めます。

価格を比べるときは、同じ範囲へそろえます。A社はPoCだけ、B社は本番基盤と保守まで含む、といった提案を総額だけで並べても意味がありません。生成AI導入支援の費用相場では、研修、コンサル、伴走、開発の費用構造の違いを整理しています。

デジタル庁の標準ガイドライン解説書でも、要件定義の理解度を評価するときは、機能、性能、開発方式、ドキュメント、機能構成などの提案が、調達仕様書や要件定義書と整合しているかを見る考え方が示されています。民間企業でも、派手なデモではなく、自社が示した要件との整合性を見るという原則は有効です。

発注側にも必要な体制がある

開発会社へ任せれば、発注側の作業がなくなるわけではありません。業務の正解、正式なデータ、許容できるリスクは、外部の会社だけでは決められないからです。

プロジェクト責任者は、目的、予算、優先順位を決めます。業務責任者は、現行業務、正解、例外、評価基準を説明します。利用者代表には、実際の質問や使い勝手を確認してもらいます。

データ所有者は正式版、機密区分、更新、削除に責任を持ちます。情報システム部門は認証、連携、環境、障害、保守を確認し、セキュリティ・法務部門は委託、個人情報、契約上のリスクを確認します。開発会社は、合意した要件に沿って設計、実装、テスト、説明、引き継ぎを行います。

特に、業務責任者がレビューへ参加しないと、技術的には動いても業務上の正解を満たさないシステムになります。レビュー日程と回答期限はRFPの時点で確保します。

AI開発のRFPで起きやすい7つの失敗

1．目的が「AIを導入する」になっている

導入そのものを目的にすると、成功を測れません。業務時間、品質、処理件数、確認負担など、導入後に変えたい状態へ置き換えます。

2．完成形だけを書き、現行業務を書かない

「社内文書へ回答するAI」だけでは、質問者、情報源、回答後の行動が分かりません。現在の流れと問題を示すことで、より簡単な代替案が提案されることもあります。

3．PoCで全社利用を再現しようとする

対象を広げるほど、評価不能になります。まず失敗原因を特定できる範囲へ絞ります。

4．精度を1つの数字だけで求める

正答率だけでは、重大な誤りと軽微な表現差を区別できません。根拠性、権限違反、拒否すべき質問、確認負担も分けて評価します。

5．発注側の作業を見積もっていない

データ準備、業務説明、テストケース作成、レビュー、社内審査には時間がかかります。担当者の時間が取れないと、開発会社が待つか、推測で進めることになります。

6．初期開発費だけで選ぶ

モデル利用料、クラウド、監視、問い合わせ、改善、再評価、データ更新を含めると判断が変わります。生成AIのクラウド・オンプレ費用比較も、総保有コストを考える際の参考になります。

7．契約終了後を決めていない

ソースコードがあっても、設定、評価データ、プロンプト、運用手順がなければ他社へ引き継げません。終了時に受け取るもの、削除するデータ、移行支援を決めます。

発注前チェックリスト

  • 解決したい業務課題を1文で説明できる

  • 対象利用者、利用場面、入力、成果物が決まっている

  • 現在の工数、件数、品質の基準値がある

  • AIと人の役割、承認、停止条件が決まっている

  • PoC、本番初期、対象外を分けている

  • 利用するデータと所有部署が分かっている

  • 機密区分、提供方法、更新、削除を説明できる

  • Must、Should、Couldを分けている

  • 非機能・セキュリティ・運用要件がある

  • テストケース、評価者、合格基準がある

  • 発注側の責任者とレビュー担当を確保している

  • 成果物、追加費用、契約終了時の移管条件を確認する

  • 提案を評価する基準をRFP配布前に決めている

すべてが決まっていなくてもRFPは作れます。ただし、決まっていること、提案を求めること、PoCで確定することを混ぜないでください。

FAQ

Q. AI開発のRFPは自社だけで作るべきですか？

自社だけで技術要件まで確定する必要はありません。業務の目的、現在の流れ、データ、許容できない失敗は自社で整理し、実現方法が分からない部分はRFIや専門家への相談で補います。特定の候補会社だけにRFP作成を任せる場合は、その会社に有利な前提へ寄りすぎないよう注意が必要です。

Q. 要件が固まっていなくても見積もりを依頼できますか？

概算は依頼できます。ただし、前提条件、対象範囲、未確定事項、費用が変わる条件を明記してもらいます。異なる前提の概算を総額だけで比較しないでください。

Q. RFPは何ページ必要ですか？

ページ数より、候補企業が同じ条件で提案できることが重要です。本文を簡潔にし、業務フロー、データ一覧、機能一覧、評価表を別紙にする方法もあります。

Q. PoCの期間はどのくらいがよいですか？

業務とデータの複雑さで変わるため、一律には決められません。期間より、開始前にデータが用意できるか、評価者を確保できるか、終了時に採用・再検証・停止を判断できるかを確認してください。

Q. RFPでは予算を伝えた方がよいですか？

予算制約があるなら、上限や対象範囲を伝える方が現実的な提案を受けやすくなります。ただし、AIworkerでは過去案件の価格をそのまま当てはめず、業務、規模、要件、工数、期待効果から個別に見積もります。公開情報だけで一律の価格を断定することはできません。

Q. 生成AIのモデル名を指定した方がよいですか？

法令、契約、社内基盤などの理由がなければ、最初から1つのモデルへ固定しない方がよい場合があります。必要な品質、速度、データ保護、費用、切り替え条件を示し、候補と選定理由の提案を求めます。

Q. 開発会社を選ぶ決め手は何ですか？

技術力だけでなく、業務を理解しようとするか、PoCの停止条件を説明できるか、運用と内製移管まで提案できるかを確認します。自社に合う会社の選び方は、既存のAIエージェント開発会社の選び方でも解説しています。

発注前に、比較できる要件を作る

良いRFPは、発注側が考えた機能を開発会社へ命令する文書ではありません。解決したい課題、制約、判断基準を共有し、より良い実現方法を提案してもらうための共通土台です。

重要なのは、すべてを確定することではなく、確定事項、提案事項、PoCで検証する事項を区別することです。この区別ができれば、各社の提案を同じ条件で比較し、契約後の認識違いを減らせます。

AIネイティブX研修｜発注側が要件を判断できる力をつける

AI開発を進める担当者向けに、業務分解、AIと人の役割分担、データ・リスク・評価項目の整理を実際の題材で学びます。ツール操作だけでなく、提案を読んで判断するための共通言語とチェック項目が社内に残ります。開発会社へすべて任せず、利用部門と情シスが主体的に進めたい企業に向いています。

AIネイティブX伴走｜業務棚卸しからRFP、PoCまで一緒に進める

現場へのヒアリング、対象業務の絞り込み、業務フロー、RFP、評価表、社内説明を一緒に作ります。助言だけで終わらず、提案取得後の比較、PoCの週次改善、本番移行の判断まで伴走します。AI推進担当が一人で要件整理や社内調整を抱えている企業に向いています。

業務AIプロ｜要件定義から開発・運用保守までつなぐ

既存システムや社内データを生かし、必要な機能だけを個別に設計・開発します。認証、権限、ログ、例外処理、評価、保守まで含め、試作で終わらない形にします。汎用AIで対象業務を検証済みで、複数人利用やシステム連携へ進みたい企業に向いています。

対象業務、データ、PoCの範囲、発注方法を整理したい場合は、無料カウンセリングで現在の検討状況を確認します。

▶️ サービス資料のダウンロード（資料請求）

▶️ 無料カウンセリング・AI活用診断のご予約

この記事が参考になりましたら、今後の記事づくりの励みになるので、スキをお願いします。

参考資料

#生成AI #AI開発 #AI導入 #AIエージェント #要件定義 #RFP #提案依頼書 #システム開発 #DX推進 #AI推進 #PoC #業務改善 #業務効率化 #社内AI #RAG #生成AI導入 #AIシステム #システム導入 #開発会社 #ベンダー選定 #外注 #内製化 #情報システム #情シス #セキュリティ #権限設計 #データ活用 #非機能要件 #プロジェクト管理 #IT調達 #見積もり #費用対効果 #ROI #稟議 #ガバナンス #運用保守 #DX #法人向けAI #AIコンサル #AIworker

いいなと思ったら応援しよう！