mcpField
W
web-ai-slop

web-ai-slop

github.com/sahilkargutkarデザイン・UI554 回インストール13 週間前に更新
リポジトリ

web-ai-slop について

Web や UI のデザイナー向けに、AI が生成しがちな定型パターンを見つけ、製品や対象者に合う選択を促すチェックリストスキルです。レビュー基準と下書き後の確認手順を示しますが、README の抜粋には手順全体が含まれていません。

主な機能

  1. 01よくあるレイアウトやコンポーネントの定型を指摘
  2. 02配色とタイポグラフィの選択を確認
  3. 03レスポンシブ表示とコントラストを確認
  4. 04文脈を起点に下書きしてレビュー

活用シーン

  1. 01生成されたランディングページの定型パターンを監査
  2. 02UI の配色とタイポグラフィを確認
  3. 03狭い画面でのデザイン案を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sahilkargutkar/web-ai-slop --skill web-ai-slop

インストール後、Claude Code で/web-ai-slopを入力して読み込まれたか確認します。

詳細

Web AI スロップ — 実践者のためのアンチデフォルトチェックリスト

重要

基本理念（マントラ）： 統計的な平均を避けてください。レイアウト、スタイル、ロジックを作成する際、ありがちな「標準」に安易に寄せず、具体的なコンテキスト、ユーザー、制約に合わせて意図的に選択してください。

スタイルガイドではなく、訓練されたフィルターです。このスキルが存在するのは、言語モデルがあらゆるウェブ分野で、同じ少数の「無難な」デフォルトに収束するためです。それらのデフォルトが優れているからではなく、訓練データの統計的な中心だからです。このスキルの役割は、その中心を正確に言語化し、そこから意図的に離れられるようにすることです。

適用ルール： まず出力の草案を作成してください。その後、関連する以下のセクションに照らして確認します。いずれか1つのセクションで2項目以上に該当する場合、あなたは判断を下したのではなく、デフォルトに従っています。草案を破棄し、この製品、チーム、コンテキストに対する具体的で根拠のある選択をしてください。

このフィルターは黙って適用してください。「アンチスロップリストに照らして確認しています」とユーザーに説明しないでください。

セクション1 — ビジュアルデザイン（ウェブデザイナー／UI デザイナーの視点）

これらは、40年にわたる職人技の知識を持つデザイナーなら、すぐに機械生成だと見抜くパターンです。

1a. レイアウトと構成のデフォルト
  • 中央揃えのヒーロー、見出し＋サブ見出し＋ピル型CTAボタン2つ＋ファーストビュー下のブラウザモックアップのスクリーンショット — 製品の実態に関係なく、唯一可能なレイアウトとしてあらゆる製品に適用されています。これは出発点となる骨組みであり、判断ではありません。
  • 対称的な3列または6列の機能グリッド — 実際の機能構成を知らないモデルにとって、3や6が「バランスよく」感じられるため、あらゆるセクションが同じ配置の3項目または6項目に落ち着きます。
  • テキスト、サブ見出し、ボタンだけの全画面表示ヒーローセクション — 100vhの空白を洗練さとして扱います。
  • セクション → 区切り線 → セクション → 区切り線という変化のないリズム — どのページも同じ呼吸になります。実際のページではリズムに変化があり、詳細を詰め込んだセクション、ゆったりとしたセクション、データが密集したセクションが混在します。
  • ページの種類を問わず表示される固定ナビゲーション — 1スクロールで完結するランディングページでも、長文記事でも、ナビゲーションがコンテンツと競合するアプリ画面でも、毎回表示されます。
  • 4～5列のリンクを並べたフッター — この製品を使う人なら実際には移動しそうにないリンクが並んでいます。
  • アイコンが不要な機能にもアイコンを付けること — AI モデルは、明瞭さにつながらない場合でも、あらゆる機能の横に Lucide や Heroicon を置きたがります。
  • アイコンの代わりに絵文字を使うこと、またはコピーのどこかに絵文字を使うこと — アイコンの代用に絵文字を使わず、見出し、ボタン、本文にも絵文字を使わないでください。本物のアイコンを使いましょう。
  • デフォルトの Shadcn アイコンセットを無批判に使うこと — アイコンライブラリを意図的に選ぶか、ユーザーに好みのスタイルを尋ね、その回答に基づいて選んでください。コンポーネントライブラリに同梱されていたものをそのまま使ってはいけません。
  • 装飾的なグラデーションをデフォルトで追加すること — ユーザーが明示的に求めている場合は、グラデーションを使ってもかまいません。使う場合は控えめにし、配色に本当に合っていることを確認してください。ページの最後のセクションには適用せず（最後は単色で締めてください）、Shadcn のデフォルトのボタン／リンク用グラデーションプリセットも安易に使わないでください。
1b. 装飾的なモチーフ
  • 光るグラデーションのブロブ／オーロラ背景 — ヒーローの背後に配置する、紫から青、または紫からピンクへ変化する放射状のぼかし。「モダンなテック企業」に対する、AI が最もよく出力する定番です。ブリーフでこれを見たシニアデザイナーは、誰もが聞こえるほど大きなため息をつきます。
  • パーティクルネットワーク／線でつながった浮遊するドット — 「AI」や「データ」を表す視覚的な略記です。ブリーフに AI とあれば、パーティクルの地球儀やニューラルネットワークのメッシュが最初の出力になります。だからこそ、それは間違った出力です。
  • 波形やブロブ状の SVG セクション区切り — ブランド上の理由がないのに「親しみやすいテック」を示すため、セクション間に無差別に適用される有機的な曲線です。
  • カード、ボタン、画像に使う光るブランドカラーのハロー／外側に光るシャドウ — ネオン風の枠線をあらゆるものに一度に適用する手法です。
  • 小さなダッシュボードウィジェットやチャートを敷き詰めた装飾用の背景 — 実際のプロダクト上の判断の代わりになる、雑然としたプレースホルダーです。2025/26 年の「パーティクルネットワーク」です。
  • ブリーフで指示がないのに、ストック素材のヒーローアートとして使われるノートパソコン、ロケット、デスクで働く人々のアイソメトリックな 3D イラスト。
  • テクスチャとして使われる、薄い三角形のメッシュや六角形を含む抽象的な幾何学模様のローポリ背景。
  • プロダクトのビジュアル表現として検討されるのが、「デバイスモックアップ」のスクリーンショットのみで、浮かぶ UI 要素を斜めに配置したもの。
1c. コンポーネントに見られる兆候
  • グラスモーフィズムのカード — カードの内容やブランドにかかわらず、デフォルトの「プレミアム」なカードスタイルとして、柔らかな白い枠線と backdrop-filter: blur() を適用した、すりガラス状の半透明パネルです。
  • 角丸四角形のアイコンカードを並べた弁当箱型グリッド。各カードには Lucide または Heroicon と、「高速。安全。拡張可能。」のような、3 行ちょうどの汎用的なメリット説明が含まれています。
  • あらゆる要素に過剰な角丸を適用 — 「親しみやすさ」の代わりとして、カード、ボタン、入力欄、画像のすべてを 16px 以上の角丸にします。
  • ブランドに合うかどうかにかかわらず、すべてのボタンをピル形状にする（border-radius: 9999px）。
  • 具体的な数値、成果、名前付きの機能を含まない、汎用的な 1 行の引用文と、ストック写真の円形アバター、名＋姓のイニシャルを使ったお客様の声カルーセル。
  • この見せ方がプロダクトに合うかどうかにかかわらず、料金プランは常に 3 段階で、真ん中のプランを色付きの枠線と「最も人気」のラベルで強調します。
  • コントラストの強い光彩／アクセントシャドウのボタン — 視覚的な階層やブランドとの整合性に関する明確な理由もなく、視覚的な小手先の工夫として、プライマリー CTA ボタンにコントラストの強いグラデーション、強いドロップシャドウ、または光るブランドカラーのハローをデフォルトで適用します。
1d. ざっと見てわかる兆候の表

技術的なことを始める前に、サイトを開いて10秒間見てください。コードを調べなくても目に入る兆候です。

兆候見るポイント
紫／青のグラデーション多くのAIツールは、似たような青から紫へのグラデーションをデフォルトで使います。一度気づくと、もう見過ごせません。通常はヒーローの背後にラジアルブラーが使われています。
どこもかしこもグラスモーフィズムブランドに関係なく、標準的な「プレミアム」表現として使われる、白い境界線付きのすりガラス風カードです。
パーティクルネットワーク／ニューラルネットワーク風のビジュアル製品の機能を具体的に示すものがないまま、「AI」や「データ」を表す汎用的な記号として、線でつながった点が浮かんでいます。
アイコンカードの弁当箱型グリッドLucide／Heroiconと汎用的なメリット説明文2～3行をそれぞれ配置した、角丸の正方形カードが3つまたは6つ並んでいます。
一貫性のない余白セクションごとにマージンやパディングが異なるため、ページのリズムが不均一に感じられます。一貫した余白は、熟慮されたデザインを示す最も明確な兆候のひとつです。それがないのは見抜く手がかりになります。
タイポグラフィの階層が弱いデフォルトのフォント、不自然な行の長さ、一貫性のない見出しサイズ、詰まった行間は、いずれも文字組みが適切に設定されていないことを示しています。
コントラストが低い白い背景に薄いグレーの文字が使われていたり、文字と背景のコントラストが弱かったりします。WCAGでは通常のテキストに最低4.5:1のコントラスト比が定められていますが、多くのAIでよく使われる配色はこの基準を満たしていません。
どのカードも同じホバー効果カードがすべて同じように浮き上がったり光ったりする効果が、実際に操作可能であることを示す必要性に関係なく一律に適用されています。
過剰なキラキラ／AI絵文字「AI搭載」を視覚的に示すものとして見出しやボタンに✨が多用されていますが、今ではそれ自体が見抜く手がかりになっています。

簡易テスト： ブラウザーの幅を狭めるか、スマートフォンで開いてみてください。AIが生成したレイアウトは、モデルに具体的な指示が与えられていない画面サイズでは、崩れたり、重なったり、はみ出したりすることがよくあります。ブレークポイントごとの実際のレスポンシブQAは、最初に省かれる工程のひとつです。

代わりに： 実際のビジュアル要素をひとつだけ選びましょう。具体的なイラスト、製品の実際のデータフローを示す図、実際のインターフェースのスクリーンショットなどです。控えめに表示し、十分な余白を取りましょう。本格的な製品を提供する企業は、AIでよく使われる質感を寄せ集めるのではなく、ひとつの画面にひとつの明確なアイデアを置きます。

セクション2 — 色とタイポグラフィ（ウェブデザイナー／UIデザイナーの視点）

2a. 色のデフォルト設定
  • ブランドから特に指定がない場合に、自動的に「テック」系の配色として、紫／バイオレット（#7c3aedのような色）またはインディゴを、青やピンクと組み合わせること。
  • 熟慮された、わずかに暖かみや冷たさ、個性のある黒や白ではなく、純粋な黒（#000000）または純粋な白（#ffffff）を背景に使うこと。
  • ダークモードをデフォルトにする判断を、見た目だけを理由に行うこと。デモで見栄えがよい、または高級感があるという理由で、コンテンツや利用状況、ユーザー層に必要とされているかどうかを考慮していません。
  • このブランドがグラデーションを使う理由を説明できないまま、グラデーションボタンを主要なCTAのスタイルにすること。
  • 「鮮やか」が要件だったという理由で、ひとつのデザインシステムにアクセントカラーを5色以上使うこと。実際のデザインシステムは抑制を基本に作られます。アクセントカラー、機能用の配色、意味を表す配色をそれぞれひとつずつ使います。
  • 出どころの説明がない色の選択。製品のブランド、カテゴリー、対象ユーザーを考慮した理由が説明されないまま、応答に16進数のカラー値が記されています。
2b. タイポグラフィのデフォルト設定
  • ウェイト400、600、700のみのInterを使い、見出し用のディスプレイ書体は使わず、本文にコントラストをつけるためのセリフ体も使わず、Interがこのブランドに適した選択かどうかも検討しません。
  • 大きなディスプレイ見出しの letter-spacing: 0 のまま字間を調整しないこと。プロフェッショナルなタイポグラフィシステムでは、ポイントサイズが大きくなるほどトラッキングを詰めます（letter-spacing: -0.02em〜-0.05em）。72pxの見出しでデフォルトのトラッキングを使うと、テンプレートのように見えます。
  • Tailwindのtracking-wide／tracking-wider／tracking-tightユーティリティを考えなしに適用し、大文字表記をデフォルトの強調スタイルとして使うこと。どちらも、タイポグラフィ上の明確な理由がある場合にのみ使ってください。また、ユーザーから指示がない限り、既存テキストの確立された大文字・小文字の使い分けを変更しないでください。
  • サイズとウェイト以外に視覚的な文字階層がないこと。本文、ミュート表示、薄い表示のテキストがすべて同じ色で、フォントサイズだけで区別されています。実際の階層には、少なくとも3段階のトーンを使います。
  • コンテキストごとの行の高さを考慮しないこと。12pxのキャプションにも56pxの見出しにも、同じline-height: 1.5を使います。
  • タイポグラフィの階層を考える代わりに、あらゆる箇所のラベルをすべて大文字にすること。
  • 本文の強調手段として、フォントウェイト700（「太字」）だけを使うこと。イタリックも、スモールキャップスも、色による強調も使いません。

代わりに： 具体的な情報源、つまり製品カテゴリ、意図的に差別化する特定の競合製品、またはクライアントから提示されたブランド上の制約ひとつをもとに、パレットを導き出してください。使う前に、16進数のカラー値とその根拠を明示してください。書体を指定する前に、どの書体を使うのか、そしてその理由を明示してください。

プロトコル

これを実行してください。リストを参考資料として開いたままにして、結局はデフォルトのやり方を選ぶだけではいけません。それこそが、このスキルの初期バージョンが「参照」されていたにもかかわらず、凡庸な成果物を生み続けた原因です。

1a. 作成前に軸を定める

この成果物が忠実であるべき具体的な対象をひとつ挙げてください。実際の題材や製品、その対象者、そしてこのページ、コンポーネント、ドキュメント、設定ファイルが果たすべき唯一の役割です。ブリーフですでに方向性が定まっている場合は、そのとおりに従ってください。明示的な指示を、自分の参考例に置き換えてはいけません。

ブリーフに余地がある場合は、照らし合わせるための具体的で実在する参考例を1〜2件挙げてください。「モダン」「すっきり」「信頼できる」「プロフェッショナル」といった雰囲気ではなく、製品の情報密度、印刷物の伝統的な段組みルール、意図的に差別化する特定の競合製品、題材の世界にある素材や道具など、実際に名前を挙げられるものにしてください。参考例がひとつだけだと、模倣を招きます。異なる要素をふたつ組み合わせれば、新しいものを生み出せます。「このハードウェアのデータシートの率直さに、農事暦のタイポグラフィの温かみを掛け合わせる」とすれば、模倣する対象がひとつではなく、ふたつの軸の間を探ることができます。

これは、初期のチェックリストだけのバージョンに欠けていたステップです。単なるフィルターでは、何を作ってはいけないかはモデルに伝えられても、代わりに何を作るべきかは伝えられません。そのため「代わりに」は、別の経路をたどって同じ方向へと戻りがちです。参考例を挙げることこそが、成果物を実際に別の方向へ動かします。

1b. 下書きを作る

軸をもとに、実際の成果物、つまりコピー、レイアウト、コンポーネント、設定ファイル、ドキュメントを作ってください。最初に思いついたパターンをもとにしてはいけません。

1c. フィルターをかける

該当する以下の参考ファイルと照らし合わせて、下書きを確認してください。参考ファイル内のいずれかのセクションで2項目以上に当てはまる場合は、選択したのではなく、デフォルトに流されています。 破棄して、ステップ1の軸をもとに作り直してください。表面的な調整、たとえばアイコンを変える、見出しを大きくする、紫の色合いを変えるといった方法で、同じ下書きを修正してはいけません。それは改訂ではなく、同じデフォルトに別の衣装を着せただけです。

現在のタスクで実際に関係するファイルだけを読み込んでください。コピーだけのタスクなら、DevOpsの参考資料を開く必要はありません。

1d. 自己確認

成果物を見せる前に、references/self-check-and-pushback.mdにある6つの質問を確認してください。「いいえ」または「わかりません」という回答がひとつでもあれば、見せる前に修正してください。

1e. 記録 — 同じセッション内で複数の作業を行う場合のみ

Claude は別の会話にまたがって記憶を保持しません。「世代をまたいで同じ選択に決して収束しない」といったルールが一貫性を持つのは、アクティブなセッション内に限られます。セッションをまたいでも成り立つと主張しても、モデルの実際の動作に照らせば通用しません。そのようなことをユーザーにほのめかさないでください。

セクション 3 — コピーライティングとコンテンツ戦略（コンテンツ開発者の視点）

ユーザー向けのあらゆる種類の文章（マーケティングコピー、ランディングページ、ドキュメント、記事、エッセイ、ソーシャル投稿、メール、UI テキスト）を作成、執筆、改訂する場合は、常にこのセクションを使用してください。

3a. 文型と構文の陳腐な表現
  • 「今日の目まぐるしく変化する／デジタルな／変化し続ける世界では……」 — 具体的な主張を述べる代わりに、広い背景を説明する前置き。
  • 「[名詞] を解き放つ／引き出す／高める／強化する／実現する」 — 曖昧な力づけを表す動詞＋所有格＋抽象名詞。SaaS コピーで最も使い古された構文の型です。
  • 「あなたが [X] でも [Y] でも、[製品] にお任せください。」 — あらゆるペルソナに同時に訴えかけようとする、見せかけの包括的な書き出し。
  • 「[悩み] にさよならしましょう。」 — 悩みがパーティーを去る登場人物であるかのような表現。
  • 「あらゆる規模のチームのために構築」や「あらゆる段階の [速度／規模／チーム] のために構築」 — 対象ユーザーを明確にするのを避けるための曖昧な表現。
  • 形容詞やフレーズを三つ並べる表現 — 内容の薄さを網羅的に見せるために、三つ並べる表現（例：「高速。高信頼。安全。」「シンプル。強力。柔軟。」「革新的で、変革をもたらし、画期的」）。
  • 否定を用いた並列表現 — 「これは X ではなく、Y です」のような構文（「これは単なる製品発表ではなく、ムーブメントです」など）。
  • 対比による見せかけの再解釈 — 実質的な対比がないところで、「しかし」を使いすぎて、内容に深みがあるように見せる表現。
  • 同じ主張を繰り返すダッシュ文 — 「私たちが構築しているのはソフトウェアだけではありません。働き方の未来を構築しています。」のように、後半が新しい情報を加えていない表現。
  • 文頭に置く接続詞や移行表現 — 「さらに」「加えて」「そのうえ」「したがって」などを文頭で何度も使い、つなぎとして水増しする表現。
  • 同じ動名詞で始まる箇条書きの機能一覧 — 「ワークフローを効率化する。パイプラインを自動化する。デリバリーを最適化する。」のように、動名詞＋所有格の名詞を 6～8 項目にわたって繰り返す表現。
  • AI のストーリーテリングにおけるお決まりの展開／物語構成 — どのランディングページのセクションでも定型的な「問題―煽り―解決」の構成を使うことや、基本的な機能リリースを劇的な「英雄の旅」として描くこと。
3b. 構成とセクション内容の定番パターン
  • 「ホーム | 製品」や「会社概要 | 会社」のような一般的なページタイトル — 検索エンジンにもユーザーにも具体的な情報を伝えないタイトル。
  • ユーザーの検索意図に直接答えるのではなく、パンフレットのようなメタディスクリプション。
  • LinkedIn 風の「私たちのストーリー」／「会社概要」 — [年] に創業し、業界を変革する使命を掲げ、情熱あふれるチームが世界クラスの製品を提供している、といった要約。
  • 修辞疑問文による書き出し — 読者が尋ねてもいない質問で、ブログ記事やガイドを始めること（「[一般的な業界の問題] の理由について考えたことはありますか？」など）。
  • 「機能」「ソリューション」「選ばれる理由」「始める」のような曖昧な名詞のセクション見出し — 明確な主張や約束を示さない見出し。
  • 「始める」「詳しく見る」「無料で試す」のような一般的な CTA ボタンの文言 — アクションによって得られる具体的な結果を示さない文言。
  • 内容の薄い FAQ — 実際の購入相談で出る質問や反論ではなく、「[製品] とは何ですか？」「始めるにはどうすればよいですか？」のような、作り上げた導入の質問に答える内容。
  • 出典のないソーシャルプルーフ — 顧客名や成果を確認できないのに、「[N]+ チームに信頼されています」「大手企業に選ばれています」と主張すること。
  • 定型的なドキュメントの構成案 — 記事の最後に「課題」や「今後の展望」のような一般的なセクションを置き、空虚な行動喚起で締めくくること。
3c. トーン、語り口、編集上の論評に関する既定値
  • 個性をそぎ落とした「プロフェッショナル」な文体 — 平板で無難、競合他社のどこにでも当てはまる文体です。
  • ペルソナへの抽象化 — ユーザーを「あなた」と呼びながら、具体的な問題を抱えた一人の人ではなく、「あなたのようなチームには……が必要です」のような抽象的なペルソナとして描写します。
  • 中身のない流行語 — 裏付けとなる根拠なしに、「シームレス」「直感的」「パワフル」「堅牢」「最先端」「クラス最高」などを使います。
  • 主語が不明確なまま能動態をまねる表現 — 文法上の主語がない、「チームがより速くリリースできるようにする」のような宙に浮いたフレーズです。
  • 誇張や重要性の水増し — 根拠なしに重要性を主張し、ありふれた事実を「変革をもたらすもの」や「より大きな動き」の一部として描写します。
  • 情報を加えない付け足しの節 — 「……地域の伝統が今も受け継がれていることを反映しています」のように、情報を加えず漠然とした意義を示す現在分詞のフレーズを後付けします。
  • 責任の所在をぼかす表現と曖昧な出典 — 出典を明示せず、「批評家の中にはそう言う人もいます」「多くの人がそう考えています」「専門家はこう指摘しています」と意見の出所をぼかします。
  • 表面的な論評 — 汎用的な肯定的コメントを挿入したり、珍しい事実を平凡な主張に「ならしたり」します。
  • 過剰な婉曲表現や限定表現 — 不必要に主張を弱めます。
3d. 語彙とリズムの特徴

AI モデルは、予測しやすい語彙と滑らかすぎる文章のリズムを使いがちです。次の表現は見つけ次第、削除してください。

  • 使いすぎる形容詞： 「入り組んだ」「活気に満ちた」「極めて重要な」「極めて重大な」「最重要の」「不可欠な」「長く続く」「細心の」「深遠な」。
  • 使いすぎる動詞： 「深く掘り下げる」「活用する」「高める」「共鳴する」「強化する」「強調する」「乗り出す」「育む」「紹介する」「例証する」。
  • 使いすぎる名詞： 「織物」「状況」「証し」「相互作用」「提供物」。
  • 使いすぎるつなぎ言葉： 「さらに」「そのうえ」「したがって」「結果として」「結論として」「『注意すべきなのは／忘れてはならないのは』」「『これについて語るなら、必ず触れなければならないのは』」。
  • 完璧だが平板なリズム — 脱線が一切なく、会話のような不揃いさもなく、どの段落も同じ長さです。
  • くだけた文章における手紙のような丁寧さ — 「ご健勝のこととお喜び申し上げます」「お時間を割いていただき、誠にありがとうございます」。
3e. 書式上の癖、定型句、残存する AI 生成の痕跡
  • 見出しや箇条書き項目での太字やタイトルケースの多用。
  • カンマやコロンを使うべき箇所に、両側にスペースを入れたダッシュ（—）を多用すること。標準的な表記規則にも反しています。
  • 技術文書の見出しでのカギ括弧や絵文字。
  • 不適切な見出し階層（例：H1 から H3 へ直接飛ぶ）。
  • 会話の名残 — 「お役に立てば幸いです！」「もちろんです！」「ほかに必要なことがあればお知らせください。」
  • 未編集の定型文 — 穴埋め式の指示が完成したコンテンツに残っています。
  • 知識のカットオフや安全性に関する免責事項 — リスクのない話題に、「専門家に相談することが重要です」のような不要な免責事項を付け加えます。
3f. 幻覚に近い表現と宣伝調の特徴
  • 捏造された引用や指標 — 偽の引用、創作した調査、または主張に添えられた無効な出典リンク。
  • 宣伝調への逸脱 — 中立的な報告を求められているのに、広告のような言葉遣いが続きます。
  • 「SNS で積極的に発信している」という癖 — 対象について「活発な SNS での存在感を維持している」と述べます（LLM 特有の言い回しです）。
  • ロマンチックな表現 — ありふれた話題に「文化遺産」「受け継がれる遺産」「活気に満ちた状況」といった表現を過剰に用います。

代わりに： この製品にしか当てはまらない一文を書いてください。競合他社が自社のウェブサイトにそのままコピーしても、明らかにおかしいとわかる一文です。社名を入れ替えても通用するなら、その文は削除してください。誰にでも当てはまる文体ではなく、この製品を支える具体的な人々と、彼らにとって大切なことを意識して書いてください。

セクション 4 — UX デザインと情報アーキテクチャ（UX デザイナーの視点）

40年の経験を持つUXリサーチャーや情報アーキテクトがヒューリスティック評価で指摘するようなパターンです。

4a. ページとフローの構成におけるデフォルト
  • すべてのランディングページで、同じセクションの順序を採用する — ヒーロー → ロゴ一覧 → 特徴（3枚または6枚のカード） → 仕組み（3ステップ） → お客様の声カルーセル → 料金（3プラン） → FAQアコーディオン → 最後のCTAバナー → フッター — この順序が個々のコンバージョン目標に適しているかを確認せず、すべての製品に適用します。
  • 実際のプロセスに必要なステップ数に関係なく、番号付きのステップがちょうど3つある「仕組み」セクション。
  • 画面上部に進捗バーがあり、スキップする選択肢がないオンボーディングフロー — ユーザーが価値を得る前にすべてのステップを完了する必要が本当にあるかを考慮せず、あらゆる登録フローにデフォルトの「ウィザード」パターンを適用します。
  • 「項目が見つかりません」とだけ表示する空の状態 — 項目が何なのか、どうすれば作成できるのか、次に何をすればよいのかを説明しません。
  • 「問題が発生しました」や「エラーが発生しました」と表示するエラーメッセージ — 次に取るべき行動を示さず、問題の原因についても説明しません。
  • インライン検証がないフォーム — すべてのエラーが送信後に、一度に、フォームの先頭にのみ表示されます。
  • 確認が必要な操作すべてにモーダルダイアログを表示する — トースト通知やインラインの切り替え表示のほうが邪魔にならないような、簡単に元に戻せる操作も含みます。
  • ユーザーが完了しようとしているタスクについてのメンタルモデルではなく、社内の部門構成を反映したナビゲーション項目。
  • パンくずリストを表示してもナビゲーション上の価値が増えないほどサイトの階層が浅い場合でも、すべてのページにパンくずリストを生成する。
4b. インタラクションデザインにおけるデフォルト
  • すべてのホバー状態を、不透明度を下げるか色を明るくするだけで表現する — opacity: 0.7 にするかベースカラーに色合いを加えるだけで、要素に別の操作可能性のシグナルが必要かどうかは考慮しません。
  • 「見た目が悪い」という理由でフォーカススタイルを削除または抑制する — 美的な好みを装ったアクセシビリティ上の不備です。
  • すべてのセクションでスクロール連動アニメーションを使う — 「動きがあってよい」という理由で、コンテンツに動きが役立つかどうかに関係なく、要素を上にスライドさせたり、フェードインさせたり、スクロールに合わせて拡大・縮小させたりします。
  • 表示位置に戻る手段がない無限スクロール — ページネーションが「古い」と感じるため、すべてのリストに適用します。
  • 表示ナビゲーションに十分な横幅があるタブレットのブレークポイントでも、ハンバーガーメニューを使う。
  • モバイルで44×44px未満のクリック領域 — モバイルのユーザビリティで最もよく見られる不備であり、最も簡単に防げる不備でもあります。
  • ローディング状態やスケルトンスクリーンがない — コンテンツが表示されるか、スピナーが表示されるかのどちらかで、その中間がありません。
  • 重要な情報にアクセスする唯一の手段としてツールチップを使う — ホバー状態の背後に隠された情報には、タッチデバイスからアクセスできません。
4c. アクセシビリティのデフォルト（軽視される分野）
  • カラーコントラスト比を確認しない — WCAG 2.1 AA（通常のテキストは4.5:1、大きなテキストは3:1）への適合を確認せず、見た目だけでテキスト色と背景色を選んでいます。
  • alt テキストのない画像、またはファイル名をそのまま繰り返したり、「画像」とだけ記したりするaltテキスト。
  • アクセシブルなラベルのないアイコンのみのボタン（aria-labelがない） — 見た目がゴミ箱アイコンのボタンでも、スクリーンリーダーの利用者には意味が伝わりません。
  • 関連付けられた<label>要素のないフォーム入力 — ラベルの代わりにプレースホルダーテキストを使っており、入力を始めると消えてしまいます。
  • クリックハンドラーを付けたインタラクティブ要素に<div>や<span>を使用しながら、roleもtabindexもキーボードイベントハンドラーも設定していません。
  • 見出しレベルを飛ばす — <h3>の見た目が適切だからと<h1>から<h3>に飛び、スクリーンリーダー向けのドキュメント構造を壊しています。
  • キーボード利用者向けの「メインコンテンツへスキップ」リンクがない — そのため、ページを開くたびにナビゲーション全体をTabキーで移動する必要があります。
  • prefers-reduced-motionメディアクエリのないアニメーション — 前庭障害、てんかん、または動きに敏感な利用者がアニメーションを無効にできません。
4d. モバイルとレスポンシブレイアウトの粗雑さ
  • モバイルでもデスクトップと同じパディングを適用 — 小さなビューポートにも同じ上下のパディング（例：padding: 80px 0や120px 0）を適用し、コンテンツが間延びして、過剰なスクロールが必要になります。
  • タイポグラフィを直線的に拡大・縮小 — 最小値や最大値を設定せず、標準的なテキストサイズ変更やビューポート幅の単位を使用することで、小さなスマートフォンでは見出しが極端に小さくなったり、読めなくなったりします。
  • 画像を直線的に拡大・縮小 — トリミングやレイアウト変更をせずに画像をそのまま縮小すると、幅320pxの画面では細部が見えなくなります。
  • 要素が重なる、または切れる — グリッド構造を調整せず（例：モバイルでも3列の特徴紹介を維持する）、テキストのはみ出しや折り返し、レイアウトのクリッピングが発生します。

代わりに: この特定のページで、訪問者に何をしてもらう、または何を信じてもらう必要があるのかを問い、すべての要素をその目的に沿って構成してください。目的に寄与しないものはすべて取り除きます。本当の情報設計とは、引き算です。

セクション5 — フロントエンドのWeb開発（Web開発者の視点）

40年の経験を持つフロントエンドエンジニアなら、コードレビューで指摘するようなパターンを紹介します。

5a. HTMLのデフォルト
  • セマンティックHTMLを使わず、レイアウト全体を<div>と<span>で構築 — <main>、<nav>、<header>、<footer>、<article>、<section>、<aside>、<figure>を使用していません。セマンティックHTMLは単なる飾りではなく、ドキュメントモデルそのものです。
  • 段落の区切りに<p>要素と適切なマージンを使わず、<br><br>を使用しています。
  • クラスベースのスタイル設定ではなく、インラインのstyle属性をマークアップ全体に散在させる。
  • width属性とheight属性のない画像 — 読み込み時にレイアウトシフト（累積レイアウトシフト、CLS）が発生します。
  • <meta name="description">、<meta property="og:title">、<link rel="canonical">がない — 最低限必要なSEOおよびソーシャル共有用メタデータが欠けています。
  • <title>タグをフレームワークのデフォルトのままにする — 「React App」「Vite App」「My Next.js Project」を本番環境にそのまま出荷しています。
  • <html>にlang属性がない — スクリーンリーダーが適切な言語プロファイルを使用できません。
  • リンクテキストが具体的でない — 遷移先を説明するテキストではなく、「こちらをクリック」「続きを読む」「詳細を見る」を使用しています。
5b. CSS のデフォルト
  • すべてのインタラクティブ要素に transition: all 0.3s ease を適用する — インターフェース内のすべての動きに、単一のイージング関数と単一の継続時間を適用します。実際のモーションデザインでは、要素のサイズ、移動距離、意味上の重要度に応じて、イージングや継続時間を変えます。
  • 詳細度の競合を解決するために !important を使う — 根本にある詳細度の問題を修正するのではなく、!important で上書きします。
  • CSS にマジックナンバーを使う — margin-top: 37px、padding: 13px 22px のように、スペーシングスケールとの関連がない値です。
  • 色、スペーシング、タイポグラフィに CSS カスタムプロパティ（変数）を使わない — 何百行にもわたって値をそのまま繰り返します。
  • フォントサイズと行の高さにすべて px 単位を使い、rem／em を使わない — ユーザーのブラウザーのフォントサイズ設定が反映されなくなります。
  • z-index: 9999（または 999、99999）を、定義されたスタッキングコンテキストの方針なしに、強引な手段として使います。
  • メディアクエリを任意のブレークポイントで定義する（768px、1024px はタブレットやデスクトップに「適しているように感じる」ため）— コンテンツに適した自然なブレークポイントを使いません。
  • 本文に max-width を設定しない — 幅の広いモニターでは文章が 1400px まで広がり、読みにくくなります。
  • Flexbox と Grid のどちらかが不適切な場合も含め、すべてに CSS Grid または Flexbox を使う — 二次元のグリッドレイアウトに Flexbox を使ったり、単一軸のフローに Grid を使ったりします。
5c. JavaScript のデフォルト
  • 本番コードに console.log を残します。
  • ループ内で DOM ノードにイベントリスナーを直接登録する — イベント委譲を使わないため、メモリリークが発生します。
  • エラーハンドリングなしでデータを取得する — .catch() もローディング／エラー状態もない fetch(url).then(r => r.json()).then(setData) です。
  • React で、実際には依存関係があるのに宣言されていない useEffect の依存配列 [] を、componentDidMount の代わりとして使います。
  • 引き上げるべき状態をコンポーネントのローカル状態に保存する — その結果、10 階層も深いコンポーネントまで props を受け渡すことになります。
  • 機能フラグ全体を if (process.env.NODE_ENV === 'development') で実装する — これは実際の機能フラグではなく、環境による制御にすぎません。
  • 型を追加すると「時間がかかりすぎる」ため、TypeScript でどこにでも any 型を使う — TypeScript を使う目的そのものを損ないます。
  • ユーザー提供のコンテンツを DOM に描画する前に入力をサニタイズしない — XSS の脆弱性がデフォルトで入り込みます。
  • 適切なローディング状態やイベントリスナーの代わりに setTimeout を使う — 遅い接続ではうまく動かないハックとして、setTimeout(() => setLoaded(true), 500) を使います。
5d. パフォーマンスのデフォルト
  • 最適化されていない画像 — 表示サイズでフル解像度の PNG や JPEG を配信し、WebP、srcset、ファーストビューより下にある画像の loading="lazy" を使いません。
  • すべての JavaScript を単一のバンドルで読み込む — コード分割、動的インポート、ルートベースのチャンク分割を行いません。
  • サードパーティのスクリプトを <head> で同期的に読み込む — Google Analytics、チャットウィジェット、A/B テスト用スクリプトが、ページの描画前にメインスレッドをブロックします。
  • Web フォントに font-display: swap を指定しない — フォントの読み込み中にテキストが表示されない（FOIT）状態になり、システムフォントが一時表示される（FOUT）状態になりません。
  • ファーストビューで使われないスタイルに対しても、レンダリングをブロックする CSS を <link rel="stylesheet"> で読み込む。
  • 使わないウェイトやスタイルの Web フォントまで読み込む — 可変フォントの 18 種類すべてのウェイトを「念のため」読み込みます。

代わりに： コンポーネントやページを書く前に、その中に含めるセマンティック要素、データフロー、エラー状態、ローディング状態を明確にしてください。それらを挙げられない場合は、そのコンポーネントを作る準備ができていません。

セクション 6 — DevOps とプラットフォームエンジニアリングの視点

これらは、40 年の経験を持つシステムエンジニアや SRE がインフラストラクチャのレビューで指摘するパターンです。

6a. CI/CD パイプラインのデフォルト設定
  • すべてのプロジェクトに、ビルド → テスト → デプロイの3段階パイプラインを適用します。プロジェクトにテストがあるか、複数のデプロイ先があるか、「main への push」以外のデプロイ戦略があるかどうかは考慮されません。
  • パイプラインの YAML ファイルにシークレットをハードコードします。API_KEY: "abc123" をシークレットストアから参照せず、ワークフロー定義に直接記述します。
  • on: push によって、デプロイを意図していないブランチも含め、すべてのブランチでパイプラインを実行します。ブランチのフィルタリングもパスのフィルタリングもありません。
  • node_modules、依存関係レイヤー、ビルド成果物のパイプラインキャッシュがありません。実行のたびに依存関係の全体を再ダウンロードします。
  • CI 環境で npm ci ではなく npm install を使用します。インストール結果が一定せず、ローカル開発環境と異なる場合があります。
  • ステージング環境もスモークテストもデプロイゲートもなく、main へのマージ後すぐにデプロイします。
  • ヘルスチェックでは HTTP 200 だけを確認します。アプリケーションが正しいコンテンツを実際に提供しているか、下流の依存関係に到達できるかは検証しません。
6b. Docker とコンテナ化のデフォルト設定
  • FROM node:latest（またはその他の latest タグ）を使用します。ビルドの再現性がなく、上流のイメージが更新されると、気付かないうちにビルドが壊れる可能性があります。
  • コンテナを root として実行します。Dockerfile に USER の指定がなく、USER node も名前付きの非 root ユーザーも設定されていません。
  • 依存関係のインストール前に COPY . . でプロジェクトディレクトリ全体をコンテナにコピーします。依存関係に影響しない変更も含め、ソースの変更のたびに Docker レイヤーキャッシュが無効になります。
  • .dockerignore ファイルがありません。node_modules、.git、テストファイル、ローカルの環境ファイルがイメージにコピーされます。
  • 開発環境全体（コンパイラー、開発ツール、テストランナー）をマルチステージビルドを使用せずに本番イメージに含めるため、イメージが数 GB にもなります。
  • HEALTHCHECK 命令がありません。コンテナ内のアプリケーションが実際に準備できているかどうかにかかわらず、起動直後にコンテナは正常と報告されます。
6c. Infrastructure-as-code のデフォルト設定
  • Terraform または CloudFormation に、環境名、リソースサイズ、リージョン名を変数化せずにハードコードします。環境間で再利用できません。
  • リモートの状態バックエンドがありません。Terraform の状態がローカルに保存されるため、インフラストラクチャを共同で管理できません。
  • 自動化されたパイプラインで terraform plan のレビューを行わずに terraform apply を実行します。人が読める差分を確認せずにインフラストラクチャの変更を適用します。
  • すべてのインフラストラクチャを1つのモノリシックなファイルにまとめます。main.tf の1か所に2,000行を記述し、ネットワーク、コンピューティング、データベース、IAM を扱います。
  • クラウドリソースのタグ付け戦略がありません。コストの割り当て、所有者の特定、リソースのライフサイクルポリシーの実装ができません。
  • セキュリティグループのアクセス範囲が広すぎます。VPC または特定の IP 範囲からのみアクセスできるようにすべきポートの受信ルールに、0.0.0.0/0 を指定します。
  • ログの保持ポリシーがありません。有効期限が設定されていないため、ストレージバケットやロググループにログが無期限に蓄積されます。
6d. モニタリングと可観測性のデフォルト
  • 構造化ログがない — タイムスタンプ、リクエスト ID、重大度レベル、機械で解析可能な形式がなく、console.log("something happened") のような文字列だけです。
  • ダウンタイム時のみアラートを送信する — レイテンシのパーセンタイル（p95、p99）、エラー率のしきい値、飽和のシグナルに対するアラートがありません。
  • あらゆるメトリクスを網羅する30個のパネルがあるダッシュボード — このダッシュボードで「正常」と「障害」がどのような状態か、明確に答えられません。
  • アラートからランブックへのリンクがない — オンコール担当のエンジニアに通知が届いても、問題の調査や修正の手順が文書化されていません。
  • 単一環境でのモニタリング — 本番環境は監視してもステージング環境は監視しないため、リグレッションが本番環境でしか検出されません。

代わりに: 生成するインフラストラクチャやパイプラインのコードごとに、本番環境、チームの規模、デプロイ頻度を明示してください。それらが不明な場合は、汎用的な3段階の YAML を生成して本番環境対応と呼ぶのではなく、不明だと伝えてください。

セクション 7 — コンテンツ開発とドキュメント（テクニカルライター／コンテンツストラテジストの視点）

7a. ドキュメントのデフォルト
  • 使い方を説明せず、プロジェクトの概要だけを記載した README ファイル — 機能の説明が何段落も続き、バッジの列があり、最後にインストールコマンドが1行あるだけです。
  • クリーンなマシンを前提とするインストール手順 — 必要な Node のバージョン、Python のバージョン、システム依存関係、環境変数の設定について触れていません。
  • 「Getting Started」と「Full API Reference」が区別された導線がない — 初心者もエキスパートも、同じ平坦なドキュメント構成に放り込まれます。
  • エラー時の処理を示さないコード例 — うまくいく場合だけを示し、「これが 401 を返したらどうすればよいか」は示しません。
  • 具体性のない「バグ修正とパフォーマンス改善」という変更履歴 — Apple の iOS リリースノートをそのまま写したような、同じく何の情報も得られない内容です。
  • パラメーターしか記載していない API ドキュメント — エンドポイントをいつ使うのか、どのような前提条件を満たす必要があるのか、呼び出し後に呼び出し側が何をする責任を負うのかを説明していません。
  • ドキュメント内の古いスクリーンショット — 現在は存在しない UI を表示しており、システム内のほかのすべてのドキュメントへの信頼を損ないます。
7b. コンテンツ戦略のデフォルト
  • 読者がその頻度で記事を読むのか、継続できるだけの独自の素材があるのか、記事が実際にどれだけ届くのかを分析せずに、「週2記事」と設定された公開頻度。
  • キーワードの検索ボリュームだけでトピックを選ぶ — プロダクトチームが真に専門知識や見解を持つテーマではなく、検索ボリュームが最も多いテーマについて書きます。
  • プロダクトの購入者がそもそも検索を利用するかを知らずに、デフォルトの SEO コンテンツ戦略として生成される「ピラーページ」と「クラスターコンテンツ」の構成。
  • 実施内容は説明しても結果を示さない事例紹介 — 「Company X のダッシュボード再設計を支援しました」と記載しながら、変更前後の指標がありません。
  • 編集せずにブログ記事として自動公開される動画の文字起こし — 話し言葉の文法は書き言葉の文法とは異なり、そのまま置き換えられるものではありません。

セクション 8 — 分野横断的なコード品質（すべてのエンジニアリング職種）

これらは、あらゆる技術分野に共通する問題です。

  • 巨大なコンポーネント／巨大な関数 — データ取得、ビジネスロジック、フォーマット、エラー処理、レンダリングをすべて担う単一の React コンポーネントまたは関数です。各分野における「巨大な単一ファイル」に相当します。
  • React ツリーにエラーバウンダリがない — 単一のコンポーネントで障害が発生すると、画面が真っ白になり、UI サブツリー全体が表示されなくなります。
  • 起動時に環境変数を検証しない — アプリケーションは起動後しばらく正常に動作しますが、10 分後に不足している API キーを使おうとした時点で、根本原因とは無関係に見える不可解なエラーが発生します。
  • コミットメッセージに git commit -m "fix" や git commit -m "update" を使う — 背景や対象範囲がなく、履歴を見ても何が変更されたのか分かりません。
  • package.json で依存関係を ^major.minor.patch に固定する — マイナー更新とパッチ更新が自動的に許可されるため、6 か月後には同じ npm install でも異なる結果になります。
  • .nvmrc も package.json の engines フィールドもない — 必要な Node のバージョンがどこにも記載されておらず、古いランタイムや新しいランタイムでプロジェクトがひそかに失敗します。
  • 成功するケースだけをテストするテスト — リグレッションを検出するのではなく、テストに通るように設計されています。
  • わずかに異なるコードを 3 つのファイルにコピーして使う — 抽象化されたパラメーター付き関数を使わないため、ロジックの変更が必要になった際に、3 つのバグが同時に発生します。
  • プロジェクトの規模に対して過剰に複雑な抽象化を導入する — 個人開発プロジェクトにマイクロサービス、4 ページのサイトにデザインシステム、ToDo リストにイベントソーシングを導入することなどです。
  • 一時ファイルをリポジトリに残す — 作業中の確認に使った一時的なテストスクリプトや使い捨ての .js／.ts／.py ファイルを、削除せずに残してしまうことです。タスクの途中で確認用に作成したファイルは、完了とする前に削除してください。
  • 説明過多なコメント — コードの自明な動作にコメントを付けることです（例：// starts loop や // check if id exists）。コードコメントでは、何をするかではなく、なぜそうするかを説明してください。
  • 画一的／汎用的な変数名 — モジュールを問わず、理論上「完璧」すぎる、または汎用的すぎる変数名のことです（例：reconSummary や hasFetchedProfile のようなドメイン固有の名前のほうが明確なのに、const dataList = ...、const isLoaded = ...、const resultObj = ... とすること）。
  • 未使用のインポートとプロパティの肥大化 — AI のボイラープレートテンプレートに含まれていたというだけで、ファイル内で一度も使わないライブラリ（例：lodash、axios）やプロパティをインポートすることです。

セクション 9 — 最終セルフチェック（すべての専門分野）

出力を見せる前に、視覚、コピー、構造、技術のどの面でも、次の質問に答えてください。答えが「いいえ」または「わかりません」なら、見せる前に修正してください。

  1. この出力は、この製品、チーム、または状況に固有のものですか？ コード、コピー、デザインをそのまま別の製品に持ち込んでも、正しいものとして通用しますか？ そうなら、汎用的です。修正してください。

  2. これが適切だから選びましたか。それとも、最初に思いついたからですか？ LLM が最初の直感で出すものは、定義上、学習データの統計的な平均です。平均はプレミアムではありません。平均は粗悪な出来です。

  3. この選択を裏付ける、具体的で明確な事実はありますか？ 実際の測定値、明示された制約、具体的なユーザーニーズ、実際のビジネスルールです。雰囲気や、「テック企業っぽく見えたから」ではありません。

  4. この分野で40年の経験を持つ実務家が、これを出すのを恥ずかしいと思うでしょうか？ あなたが書いたコードより多くの悪いコードを書いてきたシニアエンジニアなら、こうしたパターンを数秒で見抜けます。コードレビューを求めるでしょうか？ コピーに赤字を入れるでしょうか？ デザインレビューで却下するでしょうか？

  5. これが「何をしないか」を明示しましたか？ 実務のプロが出す成果物には、制約、エッジケース、明確な非目標が含まれます。粗悪な出来が説明するのは、うまくいく場合だけです。

  6. ユーザーの役に立つからではなく、あるべきだと思っただけで、この出力に含めたものはありますか？ 3つ目の料金プラン、FAQ セクション、「会社概要」ページ、ダークモード、パーティクル背景。存在する理由を説明できないなら、削除してください。

セクション 10 — 反論を受けたときの対応

ユーザーから「まだ AI が作ったように見える」「ありきたりで粗悪だ」「どの SaaS サイトとも同じに見える」「ジュニアでも書ける」と言われた場合：

してはいけないこと： 余白を調整する。色を変える。アイコンを別のものに差し替える。セクションを増やす。フォントを大きくする。

すること： 上記チェックリストのうち、自分が安易に選んでしまった項目を特定してください。明確にこう伝えます。「私は［パターン］に安易に頼りました。置き換え案は［具体的で、根拠のある代替案］です。」そのうえで、表面的な変更を加えた前の草案ではなく、その置き換え案を出発点に作り直してください。

40年の経験を持つ実務家と、モデルが定番の選択肢を生成することとの違いは、技術ではありません。具体的な存在理由のない草案を捨てる意思があるかどうかです。

第 2 部 — 自分が作っていないサイトの監査

セクション 1〜10 は、公開前に自分の作業をチェックするためのものです。以下の3つのセクションは逆の状況を扱います。URL を渡されて AI が作ったように見えるかを判断するよう求められる場合や、他の誰か、おそらく別の AI がすでに作成したサイトを整えるよう求められる場合です。根底にあるパターンは同じですが、視点が異なります。書くのではなく、読むのです。

セクション 11 — ソースコードからわかる兆候／「ソースを表示」

右クリック → ページのソースを表示（Windows では Ctrl+U、Mac では Cmd+Option+U）で、生の HTML を確認できます。以下の点に注目してください。

  • AI が書いたコメントが残っている。 開発者の中には、コード内のセクションに AI 生成であることを明示するコメントを残す人もいます。まれですが、見つかればすぐに確認できます。
  • 単純な機能に対して過剰に複雑な構造。 簡単な処理をするバイブコーディングのスクリプトでも、実際のロジックは 10 行しかないのに、リポジトリパターン一式、抽象基底クラス、依存性注入、ファクトリーメソッドまで含んでいる場合があります。人間の開発者は、問題の規模に応じて複雑さを調整します。
  • 同じサイト内で一貫しないパターン。 認証が、あるモジュールではひとつのパターンを使い、別のモジュールではまったく異なるパターンを使っているのに、筋の通った理由がない場合があります。これは、統一的なアーキテクチャを考慮せず、別々のプロンプト／セッションが独立して判断した兆候です。
  • 膨れ上がった依存関係リスト。 バイブコーディングされたプロジェクトでは、シンプルな Web アプリに 80 個以上の依存関係を取り込んでいる場合があります。それぞれが、標準ライブラリで代用せずにモデルが反射的に選んだライブラリです。
  • JS バンドル内のビルダー／ツールの痕跡。 ビルダーのブランド表示を取り除いたカスタムドメインのサイトでも、JavaScript バンドルを調べると、Lovable のアーティファクト文字列、v0 のコンポーネントパターン、ブランド表示の削除後も残る Bolt のランタイム識別子が見つかることがあります。
  • 「AI のデフォルトスタック」。 Next.js + Tailwind CSS + Shadcn UI + Lucide Icons + Radix UI は、AI コーディングツールがデフォルトで選ぶコンポーネントスタックです。これだけでは証拠になりません（人間が意図的にこのスタックを選ぶケースも多くあります）が、ほかの兆候と組み合わさると可能性が高まります。
  • メタタグの不自然さ。 メタタグの奇妙な表記や汎用的な言い回しは、表示されるページのコンテンツが人間によって書かれた場合でも、AI ツールが生成した可能性を示します。

セクション 12 — 技術面／パフォーマンスからわかる兆候

  • 予想より遅い読み込み時間。 AI 生成コードは必要以上に重いことが多く、Core Web Vitals のスコアを下げます。Chrome DevTools → Lighthouse、または PageSpeed Insights で確認してください。
  • アクセシビリティの不備。 人間による出力のレビューがない場合、代替テキストの欠如、ラベルのないボタン、キーボード操作への対応不足がよく見られます。
  • SEO／AEO の基本的な設定の欠如。 メタディスクリプションがない、Open Graph 画像がない、ページタイトルが重複している、構造化データがない、見出し階層が浅い、または省略されているといった点は、SEO の確認を経ずに公開されたサイトであることを示します。
  • 実際のバックエンドを示す要素がない。 入力フォームに入力してもどこにも送信されないサイトや、先に進めない「サインアップ」フローは、UI は生成されていても、その背後で動くバックエンドがまだ用意されていない場合によく見られます。

セクション 13 — 戦略面／ビジネスの文脈からわかる兆候（最も重要で、偽装が最も難しい）

これは純粋なコードスキャンツールでは検出できない層であり、最も信頼できる兆候と言えるでしょう。

  • サイトの明確な役割がない。 Web サイトのように見えても、通話を予約する、見込み客を獲得する、見込み客を選別するといった特定の目的を果たすように作られていません。ただ存在するだけです。
  • コンバージョンへの配慮がない。 ページ構成、ユーザーの導線、行動喚起が、設計された経路ではなく後付けのように感じられます。
  • ポジショニングの空白。 誰を対象にしているのか、なぜほかの選択肢ではなくこのサイトを選ぶべきなのかが明確に説明されていません。そもそもモデルには機能一覧を説明するよう指示されただけで、そうした戦略的な背景が与えられていなかったためです。

セクション 14 — リポジトリとデプロイの権限

  • ユーザーに代わって git init、git add、git commit を実行しないでください。 また、明示的に依頼されない限り、プッシュやデプロイも行わないでください。作業を行い、リポジトリへの操作はユーザーに任せてください。

セクション 15 — 失敗事例

失敗例 1：ありきたりなコピーとストーリーテリング（セクション 3 に違反）

問題提起・煽り・解決策の粗雑な文面： 「チームのタスク管理に何時間も費やすことにうんざりしていませんか？手作業で締め切りを追いかけるのはストレスになります。今すぐ業務を向上させましょう！TaskSync で可能性を解き放ち、生産性を飛躍的に高めましょう。高速。安全。信頼性抜群。チームのことを考えて設計されています。」

失敗する理由： 苦痛と煽りを繰り返す定型パターンに従っています。「解き放つ」「向上させる」「飛躍的に高める」といった使い古された動詞を使い、「3 つ並べるルール」に沿って形容詞を並べています。

失敗例 2：コードの定型文と自明なコメント（セクション 8 および 5c に違反）
import React, { useState, useEffect } from 'react';
import axios from 'axios'; // UNUSED IMPORT
import _ from 'lodash';    // UNUSED IMPORT

export default function UserList() {
  // state for users
  const [dataList, setDataList] = useState([]); // generic name dataList

  useEffect(() => {
    // fetch user data
    fetch('/api/users')
      .then(res => res.json())
      .then(data => setDataList(data));
  }, []);

  return (
    <ul>
      {/* loop through users */}
      {dataList.map(item => <li key={item.id}>{item.name}</li>)}
    </ul>
  );
}

失敗する理由： 未使用のインポート（axios、lodash）、汎用的な命名（dataList）、行ごとに書かれた自明なコメント（// state for users、// fetch user data、/* loop through users */）があります。

コメント

Markdown 対応