効率化パターン

問題点: ほぼ同じ機能を一つずつリリースすると、何時間もの作業が無駄になり、コードの一貫性が失われていきます。

すぐできる改善: このブロックをCLAUDE.mdに貼り付けてください。Claude が読んだ瞬間から一貫性が向上します。

# Component Generation Framework
 
When creating new [cards/forms/modals], follow the pattern in /components/examples/:
 
1. Copy the closest existing example
2. Replace data fields (keep structure identical)
3. Update types to match new data model
4. Run existing tests as template for new tests

このような短いルールを書いておくだけで、Claude がリポジトリ内にすでに存在するパターンを再発明しようとするのを防げます。

置換フレームワークとは何か

置換フレームワークは一種のトリックです。8〜12個の近い類似機能を手動でビルドし、Claude が同じ型からバリエーション11、12、13を生成できるCLAUDE.mdテンプレートを作成します。パターンは一度記録するだけです。残りはすべてClaudeが埋めてくれます。

あなたの役割が変わります。各機能のコーディングをやめ、Claude が既存の優れた設計図から生成したバリエーションをレビューするようになります。

3つのフェーズ

フェーズ1: 手動による基盤構築

まず、8〜12個の近い類似機能を自分でコーディングします。作業を進める中で、すべての判断、パターン、制約を記録します。その記録が後でClaudeが学習する参照ライブラリになります。

# Track your patterns
mkdir patterns/user-interfaces
# Build: LoginForm, SignupForm, ProfileForm, etc.
# Document decisions in each component

SaaSダッシュボードでいくつかのデータテーブルを持つ場合を具体例にしましょう。UsersTable、OrdersTable、InvoicesTable、ProductsTable。最初の3つは手動でビルドします。ラウンドを重ねるごとに、同じ判断が繰り返し浮上します。列の形状、ソートハンドラーのシグネチャ、ページネーションコンポーネント、空の状態レイアウト、ローディングスケルトン。

3ラウンド目には、インスタンス間で変わるもの（列定義、データ型、APIエンドポイント）と固定されているもの（テーブルラッパー、ページネーションロジック、ソート状態、行選択）を明確にできます。その棚卸しがフェーズ2の材料になります。

以前（各テーブルをゼロから構築）:

// Each table re-implements pagination, sorting, selection...
// UsersTable: 180 lines
// OrdersTable: 195 lines (slightly different pagination)
// InvoicesTable: 210 lines (different sort logic)

以後（パターンを抽出後）:

// Shared DataTable component: 120 lines
// UsersTable config: 35 lines (just column definitions + endpoint)
// OrdersTable config: 40 lines
// InvoicesTable config: 38 lines

フェーズ2: パターンの認識とテンプレート化

手動ビルドを見直して以下を抽出します。

• すべての実装に登場する繰り返しのコード構造
• インスタンスごとに変わる可変要素
• 品質ガードレール（型安全性、アクセシビリティ、テストカバレッジ）
• 各新しいバリエーションが実際に動作することを確認するチェック

次に、それらのパターンを実際の合格例と不合格例とともにエンコードするCLAUDE.mdセクションを書きます。重要なのは具体性です。「既存のパターンに従ってください」は不十分です。ファイルを直接指定します。「UsersTable.tsxの12〜28行目のプロップインターフェースをそのまま使用し、エンティティ型を置き換えてください」のように。

弱いフレームワーク指示:

Create new table components following existing patterns.

強いフレームワーク指示:

# Data Table Framework
 
Reference: /components/tables/UsersTable.tsx (canonical)
 
To create a new [Entity]Table:
 
1. Props: { columns: ColumnDef<Entity>[], endpoint: string, defaultSort: SortConfig }
2. Use DataTable wrapper from /components/shared/DataTable.tsx
3. Column definitions follow the format in UsersTable lines 12-28
4. Include loading skeleton matching the column count
5. Empty state uses /components/shared/EmptyState.tsx with entity-specific message
6. Tests: copy UsersTable.test.tsx, replace User fixtures with [Entity] fixtures

具体性がすべての違いを生みます。強いバージョンは正確なファイル名、行番号、共有コンポーネントを指定しています。Claude が推測する必要はありません。検証済みのパスを歩むだけです。

フェーズ3: 自動生成

フレームワークを使い始めます。簡単なケースから始めて、Claude が制約の範囲内に収まることを確認しながら難易度を上げていきます。

最初に生成されたバリエーションが完璧に返ってくることはほとんどありません。手動例と行ごとに比較すると、フレームワークが十分に具体的でなかった1〜2箇所が見つかります。その箇所を修正し、再生成し、繰り返します。3〜4回のパスの後、フレームワークは手作業での編集なしにレビューを通過するコードを出力するようになります。

フレームワーク改善戦略

制約ベースの品質管理

厳格なフレームワークルールは、有用な変化を排除せずにClaudeの創造的な範囲を狭めます。CLAUDE.mdの中で制約を明確に記述します。

CONSTRAINTS:
 
- All components must include PropTypes / TypeScript interfaces
- Use established naming conventions (camelCase for props)
- Include accessibility attributes (aria-label, role, tabIndex)
- Follow existing file structure in /components/
- Every new component gets a co-located test file

バリアンステスト

5〜10個のバリエーションを生成して並べて比較し、フレームワークにストレスをかけます。バリエーションが大きく離れすぎている場合は、CLAUDE.mdテンプレートに戻り、より鋭い例と厳格な制約を追加します。

APIエンドポイントフレームワークを使った具体的な実行例で問題が明らかになりました。最初の3つの生成エンドポイントでは、エラー処理は一定でしたが、レスポンスの形状が分岐しました。一つは{ data: ... }として返ってきました。別のものはペイロードを{ result: ... }としてラップしました。3つ目はラッパーなしで生のオブジェクトを返しました。フレームワークに一行追加するだけですべてが解決しました。「すべてのエンドポイントは{ data: T, error: null }または{ data: null, error: ErrorShape }を返す。」次の8回の生成からバリアンスが消えました。

反復的な改善

フレームワークのパスを重ねるごとに、Claude がどれだけパターンを守るかと、AIが生成したコードを信頼できるものにする要素について、あなたの理解が同時に深まります。

置換フレームワークの実践

具体的な実行例を見てみましょう。UserCard、ProductCard、OrderCardを手動でビルドしたとします。これをCLAUDE.mdに追加します。

# Card Component Framework
 
Reference: /components/cards/UserCard.tsx (canonical example)
 
To create a new [Entity]Card:
 
1. Props: { data: [Entity], onClick?: () => void, variant?: 'compact' | 'full' }
2. Structure: Avatar/Icon + Title + Subtitle + Action buttons
3. Styling: Use existing Tailwind classes from UserCard
4. Tests: Copy UserCard.test.tsx, replace User with [Entity]

Claude に「SubscriptionCardを作成してください」と依頼すると、出力は同じ形状に合わせてくれます。同じプロップ構造、同じスタイリングアプローチ、同じテストカバレッジ。手動でビルドしたカードと区別がつかないでしょう。なぜなら、同じ設計図から生まれたからです。

一般的な効率化パターン

APIエンドポイント: マッチしたエラーハンドリング、バリデーション、レスポンス形状を持つルートのフレームワーク。Zodスキーマパターン、エラーレスポンス形式、ミドルウェアチェーンを一度ずつロックダウンします。新しいエンドポイントは1時間から15分に短縮されます。

UIコンポーネント: 異なるデータ型を扱うデザインシステムコンポーネントのフレームワーク。上のカード例は、モーダル、フォーム、リストアイテム、詳細ビューにそのまま適用できます。コンポーネントがすでに3つ以上のバリエーションで存在する場合は、フレームワーク化の対象になります。

データベース操作: モデル間で共有されるトランザクション処理を持つCRUDのフレームワーク。クエリビルダー、ページネーションアプローチ、ソフトデリートの動作を一度定義します。新しいモデルは同じレール上に載るだけです。

フレームワークを構築しない場合

フレームワークはタダではありません。コードのオーバービルドと同じように、フレームワークのオーバービルドもコストがかかります。

例が1〜2つでは少なすぎます。 3つの手動ビルドが最低ラインです。2つだと、フレームワークがその正確なケースに縛られて汎化されません。

一度きりの機能にはフレームワークを使わないでください。 類似したものがない単一のカスタム管理ダッシュボードは、オーバーヘッドを増やすだけで何も返しません。フレームワークの予算は繰り返すパターンのために取っておきます。

パターンが安定するまで待ちます。 プロジェクトの最初の1か月は、コンポーネントの形状が週ごとに変わります。1週目にロックインされた厳格なテンプレートは、2週目に手直しが必要になります。8〜10回の手動ビルドで形状を確定させてからにしましょう。

過度な制約を避けます。 ルールが厳しすぎて、Claude が実際のバリエーションに対応できない場合、フレームワークは与えるものよりコストが大きくなります。良い制約は構造をロックしながら、エンティティ固有の詳細には余裕を残します。

フレームワークの成功指標

フレームワークが価値を生み出していることを確認するために、次の指標を監視します。

• 一貫性スコア: 生成されたバリエーションが、インポート、プロップ形状、ファイルレイアウトで手動ビルドと一致しているか？健全なフレームワークは構造的一致において高いスコアを出します。
• 実装速度: 調整されたフレームワークは、リクエストから動作する機能への道のりを明らかに短縮します。実際のスピードアップがなければ、さらなる詳細が必要か、パターンがまだ固まっていません。
• レビュー時間: 検証パスにどのくらいの時間がかかるか？その数値はフレームワークが成熟するにつれて下がるはずです。初期の出力は慎重なレビューが必要です。成熟した出力は正確性を確認する素早い読み取りだけが必要です。
• バグ頻度: 生成されたバリエーションごとのバグ数と、手動ビルドの機能ごとのバグ数を比較します。優れたフレームワークは、すでにフィールドテスト済みのパターンを組み込むため、バグ数を下げます。

線形から指数関数的なスケーリングへ

従来の開発は線形にスケールします。一人の開発者が一度に一つの機能を生産します。置換フレームワークはその数式を書き換えます。単一のフレームワークが多くのバリエーションを生産し、速度が上がります。

最大の恩恵は、繰り返しのパターンが異なるユーザーに提供されながら同じ技術的な型を共有するコードベースにあります。そこからリターンが複合的になります。コンポーネント、APIエンドポイント、データベース操作のフレームワークが揃えば、3層すべてにまたがる新しい機能は、各層にすでに設計図が待っているため、以前の時間のわずかな時間でリリースできます。

次のアクション:

1. 今日: リポジトリで3つの近い類似コンポーネントを探します。カード、フォーム、モーダルが最も始めやすい場所です。
2. 今週: それらの類似コンポーネント間で何が固定されているかを書き出すことで、最初のフレームワークを作成します。
3. 深堀り: フレームワークのドキュメントを効果的にするCLAUDE.mdのテクニックを学びます。
4. 関連: フレームワークのリクエストが複雑になったときはプランニングモードを活用します。
5. 最適化: コストと品質のバランスを調整するためにモデル選択戦略を使います。
6. 自動化: フィードバックループを設定して改善が複合的に積み重なるようにします。
7. 実験: 体系的なバリアンステストを実施してフレームワークの出力が安定していることを確認します。