AIにWebサイトのデザインを任せたことはありますか？
任せてみると、どこかで見たような「それっぽい」画面ばかりが出てきます。
この現象は海外で「AIスロップ」と呼ばれています。
そして、AIコーディングに取り組む人たちの共通の悩みになっています。
そんな中、RedditのClaudeAIコミュニティにある投稿が上がりました。
「FableのフロントエンドUIがすごい」という内容です。
この投稿は大きな反響を呼びました。
本記事では、この投稿とコメント欄の議論を整理して紹介します。
投稿者が語った「Fable以前」の苦労
投稿者は、数ヶ月にわたって自分のSaaSを開発してきた人物です。
しかし、フロントエンドだけはOpusでうまくいかなかったと言います。
やるべきことはやっていました。
具体的には、次のような準備です。
- デザインのDoとDon’tをまとめる
- ビジュアルの参考例を集める
- ガイドラインを大量に用意する
それでも、出力されるのは例の「AIスロップ」なWebサイトでした。
追い詰められた投稿者は、こんな手順まで試したそうです。
まず、Photoshopでページデザインを自作します。
次に、それをデザインツールに読み込ませて再現させます。
そして、Claude Codeで実装するという流れです。
ここまでやっても、仕上がりは満足のいくものになりませんでした。
投稿者にWebデザインの経験はありません。
ただし、マーケティングの下地はありました。
印刷物中心とはいえ、ページレイアウトを扱ってきたのです。
そのスキルが活きないことに、もどかしさを感じていたようです。
Fableで何が変わったのか
転機はFableの登場でした。
それまで投稿者は、複数のOpusチャットを使い分けていました。
あるチャットでは参考サイトを探します。
別のチャットでは、デザインシステムのガイドラインを書きます。
さらに別のチャットで全体の雰囲気を検討し、ページの下書きを作っていました。
役割分担はできています。
しかし、しょせんはバラバラの作業です。
Fableでは、この大半が1つのチャットで完結したと言います。
集めてあった資料と過去チャットの成果物を取り込みました。
そして、両者を組み合わせて本格的なデザインシステムを一気に構築したそうです。
さらに、モバイル向けのWebページも生成されました。
初稿としては悪くない仕上がりだったとのこと。
投稿者が最も驚いたのは、頼んでもいない振る舞いでした。
Fableはロゴを分析し、構成要素に分解しました。
そして、その断片から箇条書きの装飾などのデザイン要素を作り出したのです。
それらの要素は、ページ全体に展開されました。
「Opusならやらなかっただろう」と投稿者は評価しています。
投稿者の具体的なワークフロー
コメント欄での質問に答える形で、投稿者は自分のセットアップも明かしています。
まず、「デザインフォルダ」を用意します。
中身は、ロゴ、デザインのDoとDon’t、配色などの一般的なガイドラインです。
Fableはこれを読み込みました。
そして、デザインシステムのドキュメントを生成したのです。
各要素の使いどころまで含まれていたと言います。
あわせて、ドキュメント内で参照される素材を集めた新しいフォルダも作られました。
ここからが工夫のしどころです。
投稿者は、簡単なスキルを自作しました。
以降のデザイン関連チャットでは、「このドキュメントとこのフォルダを読む」とだけ指示します。
なぜなら、フォルダ全体を毎回読み込ませると、コンテキストが膨れ上がるからです。
新しいチャットは、ドキュメントと必要な要素だけを参照すれば済みます。
ワンショットで作ることの利点にも触れていました。
以前は、複数のOpusチャットで関連作業を分担していました。
共有ドキュメントを更新し合っても、一貫性の維持に苦労したそうです。
しかし、1つのチャットですべてを処理すれば話は別です。
同じ発想がデザイン全体に貫かれます。
コメント欄は賛否両論
ここからが面白いところです。
コメント欄の評価は、はっきりと割れました。
まず、肯定派の声を見てみましょう。
「コーディングが素晴らしく、指示を一発でこなす。大幅な進化だ」という意見がありました。
また、前日にデザインツールでUIを全面刷新したばかりの人もいます。
その人はFableを10時間使いました。
その結果、「プロジェクトへの理解がより完全で深い」と感じたそうです。
ホームページのヒーローカードを改善できた、という報告もありました。
一方、懐疑派の声は手厳しいものでした。
ある人は、FableとOpusを同条件で比較しました。
同じデザインシステム、同じプロンプト、同じ参考スクリーンショットです。
その条件で、レビューページを15パターンほど生成したと言います。
結論は「文字通り同じ」でした。
良い出力も悪い出力も運次第です。
そして、最後は必ず自分が手を入れることになる、と述べています。
「Opusと同等で、相変わらず定型的なAIデザインスロップを量産する」という観察もありました。
また、別の人は過去に作ったデザインシステムの改善をFableに依頼したそうです。
結果は、Opusと大差ありませんでした。
それなのに、5時間分のトークンの半分を消費したと報告しています。
ただし、本人はこう付け加えていました。
ゼロから作らせれば違ったかもしれない、と。
「UIにFableほど高価なモデルが必要なら、何かを見落としている」という辛辣な一言もありました。
トークンコストという現実問題
スレッド全体を通じて繰り返されたのが、コストの話です。
Fableは大量のトークンを消費します。
大きなタスクを1回実行しただけで、月間上限のかなりの割合を食うという声もありました。
企業勤めの人にとって、これは無視できない問題です。
実際、社内でトークン節約のベストプラクティスを共有している、という人もいました。
対照的に、Sonnetで十分という意見も目立ちました。
例えば、バックエンド専門でフロントエンドが苦手だという人がいます。
その人は、Sonnetで何度か反復するだけで満足のいくプロトタイプを作れていると述べています。
反復はUXづくりの一部です。
しかも、安くて修正も気軽だというわけです。
月150〜400ドル程度でやりくりしている、という人もいました。
コツは、アプリ全体を一度に作らないことです。
スクリーンショットと素材をアップロードします。
そして、ウィジェットや画面を1つずつ進めるのです。
小さな変更と小さなコンテキスト。
これが節約の秘訣だと言います。
代替ワークフローの提案
Fableに頼らない方法も、いくつか共有されていました。
人気があったのは、デザインツールとSonnetを組み合わせる流れです。
手順は次のとおり。
- 使用する技術スタックを伝える
- モックアップを納得いくまで反復する
- 仕上がったらパッケージとしてSonnetに引き渡す
この方法は、ある観察に基づいています。
Opusはゼロからの WebアプリUIが苦手です。
しかし、デザイン特化のツールなら美的センスを発揮する、というものです。
Google Studioから始めるという人もいました。
フロントエンドデザインだけは得意だからだそうです。
そこで作ったものを、別ツールで磨き上げるのだとか。
もっと手軽な方法もありました。
フロントエンドデザイナー系のプラグインを使います。
そして、「AIスロップ禁止」と明示するだけです。
これだけでも効果がある、という声がありました。
意外と盛り上がった「HTMLプレゼン」談義
このスレッドで最も支持を集めたコメントは、実はFableと直接関係ありません。
「パワポは窓から投げ捨てて、ClaudeにインタラクティブなHTMLファイルを作らせろ」という提案です。
スライドのように歩けるHTMLなら、見栄えで競合と差がつくというわけです。
実際の活用例もありました。
コンサルティング会社で、RFP（提案依頼書）への回答に使っているそうです。
パスワード付きの簡易サイトでHTMLを公開します。
そして、従来形式の書類と併用しているとのこと。
競合の提出物がパワポやWord文書なら、確かに目立つでしょう。
ただし、欠点もはっきり指摘されました。
最大の問題はコラボレーションです。
HTMLファイルにはコメントを残せません。
また、人をタグ付けすることもできません。
Googleドキュメントなら標準で備えている機能です。
それを再現する手間に見合わない、という意見には説得力がありました。
さらに、実際のプレゼンではパワポに軍配が上がるという声もあります。
画面投影とスピーカーノートが必要な場面、特にハイブリッド会議では、ということです。
それでも工夫する人はいます。
Slidevというツールを使えば、インタラクティブなHTMLとPDFを同じ見た目で生成できるそうです。
発表はHTML、配布はPDFという使い分けですね。
コメント機能を自作して、GitHubで公開した人までいました。
AIスロップの「見分け方」
スレッドの脇道で、AIっぽいデザインの特徴を挙げ合う場面がありました。
挙がっていたのは、次のようなパターンです。
- カードの左端に入った色付きボーダー
- 見出しの横に置かれた色付きのドット
- ピル型のUI要素
こうしたパターンが頻出すると、どうなるか。
見る人が見れば「AIが作ったな」とわかってしまうそうです。
こんな体験談も投稿されていました。
自分では良いUIだと思っていたのに、同僚に一目で「まだAIスロップの気配がある」と言われたそうです。
AIの出力をそのまま使うことの難しさを物語るエピソードです。
まとめ
Redditのスレッドから見えてきたのは、現実的な温度感でした。
単純な「Fable最高」でもなければ、「Fable不要」でもありません。
Fableを高く評価する声は、確かにあります。
ゼロからデザインシステムを構築できるからです。
さらに、複数チャットに分かれていた作業を、一貫性を保ったまま1回でこなせます。
ロゴを分解してデザイン要素に再利用するような、指示外の創造性に驚いた人もいました。
一方で、手放しの称賛にブレーキをかける要素もあります。
Opusと変わらないという検証報告です。
また、既存デザインの改善には弱いという指摘もありました。
そして何より、高額なトークンコストへの懸念です。
安価なモデルで反復する方が合理的だ、という意見にも一理あるでしょう。
結局のところ、モデル選びは用途と予算次第です。
ゼロからの構築ならFable。
反復前提の調整ならSonnet。
これが現時点での落としどころかもしれません。
高価なモデルが出るたびに「これで解決」と飛びつくのは危険です。
自分のワークフローのどこに効くのかを、まず見極めましょう。
スレッドの議論は、その大切さを教えてくれます。
