← Reports へ戻る

AI開発で作業ログを残すメリット

Published 2026年6月22日
Author AI Media Lab
Category ai-technology

AI開発で何を頼んだか、何を変更したか、なぜ判断したかを残す作業ログの重要性。知的資産化とリスク低減を説明。

AI開発で作業ログを残すメリット

はじめに

AI との開発では、誰が何を判断したのか が曖昧になりやすいです。「なぜこのコードがあるのか」「なぜこの方針なのか」を記録する作業ログが、後の保守・拡張を大きく効率化します。本記事では、作業ログの重要性と運用方法を解説します。

作業ログがない場合の問題

1ヶ月後、バグが発生：

「なぜこのコードがあるのか」が不明
  ↓
「単なる古いコード？」「重要な制約対応？」
  ↓
勝手に削除 → 本番エラー
  ↓
原因調査に 2 時間以上

作業ログがある場合

開発ログから：
「このコード：キャッシング戦略
詳細は Issue #38 を参照」

→ 即座に背景理解
→ 適切に修正判定
→ 安全に変更可能

作業ログに記録すべき情報

1. 何を頼んだのか

## 日付：2026-06-22 14:00

### タスク
Claude Code にユーザープロフィール編集機能を実装

### 指示内容
- ファイル：src/components/UserProfile.tsx
- 機能：編集フォーム、バリデーション
- テスト：5 ケース以上

### Issue
#42 参照

2. AI からの提案・質問

### AI からの提案

Claude Code:
「バリデーションは既存の LoginForm を参考にしますか？」

ChatGPT:
「3 つの実装案：
  1. React Hook Form + Zod
  2. Formik
  3. シンプル setState

  推奨：案1（型安全性が最高）」

3. 人間の判断

### 人間の判定

判定者：yamada (Product Manager)

決定：案1（React Hook Form + Zod）採用

理由：
- 既存 LoginForm との統一
- TypeScript 型安全
- テスト容易性

4. 実装結果

### 実装結果

実装時間：90 分
ファイル数：2 (component, test)
行数追加：150 行

テスト結果：
- 自動テスト：全 pass
- ChatGPT レビュー：OK（小さな改善案あり）

5. 判断の背景

### 判断背景・制約

キャッシュ TTL = 5 分

理由：
- データ鮮度：プロフィール変更 → 5 分以内に反映必須
  （Issue #38 でユーザーから要望）
- パフォーマンス：TTL = 5 分で DB 負荷 70% 削減
  （ChatGPT パフォーマンス分析による）
- トレードオフ：短すぎるとキャッシュ効果薄い

代替案検討：
- 1 分キャッシュ：DB 負荷削減は 20% のみ
- 1 時間キャッシュ：データ鮮度落ちすぎる
  （Issue #38 で 5 分と決定）

作業ログの形式

形式1：毎日の開発日記

# 開発ログ - 2026-06-22

## Morning (9:00-12:00)

### タスク1：プロフィール編集機能実装
- Issue #42
- Claude Code に実装指示
  - 指示：表示＆編集フォーム
  - 実装時間：90 分
- テスト結果：全 pass
- ChatGPT レビュー：OK

### タスク2：バグ修正（null user handling）
- Issue #50
- ChatGPT でエラー分析
- Claude Code で修正実装
- テスト追加：3 ケース

## Afternoon (13:00-17:00)

### タスク3：ドキュメント更新
- ChatGPT に README ドラフト作成させた
- 人間が制約・既知の問題を追加修正

### 本日の成果
- 新機能 1 個実装
- バグ修正 1 個
- ドキュメント更新完了
- 全テスト pass

### 明日の予定
- パフォーマンス最適化（Issue #51）
- 多言語対応調査（Issue #43）

形式2：Issue 単位のログ

# Issue #42：ユーザープロフィール編集機能

## 開発期間
2026-06-20 ～ 2026-06-22

## 実装内容
ユーザーがプロフィールを編集できるコンポーネント

## AI の役割分担

### Claude Code
- UserProfile.tsx 実装
- テスト実装

### ChatGPT
- バリデーション方法の提案
- コードレビュー

### 人間
- 要件定義（フィールド、バリデーション）
- 判定（実装方針承認）
- 最終テスト

## 実装プロセス

1. 要件定義（人間）：1 時間
   - フィールド：ユーザー名、メール、自己紹介
   - バリデーション基準定義

2. ChatGPT に実装案提案させ（0.5 時間）
   - 3 個の案から案1 を選択

3. Claude Code が実装（2 時間）
   - Component + Test

4. レビュー・修正（1 時間）
   - ChatGPT レビュー指摘対応
   - エッジケーステスト追加

## 判断記録

### なぜ React Hook Form + Zod か
答え：Issue #42 コメントを参照
- ユーザーからの「簡単に使える」要望
- 既存 LoginForm との統一性
- TypeScript との相性

### なぜこのバリデーション基準か
答え：Issue #38 + ChatGPT 分析
- ユーザーは 500 字以上の自己紹介を書きたい
  （Issue #38 にユーザーの声）
- 制限なし or 1000 字制限のいずれかで検討
  （ChatGPT が DB ストレージ分析）
- 決定：500 字（バランス重視）

## テスト結果

- 単体テスト：12 ケース全 pass
- 統合テスト：OK
- ChatGPT セキュリティレビュー：OK

## 成果物

- src/components/UserProfile.tsx
- tests/components/UserProfile.test.tsx
- コミット：abc1234
  （コミット見出しに Issue #42 記載）

作業ログの活用シーン

シーン1：バグ対応

問題：プロフィール画面でエラーが発生

作業ログから：
「2026-06-22 に実装した Issue #42」
「バリデーション基準：500 字」
「ユーザーがこれ以上送信したら…」

→ 根本原因を素早く特定
→ 対応が正確で迅速

シーン2：機能拡張

要望：プロフィール画像もアップロードしたい

作業ログから：
「Issue #42 のスコープ：画像アップロードは対象外」
「画像機能は別 Issue #43 で検討中」

→ 既存スコープを超えない
→ 既存の Issue との関連が明確
→ 新規 Issue として適切に追加

シーン3：新規メンバーのオンボーディング

新規メンバー：「なぜこのバリデーション基準？」

作業ログから：
「Issue #38 にユーザー要望」
「ChatGPT パフォーマンス分析」
「人間が判定：500 字」

→ 背景が理解される
→ 同じ思考プロセスを辿れる
→ 信頼感が生まれる

作業ログの運用方法

保存場所

dev-logs/
  2026-06-22_issue-42_profile-edit.md
  2026-06-22_issue-50_null-user.md
  daily-log-2026-06.md

テンプレート

# [Issue タイトル] (#ID)

## 日付
開発実施日

## タスク概要
1 段落で説明

## AI の役割分担

### Claude Code
- 実装内容

### ChatGPT
- 分析・提案内容

### 人間
- 判断内容

## 判断記録

### 決定1
- 何を決めたか
- 代替案と選ばない理由
- 参考情報

## 成果物

## テスト結果

## 次回の課題

まとめ

AI 開発では、作業ログが 知識資産 になります。

作業ログの価値：

即時：

中期：

長期：

ログ作成パターン：

AI 開発でコミットメッセージをどう書くべきかと合わせることで、開発履歴が完全に可視化され、プロジェクト全体の信頼性が大幅に向上します。

ドキュメント作業ログ知識管理AI開発