Mike Rhodesがマーケティング構築から学んだVibe Codingの教訓を共有

エピソード概要

OptmyzrのCEO兼共同創業者であるFrederick Vallaeysが、Google AdsのエキスパートでありAds to AIの創設者でもあるMike Rhodesと対談し、マーケターがAIとvibe codingをどのように効果的に活用できるかを探ります。議論では、AIが実際のアカウントコンテキストに基づいてこそ真に強力になる理由、使うツール以上により良い質問をすることが重要である理由、そしてマーケターが開発者にならずに実用的なAI搭載ツールを構築する方法について取り上げます。

Mikeは、自身の歩みから得た実例を共有します。何年も前にProfit Curveツールを作った話から、AIを活用したPPCエキスパートの評議会である8020 Brainを構築した話まで、幅広く紹介します。この会話では、Google Ads scriptsから本格的なアプリケーション開発まで、AIがより広いPPCワークフローにどのように組み込まれるのか、そしてなぜビジネスコンテキストがこれまで以上に重要なのかも掘り下げます。

学べる内容は以下のとおりです。

• AIを一般的な「平均的」な回答から引き上げ、自社に特化した結果を得る方法
• コンテキストと制約がAIをより賢くする理由、そして制限するわけではない理由
• vibe codingの現実的な限界と、依然として開発者が必要な場面
• 非技術系の人が、数か月ではなく数時間で機能するツールを構築した実話
• すべての技術的詳細を習得しようとするのではなく、AIツールの指揮者になる方法
• AIには完璧なプロンプト以上に、適切な質問と土台づくりが必要な理由
• すべてを事前に計画するのではなく、作りながら反復していくというマインドセットの転換
• AIを、単に実行するだけでなく、自分のアイデアに挑戦してくる思考パートナーとして扱う方法
• AI自動化の時代において、技術スキルよりもビジネス理解が勝る理由
• 圧倒されずに、今日から構築を始めるための実践的な第一歩

エピソードの要点

Mike Rhodesは20年以上PPCに携わっており、オーストラリアで17年間エージェンシーを運営した後、売却してAI搭載ツールの構築と、その方法を他者に教えることに専念しています。彼は、何千人もの広告主が利用する人気のPMax scriptの作成者であり、さらに最近では8020 Agentと8020 Brainを開発しました。これらのツールは、マーケターがデータを理解し、シミュレーションされたPPCエキスパートの評議会から助言を得るのを支援します。

この対談から見えてくる明確なパターンは、AIとvibe codingは専門性を置き換えるためのものではなく、それを増幅するためのものだということです。Mikeの哲学は、シンプルな考え方に集約されます。先に進んで作り、何が可能かを見極め、そして実際に役立つ実践的な内容を持ち帰って共有する。彼は理論には興味がありません。求めているのは、多少粗削りでも現実の問題を解決するツールです。

このエピソードの価値は、その地に足のついた内容にあります。Mikeは失敗や限界について率直に語り、vibe codingで作られたツールはしばしば80〜90%までは到達するものの、開発者のレビューなしでは本番運用には耐えないことを説明します。彼は、GitHubが何かも知らなかった70歳のコミュニティメンバーが、Claudeを使って一晩で完全に機能するインストーラーアプリを作り上げた話も共有します。これこそが、AIを正しく導く方法を理解したときのvibe codingの可能性であり、現実でもあります。

議論全体を通して、Mikeは一貫して核心テーマに立ち返ります。それは、コンテキストこそがすべてだということです。コンテキストのないAIは、ありきたりで役に立たない回答しか返しません。実際のアカウントデータ、ビジネス目標、戦略的制約を与えられたAIは、正真正銘の思考パートナーになります。重要なのは、使うツールそのものではありません。AIに何ができて何ができないのかを理解し、人間が適切な場所に入るワークフローを設計することです。

AIに関して、懐疑より好奇心が勝る理由

MikeのAIへの向き合い方は、懐疑ではなく好奇心から始まります。GPT-4が登場したとき、彼はすでに週末にメンターと一緒にコードを学び直しており、なぜ物事がそのように動くのかについて延々と質問していました。すると突然、その問いにほとんど即座に答えが返ってくるようになったのです。それが何かを解き放ちました。

Mikeはこう補足しています。「私はちょうど4年か5年前に、たぶんコードを学び直したところでした。週末に話をするコーディングのメンターがいて、そこに突然GPT-4が登場したんです。すると、そのレベルの好奇心に対して、私の質問のほとんどすべてに即座に答えてくれるようになったんです。」

MikeにとってAIは、人間の思考の代替ではなく、摩擦を取り除くためのツールです。GPT-4があれば、開発者とのやり取りや何時間もの手作業が、今では数分で済みます。ただし、それは何を作りたいのか、そしてなぜそれが重要なのかを理解している場合に限ります。

彼はAIを、電気が普及したときのような大きな変化の一部だと見ています。Andrew Ngは何年も前に、AIは電気のようなものになると予測していました。つまり、あらゆるものに組み込まれ、普遍的でありながら、必ずしも目に見えるわけではないということです。Mikeは、まさに今それが起きていると考えています。課題は、多くの人がクライアントワークで110%の状態、つまり限界まで走り続けており、一歩引いて何が可能かを考える時間がないことです。

そこでMikeは自分の役割を位置づけています。彼は人々をソフトウェア開発者にしようとしているのではありません。開発者にならずに何を作れるのか、そしてプロとしてコードを書く人に任せるべきタイミングはいつなのかを示そうとしているのです。

彼が提唱するマインドセットの転換はシンプルです。AIを魔法だと考えるのをやめ、非常に文字通りのアシスタントだと考えること。AIは、あなたが指示したことをそのまま実行します。意図したことではありません。出力が間違っているなら、それは指示が不明確だったか、不完全だったか、あるいは重要なコンテキストが欠けていたからです。その捉え方を変えるだけで、すべてが変わります。

vibe codingとは実際に何を意味するのか

vibe codingとは、要するにAIと会話しながら、コードをすべて書いてもらうことです。Mikeはこれを、欲しいものを言葉で説明し、AIと反復しながら動くまで作り上げるソフトウェア構築だと説明します。

Mikeはこう説明します。「vibe codingが一つのものとして認識されるようになりました。あれはいつでしたっけ、6か月前か12か月前くらい？ どうやら私はここ2〜3年ずっとそれをやっていたみたいなんです。つまりvibe codingです。要するに、文字通りAIと話しているんです。私は一日中それと話していて、すると向こうがいろいろやってくれる。私はコードを一行も書いていません。」

この名前は、欲しいものの「vibe」、つまり雰囲気、機能、目的を伝えれば、AIがそれを現実にする方法を見つけてくれる、という考え方に由来します。構文やライブラリ、フレームワークを知る必要はありません。解決したい問題を理解していれば十分です。

Mikeはこれを、昔のやり方と対比して語りました。20年前のソフトウェア開発はウォーターフォール型で、プロダクトマネージャーが仕様書を書き、アーキテクトがシステムを設計し、開発者が実装し、6〜12週間後、あるいは現実的には30週間後にようやくアルファ版をテストできる、という流れでした。フィードバックは同じ遅いサイクルを通って戻っていきました。

Mikeはこう付け加えます。「そのプロセス全体は完全になくなりました。今では新しいソフトウェアのおかげで、本当に速く、本当に対話的になっています。vibe codeなら、そういうことは数分や数時間で何でもできます。」

しかし、変わったのはスピードだけではありません。開発のループ全体が変わったのです。今では何かを作って、動くかどうかを確認し、その場で調整し、同じ午後に作り直すことができます。AIは、コードの書き方は知っているけれど、何を作るべきか、なぜそれが必要なのかについては継続的な指示を必要とする、非常に速く、非常に文字通りのインターンのように機能します。

Mikeは、プロの開発者でさえこのモデルに移行しつつあると指摘しました。すべての行を手で書く代わりに、彼らはオーケストラの指揮者のようになり、望む成果を説明し、実装の詳細はAIに任せるようになっているのです。

Mikeはそれを見事に表現しました。「あなたはオーケストラの指揮者にならなければなりません。達成したいことが何なのかを理解し、その目標をAIに説明するのです。やり方ではありません。AIはやり方を知っています。あなたが説明すべきなのは何を、なぜなのかであって、あとは任せればいいんです。」

マーケターにとっての実用的な利点は、開発チームを待ったり、カスタムソフトウェアに費用を払ったりせずに、自分のワークフローにぴったり合ったツールを作れることです。

予算ペーシング計算機が必要ですか？ 作ればいいのです。入札変更の前後で2つの検索語句セットを比較したいですか？ 作ればいいのです。もはや障壁は技術力ではありません。本当に必要なものをどれだけ明確にできるかです。

vibe codingで作られた実際のAIツール: PMax script、8020 Agent、そしてAIエキスパートの評議会

Mikeの最もよく知られたvibe-codedツールは、何千人もの広告主が使っているPMax scriptです。しかし彼の歩みは、もっとシンプルなものから始まりました。それがProfit Curveです。

Mikeはこう語ります。「私はこのツールをずっと触っていました。覚えているのは2018年です。というのも、2018年にTraffic and ConversionでRalphが私にインタビューしてくれたのを覚えているからです。Profit Curveというツールで、Google Sheetの中に入れて使っていたものなんですが、私は気に入っていたのに、チームの多くは存在すら知らなかったんです。」

Profit Curveは、今月いくら使うべきか、という一つの問いに答えるために設計されていました。扱いにくく、説明しづらく、Google Sheetの中にありました。しかし機能していたのです。そのツールが、やがて彼にもっと大きな発想をもたらしました。これが作れるなら、他に何が作れるのか、と。

約1年半前、Mikeは8020 Agentを作りました。これはGoogle Adsデータをさまざまな方法で確認できる無料ツールです。この名前は現実を反映しています。つまり、必要なことの80〜90%はこなせるが、洗練されておらず、本番運用向けではないということです。

さらに最近では、8020 Brainを構築しました。ここからが面白いところです。このツールは、Frederick Vallaeysのような人々や、Seth Godin、Rory Sutherlandのようなビジネス思考の持ち主を含むPPCエキスパートの評議会をシミュレートし、彼らに質問できるようにします。

「私はClaudeにこう言いました。『いくつか候補はあるんだけど、あなたなら誰を勧める？ 30人選ぶとしたら、誰を勧める？』 もちろん、PPC Influencerで2年連続ナンバーワン。もちろん、あなたの名前が出てきましたし、他の名前もありました。」

Mikeは、公開されている情報をClaudeに読み込ませることでこれを構築しました。ポッドキャストの書き起こし、ブログ記事、Search Engine Landの記事です。さらに、Edward de BonoのSix Thinking Hatsの手法を組み合わせました。これは、リスク、機会、直感、事実、創造性、プロセスといった異なる視点から問題を見ることを強制するものです。

これらのツールに加えて、Mikeはマスターマインドメンバーの一人からの実例も共有しました。スコットランドに住むDavidという70歳の男性で、9か月前までGitHubが何かも知りませんでした。Davidの会社は設置作業を行っており、現場作業員向けのアプリが必要でした。ある夜、寝る前にDavidはClaudeにこう伝えました。「もうすぐ寝るところなんだ。やってほしいことがある。インストーラー向けの完全に機能するアプリを、朝起きたら使える状態にしてほしい。」

翌朝起きてノートパソコンを開くと、そこにはリンクとPDFを備えた動作するアプリがありました。彼がやるべきことは、それをVercelにデプロイしてURLをチームに送ることだけでした。すると、彼らのスマートフォンですぐに動作したのです。

Mikeはこう付け加えます。「本当に2分の『これを作れる？』だったんです。彼はどう聞けばいいかを知っていて、すべてのファイルがそこにあることも分かっていたからです。あなたが話していたあの土台づくり、あのコンテキストのすべてです。」

この話は、vibe codingの可能性と限界の両方を示しています。コンテキストが十分に読み込まれ、要件が明確で、問題がきちんと定義されていれば、AIは一晩で驚くべきものを作れます。しかし、その準備がなければ、役に立つものは何も得られません。

AIを「平均の惑星」から自分専用の惑星へ移す方法

Mikeが繰り返し強調するテーマの一つは、コンテキストのないAIは役に立たないということです。データも、目標の説明も、顧客像も見せずに、コンサルタントにビジネスを改善してくれと頼むようなものです。返ってくるのは、賢そうに聞こえるけれど自分には当てはまらない一般論です。

Mikeは鮮やかな比喩を使います。インターネットで学習したAIは、中央に「平均の惑星」と呼ばれる巨大な惑星がある太陽系のようなものだ、と。

彼はさらにこう述べます。「中央に『平均の惑星』と呼ばれる巨大な惑星があるんです。だって考えてみてください。AIはRedditやTwitterで学習してきたわけですから。あまり良いアイデアではなかったですよね。でも、それはあらゆるものの平均的な寄せ集めのようなものなんです。そして、ちょっとした質問をすると、その平均の惑星から答えが返ってくるんです。」

より良い答えを得るには、AIを平均の惑星から引き離し、その太陽系にある何百万もの他の惑星、つまり具体的で役立つ、ありきたりではない洞察を持つ惑星へと導かなければなりません。そのために必要なのが、制約、コンテキスト、具体性を与えることです。

Fredはこれを、ベクトル空間が実際にどう機能するかになぞらえて補足しました。AIにより多くの制約を与えるということは、要するに検索できる「箱」を狭め、非常に特定の領域へと向けることです。そうすることで、出力ははるかに関連性の高いものになります。なぜなら、AIは平均化されたインターネット全体から引っ張ってくるのではなく、自分の状況に合った狭い範囲から引っ張ってくるからです。

「リクエストやプロンプトをより具体的にすればするほど、AIが応答しなければならない箱を実質的に限定し、その箱の一つの方向へと導くことになります。」

Mikeは実践的なPPCの例を挙げました。AIに「広告を書いて」と頼む代わりに、パリに住む人向けの広告と、ニューヨークに住む人向けの広告を書いてもらうのです。AIは、それぞれのオーディエンスが異なることを理解しており、関心事も話し方も違うと分かっています。その具体性が創造性を新しいレベルへ押し上げ、広告の関連性を高め、品質スコアを向上させ、CPCを下げます。

コンテキストとは、実際のアカウントデータをAIに与えることでもあります。Google Ads scriptやPerformance Maxの分析ツールを作るなら、AIはキャンペーン構造、検索語句、コンバージョン設定を見る必要があります。除外キーワードを提案してほしいなら、たとえそのアルゴリズムが長年の経験で培われた直感に近いものであっても、どうやってそれを選ぶのかという自分の判断基準を理解している必要があります。

Mikeはこう指摘します。「検索語句のリストを見るたびに、あなたの頭の中では何らかのアルゴリズムが動いているんです。それは、何度もやってきたから体に染みついていて自覚していないだけで、でも確かに何かしらのアルゴリズムが頭の中で動いているんです。」

80〜90%ルール: vibe codingが限界に達する場面

vibe codingは強力ですが、魔法の杖ではありません。Mikeは、どこで機能し、どこで機能しないのかを非常に明確にしています。

最も向いているのは、迅速なプロトタイピング、社内ツール、低リスクのアプリケーション、要件の明確化です。アイデアを素早く試すために何かを作る必要があるなら、vibe codingは最適です。チーム専用で、ミスがクライアントの損失につながらないツールを作るなら、vibe codingは有効です。仕様を開発者に渡す前に、本当に必要なものを整理したいなら、vibe codingは問題を考え抜く助けになります。

少なくとも支援なしではうまくいかないのは、本番運用に耐えるソフトウェアです。

Mikeはこう説明します。「私は、迅速なプロトタイピングにはとても良いと思っています… でも、こうしたツールで生成されるソフトウェアは本番運用向けではありません。つまり、達成したかったことを示すには素晴らしいのですが、80〜90%までは到達しても、本当に堅牢ではないんです。信頼性も十分ではありません。すべてのクライアントに必要なレベルまでスケールするようにはできていません。セキュリティも十分ではありません。中に手を加えるのは簡単だからです。」

Mikeは、ライブのクライアントアカウントに触れるもの、つまり入札変更、予算調整、ターゲティング変更を行うものを作るなら、デプロイ前に開発者にコードをレビューしてもらう必要があると強調しました。vibe codingで作られたツールは、スピードと機能性には最適化されていても、セキュリティ、拡張性、エッジケースへの対応には最適化されていないため、高くつくミスを犯す可能性があります。

Fredは、自身が見てきた落とし穴も付け加えました。コードが動かず、AIに修正を頼み続けると、最終的には「Fredがこれを求めているなら、常にこの答えを返す」というif-then文を入れてしまうかもしれない、というのです。AIはあなたを喜ばせようとしているのであって、必ずしも根本問題を正しく解決しようとしているわけではありません。

Mikeはまた、PPCにおけるvibe codingの限界についても語りました。彼は20年間、Google Ads最適化の究極のフローチャートを作ろうとしてきました。インプレッションシェアがXで、キャンペーンタイプがYなら、Zを行う、というようなものです。しかし最後の10%は純粋な直感であり、SOPには書き出せない暗黙知なので、完成させることができませんでした。

AIもその同じ10%に苦戦します。明確でルールベースの作業、たとえば検索語句レポートをダウンロードし、整形し、コンバージョンがゼロで100ドル超の語句をフラグ付けする、といったことは得意です。しかし、あるキーワードが戦略上の理由で3つの異なる広告グループに存在しているかもしれない、というニュアンスを理解するのは、まだ人間の領域です。

ここで両者が示す実践的なアドバイスは、vibe codingを使って、考える助けになるツール、データを整理するツール、反復作業を自動化するツールを作ることです。ただし、コードを開発者にレビューしてもらい、人間による承認ステップを組み込んでいない限り、リスクの高い環境で自律的な意思決定をさせるために使ってはいけません。

AIを意思決定者ではなく、マーケティングアシスタントとして使う

AIに対するMikeの哲学は一貫しています。それは、AIは思考のためのツールであって、判断の代替ではないということです。

Mikeはこう説明します。「AIは思考のためのツールだというのが、最も大きなものの一つだと思います。『思考』という言葉を口にした瞬間、多くの人にとっては仕事を意味します。私は考えるのが好きではありません。ただ物事を終わらせたいだけです。私は考えるのが大好きです。散歩しながらブレインストーミングするのも大好きです。そして今では、そのブレインストーミングをAIと話しながら、これまでならたどり着けなかった会話の領域へと押し広げてもらえるんです。」

彼は具体的なユースケースを挙げました。複数のYouTube動画の書き起こしを集めてClaudeに入れ、その内容に基づいてアイデアをつなぎ、解決策を提案してもらうというものです。完璧ではありません。盲目的に実行できる最終回答をくれるわけではありません。しかし、問題をより速く、そして自分だけでは思いつかなかった方向から考える助けになります。

FredはこれをClay Bavorの指摘になぞらえました。AIが失敗するとき、その原因はほとんどの場合モデルの質ではなく、十分なコンテキストで土台を作らなかったか、明確な指示を与えなかったかのどちらかだ、というものです。

Mikeもこれに同意し、その考えを広げました。AIは、たとえ頼んだ内容が筋の通らないものであっても、あなたが求めたことを実行しようと非常に努力します。正しいことをすることよりも、あなたを満足させることに関心があるのです。

だからこそ、「まずAIに聞く」戦略が非常にうまく機能します。検索語句の確認、入札調整、パフォーマンス低下の分析など、どんな作業でも始める前に、まずAIと短く会話してみるのです。データのスクリーンショットを見せ、クライアントから何を求められたのかを説明し、「これをどう考えるべき？」と尋ねます。

すると、すでに分かっていることを確認するだけかもしれません。それでも構いません。しかし多くの場合、「これについて考えましたか？」「この理由を確認しましたか？」「このキーワードは戦略上の理由でアカウントに3回入っている可能性はありませんか？」と返してくれます。

最初の数回は時間がかかります。しかし習慣になり、プロンプトを洗練させていくと、以前は30分かかっていたことが10分で済み、しかもより丁寧に考えられるようになります。

より良い質問が、より良い出力を生む理由

対談を通して、Mikeは一つの考えに何度も立ち返っていました。それは、出力の質は入力の質に依存するということです。ツールそのものよりも、どう使うかのほうがはるかに重要なのです。

Mikeはこう述べます。「スキルとして重要なのは、より良い質問をすることだと思います。AIがどんどん賢く、どんどん速く、どんどん安くなっていくほど、答えはより良く、より速く、より安くなります。私たちがより良い質問をしなければなりません。」

Mikeは、コーチングセッションの一つから例を共有しました。あるクライアント、つまりパーソナルトレーニングジムを経営する事業主が、ChatGPTを使って広告見出しを書いていました。見出しは技術的には問題ありませんでした。文法的にも正しく、前向きでした。しかし、完全に一般的だったのです。

Mikeはこう述べます。「私は彼女にこう言いました。『文字通り、世界中のどんなパーソナルトレーニングジムでも、この見出しをそのまま使えます。だからこそ、あなたにとって正しい見出しではないんです。』」

問題はChatGPTではなく、プロンプトでした。クライアントは単にパーソナルトレーニングに関する見出しを求めただけだったのです。だからChatGPTは、これまで書かれたすべてのパーソナルトレーニング見出しの平均を返したにすぎません。より良い見出しを得るには、そのジムの独自性、顧客レビュー、ランディングページ、競合調査から得た洞察をAIに与える必要がありました。

これこそが、有用なAI出力とありきたりなゴミを分けるものです。具体性、制約、そしてコンテキストです。

Mikeはまた、AIは適切に設定すれば、しばしば明確化のための質問をする方法を知っているとも指摘しました。

“Google Ads scriptsを生成するためにLLMを使うなら、まさにそういう使い方が一番好きなんです。まず、要件についてたくさん質問する必要があるとLLMに納得させることですね。というのも、私たちはたいてい要件を把握していないからです。何を求めているのか、正確には分からないんです」とMikeは語った。

AIが質問を始めると、これまで考えていなかった例外ケースや細かな点まで考えざるを得なくなります。次にAIは擬似コードを生成します。つまり、これから何を作るのかを明確かつ具体的に定義するわけです。それがそのまま仕様書になり、開発者に渡すこともできますし、AIと反復しながら動くものができるまで詰めていくための土台にもなります。

Fredは、このプロセスは最終的に開発者へ引き継ぐ場合でも価値があると付け加えた。まず vibe coding を通すことで、存在すら知らなかった複雑さの層が見えてくる。たとえば「シンプル」なキーワードツールでも、既存キーワード、ターゲティングの重複、予算配分、広告グループの構成まで考慮しなければならなくなる。そうしたことを、ウォーターフォール型開発の36か月後に発見するより、数回の vibe coding セッションで見つけられるほうがはるかに良い。

過小評価されているスキル: 実際のビジネスを理解すること

Fredが、今の有料広告で過小評価されているスキルは何かと尋ねると、Mikeはビジネススキルだと答えた。

Mikeはこう説明した。「ビジネススキル、ビジネスの文脈ですね。WebSavvyで私がずっと頭の片隅に置いていたのは、McKinseyを買えない中小企業向けにMcKinseyを作ることだったと思います」

彼の言いたかったのは、Google Ads の技術的知識はもはや最低条件だということだ。自動化も、ツールも、プラットフォームも、誰もが同じものにアクセスできる。差がつくのは、クライアントのビジネスを深く理解し、なぜその依頼をしているのか、本当に必要としているものは何か、そして他にどう支援できるかを見極められるかどうかだ。

Google Ads で大きな成果の多くは、アカウントの外側で起きる。ランディングページ、オファー、電話対応、営業プロセスだ。マーケティング、広告、さまざまなチャネル、そしてクライアント全体の事業戦略について理解を深めることは、入札を手動でうまく設定できることよりも、はるかに価値がある。

Mikeはこうまとめた。

“AIがどんどん賢くなっていくほど、答えはより良く、より速く、より安くなる。だからこそ、私たちはもっと良い質問をしなければならないと思うんです。”

ビジネススキルに加えて、Mikeは仕組みを理解することの重要性も強調した。開発者になるためではなく、何か壊れたときに選択肢を持てるようにするためだ。

“最近のGoogle Ads実務者の中には、AIファーストの世界で育ってきた人たちがいますよね。分かりますか？ 彼らは完全一致を触らない。手動入札も触らない。自動化に全振りしている。私はそれが大好きです。それが悪いと言っているわけではありません。でも問題は、それが実際に内部で何を意味しているのかを知らないことなんです” とMikeは語った。

Mikeが最後に挙げたスキルは反復だ。ホワイトボードの前に座って、すべてを計画しようとしないこと。それは昔ながらのウォーターフォール方式だ。代わりに、小さく作って、何が起きるかを見て、調整し、前に進み続ける。今のツールは十分に速いので、最初に全部計画するより、まず作って反復するほうが実際には速い。

“今のAIで最悪なのは、ホワイトボードの前に座って、すべてを計画しようとすることだと思います。『これをこう使う』と最初から決め打ちするのは、まだ自分が何を知らないのか分かっていないからなんです” とMikeは付け加えた。

プロジェクトをまたいで再利用できる Lego blocks の作り方

vibe coding の課題のひとつは、単発のプロジェクトになりがちなことだ。特定のクライアントやキャンペーンには機能するものを作れても、別の状況にそのまま転用しにくい。イタリアでカンファレンスを運営している Gabriele Benedetti が、こうした罠を避けるにはどうすればいいのかをMikeに尋ねた。

Mikeの答えは率直だった。自分も同じ失敗をしてきたという。「Gabrieleがやったのとまったく同じことを私もやってきました。つまり、何かを作って、それは特定の用途では一度は動く。でも本質的にはあまり再利用性がない。別の場所で使うには、全部を分解し直さなければならないんです」

彼の解決策は、スキルという考え方にある。つまり、プロンプト、いくつかの例、そして少しのコードを組み合わせた、小さく再利用可能なパッケージだ。Claude Code では、こうしたものをモジュール化された部品として作成し、さまざまなプロジェクトでつなぎ合わせることができる。

ただしMikeは、少し意外な見方も示した。そこまで重要ではないというのだ。「一方で、こういうものを作ったとしても、それが一つのやり方でしか動かなくても、実はそこまで問題ではないんです。今はとても速いので、『これを見て。どう作ったか見て。じゃあ今度はこっちのために作って。これは違う。これも違う』と伝えればいい。コンテキスト、制約、好み、ガイドライン、そういったものを全部渡して、もう一度作り直してもらう。そうすると、たぶん新しいものを作るのに2分くらいしかかからないでしょう」とMikeは説明した。

とはいえ、再利用性を重視したいなら、Mikeはホワイトボードにワークフローを箱で描き出すことを勧めた。各ボックスが1つのステップになる。ここからデータを取る、これをクレンジングする、これでフィルタする、これを計算する、あれを出力する。そうした箱が Lego blocks になる。そしてAIには、「将来、分岐させて似ているけれど少し違うものを作りやすい形で実装して」と伝える。

Fredは、オンデマンドソフトウェアの時代には、全員向けの汎用ツールを1つ作る必要はないと付け加えた。1つの業界向けにツールを作り、その違いを説明することで別の業界向けに適応させればいい。かつてそのレベルのカスタマイズには SaaS レベルの計画が必要だったが、今ではほとんど手間がかからない。

vibe coding は、始めるとやみつきになるのはなぜか

MikeもFredも、vibe coding には一度体験するとやめられなくなるような中毒性があると認めた。

Fredはこう言った。「深夜0時を過ぎても vibe coding をしていた夜が何度あったか、数え切れません。Optmyzr には大きなエンジニアリングチームがあるので、最近はあまりやっていなかったんですが。でも楽しいんです。やみつきになります。生産的でもあります」

Mikeも同意した。いちばん難しいのは作ることではなく、やめることだ。

彼は、今では日常になっているパターンを説明した。応答に数分かかるので、3つか4つのAIを並列で走らせる。1年前なら、作業を始めさせてから、待っている間に YouTube を見たり、アメリカンフットボールのハイライトを見たりしていた。今では、全部2分以内に終わる。

その速さが奇妙な問題を生む。機会が無限にあるように感じるのだ。以前は「面白いアイデアだけど時間がない」で終わっていたものが、今では「なんで今やらないの？」になる。Mikeはこれを、自分の人生で最もワクワクすると同時に、最もストレスの多い時期だと表現した。

Fredもこれに共感した。可能性の空間は、ほぼ無限に広がった。何年も Trello ボードに置きっぱなしだったアイデアが、突然すべて実現可能に思えてくる。それは高揚感がある一方で、圧倒される感覚もある。なぜなら、今や制約は能力ではなく、何が本当に重要かを決めることだからだ。

「これを作るべきだ」と「完成した」の間のギャップは、数時間か数分にまで縮まった。ものを作るのが好きな人にとって、そしてMikeもFredも明らかにそうだが、それは非常に魅力的だ。

Mikeが指摘した危険は、集中力を失うことだ。ボタンの色を20分かけて調整するような寄り道に入り込み、本当に重要なコア機能に取り組まなくなるのは簡単だ。

彼のアドバイスは？ 紙に優先順位付きのリストを作ること。まず大きなものに集中すること。見た目の細部は後回しにすること。そうしないと、重要ではない洗練された機能ばかりをたくさん作って、本当に大事なコア機能を放置することになる。

考えすぎずに、まず何かを作れというMikeのメッセージ

対談の終盤、Mikeのマーケター向けアドバイスは、いくつかの基本原則に集約された。

原則 #1: とにかく始める

考えすぎないこと。すべてを計画しようとしないこと。小さく作って、何が起きるかを見ること。

“私はいつも人に懇願しているんです。何を作りたいのか正確には分からないのは分かっています。進む方向の大まかなイメージがあればいい。まずはバージョン1を作ってください。まずは何らかの proof of concept、minimum viable なものを作って、そこからデータを取って、そこに入れてみるだけでいいんです” とMikeは語った。

Mikeは、vibe coding が怖く見えるのは最初の5分か10分だけだと強調した。UI がひどいオタクたちによって作られているので、最初はとっつきにくく見える。でも本質的には、ただのチャットボットだ。話しかけると何かを作ってくれる。動くか確認して、反復する。それだけだ。

原則 #2: AIに完璧を期待しない

Mikeはこう説明した。「いつも言っているのは、人工的に知能を持っているということを忘れないでほしい、ということです。私たちはつい『知能が高い』という部分ばかりに注目して、『人工的』な部分を忘れてしまうんです」

AIは、あなたが意図したことではなく、あなたが指示したことをそのまま実行する。うまくいかないときに問うべきなのは、「なぜAIはこんなに愚かなのか？」ではない。問うべきは、「私は何を伝えたから、こうなったのか？」だ。

原則 #3: 信頼しつつ検証する

Mikeは自分を「信頼しつつ検証する」タイプだと表現した。自動化には、しっかりしたコンバージョントラッキング、明確な入札戦略、適切なキャンペーン構成など、明確な指示を与える。そのうえでレポートを確認する。実際に何をしているのかを見る。望んだ通りでなければ、指示を磨いてギャップを埋める。

原則 #4: 人間をループに残す

クライアントアカウントに触れるツール、入札を調整するスクリプト、予算を変更する自動化など、リスクの高いものについては、必ず開発者にコードレビューをしてもらうこと。vibe coding は社内ツール、低リスクのプロトタイプ、そして思考のパートナーとして使うべきだ。しかし、人間の監督なしに自律システムを本番環境へ投入してはいけない。

原則 #5: コントロールからガイダンスへの移行を受け入れる

細部まで全部を管理する時代は終わった。消費者行動は変わった。SERPs も変わった。AI も変わった。新しい役割は、適切なデータ、制約、目標を与えて賢いシステムを導き、その結果を検証して調整することだ。

Mikeの最後のメッセージはシンプルだった。何かを作れ。小さなツールから始めろ。Google Ads scripts のガイド付き入門として、8020agent の scary challenge を試してみろ。Claude を開いて、動く snake game を作らせて、仕組みを見てみろ。PPC 関連だけでなく、楽しいものを作って、プロセスに慣れろ。

“2年前のクリスマスに、Asteroids を30分で作ったんです。娘が本当に大好きな、完全に動く Asteroids のゲームをね。『またあのゲームやろうよ、パパ？』って言うんですよ。Google Ads の話を忘れないでくださいね。楽しいものを作るんです。でも、とにかく作る。何ができるのか、ただ見てみるんです” とMikeは付け加えた。

ツールはある。能力も本物だ。あとは、自分のコンフォートゾーンを抜け出して試す気があるかどうかだけだ。

Episode Transcript

Frederick Vallaeys: こんにちは。PPC Town Hall の別のエピソードへようこそ。私は Fred Vallaeys です。この番組のホストを務めています。Optmyzr の CEO 兼共同創業者でもあります。Optmyzr は PPC 管理ツールです。今回のゲストは再登場ですが、しばらく話していなかった Mike Rhodes です。PPC の世界で多くのことをしてきた人物ですが、現在は Ads to AI を運営しており、AI を使った vibe-coded ツールの開発に非常に積極的です。多くの人が使っている PMax script でもよく知られています。なので、Mike を番組に迎えて、AI が彼の生活をどう楽にしているのか、そして私たち全員がそこから何を学べるのかを話せるのをとても楽しみにしています。AI に懐疑的な人はたくさんいますが、Mike は間違いなく、それを最大限に活用している人の一人だと思います。では、彼から何を学べるのか見ていきましょう。では、このエピソードを始めましょう。Mike、番組に来てくれてありがとう。

Mike Rhodes: また招いてくれてありがとう。ここに来られてうれしいです。こうしてまた話せてうれしいです。

Frederick Vallaeys: ええ。前回お話ししてから、最近何をしていたのか少し教えてください。それと、初めて会う人のために、Mike Rhodes とはどんな人なのかもお願いします。

Mike Rhodes: いやはや。私の人生の17年間、ここオーストラリアでエージェンシーを立ち上げて運営していました。とても楽しかったです。その後、いくつかのことが重なりました。ひとつは、娘を小学校まで歩いて送れる月曜日が134回しか残っていないと気づいたことです。私たちは毎週カウントダウンしています。日によっては2日あることもありますが、少なくとも毎週月曜日には、今は40回まで減っています。

でも、その気づきと、AIでこれから何が起こるかを見て、エージェンシーの買収オファーを受けました。それで2年半ほど前にそれを受け入れ、またしても信じられないほど幸運でした。まさに適切な場所、適切なタイミングでした。そして私は作り続けてきました。その前に、ちょうどコードを学び直していたんです。あなたほどではありませんが、たぶん4年か5年前に、もう一度独学でコードを学びました。

週末に話すコーディングのメンターがいて、そこへ突然 GPT-4 が登場したんです。すると、そのレベルの好奇心が、ほとんどすべての質問に即座に答えてもらえるようになった。どうやるのか？ なぜこのやり方なのか？ 別のやり方はあるのか？ それがきっかけで、いろいろ試すようになりました。

私はずっと前から遊んでいたツールがあって、2018年だったと思います。Traffic and Conversion で Ralph が私にインタビューしてくれたのを覚えているので、2018年だと分かるんです。そのツールは Profit Curve と呼ばれていて、Google Sheet の中にあったものなんですが、私はとても気に入っていました。でもチームの多くは、その存在すら知りませんでした。ほかの人にとっては使いにくすぎたり、クライアントに説明しにくすぎたりしたんです。これは、今月いくら使うべきかという問題を解決するために作られたものでした。かなり長い答えになっていますが、短い質問に対してね。

でも私はそのツールを作り上げて、ああ、という瞬間がありました。当時はかなり手作業でやっていたんです。これは vibe coding が存在する前の話です。でもそれがきっかけで、じゃあ何が作れるだろう？ と思うようになりました。それで約1年半前に、このツールを作りました。今も動いていますし、無料です。8020 Agent という名前です。Optmyzr のようなものがやることの一部しかできません。

でも、データを違った面白い見方で見られるようにしてくれます。便利なツールになり得ます。時々少し扱いにくいので、8020 という名前なんです。洗練されて完成されたものではありません。大部分はできています。そこからさらにいろいろなことへとつながっていきました。すると、人々が「こういうものをどうやって作るの？」と聞き始めました。それで昨年は Build the Agent というコースもやりました。

そして最初のコホートの終わりに、多くの人が「次は？」と言ったんです。これは素晴らしかったけれど、たった8週間だった。もっと手取り足取り導いてほしい、と。私がずっと好きだったのは、4つか5つ先の丘まで見に行って、そこから戻ってきて、見てきたことを報告するだけでなく、役立つ実践的なツールを人に渡すことなんです。

面白いことに、今ではその流れが見えるんです。私はずっとそうしてきました。かなり昔、2016年か2017年だったと思いますが、display grid を作ったり、remarketing tools を作ったり。ずっとその道のりの中でやってきたんです。ただ、その時は気づいていなかっただけです。

それで Ads to AI を作りました。コミュニティですね。AI に関するコンテンツを整理して提供し、ノイズの大半を取り除いて、できるだけ多くのシグナルを届けようとしています。そして、私は常に6か月先を見て丘を越えていくので、8020 Brain のような楽しいものを見つけては、また作ってしまうんです。学ぶのが好きだからです。

でも、学んだことを役立つ形にしない、教えない、何かに変えない、ただ学ぶためだけに学ぶというのは、私にはあまり意味がないと分かりました。だから教える必要がある。共有する必要があるんです。

2004年に Google Ads を見つけたとき、最初にしたのは、知り合い全員にこの素晴らしい Google Ads というものを急いで伝えることでした。あなたが Mountain View のどこかの cubicle で一生懸命働いている間、私は、これはすごいんだとみんなに伝えようとしていたんです。これは Yellow Pages やラジオ広告を止めるようなものだ、これこそが本物だ、と。

そして、人々から「なあ、どういう仕組みかなんてどうでもいいんだ。とにかくやってくれないか？」と言われ続けるのに、1年半くらいかかりました。その言葉を何度も聞いて、ようやくエージェンシーを始めることになったんです。

今回も同じような感じです。私は「これはすごい。すべてを変えるぞ」と言っている。あなたの言う通り、AI に懐疑的な人はたくさんいるし、AI に使うべきでないこともたくさんあります。でも、私たちができるようになる素晴らしいことは本当にたくさんある。人間を置き換えるのではなく、タスクを置き換え、ほかの多くのタスクを助けてくれるんです。

私はただ、ずっと好奇心旺盛だっただけです。いやあ、好奇心旺盛な学習者にとって、こんなに良い時代はありません。あらゆる質問に答えが得られて、しかも物を作れるんです。これも私がずっとやってきたことです。Lego blocks、模型飛行機。私はずっと何かを作るのが好きでした。そして今では、アイデアから構築、そしてインパクトまで、時には10分くらいで行けてしまう。ばかげているくらいです。本当に楽しいです。

Frederick Vallaeys: かなりすごいですよね。今のあなたは、私と同じくらい、ものをすばやく作れることにワクワクしているように見えます。でも、ひとつ興味深い点を言いましたね。ひとつの丘を登っているのに、すでに4つか5つ先の丘を見ている、と。では、そのあたりをもう少し掘り下げてみましょう。今後数か月、数年で私たちが見ていくことになる丘とは何でしょうか？

Mike Rhodes: Andrew Ng がこう言っていたと思うんです。あなたは Google にいたので Andrew を知っていますよね。Andrew Ng は、多くの人が名前を知らないけれど、実は最も賢い人の一人です。Coursera の創設者で、Google に AI を持ち込んだ人物のひとりです。Translate の時代、2010年頃にはもう deep learning をやっていました。彼は2017年に、AI は電気のようになると言いました。つまり、どこにでもあり、あらゆるものに入り込み、至るところに存在するようになる、と。

私は Traffic and Conversion での講演を、彼のその引用から始めました。そして、電気がどのように普及したか、私たちが電気を使うようになるまで何十年もかかったことを話しました。当時も、多くの人が「ああ、これは大きくなるだろう」と思っていたけれど、そのツールをどう使うかは明らかではなかった。今回も非常によく似ていると思います。使い方は本当にたくさんある。特にエンタープライズでは、採用されるまで時間がかかるでしょう。

でも、すべてを変えています。ただ、多くの人は今やっていることを止める時間がないんです。110%で走っていて、限界まで張りつめていて、「クライアントの仕事が山ほどある。納品しなきゃいけない。やり切らなきゃいけない。最新情報について2時間の YouTube 動画を見る時間なんてない」となっている。私はそういうことをするのが好きなんです。外に出てたくさん時間を使って、面白いものを持ち帰るんです。

具体的には何か？ ひとつ大きいのは、AI を思考ツールとして使うことだと思います。もちろん、thinking という言葉を使うと、多くの人にとっては仕事を意味します。「考えるのは好きじゃない。ただ終わらせたいだけだ」と。でも私は考えるのが好きです。散歩しながらブレインストーミングするのが好きなんです。そして今では、そのブレインストームを AI と会話しながら進められる。そうすることで、自分だけではたどり着けなかった会話の領域に押し広げてもらえるし、より速くそこに行けるし、ノイズの中からシグナルを見つけるのを助けてくれる。

その良い例が YouTube です。私は以前、たくさん本を読んでいました。あそこに1000冊くらいあります。ほとんど読んだけれど、全部ではありません。そしてここ2、3年のどこかで気づいたんです。あの多くは、いわば「念のため」の学習だったんだと。ビジネスの本を読むときって、こういう問題が起きたらこの本が解決してくれるかもしれない、という感じですよね。そして18か月後にその問題が起きたとき、Seth Godin が教えてくれた本の内容を少しでも思い出して、実行できるかもしれない、と。

それで私は、より「必要なときに必要な学習」をする方向に移りました。YouTube に行ったり、メールニュースレターや Substack などを読んだりして、今まさにこの具体的な問題がある。じゃあ、その問題への答えを探しに行こう、という感じです。たぶん、私たちの多くがやっていることですよね。

今なら、それを大規模にできるんです。いくつかの YouTube 動画の transcript を集めて、全部 AI に入れて、「これが私の具体的な問題です。この情報のすべてがどう役立つか、一緒に考えてください」と言えるんです。

完璧ではありません。答えを返してくれるわけではないし、よし、じゃあ盲目的にそれをそのままやろう、とはなりません。でも、考えを整理する助けにはなりますし、私がAIの最も大きな用途のひとつとして見ているのは、まさにそこだと思います。今の答えでご質問にちゃんと答えられているかは、少し自信がありません。

Frederick Vallaeys: そうですね。いや、私はそれを、質問を投げかけたりブレインストーミングしたりできる、ビジネスにおける非常に賢いパートナーだと見ています。私もまったく同じように捉えています。最近…どうぞ。

Mike Rhodes: すみません。どうぞ。

Frederick Vallaeys: そう言おうと思ったのは、AIにはものすごい知識があるからです。要するに、これまでに書かれたものをすべて読んでいるわけですよね。それが良いことか悪いことかはまた別の機会にするとして、とにかく膨大な知識が組み込まれている。大事なのは、その中から自分の文脈に合った有用な部分をどう引き出すかです。そして、AIをそうした予想外の領域へどう押し出していくか。Garbage in, garbage out です。

Mike Rhodes: たとえるなら、私はそれを太陽系みたいなものだと思っています。中心には巨大な惑星があって、それを planet average と呼んでいます。だって、現実としてAIは Reddit と Twitter で学習しているわけですから。あまり良いアイデアではなかったですよね。でも、全体の平均を寄せ集めたようなものなんです。で、ちょっとした質問をすると、planet average から答えが返ってくる。私の頭の中にある奇妙な太陽系のイメージでは、そこには何百万もの惑星があるんだと、しっかり押し広げて考える必要があります。

より良いプロンプトを与え、より良いコンテキストを与え、AIを適切にセットアップすることで、その奇妙な宇宙のはるか遠くにある惑星へと押し出し、どの惑星にも答えがあるような答えを引き出せるんです。

そして、どう質問するかによって、AIがどの惑星に行って答えを返すかが決まります。より強く押し、よりうまく誘導し、「あの宇宙の片隅に、すごく良い答えを持ったすごく良い惑星がある」と示して、planet average からの答えではなく、そこへ寄せていく。これが、AIから得られる価値に大きな違いを生みます。

Frederick Vallaeys: そうですね。ベクトル空間を可視化する面白い方法です。人が見る図って、基本的にはそういうものですよね。三次元空間の中に点がたくさんあるように見えるけれど、実際のベクトル空間はそれよりはるかに多次元です。なので、かなり限定的な表現なんです。

でも、あなたが言っていることの本質は、私たちも同じように見ています。依頼やプロンプトをより具体的にするほど、AIが応答しなければならない箱を実質的に狭め、その箱のひとつの方向へと向けることになる。そうすると、はるかに良い答えが得られます。普通は逆に考えがちですよね。人間に対しては、あまり制約をかけすぎたくない、と。たとえばアルベルト・アインシュタインの口調で答えてもらうのは人間には難しいだろう、みたいに。でもAIなら問題ありません。つまり、その惑星、あるいはベクトル空間のその一部に行って、実際にあなたが具体的に求めていた内容に基づいて、ずっと理にかなった答えを返してくれるわけです。

Mike Rhodes: そんなふうに考えたことはなかったですが、私はずっとポジティブな制約の力のファンなんです。アーティストもそう言うでしょうし、ソングライターもそう言うでしょうし、画家もそうです。「絵を描いて」と言われるより、「この非常に具体的なものを、この特定のスタイルで、この大きさで描いて」と言われたほうがいい。そういう制約が、実はアーティストの方向性をうまく導いてくれるんです。だから、私の考え方の中にもその要素があるのかもしれません。

Frederick Vallaeys: ええ、まったくその通りです。では、具体的な PPC の例でいうと、こういうことです。「ねえ、今新しい広告やクリエイティブ素材を書いているんだけど、誰に向けて書いているの？」と。私たちはしばしば平均値で考えてしまいます。まずキーワードから始めて、すべてがキーワード中心になりますよね。じゃあ、これを売るなら、広告にこれを入れよう、という具合に。

でも今は、こうした知識をすべて持ったクリエイティブパートナーがいるわけですから、パリに住んでいる人向けに広告を書いてみるとか、ニューヨークに住んでいる人向けに書いてみるとか、そういう発想ができるはずです。彼らが気にすることは違いますし、話題にすることも違う。LLM はそれを理解しているので、創造性を新しいレベルへ押し上げてくれます。その結果、広告を見る人にとってより関連性の高いものになり、品質スコアが上がり、ひいては CPC が安くなる。結局、Google Ads の仕組みの基本に立ち返るわけです。

Mike Rhodes: 基本は変わりません。でも、私たちは時々、自分の小さな殻から抜け出すのが難しいんですよね。AI が出してきたアイデアを見て、「ああ、くだらない。そんなのうまくいかない」と思って使わないこともある。でも、たまにはそのうちのひとつを試してみたくなることもあります。

ただ、22歳でパリに住んでいる女性の頭の中に入るのは、私には本当に難しいんです。何を考えているのか、正直わからない。でも、そういう意味では、単に材料が増えるだけなんですよね。アイデアが増える。使う必要はありませんが、そうした思考のきっかけが、別の惑星や別の場所へあなたを押し出し、物事を別の角度から見るよう促してくれることが多い。そして、その視点の変化が、あなたをより良いマーケター、率直に言えばより良いビジネスパーソンにしてくれるんです。

Frederick Vallaeys: ええ。では、この地球上にいる多くの賢い人たちを活用する、という話に戻りましょう。あなたは最近、LinkedIn でかなり反響のあったツールを作りましたよね。しかも私は幸運にも、そのツールに入っている人のひとりです。要するに、専門家の評議会を作ったわけですよね。このツールが何なのか、そして今話していたこととどうつながるのか、少し教えてください。

Mike Rhodes: それは、以前話していた YouTube の文字起こしの件に少し戻るんですが、ポッドキャストを聴いたり YouTube を見たりすることがどんどん増えていて、特に歩いているときなんかは、内容が本当に濃いんです。情報量がすごい。Rory Sutherland の素晴らしいポッドキャストを聴いていたんですが、たぶん彼の著書 Alchemy も読まれたことがあるでしょう。素晴らしい本ですが、とにかく中身がすごく濃いんです。

少し立ち止まる必要がありました。まるで、ああ、今でも Moleskine を持って歩き回っていたらいいのに、と思うような感じです。今はほとんど持ち歩かないんですが、そうやってアイデアを書き留めたいんですよね。で、いくつかメモを取り、音声メモも残しました。家に戻ってから動画を掘り出して文字起こしを見つけ、それを私が普段使っている AI、Claude に入れて、「これが私が考えていたことなんだけど、これが文字起こし。こういうアイデア同士はどうつながる？ Rory ならこの問題をどう解決すると思う？」と聞いたんです。かなり良かったですよ。

それで、もう一歩進めてみようと思って、「実は、Seth Godin みたいな本当に賢いビジネスパーソンが他にもたくさんいて、同じ質問をしてみたい」と考えました。そこで、彼らに関する情報をいくつか集めて質問してみたんですが、みんな少しずつ違うんですよね。

それで、会話を切り貼りして、「ねえ、Rory はこう言ってたし、Seth はこう言ってた。これを…」みたいなことをやるようになって、ただのコピペ作業でかなりごちゃごちゃしてしまったんです。

そこで、こう思いました。よし、Claude、あなたはこの人たち全員についてたくさん知っているよね。彼らの文章も全部読んでいる。5人が部屋にいると想像してみて。ここに質問がある。彼らなら何て言うと思う？ すると、まあまあではあるんですが、少し散らかっていたんです。

そのとき、25年くらい前に読んだ本を思い出しました。Edward de Bono という、私が思うに地球上でも屈指の思考家が書いた思考ツールで、Six Thinking Hats という本です。彼はこれを、8歳の子どもから88歳の大人まで、あらゆる人に教えてきたんですよね。小学校でも教えてきたし、企業の取締役会でもやってきた。比喩的な帽子、6色の帽子をかぶるようなものです。さっき話していたように、さまざまな視点に強制的に切り替えさせる仕組みです。この件に関するリスクは何か？ 起こりうる良いことは何か？ 自分の直感はどう言っているか？ そうした6つの異なる考え方です。それで、この2つをくっつけたんです。

Six Thinking Hats は本当に優れています。なぜなら、テーブルを囲む全員に発言の機会を与えてくれるからです。私はマネジメント会議などでも使ってきました。静かな人、隅にいる人にもちゃんと声が届くようになるし、たいていはずっと話し続ける男性なんですが、その人が会話を独占して、他の全員が目を丸くして会議を抜け出したくなる、なんてことも防げます。

そこでファシリテーターが、「よし、みんな今から黒い帽子をかぶってください。リスクと、なぜこれがうまくいかないのかを見ていきます」と言うんです。そしてテーブルを回っていくと、全員に発言の機会がある。そんなふうに、私はただ、これらを少しずつ組み合わせていったんです。で、「ああ、これは Google Ads の専門家たちとやったら面白そうだな」と思ったんです。

それで Claude に、「今いくつか候補に考えている人はいるんだけど、あなたなら誰を勧める？ 30人選ぶとしたら、誰を勧める？」と聞きました。もちろん、1位は PPC Influencer、2年連続です。もちろん、あなたの名前と他にもたくさんの名前、それから聞いたことのない名前もいくつか出てきました。私は、この人にはぜひ入ってほしいと言いました。そうして、公開されている情報だけを使って、たくさんのペルソナを作り上げたんです。

私は何も非公開情報は使っていません。たとえば Kirk の素晴らしい本の中身も使っていません。というのも、その本を買っていない人もいるかもしれないし、そういう非公開情報の恩恵を受けるべきではないからです。恩恵を受けたいなら、その本を買う必要があります。でも、世の中に公開されている自由に入手できる情報は使っています。いくつかのポッドキャストの文字起こしや、ブログ記事などですね。そうやってペルソナを作り、それらを全部まとめました。Google Ads 用、マーケティング用、ビジネス用があります。

最初のテストを今でも覚えています。最初のテストで、アイデアをひとつ入れてみたんです。すると返ってきて、「Mike、それは本当に良いアイデアだね」と。私は「よし、来たな」と思いました。でも、今はやるべきじゃない。今はそのタイミングじゃない、と続いたんです。私は「え？ AI が『いや、それは単にお世辞を言っているだけじゃない。何だって？』って言ったのか」と思いました。

でも不思議だったのは、それが私の人生で最も賢い2人の女性、つまり妻と、昔のゼネラルマネージャーの声そのものだったことです。私が代理店をやっていたとき、本当に素晴らしいゼネラルマネージャーがいて、たまに「ビジネス上の妻」と呼んでいたんですが、それはちょっと変ですよね。なので、彼女はゼネラルマネージャーの Zoe、そして妻は Gabby と呼ぶことにしましょう。すると、それはまさにこの2人の本当に賢い人たちが言いそうなことそのものだったんです。Mike、それは本当に良いアイデアだけど、いや、今は違う。そして、その理由まで説明してくれた。私はただ、これはすごいと思いました。

それで、ほかの質問もどんどん投げ始めました。評議会を作り込んでいって、今ではたしか60人くらいの専門家が入っています。Seth Godin、Rory Sutherland。とにかく楽しいんです。それから、Google Ads 用のものを使って小さなツールを作り、アバターも作りました。というのも、私は学んだんですが、あなたもご存じの通り、show don’t tell なんです。AI の中で動かすのは素敵ですが、すべてテキストベースです。だから、ちょっとしたきれいな画像と、簡単なデモを作って、8020 Brain のサイトに載せて、アイデアを視覚的に示しただけなんです。

で、まあ、たいていの人は気に入ってくれています。嫌う人も少しいる。なので、たぶん良いことなんでしょうね。

Frederick Vallaeys: なるほど。いいですね。人が使ってフィードバックをくれているわけですから、それは素晴らしいことです。では、その作り方について少し話しましょう。あなたは教育背景として必ずしも開発者ではないと言っていましたよね。でも、AI 上では非常によく機能していたものの、かなり面倒で手作業だったコンセプトを取り上げた。何度も行ったり来たりして、たくさんのプロンプトをコピペしなければならなかった。

それを今では、誰でも 8020 Brain にサインアップして試せるレベルまで持っていったわけです。つまり、ソフトウェアの一部になっている。では、どうやってコードを書けない状態から、こんなに素晴らしいツールを作るところまで行ったんですか？

Mike Rhodes: もっと大きな船が必要だな。短く言えば Claude Code です。長く言えば、少しずつ積み上げていった、という感じでしょうか。たとえば Profit Curve を作ったときも、1ページで、たくさんのコピペがあって、私はそれらの断片をつなぐ接着剤みたいな役割でした。あっちから HTML と JavaScript、こっちから CSS を持ってきて、それらを全部まとめてページを作っていたんです。

AI のコーディングツールは、コードを学んだことがない人にはとても敷居が高く感じられます。Google Ads scripts については、この2〜3年ずっと教えてきました。Scripts and Sheets Mastery コースもありますし、Agent も作りました。

Ads to AI という名前は、私にとっては橋のようなものなんです。できるだけ多くのフリーランサーや代理店に、「さあ、この橋の向こう側へ行こう」と言いたい。というのも、2〜3年後に Google Ads の運用代行だけを提供していても、十分ではないと思うからです。少数の人にとっては十分かもしれませんが、平均的な仕事しかできていない人にとっては足りない。だから、別のスキル、別の能力が必要なんです。

Google Ads scripts は、その橋の最初の一歩です。そして私は、「よし、しばらくそう言ってきたけど、他のステップは何だろう？ Ads to AI に移るために必要な、他のスキル、能力、メンタルモデルは何だろう？」と考えなければなりませんでした。

そこへ vibe coding が登場したんです。たしか6〜12か月前くらいでしたっけ？ どうやら、私がこの2〜3年やってきたことは vibe coding だったらしいんです。要するに、文字通り AI と会話しているんですよね。私は一日中それと話していて、すると向こうが何かをやってくれる。私はコードを一行も書いていません。

私は、何かがひどくおかしなことになっていないか確認できる程度には知っています。でも、見ようと思えばいくらでも見られます。私はコードを学びたかったんです。だから初期の頃は、AI が書いたものを全部見て、「なんでこうしてるんだろう？」と考えたり、質問したりしていました。でも、今から始めるなら、正直そこまでやる必要はまったくありません。

ちゃんとしたソフトウェア開発者でも、もうコードを見ない人はたくさんいます。部分的には見る人も多いですが、彼らは新しい開発のやり方を模索しているんです。まあ、Google で働いていて本当に実用的なものを作っているような、いわゆる本物の本物の開発者がどうしているかは知りませんが、多くの人は、よりハンズオフにコードを書く方向へ進み、バイオリン奏者ではなくオーケストラの指揮者になろうとしているように見えます。

すべての楽器を学び、あらゆるコーディング言語や細かな部分まで覚える必要はありません。昔は構文が本当に苦手でした。構文なんて全然覚えられなかった。でも今は、オーケストラの指揮者になって、達成したいことが何なのかを理解し、その目標を AI に伝えればいいんです。やり方ではなく、何をしたいのか、なぜそれをしたいのかを説明する。やり方は AI が知っています。あなたは what と why を伝えて、あとは任せればいいんです。

そしてコードの素晴らしいところは、動くか動かないかのどちらかだということです。だから、私たちは Google Ads scripts でこれを始めました。動くか動かないか、ただそれだけです。もし動かなければ、エラーメッセージが出るので、それを AI に戻して「これを直してください」と言えばいい。すると直してくれる。それを3回か4回繰り返せば、もう動くスクリプトができあがるんです。

でも、自動レポートはその橋の最初の一歩にすぎません。そこで次に考えたのは、「じゃあ次は何だ？ AI にその思考を手伝わせるにはどうする？ では、そのすべてをどう自動化する？」ということでした。そうすると、毎週月曜の朝に自動インサイトが届く。よし、次は何だ？

次の段階は、ビジネスの文脈をたくさん追加することです。クライアントについて、目標について、戦略について、追加できる情報が多ければ多いほどいい。さっきあなたが言った通り、制約や好みです。単に「今月の予算は2万ドルです」だけではなく、そうした情報すべてです。持ち込む情報が多いほど、planet average から遠ざけて、本当に面白いものに近づけられるんです。

あとは、ひたすら反復するだけです。今の AI で最悪なのは、ホワイトボードの前に座って、すべてを計画しようとすることだと思います。これをこう使う、と完全に決め打ちしてしまう。でも、まだ自分が何を知らないのかもわかっていないんです。だから、まず始める。予算ペーシングツールみたいな、本当に小さなものを作る。そして反復して、「おお、簡単だったな。次の橋の一歩は何だ？ 次は？」となる。そうやって橋を渡り続け、遊び続けるんです。

また質問にちゃんと答えられているか少し自信がないですが、また話がそれてしまいました。ただ、これができること、そしてそれを助けてくれることが本当に気に入っています。しかも、AI のほうから少し押し返してきて、この道を案内してくれるんです。次のステップは何かと聞くと、「ここには4つの方向があります。どう思いますか？」と返してくる。

Frederick Vallaeys: ええ、質問は「非開発者からどうやってソフトウェアを作るところまで行ったのか？」でした。なので、答えていただけたと思います。とはいえ、いくつかの落とし穴についても気になります。私たちが見てきた落とし穴のひとつは、コードが最初からうまく書かれていなくて失敗したときに、「これが期待される結果なんです。どうか直してください」と AI に言い続けると、最終的には if-then のループを入れてしまって、「Fred が求めているなら、常にこの答えを返せばいい。そうすれば彼は満足するから」となってしまうことです。なので、そこは少し注意が必要です。

もうひとつの課題は、PPC のニュアンスの部分です。たとえば、またこの例を出しすぎかもしれませんが、キーワードを提案するとします。よし、いくつかキーワードがある。でも、これらはアカウント内で重複しているキーワードなのか？ それは単に、ある場所と別の場所で同じテキストがある、というだけではありません。キャンペーンのジオターゲティング、時間帯配信、同じ地域、同じ時間帯も関係します。あるキャンペーンには予算制約があって、実際には本当に競合していない、ということもあります。

つまり、こうしたニュアンスがたくさんあるわけです。そこで私たちにとっての難しさは、柔軟なコードと AI、そしてこうした新しいものを、より決定論的なもの、つまり非常に厳格で固定されたルールとどう組み合わせるかです。そうしたルールは安全な範囲にとどめてくれる一方で、その範囲内でより革新的なことを始められるようにする。うまくいかなかった面白い事例があれば、ぜひ聞いてみたいです。

Mike Rhodes: 毎日ありますよ。ええ。何かがうまく動かないとき、今では4か月前よりはだいぶ減りましたが、うまく動かないと、コードの一部を削除してしまうんです。「これが動いていることを確認するテストを書いて」と頼んだのに、動かなかった。だから、動かなかった部分を削除しました。これで全部のテストが通るようになりました、みたいな。日によっては、本当に本当にバカなインターンみたいなものです。

でも、ニュアンスの話については完全に同意しますし、そこにはある種の野心のレベルがあると思うんです。懐疑派から「AI が何でもやってくれる」までの間に、グラデーションがありますよね。目指すなら、その中間あたりがいいと思います。Google Ads アカウントの中のすべてをやらせようとするのは、いや、それは大惨事のレシピです。

20年近く、私は「if this, then that」の究極のフローチャートを作ろうとしてきました。インプレッションシェアがこれで、このタイプのキャンペーンならこう、というようなものです。でも、どうしても作れなかったんです。私は今までに何万人もの人に Google Ads のやり方を教えてきましたが、究極の、究極のガイドを作ることはできなかったんです。

そして、そこでこれを見つけたんです。ええと、何て言うんでしたっけ？ The Dreyfus method です。Nat Eliason がこれについて素晴らしいブログ記事を書いています。Nat Eliason Dreyfus method で検索してみてください。そこにある2枚の画像が、私の学び方、そして教え方まで含めて、すべてを変えました。これは、初心者から専門家へとどう移行するかという話です。そして、その最後の10%くらいは、本当に直感の領域なんです。フローチャートにはできません。暗黙知なんです。やってみて身につく学習と経験です。

おそらく、AI がその多くを担えるようになる時点は来るでしょう。でも、暗黙知の問題は、それを頭の中から取り出して SOP に落とし込むのが本当に、本当に難しいことです。そして AI には入力が必要です。

もしそれを SOP として書けるなら、多くの代理店は、たとえば VA のような人材を世界のどこかで使って、チェックリストに沿って作業してもらい、検索クエリレポートを作成したり、何かをしてもらったりできます。ここからダウンロードして、この見出しを入れて、列幅を変える。そういうことは、AI にとっては何の問題もありません。

でも、このキーワードがこの地域にある場合のニュアンスや、さっきあなたが言ったあらゆる要素を理解することについては、まだ AI に任せるべきではありません。提案を出させるのはもちろんいいですが、人間がループの中に残る必要があります。最後のその一歩、そしておそらく途中のいくつかの部分も、人間が担う必要があります。私は、AI が広告運用者全員の仕事の98%をやるべきだと言っているわけではありません。でも、100%やらせようとすべきでもない。まずは AI に聞くことはできます。

ひとつ良いヒントがあります。LinkedIn の投稿で、将来必要なスキルのような話題についての質問を見かけました。今すぐできる最善のことのひとつは、作業を始める前に、親しみのある AI と少し話して、「これからこれをやろうと思っています。私はこれをやるつもりで、クライアントからはこれを求められていて、状況はこうです」と伝えることだと思います。場合によっては、少しデータを見せてもいいでしょう。スクリーンショットを撮って入れて、「これをどう考えるべきでしょうか？」と聞くんです。

私の代わりにやって、ではなく、どう考えるべきか？ です。そして、ただ自分がすでに知っていることを返してくるだけかもしれません。それでいいんです。でも多くの場合、「でも、これについては考えましたか？」とか、「あのパフォーマンス低下の理由として、これを探しましたか？」とか、あるいは「このキーワードがアカウントに3回入っているのには理由があるのでは？ 地域が違うとか、入札戦略が違うとか、そういうことかもしれませんよ」と言ってくれるでしょう。

そういう、ちょっとした追加の思考に使うんです。最初の数回はそれをやると2倍時間がかかるので、みんなやりません。「とにかくこれを終わらせないと」となるからです。でも、それを習慣にできれば、ショートカットが見えてきます。ああ、実際にはこうやって、こういう形でまとめて、こうするのを忘れなければ、以前は毎回30分かかっていたことが今では10分で済むんだ、と。時間は節約できる。でも最初にかなりの時間を投資しなければならない。だからこそ難しいんです。

Frederick Vallaeys: そうですね。やはり、思考のパートナーとして使うというあなたの例に戻ります。私の Google 時代の友人のひとり、Clay Bavor は今 Sierra AI を率いています。彼と Bret Taylor は、AI が失敗するとき、それは通常 AI の欠陥が原因ではない、と指摘していました。十分に具体的でなく、必要な仕事をうまくやるためのコンテキストで十分に地に足をつけさせていないことが原因なんです。あなたが言っていることととても近いと思います。

Mike Rhodes: そうですね。まず一緒に考えて、答えるべき質問に答えさせる必要があります。ただ放っておいて勝手にやらせるのではなく。そうすると、あなたがその問題をどう考え、どう解くべきかと一致しない判断をしてしまうかもしれません。だって、ラブラドールの子犬みたいなものですからね。あなたを喜ばせようと本当に、本当に頑張るんです。正しいことをすることよりも、あなたを喜ばせて、頼まれたことをやることのほうに関心があるんです。

だから、やるべきことを頼めば、それをやるために全力を尽くします。でも、そうですね、もしかしたら十分なコンテキストを与えていないのかもしれません。なぜなら、それは全部あなたの頭の中にあるからです。

昨日、ある人と、どうやってネガティブキーワードを選ぶのか、という話をしていました。私はこう思うんです。検索語句のリストを見るたびに、頭の中でアルゴリズムが動いているんですよ。何度もやってきたから、もう体に染みついていて自覚していないだけで、何らかのアルゴリズムが頭の中で動いている。いろいろな要素を考えて比較しているんです。ただ、それをものすごく速く、直感的にやっているから、自分がやっていると気づいていないだけなんです。

でも、そのアルゴリズムを頭の外に出して SOP に書き起こしてみてください。ニュアンスが多すぎて、ほとんど不可能なこともあります。でも最初の80%はできます。8020 です。ちょっとした宣伝ですが。多くの場合、AI を使えば最初の80%は片付きます。そうですね、私はそれに本当に同意します。そういう言い方は今まで聞いたことがなかったですが、いいですね。たいていはモデルの欠陥ではない。モデルの使い方なんです。でも、たいていはコンテキストですね。

Frederick Vallaeys: コンテキストは、基本的にすべてだと思います。Garbage in, garbage out. ですよね。昔、コーディングを学んだときもそうでした。最初に学ぶことでした。Garbage in, garbage out.

Mike Rhodes: その通りです。はい、コンテキストを与えること。つまり、モデルをあなたの真実である現実に地に足をつけさせることです。Google Ads キャンペーンの実際の数値が何なのか、ということがまさにそれです。予算予測を頼んだら、でたらめを作り出してしまう例はみんな見たことがありますよね。「いや、実際に何が起きているかを教えていないのに、どうやってこの仕事をするつもりだったの？」という話です。

今日の日付を伝えるような小さなことでもそうです。たとえば、「今、バラの検索がすごく増えているんだけど、何が起きてるの？」と言ったとします。バレンタインデーが近いことに気づいていないかもしれません。だから、「あと2週間、あるいは4週間でバレンタインデーです」と地に足をつけさせることは、その質問によりよく答える助けになります。そういう grounding が、あなたの質問に対する答えを良くしてくれるんです。

私は頭の中の宇宙の絵に戻るんですが、最初の仕事は、まともな答えがある宇宙の片隅にそれを押し込むことなんです。繰り返しますが、どの惑星にも答えはあります。私は grounding をそう捉えています。要するに事実を与えているだけなんです。Six Thinking Hats でいうところの白い帽子です。まず評議会に事実を与える。

ただ、今は脳などのおかげで、Google Ads アカウントからすべてのデータを引っ張ってきて、キャンペーン構造を見て、それら全部を取り込めるんです。だから、そういう手作業の多くをする必要はありません。もはや、それらのステップの間をつなぐ接着剤になる必要も、必ずしもありません。まずはそこから始める。事実から始めて、それから「よし、今あるのはこれだ」と言うんです。

Frederick Vallaeys: そうですね。grounding という呼び方が、確かに正しいですね。

Mike Rhodes: ええ。とにかく、技術用語としてはそうです。

Frederick Vallaeys: でも、視聴者にとってわかりやすくなるようにしましょう。ありがとう、あなたの惑星の宇宙の話は。では Mike、別の質問に行きましょう。これはイタリアでカンファレンスを運営している Gabriele Benedetti からの質問です。私たちの良き友人ですね。彼は、要素を再利用するのをどううまくやるかを尋ねています。

あなたは非常に人気のある PMax スクリプトを開発しました。そして今、8020 Brain で専門家の評議会を構築しました。Gabriele が言っているのは、彼もこうしたソリューションを作るけれど、しばしばそれが単独で存在してしまい、相互につながらないと感じる、ということです。ひとつのものを別のツールに活かせるような、Lego ブロックのようなシステムに変える良い方法は見つけましたか？

Mike Rhodes: 7、8年前の講演で、いつか AI はたくさんの Lego ブロックになって、私たちは棚に行って Lego ブロックを取ってきて組み合わせるだけになる、と言ったのを覚えています。まだそこまでは行っていません。でも8年後の今は、かなりそこに近づいています。

Gabriele がやったのとまったく同じことを私もやってきました。何かを作るんだけど、特定の用途で一度だけうまく動く。でも、それ以外にはあまり使えない。あるいは、別の場所で使うには全体をバラバラにしなければならない。

どう解決するか？ 私は、最小の個別の有用な単位で考えます。ええと、これを大きな迷路に入らずに、しかもスキルの話をしながら説明するのは難しいんですが、今のところ知っておくべきなのは、Claude Code の用語でいうスキルです。これは AI です。要するに、いくつかのものをまとめたパッケージなんです。プロンプトといくつかの例、場合によっては少しのコードも含まれていて、AI に対して「私はこういうやり方でやってほしい」と伝えるものです。そして、そういうものがいくつかできると、それらをつなげて、Lego ブロックを組み合わせるようにできるんです。

良いニュースは、今の時点で好きなものは何でも作れるということです。思いつく限りの Lego ブロックは、何でも作れます。悪いニュースは、Lego の説明書がないことです。あの、開くと「よし、ステップ7で青いブロックを赤いブロックの上に置いて、ステップ8で窓を…」みたいに書いてあるものはありません。説明書は存在しません。マニュアルはないんです。制限はあなたの創造性と想像力だけです。でも、Lego ブロック自体は AI が作ってくれるので、あとはそれをいろいろな形で組み合わせればいいんです。

ああ、頭の中でいろんな考えが同時に競合していて大変です。ひとつには、これを作ったとしても一方向にしか動かないからといって問題ではないんです。今はもう、「ねえ、これを見て。どうやって作ったか見て。じゃあ、こっちの別のもののためにこれを作って。これは違う。これは違う」と言うのがとても速いからです。繰り返しますが、すべてコンテキスト、制約、好み、ガイドラインなどです。さあ、作り直して。そうすると、たぶん新しいものを作るのに2分くらいしかかかりません。

だから、これを8個の別々の Lego ブロックに分解して、将来に備えてそれらを使えるようにしなきゃ、なんてあまり考えなくてもいいんです。作ったものを指して、「あれと同じものが欲しいけど、これと混ぜて、あれっぽくして」と言えば、作ってくれます。

一方で、それぞれの個別要素を持っておくこと、つまり何が、ええと James Clear 的に言えば atomic habits なのかを考えること。こういう体系的な思考に入る小さな要素です。たぶん、ワークフローとして図に描くんです。Nils がいくつかのスクリプトでやったように、ホワイトボードに箱を実際に描き出すんです。

まずこれをやる。あちらからデータを取ってくる。それからデータをクリーンアップして並べ替える。40,000件の検索語句なんて必要ないからです。必要なのは、10ドル以上使ったものだけです。よし、それで何をする？ 次のステップは？ 次のステップは？ それらが本質的に Lego ブロックなんです。

そして、親しみのある AI と話して、「これを作りたいんだ」と言うんです。未来に再利用しやすい形で作りたい、と AI に伝えてください。まだどうやるかはわからない。次に何を作ることになるかもわからないからです。でも、これを作るときに、将来それを分岐させて、似ているけれど違うものを作りやすくしておいてくれますか、と頼むんです。

今は本当に優秀なので、6か月前のパターンなんて、2年前のことは言うまでもなく、ほとんど関係なくなっています。昨日何かを作っていたんですが、私はたいてい3つか4つの AI を同時に動かしています。よし、君はこれ、君はあれ、みたいな感じで、私はオーケストラの指揮者になろうとしているんです。

12か月前に戻ると、YouTube をかなり見ていました。というのも、そういうものを動かしておいて、その間にアメリカンフットボールのハイライトとか、前から見ようと思っていた YouTube の動画、たとえばクライミングの動画とかを見るんです。すると、ピン、ピン、ピン、全部2分もかからず終わっている。ちょっと待って。まだ第1クォーターも終わってないのに、もう全部終わったの？ もっと仕事を見つけないと。

今は信じられないほど速くて優秀なので、たぶん一番難しいのは、実際には止めることなんです。私がそう感じているのは…

Frederick Vallaeys: 続けて。すみません。

Mike Rhodes: ええ、止めることが一番難しいんです。そして、このポッドキャストでも何度も話してきたことですが、人生で最もエキサイティングな時期であると同時に、最もストレスの多い時期でもあります。なぜなら、機会が無限大に増えたからです。昔なら「まあ、ちょっと面白いけど、時間がない。もっと優先度の高いことに集中しよう」と言っていたようなことが、今では全部違って見えるんです。

今は、さっき言ったように、4つの AI が同時に動いていて、しかもすごく速いから、「これをやるべきか、あれをやるべきか？」となるんです。10年前から考えていたことがある。じゃあ今やればいいじゃないか。そうですね。それもまた少しストレスになりますよね。

Frederick Vallaeys: でも、あなたの例え全体が好きなんです。すべてにスケールする解決策を考えなくていい、という話です。歴史的に、SaaS ソフトウェアは、たくさんの人が使えるものを作ることで、財務的に成り立ってきました。そうしないと請求書が払えないからです。だから、多くの人に使ってもらうには、ある程度一般化して、多くのユースケースに合うようにしなければならなかった。

でも今は、Claude Code や Lovable や Replit や Baseten などでオンデマンドにソフトウェアを作る時代です。そうなると、ひとつの業界向けに作ったものを持ってきて、「ねえ、これがあるけど、今度は別の業界向けにやりたい。もっと関連性が高くなるように、どう変えればいい？」と言えるわけです。そうすると、それがとても簡単になるので、あるレベルではもうビルディングブロックについて考える必要すらなくなるんです。

Mike Rhodes: それについては、ぜひ付け加えたいことがあります。とても、とても重要だからです。私のコミュニティの多くのメンバーは、これをかなり難しいと感じていました。彼らが難しいと感じたのは意外でしたが、昔 Google でチームと一緒にどうコーディングしていたかを考えると、何か月もホワイトボードの前に立って、巨大なウォーターフォール計画を作るんです。すべてが非常に、ええと、アジャイルが登場する前の話です。

たとえば、30年前の Microsoft がどう動いていたかを計画するようなものです。Windows 95 を作るときに、1年か2年先まで全部計画して、「これがこういう見た目になる」と決めて、それからその計画をオタクたちに投げる。すると当然、誰も考えていなかった新しい質問や新しい障害にぶつかるんです。全部を考えることなんてできないからです。そうして作業は予定より長引き、予算も超過する。昔のプロジェクトは、そんなふうに動くことが多かったんです。

それから誰かが agile を発明して、ああ、実は全部を計画する代わりに、次の少し先だけを計画して、それをやりながらたくさん学べばいいんじゃないか、と。学んだら次の部分を計画する。今あるツールを使うなら、圧倒的にそのほうが良い進め方です。とにかく反復することです。

私はいつも人に懇願しています。何を作りたいか正確にはわからないのはわかっています。進む方向の大まかなイメージだけ持ってください。まずは version one を作るんです。とにかく proof of concept、minimum viable でいいから、そこからデータを取ってあそこに入れるところまでやる。そしてそれが動くのを見たら、「ああ、そのデータの小さなチャートを作れますか？」となる。はい、チャートは作れます。ああ、じゃあ今度は、日付範囲を変える小さな機能もつけられる？ それもやりましょう。そうやって、ただ反復、反復、反復するんです。

すると、次のアイデアが出てくるので、いつ止めるかがわからなくなります。キーボードのキーを押しっぱなしにして、親しみのある AI に話しかけるんです。これにあれを少し足して、これも入れて、あ、ピンクにしてくれる？ いいね。次のことを考えている間に、もうそれをやってくれているんです。

Gabby が何度もこう言うんです。「夕飯の時間だよ。ご飯できたよ。」私は「うん、ちょっと待って」と。よし、それやって。それもやって。それもやって。それもやって。あ、あ、あ、ちょっと待って。もう終わったの？ よし、じゃあ次はこれ。とにかく、やることをどんどん増やしていくんです。

私は Trello ボードを持っていて、あなたが言っているようなアイデア、つまり someday maybe の項目や、PMAX スクリプトに追加したいもの、作りたかったもの、クリスマスの間に手をつけられなかったウェブサイトなんかを入れていました。もう十分だ、と思って。Trello ボードのスクリーンショットを撮ったんです。API や MCP なんて調べようともしませんでした。ただ Trello ボードのスクリーンショットを Claude に放り込んで、「この中でどれを最初に作れますか？」と聞いたんです。

すると、「よし、これ、これ、これ、これをやるべきだと思います。理由はこうです。これはもう必要ないと思います。これは実はもうやっていますよね。始めましょうか？」と言ってきたんです。じゃあ、やって。そうしたら、Trello ボードの80〜90%が片付きました。

私のメンバーのひとりがこんな話をしてくれました。これは本当に素晴らしいです。David というメンバーで、8、9、10か月前までは GitHub という言葉すら知らなかったんです。言っても気にしないと思いますが、彼は70代です。素晴らしい人です。昔は WebSavvy のクライアントでした。Savvy Group の最初期のメンバーのひとりでもあります。今は私の mastermind にいて、自分のビジネスでやっていることを見せてくれました。

彼は40年前にその事業を始めました。今は娘さんと義理の息子さんが運営しています。彼はここ6〜8か月、少し引いて、こうしたものをずっと作っていたんです。いわゆる vibe coding ですね。で、先日オフサイトがあって、彼はスコットランドにいるんですが、チームに自分がやってきたことをいくつか見せたんです。するとみんな顔を見合わせて、「よし、もうこれ以外は何もやっちゃダメだ」となったんです。「Google Ads アカウントをいじるのも禁止。現場に出て設置作業をするのも禁止。これだけやって」と。

すると翌日、設置担当の責任者から電話がかかってきて、「昨日見せてくれたことについて考えていたんだけど」と。スコットランド訛りは真似しませんが、「現場のうちの連中向けのアプリを作れると思う？」と言ったんです。

David はまさに「そんなに簡単じゃないんだよ。いろいろ考えないといけないことがあるし…」と言いかけたんですが、まあ、やれるだけやってみるよ、と。そして、その会話を私に送ってくれました。彼は Claude にこう言ったんです。「もうすぐ寝るところです。やってほしいことはこれです。朝起きたら、設置担当者向けの完全に動くアプリができているようにしてほしい。」

というのも、彼は brain を使っていたので、そこに全部のコンテキストが入っていたんです。そこには設置に関する PDF がいくつか転がっていて、それも入っていました。彼はただ「完成したアプリで目を覚ましたい。やって」と言っただけです。翌朝7時に座ったとき、そんなことを頼んだのを忘れていたそうです。コンピュータを開いて、「おや、これは何だ？」となった。すると、リンクと PDF 付きの完全に動くアプリができていて、彼がやるべきことはそれを Vercel に入れてデプロイし、設置担当者に送ることだけだったんです。すると相手は「え、これ？」となった。

しかも、彼の担当者のスマホで初回から全部動いたんです。今ではチーム全体が現場で使えるようになっています。しかも、どう頼めばいいかを彼が知っていて、すべてのファイルがそこにあることもわかっていたので、文字通り2分で「これ作れる？」という話だったんです。あなたが話していた grounding、あらゆるコンテキスト、そのすべてです。私はそれを、AI モデルが真ん中にあって、その周りにこうしたコンテキストが次の層としてぐるっと囲んでいるイメージで捉えています。それが本当に、本当に重要なんです。彼のために一晩で全部作ってしまった。もう信じられないですよ。

ええ。本当にめちゃくちゃ便利なんです。それを受け入れて、すべてをやってくれると期待しなければ。あのニュアンスまではやらない。でも、他のたくさんのことは助けてくれます。昔は、まあ、あなたが言っていたような、あまりに時間がかかるからたぶんやらなかったこと、時間がなくてできなかったことが、今では手の届くところに来るんです。

And some of that stuff is now accessible at scale. 以前は、価値があるからこそ年に1回か2回、上位10%のクライアントにだけ行っていたようなことでも、下位80%のクライアントには時間がなくてできませんでした。今では、それをすべてのクライアントに毎月実施できます。つまり、あまりにも多くの制約、障壁、制限を取り除いてくれるのです。

Frederick Vallaeys: では、デジタルマーケティングに関する私たちの質問の1つに戻しましょう。もちろん、あなたと私がこのテーマに対して共有している興奮はたくさんありますが、もし1つだけ挙げるとしたら、これはSharonの質問ですが、現在の有料広告において過小評価されていると思うスキルで、今後数年で最も大きな違いを生むものは何でしょうか？

Mike Rhodes: 皮肉っぽく答えるなら「考える力」ですが、それはやめておきます。私はビジネススキル、ビジネスの文脈について考えています。WebSavvyで私がずっと頭の片隅に置いていたのは、McKinseyを雇えない中小企業のためのMcKinseyを作ることでした。でもすぐに気づいたのは、本当に優秀な人たちはみんなMcKinseyに採用されていて、私には到底払えない金額を受け取っていたということです。なので、それは結局実現しませんでした。

私たちにとって最良のクライアントは、単なるマーケティング以外のこと、つまり他のビジネス上のことについても相談してくれる、戦略アドバイザーとして私たちを見てくれていたクライアントでした。でも、それはスケールしませんでした。なぜなら、そうしたビジネスの質問に答えられるのは私と数人だけだったからです。一方で、多くの人は「私はGoogle Adsをやるために採用されたんです。Google Adsは分かります。でもビジネスのことは何も分かりません。これが初めての仕事なんです」といった感じでした。そして彼らは私にこういうことを聞いてくるわけです。「助けて？ これを分かる人、誰か助けてくれませんか？」と。うまくスケールしなかったんです。

でも、ビジネスの文脈を理解し、ビジネスについてもっと学ぶことは、学ぶのがこれまでで最も簡単になっています。そしてそれこそが、そう、基礎は今でも非常に重要で、もちろんそれは前提条件です。Google Adsを運用するための基礎は知っていなければなりません。でも、マーケティングについてもっと知ること、広告についてもっと知ること、さまざまなチャネルを理解すること、そしてその上のレベルとして、クライアントをより深く理解すること。なぜ彼らがこれを求めているのか、本当に必要としているものは何なのか、何が起きているのか、そしてビジネスの他の領域でどう支援できるのかを考えることです。

もちろん、それはすべての代理店に当てはまるわけではありませんし、すべてのクライアントに当てはまるわけでもありません。というのも、クライアントの中には「ちょっと待って、私はデジタル広告のためにあなたを雇ったんです。私の戦略について口を出してほしくないんです。そこはちゃんと管理しています。ありがとう、もう結構です」と言う人もいるからです。でも、別のクライアントは、あなたがそこに関心を示してくれること、考えてくれること、助けようとしてくれることをとても喜ぶでしょう。

そして、そうした姿勢がますます差を生むようになると思います。というのも、あなたはこの点について長い間、とても明快に書いてきましたよね。Google Adsアカウントの中には、ますます多くの自動化が入っています。その自動化は誰でも使えます。それは前提条件です。誰もが同じツールを使っています。すべてがある程度同じ地点に収束していくんです。

大きな成果のほとんどはGoogle Adsアカウントの外で起きます。ランディングページであれ、オファーであれ、法律事務所で電話に出る人の対応であれ、何であれ、Google Adsの外にあるんです。そこで得られる成果が最も大きい。だから、その部分をより深く理解することが、将来的にはより大きな差別化要因になると思います。

Frederick Vallaeys: なるほど、納得です。あなたが言ったように、自動化されるものをやる、つまり、検索語句を見て、100ドル使って、コンバージョンなし、みたいなことですよね。なぜそんなことに人件費を払う必要があるのでしょうか？ Optmyzrがそれを自動化するし、スクリプトもそれを自動化します。そういうのは簡単な部分ですよね？

でも、その次に何をするのか？ なぜそれらはコンバージョンしなかったのか？ ランディングページの問題だったのか？ オファーの問題だったのか？ そうですね。単にキーワード選定が悪かっただけなのか？ もしかすると、今はキーワード検索をするのではなくプロンプトを使う時代で、そういうやり方はもう通用しないのかもしれませんよね。だから、そうした問いのほうがずっと重要になります。そしておっしゃる通り、重要なのは考える力と、あなたがもたらす戦略的なパートナーシップであって、最終的な戦術実行ではありません。そこは自動化がやる部分だからです。

Mike Rhodes: では、私の話をもう少し簡潔にまとめて、また15個も話が脱線しないようにすると。スキルは、より良い質問をすることだと思います。AIがどんどん賢く、どんどん賢く、どんどん賢くなっていくにつれて、答えはより良く、より速く、より安くなります。だからこそ、私たちはより良い質問をしなければなりません。

Frederick Vallaeys: いいですね。素晴らしい内容でした、Mike。とても参考になりました。多くの人がすぐに自分のPCに向かって、何か面白いものを作り始めるはずです。もしそうしたら、ぜひコメントに書いてください。ぜひ見て、コメントしたいです。Mike、Ads to AIと8020 Brain以外にも、もちろんLinkedInでつながることもできますよね。他に、皆さんにしてほしいことはありますか？

Mike Rhodes: そうですね、ただ作ってみてほしいです。それが私が皆さんにしてほしいことです。怖がらないでほしい。実際、昨日ある女性と話していたんですが、名前は伏せますけれど、こうしたこと全般について話していて、彼女が「でも、Google Ads scriptsはいまだに怖いんです」と言ったんです。解決策があります。私は実際にそれを my scary challenge と呼んでいます。これは別のサイト、別のURLに載せています。すみません、もっとちゃんとリンクを貼るべきですね。でも、8020agent.com/scary です。14分ほどの小さなチャレンジで、Google Ads scriptsは怖くないと気づけるようになっています。何が可能なのかを見せてくれるんです。

つまり、私たちが話しているこうしたことは全部同じです。そう、Claude Codeは怖そうに見えます。もしあなたがMacを使っていて、しかもすでにClaudeに月100ドル払っているなら、数日前にリリースされたClaude Co-workにアクセスできるようになっています。これは、私たちオタクが触っているあらゆるものの力を使えるようにしつつ、もっととっつきやすくしてくれるものです。

これは間違いなく徐々に広がっていくと思います。より広く利用できるようになるでしょう。大事なのは、怖がる気持ちを乗り越えることです。それは最初の5分か10分だけです。見た目は威圧的ですし、世界最高のUI感覚を持っているわけではないオタクたちが作ったものです。でも心配いりません。基本的にはただのチャットボットです。そして、これがすべての最終形というわけではありません。でも、まずはそこから始めて、より良い質問をして、ただ試してみてください。

あまりにも多くの人が試してみて、「うん、やっぱりクソだった。これが私より blah blah blah をうまくできるわけがない」と言ってしまいます。だからAIのことは全部忘れて、また12か月後にしまっておこう、やっぱり自分が正しかった、もう二度と見なくていい、となるんです。でも、そんなものではありません。もっとたくさんのことができます。

jagged intelligence について新しい話を始めたいわけではないのですが……とにかく、試してみてください。触ってみてください。それが私のお願いです。私のことは気にしなくていいです。もちろん、8020brain.com に来てください。そこでは可能なことの一部を示すデモを見ることができますし、Ads to AI はコミュニティです。

でも、ただ触ってみてください。まず始めてください。Claudeを開いて、「動くsnake gameを作って」と言ってみてください。そして右側でそれが組み上がっていくのを見てください。右側に小さなウィンドウが開くはずです。場合によっては、そのために設定を変える必要があるかもしれません。Claudeに「artifactというものの中で、これが右側に表示されるようにするにはどうすればいい？」と聞いてみてください。「artifactって何？ どうやって表示させるの？」と。そして「ゲームを見せて」と言うんです。お子さんに「好きなゲームは何？」と聞いてみてください。そうですよね？ それを作りましょう。

私たちは2回前のクリスマスに、Asteroidsを30分で作りました。娘が本当に大好きな、完全に動くAsteroidsのゲームです。「またあのゲームやろうよ、お父さん」って感じです。Google Adsの話を忘れないでください。楽しいものを作る。でも、とにかく作るんです。ただ、何ができるのか見てみてください。それが私のお願いです。作り続けてください。

Frederick Vallaeys: 素晴らしいアドバイスです。作り続ける。よし、作り続ける。見続ける。今後のエピソードを知りたいなら、ぜひ私たちのポッドキャストを購読してください。今日のゲストであるMike Rhodesとぜひつながってください。それでは、皆さん、ご視聴ありがとうございました。次回お会いしましょう。