こんにちは。認証チームのいまひろです。
直近の記事では、Claude Codeをチームでより効果的に活用するための2つの取り組みを紹介しました。
前者は、開発で得た知見をチームの資産として蓄積・再利用する知識の永続化。後者は、チームの開発規約やプロセスをプラグインとして定義し、誰が作業しても同じ品質が再現される開発プラクティスのコード化。どちらも、Claude Codeが実装の中心を担う開発をより速く・より質高く回すための仕組みです。
今回は少し異なる角度からの取り組みを紹介します。「Claude Codeが何をしたかを記録し、チームで共有する」という、純粋な開発の加速よりも、開発チームとしての可視性や連続性を支える仕組みです。プラグインのカスタムコマンドとGitHub Actionsを組み合わせることで、各セッションの作業記録を自動蓄積し、週次レポートとしてチームに届ける仕組みを構築しました。
背景：モブ開発でClaude Codeが活発になるほど、記録が散逸する
私たちのチームはモブプログラミングを主体とした開発スタイルを採用しています。クリティカルな機能を扱う関係上、チーム全員で開発方針を決め、そのままClaude Codeに調査や実装を担ってもらうことが開発の日常となっています。
ほとんどの開発がClaude Codeをインターフェースとして進む中で、気づけば一つの課題が浮かび上がってきました。
Claude Codeのセッションが散らばっている問題です。
ドライバーA の Claude Codeセッション ├─ チケットX の実装（月曜午前） └─ チケットY の調査（月曜午後） ドライバーB の Claude Codeセッション ├─ チケットY の実装（火曜） └─ チケットZ のPR対応（水曜） ドライバーC の Claude Codeセッション └─ チケットZ の追加実装（木曜）
モブ開発ではドライバーが交代するたびに新しいセッションが始まるため、その日・その週にチームとして何をしたかを把握するのが難しくなっていました。
特に問題を感じていたのは、休み明けの月曜日です。生成AIを主軸とした開発スタイルの弊害なのか、「先週何をやってたんだっけ？」という状態から始まることが多く、Jiraのチケットやプルリクエストを確認して記憶を手繰り寄せることに時間を使っていました。
解決のアプローチ：セッションごとに「航海日誌」を記録する
この課題を解決するために取り組んだのが、Claude Codeのセッション内容を自動記録する仕組みです。
考え方はシンプルです。各セッションの終わりに「このセッションで何をしたか」をMarkdownファイルとして専用のGitHubリポジトリに保存する。これを積み重ねることで、チームの開発記録（航海日誌）が自動的に蓄積されていきます。
各セッション終了時 ↓ /report-session コマンドを実行 ↓ セッション内容を自動分析 ↓ Markdownファイルとして保存 ↓ チームの開発ログリポジトリに蓄積
そして、蓄積されたログを素材に、GitHub Actionsが週次サマリを自動生成してチームに通知します。
毎週月曜日（自動実行） ↓ GitHub Actions が先週のログを収集 ↓ Claude Code が週次サマリを生成 ↓ チームのチャットルームに通知
/report-sessionコマンドの仕組み
セッション記録はプラグインのカスタムコマンドとして定義されています。
/report-session
このコマンドを実行すると、以下の処理が自動的に行われます。
ステップ1：セッションのアクティブ時間を計測
Claude Codeのセッションは、ローカルの ~/.claude/projects/ 配下にJSONL形式のログファイルとして保存されています。このログをClaudeが自身で作成したPythonスクリプトで解析し、Claudeのアクティブ処理時間（ユーザーの入力待ち時間を除いた実作業時間）を計測します。
計測対象: ユーザーがメッセージ送信 〜 Claudeが応答完了 のスパン合計 除外対象: ユーザーの入力待ち時間
各ターンの所要時間と、ツール呼び出しのカテゴリ別集計（コード編集、コード調査、Jira/Confluence操作等）も出力されます。
ステップ2：セッション内の作業内容を分析
次に、セッション内で実際に行った作業を整理します。
- コード編集・作成: 編集したファイルと変更内容
- Gitコミット・プッシュ: コミットメッセージ、対象リポジトリ、ブランチ名
- プルリクエスト: 作成・レビューしたPRの番号とタイトル
- Jiraチケット更新: 更新したチケットと操作内容
- Q&A: ユーザーからの質問と回答内容、参照したファイル
重要なポイントは、外部のディレクトリ走査や検索を一切行わないことです。セッション内で実際に使用したツールの履歴とユーザーとの対話内容のみから判断するため、余分なコストをかけずに高速に実行されます。
ステップ3：Markdownファイルとして保存
分析内容を以下のフォーマットでMarkdownファイルにまとめ、開発ログリポジトリに保存します。
# [日付] [作業の要約] > ⏱️ セッション時間: 14:00 〜 17:30（合計 45.2分） ## 📝 コード編集・作成（実測: 18.3分） ### 編集したファイル - `src/auth/login.ts` - 変更内容: 認証エラー時のリトライ処理を追加 ## 🔄 Gitコミット・プッシュ ### リポジトリ: service-repo - **ブランチ**: `feature/TICKET-1234` - **コミット**: TICKET-1234: 認証エラー時のリトライ処理を追加 ## 🎫 Jiraチケット（実測: 3.1分） ### 更新したチケット - **TICKET-1234**: 認証エラー時のリトライ処理 - 実施した操作: 状態をDONEに変更 ## ✅ まとめ | カテゴリ | 時間 | |---------|------| | コード編集 | 18.3分 | | コード調査 | 15.7分 | | Jira/PR作業 | 3.1分 | | Q&A・議論 | 8.1分 | | **合計** | **45.2分** |
ファイル名には日付と作業内容の要約が含まれます。
logs/2026/03/2026-03-05-認証エラーリトライ処理実装.md
保存後は自動的にコミット・プッシュされ、チームの開発ログリポジトリに記録が蓄積されます。
GitHub Actionsによる週次サマリの自動生成
蓄積されたログを活用する仕組みが、GitHub Actionsのワークフローです。
ワークフローの全体像
on: schedule: # 毎週月曜日 9:00 JST - cron: '0 0 * * 1' workflow_dispatch: # 手動実行も可能（任意の基準日を指定） inputs: target_date: description: '基準日 (YYYY-MM-DD形式)'
毎週月曜日の朝9時（JST）に自動実行されます。手動実行も可能で、過去の週を指定してサマリを生成することもできます。
ワークフローの処理ステップ
1. 対象週のログファイルを収集
logs/YYYY/MM/ ディレクトリから、対象週（月曜〜日曜）のファイル名で始まるMarkdownを収集し、一つのファイルに結合します。
2. Claude Codeでサマリを生成
収集したログを素材に、Claude Codeがサマリを生成します。
GitHub Actionsのワークフロー内でClaude Codeを使用することで、複数のセッションログを横断的に分析し、チームとしての週次サマリを人間が読みやすい形で生成できます。
3. サマリをコミット・プッシュ
生成されたサマリは summaries/YYYY-W{week_num}-summary.md として保存されます。
4. チャットルームに通知
保存したサマリをチームのチャットルームに通知します。
[週次サマリ 2026-W10] 今週のハイライト - 認証エラー時のリトライ処理を実装（TICKET-1234） - ログイン画面のUIを改善（TICKET-1235） - インフラのTerraform設定を更新（TICKET-1236） ...
チーム開発への拡張：個人記録からチーム記録へ
ここで一度立ち止まって、個人利用とチーム利用の違いについて整理したいと思います。
Claude Codeを個人で使う場合、セッションログは自分のローカルマシンにあるJSONLファイルに蓄積されます。振り返りたい時に自分のログを検索すればよいので、外部への記録は必須ではありません。
しかし、チームでモブプログラミングをしている場合はどうでしょうか。
個人利用の場合
ログ → ローカルJSONL（自分だけが参照可能）
チーム利用の場合
ログ → 各ドライバーのローカルJSONL（バラバラ）
↕
チームとしての記録 → ???
この「???」の部分を埋めるのが、/report-sessionコマンドと開発ログリポジトリです。
ドライバーAのセッション → /report-session → 開発ログリポジトリ
ドライバーBのセッション → /report-session → 開発ログリポジトリ
ドライバーCのセッション → /report-session → 開発ログリポジトリ
↓
GitHub Actions が集約・サマリ生成
↓
チーム全体への通知
各メンバーが自分のセッション終了時に/report-sessionを実行するだけで、自然とチームの開発ログが積み上がっていく仕組みです。コマンドの定義はプラグインで共有されているため、チームメンバー全員が同じフォーマットで記録できます。
現在の活用例：休み明けの「先週何をやったっけ」を解決する
現在チームで実感している効果は、主に1つです。
休み明けに前週の作業を思い出すコストがゼロになった
かつて月曜日の朝は、「先週何をやったんだっけ」という状態から始まることが多くありました。Jiraのチケット一覧を眺め、プルリクエストのタイトルを確認し、コミットログをさかのぼる。それだけで15〜30分が過ぎていたこともあります。
今は月曜日の朝、チャットルームに週次サマリが届いています。
[週次サマリ 2026-W10] 今週のハイライト - TICKET-1234: 認証エラー時のリトライ処理を実装し、PRを作成 - TICKET-1235: ログイン画面のUIデザインを改善（レビュー対応含む） - TICKET-1236: Terraform設定のリファクタリング（3リポジトリ横断） 週間稼働時間（Claude Codeアクティブ時間の計測値） - 計測対象セッション: 8件 - 週間合計: 312分（5時間12分）
先週の内容を5秒で把握でき、ミーティングも記憶を手繰り寄せることなくすぐに本題に入れます。
将来的な活用の可能性
現状では「休み明けの週次確認」という1つのユースケースしか本格活用できていませんが、蓄積されたログには様々な活用の可能性があると感じています。
スプリントレトロスペクティブの下準備
チームが2週間スプリントを採用している場合、スプリント終了時に「今回のスプリントで何を達成したか」をまとめる作業が発生します。これをGitHub Actionsのworkflow_dispatchで指定期間のサマリを生成することで、レトロスペクティブの素材づくりを自動化できそうです。
新メンバーのオンボーディング支援
チームに新メンバーが加わった際、「このチームが普段どんな開発をしているか」を把握するのに、過去のログリポジトリが参考になるかもしれません。実際の開発ログを読むことで、ドキュメントだけでは伝わりにくい「チームの仕事の進め方」を具体的に理解できるのではないかと思っています。
開発ベロシティの可視化
各セッションのアクティブ時間が計測されているため、集計すれば「チームとしてClaude Codeが週に何時間稼働しているか」が定量的に把握できます。例えば、チケットの種別ごとの平均所要時間を分析したり、月次での作業量の推移を確認したりするといった使い方も考えられます。チームの生産性を継続的に可視化する手段として活用できる可能性があると思っています。
デイリースタンドアップの自動化支援
毎朝の進捗共有で「昨日何をしたか」を話す際、前日のセッションログが参照できれば準備が楽になります。将来的には、スタンドアップ開始前に前日ログのサマリを自動投稿するような仕組みも作れそうです。
知識ベースとの連携
チームでは別途、開発で得た知見をMarkdownファイルとして管理する知識ベースリポジトリを運用しています。セッションログと知識ベースを連携させることで、「この週にどんな新しい知見が知識ベースに追加されたか」をサマリに含めるといった活用も面白いかもしれません。過去のセッションから「似たような問題を以前解決したことがあるか」を検索する、といった使い方も将来的には考えられます。
まとめ：「Claude Codeが何をしたか」を記録に残す
チームでClaude Codeを本格的に使い込むほど、「AIがやったことの記録」という課題が浮かび上がってきます。Claude Codeが大部分の実装を担うようになると、モブワークを主体とした開発スタイルにおいては、個々のセッションに作業が埋もれ全体像が見えにくくなります。
今回紹介した仕組みは、この問題に対するチームとしての一つのアプローチです。
| 課題 | 解決策 |
|---|---|
| セッションが各ドライバーに散らばる | /report-session で共有リポジトリに集約 |
| 週の作業を振り返るコストが高い | GitHub Actions が自動でサマリを生成・通知 |
| Claude Codeの稼働状況が不透明 | アクティブ時間の定量計測 |
コマンドの定義はプラグインで共有されているため、チームメンバー全員が同じフォーマットで記録できます。また、GitHub Actionsのワークフローはリポジトリで管理されているため、チームで継続的に改善していくことができます。
まだ運用を始めたばかりで、活用できていない可能性が多く眠っていると感じています。蓄積されたログをどう活かすかについては、今後もチームで試行錯誤を続けていきたいと思っています。
Claude Codeとの開発体験は日々進化しており、「Claude Codeが何をしたか」を記録・活用する手段もまだまだ発展の余地があると感じています。引き続き、AIと人間がそれぞれの強みを活かして協調できる開発体制の構築を目指していきたいと考えています。
