低レイテンシのソフトウェア開発会社:どの種類が必要か、自社のシステムでどう試すか

どの発注者にも当てはまる低レイテンシのソフトウェア開発会社のリストはない。この言葉が指すデッドラインには、100万倍もの開きがありうるからだ。トレーディング用のハードウェアでは、数十から数百ナノ秒を意味することがある。アプリや Web ページなら、約10分の1秒以内の応答で、使っている人にはもう瞬時に感じられる。だから最初の問いは、自社のデッドラインがどこに位置するかである。

自社のシステムにとって「低レイテンシ」とは何を意味するのか

あなたのシステムにとって、低レイテンシとは、名指しできる二つの地点のあいだで計測するデッドラインのことだ。デッドラインは大きく四つの範囲に分かれる:

• トレーディング用のハードウェア。数十から数百ナノ秒の単位。STAC-T0 は、STAC Benchmark Council に参加するトレーディング会社と協議して開発されたベンチマークで、システムのネットワーク用のハードウェアとソフトウェアが、模擬のマーケットデータを模擬の注文に変えるまでの速さを、あいだに取引ロジックを挟まずに計測する。2020年11月5日付の STAC の概要資料によれば、このベンチマークはシステムをブラックボックスとして扱い、「ネットワークパケットだけを介してシステムとやり取りし、そのパケットにハードウェアでタイムスタンプを付ける」。また、数十から数百ナノ秒の世界では、ソフトウェアのタイムスタンプにかなりの誤差が含まれうるとしている。STAC が計測対象のシステムを指して呼ぶ「被試験スタック（stack under test）」は、FPGA カードであることもある。FPGA カードには、回路を一つの処理向けにプログラムしたチップが載っている
• 取引施設。マイクロ秒から約1ミリ秒まで。取引施設の時計に求められる精度についての EU の規則は、その精度を、取引施設の取引システムが注文を処理して確認を返すまでにかかる時間に結びつけている。2026年3月2日以降、この規則は Commission Delegated Regulation (EU) 2025/1155（欧州委員会委任規則）である。同規則は、RTS 25 として知られる以前の規則に代わるもので、この時間をゲートウェイ間レイテンシ（gateway-to-gateway latency）と呼び、「メッセージが取引施設のシステムの外側のゲートウェイで受信された瞬間から、注文送信プロトコルを通じて送られ、マッチングエンジンで処理され、そして送り返されて、ゲートウェイから受付確認が送られるまでに計測される時間」としている。これが1ミリ秒以下の場合、取引施設の時計と協定世界時（UTC）とのずれは100マイクロ秒以内でなければならず、タイムスタンプは0.1マイクロ秒、またはそれより細かい単位でなければならない
• アドテク。数十ミリ秒から1秒まで。IAB Tech Lab のリアルタイムビディングの標準である OpenRTB 2.6 では、エクスチェンジが入札リクエストごとにデッドラインを設定でき、インターネットを渡るのに費やされる時間もその内側に数えられる。2026年9月17日に最終更新された Google の Authorized Buyers の開発者向けドキュメントによれば、レスポンスのデッドラインは「フォーマットとオークションの種類に応じて 80 から 1000 ms の範囲」である
• 人が使うアプリと Web ページ。約10分の1秒。Jakob Nielsen は1993年に、「0.1秒は、システムが即座に反応しているとユーザーに感じさせられる、おおよその限界である」と書いた。Web ページについては、2025年9月に最終更新された Google の web.dev のガイドが、Interaction to Next Paint（INP）が200ミリ秒以下なら応答性を良好と評価している。INP は、クリック、タップ、キー入力にページが応答するまでにかかる時間を測る指標だ

一つのプロダクトの中に、範囲の異なる部分が同居することもある。トレーダーは画面で価格を読むが、そのトレーダーが送る注文は、取引所へ向かう途中で、はるかに厳しいデッドラインを満たさなければならないことがある。それぞれのデッドラインを、それを計測する二つの地点とともに書き出す。どの範囲に入るかで、どの種類の会社に連絡すべきかがわかる。

どの低レイテンシのソフトウェア開発会社と話をすべきか

本稿は会社のランキングをしない。ふさわしい会社の種類は、自社のデッドラインがどの範囲にあるかと、どんな仕事が必要かによって決まる:

• ハードウェアとネットワークのスペシャリスト。ナノ秒や数マイクロ秒で数えるデッドライン向け。FPGA カード、ネットワークカード、スイッチ、取引所への回線を扱う。どの数字が、ネットワークケーブル上でハードウェアが取ったタイムスタンプによるものか、そしてテストが誰の機材で行われたのかを尋ねる
• トレーディング技術のエンジニアリング会社。マイクロ秒やミリ秒単位のデッドラインで、時間が自社のソフトウェアの内部や、ブローカーや取引所へ向かう途中で失われている場合に。注文を送り、マーケットデータを処理し、注文が出ていく前に一件ごとにリスクをチェックし、取引所側では売り注文と買い注文を付け合わせるソフトウェアを書く。作ったシステムのうちどれが今も本番で動いているか、そしてどのブローカーや取引所との接続を書いたかを尋ねる
• アドテクのエンジニアリング会社。エクスチェンジがリクエストごとにデッドラインを決め、サーバーの請求額がトラフィックとともに膨らむ場合に。ビッダーやアドエクスチェンジを作る。作ったビッダーやエクスチェンジのうちどれが今も稼働しているか、そしてそのタイムアウトの数字が、エクスチェンジ側の集計によるものか、その会社自身の集計によるものかを尋ねる
• 独立系のパフォーマンスエンジニア。原因がまだわからない場合や、変更は自社のエンジニアが行う場合に。たいていは一人か少人数で動き、稼働中のシステムを計測して、時間がどこで費やされているかを報告する。顧客名とデータを取り除いた過去のレポートを見せてもらうこと。期待すべきは作り直しではなく診断である
• コンポーネントベンダー。必要な部品が誰にとっても同じように機能し、自社の強みがほかのところにある場合に。マッチングエンジンや取引所への接続のような既製の部品を販売し、自社専用のものを発注する代わりに、それを自社で動かす。レイテンシの数字がどこからどこまでを計測したものか、そしてライセンスを受けたコードのうち何を変更してよいかを尋ねる
• 低レイテンシを専門とするチームを明示している総合的なアウトソーシング企業。多くのエンジニアが必要で、高速な経路が仕事のごく一部にすぎない場合に。そのチームのメンバーの名前と、それぞれが自社と同じ範囲で何を作ったかを尋ね、その人たちが自社のプロジェクトを担当することを書面にしてもらう
• 自社での採用。速さが競争の手段であり、今後もそうあり続け、しかもこの種のシステムを本番に出した経験のあるエンジニアを採用して引き留められる場合に。調査会社の Acuiti は、コンピューターモデルで売買するファンドであるシステマティック・ヘッジファンド50社に、トレーディング技術をどう構築しているかを尋ねた。2023年1月の報告で、同社は、レイテンシは「フロントオフィスの技術を外部に委託することへの姿勢を左右する主要な要因であり、レイテンシが決定的に重要な会社ほど社内で開発する傾向が強い」と述べている

多くの会社は複数の種類にまたがるので、自社に割り当てられるエンジニアがどの種類の仕事をしてきたのかを尋ねる。

その会社が過去に高速なシステムを作ったことがあるのか、どう確かめるか

上でリンクした専任チームについての記事は、どの性能の数字にも添えられているべきものを挙げ、提案依頼書（RFP）にそのまま貼り付けられるチェックリストを示している。以下の問いは、その会社自身の数字がどう作られたのかを明らかにするためのものだ。

時計がどこで動き出し、どこで止まるのかを尋ねる。米国のオプション取引所の約定と気配を統合して配信する OPRA は、入ってきたメッセージが「OPRA 環境のアプリケーション入口に到着した」時点で時計を動かし、出ていくメッセージが「OPRA 環境のアプリケーション出口に到着した」時点で止める。上で引用した EU の定義も、両方の地点について同じくらい厳密だ。始点と終点が明示されていない数字は、自社の数字と比べられない。

典型的な応答だけでなく、最も遅い応答も見る。OPRA が公表している指標では、レイテンシの中央値、つまり真ん中の値は、2024年1月に19.5マイクロ秒、2月に20.5マイクロ秒だった。同じ2か月で、99パーセンタイル、つまり最も遅い1%のメッセージだけが超えた時間は、543.5マイクロ秒から57.5マイクロ秒に下がった。中央値だけのレポートなら、ほとんど変化がないように見えていただろう。

平均もまた、遅い応答を覆い隠す。2016年に O'Reilly から出版された Google の Site Reliability Engineering 本は、毎秒1,000リクエストで平均レイテンシが100ミリ秒の Web サービスを例に挙げ、そこでは「1%のリクエストが簡単に5秒かかりうる」と述べている。経路ごとの99パーセンタイルを求め、計測できるだけのリクエストをシステムが処理しているなら、1,000件に1件の応答だけが超える99.9パーセンタイルも求める。

それぞれの数字の裏にある負荷を確かめる。STAC の2020年の概要資料によれば、STAC-T0 はテスト用のトラフィックを三つのレートで送る。最も低いレートは「システムがほとんどアイドル状態のときにどう振る舞うかを見るために設計されて」おり、最も高いレートは、通常は被試験システムが処理できる上限近くで、「システムが非常に忙しいときにどう振る舞うかを見るために」ある。自社で最も忙しい1分間の数字か、それを再現したテストの数字を求める。

負荷試験がどう行われたのかを尋ねる。多くの負荷試験ツールは、リクエストを送り、応答を待ち、それから次のリクエストを送る。システムが停滞すると、こうしたツールは送信を止めるので、停滞のあいだに届いていたはずのリクエストは、一度も計測されない。

負荷試験ツール wrk2 の作者である Gil Tene は、この効果を coordinated omission と呼ぶ。2019年9月に最終更新されたこのツールのドキュメントで、彼は「レイテンシの高い応答によって、負荷生成器がサーバーと歩調を合わせ、レイテンシが高い期間の計測を避けることになる」と書いている。彼のツールは一定のレートでリクエストを送り、それぞれの応答を「送信が行われるべきだった時刻から」計測する。その会社のツールがこのように動くのか、あるいは結果をどう補正したのかを尋ねる。

それぞれのタイムスタンプをどこで取ったのかを尋ねる。マイクロ秒単位のレイテンシについては、STAC の概要資料は、ソフトウェアのタイムスタンプを使うベンチマークを「最良の選択肢」と呼んでいる。同時に、ソフトウェアのタイムスタンプに生じる小さく不均一な遅延は「数十から数百ナノ秒のレイテンシを計測する際には、かなりの誤差となりうる」と警告しており、STAC-T0 は代わりにハードウェアでタイムスタンプを取る。ナノ秒の数字を挙げる会社なら、ハードウェアのタイムスタンプをどこで取ったのかを示せるはずだ。

誰かを雇う前に、どんなテストをすべきか

何が悪いのかはまだわからず、わかっているのは、システムが本来より遅いか、本来よりコストがかかっているように見えることだけなら、ここから始める。本命の会社に費用を払い、範囲を固定して稼働中のシステムを計測してもらう。レポートは、次にどう決めるにせよ自社のものとして残るようにする。計測のためにその会社が何をインストールし、何を変更してよいか、そして終わったあとにツールをどう取り除くかを、書面で取り決めておく。

レポートには次のことが示されているべきだ:

• 最も忙しい1分間に時間がどこで費やされているか。書き出した経路に沿って、一段階ずつ
• 経路ごとの、99パーセンタイルと99.9パーセンタイルの応答時間
• 修正策を、それぞれにかかるコストと、それによって取り除けるもので順位付けしたもの。取り除けるのが、経路上の時間であれ、遅い経路を覆い隠すために追加されたサーバーであれ
• その会社が手を付けずにおくもの、そしてその理由

トレーディングシステムについては、上でリンクした注文執行の遅さについての記事が、すべての注文で記録すべき四つのタイムスタンプを挙げている。アドテクでは、トラフィックのピークについての記事と DSP のタイムアウトについての記事が、ピーク時に、そしてエクスチェンジとの接続ごとに何を計測すべきかを扱っている。

会社はそのレポートで評価する。自社のエンジニアがその会社なしでもレポートをもとに動けるなら、次の仕事を誰に任せるかを、実際の数字にもとづいて選べる。その会社であれ、別の会社であれ。

低レイテンシの会社を選ぶときの危険信号は何か

• 速さが言葉だけで語られ、数字も計測の始点と終点もない
• 平均値しかなく、最も遅い応答については何もない
• その会社が自前のラボで、自前のハードウェアと自ら生成したトラフィックを使って行ったベンチマークが、あなたのシステムについての証拠として示される
• 誰もあなたのシステムを計測していないうちから、書き直しや新しいプログラミング言語への移行が提案される
• 最初の打ち合わせで、レイテンシの数字が約束される
• マイクロ秒で測るトレーディングの仕事にも、デッドラインが100ミリ秒の広告ビッダーにも、同じ売り込み文句を使う

会社が新しい言語を提案してきたら、下でリンクしている記事が、言語が原因なのかどうかをエンジニアがどう確かめるかを示している。

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

amBrain は、トレーディングとアドテクの遅いシステムを診断する。稼働中のプラットフォームをエンドツーエンドで計測し、時間がどこで費やされているかをレポートで特定する。トレーディング分野の仕事には、トレーディングターミナルの開発、注文管理システム、FIX プロトコルによる取引所連携が含まれる。

AdTech の分野では、amBrain は DSP 開発、リアルタイムビディングのプラットフォーム、アドエクスチェンジのエンジニアリングに取り組んでいる。

amBrain の働き方には三つの形態がある。フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニアだ。顧客は、プロダクトとコードの完全な所有権を保持する。ただし、amBrain の再利用可能なコンポーネントは除く。

amBrain は2019年からソフトウェアを作っている。

この記事は事例紹介ではなく、顧客のための仕事についても述べていない。amBrain が構築したどのシステムについてもレイテンシの数字を挙げず、価格や期間も示さない。

amBrain にも、候補に挙がっているほかのどの会社にも、自社のシステムで最初に何を計測するかを尋ね、すべての会社に同じ確認を課す。

よくある質問

• 代わりに自社のチームを作るべきか。Acuiti が2023年にシステマティック・ヘッジファンド50社を対象に行った調査では、レイテンシが決定的に重要なファンドほど、トレーディング技術を社内で開発する傾向が強かった。どちらにしても、まず計測する。どんな種類のエンジニアを雇うべきか、あるいは会社に何を頼むべきかは、レポートが教えてくれるからだ
• 一つの会社でトレーディングとアドテクの両方をカバーできるか。両方の分野で、自社と同じ範囲の本番システムを持っていれば、できる。分野ごとに稼働中のシステムを一つずつ見せてもらい、その数字を上の問いで確かめる