Claude Codeを活用してスキル成長支援&成長見守りができる仕組みを作ってみた

これまでやってきた課題やその結果、現在のスキルレベルを考慮してAIが課題を生成
  ↓
自分が取り組む ←→ AIがコーチとして伴走
  ↓
AIが添削
  ↓
メモリー自動更新（スキルのステータス、課題履歴、メンター用レポート）
  ↓
週次レポート自動生成 → メンターとの1on1で使用

~/Desktop/PJ/skill-challenge/
├── CLAUDE.md                          # AIの振る舞いルール
├── exercises/                         # 課題格納
│   └── 001-read-and-review/
│       ├── task.md                    # 課題説明・評価観点・難易度
│       ├── result.md                  # 添削結果（AI生成）
│       ├── package.json
│       ├── tsconfig.json
│       ├── vite.config.ts
│       └── src/
│           ├── main.tsx
│           ├── App.tsx
│           ├── types/
│           ├── lib/
│           ├── hooks/
│           └── components/
└── reports/                           # メンター向け（人が読む場所）
    ├── mentor-report.md               # スキル全体像（累積）
    └── weekly/                        # 週次レポート（差分）
        └── 2026-03-06.md

~/.claude/projects/<project-path>/memory/   # AI内部データ
├── MEMORY.md                          # インデックス
├── skill-profile.md                   # スキルのステータス
└── challenge-log.md                   # 課題履歴

## 会話開始時（必ず実行）

1. メモリーファイル（MEMORY.md → 各ファイル）を読む
2. `exercises/` 内に `result.md` が存在しないディレクトリがあるか確認する
   - あれば「進行中の課題がある」と判断し、ユーザーに状況を確認する
   - なければ新規課題の生成が可能な状態
3. 今日が木曜日で、その週の週次レポートが未生成なら自動で生成する

## コーチング（課題取り組み中）

- 課題を出した後、いきなり完成回答を出させない。
  まず「読んだ順番と気になった点を共有して」と促す
- ユーザーから質問があれば答える。ただし直接的な答えは出さない
- 考え方のヒント、調べるべきキーワード、着眼点を示す
- ユーザーが完全に詰まっている場合は、段階的にヒントのレベルを上げる
  （方向性 → 具体的な観点 → 該当箇所の示唆）
- 答えそのものは、ユーザーが回答を提出するまで絶対に言わない

### 課題の構成ルール

- 実務ベースの構成にすること。package.json、tsconfig.json、
  ディレクトリ構成等を含め、実際のプロジェクトに近い形にする
- yarn install して動かせる状態が望ましい
- 実務で使われるライブラリ（zod, SWR, React Hook Form 等）も適宜含める
- 「src/ にファイルが数個あるだけ」のような非現実的な構成にしない
- 難易度に応じてプロジェクト規模を段階的に上げる

## 設計・アーキテクチャ

| スキル | ステータス | 備考 |
|---|---|---|
| コンポーネント設計（責務分離） | 定着 | Container/Presentational パターンを安定して使える |
| カスタムフック設計 | 成功1回 | 課題012: データフェッチをhookに切り出せた。エラー境界との連携が課題 |
| モノレポ構成の理解 | 学習中 | 課題015: packages/ の依存関係を読み解けなかった |

## テスト

| スキル | ステータス | 備考 |
|---|---|---|
| コンポーネントテスト（Testing Library） | 成功1回 | 課題014: userEvent でのフォーム操作テストを書けた |
| API モック（MSW） | 学習中 | 課題014: ハンドラ定義はできたが、エラーケースのモックを漏らした |
| E2E テスト（Playwright） | 未学習 | |

# 課題015: モノレポ構成の注文管理システムのコードリーディング & 機能追加

## 難易度: A

## 形式: コードリーディング + 穴埋め実装

## 評価観点（メンター向け）

この課題で確認するスキル：
- モノレポ構成（Turborepo + pnpm workspace）の理解
- OpenAPI 生成型の活用
- Server Components と Client Components の使い分け
- TanStack Query によるデータフェッチとキャッシュ戦略
- MSW を使ったテストの追加

## 状況設定

あなたはモノレポ構成の EC バックオフィスにアサインされました。
注文管理画面に「注文ステータスの一括変更機能」を追加してください。
API スキーマ（OpenAPI）は既に定義済みで、型は自動生成されています。

## やること

1. プロジェクト構成を読み、各 package の役割を説明する
2. 既存の注文一覧取得の実装を読み、データの流れを説明する
3. `PATCH /orders/bulk-status` エンドポイントに対応する
   フロント実装を追加する（API クライアント、hook、UI）
4. 追加した機能のテストを1つ書く

# 課題015: モノレポ構成の注文管理システム - 結果

- 日付: 2026-05-15
- 形式: コードリーディング + 穴埋め実装
- 難易度: A

## 課題の目的

モノレポ構成の理解、OpenAPI 生成型の活用、Server/Client Components の使い分け、
TanStack Query、テスト

## 結果

| 評価観点 | 結果 | 備考 |
|---|---|---|
| モノレポ構成の理解 | 部分的 | packages/ の役割は説明できたが、依存関係の解決順序（ビルド順）を説明できなかった |
| OpenAPI 生成型の活用 | OK | 生成された型を正しく import して使えた。手動で型を書かなかった |
| Server/Client Components | 部分的 | "use client" の配置は正しかったが、Server Component で取得→Client に渡すパターンを見落とした |
| TanStack Query | OK | useMutation + invalidateQueries でキャッシュ更新まで実装できた |
| テスト | 部分的 | MSW ハンドラは書けたが、楽観的更新のロールバックテストを漏らした |

## できたこと

- OpenAPI で生成された型を手動定義せず正しく使えた
- TanStack Query の useMutation → invalidateQueries のパターンを自力で実装
- MSW でAPIモックを定義してテストを書けた

## できなかったこと

- Turborepo のビルド依存グラフ（pipeline 設定）を説明できなかった
- Server Component でデータを取得して Client Component に渡す設計パターン
- 楽観的更新のテスト（エラー時のロールバック検証）

## 学んだこと（添削で伝えた内容）

- turbo.json の pipeline でビルド順序を定義する仕組み
- RSC でデータ取得 → Client Component に props で渡す設計の利点（バンドルサイズ削減）
- useMutation の onMutate / onError でロールバックを実装するパターン

# メンター向けレポート

## 現在のスキル総括

### できること（定着済み）
- React hooks 全般（useState, useEffect, useCallback, useMemo, useReducer）
- TypeScript の型定義・union 型・型ガード・ジェネリクス
- fetch / エラーハンドリング / zod バリデーション
- コンポーネント設計（Container/Presentational, カスタムフック切り出し）
- TanStack Query の基本（useQuery, useMutation, キャッシュ無効化）

### 学習中（理解はあるが実践で不安定）
- モノレポ構成（パッケージ間依存の理解が浅い）
- Server Components / Client Components の使い分け
- テストの網羅性（正常系は書けるが、エラーケース・エッジケースを漏らす）
- 楽観的更新のパターン

### 主要な弱点・課題
1. モノレポのビルドパイプライン（turbo.json）を理解していない
2. RSC でデータ取得 → Client に渡す設計パターンが身についていない
3. テストで「何をテストすべきか」の判断力が不足（正常系偏重）

## 成長の推移

| 課題 | 日付 | 特筆事項 |
|---|---|---|
| 001 | 2026-03-06 | コードリーディング初回 |
| ... | ... | ... |
| 012 | 2026-04-24 | カスタムフック設計を自力で実装。エラー境界連携は課題 |
| 014 | 2026-05-08 | Testing Library + MSW でテストを初めて書けた |
| 015 | 2026-05-15 | モノレポ初挑戦。OpenAPI 型活用・TanStack Query は問題なし |

## 推奨する強化領域（優先度順）
1. モノレポのビルドパイプラインとパッケージ間依存の理解
2. Server Components の設計パターン（RSC でフェッチ → Client に渡す）
3. テスト設計力（エラーケース・境界値・ロールバック）

# 週次レポート: 2026-05-15

対象期間: 2026-05-08 〜 2026-05-14

## 今週取り組んだ課題

| # | テーマ | 形式 | 難易度 | 結果サマリ |
|---|---|---|---|---|
| 014 | フォーム + テスト | 新規実装 | B | React Hook Form + zod + Testing Library + MSW で実装。エラーケーステストが不足 |
| 015 | モノレポ注文管理 | コードリーディング+実装 | A | OpenAPI型活用・TanStack Query はOK。モノレポのビルド依存とRSC設計が課題 |

## 今週できるようになったこと
- MSW でAPIモックを書いてテストを実行する一連の流れ
- TanStack Query の useMutation + invalidateQueries を自力実装
- OpenAPI 生成型を手動定義せず活用する習慣

## 今週も改善が見られなかったこと
- テストで「エラーケースも書く」という意識（正常系偏重が続いている）

## 来週の推奨フォーカス
- テスト設計力の強化（エラーケース・境界値の洗い出し方法）
- モノレポのビルドパイプライン（turbo.json の読み方）