■ 実務の記録

ChatGPT Workのスケジュールから週報メールを送信した。

メールは予定時刻に送信され、Macのメールアプリでも存在を確認できた。しかし、メールを処理するGASを実行しても、以前にiOSショートカットから送った週報しか検出されなかった。

一見すると、次のいずれかが疑われる状況だった。

• Workからの送信に失敗した
• 宛先エイリアスへ配送されていない
• GASの検索条件が件名や送信元と一致していない
• GASを実行しているGoogleアカウントが異なる
• メールアプリとGmailが別のメールボックスを見ている

調査した結果、メールは配送されていた。

確認できた状態

対象メールの情報は次のとおり。

From: info@e-a2.net
To: fukanosuke@e-a2.net
Subject: [YASHIKI_WEEKLY] 2026年8月2日 屋敷楽屋裏スレ
送信時刻: 2026-08-02 19:03 JST

ヘッダーには、Gmail API経由で送信された記録があった。

Received: ... by gmailapi.google.com with HTTPREST

接続中のGmailアカウント info@e-a2.net でMessage-IDを検索すると、対象メール自体は存在していた。

ただし、付いていたラベルは次の二つだった。

SENT
SPAM

INBOX は付いていなかった。

つまり、送信済みメールとしては存在する一方、同じGoogle Workspaceユーザーのエイリアス宛に届いたメールが迷惑メールとして処理されていた。

GASが見つけられなかった理由

GASで使用していた検索条件は、調査途中で次の形へ整理されていた。

subject:YASHIKI_WEEKLY newer_than:30d

iOSショートカット経由のメールは、この検索で検出された。

一方、Work経由のメールは検出されなかった。

Gmail上で次を指定すると、Work経由のメールも見つかった。

in:anywhere subject:YASHIKI_WEEKLY

このことから、件名や宛先の不一致ではなく、対象メールが迷惑メールに入っているため、通常の検索対象から外れていたと判断できた。

本文には、既存仕様どおり次のマーカーも存在していた。

---YASHIKI_WEEKLY_START---
---YASHIKI_WEEKLY_END---

したがって、メールが通常検索で取得できた後の本文解析には問題がなく、入口の時点で候補へ入っていなかったことになる。

先にコードを直さなかった理由

調査中には、次の変更案も出た。

in:anywhere subject:YASHIKI_WEEKLY newer_than:30d

しかし、今回はすぐには採用しなかった。

in:anywhere を使うと、迷惑メールだけでなく、通常は処理対象に含めたくない領域まで検索範囲が広がる。件名と本文マーカーの両方で厳密に判定するなら実装は可能だが、本来正常なメールを迷惑メールの中から恒常的に回収する設計にする前に、Gmail側の判定を正常化する方がよい。

まず対象メールを「迷惑メールではない」として戻し、次回のWork送信が再び迷惑メールへ入るかを確認する。

再発する場合は、Gmail側で次の条件を使ったフィルタを検討する。

from:info@e-a2.net subject:YASHIKI_WEEKLY

適用する操作は「迷惑メールにしない」とする。

MacのメールやSparkだけでは分かりにくかった点

普段の確認には、Macのメールアプリや、個人Gmailをまとめて読むSparkを使用していた。

しかし、Gmailではメールの状態がフォルダではなく複数のラベルとして管理される。同じメールへ SENT と SPAM が同時に付く状態は、一般的なメールアプリの受信箱だけを見ていると把握しにくい。

今回も、次の現象が同時に起きていた。

• Work側では送信成功
• Gmail内にはメールが存在
• 受信トレイには表示されない
• 通常のGmail検索では見つからない
• GASも候補として取得できない
• 普段確認しているSparkにも現れない

「届いていない」ように見えたが、実際には「届いた直後に迷惑メールへ置かれた」状態だった。

メール入力を自動処理へ使う場合は、配送成功だけでなく、Gmail内でどのラベルが付いたかまで確認する必要がある。

メール入口を残す理由

今回の件だけを見れば、メールを介さずMarkdownを直接保存する方が単純に見える。

ただし、現行の屋敷には複数の入力経路がある。

Workスケジュール
  → メール
  → 週報GAS

iOSショートカットの手動実行
  → メール
  → 週報GAS

Workでの記事制作
  → Markdownと画像をGoogle Driveへ保存
  → 切れ端回収GAS

Google Drive経由の制作フローは、Markdownと画像の組を固定フォルダから回収する既存仕様である。週報は画像を前提としないため、同じ入口へ無理に統合する必要はない。

また、Google Driveコネクタは外部サービス側の仕様変更で利用できなくなる可能性がある。メールは古くから使われている汎用的な入口であり、iOSショートカットから手動送信する代替経路も残せる。

今回の結論は、メール入口を廃止することではない。

メールを入口にする以上、迷惑メール判定も処理経路の一部として扱う、ということである。

今後の確認手順

同様の症状が出た場合は、次の順で確認する。

1. Workやショートカット側で送信成功を確認する
2. Web版Gmailで件名を検索する
3. 通常検索で出なければ in:anywhere または in:spam を付ける
4. INBOX、SENT、SPAM のラベルを確認する
5. Message-IDで対象メールを特定する
6. GASの実行ユーザーを確認する
7. それでも取得できない場合に、検索条件や本文解析を調べる

先にGASを書き換えるのではなく、実メールと実ラベルを確認する。

今回の停止地点はGASではなかった。

週報は予定どおり発射され、メールも届いていた。ただ、Gmailが楽屋裏を迷惑メール置き場へ案内していただけでござった。