04. StitchのデザインをExpoで作れる形に分解する
Google Stitchで画面とデザインシステム（配色・共通パーツ）が決まったら、いよいよそれらを**「Expo (React Native) のコードに落とし込める部品単位」に分解する設計作業**に進みます。
Webサイト開発用のHTML/CSSと、スマートフォンアプリ開発用のReact Nativeには、レイアウトの仕組みや制約にいくつかの重要な違いがあります。
Stitchのビジュアルをそのままコード化しようとする前に、React Nativeのコンポーネント構造やStyleSheetの基本ルールに沿って「分解」しておくことで、AIエージェント（GitHub Spec Kit）が迷わずに一発で動作するクリーンなコードを生成できるようになります。
この記事のサブコンテンツ
Section titled “この記事のサブコンテンツ”この記事では、ビジュアルデザインをコード可能なコンポーネントへと分解するプロセスを以下の内容で解説します。
- ビジュアル要素からReact Native基本コンポーネントへのマッピング
- 再利用性を意識したディレクトリ構成とコンポーネント設計（Figmaエクスポート・コード同期含む）
- CSSからReact Native StyleSheet（CSS-in-JS）への変換ルール
- スマホ開発特有のレイアウト制約と対策（セーフエリア・キーボード）
- コンポーネント分解時のセルフチェック
- まとめと次のステップ
1. ビジュアル要素からReact Native基本コンポーネントへのマッピング
Section titled “1. ビジュアル要素からReact Native基本コンポーネントへのマッピング”Stitchで作成したワイヤーフレームを眺め、それぞれの要素がReact Nativeのどのコアコンポーネントに該当するかをマッピングします。
基本的なマッピング表
Section titled “基本的なマッピング表”| Stitchのビジュアル要素 | React Nativeのコアコンポーネント | 主な用途・注意点 |
|---|---|---|
| 画面の土台・四角い枠・仕切り | <View> | レイアウトの最小単位。HTMLの <div> に相当。 |
| テキスト・数値・ラベル | <Text> | 文字を表示するための唯一のコンポーネント。必ずこのタグで囲む必要があります。 |
| ボタン・タップ可能なリスト・アイコン | <TouchableOpacity> または <Pressable> | タップ時にフィードバックを与えるためのコンポーネント。 |
| アイコン画像・ユーザーのアバター | <Image> または <Expo Vector Icons> | ベクターアイコンにはExpo標準の vector-icons ライブラリを使用するのが標準的です。 |
| 入力フォーム・テキストエリア | <TextInput> | ユーザーが文字を入力する部分。 |
2. 再利用性を意識したディレクトリ構成とコンポーネント設計
Section titled “2. 再利用性を意識したディレクトリ構成とコンポーネント設計”Stitchで作成した画面から、「複数の画面で共通して使う部品」と「その画面専用の部品」を切り分けます。
構成レイヤーの分け方
Section titled “構成レイヤーの分け方”- Screens（画面・コンテナ）：
app/ディレクトリ内のルーティングに対応するファイル。状態（State）を管理し、APIやデータベースと通信します。 - Feature Components（機能コンポーネント）：特定の画面に依存する複雑なUI（例：
components/HabitCard.tsx- ダッシュボードの習慣カード）。 - UI Components（共通パーツ）：アプリ全体で使い回す汎用的なUI（例：
components/ui/Button.tsx,components/ui/Input.tsx）。
これらを切り分けておくことで、AIに「この画面を作って」と指示する際、「すでに作成済みの components/ui/Button を使って実装して」と部品を組み立てる指示が可能になり、コードの重複を防げます。
StitchからFigmaへのエクスポートとAuto Layoutの活用
Section titled “StitchからFigmaへのエクスポートとAuto Layoutの活用”Stitchで決定したレイアウトは、Figmaへエクスポート（「Copy to Figma」または html.to.design 等の変換プラグインを使用）することができます。
- Auto Layout（オートレイアウト）の維持：StitchからFigmaに送られたデザインは、画像ではなく、Figmaの「Auto Layout」機能が設定された編集可能なレイヤーとして展開されます。
- React Native Flexboxとの親和性：FigmaのAuto Layoutにおける方向設定（垂直/水平）、アイテムの間隔（Gap）、内側の余白（Padding）は、React Nativeの
flexDirection、gap、paddingスタイルとほぼ1対1で対応しています。
エクスポートしたFigmaのAuto Layout設定値を読み解くことで、StyleSheetへの変換（分解）作業の難易度が大幅に下がり、正確なレイアウト実装が可能になります。
コードベースのインポートと双方向同期
Section titled “コードベースのインポートと双方向同期”Stitchはデザインを生成するだけでなく、あなたの実際のソースコードと直接「同期」する先進的な機能を備えています。
- 既存コードベースのインポート：開発中のExpo (React Native) プロジェクトのディレクトリをStitchに直接インポートして読み込ませることができます。AIがソースコード内のコンポーネント定義やStyleSheetを解析し、デザインキャンバス上に対応するビジュアルUIを瞬時に再構築します。
- ビジュアルとコードの双方向同期（Sync）：Stitch上でボタンをドラッグして並べ替えたり、インプレイス編集（In-place Edits）で色や余白を変更すると、Stitchが自動的にローカルのソースコード（TSX/StyleSheet）を直接書き換えて更新します。逆に、コードを手動で修正した場合も、Stitchのデザインキャンバス上にリアルタイムで変更が反映されます。
この同期機能により、「デザインの修正」と「コードの実装」の垣根が完全に消滅し、手戻りのない直感的なアプリ開発（VibeCoding）が可能になります。
3. CSSからReact Native StyleSheet（CSS-in-JS）への変換ルール
Section titled “3. CSSからReact Native StyleSheet（CSS-in-JS）への変換ルール”React NativeではWebのCSSがそのまま動くわけではありません。JavaScriptのオブジェクトとして記述する StyleSheet.create を用います。Stitchからコードへ変換する際の主要なルールは以下の通りです。
Flexboxの初期値の違い（最重要）
Section titled “Flexboxの初期値の違い（最重要）”- Web CSS：
flex-directionの初期値はrow（横並び）。 - React Native：
flex-directionの初期値はcolumn（縦並び）。スマホは縦長画面が基本であるためです。
単位（px）の省略
Section titled “単位（px）の省略”React Nativeのスタイルでは、数値は単位なしのピクセル（論理ピクセル：dp / pt）で表します。
- Web：
margin: 16px; - React Native：
margin: 16,
影（シャドウ）のiOS/Android対応
Section titled “影（シャドウ）のiOS/Android対応”Stitchで作成した美しいドロップシャドウをコード化する際、OS間での表現の違いに対応する必要があります。
- iOS：
shadowColor,shadowOffset,shadowOpacity,shadowRadiusを使って繊細にコントロール。 - Android：Android OSの仕様上、
elevationという単一の数値プロパティのみで制御します。
4. スマホ開発特有のレイアウト制約と対策（セーフエリア・キーボード）
Section titled “4. スマホ開発特有のレイアウト制約と対策（セーフエリア・キーボード）”Stitchのデザインを実機で再現する際、スマホならではのハードウェアの制約をクリアする必要があります。
セーフエリア（Safe Area）の確保
Section titled “セーフエリア（Safe Area）の確保”iPhoneのノッチ（画面上部の凹凸）や画面下部のホームバー（黒い線）と、アプリのUIが被らないように設計します。
- 対策：画面の最外殻は
<View>ではなく、expo-routerやreact-native-safe-area-contextが提供する<SafeAreaView>で囲み、コンテンツが適切な領域内に収まるようにします。
スクロール（ScrollView）の明示
Section titled “スクロール（ScrollView）の明示”Webブラウザとは異なり、React Nativeの通常の <View> はコンテンツが画面外にはみ出しても自動でスクロールしません。
- 対策：習慣リストや設定画面など、要素が多くなる可能性がある部分は、必ず
<ScrollView>や、大量データの描画に最適化された<FlatList>を用いてコーディングするようAIに指示します。
キーボードによるUIの崩れ防止
Section titled “キーボードによるUIの崩れ防止”入力フォーム（<TextInput>）をタップした際、下からせり上がってくるキーボードによって入力欄が隠れてしまう問題が発生します。
- 対策：キーボードの高さに合わせて画面全体を自動でスライドアップさせる
<KeyboardAvoidingView>の組み込みを仕様として定義します。
5. コンポーネント分解時のセルフチェック
Section titled “5. コンポーネント分解時のセルフチェック”分解図とコンポーネントリストを作成したら、以下の点を確認します。
- 縦横方向の整合性：各コンポーネントが横並び（
flexDirection: 'row'）なのか縦並び（flexDirection: 'column'）なのか明確に区別できているか？ - 動的データの考慮：習慣カード内の「習慣の名前の長さ」によってレイアウトが崩れないよう、文字の切り詰め（
numberOfLines）などのルールが考慮されているか？ - 状態遷移の対応：読み込み中（Skelton UI）や、リストが空のときの表示コンポーネントが定義されているか？
6. まとめと次のステップ
Section titled “6. まとめと次のステップ”この記事では、Google StitchのビジュアルデザインをExpo (React Native) で実装可能なコンポーネント単位やスタイルシート（StyleSheet）の仕様に分解する方法を学びました。
いよいよリデザイン編の最終章です。これまでに作成した画面案、ユーザー導線、スタイルルール、コンポーネント分解の成果物を1つのドキュメント（デザイン企画書・仕様書）に集約し、開発AI（GitHub Spec KitやAntigravity IDE）にインプットする準備を整えましょう。
次の記事では、AI共同開発の司令書を作成する「05. VibeCoding用のデザイン企画書を作る」に進みましょう。