GitHub Actions失敗通知の設定｜メールだけに頼らず見逃しを減らす

GitHub Actionsの通知は、数を増やすだけでは見逃しを減らせません。対応が必要な失敗だけを、原因を調べられる情報と一緒に届けることが大切です。順番は3段階です。まずGitHub標準の失敗通知を有効にします。次にActions画面のジョブ要約(=実行結果ページに出るメモ)を整えます。チームで共有したくなったときだけ、SlackやMicrosoft Teamsなどの外部通知を足します。

結論：標準通知・ジョブ要約・共有通知の3段階で備える

最初から外部サービスへ集約しないでください。必要な速さと運用人数に合わせて、段階的に選びます。

手段	向いている場面	絞り込み	主な注意点
GitHub標準通知	個人や少人数で、まず失敗を把握したい	失敗したworkflow runだけに設定できる	自分が起動したrunの通知が中心。チーム全体の監視の代わりにはならない
ジョブ要約	Actions画面で原因調査を早めたい	stepの条件式で出力を制御できる	通知経路ではない。単独では画面を開くまで気づけない
通知専用workflow	workflow名、ブランチ、結果で通知先を分けたい	workflow_runの条件式で制御できる	権限の強い後続workflowで、信頼できない成果物を処理しない
SlackやTeamsへのWebhook	チームの共通窓口で対応状況を追いたい	送信側または受信側で制御する	送信URLの秘密管理、重複送信、外部サービス障害への備えが必要

通知先を増やす前に、決めることが2つあります。誰が確認するか。どの失敗へ対応するかです。失敗は「すぐ対応する」「営業時間内に確認する」「記録だけ残す」に分けます。本番デプロイや既定ブランチのテスト失敗は即時通知、試作ブランチの任意検査はActions画面への記録だけ、という分け方です。すべてを同じ場所へ流すと、重要な通知が埋もれます。failureだけでなく、cancelled(取り消し)やtimed_out(時間切れ)を通知するかも決めてください。

もう1つ、大事な穴があります。定期実行(schedule)自体が起動しなければ、失敗通知は出ません。失敗の通知と、「動かなかった」の検知は別ものです。重要な処理では「予定時刻までに成功記録がない」ことを別に見張ります。二重実行や再実行の設計はcron自動化の設計、長時間実行への停止条件はGitHub Actionsが終わらないときの対策も参考にしてください。

GitHub標準の失敗通知を設定する

GitHub公式の通知設定では、GitHub内通知またはメールを選び、失敗したworkflow runだけに絞れます。手順は次のとおりです。

1. 対象リポジトリをWatch(=更新を受け取る設定)にします。
2. 画面右上の自分のアイコンから「Settings」を開きます。
3. 「Notifications」を開き、「System」内の「Actions」を探します。
4. 「On GitHub」か「Email」を選びます。
5. 「Only notify for failed workflows」を選ぶと、失敗時だけに絞れます。

画面の項目名や場所はUIの変更で変わることがあります。設定するときは、その時点の公式ページと実画面で確認してください。

ここで1つ、範囲の誤解に気をつけてください。公式の説明にあるのは、自分が起動したworkflow runの完了通知です。「Watchしていればリポジトリ内の全失敗が全員に届く」仕組みとして書かれてはいません。個人の通知と、チーム共通の監視は分けて考えます。チーム全体で拾いたい失敗は、後述の通知専用workflowや外部通知で設計します。

scheduleで動くworkflowの通知先も落とし穴です。通知は最初にworkflowを作ったユーザーへ送られます。別のユーザーがcron構文を更新するとその人へ、無効化後に再有効化するとその人へ、通知先が変わります。個人の設定だけをチーム全体の監視手段にしないでください。届かないときは、Watch、workflowが起動したか、通知先メールの順で確認します。

ジョブ要約で原因調査の入口を残す

GITHUB_STEP_SUMMARYへMarkdownを書き込むと、workflow runの要約画面へ情報を表示できます(公式のworkflowコマンド解説)。次は、失敗したときだけ確認項目を追加する最小例です。failure()は、同じjobの先行stepか、依存関係にある祖先jobのどれかが失敗するとtrueになります。

- name: ビルド
  run: npm run build

- name: 失敗時の確認先を要約
  if: ${{ failure() }}
  shell: bash
  run: |
    echo "## ビルド失敗" >> "$GITHUB_STEP_SUMMARY"
    echo "- workflow: $GITHUB_WORKFLOW" >> "$GITHUB_STEP_SUMMARY"
    echo "- branch: $GITHUB_REF_NAME" >> "$GITHUB_STEP_SUMMARY"
    echo "- commit: $GITHUB_SHA" >> "$GITHUB_STEP_SUMMARY"

要約にはworkflow名、ブランチ、commit、失敗した工程、担当者が最初にすることを載せます。ログ全文は転記せず、Actions画面で確認します。公式案内では要約はstepごとに1MiBまでで、1jobに表示されるstep要約は最大20個です。また、要約のアップロードが失敗しても、stepやjobの成否には影響しません。要約が存在すること自体を合格条件にしたい場合は、別の検査が必要です。

ジョブ要約は通知そのものではありません。メールやチャットへ送る機能ではなく、通知を受け取った人が調査を始めるための入口です。検算の組み方はGitHub Actionsで記事サイトを自動検品する方法で確認できます。

Slack・Teams・通知専用workflowへ安全に広げる

外部通知は、本番や既定ブランチなど、対応が必要な範囲に絞ります。本文はリポジトリ、workflow、ブランチ、結果、実行URL、担当までで十分です。ログ全文やソースコードはGitHub側で確認します。通知先は、普段チームが見ている場所に合わせて選びます。

• Slackを使っているチーム: Incoming Webhookが入口です。専用URLへJSONをHTTP POST(=決まった形の文字を送信)すると、チャンネルへメッセージが届きます。このURL自体が秘密情報です。公開リポジトリなどで共有してはいけません。送信は通常HTTP 200とokが返りますが、不正なJSONや無効なURLでは400番台が返る場合があります。stepの成功だけでなく、応答も確認してください。
• Microsoft Teamsを使っているチーム: 古いMicrosoft 365 Connector(Office 365 Connector)は公式案内で廃止へ向かうと明記されており、新規導入には使いません。現行の案内は、Workflowsの「When a Teams webhook request is received」を使う方法です。Workflowsは特定ユーザーに紐づくため、所有者が不在になると孤立することがあります。継続運用には共同所有者を設定してください。仕様や利用できるチャネル種別は変わりやすいので、導入時点の公式案内で確認してください。
• workflow名・ブランチ・結果をコードで厳密に絞りたい場合: 通知専用workflowをworkflow_runで作ります。

通知専用workflowをworkflow_runのcompletedで起動すると、先行workflowの成否にかかわらず起動します(公式のイベント解説)。github.event.workflow_run.conclusion == 'failure'のような条件をjobへ付け、必要な結果だけを送ります。workflow_runで連鎖できるのは3段階までで、対象のworkflowファイルが既定ブランチに存在するときだけ発火します。

安全上の注意が1つあります。後続workflowは、先行workflowが持たなかったSecretsや書き込み権限を持てる場合があります。外部からのPull Request由来など、信頼できないコードの成果物やキャッシュを、権限の強い通知workflowで処理しないでください。実行URLなど固定した項目だけを渡し、権限を増やさない構成から始めます。

通知の連打にも備えます。Teams側の公式案内では、チャネル単位の送信上限(例: 1秒4件など)と、超過時のHTTP 429に対する指数バックオフ(=待ち時間を倍々に延ばす再試行)が示されています。この上限値は通知サービス側の値で、変わることがあります。導入時点の公式案内で確認してください。大量の失敗が同時に出たとき、無制限に再試行すると通知経路そのものが詰まります。同じ失敗をまとめる重複排除と、再試行の上限を先に決めておきます。

秘密情報を通知へ含めない

Webhook URLやtokenはworkflowファイルへ直接書かず、GitHub ActionsのSecretsへ保存します。公式のSecrets利用手順では、値をactionの入力または環境変数で渡し、可能ならコマンドラインで渡さず、環境変数や標準入力を使うよう案内されています。コマンドライン引数は他から見える可能性があるためです。

Secretsの自動伏字は絶対ではありません。変換した値や、JSONなどの構造化データにまとめた値は露出する可能性があります。伏字があるからといって、ログ全文や機微情報を外部通知へ流してよい保証にはなりません。APIキー、認証ヘッダー、.env、個人情報、ログ全文、未公開コードは通知へ含めません。秘密情報の確認リストも利用してください。露出が疑われる場合は、該当のSecretを無効化・再発行します。

意図的な失敗で到達テストをする

設定して終わりにせず、経路を1回だけ実際に通します。

1. 本番デプロイ、課金API、削除、顧客向けの外部送信が動かないテスト用ブランチか、手動実行のworkflowを用意します。
2. わざと失敗するstepを一時的に入れて、実行します。
3. 対象の失敗だけで通知が届くか、本文からrun URLが開けるか、秘密が混ざっていないか、同じ失敗が重複して届かないかを確認します。
4. 通知の送信自体が失敗したとき、workflowのログに残るかも確認します。
5. 確認が済んだら、テスト用の失敗stepを必ず消します。

運用後は、通知件数、見逃し、対応不要だった通知、気づくまでの時間を定期的に振り返ります。不要な通知が多ければ条件を狭め、見逃しがあれば受信者と経路を見直します。

よくある質問

GitHub Actionsが失敗したのにメールが届かないのはなぜですか

対象リポジトリをWatchしているか、通知設定の「Actions」でメールを選んでいるか、workflow run自体が起動したかを順に確認します。標準通知は自分が起動したrunが中心です。scheduleの場合は、workflowの作成者、cron構文を最後に変更した人、再有効化した人へ通知先が変わっている可能性もあります。

特定のworkflowやブランチだけ通知できますか

GitHub標準通知は「失敗したrunだけ」への絞り込みには使えますが、workflow名やブランチ別の細かな振り分けには向きません。通知専用workflowをworkflow_runで作り、対象workflowとブランチを絞ったうえで、workflow_run.conclusionがfailureのときだけ通知jobを動かす方法を検討します。

failure()とalways()はどう使い分けますか

失敗時だけ要約や通知を動かすならfailure()が基本です。always()はキャンセル後もtrueになります。公式は、重大な失敗があり得る処理へのalways()の利用を避け、成功・失敗にかかわらず動かしたい場合の別案としてif: ${{ !cancelled() }}を示しています。なおfailure()は実行中の失敗しか見られません。scheduleが起動しなかった事実は検知できないので、実行欠落の監視は別に設計します。

SlackとMicrosoft Teamsのどちらへ通知すればよいですか

普段チームが確認している場所へ合わせるのが第一です。SlackならIncoming Webhook、Teamsなら廃止へ向かう旧Connectorではなく、Workflowsを候補にします。どちらの場合も、送信URLの秘密管理と、意図的な失敗による到達テストを行ってください。

通知にエラーログ全文を載せてもよいですか

載せない構成を推奨します。通知にはworkflow名、ブランチ、結果、実行URL、最初の確認先だけを載せ、詳細は権限管理されたActions画面で確認します。ログにはSecretや個人情報が混ざる可能性があるためです。

まとめ

GitHub標準の失敗通知を土台にし、ジョブ要約で調査を短くし、共有が必要になったときだけSlack、Teams、通知専用workflowへ広げます。次にやることは3つです。

• 対象リポジトリをWatchし、通知設定の「Actions」で失敗時だけの通知を有効にする(その時点の公式画面で項目名を確認する)。
• 重要なworkflowにfailure()+GITHUB_STEP_SUMMARYの要約stepを1つ足し、失敗時に最初に見る情報を残す。
• テスト用ブランチでわざと1回失敗させ、通知の到達、秘密の混入なし、重複なしを確認してからテスト用stepを消す。

公式一次情報

確認日: 2026-07-26

• Notifications for workflow runs - GitHub Docs: 自分が起動したworkflow runの完了通知と失敗時だけへの絞り込み、schedule通知の宛先が作成者・cron更新者・再有効化した人へ変わる仕様。
• Managing GitHub Actions notifications - GitHub Docs: 通知設定のSystem > ActionsでOn GitHubまたはEmailを選び、「Only notify for failed workflows」で失敗時だけに絞る手順。
• Workflow commands for GitHub Actions - GitHub Docs: GITHUB_STEP_SUMMARYでrunの要約ページへMarkdownを表示する方法、stepごと1MiB・1jobあたり最大20個の制限、アップロード失敗がjobの成否に影響しないこと。
• Evaluate expressions in workflows and actions - GitHub Docs: failure()が先行stepや祖先jobの失敗でtrueになる条件、always()の危険性と!cancelled()の代替案。
• Events that trigger workflows - GitHub Docs: workflow_runのcompletedが成否にかかわらず発火すること、conclusionでの絞り込み、3段階までの連鎖、後続workflowの権限に関する安全上の注意。
• Using secrets in GitHub Actions - GitHub Docs: Secretをactionの入力や環境変数で渡す方法と、コマンドラインで渡すことを避ける案内。
• Sending messages using incoming webhooks | Slack Developer Docs: Incoming Webhookの仕組み、Webhook URLが秘密であること、送信時のHTTP応答の確認。
• Webhooks and connectors - Teams | Microsoft Learn: Microsoft 365 Connectorsの廃止方針と、Workflowsを使う現行の案内、所有者不在時の注意。
• Create & Send Actionable Messages - Teams | Microsoft Learn: チャネル単位の送信上限と、HTTP 429時の指数バックオフの案内。