ChatGPT vs Gemini vs Claude｜同じHTMLを書かせてみたら、見た目は似ているのにコード設計がまるで違った

前回の「同じ議事録を書かせてみた」を公開してから、「次はいよいよコードですよね？」というお声を、社内外から本当にたくさんいただきました。予告どおり、検証シリーズ第4弾は コード領域 に踏み込みます。

営業メール・提案書・議事録の3本で、ChatGPT・Gemini・Claude は「文体」ではなく「構成レベルで違う」ことが分かってきました。今回のお題は日本語ではなく HTML です。同じワイヤーフレームと同じ要件を3社に渡して、1枚のランディングページを書かせてみました。

というわけで、「ChatGPT vs Gemini vs Claude、同じHTMLを書かせてみた」 です。

「同じHTML、書かせてみた」検証シリーズVol.4の図。ChatGPT・Gemini・Claude が作った KAMI-LESS の LP とそれぞれの HTML コードを並べている

検証の前提を先に共有します

前回・前々回と同じく、比較の前に条件をそろえておきます。

使ったモデルは、いずれも 2026年7月時点の各社の主力モデル（ChatGPT／Gemini／Claude いずれも有償プランの標準モデル）
プロンプトは 一言一句同じ ものを投げる
会話の履歴は すべて新しいスレッド から開始
カスタム指示、メモリー機能、システムプロンプトは すべてオフ
生成は 1回だけ。書き直し・追加指示なし
添付するワイヤーフレームは 同一の画像1枚。テキスト要件も一言一句同じ
生成されたHTMLはそのまま index.html として保存し、Chrome の同一バージョン・同一ウィンドウ幅（1440px／375px）でスクリーンショットを取る
コードも 無編集 のまま掲載する

同じ条件、同じお題、同じ回数。前回までと同じルールで並べます。

ChatGPT・Gemini・Claude の HTML 比較の条件をまとめた図。同じワイヤーフレーム画像・同じプロンプト・同じ生成回数(1回のみ)で3社の LP とコードを並べている

今回作らせるLP

議事録の検証で使った架空案件と地続きにするため、題材は 中小企業向けに紙業務のデジタル化を提供するBtoBサービス「カミレス（KAMI-LESS）」の1枚LP としました。

構成は複雑にしすぎず、以下の5セクションに絞っています。

ヘッダー（ロゴ、お問い合わせボタン）
ファーストビュー（キャッチコピー、説明文、CTAボタン、右側に管理画面イメージ）
課題セクション（3つの課題を横並び）
特徴セクション（3つの特徴を横並び）
最下部CTA

3社の実装差を見やすくするため、あえて「機能を詰め込みすぎない」設計にしています。

AI に渡した LP のワイヤーフレーム。①ロゴとお問い合わせ ②キャッチコピーとCTAとダッシュボード画像 ③よくある3つの課題 ④サービスの特徴 ⑤無料相談の申し込み

今回使ったプロンプト

前回と同じく、「役割／素材／目的／制約」の4ブロックで組み立てました。

あなたは、BtoBサービスのランディングページを制作する
フロントエンドエンジニアです。

添付したワイヤーフレームと以下の要件をもとに、
1ページのランディングページをHTMLで作成してください。


#サービス概要
サービス名／カミレス
サービス内容／中小企業に残る紙の申請書・日報・チェックシートを、
              簡単にデジタル化できる業務改善サービス
ターゲット／紙業務の削減を進めたい中小企業の経営者・管理部門責任者


#掲載内容


##ヘッダー
-ロゴテキスト「KAMI-LESS」
-お問い合わせボタン


##ファーストビュー
-キャッチコピー／紙の業務を、今日からデジタルに。
-説明文／現場の申請書や日報を、専門知識なしでデジタル化。
          集計・確認・管理にかかる時間を削減します。
-CTA／無料相談を申し込む
-右側に、管理画面を模したUIを配置


##課題
-紙の申請書が社内にたまっている
-集計や転記に時間がかかっている
-現場の進捗をすぐ確認できない


##特徴
-既存の紙帳票をそのままデジタル化
-スマートフォン・PCの両方に対応
-導入後の運用までサポート


##最下部CTA
-紙業務の悩みを、まずはご相談ください
-無料相談を申し込む


#デザイン要件
-BtoB向けの、信頼感がある明るいデザイン
-メインカラーは青
-背景は白または淡いグレー
-最大幅は1200px程度
-デスクトップでは横並び、スマートフォンでは縦並び
-過度なアニメーションは使用しない


#実装条件
-HTML・CSS・JavaScriptを1つのHTMLファイル内に記述する
-外部CSSフレームワークは使用しない
-外部JavaScriptライブラリは使用しない
-画像素材は使用せず、CSSまたはHTML要素で代替する
-レスポンシブ対応を行う
-セマンティックなHTMLを使用する
-アクセシビリティに配慮する
-主要ブラウザで表示できるコードにする
-コードは省略せず、完成状態で出力する
-コード以外の説明文は出力しない

HTMLはメールや議事録と違って、「正解」に近い基準が言語化しやすい 領域です。だからこそ、AIごとの判断が露骨に差になります。

ChatGPT のHTML

まずは ChatGPT から。ブラウザで開くと、こんな見た目が返ってきました。

ChatGPT が作った KAMI-LESS の LP をブラウザで開いた画面。ワイヤーフレームどおりの構成で「型がきれい」と評価

コードの一部（<head> の CSS と、ファーストビュー付近）を抜粋します。

<style>
  { box-sizing: border-box; margin: 0; padding: 0; }
  body {
    font-family: "Helvetica Neue", Arial, "Hiragino Kaku Gothic ProN", sans-serif;
    color: #1f2937;
    background: #f9fafb;
    line-height: 1.7;
  }
  .container { max-width: 1200px; margin: 0 auto; padding: 0 20px; }
  .header { background: #fff; border-bottom: 1px solid #e5e7eb; }
  .header-inner {
    display: flex; justify-content: space-between; align-items: center;
    padding: 16px 0;
  }
  .logo { font-size: 20px; font-weight: 700; color: #2563eb; }
  .btn {
    display: inline-block; padding: 12px 24px;
    background: #2563eb; color: #fff; border-radius: 6px;
    text-decoration: none; font-weight: 600;
  }
  .hero { display: flex; gap: 40px; padding: 80px 0; }
  .hero-text { flex: 1; }
  .hero-image { flex: 1; background: #e5e7eb; border-radius: 12px; min-height: 320px; }
  @media (max-width: 768px) {
    .hero { flex-direction: column; }
  }
</style>

前回・前々回で見せていたキャラが、コードでも安定して出てきました。

構成が教科書どおり。header／section／footer を素直に使い、クラス名も .hero .features .cta と、誰が見ても意味が分かる命名
CSS は素直で読みやすい。CSS変数（--primary）は使わず、色コードを直接書き込む。深いネストもなく、真上から真下に流れる
メディアクエリは1箇所だけ。768px でだけ切り替える、いわゆる「モバイル対応の最小構成」
CTA・課題・特徴の構造がテンプレート的。同じ .card クラスを使い回し、迷いがない

体感としては、「そのまま社内ツール／管理画面LPに貼れる完成度、9点」 です。

一方で、「ChatGPT らしさ」もあります。全体的にキレイに整いすぎていて、アクセシビリティ配慮は最低限。CTA ボタンは <a class="btn"> で作られているものの、aria-label や focus-visible の指定はなく、prefers-reduced-motion にも触れない。デフォルトのフォーカスリングだけで済ませています。

もうひとつ気になるのは、ハンバーガーメニューを勝手には付けない ことです。ワイヤーフレームどおり「ロゴ＋お問い合わせボタン」だけを素直に置くタイプで、良くも悪くも プロンプトの外に出ない。

ChatGPT 版の CSS コードの画面。クラス名が素直、メディアクエリ1箇所、aria-label なしという特徴の注記つき

Gemini のHTML

続いて Gemini です。同じワイヤーフレームを、同じ初期状態のスレッドに投げました。

Gemini が作った KAMI-LESS の LP をブラウザで開いた画面。指定にない導入企業ロゴの帯が追加され「勝手に足す」「アニメが乗る」と評価

コードの一部（Gemini 版の CSS 抜粋）はこんな感じです。

<style>
  :root {
    --color-primary: #2563EB;
    --color-primary-dark: #1D4ED8;
    --color-bg: #F8FAFC;
    --color-text: #0F172A;
    --shadow-card: 0 8px 24px rgba(15, 23, 42, 0.08);
    --radius: 12px;
  }
  html { scroll-behavior: smooth; }
  body {
    font-family: "Inter", "Noto Sans JP", sans-serif;
    background: var(--color-bg);
    color: var(--color-text);
  }
  .hero {
    background: linear-gradient(180deg, #EFF6FF 0%, #F8FAFC 100%);
    padding: 96px 0;
  }
  .card {
    background: #fff; border-radius: var(--radius);
    box-shadow: var(--shadow-card);
    padding: 32px; transition: transform .2s ease;
  }
  .card:hover { transform: translateY(-4px); }
  @keyframes fadeInUp {
    from { opacity: 0; transform: translateY(16px); }
    to { opacity: 1; transform: translateY(0); }
  }
  .hero-text, .card { animation: fadeInUp .6s ease both; }
  @media (max-width: 1024px) { /* タブレット向け */ }
  @media (max-width: 640px)  { /* スマホ向け */ }
</style>

こちらもキレイですが、ChatGPT とは違うキャラがしっかり出ています。

CSS変数を惜しみなく使う。--color-primary --shadow-card --radius を最初に定義し、以降はすべて変数経由で参照
プロンプトで指定していない @keyframes fadeInUp を勝手に足してくる。デザイン要件には「過度なアニメーションは使用しない」と書いたのに、「過度ではない範囲」という自主判断で、フェードインとホバーの浮き上がりを追加
プロンプトで指定していない「導入企業ロゴ」の帯セクションを足してくる。しかもロゴは <div> にダミーテキストを入れて filter: grayscale(1) をかけた、それらしい見た目
メディアクエリは1024px と 640px の2段構え。タブレット領域まで自主的に切り分けてくる
フォントは Inter と Noto Sans JP を CDN から読み込もうとする。実装条件で「外部ライブラリ禁止」と書いたのに、<link> の記述までは残す（読み込み失敗時のフォールバックはある）

体感としては、「デザイナーがそのままクライアントに見せられるモック、8.5点」 です。

Google 系列らしく、Gemini は 「見た目の完成度を上げるために、指定範囲を少しだけ越える」 タイプ。導入企業ロゴやフェードインは、多くの営業LPで「あった方がいい」と言われる要素です。ただ、プロンプトの実装条件と真っ向から衝突する外部フォント読み込みまで書いてくる のは、レビュアーによってははっきり NG です。

議事録のときの「会議の背景を勝手に足す」と、キャラの根っこは同じでした。指定外の情報を、"良かれと思って" 追加してくる のが Gemini の一貫した傾向です。

Gemini 版の CSS コードの画面。変数を活用、勝手にアニメーション、勝手にセクション追加という特徴の注記つき。レスポンシブは4段階

Claude のHTML

最後に Claude です。同じ条件で投げてみた結果がこちら。

Claude が作った KAMI-LESS の LP をブラウザで開いた画面。ボタンにフォーカス枠があり「アクセシビリティ配慮」「セマンティックHTML」と評価

コードの一部（Claude 版の HTML 構造と CSS 抜粋）はこんな感じです。

<body>
  <a class="skip-link" href="#main">本文へスキップ</a>
  <header class="site-header" role="banner">
    <div class="container header-inner">
      <p class="logo"><a href="/" aria-label="カミレス トップへ">KAMI-LESS</a></p>
      <a class="btn btn-primary" href="#contact">お問い合わせ</a>
    </div>
  </header>

  <main id="main">
    <section class="hero" aria-labelledby="hero-title">
      <div class="container hero-inner">
        <div class="hero-text">
          <h1 id="hero-title">紙の業務を、今日からデジタルに。</h1>
          <p>現場の申請書や日報を、専門知識なしでデジタル化。<br>
             集計・確認・管理にかかる時間を削減します。</p>
          <a class="btn btn-primary btn-lg" href="#contact">無料相談を申し込む</a>
        </div>
        <div class="hero-visual" aria-hidden="true">
          <svg viewBox="0 0 480 320" role="img"> ... </svg>
        </div>
      </div>
    </section>

    <section class="issues" aria-labelledby="issues-title"> ... </section>
    <section class="features" aria-labelledby="features-title"> ... </section>
  </main>

  <section class="cta" id="contact" aria-labelledby="cta-title"> ... </section>
  <footer class="site-footer" role="contentinfo"> ... </footer>
</body>

そして、CSS 側にも Claude ならではの1文が入っていました。

:focus-visible {
  outline: 3px solid #FBBF24;
  outline-offset: 2px;
}
@media (prefers-reduced-motion: reduce) {
   { animation: none !important; transition: none !important; }
}

3つのなかで、いちばん 「見えないところ」に手が入っている 実装が返ってきました。

本体は極めてタイト。プロンプトで指定した5セクションを、header main section footer に素直にマッピングし、div のネストが浅い
skip-link（本文へスキップ）を自主的に追加。ワイヤーフレームにも要件にも書いていないのに、キーボード操作向けの導線を先頭に置く
すべての section に aria-labelledby を付与。見出し要素と結びつけて、スクリーンリーダー向けの構造を明示
ダミー管理画面は SVG で描画。プロンプトの「画像素材は使用せず、CSSまたはHTML要素で代替する」に対して、div の重ね合わせではなく、SVGで正面から答える
prefers-reduced-motion に対応。過度なアニメーションを禁じたプロンプトを、"ユーザー環境" の観点でもう1段強化
:focus-visible のフォーカスリングを自作。デフォルトの薄いリングではなく、コントラストの効いた色で置き換える

体感としては、「アクセシビリティ試験まで通しやすいコード、9.5点」。

一方で、Claude も課題があります。まず、HTML の行数が最も長い。aria-labelledby や role の付与、skip-link の追加、SVG のインライン記述などで、他の2社より15〜20%ほどコード量が増えます。加えて、ダミー管理画面の SVG はコードが冗長になりがち で、あとから中身を差し替える人にとっては、そのブロックだけ独立して読まなければならない負担が増えます。

議事録のときの「補足メモを分離する」に近い挙動が、HTMLでは「見えないユーザーに対する情報を、コードとして残す」 という形で顔を出しました。属人化を防ぎたい現場ほど刺さる タイプの実装です。

Claude 版の HTML コードの画面。指定外に自主的に追加された skip-link、全セクションへの aria-labelledby、prefers-reduced-motion 対応の注記つき

3つを並べて分かったこと

ここまでの結果を、前回までと同じフォーマットで整理します。

ChatGPT … クラス名が素直、CSS はフラット、メディアクエリ1箇所、aria-* は最小限、そのまま公開できる汎用LP向き
Gemini … CSS変数を活用、指定していないアニメーションと導入企業ロゴを勝手に足す、外部フォントも書いてくる、デザインモック・営業提案向き
Claude … セマンティックHTMLを厳格に守る、skip-link や aria-labelledby を自主追加、prefers-reduced-motion にも対応、アクセシビリティ・長期運用向き

比較表にすると、こうなります。

比較項目	ChatGPT	Gemini	Claude
見た目の完成度	◎	◎	○
ワイヤーフレーム再現度	◎	○（余分に足す）	◎
HTML構造	○	○	◎
CSS設計（変数・保守性）	△	◎	◎
レスポンシブ	○	◎	◎
アクセシビリティ	△	○	◎
修正しやすさ（色・要素差替え）	○	○	◎
実装条件の順守度	◎	△（外部フォント記述）	◎

前回（議事録）は 「議事録の外側を、どこまで、どんな形で残すか」 で差が付きました。今回のHTMLでは、「プロンプトの指定範囲を、どちら向きに越えるか」 で明確に差が付いています。

ChatGPT … 指定範囲の "外" には出ない（型を守る）
Gemini … 指定範囲の "見た目側" に出る（デザイン加点を狙う）
Claude … 指定範囲の "見えない側" に出る（アクセシビリティ・環境対応を厚くする）

同じワイヤーフレームを渡しても、「良い実装」の定義そのもの が3社で違う。ブラウザで開いた瞬間は「どれも整ったLP」に見えるのに、HTMLを開くと設計思想がまるで違った のが、今回の一番の学びです。

3社の「指定範囲をどう越えるか」の比較図。ChatGPT は越えない(社内ツール向き)、Gemini は見た目側に越える(デザインモック・営業提案向き)、Claude は見えない側に越える(アクセシビリティ・長期運用向き)

AIコーディングで見えた「選定の判断軸」

営業メール・提案書・議事録検証のときと同じことを繰り返しますが、AI選定はやはり 「業務でよく使うお題」を、同じ条件で並べてみる のが最短でした。

そのうえで、HTMLという切り口で見えた判断軸は、次の3つです。

「その HTML を、この先誰が触るか」を先に決める。自分ひとりで使い切る使い捨てLPなら ChatGPT、デザイナーがレビューする提案モックなら Gemini、複数人で長期運用するプロダクトLPなら Claude
「厳密な要件をどこまで守らせたいか」を先に決める。実装条件やブランドガイドが厳しい案件は ChatGPT が最も安全。「気の利いた足し算」を歓迎する案件は Gemini・Claude が刺さる
「見えないユーザーへの配慮を、どこまで含めるか」を先に決める。アクセシビリティやモーション配慮を要件として明記していない案件でも、"自主的に" 積んでほしいなら Claude 一択

コードの中身よりも、「そのコードは、誰が、いつ、何のために触り続けるのか」を先に言語化しておくと、AI 選びは驚くほどラクになります。ここは、前3回の営業メール・提案書・議事録と、まったく同じ結論です。

次回予告 ── 「同じExcel分析をさせてみます」

検証シリーズの次回は、予告どおり 「同じExcel分析をさせてみた」 です。

営業メール・提案書・議事録は「日本語の文書」、今回のHTMLは「コード」でした。次回は 数値・データ の領域に入ります。同じCSVを渡して、3つの AI に 売上データの分析と示唆出し をさせてみます。

Excel 分析は、HTMLと同じで「正解／不正解」の線が引きやすい一方で、"どの指標を主役にするか" "どの数字にどう意味づけするか" という判断で、AI ごとのキャラが露骨に差になります。実務で「AIにデータ分析を任せる先を決めたい」方は、次回もお付き合いください。

その次以降は、以下の順で予定しています。

同じキャッチコピーを書かせてみた
同じ議事録から「営業提案メール」を書き起こさせてみた（追加候補）
同じユーザーインタビュー録から示唆を抽出させてみた（追加候補）

「このお題も検証してほしい」というリクエストがあれば、ぜひお知らせください。読者のみなさまの日々の業務で「モヤっと」しているお題ほど、検証する価値があると思っています。

まとめ

ChatGPT・Gemini・Claude に 同じワイヤーフレームと要件 を渡してカミレスLPを書かせたところ、ブラウザで見た完成形は似ているのに、HTMLを開くと設計思想がまるで違った
ChatGPT は型が教科書どおりでプロンプトの外に出ない、そのまま公開できる汎用LP・社内ツール向け の実装に強い
Gemini は CSS変数を活用しつつ、指定していないアニメーションや導入企業ロゴを勝手に足す、デザインモック・営業提案 に強い
Claude はセマンティックHTMLを厳格に守り、skip-link や aria-labelledby、prefers-reduced-motion を自主的に積む、アクセシビリティ・長期運用 に強い
3社の違いは「見た目」でも「文法」でもなく、「プロンプトの指定範囲を、どちら向きに越えるか」 という判断レベルで起きていた
「そのコードは、誰が、いつ、何のために触り続けるのか」を先に言語化しておくと、AI 選びは一気にラクになる

3つの AI を契約しているなら、HTMLは「そのあと誰が触るか」で使い分けるのが結論です。前3回の営業メール・提案書・議事録とあわせて、ご自身の業務での AI 使い分けマップ に、今回で「コード領域」の1本を加えてみてください。次回のExcel分析で、この地図に「データ領域」がもう1本加わります。