DroidKaigi 2026 · Poster Session 数年滞っていたダークモード対応を およそ2週間で完了させる せる Human in the Loop で大規模なUI移行を行うためのプロセス values/ 1 対応した画面数 Wave 1〜5 の累計 2025.11 2026.05 02 事前準備1: 変更を逐次mainにいれる基盤 画面間の一貫性が命 = 中途半端に公開できない。全 リリースに混ぜつつ未公開のまま進める土台を先に作る 必要がある。 surface_primary #FFFFFF に値を集約 valuesnight/ ダークモード対応 =「使う箇所から _light を 消すだけ」に変換 or DesignSystemに則って いない部分を修正する作業 事前準備2: iOS の対応を丸ごと input AI が darkmode/wave_N の PR を作成 2 チーム（人間）が毎日ビルドを触って 成果物をレビュー へ iOS のダークモード対応 PR 約100本（2025.11– 2026.03） AI が時系列で確認し、対応の戦略・ハマった 問題点・人間の判断例を抽出 コンテキストとして活用できるように凝縮 Wave 1 のタスクリストを自動生成 し、 ループのはじめが効率よく回るように設計 フィードバックは ある？ No 土台 連休 4/30–5/12 Wave 1 5/8–5/18 Wave 2 5/15–5/19 Wave 3 5/19–5/20 Wave 4 06 ★ 5/20–5/22 5/27–5/29 人間主導 ★ 9割完了 ループを支える 2 つの skill （① と ③ が参照し合う） /feedback-to-tasks フィードバックを 「AI 対応可」と「人間判 断」に二分し、AI 分は 1 タ スク = 1 コミットに分解 Wave が終わるたびに知見を skill へ書き戻す。同じ失敗は次の Wave で は起こらない ようになります。実質 1.5 日スプリントのアジャイル開発 のようなプロセスになります。 特に /feedback-to-tasks は AIに対応可能なものなのか、人間の判断が 必要なのかを蓄積した記録と、実際のコードベース両方を確認して 裏取りをすることで、その精度を高めます。人間が対応してほしいと 判断するスコープを小さくすることが最後の Wave 5 (人間主導による 対応)の作業時間を短くするために必要です。 なぜ大きな事故を防げたのか？ ロジックを変えない 作業をリソース置換に限定し、失敗パターンを 「見た目が崩れている」のみになるようにした 2. Wave 反復の多重検査 同じ画面に複数の Wave・人 で何度もチェック が入るため、ヌケモレが小さくなる 3. Human-in-the-Loop 毎日のエンジニアのレビューに加え、PdM / デザイナーも一部Waveでは入り、 対応のスコープと色味の細やかな判断を行った 1. 07 End · ダークモード対応 完了 色置換マップと Compose / styles.xml / drawable の罠 を Wave ごとに積み上げる ナレッジベース GW タイトルの「2週間」= Wave 1 着手 5/8 → Wave 4 マージ 5/22。ここまで AI 主導で対象の 9 割が完了。 AI が判断を委ねた残りは Wave 5 で人間主導に切り替えて 5/29 に回収し、リリースを行いました。 事前準備含めて約 1 ヶ月（GW 含む）、品質担保のE2E テストでもほとんど問題は出ませんでした。 フィードバックを一箇所に集約し、 ナレッジとして蓄積 /darkmode-plan 結果と作業タイムライン AI 主導（実装中は流し見） #111111 FeatureToggle OFF の間は values-night が 読まれない = 何度リリースしても未公開の まま 03 の定義 1 3 残り 1 割は Wave 5（人間主導） Wave 5 → surface_primary_light semantic_colors.xml values/ 05 画面ごとに完璧を目指さず、広く浅く全画面にダークモード対応を 行い、毎日チーム30分触ってフィードバックを集める。各試行を Wave と呼び、生成 → 暫定版配布 → レビュー → ナレッジ化を 1 サイクルとして反復する。人間が関与するのはレビューの タイミングだけで、それ以外 AI がタスク分解含めて自走し続ける。 既存カラーを全部 rename Wave 4 時点の完成度 100+ 画面を触った結果として Wave ループで自走させるプロセス Start · wave_1 9割 ToggleOnの後のデグレ修正 全 266 コミット中 240 04 Android 10 で登場以来「いつかやりた い」課題。他に優先するべき施策も多く あったため時間を作れなかった。 iOS側の対応を先に行い、DesignSystem 含めた基盤の構築を実行 実装はほとんどAIで、レビューはチーム で行う。対象の9割を約2週間の実働で 完成。 2019 AI 共著コミットの比率 レビュー → マージも約 1 日 なぜ数年、滞っていたのか 5件 1+N_evaw 01 9割 ≈ 日 1 Wave の生成時間 → seY 100+ values-night/ Let's discuss！ 1. このループがうまく動作する条件は 「失敗を確実に検出できる」×「多重検査」× 「PdM/デザイナーの参加」だと考えています。 i18n、アクセシビリティ対応、大規模 rename… あなたのチームなら何に応用しますか？ 2. iOSとAndroidで双方に機能開発をするときに どうやってお互いのコードベースのコンテキスト を共有し、AIによる効率的な開発に 繋げていますか？モノレポ化、ドメイン知識の 外部コンテキスト化、UI操作の自動化等... あなたのチームでの事例を話したいです！ 3. UIに関する変更は Visual Regression Test のよ うな基盤を整備することで人の介在をさらに小さ くできる可能性を秘めています。このような基盤 をどう整備していますか？ 判断例ごと学ばせ、特にDesignSystemに対応していない 画面への判断を iOS に準拠させる ※本ポスターは、実際の開発結果からClaude Code / Claude Design を使用して、まとめたものです。