【FX自動売買開発ログ #7】機械的な閾値をやめて、AIに「相場環境」を判定させることにした話

2026年7月15日 2026年7月15日

solo-ai-app.com

前回のおさらい

前回、「ADX<20のときは新規エントリーを見送る」という単純な閾値フィルターを試しましたが、結果は仮説と逆で全指標が悪化しました。原因を掘り下げると、「期間全体で見た傾向」と「個々のエントリー判断時点の値」は必ずしも一致しない、ということが分かりました。トレンドの強弱という情報自体は不調期を捉えている可能性がある一方で、それを単純な数値の閾値でフィルターするやり方が合っていなかった、ということです。

今回は、その反省を踏まえて次の一手を検討します。

新しい理論モジュール:「相場環境」を判定させる

方針転換のポイントはシンプルです。ADXという単一指標を機械的に閾値判定するのではなく、価格推移・ボラティリティ・トレンド系指標を複数まとめてAIに渡し、「今の相場はレンジなのかトレンドなのか」を言語的に総合判断させる、という方向にします。

既存のダウ理論・プライスアクションと同じ構成で、strategies/theory_regime.py という新しいモジュールを作ることにしました。ただし役割が少し違います。ダウ理論やプライスアクションが「買いか売りか」という方向を当てにいくのに対し、この新しい理論は「今はエントリーに適した局面かどうか」を判定するのが仕事です。

設計方針として指定したのは次の内容です。

相場を「レンジ相場(方向感のない値動き)」「明確なトレンド相場」「トレンド転換の過渡期」の3つに分類させる
レンジ相場と判定した場合はsignal: neutral、confidenceは「レンジである確信度」として出す
明確なトレンド相場の場合はそのトレンド方向をsignal(buy/sell)とし、confidenceは「トレンドの強さの確信度」とする
判定材料として、ADX・ATRの推移(直近で拡大しているか縮小しているか)や、価格が主要な移動平均からどれだけ乖離しているかも渡す

Claude Codeはまずsystem_promptの草案だけを作り、API呼び出しはまだしないところで一旦止めてもらいました。ここは「いきなり実装して動かす」のではなく、設計を確認してから先に進めたかったポイントです。

統合方法をどうするか:投票か、拒否権か

新しい理論をどう既存の統合スコアリングに組み込むかも、実装前に相談しました。案は2つです。

案A:3つ目の理論として対等に投票へ参加させる(min_agreeのカウントに含める)
案B:フィルターとして特別扱いする。regime_filterがneutral(レンジ相場)と判定した場合は、他の2理論がbuy/sellで一致していてもエントリーを見送る「拒否権」を持たせる

自分の直感では「AIは"止める判断"に向いている」という今までの設計方針に合わせて案Bが良さそうに思えましたが、実装の手間も含めて意見を聞いてみました。

返ってきた回答は、案Bを推奨するというものでした。理由は次の3点です。

案Aは実質的に拒否権として機能しない。既存のcombine_judgmentsのロジックでは、neutral判定は単に投票から除外されるだけなので、min_agree=2でダウ理論とプライスアクションの両方がbuyなら、regime_filterがneutralでも2票が揃ってしまい素通りしてしまう。「レンジ相場だから見送る」という意図を実現するには、案Bのような明示的な上書きロジックが必要。
案Bでも実装コストは低い。combine_judgments自体は変更せず、呼び出し側に「regime_filterがneutralなら最終結果を強制的にneutralにする」という薄いラッパーを1つ追加するだけで済む。
ただし過度な期待は禁物。ADX<20フィルターの検証で「期間全体の傾向」と「個々のエントリー時点の値」が一致しなかったのと同じ理由(トリガーが発火する瞬間には、そもそもある程度方向感が出ていることが多い)で、今回も効果が限定的である可能性は残る。「効くはず」という前提では進めない方がいい、という釘刺しも添えられていました。

もう一つ、この設計変更が「リスク管理(損切り・ポジションサイズ)はAIに判断させない」という元々の方針と矛盾しないかも確認しました。この原則はあくまで損切り・サイジングに関するもので、「エントリーすべきかどうか」の判定はダウ理論・プライスアクションと同じ"入り口"の判断にあたるため、抵触しないという整理でした。言われてみれば納得です。

決定事項

今回は、以下の2点を決めたところで区切りにします。