J-QuantsのティックCSVを全部落としてみた｜2年で18.9GB・約20億行

何が配られているか

J-Quants のティックは、API を1本ずつ叩いて集めるのではなく、gzip 圧縮された CSV ファイルがまるごと置いてあるのを落とす形です。/bulk/list で一覧が取れ、/bulk/get で署名付きURLをもらって落とします。

# 配られているファイルの一覧を見る（落とす前に大きさが分かる）
r = jq.get("/bulk/list", endpoint="/equities/trades",
           **{"from": "2026-06-01", "to": "2026-09-18"})

for f in r["data"]:
    mb = int(float(f["Size"])) / 1048576
    print(f'{f["Key"]:<48} {mb:>8.1f} MB')

# from は Python の予約語なので、辞書にして ** で渡す

中身はこうなっています。列は7つだけです。

Date,Code,Time,SessionDistinction,Price,TradingVolume,TransactionId
2026-09-01,13010,09:00:00.061246,01,4775,900,000000000006
2026-09-01,13010,09:01:26.728973,01,4780,400,000000000015
2026-09-01,13010,09:02:07.342004,01,4785,300,000000000020

Time はマイクロ秒まで入っています。Code は5桁（4桁の証券コードの末尾に 0 が付く）です。売り買いの方向は入っていません。「この約定は買いか売りか」は自分で推定するしかありません。実際にやってみると約定の54.0%は前と同じ値段で判定できず、扱い方で答えが2ポイント動きます。これは別記事にまとめています。

1日ぶんの実寸

2026年9月1日ぶんを、解凍しながら数えました。

import gzip

# 解凍したときの大きさと行数を、ファイルに書き出さずに数える
raw, lines = 0, 0
with gzip.open("equities_trades_20260901.csv.gz", "rb") as f:
    while True:
        b = f.read(1 << 22)
        if not b:
            break
        raw += len(b)
        lines += b.count(b"\n")

print(f"解凍 {raw/1048576:.1f} MB / {lines-1:,} 行")
# → 解凍 266.7 MB / 4,715,198 行

14営業日ぶんの行数はこうでした。

1営業日およそ 450万行。年間245営業日として 1年で約11億行という規模感です。

★ 日次ファイルは「今月ぶん」しか無い

ここが最初のつまずきどころでした。一覧を広い期間で問い合わせると、返ってくるものが途中で変わります。

6月1日から9月18日までを一度に問い合わせると、こう返ります。

[monthly] equities_trades_202606.csv.gz       1103.3 MB
[monthly] equities_trades_202607.csv.gz       1078.1 MB
[monthly] equities_trades_202608.csv.gz        939.7 MB
[daily]   equities_trades_20260901.csv.gz       45.1 MB
[daily]   equities_trades_20260902.csv.gz       48.0 MB
   ...（9月18日まで14本）

これは実務では都合がよい面もあります。2年ぶんを揃えるのに必要な署名付きURLの発行は、日次なら490回のところ月次24回＋今月14回＝38回で済みます。ただし1本が最大1.1GBあるので、一度にメモリへ読み込まず、分割して処理する前提で組む必要があります。

★ 遡れる範囲が、日足・分足・ティックで全部違う

ここがいちばん大きな発見でした。Light プラン（月1,650円）＋分足・ティックアドオン（月5,500円）＝月7,150円の同じ契約なのに、データの種類ごとに遡れる範囲が別々に切られています。

境目は推測せず、エラー文に書いてある日付を読めば分かります。

# 契約の境目は、エラー文が教えてくれる
try:
    jq.get("/equities/bars/minute", code="86970", date="2024-09-02")
except JQError as e:
    print(e)

# HTTP 400
#   {"message": "Your subscription covers the following dates: 2024-09-21 ~ .
#    If you want more data, please check other plans: ..."}

3種類それぞれで境目を詰めた結果です。

日足だけ5年、分足とティックは2年です。「Lightは5年」という理解で分足の検証を設計すると、3年ぶん足りません。

そして、ティックのほうが分足より18日ぶん多く取れる

表をもう一度見てください。ティックは 2024-09、分足は 2024-09-21 です。ティックは月単位で切られているので、2024年9月の月次ファイルには9月1日からの約定が入っているはずです。

確かめました。1本落として、中の Date 列を数えます。

2年ぶん全部でいくらになるか

契約で取れるかぎり全部を一覧して足しました。落とさずに大きさだけ数えられるのがこの API のよいところです。

月ごとの大きさを並べると、出来高の多かった月が素直に大きいのが分かります。2025年4月が891MB（前月比＋29%）、2026年6月が1,103MBで最大でした。ディスクの見積もりは平均ではなく最大で取っておくのが安全です。

落とす速さ

同じファイルを3回落として測りました。

641.4MB の月次ファイルは 12.6秒（50.8 MB/秒）でした。大きいファイルのほうが速度が出ます。この調子なら 2年ぶん18.9GB は理論上7〜8分ですが、実際はレートリミット（1分あたり50本）と解凍・変換のほうが時間を食います。

どう置くか

CSV.gz のまま置いておくと、「銘柄 7203 の2年ぶんが欲しい」と思うたびに18.9GB を全部読むことになります。検証で使うなら列ごとに詰めた形（Parquet）に直して、銘柄ごとに並べ替えるのが実用的です。

1日ぶんで比べるとこうなりました。

2年ぶんに引き延ばすと、こういう見積もりになります。

• Parquet（日付ごと）＝ 約 12.8 GB
• 銘柄ごとに並べ替えたもの ＝ 約 16.5 GB（4,000本以上のファイルに分かれるぶん圧縮が効きにくく、1.29倍になります）
• 元の CSV.gz を残すなら ＋18.9 GB

全部残すなら50GB近く見ておくことになります。作業中は変換前と変換後が同時に存在するので、余裕はもう少し要ります。

落とす前に確かめること

1. 自分の契約でどこまで遡れるか。日足・分足・ティックで別々です。エラー文に日付が書いてあります
2. 欲しい期間に日次が配られているか。先月以前は月次1本しかありません
3. 置き場所は足りるか。2年ぶんで圧縮18.9GB、解凍112GB
4. 1本1.1GBを一度に読まない造りになっているか
5. 並べ替えは時刻ではなく TransactionId でやっているか
6. 値段が調整前であることを踏まえているか（分割をまたぐと飛びます）

まとめ

J-Quants のティックは、月7,150円の契約で2年ぶん・約20億行が取れます。個人が触れる日本株のデータとしては破格だと思います。

ただし「Lightは5年」は日足の話で、分足とティックは2年です。そして過去の月は日次で落とせません。どちらも公式の料金表からは読み取りにくく、実際に叩いて初めて分かりました。

検証の設計は、データの形が決めます。期間を決める前に、取れる範囲を自分の契約で確かめてください。