「Claude Fable 5 で LP を15分生成」を分解する — 改善ループを合格条件に落とす設計

X で流れてきた投稿が、一定の反応を集めていました。11 秒の動画が添えられています。

Claude Fable 5 が Web デザイナーを潰した 次世代 LP を15分であっさり生成してしまったw

続けて、外注費20万円クラスの品質を「安定して」出すには生成後の改善ループが重要だ、という話が並び、その中身が6項目挙げられています。最後は Skills の公開予告で締められています。

この投稿は、煽りの部分と、実務的に正しい部分がきれいに混ざっています。前半の「15分で20万円品質」は検証できません。後半の「生成後の改善ループが本体だ」は、おそらく正しい。

この記事では、まず検証できる部分とできない部分を切り分けます。そのうえで、投稿が箇条書きで済ませている「改善ループ」を、実際に動かせる形——何をもって合格とするか、誰がそれを判定するか、次回に何を持ち帰るか——まで具体化します。最後に、Fable 5 を使う場合の現実的なコストを試算します。

先に結論だけ挙げておきます。

• 「15分」は生成の所要時間であって、公開できる状態までの所要時間ではない
• 改善ループの本体は生成ではなく、機械が判定する合格条件と人間が判定する合格条件を分けて置くこと
• ループを回すほど賢くなるのは、結果を Skill に書き戻したときだけ。書き戻しがなければ毎回ゼロから15分を繰り返すだけ
• Fable 5 を全周で使う必要はない。構成設計だけ高いモデル、反復は安いモデルが費用対効果としては素直

「15分で20万円品質の LP」はどこまで検証できるか

Claude Fable 5 は実在します。 Anthropic の最上位モデル（一般提供）で、モデル ID は claude-fable-5。コンテキストウィンドウは 100 万トークン、最大出力は 128K トークン、料金は入力 100 万トークンあたり $10 / 出力 $50 です。Opus 5（$5 / $25）のちょうど倍で、Sonnet 5（$3 / $15）とは入力で 3 倍以上の開きがあります。ここは事実として確認できます。

Claude Skills も実在します。 タスク固有の手順やコンテキストを SKILL.md を中心としたフォルダにまとめ、関連する場面でモデルが読み込む仕組みです。「LP 制作用の Skills」という発想自体はまっとうで、目新しくもありません。当ブログでも Claude Code の Skills 完全ガイド や フロントエンドデザイン Skill で繰り返し扱ってきた領域です。

「15分」と「外注費20万円クラス」は検証できません。 動画は11秒で、生成過程は映っていません。何を入力したのか、何周やり直したのか、どこまで人が手を入れたのかがわからない以上、再現性のある主張として扱えません。この種のバズ投稿を追った例としては 「Claude だけで6500万ドル」投稿の真相 もあります。

そして「20万円クラス」という値付けは、そもそも成果物の見た目に対して付いている値段ではありません。外注の見積もりに含まれるのは、おおよそ次の3層です。

• 上流 — ヒアリング、競合調査、構成設計
• 制作 — コピーライティング、デザイン、実装
• 公開前後 — 表示速度とアクセシビリティの担保、計測タグの設置、薬機法・景表法まわりのチェック、公開後の修正対応

生成 AI が15分で肩代わりできるのは、このうち「制作」の実装とデザイン初稿に相当する部分です。

つまり比較の土俵がずれています。「15分で作れた」が意味するのは、ループの1周目が速く回るようになったということであって、公開できる状態に到達したということではありません。

とはいえ、これは元投稿を否定する話ではありません。元投稿自身が「AI で LP を作るだけなら誰でもできる」「品質を安定して出すには生成後の改善ループが重要」と書いています。そこが正しい。以降はその部分を具体化します。

LP 改善ループを「合格条件」に落とす

元投稿の改善ループは、こう列挙されています。

• 競合 LP をリサーチして構成を比較
• ファーストビューを複数パターン生成
• CTA の文言を AB テスト前提で作成
• ユーザー導線を分析して改善
• スマホ表示・表示速度・SEO まで最適化
• 改善内容を次回の LP へ反映

やることとしては妥当です。ただし、このままではループになりません。どれも「やる」としか書かれておらず、「どうなったら次に進んでよいか」が定義されていないからです。

エージェントに任せる作業で最初に決めるべきなのは、手順ではなく停止条件です。合格条件がないループは、モデルが「できました」と言った時点で終わります。それはループではなく、単に生成を繰り返しているだけです。この構造については ループエンジニアリング でも整理しました。AI に任せた作業が「与えた検証境界にぴったり最適化して止まる」性質については AIリファクタの完了境界 も併せて。

以下ではこの停止条件を「合格条件」、それを判定する仕組みを「ゲート」と呼びます。そこで、上の6項目を判定者ごとに二段に分けます。基準は2つ。数値で白黒がつくか、そして間違えたときに取り返しがつくか。両方を満たすものは機械へ、どちらかを欠くものは人間に残します。

機械が判定するゲート — Lighthouse CI / axe-core / Playwright

数値で白黒がつき、かつ後から直せるものは、全部ここに寄せます。人間のレビューに回してはいけません。

以下の LCP・CLS・INP は Core Web Vitals と呼ばれる3指標です。

ひとつ注意点があります。INP（応答性）はここに入れられません。 Lighthouse はラボツールで、実際のユーザー操作を行わないため INP を測定できないからです。代理指標として TBT（Total Blocking Time）を置き、INP 本体は公開後の実ユーザー計測（web-vitals ライブラリや CrUX）で見ることになります。つまり INP は機械ゲートではなく、後述する⑦の書き戻しで扱う指標です。

構造化データも同様の事情があります。Schema.org 公式の Schema Markup Validator は Web UI のみで API/CLI がないため、CI に組み込むなら CLI を持つ structured-data-testing-tool などに置き換える必要があります。

落ちたら人間に見せる前にエージェントへ差し戻す。ここを自動化しておくと、人間のレビュー時間が「速度が遅い」「文字が読みにくい」といった機械的な指摘に食われなくなります。導入前は指摘の大半が速度と可読性で埋まるのが普通で、そこが消えるとレビューが訴求とブランドの話だけになります。

Claude Code から回すなら、判定コマンドを Skill 側に書いておいて、修正 → 再検証を自走させる形になります。

<!-- .claude/skills/lp-build/SKILL.md より抜粋 -->

## 検証ゲート

実装を変更したら、必ず以下を実行して結果を確認すること。
すべて合格するまで、人間に完了を報告してはならない。

```bash
# 事前に vite preview などで localhost:4173 を起動しておくこと
npx @lhci/cli autorun --collect.url=http://localhost:4173
npx @axe-core/cli http://localhost:4173
npx playwright test tests/responsive.spec.ts
npx linkinator dist/index.html
```

Lighthouse の総合スコアではなく、LCP / CLS / TBT の実測値で判定する。
スコアは各指標の加重平均なので、個別のしきい値を隠してしまう。

最後の2行は実務上そこそこ効きます。「Lighthouse 90点以上」を条件にすると、CLS が悪くても他が良ければ通ってしまう（Lighthouse 12 の重みは TBT 30% / LCP 25% / CLS 25% / FCP 10% / Speed Index 10%）。総合スコアではなく個別指標をしきい値にするのが定石です。

なおリンクチェッカーの lychee は Rust 製で npm 配布がなく、npx lychee と書くとまったく無関係の同名 npm パッケージを取ってきてしまいます。npx で完結させたいなら Node 製の linkinator、lychee を使うなら brew install lychee などで入れて npx を外してください。同じ理由で Lighthouse CI も npx lhci ではなく npx @lhci/cli です（lhci は別のプレースホルダパッケージ）。

人間が判定するゲート — 訴求の事実性・法令表記・権利

一方、機械に判定させてはいけないものもあります。

• 訴求が事実に反していないか — 「業界No.1」「導入企業1,000社」といった数字を、モデルは平気で埋めてきます。プレースホルダのつもりで書いたものがそのまま公開される事故が一番怖い
• 景表法・薬機法などの表記 — 効果効能の断定、最上級表現、打消し表示。法的リスクなので判断を委譲できません
• 画像・フォントの権利 — 生成画像を商用利用してよい条件か、Web フォントのライセンスは足りているか
• ブランドとして出してよいか — トーン、世界観、既存サイトとの一貫性。これだけは非可逆ではありませんが、数値化もできないので人間に残ります

上3つに共通するのは、間違えたときのコストが非可逆だという点です。表示速度が遅ければ直せばいい。誇大広告を出してしまったら、直しても消えません。可逆性を基準にゲートを分けると、線が引きやすくなります。

「AB テスト前提」を合格条件に落とす

元投稿の「CTA の文言を AB テスト前提で作成」は、そのまま指示するとバリエーションを10個並べてくるだけになりがちです。それは AB テスト前提ではなく、単なる候補出しです。

AB テスト前提というのは、どの仮説を検証するのかが明示されているということです。出力の形を指定してしまうのが早い。

CTA 案は以下の形式で3案だけ出すこと。文言だけを列挙してはならない。

| 案 | 文言 | 検証したい仮説 | 効きそうな理由 | 反証されたと言える結果 |
| --- | --- | --- | --- | --- |
| A | 30秒で無料診断 | 所要時間の明示が心理的障壁を下げる | 検討初期の流入が多い | CVR 差が ±0.3pt 以内 |

「反証されたと言える結果」の列があると、負けたときに何を学んだかが残ります。これがないと、テストの結果が「A のほうが良かった」で終わり、次回に持ち越せません。

ループが賢くなるのは SKILL.md に書き戻したときだけ

ここが本題です。元投稿の6番目、「改善内容を次回の LP へ反映」。一行で流されていますが、唯一ここが「毎回進化する」を成立させる部分です。

図の⑦にあたります。公開後の計測結果——CVR、スクロール到達率、CTA クリック率——を見て、次のように書き戻します。

• 勝ったパターン → Skill の推奨構成として昇格させる
• 負けたパターン → 却下理由つきで残す。「試して駄目だった」は次回の生成で最も価値のある情報です
• 毎回同じ指摘をしている箇所 → プロンプトではなくデザイントークンや検証ゲートに移す

3番目が特に効きます。「余白が狭い」「見出しが小さい」を毎回チャットで指摘しているなら、それは指示の失敗ではなく構造化されていないルールです。トークンファイルに書けば二度と指摘しなくて済みます。デザイントークンを AI に渡す形式そのものについては Google 製 DESIGN.md が参考になります。

.claude/skills/lp-build/
├── SKILL.md              # 手順と検証ゲート
├── design-tokens.json    # 配色・書体・余白スケール
├── rejected.md           # 却下パターンと理由（負けの記録）
└── references/
    └── section-order.md  # 過去に成果が出た構成パターン

rejected.md を明示的に置くのは、これがないと同じ提案が何度も戻ってくるからです。「ヒーローに動画を敷く案は、LCP が 4 秒を超えたため却下」と書いてあれば、モデルは同じ地雷を踏みません。

そして、これがあるかないかで元投稿の主張の意味が変わります。書き戻しがあれば「LP は作るたびに進化していく」は成立します。なければ、毎回ゼロから15分を繰り返しているだけで、10本目も1本目と同じ品質です。速いことと、良くなっていくことは別の話です。

なお元投稿は「この仕組みごと使うのが一番早い」と続けて Skills の公開を予告しています。ただ、上で見たとおりループの価値の大半は書き戻しに蓄積された自社データ側にあります。他人の SKILL.md をもらってきても、手に入るのは手順の雛形までで、rejected.md に相当する部分は自分で貯めるしかありません。雛形として参考にするのは有効ですが、それ自体が答えではない、という距離感が妥当なところです。配布された Skills の扱いについては Anthropic 社内の Skills 実践知見 も参考になります。

Claude Fable 5 を全周で使う必要はない — 料金とコスト試算

ここまでの設計には副作用があります。ゲートを厳しくするほど、1本あたりの周回数は増える。つまりループの設計は、そのままコスト構造の設計でもあります。

Fable 5 の入力単価は Sonnet 5 の 3〜5 倍です（Sonnet 5 は 2026年8月31日まで $2 / $10 の導入価格）。そして LP の改善ループは、性質の違う2つの作業でできています。

1. 構成設計 — 競合の訴求軸を比較し、セクション順を決め、ファーストビューの方針を固める。難しい判断で、やり直しは効きにくい。1回だけ走る
2. 実装と修正 — HTML/CSS を書き、検証ゲートに落ち、直し、また回す。1回あたりは易しいが、何周も走る

高いモデルが要るのは1だけです。仮に構成設計を1回（入力 50k / 出力 20k）、実装ループを20周（1周あたり入力 30k / 出力 15k）と置くと、概算はこうなります。

※ Sonnet 5 は導入価格、プロンプトキャッシュ未考慮での単純計算

読むべきは絶対額ではなく比率です。全周 Fable 5 と「設計だけ Fable 5」では約 4 倍、全周 Sonnet 5 とは 5 倍の開きがあります。この比率は周回数に比例して効いてきます。LP 1本なら差は 20 ドル弱なので誤差ですが、月に20本回すならそのまま20倍になりますし、検証ゲートが厳しいほど1本あたりの周回数は増えます。

もうひとつ、実装ループではプロンプトキャッシュが素直に効きます。SKILL.md とデザイントークンは毎周まったく同じ内容を送ることになるので、これらを前置してキャッシュブレークポイント（どこまでを再利用対象にするかの区切り）を置けば、キャッシュ読み出しは通常入力の約0.1倍で済みます。逆に言うと、タイムスタンプや周回カウンタをシステムプロンプトの先頭に混ぜると全部無効化されます。ループを自作するときに踏みやすい罠で、プロンプトキャッシュを効かせる部分英語化パターン でも触れた論点です。

Claude Fable 5 の API 作法 — thinking 常時オン・30日データ保持

Opus 系のコードをそのまま Fable 5 に向けると弾かれることがあります。Opus 4.8 からの変更点は次の2つです。

• 思考が常時オン — thinking パラメータの明示指定を受け付けません。{type: "disabled"} は 400 になるので、パラメータごと外して output_config.effort で深さを制御します
• 30日間のデータ保持が必須 — ゼロデータ保持（ZDR）設定の組織では、リクエスト内容が正しくても全件 400 になります

加えてアシスタントのプリフィルも使えませんが、こちらは Opus 4.8 から変わっておらず Fable 5 固有の制約ではありません。

LP 改善ループはどこから手を付けるか

いきなり全部そろえる必要はありません。効く順に並べるとこうです。

1. 機械が判定するゲートを1つ作る — まず Lighthouse CI だけでいい。「速度は人間が見ない」という状態を作ると、レビューの質が目に見えて変わります
2. rejected.md を置く — 同じ指摘を2回したら rejected.md に書く。3回目はもう指摘しなくて済みます
3. 人間ゲートのチェックリストを固定する — 訴求の事実性、法令表記、権利。毎回同じ順で見る
4. モデルを分ける — 周回数が増えてきてから考えれば十分です

順番が逆になりがちなのが4番です。モデル選定は一番楽しいところですが、合格条件のないループでは、どのモデルを使っても結果は運任せになります。

まとめ

• 「15分で20万円品質」は検証できない。ただし元投稿自身が「生成だけなら誰でもできる」と認めており、主張の本体は改善ループのほうにある
• 改善ループを機能させる条件は、手順を並べることではなく合格条件を定義すること。数値で判定できるものは機械のゲートへ、非可逆なリスクを含むものは人間のゲートへ分ける
• 「毎回進化する」を成立させるのは書き戻しだけ。勝ちパターンより、却下理由の蓄積のほうが効く
• Fable 5 は構成設計に1回使えば十分で、反復は安いモデルで回せる。差は本数に比例して開く
• 他人の Skills は雛形としては使えるが、価値の中心にある自社の負けの記録は、自分で貯めるしかない

Web デザイナーが潰れたかどうかはさておき、「合格条件を定義して、負けを記録する」という部分は、そもそも AI が来る前からデザイナーの仕事の中身だったものです。ループの設計とは、その仕事を言語化して機械に渡せる形にすることであって、いらなくすることではありません。この論点の広い版は Dario Amodei の職業予測とデザインの行方 でも扱いました。