AI Studio のネイティブ Android vibe coding を初めて試したとき、プロンプト 1 つで設定画面がまるごと立ち上がり、思わず声が出ました。レイアウトも遷移も動いています。ただ、その生成コードを既に何年も動いているアプリへそのまま入れようとして、手が止まりました。新規プロジェクトで動くことと、稼働中のアプリの一部として正しく振る舞うことは、別の話だからです。
私自身が個人開発で保守しているアプリは、長く運用しているぶん、画面の都合だけでは決められない約束事を抱えています。生成コードはその文脈を知りません。ここでは、AI Studio が出した Kotlin を本番アプリに取り込む前に通す検めを、機械で弾く部分と人が見る部分に分けて設計します。
なぜ「新規で動く」と「本番に入れて安全」は違うのか
vibe coding が出すコードは、単体では正しく動きます。問題は、それが既存アプリの前提と噛み合うかどうかです。生成器は次を知りません。
既存の依存性注入の流儀、画面間で共有している状態の持ち方、独自の Activity 基底クラス、アプリ全体で守っているスレッドの約束。これらは画面のスクリーンショットからは読み取れないため、生成コードは「その場では動くが、アプリの文脈では事故になる」書き方をしがちです。
本番で静かに壊れる 3 領域
実際に取り込み前のレビューで繰り返し弾いたのは、次の 3 領域でした。
領域 生成コードがやりがちなこと 本番で起きること
ライフサイクル Activity の再生成を考えず状態を握る 画面回転や復帰で状態が飛ぶ メモリリーク Context や View を長命オブジェクトに渡す 画面往復でメモリが伸び続ける スレッド メインスレッドで I/O を呼ぶ 低速端末で ANR・体感のもたつき
いずれもエミュレータの短い操作では表面化しない落とし穴で、本番運用に入って初めて顕在化します。だからこそ、人の目視に頼る前に機械で弾く層を置き、形の決まった事故を先に回避します。
pre-merge ゲートを差分にだけ効かせる
最初の防御は静的解析です。ただアプリ全体に Detekt をかけると既存の警告に埋もれて、生成コード由来の問題が見えません。そこで「今回取り込む差分のファイルだけ」に厳しめのルールを当てます。
// detekt-generated.yml — 生成コード取り込み専用の厳格プロファイル complexity: LongMethod: threshold: 40 TooManyFunctions: thresholdInClasses: 12 potential - bugs: Deprecation: active: true performance: SpreadOperator: active: true style: ForbiddenComment: comments: [ 'TODO' , 'FIXME' , 'STOPSHIP' ] 差分のファイルだけに当てる実行はシェルで絞り込みます。
#!/usr/bin/env bash set -euo pipefail # 取り込みブランチで変更された .kt のみを抽出 CHANGED = $( git diff --name-only origin/main...HEAD -- '*.kt' ) if [ -z " $CHANGED " ]; then echo "対象なし" ; exit 0 ; fi
# 生成コード専用プロファイルで、変更ファイルだけを検査 echo " $CHANGED " | xargs detekt \ --config detekt-generated.yml \ --fail-on-issues \ --report txt:build/detekt-generated.txt echo "✅ 差分のみ静的解析を通過" origin/main...HEAD の三点指定で「分岐後に触れた分」だけを取れます。全体スキャンではなく差分に絞るのが肝で、これだけで生成コード固有のノイズがほぼ表に出ます。
ライフサイクルとリークは機械では足りない
静的解析はメインスレッド I/O のような形の決まった問題は捕まえますが、「この状態の持ち方は再生成で飛ぶ」という設計の話は捕まえきれません。ここは人が見る前提で、見る観点を固定します。
私が必ず確認する観点は次の 4 つです。
画面回転で復元すべき状態が、再生成に耐える置き場（ViewModel など）にあるか
Context を渡している先が、画面より長生きしないか
コルーチンのスコープが画面の寿命に紐づいて、離脱時に確実に止まるか
既存の基底クラスや共通の遷移を迂回して、独自実装を持ち込んでいないか
観点を 4 つに固定しておくと、生成コードのレビューが「なんとなく読む」から「この 4 点を順に潰す」に変わり、見落としが減りました。
5,000 行を一度に入れない
いちばん効いたのは、技術ではなく取り込み方の工夫でした。vibe coding は画面群をまとめて生成しますが、それを 1 つの大きな変更で入れると、レビューも切り戻しも一気に重くなります。
1. 生成物を機能境界で分割する（設定・一覧・詳細…）
2. 1機能ずつブランチを切り、pre-merge ゲートを通す
3. 人の4観点レビューを通す
4. 1機能だけ本番に出し、クラッシュ率とメモリを2〜3日観測
5. 異常がなければ次の機能へ進む
私の場合、設定画面の生成を最初の 1 機能として入れ、クラッシュ率が普段と変わらないことを確認してから次へ進めました。段階を踏むと、もし問題が出ても原因が 1 機能に閉じるので、切り分けが速くなります。一度に入れて全体が不安定になると、どの生成由来かを追うだけで数日溶けます。
どこまで任せ、どこから人が持つか
最後に判断軸を表にします。vibe coding は速い反面、責任の所在が曖昧になりがちなので、線引きを先に決めておくと迷いません。
工程 担い手 理由
画面の雛形生成 AI Studio 速度の恩恵が最も大きい 静的解析・差分ゲート 機械 形の決まった事故は機械が確実 ライフサイクル・設計レビュー 人 アプリ固有の文脈は人しか持たない 本番投入の可否判断 人 観測データを見て最終責任を負う
生成の速さに引きずられて、最後の 2 行まで機械任せにすると、稼働中のアプリでは取り返しがつきにくくなります。生成は思い切り使い、検めは静的ゲートと 4 観点と段階導入で固める。私はこのやり方を個人的にお勧めします。この組み合わせが、いま私が個人開発で実際に使っているやり方です。新しい生成体験を本番に活かしたい方の、足元を固める一助になればうれしいです。