共有メールアドレスの「未返信」を GAS で検知したら、最後はツール選定になった話【実録】

問い合わせ用の共有メールアドレス。最初は数人で見ていたのが、気づけば何十人も関わる窓口になっている。そして必ず起きるのが「誰も返していなかった」だ。

ある会社で、1つの共有アドレスに約70〜80名、8〜9チームが関わっていた。未返信のチェックは、各チームの担当者が1日2回、15〜20分かけて手でやっていた。これを Google Apps Script（GAS）で自動化した。作るのは早かった。時間がかかったのは、拾わなくていいものを除く作業の方だった。そして最後は、ツール選定の話になった。

▼背景：共有アドレスに何十人も関わると、何が起きるか

メールの流れはこうだった。共有アドレスに届いたメールを、100件を超えるフィルターで各チームに転送する。返信は各自の個人アドレスから行い、共有アドレスを Cc に入れる。

この運用は、規模が大きくなると限界が出る。

• ▶ Gmail の転送・配信の上限に当たり、メールが転送されないことがある
• ▶ 同じアカウントに複数人がログインすると、本人確認が入って入れなくなる
• ▶ 新しい取引先のドメインが増えるたびに、フィルターの追加が要る
• ▶ 誰が対応すべきか、誰が返したかが見えない

根本的にはツールで解く問題だ。だが、ツールの選定と導入には時間がかかる。まずは目の前の「返し漏れ」を止めるために、未返信の検知を自動化した。

▼判定は、人がやっているルールをそのまま写した

最初に、担当者が手でどう判定しているかを聞いた。答えはシンプルだった。スレッド表示で見て、最後に返信したのが自社のドメインかどうか。自社なら返信済み、相手なら未返信だ。

これをそのまま GAS に写した。「AI でメールの文面から要返信かを判定する」ような凝った作りにはしていない。人の判定ルールを写すだけなら、短期間で動く。最初のチームでは、キックオフから約3週間で本番稼働した。

▼運用で効いた工夫

実行は朝一を避けて、13時と17時

当初は午前中の実行も考えた。だが朝に届いたメールは「今から返すもの」が多い。朝一に回すと、それまで全部拾ってしまう。13時と17時の1日2回にした。昼休み明けと終業前に「まだ返していないもの」が届く形だ。

見るのは直近24時間だけ

最初は3日前まで遡っていた。すると、返信不要のメール（お礼の一言、システムの通知など）が大量に残り続ける。収集期間を直近24時間に絞った。時刻ごとにスクリプトを分けると保守が増えるので、1本のまま期間だけ変えた。

通知したメールにラベルを付け、次回の前に外す

通知したメールには「通知済み」のラベルを付ける。そして次の実行の前に、ラベルを全部外してから判定し直す（洗い替え）。こうすると、返信済みになったメールのラベルが溜まらず、まだ返していないものだけが残る。

通知先は、担当者が普段いるチャンネル

未返信の専用チャンネルを作るより、担当者が普段使っている既存のチャンネルにスレッドで投稿した方が、反応もフィードバックも返ってきた。メンションも、チーム全体ではなく案件の担当者ごとにした。

除外ルールは、運用しながら積む

稼働してから分かった「拾わなくていいもの」を、1つずつ除外に足していった。

• ▶ システムが自動で送る通知メール（返信不要のもの）
• ▶ 取引先のシステムから届く発注・承認依頼の自動メール
• ▶ 海外とのやり取り：件名の決まったパターンで除外すると、国内のやり取りへの影響が少なかった

検知を作るより、この除外ルールの積み上げの方がずっと時間がかかった。最初のチームでは、手動チェックと並行で約1週間比べて、ノイズの候補を集めた。

▼仕組みで解けない限界は「仕様」として扱う

運用していくと、どうしても拾い方がずれるケースが出てくる。

起きたこと	原因	扱い
返信済みなのに、また「未返信」で上がる	返信の宛先に共有アドレスが入っていない（共有アドレスの別名だけが入っている）	仕様として周知。スクリプトは直さない
送信者の表示が「〜経由（via）」になる	転送の経路	経由のパターンを調べて条件に反映
通知のリンクを開けない	メールが共有アドレス宛にしか届いておらず、担当者が Cc に入っていない	後回し
通知用アドレスから送ったメールへの返信を拾えない	返信が共有アドレスを経由しない	当面は手で確認。運用方針が決まってから再検討

1つ目の「再通知」は、スクリプトで直すこともできた。だが直すほど条件が複雑になり、次の不具合の原因になる。上がっても業務上は困らないので、「返信済みでも上がることがある」と周知して運用でカバーすることにした。仕組みで全部を解こうとしないのも、設計の判断だ。

▼AI で作ったスクリプトは、変更を最小限にする

このスクリプトは AI の手を借りて作った。作るのは速い。だが、細かい改修を重ねるほど条件分岐が増え、誰も全体を把握できなくなる。

そこで2つ決めた。1つは、変更は最小限にすること。「このケースも拾いたい」という要望には、まず運用でカバーできないかを考える。Slack のスタンプで「確認済み」を除外する案も出たが、保守コストが大きいので見送り、遡る期間の調整で代替した。

もう1つは、スクリプトの置き場所と管理者を決めることだ。個人のアカウントで動いていると、その人がいなくなった瞬間に止まる。今回は共有アドレス自体の Google アカウントで動かし、仕様書を残した。作った人が持ち主になるのは、ガバナンス上のリスクだ。

▼最後はツール選定になった

未返信の検知で、目の前の返し漏れは減った。だが、転送の上限、ログインの制約、担当の見えなさは残る。細かい要望を足すほど、Gmail と GAS の限界に当たる。そこで、問い合わせ管理ツールの選定に進んだ。

比較の軸はこう整理した。

比較の軸	見るポイント
担当の見える化	担当のアサイン、返信中のロック、ステータス管理
振り分けと閲覧制御	フォルダ型かボックス型か。フォルダ型は閲覧制御ができない製品があり、制御が要るならボックスを分ける → ボックス数が料金に響く
認証	既存の IdP で SSO できるか（オプション扱いの製品が多い）
連携・計測	Slack 通知、API、返信スピードのレポート
価格	ベース料金に加えて、オプションの合計

見積で驚いたのはオプションの重さだ。SSO・誤送信防止・添付ファイルの URL 化をすべて付けると、ベース料金の約1.75倍になった例があった。必須の要件を絞ると、金額は大きく変わる。

もう1つ大事なのは、運用の変化を現場がどこまで受け入れられるかだ。多くのツールは、送信も受信もツールの中で完結させる前提になっている。Gmail に送信履歴が残らなくなるなど、慣れた運用が変わる。既存のフィルター、テンプレート、今回の GAS との役割分担も整理が要る。ベンダーが示す他社比較は、あくまでその会社の主張なので、必ず事実を確かめる。

▼まとめ

• ▶ 人の判定ルール（最後の送信者が自社か）をそのまま写せば、短期間で動く
• ▶ 時間がかかるのは除外ルールの積み上げ。13時・17時、直近24時間、ラベルの洗い替えが効いた
• ▶ 仕組みで解けない限界は、仕様として周知する
• ▶ AI で作ったスクリプトは変更を最小限に。置き場所と管理者を決める
• ▶ ツール選定では、オプション込みの価格と、現場が受け入れられる運用の変化を見る