※この記事は「MTI Blog Summer 2026」の 6/4 分の記事です。
こんにちは！AIオーケストレーションエンジニア部の原です！
今回はClaude Codeのセッションデータの構造と、それを使って自分のAIの使い方を振り返ってみた話を紹介します。
はじめに
現在AIが随分と普及してきた中で、今度はどうAIを制御して使用者に最適化された形にしていくのかという部分が話題になっています。Claude CodeでいうとCLAUDE.mdに制約などを書いて充実させていくことなどが1つのケースとして挙げられますね。ただそうなると、自分の使い方や使いづらかった点を振り返りながら制約としてAIに渡していく定期的な見直しが必要になってきます。
振り返るといっても自分の使い方を正確に覚えているわけではないので、Claude Code自身の会話ログが確認できると手っ取り早いですよね。そんなわけで、Claude Codeがローカルに保存しているセッションごとの会話ログ（セッションデータ）を使って振り返りをやってみたのでそちらを紹介します。
セッションデータについて
Claude Codeのデータは ~/.claude/ 配下に保存されています（Windowsの場合は %USERPROFILE%\.claude）。
~/.claude/ ├── projects/ │ ├── home-user-my-app/ # プロジェクトごとのディレクトリ │ │ ├── <session-uuid>.jsonl # セッション別の会話記録 │ │ └── CLAUDE.local.md # プロジェクト固有の設定 │ └── home-user-another-project/ │ └── ... ├── history.jsonl # プロンプト入力履歴 ├── settings.json # ユーザー設定 ├── skills/ # スキル └── ...
今回使うのは projects/<project>/<session>.jsonl です。セッションの全会話記録がここに保存されます。<project> は作業ディレクトリのパスがハイフン区切りになったもの（例: /home/user/my-app → home-user-my-app）で、セッションごとに別ファイルが作られます。
会話記録の <session>.jsonl はJSONL形式（1行1JSON）で、中身はこんな感じです。
// ユーザーの発言 { "type": "user", "message": { "content": "このクラスの設計で抜け漏れがないか確認してほしい" }, "timestamp": "2026-05-28T06:30:00.000Z" } // AIの応答 { "type": "assistant", "message": { "content": [{"type": "text", "text": "確認します。..."}] } }
各レコードは parentUuid で前後が繋がっていて、会話の順序を辿ることができます。
なお、これらのデータは平文で保存されています。セッション中にツールが .env の中身やコマンド出力を読み取った場合、その内容もそのまま記録されるため、取り扱いには注意が必要です。またセッションデータはデフォルトで30日経つと自動削除されるので、30日より前のデータは残っていない点も要注意です。
つまり、projects/ 配下のJSONLファイルを読めば自分がClaude Codeに何を聞いて何をさせたかを振り返ることができるというわけですね。次にこれがどのように使えるのかを紹介していきます。
セッションデータの活用
使い方は色々ありますがClaude Codeに「~/.claude/projects/<project>/ 配下のセッションデータを分析して」と指示して分析してもらうのが一番シンプルでやりやすいです。Claude Code自身がファイルを見に行って、プロジェクト内の全セッションを横断的に分析してくれます。もちろん自分でJSONLファイルを読み込ませて渡す形でもOKです。"type":"user" のレコードだけを対象にすれば自分の発言に絞った分析もできますね。ではさっそくこの分析によって何ができるのか具体的にいくつか紹介していきます。
1. スキル化候補の抽出
複数のセッションを横断して読み込ませると、似たような手順を繰り返している箇所が見つかることがあります。私の場合は、DB調査で毎回同じようなクエリの組み立て方をClaude Codeに指示していたり、社内向け資料を毎回同じフォーマットで作らせていたりしていました。こういった繰り返しはスキルとして切り出す候補になります。セッションデータがなければ「なんとなく同じことやってるな」で終わるところを、具体的にどの手順が重複しているかまで特定できます。
2. CLAUDE.mdの見直し材料
最初に触れた通り、CLAUDE.mdの制約は定期的に見直す必要があります。セッションデータを見ると、毎回同じ注意や前提条件を伝え直している箇所が見つかることもあります。毎回プロンプトで伝え直しているということは、それはCLAUDE.mdに書くべきルールです。逆に、CLAUDE.mdに書いてあるのにセッション中で守られていないルールがあれば、記述の仕方を見直すきっかけにもなります。
3. 使い方の傾向分析
各セッションで何をしていたかを分類すると、自分がClaude Codeをどんなタスクに使っているかの全体像が見えてきます。自分の場合、設計の議論やレビュー依頼のセッションが最も長く、次いで運用作業の手順確認、DB調査、資料作成などにも使っているという結果でした。実装にも使っていますが、振り返ってみると相談や確認の比重が思ったより大きかったです。こういう偏りは普段使っているだけだと気づきにくいので、データとして見ることで改めて気づける部分です。
4. 指示の出し方の癖を見る
これは少し毛色が違いますが、自分のプロンプトを並べてみると指示の出し方に癖があることに気づきます。自分の場合は「これ作って」よりも「これどう思う？」「抜け漏れないか確認して」のような相談形が多かったです。実態としては壁打ちとして使っていたケースがほとんどでした。直接何かの改善に繋がるわけではないですが、自分のAIとの付き合い方を客観視できて面白かったです。
おわりに
セッションデータはただのログファイルですが、振り返りの素材としては十分使えました。特にスキル化候補の抽出やCLAUDE.mdの見直しは、セッションデータがなければ感覚頼りになりがちな部分なので、定期的にやる価値があります。またセッションデータの話に限らず、新しいツールや手法が次々入ってくる中で、立ち止まって自分の使い方を振り返る機会は意識しないと作れません。その手段の1つとして、セッションデータは手軽で良い選択肢でした。
なお、Claude Codeには /insights という組み込みコマンドもあり、過去30日分のセッション履歴からサマリーレポートを自動生成してくれます。傾向の把握やCLAUDE.mdのルール提案など、今回紹介した内容と重なる部分もあります。違いとしては、/insights が自動要約なのに対して、生のセッションデータは具体的なやりとりの文脈まで辿れる点です。まずは /insights で全体像を把握して、気になった部分を生データで深掘りするという使い分けも良いかもしれません。
Claude Codeを使っている方は、ぜひ一度 ~/.claude/projects/ の中を覗いてみてください。
