こんにちは、てつです！
前回の第4回連載では、GitHub Actionsの「CD（継続的デプロイ）」を実装し、git pushした瞬間に自宅のコンテナが全自動で最新化される魔法のような環境を作りました。手動でSSHログインしてコンテナをガチャガチャ動かす退屈な日々から卒業し、一気にプロ仕様の「大人の秘密基地」へと昇格しましたね。
しかし、こうして全自動化が進むと、今度は新たな欲が出てきませんか？
「自動デプロイが成功したのか失敗したのか、毎回GitHubの画面をブラウザで見に行くのすら面倒だな……」
――正直、この確認作業のために毎回ブラウザを開くの、スマートじゃないですよね。
今回は、その最後の「めんどくさい」を完全に解消します。 目指すのは、自動化の実行結果（成功・失敗）を、皆さんが普段使い慣れている「Discord」へ即座にプッシュ通知する環境です。
これはIT業界の最前線、特に24時間体制でシステムを監視する「SOC（セキュリティオペレーションセンター）」や「運用監視チーム」のプロが現場で必ず導入している「プッシュ型監視」とまったく同じ思想です。
これが完成すれば、スマホをポケットに入れているだけで、地球の裏側にいても自宅サーバーの状態を1秒で把握できるようになります。「趣味のホームラボ」の枠を超えた、ガチの運用体制を構築しましょう！
なぜ自宅サーバーの監視にDiscordへの自動通知が必要なのか？
具体的な手順に入る前に、なぜプロの現場が「わざわざ画面を確認しに行くこと」を嫌い、チャットツールへの自動通知にこだわるのか、その理由（Why）を解説します。
画面を確認しに行く「プル型」から卒業すべき理由
結論から言うと、「人間は見に行くのを忘れるから」、そして「異常への初動を1秒でも早くするため」です。
手動でブラウザを開いて確認するスタイル（プル型）だと、万が一デプロイがエラーで失敗していても、自分が見に行くまで気づけません。趣味のブログやWikiならまだしも、プロの現場でサービスの停止に気づけないのは致命傷になります。
そこで、システム側から人間に「終わったよ！」「エラーが出たよ！」と能動的に教えてもらう仕組み（プッシュ型）が必要になります。
Discordの「WebHook（ウェブフック）」とは？
今回は、開発者界隈で最も手軽かつ強力な「WebHook（ウェブフック）」という仕組みを使います。
WebHookとは、特定のイベント（今回はデプロイの完了）が起きた際、別のアプリケーション（Discord）にリアルタイムでデータを送り、処理を実行させる仕組みのことです。
これを使って、自宅サーバーの「監視の自動化」の第一歩を踏み出しましょう！
【前提条件】今回の通知環境構築に必要なツール
今回の構築に必要な環境は以下の通りです。
- 第4回までで構築した「GitHub Actions（Self-hosted Runner）」が動作する自宅サーバー環境
- Discordアカウント（および、自分が管理者権限を持つ専用のサーバーとチャンネル）
※今回はSlackでも応用可能ですが、最も手軽に作れて通知のレスポンスが早いDiscordをベースに解説します。
【3ステップ】GitHub ActionsからDiscordへ通知させる手順
手順はシンプルに3つの作業で進めます。画面を一緒に触りながら進めていきましょう。
ステップ1：Discord側で「WebHook URL」を発行する
まずは、GitHub側から通知を受け取るための「窓口（WebHook URL）」を発行します。
１．通知を飛ばしたいDiscordのチャンネルの横にある歯車アイコン（チャンネルの編集）をクリックします。
２．左メニューから「連携サービス」を選択し、「ウェブフックを作成」をクリックします。
３．新しいウェブフックが作成されるので、名前を「GitHub Bot」など好きな名前に変更し、「ウェブフックURLをコピー」をクリックします。
※超重要：このURLは「この宛先にデータを送れば、誰でもあなたのチャンネルに投稿できる」という魔法の鍵です。絶対に他人に教えたり、公開リポジトリに直書きしてプッシュしたりしないでください！
ステップ2：GitHubリポジトリにシークレット（秘密鍵）を登録する
DiscordでコピーしたURLを、安全に管理するためにGitHubへ登録します。第2回の.gitignoreや、前回の環境変数と同じ思想ですね。
１．あなたのGitHubリポジトリのトップページから、「Settings」タブを開きます。
２．左メニューの「Security」項目にある「Secrets and variables」→「Actions」をクリックします。
３．「New repository secret」をクリックします。
４．Nameに DISCORD_WEBHOOK と入力し、Valueに先ほどコピーしたDiscordのURLをそのまま貼り付けます。
５．「Add secret」をクリックして保存します。
ステップ3：GitHub Actionsのワークフロー（YAMLファイル）を修正する
いよいよ、前回作成したデプロイ用のYAMLファイル（.github/workflows/deploy.yml）に、通知の処理を組み込みます。
前回のファイルの最下部に、以下のコードを追記してください。全体の構造（インデント）がズレないように注意しましょう。
- name: Send Discord Notification
# デプロイが失敗しても必ず動かす設定（ここは今のままで完璧です）
if: always()
# 外部ツールは一切呼び出さず、Linux標準のシェル（bash）で実行します
shell: bash
env:
DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK }}
STATUS: ${{ job.status }}
# Ubuntuに標準搭載されている「curl」関数を使って、直接Discordへ送信します
run: |
# 成功なら緑色（3066993）、失敗なら赤色（15158332）の数値を決定
if [ "${{ job.status }}" = "success" ]; then
COLOR=3066993
else
COLOR=15158332
fi
# Discordに送るデータ（JSON形式）をその場で組み立て
JSON_DATA=$(cat <<EOF
{
"embeds": [{
"title": "Deployment ${STATUS}!",
"description": "GitHub Actionsのデプロイ処理が完了しました！（結果: ${STATUS}）",
"color": ${COLOR}
}]
}
EOF
)
# curlコマンドでDiscordのWebHook URLへ直接データを送信
curl -H "Content-Type: application/json" -X POST -d "$JSON_DATA" "$DISCORD_WEBHOOK"動作確認：git pushでスマホにプッシュ通知を飛ばす
設定が完了したら、コードを保存して git push してみましょう！
数分後、スマホやPCのDiscordアプリが「ピコン！」と鳴り、以下のような綺麗な通知が届くはずです。
- 成功時：緑色のバーとともに「Deployment Result」の通知が届く
- 失敗時：赤色のバーでエラーを知らせてくれる
わざわざGitHubの画面を開かなくても、ポケットの中で「今、自宅サーバーが最新化されたな」と分かる快感を、ぜひ体感してください！
現役インフラエンジニアが語る「プッシュ型監視」がプロ仕様である秘密
① 「Bad Request」や「Invalid Webhook Token」が出る場合
注目すべき場所：GitHub Actionsの実行ログを開き、Send Discord Notification ステップの内部ログにあるエラーメッセージ。
原因：作業1でDiscordからコピーした「WebHook URL」が、作業2でGitHubに登録する際に正しく貼り付けられていない（末尾の文字が欠けている、または余計なスペースが入っている）可能性が非常に高いです。
対策：GitHubの「Settings」→「Secrets and variables」から、登録した DISCORD_WEBHOOK を一度削除し、もう一度正確にURLをコピーし直して再登録してみてください。
② エラー時に通知ステップがスキップされてしまう場合
注目すべき場所：GitHub Actionsのグラフィカルな実行ルート画面で、通知ステップが赤でも緑でもなく「灰色のアイコン」になっている状態。
原因：YAMLファイルの記述で、if: always() のインデント（文字の開始位置）がズレているか、スペルミスをしている可能性があります。
対策：if: always() は、必ず - name: や uses: と同じ縦のライン（インデント）に揃える必要があります。スペースの数がズレていないか、もう一度エディタで確認してみましょう。
③EACCES: permission denied, rmdir というエラーで最初のステップから進まない
注目すべき場所： GitHub Actionsの実行ログの最初のステップである Checkout code（または actions/checkout@v4）の内部ログ。末尾に monitoring/grafana や npm_data などのフォルダ名が記載されているのが特徴です。
原因： サーバー内で動かしているDockerコンテナが、データの保存先として「GitHub Actionsの作業用フォルダ（相対パス ./）」を指定してしまっていることが原因です。Dockerコンテナが裏で「管理者権限（root）」を持った強力なフォルダを勝手に生成してしまい、Actionsのお掃除ロボット（一般ユーザー権限）がそのフォルダを削除できずに立ち往生（墜落）してしまいます。
対策： 1. 一度サーバーのターミナルで docker compose down を実行し、フォルダを掴んでいるコンテナを安全に停止させます。 2. sudo rm -rf [エラー画面に出ているフォルダのパス] を実行し、詰まりの原因となっていたフォルダを強制的に一度綺麗に削除します。 3. docker-compose.yml を開き、データの保存先（volumes: の左側）を ./npm_data のような相対パスではなく、/home/yoshihiro/npm-data のような「絶対パス（フルパス）」に書き換えて、作業フォルダの外側へデータの引っ越しを行ってください。
【トラブルシューティング】Discordへ通知が来ない時のエラーハンドリング
① repository not found や Unable to resolve action というエラーが出る
- 注目すべき場所： GitHub Actionsの実行ログを開き、
Send Discord Notificationステップ、または一番最初のPrepare all required actionsの内部ログ。 - 原因： 通知に使用している外部ツール（プラグイン）の作者がリポジトリを削除してしまったか、記述したバージョン（例：
@v1など）が間違っている、あるいは大文字・小文字のタイポ（打ち間違い）があることで、GitHub側がツールを見つけられずに墜落しています。また、サーバーのネットワーク環境（ファイアウォール等）によって外部ツールのダウンロード通信がブロックされた場合も、このエラーになります。 - 対策： 外部ツールのダウンロード（
uses:）を使用するのをやめ、今回の記事で紹介した Linux標準のcurlコマンドを使った内製化コード（run:） に書き換えてみてください。サーバー内部の機能だけで処理が完結するため、外部の通信エラーやツールの消滅リスクを100%回避できるようになります。
② ログ上はエラーもなく成功しているのに、Discordが静まり返っている
- 注目すべき場所： GitHub Actionsの実行ログを開き、最下部の
Send Discord Notificationステップの内部ログ。 - 原因： 送信処理自体は正常に終了している（エラーになっていない）にもかかわらず届かない場合、GitHubの「Secrets」に登録した
DISCORD_WEBHOOKのURLそのものが、Discordの「別のチャンネルのURL」になってしまっているか、WebHookの設定自体がDiscord側で削除されている可能性があります。 - 対策： 1. Discordのチャンネル設定（歯車マーク）から「連携サービス」→「ウェブフック」を開き、通知を飛ばしたいチャンネル（例：#git-push結果通知）のURLを正しくコピーし直します。 2. お使いのPCのターミナルやコマンドプロンプトから、直接以下のテストコマンドを実行し、URLが生きているか確認してください。
curl -H "Content-Type: application/json" -X POST -d '{"content":"テスト通知です"}' "ここにDiscordのWebHookURL"・スマホやPCのDiscordに「テスト通知です」と届くことが確認できたら、そのURLをもう一度GitHubのSecretsに上書き登録（再設定）してください。
まとめと次回予告（第6回：自動バックアップ術へ）
お疲れ様でした！「CI（自動チェック）」「CD（自動デプロイ）」に続き、今回は「監視・通知」という、自宅DevOpsの主要な三種の神器がすべて揃いました。これであなたのホームラボは、プロの現場に限りなく近い、自律駆動するシステムへと進化しました。
しかし、ここまで完璧な自動化環境が出来上がると、今度は「別の恐怖」が生まれませんか？
「もし今、自宅サーバーが物理的に故障したり、雷による停電が起きたら、今まで溜めた設定やデータはどうなるんだろう……？」
せっかく構築した最強の環境が、一瞬で水の泡になるのは避けたいですよね。
そこで次回の第6回（連載最終章）は、自宅サバ内のデータベース（DB）や重要設定ファイルを、自動でGitHubのプライベートリポジトリへ安全に避難させる【鉄壁のデータ保護・自動バックアップ術】をお届けします！
これができれば、万が一自宅サーバーが物理的に大破しても、新しいPCを買ってきて10分で完全に元の状態へ復元できるようになります。 「守り」まで固めてこそ、一流のインフラエンジニア。次回もどうぞお楽しみに！
★あなたの自宅サーバーは無事にSSHを卒業できましたか？
「プッシュして動いた時、ニヤニヤが止まらなかった！」「ここで別のエラーが出た！」など、ぜひX（旧Twitter）やコメントで教えてくださいね。皆さんのホームラボ報告、楽しみに待ってます！
コメント