JavaとRust、いま強い領域――取引所は誰も実装言語を公開していない

ここまでの4回は、所有権、設計の語彙、メモリ、並行処理と、言語の性質そのものを見てきた。今回は視点を変えて、それが実際にどこで使われているのかを確かめる。

この種の記事にはひとつ落とし穴がある。採用事例が伝聞で流通していることだ。「あの会社は使っているらしい」という話は多いが、出どころをたどると誰かのまとめ記事に行き着く、ということが起きる。

そこで本稿は、方針をひとつに絞った。

企業や組織の名前を出すのは、その組織自身の公開資料で裏が取れる場合に限る。 ベンダーが自社サイトに掲げる顧客ロゴも、まとめ記事も、採用要件からの推測も使わない。

この方針で調べた結果、いちばん驚いたのは、書けないことのほうが多かったという事実だった。そこから始めたい。

この回で出てくる固有名詞

前回までと違い、今回はコードではなく組織とプロダクトの名前が多く出てくる。Javaの業務システムからは見えにくいものが多いので、先に並べておく。

名前	何か
arrowhead	日本取引所グループの株式売買システム。2024年11月から第四世代（4.0）
SBE	Simple Binary Encoding。注文の電文を高速に読み書きするためのバイナリ形式。仕様自体はFIX Trading Communityという業界団体の標準
Aeron	低遅延でメッセージを送受信するためのライブラリ（Java／C++）
Chronicle Queue	ディスクに書きながら低遅延で受け渡すJavaのキュー
LMAX Disruptor	スレッド間の受け渡しを高速化するJavaのライブラリ
HdrHistogram	応答時間の裾（第3回で扱ったテールレイテンシ）を精度よく記録するライブラリ
sudo-rs	sudo コマンドのRust実装
coreutils	cp・mv・rm など、OSの基本コマンド群
Ferrocene	機能安全の認証を取得したRustの商用ツールチェーン
ISO 26262 / ASIL D	自動車の機能安全規格と、その最も厳しい等級
IEC 61508 / SIL 3	産業機器の機能安全規格と、その等級
ONNX Runtime	学習済みモデルを実行するための基盤。複数言語のAPIを持つ
DJL	Deep Java Library。JavaからAIモデルを扱うライブラリ

取引所は、誰も実装言語を公開していない

低レイテンシの話題になると必ず出てくるのが取引所である。あのマッチングエンジンは何語で書かれているのか。

日本取引所グループ、CME Group、Nasdaq、Cboe、LSEG、Deutsche Börse――六つすべてを当たって、実装言語を公開している取引所はひとつもなかった。

公開されているのは一貫して外部と繋ぐ部分の仕様までである。どんなデータ形式で電文を送り、どういう手順で接続を確立するか。海外の主要取引所は仕様書を無認証で公開しており、そこは非常に開かれている。だが内部の実装言語には触れていない。

つまり、「取引所はC++で書かれている」といった記述を、取引所自身の公開資料で裏づけることはできない。 有名な例として「LSEGのシステムはC++」という話が二次記事に流通しているが、LSEG自身の公表資料では確認できなかった。誤りだと言っているのではなく、確かめる手段がないということである。

汐見レン（証券システムの低レイテンシ実装者）

この沈黙自体を「言語が本質的な差ではないことの証拠だ」と読みたくなりますが、それも推測です。単に公開する理由がないだけかもしれない。分からないことを分からないと書くのが、この回でいちばん誠実な態度だと思います。

一方で、JPXは珍しく実数値を公開している。2024年11月に稼働した第四世代システム「arrowhead4.0」について、注文応答時間 約0.2ミリ秒、情報配信時間 約0.5ミリ秒、取引情報を三重化されたサーバ上で処理する、と明記している。実装言語は書かれていないが、要求水準は読み取れる。

この0.2ミリ秒という数字の意味を、連載の中で位置づけておきたい。第3回で、100万要素を一度に捨てたときのRustの停止を実測して8ミリ秒という値を得た。その40分の1が、応答時間の予算そのものになる。 言語の実行基盤が一度まとまった後始末をするだけで、予算を使い切る水準である。

ただし両者は別々の条件で測った別々のものであり、比較ではなく桁の感覚として読んでほしい。実装言語が公開されていない以上、この水準をどの言語でどう達成しているかは分からない。

Androidが示した「第三の道」

Rustの採用事例として最も裏付けが固く、かつ日本の業務システムに示唆が大きいのがAndroidである。

Androidの公式ドキュメントは、まず現実を認めている。プラットフォームコードの70%超がメモリ安全でない言語で書かれており、それを全部Rustに書き換えるのは現実的ではない。 そのうえで、新しいネイティブのプロジェクトについてはRustが望ましい選択だと述べる。

結果は数字で公表されている。

年	メモリ安全性起因の脆弱性の割合
2019年	76%
2024年	24%（年末までの外挿値として提示）
2025年	20%未満

密度でも公表がある。Rustコードでは約0.2件／百万行に対し、C/C++では約1000件／百万行。

重要なのは、この改善が既存資産を書き換えずに起きたことである。新しく書く部分の言語を変えただけで、比率が動いた。

灰島徹（基幹系アーキテクト）

ここが業務システムに一番効く話です。「全面刷新か、現状維持か」の二択で考えていると出てこない選択肢が、公式に言語化されている。既存の資産はそのまま動かし続けて、新しく作る部分だけ別の言語にする。移行計画の書き方が変わります。

議論では、これをグリーンフィールドでも完全リライトでもない第三の形態として位置づけた（グリーンフィールドとは、既存の資産がない更地に新しく作ることを指す）。そして正直に付け加えると、確認できた一次情報の中に「既存のJavaシステムを部分的にRustへ置き換えた」事例は見つからなかった。Androidの共存戦略はC/C++からの移行の話である。ただし「確認できない」は「存在しない」ではなく、企業が移行の詳細を公開していないだけの可能性もある。

移行は進んでいる。ただし平坦ではない

Rustの採用が広がっている、という話をするときに、成功例だけ並べると嘘になる。Ubuntuの例が、そのバランスをよく示している。

進んでいる側。Ubuntu 25.10で sudo の既定実装がRust製の sudo-rs になり、2026年4月の26.04 LTSでも既定である。長期サポート版に載っているというのは、実験ではなく本番採用を意味する。ただしUbuntu自身が「完全な置き換えではない」と明記しており、対応していない機能もある。

平坦ではない側。同じUbuntuは基本コマンド群のRust実装への移行も進めているが、26.04 LTSの時点でも cp・mv・rm はGNU版のままである。理由は未解決の不具合。そして移行にあたって外部監査を入れた結果、113件の問題が見つかり、43件が脆弱性として公表された。

桐生みなも（Rustを本番運用するSRE）

113件という数字を、Rustの評判が落ちる話として読まないでほしいと思います。外部監査を入れて、見つかったものを公表して、直るまで既定を切り替えなかった。 運用側から見て評価すべきはそこです。逆に言えば、同じ手順を踏まずに言語だけ差し替えた移行は、Rustであっても信用できません。

この事実の読み方を、議論はこう整理した。

「Rustで書いたから安全」ではない。レビューと監査の必要性は、言語を変えても変わらない。

Rustが保証するのは特定のクラスの誤りであって、実装の正しさではない――第4回までに繰り返してきたことが、実際の移行の現場でそのまま現れている。

そのほか、組織自身の公開資料で確認できた事例を挙げておく。

• fish shell 4.0（2025年2月27日）：C++からRustへの全面移植を完了。200人超が2,604のコミットを重ね、5万7千行のC++が7万5千行のRustになった。ほぼ2年の作業。
• Bun（2026年7月8日）：Zigで書かれた53万5,496行をRustへ全面書き換え。動機は解放済みメモリへのアクセス、二重解放、解放漏れ。※第1回で触れたとおり、同社はAnthropicによる買収と同社モデルの使用を自己開示している。
• Linuxカーネル：対応アーキテクチャはすべて保守対象で、最低要求Rustバージョンは1.85.0。ただしこれはカーネル本体の書き直しではなく、新規ドライバなどでの言語追加である。しかも現状は安定版コンパイラを使いつつ不安定な機能に依存しており、2026年の目標が「機能フラグ無しでビルドできるようにすること」である。

認証の世界――言語は認証されない

自動車や医療機器のような、機能安全の認証が要る領域はどうか。

Rust向けの商用ツールチェーンであるFerroceneは、認証機関TÜV SÜDのもとでISO 26262 ASIL D、IEC 61508 SIL 3などを取得したと自社サイトで公表している（ベンダー自身の公表として読む必要がある）。

ただし、ここで混同してはいけない点をRustプロジェクト自身が明記している。

認証は製品とツールチェーンの単位で行われるものであり、Rust言語そのものが認証されるわけではない。

そしてもうひとつ。Rustプロジェクトには、リアルタイム性（実行時間の上限保証など）についての公式見解が存在しない。 公式に取り組んでいるのは機能安全であって、リアルタイム性ではない。機能安全とリアルタイム性は混同されやすいので、区別して覚えておく価値がある。

なお、企業名を挙げる根拠としてよく使われるものについて、注意を二つ。

• rust-lang.org の採用企業リストは、現在存在しない（該当ページは404になっている）。公式の採用企業一覧を典拠にすることはできない。
• Rust Foundationのメンバーであることは、本番採用の証明ではない。 資金拠出と製品での利用は別の話である。

AIの計算コアはRust、上流と下流はJava

第6回で詳しく扱うが、いま最も静かに、そして急速にRustが入っているのがここである。

Pythonのライブラリとして使われている道具の中身が、Rustで書かれている例が増えた。実装言語を各プロジェクトの公式リポジトリで確認できたものを挙げる。

層	Rustで実装されているもの
文章を単語や記号の並びに切り分ける	tokenizers
モデルの実行と、重みデータの読み書き	candle、safetensors
表形式のデータを列ごとにまとめて高速に処理する	Polars、arrow-rs、DataFusion
意味の近さでデータを探す（ベクタ検索）	Qdrant、LanceDB
Python自体の開発道具（検査・パッケージ管理・拡張の作成）	Ruff、uv、PyO3、maturin

いずれも「大量のデータを速く回す」層である。PythonがAPIの顔になり、計算の核をRustが担うという構造が定着しつつある。

なお本稿は、後述するJava側のツール群と同じ基準で更新状況も確認した。上記12件はいずれも2026年8月以降に更新があり、止まっているものはなかった。名前を並べるだけで健在かどうかを確かめないのは、片側にだけ甘い基準になる。

一方Java側は、AIの上流と下流で実績を持つ。Spring AIは2.0.1でGAに達し、LangChain4jは活発に開発されている（安定版のコアとベータのモジュールが併走する構造）。ONNX RuntimeのJava APIは公式サポートである。Apache Luceneのベクトル検索も使えるが、APIはexperimental扱いで最大1024次元という制限がある。DJLはリリースが2025年12月から止まっている。

Java側の実績――低レイテンシ金融の系譜

Javaが長く実績を積んできた領域として、低レイテンシの金融システムがある。ここでも一次情報の線を引いておきたい。

組織自身の公開資料で本番採用が確認できたのは、二件だけだった。

• CME Group：自社の技術Wikiで、注文接続の仕組みについてSBEというバイナリ形式を使っていると明記している。
• LMAX：自社の公式論文が「LMAXは非常に高性能な金融取引所を作るために設立された」と述べ、そのために開発した仕組みを公表している。

これ以外の「あの会社も使っている」は、ベンダー側の掲載であり、本稿の方針では採用しない。

ツール群の現況も、前節のRust側と同じ基準（最新リリースの時期）で確認した。同じ「Javaの低レイテンシ系譜」でも、活きているものと止まっているものがある。

プロジェクト	現況
Aeron	非常に活発
SBE	非常に活発（仕様自体はFIX Trading Communityの標準）
Chronicle Queue	活発
LMAX Disruptor	最新リリースが2023年9月。3年近く更新なし
HdrHistogram	2024年5月から更新停止

ひとつ訂正しておきたい点がある。Aeronを「Real LogicのAeron」と紹介するのは、現在の実態と合わない。 リポジトリは aeron-io へ移り、所有・運営はAdaptive Financial Consultingである（同社サイトによれば、開発チームは2022年に合流している）。

領域ごとの対照

確認できた事実だけで整理すると、こうなる。

領域	確認できた実績
OS・カーネル・システム基盤	Rust（ただし新規部分での追加）
コマンドライン基盤ツール	Rust（進行中。cp/mv/rmは未完）
モバイルプラットフォームの新規ネイティブコード	Rust（Androidが公式に推奨）
AI/MLの計算コア・データ処理	Rust
AIの上流データ基盤・業務システムへの統合	Java
低レイテンシ金融のミドルウェア	Java（確認できた本番採用は2件）
取引所のマッチングエンジン	不明（どこも公開していない）
既存Javaシステムの部分的なRust化	一次情報で確認できず

読者への含意――問いの立て方を変える

議論の締めくくりは、こうだった。

「どちらの言語が優れているか」を問う前に、「この仕事は何を保証すべきか」を問う。

そして、確認できた事実が示している実務的な形は、言語選択ではなく境界設計である。どの層にメモリ安全性の保証を求め、どの層でGCによる抽象化の恩恵を受けるか。Androidが公式に言語化した共存戦略――既存資産は温存し、新規部分だけ言語を変える――は、日本の業務システムにとっても現実的な形だろう。

ただし繰り返しになるが、既存Javaシステムを部分的にRust化した事例は、一次情報では確認できなかった。前例のない道を選ぶことになる、という認識は持っておいたほうがいい。

この回で断定していないこと

• 取引所の実装言語は、六つの主要取引所すべてで公開されていない。「沈黙は言語が本質でないことの証拠だ」という解釈は議論で出たが、それ自体が未検証の推論であり、本稿では採用していない。
• 既存JavaシステムのRustへの漸進的移行は、一次情報で確認できなかった。存在しないことの証明ではなく、公開されていないだけの可能性がある。
• JNIなどの言語境界を跨ぐ際の性能への影響は、具体的な数値を確認できていない。
• Androidの脆弱性比率は開発元自身の公表であり、2024年の値は年末までの外挿値として提示されている。
• Ferroceneの認証取得はベンダー自身の公表であり、認証機関発行の証明書そのものは確認していない。
• 本稿に挙げた組織以外にも採用は当然あるが、一次情報で裏が取れなかったものは意図的に省いている。網羅ではない。

梧桐（編集長・進行）

今回いちばん書きたかったのは、実は「分からなかった」ことのほうです。取引所の実装言語は誰も公開していない。既存JavaシステムのRust化の事例も見つからない。この二つを空欄のまま出すのが、埋めて格好をつけるより読者の役に立つと判断しました。次回はAIとの関係を扱いますが、そこでも同じ問題――数字で語れないことを、数字で語らない――が中心になります。

出典を読むときのポイント

• Android「メモリ安全性」：プラットフォームコードの70%超がメモリ安全でないこと、全面的な書き換えは現実的でないこと、新規ネイティブプロジェクトではRustが望ましいとする開発元の見解を確認した。
• Google Security Blog「Eliminating Memory Safety Vulnerabilities at the Source」／「Rust in Android: move fast and fix things」：脆弱性比率が2019年76%から低下したこと、2024年の値が外挿であること、Rustが約0.2件／百万行、C/C++が約1000件／百万行という密度差を確認した。いずれも開発元自身の公表である。
• Linuxカーネル「Rust アーキテクチャサポート」／Rust 2026年ロードマップ「Rust for Linux」：対応アーキテクチャが保守対象であること、最低要求バージョンが1.85.0であること、2026年目標が機能フラグ無しでのビルドであることを確認した。カーネル本体の書き直しではない点に注意。
• Ubuntu 26.04 LTS リリースノート：sudo-rs が既定であること、および cp・mv・rm がGNU版のままであることを確認した。
• Ubuntu「An update on rust-coreutils」：外部監査で113件の問題が検出され43件が脆弱性として公表されたこと、cp・mv・rm を据え置いた理由を確認した。移行の困難さを示す一次情報にあたる。
• fish shell「Fish 4.0: The Fish Of Theseus」：移植の規模（2,604コミット・200人超、5万7千行のC++が7万5千行のRustへ、ほぼ2年）をプロジェクト自身の公表として確認した。
• Bun「Rewriting Bun in Rust」：53万5,496行のZigからRustへの書き換えと、その動機を確認した。開発元による自社事例の報告である。
• Ferrocene：TÜV SÜDのもとでISO 26262 ASIL D、IEC 61508 SIL 3などを取得したというベンダー自身の公表を確認した。認証機関発行の証明書そのものは確認していない。
• Rust 2026年ロードマップ「Safety-Critical Rust」：「認証は製品とツールチェーンの単位であり、Rust言語自体が認証されるわけではない」という記述を確認した。またRustプロジェクトの公式な取り組みは機能安全であって、リアルタイム性の保証ではないことも確認した。
• 日本取引所グループ「株式売買システム」：arrowhead4.0が2024年11月に稼働したこと、注文応答時間 約0.2ミリ秒・情報配信時間 約0.5ミリ秒、三重化されたサーバで処理することを確認した。実装言語の記載はない。
• Aeron：Aeronの所有・運営がAdaptive Financial Consultingであること、開発チームが2022年に同社へ合流したことを確認した。「Real LogicのAeron」という紹介は現況と一致しない。
• rust-lang.org：トップページに社名を伴わない一般的な記述があるのみで、採用企業の一覧ページは存在しない（該当URLは404）。公式の採用企業リストを典拠にできないことの確認にあたる。