不要なレビューをAIにまかせて AIコーディングの環境改善を加速した

Transcript

1. © Findy Inc. 不要なレビューをAIにまかせて AIコーディングの環境改善を加速した 1 2026.06.24 熊野修太（@shoota）
2. © Findy Inc. フロントエンドリード、スクラムマスター、エンジニ アリングマネージャーを経験 フルリモート in ⻘森 2 ⾃⼰紹介 熊野 修太 [くまの しゅうた] ファインディ株式会社 プロダクト開発部 / フロントエンドリード @shoota @shoota
3. © Findy Inc. 3 Findy Team+ フロントエンドの現状 ⾮常に⼤きなモノレポで構成されている ‧CIの最適化‧チューニングを継続実施 ‧コードベース全体の秩序を維持するルールを策定 https://tech.findy.co.jp/entry/2025/06/30/070000 https://speakerdeck.com/shoota/da-gui-mo-monoreponozhi-xu-gu an-li-shi-su-sinaiduo-yan-yu-hua-hurontoendonoyun-yong
4. © Findy Inc. ⾮常に⼤きなモノレポで構成されている ‧CIの最適化‧チューニングを継続実施 ‧コードベース全体の秩序を維持するルールを策定 ‧ESLint‧ユニットテスト等のガードレール整備を約1年継続 4 Findy Team+ フロントエンドの現状 • AIが⽣成するコードの品質の⼤幅な向上 • バックエンド主体メンバーがフロントエンド開発
5. © Findy Inc. 5 AIコーディング時代の新たな課題 AI対応のレビューコストが異常に⾼い ‧Lintルール1つの厳格化で 25件 のプルリクエスト ‧新ルール追加時には 150件 のプルリクエストが必要 ‧OSSが⾮推奨にした関数の置換で 1⽇72件 / 2⽇100件超 を⼀⼈で作成
6. © Findy Inc. AIの精度とコード品質を向上させるための環境改善活動の量が ⼈間の活動上限の量を超えることができない 6 解決したい課題 プルリクエストを⾼速に作り続けること⾃体は歓迎すべき 本質は「レビュープロセスが対ひとでしか機能していない」こと • ⼈の時間を奪う • ⼈のアクションを待つ • 両者にメリットが少ない
7. © Findy Inc. 7 レビューは⼤きく3種類ある ① レビュー価値がないことを確認する承認⾏為 • レビューワークフローに相乗りしている⺠主的な点検作業 ② 品質‧プログラム観点のコードレビュー • 本来のコードレビュー • ⼈間が実施すべき本質的なレビュー⾏動 ③ 指摘が反映されたかの確認レビュー • 指摘内容の反映、採⽤状況を再度点検する • 論点が絞られており、レビューによる価値が⾼まりにくい
8. © Findy Inc. AIレビュー (Approve) を作る 8
9. © Findy Inc. 9 何を判定するのか / 誰が使えるか プルリクエストの「分類器」を作る • ⼈間がレビューする必要があるか？を⾃動判定する • 振る舞いが変わらない『構造的なリファクタリング』 • code generator などの機械的な実⾏結果も対象 • Claude Code Review (〜$25)ではないなにか フロントエンドのレビュワーチームのみ利⽤可能 • ⼀定のコード品質とセルフレビューによる品質担保が前提 • 誤判定の蓄積によってコード汚染、AIコンテキスト汚染を防ぐ • ワークフロー⾃体の不備によるレビューのザル化を防ぐ
10. © Findy Inc. 10 どうやって判定するのか 基本となるコンセプトが必要 • リファクタリングの経験則を蓄積することで可能な限り⾃動化したい • ⼀⽅で体系的な情報の粒度や分類なしでは、判定基準の策定に時間がかかりすぎる Tidy First? ―個人で実践する経験主義的ソフトウェア設計 リファクタリングの構造化 • 振る舞いの変更 • 構造の変更 ( Tidy = 整頓 )
11. © Findy Inc. 11 整頓の対象パターン 物理的構造の変更 • T1: ファイル移動‧リネーム • T2: import整理‧barrel export • T3: 型定義の移動‧分離 • T4: コンポーネント‧関数の分割‧統合‧抽出 • T5: 変数‧関数‧プロパティ‧propsのリネーム コードの整理‧削除 • T6: ESLint/ Prettier修正 • T7: 不要コード‧ファイルの削除 • T8: ⾮推奨APIの機械的移⾏
12. © Findy Inc. 12 整頓の対象パターン ⾃動⽣成コード • T9: GraphQL codegenの実⾏結果 • T10: Nx generatorの実⾏結果 コードの意味的整理 • T11: ガード節への変換 （注： 早期リターンへの変更） • T12: 説明変数‧説明定数の導⼊ 宣⾔的定義の追加 • T13: Feature Flagの追加（注：フィーチャーフラグを新規追加する作業） • T14: コメントの追加‧修正‧削除
13. © Findy Inc. • NG1: 新しい条件分岐の追加‧条件式の実質的変更 • NG2: 新しいビジネスロジックを含む関数‧コンポーネントの実装 • NG3: APIエンドポイントの追加‧変更 • NG4: 状態管理の変更 • NG5: テストケースの追加‧ロジック変更 • NG6: UIの⾒た⽬の変更 • NG7: 設定値の変更 13 NGパターン NGパターンのポイントは自己改悪への防御 • 自動承認基準を引き下げてレビューシステムを破壊できないようにする 　※ ちなみにClaude Code Actionsはデフォルトブランチのプロンプトしか読まない
14. © Findy Inc. 14 実装: GitHub Actions をランナーに シンプルなフロー • プロンプトファイル読み込み • Claude Code Action に渡して実⾏ • 結果をパースしてレポート • CI結果は Findy Team+ に送信し、CI実⾏分析にも活⽤
15. © Findy Inc. 15 Claude Code Action 設定 --max-turns 20 を指定 • Claude Codeが処理する⼿数の上限を制御 • 実測では構造的リファクタリングのPRは〜15 turns に収まる 想定外の⼤きな差分や誤判定があっても「判定不能」で終了する コストキャップ（最大でも $0.5程度） 暴走したDeep Thinkの停止
16. © Findy Inc. AIなら⼤きな差分でも同⼀作業なら1つのPRにまとめてよい • これまでは「⼈間が認知できる量」にサイジングしていた • AIに⼿加減をする必要はないのではないか（巨⼤な整頓PRの実⽤） 対応: ⼤規模PRへのサンプリング判定をプロンプトに追加 • 変更30ファイル超は代表ファイルのサンプリング判定OK • サンプリング時は変更が波及するものとセットで確認 ◦ NGの偽陰性や偽陽性を起こさないために関連付けを確認させる 16 ワークフローの変化とプロンプト改善 例）関数のリネーム → テストファイル名の変更 • 新規追加として誤認しないようにする（構造的な誤検知） • テストの変更として誤認しないようにする（意味的な誤検知）
17. © Findy Inc. まとめ 17
18. © Findy Inc. 18 まとめ Tidy First?の「先に整頓、あとに整頓」を仕組みで⽀える ① PR分類器を GitHub Actions × Claude Code Action で実現 ⼈間のレビューが不要なプルリクエストは作成者単独でマージ可能に ② 開発者体験が想定以上に向上 機能開発の合間でリファクタするモチベーションが⾼まる ③ 1 run = $0.20〜0.50程度 で運⽤可能 Claude Code Review ($25) より⼤幅に低コストで現実的 ④ さらに対象を拡⼤し、組織的なAIワークフローを充実させる 不要コードの検知と削除などテストで保証できる変更の⾃動化（実⽤済み） 構造的なリファクタリング課題の検出（コスト制約がネック）
19. © Findy Inc. 2026年5⽉18⽇ころにClaude Code ActionsのデフォルトモデルがSonnetからOpusに変更された。 Opusが深い思考をするためか、判定までの⼿数が増えて判定不能で終了するケースが発⽣ 19 テックブログに書いていないその後 Claude Code Actionsのメンテナンス https://x.com/shoota/status/2060714978001440822?s=46
20. © Findy Inc. 20 テックブログに書いていないその後 Claude Code Actionsのメンテナンス 2026/05/15 2026/05/19 2026/05/20 モデルを明⽰的に指定して運⽤
21. © Findy Inc. 不要なUIモジュールを⾃動で検知する仕組み 週次実⾏することで開発品質の維持もできる feature flagを利⽤してリリース前後を整合している場合などに残りやすい 21 テックブログに書いていないその後 リファクタリングや画⾯統合によって不要となったUIモジュールの検知
22. © Findy Inc. ご清聴ありがとうございました 22