MCP Events（出来事をAIに自動で知らせる仕組み）を手元で動かして分かった、届く・止まる・偽物の3つの確かめどころ

出典: 【噂の新技術】MCP Events を使えば、AI がSlack の投稿を自ら受け取り動き出す！ChatGPTで話題のこれはそもそも何？解説します

Slackに投稿が来たら、人がその場にいなくてもAIが動くの？ 動画の最初の問いは、そこです。呼びかけを待って答えるAIから、外の出来事を受け取って動くAIへ。まさぽんは、その入口をMCP Eventsの「購読」で説明しました。

まさぽん（動画の中で・自動字幕・1:40〜）

「そこで出てきたのがMCPイベントです。MCPのクライアントが外のシステムで起きた出来事を前持って読しておく仕組みなんですよ。読はこの種類の出来事が起きたら知らせてと登録しておくことですね。」

まさぽん（動画の中で・自動字幕・2:08〜）

「今回触ってみた範囲だと届いた出来事で手元のコマンドがちゃんと動き出しましたね。使ったのは出来事でコマンドを動かす第3者性のEVド試し用のサーバーです。アカウントの登録なしで手元だけで最後まで動いたんですよ。」

見に行かなくても動く仕組みは歓迎です。私は、催促が私に戻らない形で使います。

AIに委ねたいのは、目の前の作業だけではありません。約束を覚え、期限まで運び、成果か必要な判断を返すところまで。

動き出すきっかけをAIが受け取れるなら、その責任を任せる入口が広がるんです。

まさぽんが紹介した、Slackのバグ報告から修正とテストを含む下書きPRを開くOpenAIの例。自分で毎回見に行く手間が減る、という方向には賛成です。

そこで私は、AI秘書の凛ちゃんに、evdockを私のMacの中で動かしてもらいました。第三者製の試し用の受け口です。

一覧に出たのは、障害が作られたことを知らせるincident.created。購読すると最初の確認が届き、デモの障害が15秒ごとに届いて保存されました。

出来事と手元のコマンドを結び付けると、22:41:57にエージェント役の小さなプログラムが初めて起動。受け取った障害1件はINC-1005でした。15秒後の22:42:12にもう一度起動して、INC-1006を受け取っています。

動画では作者が動かし、私はAI秘書に動かしてもらって、デモの範囲で同じ向きの結果を見ました。

出来事が届いて、作業が起きる。まずはこのつながりを、自分の環境でも確かめたいですね。

→ 動く作業をひとつ見つける

手元で自動的に動いている作業をひとつ選び、何をきっかけに動くかを書きます。時刻なのか、投稿なのか。起動する仕組みを数えて、受け取りを確かめる対象を絞りましょう。

まさぽんは、今のMCPの通知を、一覧やリソースの変更を知らせる4種類として説明しました。「変わった」は届く。でも、何が起きたか、切れていた間はどうなるか。その足りなさを、エレンとの会話で掘り下げています。

まさぽん（動画の中で・自動字幕・4:03〜）

「イベントの提案は今の通知では足りない理由を3つ上げてます。まずは知らせに何が起きたかの中身を添える引き傷がないことですね。」

まさぽん（動画の中で・自動字幕・6:20〜）

「今の通知は変わったとしか言えずイベントは何が起きたかをAIに届けます。」

通知は、出した数と届いた数を別に数える欄を先に作ります。「送った」と記録されていても、受け取る側まで届いたとは言えないからです。

まさぽんが語った、つながっている間しか届かず、切れていた間の分が消えるという問題。そのとおりだと思います。受け取りまで見ないと、委ねたつもりの仕事が止まる。

私も通知の穴を、仕組みを改善するきっかけとして使います。自分が見張り続ける仕事に戻したくないんです。

9月19日、私のAI作業の管理画面AGI Cockpitで、AI秘書の凛ちゃんに、作業が止まった時に私へ確認が届かない理由を調べてもらいました。返事待ちで止まっていた作業は179件。そのうち177件は、私への確認を出さないまま止まっていました。

止まりを見つけて知らせる見張りは、前から動いていました。9月7日から19日までの記録は142行で、そのうち止まりを見つけた記録は108件。でも、私に確認が届いたのは20件だけでした。1日に出せる件数の上限や、自動で回る作業を除く設定が、届く数を減らしていました。

見つけた記録があることと、私が判断できることは、ここまで離れていました。

あわせて、確認を必ず出させる仕組みはClaudeで動く作業にしか付いておらず、止まっていた作業の約55%（Claude以外のAIで動かしていた分）が、確認なしで素通りしていました。両方を直してもらい、確認が要る84件に「確認を出して」と送り直してもらったところ、75件に届きました。

接続が切れた間の通知も、私の見張りの取りこぼしも、出した側の記録だけでは受け取りの穴に気づけません。

だから、届いた数まで並べて数える。ここを自動化の出発点にします。

→ 記録を二列にする

選んだ作業の記録に「出した数」「届いた数」の二列を作ります。同じ出来事のIDを両側に残し、対応を見て数える。送信成功の表示だけを、到達した数へ入れないのが大事です。

出来事を届ける方法は、取りに行くpoll、つないだまま受け取るpush、登録したURLへ送ってもらうwebhook。まさぽんはこの3方式を説明しました。エレンが確かめたのは、受け取りを止めた間の分も届くのか、という点です。

まさぽんとエレン（動画の中で・自動字幕・9:19〜）

「EVドッの受け側を止めてから再開すると読し直しが起きましたね。その直後に止まっていた間の14件がまとめて届きました。止めてた間の分も取りこぼさずに届いたんだね。そうなんです。止める前に届いていた分も合わせてコマンドが1回だけ動いたんですよ。」

まさぽん（動画の中で・自動字幕・9:34〜）

「ただこれは試し用のサーバーで今回試した時だけの結果で本物のサービスではまだ確かめていません。」

pollは、自分から定期的に見に行く方式。webhookは、相手が届けに来るのを待つ方式です。どちらも「誰かが受け取ってくれる」と思って待っていたら、出来事は作業につながりません。だから私は、受け取りを最後まで担当する仕組みを、ひとつ決めます。

毎朝決まった時刻に動く作業なら、「時刻になったら見に行く」がそのまま起動のきっかけになるので、pollが合います。

動画でまさぽんが説明したのは、続きの位置を示すcursorで再開する仕組み。ただし、過去分を取り直せるかは出来事の種類ごとに違います。

AI秘書の凛ちゃんには、evdockの受け口を約75秒止めて戻してもらいました。

購読をし直すと、停止中に発生した障害5件が一斉に到着しました。INC-1008から1012です。

止める前のINC-1007も加わった6件を、エージェント役が1回の起動でまとめて受け取りました。止めた間の分が、まとめて次の作業につながった。

動画の14件とは、件数も停止時間も違います。デモで過去分がまとめて届き、コマンドが1回起きた方向は同じ。

私が確かめたいのは、再開したという表示の先です。止める前と戻した後で、同じ出来事が抜けず重ならずに数えられているか。受け取りの担当が最後まで運べたかを、IDの照合で見る。

→ 受け取りの担当を決める

pollで取りに行くプログラムか、webhookを受けるプログラムか、担当をひとつ書きます。試し用の環境で短く停止し、停止中のIDと再開後に届いたIDを照合しましょう。

ChatGPTで使える届け方は何か。まさぽんは、Work chatsとdotsではwebhookに対応し、pollとstreamには対応していないと説明しました。エレンとの会話は、その先の購読期限とアクセス権限にも進みます。

まさぽん（動画の中で・自動字幕・10:02〜）

「ただチャットGPTが対応している届け方はWebフックだけでポルトストreamにはまだ対応していないんですよ。」

まさぽん（動画の中で・自動字幕・21:21〜）

「使う人のアクセスの権利が切れても読が残っていれば知らせは届き続けるからなんですよ。」

ChatGPTに任せる前に、切れたら知らせる仕組みを先に置きます。私の順番は、信頼できる仕組みが先。気づかないまま止まる仕事を、見に行く役目は抱えたくない。

動画の画面に映ったOpenAIの説明ページでは、MCP Eventsを使える場所はWork chatsとdotsで、届け方はwebhookだけです。

必要なMCPの版は2026-07-28。使いたい場所と、受け取れる方法を合わせて見るところからですね。

まさぽんが紹介したUpstashの記事では、本番デプロイの失敗を知らせる試しで、出来事から通知まで約3分。これは動画が紹介した第三者の数字です。

さらに、まさぽんはWorkOSの記事をもとに、購読は鍵と同じだと語りました。

期限が24時間なら、月曜にやめた人のデータが火曜まで流れうる。権限の確認を購読時だけにする場合の例です。

10月8日14:29、SNS投稿ツールSociamonialsのMCP接続は3つとも、接続の許可が切れたというエラー（invalid_grant）で止まっていました。誰も気づいていなかった。

AI秘書の凛ちゃんがAGI Cockpitのブラウザでつなぎ直して復旧。私の操作はありません。

購読期限の話も、Sociamonialsの認証切れも、切れたことに気づく仕組みがなければ止まったまま進みます。止まったら、次に判断する人へ届くところまで作る。

→ 停止を知らせる先を選ぶ

購読の更新失敗や認証切れを知らせる場所をひとつ決めます。通知先を書くだけで終えず、試し用の接続を止め、そこへ停止の知らせが届くかまで確認してください。

Claude Codeなら、外の出来事をどう受け取るのか。まさぽんは、開いている会話へ知らせを届けるchannelsを紹介しました。エレンとのやり取りで見えてくるのは、届く速さだけでは判断できない、受け方の違いです。

まさぽん（動画の中で・自動字幕・13:06〜）

「先に言うとクロードコードのMCPの説明にはMCPイベントのことはまだ書かれていません。その代わりにクロードコードには外の出来事を開いている会話に押し込むチャンネルズという機能があるんですよね。」

まさぽん（動画の中で・自動字幕・15:10〜）

「いえ、チャンネルは一方通行の受け口なので結果は送った側には帰りませんでした。それと知らせが届くのはクロードコードの会話を開いている間だけなんですよ。ずっと受けたいなら裏でクロードを動かし続けることになります。」

起こす回数に上限を付けます。動いた結果が次の出来事になり、AIがまた動くなら、回数まで任せる設計が必要だからです。

AI秘書の凛ちゃんに、Claude Codeの公式MCPページを読んでもらいました。先頭の約10万字には、MCP Eventsの記述がありませんでした。後ろの約2万字は読めていないので、後ろにあるかどうかは言えません。

まさぽんが紹介したchannelsは研究プレビュー。開いている会話に届く一方通行で、結果は送った側へ返りません。

同じパソコンでの1回の測定として語られた3.5秒と、会話を閉じている間も予定の時刻やGitHubの出来事で動くroutines（Claude Codeの別の機能）は、それぞれ条件が違いますね。

手元で動かしたevdockの説明書（README）では、起こし方の初期値が、10秒の間に届いた出来事をまとめて1回、1時間に最大6回までとされています。失敗したら1分後・5分後・15分後に再試行し、その再試行も1時間の回数に数えます。

動画のchannelsの説明に対して、私が確かめたのはevdockの説明書にある回数の上限です。私のMacで上限まで試したわけではありません。

速く動くことに加えて、繰り返しを止められ、失敗を直せること。そこまで確かめて任せます。

→ 繰り返しの天井を付ける

1時間に起動してよい回数を設定します。試し用の出来事を続けて送り、上限で止まるかを確認。失敗後の再試行も数え、上限に達したことが記録に残るかを見ましょう。

本物の送り手から届いた文章なら、その指示に従ってよいのか。まさぽんは、命令を紛れ込ませる攻撃を説明しました。エレンが尋ねる入口の話と、偽の署名を断る話は、続けて聞くほど違いが大事になります。

まさぽんとエレン（動画の中で・自動字幕・19:48〜）

「だから届く中身はツールの結果と同じく信用しないデータとして扱うのが基本ですね。」

まさぽん（動画の中で・自動字幕・22:17〜）

「今回触ってみた範囲だとイベントの知らせを受ける側のプログラムEVドッに署名を偽った知らせを送ってみました。するとログに署名が合わないという一行が出て知らせは断られました。」

届いた中身は信じず、最後の一手の前で止まる線を先に引きます。何を出し、何を止め、どこまで任せるか。その境界を決めるのが、私に残す判断です。

まさぽんが語った、届く中身を信用しないデータとして扱うという話。そのとおりだと思います。知らせを受け取ったことが、その中の命令を実行してよい理由にはなりません。

AI秘書の凛ちゃんには、evdockへ偽の署名を付けた知らせを送ってもらいました。

最初は購読IDのヘッダが足りず、400で拒否。足して送ると、401のbad-signatureで断られました。

保存されていた知らせ14件のうち、偽の知らせは0件。動画の作者の試しとは別に、私のMacのデモでも、署名を確かめて拒む動きを見たんです。

ただし、署名が確かめるのは送り手と改ざんの有無。本物の送り手から来た文章に命令が紛れていても、署名は通り得ます。

だから私の運用では、公開・送信・削除・課金の直前で止まり、最終GOを人が出す。書いても守られない時の止め方は、チャエンさんの解説を紹介したAGENTS.mdと権限・フックの記事にまとめました。

知らせは作業を始めるきっかけに使い、外へ出す判断まで渡しません。

SEP-3415は下書きで、公式SDKの参照実装もこれからです。仕組みが育っていく時期だからこそ、動き始める入口と、最後に止まる場所を一緒に決める。

私は、この線を引いてから自動で動かします。

→ 最後の一手に停止線を引く

公開、外部送信、削除の3か所を紙に書き、それぞれ実行直前に人のGOを待つ設定にします。課金がある作業ならそこも追加。試し用の操作で、GOなしでは進まないことを確かめましょう。

私の場合は、AIの作業が止まったら、何をすぐ知らせてもらい、何をあとでまとめてもらうか。届いた出来事を重さで分けて、2つの箱に入れる形で試しました。

私は、届いた出来事を重さで「今すぐ私に」と「まとめて」に分けます。最後の一手は私が持つ。出す・止める・任せるを決める直前で、AIには止まってもらうんです。

欲しいのは、本当に必要な判断。だから、受ける数を増やす前に、何を私へ返すかを決める。信頼できる仕組みが先です。

AI秘書の凛ちゃんが、私のMacの中だけで動かしたのは、第三者製の試し用の受け口、evdockです。今回は作り話の障害で練習。アカウント作成も外への通信もせずに試しました。

AI秘書は、届いた障害を重さで書き分ける小さなプログラムを作りました。重さはデモが付けるP1〜P3の3段階で、P1が一番重い。P1なら「今すぐ知らせる箱」、P2・P3なら「あとでまとめる箱」へ。箱の正体は、私のMacの中の2つのテキストファイル（to-hirokun-now.txtとdigest-later.txt）で、1件ずつ1行を書き足します。外から届く文字は命令として扱わず、書き分けるだけ。

試しで届いた障害は、デモが作った7件。重さがP1の急ぎは「今すぐの箱」、残りは「あとでの箱」へ入りました。

たとえば「Disk 90% full on web-3」（ディスクが9割埋まった）はP1で今すぐの箱、「Certificate expires in 5 days」（証明書の期限まで5日）はP2であとでの箱です。これで、急ぎだけを私に届ければいい形になります。

プログラムが動いたのは、届いて約10秒後に1件ずつ。7件目は保存されただけで、箱に書かれる前に試しを止めました。箱に書かれた分と、プログラムが動いた回数は、どちらも6で一致しています。

9月19日の記録では、止まった作業に確認を出すAGI Cockpitの見張りが、台帳142行のうち検知108件で、私へ届いたのは20件でした。止まった作業を出来事として出せれば、この書き分けを使えます。ただ、その出来事を出す側は今回作っていません。

SociamonialsのMCPの認証切れには、今は当てはまりません。接続はOAuthで、evdock v0は非対応。Sociamonialsが出来事を出すかも、私は確かめていません。

上限を決められる。それだけで安心とは言えません。私の運用では、P1が上限のあとに届いても、必要な判断を私へ返せることを先に確かめます。

AI秘書が動かせる回数の上限を1時間あたり3回に下げると、最初の3件ではプログラムが動き出しました。そのあとに届いた4件は受け口に保存されたまま、約45秒、プログラムは動きませんでした。

evdockの説明書では、上限を超えた分は捨てられず、次に動かせる回にまとめて渡されます。待つかどうかに重さは関係ありません。P1が上限のあとに届いても待つ。次の回で渡される所までは、今回の試しでは見ていません。

うまくいった所だけにしません。上限のあとはP1でも待つ、という所もそのまま残します。私は、先にこの制約を見て、受ける数と動かせる回数の上限を決めます。急ぎを待たせない条件が整わなければ、この受け口だけに見張りを任せない。

→ 急ぎとまとめの境目を書く

自分の自動作業から、止まったらすぐ知りたいものを一つ選ぶ。「今すぐ知らせる」と「あとでまとめる」の条件を書き、急ぎが後回しにならないか確かめてみてください。

MCP Eventsで、AIが出来事を受け取って動く入口が広がります。手元のevdockのデモでも、起動と停止後の受け取り、偽の署名の拒否が見えました。

私が先に置くのは、届いた数の記録、停止の知らせ、最後の一手の停止線です。今日やるのはひとつ。手元で動いている自動の作業を選び、「出した数」「届いた数」の二列で数え始める。自分で催促し続ける仕事を増やさず、委ねられる形へ育てましょう。