トレーディングプラットフォームとマッチングエンジンを Rust で開発する会社：どの部分に Rust が必要か、専任チームをどう雇うか

自社のエンジニアが Rust でマッチングエンジンや注文経路のほかの部分を構築し、本番環境で動かし続けている会社を探すこと。契約の前に、あなたのチームに加わる人たちに会っておくこと。Rust が力を発揮するのは、遅延がお金に直結する場所である。マッチングエンジン、プレトレードのリスクチェック、取引所へのゲートウェイ、そしてマーケットデータのハンドラーだ。画面、レポート、バックオフィスのツールは、自社ですでに使っている言語のままでよい。

Rust のトレーディングプラットフォームとマッチングエンジンを専門にしているのはどんな会社か？

この記事は会社のランキングを作らない。専門家とは、自社のエンジニアがすでに Rust でトレーディングシステムを納品し、顧客のために運用している会社のことだ。あなたが契約した後で Rust エンジニアを採用するつもりの会社が差し出しているのは、実際には採用計画である。

トレーディングのコードは非公開であることが多い。たいていは顧客が所有し、外に出さないので、力のある会社でも GitHub 上のトレーディングコードは少ないかもしれない。その代わりに、本番環境のシステムを一つ、最初から最後まで説明してもらう。何をするシステムか、どの部分が Rust で書かれているか、速度をどう測っているか、いま誰が運用しているか、ローンチ後に何が壊れたか。秘密保持契約で顧客名が伏せられているなら、その顧客との通話を会社に手配してもらう。

次に人を確かめる。あなたのシステムに携わるエンジニアの名前と Rust の経験を聞き、契約の前に本人たちと話す。上でリンクした専任チームについての記事が、一般的な確認方法を扱っている。公開コード、有償トライアル、そして独立したエンジニアによるレビューだ。

トレーディングプラットフォームのどの部分を Rust で書くべきか？

注文の経路上にある部分だ。そこでは数ミリ秒の停止が、顧客が得る価格を変えうる。

• マッチングエンジン。買い注文と売り注文を、価格と到着時刻にもとづいて突き合わせる
• プレトレードのリスクチェック。上限を破る注文を、市場に届く前に止める
• ゲートウェイ。注文を取引所やブローカーに送り、その応答を受け取る
• マーケットデータのハンドラー。価格フィードを読み、更新を一つずつ先へ渡す

これらの部分に Rust が合うのは、ガベージコレクタなしでメモリを解放するからだ。言語によってはこの仕事にガベージコレクタを使い、それは自分で選んだタイミングでプログラムを一時停止させることがある。Rust の公式ガイドである Rust の本（2026年10月27日に閲覧）は、その背後にある一連のルールである所有権が「ガベージコレクタを必要とせずに、Rust がメモリ安全性を保証できるようにする」と述べている。

言語だけでシステムが速くなるわけではない。Rust のプログラムでも、メモリを確保するため、別のスレッドが持っているロックを待つため、あるいはネットワークを待つために止まることはある。マッチングエンジンの設計についての記事が、チームがこうしたものを注文経路から締め出す方法を説明している。

プラットフォームの残りの部分には、ミリ秒単位の期限がない。ウェブとモバイルの画面、顧客口座、レポート、バックオフィス、管理ツールなどだ。これらは、自社の開発者やベンダーがすでに使っている言語のままでよい。それらを Rust で書き直そうと提案する会社は、それであなたが何を得るのかを説明すべきだ。

すでに C++、Java、Go でプラットフォームを動かしている。Rust で書き直すべきか？

たいていは、一度に全部ではない。より安全なのは、リスクチェックやマーケットデータのハンドラーのように境界のはっきりしたコンポーネントを一つ移し、残りはそのままにしておくやり方だ。

新しいコンポーネントは、システムのほかの部分とメッセージをやり取りする独立したサービスとして動かせる。C や C++ のコードから直接呼び出すライブラリとして作ることもできる。Rust プロジェクトによる unsafe と低レベルのコードについてのガイド Rustonomicon は、そのやり方を「Calling Rust code from C」という節で説明している。

切り替える前に、新しいコンポーネントを古いものと並べて、同じ録画済みの注文フローで動かし、すべての結果を比べる。決定的なマッチングエンジンは、同じ注文が同じ順序で来れば、常に同じ結果を返す。そのため比較は簡単になる。両方のエンジンが同じルールを適用しているなら、どんな違いもどちらかのバグを指している。

それから、一度に一つの市場、あるいは一つの銘柄グループずつ移し、古いコンポーネントはいつでもトラフィックを戻せるように待機させておく。

マッチングエンジンのための外部の Rust 専任チームには、どんな人が含まれるか？

専任チームは、何か月、何年にもわたってあなたのシステムだけに取り組み、メンバーが替わるのはあなたが同意したときだけだ。マッチングエンジンや注文経路のほかの部分なら、通常は次の人たちを含む。

• 本番にコードを出したことがあり、注文がどう生きるかを知っている Rust エンジニア。注文タイプ、部分約定、訂正、取消
• 設計に責任を持ち、注文経路へのすべての変更をレビューするリードエンジニア
• 録画済みの注文フローを再生する環境を作り、結果を確かめるテストエンジニア
• サーバー、ネットワーク設定、リリースに責任を持つ人

あなたの会社にも役割がある。呼値の単位、取引時間、手数料、取引停止のときにどうなるかといった取引ルールを、あなたの側の誰かが決め、それについてのチームの質問に長く待たせずに答えることだ。

フリーランスにも優れたエンジニアはいるが、継続性を保つのは難しくなる。一人で請け負う人には、注文経路への変更をレビューしてくれる相手がいない。そしてその人が去れば、あなたのシステムについて知っていたことも一緒に去ってしまう。会社なら人を入れ替え、知識をチームの中に残せるし、契約でそれを義務づけることもできる。

会社がチームの規模を見積もれるのは、あなたの取引ルール、市場、取引量を見た後だけだ。だから、提示された人数にどうやってたどり着いたのかを尋ねるとよい。

マッチングエンジンについて、Rust チームに何を聞くべきか？

速度の数字をどう確かめるかは、低レイテンシの会社についての記事が扱っている。ここでの質問は、Rust と注文経路についてのものだ。

• 御社のコードはどこで unsafe を使っていて、その部分は誰がレビューしているか？
• 録画済みの注文を再生する以外に、エンジンをどうテストしているか？
• 注文経路はどの crate に依存していて、既知の脆弱性がないかをどう確認しているか？
• どの Rust バージョンでビルドしていて、いつアップグレードするかをどう決めているか？
• 提案されたチームのうち誰が Rust を本番に出したことがあり、それはどのシステムで、いまも動いているか？

Rust は、コードをコンパイルする段階でメモリの使い方を検査する。unsafe と記したブロックの中では、コンパイラがふだんは拒否する五つのこと、たとえば生ポインタをたどってメモリに触れることができる。Rust の本はさらに、unsafe は「借用チェッカーを止めるわけでも、Rust のほかの安全性チェックを無効にするわけでもない」と書いている。よい答えは、unsafe のコードがどこにあり、なぜそこに必要で、誰が確認したかを示す。

テストについては、チームが使っているツールの名前を挙げられるべきだ。Rust Fuzz Book が「Rust のコードをファジングするための推奨ツール」と呼ぶ cargo-fuzz は、自動生成した大量の入力をプログラムに与え、それをクラッシュさせるケースを探す。複数のスレッドで動くコードをテストするためのライブラリ Loom は、「テストを何度も実行し、各テストで起こりうる並行実行の順序を入れ替えていく」。これで、スレッドがたまたま運の悪い順序で動いたときにしか現れないバグが見つかる。

crate とは、Rust で共有されるコードのパッケージのことだ。RustSec Advisory Database は、crates.io で公開された crate についてのセキュリティアドバイザリを記録している。そのツール cargo-audit は、プロジェクトの Cargo.lock、つまりすべての依存関係の正確なバージョンを並べたファイルを、「セキュリティ上の脆弱性がある crate がないか」確かめる。注文経路を手がけるチームなら、このチェックがビルドのたびに走っているかどうかを答えられるはずだ。

Rust は6週間ごとに新しい安定版を出しており、Rust の本は「安定版 Rust の新しいバージョンへのアップグレードを恐れる必要はまったくない」と述べている。それでもチームは、すべてのビルドを一つの選んだバージョンにとどめておくことができる。Rust のインストーラー rustup のドキュメントは、「特定の Rust のリリースに『固定』されている」ことに気づき、それをリポジトリに記録したいプロジェクトのための toolchain ファイルを説明している。注文経路では、バージョンを変えるのは意図したときだけ、それもテストが通った後にすべきだ。

Rust チームとの契約には何を書くべきか？

次の点を書き込む。

• コード、テスト、リプレイ用データ、ビルドスクリプトは、あなたの会社が所有するリポジトリに置かれる
• ビルドとリリースは、あなたの会社の名義で開設したアカウントで実行される
• 誰が注文経路を変更してよく、誰がそれぞれの変更をレビューするか
• チームが対応する時間帯と、その時間外にエンジンが止まったときに誰が対応するか
• 契約が終わったときに受け取るもの。ドキュメント、アクセス権、そして次のチームへ引き継ぐためのチームの時間

amBrain はどこに位置づけられるか

このブログを発行している amBrain は、自社を一行でこう説明している。「amBrainは、アルメニア・エレバンを拠点に、Rustで低レイテンシのトレーディングプラットフォーム、マッチングエンジン、リアルタイムビディングシステムを構築するソフトウェアエンジニアリング企業です。」もう一行はこうだ。「amBrain はアルゴリズム取引の基盤を構築する:注文執行、マーケットデータ、プレトレードのリスク管理。」

amBrain は2019年からソフトウェアを作っている。チームについては自社の言葉でこう述べている。「最大40人のチームで、その約75%がシニアです。」働き方には三つの形態がある:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」

この記事は事例紹介ではなく、顧客のための仕事についても述べていない。amBrain が Rust でどんなシステムを誰のために作ったのかは書いておらず、amBrain の価格、期間、チームの規模も示していない。amBrain が候補リストに入っているなら、ほかのどの会社とも同じ質問を渡すこと。