AI エージェントはあなたを待っている：承認待ちを電話呼び出しに変える

目次

• エージェント関連のインシデントは実際どれくらい多いのか
• エージェントが人間を必要としたとき、実際に何が起きるのか
• どのエージェントイベントが電話に値するのか
• エージェントの承認ゲートを電話につなぐ手順
• ステップ 1 —— ブロックされたエージェント専用の通話チャネルを作る
• ステップ 2 —— 承認分岐から Webhook を送る
• ステップ 3 —— エージェントがライブラリではなく CLI のときはフックを使う
• ステップ 4 —— メールしか送らないエージェントを拾う
• ステップ 5 —— 条件を付けて本物のブロックだけを鳴らす
• ステップ 6 —— おやすみモードをオンにしてテストする
• これは音の大きいアラート疲れを作り直すだけでは？
• Echobell がやらないこと
• FAQ
• 電話に出たまま承認できますか？
• フレームワークのどのイベントで Webhook を叩くべきですか？
• CI 上のヘッドレスエージェントでも使えますか？
• MCP の elicitation は具体的にどう扱えばよいですか？
• エージェントの出力を通知に載せても安全ですか？
• チーム全員が同じエージェントアラートを受け取れますか？
• iOS 専用ですか？
• WebhookMCP の構成と何が違いますか？
• 関連記事

2026 年に登場した自律エージェントのフレームワークには、どれも同じ穴が空いています。エージェントはあなたなしで何時間も走り、単独では実行を許されていない操作にぶつかって停止し——そこから何も起きません。実行は失敗しません。リトライもしません。シリアライズされた状態オブジェクトを抱えたままメモリ上に座り込み、自分が待たれていることを知らない人間を待ち続けます。本記事では、Echobell を使ってエージェントの「人間が必要だ」という瞬間を鳴り響く電話に変え、この穴を塞ぐ方法を説明します。

この隙間は特定製品のバグではなく、構造的なものです。OpenAI のエージェント向けドキュメントは承認フローをこう記述しています。ツールが承認を必要とするとき「承認または拒否するまで実行は一時停止する」。結果には interruptions と再開可能な state が返り、レビューに時間がかかりそうなら state をシリアライズして保存し、後で再開せよ、と書かれています（OpenAI、Agents SDK ガイド）。このフローのどこにも、人間に届く部分はありません。承認者への通知は完全にあなたの実装に委ねられています。

その一方で、実行時間はどんどん長くなっています。AWS は自社のフロンティアエージェントを「介入なしで数時間から数日にわたって動作できる」と説明しています（About Amazon）。2026 年 8 月 4 日にローンチした Kiro Crew はもっと直接的です。「マイグレーションを開始すれば、あなたが会議中でも寝ていても、チェックポイントとリトライを通じて進み続ける」——そのうえで「ツールリクエストには承認を必須にできる」とも述べています（Kiro）。この二つは同時に真です。エージェントはあなたが寝ている間に働き、そしてあなたが寝ている間に止まります。

エージェント関連のインシデントは実際どれくらい多いのか

大半の企業が経験しており、しかも大半はエージェントを完全放任していません。 Cloud Security Alliance が Token Security の委託により 2026 年 1 月に実施した IT・セキュリティ専門家 418 名への調査では、65% の組織が過去 1 年に少なくとも 1 件の AI エージェント関連インシデントを報告しました。内訳はデータ露出 61%、業務中断 43%、金銭的損失 35% です（CSA プレスリリース、レポート）。

アラート設計にとって重要なのは、同じ調査のガバナンス側の数字です。完全自律で動かしているのは 13% だけ。53% は低リスクのタスクのみ自律に任せ、高リスクな操作には人間のレビューを挟みます。24% はほとんどのタスクで人間を介在させています。さらに 82% が過去 1 年に環境内でシャドー AI エージェントを発見しています。

これは脅し文句ではなく運用上の事実として読んでください。およそ 4 分の 3 の組織が、意図的にエージェントへ一時停止を組み込んでいるのです。その一時停止のひとつひとつが、機械が人間でブロックされている瞬間です。その人間が翌朝 9 時に気づくのなら、エージェントが夜通し働ける能力には何の価値もありません。

エージェントが人間を必要としたとき、実際に何が起きるのか

**静かに待ちます。そして、どのフレームワークも通知はあなた任せです。**仕組みは違っても、結果は同じです。

Model Context Protocol はこれを仕様レベルで明示しています。Elicitation は、まさにサーバーが実行の途中で人間に質問するために存在します。そして現行リビジョン（2026-07-28）は、サーバーが「elicitation リクエストが常に成功すると仮定すべきではない」と警告し、拒否・キャンセル・クライアント側の失敗を扱うことを求めています（MCP 仕様）。プロトコルは「質問」を標準化しましたが、「人間の注意を引くこと」は標準化していませんし、できません。

そこにチャンスの全てがあります。エージェントスタックのどの層にもよく設計された一時停止がある。しかしどの層にも電話番号がない。

どのエージェントイベントが電話に値するのか

**二つだけです。それ以外は容赦なく切り捨ててください。**電話は希少な資源であり、「眠っている人間こそが本当にボトルネック」である場面にのみ使うべきです。

1. **承認なしには先へ進めないブロック。**エージェントはアイドル、時計は進み、待っても解決しません。これが典型例です。
2. **長時間の無人実行が最終的に失敗したとき。**6 時間のマイグレーションが 2 時間目で死んだなら、その 4 時間は戻ってきません。2 時間目に知りたいはずです。

それ以外はもっと静かなチャネルに送ります。「タスクが正常終了しました」は通常プッシュ。「エージェントが予算の 80% を使いました」はせいぜい時間指定通知。「エージェントを開始しました」は通知ですらありません。Echobell の 3 つの通知タイプ——通常・時間指定・通話——はまさにこの仕分けのためにあり、エージェントのイベントをそこへ割り当てることが最も重要な設計判断になります。すでに通知量と戦っているなら、鳴るチャネルを追加する前にアラート疲れの解消を読んでください。

エージェントの承認ゲートを電話につなぐ手順

Echobell は Webhook やメールを電話に変えます。家族からの着信のように iOS の集中モードやおやすみモードを突き抜けて鳴り、振動する本物の通話です（iOS 集中モードの突破）。停止するエージェントと、それを再開できる人間の間に立ちます。

ステップ 1 —— ブロックされたエージェント専用の通話チャネルを作る

アプリでチャネルを作成し、通知タイプを**通話（Calling）**に設定します。「エージェント停止 —— 承認が必要」のように誤解しようのない名前を付け、他の用途には一切使わないこと。チャネル詳細から Webhook URL をコピーします。形式は https://hook.echobell.one/t/<channel-token> です。これは秘密情報として扱ってください——手に入れた人は誰でもあなたのスマホを鳴らせます（Webhook ガイド）。

タイトルと本文のテンプレートは、ロック画面のまま行動できる内容にします。

Title: エージェント停止: {{agent}}
Body: {{project}} で {{action}} を待機中 —— {{time}} UTC から

{{time}} をはじめとするシステム時刻変数は、送らなくても常に UTC で利用できます。

ステップ 2 —— 承認分岐から Webhook を送る

中断を返す SDK であれば、この一時停止はコード上のごく普通の分岐です。実行を退避させる前にチャネル URL へ POST します。

let result = await run(agent, input, { stream: false });

if (result.interruptions?.length) {
  await fetch(process.env.ECHOBELL_BLOCKED_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      agent: agent.name,
      action: result.interruptions[0].rawItem.name,
      project: process.env.PROJECT_NAME,
      externalLink: `https://ops.example.com/runs/${runId}`,
    }),
  });
  await saveState(runId, result.state); // シリアライズして承認後に再開
}

externalLink という特別な変数は通知レコード内でクリック可能なリンクになるので、電話に出た人は探し回らずにその実行へ直行できます。

ステップ 3 —— エージェントがライブラリではなく CLI のときはフックを使う

Claude Code は Notification フックを提供しており、その matcher は通知タイプで絞り込めます。値には agent_needs_input や agent_completed が含まれ、フックハンドラはシェルコマンドでも直接の HTTP POST でも構いません（フックのリファレンス）。command ハンドラならペイロードの形を自分で決められます。Echobell は送った JSON のキーをそのままレンダリングするので、これは重要です。

{
  "hooks": {
    "Notification": [
      {
        "matcher": "agent_needs_input",
        "hooks": [
          {
            "type": "command",
            "command": "jq -c '{agent: \"claude-code\", action: .message, project: .cwd}' | curl -sS -X POST -H 'Content-Type: application/json' -d @- \"$ECHOBELL_BLOCKED_URL\""
          }
        ]
      }
    ]
  }
}

command ハンドラの場合、フックの入力は stdin から JSON で渡され、session_id、cwd、hook_event_name、permission_mode などのフィールドを含みます。http ハンドラは同じ JSON をスクリプトなしでそのまま URL へ POST できて魅力的ですが、レスポンスがフック出力ドキュメントであることを期待します。Echobell のレスポンスはそれではありません。自分の環境で http の挙動を確認していない限り、command を使ってください。

ステップ 4 —— メールしか送らないエージェントを拾う

エージェントプラットフォーム、定期実行サービス、社内ツールの多くはメールでしか報告しません。Echobell の各チャネルは専用のメールアドレスを持てるので、転送ルールひとつでそれらを電話に変えられます（メールトリガー、メールから電話への設定）。メールトリガーでは from、to、subject、text、html がテンプレート変数として自動的に使えるため、自前のパース処理なしに件名で条件を組めます。

ステップ 5 —— 条件を付けて本物のブロックだけを鳴らす

あらゆるエージェントイベントで鳴るチャネルは、もはや電話ではなく背景ノイズです。 Echobell の条件はテンプレートと同じ式構文で変数値を絞り込めます。たとえば次のように書けます。

blocking == true && risk == "high"

その基準に満たないものは別の時間指定チャネルへ送ります。目安として、通話チャネルが鳴るのは多くても週に数回であるべきです。それより頻繁に鳴るなら、エージェントの自律境界の引き方が間違っており、通知設定では直せません。

ステップ 6 —— おやすみモードをオンにしてテストする

実際に受け取るスマホでおやすみモードを有効にしたまま、curl でチャネルを叩いてください。

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{"agent":"test","action":"deploy to prod","project":"demo","blocking":true,"risk":"high"}'

アプリで失敗した通話を再試行を有効にしておくと、集中モードにブロックされた通話がもう一度試されます。テストされていないエスカレーション経路は、ただの思い込みです。

これは音の大きいアラート疲れを作り直すだけでは？

**ステップ 5 を飛ばせば、その通りになります。**この失敗モードは実在するので、はっきり名指ししておきます。エージェントはサーバーよりはるかに多くのイベントを生みます——ツール呼び出しごと、チェックポイントごと、リトライごと——それを全部どこか目立つ場所へ流したくなる誘惑は強いものです。

有効な規律はこうです。電話は「人間が眠っていることだけがエージェントの前進を妨げている」イベントに限る。これは「エージェントがやった重要なこと」よりずっと小さい集合です。電話に出た人がその後 90 秒で何をするのかを一文で説明できないなら、それは電話に値しません。

基準を高く保つべき理由はセキュリティ側にもあります。同じ CSA 調査では、組織が主要なガバナンスシグナルとして操作リスク（63%）と人間による承認（53%）を挙げています。しかし人間による承認が実際に速やかに行われて初めて、これらのシグナルは意味を持ちます。いつも 8 時間遅れで応答される承認ゲートは、ゲートを広げる方向へ全員を訓練してしまう——完全自律 13% が、誤った理由で静かにデフォルトになる道筋です。

Echobell がやらないこと

エージェント基盤の分野は誇大表現を招きやすいので、ここは正確に書きます。

Echobell がやること： Webhook やメールを、鳴る通話・時間指定アラート・通常プッシュに変える。条件で絞り込む。テンプレートで文脈を描画する。共有チームチャネルへ同じトリガーを配信し、購読者ごとに緊急度を選ばせる。

Echobell がやらないこと：

• **承認そのもの。**承認 UI ではなく、エージェントの状態とも接続していません。スマホを鳴らすだけで、承認や拒否にはノートパソコン・ダッシュボード・ターミナルを開く必要があります。「1 を押して承認」はありません。
• **実行の再開。**エージェント状態のシリアライズと復元はフレームワークの仕事です。Echobell は一切触りません。
• エスカレーションポリシー、確認応答、オンコールローテーション。「5 分応答がなければ次の人に架電」という機能はありません。チャネルの購読者を呼び出すだけです。シフト管理と確認応答の追跡が必要なら、インシデント管理プラットフォームが必要です——その種のツールは Opsgenie 代替の比較を参照してください。
• **エージェントのセキュリティ確保。**シャドーエージェント、広すぎるツール権限、CSA レポートが指摘する廃止プロセスの欠如——ここで扱っている内容はそのどれも解決しません。人間が速く気づくことは「対応の遅さ」への緩和策であって、「設計の悪さ」への緩和策ではありません。
• **配信の保証。**通話はプッシュ基盤・ネットワーク・充電されたスマホに依存します。待ち時間を大きく縮める層として扱い、絶対的に依存できる制御とは考えないでください。

正直な言い方をすれば、どのアプリがスマホを鳴らそうと、エージェントの自律境界は変わりません。通話が変えるのは、エージェントが止まってから人間が気づくまでの時間です——夜通しの実行では、その時間こそが夜通し走らせる価値そのものです。

FAQ

電話に出たまま承認できますか？

できません。Echobell は通知内容とクリック可能なリンクを伴う通話を届けるだけで、エージェントへ戻る対話経路は持ちません。現実的なパターンは、通話で目を覚まし、externalLink から実行ダッシュボードや承認エンドポイントへ移動して、そこで判断する、というものです。返信で承認したいなら、そのエンドポイントは自分で作る必要があります。Echobell が担うのは「起こす」側だけです。

フレームワークのどのイベントで Webhook を叩くべきですか？

実行が継続できないイベントです。OpenAI Agents SDK なら空でない interruptions 配列。MCP なら、クライアントが自律的に答えられない elicitation/create リクエスト。Claude Code なら agent_needs_input matcher を付けた Notification フック。完了イベントは通話ではなく、通常または時間指定チャネルに置きます。

CI 上のヘッドレスエージェントでも使えますか？

使えますし、そこが最も効きます。ターミナルを見ている人が誰もいないからです。curl を実行できる CI ステップなら、どれでもチャネルを起動できます。すべてのジョブではなく、長いジョブの失敗分岐でのみ送ってください。さもないとパイプラインが手持ちで一番うるさいものになります。

MCP の elicitation は具体的にどう扱えばよいですか？

Elicitation はユーザーが同席しているクライアントがプロンプトを描画する前提で設計されています。無人実行では描画する相手がおらず、仕様もサーバーに対して「応答があると仮定せず、拒否とキャンセルを扱え」と明示しています。合理的なパターンは、MCP クライアントのラッパーが自律的に答えられない elicitation リクエストを受け取ったときに Echobell の Webhook を叩き、自分のポリシーに従って保留またはキャンセルする、というものです。

エージェントの出力を通知に載せても安全ですか？

できるだけ載せないでください。エージェントの実際の出力より、識別子とリンクを優先します——externalLink で、それを保持するために作られたシステム上の実行レコードを指しましょう。Echobell は通知内容と履歴を端末のみに保存し、サーバーにはアカウント・チャネル・購読関係だけを置きます（プライバシーモデル）。データ最小化には有利ですが、必要以上に送ってよい理由にはなりません。

チーム全員が同じエージェントアラートを受け取れますか？

はい。チャネルを共有すれば購読者全員がトリガーを受け取り、それぞれが通知タイプを選べます。よくある構成は、そのエージェントを担当するエンジニアが通話、ほかのメンバーは時間指定、というものです。

iOS 専用ですか？

いいえ。Echobell は iOS と、Google Play 経由の Android で利用できます（Android 版リリース）。通話型アラートの挙動はプラットフォームによって異なるため、オンコール担当者が実際に持ち歩く端末でテストしてください。

WebhookMCP の構成と何が違いますか？

WebhookMCP は、タスク完了時にモデル自身が呼び出せるツールを与えます。便利ですが、エージェントが「通知しよう」と判断することに依存します。本記事の方法は自分のコードやフレームワークのフックから発火するため、エージェントが止まっていても、混乱していても、クラッシュしていても機能します。両方使いましょう——一方は「完了」、もう一方は「停止」のために。

---

関連記事

• WebhookMCP で AI タスクの完了通知を受け取る
• 重要アラートで iOS 集中モードを突破する方法
• アラート疲れを解消する開発者向けガイド
• cron ジョブ失敗アラート
• Webhook 連携ガイド
• 条件ガイド