t3-watch

t3-watch

誰も監視していないものを見守る、待機中のエージェントです。チェックは無料で実行され、何かが変化したときだけエージェントが起動します。

Watch は、CI、クラウドアカウント、API キー、URL、スケジュールされたジョブなど、稼働中のシステムを見守ります。お使いのマシンにすでにあるプロジェクトやログイン情報を使って自動でセットアップし、チェックは独自のスケジュールで通常のコードとして実行するため、モデルのトークンを消費しません。

• ページでは状況を把握して判断できます。何が壊れているか、何があなたの対応待ちかを確認でき、ワンクリックで有効化、一時停止、キーの追加を行えます。キーはここに貼り付け、チャットには貼り付けません。「詳細」ではチェックの名前、実行頻度、設定を編集したり、チェックを削除したりできます。削除したチェックの履歴は保持され、復元できます。
• チャットでは内容を理解し、チェックを作成できます。T3 Code の「Watch」スレッド（または任意の MCP クライアント）で障害を調査し、新しいチェックを作成して、ページをインラインで表示できます。

npx @lfg-labs/t3-watch demo を実行し、サンプルデータを使って録画した 60 秒のデモです。クリックすると、より鮮明な MP4 を表示できます。GitHub ではダウンロードとして提供されます。

ウェブサイト · MCP レジストリ

まず試す

npx @lfg-labs/t3-watch demo

Node 24 以降では、デモによってこのマシン上でサンプルチェックを使った Watch が起動し、ページへのサインインリンクが表示されます。すべてのチェックとアラートにはあらかじめ用意された応答が返され、スキャンもキーの取得も行わないため、アカウントにアクセスしたり、マシン外へ何かを送信したりすることはありません。デモにサインインしても、ご自身の Watch のサインイン状態には影響しません。Ctrl-C で停止して削除できます。ここにある動画とスクリーンショットは、このデモから作成されたものです。

各製品とそのチェック	「詳細」でのチェック編集

インストール

Watch を実行するには、起動したままにできるマシンと Node 24 以降が必要です。

npm install -g @lfg-labs/t3-watch
t3-watch install

install を実行すると、Watch がバックグラウンドでログイン時に起動するよう設定され（Linux では systemd、macOS では launchd）、Codex と Claude Code に MCP サーバーが追加され、ページへのサインインリンクが表示されます。サインインリンクは 1 回だけ、発行から 10 分以内に使えます。そのため、ターミナル、ログ、チャットにコピーを残しても、使用後は役に立ちません。別のブラウザーで使う場合は、t3-watch url を実行して新しいリンクを発行するか、Watch のスレッドでページを尋ねてください。ブラウザーごとに個別のセッションが作成され、エージェントが使うアクセストークンは共有されません。また、t3-watch signout を実行すると、エージェントは引き続き動作したまま、すべてのブラウザーからサインアウトします。

T3 Code では、1 つのプロバイダーに対して複数のアカウントを、それぞれ個別のホームで実行できます。t3-watch install --all を実行すると、T3 の設定で有効になっているすべての Claude Code と Codex のホームにも Watch の MCP サーバーが追加されるため、どのアカウントでも Watch スレッドを使えます。t3-watch uninstall --all を実行すると、それらのホームから再び削除されます。

チェックアウトから実行するには、このリポジトリをクローンし、pnpm install && pnpm build を実行してから、node bin/t3-watch.js install を実行してください。

Linux では、loginctl enable-linger $USER を実行すると、ログアウト中も Watch が動作し続けます。

マシンで Tailscale が動作している場合、install は funnel ではなく tailscale serve を使い、ポート 8461 または次に空いているポートで、tailnet 内に HTTPS でページを提供します。サインインリンクもそのアドレスを指します。ページはご自身のデバイスでのみ開けます。これを実行できるのは Tailscale のオペレーターだけです。install から指示があった場合は、sudo tailscale set --operator=$USER を一度実行してから、install を再度実行してください。--no-tailscale を指定すると、ページはこのマシン上でのみ公開されます。~/.t3-watch/config.json に設定した publicUrl はそのまま維持され、uninstall は install が作成したルートを停止します。host に tailnet アドレスを指定した場合、Watch は 127.0.0.1 でもリッスンするため、tailscale serve でその前段を構成できます。

初回実行

ページを開きます。最初に、Watch が読み取る可能性のある内容が表示されます。確認対象のフォルダーは ~/Projects と、存在する ~/code、~/src、~/dev で、それぞれに含まれる git リポジトリの数も表示されます。また、3 種類のログイン情報（GitHub CLI、AWS CLI プロファイル、.env ファイル内のベンダーキー）も表示されます。Watch に触れさせたくない項目のチェックを外し、必要ならフォルダーを追加して、これらをスキャンを押します。Watch はチェックされた項目だけを読み取ります。コードで使われているベンダーを見つけ、許可したログイン情報をテストし、提案されたチェックをすべて一度ずつ実行します。不要なチェックのチェックを外し、これらを監視を押します。サービスを追加を選ぶと、その後のスキャンのたびに同じ項目を選べます。また、エージェントは watch_sources を使って読み取れます。

Watch は読み取りのみを行います。見つかったキーは暗号化して ~/.t3-watch に保存され、値がページ、ログ、エージェントに渡されることはありません。

Watch スレッド

install を実行すると、T3 Code に Watch というプロジェクトが追加されます。コードを含まない独立したフォルダーに作成されるため、そこで開始するスレッドには、どのリポジトリのフック、スキル、メモリも読み込まれません。そのプロジェクトでスレッドを開始し、「Watch を表示して」と伝えます。エージェントが watch_home を呼び出します。Codex のスレッドではページがインラインで表示され、ボタンも機能します。他のプロバイダーでは、同じ状態がテキストで表示されます。install --no-project を実行するとプロジェクトは追加されず、uninstall を実行してもスレッドはそのまま残ります。

次のように依頼できます。

• 「何が壊れていますか？」または「api の CI が失敗したのはなぜですか？」
• 「Stripe のチェックを月曜日まで一時停止して。」
• 「夜間インポートが実行されたことを確認して。」エージェントがチェックの案を作成し、一度実行してから、有効化できる状態で残します。
• 「Missive も監視して。」エージェントがベンダーの説明を書き、あなたのキーを使ってテストします。
• 「shop.example を Storefront の下に分類して。」ホーム画面では、チェックが製品ごとにグループ化されます。製品名は名前から推測されます。サイトのリポジトリ名が異なる場合、エージェントが製品名を付け、リポジトリがその分類に従います。
• 「アラートを設定して。」ページの詳細にあるアラートから、3 つの手順を確認できます。署名シークレットを作成を押すと、シークレットが一度だけページに表示されます。ここで「アラートを設定して」と伝えます。エージェントがスレッドに紐づく T3 webhook タスクを作成し、Watch の署名を検証するよう設定します。次に、シークレットを非公開の T3 カードに貼り付けるよう求め、タスクのアドレスを Watch に渡し、テストアラートを送信します。タスクが受け付けるのは、Watch のシークレットを持っている場合だけです。ページのテストアラートを送信、またはターミナルで t3-watch alerts test を実行すると、必要なときにいつでも再度テストを送信できます。t3-watch alerts を実行すると、直近のテスト結果がわかります。シークレットがチャットを経由することはありません。Watch は MCP 経由で送信されたシークレットを拒否し、ページに表示されるのは webhook のホストだけです。それ以降は、チェックが失敗し始めた場合、復旧した場合、または実行できない場合にスレッドが起動し、あなたが開く前にエージェントが調査します。問題なく通過し続けているチェックからは何も送信されません。これまで通過していたチェックは、2 回連続で通過しなかった場合にのみ失敗と見なされます。Watch は最初の失敗から 1 分以内に再実行するため、リクエストが 1 回失われただけでは通知されません。復旧はすぐに通知されます。

Slack アラート

詳細の「アラート」で、独自の Slack 着信 Webhook URL をパスワード欄に貼り付け、Slack Webhook を保存を押します。Watch はベンダーキーと同じインストールキーで暗号化し、二度と表示せず、エージェントに渡すこともありません。Slack テストを送信すると、チャンネルがメッセージを受け付けるか確認できます。ここで URL を差し替えるか、Slack を切断して送信を停止します。デモでは実際の Slack URL は使用しません。

Slack アプリで着信 Webhook を作成し、チャンネルを選択してください。Slack と GovSlack に対応しています。Slack の利用に T3 Code アカウントは不要で、T3 スレッドアラートも引き続き併用できます。送信先ごとに個別の配信キューがあります。新規または差し替えた送信先には、過去のイベントではなく、以降の変更が送信されます。

Watch は Slack の変更通知を一度に 1 件ずつ、少なくとも 1 秒間隔で送信します。送信に失敗するとサービスの分単位のタイマーで再試行し、HTTP 429 では Slack の Retry-After に従い、20 回試行した時点で停止します。詳細には最新のテスト結果と配信結果が表示されます。Slack 通知は変更を知らせますが、自動調査には引き続き T3 スレッド Webhook が必要です。

Watch 自身の接続が切れた場合

インターネット接続が必要なチェックが成功しなくなると、Watch はまずインターネットに接続できるかを確認します。https://www.gstatic.com/generate_204 と https://one.one.one.one/cdn-cgi/trace のどちらからも 5 秒以内に応答がない場合、結果を保留します。実行結果はチェックの履歴に保留として表示され、チェックには最後の結果が保持され、アラートは送信されません。ホーム画面と Watch スレッドのステータスには、Watch の接続が切れた時点が表示されます。このマシン上のハートビートとチェックは保留されません。また、プローブ先のアドレスがブロックされている場合に備え、チェックの連続失敗が保留されるのは最大 1 時間分です。

接続が遅い場合も同様に対応します。Web チェックまたはベンダーチェックで公開サイトへの接続がタイムアウトする、切断される、または名前解決が完了しない場合、Watch はプローブにかかった時間を測定します。1 秒以上かかった場合、または 2 分以内に 2 つ以上のサイトで同様の失敗が新たに発生し、プローブに 400 ms 以上かかった場合は、Watch 自身の接続が遅いと判断し、オフラインの場合と同じように失敗を保留します。接続拒否、証明書の不備、HTTP 応答、GitHub と AWS のチェック、および独自のネットワーク上のチェック（アドレス指定の場合も、nas や fritz.box のような名前を使う場合も）は、引き続き結果に反映されます。保留されたチェックの次回実行では、応答を待つ時間が 15 秒ではなく 45 秒になります。ホーム画面と Watch スレッドのステータスには、接続が遅くなった時点が表示されます。プローブまたはリクエストが 400 ms 以内に応答するか、プローブで遅延が検出されなくなると、遅延状態は終了します。

ネットワークでこれら 2 つのアドレスがブロックされている場合は、許可されているアドレスを ~/.t3-watch/config.json の probeUrls に指定して、Watch を再起動してください。リストを空にすると保留は無効になります。Watch はブロックされたリストも自動で検知します。チェックがインターネットに到達した直後にアドレスへのアクセスが 1 時間以内に 2 回失敗すると、保留を停止し、どちらかが応答するか Watch を再起動するまでホーム画面にその旨を表示します。ただし、直前の Web リクエストにプローブの待ち時間を超える時間がかかっていた場合は例外です。この場合はリストがブロックされているのではなく、接続が遅いと判断されます。

ベンダー

各ベンダーは catalog/ にある JSON ファイルです。プロジェクト内での識別方法、キーを保持する変数、キーの送信方法、キーが有効であることを確認する読み取り専用の呼び出し、提示するチェック項目を記述します。ベンダーの追加にリリースは不要で、ファイルを追加するだけです。Watch は、説明に記載された API オリジンに GET リクエストのみを送信します。

対応済み：Stripe、Pipedrive、Missive、Asana、Airtable、Jotform、Calendly、Vimeo、Sentry、OpenAI、Anthropic、Vercel、Cloudflare、Neon、Supabase、Render、SendGrid、Resend、GitLab.com、DigitalOcean。これらの新しい説明が確認するのは API アクセスであり、デプロイの正常性やメールの配信状況ではありません。エンドポイント、必要な権限、制限では、Resend にフルアクセスが必要な理由や、Twilio と Linear がまだサポートされていない理由も含め、使用するキーについて説明しています。Xero は認識されますが、サインイン用ベンダーはまだサポートされていません。

ベンダーファイルが不要なチェック種別：http、github（gh 経由。スケジュールされたワークフローの場合は、workflow に名前を指定し、maxAgeSeconds を追加してください。これにより、GitHub がスケジュールをスキップまたは無効化した場合に、チェックが緑のままではなく失敗します）、 aws_metric（AWS CLI 経由）、heartbeat（ジョブが URL に ping を送信します。失敗時には ?status=fail を追加してください）。

GitHub の runs API は、実行履歴のあるリポジトリに対して、一時的に実行履歴がまったくないと返すことがあります。リポジトリ、ブランチ、ワークフローについて実行履歴を一度でも取得した GitHub チェックは、実行履歴が空の状態を、オフライン中の Watch が失敗を保持するのと同じように保持します。対象は最大で直近 1 時間分の実行履歴で、GitHub が応答してから再確認は行いません。それを過ぎてもリストが空のままであれば、チェックはその旨を表示します。たとえば「GitHub は以前は実行履歴があったにもかかわらず、owner/repo の main に実行履歴がないと報告しました」、または任意のブランチにある単一のワークフローを確認する場合は「owner/repo の refresh.yml」などと表示します。完了した実行がまだないリストでは「完了した実行はまだありません」のままです。別のブランチまたはワークフローを編集すると、チェックの記憶はリセットされます。

開発

pnpm dev          # the service from source, on 127.0.0.1:8460
pnpm test         # unit and integration tests
pnpm typecheck
pnpm build        # server, page and the inline view
node scripts/record-demo.ts   # the README's demo video again, with Chrome and ffmpeg

設計と要件は openspec/ にあります。

ライセンス

MIT ライセンスのもとで、無料で利用できるオープンソースです。