檻と自律

Platform City の基盤（The Plat）自体は、徹底して「決定論的（Deterministic）」に設計されています。同一の入力を与えれば常に同一の結果を返す、信頼性の高い堅牢なソフトウェアです。確率的で非決定的な振る舞いはすべて参加者側の AI エージェントに委ね、プラットフォーム側はそれらを安全に包み込む確固たる「檻（ガードレール）」としての役割に徹しています。

なぜプラットフォーム側に LLM を組み込まないのか

エージェントによるコード生成がどれほど確率的であっても、それを通過させる検証基準が決定論的であれば、システムとしての安定運用が成り立ちます。lint が通り、自動テストをパスし、ヘルスチェックに正しく応答する――これらの合否判定は、LLM の確率的な揺らぎに一切影響されません。

もしプラットフォームの基盤側まで確率的に動作してしまうと、障害調査の再現が不可能になり、負荷テストの信頼性も失われ、イベント当日の挙動を運営側が予測できなくなってしまいます。100 人以上の参加者が同時にアクセスする一発勝負の大規模イベントにおいて、基盤の挙動が確率的であっては破綻のリスクを抱え込むことになります。

そのため、テナントの払い出しからデプロイの受付、街の区画割り当てに至るまで、すべての制御プレーンは決定論的なコードとして実装されています。万が一不具合が発生した場合でも、従来のシステムエンジニアリングと同様の手法で確実にデバッグと原因特定が可能です。

「檻が先、自律は檻の中で」という原則

私たちは、プラットフォームを永久に静的な檻のままにしておこうと考えているわけではありません。将来的には、プラットフォーム自身がインフラの障害を自律的に検知して自動修復するような高度な仕組みを導入することも視野に入れています。

しかし、そこには明確な順序が存在します。まずは確固たる檻（境界とガードレール）を構築し、実際の過酷な本番運用の中で十分に検証すること。その上で初めて、検証済みの安全な檻の中にプラットフォーム側の自律エージェントを解き放つべきです。

Platform Engineering Kaigi 2026 での実証実験は、その最初のステップとなる「第 1 幕」です。イベント駆動のアーキテクチャとガードレールという檻の堅牢性を、100 人規模の同時運用を通じて徹底的に検証します（次期フェーズに持ち越した課題については、第 2 幕に残したもの で触れています）。

檻は参加者を縛るためのものではない

「檻」や「ガードレール」という表現を使うと、利用者を厳しく縛り付けるような窮屈な印象を受けるかもしれません。しかし実際には、リソース Quota やレート制限に抵触した際にも、なぜリクエストが拒否されたのかという理由と、どうすれば正常に受理されるのかという具体的な解決策がセットで返却されます。

単なる一方的なエラーで終わるのではなく、拒否通知そのものがエージェントにとっての「次の行動指針」として機能します。明確な境界が定義されているからこそ、エージェントはその枠組みの中で迷うことなく、最大限に自律性を発揮できるのです。

※ なお、このアーキテクチャはあくまで設計上の基本方針であり、私たちが対外的に最も伝えたいメッセージそのものではありません。私たちが届けたいのは「AI の力を活かすことで、これまでにない優れた開発者体験を実現できる」という確信であり、決定論的な檻はその体験を支えるための土台なのです。