TOI

TOI は、Toss の社内向けの管理ツール構築プラットフォームである。ユーザーはツールが呼び出す API を登録したうえで、欲しい画面を自然言語で説明する。モデルは、登録された API のリクエストとレスポンスのスキーマを参照して React コードを生成する。TOI は AI が作ったコードがアドミンになるまで で紹介されており、同記事によれば 2026 年 2 月に社内に公開された。

TOI が取り組む課題は、繰り返しとコストだとされている。Toss では多くのチームが管理ツールを構築・改修しており、以前はそれぞれが同じ開発・セキュリティ・デプロイの作業を繰り返していた。プロジェクトの雛形作成、ビルドツールの選定、認証の追加、デプロイの設定、そして管理ツール特有の要件である、個人情報のマスキング、照会理由の記録、ダウンロードファイルの暗号化といった作業である。

TOI はこの作業を 2 つに分ける。ポリシーはプラットフォームが担う。登録された API への呼び出しは TOI サーバーを経由して元の API に届き、呼び出しの記録は自動的に残され、API ごとの設定は通信の途中で適用される。また、必須のセキュリティポリシーは自動的に適用される。画面 ― テーブルの描画、フィルターの付与、詳細ページへのリンク ― はモデルが書く部分である。

機能

出典が最も詳しく説明しているのは、生成されたコードを動作する画面として表示するランタイムであり、これはユーザー自身のブラウザ内で動作する。

• 階層化された仮想ファイルシステム。 ブラウザには、バンドラがインポートパスを解決するためのプロジェクトのファイルシステムがないため、TOI がそれを提供する。所有者と変更頻度の順に並んだ 4 つの層 ― モデルが生成した、あるいはユーザーが編集した現在のページのコード、プロジェクトのページ間で共有されるコード、プレビュー用のシェルテンプレート、そしてプレビューランタイム自体 ― からなり、手前から奥へと順に照会されて、あるパスを最初に保持している層が優先されるため、バンドラからは単一のファイルシステムとして見える。
• ブラウザ内でのビルド。 バンドラには esbuild の WebAssembly ビルドが使われている。ブラウザでそのまま動作すること、そしてプラグインインターフェースによってファイルの参照を横取りし、仮想ファイルシステムから応答できることが選定理由である。TypeScript と JSX は変換され、ローカルのインポートは 1 つの ESM バンドルにまとめられ、その処理はメインスレッドから Web Worker に移されている。ローカルファイルにも登録済みパッケージにも解決できないインポートはビルドを失敗させる。
• インポートマップを通じて提供されるパッケージ。 サードパーティのパッケージはバンドルから除外され、実行時にブラウザのインポートマップを通じて接続される。インポートマップは、react のような bare specifier を事前ビルド済みのファイルに対応づける。
• パッケージ単位ではなくパッケージの組み合わせ単位。 出典の論拠は、依存関係はパッケージ 1 つずつにきれいに分けられないというものである。あるパッケージを個別にバンドルすると、共有の依存関係の独自のコピーが埋め込まれることがあり、その結果、アプリとライブラリが、シングルトンでなければならないものについて別々のインスタンスを持つことになる。そこで TOI は、プロジェクトの依存関係の集合全体を 1 つの単位として扱い、公開エントリポイントのソート済みリストとロックファイルをあわせてハッシュ化したものでそれを識別し、そのハッシュを package.json のカスタムフィールドとして記録する。組み合わせは、空のワークスペースに実際にインストールすることで準備される。これにより、ピア依存関係の解決やバージョン競合のチェックはパッケージマネージャーの仕事のままとなる。その後ブラウザ向けにビルドされ、インポートマップとともにアップロードされる。同じ組み合わせを共有するプロジェクトは同じハッシュを共有するため、既存のビルドは繰り返されずに再利用される。
• ホットモジュールリプレースメントではなくドキュメント全体の置き換え。 ビルドが成功するたびに新しい HTML ドキュメントが生成され、iframe は丸ごと差し替えられるため、DOM、コンポーネントの状態、モジュールのグローバル変数のいずれも前のバージョンから引き継がれない。出典はこれを、プレビューの更新にトランザクションのコミットのような性質を与えるものとして説明している。実行に失敗したバンドルはコミットされず、最後に実行できたバージョンが画面に残り、その上にエラーオーバーレイが表示される。

出典によれば、このランタイムを構築した後、最初のプレビューが表示されるまでの時間は 1.3 秒になった。

採用状況とエコシステム

出典によれば、2026 年 2 月の社内公開から 2026 年 8 月までの 6 か月間に、このプラットフォーム上で 439 のプロジェクトと、その配下の 2,418 のページが作成された。

上で説明したランタイムはチームが試した 3 つ目の設計であり、出典は、最初の 2 つがなぜ放棄されたのかを軸に構成されている。サーバー上の開発サーバーを iframe 越しに表示する方法は、ライブ更新を容易に扱え、概念実証には適していたが、ユーザーごとに実行を分離していなかった。ある人が 1 つのページを編集して発生させたコンパイルエラーが、別のページを編集している他の人の画面にまでエラーオーバーレイを表示させてしまったのである。CodeSandbox の Sandpack を使って実行を各ユーザーのブラウザに移すと分離は解決したが、描画開始時に宣言されたすべてのパッケージを取得するため、最初のプレビューが表示されるまでに 47 秒かかった。さらに、社内のプライベートパッケージには、依存関係グラフをたどって tarball の URL を再帰的に書き換える認証プロキシが必要であり、サンドボックスの別オリジンの iframe は、クロスオリジンやプライベートネットワークアクセスに関する独自の問題を引き起こした。

最終的なシステムには、それ単体で新規なものは何もない。出典は、パッケージを接続しているのはブラウザ自身のインポートマップであり、依存関係の解決は通常のパッケージマネージャーのおかげだとしている。そして筆者は、まさにそれが要点だと述べている。つまり、この仕事は、既存のツールを製品の要件に照らして選び、組み合わせることだったというのである。そこから導かれる結論は、コードの生成が安価になったときにエンジニアリングの労力がどこに向かうかについてのものである。すなわち、管理ツールが守らなければならないポリシーをプラットフォームが保証するようにすること、そして生成されたコードを安全に実行できる構造を設計することである。