こんにちは。前回のコスト・マルチアセット編まで、検証はすべて過去データを使ったバックテストでした。今回は少し毛色が変わって、「実際に毎日シグナルを記録し続ける仕組み」を作った話です。正直にいうと、バックテストのコードを書くよりもこちらの方が地味に手間がかかりました。
① なぜバックテストだけでは足りないのか
バックテストの数値がどれだけ良くても、それは「過去のデータを、後から一括で計算した」結果でしかありません。実際に運用するとなると、データ取得のタイミングのズレ、シグナルを検知してから発注するまでの遅延など、バックテストでは見えてこない実運用特有の問題が必ず出てきます。実弾を投入する前の最後の砦として、毎日決まった時刻に「今日時点の目標ポジション」を計算して記録し続ける「ペーパートレード」の仕組みを用意することにしました。
2026-08-09に手動実行でこの記録を開始しました(BTC-USDは目標ポジション1=フルロング、ETH-USDは目標ポジション0=ノーポジションからスタート)。記録が一定期間溜まったら、その期間をバックテストで切り出した「期待値」と、実際に記録したシグナルをそのまま適用した「フォワード実績」を比較できるようにもしてあります。
② 手動実行から自動実行へ ― Azure Functionsで基盤を作る
最初は自分のPCで手動実行していたのですが、これでは実行を忘れる日が出てきますし、そもそも将来「少額でも実際に発注するロジック」を組み込むとしても、結局「毎日決まった時刻に起動する」という基盤は同じ形になります。そこで先にペーパートレードの段階でこの基盤をAzure Functionsで構築し、運用しながら実績を積むことにしました。
構築したリソースは以下の通りです(具体的なリソース名は、将来少額でも実弾を扱う基盤になることを踏まえ、ここでは伏せています)。
| リソース | 設定 |
|---|---|
| リソースグループ | 専用のリソースグループ(japaneast) |
| Storage Account | 専用のStorage Account(Append Blobで銘柄ごとに1ファイル) |
| Function App | 専用のFunction App(Linux消費プラン、Python 3.12) |
| 監視 | Application Insights |
| タイマートリガー | 毎日UTC 00:15(= JST 9:15)に起動 |
ローカルCLIから手動実行していたときはローカルのCSVファイルに追記していましたが、Azure Functionsは実行のたびに使い捨てのファイルシステムなので、そのままでは記録が残りません。そこで記録先をAzure Blob Storageに変更し、BTC-USD・ETH-USDそれぞれの銘柄ごとに1本のファイルへ追記していく形にしました。同じ日に二重に記録してしまわないよう、書き込み前に「その日の分がすでに記録済みか」を確認するチェックも入れています。
デプロイ後は一度手動でトリガーし、Application Insightsのログで正常終了(success: True)したことと、実際にBlob側にレコードが追記されたことの両方を確認済みです。以降は毎日JST 9:15に自動でBTC-USD・ETH-USDのシグナルが計算され、Blobに積み上がっていきます。
③ 認証は接続文字列を使わない
Storage Accountへのアクセスは、接続文字列や共有キーをコードや設定ファイルに埋め込む方法ではなく、マネージドIDを使いました。ローカル実行時は`az login`した資格情報、Azure Functions上ではFunction Appに割り当てたシステム割り当てマネージドIDが、それぞれ自動的に使われる仕組みです(`DefaultAzureCredential`)。Storage Accountへの権限もRBACで「Storage Blob Data Contributor」ロールのみを付与しており、秘密鍵をどこかに保管して漏洩リスクを抱える必要がありません。小さな検証プロジェクトとはいえ、実際のお金に近づく話になるほどこのあたりは手を抜かない方がいいと思っています。
余談ですが、Azure Functions(japaneast、Linux消費プラン)は一覧上Python 3.13・3.14も選べるように見えたのですが、実際に起動すると503(Site Unavailable)で使えませんでした。切り分けた結果、リージョン側のロールアウトがまだ追いついていないと判断し、今回はPython 3.12を採用しています。3.13以降が実際に使えるようになったタイミングで切り替える予定です。
検証で気をつけていること
今回はバックテストの数値を出す回ではなく基盤づくりの回でしたが、それでも意識したことが3つあります。
- 「動いている」を確認してから終わらせる：デプロイして終わりにせず、手動トリガーでログとBlobの両方に記録が残ることを目視で確認した
- 秘密情報を持ち回らない：接続文字列を使わずマネージドIDに寄せることで、キーの漏洩や失効管理といったリスクをそもそも作らないようにした
- 実績データが少ないうちは結論を出さない：自動記録を始めたばかりで、フォワード実績とバックテストの期待値を比較できるだけのデータはまだ溜まっていない。1〜3か月分は貯めてから初めて比較する
これでようやく「毎日勝手にシグナルが記録され続ける」状態になりました。地味な回でしたが、ここが安定して初めて次の実験――日中の値動きにどこまで追従すべきか――に進めます。
次回予告
次回は「日中監視・データ粒度編」です。これまでは日足の終値ベースで判断していましたが、ストップロスを1日1回のチェックではなく日中により高頻度に監視した場合にどう変わるか、また値動きを刻む時間の単位(1時間足・6時間足・12時間足など)自体を変えるとMACD戦略の結果がどう変わるかを検証します。お楽しみに。
最後まで読んでいただきありがとうございます。ご質問やコメントはお問い合わせからよろしくおねがいします。