LSEG Data Library の接続と認証── App Key・Machine ID・サービスアカウントの使い分け

LSEG のデータを API で取得する仕組みを新しく組むとき、最初に詰まるのはコードではなく資格情報です。手元の Workspace では動いたスクリプトが、サーバーに置いた途端に認証で止まる。夜間バッチを動かし始めたら、担当者の Workspace が勝手にログアウトされる。どちらも、接続の種類と資格情報の対応を整理しないまま進めたときに起きます。

本稿では、LSEG Data Library を前提に、接続の種類ごとに必要な資格情報、App Key と ID の役割の違い、Data Platform の認証方式 V1 と V2、同じ ID を複数の場所で使ったときの挙動、設定ファイルの置き場所を整理します。接続をどこに置くかの判断は移行を扱った前稿で扱っており、本稿はその次の段階にあたります。

接続の種類で必要な資格情報が変わる

LSEG Data Library には、接続の種類（セッション）が 3 つあります。公式のクイックスタートに沿って、それぞれに必要なものを並べます。

• デスクトップ（desktop.workspace） — 同じ端末で LSEG Workspace（または Eikon）が起動し、ログインしていること。ライブラリ側に追加のログイン情報は要らない
• Data Platform（platform.ldp） — OAuth 2.0 で認証する。認証方式 V1 なら ID・パスワード・App Key、V2 ならクライアント ID とクライアントシークレット。発行の窓口は LSEG のアカウントマネージャー
• 社内配置の配信基盤（platform.deployed） — 配信サーバーのホスト名とポート。必要に応じて DACS のユーザー名・ポジション・アプリケーション ID。窓口は社内のマーケットデータ管理者

ここで押さえておきたいのは、デスクトップの接続は人のログインに乗っているという点です。Workspace を閉じれば止まり、担当者が替われば資格情報も替わります。無人で動かす処理には使えません。逆に、Data Platform と配信基盤の資格情報は、人ではなく処理に対して発行される前提で設計します。

配信基盤の接続はリアルタイムの配信専用で、過去データの照会はできません。用途によっては、配信基盤と Data Platform の両方の資格情報を手配することになります。手配には社内外の窓口が絡むので、実装より先に着手しておきます。

App Key は「誰が」ではなく「どのアプリか」

資格情報のなかで混同されやすいのが App Key です。公式の説明では、App Key はアプリケーションを識別して監視するための鍵で、ブラウザで開く App Key Generator から発行します。誰がログインしているかを表す ID やパスワードとは、役割が違います。

LSEG が公開している設定ファイルのサンプルでは、デスクトップ・Data Platform・配信基盤のどのセッションにも app-key の欄があります。接続の種類を変えても App Key は要る、と考えておけば外しません。

設計上は、App Key を用途ごとに分けて発行しておくと後で効きます。分析者の手元のスクリプト、夜間バッチ、社内ツールの裏側で同じ App Key を使い回すと、利用状況を見たときにどの処理の呼び出しかを区別できません。どれかを止めたいときに、鍵を替えて全部を止めることにもなります。

Data Platform の認証は V1 から V2 へ

Data Platform に直接接続する場合、認証方式が 2 つあります。LSEG の移行用の対照表をもとに違いを整理します。

• V1 — OAuth2 のパスワードグラント。トークンの取得先は /auth/oauth2/v1/token。ID は GE-A-XXXXXXXX-X-XXXX の形式の Machine ID で、パスワードと App Key を組み合わせる。発行は LSEG のアカウントマネージャー
• V2 — OAuth2 のクライアントクレデンシャル。取得先は /auth/oauth2/v2/token。ID は GE-XXXXXXXXXXXX の形式のサービスアカウントで、パスワードにあたるのがクライアントシークレット。公開鍵と秘密鍵の組による JWT も使える

対照表では、V1 は将来サポートされず、アカウントは V2 へ移行されるとされています。リアルタイム配信（RTO）の V2 のサービスアカウントは、利用者がプラットフォームの管理画面から自分で作成できます。

同じ対照表には、1 つのトークンで同時に張れるリアルタイム配信のセッション数も載っています。RTO の場合、V1 は 1、V2 は 5 です。配信の接続を複数の処理に分けたい構成では、V2 のほうが設計の自由度があります。

ただし、すべての製品が V2 に対応しているわけではありません。LSEG の V2 移行の解説には、ウェルス向けのリアルタイム配信製品は V1 のみに対応していたとの注記があります。自社の契約製品が V2 で使えるかは、新しく組む前に LSEG の担当者に確認します。新規に組むなら、使える限り V2 を選んでおくのが、後の移行を避ける近道です。

同じ ID を 2 か所で使うと片方が切れる

運用で最も多い事故がこれです。Data Platform の ID は、同時にログインできるセッションの数に限りがあります。夜間バッチと担当者の手元のスクリプトが同じ ID でログインすると、後からログインした側が前のセッションを切ります。

LSEG Data Library では、この挙動を signon_control という設定で制御します。LSEG の開発者コミュニティでの LSEG の担当者の説明によれば、これは Data Platform の認証サービスの takeExclusiveSignOnControl に対応し、有効にすると新しいログインが同じ ID の既存のセッションを切って引き継ぎます。「セッション数の上限に達した」というエラーは出にくくなりますが、切られた側の処理は止まります。

ライブラリは現在、この設定を指定せずに Data Platform のセッションを開くと警告を出し、将来の版 2.0 で既定値を有効から無効に変えると予告しています。既定値に頼った実装は、ライブラリの更新で挙動が変わります。設定ファイルか呼び出し側で値を明示しておきます。

根本の対策は、ID を処理ごとに分けることです。人が使う ID と無人の処理が使う ID を分け、無人の処理同士も、同時に動くものは分けます。ID の数は契約に関わるので、ここも資格情報の手配の段階で見積もっておきます。

設定ファイルの置き場所と探される順序

LSEG Data Library は、資格情報を lseg-data.config.json という設定ファイルから読みます。公式の解説によれば、探される順序は次のとおりです。

• コードの中で設定ファイルのパスを指定した場合は、そこ
• コードを実行しているディレクトリ
• 利用者のホームディレクトリ
• 同じ端末で Workspace が起動していれば、設定ファイルが無くてもデスクトップの接続になる

コードの中で指定した値は、設定ファイルの値より優先されます。設定ファイルの sessions の default に既定の接続を書き、各接続の欄に app-key・username・password などを書く構造です。

この順序には落とし穴があります。Data Platform の資格情報が誤っていても、Workspace が起動している端末ではデスクトップの接続で動いてしまうことがあります。開発者の端末では動いたのにサーバーで止まる、という事故の典型です。検証は Workspace を起動していない環境で行い、開いたセッションの種類をログで確かめます。

設定ファイルにはパスワードを平文で書く形になるので、リポジトリには含めません。サーバーでは、実行時に秘密情報の保管庫から値を渡すか、権限を絞った場所にファイルを置きます。

まとめ

LSEG Data Library の資格情報は、接続の種類で変わります。デスクトップは人の Workspace のログインに乗り、Data Platform は V1 の Machine ID とパスワードか V2 のサービスアカウント、配信基盤はホストと DACS のユーザーです。App Key はどの接続にも要り、用途ごとに分けて発行します。V1 は V2 へ移行されるので、新しく組むなら契約製品の対応を確認したうえで V2 を選びます。同じ ID を 2 か所で使うと片方が切れるので、signon_control を明示し、ID を処理ごとに分けます。設定ファイルは探される順序を理解し、Workspace の無い環境で検証します。

金融テクノロジー総合研究所では、市場データ基盤の接続設計と実装を受託しています。資格情報の手配の進め方や、無人で動かす取得処理の設計からご相談いただけます。LSEG / Refinitiv API 対応の詳細もあわせてご覧ください。ご相談はお問い合わせよりご連絡ください。

参考資料

• LSEG Data Library for Python — Quick Start（接続の種類ごとの資格情報と発行の窓口、App Key Generator）
• Account authorization V1 to V2 migration cheat sheet（V1 と V2 のグラント・取得先・ID の形式・同時セッション数・V1 の将来）
• Getting started with Version 2 Authentication for Real-Time Optimized（V2 の導入と、ウェルス向け製品の対応状況の注記）
• Configuration process（設定ファイルの名前と探される順序、コードでの指定の優先）
• LSEG-API-Samples / Example.DataLibrary.Python（設定ファイル lseg-data.config.json のサンプル）
• LSEG Developer Community — signon_control の既定値に関する警告（takeExclusiveSignOnControl との対応と、版 2.0 での既定値の変更。コミュニティでの説明であり公式文書ではない）

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