exe が他の PC で動かない — PyInstaller のエラー別 原因逆引きガイド

cd /d "C:\tools\SampleTool"
SampleTool.exe

1. 症状から探す — 画面に出た文言別 逆引き表

「exe が動かない」という一言には、原因の異なる現象が 3 系統まざっています。切り分けの起点は、配布先の画面に何が出たかです。エラーダイアログが出たならタイトルバーの文字列が最短の手がかりになり、黒い窓が一瞬光っただけならコンソール版で例外が起きた可能性が高く、本当に何も起きないなら別の調べ方が要ります。

図にすると次のようになります。配布先の人に電話で聞くときも、「何が出ましたか」ではなく「窓のタイトルバーに何と書いてありましたか」と聞くと一発で分岐できます。

2. 配布先 PC で情報を集める — Python が入っていない環境でやること

逆引き表を引くにも、まず何かしらの文字列を手に入れる必要があります。ここが一番の関門です。配布先の PC には Python が入っておらず、開発ツールも無く、多くの場合は管理者権限もありません。その条件で使える手段を、効果が高い順に 5 つ並べます。いずれも追加インストールは不要で、Windows に最初から入っているものだけで完結します。

2.1 コマンドプロンプトから起動する — 最初の一手

エクスプローラーからのダブルクリックは、プロセスが終わると窓ごと消えます。コマンドプロンプトを先に開いてそこから起動すれば、プロセスが終わっても窓は残るので、最後に出た行を読めます。

REM 1) スタートメニューで「cmd」と入力してコマンドプロンプトを開く
REM 2) exe を置いたフォルダへ移動する（/d はドライブごと移動する指定）
cd /d "C:\tools\SampleTool"

REM 3) 直接起動する
SampleTool.exe

REM 4) 終了コードを見る
echo %errorlevel%

フォルダのパスが分からない場合は、エクスプローラーでフォルダを開いてアドレスバーに cmd と打てば、そのフォルダを開いた状態のコマンドプロンプトが立ち上がります。相手に電話で説明するときはこの方法のほうが確実です。

終了コードの読み方には注意点が 2 つあります。当サイトの検証機で測った値は次のとおりでした。

もう 1 つは、--noconsole でビルドした exe をコマンドプロンプトから起動すると、cmd は終了を待たずに次のプロンプトを返すことです。直後に echo %errorlevel% を打っても、そこに出るのは前のコマンドの結果です。終了コードまで見たいときは start /wait SampleTool.exe で起動してください（この挙動は親記事 5.2 でも触れていますが、同じ節にある「--noconsole ではトレースバックが出ない」という記述はこの点で古く、最新の実測は本記事 3.2 です）。

2.2 .bat でログにリダイレクトする — 相手に操作させずに採る

配布先の担当者にコマンドプロンプトを操作してもらうのが難しい場合は、ログを取る .bat を渡すのが確実です。「いつものアイコンの代わりに、この run.bat をダブルクリックしてください」だけで済みます。すでに配ったあとでも間に合います——下の 5 行をメモ帳に貼って run.bat という名前で保存し、メールか共有フォルダで送って「exe と同じフォルダに置いて、これをダブルクリックしてください」と伝えるだけです。exe を配り直す必要はありません。メモ帳で保存するときは、ファイルの種類を「すべてのファイル」にして拡張子が run.bat.txt にならないようにしてください。次に配るときから同梱しておけば、この往復自体が無くなります。最小構成は 5 行です。

@echo off
cd /d "%~dp0"
if not exist logs mkdir logs
"%~dp0SampleTool.exe" 1>> "logs\stdout.log" 2>> "logs\stderr.log"
echo [%date% %time%] exit=%errorlevel% >> "logs\stderr.log"

実際に、設定ファイルをわざと消した exe をこの .bat から起動して得た logs\stderr.log がこちらです（パスは記事用に置き換え。この採取はコンソール版ビルドで行ったので、最終行の exit=1 も実際の終了コードです）。

Traceback (most recent call last):
  File "sample_tool.py", line 27, in <module>
  File "sample_tool.py", line 20, in main
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\work\\SampleTool\\config.json'
[PYI-4796:ERROR] Failed to execute script 'sample_tool' due to unhandled exception!
[2026/09/03 17:46] exit=1

ここで効いているのは、リダイレクト先のファイルが「有効な標準エラー出力」になる点です。--noconsole でビルドした exe でも、この形なら Python のトレースバックがファイルに残ります（3.3 で、この差が決定的になる場面を扱います）。1>> が通常のメッセージ（標準出力）、2>> がエラーメッセージ（標準エラー出力）の行き先で、>> は追記なので起動のたびに消えずに溜まります。%~dp0 は .bat 自身の置き場所なので、ショートカット経由で呼ばれても作業ディレクトリがぶれません。

1 点だけ注意があります。--noconsole でビルドした exe の場合、2.1 と同じ理由で cmd は exe の終了を待たずに次の行へ進むため、最終行の exit= は当てになりません（アプリが終わる前に、前のコマンドの値で書かれます）。終了コードまで採りたいときは 4 行目を start /wait "" "%~dp0SampleTool.exe" 1>> "logs\stdout.log" 2>> "logs\stderr.log" に変えてください。トレースバックのリダイレクト自体は start /wait なしでも成立しますので、原因を知りたいだけならこのままで足ります。

ログ回収だけでなく、作業ディレクトリの固定・異常終了時の自動再起動まで含めた本格的なランチャーは親記事 7 章にあります。そもそも自前の logging でファイルに残す設計にしておけば、この作業自体が不要になります（24 時間動くアプリのロギング設計）。

2.3 --debug=all でビルドし直す — 起動のどこで止まったかを見る

ログが空、あるいはトレースバック以前で止まっている疑いがあるときは、診断情報を出すビルドを作って配ります。PyInstaller 公式の "When Things Go Wrong" は 「The --debug=all option (and its choices) provides a significant amount of diagnostic information.」と書いています。実際どのくらい出るのかを測りました。

pyinstaller --noconfirm --clean --onefile --debug=all --name SampleToolDbg sample_tool.py

できた exe を 1 回起動しただけで、標準エラー出力に 729 行が流れました（当サイト検証機・PyInstaller 6.22.2）。全部読む必要はありません。見るべきは冒頭の 20 行ほどで、そこから要点だけを抜き出したのが次の 12 行です（連続した出力ではなく、間の行を省いた抜粋です）。

[PYI-13464:DEBUG] PyInstaller Bootloader 6.x
[PYI-13464:DEBUG] LOADER: executable file: C:\work\SampleTool\SampleToolDbg.exe
[PYI-13464:DEBUG] LOADER: trying to load executable-embedded archive...
[PYI-13464:DEBUG] LOADER: cookie found at offset 0x725914
[PYI-13464:DEBUG] LOADER: application has onefile semantics...
[PYI-13464:DEBUG] LOADER: creating temporary directory (runtime_tmpdir=(null))...
[PYI-13464:DEBUG] LOADER: created temporary directory: C:\Users\<ユーザー名>\AppData\Local\Temp\_MEI000034982
[PYI-13464:DEBUG] LOADER: attempting to pre-load system copy of VCRUNTIME140.dll...
[PYI-13464:DEBUG] LOADER: successfully loaded system copy of VCRUNTIME140.dll.
[PYI-13464:DEBUG] LOADER: extracting files to temporary directory...
[PYI-13464:DEBUG] LOADER: starting the child process...
[PYI-13464:DEBUG] LOADER: child process started!

この 12 行だけで、どこまで進んだかが分かります。「一時フォルダは作れたか」「VC++ ランタイムは読めたか」「展開は終わったか」「子プロセスは起動したか」。たとえば creating temporary directory の直後で止まっていれば、%TEMP% の書き込み権限や容量を疑う番です。展開後の import で止まっているなら、その少し先に import 'json.encoder' # ... のような行が延々と並ぶので、どのモジュールの直後で止まったかが読み取れます。

--debug=imports だけに絞ると Python の -v 相当の import ログになり、依存の取りこぼしを追うときはこちらのほうが読みやすくなります。診断用ビルドは診断が終わったら必ず捨ててください。この exe は起動のたびに 729 行を吐くので、そのまま現場に残すと .bat のログが数分でふくれ上がります。

2.4 onefile の一時展開先 %TEMP%\_MEIxxxxxx を見る

--onefile で作った exe は、起動のたびに %TEMP% の下へ中身を自己展開してから動きます。展開先のフォルダ名は _MEI ＋乱数で、起動のたびに変わります。同じ exe を 2 回動かして採った実測値がこちらです。

1 回目  _MEIPASS : C:\Users\<ユーザー名>\AppData\Local\Temp\_MEI000014642
2 回目  _MEIPASS : C:\Users\<ユーザー名>\AppData\Local\Temp\_MEI000037342

ここが調査に使えるのは、正常に終わったときは消えるのに、異常終了すると残るからです。数えて確かめました。実行前に %TEMP% にあった _MEI* フォルダは 17 個（本記事の検証で強制終了を繰り返した残骸です）。exe を起動している最中は 18 個に増え、プロセスを強制終了したあとも 18 個のままでした。1 回目の実行で作られたフォルダは、2 回目の実行時点では消えています。

つまり配布先で %TEMP% を開いて _MEI で始まるフォルダがいくつも溜まっていたら、それは「このアプリは過去に何度も正常に終わっていない」証拠です。エクスプローラーのアドレスバーに %TEMP% と打てば開けるので、相手に頼むのも簡単です。ゴミとして消しても構いません。ただし対象アプリを終了させてから、_MEI で始まるフォルダだけにしてください（%TEMP% には他アプリの一時ファイルも同居しています）。実行中のフォルダは通常ロックされていて削除できませんが、業務 PC で消す場合は情報システム部門・設備保全部門の運用ルールに従ってください。

逆に、この展開先を前提にしたパス処理は事故のもとです。展開先は毎回変わるうえ、終了時に丸ごと消えます。設定ファイルやログを書く場所は exe の隣に置くのが原則で、その書き分けは親記事 6.4 にまとめてあります。

2.5 イベントビューアーは「効く場合」が限られる

Windows のイベントビューアー（eventvwr、または「Windows ログ > Application」）を見る手もありますが、これが役に立つ範囲は思ったより狭いので、実際に測って線を引きました。同じ検証機で 2 つのケースを実行し、直後の Application ログを数えた結果です。

ネイティブ側で落ちたときのイベント本文はこう出ました。

障害が発生しているアプリケーション名: HardCrash.exe、バージョン: 0.0.0.0
障害が発生したモジュール名: ucrtbase.dll、 バージョン: 10.0.26100.8875
例外コード: 0xc0000409
フォールト オフセット: 0x00000000000a527e

OS ビルドは 26200 なのに ucrtbase.dll が 10.0.26100.8875 なのは異常ではありません。Windows 11 の 25H2（ビルド 26200）は、24H2（ビルド 26100）に対する有効化パッケージです。両者は同じサービシングブランチとシステムファイルを共有していて、月例更新も 26200 と 26100 の 2 つのビルド番号を並記した 1 つの KB で配られます。表示上のビルド番号が上がっても、システム DLL の版数はベース側の 26100 系のままというわけです。ここで見るべきは版数ではなくファイル名のほうです。

読み方はこうです。イベントが残っていたら、それは Python の例外ではありません。「障害が発生したモジュール名」に出ている DLL が犯人側で、C 拡張やドライバまわりを疑う番になります。逆にイベントが 1 件も無いなら、Python の例外か、そもそも起動していないかのどちらかで、この場合は 2.1〜2.3 に戻ります。「イベントビューアーに何も無い」ことにも情報があるという使い方です。

2.6 手段の使い分けと、クリーンな Windows で試すという選択肢

もう 1 つ、手元にクリーンな Windows を用意して自分で再現するという王道があります。Python が 1 つも入っていない配布先相当の環境を数秒で用意できるのが、Microsoft 公式が「起動のたびに新規インストール同然の状態になる」使い捨て環境として提供する Windows Sandbox です。ただし公式ドキュメントは対応エディションを Pro / Enterprise / Pro Education・SE / Education と定めており、「Windows Sandbox is currently not supported on Windows Home edition.」と明記しています。Home 機しか手元にない場合はこの手は使えません。

当サイトの検証機では Windows Sandbox を有効化していないため、この記事のログはクリーン VM で採ったものではありません。本記事の実測はすべて、開発機上で「配布先で起きる状態」を意図的に作って採取したものです（_internal を外す・設定ファイルを消す・依存モジュールを除外する）。したがって「Python が一切入っていない PC 固有の問題」は本記事では再現できていません。この点は 11 章に未検証項目として明記します。

3. 一瞬で閉じる・何も起きない

もっとも多い訴えが「ダブルクリックしても何も起きない」です。実際には「一瞬だけ黒い窓が出た」と「本当に何も出なかった」はまったく別の症状で、原因も対処も分かれます。まずここを確定させてください。

3.1 黒い窓が一瞬出て消える — コンソール版

--noconsole を付けずにビルドした exe は、起動するとコンソール窓を持ちます。この窓はプロセスの終了と同時に閉じるため、例外で落ちた場合はトレースバックが表示された直後に消えます。読める時間はありません。

やることは 1 つ、2.1 のコマンドプロンプト起動です。cmd の窓は exe が終わっても残るので、最後の数行がそのまま読めます。ここでトレースバックが出れば 4 章、Failed to load Python DLL が出れば 5 章へ進みます。

なお input("Press Enter") をスクリプトの末尾に足して窓を止める方法はよく紹介されますが、例外で落ちる場合はその行まで到達しないので効きません。窓を止めたいなら Python 側ではなく .bat の末尾に pause を置くほうが確実です。

3.2 --noconsole でも、落ちればダイアログは出る（6.22.2 実測）

ここは日本語の解説で説明が割れているところなので、実際に測りました。「--noconsole にすると例外が画面に出なくなる」は、条件付きでしか正しくありません。

設定ファイルを読めずに落ちる --noconsole ビルドの exe を起動し、表示されたウィンドウのテキストを Win32 API で採取した結果がこちらです（onefile / onedir どちらでも同じダイアログが出ました）。

[ウィンドウのタイトル] Unhandled exception in script
[本文]
Failed to execute script 'sample_tool' due to unhandled exception:
[Errno 2] No such file or directory: 'C:\work\SampleTool\config.json'
[テキストボックス]
Traceback (most recent call last):
  File "sample_tool.py", line 27, in <module>
  File "sample_tool.py", line 20, in main
FileNotFoundError: [Errno 2] No such file or directory: 'C:\work\SampleTool\config.json'
[ボタン] Close

依存モジュールが足りないケース（--exclude-module tkinter で故意に作ったもの）でも同じ形式でした。

[ウィンドウのタイトル] Unhandled exception in script
[本文] Failed to execute script 'app_tk' due to unhandled exception: No module named 'tkinter'
[テキストボックス]
Traceback (most recent call last):
  File "app_tk.py", line 1, in <module>
ModuleNotFoundError: No module named 'tkinter'

つまり PyInstaller 6.22.2 では、スクリプトが未処理例外で終了する限り、--noconsole でもトレースバック付きのダイアログが出ます。配布先の人が「エラーが出た」と言っているなら、そのダイアログの下半分のテキストボックスをスクロールして写真を撮ってもらうだけで、調査はほぼ終わります。

ここで当サイト自身の記述を訂正します。親記事「PyInstaller で exe 化して現場に配布する」の 5.2 は、PyInstaller 5.x 時代の理解のまま「--noconsole でビルドした exe はコンソールを持たないため、ダブルクリックで起動した場合このトレースバックは画面に出ない」と書いてありました。この記述は 6.22.2 の実測で覆りました——上のとおり、ダイアログという別の出口から出ます。親記事の該当箇所は古い記述としてお読みください。

ただし、これは「スクリプトが終了する例外」に限った話です。次項がその落とし穴です。

3.3 本当に何も出ないケース — 例外が捕まって出口を失っている

GUI アプリでいちばん厄介なのが、例外が発生してもプロセスが終わらない形です。tkinter はコールバック内で起きた例外を自前で捕まえ、標準エラー出力へ書き出してからイベントループを続けます。ここで --noconsole ビルドだと、その標準エラー出力の行き先がありません。

実測しました。after() のコールバックで例外を投げる tkinter アプリを --onefile --noconsole でビルドし、ダブルクリック相当で起動してウィンドウを列挙した結果です。

HasExited=False
--- window dump ---
  [top:TkTopLevel] visible=True title=SampleTool
  [top:PyInstallerOnefileHiddenWindow] visible=False
（エラーダイアログ = クラス #32770 のウィンドウは 1 つも存在しない）

ダイアログは出ず、ウィンドウは開いたまま、アプリは動き続けます。ボタンを押しても何も起きない、値が更新されない——現場から上がってくる「フリーズした」「反応しない」の正体はこれであることが多いです。

ところが、まったく同じ exe を 2.2 の .bat 経由（標準エラー出力をファイルへリダイレクト）で起動すると、内容はきちんと残ります。

Exception in Tkinter callback
Traceback (most recent call last):
  File "tkinter\__init__.py", line 1968, in __call__
  File "tkinter\__init__.py", line 862, in callit
  File "cb_tool.py", line 4, in boom
RuntimeError: callback failed

差は exe ではなく起動方法だけです。--noconsole ビルドは標準エラー出力が有効なハンドルに繋がっていれば普通に書き込み、繋がっていなければ捨てます。だから GUI アプリを配るときは、ランチャー .bat 経由にするか、アプリ側で logging をファイルへ向けておくかのどちらかが実質必須になります。後者の設計は ロギング設計の記事に、GUI 側で例外をどう見せるかは tkinter で監視アプリを作るにまとめています。

それでも本当に何も起きない場合、残る可能性は 3 つです。①ウイルス対策ソフトに削除されて exe 自体が存在しない（8.2）、②実行制御でブロックされている（同）、③二重起動を防ぐ作りで、既存プロセスがバックグラウンドに残っている。③はタスクマネージャーの「詳細」タブに同名のプロセスが居るかどうかで判別できます。

4. Failed to execute script — 未処理例外で落ちている

検索で最も多く踏まれる文言がこれです。まず押さえるべきは、Failed to execute script は原因ではなく結果の報告だということ。PyInstaller が「あなたのスクリプトが例外で終わりました」と言っているだけで、原因は必ずその後ろに書かれています。

4.1 6.x での実際の出方

バージョンによって出方が違うため、6.22.2 での実測を並べます。

古い記事に出てくる Failed to execute script my_gui という素っ気ない 1 行だけの表示は、当サイトの検証環境（6.22.2）では現れませんでした。試した 3 パターン（設定ファイル欠落の onefile / 同じく onedir / モジュール欠落）のいずれも、例外の型と内容が同じ画面に併記されています。逆に言えば、いま Failed to execute script しか見えていないのであれば、その下や右にまだ読んでいないテキストが隠れている可能性が高いです。

公式ドキュメントの推奨手順も同じ方向を向いています。"When Things Go Wrong" は 「If you are using the --windowed option, your bundled application may fail to start with an error message like Failed to execute script my_gui.」と現象を挙げたうえで、「For Windows, you will need to re-bundle your application without the --windowed option. Then you can run the resulting executable from the command line, i.e. my_gui.exe.」と案内しています。ただし再ビルドの前に 2.1 をやってください。再ビルドして配り直すのは往復が 1 回増えるので、まず今ある exe から採れる情報を採り切るほうが早く終わります。

4.2 トレースバックの最終行で原因を分ける

トレースバックさえ手に入れば、あとは最終行の例外型で分岐できます。配布先だけで起きるということは、開発機にあって配布先に無いものが原因です。

この表で最も多いのは 1 行目です。開発機では「たまたまカレントディレクトリにファイルがあった」から動いていたという筋書きで、配布先ではショートカット経由で起動された途端に見つからなくなります。

次に多い ModuleNotFoundError について、その場でできる確認を 1 つだけ書いておきます。開発機の dist\アプリ名\_internal\ を開き、落ちたモジュールのフォルダか .pyd が入っているかを見てください。無ければビルド時に収集されていないので、--hidden-import モジュール名 を足して作り直します。収集漏れの主因は動的 import・importlib 経由・プラグイン読み込みの 3 つで、収集ルールと --collect-all の使い分けは親記事 6.3 にまとめてあります。

5. exe だけをコピーした — _internal が無い

「dist フォルダの中に exe があったので、それだけコピーして渡した」——onedir でビルドしたときに必ず一度は通る事故です。

5.1 実際に出るエラー

onedir でビルドした配布フォルダから SampleTool.exe だけを別フォルダにコピーして起動しました。コマンドプロンプトから起動したときの標準エラー出力です。

[PYI-14744:ERROR] Failed to load Python DLL 'C:\work\SampleTool\_internal\python312.dll'.
LoadLibrary: ???????????????????

終了コードは -1（0xFFFFFFFF）でした。--noconsole でビルドした場合は、次のダイアログが出ます。

[ウィンドウのタイトル] Error
[本文]
Failed to load Python DLL 'C:\work\SampleTool\_internal\python312.dll'.
LoadLibrary: 指定されたモジュールが見つかりません。
[ボタン] OK

並べると妙なことに気付きます。ダイアログには日本語で「指定されたモジュールが見つかりません。」と出るのに、コンソール側は疑問符の羅列になっています。これは文字化けの表示バグではありません。出力ファイルをバイト単位で確認したところ、その部分は本当に 0x3F（半角の ?）が並んでいました。ブートローダーが Windows のシステムエラー文言をコンソールへ書き出すときに、日本語をすべて ? に潰しているということです。したがってコンソールで LoadLibrary: ??? を見たら、ダイアログ版（--noconsole ビルド）で読み直すか、素直に「DLL が見つからない」と解釈して先へ進んでください。? の数を数えても意味はありません。

5.2 5.x 時代の情報と食い違う理由

PyInstaller 6.0.0 で onedir のレイアウトが変わりました。それ以前は exe と大量の DLL が同じ階層に並んでいましたが、6.0 以降は exe 以外がすべて _internal/ というサブフォルダに入ります。見た目が「exe 1 個 ＋ フォルダ 1 個」になったせいで、exe 単体で完結していると誤解しやすくなったのがこの事故の本質です。

当サイトの検証機で作った最小構成の内訳がこちらです。

import を 1 つも書いていないスクリプトでもこれだけ並びます。中身を見てもどれが自分のアプリに要るのかは判断できないので、「必要そうなものだけ選んでコピーする」はやめて、フォルダごと運んでください。Python 本体（python312.dll）が _internal/ に居るのですから、exe だけでは何もできません。これは「同梱漏れ」ではなく「配布物を分割してしまった」事故です。

5.3 対処 — フォルダごと渡すか、onefile にするか

• フォルダごとコピーする。zip に固めて渡すのが確実です。「exe だけ抜き出さないでください」という注意書きは、たいてい読まれません
• ZIP のまま実行させない。エクスプローラーで zip を開いて中の exe をダブルクリックすると、一時展開先で _internal が揃わずに同じエラーになります。必ず「すべて展開」してもらう手順にします
• --onefile にする。1 ファイルなので分割されようがありません。代わりに起動のたびに展開コストがかかります（親記事 3 章で onefile と onedir を実測比較しています）
• --contents-directory で名前を変える。_internal という名前が「消していいもの」に見えるのが問題なら、runtime などに変えられます（6.0.0 で追加）

現場の運用としては、ショートカットを配ってフォルダ本体は共有フォルダに置く形にすると、コピーの分割自体が起きなくなります。この配布方式は親記事 9 章で扱っています。

6. DLL load failed / DLL が見つからない

_internal が揃っているのに DLL 関連で落ちる場合は、話が一段深くなります。ここは「とりあえず VC++ 再頒布可能パッケージを入れる」で片付けてはいけない領域です。

6.1 まず、何が同梱されていて何が同梱されていないかを見る

5.2 の実測のとおり、最小構成の _internal/ に入っていた DLL は python312.dll ・ VCRUNTIME140.dll ・ libcrypto-3.dll の 3 つだけでした。api-ms-win-crt-*.dll（Universal CRT）は入っていません。これは重要な事実で、6.3 の議論の前提になります。

調べ方は単純で、開発機の dist\アプリ名\_internal\ を開いて DLL の一覧を見るだけです。numpy や pandas のような大きなライブラリを使っていれば、ここに数十〜数百の DLL と .pyd が並びます。「配布先で落ちたモジュール名」がこの一覧に無ければ、収集漏れです。

6.2 間接依存を辿る — 開発機側の作業

ImportError: DLL load failed while importing xxx がやっかいなのは、足りないのが xxx 自身ではなく、xxx が依存している DLL のさらに依存先であることが多い点です。ファイルの有無を目視で確認しても見つかりません。この型は昔から報告されていて、PyInstaller の Issue #1679（2015 年・PyInstaller 2.1〜3.0 時代の報告）はタイトルからして「同じ Windows のバージョンの別 PC で exe が動かない」で、本文に貼られているのが ImportError: DLL load failed です。OS のバージョンが同じでも、インストール済みのランタイムやドライバ由来の DLL は PC ごとに違います。

依存ツリーを末端まで辿るには、GitHub の lucasg/Dependencies（MIT ライセンス・最新 v1.11.1）が使えます。リポジトリ自身の説明は 「A rewrite of the old legacy software "depends.exe" in C# for Windows devs to troubleshoot dll load dependencies issues.」で、古い Dependency Walker が扱えなかった api-ms-win-* の API セット解決にも対応しています。ただし最新リリースの v1.11.1 は 2021 年 10 月で、以降の更新は止まっています。当サイトではこのツールを使った検証は行っていません（本記事の DLL 関連の実測は 5.1 と 6.1 の範囲です）。

注意点は、これが開発機側で使うツールだということ。配布先の PC に解析ツールを入れて回るのは現実的ではありませんし、多くの現場では許可も下りません。配布先でやるのは 2.1〜2.3 で文字列を採るところまで、解析は持ち帰ってからという分担にしてください。

6.3 VC++ 再頒布可能パッケージは、2026 年の主因ではない

「他の PC で動かない → VC++ 再頒布可能パッケージを入れろ」という説明が今も上位に残っていますが、この処方箋が有効だった時期はほぼ終わっています。PyInstaller 公式は 「Python 3.5+ uses Visual Studio 2015 run-time, which has been renamed into "Universal CRT" and has become part of Windows 10.」と書いており、Windows 10 以降では UCRT が OS の一部です。だから Windows 10 / 11 の配布先で「CRT が無い」ことは起こりません。5.2 の実測で api-ms-win-crt-*.dll が同梱されていなかったのは、同梱する必要が無いからです。

なお同じ公式ページは、この文の直前で「開発者は VC++ ランタイムの DLL の同梱に特別な注意を払う必要がある」とも書いています。ただしそこで挙げられている選択肢（Windows 7 でビルドする・VCRedist を同梱する・SDK から DLL を取り込む）は、Windows Vista〜8.1 を配布先に想定した話です。引用元は 1 つでも、対象 OS が違えば結論は変わります。

残る VCRUNTIME140.dll については、PyInstaller が配布物に同梱していることを 5.2 で確認しました。さらに --debug=all のログを読むと、起動時の挙動まで分かります。

[PYI-13464:DEBUG] LOADER: attempting to pre-load system copy of VCRUNTIME140.dll...
[PYI-13464:DEBUG] LOADER: successfully loaded system copy of VCRUNTIME140.dll.
[PYI-13464:DEBUG] LOADER: attempting to pre-load system copy of VCRUNTIME140_1.dll...
[PYI-13464:DEBUG] LOADER: successfully loaded system copy of VCRUNTIME140_1.dll.

ブートローダーは、同梱物より先に OS 側のコピーを読もうとします（そして当検証機では成功しています）。つまり配布先に新しいランタイムが入っていればそれを使い、無ければ同梱物にフォールバックする作りです。VC++ 再頒布可能パッケージを別途入れないと動かない、という前提が最初から成り立っていません。

では api-ms-win-crt-runtime-l1-1-0.dll が見つかりません が出るのはどんな場合か。配布先が Windows 7 / 8.1 で、Universal CRT の更新（KB2999226）が当たっていないときです。この更新は Windows Update 経由で配られており、Microsoft のダウンロードセンターからも入手できます。2026 年時点で残っている現場 PC は多くありませんが、装置に付属した古い PC が生き残っている現場では起こり得ます。

どうしても VC++ 再頒布可能パッケージを同梱する必要がある場合は、バージョン固定の URL ではなく永続リンク https://aka.ms/vc14/vc_redist.x64.exe（x86・ARM64 は末尾の x64 を x86 / arm64 に差し替え）を使ってください。ただしこの最新版が対応する OS は Windows 10 / 11 と Windows Server 2016 以降で、Windows 7 / 8.1 は対象外です（Microsoft Learn の記載。2026 年 8 月更新時点）。古い OS が相手なら、当てるのは VC++ 再頒布可能パッケージではなく KB2999226 のほうです。「とりあえず VC++ を入れる」は、対象 OS を確認しないと的外れになります。

6.4 開発機より古い Windows へ配るとき — Windows 11 で作って Windows 10 に渡す

現場でいちばん多い組み合わせが、開発機だけ Windows 11 で、配布先は Windows 10 のままという構成です。「新しい OS で作った exe を古い OS へ渡して大丈夫か」について、まず一次情報で確認できた範囲を書きます。

• PyInstaller 公式は GNU/Linux と macOS については「サポートしたい最も古いバージョンでビルドせよ」と明記しています（Linux: 「The solution is to always build your app on the oldest version of GNU/Linux you mean to support.」 / macOS: 「the only way to ensure that your frozen application supports an older version of the OS is to freeze it on the oldest version of the OS that you wish to support」）。理由は OS ごとに違います。Linux ではアプリが OS 側の libc に動的リンクし、macOS では収集した外部バイナリが特定バージョンの OS ライブラリに対してビルドされているためです。どちらも互換は新しい方向へは効くが、古い方向へは効かないという形になります。
• Windows については、同じ趣旨の一般的な記述が公式にありません。Windows 節に書かれているのは Visual C++ ランタイムの話だけで、選択肢の 1 つ目が 「Build on Windows 7 which has been reported to work.」です。これは Vista〜8.1 に配るときの Universal CRT 対策であって、Windows 10 と 11 の新旧差についての記述ではありません。

ここから言えるのは 2 点です。①Windows 10 は UCRT を OS 側に持っているので（6.3）、Windows 11 で作った exe を Windows 10 へ配って「CRT が無くて落ちる」という筋は成り立ちません。②それでも、ビルド機は配布先に合わせて古い側へ寄せるほうが安全です。「Windows なら新しい OS でビルドしても古い OS で動く」と公式が保証しているわけではなく、他 OS では逆の注意書きが出ているためです。Windows 10 が残っている職場なら、ビルド機も Windows 10 に揃えておいてください。

正直に書くと、この組み合わせは当サイトでは検証できていません。検証機は Windows 11 の 1 台だけで、Windows 10 の実機がありません。「Windows 11 で作った exe が Windows 10 で動く」ことを当サイトの実測として保証はできない、というのが本当のところです（11 章に未検証項目⑥として挙げます）。実際に古い Windows で落ちたときの進め方は他の症状と同じで、まず 2.1 で文字列を採り、DLL 名が出たら 6.2 の間接依存を辿ります。配布先の Windows のバージョンは、相手の PC で winver と入力してもらえば 1 画面で分かります。

7. 「このアプリはお使いの PC では実行できません」

この文言（英語版は "This app can't run on your PC"）が出たら、exe と OS のビット数が合っていないのがほぼ確実です。64bit の Python で作った exe は 32bit の Windows では起動できません。

PyInstaller はクロスコンパイルに対応しておらず、公式ドキュメントも OS ごとにその OS 上でビルドするよう案内しています。成果物のビット数は、ビルドに使った Python のビット数で決まります（開発機の OS のビット数ではありません）。なお公式の Requirements ページに Windows のビット数混在についての明記は無く、記載は 「PyInstaller runs in Windows 8 and newer.」のみでした。

exe 側のビット数は、配布先の PC でも PowerShell 4 行で確かめられます（PE ヘッダの Machine フィールドを読むだけで、追加ツールは不要です）。

$exe = "C:\tools\SampleTool\SampleTool.exe"
$b = [System.IO.File]::ReadAllBytes($exe)[0..1023]
$off = [BitConverter]::ToInt32($b, 0x3C)
"Machine = 0x{0:X4}" -f [BitConverter]::ToUInt16($b, $off + 4)

当サイトの検証機で作った exe は Machine = 0x8664（x64）でした。0x014C なら 32bit、0xAA64 なら ARM64 です。受け取り側 PC のアーキテクチャは echo %PROCESSOR_ARCHITECTURE% で分かります（検証機は AMD64）。この 2 つを突き合わせて食い違っていれば、原因は確定です。

正直に書いておくと、この症状は当サイトでは再現できていません。検証機に 32bit の Python 環境が無く、32bit の Windows も持っていないためです。上記のビット数確認の実測値（0x8664 / AMD64）は本物ですが、「不一致のときにこのダイアログが出る」部分は公式ドキュメントの記述と一般に知られた挙動に基づく記述で、当サイトの実測ではありません。

発生頻度についても誇張しないでおきます。2026 年時点で 32bit の Windows 10 / 11 が現場に残っているのはかなり例外的で、装置に付属した組み込み向け PC などに限られます。心当たりがあるなら、配るより先に相手の PC のアーキテクチャを聞いてしまうのが早いです。

8. UPX・ウイルス誤検知・実行制御 — 切り分け方と、この記事で扱う範囲

8.1 UPX 圧縮で DLL が壊れるという話は、現行版でどうなっているか

PyInstaller の古い Issue に「UPX 圧縮が vcruntime140.dll を壊す」という報告（Issue #1565）があり、いまも参照されています。現行版でどう扱われているかを、ソースと実データの両方から確認しました。

まず PyInstaller 6.22.2 のコードには、Control Flow Guard（CFG）が有効な Windows DLL に対して UPX を自動的に無効化する処理が入っています（PyInstaller/building/utils.py（v6.22.2）。PyInstaller のライセンスは GPL 2.0 以降で、ブートローダーの配布に関する例外付きです（SPDX: GPL-2.0-or-later WITH Bootloader-exception）。固めた exe を自分のライセンスで配れるのは、埋め込まれたブートローダー由来の制約を課さないこの例外が根拠です。以下は解説のための短い引用です）。

# On Windows, avoid using UPX with binaries that have control flow guard (CFG) enabled.
if use_upx and is_win and versioninfo.pefile_check_control_flow_guard(src_name):
    logger.info('Disabling UPX for %s due to CFG!', src_name)
    use_upx = False

では VCRUNTIME140.dll はこの判定に引っかかるのか。PyInstaller 自身の判定関数（PE ヘッダの DllCharacteristics と IMAGE_DLLCHARACTERISTICS_GUARD_CF = 0x4000 の AND を取るだけの関数）を、実際に生成された配布物の DLL に対して回しました。

読み取れることは 2 つです。Issue #1565 で問題になった vcruntime140.dll は、6.22.2 では構造的に UPX の対象外になっています。一方で自動除外はあくまで CFG 有効な DLL と Qt プラグインに限られ、python312.dll を含むそれ以外は対象外です。「6.x なら UPX は安全」とまでは言えません。

ここから先は当サイトでは検証できていません。検証機に UPX を導入していない（shutil.which("upx") が None）ため、実際に圧縮して壊れるかどうかは試していません。外部ツールを取ってきてまでの検証は、今後の宿題にします。UPX を使うかどうかの判断材料は親記事 5.3 にまとめてあります（当サイトの推奨は、成果物を毎回同じ状態にするために --noupx を付ける、です）。UPX を使っていて原因が絞れないなら、--noupx でビルドし直して症状が消えるか比べる——これが最短の切り分けです。

8.2 ウイルス対策の誤検知・実行制御によるブロック

「exe が消えた」「組織のポリシーによりブロックされました」「Windows によって PC が保護されました」——これらはプログラムの不具合ではなく、配布先 PC 側の判断です。原因も対処もまったく別系統なので、本記事では扱いません。

• ウイルス対策ソフトの誤検知（exe が黙って消える・隔離される）→ 親記事 6.2
• 実行制御・SmartScreen によるブロック（起動そのものが止められる）→ 情報システム部門への申請と例外登録の実務は親記事 6.2。署名で何が解決して何が解決しないのかは Python アプリ（exe）のコード署名 完全ガイド（2026 年 12 月公開）で、署名前後の実測で切り分けています

見分け方は単純です。exe がフォルダから消えていれば誤検知、exe はあるのに起動時にメッセージが出るなら実行制御。この 1 点だけ確認して、それぞれの記事へ進んでください。

9. 配布前の 5 分チェックと、事故らせない設計

ここまでの症状は、ほぼすべて配る前に 5 分かければ気付けるものです。ビルドが通ったことは、動くことの保証になりません。

1. 別のフォルダにコピーして起動する。dist の中で動かしてはいけません。C:\test\ のような無関係な場所へフォルダごとコピーして起動します。これだけで 5 章の事故と、開発機のカレントディレクトリに依存していたパス処理の両方が出ます
2. 設定ファイルを 1 つ消して起動する。落ちたときに読める形でメッセージが出るかを確認します。無言で終わるなら、それは配布先で必ず「何も起きない」と言われる作りです
3. ログが残ることを確認する。.bat ランチャー（2.2）か logging（ロギング設計）のどちらかで、起動と終了が必ずファイルに残る状態にします
4. バージョン番号を画面かログに出す。「動かない」の原因の何割かは古い exe が残っていることです。相手にバージョンを聞ければ即座に切り分けられます
5. ネットワークドライブ・ユーザー名に日本語が入るパスでも起動するか見る。共有フォルダから直接起動される運用なら必須です

もう一段先の設計としては、そもそも exe をユーザーに直接ダブルクリックさせない形があります。画面を持たない常駐処理なら Windows サービスとして常駐させるほうが、起動失敗の記録もサービス制御マネージャー側に残って扱いやすくなります。画面を見せるアプリなら .bat ランチャー経由が基本です。

10. よくある質問（FAQ）

開発機では動くのに配布先だけ動きません。まず何をすればいいですか？

配布先の PC で、コマンドプロンプトから exe を直接起動してください（2.1）。ダブルクリックでは窓が閉じてメッセージが読めません。開発機で再現しようとするのは後回しでかまいません。再現しないから配布先で失敗しているのであって、まず配布先から文字列を採るのが最短です。

Failed to execute script とだけ出ていて中身が分かりません。

PyInstaller 6.x のダイアログは、本文の下にトレースバックのテキストボックスがあります。当サイトの実測では、そこに例外の型と発生行まで出ていました（3.2）。まずダイアログを縦に広げるか、テキストボックスをスクロールしてみてください。それでも読めない場合は .bat でログにリダイレクトすれば同じ内容がファイルに残ります（2.2）。

配布先に Python をインストールしないと動かないのですか？

いいえ。PyInstaller の成果物には Python 本体（当サイトの実測では _internal\python312.dll）が含まれており、配布先に Python は不要です。ただしその _internal フォルダごと渡した場合に限ります。exe だけをコピーすると Python 本体を置き去りにすることになり、5 章のエラーになります。

Visual C++ 再頒布可能パッケージは、念のため入れておくべきですか？

配布先が Windows 10 / 11 なら、まず不要です。Python 3.5 以降は OS 同梱の Universal CRT ベースで、VCRUNTIME140.dll は PyInstaller が配布物に同梱します（実測で確認済み・6.3）。「念のため入れる」より先に、どの OS のどのビルドで落ちているのかを確認してください。Windows 7 / 8.1 が相手なら、必要なのは VC++ 再頒布可能パッケージではなく Universal CRT の更新（KB2999226）です。

%TEMP% に _MEIxxxxxx というフォルダがたくさん残っています。消していいですか？

消して問題ありません。--onefile の展開先で、正常終了時には自動で消えます。残っているのは、そのとき異常終了したか強制終了された証拠です（実測では、強制終了後もフォルダが残ることを確認しました・2.4）。数が多いなら、それ自体が「このアプリは頻繁に落ちている」という情報になります。

32bit の PC に配る予定があります。何に気をつければいいですか？

32bit の Windows で動かすなら、ビルドに使う Python も 32bit にする必要があります。PyInstaller はクロスコンパイルに対応していないため、64bit の Python から 32bit の exe は作れません。逆方向（64bit の Windows で 32bit の exe を動かす）は問題ありません。なおこの検証は当サイトでは行っていません（7 章）。

11. おわりに — 検証環境と、測れなかったこと

この記事で伝えたかったことは 1 つです。「動かない」という報告のままでは何も始まらないので、まず文字列を 1 行手に入れる。そのための手段は Windows に最初から入っているものだけで足ります。逆に、文字列さえあれば 1 章の表で行き先はほぼ決まります。

そして今回の実測で最も意外だったのは、「--noconsole だと例外が見えない」が半分しか当たっていなかったことです。スクリプトが終了する未処理例外なら 6.22.2 はトレースバック付きのダイアログを出します（3.2）。本当に何も出ないのは、GUI のコールバック内で例外が捕まってプロセスが生き残るケースで、こちらはログを取る設計にしていない限り、まず表に出てきません（3.3）。ログを残す設計は、あとから足せない保険です。

検証環境: 自宅の検証機（Windows 11 Pro ビルド 26200 / Python 3.12.10・64bit / PyInstaller 6.22.2 / pefile 2024.8.26）での 2026 年 9 月 3 日時点の結果です。記事中のパス・ユーザー名は記事用に置き換え、ログの時刻は分までに丸めています。

測れていないことを明記します。①クリーンな Windows での再現は行っていません——検証機で Windows Sandbox を有効にしていないため、症状はすべて開発機上で意図的に作りました（2.6）。したがって「Python が 1 つも入っていない PC でだけ起きる問題」は本記事では検出できません。②UPX による破損は未検証——検証機に UPX を導入していないため、確認したのは PyInstaller 側の自動除外ロジックと CFG フラグの実測までです（8.1）。③32bit / 64bit の不一致は未再現——32bit の Python も 32bit の Windows も持っていないため、公式記述の引用に留めました（7 章）。④Windows 7 / 8.1 での UCRT 不足は未検証——対象 OS が手元にありません。⑤lucasg/Dependencies は実在とライセンスを確認しただけで、使用していません（6.2）。⑥Windows 11 で作った exe を Windows 10 で動かす検証はしていません——Windows 10 の実機が手元にないためで、6.4 は公式ドキュメントの記述から言える範囲に留めてあります。

ここまでの逆引きで行き先が決まらなかった場合、たいていは「まだ文字列を採れていない」か「症状の記述が曖昧なまま」のどちらかです。2.2 の .bat で採った stderr.log の中身と、配布先の Windows のバージョン（winver の表示）の 2 つが揃えば、原因を絞り込む段階に入れます。その状態でも詰まった症状があれば、お問い合わせから症状の情報として知らせてください（お問い合わせページに明記のとおり、個別の技術サポート・トラブルシューティングの代行はお受けしていません。いただいた症状についても、個別の技術回答をお約束するものではありません）。その際、ログに含まれるユーザー名・社内のパスや共有フォルダ名・装置名は伏せて（C:\work\SampleTool のように置き換えて）お送りください。記事に反映する場合も、いただいた内容をそのまま掲載することはありません。同じ症状が複数集まったものは、この記事に節を足して実測で追記します。

⚠️ 実機適用時の注意: 本記事の手順と数値は自宅検証機での確認に基づくもので、配布した exe が現場で正しく動くことを保証する仕組みではありません。実際の設備・現場 PC に適用するときは、①対象の PC とネットワークについて設備保全部門・情報システム部門の承認を得る、②稼働中の設備に繋がった PC でのアプリ入れ替えは計画停止のタイミングで行う、③調査のための再起動やプロセスの強制終了は、その PC が設備の監視・記録を担っていないことを確認してから行う、④診断用ビルド（--debug=all）は調査が終わったら必ず通常ビルドへ戻す——この 4 点が前提です。exe 化したツールは、安全インターロック・安全 PLC・法定の警報装置の代替にはなりません。適用による設備の停止・データ欠損・機会損失について、筆者・GenbaPy は責任を負いません。