市場が動いている時間帯にプログラムをいじると、思わぬ事故につながります。そこで私が導入したのが「フリーズ窓」というルール。動いている間はAIにコードを触らせない仕組みの作り方を、失敗談つきでやさしく解説します。
⚠️ この記事は2026年7月時点の情報です。Claude Codeや各種AIツールの仕様やサービスは変わる場合があるため、最新かつ正確な情報は各公式ドキュメント・公式サイトもご確認ください。あわせてCLAUDE.mdの書き方：AIを暴走させない安全設定もどうぞ。
こんにちは。コードが書けない会社員が、AI（人工知能）を相棒にして実務システムを作っている記録です。今回は「トレード自動化実録」のカテゴリーから、少し地味だけれど、いちばん大事かもしれない話をします。それは「市場が動いている時間帯は、AIにプログラムを触らせない」という安全設計（safety design）についてです。
私が作っているのは、日本株の値動きを観測・研究するためのシステムです。大事なので先に言い切っておくと、このシステムは実際の売買（発注）はしない設計になっています。あくまで「見て、記録して、考える」ための道具です。それでも、システムが動いている最中にうっかり手を入れると、思わぬ事故が起きます。今日はその事故を防ぐための「フリーズ窓（freeze window）」という考え方と、その仕組み化のやり方をお話しします。
この記事を読むと、次のことがわかるようになります。
- なぜ「動いている間は触らない」がプログラムでも大切なのか
- 「フリーズ窓」という時間ルールの考え方
- 土日・祝日を対象外にする工夫
- ルールをAIに守らせるための「明文化」のやり方
そもそも、なぜ「動いている間は触らない」のか
まず、たとえ話から始めます。あなたが飛行機に乗っていると想像してください。整備士さんがエンジンを点検・修理するのは、飛行機が地上に停まっている間ですよね。飛行中にエンジンを開けて部品を交換する人はいません。飛んでいる最中に手を入れれば、たとえ正しい修理であっても、その瞬間に機体が不安定になるかもしれないからです。
プログラムもこれとよく似ています。私のシステムは、市場が開いている時間帯に「今どんな値動きをしているか」を読み取りながら動きます。この稼働中（ライブセッション（live session）＝実際に動いている時間帯）に、たとえ良かれと思ってコードを書き換えても、動いている本体がその変更をその場で読み込んでしまうことがあります。地上（市場が閉じている時間）で直せば安全なものが、飛行中（市場が動いている時間）だと事故のもとになる、というわけです。
ここで一つ専門用語を紹介します。ホットリロード（hot reload）という言葉です。これは「動いているプログラムを止めずに、変更をその場で反映させる仕組み」のことです。開発中はとても便利な機能なのですが、本番稼働中だと逆に「勝手に変わってしまう」危険につながります。だからこそ、動いている間は触らない、というルールが必要になるのです。
実録：稼働中にコードを触って、システムが自分を守った日
ここからは、私が実際にやらかした失敗談です。恥ずかしいのですが、この失敗こそが「フリーズ窓」を作るきっかけになったので、正直に書きます。
ある取引日のことです。私はシステムが動いている最中に、判定を担当する小さな部品（モジュール（module）＝プログラムの一部品）を2つ、うっかり書き換えてしまいました。中身の変更自体は正しいものでした。でも、システムはそれを「稼働中に部品がすり替わった」と検知したのです。
ここで、私のシステムには指紋照合（フィンガープリント（fingerprint）＝プログラムの中身から作る、ID代わりの短い符号）という安全装置が仕込まれていました。人間の指紋のように、部品の中身が変わればこの符号も変わります。システムは起動時に部品の指紋を覚えておき、動いている間にその指紋が変わっていないかを見張っているのです。
私が部品を書き換えたことで、この指紋が変化しました。するとシステムは「稼働中に部品が変わった＝何かおかしい」と判断し、安全のために新しい動作を自分から止めたのです。これは、システムがバグって止まったのではありません。設計どおりに、危険を察知して自分にブレーキをかけたのです。
正直、そのときは「なんで止まるんだ」と一瞬あわてました。でも冷静に振り返ると、これは大成功でした。もし止まる仕組みがなければ、中途半端に書き換わった部品のまま動き続けて、もっと分かりにくい不具合につながっていたかもしれません。システムが自分を守ってくれた。この出来事から、私は「そもそも稼働中に触れないようにルールで縛ろう」と決めたのです。
「フリーズ窓」という時間ルールの考え方
そこで導入したのがフリーズ窓（freeze window）です。「フリーズ（freeze）」は「凍結する・固める」という意味、「窓（window）」はここでは「ある時間帯」という意味です。合わせて「この時間帯はコードをカチコチに凍結して、いっさい変更もテストもしない」というルールになります。
考え方はとてもシンプルです。市場が動く時間帯の前後を「凍結時間帯」と決めておき、その間は次のことをすべて禁止します。
- コードの変更（本体エンジンや設定ファイル、各部品）
- テストの実行（テストが本番の記録ファイルに書き込んでしまう事故を防ぐため）
- AIによる自動作業（AIが良かれと思って手を入れるのも止める）
ここで「テストの実行も禁止するの?」と思われたかもしれません。理由があります。テストというのは「わざと変な状況を作って、正しく動くか確かめる」作業です。ところが稼働中にテストを走らせると、テスト用のにせデータ（合成データ（synthetic data））が、本番の記録ファイルに紛れ込んでしまうことがあるのです。にせの理由コードや、にせの取引IDが本番の記録に混ざると、システムが混乱します。だから、動いている間はテストもしない、と決めています。
具体的な時刻や、安全に関わる設定の数値そのものはここには書きません（それ自体が守るべき情報なので）。大事なのは「市場が動く時間帯とその前後は、いっさい手を入れない」という考え方のほうです。時刻はあくまで運用者が自分の環境に合わせて決めればよく、思想さえ共有できていれば仕組みは作れます。
土日・祝日は対象外にする、という工夫
ここで一つ、実務ならではの工夫があります。それは「市場が開かない日は、凍結しなくていい」という例外です。
フリーズ窓の目的は「取引が行われている最中の事故を防ぐこと」でした。ということは、そもそも取引が行われない日、つまり土曜・日曜・祝日・年末年始は、いくらコードを触っても取引に影響しようがありません。むしろ、そういう「市場が閉まっている安全な日」こそ、じっくり修理や改善をするのに最適なタイミングです。飛行機でいえば「地上で停まっている日」ですね。
そこで私は、フリーズ窓のルールに「市場が閉まっている日は例外にする」というスイッチを付けました。仕組みとしては、日本の祝日や年末年始の休場日を一覧にしたデータ（休日カレンダー）をシステムに持たせておき、その日に当たったら「今日は凍結しなくていい日」と判断させるのです。
この工夫のポイントは、祝日の判定を外部の便利ツールにその場で頼らないことです。本番システムはできるだけ余計なものに頼らず、シンプルで壊れにくく保ちたい。そこで、祝日の一覧は前もって別の開発ツールで作っておき、システム本体はその「できあがった一覧表」を読むだけにしました。将来、対象の年を先に伸ばしたくなったら、その開発ツールをもう一度動かして一覧を作り直せばよい、という設計です。凝ったことをその場でやらせず、あらかじめ準備しておく。これも安全設計の基本です。
ルールをAIに守らせる「明文化」のやり方
ここまで読んで、こう思った方もいるでしょう。「ルールを決めても、AIがうっかり破ったら意味ないのでは?」と。まさにそのとおりで、いちばん大事なのはルールを『AIが必ず読む場所』に、はっきり書いておくことです。
私のプロジェクトには、いわば『憲法』にあたるファイルがあります。AIに作業を頼むとき、AIは毎回そのファイルを最初に読んでから動くように設定されています。人間でいえば「作業前に必ず就業規則を読む」ようなものです。そこに、次のようなことを日本語で明記しています。
| 書いておくこと | ねらい |
|---|---|
| どのファイルが「稼働中は変更禁止」か | 触ってはいけない対象を明確にする |
| 凍結する時間帯の考え方 | いつ手を止めるかを共有する |
| 過去に起きた実際の事故の例 | 「なぜ必要か」を忘れないため |
| 変更したいときの正しい手順 | 閉場後に、本体を止めてから直す流れ |
とくに私が効果的だと感じているのは、過去の失敗談を、そのままルールの中に書き残しておくことです。「いつ・何を触って・どう止まったか」を具体的に書いておくと、AIも私自身も「ああ、これは実際に事故った話なんだな」と重く受け止められます。抽象的な禁止事項より、生々しい失敗談のほうが、ずっと守られやすいのです。
また、ルールには「変更が必要になったときの正しい手順」もセットで書いておくのがコツです。ただ「触るな」だけだと、直したいときに困ります。私の場合は「市場が閉じるまで待つ→システムを完全に止める→そこで変更とテストをする→次に動かす前に内容を確認する」という順番を書いています。禁止と手順は必ずペアにする。これでルールが「使えるルール」になります。
まとめ：安全は「あとから足す」ものではなく「先に囲う」もの
今回の話を、あらためて整理します。
- 動いている間は触らない。飛行機を飛行中に修理しないのと同じで、稼働中の変更は事故のもとになります。
- フリーズ窓（freeze window）で時間ごと囲う。市場が動く時間帯とその前後は、コード変更もテストもAIの自動作業も、まとめて止めます。
- 土日・祝日は例外にする。市場が閉まっている安全な日こそ、じっくり改善する時間にあてます。
- 憲法ファイルに明文化する。失敗談ごと書き残し、AIが必ず読む場所にルールと手順をセットで置いておきます。
安全設計というと難しく聞こえますが、根っこの発想はとても人間的です。「危ないことは、そもそもできない時間・場所を作っておく」。これだけです。あとから「気をつけよう」と誓うより、先に「触れないように囲っておく」ほうが、はるかに確実で、気持ちもラクになります。
次の一歩として、もしあなたが何かをAIと一緒に自動化しているなら、まずは「これだけは絶対に自動で触ってほしくないもの」を一つだけ書き出してみることをおすすめします。それを、AIが必ず読むメモやルールファイルの先頭に、日本語で一行書いておく。たったそれだけでも、あなたの仕組みはぐっと壊れにくくなります。私も、たった一度の失敗から始めて、少しずつこの「囲い」を増やしてきました。コードが書けなくても、安全のルールは作れます。一緒に、あわてず前に進んでいきましょう。
関連記事
無料テンプレート配布のお知らせ
Claude Codeを安全・便利に使うための設定テンプレート（CLAUDE.md）を無料配布しています。メールアドレスをご登録いただくと、すぐにダウンロードリンクをお送りします。
免責事項
本記事は執筆時点（2026年7月）の情報に基づいています。Claude Codeや各種AIツールの仕様は予告なく変更される場合があります。最新かつ正確な情報は各公式ドキュメント・公式サイトをご確認ください。本記事の内容を用いて生じたいかなる損害についても、筆者は責任を負いかねます。
コメント