今の AI エージェントは、ほとんどどんな API でも呼べます。それは簡単なほうの半分です。難しいのは、受信のほうです。エージェントが Stripe との連携を設定したり、Replicate の prediction を開始したり、GitHub の自動化を組んだりすると、結果は Webhook で返ってきます。そして Webhook には、公開されていて到達できる URL が必要です。それこそが、ターミナルやサンドボックスの中にいるエージェントが持っていないものです。
この記事は、その隔たりについてのものです。今のツールがどこでブラウザーを持つ人間を前提にしているか、そしてエージェントが自力でエンドポイントを手に入れるには何が必要かを扱います。
TL;DR
- エージェントは、自分が作った連携を検証するためにイベントを受信する必要があります。Stripe との連携は、署名付きのイベントが実際に通るまで完成とはいえません
- ほとんどの Webhook ツールは人間を前提にしています。登録フォーム、CAPTCHA、ダッシュボードでしかできない設定、あるいはインストールして見張り続けるバイナリです
- エージェントが操作できるサービスに必要なのは 4 つです。1 回の呼び出しで始められること、API で読めるイベントログ、機械可読なドキュメント、そして人間への引き継ぎ手段です
- うまくいくパターンは、エージェントが API か MCP でエンドポイントを立ち上げる → イベントを受信して調べる → 人間がアカウントに紐付けて引き継ぐ、という流れです
AI エージェントが Webhook を受信する必要がある理由
繰り返し出てくる状況が 3 つあります。
1 つ目は、自分の作業を検証することです。Stripe の Webhook ハンドラーを書いたエージェントは、署名付きの本物の checkout.session.completed イベントが届くまで、そのハンドラーが動くかどうかを知る方法がありません。ペイロードをモックすると、本番環境で実際に壊れる部分、つまり署名、ヘッダー、リトライを飛ばすことになります。エージェントには、本物の配信を受け止める本物のエンドポイントが必要です。
2 つ目は、非同期の結果を待つことです。Replicate の prediction、OpenAI のバッチジョブ、動画のレンダリング、CI のパイプライン。どれも、完了の合図は Webhook です。エンドポイントのないエージェントはポーリングするしかなく、「もう終わった？」のためにトークンとレート制限を消費し続けます。
3 つ目は、連携を端から端まで構築することです。ユーザーが「Shopify のストアをこの Slack チャンネルにつないで」と言ったら、エージェントには Shopify のイベントを受け止める場所が必要です。実際に何が届いたかをデバッグするために読めるログも必要です。
エージェントがエンドポイントを手に入れようとすると壊れるもの
エージェントの側から試すと、どのツールを選んでも、ほぼすぐに壁にぶつかります。
登録の壁と CAPTCHA は、まさに自動化を止めるために存在します。URL を発行する前にそれを解かせるサービスは、設計上、エージェントに閉ざされています。
ダッシュボードでしかできない設定が、次の壁です。転送先 URL や署名シークレットを UI をクリックしてしか設定できないなら、本来は 1 回の HTTP 呼び出しで済むはずのことに、エージェントはブラウザー自動化を必要とします。
トンネルには、バイナリと見張り役が必要です。ngrok のようなトンネルは、ローカル開発をする人間にとっては優れたツールです。しかしエージェントは、バイナリをインストールし、認証し、プロセスを生かし続け、URL がセッションとともに消えることを受け入れなければなりません。サンドボックスが一時的なものなら、そしてほとんどのエージェントのサンドボックスはそうですが、非同期のジョブが終わる前にエンドポイントは消えています。
一時的な URL は、タスクの途中で尽きます。webhook.site の無料の URL は、100 件のリクエストを受けると受け付けを止め、7 日後に削除されます。人間のデモには十分ですが、エージェントが動かし続けるつもりだった連携にとっては致命的です。
エージェントが操作できる Webhook サービスの条件
優先順位の高い順に、4 つの要件があります。
- 1 回の呼び出しで始められ、認証情報が要らないこと。
POST /quickstartが、エンドポイントの URL と API キーを返します。アカウントも、CAPTCHA も、メール確認の往復もありません。（不正利用への対策は、登録の手間ではなく、レート制限と TTL に移ります。） - すべてを API で読み書きできること。イベントログ、ペイロードの確認、転送先の設定のすべてに、手順 1 のキーでアクセスできます。エージェントがダッシュボードを見ることはないからです。
- 機械可読なドキュメントがあること。
llms.txt、OpenAPI の仕様、プレーンな Markdown の料金ページです。ツールを評価するエージェントが読むのはこれらで、デモ動画は見ません。 - 人間への引き継ぎ手段があること。エージェントの作業を行き止まりにするべきではありません。エージェントが設定したものに人間がログインし、アカウントに紐付けて自分のものにできる URL があれば、使い捨てのテストが長く使えるインフラに変わります。
その上に MCP サーバーを載せるのが、自然なパッケージングです。エージェントのランタイムがツールを見つけ、立ち上げは curl ではなくツール呼び出しになります。
現状を正直に比べる
| ツール | エージェント単独で立ち上げられるか | エンドポイントはセッション後も残るか | 備考 |
|---|---|---|---|
| webhook.site | 一部可。API がある | 無料の URL は 100 件のリクエストで止まり、7 日後に削除される | 人間がすばやく確認するには優れている。API はあるが、永続化は有料 |
| ngrok | 不可。バイナリ、アカウント、認証トークンが必要 | 残らない。プロセスとともに消える | 対象が本当に localhost なら、今も正しい選択 |
| Hookdeck | 一部可。CLI に MCP サーバーが付属 | 残る | 本格的なイベントゲートウェイ。MCP を使うには、先に認証済みの CLI セッションが必要 |
| AnyHook | 可。キー不要の POST /quickstart、MCP が自分で立ち上げる | 残る。匿名なら 7 日、アカウントに紐付ければ無期限 | リトライ、ログ、再送を備えた中継。Pro 以上なら、イベントごとに独自のコードも実行できる |
AnyHook 自身の限界も、はっきりさせておきます。ペイロードの変換や、多数のコンシューマーへのファンアウト（1 つのイベントを複数の転送先に配信）が必要なら、Hookdeck のほうが充実した製品です。ハンドラーがノート PC 上で動いているなら、トンネルを使ってください。AnyHook は、エージェントネイティブな用途のために作られています。つまり、人の手を借りずに立ち上げ、セッションを越えて残り、後で引き継ぐ、という用途です。
実際のパターン
立ち上げ（任意の HTTP クライアントで、アカウント不要）：
curl -X POST https://anyhook.net/api/v1/quickstart
# → { "inbound_url": "https://in.anyhook.net/q-8f3a/quickstart",
# "api_key": "ahk_live_...", "claim_url": "https://anyhook.net/claim/..." }
または、エージェントの MCP ランタイムに任せます。設定は 1 行で、事前のキーも要りません。
{ "mcpServers": { "anyhook": { "command": "npx", "args": ["-y", "anyhook-mcp"] } } }
anyhook_quickstart ツールがエンドポイントを作り、anyhook_events と anyhook_inspect が届いたものを読み取ります。作業が終わったら、エージェントは人間に紐付け用の URL を渡します。すると匿名の設定は、同じエンドポイント、同じキーのまま、通常の Free プランのアカウントになります。
隣接する 2 つのパターンも、同じ仕組みを使います。エージェントに URL ではなくインボックスを持たせる方法は AI エージェントにメールアドレスを持たせるで、その下にあるルーティング層は Cloudflare Email Routing でメールを Webhook に変えるで説明しています。
よくある質問
AI エージェントは、人間の関与なしに本当に Webhook サービスを使える？
はい。サービスがキー不要の立ち上げに対応していれば、使えます。エージェントは 1 回の API 呼び出しでエンドポイントを作り、プロバイダーをそこに向け、届いた配信を API で読み返します。人間が必要になるのは、設定を永続的なものにしたいときだけで、紐付け用の URL はそのためにあります。
キー不要のエンドポイントは、不正利用の温床にならない？
対策の場所が移るだけです。作成時の IP ごとのレート制限、Free プランのイベントのクォータ、アカウントに紐付けられていないエンドポイントの 7 日の TTL が、被害を一定の範囲に抑えます。CAPTCHA は、この流れが想定しているユーザーこそを締め出してしまうので、この交換には価値があります。
Webhook の代わりにポーリングを使うのは？
ポーリングでも動きますが、エージェントにとってはうまくスケールしません。「もう終わった？」のたびに、リクエストとレート制限の枠を消費し、多くの場合はトークンも消費します。1 分を超える処理なら、最後に 1 回確認すればよい Webhook エンドポイントのほうが、安く、速く済みます。
AnyHook は Webhook 中継サービスです。URL を 1 つ変えるだけで、リトライ、完全なイベントログ、ワンクリックの再送が手に入ります。上のクイックスタートは無料で、アカウントも要らないので、エージェントで今すぐ試せます。