トレーダーの道具箱 torebako.com

検証ラボ ── 2026-09-15

同じ結果をもう一度出せるようにする — このサイトで実際に使っている4つの仕掛け

検証は一度では終わりません。

数か月後に自分で見直しますし、間違いが見つかれば測り直します。そのとき同じ数字が出ないと、変わったのが手順なのかデータなのか間違いの修正なのか、区別がつきません。

このサイトで実際に使っている仕掛けを4つ書きます。どれも数行で済むものです。

前提

この記事は「こうすべきです」という一般論ではありません。手を動かして測っている最中に、必要になって足したものの記録です。

順番も、思いついた順ではなく失敗した順です。

仕掛け1:期間を1か所に書く

いちばん効いたのがこれでした。失敗したから作りました。

何が起きたか

22銘柄のティックを集計していて、2つの通貨ペアだけ2018年4月のデータが約21営業日分混ざっていました。他の20銘柄は2023年8月25日開始なのに、この2つだけ2018年4月開始だったのです。

**件数を見ても分かりません。ファイルサイズを見ても分かりません。**先頭のティックの日付を表示して、初めて気づきました。

どう直したか

期間の定数だけを持つ小さなファイルを1つ作り、全部の集計スクリプトがそれを読み込むようにしました。

中身は3行です。開始のミリ秒、終了のミリ秒、その範囲内かを返す関数。それだけです。

大事なのは中身ではなく、「各スクリプトで期間を指定する」をやめたことです。指定できるということは、指定し忘れられるということです。読み込む側にすると、忘れようがなくなります。

助かった実例

混入に気づいたとき、どの記事を直せばよいかがすぐ分かりました。

期間フィルタが元から入っていたスクリプトは、読み込み文があるかどうかを探すだけで特定できます。公開済みの2記事と時間帯別コスト計算機は元からフィルタがあったので無事でした。訂正が必要だったのは、予約中の6記事だけです。

「全部やり直し」にならなかったのは、どれが影響を受けるかを機械的に判定できたからです。

仕掛け2:乱数の種を書く

並べ替えの記事では、110万本のデータをランダムに並べ替えました。

このとき乱数の種(シード)を1に固定しました。種を書かないと、「値幅の自己相関が 0.3405 から 0.0011 になった」という数字を、二度と出せません。

一般的な乱数関数は種を指定できないことが多いので、種を指定できる数行の乱数を自分で書きました。アルゴリズムは古くからあるもので、暗号用途でなければこれで足ります。

記事にも「乱数の種は1つです」と限界として書いています。種を1つしか試していないことと、その1つが再現できることは、両方書く必要があります。

仕掛け3:入力データのスナップショットを取る

これは壊れる前に作った唯一のものです。

何が心配だったか

経済指標カレンダーは、ソフトの更新のたびに上書きされます。

ここで問題になるのが「予想値」です。発表前の予想が、発表後に書き換えられていないか。もし書き換えられていたら、プロの予想はどれくらい当たるのかで出した「予想は前回そのままより誤差3割小さい」という数字は、過大評価になります。

答え合わせの後で答えを書き直しているのと同じですから。

何をしたか

カレンダーを取得した日に、全ファイルを丸ごと別の場所にコピーしました。6.7MBです。あわせて、次に取得したときに差分を取るスクリプトを先に書きました。

そして「次にカレンダーを取り直したら、まずこれを実行すること」と編集メモに残しました。

正直に書くと

**まだ1回しか取得していないので、差分は取れていません。**作ったのは仕掛けだけです。

それでも先に作った理由は単純で、壊れてから作ると比べる相手がいないからです。上書きされた後にコピーを取っても、もう手遅れです。

差分ツール自体は、変化なしの場合と、3件の書き換えを人工的に注入した場合の両方で動作を確かめました。動くことだけは確認済み、という状態です。

仕掛け4:数字と一緒に取得日を書く

これはコードではなく、書き方の決まりです。

このサイトの記事の出典欄には、必ずこう書いてあります。

ティック(2023年8月25日〜2026年8月23日)と、同ソフトに付属する経済指標カレンダー(2026年8月26日取得)

期間と取得日が両方入っています。

3年分のティックのほうは期間が固定なので変わりません。カレンダーのほうは上書きされるので、取得日が無いと、あとで数字が合わなくなったときにどちらが正しいか判定できません。

配信データを検査した記事では、さらにデータソースの名前(どの契約段階のフィードか)まで書いています。同じソフトでも、契約によって配信されるデータが違うためです。

効果:間違いを直せるようになる

4つとも、検証の精度を上げる仕掛けではありません。上がるのは精度ではなく、間違いが見つかったときに何をすればよいか分かる度合いです。

実際に起きたことを並べると、こうなります。

起きたこと仕掛けが無かったら
2ペアに古いデータが混入していたどの記事が影響を受けるか手作業で確認するしかない
並べ替えの結果を後日確かめたくなった二度と同じ数字は出ない
カレンダーの予想値が書き換わっているかもしれない比べる相手が無いので永久に分からない
数字が他の資料と合わないいつ時点のデータかが分からず、原因を切り分けられない

**間違いは必ず見つかります。**このサイトでは、集計の間違いだけで8件記録しています。問題は間違えるかどうかではなく、見つかったときに直せるかどうかです。

いちばん大事な限界

再現できることは、正しいことではありません。

種を固定して同じ数字が出るのは、同じ計算をもう一度したからです。その計算が間違っていれば、間違いが正確に再現されます。

実際、期間フィルタを入れる前の11本のスクリプトは、毎回きれいに同じ間違った数字を出していました。再現性は完璧だったわけです。

再現できることは、間違いを直すための前提であって、正しさの証明ではありません。正しいかどうかは、対照を置く・粒度を変える・端で測らないといった別の方法で確かめるしかありません。

その他の限界

  • **ソフトのバージョンを記録していません。**配信元がデータを更新したら、同じ期間を指定しても違う数字が出る可能性があります
  • **実行環境(OSや処理系のバージョン)も記録していません。**小数の扱いが変われば末尾の桁が動きえます。今のところ問題は起きていませんが、確かめてもいません
  • スナップショットは1回分だけです。差分はまだ取れていません
  • 乱数の種は1つです。並べ替えのばらつき自体は見ていません
  • ここに書いたのはこのサイト1つの運用です。チームで回す場合に足りるかは分かりません

まとめ

  • **期間は1か所に書いて全部から読み込む。**指定できると指定し忘れる
  • **乱数の種を書く。**種を指定できる乱数を自分で用意した
  • **入力データのスナップショットを、壊れる前に取る。**後から取っても比べる相手がいない
  • **数字には取得日を添える。**期間・取得日・データの出所の3つ
  • **再現できることは正しいことではない。**間違いも正確に再現される

どれも数行です。効くのは、間違いが見つかった日でした。

出典

※本記事は情報提供を目的としたもので、特定のソフトウェアや手法の利用を推奨するものではありません。

← 検証ラボの記事一覧へ