この記事で分かること
- AI受託開発会社を比較するRFPの考え方
- RFPに入れるべき10項目と質問例
- PoCから本番へ進むための確認点
- 費用と運用を含む評価表の作り方
AI開発の相談先を確認する、既存システムの診断を相談する、要件定義から保守までの流れを読むと、発注前の材料を整理できます。
なぜAI受託開発の選定は難しいのか
AIには文書検索、問い合わせ支援、画像認識、予測、要約など異なる仕組みが含まれます。同じAI導入でも、会社によって対象範囲や運用の考え方が異なります。精度だけでなく、権限、ログ、連携、確認手順を含めて比較しなければなりません。
良い提案は、前提条件、未確定事項、検証が必要な事項を分けて示します。課題を聞かずに特定製品だけを勧める提案は、契約後の認識違いにつながる可能性があります。
1. 解決したい業務課題と利用者
AIの機能ではなく、誰のどの作業をどう変えるかを書きます。対象利用者、現在の手順、困っている点、利用頻度を具体化します。候補会社には、AIに任せる部分と人が判断する部分、例外時の手順を説明してもらいます。業務フローの理解を確認できる提案ほど、後の手戻りを減らしやすくなります。
2. 成果指標と受入基準
「便利にする」や「精度を高くする」では判定できません。回答の正確性、検索時間、確認者の作業時間、処理件数、誤回答時の停止率など、測定可能な指標にします。数値を決められない場合も、測定方法、初期値、合否を判断する会議と責任者をRFPに入れます。
3. 対象データと品質・権利
文書、顧客情報、画像、ログなどを一覧化し、保存場所、更新頻度、形式、欠損、重複、機密区分を整理します。データ整備を誰が担当するか、第三者資料や個人情報をどう扱うか、保管期間、削除方法、学習利用の有無を契約前に確認します。
4. AI方式とモデル選定
モデル名は評価項目の一つにすぎません。品質、速度、費用、データの所在、将来の変更可能性を踏まえ、なぜその方式を選ぶのかを説明してもらいます。検索、ルール、従来型プログラム、人による確認を組み合わせる案や、モデル変更時の検知方法も比較します。
5. 既存システムとの連携
ログイン、権限、マスタ、通知、承認、帳票、データベースなど、連携対象と方式を明記します。利用可能なAPI、更新タイミング、テスト環境、担当部署も必要です。連携できない場合の代替案、データ不整合時の処理、切り戻し方法まで提案を求めます。
6. セキュリティと権限管理
認証方式、ロール、分離、暗号化、管理者権限、操作ログ、監査方法を質問します。入力情報が別の利用者に表示されないこと、ログに機密情報を残しすぎないこと、退職者の権限を無効化できることが重要です。認証取得状況だけでなく、自社要件との対応表を確認します。
7. PoCの範囲と本番移行条件
PoCをデモ作成だけで終わらせないため、対象業務、データ量、利用者、期間、成果物、指標、終了条件を定めます。本番移行時に必要な環境、連携、権限、監視、教育、追加費用を別項目で提示してもらい、PoCと本番の境界を見積書に反映します。
8. 開発体制とコミュニケーション
責任者、業務理解担当、AI・データ担当、連携担当、品質確認担当を示してもらいます。再委託、担当変更時の引き継ぎ、定例会、課題管理、意思決定者も確認します。各工程の成果物とレビュー参加者が明確か、質問への回答が具体的かを見ます。
9. 費用・契約・知的財産
要件定義、データ整備、PoC、連携、テスト、教育、保守、クラウドやモデル利用料を分けて提示してもらいます。従量課金、追加開発単価、契約期間、解約時の扱い、成果物の著作権、設定情報やドキュメントの引き渡し範囲も比較します。
10. 運用・保守・改善
データ更新、外部サービス変更、誤回答の報告、設定変更、障害対応、利用状況の確認は導入後に発生します。問い合わせ窓口、対応時間、優先度、復旧目標、定期レポート、改善の承認者をRFPに書きます。ログと評価データを蓄積し、継続改善できる設計かを確認します。
候補会社を比較する評価表の作り方
価格、提案内容、実績、体制、セキュリティ、運用の列を作り、各項目に重みを付けます。ただし、必須条件の欠落を価格の安さで相殺しないことが大切です。業務責任者、情報システム、現場利用者の視点を分けて評価し、未確定事項を質問リストへ戻します。
実績は件数だけでなく、自社と似た業務、データ、利用者規模、導入後の運用まで確認します。仮定が外れたときの影響、依頼側の作業、追加費用も記録します。
10項目を商談で確かめる質問集
1. 解決したい業務課題と利用者「対象業務の現状フローと、AI導入後に変わる担当者の作業を1枚で示せますか。」を確認します。現状フローの図と導入後の役割分担を並べて比較します。
2. 成果指標と受入基準「成果指標の計算式と、合否を判定するテストデータを事前に合意できますか。」を確認します。測定担当と判定会議を先に決め、同じデータで候補案を評価します。
3. 対象データと品質・権利「データの欠損・重複・権利確認をどの工程で行い、誰が承認しますか。」を確認します。サンプルの出所と利用許諾を確認し、除外対象も一覧に残します。
4. AI方式とモデル選定「採用方式を選んだ理由と、モデル変更時の移行・再評価手順は何ですか。」を確認します。性能だけでなく費用と切替時の影響を含めて方式を比較します。
5. 既存システムとの連携「既存システムのAPIや権限情報が不足した場合、どの代替策を提示しますか。」を確認します。テスト環境で連携の読み書きを実演し、失敗時の戻し方を確認します。
6. セキュリティと権限管理「利用者の権限をAIの検索結果とログへどのように反映し、監査できますか。」を確認します。権限表とログのサンプルを見て、監査担当が追跡できるか判断します。
7. PoCの範囲と本番移行条件「PoCで検証する範囲、本番化の判断条件、本番化しない場合の成果物を明記できますか。」確認します。終了条件と本番化費用を別々に採点し、過大なPoCを避けます。
8. 開発体制とコミュニケーション「契約後の責任者、実装担当、業務担当、再委託先を固定し、変更時に通知できますか。」確認します。体制表の担当者へ直接質問し、契約後の連絡経路を確定します。
9. 費用・契約・知的財産「初期費用と月額・従量費、追加開発、終了時の返却費用を分けて提示できますか。」を確認します。見積書の内訳を同じ単位にそろえ、将来の継続費用も記録します。
10. 運用・保守・改善「誤回答や外部サービス停止を検知した後の連絡、復旧、改善の流れを定義できますか。」を確認します。障害・誤回答・更新のケースごとに、連絡先と復旧目標を照合します。
発注側で先に準備する資料
RFPと一緒に、業務フロー、用語集、サンプルデータ、現行画面、利用者と権限の一覧、既存契約、セキュリティ方針を渡せると、提案の精度が上がります。実データをそのまま共有できない場合は、匿名化や項目の置き換えを行い、置き換えによって検証できなくなる点を明記します。
資料を作る目的は、最初から完璧な仕様を決めることではありません。候補会社が不明点を見つけ、質問し、仮説を検証できる状態にすることです。未決定の事項には担当者と期限を付け、提案の比較時に決定済み・仮定・保留を区別します。
選定後の進め方もRFPに書く
会社を選んだ後の最初の会議で、RFPをそのまま開発計画へ移せるとは限りません。要件の優先順位、データのサンプル、利用者の代表、テスト環境、承認経路を確認し、追加調査が必要な項目を洗い出します。調査結果で当初の方式や費用が変わる場合は、変更理由と選択肢を示してもらいます。
検証では、成功した例だけでなく、入力が不足している例、古い情報を含む例、権限外の情報を求める例、外部サービスが利用できない例も試します。結果を記録し、利用者がどこで確認し、誤りを報告し、再発防止へつなげるかを決めます。こうした確認を先に合意しておくと、AIの回答品質をめぐる感覚的な議論を減らせます。
よくある失敗と回避策
失敗例の一つは、デモが成功したため本番でも同じ結果が出ると思い込むことです。デモのデータ、評価条件、手作業の有無を記録し、本番データで再現できるかを検証します。二つ目は、見積もりの安さだけで会社を選ぶことです。含まれる工程と含まれない工程を分け、導入後の費用と社内工数を加えて比較します。
三つ目は、現場利用者が最後まで参加しないことです。要件定義、試作評価、受入テスト、教育に利用者を招き、使わない理由を記録します。四つ目は、責任分界が曖昧なことです。データの誤り、外部サービス停止、モデル更新、誤回答、権限設定のそれぞれについて、検知する人、判断する人、復旧する人を決めます。
五つ目は、導入後の改善を契約に含めないことです。ログの確認、評価データの追加、プロンプトや検索設定の変更、モデル変更のテストを、保守契約の範囲と追加作業に分けてください。改善の優先順位を誰が決めるかも重要です。
選定会議では、点数の合計だけでなく、重大な懸念と未確認事項を別に一覧化します。最安の提案を採用する場合も、追加の検証、社内工数、将来の移行費用を含めて説明できる状態にします。最終判断者がRFP、評価表、議事録を読めば、なぜその会社を選んだのかを後から確認できることが理想です。
契約前に確認すること
検証環境で扱うデータ、成果物の形式、受入テスト、変更管理、未達時の扱い、終了時のデータ返却を確認します。口頭説明は議事録に残し、契約書・仕様書・見積書のどこに反映されたかを照合します。準備が不足している場合は、いきなり開発を決めず、業務整理や既存システムの診断から始める方法もあります。
特に、利用停止や担当会社の変更が起きたときに、自社がデータと設定を取り戻せるかを確認します。引き継ぎ資料の形式と期限を契約へ記載します。
社内の承認者と現場の利用者が同じ基準で確認できるよう、質問への回答は一覧で管理します。
まとめ：RFPは会社を選ぶための比較基準
選定で重要なのは技術の新しさだけではありません。課題、成果指標、データ、方式、連携、セキュリティ、PoC、本番移行、体制、費用、運用をRFPへ落とし込み、同じ条件で比較することです。できることだけでなく、できないこと、前提、依頼側の作業、将来費用を確認し、現場が安全に使い続けられる提案を選びます。
比較結果は、採用理由だけでなく見送った理由も残します。将来の再検討時に前提条件を引き継げるため、選定の透明性と社内説明のしやすさが高まります。
RFPの配布先と回答期限もそろえ、候補会社から受け取った質問への回答を全社へ同じ条件で共有します。個別の打ち合わせで追加された条件は、評価表へ反映してから再採点します。提案比較の途中で要件を変える場合は、変更日、変更理由、影響する候補項目を記録します。これにより、価格だけでなく、実現性、継続性、社内で運用できるかという観点を落ち着いて比較できます。
候補会社への説明資料では、必須要件と希望要件を分けます。必須要件は満たさない提案を採用候補から外し、希望要件は代替案や段階導入の提案を評価します。こうすると、すべてを一度に実現しようとして予算や納期が膨らむことを避けられます。また、現場が試用する期間と、経営層が投資判断する時期を分けて設計します。試用中に得た意見は、単なる感想として捨てず、操作時間、誤操作、確認のしやすさ、問い合わせの発生箇所に分解して記録します。
比較表には確認日も記載します。モデル、価格、契約条件、担当者は変わる可能性があるため、古い情報を現在の事実として扱わないためです。
