この記事の対象: 制作会社のディレクター・一人親方の制作者、およびAI活用を制作会社に期待している発注担当者
読了時間: 約12分
「AIで制作が速くなったんでしょう?」
打ち合わせの席で、最近よく言われるようになりました。半分は当たっていて、半分は外れています。速くなった工程は確かにあります。ただそれはコードを書く速度ではなく、ディレクションの下ごしらえの速度でした。
Webディレクターの仕事は、手を動かしている時間より「考えを文章に落とす時間」のほうが長い。議事録、要件の整理、見積の内訳、進行表、レビューのコメント。この「文章に落とす」部分が、AIで一番大きく変わりました。逆に、まったく変わらなかった部分もはっきりしています。
この記事では、要件定義・見積・進行管理・レビューの4工程について、実際にどこをAIに任せ、どこは人がやるべきかを線引きします。ツールの機能紹介はしません。現場で使っている手順とプロンプトの型、そして「任せて失敗した」話まで書きます。
そもそもAIに任せられる仕事の共通点
工程別の話に入る前に、判断基準を先に置きます。これがないと「とりあえずAIに聞いてみる」で終わり、時間だけ溶けます。
現場で回してみて残った基準は、次の3つが揃うかどうかでした。
任せる（速くなる）
- 正解が1つに決まらない
- 量が多く、下書きでいい
- 間違いを人が即座に見抜ける
任せない（かえって遅い）
- 数字や事実の正確さが命
- クライアントとの関係が絡む
- 間違いに気づけない領域
3つ目の「間違いを人が即座に見抜ける」が一番大事です。自分が判断できない領域の答えをAIに出させると、確認に時間がかかって結局遅くなります。AIは自分より下手なことを速くやらせる道具であって、自分より上手なことをやらせる道具ではない、というのが実際に回してみた実感です。
「業務効率化」の中身を分解しておく
AIディレクションによる業務効率化、と一言でいっても、実際に短くなっている時間は3種類しかありません。
| 短くなる時間 | 具体例 | 体感 |
|---|---|---|
| 白紙から書き出す時間 | 要件定義書の骨組み、議事録の整形 | 一番大きい |
| 抜け漏れを探す時間 | 見積項目のチェック、レビュー観点の洗い出し | 中くらい |
| 同じ形の文章を量産する時間 | 進捗報告メール、修正指示のまとめ | 小さいが毎日ある |
逆に、判断そのものにかかる時間はまったく短くなりません。「このサイトはWordPressで作るべきか、Shopifyで作るべきか」を考える時間は、AIを使ってもほとんど減りませんでした。減ったのは、決めたあとにそれを説明する文章を書く時間だけです。
ここを取り違えて「AIを入れれば工数が半分になる」と発注者に説明してしまうと、必ず揉めます。減るのは作文の時間で、設計の時間ではありません。
工程1: 要件定義 — 議事録から要件へ変換する
要件定義は、AI活用の効果が一番はっきり出た工程です。ただし「AIに要件定義をさせる」のではなく、「ヒアリングの音声・メモを、要件の形に整形させる」という使い方に限ります。
現場でやっている手順
2つ目の「割る」と3つ目の「訊く」だけをAIに任せ、4つ目は人が書く。この分け方が現時点での最適解でした。
使っているプロンプトの型
汎用のテンプレートを晒します。案件ごとに1行目だけ差し替えて使っています。
あなたはWeb制作会社のディレクターです。
以下は、コーポレートサイトのリニューアル案件の初回ヒアリング文字起こしです。
次の3つに仕分けて、それぞれ箇条書きで出してください。
1. 決定事項（クライアントが明確に「こうしたい」と言ったこと）
2. 宿題（クライアント側が持ち帰ったこと・こちらが調べること）
3. 未定（話題には出たが結論が出ていないこと）
ルール:
- 文字起こしに書かれていないことを補完しない
- 曖昧な発言は「未定」に入れる。決定事項に格上げしない
- 発言者が不明な箇所は末尾に (話者不明) と付ける
---
（文字起こしを貼る）
最後の3行、「補完しない」「格上げしない」が要です。これを書かないと、AIは気を利かせて言われていないことを決定事項に混ぜてきます。実際に一度、「スマホ対応は当然やる前提」という一文がクライアント発言として要件に紛れ込み、危うくそのまま議事録として送りかけました。言っていないことを言ったことにするのは、制作会社が絶対にやってはいけないミスです。
「抜けている論点」を出させるのが一番効く
もう1つ、要件定義でAIが最も価値を出すのが論点の洗い出しです。ベテランのディレクターが頭の中でやっている「これ聞き忘れてないか」の確認を、機械的に代行させます。
上記のヒアリング内容をもとに、Webサイトのリニューアル案件として
まだ確認できていない論点を、重要度の高い順に15個挙げてください。
観点:
- 公開後の運用（誰が何をどれくらいの頻度で更新するか）
- 既存資産の扱い（ドメイン・サーバー・アクセス解析・過去記事）
- 承認フロー（誰が最終決裁するか、何人が意見を出すか）
- 制約（公開希望日、社内規定、業界の表示ルール）
各論点について「なぜ確認が必要か」を1文添えてください。
15個出させると、多くは自分でも気づいていた項目です。それでも毎回1〜2個は「あ、確かに聞いてない」が混じります。この1〜2個が、後工程での手戻りを防ぎます。
とくに引っかかりやすいのがドメインとサーバーの名義まわりです。ここは着手前に確認しておかないと、公開直前に動けなくなる典型ポイントでした。
人がやるべきこと
要件定義でAIに渡してはいけないのは、「何を作らないか」の判断です。
ヒアリングで出てきた要望を全部積むと、予算に収まりません。どれを削り、どれを次フェーズに送るか。この線引きは、クライアントの温度感・社内政治・予算の余地を全部踏まえた判断なので、文字起こしには現れない情報で決まります。AIに「優先順位をつけて」と頼むと、それらしい順位表は出てきますが、現場感が抜けた順位になります。
「社長が朝礼で3回言っていた機能」は、機能単体の重要度としては低くても、削れないことがある。これはAIには絶対にわかりません。
工程2: 見積 — 積算はAIに、金額は人に
見積は、AIの使いどころと使ってはいけないところが最もはっきり分かれる工程です。
任せてよいのは「項目の洗い出し」まで
やっているのは、要件定義書を渡して作業項目に分解させるところまでです。
以下の要件定義をもとに、制作作業をWBSの形で分解してください。
出力形式:
| 大工程 | 中工程 | 作業内容 | 想定成果物 |
ルール:
- 工数・金額は書かない（こちらで入れます）
- ディレクション、デザイン、実装、テスト、公開作業、
公開後の初期サポートまで含めて漏れなく出す
- クライアント側の作業（原稿提供・素材提供・確認）も
別の表に分けて出す
---
（要件定義書を貼る）
「工数・金額は書かない」を明示するのが肝です。書かせるとそれらしい数字が出てきますが、その数字には根拠がありません。AIが持っているのは学習時点の一般論であり、自社の単価でも、そのメンバーの実際の速度でもない。
そして厄介なことに、AIが出す工数は「もっともらしい」。0.5人日と書かれていると、なんとなくそんな気がしてしまいます。この「もっともらしさ」が一番危険で、根拠のない数字を根拠のある数字と同じ顔で出してくるところが、見積工程でAIを使う最大のリスクです。
【制作者目線】工数はチームの実測でしか埋まらない
工数は、そのチームが過去に同じ作業を何時間でやったかの実績でしか決まりません。同じ「トップページのコーディング」でも、テンプレートベースなら数時間、フルスクラッチのアニメーション込みなら数日かかります。これは案件の性質とメンバーのスキルの掛け算で、外部から推定できるものではない。
だから見積の運用は、AIが出した項目表に、自社の過去案件の実測値を人が貼り付けるという形に落ち着きました。項目の洗い出しは機械的作業なのでAIが速い。数字は自社データベースの照合作業なので人が速い。役割分担が素直に決まる工程です。
【発注者目線】「AIを使っているから安い」は成立しにくい
発注側の方に伝えたいのはここです。「AIを使っているなら安くなるはずだ」という交渉は、実はあまり有効ではありません。
理由は単純で、制作費の大部分は判断と調整の時間だからです。デザインの方向性を決める、修正の意図を汲む、社内の意見を取りまとめる、公開後の運用を設計する。ここが減らない以上、総額は劇的には下がりません。
むしろ見るべきは「何にいくら払っているか」の内訳が説明できる会社かどうかです。AIで下ごしらえを効率化している会社ほど、内訳を細かく出せる傾向があります。項目分解が機械的にできるようになったぶん、粒度が細かくなるからです。
見積の内訳をどう読むかについては、こちらで詳しく分解しています。
工程3: 進行管理 — 状態の要約は任せ、催促は人がやる
進行管理は、AIに任せた効果が「小さいが毎日ある」タイプの工程です。劇的には変わりませんが、じわじわ効きます。
効果があった3つの使い方
| 用途 | やり方 | 効果 |
|---|---|---|
| 週次の進捗報告 | タスクリストの差分を渡し、報告文に整形させる | 書き出しの時間がまとまって減る |
| 修正指示の整理 | クライアントからのバラバラな指摘を、ページ別・種別に仕分けさせる | 指示の取りこぼしが減る |
| 課題の棚卸し | 「未解決のまま一定期間動いていない項目」を抽出させる | 忘れていた課題が出てくる |
2つ目の「修正指示の整理」が、地味ですが一番効きました。
クライアントからの修正依頼は、たいていメール本文に箇条書きでない形で来ます。「トップの写真、もう少し明るくできますか。あと会社概要の住所が古いままでした。それとスマホで見たときにボタンが押しにくい気がします」といった具合です。これを人力でチケットに割ると、3つ目を落とします。
以下はクライアントからの修正依頼メールです。
修正項目を漏れなく抽出し、次の表にしてください。
| No | 対象ページ | 修正内容 | 種別 | 判断が必要か |
種別は「文言」「画像」「レイアウト」「機能」「不明」から選ぶ。
「判断が必要か」は、こちらで勝手に直してよいものは「不要」、
クライアントに確認が要るものは「要確認」と書く。
メール本文に書かれていない修正を推測で足さないこと。
---
（メール本文を貼る）
「判断が必要か」の列を作らせるのがポイントです。誤字修正のように勝手に直してよいものと、デザインの方向性に関わるものを分けておくと、確認のラリーが1往復減ります。
催促と謝罪は人がやる
一方で、スケジュールが遅れているときの連絡は、絶対にAIに書かせません。
原稿がまだ来ていない、確認が返ってこない、公開日が危ない。こういう連絡は、文面の巧拙より「誰が言っているか」が効きます。AIが整えた滑らかな文章は、丁寧なのに他人事に読める。遅延の連絡で他人事に読まれるのは最悪です。
謝罪も同じです。こちらのミスで手戻りが出たとき、整った謝罪文はかえって不誠実に見えます。下手でも自分の言葉で書いたほうが伝わる、というのは何度か失敗して学びました。
工程4: レビュー — 観点は網羅させ、優先順位は人が決める
公開前チェックは、AIとの相性が非常によい工程です。理由は「観点の網羅」が主な作業で、しかも間違いを人がすぐ見抜けるから。冒頭に挙げた3条件が綺麗に揃います。
5つの視点で並列にレビューさせる
現場では、同じ成果物を5つの視点に分けて、それぞれ別々にレビューさせています。
UX視点
- 導線の迷い
- フォームの離脱要因
- スマホでの操作性
コピー視点
- 誤字・表記ゆれ
- 専門用語の残り
- 主語の欠落
テクニカル視点
- 表示速度
- アクセシビリティ
- リンク切れ
ビジネス視点
- CVへの導線
- 訴求の一貫性
SEO視点
- タイトル・見出し構造
- 構造化データ
- 内部リンク
まとめて「レビューして」と頼むと、指摘が浅く広くなります。視点を1つに絞って別々に走らせると、それぞれが深く掘ってくれる。この差は想像以上に大きいです。
出てきた指摘は3つに仕分ける
重要なのは、AIが出した指摘をそのまま修正リストにしないことです。実際に出てくる指摘は、次の3種類が混ざっています。
- 直すべきもの: 誤字、リンク切れ、コントラスト不足など、客観的に誤りといえるもの
- 好みの問題: 「もっと余白を取るべき」「CTAは目立つ色に」など、方針次第で変わるもの
- 文脈を知らないがゆえの的外れ: クライアントの意向で意図的にそうしている箇所への指摘
1つ目だけを機械的に直し、2つ目は判断し、3つ目は捨てる。この仕分けを人がやらないと、クライアントが指定したブランドカラーを「視認性が低い」という理由で勝手に変えるといった事故が起きます。
【制作者目線】検査の軸そのものを先に検証する
チェックを自動化するときに一度やらかしたのが、検査スクリプト自体が壊れていて「問題なし」を返し続けていたケースです。全ページOKと出るので安心していたら、そもそも検査対象のURLを取り違えていた。
だから自動チェックを組むときは、必ず「わざと壊したページ」を1枚用意して、それを検知できるかを先に確かめます。検知できて初めて、その検査は信用できる。「エラーゼロ」は「異常なし」ではなく「見ていない」かもしれない、という疑いを常に持つ必要があります。
【発注者目線】AIチェックがあっても人の目視は必要
発注側として知っておいてほしいのは、AIによるチェックは「見落としを減らす仕組み」であって「品質を保証する仕組み」ではないということです。
たとえばアクセス解析の計測タグが正しく動いているか。タグが埋まっているかどうかはツールで機械的に検査できますが、「意図した数字が取れているか」は実際に流入させて確認するしかありません。この最後の確認を省く会社と省かない会社の差が、公開後の運用で効いてきます。
実装工程でのAI利用は、別のルールが要る
ディレクション工程とは少し外れますが、実装でAIを使う場合の線引きにも触れておきます。ディレクターが管理する側として、知っておくべき性質があるからです。
AIが書いたコードで一番怖いのは、動くけれど将来のアップデートで壊れる書き方をしてくることです。テーマ本体のファイルを直接書き換えてしまう、既存のクラス名を上書きしてしまう、といった実装は、その場では動きます。壊れるのは半年後、テーマの更新をかけたときです。
だから実装をAIに任せる場合は、渡す前に3つを決めておきます。触ってよいファイル、作ってよい命名規則、絶対に触らない領域。この3つを渡さずに「実装して」と頼むと、動くけれど保守できないものが出てきます。
とくに効くのが2つ目の命名規則です。独自に足すクラス名やファイル名に共通の接頭辞を決めておくと、あとから「どこを自分たちが触ったか」が検索1回でわかります。テーマ更新で衝突したときも、切り分けが数分で終わる。逆にここを決めずに走らせると、半年後に「この記述は元からあったのか、AIが足したのか」が誰にもわからなくなります。
このあたりの、アップデートに耐える改修の考え方は、AIを使うかどうかに関係なく共通です。
同じ発想で、更新する人が壊さない仕組みを先に作っておく話も、AI時代にはより重要になりました。AIに更新作業を任せる可能性が出てきたぶん、「壊れにくい枠組み」の価値が上がっています。
工程別のまとめ表
ここまでの線引きを1枚に整理します。
| 工程 | AIに任せる | 人がやる |
|---|---|---|
| 要件定義 | 文字起こしの仕分け、抜け論点の列挙、文書の骨組み | 何を作らないかの決定、優先順位づけ |
| 見積 | 作業項目の分解、抜け項目のチェック | 工数の数値、単価、値引きの判断 |
| 進行管理 | 進捗報告の整形、修正指示の仕分け、停滞課題の抽出 | 遅延連絡、謝罪、スケジュールの組み替え判断 |
| レビュー | 5視点での観点網羅、機械的チェック | 指摘の仕分け、修正するかの判断、最終目視 |
| 実装 | 定型的なコード、既存パターンの横展開 | 触ってよい範囲の設計、公開作業 |
眺めてみると、人が担う側に共通しているのは「決めること」と「外に出すこと」の2つです。
決めることは、社内外の文脈を全部踏まえた判断なので、渡せる情報の量が足りません。外に出すことは、失敗したときに誰も見ていない状態を作ってはいけないので、実行した本人が結果を確認できる形にしておく必要がある。
この2つを守っている限り、AIをどれだけ使っても事故は起きにくい、というのが現時点での結論です。
小規模なチームから始めるときの導入順序
「どこから手をつければいいか」と聞かれることが増えたので、着手の順番も書いておきます。全工程を同時に変えようとすると、たいてい途中で止まります。
1週目は議事録の整形だけにします。文字起こしを仕分けさせる、それだけ。効果が一番大きく、失敗しても損害が出ない工程だからです。ここで「AIが補完してくる」「曖昧な発言を決定事項に上げてくる」といった癖を先に体感しておくと、後の工程で同じ罠を踏みません。
次に手を出すのはレビューの観点出しです。理由は、間違っていてもすぐわかるから。指摘の3〜4割は的外れですが、的外れだと1秒でわかるので、時間の損失がほぼありません。
見積と進行管理は最後にします。この2つは数字と対人関係が絡むので、AIの癖を理解していない状態で入れると事故ります。とくに見積は、根拠のない工数がそのまま提示額になる経路ができてしまうと、あとから直すのが難しい。
社内に定着させるときのコツは、プロンプトを個人の手元に置かないことです。うまくいった型を共有フォルダの1ファイルにまとめ、案件で使うたびに追記していく。個人が各自でプロンプトを工夫している状態は、一見すると生産的ですが、品質のばらつきと属人化を同時に生みます。要件定義で使う型、修正指示の仕分けで使う型、レビューの視点別の型。この3つが共有されているだけで、チームの出力はかなり揃います。
発注者が制作会社に聞くとよい質問
発注側の立場でこの記事を読んでいる方向けに、実務的な確認事項を置いておきます。「AIを使っていますか」と聞いても、はいとしか返ってきません。聞くならこちらです。
- AIが出した成果物を、誰がどう確認していますか
確認の工程が答えられない会社は、そのまま納品している可能性があります。 - 弊社の情報を、AIサービスにどこまで渡しますか
未公開の情報や個人情報を扱う場合は、事前に取り決めが必要です。学習に使われない設定になっているか、聞いておいて損はありません。 - AIで効率化したぶん、何に時間を使っていますか
ここに「設計と検証に時間を回している」という答えが返ってくる会社は、使い方を理解しています。「そのぶん安くしています」だけの答えだと、削っているのが下ごしらえではなく確認工程かもしれません。
3つ目が一番効きます。効率化の目的が値下げだけになっている場合、削られているのはたいてい目に見えない工程です。
よくある質問
AIを使うと、Web制作の費用は安くなりますか?
劇的には安くなりません。制作費の大部分は、設計・判断・調整といった人の時間だからです。AIで短くなるのは、文書を書き起こす時間や項目を洗い出す時間で、これは全体の一部にとどまります。ただし、下ごしらえが速くなったぶん、見積の内訳を細かく説明できる会社は増えています。
AIに要件定義を丸ごと任せることはできますか?
できません。要件定義の核心は「何を作らないか」を決めることで、これは予算・社内事情・クライアントの温度感といった、文字に現れない情報で決まります。AIが得意なのは、ヒアリング内容の仕分けと、確認漏れの論点を列挙することまでです。ここまでを任せるだけでも、書き出しの時間はかなり短くなります。
AIが書いた文章をそのままクライアントに送っても大丈夫ですか?
内容の種類によります。進捗報告や修正項目の一覧のような事務的な文書は、事実確認をしたうえで送って問題ありません。一方で、遅延の連絡や謝罪、提案の意図を伝える文章は、自分の言葉で書いたほうが伝わります。整った文章ほど他人事に読まれるためです。
制作会社がAIを使っているかどうか、発注前に確認すべきですか?
使っているか自体より、確認体制と情報の扱いを聞くほうが有益です。「AIが出したものを誰がどう検証しているか」「自社の非公開情報をどこまで外部サービスに渡すか」の2点を質問すれば、運用の成熟度がだいたい見えます。答えられない場合は、社内ルールが整備されていない可能性があります。
AIで公開前チェックを自動化すれば、目視確認は不要になりますか?
なりません。機械的に検査できるのは、リンク切れ・タグの有無・見出し構造のような形式的な項目までです。「意図した数字が計測できているか」「実機で操作して違和感がないか」は、人が実際に触って確認する必要があります。むしろ検査ツール自体が壊れていて「問題なし」を返し続ける事故があるため、検査結果を信じる前に検査そのものを検証する工程が要ります。
AIディレクションの導入は、どの工程から始めるのがよいですか?
議事録の整形からです。効果が最も大きく、失敗しても損害が出ません。次にレビューの観点出し、最後に見積と進行管理という順番が安全です。見積は根拠のない工数がそのまま提示額になる経路を作りやすく、進行管理は対人の連絡が絡むため、AIの癖を理解してから触るべき工程になります。
まとめ
AIでWebディレクションを効率化する、という話を工程別に分解すると、線引きは思ったよりシンプルでした。
任せてよいのは、下ごしらえと網羅。任せてはいけないのは、決めることと外に出すこと。
要件定義なら、仕分けと論点出しは任せて、何を作らないかは自分で決める。見積なら、項目分解は任せて、数字は自社の実測を貼る。進行管理なら、報告の整形は任せて、遅延の連絡は自分で書く。レビューなら、観点の網羅は任せて、指摘の仕分けは自分でやる。
この線を引いたうえで使うと、確かに楽になります。とくに「白紙から書き出す」ストレスが消えるのが大きい。ディレクターの仕事で一番エネルギーを食っていたのは、実はそこだったのだと使ってみて気づきました。
一方で、判断の時間は減っていません。むしろ下ごしらえが速くなったぶん、判断に向き合う時間が増えました。これは効率化として正しい方向だと思っています。減らすべきは考える時間ではなく、考える前の準備時間です。
制作会社を選ぶ側の方は、「AIを使っているか」ではなく「AIで浮いた時間を何に使っているか」を聞いてみてください。そこに設計と検証の話が出てくるかどうかで、その会社の姿勢がわかります。
