AI導入ベンダーから提案書や見積書を受け取ったものの、どの会社を選ぶべきか判断できずに悩んでいないでしょうか。
AIベンダーの提案では、使用するAIモデル、精度、開発実績、料金などが強調される傾向があります。しかし、技術力や価格だけで発注先を決めると、次のような問題が起こる可能性があります。
- PoCでは良い結果が出たものの、本番業務で使えない
- 現場の業務フローに合わず、利用が定着しない
- 運用や改善をベンダーに依存し続ける
- 設定やデータを移管できず、他社へ切り替えられない
- 初期見積もりに含まれていない追加費用が発生する
- 契約終了時の引き継ぎに高額な費用がかかる
AI導入ベンダー選定で重要なのは、単に「AIを開発できる会社か」を判断することではありません。自社の業務課題を理解し、成果の合否基準を一緒に設計し、導入後の運用・改善・知識移転・終了時の引き継ぎまで実行できる会社かを確認する必要があります。
また、ベンダーへ提案を依頼する前に、発注側で決めるべき項目もあります。すべてをベンダーに任せるのではなく、次の3区分を明確にすることが重要です。
- 自社が先に決めてから提案を求める項目
- ベンダーに複数案を出してもらう項目
- ベンダー単独で決めさせてはいけない項目
本記事では、AI導入ベンダーを比較中、相見積もり中、提案書評価中の担当者に向けて、評価軸、質問リスト、RFP作成前の確認事項、契約前チェックリストを実務的に解説します。
なお、2026年7月時点では、経済産業省・総務省の「AI事業者ガイドライン」は第1.2版が最新版です。同ガイドラインでは、関係者間の責任分配、文書化、教育・リスキリング、相互接続性・相互運用性などが示されています。デジタル庁も生成AIの調達・利活用ガイドライン第2.0版を公開し、基本項目と加点項目を分けた評価、要求事項の設定、裏付け資料の確認などを整理しています。政府調達向けの資料ですが、民間企業のベンダー選定にも応用できる考え方です。

AI導入ベンダー選定は技術力だけで決めてはいけない
AI導入ベンダーを比較するとき、技術力は重要な評価項目です。ただし、技術力が高ければ導入が成功するとは限りません。技術力は、あくまで必要条件の一つです。AI導入を成功させるには、少なくとも次の3つを分けて評価する必要があります。
| 評価する視点 | 確認する内容 |
|---|---|
| 作れるか | 必要な精度や機能を実現できるか |
| 使い続けられるか | 現場運用、監視、改善、教育ができるか |
| 離れられるか | データや設定を移管し、他社や自社へ引き継げるか |
AIの技術説明だけでは提案の良し悪しを判断できない
提案書に有名なAIモデル名や高度な専門用語が並んでいても、自社の業務に適しているとは限りません。例えば、AIによる問い合わせ回答システムを導入する場合、単純な回答精度だけでなく、次のような条件によって実用性が変わります。
- 誤回答が発生しやすい質問は何か
- 回答できない場合にどのような案内を出すか
- 人の担当者へ切り替える条件は何か
- 参照情報が更新されたときに誰が反映するか
- 誤回答をどのように記録し、改善するか
- 個人情報や機密情報が入力された場合にどう処理するか
これらを説明できなければ、技術的に優れたAIであっても、実際の業務では安定して使えません。ベンダーの技術力を確認するときは、「どのモデルを使うか」だけでなく、業務上の失敗をどのように定義し、発見し、修正するかまで確認しましょう。
PoCの成功と本番導入の成功は同じではない
PoCとは、技術や業務上の仮説を小規模に検証する取り組みです。PoCで一定の精度が出ても、次の条件が確認できていなければ、本番導入の可否は判断できません。
- 実際の業務データを反映した評価になっているか
- 例外的なケースを含めているか
- 現場担当者が操作できるか
- 人による確認作業が過度に増えないか
- 利用件数が増えても処理できるか
- 継続的な利用料金が予算内に収まるか
- データ更新後も品質を維持できるか
- 障害や誤出力が発生したときの対応方法があるか
PoCは「AIが動いたか」を確認するだけの場ではありません。自社の業務成果につながるか、本番運用へ進む条件を満たしたかを判断する場として設計する必要があります。
比較すべきなのは成果を継続できる仕組み
優れたAIベンダーは、開発だけを提案するのではなく、導入後の状態まで具体的に説明します。確認すべき内容は次のとおりです。
- 業務課題をどのように捉えているか
- AIを使う範囲と使わない範囲をどう分けるか
- 何をもって成功と判断するか
- 誤出力や精度低下をどう監視するか
- 誰がデータや設定を更新するか
- 自社担当者へどのように知識を移すか
- 他社へ切り替える場合に何を引き渡せるか
デモの見栄えよりも、導入後の業務を具体的に想像できる提案を評価しましょう。
【最重要】発注側とベンダーの決定範囲を3区分する
AI導入でよくある失敗は、自社で決めるべきことまでベンダーに委ねてしまうことです。ベンダーは、AI技術やシステム開発の専門家です。しかし、自社の経営方針、業務上の優先順位、許容できるリスクまで決める立場ではありません。ベンダー選定を始める前に、決定範囲を次の3つに分けましょう。
| 区分 | 主な項目 |
|---|---|
| 自社が先に決める | 業務課題、目標、優先順位、対象範囲、許容できないリスク |
| ベンダーに複数案を求める | 技術方式、開発範囲、PoC方法、運用方法、段階導入案 |
| ベンダー単独で決めさせない | 最終的な合否、データ利用範囲、許容誤差、重要業務の自動化範囲 |

自社が先に決めてから提案を求める項目
ベンダーへ問い合わせる前に、少なくとも次の項目を社内で整理します。まず「解決したい業務課題」を、「生成AIを導入したい」ではなく、どの業務の何を改善したいのかを明確にします。例えば次のように表現します。
- 問い合わせ内容の分類に時間がかかっている
- 営業担当者によって提案書の品質に差がある
- 社内文書を探す時間が長い
- 検品作業の目視負担が大きい
- 需要予測が担当者の経験に依存している
AI導入は目的ではなく、課題を解決する手段です。次に「対象業務と対象外業務」を決めます。AIを利用する範囲だけでなく、利用しない範囲も決めます。例えば、問い合わせ回答であれば、一般的な質問にはAIを使う一方、契約、返金、事故、健康、安全などに関する質問は人が対応するという区分が考えられます。
「導入後に実現したい状態」は、「業務効率化」だけでは提案の評価ができません。次のように、可能な範囲で測定できる状態にします。
- 問い合わせの一次分類時間を半減する
- 文書検索にかかる平均時間を短縮する
- 提案書の初稿作成時間を削減する
- 入力ミスによる差し戻し件数を減らす
- 人が確認すべき案件を適切に絞り込む
また、精度目標を決める前に「許容できないリスク」を整理します。個人情報を誤って表示する、存在しない契約条件を回答する、法令や社内規程に反する処理を行う、人の確認なしで重要な判断を確定する、自社の機密情報が外部学習に使われる、といった重大な誤りを防ぐ仕組みは設計できます。
ベンダーに複数案を出してもらう項目
発注側が技術方式まで細かく指定すると、より適切な代替案が出にくくなります。特に「AIを使う案とAIを使わない案」は複数提示してもらいましょう。業務課題によっては、AIよりも既存システムの設定変更、入力フォームの改善、ルールベースの自動化などが適している場合があります。
導入方式にもそれぞれ特徴があります。
| 方式 | 特徴 |
|---|---|
| 既存SaaS | 導入が比較的早いが、仕様変更や移管に制約がある場合がある |
| SaaSのカスタマイズ | 標準機能を活用しつつ、自社業務へ合わせやすい |
| 個別開発 | 自由度が高い一方、費用や運用負担が大きくなりやすい |
初期費用だけでなく、運用費、変更費、移行費まで比較します。PoCの規模と進め方、運用と知識移転の方法についても、費用・期間・確認できること・確認できないことを示した複数案を求めましょう。
ベンダー単独で決めさせてはいけない項目
「ベンダーが決めてはいけない」とは、ベンダーの意見を聞かないという意味ではありません。専門的な提案を受けたうえで、最終的な判断は自社が行うべき項目という意味です。主な項目は次のとおりです。
- 業務上の成功・失敗の最終判定
- 許容できる誤りの種類と範囲
- AIの出力を人が確認せず利用できる範囲
- 個人情報や機密情報の利用範囲
- 自社データをAIの学習やサービス改善に使ってよいか
- 重要業務の優先順位
- 導入予算の配分
- 成果物や設定データの引き渡し範囲
- 契約終了後のデータ削除や移行方針
ベンダーが提示する標準条件をそのまま受け入れるのではなく、自社の業務リスクに照らして判断します。
合否基準は共同設計し、最終決定は自社が行う
AIの合否基準は、自社だけで決めることも、ベンダーだけで決めることも適切ではありません。次のように役割を分けます。
| 項目 | 主に担当する側 |
|---|---|
| 達成したい業務成果 | 自社 |
| 許容できない失敗 | 自社 |
| 現実的な技術水準の提示 | ベンダー |
| 評価データと測定方法の提案 | ベンダー |
| PoCの具体的な合否条件 | 双方で合意 |
| 本番導入へ進む最終判断 | 自社 |
例えば、文書検索AIのPoCでは、単に「正答率80%以上」とするだけでは不十分です。回答精度、回答根拠となる文書の提示率、重大な誤回答の件数、回答不能時に適切に判断を保留できる割合、担当者の検索時間の削減量、現場担当者による使いやすさ、利用1件当たりの費用、運用担当者が情報更新できるかなど、複数の条件を組み合わせます。重要なのは、何を測り、どの状態なら本番導入へ進み、どの状態なら改善または中止するかを開始前に合意することです。
RFP作成前に自社で整理する12項目
RFPとは、ベンダーに提案を依頼するための文書です。詳細なRFPを作成できていなくても、次の12項目を整理すれば、ベンダーとの初回相談を進めやすくなります。
| No. | 整理する項目 | 主な内容 |
|---|---|---|
| 1 | 導入の背景 | なぜ今取り組むのか |
| 2 | 対象業務 | どの業務を改善するのか |
| 3 | 現状の業務フロー | 誰が、何を、どの順番で行うか |
| 4 | 現在の課題 | 時間、ミス、属人化、コストなど |
| 5 | 対象利用者 | 部門、人数、ITスキル |
| 6 | 処理量 | 月間件数、繁忙期、データ量 |
| 7 | 期待する成果 | 工数、時間、品質、売上など |
| 8 | 許容できない失敗 | 重大な誤り、情報漏えいなど |
| 9 | 保有データ | 種類、量、形式、保存場所 |
| 10 | システム連携 | 連携が必要な既存システム |
| 11 | 社内体制 | 責任者、現場、情シス、法務 |
| 12 | 予算と時期 | 予算帯、開始時期、判断期限 |

現状の業務フローを具体的にする
「資料作成に時間がかかる」といった説明だけでは、ベンダーは適切な提案を作れません。誰が作業し、何を入力し、どのシステムや資料を使い、何を判断し、何を出力し、誰が確認・承認し、どこで手戻りが起こるか、という順番で整理します。業務フローを整理すると、AIを使うべき部分と、業務ルールを見直すべき部分を分けやすくなります。
成果指標は技術指標と業務指標に分ける
AI導入では、技術指標だけでなく業務指標も設定します。技術指標には正答率、検出率、誤検出率、回答根拠の提示率、処理時間、稼働率などがあります。業務指標には作業時間の削減、対応件数の増加、差し戻し件数の減少、顧客対応時間の短縮、売上や成約率の変化、担当者の利用率、人による確認作業の量などがあります。技術指標が良くても、人の確認作業が増えれば、業務効率化につながらない場合があります。
RFP前の1ページ整理シート
初回相談では、次の形式でまとめると伝わりやすくなります。RFPを最初から完成させようとするより、まずは自社の課題と制約を明確にすることが大切です。
| 項目 | 記入内容 |
|---|---|
| 解決したい課題 | |
| 対象業務 | |
| 現在の進め方 | |
| 発生している問題 | |
| 期待する成果 | |
| 利用できるデータ/利用できないデータ | |
| 既存システム | |
| 想定利用者 | |
| 希望時期・予算帯 | |
| ベンダーに提案してほしいこと |
相見積もりは条件をそろえて比較できる状態にする
AI導入の相見積もりでは、金額だけを並べても正しく比較できません。A社はPoCのみ、B社は本番開発まで、C社は運用保守まで含んでいるというように、見積範囲が異なることが多いためです。
必須要件・希望要件・代替提案を分ける
提案依頼時には、要件を次の3つに分けます。すべてを必須要件にすると提案の自由度がなくなり、すべてをベンダー任せにすると各社の提案条件がばらばらになります。
| 区分 | 意味 |
|---|---|
| 必須要件 | 満たさなければ候補にできない条件 |
| 希望要件 | 満たすと評価が上がる条件 |
| 代替提案 | ベンダー独自の方法を提案してもらう項目 |
見積書の費目を統一する
候補各社には、次の費目を分けて見積もってもらいましょう。特に、教育、データ移管、終了時支援は初期見積もりから外れやすいため、独立した項目として提示を求めます。
| 費目 | 確認する内容 |
|---|---|
| 業務整理・要件定義 | ヒアリング、業務分析、責任分界 |
| データ調査・整備 | データ量・品質・欠損、クレンジング、ラベル付け |
| PoC・本番開発 | 環境構築、評価、システム構築、連携 |
| テスト・教育 | 受入支援、管理者研修、利用者研修 |
| 運用保守・継続改善 | 監視、障害対応、データ更新、再評価 |
| 外部利用料 | AIモデル、クラウド、外部API |
| データ移管・終了時支援 | 出力、変換、引き継ぎ、削除確認 |
前提条件と総保有コストで比較する
見積金額だけでなく、見積もりが成立する前提を確認します。自社が用意するデータの状態、自社側で必要な作業時間、対応する利用者数、月間の処理件数、システム連携数、修正回数、打ち合わせ回数、見積もりに含まれない作業、追加費用が発生する条件などです。「一式」とだけ記載された項目は、具体的な作業内容と工数を確認しましょう。
比較する費用は初期費用だけではありません。初期費用+月額費用+外部AI・クラウド利用料+保守費用+改善費用+社内運用工数+データ整備費用+移行・終了費用を含めた総保有コストで評価します。相見積もり中に特定のベンダーから受けた重要な質問への回答が提案内容に影響する場合は、他の候補ベンダーにも同じ情報を共有し、公平な比較がしやすい状態にします。
AI導入ベンダーを比較する10の評価軸

AI導入ベンダーは、次の10項目で比較します。配点は案件に合わせて変更してください。個人情報や機密情報を扱う案件ではセキュリティの比重を高くし、自社運用を目指す場合は知識移転やデータ移管の配点を増やします。
| 評価軸 | 配点例 | 主な確認内容 |
|---|---|---|
| 1.業務理解 | 15点 | 現状業務、課題、例外処理を理解しているか |
| 2.解決策・代替案 | 10点 | 特定技術ありきではなく複数案があるか |
| 3.技術・データ対応 | 15点 | 技術力、データ品質、評価設計 |
| 4.PoC・合否基準 | 10点 | 測定方法、合格条件、未達時対応 |
| 5.プロジェクト管理 | 8点 | 体制、進捗、課題、変更管理 |
| 6.セキュリティ・ガバナンス | 10点 | データ管理、ログ、権限、事故対応 |
| 7.運用・継続改善 | 10点 | 監視、保守、更新、品質改善 |
| 8.知識移転 | 8点 | 文書、研修、自社運用への移行 |
| 9.データ移管・ロックイン | 7点 | 出力形式、設定移管、他社移行 |
| 10.契約・総保有コスト | 7点 | 契約条件、追加費用、終了費用 |
| 合計 | 100点 |
業務理解では、ベンダーが自社の説明をそのまま書き直すのではなく、現状業務の流れを図にし、問題の原因を分解し、例外処理や繁忙期を確認し、AIを使わない方がよい部分まで示しているかを見ます。技術・データ対応では、モデル名や資格だけでなく、類似業務の経験、データ品質の調査方法、評価データの作り方、精度が低かった場合の原因分析方法、外部AIサービスへの依存範囲、モデル変更時の再評価方法を確認します。過去実績は、企業名だけでなく、今回の担当者が実際に関与したかまで確認しましょう。
セキュリティでは、「安全ですか」と質問するだけでなく、データの保存場所、暗号化、アクセス権限、操作ログ、保持期間、契約終了後の削除、インシデント時の連絡、外部AIサービスへの送信内容、再委託先、自社データの学習利用、監査資料や第三者認証を確認します。運用では「保守あり」という表現だけでなく、作業内容と対応時間を明確にします。営業担当者の説明が優れていても実際のプロジェクト担当者が同じとは限らないため、最終候補の段階で実際の責任者と面談することが望ましいでしょう。
提案書を公平に採点する評価シートの作り方

提案書は、点数を付けるだけでは公平に評価できません。まず失格・要再確認条件を確認し、次に加点項目を採点し、最後に残るリスクと契約条件を整理する、という3段階で評価します。
失格条件と加点評価を分ける
重大な条件は、他の高得点で相殺できないようにします。例えば、業務理解や技術力が高くても、必須のセキュリティ条件を満たさない場合は、総合点だけで採用しないようにします。失格または要再確認条件の例は次のとおりです。
- 必須のセキュリティ要件を満たさない
- 自社データの利用目的が不明
- 重要なデータや設定を出力できない
- PoCの合否基準を事前に合意できない
- 再委託先や使用サービスを説明できない
- 契約終了時の対応条件を提示しない
- 重大な前提条件が見積書に記載されていない
自己申告ではなく証拠で評価する
「対応できます」という自己申告だけでなく、裏付けを確認します。プロジェクト計画書、システム構成図、テスト計画書、運用設計書、障害対応フロー、教育計画、データ出力仕様、移管対象一覧、課題管理表、見積内訳、類似案件の体制例などのサンプル提出を依頼しましょう。デジタル庁の生成AI調達ガイドライン第2.0版でも、基本項目と任意の加点項目を分け、要求事項を満たしているか確認するための裏付け情報を事業者へ求める方法が整理されています。必須条件、加点条件、証拠資料を分けることで、印象に左右されにくい評価ができます。
評価者間の点数差を確認する
複数人で評価するときは、平均点だけでなく、評価者間の差を確認します。業務部門は高く評価している一方、情報システム部門が低く評価している場合は、セキュリティ懸念、操作の難しさ、自社側の作業負担、運用体制の不明確さなどが原因として考えられます。点数差が大きい項目は、最終判断前に追加質問します。
ベンダーの実力が分かる実務質問リスト

ベンダーへ「この機能はありますか」と質問すると、回答は「あります」「対応可能です」で終わりがちです。実力を見極めるには、方法、責任、成果物、証拠まで聞く必要があります。
| 質問(業務成果・合否基準) | 良い回答の特徴 | 注意したい回答 |
|---|---|---|
| 当社の課題をどのように理解していますか | 現状業務と原因を分けて説明する | 提案依頼書の内容を繰り返すだけ |
| PoC開始前に合否基準を一緒に定義できますか | 業務指標と技術指標を提案する | 精度は実施後に考えると言う |
| 重大な誤りをどのように定義しますか | 業務影響を踏まえて分類する | すべて同じ誤りとして扱う |
| 目標未達の場合はどう対応しますか | 改善・代替・中止条件を示す | 追加開発すれば改善するとだけ答える |
| 質問(データ・設定の移管) | 良い回答の特徴 | 注意したい回答 |
|---|---|---|
| 入力・評価データ、設定情報はどの形式で出力できますか | 対象・形式・時期・費用を示す | データは出せるとだけ答える |
| プロンプトやRAG設定を引き渡せますか | 設定・参照元・評価データを区分する | 出力データだけを移管対象とする |
| 他社へ移せるものと移せないものを一覧化できますか | 資産ごとに理由を説明する | 独自技術なので非開示と一括回答する |
| 契約終了後も自社で利用できる成果物は何ですか | 成果物を具体的に列挙する | 契約終了時に別途協議とする |
| 質問(運用・知識移転・終了) | 良い回答の特徴 | 注意したい回答 |
|---|---|---|
| 導入後の運用担当者へ知識を移す計画がありますか | 研修・演習・文書・到達目標がある | 操作説明会を1回実施するだけ |
| 担当者交代時に使える資料は何ですか | 構成図・設定一覧・手順書がある | 担当者が説明すると答える |
| 契約終了時の引き継ぎを見積もりに含められますか | 独立費目として作業を示す | 契約終了時に別途協議とする |
| 契約終了後のデータ削除を証明できますか | 削除対象・時期・証明方法を示す | 自動的に削除されるとだけ答える |
見積もりについても、「この金額が成立する前提条件は何ですか」「見積もりに含まれない作業は何ですか」「仕様変更時の費用はどう算定しますか」「利用量が増えた場合の費用を試算できますか」「外部サービスが値上げした場合はどうなりますか」を確認します。回答を受けたら「できますか」だけで終わらせず、対象、方法、時期、担当、費用、成果物まで確認しましょう。
運用・知識移転・社内定着をどう評価するか
AI導入後の支援について、提案書に「手厚くサポートします」と書かれていても、評価材料にはなりません。サポート内容を、作業と成果物に分解します。運用作業(利用者管理、参照データの更新、品質指標の確認、誤出力の調査、設定変更、モデル変更、障害の一次対応、セキュリティ事故対応、問い合わせ、改善提案)について、自社とベンダーのどちらが担当するかを整理します。「共同」とする場合も、最初に動く担当者と最終判断者を決めます。
知識移転の成果物としては、システム構成図、使用サービス・AIモデル一覧、データ項目一覧、設定一覧、プロンプト一覧、RAGの参照データ・検索設定、操作マニュアル、管理者手順書、品質評価手順、障害対応手順、データ更新手順、バックアップ・復旧手順、教育資料、FAQ、変更履歴などが挙げられます。経済産業省・総務省のAI事業者ガイドライン第1.2版でも、責任者と責任分配の明確化、必要情報の文書化、AIに関わる人への教育・リスキリング、他システムとの相互運用性への留意が共通の指針として示されています。知識移転は付加的なサービスではなく、安定運用を支える重要な要素として評価すべきです。
知識移転の目標は次のように段階化すると、ベンダーと認識を合わせやすくなります。
| 段階 | 状態 |
|---|---|
| レベル1 | 日常運用を含め、ほぼすべてをベンダーに依存する |
| レベル2 | 日常運用は自社、設定変更や改善はベンダーが行う |
| レベル3 | 軽微な設定変更や品質確認まで自社で行える |
| レベル4 | 他社への移管や一部内製化にも対応できる |
必ずレベル4を目指す必要はありません。重要なのは、目標とする状態を決め、その状態までの教育・文書作成を見積もりに含めることです。研修の実施回数だけでは知識移転の完了を判断できないため、自社担当者がデータを更新できる、利用者を追加・削除できる、品質レポートを作成できる、軽微な設定変更ができる、新任担当者へ社内で引き継げる、といった受入確認や完了条件を設定しましょう。
データ移管・引き継ぎ・ベンダーロックインを確認する

データ移管というと入力データの返却だけを想像しがちですが、AIシステムではデータ以外にも運用や品質に関わるさまざまな資産があります。次の項目について、引き渡しの可否を確認します。
| 移管対象 | 確認内容 |
|---|---|
| 元データ・加工済みデータ | 提供データ、クレンジング・構造化後のデータ |
| 評価データ | テストケース、正解データ |
| プロンプト・RAG設定 | 参照元、分割方法、検索条件 |
| ワークフロー・権限設定 | 処理順序、条件分岐、ロール、アクセス権 |
| ログ・評価結果 | 入出力・操作・エラー、精度・改善履歴 |
| ソースコード・構成情報 | 個別開発プログラム、クラウド・API・外部サービス |
| 運用文書 | 手順書、FAQ、障害記録 |
各資産について、権利を持つのは誰か、どの形式で出力できるか、出力に費用がかかるか、いつ出力できるか、他社が再利用できるか、削除対象になるか、外部サービスの規約による制限があるかも確認します。「データを出力できます」という回答だけでは不十分で、CSVやJSONなど一般的な形式か、独自形式なら仕様書が提供されるか、文字コードや項目定義が示されるかまで確認します。
契約終了時の引き継ぎは、移管対象の確認、データ・設定の出力、資料の更新、移行先への説明、質疑応答、並行稼働支援、アカウント停止、データ削除、削除完了の報告、最終報告書の作成に分けて見積もってもらいます。経済産業省の「AIの利用・開発に関する契約チェックリスト」でも、ベンダーが保持できる期間、契約終了時の削除義務、削除を証明する書類、ユーザーへのインプット提供義務や提供条件などが確認項目として整理されています。
AIベンダーが別の会社の基盤モデルやクラウドサービスを利用しているケースもあります。使用するAIモデルとバージョン、使用するクラウド・外部API、外部サービスへの送信データ、保存・学習の有無、利用規約の変更時の対応、価格改定時の対応、サービス終了時の代替案、別モデルへ切り替える方法と再評価方法を確認しましょう。デジタル庁の生成AI調達ガイドライン第2.0版でも、ベンダーロックイン回避の観点から、利用する生成AIモデルをバージョン情報とともに明示できることが基本項目として示されています。
契約前に確認する成果物・検収・責任分界
契約確認を法務部門だけに任せると、業務上必要な条件が契約書へ反映されないことがあります。業務担当者、情報システム担当者、法務担当者で確認項目を分担しましょう。以下は一般的な確認観点であり、個別案件の法的判断は弁護士などの専門家へ確認してください。
契約形態・作業範囲と成果物・検収条件
AI導入では、業務整理、PoC、本番開発、運用保守で契約を分ける場合があります。契約名称だけで判断せず、どの作業を行う契約か、何を成果物とするか、完成責任を負う範囲、自社が協力すべき作業、仕様が確定していない部分の扱い、途中で中止した場合の費用、次の工程へ進む条件を確認します。PoCは結果が事前に確定しにくいため、「期待した精度が出ること」だけを成果とするのではなく、検証の実施、結果分析、課題整理、次工程の判断材料などを成果物として定める方法があります。
成果物と検収条件については、納品される成果物、納品形式、納品期限、検収方法、検収用データ、合格条件、不合格時の修正回数、再検証の費用、検収期間、検収後の不具合対応を明確にします。AIの精度だけでなく、運用手順、設定情報、教育資料なども成果物に含めるか確認します。
インプット・アウトプット・処理成果の扱い
AIでは、入力データと出力結果だけでなく、処理の途中で新しいデータや設定が作られることがあります。経済産業省の契約チェックリストは、汎用AIサービス利用型、カスタマイズ型、新規開発型を整理したうえで、インプット、アウトプット、インプット処理成果、アウトプット処理成果などを契約上の確認対象として示しています。特に、自社データの利用目的、ベンダーの技術開発や学習への利用可否、第三者提供、再委託先への提供、出力結果の利用条件、権利帰属、契約終了後の保持・削除、移管時の提供条件を確認します。
変更管理・障害・契約終了と移行支援
AI導入では検証中に要件やデータ条件が変わることがあります。変更内容を記録し、費用・期間・品質への影響を評価し、双方が承認し、見積書や仕様書を更新し、テスト・検収条件を見直す手順を決めます。口頭やチャットだけで変更を進めると、後で追加費用や責任範囲を巡る認識違いが生じます。障害・インシデントについては、受付窓口、連絡時間、重大度の分類、初動時間、復旧目標、原因調査、再発防止、ログの提供、外部AIサービス障害時の対応、セキュリティ事故時の報告を確認します。
契約終了時には、解約通知期限、最低契約期間、データ・設定の出力期限、引き継ぎ資料、移行先への説明、並行稼働期間、移行支援費用、アカウント停止日、データ削除日、バックアップデータの扱い、削除完了の確認方法を確認します。IPAの「情報システム・モデル取引・契約書」第二版では、セキュリティ、プロジェクトマネジメント義務と協力義務、複数契約の関係、再構築対応などが主要な論点として整理されています。AI案件でも、仕様だけでなく双方の協力事項、管理方法、複数サービス間の関係を契約前に確認することが重要です。
【保存版】RFP前・相見積もり中・契約前チェックリスト
以下のチェックリストは、社内会議やベンダーへの追加質問に利用できます。
RFP作成前チェックリスト
- 解決したい業務課題を説明できる
- 対象業務と対象外業務を分けている
- 現在の業務フローと作業時間・件数を整理している
- 導入後に実現したい状態を定めている
- 技術指標と業務指標を分けている
- 許容できない失敗を整理している
- 使用できるデータと使用してはいけないデータを把握している
- 連携が必要なシステムを把握している
- 社内責任者と最終決裁者を決めている
- ベンダーに複数案を求める項目を決めている
相見積もり・提案書評価チェックリスト
- 各社へ同じ前提条件を伝えている
- 必須要件と加点要件を分けている
- 見積費目を統一し、対象外の作業を確認している
- 自社側に必要な作業と追加費用の条件を確認している
- 業務フローへの理解を確認している
- AIを使わない代替案や複数の技術・導入方式を比較している
- PoCの目的を定め、開始前に合否基準を合意できる
- 目標未達時の対応を確認している
- データ品質の調査方法と使用する外部AIサービスを確認している
- プロジェクト担当者と体制、導入後の責任分界を確認している
- 知識移転の計画とデータ・設定の移管方法を確認している
- 終了時支援の費用を確認し、総保有コストで比較している
契約前チェックリスト
- 契約範囲と見積範囲が一致している
- 成果物が一覧化されている
- 検収条件と判定者が明確である
- 自社データの利用目的が明確である
- 出力や設定の権利・利用条件を確認している
- 再委託先と外部サービスを確認している
- 仕様変更時の手順と障害・インシデント対応を決めている
- 契約終了時の引き継ぎ内容を決めている
- データ削除と削除確認の方法を決めている
AI導入ベンダー選定でよくある失敗
提案書評価時に見落としやすい失敗を、防ぐ方法とセットで整理します。
- デモの見栄えだけで選ぶ:デモでは整ったデータが使われがち。自社の実データや難しいケースで、誤回答時の動作まで確認する
- 一番安い見積もりを選ぶ:データ整備・教育・運用・移管が含まれない場合がある。見積範囲をそろえ総保有コストで比較する
- 合否基準をベンダーに任せる:測定方法は共同設計し、最終的な採否は自社が決める
- PoCだけを見て本番運用を確認しない:データ更新・利用者管理・障害対応まで、PoC段階から確認する
- 「サポートあり」を具体化しない:対応内容、時間、回数、料金、成果物を明記してもらう
- 知識移転を説明会1回で終わらせる:担当者が更新・設定変更・障害対応を実行できるか確認する
- データ移管を契約終了時に確認する:契約前に対象、形式、費用、期間を決める
- 外部AIサービスの依存関係を確認しない:価格改定、停止、規約変更時の対応を確認する
最終候補を決める手順と社内稟議のまとめ方

AI導入ベンダーの最終選定は、次の順番で進めます。
- 失格・要再確認条件を確認し、満たさないベンダーは修正提案を求めるか候補から外す
- 業務部門・情報システム部門・管理部門が個別に評価シートを採点する
- 評価者間やベンダー間で差が付いた項目を追加質問し、回答は文書で受け取る
- 営業担当者だけでなく実際の責任者・技術担当者を含めた最終面談を行う
- 採用候補が決まっても、契約前に未確定事項を一覧化する
- 選定理由を事実とリスクでまとめ、契約書・仕様書へ反映する
社内稟議には、選定目的、比較対象、評価方法、選定結果、採用理由、不採用理由、残るリスク、対応策、総費用、次の判断時期を記載します。「最も技術力が高かったから」ではなく、業務理解、運用、移管、費用を含めて説明できる状態にします。
| 項目 | 記載内容 |
|---|---|
| 選定目的 | 何を解決するための導入か |
| 比較対象 | 比較したベンダーと提案方式 |
| 評価方法 | 必須条件、配点、評価者 |
| 選定結果・採用理由 | 得点と評価理由、特に評価した点 |
| 不採用理由・残るリスク | 他社との差、未解決の懸念と対応策 |
| 総費用・次の判断時期 | 初期・運用・変更・終了費用、PoC後や本番移行前 |
AI導入ベンダー選定に関するよくある質問
AIの技術力が最も高いベンダーを選ぶべきですか?
必ずしも技術力が最も高いベンダーが、自社に最適とは限りません。技術力に加えて、業務理解、運用体制、合否基準の設計、知識移転、データ移管、契約条件、総保有コストを確認する必要があります。高度な技術を提案していても、現場が運用できない場合や、ベンダーに依存し続ける設計では、期待した成果を得にくくなります。
RFPが完成していなくてもベンダーへ相談できますか?
相談できます。ただし、業務課題、対象業務、期待する成果、利用可能なデータ、制約、予算帯、希望時期などは事前に整理しておきましょう。詳細な機能仕様を自社だけで決めるよりも、課題と制約を示したうえで、ベンダーに複数案を提案してもらう方法もあります。
相見積もりでは予算を伝えた方がよいですか?
予算上限をそのまま伝えるかは案件によりますが、少なくとも現実的な予算帯を示した方が、実行可能な提案を受けやすくなります。予算を伝える場合は、予算内の標準案だけでなく、最小構成案、推奨案、段階導入案などを分けて提案してもらうと比較しやすくなります。
各社のPoC提案が違う場合は、どう比較すればよいですか?
PoCの目的、対象業務、使用データ、評価指標、成果物をそろえて比較します。各社の方法を完全に同じにする必要はありませんが、何を確認できるPoCなのか、確認できないことは何かを明記してもらいましょう。費用や期間だけでなく、本番導入の判断に必要な情報が得られるかを評価します。
ベンダーロックインを防ぐには、何を確認すべきですか?
データだけでなく、設定、プロンプト、RAGの参照情報、評価データ、ログ、運用文書などを移管できるか確認します。また、出力形式、移管費用、移行期間、他社への説明支援、契約終了後のデータ削除についても契約前に決めましょう。すべてを移管可能にすることが難しい場合は、移管できないものと、その影響を把握したうえで判断することが重要です。
まとめ|AI導入ベンダーは導入後と終了時まで見て選定する
AI導入ベンダー選定では、技術力と価格だけを比べても、適切な発注先を判断できません。重要なポイントは次のとおりです。
- 業務課題、優先順位、許容できないリスクは自社が先に決める
- 技術方式、PoC、運用方法はベンダーに複数案を求める
- 最終的な合否やデータ利用範囲をベンダー単独で決めさせない
- 合否基準は共同設計し、最終的な採否は自社が判断する
- 見積条件をそろえ、初期費用ではなく総保有コストで比較する
- 機能だけでなく、運用、知識移転、データ移管を評価する
- 契約終了時の引き継ぎを、契約前から見積もりに含める
良いAIベンダーは、自社の強みだけを説明する会社ではありません。できないこと、前提条件、リスク、代替案、終了時の対応まで具体的に説明できる会社です。提案書や見積書を受け取った段階で不明点が残っている場合は、発注前に追加質問を行いましょう。重要な条件は口頭回答で終わらせず、提案書、仕様書、見積書、契約書へ反映することが大切です。
AI関連のガイドライン、外部サービスの仕様、利用規約、法令は更新される可能性があります。実際の導入・契約時には、公式資料の最新版を確認し、必要に応じて法務、情報セキュリティ、AI導入支援の専門家へ相談してください。
AIベンダーから提案書や見積書を受け取ったものの、比較基準、追加質問、契約前の確認事項が整理できていない場合は、発注前に第三者の視点を入れる方法があります。RFP作成前の社内要件整理、各社の提案条件の横並び比較、PoCの合否基準の確認、運用・知識移転・データ移管の漏れ確認、見積書の対象外項目や追加費用の整理、終了時の引き継ぎ条件の確認など、現在の検討段階に合わせてご相談いただけます。機密情報を伏せた状態でも、評価項目、質問リスト、比較表の整理は可能です。どのベンダーが有名かではなく、自社の業務に合うかを判断したい方は、現在の検討段階と受け取っている資料の種類を添えてお問い合わせください。
