先に要点
- 英語の watchdog は「番犬」。IT では 「定期的に生存確認(キープアライブ)を受け、来なくなったら相手を強制リセットする仕組み」 全般を指す総称。
- 大きく分けて ハードウェアウォッチドッグタイマー(WDT) / OS 側の watchdog(systemd / watchdogd) / アプリの liveness probe(Kubernetes など) / Python の watchdog ライブラリ(ファイルシステム監視) の 4 系統がある。同じ名前で別物。
- 共通の動作は 「監視対象が定期的に
kick(リセット信号)を送る → 来なくなったら強制再起動」。ハングしたプロセスや OS をフリーズ状態から救う最後の砦。 - 導入する前に 「再起動で本当に直るのか / 暴走ループにならないか / 状態は壊れないか」 を必ず検討する。安易な watchdog は障害を隠して根本原因を覆い隠す。
「サーバが固まったら自動で再起動してほしい」「systemd watchdog って何?」「Python の watchdog ライブラリって、サーバ運用のあれと同じもの?」 ── 「ウォッチドッグ」 という言葉は ハードウェア / OS / クラウドネイティブ / ライブラリ など、全く違うレイヤで使われていて、混乱しがちです。
ざっくり言うと、ウォッチドッグの本質は 「定期的な生存確認 + 来なくなったら相手を強制再起動」 の 1 行に尽きます。実装のレイヤが違うだけで、考え方はどれも同じ「番犬」です。
この記事では、語源から始めて、ハードウェア WDT、OS の watchdog、アプリの liveness probe、Python の watchdog ライブラリまでを整理し、それぞれをいつ使うべきかを示します。
語源 — なぜ「番犬」と呼ぶのか
watchdog は文字通り 「見張りの犬」 です。家を留守にするときに番犬を置いておくと、不審者が侵入しても主人の代わりに反応してくれる ── これが IT 用語としての watchdog のメタファです。
主人 = 監視される側
サーバ、プロセス、組み込み機器など、「正常に動いていることを示し続ける義務がある側」。具体的には、定期的にキープアライブ信号(俗に kick / pet / heartbeat と呼ぶ)を番犬に送る。
番犬 = ウォッチドッグ
主人からの信号が 一定時間届かないと「主人が倒れた」と判断して、システムを強制再起動したり、アラートを上げたりする。
よく似た言葉
heartbeat(死活信号)、health check(状態確認 API)、liveness probe(Kubernetes 用語)、keepalive(TCP / アプリ層)などはすべて「生きていることを定期的に示す」同じ系譜の用語。
「定期的な生存確認 + 異常時の自動アクション」 という構造を覚えておくと、どのレイヤの watchdog に出会っても話の筋が分かります。
ハードウェアウォッチドッグタイマー(WDT)
歴史的な原点は ハードウェアの専用回路 です。組み込み機器や産業用機器、サーバのマザーボードにも載っていることがあります。
基本動作
マイコンや CPU の外側に 独立したタイマー回路(WDT = Watchdog Timer)を置く。CPU 側のソフトウェアが一定間隔で WDT にリセット信号を送ると、タイマーがゼロからカウントし直す。送らなければカウントが満了して、WDT がハードウェアリセット信号を CPU に発火する。
なぜハードウェアか
CPU が完全にハングすると、ソフトウェアによる監視は一切動かない。CPU の外側にある独立した回路でなければ、フリーズした自分自身をリセットできない。
どこで見るか
自動車の ECU、医療機器、産業用ロボット、宇宙機、IoT 機器、ルーター、家電など。「人が手で再起動しに行けない」「24 時間止められない」機器ではほぼ標準装備。
サーバ側にもある
x86 サーバの BMC / iLO / iDRAC や、データセンタの IPMI 経由でハードウェアウォッチドッグ機能を呼び出せる機種がある。Linux の /dev/watchdog はこれを叩くインタフェース。
ハードウェアウォッチドッグは、「ソフトウェアが完全に死んでも復旧できる最後の砦」 として組み込み分野で歴史が長いものです。
OS 側のウォッチドッグ — Linux の /dev/watchdog と systemd
Linux にはハードウェア WDT を叩くためのカーネルインタフェースがあり、それを systemd が使いこなします。
/dev/watchdog
カーネルが提供するキャラクタデバイス。プロセスが定期的にこのデバイスに書き込むと、ハードウェア WDT がリセットされる。書き込みが途絶えると、設定時間後にマシンがハードウェアリブートされる。
watchdog デーモン
古くからある watchdog パッケージ(Linux watchdog daemon)が、定期的に /dev/watchdog へ書き込む役を担う。プロセス監視やネットワーク疎通など複数のチェックを束ね、どれか落ちたら kick を止めて再起動を促す設定もできる。
systemd の watchdog 機能
systemd はサービスごとの watchdogを持つ。Unit ファイルに WatchdogSec=30s を書くと、対象プロセスが 30 秒ごとに sd_notify(WATCHDOG=1) を呼ばないと systemd がそのサービスを再起動する。
RuntimeWatchdogSec
systemd 自体が /etc/systemd/system.conf の RuntimeWatchdogSec= でハードウェア WDT を握る。PID 1 が止まるレベルの事故が起きた場合、ハードウェアレベルでリブートさせる二段構え。
「サービス単位の watchdog」 と 「OS 全体の watchdog」 を systemd が階層的に統合しているのが、現代の Linux サーバ運用の標準です。
systemd watchdog の最小例
systemd で watchdog を効かせる設定の一例は次のようなものです(イメージ)。
[Service]
ExecStart=/usr/bin/myapp
WatchdogSec=30s
Restart=on-failure
RestartSec=5s
アプリ側は 30 秒以内に sd_notify(WATCHDOG=1) を呼ぶ実装が必要。これにより「ハングして応答しないが、プロセスは生きている」状態を検知して再起動できるようになります。
アプリ側のウォッチドッグ — Kubernetes の liveness probe
クラウドネイティブ時代の watchdog は、コンテナオーケストレータが担います。Kubernetes の liveness probe がその代表例です。
liveness probe
Pod 内のコンテナが定期的にヘルスチェックエンドポイントを叩かれる。一定回数失敗すると、Kubernetes がそのコンテナを強制的に kill して再生成する。watchdog の概念をそのまま分散環境に持ち込んだ仕組み。
readiness probe との違い
liveness = 「死んでいるなら殺し直す」、readiness = 「準備できていないならトラフィックを送らない」。前者は再起動アクション、後者はルーティング制御。役割を混同しがち。
startup probe
起動が遅いアプリ向けに、起動完了までは liveness を保留するためのプローブ。Java の Spring Boot や .NET など、起動に数十秒かかるサービスで使う。
Kubernetes / ECS / Cloud Run / App Service など、現代のオーケストレータはすべて 「ヘルスチェックが NG なら再起動」 という watchdog 思想で組まれています。詳細は 監視の基本 や Kubernetes の使いどころ も参照してください。
Python の watchdog ライブラリ — まったく別物
ここで注意したいのが、Python の watchdog パッケージです。これまで説明した「番犬」とは用途が全く違います。
何をするライブラリか
ファイルシステムのイベントを監視するライブラリ。「フォルダ A に新しいファイルが置かれたら処理する」 「ファイルが変更されたら自動で再ビルドする」 のような用途。OS の inotify(Linux) / FSEvents(macOS) / ReadDirectoryChangesW(Windows) を抽象化している。
混同しないための注意
「Python で watchdog」 と聞くと、つい systemd watchdog や liveness probe を思い浮かべがちだが、Python の watchdog はプロセス監視ではなくファイル監視。文脈で必ず確認する。
類似ライブラリ
Node.js なら chokidar、Go なら fsnotify。いずれも「番犬」ではなく「ファイル変更通知」。同じ「watch」系の名前でもレイヤが違うことを意識する。
「watchdog」 という単語に出会ったら、「番犬(死活監視)」 なのか 「ファイル監視」 なのか、まず文脈で切り分けるのが大事です。
まとめ表 — 4 系統の watchdog
ここまでの整理を 1 つの表にまとめます。
| レイヤ | 代表例 | 監視対象 | 異常時の動作 |
|---|---|---|---|
| ハードウェア WDT | マイコン / BMC / IPMI | CPU 全体のハング | 強制ハードウェアリセット |
| OS デーモン | Linux watchdog / /dev/watchdog | カーネル / 主要プロセス / 疎通 | マシン再起動 |
| サービス単位 | systemd WatchdogSec | 個別のデーモン / アプリ | サービス再起動 |
| コンテナ / クラウド | Kubernetes liveness probe | コンテナ内のアプリ | コンテナ kill + 再生成 |
| ライブラリ | Python watchdog / chokidar | ファイルシステムの変更 | (イベント通知のみ) |
下に行くほど細かい粒度で観察できる代わりに、自分自身が固まれば検知できない。だから現代の本番システムは ハードウェア WDT → systemd → liveness probe と多層で番犬を置きます。
ウォッチドッグを入れる前に考えること
watchdog は強力な反面、運用設計を誤ると障害を隠して悪化させる道具になりがちです。導入前に必ず次を考えます。
「再起動すれば直る」 が成立する範囲を見極めず、reflex 的に watchdog を入れると、「サービスは動いているが、実はずっと壊れている」 という最悪の状態を作ります。
AI 時代の watchdog
最近は AI エージェント(Claude 系コーディング、AutoGPT 系)を本番で動かすときの「AI そのものに対する watchdog」も話題に上がります。
無限ループ対策
LLM エージェントが無意味な操作を延々と繰り返すパターンに対し、タイムアウト / 試行回数上限 / トークン消費上限で打ち切る仕組みが必須。これは「AI 用 watchdog」 と呼ばれることもある。
人間の介入トリガ
エージェントが危険な操作(削除 / 課金)に踏み込もうとしたら強制停止して人間に確認を求める仕組み。「AI に勝手に走らせない」ガードレールとしての番犬。
コスト監視
LLM API のトークン消費が想定を超えたら自動停止させる watchdog。LLM アプリの観測性と合わせて、暴走による高額請求を防ぐ。
ハードウェア時代から続く「番犬」 の概念が、AI エージェントの運用という新しい場面でも、形を変えて重要になっているのが現状です。
ウォッチドッグに関するよくある質問
Q. 一言でまとめると、ウォッチドッグって何ですか?
A. 「相手が定期的に生存信号を出しているかを見張り、来なくなったら強制的に再起動させる仕組み」です。ハードウェアの専用回路から、systemd、Kubernetes の liveness probe まで、レイヤは違っても考え方は同じ「番犬」です。
Q. systemd の watchdog と Linux watchdog デーモンは何が違いますか?
A. systemd の WatchdogSec はサービス単位の watchdog で、特定のプロセスが応答しなくなったらそのサービスだけ再起動します。Linux watchdog デーモン(/dev/watchdog を叩く昔ながらの方式)はマシン全体のハードウェアリブートを担当します。最近は systemd が両方を統合管理することが多く、新規構築なら systemd の機能を使うのが標準です。
Q. Kubernetes の liveness probe は watchdog ですか?
A. はい、思想としては watchdog そのものです。「定期的に状態を確認 → 失敗が続いたら強制再生成」 という動作は WDT と同じ。違うのは、再起動対象がマシンではなくコンテナ単位であること、判定基準が HTTP / TCP / exec などソフトウェア寄りであることです。
Q. Python の watchdog ライブラリは、サーバ運用の watchdog と関係ありますか?
A. 名前が同じだけで、機能はまったく別物です。Python の watchdog パッケージはファイルシステムの変更を監視するライブラリで、「フォルダ内のファイルが変わったらコールバックを呼ぶ」 系の仕組み。プロセスの生死監視や再起動とは無関係です。文脈で必ず使い分けてください。
Q. watchdog を入れるとどんな問題が起きますか?
A. 一番ありがちなのが 「再起動の暴走ループ」。再起動しても直らない原因(ディスクフル / 設定不備 / 依存サービス停止)があると、永遠に再起動を繰り返してログだけが膨らみ、本質的には何も復旧していない状態になります。systemd の StartLimitBurst や Kubernetes の CrashLoopBackOff のような再起動回数の上限と、必ずアラート通知をセットで設計するのが鉄則です。
Q. heartbeat と watchdog は何が違いますか?
A. heartbeat は「生存信号そのもの」、watchdog は「heartbeat を見張る側」です。アプリが 5 秒ごとに送る ping が heartbeat、それを受けて「30 秒来なかったらリセット」 と判定する側が watchdog。両者はセットで使われます。
Q. 監視ツール(Datadog / Mackerel / Prometheus など)は watchdog の代わりになりますか?
A. 部分的にはイエス、完全にはノーです。監視ツールは「ヘルスチェックが NG ならアラート」 までは担えますが、そこから自動で再起動するアクションは別途必要です。Kubernetes の liveness probe や systemd の WatchdogSec のような「監視 + 復旧アクション」がセットになった仕組みが本来の watchdog です。監視ツールはアラート専門、watchdog は復旧専門、と役割を分けて考えるのが整理しやすい。
参考リンク
- Linux: Documentation/watchdog/
- systemd: systemd.service WatchdogSec
- Kubernetes: Configure Liveness, Readiness and Startup Probes
- Python: watchdog — PyPI
- 関連記事: 監視の基本(稼働 / ログ / アラート) / Kubernetes は小規模サービスにはオーバーキルか / ハーネス工学と AI エージェントの信頼性