【週次・金融AI研究】ログ94,239バイトで何回売買？更新時刻と注文記録の違い

結論：94,239バイトから売買回数は数えられません

「新しいログが94,239バイトあれば、EAが何回売買したか分かるのでしょうか」。ファイルの大きさだけでは分かりません。11月1日06:10 JSTの引継ぎで、10月31日名のローカルMQL4ログの存在とサイズが報告されました。しかし、その本文は今回の引継ぎで解析されていません。ログが見つかったという進展と、注文内容の確認を分けるのがこの記事の結論です。

バイトは保存データの大きさを表す単位です。行数、候補数、発注数、約定数とは異なります。長い一行と短い一行が混じる記録から、一定のバイト数を一回の取引とみなすことはできません。記録形式や出力条件も照合していないため、サイズを平均的な取引回数へ換算する計算は今回行いません。

根拠：存在・サイズ・更新時刻が報告されています

主資料は20261031.logについて、94,239バイト、最終更新11月1日04:23:17 JST、SHA256の再計算値を記載しています。これは引継ぎ担当がローカルに保存されたファイルを確認した報告です。記事担当がそのファイルを全行読み、EAの受付や注文と照合したという意味ではありません。確認の種類を冒頭から明確にしておきます。

ファイル名には10月31日という日付が含まれますが、最終更新の表示は翌11月1日です。名称と更新時刻が別であることは読み取れます。ただし、ファイル名だけで本文内の全時刻のタイムゾーンや収録範囲を確定できません。更新時刻も、最後の注文時刻そのものとは限りません。今回はその対応が未確認なので、04:23:17を最終売買時刻として紹介しません。

前日の「未発見」と、今回の「存在」はどう読むか

10月31日朝の前回引継ぎでは、当日名のログはその時点の探索範囲で見つかっていませんでした。11月1日朝の今回引継ぎには、前日名のファイルが存在すると記載されています。新しい観測情報が増えたことは明確です。一方、その間のいつ生成されたか、どの処理が何を出力したかは、サイズと最終更新だけでは分かりません。

したがって「未発見から存在へ変わったので、EAが復旧した」とは書きません。前回は朝、今回は翌朝という確認時点の違いもあります。前回の探索がすべての環境を網羅していたと仮定したり、今回見つかったファイルが本番VPSと同じだと仮定したりもしません。どの場所で何を確かめたかという範囲を保つことが、変化の意味を過大にしない方法です。

0バイト、未発見、未解析は異なる状態です

補助資料には、10月28日のローカルMQL4ログが0バイトだったという過去の観測もあります。0バイトは存在するファイルのサイズについての情報です。未発見は探索範囲で所在を確認できない状態、未解析は内容をまだ調べていない状態です。今回の94,239バイトはサイズが0ではないという違いを持ちますが、そのことだけで正常な注文処理が書かれているとまでは言えません。

これらを全部「ログなし」とまとめると、次に必要な確認が曖昧になります。存在しないなら所在や生成条件、存在して空なら出力の条件、存在して未解析なら本文と対応記録を調べる、というように課題が変わります。これは調査の整理であり、今回の記事担当が取引環境へ入って操作したという報告ではありません。担当範囲内で資料の未確認箇所を残します。

時刻が違う資料を、そのまま一本の経路にしない

10月31日夕方の編集正本は18:33:59 JST締切で、heartbeatは18:32:57、取引集計は18:33:59の観測です。一方、今回のログ最終更新は11月1日04:23:17 JSTというファイル属性です。資料が新しい順に並んでいても、同じ試行の前後関係を示すとは限りません。更新日時の後に何が起きたかを推測で補いません。

夕方正本の対象EA0件、建玉0件という記載も、その集計範囲の観測です。今回のログサイズを使って「夜間も0件だった」あるいは「夜間に売買が再開した」と上書きする根拠はありません。期間を延長するなら、その後の注文・決済原票を別に確認する必要があります。日付をまたいだだけで前の集計を今日の実績へ移すことも避けます。

限界：記録が多いほど良い研究とは限りません

行が増える理由には、異なる種類のメッセージや繰り返しの出力などもあり得ます。しかし、今回は本文を解析していないので、どの理由で94,239バイトになったかは未特定です。可能性を列挙しただけで原因が分かったように書くことはしません。エラー率や処理速度、成功率を出すための分母も、サイズからは作れません。

金融AIの研究で知りたいのは、データが大きいかより、一つの判断が実際にどう扱われたかです。自作インジケーターの候補が、AIの応答、EA受付、注文、約定へどうつながったかという対応が必要です。本文が解析されていても、別環境の注文原票がなければ確定しない箇所は残ります。ログ一つですべての工程が説明できるとは扱いません。

今回の引継ぎは本番のロード版、実効設定、約定、損益の対応を直接確認していません。ファイルサイズの報告を実口座の成績へ翻訳することは、その限界を越えます。また、対応するトレード録画も未照合です。見つかった別の動画を挿入して、94,239バイトの中身を再現したように見せることもしません。

次に確認すること：本文と原票を同じ試行で結びます

次の資料では、ログの先頭と末尾の時刻、出力元、時刻体系、重複の扱いを確認し、その上で候補IDやticketを抽出する必要があります。記録上のBUYやSELLは方向の表記であり、その文字だけで約定を確定しません。注文受付と約定の記録が同じ候補に対応するか、欠けている工程はどこかを示す形が望まれます。

損益を評価する際は、約定と決済に加えて数量、通貨、手数料、スワップの資料をそろえます。ファイルのSHA256は解析対象を固定するために役立ちますが、解析結論の正しさまで自動的に保証しません。今朝の進展は、解析対象にできる保存ファイルの存在が報告されたことです。注文や収益の評価は、その後の対応確認まで保留します。

11月1日18:30の追補：ログが増えたことと、障害の解消は別です

夕方正本は、10月28日のMQL4当日ログ0バイト、10月29日のMQL4ログ17:42:58 JST停止とJSON監査18:37までの更新を区別しています。その後に朝の引継ぎで94,239バイトの保存ログが報告されても、各時点・各出力の違いを追わずに「停止原因が直った」とは言えません。停止と更新の差の原因は依然未確定です。

10月26〜29日の直接監査はほぼ全件WAITINGで、理由はex_indicator_ledger_missing_or_lockedでした。10月27日にREADYが1件出ても持続せず、10月31日早朝の356件もすべてWAITINGでした。これは監査状態の件数であり、356回の注文失敗という集計ではありません。ledgerがないのか、ロックされているのかの切り分けも未完です。

v1.09の「費用控除後利益余地3,000円」は当時の設計条件で、3,000円を稼いだ実績ではありません。青線、1Rの50％、2Rの75％追随等の出口条件も、次の自然取引でticketごとに初期SLからの順序と損切り位置を緩めないことを照合する課題です。試験のために注文を作らず、ログ本文と自然取引の原票が揃った段階で評価します。

出所と、この週次記事の位置づけ

朝の保存物・ログ・指示確認の主資料はLOCAL_CODEX_HANDOFF_2026-11-01_0610_JSTで、対象は10月31日06:10〜11月1日06:10 JSTです。10月31日18:33:59 JST締切の補助資料は過去の観測として残しました。11月1日19時の追補では、同日18:30 JST締切・18:31受領可能となった編集正本DAILY_BRIEF.md、trades.json、incidents.md、code_changes.md、video_refs.json等を追加照合しました。夕方正本の週次確認窓は10月26日00:00〜11月1日18:30 JSTです。記事担当が本番VPS・ブローカー原票を独立して再検査した報告ではありません。

金融AI・AIエージェントのAI研究開発として、自作インジケーターと自動売買ソフト（EA）の研究検証を続けています。平日24時間トレードライブ配信では研究経過を共有しています。配信の存在だけで収益性や全約定が証明されたとは扱いません。仕様や提供条件はGogoJungle内の販売ページで確認できます。販売の案内を含みます。

今回の日時・方向・ticketに対応すると照合済みのトレード録画は確認できていません。別の取引映像を今回の結果として使わず、本文中の説明図で確認範囲を示します。未確認の部分が一次資料で確定した場合は、その資料の時点と対象を明示して更新します。記事作成のための試験注文や売買設定の変更は行っていません。