ChatGPTがプロジェクトボードの監視に対応：イベント駆動型エージェントに次に求められるもの

9月29日に公開されたOpenAIのDevDay振り返り記事には、わかりやすい具体例が挙げられていました。「ChatGPTにプロジェクトボード上の新しいタスクを監視させることができます。タスクが作成されると、あなたが席を外していても、ChatGPTがリンクされたドキュメントを読み込んで計画案を作成してくれます」。この機能の基盤となっているのが、全プランで提供が開始されたMCP Events仕様（提案中）のChatGPTによるサポートです。これと同時に、スケジュールやイベントをトリガーに実行されるチームタスク、そしてSlackやTeams向けの@ChatGPTという2つのチーム向け機能もリリースされました。

すでにコーディングエージェントを運用しているチームにとって、エージェントが監視するタスクボードの存在は、「新規タスク」が持つ意味を大きく変えます。かつてタスクは人間が着手するのを待つだけのものでした。しかし今や、1つあるいは複数のエージェントを自動で起動するトリガーになり得ます。もし2人のメンバーが同じボードを監視するようChatGPTに依頼しており、さらにボード自体でも新規作業にエージェントを割り当てる設定になっていた場合、たった1つの新規タスクに対して3つの異なる場所で3つの計画案が作られてしまい、どれを採用すべきか誰も判断していないという事態が発生します。

要点まとめ

MCP Eventsにより、ChatGPTは連携先アプリの変更通知を署名検証されたクリーンな方式で受け取れるようになり、ChatGPTのチームタスクはBusinessおよびEnterpriseプランにスケジュール駆動型・イベント駆動型のワークフローをもたらしました。イベントを起点にエージェントを起動すること自体は「簡単な半分」であり、OpenAIはそこを抜かりなく実装しています。本当に「難しい半分」は、そのイベントによってボード上に何が生み出されるかです。具体的には、生成された作業の担当者は誰か、計画案はどこに出力されるか、誰がそれをレビューするのか、そして2つのエージェントが同一イベントに対して重複して対応するのをどう防ぐか、という点です。これをルーティングルールとして明文化しましょう。すなわち、「1つのイベントタイプに1人の担当者」「計画案はタスクへ集約」「何かが完了とみなされる前に人間が必ず承認する」というルールです。

DevDayで発表されたこと

MCP Eventsは、連携アプリ内でアクションが発生した際にMCPサーバーからChatGPTへ通知を送り、プラグインがそれに応じて自動化処理を開始できるようにするための、Model Context Protocolの提案拡張仕様です。OpenAIのMCP Eventsガイドでは、サーバー側の仕様が説明されています。サーバーはイベントサポートを通知し、events/list、events/subscribe、events/unsubscribeの3つのメソッドを実装します。ChatGPT側はWebhookによる配信のみをサポートしており、HTTPSによる認証チャレンジの後、Standard Webhooks HMACによって署名された最大256 KiBのリクエストとして1リクエストにつき1イベントが送信されます。ガイドの言葉を借りれば、イベントを受信した際、「ChatGPTは購読中のチャットでイベントを受け取り、応答方法に関するユーザーの指示に従う」とされています。

重要な部分の設計は極めて慎重になされています。サーバーは各イベントに対して、リトライをまたいでも変わらない一意のIDを付与しなければなりません。購読は冪等（べきとう）である必要があり、その識別情報はプリンシパル、コールバックURL、イベント名、および引数から導き出されるため、再購読した場合は重複作成されず既存の購読が更新されます。さらにサーバーは、プライベートIPやローカルのコールバックアドレスをブロックし、リダイレクトに従ってはなりません。

これらが組み合わさることで、ChatGPTは会話の外側から作業を開始できる場となります。これは大きな前進であり、日常的な定型作業の多くにはこれで十分でしょう。

トリガーは「簡単な半分」にすぎない

振り返り記事に書かれていた例を、実際のチーム開発に当てはめてみましょう。ボードに新しいタスクが作成されます。ChatGPTがリンクされたドキュメントを読み込み、計画案を作成します。その後に続くのは、通信プロトコルとは無関係の4つの疑問です。

生成された作業の担当者は誰になるのか？ 計画案はタスクの割り当てではありません。そこに書かれた作業の責任を持つ担当者が必要であり、大半のチームではタスクへの氏名の記載やステータスの更新によってボード上で担当者を管理します。どれほど優れた計画案であっても、作成されただけでこれらが勝手に更新されるわけではありません。

計画案はどこに出力されるのか？ イベントは購読を設定したチャットに届き、計画案はそのユーザーの指示に従った場所に送られます。チャットへの返答かもしれませんし、プラグインがボードへの書き込みに対応しており指示にも含まれていれば、ボード側へ書き戻されるかもしれません。チーム全体でその出力先を把握していなければ、誰も読まない場所にせっかくの計画案が放置され、ボード上では「新規」のまま残り続けることになります。

どうやってレビューするのか？ 計画とはスコープの決定そのものです。コードの実装を開始する前に、作成者以外の第三者が内容を確認し、次の担当者が見つけられる場所に残しておく必要があります。

誰がイベントに応答するのか？ 冪等性によって同一の購読が二重登録されることは防げますが、2人のユーザー間での調整まではできません。プリンシパル（実行者）が購読識別情報の一部に含まれるため、各ユーザーの購読は別物として扱われるからです。これに加えてボード側でタスクにAgentが割り当てられていると、同じタスクに対して複数回計画が立てられてしまう恐れがあります。Webhookレイヤーでの重複排除は、実際のワークフローレイヤーにおける担当者の決定までは担ってくれません。

これらはマネジメント上の課題です。3人のメンバーが同じチケットに同時に着手してしまうといった問題はエージェントが登場する前から存在していましたが、寝ることもないエージェントが相手になると、その問題はより急速に表面化します。席を外している間の無人作業におけるレビュー体制については、不在時のコーディングエージェントを参照してください。

ルーティングはボード側で管理する

エージェントを担当者として設定できるボードでは、「新規タスクを監視する」ことは実質的に「タスクを割り当てる」ことと同じです。Sharklyでは、Agentに割り当てられたTaskはBacklogから移動し、ComputerとRuntimeの準備が整った段階で実行を開始します。実行担当者の枠には正確に1つのAgentまたはCrewのみが割り当てられ、Sharklyが保留中の作業をまとめる（コアレスする）ため、連続してコメントが投稿されても同一のAgentやTaskに対して重複した実行待ちが生成されることはありません。担当者の決定は曖昧な暗黙の了解ではなく、データフィールドとして厳密に管理されます。

タスクの割り当てを行わずにイベントから作業を開始したい場合は、ボード側の仕組みであるSharkly Automationsを利用します。Automationは、「指示事項」「AgentまたはCrew」「1つ以上のトリガー」「実行履歴」で構成される単一のルールであり、ActiveまたはPausedのステータスを持ちます。トリガーとしては、スケジュール（タイムゾーン指定のcron）、指定ステータスへのTaskの移動、特定フレーズを含むコメント、外部サービスからのWebhook、およびテスト用の「Run now（今すぐ実行）」が用意されています。各実行は直接起動され、履歴はそのAutomation上に記録されるため、結果をどこに記録するかを指示文に明記しておく必要があります。現在、ステータスやコメントの一致判定は組織全体を対象としているため、Automationsのドキュメントではアクションを起こす前に対象のTaskを検証する指示を含めることを推奨しています。

以下は、あるSpaceにおけるイベントとタスクのマッピング例です。

そして、その背後にあるルールをチームが確認・議論できる形で記述したものがこちらです。

Routing rule: new work in the ENG Space

1. One event type, one owner. Each event maps to exactly one
   Automation or one Agent Assignee. Personal watchers (a chat
   subscription, a dot) may read the board; they do not plan on it.
2. New requests enter Triage. A person accepts before any Agent runs.
3. Accepted work that needs a plan moves to "Needs plan", a status in
   the Backlog category. The "Draft plan" Automation runs the Planner
   Agent, which first checks the Task's Space and type and stops if
   the Task is not ours.
4. The plan returns to the Task as a comment. The Planner does not
   change status and does not assign anyone.
5. The Task's human assignee reads the plan, assigns the executing
   Agent, and moves the Task to Todo. That move starts the run.
6. Done means a person accepted the result. No Agent moves a Task
   into a Completed status.

「Needs plan」をBacklogカテゴリーに配置している点が、ステップ5を安全に進めるためのポイントです。Backlogにある割り当て済みTaskは待機状態となるため、実行が始まる前に必ず計画案を確認できます。Plannerへの指示には計画案の出力先を明確に記述し、トリガーの本番運用前に「Run now」でテストを行ってください。エージェントが実行途中で人間の判断を必要とする場合、Taskには人間の返信待ちであることが表示され、担当者のInboxに届きます。ここで初めて、「席を外していても」のプロセスが人間に戻ってくることになります。タスクボードこそが、グループチャット上の依頼を追跡可能な作業へと変換する場所であり、これはGitHub issueをエージェントに割り当てる場合にも同様に当てはまります。

ChatGPTの監視機能はどこで活きるのか

自分専用のチャット内で速報とドラフト案を受け取りたい場合には、MCP Eventsの購読が適しています。自身が管理していない参照用のボード、パートナー企業の進捗トラッカー、自分向けの金曜まとめレポートなどがその典型です。一方で、ChatGPT上で完結するチームの定期報告など、繰り返し発生する作業であり、かつBusinessやEnterpriseプランを利用している場合は、チームタスクを活用するのが良いでしょう。メンバーが個別に指示を作成するのではなく、1つの指示セットを共同で改善していけるためです。そして、誰かが実行すべき計画、レビューが必要な修正、月曜の集計に反映すべきタスクなど、チーム全体で責任を持つべき作業がイベントによって生まれる場合は、ボード側のルールを活用してください。

イベント駆動型のAIエージェントが真価を発揮できるかどうかは、「どのアカウントが応答するか」を定めるルールの完成度にかかっています。イベントの送受信は単なる配管（トランスポート）にすぎません。ルーティング、担当者の割り当て、そしてレビュー体制こそが本質的なマネジメントであり、どのベンダーのツールを採用していようと、すべてのエージェントが報告を行う共通のボード上で一元管理されるべきです。キューが満杯になった際にエージェントが次に着手すべき作業の決定方法については、AIバックログ管理とトリアージを参照してください。OpenAIの振り返り記事の冒頭で発表されたDotsも、エージェント側の視点から全く同じ問題を提起しています。

すでに複数のエージェントを運用しているなら、Sharklyを使えばタスクと成果物を1か所で一元管理できます。

参考リソース

• Sharkly Automations：4つのトリガータイプ、実行履歴、そして自動化の適用限界
• グループチャットから追跡可能なコードタスクへ：メッセージを担当者のいる作業へ変換する
• AIバックログ管理とトリアージ：エージェントが次に着手すべき作業の優先順位付け
• GitHub issueをAIエージェントに割り当てる：issueからレビュー可能なプルリクエストまで
• 不在時のコーディングエージェント：無人実行とレビューキューの運用
• 解説：OpenAI Dots：常時稼働するパーソナルエージェントと、チーム運用に不足している要素