AI搭載EAのタイムアウト設計｜AIの返事が来ない時

AIに判定させてから発注する作りのEAを動かし始めて、数日後にログを見る。判定を要求した記録はあるのに、その後ろが空白のまま次の足へ進んでいる。エラーは出ていない。注文も出ていない。何が起きたのか分からないまま、その足は過ぎている。

外部に一往復挟む作りにした時点で、返事が返らない場面は必ず出る。相手のサービスが混んでいる、回線が一瞬詰まる、端末が別の処理を抱えている。どれもEA側のコードが正しくても起きることで、こちらから直しようがない。

決めておくべきなのは原因ではなく、そのとき何をするかの方だ。ここを決めていないと、いちばん都合の悪い形で動いてしまう。今回は、通信を挟むEAで着手前に書いておく項目を順に置いていく。開発を頼む側なら、そのまま確認事項として使える。

返事が来ないのは、壊れているからではない

通信するEAでよくある思い込みが、「返事が来ないのは異常なのだから、止まるのが正しい」というものだ。だが止まるのが正しいとは限らない。何もしなくなったEAは、すでに持っているポジションの面倒も見なくなる。

相手側の都合で返らない時間は、例外ではなく運用のうちに入る。だから手当ては一つしかない。起きる前提で、そのときの動きを先に書いておくことだ。異常のときに何を続けて何を止めるかは、まとめてではなく一つずつ決めていく。

何秒待つかを、先に決める

最初に決めるのは時間切れの秒数になる。何秒待って返事が無ければ諦めるか。ここを書かないと、使っているライブラリや端末側の既定値で待つことになる。その値は自分で選んだものではないし、環境が変われば黙って変わる。

上限は、足が変わるまでの時間より十分に短いところへ置く。長く取ると、足が変わってから答えが返る状態を許すことになる。判定を頼んだ場面と答えが届いた場面が別物になり、後から筋を追えない発注が残る。待つ側の都合で、見ている相場の方が動いてしまう。

秒数そのものは運用で違うので、ここではN秒とだけ書く。決め方は一つ、N秒待ってから注文を出しても成り立つ作りかどうかだ。数時間から数日持つ作りなら余裕がある。一本の足の中で何度も出入りする作りなら、そもそも外部に聞く構成が向いていない。

遅れて届いた答えは、もう使えない

時間切れで諦めた後に、返事が届くことがある。回線の向こう側は、こちらが諦めたことを知らない。ここで届いた答えをそのまま使うと、少し前の相場を見て出した判断で、今の値段に注文を出すことになる。値は動いているのに、判断だけが古い。

防ぎ方は、答えに「いつの判定か」を持たせることだ。問い合わせるときに、どの足を見て投げたのかを控えておく。使う直前に、いま発注しようとしている足と一致するかを照合し、違えば捨てる。判定は、それが作られた時点とセットでしか意味を持たない。

照合を一つ入れるだけで、通信が不安定な時間帯に妙な注文が出る経路が減る。捨てた回数もログに残しておきたい。あとから「その日は何回捨てたのか」を数えられる。数が多いなら、時間切れの秒数か、聞きにいく頻度の方を見直すことになる。

「壊れている」の定義を先に書く

返事が届いても、中身が期待どおりとは限らない。空で返る、決めた形式ではない文章が返る、想定していない語が入っている。相手はこちらの都合を知らずに返しているので、想定は簡単に外れる。しかもその外れ方は毎回違う。

場合分けを一つずつ書き足していくと、コードが増えるわりに、どこかで漏れる。決めた形以外は、まとめて「判定できなかった」に倒す方が早い。受け取る場所で形を検査し、通らなければ返事が無かった時と同じ道へ流す。分岐が一本で済むうえ、想定していなかった返り方も勝手にそこへ入る。

そのためには、返させる形をこちらから狭く決めておくことになる。返してよい語をあらかじめ限り、余計な説明を書かせない。自由に書ける余地を残すほど崩れ方の種類が増えていく。狭く決めておけば、壊れているかどうかの判定も短い一行で済む。

返事が無いとき、既定でどちらへ倒すか

ここが本題になる。判定が得られなかったときの既定動作は、AIをどこに効かせているかで変わる。同じ「返事なし」でも、構成が違えば正しい振る舞いは逆を向く。一律に「こうする」と決められない部分で、作る前に選んでおくところだ。

見送りのゲートとして使う構成なら、つまりテクニカルとAIの両方が揃ったときだけ発注する形なら、返事が無い時点でゲートは開かない。新規は出さない。判定できていない場面で取引を増やさない、という一点で筋が通る。

テクニカルと並列に置く構成なら、AIが黙ってもテクニカルの判定だけで動き続ける。当方の標準はこちらだ。ただしこれは返事が無くても平気という意味ではなく、AI抜きでも成立するルールが先にある、という前提の上に乗っている。

型が違っても、共通する一つがある。持っているポジションの決済は、判定が取れなくても動かし続けることだ。損切りも利確も、外部の返事とは関係のない場所にある。入口を止めるのと出口を止めるのは別の話で、後者まで巻き込むと、通信の不調が持ち高の管理そのものを止めてしまう。

入口は止めてよい。出口を止めてはいけない。

再試行の回数と、復旧した直後の一発

返事が無いとき、もう一度聞きにいくのかどうか。いくなら何回までか。再試行はそのまま待ち時間に乗るし、判定の回数として費用にも乗る。無制限にはできないので、上限をM回と決めて、超えたら判定なしとして扱う。

最後に、いちばん起きやすい事故を挙げておく。通信が復旧した直後に、同じ足で二度発注してしまうものだ。再試行の途中で先に一つ通っていた、前の足の判定が遅れて届いた、端末を立ち上げ直した。経路はいくつもある。

防ぎ方は単純で、判定を処理し終えた足を記録しておき、同じ足では二度と発注しない。注文を出せたかどうかではなく、その足の処理が済んだかどうかで見る。記録は端末を再起動しても残る場所に置くこと。落ちた後に立ち上げ直した瞬間が、いちばん二重に出やすい。

---

当方は元金融系のシステムエンジニアで、MT5のAI搭載EAをココナラで開発しています。返事が来ないときの既定動作も、上の項目を一緒に決めたうえでお渡ししています。売買ルールが箇条書きの段階でも、いま動いているEAに判定を足したい段階でも構いません。ココナラのメッセージからご相談ください。なお、お渡しするのはソフトウェアであって、投資助言や運用の代行ではありません。