サポートエージェントのアクセス制御：ロール、権限、そしてAI用シート

サポートエージェントのアクセス制御がカバーするもの

多くのチームはアクセス制御を「エージェントか管理者か」で考えます。実際には4つの層があり、どれか1つに穴があれば残りの3つが無意味になります。

私はRamaで、eeselのヘルプデスク連携を作っているため、毎週の多くをこうした権限画面の向こう側で過ごしています。eeselがヘルプデスクに接続するたびに、スコープを要求し、実在するエージェントのロールの中で動く必要があります。たとえばZendeskでは、eeselの返信は接続を承認したZendeskユーザーとして投稿されるため、そのユーザーのZendeskロールがAIにできることの絶対的な上限になります。これがこの記事全体を通じた視点です。アクセス制御は、初日に設定するシートと同じくらい、忘れられがちなシートについての話でもあります。

顧客やブランドを分離している場合、可視性の層はマルチブランドのカスタマーサポートやクライアント別ナレッジベースと重なりますが、ここでは繰り返しません。

チケットの範囲設定がアクセス制御と同じではない理由

チケットの範囲設定は、多くの人が「エージェントは自分のチケットだけを見られる」と言うときに指している設定です。Zendeskの選択肢は、すべてのチケット、エージェントのグループ内のチケット、所属組織のチケット、割り当てのみです。FreshdeskはGrowth以上で、すべて、グループ、割り当てのチケットから選べます。

これを必要とするチームの例を、部門を分けることについてのr/Zendeskのスレッドから紹介します。

"the agents would belong to different business divisions under the same overall company. They'd work on tickets that employees submit with sensitive data so this is why we want the agents in one division not to have access to see another agent group's tickets and so on"

u/Quirkyordinaryy, r/Zendesk, Reddit

範囲設定は正面玄関を守ります。ベンダーのドキュメントには、少なくとも3つの勝手口が記載されています。

• CC。 Zendeskによると、エージェント（ライトエージェントを含む）をCCに入れると、チケットへのアクセス権に関係なく、公開・非公開のすべての更新がメールで届きます（Zendeskの標準ロール）。機密性の高いチケットにCCを1件入れるだけで、そのやり取りについては範囲設定が意味をなさなくなります。
• 管理者。 管理者はすべてを見られます。Zoho Deskははっきり書いています。共有設定がPrivateでも、「support admins can view all the tickets within a department」（Zohoのデータ共有ルール）。つまり、意図していたかどうかにかかわらず、管理者リストは可視性ポリシーの一部です。
• AIによる下書き。 Zendeskのauto assistは「may generate text replies based on that content for agents and end users who don't belong to the related user segment」とされています。言い換えると、制限されたヘルプセンターのコンテンツが、その記事を開けないはずのエージェントに届くことがあります。デフォルトでは、すべてのグループでauto assistが有効です（auto assistの設定）。

2つのヘルプデスクは、限界についてよりはっきり書いています。Help Scoutは受信箱単位で範囲を決め、ドキュメントには「There is no method to restrict individual conversations」とあります（Help Scoutのロール）。GorgiasはObserverを含むすべてのロールに「View tickets」権限と、すべてのオープンチケットを表示するデフォルトビューを与えており、チケットを開くことへの厳格なブロックは記載されていません（Gorgiasのユーザー権限）。単一ブランドのチームであれば、どちらも間違いではありません。ただ、分離はロールではなく、別々の受信箱やアカウントで実現する必要があるということです。

各ヘルプデスクで制御できること

初めてこれを整理したときに欲しかった並列比較がこちらです。価格は2026年10月時点の各ベンダーの料金ページにあるエージェント1人あたり月額で、ページに両方ある場合は年払いです。

出典：Zendesk、Freshdesk、Gorgias、Help Scout、Front、Zoho Desk、HubSpot。

いくつかのセルには補足が必要です。ZendeskとZoho Deskは全プランでIP制限を含み、Zendeskではエージェントも管理者もこれを回避できません（ZendeskのIP制限）。Frontの監査ログは全プランで365日分の履歴が残り、Admin Copilot、API、アプリによる変更も記録されます（Frontの監査ログ）。これは珍しく手厚い内容です。そしてEnterpriseのZendeskは標準のエージェントロールを完全になくすため、すべてのエージェントのアクセスはカスタムロールから決まり、上限はアカウントあたり197個です。

Frontのカスタム権限セットは、ボタン単位の「最小権限」がどういうものかをよく表しています。Front自身の例は、研修中のメンバーが共有受信箱で下書きを作れるようにしつつ、研修を終えるまで「Send messages」をオフにしておくというものです。

ベンダーごとの詳細は、Zendeskのロールガイドが権限の全リストを順に説明し、Freshdesk版がスコープを扱っています。Gorgiasにも独自のロール解説があります。

最小権限のコストはどれくらいか

表から見えるパターンは、きめ細かいロールは上位プランの機能だということです。各ヘルプデスクでカスタムロールが最初に使えるようになるプランは次のとおりです。

同じr/Zendeskのスレッドで、あるZendeskコンサルタントが、下位プランでこれが何を意味するかをまとめていました。

"Groups (even normal) can do this. As long as agents access is set to "Only tickets in their group". Admins will be able to always see all tickets but agents get locked down as long as Access is set that way. If in Enterprise custom roles is how you handle this."

u/TOOtall_G, r/Zendesk, Reddit

Frontはこの不満を何年も受けてきました。2022年のCapterraのレビュー（引用されている価格は当時のもので、現在のものではありません）はこう述べています。

"basic features like a user and team management are exclusive to the highest tier. For this even managing just a few users and their permission and settings is a real pain as long as you're not willing to upgread to the highest tier"

Verified Reviewer, CPO, Food & Beverages, Capterra

プライバシー制御は最もコストがかかります。エンドユーザーの名前、メールアドレス、電話番号をロールから隠すZendeskのデータマスキングは、Advanced Data Privacy and Protectionアドオンに含まれ、Enterpriseプランにのみ非公開の価格で販売されています（Zendesk ADPP）。同じアドオンには、誰がどのチケットを閲覧したかを90日間記録するアクセスログも含まれます。

率直な見解です。ロールごとの権限が必須要件で、Zendesk Enterpriseの予算がないなら、この比較の中で最も安く一通りそろうのはFreshdesk ProとZoho Desk Professionalです。すでにZendeskのSuite Professional（115ドル）を使っているなら、グループと割り当てのみの範囲、短い管理者リスト、IP制限で、かなりの部分までカバーできます。ロールのためだけにアップグレードする前に、Zendeskの料金とFreshdeskの料金の解説を確認してください。

一般的なサポートチームのために私が設定するロール

多くのチームに必要なのは15種類ではなく、5つのアクセスの形です。私ならこの構成から始めます。

最も時間をかけたいのは契約者の行です。Coinbaseが2025年5月に、海外のサポート担当者が買収されて顧客データを持ち出したと公表した後、Hacker Newsのスレッドでは何度も同じ原則に話が戻りました。

"That's not how front line support agent access should work. You get access based on active cases you are working on, not the keys to the kingdom because you might need to support a member at some future point in time."

lavezzi, Hacker News

PCIレベル1の決済会社で管理画面を作ったという別のコメント投稿者は、米国外で採用を始めた際に追加した制御をこう説明しています。「logging, monitoring and also rate-limiting (ask for manager to approve if more than 5 full details requests, etc.)」（vasusen, Hacker News）。この最後の部分、しきい値を超えたら承認が必要という仕組みは、AIについて後で触れるのと同じパターンです。BPOと協業している場合は、カスタマーサービスのアウトソーシングとオフショアサポートへのナレッジ移管のガイドが残りの設定をカバーしています。

軽量シートの行では、ヘルプデスクが提供する最も安い閲覧とコメントのシートを選びます。ZendeskはSuite Professionalに最大100人のライトエージェントを含み（ライトエージェントのシート）、Freshdeskのコラボレーターは公開返信やチケットプロパティの編集ができず（Freshdeskのコラボレーター）、HubSpotの閲覧専用シートは有料プランで無料かつ無制限です（HubSpotのシート）。

スレッドを読んでメモを残すだけのエンジニアや経理担当には、フルのエージェントライセンスは不要です。これについては部門横断のサポートエスカレーションで触れました。

退職時の対応：アクセスが残る場所

アクセス制御は、入口よりも出口で失敗しがちです。どのヘルプデスクでもユーザーを削除できます。違いは、そのユーザーのチケット、オートメーション、そして請求がどうなるかです。

出典：Zendesk、Freshdesk、Gorgias、Help Scout、Front、Zoho Desk、HubSpot。

誰かの最終出社日の前に知っておきたい落とし穴が3つあります。

• Help Scoutでは順序が重要です。 退職者の会話を特定の人に引き継ぐには、先にWorkflowを実行する必要があります。「There is no way to do this after the user has been deleted」とあるためです（Help Scout）。
• 連携は本人とともに壊れます。 Zoho Deskによると、無効化されたエージェントが設定した連携は、管理者が再承認するまで動作しません。Zendeskも、退職者の認証情報で設定したアプリは壊れる可能性があると警告しています。AIを含め、連携が誰のログインで動いているかを常に把握しておきましょう。
• データも一緒に消えます。 Zendeskのエージェントを降格すると、そのCSATデータと個人用マクロが失われ、Gorgiasのユーザーを削除すると統計が削除されます。必要なものは先にエクスポートしてください。

より静かな失敗は、権限がどう設定されたのかを誰も覚えていないことです。あるZendeskユーザーが2026年4月にこう投稿しました。

"We had some turnover in IT so no one who set up Zendesk/my account for our team are here still and I can't figure out how to add it as an option for them."

u/Accountant8622, r/Zendesk, Reddit

ロールの設定を書き留め、四半期に一度は監査ログを読みましょう。ZendeskはEnterpriseでログを無期限に保管し、すべての変更について実行者、IPアドレス、アクティビティの種類を記録します（Zendeskの監査ログ）。Zendeskの監査ログガイドには、項目ごとの解説があります。

Gorgiasでは、監査ログに12か月分のイベントが保管されます。臨時シートの季節採用については、季節サポートのオンボーディングの記事で各ヘルプデスクのルールを扱っています。

AIエージェントにもロールが必要です

多くのアクセスレビューが見落とすのがここです。AIサポートエージェントはチケットを読み、ナレッジベースを検索し、多くの構成では返信、タグ付け、クローズ、返金まで行います。社内で最も手の速いチームメンバーであり、その日たまたま管理者権限を持っていた人が設定していることも少なくありません。

ベンダーのドキュメントを見ると、現状がいかにまちまちかがわかります。

• Zendesk： デフォルトでは、どのSupport管理者もAIエージェントのClient管理者です（ZendeskのAIエージェントアクセス）。顧客向けのAIエージェントはユーザーセグメントを尊重しますが、エージェント側のauto assistは、前述のとおり尊重しません。
• Freshdesk： AIエージェントの作成には管理者アクセスが必要で、AIエージェントは全ユーザーに公開されている記事からのみ学習するため、制限されたコンテンツは完全に除外されます（Freshdeskのナレッジソース）。
• Gorgias： AI Agentを管理できるのはLeadとAdminだけですが、すべてのロールがその返信を見られます（Gorgiasの権限）。
• HubSpot： カスタマーエージェントには「Customer agent editor」権限が必要で、作成後は「it can't be deleted」とされ、一時停止しかできません（HubSpotのカスタマーエージェント）。
• Front： AI設定はワークスペース管理者プリセットにのみ含まれ、個別の権限としては提供されていません（Frontのチームメイトグループ）。

私が調べた7つのベンダーのうち、AIエージェントが個々のエージェントのチケット範囲を尊重するかどうかを文書化しているところはありません。したがって最も安全な前提は、AIは自分の接続が見られるものを見られるということで、その制御は接続で行います。

顧客データへのAIエージェントのアクセスについてのr/AI_Agentsのスレッドに、良いアドバイスがありました。

"You should treat an agent like you would any user: limit access via end points and only give them access to the endpoints they absolutely need. So avoid full/broad access as much as possible."

u/JustKiddingDude, r/AI_Agents, Reddit

これは、私が購入検討者から聞く話と一致します。GorgiasとShopifyを使い、月に約7,000件のチケットを扱うDTCサプリメントブランドのCX責任者は、eeselとの営業通話ではっきりこう言いました。

"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

そこで私は、AIエージェントのアクセスを3つの独立したダイヤルと、アクションごとの権限レベルで考えています。

1. ナレッジ。 必要なソースだけを接続します。ある部門のエージェントが別の部門のチケットを見られないなら、その部門に応答するAIもそこから学習すべきではありません。
2. アクション。 すべてのアクションを一覧にし、それぞれを自動、承認が必要、オフのいずれかに設定します。注文の照会はリスクが低いですが、返信の送信や返金の実行はそうではありません。少なくとも、AIがそれらを正しく行うのを確認するまでは。
3. ネットワーク。 AIが自社のAPIを呼び出す場合は、必要なドメインだけを許可し、認証情報はモデルの手の届かないところに置きます。

eeselのAIヘルプデスクチームメイトはこのように作られています。各アクションはエージェントごとに「自動」「承認が必要」「無効」のいずれかに設定され、承認はタイムアウト後に自動実行されることはありません。承認できるのはワークスペースのOwnerとEditorだけで、Viewerはエージェントの作業を読めますが、エージェントはViewerに代わって書き込みアクションを行いません（eeselのアカウントロール）。外部への呼び出しは、Network Accessに追加したドメインにしか届かず、エージェントが目にするのは「only ever sees the name of the header, never its value」なので、APIキーはモデルに渡りません。

同じ権限はターミナルからも適用されます。eesel CLIはダッシュボードと同じエージェントを操作し、eesel integrations zendesk actionsはすべてのZendeskアクションを承認設定付きで出力するため、1つのコマンドで、あるいはClaude Codeのようなコーディングエージェントに任せて、エージェントの権限を監査できます。CLIからの書き込みも同じルールに従い、Viewerの書き込みは常にEditorの承認待ちになります。--dry-runを使うと、何かが送信される前に、書き込みが行う正確な呼び出しを確認できます。

eeselのドキュメントでは、監督付きで始める：返信と元に戻せない操作は「承認が必要」に、返金とキャンセルはずっと承認の後ろに置くことを勧めています。多くのチームは内部メモから始め、エージェントが実績を示すにつれて任せる範囲を広げます。新入社員が歩む道と同じです。その道のりの人間側については、AIサポートエージェントのオンボーディングのガイドで順を追って説明しており、AIエスカレーションでは引き継ぎルールを扱っています。

eesel側についての正直な注意点があります。PIIの削除処理は、インデックス化する前の過去のチケットに対して行われますが、エージェントが返信を下書きするためにZendeskの最新のチケットを取得する際は、生のチケット内容がモデルに届きます。その時点でカード番号をマスクすることが必須要件なら、Zendeskのチケット墨消しのように、ヘルプデスク自体の墨消し機能とeeselを組み合わせてください。

四半期ごとのアクセスレビューのチェックリスト

アクセスは時間とともにずれていきます。人はチームを移り、契約者は去り、誰かが「今日の午後だけ」管理者になります。私なら四半期ごとにこれを行います。

1. 管理者を数える。 ほとんどのチームは2人で十分です。管理者が増えるたびに、全チケットを見られる人が増えます。
2. シートと名簿を照合する。 退職したのにシートを持ち続けている人は、セキュリティ上の穴であり、費用項目でもあります。とくにシートの課金が続くZendesk、Front、Zoho Deskでは重要です。
3. 契約者と外部委託のシートの範囲を確認する。 割り当てのみまたは1グループで、エクスポートなし。
4. 監査ログを読む。 ロールの変更、エクスポート、新しいIPアドレスからのサインインを確認します。
5. AIエージェントを他のシートと同様にレビューする。 どのソースか、どのアクションが自動か、接続は誰のログインで動いているか。システムアクセス申請のためのAIの仕組みがあるなら、同じ質問をしてください。

コンプライアンスの強化も並行して進めるなら、サポートチャットボット向けのSOC 2とGDPRのチェックリストと、Zendeskのセキュリティの概要が次の読み物として役立ちます。

範囲を絞ったAIチームメイトとしてeeselを試す

ヘルプデスクがZendesk、Freshdesk、Gorgias、Help Scout、Frontのいずれかで、AIのシートが最も不安な部分なら、eeselのAIヘルプデスクチームメイトはまさにそのために作られています。Zendesk連携（またはFreshdeskとGorgias）を通じて既存のキューに参加し、あなたが接続したソースだけを読み、あなたがオンにしたアクションだけを実行します。ツールを接続しただけでは何も変わりません。トリガーを追加するまで、オートメーションはオンにならず、返信も送信されません。

AIが触れたすべてのチケットは、何を検索し、何を行い、誰がなぜ承認したかとともにActivityに表示されます。また本番稼働の前に、シミュレーション機能があなたの実際の過去のチケットを再生するので、回答を先に確認できます。料金は全プランでエージェントとシートが無制限で、100クレジットの無料枠から始まり、その後は500クレジットで月額$299からです。そのため、AIを見守るレビュアーを追加しても、1人ごとにライセンス費用がかかることはありません。まだできていないこと：SOC 2 Type II認証の取得です（セキュリティページによると進行中です）。また、強制2FA付きSSOは月額$199からのアドオンです。内部メモから始めて、実績を積みながら任される範囲を広げていくAIをお探しなら、eeselを無料で試してください。