Claude CodeのChecklyプラグインでモニタリングチェックを作る

Checklyプラグインは、Claude Codeに「監視チェックをコードで書いて、テストして、デプロイする」ための知識とMCPサーバーを一度に足すプラグインです。入るのはスキル2つとMCP接続1つ。/plugin install の2行で揃います。

ただし、チェックを作る作業と、本番の状態を見る作業は担当が違います。ここでは導入、CLIとMCPの役割分担、書き込み時の確認、つまずきやすい点を順に説明します。

Checklyプラグインに入っているもの

Checklyはシンセティック監視のサービスで、監視をコードとして管理する「Monitoring as Code」を前面に出しています。プラグインの実体は、そのためのスキルとMCP設定のパッケージです。リポジトリの説明では、Codex、Claude Code、Cursorなどを対象にした1つのプラグインで、Checkly MCPサーバーも同梱します。

2つのスキルはプラグイン側に手書きされたものではなく、別リポジトリから同期されたコピーです。更新が毎日入るので、手元のスキル本文は導入時点から変わっていくことがあります。

インストールする

Claude Code上では、マーケットプレイスを追加してからプラグインを入れます。

/plugin marketplace add checkly/checkly-plugin
/plugin install checkly@checkly

入れたあとは、Claude Codeを再起動してプラグインを読み込ませます。スキルはスラッシュコマンドとしても呼べます。

/checkly:checkly
/checkly:playwright-best-practices-for-agents

明示的に呼ばなくても、ChecklyやPlaywrightの話題になればスキルが自動で読み込まれる作りです。たとえば「example.comのURLモニターを作って」と頼むと、Skill(checkly:checkly) が読み込まれてからCLIを調べに行く流れが公式の例に載っています。

Claude Codeのプラグインそのものの仕組みはClaude Code全体像のガイドにあります。MCP単体で入れたいだけなら、後述の claude mcp add で足ります。

CLIとMCPのどちらで動くか

このプラグインで最も混乱しやすいのが、2つの経路の違いです。checkly スキルの冒頭が、この整理から始まっています。

スキルは、シェルが使えるなら最初に npx checkly whoami を実行し、成功すればMCPツールが接続されていてもCLIで通すよう指示しています。認証エラーになった場合は、チェックの作成・デプロイならCLIでログインするよう促し、状態確認だけならMCPに切り替えます。

MCP側の公式説明には、インラインスクリプトでBrowserチェックやMultistepチェックを作成・更新できるとも書かれています。ただしプロジェクトのファイルをバンドルしたり、プロジェクトをデプロイしたりする用途はCLIの担当です。

最初のモニタリングチェックを作る

CLIの流れは init → login → test → deploy です。Checkly公式のCLI概要にある手順で、プラグインを入れたClaude Codeにはこれを依頼文で渡せます。

npx checkly init      # 動くサンプルのプロジェクトを作る
npx checkly login     # ブラウザ認証
npx checkly test      # Checklyの実行基盤でドライラン
npx checkly deploy    # チェックを登録し、24時間の監視を始める

依頼文の例を挙げます。

example.com のトップページを監視する URL モニターを作って。
5分おきに実行して、まず npx checkly test で動作を確認して。
deploy は私が内容を見てから承認する。

最後の一文が重要です。次の節で触れるとおり、書き込みコマンドは承認待ちで止まる設計ですが、依頼文でも「デプロイは確認してから」と添えておくと、止まる位置が読めます。

操作の一覧は、スキル本文では initialize(新規セットアップ)、configure(チェックの作成・管理)、investigate(失敗の調査)、communicate(インシデントと通知)、manage(プラン・メンバー)の5つに分かれています。名前がそのまま作業の種類を表すので、依頼文にも使いやすい区分です。

ログインはエージェントが仲介する

npx checkly login は端末の対話を前提にしません。実行するとJSONを1行出して終了します。人の承認が必要なときは、承認用のURLとユーザーコードが入った action_required の行が返ります。

スキルは、このURLとコードをそのままユーザーに伝え、承認を待たずに npx checkly login --wait を実行するよう指示しています。待機は長くなりうるため、バックグラウンドでの実行が前提です。複数のアカウントに所属している場合は select_account が返り、エージェントが勝手に選ぶことはありません。

アカウントの指定は、1回だけなら環境変数を前置します。

CHECKLY_ACCOUNT_ID=<アカウントID> npx checkly test-sessions get <ID>

既定のアカウントを変えるのは、ユーザーが頼んだときだけ(npx checkly switch --account-id <id>)です。キー認証にしたい場合は CHECKLY_API_KEY と CHECKLY_ACCOUNT_ID を環境変数か .env に置きます。

書き込みは確認を挟んで止まる

deploy、destroy、incidents create などの書き込みコマンドは、実行されずに終了コード2と confirmation_required のJSONを返します。スキルは、含まれる changes をユーザーに見せ、承認を得てから confirmCommand を実行するよう求めています。更新や解決も1件ずつ対象です。

例外は、変更のない checkly deploy です。何もないので承認は要らず、No changes. と出て終了コード0になります。

この二重の確認は、Claude Code側の権限設定と組み合わせると運用しやすくなります。たとえば次のような設定が考えられます(運用の一例です)。

{
  "permissions": {
    "allow": [
      "Bash(npx checkly whoami)",
      "Bash(npx checkly skills:*)",
      "Bash(npx checkly test:*)"
    ],
    "ask": [
      "Bash(npx checkly deploy:*)",
      "Bash(npx checkly destroy:*)"
    ]
  }
}

読み取り系とドライランは通し、本番に作用する deploy と destroy は毎回確認する、という分け方です。checkly スキルのfrontmatterには allowed-tools: Bash(npx checkly:*), Bash(npm install:*) が宣言されているので、手元の設定で線引きしておく価値があります。

MCPサーバーの権限スコープ

プラグインの .mcp.json は、https://api.checklyhq.com/mcp にHTTPで接続する設定で、次のスコープを要求します。

checks:write と incidents:write が含まれるので、書き込みもMCP経由で可能です。メンバーの招待に関わる account:invite まで要求している点も、承認画面で目に留めておく項目です。MCPを経由した書き込みには、CLIの確認プロトコルが付いてきません。スキルは、MCPに切り替えて書き込む場合も、変更内容を提示して承認を得てから呼ぶよう指示しています。

プラグインを使わずMCPだけ足すなら、Checkly公式の手順は次の1行です。

claude mcp add --transport http checkly https://api.checklyhq.com/mcp

初回のセッションでOAuthの認証が求められます。複数アカウントを使い分けるなら、--header "X-Checkly-Account: <アカウントID>" を付ければ接続先を固定できます。APIキー認証なら --header "Authorization: Bearer <キー>" です。

Playwrightスキルはチェックの質を担う

もう1つのスキルは、Playwrightテストの書き方に特化しています。ChecklyのBrowserチェックはPlaywrightのテストコードで書くため、ここでの指針がそのままチェックの安定性につながります。

核になる原則は6つです。

デバッグでは、Playwrightのエージェント向けCLI(playwright-cli)を使う流れが前提です。ページを開いてアクセシビリティツリーを読み、そこからロケーターを決める手順が書かれています。Playwright自体の使い方はClaude CodeとPlaywrightのE2Eテストで扱っています。

つまずきやすい点

最初に押さえておくと詰まりにくいのは次の4点です。

• 承認状況の表示が一致しない: claude.comのプラグインページには「Anthropic verified」の表示があります。一方、Checkly側のドキュメントは、AnthropicとOpenAIへ提出済みで審査待ちであり、承認まではGitHubリポジトリから入れるよう案内しています。表示の更新時期が違う可能性があるため、導入時にそれぞれのページを見比べてください
• アカウントの食い違い: CLIのログインとMCPのセッションは別のアカウントを指すことがあります。スキルは、同じ作業の中で両方の結果を混ぜる前にアカウントIDの一致を確かめるよう求めています
• 再起動が要る: 導入後はエージェントの再起動でスキルが読み込まれます
• スキルの中身が毎日変わる: 同期元がmainなので、昨日の手順が今日そのままとは限りません。迷ったら npx checkly skills の出力が最新の基準です

サンドボックス化されたセッションや、シェルを持たないチャットでは、スキルはCLIの手順を打ち切ってMCPのツールを使うよう指示しています。MCPも未接続なら、シェルかMCPのどちらかが要るとユーザーに伝える挙動です。

まとめ

Checklyプラグインの価値は、2つの経路を1回の導入で用意できる点にあります。チェックのコード化と本番反映はCLIの test と deploy、障害時の状況確認はMCP。最初は whoami と test までを許可し、deploy は毎回自分の目で承認する運用から始めると、監視の設定を誤って本番に流すリスクを抑えられます。

ブラウザ操作をMCPで足す場合の設定場所は、Playwright MCPの導入手順にあります。