AIでモバイルアプリを構築する方法:本当に重要な3つのツール
AI で作る Expo アプリにはツールが 3 つ要る。Skills(SKILL.md)、Expo MCP サーバー、そしてコンテキストを制御可能な状態に保つワークフローだ。Cursor、Claude Code、Codex。
日本語
コピー

簡易版
AI でモバイルアプリを作るには、3 つ揃える必要がある。Skills は指示ファイル(タスクが必要としたときに agent が読む SKILL.md)なので、コンテキストの消費が小さい。MCP server は agent を外部サービス(ビルドログ、dashboard、ローカルシミュレータの操作)につなぐが、その代わりツール定義を事前に読み込むことになる。AI ワークフローが扱うのは会話そのものだ。スレッドごとにコンテキストウィンドウの半分以内に収め、タスク単位で分岐させる。まず skills を追加し、次に MCP を 1 つつなぎ、それからコンテキストを監視する。
ダブルネイティブでも Expo でも、agent はタイピングの手間を大きく減らしてくれる。ただし iOS と Android を単一のネイティブリリースパスで出したい、Skills と MCP 経由で最新の Expo API を引きたい、ビルド・更新・提出を EAS に任せたいなら、Expo のほうが割がいい。このパスがなぜ成り立つのか(そしてどういうときにダブルネイティブのほうが優るのか)は Why Expo is a great fit for new and existing apps を参照。web の React から来た人は From web to native with React と合わせて読むといい。
本記事は特定の harness に縛られない。Cursor、Claude Code、Codex、その他 skills と MCP に対応する agent ならどれでも当てはまる。Expo MCP Server と Expo Skills は agent 向けのドキュメントとツールであって、別立ての「Expo Agent」という製品ではない。
サンプルプロジェクトを用意する
create-expo-app から始める(習慣トラッカーアプリを記事全体の例に使う):
npx create-expo-app@latest habit-tracker
cd habit-tracker
npm install
npx expo start
bunx / bun に慣れているならそれでいい。起動すると tabs 付きのアプリが手に入る。ここから skills、MCP、ワークフローでどうやって AI 支援のネイティブリリース閉回路にするかを説明する。
Skills:AI への説明書
skill とは指示を入れたフォルダで、AI コーディング agent がタスクに必要になったときに読む。最小構成は SKILL.md 1 つ。参考資料やスクリプトを足してもいいが、markdown だけでも十分だ。Skills は対応する agent 間で共通に使える。Claude Code、Cursor、Codex を含む。
Expo チームは Expo アプリのビルドとリリース用の skills をメンテナンスしている。expo.dev/skills か expo/skills リポジトリを見てほしい。skills CLI でインストールする(例):
bunx skills add expo/skills
# or: npx skills add expo/skills
いくつかだけ選んでもいいし、まとめて入れてもいい。毎日モバイルのリポジトリに浸かっているのでなければ、プロジェクトスコープに限定しておく。鍵になるのは段階的開示だ。skill は最初に短い説明だけを出し、完全な指示はタスクが本当に必要としたときに読み込まれる。だから skills は MCP よりコンテキストの消費が小さい。
skill を呼び出す 2 つの方法
明示的に呼ぶ:名前をそのまま指定する(Claude Code / Cursor の慣例ではスラッシュコマンド、Codex では $ がよく使われる)。
自律的に呼ばせる:agent が skill の説明とあなたの要求を突き合わせる。説明は毎ターン読み込まれるので、使わない skill を溜め込まないこと。
意図の例(UI skills を入れた状態):関連する Expo UI skill を使ってネイティブ tab のスタイルを実装するよう agent に指示する。リリース時は古い一度きりの例ではなく、expo.dev/skills にある現在の @expo/ui / skill 名を優先する。
agent に skill を探させる
パフォーマンスかベストプラクティスに関する skill を探させ、よさそうならローカルに入れる。コミュニティのディレクトリもあるが、あくまで任意として扱う。Expo のこの流れはそれらに依存しない。
MCP server:AI にエディタの外へ手を伸ばさせる
答えが repo の中にないとき(EAS のビルドログ、dashboard の状態、動いているシミュレータ)は、skill では手が出せない。MCP(Model Context Protocol) は agent をそうしたサービスにつなぎ、読ませ、操作させる。
Expo MCP server は Expo アカウントを持つ agent に EAS のビルド、workflow、ログ、および関連するプロジェクト操作を開放する。expo.dev/ai でインストールして認証する(現在のドキュメントもそこからリンクされている)。Claude Code のユーザーは skills と MCP を同梱した Expo プラグインを有効にできる。他の harness はそれぞれの MCP 設定方法に従う。入れたあとはその harness の /mcp(または同等の手順)で認証する。
Server ツール vs ローカルツール
-
Server 側の機能(デフォルト):あなたの Expo/EAS プロジェクトに対する操作(ビルド、workflow、ログ)。
-
ローカル側の機能(手動で有効化):プロジェクトに
expo-mcpをインストールすると、agent がローカルシミュレータを動かせるようになる(スクリーンショット、タップ、ログ、Router sitemap)。startスクリプトはインストール手順に従って処理する。
失敗した iOS ビルドを agent に調査させ、修正案を出させ、戻る前に検証させる。まず npx expo-doctor(または npx expo doctor)を実行する。依存バージョンの不一致は、token を無駄に消費する前に見つかることが多い。
MCP は token をよく食う
MCP はツール定義をあらかじめ読み込む。プロジェクトが実際に使うサービスに限って MCP を追加すること。「X の組み方は?」と聞きたいなら Skills を優先し、「リポジトリからは見えないシステムを読み書きしたい」なら MCP を優先する。
エコシステムには、より広いマルチターゲット自動化が必要なときに Expo MCP と併用できる、ローカル専用のデバッグツール(Software Mansion Argent など)もある。三ツールの幹にこれらは要らない。
Skills と MCP(早見表)
| Skills | MCP server | |
|---|---|---|
| 何か | 必要時に読む指示ファイル(SKILL.md) | 外部サービスへの接続。agent が読み取り、操作を実行できる |
| コンテキスト消費 | 少ない(使わないときは短い説明だけ) | 多め(ツール定義が最初から読み込まれる) |
| 向いている用途 | リポジトリ内でのビルド、アップグレード、デバッグの方法 | ビルドログ、ダッシュボード、シミュレータ操作 |
| 導入範囲 | いくつ入れてもよい。説明は正直に | 少なめに。このプロジェクトが使うサービスだけ |
AI ワークフロー(コンテキストの規律)
会話そのものが散らかっていては、skills と MCP だけでは足りない。失敗パターンは三つ。
プロダクトのコンテキストが足りない。 agent を勘のいいジュニアエンジニアだと思って接する。成果物、制約、設計意図をはっきり伝える。Skills が担うのはプラットフォーム側の操作知識で、プロダクト要件は依然としてあなたの担当だ。
自分でも何が欲しいか固まっていない。 技術スタックや実装の話をする前に、計画用の skill を使うか、構想専用のスレッドを立てる。最初のラウンドで技術スタックに触れないこと。
コンテキストの膨張。 コンテキストウィンドウの半分を少し超えたあたりから品質が落ち、コストが上がる。一つの会話、一つの目的。タスクが変わったらブランチ(または fork)を切る。まず計画、次に技術スタック、そしてビルド、最後にバグ用のブランチ。
実用的なルール:コンテキストは 50% 前後以内に抑える。harness が対応していればステータス行で監視する。ずっと話し続けるのではなく、きれいなスレッドに戻ること。
どこから始めるか
expo.dev/skills から Expo skills を追加する。
MCP を一つつなぐ:expo.dev/ai の Expo MCP。
コンテキストを見張る:タスクごとにブランチを切り、スレッドごとに焦点を保つ。
これが、AI で Expo アプリを構築し、同じネイティブリリース経路をたどる三ツールの幹だ。なぜ Expo を選ぶのか、なぜ二つのネイティブ + AI ではないのかを深掘りした記事は Why Expo is a great fit for new and existing apps。Web からストアへの引き継ぎは From web to native with React。
よくある質問
AI でモバイルアプリを構築するには何が必要か?
スキル(SKILL.md の指示ファイル)、リポジトリ外のサービス向けの MCP 接続(EAS/ログ/シミュレータ用の Expo MCP)、そしてコンテキスト管理(焦点を絞った会話スレッドで、ウィンドウの半分程度以内に収める)。create-expo-app で足場を組み、スキルを追加し、MCP を一つつなぎ、会話を管理する。
Expo スキルとは?
SKILL.md を含むフォルダで、Expo アプリの構築、アップグレード、デバッグの方法を agent に教える。公式スキル集は expo.dev/skills。Claude Code、Cursor、Codex、その他スキルに対応した agent で使える。
Expo MCP サーバーとは?
agent が Expo/EAS プロジェクト(ビルド、ワークフロー、ログ)を操作できるようにする Model Context Protocol サーバー。ローカルツールと組み合わせればシミュレータも動かせる。インストール方法とアカウント要件は expo.dev/ai と関連ドキュメントを参照。
MCP サーバーはコンテキストをかなり食うか?
スキルと比べれば食う。ツール定義が起動時にすべて読み込まれる。プロジェクトが実際に使うサービスにだけ入れること。
Agent はネイティブ開発と Expo の両方を同じくらい快適にできるか?
agent はどちらの道でもコードを書くコストを下げる。Expo は依然として、単一の TypeScript アプリ、現在の Expo API に合わせた Skills/MCP、EAS Build/Update/Submit を同じリリース経路にまとめている。共有 UI が薄い場合や、組織が技術スタックの分離を求める場合には、二つのネイティブという選択肢のほうが今も適している。詳しい回答は Why Expo のよくある質問に。
Expo Agent という製品はあるか?
ない。Expo が提供するのは Skills、MCP、ドキュメント(llms.txt)で、あなたが今使っているコーディング agent に Expo をうまく扱わせるためのものだ。使い慣れた agent をそのまま使えばよい。
次に読むもの
-
スキル:expo.dev/skills
-
AI/MCP の入り口:expo.dev/ai
-
Expo を選ぶ理由:Why Expo is a great fit for new and existing apps
-
Web からネイティブへ:From web to native with React
-
エージェント向けドキュメント:docs.expo.dev/llms.txt