Claude Codeによる仮想通貨の自動売買とは、Anthropic社のAIエージェント「Claude Code」に取引戦略の実装・改善・執行までを任せ、人間は方針決定と監視だけを行うトレード運用のことです。編集部は2026年4月からこの構成を実口座で運用してきました。結論を先に言うと、3か月の実現損益は約-21ドル。破産はしないが儲かってもいない、というのが正直な数字です。本記事では、この「地味な現実」に至るまでの設定値・失敗・改善のすべてを、盛らずに時系列で公開します。
なお本記事は成果を誇る記事ではなく、AIエージェントにトレードを任せると実際に何が起きるかの検証記録です。最新の運用成績は運用実績ページで随時更新しています。
この検証を始めた動機は2つあります。1つは、生成AIの進化で「コードを書けるAIに運用を任せる」ことが技術的に現実になり、実際どこまで通用するのかを自分の資金で確かめたかったこと。もう1つは、SNSで見かける「AIで自動売買、月利◯◯%」という類の発信に一次データで反証（あるいは裏付け）を示したかったことです。結果はご覧の通り、少なくとも編集部の3か月では「月利◯◯%」の世界は現れませんでした。ただし、それを上回る価値のある知見が残ったと考えています。この記事を読めば、同じ回り道を踏まずに済むはずです。
何をやったのか: 運用構成の全体像
構成はシンプルです。Windows PC上のタスクスケジューラが毎朝6時にClaude Codeのセッションを起動し、セッションは翌朝まで約24時間、相場の監視・エントリー判断・決済・ログ記録を自律的に行って自己終了します。翌朝はまた新しいセッションが起動し、前日の引き継ぎメモを読んで運用を継続します。
- AIエージェント: Claude Code。戦略ロジックのコード実装・バグ修正・パラメータ調整も自分で行う
- 取引の場: オンチェーンDEX（GMX）のパーペチュアル（無期限先物）取引
- 対象銘柄: ETH・BTC系を中心とした主要銘柄
- 人間の役割: 資金の入出金、方針の承認、日次ログの確認
ポイントは、Claude Codeが「注文を出すだけのbot」ではなく、損益を見て自分の戦略コードを書き換える改善ループの主体であることです。従来のbot運用では人間がやっていた「検証→修正→再デプロイ」を、AIが日次で回します。
セッションの1日の流れ
運用中のセッションが実際にやっていることを時系列で書くと、次のようになります。朝6時、タスクスケジューラがClaude Codeを起動し、前日セッションが残した引き継ぎメモ（保有建玉・直近の損益・注意事項）を読み込みます。日中は一定間隔で価格・出来高・資金調達率などを取得し、モード判定（レンジかトレンドか）を更新しながらエントリー条件の成立を監視します。条件が成立すればサイズとレバレッジを計算して発注し、建玉があればトレーリングストップの追従と決済条件の監視を続けます。深夜も同様に監視を継続し、翌朝5時台に当日の全取引と損益をログにまとめ、翌日セッションへの引き継ぎメモを書いて自己終了します。
人間が見るのはこの引き継ぎメモと損益ログだけです。1日あたりの確認時間は5分程度で、「発注は通っているか」「異常なエラーが出ていないか」「損益が想定レンジ内か」の3点だけをチェックします。
なぜDEX（オンチェーン）を選んだか
取引の場としてオンチェーンDEXを選んだ理由は、APIキーの発行や取引所の審査なしにプログラムから直接取引でき、すべての約定がブロックチェーン上に残るため損益の検証がごまかしようがないからです。本記事の損益数値も、このオンチェーン記録を突き合わせて確定させたものです。一方で後述の通りガス代という固有のコストがあり、これが今回の運用の最大の教訓になりました。中央集権取引所のAPIで同じ構成を組むことも可能で、その場合の取引所選びと設定は別記事で扱います。
運用ルール: 実際の設定値を公開
2026年7月時点の基本設定は次の通りです。
| 項目 | 設定値 |
|---|---|
| レバレッジ | 10倍 |
| 利確目標 | 建玉比 +3.5% |
| 損切り | 建玉比 -4.5%（トレーリングストップ併用） |
| エントリー方式 | モード判定式（レンジ相場=端でのフェード / トレンド相場=押し目） |
| 建玉サイズ | 400ドル以上（後述の理由で下限を設定） |
| 監視体制 | 日次セッション（毎朝6時起動→翌朝自己終了）による24時間監視 |
エントリーは「今がレンジ相場かトレンド相場か」をまず判定し、レンジならレンジ上限・下限での逆張り、トレンドなら押し目での順張りという2モードを切り替える方式です。これは後述する失敗を経て、Claude Code自身がリライトした2代目のロジックです。
モード判定式にした理由
初代ロジックは単一の条件式でエントリーを判定していましたが、レンジ相場とトレンド相場では「正しい行動」が真逆になります。レンジ相場でブレイクアウトに飛び乗ると往復ビンタになり、トレンド相場で逆張りすると踏まれ続けます。そこで2代目では、直近の値動きの構造（高値安値の切り上げ/切り下げ、レンジ幅に対する現在位置など）からまず相場のモードを判定し、レンジと判定した場合はレンジ端まで引きつけてからの逆張り（フェード）、トレンドと判定した場合は押し目・戻りを待っての順張りに行動を切り替える設計にしました。
この変更で重要だったのは、勝率の改善そのものより「負けたときに原因を説明できる」ようになったことです。単一ロジック時代は負けの原因が戦略なのか相場環境なのか切り分けられませんでしたが、モード判定式にしてからは「モード判定の誤り」「エントリーポイントの甘さ」「決済設計の問題」のどこで負けたかをログから特定でき、改善指示が具体的になりました。AIに運用を任せる場合、この「敗因を構造化できるか」が改善ループの回転速度を決めます。
3か月の結果: 一次データ
2026年7月上旬に、オンチェーンの取引記録をすべて突き合わせる監査を行いました。ウォレットの入出金とDEX上の約定履歴から積み上げた確定値です。
- 入金額: 当初188ドル、その後400ドルを追加
- 実現損益: 約-21ドル
- 内訳の特徴: 戦略自体の勝敗よりも、ガス代・手数料などの執行コストが損益を圧迫
監査で分かったのは、-21ドルという数字が「大負けトレードの積み重ね」ではないことです。個々のトレードの勝ち負けはおおむね拮抗しており、損益を削っていたのは1回ごとの執行コストと、早期損切りによる細かい損失の累積でした。つまり戦略の方向性が致命的に間違っていたのではなく、運用の設計（サイズ・決済・コスト構造）が利益を通さない形になっていたということです。これは改善可能な性質の問題であり、実際に後述の3つの改修はすべてこの監査データから導かれています。逆に、監査をせずに「なんとなく増えない」まま回し続けていたら、原因を特定できないまま資金だけが減っていたはずです。
「AIに任せたら勝てました」という記事を期待した人には申し訳ない数字ですが、この-21ドルの内訳にこそ、AI自動売買の本当の難所が詰まっています。
時系列で振り返ると、運用は次のような経過をたどりました。
| 時期 | 主な出来事 |
|---|---|
| 2026年4月 | 運用開始。188ドル入金、小サイズで検証運用 |
| 2026年5月 | 「利確トリガーは引けるのに決済すると損」というガス代問題が顕在化 |
| 2026年6月 | 400ドルを追加入金し建玉サイズの下限を引き上げ。早期損切りの弊害を計測 |
| 2026年7月 | ロジック全面リライト（早期損切り廃止・トレーリング導入・モード判定式へ）。オンチェーン監査で実現損益 約-21ドルを確定 |
「3か月で-21ドル」という結果は、見方を変えれば3回の構造的な失敗を実弾で踏みながら、損失を21ドルに抑えて授業料にしたとも言えます。以降でその3つの失敗を解説します。
失敗1: ガス代で「勝っているのに利確できない」
最初の、そして最大の敗因は建玉サイズでした。オンチェーンDEXでは建玉・決済のたびにガス代（ネットワーク手数料）がかかります。運用初期は1回あたり数十ドル規模の小さな建玉で回していたため、+3.5%の利確目標に届いても、利確幅がガス代を下回るという構造的な問題が起きました。利確のトリガーは引けているのに、実行すると損になるので決済できない。botは正しく動いているのに資金が減っていく、という状態です。
対策はシンプルで、建玉サイズに下限（400ドル・レバレッジ5倍以上）を設けたことです。執行コストは建玉サイズに対してほぼ固定費なので、サイズを上げるほど相対的に軽くなります。「小資金で試す」こと自体がオンチェーン取引ではハンデになる——これは実際に回して初めて体感できた教訓でした。
数字で単純化するとこうなります。建玉100ドル・利確+3.5%なら利確幅は3.5ドルです。ここで建玉と決済に合計2〜3ドル相当の執行コストがかかると、手残りは1ドル前後まで削られ、わずかな滑り（スリッページ）で赤字に転じます。同じ条件で建玉400ドルなら利確幅は14ドルとなり、同じ執行コストでも手残りは11ドル以上。戦略が同じでも、サイズ設計だけで「勝てるbot」と「勝てないbot」に分かれるわけです。中央集権取引所で構築する場合も、取引手数料が同じ構造で効くため、想定利幅と手数料率の比率は最初に計算しておくべきです。
失敗2: 早すぎる損切りがノイズに刈られる
初期のロジックには、含み損が小さいうちに逃げる「早期損切り」の仕組みを入れていました。一見堅実ですが、実際には相場の通常のノイズで次々と損切りが発動し、小さな損失が積み重なる結果になりました。損切り後に価格が想定方向へ戻るケースが多発し、「正しい方向を向いていたのに退場させられる」パターンです。
この失敗の厄介なところは、1回1回の損失が小さいため異常に気づきにくいことです。日次ログでは「小さな損切りが数回」としか見えず、週次で集計して初めて「損切り回数が異常に多く、その大半が直後に反転している」というパターンが浮かび上がりました。ここでもオンチェーンに全約定が残っている利点が効き、損切り執行時刻と価格推移を突き合わせることで「損切りの何割が刈られ損だったか」を定量的に確認できました。感覚ではなくデータで敗因を確定できたことが、次の改善の説得力につながっています。
2026年7月の全面リライトでこの早期損切りは廃止し、トレーリングストップ（価格が有利方向に動いたら損切りラインを追従させる方式）に置き換えました。含み益が乗った建玉は利益を守りながら伸ばし、逆行時は-4.5%の固定損切りで退出する、という非対称の設計です。損切りの「回数」は減り、1回あたりの損失は管理された範囲に収まるようになりました。
トレーリングストップの動作を具体例で書くと、ロング建玉が+2%まで伸びた場合、損切りラインを建値近辺まで引き上げます。さらに+3%まで伸びれば損切りラインも+1%台へ追従し、この時点で「最悪でも小幅なプラスで終わる」状態が確定します。そのまま+3.5%の利確目標に届けば利確、届かず反落すれば追従させたラインで決済です。固定の利確・損切りだけの設計と比べて、「大きく伸びた含み益を反落で全部吐き出す」パターンと「利確目標の直前で反転して損切りまで往復する」パターンの両方を緩和できます。ただしトレーリング幅を狭くしすぎると今度はノイズで早々に決済されてしまうため、この幅の調整は現在も検証を続けているパラメータです。
失敗3: 実装バグで特定銘柄が発注できない
3つ目は泥臭い話です。特定銘柄（WBTC）の発注処理にバグがあり、シグナルが出ても建玉できない状態が一定期間続いていました。ログ上は「エントリー見送り」に見えるため発見が遅れ、機会損失になりました。発注監視の仕組み（watchdog）を差し替えることで解消し、対象銘柄を再び拡大しています。
このバグから得た運用ルールが「エントリー見送りにも理由を書かせる」です。改修後は、シグナルが出たのに建玉しなかった場合、その理由（条件未達なのか、発注失敗なのか、残高不足なのか）を必ずログに残す仕様にしました。正常な見送りと異常な発注失敗がログ上で区別できるようになり、同種のバグは数時間で検知できる体制になっています。
AI自動売買というと戦略の話に目が行きがちですが、実運用の損益は発注が通っているか、決済が執行されているか、ログは嘘をついていないかという運用品質でも決まります。AIに実装させたコードであっても、動作検証とログの突き合わせは人間側の仕事として残ります。
見落とされがちなコスト: AI利用料と運用の固定費
損益を語る上で避けて通れないのが、トレードの外側にあるコストです。この構成では、取引のガス代・手数料に加えて次の固定費がかかります。
- AI利用料: Claude Codeの利用料（サブスクリプションまたはAPI従量課金）。24時間監視のセッションを毎日回すと、プランや処理量によって月数十ドル規模になり得ます
- インフラ: 常時起動しておくPC（またはVPS）の電気代・維持費
- 時間コスト: 日次ログ確認は5分でも、障害対応やロジック見直しの判断には時間を使います。とくに運用初期はバグ対応と検証で相応の時間がかかることを見込んでください
この構造を「損益分岐ライン」として意識しておくと判断がぶれません。月の固定費合計を先に見積もり、それを運用資金で割れば「最低限必要な月次リターン」が出ます。この数字が現実的な水準（経験則では月数%以内）に収まらないなら、資金を増やすか、セッション頻度を落として固定費を削るか、検証と割り切って別の得るもの（ノウハウ・発信素材）を目的にするか、のどれかを選ぶことになります。編集部は現在3つ目の立場で、この記事自体がその「得たもの」の一部です。
重要なのは、運用資金が小さいほどこれらの固定費が重くのしかかることです。仮に月のAI利用料が数十ドルなら、数百ドルの運用資金で同額を稼ぐには毎月数十%のリターンが必要になり、これは現実的ではありません。編集部の運用が「検証」と割り切って小資金で続けているのはこのためで、収支としての成立を目指すなら運用資金・建玉サイズ・固定費の3つをセットで設計する必要があります。逆に言えば、この構成で得たノウハウ（設定値・失敗パターン・改善手順）は資金規模に関係なく再利用できる資産になります。
他の自動売買手段と比べてどうか
自分でAIエージェント構成を組む以外にも、自動売買に近づく手段はあります。3か月回した実感ベースで比較します。
対 コピートレード
取引所のコピートレード機能は、コードを書かずに他人の戦略に乗れる手軽さが最大の利点です。一方で戦略の中身はブラックボックスで、改善ループを自分で回すことはできません。「まず自動売買がどんなものか体験したい」ならコピートレードが早く、「戦略を自分の資産として育てたい」ならエージェント構成に分があります。
対 既製の売買bot・シグナル配信
市販botや有料シグナルは初期構築が不要ですが、ロジックが公開されていないものが多く、相場環境が変わったときに「なぜ勝てなくなったか」を検証できません。Claude Code構成の本質的な価値は、勝率そのものより損益データを根拠にロジックを書き換え続けられることにあります。
対 手動の裁量トレード
裁量との最大の差は感情と稼働時間です。AIは深夜の急変動でもルール通りに執行し、損切りをためらいません。一方で「今日は様子見」という人間的な柔軟性はなく、想定外の相場（フラッシュクラッシュ等）ではルール通りに損切りを繰り返すだけです。24時間の監視体制と引き換えに、想定外への弱さを受け入れる取引だと言えます。
対 チャットAIへの「相場予想」相談
ChatGPTなどのチャットAIに「今買うべきですか」と聞く使い方と、本記事の構成は根本的に別物です。チャット相談は判断の参考にはなっても、執行・記録・検証が人間任せのため、感情による裁量の問題を何も解決しません。エージェント構成の価値は予想の的中率ではなく、ルールの一貫した執行と、全取引が検証可能なログとして残ることにあります。「AIの相場観」に期待するのではなく、「AIの実行力と改善速度」を使う、というのがこの3か月で固まった結論です。
同じ環境を作る手順（概要）
再現のための大まかな手順は次の5ステップです。
- 資金と口座の準備: 失っても生活に影響しない資金額を決め、取引環境（オンチェーンDEXまたはAPI対応の取引所）を用意する。今回の教訓から、建玉サイズに対する執行コスト（ガス代・手数料）の比率を最初に試算しておくこと。利確幅の目安が+3.5%なら、執行コストが建玉の1%を超える構成は最初から成立しません
- Claude Codeのセットアップ: 作業ディレクトリに運用方針・リスク上限・禁止事項を書いたルールファイルを置く。「1回の建玉は資金のX%まで」「日次最大損失Yドルで当日停止」「出金操作は絶対にしない」といった禁止事項を明文化し、AIの裁量の外側に置くのがこの構成の生命線です
- 戦略スクリプトの実装: エントリー条件・利確/損切り・建玉サイズ下限をClaude Codeに実装させ、まず少額またはテストネットで挙動確認。この段階で「シグナルは出たのに発注されない」類のバグを潰しておくと、後の機会損失を防げます
- 定時起動の自動化: タスクスケジューラ等で日次セッションを起動し、前日の引き継ぎメモを読ませて連続運用にする。セッションを日次で使い捨てにすると、長時間稼働による文脈の劣化やエラーの引きずりを避けられます
- 日次のログ確認: 約定・損益・エラーを毎日確認し、改善指示だけ人間が出す。数字が想定レンジを外れた日は、原因が特定できるまで新規エントリーを止めるルールにしています
この記事では全体像に絞りましたが、実際のプロンプト設計・ルールファイルの中身・失敗時の対処記録まで含めた詳細はnoteで公開しています。またAPI対応取引所での構築を考えている人向けに、取引所側のAPI設定手順は別の手順記事で解説しています。
AIに資金を任せる前に: リスクと注意点
実際に運用して痛感したリスクを列挙します。始める前に必ず読んでください。
- 元本割れリスク: 本記事の通り、AIに任せても普通に損はします。レバレッジ取引では入金額を超える速度で資金が減る局面もあります
- 実装バグのリスク: 発注不能・二重発注・ログと実態の乖離など、コード起因の損失は自己責任です。少額での検証期間を必ず設けてください
- 執行コスト負け: ガス代・取引手数料・AI利用料の合計が利益を上回る「コスト負け」は小資金運用で特に起きやすい構造です
- 想定外相場への弱さ: 急変動時、AIはルール通りに動くだけです。損切り上限や1日あたりの最大損失をコード側で強制する設計が必須です
- API・環境障害: 取引所APIの停止やネットワーク障害で、決済したいときに決済できない可能性があります
- セキュリティ: APIキーや秘密鍵の管理を誤ると資金を直接失います。出金権限を持たせない・IP制限をかける等の基本を徹底してください
- 税務: 自動売買でも利益は課税対象で、高頻度取引は損益計算が複雑になります。取引ログの保存を自動化し、詳細は税理士など専門家に相談してください
編集部が実際に使っている資金管理ルール
参考までに、上記リスクに対して編集部がコード側で強制しているルールを挙げます。第一に、運用ウォレットには運用資金以外を入れない（生活資金や長期保有分と物理的に分離する）。第二に、1建玉あたりのサイズ上限と、日次の最大損失額を設定し、超えたら当日の新規エントリーを停止する。第三に、AIには取引権限のみを与え、外部への送金・出金に類する操作は実装させない。第四に、緊急時に人間が全建玉を手動決済できる手順を用意しておく。AIの判断能力を信頼するかどうかとは無関係に、「最悪の日でも失う金額の上限」を人間が先に決めておくのがこの運用の大前提です。
- 失っても生活に影響しない資金だけを入れている
- 損切りと1日の最大損失がコードで強制されている
- 少額・テスト環境での検証期間を設けた
- APIキーの出金権限をオフにした
- 取引ログを毎日確認する運用体制がある
まとめ: 「AIなら勝てる」ではなく「AIなら改善が速い」
3か月の運用で得た結論はこうです。Claude Codeに仮想通貨トレードを任せても、自動的に儲かることはありません。損益を決めたのは戦略の賢さよりも、建玉サイズとガス代の比率、損切り設計、発注の実装品質という地味な要素でした。
それでもこの構成を続ける理由は、失敗から改善までのサイクルが人間の運用より圧倒的に速いからです。ガス代問題の特定もロジックの全面リライトも、損益データを見せて指示すれば数時間で実装まで終わります。自動売買は「作って終わり」ではなく改善の継続戦であり、その継続コストを劇的に下げてくれるのがAIエージェントの本当の価値だと考えています。
今後の計画も書いておきます。直近の課題は、リライト後のモード判定ロジックが各相場環境（レンジ・上昇トレンド・下落トレンド）で想定通りに機能しているかの検証データを貯めることです。加えて、オンチェーンで得た知見を中央集権取引所のAPI取引にも展開し、執行コスト構造の違いが損益にどう出るかを比較する予定です。これらの経過も、良い結果も悪い結果もそのまま記事とニュースレターで公開していきます。
今後も損益はそのまま公開していきます。週次の途中経過と改善の記録はニュースレターで配信しているので、この実験の続きに興味がある人は登録して見届けてください。
最後に、読者のタイプ別に次の一歩を整理しておきます。自分でも構築してみたい人は、本記事の5ステップと失敗3つを踏まえれば、少なくとも編集部が3か月かけて踏んだ回り道はスキップできます。詳細な設計はnoteで公開しています。コードを書かずに自動売買を試したい人は、取引所のコピートレード機能から入るのが現実的です。始め方は当サイトの手順記事にまとめています。まず様子を見たい人は、ニュースレターでこの実験の経過を追いながら判断してください。どの選択でも、「失っても困らない資金で、損失上限を先に決めてから」という原則だけは共通です。
本記事は情報提供を目的としたものであり、投資助言ではありません。掲載している損益・設定値は編集部の実運用記録であり、同じ構成が将来も同様の結果になることを保証するものではありません。暗号資産のレバレッジ取引は元本を失うリスクがあります。投資判断はご自身の責任において行ってください。
<!-- INTERNAL_LINKS_RELATED -->
関連記事
<!-- INTERNAL_LINKS_RELATED -->