AI時代のコードレビューは人に向けるな、仕組みに向けろ

Transcript

1. AI時代のコードレビューは 人に向けるな、仕組みに向けろ meijin
2. このスライドの元になった記事 zenn.dev/manalink_dev
3. 自己紹介 名人（X: @meijin_garden） 2019年〜 株式会社NoSchool CTO 2022年〜 個人開発で テストメーカーをリリース 趣味：将棋、カメラ、麻雀、多肉植物 7月に子どもが生まれました👶
4. オンライン家庭教師 マナリンク オンライン家庭教師のための オールインワン集客・指導支援システム 保護者が先生を検索、一覧、お問合せ、課金できる 先生が授業を実施、予定管理、 宿題の提示や提出できる LLMが授業の文字起こしなどを分析し、 業務や指導を改善 Webサイトに加えてスマホアプリやAI Agentも開発
5. テストメーカー 個人開発している穴埋めテスト作成ツール 穴埋めテスト特化のWYSIWYGエディタを 開発 累計40,000ユーザー、80,000件のテスト 学校の先生、受験勉強、企業研修などで 利用
6. 私のスタンス 「コードレビュー」は残る 正確には「コードレビュー」という単語は消えるかもしれないが 「開発者以外の第三者の視点を今後の改善のために入れる」 という概念は残る
7. コードレビューの変化 コードそのものを見る レビューではなくなっていく コードを生み出した"Claude Codeなどの仕組み"に対するレビューになる
8. 背景：AIは指摘を反省しない その場しのぎで修正しても また繰り返す 対人レビューと異なり、 指摘が資産にならない
9. 同じミスを繰り返さないために コードを生み出した "仕組み"をレビューする
10. コードを生み出す"仕組み"って何だ？
12. コード編集前 既存コードを調査する SKILLやCLAUDE.mdを参照する grilling したりADRを作成する
13. コード編集中 Coding Agentによる実際の編集 Agent Hooksにより実装中にも フィードバックできる
14. コード編集後 Commit HookやCIでLint・Test Codeを実行 /code-review や内製レビュースキルを実行
15. レビューが解くべき問い レビューで見つけた問題点を、 どのフェーズに対して対策を差し込めば、 今後起きないようにできるのか？
16. フェーズごとの 特徴と選ぶ基準 コード編集前・中・後それぞれの特徴と、 仕組み改善のポイントを解説
18. コード編集前フェーズの特徴
19. コード編集前フェーズの注意点 CLAUDE.md/AGENTS.mdは太らせない・ほぼ書かない 絶対に守らないといけない指示を自然言語で書かない 決定的にできることは決定的にする（Skillにスクリプトを同梱） モデルの進化によって陳腐化しやすい
20. コード編集前フェーズの改善方針 最上位の指示 マナリンクの例 コード編集後では間に合わない or 局所最適で修正されてしまうような 最上位の指示を与える DB設計、API設計、ドメイン設計などにおける 見るべきファイルや過去事例をまとめた referenceをSkill化 各開発者が開発前などに呼び出す いろいろあるけど、結局コードが綺麗になっていることが一番効果的。リファクタリングの価値が 上がっている
21. ソースレビューとの関わり 「もうこれソースコード以前に設計が悪いんだよなぁ」がAIにより加速 特に”自社サービス特有の隠れた常識”を踏み倒すことが多い印象 上流で呼び出すスキルやreferenceへ 書き込む形でフィードバック
22. コード編集中フェーズの特徴
23. コード編集中フェーズのポイント Agent HooksによってCoding Agentの挙動をカスタマイズできる zenn.dev/manalink_dev
24. （半分余談）Hooksは慣れると便利な一例 弊社の代表「徃西（おうにし）」 AIがよく「大西さん」と出力して、GitHub等に書 き込んで心証が悪い 外部に”大西”を含むテキストを送ろ うとしたら一律Hookで防いでいる 弊社に”大西”が居ないので成り立つ🙄 こういう地味だけどAIが人間を下回っている細かいポイントを地道に防ぐのに向いている
25. コード編集後フェーズの特徴
26. コード編集後フェーズの改善方針 AI特有のミスを防ぐ secretlint knip as any 禁止など
27. ソースレビューとの関わり Coding Agent Coding Agent自身にカスタムLintルールを実装させる ASTを用いたアルゴリズムを書くこと自体は得意 人間が決めるのは 何をアウトにして、何をセーフにするのか ErrorにするのかWarnにするのか コードレビューで見つけた問題を資産に転換する
28. セルフQ&A
29. Q. チームで仕組みを育てやすくするには？
30. A. 気楽に増やせるラインを立案する 仕組みを増やすハー 他人の開発環境に影響させる心理的ハードル☠️ ドル プレッシャーの軽減 Warnや臭うコードレベルのSeverity追加の選択肢も用意 → CIでErrorにするルールの追加はプレッシャーになるから 小さなツール・スク 頻出作業のCLI化やASTベースの検知器開発”だけ”でもOK リプトを歓迎 → SKILL化やCI対応などを必須にしない。小さな資産を増やす志向
31. Q. 新規事業のほうが、 仕組み化がやりやすそうか？
32. A. そうとも言えない 以前の認識 「新規で始める事業の方が、 ゼロからAI前提で 組織もプロダクトも開発プロセスも 定義できるからやりやすそう」と思っていた 今の認識 歴史が長く開発文化がすでにある事業は 「何を正しいとして進めば 事業がうまくいくのか」が見えている 固執も良くないが 何もかもアンラーンするぞというのも勿体ない 例：過去のGitHubレビューコメントを AIに投げて分析
33. 最近やっている取り組み
34. 要領よくコードを読むための支援にLLMを利用 前提 （当然だが）全部の行を読んでいられない 要領よくPRの全体像を把握し、勘所だけ読みたい
35. 要領よくコードを読むための支援にLLMを利用 取り組み例 その他のアイデア ※現在進行形でお試し中 AIにMermaidで状態遷移図やフローチャートを書かせ、PR本文に添付 AIの提案素通り / POの決定 / 実装者の決定 を分けてADRに記載し、 レビュアーが臭いところを発見しやすくする 「臭うコード」を検知しReviewdogでPRにコメント JevでDiff filesの中から（高リスクのものだけ？）分類して提示 UMLなどを組み込んだソースレビュー用の専用HTML UIを作る
36. まとめ コードレビューは役目を変えて残る 何も考えずにAI使うとミスが増えるデメリットを被るだけになってしまう AI時代だからこそ増やしやすい仕組みもある コード編集前〜後まで幅広く見て改善内容を検討するべし
37. 告知
38. 少人数組織×教育事業に関心がある方、話しましょう マナリンク オンライン家庭教師の集客・指導支援システム 特徴 1. 集客（SEO・AEO）とシステム（決済・授業）両方持つ 2. 少人数組織（全社10名以下） 3. マナリンクで生活している（年収X00万以上）方がいる 開発体制 Claude CodeとCodex、原則1人1PJ、上流〜下流まで担当 Next.js、Laravel、Mastra、React Native、AWS 人の生活を支えるシステムを大規模に少人数で開発・運用する世界線に関心のある方ぜひ💬
39. ご静聴ありがとうございました ご連絡はXのDMまで 名人｜マナリンクCTO