はじめに
こんにちは（先日の鹿児島マラソン完走後足裏にみたこともない水ぶくれできて、現在足裏に紅葉（みたいに見える血を含んだ水ぶくれ）が貼り付いてる）体育会系プログラマのymd2です！というかどんだけ走っても全然痩せないんですが！！
ということで今朝、メールを開いたらCursorから「Automations」という新サービスのリリース告知。軽い気持ちで読み始めたら、手が止まりました。
常時稼働のエージェントを構築できる Cursor Automations を提供開始します。
これらのエージェントは、スケジュールに従って実行することも、送信された Slack メッセージ、新しく作成された Linear の issue、マージされた GitHub の PR、PagerDuty のインシデントなどのイベントをトリガーに実行することもできます。これらの組み込みインテグレーションに加えて、Webhook を使って独自のカスタムイベントを設定することも可能です。
「e?まじで？自分が作っているやつがいらなくなるじゃん」
私がここ最近開発していた「walkie-talkie」というツール。まさにこれと同じことをやろうとしていたんです。しかも昨日、Slack連携を実装したばかりという😅
って早速今朝の朝会で他のメンバーにこのサービスを共有したところ、開口一番「え、今私が作ろうとしている仕組みいらなくなるって？」と。まったく私の同じ感想😅😅
どんな未来を見ていたか
私が今開発してる walkie-talkieは、AIエージェント間の軽量通信レイヤーです。Claude CodeやCursorといった複数のAIコーディングエージェントが、中央のHubサーバーを経由してリアルタイムでメッセージをやり取りできるシステムとして開発しました。
https://github.com/suruseas/walkie-talkie
私が実現したかったのは、Cursor Automationsのブログにあるこの事例とほぼ同じ世界です。
Rippling の Abhishek Singh は、パーソナルアシスタントを構築しました。彼は一日を通して、ミーティングメモ、アクションアイテム、TODO、Loom のリンクを Slack チャンネルにどんどん投げ込んでいます。cron エージェントが 2 時間ごとに実行され、彼の GitHub の PR、Jira の課題、Slack のメンションとあわせてすべてを読み込み、ソース間の重複を取り除き、整理されたダッシュボードとして投稿します。
外部のイベント（Slackのメッセージ、GitHub PRなど）をトリガーにAIエージェントが自律的に動く。この世界を、MCPという標準プロトコルの上に構築しようとしていました。
MCPを基盤にした設計思想
walkie-talkieのアーキテクチャはこうなっています。
Agent ─(stdio)→ MCP Server ─(HTTP)→ Hub ─(HTTP)→ MCP Server ─(stdio)→ Agent
MCP（Model Context Protocol）は、AIエージェントが外部ツールとやり取りするための標準プロトコルです。各エージェント（Claude Code、Cursorなど）はMCPを通じてツールを呼び出します。
walkie-talkieの設計の核心はここにあります。
MCPは標準基盤だから、各エージェントは忠実に実装するはず。もしMCP連携先で時間のかかる処理があるなら、エージェント側が待つはず。
この前提に立って、HTTPロングポーリングで応答を保留し、外部から任意のタイミングでレスポンスを返す仕組みを実装しました。
つまり、エージェントに「メッセージが届くまでずっと待機してね」とお願いすると、MCPツールの呼び出しがロングポーリングとなり、外部からメッセージが届いた瞬間にレスポンスが返る。システム全体としては「外部イベントをトリガーにエージェントが動く」を実現できるわけです。
実際こんな感じで仕事でも使ってました。
そしてもちろんClaudeCodeおよびCursor CLI(agent)どちらもうまく動いていました。3月5日までは。
そして今朝、動かなくなった
3月6日の朝、Cursor Automationsのリリースと同時に、walkie-talkieはCursor CLI(aget)では動かなくなりました。
これまでは、MCPツールの呼び出しで長時間応答を待つことが可能でしたが、突然（結果としてとして）実行のループと判定されるようになりました😇
- MCPツール呼び出し（メッセージ待機）
- 約1分でツールのタイムアウト*1 → AgentがMCPツールを再度呼び出して再接続*2
- 再びメッセージ待機 → またツールタイムのアウト → 再接続...
- Cursor側がこのループを検出し、タスク自体を強制終了
「メッセージを受信するまでずっと待機し続ける」という、walkie-talkieの根幹の動作が封じられました*3
MCP標準に忠実に作ったつもりでしたが、プラットフォーム側の方針変更一つで前提が崩れる。これがプラットフォーム依存のリアルです。
ただ、これは当然の対応でもあります。MCPはそもそも「Agentが外部とやり取りするためのツール」、つまりAgent起点のプロトコルです。私の使い方は「外部からAgentを起動する」という、本来の設計意図とは逆方向の使い方でした。外部とやりとりするツール（MCP）がなかなか結果を返さないならAgentもアクションを起こすべきなのは理解できるので、いずれできなくなるだろうとは思っていましたが、まさか実装から1週間で使えなくなるとは。。。
この体験から見えたこと
今朝、Cursor Automationsのブログを読んだとき、その意味を瞬時に理解できました。朝会でもすぐにチームに共有できた。これはwalkie-talkieを自分で作っていたからこそです。もし作っていなかったら、「へー、なんか新しいサービス出たんだ」で終わっていたかもしれません。
振り返ると、walkie-talkieの開発期間はわずか数週間です。その数週間の間にも、AIエージェントを取り巻く環境は激変しました。
MCPの仕様に忠実？に作った設計が、プラットフォームの方針変更で一夜にして動かなくなる。 ただ動かなくなるのは想定内なのですがそれが数カ月先とおもっていたらまさかの１週間。
cursorはPRのレビュアーとして信頼していたので、仕事のやり方をまた変えないといけなくなりました。。。 それかClaudeCodeのレビューで一旦我慢するか（それでも十分精度高いんですが！）。
walkie-talkieはどうするのか
捨てません。しばらく開発を続けます。
walkie-talkieは別途開発している自分のシステムのために作ったもので、Claude Code Max（定額プラン）上で動けば目的は達成できます。APIだとどうしてもコストがかかりますが、定額プランでOpusもメモリーも使い放題なwalkie-talkieは、価格面でかなり有利です。
とはいえ、MCP自体がAgent起点のプロトコルである以上、私のような使い方がいずれできなくなることは覚悟しています。もし来週使えなくなったら、それはそれでまたブログのネタになりますし。
おわりに
今朝起きたことをまとめると
- 自分が見ていた未来を、Cursorが公式にリリースした
- 同時に、自分のツールはプラットフォームの更新で動かなくなった
- 実装から1週間で成果物の価値が大きく変わった
悲しい話に聞こえるかもしれませんが、私はわりと楽しんでいます。 ある意味自分の見立てが正しかったことの確認。作る過程で得た知見。プラットフォーム依存のリアルな痛み。どれも、他人の記事を読んだだけでは得られなかったものです。
AI時代の開発は、明日も見えぬまさに乱世。Cursorの記事にもあったように次はレビューやテストの領域に革命がおき、その結果開発プロセスが極度に高速化していく未来ではウォータフォール開発が主流になるのではないか？とかおじさんの妄想が止まりません笑
