損切り幅を広げれば負けは減る？3,500 JPY比較・H1案と翌週の検証条件
18:35追記の結論：損切り拡大・H1案は検証段階で、本番採用ではありません
損切りを2,500 JPYから3,500 JPYへ広げれば、今週の負けは減ったのでしょうか。10月24日18:35 JST締切の新資料はread-onlyの比較結果を示しましたが、戦略全体の最終損益差は未確定です。H1別構成も調査段階で、売買プログラムは未作成・未稼働。現行M5 v1.42とEA v1.26へH1由来の変更はなく、不採用だった旧M5向けレンジゲートも復活していません。仮想条件の比較と、実際に取引した結果を分けます。
根拠：建値条件が違えば、同じ9件でも結果が変わります
初期SL負け9件を対象とする2,500→3,500 JPYの比較では、建値発動を1,250 JPYに据え置くと、2件が建値水準へ回復、6件が3,500 JPY側へ到達、1件はデータ末尾で未決済相当でした。一方、リスク額自体を3,500 JPYへ変え、建値を0.5R＝1,750 JPYとすると、回避候補1件、3,500 JPY到達7件、未決済相当1件です。どちらも合計9件ですが、建値条件が異なるため同じ実験ではありません。
回避候補という呼び方は、現実に損失を回避した実績を意味しません。到達順序、後続注文への干渉、全追随、部分決済、スリッページを含めた戦略全体成績が未確定だからです。未決済相当の1件をゼロ損益で埋めることもできません。単に2件が建値へ戻ったから安全性が上がった、損切り幅を広げるべきだ、という推奨には使いません。
限界：H1とH4の判定例は、勝率を示しません
H1別構成では、H4の確定済み20EMAと30SMAの方向一致案、H1の20EMA付近へSLを利益側だけに追随する案が記録されています。10月21日のH1 BUY候補はH4逆方向で拒否、22日のH1 SELL候補はH4一致という例もありますが、これは条件の判定例です。利益を比較した成績表でも、勝率を検証した母集団でもありません。H1の初期SL、EMA余白、建値開始、通常スコープとの併用、箱期間と閾値はまだ未確定です。
運用品質の問題も残ります。10月20日以降のaccount score stale、runtime audit ledger missing/locked、structure shadowのclosed_24h_valid=falseについて、恒久原因と復旧は確認されていません。表示名だけで根本原因を特定したことにせず、最新時刻のデータと有効状態の継続を確かめる必要があります。監査件数が増えたことや候補が現れたことを、台帳が復旧した証拠にはしません。
次に確認すること：五つの入口条件
- v1.42の最初の自然確定クロスを、scope→signal→ACK→ticket→result→Drive mediaまで一気通貫で照合する。
- 3,500 JPY案は本番変更せず、到達順序をtick精度または十分な実サンプルで再検証する。
- H1案は未来参照なしの確定足、H4方向、SL余白、BE条件を事前固定してshadow評価する。
- account scoreとaudit ledgerのデータ鮮度を確認し、closed_24h_valid=trueの継続が確認できるまで運用品質を未解決とする。
- Drive正本の週次メディア欠落を解消する。ローカルだけの画像・動画を完了にせず、ticketごとの動画・entry/exit画像・trade_metaを照合する。
出所：Google Driveの2026年10月24日DAILY_BRIEF.md、18:35 JST締切、週次対象10/18 00:00〜10/24 18:35。AI研究開発・自作インジケーターとEAの研究検証として次の条件を整理しました。今回の記事編集で本番のリスク額や売買設定、VPS、AutoTrading、OBSは変更していません。平日24時間トレードライブ配信は活動として記載しますが、今週の出所確認済み録画は未整備で、別素材は埋め込みません。以下の朝08:08版は当時の監査・候補・途中集計の履歴であり、「最新」「現在」は朝資料の範囲に限定します。
朝08:08版の確認履歴：監査行数・スコア鮮度・取引の連結
結論：増えた行数だけでは、取引の検証完了とはいえません
監査ログが毎日増え、ハートビートも届いている。それならEA検証は順調に進んだといえるでしょうか。結論は、記録が増えたこと、記録を解析できたこと、実取引と対応したことを分ける必要がある、です。10月19〜23日の資料ではWAITINGが多く、古いスコアが残る一方で口座全体の決済も記録されています。監査の待機を、そのままEAの注文停止や取引なしに置き換えることはできません。
この週次レビューは金融AIとAIエージェントのAI研究開発、自作インジケーターとEAの研究検証の経過を整理するものです。週の対象は10月19〜23日、最新の補足は24日06:10 JSTの引継ぎです。監査行数を実績として大きく見せるのではなく、どの段階が確認でき、どこから先が未確認なのかを明らかにします。障害原因や復旧を確認していない段階で「直った」「正常」とも書きません。
根拠：火曜だけはREADYとWAITINGが混在していました
10月19日18:35:03 JST締切のDAILY_BRIEFでは監査694行がすべてWAITINGです。20日18:33:41 JST締切では監査873行のうちREADYが2行、WAITINGが871行でした。READYの理由はnew_ex_events_only_no_backfill、WAITINGの理由はex_indicator_ledger_missing_or_lockedです。したがって火曜分を「873行全部WAITING」とまとめるのは誤りです。小さな違いでも、状態の変化を記録する週次報告では残す必要があります。
21日18:30:11 JST締切は1,047行すべてWAITING、22日18:34:24 JST締切は1,051行すべてWAITING、23日18:34:43 JST締切は1,054行すべてWAITINGです。これらは各締切で見た監査記録の件数で、同じ累積記録を含む可能性があります。五日分を足して週の注文回数やユニークな取引回数にしてはいけません。差分が何を表すかも、各行の対象IDと時刻を確認してから判断します。
理由名にmissing_or_lockedとあっても、ファイルが存在しないのか、ロック中なのか、参照場所、権限、書き手、解析形式のどこに原因があるかは、この表示だけでは確定しません。表示名を日本語の確定診断に変換しないことが大切です。READYの二行も、注文が二件成功した証拠ではありません。監査の準備状態と、AIの判断、注文送信、約定は別の段階です。
図解：監査・候補・口座結果の三つの箱
図では、監査の状態、スコアの鮮度、取引との連結を別の箱にしています。監査が動くから取引が健康、候補が出るから約定した、という短絡を避けるためです。箱の間をつなぐのは、同じ事象に属するsignalIDやticket、時刻です。数字だけを横に並べても、対応表の代わりにはなりません。監査の改善を報告するときも、どの箱の何が変わったのかを限定します。
限界その一：古いスコアのゼロは、今日のゼロではありません
火曜以降の資料で問題になったのは、スコアの更新時刻が10月20日02:59:08 JSTのまま残っている点です。現在時刻のハートビートが届いていても、別ファイルのスコアが新しくなった証拠にはなりません。水曜には口座全体の1決済、木曜にも1決済、金曜には7決済の途中集計が別に記録されています。古いスコアだけを見て「その後ずっと取引ゼロ」と説明すると、同じ週の別の観測と食い違ってしまいます。
ここでは取得時刻と生成時刻を分けます。今日ファイルを読めたとしても、中身が今日生成されたとは限りません。今後の監視表では、読取り成功の欄だけでなく、データが最後に更新された時刻、対象期間、対象の口座とEAを置く必要があります。値がゼロでも、更新が古い場合は数値そのものを現在の事実として採用しません。ゼロと不明を区別することで、成績の過大評価だけでなく、不必要な障害断定も避けられます。
限界その二：シグナル件数は、売買回数ではありません
自然シグナルは月曜80件、火曜74件、水曜84件、木曜101件、金曜107件と各日の資料にあります。ただしこれは表示・候補の記録であり、その数だけ注文を出した意味ではありません。金曜の107件はBUY37、SELL70という方向別の内訳と、warn 0・1・2が46・13・48という警告別の内訳を持ちます。同じ107件を別の軸で分類しているため、両方を足して214件の観測とはしません。
金曜の補助観測211件にはclosed24h有効0、M1有効39、M5有効209という独立フラグもあります。M1とM5は相互排他的な分類ではないため、39と209を足して全体件数と比較したり、211件のうち248件が有効と書いたりできません。必要な24時間条件が成立していないことと、短い時間足の一部データが有効であることは両立します。どの条件で何を判定する設計かを先に示します。
さらに24日06:10 JST引継ぎには、前日のローカルログでSELL候補が二行観測されています。bar時刻17:30:00・表示価格3977.79と17:40:00・3994.81ですが、bar時刻のタイムゾーン、signalID、ticketとの対応は未確認です。この二つの価格を引いて利益やスプレッドに換算したり、金曜の7決済のうち二件と対応づけたりしません。警告0という表示も、AI承認済みや約定済みの印ではありません。
次に確認すること：復旧の条件を、件数ではなく接続で決める
次に必要なのは、監査の入力元と読取り条件を確認し、待機理由を特定し、同じ事象が候補から注文と結果までつながるかを再確認することです。参照場所や権限の検査は調査であり、取引設定の変更とは分離します。原因が不明なまま監査件数が増えたことを、復旧の完了条件にはしません。再び読めたときも、過去分が遡って埋まるのか、新しい事象だけが対象なのかを確認する必要があります。
平日24時間トレードライブ配信は、表示と時系列の対応を補う材料です。ただし今回の週次対象では取引ごとの出所確認済み録画がそろっていません。無関係な映像を添えて検証済みの印象を作らず、確認できた資料から説明します。現時点では監査の行、候補の行、口座集計の行を独立に保管し、共通IDが見つかった箇所から対応表を埋める方針です。
読者が次の報告で注目すべきなのは、監査が何行増えたかより、生成時刻が新しくなったか、待機理由が証拠で特定されたか、個別取引の入口と出口がつながったかです。候補数や監査量をAIの精度や利益率として扱わないことが、研究を正しく読む近道になります。FXやGOLD、自動売買には損失リスクがあり、ログや検証の充実が将来の利益を保証することはありません。
週次の見せ方：状態の変化だけを確定範囲で示す
監査の一覧には各日の締切を付け、状態ごとの件数を残すようにします。たとえば火曜の二行がREADYだったことは、他の日がすべてWAITINGだったという見やすい物語に合わせて消しません。一方で、その二行を復旧の継続や注文の成功へ拡張もしません。状態が一度変わった事実と、その状態が持続した事実は違います。同様に障害の報告が増えなかったことも、全経路の健康を確認したこととは区別して扱います。
出所と研究ページ
出所はGoogle Drive保管の10月19〜23日付DAILY_BRIEF.md各締切版と、LOCAL_CODEX_HANDOFF_20261024_0610.mdです。日別件数は締切時点の記載値で、全週の重複排除済み台帳ではありません。この記事の作成によるEA、インジケーター、VPS、AutoTrading、配信設定の変更はありません。AI主導で入口から出口まで自ら判断する構想も、最新資料では未実装・未配備のままで、監査ログの増加をその完成の証拠にはしていません。
研究中の商品仕様・提供状況はGogoJungle内の販売ページで確認できます。直近確認時は販売中止表示のため、購入可能と案内するものではありません。記事の数字は過去の研究記録で、将来の利益や損失回避の保証ではありません。
