013つの計算タイプを振り返る
このシリーズは、ひとつの素朴な疑問から始まった——WebGPUは本当に速いのか。答えは「計算による」だった。だがそれでは何も言っていないに等しい。そこで、計算を「質」で分類し、タイプごとに実測することにした。選んだのは3つだ。
#1 独立並列は、各スレッドが完全に独立して計算する。モンテカルロ法で1万通りの資産推移を同時にシミュレートするような計算で、GPUの最も素直な使い方だ。#2 行列演算は、出力が多数の入力に依存する。行列積や共分散行列、ポートフォリオ評価がこれにあたり、メモリの読み方が性能を左右する。#3 協調計算は、スレッド同士が結果を共有しながら進む。エージェント市場では、全員の注文を集計して価格を決め、それを全員が見て次に進む——という反復が核心だった。
この3つは、スレッド間の「依存の強さ」で並んでいる。独立（依存なし）→ 入力依存 → 相互依存。依存が強くなるほど、GPUの使い方は難しくなる。その難しさが性能にどう表れるかが、本シリーズの主題だった。
02クロスオーバーという共通構造
3タイプすべてに、ひとつの共通構造があった。規模が小さいうちはCPUが速く、ある規模を超えるとGPUが逆転する——クロスオーバーだ。
各タイプの「規模」に対するGPU高速化倍率（CPU比、対数軸）。1.0を超えるとGPUが有利。すべて右肩上がりで、どこかで1.0をまたぐ。
小規模でCPUが勝つ理由は共通している。GPUは起動・データ転送・カーネル発行にコストがかかり、計算量が小さいとこの固定費が回収できない。規模が大きくなるほど、GPUの大量の演算ユニットが活き、固定費が相対的に小さくなって逆転する。#1で「WebGPUが常に最速とは限らない」と気づいたこの構造は、結局すべてのタイプに通底していた。
03律速を決めるもの — タイプごとに違う「効くスケール」
ところが、「どの規模で逆転するか」「規模を増やすと何が起きるか」は、タイプごとにまるで違った。性能を律速する要因（ボトルネック）がタイプ固有だったからだ。
| 計算タイプ | 律速する要因 | 規模を増やすと |
|---|---|---|
| #1 独立並列 | 試行数（並列度） | GPUが並列に吸収、優位拡大 |
| #2 行列演算 | 行列サイズ・計算密度 | O(n³)でCPUが急速に重く、GPU圧勝（512で約100倍） |
| #3 協調計算 | 同期回数（ステップ数） | GPU時間ほぼ一定、エージェント数に非依存 |
特に協調計算は異質だった。エージェント数を100倍にしてもGPU時間がほぼ変わらない。律速が「並列度」ではなく「ステップごとの同期回数」だからだ。500ステップなら500回、CPUとGPUが往復する。1ステップの計算がどれだけ軽くても、この往復が積み重なる。一方の行列演算は、計算密度（1要素あたりの演算量）が高く、サイズを増やすほどGPUの並列性が効いて、CPU比100倍超に達した。同じ「規模を増やす」でも、効くスケールがタイプごとに違う。
04最適化の移植性 — どこまで通用するか
本シリーズで最も意外だったのは、最適化がどこまで他のデバイスで通用するか（移植性）が、タイプによって全く違ったことだ。これは2機種（Pixel 10 Pro と iPad mini A17 Pro）で測ったからこそ見えた。
行列演算では、最適化に移植性があった。タイル化の最適サイズ（32×32）は、Pixel でも iPad でも同じく最速だった。アーキテクチャの違うGPUでも、メモリ階層を意識した最適化は同じように効く。だから「tiled-32がよい」という知見は、デバイスを越えて通用する。
ところが協調計算では、移植性がなかった。同じコードが、iPadで8.2倍速、Pixelで1.2倍速。8倍と等速、という桁違いの差だ。鍵はCPU-GPU間の同期コスト。Apple GPUはメモリを共有する設計で往復が軽く、500回の同期を苦にしない。別アーキテクチャでは同期のたびにコストが積み上がる。計算の中身ではなく、同期の実装とハードウェアが性能を決めてしまう。
05「GPUは万能ではない」の本当の意味
シリーズを通じて繰り返してきた「GPUは万能ではない」という言葉。その中身が、3つの軸として整理できる。
| 軸 | 問い | そこから得た知見 |
|---|---|---|
| 規模 | 計算は十分に大きいか? | 小さければCPU。クロスオーバーがある（原理①） |
| 質 | 律速はどこか? | タイプ固有のボトルネックを攻める（原理②） |
| デバイス | どのGPUで動くか? | 依存が強い計算ほど左右される（原理③） |
当初は「規模」だけの話だと思っていた。小さければCPU、大きければGPU——それで十分だと。だが測り進めるうちに、「質」（律速の違い）が、そして最後に「デバイス」（移植性の違い）が立ち現れた。GPUが速いかどうかは、この3軸の交点で決まる。ひとつでも見落とすと、判断を誤る。
速さは、規模・質・デバイスの交点に宿る。
06ブラウザで動くという意味
忘れてはならないのは、これらすべてがブラウザの中で動いたことだ。専用のGPUプログラミング環境も、ドライバのインストールも、サーバーも要らない。スマートフォンやタブレットのブラウザで、行列積が100倍速くなり、5万通りのポートフォリオが一瞬で評価され、市場のバブルが創発した。
WebGPUは、かつて一部の専門家のものだったGPU計算を、Webページの一部にした。本シリーズのベンチマークやツールは、すべて単一のHTMLファイルとして配布でき、リンクを開くだけで誰のデバイスでも走る。計算結果が「読む」コンテンツから「その場で試せる」コンテンツへ変わる——その可能性こそ、WebGPUを追ってきた理由だ。
もちろん、本シリーズで見たように、ブラウザのGPU計算には固定費があり、デバイス差があり、計算の質ごとの難しさがある。万能ではない。だが「いつ・なぜ速いのか」を見極めれば、その上で十分に実用的な計算力が、手のひらの中で手に入る。
07結び — 計算の質を見極める
3つの計算タイプ、2つのデバイス、ひとつの問い。「WebGPUは速いのか」への答えは、最初に思っていたより、ずっと豊かなものだった。
速さは計算の規模で決まり、最適化は律速で決まり、移植性は計算の質で決まる。GPUを使いこなすとは、これらを見極めることだ。手元の計算がどのタイプか、ボトルネックはどこか、どのデバイスで動くのか——その問いに答えられたとき、初めてGPUは正しく速くなる。
このシリーズは、特定の答え（「GPUは速い／遅い」）を出すためではなく、正しく問う方法を見つけるためのものだった。計算の質を見極める目——それが、三部作を通じて残った、いちばんの収穫だ。
ここで使った計算エンジンは、独立並列・行列演算・協調計算を1つにまとめた共通ライブラリとして、金融教育ツール（確率的ライフプラン、ポートフォリオ最適化、市場シミュレーション）にも応用している。ベンチマークで得た知見が、そのまま実用ツールの土台になっている。技術の探究と実用が地続きであること——それもまた、このシリーズが示せたことだと思う。
