会社情報
採用情報
お問い合わせ
Article

15分で設定！メールの自動振り分けルール

高田晃太郎
15分で設定！メールの自動振り分けルール

研究データでは、ナレッジワーカーは業務時間の約28%をメール処理に費やすと報告されています（McKinsey, 2012）¹。MicrosoftのWork Trend Indexでも、情報労働者が大量のメッセージに晒される状況が継続し、未読の蓄積が集中や意思決定に影響する旨が繰り返し指摘されています²。受信トレイの混雑を和らげるには、クライアント任せではなくサーバー側で確実に動く自動振り分け（フィルタ／ルール）を起点にするのが効果的です。ポイントは完璧主義を捨て、最初の15分で“効く”ルールから置くこと。以降では、Gmail・Microsoft 365・汎用IMAPの三系統を主役に、設定例と再現可能なコードで、短時間の導入をリードします。

15分で終わらせる設計：最初に決めるのは重要度と着地点

最速導入で効かせるには、まず受信トレイの役割を定義します。受信トレイはリアルタイム対応が必要なNowの箱、当日中にまとめて捌くScheduleの箱、検索や監査のために後で参照するLogの箱、この三つの流れに整理します。達成したい目標値は前もって決めておくと良く、例えば「受信トレイ流入を30%削減」「アラートの重複を70%圧縮」「VIP送信者の平均一次応答（FRT: First Response Time）を15分以内」といった閾値は設計の指針になります。技術的には、フィルタ条件を人とコンテキスト、そして時間の三つで編成すると衝突が少なく運用が安定します。人は経営・顧客・重要ベンダーを優先層として、コンテキストはアラート、コードレビュー、インボイス、法務など業務の“箱”で切り出し、時間は業務時間内と夜間のルーティング差やSLA（Service Level Agreement: 応答・解決までの合意時間）の違いを反映させます。この設計を10分で下書きし、残り5分で三つのルールを先に置けば、初日から負荷軽減を実感できることが多いはずです。完璧さよりも即効性を優先し、翌日以降に誤分類の微調整を入れる前提で進めると、心理的抵抗も最小限に抑えられます。

Gmail/Outlook/IMAP：サーバー側で確実に動く実装レシピ

Gmailは検索演算子が強力で、from、to、subject、list、has、newer_thanなどを組み合わせれば³、クライアント依存なくルールがサーバーで走ります⁴。例えば、監視システムからの重大アラートだけをNowに残し、残りをAlertsラベル配下に退避する場合、subject:(CRITICAL OR P1) AND from:alerts@monitoring.example.com のように条件を狭め、INBOXを外し、重要度の高い送信者だけを受信トレイに留めます。Microsoft 365ではGraph APIで統制されたルール配布が可能で、組織単位での標準化や監査にも向きます⁵。汎用IMAP環境なら、サーバー側のSieve（メールサーバーのフィルタリング言語）や、必要に応じて最小限のIMAPスクリプトで移動処理を担保します⁶。ここからは動くコードで一気に形にします。

Gmail APIで重大アラートをラベル化し受信トレイから除外

import os
import sys
from google.oauth2.credentials import Credentials
from google.auth.exceptions import GoogleAuthError
from googleapiclient.discovery import build
from googleapiclient.errors import HttpError

def get_service(creds: Credentials):
    try:
        return build("gmail", "v1", credentials=creds)
    except GoogleAuthError as e:
        print(f"Auth error: {e}")
        sys.exit(1)

def ensure_label(service, user_id: str, label_name: str) -> str:
    labels = service.users().labels().list(userId=user_id).execute().get("labels", [])
    for lb in labels:
        if lb["name"] == label_name:
            return lb["id"]
    body = {"name": label_name, "labelListVisibility": "labelShow", "messageListVisibility": "show"}
    created = service.users().labels().create(userId=user_id, body=body).execute()
    return created["id"]

def create_filter(service, user_id: str, from_addr: str, subject_query: str, label_id: str):
    body = {
        "criteria": {
            "from": from_addr,
            "subject": subject_query
        },
        "action": {
            "addLabelIds": [label_id],
            "removeLabelIds": ["INBOX"]
        }
    }
    try:
        return service.users().settings().filters().create(userId=user_id, body=body).execute()
    except HttpError as e:
        print(f"HTTP error: {e}")
        sys.exit(2)

if __name__ == "__main__":
    # 事前にトークンを発行しておく（https://developers.google.com/gmail/api）
    token_path = os.environ.get("GMAIL_TOKEN_PATH", "token.json")
    creds = Credentials.from_authorized_user_file(token_path, ["https://www.googleapis.com/auth/gmail.settings.basic","https://www.googleapis.com/auth/gmail.labels"])
    svc = get_service(creds)
    label_id = ensure_label(svc, "me", "Alerts/CRITICAL")
    res = create_filter(svc, "me", "alerts@monitoring.example.com", "(CRITICAL OR P1)", label_id)
    print(f"Created filter id: {res.get('id')}")

このスクリプトは、Alerts/CRITICALというラベルを作成し、監視アラートの重大な件名を自動でラベル付けしたうえでINBOXから外します。受信トレイの視覚的ノイズを減らせる構成で、誤分類の恐れがあればnegatedQueryやnewer_thanを組み合わせて範囲を狭めます³⁴。

Microsoft GraphでVIP送信者を常に最上位に固定

import os
import sys
import json
import requests

def create_vip_rule(token: str, vip_addresses: list[str]):
    url = "https://graph.microsoft.com/v1.0/me/mailFolders/inbox/messageRules"
    headers = {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}
    conditions = {"senderContains": vip_addresses}
    actions = {"markImportance": "high", "stopProcessingRules": True}
    body = {"displayName": "VIP-Top", "sequence": 1, "conditions": conditions, "actions": actions, "stopProcessingRules": True}
    resp = requests.post(url, headers=headers, data=json.dumps(body), timeout=10)
    if resp.status_code >= 300:
        print(f"Graph error: {resp.status_code} {resp.text}")
        sys.exit(3)
    return resp.json()

if __name__ == "__main__":
    token = os.environ.get("GRAPH_TOKEN")
    if not token:
        print("GRAPH_TOKEN not set")
        sys.exit(2)
    rule = create_vip_rule(token, ["ceo@example.com", "key.customer@client.com"])
    print(f"Created rule: {rule.get('id')}")

このルールはVIP送信者を常に高重要度に設定し、後続のルール処理を停止します⁵。重要な連絡の見逃しを減らし、一次応答（FRT）の短縮につながることが多い構成です。

IMAP運用環境での軽量移動バッチ（Python/imaplib）

import imaplib
import email
import os
import sys

def safe_imap_login(host: str, user: str, password: str) -> imaplib.IMAP4_SSL:
    try:
        m = imaplib.IMAP4_SSL(host)
        m.login(user, password)
        return m
    except imaplib.IMAP4.error as e:
        print(f"IMAP error: {e}")
        sys.exit(1)

if __name__ == "__main__":
    host = os.getenv("IMAP_HOST")
    user = os.getenv("IMAP_USER")
    pwd = os.getenv("IMAP_PASS")
    m = safe_imap_login(host, user, pwd)
    m.select("INBOX")
    typ, data = m.search(None, '(FROM "noreply@internal.example.com" SUBJECT "build succeeded")')
    if typ != 'OK':
        print("Search failed")
        sys.exit(2)
    ids = data[0].split()
    for msg_id in ids:
        m.copy(msg_id, "Logs/CI")
        m.store(msg_id, '+FLAGS', '\\Seen')
        m.store(msg_id, '+FLAGS', '\\Deleted')
    m.expunge()
    m.logout()

CIの成功通知など“読む必要はないが残したい”系をLogsに落とし、INBOXを通過させない構成です。受信トレイの件数を圧縮でき、検索時はフォルダ限定で高速化します。

Node.jsでIMAPを常駐監視し、P1のみをモバイルに残す

import { ImapFlow } from 'imapflow';

const client = new ImapFlow({
  host: process.env.IMAP_HOST,
  port: 993,
  secure: true,
  auth: { user: process.env.IMAP_USER, pass: process.env.IMAP_PASS }
});

async function main() {
  try {
    await client.connect();
    let lock = await client.getMailboxLock('INBOX');
    try {
      for await (let msg of client.fetch({ seen: false }, { envelope: true, source: false })) {
        const subj = msg.envelope.subject || '';
        const from = (msg.envelope.from?.[0]?.address || '').toLowerCase();
        const isP1 = subj.includes('P1') || subj.includes('CRITICAL');
        if (!isP1 && from.endsWith('@monitoring.example.com')) {
          await client.messageMove(msg.uid, 'Alerts/NonCritical');
        }
      }
    } finally {
      lock.release();
    }
  } catch (e) {
    console.error('IMAP error', e);
    process.exit(1);
  } finally {
    await client.logout();
  }
}

main();

この常駐は重要度でモバイル通知を抑制します。夜間の誤起床を避けながら、P1のみを即時可視化できます。運用上はサービスアカウントで権限を限定し、障害時は受信トレイにフォールバックする設計にします。

AWS SES + Lambdaで件名を解釈しS3に自動仕分け

import os
import json
import boto3
from email import policy
from email.parser import BytesParser

s3 = boto3.client('s3')
BUCKET = os.getenv('S3_BUCKET')

def lambda_handler(event, context):
    record = event['Records'][0]
    s3_obj = record['s3']
    bucket = s3_obj['bucket']['name']
    key = s3_obj['object']['key']
    raw = s3.get_object(Bucket=bucket, Key=key)['Body'].read()
    msg = BytesParser(policy=policy.default).parsebytes(raw)
    subj = msg['subject'] or ''
    frm = (msg['from'] or '').lower()
    if 'CRITICAL' in subj or 'P1' in subj:
        prefix = 'now/'
    elif frm.endswith('@ci.example.com') or 'build succeeded' in subj.lower():
        prefix = 'logs/ci/'
    else:
        prefix = 'archive/'
    dst_key = f"{prefix}{os.path.basename(key)}"
    s3.copy_object(Bucket=BUCKET, CopySource={'Bucket': bucket, 'Key': key}, Key=dst_key)
    s3.delete_object(Bucket=bucket, Key=key)
    return {"status": "ok", "stored": dst_key}

オンプレの制約が少ない環境では、受信の直後にサーバー側で自動分類してから配信できます⁷⁸。セキュアにアーカイブしつつNow/Schedule/Logの三層へ分配することで、コンプライアンスと可観測性も同時に担保します。

ノイズを減らし、重要を浮かせる：運用で効かせる細部

自動化の目的はゼロ未読ではなく、重要な意思決定を速く正確に行うことです。重要な送信者の優先表示、機械的な成功通知の即時退避、同一アラートの重複抑制、請求・法務・セキュリティの個別レーン化、この四つを先に効かせるだけで、日々の数分単位の節約が積み上がります。誤分類のリスクを抑えるため、初週は「疑わしい分類」のためのQuarantineラベルを併設し、朝の3分レビューで戻す運用を足します。Gmailなら newer_than:7d を添えて新規ルールの影響範囲を7日以内に制限し³、Microsoft 365なら stopProcessingRules の指定でVIPルールを最初に止める順序を守れば、期待通りの結果に近づきます⁵。監査や引き継ぎを考えると、ルールのエクスポートと変更履歴をリポジトリで管理し、Pull Request経由でレビューするのが安全です。誤配送を避けるため、社外転送は初期配置から外しておき、週次レビューを通過したルールに限定してから有効化します。モバイル通知はP1のみ、P2はバッジのみ、P3は無通知といった段階的な通知設計にすると、睡眠の質が保たれ、日中の集中も持続します。

効果測定とベンチマーク：入れて終わりにしない

導入効果は「前後比較」を設計して測ります。例えば30日をベースライン期間とし、同期間での指標推移を追うと変化が見えます。見るべきは、受信トレイ流入数（INBOXに到達した件数／日）、一次応答の中央値（FRT）、重複アラートの比率（同一送信元・件名の短時間多発率）、Nowボックスの滞留時間（最初の未読から既読までの経過）です。ダッシュボード上は未読総数よりも、Nowボックスの滞留時間、VIP送信者のFRT、アラートの重複比率の三指標を並べると、意思決定に直結する改善が見えやすくなります。ルールの遅延はサーバー側処理で吸収されることが多く、クライアント常駐に頼るより安定します。なお、測定時は季節要因やキャンペーンによる流量変動を控えめに見るため、週次トレンドと中央値で評価するのが実務的です。

ガバナンス、失敗時の設計、そしてチーム共有

チーム運用では、個人ルールの属人化を避けるため、テンプレートを作り、Pull Requestベースで合意形成を図ります。GraphやGmail APIを使えば、同じ条件セットをチーム全員に配布でき、異動時や新入社員のオンボーディングも数分で完了します⁵⁴。誤分類の“最悪ケース”を想定し、二重のセーフティネットを敷くと安心です。第一にQuarantineラベルでの一時留め置き、第二に7日以内のINBOX除外のみを許可する時限ルール、第三に毎朝の3分レビューで復帰という流れにしておけば、重要メールの取り逃しは最小化できます。障害時のフォールバックとして、ルールエンジンが失敗したときはINBOXへ集約する片方向の安全側設計を選び、外部転送や削除を初期段階から用いないことが実運用上のリスクを減らします。費用対効果は、前提を置いた簡易試算で共有すると意思決定が進みます。例えば、時給5,000円相当のエンジニアが一日10分のメール処理を削減できた場合、月20営業日で約16,600円（5,000円 × 3.33時間）の削減に相当し、チーム5名なら月8万円超の人件費相当効果になります。設定そのものは15分、微調整を含めても初週合計90分を目安に、翌週からはスムーズに利益が積み上がる運用設計にしておくと良いでしょう。

日々の運用改善を継続するために、詳しいAPIの扱いは関連ガイドも参照してください。Gmailのスコープ設定や認可フローは「Gmail API入門」、Microsoft 365のエンドポイントやアプリ権限は「Microsoft Graph APIの実践ガイド」、通知ノイズの体系的削減は「Slackの自動化で通知ノイズを半減」、アラート疲労を避ける設計は「SREのアラート疲労を減らす」が補完します。

まとめ：最初の15分で“効く場所”に刃を入れる

メールの自動化は、完璧なルールの網を作る作業ではありません。重要を浮かせ、ノイズを沈めるための、いくつかのてこを正しい順序で差し込む営みです。受信トレイの役割を三つに分け、VIP・重大アラート・機械通知の三領域から手を付ければ、初日から変化を体感できるはずです。もし今日15分を確保できるなら、まずはVIPの固定、重大アラートの退避、CI成功通知のログ化という三手を入れてみてください。明日の朝会で、未読の景色が変わっているはずです。次にどのルールを磨きますか。チームのSLAに一番効く領域から、もう15分を投資してみましょう。

参考文献

  1. CNBC. Workers spend one-fourth of workday reading, responding to email: survey. 2012-08-01. https://www.cnbc.com/2012/08/01/workers-spend-onefourth-of-workday-reading-responding-to-email-survey.html
  2. Microsoft WorkLab. 2023 Work Trend Index. https://www.microsoft.com/en-us/worklab/work-trend-index/
  3. Google Support. Search operators you can use with Gmail. https://support.google.com/mail/answer/7190?hl=en
  4. Google Developers. Gmail API — Filter settings. https://developers.google.com/gmail/api/guides/filter_settings
  5. Microsoft Learn. Create messageRule (Microsoft Graph v1.0). https://learn.microsoft.com/en-us/graph/api/mailfolder-post-messagerules?view=graph-rest-1.0
  6. IETF. RFC 5228: Sieve: An Email Filtering Language. https://datatracker.ietf.org/doc/html/rfc5228
  7. AWS Documentation. Receiving email with Amazon SES. https://docs.aws.amazon.com/ses/latest/dg/receiving-email.html
  8. AWS Documentation. Using AWS Lambda with Amazon SES for incoming emails. https://docs.aws.amazon.com/ses/latest/dg/receiving-email-action-lambda.html