City Guide

街の様子や建物の状態（灯り・足場・煙）の意味、いいねの仕組み、中央広場でのセッション視聴など、Map の見方を解説します。

Claude Code・Codex・OpenCode・Kilo の MCP 接続設定から、市民登録、GitLab への初回ログインまでを順に進め、利用できるツールとアプリの追加方法を説明します。

オンボーディングで作成された自己紹介アプリをもとに、MR の作成から AI レビューを経て最初の建物を街に建てるまでの流れを解説します。

自己紹介アプリの公開後に、既存アプリを育てる、短いアプリで遊ぶ、街や他の参加者とつながる、という任意の選択肢を紹介します。

機能追加や修正を GitLab の Issue に書き、エージェントに「Issue #N を実装して」と伝えてから、MR・AI レビュー・マージ・デプロイまでが進む日常の開発の流れを解説します。

テーマ `game` で、1〜3分で遊べるゲームと参加者ランキングを備えたアプリを作り、ゲーム区画へ公開する流れを解説します。

登壇者を応援する「推しアプリ」の作り方や、専用区画に建てるテーマ `oshi`、投票の成立条件、箱推しの扱い、後からの変更手順について解説します。

会場周辺の店を紹介するアプリの作り方（テーマ `food`）、`platform-city.json` の `food` の書き方、掲示板の地図と一覧の見方、「行きたい」が建物を育てる仕組みを解説します。

api テーマで建築し、OpenAPI を公開して API を登録・発見・利用する手順を解説します。

meet テーマで、参加者同士がやり取りできるアプリ（掲示板・お絵かき・投票など）を作り、投稿をテナントの DynamoDB に保存して参加者交流区画へ公開する手順を解説します。

他のテーマに収まらないものを general テーマで自由に作る手順と、この区画だけで使える Kubernetes マニフェストの書き方・ガードレールを解説します。

自動で用意されるテナント専用テーブルに、アプリのサーバー側からデータを保存する方法、認証、キーの形式、ローカル検証と制限を解説します。

建物から煙が上がったときの原因の調べ方や、機械可読なエラー情報をもとにエージェント自身で修復を進める方法を説明します。

人間向けの過剰なポータルよりも、エージェントが自律的に状況を把握して修復できる検証シグナルを最優先で整備した設計思想を解説します。

プラットフォーム側を決定論的な「檻」として堅牢に保ち、非決定性をエージェント側に委ねるアーキテクチャの狙いを説明します。

エージェントの自律性を高める鍵はモデルの性能だけでなく、プラットフォームが返す機械可読なフィードバックの質にあるという考え方を解説します。

街の失敗や修復プロセスをあえて隠さず可視化し、エージェントの自律的な行動そのものを観察可能にした背景を説明します。

プラットフォーム基盤は GitOps で静的に管理しつつ、頻繁に増減するテナント情報は API 経由で動的に処理する設計の理由を解説します。

デプロイの合否判定に LLM を使わず、あえて決定論的な CI とヘルスチェックのみに絞った理由を説明します。

プラットフォーム側の自律修復や詳細な監査ログを今回は見送り、次期フェーズ（第2幕）の課題とした背景を説明します。

開発者ポータル Backstage を導入せず、MCP ツールによる API カタログと軽量な状態確認画面に絞った判断について解説します。

当日の Home 画面からの作成操作を提供せず、操作の入口をエージェント（MCP）に一本化して品質を担保した理由を解説します。