日本株の API 比較 — J-Quants / EDINET / kabuステーション

この記事が役に立つ人

日本株の株価や決算データをプログラムから扱いたい
J-Quants は見つけたが、ほかに何があるのか分からない
作ったものを公開してよいのかを、実装を始める前に知っておきたい

内容は 2026 年 9 月時点 の公式情報に基づきます。料金は構造と桁感だけを書き、金額は変わるため断定しません。順位付けではなく、用途による使い分けの整理です。

結論を先に

🗺️ 何をしたいかで選ぶ

3 つは競合ではなく、返すものが違う

📈 相場や決算の数値で分析したい

J-Quants API

株価・財務・信用残を数値で返す。ただし個人の私的利用に限られる

📄 開示書類の中身を読ませたい

EDINET API

有価証券報告書などの書類そのものを返す。無料で、金融庁が提供

🛒 注文まで出したい

kabuステーションAPI

板情報の取得と発注ができる。証券口座とプラン条件が前提

そもそも 3 つは競合していない

同じ「日本株の API」でくくられるが、返すものが違う。どれが優れているかではなく、やりたいことがどこに当たるかで決まる。

🔧 やりたいことと、返ってくるもの

先に決めるのは製品ではなく、必要な出力の種類

<path d="M360 52 L360 74" stroke="rgb(100 116 139)" stroke-width="1.5"/>
<path d="M120 74 L600 74" stroke="rgb(100 116 139)" stroke-width="1.5"/>
<path d="M120 74 L120 96" stroke="rgb(100 116 139)" stroke-width="1.5"/>
<path d="M360 74 L360 96" stroke="rgb(100 116 139)" stroke-width="1.5"/>
<path d="M600 74 L600 96" stroke="rgb(100 116 139)" stroke-width="1.5"/>
<polygon points="120,104 115,94 125,94" fill="rgb(100 116 139)"/>
<polygon points="360,104 355,94 365,94" fill="rgb(100 116 139)"/>
<polygon points="600,104 595,94 605,94" fill="rgb(100 116 139)"/>

<rect x="20" y="106" width="200" height="58" rx="10" fill="rgb(56 189 248 / 0.08)" stroke="rgb(56 189 248 / 0.4)"/>
<text x="120" y="130" text-anchor="middle" fill="rgb(125 211 252)" font-size="14">数値で分析したい</text>
<text x="120" y="151" text-anchor="middle" fill="rgb(148 163 184)" font-size="12">株価・財務・信用残</text>

<rect x="260" y="106" width="200" height="58" rx="10" fill="rgb(16 185 129 / 0.08)" stroke="rgb(16 185 129 / 0.4)"/>
<text x="360" y="130" text-anchor="middle" fill="rgb(52 211 153)" font-size="14">書類の中身を読みたい</text>
<text x="360" y="151" text-anchor="middle" fill="rgb(148 163 184)" font-size="12">有価証券報告書など</text>

<rect x="500" y="106" width="200" height="58" rx="10" fill="rgb(245 158 11 / 0.08)" stroke="rgb(245 158 11 / 0.4)"/>
<text x="600" y="130" text-anchor="middle" fill="rgb(251 191 36)" font-size="14">注文を出したい</text>
<text x="600" y="151" text-anchor="middle" fill="rgb(148 163 184)" font-size="12">板情報と発注</text>

<path d="M120 164 L120 190" stroke="rgb(100 116 139)" stroke-width="1.5"/>
<path d="M360 164 L360 190" stroke="rgb(100 116 139)" stroke-width="1.5"/>
<path d="M600 164 L600 190" stroke="rgb(100 116 139)" stroke-width="1.5"/>
<polygon points="120,198 115,188 125,188" fill="rgb(100 116 139)"/>
<polygon points="360,198 355,188 365,188" fill="rgb(100 116 139)"/>
<polygon points="600,198 595,188 605,188" fill="rgb(100 116 139)"/>

<rect x="20" y="200" width="200" height="44" rx="10" fill="rgb(30 41 59)" stroke="rgb(56 189 248 / 0.5)"/>
<text x="120" y="228" text-anchor="middle" fill="rgb(226 232 240)" font-size="14">J-Quants API</text>

<rect x="260" y="200" width="200" height="44" rx="10" fill="rgb(30 41 59)" stroke="rgb(16 185 129 / 0.5)"/>
<text x="360" y="228" text-anchor="middle" fill="rgb(226 232 240)" font-size="14">EDINET API</text>

<rect x="500" y="200" width="200" height="44" rx="10" fill="rgb(30 41 59)" stroke="rgb(245 158 11 / 0.5)"/>
<text x="600" y="228" text-anchor="middle" fill="rgb(226 232 240)" font-size="14">kabuステーションAPI</text>

<rect x="20" y="256" width="680" height="34" rx="8" fill="rgb(239 68 68 / 0.08)" stroke="rgb(239 68 68 / 0.3)"/>
<text x="360" y="278" text-anchor="middle" fill="rgb(252 165 165)" font-size="13">どれを選んでも、次に確かめるのは「自分の用途で使ってよいか」</text>

取得できるもの

	J-Quants API	EDINET API	kabuステーションAPI
提供元	JPX 系	金融庁	三菱UFJ eスマート証券
主に返すもの	株価・財務・信用残などの数値	提出された開示書類そのもの	板情報・銘柄情報・取引余力
形式	JSON	一覧は JSON、本体は XBRL / PDF	JSON と PUSH（WebSocket）
発注	できない	できない	できる
リアルタイム性	プランによる	提出されたあと	板情報を PUSH で受け取れる

EDINET だけ毛色が違う。返ってくるのは数値ではなく書類なので、決算の数字を使いたいなら XBRL を解く工程が別に要る。「API を叩けば決算数値が JSON で返ってくる」という前提で設計すると、あとから解析基盤を足すことになる。

最初の分岐は機能ではなく「使ってよいか」

この領域では、値が返ってくることと、その値を自分のサービスに載せてよいことが一致しない。技術検討より先にここで結論が出ることが珍しくない。

	使える範囲
J-Quants API	個人の私的利用に限定。法人利用は禁止で、取得したデータの配布・共有も、それを使ったアプリの提供も営利・非営利を問わず不可
EDINET API	公開情報だが、利用条件は EDINET のサイトで提示されている。載せ方によって判断が変わるため、事前に規約を読む必要がある
kabuステーションAPI	自分の口座での利用が前提。取得した相場情報を第三者に見せる形は、別途 kabuステーション側の規定を確認する

🔴

「株価データでサービスを作る」は J-Quants では成立しません

J-Quants は個人の私的利用に限って提供されており、法人による利用は禁止されています。取得したデータを閲覧できる形で配布・共有すること、そのデータを使ったアプリを提供することも、営利・非営利を問わず認められていません。ここでいう私的利用は自身の投資分析やポートフォリオ管理を指し、分析結果を継続反復して第三者へ配信する行為は含まれません。法人での利用や外部配信が必要な場合は J-Quants Pro が案内されています。公開するものを作る前提なら、実装に入る前にここで判断が終わります。

EDINET については、このページでは可否を断定していません。金融庁は EDINET のサイト以外では有償・無償を問わずこの情報の提供を行っていないと明記しており、取得元と利用条件の確認は利用者側の責任になります。

動かす場所の制約が先に来ることがある

外部のホストに向けて叩く前提で設計を始めると、1 つだけ外すものがある。

🟡

kabuステーションAPI の接続先は localhost だけです

公開されている API 定義に載っているサーバーは http://localhost:18080/kabusapi（本番用）と http://localhost:18081/kabusapi（検証用）の 2 つだけです。Windows で kabuステーションを起動しているあいだ、そのマシンの中に API サーバーが立つ構造で、VPS やサーバーレスに置いて 24 時間動かす構成にはそのままでは載りません。常時稼働させたいなら、置き場所の話が実装より前に来ます。加えて利用には Professional か Premium プランであることが条件で、申込が済んでいてもプラン条件を満たさなければ「利用不可」と表示されます。

J-Quants と EDINET は通常の HTTP API なので、この制約はない。サーバー側で定期実行して溜める形にそのまま載る。

数値は「いつ時点のものか」で意味が変わる

3 つに共通して効いてくるのがこれだ。取得した値をそのまま保存して集計すると、 古い数値と新しい数値が混ざったまま結論が出る。

🟡

訂正報告書は「別の書類」として後から出てきます

EDINET では、提出済みの書類が訂正されると訂正報告書が改めて提出日に現れます。日付で舐めて集めると、同じ会社の同じ決算期について複数の書類が集まります。提出者と対象期間で名寄せし、訂正の有無を見て採用する版を決める処理を入れていないと、集計に古い数値が残ります。取り込む側では、値だけでなく「いつ提出されたものか」を一緒に保持しておくと、あとから遡って再計算できます。

料金の考え方

金額は変わるので構造だけ書く。

J-Quants — 無料プランと有料プランがあり、遡れる期間と待たされる度合いが変わる。使えるデータの種類そのものもプランで変わる
EDINET — 課金の仕組み自体が無い。利用登録と API キーの発行だけで使える
kabuステーションAPI — API に利用料を課す形ではないが、kabuステーションのプランが条件になる。つまり費用は口座側の条件として現れる

「無料かどうか」で並べると kabuステーションを取り違えやすい。 API の料金表に金額が無くても、使うための条件は口座側にある。

大量に取りに行く設計にはなっていない

3 つとも、全期間・全銘柄を一度に引く経路は用意されていない。

💡

最初から差分取得の形で組むと、そのまま運用に乗ります

EDINET は日次の一覧から必要な書類だけ本体を落とす形、J-Quants はプランごとの流量、kabuステーションは秒間 10 件ほどの制限と登録できる銘柄が REST / PUSH 合わせて最大 50 という上限があります。とくに kabuステーションは情報系のリクエストを投げると照会した銘柄が自動で登録リストに入るため、スクリーニングのつもりで多数の銘柄を順に照会すると枠を使い切ります。取得済みのものを識別子で持ち、再取得しない作りにしておくと、上限に当たってから設計を変える手戻りを避けられます。

組み合わせるとどうなるか

役割が違うので、併用は自然に成立する。よくある形は次の 2 つだ。

数値 + 書類 — J-Quants で株価と財務の推移を取り、気になった銘柄について EDINET で有価証券報告書の本文を読む。数値では見えない事情がこちらに出る
分析 + 発注 — 分析を別の経路で行い、注文だけ kabuステーションに出す。ただし発注側は手元の Windows 環境が要るので、分析部分と同じ場所には置けない

いずれの場合も、利用条件はサービスごとに別々に効く。片方で許されていることが、もう片方でも許されるわけではない。

まとめ

返すものが違うので、3 つは競合ではない。数値なら J-Quants、書類なら EDINET、発注なら kabuステーション
最初の分岐は機能ではなく利用条件。とくに J-Quants は個人の私的利用に限定されており、公開するものを作る前提ならここで結論が出る
kabuステーションは localhost でしか動かない。クラウドに置く前提の設計とは噛み合わないので、置き場所を先に決める
値と一緒に「いつ時点か」を持つ。訂正や遡及修正があるため、値だけ保存すると古い数値が混ざる

🔗