Pythonによる仮想通貨botの作り方とは、取引所が提供するAPIをPythonプログラムから呼び出し、価格取得・売買判断・発注・監視を自動化する開発手法である。結論を先に言えば、初心者が最初に作るべきは「毎日決まった時刻に少額を買うだけのbot」であり、これを国内取引所GMOコインのAPIで動かすのが2026年7月時点の最短ルートだ。派手な売買ロジックは後回しでいい。本記事は、編集部が2026年4月から実口座で続けているAI自動売買の検証運用——その過程で固まった「実運用コードの基本構造」を下敷きに、API接続から発注、そして落とし穴までを実装レベルで解説する。損益がマイナスの期間も含めた一次情報である。
前提:編集部の実運用とこの記事の立ち位置
まず、この記事が何に基づいているかを明らかにしておく。編集部は2026年4月から、AIエージェント（Claude Code)にトレードを任せる検証運用を実口座で継続している。取引の場はオンチェーンDEX（GMX）のパーペチュアルで、毎朝6時にセッションが起動し翌朝自己終了する日次サイクルにより、実質24時間の監視を回している。設定はレバレッジ10倍・利確+3.5%・損切り-4.5%・トレーリングストップ併用・建玉下限400ドル。戦略は相場をレンジとトレンドに分類するモード判定式（レンジ相場ではレンジ端の逆張り、トレンド相場では押し目の順張り）だ。
結果も正直に書く。入金は当初188ドルとその後の追加400ドルで計588ドル。2026年7月上旬にオンチェーン記録を突き合わせた監査での実現損益は約-21ドルである。儲かった自慢をするための記事ではない。3カ月の運用で「botのコードはどういう構造にしておくと壊れにくいか」「どこで事故が起きるか」が具体的に見えたので、それを共有するのが本記事の目的だ。最新の状況は運用実績ページ（/ai-trading）で公開している。
3カ月で起きた失敗と、コード構造への教訓
運用中に起きた失敗は3つある。第一に、ガス代（取引手数料）に対して建玉が小さすぎて、利確しても手数料負けする状態が続いた。対策として建玉の下限（400ドル）をコードに組み込んだ。第二に、早期の損切りが相場のノイズで次々に刈られた。対策として早期損切りを廃止し、トレーリングストップへ2026年7月に全面リライトした。第三に、特定銘柄（WBTC）で発注が通らない不具合が出た。対策として発注を監視するwatchdogを差し替えた。
この3つの失敗が示す教訓は明確で、botの品質は売買ロジックではなく「手数料の計算」「決済ルールの設計」「発注が通ったかの監視」というインフラ部分で決まる、ということだ。以降の基本構造は、この教訓をそのまま反映している。
補足すると、3つの失敗はいずれも「バックテストでは発見できない種類の問題」である。手数料負けは実際のガス代が変動して初めて顕在化し、損切りの刈られすぎは実際の値動きのノイズの中でしか測れず、発注不具合は本番のAPIとの相互作用でしか起きない。つまり、どれだけ事前検証を重ねても、少額の実運用期間を挟まずに本番サイズへ進むのは構造的に危険だということでもある。この点は後述の検証3段階に直結する。
なぜPythonなのか:bot開発の標準言語である理由
仮想通貨botの開発言語としてPythonが事実上の標準になっているのには、実利的な理由が3つある。第一に、取引所APIとの通信に必要な道具（requests、hmac、hashlib、json）がすべて標準ライブラリか定番ライブラリで揃い、数十行で発注まで到達できること。第二に、pandasやNumPyによるデータ分析、さらに機械学習ライブラリまで同じ言語で接続できるため、バックテストから戦略研究までを1つの環境で完結できること。第三に、日本語圏・英語圏ともに取引所API×Pythonの実装例が豊富で、詰まったときに参照できる情報量が他言語と桁違いであることだ。実行速度は速い言語ではないが、秒単位以下の応答が必要な高頻度取引でもない限り、個人のbot開発でPythonの速度がボトルネックになることはまずない。加えて2026年現在は、生成AIにコードの叩き台を書かせる開発スタイルが一般化しており、AIの学習データに最も多く含まれるPythonは、AI支援との相性という点でも有利になっている。
実運用から抽出したbotの基本構造:5つのモジュール
言語やライブラリが何であれ、実運用に耐えるbotは次の5モジュールに整理できる。
| モジュール | 役割 | 事故が起きたときの症状 |
|---|---|---|
| 設定 | APIキー・パラメータの一元管理 | キー漏えい、環境ごとの設定齟齬 |
| データ取得 | 価格・残高・建玉の取得 | 古い価格での誤発注 |
| 判定 | 売買条件の評価 | 過剰最適化、ロジック暴走 |
| 執行 | 発注・決済・リトライ | 手数料負け、二重発注 |
| 監視 | 死活・約定確認・通知 | 静かな停止、放置ポジション |
設定:APIキーは環境変数、パラメータは1ファイルに
APIキーとシークレットは環境変数から読み、コードには絶対に直書きしない。売買パラメータ（利確幅・損切り幅・建玉サイズ）は設定ファイルに集約する。編集部の運用でトレーリング化のような方針転換を即日反映できたのは、パラメータが1カ所にまとまっていたからだ。
import os
API_KEY = os.environ['GMO_API_KEY']
API_SECRET = os.environ['GMO_API_SECRET']
PARAMS = {
'symbol': 'BTC',
'order_jpy': 1000, # 1回の発注額
'take_profit': 0.035, # 利確 +3.5%
'stop_rate': 0.045, # 許容下落 -4.5%
}
データ取得:PublicとPrivateを分けて考える
GMOコインのAPIは、認証不要のPublic API（レート・板・約定履歴）と、認証必須のPrivate API（残高・注文・建玉）に分かれる。まずPublicで価格が取れること、次にPrivateで残高が取れることを、この順で確認する。Private APIの認証は、タイムスタンプとリクエスト内容からHMAC-SHA256で署名を作ってヘッダーに載せる方式だ。
import time, hmac, hashlib, json, requests
BASE = 公式ドキュメント記載のAPIエンドポイント
def latest_price(symbol):
r = requests.get(BASE + '/public/v1/ticker?symbol=' + symbol)
return float(r.json()['data'][0]['last'])
def private_get(path):
ts = str(int(time.time() * 1000))
text = ts + 'GET' + path
sign = hmac.new(API_SECRET.encode(), text.encode(), hashlib.sha256).hexdigest()
headers = {'API-KEY': API_KEY, 'API-TIMESTAMP': ts, 'API-SIGN': sign}
return requests.get(BASE + '/private' + path, headers=headers).json()
注意点はリクエスト頻度の上限で、GMOコインのAPIは概ね1秒あたり1リクエストの間隔を守る必要がある。連続で叩くとエラーが返るため、ループには必ず1秒以上のスリープを入れる。
判定:最初は「時刻が来たら買う」で十分
売買判定は最も夢が膨らむ部分だが、最初のbotでは「毎日決まった時刻に定額買う」だけでいい。移動平均クロスやRSIは、発注・監視の背骨が安定稼働してから足す。編集部の運用でも、モード判定式という比較的複雑な戦略に到達したのは、発注と決済のインフラが固まった後である。判定モジュールの要件はただひとつ、「同じ入力に対して同じ判断を返す純粋な関数にしておく」こと。これができているとバックテストと本番でロジックを共有できる。
def decide(price, avg_price_7d, position):
# 例: 7日平均より3%安く、ポジションがなければ買う
if position == 0 and price < avg_price_7d * 0.97:
return 'BUY'
return 'HOLD'
この程度の単純な関数でも、「価格と状態を受け取り、注文の意思だけを返す」という分離ができていれば、後からロジックを差し替えるのは容易だ。逆に、判定の中でAPIを直接呼んだり発注したりする書き方をすると、バックテストが書けなくなり、テストされていないロジックが本番に直行することになる。
執行:成行の最小注文から、冪等性を意識する
執行モジュールで最初に潰すべき事故は二重発注だ。ネットワークエラーでレスポンスが返らなかったとき、注文が「通っていないと思って再送したら2回通っていた」は定番の事故である。発注前に注文一覧と建玉を確認し、意図しない注文が残っていたら発注を止める防御をループの先頭に入れる。
def buy_market(symbol, size):
path = '/v1/order'
body = {'symbol': symbol, 'side': 'BUY',
'executionType': 'MARKET', 'size': size}
ts = str(int(time.time() * 1000))
payload = json.dumps(body)
text = ts + 'POST' + path + payload
sign = hmac.new(API_SECRET.encode(), text.encode(), hashlib.sha256).hexdigest()
headers = {'API-KEY': API_KEY, 'API-TIMESTAMP': ts,
'API-SIGN': sign, 'Content-Type': 'application/json'}
return requests.post(BASE + '/private' + path,
headers=headers, data=payload).json()
もうひとつ、編集部の手数料負けの教訓から言えるのは、発注サイズと手数料の関係を執行モジュールで検証することだ。「1回の期待利益が往復手数料を上回るサイズか」をコードでチェックし、下回るなら発注しない。この1つのif文が3カ月分の授業料の結晶である。具体的には、利確幅3.5%で発注するなら、建玉×3.5%が往復手数料＋スリッページ想定を明確に上回る建玉サイズが下限になる。編集部の運用で建玉下限を400ドルに設定したのは、まさにこの逆算の結果だった。手数料率は取引所・取引種別で異なるため、自分の環境の実数で必ず計算し直してほしい。
監視:ロジックより先に通知を作る
botは静かに死ぬ。APIエラー、通信断、取引所メンテナンス、プロセスの停止——いずれも例外を握りつぶすと「動いているつもりで止まっていた」状態になる。編集部のWBTC発注不具合も、発注監視（watchdog）がなければ発見がさらに遅れていた。実装としては、①発注の成否をチャットやメールに通知する、②定期的に「生きている」ことを通知する（ハートビート）、③残高が想定レンジを外れたら警報を出す、の3点をロジックより先に作る。
とくに②のハートビートは軽視されがちだが、「通知が来ない」ことを異常のシグナルにできる唯一の仕組みだ。エラー通知だけに頼ると、通知システムごと死んだときに検知手段がなくなる。毎朝決まった時刻に「残高◯円・建玉◯件・直近24時間の約定◯件」という定期報告を送る形にしておくと、死活確認と運用記録を同時に満たせて一石二鳥である。
【手順】GMOコインAPIで最小botを動かす6ステップ
ここからは、上の基本構造を最小構成で動かすまでの手順だ。国内取引所のGMOコインを使うため、海外送金なしの日本円だけで完結する。
- GMOコインの口座を開設する。 金融庁登録の暗号資産交換業者で、口座開設・維持費は無料。暗号資産の送金手数料が無料なので、後で海外取引所と連携する構成に進む場合も土台として使える。
APIキーを発行し、権限を絞る。 会員ページでAPIキーを作成し、必要な権限（参照・注文）だけを有効にする。出金権限は自動売買に不要なので必ずオフ。キーは環境変数に設定し、コードやGitリポジトリに含めない。
Public APIで価格取得を確認する。 上記のlatest_price相当のコードで最新レートが表示されれば、通信まわりはクリアだ。
Private APIで残高照会を通す。 署名の作り方（タイムスタンプ+メソッド+パス+ボディをHMAC-SHA256で署名）を一度通せば、以降のすべての認証付きリクエストは同じ形で書ける。エラーが出る場合は、タイムスタンプのずれと署名対象文字列の組み立て順をまず疑う。
最小単位の成行注文をテストする。 GMOコインは1,000円程度の少額から購入できる。発注→約定確認→履歴取得を一連で通し、注文IDで結果を追える状態を作る。
定期実行と通知を仕込んで放流する。 クラウドの小さな仮想マシンやサーバーレス環境でスケジュール実行し、成否を通知する。自宅PCの常時起動はスリープ・停電・再起動で必ず止まるので推奨しない。まずは1日1回の積立botとして1〜2週間動かし、履歴と通知が期待通りかを確認する。
実行環境の選び方も補足しておく。1日1回〜数回の実行なら、サーバーレスのスケジュール実行（クラウドの関数実行サービス）が最も安く、月額は誤差程度で済む。数分間隔のループが必要になったら、最小構成の仮想マシンを1台立てて常駐させる。編集部の運用のように日次でセッションを起動・終了させる設計は、長時間稼働によるメモリリークや状態の壊れを毎日リセットできるため、常駐型の安定運用の参考になるはずだ。いずれの場合も、タイムゾーンをJSTに固定し、実行ログを日付付きで残すことを忘れずに。
ステップアップ:ccxtと海外取引所APIへ
国内で背骨が動いたら、次の選択肢が2つ見えてくる。
ひとつはccxtライブラリの導入だ。ccxtは多数の取引所のAPIを共通インターフェースで扱えるPythonライブラリで、取引所ごとの署名方式の違いを吸収してくれる。価格取得・残高・発注が統一されたメソッド名で書けるため、取引所を切り替えても売買ロジック側の変更がほぼ不要になる。複数取引所への展開や乗り換えを見据えるなら、直叩きからccxtへの移行は自然な進化になる。
もうひとつは海外取引所のAPIだ。Bitgetは現物・先物に加えてコピートレードまでカバーするREST/WebSocket APIを提供しており、APIキーのIP制限にも対応している。WebSocketでリアルタイムに価格を受け取れるため、秒単位の判定が必要な戦略はこちらの領域になる。手数料は現物0.1%（BGB払い0.08%）、先物メイカー0.02%・テイカー0.06%という水準だ。ただし海外取引所を使う場合は、必ず国内取引所で口座を持った上で、資金の入口・出口を国内に置く構成にする。国内取引所はUSDTを扱っていないことが多いため、国内でBTCやETHを購入して海外へ送金し、現地でUSDTに替えるのが定石だ。送金ネットワーク（ERC20/TRC20など)の不一致は資産喪失に直結するため、テスト送金を必ず挟むこと。
自作botはどんな人に向くか:3つの比較
自作bot 対 コピートレード
対コピートレードで自作botが勝るのは、ロジックの中身を完全に把握・改善できる点と、利益分配のコストがない点だ。コピートレードは利益の最大10%程度がトレーダーへ分配されるが、自作botのランニングコストは実質サーバー代のみ。運用が長期になるほど、このコスト差は複利的に効いてくる。もうひとつ見逃せないのが「不調時の打ち手」の差で、コピートレードの改善手段が実質トレーダーの乗り換えしかないのに対し、自作botは履歴を分析してパラメータやロジックを自分で修正できる。一方、立ち上げの速さと手間ではコピートレードが圧勝で、プログラミングを学ぶ意思がないなら無理に自作する必要はない。過去の成績は将来の利益を保証しないという注意はどちらの方式にも等しく当てはまる。
GMOコインAPI 対 Bitget API
対Bitget APIでGMOコインAPIが勝るのは、金融庁登録業者の枠内で日本円のまま完結する点と、少額（1,000円程度）でのテストのしやすさだ。学習用・積立用の最初のbotに向く。対してBitget APIは、WebSocketによるリアルタイムデータ、先物・コピートレードAPI、最大125倍のレバレッジ（使うかは別として）と、戦略の自由度で勝る。順序としては「GMOコインで背骨を作り、必要になったらBitgetへ広げる」が編集部の推奨だ。
ccxt 対 API直叩き
対API直叩きでccxtが勝るのは、取引所間の差異を吸収した共通インターフェースと、乗り換え耐性だ。取引所ごとに異なる署名方式・エンドポイント・シンボル表記を覚え直す必要がなく、同じコードでBitgetにも他の海外取引所にも接続できる。一方、直叩きは依存ライブラリがなく、APIの仕様変更に自分のコードだけで追従できる把握のしやすさがある。ライブラリのバージョンアップで挙動が変わるリスクとも無縁だ。学習目的なら一度は直叩きで署名を書き、運用が本格化したらccxtに寄せる、という両取りが現実的だろう。なお、国内取引所はccxtの対応が海外大手ほど手厚くない場合があるため、GMOコインを使う段階では本記事のような直叩き実装が確実である。
バックテストと少額実運用:検証の3段階
作ったロジックをいきなり本番資金で動かしてはいけない。検証は3段階に分ける。なお、バックテスト用の過去データは、取引所のPublic APIで取得できるローソク足（KLine）データをCSVで保存しておくのが手軽だ。データ取得モジュールに「過去データをファイルから読む」モードを足しておくと、本番と同じコードパスで検証できる。第一段階はバックテスト。過去の価格データでロジックの成績を確認する。ただし、過去データに合わせ込んだロジック（カーブフィッティング）は本番で機能しないことが多く、手数料とスリッページを含めない成績は必ず過大評価になる。第二段階は少額の実運用テスト。最小発注単位で2〜4週間動かし、バックテストとの乖離を測る。編集部の経験では、この段階で手数料負けや発注不具合といった「バックテストに存在しない問題」が必ず出てくる。第三段階でようやく増額だが、一度に増やさず段階的に行い、1回の取引で失う額を運用資金の1〜2%に抑える固定リスク率をコードに組み込んでおく。増額の判断基準も数値で決めておくとよい。たとえば「少額運用で4週間、手数料込みの損益がバックテスト想定の下限を上回ったら2倍に増額」「最大ドローダウンが想定の1.5倍を超えたら即減額して原因分析」のように、増やす条件と減らす条件をペアで用意しておくと、感情による資金管理の乱れを仕組みで防げる。
リスクと注意点
- 元本割れリスク。 どれだけ丁寧に作ってもbotは損をする。編集部の3カ月も約-21ドルのマイナスだ。失っても生活に影響しない余剰資金で運用すること。
- APIキーの漏えい。 キーが漏れれば第三者に発注される。環境変数管理・出金権限オフ・IP制限は最低限のセットで、GitHubへの誤コミットは典型的な漏えい経路だ。誤ってコミットした場合は、履歴からの削除では不十分で、即座にキーを無効化して再発行するのが唯一の正解である。
- バグによる想定外の発注。 単位の取り違え（BTCと円）、ループ暴走による連続発注など、バグは資金の損失に直結する。最小単位でのテストと発注上限のハードコードで防御する。
- 海外取引所の利用リスク。 Bitgetなどは金融庁登録の暗号資産交換業者ではなく、日本の法規制・補償の対象外だ。出金制限・サービス変更のリスクがあり、実際にBybitは日本居住者向けサービスを終了し、2026年7月22日には未決済ポジションの強制決済に至っている。海外に置く資金は限定すること。
- 取引所メンテナンスと仕様変更。 APIは予告付きで仕様が変わる。エラー時に安全側（発注停止）に倒れる設計にしておく。
- 過剰最適化。 バックテストの好成績はそれ自体では何も保証しない。パラメータを増やすほどカーブフィッティングのリスクは上がる。
- 税務。 botの利益も原則として雑所得で、給与所得者でも年間20万円超の利益は確定申告が必要。取引回数が多いbotは損益計算が煩雑になるため、履歴の自動保存を最初から仕込み、申告の判断は税理士など専門家に相談してほしい。
稼働前チェックリスト
- APIキーを環境変数で管理し、出金権限をオフにした
- 発注サイズが往復手数料を上回るかをコードで検証している
- 発注の成否と死活を通知する仕組みを実装した
- 最小単位の実注文で発注→約定確認→履歴取得を通した
- 1回の損失上限と停止条件を数値で決めてコードに入れた
まとめ
Pythonでの仮想通貨botの作り方は、設定・データ取得・判定・執行・監視の5モジュールに分解し、判定以外の「背骨」から作るのが実運用に基づく結論だ。最初のbotは毎日定額を買うだけでよく、GMOコインのAPIなら日本円1,000円程度から国内完結で検証できる。背骨が安定したら、ccxtや海外取引所APIへ広げ、バックテスト→少額実運用→段階増額の3段階で育てていく。編集部の3カ月・約-21ドルという実績が示す通り、botは魔法ではない。しかし、手数料と監視というインフラを固めた上で改善を重ねる限り、感情に依存しない再現可能な運用体制として機能する。最初の1台が動いた日から、あなたの学習は座学ではなく実データ主導に切り替わる。それがbot自作の最大の価値だ。プログラミングなしで始めたい場合や、口座開設・資金移動のより詳しい流れは、当サイトの自動売買の始め方の手順記事で解説しているので併せて参照してほしい。
<!-- INTERNAL_LINKS_RELATED -->
関連記事
<!-- INTERNAL_LINKS_RELATED -->