AIはWebサイトのコーディングをどこまでできるのか。お問い合わせフォームのカンプを渡して実測してみた

デザインカンプがある。入力チェックの条件やエラー時の文言といった仕様も、ひととおり用意した。あとは実装するだけ——というフォームを、人の手を一切入れずにAIへ丸ごと投げたら、どこまで形になるのか。

コーディングをAIに任せる話は、もう珍しくもありません。精度も、少し前とは比べものにならない速さで上がっています。

なので、試してみました。出てきたものを、フロントエンドエンジニアの目で一つずつ見ていきます。

検証の条件

結果の前に、何をどんな条件で試したかだけ整理します。

AIに渡したのは、実装を依頼するプロンプト1通と、そこで参照する2つの資料——フォームのデザインカンプと、バリデーション（入力チェック）の定義書です。

指示は、実装の専門家が書くようなものではなく、依頼する側が用意する要件のレベルにとどめました。本来なら制作側で補う細部は、あえて指定していません。実際に渡したプロンプトは次のとおりです。

以下のFigmaデザインをもとに、お問い合わせフォームをコーディングしてください。
　■ Figmaカンプ：https://www.figma.com/design/**********
　■ バリデーション定義：別紙の一覧表を参照してください

【実装範囲】
　■ 入力画面のみの実装をお願いします
　■ 確認画面・完了画面への遷移は不要です（バックエンド側で処理するため）

【バリデーションのタイミング】
　■ 各項目は、入力が終わったタイミングで検証し、OK／エラーの状態を表示してください
　■ 「入力内容を確認する」ボタンを押したときは、全項目を一括で検証してください
　　■ エラーがなければ、そのまま送信処理に進む想定です（送信処理自体の実装は不要）
　　■ エラーがある場合は、該当箇所にエラーを表示し、最初のエラー箇所までスクロールしてください

【バリデーションの内容】
　■ 各項目のエラー条件とエラーメッセージは、別紙の一覧表に従ってください
　■ OK状態・エラー状態のデザインは、カンプに含めているものに従ってください

【入力補助】
　■ 「お名前」を入力したら、フリガナ欄に自動で読みを入力してください

【技術要件】
　■ 純粋なHTML/CSS/JavaScriptで実装（フレームワークは使わない）

よろしくお願いします。

プロンプト内で「別紙の一覧表」と呼んでいるのが、次のバリデーション定義書です。

環境は、Claude Code（デスクトップ版）で Opus 4.8 を動かし、そこに Figma公式のリモートMCP を接続。設定ファイル（CLAUDE.md）は置かず、空のディレクトリから生成させました。

AIはここまで作れた

プロンプトとバリデーション定義書を渡すと、21分で HTML・CSS・JavaScript の3ファイルが生成されました。ブラウザで表示した結果と、元のカンプを並べます。

レイアウト、配色、余白、フォント、必須・任意のバッジ——見た目の大枠は、PC・スマホともにカンプを再現できていました。

バリデーション定義書の条件は、一覧のとおりほぼそのまま実装されていました。入力チェックが実際に動いている様子が下の画像です。

指示に含めていなかった細部も見られました。メールアドレス欄には、ブラウザのメール入力補助が働く指定（type="email"）が入り、電話番号欄には、スマートフォンで数字キーパッドが表示される指定（inputmode="numeric"）が入っていました。

手直しが必要なところ

生成されたフォームを操作し、カンプと細部まで見比べると、いくつか穴が残っていました。重大度の高いものから挙げます。

使い勝手の穴

メールアドレスと確認用の欄に同じものを入れると「OK」が出ます。しかし、そのあと本欄だけ書き換えても、確認欄は「OK」の表示のまま。実際には一致していないのに、一致しているように見えてしまいます。確認欄の再チェックが、すでにエラーが出ているときにしか動かないためです。

プルダウンで選択肢を選ぶと、右端の下向き矢印が消えてしまいます。選択後にOK状態の背景色を付ける指定が、矢印の画像ごと上書きしているためです。

「年代」のような任意のプルダウンは、一度選ぶと最初の「選択してください」に戻せません。任意項目である以上、選び直して未選択に戻せるべきところです。

お名前を入れると、読みがフリガナ欄に自動で入ります。ただし、フリガナ欄で手を加えた内容は保持されないため、フリガナを直したあとにお名前欄を触ると、手直しが消えてしまいます。

画面上は各項目に見出しが付いています。ただしプログラム上は、その見出しと入力欄が結び付いていないところが多数ありました。そのため、目の不自由な人が読み上げソフト（スクリーンリーダー）で使うと、入力欄にたどり着いても「何を入力する欄なのか」が読み上げられません。見出しと入力欄は、プログラム上も紐付けておく必要があります（label と for）。

見た目の穴

プルダウンの初期表示「選択してください」は、カンプでは薄いグレーですが、出力では通常の濃い文字色になっています。グレーにするための指定は書かれているものの、条件が合っておらず効いていません。

PC表示で、項目名（見出し）の見え方がカンプと異なります。カンプでは行の上下中央に置かれますが、出力では上寄りになり、折り返す位置も変わっています。

ラジオボタンやチェックボックス、OK・エラーの状態を示すアイコンなど、各パーツの形が少しずつカンプと違います。一つひとつは小さな差ですが、積み重なると気になります。

スマホ表示では、細かなズレがまとまって出ています。一部の文字がカンプより大きく、その結果、意図しない位置で折り返しています。チェックボックスと項目名の間隔も広く、「入力内容を確認する」ボタンの寸法も異なります。また、ボタンの上にあるはずの区切り線がありません。

今回の検証から考えたこと

できたことと、残ったこと

条件を文章で書き切れるもの——バリデーションのような機能は、AIが正確に形にしました。一方で、カンプの細部や、操作して初めて分かる詰め（フリガナの手直しが消える、確認欄が一致していないのに「OK」になる、など）には穴が残りました。

書いたことはやる。欲しいのは、その先

書けば正確にやってくれるのは、素直にすごいと思います。ただ、現場の感覚で言えば、それは前提です。実務では、「全部を言わなくても、こう判断してこうやろう」「厳密には指示と違うが、こちらのほうが使う人が迷わない」——そういう判断がいくらでも求められます。逆に、こと細かく書かないとできないのなら、その指示を書く時間で自分で組んだほうが速い。

今のAIは、書いていないことでも気を利かせてやってくれるようになってきました。弱いのは、その先です。仕様書に現れない暗黙の前提や、プロジェクトごとの品質基準、それに「たぶんここでこういう事故が起きる」という経験則の先回り。さらに、それらの中で何を優先すべきかという判断は、人ほど安定していません。

もちろん、人間でも判断が分かれることはあります。それでも、経験を積んだエンジニアは、チームやプロジェクトの文脈まで含めて自然に判断しています。AIがそこまで担えるようになったら、本当の意味で「頼れる相棒」になると思います。

検証済みの「引き出し」と、「読めない時間」

エンジニアには、長年の経験で蓄えた「引き出し」があります。バリデーションや、各種UI（アコーディオン、カルーセル、モーダルなど）、レイアウト、アニメーションといった、何度も実装・検証してきた型があるからこそ、品質も工数もある程度見通せます。この「検証済み」という積み重ねは、大きな価値です。

一方、AIのコードは毎回初対面です。細部まで確認し、不具合があればコードを理解して修正しなければなりません。AIに修正を頼んでも解決するとは限らず、結局は自分で直すことも少なくない。問題は精度よりも、検証や修正にどれだけ時間がかかるか読めないこと——いわば「読めない時間」です。

AIの強みは生成速度です。ただ、現場で本当に重要なのは、生成にかかった時間ではなく、検証と修正まで含めた総時間のほうです。

一発で完璧は出ない前提で使う

今回は一枚まるごと作らせましたが、実務ではパーツやモジュール、機能単位で使うことのほうが多いです。特に既存案件では、既存サイトの他ページや、そのサイト特有のルール・クセに合わせる必要があります。こうした土台は人が手で用意し、必要な部分だけAIに任せるほうが、実務では扱いやすいです。

どんな使い方でも、「一発で完璧なものは出てこない。修正や詰めは当然発生する」と構えておくことが大切です。そのうえで、あとで直しやすいように、分かりやすいコメントや整理された構成で出力させるなど、先に手を打っておきます。

今回挙げた穴は、どれも派手な不具合ではありません。地味な詰めばかりです。しかし、その地味な詰めに気づき、仕上げられるかどうかが、AIを実務で使いこなせるかどうかの差になっていきます。

まとめ

今回の穴は、どれも、そこに目を向ける人がいて初めて立ち上がるものでした。

これはAIに限った話でもありません。更新性や運用、SEOに関わる構造、表示速度、アクセシビリティ——目に見えにくい品質は、意識してチェックしておかないと、公開してから気づくことになります。

AIは日進月歩なので、半年後には変わっている部分も出てくるかもしれません。私自身、最新の状況を追いながら、また試していくつもりです。

制作・技術相談を受け付けています

制作会社様・企業様からのフォーム制作やフロントエンド実装のご相談を受け付けています。

例えば、

• お問い合わせフォームの制作・改修を依頼したい
• フォームやJavaScriptの実装について相談したい
• HTML/CSS・フロントエンドの実装について相談したい
• Web制作に関する技術的な相談をしたい

小さなご相談でも構いません。お気軽にお問い合わせください。

みなと

フロントエンドエンジニア

XContact

Web制作会社に勤務して18年、ナショナルクライアントの案件が動く制作現場で、コーポレートサイト・LP・CMSサイトなど、Webサイトを実装してきました。このブログでは、AIツールの出力を現場の品質基準で検証しています。

詳しいプロフィールと、お仕事のご依頼はこちら →