AIチャットボットのセキュリティチェックリスト｜契約前の確認項目

AIチャットボットの商談で、営業担当者から「通信は暗号化されています」「第三者認証を取得しています」と説明されても、それだけで契約可否を判断することはできません。自社が入力させる情報、会話ログの保存先、外部のAI・クラウド事業者への再委託、解約後の削除など、確認すべき事項が一つの説明資料にまとまっているとは限らないためです。

契約前のセキュリティ審査では、機能の有無を比べる前に、自社がどの利用場面で何の情報を扱うかを決めます。そのうえで、ベンダーへの質問を、仕様書、契約書、データ処理契約、第三者認証、テスト結果などの証拠と結び付けます。回答や証拠がない項目を推測で合格にせず、保留として責任者へ戻せる審査表を作ることが重要です。

ここでは、AIチャットボットのセキュリティチェックリストを、質問、証拠、合格条件、保留条件、社内担当の順に整理します。特定の認証や機能があれば安全だと一律に判断するものではありません。自社の利用目的、契約、法令、社内規程に照らし、必要に応じて法務・情報セキュリティの専門家へ確認してください。

契約前チェックは入力情報の分類から始める

最初に作るのは製品比較表ではなく、チャットへ入力される情報の一覧です。同じサービスでも、営業時間やアクセスだけを案内する窓口と、予約変更や契約内容を扱う窓口では、必要な安全対策が異なります。想定質問を十数件集め、質問文、添付ファイル、回答時に参照する資料、有人担当者へ渡す情報を書き出してください。

分類後は、「入力される可能性がある情報」と「業務上取得する必要がある情報」を切り分けます。利用者が自由入力欄へ書く可能性はあっても、自社で保存・利用する必要がない情報もあります。入力画面の注意書きだけに頼らず、受信後の閲覧範囲、ログへの記録、検知後の処理、削除手順まで確認してください。個人情報を入力させる前の整理は、AIチャットボットの個人情報確認項目でも詳しく確認できます。

匿名利用と会員利用で取得・保存する情報を分ける

公開ページの匿名チャットで「土曜日は営業していますか」と尋ねる場面では、氏名や電話番号を取得する必要はありません。一方、予約変更や契約内容の照会では、本人確認や担当者への引き継ぎが必要になる場合があります。両者を「チャット利用者」とひとまとめにせず、利用場面ごとに取得項目と保存条件を分けます。

匿名利用では、端末や通信に関する識別情報、会話ログ、アクセス解析情報が取得されるかを確認します。会員利用では、アカウント情報と会話履歴のひも付き、本人確認の方法、担当者が閲覧できる範囲、退会後の処理も確認対象です。ベンダーへ「個人情報を扱えますか」とだけ尋ねるのではなく、想定する画面、手続き、データ項目を提示すると、回答の対象範囲を明確にできます。

• 利用目的: 何のために取得し、別の目的へ利用しないか。
• 必須項目: その手続きに本当に必要な情報だけになっているか。
• 通知・同意: 利用者へいつ、どの内容を示すか。
• 閲覧範囲: 運用担当者、管理者、委託先の誰が閲覧できるか。
• 保存と削除: 会話終了、退会、契約終了後にどう処理するか。
• 有人引き継ぎ: 担当者へ渡す項目と渡さない項目を分けているか。

「将来使う可能性がある」という理由だけで取得項目を増やさないことも重要です。利用目的が決まっていない情報は取得せず、必要になった時点で目的、通知、保存、閲覧権限を再審査します。匿名案内から会員向け手続きへ移る場合は、画面上で利用場面が切り替わったことを明確にし、追加取得する情報とその目的を確認します。

ベンダーへの質問を証拠と合格条件までセットにする

質問票に「暗号化されていますか」「ログは取れますか」とだけ書くと、回答が「はい」で終わり、契約判断に使えません。質問には対象、条件、例外を含め、何を確認できれば合格にするかを先に決めます。証拠は一種類に固定せず、仕様書、契約書、データ処理契約、第三者認証の適用範囲、管理画面での実機確認、テスト結果などから質問に合うものを選びます。

営業資料や口頭説明は、質問の入口にはなっても、重要項目の最終的な証拠には適さない場合があります。資料名、版、確認日、回答者を記録し、契約条件と仕様の説明が食い違う場合は、どちらが優先されるかを確認してください。第三者認証についても、認証名だけでなく、対象組織、対象サービス、適用範囲、有効期間を確認します。

公的な確認観点として、IPAのテキスト生成AI導入・運用ガイドラインは、ガバナンスとシステムの両面を整理しています。調達時に求める証拠資料を検討する場合は、デジタル庁の生成AIシステム用調達チェックシート案も参考になります。公的資料の項目をそのまま転記するのではなく、自社の規模、利用目的、扱う情報に合わせて優先順位と合格条件を決めてください。

データの学習利用・保持・再委託・削除を確認する

データの扱いを確認するときは、サービス提供会社だけを見るのではなく、入力から削除までの流れをたどります。利用者の入力、AIの出力、添付ファイル、会話ログ、評価、管理者の操作履歴を分け、どの処理先を通り、どこへ保存されるかを書き出します。外部のAIモデル、クラウド、監視、問い合わせ対応などに別会社が関与する場合は、その会社が担当する処理も確認対象です。

「学習に使わない」という回答を得た場合は、何の学習を指しているかを確認します。基盤モデルの学習、サービスの品質改善、人による内容確認、障害調査は、それぞれ目的と取扱条件が異なります。入力、出力、添付、評価、会話ログごとに、利用目的、設定、例外、保持期間を確認してください。契約中に条件や再委託先が変わる場合は、通知時期と確認方法も審査表へ記録します。

保持期間も、一つの数字だけでは判断できません。管理画面に表示される会話、出力したファイル、障害調査用ログ、バックアップ、再委託先に渡ったデータを分けて確認します。削除申請後に利用者から見えなくなる時点と、主系データやバックアップから削除される時点が異なる場合は、それぞれの期限と確認方法を質問してください。保存期間を決める手順は、チャットボットのログ保存期間で詳しく整理しています。

暗号化、アクセス制御、脆弱性対応などの技術項目を自社の担当者だけで評価できない場合は、「安全ですか」と結論だけを求めないことが大切です。通信時・保存時の適用対象、方式、鍵の管理主体、例外、テストの対象範囲など、専門家が判断できる資料を依頼します。AWSが公開する生成AIアプリケーションのセキュリティ確認手順も、実験段階から本番へ移る際の技術・統制上の観点を補う資料になります。

ナレッジと回答品質の安全管理を確認する

AIチャットボットでは、情報漏えいだけでなく、古い資料や対象外の情報に基づく誤回答も業務上のリスクになります。サービス基盤に安全対策が施されていても、料金表の旧版と新版が混在し、更新責任者が決まっていなければ、利用者へ誤った案内を出すおそれがあります。

契約前には、登録できるファイル形式や件数だけでなく、ナレッジの正本をどう管理するかを確認します。資料の登録者、承認者、公開日、失効日、差し替え方法、変更履歴、再テストの担当を整理し、自社とベンダーの担当範囲を分けてください。回答時に参照元を確認できるか、根拠が不足する質問に対して推測で答えず、回答を止めたり有人対応へ切り替えたりできるかも、想定質問を使って検証します。

古い料金表に基づく誤回答が見つかった場合は、該当回答を停止し、正本を確認して資料を差し替えます。その後、同じ質問だけでなく、言い換えた質問でも再テストし、承認を得てから公開を再開します。この一連の作業を管理画面だけで完結できると仮定せず、現行仕様で可能な操作と社内作業を切り分けてください。ベンダーが更新を代行する場合も、内容の正誤を最終承認する自社責任者は必要です。

権限・監査ログ・有人引き継ぎを業務フローで試す

権限表に「管理者」「担当者」と書かれていても、自社の分担に合うとは限りません。ナレッジを登録する人、内容を承認する人、公開する人、会話を閲覧する人、アカウントを追加・停止する人を並べ、それぞれが必要な操作だけを行えるか確認します。一つのアカウントを複数人で共有すると、変更者を追跡できず、退職や委託終了時の利用停止も難しくなります。

権限設計の詳細はチャットボットのアクセス権限設計、変更追跡に必要な記録はチャットボット監査ログの設計で確認できます。契約前のデモやPoCでは、資料を読むだけでなく、権限の異なる試験アカウントを使って登録、承認、公開、閲覧、削除を試してください。各操作について、実行者、日時、対象、変更内容が記録されるかを確認します。ログを利用できるプラン、保持条件、出力方法が未確認なら、機能があるという説明だけで合格にしません。

有人引き継ぎも、実際の通知先と通知内容まで確認します。担当者が対応を始めるために必要な情報へ絞り、会話全文を無条件に渡さないことが基本です。要約、連絡先、希望内容、緊急度などから、利用目的に必要な項目だけを選びます。通知先のメールや業務システムでの保存、閲覧、転送も確認対象です。誤った担当者へ通知された場合に誰が連絡を止め、利用者へ案内し、記録を修正するかまで決めると、機能表だけでは見つからない運用上の不足を確認できます。

未回答や条件付き回答は保留として管理する

審査表を「はい・いいえ」だけで管理すると、確認中の項目や追加条件が埋もれます。各項目を「確認済み」「条件付き」「未確認」「不適合」の4状態に分けてください。「条件付き」は、特定プランへの変更、追加設定、個別契約、運用上の制限を満たす場合だけ合格になる状態です。「未確認」は、回答や資料がそろっておらず、判断できない状態を指します。

たとえば、監査ログが特定プランだけで提供される場合は、自社が契約するプラン、記録対象の操作、保持条件を確認するまで「条件付き」とします。「個別に対応可能」という回答も、費用、納期、保守範囲、契約への記載を確認するまでは合格にしません。口頭で説明を受けた項目は、回答者と確認日を記録したうえで、仕様書や契約条項などの証拠を依頼します。

保留表には、未確認事項、必要な証拠、回答責任者、回答期限、保留解除条件、期限を過ぎた場合の扱いを記録します。顧客データの学習利用、再委託先、削除、事故通知などの重要項目を確認できない場合は、ほかの項目が合格でも契約へ進めないという停止条件が必要です。停止条件は審査の途中で都合よく変えず、開始時に経営者、法務、情シス、業務責任者で合意してください。

事故や情報漏えいへの対応も、保留にしやすい項目です。事故の定義、通知期限、連絡経路、初動、調査協力、ログ提供、復旧、再発防止、休日の連絡方法を確認し、自社とベンダーの担当範囲を契約やSLAへ残します。通知時期やログ提供条件が曖昧な場合は、営業担当者の説明だけで確認済みにしないでください。

PoCから本番へ進む前に差分を再審査する

PoCでは公開済みFAQだけを登録し、社内の少人数だけで試すことがあります。本番で顧客の自由入力を受け、CRMや通知先と連携し、複数の委託先が管理画面を利用するなら、リスク条件は変わります。PoCで事故が起きなかったことを、本番環境全体の安全性の証明として扱わないでください。

差分ごとに追加テストを作り、テスト結果、残る制約、承認者を記録します。公開前の質問分類には、チャットボット公開前のテストケースを利用できます。セキュリティ審査では、正しい回答が返ることだけでなく、禁止情報を答えないこと、根拠不足の質問へ推測で答えないこと、有人通知が必要な相手だけに届くことも確認してください。

PoCでは公開情報だけを使っていても、本番で顧客情報、添付ファイル、CRM連携を追加するなら、データフローと権限を再審査します。差分がない項目も「変更なし」と記録し、見落としたのか、確認した結果なのかを区別できるようにします。本番移行の承認は、PoCの評価者だけでなく、追加されるデータや運用の責任者も含めて行います。

解約時の返却・削除まで契約前に確認する

出口条件は、解約を決めてから確認するのでは遅すぎます。契約前に、会話ログ、登録したナレッジ、設定、評価、添付ファイル、アカウント情報を、どの形式でいつまで取得できるか確認してください。出力できない項目がある場合は、乗り換えや監査に必要かを判断し、必要であれば契約前に代替手段を決めます。

削除については、管理画面、主系データ、バックアップ、再委託先を分けます。解約日、管理画面へ入れなくなる日、データの出力期限、各保存先からの削除予定日、削除を確認する方法を日程表にしてください。管理画面からデータが見えなくなる日と、主系データやバックアップから削除される日は同じとは限りません。法令や紛争対応などを理由とする例外的な保持がある場合は、対象、目的、期間、アクセス制限を確認します。

契約終了時の作業責任も切り分けます。たとえば、自社は必要データの出力、外部連携の停止、アカウントの確認を担当し、ベンダーは契約に定めた返却・削除とその確認資料の提供を担当します。再委託先にも削除義務が及ぶか、削除証明をどの単位で受け取れるかも契約前の確認事項です。乗り換えを含む全体手順はチャットボットの乗り換え判断と移行手順で確認できます。

AIチャットボットのセキュリティ確認に関するFAQ

契約前に残す確認記録

最終的な審査記録には、利用目的、対象利用者、情報分類、質問票、証拠資料の名称・版・確認日、未確認事項、条件付き項目、PoCの結果、本番との差分、例外承認、最終承認者を残します。営業資料を保存するだけでは、どの条件を確認し、なぜ合格と判断したかを後から説明できません。契約後に条件が変わったときも、前回の判断根拠があれば再審査する範囲を特定しやすくなります。

各項目には、確認した証拠への参照先と、判断した担当者を記録します。資料が更新された場合に過去の版を確認できるよう、受領日と版をセットで残してください。条件付きで承認した項目には、守るべき制約、解除条件、再確認日を付けます。例外を認める場合は、承認者、理由、期限、代替策を記録し、期限後も自動的に継続しない運用にします。

すべての項目を一律に満たすことが目的ではありません。自社が扱う情報と業務への影響に応じて優先順位を決め、証拠を確認できない重要項目は保留または見送りとします。小さく試す場合も、試用してよいデータ、利用者、連携先、期間を先に決めることが、安全性を説明できる導入判断の出発点です。

[cta-mailmag]