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

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

Checkmate（bluewave-labs/Checkmate）は、サーバーの稼働・応答時間・SSL証明書の期限・インシデントをリアルタイムに1画面で追うオープンソースのセルフホスト型監視ツールである。GitHubスターは10,747、フォーク1,186、ライセンスは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日の初出後、2026年8月25日に全面的に再検証している。数値はいずれもGitHub APIおよびコンテナレジストリ（GHCR）の実測値だ。

・⭐ GitHubスター：10,747（フォーク 1,186／Watch 35）
・📦 最新リリース：v3.10.0（2026年7月28日公開）。前版v3.9.2は7月7日で、初出記事の公開8日後に次版が出た
・👥 コントリビュータ：157〜176人（GitHub APIのcontributorsで匿名を除くと157人、含めると176人。計測方法で振れる）
・🛠️ 主要言語：JavaScript（React + MUI フロント、Node.js バックエンド、Recharts で可視化）
・🗄️ データストア：MongoDB（v3.10.0でも変更なし。公式Composeは mongo:8.0）
・🏢 開発元：bluewave-labs（カナダ）。商用クラウド版 checkmate.so を並行運営
・🕒 直近のプッシュ：2026年8月24日（開発は現役で稼働中。既定ブランチは develop）

2024年4月末に始まったプロジェクトで、スター1万超・コントリビュータ150人超という規模は、稼働監視という成熟ジャンルの後発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年8月25日時点でGitHub API・公式情報を再確認した実測値だ。

数字だけ見れば、Uptime Kuma（スター約9.1万・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のコミュニティフォークだが、既定ブランチ（dev）の最終コミットが2025年6月4日で、2026年8月時点では1年以上更新が止まっている。新規採用の第一候補にはしづらい。Better Stack（旧Better Uptime）は商用SaaSで、OSSではない。運用を完全に丸投げしたい・オンコール管理まで統合したいならSaaSが早いが、監視データは第三者に預けることになる。

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

v3.10.0でDocker配布が単一イメージに一本化：旧イメージの非推奨と貼り替え手順

本記事の初出（2026年7月20日）の8日後、2026年7月28日に公開されたv3.10.0で、Checkmateの配布方法が変わった。リリースノートは冒頭に「Deployment change, action required（デプロイの変更、対応が必要）」と掲げており、セルフホスト運用者が最初に確認すべき変更点になっている。ここは初出時点の記事には存在しなかった情報なので、2026年8月25日の再検証で実測した内容を独立した節として加える。

公式が告知した変更は次の3点だ。

・単一イメージへの一本化：Checkmateは ghcr.io/bluewave-labs/checkmate の単一イメージとして配布される
・旧イメージの非推奨：サービスごとに分かれていた checkmate-client / checkmate-backend / checkmate-mongo / checkmate-backend-mono の4イメージは非推奨（deprecated）
・データは影響を受けない：公式は「データベースとデータは影響を受けず、マイグレーションは初回起動時に自動実行される」と明記している

GHCR実測：latest・develop・旧イメージが実際に指しているもの

「非推奨」「更新されない」というのは提供元の告知であって、それ自体は検証されていない主張だ。そこでコンテナレジストリ（GHCR）を直接引いて実測した。以下はいずれも2026年8月25日に取得した値である。

見る指標は2つある。ダイジェスト（同じ値なら中身が完全に同一）と、そのパッケージに存在するバージョンタグの一覧（どのリリースが配布されたか）だ。なおイメージ設定に記録された作成日時は「イメージがビルドされた時刻」であって「レジストリに公開された時刻」とは限らないため、以下では補助的な情報として扱い、判断はダイジェストとタグ一覧に置いている。

まず、現行の単一イメージ checkmate の各タグが指す中身を比較する。

:latest と :v3.10.0 はダイジェストが一致するので、中身が同一のイメージだと確定できる。一方 :develop は別のダイジェストで、ビルド日時もリリース（7月28日）より約3週間新しい2026年8月18日だった。つまり :develop はリリースを経ていない開発版を指している。

次に、非推奨とされた旧4パッケージがどのリリースまで配布されたかを、各パッケージのタグ一覧から確認する。こちらは「どのバージョンが公開されたか」を直接示すため、ビルド日時よりも強い証拠になる。

これで公式の告知は独立に裏付けが取れたと言える。checkmate-backend-mono は「このリリースを移行用の別名として受け取り、以後は更新されない／当該名で公開される最後のリリースになる」という告知どおり、v3.10.0のタグを持ち、かつそのイメージは単一イメージ版のv3.10.0と同じ時刻にビルドされている。

一方 checkmate-client / checkmate-backend / checkmate-mongo の3つはv3.10.0のタグをそもそも持たない。告知は「非推奨」とだけ述べているが、実測ではこの3つはv3.9.2で配布が止まっている——旧構成のまま運用しているなら、v3.10.0で入った修正（ステータスページのカスタムCSSインジェクション、CSP設定、監視削除時のインシデント残留など）を受け取れていないことになる。

なお、初出時に :develop を案内したこと自体は当時の実測としては正しかった。単一イメージ方式はv3.10.0で正式化された配布形態であり、7月20日時点ではまだリリース前で :latest が存在しなかったためだ。つまり「壊れた」のではなく、先行して使っていた経路が公式化され、当時必要だった但し書きが不要になったというのが実際の経緯である。7月の手順で構築した環境がいま動かなくなっているわけではない。

実測：JWT_SECRET を渡さないとComposeは起動前に停止する（fail-closed）

v3.10.0の公式Composeファイルは、署名鍵 JWT_SECRET を ${JWT_SECRET:?set JWT_SECRET in your environment} という形で宣言している。これは値が無ければComposeが解釈の段階で停止する書き方だ。実際にそうなるかを、Dockerデーモンを起動せずに検証できる docker compose config（構成の検証・展開のみを行うサブコマンド）で確かめた。

対照群として「設定した場合」を挟むことで、停止が本当に JWT_SECRET に起因すると確認できる。空文字でも停止する点が実務上は重要で、.env に JWT_SECRET= とだけ書いて放置した場合も黙って弱い鍵で起動するのではなく、確実に止まる。認証トークンの署名鍵が未設定のまま公開されてしまう事故を防ぐ、fail-closedな設計だ。この検証はデーモン不要で数秒で終わるため、読者も自分の手元で同じ結果を再現できる。

Docker Composeでセルフホストする手順：公式クイックスタートと実測の所要時間

ここからは実際に手を動かす。Checkmateは公式が提供するDocker Compose構成で、本体イメージ（オールインワン）とMongoDBを立ち上げるのが最短だ。所要時間とリソースは2026年7月20日にarm64のMac（Docker 27.4.0）で計測した実測値で、手順そのものは2026年8月25日にv3.10.0の公式構成へ更新している。

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

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

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

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

公式の推奨は、リファレンスのDocker Composeファイルを取得し、JWT_SECRET を渡して起動する方式だ。単一イメージ（ghcr.io/bluewave-labs/checkmate）とMongoDBが同時に立ち上がる。READMEのクイックスタートは次の2行で完結する。

# 公式のリファレンス Compose を取得して起動（JWT_SECRET はその場で生成）
curl -O https://raw.githubusercontent.com/bluewave-labs/checkmate/master/docker/docker-compose.yaml
JWT_SECRET="$(openssl rand -hex 32)" docker compose up -d

取得される docker-compose.yaml の中身は次のとおりで、本体とMongoDBの2サービス構成になっている。ヘルスチェックと depends_on により、MongoDBが応答可能になってから本体が起動する順序が保証されている。

services:
  checkmate:
    image: ghcr.io/bluewave-labs/checkmate:latest   # v3.10.0以降は :latest が正規（実測でv3.10.0と同一）
    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 in your environment}
    stop_grace_period: 60s
    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:

本番で使うなら :latest ではなく v3.10.0 のようなバージョン固定タグにしておくと、pull_policy: always と組み合わせたときに意図しないタイミングで版が上がるのを避けられる。

起動後、ブラウザで 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）で実際の管理画面を触ってから判断してもよい。

AI開発者にCheckmateが噛み合う使いどころ：LLMサーバー・推論ボックスの監視

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.10.0（2026年7月28日）、直近のプッシュは2026年8月24日。2024年4月末から継続的に開発され、リリースは通算30回以上。稼働監視という成熟ジャンルで、開発は現役で回っている。
・バス係数／開発体制：コントリビュータは157〜176人（匿名コミットを除くか含めるかで変わる）と多く、good-first-issueやHacktoberfestで新規貢献を積極的に受け入れている。ただしコミット数は中核メンバーに強く集中しており、最大貢献者（ajhollid）だけで6,227コミットと、実装の中枢は少数が担っている。これは運営元bluewave-labsが専任チームで開発している証でもあり、企業バックのOSSとしてはむしろ自然な形だが、「中核が抜けたときの継続性」は基幹監視に据える際に織り込んでおきたい。
・企業サポート：開発元は商用クラウド（checkmate.so）を運営する企業であり、事業として継続する動機がある。一方、セルフホスト版に対する公式の保証やSLAは無く、サポートはDiscordやGitHub Discussionsといったコミュニティ窓口が中心になる。
・依存とセルフホストの手間：MongoDBが必須で、単一イメージ＋MongoDBの2コンテナ構成が基本だ（v3.10.0でもデータストアはMongoDBのまま）。インフラ監視まで使うなら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（v3.10.0以降は :latest がそのまま使える）で実際に立ててみるのが、判断の一番の近道になる。

参照ソース

• 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）