Claude のログ分析基盤を S3 Tables + Athena で構築する

Claude Team プランを部内のメンバーに配っても、使いこなせる人とそうでない人の差は自然には縮まりません。この記事では、Claude Code と Cowork の利用ログを CloudWatch Logs 経由で S3 Tables に集め、Athena で分析して良い使い方を自動的に見つけ、ダッシュボードで組織に還元する仕組みを紹介します。Databricks のような専用データ基盤ではなく、AWS だけで完結する構成にすることで、月数十ドル程度のランニングコストに抑えています。

配っただけでは AI 活用は浸透しない

部で Claude Team プランを購入してメンバーに配布すると、使いこなせる人とそうでない人の差がすぐに出ます。本来は各自が Slack などで良い使い方を自発的に共有できれば理想的ですが、そうした文化が根付くには時間がかかります。

文化の醸成を待つ間にも活用度の差は広がっていくため、良い使い方を自動的に見つけて組織にフィードバックする仕組みが必要だと考えました。「こういう使い方をしている人がいます、こういう使い方はどうですか」を、組織側から提示できる状態を目指します。

これを実現するためにやることは 3 つです。

1. ログを集める
2. その中から良い使い方を見つける
3. 見つけたものを組織に配る

この 3 つを回し続けるには、裏側にログを蓄積・分析するデータ基盤が要ります。

全体アーキテクチャ

基盤は次の 5 つの工程で構成しています。

技術選定では、Databricks のような専用データ基盤ではなく AWS（S3 Tables + Athena）を選びました。理由はスモールスタートしやすく、ランニングコストを抑えられるからです。Athena のスキャン量にもよりますが、月数十ドル程度で運用できています。複雑で大規模な分析基盤が必要になった場合は、Databricks のような専用プラットフォームのほうが適していますが、まず小さく始めるという目的には今回の構成が向いています。

以下、①から⑤までを順に説明します。

① 集める：Claude Team プランの管理機能で OTel 収集を強制する

Claude Team プランには、部内の全メンバーの設定を一括管理できる管理機能があります。これを使って OpenTelemetry（OTel）テレメトリの送信を強制し、収集を個々人の任意設定に委ねないようにしました。送信先には CloudWatch Logs を指定しています。OTel の送信プロトコルである OTLP を CloudWatch Logs が直接受け付けるため、中継サーバーを別途構築する必要はありません。

Claude Code と Cowork では設定方法が異なります。

Claude Code は managed-settings.json で設定します。このファイルは最優先で読み込まれ、ユーザー側の設定で上書きできません。

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://logs.<region>.amazonaws.com",
    "OTEL_LOG_USER_PROMPTS": "1"
  }
}

Cowork は環境変数ではなく、Claude Desktop の Organization settings 内にある Cowork の設定画面から、管理者が同じ CloudWatch Logs の送信先を中央設定します。プロンプト本文も既定で送信されます。

どちらの経路でも、全イベントは prompt.id / user.email / session.id を持ちます。この 3 つのキーがあることで、人 × プロンプト × セッションで束ね直して分析できます。

② 貯める：CloudWatch Logs から S3 Tables へネイティブ統合する

CloudWatch Logs の S3 Tables Integration を使うと、Firehose のような中継を挟まずに、ログをそのまま Apache Iceberg 形式で S3 Tables に貯められます。中間インフラを別途用意する必要がありません。

Iceberg 形式なので、スキーマ進化や MERGE がそのまま使えます。分析の土台をこのあとの工程で SQL だけで扱えるのは、この特性によるものです。

ここで一点注意が必要です。CloudWatch Logs が管理する raw データは、CloudWatch 側のリテンション設定と連動して消えます。ログをそのまま長期保管したい場合は、次の「整形する」工程で作る structured 層を長期保管の砦にしておく必要があります。

③ 整形する：3層構成で分析できる形に整える

データは raw → structured → analytics の 3 層構成にしています。いずれの層も、prompt_id を冪等キーとした MERGE でコピーします。同じ prompt_id のレコードが再実行で重複挿入されるのを防ぐためです。

raw → structured では型付けと prompt_kind（scheduled / with_upload / interactive など）の判定を行います。

MERGE INTO structured.agent_user_prompts t
USING (
  SELECT prompt_id, user_email, event_time, prompt_text,
    CASE WHEN prompt_text LIKE '<scheduled-task%' THEN 'scheduled'
         WHEN prompt_text LIKE '<uploaded-files%' THEN 'with_upload'
         ELSE 'interactive' END AS prompt_kind
  FROM raw.agentevents
  WHERE day = current_date - interval '1' day
) s ON t.prompt_id = s.prompt_id
WHEN NOT MATCHED THEN INSERT
  (prompt_id, user_email, event_time, prompt_text, prompt_kind)
VALUES
  (s.prompt_id, s.user_email, s.event_time, s.prompt_text, s.prompt_kind)

structured → analytics では、用途別のマートを作ります。

MERGE INTO analytics.person_prompts_timeline t
USING (
  SELECT user_email, date(event_time) AS report_date,
         event_time, prompt_id, prompt_kind, product, session_id
  FROM structured.agent_user_prompts
  WHERE user_email IS NOT NULL
) s ON t.prompt_id = s.prompt_id
WHEN NOT MATCHED THEN INSERT
  (user_email, report_date, event_time, prompt_id,
   prompt_kind, product, session_id)
VALUES
  (s.user_email, s.report_date, s.event_time, s.prompt_id,
   s.prompt_kind, s.product, s.session_id)

※ 上記の SQL は登壇資料からの抜粋で、一部省略しています。

この変換は毎日決まった時刻にバッチとして自動実行しています。EventBridge が定時に起動し、Step Functions がワークフローを順に実行し、Athena が StartQueryExecution で MERGE を実行し、S3 Tables の structured / analytics テーブルが更新されます。手を動かすのは初回の全量ロードだけです。

前日分の絞り込みは current_date - interval '1' day を条件に加えるだけで、初回の全量ロードと同じ SQL を使い回せます。締切や遅延到着のデータを厳密に扱いたい場合は、Systems Manager Parameter Store のウォーターマークと Step Functions の ExecutionParameters を組み合わせて渡す方法が使えます。

④ 分析する：整形済みのデータに Athena で SQL を投げる

ここまで整形が終わっていれば、あとは普通の SQL で分析できます。たとえば、直近 7 日間の利用者ごとのプロンプト数はこの 1 本で取得できます。

SELECT user_email, count(*) AS prompts
FROM   analytics.person_prompts_timeline
WHERE  report_date >= date '2026-07-14'
GROUP BY user_email
ORDER BY prompts DESC

このクエリを含む集計結果はそのままダッシュボードに流せます。ある週（2026/7/14〜7/21、全製品）の実データでは、総プロンプト数 2,345、セッション数 589、アクティブ利用者 24 名、平均プロンプト長 656 字という値になりました。製品別の内訳は Cowork が 54%、Claude Code Desktop が 26%、Claude Code CLI が 19% です。

⑤ 配る：ダッシュボードと個人インサイトで組織に届ける

集計結果はダッシュボードにして初めて組織に届きます。Claude Team プランではライブアーティファクトをそのまま共有でき、作成した本人以外も開けば最新の集計を見られます。

仕組みとしては、画面から MCP を呼び出し、MCP が Athena で SQL を実行し、結果の JSON を受け取って描画します。ボタン一つで最新化でき、共有された側も同じものを見られます。今回利用した MCP は awslabs の aws-dataprocessing-mcp-server です。Athena や Glue といった AWS のデータ処理系サービスを呼び出せます。

ダッシュボードには 2 つの画面を用意しています。

• 全体ダッシュボード：KPI・日次推移・製品比・利用者ランキング・種別構成を一画面に集約し、期間や製品で絞り込めます。
• 個人インサイト：メンバーを指定すると、その人の種別構成や日次推移を確認できます。繰り返し出している指示を CLAUDE.md にルール化する提案まで表示され、個人の使い方を振り返る入口になっています。

固定のダッシュボード以外に、MCP を Athena に繋いでおけば、決まった画面に縛られない分析もできます。「先週いちばん使ったのは誰か」のような問いを自然言語で投げると、Claude が SQL を組んで Athena で実行し、その場で答えます。「この切り口で可視化して」と頼めば、Claude がその場でライブアーティファクトを生成することもできます。集計を提示するだけでなく、活用を支援する分析として使える形です。

実ログから見つかったユースケース

実際の利用ログ（2026/7/6〜7/21のプロンプト利用ログ）から、効果の大きいユースケースを抽出しました。判断軸は再利用性、意思決定への貢献、削減頻度、展開ポテンシャルという定性的なものです。時間削減量のような定量指標にもとづく評価はまだできていません。ここで挙げる 4 件は、担当者名・お客様名を伏せた上での紹介です。

分析頻度と品質評価の難しさ

この抽出は AI（Claude）に任せています。ユーザーが投げたプロンプトはスラッシュコマンド経由か自動解釈かを区別せず、まとめて渡しています。

一度に解析する期間を伸ばしすぎると Claude がエラーを返してくることがわかったため、現在は週単位（週 1 回）で解析を回しています。

もう一つ未解決の課題として、Claude の回答品質の評価があります。ログにはユーザーのプロンプトから Claude が実行したコマンド、そして返した結果までの一連の流れがすべて残っています。ただし、その回答が「良い回答だったか」を自動で判定する仕組みはまだありません。プロンプトと結果を 1 対 1 に紐付けて品質を評価するところまでは到達していません。良い回答かどうかの判断は、次の質問が必要だったかどうかなど、人が見ても判断が難しい部分があり、今後の検討課題です。

これから：効果測定への展開

ユースケースを見つけて配る仕組みができたので、次は効果測定に取り組む予定です。具体的には次の 3 つを考えています。

1. 活用度計測：どの案件で、どれくらい使っているのかを可視化する
2. 適用業務発見：繰り返し処理を見つけ、業務フローの改善につなげる
3. 効率化率：削減できた時間を計測し、効果を数字で示す

まとめ

Claude のログ分析を行い、以下を実現しました。

• 良い使い方を自動的に見つけ、組織に展開する仕組み
• それを S3 Tables + Athena で低コストに実現するアーキテクチャ

社内で継続的に改善を進めています。同じように Claude の利用ログから活用実態を可視化したいという方は、お気軽に KDDI アイレットへご相談ください。