この記事で分かること
- AI受託開発のRFPに書くべき業務、データ、成果の条件
- 提案範囲、体制、方式、費用、期間を比較する視点
- PoCと本番開発、テスト、保守の責任分担
- 選定時に確認したい契約と引き継ぎの条件
RFPは会社を評価する前に条件をそろえる書類
RFPは、開発会社に同じ条件で提案してもらうための依頼書です。完成した仕様書である必要はありませんが、困っている業務、対象利用者、データ、期待する成果、制約を記載します。条件がそろっていないと、各社が違う範囲を見積もり、価格だけで比較できなくなります。
AIの方式を指定しすぎないことも大切です。目的と評価条件を示し、検索、分類、生成、既存システム改修などの実現方法は提案会社に説明してもらいます。AIを使わない案や、段階導入の案も比較対象へ含めます。
| 項目 | RFPに書く内容 | 比較する点 |
|---|---|---|
| 背景と課題 | 現行業務、件数、時間、問題 | 業務理解の深さ |
| 目的と成果 | 削減時間、品質、利用率 | 評価方法の具体性 |
| 利用者 | 部署、役割、端末、人数 | 画面と権限の提案 |
| データ | 場所、形式、量、更新、制約 | 整備と取り込みの範囲 |
| 希望条件 | 時期、予算、連携、保守 | 実現性と前提 |
RFPに入れるべき10項目
1. 背景と解決したい業務
なぜ開発を検討するのか、現在どの作業に時間やミスが発生しているのかを書きます。担当者が行う手順、例外、完了条件を説明し、単なる「AI導入」という表現を避けます。
2. 目的と評価指標
処理時間、回答までの時間、修正率、利用率、問い合わせ件数など、導入前後で測れる指標を示します。数値が未確定なら現状を調査すること自体を提案範囲に含めます。
3. 利用者と権限
誰が利用し、誰が承認し、誰が管理するかを記載します。部署や役割で見られる資料が異なる場合は、権限外の情報を表示しないことを要件にします。
4. データとサンプル
Excel、Access、PDF、CSV、データベースなどの場所と形式、件数、更新頻度を示します。匿名化した代表例と処理しにくい例を用意し、品質や整備費用を提案会社が確認できるようにします。
5. 必要な機能と対象外
検索、要約、分類、回答案、通知、管理画面、ログ、連携などを分けます。初期に作らない機能も書き、将来の拡張条件を共有します。
6. AIの評価とテスト
正常な入力だけでなく、誤字、空欄、古い資料、長文、権限外の質問、回答不能な質問を含むテスト条件を示します。正解率だけでなく、根拠、待ち時間、人の修正負担も評価します。
7. 既存システムとの連携
Excel、Access、CRM、販売管理などとの接続方式、更新タイミング、認証、失敗時の再処理を確認します。連携先を管理する社内外の担当者がいれば、調整の責任者も決めます。
8. 開発体制と成果物
PM、業務担当、AI担当、画面や連携の担当、テスト担当を示してもらいます。要件定義書、設計書、ソースコード、評価結果、手順書など、納品物を確認します。
9. 費用と期間
要件定義、PoC、本開発、データ整備、移行、教育、クラウドやAPI、保守を分けて見積もってもらいます。発注側の準備期間、検収、追加費用、仕様変更の条件も記載します。
10. 運用・保守と引き継ぎ
障害、データ更新、精度改善、利用者問い合わせ、サービス変更へ誰が対応するかを確認します。契約終了時のデータ、アカウント、設定、資料の引き渡しも提案へ含めます。
提案書を比較する採点表を作る
RFPへの回答は、金額だけでなく、条件に対する回答の具体性で比較します。評価項目に重みを付ける場合も、合計点だけで決めず、必須条件を満たしているかを先に確認します。例えば、権限管理が必須なのに、その説明がない提案は価格が低くても再質問が必要です。
| 比較軸 | 見る内容 | 質問例 |
|---|---|---|
| 業務理解 | 現行フローと例外への理解 | どの工程をどう変えるか |
| 技術提案 | 方式、連携、権限、評価 | その方式を選ぶ理由は何か |
| 体制 | 担当者、役割、連絡方法 | 誰が日々の判断を支援するか |
| 費用 | 含む作業、対象外、月額 | 利用量が増えた場合どうなるか |
| 運用 | 保守、改善、移管 | 契約終了時に何が残るか |
RFPと提案のやり取りで注意すること
提案会社から質問を受けたら、回答を全社へ同じ条件で共有します。特定の会社だけが知る前提があると、比較の公平性が崩れます。回答によって条件が変わった場合は、RFPを更新して版を管理します。
デモを見るときは、用意されたサンプルだけでなく、自社に近いデータを使います。見栄えのよい画面より、誤った入力、回答不能、権限、連携失敗の動きを確認します。デモで確認できない項目は、実証方法と時期を提案書へ書いてもらいます。
実績を確認する場合は、件数だけでなく、業務、利用者、データ、導入後の運用範囲を質問します。公開できない情報を無理に求めず、提案会社がどの部分を担当したか、現在も保守しているかを確認します。
選定プロセスを四段階に分ける
会社選定は、書類確認、質問、提案・デモ、最終確認の四段階に分けると進めやすくなります。書類確認では、RFPの条件を満たすか、対象外が明確かを見ます。質問では、データ、連携、権限、評価の不明点を聞き、回答の具体性を比較します。
提案やデモでは、自社に近い業務を一件通して確認します。入力、AI処理、結果の確認、修正、承認、保存、次のシステムへの連携まで見せてもらいます。画面の見栄えだけを切り出すと、実際に必要な管理やエラー処理を評価できません。
最終確認では、見積もり、工程、体制、契約、保守、引き継ぎを担当者と確認します。担当者が変わる場合や、外部パートナーが実装する場合は、その関係と責任を明記します。提案段階で不明なものを、契約後に自然に解決すると考えないことが大切です。
| 段階 | 確認するもの | 判断する質問 |
|---|---|---|
| 書類 | 条件、経験、対象範囲 | RFPの必須条件を満たすか |
| 質問 | 不明点への回答 | 前提とリスクを説明できるか |
| 提案 | 方式、画面、テスト | 自社の業務を完了できるか |
| 契約前 | 費用、体制、保守、移管 | 導入後も運用できるか |
スコアだけで決めず必須条件を確認する
採点表は比較の補助に使います。業務理解、技術提案、データ、セキュリティ、体制、費用、期間、保守へ点を付ける場合も、総合点だけで決定しません。権限、個人情報、必要な連携などの必須条件を満たさない提案は、点数が高くても再確認が必要です。
点数の根拠を一言で記録します。「提案あり」ではなく、どの資料の何ページで、どの条件に答えているかを残します。回答が曖昧な項目は、減点するだけでなく、追加質問と回答期限を設定します。比較メンバーが複数いる場合は、評価後に差が大きい理由を話し合います。
価格が低い理由も確認します。AIの利用料が含まれていない、データ整備が発注側、テストが最小限、保守が別契約など、作業範囲が違う可能性があります。社内の作業時間と将来の追加費用を加え、導入から一年程度の総負担で比較します。
RFPに書きにくい情報も整理して共有する
既存業務の不満や社内事情は書きにくいものですが、提案の前提になります。担当者が退職して属人化している、部署ごとに台帳が違う、資料の最新版が分からない、承認者が忙しいなど、実際の制約を明示します。隠したまま提案を受けると、実装後に問題として現れます。
反対に、公開できない情報は匿名化して構いません。どの部分を変えたか、実データと何が違うかを示し、権限や文書構造が評価できるサンプルにします。秘密保持契約が必要なら、締結の時期と対象データをRFPのスケジュールへ入れます。
将来構想も一行でよいので書きます。初期は一部署でも、将来は複数部署で使う、顧客向けに展開する、販売管理と連携するなどの予定があれば、初期設計の前提になります。今すぐ作る機能と、拡張のために考慮する条件を分けて記載します。
契約前に残す確認事項
最終候補が決まったら、RFPと提案書の差分を確認します。提案会社が追加した前提、対象外にした作業、発注側へ求める準備、納品されない資料を一覧化します。口頭で説明された内容も、契約書や仕様書へ反映します。
AIの品質は、データと利用方法で変わります。評価に使うデータ、合格条件、再評価の方法、問題が起きた場合の改善担当を記載します。無期限の精度保証を求めるのではなく、どの条件で確認し、どの対応を行うかを決めることが現実的です。
運用では、資料の更新、モデルやAPIの変更、利用量の増加、問い合わせ、障害、権限変更が発生します。保守契約へ含める作業と別料金になる作業を分け、受付方法と対応時間を確認します。設定やデータのバックアップ場所も共有します。
この確認を終えてから発注すると、候補会社との認識差を減らせます。契約後も変更は起こり得るため、変更依頼、影響確認、承認、記録の流れをあらかじめ決めておくと、納期と費用を管理しやすくなります。
選定メンバーには、現場で日常的にシステムを使う人を含めます。業務担当者がデモを操作すると、入力の手間、結果の見やすさ、修正や差し戻しのしやすさが分かります。担当者の意見は感想だけでなく、どの作業に何分かかるかという形で記録します。
RFPの内容は、発注後の要件定義にも引き継ぎます。提案時の仮定と、契約後に検証する項目を分けて残し、最初から確定した要件と誤解しないようにします。提案会社と発注側が同じ資料を見続けることが、開発の手戻りを抑える基本です。
見積もりの有効期限や利用サービスの料金条件にも注意します。契約や方式が変われば、費用や納期へ影響する場合があります。変動する項目を明記し、確定する時期と判断者を決めておくと、社内の予算管理にも使えます。提案の前提条件も保存します。後の比較に役立ちます。担当部署も確認します。記録の保管場所も決めます。更新日も記録します。社内で適切に管理します。関係者にも共有します。必要に応じて更新します。確実に確認します。
AI受託開発のRFP作成に関するFAQ
RFPは仕様書がなくても作れますか？
作れます。現行業務、困っている作業、利用者、データ、期待成果、制約を示し、未確定な部分は提案会社へ確認してもらいます。
RFPでAIの方式を指定すべきですか？
目的と評価条件を先に示し、方式は提案してもらう方法が一般的です。既存の制約や社内で決まった条件がある場合は、指定理由も記載します。
見積もりの安い会社を選べばよいですか？
対象範囲が同じかを確認します。データ整備、テスト、連携、教育、保守が対象外なら、社内工数や別費用を加えて比較してください。
PoCをRFPに含めるべきですか？
精度やデータの状態が不確かな場合は有効です。対象、期間、成果物、合格条件、本開発へ進む判断をRFPへ書きます。
保守の条件も最初から聞くべきですか？
聞くべきです。障害対応、精度改善、資料更新、利用者支援、外部サービスの変更、引き継ぎを分けて確認します。
AI受託開発会社の選定を相談する
マクティズムのAI開発サービスでは、要件が固まっていない段階から業務、データ、利用者、成果を整理し、AI開発の進め方を相談できます。社内文書検索、問い合わせ対応、文書作成、Excelや既存システム連携など、目的に合う範囲を検討します。
RFPへ入れる情報が不足していても、現行の業務フローや資料のサンプルがあれば、候補となる方式、検証範囲、見積もりの前提を整理できます。
まとめ｜RFPで同じ条件と合否をそろえる
AI受託開発会社を選ぶときは、背景、成果、利用者、データ、機能、評価、連携、体制、費用、保守の10項目をRFPへ入れます。提案の金額だけでなく、作業範囲、前提、成果物、責任、運用を同じ条件で比較してください。
RFPは、会社を落とすための書類ではなく、業務の目的と開発条件を共有する資料です。未確定な部分を明示し、質問と回答を記録しながら、PoCや本開発へ進む判断基準を作りましょう。
