要点（短く）
AIでモバイルアプリを作るには、3つのツールが必要です。
- Skills：AIコーディングエージェントがタスクが必要なときだけ読む指示ファイル（単一の
SKILL.md）。コンテキストコストがほとんどかかりません。
- MCPサーバー：ビルドダッシュボードやシミュレータの操作のように、エージェントを外部サービスにつなげる（ただしツール定義は事前に全てロードされるためコストがかかります）。
- AIワークフロー：会話自体の管理方法。各スレッドをコンテキストウィンドウの約50%未満に保ち、タスクごとにスレッドを分岐させます。
まずはスキルを追加し、1つのMCPを接続し、その後コンテキストを監視してください。以下ではハビットトラッカー（習慣トラッカー）を例に、具体的な手順を示します。
プロジェクトの足場（例）
まず create-expo-app でプロジェクトをスキャフォールドします。bunx でも npx でも構いませんし、別のスターターテンプレートを使っても良いです。
bunx create-expo-app@latest habit-tracker
cd habit-tracker
bun install
bun start
これでデフォルトのタブがある実行中のアプリができます。ただし見た目は古いスタイルです。下部タブにネイティブのリキッドガラス風エフェクトを入れたいので、ここで最初のツールが登場します。
ビデオで同内容を解説しています（興味があれば視聴を推奨）。
Skills：AIへの指示マニュアル
スキル（skill）は、タスクが呼ばれたときにAIコーディングエージェントが読む指示のフォルダです。必要なのは単一の SKILL.md ファイルだけです。参照ドキュメントやスクリプトを追加することもできますが、Markdownファイルだけで十分です。
スキルは Claude Code、Cursor、Codex などスキル対応のエージェント間で動作します。ExpoチームはReact Nativeアプリの構築と出荷向けのスキル群を維持しており、コミュニティのスキルも多数あります。一覧は expo.dev/skills を参照、または expo/skills リポジトリからまとめて取得できます。
インストールはスキルページのコマンドをコピーしてターミナルで実行します。スキルをどれにするか聞かれたら個別に選ぶか、ワイルドカードで全て追加できます：
npx skills add -s "*"
次にどのコーディングエージェントで使うかを聞かれます。ほとんどのエージェントは agents/ ディレクトリを読みますが、Claude Code は独自の慣習があるので明示的に追加してください。スコープ（プロジェクト内のみかグローバルか）についても聞かれます。モバイルアプリを毎日作るのでなければプロジェクトスコープにしておくのが無難です（毎日作るならリスペクトしてシンボリックリンクをどうぞ）。
インストール後は agents/ と .claude/ が新しいスキルで埋まっているはずです。
良いスキルのポイントを理解したければ、Anthropic のスキル作成ガイドを参照してください。今覚えておくべきアイデアは「段階的開示（progressive disclosure）」です：理由がない限り情報をロードしない。スキルは短い説明を前面に出し、タスクが要求されたときに完全な指示を取りに行きます。この原理がスキルをコンテキスト面で安価に保つ理由です。
スキルを呼び出す2つの方法
-
明示的呼び出し：スラッシュコマンドで名前を指定します。
/expo-ui
これによりAIはそのスキル内の SKILL.md をタスクの前に読みます（Codex ではプレフィックスが $ です）。例：
/expo-ui
Please implement the liquid glass effect inside the bottom tabs.
2. 自律的呼び出し：各スキルは説明を持っており、AIはそれを見て自動的に関連性を判断します。つまり各説明はすべての会話にロードされます。ここが重要で、スキルを溜め込みすぎると説明テキストでコンテキストを圧迫します（後述）。
例：タブの変更
スキル1つで一発で完了するクリーンなワンショットの例を見ました。
AIに最適なスキルを見つけさせる
パフォーマンスやベストプラクティスをカバーしたスキルを書くこともできますが、既に誰かが作っている可能性が高いです。なのでこう聞いてみてください：
「アプリのパフォーマンスを常に最高に保ち、何も遅くしないようにするスキルを見つけるのを手伝ってくれますか？」
AIはグローバル設定にある find-skills スキルを自律的に呼び出し、skills.sh（約90万件のコミュニティスキルを横断検索するディレクトリ）で探します。find-skills 自体は非常に単純な1ファイルですが強力です。推奨されたらローカルにインストールするよう指示すれば、残りを処理してくれます。
MCPサーバー：エディタ外でAIに「手」を持たせる
スキルだけでは、コードベースから見えない情報が必要になった瞬間に限界に達します。私の例では変更をプッシュしてビルドが失敗しましたが、ログはローカルに無くExpoダッシュボードにありました。そこへ行って読むのは面倒です。AIがダッシュボードのログを読み、自律的に修正を実装できたらどうでしょう？それがMCPです。
MCP（Model Context Protocol）はAIエージェントをNotion、Supabase、GitHub、ビルドダッシュボードなどの外部サービスに接続し、データの読み取りと操作を可能にするオープン標準です。ExpoのMCPサーバーはEASビルド、ワークフロー、ログ、クラッシュレポートを公開します。最近の変更で、かつては有料プランでの機能だったものが誰でも無料で使えるようになりました。
入手とインストール手順、詳細なウォークスルーは expo.dev/ai を参照してください。Expo MCP の解説動画もあります（昔の有料プラン時代の内容なので留意してください）。Claude Code を使っている場合は、対応スクリプトをコピーして使ってください。
ExpoプラグインをインストールするとスキルとMCPサーバーがバンドルされます。Claude の settings.json に以下が見えれば追加されています：
{
"enabledPlugins": {
"expo@claude-plugins-official": true
}
}
認証は /mcp を実行して行います。実際に使う例：
My Expo iOS build is failing. Investigate the cause, figure out a solution, and make sure the solution actually works before coming back to me.
有用なメンタルモデル：Expoダッシュボードでできることは、MCPを通してできる可能性が高いです。ビルドとワークフロー関係のツールが大半をカバーします。
サーバーツールとローカルツールの違い
Expo MCP は2種類のツールに分かれます。サーバー機能（大半）はデフォルトでインストールされ、ダッシュボードに対して動作します。ローカル機能はより限定的で、別途オプトインのインストールが必要です：
npx expo install expo-mcp
これはdev dependenciesに入ります。ローカルツールはAIにシミュレータを操作させることができます：スクリーンショットの取得、ボタンのタップ、ネイティブとJSのログ読み取り、DevToolsの起動、Expo Routerのサイトマップ検査など。これにより単にコンパイルが通るだけでなく、修正が実際に動作するかを検証できます。
ローカルサーバーを有効化するには、インストーラが示すコマンドで package.json の start スクリプトを更新し、再度 bun start を実行します。
私の場合、ビルドは緑に戻りました。原因は React Native Reanimated のバージョン不一致で、expo doctor が既に警告していました（期待バージョンと検出バージョンが出力に表示されます）。
Expo Doctor
なので、多くのトークンを無駄にする前に expo doctor を実行するのを忘れないでください。これらの問題は数秒で検出できます。
MCPはトークンを多く消費するので選択的に使う
MCPサーバーはスキルに比べて相対的にトークン消費が多い点に注意してください。インストールするとそのMCPの全ツール定義が事前にコンテキストにロードされます（たとえ使わなくても）。したがって、プロジェクトが実際にそのサービスを使う場合にのみMCPを追加してください。例えば、プロジェクトがSupabaseをバックエンドに使っているときだけSupabase MCPを追加し、グローバルにインストールしないようにします。
デバッグ向けでWebアクセス、Androidエミュレータ、iOSシミュレータを同時に扱いたいなら、Software Mansion の Argent を検討してください。3ターゲットで自律的にテストでき、オープンソースです。
SkillsとMCPの使い分け
両者は異なる問題を解決します。違いはコンテキストコストと到達範囲にあります。
- 知識が指示ファイル内にあるならスキルを使う。
- 答えがリポジトリから見えないシステムにあるならMCPを使う。
AI開発の理想的ワークフロー
正しいスキルをインストールし、正しいMCPを接続しても、AIが期待通りの結果を出さないことがあります。主な原因は3つです。
1) 十分なコンテキストを与えていない
AIをジュニア開発者に例えると、何をやって欲しいか詳しく伝えないと、彼らは多くの仮定をしてしまい、それはたいてい一般的すぎます。スキルは助けになりますが、具体的な機能やデザインについてはあなたがしっかり伝えないといけません。
2) 自分でも何を作りたいか分かっていない
多くの人がこれで躓き、何も作らなくなります。しかし忘れてはいけないのは、AIはあらゆる役割を引き受けられるということです。アイデア出しの賢い相棒として振る舞わせることができます。
ハビットトラッカーの例では、機能を列挙する代わりに自分の状況をこう説明しました：
「ハビットトラッカーを作りたいが、どんな見た目・動作にすれば続かなかった過去の問題を解決できるか分からない。動機維持や毎日の記録を忘れないようにしたい。ウィジェットで自動的に表示・更新できれば助かるかもしれないが確信はない。どう思う？」
このプロンプトは私が自作した /co-ceo スキル（Garry Tan の類似スキルに触発されたもの）に投げました。疑問点を引き出すスキルとしては Matt Pocock の grill-me も価値があります。スキルは単にコードを書かせるためだけでなく、より良いプロダクトを作るための助けにもなります。
ここで意図的に省いたものに注意してください。技術スタックや実装の詳細は書いていません。会話を過剰に複雑にしたくなかったからです。まずコアアイデアを固める。スタックは別スレッドの会話です。
3) コンテキストの膨張（Context bloat）
AIのメモリを脳に例えてください。大量の情報を渡して鋭い質問をすると、曇った答えが返ってきます。モデルも同じで、あるレベルを超えると応答が悪化し、コストも上がります。
ccstatusline のようなツールでターミナル内のコンテキストウィンドウ使用率を確認できます。新しいセッションはシステムプロンプト、設定ファイル、スキル説明などで約5%あたりに収まり、アイデア出しのセッションで30%まで行くことがあります。私の経験則は「50%を超えないこと」。それを超えるとモデルが幻覚を始め、性能が落ちます。
コンテキストを制御するための習慣は2つあります。
- 1会話1アウトカム：アイデア出しのスレッドはアイデア出しに専念させ、名前を "initial planning" のように変更して後で見つけやすくする。
- 継続し続けるのではなく分岐する：技術スタックを決める段階になったら、同じスレッドに積み上げ続けずに会話を分岐させる。
以上が、AIを使ってモバイルアプリを作る際に本当に重要な3つのツールと、それらを効果的に運用するための実践的なアドバイスです。