この記事は、TOI の背後にある実行環境について記述している。これは Toss の社内プラットフォームであり、チームは必要な API を登録した上で、欲しい画面を自然言語で依頼することでアドミンツールを構築し、モデルが登録されたリクエストとレスポンスのスキーマに基づいて React コードを書く。記事の主題はコード生成ではなく、その周囲に存在しなければならないものである。著者の捉え方では、コードを生成するだけで十分だったことは一度もない。リアルタイムに生成されたコードが製品になるのは、それを実行して見せる場所があってこそだからである。
記事はアドミンツールをポリシーと画面に分ける。ポリシー、すなわち呼び出しのログ記録、個人情報のマスキング、ダウンロードファイルの暗号化、データを照会する理由の記録は、プラットフォームが担う。プラットフォームは登録されたすべての API 呼び出しをプロキシし、その過程でそれらの設定を適用する。画面はモデルが書くものである。記事はその後、生成されたコードを実行するための 2 つの失敗したアプローチと、それらに取って代わった設計をたどり、コードそのものが安く生み出せるようになったとき、エンジニアリングの労力がどこに向かうのかについての議論で締めくくる。
要点
- プラットフォーム自体の規模は著者らによって報告されている。2026 年 2 月に社内で公開され、2026 年 8 月までに 439 のプロジェクトとその配下の 2,418 のページが蓄積された。
- iframe を通じてユーザーに見せるサーバーサイドの共有開発サーバーは、概念実証には使えたが、複数ユーザーには使えなかった。実行環境がユーザーごとに分離されていなかったため、ある人が 1 つのページを編集して起きたコンパイルエラーが、他の人の画面にもエラーオーバーレイを表示させてしまったのである。
- サードパーティのサンドボックスを使って実行を各ユーザーのブラウザに移すことでユーザーの分離には成功したが、別の問題が生じた。サンドボックスが描画時に宣言されたすべてのパッケージをダウンロードするため、最初のプレビューに 47 秒かかったのである。
- 社内のプライベートパッケージがこれに拍車をかけた。認証情報をブラウザのランタイムに露出させることはできず、またメタデータのリクエストだけをプロキシしても不十分だった。メタデータ内の tarball の URL が元のレジストリを指していたため、それも書き換える必要があり、しかも依存グラフを再帰的にたどって書き換えなければならなかった。
- チームの代替案は、仮想ファイルシステムの上でブラウザ自体の中でビルドを実行するものである。仮想ファイルシステムは、現在のページのコード、プロジェクト共有のコード、プレビューシェルのテンプレート、プレビューランタイムの 4 層に重ねられ、前から順に探索されることで、バンドラーからは 1 つのファイルシステムに見える。
- パッケージはバンドルから取り除かれ、ブラウザ自身の import map を通じて提供される。これらはプレビュー時に解決されるのではなく、事前にビルドされる。
- 依存関係は個々のパッケージではなく組み合わせとして扱われる。パッケージを別々にバンドルすると、アプリとその依存先が共有のシングルトンの 2 つの異なるインスタンスを持つことになりうるからである。組み合わせは、公開エントリーポイントのソート済みリストをロックファイル自体のハッシュと共にハッシュ化し、先頭 16 文字を取ることで識別され、
package.jsonの独自フィールドpackageSetHashとして記録される。 - 組み合わせは実際にインストールすることで構築される。空のワークスペースを作成し、プロジェクトの
package.jsonをコピーし、パッケージマネージャーを実行するのである。著者はここが要点だと述べる。peer dependency の解決やバージョン競合のチェックは、再実装されるのではなく、パッケージマネージャーの仕事のままになる。 - ホットモジュールリプレースメント（HMR）は採用されず、ビルドのたびにドキュメント全体を置き換える方式が選ばれた。その理由の一部は、使用しているバンドラーが HMR を提供しておらずモジュールグラフの追跡を自前で構築しなければならないことであり、また一部は、プレビューは操作されるのではなく見られるものなので、編集状態を保持してもあまり得るものがないことである。著者は、ドキュメント全体の置き換えによって各更新がトランザクションのコミットのように振る舞うと指摘している。実行に失敗したバンドルはコミットされないため、プレビューは最後に実行できたバージョンを表示し続け、その上にエラーオーバーレイが表示される。
- 最初のプレビューまでの時間は 47 秒から 1.3 秒になったと報告されており、著者はこれを、プレビューのたびに繰り返されていた作業を、パッケージの組み合わせが変わった時点に移したことによるものとしている。
- 締めくくりの主張は、コードを生み出すコストが下がるにつれて、製品づくりで何が重要なのかがよりはっきり見えてくるというものである。ここでは、アドミンツールが守るべきポリシーを保証することと、生成されたコードを安全に実行できる構造を設計することがそれにあたる。著者は、システムのほとんど何もゼロから作られてはいないと述べている。作業は、既存のツールを製品の要件に照らして組み合わせることだった。
背景
この記事はプラットフォームを構築したチームによるエンジニアリングの報告であり、その数値、すなわちプロジェクト数とページ数、47 秒と 1.3 秒という計測値は、そのチーム自身のものである。生成された画面がどの程度うまく動くか、どれくらいの頻度で修正が必要かについては何も述べておらず、主題は厳密にコードが実行される環境である。
モデルの出力を安価になった部分として扱い、その周囲のシステムを残された作業の所在として捉えるという締めくくりの論法は、この wiki が他の箇所でも記録しているものである。Software 3.0 時代、Harness による組織生産性の底上げ と比較されたい。あるコメント投稿者は、AI が生成したフロントエンドのコンポーネントをデザインシステムの規約とセキュリティポリシーの範囲内に保つための同等の作業を記述し、自らの経験からこの結論を支持している。一方で別のコメント投稿者は、新しいバックエンドをプラットフォームに接続するためにチームが何をしなければならないかという、記事が答えていない質問をしている。