こちらは、MIXI DEVELOPERS Advent Calendar 2025の12日目の記事になります。
こんにちは。家族アルバム「みてね」（以下、みてね）でAndroidの開発をしているnagaと申します。
本記事では、みてねのAndroidアプリがEdge-to-edge表示対応を進める中で取り組んだ、AIと共に開発し品質を担保する取り組みについて紹介します。
Edge-to-edge表示の詳細については、下記ページをご覧ください。
背景
みてねのAndroidアプリは、2015年にリリースされ、約350の画面が存在しています。
アプリ内の機能はサポートする全てのバージョンで利用可能で、2025/12/12時点ではAndroid 9.0以降をサポートしています。
画面構成は View System (Android View)が多く、次いで Jetpack Compose、一部が相互運用APIで構成されています。
画面の基底クラスが複数存在していることやコードベースの歴史が長いことから、Edge-to-edge対応を一括で行うのは難しい状況でした。
そのため、アプリの体験を大きく損なわないように、機能単位で段階的に対応する方針でEdge-to-edge対応を進めています。
みてねのAndroidアプリ開発についてはこちらをご覧ください。
ガイドラインを整備してAIに実装を任せる
AIに自力実装させるためのガイドラインを作る
AIに確度の高い実装をしてもらうために、ガイドラインを用意することから始めました。
ガイドラインの作成にあたっては、以下の2つのアプローチを組み合わせています。
まず、公式ドキュメントにアクセスできるAIに一般的な実装パターンを整理してもらいました。具体的には、
Material3 Jetpack ComposeでBottomSheetのEdge-to-edge対応する方法について、公式ドキュメントを参考に整理してください
といった形で依頼し、標準的な実装方法を網羅的に整理しました。
これらは一つのAIのみに依頼するのではなく、複数のAI (ChatGPT, Gemini)やDeep Researchを活用することで品質を高めました。
次に、プロジェクトのコンテキストにアクセスできるAIに、コードベース固有の実装パターンを整理してもらいました。こちらは、
xxxActivityのEdge-to-edge対応方法について、拡張関数の内部実装を含めて整理してください
といった依頼をして、プロジェクト独自のルールを整理しました。
みてねでは独自のデザインシステムを採用しているため、使用するデザインシステムのコンポーネントやパスを含めて出力するようにしています。
これらの回答をMarkdownにまとめることで、ガイドラインの初稿を作成しました。
ガイドラインの作成自体はAIに任せたため、手直しを含めても30分程度の作業時間で完了しました。
なお、具体例を含めると出力品質が向上すると考え、最低1つは人間が手動で実装しそれを正解データとしてガイドラインに記載しています。
完成したEdge-to-edge実装ガイドラインの初稿
こうして完成し、現在も運用しているガイドラインの概要は以下の通りです。
実際のガイドラインは具体的なコード例なども含み長文ですが、AIに渡すことを前提に、自然言語での説明よりも構造化された情報や実例のリンクを優先して記載しています。
# 内容
Android 15 (SDK 35)以降で強制されるEdge-to-Edge対応の実装ガイドラインです。アプリ表示領域をステータスバー・ナビゲーションバーの下まで拡張するUIを実現する方法をまとめています。
# 実装において便利な点・ポイント
1. パターン化されたコード例
- Compose: enableEdgeToEdge用拡張関数() + Scaffold + safeDrawingPadding()
- AndroidView: ViewCompat.setOnApplyWindowInsetsListenerで動的パディング設定
2. よくある問題と解決策
- API 29以下のSnackbar/IME問題
- BottomSheetのAPI 30以下表示崩れ → Material3 ModalBottomSheetのインテグレーション方法
- システムバー文字が見えない → enableEdgeToEdge用拡張関数()
3. チェックリスト付き
- 動作確認項目・実装確認項目が明確
4. 実績あるPR参照
- 各パターンに対応するPRリンクがあり、実際のコード例を参照可能
5. フラグ制御パターン
- 既存画面への段階的適用方法・フラグ管理の手順など
etc...
ガイドラインを使ってAIに実装してもらう
ガイドラインができたら、実際にAIに実装を任せます。今回は、Claude Code (Sonnet 4.5) x Serena MCP を利用した実装の流れを紹介します。
ガイドラインを認識できる状態で Claude Code を立ち上げ、Planモードで下記のようにプランニングを実施しています。
Edge-to-edge.mdを参照して、ガイドラインに沿って下記の画面を対応してください。
xxxActivity
yyyActivity
zzzActivity
なお、実装計画は厳密かつ簡潔に、レビューできる粒度で作成してください。
実装は PR #12345 や aaaActivity を参考にしてください。
ここで重要なのは、計画に期待通りの実装が書かれている状態にすることです。
計画段階で曖昧な指示を出すと修正作業に時間がかかるため、自分の意図を可能な限りインプットするようにしています。
意図通りの計画が出来上がったら、Approveして実行します。その際に、Serena MCPを併用すると事例探査が効率化するため併せて使用しています。
結果的にモデルの性能に頼らないガイドラインになった
ガイドラインを整備し始めた当時、主流のAIエディタは Agent/Askモードが搭載されたCursorとVS Codeでした。モデルもGPT-o1とClaude Sonnet 3.5が主流だったためか、言語化していない部分を適切に対応する能力が今より低かった記憶があります。その反面、詳細な指示を追記することで、より強固なガイドラインができたとも感じています。
AIからのフィードバックで継続的にガイドラインを育てる
意図通りのアウトプットが出なかった場合、修正依頼を出すことは多々あるかと思います。
より確実なアウトプットを出してもらうために、AI自身にどこが理解できなかったか・不明だったかフィードバックをもらうようにしています。
Copilot Agentにフィードバック依頼を出している様子
そのフィードバックをAI自身にガイドラインに記載してもらうことで、徐々にアウトプットの確度が上がっていきました。
現在では、LLMモデルの性能向上もありほぼ確実に意図通りのアウトプットを出せるようになりました。
別のLLMと協力して例外対応してもらう
2025/12/12現在はWeb検索できるAI Agentも増えていますが、それでもなおLLMによる得意・不得意は存在しています。
その際に活躍するのが o3-search-mcp です。名前にo3とありますが、gpt-5やo4-miniなども利用可能です。
こちらのMCPを利用することで、Claude が分からないことを OpenAI のLLMと協力して解決できるようになります。
実際にガイドライン外の対応が発生した際も、協力して対応を試みてくれました。
それでも難しかったデバッグ対応
ここまで、実装のAI移譲について紹介してきましたが、一番の壁となるのがデバッグ作業です。
エミュレータの操作をAIに移譲できないか、mobile-mcp や ADBコマンドを組み合わせた自動化を試みましたが、要求レベルを達成できず断念しているのが現状です。
そのため、現時点では開発者がデバッグし、網羅的なチェックはQAチームにお願いする流れで進めています。
実際に人力で検知した不具合の事例です。
- API29以下で古い画面の SnackBarに画面下部のInsetsが当たらない
- 追加で拡張関数を用意して対応
- API29以下でIMEの開閉時にInsetsが正しく当たらない
android:windowSoftInputMode="adjustResize"をManifestに追加- API30以下で Material2 BottomSheet の表示が崩れる
- Material3 ModalBottomSheetに移行する
etc...
なお、発生した不具合は確認事項として全てガイドラインに追記し、再発を防ぐようにしています。
結果として人力比で2倍の効率になった
これらの取り組みにより、手動で実装していた頃と比べて約半分の時間で対応できるようになりました。定型的な対応をAIに任せることで、人間はレビューや例外対応に集中できるようになったのが大きいと感じています。
クラウド上で動くAI Agentを利用して、プランニングを効率化する
続いて、プランニング段階のAI活用について紹介します。
みてねでは、GitHub Copilot Coding Agent, Claude Code GitHub Actions, Devin.ai, OpenAI Codex を併用しています。
今回は、一例として"画面遷移体系を整理する"作業をGitHub上で行う流れを紹介します。
まず、起点となるActivity名を記載、調査範囲を明示したGitHub issueを作成します。
xxxxActivity以下の遷移体系を整理してください。
- 構成しているActivity/Fragment
- Screen（Compose/Android View)
- BottomShee（Compose/Android View)
- ここに関してはM2かM3かを含めて確認して欲しいです
- 調査階層については、基本的には4次まで、まだ続きがあればさらに調べてください。
- 遷移体系をMermaidにしてください
結果をmdファイルに出力してください。
作成できたら、Copilot / Claude をアサインして、調査完了を待ちます。
その後、出力されたMarkdownファイルをベースにチームでプランニングを実施し、対応順番やリリースグループを決めています。
みてねの「1秒動画編集」機能を調査した際の結果
実際の画面のMermaid図
この方法のメリットとしては、
- ローカルのコードベースを汚すことなく検索が可能である
- 人間がローカルで別の作業を行える
点にあると考えています。
ローカル環境のClaude CodeやCursor Agentを使っても同様の結果は得られます。
しかし、このような調査に関してはクラウドで対応したのちにローカルで詳細な調査をすると、より効率が上がると感じています。
限られたローカルPCのスペックで並列作業を行うと、メイン作業のビルド時間が遅くなるなど作業に支障をきたすため、適切な分散が重要だと考えています。
なお、詳細な調査や対話的かつ迅速に解決したい問題の場合はローカルで対応しています。
AIを利用して、対応漏れ画面を検知し品質を担保する
みてねでは、Edge-to-edge対応画面をNotion データベースで管理しています。しかし、実装前に事前に念入りな調査を行ったとしても、画面数の多さゆえ対応が漏れてしまう画面もわずかながら存在します。
使用している Edge-to-edge対応ポータルページ
それを未然に防ぐ取り組みとして、 Claude Code x Serena MCP を使用した、対応漏れ画面を検知する取り組みを行っています。
みてねでは、共通の拡張関数やテーマを利用してEdge-to-edge対応をしています。
そのため、該当する記述を検索することで、適切な対応がされているか AI Agent が検知できます。
そこで活躍するのが、プロジェクト構造をセマンティックに分析し、必要な情報を適切にAgentに提供してくれる Serena MCPです。
Serena MCPは現在Kotlinに正式対応しているため、Androidのコードベースに適した情報を提供してくれます。
現在では、機能単位の実装が完了したタイミングや、スプリント終盤で手動で検知を行っています。
今後はNotion MCPを利用したデータベースの自動連携や、CI化で定期実行することで、より確実な品質担保が行えると考えています。
さいごに
2025/12/12現在、みてねアプリの約90%以上がEdge-to-edge対応済みとなりました。
これらのナレッジはAndroid 16で発生する 画面方向、サイズ変更、アスペクト比の制限廃止対応でも活用できると考えています。
一筋縄ではいかないことの多いUIの改修対応ですが、この記事がみなさまのお役に立てば幸いです！
MIXI DEVELOPERS Advent Calendar 2025では、MIXI GROUP の各社に所属するエンジニアが多様なアウトプットをおこなっています。他の記事もぜひご覧ください！
Discussion