「過去のメールを探すのに時間がかかる」——業務時間の使い道を聞くと、必ず上位に出てきます。検索窓にキーワードを入れて、ヒットした数十件を上から開いていく。あの時間です。
ここは生成AIが効きやすい領域です。ただし「Gmailを連携すれば賢く探してくれる」わけではありません。実装してみると、精度を決めているのはAIの性能ではなく、渡す前のデータの状態でした。
キーワード検索とAI検索は、探しているものが違う
Gmailの標準検索は文字列の一致で探します。「見積」と入れれば「見積」を含むメールが出る。当たり前ですが、これは言葉を覚えている前提の仕組みです。
実務で困るのはその逆側です。「あの会社と、たしか値引きの話をしたはず」「先方の担当が変わった連絡がどこかにあった」。こういう問いは、覚えている言葉が本文に含まれているとは限りません。
| キーワード検索 | AI検索 | |
|---|---|---|
| 得意 | 件名・送信者が分かっている | 状況は覚えているが言葉が出ない |
| 苦手 | 言い換えられている場合 | 網羅性の保証（探し漏れ） |
| 出力 | 該当メールの一覧 | 要約された答えと出典 |
置き換えではなく、住み分け
ここを「AIを入れたらGmail検索は要らなくなる」と説明してしまうと、現場は期待外れを感じて離れます。「言葉を覚えているときは検索、状況しか覚えていないときはAI」と伝えてください。
「出典が出ること」が実用の分かれ目
要約だけ返すAI検索は、業務では使われません。元のメールに飛べないと、確認できないからです。「たぶんこう言っていました」で送信ボタンは押せません。
出典を出せない構成は、作り直しになる
回答文に加えて「いつ・誰から・どのスレッド」が必ず併記され、クリックで原文に飛べる。この形になって初めて、現場は業務で使い始めます。
後から足せる機能ではありません。どのスレッドを根拠にしたかは、回答を作る時点で保持しておく必要があります。要件に入れるのは実装前です。
実務で詰まるのは、権限の引き継ぎ方
ここがGmail連携で最も慎重に設計すべき箇所です。メールは個人の受信箱にあります。全社のメールを1つのAIに読ませると、本来見えないやりとりが回答に混ざります。
その前に：Google Workspace に「共有メールボックス」は無い
Exchangeの共有メールボックスに相当する機能を探すと、混乱します。Google Workspace では仕組みが2つに分かれていて、それぞれ性質が違います。
| 仕組み | 実体 | 上限 |
|---|---|---|
| メール委任 delegation |
他人のアカウントを代理で読み書きする | 職場アカウントは最大1,000人。同時利用は40人程度が目安 |
| 協働トレイ Google グループ |
グループ宛のメールをメンバーで担当分けする | グループの人数に準じる |
info@ が「委任されたユーザーアカウント」なのか「グループの協働トレイ」なのかで、AIから見えるかどうかが変わります。まずどちらで運用されているかを確認してください。
純正のGeminiは、委任された受信トレイを読めない
Googleは委任先で使えない機能に Gemini in Gmail を名指しで挙げています。公式の記載は次のとおりです。
If someone has given you delegated access to their inbox, Gemini doesn’t have access to those messages, only the messages in your own inbox.
（委任アクセスを受けていても、Geminiはそのメッセージにアクセスできない。自分の受信トレイのメッセージのみ）
「info@ を純正Geminiに読ませる」構成は成立しません。ここを対象にするなら、Gmail APIで自前に組む必要があります。
取りうる構成は3つ
| 構成 | 純正Gemini | 性質 |
|---|---|---|
| 個人単位 | 可 | 自分の受信箱だけを参照。安全だが、組織のナレッジにはならない |
| 共有窓口のみ | 不可 | info@ や support@ を対象にする。自前構築が前提 |
| 権限引き継ぎ型 | 実質これ | 利用者が見られる範囲だけを検索する |
純正Geminiの権限モデルは、公式の一文で言い切られています。
Gemini has the same access to Workspace data as you do.
（Geminiは、あなたと同じ範囲のWorkspaceデータにアクセスする）
つまり純正を使うかぎり、権限設計の余地はありません。利用者の権限がそのまま参照範囲になります。設計が必要になるのは、自前で組む場合だけです。方式の比較は権限の引き継ぎ方をどう決めるかにまとめています。
順序としては「個人単位で有効性を確認してから、共有窓口を自前で足す」のが現実的です。共有窓口を先に置くと、純正では動かないぶん最初から実装工数がかかります。
全社一括参照は、ほぼ確実に止まる
止まってから設計をやり直すと、工数が丸ごと無駄になる
「全員のメールをまとめてナレッジ化したい」という要望はよく出ます。ただ実際に進めると、人事・労務・与信のやりとりが混ざることが分かった時点で法務か情シスに止められます。
データ側で先にやっておくこと
連携作業そのものより、事前の整理のほうが精度に効きます。
| 項目 | 問題 | 対処 |
|---|---|---|
| 署名・定型文 | 全メールに同じ文が入り、検索のノイズになる | 取り込み時に除去する |
| 引用の入れ子 | 返信の連鎖で同じ本文が何度も重複する | スレッド単位でまとめる |
| 添付ファイル | 本文に情報がなく、添付側に実体がある | 添付も対象に含めるか決める |
| メルマガ・通知 | 件数が多く、検索結果を埋める | 対象から除外する |
最も効くのはメルマガと自動通知の除外
件数ベースでは受信メールの大半を占めることも多く、これを外すだけで体感精度が変わります。設計に手を入れる前に、まずここから試してください。
どこまで遡るか
「全期間」を選びたくなりますが、古いメールほど組織も担当も変わっていて、参照されると誤解を生みます。まず直近1〜2年で始めて、必要が出てから遡るほうが、精度と処理コストの両面で合理的です。
導入前に測っておくべきこと
効果を後から説明できるようにするには、導入前の状態を数字で持っておく必要があります。
- 「過去のやりとりを探す」行為が1日に何回発生しているか
- 1回あたり何分かかっているか
- 探した結果、見つからなかった割合
3つ目を別枠で数える
見つからずに諦めて、電話で聞き直しているケースが一定数あります。ここは時間短縮ではなく「そもそも到達できていなかった情報に届く」という価値なので、別枠で数えたほうが実態に合います。
Googleの保存期間と、日本ドメインの既定値を確認しました
Gemini in Workspace の会話は90日〜無期限で、管理者が決めます。また、ドメインの所在地が日本の場合、Workspaceのスマート機能は既定で無効です。主要4サービスの保存期間・保存先を比較した表です。
まず1週間、質問を集めるところから
連携設計に入る前に、実際に社内で発生している「探しもの」を20〜30件集めてください。その質問に答えられる構成になっているかが、設計の合否判定になります。ツールから入ると、この検証ができないまま完成してしまいます。
どこから連携すべきか、3分で分かります
共有窓口からか、個人単位からか。純正で足りるのか、自前が要るのか。かんたんな設問に答えるだけで診断します。設計に入る前に見ておくと、後戻りが減ります。費用はかかりません。
この記事について：Geminiのアクセス範囲と委任受信トレイの扱いは Google Workspace ヘルプ「What controls Gemini’s access to Workspace data」および Gmail ヘルプ「Delegate & collaborate on email」の記載に基づいています。協働トレイに対するGeminiの挙動は公式に明記がないため、断定していません。仕様の更新が速い領域のため、導入検討時には最新の公式文書をご確認ください。本文の検索時間・件数に関する記述は、社内で観測した傾向であり調査統計ではありません。
