Windowsで作ったアプリをMacで動かそうとして、起動しない、または研究データを読み込めない。 最短の対処は、macOS上でPyInstaller 6.22.3を使い、まずディレクトリ形式で依存関係とデータを確認することです。検証後に必要性を判断して、単一ファイル形式や配布方法へ進みます。PyInstallerの公式変更記録ではバージョンが6.22.3として示されています。(公式変更記録)

この記事が役立つ人：Macを使う指導教員や共同研究者にPython解析スクリプトを渡したい大学院生・博士課程の学生。 GUI、データファイル、ネイティブ依存を含むPython研究用アプリをmacOS向けにまとめたい開発者。 研究室向けに、繰り返し確認できるビルドと受け入れ手順を整えたい大学の技術支援担当者。

ビルド対象と受け渡し先の整理

PyInstallerは、別のOS向けアプリを作るクロスコンパイラーとして使うものではありません。Mac向けの成果物が必要なら、macOS環境でビルドしてください。Windows上で作った成果物を、そのままMac用アプリとして渡すことはできません。(PyInstaller公式のOS別ビルド説明)

先に決めるのは、アプリの見た目ではなく、誰に何を渡すかです。研究室内での動作確認、特定の共同研究者への受け渡し、一般ユーザー向けの公開では、必要な確認が異なります。いずれも、ビルドが完了したことだけをもって受け渡し可能と判断しないでください。

WindowsだけでMac用アプリを作れますか？ Mac向けの成果物はmacOS上でビルドします。Macが手元にない場合は、利用できるmacOS環境を確保してから作業計画を立ててください。ビルドする環境と配布先のMacで、実際の起動や入力データを確認することも必要です。

構築前のプロジェクト控え

元の研究プロジェクトを直接変更せず、コピーした作業用プロジェクトで進めます。ビルドに使うPython、PyInstaller、依存パッケージ、対象Macのアーキテクチャを記録し、再構築時に比較できる状態にしてください。PyInstallerのバージョンとコマンドも記録に含めます。

コード以外に必要なものも、先に一覧化します。設定ファイル、テンプレート、モデル、入力サンプル、参照表などが実行時に必要なら、どこから読み込む設計なのかを確認してください。プロジェクトの依存関係を再現する方法は、依存関係を整理する手順も参照し、既存環境を無断で更新しないようにします。

研究データを含める場合は、利用権限と機密性を確認します。初回の動作確認には、個人情報や未公開データを含まないサンプルを使い、データをビルド成果物やログへ混入させないようにしてください。

初回ビルドと依存ファイルの確認

まず、作業用プロジェクトの環境でPyInstallerをインストールします。公式のコマンド説明にあるように、バージョンを指定して導入し、実行も同じPython環境から行います。(PyInstaller公式のコマンドオプション)

python -m pip install pyinstaller==6.22.3
python -m PyInstaller --onedir your_script.py
your_script.pyは実際の起動スクリプト名に置き換えてください。GUIアプリでは、起動時のコンソール表示を変える設定が必要になることがありますが、まずはエラーを確認できる形でビルドするほうが切り分けやすくなります。利用するオプションは[公式の使用方法](https://pyinstaller.org/en/stable/usage.html)で確認してください。

最初に選ぶディレクトリ形式（--onedir）は、実行ファイルと関連ファイルの配置を点検しやすい形式です。起動できない場合、エラーと成果物の内容を照らし合わせ、不足するモジュールや動的ライブラリ、データファイルを個別に調査します。PyInstallerのspecファイルでは、追加データなどのビルド設定を記述できます。(specファイルの公式説明)

パッケージ化後に研究データや設定ファイルが見つからない場合は？ 実行ファイルの場所と、データを置いた場所を分けて調べます。PyInstallerへ追加データを渡す設定だけでなく、アプリ側が実行時にどのパスを参照するかも確認してください。データを成果物に含める場合は、specファイルの設定を見直し、必要なファイルがビルド後の構成に含まれているかを確認します。(PyInstaller公式のデータファイル設定)

起動できたかどうかだけでは、依存関係の確認は終わりません。入力ファイルを読み込み、想定した場所へ結果を書き出すところまで、代表的なケースで確かめてください。

GUIと解析結果の初回確認

ビルドしたアプリは、ターミナルからの起動だけでなくFinderからも起動します。GUIの表示、ボタン操作、ファイル選択、設定ファイルの読み込み、結果の保存先を順に確認し、実験手順で利用する操作が抜けていないかを記録してください。

既知の入力サンプルを使い、元のPythonプロジェクトとパッケージ化したアプリで、重要な出力が一致するかを比較します。出力ファイルだけでなく、読み込んだデータ、設定値、ログも照合し、パッケージ化に伴う問題と解析ロジック自体の誤りを混同しないようにします。PyInstallerのhookは、パッケージ化時にモジュールの依存情報を補う仕組みです。不足するモジュールが見つかったら、公式hookの説明を確認し、原因を記録してから修正してください。

受け渡し方法の選択

<
方式・目的合う場面注意点判断
ディレクトリ形式（--onedir）初回検証、研究室内の動作確認関連ファイルをまとめて渡す必要があります依存関係の点検を優先するなら適合度：高
単一ファイル形式（--onefile）受け取り側の操作を簡潔にしたい場合内部リソースの扱いと起動時の挙動を再確認します受け渡しの簡便さが必要なら検討
公開配布不特定の利用者へ提供する場合署名、公証など配布経路に応じた確認が必要ですビルド検証とは別工程
**onedirとonefileは、どちらを選ぶべきですか？** 依存関係やデータファイルを調べている段階なら、ディレクトリ形式を選びます。受け取り側がファイル一つで扱えることを優先する場合に限り、検証済みの構成から単一ファイル形式を試してください。形式を切り替えたら、GUI操作、入力データの読み込み、結果の保存を再度確認します。単一ファイル形式では実行時に一時的な展開が行われるため、アプリが参照するファイルの置き場所も再点検します。([PyInstaller公式の動作モード説明](https://pyinstaller.org/en/stable/operating-mode.html))

次の条件で分岐すると、作業の戻り先が明確になります。

  • 依存関係やデータファイルが未確認なら、ディレクトリ形式に戻して構成を点検します。
  • 代表的な入力と出力を確認済みで、受け取り側に簡単な操作を求めるなら、単一ファイル形式を候補にします。
  • 研究室内だけで使うなら、内部利用の条件に合わせて確認します。一般公開するなら、署名・公証・配布経路を別途確認してから公開判断へ進みます。

再現性と配布の最終確認

受け入れ確認は、次の段階に分けます。アプリが起動すること、研究結果が再現できること、外部利用者へ配布できることは、それぞれ別の判定です。別のプロジェクトコピー、または実際の受け取り手が使うMacアカウントから起動し、代表的な解析、結果ファイル、ログを確認してください。

Macアプリの署名や公証は必要ですか？ すべての内部テストに同じ配布要件が適用されるわけではありません。公開先と配布方法に応じて、Appleが示す署名、公証、配布の条件を確認してください。公開配布では、内部で起動したという確認だけで要件を満たしたとは判断できません。(AppleのmacOSソフトウェア配布ガイド)

最終記録には、ビルド環境、依存パッケージ、コマンド、入力サンプル、期待する出力、実際の確認結果を残します。トラブルが起きたときに、同じ条件で再実行できない記録では原因を追いにくいためです。macOSアプリの署名や公証を含む公開手順を進める場合は、Macの利用方法と作業環境も確認し、ビルド環境と配布先の条件を混同しないようにしてください。

WindowsやLinuxだけで作業を続けると、Mac向け成果物そのものを作れず、研究室の共用Macに頼る場合も環境や利用時間を確保しにくくなります。一方、Macを購入すれば初期費用に加え、管理や保守も必要です。短期間の構築や受け取り側での再確認だけが目的なら、MACGPUのリモートMacを利用する方法もあります。利用前に、必要なmacOS環境、アクセス方法、研究データを持ち込めるかを確認してください。継続的な高負荷処理や物理接続が必要な場合は、レンタルではなく研究室の常設設備が適することもあります。