Julia 1.13の導入先がApple Silicon Macなら、通常は公式のjuliaupを使い、課題ごとにProject.tomlとManifest.tomlを分けてください。旧プロジェクトは上書きせず、隔離したJulia 1.13環境でパッケージ、計算結果、図の生成まで回帰確認します。
この手順は、WindowsまたはLinuxしかない研究室でmacOS arm64環境を確認したい大学院生、旧Julia課題を移行する研究者、研究室向けに再現可能な計算環境を整える技術担当者に向いています。
まずバージョンと導入経路を固定します
2026年9月19日時点で、Julia 1.13.0は2026年9月9日に公開された現行安定版として扱われており、公式にはmacOS向けApple Siliconビルドがあります。最新の安定版、LTS、旧課題で固定された版、開発プレビュー版は役割が違うため、研究論文の再現性だけを理由に既存環境を即時更新してはいけません。
新規課題ならJulia 1.13とjuliaupを優先します。公式の手動ダウンロード一覧とプラットフォーム別の導入説明を確認し、配布元が不明なパッケージマネージャーから古いビルドを取得する方法は避けてください。
導入後は、次の3点を記録します。
julia --versionで実際のバージョンを確認します。which juliaで起動元のパスを確認します。juliaup statusでチャンネルと既定版を確認します。
arm64の不整合を先に切り分けます
Apple Silicon Mac本体、Julia、外部コマンド、C・Fortranライブラリの4層が同じアーキテクチャで動くとは限りません。パッケージの依存解決は成功しても、artifactや外部実行ファイルの読み込み段階で失敗することがあります。
Juliaのアーキテクチャは、バージョン情報だけで判断せず、実行ファイルの場所とプロセス情報を組み合わせて確認します。Macのシステム情報でチップを確認したうえで、Juliaの実体を調べ、外部依存のバイナリも個別に確認してください。公式のmacOS導入説明ではApple Silicon向けの導入経路が示されています。
Rosettaは標準の修復策ではありません。arm64版が存在しない古い依存だけを対象に、別の互換環境として用いるべきです。Julia本体、研究プロジェクト、外部ライブラリをすべてx86_64側へ寄せると、問題の原因が見えにくくなり、後でネイティブ環境へ戻す作業も増えます。
次のいずれかに該当したら、その場で移行を止めます。
- Juliaはarm64だが、必要な外部ライブラリだけがx86_64です。
- artifact取得後のロードでクラッシュまたはロードエラーが出ます。
- WindowsやLinuxで使っていたネイティブバイナリを、そのままMacへコピーしています。
- 同じプロジェクトが端末ごとに異なるJuliaのパスを返します。
PATHとjuliaupの衝突を安全に直します
「Juliaが見つからない」「更新したのに古い版が起動する」という症状は、JuliaそのものよりShell設定の重複で起きることがあります。まず既存のコード、データ、設定ファイルを保存し、主ディレクトリを無差別に削除して再インストールする方法は取らないでください。
調査は次の順番で進めます。
- 利用しているShellで
which juliaとjulia --versionを実行します。 juliaup statusで既定チャンネルを確認します。echo $PATHから古いJuliaのbinディレクトリを探します。- Shellの設定ファイルに重複したPATH追加がないか確認します。
- 既定チャンネルを決めてから、新しい端末で再検証します。
科研パッケージの失敗箇所を層別に調べます
パッケージが入らないとき、いきなりJuliaやMacを再インストールするのは適切ではありません。最初に出た有効なエラーを保存し、次のどの層で止まったかを分けます。
| 症状 | 主な確認対象 | 処理の優先度 | 合格条件 | 判断スコア |
|---|---|---|---|---|
| レジストリを取得できない | HTTPS、プロキシ、証明書 | 高 | 登録情報を取得できる | 5/5 |
| パッケージ本体を取得できない | パッケージサーバー、Git接続 | 高 | 依存解決が完了する | 4/5 |
| artifactを読み込めない | arm64対応、外部バイナリ | 最優先 | using後に必要機能が動く | 5/5 |
| ローカルコンパイルで失敗する | C・Fortranツールチェーン | 高 | 最小課題が再ビルドできる | 4/5 |
| 図や出力だけ失敗する | 描画バックエンド、権限、保存先 | 中 | PNGなどを指定先へ出力できる | 4/5 |
学校のファイアウォール、プロキシ、証明書方針が関係する場合は、Julia公式の接続先とHTTPS通信をネットワーク管理者へ確認してください。セキュリティ機能を無効化したり、検査を回避したりする設定は、研究データを扱う環境では採用しないでください。
最初の合格判定には、依存の軽い科研パッケージを1つ選び、空の環境で追加、読み込み、簡単なデータ処理、ファイル出力まで確認します。大規模なパッケージ群の互換性は一括で推測せず、各パッケージの公式資料を確認してください。
ProjectとManifestを課題単位で隔離します
全体環境は一時的な試用には便利ですが、論文、授業、研究室の共有課題には不向きです。課題ごとにProject.tomlとManifest.tomlを管理し、コード、入力データ、乱数種、Juliaのバージョンを同じ記録に残してください。
Pkgの環境管理資料に沿ってプロジェクトを有効化し、依存を追加します。TOMLファイルの役割は公式のTOML説明で確認できます。
旧課題をJulia 1.13へ移すときは、次のように扱います。
- 旧Project.tomlとManifest.tomlを読み取り専用で複製します。
- Julia 1.13用に別ディレクトリと環境を作成します。
- 依存を再解決し、変更されたパッケージを記録します。
- 旧版と1.13版で同じ入力、乱数種、出力形式を使います。
- 差分を確認してから、共有環境の既定版を変更します。
研究タスクを通した放行条件を決めます
REPLで足し算ができても、科研環境の移行が成功したとは言えません。最低限、端末計算、開発環境またはノートブック接続、図の表示、ファイル読み書き、長時間処理を別々に確認します。
公開データまたは脱敏済みデータを使い、次の順に記録してください。
- 新しい環境のインスタンス化時間と最初のエラー。
- 代表的な解析の初回実行結果。
- 図と表の保存結果。
- 連続処理中の接続断や端末終了後の状態。
- 旧環境との主要出力、依存状態、乱数種の差分。
判断を「継続・二系統・回退」に分けます
- 新規課題で、依存がarm64対応し、代表タスクまで通る場合は、Julia 1.13とjuliaupを標準環境にします。
- 旧課題の結果は一致するが、一部パッケージの移行確認が終わっていない場合は、旧版とJulia 1.13を二系統で保管します。
- artifact、外部ライブラリ、図の生成、長時間処理のいずれかが未確認の場合は、既存環境を変更せず回帰試験へ戻します。
- arm64版がなく、互換環境でも再現性を確認できない場合は、Rosettaを常用化せず、移行を停止してパッケージ提供元へ確認します。
- Macへ接続できず、同じデータで検証できない場合は、macOS対応済みとは判定しません。
よくある確認事項
Julia 1.13は安定版とLTSのどちらを選ぶべきですか？
新規の研究課題でApple Silicon対応を確認するなら、公式に現行安定版とされるJulia 1.13を基準にします。すでに発表済みの論文や授業資料を再現する場合は、LTSや当時のJuliaを残し、1.13を別環境で比較します。どちらを選んでも、Manifestと主要出力を保存しない運用は避けてください。
Julia 1.13でRosettaは必要ですか？
通常は必要ありません。Apple Silicon向けJuliaとarm64対応パッケージを優先し、x86_64しか提供されない外部依存があるときだけ隔離した互換環境を検討します。Rosettaを先に導入して全体を動かすと、どの依存が本当の原因か追跡しにくくなるため、架構確認を先に行います。
遠隔のApple Silicon Macで図を含むJulia処理はできますか？
可能性はありますが、Juliaの計算処理が動くことと、図形ウィンドウやノートブック表示が安定することは別に確認します。描画バックエンド、保存先の権限、接続方式、処理中の切断復帰を代表タスクで記録してください。画面表示だけで合格にせず、ファイル出力も比較対象にします。
LinuxとmacOSで同じManifestを共有できますか？
同じManifestを無条件に共有する運用は避けてください。プラットフォーム固有のartifactや外部バイナリが含まれる場合、Linuxで解決した状態がApple Siliconでそのまま利用できないことがあります。共通のProject.tomlを起点にし、必要ならJuliaバージョンとプラットフォームごとのManifestを保管してください。
どの時点でJulia 1.13への移行を中止すべきですか？
代表的な入力に対する主要出力、乱数種、図、ファイル形式、長時間処理のいずれかを比較できない状態なら、移行完了とは判定しません。arm64対応のない依存が研究上不可欠で、隔離環境でも再現できない場合は、旧環境を保存して移行を停止します。検証不足のまま共有環境を更新しないことが重要です。
最後に、LinuxやWindowsの既存環境は大量計算、既存ツール、研究室内の共有運用では有効ですが、macOS arm64固有の依存を確認できず、物理的なMacも用意できないという弱点があります。購入は長期安定運用に向く一方、短期の論文移行では初期費用、管理、保管場所が先に発生します。
Project.toml、Manifest.toml、依存一覧、代表データを整理済みなら、まず短期の遠隔Apple Silicon MacでJulia 1.13の回帰試験を行う方が、未検証のまま機器を購入するより判断材料を得やすいです。MACGPUの環境で同じ驗收表を埋め、継続利用、購入、LinuxとmacOSの二系統維持のどれが課題に合うかを決めてください。