2026-06-14　AI自動化メール管理業務効率化非エンジニア

AI自動化

受信箱を開く前にAIで仕分ける方法｜重要メールだけ自動通知するトリアージ設計

当サイトはアフィリエイトプログラムを利用しており、紹介リンク経由での申込により報酬を得る場合があります。記事内で紹介するサービスには筆者が実際に使用しているものと、客観情報として比較掲載しているもの（未使用・PR表記あり）が含まれます。

結論

AIにメールを仕分けさせる最大のコツは「受信箱を開く前に判定を済ませる」設計にすること。IMAPのreadonly接続で未読フラグを維持しながら1日4回ポーリングし、AIが「要対応」「重要」と判定したメールだけをSlackに通知する仕組みを作れば、受信箱のチェック回数を体感で大幅に減らせる（個人差あり）。重要なのは「AIが重要でないと言ったら完全無視する」運用にしないこと——この境界線だけ守れば、非エンジニアでも再現できる。

受信箱を開くたびに、広告・newsletter・自動通知に埋もれた重要メールを探す時間がじわじわと集中力と時間を奪っていく。

自分はフリーランスで複数のクライアントと仕事をしており、1日に届くメールが平均60〜80通ある。大半は「読まなくていい」ものだとわかっていても、「重要なメールを見落としたら」という不安から1時間ごとに受信箱を確認していた。

これを解決するために、2025年末からAIによる自律メールトリアージを運用している。この記事では、その仕組みの全体設計と、非エンジニアでも再現できる手順を一次体験ベースで紹介する。

なぜ「受信箱を開く前に」仕分けるのか#

メールアプリを開いてから仕分けを始める、という順番には落とし穴がある。受信箱を「開く」という行為自体がコンテキストスイッチを引き起こす。メールを1通でも目にした瞬間、脳はそのメールの処理モードに入ってしまい、10分後には「なんとなくメールを読んでいた」状態になる。

AIトリアージの目的は「判定を受信箱を開く前に完了させる」こと。メールを見るのは「対応が必要だと通知が来たときだけ」にする設計だ。

メモ

Gmail・Outlookなどのフィルタ機能でもラベル分けはできる。ただしルールベースでは新しいパターンに追いつかず、「重要か否か」の文脈判断は単純な条件分岐では難しい。「先方の名前は入っていないが締め切りの言及がある」といったメールをAIは読み取れるが、ルールフィルタでは対応できない。

自分が使っているシステムの全体像#

構成の早見表#

要素	内容
メール取得方法	IMAPでreadonly接続（未読フラグを変えない）
実行頻度	1日4回（7時・12時・17時・21時）
判定エンジン	Claude APIに件名＋差出人＋本文冒頭200字を送る
通知先	Slack（#mail-alertチャンネル）
冪等性	処理済みMessage-IDをJSONファイルに記録し二重通知を防ぐ
実行環境	Mac miniのlaunchdジョブ（Pythonスクリプト）

IMAP readonlyが重要な理由：IMAPの通常接続は「開封」すると未読フラグが消える。readonlyで接続することで、AIがメールを読み取っても受信箱の未読状態が維持される。メールアプリを後で開いたとき、まだ未読で残っているので「開いていないのに既読にしてしまった」という誤操作が起きない。

冪等設計が重要な理由：ジョブが何らかの理由で再実行されたとき、同じメールの通知が2回届くのを防ぐ。処理済みのMessage-IDを記録し、次回以降はスキップする仕組みにしている。この設計が抜けていると、再起動のたびに大量の重複通知が来て仕組み自体が嫌いになる。

AIに判定を任せてよい部分と、任せてはいけない部分#

注意

AIの判定だけを根拠に「AIが重要でないと言ったメールは絶対見ない」運用は危険です。この仕組みは「確認の頻度を減らすための補助」であり、判定はあくまで参考情報です。重要メールの最終確認責任はAIではなく自分にあります。

AIに任せてよいこと

差出人・件名・本文冒頭から「緊急度」「対応要否」を判定する
newsletterや自動通知メールを「スキップ」と分類する
「このクライアントからのメールは重要」といった文脈を自然言語で指示できる

AIに任せてはいけないこと

最終的な返信・対応の意思決定
機密情報を含む本文全体をAPIに送ること（本文冒頭200字に限定する）
「重要でない」判定を最終確定扱いにすること

プロンプトには「判定に迷ったら"要確認"と返せ」と明記しており、三値（要対応／重要／スキップ）で返させている。「迷ったら通知する」設計にすることで、AIの誤スキップリスクをある程度ヘッジできる。

セットアップ手順（ノーコード版）#

自分のケースはPythonスクリプトとlaunchdを使ったものだが、ノーコードでも同じ仕組みは作れる。ここではMake（旧Integromat）とGmailを使った構成を例に説明する。

手順

Makeアカウントを作成（無料プランあり）し、Gmailモジュールで「Watch Emails」を追加する。トリガーは「Schedule」に設定し、1日4回（朝・昼・夕・夜）を指定する。
HTTPモジュールを追加してClaude APIと接続する。リクエストボディに「件名・差出人・本文冒頭」を組み合わせたテキストを入れ、判定結果（要対応／重要／スキップ）を返させるプロンプトを書く。
Filterモジュールで分岐させる。APIの返答が「スキップ」のときはそこで止め、「要対応」または「重要」のときだけ次のステップへ進む。
Slackモジュールを追加して通知を送る。差出人・件名・AIの判定理由の3点を1メッセージに収める形にすると見やすい。
データストア（またはGoogleスプレッドシート）でMessage-IDを記録する。次回のポーリングで同じメールが来たときにスキップする冪等処理を入れる。
テスト実行で動作確認。自分宛に「緊急：今日中にご確認をお願いします」という件名のメールを送り、Slackに通知が届くか検証する。

ノーコードツールの比較#

ツール	費用目安	難易度	特徴
Make（旧Integromat）	無料〜約1,000円/月	低	GUIでノード接続するだけ・日本語情報多め
Zapier	無料〜約2,000円/月	低	英語UIだが連携数が多い
n8n（セルフホスト）	ほぼ無料	中	自由度が高いが初期設定が必要
Pythonスクリプト+launchd	APIコストのみ	高	完全カスタマイズ可能・自分はこれ

非エンジニアの方にはMakeをまず試すことをすすめる。条件分岐のノードをドラッグ&ドロップで並べるだけで、上記の流れを再現できる。

つまずきポイントと実際の失敗談#

判定が荒くてノイズが多かった（最初の1週間）#

最初のプロンプトは「重要なメールを教えてください」という雑な指示だった。そのせいでECサイトの「ご注文確認メール」や「ご利用明細が届きました」のような自動通知まで「重要」判定されて、Slackが荒れた。

解決策：プロンプトに判定基準を明文化した。

重要：クライアントからの依頼・質問・締め切りの言及
要対応：入金確認・契約関連・期限付き手続き
スキップ：newsletter・EC注文確認・SNS通知・自動返信メール

この基準を入れた途端、精度が体感で大幅に上がった。プロンプトを育てる最初の1〜2週間が一番大事だ。

Message-IDの記録が消えて二重通知が出た#

Makeの無料プランではデータストアの容量が限られており、記録が消えたタイミングで古いメールが再通知されてしまった。対策としてGoogleスプレッドシートに記録先を移した。スプレッドシートはデータが消えないうえ、後から「いつ何のメールが重要と判定されたか」のログとしても使える。

メモ

二重通知はストレスになるが、「見逃し」より「見落とさない」を優先する設計思想でいる。万一二重通知が来たときは手動でスプレッドシートのIDを確認するだけで解消できる。

ビフォーアフター#

メリット

メールチェックのために集中作業を中断する回数が体感で大幅に減少
「重要なメールを見落としているかもしれない」という不安がほぼなくなった
朝の集中作業時間を以前より長く確保できるようになった
newsletterの解除作業や仕分け作業に時間を使わなくてよくなった

デメリット

初期セットアップに2〜4時間かかった（ノーコードツールの学習コスト含む）
Claude APIのコストが月に数百円発生する（メール量・本文の長さによる。目安）
稀に重要メールを誤スキップするため完全依存はできない
プロンプトのチューニングに最初の1〜2週間が必要

メールを自動で引き取る仕組みができたことで、空いた時間を企画書・提案文・SNS投稿の作成に回せるようになった。文章作成にもAIを活用したい場合は、AIライティングツールを組み合わせると効果的だ。

まとめ#

メールのAI自律トリアージで押さえるべきポイントは3つだ。

受信箱を開く前に判定を終わらせる設計にする
IMAP readonlyで未読フラグを維持し、開封の痕跡を残さない
AIが「スキップ」と言っても完全無視しない——AIは補助であり最終判断は自分

冪等設計（二重通知防止）は地味だが、運用を続ける上で効いてくる要素だ。ノーコードツール（Make等）を使えば、プログラミングなしでも同様の仕組みを構築できる。

最初からパーフェクトな判定を目指す必要はない。まず「newsletterをスキップさせるだけ」から始め、徐々に判定基準を育てていくのが現実的なアプローチだ。

よくある質問#

GmailのフィルタやラベルとAI仕分けは何が違いますか？#

Gmailのフィルタ機能はルールベースで動くため、差出人・件名の条件を事前に登録する必要があります。AIトリアージとの最大の違いは「文脈判断ができるかどうか」です。「急ぎ」「今日中に」「ご確認ください」といった表現を柔軟に読み取るのはAI（LLM）の得意領域で、ルールフィルタでは拾いにくいパターンもカバーできます。GmailフィルタとAI判定を組み合わせ、明らかなSPAMの除外はGmailフィルタ、残りの判定にAIを使う二段構えも有効です。

メールの内容をAPIに送ることで情報漏洩のリスクはありませんか？#

本文全体を外部APIに送ることにはリスクが伴います。この記事で紹介した設計では件名・差出人・本文冒頭200字だけを送ることでリスクを限定しています。機密性の高い業種（医療・法律・金融など）では、クラウドAPIではなくローカルで動くLLM（Ollama等）を検討する選択肢もあります。まず自社・自分のセキュリティポリシーを確認してから導入を判断してください。

1日4回のポーリングでは緊急メールへの対応が遅れませんか？#

実際には、緊急度の高い連絡はメールよりもSlackやLINE・電話で来ることがほとんどです。「メールで緊急連絡が来る」関係者には、重要な連絡はSlackに送ってもらうよう事前に伝えておくと運用が安定します。それでもリアルタイムに近い対応が必要な場合は、ポーリング頻度を15〜30分に上げる設定変更で対応できます。