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

by kobaken

Embed

Start on current slide

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

kobaken ピクシブ株式会社 pixivコミックのAndroidアプリを開発

Slide 3

Slide 3 text

突然ですが！ AIにコードレビューさせてる？🙋 3

Slide 4

Slide 4 text

オープニング — 課題提起ボトルネックはレビューに移った • AIの導入により設計・実装・テストが高速化された • 他工程が速いほど、レビュー待ちが目立つ • スループットを決めるのが人間のレビュー→ボトルネックに設計実装テスト AIで高速化 ──────────────────────────────────────────▶ レビューここが滞留する 4

Slide 5

Slide 5 text

オープニング — 課題提起理想：AIレビューを導入して爆速開発！ • コードレビューもAIにさせればいいじゃない • 人間は仕様や体験を提示するだけ • AIにコード生成させて、AIに指摘してもらい、AIで修正する指摘がなくなるまでループ！設計実装テストレビュー AIで高速化 ────────────────────────────────────────▶ 5

Slide 6

Slide 6 text

オープニング — 課題提起理想：AIレビューを導入して爆速開発！ • コードレビューもAIにさせればいいじゃない 🤔 • 人間は仕様や体験を提示するだけ • AIにコード生成させて、AIに指摘してもらい、AIで修正する指摘がなくなるまでループ！設計実装テストレビュー AIで高速化 ─────────────────────────────────────────────────────────────▶ 5

Slide 7

Slide 7 text

本セッションの問い AIがレビューする時代に、人間は何をレビューするのか 6

Slide 8

Slide 8 text

オープニングアジェンダセクション 1. オープニング — 課題提起 2. 前提共有 — pixivコミックAndroidとAIレビュー導入の文脈 3. レビューの土台づくり 4. レビューの再設計 5. まとめ 7

Slide 9

Slide 9 text

SECTION 02 前提共有 pixivコミックAndroidアプリと、AIレビュー導入の経緯 02

Slide 10

Slide 10 text

前提共有 pixivコミック Androidアプリの全貌 • 10年以上の歴史 • マルチモジュール移行中 • 大半のレガシーコードがappモジュールに残存 • Compose移行中 • ViewBinding / DataBindingが残存 • MVVM 9

Slide 11

Slide 11 text

前提共有 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

Slide 12

Slide 12 text

AI導入当初の流れ AIがコードを生成してくれるこれまで以上の速度で機能開発が可能に 11

Slide 13

Slide 13 text

AI導入当初の流れしかし、MRの作成頻度に比べてリードタイムが改善しない…… 12

Slide 14

Slide 14 text

前提共有 pixivコミックで発生した課題課題 MRの滞留 ― レビュー待ちが積み上がり、リードタイムが改善しない ▲ 原因差分の大きいMRはレビュー負荷が高い AIコーディングで差分の大きいMRが増加 1本のレビューが重く、捌けるペースを超えて積み上がっていく 13

Slide 15

Slide 15 text

MR滞留問題を解決したい AIにコードレビューをしてもらおう🤖📝 14

Slide 16

Slide 16 text

前提共有 — AIレビュー導入の経緯と変遷 GitLab上にAIレビューを導入 • 任意のプロンプトを渡せる • GitLabにコメントしてくれる 15

Slide 17

Slide 17 text

前提共有 — AIレビュー導入の経緯と変遷 GitLab上にAIレビューを導入 16

Slide 18

Slide 18 text

前提共有 — AIレビュー導入の経緯と変遷 GitLab上にAIレビューを導入 17

Slide 19

Slide 19 text

AIレビュー導入の経緯と変遷 AIレビューを導入したものの、人間によるレビューはそこまで変わらずボトルネックは残ったまま…… 18

Slide 20

Slide 20 text

「AI万能論」でも「AI否定論」でもない任せる領域と責任範囲を設計する話レビューという過程を、どう設計し直すか 19

Slide 21

Slide 21 text

アジェンダセクション 1. オープニング — 課題提起 2. 前提共有 — pixivコミックAndroidとAIレビュー導入の文脈 3. レビューの土台づくり 4. レビューの再設計 5. まとめ 20

Slide 22

Slide 22 text

SECTION 03 レビューの土台づくり精度を左右する整備と、Android固有の失敗事例 03

Slide 23

Slide 23 text

土台づくり — なぜ土台が必要か土台なしで導入した結果鋭いようで的外れな指摘の量産誤検知・ノイズ化指摘が読まれなくなるレビューが機能しない悪循環へ 22

Slide 24

Slide 24 text

仮説 AIレビューの精度＝与えた文脈の質 23

Slide 25

Slide 25 text

さらにレビューで指摘される些細な修正を減らす →AIコーディングの質を上げる 24

Slide 26

Slide 26 text

土台づくり AIに文脈を与えるモジュール構成と依存方向アーキテクチャ方針コーディング規約 Androidに関する知識テストエージェントの行動指針プロジェクト固有の知識 25

Slide 27

Slide 27 text

土台づくり — AIに文脈を与えるモジュール構成と依存方向 • マルチモジュールの全体像 • モジュールごとの役割の説明 • feature → app への依存禁止などのルール 26

Slide 28

Slide 28 text

土台づくり — AIに文脈を与えるアーキテクチャ方針 • 各レイヤーのコンポーネントに関する説明 • それぞれの責務を明文化 • ViewModelやComposeの状態管理 • UiStateの設計方針 27

Slide 29

Slide 29 text

土台づくり — AIに文脈を与える Androidに関する知識 • 基本的には不要 • 繰り返し意図と異なる結果になったら知識を与える • Edge to Edge 28

Slide 30

Slide 30 text

土台づくり — AIに文脈を与えるエージェントの行動指針 • 「3ステップ以上かかるタスクは実行計画を提案して」 • 「ビルドコマンドはログ抑制モード（-q）で実行して」 29

Slide 31

Slide 31 text

土台づくり — AIに文脈を与える単体テストのルール • テストの手法 • ダミーデータやモック化に関する方針 30

Slide 32

Slide 32 text

洗練された文脈を与えるために AGENTS.mdを記述する 31

Slide 33

Slide 33 text

土台づくり — AIに文脈を与える AGENTS.mdとは • AIエージェントにプロジェクト固有のルールを記載する場所 • Claude CodeではCLAUDE.md • AGENTS.mdの参照をCLAUDE.mdにも記述しておくと便利 32

Slide 34

Slide 34 text

土台づくり — AIに文脈を与える AGENTS.mdを育てる • 全体で30行程度 • エージェントの行動指針を示す • 以下のmdファイルを作成して参照させている • architecture.md • junit5̲unit̲tests.md 33

Slide 35

Slide 35 text

土台づくり — AIに文脈を与える: AGENTS.mdを育てる architecture.md • 各レイヤーの説明や実装サンプルなど • アーキテクチャやモジュール構成 • プロジェクト固有のUiStateの設計方針 • Jetpack Composeのガイドライン • アンチパターンも記述してコード生成&レビューで検知可能に 34

Slide 36

Slide 36 text

土台づくり — AIに文脈を与える: AGENTS.mdを育てる junit5̲unit̲tests.md • 単体テストを書く際の基本ルールや採用ライブラリを列挙 • Coroutinesが絡むテストに関しては補足を追加 • モックデータやダミーデータの取り扱い 35

Slide 37

Slide 37 text

土台づくり — AIに文脈を与える: Skills 特定の作業フローは Skills として定義 • adapting-edge-to-edge（独自スキル） • 画面をEdge to Edgeに対応させるためのスキル • Android View / Compose 両対応 • 公式のスキルはComposeのみ 36

Slide 38

Slide 38 text

土台づくり — AIに文脈を与える: Skills 特定の作業フローは Skills として定義 • multi-perspective-code-review（独自スキル） • 複数の観点をサブエージェントにレビューさせる「振る舞い」or「構造」設計 UI / Compose Data / Infra テストセキュリティ 37

Slide 39

Slide 39 text

土台づくり — AIに文脈を与える: Skills multi-perspective-code-reviewの出力設計重要度対象レイヤなぜダメか代替案直すべきか、 UI / ドメイン / 規約か、バグか、どう直すかの参考かデータのどこか設計原則か具体案 38

Slide 40

Slide 40 text

土台づくり — AIに文脈を与える: Skills multi-perspective-code-reviewの出力設計指摘コメントの例（イメージ） [High / UI層] LazyColumn内でViewModelのFlowを直接collectしています。再コンポーズごとに購読が張り直されるためです（規約: UiState経由で購読）。代替案: collectAsStateWithLifecycle()で購読し、UiStateに集約してください。出力形式を固定化 → 指摘の採用判断の質が向上 39

Slide 41

Slide 41 text

土台づくり — レビューのためのプロンプトレビューガイドラインを整備 • review̲guideline.md • architecture.mdやjunit5̲unit̲tests.mdなどを参照させる • 「~.mdを参考に基準を満たしているかレビューして」 • MRのdescriptionもチェックして実装と乖離がないか • 「descriptionで目的が明確になっているか」 • 「実装と乖離していないか」 40

Slide 42

Slide 42 text

文脈以外にも大事なものがテストを整備してより強固な体制にする✅ 41

Slide 43

Slide 43 text

土台づくり — テスト整備がレビューにつながる単体テスト概要 JUnit / Robolectric によるロジックの検証ドメインロジックやUI状態の変化を、コードで機械的に検証できる AIレビューとの関係 AIの指摘を「検証可能」にする指摘の裏取りが機械的にでき、リファクタリング提案も安心して受け入れられる 42

Slide 44

Slide 44 text

土台づくり — テスト整備がレビューにつながるビジュアルリグレッションテスト（VRT）概要 Roborazzi などによるスクリーンショット比較「UIが変わっていない」ことを画像差分で機械的に検証する AIレビューとの関係「見た目が変わらない」を機械的に証明するリファクタリング系の変更で、人間が画面を目視確認する負担を減らせる 43

Slide 45

Slide 45 text

土台づくり — テスト整備がレビューにつながるテストがあると、AIの指摘が「検証可能」になる AIの指摘テストで裏取り採否判断 • 単体テストがロジックの確かさとリファクタリング強度を上げる • VRTで「UIが変わっていない」を機械的に証明 44

Slide 46

Slide 46 text

土台づくり — さらに発展させてみる Konsistでアーキテクチャ違反を機械的に検知 • アーキテクチャルールをテストコードとして記述 • 依存禁止 / レイヤ間の参照方向などをCIで自動チェック • ツール化できるルールはKonsist、判断基準だけをAGENTS.mdへ可能な限りルール違反はAIに指摘させず、テストで落とす 45

Slide 47

Slide 47 text

土台づくりをしていく中での失敗事例土台を固めていく過程で pixivコミックが直面した失敗事例💣💥 46

Slide 48

Slide 48 text

土台づくり — pixivコミックの失敗事例失敗事例：自動生成コードを「ビルドエラー」と誤判定事象 ViewBinding / DataBinding の生成クラスをAIが参照できず「ビルドエラーになる」と誤指摘 47

Slide 49

Slide 49 text

土台づくり — pixivコミックの失敗事例失敗事例：自動生成コードを「ビルドエラー」と誤判定原因ビルド時に自動生成されるコードがリポジトリにない 48

Slide 50

Slide 50 text

土台づくり — pixivコミックの失敗事例回避策：「AIから見えないもの」を文脈で補う • 自動生成コードの存在と扱いをレビュー用のmdファイルに明記 • 「未定義」「ビルドエラー」といった指摘を無視する 49

Slide 51

Slide 51 text

土台づくり — 小まとめ土台づくりのまとめ ✓AIコーディングの質を高めよう ✓AGENTS.mdを育てよう ✓エージェントの行動指針やプロジェクト固有の知識 ✓レビュー用のプロンプト・Skillsを整備しよう ✓複数の観点✖指摘の重要度 ✓テスト（Unit / VRT）を導入して検証可能にしよう 50

Slide 52

Slide 52 text

アジェンダセクション 1. オープニング — 課題提起 2. 前提共有 — pixivコミックAndroidとAIレビュー導入の文脈 3. レビューの土台づくり 4. レビューの再設計 5. まとめ 51

Slide 53

Slide 53 text

SECTION 04 レビューの再設計人間とAIの責任範囲の再定義と運用 04

Slide 54

Slide 54 text

レビュー再設計 — これまでのレビューフローレビューフロー Before 設計・実装 MR作成 AIレビューBot（任意）人間レビュー（必須）マージ 53

Slide 55

Slide 55 text

レビュー再設計 — 責任の移動コードレビューの目的を6つの観点に分解品質保証保守性セキュリティバグ・デグレの検出可読性・変更の容易性脆弱性・情報漏洩防止要件チーム合意形成責任境界の明確化仕様どおりに動くか設計・方針の共有誰が責任を持つか 54

Slide 56

Slide 56 text

レビュー再設計 — 責任の移動どこをAIに任せ、どこを人間が担うか観点 AI 人間補足品質保証 ◎ ◯ 規約違反・定型バグはAIが一次検出。人間は妥当性を確認保守性 ◎ ◯ 命名・一貫性はAI。構造・設計の妥当性は人間が判断セキュリティ ◯ ◎ パターン検知はAI。リスク判断と最終責任は人間要件 △ ◎ 仕様を渡せばAIも補助可能。仕様との突き合わせは人間チーム合意形成 — ◎ 設計判断の共有・納得形成は人間にしかできない責任境界の明確化 — ◎ 「誰が承認したか」の責任はAIに移せない ◎ 主担当 ○ 補助 △ 条件つき — 対象外 55

Slide 57

Slide 57 text

レビュー再設計 — 実装前のレビュー実装の前に要件・仕様・設計をレビューする取り組み要件・仕様・設計のレビューを実装前のフローに追加コードになる前の判断は自動化せず、人間がレビューを担う ▼ 採用したフレームワーク Design Docs 実装前に、背景・目的・設計方針・代替案とトレードオフを短いドキュメントにまとめ、関係者のレビューで設計判断の合意をつくるプラクティス 56

Slide 58

Slide 58 text

コードレビューしやすくするための取り組みコードレビューしやすいとはどういう状態なのか？🤔 57

Slide 59

Slide 59 text

レビュー再設計 — レビューしやすいMR分割 MRを「振る舞い」と「構造」に分割する振る舞いの変更構造の変更仕様・挙動の変更、バグ修正など動作に影響しないリファクタリングユーザー影響が高いカテゴリユーザー影響なし混在MRがレビューを遅くする → 分割してレビュー速度を上げる参考: Kent Beck『Tidy First?』 — structural / behavioral changes 58

Slide 60

Slide 60 text

レビュー再設計 — レビューしやすいMR分割分類ごとのレビュー運用振る舞いの変更構造の変更 AIコードレビュー × 人間のレビュー AIコードレビュー＋ VRTで完結可能レビュイーは変更意図の提示義務あり事後修正可能なことが多い注記: スマホアプリの「後から修正」は即時に全体反映ではない修正リードタイムを許容できる変更かで線引き 59

Slide 61

Slide 61 text

レビュー再設計 — 「振る舞い」の変更と「構造」の変更どのようにして判定するか • 土台づくりで用意していたmulti-perspective-code-review • 変更の種類を「振る舞い」「構造」「混在」で判定 • 「混在」している場合は、それらを分離するようにAIに指示 • 分割してMRを出すことで認知負荷の軽減 60

Slide 62

Slide 62 text

レビュー再設計 — リスクベースのレビュー強度設計変更リスクでレビュー強度を変えるリスク変更の例レビュー方針高課金・認証・個人情報・targetSdk更新仕様リンク必須＋人間レビュー必須中機能追加・ロジック変更 AIレビュー＋人間レビュー低 UI微修正・文言変更 AI ＋セルフレビュー中心（人間レビューは任意）リスクに応じて人間の時間を配分する 61

Slide 63

Slide 63 text

大いなる力には、大いなる責任が伴う責任の所在はAI？🤖 レビュアー？レビュイー？🧐😎 62

Slide 64

Slide 64 text

レビュー再設計 — 責任の移動責任はMR作成者に重く — セルフAIレビューという帰結 • レビュイーが主体的になり、ソースコードの責任を負う • レビュアーはサポーターとして機能 • MR作成前にAIレビュー&修正をループさせる • multi-perspective-code-reviewを活用する実装中に観点別 MR時点で「書き方」レビュアーはセルフレビューの指摘は改善済み意図・設計に集中 63

Slide 65

Slide 65 text

レビュー再設計 — 新しいレビューフローレビューフロー After 仕様・設計レビュー（人間）実装複数観点レビュー MR作成 AIレビューBot 人間レビュー ※変更分類によるマージ 64

Slide 66

Slide 66 text

レビュー再設計 — レビューフローの遷移レビューフロー Before → After Before After 仕様・設計レビュー（人間）設計・実装実装 MR作成 AIレビューBot（任意）人間レビュー（必須） → 複数観点レビュー MR作成 AIレビューBot 人間レビュー ※変更分類によるマージマージ 65

Slide 67

Slide 67 text

レビュー再設計により実装後の要件漏れによる手戻りが減り最終的な成果物の質が向上した🎉 66

Slide 68

Slide 68 text

レビュー再設計によりリファクタリングの受け入れが再設計前に比べてスムーズになった😎 MRの滞留問題が軽減された 67

Slide 69

Slide 69 text

レビュー再設計をしていく中での失敗事例レビューフローの再設計中に pixivコミックが直面した失敗事例💣💥 68

Slide 70

Slide 70 text

レビュー再設計 — pixivコミックの失敗事例失敗事例① 仕様情報をAIに渡していなかった事象コードとしては妥当でも、実装と仕様の乖離をAIレビューは見逃した「何を作るべきか」を知らないまま、コードの書き方だけをレビューさせていた 69

Slide 71

Slide 71 text

レビュー再設計 — pixivコミックの失敗事例失敗事例① 仕様情報をAIに渡していなかった • 対策: 開発フローに仕様書（Spec）作成を追加 • 実装時にAIエージェントにはSpecを渡す • 仕様情報はDesign Docsにまとめて人間にレビューしてもらう 70

Slide 72

Slide 72 text

レビュー再設計 — pixivコミックの失敗事例失敗事例② AIのLGTMで人間レビューが甘くなる事象 AIに「問題なし」と言われると人間のレビューから厳しさが抜け落ちる承認済みに見えるMRは注意力が落ちてしまう（個人差あり） 71

Slide 73

Slide 73 text

レビュー再設計 — pixivコミックの失敗事例失敗事例② AIのLGTMで人間レビューが甘くなる • 対策: AIと人間がチェックする観点を明確にする • 人間は仕様・意図・リスクを見る • 指摘から意図の確認、質問へシフト 72

Slide 74

Slide 74 text

レビュー再設計 — pixivコミックの失敗事例失敗事例③ Design Docs ≒ Plan問題事象 Design Docsに詳細すぎる設計を書いてしまう具体的すぎてレビューコストが増加していた 73

Slide 75

Slide 75 text

レビュー再設計 — pixivコミックの失敗事例失敗事例③ Design Docs ≒ Plan問題 • 対策: 不確実性の高い大規模開発・リファクタリングで採用する • 普段の機能開発ではmini Design Docsを利用する • 通常のDesign Docsより粒度や項目を減らしたミニマル版 74

Slide 76

Slide 76 text

SECTION 05 まとめ 05

Slide 77

Slide 77 text

まとめ土台を整え、レビューを再設計するレビューの土台づくり AIレビューの精度は「文脈の質」で決まる AGENTS.md・Skills・テストを育て、指摘を検証可能にするレビューの再設計 AIと人間の責任範囲を定義し直す実装前レビュー・MR分割・セルフAIレビューを運用する 76

Slide 78

Slide 78 text

AIは万能なレビュアーではない。任せる領域を設計した分だけ、仕様・設計・意図・リスクに集中できる。 77

Slide 79

Slide 79 text

おわりに資料 • プロンプト・スキルは可能な限り、公開予定 • 質問は Ask the Speaker でお待ちしています 78