J-Quants V1が廃止された日、僕の自動売買は静かに死んでいた（V2移行の実装差分ぜんぶ）

僕の自動売買は、3ヶ月動いていませんでした。

しかも、止まっていたことに気づいたのが3ヶ月後です。エラー通知も見ていました。ログも残っていました。それでも気づけなかった。理由は身も蓋もなくて、ペーパートレードのまま放置していたからです。実弾が入っていないと、壊れても誰も困らない。僕すら困らない。だから気づかない。

きっかけはJ-Quants V1の廃止（2026年6月1日）でした。「エンドポイントのパスを直せば済むだろう」と思って開いたら、認証方式ごと入れ替わっていました。

この記事は、その移行で僕が実際に踏んだ地雷と、直すのに必要だった差分を全部置いておくものです。同じ穴に落ちる人を減らしたい。コードはClaude Codeに書かせています。僕は本業が会社員で、エンジニアではありません。

先に断ります。この記事は特定銘柄の推奨も、投資助言も、利益の保証もしません。書いてあるのは「売買を自動化する仕組みを動かし続けるための実装の話」だけです。運用は自己責任で、必ずペーパートレードから始めてください。サービスの料金・API公開状況・自動売買の可否は各社の規約と最新情報をご自身で確認してください。

踏んだ地雷6個（先に結論）

1. API廃止：V1が2026-06-01に廃止。パスだけの話だと思ったら認証が3段トークン方式 → APIキー1本方式に入れ替わっていた。関数が丸ごと不要になりました。
2. 存在しないパスで「通った」と誤解：価格取得を /v2/prices/daily_quotes と書いていた。このパスは存在しません。 正しくは /v2/equities/bars/daily。上場一覧のほうだけ通っていたので「移行できた」と勘違いしていました。
3. カラム名の短縮：Open→O、Close→C、Volume→Vo。通信量削減でレスポンスの項目名が短くなります。参照を全部直す必要があります。
4. レート制限：V2でプランごとにリクエスト上限。全銘柄をループで回す設計だと詰まります。数銘柄を朝1回なら平気でした。
5. 「ペーパーのまま放置」の罠：冒頭のとおり。壊れても誰も困らない構成だと、壊れたことに気づけません。
6. 売った瞬間、加害側に回る：僕は過去に「動くコード」を記事にして売っていました。買った人の環境は、僕が気づかないうちに、僕のせいで止まっていた。 これが一番効きました。

技術の話は1〜4で終わりますが、実際にダメージが大きかったのは5と6です。自動売買は「作る」が2割で、「動かし続ける」が8割でした。

認証：ここが本丸

一番変わったのは認証です。パスの話だと思って油断していました。

V1（廃止済み）

メール＋パスワード
  → リフレッシュトークン取得
  → IDトークン取得
  → Authorization: Bearer {idToken}

3段構えで、トークンの有効期限管理も自前で必要でした。

V2

ダッシュボードでAPIキーを1本発行
  → ヘッダーに載せるだけ（有効期限の管理は不要）

つまり、get_refresh_token() と get_id_token() に相当する処理は関数ごと削除していいです。V1廃止後は呼んでもエラーになるだけなので、残しておく理由がありません。

僕はここで「まだ動くかもしれないから残しておこう」と迷って、結局デバッグを複雑にしました。壊れた層は消したほうが速いです。

エンドポイント対応表

V1	V2
/v1/prices/daily_quotes	/v2/equities/bars/daily ← ★/v2/prices/... は存在しない
/v1/prices/prices_am	/v2/equities/bars/daily/am
/v1/listed/info	/v2/equities/master
/v1/derivatives/futures	/v2/derivatives/bars/daily/futures
/v1/derivatives/options	/v2/derivatives/bars/daily/options
/v1/option/index_option	/v2/derivatives/bars/daily/options/225

/v2/prices/daily_quotes と機械的に読み替えたくなりますが、そのパスは無いです。僕はここで一番時間を溶かしました。上場一覧（/v2/equities/master）のほうは素直に通るので、「移行成功」と誤認しやすいのも罠でした。

カラム名対応

V1	V2
Open	O
High	H
Low	L
Close	C
Volume	Vo
AdjustmentClose	AdjC

中身は変わりません。df["Close"] → df["C"] の置換で済みます。ただし置換漏れはその場では落ちず、後段の判定ロジックで静かにNaNになるので、移行後は必ず1回、取得直後のDataFrameのカラムを目視してください。

直し方（5ステップ）

1. ダッシュボードでAPIキーを発行。トークン取得処理は全消し
2. リクエストヘッダーをAPIキー方式に差し替え
3. 価格取得パスを /v2/equities/bars/daily に
4. カラム参照を短縮名に置換
5. 売買判断・リスク管理のコードは触らない

5番目が言いたいことの半分です。次で説明します。

なぜ「取得層だけ」直して済んだのか（設計の話）

移行で書き換えたのは、データ取得の1ファイルの認証とパスだけでした。売買判断もリスク管理も、1行も触っていません。

これは僕が偉かったからではなく、最初に層を分けておいたからです。

main.py              ← 起動・全体のオーケストレーション（毎朝1回叩く）
 ├─ data_fetcher.py    ← 価格・銘柄情報を取得   ★V2移行で作り替えた層
 ├─ signal_engine.py   ← 売買シグナルを判定     ← 触っていない
 ├─ risk_manager.py    ← ポジション量・損切り   ← 触っていない
 ├─ order_executor.py  ← 発注                   ← 触っていない
 └─ reporter.py        ← 結果の記録・通知

勘所はひとつです。API仕様の変更は、必ず「外側」で起きます。 取得・認証・発注が外側で、判断とリスクが内側。この2つを混ぜて1つの巨大スクリプトにすると、廃止のたびに全部を読み直すことになります。分けておくと「外側だけ直せば復活」で済みます。

自動売買を作るときに一番効いた判断は、アルゴリズムの選定でも銘柄の選定でもなく、この分割でした。

Claude Codeに直させるときのコツ

非エンジニアなので、実装はClaude Codeにやらせています。移行のときに効いたのは、「機能」で頼まず「条件」で頼むことでした。

悪い頼み方：

J-Quants V2に移行して

これだと、動いている内側のロジックまで気を利かせて書き換えられることがあります。

良い頼み方：

data_fetcher.py だけを修正してください。
- 認証をAPIキー方式に変更（トークン取得関数は削除）
- 価格取得パスを /v2/equities/bars/daily に変更
- カラム参照を O/H/L/C/Vo/AdjC の短縮名に変更
- signal_engine.py と risk_manager.py は絶対に変更しないでください
- 変更後、取得したDataFrameのカラム一覧をprintする一時コードを入れてください

触ってはいけないファイルを明示するのと、検証用のprintまで頼んでおくのが効きます。移行作業でいちばん怖いのは「静かに壊れる」ことなので、確認手段を同じ依頼に含めておくと事故が減ります。

まとめ

• V1→V2はパスの差し替えではなく認証の作り替え。トークン取得は関数ごと消す
• /v2/prices/daily_quotes は存在しない。正解は /v2/equities/bars/daily
• カラムは短縮名に。置換漏れは静かにNaNになるので取得直後に目視する
• 外側（取得・認証・発注）と内側（判断・リスク）を分けておくと、廃止が来ても内側は無傷
• そして——ペーパーのまま放置すると、壊れたことに誰も気づけません。僕は3ヶ月気づきませんでした。

---

おまけ（宣伝です）

この記事に書いたのは「壊れたものの直し方」だけです。その手前の「そもそもどのAPIを選ぶか」——データ取得と注文執行で最適解が違う話、4社を比較してどう決めたかの意思決定表、6モジュールの設計を実際どう切ったか、Claude Codeへの依頼文テンプレ集、本番稼働までのチェックリスト——は、noteに1本にまとめて置いています（有料）。

👉 自動売買は「作る」が2割だった。残り8割、「動かし続ける」で全部壊れた話

この記事の移行差分は、それを買わなくても直せるように全部無料で出しています。 上のnoteは「これから作る人が、選定から本番稼働までを1本で通したい」場合のものです。