この記事で分かること
※本記事は教育目的の解説であり、特定の投資戦略の推奨ではありません。売買判断の材料となる戦略やパラメータは一切提示せず、扱う範囲は「検証設計の方法論」に限定しています。
結論：バックテストの品質は「結果を見る前に何を決めたか」で決まる
バックテストの成績が良く見えるとき、その大半は戦略が優れているからではなく、検証の設計に穴があるからです。そして穴の多くは、結果を見た後では見つけられません。良い数字が出てしまうと、人は無意識にその数字を守る方向に検査を緩めるからです。だからこそ、順序を逆にします。結果を出す前に「どういう結果なら疑うか」を書き留めておく——これが本記事の中心にある考え方です。
過学習やデータリークが「なぜ」起きるのかという概念そのものは、ファイナンスのための機械学習入門で解説済みです。本記事はその概念を繰り返しません。役割分担ははっきりしています。概念は既存記事、本記事は「検査手順とチェックリスト」です。手を動かして判定できる形に落とすことだけを扱います。
AIが関わる場面は主に2つあります。1つはバックテストのコードをAIに書かせる場面。もう1つは結果の解釈や要約をAIに手伝わせる場面です。どちらも便利ですが、前者ではAIが書いたコードに未来情報が紛れ込みやすく、後者ではAIが「良い結果」を肯定的に要約しがちです。人が担うのは、事前登録の作成、リーク検査の合否判定、コスト前提の決定、そして「この検証は失敗だった」と結論づける判断です。
バックテストの工程：どこで何を止めるか
検証は6つの工程に分かれます。重要なのは、工程③（リーク検査）と工程⑥（頑健性確認）がゲートだという点です。ここを通らなければ先に進まない、通らなかったら①に戻る、という運用にします。工程④で結果が出てから設計を変えると、その時点で検証は「探索」に変わり、統計的な意味を失います。
工程①：事前登録シートを先に書く
臨床研究で用いられる事前登録（プレレジストレーション）の考え方を、検証設計に持ち込みます。目的は単純で、結果を見た後にルールを書き換える余地をなくすことです。以下の7項目を、データに触れる前に紙かテキストファイルに書き、日付を入れて保存します。共有ドライブに置いて上長の目に触れるようにすると、なお有効です。
| 項目 | 書くこと | 記入例（架空・様式の見本） |
|---|---|---|
| 1. 仮説 | 検証したい命題を1文で。「儲かるか」ではなく「〜という関係が観測されるか」の形にする | 指標Xが高い銘柄群と低い銘柄群で、翌月のリターン分布に差が観測されるか |
| 2. 対象期間 | 開始日・終了日。検証用に温存する期間（ホールドアウト）も先に切り分ける | 2018-01-01〜2023-12-31を検証、2024-01-01〜2025-12-31は開封禁止で温存 |
| 3. ユニバース | 対象銘柄の定義と、各時点でどう決まるか。上場廃止銘柄の扱いを明記 | 各月末時点で東証プライム上場かつ時価総額上位500銘柄。以後の廃止銘柄も廃止日まで含める |
| 4. 売買ルール | 発注タイミング・約定価格の仮定・リバランス頻度・保有銘柄数 | 月末営業日にシグナル生成、翌営業日の始値で約定、20銘柄等金額、月次リバランス |
| 5. 評価指標 | 主指標1つと従指標2つまで。後から指標を追加しない | 主：コスト控除後の年率リターン／従：最大ドローダウン、月次勝率 |
| 6. 中止条件 | どうなったら「この検証は不成立」とするか。数値で書く | 日付を1営業日後ろにずらすと主指標が半分以下になる場合／廃止銘柄の復元で主指標が2pt以上下がる場合は再設計 |
| 7. 試行回数の上限 | パラメータ探索を含む実行回数の上限。超えたら結論は「保留」にする | 上限20回。実行のたびに日時・変更点・主指標を1行ずつ追記する |
6番の中止条件が、この様式でいちばん効きます。多くの現場では「結果が良かったので採用」「悪かったので条件を変えて再挑戦」という運用になりがちですが、再挑戦の回数が増えるほど偶然の良い結果を引く確率が上がります。上限と中止条件を先に決めておけば、この滑りを止められます。なお、評価指標の選び方そのものはリスク調整後リターンの指標で整理しています。戦略の類型についてはヘッジファンド戦略入門、ファクター投資の枠組みを参照してください（本記事では特定の戦略の是非は扱いません）。
6つのバイアス：症状 → 検査方法 → 対処
バックテストを歪める要因は数え上げればきりがありませんが、実務で先に潰すべきものは6つに集約できます。それぞれについて「どういう症状で現れるか」「どう検査するか」「見つかったらどうするか」を決めておけば、検証は再現可能な作業になります。
| バイアス | 症状 | 検査方法 | 対処 | 日本市場固有の落とし穴 |
|---|---|---|---|---|
| ① ルックアヘッド バイアス 未来の情報を使う | 成績が不自然に安定し、負けの月がほとんど無い。特定の指標を入れた瞬間に成績が跳ねる | 全シグナルの日付を1営業日後ろにずらして再実行。成績が大きく落ちるなら未来情報が入っている疑いが濃い | 各データ列に「値が確定する日」を定義書として作り、結合キーをその日付に統一する | 決算発表日と決算期末日の取り違えが典型。3月期末の数値を4月頭から使えるはずはなく、実際の入手可能日はTDnetの適時開示で決算短信が出た日以降。開示日はTDnetの適時開示情報閲覧サービスで確認できる（無料公開は開示日を含む31日分） |
| ② サバイバーシップ バイアス 生き残りだけを見る | 下落局面の損失が実感より小さい。長期になるほど成績が良くなる | 検証期間中の上場廃止・統合・非上場化の件数を数える。件数がゼロなら、データ側が現存銘柄だけになっている | 廃止銘柄を廃止日まで含め、廃止時の価格を明示的に定義する（最終売買日の終値か、ゼロ評価か） | 株式移転・株式交換による持株会社化や経営統合で証券コードが変わる例が多く、単純な銘柄コード結合では系列が途切れる。上場廃止基準に該当した銘柄の扱いを先に決める |
| ③ 過学習 探索回数に対しデータが少ない | 期間を1年ずらす、ユニバースを少し変える、といった小さな変更で効果が消える | 独立な観測数（月次なら期間数）と、試したパラメータ組み合わせ数を並べて記録する。温存したホールドアウト期間で1回だけ確認する | パラメータを減らす。細かい閾値の最適化をやめ、粗い区分に丸める。ホールドアウトは最後に1回だけ開封する | 日本株の月次データは1銘柄あたりの期間が限られ、業種構成も偏りやすい。少数の大型銘柄が結果を左右していないか、寄与の内訳を必ず確認する |
| ④ 取引コスト 手数料・税 | 高回転の設計なのに、費用が「年0.1%」といった率だけで語られる | 年間売買代金を先に計算し、手数料率を掛けて金額に直す。運用資産に対する比率へ戻して主指標から引く | 売買代金・手数料・税を別行で計上した明細表を作る。税は運用主体（法人・個人・年金等）の前提を必ず明記する | 個人の課税口座では上場株式等の譲渡益に20.315%（所得税15%・復興特別所得税0.315%・住民税5%）がかかり、高回転の設計ほど影響が大きくなります。前提を書かずに比較すると、主体の違いで結論が変わってしまいます |
| ⑤ スリッページ・ 流動性 想定価格で約定しない | 小型・低流動の銘柄ほど成績が良く見える。約定価格が常に理想的 | 各銘柄の想定発注金額を、直近の平均売買代金と比べる。比率が高い銘柄を除外して再実行し、結論が変わるか見る | 約定価格の仮定を明示（始値・終値・VWAPのいずれか）。発注金額に上限を設ける。低流動銘柄をユニバースから外す | 東証には基準値段に応じた値幅制限があり、制限値幅まで動いた日は想定価格で約定できないことがあります。売買が成立しない場合のストップ配分も現実には起こります。浮動株比率の低い銘柄は特に注意 |
| ⑥ データ スヌーピング 同じデータで何度も試す | 「いろいろ試した結果これが一番良かった」という説明しか出てこない | 実行ログ（日時・変更点・主指標）を数える。ログが無ければ、その検証は再現不能とみなす | 試行回数を報告書に明記し、多重検定の影響を注記する。上限を超えたら結論を「保留」とし、新しいデータを待つ | 日本株の検証は使えるデータ提供元が限られ、同じ提供元のデータを業界全体で繰り返し使う構造になりやすい。自分の試行回数だけでなく、その論点が業界でどれだけ試され尽くしているかも考慮する |
市場区分に関するもう1つの論点があります。2022年4月の東証の市場区分再編により、市場区分を条件に使ったユニバース定義は再編前後で意味が変わります。再編前の期間に「プライム上場」という条件をそのまま適用することはできず、当時の区分に読み替えるか、時価総額など区分に依存しない条件に置き換える必要があります。区分の定義は東証の市場区分で確認してください。株式分割・併合の遡及調整も同様で、調整済み株価と未調整株価が混在すると、分割日に巨大なリターンが生まれます。
AIに戦略を作らせると起きる典型的なリーク
AIにバックテストのコードを書かせると、動くコードは短時間で手に入ります。問題は、動くことと正しいことが別だという点です。AIは「移動平均でシグナルを作って」といった指示に対して、統計的には自然でも時系列的には成立しないコードを書くことがあります。以下の4類型は、実際に頻出する形です。
| リークの型 | 何が起きているか | 直し方 |
|---|---|---|
| A. rolling計算のシフト漏れ | 20日移動平均を当日終値まで含めて計算し、その値を当日の売買判断に使っている。当日の終値は取引開始前には分からない | シグナル系列を1期分ずらす（当日の判断には前日までの値だけを使う）。ずらす日数を事前登録に書いておく |
| B. 全期間での標準化 | 指標を「全期間の平均と標準偏差」で標準化している。全期間の平均は将来を含むため、過去時点では計算できない値が入り込む | その時点までのデータだけで標準化する（拡大窓または移動窓）。分位点によるランク付けも同じ扱いにする |
| C. 欠損の後方補完 | 欠損値を「次に現れた値」で埋めている。未来の値で過去を埋めており、決算データや財務指標で特に起きやすい | 前方補完に限定するか、欠損時点はユニバースから除外する。補完の方針を1つに決めて全列に適用する |
| D. 決算期末日での結合 | 財務データを決算期末日で株価データに結合している。実際には発表日まで入手できない情報を、期末日の翌日から使ってしまう | 結合キーを決算発表日（適時開示の公表日）に変え、さらに翌営業日から利用可能とする。発表日が取得できない列は検証対象から外す |
加えて、学習と検証の分割がランダム分割になっているケースもあります。時系列データを無作為に分割すると、未来の観測が学習側に入り、検証側の成績が実力以上に良く出ます。時間で区切る分割になっているかは必ず確認します。データ取得の実装そのものはPythonで財務データを取得するで扱っています。
ネガティブコントロール：わざと壊して成績が消えるか
リーク検査でもっとも確実な方法は、意図的に情報を壊してみることです。理屈のうえで成績が消えるはずの操作をして、実際に消えるかを見ます。消えなければ、どこかに未来情報が残っています。
- 日付ずらし：全シグナルを1営業日後ろにずらす。1日の遅延で主指標が半減するなら、当日情報に依存しています。
- ラベルのシャッフル：将来リターンを銘柄間で無作為に入れ替える。この状態で主指標がゼロ近傍にならなければ、計算経路のどこかに漏れがあります。
- 無意味な指標：乱数から作った指標で同じ手順を回す。成績が出てしまうなら、手順そのものが成績を生んでいます。
3つとも、期待される結果は「成績が消えること」です。消えなかったときだけ調べればよいので、検査の負担は小さく済みます。なお、乱数を使った検証の考え方はモンテカルロシミュレーションと地続きですが、本記事では確率分布の設計そのものには立ち入りません。
数値例：取引コストを入れる前と後（架空データ）
以下はすべて架空のデータであり、実在する戦略・銘柄・運用実績とは一切関係ありません。仮設のリサーチチーム「木挽町クオンツラボ」が、ある指標に関する検証を行った際の内訳という設定です。単位は百分率（年率）と百万円で統一します。
前提：運用資産1,000百万円、保有20銘柄の等金額、月次リバランス、毎月5銘柄（保有の25%）を入れ替え。したがって月間の売買代金は売却250百万円＋購入250百万円＝500百万円、年間では500×12＝6,000百万円（運用資産の6.0回転）です。手数料は約定代金の0.05%、スリッページは約定代金の0.20%と仮定します。
| 段階 | 年率リターン | 差分 | 金額（百万円） | 計算根拠 |
|---|---|---|---|---|
| ① 初回集計（グロス） | 12.0% | — | 120 | 現存銘柄のみ・決算期末日で結合したままの集計 |
| ② 上場廃止銘柄を復元 | 9.5% | −2.5pt | 95 | 廃止・統合銘柄を廃止日まで含めて再集計 |
| ③ 決算発表日基準に修正 | 7.2% | −2.3pt | 72 | 財務データの利用開始を発表日の翌営業日に変更 |
| ④ 手数料控除後 | 6.9% | −0.3pt | 69 | 6,000 × 0.05% ＝ 3百万円（＝0.3%） |
| ⑤ スリッページ控除後 | 5.7% | −1.2pt | 57 | 6,000 × 0.20% ＝ 12百万円（＝1.2%） |
| ⑥ 税控除後（実質） | 4.5% | −1.2pt | 45 | 57 × 20.315% ＝ 11.58 → 約12百万円（＝1.2%） |
検算します。率で追うと 12.0 − 2.5 ＝ 9.5、9.5 − 2.3 ＝ 7.2、7.2 − 0.3 ＝ 6.9、6.9 − 1.2 ＝ 5.7、5.7 − 1.2 ＝ 4.5。控除の合計は 2.5＋2.3＋0.3＋1.2＋1.2 ＝ 7.5pt で、12.0 − 7.5 ＝ 4.5 と一致します。金額でも追えます。運用資産1,000百万円に対し、コスト前の③は72百万円。手数料3百万円とスリッページ12百万円を引いて 72 − 15 ＝ 57百万円。税は 57 × 20.315% ＝ 11.58百万円なので、57 − 12 ＝ 45百万円（丸め）。45 ÷ 1,000 ＝ 4.5% で率と一致します。
取引コストを入れる前と後の対比は、③の7.2%と⑥の4.5%です。差は2.7pt。コスト前に対する割合は 2.7 ÷ 7.2 ＝ 37.5%で、リターンの4割近くがコストで消えた計算になります。年間売買代金6,000百万円という回転率がこの結果を作っているので、リバランス頻度を月次から四半期に落とせば売買代金は4分の1になり、手数料とスリッページの合計15百万円も概ね4分の1に近づきます。回転率はコスト構造そのものだという事実は、事前登録の段階で意識しておく価値があります。
税率20.315%は上場株式等の譲渡益に対する申告分離課税の税率（所得税15%・復興特別所得税0.315%・住民税5%）で、この設例では個人の課税口座を前提としています。運用主体が法人や年金基金であれば扱いは全く異なります。前提を書かずにコスト後の数値を並べると、比較そのものが成立しません。
AIに任せる部分と人が判断する部分
この工程でAIが有用なのは、機械的に読める形の点検です。逆に、判定基準そのものと合否の判断は人が持ちます。
| 工程 | AIに任せてよいこと | 人が決めること |
|---|---|---|
| ① 事前登録 | 記入漏れの指摘、仮説文の曖昧さの言い換え候補の提示 | 仮説の内容、中止条件の数値、試行回数の上限 |
| ② データ準備 | 列ごとの「値が確定する日」の一覧化、結合キーの不整合の列挙 | 廃止銘柄の評価方法、欠損の扱いの方針 |
| ③ リーク検査 | コードの行単位の指摘（シフト方向・標準化の範囲・補完の向き・分割方法） | 指摘の採否、ネガティブコントロールの合否判定 |
| ⑤ コスト反映 | 明細表の作成、率と金額の相互検算 | 手数料率・スリッページ率・税の前提 |
| ⑥ 頑健性確認 | 結果表の差分の要約、感度の一覧化 | 「結論が反転した」と判断する基準、検証の中止 |
ここで注意したいのは、AIに結果の解釈をさせると肯定的な要約に寄りやすいことです。「この結果をどう評価しますか」と聞けば良い面を並べます。そうではなく「この結果を疑うとすれば、どの前提が最も脆いですか」と聞く形にすると、検査として機能します。プロンプトの一般的な設計は金融実務のためのプロンプトエンジニアリングにまとめてあります。
プロンプト例：AI生成コードのリーク検査
次のプロンプトは、特定のAI製品に依存しない汎用の形です。コード全文とデータ定義書を貼り付けて使います（機密の扱いは後述）。
【役割】 あなたは定量リサーチのコードレビュー担当です。バックテスト用コードに含まれる 「未来情報の混入（ルックアヘッド）」の検出だけに集中してください。 【目的】 添付コードが、各時点で実際には入手できない情報を使っていないかを点検し、 該当箇所を行番号つきで指摘する。 【入力資料】 ・backtest.py（全文を下に貼付） ・データ定義書：列名／その列の値が確定する日／欠損の発生条件 ・対象期間：2018-01-01〜2023-12-31（月次リバランス、日次終値データ） 【前提・単位】 ・シグナル生成は当日の取引開始前に完了しているものとする。 ・財務データは決算発表日の翌営業日から利用可能とする（決算期末日ではない）。 ・リターンは年率（%）、金額は百万円。 【点検項目】各項目に「該当あり／該当なし／判断不能」を必ず付すこと。 1. rolling / ewm / expanding のウィンドウに当日値が含まれ、それを当日の売買判断に使っていないか 2. shift の方向と日数（負方向のシフトは未来参照。意図が読めなければ指摘） 3. 標準化・正規化・分位点計算を全期間データで行っていないか 4. 欠損補完に後方補完や前後両方向の補間を使っていないか 5. 学習・検証の分割が時間順か（無作為分割になっていないか） 6. 財務データの結合キーが決算発表日ではなく決算期末日になっていないか 7. ユニバース選定に、その時点では未確定の情報（後年の時価総額、存続の有無）を使っていないか 8. 取引コストとスリッページが計上され、率と金額の両方を出力できるか 【出力形式】 表（列：No／点検項目／判定／該当行番号／根拠／修正案の1行要約）。 表の後に「重大度の高い順の上位3件」を各3行以内の箇条書きで。 【計算方法】 修正案でシフト量を提案する場合は、何営業日ずらすかを数値で示す。 【禁止事項】 ・戦略の良し悪し、期待リターンの評価、改善案の提案はしない。 ・コードに書かれていない仕様を推測で補わない。 ・「問題ありません」という総括だけの回答は不可。 【不明情報の処理】 データ定義書に「値が確定する日」の記載がない列は判定を「判断不能」とし、 確認すべき事項を1行で書く。推測で「該当なし」としない。 【出典の表示】 すべての指摘に該当行番号を付す。行番号を特定できない指摘は書かない。 【検算】 最後に、点検項目8件すべてに判定を付けたかを自己確認し、 付けていない項目があれば列挙する。 【レビュー項目】（人間側の確認用に列挙すること） ・「該当なし」と判定した項目のうち、根拠が1文しかないもの ・「判断不能」の件数と、その解消に必要なデータ
出力例（抜粋・イメージ）
| No | 点検項目 | 判定 | 該当行 | 修正案（要約） |
|---|---|---|---|---|
| 1 | rolling に当日値 | 該当あり | L48 | シグナル系列を1営業日ずらす |
| 3 | 全期間での標準化 | 該当あり | L71-L73 | その時点までの窓に変更 |
| 6 | 結合キーの日付 | 判断不能 | L102 | 財務データの発表日列の有無を要確認 |
| 8 | コスト計上 | 該当あり | — | 計上箇所なし。売買代金の集計を追加 |
この出力をそのまま結論にしないことが重要です。AIが「該当なし」とした項目こそ、人が根拠を読み直します。特に、AI自身が書いたコードをAIに検査させると見落としが起きやすいので、可能ならコードを書いたセッションとは別のセッションで検査させます。
検証方法：この作業に固有の確認項目
AI出力の一般的な検証手順（出典の実在確認→数値転記→計算再現→論理整合）は生成AI出力の検証手順に譲ります。バックテスト設計に固有の確認は次の5点です。
- 行番号の実在確認：AIが指摘した行番号を実際に開き、その行が指摘どおりの処理をしているか。存在しない行や別の処理を指している場合、その指摘は棄却します。
- 指摘の再現：指摘を反映したコードで再実行し、主指標が実際に変化するか。変化しないなら、その指摘は結果に影響していないか、反映が効いていません。
- ネガティブコントロールの合否：日付ずらし・ラベルシャッフル・乱数指標の3つで成績が消えるか。1つでも消えなければ工程③のゲートは不合格です。
- コスト明細の相互検算：率で計算した控除幅と、金額で計算した控除幅が一致するか。本記事の設例では0.3%＝3百万円、1.2%＝12百万円で対応を確認しました。
- 試行回数ログの照合：報告書に書いた試行回数と、実行ログの件数が一致するか。差があれば、記録漏れか報告漏れです。
機密情報・個人情報の注意
バックテストのコードには、契約データベースの接続情報や、自社の運用パラメータ、顧客口座に紐づく情報が混じることがあります。外部のAIサービスに貼り付ける前に、接続情報・実口座の残高・個人が識別できる情報を除き、必要ならダミー値に置き換えてください。組織としての線引き（何を入れてよく、何がいけないか）は生成AIに入れてよい情報・いけない情報で整理しています。
データ提供元の利用規約にも注意が必要です。JPXのサイト利用条件は、契約に基づく場合等を除く商用目的のデータ収集・二次利用を認めておらず、生成AIによる学習・解析・生成での利用についても制限を置いています（2026-08-03確認）。EDINETの利用規約も、API以外の機械的取得を原則として禁じ、二次利用時には編集・加工を行ったことと主体の記載を求めています（同）。検証用データの調達方法は、規約の確認から始めてください。
よくある失敗
- 結果を見てから事前登録を書く：形式だけ整っていても機能しません。作成日時が分かる形で、データに触れる前に保存します。
- 「バイアスは分かっている」で検査を省く：知識として知っていることと、実際に検査して合否を出すことは別です。6バイアスは毎回、判定を書き残します。
- コストを率だけで語る：「手数料は年0.1%程度」といった記述は、回転率が変わると成立しません。年間売買代金から金額を出し、率に戻します。
- 良い結果が出たときだけ検査を緩める：これが最も起きやすい失敗です。中止条件を先に数値で決めておくことでしか防げません。
- AIが書いたコードをそのまま信じる：動作することと、時系列的に成立していることは別問題です。リーク検査を通していないコードの結果は、報告書に載せません。
実務チェックリスト（18項目）
工程順に並べています。すべてに「済／未／該当なし」を記入し、未が1つでも残る間は結論を出しません。
- 1. 仮説を1文で書き、どういう結果なら棄却するかを先に定義した
- 2. 対象期間を開始日・終了日で固定し、ホールドアウト期間を切り分けた
- 3. 評価指標を主1つ・従2つまでに絞り、後から追加しないと決めた
- 4. 試行回数の上限と中止条件を数値で書き、日付つきで保存した
- 5. ユニバースに上場廃止・統合・非上場化した銘柄が含まれている（件数を確認した）
- 6. 株式分割・併合・株式移転の遡及調整が全期間で一貫している
- 7. 配当の扱い（トータルリターンか価格リターンか）を明示した
- 8. 財務データを決算発表日で紐づけ、翌営業日から利用可能としている
- 9. 市場区分再編や指数構成銘柄の入替の扱いを記録した
- 10. rolling・shift のずらし方向と日数を1本ずつ確認した
- 11. 標準化・正規化・欠損補完を「その時点までのデータ」だけで行っている
- 12. 学習と検証が時間で分離されている（無作為分割になっていない）
- 13. ネガティブコントロール3種で成績が消えることを確認した
- 14. 手数料・スリッページ・税を金額で計上し、資産比の率に戻して検算した
- 15. 約定価格の仮定（始値・終値・VWAP）を明示し、値幅制限の影響を検討した
- 16. 想定発注金額が対象銘柄の平均売買代金に対して過大でないことを確認した
- 17. 期間・ユニバース・パラメータを動かしても結論が反転しないことを確認した
- 18. 実行ログの件数と報告書に書いた試行回数が一致し、多重検定の影響を注記した
この18項目は、金融庁「モデル・リスク管理に関する原則」（2021年11月12日）が示す、モデル開発・検証・継続モニタリングを分離して記録するという考え方とも整合します。同原則の直接の適用対象は本邦G-SIBs・D-SIBs等に限られますが、「検証の記録を残す」という発想は組織の規模を問わず有効です。
面接での答え方（30秒回答例）
質問例：「バックテストの結果を、あなたはどう信用しますか」
「結果そのものより、結果が出る前に何を決めていたかを見ます。仮説・期間・ユニバース・評価指標・中止条件・試行回数の上限を先に書き、それから1回だけ回す。次に、日付を1営業日ずらす、ラベルを入れ替える、乱数の指標を使う、という3つの操作で成績が消えるかを確認します。消えなければ未来情報が残っています。最後に、年間売買代金から手数料とスリッページを金額で計上し、率に戻して主指標から引きます。私の設例では、この工程で年率が7.2%から4.5%まで下がりました。ここまで通って初めて、結果を議論の土台にします。」
約30秒。ポイントは、手順を具体的な動詞で語ることと、数字が下がった事実を隠さないことです。良い結果を強調するより、疑い方を説明できるほうが評価されます。
よくある質問（FAQ）
Q. 事前登録をしても、結果が悪ければ結局やり直すのではないですか。
A. やり直すこと自体は問題ありません。問題は、やり直しを記録せずに最後の1回だけを報告することです。事前登録は「やり直し禁止」の仕組みではなく、やり直した回数を数えるための仕組みです。試行回数を明記したうえで「20回試して最良のものなので、この結果は割り引いて読むべきだ」と書けば、報告として成立します。
Q. 上場廃止銘柄のデータが手元にありません。どうすればよいですか。
A. 有料のデータサービスを契約するのが確実ですが、それが難しい場合は結論の書き方を変えます。「サバイバーシップバイアスを除去できていないため、実際の成績はこれより低い」と明記し、参考値として扱います。除去できていない事実を書かずに数値だけ出すのが、最も避けるべき対応です。なお、TDnetの適時開示情報閲覧サービスは無料公開が開示日を含む31日分に限られ、過去分の網羅的な取得には有料サービスが必要です（2026-08-03確認）。
Q. AIにバックテストのコードを書かせること自体、やめたほうがよいですか。
A. そこまでする必要はありません。AIは定型的な集計処理を速く書けますし、リーク検査の観点を列挙させる用途では特に有用です。ただし検査を通していないコードの出力を、結果として扱わないという一線を引いてください。コードを書かせたセッションと検査させるセッションを分けるだけでも、見落としは減ります。
まとめ
バックテストの設計は、結果を出す技術ではなく結果を疑う手順を先に固定する技術です。事前登録シートの7項目で疑い方を決め、6バイアスを症状・検査方法・対処の形で毎回判定し、AIが書いたコードは行番号つきのリーク検査を通す。そのうえで、手数料・スリッページ・税を金額で計上して率に戻す。架空データの設例では、この工程を経て年率12.0%が4.5%になり、うち2.7pt（コスト前の37.5%）が取引コストによる低下でした。
18項目のチェックリストは、この流れを毎回同じ形で踏むためのものです。項目を埋める作業自体は地味ですが、埋まらない項目が残っているという事実こそが、いちばん価値のある情報だと考えてください。数字が良いことより、どこが確かめられていないかを言えることのほうが、実務では信用されます。
※繰り返しになりますが、本記事は教育目的の解説であり、特定の投資戦略の推奨ではありません。掲載した数値はすべて架空の設例であり、将来の運用成果を示すものではありません。
出典・参考（2026-08-03確認）
- 金融庁「モデル・リスク管理に関する原則」令和3年11月12日 https://www.fsa.go.jp/common/law/ginkou/pdf_02.pdf
- 金融庁「AIディスカッションペーパー（第1.1版）」2026年3月3日 https://www.fsa.go.jp/news/r7/sonota/20260303/aidp.html
- JPX（東京証券取引所）「TDnetの概要」 https://www.jpx.co.jp/equities/listing/disclosure/tdnet/
- JPX「サイトのご利用上の注意と免責事項」 https://www.jpx.co.jp/term-of-use/
- 金融庁 EDINET「利用規約」 https://disclosure2dl.edinet-fsa.go.jp/guide/static/disclosure/WZEK0030.html
- 国税庁 タックスアンサー No.1463「株式等を譲渡したときの課税（申告分離課税）」 https://www.nta.go.jp/taxes/shiraberu/taxanswer/shotoku/1463.htm
- 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」2026年3月31日 https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html
※本記事は教育目的の一般的な解説であり、法務・税務・会計・投資に関する助言ではありません。実際の判断は専門家にご確認ください。設例は理解のための仮設例です。AI製品の仕様・料金は変更されることがあるため、利用前に各社の公式情報をご確認ください。