Expo Go の Android で DevTools の

Expo の Issue 一覧を読んでいて、「これは胃が痛くなる症状だな」と手が止まった報告がありました。Android の Expo Go で j キーを押して React Native DevTools を開くと、Console に式を打っても何も返ってこず、Sources タブも空のまま、というものです。

エラーは出ません。画面も落ちません。ただデバッガが黙っているだけです。こういう症状は、自分のコードを疑って一時間を溶かしやすいのです。

先に結論をお伝えします。この症状は、Expo Go の Android 側の問題として報告されています。まず実行環境を切り分け、コードを読むのはその後にします。 以下、2026年10月29日時点で私が読めた範囲の情報です。私の手元で再現したものではなく、Issue の報告を元に整理しております。

症状の見分け方

報告されている症状は、次のとおりです。

Console タブで 1 + 2 のような式を打っても結果が返ってきません
Sources タブにファイルが一つも並びません
報告によっては Components と Profiler のタブも動かないという声もあります

expo/expo#46333 では、SDK 56 の新規プロジェクト（create-expo-app の既定テンプレート）で再現するとされています。コメントには SDK 57 でも同じだという報告があり、2026年10月28日の時点で Issue は open のままでした。

大事なのは、「あなたのアプリが書いたコード」に関係なく起きるとされている点です。新規作成直後の空のプロジェクトで出る症状なら、自分の useEffect を読み返しても答えは出ません。

自分のコードを疑う前に、5分で分ける3つの確認

順番に試してみてください。上から順に、安くて判断が速いものです。

確認	やること	読み方
1. 同じ手順を iOS で	iPhone かシミュレータで同じ Expo Go を開き、`j` で DevTools を開いて Console に式を打つ	iOS で動けば、Android 側の環境が疑わしい
2. 新規プロジェクトで	`npx create-expo-app@latest` で空のアプリを作り、Android の Expo Go で同じ操作をする	空のアプリでも黙るなら、自分のコードは無関係
3. ターミナルのログ	`console.log` の出力が Metro のターミナルに届くかを見る	ログが届くなら、アプリ自体は動いていてデバッガの経路だけが死んでいる

3つ目は、結果を断定せずにお読みください。報告されているのは Console の評価と Sources の不具合で、ログの転送が止まるとは書かれていません。届くかどうかはご自身の環境で確かめるのが確実です。

原因として報告されていること

報告には、もう一段深い確認が付いていました。Metro の /json/list が返す WebSocket の URL に、Chrome DevTools Protocol のメッセージを直接送ると、Runtime.evaluate が -32601（Method not found）で返るというものです。

つまり、Console が黙っているのは画面の描画の問題ではなく、デバッガと JS ランタイムをつなぐ経路で、式の評価というメソッドが受け付けられていない、という見立てです。

ここから先は未確定です。Issue のラベルは Android、sdk-56、sdk-57 で、Expo 側のトリアージは「Expo Go の Android で JS デバッグが壊れる」という要約までしか出ていません。根本の原因と修正の時期は、2026年10月29日の時点で分かっておりません。

分からないことを分からないまま持ち帰るのも、トラブル対応の大事な作業です。原因が未確定のあいだは、直そうとせず、避けて通ります。 私はこの線引きで動いています。

避ける方法：開発ビルドに切り替える

同じ Issue のコメントに、実際に効いたという回避策が書かれていました。Expo Go ではなく、開発ビルド（development build）で動かすと、デバッガが普通に使えるというものです。この報告者は、影響を受けるのは Expo Go の Android だけだと書いています。

手元に Android Studio と実機かエミュレータがあるなら、次の2行で足ります。

# 開発クライアントを依存に足す
npx expo install expo-dev-client
 
# ネイティブのプロジェクトを生成して、Android の実機/エミュレータにインストールする
npx expo run:android

ビルドが終わったら、これまでと同じように Metro を起動し、ターミナルで j を押します。ここで Console が式を返せば、症状が Expo Go に由来していたと確かめられます。

Android Studio を入れていない場合は、EAS Build でクラウドに作らせる方法もあります。eas.json に開発用のプロファイルを足します。

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "android": {
        "buildType": "apk"
      }
    }
  }
}

eas build --profile development --platform android

buildType を apk にしているのは、実機に直接入れられる形式にするためです。ビルドが終わったら、表示される QR かリンクから端末にインストールしてください。

開発ビルドで増える手間

回避策には対価があります。Expo Go なら QR を読むだけで済んでいたものが、開発ビルドでは初回のビルドを待つ必要があります。ネイティブの依存を足したり変えたりするたびに、作り直しも発生します。

個人開発の感覚で言えば、毎日何十回も画面を確かめる段階では、この待ち時間が効いてきます。一方で、デバッガが使えないまま推測で直す手間のほうが、長い目ではずっと高くつくと感じています。

切り替えたくないとき

開発ビルドに移す余裕がない日もあります。そのときは、症状を受け入れたまま、使える手段で進めます。

ログを出します。 console.log を要所に置き、Metro のターミナルで読みます。デバッガほど快適ではありませんが、状態の変化は追えます。
iOS 側で確かめます。 報告は Android の Expo Go に限られています。ロジックの確認なら iOS で済ませ、Android 固有の部分だけ実機で見ます。
Issue を追います。 修正が入れば Issue が動きます。購読しておけば、直った時点で気づけます。

まとめ代わりに、次の一歩

デバッガが黙ったときに最初にすることは、コードを開くことではありません。同じ操作を、iOS と空のプロジェクトで一度ずつ試します。 それだけで、疑うべき場所が自分の側か実行環境の側かが分かれます。

まずは新規プロジェクトを一つ作って、Android の Expo Go で j を押してみていただければ幸いです。結果がどちらでも、次に何をすればよいかが決まります。

DevTools が使える環境では、ダークモードの確認をエミュレーションに寄せる使い方もあります。そちらは別の記事に書き残しました。デバッガが戻ってきたあとの楽しみとして、気が向いたときに読んでいただければと思います。

Expo Go の Android で DevTools の Console が何も返さないとき、疑うのは自分のコードより先に実行環境です