Web制作で使いやすいAIはどれ？

Web制作で使うAIは、デザイン案や文章の相談をしたいのか、既存リポジトリを変更してテストまで回したいのかで選び方が変わります。前者ならChatGPT、Claude、Geminiなどのチャットから試せます。後者ならCodex、Claude Code、Antigravity CLIなど、ファイルとコマンドを扱う開発環境も比較対象です。どれが一番よいかは、制作物と既存ルールを同じ条件で試すまで決められません。

最初に、作業を「企画・文章」「デザイン素材」「実装」「保守」に分けます。全工程を一つへ任せるより、変更範囲、合格条件、止める操作を先に決める方が、手戻りを減らせます。

作業段階から候補を選ぶ

表は横にスクロールできます

今の仕事	試す入口	確認すること
要件整理、ページ構成、文章案	ChatGPT / Claude / Geminiのチャット	前提や読者像が成果物に残るか
画面案、画像、説明図	使用中のデザイン環境と画像機能	元データを編集できるか、権利・ブランド条件は何か
既存コードの調査と修正	Codex / Claude Code / 対応するAntigravity環境	リポジトリ、コマンド、テストへのアクセス範囲
公開後の保守	上記の開発環境	変更差分、再現手順、テスト結果を確認できるか

この表は製品の性能順位ではなく、どの作業場所で試すかを選ぶためのものです。同じ名前のAIでも、チャット、IDE、CLI、組織向けライセンスで使える機能と権限が異なります。

企画・文章は、作業条件を渡せるチャットから始める

サイト構成やCTAを相談するときは、サービス名だけを伝えるより、読者、ページの目的、既存のブランド表現、変更できない条件を一緒に渡します。たとえば「問い合わせを増やしたい」だけでなく、「対象読者、避ける表現、本文の文字数、既存の見出しを維持」と書けば、確認する箇所が明確になります。

ChatGPT、Claude、Geminiは文章や調査、ファイルの整理などを幅広く扱えます。ただし無料・有料、地域、アカウント、利用上限で使える機能は変わります。画像生成やファイル読み込みが必須なら、いま使うアカウントで実際に選択できるかを確認します。

デザインとコードの境界を先に決める

画像やUI案を作れることと、デザインシステムに合う編集可能な成果物ができることは別です。Figmaなどの既存環境を中心にするなら、画像生成だけでなく、コンポーネント、余白、フォント、色のルールを保てるかを確認します。完成画像しか残らない場合、後から細部を直す手間が増えることがあります。

コード相談だけなら通常チャットで十分な場面があります。リポジトリ全体を読み、複数ファイルを変更してテストするなら、開発エージェントの方が作業の流れに合います。CodexやClaude Codeはリポジトリを読み、ファイル編集やコマンド実行を行う開発環境として案内されています。

Googleの個人向けGemini CLIとGemini Code Assist IDE拡張は、2026年6月18日以降、個人向けGemini Code Assist、Google AI Pro、Ultraでの提供が終了し、対象ユーザーにはAntigravity CLIへの移行が案内されています。Standard / Enterpriseなど組織ライセンスの条件は別です。古い記事や動画の「Gemini CLIが無料で使える」という説明を、そのまま現在の契約判断に使わないでください。

小さなLP修正で比較する

実力を比べるなら、同じ入力と初期状態を使います。まず公開前の複製ページか小さなサンプルを用意し、依頼文に次を含めます。

• 変えてよいファイルと、触れないファイル

• 画面幅、見た目、アクセシビリティの合格条件

• 実行してよいコマンドと禁止する操作

• 変更後に通すlint、test、build

• デプロイ、認証情報、削除、外部送信の前で止まること

完了後は、見た目の近さだけでなく、リンクやフォームの動作、モバイル幅、エラー、差分の読みやすさを確認します。人が修正に使った時間も記録します。生成が速くても、後から直す時間が増えるなら開発全体では得になりません。

失敗したときに見る場所

表は横にスクロールできます

症状	切り分け	次の手
既存デザインとずれる	禁止・維持ルールが依頼に含まれたか	色、余白、コンポーネント例を追加して再試行
画面は作れたが動かない	クリック、入力、画面遷移を確認したか	合格条件に操作結果を追加
修正範囲が広がった	変更対象と止まる地点が明記されたか	変更ファイルを限定し差分レビューを要求
モバイルで崩れる	小さい画面の基準が依頼にあったか	390px相当で確認し、該当箇所だけ修正
テストが通らない	エラーと変更箇所が結びついているか	変更前後を分け、テストを再実行

この手順はAIの品質を保証するものではありません。問題を早く見つけ、元へ戻せる範囲で試すためのものです。

実装を依頼する前の作業メモ

AIへコード変更を頼む場合は、まず「何を作るか」ではなく、何を変えてよいかを決めます。たとえば既存サイトの問い合わせボタンを直すなら、次のように整理します。

• 目的：スマートフォンで問い合わせボタンが画面外へはみ出さないようにする。

• 対象：ヘッダーのボタンと、そのスタイルだけ。

• 維持するもの：色、文言、リンク先、PC表示。

• 確認条件：390px幅で横スクロールがなく、リンクが正しいページへ移動する。

• 止まる操作：本番公開、フォーム送信、他ページへの一括変更は実行しない。

作業後は、変更ファイルの一覧、変更理由、実行した確認、未確認の点を分けて報告させます。指示に「直して」だけを使うより、完了条件を先に書く方がレビューしやすくなります。

公開前の確認表

表は横にスクロールできます

確認箇所	見るもの	不合格なら
見た目	PCと390px幅で配置、文字切れ、余白	画面幅と崩れた箇所を指定して再修正
操作	ボタン、フォーム、リンク、戻る操作	期待した操作結果を一つずつ定義
内容	数字、会社名、リンク先、法的表現	原資料や依頼文へ戻って人が照合
保守性	変更範囲、既存パターン、命名	差分を小さくし、不要ファイルの変更を戻す
技術確認	lint、テスト、build、エラー	失敗したコマンドと原因を分けて対応
公開	本番環境、認証情報、外部送信	人の承認を残して作業を止める

一度で全部を任せる必要はありません。要件整理、画面案、実装、QAに分け、各段階で成果物を確認すれば、方向がずれたときに早く戻れます。

画像生成と実装は成果物の形式まで見る

ヘッダー画像や挿絵を作る場合は、画像の見た目だけで決めず、Webで使う比率、背景透過の要否、文字を画像に含めるか、後から編集する担当者を決めます。日本語の見出しを画像内に焼き込むと、スマートフォンで読めない、文言変更のたびに作り直す、といった負担が出ます。装飾画像はAI、実際のUI文字はHTMLのように役割を分ける方法もあります。

コード生成では、動くかどうかと、既存サイトに安全に入るかを分けて確認します。画面が表示されても、フォーム送信先を変えていたり、既存のアクセシビリティ属性を消していたりすることがあります。AIには「変更したファイルだけ示す」「触れた理由を説明する」「変更しなかった条件も報告する」と依頼し、差分を担当者が読みます。

Web制作でAIを使わない方がよい場面

完成した画像やコードを見ただけで、権利、セキュリティ、法的適合性まで判断することはできません。外部サービスへ顧客の素材を送る場合、ライセンスが不明な画像を公開する場合、本番データベースや決済を変更する場合は、AIへ任せず担当者が確認します。テスト用の複製環境を用意できない作業も、まず安全な確認手順を整えるところからです。

比較ログには「見栄え」「操作」「既存コードとの整合」「人の修正時間」を別の欄にします。画面の印象だけで採用せず、動作と差分が確認できた箇所だけを候補に残します。

見た目の再現を重視する仕事では、元デザインとの比較画像を保存し、直した差分だけを確認します。文章案が中心なら、公開前にリンク先と事実を別の担当者が確認します。

手戻りが残る場合は、AIへ一度に複数の工程を頼まず、要件、コード、画面確認を分けて試します。

比較の条件を揃えた記録は、数週間後に別ツールを試すときにも役立ちます。

同じ作業を比べるときは、結果だけでなく次の3点をメモします。

• AIに渡した前提を、成果物がどれだけ保てたか

• 公開前に人が直した箇所と、その所要時間

• 変更差分や利用した素材を後から追えるか

たとえば「LPの見出し案を作る」だけでは、コード編集環境の良さは比べられません。文章案なら文章案、既存ページの修正なら複製ページの修正というように、各候補が得意とする作業条件を揃えます。採用判断は、最初の出力の印象ではなく、確認後に使える状態までの合計時間で行います。

AIものさし編集部の判断

Web制作では、チャットで仕様を整理する段階と、リポジトリへ変更を入れる段階を分けて考えます。依頼文や画像案までなら普段使うチャットから。実装や保守なら、既存コード、テスト、差分を扱える環境から試します。

最初の比較対象は、自分がよく行う作業を一つに絞ります。同じ小規模LPの修正を依頼し、成果物の品質だけでなく、確認と手直しにかかった時間を記録する。そこまでできてから、Web制作で継続利用する候補を決めるのが現実的です。

未実施の検証

同じ小規模LPを対象に、

• 指定デザインへの再現

• React / Next.js実装

• レスポンシブ修正

• 既存コードを壊さないか

• Lighthouseやアクセシビリティ上の問題

• 修正指示に必要だった往復回数

を同条件で比較するテストは、この記事ではまだ実施していません。

自分の条件なら？

新規制作なのか、既存サイトの修正なのか、WordPressなのか、React / Next.jsなのかでも選び方は変わります。AIものさしのかんたん診断から、自分の作業に合う候補を絞れます。