AIがレビューする時代に、Androidエンジニアは何をレビューするのか 〜土台づくりとレビュー再設計〜
kobakenpixiv inc.
AIコーディングの普及により、Android開発では実装・テスト・レビュー補助の一部をAIに任せられるようになりました。一方で、PRの滞留、レビュアーごとの観点のばらつき、Jetpack Compose / Edge-to-Edge / マルチモジュール構成などAndroid固有の文脈をAIが読み違える問題は残ります。本セッションでは、10年以上の歴史を持つ大規模プロダクトであるpixivコミックAndroidでGemini Code AssistによるPRレビューを導入・運用した経験をもとに、AI時代のコードレビューをどう再設計したかを共有します。 前半では、AIレビューを継続運用するための土台づくりを扱います。[AGENTS.md](http://agents.md/) / Skills に記述したプロジェクトの設計方針、Composeの状態管理、DI、Kotlinコーディング規約、単体テスト・E2Eテストの整備が、AIレビューの精度や誤検知にどう影響したかを紹介します。特に、ViewBinding / DataBindingの生成クラスをAIが参照できずビルドエラーと誤判定した事例など、Androidプロジェクトならではの失敗を取り上げます。 後半では、人間レビュアーの責任を「コードの書き方」から「仕様・設計・意図・リスク判断」へ移すためのレビュー設計を説明します。UI微修正と、課金・認証・個人情報を含む高リスク変更を同じ強度でレビューしない運用、PR作成者によるセルフAIレビュー、人間が最終判断すべき観点を整理します。また、仕様情報をAIに渡さなかったことで仕様との乖離を見逃した事例や、AIレビューワークフロー自体が運用コストになった事例も共有します。 AIを万能なレビュアーとして扱うのではなく、任せられる領域と人間が責任を持つべき領域を、実運用での失敗とトレードオフを含めて整理します。AIコーディングを導入したもののレビューがボトルネックになっているAndroidチームに向けて、明日から使えるAIレビュー土台チェックリストと、リスクベースのレビュー再設計のたたき台を持ち帰ってもらうことを目指します。
対象者
- AIコーディングを導入済みのAndroidチームで、PRレビュー待ちや観点のばらつきに悩むテックリード / シニアAndroidエンジニア - Jetpack Compose / マルチモジュールなど、Android固有の文脈をAIレビューにどう渡すべきか悩んでいる開発者 - AIにどこまで任せ、どこから人間が責任を持つかをレビュー運用として設計したいAndroidエンジニア