AI駆動開発
投稿日:

コーディング代行会社がAIと共存するために ─ 品質で差別化する時代の制作体制

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

「AIでコーディングが自動化されたら、制作会社って要らなくなるんじゃないですか?」

この質問を、クライアントからも、採用面接に来た候補者からも、業界の知人からも聞かれるようになりました。正直に言えば、私も最初はそう思った時期があります。

AIがHTML/CSSを書ける。デザインカンプからの変換もできる。JavaScriptのUI部品も作れる。じゃあ、うちのような会社の存在意義は何なのか。

この問いに対する私たちの答えは、約2年間のAI導入実践を通じて明確になりました。今回は、コーディング代行会社がAI時代にどう生き残るか、うちが実際に変えてきたことをお話しします。

AIが代替できること、できないこと

まず前提を整理します。この連載でこれまで書いてきた検証結果をもとに、AIが代替できる領域とできない領域を改めてまとめます。

AIが代替できる領域

初期コーディング。デザインカンプからHTML/CSSの骨格を作る作業は、AIで約50%の工数削減が実現できています。セクション単位で指示すれば、レイアウトの再現度は高い。

定型的なJavaScript。アコーディオン、モーダル、タブ切替など、パターンが決まっているUI部品はAIが正確に書きます。

Zodスキーマやバリデーションの定型部分。型定義や基本的なバリデーションルールは、AIの出力がほぼそのまま使えます。

kintoneのREST API呼び出し。リファレンスに沿ったコードは正確に出力されます。

AIが代替できない領域

タブレット幅のレスポンシブ判断。PC/SPの2カンプしかない場合、中間幅の処理はAIにはできません。コーダーの経験則に依存する暗黙知です。

品質検証。クロスブラウザ検証、実機テスト、アクセシビリティチェック。これらはAIが「生成」する領域ではなく「検証」する領域であり、現時点で自動化が難しい。

既存コードとの整合性。BEMの命名規則に揃える、既存のCSS設計方針に合わせる、子テーマの最小限の変更を判断する。既存コードの文脈を理解した上での判断が必要です。

UI/UXの設計判断。kintoneのバリデーションタイミング、一覧画面での情報の優先順位、ユーザーの業務フローに沿った操作設計。コードが動くことと使いやすいことは別の問題です。

クライアントとのコミュニケーション。「なぜこの実装方法なのか」「この変更の影響範囲はどこまでか」をクライアントに説明する。見積もりの根拠を工程別に示す。これはAIにはできません。

「AIで作ったものを仕上げるプロ」へのシフト

うちが約2年間で変わったのは、「ゼロからコードを書く会社」から「AIが書いたコードを検証・仕上げる会社」へのシフトです。

変刖1:工程の比重が変わった

以前のうちの工数配分と、現在の配分を比較します。以下はコーポレートサイト新規制作(10〜20ページ規模)での傾向値です。

工程AI導入前現在
実装(HTML/CSS/JS)55%25%
AI指示・仕様設計0%15%
レビュー・品質検証20%30%
修正・調整15%20%
ディレクション10%10%

実装の比重が55%から25%に下がり、レビュー・品質検証が20%から30%に増えました。「作る」から「検証する」に比重が移っています。

変刖2:採用基準が変わった

以前は「速く正確にコーディングできる人」を求めていました。今は「AIの出力を見て問題点を指摘できる人」を重視しています。

具体的には、面接で「このHTML/CSSを見て、問題点を指摘してください」というコードレビューの実技を行っています。見出し階層の誤り、不要なdiv、!importantの乱用、alt属性の不備、レスポンシブの中間幅の未対応。こうした問題を見抜ける目があるかどうか。

コーディングの速度はAIが補えます。しかし、品質を見極める目はAIでは補えない。ここが、これからのコーダーに求められるスキルだと考えています。

変刖3:チェックリストが成長し続けている

AIの出力に繰り返し見つかる問題パターンを、チェックリストに反映し続けています。1年前は30項目だったチェックリストが、現在は50項目を超えています。

このチェックリストこそが、うちの最大の資産だと考えています。AIが進化してもチェックリストの重要性は変わらない。むしろ、AIの出力パターンが変わるたびにチェックリストも進化していく。

品質で差別化するとはどういうことか

「品質で差別化する」と言葉にするのは簡単ですが、具体的に何をしているかを3つ挙げます。

差別刖1:納品前の検証工程を厚くしている

うちでは納品前に以下の検証を行っています。

  • HTMLのW3Cバリデーション
  • Lighthouseスコアの確認(Performance、Accessibility、Best Practices、SEOの4指標)
  • クロスブラウザ検証(Chrome、Safari、Firefox、Edge + iOS Safari、Android Chrome)
  • レスポンシブ4幅の実機確認(PC、タブレット横、タブレット縦、SP)
  • アクセシビリティチェック(見出し階層、alt属性、フォーカス管理、色コントラスト)

これらを全案件で標準実施しています。「安い会社」との差はここに出ます。安い見積もりの会社は、これらの工程を省略しているから安い。うちはこの工程を含めた上で見積もりを出し、その分の品質を保証します。

差別刖2:問題が起きたときの対応力

納品後に問題が見つかったとき、原因と対策をセットで報告する。影響範囲を調べて、類似の問題が他のページにないか確認する。再発防止策をチェックリストに反映する。

この「問題対応の型」があるかどうかで、クライアントの信頼感はまったく違います。AIが普及しても、この対応力は自動化されません。

差別刖3:クライアントへの説明力

「なぜこの実装方法なのか」「なぜこの工数がかかるのか」「AIで安くなる部分とならない部分はどこか」。これらをクライアントに分かりやすく説明できることは、制作会社としての付加価値です。

AIが書いたコードを「はい、できました」と渡すだけなら、クライアント自身がAIを使えば済む話です。プロとして付加価値を出すのは、「なぜそうしたか」を説明できること、そして「クライアントが見落としている課題」を先回りして指摘できることです。

「AIに仕事を奪われる」のではなく「仕事の中身が変わる」

最後に、この連載を通じて私が感じていることをまとめます。

AIの登場で、コーディング代行会社の仕事は「なくなる」のではなく「中身が変わる」のだと思っています。

以前は「デザインカンプ通りにHTMLを書くこと」に価値がありました。今は「AIが書いたHTMLの品質を保証すること」に価値が移っています。書くスキルから、見極めるスキルへ。実装力から、品質管理力へ。

この変化は、制作会社にとって脅威であると同時にチャンスでもあります。品質管理の仕組みを持っている会社は、AI時代にむしろ強くなる。「AIが作ったものを、プロが仕上げて納品する」というモデルは、クライアントにとっても「速くて品質が高い」という最良の選択肢になり得るからです。

うちもまだ試行錯誤の途中です。ただ、「AIと戦う」のではなく「AIを前提にした品質管理体制を作る」という方向性は間違っていなかったと、2年間の実践を通じて確信しています。

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