20071110

システムトレードの最適化問題（初級編）

「過剰最適化」、「オーバーフィッティング」、「カーブフィッティング」、「最適化し過ぎ」あるいは「最適化しすぎの為、実運転後損益が悪化した」や「カーブフィッティングが原因で実践で即、崩れ出す」まだまだ多様なキーワードがあるのですが、これらの言い回しを目にする、耳にする読者様も多いと思います。上のの語句は全てひっくるめて、最適化のし過ぎがよくない事を言っていて、最適化し過ぎのシステムは運転に耐えられないことを意味し、最適化を施したシステムは、どれも全部よくないように連想させてしまうほど、システムトレードには負の部分としてついて回る言葉ではないでしょうか。最適化といった言葉が妙に怖がられている昨今ですが、今回はこの最適化問題に少し触れてみたいと思います。（この最適化問題はシステムトレードにおいて重要ですのでしばらくしてまた別側面で取りあげることもあると思います）最適化とは簡単には、目的としていることに、出来る限り適切な計画をして設計することなのだと思います。したがってシステムトレードにおいては出来る限り安定した損益動向を得る為に、過去の相場に照らし合わせて、十分なパラメータ調整をして設計することとなります。ですので、テクニカル指標を組み合わせて設計するシステムは最適化処理を必ず行っていることになり、もっと言ってしまうと前回時に述べたすりあわせ式のシステムは全て最適化処理をして設計を完成させているものだといえます。いわゆる、最適化問題とは結果論的問題なのではないのでしょうか。ようは、システムが崩れてしまったからカーブフィッティングだったと考えるのではないか。と、最近の風潮から感じます。それでは崩れない限り、つまり計画通りに行っている限りは、そのシステムが過剰な最適化だと断定してシステム運転を中止出来るでしょうか。筆者がすりあわせ式システムの限界を感じたのがここにあります。すりあわせて作ったシステムは、数値では、十分に過去のパフォーマンスを示し、うまく安定した運転が出来ているものの、いつうまく行かなくなるのかが、解らない事、また、うまく行かなくなっているのにそのシステムでのトレードを続けてしまう不安など、どの段階でそのシステムがよくない状態に入るのかが今ひとつわからない実際があります。筆者はこれまでで、いくつも、すりあわせ式システムを作ってきた結果、なかには５年以上、バックテスト通りの結果を残しており現在もうまく行っている、すりあわせ式システムを幾つも持ち合わせているものの、なかには十分なテスト（バックテスト。必要なフォワードテスト）も行い、すり合わせといえども構造は随分シンプルなものであったにもかかわらず、バックテスト通りにはいかず、横ばい損益動向を示すシステム、あるいは過去のドローダウンを更新したシステムもあります。他には、一時的に計画通りに行かず、その後はうまく行き全体を通してみれば期待通りに来ているシステムもあります。筆者は未だにすり合わせ式システムがどの段階でうまくいかなくなるのか、十分な特定の仕方を知り得ていませんが、どうも、すり合わせ式がうまく行かなくなるタイミングを捉えるのは、難しいと暫定的には感じています。したがって十分な監督をしながら、すり合わせ式システムとはつきあう必要があるなと感じています。（監督方法は後々、書いてみたいと思います）ここまで読み進めて頂きました、読者様の多くは、前回述べた根拠準拠型システムが、この手の最適化問題が殆ど、当てはまらないことにお気付きの方もいると思います。筆者は、根拠準拠型システムがすり合わせ式に比べてのメリットはこれが非常に大きいと思います。つまり、崩れるタイミングが目に見えて解るといったことです。前回、例に出したように、野球の左打者での一塁に達する優位さはルールが変わらない間は基本的に有効と考えられ、ルールが変わればその優位さはなくなります。したがって根拠準拠型システムはどの時点でうまくいかなくなるのかが容易に解る為、運転中の監督（経過管理）がすり合わせ式に比較して簡便であり、実務的にも精神的にも負担がすくないメリットがあります。これ以外は大体の所、すり合わせ式システムにパフォーマンスは劣ります。但し最適化問題と離れたところで運転するのは楽であり、ちょっとやそっとの落ち込みでは慌てずにじっくり運転できるわかりやすさがあります。根拠準拠型の弱点はその根拠がなくなってしまう事ですが、普通は野球の例に出した左打者の事のように、当面、有効。解りやすく言えば、そう簡単になくならない根拠を拠り所にしなければなりません。余談ですがホームページのシステム（根拠準拠型）もこの左打者の事のように、簡単にはなくならないものを拠り所にした根拠準拠型システムです。ところで、最適化問題とはそれほど恐ろしいものなのでしょうか。何れにしろ、すり合わせ式システムにはこの問題がついて回る事になりますが、実際、すり合わせ式システムといえども、十分なバックテストで有効を確認し、上手に相場の値動きにすり合わせたものは、すぐにシステムがうまく機能しないといった事には陥りにくいです。筆者は、つまり、最近の最適化問題は、本来の最適化問題とは意味合いが違うと考えています。これは、システムトレードにおいてロジック設計する段階での間違いと最適化問題が混同されている（あるいは、問題をすり替えてしまっている）からだと思います。システム設計時の根本的な間違いの代表的なものは、以下のようなものです。 ①バックテスト期間２２５先物相場は、最近流行の寄り付き仕掛け大引け締めのシステムトレードが流行っていますが、少なくともこのようなトレードスタイルのシステムであれば、設計時に５年程度のバックテストでは不足です。最低でも１０年は欲しいと思います。（但し２２５相場に限っては価格帯が８８年の開始時には終値２８７５０円その後、８９年末から９０年初にかけて４万付近までいった事もある為、この頃まで遡ってテストした方がよいと思います）システム設計時に十分な期間をテストしないことは、設計時の間違いの一つです。有効であるか、そうではないのかについてを考える以前の間違いであると思います。 ②指標の組み合わせ数これは複数の指標を複雑に組み合わせたからといって、一貫して常にロジックに組み込んでいるなら、そのこと自体が過剰最適化に繋がるとは言い切れない面があると思います。多くの指標を組み込んだから実際では即、崩れると、考えることは絶対に正しいとは、筆者は思いません。大体の場合、多くの指標を組んでいて、短いバックテスト期間で、実用に移行したものが崩れることが多いといえ、この問題は指標の組み合わせよりは①に間違いがあることが多いです。実際の所、複数の指標を利用して過去の相場を最適化する事、自体は、システム構築としては難しさもあり難易度の高い設計技法です。ですがシンプルに組むといった事は、基本ですので、組み込む際には本当にその指標がないと補えないのか（すりあわせが出来ないのか）十分に検討していかなければ成りません。ものにもよりますが、ロジックの中に移動平均が入っているのにボリンジャーバンドも入っているような同じ系統の指標が入っている場合などは、どちらかで済ませられないか等を検討するべきであると思います。 ③ドローダウン「有効を確認し、実際のトレードに移行したものの、突如、崩れだし、最大ドローダウンを更新したのでシステムが崩れきったと見なしてしまう。」これも設計時に間違っている場合があります。この問題も①が関連し、十分な期間での最大落ち込みを確認していないことが、問題の場合が多いです。さらに遡ってバックテストをしていれば直近の最大ドローダウンより、さらなる大きなものがあることも十分あります。もしかしたら、長い期間で見た場合は有効ではないかも知れません。最大ドローダウンの更新＝システムロジックの否定　　といった流れは完璧な正解ではないと思います。（但し直近よりも相対的にボラリティが大きかった時期に記録したドローダウンを直近で更新した場合は有効さの薄れを危険視しなければならないこともあります。例えば、２２５でいえば直近よりあきらかに、値動きの激しい時期が９０年台にはあった事から、この時期に記録した値を大きく更新するようであれば、システムの調子を考える必要もあるかもしれません） ④トレード数よく、デイトレードなら（おそらく３０分ブレイクアウトのようなシステムを指しているようですが）トレード数は４００～５００回程度のバックテストが必要だ・・・・といった事を聞きますが、これは乱暴な意見だと思います。トレード数だけでは最適化問題を考えることは不可能だと思うからです。このトレード数も①と密接な関わりがあります。十分なバックテスト期間はもちろんのこと、トレード数もバックテスト期間中に十分にこなしていることが必要です。目安はどのくらいなのかを考えた場合、これは仕組みにもより絶対にこのトレード数を越えないとよくないといった事はありません。が、全期間における４５％程度以上が標準的な目安ではないかと経験的に思います。例を挙げるなら、一日一回のサインの出る仕組みなら４０００営業日における４．５割ですと１８００回程度ですのでこの位は標準だと思います。最近のシステム事情を見ますと、全般的にトレード数は多めの物が多いようです。毎日サインがあるから良いシステム、４５％に満たないから悪いシステムといった見方はしませんが、１０％にも満たないような場合はトレード数からの側面では過剰最適化の可能性はあります。一度ロジック設計し終えたものを、さらにフィルター処理でトレード数を削りすぎると相当、トレード数の低いものが出来てしまいます。トレード数については歯切れの悪い文ですが、これには理由があります。 ①だけではなく、勝率と損益比、関連も考慮しなくてはならないからです。通常システムトレードの勝率は５割近辺に推移します。（ブレイクアウト系のシステムはもっと低いです）したがってトレード数が少なく、かつ期間も短い上に、勝率が高く、ＰＦ等が妙に高い（２を完全に越えている）ような場合はバックテストが十分でない場合が多いです。トレード数が極端に少ない設計も最適化問題以前での間違いであることが多いように思います。 ⑤勝率・損益曲線上で５割が基本と述べましたが、仕組みによりこれは、やや異なります。デイトレードにおいてはブレイクアウト型（トレンド狙い）　　４割トレンドつぶし型（トレンド逆張り）　５．５割寄り付き大引け型　　　　　　　　　　５割スイングトレードではスイングトレード短期　　　　　　　　５～５．５割スイングトレード長期　　　　　　　　５．５割～６割スキャルピングはもっと高いですがやや特殊ですのでここでは考えないとします。大体、これは目安になると思います。筆者の経験では２２５に限らず大方の相場でシステム設計すると上のような感じになってきます。勝率が妙に高いものは①が伴っていない場合が多く、トレード数も低い事が多いです。最適化問題以前の期間やトレード数などの不足点がないかをロジック構造において検討する必要があります。次に損益曲線についてですが、よく、あまりにも直線性の高い損益曲線はよくない、や、直近に近づいて行くにつれてよく伸びているものが、過度の最適化である。またはＲＳＱ（損益曲線の直線性）が９０％以上だと過剰最適化、等、色々な意見があるようですが、筆者は、損益曲線で過度の最適化を論じる事は乱暴だと思います。直近で伸びている損益曲線は、直近で落ち込んでいる曲線より、著者には良いもののように感じます。無論十分なトレード期間やトレード数等をしっかり伴ったシステムでなければならないわけですが。但し損益曲線の様子からその後、崩れやすいと、思われる曲線には傾向があることは、経験的にある程度いえると思います。以下のような場合です。・トレード期間とトレード数の少ない損益曲線（グラフにするとやたらとギクシャクした曲線になります）・波のない曲線トレード期間とトレード数を伴っているシステムはいわゆるドローダウン期やフラット期、あるいは良く伸びる時期といったものを、織り込んだ曲線になります。直線性の高い低いはともかく、波を打ちながらの損益曲線を描くことが普通です。したがって波のない、殆どまったくドローダウンなどないような損益曲線は、バックテスト期間の短く、その短い期間であまりにもチューニングし過ぎのシステムが多いです。システムにゆとりのない分、相場が少し変わると、即、システムの損益動向に異常が出る場合があります。・理由の考えにくい放物線的な損益曲線ある時期まで直線的な曲線が途端に放物線のように急カーブで上がっているものは以下の２点で主に起こります。１）運転中に相場ボラリティが高まり、すりあわせ型ロジックがこれによくフィットしている状態。十分な期間で十分なトレード数を伴ったシステムでも相場が極端に活況になり、システムが機能しているとこのような場合に遭遇することはあります。値動きの加減や日中ボラリティなどが２～３倍程度まで膨らまないと起こりません。大抵このような場合はボラリティがもとに戻るにしたがって大きめなドローダウンが（場合によっては最大ドローダウンになることも）おこり、その後、再び通常通りの損益曲線に近づくことが多いです。２）まだ運手して時期が浅く（あるいはバックテストしただけの状態）ロジック設計時のパラメータ調整がうまくできていない状態。※普通は放物線のような損益曲線になった場合はチューニングし直して設計することが基本であることから、直近を意識しすぎてチューニングした場合も放物線のような曲線がロジック設計段階で出来てしまうこともあります。１）のケースは相場の動向が原因と考えやすいで、あまり心配ない場合も多いですが、２）のケースはバックテスト期間が不足していて、パラメータ調整してしまった結果が多いです。損益曲線についてはまだまだ見極め方があるのですが、大きくは上の通りのような場合に突然、損益動向に大きな変調が出る傾向があると思います。やはりここでも十分なバックテスト期間やあるいはトレード数を伴わないロジック設計になっていることが関連することが多いと思います。これらも最適化問題以前の設計時での不足点ではないかと思います。 ⑥フォーワードテストフォワードテストとは、バックテストなどで十分有効が確認出来ているものを、試験的に運転して（仮想運転して）結果の善し悪しをバックテスト期間のパフォーマンスと比較して検討するものです。最近はこの単語をよく見かけますが、筆者はフォワードテストを軽視しています。もちろん、筆者もこの手の検定方法には精通しています。単純なフォワードテストや期間ずらしフォワードテスト（ウォークフォワード）。あるいはバックテストの性能とフォワードテストの性能比較検討等。当たり前の検定だけではなく、これらに、さらにボラリティレベルを相対比で考慮するや、コンピュータでランダムにバックテストとフォワードテストのサンプルを取り出して比較する等、多様な分析方法を実践しています。ですが、フォワードテストといったものを今ひとつ重視できない気持ちもあります。それは、フォワードテストで合格すれば絶対有効なのかを考えた場合に、言い切れない面があり、また、フォワードテストで本当に過剰最適化を判定できるのかを考えた場合これも言い切れないと思っているからです。ですが、フォワードテストで確かに不合格を示し実際もよくない場合もあります。一つのテスト法として検討してもよいものだと思います。最適化問題を考える以前のロジック設計時の間違いや不足点によるシステムの至らなさの、あぶりだしにはよいテストではあると思います。以上、最適化問題と混同されやすい、ロジック設計する際でのミスについて述べましたが、最近は本来の最適化問題ではなく、設計時の準備不足やミスによる実運転中のアクシデントを最適化問題と混同させているように思います。今回、筆者の述べたい点は、すなわち、設計ミスと最適化問題は著者の持論では、まったく別問題であるということです。相場の値動きを最適化して作る、すり合わせ型ロジックといえでも、たしかに運転中にある種、つかみ所のない不安はあるものの、十分なバックテスト期間での、有効を確認した上での運転は、いきなり上手く行かないようなアクシデントに見舞われることは多くはありません。ですので、システムトレード入門時には設計前のミスをしないことが大切だと思います。確かにすり合わせ型ロジックは運転中には、つかみ所のない不安を感じます。ここに不足（限界）と感じ、根拠準拠型ロジックをもとめていった筆者ですが、今でもすり合わせ型ロジックの開発は日々行っています。下手な鉄砲も・・・・ではないですが、１００個制作して一つでもよいものができればと考えている為です。例えば以下の損益曲線は２２５用で寄り付き仕掛け大引け手仕舞いの、すり合わせ式システムですが（※ホームページのシステムとは別のものです。）

運転して４年を過ぎても、ＰＦは１．２程度で推移しており、勝率も４０パーセント後半で推移しており安定して有効が見られます。ロジックも、単純移動平均にボラリティと、任意期間中に買い手、売り手のどちらが優位であったかを考慮出来るように改良を与えたものを２本使って、前日終値時点でゴールデンクロス中は買い、デットクロス中は売りとする単純なものです。別にこのシステムがどうなのか、云々を述べたいのではなく、色々研究を進めると、すり合わせ式システムであってもよいものが出てくる場合があるといったことの例に挙げました。システムトレード入門時に、いきなり根拠準拠型システムを作成することは、ロジック研究に慣れない点も考慮すると難しいと思います。先ずはすり合わせ式システムを設計する、研究することは副産物として相場の値動きをよく知ることにも繋がり、ここでの失敗、成功、限界がもっと単純で管理も簡便な根拠準拠型ロジック設計の研究に役立つことが多くあります。すりあわせ式システムを作るにはテクニカル指標をある程度（できればハイレベルまで）知ることが大切だと思います。次回からは本題とやや逸れますがテクニカル分析や指標に触れ、また戻りたいと思います。今回は最近の最適化問題が実はロジック設計時のミスと混同されている点に触れました。少し、長文になりましたが、次回はもう少し読みやすい量にしたいと思います。御一読ありがとうございました。