業務のJSONアクセスログ100件を、Claude Codeに6分で5タイプ別の行動傾向メモにしてもらった夜

2026年6月29日 18:05

夜中の0時、社内Slackにポロッと「来週の機能棚卸しで、先週分のアクセスログ100件くらい見ておいてほしい」と振られて、ふむ、と思いました。100件くらいなら手で読めば1〜2時間で終わる量、けれど業務時間にそれをやると確実に他作業が止まります。

マスキング済みのJSONログを眺めていると、user_idとendpointがID化されていて読みやすい一方、人間が読むには「で、結局このユーザー層は何をしている人たちなんですか」のサマリが結局自分の頭の中で組み上がらないと意味がない、というのが厄介な点でした。

そこで今夜は、JSONアクセスログ100件を入力に、Claude Codeに5タイプ別の行動傾向メモを書かせる方向で1本だけプロンプトを組んでみました。普段はSREの先輩が組んでくれている観点を、夜のうちに自分用テンプレに落とし込む試みです。結論から書くと、6分以内で1,300字ほどのメモが返ってきて、(要確認)タグも出るところに出てくれました。

こういう困りごと、ありませんか

業務でアクセスログを眺める場面は、機能棚卸し・パフォーマンス改善・障害切り分け・ユーザーガイドの優先順位付けなど、意外と多めです。SaaS側のダッシュボードでもざっくり傾向は見られるのですが、「特定ユーザー層がどこを踏んで何で詰まっているか」を把握しようとすると、結局生のログを開く流れになります。

そして開いた瞬間に困るのが、行数ではなく粒度です。100件くらいだと統計に丸めるには少なく、目で読むには多い。リクエスト1つずつにメソッドとステータスがあり、durationにバラつきがあり、user_idは伏せ字、endpointもID化、というのが業務環境の実情だと思います。

これを「結局このユーザー層は何をしている人たちか」までまとめるとなると、頭の中で軽い分類器を走らせる必要があり、これが時間を吸います。私の体感で90〜180分くらい、そのうち集中して読めている時間は半分くらい、というのが常でした。

業務でこの作業を週次でやる人にとっては、もう少しテンプレ化したい領域のはずです。今夜はその一段目として、5タイプ別の傾向メモに整える役割をClaude Codeに任せました。

試したこと

狙いは、Claude Codeに「ログを読んでサマリにする」だけでなく、「サマリの構造を5タイプに固定する」ところまで一気に渡すことです。出力の自由度を残すと、毎回違う章立てが返ってきて、後工程の比較が効きません。

5タイプは、(1)学習・閲覧／(2)作成・編集／(3)設定変更／(4)共有・通知／(5)エラー・離脱、の順に固定しました。これは社内SREの先輩がよく使っている分類を、Claude Codeに渡すために言葉を寄せ直したものです。順番込みで固定しているので、応答を流し読みしたときの認知負荷がだいぶ下がります。

合わせて、user_idと行動内容の紐付け禁止／ログにない属性の推定禁止／duration_msが3000ms超過の行はエラー・離脱タイプに寄せる、といった判定ルールを明文化しました。前にこの種の集計を雑にやらせたとき、いきなり「20代男性のヘビーユーザー像」みたいなペルソナを書き始めて困ったことがあり、その再発防止です。

最後に、注記欄とセルフチェック行を様式固定で末尾につけました。判定不能だった行の番号と、複数タイプ判定の根拠1行を可視化させる狙いです。出力本文の正しさを目視で追うとき、この末尾2つがあるとだいぶ楽になりました。

使ったプロンプト

下のプロンプトをそのままClaude Code（または同等のLLM環境）に貼り、最後の「↓」の下にマスキング済みJSONログ100件を貼って実行します。フィールド名は環境に合わせて読み替えてください。

あなたはサーバアクセスログ分析が得意なシニアSREです。
以下のJSONアクセスログ100件を入力に、ユーザー行動を5タイプ別の傾向メモに整理してください。

【入力】
- JSONアクセスログ100件(各行=1リクエスト)
- 各行のフィールド: timestamp, user_id, endpoint, method, status, duration_ms, user_agent
- user_idとendpointはマスキング済み(USER_001 / EP_A 形式)

【出力フォーマット(5タイプ固定・順番厳守)】
(1)学習・閲覧タイプ
  - 件数: (合計件数)
  - 代表エンドポイント: (3つまで、EP_X形式)
  - 時間帯傾向: (朝/昼/夜/深夜から該当2個まで)
  - 一文サマリ: (このタイプの行動を60字以内)
(2)作成・編集タイプ
  - 件数 / 代表EP3つ / 時間帯傾向 / 一文サマリ(60字以内)
(3)設定変更タイプ
  - 件数 / 代表EP3つ / 時間帯傾向 / 一文サマリ(60字以内)
(4)共有・通知タイプ
  - 件数 / 代表EP3つ / 時間帯傾向 / 一文サマリ(60字以内)
(5)エラー・離脱タイプ
  - 件数 / 代表EP3つ(status=4xx/5xx中心) / 時間帯傾向 / 一文サマリ(60字以内)

【厳守ルール】
1. 5タイプは順番込みで固定。タイプの追加・削除・順序入れ替えは禁止
2. 1行=1タイプ判定。複数タイプにまたがる行は最有力1タイプにだけ計上(理由は注記欄に1行)
3. user_idと行動内容の紐付けは禁止(個別user_idの行動推定をしない)
4. ログにない属性(年齢/職業/性別/言語/勤務先など)の推定は絶対禁止 → (要確認)タグで止める
5. 件数は実数のみ。「だいたい○件」のような曖昧表現は禁止
6. 時間帯傾向は次の4区分から該当2個まで:朝(6〜10時)/昼(10〜18時)/夜(18〜23時)/深夜(23〜6時)
7. status=4xx/5xxは(5)エラー・離脱タイプの代表エンドポイントとして優先計上
8. duration_msが3000ms超過の行はuser_agentに関わらず(5)エラー・離脱タイプに寄せる
9. 末尾に「(注記欄)」を設け、複数タイプ判定の根拠1行と、判定不能だった行の番号(計N件)を列挙
10. 全体1,200〜1,600字以内、各タイプの一文サマリは60字以内厳守

【セルフチェック行(末尾に1行・様式固定)】
(セルフチェック)5タイプ=(1)(2)(3)(4)(5)全部出力済/字数約X,XXX字/(要確認)タグN箇所/判定不能M件

入力のJSONログ100件は以下↓
(ここにマスキング済みJSON配列を貼る)

差し替えるのは「↓」の下のJSON配列だけです。フィールド名が違う環境では、上段の【入力】ブロックのフィールド一覧を実体に合わせて書き換えると、それ以降のルールは大体そのまま流用できました。

戻ってきたもの

マスキング済みJSON100件(およそ45KB)を入れて、戻ってきたのが下のような形でした。5タイプの順番込みで全部埋まっていて、注記欄とセルフチェック行が末尾についています。文字数は約1,380字、(要確認)タグは3箇所、判定不能行は2件でした。

(1)学習・閲覧タイプ
  - 件数: 38
  - 代表エンドポイント: EP_A / EP_C / EP_H
  - 時間帯傾向: 朝 / 夜
  - 一文サマリ: ダッシュボード表示と検索結果ページの取得が中心で、書き込み操作はほぼ伴わない。

(2)作成・編集タイプ
  - 件数: 21
  - 代表エンドポイント: EP_B / EP_D / EP_E
  - 時間帯傾向: 昼
  - 一文サマリ: 主に昼の業務時間帯にPOST/PUTが集中、duration_msは概ね500〜1200msの範囲。

(3)設定変更タイプ
  - 件数: 9
  - 代表エンドポイント: EP_F / EP_K / EP_M
  - 時間帯傾向: 昼
  - 一文サマリ: 通知設定とプロフィール更新が中心、全体に占める割合は1割未満。

(4)共有・通知タイプ
  - 件数: 14
  - 代表エンドポイント: EP_G / EP_I / EP_N
  - 時間帯傾向: 夜
  - 一文サマリ: リンク発行と外部通知系のPOSTが夜に集中、(要確認)外部送信先の特定は本ログだけでは不可。

(5)エラー・離脱タイプ
  - 件数: 16
  - 代表エンドポイント: EP_J(500) / EP_L(429) / EP_O(timeout)
  - 時間帯傾向: 夜 / 深夜
  - 一文サマリ: 5xxと429の混在、duration_ms 3000超は夜〜深夜に偏る、再試行有無は(要確認)。

(注記欄)
- 複数タイプ重複の判定根拠: 同一トランザクション内でPOST→GET連続の行は直前POSTの(2)側に寄せた
- 判定不能行: LOG #07, LOG #34 (methodが空かつendpointが EP_? のため)→(要確認)

(セルフチェック)5タイプ=(1)(2)(3)(4)(5)全部出力済 / 字数約1,380字 / (要確認)タグ3箇所 / 判定不能2件

5タイプの並びと様式が固定なので、来週同じ作業をやってもパッと突き合わせができそうな形に整っています。「で、結局この週は何が起きているのか」という問いに、注記欄とセルフチェック行が補助線として効きました。

効いた指示・工夫したポイント

5タイプ順番込みで固定：(1)〜(5)を毎回同じ順で出させると、週次の差分が一目で読めるようになりました。順番を緩めると応答ごとに章立てが変わって比較が効かなくなります。
user_idと行動の紐付けを禁止：これを入れないと、「USER_007はヘビー作成ユーザー」のような個別人物像をいきなり書き始めるので、プライバシー方針的にも分析方針的にも事故の元になります。
ログにない属性の推定は(要確認)タグで止める：年齢・職業・勤務先などの外挿は一切させず、推定が必要な場面では(要確認)で停止させるルールに寄せました。今回も外部送信先の特定箇所で(要確認)が出ています。
duration_ms 3000ms超過は(5)に寄せる：性能観点の異常を(5)エラー・離脱タイプ側に集約することで、後で「夜〜深夜に遅い」「日中は遅延少ない」のような時間帯傾向が浮かびやすくなりました。
注記欄＋セルフチェック行を様式固定で末尾に：判定不能行と複数タイプ判定の根拠を可視化することで、目視チェックの起点がはっきりします。出力本文の数字だけ追って終わらせない歯止めにもなりました。

カスタマイズ・他用途への応用

機能棚卸しの一次資料：(1)〜(4)の代表エンドポイントを「よく踏まれている機能」として並べ替えると、機能横断のユーザーガイド更新優先度の素案になります。
SaaSのプライシング見直し：(2)作成・編集と(4)共有・通知の比率を週次で並べて、書き込み中心ユーザーと共有中心ユーザーの構成変化を追う材料にできます。
パフォーマンス改善の優先度判断：(5)に寄せたduration超過行の代表エンドポイントを並べて、改善作業の順序を決める入力にできます。
5xx集中時間帯の早期検知：(5)エラー・離脱タイプの時間帯傾向に「深夜」が出始めた週は、夜間バッチかリリース後の翌朝対応をスタックに積む合図にできます。
ユーザーガイド更新の優先順位：(1)学習・閲覧タイプの代表エンドポイントから順にFAQやチュートリアル更新を当てる、という運用に流せます。

使い心地・気づき

(4)共有・通知タイプを(2)作成・編集から別立てにしておくと、夜の外部送信ピークが見えやすくなり、想像以上に効きました。最初は(2)に混ぜていたのですが、別立てにしたほうが時間帯傾向のメリハリがつきます。
user_idと行動内容の紐付け禁止は必ず明文化が必要です。明示しないと、LLM側が親切心で自動的にペルソナを書き始める傾向がありました。
注記欄に「判定不能行の番号」を出させると、後から該当ログを直接確認しに行けるので便利でした。逆にここを省くと、出力サマリだけで仕事した気になりがちです。
(要確認)タグを禁止語と勘違いしてしまうケースがあり、ルール文に「→(要確認)タグで止める」と明示しておくのが安定運用のコツでした。
マスキングは入力前に必ず一度入れます。Claude Code側に「マスキングしてから渡しています」と書くだけでなく、本当にマスキング済みかをコピー前に目視で1回確かめておくと、後悔がありません。

所要時間のまとめ

ログのマスキング(USER_xxx / EP_xx へ置換): 2分
プロンプト貼り付け＋応答待ち: 1分
(要確認)タグと判定不能行の目視チェック: 3分

合計で6分以内。手作業で同じ深さのメモまで持っていくと、私の体感で90〜180分はかかっていた領域でした。1桁減ったというより、業務時間の他作業を止めずに済む、という方が効果としては大きい印象です。

結びに

ふむ、ログを5タイプ別に整えるテンプレが1枚あるだけで、夜中に頼まれたチケットを翌朝までに静かに片付けられるようになる、というのが今回の手応えでした。プロンプト自体は短めですが、(要確認)タグ・注記欄・セルフチェック行の3点セットが地味に効いています。

同じ作業を週次で回す場合は、5タイプの内訳をそのまま週次の比較表にしてしまうのが次の一手になりそうです。手元の業務でもこのテンプレで一通り回せそうな手応えがありました。