日本祝日でも終日停止しない：東京時間だけAIへsoft cautionを渡す設計
金融AI／AIエージェント研究開発・市場コンテキスト
日本祝日でも終日停止しない：東京時間だけAIへsoft cautionを渡す設計
「祝日だから取引しない」という単純停止ではなく、流動性が薄くなりやすい東京コア時間だけを補助情報としてAIへ渡し、上位足構造を主判断に残しました。
本稿は、私が開発したインジケーターと自動売買ソフト（EA）を、AIエージェントと実口座で研究・検証している開発ログです。検証の様子は平日24時間のトレードライブ配信でも公開しています。
なぜ「祝日=停止」にしないのか
日本が祝日でも、GOLDはロンドン時間やニューヨーク時間に大きく動くことがあります。祝日という一つの属性だけで24時間停止すると、東京市場の注意点を海外時間まで引きずり、有効な機会まで失います。
一方で09:00から15:59 JSTの東京コア時間は、参加者構成や流動性が通常日と異なる可能性があります。薄い値動き、スプレッド拡大、短期ブレイクの失敗、遅い追いかけを普段より慎重に見る価値があります。
実装した時間境界
- 08:59 JST：soft caution無効
- 09:00 JST：有効
- 15:59 JST：有効
- 16:00 JST：無効
- 非祝日：終日無効
- 祝日ライブラリ異常：中立継続
日本祝日かつ東京コア時間のときだけsoft_caution_active=trueとします。条件外ではfalseです。祝日情報が取得できない場合も取引を全面停止せず、available=falseとして中立に戻します。
AIへ渡す補助文脈
soft cautionが有効な場合、Geminiはスプレッド拡大、tick比率低下、上位足競合、H1／M15確認のないM5単独ブレイク、リテスト不在の遅い追いかけ、長いヒゲによる失敗兆候を既存データから慎重に評価します。
重要なのは、この情報だけでskipを強制しないことです。PRIMARY=D1／H4、SECONDARY=H1／M15、ENTRY=M5の確定pivot列が主判断であり、祝日は補助情報です。相場構造を無視してカレンダーだけで売買しません。
多時間足ダウ構造との関係
AIへ渡すダウ理論は、一本のローソク足ではなく確定pivot列です。日足とH4で大きな方向、H1とM15で中間転換、M5で入口を見ます。形成中の足を除外し、確定情報だけを比較します。
東京時間のsoft cautionは、この三層構造へ「追いかけリスクを厳しく見る」という文脈を加えます。上位足と中間足が揃い、スプレッドと鮮度も正常なら、祝日であることだけを理由に入口を閉じません。
機械hard guardを優先する
AIが柔軟に解釈しても、warning signal、spread上限、重複防止、口座状態、発注安全網などの機械ガードは常に優先します。soft cautionはhard guardを弱めるものではなく、モデルへ追加の注意材料を与える層です。
さらに上位足がCOUNTER_TRENDで、GeminiがREVERSAL_ATTEMPT、中間足にWITH_TRENDまたはREVERSAL_BREAKがない場合は、祝日かどうかに関係なく機械的に見送ります。カレンダー文脈と転換確認を別々の責任として扱います。
試験で確認したこと
新しい隔離試験は8/8 PASSでした。08:59、09:00、15:59、16:00の境界、非祝日、ライブラリ未導入時の中立動作を確認しています。実データAPIを呼び出さない監査では、国民の休日、東京コア時間、soft caution有効、プロンプト生成まで確認しました。
既存回帰は変更前後で同一でした。既知ベースライン31/41、低頻度4/4、スプレッド6/6です。古い期待値とRELAX設定の不一致が残るため、「すべて合格」とはしません。
安全な配備手順
配備前heartbeatはopen_count=0、tickets空、ack_pendingなしを確認しました。一時停止中はEA5_ENTRY_ENABLED=False、通常入口は維持し、最終版配置後にEA5入口を戻しました。10:25 cronはNO_BREAKOUT、exit=0で正常終了し、receiverとfunda serviceのactiveを確認しました。
SL、TP、ロット、HOLD、warning hard block、receiver／cron処理、AutoTrading、MT4、GOLD13は変更していません。今回の差分はAIへ渡す祝日文脈とbasis保存です。
basisへ残す理由
AIが見送ったとき、後から「祝日だから」なのか「上位足競合だから」なのか分からなければ改善できません。そこで祝日名、東京コア時間該当、soft caution状態、rule versionをbasisへ保存します。
enterの場合も同じです。注意文脈が有効なのに入ったなら、どの相場構造とデータを根拠に上回ったのかを確認します。文章だけでなく、入力値と判定版を再現できる状態にします。
まだ確認できていないこと
自然な日本祝日×東京コア時間の候補が発生し、実際のGemini判断と保存basisに新しいcontextが含まれる場面は未観測です。したがってLIVE_VALIDATIONはPENDINGです。
テストで境界が正しくても、実市場ではデータ欠損、タイムゾーン、夏時間、ライブラリ更新、サービス再起動が影響します。次の自然候補で時刻、祝日名、判定、保存結果を通しで確認します。
評価する指標
- 祝日東京時間の候補数と注文数
- 見送り理由の分類
- 見送り後の最大順行・最大逆行
- 通常日とのスプレッド・tick比率差
- 東京時間外への誤適用件数
- basis欠損と時刻ずれ
祝日に取引数が減っただけでは成功としません。止めた候補が大きく伸び続けるなら機会損失です。通常日と同じ形式で比較し、慎重さが実際の損失抑制へ寄与したかを判断します。
記事と動画の扱い
対応する実取引が発生した場合だけ、ticket、口座、時刻が一致する録画を記事へ埋め込みます。祝日というテーマに合いそうという理由で別取引のチャート動画を使いません。取引がなければ、無理に映像を付けず、候補と稼働ログを検証結果として公開します。
結論
祝日をhard stopへせず、東京コア時間だけのsoft cautionへしたことで、海外時間の機会を残しながら薄商いの追いかけリスクをAIへ伝えられます。カレンダー、ダウ構造、機械ガードを一つへ混ぜず、それぞれの役割を分けました。
本番配備は完了していますが、自然候補でのLIVE検証はこれからです。配備済み、テスト済み、実市場確認済みを区別し、次の事実が得られた時点で更新します。
タイムゾーンを明示する
VPS、MT4、サーバーログ、記事公開時刻で表示する時間帯が違うと、09:00境界の判定を誤ります。祝日判定はAsia/Tokyoへ明示的に変換した時刻を使い、元のUTC、MT4 server time、JSTを記録します。単に画面の時計を見て境界試験を済ませません。
夏時間の影響を受けるロンドン・ニューヨーク時間と、日本の祝日判定を同じ固定オフセットへまとめないことも重要です。市場セッションは別計算、祝日コア時間はJST固定として責任を分けます。
祝日データの更新と障害
祝日ライブラリが古い、臨時休日が反映されない、読み込みに失敗する場合があります。そのとき取引を全面停止すると、外部データの小さな障害が24時間運用全体を止めます。今回はfail-neutralとし、取得不能をbasisへ残したうえで通常の相場構造とhard guardへ戻します。
ただし取得不能が続いていることを見逃さないよう、available=falseの回数と継続時間を監視します。中立継続は障害を無視する意味ではなく、取引作用と運用アラートを分離する設計です。
次の改善判断
十分な母数が集まる前に、祝日はすべて止める、あるいはsoft cautionを外す判断はしません。祝日東京時間、通常東京時間、祝日海外時間を分け、候補品質、見送り後の値動き、約定スプレッドを比較します。評価期間と最低件数を先に決め、後から都合のよい期間を選びません。
本稿は研究開発・実口座検証ログであり、利益や将来の性能を保証するものではありません。
