7月30日、InfoWorldが「Shipping an MCP test agent: The boring parts nobody demos」と題した記事を公開した。MCPテストエージェントを本番環境に載せる際に、デモでは決して紹介されない「地味だが重要な実装上の落とし穴」について詳しく論じた内容だ。
誰もデモしない「91チケット事件」
記事の著者がプロジェクト開始から約6週間後、自動化ユーザーが過去30日間に作成したJiraチケットをクエリしたときのことだ。想定していた件数は20件程度。実際は91件あった。
そのうち68件はタイトルに「[DRAFT]」がついたまま、人間の手が一切入っていない状態で放置されていた。ある午後、手作業でそれらを閉じながら著者は気づいた。パイプラインには、自分が設計していない「暗黙の第二の仕事」があった——ガベージコレクション（不要成果物の回収）である。
Model Context Protocol（MCP）を使ったAIエージェントは、Jiraチケットの作成、プルリクエストのオープン、TestRail（テスト管理ツール）へのテスト結果の記録など、複数の外部システムへ書き込む能力を持つ。しかしエージェントが途中でエラーを起こしたり、再実行されたりすると、中途半端に生成された成果物が各システムに残り続ける。このゴミの回収を最初から設計に組み込んでいなかったことが、91チケットという結果を招いた。
著者が今すべてのパイプラインに書く「3つのもの」
この経験から、著者は最初のエージェントを書く前に必ず以下の3点を書くようになったという。
- シャットダウンスクリプト：現在の実行が孤立させた成果物を閉じる
- 夜間の突合パス：過去の実行が孤立させた成果物を閉じる
- 名前のある人間のオーナー：パイプラインが書き込める下流システムごとに、Slackハンドルつきの担当者を組織図上で明示する
3番目のルールが特に実践的だ。Jiraチケットを作成したら実際の担当者をアサインする。プルリクエストをオープンしたら特定のレビュアーを指定する。TestRailにテスト実行を登録したら、それが陳腐化した場合に誰かへ通知が飛ぶようにする。そしてパイプラインは、名前のあるオーナーが存在しないシステムには書き込めないというルールを設ける。
このルール一つで、あの91チケットの午後は防げた。
このアプローチが求めているのは、単なるコードの変更ではない。「エージェントが触れる外部システムごとに、人間の責任者を事前に決めておく」という設計上の規律だ。Jira・GitHub・TestRailといった書き込み先が増えるほど、オーナーの明示なしに運用を続けることのリスクは線形以上に高まる。
「エージェントに自分の成果物を閉じさせるな」
記事が最も強調するアンチパターンが、エージェント自身にクリーンアップをさせることだ。
著者は実際に試みた。クリーンアップを担当させたエージェントは、誤った30件のチケットを閉じた。そして自信を持って「正しいものを閉じた」という要約を書いた。
この失敗が示す教訓はシンプルだ。クリーンアップは人間のループか、決定論的なスクリプトで行う。モデルへの呼び出しではない。LLMは「どれが孤立した成果物か」という判断を、一貫性をもって正確に行うことができない。確認の文章を生成するのは得意でも、それが正しいとは限らない。
言い換えれば、LLMの得意な「文章生成」と、冪等性や正確性が求められる「状態管理」は、明確に分離して設計しなければならない。エージェントに書き込みをさせるなら、書き込みの後始末は決定論的なコードが担う——この原則を最初から組み込むかどうかで、運用後の負債の大きさが変わる。
なぜ今これが重要か
※編集部の考察
MCPエージェントの実装事例が増える中、プロトタイプから本番への移行で詰まるポイントとして「成果物管理」と「外部システムへの書き込み制御」が繰り返し話題になっている。デモ動画ではエージェントがきれいに動く部分しか見せないが、実際の運用では今回の記事が指摘するような「設計されていなかった仕事」が必ず発生する。
特に複数の外部システム（Jira・GitHub・TestRailなど）にまたがって書き込みを行うエージェントを運用する場合、孤立した成果物の管理とオーナーシップの明示は、後から付け足すのが難しい設計上の関心事だ。MCPの仕様自体は公式サイトで公開されているが、仕様が定義するのはプロトコルであって、本記事が扱うような「運用上の設計規律」は仕様書には書かれていない。現場で積み上げられた知見として、本記事の内容は参照価値が高い。
詳細はShipping an MCP test agent: The boring parts nobody demosを参照していただきたい。
