post-cover

【第2回】OpenClaw で顧客分析基盤をどう作ったか: メール、請求データ、顧客DBの統合

アイゼック株式会社
技術ブログ

はじめに

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

関連記事:

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

GitHub:

Web マーケティングの次に着手したのが、既存顧客との関係性強化に向けた顧客分析基盤です。ここでは、売上、メール、顧客情報、営業の気づきといったバラバラの情報を、OpenClaw が継続的に読める形へ揃える必要がありました。

この記事では、顧客分析領域でどのようにデータを集め、どこで情報が不足し、何を追加実装したのかを整理します。

どこから着手したのか

導入の順番としては、Web マーケティング分析の次に、まずマネーフォワード クラウド請求書からのデータ取得を進め、その後にメールの収集と分析を整備しました。

理由は、先に請求データから顧客 DB の土台を作り、顧客 ID を基準に各種データを紐付けたかったからです。そのうえで接点履歴としてメールを重ねていけば、顧客別の状況をかなり見られるだろうと考えました。ただし、実際にやってみると、それだけでは足りない部分も明確になりました。

マネーフォワードの請求データをどう使っているか

最初にやったのは、マネーフォワード クラウド請求書から顧客別の売上、請求書数、購入商品数、売れている品目を取得する仕組みを作ることでした。ここで顧客 DB の土台を作り、以降のメールや日報をどの顧客 ID に紐付けるかの基準にしています。

この記事で触れている顧客分析系のサンプルコードと仕様書は、公開用リポジトリの 02-customer-analysis-samples にまとめています。マネーフォワード疎通確認、PST の匿名化 JSON 変換、POP3 の read-only 取得と JSONL 追記仕様を、会社情報や個人情報がそのまま出ない形で整理しています。

API 取得は、まず read-only スコープを前提に設計しています。初期段階では、更新系よりも「何がどれだけ売れているか」「どの顧客が重要か」を安定して見られることを優先しました。

現在は、マネーフォワードも freee も、API や MCP サーバーの整備が進み、どちらも AI と組み合わせて会計分析や経営分析へつなげやすい選択肢になってきています。会計や請求データを AI に読ませて分析させたいなら、自社で使っている SaaS や周辺運用に合わせて、どちらかを基盤に選ぶのが現実的だと思います。

参照:

Outlook の PST をどう扱ったか

請求データから顧客 DB の土台を作ったあとに、次は過去のメールをその顧客 ID に紐付けていきました。そのため、初回は Outlook の PST ファイルを JSON 化する仕組みを作り、メール本文、送受信先、件名、添付情報などを AI が扱いやすい構造化データに変換しました。

この作業の目的は、過去のメールを顧客分析基盤へ載せることです。PST の中身をそのまま保存したいのではなく、顧客分析の入力データとして再利用できる状態にすることを重視しました。

顧客 DB の顧客 ID を先に持っていたことで、PST から取り出したメールがどの顧客に該当するのかを整理しやすくなりました。その後は、POP3 で日次取得した新規メールを増分で取り込み、初回に整備した過去データへ足していく構成にしています。

実際に分かったこと

メールと請求データを組み合わせると、顧客との接点頻度や売上傾向はかなり見えるようになります。ただし、実際に顧客メールを分析すると、 内容の大半はサポート対応と見積依頼 でした。

つまり、メール分析だけでは、潜在ニーズの掘り起こしや 「次に何を提案するとよいか」 という判断材料がほとんど取れませんでした。ここが、顧客分析基盤を作るうえで大きな発見でした。

なぜ顧客DBと営業日報を追加したのか

この不足を補うために、レポート用サイト側へ顧客 DB と営業日報の入力機能を追加しました。

顧客DB

顧客 DB には、社員が顧客の概要を入力できるようにしています。たとえば、どのくらいの規模の会社なのか、どういう取引が多いのか、窓口担当者は誰かといった、定量データだけでは持てない情報を入れられるようにしました。

営業日報

営業日報には、営業担当者が「今日はこの顧客に対して何をしたか」「何に気づいたか」を書けるようにしています。これによって、メールや請求データには現れにくい現場の感触を OpenClaw が読めるようにしました。

最初は顧客別に日報を書く UI を考えましたが、この方式では入力工数が大きく、継続運用しにくいことが分かりました。そこで、営業担当者は通常の日報を書く形にし、夜間バッチで OpenClaw が本文を読み、どの顧客に関する内容かを判断して顧客側へ反映する方式に変更しました。

この変更によって、入力負荷を増やさずに、顧客ごとの行動履歴や気づきを分析へ取り込めるようになっています。

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

ここでまず確認したいのは、顧客分析の入口になるデータを、安全に取得して同じ基盤へ積み上げられるかです。手順は次のとおりです。

  1. 02-customer-analysis-samples を参照し、ローカルに配置したうえでそのディレクトリへ移動する
  2. pnpm install を実行する
  3. .env.example を .env にコピーする
  4. マネーフォワード、PST 対象ファイル、POP3 の設定値を .env に書く
  5. pnpm run check で型チェックを通す
  6. 目的ごとに個別コマンドを実行する

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

pnpm run test:money-forwardpnpm run export:pstpnpm run fetch:pop3

役割は次のように分かれています。

  • pnpm run test:money-forward 請求データを read-only で取得し、顧客 DB の土台を作れるかを確認する
  • pnpm run export:pst Outlook の PST を、匿名化済みの JSON として分析基盤へ載せられる形に変換し、どの顧客 ID に紐付けるかを整理する
  • pnpm run fetch:pop3 POP3 で新着メールを read-only 取得し、増分追記できることを確認する

この段階で見たいのは、認証が通るかだけではありません。顧客単位で束ねるためのキーが作れるか、請求データを基準にメールを紐付けられるか、匿名化したあとでも分析に必要な粒度が残るか、過去データと日次増分を同じ形式で積み上げられるかまで確認します。

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

この基盤の上で、OpenClaw には次のような役割を持たせています。

  • マネーフォワードの売上や請求データから顧客 DB を作り、顧客ごとの ABC 分析を行う
  • 過去メールと日次メールを顧客 ID に紐付けて、顧客ごとの関係性や最近のやり取りを要約する
  • 顧客 DB と営業日報も合わせて読み、次に誰へ何を提案すべきかを候補として出す
  • 既存の購入商材と問い合わせ傾向を見て、クロスセル候補や追加提案の切り口を挙げる
  • 一定期間接点が薄い顧客を抽出し、休眠顧客として優先順位付きで並べる
  • 月次レポートとして、重点顧客、注意顧客、次アクション候補を一覧で出力する

現時点では、月次レポートを出力する運用まで進んでいます。一方で、既存顧客との関係性強化施策そのものはまだ本格実施前で、そろそろ着手できる見込みという段階です。

次の構想として考えているのがメルマガ施策です。これまでは必要だと思いつつ、そこまで工数を回せていませんでした。ただ、今は顧客分析基盤で顧客情報を拾えるようになり、HubSpot もあるため、OpenClaw に「どんな情報が受けやすいか」「何がメルマガの題材になりそうか」を提案させ、文面の下書きまで支援させたいと考えています。

そのうえで、人間が内容を確認したうえで HubSpot から配信し、開封率や反応データを回収し、また次の顧客施策へ戻す流れを作りたいと考えています。顧客分析が単独で終わるのではなく、配信施策と効果測定までつながると、既存顧客との関係性強化のサイクルがようやく回り始めます。

特に重要だったのは、メールや請求データだけでは「次に何を売るべきか」までは見えにくかったことです。だからこそ、OpenClaw には定量情報だけでなく、顧客 DB の概要や営業日報の気づきも読ませ、実務に近い提案まで出させたいと考えています。

データをどう保存し、共有しているか

この領域でも重要なのは、分析データを個人のローカル環境に閉じ込めないことです。メール由来の情報、請求データ、顧客 DB、営業日報などを顧客分析用の共通データ基盤へ集約し、その成果物を R2 側へ置いて OpenClaw と社内のレポート閲覧環境が参照できるようにしています。

これによって、「ある担当者の PC にだけ最新の顧客分析結果がある」という状態を避けやすくしています。

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

顧客データは、Web マーケティングよりさらに慎重な扱いが必要です。そのため、次の方針を重視しています。

  • API キーやトークンはローカル保存を原則にする
  • 秘密情報は GitHub に置かない
  • 権限は read-only を基本にする
  • 書き込みはレポート保存先や必要な共有基盤だけに限定する
  • OpenClaw は専用 PC 上で動かし、必要な情報にだけ触れさせる

また、当社では開発と検証では同じキーを使い、稼働に入るタイミングでキーをリフレッシュしました。理想論だけでなく、運用に入る境目で確実に切り替えることを重視しています。

現時点での位置づけ

OpenClaw 導入は 2026年3月16日（月）から着手し、2026年4月13日（月）時点で約 1か月です。この時点で、データ収集と分析基盤は一通り動き始めています。

これまでの AI 活用は、チャット欄で相談したり、特定フォルダだけを見せたりする形が中心でした。しかし OpenClaw の導入で、AI が会社全体の情報を継続的に収集し、分析し、そこから提案を出す状態へ変わりつつあります。顧客分析基盤は、その変化を最も実感しやすい領域のひとつです。

SNSでシェアしよう

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

URLをコピーしました