AIベンダー選定の進め方とは？評価基準・RFP・PoC・契約の要点を実務解説

AIベンダー選定で最初に決めるべきことは？

AIベンダー選定は候補探しから始めず、対象業務・成功水準・投資枠・決裁ラインの四点を先に確定させます。

AX（AI Transformation）の現場で選定が長引く案件には共通点があります。候補企業の洗い出しから始めてしまい、「何を任せたいのか」が曖昧なまま提案を受けている状態です。この順番だと提案書ごとに前提が違うため比較ができず、最後は知名度や価格の印象で決まってしまいます。最初に固めるべきは市場調査ではなく、自社側の意思決定の枠組みです。

具体的には、次の四つをA4一枚に書き切れるかを確認してください。書けない状態でRFP（提案依頼書）を出すと、要件がベンダーの得意領域に引き寄せられます。

本記事では、この枠組みを起点に「評価基準の設計」「RFP・提案評価・PoC」「契約とリスク管理」「ロックイン回避の体制」の順で、AIベンダー選定の全工程を整理します。

自社の課題定義と要件はどこまで固める？

業務の入出力と判断基準までは自社で書き下し、技術手段の選択はベンダーが提案する余地として残します。

線引きははっきりしています。「どの業務のどの工程を、どの品質で、誰の承認を経て処理するか」は自社が決めることです。一方、「生成AIを使うか」「RAG（検索拡張生成）で社内文書を参照させるか」「AIエージェントとして自動実行させるか」は、提案として比較する対象にしたほうが良い結果になりやすいと感じています。手段を先に指定すると、より安価で確実な選択肢が提案から落ちてしまいます。

内製・SaaS・受託開発のどれを選ぶ？

汎用業務はSaaS、自社固有の業務ロジックは受託開発、継続的な改善が競争力になる領域は内製が基本線です。

この判断を飛ばして「AI開発ベンダーを探す」から入ると、Microsoft 365 CopilotやGoogle Workspaceの生成AI機能、あるいは契約済みSaaSの標準機能で足りる業務まで開発案件になってしまいます。文書要約・議事録・下書き作成のような汎用用途は、まず利用中のツールの標準機能を確認するのが妥当な順番です。

実務では、業務設計は自社で握り、実装を外部に出す分担が扱いやすいという印象です。設計まで外に出すと、後から改善したいときに毎回見積もりが必要になります。

選定体制と役割分担はどう組む？

選定体制は業務部門・情報システム・法務調達の三者を最初から常設し、決裁者を一人に定めておきます。

三者のどれかが後から合流すると、選定の終盤でセキュリティ審査や契約条項の指摘が出て差し戻しになります。特に生成AIやLLM（大規模言語モデル）を扱う案件では入力データの取扱いが必ず論点になるため、法務・情報セキュリティは最初から参加させるのが原則です。技術検証は数週間で終わっても、社内審査に数か月かかることは珍しくありません。

AIベンダーの評価基準はどう設計する？

評価基準は必須要件と加点要件を分け、業務理解・技術・セキュリティ・運用・価格・継続性に配点して設計します。

最大の要点は、デモの完成度で決めないことです。生成AIのデモは短時間で見栄えのするものが作れます。しかし本番運用で問われるのは、想定外の入力への挙動、精度が落ちたときの原因特定、モデル更新時の再検証体制です。この差を評価に反映させるには、提案を受ける前に配点表を作っておく必要があります。

技術評価では何を見る？

技術評価ではモデル選択の自由度、精度評価の手法、既存システムとの連携実装力の三点を確認します。

回答の質は質問の仕方で変わります。「精度は何%出ますか」と聞けば数字は返ってきますが、比較の材料にはなりません。代わりに、次のように聞くのが有効です。

1. 評価データはどう作るか：自社の想定質問セットをどの手順で作り、誰が正解を定義するか
2. 精度が出なかったときの打ち手：プロンプト改善、検索設定の調整、データ整備のどこから着手するか
3. モデルの選択肢：OpenAI・Anthropic・Googleなど複数のLLMを切り替えられる構成か、単一モデル固定か
4. モデル更新への対応：ベンダー側でモデルが更新された際の再検証の運用と費用負担
5. 失敗時の挙動：回答できない場合に「わからない」と返す設計になっているか
6. 連携の実績：自社が使う基幹システムやSaaSとの接続を、どの方式で何件手掛けたか

3番目は数年後の選択肢に直結します。外部ツール接続の標準仕様としては、Anthropicが公開したMCP（Model Context Protocol）のような取り組みも広がっています。標準的な接続方式に沿った設計かどうかは確認しておく価値があります。

セキュリティとデータ取扱いはどう確認する？

入力データを学習に使うか、保存リージョン、ログ保持期間、再委託先の四点を必ず文書で確認します。

口頭の説明ではなく、契約書・仕様書・第三者認証に記載があるかを見てください。同じベンダーでも提供プランによって学習利用の条件が異なることがあるため、「自社が契約するプランで」確認することが重要です。

配点とスコアリングはどう作る？

必須要件で失格を判定し、加点要件で差をつける二段構造にして、評価者の合議で配点を確定します。

以下は配点の構造を示す例です。数値は自社の重み付けに合わせて調整する前提で、業界標準値ではありません。

必須要件（満たさなければ即失格）と加点要件を混ぜないのがコツです。セキュリティ要件を加点項目に置くと、合計点で「安いが要件を満たさない」提案が勝ってしまいます。

RFPと提案評価・PoCの進め方は？

RFPでは業務要件と評価軸を先に開示し、PoCは合否基準と撤退条件を着手前に数値で固めてから始めます。

RFPの目的は「安く買うこと」ではなく、「同じ土俵で比較できる状態を作ること」です。評価軸を開示すると提案が横並びになると心配されがちですが、実務では逆です。開示しないと各社が自社の強みに寄せた提案を出してきて、比較できなくなります。

RFPに何を書くべきか？

RFPには対象業務・データ条件・評価指標・運用体制・契約前提の五項目に加え、提出様式と日程を明記します。

質問回答の期間は必ず設け、質問と回答を全候補に同じ内容で共有してください。ここを個別対応にすると、後で公平性を説明できなくなります。

提案評価はどう比較する？

提案は同じ様式の評価シートに落とし込み、価格は初期費用ではなく三年総額（TCO）で並べて判断します。

初期費用だけで比べると、運用費用が高い提案が有利に見えてしまいます。生成AIを使う構成では、LLMの従量課金、インフラ費用、精度を維持する工数が毎月かかり続けます。初期費用が安くても、総額で有利とは限りません。単価が改定される前提で、利用量が想定の0.5倍・1倍・2倍になった場合の年間費用を各社に出してもらうと、費用構造の違いが見えます。

提案書の読み合わせに加えて、次を行うと評価の精度が上がります。

1. 同一課題での実演：自社の実データに近いサンプルで、同じお題を各社に処理させる
2. 担当者面談：提案書を書いた人ではなく、実際に稼働する担当者と話す
3. 既存顧客への確認：可能であれば、稼働後の改善対応について既存の導入先に確認する
4. 失敗事例の質問：うまくいかなかった案件とその原因・対応を説明できるか

4番目は差が出やすい設問です。現場での感触としては、失敗を具体的に語れるベンダーほど、精度が出ない局面での打ち手を持っています。

PoCの合否基準はどう決める？

PoCは対象範囲・期間・評価データ・合格水準・撤退条件を、着手前に文書で合意してから始めます。

PoCが「やってみて良さそうだった」で終わる最大の原因は、合格水準を後から決めていることです。評価用の想定質問セットは着手前に自社で用意し、正解の定義まで自社で持っておけば、判断が主観に流れません。この評価データは自社の資産として残り、次回のベンダー比較にも使い回せます。

期間は短く区切ったほうがうまく回ります。長期のPoCは「延長すれば良くなる」という期待から判断が先送りされがちです。撤退条件も同じ文書に書いておくことをお勧めします。

契約とリスク管理で押さえる論点は？

契約では知的財産の帰属、データの二次利用、精度の非保証、責任分界点の四点を明文化しておきます。

AI案件の契約は、従来のシステム開発契約のひな形だけでは足りません。生成AIの出力は同じ入力でも変わりうるため、「仕様どおり動くこと」を成果物の基準にしにくいという構造的な難しさがあります。契約書の文言を詰めるより先に、業務のどこで人が確認するかを業務フロー上で決めるほうが実効性があります。なお、契約条項の最終判断は、自社の法務部門と弁護士の確認を前提としてください。

知的財産と成果物の権利はどう扱う？

プロンプト・評価データ・学習済み資産の帰属をそれぞれ定め、利用範囲を用途ごとに契約へ明記します。

「成果物の権利は発注者に帰属」と一括で書いても、実際には汎用的なノウハウとの切り分けが必要になります。論点を分けて個別に合意しておくほうが、後の紛争を避けやすくなります。

精度と責任分界点はどう定める？

生成結果の精度は保証の対象外とし、人が確認する地点と責任分界点を業務フロー上に明記します。

現実的なのは、「出力の正しさをベンダーが保証する」形ではなく、「一定の水準を満たすための作業と改善プロセスをベンダーが提供する」形です。そのうえで、誤った出力が業務に与える影響を誰が負うのかを業務フロー図に落として合意します。

外部顧客への回答や、与信・採用など人に影響する判断を扱う場合は、人による確認を必須工程として組み込むのが基本線です。AIエージェントに自動実行させる範囲を広げるほど、承認地点の設計とログ保全の重要性が増します。

情報漏洩・規制対応のリスクはどう管理する？

個人情報の取扱い、再委託の可否、監査権、インシデントの通知期限を契約条項で担保しておきます。

日本国内では個人情報保護法が基本の枠組みです。EU圏の個人データを扱う場合は、GDPRが適用されるかを確認する必要があります。加えて、欧州のAI法（EU AI Act）のように用途のリスク区分に応じた規制の議論が各地域で進んでいるため、海外展開を含む業務では自社の法務部門と適用範囲を確認してください。条文の適用は業務内容と地域で変わるため、一般論だけで判断しないのが安全です。

運用面では、次の項目を契約と運用手順の両方に書いておくと機能します。

1. 入力禁止データの明示：機密区分ごとに、利用者が入力の可否を判断できる形で定義する
2. 監査権：年次のセキュリティ報告の提出と、必要時の監査受け入れを条項化する
3. インシデント通知：発覚から通知までの時間を数値で定め、連絡経路を指定する
4. サービス停止時の対応：障害時の代替手段と、業務を止めない運用を取り決める
5. 契約終了時の措置：データの返還形式、削除証明の提出、移行への協力義務を定める

ベンダーロックインを避ける体制はどう作る？

ロックインを避けるには、データとプロンプトの可搬性を選定条件に入れ、出口の手順を契約に明記します。

ロックインは「悪いベンダーを選んだから起きる」のではありません。改善のたびに委託しないと動かせない構造から起きます。DX（デジタルトランスフォーメーション）の文脈で長年語られてきた課題と本質は同じですが、AI案件は改善サイクルが速いぶん、影響が早く表れます。

可搬性はどこで確保する？

可搬性はデータ形式、モデルを差し替えられるか、連携方式が標準に準拠しているかの三点で確保します。

すべてを可搬にしようとすると初期コストが上がります。優先順位を付けるなら、まず評価データと業務データ、次にプロンプト、最後にモデル選択の順で押さえるのが、費用対効果の面で現実的だと感じています。

社内に残す能力は何か？

社内に残すべきなのは、業務要件の設計、評価データの保有、運用指標の管理という三つの能力です。

実装をすべて外部に出しても、この三つが社内にあればベンダーは入れ替えられます。逆に、精度の評価をベンダーの報告に頼っている状態では、金額交渉でも改善要求でも主導権を失います。

最小限の体制としては、業務側に要件と評価を持つ担当を一人、情報システム側に連携と権限を見る担当を一人置く形から始められます。専任のAX推進組織が理想ですが、その立ち上げを待っていると着手が遅れます。

乗り換え・撤退の準備はどう進める？

乗り換えの準備は、契約終了時のデータ返還・削除証明とログ引き継ぎの手順を事前に合意することから始めます。

導入時に出口の話をするのは気が引ける、という声はよく聞きます。しかし稼働後に交渉すると、条件は必ず悪くなります。契約更新のたびに次の項目を点検する運用にしておくと、判断を機械的に進められます。

1. 年次点検：契約数と実利用者数、月次費用の予算比、精度指標の推移を突き合わせる
2. 代替可能性の確認：同等機能を他の形態（SaaS・内製）で実現する場合の概算を年に一度取る
3. 依存度の記録：そのベンダーしか把握していない設定・手順を洗い出し、文書化を求める
4. 移行手順の維持：エクスポート手順と移行にかかる期間を、稼働後も最新の状態に保つ

最後に一点付け加えます。AIベンダーの選定は「最良の一社を当てる」作業として語られがちですが、実務での実感は違います。大事なのは、選定を間違えたときに立て直せる状態を作っておくことです。評価データを自社に置き、要件を自社の言葉で書けていれば、次の選定は一度目より確実に速く、安くなります。

本稿の実務所見部分は監修者による確認・承認を経て公開しています。配点例は評価設計の構造を示すための例示であり、業界標準値や特定企業の実績値ではありません。契約条項および法令の適用は業務内容・地域・契約形態によって異なるため、最終判断は自社の法務部門および専門家の確認を前提としてください。LLMの提供条件や料金は改定されるため、OpenAI・Anthropic・Google・Microsoftなど各社の公開情報の最新版をご確認ください。

姉妹メディアの関連記事

AIベンダーを選定した後は、PoCで止めずに現場へ定着させる進め方が、投資の成果を大きく左右します。