キャップストーン：完全な機能を構築する

🔄 前回のおさらい: レッスン7で高度なワークフロー——プログレッシブリファインメント、コードレビューパートナー、大規模リファクタリング、TDD、ラバーダックデバッグを学びました。ここですべてを統合して、完全な機能を構築します。

完全なワークフロー

すべてをまとめる時です。このコースのすべてのテクニックを使って、完全な機能を構築するプロセスを歩きましょう。

これはおもちゃの例ではありません。本番コードで実際に使うワークフローです。

対象機能：APIレートリミッティング

Express.js APIにレートリミットを追加します。要件：

ユーザー単位のリクエスト制限（APIキー別）
設定可能なリミット（1分あたりのリクエスト数）
超過時に適切な429レスポンスを返す
管理者ユーザーのバイパス
分散デプロイ向けのRedisバックエンド
包括的なテスト

構築しましょう。

フェーズ1：計画

まだコードに触らない。先に計画。

> Express.jsアプリにAPIレートリミットを追加する必要がある。
> 要件：
> - APIキーによるユーザー単位の制限
> - 設定可能なリミット
> - 適切な429レスポンス
> - 管理者バイパス
> - Redisバックエンド
> - フルテストカバレッジ
>
> 実装の概要を出して：
> 1. 作成するファイルは？
> 2. 変更する既存ファイルは？
> 3. 実装の順序は？
> まだコードは書かないで。

Claudeが計画を出す。レビュー。質問する：

> なぜインメモリではなくRedis？両方サポートしたい場合は？

> 管理者バイパスはどう実装する？ヘッダーチェック？DB参照？

実装前にアラインメントを取る。

フェーズ2：コンテキストセットアップ

フェーズ3：コア実装

レートリミッターを構築：

> src/middleware/rate-limiter.jsにレートリミットミドルウェアを作成して
>
> 計画に基づく要件：
> - トークンバケットアルゴリズム
> - Redisストレージ（インメモリフォールバック付き）
> - configからの設定可能なリミット
> - Retry-Afterヘッダー付き429レスポンス
>
> 既存のミドルウェアファイルのパターンに従って。

Claudeがミドルウェアを作成。レビュー：

> トークンバケットのリフィルの仕組みを説明して。

> Redisが利用不能な時はどうなる？

問題を修正：

> フォールバックロジックが正しくない。Redis障害時は：
> - エラーをログ
> - インメモリにフォールバック
> - リミットチェックは継続
> これを修正して。

フェーズ4：テスト

統合前にテスト作成：

> tests/middleware/rate-limiter.test.jsにテストを作成して
>
> テストケース：
> - リミット未満のリクエストを許可
> - リミット超過のリクエストをブロック
> - 正しい429レスポンスとRetry-Afterヘッダー
> - 管理者バイパスが機能する
> - Redis障害時のフォールバック
> - ウィンドウ経過後のリミットリセット

テスト実行：

> テストを実行して。すべてパスするはず。

✅ 確認クイズ: 完全な機能構築で「計画→実装→テスト→統合」の順序が重要な理由は？→計画で方向性を合わせ、実装でコアを作り、テストで品質を担保し、統合で全体をつなぐ。逆順や同時進行だと、間違った方向に進んでしまったり、問題の発見が遅れたりします。特に計画フェーズのスキップが最大のリスク。

フェーズ5：統合

ワイヤリング：

/add src/app.js
> レートリミッターミドルウェアを統合して。
> - 認証ミドルウェアの後にグローバル適用
> - リミット値はconfigから使用
> - ミドルウェアチェーンの正しい位置に追加

設定を追加：

/add src/config/index.js
> レートリミット設定を追加して：
> - RATE_LIMIT_WINDOW_MS（デフォルト60000）
> - RATE_LIMIT_MAX_REQUESTS（デフォルト100）
> - RATE_LIMIT_ADMIN_BYPASS（デフォルトtrue）

フェーズ6：エッジケース

堅牢化：

> レートリミッターのエッジケースをレビューして：
> - APIキーがない場合は？
> - APIキーが不正な形式の場合は？
> - 分散環境での競合状態は？
> - リミット設定が無効な場合は？
>
> ギャップがあれば対処して。

フェーズ7：最終レビュー

コミット前にフルレビュー：

> 構築したすべてをレビューして：
> - src/middleware/rate-limiter.js
> - tests/middleware/rate-limiter.test.js
> - src/app.jsとconfigの変更
>
> 問題は？テストケースの漏れは？潜在的なバグは？

最終テスト実行：

> すべてのテストを実行。すべてパスすることを確認。

フェーズ8：コミット

クリーンなgit履歴：

git add src/middleware/rate-limiter.js
git commit -m "feat: Redisストレージ付きレートリミットミドルウェアを追加"

git add tests/middleware/rate-limiter.test.js
git commit -m "test: レートリミッターのテストカバレッジを追加"

git add src/app.js src/config/index.js
git commit -m "feat: レートリミッターをグローバルに統合"

各コミットが独立してリバート可能な論理的単位。

コースの振り返り

8レッスンを通して学んだこと：

レッスン	学んだこと
1. イントロダクション	メンタルモデル：質問ではなく指示する
2. コアコマンド	毎日使う必須スラッシュコマンド
3. コンテキスト管理	より良いレスポンスのための戦略的ファイルロード
4. タスクオーケストレーション	複雑な作業の分解と順序付け
5. ファイル操作	安全で効率的なファイル操作
6. Bash統合	シェルコマンドによるインテリジェント自動化
7. 高度なワークフロー	本格的な開発のプロフェッショナルパターン
8. キャップストーン	すべてを組み合わせた実践

6つの原則

コンテキストがすべて。 量より質。
実装前に計画。 特に非自明なものは。
やり直しではなく反復。 うまくいった部分を活かす。
継続的に検証。 テストは早く、頻繁に。
Gitがセーフティネット。 こまめにコミット、簡単に巻き戻し。
適切なレベルの指示。 タスクの複雑度に合わせる。

まとめ

完全な機能構築は計画→コンテキスト→実装→テスト→統合→エッジケース→レビュー→コミットの順序で進める
各フェーズに明確なゴールと検証ポイントがあり、問題を早期に発見できる
プログレッシブリファインメント——まず動かし、テストし、堅牢化し、本番品質に仕上げる
Gitをセーフティネットとして活用し、論理的な単位でクリーンにコミットする
Claude Codeの真価は単発の質問ではなく、ワークフロー全体のオーケストレーションにある——コンテキスト管理、タスク分解、反復改善を組み合わせて10倍速い開発を実現する