Backstage を入れない

プラットフォームエンジニアリングの文脈において、開発者ポータル（Internal Developer Portal）の代表格である Backstage の導入は有力な選択肢の一つです。しかし Platform City では、企画の初期段階で Backstage の採用を意図的に見送りました。Home はユーザーが自身の環境状態を素早く確認するための軽量なダッシュボードであり、重厚なソフトウェアカタログを目指したものではありません。サービスカタログとしての役割は、エージェント向けに提供される 2 つのシンプルな MCP ツールで十分に満たせると判断したためです。

採用を見送った背景と理由

Backstage を本格的に活用するためには、バックエンドサービス、独自プラグイン、認証基盤、そしてカタログメタデータの厳密なモデリングなど、多大なインフラ構築と運用保守のコストが求められます。1 日限りの実証イベントというスコープに対し、その運用負荷は過大であると言わざるを得ませんでした。

しかし、理由は単なる構築工数の問題だけではありません。より本質的な理由は、このプラットフォームにおける第一級の利用者が「参加者の AI エージェント」であるという点にあります（詳細は 第一級の利用者 を参照）。

人間のエンジニアがブラウザ上で一覧を眺めるためのリッチな Web ポータルをどれほど豪華に作り込んだとしても、実際に自律開発を行う AI エージェントはその UI を参照しません。エージェントが真に求めているのは、ブラウザ向けの見栄えの良い画面ではなく、機械可読な形式で即座に問い合わせ可能な API カタログと、迅速に修正ループを回せる高品質なシグナルなのです。

カタログ機能は MCP ツールでシンプルに提供する

Platform City において、他の参加者が公開している API を探索したい場合は discover_apis ツールを、自分自身が開発した API を街に公開・登録したい場合は register_api ツールを使用します。

どちらもエージェントから自然なコマンドとして呼び出されるため、人間がブラウザ上で煩雑なカタログ画面を行き来する必要はありません。

さらに、エージェントが他のアプリの API を利用すると宣言すると、Map 上で建物同士の間に道（パス）が自動的に接続されます。ソフトウェア同士の連携関係は、静的な一覧テーブルではなく、生き生きとした街並みの景観そのものとして可視化される仕組みになっています。

Home 画面が果たすべき本来の役割

Home 画面は、ログインした参加者本人が「自分自身の環境が現在どういう状態にあるか」を一目で確認するためのシンプルなダッシュボードです。

市民登録が正常に完了したか、GitLab のリポジトリ準備が整ったか、最初の建物が無事に街に建ったか、そして現在自分のアプリに煙が上がっていないか――それらの重要事項を素早く把握し、次に取るべきアクションを把握するために存在しています。

この Home 画面自体には、アプリを作成したり設定を変更したりする直接の操作ボタンは設けていません。すべての能動的な変更操作は、エージェントを通じて MCP 経由で実行します（詳細は Home からの作成 を参照）。必要最小限のダッシュボードを 1 枚提供することと、重厚な開発者ポータルを抱え込むことの違いを明確にし、本質的な価値に集中した設計を選択しています。