AI統合ベンダーを選定する方法：提案依頼書を送る前に確認すべきポイント

既存システムにAIを統合するプロジェクトでは、ベンダー選定の前段階でどれだけ準備できているかが、提案内容の質とプロジェクト成功率を大きく左右します。AIチャットボット、社内ナレッジ検索、問い合わせ回答支援、営業文書生成、データ分類、業務自動化、RAG、画像解析など、AI統合のテーマは多岐にわたりますが、自社側の目的、対象業務、利用データ、既存システム、セキュリティ制約、品質基準が曖昧なまま提案依頼書を送ると、各ベンダーが異なる前提で提案を作ってしまい、価格もスケジュールも技術構成も比較しにくくなります。その結果、PoCでは動いたものの本番導入で止まる、データ管理や権限管理が後から問題になる、運用保守の費用が想定以上に増えるといった課題が発生しやすくなります。

AIベンダー選定では、単に「AIに詳しい会社か」「デモがきれいか」「価格が安いか」だけで判断するのは危険です。AI統合は、モデルやプロンプトだけでなく、既存システム連携、API設計、データ品質、セキュリティ、ログ管理、評価設計、運用保守、社内ガバナンス、契約条件まで含むシステム統合プロジェクトです。NISTのAI Risk Management Frameworkは、AIに関連するリスクを個人、組織、社会の観点から管理する枠組みとして示されており、AI導入では技術だけでなくリスク管理をライフサイクル全体で扱う姿勢が重要になります。ISO/IEC 42001も、AIマネジメントシステムの国際規格として、AIに関するリスクと機会を継続的に管理する考え方を示しています。ベンダー選定でも、こうしたAIガバナンスの視点を確認項目に含めることが重要です。

1. AI統合の目的を明確にする

AI統合ベンダーに提案を依頼する前に、まず自社がAIで何を実現したいのかを明確にする必要があります。「AIを導入したい」「生成AIを活用したい」という表現だけでは、ベンダー側は幅広い解釈をしてしまい、チャットボット、検索、文書生成、分析、自動化など、まったく異なる提案が出てくる可能性があります。目的が曖昧なまま提案を比較すると、各社の前提が違うため、価格差やスケジュール差が妥当なのか判断できません。RFPを送る前には、AIによって解決したい業務課題、利用者、期待する成果、初期導入の範囲、将来的な拡張範囲を整理しておく必要があります。

1.1 解決したい業務課題を定義する

AI統合の目的は、AIという技術を導入することではなく、既存業務の中にある具体的な課題を解決することです。たとえば、問い合わせ対応時間が長い、社内ナレッジ検索で必要な情報にたどり着けない、営業担当者ごとに提案文書の品質がばらつく、商品データや顧客データの分類に時間がかかる、入力ミスや表記ゆれによって分析精度が下がっているなど、AIを入れる前に業務上の痛点を具体化する必要があります。課題が具体的であれば、ベンダーが提案するAI機能が本当に課題解決に結びついているかを判断しやすくなります。

業務課題を定義する際には、現場の声だけでなく、数値データも確認します。問い合わせ対応なら平均対応時間、一次解決率、FAQ参照率、エスカレーション率を確認し、社内検索なら検索成功率、再検索率、問い合わせ先への確認件数を見ます。営業支援なら資料作成時間や文面修正回数、データ品質改善なら重複率、欠損率、分類ミス率を確認します。こうした現状値があると、PoC後にAI導入効果を判断しやすくなり、ベンダーにも具体的な改善目標を伝えられます。

1.2 AIで解決すべき範囲を絞る

AIは多くの業務に応用できますが、初期段階から広い範囲を対象にすると、データ準備、評価、セキュリティ確認、運用設計の負荷が大きくなります。問い合わせ対応を例にすると、すべての問い合わせをAIで処理するのではなく、まずはFAQで回答できる定型質問、ログイン関連、料金プラン、操作手順、配送状況など、回答ルールが明確でリスクの低い領域から始める方が現実的です。対象範囲を絞ることで、評価データを作りやすくなり、AIの品質を判断しやすくなります。

RFP前には、初期導入で扱う範囲と、将来的に拡張したい範囲を分けて整理します。初期導入では社内担当者向けの回答候補提示に限定し、将来的には顧客向けチャット、チケット自動分類、CRM連携、FAQ改善提案へ広げるといった段階設計が考えられます。このように段階を分けておくと、ベンダーにもロードマップ型の提案を求めやすくなります。

1.3 自動化レベルを決める

AI統合では、AIが単に候補を提示するだけなのか、人間が確認して反映するのか、一定条件では自動処理するのかを決める必要があります。たとえば、社内文書の要約であればAI出力をそのまま参考にしても問題が少ない場合がありますが、顧客への返信、契約条件、請求情報、個人情報変更、返金判断などに関わる場合は、AIの自動処理には大きなリスクがあります。自動化レベルを決めずに提案依頼を出すと、ベンダーごとにリスク前提が異なり、提案の比較が難しくなります。

初期導入では、AIが回答案や分類候補を出し、人間が確認して確定する「支援型」の設計が安全です。その後、採用率や誤回答率を測定し、十分に品質が確認できた領域だけ自動化レベルを上げる方法が現実的です。RFPには、自動化したい処理と人間確認を残したい処理を分けて記載し、ベンダーに承認フローやエスカレーション条件も含めた提案を求めるべきです。

1.4 成功指標を設定する

AI統合の成功は、機能が完成したかどうかではなく、業務上の成果が出たかどうかで判断する必要があります。問い合わせ対応なら、平均一次回答時間、自己解決率、AI回答案の採用率、手動修正率、顧客満足度、エスカレーション率が指標になります。社内検索なら、検索成功率、再検索率、問い合わせ件数の削減、文書参照時間の短縮が考えられます。文書生成なら、作成時間、修正回数、承認までの時間、出力の採用率を見ることができます。

成功指標を決めておけば、PoC後に「良さそうだった」という感覚ではなく、継続すべきか、本番化すべきか、改善すべきかを判断できます。ベンダーにも、PoCでどの指標をどう測るのかを提案してもらうことが重要です。AI評価は通常のシステムテストとは異なり、出力品質、業務適合性、安全性を測る必要があるため、評価指標をRFPに含めることで、より実務的な提案を受けやすくなります。

1.5 対象外業務を明記する

AI統合プロジェクトでは、関係者から追加要望が出やすくなります。社内検索もしたい、問い合わせ回答もしたい、営業メールも作りたい、データ補正もしたいというように、AIへの期待が広がるほどスコープが膨らみます。スコープが広がりすぎると、評価対象が増え、リスク確認も複雑になり、費用とスケジュールが読みにくくなります。そのため、RFP前に今回の対象外範囲を明記しておくことが重要です。

たとえば、初期フェーズでは顧客への自動送信はしない、契約判断はしない、請求金額の変更はしない、個人情報の自動補完はしない、基幹DBへの自動書き込みはしないといった制限を設けることができます。対象外を明記することは、消極的な対応ではなく、プロジェクトを現実的に進めるための品質管理です。ベンダーにも、対象外領域を尊重したうえで、将来拡張する場合の条件や追加設計を提案してもらうとよいです。

1.6 経営目的と現場目的を接続する

AI導入では、経営層はコスト削減、業務効率化、競争力向上を期待する一方で、現場担当者は使いやすさ、誤回答リスク、業務負担、確認作業の増加を気にします。経営目的と現場目的が接続されていないと、導入後に「経営層は効果が出ると思っていたが、現場では使われない」という状態になりやすくなります。AI統合ベンダーを選ぶ前に、経営視点と現場視点の両方を整理しておく必要があります。

RFPには、経営上の狙いだけでなく、現場で実際にどの作業を楽にしたいのか、どの画面でAIを使いたいのか、どの業務フローを変えたくないのかも記載します。良いベンダーは、経営効果と現場定着の両方を考えて提案します。単にAI機能を並べるだけではなく、現場で使われる導線、承認フロー、教育、運用改善まで提案できるかを確認することが重要です。

2. 現行システムと連携範囲を整理する

AI統合ベンダーを選ぶ際には、AI単体の開発力だけでなく、既存システムと安全に連携できるかを確認する必要があります。多くのAI統合プロジェクトでは、CRM、CMS、ERP、DWH、社内ポータル、チケットシステム、チャットツール、ID管理、ファイルサーバーなど複数の既存システムが関係します。AIがどのデータを読み、どの画面に出力し、どのシステムへ書き戻すのかを整理しないままRFPを送ると、ベンダーごとに連携前提がずれてしまいます。

2.1 連携対象システムを一覧化する

RFP前には、AIモジュールが接続する可能性のある既存システムを一覧化します。システム名、管理部門、利用目的、APIの有無、データ形式、認証方式、更新頻度、外部接続可否、個人情報の有無、機密情報の有無を整理しておくと、ベンダーは正確な技術構成と見積もりを出しやすくなります。たとえば、CRMから顧客情報を取得し、チケットシステムから問い合わせ履歴を取得し、CMSからFAQを取得し、AIが回答候補を作る構成では、各システムの制約を事前に把握する必要があります。

連携対象が曖昧なままだと、PoCではCSVや手動アップロードで簡単に動かし、本番化の段階でAPI連携、権限管理、ログ保存、データ更新の問題が発覚することがあります。RFPでは、連携対象システムの一覧を提示し、ベンダーに「初期フェーズで接続するもの」「将来接続するもの」「接続しないもの」を分けて提案してもらうと、スコープと費用を管理しやすくなります。

2.2 API連携の可否を確認する

AI統合では、既存システムにAPIがあるかどうかが大きな分岐点になります。APIが整備されていれば、AIモジュールから必要なデータを取得し、ユーザー権限に応じた表示制御やログ管理を実装しやすくなります。一方で、APIがない場合は、CSV連携、DB参照、RPA、手動アップロード、別途API開発などが必要になり、工数や運用負荷が増えます。ベンダーに提案を依頼する前に、現行システムのAPI仕様書、認証方式、レート制限、エラー仕様を確認しておくことが重要です。

ベンダーには、単に「API連携できます」と言えるかどうかだけでなく、API設計、認証、権限、エラー処理、タイムアウト、再試行、ログ保存、監視まで含めて対応できるかを確認します。AI統合では、AIモデルの精度よりも、既存APIの制約やデータ取得方法が品質に影響することがあります。特に、リアルタイム回答や顧客対応にAIを使う場合は、APIの応答速度と安定性も重要な確認項目です。

2.3 データ取得とデータ更新を分ける

AI統合では、AIが既存システムからデータを読むだけなのか、AI出力を既存システムへ書き戻すのかを明確に分ける必要があります。読み取りだけであれば、比較的リスクを抑えやすく、PoCにも向いています。しかし、AIが分類結果をCRMへ反映する、問い合わせステータスを更新する、FAQを自動生成してCMSへ登録する、顧客データを補正するなど、書き戻しを行う場合は、承認フロー、差分確認、監査ログ、ロールバックが必要になります。

RFP前には、初期フェーズで書き戻しを行うかどうかを決めます。多くの場合、まずはAIが候補を提示し、人間が確認して反映する形にした方が安全です。ベンダーには、将来的に自動反映へ進める場合の条件、必要な評価基準、承認プロセス、データ変更ログの設計も提案してもらうとよいです。AI出力を本番データに反映する設計は、単なる機能追加ではなく、データガバナンスの問題として扱う必要があります。

2.4 認証・権限との連携を確認する

AI機能が社内データや顧客データを参照する場合、既存の認証・権限管理と連動していることが必須です。ユーザーが本来見られない文書や顧客情報を、AI経由で取得できてしまう状態は重大な情報漏えいリスクになります。たとえば、営業担当者が自分の担当顧客だけを閲覧できるルールがある場合、AIもその範囲内のデータだけを参照しなければなりません。

ベンダーには、SSO、ID管理、RBAC、部署別権限、顧客担当者権限、文書アクセス権限をどのようにAI機能に反映するかを確認します。AI統合では、AIが便利な横断検索を提供する一方で、権限制御が甘くなる危険があります。RFPには、既存権限を維持すること、AIが権限を迂回しないこと、参照ログを残すことを条件として明記するべきです。

2.5 既存インフラの制約を整理する

企業によっては、クラウド利用制限、オンプレミス環境、VPN、閉域網、特定リージョン要件、外部API利用制限、データ持ち出し禁止、監査要件などの制約があります。AI統合では、こうしたインフラ制約が技術構成に大きく影響します。外部AI APIを利用できるのか、社内環境にAI基盤を構築する必要があるのか、ログをどこに保存できるのか、データを海外リージョンへ送信できるのかを事前に整理する必要があります。

ベンダーに提案を依頼する際には、自社のインフラ制約を隠さず提示した方がよいです。制約を後出しにすると、提案の前提が崩れ、設計変更や追加費用が発生します。特に、金融、医療、公共、製造業の一部では、データ保管場所や接続方式に厳しい制約があるため、ベンダーのクラウド前提の提案がそのまま使えないことがあります。

2.6 既存運用への影響を確認する

AI機能を追加すると、既存の業務フローや運用手順が変わる可能性があります。たとえば、問い合わせ対応では、担当者がAIの回答候補を確認する時間が増える一方で、検索時間は短縮されるかもしれません。FAQ運用では、AIが参照するナレッジの更新頻度が上がり、データオーナーの承認作業が増える可能性があります。AI統合は、システム連携だけでなく運用連携として考える必要があります。

RFP前には、AI導入によって影響を受ける部門と作業を洗い出します。ベンダーには、開発だけでなく、運用設計、マニュアル作成、現場教育、品質レビュー、改善会議まで支援できるかを確認します。AI機能が技術的に優れていても、既存運用に自然に組み込まれなければ、現場で使われないシステムになってしまいます。

3. ベンダーのAI開発実績を確認する

AI統合ベンダーを選定する際には、一般的なWeb開発や業務システム開発の実績だけでなく、AIモジュール、LLMアプリケーション、RAG、AI評価、本番運用の実績を確認する必要があります。AIデモを作ることと、実際の業務システムに組み込んで安定運用することは別です。特に、PoC止まりではなく、本番導入後の品質改善や保守運用まで経験しているかを確認することが重要です。

3.1 PoCだけでなく本番実績を確認する

AIベンダーの中には、短期間のPoCやデモ構築は得意でも、本番環境での権限管理、ログ管理、セキュリティ、評価、障害対応、運用改善の経験が少ない会社もあります。PoCでは、限られたデータと少数のテストケースで良い結果が出ることがありますが、本番では想定外の入力、古いデータ、権限の複雑さ、利用者のばらつき、コスト増加などが発生します。ベンダー選定では、本番運用まで担当した実績があるかを必ず確認します。

確認する際には、「AIチャットボットを作ったことがありますか」だけでは不十分です。どの業務で、どの規模で、どのデータを使い、どのような品質評価を行い、リリース後にどのような改善をしたのかを具体的に聞きます。可能であれば、PoC、本番導入、運用保守の各フェーズでベンダーが担った役割を分けて確認します。

3.2 自社業界に近い実績を確認する

AI統合では、業界ごとの業務知識が品質に影響します。金融、医療、製造、小売、教育、SaaS、物流、公共、カスタマーサポートでは、扱うデータ、リスク、顧客対応ルール、承認フローが異なります。自社業界に近い実績を持つベンダーであれば、業務特有の注意点を理解しやすく、提案も現実的になりやすいです。

ただし、同業界実績があるだけで安心するのは危険です。重要なのは、その実績でどのような課題を解決したかです。たとえば、同じカスタマーサポートAIでも、FAQ検索を改善したのか、AIエージェントを導入したのか、担当者向けの回答支援を作ったのかによって必要なスキルは違います。ベンダーには、業界実績の内容と成果を具体的に説明してもらいます。

3.3 RAGや検索連携の経験を確認する

社内ナレッジ検索、FAQ回答、問い合わせ支援、マニュアル検索では、RAGや検索連携の設計力が重要です。RAGは、外部ナレッジを検索し、その結果をモデルの回答に使う構成ですが、単に文書をベクトルDBに入れれば品質が出るわけではありません。チャンク分割、メタデータ設計、検索方式、再ランキング、参照元表示、回答生成、評価がすべて関係します。

ベンダーには、RAGの実装経験だけでなく、検索精度が出なかった場合にどう改善するかを確認します。たとえば、文書構造を見直す、メタデータを追加する、キーワード検索とベクトル検索を組み合わせる、評価データを作る、参照元表示を改善するなどの具体策を持っているかが重要です。RAGの品質管理ができるベンダーは、本番運用で強いです。

3.4 プロンプト設計の経験を確認する

LLMを使うAI統合では、プロンプト設計が出力品質に大きく影響します。しかし、プロンプトを個人の勘や場当たり的な修正で管理しているベンダーでは、本番運用時に品質が安定しにくくなります。プロンプトは、タスクごとに目的、入力、出力、禁止事項、例外処理、バージョンを管理する必要があります。

ベンダーには、プロンプトをどのように作り、どのように評価し、どのように改善しているかを確認します。プロンプト変更時に評価データを再実行しているか、バージョン管理しているか、業務担当者がレビューできる形にしているかも重要です。プロンプト設計を単なる「AIへの指示文」と考えるのではなく、システム仕様の一部として扱えるベンダーを選ぶべきです。

3.5 評価設計の経験を確認する

AI統合では、通常のシステムテストとは別に、AI出力の品質を評価する仕組みが必要です。分類精度、回答の正確性、参照元一致率、出力形式の安定性、禁止表現、有人切り替え判定、手動修正率などを評価する必要があります。評価設計がないままPoCを行うと、結果が良かったのか悪かったのかを主観で判断することになります。

ベンダーには、評価データセットの作り方、自動評価と人間評価の使い分け、回帰テストの方法、本番ログを改善に使う方法を確認します。NISTのAI RMFは、AIリスクを測定・管理する考え方を示しており、AI導入では評価とモニタリングが重要になります。ベンダーが評価設計を具体的に語れるかは、選定時の重要な判断材料です。(NIST)

3.6 失敗事例への対応経験を確認する

AIベンダーの説明では、成功事例やデモが強調されがちですが、実務では失敗や改善の経験も重要です。AIの誤回答、検索精度不足、データ品質不足、現場に使われないUI、コスト増加、セキュリティ審査での差し戻しなど、AIプロジェクトではさまざまな問題が起こります。そうした問題にどう対応したかを聞くことで、ベンダーの実運用力が見えます。

失敗事例を正直に説明できるベンダーは、AI導入の難しさを理解している可能性があります。逆に、リスクをほとんど語らず、「AIで何でもできます」「すぐ自動化できます」といった説明ばかりするベンダーには注意が必要です。AI統合では、問題が起きないことよりも、問題を早期に検知し、改善できる体制があることが重要です。

4. データ管理とデータ品質への対応力を確認する

AI統合の品質は、モデルだけでなくデータに大きく左右されます。FAQ、マニュアル、商品情報、問い合わせ履歴、営業メモ、顧客情報、社内文書が古い、重複している、矛盾している、構造化されていない場合、AIの出力も不安定になります。良いベンダーは、AIモデルの話だけでなく、AIが使うデータをどう整えるかまで提案できます。

4.1 データ棚卸しに対応できるか確認する

AI統合前には、対象データの種類、保存場所、形式、責任者、更新頻度、利用可否を棚卸しする必要があります。FAQ、PDF、Word、HTML、Excel、CRMレコード、チケット履歴、CMS記事など、データ形式が混在している場合、AIに投入する前に整理が必要です。ベンダーがこの棚卸し工程を支援できるかを確認します。

データ棚卸しを行わずにAI導入を進めると、古い情報、非公式メモ、重複文書、承認されていない資料がAIの参照対象に入る可能性があります。これは誤回答や情報漏えいの原因になります。RFPには、データ棚卸しをベンダーの作業範囲に含めるか、自社側で行うかを明記し、責任範囲を分けておくべきです。

4.2 データ前処理の方法を確認する

AIに渡す前には、HTMLタグ除去、重複削除、文字コード統一、表記ゆれ整理、個人情報マスキング、不要情報の削除、文書分割、メタデータ付与などの前処理が必要になることがあります。特にRAGでは、文書をどの粒度で分割するか、どのメタデータを付けるかが検索品質に直結します。

ベンダーには、データ前処理をどのように行うか、手作業と自動処理をどう分けるか、前処理後の品質をどう確認するかを聞きます。データ前処理を軽視するベンダーは、モデルの性能だけに依存しがちです。しかし実務では、データを整えないままAIを入れても十分な品質は出にくいため、前処理の設計力は重要です。

4.3 データ権限を維持できるか確認する

AIが社内データを参照する場合、ユーザーごとの閲覧権限を維持する必要があります。たとえば、部署別の文書、プロジェクト別の資料、担当顧客データ、未公開情報などは、利用者によって見られる範囲が異なります。AIが横断検索を提供することで、権限の境界が崩れると重大な問題になります。

ベンダーには、文書単位、フォルダ単位、部署単位、ロール単位でアクセス制御を設計できるか確認します。また、AI回答に使われた参照元がユーザーの権限内かどうかをどう確認するのかも重要です。AI機能は、既存の権限管理を迂回する別ルートになってはいけません。

4.4 個人情報と機密情報の扱いを確認する

顧客情報、問い合わせ履歴、契約内容、営業メモ、社内資料をAIに渡す場合、個人情報や機密情報の扱いを慎重に確認する必要があります。ベンダーが、マスキング、匿名化、入力データ最小化、ログ制御、保存期間制限、アクセス制御に対応できるかを確認します。データをAIに渡すことが技術的に可能でも、業務上・契約上・法務上許可されるとは限りません。

RFPでは、個人情報を含むデータを利用する可能性があるか、外部AI APIへ送信するか、学習利用されるか、ログに残るか、保存期間はどれくらいかを明確に確認します。AIガバナンスでは、データの適切な取り扱いが重要であり、OECD AI Principlesも信頼できるAIのために人権や民主的価値を尊重することを重視しています。ベンダー選定でも、データ保護への姿勢を確認すべきです。(OECD)

4.5 データ更新とインデックス更新を確認する

AIがFAQやCMS記事、マニュアルを参照する場合、元データが更新されたときにAIの検索インデックスやキャッシュも更新される必要があります。CMSでは新しいFAQが公開されているのに、AIが古いFAQを参照して回答してしまうと、顧客対応や社内業務で誤りが発生します。データ更新とAI参照データの同期は、本番運用で非常に重要です。

ベンダーには、データ更新の検知方法、再インデックスのタイミング、非公開データの除外、削除済みデータの反映、キャッシュ更新、更新失敗時の通知を確認します。特に、料金、契約条件、製品仕様、障害情報など、最新性が重要なデータを扱う場合は、更新遅延が業務リスクになります。

4.6 データ品質改善の提案力を確認する

AI統合プロジェクトでは、自社データが最初から整っているとは限りません。FAQが重複している、マニュアルが長すぎる、文書タイトルが曖昧、カテゴリが古い、更新日が不明、責任者がいないといった問題がよくあります。良いベンダーは、AIを実装するだけでなく、AIが使いやすいデータ構造へ改善する提案ができます。

確認すべきなのは、FAQ統合、カテゴリ再設計、メタデータ設計、ナレッジ責任者の設定、文書テンプレート化、RAG向けチャンク設計などの提案ができるかです。AI導入で成果が出ない原因は、モデルではなくデータ品質にあることも多いため、データ改善を含めた提案ができるベンダーを選ぶことが重要です。

5. セキュリティとコンプライアンスを確認する

AI統合では、外部API、クラウド、社内データ、個人情報、ログ、プロンプト、モデル設定が関係するため、セキュリティとコンプライアンスの確認が欠かせません。AI機能は便利ですが、データ送信先、学習利用、ログ保存、権限管理が曖昧なまま導入すると、情報漏えいや監査対応の問題につながります。

5.1 データ送信先を確認する

AI APIやクラウドサービスを利用する場合、自社データがどこへ送信され、どこで処理され、どこに保存されるのかを確認します。国内リージョンなのか、海外リージョンなのか、第三者サービスを経由するのか、ベンダーのサーバーに保存されるのか、モデル提供元に直接送信されるのかによって、法務・セキュリティ上の判断が変わります。

ベンダーには、データフロー図を提出してもらうことが望ましいです。ユーザー入力、社内データ、AI API、検索基盤、ログ基盤、管理画面、外部サービスの間で、どのデータがどう流れるのかを可視化すれば、社内審査もしやすくなります。データ送信先が曖昧な提案は、セキュリティ審査で止まる可能性が高くなります。

5.2 学習利用の有無を確認する

AIサービスに入力したデータが、モデルの学習や改善に使われるかどうかを確認します。利用するAI API、契約プラン、ベンダーの実装方式によって、データの扱いは異なる可能性があります。顧客情報や社内機密を扱う場合、学習利用の有無は非常に重要な確認項目です。

ベンダーには、入力データ、出力データ、ログデータがモデル学習に使われるか、オプトアウトできるか、契約上どのように扱われるかを明示してもらいます。口頭説明だけでなく、利用規約、データ処理契約、秘密保持契約に反映できるか確認します。AI統合では、データ利用条件を契約面でも明確にすることが必要です。

5.3 APIキーと認証情報の管理を確認する

AI統合では、AI APIキー、検索APIキー、CRM APIトークン、CMS認証情報などを扱います。これらの情報が漏えいすると、不正利用やデータ流出につながります。ベンダーがシークレット管理、環境別キー管理、権限最小化、ローテーション、漏えい時の無効化手順に対応できるかを確認します。

特に注意すべきなのは、APIキーをフロントエンドに埋め込むような設計です。AI APIへの呼び出しは基本的にサーバー側で行い、利用者の認証・権限を確認したうえで実行する必要があります。RFPでは、APIキーや認証情報の管理方法も技術提案に含めてもらうべきです。

5.4 ログの保存範囲を確認する

AI統合では、入力、出力、参照データ、ユーザー操作、エラー内容、プロンプトバージョン、モデルバージョンなどをログとして保存することがあります。ログは品質改善や監査に役立ちますが、個人情報や機密情報が含まれる可能性もあります。そのため、何を保存し、何を保存しないかを事前に決める必要があります。

ベンダーには、ログの保存範囲、保存期間、マスキング方法、閲覧権限、削除方法、監査対応を確認します。過剰に詳細ログを残すと情報漏えいリスクが増えますが、ログが少なすぎると品質改善やトラブル調査ができません。必要十分なログ設計ができるベンダーを選ぶことが重要です。

5.5 セキュリティ認証や管理体制を確認する

ベンダーのセキュリティ管理体制も確認します。ISO/IEC 27001、SOC 2、プライバシーマーク、ISO/IEC 42001などの認証や、社内のセキュリティポリシー、脆弱性管理、アクセス管理、インシデント対応体制があるかを確認します。ISO/IEC 42001はAIマネジメントシステムの国際規格として、AIに関するリスクと機会を管理する構造を提供しています。(ISO)

ただし、認証を持っていることだけで十分とは限りません。重要なのは、実際のプロジェクトでどのようにセキュリティを担保するかです。データ送信、環境分離、アクセス制御、ログ閲覧、委託先管理、障害時対応について具体的に説明できるかを確認します。

5.6 法務・規制対応の支援可否を確認する

AI統合では、個人情報保護、著作権、契約条件、業界規制、説明責任、監査対応が関係する場合があります。ベンダーが法務確認に必要な資料、データフロー、利用サービスの規約情報、セキュリティ説明資料を提供できるかを確認します。法務部門やセキュリティ部門が判断できる材料を出せないベンダーは、社内承認プロセスで止まる可能性があります。

特に、顧客向けAI、採用・評価・与信・医療・金融に関わるAI、個人情報を扱うAIでは、法務・コンプライアンス確認が重要になります。OECD AI Principlesも、信頼できるAIにおける透明性、説明責任、人権尊重を重視しています。ベンダーには、単に開発するだけでなく、社内審査に必要な説明責任を支援できるかを確認すべきです。(OECD)

6. AI品質評価の方法を確認する

AI統合プロジェクトでは、品質をどのように測るかが非常に重要です。通常のシステム開発のように、画面が表示される、APIが正常に返る、DBに保存されるという確認だけでは不十分です。AIは、出力が正しいか、業務に使えるか、安全か、安定しているかを評価する必要があります。ベンダーがAI品質評価の仕組みを持っているかどうかは、選定時の重要なポイントです。

6.1 評価データセットを作れるか確認する

AI品質評価には、実際の業務に近い評価データセットが必要です。問い合わせ回答AIなら、実際の問い合わせ文、期待される回答、参照すべきFAQ、有人対応へ切り替えるべきケースを用意します。社内検索なら、検索クエリ、期待される文書、許容される検索結果を定義します。分類AIなら、入力データと正解ラベルを用意します。

ベンダーには、評価データセットをどのように作るか、どのくらいの件数が必要か、個人情報をどう匿名化するか、期待出力を誰が定義するかを提案してもらいます。評価データなしでPoCを行うと、デモでは良く見えても、実際の業務品質を判断できません。

6.2 自動評価と人間評価を分けられるか確認する

AI品質評価には、自動評価と人間評価の両方が必要です。分類精度、JSON形式の正しさ、必須項目の有無、禁止語の有無などは自動評価しやすいですが、文章の自然さ、顧客対応としての丁寧さ、ブランドトーン、業務文脈に合っているかは人間評価が必要です。

ベンダーには、自動評価で何を測り、人間評価で何を確認するかを明確にしてもらいます。すべてを自動評価だけで判断する提案は危険ですし、すべてを人間評価に頼ると運用負荷が高くなります。両者を適切に組み合わせる設計が重要です。

6.3 回帰テストに対応できるか確認する

AIモジュールでは、プロンプト、モデル、参照データ、検索設定を変更すると、出力が変わる可能性があります。あるケースを改善した結果、別のケースが悪化することもあります。そのため、変更のたびに評価データを再実行し、品質が下がっていないかを確認する回帰テストが必要です。

ベンダーには、AI機能の回帰テストをどのように実施するかを確認します。プロンプト変更時、モデル変更時、データ更新時、検索設定変更時に、どの評価を再実行するのかを提案してもらいます。AIはリリース後も変化するため、回帰テストがないと品質管理が属人的になります。

6.4 失敗ケースの評価方法を確認する

AI評価では、うまく回答できるケースだけでなく、失敗すべきケースも評価する必要があります。たとえば、情報が不足している質問、範囲外の質問、機密情報を求める質問、悪意ある入力、感情的な問い合わせ、法務リスクがある問い合わせなどです。AIが無理に回答せず、確認質問を返したり、有人対応へ切り替えたりできるかを確認します。

ベンダーには、拒否すべきケース、エスカレーションすべきケース、回答を保留すべきケースをどう評価するかを確認します。AI導入では、正しく答える能力だけでなく、安全に答えない能力も重要です。特に顧客向けAIでは、失敗時の設計がブランド信頼に関わります。

6.5 品質基準を数値化できるか確認する

AI品質を判断するには、できるだけ数値化された指標が必要です。回答採用率、手動修正率、分類精度、参照元一致率、JSON適合率、禁止表現率、エラー率、再生成率、ユーザー満足度などを測定できるようにします。数値指標があれば、PoC後の判断や本番後の改善がしやすくなります。

ただし、AI品質は数値だけでは判断できません。たとえば、文章の印象、顧客への配慮、ブランドトーンは人間評価も必要です。ベンダーには、数値評価と人間評価を組み合わせ、RFP段階から品質基準を提案してもらうことが望ましいです。

6.6 品質改善サイクルを提案できるか確認する

AI品質は一度の開発で完成しません。利用ログ、現場フィードバック、評価結果、誤回答事例をもとに、プロンプト、参照データ、検索方式、UI、モデル設定を継続的に改善する必要があります。ベンダーがリリース後の改善サイクルまで提案できるかを確認します。

保守契約の中に、定期的な品質レポート、評価データの更新、プロンプト改善、モデル変更検証、ナレッジ改善提案が含まれるかを確認します。AI統合は、作って終わりではなく、運用しながら品質を育てるプロジェクトです。品質改善まで伴走できるベンダーを選ぶことが重要です。

7. RAG・ナレッジ検索の設計力を確認する

社内ナレッジ検索、FAQ回答、問い合わせ支援、マニュアル検索を目的とする場合、RAGの設計力は非常に重要です。RAGは、AIが外部ナレッジを検索し、その結果をもとに回答する仕組みですが、検索対象の文書構造、メタデータ、検索方式、回答生成ルールが不十分だと、回答品質は安定しません。RAGを提案するベンダーには、検索と生成の両方を管理する力が求められます。

7.1 文書分割の方針を確認する

RAGでは、文書をチャンクと呼ばれる単位に分割して検索対象にすることが一般的です。しかし、分割が粗すぎると関係ない情報までAIに渡され、分割が細かすぎると文脈が失われます。FAQ、マニュアル、規約、議事録、製品仕様書、問い合わせ履歴では、適切な分割方法が異なります。

ベンダーには、文書種別ごとにどのように分割するかを確認します。たとえば、手順書では「条件」「手順」「注意点」を一緒に保持する必要がある場合がありますし、規約文書では条項単位で分割する必要があります。文書分割の設計が雑なベンダーは、RAGの回答品質を安定させにくいです。

7.2 メタデータ設計を確認する

RAGでは、文書本文だけでなく、カテゴリ、製品名、言語、対象部署、公開状態、更新日、責任者、地域、プラン、重要度などのメタデータが重要になります。メタデータが整っていれば、検索時に不要な文書を除外し、より正しい文書をAIに渡しやすくなります。

ベンダーには、どのメタデータを付けるべきか、CMSや文書管理システムから自動取得できるか、手動で追加する必要があるかを確認します。多製品、多言語、多部署でAIを使う場合、メタデータ設計がRAG品質を大きく左右します。

7.3 検索方式を確認する

RAGではベクトル検索がよく使われますが、すべてをベクトル検索だけで解決できるわけではありません。エラーコード、型番、商品ID、契約プラン名、法人名などは、意味の近さよりも完全一致やキーワード一致が重要な場合があります。そのため、キーワード検索、ベクトル検索、ハイブリッド検索、再ランキングを使い分ける設計が必要です。

ベンダーには、検索方式を業務データに合わせて選べるか確認します。「ベクトルDBを使うので大丈夫です」という説明だけでは不十分です。検索に失敗した場合に、どのように原因を特定し、検索方式や文書構造を改善するかまで確認するべきです。

7.4 参照元表示に対応できるか確認する

AI回答には、どのFAQ、マニュアル、社内文書を根拠にしたかを表示できることが望ましいです。参照元が表示されれば、担当者は回答の根拠を確認でき、顧客への説明もしやすくなります。参照元がないAI回答は、自然な文章であっても信頼しにくく、業務利用では不安が残ります。

ベンダーには、回答本文と参照元リンクをどのように表示するか、引用範囲をどう示すか、複数文書を参照した場合にどう表示するかを確認します。また、参照元が見つからない場合にAIが推測で答えないようにする設計も必要です。

7.5 ナレッジ更新フローを確認する

RAGで使うナレッジは、常に最新である必要があります。CMSでFAQを更新したのにAI検索インデックスが古いままだと、AIは古い情報をもとに回答してしまいます。特に、料金、契約条件、サポート手順、障害情報、製品仕様などは更新反映の遅れが大きなリスクになります。

ベンダーには、ナレッジ更新後の再インデックス、非公開データの除外、削除済み文書の反映、キャッシュ削除、更新失敗時の通知を確認します。RAGは作って終わりではなく、ナレッジ運用と一体で管理する必要があります。

7.6 RAG品質の評価方法を確認する

RAGの品質評価では、最終回答だけでなく、検索結果そのものを評価する必要があります。正しい文書が検索上位に出ているか、不要な文書が混ざっていないか、AIが参照元と矛盾した回答をしていないかを確認します。回答が自然でも、根拠文書が間違っていれば業務利用には適しません。

ベンダーには、検索評価、回答評価、参照元評価を分けて提案してもらいます。検索精度を測る評価データを作り、回答生成の評価データと組み合わせることで、RAG全体の品質を管理できます。RAG設計力のあるベンダーは、検索と生成を一体ではなく、分解して改善できます。

8. プロジェクト管理力を確認する

AI統合プロジェクトでは、要件定義、PoC、データ整備、API連携、セキュリティ確認、品質評価、運用設計が並行して進むことが多くなります。通常の開発よりも不確実性が高いため、ベンダーのプロジェクト管理力が非常に重要です。スケジュールを引くだけでなく、要件変更や品質改善をどう管理するかを確認する必要があります。

8.1 AI特有の不確実性を管理できるか確認する

AIプロジェクトでは、最初の仕様通りに進めるだけでは十分ではありません。評価結果を見てプロンプトを調整する、データを追加する、検索方式を変える、出力形式を見直すなどの変更が発生します。これはAIプロジェクトでは自然なことであり、失敗ではありません。しかし、変更管理の仕組みがなければ、スケジュールや費用が膨らみます。

ベンダーには、AI特有の不確実性を前提にした進行計画を提案できるか確認します。検証期間、改善期間、評価期間、社内レビュー期間がスケジュールに含まれているかを見ます。単に「2か月で開発します」という提案よりも、検証と改善のサイクルを組み込んだ提案の方が実務的です。

8.2 要件変更管理の方法を確認する

AI統合では、プロンプト変更、参照データ追加、モデル変更、出力形式変更、UI変更、運用フロー変更が起こりやすくなります。これらを口頭やチャットだけで処理すると、後から何が変更されたのか分からなくなります。

ベンダーには、変更管理表、影響分析、承認フロー、再評価の仕組みがあるかを確認します。特に、AI品質に影響する変更は、変更後に評価データで再確認する必要があります。要件変更を禁止するのではなく、管理できるベンダーを選ぶことが重要です。

8.3 役割分担を明確にできるか確認する

AI統合プロジェクトでは、ベンダーだけで完結する作業は多くありません。自社側も、業務要件の定義、データ提供、評価、承認、セキュリティ確認、現場フィードバックを担当する必要があります。役割分担が曖昧だと、ベンダーが待ち状態になったり、必要なデータが集まらなかったりします。

ベンダーには、自社側に必要な作業を明確に提示できるか確認します。たとえば、評価データの作成は誰が行うのか、FAQの承認は誰が行うのか、セキュリティ審査資料は誰が準備するのかを整理します。プロジェクトを進めるためには、ベンダーの作業範囲だけでなく、自社側タスクも明確にする必要があります。

8.4 PoCから本番化までの計画を確認する

PoCの提案だけでは不十分です。PoCで何を検証し、どの条件を満たせば本番化へ進み、本番化では何が追加で必要になるのかを確認します。PoCでは簡易的に手動データ投入で動かし、本番ではAPI連携、権限管理、監査ログ、運用画面が必要になることがあります。

ベンダーには、PoC、本番開発、運用保守を分けた計画と見積もりを提示してもらいます。PoCが安くても、本番化の費用や工数が不明なままだと、社内稟議や予算確保が難しくなります。最初から本番化までの道筋を確認することが重要です。

8.5 コミュニケーション体制を確認する

AIプロジェクトでは、技術、業務、データ、セキュリティ、品質評価に関する議論が多く発生します。そのため、定例会、課題管理、変更管理、品質レビュー、リスクレビューの進め方を確認します。ベンダーの担当者がAI技術だけでなく、業務側の言葉で説明できるかも重要です。

コミュニケーション体制が弱いと、AIの品質問題が技術課題なのか、データ課題なのか、業務要件の認識違いなのか分からなくなります。ベンダーには、プロジェクトマネージャー、AIエンジニア、データ担当、セキュリティ担当、業務ヒアリング担当の体制を確認します。

8.6 ドキュメント作成力を確認する

AI統合では、AI要件定義書、API仕様書、データ設計書、プロンプト仕様書、評価仕様書、セキュリティ説明資料、運用マニュアルなど、多くのドキュメントが必要になります。これらが不足すると、リリース後に自社で運用できなくなったり、担当者変更時に品質が落ちたりします。

ベンダーには、どのドキュメントを成果物として納品するかを確認します。特に、プロンプト、評価データ、参照データ、モデル設定、運用手順はAIモジュールの重要な資産です。ドキュメントを残さないベンダーは、短期開発には向いていても長期運用には不向きです。

9. 契約条件と知的財産を確認する

AI統合では、契約上の確認項目が通常のシステム開発より多くなります。ソースコード、プロンプト、評価データ、学習データ、ログ、モデル設定、API契約、外部サービス利用、成果物の権利、解約時の引き継ぎ条件などを明確にしておく必要があります。契約条件が曖昧なまま進めると、後から内製化やベンダー変更が難しくなる可能性があります。

9.1 成果物の範囲を確認する

ベンダーが納品する成果物を明確にします。ソースコード、設定ファイル、プロンプト、評価データ、設計書、API仕様書、データ処理スクリプト、運用マニュアル、テスト結果、セキュリティ資料、ログ仕様などを成果物として定義します。AI統合では、画面やAPIだけでなく、プロンプトや評価データも重要な成果物です。

成果物が曖昧だと、契約終了後に自社で運用できなくなる可能性があります。たとえば、プロンプトや評価データがベンダー側にしかなく、自社には画面だけが残る状態では、品質改善ができません。RFPでは、納品物一覧を明記してもらい、契約書にも反映する必要があります。

9.2 プロンプトの権利を確認する

AIモジュールでは、プロンプトがシステムの動作を左右する重要な資産になります。プロンプトの所有権、利用権、変更権、再利用可否、ベンダー独自テンプレートとの関係を確認します。プロンプトがベンダーのノウハウとして非公開になる場合、自社で改善できなくなる可能性があります。

RFPでは、プロンプトを成果物として納品できるか、自社が契約終了後も利用できるか、プロンプト変更履歴を共有できるかを確認します。プロンプトは単なる文章ではなく、AI機能の仕様です。運用改善を考えるなら、自社が理解し、管理できる形で引き渡される必要があります。

9.3 データ利用条件を確認する

自社が提供したデータを、ベンダーがどの範囲で利用できるかを契約で明確にします。PoC後の削除、第三者提供禁止、別案件での再利用禁止、モデル学習利用禁止、ログ保存期間、バックアップ削除などを確認します。特に、顧客データや機密データを扱う場合は、データ処理条件を厳密に定める必要があります。

ベンダーが外部AIサービスを使う場合は、その外部サービスのデータ利用条件も確認する必要があります。自社データがどの契約のもとで処理されるのか、ベンダー契約なのか自社契約なのか、責任範囲がどう分かれるのかを明確にします。

9.4 モデル・外部サービスの契約関係を確認する

AI統合では、外部AI API、クラウド、ベクトルDB、監視ツール、翻訳APIなどを利用することがあります。これらの契約主体が自社なのかベンダーなのかを確認します。契約主体によって、費用、データ処理条件、障害時責任、解約時の移行方法が変わります。

ベンダー契約で外部サービスを使う場合、初期導入は簡単ですが、将来的に自社で管理しにくくなる可能性があります。一方、自社契約にすると管理は明確ですが、初期設定や請求管理の負担が増えます。どちらがよいかは、長期運用とガバナンスの方針に合わせて判断します。

9.5 保守範囲を確認する

AIモジュールは、リリース後もモデル変更、プロンプト改善、データ更新、API仕様変更、セキュリティ更新、品質評価が必要になります。保守契約に何が含まれるのかを確認しないと、リリース後の改善がすべて追加費用になる可能性があります。

保守範囲には、障害対応だけでなく、プロンプト調整、評価レポート、ログ分析、モデル更新検証、ナレッジ更新支援、セキュリティパッチ対応が含まれるかを確認します。AI統合では、通常のシステム保守よりも「改善運用」の比重が高くなります。

9.6 解約時の引き継ぎ条件を確認する

契約終了時に、ソースコード、プロンプト、設定、評価データ、ログ、ドキュメント、運用手順、外部サービス設定を引き渡してもらえるか確認します。これが曖昧だと、将来的にベンダーを変更したり内製化したりする際に大きな問題になります。

AI統合では、ノウハウがベンダー側に偏りやすいです。解約時の引き継ぎ条件を契約前に確認し、ベンダーロックインを避けることが重要です。特に、プロンプトや評価データが残らない場合、品質改善を継続できなくなります。

10. 見積もりの比較ポイントを決める

AI統合ベンダーの見積もりは、単純な開発費だけでは比較できません。PoC費用、本番開発費、API利用料、データ整備費、評価費、セキュリティ対応費、保守費、運用支援費が分かれているかを確認する必要があります。価格だけを見ると安く見えても、必要な工程が含まれていない場合があります。

10.1 PoC費用と本番費用を分ける

PoC費用が安くても、本番導入費用が高くなるケースはよくあります。PoCでは、データ量を限定し、手動アップロードで動かし、ログや権限管理を簡略化していることがあります。本番では、API連携、ユーザー認証、権限管理、監査ログ、運用画面、障害対応、セキュリティ審査が必要になり、費用が大きく変わります。

見積もりでは、PoC、本番開発、運用保守を分けて提示してもらいます。PoCだけの価格で判断するのではなく、本番化までの総額と段階ごとの費用を確認します。PoCの目的が本番化判断であるなら、本番化に必要な追加作業も最初から見える化するべきです。

10.2 API利用料を確認する

AI APIや検索基盤の利用料は、リクエスト数、入力トークン、出力トークン、保存データ量、同時利用数によって変動します。初期見積もりにAI API利用料が含まれているのか、自社が別途負担するのかを確認します。特に、利用者数が増えた場合や、大量バッチ処理を行う場合、運用費が想定以上に増える可能性があります。

ベンダーには、月間利用量ごとの費用シミュレーションを出してもらうとよいです。少量利用、通常利用、大量利用の3パターンで試算すれば、予算管理がしやすくなります。AI統合では、初期開発費よりも継続利用料が重要になる場合があります。

10.3 データ整備費を確認する

AI統合では、データ棚卸し、クレンジング、文書構造化、重複削除、メタデータ付与、FAQ整理、個人情報マスキングなどの作業が必要になることがあります。この作業が見積もりに含まれていない場合、後から追加費用になります。

データ整備を省くと、AI品質が出にくくなります。安い見積もりに見えても、データ整備が含まれていない場合は注意が必要です。RFPでは、データ整備をベンダーに依頼するのか、自社で行うのか、範囲を明確にします。

10.4 評価・テスト費を確認する

AI品質評価、評価データ作成、回帰テスト、セキュリティテスト、負荷テスト、ユーザー受け入れテストが見積もりに含まれているかを確認します。AIでは評価工程が非常に重要ですが、見積もりから省かれていることがあります。

評価が含まれていない見積もりは、開発後に品質判断ができません。AI統合では、評価設計とテストを開発の一部として扱う必要があります。RFPでは、評価工程の内容と費用を明確にしてもらうべきです。

10.5 保守・改善費を確認する

AIモジュールはリリース後も改善が必要です。プロンプト改善、モデル変更、データ更新、品質レポート、ログ分析、障害対応、セキュリティ更新が保守に含まれるか確認します。通常の保守契約では、AI特有の改善作業が含まれない場合があります。

保守費が安くても、プロンプト修正やモデル変更検証がすべて別料金であれば、運用中の改善が進まなくなります。AI統合では、初期費用だけでなく、月額運用費と改善費を含めて比較する必要があります。

10.6 価格だけで比較しない

AI統合では、価格だけでベンダーを選ぶと失敗しやすくなります。安い提案は、データ整備、評価、セキュリティ、運用保守、ドキュメント作成が不足している可能性があります。一方で、高い提案でも、何に費用がかかっているのか分からなければ判断できません。

比較表を作り、価格、技術構成、データ対応、品質評価、セキュリティ、運用保守、契約条件、体制、実績を点数化すると判断しやすくなります。AI統合は短期開発だけでなく長期運用が重要なため、総合評価で選定することが大切です。

11. RFPに含めるべき項目を整理する

ベンダーへ提案依頼書を送る前に、RFPに何を含めるかを整理します。RFPの情報が不足していると、各ベンダーが異なる前提で提案を作り、比較が難しくなります。AI統合のRFPでは、通常のシステム開発要件に加えて、データ、AI品質評価、セキュリティ、運用保守、リスク管理の項目を含める必要があります。

11.1 プロジェクト背景を記載する

RFPには、なぜAI統合を検討しているのか、現在どのような業務課題があるのかを記載します。背景が分かれば、ベンダーは単なる技術提案ではなく、課題解決に向けた提案を作りやすくなります。たとえば、問い合わせ対応時間が長い、社内ナレッジが活用されていない、営業資料作成が属人化している、データ分類に時間がかかるなど、現状課題を具体的に書きます。

背景情報が不足しているRFPでは、ベンダーは一般的なAIチャットや検索機能を提案しがちです。自社の業務課題、現場の困りごと、経営上の目的を整理しておくことで、提案の質を高められます。

11.2 対象業務と利用者を記載する

AIを使う業務、利用者、利用シーンを記載します。社内担当者向けなのか、顧客向けなのか、管理者向けなのかによって、必要なUI、品質基準、セキュリティ、承認フローが変わります。問い合わせ担当者向けの回答支援と、顧客向けの自動チャットでは、許容できるリスクが大きく異なります。

利用者情報には、利用者数、部署、利用頻度、利用端末、既存業務フローも含めるとよいです。ベンダーはこれをもとに、画面設計、権限管理、運用教育、スケーラビリティを検討できます。

11.3 既存システム情報を記載する

RFPには、連携対象となる既存システム、API有無、データ形式、認証方式、インフラ環境、セキュリティ制約を記載します。可能であれば、簡単なシステム構成図やデータフロー図を添付します。既存システム情報があれば、ベンダーはより現実的な技術提案と見積もりを出せます。

既存システム情報が不足していると、ベンダーはリスクを見込んで高めに見積もるか、逆に楽観的な見積もりを出して後から追加費用を請求する可能性があります。AI統合では、既存システムの制約がプロジェクトの難易度を大きく左右するため、RFP段階でできるだけ情報を出すことが重要です。

11.4 データ情報を記載する

AIが利用する可能性のあるデータの種類、件数、形式、更新頻度、保存場所、権限、個人情報の有無、機密情報の有無を記載します。FAQ、PDF、HTML、CRMデータ、問い合わせ履歴、商品マスタなど、データごとに状態が異なる場合は、その違いも伝える必要があります。

データ情報は、RAG、検索、分類、要約、セキュリティ設計に影響します。ベンダーに正確な提案を求めるなら、データの状態を隠さず伝えるべきです。データが整っていない場合でも、その状態を共有することで、データ整備を含めた現実的な提案を受けられます。

11.5 品質評価の希望を記載する

RFPには、PoCや本番前にどのような品質評価を行いたいかを記載します。分類精度、回答採用率、修正率、参照元一致率、検索成功率、禁止表現率、ユーザー満足度など、業務に合った指標を指定します。評価指標が明確であれば、ベンダーも評価設計を提案しやすくなります。

品質評価をRFPに入れないと、ベンダーは機能開発だけを提案し、AI出力の品質検証が後回しになる可能性があります。AI統合では、評価設計が成功の鍵になるため、RFP段階から明記することが重要です。

11.6 提案してほしい内容を明確にする

ベンダーに提案してほしい内容を明確にします。技術構成、開発範囲、スケジュール、体制、費用、セキュリティ対策、データ管理、品質評価、運用保守、リスク、前提条件、除外範囲を指定します。提案フォーマットをそろえることで、複数ベンダーの比較がしやすくなります。

自由形式の提案だけにすると、各社が強みだけを強調し、不足部分が見えにくくなります。RFPでは、比較したい観点をあらかじめ提示し、各項目に回答してもらう形にすると判断しやすくなります。

12. ベンダー比較表を作る

AI統合ベンダーを比較する際は、価格だけでなく、技術力、業務理解、データ対応力、品質評価、セキュリティ、運用保守、契約条件を総合的に見る必要があります。比較表を作ることで、関係者間で判断基準をそろえやすくなります。

12.1 技術力を評価する

技術力では、AI API、RAG、ベクトル検索、ハイブリッド検索、プロンプト設計、既存システム連携、クラウド構築、監視、ログ設計に対応できるかを確認します。デモがきれいでも、本番で必要なAPI連携や権限管理が弱ければ、導入後に問題が発生します。

評価時には、技術要素の有無だけでなく、なぜその構成を選んだのか、他の選択肢と比較した理由を聞きます。良いベンダーは、自社の課題や制約に合わせて技術構成を説明できます。

12.2 業務理解を評価する

AI統合では、業務理解が非常に重要です。業務フロー、現場の判断基準、顧客対応ルール、承認プロセスを理解していないと、技術的には動いても実務で使いにくいAIになります。

ヒアリング時に、ベンダーが業務課題を深掘りしてくれるか、リスクを指摘してくれるか、現場利用を想定した質問をしてくれるかを確認します。AI機能を売り込むだけでなく、業務に合わせて設計しようとする姿勢が重要です。

12.3 データ対応力を評価する

データ対応力では、データ棚卸し、前処理、メタデータ設計、権限管理、データ品質改善、更新フローに対応できるかを確認します。AI品質はデータ品質に依存するため、データ対応力の低いベンダーは本番運用で苦労する可能性があります。

提案書にデータ整備やナレッジ管理の話がほとんどない場合は注意が必要です。特にRAGや社内検索を目的とする場合、データ設計をどれだけ具体的に提案しているかを確認します。

12.4 セキュリティ対応力を評価する

セキュリティ対応力では、データ送信先、ログ管理、アクセス制御、APIキー管理、個人情報保護、監査対応を確認します。セキュリティ説明が曖昧なベンダーは、社内審査で問題になる可能性があります。

認証や標準への対応だけでなく、実際のプロジェクトでどのように守るのかを確認します。データフロー図、セキュリティ設計書、インシデント対応手順を出せるベンダーは信頼しやすいです。

12.5 運用保守力を評価する

AIモジュールは、リリース後の運用保守が重要です。モデル変更、プロンプト改善、データ更新、品質監視、ログ分析、障害対応に対応できるかを確認します。初期開発だけが得意なベンダーでは、長期的なAI活用が難しくなります。

運用保守では、定期レポート、改善提案、品質評価、利用状況分析を提供できるかを見ます。AI統合は、リリース後に品質を育てる必要があるため、保守運用の体制を重視すべきです。

12.6 契約・移管条件を評価する

契約条件では、成果物、ソースコード、プロンプト、評価データ、ログ、ドキュメント、解約時の移管条件を確認します。ベンダーロックインを避けるためには、契約終了後も自社で運用・改善できる状態を確保する必要があります。

価格や技術だけでなく、将来の内製化や別ベンダーへの移管を見据えて評価します。AI統合は長期運用が前提になるため、契約条件の透明性も重要な選定基準です。

ベンダー確認チェックリスト

RFP送付前に社内で決めるべきこと

おわりに

AI統合ベンダーを選定する前には、自社側で目的、対象業務、利用データ、既存システム、品質基準、セキュリティ要件、運用体制を整理しておく必要があります。これらが曖昧なまま提案依頼書を送ると、ベンダーごとに異なる前提で提案が作られ、価格やスケジュール、技術構成を正しく比較できません。AI導入は、単なる技術選定ではなく、業務課題、データ、システム連携、リスク管理を含む統合プロジェクトとして考える必要があります。

特に重要なのは、AIを「便利な追加機能」として見るのではなく、データ、API、権限、ログ、評価、運用保守まで含めた業務基盤として扱うことです。PoC段階では簡単に動いても、本番導入ではデータ更新、権限管理、品質評価、セキュリティ審査、運用改善が必要になります。NIST、ISO、OECDのようなAIリスク管理や信頼できるAIに関する枠組みも、AI導入では技術性能だけでなく、透明性、説明責任、リスク管理、継続的改善が重要であることを示しています。(NIST)

RFPを送る前に確認項目を整理しておけば、ベンダーからの提案内容は具体的になり、比較もしやすくなります。価格だけでなく、AI開発実績、既存システム連携力、データ管理力、RAG設計力、品質評価力、セキュリティ対応力、運用保守力、契約条件を総合的に評価することが重要です。AI統合は短期的な開発案件ではなく、長期的に改善しながら業務に定着させる取り組みです。そのため、自社のAI活用を継続的に支えられるベンダーを選定することが、提案依頼前の最大のポイントになります。