AIベンダーへ何を聞くか。回答の根拠と未回答を整理する

AIベンダーへの確認質問では、機能や見積金額に加え、入力データの用途、依存する第三者サービス、変更の把握方法、利用終了後に残るものを押さえます。

ただし、埋まった回答欄の数だけでは導入可否を決められません。回答を裏づける規約や契約などを確認できるか、何が未回答のままか、その状態で自社はどこまでなら実行するかを分けて記録する必要があります。判断の焦点は「ベンダーが安全か」という抽象的な評価から、「自社が定めた条件の範囲で使えるか」へ移します。

その判断を曖昧にしないため、データ用途・第三者サービス・変更通知・退出方法を同じ表で評価します。難しいのは、十分な回答が得られない項目を、即座に採用不可とするのでも、そのまま受け入れるのでもなく、具体的な導入条件へ変換することです。

AIベンダーへの確認質問は四つの領域でそろえる

確認項目を増やし続けるより、まず情報の流れと契約後の変化を追える単位に分けます。以下の四領域は、公式資料の一般原則を基にした実務上の整理であり、原典が定める分類や法的義務ではありません。

データ用途

入力・提供するデータについて、「保存しますか」だけでは足りません。次のように、利用、共有、保存、アクセスを分けて聞きます。

• 自社が入力・提供するデータは、サービス提供以外の目的に使われるか
• ベンダーとデータを共有する範囲と方法は何か
• 誰にアクセスが付与され、分析などのため別の場所へ保存されるか
• 利用終了時を含め、保持と削除をどの文書で確認できるか

英国政府のAI調達ガイドは、調達段階とその後のプロジェクトでベンダーとデータを共有するか、共有するならどのように共有するかを定義するよう示しています。また、データガバナンスの論点として、プロジェクトメンバーへのアクセス付与、分析のための別場所への保存、データ同意の見直しを挙げています（Guidelines for AI procurement、2026年9月21日確認）。

したがって、「学習に使わない」という回答だけで判断を終えません。サービス提供の過程で誰が扱い、どこへ移り、何を根拠にその運用を確認できるかまでが判断材料です。

第三者サービス

AIサービスは、回答した企業の説明だけを確認すればよいとは限りません。ここでは、その企業が利用する外部のAIシステムやデータについて聞きます。

• 提供機能に関与する第三者サービスは何か
• 第三者システムの役割と、自社データが渡る範囲は何か
• 訓練データ、訓練・推論アルゴリズム、前提、制約について、ベンダーが把握し説明できる範囲はどこまでか
• 第三者サービスが変わる場合、どのように通知されるか

NIST AI RMF Playbookは、第三者のAIシステムとデータに関する方針を設け、第三者システムの機能について、訓練データ、訓練・推論アルゴリズム、前提、制約を把握できる透明性を扱うことを提案しています（NIST AI RMF Playbook: Govern、2026年9月21日確認）。

求める対象は、自社の利用判断に必要な情報です。そのうち何が開示され、何が開示されないかを質問で明確にします。開示されない事項は「問題なし」と解釈せず、未回答として残します。

変更通知

導入時点の確認結果も、機能や依存先の変化に応じて見直します。変更の内容に加え、通知の時期と再確認の方法を聞きます。

• 仕様、データ用途、第三者サービス、規約の変更はどこで通知されるか
• 通知は適用前か適用後か
• ホットフィックス、パッチ、更新はどの計画で管理されるか
• 前方・後方互換性について、何が保証され、どの文書に記載されるか

NIST AI RMF Playbookは、第三者ソフトウェアのリリース予定と変更管理計画について、ホットフィックス、パッチ、更新、前方・後方互換性の保証を含めて確認することを提案しています（NIST AI RMF Playbook: Map、2026年9月21日確認）。

通知先のメールアドレスだけでは、自社が再審査すべき変更を拾えるとは限りません。「データ用途または第三者サービスが変わったら利用範囲を見直す」のように、通知を受けた後の自社側の行動まで決めます。

退出方法

導入判断では、使い始める条件と同じ重さで、やめられる条件を確認します。

• 契約終了時に、データの返却、移行、削除を誰が行うか
• 返却されるデータと形式は何か
• モデルや関連成果物は終了後にどこで、どのように扱われるか
• 上流・下流の依存先を含め、代替システムへの移行に必要な手順は何か

NISTのAI RMF Playbook: Governは、AIシステムの廃止方針で、上流・下流の依存関係、データ保持に関する規制上の要件、代替システムへの移行、廃止後のモデルや関連成果物の保管場所と期間を扱うことを提案しています。英国政府のAI調達ガイドも、AIシステムとデータの終了プロセス、契約終了時の発注者と供給者の役割・手順を定義し、契約に含めることを示しています（いずれも2026年9月21日確認）。

「削除可能」という回答を得たら、対象、手続き、役割、確認方法へ分解します。退出できるという抽象的な約束を、退出時に実行できる手順へ落とし込むためです。

回答を「根拠あり」「根拠なし」「未回答」に分ける

口頭説明や回答票には、検討を進める価値があります。しかし、後から同じ内容を再確認できなければ、変更時や担当者交代時の判断材料としては弱くなります。

NISTのAI RMF Playbook: Mapは、第三者に関する価値評価とリスク管理の材料として、監査報告、テスト結果、製品ロードマップ、保証、利用規約、エンドユーザーライセンス、契約などの文書を確認することを提案しています（2026年9月21日確認）。この一般原則を基に、回答内容と根拠資料を別欄にします。この三つの評価区分は記事が提案する実務上の方法であり、NIST所定のものではありません。

• 根拠あり：回答に対応する規約、契約、監査報告、テスト結果、ロードマップなどを再確認できる
• 根拠なし：説明はあるが、その内容を再確認できる資料が示されていない
• 未回答：質問に対応する説明がない、または質問した範囲と回答の範囲が一致しない

判断で区別すべきなのは、根拠なしと未回答です。前者は資料の提示を依頼する余地があり、後者は質問の再提示か、情報が得られない前提での条件設定が必要になります。根拠資料がある場合も、資料名に加えて該当箇所と確認日を残せば、変更後との差分をたどれます。

回答評価を導入条件に変える判断表

質問、回答、根拠、未回答を別々のファイルに散らすと、最終判断とのつながりが見えません。次の表は、公式資料の一般原則を基にした記事独自の実務様式です。

この表には合否の点数を置きません。未回答の重みは、扱うデータや業務によって変わるからです。代わりに、「条件を満たす範囲だけ実行する」「追加資料を確認するまで入力対象を限定する」「変更があれば再確認する」といった行動へつなげます。

たとえば、データのサービス提供外利用について説明はあるものの、再確認できる文書が示されていない場合、「回答済み」で閉じません。根拠なしと記録し、文書の提示を依頼します。提示まで利用を進めるなら、扱うデータの範囲を自社条件として明記します。第三者サービスの変更通知が未回答なら、その事実を残したうえで、変更を把握できない状態でも許容できる業務に対象を限るかを決めます。

未回答の数だけで一律に見送ると、業務やデータごとの違いを判断に反映できません。未回答をベンダー任せにすれば、自社が引き受ける不確実性も曖昧になります。扱うデータと共有範囲、利用する第三者サービス、変更時の再確認、終了時の返却・削除・移行の役割を自社の条件にし、その条件を満たす範囲だけを実行対象にします。この条件付き判断は、出典の一般原則を基にした記事独自の提案です。

判断表を社内運用へつなぐ

判断表の作成者だけが条件を知っていても、実際の利用時には守れません。許可するデータ、対象業務、再確認が必要な変更、利用終了時の連絡先を、利用者が参照する社内ルールへ反映します。生成AIの社内ガイドラインを整える際は、禁止事項だけでなく、この表で決めた利用条件と見直しの契機を対応させると、ベンダー確認と日々の運用が分断されません。

導入初期の担当、確認期限、見直しの場を設計するなら、AI活用の最初の90日を設計する流れにも判断表を組み込めます。条件が変わったときに戻る記録として扱うためです。

導入前の質問数より、四領域の回答、再確認できる根拠、未回答、自社の導入条件、再確認の契機が一本につながっているかを重視します。ベンダーから十分な情報を得られない項目が残っても、それを空欄のまま通過させず、入力するデータ、対象業務、見直す変更、退出時の役割という条件へ変換できれば、実行範囲を具体的に決められます。