GitHub Actions の「Process completed with exit code 137」：メモリで強制終了されたプロセスと、ランナーのメモリの量
終了コード 137 は 128 + 9 で、ステップの中のプロセスが SIGKILL で終わったことを表します。自分のコードがこの合図を送ることはなく、GitHub のホストのランナーでは、ほとんどがカーネルの OOM killer（メモリ不足のときに大きなプロセスを選んで止める仕組み）によるものです。仮想マシンのメモリが尽きると、プロセスが止められてステップが失敗し、ジョブはそれを報告して続きます。仮想マシン全体があふれたときは、ランナーそのものが失われます（「The runner has received a shutdown signal」）。
見え方
止められたプロセスは自分では何も出しません。シェルかタスクランナーが強制終了を知らせ、ステップは 137 で、またはラッパーが自分の失敗に置き換えて 1 で失敗します（microsoft/vscode #341818）：
[eslint ] Killed ERROR: "eslint" exited with 137. ##[error]Process completed with exit code 1.
モノレポでは、タスクランナーがパッケージの名前を出します（desk-skills #409）：
##[error]@repo/api#type-check: command (.../packages/api) pnpm run type-check exited (137) ##[error]Process completed with exit code 137.
たいていは、ときどきしか起きません。vscode では、2026年10月14日と15日のプルリクの実行のうち直近80回中3回で ESLint が止められました。実行が始まって4分45秒、同じランナー（このプロジェクトの独自の大きいランナー）で縮小したバンドルを並行してビルドしている最中でした。もう1つの報告では、同じジョブが前後の main では通っていて、ブランチに直すものはありませんでした。止められるかどうかは、同じ瞬間にほかの何がピークを迎えるかで決まります。
ランナーのメモリの量
GitHub の標準のランナーの説明から（GitHub-hosted runners）：
ubuntu-latestとほかの Ubuntu のラベル、Windows：公開のリポジトリでは 4 CPU・16 GB、非公開と内部のリポジトリでは 2 CPU・8 GB。ubuntu-slim：1 CPU・5 GB。共有の仮想マシンの上のコンテナーです。macos-latest・macos-15・macos-26・xcode-27（Apple Silicon）：3 CPU・7 GB。Intel の macOS のラベルは 14 GB。
そのため、公開のリポジトリで通っていたジョブが、非公開のリポジトリに移ると止められることがあります。メモリも CPU も半分になるからです。
プロセスの見つけ方
- 終了コードの前の行に、たいていコマンドの名前が出ます（上の例のとおり）。出ないなら、試しのブランチでステップを1つずつ動かします。
- Ubuntu のランナーでは
sudoが使えるので、失敗のあとのステップでカーネルの強制終了の記録を読めます：- if: failure() run: sudo dmesg -T | grep -i -E "out of memory|killed process" || true
- ステップがどこまで近づくかは、
/usr/bin/time -vの下で動かして「Maximum resident set size」を見るか、前後でfree -mを出して確かめます。
ピークの下げ方
- 同時に動かすものを減らす。この強制終了のほとんどは、重いプロセスがいくつも並行しているときに起きます。タスクランナーの並列数（Turborepo の
--concurrency・make -j）やテストのワーカー数（Jest の--maxWorkers）を下げるか、重い確認を別のジョブに分けます。別のジョブには別のランナーが付きます。 - Node.js なら、
NODE_OPTIONS=--max-old-space-size=...（MB）でヒープの上限をランナーのメモリより下に置きます。その上限に達したプロセスは「JavaScript heap out of memory」と言って失敗するので、黙って止められるより原因が分かります。ランナーのメモリより上の上限は、強制終了の時期をずらすだけです。 - 古いツールチェーン向けに作られたツールは、新しいものの上でずっと多くのメモリを使うことがあります。golangci-lint v1.64.8 は Go 1.26 の上でメモリが際限なく増えます（Go 1.24 がイメージから消える）。
- スワップのファイルを足すと、短いピークは速さと引き換えにしのげますが、ディスクを使います（No space left on device）。
- 作業がそれだけ要るなら、メモリの多い大きいランナーを使います。
見分け方
- 終了コード 143 は 128 + 15 の SIGTERM：ジョブがキャンセルされたか、時間切れか、ランナーを失いました（停止の合図・「The operation was canceled」・実行時間の上限）。
- 終了コード 134 と「FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory」：ランナーのメモリでなく、Node.js が自分のヒープの上限に達しました。
- 「No space left on device」：メモリでなくディスクです（何を消すか）。
失敗したジョブを IntelliJ IDEA から見るなら
Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べるので、強制終了されたステップがすぐ分かり、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。
GitHub と GitHub Actions は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc. とも JetBrains とも提携しておらず、承認も受けていません。
ほかに：The runner has received a shutdown signal · No space left on device · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English