Gmailの代理アクセスをサポートチームで使う方法：設定、上限、限界が来る場所

TL;DR

Gmailの代理アクセスは、2〜3人ほどのサポートチームなら十分に機能します。 1人がsupport@のような受信箱を所有し、同僚を代理人として追加し、全員がそのアドレスから返信します。Workspaceアカウントでは最大1,000人の代理人を追加できますが、Googleによれば同時に利用できるのは約40人だけで、すべての返信は1日2,000通という共有の送信上限にカウントされます。本当の問題は、代理アクセスが全員にアクセス権を与える一方で、誰にも所有権を与えないことです。担当者割り当てなし、「誰かが対応中」という警告なし、返信時間のレポートもありません。

つらくなるまではラベルによるルールで回し、それから共有受信箱ツールに移行しましょう。定型的な質問なら、eeselが共有受信箱内で返信を下書きし、人が送信するだけにできます。CLIを使えば、コーディングエージェントがそれを設定し、先にテストすることもできます。

Gmailの代理アクセスはサポートチームでどう機能するか？

Gmailの代理アクセスを使うと、あるGoogleアカウントの所有者が、同じ組織内の他のメンバーにその受信箱へのアクセス権を与えられます。Googleの代理アクセスのヘルプページによれば、代理人は そのアカウントで「メールの読み取り、送信、削除」ができます。代理人がメッセージを送信すると、受信箱のアドレスの横に本人のアドレスが表示されます。

サポートチームの場合、設定は次のような形になるのが一般的です。顧客が書き込む1つのアドレス、たとえばsupport@yourcompany.comがあり、これは通常のGoogle Workspaceアカウントです。各担当者を代理人として追加します。各担当者は自分のGmailのアカウント切り替えから、別のタブでサポート用の受信箱を開き、そこから返信します。Googleの技術サポートチーム向けガイド自体も、まさにこれを勧めています。サポート担当者を代理人として追加し、「受信した問い合わせを確認して返信できるように」するという内容です。

私はeeselでインテグレーションを作っていて、他社のサポート体制の中で多くの時間を過ごしています。メールは多くの小規模チームがまず始める場所です。2026年3月、Gmailだけで複数の若い会社を運営していた創業者との営業電話で、eeselの共同創業者Amoghは、メールこそ世界最大のヘルプデスクであり、eeselはそれをきちんとサポートしなければならないと確信しました。こうしたGmailチームの多くが代理アクセスでサポートアドレスを共有しているのは、無料ですでに組み込まれているからです。

以下すべてを左右する、Googleのドキュメントからのいくつかの事実です。

• 仕事用と個人用のアカウントは異なります。 個人の@gmail.comアカウントは最大10人の代理人を追加できます。仕事用・学校用アカウントは最大1,000人です。
• 代理人は自分の組織に属している必要があります。 Workspaceでは、管理者向けヘルプページによれば、同じ組織内の人やグループしか追加できません。
• エイリアスは代理設定できません。 代替アドレスやエイリアスはGoogleアカウントではないため、そこに代理人を追加することはできません。サポート用アドレスは実在するアカウントである必要があります。
• 代理人が管理できるのはメールのみです。 パスワードの変更、そのアカウントとしてのChatの利用、アカウントのGoogle設定を開くことはできません。

鍵となる言葉は「共有」です。代理アクセスは全員に同じ部屋の鍵を渡します。どのメールが誰のものかまでは教えてくれません。

サポート用受信箱にGmailの代理アクセスを設定するには？

手順は2つに分かれます。管理者が組織向けに代理アクセスを有効にし、その後、誰かがサポート用受信箱に担当者を追加します。管理者の変更も新しい代理人のアクセスも有効になるまで最大24時間かかるとGoogleは述べているため、1日分の余裕を見ておきましょう。

ステップ1：管理者としてメールの代理アクセスを有効にする

Google管理コンソールで、Googleの管理者向け手順に従い、アプリ > Google Workspace > Gmail > ユーザー設定 > メールの委任に進みます。Gmail設定の管理者権限が必要です。そのうえで：

1. ユーザーが同じドメイン内の他のユーザーに受信箱へのアクセス権を委任できるようにするにチェックを入れます。組織全体に適用することも、サポートチームのような1つの組織部門だけに適用することもできます。
2. デフォルトの送信者情報を選びます。アカウント所有者とメールを送信した代理人の両方を表示にすると、両方のアドレスがメッセージに表示されます。アカウント所有者のみ表示にすると担当者は表示されません。
3. 任意でユーザーがこの設定をカスタマイズできるようにするにチェックを入れると、サポート用受信箱自身でこの設定を選べるようになります。
4. 任意でユーザーが受信箱へのアクセス権をGoogleグループに付与できるようにするにチェックを入れます。これにより、support-team@のようなグループ全体を1人の代理人として追加できます。
5. 保存をクリックします。

このグループのオプションには、多くの人がつまずく落とし穴があります。サポート用受信箱の組織部門と、グループの各メンバーの組織部門の両方でこの設定が有効になっている必要があります。自分の組織部門で有効になっていない人は、グループに入っていても受信箱を開けません。

ステップ2：サポート用受信箱を作成または選択する

まだサポート用アカウントがない場合、Googleの共有受信箱のページが管理者を手順に沿って案内します。管理コンソールのユーザーで共有メールアドレスを設定をクリックし、アドレスを入力し、アクセスが必要な人を追加します。Googleはこれを Business Starter、Business Standard、Business Plusで提供しています。既存のアカウントを変換することもでき、support@がこれまで1人のログイン用だった場合に便利です。

ステップ3：各担当者を代理人として追加する

サポート用受信箱自体から、パソコンで操作します(Gmailアプリではできません)。

1. 設定 > すべての設定を表示 > アカウント(またはアカウントとインポート)を開きます。
2. 自分のアカウントへのアクセス権を付与の下で別のアカウントを追加をクリックします。
3. 担当者のメールアドレスを入力し、次のステップをクリックし、続いてアクセス権付与のメールを送信をクリックします。

Googleは代理人を追加する前に本人確認を求めます。各担当者には1週間で期限切れになる招待が届くので、見逃さないよう伝えておきましょう。

ステップ4：担当者に受信箱の開き方を示す

担当者が招待を承認すると、Gmailでプロフィール画像をクリックし、委任されたアカウントと表示されたアカウントを選びます。新しいタブで開きます。Googleのこのアドバイスは「急に使えなくなった」という問い合わせを大きく減らせます。委任された受信箱をブックマークしないことです。リンクが変わることがあるためです。毎回アカウント切り替えを使ってください。

何十もの受信箱を管理している場合、開発者はGmailのAPIのdelegatesリソースを使ってステップ3と4をまとめて行えます。この方法にはドメイン全体の権限を持つサービスアカウントが必要で、メールでの招待は不要になります。APIで作成された代理人はその場で承認済みになります。

Gmailの代理アクセスの上限は？

目を引く数字である1,000人の代理人に実際に達することはほとんどありません。サポートにとって重要なのは、同時利用の上限と共有の送信上限の2つです。

このうち2つは詳しく見る価値があります。

同時約40人、ツールを追加すればさらに減る。 Googleによれば、代理人の利用が平均より多い場合や、「頻繁にGmailにアクセスする自動化されたプロセス」(APIやブラウザ拡張機能と定義されています)があると、この数字は下がります。つまり、受信箱に問い合わせるあらゆる追加ツール(CRM同期、レポートツール、AIアシスタント)が、担当者が使うのと同じキャパシティを消費します。Googleはまた、多くの人が別々の場所から1つのアカウントにサインインすると、Gmailがアカウントを一時的にロックすることがあるとも警告しています。サポート用受信箱にとって、忙しい朝のロックアウトは想定しておくべき障害です。

送信上限は全員で1つ。 Googleは「代理ユーザーによって送信されたメッセージ」をアカウントの上限にカウントされるメッセージの1つとして挙げています。代理アクセスは「Gmailアカウントの上限を増やすものではありません」。つまり5人の担当者がいても、1日あたり2,000通の5倍を使えるわけではありません。全員で1つの予算を共有します。同じアドレスから注文更新やニュースレターも送っているなら、それもここから出ていきます。上限に達すると、受信箱は最大24時間、新しいメールを送信できなくなります。

APIガイドの25という数字は、代理人をスクリプトで設定するなら知っておく価値があります。ヘルプセンターとAPIガイドでは上限が異なり、自動化するものについては私なら低い方の数字で計画します。

委任された受信箱で働く担当者は何を失うのか？

これはほとんどのチームを驚かせます。Googleはセキュリティとプライバシーのために、代理人向けに一連の機能をオフにしていて、その中には担当者が自分の受信箱で頼っているであろう執筆補助機能も含まれます。Googleのリストによると、代理人が使えないのは以下です。

• Gmail内のGemini
• スマートリプライとスマートコンポーズ
• スペルと文法のチェック、自動修正、自動補完
• Driveからの添付やGoogleフォトからの写真の追加
• タスクへの追加、Gmail内のChat、Gmail内のMeet
• 絵文字リアクションとクライアントサイド暗号化

スマートフォン向けGmailアプリでは、代理人は通知設定、ナッジ、会話の要約、バックグラウンド同期も失います。

つまり、チームが1日中顧客に向けて書いている受信箱こそが、Geminiの文章作成サポートやスペルチェックを使えない唯一の場所になるということです。返金に関する返信でのタイプミスは小さなことです。それが週に20件あれば目立ってきます。自分の受信箱で下書きしてからコピーするチームもあり、これはうまくいきますが、返信のたびに1手間が増えます。チームがGoogle Workspace向けGeminiに頼っている場合、それが止まるのは委任されたタブだと知っておいてください。

サポートチームにとってGmailの代理アクセスはどこで限界に来るのか？

代理アクセスは、ある役員のメールを管理するアシスタントのために設計されたものです。サポートのキューはそれとは別の仕事です。多くの人、多くの会話があり、それぞれで誰かが待っています。ここにその差が現れます。

誰もメールを所有していない。 すべての代理人が同じ受信箱を見ます。Gmailには担当者を割り当てるフィールドがないため、2人の担当者が同じクレームを開いて両方が入力を始めることがあります。2人目に何も警告はありません。顧客は2通の返信を受け取り、時には内容が異なることもあります。

ステータスがない。 メールは既読か未読か、アーカイブ済みかそうでないかしかありません。「顧客の返答待ち」や「対応中」はないため、チームは星印、ラベル、共有スプレッドシートで即席の対応をします。Google自身のサポートガイドも、依頼や担当の割り当てをGoogleスプレッドシートで追跡することを勧めており、これは受信箱単体ではそれができないことを物語っています。

既読状態が共有される。 全員が同じ受信箱で作業するため、共有受信箱の既読にする設定によっては、1人の担当者がメールを開くとチーム全体で既読になることがあります。忙しい日には、誰かがざっと見て放置しただけのメールが、対応済みに見えてしまうことがあります。

キューを測定できない。 初回返信時間も、未対応メール数も、担当者ごとの数値もありません。顧客に指摘されるまで、キューが悪化しているかどうか分かりません。返信時間の目標がある場合(私のSLAのベストプラクティスを参照)、代理アクセスだけではそれを確認する手段が何もありません。

アクセスの削除は手作業です。 代理人を削除できるのは受信箱側だけです。Googleは「アカウントのパスワードが期限切れになっても、代理人は引き続きアカウントにアクセスできる」と述べており、オフボーディングとは自分のアカウントへのアクセス権を付与の下でその人を削除することを意味し、パスワードのリセットだけでは不十分です。逆方向にも同じことが言えます。追加された人は簡単には自分で抜けられません。あるHacker Newsのスレッドは、何年も受信箱から抜けられなかった代理人の話を伝えています。

"multiple chats with Google support reps have indicated that the only way to do this is by contacting the account admin and asking to be removed."

kkoppenhaver, Hacker News

これは代理アクセスが悪い選択だということではありません。1日20通のメールに対応する2人にとっては、無料で、速く、十分です。ただキューへとスケールしないだけで、その亀裂は3人目か4人目の担当者あたりから現れ始めます。

互いにぶつからずに委任されたサポート受信箱を運用するには？

当面プレーンなGmailのままにするなら、いくつかの社内ルールでほとんどの隙間を塞げます。どれも新しいソフトウェアは必要ありません。

1. ラベルをオーナーとして使う。 Owner/MariaやOwner/Samのようなラベルを作ります。受信箱の第一のルールは、返信を書き始める前に自分の名前でメールにラベルを付けることです。他の全員はラベル付きのメールを飛ばします。手動の担当割り当てであり、全員が守れば機能します。
2. ラベルをステータスとして使う。 顧客の返答待ちやエスカレーション済みを追加します。メールが本当に終わったときだけアーカイブし、受信箱自体を未対応キューにしておきます。
3. 「送信者」表示をオンのままにする。 管理者のデフォルトをアカウント所有者とメールを送信した代理人の両方を表示のままにしておきます。誰が何に返信したかを示す唯一の記録です。
4. 明らかなものにはフィルターを設定する。 Gmailのフィルターは、請求関連のメールや注文に関する質問、「至急」を含むものなどを、届いた時点でラベル付けできます。Googleのサポートガイドもこれを勧めています。担当者は1つの長い受信箱をスクロールする代わりに、ラベルごとに作業できるようになります。
5. 返信ライブラリを持つ。 代理人はスマートコンポーズを使えないため、よくある回答を共有ドキュメントに入れるか、メールテンプレートを使い、返信を一貫させましょう。
6. 当日のうちにオフボーディングする。 「support@の代理人から削除する」を退職者チェックリストに加えます。

これらのルールは、担当者が一握り程度までは機能します。それを超えると、ラベル付けの規律は最も忙しい日にこそ緩みがちで、まさにそれが最も必要になる瞬間です。

サポートチームはいつGmailの代理アクセスを卒業すべきか？

メールの所有者が誰か、どんな状態か、どれくらいの速さで返信しているかを知る必要が出てきたら、移行のタイミングです。これは代理アクセスが与えてくれない3つのことであり、どんなラベルの仕組みもそれを完全には再現できません。

現実的な次の一手は3つあります。

真ん中の行がもっとも穏やかな一歩です。Hiverのようなツールは、チームがすでに知っているGmailの画面そのものに、オーナーシップとステータスを追加します。Hiverの料金ページでは、年払いで1ユーザーあたり月額、Growthが25ドル、Proが55ドル、Eliteが85ドル(月払いでは35ドル、65ドル、95ドル)となっています。各プランの内訳はHiverの料金ガイドで解説しています。

ツールを比較しているなら、まずHiverの代替ツールのリストから始めてください。Freshdeskも座席ごとの料金を公開しており、Freshdeskの料金で取り上げています。

このスクリーンショットは、そのギャップを一枚の画像で示しています。Unassigned、Mine、Due Soon SLAsは、まさに単純な代理アクセスでは得られないビューです。より大きな移行を検討しているなら、私の共有受信箱 vs チケットシステムの記事で、本格的なキューがいつ見合うかを扱っており、共有受信箱ソフトまとめで分野全体を比較しています。

Frontはまた少し違った動き方をします。私のFrontの共有受信箱のオーナーシップの記事で、その割り当てルールの挙動を説明しています。

委任されたGmail受信箱でAIはどこに当てはまるのか？

座席を追加したりツールを乗り換えたりする前に、受信箱の中身を実際に見てみましょう。その大半が同じいくつかの質問(注文はどこか、返金はどうすればいいか、プランは変更できるか)なら、それらこそが溜まって二重返信を引き起こすメールであり、AIが下書きできるものです。

サポート用受信箱につながったAIエージェントは、その負荷を引き受けられます。eeselのGmail連携がやっているのはまさにこれです。Googleサインインで共有受信箱を接続すると、エージェントがメールを検索し、スレッド全体を読み、返信を下書きまたは送信し、ラベルを追加できるようになります。ヘルプセンターやポリシー、他の接続済みソースに加えて、メール自体を元に返信します。

委任された受信箱に特に合う理由がいくつかあります。

• 送信ではなく下書きができる。 下書き作成をオンにし、メール送信をオフにしておけば、すべての返信は担当者が確認して送信するまで下書きフォルダで待機します。これにより、すべてのメールに人が関わる体制を保ちながら、タイピングの大部分を取り除き、代理人が失う執筆補助もカバーします。
• ラベルがキューになる。 ラベル付き新着メールトリガーは、選んだラベルでのみ発火します。担当者がメールにAI下書きのラベルを付ければ、エージェントがそれを拾います。あるいはフィルターがラベル付けを行い、定型的なケースには誰も触れずに済みます。
• 検索で範囲を絞る。 検索一致の新着メールトリガーはlabel:support -from:meのようなGmailクエリを受け取るため、選んだメールだけに触れます。
• 接続した受信箱だけを担当する。 そのアカウントとして送信し、その受信箱が見られる範囲だけを見ます。

正直な限界も2つあります。新着メールはポーリング間隔でエージェントに届くため、返信は即座ではなく短い遅延を伴います。また、受信箱を読む自動化されたプロセスである以上、Googleが同時に利用できる代理人の数を減らしうると述べているタイプのツールに当たります。4人のチームならそれは問題になりません。40人に近づくチームなら、いずれにせよ共有受信箱ツールかヘルプデスクに移行するでしょう。

この「先に下書き」というパターンは、eeselの顧客がヘルプデスク上で使っているのと同じものです。バンクーバーの文房具ブランドSTIL Classicsは、eeselがShopifyの注文を確認した後、各チケットに下書きの返信を得て、人がそれを確認して送信します。月430件の下書き返信です。スイスの小さなスーツケース店Koffer.chは、顧客が書いた4つの言語のいずれかで下書きを受け取り、人がそのすべてを送信します。どちらのチームも既存の体制を保ったまま、AIを上乗せしただけです。

開発者やAIコーディングエージェントがこれを設定する場合、eesel CLIでeesel integrations connect gmail_pipedreamを実行すれば、Googleサインインのリンクが表示され、その後自動化を作成してテストできます。サインイン自体は、サポート用受信箱へのアクセス権を持つ人が承認する必要があります。

より広い視点には、私のGmail向けAIアプリのまとめをご覧ください。エージェントの視点を特に知りたい場合はAIメールエージェントのガイドがさらに深く扱っており、メールチケットシステムのガイドは共有受信箱から完全に移行する際に何が変わるかを説明しています。

共有Gmail受信箱でeeselを試す

チームがsupport@を代理アクセスで共有していて、いつも同じ5つの質問につまずいているなら、eeselはその受信箱のためのチームメイトです。各スレッドを読み、ヘルプドキュメントとポリシーを確認し、担当者が確認して送信する下書きを残すので、受信箱はGmailのままで、すべての返信に人が関わり続けます。インテグレーションページから数分で接続し、まずは自分宛てのメールで試してみてください。eeselを試す。