公式ダウンロードページでは、2026年9月20日時点で Julia 1.13.0 が Stable として掲載されています（Julia公式ダウンロードページ）。ただし、Julia 1.13 リリース後の研究プロジェクトは、公開直後に正式環境を置き換えないでください。旧環境を保存し、独立した検証環境で主要パッケージと代表的な数値結果を確認してから、アップグレード、二重運用、保留のいずれかを決めるのが安全です。
この手順は、Juliaパッケージを保守する開発者、論文の再現性を守りたい大学院生、複数人の研究環境を管理する研究室の担当者を対象にしています。新規プロジェクトは Stable を早めに試せますが、進行中の正式課題は新しさではなく、再現可能な証拠で判断してください。
最終更新：2026年9月20日。バージョン情報は Julia公式の配布・プラットフォーム情報 と Julia 1.13のリリース告知 を確認しています。パッケージの対応状況や重要な回帰が発表された場合は、再確認が必要です。
公開当日：正式環境を止めずに事実を固定する
最初に保存するのは、Julia本体のバージョンだけではありません。Project.toml、Manifest.toml、起動スクリプト、CI設定、主要な入力データ、代表的な出力、実行時の警告とエラーログを一式で保管します。
Manifest.toml は依存関係の具体的な解決結果を記録するため、研究成果の再現に関わります。Juliaのパッケージ文書でも、プロジェクトファイルとマニフェストファイルを分けて管理する仕組みが説明されています（TOMLファイルの公式文書）。
Julia 1.13 リリース後、旧プロジェクトはアップグレードすべきですか。
論文投稿、学会提出、長時間計算の途中であれば、直ちに置き換えるべきではありません。旧環境を再現できる状態にしたうえで、新しいブランチだけを検証対象にします。新規の解析やまだ設計段階のコードなら、同じ検証手順を通過させることを条件に Stable を採用できます。
この段階では、公式発表で確認できる事実と、パッケージ保守者の告知、コミュニティ上の未確認情報を分離してください。特定のパッケージで問題が起きるという報告があっても、手元のプロジェクトで再現するまでは確定事項として扱わないことが重要です。
注意：正式環境の
Project.tomlやManifest.tomlを先に更新すると、問題発生時に「Julia本体の変更」と「依存パッケージの再解決」を切り分けにくくなります。最初の作業は更新ではなく、復元可能な記録の作成です。
第一段階：1時間以内に独立した検証環境を作る
公式の juliaup、またはJulia公式バイナリを使い、既存の実行環境とは別のバージョンとして Julia 1.13 を登録します。公式の手動ダウンロードページには、Stable、LTS、旧版、対応プラットフォームへの導線がまとめられています（公式の手動ダウンロード情報）。
記録すべき項目は次のとおりです。
- インストールに使った方法と取得元を記録します。
julia --versionの結果を保存します。Pkg.status()でプロジェクトと依存パッケージを確認します。- パッケージ解決にかかった時間と警告をログへ出力します。
- 旧環境へ戻すコマンドと、作業担当者を保守記録に残します。
Apple Silicon のMacを使う場合は、対応するプラットフォーム用の公式案内を確認し、Intel向けの実行経路と混同しないようにします。Apple Siliconで動いたことだけでは、Intel環境やLinux環境でも同じ結果になる証拠にはなりません。
Julia 1.13 のパッケージ互換性は、どのように確認しますか。
まず対象パッケージの Project.toml にある互換性指定を確認し、次に独立環境で依存関係を解決します。Juliaのパッケージ互換性に関する公式文書は、許容するバージョン範囲を調べる出発点になります（パッケージ互換性の公式文書）。
ただし、互換性指定を満たしていても、研究コードの出力が同一になるとは限りません。パッケージが読み込めること、主要関数が実行できること、数値結果と図表が許容範囲に収まることを別々に判定してください。
第一日：代表ケースで数値回帰を確認する
プロジェクト全体をいきなり回すのではなく、研究上の判断に直結する最小ケースを選びます。たとえば、代表的な入力データ、主要モデル、境界条件、収束判定、最終表、重要な図を一つの再現手順にまとめます。
比較対象は「最後まで実行できたか」だけでは不十分です。次の観点を旧環境と Julia 1.13 の双方で確認します。
- 推定値、誤差、収束状態が許容範囲にあるか
- 欠損値、例外、警告の扱いが変わっていないか
- 表の行列、図の軸、凡例、単位が変わっていないか
- 乱数を使う処理で、固定したシードの扱いを確認できるか
- ログに新しい非推奨警告や依存関係の警告が出ていないか
Juliaの新しいバージョンで数値結果が変わっていないか、どう検証しますか。
旧環境の出力を正解データとして上書きせずに保存し、Julia 1.13 側の出力を別名で生成して比較します。完全一致を要求する項目と、浮動小数点の丸め誤差を許容する項目を、研究室内で先に決めておく必要があります。
「コードがエラーなく終わった」という判定と、「論文の結論を再現できた」という判定は分けて記録してください。後者を確認できなければ、正式採用ではなく追加調査または二重運用に戻します。
Apple Siliconを含む実行経路を比較する
Apple Silicon を対象にする場合、CPUの種類だけでなく、ネイティブ実行か互換レイヤー経由か、依存するバイナリ成果物が取得できるか、外部コマンドのパスが一致するかを確認します。Juliaのプラットフォーム情報は、対応する配布経路を調べる際の基準になります（Julia公式プラットフォーム情報）。
Macがない場合、Julia 1.13のApple Silicon環境をどう確認しますか。
手元にMacがなければ、実機を用意するまで判断を保留するのではなく、隔離されたリモートMacでインストール、パッケージ復元、代表ケースの実行、ログ回収を行います。ただし、リモート環境で確認できるのは登録した構成と手順の再現性であり、研究室の全端末で同じ結果になることを保証するものではありません。
SSH、VNC、ブラウザ操作のどれを使う場合でも、研究データを置く場所、アクセス権、終了時の削除手順を先に決めてください。Macを一時的な検証環境として使う場合は、接続方法、権限、作業終了時の確認事項を事前に文書化しておくと、担当者が変わっても同じ手順を再現できます。接続前の確認項目は、Mac環境の利用前チェックのような一覧に沿って整理すると抜け漏れを抑えられます。
第一週：CI、文書、メンバーの復元手順を検査する
パッケージや研究コードの動作確認が終わったら、自動化と引き継ぎを調べます。GitHub Actionsを使っている場合は、Juliaのセットアップ方法を setup-juliaの公式リポジトリ で確認し、既存のワークフローが意図したバージョンを実際に起動しているかを確認します。
複数バージョンをCIで扱う場合は、ジョブの組み合わせ、失敗時のログ、キャッシュ、OSごとの条件分岐を確認します。GitHub Actionsのジョブ変数に関する公式説明も、バージョン別の実行条件を点検する際に役立ちます（GitHub Actionsのジョブ変数に関する説明）。
READMEには、Juliaの導入方法、環境ファイルの配置場所、パッケージ復元コマンド、代表ケースの実行方法、期待する出力、失敗時の回退方法を記載します。環境管理の操作は、Juliaパッケージ文書の手順とも照合してください（パッケージ管理の公式文書）。
結果をアップグレード、二重運用、保留に分類する
最初の1週間の判定では、単純な「成功」か「失敗」かではなく、次の比較を使います。
| 選択肢 | 主要な条件 | 適した状況 | 回退の考え方 |
|---|---|---|---|
| Julia 1.13へ移行 | 代表ケース、主要パッケージ、CI、文書が確認済み | 新規研究、締切まで余裕がある課題 | 保存済みManifestで旧環境へ戻す |
| Stableと旧環境を二重運用 | 一部パッケージや端末で確認が残る | 論文作業と新規開発を並行する場合 | 正式成果は旧環境で固定する |
| 変更を保留 | 数値差、依存関係の失敗、CI停止が解消しない | 締切直前、再現性が最優先の課題 | 原環境を変更せず、課題を記録する |
研究室としては、採用した版、保留した理由、責任者、次回の再確認日、問題のあるパッケージ名を一つの保守記録にまとめてください。LTSを長期運用の候補にするか、Stableを新規開発に使うかは、課題の期間と回退コストを基準に決めるべきです。必要なら、JuliaのMac向けStableとLTSの選び方を扱う資料も参照し、検証結果を残したうえで選択してください。
経験上、パッケージの対応待ちを無理に解消するより、旧環境を再現可能な状態で保管し、期限を決めて再確認する方が、論文の再現性と担当者の引き継ぎを守りやすくなります。
Julia 1.13 リリース後の研究プロジェクトを判断する基準
公開後の最初の週に必要なのは、性能向上を期待してすぐ移行することではありません。旧環境を固定し、独立環境を作り、Juliaパッケージの互換性、代表的な数値結果、Apple Siliconを含む実行経路、CI、文書を順番に確認することです。
研究室の既存PCだけで検証できない場合、Macを購入すると導入費用、保守、利用期間の長さが負担になる一方、一般的なクラウド仮想環境ではmacOS固有の挙動や実機に依存する確認を代替できない場合があります。短期間のApple Silicon検証や、論文作業と切り離したJulia環境の確認であれば、SSHMacのMacレンタルを使って必要な期間だけ実機へ接続する方が、購入前の判断を進めやすい選択肢です。
ただし、長期間にわたる安定した高負荷計算、物理ポートを使う装置連携、研究データを学内設備だけで管理する規定がある場合は、既存の研究室機器や学内サーバーの方が適しています。遠隔Macは、今回のような隔離検証、互換性確認、短期の再現環境として条件を明確にして使うのが現実的です。必要な期間だけのプランは SSHMacのMacレンタル案内 で確認できます。