証券・FX・暗号資産API比較｜IBKRなど6社の利用条件と制限

この記事では、IBKR、サクソバンク証券、三菱UFJ eスマート証券のkabuステーションAPI、OANDA証券、GMOコイン、bitbankの6社を比較します。対象は自分の取引口座の参照・操作です。IBKRのAPIの使い分けを詳しく見た後、残高・保有資産・約定履歴を集約する設計と、bitbankの残高を取得するPythonの実装例を紹介します。

• 株式や複数市場の口座情報：IBKR、サクソ、日本株中心ならkabuステーションAPIを比較。
• FX口座のREST API：OANDA日本のNYサーバー口座を対象に利用条件を確認。
• 暗号資産の口座情報：GMOコインとbitbankを比較。Python例はbitbankの残高取得から始める。
• 大量呼び出し：毎秒の上限だけでなく、個別APIの待機時間・1回の取得件数・履歴保持期間も比較。

候補を絞るなら第1・2節、IBKRを検討中なら第3節、呼び出し回数と長期運用は第5節、Pythonで試すなら第6・7節から読めます。

ポジション・建玉は保有中の取引、約定は注文が成立した記録です。取得の方式も異なり、REST APIは必要なときに要求を送り、WebSocketは接続を保って更新通知を受け取ります。後者でも購読操作や再接続の制限はあります。

たとえば、口座残高を取得できても、その口座が持つ全銘柄のリアルタイム価格を自由に受け取れるとは限りません。IBKRでは市場データの購読や商品権限が別に関係します。サクソでも価格権限によってポジションの現在価格や損益項目が得られない場合があります。IBKRの市場データ条件・サクソの価格と口座情報

この記事でいう「大量取得」は、必要なデータを利用条件の範囲で継続して取得することです。毎秒の回数だけでなく、1回で返る件数、差分取得、配信の購読、帳票の一括取得を含めて考えます。残高を1日1回集める用途なら、毎秒の上限より認証の維持と履歴の取りこぼしが重要になることもあります。

用途から候補を選ぶなら、複数市場の口座情報を扱う設計はIBKR、OAuth 2.0でアプリへアクセス権を与える設計はサクソ、日本株を中心に本人がプログラムを作るならkabuステーションAPI、日本向けFX口座のREST連携はOANDA、暗号資産の残高取得はGMOコインとbitbankが比較の出発点になります。

IBKRの日本法人はWeb APIとTWS APIを案内しています。口座情報、ポジション、証拠金、注文などを扱えるため、複数資産の管理を考える際の主要候補です。一方、APIごとに接続方法と取得範囲が違います。日本法人のAPI案内

個人Web APIの公式条件は、開設が完了して入金済みのIBKR Pro口座です。関連するペーパー口座を使う場合も本口座の条件が関係します。認証専用資料では個人向けの標準方式がClient Portal Gatewayとされており、「OAuth対応だから個人も常駐アプリなしで使える」とは一括りにできません。個人向け条件・認証方式と対象口座

Client Portal Gatewayは、同じ端末のブラウザーで認証して、その端末からAPIを呼ぶ方式です。公式は毎日の再認証を求め、認証手順の自動化をサポートしていません。日次バッチでは「認証待ち」を処理状態として持たせ、失効した際に古い残高を本日の値として扱わない設計にします。Gatewayの制約・Gateway FAQ

さらに、ポートフォリオ参照用のセッションと、注文・市場データを扱うbrokerage sessionには違いがあります。同じユーザー名で有効にできるbrokerage sessionはIBKR製品を通じて1つです。手動操作するアプリと自作プログラムを同時に使うときも確認が必要です。セッション管理

TWS APIではTWSまたはIB Gatewayを起動し、ログインした状態で利用します。Web APIのClient Portal Gatewayと名前が似ていますが別物です。日次・週次のレポートが目的なら、Client Portalで作ったFlex QueryをHTTP経由で生成・取得するFlex Web Serviceも検討できます。直近の注文一覧と、指定期間の口座レポートは用途を分けて扱います。TWSの導入条件・Flex Web Service

IBKRを採用する際の最初の成果物は、API接続だけでなく「毎朝の取得手順」「認証が切れた日の表示」「不足した履歴の補完方法」です。常時配信が必要か、1日1回のレポートで足りるかを先に決めると、選ぶ接続方式も絞れます。

日本法人は、有効な取引口座を持つ利用者にOpenAPIを案内し、私的使用目的は無料としています。Portfolioで残高やポジション、Tradingで注文、Account Historyで過去取引などを扱えます。API利用料と取引手数料・市場データの費用は分けて見積もります。日本法人の利用案内・APIの機能一覧

試験環境のSIMと本番環境のLIVEではアプリが別で、本番用アプリの申請手順も確認が必要です。個人の本番申請では入金済み口座が条件に挙がっています。OAuth 2.0のトークン更新では、新しいリフレッシュトークンへ置き換える処理まで実装します。試用画面の24時間トークンを本番認証の設計に流用しません。本番アプリの申請・認証仕様

三菱UFJ eスマート証券のkabuステーションAPIは、Professionalプラン以上で利用できます。Windowsでkabuステーションを起動し、APIパスワードからトークンを発行して接続します。/positionsで残高、/wallet/*で商品別余力、/ordersで注文約定を照会できます。利用条件・動作環境・APIリファレンス

利用規定には第三者作成プログラムの利用に関する制限があります。本人が開発する際も現行規定を確認します。トークンは終了・ログアウトだけでなく、別のトークンを新しく発行した場合にも失効します。同じ接続先を使うジョブでは、発行と更新を一か所で管理し、毎朝の接続確認を運用に含めます。API利用規定・接続と認証の仕様

OANDAは東京／TY3向けMT5 APIも案内していますが、本記事ではNYサーバー向けREST APIを比較します。REST・MT5 APIの使い分け

日本向けREST APIは、NYサーバーのFX口座情報・ポジション・注文・履歴等を扱います。Gold会員、プロコース、NYサーバー口座の残高25万円以上などの継続条件があり、初期・月額のAPI利用料金は無料です。デモ口座だけを登録してもAPIを利用できません。国内API案内・デモ利用の条件

海外向けv20の上限を、日本契約の確定値として転載しないことが大切です。履歴取得についても国内の機能表とv20の解説では説明の範囲が異なります。本記事では回数・保存期間を一律の数字にせず、対象口座での確認事項としています。国内の履歴取得解説

暗号資産APIは、本人の残高・余力・建玉・注文・約定情報を扱い、機能ごとのキー権限や接続元IPアドレスの制限を設定できます。公開の価格・板情報を返すPublic APIと、口座情報を返すPrivate APIは別です。注文・約定の通知を受けるPrivate WebSocketもあります。公式API仕様

履歴の設計では、たとえばlatestExecutionsは直近1日分で、1ページ最大100件という条件に注意します。銘柄指定のsymbolが必須なので、売却済みの銘柄も含む取引対象ごとに全ページを取得します。現在の残高だけで取得対象を決めると、残高ゼロの銘柄の約定を落とすおそれがあります。この経路だけで数年分を初回取得できるわけではありません。残高の表示は毎朝でも、約定履歴の収集は保持期間より十分短い間隔にします。たとえば1時間ごとに取得範囲を重ね、約定IDで重複を除く設計です。最終成功時刻を監視し、停止期間が取得範囲を超えたときは欠落を明示します。約定取得を含む公式仕様

bitbankは、資産・注文・約定・入出金履歴等のAPIを提供し、資産管理用途ではAPIキーを「参照」のみの権限にするよう案内しています。本記事の実装例には、この残高取得を使います。キーの権限設定・公式REST仕様

約定履歴は1回最大1,000件で、期間指定も可能です。一方、約定済み・取消済みの注文照会には別の期間条件があります。「注文の状態」と「約定という出来事」を同じ履歴として扱わず、必要な情報を返すエンドポイントを選びます。注文照会・約定履歴の仕様

レート制限は、一定時間内にAPIを呼べる回数の上限です。複数の会社を比較するときは、秒・分・日という時間枠と、誰の呼び出しを合算するかをセットで読みます。

下表の「均等配分の計算値」は、時間を回数で割った平均の間隔です。提供元が保証する最短間隔ではありません。たとえば10回／秒を0.1秒ごとに送っても、通信の揺れ、他のジョブ、個別APIの制限により超過する場合があります。回数を数える時間枠、上限を共有する単位、個別の待ち時間を組み合わせて制御します。

上の間隔はIBKRの公式制限表に基づきます。制限超過では429が返り、IPが10分間の制限対象になる場合もあるため、429のたびに即時再送する設計にはしません。

サクソには、セッション別の枠に加えてアプリ全体で1日1,000万回という標準枠があります。これは全ユーザー・全セッションの合計で、個人口座に毎日1,000万回が割り当てられる意味ではありません。応答のX-RateLimit-<dimension>-RemainingとX-RateLimit-<dimension>-Resetで残数とリセットまでの秒数を確認します。バッチも内部の要求を数えるため、10要求をまとめても1回扱いにはなりません。サクソの上限・応答ヘッダー

kabuステーションAPIには、歩み値の取得が2件／秒という個別枠もあります。APIで同時に利用できるkabuステーションは1つで、API登録銘柄はREST・PUSHを合わせて最大50銘柄です。これは口座に保有できる銘柄数の上限ではありません。API仕様・同時利用の条件

GMOコインのWebSocketでは、購読・解除の操作が同一IPから1回／秒に制限されます。通知が毎秒1件までという意味ではありません。Private用トークンも有効60分・最大5個なので、更新と発行数の管理が必要です。またAPIの呼出上限超過はERR-5003で通知されるため、HTTP 429だけでなく応答本文のエラーも判定します。GMOの制限・エラー仕様

APIキーや実行プロセスを増やしても、口座・ユーザーで共有される枠は増えません。1つの取得プログラムを毎秒5回に抑えても、同じ口座を使う別のプログラムが毎秒8回呼んでいれば、合計が上限を超える場合があります。各ジョブをまとめて制御し、全体と個別APIの両方の枠を守る必要があります。

実装例として、全体上限10回／秒の照会をまず5回／秒、つまり0.2秒ごとの送信に抑え、別途1回／5秒のAPIは6秒ごとに取得する設定が考えられます。これらは説明用の余裕を持たせた設定で、公式推奨値ではありません。ほかのジョブの利用量と応答を見て調整します。待ち時間には時計の補正で逆戻りしない時刻計測を使い、リクエストの送信時点で枠を消費させます。

件数も一緒に見積もります。仮に1回100件返るAPIで6万件を取り込むなら、必要な呼び出しは少なくとも600回です。毎秒5回に抑える設計では約120秒分の呼び出し枠が必要で、さらに通信・ページ処理・再試行の時間がかかります。これは仮の計算例で、上表の各社を実測した速度ではありません。

• 初回取得：対象期間・ページサイズ・履歴保持期間を確認し、取得可能な範囲を記録する。
• 継続取得：最後の成功時刻や取引IDを保存し、期間を少し重ねて取得して重複を除く。同時刻の複数約定を落とさない。
• 配信：WebSocketが使える場合は通知を受け、切断後はRESTやレポートで欠落を照合する。
• 429や一時障害：提供元の指示とRetry-Afterを尊重し、待機・試行回数・処理期限を制限する。注文の再送は照会の再試行と分ける。

再試行の作り方は429とRetry-Afterの扱いで解説しています。上限まで常に呼ぶ設計より、必要な情報を少ない回数で取る設計を先に検討します。

履歴を取り切る方法はページネーションで全件取得する、取得位置と重複を管理する方法は差分取得と再実行の設計で詳しく扱っています。

最初の実装は、複数口座の情報を集めて毎朝確認できる画面にする構成が考えられます。各社の認証と項目変換を担当するプログラムを分け、保存先の形式をそろえます。発注は別の仕組みとして設計し、残高集計のプログラムへ混ぜない構成です。

円換算する場合は、元の通貨・数量、換算レート、価格の時点を別に保存します。口座が返す純資産には現金や評価損益が既に含まれることがあり、「純資産＋現金＋保有商品の評価額」と足すと二重計上になります。口座ごとの純資産を使う集計と、構成資産を積み上げる集計は別々に作り、定義を確認して照合します。

同じ銘柄名でも市場や通貨、デリバティブの限月・権利条件で別の商品になります。銘柄名だけで結合せず、提供元の識別子と商品属性を持たせます。銘柄コードと識別子の突き合わせも参照してください。小数の数量・金額は文字列またはDecimalとして扱い、必要な丸め方を決めるまで精度を保ちます。

画面には「取得済みの口座数／対象口座数」「最終成功時刻」「換算できていない通貨」を出します。取得できなかった口座を0円として合計せず、前回値を使う場合もその日時を表示します。全口座が同時に更新されるわけではないため、異なる時点の値を合算した概算であることも分かるようにします。

添付のサンプルはPython 3.10以降の標準ライブラリだけで動き、結果をJSON形式で出力します。実口座用のbitbank_balance.pyと、架空レスポンスで項目変換を試すdemo_balance.pyを同じフォルダに保存します。まずは認証情報不要のデモを実行してください。残高取得コード・架空データのデモ

残高のonhand_amountを総数量、free_amountを利用可能数量として扱い、提供元・取得時刻・資産コードを付けます。JPYとBTCの数量をそのまま足したり、利用可能数量を総数量に足したりはしません。APIが返す数値の形式や重複した資産、数量の整合性を確認してから出力します。bitbankの資産取得仕様

実口座を試す場合は、参照権限だけのキーを作り、環境変数BITBANK_API_KEYとBITBANK_API_SECRETに設定します。キーをソースコードや記事のコメント欄へ貼らないでください。サンプルは固定のHTTPS接続先と残高取得パスを使い、リダイレクトを拒否します。失敗時に認証情報や応答本文をエラーメッセージへ含めません。残高の出力先にも本人の資産情報が残るため、保存・共有の範囲を決めて使います。

この最小例はタイムアウトや429で失敗として終了し、再試行はしません。定期実行へ進む段階で、取得状態の保存、上限を共有する制御、待機を含む再試行、失敗通知を追加します。まず一つの口座で「成功した値」「失敗した状態」「古い値」を区別できるところまで作り、その後に接続先を増やす順序が扱いやすいでしょう。

IBKRを中心に比較するなら、Web・TWS・Flexのどれで目的を満たせるかを先に決めます。暗号資産の資産集計から始めるなら、照会権限を絞って残高を取得し、取得時刻と欠損を残すところまで作ります。取引口座をAPIで扱う第一歩は、必要な情報が毎回そろい、欠けたときに分かる仕組みを用意することです。