AIチャットボットのセキュリティ対策｜小規模企業向け公開前チェックリスト

01

安全性は、AIへの一文ではなく周辺設計でつくる

生成AIは自然な回答を返せますが、入力文の意図を常に正しく判定するわけではありません。利用者が指示を上書きしようとする文章を入力する、WebページやPDFの中に不正な指示が紛れ込む、参照資料に公開対象外の情報が含まれる、といった問題を一つのプロンプトだけで完全に防ぐことは困難です。OWASPも、プロンプトインジェクションには単独で確実な予防策がないとして、多層防御と最小権限を重視しています。

したがって、AIチャットボットは『入力』『検索・参照』『生成』『外部操作』『表示』『記録』の流れに分け、各段階で失敗しても被害が広がらないように設計します。公開情報だけを答えるチャットボットと、注文情報を照会できるチャットボットでは必要な対策が異なります。機能を増やす前に、何を守り、どこまで動かすかを決めることが出発点です。

小規模企業では、高価な仕組みを一度に導入するより、公開済みの情報だけを扱う一業務から始め、権限を増やすたびにテストを追加する方が現実的です。セキュリティは『導入するか、しないか』ではなく、使う情報と機能に応じてリスクを下げ続ける運用として考えます。

02

最初に、守る情報とAIができる操作を棚卸しする

対策を選ぶ前に、チャットボットが受け取る情報、参照する情報、外部へ送る情報、実行できる操作を一枚の表にします。『問い合わせ内容』とまとめず、氏名、メールアドレス、注文番号、相談内容、会話ログのように分けます。参照データも、公開FAQ、商品情報、社内手順、顧客データを区別します。

次に、それぞれが本当に必要かを確認します。商品選びの相談に氏名は不要です。配送状況の確認が目的でも、公開チャット上で注文情報を直接返すより、本人確認済みのマイページへ案内する方が安全な場合があります。必要性が説明できない情報や操作は、初期版から外します。

最後に、担当者、保存場所、保存期間、削除方法を決めます。AI提供会社だけでなく、フォーム、アクセス解析、ログ保管、通知先など、情報が通るサービス全体を確認します。データの流れが分からない状態では、利用規約や設定を正しく評価できません。

• 入力：利用者に何を入力してもらうか、入力してほしくない情報は何か
• 参照：公開情報、社内限定情報、個人データをどこで分けるか
• 出力：価格、在庫、契約、健康・法律など、誤りの影響が大きい回答は何か
• 操作：検索、メール送信、予約、注文変更など、AIに何を許可するか
• 記録：誰がログを見られ、いつ削除し、事故時にどこまで追跡できるか

03

個人情報は『入力させない・送らない・残しすぎない』

個人情報を扱う場合は、利用目的の範囲と必要性を確認し、入力欄の近くで利用者に分かるように示します。個人情報保護委員会は、生成AIサービスへ個人データを入力する際、利用目的の範囲内か、提供事業者が機械学習へ利用しないかなどを確認するよう注意喚起しています。契約や設定によって扱いが異なるため、『AIだから自動的に学習される』『設定すれば絶対に保存されない』と一括りにしないことが大切です。

公開チャットでは、氏名、住所、電話番号、注文番号、クレジットカード情報、パスワードなどを入力しないよう明示します。自由入力だけに任せず、個人情報らしい文字列を検知して送信前に注意を出す、必要な相談は専用フォームや本人確認済み画面へ移す、といった導線を用意します。カード情報やパスワードは、チャットボットで受け取らない設計を基本にします。

ログは改善に役立ちますが、目的なく長期間残すほどリスクが増えます。保存する項目、期間、閲覧者を決め、分析用データでは個人を識別しにくくします。削除依頼や契約終了時に、提供会社側を含めてどのデータが消えるのかも事前に確認します。

04

RAGは公開情報と限定情報を検索時点で分離する

RAGは、質問に関連する自社資料を検索し、生成AIへ渡して回答を作る仕組みです。便利な一方、公開FAQと社内資料を同じ知識ベースへ入れ、回答文の指示だけで出し分ける設計は避けるべきです。IPAも、アクセス権限が異なる情報をRAGで混在させると、本来見られない情報が回答に含まれる可能性を指摘しています。

公開サイトのチャットボットは、原則として公開済み情報専用の知識ベースから始めます。社内向けや会員向けを作る場合は、利用者の本人確認と権限確認を行い、検索する前に対象データを絞ります。回答を生成した後に機密語を隠す方法だけでは、言い換えや要約で内容が漏れる可能性を残します。

登録資料には公開範囲、更新日、版、担当者を付け、旧版と重複を除きます。外部Webページを自動取得する場合は、そのページ内の文章も信頼できない入力として扱います。取得元を限定し、変更時に再確認し、回答には根拠URLを示せる状態にします。RAGの作り方は、別記事の導入手順とあわせて確認できます。

05

プロンプトインジェクションを前提に権限を小さくする

プロンプトインジェクションとは、利用者の入力や参照コンテンツに含まれる指示によって、開発者が想定したルールを回避させようとする攻撃です。『以前の指示を無視して』のような直接的な入力だけでなく、AIが読むWebページ、PDF、画像などに隠された間接的な指示も対象になります。

入力の禁止語だけでは、表現を変えた攻撃を防ぎ切れません。まずAIへ与える権限を、目的に必要な範囲へ限定します。商品案内だけなら、管理画面、顧客一覧、メール送信、注文変更へ接続しません。外部機能を使う場合も、読み取りと更新を分け、対象データを限定し、一回あたりの件数や金額に上限を設けます。

また、AIが作ったURL、コード、メール本文、検索条件をそのまま実行しません。形式、許可された宛先、対象ID、文字数などをプログラム側で検証し、影響が大きい操作は確認画面や担当者承認を挟みます。AIの回答を『命令』ではなく、検査が必要な候補として扱うことが重要です。

• システム用の秘密情報やAPIキーを、プロンプトや参照資料へ書かない
• AI用アカウントは専用にし、管理者権限を与えない
• 許可する機能、データ、宛先、回数を明示的なリストで制限する
• 注文変更、返金、外部送信などは、本人確認と人の承認を組み合わせる
• 参照するWeb、ファイル、ツールの出力も信頼できない入力として検査する

06

誤回答と危険な出力を、表示前と導線で抑える

情報漏えいだけが安全上の問題ではありません。根拠のない価格、存在しない在庫、誤った返品条件、断定的な専門助言は、利用者と事業の双方に影響します。回答に使う資料を限定し、根拠が見つからない場合は推測せず、担当窓口へ案内するルールを設けます。

出力は、文字数、リンク先、禁止する形式、個人情報らしい文字列などを表示前に検査します。重要条件は原文ページへのリンクを添え、価格や規約のように更新される情報には有効日を持たせます。医療、法律、金融など専門判断を要する内容は、用途に応じて回答範囲を狭め、専門家や正式な窓口へつなぎます。

人への引き継ぎは、AIが失敗した後の例外ではなく、最初から設計する機能です。回答の根拠が弱い、利用者が不満を示す、同じ質問を繰り返す、個別契約の確認が必要、といった条件を決めます。引き継ぐ際も、不要な会話全文を送らず、利用者の同意と必要な情報を確認します。

07

ログは改善と事故調査に必要だが、閲覧範囲を絞る

公開後は、入力、参照した資料、回答、エラー、外部機能の実行、設定変更を、必要な範囲で記録します。何が起きたかを追跡できなければ、誤回答の原因が資料・検索・生成・連携のどこにあるか判断できません。一方で、ログ自体に相談内容や個人情報が含まれる可能性があります。

管理画面は強いパスワードと多要素認証を使い、閲覧者を必要な担当者へ限定します。日常の品質分析では個人を識別しにくい表示を使い、元ログへアクセスした操作も記録します。ログのダウンロード、共有、外部分析ツールへの送信を安易に増やさないことも重要です。

監視では、急な会話数増加、同じ送信元からの連続利用、エラー率、回答不能率、特定資料への偏り、禁止した操作の試行を確認します。平常時の範囲を把握し、どの状態で通知し、誰が確認し、いつ一時停止するかを決めます。

08

利用上限とレート制限で、費用とサービス停止を防ぐ

生成AIは利用量に応じて費用が増える構成があります。公開チャットボットが自動アクセスや大量入力を受けると、情報漏えいがなくても、想定外の請求や利用枠の消費によって通常の利用者が使えなくなる可能性があります。OWASPの現行リスクでも、無制限なリソース消費が重要項目として扱われています。

一人あたりとサイト全体の回数、一定時間内の送信数、一回の入力・出力の長さ、参照資料量、外部機能の実行数に上限を設けます。月額予算に近づいた時の通知、上限到達時の安全な案内、管理者がすぐ停止できる機能も用意します。上限値は公開後の実績を見て調整します。

単にCAPTCHAを置くだけでなく、連続利用や異常な入力を段階的に制限します。厳しすぎる制限は利用者を妨げるため、通常利用の回数と時間を確認し、異常時だけ追加確認や待ち時間を設ける方法が現実的です。

09

サービス選定では、機能表よりデータの扱いを質問する

AIモデル、チャットボット基盤、クラウド、運用支援を別の会社が提供する場合があります。契約先だけでなく、入力と登録資料が実際にどのサービスへ送られ、どこに保存されるかを確認します。料金や回答精度に加え、設定を自社で確認できるか、事故時に連絡できるかも選定条件です。

回答は口頭説明だけでなく、利用規約、プライバシーポリシー、セキュリティ資料、契約条件で確認します。『学習に使わない』という説明が、モデル改善だけを指すのか、ログ保存や不正利用監視まで含むのかを分けて質問します。個別の法的判断が必要な場合は、専門家へ確認します。

• 入力、会話ログ、登録資料はどこへ送信・保存され、再学習に利用されるか
• 保存期間、バックアップ、契約終了時の返却・削除方法はどうなっているか
• 公開情報と限定情報の権限を、検索前に分離できるか
• 管理者の多要素認証、権限分け、設定変更履歴、監査ログがあるか
• 利用量の上限、通知、レート制限、緊急停止を設定できるか
• 障害・事故時の連絡経路、初動、報告範囲、再開条件は何か
• 再委託先とデータの保存地域を確認できるか

010

公開前テストと、問題発生時の停止手順を用意する

公開前は、通常の質問だけでなく、答えてはいけない質問を含めて試します。個人情報の入力、内部指示の開示要求、権限外データの質問、根拠のない質問、長文の連続送信、危険なリンク生成、外部操作の改変などを用意します。検索された資料と最終回答を分けて確認し、設定変更後も同じ質問集で再テストします。

問題を見つけた時は、担当者が管理画面へ入れない状況も想定します。チャット表示を止める方法、APIキーや連携権限を無効化する方法、関係者への連絡先、ログ保全、利用者への案内、原因確認、再開条件を短い手順書にします。連絡先と操作方法は、チャットボットの外に保管します。

すべての問題をゼロにしてから公開するのではなく、残るリスクと影響を確認し、対象を限定して公開します。NISTの生成AI向けリスク管理資料や、経済産業省・総務省のAI事業者ガイドラインも、企画から運用まで継続してリスクを管理する考え方を示しています。

• 正常系：主要な質問へ、正しい根拠とリンクで答えられる
• 回答不能：資料にない質問へ推測せず、適切な窓口を示せる
• 情報保護：個人情報や限定情報の入力・出力を安全に扱える
• 攻撃・乱用：指示の上書き、大量送信、権限外操作の影響を限定できる
• 運用：通知、停止、ログ確認、設定復旧を担当者が実行できる

011

小規模企業は、公開情報だけの一業務から始める

最初の優先順位は、公開情報の分離、個人情報を入力させない導線、最小権限、回答不能時の案内、利用上限、緊急停止です。これらを確認したうえで、商品案内やよくある質問など、失敗時の影響を限定しやすい一業務から公開します。顧客データ連携や注文変更は、利用価値と追加リスクを比較して後から判断します。

AIチャットボットの安全性は、導入時の設定だけでは維持できません。資料やモデル、連携、担当者が変わるたびに、権限とテストを見直します。会話ログから未回答や不自然な利用を確認し、チャットボットだけでなく、FAQや商品ページも改善します。

小さく始めることは、対策を省略することではありません。扱う情報と機能を減らし、必要な対策を確認できる大きさにすることです。導入範囲を具体化する際は、導入手順、RAG、基礎知識、費用の記事もあわせて確認すると、機能と運用を整理しやすくなります。