AIベンダー選定チェックリスト｜PoCで失敗しない評価項目・契約確認・判断基準

AIベンダーのPoC（試験導入）は、「デモで便利そうだったか」を見る場ではありません。情シスが確認すべきなのは、本番導入後に安全に運用できるか、社内で説明できるか、契約終了時まで管理できるかです。社内文書検索、問い合わせ回答、議事録要約、FAQ生成、業務エージェントのような用途では、回答精度だけで判断すると失敗します。PoCではよく動いたのに、本番では権限管理が合わない、ログが取れない、月額費用が想定より上がる、誤回答時の修正責任が曖昧になる、といった問題が起こりやすいためです。

私自身、ここで一度ヒヤッとしています。問い合わせ履歴や申請データをAIで分類・要約しようとしたPoCで、ベンダーのデモはきれいに動いたのに、自社の実データを入れた途端に精度が落ちました。この記事は、そのとき何が起きたのかと、以降PoCで必ず確認するようにしたことを、情シス・セキュリティ・法務・業務部門で共有しやすい形に整理したものです。

まず決めるべきは「PoCの合格条件」

PoCを始める前に最初に決めるべきなのは、評価項目ではなく、本番導入に進める条件です。ここが曖昧なまま複数ベンダーを比較すると、画面の見やすさ、営業担当の説明、デモの印象に判断が引っ張られます。合格条件は次の3段階で分けると実務で使いやすくなります。

ここで重要なのは、「回答精度が高いから本番候補」ではないことです。個人情報や顧客情報を扱うなら、アクセス制御、監査ログ、データ削除、委託先管理、インシデント時の通知、契約終了時のデータ返却まで確認して初めて本番候補になります。

評価軸は6つに分ける

AIベンダー選定の評価軸は、機能だけでなく、業務効果、セキュリティ、契約、運用、費用に分けます。各項目には「必須」「加点」「要確認」を付けます。

総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」では、AIの開発・提供・利用に関わる事業者を、AI開発者、AI提供者、AI利用者に分けて整理しています。自社が外部AIサービスを使う場合でも、単なる利用者として終わるのではなく、業務で使うデータ、利用者への影響、正常稼働の継続について自社側の役割を持つ点を意識する必要があります。

PoCで一番見るべきなのは、AIの精度ではなく「自社データの汚れ」

PoCで一番印象に残っているのは、問い合わせ履歴や申請データをAIで分類・要約しようとしたときです。ベンダーのデモでは「問い合わせ内容を入れると自動でカテゴリ分けされます」「過去の対応履歴からよくある質問を抽出できます」「申請内容を要約して担当部署ごとに振り分けられます」という説明で、画面上は本当にそれっぽく動いていました。ところが自社の実データを少し入れてみると、急に精度が落ちました。原因はAIというより、こちらのデータの汚れでした。

たとえば同じ部署でも、古い組織名と新しい組織名が混ざっていました。「〇〇製造所」と書かれているものもあれば「製造統括本部」と書かれているものもあり、人によっては略称で書く。過去の申請データには旧名称のまま残っている。人間なら「ああ、同じ系統の部署のことね」と文脈で読めますが、AIや分類ロジックに食わせると、別物として扱われたり、逆に変にまとめられたりしました。会社名や取引先名も同じで、「株式会社〇〇」「(株)〇〇」「㈱〇〇」「〇〇様」「〇〇社」と表記がばらばら。半角カナ、全角カナ、スペースの有無も混ざり、メールから貼り付けた文章は改行位置も人によって違います。

地味に効いたのがメモ欄です。業務システムのメモ欄は思っている以上に自由で、「確認済」「後日対応」「〇〇さんに確認」「たぶん不要」「前回と同じ」のような、人間には何となく伝わるけれどAIには判断材料として弱い文章がたくさん入っています。さらに困ったのが、古い版と新しい版の混在でした。過去の申請では任意だった項目が途中から必須になっている、選択肢の名称が変わっている、昔は自由入力だったものが今はマスタ選択になっている。そういう履歴が残っているので、AIにまとめさせると判断の軸がぶれました。

そのとき思ったのは、「PoCはAIの精度を見る場でもあるけれど、実は自社データの汚れを見る場でもある」ということです。SQL Serverを触っていると、本番データはきれいな前提で見ないほうがいいと感じます。NULL、空文字、0、古いコード、使われなくなった区分、重複、手入力の揺れ、途中から変わった運用。そういうものが必ずあります。だからAIツールのPoCでは、ベンダーのサンプルでうまくいくかよりも、自社の実データを入れたときにどこで崩れるかを見たほうがいい。むしろ最初から少し汚いデータを入れたほうが、現実的な評価になります。一番ヒヤッとしたのは、AIが外したことではなく、自社のデータが思っていた以上に人間の勘と運用で支えられていたと気づいた瞬間でした。

この経験以降、PoCでは次を必ず確認するようにしました。表記ゆれはどれくらいあるか、旧組織名や旧コードが残っていないか、同じ意味のデータが別項目に分かれていないか、自由入力欄に重要情報が埋まっていないか、空欄や「0」や「未設定」をAIがどう扱うか、途中で運用が変わった時期のデータを混ぜても破綻しないか。PoCではベンダーが用意した成功例だけを試してはいけません。本番に近い失敗条件を入れて、そのAIが「どこまで答えられるか」だけでなく、答えてはいけない場面で止まれるかを確認します。

社内文書検索AIのテスト例

最新版と旧版の規程が混在している状態で最新版に基づいて回答できるか、部署・雇用形態・拠点によってルールが異なる質問に対応できるか、根拠文書がない質問に推測で答えず確認依頼を返せるか、閲覧権限のない文書を参照しないか、参照元URL・文書名・更新日を回答に表示できるか。

問い合わせ回答AIのテスト例

FAQにある典型質問へ正しく回答できるか、FAQにない質問を勝手に補完せずエスカレーションできるか、曖昧な依頼に確認質問を返せるか、担当者の修正時間を含めても業務時間が削減されるか、誤回答が見つかったとき管理者がナレッジやプロンプトを修正できるか。

PoC記録ひな型

テストID：
業務シナリオ：
入力データの種類：
期待する回答：
実際の回答：
参照元の有無：
権限違反の有無：
人手修正にかかった時間：
判定：合格／条件付き／不合格
未確認事項：

セキュリティと契約はPoC前に確認する

セキュリティや契約条件は、PoC後ではなくPoC前に確認します。評価結果が良くても、データ保存、学習利用、監査ログ、再委託、削除方法が自社基準に合わなければ、本番導入は止まります。

ここで一度、痛い思いをしています。口頭説明の印象だけで「このツールはログが取れそう」と思っていたものが、後で確認すると画面上で利用状況を見られるだけで、CSVエクスポートや監査用の履歴出力まではできませんでした。ベンダーが嘘をついていたというより、こちらが聞きたい”ログ”と、ベンダーが説明している”利用状況の確認”が微妙に違っていたのだと思います。だから営業資料の言葉ではなく、ログサンプルや管理画面の実物で確認するようにしています。

個人データの取扱いを外部に委託する場合、個人情報保護委員会のガイドラインでは、委託先の選定、委託契約の締結、委託先における取扱状況の把握などが示されています。AIベンダー選定でも、営業資料だけでなく、契約書や運用実態で確認する必要があります。

また、個人情報保護委員会は、漏えい等報告について、速報は発覚日から3〜5日以内、確報は原則30日以内、不正な目的で行われたおそれがある場合は60日以内と案内しています。AIベンダーの契約では、自社が必要な判断と報告を行えるよう、ベンダーからの事故連絡期限を短く設定できるか確認します。

費用は「月額」ではなく「本番運用総額」で見る

AIサービスの費用は、月額ライセンスだけでは比較できません。社内検索AIなら、利用者数、文書量、更新頻度、検索回数、回答生成回数、ログ保存量、再インデックスの頻度が費用に影響します。問い合わせ回答AIなら、月間問い合わせ件数、添付ファイルの有無、評価データ作成、回答改善の回数も見積対象です。費用比較では、PoCと同じ小規模利用の場合、本番初年度に想定する通常利用の場合、利用者数・文書量・問い合わせ件数が増えた場合の3パターンの見積を必ず依頼します。

見積依頼ひな型

利用者数：PoC参加者数、本番初年度の想定利用者数、将来的な全社展開時の利用者数を分けて記載する。
月間利用回数：検索回数、回答生成回数、問い合わせ件数、API利用回数など、課金に影響する利用量を記載する。
対象データ量：登録する文書数、ファイル容量、更新頻度、再インデックスの想定回数を記載する。
必要ログ保持期間：社内規程、監査対応、事故調査に必要な期間をもとに、ログを何か月または何年保持したいかを記載する。
必要サポート時間：平日日中のみでよいか、休日・夜間対応が必要か、問い合わせ窓口と初動時間を確認する。
上振れ条件：ユーザー増、API利用増、ストレージ増、追加開発、保守追加の単価を明記してもらう。

この時点で費用上限を説明できない場合は、本番導入後に利用が広がったときの追加費用を予測できません。見積時点で「通常利用」と「増加時」の両方を確認しておくことが重要です。

PoC中に見るべき運用・保守体制

PoC中はベンダー担当者が手厚く支援してくれることがあります。しかし本番後も同じ体制とは限りません。PoCの段階で、本番運用の担当範囲を確認します。

比較は「印象戦」にしない。プリザンターの台帳に時点ごとで残す

複数のAIベンダーやツールを比較するとき、メールや記憶だけで管理するのはやめました。理由は単純で、後から本当に分からなくなるからです。最初はベンダー説明を聞いた後にメールでメモを残したり、打ち合わせ資料をフォルダに置いたりしていました。でも2社、3社と比較していくと記憶が混ざってきます。「あの管理者ログを出せると言っていたのはA社だったかB社だったか」「ファイルアップロードを制限できるのはどっちのプランだったか」「無料版ではだめだけど法人版ならできるという話はどのツールだったか」。こういうことが普通に起きました。

AIツールはどの製品もデモ画面ではそれなりに便利に見えます。要約できます、検索できます、議事録を作れます、社内文書を参照できます、という説明だけ聞くとどれも似ています。でも情シスとして本当に見たいのは、SSOが使えるか、退職者を止められるか、ログを出せるか、入力データを学習に使わない設定があるか、ファイルアップロードを制御できるか、監査時に説明できるか。こういう地味な差は、メールの文章だけだと埋もれやすいです。

そこで比較項目はプリザンターの台帳に残すことにしました。一覧で比較でき、項目をそろえられ、後から更新履歴も追いやすいからです。メールだと誰かの受信箱の中に情報が散らばりますし、Excelでも最新版がどれか分からなくなったり、誰かがローカルで持っていたりします。プリザンターなら評価中のツールを1件1レコードで残せて、関係者が同じ画面を見ながら確認できます。これが実際に運用しているベンダー比較の台帳です（社名等はマスキング済み）。

更新は開始時・中間・終了時の3回に分けています。開始時には、そもそもの期待値を残します。何を解決したくてPoCを始めるのか、対象業務は何か、使うデータは何か、最初にベンダーから聞いている前提は何か。この時点を残しておかないと、終了時に「思っていたのと違う」となっても、何を期待していたのか分からなくなります。中間時には、実際に使って出てきた違和感を残します。デモでは良かったが自社データでは精度が落ちた、ログ出力が思ったより弱かった、現場が使い方で迷った、ファイルアップロードや権限設定で制約が見えた。終了時には、最終判断の理由を残します。導入するのか、見送るのか、継続検証するのか。見送るなら、価格なのか、精度なのか、ログなのか、権限管理なのか、セキュリティ条件なのか。

台帳化してよかったのは、「なぜ見送ったか」が残ることです。AIツールは新しいものが次々出てくるので、現場からすると「前に見たあのツール、結局どうなったんでしたっけ」となりやすい。そのとき記憶ではなく台帳を見れば、当時の判断理由を説明できます。特にありがたかったのは、PoC開始時の期待と終了時の評価を並べて見られることでした。最初は「問い合わせ要約ができれば十分」と思っていたのに、途中で「顧客情報のマスキングが必要」「ログが出ないと困る」「退職者管理ができないと業務利用は難しい」と論点が増えていくことがあります。これを記録しておくと、単に「このAIは使えなかった」ではなく、「機能は良かったがログ面で見送り」「精度は十分だが権限管理に課題」「デモは良かったが自社データの表記ゆれに弱かった」という形で、次の判断材料になります。結局、台帳化した理由は、ベンダー比較を”印象戦”にしないためです。

本番導入へ進める判断フロー

PoC後は、最高点のベンダーを選ぶのではなく、次の順番で本番導入可否を判断します。必須条件を満たしていない項目がないか確認する、未確認事項が契約前に解消できるか確認する、本番費用が通常利用と増加時の両方で許容範囲か確認する、障害・誤回答・漏えい等のおそれがある場合の責任分界を確認する、PoCで作ったプロンプト・設定・評価データ・ナレッジを本番へ引き継げるか確認する、自社側の運用オーナー・情シス担当・業務部門担当を決める。

次のいずれかに該当する場合は、追加PoCよりも先に条件整理を行います。監査ログが取得できるか不明、自社データの学習利用の扱いが契約上明確でない、PoC環境と本番環境で保存期間や管理機能が異なる、本番後のサポート範囲がPoC中と異なる、利用量増加時の費用上限が説明できない。対象データや運用責任者が決まっていない場合は、本番候補ではなく条件付き候補として扱い、契約前に確認事項を解消します。

本番判断メモひな型

候補ベンダー：
利用目的：
対象データ：公開情報、社内一般情報、機密情報、個人情報、顧客情報のどれを扱うかを分類する。
本番開始範囲：
合格した必須条件：
残る未確認事項：
契約前に解消すべき条件：
本番後の運用責任者：業務部門の利用責任者、情シスの管理担当、アカウント管理者、問い合わせ窓口を決める。
最終判断：本番候補／条件付き候補／見送り

まとめ：PoCの目的は「成功デモ」ではなく「導入判断」

AIベンダー選定のPoCは、AIが動くことを確認する場ではありません。本番で安全に、継続的に、説明可能な形で使えるかを判断する場です。そのためには、PoC前に合格条件を決め、PoC中は成功例だけでなく失敗条件と自社の汚れた実データを試し、PoC後は機能・セキュリティ・契約・運用・費用を同じ表で比較します。そして比較を記憶や印象で終わらせず、同じ項目・同じ場所・時点ごとに残す。判断に迷う場合は、追加PoCを増やすよりも、未確認事項を「誰が、いつ、どの証跡で確認するか」まで落とし込むことが重要です。