post-cover

【第1回】 OpenClaw で Web マーケティング分析基盤をどう作ったか

アイゼック株式会社
監視カメラ・レコーダー技術ブログ

はじめに

この記事は、OpenClaw 導入をテーマにした連載記事の第1回です。OpenClaw の概要や導入全体の話は導入事例の記事でまとめており、技術的な詳細は本連載の各記事で整理しています。

関連記事:

この記事で記載しているサンプルコードは、公開リポジトリで参照できます。

GitHub:

当社で OpenClaw 導入の最初の対象にしたのは、Web マーケティング分析でした。理由は明確で、既存記事のリライト、内部リンクの整備、LP の見直し、広告改善といった施策が、見たい数字はあるのに実行へ落とし切れていなかったからです。

この記事では、Web マーケティング領域でどのようなデータを集め、どこまで分析できる基盤を作ったのかをエンジニア向けに整理します。

なぜ最初に Web マーケティングだったのか

導入の順番として、最初に Web マーケティングから着手しました。既存記事や LP はすでに資産として存在しており、分析と改善提案の仕組みができれば、比較的早く人間側の実行につなげやすかったからです。

現時点では、週次で Web マーケティングと広告のレポートを出力し、人間側ではそのレポートを読みながら記事リライトに着手しています。導入から約 1か月で、少なくとも「見るだけ」で終わらず、実際の改善作業へ接続できる状態までは持っていけました。

どのデータを横断しているのか

当社では、次のデータを組み合わせて Web マーケティング分析を行う構成にしています。

  • GA4
  • Google サーチコンソール
  • Google 広告
  • HubSpot
  • Clarity
  • Contentful
  • GitHub 上のサイトソース

重要なのは、分析ツールの数値だけで終わらせないことです。GA4 や Search Console だけでは、どの URL が見られているか、どの検索クエリで流入しているかは分かっても、ページ本文の中身や LP の導線設計までは判断できません。

そのため、Contentful の本文データや GitHub 上のソースコードも合わせて読み込ませ、数字とコンテンツ実体の両方を踏まえて提案できるようにしています。

API 取得はどう進めたのか

基本方針は、まず read-only で安全に取得できる状態を作ることでした。最初から更新系に踏み込まず、どの指標をどの粒度で取るかを先に固めています。

今回の記事で触れている API については、公開用リポジトリの 01-api-connection-samples に TypeScript の疎通確認サンプルをまとめています。pnpm install 後に .env.example を .env へコピーし、pnpm run test:ga4 や pnpm run test:hubspot のように read-only で確認できる構成です。

GA4

GA4 では Google Analytics Data API を使って、ページ別の閲覧状況、流入元、コンバージョンにつながる行動指標を取得する前提で設計しています。定期取得では、Google Cloud 側で API を有効化し、対象プロパティに対して閲覧権限を付与した認証主体を使って取得します。

参照:

Google サーチコンソール

Google サーチコンソールでは Search Console API を使い、検索クエリ、表示回数、クリック、掲載順位の変化を取得する構成にしています。Search Console は通常のデータ取得で OAuth 2.0 ベースになるため、対象サイトにアクセス可能な主体を用意し、webmasters.readonly を基本に設計しています。

参照:

Google 広告

Google 広告 API は、GA4 や Search Console よりセットアップが重い部分でした。OAuth を設定すれば終わりではなく、別途 Google Ads manager account の用意と developer token の申請が必要でした。

実務上は、次の順番で進めました。

  1. manager account を用意する
  2. API Center で developer token を申請する
  3. 必要に応じて access level の審査を進める
  4. Google Ads API を有効化した Google Cloud project 側で OAuth 2.0 認証を準備する
  5. developer-token や login-customer-id を含めた形で API を呼ぶ

当社では、まず広告レポート取得を中心に進め、いきなり更新系の運用には踏み込まない方針にしています。

参照:

HubSpot

HubSpot は、単一アカウント内の自社利用であれば private app access token、複数アカウントへ配布するアプリであれば OAuth という整理になります。当社のように自社の HubSpot データを読む用途では、まず private app で必要なスコープだけを付けて始めるのが現実的です。

private app を使う場合の流れは次のとおりです。

  1. HubSpot アカウント側で private app を作成する
  2. 必要なスコープだけを付与する
  3. 発行された access token を Authorization: Bearer ... で使う
  4. 必要に応じてトークンをローテーションする

もし将来的に複数アカウントへ配布する構成に広げる場合は、HubSpot の public app と OAuth へ寄せる形になります。OAuth の場合は、app を作成し、client_id と client_secret、redirect_uri、scope を設定して認可 URL を組み、返ってきた code から access_token と refresh_token を取得する流れです。

参照:

Clarity

Microsoft Clarity では Clarity Data Export API を使います。設定方法は比較的単純で、Clarity のプロジェクト管理者がプロジェクト設定画面から API トークンを発行し、そのトークンを Authorization: Bearer ... で送ります。

流れとしては次のとおりです。

  1. Clarity の対象プロジェクトを開く
  2. Settings -> Data Export -> Generate new API token から API トークンを発行する
  3. 発行したトークンを安全に保管する
  4. project-live-insights エンドポイントへ認証付きでリクエストする

Clarity の Data Export API は、取得可能期間が直近 1 から 3 日、1 プロジェクトあたり 1 日 10 リクエストまでなどの制約があるため、週次分析に組み込む場合も呼び出し回数と取得設計を意識する必要があります。

参照:

Contentful

Contentful は、何を読みたいかで使う API が変わります。公開済み本文を読むだけなら Content Delivery API、未公開の下書きも読みたいなら Content Preview API、コンテンツ管理操作まで含めるなら Content Management API です。

当社の Web マーケティング分析では、まず公開済みコンテンツを読む用途が中心なので、基本は Content Delivery API を前提にしています。必要に応じて、公開前の原稿確認や比較用途で Content Preview API を併用する想定です。

設定方法は次のとおりです。

  1. Contentful の対象 space を用意する
  2. space の APIs タブで Delivery API key を作成する
  3. 公開済みコンテンツ取得には CDA の access token を使う
  4. 未公開コンテンツを扱う場合は、同じ API key に紐づく preview access token を使う

Content Delivery API は環境ごとの access token で読み取り専用です。一方、Content Management API は read/write API で、Personal access token や OAuth 2.0 フローを使います。マーケ分析用途なら、まずは CDA または CPA に限定しておく方が安全です。

参照:

GitHub 上のサイトソース

GitHub 上のサイトソースを読む方法はいくつかありますが、組織や複数リポジトリを安全に扱う前提なら、GitHub 公式も GitHub App を推奨しています。個人利用なら fine-grained personal access token でも構いませんが、継続運用と権限制御を考えると GitHub App の方が扱いやすいです。

GitHub App を使う場合の流れは次のとおりです。

  1. GitHub App を登録する
  2. 必要最小限の権限を設定する
  3. private key を発行する
  4. JWT を生成して app として認証する
  5. installation access token を発行する
  6. そのトークンで対象リポジトリの contents や trees を読む

単にソースを読むだけなら、Contents や Metadata などの read-only 権限に絞るのが基本です。個人用トークンを使う場合も、fine-grained token で対象リポジトリと必要権限だけに限定する方が安全です。

参照:

サンプルプログラムの使い方

まずやることは、各 API に対して read-only で安全に接続できることの確認です。手順は次のとおりです。

  1. 01-api-connection-samples を参照し、ローカルに配置したうえでそのディレクトリへ移動する
  2. pnpm install を実行する
  3. .env.example を .env にコピーする
  4. 対象 API の認証情報や対象 ID を .env に設定する
  5. pnpm run check で型チェックを通す
  6. 確認したい API ごとのコマンドを実行する

実行コマンドは次のとおりです。

<span class="line"><span style="color:#B392F0">pnpm</span><span style="color:#9ECBFF"> run</span><span style="color:#9ECBFF"> test:ga4</span></span><span class="line"><span style="color:#B392F0">pnpm</span><span style="color:#9ECBFF"> run</span><span style="color:#9ECBFF"> test:gsc</span></span><span class="line"><span style="color:#B392F0">pnpm</span><span style="color:#9ECBFF"> run</span><span style="color:#9ECBFF"> test:google-ads</span></span><span class="line"><span style="color:#B392F0">pnpm</span><span style="color:#9ECBFF"> run</span><span style="color:#9ECBFF"> test:hubspot</span></span><span class="line"><span style="color:#B392F0">pnpm</span><span style="color:#9ECBFF"> run</span><span style="color:#9ECBFF"> test:clarity</span></span><span class="line"><span style="color:#B392F0">pnpm</span><span style="color:#9ECBFF"> run</span><span style="color:#9ECBFF"> test:contentful</span></span><span class="line"><span style="color:#B392F0">pnpm</span><span style="color:#9ECBFF"> run</span><span style="color:#9ECBFF"> test:github</span></span>

この段階で見たいのは、レスポンスが返るかだけではありません。どの API でどの指標が取れるのか、どの認証方式が必要か、週次運用に乗せるときに制限や権限で詰まらないかまで含めて確認します。

疎通確認ができたら OpenClaw にやらせたいこと

この基盤の上で、OpenClaw には次のような分析を担わせています。

  • GA4 と Search Console を見て、流入があるのに CV につながっていない記事を抽出する
  • 検索クエリ、表示回数、順位変化を見て、リライト優先度の高い記事を毎週並べる
  • Contentful の本文と GitHub 上のソースを読んで、どの見出し、CTA、内部リンクを直すべきかを提案する
  • Clarity の行動データを踏まえて、離脱しやすい導線や読み飛ばされているセクションを指摘する
  • Google 広告、自然流入、HubSpot の問い合わせ状況をつなげて、どの流入経路に予算や改善工数を寄せるべきかをまとめる
  • 週次レポートとして、重要指標の変化、原因候補、次に打つ施策を Markdown や PDF で出力する

単に数値異常を検知するだけではなく、「どのページをどう直すべきか」まで踏み込ませるために、コンテンツ本文とサイト実装も読ませているのがポイントです。

特にやらせたいのは、分析結果を人間の作業へ直接つなげることです。たとえば「この記事は順位が落ちている」で終わらせず、「どの検索意図に対して説明が足りないか」「どの関連記事への内部リンクを追加すべきか」「CTA をどこへ置き直すべきか」まで具体化させたいと考えています。

Cloudflare をどう位置づけているか

OpenClaw にレポートを作らせること自体はできても、人間が継続的に読める形で共有できなければ意味がありません。そのため当社では、生成した成果物を見るための基盤もあわせて用意する前提で設計しました。

具体的には、Cloudflare Workers 上で React Router を使ったレポート閲覧用サイトを動かし、OpenClaw が出力した PDF、Markdown、HTML を R2 に保存する構成にしています。これにより、「分析はできるが、成果物はその人の PC にしかない」という状態を避けやすくなります。OpenClaw がレポートを作り、社内の人間は同じ場所にアクセスして内容を確認する、という流れを作ることを重視しました。

なお、D1 も Cloudflare 上の構成要素として利用していますが、この Web マーケティング分析の記事で主に使っているわけではありません。D1 はどちらかといえば顧客DBのような共有データを扱う用途で使っており、ここでは Workers による閲覧基盤と R2 による成果物保管が中心です。

セキュリティで意識したこと

この領域でも基本方針は変わりません。

  • API キーや OAuth 情報はローカル保存を原則にする
  • 秘密情報を置くディレクトリは .gitignore に入れる
  • GitHub にはコードや仕様書を置くが、秘密情報は載せない
  • 権限は read-only を基本にする
  • 書き込みはレポート保存先など必要な場所だけに限定する

また、OpenClaw は個人 PC ではなく専用 PC 上で動かし、必要なデータにだけアクセスさせるようにしています。Web マーケティング用途であっても、AI に広い権限を持たせる前提にはしていません。

現時点での到達点

OpenClaw 導入は 2026年3月16日（月）から着手しており、この記事作成日の 2026年4月16日（木）時点で約 1か月です。この時点で、Web マーケティングではデータ収集と分析基盤は動き始めており、人間側では週次レポートを見ながら既存記事のリライトへ入っています。

次の段階では、内部リンク修正提案を実行に移し、その後 Google 広告の最適化へ広げていく予定です。

SNSでシェアしよう

この記事が役に立ったら、ぜひシェアしてください

URLをコピーしました