きまぐれでAIに書かせた作業ログがチームの振り返りやADRに使えるかも・・・?

株式会社カミナシで VPoE を務めている pospome です。 (´・ω・`)

プライベートの時間で勉強がてらWebアプリケーションを作っているのですが、きまぐれでClaude Codeに作業記録を書いてもらっていました。最初は「前回何やったっけ?」を思い出すためのメモ程度だったのですが、これがチーム開発でも意外と活用できそうだなと思ったので、記事にしてみます。

作業記録とは?

作業記録はAIに書かせるドキュメントで、実体としては以下のようなマークダウンファイルです。

作業記録の例

# TypeScript / React 向け Prettier を導入した

**日付：** 2026-04-08
**作業時間：** 約9分

## 背景・目的

プロジェクトの TypeScript / React コードにフォーマッターが導入されておらず、コードスタイルが統一されていなかった。コミット時に自動でフォーマットされる仕組みを整えるため、フォーマッターを導入した。

## やったこと

`apps/web` に Prettier を導入し、lint-staged と連携させた。

フォーマッターの選定にあたり、Biome と Prettier を比較した。Biome は linter と formatter の両方を備えたツールだが、プロジェクトには既に ESLint が導入済みであり、役割が重複する。今回は formatter のみが必要だったため、シンプルに導入できる Prettier を採用した。

設定はデフォルト（空オブジェクト）とし、ESLint の ignores と同じディレクトリを `.prettierignore` に記載した。lint-staged では Prettier → ESLint の順に実行するよう構成し、フォーマット後に lint が走る流れにした。

## 結果

`apps/web` 配下の TypeScript / React コードが Prettier でフォーマットされるようになった。コミット時には lint-staged 経由で自動フォーマットが実行される。既存コードにもフォーマットを適用済みで、`hello.tsx` と `openapi.yaml` の2ファイルに変更があった。

## 変更したファイル

- `apps/web/package.json` — prettier の追加、format / format:check スクリプトの追加
- `apps/web/.prettierrc.json` — Prettier 設定ファイル（デフォルト設定）
- `apps/web/.prettierignore` — フォーマット対象外の指定
- `package.json` — lint-staged に Prettier を追加（Prettier → ESLint の順で実行）
- `apps/web/app/routes/hello.tsx` — Prettier による自動フォーマット
- `apps/web/typespec/tsp-output/openapi.yaml` — Prettier による自動フォーマット

## 残課題

なし

プライベートで開発作業をしていると、確保できる時間が細切れになりがちなんですよね。仕事終わりに1時間やって、次に触るのは週末...みたいなことがよくあります。そうなると「前回何をやったのか」を忘れるんです。この課題を解決するために、なんとなく作業記録をつけ始めました。

Claude Codeの1セッションにつき1ドキュメントという単位になっていて、作業が一通り終わったタイミングで作業記録を書いてもらっています。

作業記録の生成は以下のようにSkill化しています。

Skillファイル

今回の会話の作業内容をもとに、以下のフォーマットで作業履歴ドキュメントを作成してください。

## ファイルパス

`task-history/YYYYMMDDHHmm-タイトル.md` の形式で保存する。
- 日付時刻は現在の JST 日時（時分まで含める）
- タイトルは作業内容を表す短い英語のスラッグ（例: `react-router-setup`）

## ドキュメントのフォーマット
\```
# タイトル（日本語）

**日付：** YYYY-MM-DD
**作業時間：** 約XX分

## 苦戦レベル

（自分で記入する）

## 背景・目的

なぜこの作業を行ったか。

## やったこと

作業内容の概要。

## 結果

作業の結果どうなったか。

## 問題と解決

（ハマったことがあれば記載。なければセクションごと省略）

**問題：** 何が起きたか。

**原因：** なぜ起きたか。

**対処：** どう解決したか。

## 変更したファイル

- `path/to/file` — 変更内容の一言説明

## コミットハッシュ

- `commit_hash` — コミットメッセージの要約

## 残課題

（あれば記載。なければ「なし」）
\```

## 作業時間の計算

`task-history/.session-start` に作業時間のセグメントが記録されている（SessionStart hook および `/taskhistory-pause`・`/taskhistory-resume` コマンドによる記録）。

### ファイル形式

\```
start <unix_timestamp>
pause <unix_timestamp>
start <unix_timestamp>
\```

- `start` 行は計測開始、`pause` 行は計測停止を意味する
- SessionStart hook がセッション開始時に最初の `start` 行を書き込む
- `/taskhistory-pause` で `pause` 行を追記、`/taskhistory-resume` で `start` 行を追記する

### 計算方法

1. ファイルを読み取り、各行を順に処理する
2. `start` と `pause` のペアごとに `pause - start` を計算して合算する
3. 最後の行が `start`（現在計測中）の場合は `現在時刻 - start` を加算する
4. 合算した秒数を分に変換し「約XX分」として記載する

ファイルが存在しない場合は「不明」と記載する。

## コミットハッシュの取得

`git log` で今回の会話中に作成されたコミットを取得し、「コミットハッシュ」欄にフルハッシュで記載する。
コミットが存在しない場合は「なし」と記載する。

## 注意事項

- 作業履歴はコミット後に作成すること。成果物をコミット → 作業履歴を作成（コミットハッシュを記載）→ 作業履歴をコミット、の順で行う
- 「問題と解決」は実際にハマった問題がなければセクションごと省略してよい
- 「変更したファイル」は主要なものだけ記載すれば十分
- 文体は簡潔に、箇条書きより文章を優先する
- ツール選定や設計方針など議論・比較を行った点は、何を選び何を選ばなかったか、その理由を具体的に記載する

どう活用するのか?

ここからは、この作業記録をどう活用できるのかについて書いていきます。

前回どのような作業をやったか確認する

これは元々の動機そのままですね。前回の作業記録をサッと見れば、どこまで進んだのか、何をやっていたのかがすぐにわかります。自分の場合はプライベート開発なので細切れの時間で作業することが多いわけですが、チーム開発でも同じような場面はあるんじゃないかなと思います。例えば、長期休暇明けに「あれ、このタスクどこまでやったっけ...」みたいな状況ですね。

作業の振り返り

Claude Codeに「先週やったことを要約して」という指示を出すと、作業記録をもとに "何をやったのか"、"それぞれにどのくらいの時間がかかったのか" を振り返ることができます。

もしくは以下のように時系列にやったことを並べて画像化してもらうこともできます。

タイムライン作成のSkill

指定された期間の作業履歴からタイムライン図（SVG + PNG）を生成する。

## 引数

`$ARGUMENTS` で期間を指定する。

- `2026-04` — 特定の月
- `2026-04 2026-06` — 月の範囲（開始月〜終了月）
- 引数なし — 当月

## 手順

### 1. 期間の決定

引数を解析して対象期間を決定する。ファイル名の先頭8桁（YYYYMMDD）で絞り込む。

### 2. 作業履歴ファイルの読み取り

`task-history/YYYYMMDD*.md` にマッチするファイルを Glob で取得し、対象期間内のものを抽出する。各ファイルから以下を読み取る。

- **日付**: ファイル名の先頭8桁（YYYYMMDD）
- **タイトル**: マークダウンの `# ` 見出し（1行目）
- **作業時間**: `**作業時間：**` 行の値。「不明」の場合はそのまま
- **カテゴリ**: ファイルの内容からカテゴリを判定する（後述）

### 3. カテゴリの判定

作業内容に基づき、以下の4カテゴリに分類する。タイトルと「やったこと」セクションの内容から判断する。

| カテゴリ | 判定基準（例） | 背景色 | 枠線色 |
|---------|-------------|--------|--------|
| 開発環境 | Dev Container、ツール導入、設定変更、CI/CD | `#DBEAFE` | `#3B82F6` |
| Lint / Format | Linter、Formatter、コード品質ツール | `#DCFCE7` | `#22C55E` |
| ドキュメント | PRD/Design Doc/ADR のテンプレート、戦略、フォーマット | `#FEF3C7` | `#F59E0B` |
| 機能開発 | 特定機能の PRD 作成、Design Doc 作成、実装 | `#F3E8FF` | `#A855F7` |

上記に当てはまらない場合は、最も近いカテゴリに割り当てる。カテゴリが5つ以上必要な場合は適切な色を追加してよい。

### 4. データの整理

同じ日付の作業をグループ化する。各日付ごとに:
- 作業項目を時系列順に並べる（ファイル名の時刻部分でソート）
- 作業時間を合算する（「不明」が含まれる場合は「不明」とする。全て「不明」の場合も「不明」）

### 5. SVG の生成

以下のレイアウト仕様に従って SVG を生成し、`docs/timeline-{期間}.svg` に保存する。

#### レイアウト仕様

```
定数:
  BOX_W = 270        # アイテムボックスの幅
  BOX_H = 40         # アイテムボックスの高さ
  BOX_GAP = 8        # ボックス間の垂直ギャップ
  DAY_SPACING = 370  # 日付間の水平スペース
  TIMELINE_Y = 400   # タイムライン軸の Y 座標
  START_GAP = 16     # タイムラインとボックス間のギャップ
  FIRST_CX = 190     # 最初の日付の X 中心

日付の X 座標:
  cx[i] = FIRST_CX + i * DAY_SPACING

ボックスの Y 座標（下から上に積み上げ、idx=0 が最下段）:
  rect_y[idx] = TIMELINE_Y - START_GAP - BOX_H - idx * (BOX_H + BOX_GAP)
             = 344 - idx * 48

SVG サイズ:
  width = FIRST_CX + (日数 - 1) * DAY_SPACING + FIRST_CX
  height = 500
```

#### SVG 構造

テキスト折り返し防止のため、`<rect>` と `<text>` は必ず別の `<g>` グループに分離する。

```xml
<svg>
  <defs><style>
    text {
      font-family: 'Noto Sans CJK JP', 'Noto Sans JP', -apple-system,
                   'Helvetica Neue', Arial, sans-serif;
      white-space: nowrap;
    }
  </style></defs>

  <!-- 1. タイトル -->
  <!-- 2. 凡例 -->
  <!-- 3. タイムライン軸（横線 + 矢印） -->
  <!-- 4. 日付ドット・日付ラベル・作業時間ラベル -->
  <!-- 5. アイテム背景 <g id="backgrounds"> — rect のみ -->
  <!-- 6. アイテムラベル <g id="labels"> — text のみ -->
  <!-- 7. フェーズ括り線 <g id="phases"> -->
</svg>
```

#### 日付ラベルの下に作業時間を表示

各日付ラベル（font-size="14", y=432）の下に、その日の合計作業時間を表示する。
- font-size="11", fill="#9CA3AF", y=449
- 数値がある場合: `XX分`
- 不明の場合: `（不明）`

### 6. PNG への変換

以下のコマンドで SVG を PNG に変換する。

```bash
npx --yes resvg-cli <input.svg> <output.png> \
  --dpi 144 \
  --font-dir /usr/share/fonts/opentype/noto \
  --font-default-family 'Noto Sans CJK JP'
```

日本語フォント（fonts-noto-cjk）がインストールされていない場合は、先に以下を実行する。

```bash
sudo apt-get update -qq && sudo apt-get install -y -qq fonts-noto-cjk
```

### 7. 出力ファイル

- SVG: `timeline/{期間}.svg`
- PNG: `timeline/{期間}.png`

期間の形式:
- 単月: `2026-04`
- 範囲: `2026-04-to-2026-06`

ディレクトリが存在しない場合は作成する。

生成完了後、PNG のパスをユーザーに伝える。

これらはスクラムの振り返りとかで使えそうなんですよね（特に時系列のやつ）。スプリント中にやったことを人間がまとめるのは意外と手間ですし、記憶に頼ると抜け漏れが出たりします。作業記録が溜まっていれば、AIに「今スプリントでやったことをまとめて」と言うだけで振り返りの材料が出てくるわけです。

意思決定の履歴を残す

作業記録には、作業中の意思決定が残されています。「AとBの方法があったけど、こういう理由でAを選んだ」みたいなやつですね。これがADR（Architecture Decision Records）のような役割を果たしてくれます。

日々の細かい意思決定をわざわざADRに記録するのって、正直なところ面倒ですし、忘れがちだったりします。でも、作業記録の中にAIが勝手に記録してくれるのであれば、あとからClaude Codeで「このモジュールの設計判断ってどういう経緯だっけ?」と検索できるわけです。意思決定を記録する仕組みとしてはかなり楽なんじゃないかなと思います。ADRとして残したいのであれば、ADRとしてエクスポートしてもらえればいいわけです。

見積もりに活用できる

作業記録には作業時間が記録されているので、過去の作業記録を参考に「何にどのくらいの時間がかかりそうか」を見積もれるかもしれません。

もちろん、ソフトウェア開発の見積もりは過去の実績だけで正確にできるものではないですが、「前に似たような作業をやったとき、これくらいかかったな」というデータがあるのとないのとでは、見積もりの精度がだいぶ変わってくるんじゃないかなと思います。

残課題の整理

作業記録には「残課題」というセクションがあります。ここには「これやりたいけど、今はやらなくていいか」というものを記録しています。

作業中に気づいた改善点やリファクタリングしたい箇所って、その場で対応しないとそのまま忘れ去られることが多いんですよね。作業記録に残課題として記録しておけば、Claude Codeに指示して定期的に残課題を確認したり、JIRAなどのタスク管理システムにエクスポートしたりすることもできます。「やりたいけど今じゃないもの」の取りこぼしを防げるのは地味にありがたいです。

（補足）作業時間の算出方法

作業時間は「Claude Codeのセッションが始まった時間を開始時刻」「作業記録を書くときの時間を終了時刻」としています。厳密な作業時間ではないですが、大体の目安としては十分かなと思います。

作業中に離席することもあるので、Pause/Resume 用のSkillを作りました。

Pause用のSkill

作業時間の計測を一時停止する。

`task-history/.session-start` に `pause <現在のUNIXタイムスタンプ>` を追記すること。

## 手順

1. `task-history/.session-start` ファイルが存在するか確認する。存在しない場合は「セッションが開始されていません」と伝えて終了する
2. ファイルの最終行を確認する。最終行が `pause` で始まる場合は「すでに一時停止中です。再開するには /taskhistory-resume を実行してください」と伝えて終了する
3. `echo "pause $(date +%s)" >> task-history/.session-start` を実行する
4. 「作業時間の計測を一時停止しました。再開するには /taskhistory-resume を実行してください」と伝える

Resume用のSkill

作業時間の計測を再開する。

`task-history/.session-start` に `start <現在のUNIXタイムスタンプ>` を追記すること。

## 手順

1. `task-history/.session-start` ファイルが存在するか確認する。存在しない場合は「セッションが開始されていません」と伝えて終了する
2. ファイルの最終行を確認する。最終行が `start` で始まる場合は「すでに計測中です。一時停止するには /taskhistory-pause を実行してください」と伝えて終了する
3. `echo "start $(date +%s)" >> task-history/.session-start` を実行する
4. 「作業時間の計測を再開しました」と伝える

まとめ

AIは非構造化されたデータを扱えるので、作業記録のような1次情報も用途に合わせて抽出できるのはとても便利ですね。 今回の件に限らず、AI活用は個人や組織の生産性を大きく左右するので、「なにかできることないかなー」というアンテナを常に張っていたいなーと思いました。

宣伝

株式会社カミナシでは以下のポジションをすごく募集しています。 興味のある方は応募してみてください。