💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — Fortranは死んだ、Fortran万歳

2026年にもFortranを扱うと言えば、二つの反応が返る。第一、「なぜ?」第二、「まだ生きているのか?」どちらも誤った問いだ。正しい問いはこうだ。**「なぜFortranは1957年から70年経っても消えないのか?」**

答えはシンプルだ。科学計算の核心は配列演算であり、配列演算をFortranより上手にやる言語はまだない。コンパイラは70年分の最適化技術を積み、BLAS・LAPACK・ScaLAPACK・PETScはFortranで書かれ、ECMWFのIFS、NCARのCESM、日本RIKENのNICAM、CMIP6のすべての気候モデルは今もFortranで動く。Top500スーパーコンピュータの半分はFortranコンパイル優先サポートだ。

しかし2026年の科学計算風景はFortran単独ではない。PythonのNumPy/SciPy/Pandas/Polarsがデータ分析標準になり、Julia 1.11は動的言語としてFortranに近い性能を出す。JAXは自動微分とXLAでMLと科学計算の境界をぼかし、MojoはPython構文でSIMD/GPUを狙う。APL一族 — J、K、BQN、Uiua — は配列思考の極を示す。

この記事はその地形全体を整理する。Fortran 2023標準の新しさ、コンパイラ8種(gfortran/LFortran/Flang/NVIDIA HPC/ifx/AOCC/XLF/Cray)、HPC並列化(OpenMP/MPI/CAF/DO CONCURRENT)、気候・工学モデルコードベース、Python・Julia・R・MATLAB生態系、APL一族、GPUと量子、スーパーコンピュータ(富岳/Nurion/Frontier)、データ形式(HDF5/NetCDF/FITS)まで — 一編が終わると2026年科学計算の地図が手元に揃う。

第1章 · Fortranはなぜ死なないか — 70年分の慣性の正体

まず最もよく聞く誤解を整理しよう。

**「Fortranは老人用言語だ。」** 半分正しく半分間違いだ。Fortranコードを書く人の平均年齢は高い。しかし*コード自体*は老けていない。2023年12月にISO/IEC 1539:2023(Fortran 2023)が発表され、2018・2008・2003・95標準が順にOOP・コアアレイ・サブモジュール・同時実行を持ち込んだ。2026年のFortranは1990年のFortranとは別言語だ。

**「Pythonが全部置き換えた。」** Pythonは*言語*レベルではそうだ。しかしPythonのNumPy/SciPy内部はCとFortran(LAPACK)で書かれている。したがって「PythonがFortranを殺した」ではなく「PythonがFortranを*フロントエンドなしで使う方法*を教えてくれた」が正確だ。

**「新規プロジェクトはすべてJulia/JAXで始まる。」** 新しい科学MLプロジェクトはそうだ。しかしNCAR、ECMWF、NASA、JAXA、KMA、NOAAが運用する*プロダクション*気候モデルは100万行単位のFortranだ。これを新言語で書き直す資源は誰にもない。

Fortranが消えない本当の理由は三つだ。

1. **配列語彙。** `A(:,2:N) = B(:,1:N-1) + C(:,1:N-1)`一行が明示的ループ + コンパイラ自動ベクトル化に解ける。NumPyが真似るその語彙の原典だ。

2. **数値精度とABI安定性。** Fortran標準はIEEE 754浮動小数点、コンパイラ間呼び出し規約、モジュールインタフェースを釘付けにした。2003年のFortranコードが2026年コンパイラで*そのまま*動く。

3. **HPCライブラリ資産。** BLAS(1979)、LAPACK(1992)、ScaLAPACK、FFTW、PETSc、Trilinos — 数十万関数がFortran呼び出し規約を前提に書かれた。これを捨てるコストは天文学的だ。

だからFortranを*学ぶ*人より、Fortran*呼び出し方*を学ぶ人の方がはるかに多い。NumPyユーザーはLAPACKを呼ぶ計算であり、JAXはLAPACKをBLAS経由でXLAが再コンパイルする。Fortranは直接書く言語から*基盤岩*へ移った。

第2章 · Fortran標準進化 — 77, 90, 95, 2003, 2008, 2018, 2023

標準の流れを一目で見よう。

1957 FORTRAN I IBM 704, John Backus, コンパイラの始まり

1966 FORTRAN 66 初のANSI標準

1978 FORTRAN 77 構造化IF/DO, CHARACTER型

1991 Fortran 90 自由形式, 配列表記, モジュール, 動的割当

1997 Fortran 95 FORALL, WHERE, PURE

2004 Fortran 2003 OOP, C相互運用, 手続きポインタ

2010 Fortran 2008 CoArrays, submodule, DO CONCURRENT, BLOCK

2018 Fortran 2018 チーム, イベント, 追加CAF機能

2023 Fortran 2023 CONDITIONAL式, $トークン, 追加配列演算

中核の分岐点は1991年のFortran 90だ。FORTRAN 77までが「旧Fortran」で、Fortran 90以降が「モダンFortran」だ。自由形式ソース、モジュール、配列スライス、動的割当が入ったことで、C++やPython並みの抽象化が可能になった。

Fortran 2003はOOPを持ち込んだ。`type, extends :: shape`クラス継承、抽象インタフェース、多態、型束縛手続き(type-bound procedure)が正式標準になった。ISO_C_BINDINGが入りCライブラリ呼び出しが標準化された。

Fortran 2008は並列を持ち込んだ。CoArrays(`real :: x[*]`)で多ノードデータ共有、DO CONCURRENTで安全並列ループ、submoduleでコンパイル単位分離が可能になった。

Fortran 2023の新機能は小さいが象徴的だ。条件式`merge`より直感的な`if (cond) then val1 else val2`、`$`トークン、強化された配列演算。モダンFortranはもはや90年代言語ではない。

第3章 · Fortranコンパイラ8種 — 2026年ラインナップ

Fortranコンパイラは多様だが、2026年に実際に使われるのは8種だ。

| コンパイラ | ライセンス | 強み | 弱み |

| --- | --- | --- | --- |

**gfortran**はGCCの一部で14.xが2025年5月にリリースされた。Fortran 2008のほぼ全てとFortran 2018の相当部分、Fortran 2023の一部をサポートする。学術・研究環境では事実上のデフォルトだ。

**LFortran 0.50**(2025年)は最も興味深い新参だ。2022年にOndrej CertikがMITライセンスで始めたコンパイラで、**対話モード**がある。`lfortran`コマンドでREPLを起動し、一行ずつFortranを実行できる — Pythonのような体験をFortranで。バックエンドはLLVM、C、x86、WASMの多重サポート。ASR(Abstract Semantic Representation)中間表現が清潔で、他のツールの基盤になりやすい。

**Flang (LLVM)**はLLVMプロジェクトのFortranフロントエンドだ。以前のPGIベース「Classic Flang」は2023年に廃止され、現在は「F18」から始まった新Flangが LLVM 18+本流に入っている。2025年から本格的な運用段階で使われる。

**NVIDIA HPCコンパイラ**はPGIを買収して作ったもので、**CUDA Fortran**と**OpenACC**の事実上の標準実装だ。GPUに直接コードを載せるなら、事実上これを使う。`nvfortran`コマンドで呼ぶ。

**Intel ifx**は旧ifortの後継で、LLVMベースだ。2024年からifortは非使用推奨に転換され、ifxが標準になった。Intel CPUのAVX-512のようなSIMD命令で最高性能を出す。oneAPIパッケージに含まれるので無料だ。

**AMD AOCC**はLLVM Flangをベースに、AMD Zenアーキテクチャに最適化したビルドだ。EPYCサーバーでgfortranより5–15%速い場合がしばしばある。

**IBM XLF**はPOWERシステムとz/OSの標準Fortranコンパイラで、商用ライセンスだ。金融・気候モデルの一部がここに結びついている。

**Cray Fortran(CCE)**はHPE Cray EXシステム — Frontier、Aurora、El Capitanのようなエクサスケールスーパーコンピュータ — の最適コンパイラだ。これなしではTop500首位マシンで最大性能を出せない。

第4章 · LFortranを深く見る — FortranのIPython的瞬間

LFortranは2026年時点で最も興味深いFortranプロジェクトだ。なぜか?

第一、**対話REPL**。70年間Fortranはコンパイル-実行サイクルを強制してきた。LFortranはそれを破る。

$ lfortran

LFortran 0.50.0

>>> integer :: i, n

>>> n = 10

>>> do i = 1, n

... print *, i*i

... end do

100

Jupyterカーネルもある。Fortranノートブックが可能になった。教育現場が爆発的に反応した理由だ。

第二、**モジュール式アーキテクチャ**。LFortranはフロントエンド(パーサ・AST)とバックエンド(LLVM・C・x86・WASM)が綺麗に分離されている。ASR(Abstract Semantic Representation)という中間表現で全バックエンドを統一する。他のツールがASRを読んでFortranコード分析・変換ができる。

第三、**WebAssembly出力**。`lfortran --backend=wasm`で.wasmバイナリが出る。ブラウザでFortranを動かせる — 教育と展示に大きな意味だ。

第四、**MITライセンス**。gfortran(GPL)と違いLFortranは商用利用・統合に自由だ。組み込みシステムやクラウドサービスがFortranコンパイラを組み込むのに適している。

ただし限界も明確だ。2026年5月時点でLFortranはFortran 90の一部、2008の一部しか実装していない。CoArray、OpenMP、OpenACCは未完成だ。実際のHPCコードをコンパイルするには時期尚早だ。しかし半年ごとに大きな進展を見せているため、2027年頃には運用環境で使えるレベルになる可能性が高い。

第5章 · fpm — FortranのCargo / pip

Fortranの最も弱い環はビルドシステムだった。C++にCMake・Conan、RustにCargo、Pythonにpipがある間、FortranはMakefile + autoconf時代に留まった。

**fpm(Fortran Package Manager)**がそれを変えた。2020年にfortran-lang.orgコミュニティが始め、2024年に1.0が出た。

fpm.toml

name = "my_project"

version = "0.1.0"

[dependencies]

stdlib = { git = "https://github.com/fortran-lang/stdlib" }

fftpack = { git = "https://github.com/fortran-lang/fftpack" }

[[executable]]

name = "myapp"

source-dir = "app"

main = "main.f90"

$ fpm build

$ fpm run

$ fpm test

$ fpm install

Cargoとほぼ同じ体験だ。依存関係はGit URLで取得、ビルドは自動並列、テストフレームワーク統合、パッケージインデックス(fpm-registry)まで備わっている。

fpmのおかげでFortranライブラリ生態系が再び息を吹き返した。**fortran-lang/stdlib**(標準ライブラリ)、**fortran-lang/fftpack**、**fortran-lang/fortuno**(テスト)、**awvwgk/json-fortran**、**jacobwilliams/json-fortran**、**certik/fastGPT**のような活発なプロジェクトがfpmベースで育っている。

第6章 · OpenMP · MPI · CoArray · DO CONCURRENT — Fortran並列4種

Fortranの真の強みは並列性だ。4つのモデルをどう選ぶか。

+----------------------------------------------------------------+

| Fortran 並列化 4モデル |

| |

| OpenMP 単一ノード, 多重スレッド, 共有メモリ |

| !$omp parallel do |

| |

| MPI 多重ノード, メッセージ送信, 分散メモリ |

| call MPI_Send / MPI_Recv |

| |

| CoArray (CAF) 分散だがFortran構文で表現 |

| a[5] = a[3] + b[1] |

| |

| DO CONCURRENT コンパイラが自動並列化する安全ループ |

| do concurrent (i=1:N) |

+----------------------------------------------------------------+

**OpenMP 5.2**(2021)は単一ノード多重スレッドモデルだ。指示文(directive)一行でループを並列化する。

!$omp parallel do reduction(+:s)

do i = 1, N

s = s + a(i) * b(i)

end do

!$omp end parallel do

最も簡単で最も広く使われる。gfortran、ifx、NVIDIA HPCのすべてがOpenMP 5.xをサポートする。OpenMP 5.2はGPUオフローディングも標準化した — `!$omp target`指示文でCUDA/HIP/SYCLなしにGPUにコードを載せられる。

**MPI 4.1**(2023)は多重ノードメッセージ送信標準だ。スーパーコンピュータの標準通信方式だ。OpenMPI、MPICH、Intel MPI、Cray MPICHなど実装は多様。MPI 4.1は部分データタイプ、永続コレクティブ、セッションモデルを持ち込んだ。

**CoArray Fortran(CAF)**はFortran 2008に入った標準分散モデルだ。別のライブラリ呼び出しなしに*言語構文*で多重ノードデータ共有を表現する。

real :: a(100)[*] ! 全イメージがa(100)を持つ

a(:) = a(:)[3] ! イメージ3のaを自分のaにコピー

sync all ! 全イメージ同期

CAFは学習曲線が最も急だが最も優雅だ。OpenCoArraysはGFortran/gcc上でCAFをMPIで実装するライブラリだ。

**DO CONCURRENT**(Fortran 2008)はコンパイラが自動並列化する安全ループだ。

do concurrent (i = 1:N) local(tmp)

tmp = a(i)**2

b(i) = tmp + c(i)

end do

ループ反復間に依存性がないことを*言語が保証*するので、コンパイラは自由にベクトル化・スレッド化・GPUオフロードできる。NVIDIA nvfortranはDO CONCURRENTを自動的にGPUに載せる — OpenMPやOpenACC指示文なしに。

第7章 · BLAS · LAPACK · PETSc — HPCライブラリ生態系

Fortranを直接書かなくてもBLASとLAPACKはほぼ皆が使う。NumPy、MATLAB、R、Julia、Octave、SciPy — すべてLAPACK呼び出しが核だ。

+----------------------------------------------------------------+

| HPC 数値ライブラリスタック |

| |

| +------------------------------------------+ |

| | アプリ層: SciPy, NumPy, MATLAB, Julia, R | |

| +------------------------------------------+ |

| | LAPACK (1992) — 線形代数 (行列ソルバー) | |

| +------------------------------------------+ |

| | BLAS (1979) — ベクトル/行列の原始演算 | |

| +------------------------------------------+ |

| | ScaLAPACK/PETSc — 分散メモリ拡張 | |

| +------------------------------------------+ |

+----------------------------------------------------------------+

**BLAS(Basic Linear Algebra Subprograms)**は1979年に始まった標準インタフェースだ。Level 1(ベクトル-ベクトル)、Level 2(行列-ベクトル)、Level 3(行列-行列)の三段階に分かれる。Level 3が最も重要だ — `gemm`(general matrix multiply)一関数がスーパーコンピュータ性能測定の標準ベンチマークになった。

実装は多様だ。**OpenBLAS**(オープン、最も人気)、**Intel MKL**(Intel CPU最適、無料利用)、**AMD AOCL**(AMD最適)、**BLIS**(研究用、モジュール式)、**Apple Accelerate**(Mシリーズ)、**NVIDIA cuBLAS**(GPU)。

**LAPACK**はBLASの上で線形代数アルゴリズムを実装する。LU分解、QR分解、SVD、固有値 — ほぼ全ての行列問題がLAPACK呼び出し一つに溶ける。35万行のFortranで、1992年初版から30年以上磨かれてきた。

**ScaLAPACK**はLAPACKの分散メモリ版だ。MPI上で動作し、スーパーコンピュータで数十万コアによる行列分解を行う。

**PETSc(Portable Extensible Toolkit for Scientific Computation)**はArgonne National LabによるPDEソルバーライブラリだ。疎行列、非線形ソルバー、時間積分、メッシュ管理を統合する。FortranとC両方から呼べ、大規模シミュレーション(流体、電磁気、量子化学)のバックボーンだ。

**Trilinos**はSandia National LabのPETSc代替だ。よりモジュール式でC++ベースだが、Fortran互換インタフェースを提供する。

**FFTW(Fastest Fourier Transform in the West)**はMITのFFTライブラリで、自己調整アルゴリズムでハードウェアに合った最適コードを実行時生成する。信号処理、天体物理、量子力学で必須。

第8章 · 気候モデル — NEMO, CESM, ECMWF IFS, CMIP6

Fortranの真の王国は気候モデルだ。CMIP6(Coupled Model Intercomparison Project Phase 6)に登録された30+気候モデルのほぼ全てがFortranで書かれている。

| モデル | 機関 | コード規模 | 主コンパイラ |

| --- | --- | --- | --- |

| KIM | 韓国KMA | 40万行 | Intel |

**NEMO(Nucleus for European Modelling of the Ocean)**はヨーロッパの海洋シミュレーション標準だ。50万行のFortran 90+、MPIで分散、OpenMPでノード内並列。衛星観測とデータ同化を通じてリアルタイム海洋状態を再現する。

**CESM(Community Earth System Model)**はNCARの総合地球システムモデルだ。大気(CAM)、海洋(POP)、海氷(CICE)、陸地(CLM)、結合器(CPL)で構成され、150万行を超える。CMIP6米国側貢献の中心だ。

**ECMWF IFS(Integrated Forecasting System)**は世界で最も正確なグローバル気象予報モデルだ。200万行のFortran、8000+モジュール、Crayスーパーコンピュータで毎日4回予報を出す。2026年時点IFS 49R3が正式運用版だ。

**NICAM(Nonhydrostatic ICosahedral Atmospheric Model)**はRIKEN(日本)の正20面体格子大気モデルだ。富岳スーパーコンピュータで3.5km解像度グローバルシミュレーションを回す。日本のスーパーコンピュータ活用戦略の象徴だ。

こうしたコードをPythonやJuliaで書き直すのは非現実的だ。検証・認証・運用安定性に30年以上が入っている。新言語で部分モジュールを追加する試みはあるが、コア力学カーネルはFortranに残る。

第9章 · Python科学スタック — NumPy / SciPy / Pandas / Polars

Fortranが*基盤*なら、Pythonは*フロントエンド*だ。2026年科学計算ワークフローの事実上の標準入口はPythonだ。

**NumPy 2.x**(2024年2.0、2026年2.3)は多次元配列の事実上の標準だ。内部的にLAPACK・BLASを呼び、ndarray一オブジェクトに数十年分の最適化が入っている。2.0で大きなAPI整理があり(string dtype, scalar promotion変更)、2.3でGPUバックエンド統合が進行中だ。

**SciPy 1.16**(2026)はNumPyの上で科学計算関数を提供する。積分、ODE、最適化、信号処理、統計、疎行列、補間 — ほぼすべての科学計算領域をカバーする。内部はFortran(LAPACK、ODEPACK、MINPACK、FFTPACK)とCで書かれている。

**Pandas 2.x**(2024年2.0、2026年2.4)はデータフレーム標準だ。2.0でPyArrowをバックエンドに採用し、性能とメモリ効率が大きく改善した。時系列・カテゴリ・欠損値処理でRのdata.frameを上回る水準になった。

**Polars 1.x**(2024年1.0)はRustで書いたPandas代替だ。列指向メモリ、lazy評価、自動並列、Apache Arrowネイティブ。大規模データセットでPandasより5~50倍速い。2026年1.20台 — Pandas互換APIとGPUバックエンド(cuDF統合)が安定化した。

**NetworkX**(グラフ)、**scikit-learn**(ML)、**statsmodels**(統計)、**xarray**(ラベル付N次元配列、NetCDF親和)、**Dask**(分散NumPy/Pandas)がその上に積まれる。

第10章 · JAX · Equinox · Flax — 自動微分時代の科学計算

**JAX**(Google, 2018)はNumPyのAPIをそのままに、自動微分とXLAコンパイルを加えたライブラリだ。2026年JAX 0.5/1.0が正式安定化段階に入った。

from jax import grad, jit

def loss(x):

return jnp.sum(jnp.sin(x)**2)

grad_loss = jit(grad(loss))

g = grad_loss(jnp.array([1.0, 2.0, 3.0]))

中核機能は4つの変換だ。

1. `grad` — 自動微分

2. `jit` — XLAコンパイル

3. `vmap` — 自動ベクトル化

4. `pmap` — 自動分散

`@jit`でデコレートされた関数はXLAがコンパイルし、GPU/TPUでそのまま動く。NumPyコード一行も変えずに100倍速くなる体験を与える。

**Equinox**(Google DeepMind出身、2022)はJAXにPyTorchスタイルのモデル定義を加える。

**Flax**(Google, 2020)はJAXの代表的NNフレームワークだ。NNモデル、学習ループ、チェックポイント、分散を標準化する。

JAX生態系はMLを超えて科学計算へ広がる。**JAX-FEM**(有限要素)、**JAX-CFD**(流体)、**JAX-MD**(分子動力学)が活発な例だ。自動微分がPDEソルバーと結合すると*逆設計最適化*が自然になる — 入力形状を微分して所望の出力を出す形状を見つける。

第11章 · Numba · Cython · PyPy · Mojo — Python加速化4種

Pythonの弱点はインタプリタ速度だ。これを補う4つのアプローチ。

**Numba**(Anaconda, 2012)はLLVMベースJITだ。デコレータ一つでPython関数がCレベル速度で動く。

from numba import njit

@njit

def sum_loop(n):

s = 0.0

for i in range(n):

s += i**2

return s

NumPyとよく合い、CUDAバックエンドもある。MLより科学計算・シミュレーションでよく使われる。

**Cython**(2007)はPythonとCの中間言語だ。.pyxファイルに型注釈を加えるとコンパイルされた.soが出る。NumPyの一部、scikit-learnの核アルゴリズムがCythonで書かれている。

**PyPy 7.3**(2026)は別のJIT Pythonインタプリタだ。CPythonより4~10倍速いがNumPy/SciPy互換性が落ちる。純Pythonビジネスロジックに良い。

**Mojo**(Modular, 2023; Chris Lattner)はPythonのスーパーセットを自称する新言語だ。LLVMベース、SIMD/GPUネイティブ、静的型付けオプション。2025年に0.7が出て、2026年1.0が近い。Pythonコードをそのまま持ち込み、徐々に静的型を加えて加速する。野心は大きいがまだライブラリ生態系が薄い。

第12章 · Julia 1.11 — 動的+速いの約束

**Julia**(2012)は「Walks like Python, runs like C」を標語に出発した。2026年時点で1.11がLTS、1.12が安定進行中だ。

Juliaの強みは4つだ。

1. **LLVM JITコンパイル。** 動的言語なのにコンパイル言語レベルの速度が出る。

2. **多重ディスパッチ。** 関数が引数型の組み合わせごとに異なるメソッドを持つ — 科学計算に自然だ。

3. **メタプログラミング。** LispレベルのマクロでDSL作成が易しい。

4. **数学親和構文。** Unicode変数名(α、β、γ)、演算子オーバーロード。

生態系の核は**DifferentialEquations.jl** — 世界最高のODE/PDEソルバーライブラリだ。SUNDIALSと共に事実上の標準。**Flux.jl**(ML)、**MLJ.jl**(MLメタフレームワーク)、**Symbolics.jl**(象徴計算)、**Pluto.jl**(反応型ノートブック)、**Plots.jl**、**Makie.jl**(可視化)。

**SciML(Scientific Machine Learning)**はJuliaの差別化領域だ。微分方程式 + ニューラルネット = 「Universal Differential Equations」で、物理法則とデータを共に学習する。Julia 1.11がこの分野の事実上の標準だ。

ただしJuliaの市場占有はPythonよりはるかに小さい。学界採用は活発だが産業採用はまだ限定的だ。

第13章 · R 4.5 · MATLAB 2026 · Mathematica 14 — 商用陣営

オープンソースの他に商用ツールも依然として重要だ。

**R 4.5**(2026)は統計の標準言語だ。tidyverse(dplyr, ggplot2, tidyr)生態系がデータ分析ワークフローの標準になった。Posit(旧RStudio)がIDEとクラウドサービス、Quarto(多言語ノートブック)を作る。2026年R 4.5はALTREP改善、並列BLAS統合、ネイティブパイプ`|>`の安定化が核だ。

**MATLAB R2026a**(MathWorks)は工学シミュレーションの産業標準だ。Simulinkは自動車・航空・電力システム設計で事実上必須だ。2026年版はMATLAB Copilot(LLMアシスタント)、GPU Coder強化、自動ROS 2コード生成を持ち込んだ。ライセンスは高いが産業認証価値がある。

**Octave 9**(2026)はMATLABとほぼ互換のオープンソース代替だ。学習用・小規模研究では十分だが、Simulinkがないため代替不可能な領域がある。

**Wolfram Mathematica 14**(2024)は象徴計算の皇帝だ。Wolfram Languageで象徴・数値・可視化・ノートブックを統合する。LLMFunctionが正式に入りGPT/Claudeを関数のように呼ぶ。

**SageMath 10.4**(2026)はSymPy、Maxima、PARI/GP、GAPを束ねた総合オープンソースCASだ。Pythonベースなので入りやすい。

第14章 · APL一族 — 配列思考の極

**APL(A Programming Language)**はKenneth Iversonが1962年に発表した表記法に始まる言語だ。特殊文字(ρ、ι、左矢印、反転)で配列演算を表現し、「一行が一ページ」という表現が似合う。

"平均計算"

mean assignedTo curly{(plusReduce omega) divide tally omega}

mean 1 2 3 4 5

APLは死んでいない。むしろ2026年に一族が増えた。

| 変種 | 表記 | ライセンス | 強み |

| --- | --- | --- | --- |

| J | ASCII | GPL | Iverson後続, 無料 |

| BQN | Unicode | MIT | 現代化, 関数型 |

**Dyalog APL**は商用APLの事実上の標準だ。金融、保険、通信で使われる。JetBrainsスタイルのIDEサポートもある。

**J**(1990)はIversonがASCII文字で再構築したAPLだ。Unicodeキーボードなしで使える。

**K + kdb+ + q**(Kx Systems)は金融時系列DBの事実上の標準だ。qはKの上のSQLライクなクエリ言語。グローバル銀行・HFT会社のほぼ全てがkdb+を使う。ライセンスは高いが(年間数十万ドル)代替不可能だ。

**BQN(Big Question Notation)**と**Uiua**(2023)は21世紀のAPLだ。BQNは関数型パラダイムを加え、Uiuaはスタックベース(Forthライク)だ。両方とも活発なコミュニティがある。

**Co-dfns**はAPLの部分集合をGPUにコンパイルする — 配列言語の真の未来かもしれない。

配列言語の市場占有は小さいが、思想的影響は大きい。NumPyのbroadcasting、Pandasのvectorization、JAXのfunctional変換は全てAPLが1962年に示したアイデアだ。

第15章 · GPU計算 — CUDA / ROCm / oneAPI / Triton / CuPy

2026年の科学計算でGPUは選択ではなく基本だ。

**CUDA 13**(NVIDIA, 2025)はGPU計算の事実上の標準だ。CUDA C、CUDA Fortran、CUDA Python(旧cuda.core)、cuBLAS、cuDNN、cuSPARSE、cuSOLVER、cuFFTなどライブラリスタック。14年分の最適化と生態系資産がある。

**ROCm 6.x**(AMD, 2024)はAMD GPUのCUDA代替だ。HIPというCUDA類似APIでコード移植が比較的容易だ。El Capitan(LLNL, AMD MI300)スーパーコンピュータがROCmベースだ。

**oneAPI**(Intel, 2020)はSYCL標準ベースのIntel GPUプログラミング環境だ。Auroraスーパーコンピュータ(Argonne)が使う。

**Triton**(OpenAI, 2021)はGPUカーネルをPythonで書く言語だ。CUDAより抽象化が高く、PyTorchバックエンドの一部を占める。学習・研究環境で爆発的に使われる。

**CuPy**(Preferred Networks, 2017)はNumPyのCUDA代替だ。`import cupy as np`一行でNumPyコードがGPUに載る。

**OpenACC**はOpenMPのGPU親和な従兄弟だ。指示文でGPUオフロードを表現する。Fortranと最もよく合い、NVIDIA HPCコンパイラの主力だ。

GPU時代の本当の変化は*言語がGPUを隠す*ことだ。JAX、Julia、CuPyを使う人は自分が何をGPUに載せているか見なくてもコードが動く。FortranユーザーはDO CONCURRENT一行でGPUが自動で落ちる。

第16章 · スーパーコンピュータ — 富岳, Nurion, Frontier, El Capitan

**Top500**(毎年6月、11月発表)はスーパーコンピュータ順位リストだ。2026年上位マシンを見よう。

| 順位 | マシン | 機関 | 性能 (Rmax PF) | アーキテクチャ |

| --- | --- | --- | --- | --- |

| 5 | 富岳 | RIKEN (日本) | 442 | Fujitsu A64FX (ARM) |

**富岳**(2020導入、日本RIKEN)はARMベーススーパーコンピュータで、2020~2021年Top500首位だった。Fujitsu A64FXチップ(48コアARM + SVE 512bitベクトル)を158,976ノードで構成。CPUのみで1.4 ExaFLOPSを出した — GPUなしに。2026年時点で5位に下がったが依然活発に運用される。後続「富岳-NEXT」が2030年稼働を目標に設計中だ。

**Nurion**(2018、韓国KISTI)は韓国最大のスーパーコンピュータでIntel Xeon Phiベースだ。25.7 PFで導入当時Top500 11位。現在はさらに後退したが、国内の気象・バイオ・航空宇宙研究の中心だ。後続KISTI 6号機が2026年導入進行中だ。

**Frontier**(2022、ORNL)は世界初のExaFLOPSマシンだ。AMD EPYC CPUとInstinct MI250X GPUで構成。気候・核融合・材料シミュレーションの米国側拠点。

**El Capitan**(2024、LLNL)は2026年5月時点Top500 1位だ。AMD MI300A(APU — CPU + GPU統合)を採用して1.74 ExaFLOPS。核兵器シミュレーションと気候が主用途。

**Aurora**(2024、Argonne)はIntel Max GPUベースだ。AI/HPC融合ワークロードが主ターゲット。

こうしたマシンで動くコードの圧倒的多数がFortranかC++だ。スーパーコンピュータ使用時間は1時間あたり数万ドルで取引され、「1%性能向上」が莫大な価値だ。だからCray、Fujitsu、NVIDIAの専用コンパイラが生き残る。

第17章 · スーパーコンピュータ管理 — Slurm / PBS Pro / LSF / Spack

スーパーコンピュータユーザーは通常*直接*マシンを動かさない。キューシステムにジョブを提出して結果を受け取る。

**Slurm**(SchedMD, 2003)は最も広く使われるオープンソースジョブスケジューラだ。Top500の60%以上がSlurmを使う。

#!/bin/bash

#SBATCH --job-name=climate_run

#SBATCH --nodes=128

#SBATCH --ntasks-per-node=64

#SBATCH --time=24:00:00

#SBATCH --partition=large

mpirun -n 8192 ./nemo.exe

`sbatch script.sh`で提出、`squeue`でキュー確認、`scancel`でキャンセル。

**PBS Pro**(Altair)と**LSF**(IBM)は商用代替だ。古いスーパーコンピュータの多くがPBSかLSFを使う。

**Spack**(LLNL, 2013)はHPC環境のパッケージマネージャだ。apt/yumと違い、同じライブラリの複数バージョン・コンパイラ組み合わせを同時にインストールできる。

$ spack install petsc@3.19.0 +mpi ^openmpi@4.1.5 %gcc@13.2.0

PETSc 3.19、MPIバックエンド、OpenMPI 4.1.5、GCC 13.2.0でビルド。同じシステムにPETSc 3.20 / Intel MPI / ifxビルドも別途インストールできる。スーパーコンピュータ運営者に必須。

**Easybuild**(ベルギーKU Leuven)はSpackの欧州競合だ。

第18章 · 科学データ形式 — HDF5 / NetCDF / FITS / MAT

大規模な科学データはCSVやJSONでは扱えない。4つの形式が標準だ。

**HDF5(Hierarchical Data Format 5)**はNCSAが作った自己記述型バイナリ形式だ。木構造でデータセットとメタデータを保ち、圧縮、チャンク、並列I/Oをサポートする。天体物理、気候、生命科学で標準。

**NetCDF(Network Common Data Form)**はUCARが作った気候・海洋データ標準形式だ。NetCDF 4からはHDF5の上で動作する。ECMWF、NCAR、NOAAの全てのモデル出力がNetCDFだ。

**FITS(Flexible Image Transport System)**は天文学の標準形式だ。1981年に標準化され、NASA、ESA、JWSTが全てFITSでデータを配信する。

**MAT(MATLABファイル)**はMATLABのネイティブバイナリだ。v7.3からはHDF5ベースだ。SciPyの`scipy.io.loadmat`でPythonから読める。

**Apache Parquet**と**Apache Arrow**はビッグデータ陣営の標準だが、科学計算ではまだNetCDF/HDF5が優勢だ。

**Zarr**(2018)はNetCDF/HDF5のクラウド親和な代替だ。チャンクをS3オブジェクトとして分散保存して分散分析に適する。xarrayと組み合わせて使う。

第19章 · Mojo · LFortran · 次世代科学言語

2020年代後半に入り、科学計算の*次世代*言語候補が三つ登場した。

**Mojo**(Modular, 2023)はChris Lattner(LLVM/Swift創始者)が作った。Pythonスーパーセットを自称し、LLVM/MLIRベースでSIMD/GPUをネイティブサポートする。2026年1.0近接。野心は「Pythonの使いやすさ + C++の性能 + Fortranの配列演算」だ。

**LFortran**(2022)は既に第6章で見た通りFortranのIPython的瞬間だ。

**Bend**(2024)はGPU親和な関数型言語だ。CPUコードを自動的にGPU並列化する。まだ実験的だがパラダイム転換の可能性を示す。

Julia 1.xも依然候補だ。1.11/1.12でABIを固定して産業採用の最後の障壁を下げている。

このうちどれか一つがFortranを*代替*する可能性は低い。しかし*新規科学プロジェクト*のデフォルトになる可能性はある。5~10年後の風景は大きく異なるだろう。

第20章 · 量子計算と科学 — Qiskit / Cirq / PennyLane

量子コンピュータはまだNISQ(ノイズの中規模)段階だが、科学シミュレーションで意味のある結果が出ている。

**Qiskit**(IBM)はPythonベースの量子SDKだ。IBM Quantumハードウェア(127~1121キュービット)をクラウドで使う。化学シミュレーション、最適化、MLが主応用領域。

**Cirq**(Google)はSycamoreとWillow(105キュービット、2024)ハードウェアを使う。量子優位性実験のツール。

**PennyLane**(Xanadu)は量子ML特化フレームワークだ。PyTorch/JAXと統合される。

量子計算とFortranの接点は*古典シミュレータ*だ。量子回路を古典計算機でシミュレーションする際の核演算がテンソル収縮(tensor contraction)で、これは結局BLAS gemm呼び出しだ。Cray、NVIDIA、Intelの量子シミュレータバックエンドは全てBLAS/LAPACKに依存する。

このテーマは別の記事でより深く扱う。ここでは量子計算も結局*数値線形代数*の上に立つという点だけ押さえて通り過ぎる。

第21章 · 韓国・日本の科学計算 — KISTI / RIKEN / AIST

**KISTI(韓国科学技術情報研究院)**は韓国のスーパーコンピュータ運営機関だ。Nurion(5号機、25.7 PF)、Tachyon2を運営し、2026年6号機導入を進めている。韓国気象庁のKIMモデル、核融合研究院のKSTARシミュレーションがKISTIで動く。

**ソウル大スーパーコンピュータ**も別途運営される。NVIDIA DGXクラスタとInfiniBandベース。AI研究が主ワークロード。

**KAIST**、**GIST**、**UNIST**もそれぞれスーパーコンピュータ資源を運営する。

**RIKEN(理化学研究所)**は日本の代表的科学研究所だ。富岳を運営しNICAM気候モデル、MDシミュレーション、量子シミュレーションを動かす。2030年稼働目標の次世代富岳-NEXTが設計中だ。

**AIST(産業技術総合研究所)**は日本の応用科学研究機関だ。ABCI(AI Bridging Cloud Infrastructure)スーパーコンピュータを運営しAI/HPC融合ワークロードを扱う。ABCI 3.0が2024年に稼働を始めた。

**JAMSTEC(海洋研究開発機構)**は地球シミュレータを運営する。1世代(2002)、2世代(2009)、3世代(2015)、4世代(2021) — NEC SX-Aurora TSUBASAベクトルマシンで、日本のベクトル計算の伝統が生きている場所だ。

韓日両国の科学計算伝統は深い。日本のベクトル計算機伝統(地球シミュレータ、富岳)と韓国のGPU/AI転換が対照的だ。

第22章 · ノートブック環境 — Jupyter / Quarto / Marimo / Pluto

科学計算の日常ツールはノートブックだ。2026年の風景。

**Jupyter**(2014、旧IPython)は事実上の標準だ。Python/Julia/R/Fortran(LFortran)/Scalaなど40+カーネルをサポートする。JupyterLab 4.xが次世代インタフェース。

**Quarto**(Posit, 2022)はR Markdownの後継だ。Python/R/Julia/JS多言語文書をPDF/HTML/Word/EPUBで出力する。Quarto Manuscriptsは学術論文作成用。

**Marimo**(2023)は反応型Pythonノートブックだ。Pluto.jlのようにセル間依存性を自動追跡し、.pyファイルで保存される。Git diffがよく出てreproducibilityが良い。

**Pluto.jl**(2020)はJuliaの反応型ノートブックだ。セル一つを変えると依存する全てのセルが自動的に再実行される。教育と展示に強い。

**Deepnote**、**Hex**、**Noteable**はクラウドノートブックサービスだ。協業とSQL/Python統合に強み。

このテーマは別のノートブック記事でより深く扱う。

第23章 · 科学計算学習経路 — 学生 / 研究者 / 技術者

最後に誰が何を学ぶべきか整理する。

**大学生(学部)**:

1. Python + NumPy + Matplotlib(基本ツール)

2. Jupyterノートブック(作業環境)

3. Git/GitHub(協業)

4. 線形代数と数値解析(理論)

5. 関心分野に応じてR/Julia/MATLABのいずれか追加

**大学院生(修士・博士)**:

1. 学部 + SciPy + scikit-learn(応用)

2. PyTorchまたはJAX(自動微分)

3. 領域別ドメインライブラリ(例: 天体物理はAstropy)

4. HPC使用法(SLURM, Spack)

5. Fortran*読み*の能力(既存コード理解)

**気候・海洋研究者**:

1. Fortran*書き*の能力必須

2. NetCDF/HDF5/xarray

3. NEMO/CESM/IFSのような運用モデルコード理解

4. MPI/OpenMP並列化

5. Cray/Intelコンパイラ使用法

**技術者(シミュレーション)**:

1. MATLAB + Simulink(事実上の標準)

2. ANSYS/ABAQUS/COMSOL(商用ツール)

3. Python補助(データ処理)

4. 一部Fortran(レガシソルバー)

**データサイエンティスト**:

1. Python + Pandas + Polars

2. SQL熟達

3. scikit-learn → PyTorch/JAX

4. クラウドノートブック(Hex, Deepnote)

5. 統計のためにRもオプション

核は*Pythonを基本に*据え、領域に応じてFortran/Julia/R/MATLABを加えることだ。一つのツールで全てを行う時代は終わった。

第24章 · よくある質問 — Q&A

**Q. 2026年にFortranを新たに学ぶ価値はあるか?**

A. *新規プロジェクトを始める*ならJuliaかPythonの方が良い。ただし気候・高エネルギー物理・HPC研究者ならFortran*読み*は必須だ。100万行の運用モデルを理解する必要がある。

**Q. NumPy/SciPyはFortranより遅いか?**

A. 一対一の比較ではないが、NumPyの内部は結局Fortran(LAPACK)/C(BLAS)だ。ユーザーコードがNumPy関数呼び出し主体ならFortranと同程度の速度が出る。ユーザーコードがPython for-loop主体なら100倍遅くなる。Numba/Cythonでその部分を加速できる。

**Q. JuliaがFortranを代替するか?**

A. 短期にはしない。運用コード書き換えコストが大きすぎる。長期には新規プロジェクトの相当部分をJuliaが奪う可能性がある。

**Q. LFortranはいつ運用環境で使えるか?**

A. 2026年5月時点でLFortranはベータだ。早ければ2027年、遅ければ2028~2029年に運用水準になる。

**Q. Mojoはどうか?**

A. 野心は大きいがライブラリ生態系が薄い。1.0が出てもNumPy/SciPyレベルの資産を積むには5~10年要する。

**Q. APLは本当に使えるか?**

A. *金融HFT*はK/qが事実上の標準だ。その他は思想的興味の方が大きい。NumPyユーザーはAPLのメンタルモデルを習得するとNumPyコードが優雅になる。

第25章 · おわりに — Fortranの逆説と科学計算の未来

Fortranの最大の逆説はこうだ。**「最古の高水準言語が依然として最速の言語の一つだ。」**

この逆説の答えはシンプルだ。Fortranは*特定問題*(配列演算)を*最初からうまくこなす*ように設計された。70年経ってさらに良くなった。Cはシステムプログラミングをうまくこなすように設計され、Pythonは使いやすさをうまくこなすように設計された。それぞれ自分の領域で最強だ。

2026年の科学計算は*言語多様性*の時代だ。Fortranは運用モデルの基盤岩として残り、Pythonがフロントエンドを取り、Juliaが新規プロジェクトを狙い、JAXがML/科学を融合する。APLは思想として生き、MATLABは産業として生き、Rは統計として生きる。

この記事がその地形全体の地図になれたことを願う。最後に行動の推奨を。**(1)**既にツールがあるならそれをさらに深く掘れ。新ツールは慎重に追加せよ。**(2)**Python + NumPyは*共通語彙*だ。どんな領域でもこれは知るべきだ。**(3)**Fortranを*書か*なくても*読む*方法は習得せよ — 科学計算ライブラリの半分は結局Fortranで始まる。**(4)**Julia/JAX/Mojoのような新参を観察せよ。5年後に標準になるか死ぬかまだ分からない。

気候が変わり、粒子加速器が動き、スーパーコンピュータがExaFLOPSを超える。そのすべての裏でコンパイルされた配列演算が回る限り、Fortranの子供たちは働き続けるだろう。Fortranは死なない — ただ*形を変えて*生き残る。

参考資料 (References)

1. Fortran 2023標準 (ISO/IEC 1539:2023): https://www.iso.org/standard/82170.html

2. fortran-lang.orgコミュニティハブ: https://fortran-lang.org/

3. LFortranプロジェクト: https://lfortran.org/

4. gfortran (GCC): https://gcc.gnu.org/fortran/

5. LLVM Flang: https://flang.llvm.org/

6. NVIDIA HPC SDK: https://developer.nvidia.com/hpc-sdk

7. Intel ifx / oneAPI: https://www.intel.com/content/www/us/en/developer/tools/oneapi/fortran-compiler.html

8. Fortran Package Manager (fpm): https://fpm.fortran-lang.org/

9. Fortran stdlib: https://stdlib.fortran-lang.org/

10. OpenMP 5.2仕様: https://www.openmp.org/specifications/

11. MPI 4.1ドキュメント: https://www.mpi-forum.org/docs/

12. LAPACK: https://www.netlib.org/lapack/

13. BLAS: https://www.netlib.org/blas/

14. PETSc: https://petsc.org/release/

15. NumPy 2.xドキュメント: https://numpy.org/doc/stable/

16. SciPyドキュメント: https://docs.scipy.org/doc/scipy/

17. JAXドキュメント: https://docs.jax.dev/

18. Julia 1.11ドキュメント: https://docs.julialang.org/en/v1/

19. Top500 2025年11月リスト: https://top500.org/lists/top500/2025/11/

20. RIKEN富岳: https://www.r-ccs.riken.jp/en/fugaku/

21. KISTIスーパーコンピュータ: https://www.ksc.re.kr/eng

22. ECMWF IFS: https://www.ecmwf.int/en/forecasts/documentation-and-support

23. NCAR CESM: https://www.cesm.ucar.edu/

24. CMIP6: https://www.wcrp-climate.org/wgcm-cmip/wgcm-cmip6

25. APL Wiki: https://aplwiki.com/

26. Modular Mojo: https://docs.modular.com/mojo/

27. HDF5: https://www.hdfgroup.org/solutions/hdf5/

28. NetCDF: https://www.unidata.ucar.edu/software/netcdf/

最終更新: 2026-05-16。次の記事ではこの地図で触れた一つの分野 — *気候モデルコードをコードベース水準で深く見る* — を深掘りする。