一目均衡表とRSIの組み合わせ — 条件を足すのではなく引いて組み立てる

指標を2つ組み合わせるとき、多くの場合は「両方が成立したら入る」という形にまとめます。ところがこの形は、片方が遅い指標だと成立がさらに遅くなり、片方がダマシの多い指標だとそのダマシも一緒に持ち込むことになります。本記事では、一目均衡表とRSIを題材に、RSIを「入る理由」ではなく「入らない場面を決める側」に置く組み立て方を整理します。条件を足して判定を厚くするのではなく、引いて対象を狭める設計です。一目均衡表を条件式に落とし込む段階で手が止まっている方、条件を増やしたのに挙動が良くならず困っている方に向けた内容です。

一目均衡表の役割 — 遅れる代わりに前提を固める

一目均衡表は、転換線・基準線・2本の先行スパン・遅行スパンという5本の線から成り立っています。どの線も、ある期間のレンジの中心を求め、それを時間軸に沿ってずらして並べたものです。値動きの勢いを測る指標ではなく、価格と時間の両面で見方が揃っているかを確かめる設計だと捉えると、性格がつかみやすくなります。

代表的な読み方が三役好転・三役逆転と呼ばれる形です。転換線と基準線の並び、価格と雲の並び、遅行スパンと過去の価格の並びという3つが同じ向きに揃った状態を指します。線1本の交差より条件が厳しいぶん、前提が頻繁にひっくり返りにくいという性質を持ちます。この組み合わせで一目均衡表に任せたいのは、まさにこの「前提の固定」です。

単独で使う場合の弱点もはっきりしています。条件が出そろうまでに時間がかかるため、揃ったころには値動きの初動が終わっている場面が少なくありません。レンジでは線どうしが寄り集まり、並び順を読む意味が薄れます。そもそも雲は、確定した過去の値を先の時間帯へ写し取った描画であり、その先の値動きを予告するものではありません。前提は固められても、いま入る位置かどうかは別問題だと割り切っておくのが実務的です。

RSIの役割 — 速い代わりに前提を持たない

RSIは、直近の上昇分と下落分の比率から値動きの偏りを0〜100の目盛りへ置き換えるオシレーター系の指標です。参照する期間が短いため反応が速く、偏りが変われば水準にすぐ現れます。

この速さは、単独でエントリーの合図に使うと扱いにくい性質でもあります。RSIには方向の前提がないため、流れが強い局面では高い水準や低い水準に長く留まり続けます。その状態を反転の兆候と読んでしまうと、流れに逆らう判断を繰り返すことになります。価格の高値とRSIの高値がそろわないダイバージェンスも材料の一つですが、それが実際の動きへいつつながるかまでは分かりません。

そこで本記事では、RSIの速さを「入る合図」ではなく**「すでに伸び切っている」と早めに気づくため**に使います。同じ指標でも、合図として読むか除外の材料として読むかで、求められる精度がまったく変わります。合図に使うなら当たり外れが問われますが、除外に使う場合に問われるのは「明らかに行き過ぎた場面を機械的に外せるか」だけです。RSIの得意な部分だけを取り出す配置、と言い換えてもよいと思います。

なぜ足すのではなく引くのか

2つの指標をどちらも「入る理由」として扱い、ANDで重ねる設計には落とし穴があります。全体の成立タイミングは遅い側に引っ張られ、それでいて速い側が拾うダマシは排除されません。成立の頻度だけが下がり、判断の質は思ったほど変わらない、という結果になりやすい構造です。

そこで、2つの係を非対称にします。

• 一目均衡表: どちら向きの前提で考えるかを固定する（入る理由）
• RSI: その前提の中で、いま入るべきでない場面を外す（入らない理由）

補完関係は二方向に働きます。一目均衡表の弱点は、成立が遅く、動いた後に条件が揃いやすいことでした。前提が揃った時点でRSIがすでに上方へ張り付いているなら、それは前提が正しいことの裏付けであると同時に、初動から時間が経った合図でもあります。除外条件として扱えば、遅い側の弱点を速い側で機械的に外せます。逆に、RSIが前提を持てない点は一目均衡表が埋めます。雲の下で出た反転の兆しは、そもそも判定の対象に入りません。ノイズフィルターとして機能することが期待できる部分です。

この非対称な役割分担には、検証上の利点もあります。除外条件は後から足したり外したりしやすいため、あり・なしで挙動を比べれば、その条件が何を削っているのかを切り分けられます。入る理由を2つ重ねた設計では、どちらの条件が効いているのかを分離しにくくなります。

もっとも、除外条件も条件のひとつです。増やせばシグナルの発生頻度は下がりますし、過去データに合わせて水準を細かく調整すれば、過剰最適化の余地もそのぶん広がります。この構成が狙うのは機会の多さではなく、判断の入口を1本に固定して検証を進めやすくすることだ、と位置づけておくと期待とのずれを避けられます。なお、移動平均とRSIの組み合わせは方向とタイミングの分業でしたが、本記事は入る理由と入らない理由の分業という違いがあります。

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

調整対象は、一目均衡表の3つの期間と判定に使う線の選び方、そしてRSIの期間と除外に使う水準です。

一目均衡表の9・26・52という数字は、相場の統計から導かれたものではなく、かつての商習慣における日数が背景にあると説明されることが多い設定です。そのため時間足に合わせて動かしても理屈のうえでは問題ありませんが、変更した時点で、他の参加者が画面に出している線とは別物になります。期間を探るより先に、判定へ使う線を2本程度まで絞り込むほうが、挙動を追いやすくなります。5本すべてを条件に入れると、どの線が結果を左右しているのか分からなくなるためです。

RSI側は、期間を短くすると反応が増えて振れが大きくなり、長くすると滑らかになって反応が減ります。除外に使う水準は、反転を狙うための水準とは考え方が異なります。ここで決めたいのは「もう十分に伸びた」と見なす境目なので、緩めれば機会が増える代わりに動いた後の判定も混じり、厳しくすれば機会が減ります。

いずれも「反応を速くするのか、安定させるのか」という方向性の理解に留め、一度に複数を動かさないことが大切です。バックテストでは、まず除外条件を外した状態を基準として測り、そこへ除外を足したときに何がどう変わったかを見る順序が分かりやすいと思います。時間足を変えたときは、除外の水準も合わせて見直す前提で考えます。

cBot化する際の考慮点

cTraderのcBotとして実装する場合、一目均衡表を含むことで生じる論点がいくつかあります。

雲の上端と下端は入れ替わる: 2本の先行スパンは大小関係が入れ替わります。俗に「ねじれ」と呼ばれる箇所です。どちらか一方を上端だと決め打ちすると、入れ替わった区間で判定が反転してしまいます。毎回、大小比較で上端と下端を取り直してから並びを評価します。

線ごとにずらす方向が違う: 先行スパンは計算した値を先の時間へ、遅行スパンは過去方向へずらして描かれます。画面上でいまの位置に見えている雲は、過去のバーで計算された値です。どのインデックスを読んでいるのかをコード上で明示しないと、意図と数本ずれた判定になります。遅行スパンを条件へ加える場合、比較対象が過去のバーになるぶん判定の確定がさらに後ろへずれる点も、設計時に織り込んでおきます。

確定したバーで揃える: 形成途中のバーはRSIの値が動き続けるため、同じバーの中でも判定結果が変わります。参照するインデックスを共通の変数として持ち、前提側と除外側が同じバーを見るようにします。

ヒストリーの不足: 起動直後は、長い期間を参照する先行スパンとシフト分を合わせたバーがまだ揃っていません。不足したまま読むと意味のない値で判定してしまうため、必要本数を満たすまで処理を抜ける分岐を先頭に置きます。

除外の記録を残す: 除外条件で見送った回数と理由は、前提が崩れて見送った場合と分けて残しておきます。これがないと、条件を締めすぎているのかどうかを後から判断する材料がありません。

// 例: 前提を固めてから除外で絞る（参照はすべて確定済みのバー）
var ichimoku = Indicators.IchimokuKinkoHyo(TenkanPeriod, KijunPeriod, SenkouBPeriod);
var rsi      = Indicators.RelativeStrengthIndex(Bars.ClosePrices, RsiPeriod);

if (Bars.Count < SenkouBPeriod + KijunPeriod + 5) return;   // 参照本数のガード

int i = 1;                                                  // 確定済みバー
double close = Bars.ClosePrices.Last(i);
double spanA = ichimoku.SenkouSpanA.Last(i);
double spanB = ichimoku.SenkouSpanB.Last(i);
double cloudTop = Math.Max(spanA, spanB);                   // ねじれで上下が入れ替わる

// ① 前提: 向きを一つに固定する
bool premiseUp = close > cloudTop
              && ichimoku.TenkanSen.Last(i) > ichimoku.KijunSen.Last(i);
if (!premiseUp) { CountSkip("premise"); return; }

// ② 除外: 伸び切った位置なら外す（入る理由には使わない）
if (rsi.Result.Last(i) >= RsiExcludeLevel) { CountSkip("extended"); return; }

処理そのものは軽く、バー確定ごとの判定であれば負荷を意識する必要はほとんどありません。実装の初期段階では、前提が成立したバーと除外に該当したバーをそれぞれ書き出し、チャート上の位置と突き合わせておくと、水準の見当が付けやすくなります。

実装の流れ

処理は、前提を固める → 入らない場面を外す → 実行する、という一方向の流れに整理できます。

1. 入力: 銘柄と時間足を決め、確定したバーの位置で両指標の値を取得します
2. 前提: 雲と線の並びを見て、上向き・下向き・どちらとも言えない、の三通りへ振り分けます
3. 除外: 前提と同じ向きの中で、RSIが伸び切った位置にないかを確認し、該当すれば理由を残して見送ります
4. 発注・管理: 通過した場合だけ発注へ回し、撤退水準と数量の決定はこの判定とは別系統で扱います

大事なのは、前提と除外を1つの複合条件へ押し込めないことです。別々のフラグとして持たせておけば、どちらの理由で見送ったのかを後から数えられ、水準の見直しに使える材料が手元に残ります。なお、モメンタムの転換そのものを判定に使いたい場合は、一目均衡表とMACDの組み合わせのほうが素直な構成になります。

どう活用するか

自作派の方は、Claude Code でcBotを書くときの下書きとして、「前提を決める条件」と「入らない条件」を最初から別々の関数に切り分けてみてください。一目均衡表を他の水準系の指標へ置き換えても、この分け方はそのまま使えます。

委託派の方は、ai-programming.xyz へ実装を相談する際、「この条件は入る理由ではなく除外として扱いたい」という前置きを添えると、仕様のすり合わせが短く済みます。教育派の方は、いま手元にある単一条件のロジックへ除外条件を1つだけ足す課題として扱うと、条件を引くという設計の意味を、手を動かしながら確認できます。

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