Eikon Data API から LSEG Data Library へ── 接続の置き場所から決め直す

Eikon Data API を使って書かれた分析用のスクリプトは、金融機関のなかにかなりの量が眠っています。動いているので触っていない、というものも多いはずです。その Eikon Data API は機能追加が止まり、サポートと保守が終了しています。動かなくなったわけではありませんが、この先の窓口は LSEG Data Library に移りました。

移行というと関数の置き換えを思い浮かべますが、実際に決めるべきなのはそこではありません。接続をどこに置くかです。本稿ではその判断軸を整理します。参照した一次資料は末尾に挙げています。

何が変わったのか

LSEG Data Library for Python は、Refinitiv Data Library for Python のバージョン 2 にあたります。Eikon Data API のような旧来のライブラリからの移行を助ける目的で作られており、Eikon Data API でできることはすべてでき、さらにできることが増えている、という位置づけです。PyPI 上のパッケージ名は lseg-data です。

重要なのは、単に新しいライブラリが出た、という話ではない点です。接続の形態が選べるようになりました。デスクトップから、社内に配置したストリーミング基盤を通して、あるいはクラウドへ直接。そして、どの経路で繋いでも同じ Python コードでデータを取得できます。

これが移行の本質です。関数名の対応表を作って置き換えるだけなら半日の作業ですが、それでは旧構成の制約をそのまま引き継ぐことになります。

LSEG 自身は、この 3 つをアクセスポイントという言い方で整理しています。公式の図では、同じ Data Libraries の下に Platform access point・Desktop access point・Real-Time Platform access point が並び、いずれも最終的に LSEG Data Platform へ繋がる形で描かれています。注目したいのは、Eikon Desktop と LSEG Workspace が Desktop access point の内側に置かれている点です。この 2 つは経路の一種であって、ライブラリの前提ではありません。ここが Eikon Data API との違いで、旧 API はこの箱の中にしか居場所がありませんでした。

デスクトップ依存という制約

Eikon Data API は、端末で Eikon（現 Workspace）が動いていることが前提でした。つまり、人がログインしている端末でしか動きません。この制約は、分析者が手元で回す用途では問題になりませんが、次のような場面ですべて壁になります。

夜間バッチで前日のデータを取得したい。分析結果を社内の共有基盤へ日次で流し込みたい。複数人が使う内製ツールの裏側でデータを引きたい。コンテナ上で動かしたい。いずれも「人がログインした端末」を前提に置けません。

結果として、こうした要件が出るたびに、誰かの端末を専用機にして起動しっぱなしにする、という運用が生まれます。動きはしますが、その端末が再起動すれば止まり、担当者が変われば引き継がれず、なぜ止まったのか分からない障害が定期的に起きます。

移行の機会に決めるべきは、この依存を残すか外すかです。ライブラリの置き換えだけを行えば、依存はそのまま残ります。

接続の置き場所をどう選ぶか

判断は用途で決まります。

分析者が手元で試行錯誤する用途なら、デスクトップ経由のままで構いません。Workspace が立ち上がっている前提が自然に成り立ち、追加の手配も要りません。移行では、この用途のスクリプトを最優先で置き換えます。数が多く、影響範囲が閉じているためです。

無人で動かす用途は、デスクトップ経由から外します。クラウドへ直接繋ぐか、社内に配置した基盤を経由するかは、データの置き場所と社内の方針で決まります。この判断には権限の手配が伴うため、実装より先に着手しておく必要があります。

リアルタイム配信を扱う用途は、社内配置の基盤を経由する構成が前提になることが多く、ネットワークの手配まで含めた話になります。ここだけは移行の日程感が違うので、分析用スクリプトの移行と同じ枠で考えないほうがよいでしょう。

移行の進め方

実務としては、次の順序を勧めます。

第一に、棚卸しです。Eikon Data API を呼んでいるコードを洗い出し、それぞれが何のために動いているか、いつ動いているか、誰が使っているかを並べます。「動いているので触っていない」ものほど、この段階で用途が分からなくなります。分からないものは、止めてよいかを確認する対象です。

第二に、用途で分類します。手元の試行錯誤か、定期実行か、他システムへの供給か。ここで前節の置き場所が決まります。

第三に、手元用途から置き換えます。接続形態を変えないので、変更はライブラリの呼び出し部分に閉じます。ここで新しいライブラリの挙動に慣れておくと、次の段階が進めやすくなります。

第四に、無人用途を接続形態ごと移す。ここが本番です。権限とネットワークの手配が要るため、実装より手配の日程が制約になります。

移行時に確認しておくこと

取得結果の突き合わせ。ライブラリを替えたときに、同じ問い合わせで同じ結果が返るかは必ず確認します。データ型、欠損の表現、時刻の扱いが変わることがあります。移行前後で同じ期間・同じ銘柄を取得し、差分を出す検証を挟みます。目視ではなく、差分をコードで出します。

性能の確認。呼び出し方によっては、旧ライブラリのほうが速い場合があるという報告も出ています。大量に回すバッチでは、移行後に実測して、必要なら取得の単位を見直します。「新しいから速い」という前提は置かないほうが安全です。

資格情報の置き場所。接続形態を変えると、資格情報の種類と置き場所も変わります。デスクトップ経由では Workspace のログインに乗っていたものが、クラウド直結では独立した資格情報になります。コードに書かない、ログに出さない、という原則をここで通しておきます。

まとめ

Eikon Data API から LSEG Data Library への移行は、関数の置き換えとして扱うと、旧構成の制約をそのまま引き継ぐことになります。新しいライブラリは、デスクトップ・社内基盤・クラウドのどこから繋いでも同じコードで書ける点が要点で、ここを使わないと移行の価値の大半を捨てます。棚卸しをして用途で分類し、手元用途から置き換え、無人用途は接続形態ごと移す。取得結果は移行前後で突き合わせ、性能は実測する。この順で進めれば、専用機を起動しっぱなしにする運用から抜けられます。

金融テクノロジー総合研究所では、市場データ基盤の移行と接続設計を受託しています。棚卸しと方式選定からご相談いただけます。LSEG / Refinitiv API 対応の詳細もあわせてご覧ください。ご相談はお問い合わせよりご連絡ください。

参考資料

• LSEG Data Library for Python（デスクトップ・配置済みストリーミング基盤・クラウドの 3 経路と、経路によらず同じコードで書ける点。PyPI パッケージ名 lseg-data）
• Upgrade from using Eikon Data API to the Data library（移行の指針）
• Eikon Data API｜LSEG Devportal（機能追加の終了とサポート・保守の終了）
• Refinitiv Data Library performance significantly worse than Eikon Data API（移行後の性能について実際に上がっている報告。開発者コミュニティの投稿であり公式見解ではない）

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