AIサポートベンダーのセキュリティチェックリスト：2026年版・25の質問

TL;DR

AIサポートベンダーの審査は、通常のSaaS審査に3つの新しい質問を足したものです。モデルがチケットを読むとき、そのデータはどこへ行くのか。エージェントはヘルプデスクで何をしてよいのか。そして、あとからすべての返信とアクションを確認できるのか。SOC 2レポートは最初の層にはよく答えます。残りの3つにはほとんど答えず、多くの審査はそこで質問をやめてしまいます。

2026年10月20日に、AIを組み込んだヘルプデスクベンダー7社のトラストページを確認しました。ギャップは具体的です。SalesforceはAgentforceでデータマスキングをオフにしています。HubSpotのオーストラリアとカナダのデータセンターは、AI処理を米国に送ります。GorgiasはAI Agentが他のブランドのやり取りから学習すると述べています。侵害通知の期限は、Zendeskの48hから、7社中4社の "without undue delay"（時間の記載なし）までさまざまです。下の25項目のチェックリストはインタラクティブなので、ベンダーとの通話中にそのままチェックしていけます。

eeselの答えを率直に言います。SOC 2 Type II監査は進行中で（観察期間は2026年10月1日から12月31日、レポートは2027年）、AIヘルプデスクのチームメイトができるすべてのアクションは、自動、承認制、オフのいずれかに設定されています。規制対象の貸金業者であるsmavaは、月27,000件のZendeskチケットでこれを運用しており、ルールは1つです。"eesel never sends it itself."

なぜSOC 2レポートだけではAIサポートベンダーの審査に足りないのか？

私はeeselのエージェント側を担当しているため、セキュリティ審査担当者が最も厳しく見る部分に多くの時間を割いています。eeselはまさにこのチェックリストが原因で案件を失ったこともあります。Zendeskをお使いのアメリカのヘルスケアプラットフォームはBAAに署名できなかったため、デモの途中で話が止まりました。Freshdeskをお使いのあるポッドキャストプラットフォームはSOC 2が完了していなかったため進められませんでした。この2件が、eeselが日付入りの監査スケジュールを載せた公開トラストセンターを持つ大きな理由です。ですから、現状については正直にお伝えします。

そこで学んだことがあります。SOC 2レポートは、ベンダーが暗号化、アクセスレビュー、変更管理、インシデント対応といったシステム運用を慎重に行っていることを示します。AICPAのTrust Services Criteriaは、セキュリティ、可用性、処理の完全性、機密性、プライバシーを対象にしています。これは最低ラインで、必ず求めるべきです。

しかしAIサポートエージェントは別の種類のベンダーです。チケットを保管するだけではありません。読み、他社が運用する大規模言語モデルに送り、多くの構成では注文を返金したりアカウントを変更したりできます。SOC 2のどのカテゴリも「顧客があなたのボットを説得して返金させられるか」とは問いません。

AICPA自身も、バッジを集める発想に対して購入者に注意を促し始めています。SOC 2のトピックページは、2026年の記事 "Promises of 'fast and easy' threaten SOC credibility" へリンクしています。レポートを読み、日付を確認し、AI製品が実際に対象範囲に入っているかを確かめてください。そのうえでさらに踏み込みます。

幸い、2層目を一から作る必要はありません。フレームワークはすでにあります。

セキュリティチームがすでにSIGやCAIQを使っているなら、最初の通話の前にベンダーへ記入済みのコピーを依頼してください。1週間短縮できます。下のチェックリストは、監査人ではなくサポートリーダー向けの言葉で、その上に重ねたい項目です。

AIサポートベンダーのセキュリティチェックリスト

ベンダーが回答するたびに項目をチェックしてください。「重要」と付いた項目は、AIエージェントが本番の顧客チケットに触れる前のブロッカーとして扱うことをおすすめします。上部のカウンターが進捗を表示します。

この記事の残りでは、6つのグループを順に見ていきます。それぞれについて、よく知られたヘルプデスクベンダー7社が実際に公開している内容を取り上げます。Zendesk、Freshworks、Salesforce、HubSpot、Gorgias、Help Scout、Frontを選んだのは、AIがヘルプデスクの中にあるため、多くのサポートチームが最終的に読むのがこれらのトラストページだからです。

チケットで学習するのか？

これは誰もが最初に聞く質問ですが、答えは想像するほど揃っていません。実際には3つの別々の質問が隠れています。ベンダーが自社モデルをお客様のデータで学習させるか、背後のモデルプロバイダーが学習させるか、そしてお客様のデータが他の顧客のエージェントの役に立つか、です。

ほとんどのベンダーは、モデルプロバイダーについては明確です。Zendeskによれば、LLMの再委託先は "cannot use your Service Data to train their models" とされ、Frontは再委託先が顧客データを "to train foundation models" に使うことを禁じています。興味深くなるのは、ベンダー自身のモデルです。

• Zendeskは、トラストセンターによれば、識別子を除去するサニタイズ処理を経たサービスデータで、分類用の "generic, cross-account machine learning models" を学習させています。生成機能は別扱いです。
• Gorgiasは珍しく率直です。AI Agentのセキュリティ FAQは、"Our AI Agent does learn from interactions from other brands," と述べ、漏えいを減らす保護策があるとしています。この率直さは役に立ちます。同時に、競合のエージェントがお客様のチケット履歴の恩恵を受ける可能性があるということでもあり、受け入れるブランドもあれば、そうでないブランドもあるでしょう。
• Freshworksは学習のオプトアウトを提供しますが、Freddy AIのデータ処理フレームワークによれば、support@freshworks.comへのメールで行います。確認は書面でもらってください。

次に、モデルプロバイダー側の保持です。「ゼロデータ保持」とは、プロバイダーが回答を返したあと何も保持しないことを意味します。Zendesk、Salesforce、Frontは、いずれも生成機能についてこれを主張しています。Help ScoutのAI Assistのドキュメントは、OpenAIがデータを "for up to 30 days" 保存するとしています。30日は多くのチームにとって致命的ではありませんが、DPAがこの数字と一致しているべきです。

eesel側では、お客様のデータでモデルを学習もファインチューニングもしておらず、再委託先リストにある4つのオープンモデルのホストはゼロデータ保持で運用されています。Anthropic、OpenAI、Googleについては、API データでの学習を許可しない各社の商用API規約に依拠しています。この3社の保持期間を書面で必要とされる場合は、ブログ記事の言葉を信じるのではなく、セキュリティパックの一部として私たちに依頼してください。

チケットは実際にどこへ行くのか？

顧客からの1通のメールを想像してください。それはヘルプデスクに届き、AIベンダーに同期され、モデルプロバイダーに送られ、検索インデックス（多くはベクターデータベース）といくつかのログに保存されます。どの区間も、保持され、コピーされ、国境を越えて移動しうる場所です。

GDPRの第28条により、モデルプロバイダーは再処理者にあたり、ベンダーはお客様に通知して異議を述べる機会を与えずに追加することはできません。つまり再委託先リストは形式ではなく法的文書です。ここにはずれも現れます。GorgiasのFAQはAI Agentが "OpenAI, Anthropic, and internally fine-tuned LLMs" を使うと述べていますが、2026年3月30日に最終更新された再委託先リストでは、AIプロバイダーとしてOpenAIのみが挙げられています。Help Scoutのリストは2025年1月付けです。どちらも必ずしも誤りではありません（クラウド上でホストされたモデルは、法的にはそのクラウドプロバイダーの行に載ることがあり、これはまさにSalesforceがAnthropicの利用を説明している方法です）が、確認すべき質問です。

データレジデンシーはもう半分で、細かい注意書きはここにあります。以下はいずれもベンダー自身が文書化している内容です。

• HubSpot： オーストラリアとカナダのデータセンターについては、再委託先ページのAIプロバイダーの行がすべて "United States" になっています。EUのデータセンターでは、AI処理は欧州経済領域内にとどまります。
• Salesforce： リージョン内のエンドポイントが応答しない場合、"the request falls back to Azure OpenAI in the United States." これをオフにするには、まずData 360が必要です（ジオアウェアルーティングのドキュメントによる）。
• Freshworks： インド、オーストラリア、中東・アフリカのアカウントでは一部の機能が米国で処理されますが、"AI features that require data processing outside your primary hosting region are disabled" がデフォルトです。このデフォルトは良いものです。FreddyについてはFreshdeskのデータレジデンシーガイドもご覧ください。
• Zendesk： AIの利用は "does not impact any Customer data locality commitments," ただし、AI Agents - Advancedのような買収した製品は、トラストセンターによれば米国または欧州のGoogle Cloudに "may remain on" "for a period of time" とされています。
• Front： 米国またはEEAのホスティングを選べますが、ホスティングポリシーによれば、データは "as reasonably necessary" でその外でも "may be otherwise processed" とされています。

どれも隠されてはいません。すべてベンダー自身のページにあり、その点は評価できます。ただ、営業担当が送ってくるページにはありません。eeselでは、本番環境はデフォルトで米国（バージニア北部）のAWSで稼働しており、AI処理を含むEU内の完全なデータレジデンシーは、トラストセンターにあるとおりEnterpriseプランに紐づいています。思い込む前にプランを確認してください。

エージェントはヘルプデスクで何ができるのか？

最も時間をかけたいのがこのセクションです。実際の被害が起きるのはここだからです。OWASPはこれをExcessive Agencyと呼び、"unexpected, ambiguous or manipulated outputs" に反応して有害なアクションが取られることとしています。根本原因は3つで、機能が多すぎること、権限が多すぎること、自律性が高すぎることです。サポートに置き換えると、注文を調べるだけでよいのに返金までできてしまうエージェントです。

法的な面も追いついてきました。Moffatt v. Air Canadaでは、ブリティッシュコロンビア州の審判所が、チャットボット自身の発言の責任はチャットボットにあるという航空会社の主張を退けました。"It makes no difference whether the information comes from a static page or a chatbot." 損害額は小さく（合計$812.02 CAD）、審判所の判断であり拘束力のある判例ではありません。しかし原則は通用します。エージェントの発言と行動の責任は自社にあります。

そこでベンダーへの質問は具体的です。権限の一覧を見せてください。そして、取り消せないことが実行される前に何が起きるかを見せてください。

各ベンダーが文書化している内容は次のとおりです。

• Gorgiasは良いデフォルトを持っています。アクションのドキュメントによれば、注文のキャンセルや定期購入のスキップのような取り消せないアクションでは "Customer confirmation is turned on automatically," であり、オフにするには理解したことを確認する必要があります。詳しくはGorgias AI Agentのアクション解説をご覧ください。
• HubSpotは、カスタマーエージェントの各アクションに None、Match email、Verify email の保護レベルを与え、設定ガイドによれば、アカウントアクセスの変更は直接実行せず安全なリンクを送るよう勧めています。エスカレーション面はBreezeのガードレールガイドで扱っています。
• Salesforceは、エージェントが "respect standard Salesforce access controls" し、カスタムアクションは背後のフローまたはApexクラスの権限を継承します（Trust and Agentforceによる）。強力ですが、Salesforceの権限管理がそのままAIの権限管理になるということです。
• Freshworksは、エージェントが "stays within predefined flows" としています（Freddy AIトラストフレームワークによる）。管理画面ではそれがどう見えるのか、確認してください。

2つの異なる形に注目してください。GorgiasとHubSpotは顧客に確認を求め、人による承認キューは自社のチームに確認を求めます。顧客確認は、アカウント所有者ではない攻撃者を止めます。しかし、本物の顧客が喜んで受け入れる誤った判断、たとえばポリシー外の返金は止められません。お金が動くアクションについては、少なくとも最初の数か月は、自社チームの人間を介在させたいと考えます。サポートの承認ワークフローのガイドで、線をどこに引くかを詳しく説明しています。

ここがeeselで私が最もこだわる部分です。すべてのアクションは権限であり、エージェントごとに自動、承認制、無効のいずれかに設定します。アクションと承認のドキュメントは "refunds, cancellations and anything that costs money behind an approval" を推奨しています。承認はタイムアウト後に勝手に実行されることはなく、Viewerは承認できず、各承認には誰がいつ判断したかが記録されます。

審査担当者がここで確認すべきことがあと2つあります。1つ目は認証情報です。eeselでは、外向きのリクエストはNetwork Accessで許可したドメインにしか送られず、認証ヘッダーはサーバー側で付与されるため、"a manipulated agent can't read out a key or token because it never had one." です。2つ目は、それ以外のすべての入口です。eeselにはCLI（npx @eesel/cli）があり、人、スクリプト、Claude CodeやCursorのようなコーディングエージェントが、チームメイトとチャットし、ナレッジをアップロードし、自動化を設定し、eesel approvalsで承認キューを処理できます。すべてのワークスペースはModel Context Protocolサーバーでもあります。セキュリティ上のポイントは、CLIとMCPからの書き込みが "follow the same action permissions as everything else" であることで、保留中のアクションはどの入口から来ても保留のままです。どのベンダーにも、APIについて同じ質問をしてください。

権限と同じくらいスコープも重要です。米国のパスポート申請を支援するAdverscaleは、社内メモに人が@eeselと書いたときだけZendeskのエージェントを動かし、"She never decides a refund." としています。米国の州や大学と取り組む教育ソフトウェア会社XAPは、Freshdeskのエージェントの前にフィルターを置き、紹介案件とポータルのパスワードリセットだけが通るようにしています。

顧客のメールでボットを動かせてしまうのか？

可能性はあります。そして優れたベンダーは、免疫があると主張せずにそう認めます。OWASPはプロンプトインジェクションをリスク第1位に挙げ、注入された指示は "do not need to be human-visible/readable, as long as the content is parsed by the model" と指摘しています。サポートエージェントの場合、メール内の白い文字、PDF添付ファイル内の1行、汚染されたヘルプ記事などがそれにあたります。OWASPはまた、検索拡張生成やファインチューニングでは "do not fully mitigate" とも述べています。プロンプトインジェクションの用語集に、わかりやすい解説があります。

各ベンダーが文書化している内容は次のとおりです。

• Freshworksは、入力を "Azure AI Content Safety and Prompt Shields" でスキャンします（Freddy AIトラストフレームワーク）。
• Salesforceには "Prompt Defense" があり、システムポリシーとプロンプトインジェクション検知として説明されています（Trust and Agentforce）。
• Frontはトラストセンターに "Front AI Pentest 2026" レポートを掲載しており、これはすべてのベンダーに求めたい種類の文書です。
• Zendesk、HubSpot、Gorgias、Help Scoutは、私が確認したページではプロンプトインジェクションの防御を説明していません。存在しないという意味ではありません。聞く必要があるということです。

正直な答えは、フィルターはリスクを減らし、権限は被害の上限を決める、ということです。eeselのセキュリティFAQはこうまとめています。"the protection isn't that the model can't act. It's that what it can act on is bounded, and you set the bounds." オンにしていないアクションは、メールに何と書かれていてもモデルから利用できません。契約前に自分で試したい場合は、敵対的テストのガイドに試す価値のあるテストプロンプトがあります。

機密データは兄弟のようなリスクです。OWASPのSensitive Information Disclosureは、個人情報、金融情報、医療記録、認証情報を対象にしています。私が最もよく見る落とし穴は、ベンダーの個人情報マスキングがAIエージェントにも適用されると思い込むことです。Salesforceはここで率直です。パターンベースとフィールドベースのマスキングは "is disabled for agents," であり、プライバシーFAQは "to improve performance and accuracy of agents" と説明しています（Data Masking Limitations in Agentforce）。Zendeskの自動マスキングはEnterpriseプラン向けのADPPアドオンにあります。

eeselにも同じ基準を当てます。eeselの個人情報マスキングは、過去チケットを保存・インデックス化する前に15カテゴリ（カード、社会保障番号、銀行情報、APIキー、氏名、住所など）を対象にし、フェイルクローズで動作します。マスキングできないチケットはスキップされ、生のままインデックス化されることはありません。ただし、連携ごとのオプトインであり、新しいワークスペースではデフォルトでオフで、ライブの会話には適用されません。エージェントが返信を作成するためにチケットをライブで取得するとき、生のチケットがモデルに届きます。それが重要な場合は、DPAの議論に含めるべきです。より広い選択肢については、サポートの会話記録で個人情報をマスキングする方法のガイドをご覧ください。

あとからすべての返信とアクションを確認できるのか？

監査証跡は、「エージェントは正しく動いたと思う」を「チケット4,812でこれをして、理由はこうだった」に変えるものです。AIに関しては最も欠けやすい項目でもあります。一般的な管理者向け監査ログは普通にあります。AIが何をしたかのログは、そうではありません。

• Frontの監査ログは全プランにありますが、記載されているソースは Admin Copilot、API、Applications、SCIM、Teammates です。Autopilotは含まれていません。
• HubSpotのアクティビティ履歴は "only records HubSpot-user based actions."
• Zendeskの監査ログはEnterprise以上のプラン向けです。Custom Agentsについては、Zendeskは "how an agent arrived at its responses or decisions" が表示されるとしています。
• Salesforceは、プロンプト、レスポンス、トラストシグナルをData 360に記録し、Einsteinアドオン付きのEnterprise以上で監査証跡を提供します。書面上は7社で最も充実しています。
• Gorgiasは、FAQによれば "view every single answer AI Agent sends, including the knowledge sources it pulls from" ができます。

eeselでは、Activityがすべてのチャネルでのすべての実行を一覧にします。何がきっかけか、どのナレッジを読んだか、どのアクションを取ったか、その判断理由です。承認済み、却下、保留で絞り込めます。

稼働前の可視性も、稼働後と同じくらい重要です。私が見た中で最も安全な審査は、自社の解決済みチケットでエージェントを動かし、何も送信せず、セキュリティチームとサポートリーダーがデモ用の台本ではなく本物の回答を評価する形で終わります。eeselのシミュレーションレポートは、最近解決した20件のチケットでこれを行い、公開前のAIエージェントのテストとAIサポートのパイロット運用のガイドで残りを説明しています。これはAIのハルシネーションに対する最良の防御でもあります。XAPのエージェントは "never invents a URL, a fee, a date or a policy," で、詳細の根拠が取れないときはチーム向けのプレースホルダーを残します。

ヘルプデスクベンダー7社は書面上でどう比較されるのか？

各ベンダーのトラストセンター、DPA、ヘルプドキュメントから、書類面を1つの表にまとめました。2026年10月20日時点の確認です。"Not stated" は、公開ページで見つけられなかったという意味であり、存在しないという意味ではありません。

この表のうち2行は、もう一度見る価値があります。1つ目は侵害の期限です。GDPRの第33条は、管理者であるお客様に、監督当局へ通知するための72時間を与えていますが、処理者にはお客様へ "without undue delay" で知らせることしか求めていません。ベンダーの契約が同じ文言であれば、お客様が知る前に72時間の時計が動き出すことがあります。時間単位の数字を求めてください。

2つ目はHIPAAです。Help Scoutが別途AI Feature Healthcare Addendumを求めているのは、実は良いパターンです。医療分野の購入者が忘れがちな問いを突きつけるからです。BAAはAIをカバーしているのか、それとも受信箱だけなのか。HIPAA準拠のAIガイドとヘルスケア向けAIカスタマーサービスの記事でさらに詳しく扱っています。これらのヘルプデスクのいずれかをお使いの場合は、Zendeskのセキュリティとコンプライアンス、FreshdeskのSOC 2、GorgiasのSOC 2も詳しくまとめています。

リストに加えておきたい法律がもう1つあります。EU AI Act第50条は、人と対話するAIシステムに対し、明らかな場合を除き、AIと話していることを伝えるよう求めており、この義務は2026年8月2日から適用されています。EUの顧客に対応するなら、ベンダーがその開示を設定できるか確認してください。

プロジェクトを止めずに審査を進めるには？

AIツールのセキュリティ審査は、「ノー」ではなく順番待ちの中で消えていきがちです。私が進める順序はこうで、たいてい2週間以内に収まります。

1. 初日にパックを依頼する。 SOC 2レポートまたは監査スケジュール、DPA、再委託先リスト、記入済みのCSA AI-CAIQまたはSIG Lite。これらの送付に1週間かかるベンダーは、それ自体が何かを物語っています。
2. 上の重要10項目を通話で確認する。 学習、顧客横断の学習、保持、モデルプロバイダー、アクションごとの権限、お金が動く承認、プロンプトインジェクション、アクションログ、SOC 2の範囲。回答はあとで書面でもらいます。
3. 自社リージョンのデータ経路を描く。 上の図の5つの区間に、ベンダーの実際の回答を当てはめます。レジデンシーの例外はここで見つかります。
4. ドラフトモードでエージェントを開始する。 社内メモのみで、顧客には何も送りません。自治体や学校を顧客に持つデンマークのセキュアメールベンダーTimengoは、Freshdeskでこのようにeeselを運用しています。"The engineer sends; eesel does not."
5. 権限を1アクションずつ広げる。 ログを見ながら、まずタグ付けを自動にし、次に初回返信、そして返金は最も長く承認制のままにします。

そもそも購入するか迷っているなら、AIサポートの自社構築と購入が内製の道を扱い、審査に落ちたベンダーを置き換える場合はAIサポートベンダーの乗り換え方が役立ちます。AIサポートのパイロットスコアカードは、ステップ4を合格・不合格の数字にします。

セキュリティチェックリストを手にeeselを試す

ZendeskまたはFreshdesk向けのAIエージェントでこの審査を行うなら、eeselにも同じ審査を行ってください。eeselはAIヘルプデスクのチームメイトとして、Zendesk、Freshdeskなどのヘルプデスクの既存キューに参加し、すべてのアクションがお客様の管理する権限リストに載り、すべての実行が判断理由とともに記録されます。消費者向け金融比較サイトのsmavaは、1つのZendeskで2つのブランド向けにスコープを絞ったeeselエージェントを運用しており、"Each agent has one job and a list of things it must never do." としています。

トラストセンターには現在のステータスがあり、セキュリティパック（ポリシー、DPA、CAIQまたはSIG Liteの回答）はNDAのもとでご依頼に応じて提供しており、通常は1営業日以内です。料金ページから100クレジットで無料で始め、誰かが何かに署名する前に、自社の過去チケットでシミュレーションを実行することもできます。eeselを試す。