1. そのとき: 「テストは通った」が「動く」を意味しないとき
そのときは、居心地の悪い真実に気づいた日にやってきます。コードが「問題ない」ことは、アプリが動くことを保証しない、という真実です。リリースした、テストはグリーンで通った、デプロイも完璧だった。それなのに、ユーザーがログインできない。なぜ? あなたのコードとユーザーの間には、リポジトリのどんなテストも見えない無数のものがあるからです。サーバー、ネットワーク、本番の設定、遅い外部API、土壇場の変更。
それがWatchの出番です。外から、本物のユーザーのように、本当にアプリをテストしてくれる誰かが必要だと理解したとき — ブラウザを開き、ログイン欄に入力し、ボタンを押し、次の画面が読み込まれるか確認する。コードをレビューするのではなく、アプリを使うのです。それを合成モニタリングと呼び、Watchがあなたの代わりにやってくれます。
2. その痛み: 顧客から知らされる、それはもう手遅れ
その痛みは正直で静かです。劇的ではなく — むしろもっと悪い。ユーザーを失うまで見えないのです。症状はこうです:
- 午前3時にログインが壊れ、あなたが知るのは午前9時、最初の激怒した顧客のメールが届いたとき。
- 文言の変更（「ログイン」→「サインイン」）が、誰も気づかないまま自動化フローを壊す。
- ある画面が8秒かかるようになる。ユーザーは文句を言わず、ただ去っていく。
- 外部APIが失敗してアプリの半分が動かなくなるのに、あなたのモニタリングは「サーバーが応答するか」しか見ていない（そして応答する…壊れたページを返しながら）。
根本の問題はこうです。従来のモニターは「サーバーは生きているか?」しか確認しません。でもサーバーは、壊れたページを配信しながらピンピンしていることがあります。アプリが動くかどうかを知る唯一の方法は、誰かがそれを使うこと。そしてその誰かがいつも障害を発見する本物の顧客なら、もう負けています。
3. その習慣: 見張りは常時であって、一度きりのチェックではない
ここがあなたの行動を変えるところです。Watchはリリース前に一度だけ走らせるテストではありません。繰り返される見回りです。重要なフローを定期的に（たとえば15〜30分ごとに）見張るよう伝えると、各巡回を前回と比較します。昨日は2秒で動いていたのが今日は8秒かかる、それを検知します。昨日は通っていたのが今日は失敗する、それを検知します。
常に見張る価値のあるフロー（壊れたらお金かユーザーを失うもの）はこれです:
- ログイン — 誰も入れなければ、既存の顧客にとってアプリは落ちているのと同じ。
- 登録 — 誰も登録しなければ、成長が止まる（そしてすでに払ったキャンペーンの回収もできない）。
- あなたを食わせるフロー — ユーザーがやりに来たこと（何かを作る、公開する、買う）。
- チェックアウト / 決済 — 壊れれば、静かに売上を失う。
4. しくみを、シンプルな3つのピースで
理解するのにコードの知識はいりません。Watchは3ステップで働きます:
1) あなたが一度フローを記述する。 シンプルなファイル（flows.json）に重要な経路を並べます。「/login を開く、メールを入力、パスワードを入力、ログインを押す、パネルに着くか確認」。本物のパスワードはそこに書きません — 安全な変数を使います。
2) Watchがユーザーのように巡回する。 agent-browser（AIが操作する本物のブラウザ）を使って、まさにそれをやります。開く、入力する、押す、待つ、見る。各ステップにどれだけかかるかを測り、画面をキャプチャします。
3) すべて順調だった前回と比較する。 以前は動いていたステップが今は失敗している? 2秒だったフローが今は8秒かかる? 本当に変わったものだけを知らせます — 同じ警報を百回も送るスパムはなし。
5. インストール方法: コマンド1つ
WatchはClaude Codeのスキルです。コマンド1つでインストールでき、ブラウザのエンジンとしてagent-browserが必要です:
/plugin marketplace add MentexDev/neuralos-watch /plugin install neuralos-watch@neuralos-watch # El motor del navegador (una vez): npm i -g agent-browser && agent-browser install
別のアシスタント? npx skills add MentexDev/neuralos-watch でも動きます。あとはフローのサンプルファイルをコピーして、あなたのアプリに合わせて調整し、AIに普通に話しかけるだけです。
/schedule）で定期的に自動実行するようスケジュールします。正直に言うと、永遠に勝手に走る魔法のサービスではありません — あなたが決めた時間に、あなたのフローを実行する、あなたのエージェントです。6. コピペですぐ使えるプロンプト
ここに最初から最後まで用意しました。エージェントに貼り付けて（Watchはインストール済みで）、[角括弧]を埋め、見張り番に見回りをさせましょう:
neuralos-watch スキルを使って、私の重要なフローの健全性を、read-only かつ非破壊的なモードで確認してほしい（データを消したり、実際の購入をしたりしないこと）。 私のアプリのURL（顧客データのある本番ではなく、staging/テストを指すこと）: [https://staging.miapp.com] 見張る重要なフロー: [例 1) ホームが読み込まれること · 2) メール+パスワードでログイン → パネルに着く · 3) 新しいプロジェクトを作成する] テスト用の認証情報: 環境変数 [WATCH_TEST_EMAIL / WATCH_TEST_PASSWORD] を使い、ここにパスワードを書かないこと。 Watchの手順に従うこと: flows.json がなければ定義を手伝い、agent-browser で各フローを巡回し、時間を測り、レポートを渡してほしい。問題ごとに: 失敗した正確なステップ、スクリーンショット、期待した内容と実際に見つかった内容、そして修正案を。壊れていなくても遅くなったものも印をつけて。 初回の巡回なら、ベースラインを設定すること（まだ比較しないこと）。安全でサンドボックスと明記されていない限り、破壊的または決済のステップは一切実行しないこと。
7. 簡単な道: 誰が何をやるか
- 実際のブラウザで、ユーザーのように、ステップごとにフローを巡回する。
- 時間を測り、画面をキャプチャし、失敗したネットワークリクエストを検知する。
- 前回の正常な巡回と比較し、修正案つきのレポートを書いてくれる。
- 重要なフローをサンプルファイルに記述する（またはAIに手伝ってもらう）。
- 本物の顧客データがある本番ではなく、テスト環境を指すようにする。
- 定期的な自動見張りが欲しいなら、ルーティン（/schedule）をスケジュールする。
8. リポジトリ(無料、MIT、スターを)
Watchはオープンソースで無料です。あなたのユーザーより先に故障を知らせてくれたなら、スターを残してください:
agent-browser を使って実際のブラウザであなたの重要なフローを巡回し、どれかが壊れたり遅くなったりしたときに知らせてくれるロボットユーザー — 失敗したステップ、スクリーンショット、修正案つき。デフォルトで read-only。