Pythonで株アルゴリズムを自作して長期運用する完全ロードマップ決定版

※本記事のコードや情報は執筆時点の仕様に基づいています。投資は自己責任であり、必ずデモ環境や少額資金でテストした上で運用してください。

先に結論からお伝えします。自作アルゴリズムを長期運用できるかどうかは、戦略そのものの優秀さではなく「劣化に気づく仕組み」と「やめる基準」を先に作れているかで決まります。バックテストで良い数字が出た戦略も、市場構造が変われば必ず効かなくなります。長く生き残っている個人投資家は、当たり続ける戦略を持っている人ではなく、効かなくなった戦略を早く手放せる人です。

ところが世の中の情報は「作り方」に偏っています。データ取得、指標計算、バックテスト、証券会社APIへの接続——ここまでの解説記事は無数にありますが、作った後に何年も回し続けるための運用設計を扱ったものはほとんどありません。実際に個人の自作システムが止まる原因も、コードのバグより「成績が落ちてきたときに判断できず、ずるずる損を広げた」というケースが大半です。

本記事では、自作アルゴリズムを長期運用に乗せるためのロードマップを4つのフェーズに分けて解説します。特に、アルファ（優位性）の減衰を数字で検知する具体的な閾値と、再最適化・縮小・撤退を機械的に切り分ける意思決定ルールに紙面を割きました。ここが曖昧なまま実弾を入れると、判断が感情に乗っ取られます。

📘 外部参考：Walk forward optimization（Wikipedia）／ Backtesting（Investopedia）

自作アルゴリズムが「1年もたない」典型的な理由
長期運用ロードマップの全体像
フェーズ1: 資金を入れる前に「投資方針書」を書く
フェーズ2: 資金を3段階に分けて投入する
フェーズ3: アルファ減衰を「数字」で検知する
- ローリング指標を自動集計するコード
- 警戒ラインを割ったら通知する
フェーズ4: 再最適化・縮小・撤退を切り分ける
- 再最適化してよい条件
- 撤退の判断は「戻さない」ことが価値
長期運用を支えるインフラと記録
年間の運用カレンダー
戦略は1本ではなく複数持つ
よくあるつまずきと対処法
まとめ

自作アルゴリズムが「1年もたない」典型的な理由

まず、なぜ多くの自作システムが短命に終わるのかを整理します。原因はおおむね次の5つに集約されます。技術的な難しさよりも、運用設計の欠落が効いていることがわかります。

理由1: 撤退ラインを決めずに実弾を入れる

最も多いパターンです。「どこまで負けたらやめるか」を決めずに始めると、含み損が膨らんだときに判断できません。人間は損失局面で「もう少し待てば戻る」と考える傾向があり、これは意志の強さでは克服できません。だからこそ、資金を入れる前に、文章として撤退条件を書いておく必要があります。

理由2: バックテストの数字を信じすぎる

手数料とスリッページを入れていないバックテストは、ほぼ確実に実運用より良い数字を出します。特にデイトレード寄りの高頻度な戦略ほど、コストの影響は致命的になります。年利30%に見えた戦略が、現実的なコストを入れた瞬間に年利5%まで落ちる、ということは珍しくありません。コストの織り込み方は手数料・スリッページをPythonで組み込む方法で詳しく扱っています。

理由3: パラメータを過剰に最適化している

過去データに合わせ込んだパラメータは、未来のデータでは機能しません。いわゆるカーブフィッティングです。移動平均の期間を「23日」のように中途半端な値に決め打ちしている場合、その多くは過学習を疑うべきです。健全な戦略は、パラメータを少しずらしても成績がなだらかに変化します。逆に、1点だけ突出して良い設定がある戦略は危険信号です。

理由4: 動いているかどうかを見ていない

自動化した安心感から、数週間ログを見ないという状態が起こります。APIの仕様変更、証券会社のメンテナンス、ライブラリの破壊的アップデート、VPSの再起動——システムは想像以上に簡単に止まります。「動いている前提」で放置せず、止まっていたら通知が来る仕組みを先に作るべきです。

理由5: 記録を残していない

成績が落ちたとき、原因を切り分けるには過去の約定記録が必要です。「相場が変わったのか」「自分がコードをいじったせいなのか」「単なる不運の範囲なのか」は、記録がなければ永遠にわかりません。記録がない運用は、改善のしようがない運用です。

長期運用ロードマップの全体像

ここからが本題です。自作アルゴリズムを長期運用に乗せる流れを、4つのフェーズに整理しました。重要なのは、フェーズ1を飛ばさないことです。多くの人がフェーズ2から始めてしまい、結果として判断基準のないまま資金を減らします。

フェーズ	やること	目安期間	投入資金	ここを抜けた合図
1. 運用設計	撤退ライン・リスク上限・監視項目を文書化	1〜2週間	0円	投資方針書が書き上がる
2. 段階投入	ペーパートレード→少額実弾→本番資金	3〜6か月	総資金の5%→20%→100%	実運用30〜50約定を通過
3. 監視	成績指標のローリング集計と自動通知	継続	据え置き	ダッシュボードが自動更新される
4. 判断	再最適化・縮小・撤退の切り分け	四半期ごと	判断により変動	ルールに沿って淡々と処理できる

この4フェーズは一方通行ではなく、フェーズ4の判断結果によってフェーズ2やフェーズ1に戻ります。戦略を入れ替えるたびに、この輪を回すイメージを持ってください。

それぞれのフェーズには、明確な役割があります。フェーズ1は「判断基準を作る」段階で、ここで決めたことが後のすべての意思決定を支えます。ここを飛ばすと、フェーズ4で必ず迷います。フェーズ2は「バックテストと現実の差を測る」段階です。紙の上の数字がどれだけ楽観的だったかを、小さな損失で知るための工程だと考えてください。

フェーズ3は「異変に気づく」段階で、ここは可能なかぎり自動化します。人間が毎日数字を眺める運用は長続きしません。そしてフェーズ4が「決める」段階です。ここでやることは新しい判断ではなく、フェーズ1で書いた基準に現在の数字を当てはめる作業だけになります。この構造にしておくと、成績が悪化した局面でも冷静さを保てます。

逆に言えば、フェーズ4で悩んでいる時点で、フェーズ1の設計が不十分だったということです。迷いが生じたら、パラメータではなく方針書のほうを見直しましょう。

フェーズ1: 資金を入れる前に「投資方針書」を書く

機関投資家には運用ガイドラインがあり、担当者の気分で方針を変えられないようになっています。個人でも同じ仕組みを作れます。A4で1枚、次の項目を埋めるだけで十分です。

戦略の前提: なぜこの戦略が効くと考えるのか（例: 決算後の過剰反応が数日かけて修正される）
前提が崩れる条件: 何が起きたらこの前提は無効になるのか
1トレードあたりの最大リスク: 総資金の何%まで（例: 0.5%）
許容ドローダウン: どこまでの含み損なら想定内か（例: 資金の15%）
ハードストップ: 無条件で全停止する水準（例: 資金の25%）
監視する指標と頻度: 何を、いつ見るのか
見直しのタイミング: 定例レビューをいつ行うか（例: 毎四半期末）

特に重要なのが2番目の「前提が崩れる条件」です。これを先に書いておくと、成績が落ちたときに「単なる不調」なのか「前提そのものが無効になった」のかを切り分けられます。前提が生きていれば粘る価値がありますが、前提が壊れているなら、どれだけパラメータをいじっても意味がありません。

実際に書くとこうなります。抽象的な決意表明ではなく、数字と条件で書くのがコツです。読み返したときに解釈の余地が残っていると、都合よく読み替えてしまいます。

【投資方針書】決算後ドリフト戦略

前提
  決算発表直後の過剰反応が、5営業日ほどかけて修正される

前提が崩れる条件
  ・決算後5日のリターンの偏りが2四半期連続で消える
  ・決算発表の同日開示が一般化し、反応が即日で終わるようになる

リスク上限
  1トレードあたり  : 総資金の0.5%
  同時保有          : 最大5銘柄
  許容ドローダウン  : 15%（ここで新規建てを停止し検証）
  ハードストップ    : 25%（全建玉解消、運用停止）

監視
  毎日  死活監視の通知確認
  毎月  直近50約定の勝率・PF・期待値
  四半期 方針書と突き合わせて継続可否を判断

見直し
  毎四半期末。それ以外のタイミングではパラメータを変更しない

ポイントは「許容ドローダウン」と「ハードストップ」を2段階で置くことです。1段階目で新規建てを止めて原因を調べ、それでも悪化するなら2段階目で完全に降りる。この二段構えにしておくと、一時的な不調で全部を投げ出さずに済み、かつ致命傷も避けられます。

リスク上限の決め方については、自作システムで株を運用する際の絶対ルールと資金管理法もあわせてご覧ください。1トレードあたりのリスクをどう資金量に反映させるかは、適切な購入株数とリスクを自動計算する方法が参考になります。

フェーズ2: 資金を3段階に分けて投入する

いきなり全額を入れるのは、バックテストと実運用のギャップを確認しないまま本番に出るのと同じです。次のように段階を踏みます。

段階	資金	期間の目安	ここで確認すること
ペーパートレード	0円	1〜2か月	シグナルが想定通り出るか、システムが止まらないか
少額実弾	総資金の5%程度	2〜3か月	実際の約定価格とバックテスト想定のズレ（スリッページ）
本格運用	方針書で決めた上限まで	継続	成績が想定レンジ内に収まっているか

ペーパートレードで見るべきは損益ではありません。「システムが止まらずに動き続けるか」です。1か月連続で予定どおりシグナルを出せたなら、それだけで合格です。逆にこの段階で週に1回落ちるようなら、実弾を入れてはいけません。

少額実弾のフェーズでは、バックテストの想定約定価格と実際の約定価格の差を必ず記録します。この差が想定より大きい場合、バックテストの数字は上振れしていたことになります。次のコードは、想定と実績のズレを集計するシンプルな例です。

import pandas as pd

# trades.csv: date, side, expected_price, filled_price, qty
df = pd.read_csv("trades.csv", parse_dates=["date"])

# 1約定あたりのスリッページ（不利方向をプラスで表現）
sign = df["side"].map({"BUY": 1, "SELL": -1})
df["slippage"] = (df["filled_price"] - df["expected_price"]) * sign
df["slippage_bp"] = df["slippage"] / df["expected_price"] * 10000  # ベーシスポイント

print(f"約定数            : {len(df)}")
print(f"平均スリッページ  : {df['slippage_bp'].mean():.2f} bp")
print(f"中央値            : {df['slippage_bp'].median():.2f} bp")
print(f"最悪値            : {df['slippage_bp'].max():.2f} bp")
print(f"総コスト          : {(df['slippage'] * df['qty']).sum():,.0f} 円")

平均スリッページが判明したら、その値をバックテストに戻して再計算します。ここで成績が想定を大きく下回るようなら、本格運用に進む前に戦略を見直すべきです。スリッページの組み込み方はPythonバックテストにスリッページを加味する実装方法で詳しく解説しています。

フェーズ3: アルファ減衰を「数字」で検知する

ここが長期運用の核心です。戦略の優位性（アルファ）は、時間とともに必ず薄れていきます。他の参加者が同じ歪みに気づけば裁定が効きますし、そもそも市場の構造自体が変わります。問題は「調子が悪いだけ」と「本当に効かなくなった」を区別できるかです。

これを感覚で判断すると、たいてい手遅れになります。そこで、あらかじめ数値の警戒ラインを決めておきます。実務で使われている目安をまとめると次のようになります。

監視指標	警戒ライン	意味
勝率	ベースラインより10〜15ポイント低下が2期間連続	シグナルの質が落ちている
ドローダウン	過去最大DDの1.5〜2倍に到達	想定リスクを超えている
プロフィットファクター	1.5〜2.0から1.0付近へ低下（コスト差引後）	優位性がコストに食われている
期待値	複数期間でゼロ近辺または負	回すほど損をする状態
1トレードあたり平均R	+0.05R以下に圧縮	リスクに見合わない

集計の単位は約定回数ベースにします。カレンダー月で区切ると、取引が少ない月にノイズが乗るためです。目安として30〜50約定で早期警戒、100約定以上で確定判断とすると扱いやすくなります。スイング系で約定が少ない場合は、3〜6か月のカレンダー窓を併用します。

また、運用開始からの最初の100約定では、実運用の損益曲線がバックテスト想定の±15〜20%の帯に収まっているかを見ます。継続的に下振れするなら、優位性の消失・コストの見積もり不足・過学習のいずれかが起きています。

ローリング指標を自動集計するコード

約定履歴から、直近N約定の成績を転がしながら計算します。これを毎日回して、警戒ラインを割ったら通知する構成にします。

import pandas as pd
import numpy as np

WINDOW = 50          # ローリング窓（約定数）
BASE_WIN_RATE = 0.55 # バックテスト時の勝率（ベースライン）
BASE_PF = 1.8        # バックテスト時のプロフィットファクター

df = pd.read_csv("trades.csv", parse_dates=["date"]).sort_values("date")
pnl = df["pnl"]  # 手数料・スリッページ差引後の損益

def profit_factor(x):
    gain = x[x > 0].sum()
    loss = -x[x < 0].sum()
    return gain / loss if loss > 0 else np.nan

roll = pd.DataFrame({
    "win_rate":   pnl.rolling(WINDOW).apply(lambda x: (x > 0).mean(), raw=False),
    "pf":         pnl.rolling(WINDOW).apply(profit_factor, raw=False),
    "expectancy": pnl.rolling(WINDOW).mean(),
})
roll["date"] = df["date"].values

latest = roll.dropna().iloc[-1]
print(f"直近{WINDOW}約定の成績")
print(f"  勝率      : {latest['win_rate']:.1%}  (基準 {BASE_WIN_RATE:.1%})")
print(f"  PF        : {latest['pf']:.2f}  (基準 {BASE_PF:.2f})")
print(f"  平均損益  : {latest['expectancy']:,.0f} 円")

# 警戒判定
alerts = []
if latest["win_rate"] < BASE_WIN_RATE - 0.10:
    alerts.append("勝率が基準より10ポイント以上低下")
if latest["pf"] < 1.0:
    alerts.append("PFが1.0を下回った（回すほど損）")
if latest["expectancy"] <= 0:
    alerts.append("期待値がゼロ以下")

print("判定:", " / ".join(alerts) if alerts else "警戒ラインの範囲内")

プロフィットファクターや期待値の考え方そのものは、プロフィットファクターを計算する方法で基礎から解説しています。あわせて最大ドローダウンを自動計算するコードを組み合わせると、監視項目がひととおり揃います。

警戒ラインを割ったら通知する

集計しても見なければ意味がないので、判定結果を自動で手元に飛ばします。毎日決まった時刻に実行し、警戒に該当したときだけ通知する形が現実的です。

import os
import requests

def notify(text: str):
    """Discord Webhook に通知する（LINE以外の選択肢として扱いやすい）"""
    url = os.environ["DISCORD_WEBHOOK_URL"]
    requests.post(url, json={"content": text}, timeout=10)

if alerts:
    body = "戦略の劣化シグナル\n" + "\n".join(f"・{a}" for a in alerts)
    body += f"\n直近{WINDOW}約定: 勝率 {latest['win_rate']:.1%} / PF {latest['pf']:.2f}"
    notify(body)

あわせて「システムが動いている」こと自体の死活監視も入れます。正常時にも1日1回「稼働中」の一言を送るようにしておくと、通知が来ない日＝止まっている日、と気づけます。異常検知だけを実装すると、システムが完全に停止したときに何の通知も来ないという事故が起きます。

フェーズ4: 再最適化・縮小・撤退を切り分ける

警戒シグナルが出たとき、選択肢は3つしかありません。パラメータを直す（再最適化）、ポジションを小さくして様子を見る（縮小・一時停止）、その戦略を捨てる（撤退）です。どれを選ぶかを、次の表であらかじめ決めておきます。

観点	再最適化	縮小・一時停止	撤退
期待値	プラスだが低下傾向	ゼロ近辺で不安定	コスト差引後が継続的にマイナス
ドローダウン	過去の範囲内	過去最大の1.5倍前後	方針書のハードストップに到達
パラメータ頑健性	近傍の設定でも成績が安定	結果がまちまち	ウォークフォワードで繰り返し不合格
前提（ロジック）	現在の市場構造に合っている	移行期で判断がつかない	前提そのものが構造的に無効
コスト	コストを引いても優位性が残る	コスト後はぎりぎり	コストが優位性を消している

再最適化してよい条件

成績が落ちるとすぐパラメータを触りたくなりますが、再最適化が許されるのは次の3条件をすべて満たすときだけです。

戦略の中心的な考え方が、いまの市場でもまだ通用すると説明できる
最適化に使っていない期間（アウトオブサンプル）で、コスト差引後もプラスが残る
最適値の近くの設定でも、似たような成績が出る（1点だけ突出していない）

3番目が特に重要です。狭い範囲でしか良い数字が出ない場合、それは調整ではなくカーブフィッティングです。ここで手を入れると、見かけの数字だけ戻って実運用はさらに悪化します。この検証を仕組みとして回すのがウォークフォワード最適化で、ウォークフォワード最適化で過学習を防ぐ方法に実装例をまとめています。

撤退の判断は「戻さない」ことが価値

撤退を決めたら、その戦略のコードはアーカイブして、当面は動かしません。「もう一度だけ」と再稼働させるのは、判断ルールを自分で壊す行為です。ただし、記録は消さないでください。数年後に市場環境が変わり、同じロジックが再び効くようになる可能性はあります。そのとき役に立つのは、「いつ、なぜ、どの数字を見て撤退したか」という記録です。

長期運用を支えるインフラと記録

ここまでの判断をすべて成立させる土台が、実行環境と記録です。何年も回すことを前提にすると、押さえるべき点は絞られます。

実行環境: 自宅PCではなくVPSへ

自宅PCでの運用は、停電・Windows Update・スリープ・回線断で簡単に止まります。月額数百円から千円台のVPSに移すだけで、稼働の安定性は大きく変わります。導入手順はConoHa VPSでPython環境を構築する完全手順にまとめました。当面は自宅PCで続けるという場合でも、タスクスケジューラで自動実行する手順とスリープ抑止の設定は必須です。

記録: CSVではなくデータベースに寄せる

約定履歴、シグナル発生履歴、エラーログ、パラメータの変更履歴。これらを日付別のCSVに散らかすと、後から集計できません。SQLiteであればファイル1つで完結し、追加のサーバーも不要です。設計例はSQLiteで自動売買のログを一元管理する設計で扱っています。

最低限、次の4テーブルを持っておくと後の分析が楽になります。

CREATE TABLE signals (      -- シグナルが出た記録（発注しなかった分も残す）
    id INTEGER PRIMARY KEY, ts TEXT, symbol TEXT,
    side TEXT, reason TEXT, executed INTEGER
);

CREATE TABLE trades (       -- 実際の約定
    id INTEGER PRIMARY KEY, ts TEXT, symbol TEXT, side TEXT,
    expected_price REAL, filled_price REAL, qty INTEGER,
    fee REAL, pnl REAL
);

CREATE TABLE params (       -- パラメータ変更の履歴
    id INTEGER PRIMARY KEY, ts TEXT, strategy TEXT,
    key TEXT, old_value TEXT, new_value TEXT, note TEXT
);

CREATE TABLE health (       -- 死活監視
    id INTEGER PRIMARY KEY, ts TEXT, status TEXT, message TEXT
);

params テーブルを軽視しないでください。成績が変わった原因が「相場」なのか「自分の変更」なのかを切り分ける唯一の手がかりになります。いつ何をどう変えたかを残していないと、後から検証しようがありません。

税務: 年をまたぐ前に整えておく

特定口座（源泉徴収あり）で完結していれば、原則として確定申告は不要です。ただし、複数の証券会社を使っている場合や、損失を翌年以降に繰り越したい場合は申告が必要になります。自動売買は約定件数が多くなりがちなので、年末に慌てないよう、月次で損益を集計しておくと安全です。集計の自動化は株の損益計算を自動化するツールをご覧ください。

📘 外部参考：特定口座（楽天証券）／株式取引の税制・確定申告（松井証券）

年間の運用カレンダー

「継続的に監視する」と言われても、具体的に何をいつやるかが決まっていないと続きません。次のように頻度で割り振ると、負担を抑えたまま回せます。

頻度	やること	所要時間
毎日	死活監視の通知を確認するだけ（自動）	1分
毎週	約定件数とエラーログをざっと見る	10分
毎月	ローリング指標を確認、損益を集計	30分
四半期	方針書と照らして再最適化・縮小・撤退を判断	2〜3時間
年次	税務処理、戦略ポートフォリオ全体の見直し	半日

ポイントは、重い判断を四半期に1回へ寄せることです。毎日成績を眺めていると、ノイズに反応して余計な手を入れたくなります。日次でやるのは「止まっていないか」の確認だけで十分です。

それぞれの頻度で、具体的に何を見るのかを補足します。毎週のチェックで見るのは損益ではなく「約定件数」です。想定より極端に少なければシグナルが出ていない可能性があり、多すぎればロジックの暴走を疑います。損益は週単位ではぶれが大きく、見ても判断材料になりません。

毎月は、ローリング指標が警戒ラインの内側にあるかだけを確認します。内側なら何もしません。ここで「もう少し良くできそう」と手を入れ始めると、四半期レビューの意味がなくなります。月次でやるもう1つの仕事は損益の集計で、これは年末の税務処理を軽くするための作業です。

四半期レビューでは、方針書を実際に開いて読み返します。「前提が崩れる条件」に該当していないかを確認し、そのうえで判断表に現在の数字を当てはめます。所要時間は2〜3時間ほど見ておくと、腰を据えて検証できます。年1回は、戦略単体ではなくポートフォリオ全体の構成——どの戦略に資金がどれだけ寄っているか——も点検しましょう。

戦略は1本ではなく複数持つ

長期運用を前提にするなら、戦略は必ず劣化するという前提に立ちます。だとすれば、1本の戦略に全資金を預けるのは構造的に危険です。性質の異なる戦略を2〜3本並走させ、片方が不調でも全体が止まらない形にします。

トレンドフォロー系: 相場が一方向に動く局面で稼ぐ。レンジ相場では削られる
平均回帰系: レンジ相場で稼ぐ。強いトレンドが出ると逆行して損失が膨らむ
イベント系: 決算などの特定局面のみ稼働。稼働頻度は低いが他と相関しにくい

この3つは得意な相場が異なるため、成績の谷が重なりにくくなります。新しい戦略を追加するときも、既存の戦略と損益の相関が低いかを確認してから組み入れてください。似た戦略を並べても、分散にはなりません。

相関は感覚ではなく数字で確かめられます。各戦略の日次損益を並べて相関係数を取るだけです。

import pandas as pd

# 各戦略の日次損益を1つの表にまとめる
daily = pd.DataFrame({
    "trend":     trend_pnl,      # トレンドフォロー系
    "reversion": reversion_pnl,  # 平均回帰系
    "event":     event_pnl,      # イベント系
})

corr = daily.corr()
print(corr.round(2))

# 0.7以上の組み合わせは「実質同じ戦略」とみなす
high = [(a, b, corr.loc[a, b])
        for i, a in enumerate(corr.columns)
        for b in corr.columns[i + 1:]
        if corr.loc[a, b] >= 0.7]
for a, b, v in high:
    print(f"警告: {a} と {b} の相関が {v:.2f} — 分散になっていない")

目安として、相関0.7以上なら実質的に同じ戦略と考えます。トレンドフォローを2本持っているつもりでも、実は同じ相場でしか勝てないなら、資金を2倍賭けているのと変わりません。逆に相関がマイナスの組み合わせが見つかれば、片方の不調をもう片方が補う関係になります。

ただし、戦略を増やしすぎるのも考えものです。個人で無理なく管理できるのは2〜3本までだと考えておきましょう。数が増えるほど監視の手間が増え、結局どれも見なくなります。相関の低い戦略を少数だけ持つ——これが現実的な落としどころです。

よくあるつまずきと対処法

「成績が落ちたのでパラメータを毎月調整している」

これは実質的に、毎月カーブフィッティングをやり直している状態です。調整頻度は四半期に1回までと決め、再最適化の3条件を満たしたときだけ実施してください。頻繁に触るほど、直近のノイズに合わせ込んだ設定になっていきます。

「ライブラリを更新したら動かなくなった」

運用環境では、バージョンを固定します。pip freeze > requirements.txt で現在の構成を保存し、更新は検証環境で試してから本番へ反映します。データ取得ライブラリは仕様変更が入りやすいため、特に注意が必要です。

「ログはあるが、多すぎて見ていない」

生ログを読む運用は続きません。集計済みの数字を1画面にまとめ、そこだけ見れば判断できる状態を作ります。ダッシュボード化しておくと、月次レビューの負担が大きく下がります。

「実運用の成績とバックテストが合わない」

まず疑うべきはルックアヘッドバイアスです。当日終値でシグナルを出して当日終値で約定する、といった実現不可能な前提が紛れ込んでいると、バックテストは必ず上振れします。次にコスト、最後に過学習の順で切り分けていきます。この順番が大事で、いきなり過学習を疑ってパラメータを触ると、本当の原因を見逃します。

「上場廃止・株式分割で過去データが変わった」

意外と見落とされがちな問題です。株式分割があると、データ提供元が過去の株価を遡って調整するため、先月まわしたバックテストと今月の結果が変わることがあります。また、上場廃止になった銘柄が銘柄リストから消えると、生き残った銘柄だけで検証することになり、成績が実態より良く出ます（生存者バイアス）。検証に使ったデータのスナップショットを日付付きで保存しておくと、こうした差異を追跡できます。

「途中でルールを増やしたら成績が良くなった」

「この条件を足したら勝率が上がった」という改善は、多くの場合ただの過学習です。条件を1つ増やすたびに、過去データへの適合度は必ず上がります。判断基準はシンプルで、その条件を思いついた理由を、成績を見る前に説明できたかです。数字を見てから後付けで理由をひねり出したなら、それは発見ではなく偶然の当てはめだと考えたほうが安全です。

まとめ

自作アルゴリズムの長期運用は、良い戦略を見つける競争ではなく、劣化を早く見つけて淡々と処理する運用体制の勝負です。要点を整理します。

資金を入れる前に投資方針書を書く。特に「前提が崩れる条件」を先に言語化しておく
資金はペーパー→5%→本番の3段階で投入し、実際のスリッページを測ってからバックテストに戻す
劣化の判定は約定回数ベースで。30〜50約定で早期警戒、100約定以上で確定判断
勝率が10〜15ポイント低下、DDが過去最大の1.5〜2倍、PFが1.0付近——このいずれかで判断のテーブルに載せる
再最適化は3条件をすべて満たしたときだけ。近傍設定で成績が崩れるならカーブフィッティング
重い判断は四半期に1回へ寄せる。日次でやるのは死活監視の確認だけ
戦略は性質の異なるものを2〜3本並走させ、1本の劣化で全体が止まらないようにする

ここまで読んで「思ったより地味だ」と感じたなら、それが正しい感想です。長期運用の実態は、新しい戦略を探し続ける作業ではなく、決めたことを決めたとおりに実行し続ける作業です。派手さはありませんが、この体制がある人とない人とでは、3年後に残っている資金がまるで違います。

まず手を動かすなら、投資方針書の1枚目から始めましょう。撤退ラインを1行書くだけで、次に成績が落ちたときの判断が変わります。仕組みができていれば、あとは決めたとおりに実行するだけです。