02. バイブコーディングで作ったExpoアプリの品質チェックリスト

セキュリティを見る前に、まず確認したいのが「そもそも壊れていないか」です。

バイブコーディングでは、動く画面が短時間で手に入る代わりに、開発者自身がコードの全体像を把握しないまま完成扱いになりがちです。その結果、自分がテストした経路だけが動き、それ以外が静かに壊れているという状態が起こります。

この記事では、Expoアプリの品質を「機械で測れるもの」と「手で触らないと分からないもの」に分け、それぞれのチェックリストとして整理します。

この記事のサブコンテンツ

品質を2種類に分けて考える
機械で測る：型・Lint・依存関係・ビルド
手で触る：状態・境界値・OS差
アクセシビリティという見落としがちな品質
パフォーマンスの最低ライン
リリース前の総合チェックリスト
まとめと次のステップ

1. 品質を2種類に分けて考える

品質チェックには、性質のまったく違う2種類があります。

種類	例	特徴
機械で測れる品質	型エラー、Lint違反、脆弱性、ビルド成功	コマンド一発で分かる。必ず全部やる
手で触らないと分からない品質	空状態、通信断、極端な入力、片手操作	人間が意図的に試すしかない。優先順位をつける

前者はコストがほぼゼロなので言い訳が効きません。後者は無限にあるので、壊れたときの被害が大きい順に潰します。

2. 機械で測る：型・Lint・依存関係・ビルド

まず、次の4つを順に実行します。ここで落ちるものがあるうちは、手で触るテストに進む意味がありません。

# 型エラーがないか
npx tsc --noEmit

# Lintルールに違反していないか
npx expo lint

# 依存パッケージに既知の脆弱性がないか
npm audit

# Expoの推奨構成からズレていないか
npx expo-doctor

npx expo-doctor は特に効きます。SDKバージョンと合っていないライブラリや、設定ファイルの不整合など、実機では気づけないのにビルド時に爆発する問題を事前に教えてくれます。

エラーが出たら、内容をそのままAIに貼り付けるのが最短経路です。

以下は `npx expo-doctor` の出力です。
それぞれの警告について「何が問題か」「放置した場合に何が起きるか」
「具体的な修正コマンドまたは変更内容」を教えてください。
緊急度の高い順に並べてください。

[ここに出力を貼り付ける]

3. 手で触る：状態・境界値・OS差

① 画面の「4つの状態」を全部見る

AIは基本的に「データがある正常な状態」だけを作ります。残り3つは自分で確認してください。

空状態（Empty）：データが0件のとき、何も表示されない寂しい画面になっていないか
読み込み中（Loading）：一瞬でも真っ白な画面が出ていないか
エラー（Error）：失敗したことがユーザーに伝わるか。無言で何も起きないのが最悪です
正常（Success）：ここだけは誰でも確認します

② 境界値を入れてみる

入力欄には、意地悪な値を入れてください。

空文字、スペースだけ
絵文字（👨‍👩‍👧‍👦 のような結合絵文字が特に危険）
200文字を超える長文
改行を含む文字列
前後に空白が付いた文字列

「空文字で追加ボタンを押したらクラッシュする」は、AI生成アプリで最もよく見るバグです。

③ 通信と端末の状態を変える

機内モードにして起動する
操作の途中で機内モードに切り替える
アプリをバックグラウンドに送って数分後に戻る
端末を再起動してから開く

④ OSと画面サイズの差を見る

iPhone SE のような小さい画面で文字が切れていないか
Android の戻るボタン（ジェスチャー含む）で意図しない画面に飛ばないか
iOS のノッチ・ホームバーとUIが重なっていないか
OSの文字サイズを最大にしてもレイアウトが崩れないか

4. アクセシビリティという見落としがちな品質

AIはアクセシビリティ属性をほぼ付けてくれません。しかしこれは、ストア審査で指摘される可能性があり、かつユーザー層を広げるものです。

最低限、次の2つだけでも入れておきます。

タップ領域は44×44以上：小さすぎるチェックボタンは、指の大きい人や手が震える人には押せません。
アイコンだけのボタンにラベルを付ける：スクリーンリーダー利用者には、アイコンは何も伝えません。

<TouchableOpacity
  onPress={handleToggle}
  accessibilityRole="checkbox"
  accessibilityLabel="読書"
  accessibilityState={{ checked: isCompleted }}
  hitSlop={{ top: 8, bottom: 8, left: 8, right: 8 }}
>
  <Text>{isCompleted ? '完了済み' : '未完了'}</Text>
</TouchableOpacity>

hitSlop は、見た目を変えずにタップ判定だけを広げるプロパティです。デザインを崩さずに押しやすさを足せるので、小さなボタンには積極的に付けてください。

5. パフォーマンスの最低ライン

凝った最適化は不要ですが、次の2つは体感に直結します。

一覧は FlatList を使う：ScrollView の中で map() して全件描画すると、件数が増えた瞬間に固まります。AIは楽なほうの map() を選びがちなので、リストを見つけたら確認してください。
画像はサイズを落としてから入れる：4000pxの写真をそのまま assets/ に置くと、アプリのサイズと起動時間が悪化します。

体感が重いと感じたら、そのまま相談できます。

リストを100件ほど表示すると、スクロールが引っかかります。
`app/(tabs)/index.tsx` と `components/HabitCard.tsx` を読んで、
再レンダリングの原因と、FlatList / memo を使った改善案を提示してください。

6. リリース前の総合チェックリスト

機械で測る（全部やる）

npx tsc --noEmit が通る
npx expo lint が通る
npm audit の high 以上に対応済み、または内容を把握している
npx expo-doctor の警告に対応済み
eas build --profile preview が成功する

手で触る

空状態・読み込み中・エラー・正常の4状態をすべて目で見た
空文字／絵文字／長文を入力しても壊れない
機内モードで起動しても、無言で固まらない
アプリをタスクキルしてもデータが残る
iPhone SE 相当の小さい画面で文字が切れない
Androidの戻る操作で行き止まりにならない
OSの文字サイズを最大にしてもレイアウトが破綻しない

アクセシビリティ

主要なボタンのタップ領域が44×44以上ある
アイコンのみのボタンに accessibilityLabel が付いている

7. まとめと次のステップ

品質チェックの半分は、コマンド4つで終わります。残り半分は、「自分がまだ試していない操作」を意図的に探す作業です。

一通り点検すると、直したい箇所がまとめて出てくるはずです。次の記事では、それをAIに安全に片付けさせる「03. AIにリファクタリングを依頼するプロンプト」に進みましょう。