AIがレビューする時代に、 Androidエンジニアは何をレビューするのか 〜 土台づくりとレビュー再設計 〜

DroidKaigi 2026の登壇資料です。

Transcript

1. AIがレビューする時代に、 Androidエンジニアは何をレビューするのか 〜 土台づくりとレビュー再設計 〜 kobaken DroidKaigi 2026
2. kobaken ピクシブ株式会社 pixivコミックのAndroidアプリを開発
3. 突然ですが！ AIにコードレビューさせてる？🙋 3
4. オープニング — 課題提起 ボトルネックはレビューに移った • AIの導入により設計・実装・テストが高速化された • 他工程が速いほど、レビュー待ちが目立つ • スループットを決めるのが人間のレビュー→ボトルネックに 設計 実装 テスト AIで高速化 ──────────────────────────────────────────▶ レビュー ここが滞留する 4
5. オープニング — 課題提起 理想：AIレビューを導入して爆速開発！ • コードレビューもAIにさせればいいじゃない • 人間は仕様や体験を提示するだけ • AIにコード生成させて、AIに指摘してもらい、AIで修正する 指摘がなくなるまでループ！ 設計 実装 テスト レビュー AIで高速化 ────────────────────────────────────────▶ 5
6. オープニング — 課題提起 理想：AIレビューを導入して爆速開発！ • コードレビューもAIにさせればいいじゃない 🤔 • 人間は仕様や体験を提示するだけ • AIにコード生成させて、AIに指摘してもらい、AIで修正する 指摘がなくなるまでループ！ 設計 実装 テスト レビュー AIで高速化 ─────────────────────────────────────────────────────────────▶ 5
7. 本セッションの問い AIがレビューする時代に、 人間は何をレビューするのか 6
8. オープニング アジェンダ セクション 1. オープニング — 課題提起 2. 前提共有 — pixivコミックAndroidとAIレビュー導入の文脈 3. レビューの土台づくり 4. レビューの再設計 5. まとめ 7
9. SECTION 02 前提共有 pixivコミックAndroidアプリと、AIレビュー導入の経緯 02
10. 前提共有 pixivコミック Androidアプリの全貌 • 10年以上の歴史 • マルチモジュール移行中 • 大半のレガシーコードがappモジュールに残存 • Compose移行中 • ViewBinding / DataBindingが残存 • MVVM 9
11. 前提共有 pixivコミック Androidアプリの全貌 42 202,727 2 58 GitLab モジュール数 コード行数 コミッター数 月あたりMR数 バージョン管理 app 1・library 1 うちテスト 45,758 kobakenともう一人 平均値・MAX 95 社内セルフ core 14 ビルド・CI 3,396 2025/7〜2026/7 ホスティング feature 26 10
12. AI導入当初の流れ AIがコードを生成してくれる これまで以上の速度で機能開発が可能に 11
13. AI導入当初の流れ しかし、MRの作成頻度に比べて リードタイムが改善しない…… 12
14. 前提共有 pixivコミックで発生した課題 課題 MRの滞留 ― レビュー待ちが積み上がり、リードタイムが改善しない ▲ 原因 差分の大きいMRはレビュー負荷が高い AIコーディングで差分の大きいMRが増加 1本のレビューが重く、捌けるペースを超えて積み上がっていく 13
15. MR滞留問題を解決したい AIにコードレビューをしてもらおう🤖📝 14
16. 前提共有 — AIレビュー導入の経緯と変遷 GitLab上にAIレビューを導入 • 任意のプロンプトを渡せる • GitLabにコメントしてくれる 15
17. 前提共有 — AIレビュー導入の経緯と変遷 GitLab上にAIレビューを導入 16
18. 前提共有 — AIレビュー導入の経緯と変遷 GitLab上にAIレビューを導入 17
19. AIレビュー導入の経緯と変遷 AIレビューを導入したものの、 人間によるレビューはそこまで変わらず ボトルネックは残ったまま…… 18
20. 「AI万能論」でも「AI否定論」でもない 任せる領域と責任範囲を設計する話 レビューという過程を、どう設計し直すか 19
21. アジェンダ セクション 1. オープニング — 課題提起 2. 前提共有 — pixivコミックAndroidとAIレビュー導入の文脈 3. レビューの土台づくり 4. レビューの再設計 5. まとめ 20
22. SECTION 03 レビューの土台づくり 精度を左右する整備と、Android固有の失敗事例 03
23. 土台づくり — なぜ土台が必要か 土台なしで導入した結果 鋭いようで的外れな 指摘の量産 誤検知・ノイズ化 指摘が 読まれなくなる レビューが機能しない悪循環へ 22
24. 仮説 AIレビューの精度 ＝ 与えた文脈の質 23
25. さらに レビューで指摘される些細な修正を減らす →AIコーディングの質を上げる 24
26. 土台づくり AIに文脈を与える モジュール構成と依存方向 アーキテクチャ方針 コーディング規約 Androidに関する知識 テスト エージェントの行動指針 プロジェクト固有の知識 25
27. 土台づくり — AIに文脈を与える モジュール構成と依存方向 • マルチモジュールの全体像 • モジュールごとの役割の説明 • feature → app への依存禁止などのルール 26
28. 土台づくり — AIに文脈を与える アーキテクチャ方針 • 各レイヤーのコンポーネントに関する説明 • それぞれの責務を明文化 • ViewModelやComposeの状態管理 • UiStateの設計方針 27
29. 土台づくり — AIに文脈を与える Androidに関する知識 • 基本的には不要 • 繰り返し意図と異なる結果になったら知識を与える • Edge to Edge 28
30. 土台づくり — AIに文脈を与える エージェントの行動指針 • 「3ステップ以上かかるタスクは実行計画を提案して」 • 「ビルドコマンドはログ抑制モード（-q）で実行して」 29
31. 土台づくり — AIに文脈を与える 単体テストのルール • テストの手法 • ダミーデータやモック化に関する方針 30
32. 洗練された文脈を与えるために AGENTS.mdを記述する 31
33. 土台づくり — AIに文脈を与える AGENTS.mdとは • AIエージェントにプロジェクト固有のルールを記載する場所 • Claude CodeではCLAUDE.md • AGENTS.mdの参照をCLAUDE.mdにも記述しておくと便利 32
34. 土台づくり — AIに文脈を与える AGENTS.mdを育てる • 全体で30行程度 • エージェントの行動指針を示す • 以下のmdファイルを作成して参照させている • architecture.md • junit5̲unit̲tests.md 33
35. 土台づくり — AIに文脈を与える: AGENTS.mdを育てる architecture.md • 各レイヤーの説明や実装サンプルなど • アーキテクチャやモジュール構成 • プロジェクト固有のUiStateの設計方針 • Jetpack Composeのガイドライン • アンチパターンも記述してコード生成&レビューで検知可能に 34
36. 土台づくり — AIに文脈を与える: AGENTS.mdを育てる junit5̲unit̲tests.md • 単体テストを書く際の基本ルールや採用ライブラリを列挙 • Coroutinesが絡むテストに関しては補足を追加 • モックデータやダミーデータの取り扱い 35
37. 土台づくり — AIに文脈を与える: Skills 特定の作業フローは Skills として定義 • adapting-edge-to-edge（独自スキル） • 画面をEdge to Edgeに対応させるためのスキル • Android View / Compose 両対応 • 公式のスキルはComposeのみ 36
38. 土台づくり — AIに文脈を与える: Skills 特定の作業フローは Skills として定義 • multi-perspective-code-review（独自スキル） • 複数の観点をサブエージェントにレビューさせる 「振る舞い」or「構造」 設計 UI / Compose Data / Infra テスト セキュリティ 37
39. 土台づくり — AIに文脈を与える: Skills multi-perspective-code-reviewの出力設計 重要度 対象レイヤ なぜダメか 代替案 直すべきか、 UI / ドメイン / 規約か、バグか、 どう直すかの 参考か データのどこか 設計原則か 具体案 38
40. 土台づくり — AIに文脈を与える: Skills multi-perspective-code-reviewの出力設計 指摘コメントの例（イメージ） [High / UI層] LazyColumn内でViewModelのFlowを直接collectしています。 再コンポーズごとに購読が張り直されるためです（規約: UiState経由で購読）。 代替案: collectAsStateWithLifecycle()で購読し、UiStateに集約してください。 出力形式を固定化 → 指摘の採用判断の質が向上 39
41. 土台づくり — レビューのためのプロンプト レビューガイドラインを整備 • review̲guideline.md • architecture.mdやjunit5̲unit̲tests.mdなどを参照させる • 「~.mdを参考に基準を満たしているかレビューして」 • MRのdescriptionもチェックして実装と乖離がないか • 「descriptionで目的が明確になっているか」 • 「実装と乖離していないか」 40
42. 文脈以外にも大事なものが テストを整備して より強固な体制にする✅ 41
43. 土台づくり — テスト整備がレビューにつながる 単体テスト 概要 JUnit / Robolectric によるロジックの検証 ドメインロジックやUI状態の変化を、コードで機械的に検証できる AIレビューとの関係 AIの指摘を「検証可能」にする 指摘の裏取りが機械的にでき、リファクタリング提案も安心して受け入れられる 42
44. 土台づくり — テスト整備がレビューにつながる ビジュアルリグレッションテスト（VRT） 概要 Roborazzi などによるスクリーンショット比較 「UIが変わっていない」ことを画像差分で機械的に検証する AIレビューとの関係 「見た目が変わらない」を機械的に証明する リファクタリング系の変更で、人間が画面を目視確認する負担を減らせる 43
45. 土台づくり — テスト整備がレビューにつながる テストがあると、AIの指摘が「検証可能」になる AIの指摘 テストで裏取り 採否判断 • 単体テストがロジックの確かさとリファクタリング強度を上げる • VRTで「UIが変わっていない」を機械的に証明 44
46. 土台づくり — さらに発展させてみる Konsistでアーキテクチャ違反を機械的に検知 • アーキテクチャルールをテストコードとして記述 • 依存禁止 / レイヤ間の参照方向 などをCIで自動チェック • ツール化できるルールはKonsist、判断基準だけをAGENTS.mdへ 可能な限りルール違反はAIに指摘させず、テストで落とす 45
47. 土台づくりをしていく中での失敗事例 土台を固めていく過程で pixivコミックが直面した失敗事例💣💥 46
48. 土台づくり — pixivコミックの失敗事例 失敗事例： 自動生成コードを「ビルドエラー」と誤判定 事象 ViewBinding / DataBinding の生成クラスをAIが参照できず 「ビルドエラーになる」と誤指摘 47
49. 土台づくり — pixivコミックの失敗事例 失敗事例： 自動生成コードを「ビルドエラー」と誤判定 原因 ビルド時に自動生成されるコードがリポジトリにない 48
50. 土台づくり — pixivコミックの失敗事例 回避策：「AIから見えないもの」を文脈で補う • 自動生成コードの存在と扱いをレビュー用のmdファイルに明記 • 「未定義」「ビルドエラー」といった指摘を無視する 49
51. 土台づくり — 小まとめ 土台づくりのまとめ ✓AIコーディングの質を高めよう ✓AGENTS.mdを育てよう ✓エージェントの行動指針やプロジェクト固有の知識 ✓レビュー用のプロンプト・Skillsを整備しよう ✓複数の観点✖指摘の重要度 ✓テスト（Unit / VRT）を導入して検証可能にしよう 50
52. アジェンダ セクション 1. オープニング — 課題提起 2. 前提共有 — pixivコミックAndroidとAIレビュー導入の文脈 3. レビューの土台づくり 4. レビューの再設計 5. まとめ 51
53. SECTION 04 レビューの再設計 人間とAIの責任範囲の再定義と運用 04
54. レビュー再設計 — これまでのレビューフロー レビューフロー Before 設計・実装 MR作成 AIレビューBot（任意） 人間レビュー（必須） マージ 53
55. レビュー再設計 — 責任の移動 コードレビューの目的を6つの観点に分解 品質保証 保守性 セキュリティ バグ・デグレの検出 可読性・変更の容易性 脆弱性・情報漏洩防止 要件 チーム合意形成 責任境界の明確化 仕様どおりに動くか 設計・方針の共有 誰が責任を持つか 54
56. レビュー再設計 — 責任の移動 どこをAIに任せ、どこを人間が担うか 観点 AI 人間 補足 品質保証 ◎ ◯ 規約違反・定型バグはAIが一次検出。人間は妥当性を確認 保守性 ◎ ◯ 命名・一貫性はAI。構造・設計の妥当性は人間が判断 セキュリティ ◯ ◎ パターン検知はAI。リスク判断と最終責任は人間 要件 △ ◎ 仕様を渡せばAIも補助可能。仕様との突き合わせは人間 チーム合意形成 — ◎ 設計判断の共有・納得形成は人間にしかできない 責任境界の明確化 — ◎ 「誰が承認したか」の責任はAIに移せない ◎ 主担当 ◦ 補助 △ 条件つき — 対象外 55
57. レビュー再設計 — 実装前のレビュー 実装の前に要件・仕様・設計をレビューする 取り組み 要件・仕様・設計のレビューを実装前のフローに追加 コードになる前の判断は自動化せず、人間がレビューを担う ▼ 採用したフレームワーク Design Docs 実装前に、背景・目的・設計方針・代替案とトレードオフを短いドキュメントにまとめ、 関係者のレビューで設計判断の合意をつくるプラクティス 56
58. コードレビューしやすくするための取り組み コードレビューしやすいとは どういう状態なのか？🤔 57
59. レビュー再設計 — レビューしやすいMR分割 MRを「振る舞い」と「構造」に分割する 振る舞いの変更 構造の変更 仕様・挙動の変更、バグ修正など 動作に影響しないリファクタリング ユーザー影響が高いカテゴリ ユーザー影響なし 混在MRがレビューを遅くする → 分割してレビュー速度を上げる 参考: Kent Beck『Tidy First?』 — structural / behavioral changes 58
60. レビュー再設計 — レビューしやすいMR分割 分類ごとのレビュー運用 振る舞いの変更 構造の変更 AIコードレビュー × 人間のレビュー AIコードレビュー ＋ VRTで完結可能 レビュイーは変更意図の提示義務あり 事後修正可能なことが多い 注記: スマホアプリの「後から修正」は即時に全体反映ではない 修正リードタイムを許容できる変更かで線引き 59
61. レビュー再設計 — 「振る舞い」の変更と「構造」の変更 どのようにして判定するか • 土台づくりで用意していたmulti-perspective-code-review • 変更の種類を「振る舞い」「構造」「混在」で判定 • 「混在」している場合は、それらを分離するようにAIに指示 • 分割してMRを出すことで認知負荷の軽減 60
62. レビュー再設計 — リスクベースのレビュー強度設計 変更リスクでレビュー強度を変える リスク 変更の例 レビュー方針 高 課金・認証・個人情報・targetSdk更新 仕様リンク必須 ＋ 人間レビュー必須 中 機能追加・ロジック変更 AIレビュー ＋ 人間レビュー 低 UI微修正・文言変更 AI ＋ セルフレビュー中心（人間レビューは任意） リスクに応じて人間の時間を配分する 61
63. 大いなる力には、大いなる責任が伴う 責任の所在はAI？🤖 レビュアー？レビュイー？🧐😎 62
64. レビュー再設計 — 責任の移動 責任はMR作成者に重く — セルフAIレビューという帰結 • レビュイーが主体的になり、ソースコードの責任を負う • レビュアーはサポーターとして機能 • MR作成前にAIレビュー&修正をループさせる • multi-perspective-code-reviewを活用する 実装中に観点別 MR時点で「書き方」 レビュアーは セルフレビュー の指摘は改善済み 意図・設計に集中 63
65. レビュー再設計 — 新しいレビューフロー レビューフロー After 仕様・設計レビュー（人間） 実装 複数観点レビュー MR作成 AIレビューBot 人間レビュー ※変更分類による マージ 64
66. レビュー再設計 — レビューフローの遷移 レビューフロー Before → After Before After 仕様・設計レビュー（人間） 設計・実装 実装 MR作成 AIレビューBot（任意） 人間レビュー（必須） → 複数観点レビュー MR作成 AIレビューBot 人間レビュー ※変更分類による マージ マージ 65
67. レビュー再設計により 実装後の要件漏れによる手戻りが減り 最終的な成果物の質が向上した🎉 66
68. レビュー再設計により リファクタリングの受け入れが 再設計前に比べてスムーズになった😎 MRの滞留問題が軽減された 67
69. レビュー再設計をしていく中での失敗事例 レビューフローの再設計中に pixivコミックが直面した失敗事例💣💥 68
70. レビュー再設計 — pixivコミックの失敗事例 失敗事例① 仕様情報をAIに渡していなかった 事象 コードとしては妥当でも、実装と仕様の乖離をAIレビューは見逃した 「何を作るべきか」を知らないまま、コードの書き方だけをレビューさせていた 69
71. レビュー再設計 — pixivコミックの失敗事例 失敗事例① 仕様情報をAIに渡していなかった • 対策: 開発フローに仕様書（Spec）作成を追加 • 実装時にAIエージェントにはSpecを渡す • 仕様情報はDesign Docsにまとめて人間にレビューしてもらう 70
72. レビュー再設計 — pixivコミックの失敗事例 失敗事例② AIのLGTMで人間レビューが甘くなる 事象 AIに「問題なし」と言われると人間のレビューから厳しさが抜け落ちる 承認済みに見えるMRは注意力が落ちてしまう（個人差あり） 71
73. レビュー再設計 — pixivコミックの失敗事例 失敗事例② AIのLGTMで人間レビューが甘くなる • 対策: AIと人間がチェックする観点を明確にする • 人間は仕様・意図・リスクを見る • 指摘から意図の確認、質問へシフト 72
74. レビュー再設計 — pixivコミックの失敗事例 失敗事例③ Design Docs ≒ Plan問題 事象 Design Docsに詳細すぎる設計を書いてしまう 具体的すぎてレビューコストが増加していた 73
75. レビュー再設計 — pixivコミックの失敗事例 失敗事例③ Design Docs ≒ Plan問題 • 対策: 不確実性の高い大規模開発・リファクタリングで採用する • 普段の機能開発ではmini Design Docsを利用する • 通常のDesign Docsより粒度や項目を減らしたミニマル版 74
76. SECTION 05 まとめ 05
77. まとめ 土台を整え、レビューを再設計する レビューの土台づくり AIレビューの精度は「文脈の質」で決まる AGENTS.md・Skills・テストを育て、指摘を検証可能にする レビューの再設計 AIと人間の責任範囲を定義し直す 実装前レビュー・MR分割・セルフAIレビューを運用する 76
78. AIは万能なレビュアーではない。 任せる領域を設計した分だけ、 仕様・設計・意図・リスクに集中できる。 77
79. おわりに 資料 • プロンプト・スキルは可能な限り、公開予定 • 質問は Ask the Speaker でお待ちしています 78