Home からの作成

Home 画面には、新しいテナントを開設するフォームも、追加のアプリケーションを作成するボタンも用意されていません。イベント当日の Home は徹底して「読み取り専用（Read-only）」のダッシュボードとして提供されます。テナントを作成する onboard や、アプリを追加する create_app といったあらゆる書き込み操作は、使い慣れた AI エージェントから MCP を経由して実行します。

Web 画面からの作成導線をあえて設けなかった理由

Home 画面上にリソース作成用のボタンや入力フォームを配置すること自体は、技術的に決して難しいことではありません。それでも私たちが画面からの作成導線を用意しなかったのは、システムに対する書き込みの入口を 2 つに分裂させないためです。

MCP 経由で実行される操作は、処理が失敗した際にも詳細な機械可読のエラー構造体と、次に取るべき具体的なアクション（next_steps）をセットで返します（詳細は 検証シグナル を参照）。もし Home 画面からも同様のリソース作成を可能にしてしまうと、Web UI 側でもまったく同等の品質を持つエラー表示や、きめ細やかなガイダンス体験を二重で実装・保守し続けなければならなくなります。

限られたリソースの中で参加者に届ける体験の総合的な品質を最優先に考えた結果、書き込みのインターフェースをエージェント（MCP）へ一本化する決断を下しました。もし片方の UI だけエラーハンドリングが不親切になってしまえば、そこから開発者体験全体の破綻が始まってしまうからです。

すべての操作をエージェントへ集約するメリット

操作の窓口をエージェント側に集約することで、人間の開発者が手動で行うべき作業は劇的にシンプルになります。

参加者は Home 画面で現在のシステム状態を俯瞰し、画面上に提示された「次にやること」を確認して、それをそのまま手元の AI エージェントにプロンプトとして渡すだけで作業が進みます。Home 画面に表示されるガイダンス文は、エージェントへそのままコピー＆ペーストして指示できるように最適化されています。

この役割分担は、プラットフォームにおける第一級の利用者を AI エージェントとして位置づけるという基本設計（第一級の利用者）とも美しく調和しています。人間向けの Web 画面は直感的な状態把握とナビゲーションに特化させ、実際のリソース操作と修復の実行権限はエージェント側に持たせる――Home 画面の読み取り専用という制約は、この明確な設計思想のもとに成り立っています。

将来的な拡張に対するスタンス

今後のプラットフォームの発展やフィードバックによっては、Home 画面側から直接アプリを作成できる機能を追加する日が来るかもしれません。しかしその場合でも、なぜその入口を増設するのか、そして 2 つの操作経路において同等水準の優れた開発者体験をどのように保証するのかを、アーキテクチャ決定記録（ADR）として事前に明確に定義した上で実装を進めます。

現在 Home 画面に作成ボタンが存在しないのは、設計上の見落としや開発期間の不足による妥協ではなく、開発者体験の品質を守るために意図して下された積極的な意思決定なのです。