Forge誕生の物語｜ウェブサイト作りを変えた、決定論的AIコンパイラ

AIのウェブサイトビルダーは、どれも同じ仕組みです。プロンプトを入力すると、LLMがHTMLを書き、出てきたものをそのまま受け取ります。よい出来のこともあれば、そうでないこともあります。もう一度「生成」を押すと、まったく違うものが出てきます。レイアウトも、色も、品質も別物です。出力は、根本的に予測できません。

私たちも、そのモデルを世に出しました。うまく動きました。多くの人がそれで本物のウェブサイトを作りました。けれど、何千ものサイトが生成されるのを見ているうちに、あるパターンが見えてきました。LLMが、本来判断すべきでないことを一から考え直すのに、トークンの大半を費やしていたのです。ナビゲーションの仕組み。色のコントラスト。モバイルのブレークポイント。アンカーリンク。フォントの読み込み。問い合わせフォームのマークアップ。

生成のたびに、正解のある問題に対して、新しくサイコロを振っていたのです。

Forgeは、その気づきへの私たちの答えです。少しずつの改良ではなく、AIがウェブサイトを作る仕組みそのものを、根本から変えたアーキテクチャです。

AIに生のHTMLを書かせる問題

LLMに「理髪店のウェブサイトを作って」と頼むと、LLMは何千もの判断を同時に下さなければなりません。どのセクションを入れるか。どんな順番で並べるか。ナビゲーションはどんな見た目か。どんな色を使うか。モバイルのレイアウトをどう扱うか。フォントをどう読み込むか。アンカーリンクをどうつなぐか。HTMLをどうセマンティックに構造化するか。コントラスト比をどう扱うか。営業時間をどう整えるか。電話番号をどうクリックできるリンクにするか。

そのうちのいくつかは創造的な判断です。どのセクションを入れるか、理髪店にはどんな配色が合うか、全体の雰囲気をどうするか。

ほとんどはエンジニアリングの判断です。ナビゲーションは本物のアンカーへスクロールしなければならず、コントラスト比は4.5:1以上でなければならず、電話番号はE.164形式でなければならず、フォントはpreconnectつきでGoogle Fontsから読み込まなければならず、モバイルのレイアウトは480px以下で縦に積み重ならなければなりません。

その両方をLLMに任せると、創造的な判断はよくても、エンジニアリングの判断にはばらつきが出ます。コントラストが完璧な生成もあれば、そうでないものもあります。アンカーリンクが機能するものもあれば、存在しないセクションを指す無効なhrefのものもあります。フォントを正しく読み込むものもあれば、解決されないfont-faceをインラインで書いてしまうものもあります。

Forgeの根底にある発想はこうです。創造的な判断とエンジニアリングの判断を切り分ける。創造性はAIに、正しさはコンパイラに任せる。

2段階のアーキテクチャ

Forgeは、ウェブサイトの生成を2つの段階に分けます。

フェーズ1：AIが何を作るかを決める（SiteSpec）

生のHTMLを書く代わりに、AIは構造化された仕様、つまりSiteSpecと呼ぶJSON文書を作ります。SiteSpecには、サイトにどんなセクションがあるか、各セクションにどんな内容が入るか、配色とタイポグラフィをどうするか、ナビゲーションがどう見えるか、デザイン全体の方向性はどうかが記されています。

創造的な判断は、すべてAIが行います。暗くて高級感のある雰囲気か、明るくて雑誌のような感じか。ヒーローには、Bebas Neueのような縦長の見出しフォントを使うか、Cormorant Garamondのようなエレガントなセリフ体を使うか。セクションに、ギャラリー、統計バンド、FAQ、チームのグリッドを含めるか。

しかしAIは、それをどう描画するかは決めません。HTMLもCSSも1行も書きません。意図を記述するだけです。

フェーズ2：コンパイラが、毎回完璧に描画する

SiteSpecは、決定論的なコンパイラに渡されます。仕様とプレイブック（Playbook）を受け取り、自己完結した本番品質のHTMLを出力する、純粋な関数です。同じ入力からは、必ず同じ出力が得られます。

エンジニアリングの判断は、すべてコンパイラが担います。

• ナビゲーションのアンカー — すべてのナビゲーションリンクは、本物のセクションを指します。無効なアンカーは起こりえません。コンパイラが、すべての #href を実際のセクションIDと照合します。
• コントラストの安全性 — 背景に対する文字のコントラストが検査され、WCAG AA（4.5:1）が保証されます。AIが配色を選び、コンパイラが読みやすさを保証します。
• 背景の交互配置 — 隣り合う2つのセクションが同じ背景色になることはありません。コンパイラが、ベースとセカンダリの面を自動で交互に配置して、視覚的なリズムを生みます。
• 連絡先の正規化 — 電話番号は tel: リンク用にE.164形式へ整えられ、WhatsAppの窓口は自動検出され、営業時間や住所は整理されます。すべての連絡先が、本物のクリックできるリンクとして機能します。
• フォントの読み込み — Google Fontsは、preconnectとdisplay-swapつきで読み込まれます。壊れたfont-faceも、レイアウトのずれもありません。
• レスポンシブなレイアウト — すべてのブロックが、モバイル、タブレット、デスクトップのブレークポイントで正しく表示されます。ブレークポイントを選ぶのはAIではなく、コンパイラが強制します。
• フッターとナビゲーションの補完 — AIがフッターやナビゲーションを省略した場合（トークンの節約になります）、コンパイラが存在するセクションから自動で作ります。最終的な出力に欠けるものはありません。

なぜ重要か：速さと決定論

速さ

AIが生のHTMLではなく構造化データを作るので、出力は劇的に小さくなります。ページ全体のHTMLを生成するには、LLMの出力が15,000〜25,000トークン必要です。同じサイトのSiteSpecなら4,000〜6,000トークンで済み、3〜4分の1に減ります。これがそのまま、生成の速さ（サイト全体で90秒以内）と、コストの低さにつながります。

決定論

コンパイラは純粋な関数です。同じSiteSpecを渡せば、必ず同じHTMLを出力します。これには次の意味があります。

• 編集が安全です。 ビジュアルエディタでセクションの見出しを変えても、変わるのはそのセクションだけです。コンパイラが仕様を再描画しても、サイトのほかの部分はまったく同じです。連鎖的な副作用はありません。
• 品質が保証されます。 コントラスト、アンカー、連絡先の書式、フォントの読み込み。そのすべてが、ときどきではなく、毎回の生成で正しくなります。
• テストができます。 決定論的なエンジンは、体系的に評価できます。色のコントラスト、アンカーの整合性、ブロックの多様性、生成ごとのデザインのばらつきについて、自動チェックを実行しています。

制約のなかの創造性

直感に反する発見があります。制約は、AIをより創造的でなくするどころか、より創造的にします。LLMが定型的なHTMLやCSSを書く作業から解放されると、トークンの予算のすべてを、本当に大切な判断、つまりセクションの選択、コンテンツの戦略、デザインの方向性、色彩理論に使えます。エンジニアリングの出力が引き受けられているからこそ、創造的な出力がよくなるのです。

プレイブックの仕組み

コンパイラは、ブロックの描画方法を固定で書き込んではいません。代わりにプレイブック（Playbook）を受け取ります。これは、ブロックライブラリ（各セクションの種類をHTML/CSSにどう描画するか）、デザイン解決の仕組み（配色とタイポグラフィをどう決めるか）、ベースのスタイルシートを定義するモジュールです。

プレイブックを入れ替えると、同じSiteSpecがまったく別のビジュアル言語で描画されます。エンジンは同じで、ブロックが変わるのです。これがForgeを拡張しやすくしている理由です。新しいセクションの種類、新しいデザインの方向性、新しい描画戦略を、コンパイラの中核に手を入れずに加えられます。

現在、サイト生成用のプレイブックには、ヒーローセクションやサービス一覧から、統計バンド、ギャラリー、FAQ、チームのグリッド、マーキー、予約のCTAまで、26種類以上のブロックが含まれています。AIは、ビジネスの種類とコンテンツに応じてこのライブラリから選び、コンパイラがピクセル単位の精度で描画します。

Forgeはどう生まれたか

Forgeは、壮大な計画から始まったわけではありません。始まりは試作品でした。手書きのJSON仕様を受け取ってHTMLに描画する、compile.mjs という1つのファイルです。問いはシンプルでした。ブロックを自分たちで定義し、AIには内容だけを埋めてもらったら、生のLLMのHTMLよりよい結果になるだろうか？

なりました。劇的によくなりました。試作品は、理髪店のサイトを、完璧なコントラスト、機能するナビゲーション、適切なフォントの読み込み、まとまりのあるダークとゴールドの雰囲気で描画しました。しかも、同等のHTMLのほんの一部の大きさのJSON仕様だけで。

そこから、アーキテクチャが形になっていきました。

1. 試作品は、型つきでフレームワークに依存しないエンジンになりました。ReactにもNext.jsにもSiteDropの内部にも依存せず、どのJavaScriptランタイムからでも読み込めます。
2. 固定で書かれていたブロックの描画は、差し替え可能なプレイブックの仕組みになりました。各プレイブックが、独自のブロック、デザイントークン、CSSを定義します。
3. LLMとの連携は、生のHTML出力から、構造化されたツール利用へ移りました（SiteSpecのスキーマがそのままツールのスキーマで、出力の形を制約しながら、モデルに何を作るかを教えます）。
4. 自己説明型のスキーマが、従来のシステムプロンプトに取って代わりました。スキーマの説明が各項目の意味をAIに教えるので、「文法」はほんの数行で済みます。
5. 品質のチェック、つまりコントラストの検査、アンカーの照合、背景の交互配置、連絡先の正規化が、コンパイラに組み込まれました。任意の後処理ではなく、毎回の生成で必ず実行されます。

その結果、できあがったのは、プロバイダーに依存せず（Claude、GPT、Gemini、DeepSeek、xAIなど、構造化出力に対応するどのモデルでも動作）、フレームワークに依存せず（単体のパッケージとして取り出せる）、決定論的な（同じ仕様なら、常に同じHTML）エンジンです。

あなたにとっての意味

SiteDropをお使いなら、サイトを生成するとき、Forgeはすでに動いています。何か特別な操作は必要ありません。変わるのは、出力の品質、速さ、一貫性です。

• 生成が速くなります — AIの出力が3〜4分の1になるので、サイトは90秒以内に生成されます。
• 品質が安定します — どの生成でも、コントラストが正しく、ナビゲーションが機能し、フォントが適切に読み込まれ、連絡先が整って表示されます。
• デザインがより多彩になります — AIは、26種類以上のブロック、4種類以上のデザインの型、豊富なタイポグラフィの組み合わせから選びます。理髪店には暗く縦長の雰囲気、歯科医院にはすっきりした雑誌のような雰囲気、高級レストランには上質なセリフ体の仕上げが与えられます。
• 編集がより安全になります — ビジュアルエディタはSiteSpecを書き換えてコンパイラで再描画するので、変更は予測可能で、副作用がありません。

Forgeのこれから

コンパイラのアーキテクチャは、私たちが作るすべてのものの土台です。エンジンが仕様で動くので、新しい機能は、新しいブロックの種類、新しいプレイブック、新しいデザイントークンのいずれかであり、生成パイプラインの作り直しではありません。これが、分離の力です。AIは決めるのがうまくなり、コンパイラは描画するのがうまくなり、両者はそれぞれ独立して向上します。

この2段階のパターン、つまり意図はAIが、実行はコンパイラが担う形こそが、これからウェブアプリケーションが作られていく方法だと私たちは考えています。1ページのウェブサイトだけでなく、複数ページのアプリケーション、ダッシュボード、インタラクティブな体験も同じです。AIが、何が存在すべきかを記述します。コンパイラが、それが動くことを保証します。