自社のレビュー履歴からAIコードレビュアーをつくる方法

コードレビューどうしてる？ ボトルネックに向き合う仕組み化Tips共有会
2026/09/30(水) 12:00 〜 13:00
https://findy.connpass.com/event/406145/

株式会社estie 取締役CTO
岩成 (@tiwanari)

Transcript

1. 7 年分の PR レビューを「会社の方言」に蒸留した話 記事『自社のレビュー履歴から AI コードレビュアーをつくる方法』の 10 分版 コードレビューどうしてる？ ボトルネックに向き合う仕組み化 Tips 共有会 2026/09/30 12:00~13:00 株式会社 estie 取締役 CTO 岩成達哉 (Nari) © estie, inc. © estie Inc.
2. 自己紹介 バックグラウンド • 松江高専 [ 島根 ] で情報工学を学ぶ • 高専時代の教材をもとに大学在学中に起業 キャリア • Indeed Japan で求人データ基盤を開発 • 2020 年 estie 参画、 2021 年 取締役 CTO 就任 • 2025 年 不動産 AI Lab 設立 個人 Nari （ @tiwanari ） • 6 歳と 4 歳の男の子の父 • 2025 年 10 月から社会人博士として AI を研究 estie 取締役 CTO © estie, inc. © estie Inc. 1
3. AI レビュー、使っていますか？ © estie, inc. © estie Inc. 2
4. その AI は「うちではこうする」まで 見てくれていますか？ © estie, inc. © estie Inc. 3
5. 問題｜汎用 AI だけでは足りない 汎用 AI は「会社の方言」を知らない 汎用 AI が知っていること 一般的なベストプラクティス 汎用 AI が知らないもの 会社の方言 言語ごとの定石 命名・設計の好み Rust / TypeScript などの一般的なベストプラクティス このパッケージ名でよいか、責務をどこに置くか 既知のアンチパターン レビューの指摘の強さ よくあるバグや保守性の問題 どこから blocker か、どこまでが nit か 目に見えるコード どう進化させるか 与えられた範囲の不具合を指摘できる MVP ならこの実装でよい、次に何を直すか © estie, inc. © estie Inc. 4
6. 蓄積｜会社の方言はどこにある？ 「会社の方言」はレビューコメントに残っている What: 何を指摘するか 例外処理・責務分割・テスト・命名 伝え方にも会社（ estie ）の特徴がある コメント長の中央値 55 文字 Severity: どれくらい強く言うか blocker （必須） / want （希望） / nit （軽微） How to say: どう伝えるか 短く問いかける / 技術用語は英語で書く © estie, inc. © estie Inc. 疑問形で問いかけている 約3割 日本語の中に英語の技術語 約8割 5
7. 自社のレビュー履歴を用いて 痒いところに手が届く 自社製レビュアーを作ろう！ © estie Inc. 7
8. 作り方｜ 5 つのステップで始める 最初の一歩は使って良いデータのスコープを決めること 1 2 3 4 5 対象を決める 集める 分析する 蒸留する 使う 使うデータを決める 1 コメント = 1 行 数える + 意味で束ねる 根拠つき Markdown 複数エージェント 始める前の前提 GitHub から JSONL 数字で癖を見る 条件・強さ・例・件数 規約を読ませてレ で集める ビューする 初期スコープの決め方の例 対象 AI に渡す情報 除外する情報 1 リポジトリ × 数か月 body / diff_hunk のみ Bot / 自己レビュー / "LGTM" © estie, inc. © estie Inc. 6
9. 収集｜ 1 コメント = 1 行に落とす 収集に特別な基盤は要らない (GitHub API と JSONL だけ ) JSONL / 1 comment = 1 line { 最小項目から repo / pr_number / path / body / diff_hunk "repo": "example/repo", "pr_number": 123, "reviewer": "user_b", "path": "app/models/example.rb", 期間で分割 半年単位に分け、 GraphQL のタイムアウトを避ける "language": "Ruby", "body": "nil のときに落ちそうです ", "diff_hunk": "@@ ...", "line": 42, 再開可能に レート制限やタイムアウト後も途中から再開 "is_bot": false, "is_self_review": false } © estie, inc. © estie Inc. 後で除外 Bot ・自己レビューはフラグだけ持たせる 7
10. 分析｜「数える」と「意味を読む」を分ける 統計量はスクリプト、意味解釈は AI 統計量 : JSONL を集計するだけ カテゴリ 意味解釈 : 表現が違っても同じ指摘にまとめる 「 0 件のとき、どうなりますか？」 bug / naming / testing / security 強さ 「空配列のケースは大丈夫ですか？」 blocker / want / nit 書き方 「結果が空でも通りますか？」 長さ / 疑問形 / suggestion 率 → 同じ指摘としてまとめる © estie, inc. © estie Inc. 8
11. 蒸留｜判断を規約にする AI に規約を発明させず「繰り返された判断」を残す AI は候補を出すが、規約として採用するかは人が決める 「外部 API の失敗」に関するコメントの集計結果（出力例） ### 指摘する条件 外部 API の失敗が、呼び出し元に伝わらない場合 ### 指摘の強さ 実バグ → blocker ／ 設計上の改善提案 → want ### コメント例 「この API が失敗したとき、どう扱いますか？」 ### 根拠 過去のレビューコメント 18 件 © estie, inc. © estie Inc. 9
12. 実行｜観点別にエージェントを分ける 万能レビュアーをやめ、 6 つの観点で並列レビュー © estie, inc. © estie Inc. 10
13. 結果｜ CodeRabbit と比較してみた 競争ではなく補完関係 estie 製は「広く見る」 <> CodeRabbit は「具体的に直す」 © estie, inc. © estie Inc. 11
14. 何を大事にしているか = AI と人間で役割を分ける 人間は「設計判断とビジネス整合」に集中する © estie, inc. © estie Inc. 12
15. 持って帰っていただきたいこと 各社のレビュー履歴は AI 時代の「学習データ」になる 1. コードレビュー履歴は宝の山 設計判断や指摘の強弱が残っている 2. 小さくはじめられる 特別な基盤は不要 GitHub API で 1 リポジトリから始められる 3. この仕組みも育てていくもの 抜け漏れをなくすサイクルが大事 © estie, inc. © estie Inc. 13
16. 続きが気になる方は… ご清聴ありがとうございました © estie, inc. © estie Inc. 14
17. バックアップ 以降は質疑用 © estie, inc. © estie Inc. 15
18. （参考）モデルの使い分け（ 2026/09 時点） 高難度の判断には高性能モデル 単純な照合には軽量モデル 観点ごとの割り当ては本編の図を参照 バグスキャン リポジトリ規約の準拠 Opus （重い） Sonnet （標準） 重大なバグに集中する 変更が CLAUDE.md に沿っているか Git 履歴・依存関係 過去 PR コメントとの照合 Sonnet （標準） Sonnet （標準） git blame で経緯を読み、破壊的変更を検出 同じ指摘が過去に出ていて再発していないか レビュー規約チェック コード内コメント整合性 Sonnet （標準） Haiku （軽い） 蒸留した規約に沿った指摘 TODO / FIXME と変更内容の矛盾 © estie, inc. © estie Inc. 16