使いながら育てる Claude Code — 開発フローの1コマンド化 × 繰り返し指摘の自動仕組み化

AI Excellence Meetup（2026年6月19日）発表資料です。
株式会社カカクコム 食べログカンパニー フロントエンド基盤チーム / 遠藤司樹

スライドに沿った詳細解説は食べログテックブログをご覧ください。
https://tabelog-tech-blog.hatenablog.com/entry/react-pipeline-review-digest-claude-code-quality-automation

Transcript

1.  使いながら育てる Claude Code 開発フローの1コマンド化 × 繰り返し指摘の自動仕組み化  2026年6月19日 AI Excellence Meetup 株式会社カカクコム 食べログカンパニー フロントエンド基盤チーム 遠藤司樹
2.   今日紹介すること   開発フローの 1コマンド化 繰り返し指摘の 自動仕組み化 react-pipeline review-digest 
3.   前提: 私たちのケース 対象 jQuery から React へのリプレース 課題 Claude 導入で実装は高速化。 一方で...  毎週のPRレビューと 修正に膨大な時間がかかる   解決のアプローチ 独自の Skill を設計する
4.  解決策: Skill /react-pipeline 単なる自動化ではなく、全工程の品質を担保    Claude による一貫した 品質担保 Skill /react-pipeline 人間は叩くだけ    1. 実装  2. レビュー  3. テスト  4. PR作成
5.  Claude Code の拡張・自動化機能     Skill Subagent Hooks ワークフローを定義 処理委譲の仕組み 自動化のトリガー 名前 でいつでも 別コンテキストで起動し 専門タスクを委譲 イベント(セッション開始等)に 連動するシェルコマンド  / 呼び出せる手順書
6.  react-pipeline の全体像 大きく 4つのフェーズ に分かれて自動実行されるパイプライン  Phase 1 Phase 2 Phase 3 Phase 4      実装 調査・API生成 UIコンポーネント  レビュー 複数Agentによる 多角的・ 並行チェック  テスト ブラウザ自律操作で E2Eテスト  PR作成 差分から説明文を 自動生成して提出
7.   Skill と Subagent の階層設計 Orchestrator /react-pipeline Phase Skill Phase Skill Phase Skill /implement-react /pr-review /manual-test-on-vm    調査 Subagent  実装 Subagent...      設計 Subagent Test Subagent...  ブラウザ操作 Subagent 司令塔（Orchestrator）がフェーズを進行し、各フェーズ内で専門のワーカー（Subagent）が働く
8.  なぜ Subagent を分けるのか   一体型（何でも屋） 専門特化（集団）  指示や規約が混ざり混乱  コンテキスト肥大化・低速   調整やメンテナンスが困難  VS  担当ルールに集中し精度向上  軽量で並列・高速実行  個別に入れ替え・調整が可能  知識を混ぜると混乱するため、「1エージェント ＝ 1つの責務」を徹底
9.  Phase 1: implement-react 3つの Subagent が直列で動作 1 react-investigator  旧コード・既存パターン調査  2  3 api-client-generator react-implementer  スキーマからAPIクライアント生成   実装・テスト・Lint実行 
10.  Phase 2: pr-review (7並走) react-reviewer   refactor-reviewer      対象コード (PR) test-reviewer  security-reviewer     7つの専門 Subagent が 多角的な視点で一斉レビュー    project-reviewer  yagni-reviewer dead-code 
11.   自動修正 vs 人間確認 Claude の「自動修正」と 人間の「確認」を分ける  自動修正  人間確認  react-reviewer 軽微な修正 アーキテクチャの指摘  refactor-reviewer 命名規則など 仕様漏れ  security-reviewer - (対象外) 脆弱性の指摘  その他  全て自動修正で完結
12.   Phase 3: テスト (Playwright MCP) Step 1 Step 2 Step 3    ケース自動生成 仕様を読み解き シナリオ作成   自律的なテスト実行 Playwright MCP を 経由しブラウザ操作  結果の報告 PASS FAIL SKIP AIによる「テスト設計」から、 Playwright MCP を使った「ブラウザ操作」へ。 人間の手を介さずに、動作検証までが一気通貫で完結！
13.  【成果】品質向上によるレビュー工数の削減   react-pipeline 実装・レビュー・テストの  全工程を1コマンド化  コード品質の向上 規約通りの実装と自動修正 最初から高品質な PR が完成   レビュー工数の削減  生産性の低い規約違反の指摘がゼロに 人間は「本質的な確認」のみに集中
14.   【成果の裏側】なぜ Claude は規約を守れたのか？ 実は、膨大な規約は Skill や Subagent 内には書いていない  Skill / Subagent 内  コマンド実行時のみ 日常の開発では効かない   rules  VS .claude/rules/  日常の開発でも常に効く ファイル参照時に自動適用 に置くことで、Skill の枠を超えて Claude 全体の品質を底上げ。
15.  .claude/rules/ とは 指定パスのファイル参照時のみ自動ロード  .claude/rules/react/hooks.md  ファイル参照時  src/modules/api.ts  paths  パス一致  --paths: - "**/modules/**/*.ts" --# - 命名は use から始めること カスタムフック規約 に一致した場合のみ、コンテキストへルールを注入   注入
16.  規約構成: 7 ファイル分割 関心事ごとにルールを分割し、必要な時だけ読み込ませる  directory-structure  hooks  states components  usecases  api-clients  testing   
17.   規約一元化の効果 rules を更新するだけで、すべての Skill と Subagent に自動適用  実装 Subagent 規約違反の予防      rules 一元管理   レビュー Subagent  規約違反の検知 実装やレビューを含め、プロジェクト全体の品質が底上げされる
18.  残された課題：繰り返されるレビュー指摘 分かっていても繰り返される「非効率なループ」  1週目 2週目 3週目 handleReply... onReply... const getReview...  「handleChange... で」    「onClick... にして」  毎週人間が同じことを言っている 「名前は改善する」
19.  なぜ「仕組み化」が滞るのか？  非効率なループを断つには「即座の仕組み化」が必要だが... 理想 現実の壁   即座に「仕組み化」 手動運用では「滞る」   静的解析ルールの作成  ルールの動作検証   忙しくて後回し  実装方法に迷う
20.  だから「仕組み化の作業自体」を自動化する 静的解析ルールの実装まで Claude Codeに一任   日々の レビュー指摘    独自の Skill  /review-digest   分析からPR作成まで全自動化   静的解析に ルールを追加 面倒な「仕組み化」の作業を丸ごと代行させる
21.  静的解析が事前に止める世界へ    開発者 違反は差し戻し 対象コード   静的解析  安全なコード (フィルター)   非効率なループから解放され、 人間は「本質的なレビュー」に集中できる   人間の レビュアー
22.  Skill: /review-digest の処理フロー レビュー指摘を 1コマンドで自動化する 5つのステップ 1 2   抽出・分類 履歴と照合    3   手段の判定 4   自動実装  5   記録・共有 日々の開発を通じて Claude Code を「使いながら育てる」 成長ループ！
23.  Step 1: 指摘テーマの抽出 バラバラなコメントから 共通の問題 を抽出・要約 handleChange... でお願いします     onClick... にしたいです 口頭で会話。名前は改善する。    Claude 要約・分類   「イベントハンドラ 命名規約違反」
24.  Step 2-1: 履歴データとの突合 抽出されたテーマを 過去の履歴データと照合   過去の指摘履歴 history.json   照合 +  既存の指摘と一致 カウントを +1する 新しい指摘 新規テーマとして追加
25.  Step 2-2: 自動化の閾値判定 同じ指摘が3回出たら「自動化フロー」へ昇格 1回目 2回目 1 2 記録のみ 様子見    累積 3回目    自動化フローへ
26.   Step 3: アクション判定 自動化する手段を機械的に防げる順（優先度順）に判定する。 最優先   静的解析 コード構造から 機械的に検出可能 不可なら  代替策 最終判断   Hooks 静的解析でカバー できない複雑な仕様 不可なら  Skip あえて rules に 追加しない 肥大化による精度低下を防ぐ
27.  Step 4: 自動実装と PR 作成 設定変更から検証まで Claude が自律実行  設定ファイルを書き換え   ローカルでテスト・検証     ルールの PR 作成 人間は Claude が作った PR を確認するだけ
28.  Step 5: 累積データの Git 管理 裏側はシンプルな history.json ファイル。Git で履歴を管理します。 [ { "category": "命名規約", "summary": "イベントハンドラ命名規約違反", "total_pr_count": 3, "status": "open", "action": "eslint-plugin-react有効化", "pr_list": [49487, 50378, 50666], "first_seen": "2026-04-27"  } ] 
29.  Step 5: Miro への結果共有 (1/2)  
30.  Step 5: Miro への結果共有 (2/2)  
31.  自動ループが回っている Step 1 Step 2  指摘の発生  自動PR作成  Step 3       未然に防ぐ 人間は作られたPRを「マージするか」判断するだけ 
32.  ループのリアリティ   100%を目指す 完璧な自動化に悩み 仕組みづくりが停止する   VS  不完全でも回す 手動の指摘は残っても 改善のサイクルは回り続ける ループが回っていない状態よりずっといい！
33. Claude Code は単なる 「導入物」ではなく 「育てる仕組み」 /react-pipeline   一貫した 品質担保 /review-digest +  弱点の 自動補強 
34.   Appendix 設計・運用の工夫と見えてきた限界 
35.  【Tips 1】rules 適用範囲の厳密化  対象外のファイルで規約が発火すると、Claudeの混乱やトークンの無駄遣いに。  大雑把な指定の罠  パッケージからの明示 paths: ["**/components/*.tsx"] paths: ["packages/frontend/src/..."] 別ツールの同名フォルダにも 誤適用され誤検知の原因に ルートから厳密に指定し ノイズとトークン消費を抑える 
36.  【Tips 2】思考の Opus と 作業の Sonnet 日常開発の「デフォルト設定」として最強！ /model opusplan プランフェーズ 実装フェーズ   Opus 4.8  (推論・設計 特化) 「最初の方針」にコストをかけ 手戻りをゼロにする プラン承認   Sonnet 4.6 (高速・低コスト) 承認済みプランに従って 粛々と実装を実行する
37.   【Tips 3】プラン承認時のコンテキストクリア トークンの無駄遣いを防ぐ設定 showClearContextOnPlanAccept: true  デフォルト設定 (通常)  設定あり (推奨) 調査の長い会話履歴が実装に持ち越され 毎ターン全履歴を送信してしまう。 プラン承認時に「コンテキストをクリア」 の選択肢が使えるようになり 身軽な状態で実装をスタートできる。  プランで 1万 トークン消費した場合、 クリアせずに実装を10ターン行うと 同じ履歴を合計10万トークン分も再送信 に！  ※ プロンプトキャッシュで課金は抑えられるが、無関係な文脈の肥大化は防げない
38.  【Tips 4】テスト実行方式の最適化（MCP vs  CLI） Claude Code では、コンテキスト消費を抑えるために CLI 経由での実行がおすすめ Claude Desktop 等で推奨 Claude Code で推奨！  Playwright MCP  Playwright CLI ~ 114,000 Tokens   20〜40以上のツール定義が毎回送信  出力が巨大な構造化データ ~ 27,000 Tokens 約 4.2倍 効率的！ VS  ツール定義のオーバーヘッドなし  出力がコンパクトなテキスト ※ どちらも結果はコンテキストに直接追加される。 CLIはコーディングエージェント向けに最適化されており、トークン効率が劇的に高い。 
39.  【見えてきた限界】コンテキスト長の上限   1コマンド化の罠  「手動分割」への回帰 長いタスクで上限に達すると、Claudeの 「自動要約」が発動。 「全知全能」に固執せず、 重い実装はフェーズごとに手動実行し直す。 規約などの重要な詳細が抜け落ち、 後半の精度が低下する。  $ claude /implement-react  コンテキストリセット $ claude /pr-review
40.   ご清聴ありがとうございました 