この記事の対象: 制作会社のディレクター・デザイナー・エンジニア、およびAI活用を検討している発注担当者
読了時間: 約12分
AIツールの記事はもう飽きるほど出ています。「おすすめ10選」を読んで一通り試して、結局どれも中途半端に使って終わった、という人は多いはずです。問題はツールを知らないことではなく、どの場面でどれに切り替えるかの判断基準を持っていないことにあります。この記事では機能紹介を一切せず、制作会社の実務で「ここはAIに投げる」「ここは絶対に人がやる」の線引きをどう引いているかだけを書きます。判断軸が手元にあれば、来年ツールの名前が全部変わっても使い回せます。
AIツール比較の前に決めるべき「投げる基準」
ツールの性能差より、投げ方の差のほうが大きい
制作の現場でAIを日常的に使ってみて、はっきりしたことがあります。成果物の質を分けているのは、どのモデルを使ったかよりも、どういう仕事を投げたかのほうです。
同じモデルでも、「このLPのコピーを書いて」と投げたときと、「このLPは既存顧客の再購入が目的で、離脱は価格提示の直後に集中している。価格の見せ方を3案、それぞれ根拠付きで」と投げたときでは、返ってくるものが別物になります。前者は誰でも書ける当たり障りのない文章、後者は叩き台として使えるものが出てきます。
つまり比較すべきは「ツールA vs ツールB」ではなく、「この仕事はAIに投げられる形になっているか」という問いです。ここを飛ばしてツール比較の記事を読むと、いつまでも「試したけど微妙だった」を繰り返すことになります。
投げてよい仕事の3条件
実務で回してみて、この3つが揃ったときはほぼ確実にAIのほうが速い、という条件が見えてきました。
投げる（3つ揃う）
- 大量に読む・書く必要がある
- 正解が1つでなく、案が複数あってよい
- 間違っても手戻りが安い
自分でやる（1つでも欠ける）
- 読む量が少なく、判断が重い
- 正解が1つしかない
- 外に出たら取り返しがつかない
この3条件のうち、実務で一番効くのは3つ目の「手戻りが安いか」です。デザインカンプの方向性を3案出させるのは手戻りが安い。クライアントに送るメールの本文をそのまま送るのは手戻りが高い。この差だけ意識しておけば、事故はほぼ防げます。
「手戻りが安い」の定義も決めておくと迷いません。間違いに気づく人が自分だけで、やり直しても失うのが自分の時間だけなら安い。気づくのがクライアントや、その先のエンドユーザーなら高い。同じ「原稿を書く」でも、社内共有用のメモは安く、公開ページの本文は高い、という分かれ方をします。
「AIに投げると速くなる」が嘘になる場面
現場でよく起きる失敗が、検証時間を計算に入れていないパターンです。
コードを数分で生成させても、動作確認とデバッグに何十分もかかれば、自分で書いたほうが速い。これはとくに、既存プロジェクトの改修で顕著に出ます。プロジェクト固有の命名規則やディレクトリ構成をAIは知らないので、生成物が既存コードと噛み合わず、結局全部書き直すことになる。
判断としてはシンプルで、「生成物を検証する時間 < 自分で作る時間」が成り立つときだけ投げる。この不等式が成り立たない領域は、AIを使わないほうが速いです。新規のゼロイチは成り立ちやすく、複雑な既存改修は成り立ちにくい。
厄介なのは、この不等式が事前には見えにくいことです。生成そのものは常に速いので、投げた直後は「うまくいった」ように見える。差が出るのは検証を始めてからで、そこで初めて「これは自分で書いたほうが速かった」と分かる。対策は、投げる前に検証手順を先に決めておくことです。どうやって正しさを確かめるかが即答できない仕事は、投げても検証で詰まります。コードならテストの通し方、原稿なら事実確認の当て先。これが決まっていない状態で投げるのは、速くなっているのではなく、判断を後ろに先送りしているだけです。
場面別の使い分け｜Webディレクターの1案件を通して
実際の案件を頭から終わりまで追いながら、どの工程で何に切り替えているかを書きます。ツール名ではなく「AIの種類」で整理したほうが、来年も使えます。
提案・企画フェーズ
投げるもの
| やること | 投げるか | 理由 |
|---|---|---|
| 競合サイトの構成調査 | 投げる | 大量に読む。並列に走らせられる |
| 業界の一般的な訴求パターンの洗い出し | 投げる | 案が複数あってよい |
| 企画書の骨子・章立ての抜け漏れチェック | 投げる | 網羅性の検査は機械が強い |
| 提案の方向性そのもの | 投げない | 案件ごとに唯一解がある |
| 見積金額 | 投げない | 根拠のない数字が出てくる |
競合調査は最もAI適性が高い工程です。複数社のサイトを人が見て構成をメモする作業は時間がかかりますが、URLを渡して「ナビゲーション構成・ファーストビューの訴求・CTAの位置を表にして」と投げれば、比較できる形で戻ってきます。ただし返ってきた表を鵜呑みにせず、必ず数社は自分の目で開く。AIは「見えなかったもの」を空欄ではなく推測で埋めることがあります。
裏取りの当て方にもコツがあります。全社を見直すのではなく、表の中で「他社と違う」と書かれている行だけを開く。提案の根拠になるのは差分の部分なので、そこが事実なら表全体が使えます。逆に、差分の記述が実物と食い違っていたら、その表は作り直したほうが速い。
見積を投げないのは絶対のルールにしています。AIは「Webサイト制作の相場は〜」という形で、出典のない数字を自信たっぷりに出してきます。これを提案書に載せると、根拠を聞かれた瞬間に崩れる。金額の話は自社の実績と工数から積み上げるしかありません。
設計・ワイヤーフェーズ
ここは投げる領域と投げない領域がくっきり分かれる工程です。
情報設計（どのページに何を置くか、どう回遊させるか）は投げません。クライアントの事業構造とターゲットの動線を踏まえた判断で、正解が1つに近いためです。一方で、設計した構成の抜け漏れチェックは投げると効きます。「このサイトマップで、BtoB製造業の見込み客が問い合わせに至るまでに不足している情報は」と聞くと、こちらが見落としていた項目がいくつか出てくることがあります。
指摘のうち採用できるのは一部ですが、それでいい工程です。ここでのAIの役割は正解を出すことではなく、自分の設計が前提にしている「言わなくても分かるだろう」を突いてくることにあります。社内で長く関わっているほど暗黙になる部分なので、外から一度当ててもらう価値があります。
もう1つ効くのがライティングの叩き台です。ワイヤーに入れるダミーテキストを「〇〇文字前後で、この見出しの下に入る本文」として生成させると、文字量の当たりが正確になります。レイアウト確認用のダミーが実際の原稿と文字量で乖離していると、原稿が入った瞬間にレイアウトが崩れる。これはAIが出てくる前からある古典的な事故で、AIで解決できる数少ない実務的な問題です。
日本語で組むサイトではとくに効きます。見出しが1行に収まるか2行に折り返すかでファーストビューの印象が変わるので、実際に入る想定文字数でダミーを作っておくと、デザイン段階で折り返しを確認できる。英文ロレムイプスムで組んだワイヤーが、日本語原稿を入れた途端に間延びする、という事故を防げます。
実装フェーズ
実装は言語と規模で切り替えます。
よく投げる
- 単発のCSSレイアウト（Grid・Flexの組み方）
- 正規表現・日付処理などの定型ロジック
- 既存コードのリファクタ案の提示
- エラーメッセージの原因当て
条件付きで投げる
- 新規のコンポーネント実装（規約を渡せるとき）
- テストコードの生成
投げない
- 本番デプロイ・DBのマイグレーション適用
- 既存の大規模テーマの改修
「単発で完結するもの」ほどAI適性が高い、というのが実装工程の全体像です。文脈を渡す量が少なくて済むほど、生成物の精度が上がります。
一番効くのは、実はエラーの原因当てです。スタックトレースを丸ごと貼って「何が起きているか」と聞くと、検索するより速く当たりがつくことがあります。これは「大量に読む」がAIの得意分野そのものだからで、人間がログを目で追う時間を丸ごと削れます。
このとき、エラーメッセージだけを切り取って貼らないのがコツです。前後のログ、実行環境、直前に触ったファイルまで一緒に渡すと精度が上がります。逆に「エラーが出ました」の一文だけでは、返ってくるのは一般的な原因リストで、検索結果と変わりません。ここでも効いているのは「文脈を渡した量」です。
逆に既存テーマの改修は成功率が落ちます。ShopifyのDawnテーマのように、本体の構造を理解した上で「どこを触らずに済ませるか」の判断が要る改修は、文脈の量が多すぎてAIには渡しきれません。この手の改修では、実装そのものより「どのファイルを触ってよいか」の線引きを人が先に決めるほうが効きます。触ってよい範囲を絞ってから渡せば、条件付きで投げられる仕事に変わります。
公開後・運用フェーズ
運用フェーズは、AIに投げると効くのに投げていない人が多い領域です。
- アクセス解析データの読み取り: GA4の数字をそのまま貼って「気になる変化と、その原因の仮説を3つ」と投げる。人が見落とす小さな変化を拾ってくれます
- 改善施策の候補出し: 「直帰率が高いページ」に対して打てる手を並べさせ、その中から自分で選ぶ
- クライアント向け説明文の平易化: 技術的な内容を非エンジニア向けに書き直す。ここはAIがかなり得意
ただし数字の解釈をそのまま報告書に載せない。AIは相関を因果として書く癖があります。「この施策で改善しました」と断定してくる文章が来たら、その因果が本当に成り立つかは自分で検証する。
検証のやり方は決まっていて、同じ期間に他の要因がなかったかを先に潰すだけです。広告の出稿量、季節性、他ページの改修、計測設定の変更。これらを確認しないまま因果を書くと、翌月に数字が戻ったときに説明できなくなります。報告書は毎月続くものなので、一度断定して外すと次回以降の説明がすべて重くなります。
AIツールの種類別｜どれをどの場面で開くか
ここまで工程順に見てきたので、今度は「ツールの種類」の軸で整理します。個別の製品名ではなく、種類の特性で覚えるのが実務的です。製品は入れ替わりますが、種類ごとの得意・不得意はあまり変わりません。
対話型（チャット）
もっとも汎用で、迷ったらここに投げる、という位置づけです。
強いところ: 文脈を積み上げられること。「さっきの案をもっと保守的に」「今度は逆に振って」と往復できるので、方向性が決まっていない探索段階に向いています。
弱いところ: セッションが変わると全部忘れること。案件の文脈を毎回説明し直すコストがバカにならないので、繰り返す作業には向きません。
実務的なコツとして、案件ごとに「前提を書いた短いテキスト」を用意しておき、毎回それを先頭に貼る運用にすると精度が安定します。クライアントの業種・ターゲット・トーン・NGワードをまとめたもので、これがあるとないとで出力の質がはっきり変わります。
この前提テキストは、書き足していく前提で持つのがコツです。使っていて「そこは違う」と直した内容を1行ずつ足していくと、案件が進むほど精度が上がります。案件の途中で担当が増えたときにも、そのまま共有すれば同じ品質で投げられるようになる。ディレクターが持つ資産としては、ツールの使い方より、この1枚のほうが価値があります。
コーディング支援型（エディタ統合）
エディタの中で動くタイプは、対話型とは用途が違います。
対話型に「Gridで3カラムのカードレイアウトを書いて」と聞くと汎用的なコードが返ってきますが、エディタ統合型はプロジェクトの既存ファイルを読んだ上で書くので、命名規則や使っているCSS変数に合わせてくれます。既存プロジェクトの改修では、こちらのほうが手戻りが少ない。
逆に、ゼロから設計を考える段階では対話型のほうが向いています。エディタの中だと、どうしても「今あるコードの延長」に引っ張られるためです。
| 対話型 | エディタ統合型 | |
|---|---|---|
| 得意な段階 | 探索・設計・方針決め | 既存コードの改修・実装 |
| 文脈の渡し方 | 毎回自分で説明する | プロジェクトを自動で読む |
| 出力の粒度 | 説明付き・抽象度が高い | 差分・すぐ動く形 |
| 向かない場面 | 繰り返しの実装作業 | ゼロからの設計判断 |
この2つは競合ではなく併用するもの、というのが現場の結論です。方針を対話型で決めて、実装をエディタ統合型に渡す。この流れが一番手戻りが少ない。
画像生成型
制作会社での使い方は、納品物ではなく検討材料が主戦場です。
デザインの方向性を3案並べて社内で議論するとき、ラフを描く時間を削れます。クライアントに「こういう雰囲気」を伝える叩き台としても使えます。ただしそのまま納品するのは避ける。理由は2つあって、①権利関係の説明責任を負えない ②細部の破綻がクライアント側で発見されると信用に響く、からです。
実務では「デザインの言語化」に使うのが一番効きます。上がってきたラフを見て「この方向は違う」と言うより、AIが出した複数案を並べて「これは近い、これは遠い」と指差してもらうほうが、クライアントとの認識合わせが速い。
見せ方には注意が要ります。「これは方向性を決めるための素材で、このまま作るものではない」と明示してから出す。説明せずに並べると、クライアントはそれを完成イメージとして受け取ります。あとから「あの画像と違う」という指摘が出るのは、たいていこの一言を省いた案件です。社内検討用と提示用でフォルダを分けておくと、混ざる事故も防げます。
検索・調査型
Web検索と組み合わさったタイプは、「知らないことの名前を知る」用途に絞ると外しません。
新しいツールや技術の名前だけ聞いて中身を知らないとき、概要をつかむのは速い。ただし数字と仕様は必ず一次情報で裏取りする。料金プラン、APIの引数、サービスの上限値。この3つは変わるのが速すぎて、AIの内部知識では追いつきません。AIの学習データには時点があるので、聞いた時点ですでに古い数字が返ってくることがあります。
この3ステップを踏むと、調査の速度は上がるのに精度は落ちません。1ステップ目だけで止めると事故ります。
もう1つ、名前そのものを間違えている場合があることも押さえておきます。新しいサービス名は綴りが似たものが多く、AIが知らない名前を知っている別のものとして扱ってしまうことがあります。返ってきた説明が妙に一般的だったり、公式サイトのURLが見つからなかったりしたら、名前の時点で食い違っている可能性を疑ってください。
発注者側から見た「AIを使う制作会社」の見分け方
ここからは発注する側の視点です。制作会社がAIをどう使っているかは、見積や提案の中身に必ず現れます。
安さの説明としてAIを持ち出す会社に注意する
「AIを活用しているので安くできます」という説明は、単体では判断材料になりません。どの工程を効率化したのかが具体的に言えるかどうかが分かれ目です。
- 「調査工程を短縮し、その分を設計に回している」→ 説明として成立している
- 「AIで作るので安い」→ 何が削れたのか不明。品質管理の工程が削られている可能性がある
制作費が安くなる理由は、AI以前にテンプレート利用の有無・ページ数・カスタマイズ範囲・原稿や写真をどちらが用意するかで決まります。そこを説明せずにAIだけを理由にしている場合は、内訳を聞き直したほうがいい。
聞き方は具体的なほうがいいです。「この見積で、AIを使っていない場合と比べて減っている工数はどこですか」と聞けば、答えられる会社は工程で答えます。答えられない会社は「全体的に効率化しています」と返ってきます。この差がそのまま、公開後に何かあったときの説明力の差になります。
「AIが書いた原稿」がそのまま納品されていないか
これは公開後に効いてきます。AI生成の原稿をそのまま載せたサイトは、業界の一般論しか書いていないという共通の症状が出ます。事例が入っていない、自社の数字が入っていない、どの会社のサイトに貼っても成立してしまう。
検索でもユーザーの信頼でも、これは不利に働きます。原稿制作を依頼するときは「取材やヒアリングをするか」を聞いておくと、この事故は防げます。
見分け方としては、社名を別の会社に置き換えても文章が成立するかを試すのが早いです。成立してしまうなら、その原稿は自社について何も語っていません。逆に、自社でしか言えない事実が入っていれば、置き換えた瞬間に嘘になります。この一点だけで、原稿の作り方はだいたい判定できます。
運用フェーズの体制を聞く
AIで制作を速くできても、公開後の運用は人がやる部分が多く残ります。更新対応、障害時の切り分け、計測の維持。ここが弱いと、公開直後は良くても半年後に放置サイトになります。
確認すべきは、担当者が変わっても回るかどうかです。属人的に一人が支えている体制は、その人が離れた時点で止まります。誰が窓口で、どこまでが月額に含まれ、どこからが別見積か。この3つが書面で示せる会社は、運用に入ってからのやり取りも軽くなります。
現場でよくある失敗と、その回避方法
実務で実際に起きた（あるいは起きかけた）失敗を並べます。ツールの選択より、こちらのほうが成果に効きます。
失敗1｜文脈を渡さずに投げて、汎用的な答えが返ってくる
一番多いパターンです。「ECサイトのCVRを上げる方法」と聞けば、教科書的な項目が並んで返ってきます。これは知識としては正しいが、目の前の案件には使えません。
回避方法: 制約を先に書く。「予算は追加開発なし、触れるのはテーマの範囲、ターゲットは40代女性のリピーター、カゴ落ちが起きているのは決済手段の選択画面」まで書くと、返ってくる案が実行可能なものに絞られます。制約が多いほど答えの質が上がる、という性質はAIに固有のもので、人間相手のブリーフィングとは逆の感覚が要ります。
失敗2｜生成物のチェックを飛ばして本番に出す
コードでもテキストでも、AIの出力は「もっともらしいが間違っている」形をとります。明らかにおかしいものは気づけますが、大部分が合っていて一部だけ間違っているものが一番危ない。
回避方法: 「本番に出す最後の一歩は必ず人がやる」を運用ルールにする。デプロイ、記事の公開、メールの送信、DBの変更。ここだけは自動化しない。実行した本人が結果を見て報告できる状態を保つ、という考え方です。
失敗3｜守秘情報を投げてしまう
クライアントの未公開情報、個人情報、認証情報。これらを外部サービスに投げるのは契約違反になり得ます。
回避方法: 案件開始時に「AI利用の可否と範囲」をクライアントと合意しておく。使ってよい範囲が決まっていれば、判断のたびに悩まなくて済みます。合意が取れていない案件では、固有名詞を伏せて構造だけを投げる運用に切り替える。
失敗4｜AIに判断を任せてしまう
これが構造的には一番深刻です。「どっちの案がいいと思う?」と聞くと、AIは必ず答えを出します。それらしい理由も付いてきます。しかしその判断の責任はAIが取れません。
回避方法: AIに聞くのは「選択肢と、それぞれのトレードオフ」まで。選ぶのは自分。この線を引いておかないと、なぜその設計にしたのかをクライアントに説明できなくなります。説明できない成果物は、修正が入ったときに崩れます。
失敗5｜同じ仕事を毎回ゼロから投げている
見落とされやすい失敗です。案件が変わるたびに前提を一から説明し直し、毎回違う品質のものが返ってくる。うまくいった投げ方が手元に残らないので、経験が積み上がりません。
回避方法: うまくいった指示文をそのまま保存する。案件名を差し替えるだけで再利用できる形にしておけば、2回目以降の精度が安定します。競合調査、抜け漏れチェック、説明文の平易化。この3つは案件をまたいで同じ形が使えるので、まずここから貯めるのが早いです。
使い分けの判断基準を1枚にまとめる
ここまでの内容を、実務で参照できる形に圧縮します。
| 場面 | 投げるか | 判断の根拠 |
|---|---|---|
| 競合サイトをまとめて調べる | 投げる | 大量に読む・並列可・書き込まない |
| サイト構成の抜け漏れ検査 | 投げる | 網羅性の検査は機械が強い |
| エラーの原因当て | 投げる | ログを大量に読むのが得意 |
| 単発のCSS・定型ロジック | 投げる | 文脈が少なくて済む |
| デザイン方向の3案出し | 投げる | 案が複数あってよい・手戻りが安い |
| 情報設計そのもの | 投げない | 案件ごとに唯一解がある |
| 見積・金額の根拠 | 投げない | 出典のない数字が出る |
| 本番デプロイ・公開 | 投げない | 壊れた瞬間を人が見ている必要がある |
| 最終的な選択 | 投げない | 責任を取れるのは人だけ |
この表の右の列が本質です。「投げるか」は覚えなくてよくて、根拠のほうを覚えると、新しい場面でも自分で判断できるようになります。
よくある質問
AIツールは有料版を契約すべきですか？
用途によります。探索や叩き台づくりが中心なら無料版でも十分に効果が出ますが、既存プロジェクトの改修に使うならエディタ統合型の有料プランが実務的な差になります。判断の目安は「月に何時間削れるか」で、削れる時間の人件費が月額を上回るなら契約する価値があります。まず無料版で1か月使い、削れた時間を実測してから決めるのが確実です。
AIで作ったサイトは検索で不利になりますか？
生成に使ったこと自体が不利になるわけではありません。不利になるのは、どの会社のサイトに貼っても成立するような一般論だけの内容になっている場合です。自社の事例・数字・具体的な運用経験が入っていれば問題になりません。AIを下書きに使い、固有の情報を人が足す運用にしてください。
制作会社にAI利用の可否を確認すべきですか？
確認しておくことをおすすめします。とくに未公開情報や個人情報を扱う案件では、契約書にAI利用の範囲を明記しておくとトラブルを防げます。禁止するかどうかより、「どこまで使ってよいか」を先に決めておくほうが実務的です。使用そのものを一律禁止にすると、調査工程まで止まって納期に影響することがあります。
ディレクターの仕事はAIに置き換わりますか？
置き換わるのは調査・整理・叩き台づくりの部分で、判断と説明責任の部分は残ります。むしろ選択肢を出す速度が上がった分、「どれを選ぶか」の判断が仕事の中心に移ります。クライアントに対して設計の理由を説明できるかどうかが、これまで以上に問われるようになっています。
どのツールから試すべきですか？
対話型を1つ選び、案件の前提をまとめたテキストを用意して1か月使うところから始めてください。ツールを並行して試すより、1つを深く使い込むほうが「投げ方」が身につきます。投げ方が分かってから2つ目に手を出すと、比較の軸が自分の中にできているので判断が速くなります。
まとめ
AIツールの比較で本当に必要なのは、製品の機能表ではなく投げる／投げないの判断基準です。
押さえるべき線は3本あります。
- 投げてよいのは「大量に読む × 案が複数あってよい × 手戻りが安い」が揃うとき。1つでも欠けたら自分でやる
- 本番に出す最後の一歩は人がやる。デプロイ・公開・送信・削除は自動化しない
- 判断はAIに渡さない。選択肢とトレードオフまでを聞き、選ぶのは自分
この3本を持っていれば、来年ツールの名前が全部入れ替わっても、同じ基準で判断できます。逆に「どのツールが最強か」を追い続けると、半年ごとに探し直すことになります。
発注する側にとっても同じで、制作会社がAIを使っているかどうかより、どの工程を効率化して、その分をどこに回しているかを説明できるかが判断材料になります。説明できる会社は、成果物についても説明できます。
