LASSIC Media らしくメディア
Uptime Kumaで死活監視をセルフホスト構築する外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Uptime Kumaは死活監視を無償でセルフホストできるオープンソースの監視ツールです。
- 対応する監視種別・通知連携・Dockerでの構築手順を押さえておく必要があります。
- 内製と外注、それぞれの工数とリスクを踏まえたうえで運用体制を判断することが求められます。
目次
Uptime Kumaとは何か－OSSの死活監視ツールとセルフホストという選択肢
Uptime Kumaとは、HTTP・TCP・Ping・DNSレコードなど9種類の監視方式と最短20秒間隔のチェックに対応し、自社サーバーへ無償でセルフホスト（自社の環境で自らソフトウェアを構築・運用すること）できるMITライセンスのOSS（オープンソースソフトウェア）死活監視ツールです*1。
Uptime Kumaのセルフホスト構築を外注するとは、このツールの導入設計から通知ルールの整備、証明書監視の運用までを外部の専門パートナーに委託し、自社の運用負担を軽くする取り組みを指します。自社の情報システム部門だけで完結させるか、外部の知見を組み合わせるかは、後述する必要スキル・工数を踏まえて判断することになるでしょう。判断を誤ると障害検知の遅れにつながりかねないため、慎重な比較検討が求められます。
Uptime Kumaは開発者louislam氏が公開しているオープンソースプロジェクトで、MITライセンスのもと商用利用を含め無償で使用できます*1。GitHub上でのスター数は8万9千を超え、直近のメジャーアップデートであるv2.4.0は2026年5月31日に公開されました*2。
監視対象の数や取得するログ量に応じて費用が積み上がる従量課金型のSaaS監視サービスに対し、Uptime Kumaはインフラ費用を自社で負担する代わりにライセンス費用が発生しない点が特徴です。コストを抑えたい法人のIT部門にとって、セルフホストは有力な選択肢のひとつになっています。
実務での想定用途としては、自社ECサイトやコーポレートサイトのフロント監視、社内基幹システムが外部APIと連携する経路の疎通確認、複数拠点を結ぶネットワーク機器の死活監視などが挙げられます。監視対象や通知経路をどこまで細かく設計するかによって、必要な工数は大きく変わってくるでしょう。
HTTP・TCP・証明書期限まで－9種類の監視方式と20秒間隔のチェック
Uptime Kumaは、HTTP(s)監視・TCP監視・HTTP(s)キーワード監視・HTTP(s) JSONクエリ監視・Websocket監視・Ping監視・DNSレコード監視・Push監視・Dockerコンテナ監視という9種類の監視方式に対応しています*1。監視間隔は最短20秒まで短縮でき、障害発生から検知までの時間を短く保てます*1。
WebサイトやAPIを外部公開している場合は、TLS証明書（通信を暗号化するための電子証明書）の有効期限も自動で確認できます*1。証明書の失効に気づかないまま放置すると、ブラウザ上に警告が表示されたり接続自体ができなくなったりするおそれがあり、顧客対応窓口となるサービスであれば信用に関わる問題になりかねません。
応答速度の推移をグラフで確認できるPingチャートも備わっており、日々の応答時間がどう変化しているかを見える化できます*1。障害が起きてから気づくだけでなく、応答が徐々に遅くなっているといった予兆をとらえる用途にも使えるでしょう。
| 監視種別 | 確認できる内容 |
|---|---|
| HTTP(s)監視 | Webサイト・APIへのアクセス可否とレスポンス状態を確認します*1。 |
| TCP監視 | 指定ポートへの接続可否を確認します*1。 |
| Ping監視 | サーバー・ネットワーク機器の疎通状況を確認します*1。 |
| DNSレコード監視 | 名前解決結果の変化を確認します*1。 |
| 証明書情報監視 | TLS証明書の有効期限を確認します*1。 |
| Dockerコンテナ監視 | コンテナの稼働状態を確認します*1。 |
Slack・Discord・メールなど90以上の通知連携とステータスページ公開
通知連携はTelegram・Discord・Gotify・Slack・Pushover・メール（SMTP）を含め、90以上のサービスに対応しています*1。障害を検知しても担当者に届かなければ意味がないため、日常的に使っているチャットツールへ届く通知経路を選んでおくことが欠かせません。
監視結果は複数のステータスページとして公開でき、独自ドメインへの割り当てにも対応します*1。管理画面には二段階認証（2FA）を設定できるほか、プロキシ経由でのアクセスにも対応しているため、社内のネットワーク構成に応じた運用設計が可能です*1。
取引先や顧客に見せるステータスページと、自社の担当者だけが操作する管理画面とでは、求められるアクセス制御のレベルが異なります。公開範囲と管理権限を分けて設計しておくことが、社外への情報公開と社内セキュリティを両立させる前提になるでしょう。
Docker Composeで構築するUptime Kumaの導入手順とNode.js要件
Dockerで導入する場合の手順
Docker Composeを使う場合は、公式が配布する設定ファイルを取得したうえでdocker compose up -dを実行するだけで、ポート3001上にUptime Kumaが起動します*1。Dockerコマンド単体でもdocker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2という1行で同様に導入できます*1。
データを永続化するにはボリュームマウントが必須で、NFS（ネットワークファイルシステム）上のディレクトリはサポート対象外と明記されています*1。マウント先の選び方を誤ると、再起動時にデータが失われるおそれがあるため注意が必要です。
Dockerを使わない場合の要件
Dockerを使わずに構築する場合は、Node.js（バージョン20.4以上）とGit、バックグラウンド実行用のPM2（プロセス管理ツール）が必要です*1。対応OSは主要なLinuxディストリビューションと、Windows 10（64bit版）またはWindows Server 2012 R2（64bit版）以上に限られます*1。FreeBSD・OpenBSD・NetBSDや、Replit・Herokuのような一部のホスティング環境は非対応と明記されており、環境選びの段階で確認しておく必要があるでしょう*1。
管理画面をそのままインターネットへ公開すると、認証を突破されない限り誰でもアクセスできる状態になります。リバースプロキシ（外部からの通信を一度受けて内部サーバーへ中継する仕組み）を経由したアクセス制御とHTTPS化を組み合わせる設計が、実務上は前提になるでしょう。
内製構築で問われるDocker運用・証明書運用・セキュリティ追従の負担
自社だけでUptime Kumaを構築・運用する場合、Dockerコンテナの運用知識、Linuxサーバーの管理経験、監視対象ごとの通知ルール設計という3つの知識が最低限求められます。加えて証明書監視の設定と、リバースプロキシによるアクセス制御の設計も欠かせません。
構築して終わりではなく、バージョンアップへの追従やセキュリティパッチの適用、監視対象の増減に合わせた設定変更といった保守作業が継続的に発生します。これらを情報システム部門の兼務担当者が日常業務と並行してこなそうとすると、優先度が下がりやすくなる点が実務上の課題になるでしょう。
通知ルールの設定漏れや証明書監視の見落としがあると、実際に障害や証明書失効が起きても誰も気づけないまま、外部向けサービスが停止し続けるおそれがあります。監視ツールを導入したこと自体が目的化し、通知が届くところまで検証できていない状態は、運用の落とし穴になりやすいでしょう。
ライセンス費用がかからない点はセルフホストの利点ですが、Uptime Kuma自体を動かすサーバーやVMのインフラ費用、そのバックアップ・冗長化は別途自社で確保する必要があります。監視ツールを載せているサーバー自体が停止すれば、監視機能そのものが失われるため、監視基盤の可用性まで含めた設計が欠かせません。
外注でUptime Kumaを構築・運用するメリットと依頼先選定の視点
専門パートナーに依頼した場合との違い
外注する場合も、構築の工程自体は内製と変わらず要件整理・環境構築・監視対象の登録・通知と証明書監視の設定です。違うのは、複数の監視対象や通知ルールを扱ってきた実務知見をもとに、抜け漏れが起きやすい通知経路の検証まで含めて設計できる点にあります。
構築時点の動作確認だけでなく、運用フェーズでのバージョンアップ追従・セキュリティパッチ適用まで見据えた保守計画を、外部パートナーと一緒に組み立てられるかどうかも、内製と外注で差が出やすい部分です。
依頼先を選ぶ際の視点
依頼先を選ぶ際は、Dockerを含むコンテナ運用の実績とLinuxサーバー運用の実績の両方を確認することが大切です。導入だけを請け負う事業者と、導入後の監視・保守まで一貫して受託できる事業者とでは、障害発生時の対応力に差が出るでしょう。
相談範囲は「初期構築のみ」から「監視設計・通知ルール整備・日常保守までの一貫委託」まで幅があります。自社の兼務担当者が対応できる範囲を先に洗い出し、手が回らない工程だけを切り出して依頼する進め方も選択肢のひとつです。
LASSICのIT運用保守サービスでは、こうしたシステムの保守・運用支援を継続的な体制で提供しています。監視体制の整備から相談したい場合は、早めの段階で専門パートナーに声をかけることが後工程の手戻りを減らすことにつながります。
まとめ：Uptime Kumaセルフホスト導入の3つの判断軸
本稿ではUptime Kumaの監視機能・構築手順・内製と外注それぞれの負担を整理しました。要点を3つに集約すると次の通りです。第一に、Uptime KumaはHTTP・TCP・Ping・DNSレコード・証明書情報など9種類の監視に対応し、MITライセンスのOSSとして無償でセルフホストできます*1。第二に、構築自体はDocker Composeの数コマンドで完了しますが、通知ルールや証明書監視、セキュリティ追従まで含めた運用体制の設計こそが継続的な負担になります。第三に、この運用体制を自社の兼務担当者だけで維持し続けられるかを見極めたうえで、難しい場合は外部パートナーへの委託を検討することが現実的な判断になるでしょう。
よくある質問
Uptime Kumaは商用利用でも無償で使えますか？
はい、無償で利用できます。Uptime KumaはMITライセンスで公開されているオープンソースソフトウェアのため、商用利用を含めライセンス費用は発生しません*1。
Uptime Kumaはどのような監視方式に対応していますか？
HTTP(s)監視・TCP監視・Ping監視・DNSレコード監視・証明書情報の確認など、9種類の監視方式に対応しています*1。監視間隔は最短20秒まで短縮できます*1。
Dockerを使わずに構築することはできますか？
できます。Node.js（バージョン20.4以上）とGit、PM2があれば非Docker環境でも構築可能です*1。ただし対応OSは主要Linuxと一部のWindows環境に限られ、FreeBSD系や一部のホスティング環境は非対応です*1。
Slackやメール以外の通知手段にも対応していますか？
対応しています。Telegram・Discord・Gotify・Pushoverなどを含め、90以上の通知サービスと連携できます*1。
自社での構築が難しい場合、どの工程から外注を検討するのが現実的ですか？
まず監視設計と通知ルールの整備から相談するのが現実的です。どの監視対象にどの通知経路を割り当てるかを整理したうえで、Docker環境の構築・証明書監視・運用保守まで一貫して依頼できるパートナーを選ぶ流れが実務的といえます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：GitHub「louislam/uptime-kuma」（確認日：2026年7月22日）
- *2 出典：GitHub「louislam/uptime-kuma」Releases（v2.4.0）（確認日：2026年7月22日）
