検証シグナル

AI エージェントがどこまで自律的に開発や運用を進められるかは、基盤モデルのパラメータ数や賢さだけで決まると思われがちです。しかし Platform City では、そうした見方をとっていません。エージェントの自律性を真に左右するのは、プラットフォームが返すフィードバック情報の質と粒度であると考えています。

モデルの賢さ以上に「返される情報の質」が重要である理由

エージェントは、ツールから返却された実行結果をコンテキストとして読み込み、次に取るべき行動を推論します。もしツールが単に「失敗しました（Internal Server Error）」としか返さなければ、どれほど優秀なフロンティアモデルであっても、暗中模索で場当たり的な推測を繰り返すしかありません。

逆に、どの処理フェーズで何が期待と食い違っていたのかが明瞭に伝われば、エージェントは即座に根本原因へアプローチできます。

Platform City の MCP ツール群は、処理の成功・失敗を問わず、常に次に実行すべき推奨アクション（next_steps）を返します。エラー情報も曖昧な自然言語ではなく、機械可読な構造化データとして返却されます。たとえばアプリケーションの作成上限に達した場合であれば、上限に達した事実、許容されている最大数、枠を空けるための手段が明確に提示されるため、エージェントは人間の手を借りずに自力で状況を打開できるのです。

status は deploy のおまけではない

一般的な開発基盤では、デプロイを受け付ける API さえ用意すれば十分であるかのように考えられがちです。しかし、実際の開発現場ではそれだけではまったく不十分です。デプロイが正常に通った瞬間よりも、デプロイが失敗したときに「内部で何が起きていたのか」を正確に把握できる観測手段こそが、トラブルシューティングにおいて決定的な役割を果たします。

Platform City の status ツールは、直近のデプロイフェーズ（started / succeeded / failed）、配備対象のコンテナイメージ、処理の開始・完了時刻などを詳細に返します。もしこの観測シグナルが貧弱であれば、100 人以上の参加者が直面する「動かない」という詰まりを、運営スタッフが手作業で 1 件ずつ調査して回らなければならなくなります。

当日の運営リソースでその詰まりを捌き切ることは不可能です。トラブルを自律的に解決するのはあくまで参加者側のエージェントであり、エージェントが自力で問題を解決できるように質の高い判断材料を供給し続けることこそが、プラットフォームの最も重要な責務です。

検証シグナルを「決定論的な結果」に限定する意義

プラットフォームがエージェントに返すシグナルは、決定論的な検証結果のみに厳密に絞り込んでいます。CI パイプラインが成功したか、ヘルスチェックのエンドポイントが正常に応答したか――いずれも同じ入力・同じ状態であれば、常に寸分違わぬ同一の判定結果を返します。

ここに LLM による主観的な良し悪しの判定（LLM-as-judge）を挟むことはしていません。非決定的な検証者によって非決定的な生成物を統制しようとする複雑な問題は、今回のアーキテクチャではあえて扱わない方針をとっています（詳細は LLM-as-judge を参照）。

街並みに現れる修復の軌跡

煙の上がった建物へとエージェントが駆けつけ、自律的にトラブルを解消していく様子は、Map の画面上でリアルタイムに目撃できます。具体的なトラブルシューティングの流れは 壊れたときの直し方 を、可視化に込めた意図については 失敗の可視化 をご覧ください。