GitHub、信頼できる multi-agent system には schema・action・MCP が必要と提言

GitHubは2026年3月9日のXスレッドで、multi-agent system がなぜ失敗するのか、そして何がそれをより信頼できるものにするのかを説明したガイドを再び紹介した。リンク先の記事自体は2026年2月24日に公開されたものだが、主張は十分に新しい。GitHubは失敗の多くが model の能力不足ではなく structure の不足から生まれるとし、agent workflow を chat interface ではなく interface、contract、validation boundary を持つ distributed system として扱うべきだと述べている。

最初のパターンは typed schema だ。GitHubによれば、agent 同士が曖昧な自然言語や揺れた JSON をやり取りし始めると、field 名が変わり、type がずれ、下流の step が検証ではなく推測で動くようになる。出力を machine-checkable な data に強制すれば、不正な output を早い段階で止められ、問題を曖昧な prompt 挙動ではなく具体的な contract violation として切り分けられるという。

次のパターンは action schema だ。data shape が正しくても、intent が曖昧なら workflow は依然として壊れやすい。たとえば「この issue を分析して次の action を助けてほしい」という指示は、ある agent には close、別の agent には assign、さらに別の agent には何もしないという結果を返させるかもしれない。GitHubはその曖昧さを減らすため、許可された outcome を小さく明示し、agent に必ずひとつの valid action を返させるべきだとしている。

三つ目のパターンは enforcement で、GitHubはこれを Model Context Protocol、つまり MCP と結びつける。記事では MCP を、tool input と output を実行前に検証する execution layer と説明している。schema や allowed action があっても、runtime がそれを一貫して強制しなければ単なる convention に過ぎない。production service に state が到達する前に厳密な boundary を置くことが、信頼できる agent system には必要だという整理だ。

全体としてのメッセージは、GitHubが agent orchestration を software engineering の discipline に引き戻そうとしている点にある。model に「慎重に動け」と頼むのではなく、typed interface、constrained action、validated tool call を既定の設計原則にせよという提案だ。Copilot extension、内部 automation、MCP 互換の agent pipeline を作るチームにとっては、議論の中心を prompt の工夫から system design へ移す重要な示唆になる。