こんにちは、てつです！
第1回では、Dockerコンテナを24時間体制で最新状態に保ってくれる頼もしい味方「Watchtower」の導入方法を解説しました。
記事リンクはこちら：[【10分で自動化】Watchtowerで行うDockerコンテナの自動アップデート導入ガイド]
これで面倒な手動アップデートから解放され、あなたのサーバーには「専属の管理人」が誕生したわけです。
しかし、完全自動化を手に入れた後に、こんな不安に襲われていませんか？
「自分が寝ている間や仕事中に勝手に更新されて、もしエラーでブログやシステムが止まっていたらどうしよう……」
自動化は便利ですが、ブラックボックス（中身が見えない状態）のまま放置するのは、プロの現場でも非常に危険視されます。
気づかないうちにシステムがダウンしている「サイレント失踪」を防ぐためには、ロボットに「今、何をしたか」を報告させる必要があります。
そこで今回は、Watchtowerのアップデート結果を普段使っているDiscordやSlackへ自動通知する設定を解説します。
この設定を行うことで、サーバーに付きっきりにならなくても、スマホを見るだけで愛車のコンディションを確認するように、いつでも愛用サーバーの健康状態を1秒で把握できるようになります。
実務のインフラ運用現場でも絶対に欠かせない「可視化（モニタリング）」のプロ技術を、あなたの環境に組み込んでいきましょう！
- WatchtowerのDiscord/Slack通知連携に必要な準備と前提知識
- 【実務レベル】Watchtowerとチャットツール（Discord/Slack）を連携させる3ステップ
- docker-compose.ymlに環境変数を追記してDockerの通知を有効化する
- ステップ3：コンテナを再起動してDiscordやSlackにテスト通知が届くか動作確認する検索者が求める最終ゴール（通知の確認）を
WatchtowerのDiscord/Slack通知連携に必要な準備と前提知識
手順に入る前に、今回のゴールに必要な環境を確認しておきましょう。
必要なツール・環境
- 第1回で構築した「Watchtower」が動作するLinux環境（Docker / Docker Composeがインストールされていること）
- 自分が普段使っている「Discord」または「Slack」のアカウント（通知を受け取るチャンネルを自由に作成できる権限）
前提知識
今回は、第1回で作成した docker-compose.yml という設計図に、少しだけ「環境変数（environment）」という設定を追記します。
「ファイルの書き換えを少しやったことがある」というレベルの知識があれば、10分もかからずに完了するので安心してください。
また、今回は「Webhook（ウェブフック）」という技術を使います。難しそうな名前に聞こえますが、これは「特定のアプリ（今回はWatchtower）から、別のアプリ（DiscordやSlack）へ、インターネットを通じて自動でメッセージを投げ込むための専用のURL」のことです。
日常で例えるなら、外部の郵便配達員があなたの家に直接手紙を入れられる「専用ポストの住所」を一時的に発行するようなイメージです。
【実務レベル】Watchtowerとチャットツール（Discord/Slack）を連携させる3ステップ
それでは、実際に手を動かして設定していきましょう。迷わず実践できるよう、ステップバイステップで解説します。
ステップ1：Discord・Slackで通知の受け皿となる「Webhook URL」を発行する
まずは、Watchtowerからのメッセージを受け取るための「専用ポストの住所（Webhook URL）」をチャットツール側で発行します。今回は利用者の多いDiscordとSlackの両方の手順を用意しました。どちらか片方、自分が使いたい方の手順を進めてください。
Discordの場合
- 通知を受け取りたいサーバーのチャンネル（例：#server-notice など）の横にある歯車マーク（チャンネルの編集）をクリックします。
- 左メニューの「連携」を選択し、「ウェブフックを作成」をクリックします。
- 作成されたウェブフックを開き、名前（「Watchtowerロボ」など）を自由につけ、「ウェブフックURLをコピー」をクリックします。
- ※ https://discord.com/api/webhooks/… という長いURLがクリップボードにコピーされます。
Slackの場合
- 通知したいチャンネルのタイトルをクリックし、「インテグレーション」タブを開きます。
- 「アプリを追加する」から「Incoming Webhook」を検索して選択します（未インストールの場合はSlackのAppディレクトリページが開くので、画面に従って追加してください）。
- 通知先のチャンネルを選択し、「Incoming Webhook インテグレーションの追加」をクリックします。
- 画面に表示される「Webhook URL」（https://hooks.slack.com/services/…）をコピーします。
なぜこの設定が必要なの？
Watchtowerというロボットが、世界中にある無数のチャット部屋の中から「まさにあなたのあのチャンネル」を迷わずに見つけ出し、メッセージを確実に届けるための正確な宛先住所が必要だからです。
docker-compose.ymlに環境変数を追記してDockerの通知を有効化する
宛先URLが手に入ったら、次はWatchtower側に「ここに通知を送りなさい」という命令を書き加えます。
前回作成した docker-compose.yml をテキストエディタ（nanoやvimなど）で開き、以下のように変更してください。
version: '3.8'
services:
watchtower:
image: containrrr/watchtower
container_name: watchtower
volumes:
- /var/run/docker.sock:/var/run/docker.sock
# ---- ここから下の「environment」を追加・変更します ----
environment:
- WATCHTOWER_NOTIFICATIONS=discord # Slackを使う場合は「slack」と書き換えてください
- WATCHTOWER_NOTIFICATION_URLS=https://discord.com/api/webhooks/your_actual_webhook_url_here
# ---- ここまで ----
restart: always初学者向け・環境変数の1行解説
プロのコードに必ず登場する、重要な英単語の意味をまとめました。
- environment:
- 解説： ここから下に「環境変数（かんきょうへんすう）」を書きます、という宣言です。
- 何を表しているか： 環境変数とは、「プログラムの本体（イメージ）を一切改造することなく、外側からツールの動きや設定をカスタマイズするためのスイッチ」です。プロの現場では、開発環境と本番環境で接続先を切り替える際などに必ず使われる仕組みです。
- – WATCHTOWER_NOTIFICATIONS=discord
※envファイルでURLを分離するのがベストプラクティスではありますが、今回は簡易的にこの方法を採用します。GitHubにこのファイルをアップロードする場合は必ず分けることを推奨します。
過去にも通知連携をしているのでこちらも併せてご参照ください。
ステップ3：コンテナを再起動してDiscordやSlackにテスト通知が届くか動作確認する検索者が求める最終ゴール（通知の確認）を
設計図の書き換えが終わったら、保存して閉じます。最後に、新しい設定をロボットに読み込ませて起動しましょう。
ターミナルで、docker-compose.yml があるディレクトリに移動し、以下のコマンドを実行します。
docker compose up -dなぜこのコマンドが必要なの？
指示書（YAMLファイル）を書き換えただけでは、現在裏側で動いているロボットは古いルールのまま動いています。
そのため、docker compose up -d を再実行することで、「指示書が新しくなったから、これに基づいて新しく動き直して！」とコンテナを安全にリフレッシュさせる必要があるのです。
正しく設定ができていれば、コマンドを実行して数秒〜数十秒後に、あなたのDiscordまたはSlackへ以下のようなテストメッセージがピコん！と飛んできます。
I am watchtower v1.X.X
Using notifications: discord
Checking all containers nowこの最初のメッセージが確認できれば、無事にWatchtowerとあなたのチャットツールがつながった証拠です！
現役インフラエンジニアが「Docker運用監視の可視化」を絶対にお勧めする理由
ここで、少しだけプロの現場の裏話をお伝えします。
IT企業にある「システム運用監視チーム」といったプロのインフラ現場では、システムを「ただ動かすこと」と同じくらい、「異常や実行結果にすぐ気づける状態を作ること（可視化・モニタリング）」が最重要視されます。
どれだけ優れた自動化システムを作っても、それが成功したのか失敗したのかが外から見えないようでは、エンジニアとしては「半人前」と言わざるを得ません。
今回あなたが構築した仕組みは、まさにプロが数千台のサーバーを管理する現場で実践している「エビデンス（実行ログ）の自動収集」の第一歩です。
こうした「自分の時間を切り売りしないインフラ運用の思想」を初学者の段階から体感しておくことは、将来実務にチャレンジする上で非常に大きなアドバンテージになります。
運用の注意点：Webhook URLは「秘密の鍵」
非常に重要なセキュリティ上の注意点があります。今回取得した Webhook URL は、絶対に他人に教えてはいけません。
このURLは、認証（パスワード入力）なしでそのチャンネルにメッセージを書き込める特別な権利を持っています。もしこのURLがGitHubに公開されてしまったり、ブログやnoteのスクリーンショットに映り込んで外部に漏れてしまうと、悪意のある第三者からあなたのチャットツールへ大量のスパムメッセージを勝手に送り込まれるリスクがあります。
コードをインターネット上に公開する際は、必ずURLの部分を https://discord.com/api/webhooks/XXXXXX のように隠す（マスキングする）癖をつけましょう。
【エラーハンドリング】Watchtowerの通知が届かない時の原因と解決策
「コマンドは正常に通って、Watchtowerも動いているっぽいのに、なぜかDiscordやSlackに何も通知が来ない……」
手順通りにやったはずなのに動かない。これは環境構築において誰もが必ず通る道です。焦ってすぐにネットを闇雲に検索する前に、まずはプロのエンジニアと同じように「ログ」を確認してみましょう。
ターミナルで以下のコマンドを入力し、Watchtowerが吐き出しているエラーの声を聴いてみます。
docker compose logs watchtower画面にズラズラと英語が出てきますが、焦る必要はありません。「エラーメッセージの最後の2〜3行」を凝視してください。そこに答えが書いてあります。
よくあるエラーメッセージ
ログの最下部に、以下のような文字が紛れ込んでいませんか？
Failed to send notificationまたは
Level=error msg="Post \"https://discord.com/api/webhooks/...\": context deadline exceeded"あるいは、メッセージの中に 400 Bad Request や 404 Not Found といった3桁の数字が含まれている場合があります。
どこに注目すべき？
注目すべきは、Failed to send（送信失敗） という単語や、400 404 などのHTTPステータスコードです。これらはすべて、「Watchtowerは通知を送ろうとしたけれど、宛先（URL）が正しくないか、チャットツール側に拒絶された」ということを意味しています。
解決策
この手のエラーの9割以上は、以下のような「タイポ（打ち間違い）やコピペのミス」が原因です。
- docker-compose.yml にWebhook URLを貼り付ける際、最初や最後に余計なスペース（空白）が入ってしまっていないか。
- URLを囲むクォーテーションの対応がおかしくなっていないか。
- WATCHTOWER_NOTIFICATIONS の綴りを間違えていないか（NOTIFICATION と単数形にしてしまうミスが非常に多いです。正しくは末尾に S がつく複数形です）。
一度冷静になって、ステップ2のコードと自分のファイルを1文字ずつ見比べて修正し、再度 docker compose up -d を試してみてください。文字のズレを直すだけで、驚くほどあっさり動き出すはずです。
まとめ：これであなたのサーバーは「喋る管理人」に進化した
お疲れ様でした！今回の要点を振り返りましょう。
- 自動アップデートの不安を解消するには、実行結果をチャットツールへ可視化することがプロの鉄則。
- docker-compose.yml の 「環境変数（environment）」 を使えば、イメージを書き換えることなく宛先（Webhook URL）を安全に設定できる。
- 動かない時は、あわてず docker compose logs の最後の数行を見て、URLのコピペミスやスペルミスがないかを確認する。
これで、あなたのサーバーはただ黙々とアップデートするだけの存在から、自分の仕事をスマホへ健気に報告してくれる「喋る管理人」へと進化しました。
コンテナが壊れる恐怖から完全に解放された、真の自動運用環境の完成です！
次のステップ（次回予告）
通知が来るようになって一安心……と思いきや、次のような新たな疑問やこだわりが生まれてきませんか？
「通知が来るのは嬉しいけれど、WordPressのデータベース（MySQLなど）まで勝手にアップデートされて、データが消えたりしたら怖いな……」
「アクセスの多い昼間に勝手に再起動されると困るから、みんなが寝静まった深夜にだけアップデートを実行したい」
これは非常に鋭い視点です。
次回の第3回は【制御・安全編】として、特定の重要なコンテナを自動更新の対象から「除外」するテクニックや、Cron（クロン）という仕組みを使って「毎週日曜の深夜3時にだけ実行する」といった、実務レベルのスケジュール制御術を徹底解説します。
これができれば、コンテナ自動運用は完全マスターです！
記事でお会いしましょう！
筆者のnote👇
コメント