一目均衡表とADXを組み合わせる考え方 — 雲の位置とトレンド強度を四象限で整理する設計

一目均衡表(いちもくきんこうひょう)の雲は、価格が「どちら側の構造にいるか」を示してくれます。ただし、雲の上にいるという事実だけでは、その流れに力が残っているのか、惰性で位置を保っているだけなのかは区別できません。ADX(Average Directional Index:平均方向性指数)はその逆で、トレンドの強さは数値化しますが、上向きか下向きかという方向の情報を持ちません。

本記事では、この2つを「位置」と「強度」という別々の軸として扱い、掛け合わせた四象限で相場の状態を分類する設計を整理します。売買の合図を作るというより、いまの状態にラベルを付けるための考え方です。cBotを自作したい方、開発を依頼する前に要件を整理したい方を想定しています。設計の参考としての位置づけであり、特定の設定が成果を保証するものではありません。

雲の内外を縦軸、ADXの向きを横軸に取り、相場の状態を四つの象限に分類した模式図

一目均衡表の役割

この組み合わせで一目均衡表に任せるのは、方向と位置の判定です。転換線・基準線・先行スパン1/2・遅行スパンのうち、ここでは先行スパン1と2に挟まれた「雲」を主に使います。各線の成り立ちは一目均衡表の基本構造にまとめています。

雲から読み取れる情報は3つあります。価格が雲の上・下・中のどこにあるか、雲がどちら向きにねじれているか、そして雲がどれくらい厚いかです。厚い雲は過去の高値と安値の中値が離れている状態を表し、価格が通過するまでに時間がかかりやすいゾーンとして一般に解釈されます。

単独使用時の限界は、位置の情報が「状態」であって「勢い」ではない点です。雲を抜けた直後の勢いのある局面と、雲の上で横ばいが続いている局面は、どちらも同じ「雲の上」として表示されます。雲からの距離である程度は推測できますが、距離は価格水準や銘柄ごとの値幅に左右されるため、共通の物差しにはなりにくい面があります。

ADX の役割

ADXに任せるのは、強度の判定だけです。ADXは+DIと-DIという2本の方向性指数の差を平滑化して作られ、値が大きいほど一方向への動きが続いている状態を表します。詳しくはADXの基本を参照してください。

読み方のポイントは水準と向きの2つです。水準はトレンドがあるかどうかの目安になり、向きは強まっているのか弱まっているのかを示します。この組み合わせでは向きのほうを重視します。水準が高くてもADXが下向きなら、勢いはすでにピークを過ぎつつあると読めるためです。

単独使用時の限界ははっきりしています。ADXは強い上向きの動きでも強い下向きの動きでも同じように大きくなるため、方向の判定には使えません。+DIと-DIの大小で方向を補うこともできますが、この2本は短い間隔で交差しやすく、レンジでは入れ替わりが頻発します。また平滑化を二重にかけているぶん反応が遅く、動き出しの数本は低い値のまま推移する傾向があります。

なぜこの組み合わせか

2つの指標は、互いが持っていない軸をちょうど埋め合う関係にあります。雲は方向と位置を持ち強度を持たず、ADXは強度を持ち方向を持ちません。一般論として、役割が重ならない指標どうしは組み合わせたときに条件の意味を説明しやすくなります。

雲の内外とADXの向きを掛け合わせると、次の四象限に整理できます。

ADXが上向きADXが下向き
価格が雲の外構造と勢いが揃っている状態構造は残るが勢いが弱まっている状態
価格が雲の中雲を抜ける動きの準備段階の候補方向感の乏しい停滞

左上は、流れの継続を確認する材料として最も扱いやすい象限です。右上は見落とされやすい象限で、チャート上は雲の上(または下)に位置していても、ADXが下向きであれば追随する根拠が薄くなっていると読めます。新規の判断を控える、保有中の管理を見直すといった「守り側の条件」に使う設計が考えられます。

左下は、雲の中にいながら強度だけが先に切り上がっている状態です。雲を抜ける動きの前段として監視対象に加える使い方がありますが、どちらへ抜けるかはこの時点では決まりません。右下は両方の軸が曖昧なため、判定そのものを見送る象限として扱うのが素直です。

この分類の利点は、シグナルの有無ではなく状態を4種類のラベルで持てることです。ADXがレンジでの判定を止めるノイズフィルターとして機能することが期待でき、雲がADXに欠けている方向を補います。一方で、どちらも過去の値を平滑化した遅行系の指標であり、状態の切り替わりは実際の値動きより遅れて確定します。初動を捉える用途には向かないという前提は、設計の最初に置いておくのが現実的です。

パラメータをどう考えるか

ここで挙げるのは方向性だけで、正解となる値を示すものではありません。

一目均衡表側 は9/26/52が標準です。日足を前提に作られた値であるため、短い時間足でそのまま使うか、期間を調整するかは検証で決める領域になります。雲の厚みを条件に使う場合は、価格差をそのまま比べず、ATR(平均的な値幅)で割って正規化しておくと銘柄をまたいで扱いやすくなります。

ADX側 は14期間が広く使われています。短くすると向きの変化が早く現れる代わりに上下動が増え、長くすると滑らかになる代わりに遅れが大きくなります。「上向き」の定義も設計項目のひとつです。1本前との比較にすると細かく反転しやすいため、数本前との差で見る、あるいは軽く平滑化してから傾きを取るといった方法が考えられます。

ADXの水準に閾値を置く場合、教科書的な目安の値はありますが、銘柄や時間足によって分布が異なります。固定値をそのまま採用せず、対象銘柄でのバックテストで分布を確認してから決める手順をおすすめします。条件を細かく合わせ込むほど過去データへの過剰適合が起きやすくなる点にも注意が要ります。

cBot化する際の考慮点

cTraderのcBotとして実装する場合、この組み合わせに固有の注意点を整理します。

状態は列挙型で持つ: 四象限を2つのbool変数の組で扱うと、条件分岐が散らばりやすくなります。列挙型として1つの変数にまとめ、「前の足の象限」と「今の足の象限」を比較できる形にしておくと、象限が移った足だけを検出する処理が書きやすくなります。

先行スパンのインデックス: 雲は基準線の期間ぶん未来へずらして描かれます。判定に使いたいのは「評価する足の位置に描かれている雲」であり、系列の末尾の値ではありません。インデックスを明示して参照し、チャート上の表示と値が一致するかを実装初期に確認します。

確定足で評価する: ADXは形成中の足では値が動き続けます。OnTickで向きを判定すると同一バー内で象限が行き来するため、OnBarで1本前の確定足を評価する構成が基本です。

履歴不足: 先行スパン2の52本にずらしの26本、さらにADXの平滑化ぶんが必要です。起動直後は値が揃わないため、本数のチェックとNaN判定を先頭に置きます。

計算負荷: どちらも組み込みインジケーターで、OnBarでの評価なら負荷は小さく収まります。複数の銘柄や時間足を同時に監視する場合は、OnStartで一度だけインスタンスを生成する形にします。

// 例: 四象限を列挙型で保持する
enum Regime { Aligned, Fading, Building, Stalled }

var ichimoku = Indicators.IchimokuKinkoHyo(9, 26, 52);
var dms = Indicators.DirectionalMovementSystem(14);

if (Bars.Count < 120) return;

int i = Bars.Count - 2;                       // 1本前の確定足
double close = Bars.ClosePrices[i];
double spanA = ichimoku.SenkouSpanA[i];       // その足の位置に描かれている雲
double spanB = ichimoku.SenkouSpanB[i];
if (double.IsNaN(spanA) || double.IsNaN(spanB)) return;

bool outsideCloud = close > Math.Max(spanA, spanB) || close < Math.Min(spanA, spanB);
bool adxRising = dms.ADX[i] > dms.ADX[i - 3]; // 向きの定義は検証で決める

Regime regime = outsideCloud
    ? (adxRising ? Regime.Aligned : Regime.Fading)
    : (adxRising ? Regime.Building : Regime.Stalled);

ポジション管理との連携では、象限ごとに「何を許可するか」を先に表として決めておくと整理しやすくなります。たとえば新規の判断は揃っている象限のみ、勢いが弱まった象限では新規を止めて既存分の管理だけを行う、といった対応です。損切りの位置は象限とは独立に、発注時点で設定しておく設計が安全側です。

実装の流れ

入力から出力までを順に並べます。

  1. 入力: 対象の銘柄と時間足を決め、必要な本数の確定足を取得する
  2. 計算: 一目均衡表とADXをそれぞれ別の系列として保持する
  3. 位置の判定: 評価する足の終値が雲の外か中かを決める。外であれば上側か下側かも記録する
  4. 強度の判定: ADXの向き(必要なら水準も)を評価する
  5. 象限の決定: 3と4の結果から4種類のいずれかに分類し、前の足の象限と比較する
  6. 出力: 象限が移った足だけ、ログや通知へ状態と各値を渡す。発注を行う場合もこの段階で扱う

毎足シグナルを出すのではなく、象限の移り変わりをイベントとして扱う点がこの構成の特徴です。同じ象限が続いている間は何も出力しないため、通知の量も抑えられます。

確定足の取得から位置と強度の判定、象限の決定、象限が移ったときだけ出力するまでの処理フロー図

どう活用するか

目的に応じた使い方を挙げます。

自作派の方は、Claude Codeを使ったcBot開発の設計メモとして、四象限の列挙型と「象限が移った足だけ出力する」という方針を下敷きにしてみてください。まずは発注を行わず、状態をログに書き出すだけのインジケーターとして作ると検証が進めやすくなります。委託派の方は、ai-programming.xyzへの開発相談の際に、象限ごとに許可したい動作を表にして共有すると要件定義がスムーズです。教育派の方は、スクールの演習として状態遷移の実装に取り組むと、条件分岐の整理の仕方が身につきます。

同じ一目均衡表でも、相手をモメンタム系に替えると設計の重心が変わります。一目均衡表とMACDの組み合わせと読み比べると、強度を見る構成とタイミングを見る構成の違いが整理しやすくなります。

本記事は一般的な情報提供を目的としています。投資助言ではありません。 取引判断はご自身の責任で行ってください。