AIによるWebサイト生成
指示からWebサイトのコードと成果物を生成する仕組み。公開されている実装3件を同じ観点で比較した構成です。
公開実装 3 件を、各リポジトリの固定コミット（コミット日 2026-01-21〜2026-08-30）で見ています。根拠の一覧へ
- Claude Code指示文あり・実行は未検証
- Codex未対応
完成後にできること
この構成を作ると、実データで確認された範囲で次のことができます。
- 1指示の受け取り
- 2モデル・プロバイダ設定
- 3コード生成
- 4成果物の取り出し
- 5状態の永続化
- 6失敗の処理
システム構成
役割による層（入力→処理→出力）。実データで観測された要素のみ。
接続線は構成レイヤー（役割の流れ）を示します。個々のツール間の正確な接続は、Evidence で確認できた場合のみ別途表示します。
公開実装の画面例
この構成の根拠になった公開実装のうち、実際の画面を確認できたものです。Blueprint そのものの完成画面ではありません。
公開実装の画面使用ツール / 始める前に必要なもの
観測された実装と Blueprint の要件です。
- 指示の受け取り
REST と WebSocket の2入口・prompt / model / budget_policy / strategy / direction_id / inherits_from / prompt か messages を必須とし、provider / model / tools / context 等を同じ入口で受け取る / 用途別プロンプト定義の集約（会話 / コード生成 / プロンプト強化）
- モデル・プロバイダ設定
3層のモデル解決（リクエスト単位 → エージェント設定 → 全体既定） / プロバイダをリクエストごとに選択し送信形式を解決・独自エンドポイントは外部URLのみ許可 / 単一モデルに対する用途別3セッションと応答形式の分離
- コード生成
役割エージェントによる生成（生成→レビューのループ内） / 生成 API（画像生成とは別エンドポイント） / サーバ送信イベントで逐次返すコード生成
- 成果物の取り出し
実プロジェクトのディレクトリ・git チェックポイント・ZIP 書き出し / 出力ランタイム8種から選択（static / handlebars / react / preact / svelte / vue / python / lua） / ブラウザ内サンドボックスでの編集・プレビューと package.json 付き ZIP 書き出し
- 状態の永続化
SQLite 9テーブル（projects / pages / versions / messages ほか） / 仮想ファイルシステム上のチェックポイント / users と workspace(messages, fileData) の2テーブル
- 失敗の処理
拒否応答の検出と再試行ヘルパ / ツール呼び出し JSON の切断検出と修復 / 蓄積全文の JSON 解釈に失敗した場合のエラー返却
- 生成の調整
生成とレビューを束ねる反復ループ（AsyncLoopGroup） / AgentLoop / Coordinator / ToolExecutor を束ねる facade
- 役割の分割
pm / designer / developer / reviewer / critique ＋ 専門8種 / agent / coordinator / multi-agent-orchestrator / tool-registry / write-scope の分割
- 出力形式の制約
レビュー出力を ReviewFeedback スキーマに強制 / プロンプトが応答スキーマを指定（projectTitle / explanation / files / generatedFiles）
- 画像・アセット生成
image 専門エージェント（視覚アセットの生成と管理） / 画像生成 API（modalities に image を渡すプロバイダ拡張）
- 生成物の検証
ブラウザ自動化による決定的な検証ゲート（LLMレビューは覆せない） / テストシナリオの実行と、結果をモデルに判定させる判定器
- 再生成の経路
最大反復数と承認閾値でループを制御 / プレビュー実行時エラーを完了判定に吸い上げ・一時停止と再開
- 生成物の計測
経路単位の監査（絶対下限＋前版からの後退幅） / 公開単位（deployment）ごとの計測 API・サーバ側で有効化を検証
- 生成物の公開
静的サイトへコンパイルし外部ホスティングのリポジトリへ commit
必須（最初に用意）
- ・指示の受け取り
- ・モデル・プロバイダ設定
- ・コード生成
- ・成果物の取り出し
- ・状態の永続化
- ・失敗の処理
後から追加
- ・生成の調整
- ・役割の分割
- ・出力形式の制約
- ・画像・アセット生成
- ・生成物の検証
- ・再生成の経路
- ・生成物の計測
必要になったら
- ・生成物の公開
なぜこの構成なのか
なぜモデル設定が核か：3実装すべてが「どのモデルをどう選ぶか」を独立した関心事として実装していた（3層解決 / プロバイダ選択 / 用途別セッション）。
なぜ永続化が核か：3実装すべてが状態を持っていた。その場限りの生成器ではない。
なぜ失敗処理が核か：3実装すべてがモデル出力の失敗を明示的に扱っていた（拒否検出 / JSON切断の修復 / 解釈失敗の返却）。素朴に作ると抜ける箇所。
なぜ成果物の取り出しが核か：3実装すべてが「何が手に入るか」を実装していた（実プロジェクト＋ZIP / ランタイム選択 / サンドボックス＋ZIP）。
検証は核ではない：3実装中2件で観測。しかも方式が違う（ブラウザ自動化の決定的ゲート / モデル判定）。共通の作法はまだ言えない。
NOW — 3件すべてで観測された部分
指示の受け取り・モデル設定・生成・成果物の取り出しに、状態の永続化と失敗処理が全体にかかる形。3件すべてで観測されました。
- 指示の受け取り
REST と WebSocket の2入口・prompt / model / budget_policy / strategy / direction_id / inherits_from / prompt か messages を必須とし、provider / model / tools / context 等を同じ入口で受け取る / 用途別プロンプト定義の集約（会話 / コード生成 / プロンプト強化）
- モデル・プロバイダ設定
3層のモデル解決（リクエスト単位 → エージェント設定 → 全体既定） / プロバイダをリクエストごとに選択し送信形式を解決・独自エンドポイントは外部URLのみ許可 / 単一モデルに対する用途別3セッションと応答形式の分離
- コード生成
役割エージェントによる生成（生成→レビューのループ内） / 生成 API（画像生成とは別エンドポイント） / サーバ送信イベントで逐次返すコード生成
- 成果物の取り出し
実プロジェクトのディレクトリ・git チェックポイント・ZIP 書き出し / 出力ランタイム8種から選択（static / handlebars / react / preact / svelte / vue / python / lua） / ブラウザ内サンドボックスでの編集・プレビューと package.json 付き ZIP 書き出し
- 状態の永続化
SQLite 9テーブル（projects / pages / versions / messages ほか） / 仮想ファイルシステム上のチェックポイント / users と workspace(messages, fileData) の2テーブル
- 失敗の処理
拒否応答の検出と再試行ヘルパ / ツール呼び出し JSON の切断検出と修復 / 蓄積全文の JSON 解釈に失敗した場合のエラー返却
NEXT — 3件中2件で観測された部分
調整・役割分割・出力契約・検証・再生成・アセット生成・計測。必須ではなく、実装ごとの選択として観測されました。
- 生成の調整
生成とレビューを束ねる反復ループ（AsyncLoopGroup） / AgentLoop / Coordinator / ToolExecutor を束ねる facade
- 役割の分割
pm / designer / developer / reviewer / critique ＋ 専門8種 / agent / coordinator / multi-agent-orchestrator / tool-registry / write-scope の分割
- 出力形式の制約
レビュー出力を ReviewFeedback スキーマに強制 / プロンプトが応答スキーマを指定（projectTitle / explanation / files / generatedFiles）
- 画像・アセット生成
image 専門エージェント（視覚アセットの生成と管理） / 画像生成 API（modalities に image を渡すプロバイダ拡張）
- 生成物の検証
ブラウザ自動化による決定的な検証ゲート（LLMレビューは覆せない） / テストシナリオの実行と、結果をモデルに判定させる判定器
- 再生成の経路
最大反復数と承認閾値でループを制御 / プレビュー実行時エラーを完了判定に吸い上げ・一時停止と再開
- 生成物の計測
経路単位の監査（絶対下限＋前版からの後退幅） / 公開単位（deployment）ごとの計測 API・サーバ側で有効化を検証
LATER — 3件中1件で観測された部分
生成したサイトの公開。1件でしか観測されていないため、共通の構成には含めていません。
- 生成物の公開
静的サイトへコンパイルし外部ホスティングのリポジトリへ commit
この Blueprint では規定しない
観測が割れている、または観測していない事項。決めないことを明示します。
- 生成サイトの公開先を決めること
- 役割別エージェントを必須にすること
- 検証方式を1つに決めること
FAQ
根拠（なぜこの構成か／実例限定の理由）から生成しています。
なぜ「モデル・プロバイダ設定」がこの構成に必要か？
なぜモデル設定が核か：3実装すべてが「どのモデルをどう選ぶか」を独立した関心事として実装していた（3層解決 / プロバイダ選択 / 用途別セッション）。（3/3 システムで確認・確度: 確認済み）
根拠:jhd3197 ↗（AgentSite の観測時点のソースを開く（コミット 758d566）・新しいタブで開く）o-stahl ↗（OSW Studio の観測時点のソースを開く（コミット 7724d28）・新しいタブで開く）Ratna-Babu ↗（Ai-Website-Builder の観測時点のソースを開く（コミット 503f119）・新しいタブで開く）
なぜ「状態の永続化」がこの構成に必要か？
なぜ永続化が核か：3実装すべてが状態を持っていた。その場限りの生成器ではない。（3/3 システムで確認・確度: 確認済み）
根拠:jhd3197 ↗（AgentSite の観測時点のソースを開く（コミット 758d566）・新しいタブで開く）o-stahl ↗（OSW Studio の観測時点のソースを開く（コミット 7724d28）・新しいタブで開く）Ratna-Babu ↗（Ai-Website-Builder の観測時点のソースを開く（コミット 503f119）・新しいタブで開く）
なぜ「失敗の処理」がこの構成に必要か？
なぜ失敗処理が核か：3実装すべてがモデル出力の失敗を明示的に扱っていた（拒否検出 / JSON切断の修復 / 解釈失敗の返却）。素朴に作ると抜ける箇所。（3/3 システムで確認・確度: 確認済み）
根拠:jhd3197 ↗（AgentSite の観測時点のソースを開く（コミット 758d566）・新しいタブで開く）o-stahl ↗（OSW Studio の観測時点のソースを開く（コミット 7724d28）・新しいタブで開く）Ratna-Babu ↗（Ai-Website-Builder の観測時点のソースを開く（コミット 503f119）・新しいタブで開く）
なぜ「成果物の取り出し」がこの構成に必要か？
なぜ成果物の取り出しが核か：3実装すべてが「何が手に入るか」を実装していた（実プロジェクト＋ZIP / ランタイム選択 / サンドボックス＋ZIP）。（3/3 システムで確認・確度: 確認済み）
根拠:jhd3197 ↗（AgentSite の観測時点のソースを開く（コミット 758d566）・新しいタブで開く）o-stahl ↗（OSW Studio の観測時点のソースを開く（コミット 7724d28）・新しいタブで開く）Ratna-Babu ↗（Ai-Website-Builder の観測時点のソースを開く（コミット 503f119）・新しいタブで開く）
なぜ「生成物の検証」がこの構成に必要か？
検証は核ではない：3実装中2件で観測。しかも方式が違う（ブラウザ自動化の決定的ゲート / モデル判定）。共通の作法はまだ言えない。（2/3 システムで確認・確度: ほぼ確実）
根拠:jhd3197 ↗（AgentSite の観測時点のソースを開く（コミット 758d566）・新しいタブで開く）o-stahl ↗（OSW Studio の観測時点のソースを開く（コミット 7724d28）・新しいタブで開く）
「生成物の公開」はなぜ後回し/限定なのか？
実例が限定的なためです（1/3 システムでのみ確認・推定）。
この目的に対して証拠が限定的な範囲は？
生成物の公開先（3実装中1件） / 検証の作法（3実装中2件・方式が不一致） / 役割分割の要否（3実装中2件） / 生成物の品質や性能（観測していない） / 運用実績（公開された運用実績は確認していません）（標準構成ではありません。レビューした3つの公開実装で共通して観測された部分と、実装ごとに分かれた部分を分けて示しています。）
根拠（一次ソース・証拠レコード）
公開実装 = 3 件。証拠レコード = 33。両者は別物です。
リンク先は Plentro が観測した時点のソース（コミット固定）です。その後の更新は含みません。
- AgentSite
Builder: jhd3197 · github_repository
観測コミット 758d566（2026-08-28）
観測時点のソースを開く ↗（AgentSite の観測時点のソースを開く（コミット 758d566）・新しいタブで開く） - OSW Studio
Builder: o-stahl · github_repository
観測コミット 7724d28（2026-08-30）
観測時点のソースを開く ↗（OSW Studio の観測時点のソースを開く（コミット 7724d28）・新しいタブで開く） - Ai-Website-Builder
Builder: Ratna-Babu · github_repository
観測コミット 503f119（2026-01-21）
観測時点のソースを開く ↗（Ai-Website-Builder の観測時点のソースを開く（コミット 503f119）・新しいタブで開く）
この構成を出発点に、自分の条件で選ぶ。
登録すると、条件を入力して構成候補を確認できます。Claude Code を接続すれば、 あなたの構成を検出し、実在 Builder の Claude Code 構成と比べられます。
- あなたが渡すもの
- Claude Code に指示文を貼り、内容を自分で確認して承認すると、構成の一覧（ツール / MCP / スキル / コマンド / フックの種類と数）だけが送られます。
- 送られないもの
- ソースコード本文・APIキー等の秘密情報・.env・秘密鍵・git 認証情報・会話履歴・端末内の絶対パス。 これらは受信側で構造的に拒否・除去されます。
- 返ってくるもの
- あなたの構成の検出結果と、実在 Builder の Claude Code 構成との差分、そこから決まる次にやること 1 つ。