Claude Fable 5.2の登場により、「1つのエージェントで製品一式をゼロから書く」ことが以前より現実的に聞こえるようになった。しかし、それが変えたのは、モデルが1回のタスクでどれだけの文脈を理解し、どれだけのコードを正しく修正できるかであって、ドメイン解決、ログイン認証、決済照合、コンテンツ管理画面、公開後の保守を誰が代行するかではない。この線引きこそが、AIコーディングエージェントとAIウェブサイトビルダーの分水嶺である。
一言でまとめると：AIコーディングエージェントは最大の自由度を与えるが、その代償としてエンジニアリングと運用の責任を自分で負う。AIサイト構築プラットフォームは自由度の一部を譲る代わりに、すでにつながった納品経路を提供する。 選び間違いのコストは通常、初日ではなく、公開後3か月目に現れる——コピーを変更できる管理画面、決済できるフロー、検索エンジンとAI検索に理解される構造が必要になったときだ。
Claude Fable 5.2がもたらした変化
Anthropicは2026年11月9日にClaude Fable 5.2とClaude Mythos 5.2を発表した。両者は同じ基盤モデルに基づく。Fableはサイバーセキュリティと生物領域向けの保護措置を備えるため全ユーザーに公開され、Mythosは審査プロジェクトへの申請が必要だ。発表説明で注目すべき点はAnthropicの告知を参照：
- 出力速度は最大でFable 5.1より30%高速。価格は入力100万トークンあたり8ドル、出力100万トークンあたり40ドル。オプションのfast modeでは生成速度を最大2.5倍に高められ、対応価格は入力100万トークンあたり16ドル、出力80ドル。
- Agentic coding評価FrontierCode 2.0で、Fable 5.2はXhigh effortで49.1%、FrontierSWE v2で69.9%を記録し、いずれも前世代とOpus 5.5を上回った。
- 公式は、大多数のコーディングと知識タスクはClaude Opus 5.5から始め、複雑さに応じてFable/Mythosへ上げるか、Sonnet、Haikuへ下げることを推奨している。Fable 5.2はAdvisorまたはOrchestratorとしてマルチエージェント協働に参加することもできる。
これらの数字が示すのは、単一タスク能力の底上げであり、製品形態の置き換えではない。発表説明はこれをウェブサイトやアプリの納品プラットフォームとは定義していない。Agent能力を提供するもので、コードリポジトリ、実行環境、データ、リリースフローは依然として誰かが構築・保守する必要がある。
まず3種類のツール形態を分けてから、選定を語る
2026年のサイト構築実践ガイドは、選択肢を3種類に分けている。オールインワンのサイト構築プラットフォーム（Wixなど）、prompt-to-app生成器（Lovable、v0など）、そして自分のコードリポジトリ内で動作するコーディングエージェント（Claude Codeの類）である。トレードオフは明確に書かれている。オールインワンプラットフォームは宣伝サイトや小規模店舗に向くが、代償はプラットフォームへの縛りとパフォーマンス制御が限られることだ。prompt-to-app生成器はカスタムUIとエクスポート可能なコードを求めるチームに向くが、代償はクレジットまたはトークン課金で、成果物に人手のレビューが必要なことだ。リポジトリ内のコーディングエージェントは完全な制御とバージョン履歴を求める開発者に向くが、代償はホスティング、テスト、デプロイをすべて自分で担うことである（How to Build a Website With AI in 2026参照）。
この分類とFable 5.2を並べると明確になる。Fable 5.2は第3カテゴリの「エンジン」であり、We0、Lovable、Boltはエンジン、インフラ、納品フローをパッケージ化した層である。両者は同じ土俵の競合ではなく、実際に比べるべきは「誰が納品責任を負うか」だ。
7つの軸で横断比較
| 比較軸 | AIコーディングエージェント（Claude Fable 5.2など） | AIサイト構築プラットフォーム（We0、Lovable、Boltなど） |
|---|---|---|
| コード制御 | 柔軟性が高く、リポジトリを完全に引き継ぎ、リファクタリングできる | プラットフォームがエクスポートとコードアクセスを開放しているかによる |
| ページ生成 | 開発フローとの連携が必要で、成果物はページ構造と直接結びつかない | ウェブサイト、ページ、コンテンツ構造を直接中心に構築する |
| ユーザー認証 | 通常、自分で選定・設定する必要がある | 多くのプラットフォームが基本のログイン機能を提供 |
| 決済体系 | 自分で統合、照合、リスク管理を行う必要がある | 一部のプラットフォームが提供。通貨、手数料、決済方式の確認が必要 |
| CMS管理画面 | 開発が必要、または別のコンテンツシステムを接続する | 一部のプラットフォームが既製の管理画面を提供 |
| デプロイ | エンジニアリング環境、CI、ロールバックの設定が必要 | 通常、ビジュアルな公開フローと独自ドメインを備える |
| 技術的ハードル | 比較的高く、コードの正誤を判断できる人材が必要 | 非専門の開発者でもセルフサービスで操作しやすい |
表を読むときの主線はこうだ。コード制御とデプロイ方式が乗り換えコストを決め、認証、決済、CMS、多言語が公開後3か月の運用負担を決め、技術的ハードルが「誰がやるか、継続できるか」を決める。4つのインフラのうち1つ欠ければ、自分で補わなければならない。
We0、Lovable、Boltはそれぞれ「パッケージ化」をどこまで進めたか
We0の位置づけは「サイト構築からリード獲得までのAIワークスペース」である。自然言語で要件を記述すると、マルチエージェントチームが実行可能なウェブサイトに変換し、ビジュアルキャンバスで微調整し、ワンクリックで独自ドメインにデプロイする。機能一覧にはCMS管理画面、SEOとGEO最適化、決済フロー、独立系ECサイト、多言語、ドメインデプロイも含まれる（We0公式サイト参照）。強調しているのは、ページ生成、管理画面、公開、その後の成長を同じ経路に置くことであり、単にフロントエンドコードを納品することではない。
Lovableはprompt-to-app生成器の路線に属する。対話で使えるUIとアプリを生成し、クレジットで課金し、成果物を受け取った後は項目ごとにレビューが必要だ。上記ガイドも「出力にはレビューが必要」を主要なトレードオフの一つに挙げている。
Boltはインフラを製品に組み込んでいる。対話型のアプリ・サイト生成に加え、Bolt Cloudはホスティング、データベース、ユーザー管理と認証、SEO最適化、独自ドメイン、分析を提供する。公式ページは、タスクに応じて適切なモデルへ自動ルーティングすると説明している（Bolt公式サイト参照）。
三者はいずれも「パッケージ化」の方向に進んでおり、違いは重点にある。Boltはクラウドインフラに重点を置き、We0はページからコンテンツ管理画面、決済、多言語、リード獲得までの経路に重点を置く。判断基準は実務的だ——自分に欠けているのはどの部分か。
6つの質問に1つずつ答える
Claude Fable 5.2はAIサイト構築ツールを直接代替できるか？
直接の代替にはならない。コードの生成と修正を明確に速めることはできるが、サイト納品にはドメイン、デプロイ、フォームとリードの受け皿、コンテンツ管理画面、公開後の巡回確認が必要だ。チームにこれらの工程を引き受けるエンジニアがいるなら、この種のAgentは生産性を高める増幅装置になる。そうした人材がいない場合、足りないのはより強力なモデルではなく、すでにつながった納品経路である。
プログラミングができない人はどれを選ぶべきか？
サイト構築プラットフォームを選ぶ。判断基準は「どのデモが派手か」ではなく、「人を探さずに、コピーを変更し、ページを追加し、画像を差し替え、公開できるか」だ。ビジュアルキャンバスとワンクリックデプロイのほうが、コードを書けても正誤判断を自分に求めるAgentより現実的である。
完全なSaaSを作りたい場合はどれを選ぶべきか？
SaaSの競争優位性がビジネスロジック、データモデル、統合にあるなら、コーディングエージェントのほうが適している。リポジトリ、テスト、バージョン履歴があり、将来必要に応じてリファクタリングできる。ただし認証、課金、管理画面、コンプライアンスの工数を見込んでおく必要がある。これらは通常「一度生成する」だけで長期的に安定運用できるモジュールではない。
企業サイトを素早く1つ作りたいだけなら？
サイト構築プラットフォームのほうが通常は割安だ。企業サイトの難しさはコードになく、構造（トップ、製品・サービス、事例、会社概要、問い合わせ）、検索可能なコンテンツ、公開後の継続更新にある。これらをすでにつながったフローに置くほうが、ゼロからフロントエンド工程を組むより速い。
ログイン、決済、CMS管理画面が必要な場合はどう選ぶか？
まずプラットフォームがネイティブに提供しているかを確認し、そのうえで自前構築の要否を決める。コーディングエージェントで自前構築するなら、各項目の選定、統合、テスト、資金フローへの責任が発生する。プラットフォームを使うなら、管理画面が編集権限、多言語、SEOとGEOの実需を満たすか、決済チャネルが対象市場をカバーするかを見る必要がある。
今後継続的に反復する場合、どの能力に注目すべきか？
- コードとデータをエクスポートできるか、乗り換えコストはどれほど高いか；
- 編集可能なキャンバスとコンテンツ管理画面があり、非技術の同僚がセルフサービスで改版できるか；
- 多言語と構造化コンテンツをカバーし、後続のSEO/GEOをしやすくしているか；
- 公開とロールバックがビジュアル化され、問題発生後にどれだけ早く復旧できるか；
- リードがどこから入り、どこに着地するか、CRMやメールシステムに接続できるか。
3つの典型的なチーム、3つの組み合わせ方
数分で紹介サイトを作り、リード獲得を伸ばす
アイデアを一文で入力するだけで、We0 AI が紹介サイト、ページ、CMS を生成し、公開後の顧客獲得と流入拡大を支援します。
無料登録で完全なプロジェクトを 1 つ生成
1 つの完全な生成フローを試し、最初のプロジェクトのドラフトをすぐに確認するのに最適です。
2人組の創業チームがB2B企業サイトを作る：企業サイトはサイト構築プラットフォームで完成させ、まずページ構造、事例、引用可能な事実ブロックを固める。製品プロトタイプはコーディングエージェントで検証し、リードページはエンジニアのスケジュールを待たなくてよい。
エンジニアリングチームを持つSaaS企業：中核製品は自社リポジトリでAgentを使って開発を加速し、マーケティングサイトとランディングページはプラットフォームに任せ、イベントページのたびにリリースフローを通すのを避ける。両側はドメイン体系を共有するが、コンテンツとエンジニアリングの責任は分ける。
Agencyとコンサルタント：顧客サイトはプラットフォームで一括納品し、反復的な巡回確認とリード受け皿のフローを固定化する。深いカスタマイズが必要なプロジェクトだけAgentで書き、クレジット課金ではなくプロジェクト単位で見積もる。
公開はスタートにすぎない：発見可能性とコンバージョンが長期的なコストになる
AIが生成したページは本質的に初稿だ。公開前に少なくとも3つのことを行う：
- 事実の再確認：価格、サービス範囲、資格、連絡先を項目ごとに追跡可能にし、モデルが捏造した顧客レビューや「1万社以上にサービス提供」といった数字を削除する。
- 構造と発見可能性：各ページにH1を1つ、固有のタイトルと説明、サーバー側でクロール可能なHTML、正しいsitemapとrobots.txt。テスト環境のnoindexを本番に持ち込まない。
- パフォーマンスとコンバージョンの実測：Core Web Vitalsの一般的な達成ラインはLCP ≤ 2.5秒、INP ≤ 200ミリ秒、CLS ≤ 0.1で、75パーセンタイルで判断する（上記ガイド参照）。フォームは実際に1回送信し、リードが人とシステムに届くことを確認する。
もう一つ見落とされがちな違いはコンテンツ構造にある。AI生成のフロントエンドは再利用可能なコンポーネントと統一されたコンテンツモデルを欠きやすく、ナビゲーションを変えるたびにページごとにコピーが必要になり、長期的な保守コストがかえって上がる。ページ生成とCMS管理を分けることが、より安定した組み合わせだ（Can AI coding platforms replace traditional page builders?参照）。
さらに明確なポリシーリスクを避ける必要がある。Googleのスパムコンテンツポリシーは、「生成AIで付加価値のないページを大量生産する」ことをscaled content abuseの典型例として挙げている。少なくても有用であるほうが、多くても同質であるより良い。
自社リポジトリで作業する前に、1つのコマンドでほとんどの不整合を掃除できる：
grep -rniE "lorem ipsum|example\.com|TODO|FIXME|api[_-]?key|secret" ./src
実行可能な選定フロー
- 目標を明確に書く：このバージョンでリードを得るのか、需要を検証するのか、それとも完全な製品ロジックを担うのか？
- 必須要件を列挙する：ログイン、決済、管理画面、多言語、マルチサイトを項目ごとにチェックする。
- チーム能力を判断する：公開後48時間以内に、壊れたフォームを誰が直せるか？
- 総コストを計算する：サブスクリプション費、モデルのトークン費、エンジニアリング時間、3か月の運用時間を同じ表に入れる。
- 小範囲で試運転する：まず1つのランディングページまたは1つのサブフローで検証し、その後メインサイトを移行するか決める。
意思決定チェックリスト——3項目以上に当てはまるなら、AIサイト構築プラットフォームを優先
- チームにコードを長期的に保守できる人がいない；
- 公開時期が四半期単位ではなく週単位；
- コンテンツ管理画面、多言語、オンライン決済が必要；
- 検索とAIに引用されるコンテンツページを継続的に生み出す必要がある。
意思決定チェックリスト——3項目以上に当てはまるなら、AIコーディングエージェントを優先
- 製品ロジックそのものが中核資産で、深いカスタマイズが必要；
- 既にエンジニアリングチーム、テスト、CI/CDがある；
- 社内システムや自社データソースへの接続が必要；
- 将来、自社インフラへ移行する計画がある。
よくある質問
Claude Fable 5.2とは何か？
Anthropicが2026年11月9日に発表したモデルバージョンで、Mythos 5.2と同じ基盤モデルに基づく。違いは、Fableがより強力な安全保護を備え、全ユーザーに公開されていることだ。向上はコーディング、推論、視覚タスクに集中しており、公式は大多数の日常的なコーディングと知識タスクをOpus 5.5から始めることを推奨している。
We0とLovableの違いは何か？
We0はページ生成、コンテンツ管理画面、決済フロー、多言語、ドメインデプロイを同じ納品経路に置く。Lovableはprompt-to-app生成器の路線で、クレジット課金、成果物にはレビューが必要だ。選択は「パッケージ化された公開経路」が欲しいのか、「さらに開発を続けられるコード」が欲しいのかで決まる。
AIサイト構築プラットフォームで作ったサイトは、SEOが悪くなるのか？
差は通常、プラットフォームに由来せず、技術的な基礎項目を処理しているかどうかに由来する。クロール可能なHTML、固有のタイトルと説明、正しいsitemap、実際のコンテンツと構造化データである。これらはプラットフォーム上でも同様に実現でき、むしろ自前構築プロジェクトで見落とされがちだ。
どのようなときに両方を併用すべきか？
よくある組み合わせは、企業サイト、ランディングページ、コンテンツサイトはプラットフォームで継続運用し、社内システム、データパイプライン、複雑なビジネスロジックはコーディングエージェントで開発する。両者はブランドとドメインを共有するが、反復のリズムを分け、互いにブロックしないようにする。
関連ツール（Related Tools）
- We0：展示型ウェブサイトとリード獲得向けのAIプラットフォーム。自然言語によるサイト構築、CMS管理画面、決済フロー、多言語、ドメインデプロイをカバーする。
- Bolt：対話型でアプリとウェブサイトを生成し、ホスティング、データベース、認証、独自ドメインなどのクラウド機能を備える。
- Claude Fable 5.2 発表説明：このモデルのAgentic codingにおける評価結果と価格を確認できる。
関連リンク（Related Links）
- Anthropic：Claude Fable 5.2とMythos 5.2
- How to Build a Website With AI in 2026: Tools and Steps
- Can AI coding platforms replace traditional page builders?
- We0公式サイト
- Bolt公式サイト
まとめ（Summary）
Claude Fable 5.2は単一タスクのコーディング能力を高めたが、納品責任の分担は変えていない。コーディングエージェントは自由度を与え、サイト構築プラットフォームはすでにつながった経路を与える。判断方法は3つの問いに集約できる——公開後に誰が保守するのか、どのインフラ（認証、決済、管理画面、多言語）が必要か、将来コードを移行するつもりがあるか。まず1つのランディングページまたは1つのサブフローで試運転するほうが、2つの形態の間で議論を繰り返すより早く答えを得られる。
