ガイド

仮想通貨botのAPIキーセキュリティ完全ガイド｜権限最小化とIP制限の実践

仮想通貨botや自動売買でAPIキーを安全に扱う方法を、2026年7月時点の国内取引所の権限設定を踏まえて整理。出金権限オフ・IP制限・.env管理・GitHub誤コミット対策・VPS防御・鍵ローテーションまで、コピーして使えるコードと比較表つきで解説する。

公開: 2026-07-20 著者: Web3-AINEWS 編集部ガイド

取引所APIキーとは、取引所のアカウント本体にログインすることなく、プログラムから残高照会や発注などの操作を行うために発行される「文字列の合鍵」である。仮想通貨botやAIトレードを動かす人にとって、このAPIキーの扱いはコードの良し悪しよりも先に効いてくる論点で、権限設定をひとつ間違えるだけで、資産がまるごと外部へ持ち出される経路になり得る。

本記事は2026年7月時点の情報をもとに、国内取引所のAPIキー権限モデル、鍵の保管方法、GitHubへの誤コミット対策、VPSの防御、鍵のローテーションまでを、そのままコピーして使える形で整理したものである。あくまで「自分の鍵を守るための設定と運用」に限定した防御側の内容であり、攻撃手法は扱わない。

仮想通貨botのAPIキーセキュリティとは何か

APIキーセキュリティとは、取引所が発行したAPIキーとシークレットについて、「持てる権限を必要最小限にし」「アクセスできる場所を限定し」「保管場所をコード管理から隔離し」「定期的に作り直す」という4つの操作を継続的に行う運用のことである。

ここで押さえるべきなのは、APIキーは通常のパスワードとは性質が違うという点だ。パスワードは人間が入力する前提なので、2段階認証やログイン通知といった追加の防御が挟まる。一方でAPIキーは機械が無人で使う前提なので、追加確認が挟まらない。つまりキーが漏れた瞬間から、追加の障壁なしにその権限がそのまま行使される。だからこそ、キーそのものを守る以上に「そのキーに何ができるか」を最初に絞ることが本質になる。

APIキーとAPIシークレットの役割の違い

多くの取引所は2つの文字列を発行する。

APIキー（アクセスキー）: 「誰からのリクエストか」を示す識別子。HTTPヘッダーにそのまま載る
APIシークレット（秘密鍵）: リクエスト内容にHMAC署名を付けるための鍵。ネットワーク上を流れない

シークレットはネットワークを流れないため、通信を覗かれても直ちに悪用はされない。逆に言えば、シークレットが漏れる経路は基本的に自分の手元（ソースコード、設定ファイル、チャット、スクリーンショット、VPS上のファイル）に限られる。守るべき場所がはっきりしているのは、むしろ有利な条件だと考えたい。

なぜbot運用者ほど危険度が上がるのか

手動取引のユーザーはAPIキーを発行しない。APIキーを持つのはbotを回している人だけであり、しかもその鍵は「24時間、無人で、実行環境に置かれ続ける」。加えてbot運用者は複数取引所に口座を持ち、鍵を複数管理し、GitHubでコードを管理し、VPSを借りる。管理対象が増えるほど、どこか1点の設定漏れが発生する確率は上がる。自動売買の設計そのものは /guides/crypto-auto-trading や /guides/crypto-bot-python で扱っているが、セキュリティは別軸で独立して点検する必要がある。

APIキーが漏れたとき実際に何が起きるか

被害の形は権限設定によって大きく3段階に分かれる。自分のキーがどの段階にあるかを把握しておくことが、優先順位づけの出発点になる。

段階1: 参照権限のみのキーが漏れた場合

残高・取引履歴・注文履歴が第三者に読まれる。資産は動かない。ただし保有量やポジションの傾向が知られるため、SNSと紐づけられた場合の個人情報リスクは残る。損害額としては最小だが、「読めるだけだから安全」と放置するのは適切ではない。

段階2: 取引権限つきのキーが漏れた場合

第三者が勝手に発注・約定できる。出金はできないので資金は口座内に留まるが、板の薄い銘柄で不利な価格の売買を繰り返されると、口座内の資産価値が削られていく。取引所の外へ資金を出さずに損失だけを与える手口が成立するため、「出金権限を切っていれば無傷」とは言えない。実質的な損害は口座残高の相当割合に及び得る。

段階3: 出金権限つきのキーが漏れた場合

外部アドレスへ送金される。ブロックチェーン上の送金は取り消せないため、原則として回復しない。bot運用で出金権限が必要になる場面はほぼ存在しないので、ここは議論の余地なくオフにする。

権限構成	想定される最大被害	回復可能性	bot運用での必要性
参照のみ	保有状況の露見	資産被害なし	監視・集計botには十分
参照＋取引	不利約定による残高の目減り	一部は交渉余地あり	売買botに必要
参照＋取引＋出金	資産の全額流出	ほぼ不可	通常は不要

国内取引所のAPI権限設定を比較する

2026年7月時点で、国内主要取引所のAPIキーは「権限をどこまで細かく分けられるか」「IPアドレス制限をキー単位でかけられるか」に差がある。ここは記事執筆時点の公開情報にもとづく整理であり、仕様は変更され得るため、実際の発行画面で最新の選択肢を必ず確認してほしい。

取引所	権限の粒度	キー単位のIP制限	発行時の2段階認証	備考
GMOコイン	機能単位で個別選択（発行時に指定した機能のみ呼び出し可）	会員ページでIP制限機能を有効化して指定	必要	Private APIの呼出上限は段階的に緩和されてきた経緯がある
bitbank	参照系／更新系を分けて選択	公開情報では明確な提供の記載を確認できず	必要	外部サービス連携時は「参照のみ」を選ぶよう案内されている
bitFlyer	APIキー追加時に権限項目をチェックで選択	公開情報では明確な提供の記載を確認できず	必要	IPあたりのレート制限（分あたり約500回）は別途存在
Coincheck	パーミッションをチェックボックスで選択	発行・編集画面でIPアドレスを指定可能	必要	シークレットは発行時に一度しか表示されない

表から読み取れる実務的な結論は次の2つだ。

どの取引所でも「権限の最小化」は必ずできる。IP制限が使えなくても、権限を絞るだけで被害の上限は大きく下がる
IP制限が使える取引所では必ず使う。VPSの固定IPを登録すれば、鍵が漏れても攻撃者の環境からは呼び出せない

GMOコインとCoincheckのようにIP制限をキー単位で指定できる場合、そちらを優先的にbotの本番口座に充てる設計は合理的である。GMOコインでの具体的なAPI発行手順とエンドポイントの叩き方は /guides/gmocoin-api-trading にまとめている。

「シークレットは一度しか表示されない」の意味

発行画面を閉じるとシークレットは二度と表示されない取引所が多い。これは取引所側が平文で保持していない設計であることを示しており、セキュリティ上は望ましい。運用側の含意は、発行の瞬間に保管先を決めておく必要があるということだ。「とりあえずメモ帳に貼って後で整理する」という流れが、そのまま平文放置の温床になる。

実践手順: 安全なAPIキーを発行して運用に載せる7ステップ

ここからは実際の作業手順である。順番に意味があるので、飛ばさずに進めてほしい。

ステップ1: 保管先を先に決める

キーを発行する前に、どこに保管するかを決める。開発機なら .env ファイル、本番VPSなら環境変数またはOSのキーチェーン、チーム運用ならクラウドのシークレットマネージャ。この決定を後回しにすると、必ず一度は平文でどこかに貼ることになる。

ステップ2: bot専用のアカウント設計を確認する

可能であれば、bot用の口座と長期保有用の口座を分ける。同一取引所内で分けられない場合は、bot口座に置く資金量そのものを上限として管理する。APIキーで守るのではなく、そもそも触れられる金額を絞るという発想が最も確実な防御になる。

ステップ3: 権限を最小化してキーを発行する

各取引所の会員ページからAPIキー作成画面へ進み、必要な権限だけにチェックを入れる。判断基準は単純だ。

残高・価格の監視だけ → 参照のみ
発注する → 参照＋取引
出金 → 常にオフ

なお、IP制限まで含めてこの手順を素直に実行できるのはGMOコインである。API取引を前提に口座を用意するなら、権限とIP制限の両方を発行時に設定できる環境を選んでおくと後の運用が楽になる。

ステップ4: IP制限（ホワイトリスト）を設定する

botを動かすサーバーのグローバルIPアドレスを登録する。VPS上で次のコマンドを実行すれば自分のIPが確認できる。

# VPS のグローバル IP を確認する
curl -s https://api.ipify.org

自宅の回線からbotを動かす場合、ISPによってはIPが変動する。その場合はIP制限が実用にならないため、固定IPを持つVPSへ移すのが正攻法になる。VPSの選定と初期構築は /guides/crypto-bot-vps を参照してほしい。

ステップ5: 環境変数として保管し、コードから分離する

プロジェクト直下に .env を作る。

# .env （このファイルは絶対にコミットしない）
GMO_API_KEY=あなたのAPIキー
GMO_API_SECRET=あなたのAPIシークレット
BITBANK_API_KEY=あなたのAPIキー
BITBANK_API_SECRET=あなたのAPIシークレット

読み込み側のPythonコードは次のようにする。python-dotenv を使い、値が無い場合は起動時点で落とすのが要点だ。

# config.py
import os
from dotenv import load_dotenv

load_dotenv()  # プロジェクト直下の .env を読み込む


# 必須の環境変数を取得する。無ければ起動時に失敗させる
def require_env(name: str) -> str:
    value = os.getenv(name)
    if not value:
        raise RuntimeError(
            f"環境変数 {name} が設定されていません。.env を確認してください。"
        )
    return value


GMO_API_KEY = require_env("GMO_API_KEY")
GMO_API_SECRET = require_env("GMO_API_SECRET")


# ログ出力用に鍵をマスクする
def mask(secret: str) -> str:
    if len(secret) <= 8:
        return "*" * len(secret)
    return f"{secret[:4]}{'*' * (len(secret) - 8)}{secret[-4:]}"


if __name__ == "__main__":
    # 動作確認でもフル文字列は絶対に表示しない
    print("GMO_API_KEY:", mask(GMO_API_KEY))

print(api_key) でそのまま出力する癖は早めに捨てたい。ターミナルの履歴、CIのログ、スクリーンショット、画面共有——鍵が漏れる経路の多くは「デバッグのために表示した」ことに起因する。

ステップ6: `.gitignore` を整備する

.env をコミットしない仕組みを、意志ではなく設定で担保する。

# 認証情報
.env
.env.*
!.env.example
*.pem
*.key
credentials.json
secrets.yaml

# ローカル実行の副産物
__pycache__/
*.log
.venv/

.env.example だけはコミットして、必要なキー名を共有する。

# .env.example （値は空のまま。これはコミットしてよい）
GMO_API_KEY=
GMO_API_SECRET=
BITBANK_API_KEY=
BITBANK_API_SECRET=

さらに、コミット前に自動で検査する仕組みを入れるとより堅い。pre-commit を使う例を挙げる。

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: detect-private-key
      - id: check-added-large-files

pip install pre-commit
pre-commit install   # 以後、コミットのたびに自動検査が走る

ステップ7: ローテーションの周期を決めて記録する

発行日をメモし、周期を決めて作り直す。目安として、本番の取引権限つきキーは90日ごと、参照専用キーは180日ごと。加えて、次のイベント時は周期に関係なく即時ローテーションする。

開発端末を紛失・売却した
リポジトリを公開設定に変えた
外部の人にコードを渡した
依存パッケージに不審な更新があった

鍵の保管方法を比較する

保管方法には段階がある。自分の運用規模に合わないものを選ぶと、面倒さから形骸化するので、身の丈に合ったところから始めるのが正しい。

保管方法	導入コスト	平文で残るか	端末を奪われた場合	向いている規模
`.env` ファイル	非常に低い	残る（ディスク上に平文）	読まれる	個人・開発機
OSキーチェーン（Keychain / Credential Manager）	低い	残らない（OSが暗号化）	ログイン中なら読まれ得る	個人の本番運用
クラウドのシークレットマネージャ	中	残らない	アクセス権を即時失効できる	チーム・複数サーバー
ハードウェア隔離（署名を別端末で実行）	高い	残らない	鍵は端末外へ出ない	大口・法人

`.env` を使う場合の最低限の作法

.env は平文である。それでも実用に足るのは、以下を満たしている場合に限る。

# 所有者以外が読めないようにする（Linux / macOS）
chmod 600 .env
ls -l .env
# -rw------- 1 user user  512 Jul 21 10:00 .env

Windowsの場合は、ユーザープロファイル配下（他ユーザーからアクセスできない領域）にプロジェクトを置くことが実質的な最低ラインになる。共有PCや、他人がアカウントを持つマシンでの .env 運用は避けたい。

OSキーチェーンを使う場合

Pythonなら keyring パッケージで、OS標準の資格情報ストアを透過的に扱える。

# 保存（一度だけ実行する）
import keyring
keyring.set_password("cryptobot", "GMO_API_SECRET", "あなたのシークレット")

# 取得（bot 起動時）
secret = keyring.get_password("cryptobot", "GMO_API_SECRET")

ディスク上に平文ファイルが存在しなくなるため、.env の誤コミット・誤共有という事故そのものが消える。個人運用の本番環境ではここまで上げておく価値がある。

GitHubへの誤コミットを防ぐ・起きた後に消す

鍵の漏洩経路として最も報告数が多いのが、公開リポジトリへの誤コミットである。GitHubは既知のクレデンシャル形式を検知して push をブロックする Push Protection を提供しており、対象パターンは2026年にかけて継続的に拡張されている。ただしこれは万能ではない。取引所APIキーの多くは単なるランダム英数字であり、既知パターンとして登録されていない形式は検知されない。防御は自分の設定で完結させる必要がある。

誤コミットしてしまったときの最優先行動

順番が重要だ。

まず取引所の画面でキーを失効（削除）する。履歴の消去より先にこれをやる
新しいキーを発行し、権限とIP制限を設定し直す
そのうえでGit履歴からファイルを除去する
リモートへ強制 push し、共同作業者に再クローンを依頼する

「履歴から消したから大丈夫」は誤りである。公開リポジトリは自動収集の対象になっており、push された時点で読まれた前提で動くべきだ。失効が唯一の確実な対処になる。

Git履歴から機密ファイルを除去する

git filter-repo を使うのが現在の推奨である。

# 1. 必ずバックアップを取る
cp -r myrepo myrepo-backup

# 2. git-filter-repo を導入
pip install git-filter-repo

# 3. 履歴全体から .env を除去する
cd myrepo
git filter-repo --invert-paths --path .env --path config/secrets.yaml

# 4. リモートを再設定して強制 push
git remote add origin git@github.com:youraccount/myrepo.git
git push origin --force --all
git push origin --force --tags

実行後、共同作業者のローカルリポジトリは履歴が食い違うため、git pull ではなく再クローンしてもらう必要がある。この作業は履歴を書き換える不可逆な操作なので、必ずバックアップを取ってから行うこと。

直前のコミットだけを取り消したい場合

まだ push していない直近のコミットに含まれてしまっただけなら、履歴書き換えは不要だ。

# 直前のコミットからファイルを外す（変更内容は手元に残る）
git rm --cached .env
git commit --amend --no-edit

# 追跡対象から外れたことを確認
git ls-files | grep -c "^.env$"   # 0 なら OK

VPS・実行環境とアカウント本体の防御

鍵をどれだけ丁寧に保管しても、その鍵が置かれているサーバーに他人が入れるなら意味がない。24時間動くbotサーバーは、放置すると自動化されたログイン試行の的になる。

最低限やっておく設定

# 1. パスワード認証を無効化し、公開鍵認証のみにする
sudo sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

# 2. ファイアウォールで必要なポートだけ開ける
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

# 3. セキュリティ更新の自動適用（Ubuntu / Debian）
sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

# 4. 総当たりログインの遮断
sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

bot専用ユーザーで実行する

root でbotを動かさない。専用ユーザーを作り、そのユーザーのホーム配下にのみ鍵を置く。

sudo adduser --disabled-password --gecos "" botuser
sudo -u botuser mkdir -p /home/botuser/app
sudo chmod 700 /home/botuser

万一botのプロセスが乗っ取られても、影響範囲がそのユーザーの権限内に閉じる。

監視とアラートを併設する

不正な発注が始まったことに気づくまでの時間が、そのまま損失の大きさになる。約定数の急増や想定外の銘柄への発注を検知したら通知する仕組みは、セキュリティ施策として機能する。運用監視の具体的な組み方は /guides/trading-bot-monitoring にまとめている。

アカウント本体を守る: 2段階認証とパスキー

APIキーの手前にある取引所アカウント本体も守る必要がある。アカウントを乗っ取られれば、攻撃者が自分でAPIキーを発行できてしまうからだ。

SMS認証より認証アプリ、認証アプリよりパスキー

2段階認証の方式には強度差がある。

方式	フィッシング耐性	SIMスワップ耐性	推奨度
SMS ワンタイムコード	低い（偽サイトに入力させられる）	低い	他が使えない場合の次善策
認証アプリ（TOTP）	低い（同上）	高い	実用的な標準
パスキー / セキュリティキー	高い（ドメインに紐づくため偽サイトで動かない）	高い	対応していれば最優先

TOTPは「偽サイトに6桁を入力してしまう」攻撃を防げない。パスキーやFIDO2セキュリティキーは認証情報がドメインに紐づくため、偽ドメインでは原理的に成立しない。取引所が対応していれば、これを選ぶ意味は大きい。

フィッシング対策の実務

取引所へは必ずブックマークからアクセスする。検索結果の広告枠から入らない
「APIキーを再登録してください」というメールのリンクは踏まない。取引所がAPIシークレットを尋ねることはない
サポートを名乗る相手にシークレットを伝えない。正規のサポートがシークレットを聞くことは絶対にない
「あなたのbotを高速化します」「無料の裁定ツール」といった触れ込みでAPIキーの入力を求めるサービスに渡さない

この種の詐欺手口の見分け方は /guides/ai-trading-scam で個別に整理している。

鍵のローテーションと定期監査

一度作った鍵を作りっぱなしにしないための仕組み化である。手作業の記憶に頼ると必ず抜けるので、スクリプトに判定させる。

発行日を記録して期限を判定するスクリプト

# key_audit.py — 鍵の経過日数を点検する
import json
from datetime import datetime, timezone
from pathlib import Path

INVENTORY = Path("key_inventory.json")
# 権限に応じたローテーション周期（日）
POLICY = {"trade": 90, "read": 180}


# 台帳を読み、ローテーション期限を超えた鍵を数える
def audit() -> int:
    keys = json.loads(INVENTORY.read_text(encoding="utf-8"))
    today = datetime.now(timezone.utc).date()
    alerts = 0

    for key in keys:
        issued = datetime.fromisoformat(key["issued_at"]).date()
        age = (today - issued).days
        limit = POLICY.get(key["scope"], 90)
        status = "OK"
        if age >= limit:
            status = "ROTATE"
            alerts += 1
        elif age >= limit - 14:
            status = "SOON"
        print(f"{key['exchange']:<10} {key['scope']:<6} {age:>4}日 {status}")

    return alerts


if __name__ == "__main__":
    n = audit()
    print(f"\n要ローテーション: {n} 件")
    raise SystemExit(1 if n else 0)

対応する台帳ファイルは次の形式にする。ここに鍵そのものは書かない。書くのは「どの取引所の、どの権限のキーを、いつ発行したか」だけだ。

[
  {"exchange": "gmocoin", "scope": "trade", "issued_at": "2026-05-01", "ip_locked": true},
  {"exchange": "bitbank", "scope": "read",  "issued_at": "2026-02-10", "ip_locked": false}
]

cron に登録すれば、毎週自動で点検が回る。

# 毎週月曜 9:00 に点検して、要対応があれば通知を出す
0 9 * * 1 cd /home/botuser/app && /usr/bin/python3 key_audit.py || echo "APIキーのローテーション期限です"

ローテーションの手順を無停止で行う

いきなり旧キーを消すとbotが止まる。次の順序で入れ替える。

新しいキーを発行し、権限とIP制限を旧キーと同一に設定する
.env を書き換え、botを再起動して新キーで正常動作することを確認する
数時間から1日、エラーがないことを監視する
取引所の画面から旧キーを削除する

4番を忘れると、権限のある鍵が使われないまま残り続ける。これは実質的に放置された合鍵であり、ローテーションの意味が失われる。

他の手法との比較

対「.envに平文で置くだけ」の運用

.env 単体は導入が最も速く、個人開発では合理的な出発点である。弱点は、ディスク上に平文が残ることと、誤コミット・誤共有の事故が起こり得ること。これは chmod 600・.gitignore・pre-commit の3点セットでかなり潰せるため、「.env が危険」なのではなく「.env を裸で使うのが危険」と理解するのが正確だ。単一サーバーで自分だけが運用するなら、対策込みの .env は現実的な選択肢である。

対クラウドのシークレットマネージャ

AWS Secrets Manager や Google Secret Manager などを使うと、鍵をディスクに置かず、アクセス権を中央で即時失効でき、参照履歴も残る。複数サーバー・複数人の運用では明確に優位である。一方で、クラウド側の認証情報（IAMロールやサービスアカウント鍵）を管理する必要が生じ、守るべき対象が別のレイヤーへ移動するだけになる場合もある。個人でVPS1台なら、追加の複雑さに見合わないことが多い。チーム化やサーバー増設のタイミングで移行するのが素直な判断になる。

対ハードウェア隔離（署名を別端末で実行）

鍵を専用のハードウェアに封じ込め、署名処理だけを行わせる方式。鍵が端末外へ出ないため理論上は最も堅い。ただし取引所のREST APIはHMAC署名が前提で、ハードウェア署名モジュールとの相性が良いとは言えず、実装コストが跳ね上がる。運用資金が大きく、専任で管理できる体制がある場合の選択肢であり、個人のbot運用で最初に検討すべきものではない。

対「取引所側の権限制御だけに任せる」運用

「出金権限を切ってあるから保管は雑でよい」という考え方は、被害段階2（不利約定による残高の目減り）を見落としている。権限制御は被害の上限を下げる施策であり、被害の発生確率は下げない。保管とIP制限は発生確率を下げる施策で、両者は代替関係ではなく補完関係にある。片方だけで済ませないことが要点だ。

リスクと注意点

2026年7月時点で、bot運用者が現実に踏みやすい落とし穴を優先度順に並べる。

出金権限つきキーの流出: 最も損害が大きく、回復もほぼ不可能。bot用途で出金権限が要る場面は通常ないため、発行時に必ずオフにする
GitHubへの誤コミット: 公開リポジトリは自動収集の対象になっている。Push Protection は既知パターンにしか効かず、取引所キーの多くは検知対象外。.gitignore と pre-commit で自前に防ぐ
VPSの踏み台化: パスワード認証を残したSSH、開けっぱなしのポート、放置された古いパッケージ。侵入されれば .env は読まれる。root実行を避け、専用ユーザーに閉じる
フィッシングサイトへのキー入力: 「連携すると自動で利益が出る」といった触れ込みでシークレットを入力させる手口が続いている。正規のサービスがAPIシークレットを求めることはない
依存パッケージのサプライチェーン: 名前が酷似したパッケージや、乗っ取られたメンテナアカウント経由の悪意ある更新で、環境変数が外部送信される事例がある。pip install の対象名を毎回確認し、requirements.txt はバージョンを固定する
ログとスクリーンショットへの露出: デバッグ出力、CIのログ、画面共有、SNS投稿。マスク関数を通していない出力が最も多い漏洩経路のひとつ
旧キーの放置: ローテーション時に新キーだけ追加して旧キーを消さないと、権限のある鍵が管理外で生き続ける
IP制限の過信: IP制限は強力だが、同じサーバーが侵害された場合は無力である。保管の暗号化・権限の最小化と組み合わせて初めて意味を持つ
バックアップ経路からの漏洩: サーバーのスナップショットやローカルのバックアップに .env が含まれていることを忘れがち。バックアップ先の権限も同じ基準で扱う

なお、botの設定ミスや相場急変によるドローダウンはセキュリティとは別のリスクである。運用そのもののリスク管理は /guides/ai-trading-risk、実装上の失敗パターンは /guides/trading-bot-failure で扱っている。

まとめと本番投入前チェックリスト

本番投入前のセキュリティ点検チェックリスト

botに実資金を触らせる前に、以下をすべて確認する。ひとつでも未チェックなら、資金を入れる前に潰しておきたい。

APIキーの出金権限がオフになっている（取引所の画面で目視確認した）
使う機能に必要な権限だけにチェックが入っている（参照のみで足りるbotに取引権限を与えていない）
IP制限が使える取引所では、botサーバーのグローバルIPを登録した
.env が .gitignore に含まれ、git ls-files に出てこないことを確認した
.env のパーミッションが 600 になっている
コード内に鍵をそのまま出力する print / logger.info が残っていない
取引所アカウントに2段階認証（できればパスキー）を設定した
SSHのパスワード認証を無効化し、ファイアウォールで不要ポートを閉じた
botをroot以外の専用ユーザーで実行している
鍵の発行日を台帳に記録し、ローテーション周期を決めた
まず少額で稼働させ、想定外の発注が起きないことを確認する計画になっている

なお、当サイトでは実際にAIによる自動売買を運用しており、その日次の損益推移は /ai-trading で公開している。上記の設定を実運用の前提として組んだうえでの記録である。

結論: 着手する順番を間違えない

仮想通貨botのAPIキーセキュリティは、突き詰めると「権限を絞る」「場所を絞る」「保管を分ける」「定期的に作り直す」の4点に集約される。順序としては、出金権限をオフにする（被害上限を下げる）、IP制限をかける（発生確率を下げる）、.gitignore と pre-commit を入れる（最頻の漏洩経路を塞ぐ）の3つを先にやれば、リスクの大部分は削れる。

2026年7月時点で、国内取引所のAPIキーはいずれも権限の最小化に対応しており、GMOコインやCoincheckのようにIP制限まで指定できるところもある。まずは自分が今使っているキーの権限画面を開いて、出金にチェックが入っていないかを確認するところから始めてほしい。そのうえでローテーションの周期を決め、台帳に記録すれば、運用は仕組みとして回り始める。

コードの品質を上げるのは後からでもできるが、鍵が流出した後の回復はできない。着手の順番を間違えないことが、bot運用を長く続けるための条件になる。

よくある質問 (FAQ)

仮想通貨botのAPIキーに出金権限は必要ですか？

通常は不要です。botが行うのは残高照会と発注・キャンセルであり、外部アドレスへの送金は人間が手動で行えば足ります。出金権限つきのキーが流出するとブロックチェーン上で送金され、取り消しができません。発行画面で出金にチェックを入れないことが、最も費用対効果の高い防御になります。

取引所のAPIキーにIP制限をかけられますか？

2026年7月時点で、GMOコインは会員ページでIP制限機能を有効にすることでAPI呼び出し元のIPを制限でき、CoincheckもAPIキーの発行・編集画面で許可IPを指定できます。bitbankやbitFlyerについては公開情報でキー単位のIP制限の提供を明確には確認できませんでした。実際の設定可否は発行画面で最新の選択肢を確認してください。

APIキーをGitHubに誤ってコミットしてしまいました。何から手を付けるべきですか？

最優先は取引所の画面でそのキーを削除・失効させることです。公開リポジトリは自動収集の対象になっているため、pushされた時点で読まれた前提で動くべきです。失効後に新しいキーを権限最小化とIP制限つきで再発行し、そのうえでgit filter-repoなどで履歴からファイルを除去する順序が安全です。

.envファイルに秘密鍵を置くのは危険ではないですか？

.env自体は平文なので、裸で使うと危険です。ただしchmod 600でパーミッションを絞り、.gitignoreに追加し、pre-commitで検査を自動化すれば、個人のVPS1台運用では実用的な水準になります。より安全性を上げたい場合はkeyringでOSの資格情報ストアに移し、ディスク上の平文をなくす方法があります。

出金権限をオフにしていれば、キーが漏れても資産は無事ですか？

資金が取引所の外へ出ることは防げますが、無事とは言えません。取引権限が残っていれば第三者が勝手に発注でき、板の薄い銘柄で不利な価格の売買を繰り返されると口座内の資産価値が削られます。出金権限のオフは被害の上限を下げる施策であり、IP制限や鍵の適切な保管と組み合わせる必要があります。

VPSで自動売買botを動かすとき、最低限どんなセキュリティ設定が必要ですか？

SSHのパスワード認証を無効化して公開鍵認証のみにする、rootログインを禁止する、ufwなどのファイアウォールで必要ポートだけ開ける、セキュリティ更新を自動適用する、fail2banで総当たりを遮断する、の5点が基本です。加えてbotはroot以外の専用ユーザーで実行し、鍵をそのユーザーのホーム配下に閉じ込めます。

2段階認証はSMSと認証アプリのどちらを使うべきですか？

SMSはSIMスワップの影響を受けるため、認証アプリ（TOTP）のほうが安全です。ただしTOTPも偽サイトにコードを入力させる攻撃は防げません。取引所がパスキーやFIDO2セキュリティキーに対応している場合は、認証情報がドメインに紐づくためフィッシング耐性が高く、こちらを優先するのが合理的です。

APIキーはどのくらいの頻度で作り直すべきですか？

目安として、取引権限つきの本番キーは90日ごと、参照専用キーは180日ごとです。周期に関係なく、端末の紛失・売却、リポジトリの公開設定変更、外部へのコード共有、依存パッケージの不審な更新があった場合は即時ローテーションします。入れ替え後に旧キーを削除するところまでが手順に含まれます。

この記事の内容は投資助言にあたりますか？

いいえ。本記事はAPIキーの管理方法に関する技術的・運用的な情報提供であり、特定の暗号資産の売買や投資判断を推奨するものではありません。暗号資産の取引には価格変動リスクやシステムリスクが伴います。取引所の仕様は変更され得るため最新の公式情報を確認し、税務や法務の判断が必要な場合は専門家に相談してください。

仮想通貨bot APIキーセキュリティ自動売買 AIトレード GMOコイン bitbank bitFlyer Coincheck IP制限出金権限 python-dotenv gitignore VPS 2段階認証パスキーフィッシング対策鍵のローテーションシークレット管理 API取引