「AIを使ってLP修正を高速化したから何？」と思ってたら予想以上に奥が深かった話

社内の勉強会で、先輩がひとつのケースを話してくれました。

朝10時に行ったミーティングでレビューをもらったLPの大幅修正を、2時間以内に返した。即クライアント側でミーティングしてもらって、その日のうちに確認まで終わらせた。

従来なら3日から4日はかかる修正量、そしてミーティングから確認まで1週間以上かかるレベルだったそう。

正直に言うと、私は最初、心の中でこう思っていました。

「AIで作業を速くしたって話でしょ。で、それが何？」

聞き終わったいま、その感想を取り消したいです。速くなったのは結果で、本題は別のところにありました。

私が浅かった。今日はその、想像以上に奥が深かった話を書きます。

表面だけ見ると「高速化しました」で終わる

先輩のケースは、こう要約できます。

3〜4日かかる大幅修正を、当日朝に返した。プロジェクトのサイクルが一気に上がった。

これだけ聞くと、AIで制作を高速化した成功例に見えます。私もそう受け取りました。でも先輩の話を分解していくと、高速化はいちばん最後に出てくる「結果」でしかなくて、その手前に三段の設計が積まれていました。

順番が大事だ、と先輩は何度も言っていました。

一段目：作る人を、できる限り減らす

最初は組織と人の設計です。

先輩の前提はシンプルでした。プロジェクトを推進する人数が少なければ少ないほど、スピードは上がる。

究極の理想は、戦略設計を、あらゆる施策を、クリエイティブを、計測を、一人のプロジェクト推進者が全てできるようになること。確認や調整で人を挟むほど、プロジェクトは遅くなる。

ただ、ここで壁があります。

例えばクリエイティブを非クリエイターの推進者が作っても、クライアントワークで出せるクオリティには届かない。これは先輩自身が、はっきりそう言っていました。デザインとしては出せない、と。

そこで登場するのが、デザイナーの先輩です。役割が独特でした。

素晴らしいデザインに仕上げる、だけではない。デザインシステムから根本でガチガチに固める。崩れない土台を作る。そうすると何が起きるか。

あとからどれだけ修正を入れても、デザインが崩れない。つまり、修正のたびにデザイナーへ依頼を出さなくてよくなる。

あとは、非クリエイターの推進者が一人でAIを活用し直しきれる。デザイナーの先輩の役割は「素晴らしいクオリティに仕上げる」だけではなく、「修正しても崩れない土台も合わせて構築する」だったんです。

依頼を挟むと、相手が朝起きているかも、手が空いているかも、認識が合っているかもわからない。その不確実性をまるごと消すための土台づくり。ここに痺れました。

二段目：AI部下が、修正のクオリティを底上げする

土台ができても、現実はそんなにきれいにいきません。

修正の一個一個を手で打ち込むのは時間がかかるし、ミーティング単体の情報だけだと、文脈が抜けて指示がぶれる。クライアントに言われた言葉をそのまま直すと、ずれる。

ここで先輩のAI部下が動きます。

このAI部下は、これまでの資料やミーティングを集めており、細かいコンテキストを全部まとめて把握しています。

プロジェクトがいまどこに向かっているか、過去にどんな議論があったか、どんな修正指示が出ているか。そのコンテキストと、レビューのミーティングデータを掛け合わせて、修正指示書を作ってくれる。

先輩の言い方が腑に落ちました。

「修正のたびにデザイナーを変えないですよね？同じプロジェクトをずっと一緒にやってきた人に頼むほうが速い。なぜなら、その人はプロジェクトの文脈を背負っているから。」

AI部下は、その「あらゆるプロジェクトのコンテキストを丁寧に整理して把握している」状態を作っていました。

そして、自律実行するAI部下は、文脈とレビューデータをベースに、ミーティングが終われば修正指示書をすぐに仕上げてくれている。それをLPの制作環境に渡して、AIに修正してもらう。

デザインは崩れない。土台があるから。あとは人として目視で見返して整える。推進者がこれ以上ない、そう思えるまで作り込む。大幅に変わった修正でも、2時間以内で終わる。

高速化は、ここでようやく顔を出します。でもそれは、一段目と二段目が積み上がった先にある結果でした。

三段目：AIが指示書を作りやすいように、ミーティングをする

私がいちばん見落としていたのが、ここです。

修正指示書はAI部下が作る。ということは、そのインプットになるミーティングの質が、すべてを左右します。だから先輩は、AI部下が指示書を作りやすいようにミーティングをしていました。

先輩はクライアントに資料や見出し案を持っていかず、サイトやLPをそのまま渡して、ストーリーラインを語り、ゴリゴリその場でレビューをしてもらい、ディスカッションするようです。

その時に、どうまとめるかを意識して、ちゃんと言葉として音声に残すこと。

後でAI部下が出してはいけない情報をマスキングしたトランクスリプトを読んで指示書にするから、ミーティング時点でそれらを踏まえて、少しでも良い修正指示書を作ってくれるように。

ミーティングが、ただの打ち合わせではなく、AIへの上質なインプットを作る場になっていました。

AIベースのプロジェクトって、自分の仕事のあり方に合わせるのでなく、AIをベースにリビルドすることの意味を、改めて思い知らされました。

本質は、高速化そのものじゃなかった

三段を聞いて、最初の「高速化したから何？」が、いかに浅い感想だったかがわかりました。

先輩がやっていたのは、単にLP修正を速くすることではありません。これを高速化の小技として真似しても、たぶん再現できない。

先輩の言葉を借りると、AIベースの支援会社として、プロジェクトのあり方そのものを設計している。人の置き方、AIの挟み方、ミーティングの作り方。この三段がセットで初めて、当日修正が成立する。

そして大事なのは、この型がLP修正だけの話じゃないことです。戦略でも、コンテンツでも、あらゆる領域で同じ構造が組める。LP修正は、その型がたまたま現れた一例にすぎませんでした。

さいごに

「AIで高速化したから何？」

この問いは、まちがってはいませんでした。AIで作業を速くしただけなら、本当に「だから何？」で終わります。

ただ、先輩がやっていたのはその逆で、速くなったのは結果だった。作る人を減らし、崩れない土台を作り、AIが文脈を背負い、その文脈が育つようにミーティングを設計する。順番に積み上げた先に、当日修正という結果が乗っていました。

私はこれから、何かが速くなったとき、もう一度立ち止まろうと思います。速くなったのは結果で、その手前に設計があるんじゃないか、と。

それを教えてくれた一例が、朝に返ってきたLPでした。