0xKyosuke Blog
AI Website Clonerの設計思想がヤバい — ツールより学ぶべきマルチエージェントパターン

AI Website Clonerの設計思想がヤバい — ツールより学ぶべきマルチエージェントパターン

2週間で★2,000超え。でもツール自体より設計思想が本体

ai-website-cloner-templateっていうリポジトリが話題になってるわ。URLを指定するだけで、Claude CodeがChrome MCP(ブラウザ自動操作)でサイトを解析して、ピクセルパーフェクトなクローンをNext.jsで自動生成するってもの。

2週間で★2,170。勢いはすごい。

ただ、正直に言うわ。このプロダクトの一番の価値は、ツール自体じゃなくて設計思想にある。Claude Codeのマルチエージェント機能をどう使い倒すかのパターン集として読むと、めちゃくちゃ学びが多い。

何をするツールなのか

5フェーズの自動パイプラインでWebサイトをクローンする:

  1. 偵察(Reconnaissance) — スクリーンショット撮影、デザイントークン抽出、インタラクション調査
  2. 基盤構築(Foundation) — フォント・カラー・グローバルCSS設定、アセットのダウンロード
  3. 仕様書作成getComputedStyle()で正確なCSS値を抽出し、セクションごとに詳細な仕様書を生成
  4. 並列ビルド — 複数のビルダーエージェントをgit worktreeで並列に走らせて各コンポーネントを構築
  5. 統合 & ビジュアルQA — worktreeをマージし、元サイトとの比較差分チェック

技術スタックはNext.js 16 + React 19 + shadcn/ui + Tailwind CSS v4。再現するのはフロントエンドの見た目と動的なふるまい(スクロールアニメ、ホバー、タブ切替、レスポンシブ)まで。バックエンドやAPI、認証ロジックは対象外。つまりガワだけ

正しい用途

  • デザインリニューアルの出発点 — 既存サイトをクローンしてからリファクタリング。ゼロから書き直すより速い
  • レガシーサイトのモダン化 — 古いHTMLベタ書きサイトをNext.js+Tailwindに自動変換
  • フロントエンド学習 — 好きなサイトのクローンを作って「プロはこう実装してるのか」を学ぶ
  • マルチエージェント設計パターンの参考実装 — これが一番の価値だとアタシは思ってる

アホな用途

「スクレイピングに使える!」とか言ってる人がいるみたいだけど、バッカじゃないの。

これはサイトの見た目をNext.jsで再構築するツールであって、データを抜くツールじゃないのよ。スクレイピングしたいならBeautiful SoupやPlaywrightを使えばいい話で、サイト丸ごとクローンするのはオーバースペックもいいところ。ツールの本質を理解してない典型ね。

あと、クローンしたサイトをそのまま公開するのも当然アウト。MITライセンスはこのツール自体のライセンスであって、クローン先のコンテンツの著作権を許諾するものじゃないから。

設計思想の深掘り — ここが本題

現場監督パターン(Foreman Pattern)

親エージェント(オーケストレーター)は「現場監督」として振る舞う。サイト全体を調査して、セクションごとに仕様書を書いて、ビルダー(子エージェント)をgit worktreeで並列に派遣する。

ポイントは全部調査してから一括dispatchじゃなくて、調査しながら逐次dispatchするパイプライン方式ってこと。SKILL.mdの中では「foreman walking the job site(現場を歩く現場監督)」と表現されている。

ただし、これが有効なのはセクション間の依存関係が薄い場合に限る。Webサイトのクローンは、ヘッダー、ヒーロー、フィーチャーセクション、フッターが互いにほぼ独立してるから成立する。だから「共通デザイントークンやグローバルCSSは最初に順次的に確定させる(Foundation フェーズ)」という例外もちゃんと設けている。

依存関係が複雑なタスクに安易に適用すると手戻り地獄になるから、その見極めが現場監督の腕の見せどころってわけ。

仕様書駆動(Design by Contract)

一番核心的な設計思想がこれ。各コンポーネントに対して docs/research/components/<name>.spec.md という詳細な仕様書を先に書いてからビルダーにdispatchする。

仕様書に含まれる情報:

  • DOM構造
  • getComputedStyle()で取得した実測のCSS値(「text-lgっぽい」は禁止)
  • 状態遷移の定義(ホバー、クリック、スクロール時のCSS変化、transition設定)
  • レスポンシブの差分(1440px / 768px / 390px)
  • 使用するアセットのローカルパス
  • テキスト内容(丸ごと)

そしてこの仕様書をビルダーに渡すとき、プロンプトにインライン展開する。「このファイル読んで」とは絶対に言わない。ビルダーが外部ファイルを参照する必要をゼロにするのが鉄則。

なぜか? 子エージェントはコンテキストがゼロからスタートする。曖昧な部分があると推測するしかなくなり、品質が落ちる。だから推測の余地をゼロにする精度が仕様書に要求される。ソフトウェアエンジニアリングの「契約による設計(Design by Contract)」の考え方がマルチエージェントシステムに適用されてるわけ。

150行ルール

ビルダーに渡すspecの内容が約150行を超えたら、そのセクションは複雑すぎるから分割しろ、というメカニカルなルール。

“If a builder prompt exceeds ~150 lines of spec content, the section is too complex for one agent. Break it into smaller pieces. This is a mechanical check — don’t override it with ‘but it’s all related.’”

「関連してるから1つでいける」は明示的に禁止されている。主観的な判断を排除して、機械的に分割を強制する。シンプルだけど効果的な基準よね。

アンチパターン集(12個の地雷)

実際に踏んだ失敗から導き出された禁止事項が12個列挙されている。いくつか紹介するわ:

  • スクロール駆動とクリック駆動の取り違え — 最も高コストなミス。スクロールで動くものをクリックUIとして実装すると全面書き直し
  • CSS値の推測 — 「text-lgっぽい」は禁止。getComputedStyle()の実測値を使え
  • デフォルト状態だけ抽出 — タブが3つあるなら3つ全部の内容を抽出しろ
  • レスポンシブ確認のスキップ — デスクトップだけ見てモバイルが壊れるパターン
  • ビルダーから外部ドキュメントを参照させる — 必要な情報はすべてインライン展開が鉄則
  • モノリシックコミット — インクリメンタルに進めるのがパイプラインの意義

これらは「やるな」と書いてあるだけじゃなくて、なぜダメなのか(コスト) まで説明されてるのがいい。過去の失敗を組織知として定着させる姿勢が見える。

CLAUDE.mdの参照チェーン

CLAUDE.md → AGENTS.md → INSPECTION_GUIDE.md / TARGET.md と3段階の参照構造でコンテキストを階層化している。全部1ファイルに詰め込まないで、関心事ごとにファイルを分けて @ファイル名 で参照する設計。

これは地味だけど重要な工夫で、CLAUDE.mdが肥大化するとそれ自体がコンテキストを圧迫するし、メンテナンスもしにくくなる。

実務への応用 — プランモード+タスク分割+dispatch

この設計思想、Webサイトのクローン以外にも応用できる。特に「独立した複数の機能変更を同時並行で進める」場面で威力を発揮する。

具体的には、こんなワークフローが考えられる:

  1. プランモードで設計 — 全体の方針を固める
  2. プランをドキュメントに残す — 子エージェントに渡せるレベルの詳細さで
  3. 独立したタスクに分割 — 依存関係のないタスクを識別する
  4. 各タスクをプロンプト化して子エージェントにdispatch — worktreeで隔離して実行

ここで仕様書駆動の思想が活きる。プランモードの内容をドキュメントとして残しているなら、それをベースにタスクを切り分けて、各タスクの仕様をプロンプトとしてインライン展開して子エージェントに渡す。

並列でやるか順次でやるかは、タスク間の依存関係で決める。DBスキーマ変更→API実装→UI実装みたいな依存チェーンがあれば順次。設定画面の改修とダッシュボードのグラフ追加みたいに独立していれば並列。

副次的なメリットもある:

  • 各タスクのスコープが明確になるから品質が安定する
  • メインのコンテキストが汚れない — 子エージェントが独立したコンテキストで作業するから
  • 失敗しても影響範囲がそのタスクだけで済む

まとめ

ai-website-cloner-templateは、サイトクローンツールとしてではなく、Claude Codeのマルチエージェント設計パターンの教科書として読むべきリポジトリ。

学ぶべきポイント:

  • 現場監督パターン — 調査しながら逐次dispatchするパイプライン方式(ただし依存関係の薄いタスクに限る)
  • 仕様書駆動 — 子エージェントに推測させない、契約書レベルの仕様を書く
  • 150行ルール — 主観を排除したメカニカルな分割基準
  • アンチパターン集 — 失敗を組織知として定着させる
  • 参照チェーン — CLAUDE.mdの肥大化を防ぐ階層化

道具の使い方より、道具の作り方を学ぶ方がずっと価値があるわよ。