·9 分で読めます

Stitch のデザインを Android へ:Antigravity ワークフロー

Google 公式デモによるエンドツーエンドのワークフロー:Stitch のデザイン案を Antigravity と Android CLI で Jetpack Compose コンポーネントに変換し、エミュレーターで検証してから実機で動作させ、Web ルートとの比較も行います。

S
Stitch Prompt Team
Content Team
StitchAIチュートリアル

これまで Stitch の「デザイン to コード」の経路はほぼ Web に限られていました。HTML、React、Vue、Next.js です。Android の開発者はデザインカンプを見られても、ネイティブの成果物は得られませんでした。

状況は今週変わりました。Google for Developers がエンドツーエンドのワークフローを公式にデモしたのです。Stitch MCP を Antigravity と Android CLI に接続すると、エージェントがデザインカンプからネイティブアプリまでの完全な経路を自動で完遂できます——出力されるのは WebView のラッパーではなく、本物の Jetpack Compose コンポーネントです。

本記事では、このワークフローの三種の神器の役割分担、環境構築、実践手順、検証の閉ループを分解し、どの細部が公式デモで確認されたもので、どれが実測による補足が必要かを説明します。

注記:本記事は公式デモと Android CLI のリリースノートに基づいて整理しています。具体的なバージョンの挙動は、あなたがインストールした Antigravity と Android CLI を基準にしてください。

1. 公式デモが語ったこと:Stitch のデザインカンプから実機動作まで

公式デモのワークフローは 4 ステップにまとめられます。

  1. Stitch から UI デザインカンプをインポートする。
  2. エージェントがネイティブの Jetpack Compose コンポーネントに変換する(WebView でも React Native でもない)。
  3. エミュレーターでビルドと画面を検証する。
  4. 実機で最終ビルドを動作させる。

4 ステップすべてをエージェントが自動で行い、人はタスクの指示と結果の検収を担当します。この経路の象徴的な意味は、Stitch の着地点が Web から Android ネイティブへ拡大したことです。

2. 三種の神器の役割分担:Antigravity/Stitch MCP/Android CLI

3 つのツールがそれぞれの役割を担い、どれも欠かせません。

ツール役割担当すること
Antigravityホストとなるエージェント環境エージェント、タスク、実行フローの管理
Stitch MCPデザインソースの接続エージェントが Stitch プロジェクトのデザインカンプを読めるようにする
Android CLIネイティブエンジニアリングの能力ビルド、レンダリング検証、デバイスへのデプロイ

背景情報:Antigravity 2.0 は Android CLI と skills を正式に統合し、並列ローカルエージェント管理、Projects、スケジュールタスク(/schedule)、CLI と SDK などの能力をもたらしました。

3. 環境構築(Android CLI のインストールを含む)

Android CLI は主要なパッケージマネージャーでのインストールに対応しています。プラットフォームに応じて選んでください。

# macOS / Linux
brew install android-cli

# Windows
winget install android-cli

# Ubuntu
sudo apt-get install android-cli

具体的なパッケージ名と最新のインストール方法は公式のリリースノートを基準にしてください。インストール後、Antigravity で 2 つのことを行います。

  1. Stitch MCP を設定し、エージェントがあなたの Stitch プロジェクトにアクセスできるようにする。
  2. Android skills をインストールし、エージェントに Android プロジェクトのビルドと検証の能力を持たせる。

4. 実践:デザインカンプ → Jetpack Compose コンポーネント

環境が整ったら、1 つのタスク指示で経路全体を起動します。

Import the login and home screens from my Stitch project [ID],
convert them into Jetpack Compose components following Material 3,
validate the build in the emulator, then deploy to my connected device.

この指示には 4 つの重要な取り決めが含まれます。

  • ソース:Stitch プロジェクトと具体的なページ(login / home)を指定する。
  • ターゲット:Compose コンポーネントに変換し、Material 3 の規約に従う。
  • 検証:まずエミュレーターでビルド検証を完了する。
  • 納品:接続済みの実機にデプロイする。

5. 検証の閉ループ:エミュレーター、Journeys、実機

Android 側の検証手段は Web よりも豊富で、公式デモでは 3 つの階層が使われています。

  • エミュレータービルド:まずコードがコンパイルでき、画面がレンダリングできることを確認する。
  • Journeys:ユーザーフローを自然言語で記述し、ツールがインタラクションの経路を自動で検証する。
  • 実機動作:最終ビルドを実機にデプロイし、実環境での挙動を確認する。

この「エミュレーター → フロー → 実機」という検証の順序は、単独で参考にする価値があります。Stitch を使わなくても、Android エージェントのワークフローの既定の検収経路として使えます。

6. Stitch → React/Vue の Web ルートとの比較と選択

2 つのルートは成果物がまったく異なり、選択はターゲットプラットフォーム次第です。

項目Web ルート(React / Vue)Android ネイティブルート(Compose)
成果物Web のコードとコンポーネントJetpack Compose コンポーネント
検証方法ブラウザエミュレーターと実機
適した用途Web サイト、Web アプリ、クロスプラットフォームAndroid アプリ、ネイティブ体験
エコシステムのツールNext.js、Vite、shadcn/ui などAndroid Studio、Gradle など

判断はシンプルです。ターゲットが Web なら Web のパイプライン、Android ならネイティブのパイプライン。両者は同じデザインカンプと DESIGN.md の規約を共有できますが、成果物が互いを代替できると期待しないことです。

7. 制限と注意点

  • ネイティブ変換はピクセル単位ではない:デザインカンプから Compose コンポーネントへの変換は Material の取り決めに従うため、視覚的な細部は人手での微調整が必要です。
  • 基礎的なエンジニアリング知識には依然価値がある:ビルドの失敗、署名、依存関係の衝突などは、エージェントがすべて自動で解決できるとは限りません。
  • バージョンの細部は実測を基準に:公式デモが確認したのはエンドツーエンドの経路と成果物の種類です。具体的なコマンドの引数は手元の CLI の出力を基準にしてください。
  • 小さな範囲から始める:まず 1〜2 ページを変換して経路を通し、それから範囲を広げましょう。

8. よくある質問(FAQ)

Q1:Android 開発の経験がなくても、この経路は使えますか?

始めることはできますが、基本的な Gradle のビルドとエミュレーターの概念は理解しておくことをおすすめします。ビルドエラーに遭遇したとき、基礎的な認識があれば切り分けの時間を大幅に短縮できます。

Q2:生成される Compose コードの品質はどうですか?

「動作する出発点」であり、ピクセル単位の再現ではありません。Material 3 の規約に沿って段階的に調整し、各ステップをエミュレーターで検証することをおすすめします。

Q3:Stitch から直接 React コードをエクスポートするのと何が違いますか?

成果物が異なります。一方は Compose コンポーネント、もう一方は Web のコードです。選択の根拠はターゲットプラットフォームで、両者は直接互換できません。

9. まとめ

この公式ワークフローは、Stitch の能力の境界を Web から Android ネイティブへ押し広げました。デザインカンプ、エージェント、ネイティブコンポーネント、エミュレーター、実機が、初めて完全な公式経路としてつながりました。Android チームにとっては、まず小さなプロジェクトで流れを検証し、それから正式な開発工程に組み込むかを決める価値があります。

続けて読む: