金融市場データAPI：REST APIでリアルタイム株式データを取得する方法

株価データをアプリに取り込むだけなら、最初の一回はそれほど難しくない。むしろ大変なのは、開発を進めるうちに必要なデータが増えていったときだ。

最初は現在値だけでよかったのに、チャート用の過去データも欲しくなる。監視対象の銘柄も一つから数十銘柄に増え、さらに板情報まで必要になる。ここまで来ると、金融サイトから直接データを取得する方法は、手軽な試作としては使えても、長く運用する仕組みとしては少し心もとない。

そこで使いやすいのが 金融市場データAPI だ。Webページを解析する代わりに、アプリ側から必要なデータをリクエストし、構造化されたレスポンスをそのまま処理できる。

そして、「リアルタイム株式データ」が必要だからといって、最初からWebSocketを使わなければならないわけでもない。ウォッチリスト、ポートフォリオ画面、マーケット監視ツールなどでは、REST APIだけで十分なケースもかなりある。

REST APIでどんな株式データを取得できるのか

RESTを金融データで使う場合、難しく考える必要はない。

「この銘柄の最新価格は？」

「直近100本のK線を取得したい」

「現在のBidとAskを知りたい」

こうした“必要なときに問い合わせる”処理は、REST APIと相性がいい。

実際の株式市場データAPIでは、最新の取引価格だけでなく、過去のK線、板情報、銘柄の基本情報、取引状態なども必要になることが多い。

もちろん、全部を使う必要はない。重要なのは、プロジェクトの要件が増えたときに、同じデータ基盤の上で必要な機能を追加できることだ。

リアルタイム株式データにREST APIを使ってもいいのか

「リアルタイム」と聞くと、すぐにWebSocketを思い浮かべる人は多い。

でも、必ずしもそうではない。

たとえば、数秒おきにウォッチリストを更新するだけなら、RESTで十分な場合がある。ユーザーが銘柄詳細ページを開いた瞬間に最新価格を取得する処理も同じだ。リクエストを送り、JSONを受け取り、画面を更新する。かなりシンプルに組める。

AllTickのREST APIも、このようなリクエスト型のデータ取得に対応している。最新の約定データについては、複数の銘柄コードをまとめて指定でき、価格や時刻、出来高、売買代金などを取得できる。

たとえば、レスポンスは次のような構造になる。

{
  "ret": 200,
  "msg": "ok",
  "data": {
    "tick_list": [
      {
        "code": "857.HK",
        "seq": "30841439",
        "tick_time": "1677831545217",
        "price": "136.302",
        "volume": "0",
        "turnover": "0",
        "trade_direction": 0
      }
    ]
  }
}

実際に便利なのはURLそのものではなく、データが最初から構造化されていることだ。取得した値をそのままフロントエンドへ渡してもいいし、キャッシュやデータベースに保存してもいい。

ただし、一つだけ注意したい。最新値を返すAPIと、過去のTickデータを検索するAPIは同じものではない。現在値が欲しいのか、過去の約定履歴が欲しいのかを最初に分けて考えておく必要がある。

チャートを作るなら、過去データも必要になる

現在の価格だけ見ても、その銘柄がどう動いているのかは分からない。

チャートには過去のローソク足が必要だし、テクニカル分析やリサーチでも過去データは欠かせない。シンプルな銘柄ページでも、現在値だけでは少し物足りない。

ここで 株式市場データ向けREST API が使いやすい。銘柄、時間足、本数を指定して、必要な履歴だけを取得できるからだ。

AllTickのK線APIでは、1分足、5分足、15分足、30分足、時間足、日足、週足、月足などのデータを扱える。株式については最短1分足で、2時間足と4時間足は対象外となっている。

レスポンスも見慣れた形だ。

{
  "timestamp": "1677829200",
  "open_price": "136.421",
  "close_price": "136.412",
  "high_price": "136.422",
  "low_price": "136.407",
  "volume": "0",
  "turnover": "0"
}

これならチャート用のデータとしてそのまま扱いやすい。ページを開いたときに過去のK線を取得し、そのあと最新値を更新していく構成にすれば、初期表示とリアルタイム更新をきれいに分けられる。

複数銘柄を扱うなら、バッチ取得も便利

1銘柄だけなら問題ない。でもウォッチリストが20銘柄、50銘柄と増えていくと、1銘柄ごとに別々のリクエストを送る方法は少しずつ重くなってくる。

そんなときに便利なのがバッチ取得だ。

AllTickには複数銘柄と複数のK線タイプをまとめて取得できるバッチK線APIがある。ただし、これは最新のK線をまとめて取得する用途が中心で、大量の過去データを一括で取るためのものではない。

この違いは意外と大事だ。バッチAPIは「今この銘柄群の状態をまとめて取得したい」という用途に向いていて、長期間の履歴を集める場合は通常のK線取得を使う方が自然だ。

最新価格だけでは足りないときは板情報

単純な株価一覧なら、最新約定価格だけでも十分だ。

でも、もう少し詳しいマーケット画面を作るなら、それだけでは情報が足りない。たとえば136.30で取引されているとしても、現在どこに買い注文があり、どこに売り注文が並んでいるかは分からない。

そういう場合に必要になるのが板情報だ。

板情報APIではBidとAsk、それぞれの価格と数量を取得できる。アプリ側ではスプレッドの表示や簡単な板表示、流動性の確認などに使える。

{
  "code": "857.HK",
  "bids": [
    {
      "price": "136.424",
      "volume": "100000.00"
    }
  ],
  "asks": [
    {
      "price": "136.427",
      "volume": "400000.00"
    }
  ]
}

ただ、機能があるからといって全部使う必要はない。ポートフォリオ画面なら板情報は不要かもしれないし、マーケット監視ツールなら逆に重要になる。必要なデータだけを使った方が、システムはずっとシンプルになる。

株価以外の情報も意外と重要

株式データというと価格ばかりに目が行くが、実際には銘柄そのものの情報も必要になる。

アプリが 700.HK を受け取ったとして、それが何という銘柄なのか、どの取引所に属しているのか、どの通貨で取引されているのか、といった情報がなければ画面を作りにくい。

AllTickの銘柄情報APIでは、米国株、香港株、中国A株について、銘柄名、取引所、通貨、株式数、ロットサイズ、EPS、配当利回りなどの基本情報を取得できる。

こうしたデータは、最新価格のように頻繁に更新する必要はない。別でキャッシュしておけば十分なケースが多い。

取引停止情報も同じだ。株価が更新されない原因が単なる通信障害なのか、実際に取引停止なのかを区別できるだけでも、画面の分かりやすさはかなり変わる。SSE、NYSE、Nasdaq向けの取引ステータス情報が用意されているのは、そのためだ。

REST APIを実際に組み込む

接続そのものは、それほど複雑ではない。

AllTickでは X-API-Key をリクエストヘッダーに設定して認証する。最新値を取得する場合は、取得したい銘柄コードをリクエストに含めればいい。

Pythonなら、たとえば次のように書ける。

import requests

API_KEY = "YOUR_API_KEY"

url = "https://quote.alltick.co/quote-stock-b-api/v1/quote"

payload = {
    "trace": "stock-demo-001",
    "data": {
        "symbol_list": [
            {"code": "857.HK"},
            {"code": "UNH.US"}
        ]
    }
}

response = requests.post(
    url,
    headers={
        "X-API-Key": API_KEY,
        "Content-Type": "application/json"
    },
    json=payload,
    timeout=10
)

response.raise_for_status()

result = response.json()

for item in result.get("data", {}).get("tick_list", []):
    print(item["code"], item["price"], item["tick_time"])

最初はこれくらいで十分だと思う。まずデータを取得できる状態にして、その後でキャッシュ、データベース、チャート、アラートなど必要な機能を足していけばいい。

RESTとWebSocketはどう使い分ける？

WebSocketを検討するタイミングは、主に更新頻度と監視銘柄数が増えたときだ。

少数の銘柄を数秒ごとに更新するのであれば、RESTで問題ない場合が多い。一方で、多数の銘柄を継続的に監視し、更新が発生したらできるだけ早く受け取りたいとなると、毎回ポーリングする方式はだんだん扱いにくくなる。

そこでWebSocketが効いてくる。

私はRESTとWebSocketを「どちらか一つ」ではなく、役割分担で考える方が分かりやすいと思う。

履歴データ / 初期表示
          ↓
        REST
          ↓
      データ層
          ↑
      WebSocket
          ↑
    リアルタイム更新

RESTで履歴や初期状態を取得し、その後の継続的な更新をWebSocketに任せる。こうすると、最初から複雑なストリーミング構成を作る必要がなく、必要になった段階でリアルタイム部分だけ拡張できる。

実装前に押さえておきたいポイント

APIそのものより、周辺の設計でつまずくことは多い。

API Keyはフロントエンドに直接埋め込まず、バックエンド側で管理する。さらに、ダッシュボードの各コンポーネントがそれぞれ独自に同じ銘柄をポーリングすると、同じデータを何度も取得することになる。共通のデータ層と短時間のキャッシュを用意した方が扱いやすい。

銘柄コードも確認しておきたい。API側で指定されたコードと一致している必要があり、大文字・小文字も含めて正確に扱う必要がある。

それから、データごとに更新頻度を分けることも大切だ。最新価格は頻繁に更新する一方、過去のK線や銘柄基本情報まで同じ頻度で取り直す必要はない。ここを分けるだけでも、リクエスト数とシステムの複雑さをかなり抑えられる。

最初から大きなシステムを作る必要はない

私なら、最初のバージョンでは最新価格と過去K線だけを入れる。

そこからウォッチリストが大きくなったらバッチ取得を追加する。板情報が必要になったら、その部分だけ増やす。継続的なリアルタイム更新が本当に必要になった段階で、WebSocketを導入すればいい。

この流れなら、AllTickも自然に使える。REST APIで最新値や過去K線を取得し、必要に応じてバッチK線や板情報を追加し、リアルタイム性がより重要になればWebSocketへ広げていける。

最初から全部を使う必要はない。

プロダクトが必要としているデータから始めればいい。

自分のプロジェクトに合う金融市場データAPIを選ぶには

金融市場データAPIを選ぶとき、私はエンドポイントの数だけでは判断しない。

必要な最新価格を取得できるか。チャートに使う履歴データがあるか。複数銘柄を効率よく処理できるか。そして、将来的に継続的なリアルタイム更新が必要になったとき、RESTからWebSocketへ自然に拡張できるか。

こうした点の方が、実際の開発ではずっと重要だ。

多くの株式アプリにとって、RESTは十分現実的なスタート地点になる。最新値や履歴データの取得はもちろん、開発中のテストもしやすい。その後、監視対象や更新頻度が増えたら、リアルタイム部分だけWebSocketに移せばいい。

目指すべきなのは、可能な限り多くの市場データを集めることではない。

必要なデータを、必要なタイミングでアプリに届けられること。そして、その仕組みを無理なく維持できること。それが、実際に使いやすい リアルタイム金融データAPI の条件だと思う。