Bloomberg API（BLPAPI）接続の設計── Desktop・Server・B-PIPE をどう選ぶか

Bloomberg のデータをシステムから取りに行きたい、という相談は繰り返し受けます。そして着手してから行き詰まる箇所も、だいたい決まっています。検証環境では動いたコードが本番で使えない、Python の SDK がインストールできない、深夜のバッチだけ落ちる。いずれも API の書き方ではなく、どの提供形態を選んだかに起因します。

Bloomberg の API（BLPAPI）は、プログラミングインターフェースとしては 1 つですが、データがどこから配信されるかによって 3 つの形態に分かれます。ここを取り違えたまま設計を進めると、コードが完成した後で作り直しになります。本稿では、その 3 形態の違いと、接続・認証・バージョン合わせで実際に問題になる箇所を整理します。参照した一次資料は末尾に挙げています。

API は同じ、配信点が違う

まず押さえるべきなのは、API の呼び出し方は 3 形態で共通だという点です。同じ Session を開き、同じサービスを開き、同じリクエストを組み立てます。違うのは、そのセッションがどこに繋がるかです。

Desktop API は、Bloomberg ターミナルが動いている端末そのものが配信点になります。ターミナルにログインしている人の権限でデータが出てくるため、その端末でターミナルが起動していなければ何も取れません。開発中に「自分の PC では動く」のはこの形態を使っているからで、サーバーに置いた途端に動かなくなります。

Server API は配信点をサーバーへ移した形態です。端末に張り付いている必要がなくなり、複数のプロセスから利用できます。B-PIPE はさらに企業向けの配信基盤で、ターミナルの利用者とは独立した権限体系のもとで、認証・認可を伴って配信されます。

設計上の判断は単純です。無人で動き続ける処理を作るなら、Desktop API は選択肢に入りません。バッチ、常駐サービス、コンテナ上のワーカー、いずれも人がターミナルにログインしている前提を置けないためです。検証を Desktop API で始めるのは構いませんが、その時点で本番の配信形態を決め、権限の手配を並行して進めておかないと、コードができた後で数週間止まります。

接続先のかたち

接続先はセッションの設定として与えます。Python SDK のドキュメントでは、SessionOptions の既定値は接続先ホストが 127.0.0.1、ポートが 8194 と記載されています。Desktop API はこの既定のまま繋がるため、ローカルで書いたコードには接続先の記述が現れません。ここが後で効いてきます。

サーバー側の配信点へ向けるときは、ホストとポートを明示します。setServerAddress は添字を取る形になっており、複数の接続先を並べられます。切り替え先を用意しておくかどうかは可用性の設計に属する話で、片系しか登録していなければ、その 1 台が落ちたときに処理も止まります。

実務では、接続先を設定ファイルや環境変数へ追い出しておくことを勧めます。既定値に頼ったコードは、ローカルとサーバーで挙動が変わる箇所が読み取れません。「どこにも書いていないから既定の 127.0.0.1:8194 に繋ぎに行っていた」という形の障害は、原因に辿り着くまでが長くなります。

サービスとリクエストの組み立て

BLPAPI では、セッションを開いた後にサービスを開いてからリクエストを送ります。参照系・履歴系のデータは //blp/refdata、リアルタイムの配信は //blp/mktdata という名前で分かれています。前者は要求と応答の往復、後者は購読して更新を受け取り続ける形で、扱いが根本的に違います。

この違いは、実装の構造に直結します。参照系は「投げて待つ」ので同期的に書けますが、購読系はイベントを受け取り続けるループになり、接続断と再購読の処理が必要になります。同じ API だからと同じ層に押し込むと、再接続のたびに参照系の処理まで巻き込まれる作りになりがちです。参照系と購読系はモジュールを分けておくのが無難です。

もう一点、リクエストの単位に注意が要ります。銘柄と項目をまとめて送れるため、つい大きな要求を一度に投げたくなりますが、応答は分割されて返り、部分的にエラーを含むこともあります。応答を「成功か失敗か」の二値で扱うと、一部の銘柄だけ欠けたデータをそのまま下流へ流します。銘柄ごとの結果を個別に確認する作りにしておく必要があります。

バージョンを揃える──Python SDK で最初に躓く箇所

Python から使う場合、ここが最初の関門になります。Bloomberg の Python SDK は C++ SDK の薄いラッパーで、C++ SDK と同じメジャー・バージョンおよびマイナー・バージョンである必要があります。公式リポジトリの説明にそう明記されています。パッケージだけ新しくしても、手元の C++ SDK が古ければ動きません。

インストール時には、C++ SDK の場所を BLPAPI_ROOT 環境変数で示します。include ディレクトリを含む階層を指す必要があり、Windows なら C:\blp\API\APIv3\C++API\v3.x.y.z\ のような形です。この変数はインストール時にのみ必要で、実行時には要りません。実行時に必要なのは共有ライブラリのほうで、標準の場所へ置くか、PATH（Linux なら LD_LIBRARY_PATH、macOS なら DYLD_LIBRARY_PATH）を通します。

あわせて、CPython は 3.10 以降が必要で、Python に対応する C/C++ コンパイラも要ります。Windows では Python のビルドに合った VC 再頒布可能パッケージが必要です。

この構成は、コンテナ化するときに効いてきます。C++ SDK は Bloomberg から取得するもので、公開リポジトリから pip install だけで揃う類のものではありません。イメージのビルド手順に SDK の配置を組み込み、バージョンを固定しておく必要があります。ここを曖昧にしたまま「動く環境」を手作業で作ると、再現できない本番環境が 1 台出来上がります。

権限とデータの使い方

技術的に繋がることと、そのデータを使ってよいことは別です。Bloomberg のデータは契約の範囲内でのみ利用でき、取得したデータを別システムへ再配信したり、社外へ提供したりする場合には、その用途が契約に含まれている必要があります。B-PIPE のような企業向けの形態が存在するのは、まさにこの利用範囲を扱うためです。

設計の初期に確認しておくべきことは 3 つあります。取得したデータをどこへ保存するか、誰が参照するか、加工した結果を外部へ出すか。この 3 点が決まっていれば、必要な提供形態と権限の話を先に進められます。逆に、これらを曖昧にしたまま実装だけ進めると、完成後に配信形態からやり直しになります。

運用で効いてくるところ

接続が確立した後に問題になるのは、たいてい次の 3 つです。

第一に、接続断からの復帰です。購読系のセッションは切れます。切れたときに再購読するだけでなく、切れていた間の扱いを決めておく必要があります。値を持ち越すのか、欠損として扱うのか。ここを決めずに実装すると、復帰後に古い値を最新として扱う処理が残ります。

第二に、要求量の制御です。データの要求には上限があり、それを超えると応答が返らなくなります。バッチで大量の銘柄を回すときは、要求の分割と間隔の制御を最初から入れておくほうが、後から詰まってから直すより楽です。想定より少ない件数で始め、実測しながら広げるのが確実です。

第三に、バージョンの固定です。SDK の更新は、C++ 側と Python 側を揃えて行う必要があります。片方だけを更新する運用は事故を招くため、両者のバージョンを 1 か所で管理し、更新は同時に行う手順にしておきます。

まとめ

BLPAPI で行き詰まる原因は、API の使い方より手前にあります。無人で動かすなら Desktop API は使えない。接続先は既定値に頼らず明示する。参照系と購読系は構造を分ける。Python から使うなら C++ SDK とバージョンを揃える。データの利用範囲は実装前に決める。この 5 点を最初に押さえておけば、後戻りの大半は避けられます。

金融テクノロジー総合研究所では、Bloomberg をはじめとする市場データ基盤の接続設計と実装を受託しています。提供形態の選定や既存構成の点検からご相談いただけます。Bloomberg API 対応の詳細もあわせてご覧ください。ご相談はお問い合わせよりご連絡ください。

参考資料

• blpapi-python（Bloomberg 公式の Python SDK。C++ SDK と同じメジャー・マイナーのバージョンが必要、CPython 3.10 以降、BLPAPI_ROOT の指定方法）
• blpapi.SessionOptions（接続先ホストの既定値 127.0.0.1、ポートの既定値 8194、setServerAddress による複数接続先の指定）
• BLPAPI Documentation（各言語の SDK リファレンス）
• Bloomberg Enterprise Data（B-PIPE を含む企業向け配信の位置づけ）

FTL の技術スタックと受託開発の進め方は FTLの技術とは？ にまとめています。