SDK を一つ上げて、ついでに依存も整えて、EAS に Android のビルドを投げます。ログの末尾が赤くなって、こう止まっていたとします。
FAILURE: Build failed with an exception.
* Where:
Script '/home/expo/workingdir/build/node_modules/@sentry/react-native/sentry.gradle' line: 127
> Could not find method exec() for arguments [...] on task ':app:createBundleReleaseJsAndAssets_SentryUpload_...' of type org.gradle.api.DefaultTask.自分の build.gradle は一行も触っていません。それなのに「method が見つからない」と言われると、手が止まります。
最初にお伝えしたいのは、このログで読むべきなのは最後のエラー文ではなく、その二行上の Script '…' line: N だということです。ここには、落ちた場所のパッケージ名と行番号がそのまま書いてあります。
この文言は、expo/expo の Issue #42494（SDK 55 の preview 期、2026 年 1 月に報告されて現在は closed）で報告されているものと同じ形です。Issue のページを読む限り、@sentry/react-native の 7.2.0 で起き、Sentry 側は 7.3.0 で直したと書かれています。ページには原因の仕組みまでは書かれておらず、題名にある「Gradle 9 との非互換」という見立てが示されているだけです。私が手元で確かめたのは、後半のログ解析の部分で、EAS 上でのビルドそのものを再現したわけではありません。その点はご承知おきください。
なぜ「アプリのコード」ではなく Script 行を見るのか
Gradle のエラーは、落ちたタスクの名前が長く、末尾の文言も抽象的です。一方で Script '…' line: の一行は、「どのファイルの何行目を実行中に落ちたか」を教えてくれます。パスが node_modules/ の中を指していれば、原因は自分のアプリのコードではなく、入れているパッケージ（とその版）です。
なお、Gradle 9 では、以前から非推奨になっていたプロジェクトの exec() 呼び出しが使えなくなっています。古い書き方のままのスクリプトが新しい Gradle で動かなくなる、というのが「Could not find method exec()」の読み方の骨格です。ただ、これは私が公式の移行ガイドの記述から理解していることで、個々のログで確かめたわけではありません。ですから「Gradle が新しくなった」と決めつける前に、次の順で事実を一つずつ拾います。
- 落ちたスクリプトのパッケージ名を取り出す
- そのパッケージの、いま入っている版を見る
- 同じ症状の報告があり、直った版が示されているかを見る
- 版を上げ、同じ依存の組み合わせでビルドし直す
1 と 2: ログからパッケージを取り出す小さなスクリプト
毎回ログを目で追うのは疲れるので、次のスクリプトにしました。EAS の画面からログを保存して渡すだけで、パッケージ名・スクリプト名・行番号・症状を出します。
#!/usr/bin/env bash
# 使い方: bash who-called-gradle.sh build.log
# Gradle のログから「どの node_modules のスクリプトが、何行目で落ちたか」を取り出す
log="${1:?ログファイルを渡してください}"
line=$(grep -m1 "^Script '" "$log") || { echo "Script 行が見つかりません（アプリ側の build.gradle で落ちている可能性）"; exit 1; }
path=$(printf '%s' "$line" | sed -E "s/^Script '([^']+)'.*/\1/")
lno=$(printf '%s' "$line" | sed -E "s/.*line: ([0-9]+).*/\1/")
pkg=$(printf '%s' "$path" | sed -E 's#.*/node_modules/((@[^/]+/)?[^/]+)/.*#\1#')
echo "package : $pkg"
echo "script : ${path##*/node_modules/}"
echo "line : $lno"
grep -m1 -oE "Could not find method [a-zA-Z]+\(\)" "$log" | sed 's/^/symptom : /'
echo "next : npm ls $pkg # 入っている版を確かめる"このスクリプトを、上のログと同じ形のサンプル（sample-eas.log）に対して実行すると、次のように出ました。
package : @sentry/react-native
script : @sentry/react-native/sentry.gradle
line : 127
symptom : Could not find method exec()
next : npm ls @sentry/react-native # 入っている版を確かめるScript 行が無いログ（たとえば plain error とだけ書いたファイル）を渡したときは、「アプリ側の build.gradle で落ちている可能性」と出して終了コード 1 で止まります。この分岐を入れたのは、スクリプトが「何も出さずに成功したように見える」状態をいちばん避けたかったからです。
サンプルのログは、Issue の文言をもとに私が書き起こしたものです。実際の EAS のログで、行番号や前後の出力が異なる場合は、grep のパターンを合わせていただければと思います。
3: 同じ症状で、直った版が示されているか
パッケージ名が分かったら、そのリポジトリの Issue か、Expo 側の Issue を検索します。今回の例なら、@sentry/react-native の 7.3.0 で直ったと書かれていました。入っている版が 7.2.0 なら、一致です。
ここで注意したいのは、Expo の推奨版（npx expo install が入れる版）と、パッケージ側の修正版が食い違うことがある点です。Issue の報告者は、Expo が勧めている版そのものが 7.2.0 で、そこが症状の入口になっていると指摘していました。「expo install で入れたから大丈夫」とは限らない、ということです。
# 入っている版（依存の依存として入っていないか）を確かめる
npm ls @sentry/react-native
# Expo が想定している版とのずれを見る
npx expo install --check後者は、版が食い違っているパッケージを一覧にして、直すかどうかを聞いてきます。直す前に、まず出力を保存しておきます。何が動いたかを、あとで読み返せるようにするためです。
4: 版を上げて、同じ条件で投げ直す
修正版が分かれば、その版を明示して入れ直します。
npx expo install @sentry/react-native@7.3.0 # 例: 修正が入った最小の版
npx expo-doctor # 依存の食い違いが増えていないか
eas build --platform android --profile productionここで、7.3.0 と固定したのは、Issue に「修正はこの版から」と書かれていたからです。最新版へ一気に上げる手もありますが、依存の食い違いが別の場所で増えることもあり、私はまず最小の版で通ることを確かめてから、上げるかどうかを分けて考えるようにしています。
まだ分からないこと
個人開発で Android のリリースビルドを自分の手で回していると、こうした「確かめきれていない点」を抱えたまま進める場面が少なくありません。今回の整理にも、確かめられていない点が三つあります。
| 確かめていないこと | 理由 |
|---|---|
| EAS 上で同じエラーを再現したか | していません。ログ解析のスクリプトだけを、サンプルのログで実走しました |
| Gradle 9 のどの変更が直接の原因か | Issue のページに仕組みの説明が無く、題名の見立てを引いています |
| 他の Gradle スクリプトにも同じ書き方が残っていないか | Sentry 以外は調べていません |
三つ目は、特に気になります。Sentry で起きたのなら、同じ古い書き方を残したまま、まだ誰も踏んでいないパッケージがあるかもしれません。SDK を上げるたびに、node_modules 以下の .gradle を一度 grep -rn "exec(" node_modules --include=*.gradle で眺めておくと、本番ビルドの前に気づける可能性があります。
今回の線引き
ビルドの失敗は、赤い最後の一行を直そうとして、遠回りになることが多いと感じています。
エラー文の最後ではなく、その上の「どこで落ちたか」の一行から読みます。 版の話になるのは、その一行がパッケージを指したあとです。
次の一歩として、手元の直近の失敗ログが残っていれば、このスクリプトに一度通してみていただければと思います。パッケージ名が出れば、半分は終わっています。
依存の版が気づかないうちにずれていく話は、expo install の同梱モジュールが、パッチ更新でどれだけずれるかを数えた記事にもまとめています。
Sources: