Claude Codeのroutineでメール通知が届かないときの確認先

Claude Codeのroutine(定期実行)を回しているのに、完了メールが届かない。実行は成功と表示されているのに、迷惑メールフォルダにも何もない。こうした報告が、GitHubのissueに3件上がっています。

結論から言うと、利用者側の設定ミスとして直せる形では、原因は特定されていません。確かめられるのは「設定が保存されているか」「実行自体は成功したか」「別の経路で結果を受け取れるか」の3点です。

報告されている症状と再現条件

issueは時系列で3件あります。

前の2件がnot plannedで閉じられたため、#96059は「再現し続けているので改めて起票した」という位置づけで立てられました。

#96059の報告者が示した条件は具体的です。

• 平日の毎日実行(cron式で 30 13 * * 1-5)のscheduled routine
• 通知チャネルはEmailだけ有効で、Pushは無効、Slackも無効
• 設定の最終保存は実行の17時間以上前で、「保存直後で反映が遅れた」可能性は低い
• 実行は成功(succeeded)し、最終結果のサマリーも生成された
• 迷惑メールフォルダを確認し、アカウントのメールアドレスも合っている

エラーもログも、画面に出た形跡はありません。届かなかったことを知らせる表示がないので、気づくのは「待っていたメールが来ない」ときだけです。

気になる点 — 無効にしたPushが呼ばれている

#96059には、通知の仕組みを考えるうえで見逃せない観察が書かれています。Pushを無効にしたroutineなのに、実行の最終ステップでエージェントが PushNotification ツールを呼び、「Mobile push requested」という応答が返ったというものです。

PushNotification はClaude Codeのツールで、デスクトップ通知を出し、Remote Controlが接続されていれば携帯へのプッシュも送ります。送信はAnthropicのホスト側の基盤を通ります。ツール一覧にはこの説明があり、長時間のタスクやセッション内のscheduled taskが、席を離れた人に連絡できるようにするためのものと書かれています。

報告者は、エージェントが呼ぶ通知と、プラットフォーム側のチャネル振り分けが同期していないのではないか、と推測しています。ただしこれは報告者の推測で、原因として確認されたわけではありません。コメントの1つも、実行の成否と通知の配信成否を別の状態として記録すべきだ、という設計上の提案に留まります。

追加報告で分かる範囲

#96059には4件のコメントが付いていて、症状の報告は次の3件です(残る1件は設計の提案で、前の節で触れています)。

• 3つの別のクライアントの環境で同じ症状を確認した、という報告
• 同じ症状でうんざりしている、という報告
• 10月22日付で、PushとEmailの両方を有効にした日次routineが8日連続で成功し、どちらの通知も1通も届かなかった、という報告

つまり症状は「Emailだけが落ちる」型(#84645)だけでなく、「両チャネルとも届かない」型(#80880、10月22日のコメント)にも広がっています。ただしコメントの数は少なく、発生率や条件の絞り込みまでは書かれていません。

公式ドキュメントには何が書かれているか

routinesの公式ページ(scheduled tasksの説明)には、通知チャネルの設定項目についての記載がありません。ページにあるのはトリガーの種類、接続先、権限、環境、利用上限、そして「The last run」で始まる警告の対処です。

関連する記述として確実に言えるのは、次の1点です。History欄のSucceededは「セッションがClaude Codeの報告する失敗なしに終わった」ことを示し、プロンプトの作業が完了したかどうかは示しません。通知を送る処理が成功したかどうかも、この表示からは分かりません。

警告が出ているケースは別の話です。警告の読み方はClaude Code Routinesの警告8種に表でまとめています。ここで扱うのは、警告も失敗表示もないのに通知だけ届かないケースです。

切り分けの順番

通知が届かないとき、上から順に確かめます。

設定を開き直して確かめるときは、保存し直してRun nowを1回押す流れが手早い方法です。ただしRun nowは同じタスクで1時間30回までという上限があります。連打せず、1回走らせて結果を待ちます。

CLIから確認したいときは、一覧と直近の実行を /schedule で見られます。

/schedule list
/schedule run

/schedule list はscheduled taskの一覧、/schedule run は即時の実行です。通知の配信状況を見るコマンドではないので、あくまで「実行が走っているか」を確かめる手段として使います。

通知に頼らず結果を受け取る方法

通知チャネルの不具合が直るまで、結果を受け取る経路を通知以外に移す方法があります。どれも公式ページに書かれた仕組みの範囲です。

• Historyを見に行く: 成功した実行の行は、すべて詳細ページのHistoryに残ります。サマリーはセッションを開けば読めます。毎朝見る習慣のあるチームなら、これが最も確実です
• コネクタで書き込ませる: routineは接続したコネクタ経由で外部サービスに書き込めます。公式ページの使用例には、毎晩のIssue整理のあとに要約をSlackへ投稿するタスクが載っています。通知チャネルとは別のしくみなので、チャネルの不具合の影響を受けない可能性があります
• 成果物をリポジトリに置く: プロンプトで、結果をファイルにまとめてブランチにコミットさせる方法です。Claudeが作業ブランチに claude/ で始まる名前を使うことは、公式ページに書かれています

コネクタで書き込ませる場合のプロンプトは、たとえば次のような形になります。これは書き方の一例で、Slackコネクタを接続済みの場合の例です。

最後に、今回の結果を3行以内に要約し、Slackの#dev-reportチャンネルへ投稿してください。
投稿に失敗した場合は、失敗した理由を最終結果の冒頭に書いてください。

2行目の「失敗した理由を冒頭に書く」指示は、実行履歴を開いたときに失敗が見えるようにするためのものです。通知が届かなくても、Historyのサマリーに残ります。

手元のPush通知と、routineの通知を混同しない

Claude Codeの通知まわりには、routineの通知とは別に、ターミナルやスマホ向けの仕組みがあります。それぞれ別の記事で扱っています。

• ターミナルのデスクトップ通知が届かない問題は、Claude Code通知の設定が対象です
• スマホへのプッシュは、Claude Codeの通知をスマホに届ける設定が対象です

この2つで届かない原因(ターミナル側の許可、在席判定、Remote Controlの接続)は、routineのメール通知が届かない症状とは別の話です。ローカルのセッションで通知が正常に出ていても、クラウドで動くroutineのメール通知とは関係がありません。routine全体の仕組みはClaude Code Routines完全ガイドに、外部から起動する方法はfire APIの手順にあります。

まとめ

routineの通知が届かないとき、まず疑うのは自分の設定ではなく、「実行の成功」と「通知の配信」が別の処理だという点です。#96059はオープンのままで、前身の2件はnot plannedで閉じられています。

通知を結果確認の唯一の手段にしないこと。Historyの確認か、コネクタ経由の書き込みを併用しておけば、不具合が続いても業務は止まりません。再現条件を書き足す先は #96059です。