Checkmateとは：稼働監視OSSをDockerでセルフホスト｜Uptime Kuma比較と実測

本番のサービスが落ちたとき、それを最初に知らせてくれるのは監視ツールであってほしい。顧客からの問い合わせや、SNSの「サイト重くない？」という投稿で気づくのは避けたい——この当たり前を、SaaSに月額を払わず自前で完結させたい人のための選択肢が Checkmate だ。

Checkmate（bluewave-labs/Checkmate）は、サーバーの稼働・応答時間・SSL証明書の期限・インシデントをリアルタイムに1画面で追うオープンソースのセルフホスト型監視ツールである。GitHubスターは約10,200、フォーク1,100超、ライセンスはAGPL-3.0。MongoDBを添えてDocker Composeで立ち上げれば、監視データを第三者のクラウドに預けることなく自社インフラの内側で保有できる。開発元のbluewave-labs（カナダ）は商用のマネージドクラウド（checkmate.so）も並行提供しており、いわゆる「セルフホスト無料＋クラウド有料」型のOSSだ。

この記事ではセルフホスト型のDevOps/監視ツールとしてCheckmateを解説します。自動化・運用ツール全般のカバレッジは AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 をご覧ください。

Checkmateとは：サーバー稼働・応答時間・SSL・インシデントを1画面で追うセルフホスト監視OSS

Checkmateが解決するのは、「自分たちのサービスが、外から見て今ちゃんと動いているか」を継続的に確かめ続けるという地味だが欠かせない仕事だ。ユーザーがアクセスするのと同じ経路で、一定間隔でサーバーやサイトを叩き、応答が返ってくるか・十分に速いか・SSL証明書が切れていないかを記録し、状態が変わった瞬間にインシデントを起こして通知する。この一連を、外部SaaSに頼らず自分のサーバー上で完結できるのがCheckmateの核心である。

公式が掲げる説明はシンプルで、「サーバーのハードウェア・稼働・応答時間・インシデントを、美しいビジュアルでリアルタイムに追跡・監視するオープンソースのセルフホストツール」だ。READMEには「Open-source infrastructure monitoring（オープンソースのインフラ監視）」というタグラインが添えられている。稼働監視（uptime monitoring）を軸にしつつ、単にサービスの生死だけでなく、サーバー内部のリソース状況やページ表示速度まで一枚のダッシュボードに束ねている点が、単機能のpingツールとの違いになる。

読者にとって「Checkmateは結局何なのか」を一言でいえば、セルフホストできる稼働監視＋ステータスページの統合ダッシュボードだ。監視対象を登録すると、稼働率・応答時間の推移・直近のインシデントがカード形式で並び、状態が落ちれば設定した通知先（Slack・Discord・Telegram・メール等）に即座に飛ぶ。さらに、そのステータスを公開ページとして外部に見せることもできる。SaaSの外形監視サービスで実現していることを、データの所在を自分の手元に置いたまま再現するツール、と捉えると位置づけがはっきりする。

実測で確認したプロジェクトの規模

記事化にあたり、2026年7月20日時点の実データをGitHub APIで確認した。数字は次のとおりだ。

・⭐ GitHubスター：約 10,200（フォーク約1,150）
・📦 最新リリース：v3.9.2（2026年7月7日公開）／通算30回以上のリリース
・👥 コントリビュータ：約 168人（good-first-issue・Hacktoberfestで新規貢献を歓迎）
・🛠️ 主要言語：JavaScript（React + MUI フロント、Node.js バックエンド、Recharts で可視化）
・🗄️ データストア：MongoDB
・🏢 開発元：bluewave-labs（カナダ）。商用クラウド版 checkmate.so を並行運営
・🕒 直近のプッシュ：2026年7月中旬（開発は現役で稼働中）

2024年春に始まったプロジェクトで、スター1万超・コントリビュータ168人という規模は、稼働監視という成熟ジャンルの後発OSSとしては十分な勢いだ。公式によれば1,000以上のアクティブな監視を載せた負荷試験でも目立った性能上のボトルネックは出なかったとされ、小規模の趣味利用から中規模のチーム運用までを想定した設計になっている。

Checkmateの主要機能：8種の監視タイプ・インフラ計測・4テーマのステータスページ・10種の通知

Checkmateの機能は「監視する対象を増やす」方向と「落ちたときに気づかせる」方向の両輪で構成されている。公式READMEが挙げる主要機能を、実務での使いどころとともに整理する。

監視タイプ（実機では8種類）：公式READMEは「Uptime・Docker・Ping・SSL・Port・ゲームサーバー」を挙げるが、本記事で実際に動かしたビルドの監視作成ウィザードには、HTTP(S)・Ping・Docker・Port・Game に加えて gRPC・WebSocket・DNS の計8タイプが並んでいた（上図・実機）。Web APIやサイトの死活はHTTP(S)で、ネットワーク到達性はPingで、特定ポートの開放状態はPortで、コンテナの稼働はDockerで、gRPCサービスは標準のHealth Checking Protocolで監視、といった具合に対象の性質に応じて方式を選べる。SSL証明書の有効期限は独立した監視タイプではなく、前掲の監視詳細画面に「CERTIFICATE EXPIRY」として表示される形だ。「サーバーやWebサイトが到達可能で最適に動作しているかを定期的にチェックし、可用性・ダウンタイム・応答時間をリアルタイムで報告する」のが基本動作である。

ページ速度（Pagespeed）監視：単に「落ちていないか」だけでなく、ページの表示速度を継続的に計測できる。可用性は保っていても徐々に遅くなる、という劣化を早期に捉えるのに役立つ。

インフラ監視（Captureエージェント経由）：メモリ・ディスク使用量・CPU性能・ネットワークなど、サーバー内部のリソースを監視できる。これには補助エージェントの Capture（別リポジトリ・Go製）を対象サーバーに常駐させる必要がある。CaptureはLinux・Windows・Mac・Raspberry Piなど、Goが動く機器で動作する。マウントポイントを選んだ選択的なディスク監視にも対応する。外形監視だけならCaptureは不要で、内部リソースまで見たいときにのみ追加する構成だ。

インシデント管理とステータスページ：状態変化はインシデントとして記録され、一覧で俯瞰できる。さらに監視状況を外部公開するステータスページを4種類のテーマで用意でき、ユーザーや社内向けに「今どのサービスが正常か」を透明に見せられる。

10種類以上の通知連携：メール・Webhooks・Discord・Slack・PagerDuty・Matrix・Microsoft Teams・Telegram・Pushover・Twilio（SMS）に対応する。チャットにもオンコールにもSMSにも飛ばせるため、既存の運用フローに組み込みやすい。

スケジュールメンテナンス・JSONクエリ監視・多言語：計画メンテナンス時間を設定して不要なアラートを抑制できるほか、APIのJSONレスポンスの中身を条件に監視するJSONクエリ監視も持つ。UIは日本語を含む16言語に対応している。

監視のライフサイクル：チェックから通知までの流れ

Checkmateの内部で、1つの監視がどう状態を判定して通知に至るのか。READMEに記載された「Monitor Lifecycle（監視のライフサイクル）」を図にすると、判定のロジックが見えてくる。

ポイントは、1回の失敗で即アラートを飛ばすのではなく、設定した「状態変化しきい値（status change threshold）」を満たしたときにだけ状態を遷移させる点だ。ネットワークの一時的な揺らぎで大量のアラートが飛ぶ「アラート疲れ」を避けるための設計であり、initializing（初期化中）・up（正常）・down（停止）・breached（閾値超過）という状態を持つ。状態が実際に変わったときにのみインシデントを起こし、通知するため、ノイズが抑えられる。

監視の3レイヤーで住み分ける：外形監視・オブザーバビリティ・変更検知

「監視ツール」と一括りにされがちだが、実際には見ている対象のレイヤーが異なる別々の道具が混在している。Checkmateを正しく位置づけるために、当サイトで扱ってきた近接ツールとの住み分けを整理しておく。ここを混同すると「Checkmateを入れたのにトレースが見られない」といったミスマッチが起きる。

① 外形監視（ブラックボックス監視）＝Checkmateの主戦場：サービスを外側から叩き、「生きているか」「応答は速いか」「証明書は有効か」を確かめる。中で何が起きているかは知らないが、ユーザーが体感する可用性を最短で捉えられる。CheckmateやUptime Kuma、Gatus がこのレイヤーに属する。障害が「起きた事実」を検知するのが役割だ。

② オブザーバビリティ（ホワイトボックス監視）：外形監視が「落ちた」と教えてくれた後、「なぜ落ちたのか」を内側から追うのがこのレイヤーだ。OpenTelemetryで集めたトレース・ログ・メトリクスを扱う。当サイトで解説した openobserve：Rust製のセルフホスト型オブザーバビリティ基盤 や、Claude Codeが本番エラーを自力で辿る Traceway がここに当たる。Checkmateはこのレイヤーを担わない——応答時間は測れても、リクエストが内部のどのサービスで詰まったかは分からない。障害の「原因」を掘るには別途オブザーバビリティ基盤が要る。

③ 変更検知：稼働はしているが「中身（コンテンツ）が変わったか」を追うのが変更検知で、changedetection.io：Webサイトの変更を検知する監視OSS が代表格だ。価格変動・在庫復活・改ざん検知が典型で、Checkmateの「サービスが生きているか」とは目的が異なる。

つまり、Checkmate＝外形監視、openobserve/Traceway＝オブザーバビリティ、changedetection.io＝変更検知、と役割が分かれている。実務では①で落ちた事実を掴み、②で原因を掘り、必要なら③で中身の変化も見る、という組み合わせになる。Checkmateはこのうちの①を、SaaSに頼らずデータ自社保有で担うためのツールだと理解すると選定を誤らない。

Uptime Kuma・Gatus・Statping・Better Stackとの比較：Checkmateはどこに向くか

同じ「外形監視」レイヤーの中で、Checkmateはどこに位置するのか。セルフホスト稼働監視の定番であるUptime Kuma、設定ファイル駆動のGatus、老舗のStatping、そして商用SaaSのBetter Stackと横並びで比較する。数値・ライセンスは2026年7月20日時点でGitHub API・公式情報を確認した実測値だ。

数字だけ見れば、Uptime Kuma（スター約8.9万・MIT）がこのジャンルの圧倒的な定番で、日本語情報も最も豊富だ。個人サーバーや小規模プロジェクトを手早く監視するなら、まず候補に挙がる。CheckmateはUptime Kumaに対して、CPU/メモリ/ディスクのインフラ監視（Captureエージェント）、ロールベースのチーム運用、4テーマのステータスページといった「チームでインフラを運用する」要件に寄せた機能で差別化している。逆に言えば、1人で数台を見るだけならUptime Kumaのほうが軽く、情報も探しやすい。

Gatus（Apache-2.0・Go）は思想が異なり、監視対象をYAMLの設定ファイルで宣言的に定義する。GitOps的にリポジトリで監視構成を管理したいチームに刺さるが、UIでポチポチ足したい人には不向きだ。Statping-ng（GPL-3.0・Go）は老舗Statpingのコミュニティフォークだが、最終コミットが2025年6月と更新が停滞気味で、新規採用の第一候補にはしづらい。Better Stack（旧Better Uptime）は商用SaaSで、OSSではない。運用を完全に丸投げしたい・オンコール管理まで統合したいならSaaSが早いが、監視データは第三者に預けることになる。

Checkmateが向くのは、「SaaSにデータを預けたくない」「稼働監視だけでなくサーバーのリソースやチーム運用・公開ステータスページまで1つでまかないたい」「Uptime Kumaより一歩チーム向けの機能が欲しい」というケースだ。ライセンスがAGPL-3.0である点（後述）と、中核開発者が少数である点（後述）を織り込んだうえでなら、有力な選択肢になる。

Docker Composeでセルフホスト：本日実測した所要時間とセットアップ手順

ここからは実際に手を動かす。Checkmateは公式が提供するDocker Compose構成で、本体イメージ（オールインワン）とMongoDBを立ち上げるのが最短だ。本記事では2026年7月20日にarm64のMac（Docker 27.4.0）で実際にセルフホストし、所要時間とリソースを計測した。

実測：docker compose up から起動まで約42秒

計測結果は次のとおりだ。ネットワークとキャッシュ状況に依存するため絶対値ではないが、「重くない」ことの目安にはなる。

コールドスタート（イメージ未取得）でも1分かからずにログイン画面まで到達し、アイドル時のメモリフットプリントは合計350MiB前後と軽量だった。公式は「323台のサーバーを毎分監視するNode.jsインスタンスでもごく小さなメモリで動く」と説明しており、この軽さは実機でも体感できた。

手順1：Compose構成の取得と起動

公式の推奨は、リファレンスのDocker Composeファイルを用意し、JWT_SECRET を渡して起動する方式だ。オールインワンイメージ（ghcr.io/bluewave-labs/checkmate）とMongoDBが同時に立ち上がる。まず作業ディレクトリに、本体とMongoDBを定義した docker-compose.yaml を用意する。

mkdir checkmate && cd checkmate
cat > docker-compose.yaml <<'YAML'
services:
  checkmate:
    image: ghcr.io/bluewave-labs/checkmate:develop   # :latest は現状取得不可。:develop を指定
    pull_policy: always
    restart: always
    ports:
      - "52345:52345"
    environment:
      - DB_CONNECTION_STRING=mongodb://mongodb:27017/uptime_db
      - CLIENT_HOST=${CLIENT_HOST:-http://localhost:52345}
      - JWT_SECRET=${JWT_SECRET:?set JWT_SECRET}
    depends_on:
      mongodb:
        condition: service_healthy
  mongodb:
    image: mongo:8.0
    restart: always
    command: ["mongod", "--quiet", "--bind_ip_all"]
    volumes:
      - mongo-data:/data/db
volumes:
  mongo-data:
YAML

次に、署名鍵 JWT_SECRET を生成しながらコンテナを起動する。openssl rand -hex 32 でランダムな鍵を作り、そのまま docker compose up に渡すのが手軽だ。

# JWT_SECRET を生成してバックグラウンド起動
JWT_SECRET="$(openssl rand -hex 32)" docker compose up -d

起動後、ブラウザで http://localhost:52345 を開く。ドメインやLAN IPなど別のオリジンでアクセスする場合は、CLIENT_HOST をそのURLに合わせる。TLSを付けるなら、Caddy・Traefik・nginxなどのリバースプロキシを52345番ポートの前段に置くのが定石だ。起動状態の確認やログの追跡、将来のアップグレードは、次のような通常のDocker Compose操作で行える。

# コンテナの状態を確認（healthy になっていれば起動完了）
docker compose ps

# 本体のログを追う（初期化の様子や監視の実行を確認）
docker compose logs -f checkmate

# 新しいイメージが出たらプルして再作成（データはMongoDBのボリュームに残る）
docker compose pull && docker compose up -d

手順2：初回セットアップ（Super Admin作成）と監視の追加

初回アクセス時は、管理者（Super Admin）を作成する登録画面が表示される。氏名・メール・パスワードを入力して登録すると、/uptime のダッシュボードに入る。あとはUIから「Create a monitor」で監視対象を追加していくだけだ。HTTP監視ならURL・監視名・チェック間隔を指定すれば、数十秒後には最初のチェック結果が並び始める。

環境変数は本体コンテナ側に集約されており、押さえるべきは次の3つだ。

・DB_CONNECTION_STRING（必須）：MongoDBの接続文字列。例 mongodb://mongodb:27017/uptime_db
・JWT_SECRET（必須）：認証トークンの署名鍵。openssl rand -hex 32 で生成する
・CLIENT_HOST（必須）：ユーザーが実際にアクセスするURL。CORSや通知・招待メールのリンク生成に使われる

なお、Docker Compose以外にも、Coolify・Elestio・Kubernetes（Helm chart）・PikaPods などからの導入手段が公式に用意されている。手元にDockerが無い場合は、公式デモ（demo.checkmate.so）で実際の管理画面を触ってから判断してもよい。

AGPLライセンスと「AIツールではない」点を正直に：それでもAI開発者に噛み合う使いどころ

当サイト（AI関連OSSの解説メディア）の文脈で、Checkmateの位置づけを正直に述べておく。Checkmate自体にAI機能は一切ない。 LLMを使うわけでも、AIエージェントを内蔵するわけでもない、純粋なインフラ監視ツールだ。その意味で本記事は、当サイトのAIフォーカスからは外れる周辺トピックである（読者への誠実さのため、冒頭とFAQに続きここでも明記する）。GitHubのトピックにも ai や llm は含まれず、uptime-monitor・server-monitoring・statuspage などが並ぶ。

それでも、AIプロダクトを運用する開発者にとってCheckmateが実務的に噛み合う「使いどころ」は確かに存在する。捏造ではなく、機能から素直に導ける範囲で挙げる。

① セルフホストのLLMサーバー・AIエージェント基盤の死活監視：Ollama・vLLM・LiteLLMといったLLM推論サーバーや、自前で立てたMCPサーバー・AIエージェントのAPIエンドポイントは、結局のところ「落ちたら困るHTTPサービス」だ。CheckmateのHTTP/Port監視でこれらの死活と応答時間を追い、落ちた瞬間にSlackやTelegramへ飛ばす、という使い方はそのまま成立する。AI推論はレイテンシが体感品質に直結するため、応答時間の劣化を継続監視できる価値は小さくない。

② GPU/推論ボックスのハードウェア監視：ローカルLLMやファインチューニングを回す推論マシンは、メモリ・ディスク・温度が実運用のボトルネックになりやすい。Captureエージェントを推論サーバーに常駐させれば、CPU/RAM/ディスク/温度を監視でき、「深夜のバッチ推論でディスクが埋まって停止」といった事故の予兆を掴める。GPU使用率そのものを直接見る専用ツールではない点は補足しておくが、ホストのリソース逼迫を捉える一次防衛線にはなる。

③ 監視データを第三者クラウドに渡さない：プライバシーやデータ主権を製品価値に掲げるAIプロダクトが、自社インフラの監視データを外形監視SaaSに丸ごと預けているのは、メッセージとして一貫しない。Checkmateをセルフホストすれば、どのエンドポイントをいつ監視し、いつ落ちたかというメタデータも自社のサーバー内にとどまる。

要するに、CheckmateはAIツールではないが、AIインフラを「運用する」開発者の道具箱には収まる。AI機能を期待して入れるものではなく、自前で立てたAIサービス群の可用性とサーバーリソースを、データ主権を保ったまま見張るための監視基盤として捉えるのが正しい。

「本当に使えるか」の判定材料：活性度・バス係数・企業サポート・依存

最後に、技術選定の判断材料を、盛らずに整理する。監視ツールは一度基幹に据えると外しづらいため、導入前にこれらを見ておきたい。

・活性度：最新リリースはv3.9.2（2026年7月7日）、直近のプッシュも2026年7月中旬。2024年春から継続的に開発され、リリースは通算30回以上。稼働監視という成熟ジャンルで、開発は現役で回っている。
・バス係数／開発体制：コントリビュータは約168人と多く、good-first-issueやHacktoberfestで新規貢献を積極的に受け入れている。ただしコミット数は中核メンバーに強く集中しており、最大貢献者（ajhollid）だけで約6,000コミットと、実装の中枢は少数が担っている。これは運営元bluewave-labsが専任チームで開発している証でもあり、企業バックのOSSとしてはむしろ自然な形だが、「中核が抜けたときの継続性」は基幹監視に据える際に織り込んでおきたい。
・企業サポート：開発元は商用クラウド（checkmate.so）を運営する企業であり、事業として継続する動機がある。一方、セルフホスト版に対する公式の保証やSLAは無く、サポートはDiscordやGitHub Discussionsといったコミュニティ窓口が中心になる。
・依存とセルフホストの手間：MongoDBが必須で、オールインワンイメージ＋MongoDBの2コンテナ構成が基本だ。インフラ監視まで使うならCaptureエージェントを各対象サーバーに配る運用も加わる。立ち上げ自体は数分だが、TLS・バックアップ・アップグレード・MongoDBの容量監視は自己責任になる。
・ライセンス：AGPL-3.0。前述のとおり自社利用は問題ないが、SaaSへの組み込み再提供では開示義務を確認する必要がある。ライセンスの制約を避けたいならMITのUptime Kumaが選択肢になる。
・ドキュメントと導入経路：公式ドキュメントポータル（checkmate.so/docs）に加え、Coolify・Elestio・Helm・PikaPodsなど複数の導入経路が用意されており、デモ環境（demo.checkmate.so）で事前に触れる。

まとめると、Checkmateは「稼働監視・インフラ監視・ステータスページ・チーム運用を、SaaSにデータを預けずに1つでまかないたい」という要件に、企業バックの現役OSSとして応える選択肢だ。個人で数台を軽く見るだけならUptime Kumaのほうが手軽で情報も多く、GitOpsで宣言的に管理したいならGatusが向く。CheckmateはそれらとAGPL・機能・チーム運用の観点で差別化されており、AIツールではないと理解したうえで、自前のインフラ（AIサービス群を含む）の可用性を自分の手元で見張りたい人に噛み合う。まずはデモ環境か、上で示したDocker Compose（:develop タグに注意）で実際に立ててみるのが、判断の一番の近道になる。

参照ソース

• bluewave-labs/Checkmate - GitHub（公式リポジトリ）
• bluewave-labs/capture - GitHub（インフラ監視エージェント）
• Checkmate 公式サイト・ドキュメント
• Checkmate 公式デモ環境
• Uptime Kuma - GitHub（比較対象・MIT）
• Gatus - GitHub（比較対象・Apache-2.0）
• Statping-ng - GitHub（比較対象・GPL-3.0）