自動レビューエンジンの実装と運用 ~レビューのない世界へ~

by Kanato

Embed

Start on current slide

Slide 1

Slide 1 text

本資料は、トグルホールディングス株式会社に許可なく複製・転載をしないようお願いします。⾃動レビューエンジンの実装と運⽤ ~レビューのない世界へ~

Slide 2

Slide 2 text

Slide 3

Slide 3 text

3 © toggle holdings inc. どのCoding Agent使ってますか？

Slide 4

Slide 4 text

4 © toggle holdings inc. Claude? Codex? Cursor? Gemini? Devin? Grok? Copilot?

Slide 5

Slide 5 text

5 © toggle holdings inc. 弊社ではCodexとClaudeが⼤多数です私はCodex派です🖐

Slide 6

Slide 6 text

6 © toggle holdings inc. 実際どれくらい作業効率上がってるの？

Slide 7

Slide 7 text

7 © toggle holdings inc.

Slide 8

Slide 8 text

8 © toggle holdings inc. 実装速度が上がり、人間がボトルネックに

Slide 9

Slide 9 text

9 © toggle holdings inc. 同時に10タスク近く抱えることも。。開発で求められる速度⤴

Slide 10

Slide 10 text

10 © toggle holdings inc. レビューしてる暇はないがコードがカオスになるのは避けたい！

Slide 11

Slide 11 text

11 © toggle holdings inc. よくある対策 AIによるレビュー

Slide 12

Slide 12 text

12 © toggle holdings inc. ローカルで AIにレビューさせてから Push or CIでAIがレビュー

Slide 13

Slide 13 text

13 © toggle holdings inc. プロンプト打つのがめんどい or レビューが不要な時も回ってしまう

Slide 14

Slide 14 text

14 © toggle holdings inc. Codex vs Codex 私なりの解決方法！

Slide 15

Slide 15 text

15 © toggle holdings inc. Codex vs Codex ● Codexにレビューさせて Codexに修正させるループをひたすら繰り返す自作 skills ● レビュー内容 /修正内容を毎回 PRのコメントに記す ● 実装もレビューも毎回新規セッションでやる (バイアス排除)

Slide 16

Slide 16 text

16 © toggle holdings inc. レビュー内容 ● PRの責務内の実装か (余計な実装したり不足がないか) ● このPRの実装で重複コードが発生してないか ● 潜在的な不具合がないか ● その他セキュリティも見て

Slide 17

Slide 17 text

17 © toggle holdings inc.

Slide 18

Slide 18 text

18 © toggle holdings inc. 開くとこんな感じ

Slide 19

Slide 19 text

19 © toggle holdings inc. ● ただのAIレビューより重複実装が減った ● コメントが残るから後からプロンプトの良し悪しやプロダクトの問題点を振り返って改善できる ● ローカルPCではなくGitHubに履歴を残すのは⼤事な気がする(AIを使って振り返れる)

Slide 20

Slide 20 text

20 © toggle holdings inc. 検証も通っていてCodexによる指摘も0であれば滅多にバグは踏まない感覚 (UIは思い通りにいかない時あり)

Slide 21

Slide 21 text

21 © toggle holdings inc. ● ただ、たまに PRがめちゃくちゃ膨れる ● たまに15Roundくらいまで行ってめちゃくちゃ待たされる(途中で打ち切れるけど ) 多分元々のコードの問題

Slide 22

Slide 22 text

22 © toggle holdings inc. コードの品質担保が重要

Slide 23

Slide 23 text

23 © toggle holdings inc. 色々チェックしてくれる 1つの品質ゲートを作ろう

Slide 24

Slide 24 text

24 © toggle holdings inc. 作ってみた。名付けてcode-police

Slide 25

Slide 25 text

25 © toggle holdings inc. ● ファイル/関数の行数 ● 引数数/ネスト深度 ● ast-grep: 空 catch / bare except / throw literal / subprocess shell=True など AST パターン検出 ● 循環依存/禁止import/private package参照 ● knip: TS/JS の未使用file / export / dependency / devDependency を検出

Slide 26

Slide 26 text

Slide 27

Slide 27 text

27 © toggle holdings inc. Biome tsc TypeScript TypeScript Compiler API ts-semantic ts-semantic-index knip Semgrep ast-grep TypeScript metrics engine import_graph_ts semantic_dependency deep dataflow SAST bug-semantic analyzer vitest jest mocha gitleaks Trivy osv-scanner

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

31 © toggle holdings inc. ● ⼤きめのPRで4~8roundかかっていたのが2~4 round程度になった ● 品質改善/リファクタ系：2~5round → 1~2round 本質的なバグ‧不具合をより⾒てくれるように

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

34 © toggle holdings inc. ● code-policeが本質的でない部分を潰してくれるから Codexのレビューの質が上がる ● Pass or Failedだけでなく %で出してくれる項目もあるので現状の実装の良し悪しがわかりやすくなった ● 型があるからこそ code-policeによる品質担保の役割がより活きる所感

Slide 35

Slide 35 text

Slide 36

Slide 36 text

36 © toggle holdings inc. まとめ ● Codexを使ったレビューと修正のサイクル ● バグは潰してくれるが実装が膨らみがち ● 多角的に見てくれる品質ゲートを導入し、実装がより安定した ● 仕様やルールはドキュメントに詳細に残すのが大事(それさえあれば実装はなんとかなる！ )