ランサーズ株式会社Publicationへの投稿
🌟

PdMのためのAI活用 ~LLMでアクセスログを“読む”~

だす
に公開
AI
pdm
LLM
ユーザー分析
zennfes2025ai
tech

はじめに

皆さんは施策を打つ際にどこのセグメントを対象にすると良いのかを考えるときにどうしていますか？

アクセスログを確認したり、インタビューを通してユーザーを知り、仮説を立て、そこから同じようなユーザーがどれくらいいるかをどうにか集計するなど、コストもかかるし難しい作業だと思います。
そこでせめて仮説だけでもなんとか低コストで立てたいと考えました。

本来であれば、ユーザー1人ずつ行動ログを見ていけば、仮説を立てることができますが、めちゃくちゃ時間がかかります。分担するにしても主観評価になると一貫した分析が難しいです。
LLMを活用することで、同じ価値観で分析を大量に処理できるので、ものすごく効率的に仮説を立てるところまでできることがわかりました。

アクセスログ分析の流れ

本記事で紹介する分析の全体の流れは以下の通りです。

  1. データ準備
  2. ユーザーごとの行動分析
  3. 分類
  4. セグメント比率の算出

1. データの準備

まずはユーザーのプロフィールとアクセスログのデータを用意しましょう。

自己紹介文など、サービス利用の動機や背景がわかるデータがあるほど精度が上がります。

ここで注意点ですが、個人情報の扱いに気をつけてください。匿名化済みであるか、LLMに渡しても個人情報が漏洩しないかを確認してください。
DeepSeekなどは渡したデータが向こうのサーバーに保存されるため、個人情報の扱いには注意が必要です。

用意するデータ量として、分析の初期段階では 10〜20人分をランダムに抽出してください。足りない場合はサンプルサイズを増やしましょう。

ユーザーごとにディレクトリを用意して、その中にログとプロフィールを用意しましょう。

user_001/
├── user.json
└── access.json

user_001/user.jsonイメージ

{
  "user_id": "u_001",
  "name": "John Doe",
  "created_at": "2025-08-01T10:12:00Z",
  "introduction": "〇〇を探しています。"
}

user_001/access.jsonイメージ

[
  {
    "user_id": "u_001",
    "timestamp": "2025-08-01T10:12:00Z",
    "action": "register"
  },
  {
    "user_id": "u_001",
    "timestamp": "2025-08-01T10:15:00Z",
    "action": "search",
    "keyword": "web design"
  },
  {
    "user_id": "u_001",
    "timestamp": "2025-08-01T10:20:00Z",
    "action": "view_detail",
    "item_id": "pkg_123"
  },
  {
    "user_id": "u_001",
    "timestamp": "2025-08-01T10:25:00Z",
    "action": "conversion",
    "item_id": "pkg_123"
  }
]

2. ユーザーごとの行動分析

次は1人ずつアクセスログをLLMに分析させていきます。

生のログでも割と解釈してくれます。ただし、URLやパラメータからの推測なので、少し仕様を教えてあげる必要が出てきます。/hogeと/fuga違うパスなのに同じ機能を提供しているとかあるんじゃないかと思います。弊社はあります….

かなり良い感じにLLMが解釈してくれるのですが、ドメイン知識がないと間違えることも多々あるので、最初の数件や定期的に人のレビューも行い随時プロンプトを改善すると良いでしょう。

要約した内容には、タイムラインと分析コメントも含めると解釈がしやすいです。

プロンプト例 (CursorやWindsurfからファイル参照して実行を想定)

あなたはアクセスログを分析するアナリストです。
ユーザーの行動を分析して要約してください。

## プロフィール
@files:/user_001/user.json

## アクセスログ
@files:/user_001/access.json

## 注目ポイント
- 登録後にどんな行動をしたか
- 繰り返した行動があったか
- コンバージョンしたか、しなかったか
- 離脱や再訪問があったか

## 注意点
- 必ずアクセスログを全文を読んでから要約してください

## 出力フォーマット

保存先: /{user_id}/report.md

### プロフィール概要

### タイムラインサマリー
例：
- 10:12 登録
- 10:15 「web design」で検索
- 10:20 サービス詳細を閲覧
- 10:25 コンバージョン

### 行動分析の考察
登録直後から検索 → 閲覧 → 即日コンバージョンという流れで、
短期間で即決したタイプと考えられる。

### 要約
能動的に検索行動を繰り返し、コンバージョンを達成した。
実行例

実行してみるとこんな感じでうまい具合にアクセスログを解釈してくれます。

分析レポート（個人情報マスク済み）

# プロフィール概要
- ユーザーID: user_****
- ニックネーム: anon-****
- 種別: 個人
- アカウント状態: 非表示
- 稼働状況: active
- 地域: 北海道
- 生年: 1994年
- 登録日: 2025-06-01
- 認証関連: 非公開
- メタ情報: search_count 0 / engagement_count 1

# タイムラインサマリー
- 01:16 登録（アカウント作成）
- 01:21 仕事詳細を閲覧（/work/detail/{id} へ遷移、参照: /work_form/add_finish/{id}）

# 行動分析の考察
- 登録直後（約5分後）に仕事詳細ページへ遷移し、目的意識のある初期行動が見られる。
- 検索行動の記録はなく（search_count 0）、サイト内回遊は最小限で単発の閲覧にとどまる。
- 遷移元から、仕事投稿完了画面から当該仕事の詳細に移動した可能性が高く、自己投稿の確認行動と推察される。
- コンバージョン（課金/発注/依頼確定など）の記録は確認できない。
- 同日内の短時間セッションで離脱しており、再訪の記録はない。

# 要約
- 登録→自己投稿の詳細確認という最小行動のみで、検索や追加アクションはなし。コンバージョン未達・再訪なし。

3. 分類

複数ユーザーの要約を生成したら、それらを元に分類を生成します。
分類の仕方に何か条件を入れたい場合はこの段階で調整しつつ、行動分析の時点で情報が足りなければステップを戻ってプロンプトを調整しましょう。

プロンプト例

以下はユーザーの行動要約です。
共通するパターンを見つけ、ユーザー行動の分類を定義してください。

@files:/user_001/report.md
@files:/user_002/report.md
@files:/user_003/report.md
...
実行例
[A] アカウント作成のみで離脱
[B] 数件のみ検索行動のみ
[C] 積極的なサイト回遊
[D] 購入コンバージョン
[E] 違反行為

4. セグメント比率の算出

各分類（セグメント）のボリューム感も算出するために、CSVに出力すると便利です。

各ユーザーの分類をCSVに出力してください。

出力CSVカラム

{user_id}, {分類名}
実行例
user_001,A
user_002,B
user_003,C
user_004,D
user_005,E
...

ROI試算が驚くほど楽にできた

これでセグメント比率を算出できるので、これを活用すればROI試算が劇的に楽になります。
例えば、登録直後に離脱するユーザーが20％いるなどと分かれば、これの改善施策を行うかの判断もしやすいです。

（おまけ）サンプリングサイズを拡張

1~4のステップを繰り返してサンプルサイズを増やしていくとより正確な比率の算出と他の分類パターンも発見できます。
時間とコストによって実施すると良いでしょう。

（おまけ2）MCPサーバーを接続してデータを自動で取得する

分析を作成する際に、実際にユーザーがアクセスしたデータを参照して分析レポートを作成してもらいたいですよね。
サービスとLLMを繋ぐMCPサーバーを作ればこれも可能になります。
実際にMCPサーバーを作成してみたところ（社外へは非公開）、分析レポートがかなり精緻になりとてもよかったです。

まとめ

どのセグメントをターゲットに手を打つべきかをなるべく早く正確に見極めて施策の効果を高めていくことが理想です。

今回の手法でLLMを活用することで以下のようなメリットもあります。

  • 分析コストを下げられる
    LLMにアクセスログを分析してもらうことで1人ずつ分析していく膨大なコストを削減できる

  • 施策検討のスピードアップ
    行動分類 → セグメント比率 → ROI試算まで一気通貫で行えるため、改善施策の優先順位を短時間で検討できる。

  • 主観やバイアスを排除しやすい
    人が分析対象を選択するとチェリーピッキングが起こりやすいです。ランダムサンプリングで対象を決めて分析の流れを組めるのでバイアスも避けられる。

  • ユーザーの解像度が上がる
    仮説を立てるステップとして今回の手法を使うことで、インタビューなど従来手法と組み合わせてより深くユーザーを理解することにもつながる。

LLMのおかげで、従来は人が解釈するのが難しかったアクセスログなどを”読む”ことが、ものすごく簡単になりました。
ぜひ試してみてください！

GitHubで編集を提案
ランサーズ株式会社
ランサーズ株式会社Publication

ランサーズ社の開発やデザインに関するノウハウをご紹介します。

Discussion