expo-dev-client

expo-dev-client スキルの概要

expo-dev-client ができること

expo-dev-client スキルは、そもそも Expo development client が本当に必要かを先に見極め、そのうえで EAS Build を使った development client の設定とビルドを、ローカル環境でも TestFlight 向けでも進められるよう案内します。単に「ビルドを作る」ためのものではなく、「Expo のドキュメントを手探りで追わずに、カスタム native 機能を含むテスト用アプリを実機へ確実に載せる」ための実務向けガイドです。

このスキルが向いている人

このスキルが特に役立つのは、次のようなケースです。

• native module を追加する Expo チーム
• ローカルの Expo module やカスタム native code を検証したい開発者
• widget、app clips、extensions など Apple 固有の target を使うアプリ
• TestFlight を使った iOS の社内テスト手順を再現可能な形で整えたいチーム

アプリが Expo Go で完全に動くなら、このスキルはたいてい不要です。

導入時のいちばん重要な判断

導入で最初に考えるべきことはシンプルで、「そもそも development client が必要か」です。expo-dev-client スキルの価値は、この判断を早い段階でできる点にあります。まず npx expo start で Expo Go を試すよう明確に促すため、不要なビルド時間や EAS の複雑さを抱え込まずに済みます。

一般的な Expo 用プロンプトと expo-dev-client の違い

一般的なプロンプトなら「Expo dev client をセットアップして」と指示できますが、このスキルはもっと判断志向です。特に重視しているのは次の点です。

• dev client が必要になる境界条件
• 必要な eas.json の形
• ローカルビルドと cloud / TestFlight ビルドの違い
• 実機向けの配布テストを進めるための実用的なコマンドの流れ

そのため、広く浅い Expo アシスタント用プロンプトよりも、セットアップやリリース周辺の実務フローに向いています。

expo-dev-client スキルの使い方

expo-dev-client スキルをインストールする

skills 対応環境では、次のコマンドでインストールできます。

npx skills add https://github.com/expo/skills --skill expo-dev-client

このスキルはコンパクトで、内容の中心が SKILL.md にまとまっています。インストールの主目的は、Expo の native テスト作業で再利用できるようにしておくことです。

コマンドから入るのではなく、達成したい仕事を先に定義する

expo-dev-client スキルを呼び出す前に、まず実際の目的をはっきりさせましょう。

• 「native SDK を追加したので iPhone で検証したい」
• 「QA 向けにブランチ専用の dev client が必要」
• 「アプリに widget を入れたので、もう Expo Go では足りない」
• 「TestFlight 経由で配布する iOS development build が欲しい」

この整理が重要なのは、カスタム native code が必要な理由が明確なほど、このスキルの強みが活きるからです。

まず Expo Go で足りるか確認する

よくある失敗は、expo-dev-client を早い段階で使い始めてしまうことです。最初に試すべきなのは次です。

npx expo start

アプリが Expo Go で動くなら、そこで止めて構いません。development client を使うと、ビルド時間、署名設定、配布の手間が増えます。native 機能の都合で本当に必要な場合にだけ、このスキルを使うのが適切です。

expo-dev-client がはまる典型パターンを把握する

expo-dev-client を使うべきなのは、プロジェクトに次の要素がある場合です。

• ローカルの Expo modules
• custom native code
• Expo Go では使えないサードパーティ native module
• widget、app clips、extensions などの Apple target

こうしたケースでは、dev client は「あると便利」ではなく「必須」に変わります。

エージェントに最低限渡すべき情報を準備する

エージェントに expo-dev-client スキルをうまく使ってもらうには、少なくとも次の情報を渡してください。

• 対象プラットフォーム: ios、android、または両方
• 想定している配布方法: ローカルインストール、社内テスト、または TestFlight
• すでに EAS の設定が済んでいるか
• 現在の eas.json
• Expo Go で未対応の native module を使っているか
• バージョン管理や署名に関する制約

この前提がないと、エージェントはコマンド提案自体はできますが、適切な build profile を外したり、不要な設定まで勧めたりしがちです。

「set up expo-dev-client」より具体的なプロンプトを使う

弱いプロンプト:

Set up expo-dev-client.

強いプロンプト:

Use the expo-dev-client skill to determine whether this Expo app needs a dev client. We added a third-party native iOS SDK and need a TestFlight-distributed development build for internal QA. Review this eas.json, identify missing settings, and give the exact commands for building and submitting.

このほうがうまくいく理由:

• まず適合性の判断を求めている
• native 側のトリガーを明示している
• 目標のワークフローを特定している
• 修正対象の設定を具体的に渡している

eas.json を正しく構成する

このスキルで特に重要になる設定は、developmentClient: true を持つ development build profile です。通常は version 自動管理も併せて使います。

{
  "cli": {
    "version": ">= 16.0.1",
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true
    },
    "development": {
      "autoIncrement": true,
      "developmentClient": true
    }
  },
  "submit": {
    "production": {},
    "development": {}
  }
}

特に重要なのは次の項目です。

• developmentClient: true: EAS に development client を含めたビルドであることを伝える
• autoIncrement: true: build number 周りの面倒を減らす
• appVersionSource: "remote": EAS を通じて version 管理を一貫させる

実機でのリモート検証が必要なら TestFlight 向けにビルドする

iOS チームにとって、価値の高い expo-dev-client usage の代表例は TestFlight です。

eas build -p ios --profile development --submit

これは、テスターに配るための dev 対応アプリが必要なときの、実務的な「expo-dev-client for Deployment」フローです。ローカル成果物を作るだけでなく、cloud build と submit をまとめて進められるため、別々の手順をつなぎ合わせるより速いことが多いです。

速度や秘匿性を重視するならローカルビルドを使う

TestFlight が不要なら、ローカルビルドのほうが合う場合もあります。

• 環境によっては反復が速い
• ローカルのツールチェーンをより細かく制御できる
• 社内展開前に自分の実機で native 連携を確認するのに便利

セットアップのデバッグや、自分の端末での native integration 検証にはローカルを選びましょう。QA や非技術系テスターと連携するなら TestFlight が向いています。

まず読むべき repository ファイル

このスキルはシンプルなので、最初に見るべきは SKILL.md です。このスキルのパスには resources/、rules/、helper script のような補助ディレクトリがなく、使えるガイダンスの大半はそこにまとまっています。

同時にこれは、深い自動化ロジックを期待しすぎないほうがよい、という意味でもあります。基本的には、実務向けの判断とワークフロー案内に特化したスキルです。

実案件での推奨ワークフロー

信頼しやすい expo-dev-client guide の流れは次のとおりです。

1. Expo Go が native 由来の理由で使えないことを確認する。
2. eas.json を確認する、または新規作成する。
3. developmentClient: true を含む development profile を追加する。
4. ローカルビルドにするか TestFlight 配布にするか決める。
5. 対象プラットフォーム向けの正確な EAS build コマンドを実行する。
6. 実機でテストする。
7. version 管理や submit の挙動に問題があれば profile 設定を見直す。

この順番にすると、無駄なビルド回数を減らしつつ、「そもそも dev client は不要だった」というケースを早めに見つけられます。

expo-dev-client スキル FAQ

expo-dev-client は高度な Expo アプリ専用ですか？

おおむねそうです。初心者でも使えますが、本領を発揮するのは、native 要件のためにアプリが Expo Go の範囲を超えた段階です。まだ純粋な managed workflow の範囲にいるなら、現時点では価値を感じにくいかもしれません。

expo-dev-client は、プロジェクトに expo-dev-client を入れることと同じですか？

いいえ。expo-dev-client スキルは、development-client build をどう進めるかという周辺ワークフローのためのガイダンスです。いつ使うべきか、EAS をどう設定するか、どの build path を選ぶかを整理してくれます。単なる package インストールの注意喚起ではありません。

expo-dev-client スキルを使わないほうがよいのはいつですか？

次のような場合は使わないでください。

• アプリがすでに Expo Go で動いている
• JavaScript レベルの反復だけが必要
• development client のセットアップではなく、本番 release build 全体のガイドが欲しい
• 問題の本質が native 機能や build 配布に関係していない

通常の Expo トラブルシューティング用プロンプトと何が違いますか？

通常のプロンプトだと、汎用的な build アドバイスに寄りがちです。expo-dev-client skill は範囲が狭いぶん、導入判断の案内に強く、特に「dev client が必要かどうか」というチェックポイントと、導入で詰まりやすい EAS profile の具体設定に焦点を当てています。

expo-dev-client は Android にも役立ちますか？

はい。明示的な説明は iOS と TestFlight 周りが中心ですが、基本ロジック自体は Android の development build にもそのまま当てはまります。Expo Go では足りず、custom native code のために dev client が必要なら有効です。

deployment ワークフローにも向いていますか？

はい。ただし範囲には限界があります。expo-dev-client for Deployment は、本番リリース全体の代替というより、development build の社内配布、特に QA やブランチ検証向けの TestFlight 配布として捉えるのが正確です。

expo-dev-client スキルを改善する方法

現在のプロジェクト状態を最初に共有する

expo-dev-client スキルからより良い結果を得るには、最初に次を渡してください。

• eas.json
• 対象デバイスとプラットフォーム
• ローカル限定か TestFlight か
• 何の native module または target がきっかけで必要になったか
• すでに Expo Go を試したかどうか

これがあると、エージェントは一般論ではなく、具体的な修正内容と正確なコマンドに踏み込めます。

手順を聞く前に、まず判断を求める

質の高いプロンプトは、まず次の一文から始まります。

First determine whether this app truly needs expo-dev-client.

この一文だけでも出力品質はかなり上がります。このスキルの最大の価値は、不要な dev-client セットアップを避けることにあるからです。

レビュー用に設定断片を含める

既存の eas.json を貼れば、エージェントは次のことができます。

• developmentClient: true の不足を検出する
• version 管理の修正を提案する
• submit と build profile の整合を取る
• 不要な設定をでっち上げずに済む

ゼロから相談するより、こちらのほうがはるかに実用的です。

配布の意図を明確に伝える

適切なコマンドは、次のどれを求めているかで変わります。

• ローカルの development build
• 実機インストール用の cloud build
• TestFlight に submit する iOS build

ここを明示しないと、最初の回答は技術的には正しくても、チームの運用には合わないものになりがちです。

主な失敗パターンを意識する

もっとも多い失敗は、Expo Go のままで十分なアプリに expo-dev-client を使ってしまうことです。次に多いのが、EAS 設定の情報をほとんど渡さず、出力が曖昧だとスキル側のせいにしてしまうことです。どちらも、native 要件と現在の設定を最初に提示すれば防げます。

最初の回答のあとに掘り下げる

最初の返答のあとには、次のような追加質問をすると効果的です。

• “Validate this eas.json against a dev-client TestFlight workflow.”
• “Rewrite the build commands for Android only.”
• “Assume our app uses a widget extension; what changes the decision?”
• “Minimize the setup to the smallest working development profile.”

こうした聞き方をすると、expo-dev-client skill は一般的な説明から、実プロジェクト向けの実行支援へと進みやすくなります。

チーム利用なら標準プロンプトを用意する

複数の開発者がこのスキルを使うなら、次のような再利用可能な社内プロンプトテンプレートを作っておくと便利です。

Use expo-dev-client to assess whether this Expo app requires a development client. Here is our eas.json, target platform, distribution goal, and native dependency list. Return: 1) decision, 2) config changes, 3) exact commands, 4) likely blockers.

こうしておくと、出力のばらつきが減り、オンボーディング時の負担も軽くなります。

単なる手順集ではなく、判断ゲートとして使う

expo-dev-client usage を改善する最善の方法は、ビルド前の判断ゲートとして扱うことです。チームが dev client を使う前提をすでに固めたあとでしかこのスキルを使わないなら、いちばん大きな利点である「不要な native-build ワークフローのオーバーヘッドを防ぐこと」が失われます。