この記事の対象: 制作会社のディレクター・エンジニア／AI活用を検討している発注担当者
読了時間: 約14分
ターミナルで動くAIエージェント「Claude Code」を、実際の制作案件で使い続けています。Shopifyテーマの改修、WordPressの子テーマ追加、記事生成の自動化——どこまで任せられて、どこから任せてはいけないのかが、しばらく回してようやく輪郭を持ってきました。この記事は機能紹介ではありません。指示の出し方、触らせない範囲の設定、戻ってきたコードのレビュー手順を、制作現場の実感として書きます。うまくいった話と同じ量だけ、失敗の話も入れます。
Claude CodeがWeb制作で効く場面と効かない場面
「コードを書く」より「読む」が主戦場
導入前の期待は「ゼロからコードを書かせる」でした。実際に一番効いているのは逆です。既存のコードを読ませて、どこを直せばいいかを特定させる作業が圧倒的に速い。
引き継ぎ案件のテーマを開くと、sections/ に section-*.liquid が数十本、assets/ に用途不明のJSが十数本ある、という状態にしばしば出くわします。ここから「商品ページの在庫表示を出しているのはどのファイルか」を人力で探すと、ファイルを開いては閉じる往復で相当な時間が溶けます。Claude Codeは全文検索と参照関係の追跡を同時にやるので、候補を短時間で挙げてきます。しかも「このファイルとこのファイルの両方に在庫表示のロジックがあり、片方は使われていない可能性がある」まで添えてくる。
これは制作会社にとって地味に大きい変化です。引き継ぎ案件の初期調査コストが、見積の前提から外れるからです。従来は「まず現状を読む」に一定の工数を積むしかなく、しかもその工数はクライアントから見て価値が見えにくい部分でした。ここが圧縮されると、同じ見積の中で実装と検証に回せる時間が増えます。
効かないのは「決めること」
一方で、これは運用を重ねるうちにほぼ結論が出ました。
任せている（作り方）
- 既存コードの調査・影響範囲の特定
- 決めた仕様どおりの実装
- 命名規約に沿ったリファクタ
- コードレビューの一次パス
- ドキュメント・コメントの整備
任せていない（決めること）
- デザインの方向
- 情報設計・ページ構成
- 見積・工数の判断
- 本番へ出す最後の一歩
- クライアントへの説明
線引きの基準はシンプルで、「何を作るか」は渡さない、「作り方」だけを渡す。この線を曖昧にすると、それらしい成果物が返ってくるぶん、間違いに気づくのが遅れます。
たとえば「トップページのファーストビューを改善して」と投げると、動くコードが返ってきます。でもその改善案が正しいかどうかは、そのクライアントの商材と客層を知らないと判断できない。AIは判断材料を持っていないので、一般的に良いとされる形——余白を広く、CTAを大きく、コピーを短く——に寄せます。それが正解の案件もありますが、そうでない案件も少なくありません。取扱商品が多くて回遊が価値になるサイトで、ファーストビューを削ぎ落とすと、単に情報が減るだけになります。
制作費の考え方については、Web制作の発注予算の決め方｜目的から逆算する手順【2026年】で別途整理しています。AIが工数を圧縮する部分と、圧縮できない部分は分けて考える必要があります。
指示の出し方｜3つ渡して、判断は渡さない
渡すのは「触ってよいパス」「作るもの」「誰に出すか」
運用で固まった型がこれです。指示に含めるのは3つだけ。
1. 触ってよいパス
触ってよい: sections/ts-product-stock.liquid, assets/ts-product-stock.js
触らない: それ以外のすべて。特に templates/*.json と config/settings_data.json
これを書かないと、AIは「ついでに直したほうがよさそうな箇所」を勝手に直します。善意なのですが、テーマエディタの設定JSONを書き換えられると本番の設定が飛ぶ。ここは実際に一度やられました。
2. 作るもの
仕様は箇条書きで、曖昧語を排除して書きます。「いい感じに」「適切に」「必要に応じて」を1つでも入れると、そこがAIの裁量になります。
- 在庫が0のとき「入荷待ち」バッジを商品名の下に出す
- バッジの文言は section settings から変更できるようにする
- 既存の .price ブロックのマークアップは変更しない
- CSSは assets/ts-product-stock.js から動的挿入せず、専用のCSSファイルに書く
最後の1行のような「やり方の禁止」を入れておくと、後で保守する人が探す場所が減ります。JSから動的にスタイルを挿す実装は、動いてはいるが検索で見つからないコードになりがちです。
3. 誰に出すか
「クライアントの担当者がテーマエディタから編集する」のか「開発者しか触らない」のかで、実装の粒度が変わります。前者ならsection settingsを厚めに、後者ならハードコードでいい。ここを伝えないと、必要のない設定項目が大量についてきます。設定項目は増えるほど、クライアント側で誤操作する余地も増えるので、多ければよいものではありません。
悪い指示と良い指示の実例
実際に投げた指示を比較します。
| 悪い指示 | 何が起きたか |
|---|---|
| 「商品ページの表示を整えて」 | CSSを広範囲に書き換えた差分が返ってきた。量が多すぎてレビュー不能 |
| 「Dawnのアップデートに耐えるように直して」 | 「耐える」の解釈がこちらと違い、Dawn本体を編集する形になった |
| 「バグを直して」 | 症状を伝えていないので、無関係な箇所の”改善”が複数混ざった |
| 良い指示 | 結果 |
|---|---|
「sections/ts-hero.liquid の34行目、モバイルで画像が縦に伸びる。object-fit の指定を確認して修正案を出して」 |
原因の特定が早く、差分は10行以内に収まった |
「ts- 接頭辞の命名規約に沿って、assets/custom.js の関数名を統一。ロジックは一切変えない」 |
機械的な置換として過不足なし |
差は「範囲」と「症状」の具体性です。症状を書かずに「直して」と言うと、AIは症状を推測するところから始める。その推測が外れると、直っていないコードが「直しました」という報告つきで返ってきます。
もうひとつ効くのが、再現手順を書くことです。「モバイルで」だけでなく「Chrome の DevTools で iPhone 表示、幅375pxのとき」まで書くと、AIが確認すべき条件が固定されます。条件が曖昧なままだと、AIは自分にとって都合のいい条件で「再現しませんでした」と返してきます。
Shopifyテーマの改修方針そのものについては、こちらで詳しく書いています。
触らせない設定｜事故を構造で防ぐ
指示文で「触るな」と書くだけでは足りません。書いても、たまに触られます。仕組み側で塞ぎます。
CLAUDE.md にプロジェクトの掟を置く
Claude Codeはプロジェクトルートの CLAUDE.md を読み込みます。ここに「このプロジェクトでやってはいけないこと」を書いておくと、指示のたびに書かなくて済みます。
実際に使っているShopify案件用の抜粋です。
# このテーマについて
## やらないこと
- `templates/*.json` を直接編集しない（テーマエディタの設定が飛ぶ）
- Dawn本体のファイル（`section-main-product.liquid` など）を編集しない
→ 上書きが必要なら `ts-` 接頭辞で新規ファイルを作り、そちらを参照する
- `shopify theme push` を実行しない（本番反映は人がやる）
- `config/settings_data.json` に触らない
## 命名規約
- 独自セクションは `ts-` 接頭辞
- CSSクラスは `.ts-<セクション名>__<要素>`
- JSのグローバル汚染禁止。`window.TS` 名前空間の下に置く
## 確認の取り方
- 差分が20行を超えたら、実装前に方針だけ先に出す
- 「どちらでもいい」判断が発生したら、片方を実装して理由を添える
最後の2行が効きます。「実装前に方針だけ先に出す」を入れておくと、大きな差分がいきなり降ってくる事故が減る。レビューできない量の変更は、あってもなくても同じです。
「どちらでもいい判断は片方を実装して理由を添える」のほうも、地味に工程を短くします。判断を投げ返されるたびに手が止まるより、仮で作らせて違ったら直すほうが速い。ただしこれが成立するのは、差分が小さくて戻せる場合に限ります。
権限は最小から始めて足す
Claude Codeはファイル書き込みやシェルコマンドの実行について、都度確認する設定と、事前に許可しておく設定の両方が持てます。制作案件では書き込み可能なディレクトリを絞るのが基本です。
三段目を崩さないのが一番大事です。確認を取らずに実行していいのは、実行した本人が結果を見て報告できるときだけ。デプロイをAIに投げると、壊れた瞬間を誰も見ていない状態になります。ロールバックできる仕組みがあっても、壊れたことに気づくのが翌朝では意味がない。
段を上げるタイミングも決めておくと迷いません。調査フェーズで出てきた「触るべきファイル」の一覧に納得できたら、そのパスだけを開けて二段目に上げる。一覧に納得できないうちは、まだ仕様が固まっていないということなので、実装に進まない。
git がない場所では使わない
これは運用してから気づいた前提条件です。Claude Codeの改修は、差分が見られる状態でないとレビューできません。FTPで直接サーバーのファイルを触るタイプの案件（引き継ぎで割とある）では、まずローカルにgitリポジトリを作って現状をコミットするところから始めます。
この一手間を飛ばすと、「何を変えたか分からないが動かなくなった」状態に一直線です。バックアップとしてフォルダを日付つきで複製する運用もありますが、あれは「戻せる」だけで「何が変わったか読める」ではありません。レビューの土台になるのは差分のほうです。
レビューの仕方｜報告を信じない
「できました」は検証していない可能性がある
AIエージェントは自信を持って間違えます。しかも報告の文章は、正しく動いた場合と区別がつきません。ここが実務で一番きつい部分です。
対策は3つ。
1. 差分を必ず自分の目で読む
git diff を通す。20行なら読む、200行なら「なぜ200行になったか」を聞き返す。読まずにマージすると、その時点で品質保証の連鎖が切れます。
2. 実物で確認する
ローカルで開く、プレビューURLで見る。「コードが正しい」と「画面が正しい」は別です。特にShopifyはキャッシュが効くので、?preview_theme_id= を付けないと古いHTMLを見て「直っていない」と誤診します。誤診したまま追加の修正を投げると、直っているものをさらに壊します。
3. 予期しない変更を探す
指示していないファイルに差分が出ていないか。CSSの1行だけ変えたつもりが、フォーマッタが走って全体がインデント変更になっているケースは頻出です。この手の差分は中身としては無害ですが、混ざると本当の変更が埋もれるので、コミットを分けさせます。
レビューを別のAIに一次パスさせる
自分でレビューする前に、別セッションのAIにレビューさせる構成を取っています。同じセッションで「レビューして」と言っても、自分の書いたコードに甘い判断が出ます。直前まで「これでいい」と考えていた文脈が残っているぶん、批判的に読めない。
観点を分けて並列で走らせると精度が上がります。
| 観点 | 見るもの |
|---|---|
| テクニカル | 動作の正しさ、パフォーマンス、ブラウザ対応 |
| コピー | 画面に出る文言、日本語として自然か |
| SEO | 見出し構造、構造化データ、内部リンク |
| UX | 操作の流れ、エラー時の挙動 |
| ビジネス | クライアントの目的に合っているか |
このうちAIが強いのはテクニカルとSEO。判断の基準が言語化しやすく、正誤がコードとマークアップに現れるからです。UXとビジネスは、案件の文脈を持っていないので参考程度。ビジネス観点だけは最後まで人が持つ——これは変わっていません。
計測まわりの検証については、アクセス解析ツール比較｜GA4と補助ツールの選び方【制作会社が解説】も参考になります。改修後に計測が壊れているケースは本当に多いので、テーマやテンプレートを触った案件では、公開後に計測タグの発火まで見ておくのが安全です。
実際に回している範囲｜自社メディアの記事生成
何を自動化して、何を残したか
Soreiine!!のマガジン記事も、一部の工程をAIエージェントで回しています。ただし全自動ではありません。
人が決める
- 何について書くか（選題）
- 誰に向けて書くか
- 使ってよい事実・数字の範囲
- 公開するかどうか
AIが担当
- 構成案の作成
- 本文の執筆
- 内部リンクの候補出し
- 校閲の一次パス
重要なのは「使ってよい事実・数字の範囲」を人が事前に確定させている点です。AIに数字を思い出させると創作します。制作費の相場、市場規模、シェア——それらしい数字が自信満々で出てきて、出典を聞くと出てこない。学習データの中にあった別の文脈の数字を、いま書いている文脈に合わせて出してくるので、桁だけそれらしく中身が違う、という壊れ方をします。
なので記事生成の指示には、使ってよい事実を構造化したデータで明示的に渡します。そこに無い数字は書かせない。「調べて書いて」ではなく「この範囲だけで書いて」にする。この制約を入れてから、事実誤認の混入が目に見えて減りました。
同じ考え方は、クライアント案件の原稿にも使えます。数字を含む文章をAIに書かせるなら、数字の出どころを先に人が確定させてから渡す。順番を逆にすると、書かれた数字の裏取りに執筆と同じだけの時間がかかります。
公開だけは人が押す
記事の公開、テーマの本番push、DBのマイグレーション適用。外に出る操作は全部人の手にしてあります。
理由は単純で、間違えたときに取り返しがつかないから。記事なら消せますが、消す前に読まれたら終わりです。クライアントのサイトなら、なおさら。
この設計にすると「AIを使っているのに手間が減っていないのでは」と思われがちですが、実感としては作業の大部分が圧縮されて、残りの判断が人に集中する形です。判断の密度は上がっている。作業が減って判断が増えるので、疲れ方の質が変わります。1日の終わりに残っているのは「手を動かした疲れ」ではなく「決め続けた疲れ」になる。
発注側から見たとき｜「AIで作ったから安い」は成り立つのか
圧縮されるのは作業、消えないのは判断
発注担当者の方から実際に聞かれます。「AIを使うなら安くなりますよね」と。
正直に答えると、下がる部分と下がらない部分があります。
| 工程 | AI導入の影響 |
|---|---|
| 既存サイトの調査 | 大幅に短縮。引き継ぎ案件で顕著 |
| 仕様どおりの実装 | 短縮する。ただし仕様が固まっている場合に限る |
| デザイン・情報設計 | 変わらない。むしろ相対的に比重が増す |
| ヒアリング・要件定義 | 変わらない |
| レビュー・品質保証 | 増える。AIが書いた分だけ検証が必要 |
| 公開・運用の判断 | 変わらない |
「実装が速くなったぶん、レビューが増える」——これが実感です。総工数が劇的に減るようなことは起きていません。
そして重要なのは、仕様が固まっていない案件ではAIの恩恵がほぼ出ないこと。「とりあえず作りながら考える」進め方だと、AIに渡す指示が毎回変わり、作り直しが発生します。仕様を固める工程は人間の仕事なので、そこがボトルネックになる。
逆に言えば、発注側が「AI活用で安くしたい」と考えるなら、効くのは値引き交渉ではなく要件を先に固めることです。決まっていない仕様を制作会社に決めさせる進め方は、AIを使っても使わなくても工数を押し上げます。要件定義に時間を使った案件のほうが、結果的に実装フェーズが短くなる。この関係はAIが入っても変わりませんでした。
見積の構造について知っておくと、この話はもう少し立体的に見えます。
「AIで作りました」を売りにしない理由
制作会社としては、AIを使っていること自体を打ち出していません。クライアントが買っているのは成果物と、それが正しく動く保証であって、作り方ではないからです。工具の銘柄を売りにする大工がいないのと同じ話です。
ただし聞かれたら答えます。隠すことでもない。発注側から確認しておくとよいのは次の3点です。
- 納品物の権利関係：AIが生成したコードの扱いをどう考えているか
- 検証の工程：AIが書いたものを誰がどうレビューしているか
- 障害時の対応：動かなくなったときに、中身を理解している人がいるか
3つ目が一番大事です。AIに書かせたコードを誰も理解していない状態で納品されると、保守で詰みます。改修のたびに「まずコードを読む」からやり直しになるので、結果的に高くつく。
見分け方はひとつあって、納品時にコードの構成を説明できるかを聞くことです。ファイルの役割分担、命名規約、どこを触ると何に影響するか。これが説明できる制作会社は、AIが書いたものを人が読んでいます。説明が「AIが最適な形で作っています」で止まるなら、読んでいない可能性が高い。
制作会社とフリーランスの違いを考えるときも、この観点は使えます。
つまずきやすい点｜実際に踏んだ地雷
実際にやられたものだけ挙げます。
1. 指示していないファイルが書き換わる
一番多い。CLAUDE.md に「触らないファイル」を明記し、差分を必ず確認する。それでも起きるので、gitで戻せる状態を維持しておく。
2. 「動きました」が動いていない
ローカルで確認しないまま報告が返る。実物確認を工程に組み込む。Shopifyならプレビューテーマ、WordPressならステージング環境。「確認したか」ではなく「どうやって確認したか」を聞くと、確認していないケースが表に出ます。
3. コードが冗長になる
放っておくと、既存の関数と同じことをする関数を新しく作ります。「既存に同じ処理がないか先に探して」を指示に入れる。既存資産の把握はAIが得意な領域なので、探させれば見つかります。探させないと作ります。
4. 記憶が引き継がれない
セッションが変わると前回の判断を忘れます。重要な決定はCLAUDE.mdか、プロジェクト内のドキュメントに書き残す。会話の中だけで決めたことは消えます。「前回こう決めたはず」が通じない前提で運用する。
5. ライブラリのバージョンを記憶で答える
学習データの時点で情報が止まっているので、最新の仕様を古い形で書きます。ライブラリの引数や既定値は、必ず公式ドキュメントを引かせてから実装させる。厄介なのは、古い書き方でも動いてしまうケースがあることです。動くので気づかず、非推奨のまま納品される。
6. 「全部直しました」が信用できない
複数箇所の修正を指示すると、一部だけ直っているのに「全て完了しました」と返ることがあります。指示した項目をチェックリスト形式で書き、1つずつ確認する。項目に番号を振っておくと、返答も番号で返させられるので照合が速い。
7. 差分が大きいまま出てくる
「実装前に方針を出す」を入れていても、指示の範囲が広いと大きな差分になります。この場合はAI側の問題ではなく、指示の切り方の問題です。1回の指示で触るファイルは数本まで、と決めておくと安定します。
よくある質問
Claude CodeはWeb制作の実務でどこまで使えますか？
既存コードの調査、仕様が固まった実装、リファクタ、コードレビューの一次パスは実務レベルで使えます。一方でデザインの方向決め、情報設計、見積判断、本番への公開は任せていません。「何を作るか」は人が決め、「作り方」だけを渡すのが安全な線引きです。
AIに任せたコードのレビューはどうすればいいですか？
差分を必ず自分の目で読み、実物の画面でも確認するのが最低ラインです。差分が大きすぎてレビュー不能な場合は、指示の範囲が広すぎるサインなので分割し直します。別セッションのAIにテクニカル・SEOの観点で一次レビューさせると精度が上がりますが、最終判断は人が持ちます。
AIを使うと制作費は安くなりますか？
調査と実装の工程は短縮されますが、レビューと品質保証の工数は増えます。デザイン・情報設計・ヒアリングは変わりません。総額が大きく下がるようなことは起きていないというのが実務での感触です。仕様が固まっていない案件ではAIの恩恵がほぼ出ない点にも注意が必要です。費用の目安は、サイトの規模・ページ数・機能要件・運用体制といった条件で決まるので、AI利用の有無を単独の値引き根拠にはできません。
制作会社にAI活用を確認するとき、何を聞けばいいですか？
「AIが書いたコードを誰がレビューしているか」「障害が起きたときに中身を理解している人がいるか」「納品物の権利関係をどう整理しているか」の3点です。特に2つ目が重要で、誰も理解していないコードを納品されると保守フェーズで改修コストが跳ね上がります。納品時にコードの構成を口頭で説明してもらえるかを確認すると、実態が見えます。
事故を防ぐために最初にやるべき設定は何ですか？
gitで現状をコミットして戻せる状態を作ること、プロジェクトルートの CLAUDE.md に「触ってはいけないファイル」を明記すること、本番への反映を人の手に限定すること。この3つを先に整えてから使い始めます。指示文だけで制御しようとすると必ず漏れます。
既存サイトの引き継ぎ案件でも使えますか？
引き継ぎ案件こそ効きます。前任者のコードを読んで構造を把握する工程が最も短縮されるためです。ただし前提として、まずローカルにgitリポジトリを作り、現状をコミットしてから始めてください。差分が見られない状態では、AIが何を変えたかを検証できません。FTPで直接サーバーを触る運用のまま使うのは避けます。
まとめ
Claude CodeをWeb制作で使うときの要点を整理します。
- 調査と実装は任せる、判断は任せない。「何を作るか」は人、「作り方」がAI
- 指示は3つに絞る。触ってよいパス／作るもの／誰に出すか
- 触らせない設定は仕組みで作る。CLAUDE.md と権限設定と git
- 報告を信じずに現物を見る。差分と実画面の両方
- 本番へ出す最後の一歩は人が押す。壊れた瞬間を見ている人が必要
運用してみて、一番変わったのは工数ではなく仕事の質です。手を動かす時間が減り、決める時間と検証する時間が増えました。AIが増やしているのは判断の量で、それは減らせません。
そして、この記事で書いていない領域——デザインの方向、クライアントとの合意形成、案件全体の設計——は、いまのところ人の側に残り続けています。そこが制作会社の価値になっていく感触があります。
