生成AIベンダーの選び方｜比較表・RFP・契約前チェックリスト

生成AIベンダーを選ぶとき、最初にモデル名や料金表を並べるのはおすすめしません。

結論から言えば、先に決めるべきなのは「自社の業務で、何を満たせば採用するか」です。そのうえで、候補サービスを同じ条件で比較し、小さなPoCで確かめ、最後に契約条件を確認します。

実務では、次の順番にすると選定がぶれにくくなります。

対象業務と対象外を決める
必須条件と加点条件を分ける
同じ質問票・同じテストケースで比較する
セキュリティとデータの扱いを確認する
実データに近いPoCで品質と運用負荷を測る
初期費用ではなく総コストで比較する
SLA・サポート・契約終了時のデータ処理まで確認する
評価表と根拠を残して決裁する

2026年6月、デジタル庁は「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」を2.0版へ改定し、調達チェックシートと契約チェックシートを別紙として公開しています。民間企業向けの強制ルールではありませんが、生成AIの調達を「機能比較だけで終わらせない」ための確認観点として参考になります。

この記事では、SaaS型の生成AI、社内検索・RAG、AIエージェントなどを導入するときに、担当者がそのまま比較表へ落とせる形で選定手順を整理します。

この記事は一般的な実務整理です。個人情報、秘密保持、知的財産、損害賠償、準拠法などの契約判断は、自社の法務・情報セキュリティ・個人情報保護・調達担当者と確認してください。

まず「ベンダー」ではなく「業務」を決める
必須条件と加点条件を分ける
1. 必須条件
2. 加点条件
比較表は100点満点より「根拠」を残す
ベンダーへ同じ質問をする
デモではなく「同じテストケース」でPoCする
料金は月額単価ではなく総コストで比較する
契約前に確認する10項目
「撤退できるか」を選定条件に入れる
RFP・質問票にそのまま使える項目
迷ったらこの順番で3社まで絞る
選定会議で最後に確認する5つの質問
1. WRITTEN BY
  1. kazurinho
2. RELATED ARTICLES

まず「ベンダー」ではなく「業務」を決める

選定が失敗しやすいのは、「生成AIを導入したい」から話を始めるケースです。

同じ生成AIでも、目的が違えば重視する条件は変わります。

利用目的	特に重視する条件
文書の要約・下書き	操作性、出力品質、利用者管理、入力データの扱い
社内文書検索・RAG	検索精度、引用元表示、アクセス制御、更新反映
コーディング支援	開発環境との統合、コードの扱い、監査、管理機能
問い合わせ対応	回答精度、エスカレーション、ログ、運用監視
AIエージェント	実行権限、承認、ツール制限、監査ログ、停止手段

たとえば、社内検索が目的なのに「モデルのベンチマークが高い」という理由だけで選んでも、必要な文書を検索できなければ価値は出ません。

最初に1枚で次を固定します。

対象部署
対象業務
利用人数
入力する情報の種類
AIに任せる範囲
人が必ず確認する範囲
成功とみなす指標
利用開始時期
予算上限
絶対に許容できない条件

稟議まで進める場合は、生成AI導入の稟議書はどう書く？で、目的・費用・リスク・撤退基準まで一枚にまとめる方法を整理しています。

必須条件と加点条件を分ける

比較表を作る前に、条件を2種類へ分けます。

必須条件

1つでも満たさなければ候補から外す条件です。

例としては次のようなものがあります。

自社が許可する認証方式に対応している
管理者が利用者を停止できる
契約上、入力データの利用条件を確認できる
必要なログを取得できる
指定した地域・条件でデータを扱える
必要なSLAやサポート条件を満たす
契約終了時のデータ削除・返却方法を確認できる

ここは点数制にしません。セキュリティ上絶対に必要な条件を「安いから5点加点」で相殺すると、評価表の意味がなくなるからです。

加点条件

満たすほど業務価値が上がる条件です。

回答品質
操作性
管理画面の使いやすさ
既存システムとの連携
導入支援
日本語サポート
レポート機能
コスト

足切りと順位付けを分けるだけで、比較はかなり整理しやすくなります。

比較表は100点満点より「根拠」を残す

点数は便利ですが、数字だけを残すと後で判断理由が分かりません。

次のように「配点・評価・根拠」をセットにします。

評価領域	配点例	確認すること
業務適合	20	対象業務を本当に短縮・改善できるか
品質・評価	15	正答率、引用、失敗パターン、再現性
セキュリティ・データ	20	認証、権限、暗号化、学習利用、保持、監査
管理・運用	15	利用者管理、ログ、障害対応、変更管理
連携性	10	API、SaaS、ID基盤、データソースとの接続
コスト	10	ライセンス、従量費、開発、運用、人手確認
契約・サポート・退出	10	SLA、問い合わせ、解約、データ返却・削除

これはあくまで一例です。重要なのは、自社の利用目的に合わせて重みを変えることです。

AIエージェントのように外部システムを操作する用途なら、セキュリティ・権限・監査の比重を上げるべきです。詳しくはAIエージェントのセキュリティ設計を参照してください。

ベンダーへ同じ質問をする

候補ごとに営業資料を読むだけでは、比較できません。各社へ同じ質問を送り、回答を同じ表へ入れます。

最低限、次の質問はそろえておくと実務で使いやすくなります。

サービスとモデル

利用できるモデルは何か
モデル変更は誰が、どの頻度で行うか
モデル更新を事前に把握できるか
バージョン固定や段階的な切り替えは可能か
障害時の代替手段はあるか

生成AIでは、契約期間中でもモデルや周辺機能が更新されることがあります。導入時点の精度だけでなく、変更をどう管理するかを確認します。

入力・出力データ

入力データはサービス改善やモデル学習に使われるか
オプトアウト条件は何か
入力・出力・ログはどこに、どれだけ保持されるか
削除要求は可能か
バックアップ上のデータはどう扱われるか
再委託先やサブプロセッサーはどのように管理されるか

「学習に使わない」という一文だけで終わらせず、保存、ログ、バックアップ、サポート時の閲覧可能性まで分けて確認するのがポイントです。

セキュリティと管理

SSOやMFAに対応するか
管理者が利用者・権限を制御できるか
操作ログを取得・エクスポートできるか
管理者権限を分離できるか
インシデント通知の条件と時間はどうなっているか
脆弱性やセキュリティ更新をどう管理しているか

NISTのGenerative AI Profileも、生成AIを単なる精度問題としてではなく、ガバナンス、情報セキュリティ、プライバシー、評価、インシデント対応を含むリスク管理の対象として整理しています。

品質と評価

自社データで評価できるか
参照元や根拠を表示できるか
回答を拒否すべき条件を設定できるか
評価用ログを取得できるか
モデル更新後に再評価できるか

社内検索を導入するなら、モデル単体の性能より、検索・権限・文書更新・引用の設計が重要です。RAGの精度が上がらない原因と改善手順も比較項目づくりに使えます。

デモではなく「同じテストケース」でPoCする

ベンダーのデモは、サービスが得意な条件で作られています。採用判断には、自社の代表ケースと失敗しやすいケースを使います。

たとえば社内規程検索なら、次のように20〜50件ほどの評価セットを作ります。

答えが1文書に明記されている質問
複数文書を照合しないと答えられない質問
古い規程と新しい規程がある質問
権限がない文書に答えてはいけない質問
文書に答えがなく「分からない」と返すべき質問
表やPDFを正しく読めるか確認する質問

各社に同じ入力を行い、次を記録します。

指標	測り方の例
正答率	正しい回答になった件数 ÷ 全評価件数
根拠一致率	正しい出典を示せた件数 ÷ 出典が必要な件数
不回答精度	答えてはいけない質問で適切に止まれたか
修正時間	人が最終成果物へ直すのに必要な時間
応答時間	業務上許容できる速度か
再現性	同条件で結果が大きく揺れないか

生成AIのPoCは「すごい回答が出たか」ではなく、本番で繰り返し使えるかを見るものです。PoCから本番へ進める条件は生成AIのPoCが本番導入で止まる7つの理由で詳しく整理しています。

料金は月額単価ではなく総コストで比較する

生成AIは、ライセンス価格だけで比較すると判断を誤りやすい領域です。

総コストには、少なくとも次を含めます。

初期導入・設定
ライセンス
APIやモデルの従量費
データ整備
RAG・連携開発
ID・権限設定
セキュリティ審査
評価テスト
利用者教育
管理者運用
ログ保管・監視
人による確認
ベンダー変更・移行

安いサービスでも、人による修正や管理作業が毎月増えるなら、総コストは高くなります。

逆に単価が高くても、修正時間や問い合わせ処理が大きく減るなら採算が合う場合があります。

ROIとKPIは、生成AIの費用対効果はどう測る？のように、利用量・時間短縮・品質・コスト・リスクを分けて測ると判断しやすくなります。

契約前に確認する10項目

PoCで勝ったベンダーを、そのまま契約してはいけません。PoCは技術評価、契約は責任と継続条件の確認だからです。

契約書、利用規約、DPA、SLAなどを横断して、少なくとも次を確認します。

利用目的と利用範囲：契約したサービスを何に使えるか
入力・出力データの扱い：保存、学習利用、二次利用の条件
知的財産：入力・出力・追加学習物などの権利関係
秘密保持と個人情報：取り扱い条件、再委託、国外移転等
セキュリティ：要求事項、監査、インシデント通知
サービス水準：稼働率、障害対応、サポート窓口
仕様変更：モデル・機能・価格変更時の通知や対応
責任分担：損害発生時の役割、責任制限、補償条件
終了条件：解約、契約更新、価格改定への対応
退出時のデータ：返却、移行、削除、証跡

経済産業省は2025年に「AIの利用・開発に関する契約チェックリスト」を公開し、生成AIを含むAIサービスの契約で、当事者間の利益とリスクの分配を確認するための観点を整理しています。また、デジタル庁の2026年6月のガイドライン2.0版でも、調達時と契約時のチェックシートを分けています。

契約レビューは最後の押印直前ではなく、比較表を作る段階から法務・セキュリティ・調達を巻き込むほうが手戻りを減らせます。

「撤退できるか」を選定条件に入れる

導入時には見落とされがちですが、重要なのがベンダーロックインです。

サービス終了、値上げ、品質低下、社内方針変更などで切り替えが必要になることがあります。

そのため選定時に次を確認します。

会話・ログ・設定をエクスポートできるか
RAGの元データを標準形式で保持できるか
プロンプトや評価セットを自社で管理できるか
他サービスへ移行するためのAPIや出力形式があるか
契約終了後のデータ削除時期を確認できるか
移行支援の費用と条件はどうなっているか

「導入しやすい」だけでなく、やめやすいことも製品価値の一部として評価します。

RFP・質問票にそのまま使える項目

RFPを大きな資料にする必要はありません。まずは次を1枚の質問票にまとめれば、候補間の比較ができます。

1. 業務要件

対象業務でできること
できないこと・制約
想定利用人数と利用量
必要な応答時間
必要な連携先

2. AI・品質

利用モデル
モデル変更方針
自社評価の方法
根拠表示
ガードレール・不回答制御

3. データ

保存場所
保存期間
学習利用
削除
バックアップ
再委託

4. セキュリティ

認証
権限
暗号化
ログ
インシデント対応
管理者統制

5. 運用

SLA
サポート時間
障害時の連絡
仕様変更通知
管理画面
利用状況レポート

6. 費用

初期費用
固定費
従量費
オプション
導入支援
移行・解約費用

7. 契約・退出

契約期間
更新条件
価格改定
責任分担
データ返却
データ削除

この質問票に「回答」「証拠URL・資料名」「担当者」「確認日」の列を追加すると、そのまま選定記録として残せます。

迷ったらこの順番で3社まで絞る

候補が多いときは、いきなり10社でPoCをしないほうが効率的です。

まず書面で必須条件を確認し、3社程度まで絞ります。その後、同じ評価セットでPoCを行います。

実務上の流れは次のようになります。

業務課題を1つに絞る
必須条件を決める
5〜10社へ同じ質問票を送る
必須条件で足切りする
2〜3社でPoCする
品質・運用負荷・総コストを採点する
契約条件をレビューする
最終候補の稟議を上げる
導入後30〜90日で再評価する

利用ルールが未整備なら、契約前に生成AIの社内ルールの作り方も合わせて整理しておくと、導入後に「何を入力してよいか分からない」という状態を減らせます。

選定会議で最後に確認する5つの質問

最後の会議では、サービスの魅力を説明するのではなく、次の5問に答えられるか確認します。

このベンダーでなければ解けない業務課題は何か
PoCで改善した数字は何か
最も大きな残存リスクは何か
1年間の総コストはいくらか
期待を下回ったとき、いつ・どうやって止めるか

この5つに答えられないなら、選定はまだ終わっていません。

生成AIベンダー選定で重要なのは、「一番高性能なAI」を当てることではなく、自社の業務価値、リスク、コスト、運用、契約を同じ物差しで比較し、導入後も見直せる状態を作ることです。

モデルや製品は変わります。だからこそ、製品名ではなく評価方法を資産として残すことが、次の選定にも効いてきます。