1日3000万チェックのCheckly、CLI利用者の半分がAIエージェントになった理由

Checklyは、コードとして定義した監視を本番環境で走らせ続けるためのプラットフォームだ。

ブラウザのE2EテストとAPIチェックを同じリポジトリで管理し、失敗時にはスクリーンショット、動画、PlaywrightトレースとAIによる原因分析を返す。出典

2020年、Hannes Lenke、Timo Euteneuer、Tim Noletの3人は「エンジニアが障害を10倍速く見つけて直せるようにする」という同じ目的でChecklyを立ち上げた。

3人はいずれもWeb監視と観測性の領域で会社を興した経験を持つ。出典

監視をコードの隣に置く

Checklyが最初に選んだのは、監視をダッシュボードではなくリポジトリに置くという設計だった。

チェックはTypeScriptのconstructとして書き、CLIでテストし、CIからデプロイする。

Playwrightのテストは書き換えずにそのまま本番監視へ回せる。出典

この設計は、当時の監視ツールの前提を裏返すものだった。

監視の設定がUIの中にしかないと、誰が何を監視しているのか分からなくなり、担当者が退職すると誰も触れないチェックが残る。

Checklyはこの状態を「所有権の不在」と呼び、コードとして監視を持つことで所有・発見・レビューを可能にした。出典

資金調達より先に、顧客の運用を変えた

2020年4月、Accel主導で$2.25Mのシードを調達する。出典

1年後の2021年6月にはCRV主導の$10M Series Aを発表し、累計10億check runsを突破したと公表した。

1PasswordやVercelが、デプロイのたびに走るチェックとしてChecklyを使い始めていた時期でもある。出典

2023年9月にはGartnerのCool Vendors in Monitoring and Observabilityに選ばれ、Monitoring as Codeは2つのHype Cycleに掲載された。出典

2024年7月にはBalderton主導で$20MのSeries Bを調達し、累計調達額は$32.25Mに到達。

同時にOpenTelemetryのトレースと合成監視を接続するCheckly Tracesを公開している。出典

AIエージェントが最初の利用者になった

2025年10月、ChecklyはPlaywright Check SuitesをGAした。

既存のplaywright.config.tsとテスト一式を、そのまま本番の監視として動かせるようにした発表だ。出典

転機はそこから来た。

2026年3月、Hannes Lenkeは自社ブログで「AIエージェントはボタンを押さず、ダッシュボードも読まず、よくできた設定画面にも関心がない」と述べ、CLIのアクティブ利用者の50%がすでにエージェントになっていると明かした。出典

エージェントはターミナルに住み、テキストで推論する。

コードとして書かれた監視は、そのままエージェントが読み書きできる対象になる。

結果としてChecklyは、人間向けのUIを磨くのと同じ熱量で、npx checkly skillsのようなエージェント向けの導線を整えることになった。出典

同じ時期、社内ではNode.js製のResults DaemonをClaude CodeにGoへ書き換えさせている。

1日約9,200万メッセージを処理する基盤サービスで、書き換え前に600件規模のテストハーネスを用意し、ポッド数を70%削減しつつインシデントゼロで移行した。出典

監視の入口は、人間だけではなくなった

Mistralでは、Terraformで管理する監視の変更の98%をAIエージェントに委任している。

監視は「人が設定するもの」から「エージェントが保守するもの」へと役割を変えつつある。出典

Checklyが刺さるのは、E2EテストをすでにPlaywrightで書いている開発組織だ。

テストはCIで回っているのに、本番で同じフローが壊れたことを検知できない。

この「テストと本番監視の断絶」が導入の起点になる。出典

2024年時点で有料顧客は1,000社を超え、1日3,000万件以上のチェックが実行されている。出典

監視をコードとしてリポジトリに置くことで、誰が何を監視しているかが可視化され、担当者の異動後もチェックが残る。

Playwrightのテスト資産を書き換えずに本番監視へ移せる実行基盤と、Monitoring as Codeのconstruct群が実質的な障壁になっている。

テストと監視が同じコードで完結するほど、他ツールへの移行コストは上がる。出典

ネットワーク効果は弱い。

監視ツールは顧客間でつながる製品ではなく、効果は個々のリポジトリ内で完結する。

一方で、Agent SkillsやMCPのようなエコシステム側の接点は、対応エージェントが増えるほど導入経路が広がる弱い間接効果を持つ。出典

すでにPlaywrightでE2Eテストを書き、本番の主要フロー（ログイン、決済、検索）を外部から継続監視したいSRE・プラットフォームエンジニアリングのチーム。

監視設定をGitのレビュー対象にしたい組織。出典

1つ目は、Playwrightをネイティブに実行する設計を早期に選んだこと。

2つ目は、CLIとTerraform／Pulumiを一次インターフェースにしたことで、AIエージェントがそのまま利用者になったこと。

Hannes LenkeはCLIのアクティブ利用者の50%がエージェントになったと公表している。出典

ARRと解約率が非公開で、成長の質は外部検証できない。

合成監視はRUMやAPMの代替ではなく併用前提のため、景気後退時には予算削減の対象になりやすい。

エージェント経由の操作が増えると、意図しないcheckの増殖や誤設定という新しい運用リスクも生じる。出典

ボトムアップの開発者採用と、無料枠からの拡大が主チャネルだ。

CLI、Terraform、Pulumiをオープンに整備し、GitHub Actions連携でCIに食い込む。

2026年はAgent SkillsとMCPサーバーで、コーディングエージェント経由の導入経路を追加した。

ドキュメントをエージェント向けに整備する投資が、人間向けのSEOとは別の獲得チャネルになっている。出典

主要チャネル: content, oss, community, product_led

プロダクトの一次インターフェースをコードとCLIにしておくと、UIを増やさずに新しい利用者層へ届けられる。

Checklyは人間向けに作ったMonitoring as Codeが、結果的にAIエージェント向けのAPIになった。

UI中心の監視ツールが後からAIを足すのとは、順序が逆である。出典

日本市場では、E2EテストがQA部門に閉じ、本番監視は別チームが別ツールで持つ分断が起きやすい。

Playwrightの資産をそのまま監視へ流用できる点を入口に、まず売上直結の1フローへ絞って導入し、監視定義をリポジトリのレビュー対象にすると定着しやすい。

国内のSIer経由より、プロダクト組織への直接導入が現実的だ。出典