結論：夏季休暇中に溜まる問い合わせメールの一次対応は、「受信の取得→緊急/通常/営業の3分類→復帰後の優先順位付きリスト生成→定型返信の下書き作成」までをClaude Codeで仕組み化できます。ただし設計原則は明確で、メールの自動送信は組み込まない。仕分けと下書きまでを機械に任せ、送信ボタンは必ず人が押す構成にします。
- 要点1：メールソフトの不在自動応答は「返信が遅れます」と伝えるだけで、休暇明けの受信箱には手つかずのメールがそのまま積み上がる。溜まること自体は防げないので、「復帰日の朝に何から読むか」が決まっている状態を仕組みで作るのが本記事のゴールになる
- 要点2：分類はルールベースを先行させ、ルールで確定しなかったメールだけをClaude Codeの判定に回す2段構えにする。既存顧客ドメインや「至急」等の語はコードで決定的に判定でき、AIに全件を読ませるより速く、判定根拠も説明しやすい
- 要点3：誤送信防止は「気をつける」ではなく構造で担保する。下書きはIMAPの下書きフォルダまたはローカルファイルに書き出すだけにして、SMTP送信のコードを最初から書かない。送信機能が存在しなければ、誤送信は原理的に起きない
対象読者：問い合わせ窓口を少人数で回している会社の開発者・情報システム担当・バックオフィス責任者。お盆や年末年始の長期休暇前に一次対応の段取りを整えたい方
今日やること：直近1か月の受信メールを眺めて、「緊急」「通常」「営業・自動通知」の3つに手で分けたら何対何対何になるか、ざっくり数えてみる。その比率が、休暇明けに本当に読むべきメールの量を教えてくれます
先に断っておくと、本記事は複数の支援経験をもとに一般化した実装パターン解説です。登場する工数や件数はいずれも想定モデルケースの目安で、特定企業の実測値ではありません。効果は問い合わせの量・種類・既存の運用によって変わります。
バックオフィスのAI活用支援で夏前によく聞くのが、「お盆の1週間、問い合わせメールを誰も見ない状態になるのが毎年こわい」という話です。不在自動応答は設定してある。それでも休暇明けの朝、受信箱には数十件から百件超のメールが未読のまま並び、その中に「休暇初日に届いていた既存顧客の障害連絡」が埋もれていないか、全件を上から読んで確かめることになる——この「復帰日の全件目視」が、休暇明け初日の午前を丸ごと持っていくわけです。
この記事では、休暇中の問い合わせメールを対象に、受信の仕分け・緊急度判定・復帰後の優先順位付きリスト生成・定型返信の下書き作成までをClaude Codeで仕組み化する実装を解説します。EC問い合わせ対応の自動化や自治体の問い合わせ振り分けで扱った「分類はルールとAIの2段構え」パターンの、長期休暇特化版です。
なぜ不在自動応答だけでは休暇明けがつらいのか
ほとんどのメール環境には不在自動応答（バケーションレスポンダー）があり、休暇前に設定している会社は多いはずです。ところが不在応答が解決するのは「送り手に返信遅延を伝える」ことだけで、受け手側の問題は何も解決しません。休暇明けに残る作業を分解すると、次の3つになります。
| 作業 | 内容 | 不在応答で解決するか |
|---|---|---|
| 全件の目視確認 | 緊急案件が埋もれていないか、上から全部読む | 解決しない |
| 優先順位付け | どれから返すかを決める。判断基準は頭の中にしかない | 解決しない |
| 返信文の作成 | お待たせした詫びと本題への回答を1通ずつ書く | 解決しない |
特に問題なのが1つ目です。営業メールやシステム通知が大半を占める受信箱でも、「読まずに捨てる」判断をするためには結局1通ずつ開くことになる。つまり休暇明けの負荷は受信総数に比例します。件数そのものを減らすことはできないので、打ち手は「読む順番と読まなくてよいものが、復帰前に確定している状態を作る」ことになります。これは機械が得意な仕事です。
設計原則——自動送信はしない。仕分けと下書きまで
実装に入る前に、この仕組みの設計原則を明確にしておきます。本記事の構成では、メールを自動送信する機能を最初から作りません。理由は3つあります。
- 誤送信は取り返しがつかない — 分類の誤りは復帰後に直せますが、誤った相手に誤った文面が送信された事故は取り消せません。特に休暇中は送信結果を監視する人がいないため、誤送信が数日間放置されるリスクがあります
- 不在応答との二重返信になる — メールサーバー側の不在応答と自作の自動返信が両方動くと、送り手に2通の機械応答が届きます。相手を混乱させるだけでなく、返信ループの温床にもなります
- 送信機能がなければ誤送信は原理的に起きない — 「送信前に確認する運用にする」よりも「送信コードが存在しない」ほうが強い保証です。安全は運用ではなく構造で担保します
したがって役割分担はこうなります。休暇中の即時応答はメールサーバー標準の不在自動応答に任せる。自作の仕組みは受信を読み取り専用で取得して仕分け・下書きを作るだけ。送信は復帰後に人が下書きを確認して1通ずつ行う。Claude Code側にも、後述するようにメール送信系のコマンド実行を許可しない設定を入れておきます。
実装の全体像——取得・分類・出力の3層
仕組みは3層のシンプルなパイプラインです。
- 取得層 — IMAPで受信箱を読み取り専用で取得する。IMAPが使えない環境では、メールソフトからエクスポートしたmbox/emlファイルを入力にする
- 分類層 — ルールベースで「緊急/通常/営業・通知」の3分類を先に確定し、ルールで決まらなかった残りだけをClaude Codeの判定に回す
- 出力層 — 復帰日の朝に読む優先順位付きMarkdownリストと、緊急・通常メール向けの返信下書き（ファイルまたはIMAP下書きフォルダ）を生成する
動作環境はPython 3.11以降を想定します。メール取得に使うimaplib・mailbox・emailはいずれもPython標準ライブラリなので、追加インストールは不要です。Claude Codeはターミナルで動くAnthropicのコーディングエージェントで、対話的な構築だけでなくclaude -pによるヘッドレス実行でスクリプトに組み込めます（公式ドキュメント: Headless mode）。
実装コード例1：受信メールを読み取り専用で取得する
まず取得層です。IMAPのselectには読み取り専用モードがあり、readonly=Trueを指定すると既読フラグの変更を含めて一切の書き込みが発生しません。休暇中の受信箱を「触らずに読む」ための基本です。
# fetch_mails.py — 指定日以降の受信メールをJSONに書き出す
import imaplib, email, json
from email.policy import default as default_policy
IMAP_HOST = "imap.example.co.jp"
USER = "[email protected]"
# パスワードは環境変数や資格情報ストアから読む（コードに直書きしない）
def fetch_since(host, user, password, since="01-Aug-2026"):
box = imaplib.IMAP4_SSL(host)
box.login(user, password)
box.select("INBOX", readonly=True) # 読み取り専用が重要
_, data = box.search(None, f'(SINCE "{since}")')
mails = []
for num in data[0].split():
_, msg_data = box.fetch(num, "(RFC822)")
msg = email.message_from_bytes(msg_data[0][1], policy=default_policy)
body = msg.get_body(preferencelist=("plain",))
mails.append({
"uid": num.decode(),
"from": str(msg.get("From", "")),
"subject": str(msg.get("Subject", "")),
"date": str(msg.get("Date", "")),
"message_id": str(msg.get("Message-ID", "")),
"body": body.get_content()[:2000] if body else "",
})
box.logout()
return mails
if __name__ == "__main__":
import os
mails = fetch_since(IMAP_HOST, USER, os.environ["IMAP_PASSWORD"])
with open("inbox.json", "w", encoding="utf-8") as f:
json.dump(mails, f, ensure_ascii=False, indent=2)
print(f"{len(mails)}件を取得しました")
IMAPを直接使えない環境（会社のセキュリティポリシーでアプリからの接続が許可されていない場合など）では、メールソフトのエクスポート機能で書き出したファイルを入力にします。ThunderbirdやGoogle Takeoutが出力するmbox形式なら、標準ライブラリのmailbox.mboxでそのまま読めます。取得層の出力を上と同じJSON形式に揃えておけば、以降の分類層は入力元を意識せずに動きます。
本文を2,000字で切っているのは意図的です。分類に必要な情報は冒頭に集中していることが多く、全文を後段のAI判定に渡すとトークンを浪費するうえ、長い引用スレッドが判定ノイズになるためです。
実装コード例2：緊急/通常/営業の3分類——ルール先行の2段構え
分類層の核心は、AIに全件を判定させないことです。先にルールベースで確定できるものを確定させます。分類の定義は次の3つです。
| 分類 | 定義 | 復帰後の扱い |
|---|---|---|
| 緊急 | 既存顧客・取引先からの障害/トラブル/期限つき依頼 | 復帰日の朝いちで返信 |
| 通常 | 返信は必要だが数日待てる問い合わせ・相談 | 復帰日〜2営業日で返信 |
| 営業・通知 | 営業メール・メルマガ・システム自動通知 | まとめて確認、返信不要 |
# classify_rules.py — ルールで確定できるものを先に確定する
import json, re
URGENT_WORDS = ["至急", "緊急", "障害", "エラー", "停止", "不具合", "トラブル",
"本日中", "期限", "納期"]
PROMO_PATTERNS = [r"unsubscribe", r"配信停止", r"メルマガ", r"no-?reply@",
r"newsletter", r"キャンペーン"]
def load_known_domains(path="known_domains.txt"):
# 既存顧客・取引先のドメイン一覧（1行1ドメイン）
with open(path, encoding="utf-8") as f:
return {line.strip().lower() for line in f if line.strip()}
def classify_by_rule(mail, known_domains):
sender = mail["from"].lower()
text = (mail["subject"] + " " + mail["body"]).lower()
if any(re.search(p, sender + " " + text) for p in PROMO_PATTERNS):
return "promo"
from_known = any(d in sender for d in known_domains)
if from_known and any(w in mail["subject"] + mail["body"] for w in URGENT_WORDS):
return "urgent"
if from_known:
return "normal"
return None # ルールで確定できない → AI判定へ
ルールで確定しなかった残り——初めての相手からの問い合わせや、既知ドメインだが緊急語を含まないメール——だけをClaude Codeのヘッドレス実行で判定します。
# classify_ai.py — 残りをClaude Codeで判定する
import json, subprocess
PROMPT = """次のメールを urgent / normal / promo のいずれかに分類してください。
判定基準:
- urgent: 障害・トラブル・期限つき依頼など、放置すると実害が出るもの
- normal: 返信が必要だが数日待てる問い合わせ・相談・見積依頼
- promo: 営業・宣伝・自動通知・返信不要のもの
迷ったら normal に寄せてください（緊急の取りこぼしより過剰検出を許容）。
出力はJSONのみ: {"label": "...", "reason": "30字以内の根拠"}
"""
def classify_by_ai(mail):
payload = json.dumps(
{"from": mail["from"], "subject": mail["subject"], "body": mail["body"]},
ensure_ascii=False)
result = subprocess.run(
["claude", "-p", PROMPT + "nn" + payload,
"--output-format", "json"],
capture_output=True, text=True, timeout=120)
return json.loads(result.stdout)
プロンプトの「迷ったらnormalに寄せる」は重要な設計判断です。3分類の誤りのうち実害が大きいのは「緊急をpromoに落とす」方向の誤分類なので、判定を安全側に倒しています。さらに後述の優先リストでは、AI判定のものにはその旨を明記し、人が最終確認できるようにします。
実装コード例3：復帰後の優先順位付きリストを生成する
出力層の1つ目は、復帰日の朝に上から順に処理するためのMarkdownリストです。分類結果を集約して1枚にまとめます。
# make_report.py — 復帰日の朝に読む1枚を作る
import json
from datetime import datetime
def make_report(classified):
urgent = [m for m in classified if m["label"] == "urgent"]
normal = [m for m in classified if m["label"] == "normal"]
promo = [m for m in classified if m["label"] == "promo"]
lines = [f"# 休暇中メール処理リスト（{datetime.now():%Y-%m-%d} 生成）",
"",
f"総数 {len(classified)}件 = 緊急 {len(urgent)} / "
f"通常 {len(normal)} / 営業・通知 {len(promo)}",
"", "## 1. 緊急——朝いちで返信する"]
for m in sorted(urgent, key=lambda x: x["date"]):
ai = "（AI判定）" if m.get("by_ai") else ""
lines.append(f"- [ ] {m['date'][:16]} {m['from']}｜{m['subject']}{ai}")
lines.append(f" 根拠: {m.get('reason', 'ルール判定')}｜下書き: {m.get('draft_file', '-')}")
lines.append("")
lines.append("## 2. 通常——2営業日以内に返信する")
for m in sorted(normal, key=lambda x: x["date"]):
ai = "（AI判定）" if m.get("by_ai") else ""
lines.append(f"- [ ] {m['date'][:16]} {m['from']}｜{m['subject']}{ai}")
lines.append("")
lines.append(f"## 3. 営業・通知 {len(promo)}件——件名一覧のみ。個別確認は不要")
for m in promo:
lines.append(f"- {m['subject'][:40]}")
return "n".join(lines)
ポイントは3つあります。緊急・通常はチェックボックス付きで「処理した/していない」を消し込めるようにすること。AI判定のものに印を付けて、人がひと目で「機械の判断だ」とわかるようにすること。そして営業・通知は件名一覧だけを出して「開かなくてよい」と宣言することです。この3点目が復帰日の心理的負荷をいちばん下げます。
実装コード例4：定型返信の下書きを作る——送信はしない
出力層の2つ目は返信下書きです。緊急・通常に分類されたメールについて、「お待たせした詫び＋本題の受領確認＋回答予定」の骨格をClaude Codeに書かせ、ファイルとして保存するだけにします。
# make_drafts.py — 返信下書きをファイルに書き出す（送信しない）
import json, subprocess, pathlib
DRAFT_PROMPT = """次の問い合わせメールへの返信下書きを日本語で書いてください。
条件:
- 夏季休暇明けの返信である旨を1文で詫びる（過剰に謝らない）
- 相手の依頼内容を1文で復唱して受領を示す
- 具体的な回答や日程はあなたが創作せず「{回答}」「{日程}」の
プレースホルダーで残す
- 社名や担当者名は署名テンプレートに任せるので書かない
- 300字以内、です・ます調
出力は本文のみ。
"""
def make_draft(mail, outdir="drafts"):
pathlib.Path(outdir).mkdir(exist_ok=True)
payload = json.dumps(
{"from": mail["from"], "subject": mail["subject"], "body": mail["body"]},
ensure_ascii=False)
result = subprocess.run(
["claude", "-p", DRAFT_PROMPT + "nn" + payload],
capture_output=True, text=True, timeout=120)
safe_id = mail["uid"]
path = pathlib.Path(outdir) / f"draft_{safe_id}.txt"
path.write_text(
f"To: {mail['from']}nSubject: Re: {mail['subject']}nn{result.stdout}",
encoding="utf-8")
return str(path)
下書きプロンプトにも安全装置を入れています。「具体的な回答や日程を創作せずプレースホルダーで残す」という指示です。AIは問い合わせに対してもっともらしい回答を書いてしまうことがありますが、納期や価格の回答を機械が創作した下書きは、確認する人がうっかり見落とすとそのまま誤回答になります。骨格だけを書かせ、事実は人が埋める分担にします。
メールソフトの下書きフォルダに直接入れたい場合は、imaplibのappendで下書き用メールボックスにDraftフラグ付きのメッセージを追加する方法もあります。この場合も追加先は下書きフォルダであって送信キューではないので、送信は起きません。ただしフォルダ名がサーバーによって「Drafts」「INBOX.Drafts」などと異なるため、listコマンドで実際のフォルダ名を確認してから実装してください。
Claude Codeへの指示プロンプト集——構築と休暇前後で使う5つ
ここまでのコードは、Claude Codeとの対話で組み立てていくのが現実的です。実際の構築・運用で使うプロンプトを5つ挙げます。
プロンプト1（構築・取得層）
imaplibで受信箱を読み取り専用で取得するスクリプトを書いて。
selectは必ずreadonly=Trueで、既読フラグを変えないこと。
SINCEで日付指定できるようにして、結果はJSONで保存。
パスワードは環境変数IMAP_PASSWORDから読むこと。プロンプト2（構築・分類ルールの叩き台）
inbox.jsonの直近100件を読んで、緊急/通常/営業・通知の3分類の
ルール案を作って。差出人ドメイン・件名の頻出語を集計して、
「このドメインは既知顧客か要確認」のリストも出して。
判定コードはまだ書かず、ルール表だけをMarkdownで。プロンプト3（休暇前・known_domainsの棚卸し）
known_domains.txtと過去3か月の受信ログを突き合わせて、
取引があるのにリストに入っていないドメインの候補を挙げて。
判断がつかないものは推測で追加せず「要確認」欄に分けて。プロンプト4（休暇明け・朝の実行）
fetch_mails.py→classify_rules.py→classify_ai.py→make_report.py
→make_drafts.pyの順で実行して、report.mdと drafts/ を作って。
実行前にどのコマンドを実行するか一覧で見せて。
メール送信に該当する操作は一切しないこと。プロンプト5（休暇明け・精度の振り返り）
report.mdに対する私の手動修正（ラベルの付け替え）をdiffして、
誤分類のパターンを整理して。ルールに昇格できる規則があれば
classify_rules.pyへの追加案をコードで提示して。適用は私が確認してから。プロンプト4の「実行前にコマンド一覧を見せて」は、ヘッドレスではなく対話実行時の安全確認です。加えてClaude Codeの設定でBashの許可リストを絞り、sendmailやcurlによるSMTP送信系の操作を許可しない構成にしておくと、エージェント側からの送信経路も塞げます（公式ドキュメント: Settings）。
運用の3フェーズ——お盆前1週間から復帰日まで
Phase 1（休暇前の1週間）：構築とドライラン。取得〜レポート生成までを組み、直近1か月の受信メールで試運転します。ここでの主作業はコードよりもknown_domains.txtの整備です。既存顧客・取引先のドメインをどれだけ網羅できるかが緊急判定の精度を直接決めます。あわせて不在自動応答の文面に「緊急のご用件は◯◯へ」という代替連絡先を入れておくと、本当の緊急案件はメール以外の経路で届くようになり、仕組み側の責任範囲が明確になります。
Phase 2（休暇中）：基本は放置、任意で日次実行。設計上、休暇中に何かを動かす必要はありません。復帰日にまとめて処理すれば足ります。当番制で誰かが軽く見る運用にする場合は、取得と分類だけを日次で回して「緊急◯件」のサマリーをチャットに通知する構成にすると、当番は緊急欄だけ見ればよくなります。この場合も送信系は組み込みません。
Phase 3（復帰日の朝）：リストの上から消し込む。パイプラインを1回実行し、report.mdの緊急欄から順に、下書きを確認・修正して手で送信します。処理が終わったら、自分が付け替えたラベルをプロンプト5で振り返り、ルールに昇格できるものを反映します。この振り返りを1回やっておくと、年末年始の休暇では同じ仕組みがそのまま、より高い精度で使えます。
【要注意】よくある失敗パターンと回避策
❌ 失敗1：「せっかくだから」と自動送信まで作り込む
仕分けができると、次は「緊急メールには自動で一次回答を送りたい」という欲が出ます。しかし休暇中は誤送信に気づける人がいない期間です。機械応答の役割はサーバー標準の不在応答が既に果たしています。
⭕ 回避策：送信コードを書かない原則を守る。即時応答の要件が本当にあるなら、それは休暇対応ではなく通常時のサポート体制の課題として、営業日の監視体制とセットで別途設計する。
❌ 失敗2：AIの分類を無条件に信頼して緊急欄しか見ない
分類には必ず誤りが混ざります。特に「新規顧客からの重要な問い合わせ」は既知ドメインに該当せず、文面も丁寧で緊急語を含まないため、通常や営業に落ちやすい典型例です。
⭕ 回避策：復帰日は緊急欄だけでなく通常欄の件名まで目を通す前提で運用する。リストにAI判定マークを付け、機械の判断であることを常に可視化する。判定に迷うものをnormal側に寄せるプロンプト設計も同じ理由です。
❌ 失敗3：顧客メールの本文を無断でそのまま外部AIに渡す
問い合わせメールには氏名・連絡先・契約内容が含まれます。社内の利用ルールを確認せずに本文全文をAIサービスへ送ると、社内規程や顧客との守秘条項に抵触する可能性があります。
⭕ 回避策：着手前に自社のAI利用ポリシーと利用サービスのデータ取り扱い条件を確認する。ルール分類を先行させてAIに渡す件数自体を減らす、本文を冒頭のみに制限する、判定に不要な署名部分を落とすなど、渡す情報の最小化を設計に組み込む。
❌ 失敗4：休暇直前に初めて動かす
メール環境は会社ごとに癖があります。IMAPの認証方式、フォルダ構成、文字コード、HTMLメールの比率——どれも実データで動かして初めて問題が出ます。休暇前日の夕方に初回実行して認証エラーで詰まると、そのまま「今年は手動で」になります。
⭕ 回避策：Phase 1のドライランを休暇の1週間前までに終える。直近1か月分での試運転で、分類の妥当性より先に「そもそも全件取得できているか」を件数で確認する。
よくある質問
Q. メールサーバーの不在自動応答があれば十分ではないですか？
役割が違います。不在応答は送り手への通知であって、受け手側の「休暇明けに何から読むか」問題は解決しません。本記事の仕組みは不在応答を置き換えるものではなく併用する前提で、即時応答はサーバー標準機能に、復帰後の処理順の整理を自作パイプラインに分担させています。
Q. 顧客のメールをAIに読ませても問題ないですか？
会社のAI利用ポリシーと、利用するAIサービスのデータ取り扱い条件の両方を確認してから着手してください。法人利用では入力データが学習に使われない契約形態を選ぶのが基本です。そのうえで、ルール分類を先行させてAIに渡す件数を減らす、本文を冒頭に制限するなど、渡す情報を最小化する設計を推奨します。判断に迷う場合は情報システム部門や法務への確認が先です。
Q. GmailやMicrosoft 365でも使えますか？
どちらもIMAPに対応しているため基本構成は同じです。ただし認証は通常のパスワードではなく、アプリパスワードやOAuth 2.0が必要な場合が多いので、自社テナントの設定を情報システム担当に確認してください。IMAPが許可されていない場合は、エクスポートしたmboxファイルを入力にする構成が確実です。
Q. 返信の送信まで自動化することは技術的にできないのですか？
技術的には可能ですが、本記事では意図的に設計から外しています。休暇中は誤送信を検知・訂正できる人がいないため、送信の自動化はリスクに対してリターンが小さいからです。送信機能を持たない構成にすることで、誤送信が原理的に起きないという構造的な保証を優先しています。
Q. 休暇明けの処理はどの程度楽になりますか？
効果は受信構成によって変わるため断定はできません。目安として、営業・通知系が受信の過半を占める受信箱であれば、「開かなくてよいメール」が事前に確定するだけで全件目視はなくなります。正確に知りたい場合は、Phase 1のドライランで直近1か月分を分類し、自社の3分類の比率を実測するのが確実です。
まとめ：今日から始める3つのアクション
- 今日やること：直近1か月の受信メールを「緊急/通常/営業・通知」に手で分けて比率を見る。営業・通知が多いほど、この仕組みの効きは大きくなります
- 今週中：既存顧客・取引先のドメイン一覧（known_domains.txt）を作る。請求書の宛先一覧や会計ソフトの取引先マスタから抽出すると早く、これだけで緊急判定の土台ができます
- 休暇の1週間前まで：取得〜レポート生成のドライランを終わらせる。分類精度の調整は後からできますが、認証やフォルダ構成の詰まりは実データでしか見つかりません
問い合わせの一次対応は、EC問い合わせ対応の自動化・自治体の問い合わせ振り分けと同じ「分類はルールとAIの2段構え、実行は人が握る」パターンの応用です。休暇対応で一度組んでおけば、平常時の受信トリアージにもそのまま流用できます。
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
参考・出典
- Claude Code公式ドキュメント: Overview（参照日: 2026-08-02）
- Claude Code公式ドキュメント: Headless mode（参照日: 2026-08-02）
- Claude Code公式ドキュメント: Settings（参照日: 2026-08-02）
- Python公式ドキュメント: imaplib（参照日: 2026-08-02）
- Python公式ドキュメント: mailbox（参照日: 2026-08-02）
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
