この記事の対象: 制作会社でコーディングを担当している人／AI活用を前提に見積を考えたい発注担当者
読了時間: 約12分
AIにコードを書かせる話は、もう「試してみた」の段階を通り越しています。問題は「使えるか」ではなく「どこまで任せて、どこから人が見るか」の線引きです。制作会社の現場では、静的サイト・WordPress・LP・ECで、AIが効く場所と足を引っ張る場所がはっきり分かれます。同じ「コーディング」でも、成果物の寿命と改修者の数が違うからです。この記事では、案件の種類ごとに任せられる範囲を切り分け、レビュー工数がどう増減するかまで具体的に書きます。
AIコーディングをWeb制作の現場で評価するときの前提
「書く時間」より「直す時間」で見る
AI導入の効果を測るとき、多くの人が「コードが出てくるまでの時間」を見ます。現場の実感で言うと、そこはほとんど問題になりません。ボトルネックは昔から一貫して、書いた後にあります。
- 既存コードとの命名・設計の食い違いを直す時間
- 実機・実ブラウザで崩れたところを詰める時間
- 別の人が半年後に触ったときに壊れない形に整える時間
AIコーディングは1つ目の工程を短縮し、2つ目を変えず、3つ目を悪化させることがある。この非対称が、現場で「速いのに楽にならない」と感じる正体です。
初稿の短縮だけを見て「工数が半分になる」と見積もると、後半の2工程で溶けます。効果を主張するなら、4工程の合計で比べる必要があります。
レビューの質が変わる、という現場の実感
もうひとつ、数字に出にくい変化があります。人が書いたコードのレビューは「なぜこう書いたか」を本人に聞けば済みます。AIが書いたコードのレビューは、書いた本人も理由を持っていない。「AIがこう出したので」で止まると、レビュアーが一からコードを読み直すことになります。
ここが現場で一番効いてくる差です。AIを使う担当者に求められるスキルが、「書ける」から「読んで説明できる」に移った。コードを書くのが速い人より、他人のコードを短時間で理解できる人のほうが、AI前提の体制では強くなっています。
静的サイト・LP：AIコーディングが最も効く領域
任せられる範囲が広い理由
静的HTML/CSSの案件は、AIコーディングの効果が一番はっきり出ます。条件を並べると理由が見えます。
| 条件 | 静的サイトの場合 |
|---|---|
| 依存関係 | ほぼない。HTML/CSS/JSで閉じている |
| 正解の判定 | ブラウザで見れば分かる。目視で完結する |
| 壊れたときの影響 | そのページだけ。他に波及しない |
| 改修する人数 | 制作時は少人数。納品後はほぼ触らない |
「見れば分かる」「壊れても局所的」の2つが揃っているので、AIに書かせて人が目で確認するサイクルが最短で回ります。
具体的に任せてよい作業
現場で実際に任せている粒度を挙げます。
- 既存デザインからのマークアップ起こし：Figmaの1セクションを渡して構造とCSSを出させる。命名規約だけ先に指示する
- レスポンシブの中間ブレークポイント調整：PCとSPが決まっていて、タブレット幅が崩れる場合の当て込み
- 同型セクションの量産：カード3枚のセクションを6枚に、実績一覧を10件に、といった機械的な複製
- フォームのバリデーション：必須・メール形式・電話番号の判定。仕様が明文化しやすい
- アニメーションの初稿：IntersectionObserverでのフェードイン、スクロール連動。動きの調整は人がやる
逆に、セクション同士の余白のリズムやタイポグラフィの階層は任せません。これは正解が明文化できず、サイト全体を通して見ないと判断できないからです。AIは1セクション単位では整った結果を出しますが、10セクション並べると余白がバラつきます。
実装のポイント：先に規約を渡す
AIコーディングで最も効くのは、プロンプトの工夫ではなく規約を先に渡すことです。指示せずに書かせると、AIは一般的に多い書き方を選びます。それが既存コードと違うと、全部直すことになります。
最低限、次の5つを最初に固定します。
1. クラス命名規則（BEMか、ユーティリティか、独自プレフィックスか）
2. CSSの単位（remかpxか、余白のスケール）
3. ブレークポイントの値と方向（min-width基準かmax-width基準か）
4. 使ってよいCSS機能の下限（Grid可、:has()可、@container不可 など）
5. JSの前提（バニラか、jQueryが既に入っているか）
これをプロジェクトのルートに置いたテキストファイルにまとめ、毎回冒頭で読ませる。この一手間で、後工程の直しが目に見えて減ります。
つまずきやすい点：ブラウザ対応の判定
AIは「そのCSSがいつから使えるか」を正確に持っていません。学習時点の情報で答えるので、新しすぎる機能を平気で提案することも、もう使える機能を古い書き方で回避することもあります。
現場では、AIが出したCSSに新しめの機能が含まれていたら、必ず自分でBaselineの状況を確認します。特に注意が要るのは次のあたりです。
| 機能 | 現場での扱い |
|---|---|
:has() |
主要ブラウザで使えるが、案件の対応要件次第。要件表を見てから判断 |
| コンテナクエリ | 使えるが、フォールバックが必要な案件かどうかを先に決める |
text-wrap: balance |
日本語では期待した結果にならないことがある。実物で見る |
subgrid |
対応は進んだが、AIが出す実装が冗長になりがち |
判定の手順を決めておくと迷いません。①AIの出力に見慣れない機能があるか目で拾う、②その機能名でBaselineの現況を引く、③案件の対応要件表と突き合わせる、④フォールバックを書くか、機能ごと使わないかを決める。AIの回答をそのまま「対応ブラウザ」の根拠にしないこと。ここは人が一次情報を見る工程として残します。
サイト制作の判断軸そのものを整理したい場合は、こちらもあわせてどうぞ。
WordPress：AIに任せる範囲が一段狭くなる
静的サイトとの決定的な違い
WordPress案件では、AIコーディングの効き方がはっきり落ちます。落ちる理由は「PHPが苦手だから」ではありません。AIが見えていない前提が多すぎるからです。
静的サイト
- 渡したファイルが全部
- 実行環境の差がほぼない
- 壊れる範囲がそのページだけ
WordPress
- テーマ・プラグインの実装が見えない
- フックの発火順で結果が変わる
- 1関数の追加で全ページが落ちる
右側の3つは、コードを読んだだけでは分かりません。AIに全ファイルを渡しても、有料テーマの中身やプラグインの内部処理までは把握しきれない。ここが任せる範囲を狭める理由です。
任せてよい作業と、任せない作業
| 作業 | 判定 | 理由 |
|---|---|---|
| ブロックパターンのHTML作成 | 任せる | 出力が静的HTMLに近く、目視で確認できる |
| ショートコードの実装 | 条件付き | 単機能なら任せる。DBを触るものは人が書く |
| カスタム投稿タイプ・タクソノミーの登録 | 任せる | 定型コード。引数の確認だけ人がやる |
functions.php への機能追加 |
条件付き | 影響範囲を人が先に決める。丸投げしない |
| WP_Query のチューニング | 任せない | 実データ量とインデックス状況を見ないと判断できない |
| プラグインとの競合調査 | 任せない | 実環境で切り分ける作業。コードだけでは分からない |
| セキュリティに関わる処理 | 任せない | nonce・権限チェック・エスケープの漏れは致命的 |
最後の1行が重要です。AIが出すWordPressコードは、エスケープとnonceの扱いが甘い場合がある。動くコードとしては正しいので、テストでは通ってしまいます。ここは人が必ず読む工程として残してください。
見るべき箇所は決まっています。画面に出す値に esc_html() / esc_attr() / esc_url() が付いているか、DBに入れる前に sanitize_text_field() などを通しているか、管理画面からの更新処理に wp_verify_nonce() と current_user_can() の両方があるか。この3点だけでも、目視の順番を固定しておくと漏れが減ります。
実装のポイント：子テーマ内で完結させる
AIに書かせるときは、触ってよいファイルを子テーマの中だけに限定する指示を必ず入れます。親テーマや wp-content の外に手を出させると、アップデートで消えるコードが生まれます。
<?php
/**
* 子テーマ functions.php への追記例
* AIに書かせたコードは、この形で「入口を1つ」にまとめる
*/
// 追加機能はすべて専用ファイルに分離し、子テーマ内で完結させる
$soreiine_modules = array(
'inc/custom-post-types.php', // カスタム投稿タイプの登録
'inc/shortcodes.php', // ショートコード
'inc/enqueue.php', // CSS/JSの読み込み
);
foreach ( $soreiine_modules as $module ) {
$path = get_stylesheet_directory() . '/' . $module;
if ( file_exists( $path ) ) {
require_once $path;
}
}
なぜこう書くかというと、AIが追記した箇所を後から特定できるようにするためです。functions.php に直接足していくと、数か月後に「どれがAIの出力で、どれが人が書いたか」が分からなくなります。ファイル単位で分けておけば、疑わしい範囲を丸ごと読み直せます。
file_exists() を挟んでいるのは、ファイルの取り込み漏れでサイト全体が白画面になるのを防ぐためです。require だと致命的エラーで止まりますが、この形なら該当機能だけが無効になります。
動作環境：WordPress 6.x 系、PHP 8.0以上で確認。get_stylesheet_directory() は子テーマのパスを返すので、親テーマを直接触らずに済みます。
ブロックパターン周りをちゃんと作りたい場合は、こちらの手順が使えます。
つまずきやすい点：フックの発火順
AIは add_action の第3引数（優先度）を、聞かれない限り既定値の 10 で出します。既存テーマやプラグインが同じフックに同じ優先度で刺さっていると、実行順が読み込み順に依存して、環境によって動いたり動かなかったりする状態が生まれます。
現場では、AIが出したフックのコードを見たら、必ず優先度を明示的に書き換えます。
// AIの初期出力（優先度が既定のまま）
add_action( 'wp_enqueue_scripts', 'soreiine_enqueue_assets' );
// 既存の読み込みより後に走らせたい場合、明示する
add_action( 'wp_enqueue_scripts', 'soreiine_enqueue_assets', 20 );
数字そのものより、「意図して指定した」という事実が後任者に伝わることに意味があります。この症状は再現条件が読み込み順に依存するため、ローカルで直ったように見えて本番で再発します。プラグインを本番と同じ構成にしたステージング環境で確認するのが確実です。
Shopify・EC：テーマの作法をどこまで守らせるか
独自テンプレート言語という壁
Shopify案件では、AIコーディングにさらに条件が付きます。Liquidという独自のテンプレート言語で、かつテーマ側の設計思想（Dawnならセクション・ブロックの構造）に従う必要があるからです。
AIが出すLiquidは、構文としては正しいが、テーマの作法から外れていることがよくあります。具体的には次のようなパターンです。
- セクションスキーマを持たず、テーマエディタから編集できない実装になる
- Dawn本体のクラス名を上書きして、アップデートで壊れる形になる
- 商品バリアントの扱いが単純化されていて、複数バリアントで破綻する
- 翻訳キーを使わず、日本語をLiquidに直書きする
いずれも「動きはする」ので、テストでは見つかりません。納品後、クライアントがテーマエディタを開いて「ここが編集できない」と言われて発覚します。
現場での切り分け
| 作業 | AIの使い方 |
|---|---|
| セクションのHTML/CSS部分 | 初稿を出させる。効率が良い |
| セクションスキーマ（JSON） | 項目リストを人が決め、書式化だけ任せる |
| 商品・在庫まわりのLiquid | 人が書く。データ構造の理解が要る |
| カートのJS処理 | 条件付き。Ajax APIの仕様を人が確認してから |
| チェックアウト関連 | 触らない。プラン制約と規約の判断が要る |
Dawnベースの改修方針そのものについては、別記事で整理しています。
実装のポイント：ts- プレフィックスで境界を作る
自作セクションには必ず独自のプレフィックスを付けます。AIに書かせるときも、この規約を先に渡します。
{% comment %}
sections/ts-feature-cards.liquid
独自セクションは ts- を付け、Dawn 本体のクラス名を上書きしない
{% endcomment %}
<div class="ts-feature-cards" style="--ts-gap: {{ section.settings.gap }}px;">
{% for block in section.blocks %}
<article class="ts-feature-cards__item" {{ block.shopify_attributes }}>
<h3 class="ts-feature-cards__title">{{ block.settings.title | escape }}</h3>
<div class="ts-feature-cards__body">{{ block.settings.body }}</div>
</article>
{% endfor %}
</div>
{% schema %}
{
"name": "特徴カード",
"blocks": [
{
"type": "card",
"name": "カード",
"settings": [
{ "type": "text", "id": "title", "label": "見出し" },
{ "type": "richtext", "id": "body", "label": "本文" }
]
}
],
"settings": [
{ "type": "range", "id": "gap", "label": "カード間の余白", "min": 8, "max": 48, "step": 4, "default": 24, "unit": "px" }
],
"presets": [{ "name": "特徴カード" }]
}
{% endschema %}
ポイントは3つあります。
{{ block.shopify_attributes }}を必ず入れる：これが無いと、テーマエディタで該当ブロックを選んでもプレビューがハイライトされません。AIは高い確率でこれを落としますpresetsを書く：これが無いとテーマエディタのセクション追加一覧に出てきません| escapeを付ける：text型の入力はエスケープする。richtextはHTMLを含むので付けない
3つとも、抜けていても表示は普通に出ます。だからレビューで見落とされやすい。チェック項目として明文化しておくのが現実的な対策です。
納品前の確認も、コードではなくテーマエディタ側から始めると早い。セクション追加一覧に自作セクションが出るか、各ブロックをクリックしてプレビューがハイライトされるか、設定値を変えて即座に反映されるか。この3つを触るだけで、上の3点の抜けはほぼ検出できます。
動作環境：Shopify Online Store 2.0 のセクション仕様に準拠。Dawn 系テーマで確認。
レビュー工数は結局どう動くか
増える領域・減る領域
AIコーディングを入れると、レビュー工数は一律には動きません。案件の性質で方向が変わります。
減る（目視で判定できる）
- LP・キャンペーンページ
- 静的サイトのマークアップ
- 同型セクションの量産
- 短命な販促ページ
増える（実物で確かめる工程が残る）
- WordPressの機能追加
- ECの購入導線まわり
- 複数人で長く保守するサイト
- 既存サイトへの追加改修
判定の分かれ目は「ブラウザで見て分かるか」の一点です。見て分かるものはAIで速くなる。見て分からないもの（権限、実行順、データ量が増えたときの挙動、後任者が読めるか）は、レビューが減らないどころか増えます。
見積にどう反映するか
発注側にとって重要なのはここです。「AIを使うから安くなる」は、案件の種類によって成り立ったり成り立たなかったりします。
- 短命な販促LP：AIの効果が出やすい。制作期間の短縮も現実的
- 企業サイトの新規制作：初稿は速くなるが、設計と確認の工程は残る。全体では大幅には縮まない
- 既存サイトの改修：ほぼ変わらない。既存コードを読む工程がボトルネックのため
- EC・会員機能を持つサイト：変わらないか、確認工程が増える
「AI活用で安くします」という提案を受けたときは、どの工程が何時間減るのかを聞いてください。工程を分けて答えられない相手は、初稿の短縮だけを見ている可能性があります。
聞き方は具体的なほうがいい。「デザインは今まで通り人が起こすのか」「コーディングの何割をAIに出させて、レビューに誰が何時間かけるのか」「実機確認の工程は減るのか」。この3つに数字で答えられるなら、工程を分解して見積もっている相手です。逆に「AIで全体3割減」としか返ってこない場合、削られているのは初稿の時間だけで、後工程の手戻りは見積に入っていない可能性があります。
制作費の構造そのものは、こちらで分解しています。
品質チェックの置き場所を変える
AIを入れると、バグの出方が変わります。人が書いたコードのバグは「書き忘れ」が多い。AIが書いたコードのバグは「それらしく書かれた間違い」が多い。後者は目が滑ります。
対策として現場でやっているのは、レビューの順番を変えることです。
コードを最初から読むと、それらしい見た目に引っ張られます。チェックリストと実物確認を先に通してから読むと、見落としが減ります。
チェックリストは案件ごとに作り直さず、技術ごとに1枚持って使い回すのが現実的です。静的サイトなら「alt属性・見出し階層・フォームのラベル紐づけ・404時の挙動」、WordPressなら「エスケープ・nonce・権限チェック・フック優先度」、Shopifyなら「shopify_attributes・presets・翻訳キー・バリアント複数時の表示」。どれも機械的に見られる項目なので、コードを理解していない人でも通せます。ここを分業できることが、AI前提の体制では効いてきます。
発注する側が確認しておくとよいこと
制作会社にAI活用の可否を確認するとき、「AIを使っていますか」という質問はあまり意味がありません。使っているかどうかより、成果物の責任がどこにあるかが重要です。
聞くべきなのは次の3つです。
| 確認事項 | なぜ聞くか |
|---|---|
| 納品コードの説明ができるか | AIが書いた部分も含め、なぜそう書いたか答えられるか |
| 保守を誰がやるか | 書いた人が離れたとき、次の人が読める形になっているか |
| 修正対応の範囲 | AI起因の不具合も通常の瑕疵と同じ扱いか |
3つ目は契約時に明記しておくと安全です。「AIが出したコードなので」が免責の理由にならないことを、双方で確認しておく。
あわせて、渡した資料や既存コードをAIサービスにどう入力するかも確認しておくと安全です。未公開の商品情報や個人情報を含むデータを扱う案件では、入力してよい範囲を先に決めておく必要があります。ここを詰めていない制作会社は、AI活用の体制がまだ整っていないと見ていい。
サイトの保守という観点は、こちらで整理しています。
よくある質問
AIコーディングを使うと制作費は安くなりますか
案件の種類によります。短命な販促LPや静的ページの量産は、初稿作成が短縮されるぶん反映されやすい領域です。一方、既存サイトの改修やEC・会員機能を持つサイトでは、既存コードを読む工程と実物での確認工程が残るため、大きくは変わりません。見積の話をするときは「全体で何%」ではなく「どの工程が何時間減るのか」で確認してください。
AIが書いたコードの品質はどう担保しますか
チェックリストによる機械的な確認と、実物での挙動確認を先に通し、コードを頭から読むのは最後に回します。AIのコードは「それらしく書かれた間違い」が混ざるため、先にコードを読むと見た目の整合性に引っ張られて見落とします。特にWordPressのエスケープ・nonce、Shopifyのセクションスキーマなど、抜けていても表示は正常に出る箇所は明文化したチェック項目として持っておくのが現実的です。
制作を依頼するとき、AIを使っているか確認すべきですか
使用の有無より、納品されたコードについて「なぜそう書いたか」を説明できるかを確認するほうが実用的です。あわせて、保守を誰がやるか、AI起因の不具合も通常の瑕疵担保と同じ扱いになるかを契約時にすり合わせておくと、後で揉めにくくなります。渡す資料をAIサービスに入力してよいかの線引きも、着手前に決めておくと安全です。
制作者はAIコーディングで仕事がなくなりますか
現場での実感としては、求められるスキルの重心が移っています。ゼロからコードを書く速さより、他人の書いたコードを短時間で読んで正しさを判断できる力のほうが価値が上がりました。設計を決める、要件と実装の食い違いを見つける、実環境で切り分けるといった工程は、コードだけを見ても判断できないため残ります。
WordPressとShopifyでは、どちらのほうがAIに任せやすいですか
表示部分に限れば、どちらも似た程度に任せられます。差が出るのは機能実装です。WordPressはプラグインとの競合やフックの発火順といった「コードを読んだだけでは分からない前提」が多く、Shopifyはテーマエディタ対応やバリアントの扱いなど独自の作法があります。どちらも、購入導線・権限・データ操作に関わる部分は人が書く判断で運用するのが安全です。
まとめ
AIコーディングは「使えるか」という問いにはもう答えが出ていて、実際の論点は境界線の引き方です。判定の軸は1つに絞れます。ブラウザで見て分かるものは任せる、見て分からないものは人が持つ。
- 静的サイト・LPは効果が出やすい。規約を先に渡すことで直しが減る
- WordPressは範囲が狭まる。エスケープ・nonce・フックの優先度は人が見る
- Shopifyはテーマの作法が壁になる。
shopify_attributesとpresetsの抜けが典型 - レビュー工数は一律には減らない。案件の性質で増減が分かれる
- 見積の議論は「全体で何%」ではなく「どの工程が何時間」で行う
現場で効いているのは、プロンプトの巧さではなく、任せる前に規約を渡すことと、任せた後にチェックリストで機械的に落とすことの2つです。どちらも地味な作業ですが、ここを整えているかどうかで、AI導入が効率化になるか手戻りの増加になるかが分かれます。
