■ 1. 概要と課題
- 食べログカンパニー フロントエンド基盤チームによるClaude Code活用事例
- jQueryからReactへのリプレース事業においてClaude Codeを導入
- 生成コードの品質にばらつきが生じ、PRレビューと修正に多大な時間を要する問題が発生
■ 2.
/react-pipelineSkill: 実装からPR作成の1コマンド化
- 実装からPR作成までの全工程を1コマンドに集約し、品質を一貫して担保する仕組み
- 4つのフェーズ構成:
- Phase 1 (実装): 3つのSubagent（調査・API生成・実装）が動作し、完了条件の確認と設計承認を経て実装を進行
- Phase 2 (レビュー): 7つの専門Subagentが並行レビューを実施し、自動修正と人間確認を区別
- Phase 3 (テスト): Playwright MCPでブラウザ自動操作によるテストを実行
- Phase 4 (PR作成): Draft状態でPRを自動生成
- 階層設計: Orchestrator Skillが各Phase Skillを指揮し、専門Subagentが実行する「1エージェント=1責務」の原則を徹底
■ 3.
/review-digestSkill: 繰り返し指摘の自動仕組み化
- 繰り返されるレビュー指摘を検知し、自動的に静的解析ルールへ変換する仕組み
- 5ステップのフロー:
- 指摘テーマの抽出・分類（表記揺れをまとめる）
- 履歴データとの照合・カウント（3回目で自動化昇格）
- 自動化手段の判定（静的解析→Hooks→Skip の優先順）
- 自動実装とPR作成
history.jsonへの記録とMiroへの出力- 3回の指摘閾値: 1〜2回は偶然のミスとして記録し、3回目で「仕組み化すべき」と判定
■ 4.
.claude/rules/による規約管理
- 規約を7つのファイルに分割して管理: directory-structure、hooks、states、components、usecases、api-clients、testing
- ファイル参照時に自動ロードされ、日常開発全体で効果を発揮
■ 5. 成果と指標
- PR平均コメント数: 15.10件 → 8.04件（約47%削減）
- 測定期間: 導入前後各108日間、対象は同一チームのReactリプレースPR
- 品質面: 仕様漏れ、ファイル構造違反、規約違反が大幅減少
- 指摘内容の質的変化: 軽微なルール違反から、Jotaiの状態管理パターン・React Queryの細かい仕様など高度な設計判断へシフト
- review-digestの実装例: ESLintカスタムルール3件、ESLintルール1件、Knipツール導入
■ 6. 設計原則
- Subagentの専門特化: 単一の「何でも屋」エージェントではなく専門分野に特化させることでコンテキスト肥大化を防止
- 自動修正と人間確認の分割:
- 軽微な修正: Claudeが自動実行
- アーキテクチャやセキュリティに関わる修正: 人間確認
- 脆弱性: 常に人間確認
■ 7. 運用上のTips
.claude/rules/のパス指定は「/components/*.tsx」より「packages/frontend/src/...」など厳密なパスを使用- Opus（思考）+ Sonnet（作業）の使い分けで、初期方針にコストをかけ承認後は低コスト実装
- プラン承認時にコンテキストをクリアして無関係な履歴の再送信を防止
- Playwright CLIはMCPより約4.2倍効率的
■ 8. 現状の課題と今後の展望
- 現在の制約: 大規模タスクでコンテキスト上限に達した場合、Claudeの自動要約が重要な詳細を削除して精度が低下
- 現在の対処法: 各フェーズを別セッションで実行
- 今後の目標:
- 高コストフェーズ（pr-review・manual-test）の最適化
- 静的解析で防げない指摘への対応
■ 9. 結論
- 完璧を求めず、不完全でも改善サイクルを回し続けることがより良い結果をもたらす
- react-pipelineとreview-digestは単発の導入物ではなく「使いながら改善し続ける仕組み」として設計