FXが絶望的に下手だったので、AIにチャートを学ばせて自動売買させた話
Chapter 1｜開発動機：「下手」を自動化で解決する発想
私はFXが絶望的に下手だった。
数年やっても、同じ失敗を繰り返した。損切りラインを決めても、いざ含み損を抱えると「もう少し待てば戻るはず」と動けなくなる。エントリールールを決めても、相場が動き出すと感情が先に動いて、ルールを破る。
上手くなれないのではなく、人間である以上、感情から切り離せないのだと気づいた。
デビューから既に養分だった。
「再現性を追うなら、人間がやる必要はない」
FXで安定して利益を出すために必要なことは、突き詰めると単純だ。
- 統計的に有利な条件でだけエントリーする
- ルールを毎回必ず守る
これだけだ。難しいのは「これだけ」を人間が実行し続けることだ。
数年間、自分でトレードを続けてわかったのは、自分はこの2つを同時に守れないという事実だった。ある程度の基準を決めて再現性を追う取引をするのであれば、最初からAIやアルゴリズムに任せてしまえばいい。そう考えた。
これがこのシステムを作ったきっかけだ。
このシステムが解く問題
このシステムの目的は、感情を排除し、統計的根拠のある取引のみを実行することだ。
「AIが相場を予測する」のではない。予測は諦めている。そうではなく、「過去15年分のデータで期待値がプラスと証明された形状が出たときだけ、機械的にエントリーする」という設計だ。
システムの全体像
システムは大きく3つのフェーズで動く。
① 学習フェーズ
Claude Haiku 4.5に15年分のチャートデータを読ませ、所謂セオリー上の特有の形状（ダブルトップなど）を発見させる。その形状でエントリーした場合の収支を1件ずつDBに記録し、形状ごとの期待値を算出する。
② 戦略セット生成フェーズ
算出した期待値をもとに、ユーザーが設定した閾値（例：勝率51%以上かつ期待値1.0pips以上）を満たした形状のみを「取引可能」としてセットに登録する。
③ 監視・判断・発注フェーズ
リアルタイムでチャートを監視し、取引可能セットの形状を観測した時点でClaude Opus 4.7などの上位モデルにエスカレーションする。上位モデルが最終的な取引有無を判断し、証券会社APIまたはMT5経由で発注する。
15年分のチャート
↓
【Haiku】形状発見・収支記録
↓
期待値算出 → 戦略セット生成
↓
【Haiku】リアルタイムで対象通貨のチャートを監視し、形状観測
↓（戦略セットに含まれる取引可能形状を検出）
【Opus(/Sonnet)】最終判断
↓
証券会社API/MT5 → 発注
Chapter 2以降では、各フェーズの設計でどのような判断をしたか、何を捨てたかを順に説明する。
Chapter 2｜学習設計：AIに15年分のチャートを読ませる
学習フェーズの設計で最初に決めなければならなかったのは、どのくらいの期間のデータを使うかだ。
なぜ長期データなのか
短期間のデータには致命的な欠陥がある。
例えば、直近3年分のデータだけを使った場合、その3年間がたまたま上昇トレンド一方だったとする。すると「買いエントリーの期待値が高い」という結果が出やすくなる。しかしそれは相場の本質ではなく、たまたまそういう時期だったというノイズだ。
もちろん、短期のデータを用いることで、今のトレンドが継続した場合により大きなリターンを得ることができるだろう。
しかし、このシステムの前提は「予測をしない」ことと「再現性を追う」ことだ。短期データに基づく期待値はこの前提と矛盾する。期待値がプラスに見えても、それが特定の相場環境に依存したものであれば、再現性はない。
必要なのは、トレンド転換・急落・急騰・長期的な横ばいなど、あらゆる相場環境を含むデータだ。リーマンショック後の暴落、その後の回復、コロナショックの急落と急回復など、極端な局面も含めて期待値を算出することで初めて、「どんな相場でも統計的に有利」と言える根拠になる。
AIに何を指示したか
学習フェーズでAIに与えた指示はシンプルだ。
「セオリー通りの形状を検出し、取引した結果から期待値を計算して。」
もちろん、指示を明確にするためにもう少し文章は長かったが趣旨はシンプルである。ダブルトップ・ダブルボトム・ヘッドアンドショルダーと、FXにおけるセオリーは既に数多くあるため、AIに形状を一から定義させるのではなく、すでに広く知られている概念をそのまま使わせた。
AIの形状検出が完璧である必要はない。多少のノイズが入っても、その後の期待値フィルターで弾かれる。今回の例だと勝率48%未満・期待値0.3pips未満の形状は戦略セットに登録されない。精度の低い検出結果は、フィルターが自動的に除外する設計になっている。
学習フェーズに求めるのは完璧さではなく、十分な量の記録だ。
また、セオリーの中でも信用に値しないものも多くあることがわかった。
記録する内容の設計
学習は、自分で対象となる通貨ペアと時間足を選択し、その時間足の取引セットが作成される。
ここでは、AIが形状を観測するたびに、DBに以下を記録する。
- 観測した形状の種類
- エントリー方向(BUY/SELL)
- 勝率
- 総収支(pips)
- 観測日時・通貨ペア・時間軸
- 期待値
ダブルトップ（SELL）→ 観測300回 → 総収支+450pips → 期待値+1.5pips
ダブルトップ（BUY） → 観測300回 → 総収支-200pips → 期待値-0.67pips
このような形で、形状と方向の組み合わせごとに期待値が算出される。次章で説明する戦略セットは、この結果をもとに構築される。
なぜHaiku 4.5を選んだか
15年分のチャートを1件ずつ処理する学習フェーズは、呼び出し回数が膨大になる。
もちろん、Opusに任せればもっといい結果が得られるかもしれない。
しかし、上位モデルで同じ処理をすればコストが跳ね上がる。学習フェーズに求めるのは高度な推論ではなく、セオリー通りの形状を見つけて記録するという反復作業だ。この用途にHaiku 4.5は十分な性能を持ち、かつコストを現実的な範囲に収められる。
単純な形状を読み取ってほしいため、深読みしないHaikuの方が良いという見方もできる。
FXで養分なのにOpus使う余裕があるわけもない
コストと精度のバランスで、モデルを使い分ける。この判断はChapter 4で説明するエスカレーション設計の根底にある考え方と同じだ。
Chapter 3｜期待値設計：「統計的に有利な取引のみ許可する」仕組み
Chapter 2で説明した学習フェーズによって、形状ごとの期待値が出揃った。次の問題は、どの形状を「取引可能」とするかだ。
勝率だけでも、期待値だけでも不十分な理由
まず前提として整理する。
勝率だけを見ることの問題は明白だ。勝率が高くても、負けたときの損失が大きければ統計的に不利になる。勝率90%でも、1回の負けで9回分の利益が消えるなら意味がない。
*補足すると、それも戦略としてないわけではない。ポジション調整などで戦略として成り立つが今回は割愛する。というより、株やFXの究極の答えだと思っている。
MT5 自作EA:「Equity Step Growth」バックテスト結果より
では期待値だけを見ればいいかというと、そうでもない。
一般に、プロフィットファクター(総利益÷総損失)が1.5〜2程度であれば期待値面で優良な戦略とされている。しかしその水準を達成しようとすると、勝率は33〜50%程度に落ち込むことが多い。
ここで問題になるのがドローダウンだ。
勝率33%とは、平均して3回に1回勝つということだ。しかし確率には偏りが生じる。理論上は3回に1回勝つ計算でも、現実には10連敗することがある。上振れの連勝も起きるが、レバレッジをかけるFXにおいて、負けの連続は資産を大きく毀損する。 期待値がプラスであっても、ドローダウンに耐えられなければ退場するしかない。
勝率と期待値を両方の条件として課すのは、このためだ。
要するに、収束した後の結果も大事で、収束するまでの偏りにも耐えられなければならないということ。
スプレッドという「取引するだけで負ける」コストとAPIコストのトレードオフ性
戦略セットの設計でもう一つ考慮したのが、スプレッドだ。
FXには必ずスプレッドが存在する。買値と売値の差であり、取引のたびに必ず発生するコストだ。つまり、取引すればするほど必ず一定のコストを払い続ける構造になっている。
この観点からすると、取引回数を減らして精度を高めることは合理的だ。条件を厳しくして取引回数が減ることは、必ずしも悪いことではない。
一方で、監視フェーズにはAPIのコストがかかる。期待値がプラスと判明している形状をわざわざスルーすることにも、機会損失というコストが発生する。
精度だけを極限まで高めることが正解ではなく、コストと機会のバランスが取れた閾値を自分で決めるというのがこのシステムの設計思想だ。
戦略セットの構造
前期待値フィルターを通過した形状は、戦略セットとして保存される。
各通貨に対して上限1つでActive可で、Activeなセットを持つ通貨ペアは監視関数に渡される。また、各通貨、時間軸は自由に追加可能。
戦略セットとは、取引可能と判断された形状と方向の組み合わせの集合だ。例えば以下のようなイメージになる。
戦略セット（例）
├── ダブルトップ SELL ✓（勝率54%・期待値+1.8pips）
├── ダブルボトム BUY ✓（勝率52%・期待値+1.2pips）
├── ヘッドアンドショルダー SELL ✓（勝率55%・期待値+2.1pips）
└── ...
このセットは通貨ペアと時間軸ごとにカスタム可能だ。ドル円の1時間足と、ユーロドルの4時間足では、同じ形状でも期待値が異なる。相場によって有効な形状は違うため、戦略セットを使い分けることで対応する。
また、取引回数を増やしたければ、より短い時間足を使うとよいだろう。
ただ、どうやら日足だけは非常に信頼度が高かったことがわかった。
シグナルの信頼度は、長い時間足になればなるほど増加傾向にあった。
監視フェーズのAIはこの戦略セットを参照しながらチャートを監視し、一致する形状を観測した時点でエスカレーション関数を呼ぶ。
捨てた設計：動的な閾値調整
設計段階で検討したが採用しなかったアプローチがある。相場環境に応じて閾値を動的に変えるというものだ。
ボラティリティが高い相場では閾値を上げ、穏やかな相場では下げるという発想だ。一見合理的に見えるが、これは「相場を予測する」ことと本質的に同じになる。どんな相場環境かを判断する時点で、予測が介在する。
このシステムの前提は予測をしないことだ。閾値は固定し、相場環境への判断はエスカレーション先の上位モデルに委ねる。役割を明確に分離した方が、設計がシンプルになり検証もしやすい。
あと面倒くさかった。
Chapter 4｜判断設計：なぜ最終判断だけ上位モデルに任せるのか
Chapter 2でHaikuを選んだ理由としてコストを挙げた。Chapter 4ではその判断をさらに掘り下げる。このシステム全体を貫く設計思想は、モデルのコストと役割を明確に分離することだ。
「全部Opusに任せればいい」ではない理由
シンプルな疑問から始める。最も高性能なモデルに全部任せれば、最も良い結果が出るのではないか。
私の答えはNoだ。理由は2つある。
1つ目はコストだ。
リアルタイム監視とは、チャートを継続的に処理し続けることを意味する。上位モデルで全ての処理を行えば、取引が発生しない時間帯も含めて膨大なAPIコストがかかり続ける。個人が運用できるコスト水準を超える。
もちろん、圧倒的な資金があればAPIコストなんか些細なものであるが、私みたいな貧乏人にはOpusコストだけで破産してしまうだろう。
2つ目は役割の問題だ。
監視フェーズで必要なのは「この形状は戦略セットに一致するか」という判断だ。これは高度な推論ではなく、パターン照合に近い処理だ。この用途に上位モデルを使うのはオーバースペックであり、コストに見合わない。
また、単純なアルゴリズムでの検知ではないのは、形状には微妙な違いやスケールが存在し、漏れがどうしても発生するからだ。これは、私が単純なアルゴリズム取引EAをいくつか開発した経験からHaikuに監視させるという機構にした。
エスカレーションという設計
このシステムのエスカレーション設計は以下の考え方に基づいている。
「高コストのリソースは、本当に必要な瞬間だけ使う」
監視AIが戦略セットに一致する形状を観測した時点で初めて、上位モデルを起動する。それまでは上位モデルは一切動かない。
発注は、最も金に関わる部分なので上位モデルを使う。ここをケチって損したら元も子もない。
【Haiku】常時稼働・形状照合
↓ 取引可能形状を検出した時
【Opus(/Sonnet)】起動・最終判断
↓
取引 or スキップ
この設計により、上位モデルの呼び出しは「統計的に有利と判明した形状が出た瞬間」だけに限定される。無駄なコストを払わず、判断が必要な場面でだけ上位モデルの能力を使う。
Chapter 2でHaikuに大量処理を任せた判断と、根底にある考え方は同じだ。
処理の性質に合ったモデルを使う。
上位モデルが担う判断の中身
戦略セットによるフィルターを通過した時点で、「この形状は過去15年のデータで期待値がプラスだった」という統計的根拠はすでにある。ではなぜ、さらに上位モデルの判断を挟むのか。
それは、ポジションに取るにあたって必要なのは、取引するかどうかだけではないからだ。
ポジション1つ取るにしても、ボラリティに対するレバレッジの調整、次の抵抗ラインを考えたTP/SL調整、自分が既に所持しているポジションとの兼ね合い(疑似的な両建てを回避するなど)等、多くの細かな考慮すべきものがある。これらを全て単純アルゴリズムで制御するのは非常に困難である。
つまり、上位モデルには、この最終調整を委ねている。統計が示す期待値と、現在の相場環境を照らし合わせた上で、取引するかしないか、リスクマネジメントをどのようにするかなどである。
これは、FXも株もポジション調整こそが最重要という考えからの実装だ。
上位モデルを選択可能にしている理由
現在の実装では、SonnetとOpusをユーザーが選択できる設定にしている。
正直に言うと、開発段階でSonnetを使っているのは、現時点の資金規模ではOpusのAPIコストに継続的に耐えられないからだ。Opusの方が取引判断の質は高いだろう。しかし、コストが運用を圧迫してはシステムとして成立しない。
資金が増え、運用規模が拡大すれば、Opusへの移行は自然な選択になる。現時点ではSonnetで十分な判断品質を確保しつつ、コストを現実的な範囲に収めている。
この設計で得られた学び
Haiku・Sonnet・Opusという3つのモデルを、それぞれの役割に応じて使い分けるこの設計は、コスト効率だけが目的ではない。
役割が明確に分離されているため、検証と改善がしやすい。
例えば、学習フェーズの精度に問題があればHaikuへのプロンプトだけを改善すればいい。最終判断の質を上げたければエスカレーション先のモデルを変えればいい。システム全体を作り直す必要がなく、問題のある部分だけを個別に改善できる。
シンプルな役割分担が、長期的な保守性を生む。
Chapter 5｜本番稼働で直面したコスト問題と、機能を削除した話
本番稼働を始めて最初に直面した問題は、機能の不足でも精度の低さでもなかった。APIコストだ。
監視システムのコスト構造
このシステムの監視フェーズは、チャートを継続的に処理し続ける。Haikuとはいえ、呼び出し回数が積み上がれば無視できないコストになる。
特に問題になったのが時間軸だ。
1分足や5分足を対象にした場合、数秒未満の呼び出しによって監視の回数は膨大になる。24時間動き続けるFX市場を短い時間軸で監視すれば、たとえHaikuであっても、コストはすぐに現実的な水準を超える。
最初の設計：決済もAIに任せていた
当初の設計では、決済の判断もAIに委ねていた。
ポジションを保有している間も、該当通貨ペアの監視を継続する。相場が不利な方向に動けばAIが判断して損切りし、有利な方向に動けば利確するという設計だ。
一見すると理想的に見える。しかし実際に動かすと、ポジション保有中も監視が止まらないため、コストが二重にかかり続けるという問題が顕在化した。エントリーの監視コストに加えて、決済の監視コストが常時発生する構造だ。
機能を削除するという判断
解決策として取ったのは、機能の追加でも最適化でもなかった。決済管理の機能を丸ごと削除した。
具体的には以下の設計に切り替えた。
- ポジションを保有している通貨ペアは、一切監視しない
- エントリー時に上位モデルが決定したTP/SL（利確・損切りライン）を、そのまま遵守する
- 決済の判断はAIではなくMT5の自動処理に委ねる
この判断の背景にあるのは、Chapter 1で述べた設計理念と同じだ。AIに任せるべき判断と、任せなくていい判断を分ける。 TP/SLはエントリー時点で上位モデルが算出している。その判断を信頼して守り抜くことは、AIではなくルールで十分だ。
むしろ、ポジション保有中も監視を続けてAIが決済判断を覆す設計は、「統計的根拠のある判断を感情で破る」という、人間のトレードで起きていた問題と本質的に同じだと気づいた。
呼び出し頻度のカスタマイズ
もう一つのコスト改善が、時間軸ごとの呼び出し頻度の個別設定だ。
1分足と日足では、チャートが意味のある変化をする速度がまったく異なる。日足を1分ごとに監視しても意味がなく、コストの無駄でしかない。
現在の設計では、時間軸ごとに呼び出し間隔を個別に設定できる。
例:
1分足 → 1分ごとに監視
5分足 → 5分ごとに監視
1時間足 → 15〜30分ごとに監視
日足 → 数時間ごとに監視
必要な頻度でだけ呼び出す。それだけでコストは大きく変わる。
本番稼働1ヶ月の現状
現時点での結果は約+8%だ。ただし、この数字に統計的な信頼性はまだない。1ヶ月・限られた取引回数では、結果が実力なのか運なのかを判断できない。
それよりも重要だと考えているのが、ポジションの妥当性だ。
システムが取るポジションを見ると、人間が見ても納得できる根拠のある場所でエントリーしている。「なぜここで買うのか」「なぜここで売るのか」が説明できる。これは数字よりも本質的な評価軸だと思っている。ブラックボックスとして動くのではなく、判断の根拠が人間に説明できる状態であることが、長期的な信頼の土台になる。
おわりに
このシステムを作った学びとしては、アプリ開発において、保守・運用まで考慮した設計にすることが重要であるとわかった。
コストを最適化する、設計をシンプル化するために機能を捨てるという思考が、このAIコーディング時代に重要となる思考の1つなのではないかと気がついた。
取引基準については、相場を読もうとするから難しくなる。読むのをやめて、統計的に有利な条件が揃った時だけ機械的に動く、そう割り切ったとき、設計は一気にシンプルになった。
「AIが相場を予測する」システムではない。「人間が感情で破ってきたルールを、AIが淡々と守り続ける」システムだ。
私が絶望的に下手だったのは、相場を読む能力がなかったからではなく、決めたルールを守る能力がなかったからだ。そしてその問題は、自動化によって解決できた。
現在は、株取引について開発中である。これについては、また今度扱おうと思う。
Discussion