トリガー:webhookモード

本当に何かが起きたとき
エージェントが動き出す

トリガーが答えるのは一つの問いだけです:このエージェントはいつ起動するのか?スケジュールタスクは時刻で答えます。webhookトリガーは外の世界のイベントで答えます。pull requestが開き、ビルドが壊れ、アラートが発火する。そのときエージェントはもう動いています。

AgentsRoomは、トリガーごとに公開URLと署名用シークレットを発行します。そのURLをGitHub、GitLab、Slack、Linear、Sentry、あるいはJSONをPOSTできるものに貼り付けてください。リクエストが届き、署名が検証され、ペイロードがあなたのプロンプトの変数になり、本物のエージェントが自分のターミナルとトランスクリプトを持ってプロジェクト内で起動します。

Webhookトリガー受信待ち
POSTGitHubpull_requestAPIにrate limitingを追加
署名を検証
フィルターに一致
コードレビュアー
{{event.title}} = APIにrate limitingを追加
何も起きない間は、何も動かないイベントで起動

1つのトリガー、1つの公開URL。イベントが届き、署名が検証され、ペイロードがプロンプトの変数になり、あなたのプロジェクトでエージェントが起動します。

スケジュールタスクは問題の半分を解決しました。毎朝8時にpull requestをレビューして、とエージェントに頼むことはもうできます。けれどエージェントに任せたい仕事の大半は8時には起きません。誰かがpull requestを開いたとき、ビルドが赤くなったとき、顧客が午後2時にバグを報告したときに起きます。

これまでそれを捕まえる唯一の方法は、エージェントに見張らせることでした。短い間隔で実行し、APIをポーリングさせ、「何か新しい?」と尋ねさせ、「いいえ」という答えのために一日に何百回もトークンを払う。高くつき、反応は遅く、リポジトリを3つ見張ろうとした途端に破綻します。

webhookトリガーは向きを逆にします。知らせてくるのはサービスのほうです。AgentsRoomがURLを渡すので、それをGitHub、GitLab、Slack、Linear、Sentry、あるいはCIに貼り付けます。そのサービスが呼び出すまで、何も動きません。呼び出せば、イベントがすでにプロンプトに入った状態でエージェントが起動します。静かな一日はトークンゼロ、そうでない日は数秒でエージェントが現場に入ります。

イベントがポーリングループに勝つ理由

沈黙にお金を払うのをやめられます。5分ごとにリポジトリを確認するエージェントは、5分ごとにコンテキストを丸ごと1ターン消費し、そのほとんどは何も見つけません。トリガーは、イベントが届くまで何一つ消費しません。

反応は即座です。調整すべき間隔もなく、ちょうど確認が終わった直後だからpull requestが11分放置される、という時間帯もありません。エージェントはリクエストを受けて起動するので、作者がページを再読み込みするころにはレビューが待っています。

イベントは自分のデータを連れてきます。ペイロードは、プロンプトにそのまま差し込める変数に分解されます:タイトル、作者、URL、番号、ブランチ、あるいは生のJSON全体。エージェントは、自分を起こしたものを取りに行く必要がありません。

画面はあなたがすでに知っているものです。トリガーは、スケジュールタスクのリスト、オン・オフの切り替え、実行ごとの履歴、エージェントの選択、マシン単位のスコープをそのまま引き継ぎます。webhookは「いつ発火するか」への、もう一つの答えにすぎません。

1つのトリガー、2通りの発火

同じパネルが両方を持ちます。あなたが待っているものに合うほうを選んでください。

スケジュール

元からあるモード、そのままです。N分ごと、毎時、毎日、毎週、毎月、cron式を書く必要はありません。時計に属する仕事のために:朝のレビュー、月曜の依存関係チェック、金曜のchangelog。

Webhook

エージェントは時刻ではなくイベントを待ちます。AgentsRoomが公開URLと署名用シークレットを渡すので、URLをサービスに貼り付ければ、そのサービスがPOSTした瞬間にトリガーが発火します。何かが起きたことに属する仕事のために:pull request、失敗したビルド、新しいバグ報告。

何をトリガーにするか

実際のイベントと、その先に置きたいエージェント。

開かれた瞬間に、すべてのpull requestをレビュー

GitHubまたはGitLabのwebhookをトリガーに向け、pull requestが開かれたときだけを通すフィルターをかければ、レビュアーエージェントが数秒でdiffに取りかかります。作者は、変更がまだ頭に残っているうちにフィードバックを受け取れます。

赤いビルドを自動で調査する

あなたのCIは、パイプラインが失敗したときにPOSTできます。トリガーは、ブランチと実行のURLをプロンプトに入れてエージェントを起動するので、赤いバッジではなく、失敗したジョブを読んだうえでの原因が返ってきます。

報告された瞬間にクラッシュをトリアージする

Sentryのアラートをトリガーにつなぎます。本番の新しい例外が、エラーのタイトルとチケットのURLを持つバックエンドエージェントを起動するので、誰かがダッシュボードを開くより先に、スタックトレースの最初の一読が終わっています。

Slackからエージェントを起動する

Slackのスラッシュコマンドやアウトゴーイングwebhookから、トリガーのURLを叩けます。誰かがチャンネルで依頼を打てば、ペイロードがプロンプトに届き、エージェントが正しいプロジェクトでそれを引き受けます。

作成された直後に、新しいチケットを固める

GitHub、GitLab、Linearでチケットが作成されると、プロダクトエージェントが起動して報告を読み、足りない点を質問し、開発者がそのまま着手できる形に変えます。

デプロイのたびにQAパスを実行する

デプロイのパイプラインは、リリースが出たときにPOSTします。トリガーはQAエージェントを起動し、リリースと何の関係もないスケジュールではなく、たった今出たバージョンに対してアプリを動かします。

タグでリリースノートを書く

タグがpushされ、リリースが公開されると、ドキュメントエージェントがコミットを読めるノートに変えます。イベントがタグ名を運ぶので、エージェントはどの範囲を要約すべきかを正確に把握しています。

JSONをPOSTできるものなら、何でも

対応を待つ統合リストはありません。サーバー上のcron、Zapierのステップ、監視ツール、あなた自身のバックエンド:署名付きのPOSTをURLに送れるなら、それであなたのプロジェクトのエージェントを起動できます。

webhookトリガーの仕組み、ステップごとに

空のフォームから、本番に反応するエージェントまで、数分で。

01

トリガーを作る

プロジェクトでトリガーパネルを開き、新しいものを1つ作ります。同じリスト、同じオン・オフの切り替え、スケジュールタスクと同じ履歴です。同じパネルなのですから。

02

Webhookに切り替える

スケジュールの代わりにWebhookを選びます。AgentsRoomがこのトリガー用の公開URLと、その隣に署名用シークレットを生成します。シークレットはいつでも再生成でき、古いものを持っていた相手を締め出せます。

03

URLをサービスに貼り付ける

GitHubやGitLabのwebhook、Slackアプリ、LinearやSentryの連携、あるいはあなたのCIに入れてください。署名用シークレットもサービスに渡せば、送られてくるリクエストを検証できます。

04

本当に発火すべきものだけを絞る

リポジトリはたくさんのイベントを送ってきます。ペイロードに任意の条件を足せば、たとえばactionがopenedのときだけにして、それ以外はすべて無視できます。バースト制限を設ければ、騒がしいサービスが1分で20個のエージェントを起動することもありません。

05

イベントをプロンプトに入れる

イベントの変数を使ってプロンプトを書きます:タイトル、作者、URL、番号、ブランチ、あるいはペイロード全体。スケジュールタスクがすでに対応している日付と時刻の変数とまったく同じように、トリガーが発火したときに解決されます。

06

最後のリクエストを再送して、本番へ

エディターは、トリガーが最後に受け取ったリクエストを生のJSONごと表示し、ワンクリックで再送します。webhookは推測ではなく、見ながら配線するものです。正しくなったら、トリガーをオンにします。

Webhookモードで開いたAgentsRoomのTriggersエディター:サービスに貼り付けるために生成されたトリガーのURLとCopyボタン、署名用シークレットの欄、Any service (JSON)、GitHub、GitLab、Slack、Linear、Sentryが並ぶ送信元の選択、action == "opened" に設定されたOnly fire ifのフィルター、実行を最大2分に1回に抑えるバースト保護の設定、そしてプロンプトで使えるイベントの変数。
Webhookモードのトリガーエディター:サービスに貼り付けるURLが1つ、署名用シークレット、任意のフィルター、バースト保護の時間枠、そしてすでにプロンプトの変数に対応づけられたペイロードの項目。

サービスの並びはショートカットであって、許可リストではありません。エディター自身が選択肢の下でそう書いていますし、最初の項目がAny service (JSON)なのもそのためです。JSONの本文をPOSTできるものなら何でも動きます。GitHub、GitLab、Slack、Linear、Sentryを選ぶと増えるのは、ちょうど2つだけです:検証に使うそのサービス固有の署名ヘッダーと、イベントの変数にすでに対応づけられたペイロードの項目。リストにないという理由で拒否されるものは、何もありません。

変数のチップはドキュメントではなく、ボタンです。クリックすればプロンプトに挿入され、最後のリクエストで実際に値が入ったものはハイライトされます。その下には、トリガーが最後に受け取ったリクエストが置かれています。だから、目に見える本物のペイロードに対してフィルターとプロンプトを書き、それを再送し、実行が正しく出てからトリガーをオンにできます。

イベントからエージェントへステップ1/4
  1. イベントがトリガーのURLに届く

    サービスがJSONをPOSTします。AgentsRoomはあなたのシークレットで署名を検証し、署名のないリクエストは拒否します。フィルターを設定していれば、そのあとに適用します。

  2. 誰もいなければ、待つ

    あなたのマシンは落ちていて構いません。イベントは捨てられずに最長1週間保持され、次回起動時に再送されます。スケジュールタスクがすでに使っているのと同じ追いつきの仕組みです。

  3. 取るマシンは、一台だけ
    会社のMac
    自宅のMac
    ビルドマシン

    複数のコンピューターでプロジェクトを開いていても、最初にそのイベントを取ったマシンがロックします。ほかのマシンは取られたことを見て先に進むので、1つのイベントが2つのエージェントを生むことはありません。

  4. エージェントが、一度だけ実行される

    あなたが選んだロール、プロバイダー、モデルを持つ本物のエージェントがプロジェクト内で開き、専用のターミナル、会話ビュー、そしてあとから読み返せるアーカイブ済みのトランスクリプトが残ります。

公開URL、ただし開いた扉ではない

URLはインターネットから届きます。だからトリガーは、何かが始まる前に、何を受け入れるかを決めます。

すべてのリクエストは署名される

AgentsRoomは、何かが始まる前に、すべてのリクエストをあなたのシークレットで検証します:GitHubにはX-Hub-Signature-256、SlackにはX-Slack-Signature、GitLabには共有トークンのX-Gitlab-Token、Linear、Sentry、その他の一般的なソースには生の本文に対する素のHMAC。署名のないリクエストは拒否されるので、URLを知っているだけでは、あなたのマシンでエージェントを起動できません。

シークレットは好きなときに入れ替える

署名用シークレットはエディターに表示され、その場で再生成できます。古いリクエストはただちに検証を通らなくなります。サービスを止めた日や、シークレットがログに漏れた日に、まさに欲しい挙動です。

ペイロードで絞り込む

任意の条件が、そのイベントにエージェントを割く価値があるかを決めます。actionがopenedのときだけ、1つのブランチだけ、1つのラベルだけ発火させる。条件に合わないものは、何も起動せずに捨てられます。

バースト保護

時間枠あたり、実行は最大1回です。10秒で30件のイベントを送るサービスが、30個のエージェントを起動することはありません。その枠内に届いたリクエストはまとめられ、1回の実行がそれらをカバーします。

ペイロードが、あなたのプロンプトになる

サービスが送ってきたJSONは、プロンプトに直接書ける変数に分解されます。スケジュールタスクがすでに使っている日付と時刻の変数と同じく、発火の時点で解決されます。

プロンプトを一度書けば、どの実行も、自分を起動したイベントのデータを受け取ります。

  • {{event.title}}イベントのタイトル:pull requestのタイトル、チケットのタイトル、アラートの名前。
  • {{event.author}}誰が起こしたか:pull requestの作者、チケットを開いた人。
  • {{event.url}}イベントに戻るリンク。エージェントがpull requestやアラートを開けます。
  • {{event.number}}pull requestやチケットの番号。サービスがそれを送ってくる場合に。
  • {{event.branch}}イベントが対象とするブランチ。push、pull request、失敗したビルドのために。
  • {{payload}}生のJSON全体。名前付きの変数でカバーできないもののために。
プロンプトの例
Review pull request #{{event.number}} "{{event.title}}" opened by {{event.author}} on branch {{event.branch}}. Read the diff at {{event.url}} and reply with the risky parts first.

変数名は、プロンプト欄に二重の波かっこで囲んで書きます。スケジュールタスクの日付と時刻の変数とまったく同じです。

GitHub
event.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.state
GitLab
event.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.state
Slack
event.actionevent.titleevent.bodyevent.authorevent.channelevent.urlevent.team
Linear
event.actionevent.numberevent.titleevent.bodyevent.authorevent.assigneeevent.stateevent.priorityevent.urlevent.team
Sentry
event.actionevent.titleevent.bodyevent.levelevent.projectevent.urlevent.count
Generic JSON
event.actionevent.titleevent.bodyevent.authorevent.urlevent.id

実際に何が、どこで実行されるのか

スケジュールタスクと同じ正直な実行モデルを、イベントに広げたものです。

アプリが閉じていても、何も失われない
AgentsRoomが動いていない間に届いたイベントは、サーバーのキューに入り、最長1週間、次回起動時に再送されます。エージェントは、起動しないのではなく少し遅れて起動します。
1つのイベントに、1つのエージェント
複数のコンピューターでプロジェクトを開いていても、最初にイベントを取ったマシンがロックします。ほかのマシンはそれを飛ばします。2台のマシンが同じwebhookに二度答えることはありません。
スクリプトではなく、本物のエージェント
実行はプロジェクト内に本物のエージェントを開きます。ロール、プロバイダー、モデル、effort、skills、システムプロンプト、そして専用のターミナルと会話ビューを持っています。実行の途中であなたが引き継げます。
実行ごとの履歴
発火するたびに、そのエージェントが書いた内容がトリガーの履歴に残ります。セッションを閉じたあとでも、同じアカウントにサインインした別のマシンからでも読み返せます。

イベントはどこから来るのか

JSONの本文を持つ署名付きPOSTを送れるものなら、何でもエージェントを起動できます。まず配線されるのは、このあたりです。

あなたのCI、あなたのバックエンド、何でも

パイプラインのステップ、監視ツール、社内サービス、curlを使ったシェルスクリプト。申請すべき統合はありません。JSONの本文と署名を持つPOST、それが契約のすべてです。

GitHubとGitLab

pull requestやmerge requestが開かれた、レビューされた、マージされた、チケットが作成された、push、リリース、失敗したワークフロー。定番のソースであり、もっとも役に立つペイロードを持っています。

Slack

スラッシュコマンドやアウトゴーイングwebhookが、チャンネルのメッセージを、正しいプロジェクトでのエージェント実行に変えます。Slackの署名はX-Slack-Signatureで検証されます。

LinearとSentry

チケットが別のカラムに移った、本番で新しい例外が出た、リグレッションのアラートが鳴った。トラッカーが発火し、チケットやエラーをプロンプトに入れてエージェントが起動します。

同じパネルの、もう半分

トリガーとスケジュールタスクは、同じ問いへの2つの答えを持つ1つの機能です。スケジュールタスクは、イベントが時計であるトリガーです。webhookトリガーは、スケジュールが外の世界であるスケジュールタスクです。同じリストに並び、同じエージェント設定、同じ有効化スイッチ、同じ実行履歴、同じマシン単位のスコープを共有します。

だから道具ではなく、仕事ごとに選べます。依存関係の監査は月曜の朝のままです。パッケージが古くなったことを、外の誰も知らせてくれないからです。pull requestのレビューはwebhookに移ります。それが起きるべき正確な瞬間を、GitHubがすでに知っているからです。この家族の時計側については、スケジュールタスクのページを読んでください。

スケジュールタスクを見る:同じパネルの時計側

FAQ

AgentsRoomのwebhookトリガーとは何ですか?

決まった時刻ではなく、外部サービスからイベントが送られてきたときにAIエージェントを起動するトリガーです。AgentsRoomはトリガーに公開URLと署名用シークレットを与えます。そのURLをGitHub、GitLab、Slack、Linear、Sentry、あるいはJSONをPOSTできるどんなツールにも貼り付けてください。そのサービスが呼び出すと、署名が検証され、設定していれば任意のフィルターが適用され、ペイロードがすでにプロンプトの変数として使える状態で、あなたのプロジェクト内にエージェントが起動します。

スケジュールタスクとは何が違いますか?

変わるのは「いつ発火するか」という問いだけです。スケジュールタスクは時計で発火します:N分ごと、毎時、毎日、毎週、毎月。webhookトリガーは外からのイベントで発火します。それ以外はすべて共通です:同じリスト、同じオン・オフの切り替え、同じエージェント設定、同じ実行ごとの履歴、同じマシン単位のスコープ。

エージェントにAPIをポーリングさせるのではだめですか?

ポーリングは一周ごとにトークンを使い、しかもほとんどの周回は何も見つけないからです。5分ごとにリポジトリを確認するエージェントは、「いいえ」と答えるために5分ごとに丸ごと1ターンを実行します。webhookトリガーは何も起きていない間は何も消費せず、何かが起きれば数秒で反応します。これがこの機能の経済的な理由のすべてです。

トリガーのURLは公開しても安全ですか?

URLだけでは何も起動できません。すべてのリクエストは、あなたのシークレットを持つサービスから来たことを証明しなければなりません:GitHubにはX-Hub-Signature-256、SlackにはX-Slack-Signature、GitLabには共有トークンのX-Gitlab-Token、Linear、Sentry、その他の一般的なソースには生の本文に対する素のHMAC。署名ヘッダーのないリクエストは拒否され、素通りすることは決してありません。シークレットはエディターに表示され、いつでも再生成できます。再生成すれば、古いシークレットを使っていたものはただちに無効になります。

一部のイベントだけで発火させられますか?

はい。リポジトリは、エージェントを割きたい数よりずっと多くのイベントを送ってきます。だからトリガーは、ペイロードに任意の条件を1つ取ります。たとえばactionがopenedと等しいとき、といった具合です。一致しないイベントは無視され、何も起動されません。バースト制限もあります:時間枠あたり実行は最大1回で、その枠内に届いたリクエストはまとめられます。

イベントが届いたときにAgentsRoomが閉じていたら、どうなりますか?

イベントはサーバーのキューに入り、次にアプリを起動したときに再送されるので、一度も実行されないのではなく、遅れて実行されます。キューのイベントは1週間保持されます。長い週末のあいだノートPCを閉じていても足りる一方で、戻ってきたときに1か月分の古い仕事が再送されることはありません。スケジュールタスクが使っているのと同じ「アプリ内+追いつき」のモデルです。webhookトリガーがあなたのエージェントをクラウドで動かすことはありません。エージェントは常に、あなたのマシンの、あなたのプロジェクトで実行されます。

2台のコンピューターでプロジェクトを開いています。エージェントは二度実行されますか?

いいえ。イベントは一度しか消費されません。最初に拾ったマシンがそれをロックし、ほかのマシンは取られたことを見て飛ばします。特定のコンピューターに担当させたいなら、スケジュールタスクとまったく同じように、トリガーを指定のマシンに固定することもできます。

イベントから、プロンプトに何を入れられますか?

ペイロードは、プロンプト欄に二重の波かっこで囲んで直接書ける変数に分解されます:event.title、event.author、event.url、event.number、event.branch、そして生のJSON全体を表すpayload。スケジュールタスクの日付と時刻の変数と同じく、トリガーが発火したときに解決されます。

自分のwebhookが正しく配線できているか、どうやって分かりますか?

エディターは、トリガーが最後に受け取ったリクエストを生のJSON本文ごと表示し、ワンクリックで再送できます。だから、目に見える本物のペイロードに対してフィルターとプロンプトを合わせ、実行が正しくなるまで再送すればよく、結果を知るためにテスト用のコミットをpushする必要はありません。

どのサービスに対応していますか?

JSONの本文を持つ署名付きPOSTを送れるサービスなら、どれでもです。GitHub、GitLab、Slack、Linear、Sentryはペイロードが豊富なので最初に配線されがちですが、許可リストのようなものはありません:CIのジョブ、監視ツール、あなた自身のバックエンド、シェルスクリプトの中のcurlも、まったく同じように動きます。

これは複数ステップのシナリオを組む、ビジュアルな自動化ビルダーですか?

いいえ。そうなろうともしていません。トリガーの仕事は1つだけです:エージェントをいつ起動するかを決め、イベントを渡すこと。複数ステップの部分はエージェント自身が担い、コードを読み、ツールを走らせ、仕事をします。複数のエージェントに作業を引き継がせたいなら、それはシナリオのキャンバスではなく、エージェントチームの役目です。

AgentsRoomから、他のサービスにwebhookを送れますか?

トリガーは受信専用です:AgentsRoomはイベントを受け取りますが、送り出しません。実行の最後にエージェントから外部サービスを呼びたいなら、それは、あなたが与えたツールとMCPサーバーを使うエージェント自身の仕事です。

相性のよい機能

ポーリングをやめて、反応しよう。

AgentsRoomをダウンロードして、URLを1つGitHub、GitLab、Slack、Linear、Sentryに貼り付け、イベントにエージェントを起動させましょう。何も起きない間は、何も動きません。

無料AgentsRoomをダウンロード

コンパニオンアプリ:外出先でもエージェントを確認

Claude、Codex、Antigravity CLI、またはその他の AI プロバイダーを使用します。

拡張機能を入手
Chrome Web Store

バグや要望を公開バックログに直接送信できます。

実際の AgentsRoom の様子。

マルチプロジェクト
マルチプロバイダー
マルチエージェント
ライブステータス
ファイル差分
モバイルアプリ
ライブプレビュー
エージェントチーム
ブラウザテスト
バックログ駆動開発
プロンプトライブラリ
スキルライブラリ
すべての機能を見る