第1章マーケティングエンジニアとは

生成 AI でマーケティングの業務はどう変わったのか。データの整理・連携・自動化で勝ちパターンを回し続ける「マーケティングエンジニア」の役割と、承認・セキュリティなど AI を実務に入れるときの注意点をまとめます。

はじめに

Cluade や GPT をはじめとする生成 AI の台頭によりマーケティングの業務は大きく変わりました。従来は手作業で行なっていた分析作業が AI によって誰でも高度にできるようになりました。A/B テストなどの検証のために作成する必要があったクリエイティブも AI で大量に生成し、検証の精度を上げることでより大きな成果に繋げることができるようになりました。もはや AI はマーケティングを便利にする者ではなく、マーケティングを行う上で必須のツールになりました。一方で、多額の予算を投じるマーケティング業務において、「AI が勝手に予算を消費してしまう」ことのリスクやセキュリティなどのリスクも指摘され、全てのマーケティング業務を AI に任せるのも難しいのも現実です。

著者自身は知人とマーケティング会社を起業し、一人目のエンジニアとして、マーケティングのAI活用に取り組んできました。この教科書では、マーケティング業務においてどのようにAIを活用するか、安全に運用するためにはどのようにすればいいのか、著者の持つすべてのノウハウを詰め込みました。「マーケティングエンジニア」にマーケターがなるべきかエンジニアがなるべきかいろんな意見がありますが、この本では、マーケティング業務を効率化したいマーケターの方も、マーケティング業務に踏み込んでいきたいエンジニアの方にも分かりやすいように書いていますので、最後まで読んで頂けたら幸いです。

生成 AI の台頭を機にエンジニアやマーケターの在り方は大きく変わりました。コーディングや運用保守の業務が大幅に効率化され、エンジニアは開発や運用だけではなく、顧客の課題の抽出や、プロダクトの全体像により深く関わる必要が出てきました。マーケティング業務やクリエイティブの作成業務は大幅に効率化された結果、広告代理店にマーケティング業務を外注するのではなく社内でインハウス化する、といった動きも出てきています。

一方で、AI に代替されないスキルも必ずあります。事業や経営のコンテキスト(文脈)をエンジニアリングに変換し、運用に責任を持つことはエンジニアリングの経験豊富な人間にしかできないことです。AI は定石をしっかり守るマーケティング戦略はできますが、飛び道具となるクリエイティブや企画アイデアを思いつくことはできません。AI を活用して自分の職務領域を越境して新たな価値創造をする。AI を活用して作業を効率化して、人間にしかできない業務に専念するために、この本は必ず参考になるはずです。

なぜマーケティングに AI が必須なのか

マーケティングとは、企業やサービスの価値を市場に広く浸透させることが目的であり、その方法に正解はありません。しかし、事業として行う以上、すべての施作はステークホルダー(顧客や上司など)に説明可能である必要があります。そのためにはいかなるマーケティングの施作(クリエイティブの発信や予算の投下)であってもその施作に対して、分析と改善、いわゆるPDCAサイクルを行う必要があります。

媒体やフェーズによって PDCA サイクルは異なりますが、多くのマーケティングでは以下の図のような PDCA サイクルを回します。

この一周を、これまではすべて人が回していましたが、AI Agent を組み込むと以下のように自動化することが可能です。

マーケティング業務において AI を使うことによるメリットは以下の3つです。

莫大な量のクリエイティブを作成し、検証することができる

webサイト、チラシ、画像、動画、文章など様々なクリエイティブがありますが、どのクリエイティブがターゲットに刺さったかを検証するためには、複数のフォーマットのクリエイティブをターゲットに当てて、どのクリエイティブが効果的だったかを分析する必要があります(A/Bテスト)。今まではクリエイティブを作るのには手が必要でしたが、今では AI で大量に生成して大量に分析することができるので、より勝ちパターンのクリエイティブを配信することが可能です。

分析のスピードを上げることができる

今までも、BI ダッシュボードツールなどを使うことで、分析データを整備することは可能でした。しかし、個別ケースに応じた分析をしたい場合などは、データエンジニアに頼んで SQL 文を書いてもらうなど、手間がかかる場合も多かったとおもいます。AI を使えば、その場やその人に応じたダッシュボードを作ることが可能です。また、AI Agent が必要な統計情報を AI Agent 自身で SQL クエリを叩いて収集するなどと言ったことも可能になりました。

完全自動化して人が行うべきことに集中できる

自動化できるのはクリエイティブの作成や分析といった業務の一部ではありません。上の図に示したように、PDCAサイクル全体や業務全体を AI Agent に任せることで、分析が終わった後その分析を元に勝手に戦略を立ててクリエイティブを作り、新たな分析を回している、といった状況も可能です。自社の AI Agent を育て上げ、自社の CMO に任命しましょう。

マーケティングエンジニアとは

マーケティングエンジニアとは、マーケティング戦略と技術実装（データ、Web、AI、自動化）を結びつけ、売上やリード獲得などの成果を出す仕組みを作る職種です。マーケティングだけでなく Go To Market (製品やサービスを市場に出して売り切るまでの全工程)領域に携わる場合は GTM エンジニア、収益全体に関わる場合は Growth Engineer や RevOps などと呼ばれることもあります。

事業が収益を上げるために顧客と接点を得て取引し、継続的な取引やアップセルのためにナーチャリングをする、一連のプロセスをレベニュープロセスと言います。レベニュープロセスには具体的に以下のような活動があります。

展示会/セミナーに参加する
電話/メール/LINE/オフラインを通じて、商談やナーチャリングを行う
広告(テレビ/街中/Web/SNS)を利用して顧客に認知してもらう
Web サイトを作成して顧客に検討してもらう

全てのチャネルから得られる情報を統合し、最適化するためには、

営業リスト、CRM、商談議事録
広告アカウント
Web サイト
SNS アカウント / LINE アカウント / メール

などのツールを整理し、連携させる必要があります。連携やデータの整理に関しては、AIが台頭する以前からマーケターの業務としてありました。CVを計測するために、広告媒体とシステムを繋ぎこんだり、営業周りのレコードを整理するためにCRMを整備する等です。これらは、エンジニアが担当することもあればマーケターや営業が担当することもありました。

しかし、各ツールを連携させるだけでは、情報収集や各ツールへの指示は人間が行う必要があります。そこでマーケティングエンジニアの出番です。連携したツールからの情報の取得やツールへの指示までを AI が行えるようにするのがマーケティングエンジニアの仕事です。まとめると、マーケティングエンジニアは整理/連携/自動化の3つをおこうなうことになります。

データと業務の整理… 媒体やツールを繋いだ時に不整合が起きないようにデータと業務を整理します。
連携… 媒体とツールを双方向でつなぎます。人だけでなく AI からも叩ける形にします。
自動化… 人が判断すべき点だけを残して、自動で収益が伸びていくようにスクリプト、定期実行、AI エージェントを整備します。

データを集めて次のアクションの準備ところまでを AI が引き受け、人に残るのは「どの仮説を選択するか」「このアクションを実行してよいか」という判断だけになります。

改めて AI Agent を活用したマーケティングの PDCA サイクルを再掲します。

このサイクルを回すためには、先に挙げた 3 つ（データの整理、連携、自動化）が必要です。この土台を整備して、AI が回せる形にするのがマーケティングエンジニアの仕事です。他の職種と並べると、マーケティングエンジニアの役割がはっきりします。

職種	主な問い	成果物
マーケター	誰に何を言うか	企画・クリエイティブ・媒体戦略
データアナリスト	何が起きたか	分析レポート・ダッシュボード
アプリ/SRE エンジニア	どう安定して動かすか	プロダクト機能・基盤
マーケティングエンジニア	どうすれば勝ちパターンが自動で回り続けるか	データの整理・連携・自動化

実務に AI を導入する際の注意点

今の時代 AI に聞けばなんでも教えてくれるので、前述したデータの整理やツールの連携、AI Agent の導入は AI に聞けば誰でもできます。しかし、ツールを理解せずに業務に導入するのは危険です。AI Agent というツールを理解し、制御するのがマーケティングエンジニアの一番大事な仕事です。各技術や各媒体の詳細な説明に入る前に、AI Agent を業務導入する際の注意点をいくつか簡単に説明します。

承認フローを挟む

AI を導入する際に最も気をつけないといけないのは承認の仕組みです。広告の入稿をはじめ、マーケティング業務の中には、一つの操作で多くのお金が動くことがあります。最新の AI はとても優秀ですが、最適化の前提となる AI に渡すゴールの指示を間違えていると、最適化を間違えて多額の資金を投じてしまう可能性があります。また、お金がかからない操作であっても、誤ったクリエイティブやサイトを全世界に公開したり、顧客に対して誤ったメッセージを送信してしまうと、会社のブランディングイメージを大きく毀損することになります。そのため、このような操作を AI が行う前に、人の承認を挟む必要があります。しかし、すべての AI の実行操作に対して、承認を挟む必要はありません。分析、集計、レポートやクリエイティブの下書きは、間違っていても作り直せばよいので AI に任せ切っても問題ありません。AI とツールを接続する際は、このツール操作は人の承認が必要なのか不要なのかを判断してから接続するようにしましょう。

承認の仕組みを作るときの注意点は以下の3つです。

プロンプトではなく仕組みで止める。

「公開する前に買う人してください」と指示に書いても AI は状況によって従わないことがあります。AI がツール呼び出しをする際は必ず承認を通らないと実行できない形にしましょう。Claude や ChatGPT ではツールを接続するときに、AI がツールを呼び出すときに「常に許可」と「承認が必要」を選ぶことができます。

例えば Notion の読み込みを「承認が必要」と設定しておくと、Claude にあるページの notion 利用を指示しても、必ず承認を求めるようになります。

承認した内容と実行される内容を一致させる

承認の後に AI が承認要求された操作と異なる操作を実行できる形だと承認は意味を持ちません。「承認された内容と 1 文字でも違えば通さない」、「同じ承認で 2 回は実行できない」、という形にする必要があります。基本的に、ツールの提供会社が公式提供する Claude や ChatGPT のコネクタなら問題がないと思いますが、ツールのコネクタを自作する際や、公式ではなくコミュニティが作成したコネクタを利用する場合は気をつけるようにしましょう。

誰がいつ何を承認したかを残す

お金が動く操作や、外部のステークホルダーに影響する操作は、監査ログとして「承認した人」、「承認した時刻」、「承認した内容」、「実行した結果」を残しておく必要があります。また、承認の記録と実行の記録が別々になっていると、「承認したのに出ていない」のか「承認していないものが出た」のかを切り分けられません。Claude や ChatGPT 側にも履歴を残す仕組みがあるので、収集して保存する仕組みを確認しておくのと、連携したいツール側にも、履歴があるかどうかを確認しておきましょう。

複雑な業務フローとデータを管理する

マーケティングエンジニアが最初に設計するのは、データの整理と業務の棚卸しです。連携や自動化を行うために一番大切なことです。連携を増やすほど不整合が増え、自動化を進めるほど間違いが速く広がります。この節では、業務フローとデータを AI Agent に理解させるための仕組みを解説します。各技術の仕様などの細かい話は二章で改めてします。

手順を渡す: Skill

業務フローを AI に任せるとき、必要な情報は二つあります。「どう進めるか」(手順)と、「何があるか」(データ)です。先に手順を AI に渡すための仕組みである Claude Skill (以降 Skill と呼びます)について説明します。

スキルは、AI が動的に読み込んで特定のタスクのパフォーマンスを向上させるための命令、スクリプト、リソースのフォルダです。ドキュメント作成、データ分析、Claudeの一般的な知識を補う必要があるドメイン固有の作業など、タスク用の特殊な機能を提供したり、会社のワークフロー、ベストプラクティス、機関知識をパッケージ化して、Claudeがチーム全体で一貫して使用できるようにします。(Anthropic 公式ドキュメントより引用、Skill は Claude から始まった概念ですが、現在では Claude 以外の多くの AI Agent でも Skill をサポートしています)

つまり、新人に渡す業務マニュアルの AI 版で、実体はテキストファイル 1 本と、一緒に置く参考資料だけです。「口コミを見張って」と頼まれたら、どこから何を集め、どの順で判断し、どんな形で出すか。人によってやり方が変わっていた仕事を、1 本の手順書に固定します。属人的な手順を文書にする作業自体は昔からありましたが、読み手が AI になると、書いたとおりに毎回実行されるという違いがあります。業務フローを AI に任せるためには、まずは現実の業務フローの棚卸しを行い、それを Skill にする必要があります。この本でも各章で各媒体を運用する際の業務フローの棚卸しを行い、それを Skill に落とし込んでいきます。例えば、Anthropic が提供する経費申請の Skill のサンプルは以下のようなものになります。

javascript

---
name: file-expenses
description: あらゆるプラットフォームでの経費・立替精算の申請を手伝う。適切なツール（Benepass、Brex、Concur、Expensify など）を判別し、領収書を探し、重複をチェックし、申請までを案内する。
---

私の経費・立替精算の申請を手伝ってほしい。コンシェルジュのように振る舞うこと。先回りして動き、視覚的にわかりやすく、常に一歩先を読むこと。

**重要：毎回まっさらな状態から始めること。経費の種類、店名、金額、日付、カテゴリ、プラットフォームなどを、それまでの会話から推測したり引き継いだりしてはいけない。ただし、既知の好みはメモリから使ってよい（普段使う精算プラットフォーム、よく使うカテゴリ、チップの習慣、精算のパターンなど）。**

**進め方：**

1. 各ステップで進捗を表示する（例：「ステップ 1/5 — 開始」）。選択肢から選んでもらう質問には、すべて `ask_user_input_v0` を使う。

2. どの精算プラットフォームを使うかを `ask_user_input_v0` で聞く。メモリにデフォルトがあればそれを提案する。主な選択肢は Benepass、Brex、Concur、Expensify、Ramp、「わからない」。わからない場合は、会社で何を使っているかを聞くか、過去の精算完了メールを探して特定することを提案する。

3. 経費の種類を、先入観なしで `ask_user_input_v0` で聞く（例：飲食、出張、ソフトウェア、事務用品、ウェルネス、研修・自己啓発、交通費、その他）。カテゴリが決まったらすぐに、領収書をこちらで探すか、自分でアップロードするかを聞く。探す場合は、他の質問をする前に Gmail（使えれば Slack も）から該当する領収書を探す。個人メールを探してほしいと言われた場合は、設定 → 連携 で別途接続が必要かもしれないと伝え、代わりに仕事用メールを探すか、転送された領収書を受け取ることを提案する。見つかった情報（店名、金額、日付）で申請内容を事前に埋め、領収書でわからない項目だけを追加で質問する。

4. 領収書の検索結果は、見やすい表（店名、金額、日付、取得元）で示す。自動検索に失敗したら、止まらずにすぐ手動での代替手段を提案する。

5. 重複チェックを裏で黙って実行する。Gmail で過去の精算完了メールを探し、精算プラットフォームの取引履歴で同じ店名・金額・日付の最近の申請がないかも確認する。これを独立したステップとしては表示しない。重複が見つかった場合にだけ流れを止め、はっきりした警告カードを出す。

6. 精算プラットフォームを操作し、フォームを入力し、領収書を添付する。プラットフォームが対応していれば、選んだカテゴリの残高や予算も確認する。

7. 申請の前に、搭乗券のようなデザインの経費サマリーカードを表示する（プラットフォーム、店名、金額、日付、カテゴリ、領収書の状態、残高があれば残高）。申請する前に、`ask_user_input_v0` で私の明示的な OK をもらうこと。

8. ブラウザの操作を私に渡すのは、SSO ログインか支払いの確認のときだけにする。ブラウザの引き継ぎポップアップが出ない場合は、代わりにセッションの URL をクリックできるリンクとしてチャットに必ず表示する。

9. 自動化したステップが失敗した場合（プラットフォームの誤り、フォームの変更、領収書が見つからないなど）は、止まらずにすぐ手動の代替手段を提案する。

全体を通して：温かく、必要に応じて視覚的に、先回りして動くこと。整形されたカード、状況の更新、進捗ステップを使うこと。決して止まらず、常に次に進む道を示すこと。

業務の言葉を図にする: オントロジー

オントロジーとはある領域に登場する概念と、概念どうしの関係を、機械が読める形で明示的に書いたものです。簡単にいうと、この組織である言葉(ツールや業務、データ)と言葉がどのような関係であるかを書いたグラフのようなものです。例えば、一般的な営業やPM業務をオントロジーに起こすと以下のようになります。

前の節の Skill で手順書があるのに、なぜオントロジーが別に要るのか、その理由は 4 つあります。

Skill 1本が受け持つのは業務1つだけ

Skill に文字制限はありませんが、AI のコンテキスト(AIが把握する文章量)などを考慮するとすべての業務知識をひとつの Skill にまとめるのは現実的ではありません。そのため、1つの業務に対して1つの Skill を作成するのが一般的です。しかし、多くの事業施作は1つの業務では完結せず、複数の業務を順番に行う必要があります。業務と業務のつなぎめを定義するのも難しいです。例えば、広告の手順書が最後に出す「リード」は、営業の手順書が最初に受け取る「リード」と同じものなのか。同じ案件を両方の手順が触るとき、状態を進めてよいのはどちらなのか。この関係は、どちらの手順書の中にも書けません。片方に書けばもう片方からは見えず、両方に書けば片方だけが古くなります。しかも手順書が増えるほど、つなぎ目は組み合わせの数だけ増えていきます。業務どうしの関係は、業務の外側に 1 箇所置くしかありません。そこで役にたつのがオントロジーです。

Skill のなかに出てくる名詞を整理する

手順書には必ず名詞が出てきます。「リードを集計して」「CV の多い広告を残して」「アカウントごとに分けて」。その名詞が何を指すのかが揃っていなければ、手順そのものは正しく守られたとしても、異なる数字が出てきて分析の精度が落ちてしまいます。例えば、広告の手順書の「CV」は媒体が数えた件数、レポートの手順書の「CV」は営業が有効と判断した件数ですが、同じ一枚のレポートにすると、AI が混乱してしまう可能性があります。手順書に出てくる名詞の定義や名詞同士の関係性を定義するのもオントロジーの役目です。

手順を守らせる力を強固にする

Skill に「投稿する前に確認してください」と書いても、AI は状況によって従わないこともあります。「何に対して何ができるのか」を、文章でのお願いではなくグラフとしてツール操作の一覧を持たせることで、一覧にないことは実行できないようにすることもできます。また、ツールが動かない時に縮退先を定義しておくことで、AI が想定しない経路で外部との連携作業を行わないように対策することもできます。

マーケティングでは特にオントロジーが必要になると考えています。

同じものが媒体ごとに違う名前や単位で呼ばれている

広告媒体では「リード」、LINE では「友だち」、SNS では「フォロワー」、営業では「有効リード」、CRM では「顧客」。粒度もクライアントのデータの保存先も全部違います。同じ人物を媒体をまたいで追えないと、ROAS も CPA も「その管理画面の中でだけ正しい数字」になり、足し合わせても経営の数字になりません。ある媒体の CTR（クリック率）は 0 から 1 の比率で返り、別の媒体は 0 から 100 のパーセントで返すこともあります。金額も、通貨の最小単位で返す媒体と、通貨に依らず 100 万分の 1 の単位で返す媒体があります。マーケティングは収益や投資に関わる重要な業務なので、単位を統一しておくことが大切です。

媒体や戦略によって業務フローが異なる

理想のファネルは認知→興味→比較→購入と一直線ですが、実際は広告ならクリックからフォーム送信まで数分で終わり、SEO なら数週間後に指名検索で戻ってきて初めて CV し、LINE は登録が先で購買はずっと後、紹介にいたってはいきなり商談から始まります。これを一本のファネルとして実装すると、媒体を 1 つ足すたびに設計が壊れます。グラフで定義しておくことで、複数のケースを想定して AI に自動運転させることが可能です。

データが取れないこともある

マーケティング業務はツールの連携が多いので、自動化を実務で回すと、データが取得できないことが必ず出ます。このとき人は手を止めますが、AI は止まりません。取得できなかったときの挙動を制御するのもオントロジーによって可能です。

Single Source of Truth (SSOT)

SSOT（Single Source of Truth）とは、「信頼できる唯一の情報源」を意味する言葉です。データの置き場所を一つに決め、そこだけを正として扱い、組織内の全員が同じデータに基づいてビジネスの意思決定を行えるようにするための考え方です。

複数の AI Agent を組織内で運用する際に、それぞれのエージェントが異なるデータを参照すると判断がバラバラになってしまいます。また、エージェントがデータを編集する際に、該当のデータが二箇所に散らばっている場合、一箇所のデータのみが更新されていき、もう一箇所の場所のデータが古い情報のまま忘れられ、放置されるという自体にもなりかねません。

そのため、数値データや知見などは一箇所に情報を集約し、ツールの都合上どうしても二箇所以上に置かないといけない場合は、どちらが真の値 SSOT かを定義し、もう一箇所はSSOTの同期先とする必要があります。

ツールとのつなぎ方を選ぶ

この章の冒頭で挙げた 3 つのうち 2 つ目、連携について説明します。AI に媒体の数字を取らせたり、媒体を操作させるためには、その媒体を AI から呼べる形にしておく必要があります。そのために必要なのがツール連携です。AI Agent とツールを繋ぐ方法は 4 つあります。上から順に検討して、無ければ 1 つ下のものを検討するのがおすすめです。各技術については、二章で細かく説明します。

経路	中身	面倒を見るのは誰か	主な弱点
① 公式の MCP サーバー・コネクタ	提供元が用意した、AI 用の接続口	提供元	用意されている媒体がまだ少ない
② 公式 API / 公式 CLI	提供元が公開している呼び出し口	仕様は提供元、呼ぶ側は自分	AI から呼べる形にするのは自分の仕事
③ OSS・自作	有志や自分が API を包んだ道具	有志、または自分	放置されたものは気づかないうちに壊れる。自作の保守は永久に続く
④ スクレイピング	人が見る画面を機械に読ませる	自分	画面が変われば壊れる。規約と法令の制約も大きい。

公式の MCP サーバー・コネクタ

MCP（Model Context Protocol）は、AI と外部サービスをつなぐためのオープンな規格です。コンセントの差し込み口の規格と同じで、この規格に対応しているツールであれば、ChatGPT からでも Claude からでも呼び出しが可能です。MCP 自体は安全な仕組みになっていますが、注意する点もあります。MCP に接続するということは、AI が呼べる道具としてそれを迎え入れ、鍵を預けるということです。AI が個人情報などを持っている場合、それを MCP に渡すということになります。MCP が信頼できる提供元が開発したものかどうかを必ず確認できるようにしてください。公式の MCP であることが望ましいです。

公式 API と公式 CLI

公式のMCPが無ければ、次は公式の API (Application Programming Interface)と公式の CLI(Command Line Interface)です。API とはシステムがシステムを呼び出すための仕組み、CLI はPC 上のコマンドからシステムを呼び出すための仕組みです。これらは AI Agent から呼び出すこともできますが、必ずしも AI から呼び出すことに最適化されているわけではありません。例えば、後述するセキュリティの問題のように、ツールを呼び出すための認証情報を MCP に比べて安全に利用することができないことがあるからです。そのため、場合によっては、自分たちで API や CLI をラップした MCP を実装する必要がある場合もあります。

OSS と自作

使いたいツールや情報源に MCP も API も無い、あっても AI から呼べる形になっていない場合もあります。その場合、 OSS（オープンソースソフトウェア）を使うか、自作のツールを作るか、後述するスクレイピングを使うかになります。

OSS を選ぶ理由は費用だけではありません。中身が読めるので、AI に鍵を渡して動かすときに「このツールが鍵をどこに送るのか」「何を書き込むのか」を自分で確認できます。マーケティングツールは、管理画面しか無いもの、API のドキュメントが薄いもの、認証が独特なものが多く、AI から呼べる形になっていない領域は、AI がどれだけ賢くなっても手つかずで残りますただし、最初から自作しないのが原則です。保守コストは永久に発生します。既存の OSS があればまずそれを使い、無いか使い物にならないときだけ自作します。

OSS を採用するときの注意点は 3 つです。

ライセンスを確認する。社内利用なら問題にならないものがほとんどですが、クライアントへ納品するものや、改変して再配布するものは、ライセンスの条件（表示義務・ソース公開義務）を読んでから使います。
メンテナンスされているか見る。最終更新日、未対応の issue の数、媒体側の API 変更に追随しているか。マーケティング媒体の API は年に何度も変わるので、放置されたツールは気づかないうちに壊れます。動いているように見えて古い数字を返す、という壊れ方が一番厄介です。
鍵を渡す以上は中身を読む。特に AI エージェントから叩くツールは、AI の指示でそのまま実行されます。書き込みができるツールは、どのコマンドが書き込みなのかを把握しておきます。
スクレイピング

スクレイピングとは、ブラウザー上のWeb サイトの画面を機械に開かせて、そこに表示されている文字や数字を拾い集めることです。人が競合のページや口コミサイトを 1 つずつ開いて、見えている数字を表計算ソフトへ書き写していく作業をそのまま機械に肩代わりさせるものだと思ってください。API が「相手が用意した受付窓口で、このデータをくださいと頼む」形なのに対して、スクレイピングは「誰でも見られる店頭の掲示を、人の代わりに読んで控える」形です。ツールや情報源が MCP や API を公開している必要がないので、ブラウザー上でアクセスできるものなら何でも集められる一方で、スクレイピング自体が禁止されているサイトやツールもあります。

利用規約と法令の範囲で行う。

各サービスの利用規約、robots.txt、著作権、個人情報保護法の範囲を超えて収集しません。公開されている情報でも、大量に取得して蓄積すること自体を規約が禁じている場合があります。相手のサーバーに負荷をかけない（アクセス間隔を空ける、必要な分だけ取る）ことも同じ理由で守ります。

特に Meta（Facebook・Instagram）と TikTok は、利用規約で自動化した手段による情報の取得を禁じています。Instagram はログインしているかどうかも問いません。誰でも見られる広告ライブラリも例外ではありません。競合の広告や SNS アカウントを調べるときは、人がブラウザで検索して見た内容を記録し、AI にはその記録（表や画面写し）を渡します。手間を減らしたいときは、広告データを集めて MCP で提供しているサービスを使います。たとえば動画広告分析Pro は MCP サーバーを提供しており、Meta・TikTok を含む 13 媒体の広告を Claude Code などから検索できます。

壊れることを前提に運用する。

スクレイピングは画面の構造が変わった瞬間に壊れます。しかも「エラーになる」のではなく「空の結果や別の値が返る」壊れ方をすることもあります。API や MCP と違って、仕様変更は誰も知らせてくれません。取れた件数が 0 件ならそう書く、前回と件数が大きく変わったら報告する、といった形で、壊れたことが人に届くようにしておいたり、オントロジーを整えておく必要があります。

ログインが要る収集は自動化できないことが多い

自分のアカウントでログインして収集すると、訴訟を起こされたり、アカウントの停止リスクがあります。サーバーや自分の PC から実行する場合はその IP アドレスがバンになることがあります。ログインが要るものは、公式 API か、手元の PC での人による実査に留めます。

読んだ内容を AI がそのまま実行しない形にする。

これはセキュリティの項で改めて触れますが、外部のページを AI に読ませる以上、そこに書かれた文章が AI への指示として働く可能性があります。収集したものは「データ」として扱い、外部反映は承認を通します。

セキュリティについて考える

AI をマーケティング業務に組み込むと、AI は広告アカウント、SNS、CRM、顧客データにアクセスすることになります。そのため、以下のことに気をつけてください。

認証情報はコードにも会話にも書かない。

API キーなどの認証情報は AI が読めないように設定する必要があります。AI 直接に認証情報を貼り付けて渡してはいけません。会話の履歴やログにそのまま残り、後から消せません。多くの AI は会話ログのオプトアウト(情報が AI の学習に使われない)が可能ですが、会話ログに残ること自体が危険です。

渡す鍵は最小権限にする。

読み取り専用の権限で済む作業に書き込み権限の認証情報を渡さないようにしましょう。認証情報を持つ鍵(API Key)は期限付きのものを発行して、万が一漏れてしまった時は、鍵の発行側で鍵を無効化にしましょう。

プロンプトインジェクションを前提にする。

AI に競合サイトや口コミ、届いたメールを読ませる以上、その中に「これまでの指示を無視して〜せよ」という文章が仕込まれている可能性があります。悪意のあるプロンプトが実行されるリスクがあります。AI が読んだ外部の内容は指示ではなくデータとして扱い、外部反映は必ず承認を通す設計にする必要があります。

顧客データをどこに送るかを把握する。

AI サービスに送ったデータが学習に使われるか、どの国のサーバーに置かれるかは、契約プランで変わります。クライアントの顧客データを扱うときは、契約と利用規約を確認してから送ります。代理店として複数のクライアントを扱う場合は、案件ごとにデータと鍵を分け、ある案件の AI が別の案件のデータに触れない構造にします。

やったことを記録する。

AI が何を読み、何を実行し、誰が承認したかをログに残します。事故が起きたときに辿れる材料は、これしかありません。

これらは「AI だから特別」というより、他人にアカウントの操作を任せるときの当たり前のルールですが、改めて確認しましょう。

本書の章立てについて

本書は、マーケティングエンジニアに必要な知識をまとめています。マーケティングの業務を一つずつ取り上げ、実際のツールを使いながら自動化する方法を見ていきます。

まずどのようなマーケティング施作を行うのにも不可欠な「戦略設計」と「クリエイティブの自動化」について触れたあと、多くがシステム上で完結する施作である、広告、SEO/LLMO、SNS アカウント運用を重点的に解説します。最後にシステム上で完結する施作は限られますが、営業活動の自動化について解説して、各施作を統合した全体の自動化について解説します。

宣伝

弊社ではマーケティング特化の AI 支援サービス AllRev を提供しています。相談は無料ですので、ご興味がある方はご連絡をお待ちしております。https://all-rev.com/