AI任せのコーディングで気をつけるべきポイント10個

AI任せのコーディングで気をつけるべきポイント10個

環境構築

紙の線が輪になって集まり、思考の流れと蓄積を表現したサムネイル

AIに「このデザインをコーディングして」と頼むと、見た目もコードも一見それらしく仕上がります。頼んだ内容が短時間でコードになる速さは、Web制作の進め方が変わるほどです。

私のWeb制作でも、コーディングの一部をAIに任せています。ただ、確認せずにそのまま納品できるクオリティには達していません。

「動くコード」と「実案件に出せるコード」は別物だと、私は考えています。

この記事では、AIに実装を任せたときに起こりやすい10のパターンをご紹介します。
すべての案件やセッションで必ず起きるものではありませんが、比較的起きやすい出力の傾向です。

  1. デザインを確認できないと「それっぽく」勝手に補完する
  2. 長いページを一括生成すると後半ほど実装が雑になる
  3. marginとpaddingを使い分けず余白を場当たり的に調整する
  4. レスポンシブ対応を「縮小・非表示」だけで済ませる
  5. すべての要素にclassを付け似たCSSを大量に作る
  6. 値が同じというだけで役割の違う要素を同じclassにまとめる
  7. 見た目を揃えるためカードやセクションの高さを固定する
  8. 修正前のコードを消さず大量のコメントアウトを残す
  9. 修正が効かないと原因を調べずCSSを末尾に継ぎ足す
  10. 画面を確認せずコードを書き終えた時点で「完成」と判断する

1. デザインを確認できないと「それっぽく」勝手に補完する

デザインデータを確認できない状態で任せると、AIはフォント、余白、色、サイズを推測で実装することがあります。
しかも値がそれらしく見えるため、ぱっと見では補完されたことに気づけません。

スクリーンショットだけを渡して「この通りに実装して」と頼むと、この補完が起きやすくなります。画像から読み取れない値を、AIが自分で決めてしまうからです。

そのため、スクリーンショットだけでなく、Figmaのデザインデータも渡すようにしています。
確認できない値がある場合は、推測で確定させず、「未確認」としてAIから質問してもらう仕組みを作っています。

2. 長いページを一括生成すると後半ほど実装が雑になる

長いLPや複数セクションのページを一度に実装させると、後半の構造や細部が崩れやすくなります。
前半は指示どおりでも、後半へ進むほど実装が雑になりがちです。まったく別のデザインに仕上がることもあります。

私は1セクションずつ実装してもらい、表示を確認してから次のセクションへ進めています。
このほうが、崩れたときに問題箇所を追いやすくなります。

3. marginとpaddingを使い分けず余白を場当たり的に調整する

余白の調整を任せると、marginとpaddingが混在しがちです。
目の前の見た目を合わせることが優先され、そのとき都合のいいほうで余白を調整してきます。

<p class="text">テキスト</p>
.text {
  margin-top: 40px;
  padding-inline: 20px 24px;
  padding-bottom: 24px;
}

デザインに合わせた意図のある指定ならいいのですが、実値が分からないデザインを見た目だけで再現するために余白を指定している場合は問題です。

実装のたびに余白のとり方が変わるため、私の環境ではAIに守らせる基本のコーディングルールを用意しています。

プロジェクトごとにルールファイルを作り、実装前にAIに確認させています。

コーディングルールの一部

  • 要素間の余白はmargin、要素内の余白はpadding
  • セクション間や要素間の余白は原則margin-bottomで指定する
  • 背景色を含む余白が必要な場合はpaddingで作る

デザインによってはルールに合わない例外もあります。その場合は例外であることを伝えたうえで、デフォルトではルールに従わせています。

4. レスポンシブ対応を「縮小・非表示」だけで済ませる

レスポンシブ対応では、PCのレイアウトをscaleやzoomでそのまま縮小したり、収まらない要素を非表示にしたりすることがあります。
画面には収まるため、一見うまく対応できているように見えます。

たとえば、次のような実装です。

@media (max-width: 767px) {
  .main-visual {
    transform: scale(0.6);
  }

  .sub-image {
    display: none;
  }
}

スマホで必要なのは縮小ではなく再配置です。
並び順、幅、情報の見せ方を、必要に応じてスマホの画面に合わせて組み直します。

scaleやzoomで全体を縮めると、文字や操作領域まで小さくなります。
収まっているかではなく、スマホで読めて操作できるかを確認します。

5. すべての要素にclassを付け似たCSSを大量に作る

AIは要素ごとに新しいclassを作り、似た指定を繰り返すことがあります。

<p class="hero">普通のテキスト</p>
<p class="main-text">普通のテキスト</p>
.hero {
  font-size: 16px;
  margin-bottom: 30px;
}

.main-text {
  font-size: 16px;
}

1つ1つは正しく表示されますが、CSSが増えるほど、どこを直せばよいか分かりにくくなります。
同じ修正を複数箇所へ入れることにもなるため、メンテナンス性も悪くなります。

<div class="text">
  <p class="hero">普通のテキスト</p>
  <p>普通のテキスト</p>
</div>
.text {
  font-size: 16px;
}

.hero {
  margin-bottom: 30px;
}

font-sizeのように子要素へ継承されるプロパティなら、共通の親要素へ指定できます。上記では<div class="text">で囲み、2つの子要素へ一括で指定しています。

また、役割、見た目、レスポンシブ時の変化、変更単位の4つがそろう要素だけに、共通のclass名を指定しています。

コーディングをする人にとっては基本的な内容ですが、AIは間違えることがあります。そのためルールにして、確認時にも注意しています。

6. 値が同じというだけで役割の違う要素を同じclassにまとめる

5とは反対のパターンもあります。
たまたま文字サイズや色が同じという理由で、見出しと別用途の要素が同じclassへまとめられることがあります。

たとえば、見出しと日付が同じclassになっているケースです。

<h2 class="title">お知らせ</h2>
<p class="title">2026.07.19</p>
.title {
  font-size: 18px;
  font-weight: 600;
}

その時点では問題なく表示されます。
困るのは、あとから見出しだけを変えたくなったときです。同じclassを使っている日付まで一緒に変わります。

先ほど説明したとおり、classは値の再利用ではなく、役割、見た目、レスポンシブ時の変化、変更単位で決めています。
font-sizeが同じというだけで同じclassが使われていることがあるため、確認時に注意しています。

7. 見た目を揃えるためカードやセクションの高さを固定する

カードを並べたとき、見た目をそろえるために高さを固定してくることがあります。

.card {
  height: 320px;
}

そのときのテキスト量なら、きれいにそろって見えます。

崩れるのは、文言が増えたときや、スマホで改行が増えたときです。
テキストが切れる、要素が重なる、内部にスクロールが出るといった症状が起きます。

内容量が変わる要素は、内容に合わせて高さが伸びる構造にします。
デザインに合わせて例外的に高さを固定することもありますが、デフォルトでは禁止しています。

8. 修正前のコードを消さず大量のコメントアウトを残す

修正を頼むと、修正前のCSSやHTMLをコメントアウトで残してくることがあります。
たとえば、次のような状態のCSSです。

/* .section-title {
  font-size: 24px;
} */

/* .section-title {
  font-size: 26px;
  margin-bottom: 32px;
} */

.section-title {
  font-size: 28px;
  margin-bottom: 40px;
}

修正前のコードを残しておきたい場合もあります。ただ、デザインを再現できていない問題を直す修正で、古いコードが必要になることはほとんどありません。

どれが現在使われている指定なのか分からなくなり、次の修正でAIが判断を誤って古いコードを復活させる場合があります。

履歴はGitなどの変更履歴で管理し、現行ファイルには必要な説明だけを残します。
不要になったコードは、コメントアウトではなく削除してもらいます。

9. 修正が効かないと原因を調べずCSSを末尾に継ぎ足す

修正の指示が画面に反映されないとき、AIは既存の指定を確認せず、新しいCSSを末尾に追加し続けることがあります。
たとえば、このような継ぎ足しです。

.news .title {
  font-size: 14px;
}

/* 効かないため追加 */
.title {
  font-size: 16px;
}

/* それでも効かないため追加 */
.title {
  font-size: 16px !important;
}

最初の.news .titleのほうがCSSセレクタの詳細度が高いため、あとから.titleを追加しても適用されません。原因を調べないまま、最後は!importantで強制的に上書きしています。

書き足すたびに不要なCSSが増えるため、人がコードを編集するときに原因を見つけにくくなります。

画面が変わらない原因には、キャッシュ、読み込まれているファイル、CSSセレクタの詳細度、後勝ちの指定などがあります。

追加する前に、実際に適用されているCSSと、変更したファイルが読み込まれているかを確認します。

10. 画面を確認せずコードを書き終えた時点で「完成」と判断する

AIはブラウザでどう見えているかを確認せず、コードを書き終えた段階で「完成しました」と報告してくることがあります。

実DOM、適用されているCSS、表示されている画像、画面幅ごとの表示を確認しないと、変更が画面に反映されていないことにも気づけません。

AIには、コードを書き終えたときではなく、実装後のブラウザ確認まで終えてから完成と判断してもらうようにしています。

以前は、AIによるブラウザ確認でエラーが続き、トークン（AIの利用量）を無駄に使うことがありました。現在はアプリ内ブラウザを使える環境があるため、ブラウザ確認まで任せています。

AIの出力はレビュー前の作業結果として扱う

ここまでの10個に共通する対処は、AIの出力をそのまま受け取らないことです。
私は、AIの出力を完成品ではなく、レビュー前の作業結果として扱っています。

10項目すべてを毎回手作業で探すのではなく、プロジェクトのルールと確認手順にしておくと、AIへ渡す指示もレビューも安定します。

さらに、コーディング完了後はClaude Code、Codex、私の3者で確認し、見落としを減らしています。

私が伝えたいのは、AIにコーディングを任せてはいけないということではありません。

AIがつまずきやすい場所を先に知り、その場所だけは人が判断できるようにしておくことです。

AIの品質は、コードを書く速さだけでなく、どこを任せてどこを確認するかで変わります。
AIと一緒に実装するときのチェックポイントとして、この10個を使ってみてください。

Share

関連記事