DEX上で動くAIエージェントとは、相場データの取得・LLMによる状況判断・発注という一連の作業を自律的に繰り返すプログラムのことです。中央集権型取引所と違って口座審査を待つ必要がなく、ウォレットを接続すればすぐにAPIを叩けるため、DEXはAIエージェントの実験場として選ばれやすい環境になっています。ただし「作れる」ことと「安全に、かつ資金を守りながら運用できる」ことの間には大きな距離があります。この記事では、設計思想から実装の骨格、秘密鍵の権限設計、やってはいけない失敗例までを、実運用で得られた知見を交えて整理します。
AIエージェントによるDEX自動売買とは
一般的なbotは、あらかじめ決めた条件式(移動平均線のゴールデンクロスで買う、など)を淡々と実行するだけの仕組みです。これに対してAIエージェントは、相場データに加えてニュースやオンチェーン指標などの非構造化情報もLLMに読ませ、その都度「なぜそう判断したか」を言語化させながら発注可否を決めます。判断の根拠が言語化される分、後から検証しやすいという利点がありますが、同時に「もっともらしい理由」でリスク管理ルールを逸脱してしまう危険も持ち合わせています。この二面性を理解した上で設計に入ることが出発点です。
「AIエージェントに任せれば人間より賢く儲かる」という期待を持って着手すると、最初のドローダウン(含み損の拡大)で運用をやめてしまいがちです。実際には、AIエージェントが優れているのは判断の速さと一貫性であり、相場そのものを予測する力が人間より飛躍的に高いわけではありません。この記事で紹介する設計思想は、「儲かる魔法のロジック」ではなく、「資金を大きく減らさずに検証を続けられる構造」を作ることに主眼を置いています。
できることと限界
過度な期待を持ったまま着手すると、最初のドローダウンで運用をやめてしまいがちです。着手前に、AIエージェントで現実的にできることと、できないことを整理しておきます。この表を最初に頭に入れておくだけで、後述する設計判断の多くが「なぜそうするのか」まで含めて理解しやすくなります。
| 項目 | できること | 限界 |
|---|---|---|
| 情報処理 | ニュース・オンチェーン指標・価格データを横断的に読み込み、判断材料として整理する | 一次情報の真偽そのものを検証する能力は無い。誤情報を前提にすると誤判断につながる |
| 判断速度 | 24時間、人間より高速かつ一貫した基準で判断できる | 相場の急変や薄商いでの異常値には脆弱で、想定外の値動きへの対応力は限定的 |
| 実行 | 決めたルール通りに感情を挟まず発注・決済できる | ルール自体の質が悪ければ、機械的に同じ失敗を繰り返す |
| 記録 | 判断根拠を毎回言語化してログに残せる | ログを分析し戦略を改善するのは依然として人間の役目 |
全体アーキテクチャ：4つのレイヤーで考える
AIエージェントを一枚岩のプログラムとして書き始めると、後から安全機構を差し込むのが難しくなります。最初から4つのレイヤーに分けて設計すると、テストと権限管理がしやすくなります。
データ層
価格・板情報・出来高などのマーケットデータと、必要であればニュースやオンチェーンの資金フローを取得する層です。ここは認証も資金も不要なので、検証段階から気兼ねなく試行錯誤できます。この層で取得したデータは、後述する判断層の出力を検証するための「客観的な事実」としても使うため、判断層より先に、単独で正しく動く状態まで作り込んでおくのが得策です。
判断層（LLM）
取得したデータをもとに、LLMが「エントリーする／しない／決済する」を判断し、根拠をテキストで出力する層です。判断はあくまで「提案」であり、次の実行層に渡る前に必ず検査を通します。判断層単体では資金を動かさないため、この層だけを先に動かして「LLMがどんな根拠でどんな判断をするか」を、実弾を投じる前にログとして貯めておくことができます。
実行層
判断層からの提案を受け取り、コード側で固定したリスクルールに照らして問題なければ発注する層です。ここにこそ人間が決めた不可侵のルールを置きます。LLMにはこの層のルールを変更する権限を持たせません。実行層は最後に実装する部分であり、データ層・判断層が十分に検証できてから資金に触れさせるという順番を守ることが、事故を減らす一番の近道です。
監視層
ポジションの状態・エージェントの生存確認・異常検知を行い、問題があれば通知を飛ばす層です。実務上、開発の優先順位が最も低く見られがちですが、静かに壊れるbotに気づく唯一の手段なので、判断層より先に作ってもよいくらい重要です。エラーで停止した、ポジションを持ったまま応答が無くなった、API呼び出しが連続で失敗している、といった異常を検知したら、即座に通知が届く経路を確保してください。
判断層（LLM）の設計
プロンプト設計の基本
判断層のプロンプトには、相場データだけでなく「今回のエントリー根拠」「無効化される条件」「確信度」を毎回出力させる形式にします。これによって、後から見返したときに「そのとき何を考えて発注したか」を再現できます。自由記述だけにすると出力形式がぶれるため、項目を固定したテンプレートで出力させるのが安全です。以下は、そのまま流用できる出力フォーマットの例です。
【エントリー判断フォーマット】
- 銘柄:
- 方向(ロング/ショート/様子見):
- 根拠(価格・出来高・直近のニュース等から具体的に):
- 無効化ライン(この価格を超えたら判断が誤りだったと言える水準):
- 確信度(1〜5):
- このまま発注してよいか(はい/いいえ、理由):
このフォーマットを守らせることで、後から「勝っていた判断パターン」「負けていた判断パターン」をログから分類・分析できるようになります。判断根拠を残さないまま数十件・数百件と発注を重ねても、「増えた／減った」という結果しか手元に残りません。
判断ループの頻度設計
判断層をどのくらいの頻度で回すかも設計上の重要な選択です。数分おきに判断させると相場の変化に素早く反応できますが、その分LLMの呼び出し回数が増えてAPI利用料がかさみ、ノイズの多い値動きに反応して余計な発注をしてしまうリスクも上がります。逆に数時間おきにすると反応は遅くなりますが、コストを抑えられ、短期的なノイズに振り回されにくくなります。どちらが正しいかは戦略の性質によるため、まずは頻度を落として検証し、必要に応じて上げていくのが安全な進め方です。
確信度の扱い方
実運用で興味深かったのは、LLMに出させた確信度のスコアが、勝率そのものとは相関しなかったという結果です。一方で、確信度は損益の大きさとは相関する傾向が見られました。つまり「確信度が高いから勝てる」わけではなく、「確信度が高いときは勝っても負けても値幅が大きくなりやすい」という性質として扱うべきだということです。確信度をエントリーの可否ではなく、建玉サイズの調整に使う設計の方が実態に合っています。
ハルシネーション対策
LLMは存在しないニュースや誤った価格水準をもっともらしく語ることがあります。判断層の出力を鵜呑みにせず、価格や指標などの数値部分はデータ層から取得した実測値で必ず上書き・検証する処理を挟んでください。LLMの役割は「解釈」であり「事実の生成」ではない、という線引きを実装レベルで徹底することが事故の予防になります。
秘密鍵と権限設計
なぜ権限分離が最重要事項なのか
AIエージェントのプログラムに、資産を保有するメインウォレットの秘密鍵をそのまま持たせるのは避けるべきです。24時間稼働するサーバーが侵害された場合、鍵が漏れた瞬間に資産全体を失うことになります。
エージェントウォレットという仕組み
多くのオンチェーンDEXでは、取引の実行だけを許可し出金の権限を持たない「エージェントウォレット」という仕組みが使えます。手順としては、(1)エージェント専用の鍵ペアを別途生成する、(2)メインウォレットからそのエージェントに取引権限だけを委任する、(3)プログラムにはエージェントの鍵だけを持たせる、という3段階です。この構成なら、鍵が漏れた場合の最悪ケースが「勝手に売買される」で止まり、「資産を外部に抜かれる」までは進みません。
鍵が漏洩した場合の被害範囲を具体的に考える
権限分離の効果を実感するために、被害範囲を具体的に比較します。メインウォレットの鍵をそのまま持たせていた場合、サーバー侵害と同時に証拠金の全額を任意のアドレスへ送金されるおそれがあります。一方、エージェントウォレットの鍵しか持たせていない場合、攻撃者にできることは「不利な条件で売買を繰り返させる」までにとどまり、証拠金そのものを盗み出すことはできません。もちろん被害はゼロではありませんが、「資産を完全に失う」のと「一部の含み損で被害が止まる」のとでは、事故の深刻度がまったく異なります。この差を理解した上で、権限設計を後回しにしないでください。
コピペで使えるリスク検査の骨格
発注関数の手前に必ず置くべき検査項目を、そのまま使えるチェックリストとして掲載します。実装言語は問いません。
# 発注前リスク検査（このチェックを全て通過しない限り発注しない）
- [ ] 同一銘柄で既にポジションを持っていないか
- [ ] 今回の建玉が証拠金の一定割合(例: 5%)を超えていないか
- [ ] レバレッジがコードで固定した上限を超えていないか
- [ ] エントリーと同時に無効化ライン(損切り水準)を設定できているか
- [ ] 直近1時間の約定エラー回数が閾値を超えていないか
- [ ] APIやLLM呼び出しが例外を返した場合、新規発注だけを止め、既存ポジションの監視は継続しているか
やってはいけないこと・失敗しやすいパターン
売り込みの前に、失敗例を先に共有します。実際に検証を重ねる中で見えてきた、やってはいけない設計です。
メインウォレットの秘密鍵をそのままエージェントに持たせる。 サーバー侵害時の被害が資産全損に直結します。必ず権限を絞った鍵を使ってください。
LLMの判断をそのまま発注に直結させる。 リスク検査を挟まないと、もっともらしい理由でルールを逸脱した発注が通ってしまいます。
極端に少ない証拠金で検証する。 オンチェーンの決済コストに利益を食われ、戦略が良いのか悪いのか判定できないまま資金と時間だけが減ります。
確信度だけでポジションサイズを大きく変える。 確信度は損益の値幅とは相関しても勝率とは相関しないため、確信度に応じてレバレッジまで引き上げるのは損失を拡大させるリスクがあります。
通知・監視の仕組みを後回しにする。 botはエラーで止まっても、ポジションを持ったまま固まっても、自分からは教えてくれません。稼働開始前に必ず通知経路を作ってください。
バックテストの好成績を鵜呑みにする。 過去データに最適化されたパラメータは、探せばいくらでも見つかります。実運用の値動きは過去と同じ形では繰り返しません。
サンプル数が少ないうちに戦略を確信する。 数十件のトレードで勝率が高かったとしても、それが偶然の範囲を超えているとは限りません。少なくとも数十件〜百件単位のサンプルが貯まるまでは、結論を急がないことが重要です。
対応DEXの選び方
AIエージェントを載せるDEXは、板の方式・手数料・レバレッジ上限・bot開発のしやすさで選びます。代表的な3つを比較します。
| DEX | 取引方式 | レバレッジ上限 | bot開発のしやすさ |
|---|---|---|---|
| Hyperliquid | 独自L1上のフルオンチェーン・オーダーブック方式 | 最大50倍 | 公式Python SDKがあり、署名処理を自前実装しなくて済む |
| GMX | オラクル価格を参照するプール型(GLP/GM)、ゼロスリッページが特徴 | 銘柄により異なる | プール型のためオーダーブックの板読みロジックが不要。仕組みが異なる分、戦略設計の考え方を変える必要がある |
| dYdX | オーダーブック方式のPerp専業DEX | 最大20倍 | 日本語を含む多言語対応。オーダーブック型のロジックはHyperliquidと近い考え方が使える |
対Hyperliquid
独自L1上でフルオンチェーンのオーダーブックを動かしており、テイカー0.045%・メイカー0.015%という手数料水準はCEXに近く、AIエージェントが板を読んで指値を刺す戦略との相性が良い設計です。公式のPython SDKが署名やnonce管理を面倒見てくれるため、実装コストが低い点も選ばれる理由です。約70ミリ秒というファイナリティの速さもCEXに近く、高頻度に近い判断ループを組みたい場合の候補になります。
対GMX
Arbitrum・Avalanche上で稼働し、GLP／GMという流動性プールがカウンターパーティになる仕組みです。オーダーブックを読む必要が無い代わりに、価格変動に対するプール側のインセンティブ構造を理解しておく必要があります。板読み戦略よりも、トレンド追随や裁定的な戦略に向いた設計です。V2で導入されたGMトークンはアイソレート市場ごとに分かれており、銘柄ごとにリスクを切り分けたい場合に扱いやすい構造になっています。
対dYdX
Perpetual取引に特化したオーダーブック型のDEXで、日本語を含む多言語UIに対応しています。レバレッジ上限はHyperliquidより低めですが、オーダーブックのロジックはHyperliquid向けの戦略設計と考え方を流用しやすい構成です。日本語UIがある分、相場データやドキュメントを確認する際の負担が小さいという実務上のメリットもあります。
どのDEXを選ぶ場合でも、まずはtestnet(テスト環境)が用意されていればそこで発注ロジックを一通り動かし、実弾を投じるのは最後にする順番を徹底してください。オンチェーンの取引はいったん発注すると取り消しが難しいものも多く、テスト不足のまま本番に進むと小さなバグが実損に直結します。
コストを実額で見る
AIエージェントの運用には、売り込み材料になりがちな「儲かる話」の裏で、必ずかかる実額のコストがあります。着手前に把握しておくべき項目を整理します。
取引手数料: Hyperliquidの場合、テイカー0.045%・メイカー0.015%です。1回100USDT分の建玉をテイカー注文で往復させると、往復で約0.09USDT(約13〜14円、1USDT=150円換算)のコストがかかります。1日に何度もエントリーとイグジットを繰り返す高頻度な戦略では、この積み重ねが利益を圧迫します。
ガス代(オンチェーン手数料): DEXの種類やチェーンの混雑状況によって変動しますが、発注・決済のたびに数円〜数十円のガス代が発生する場合があります。Hyperliquidのように独自L1でガス代を低く抑えている設計もあれば、Ethereum本体のように混雑時に手数料が跳ね上がるチェーンもあり、どのチェーン上で動くDEXかによってコスト構造が大きく変わります。
LLM API利用料: 判断層でLLMを1回呼び出すたびに、モデルとトークン数に応じたAPI利用料がかかります。24時間・数分おきに相場を判断させる構成にすると、月間のAPI利用料が数千円〜数万円規模になることも珍しくありません。判断の頻度を上げるほど反応は速くなりますが、コストも比例して増える点は事前に見積もっておくべきです。
サーバー・インフラ費用: 24時間稼働させるVPSやクラウドサーバーの費用が、月額で数百円〜数千円程度かかります。小さな金額に見えますが、少額の証拠金で運用している場合はこのランニングコストだけで利益を上回ることもあります。
これらのコストを合計すると、極端に小さい証拠金・極端に高頻度な判断ループでは、戦略が正しくてもコスト負けする構造になりやすいことが分かります。検証を始める前に、想定する取引頻度でひと月あたりのコストを概算しておくことを強く勧めます。目安として、取引手数料・ガス代・API利用料・サーバー費用を合算した「固定費+変動費」を、検証に投じる証拠金の何パーセントに相当するかで見積もると、資金規模が適切かどうかを判断しやすくなります。
具体的なユースケース
AIエージェントの活用は「エントリーとイグジットの全自動化」だけではありません。実務でよく使われる構成を3パターン紹介します。
パターン1: 判断だけを自動化し、発注は人間が承認する
LLMが「今のエントリー案」を通知だけしてくれて、実際の発注ボタンは人間が押す構成です。資金を完全に機械へ預けることに抵抗がある場合、最初のステップとしてこの半自動構成から始める方法があります。事故のリスクを抑えつつ、LLMの判断の質を実弾で検証できます。
パターン2: リスク検査だけを自動化し、エントリー判断は人間が行う
逆に、エントリーそのものは人間が判断し、「無効化ラインを守っているか」「証拠金比率が上限を超えていないか」といったリスク管理だけをプログラムに任せる構成です。人間の判断力を活かしつつ、感情によるルール逸脱を機械的に防げます。
パターン3: 完全自律型のエージェント
判断からリスク検査、発注、決済まで全てを自律的に行う構成です。最も実装コストが高く、事故が起きたときの被害も大きくなりやすいため、パターン1・2で十分な検証を積んでから移行するのが安全な順序です。
資金の持ち込み方
DEXで取引するには、まず証拠金となる暗号資産をオンチェーンのウォレットに用意する必要があります。日本国内の取引所から直接DEXへ送れないケースが多いため、実務上は次の流れになります。
- 国内の取引所で日本円を暗号資産に換える
- 国内取引所で口座を持った上で、海外取引所にも口座を開設する
- 海外取引所からオンチェーンのウォレットへ出金する
- そのウォレットをDEXに接続する
中継に使う海外取引所は、対応チェーンと出金手数料で選ぶのが実務的です。同じ銘柄でもチェーンによって手数料が数十倍変わることがあり、ここを間違えると検証を始める前に資金が目減りします。中継先の候補としては、コピートレードやAPI取引に対応しているBitgetのような取引所が実務での選択肢になります。海外取引所は日本の金融庁への登録を受けていない場合があるため、無登録業者リスク・出金リスクを理解した上での利用になります。
なお、この資金導線は一度作ってしまえば検証のたびに繰り返し使えます。最初の送金経路を確立する段階でつまずくと、その後の戦略検証そのものに着手できなくなるため、AIエージェントのコードを書き始める前に、資金導線の確認を済ませておくことをおすすめします。国内取引所での口座開設・本人確認には数日かかることもあるため、着手の順番としてはむしろ早めに動いておく部類の作業です。
リスクと注意点
AIエージェントによるDEX自動売買には、次のようなリスクが伴います。着手前に必ず目を通してください。
- 秘密鍵・APIキーの漏洩リスク: サーバー侵害時に資産へアクセスされる可能性がある。権限を絞ったエージェントウォレットを使っていても、リスクがゼロになるわけではない
- スマートコントラクトのリスク: DEX自体のコードに脆弱性があれば資産が影響を受ける可能性がある。監査済みかどうか、稼働実績の長さを事前に確認する
- 強制ロスカット(清算)のリスク: レバレッジをかけている以上、想定を超える値動きで証拠金以上の損失を防ぐ清算が発動する。清算価格を常に把握できる設計にしておく
- LLMの誤判断リスク: もっともらしい理由で誤った発注を行う可能性があり、コード側の検査が唯一の歯止めになる。判断層の出力を無条件に信用しない
- 流動性リスク: 薄商いの銘柄では想定した価格で約定しない、あるいは大きなスリッページが発生する。出来高の少ない時間帯・銘柄は建玉を絞る
- 無登録業者リスク: 海外の取引所・DEXは日本の金融庁に登録されていない場合があり、国内の補償制度の対象外になる。利用は自己責任が前提になる
- 通信・稼働環境のリスク: サーバー障害や回線断で監視が止まると、ポジションを持ったまま無防備な状態が続く。稼働環境の冗長化も検討に値する
- 過学習(オーバーフィッティング)のリスク: 過去データに最適化しすぎた戦略は将来の相場で機能しないことが多い。バックテストの好成績を過信しない
- 税務リスク: 取引回数が多くなるため損益計算が煩雑になりやすく、確定申告の準備を怠ると後々の負担が大きくなる。専門家への相談を早めに検討する
実装前に確認するチェックリスト
設計から実装に移る前に、次の項目を満たしているか確認してください。
- メインウォレットの秘密鍵ではなく、権限を絞ったエージェントウォレットの鍵をプログラムに持たせている
- 発注関数の手前に、コード側で固定したリスク検査(建玉上限・レバレッジ上限・無効化ライン)を必ず通す構造になっている
- 判断層(LLM)の出力を実行層がそのまま信用せず、数値部分はデータ層の実測値で検証している
- 想定する取引頻度でのAPI利用料・ガス代・手数料を月額換算で見積もっている
- 稼働停止・約定エラー・想定外の例外が起きたときに通知が届く仕組みを用意している
まとめ
AIエージェントによるDEX自動売買は、「データ層・判断層・実行層・監視層」に分けて設計し、判断層(LLM)の出力を鵜呑みにせず、実行層に固定のリスクルールを置くことが安全性の核になります。秘密鍵はエージェントウォレットで権限を分離し、記録の仕組みをロジックより先に作る。この順番を守ることで、事故の被害を限定しながら検証を積み重ねられます。
始めやすさと勝ちやすさは別物であり、確信度の高い判断が必ずしも高勝率を意味しない、という実運用の知見を踏まえて設計を進めてください。コストの見積もりを怠らず、パターン1・2のような半自動構成から始めて判断の質を検証し、十分な手応えを得てから完全自律型へ段階的に移行する。この順序が、資金を守りながらAIエージェントの自動売買を育てていく上で、結局いちばん近道になります。
技術的な実装力があれば、AIエージェントの構築自体は決して手の届かない領域ではありません。むしろ差がつくのは、コードの巧拙よりも「権限をどう分離するか」「リスク検査をどこに固定で置くか」「記録をどう残すか」という設計の地味な部分です。派手なロジックよりも、この地味な設計に時間をかけることが、長く運用を続けられるAIエージェントを作る一番の近道です。
本記事は情報提供を目的としたものであり、投資助言ではありません。暗号資産の証拠金取引は元本を失う可能性があります。海外の取引所・DEXは日本の金融庁への登録を受けていない場合があります。税務の取り扱いについては専門家にご相談ください。利用は自己責任でご判断ください。
<!-- INTERNAL_LINKS_RELATED -->
関連記事
<!-- INTERNAL_LINKS_RELATED -->