Platform City で何が体験できるのか “オンボーディングから、煙の上がる建物をエージェントが直すまで”
Platform City チームの川村です。
Platform City は、概要ページにあるとおり「会場参加者100人以上が一斉に AI エージェントでアプリを開発・デプロイし、仮想都市を作り上げる実証実験」です。
Platform Engineering Kaigi当日を待たず、事前に皆様に体験いただけるコンテンツになっています。 近日、現地参加される皆さま向けに詳細な体験方法をご案内しますので、続報をお待ちください！
本記事では、先日の紹介記事に続いてPlatform Cityで「当日何が体験できるのか？」「中身はどうなってるの？」をご紹介します。
今回はまず体験の話です。参加の流れは、オンボーディング → エージェントで開発 → push で自動デプロイ → 施設同士が連携、の4ステップです。この4ステップで実際に何をして、何が起きて、何が見えるのかを順に追います。仕組みの話は次回以降ご紹介します。
まず、いまの街がどんな見た目かをお見せしておきます。
中央の広場を囲んで区画が放射状に並んでいて、参加者のアプリが1棟ずつ建物になります。これがどう建って、どう煙が出るのかを、参加者の体験としてここから順に追っていきます。
MCPでオンボーディング
参加者が準備するのは、お使いの AI エージェント（Claude Code、Codex、Cursor など、MCP に対応したもの）に Platform City の MCP サーバーを登録することだけです。
https://<MCP サーバーの URL(後日公開)>/mcpこれを設定ファイルに足して終わりです。ローカルで何かをビルドしたり、サーバープロセスを起動したりする必要はありません。あとは日本語で話しかけるだけです。申請フォームも承認待ちもない、シンプルな手順となっています。承認がないのは「省略した」のではなく「経路がない」からで、onboard は既にテナントがあれば 409 を返すだけで、既存テナントには一切書き込みません。人間のゲートを外す代わりに、書き込み経路そのものを閉じています。
概要ページに記載している通り、Kubernetes も Docker も知らなくても参加できます。
「参加したい」と言うと街の住人になる
MCP サーバーを登録したエージェントに向かって、自分のusernameとemailを決めて、こう入力してみてください。
Platform City にオンボーディングして。username は taro-yamada、email は [email protected]エージェントが onboard というツールを呼ぶと、1〜2分で以下が揃います。
- GitLab 上の自分専用サブグループと、最初のプロジェクト（自己紹介アプリ）
- Kubernetes の namespace と、その中だけで作業できる権限
- リソース上限（CPU・メモリ・Pod 数）の設定
- 公開用のホスト名
- このテナント専用の API トークン（
logsなどで使います。再表示されないので保管してください）
リポジトリと CI/CD は GitLab.com を使っています。これは GitLab さんにスポンサーとして Ultimate プランをご提供いただいているもので、後述する AI レビュー（GitLab Duo）や、CI をプロジェクトの外側から固定する仕組みは、この提供があって初めて成り立っています。この場を借りてお礼申し上げます。
ここで指定した username が、そのままあなたの「住所」になります。Kubernetes の namespace 名、公開 URL のサブドメイン、GitLab のパスが全部この名前から決まるので、一度決めたら変えられません。1か所の命名で3つの世界の識別子が揃う、命名がそのまま契約という形です。
email は、このあと GitLab にログインするときに使う Google または GitHub アカウントのアドレスを指定ます。
ツールのレスポンスには next_steps として次にやることが書かれて返ってくるので、エージェントがそのまま案内してくれます。GitLab の初回ログインまわりは SSO の都合で少し手順があるので（招待メールのリンクは踏まない、など）、ここはエージェントの案内と、当日公開する City Guide（Platform City の使い方ページ）の「市民になる」に従ってもらう形です。
コードを書いて push すると、勝手に公開される
払い出されたプロジェクトには、最初から通る CI が入っています。lint → test → build → イメージの push → デプロイまで構築済みで、参加者は CI を1行も書きません。ちなみに、プロジェクト内の .gitlab-ci.yml を書き換えても効きません。CI はグループ側のポリシーがプロジェクトの外から上書きしているので、「触れない」のではなく「触っても効かない」作りです。
開発の流れ自体は普通です。トピックブランチを切って、コードを直して、マージリクエストを出す。main への直 push は塞いであります。
MR を作るときに、レビュアーに @GitLabDuo（GitLab の AI レビュー機能）を指定します。 これもエージェントが API でやるので、ブラウザを開く工程はありません。MR を出すと verify-ai-review というジョブが最初は失敗しますが、これは正常な挙動で、「まだ AI レビューを受けていないよ」と検出できている状態です。Duo のレビューコメントに対応してスレッドを解決し、ジョブを Retry すると緑になってマージできます。「AI レビューを受けたか」をコメントではなくジョブの成否で表現しているので、レビューを飛ばしてマージする経路がありません。
マージすると main のパイプラインが走り、ビルドされたイメージが自動でクラスタに配られます。公開 URL はこうなります。
https://<username>.<街のドメイン>/2つ目以降のアプリは https://<username>.<街のドメイン>/<アプリ名>/ というパス形式です。1テナントあたり3つまでアプリを作れます。4つ目を作ろうとすると、上限に達した事実・許容数・枠を空ける方法がセットで返ってきます。リソース上限も同じで、「既存 750m + 追加分 500m = 1250m > 上限 2000m」のように式ごと返ります。当日ぜひ一度、わざと上限に当たってみてください。
そして建物が建つ
デプロイされたアプリは、会場スクリーンに映る街に 1棟の建物として生えます。
- 建設中: 足場が組まれます。新しいバージョンがクラスタに配り終わるまでの状態です
- 稼働中: アプリが 8080 番ポートで待ち受け、
/healthzが 200 を返し始めると、窓に灯りがともります。さらに街の外から公開 URL を1分に1回GET /していて、こちらが失敗し続けると橙に落ちます
建物の見た目と建つ場所は、プラットフォーム側により自動でアサインされます。乱数は使っていません。テナント名とアプリ名から決定論的に決まるので、リロードしても、会場スクリーンでも手元のスマホでも、同じ建物が同じ場所に立ちます。「自分のビルを覚えられること」を体験の要件にしているからです。
失敗すると煙が出る、そして自ら直せる
Platform City の面白いポイントの1つです。
ヘルスチェックに応答しない、起動に失敗して再起動を繰り返している、コンテナイメージを取得できない。そういうとき、建物から煙が上がります。 全滅していれば黒煙と赤い明滅、一部が生きていれば橙のマーカーです。煙が出るのはデプロイの失敗だけではありません。街は control-plane からの通知ではなく Kubernetes そのものを観測して描いているので、デプロイ成功の3分後に OOM で落ちても煙が上がります。
そして運営は、それを隠しません。裏でこっそり直したりもしません。直すのは参加者の手元にいるエージェントです。
煙が出ている建物をクリックすると、カードに障害の理由がそのまま出ます。エージェントに status を叩かせれば、直近のデプロイがどのフェーズで、どのイメージで、いつ始まっていつ終わったのかが返ってきます。logs を叩かせれば（onboard で受け取ったトークンが要ります）、いまのログと再起動前のログ、起動に失敗した理由まで返ってきます。あとはエージェントがそれを読んで直します。
修正版が配られている間は、また足場が組まれます。そしてアプリが正常に応答を返した瞬間、煙が消えて灯りが戻ります。
100人が同時に deploy しても壊れないよう、デプロイはテナントあたり60秒に10回まで、クラスタ全体の同時ロールアウトにも上限があり、同じアプリへの連続デプロイは1件ずつ直列になります。制限に当たると「あと何秒待てばいいか」が返ってきます。
会場スクリーンで煙を中継したときは、修復が終わったら対になる「修理完了」のアナウンスを出す予定です。失敗が物語の一部になって、修復までがセットで見える。そういう形を目指しています。
他の人の API と繋ぐと、街が経済圏になる
概要ページの4つ目のステップです。自分の API を register_api で街のカタログに載せると、他の参加者のエージェントが discover_apis で見つけられます。見つけた API を組み込んで deploy するときに consumes で「この API を使っています」と宣言すると、その連携がプラットフォームに記録されます。
グルメ情報 API を会場マップアプリが呼ぶ、という具合に施設同士が繋がり始めたら、それが概要ページで言う「都市に経済圏が生まれる」瞬間です。仕込む側としても、当日いちばん見たい場面です。
いいねで建物が育つ
来場者は、気になった建物に匿名でいいねを押せます。連打などの不正はリアルタイムには弾かず、記録して集計側で区別します。弾くと押した人の画面に反映されず「壊れてる？」という不信感が出るからです。匿名なので自己投票も厳密には排除できないため、いいねの数だけで表彰を決めることはあえてしません。
いいねが集まると建物が段階的に育ちます。10いいねで一段育ち、50いいねに達すると高層ビルに建て替わります。建て替わるときはちょっとした演出が入ります。
いいねがたくさん集まるようなアプリをデプロイしていただき、面白いと思った建物にはいいねをしてみてください。
皆さんの行動により、街全体が育っていきます。
また、いいねとは別に「応援」ボタンもあって、こちらは好きなだけ連打できます。応援が届くと中央広場から花火が上がります。票数や建物の成長には加算されませんが、是非やってみてください。
街にはたくさんの区画がある
街は中央広場を中心に、区画が放射状に並んでいます。自己紹介区画、ゲーム区画、API・Cloud Native 実験区画、推し登壇者トリビュート区画など、テーマごとに地面の色もランドマークも違います。どの区画に建てるかで、自由度も変わります。自己紹介アプリは CI 完全固定、ゲームはビルド処理だけ自由にする設計で、テーマを選ぶことが信頼レベルを選ぶことになっています。
どの区画に建てられるか（create_app で選べるテーマ）は当日に向けて順次増やしていきます。区画の内容も多少変わるかもしれません。
中央広場には Track A・B・C のパブリックビューイングが最初から建っています。建物をクリックすると YouTube の配信が立ち上がるので、街を散策しながらセッションを観られます。
これは何の実証実験なのか
最後に、企画の話をします。概要ページには「この企画が証明すること」として3つ書いてあります。
- MCP＋スキルでプラットフォームの知見を AI に渡せば、オンボーディングコストはほぼゼロになる
- プラットフォームが契約（API 仕様＋エコシステムルール）を定義すれば、エコシステムは自律的に成長する
- AI エージェントは最高のプラットフォーム消費者になれる
ここまで書いた体験は、この3つをそのまま手順にしたものです。URL を1つ足すだけで住人になれるのが1、/healthz や 8080 番ポートといった規約と API カタログが2、煙が上がった建物にエージェントが駆けつけて灯りを戻すのが3です。
これを基礎として、様々な体験が構築されています。
100人規模になると、人間が1件ずつ承認したり、詰まった人のログを運営が読んで助けたりすることは物理的にできません。だからプラットフォームは「エージェントが自分で直せる情報」を返せなければいけません。効いてくるのはモデルの賢さではなく、プラットフォームが返すフィードバックの質です。
当日の街を見れば、その設計が正しかったかどうかが分かります。煙が上がったまま放置されていれば我々が返している情報が足りないという証拠で、すぐ灯りが戻るなら3つの命題が当たっていたということです。街はビジュアル表現であると同時に、この実験の採点表でもあります。
終わりに
次回は、この「エージェントが顧客になったプラットフォーム」をどう作ったのかを書きます。
また、Platform City の続報や当日の様子は、公式 X でも発信していきます。ぜひフォローして最新情報をチェックしてください！ https://x.com/cnia_pfem（ハッシュタグ: #PEK2026）
Platform Engineering Kaigi 2026
- 開催日：2026年9月26日（土）
- 場所：中野セントラルパークカンファレンス
- 申し込み：FindyConference (一般申し込み、オンラインともにリンク先からの申し込みが必要となります)
- 問い合わせ：問い合わせフォーム