コーディング代行にAIを導入して変わったこと ─ 工数・品質・納品フローの現実

株式会社ファストコーディングでフロントエンド開発と技術戦略を担当している黒田です。

「AIを使えばコーディング費用は半分になりますか？」

ここ半年ほど、クライアントからこの質問を受ける頻度が明らかに増えました。ChatGPTやClaude、Cursorの普及で、「AIがコードを書く」という認識が一般的になったからだと思います。

結論から言うと、半分にはなっていません。ただ、何も変わっていないかというと、そうでもない。うちではコーディング代行業務にAIを本格的に組み込んで約1年が経ちますが、変わったのは「コストの総額」ではなく「コストの内訳」でした。

今回は、フロントエンドのコーディング代行を専門とする制作会社の技術責任者として、AIを導入して実際に何が変わり、何が変わらなかったのかをお話しします。

コーディング代行の工程をおさらいする

まず前提として、うちのコーディング代行業務がどういう工程で動いているか整理しておきます。

AIが影響を与えるのは主に「HTML/CSSコーディング」と「JavaScript実装」の部分で、ここが全体の60%を占めていました。

AIを導入して変わった工数の内訳

約1年間の実績をもとに、AI導入前後の工数比率の変化をまとめました。

HTML/CSSコーディング工程は半分以下に減りました。一方で、レビュー・品質検証と修正・調整の工数が合計で25%増えています。

トータルの工数削減率は、絶対値ベースで約20%です。上の表は「削減後の総工数に対する比率」なので、全体のパイ自体は小さくなっています。とはいえ「AIで半額」にはほど遠い数字で、現実的にはこのあたりが妥当かなと思っています。

社内でこの数字を共有したとき、若手のエンジニアから「もっと減らせるんじゃないですか」という声がありました。正直、私もそう思っていた時期はあります。ただ、品質検証を省略した結果クライアントからの差し戻しが増えたことがあり、今はこの20%削減が「品質を落とさずに達成できるライン」だと考えています。

AIが得意なこと、苦手なこと

1年間チームで回してきた実感として、コーディング代行業務でのAIの得意・不得意を整理します。

AIが得意な作業

ベースとなるHTMLマークアップの生成。セクションごとの基本構造をFigmaのレイヤー名やテキスト情報をもとに出力させると、8割程度の精度で骨格ができます。ヘッダー、フッター、カード型のコンテンツブロック、テーブルなど、パターンが決まっている要素は特に精度が高い。

繰り返しパターンのCSS。余白、色、フォントサイズなど、デザイントークンに沿った基本スタイルの生成は速い。同じレイアウトパターンが複数ページにまたがる場合、1ページ分を手動で作り込んでからAIに展開させるフローがうちでは定着しています。

JavaScriptの基本的なUI部品。アコーディオン、モーダル、タブ切替のような定番のインタラクションは、AIが標準的な実装を出してくれます。アクセシビリティ対応（適切なHTML要素の選択、aria属性、キーボード操作）も、プロンプトで指定すれば考慮されたコードが返ってきます。

AIが苦手な作業

デザインカンプの「行間」を読むこと。これはチーム内でも一番話題になった点です。Figmaのカンプに明示されていない判断が必要な部分、たとえば「テキストが3行になったときの処理」「画像のアスペクト比が異なるデータが入ったときの対応」「768px〜1024pxの中間幅でのレイアウト」は、AIに指示しないと対応されません。うちのコーダーであれば経験則で対処するこれらの判断を、AIは自力ではできない。

既存のCSS設計との整合性。途中から参加する改修案件で、既存のCSSにBEMの命名規則が使われている場合、AIに「BEMに従って」と伝えても、Block-Element-Modifierの粒度が既存コードと揃わないことが多い。.card__titleと書くべきところを.card-titleにしたり、Modifierの付け方が独自解釈になったりします。

ピクセル単位の調整。デザインカンプとの誤差が2〜3px程度あることは日常的に発生します。余白の数値、line-height、letter-spacingなど、Figmaの値をそのままCSSに反映しても、ブラウザのレンダリング結果とは微妙にズレる。ここは最終的に人間の目が必要です。

実際に起きた失敗事例

AI導入初期に発生した問題をいくつか紹介します。これからAIを導入しようとしている制作会社の参考になれば幸いです。

失敗1：!importantの連鎖

あるLP案件でAIにCSSを生成させたところ、既存のリセットCSSとの競合を解消するために!importantを使い始め、その後の修正でも!importantが増え続けました。最終的に27箇所の!importantが発生し、結局CSSの大部分を書き直すことになりました。

原因は、既存のCSSファイルの内容をAIに読ませずに、新規パーツだけ生成させたことです。コンテキストが不足していると、AIは目の前の問題を場当たり的に解決しようとします。これは社内で「AIにはケチらずコンテキストを渡せ」という教訓として共有されました。

失敗2：レスポンシブの中間幅が崩れる

PCカンプとSPカンプの2枚だけ渡してコーディングを依頼した案件で、タブレット幅（768px〜1024px）の表示が大きく崩れていました。AIはPC版のレイアウトをそのまま縮小しただけで、カード型のグリッドが3列→2列に切り替わるべきところが、3列のまま窮屈に詰まっていた。

うちのコーダーであれば「この幅では2列にすべき」と判断しますが、AIはカンプにない判断はしません。当たり前といえば当たり前なのですが、初期はこの「当たり前」に気づくのに時間がかかりました。

失敗3：納品後にアクセシビリティ指摘

AIが生成したHTMLで<div>のクリックイベントを使ったボタンがあり、キーボード操作でフォーカスが当たらない問題がクライアントのアクセシビリティチェックで検出されました。<button>要素を使うべき箇所です。

AIに「アクセシビリティに配慮して」と伝えれば<button>を使ってくれますが、プロンプトに含めないとセマンティクスが甘くなるケースがあります。この件以降、うちではAIへの指示テンプレートにアクセシビリティ要件を必ず含めるようにしました。

現在の運用フロー

これらの失敗を経て、現在はチームとして以下のフローでAIを活用しています。

ポイントは「セクション単位で生成させる」ことです。ページ全体を一度に生成させると出力のコントロールが難しくなります。ヘッダー、メインビジュアル、コンテンツセクション、フッターのように分割して依頼し、人間が統合する。このフローに落ち着くまでに3ヶ月ほどかかりましたが、今はチーム全員がこのやり方で回しています。

「AIで安くなりますか？」への回答

冒頭の質問に戻ります。

正直にお伝えしているのは、「実装の速度は上がりましたが、品質を維持するためのコストは変わりません」ということです。

AIの導入で変わったのは「誰がコードを書くか」ではなく、「コードの品質をどう担保するか」の比重です。以前は「経験豊富なコーダーが最初から正しく書く」ことで品質を担保していました。現在は「AIが高速に出力し、人間が検証・修正で仕上げる」フローになっています。

結果として、単純な実装だけの案件では確かにコストが下がっています。しかし、品質基準が高い案件、既存サイトの改修案件、複雑なレスポンシブ対応が必要な案件では、トータルコストはそれほど変わらないのが実情です。

まとめ

コーディング代行にAIを導入して1年の結果を率直にまとめます。

下がったもの：

• HTML/CSSの初期コーディング工数（約50%減）
• 定型パターンのJavaScript実装工数

増えたもの：

• AI向けの仕様書・指示書作成工数
• コードレビュー・品質検証工数
• AI出力起因の修正工数

変わらなかったもの：

• クロスブラウザ検証の必要性
• レスポンシブの中間幅に対する人間の判断
• ピクセルレベルのデザイン調整
• 納品品質の基準そのもの

AIを導入すれば制作会社が不要になる、という段階にはまだ来ていません。むしろ、AIが出力するコードが一定水準に達しているからこそ、「その先の品質」を担保できる制作会社の存在意義は増しているのではないかと思っています。

うちのチームでもまだ日々試行錯誤を続けています。開発チームを見ている立場として思うのは、AIの使い方よりも「AIを前提にした工程設計」の方がはるかに大事だということです。ツールは変わっていきますが、品質管理の考え方は残ります。現場で得られた知見は今後も共有していくつもりです。

コーディング代行の品質やAI活用の進め方について相談したいという方は、株式会社ファストコーディングのお問い合わせフォームからお気軽にご連絡ください。