AI ベンダーは数が多く、デモはどれも魔法のように見えます。けれど契約してから「自社のデータでは精度が出ない」「請求が読めない」「乗り換えられない」と気づくと、戻すのは大変です。この記事は、初めて AI ベンダーを選ぶ人がデモの印象ではなく事実で選ぶための基準と、よくある落とし穴を、図とともに整理します。
FIG.1 モデルが同じでも、入力データの質が違えば結果は別物になる
大事な前提をひとつ。「どのベンダーが一番賢いか」より「自社の課題と自社のデータで成果が出るか」のほうが、はるかに結果を左右します。だから比較は、ベンダーのスライドではなく、あなたのデータで行うのが原則です。
01選ぶ前に「評価指標」を決める
最初にやりがちな失敗が、指標を決める前にデモを見てしまうことです。魅力的な画面を見たあとでは、判断が「印象」に引っ張られます。順番を逆にしましょう。解きたい課題と、合格ラインの数字を先に紙に書く。これだけで比較がぶれなくなります。
課題を1つに絞る
「問い合わせ一次対応の自動化」「契約書レビューの下読み」など、業務を具体的に1つ決める。範囲を広げすぎると評価できない。
合格ラインを数字で書く
例：正答率80%以上、1件あたり処理コスト◯円以下、応答3秒以内。あいまいな「賢ければOK」では比較できない。
評価用の問題集を作る
自社の実データから30〜100問の想定質問と正解を用意。これが全ベンダー共通の“ものさし”になる。
この問題集は、契約後の運用でも品質を測り続ける資産になります。最初に作る手間を惜しまないのがコツです。
02評価すべき7つの軸
指標が決まったら、各ベンダーを同じ観点で並べます。次の7軸が実務での定番です。値はベンダーのうたい文句ではなく、契約書・公式ドキュメント・自社PoCで裏を取ります。
1. 精度の実証
自社データでのPoC結果で判断。ベンダー提供の好例（チェリーピック）だけで決めない。
2. データの扱い
入力が学習に使われないか、どこに・どれだけ保存されるか。契約条項で確認（詳細は次章）。
3. セキュリティ認証
SOC 2 Type II、ISO 27001、医療なら HIPAA とBAA。有効期限内の報告書を出せるか。
4. 運用サポート
障害時のSLA（復旧目標）、問い合わせ窓口、日本語対応や時差の体制。
5. 価格体系
従量課金の上振れリスク、最低利用料、隠れた追加費（後述）。
6. ロックイン
移行のしやすさ、データのエクスポート可否、独自仕様への依存度。
7. 事業継続性
提供元の財務・継続性。小規模スタートアップ単独依存のリスクを見積もる。
03データの扱い：契約で確認すべきこと
ここは誤解が多い場所です。2026年時点で、主要な法人向けAPI（OpenAI・Anthropic・Azure OpenAI など）は、入力データを既定でモデルの再学習に使いません。「APIに送ると勝手に学習される」というのは、少なくとも法人プランでは正確ではありません。ただし安心して任せきりにせず、次の3点は自分で公式ドキュメントと契約（DPA）で確認します。
- 再学習への不使用：法人APIは既定で非学習。一方、無料の一般向けチャットは扱いが異なることがある（業務データを貼らない運用が無難）。
- 保存期間：不正監視のため一定期間（例：最大30日程度）保持→削除、という運用が一般的。期間と削除条件を確認する。
- ゼロデータ保持（ZDR）：機微なデータでは「処理後に残さない」ZDR を選べる場合がある。ただし対象プラン・申請の要否は提供元で異なるため、必ず契約・公式手続きで裏を取る。
「学習に使われない」を口頭ではなく契約条項（DPA）で確認できるか——これが法人利用の分かれ目。
FIG.2 保持期間とZDRの違い。どの扱いになるかは契約・プランで確認する
04同じ条件で2〜3社をPoC比較する
カタログスペックより、自社データでの実測が最も雄弁です。候補を2〜3社に絞り、第02章で作った問題集を全社に同条件で通します。表のように軸ごとに並べると、得意・不得意がはっきりします。
| ベンダーのデモで見えるもの | 自社PoCで初めて見えるもの |
|---|---|
| 整ったサンプルでの高い正答率 | 表記ゆれ・欠損・スキャンPDFでの精度低下 |
| 魅力的なUIと滑らかな応答 | 自社の専門用語・社内ルールへの弱さ |
| 「だいたい何でもできます」 | どこが自動で、どこは人手が要るかの線引き |
| 提示された月額イメージ | 実際の利用量から見積もる現実的なコスト |
PoCは「動くか」だけでなく、合格ラインの数字に届くかで判定します。同じ問題集・同じ評価者で比べることが、公平な比較の条件です。
05よくある落とし穴
失敗事例には共通のパターンがあります。先に知っておけば、契約前に確認質問へ変えられます。
デモ環境の幻想
きれいなデータでは動くのに、現場データで精度が激減。→ 必ず自社の生データでPoCする。
隠れコスト
API従量課金の上振れ、追加ライセンス、初期構築・カスタマイズ費、データ移行費。→ 想定利用量で年額を試算し、上限超過時の挙動を確認。
「AIでできます」の曖昧さ
何が完全自動で、何が人手の確認前提かが不明確。→ 役割分担を仕様として書面化させる。
ロックインの軽視
独自フォーマットや独自オーケストレーションに深く依存し、乗り換え費用が膨らむ。→ 次章の対策を契約前に設計する。
06ロックインを避ける設計
2026年の実務では、AIのロックインは「データを出せるか」だけの問題ではありません。業務フローやエージェントの作り込みが特定ベンダー前提になるほど、乗り換え費用は足し算ではなく掛け算で膨らみます。対策の定番が抽象化レイヤです。自社側に「やりたいこと」を表す共通の窓口を置き、その奥でベンダーのAPIを差し替えられるようにします。乗り換えるときは“配線”を替えるだけで、業務側のインターフェースは変えずに済みます。
FIG.3 業務アプリは窓口だけを見る。差し替えは抽象化レイヤの奥で行う
- データを定期的にエクスポートできるかを契約で確認（形式・頻度・解約後の扱い）。
- 業務ロジックとモデル呼び出しを分離しておく（モデルは交換可能な部品として扱う）。
- 用途によっては複数ベンダーの併用も選択肢。1社に全部を寄せない。
Security & Compliance
セキュリティ認証は「入口の鍵」
2026年の法人調達では、有効期限内の SOC 2 Type II 報告書が事実上の入口になっています。これが出せないベンダーは、そもそも検討の土俵に上がりにくい、という感覚です。加えて、欧州にデータが関わるなら GDPR 対応、医療データなら HIPAA とBAA、基礎要件として ISO 27001 が求められる場面が増えています。
FIG.4 必須認証で先にふるいにかけ、残った候補だけをPoCに進める
「監査証跡が引けるか」「操作ごとに権限を制御できるか」も、調達の確認項目として一般的になりました。認証は万能ではありませんが、最低限の信頼をそろえる入口として先に確認するのが効率的です。
07選定プロセスの型
ここまでを1本の流れにすると、迷いにくくなります。指標を決める前にデモを見ないのが最大のコツです。
課題と評価指標を定義
解きたい業務と合格ラインの数字、評価用の問題集を先に用意する。
認証で一次ふるい
SOC 2 Type II など必須要件を満たすベンダーに候補を絞る。
2〜3社で同条件PoC
自社データで精度・コスト・運用負荷を実測し、合格ラインと突き合わせる。
契約条項を法務確認
データ扱い（DPA・保持・ZDR）、解約とエクスポート、SLA、価格上限を書面で詰める。
08AI を選定そのものに使う
提案書や契約書のチェックは、AI に下読みさせると見落としが減ります。たとえば次のように頼みます。
プロンプト例
この提案書を「データの取り扱い（学習利用の有無・保存期間・ZDRの可否）」「総コスト（従量の上振れ・追加費・解約費）」「ロックイン（エクスポート可否・独自依存）」の3観点で読み、確認すべき不明点を箇条書きにしてください。
ただし、AI の回答は提案書の読み落としや事実誤認（ハルシネーション）を含むことがあります。最終判断は必ず原文と一次情報で裏取りし、料金や法的条件は公式ドキュメント・法務確認を優先します。AI は「論点を漏れなく洗い出す相棒」であって、決裁者ではありません。
09まとめ
AI ベンダー選びは、賢さ比べではなく相性確認です。指標を先に決め、認証で入口を絞り、自社データで同条件PoCし、データ扱い・コスト・ロックインを契約で詰める——この型を守るだけで、デモの印象に流される失敗は大きく減ります。まずは課題を1つ選び、評価用の問題集を作るところから始めましょう。次章では、外注せず内製する場合の損益分岐を扱います。
