AIコーディングエージェントで既存サイトをまるごと解析し、モダンなNext.jsコードとして再構築する — いわば「AIエージェントによるサイトクローン」を、テンプレート化された一連のワークフローとして実装したOSSが ai-website-cloner-template です。
「WordPressやWebflowで運用してきたサイトをそろそろNext.jsに載せ替えたい」「ソースコードが散逸したまま運用が続いている本番サイトを、生きているURLから再構築したい」といった課題は、実装工数の見積もりが難しく、着手判断そのものが止まりがちです。AIコーディングエージェントを部分的に導入している開発現場でも、「単発のコード生成」から一歩踏み込んだ用途になると、どこから手を付ければよいか判断がつかないことが少なくありません。
本記事では、ai-website-cloner-template の仕組み・対応するAIエージェント・類似OSSとの違いを、公開ドキュメントとリポジトリメタデータの一次情報のみに基づいて整理します。動作検証は行わず、あくまで「初見エンジニアが採用可否を短時間で判断するための材料」を提示することを目的としています。
なお、本記事執筆時点(2026年7月)のリポジトリメタデータは archived=false(アーカイブされていない)/fork=false(フォークではなく本家)/disabled=false/visibility=public であり、活発にメンテナンスされている本家リポジトリです。数値はすべて GitHub API /repos/JCodesMore/ai-website-cloner-template から取得した値と一致させています。
ai-website-cloner-templateとは
AI Website Cloner Template(リポジトリ名: ai-website-cloner-template)は、AIコーディングエージェントを使って任意のWebサイトをリバースエンジニアリングし、Next.js 16 を土台としたクリーンなコードベースとして再構築するためのテンプレートリポジトリです。位置付けとしては、「AIエージェントによるサイトクローン」を再現可能なテンプレートとして提供するOSSと言い換えることができます。
公式の一行説明は「Clone any website with one command using AI coding agents(1つのコマンドで、AIコーディングエージェントを使って任意のサイトをクローンする)」です。単発でスクリーンショットからコードを生成するタイプのツールとは異なり、対象URLを渡すとエージェントが自律的にサイトを調査し、デザイントークンとアセットを抽出し、コンポーネント仕様を書き出し、並列でビルダーを走らせて再構築する、という一連のパイプラインが組まれている点が特徴です。
詳細は公式リポジトリ(JCodesMore/ai-website-cloner-template)を参照してください。
リポジトリ基本情報
本記事執筆時点(2026年7月)の一次情報(GitHub API)は以下のとおりです。
項目 | 値 |
|---|---|
owner/name | JCodesMore/ai-website-cloner-template |
description | Clone any website with one command using AI coding agents |
主要言語 | TypeScript |
ライセンス | MIT |
スター数 | 25,442 |
フォーク数 | 3,583 |
最終 push | 2026-07-04 |
visibility | public |
archived / fork / disabled | すべて false(本家・アーカイブなし・無効化なし) |
スター数25,442・フォーク数3,583は本記事執筆時点の値で、GitHub API の実測値と一致させています。最終 push が本記事執筆当日である点、archived=false である点から、メンテナンスは活発と判断できます。
何を解決するのか — 3つの典型ユースケース
READMEの「Use Cases」セクションでは、3つの典型ユースケースが提示されています。読者が自分の案件と照らして採否を判断するうえで、この3分類は有効な起点になります。
既存CMS/レガシースタックからのNext.js移行
WordPress・Webflow・Squarespaceなどで運用してきたサイトを、Next.js 16 の App Router とTypeScript strictの構成に載せ替えたいケースです。フロントエンドのビジュアルとインタラクションをできる限り忠実に保ちつつ、モダンなコンポーネント設計に落とし直すことが目的になります。
ソースコード紛失時のライブサイトからの再構築
「サイトは公開されているがリポジトリが見つからない」「開発を担当したベンダーとの関係が切れ、コードにアクセスできない」といった状況で、公開されているURLだけを頼りにコードベースを復元するユースケースです。ライブサイトのDOMとスタイルを一次情報として扱う設計であるため、この用途との相性が想定されています。
学習用途(プロダクションサイトの分解学習)
実運用サイトのレイアウト・アニメーション・レスポンシブ挙動を、コンポーネント仕様と実際のコードとして分解学習したいケースです。生成物が shadcn/ui と Tailwind CSS v4 に沿った構造で出力されるため、モダンな設計パターンの参照素材としても利用できる想定です。
裏を返せば、これらのユースケースから外れる領域(例: 動的な業務ロジックの再現、バックエンドAPIの復元、ログイン後の会員機能の再現)は本テンプレートの想定外です。この点はのちほど「導入前に確認すべきポイント」で改めて整理します。
5フェーズパイプラインで既存サイトをコンポーネント化する仕組み
ai-website-cloner-template の中核は、READMEの「How It Works」セクションで説明される5フェーズパイプラインです。各フェーズで「何を入力に」「何を出力するか」「テンプレートが決めていること」「AIエージェントが判断すること」が明確に分かれています。詳細は公式リポジトリの README.md を参照してください。
Reconnaissance(偵察・抽出)
対象URLに対してスクリーンショットを取得し、デザイントークン(色・タイポグラフィ・間隔など)を抽出します。あわせてスクロール・クリック・ホバー・レスポンシブといったインタラクションを網羅的に観測します。ここで得られた情報は後段のコンポーネント仕様書き出しの一次情報になります。
Foundation(フォント・色・グローバルCSSの整備)
抽出したデザイントークンをもとに、フォント・色・グローバルCSSを更新し、必要なアセット(画像・動画・SVG・OG画像・favicon など)をダウンロードします。ここでは「モダンスタックとして整合の取れた土台」を先に用意することで、後続の並列ビルドが独立して走れる状態に整えるという発想です。
Component Specs(コンポーネント仕様の書き出し)
docs/research/components/ 配下に、各コンポーネントの詳細仕様が書き出されます。仕様には getComputedStyle() で観測された実測値、複数ステートのコンテンツ、インタラクションモデル、レスポンシブブレークポイントごとの挙動、アセットパスがインラインで含まれます。設計原則として「推測なし(No guessing)」が掲げられており、AIエージェントが後段で憶測に頼らず実装できるだけの情報量を、ここで確定させることが目的です。
Parallel Build(git worktree による並列ビルド)
各コンポーネント/セクション単位のビルダーエージェントが、git worktree上の独立ブランチで並列に起動されます。ビルダーエージェントには先に書き出したコンポーネント仕様が渡され、実装が並列に進みます。並列化と worktree による分離は、コンフリクトを最小化しつつスループットを稼ぐための設計です。
Assembly & QA(統合と視覚的な整合検証)
各worktreeをマージしてページを結線し、オリジナルサイトとの visual diff(視覚的差分)で整合を検証します。オーケストレーター役のエージェントがフルコンテキストを保持したままマージコンフリクトを解決する構成が README で示されており、単なる並列生成ではなく「最終的な視覚整合まで含めて自動化する」という設計思想が読み取れます。
このパイプライン全体は「テンプレートが決めているもの(フェーズ構成・ディレクトリ規約・仕様書き出しの粒度)」と「AIエージェントが判断するもの(デザイントークンの解釈・コンポーネント分割・実装コード)」を分離しています。採用可否の判断では、この分担がプロジェクトのスタイル・レビュー体制と合うかが焦点になります。
対応するAIコーディングエージェントと推奨構成
本テンプレートは特定のLLM APIを内蔵せず、「利用者側のAIコーディングエージェントに実装を委任する」設計になっています。READMEには対応エージェントが列挙されており、日常的に使っているエージェントで動かせる可能性が高い点は採用判断において重要です。
対応エージェント一覧
READMEに記載されている対応エージェントは以下のとおりです(推奨構成として Claude Code の Opus 4.8 が明示されています)。
Agent | 位置付け |
|---|---|
Claude Code | Recommended(Opus 4.8) |
Codex CLI | Supported |
OpenCode | Supported |
GitHub Copilot | Supported |
Cursor | Supported |
Windsurf | Supported |
Gemini CLI | Supported |
Cline | Supported |
Roo Code | Supported |
Continue | Supported |
Amazon Q | Supported |
Augment Code | Supported |
Aider | Supported |
Claude Codeが推奨されている一方で、他エージェントも Supported として明示されているため、既存の開発フローに合わせて選択できます。
AGENTS.md を単一情報源とする設計
複数エージェントに同じ意図を持たせるために、本テンプレートは AGENTS.md をエージェント指示の単一情報源としています。詳細は公式リポジトリの AGENTS.md を参照してください。CLAUDE.md・GEMINI.md など各プラットフォーム向けの派生ファイルは、AGENTS.md を import する形で構成されており、内容の同期はスクリプト経由で行う想定になっています。
READMEに記載されている同期コマンドは以下のとおりです。
bash scripts/sync-agent-rules.sh
node scripts/sync-skills.mjs
出典: ai-website-cloner-template README
「エージェント指示は一箇所にまとめ、派生ファイルはスクリプトで再生成する」という設計は、複数プラットフォームを併用するチームで指示の差分が生まれにくくなるという利点があります。
出力される技術スタック
生成されるNext.jsプロジェクトの技術スタックは、README の「Tech Stack」セクションに明記されています。自社の技術スタックと合うかを判断する際の主要な観点は次のとおりです。
フロントエンド構成
- Next.js 16 —
App Router、React 19、TypeScript strict - shadcn/ui — Radix プリミティブ + Tailwind CSS v4
- Tailwind CSS v4 —
oklchデザイントークン - Lucide React — 既定アイコン(クローン時は抽出SVGに置換される想定)
Next.js 16 の App Router を前提としているため、Pages Router を維持したい既存プロジェクトへそのまま統合するには追加の作業が必要になります。また、Tailwind CSS v4 の oklch トークンが前提となる点は、既存の Tailwind CSS v3 プロジェクトと混在させる場合に注意が必要です。
生成されるディレクトリ構造
README に記載されているプロジェクト構造は以下のとおりです。
src/app/ # Next.js ルート
src/components/ # React コンポーネント(ui: shadcn primitives、icons.tsx: 抽出 SVG)
src/lib/utils.ts # cn() ユーティリティ
src/types/ # 型定義
src/hooks/ # カスタムフック
public/images/ # 抽出画像
public/videos/ # 抽出動画
public/seo/ # favicon / OG 画像
docs/research/ # 抽出出力・コンポーネント仕様
docs/design-references/# スクリーンショット
scripts/sync-agent-rules.sh # エージェント指示ファイルの再生成
scripts/sync-skills.mjs # /clone-website の全プラットフォーム再生成
AGENTS.md # エージェント指示(単一情報源)
CLAUDE.md # Claude Code 設定(AGENTS.md を import)
GEMINI.md # Gemini CLI 設定(AGENTS.md を import)
出典: ai-website-cloner-template README
docs/research/ にコンポーネント仕様が集約される構成であるため、生成物のコードだけでなく「AIエージェントに渡された仕様書き出し」も後から辿ることができます。レビューや監査の観点でも一定の可読性が担保される設計です。
類似リポジトリ・ツールとの棲み分け
同じ「AIでサイトをコード化する」というコンセプトを掲げるツールは複数存在します。ここでは初見エンジニアが選定判断を行う際に比較検討の対象となりやすい3つを取り上げ、ai-website-cloner-template との棲み分けを整理します。
screenshot-to-code との違い
abi/screenshot-to-code は、静止画スクリーンショットを入力として HTML / Tailwind / React / Vue のコードを生成する OSS です。単一画面・単発コンポーネントの生成を主用途としており、GPT-4V などのマルチモーダル LLM を内部で直接呼び出す構成です。
対して ai-website-cloner-template は、ライブURL(複数指定可)を入力に、生きたブラウザから DOM・getComputedStyle 値・レスポンシブ挙動を抽出し、マルチページかつ複数ブレークポイントに対応します。LLM 呼び出しは利用者側のエージェントに委ねる設計で、任意の対応エージェントで動作します。「1画面のスケッチをコード化したい」なら screenshot-to-code、「本番サイトを丸ごとコンポーネント化したい」なら ai-website-cloner-template、という粒度感の違いが選定の分岐点になります。
HTTrack との違い
HTTrack(公式サイト)は1998年から提供されている老舗のオフラインブラウザ/サイトミラーです。出力は HTML / CSS / 画像のディレクトリコピーであり、コンポーネント化・モダンフレームワークへの変換は行いません。ミニファイ済み CSS・フレームワーク由来の属性なども「そのまま」出力されます。
「オフラインで参照したい」「静的アーカイブを作りたい」用途では HTTrack が引き続き有力ですが、「モダンスタックへの移植」を目的とする場合は HTTrack では要件を満たせません。デザイントークンを oklch として抽出し、shadcn/ui + Tailwind CSS v4 の構造に落とし込むというアプローチは、ai-website-cloner-template のようなコンポーネント再構築型でなければ実現しにくい領域です。
v0 by Vercel との違い(比較参考)
v0 by Vercel は Vercel が提供する URL・画像からの React 生成 SaaS です。生成物は shadcn/ui + Tailwind を採用しており、この点は ai-website-cloner-template と共通しています。ただし SaaS であるため、「自社の AI エージェント環境で完結させたい」「機密性の高いプロジェクトで外部 SaaS に送信したくない」「既存の IDE ワークフローに組み込みたい」といった要件がある場合は選択肢から外れます。
ai-website-cloner-template は Claude Code や Cursor などのローカルエージェントで完結できる点で、ローカル完結を重視する組織との適合性が高くなります。
比較テーブル
観点 | ai-website-cloner-template | screenshot-to-code | HTTrack |
|---|---|---|---|
入力 | ライブ URL(複数可) | 静止画スクリーンショット | ライブ URL |
出力 | Next.js 16 コンポーネント(shadcn/ui + Tailwind v4) | HTML / Tailwind / React / Vue コード | HTML / CSS / 画像の静的ミラー |
AI 利用 | 利用者のエージェントに委任 | 内部で LLM を直接呼び出し | なし(AI 非使用) |
並列化 | git worktree での並列ビルド | なし | なし |
検証 | オリジナルとの visual diff | なし | なし |
対応ブレークポイント | レスポンシブ多点 | 単一画面 | HTML そのまま |
導入前に確認すべきポイント
ai-website-cloner-template を採用する前に、法的・技術的・運用的な観点で押さえておくべきポイントがあります。裏テーマである「採用可否の意思決定」に直結するため、READMEの記載内容と一次情報を整理します。
ライセンス・法的注意(禁止用途を含む)
ライセンスは MIT です(詳細は公式リポジトリの LICENSE を参照)。テンプレート自体は商用・非商用問わず利用可能ですが、READMEの「Not Intended For」セクションで以下の用途が明示的に想定外とされています。
- フィッシング・なりすまし
- 他者デザインの盗用(ロゴ・ブランド資産・オリジナルコピーは所有者に帰属)
- 利用規約違反(スクレイピングやコピーを禁じるサイトへの適用)
自社サイトや正規に権利を保有しているサイトを対象とするか、対象サイトの利用規約と権利関係を事前に確認したうえで運用する必要があります。
実行要件
READMEの Prerequisites セクションに以下が明記されています。
- Node.js 24+
- AIコーディングエージェント(前掲の対応一覧のいずれか)
Node.js 24+ は執筆時点で比較的新しめのバージョンであり、既存の CI/ローカル環境のバージョン管理と合わせる必要があります。加えて AI エージェントのトークン消費コスト(Claude Code の Opus クラスを推奨構成として使う場合は特に)が案件規模に応じて発生する点も、見積もりに含めておくべき要素です。
再現外の範囲
本テンプレートは「フロントエンドの視覚的・構造的な再構築」を対象としており、以下は再現外です。
- サーバサイドの業務ロジックやAPI
- 動的なコンテンツ生成(CMSデータ・DBデータ)
- ログイン後の会員機能・認証フロー
- 実データ(顧客情報・受発注データなど)
「フロントエンドをNext.jsに移植し、バックエンドは別途つなぎ直す」という前提であれば適合しますが、「バックエンドを含めた業務システム全体の移行」用途にはそのまま適用できません。この境界を事前にクライアントや社内関係者と揃えておくことが、案件のスコープ管理のうえで重要です。
話題性とコミュニティ
本記事執筆時点でスター数は 25,442、フォーク数は 3,583 に達しており、公開後の短期間で大きな注目を集めているリポジトリです。数値は GitHub API /repos/JCodesMore/ai-website-cloner-template の実測値と一致しています。スター数の推移は Star History で可視化できます。
コミュニティ面では、READMEから公式の Discord サーバー がリンクされており、質問・議論・情報収集の場として機能しています。導入時にハマりどころが出た際、公式ドキュメント以外の相談経路が用意されている点は、初見エンジニアが採用判断を行ううえでプラスに働く要素です。
archived=false・最終 push が本記事執筆当日であることから、メンテナンスは継続中と判断できます。導入判断において「メンテナンス継続性」は重要な要素であり、この点は本記事執筆時点ではプラス評価に働きます。
まとめ — こんな人に向いている/向いていない
ai-website-cloner-template は「AIコーディングエージェントを使って、既存サイトをNext.js 16のコンポーネント構造として再構築する」という一点に特化したOSSテンプレートです。5フェーズパイプライン・git worktree による並列ビルド・visual diff による整合検証まで含めた設計が組まれており、単発のコード生成ツールとは射程が異なります。
向いているケース
- WordPress/Webflow/レガシースタックから
Next.js 16+shadcn/ui+Tailwind CSS v4への移植を検討している - ソースコードにアクセスできない本番サイトを、公開URLから再構築したい
- 既に Claude Code・Cursor 等のAIコーディングエージェントを日常運用しており、ローカル完結の設計を選びたい
- モダンなコンポーネント設計の参照素材として、実運用サイトのコード化された分解結果を得たい
向いていないケース
- バックエンドAPI・業務ロジック・会員機能まで含めた移行を求めている
- Pages Router を維持したい、あるいは Tailwind CSS v3 を維持したい既存プロジェクトに統合したい
- 対象サイトの利用規約や権利関係が確認できておらず、法的リスクを許容できない
- SaaS で完結させたい、UIから操作したい(この場合は SaaS 型の別ツールが選択肢になる)
裏テーマ「初見エンジニアの意思決定支援」の観点で言えば、ai-website-cloner-template は「AI任せ」と「テンプレートの規約」の境界が明確に設計されている点が採用判断のしやすさに直結します。まずは公式リポジトリの README と AGENTS.md に目を通し、自プロジェクトの技術スタックと照らして採否を判断する流れが現実的です。



