自分の取引ワークフローを作る – データから振り返りまで

よい工程は記憶で計画を再構成せず、データ・分析から判断、執行、点検へ進みます。各段階に目的と記録先があり、意図と実際を比較できます。基盤、予定、通知、日誌をつなぎ、必要道具と緊急手順を選びます。手動とコード両方を扱います。

1. 二つの正本 – 典型的な破綻

工程は合意した順序と、見落とされがちな各結果の保管先です。順序だけでは足りず、価格が線、数量が計算窓、理由が記憶だけなら、一週後に成績はあっても過程がありません。

同じ情報が二箇所にあり異なり得ると始まります。自動取込の日誌と毎夜手入力表が並行し、前者はサーバー時刻と実執行、後者は自分の物語を持ちます。部分決済や調整が違って一月後の件数差を復元できません。アプリの欠陥でなく優先元未定の帰結です。

工程でないもの。 アプリ数、窓数、「毎朝見る」という痕跡のない宣言ではありません。直近取引の各段階で生じた記入、ファイル、記録を示せるのが工程です。

道具に負わせられない重さを外す。 道具だけでは優位性は生まれない。 基盤、予定、日誌は反復性・操作性・信頼性を改善し大きな意味があります。しかし優位性は出入りのルールからで、ソフトからではありません（記事8.2）。実コスト、執行ミス、記録完全性を通じた純損益への影響が全範囲です。「優位性を与える」はここで確認不能ですが、「計画逸脱を減らす」は第12節で測れます。

2. 工程図：十一段階と各故障

十一段階のモデルです。監視と点検は循環しても判断記録は順序を保ちます。

予定・データ → 監視一覧 → 分析 → 計画 → 通知 → 判断 → 執行 → 監視 → 日誌 → 点検 → 工程変更

依存関係の例で、分析と通知の順は戦略で変わっても、執行前の計画記録は必須です。飛ばすと作業を不適切な段階へ移すだけです。計画は消えず、発注時に時間圧力下で無記録のまま再構成されます。

以下が記事の核心です。目的、欠落時の故障、失敗の検出条件を示します。最終列はデータで確認する成果物と比較を指定します。条件がなければ管理できず、故障を感じるだけで数えられないからです。

この十一項目はすべて活動です。記録先には二種類あります。計画台帳、執行台帳（日誌）、プロセス台帳という三つの台帳は、構造化データ、つまり集計できるデータの出所です。その横に添付資料保管庫を置きます。これは証拠の正本を保管する場所で、日付付きの監視銘柄リスト、画面キャプチャー、履歴のエクスポートなど、列に収まらない資料を保存します。各ファイルを日付、計画、インシデントの記録に結び付けることで、活動の痕跡が台帳、保管庫、または両方に残ります。振り返りも例外ではありません。振り返りは独立した台帳ではなく、結果を適切な場所に記す活動です。完成した記録は執行台帳へ、変更カードはプロセス台帳へ送ります。この区別が以後の構成を決めます。まず台帳を整え、次にそこへ記録を供給する活動を整えます。

3. 正本を一本化する：計画、日誌、プロセスのバージョン

原則は一文にまとめられます。 情報ごとに、食い違いがあったときに優先する場所を一つ決める。同じ情報を繰り返すものはすべて作業用コピーです。コピーは失っても出所から作り直せます。正本の記録は、任意の作業用コピーではなく、履歴を含む管理されたバックアップから復元します。

実務上、記録先は三つあり、作成される時点が異なります。

• 計画台帳 ：発注前に作成し、その後は編集しません。独立した表計算ファイルでも日誌の一部でも構いません。重要なのは形式ではなく作成時点です。事後に編集した記載は、振り返りの比較基準として使えなくなります。
• 執行台帳 ：インポートできる場合は口座履歴から取り込みます。理由は一つであり、インポート全般の優位性ではありません。インポートにはブローカーのサーバー時刻と実際の取引条件が含まれ、これらは記憶から再現できないからです。手入力欄は、セットアップの種類、決済理由、計画からの逸脱、介入時点などの分類を担います。記録の構造、インポートの落とし穴、指標の定義は 記事11.6で扱います。
• プロセス台帳 ：ある期間に有効だったルールを、日付とバージョン番号付きでまとめます。この台帳は省かれがちですが、なければ三月にどのルールで取引していたかを後から説明できません。

この三つの台帳の横に 添付資料保管庫を置きます。画面キャプチャー、日付付きの監視銘柄リスト、履歴エクスポートなどの保管先です。集計可能なデータを担わないため、第四の台帳ではありません。ただし証拠の正本保管先です。ここにあるファイルより優先されるコピーはなく、各ファイルを識別子で日付、計画、インシデントの記載に結び付けます。一方、チャートレイアウト、アプリの現在の監視リスト、アラート群、スマートフォンのメモは作業用コピーです。すべて必要ですが、どれも正本ではありません。判断に必要な確認は一分でできます。 今日チャートのプロファイルが消えたら、直近五取引の計画を再現できますか。 できなければ、チャート上の水準がコピーではなく正本になっています。プロセス全体が一つのアプリの設定ファイルに依存している状態です。

絶え間ない修正より、バージョン管理。 週の途中で変更したルールは評価できません。プロセス変更カードは五項目で数行に収まり、プロセス台帳に入ります。適用日、変更を促した観察事実、変更の正確な範囲、評価基準、そして再検討までに守る最低有効期間です。この五項目がなければ、変更は決定ではなく反応にすぎません。

ルールの評価では、変更前後の結果を一つの均質な標本にできません。金銭的な損益の総額は合算できますが、有効性はプロセスのバージョン別に評価します。同じ口座でも、別の集団です。この原則を過去検証に適用すると、データを学習用と検証用の標本に分ける意味があるかどうかが決まります。 記事11.7で扱います。

4. プロセスの入口：カレンダー、監視リスト、アラート

この三つを別々のシグナル源として扱うことがあります。しかしプロセス内の役割は逆で、注意を向ける必要のある状況を減らすフィルターです。それぞれ別の問いに答えますが、「入るべきか」という問いにはどれも答えません。

カレンダーが答えるのは、作業時間内に条件が変わるかどうかだけです。 相場の方向ではありません。予定の各項目の読み方、予想値の出所、「影響度」というラベルが市場ではなくデータ提供者の判断である理由は、 記事11.3で扱います。発表内容の解釈と、指標発表前後の市場の動きは 記事6.4で扱います。ワークフローに残る作業は一つです。発表時刻を、読み取ったときのタイムゾーンとともに計画に転記します。頭の中での換算は、一時間のずれを生みがちだからです。

監視リストは、使える時間から決めます。利用可能な銘柄数から決めるものではありません。プロセス内の役割で、取引する銘柄、背景把握のために見る銘柄、条件成立を待つ銘柄に分けるのが合理的です。リストとチャートレイアウトの整理は 記事11.2で扱います。ここでは二点が重要です。入れ替えルールを記録せず毎日変更すると、リストの監査が難しくなります。単に目を引いた銘柄を選んだだけかもしれません。明示したルールに沿う変更は、正当なプロセスの一部です。そして確認可能にするには、リスト自体の痕跡が必要です。その日について確定した版を、日付付きのエクスポート、画面キャプチャー、ファイルのコピーのいずれかで添付資料保管庫に保存します。アプリの現行リストが示すのは今日の状態だけで、昨日の姿は分かりません。

アラートとは、条件が満たされるとイベントと通知を生むものであり、注文ではありません。 条件の評価場所はツールによって違います。別のソフトの原則を当てはめず、実際に使うツールについて確認します。TradingViewのヘルプでは、アラートはプラットフォームのサーバー上で作成・発火し、チャートページを閉じても動作すると説明されています^[1]。MetaTrader 4のヘルプでは、実行中のアプリがその役割を担います。アラートを作成すると、「クライアントターミナル」がイベントを通知します^[2]。つまり、ターミナルを閉じると通知されません。MetaTrader 5のヘルプも自社プラットフォームについて同様に説明し、重要な点を加えています。アラートの時刻条件にはローカルコンピューターの時刻を使います^[3]。これは第11節で保護条件について確認するよう求める依存関係と同じです。アラートでも、個々のツールの提供元の文書で確認します。アラートは発注せず、価格を確保せず、通知された時点で条件成立時の水準で取引できることも保証しません。条件から注文までの全連鎖は 記事11.2で分解します。ワークフローでは、次の三つの整理原則を守ります。

1. 一水準に一アラート。冗長化は設計した場合に限ります。 役割を決めずに、チャートプラットフォームとターミナルの両方で同じ水準を監視すると、時刻の異なる二つのイベントが発生し、追跡すべき状態が増えます。ただし、独立した経路を意図的に二重化することは非常時手順の一部になり得ます。その場合は、主経路、予備経路、二つの通知が同一イベントだと見分ける方法、予備経路が今も動くことの確認方法という四点を事前に決めます。この四点がなければ重複は安全策ではなくノイズです。いずれの場合も、二重の執行を起こしてはいけません。
2. 通知文から背景を再現できるようにします。 水準だけでは三週間後に意味が分かりません。メッセージ欄に、シナリオ、無効化水準、計画台帳の記載への参照を入れます。
3. アラートには有効期限を設けます。 数週間前に引いた水準は、設定時の背景を失っているかもしれません。六週間は作業上の期間案であり、測定で得た閾値ではありません。期限設定やリストの定期点検の方が、理由を思い出せない通知に反応するより低コストです。

通知先も事前に決めます。スマートフォンに届くアラートと作業画面に表示されるアラートでは、開始する手順が異なります。これは独立した設計上の判断で、端末の側から 記事11.4で説明します。

5. 取引計画と執行チェックリスト

取引計画の機能は一つ、振り返りの比較基準を用意することです。落ち着いてセッションを始めることや頭の整理は副次的効果で、目的ではありません。一週間後に何を予定していたか記録から読めなければ、執行が意図どおりだったかも判断できません。その振り返りは、プロセスではなく記憶を評価することになります。

最低限必要なのは次の七項目で、すべて発注前に記入します。

1. 銘柄とエントリー条件：一言で成立・不成立を決められるように書きます。「持ち合いのブレイク」では条件になりません。「一時間足が水準Xを上回って確定する」なら条件です。
2. 仮説の無効化水準 ：ポジションの現在の損益にかかわらず、仮説が成立しなくなる価格またはイベントです。発表、足が水準の反対側で確定すること、時間の経過などが該当し、この種の条件は注文としてブローカーへ送れません。
3. 予定する保護注文の水準 ：仮説の無効化水準とは別に記録します。執行後に、サーバーが実際に確認した水準を追記します。両者は異なり得ます。口座履歴に対応する記録があるのは、確認された注文だけです。混同すると、振り返りで計画の記載を、履歴に存在しなかった記録と比較してしまいます。
4. 根拠を添えたポジションサイズ。 数値だけでは、一か月後にその算出根拠を再現できません。サイズと上限の決め方は 第9部で扱います。ワークフローで重要なのは、発注前に数値を出し、前提とともに記録することです。
5. 見送り条件 ：エントリー条件が成立しても意図的に入らない状況です。想定を外れるエントリーコスト、対象時間内の発表、保有を監視する時間がない場合などが該当します。
6. 記入時刻とタイムゾーン ：計画、アラート、執行のタイムスタンプが異なる場合に、後から出来事の順序を確定できます。
7. 記載の識別子 ：形式は自由ですが、同じものを画面キャプチャーのファイル名、アラート通知文、日誌記録に入れます。注文自体には自動で入りません。後述の別作業が必要です。

七項目目は事務作業に見えますが、安価に用意できる重要な部品です。台帳と添付資料保管庫を一つの追跡経路に束ね、日誌から事前の計画まで戻れるようにします。共通の識別子がないと、時刻と銘柄から毎回対応を再構成しなければならず、取引数が増えるほど難しくなります。

計画IDは注文IDではありません。 口座履歴には、注文、約定、ポジションそれぞれ別の番号があり、あなたの計画IDは認識しません。注文コメントに書きたくなりますが、無条件には頼れません。文字数制限があり、変更や部分決済時にブローカーのサーバーが切り詰め、上書き、独自印の追加を行う場合があります。持続的な解決策はもっと単純です。日誌を完成させる際、計画IDと、口座履歴から写した注文・約定・ポジションのIDを対応付ける表を計画台帳に別途保存します。第12節の記録完全性測定で使う資料と計画を結ぶのは、この対応表であって注文コメントではありません。

計画の記載に追記する意思決定記録。 上記の七項目は発注前に作ります。意思決定段階では、アラート発火時に同じ記載へ一行を追加します。タイムゾーン付き時刻、計画ID、入るか見送るかの判断、見送るなら該当条件を記します。一行で十分です。「条件が成立した」と「入った」を、後から検証できる形で分けるための行だからです。これがなければ、エントリーと意図的な見送りは、どちらも痕跡なしという同じ状態になり、振り返りには実際に行われた取引しか現れません。

執行チェックリストは計画とは別物です。 計画は取引内容を記し、チェックリストは作業を管理します。二択で答えられ、短く、発注と同じ画面内で実行できる必要があります。別アプリへの切り替えが必要なら、役立つはずの日にこそ実行されなくなります。通常は四項目で十分です。注文条件が計画と一致するか、サイズが計算どおりか、取引時間内にリスト上の発表があるか、同じエクスポージャーの既存ポジションがあるかです。セッション前、取引前、一日の終わり、週末のひな型は ツールキットのチェックリスト集にありますので、ここでは繰り返しません。

この段階の不具合には特徴があります。建玉後にチェックを付ける、あるいは「時間がない」日に付けなくなることです。どちらも、リストが発注手順の一部ではなく、付け足しになっていることを示します。

6. 監視、日誌、添付資料保管庫

保有中のポジションは特別な場所です。結果について逐一反応すべきでない人の目の前で、その結果が変化する唯一の地点だからです。守りは手順で作り、次の三点を事前に書きます。 何を、どの時点で監視し、具体的に何が起きればポジションの状態を変えてよいか。例えば「一時間足の確定時とリスト上の発表時に点検する」でも、別のルールでも構いません。セッション前に作ったことが重要です。保有管理としてどのルールが妥当かは ポジション管理の別記事で扱います。ワークフローが担うのは、事前に記述してあり、実行したかを後で確認できることだけです。

日誌は、損益と執行の質を分けて初めて機能します。 損益しか読めない記録は、名前を変えた口座明細です。役割分担は単純です。履歴インポートはブローカーのサーバー時刻と実際の価格を知っているので、執行条件を供給します。手入力欄は分類を供給します。セットアップの種類、決済理由、計画からの逸脱の有無と方向、介入時点です。介入時点とは、決済を含む保有への介入が、記録済みの点検時点に行われたか、それ以外だったかを示します。この欄は自分で作る必要があり、プラットフォームのエクスポートでは代替できません。エクスポートに操作理由の欄があっても、示すのは注文の発生元や約定の技術的理由であり、あなたの予定との一致ではありません。MQL5文書は DEAL_REASON プロパティについて、「モバイルアプリやMQL5プログラムから出された注文の発動、StopOutイベント、変動証拠金の計算などによって約定が発生し得る」と説明しています。値として順に「デスクトップターミナルから出された注文の発動」「…モバイルアプリから」「…ウェブプラットフォームから」「…MQL5プログラム、すなわちExpert Advisorまたはスクリプトから」、続いてStop Lossの発動、Take Profitの発動、Stop Out、ロールオーバー、変動証拠金の計算、分割、コーポレートアクションを挙げています^[7]。これは発生元と技術的原因の一覧であり、記録した点検時点で決済したかの答えではありません。だから「介入時点」は、記録を完成させる際に手入力します。値は三つです。計画どおり推移したポジションの「介入なし」、「予定した時点」、「計画外」です。一度でも予定外の介入があれば最後を選びます。記録全体の構造、インポートの注意点（タイムゾーン、部分決済、調整、入出金）、指標の定義は 記事11.6で扱います。

添付資料保管庫 は第四の台帳ではありません。三台帳の記載に添える画面キャプチャー、日付付き監視リスト、履歴エクスポートを置く場所です。存在を思い出すのは手遅れになってからになりがちです。画像に価値があるのは、表示銘柄、時間足、時刻表示、スケールから背景を再現できる場合だけです。それらのないチャート画像は、記載の飾りです。後で検索できる保管庫にするには三原則で足ります。

• ファイル名を計画台帳の識別子で始める。 日付順のフォルダーは画像集ですが、識別子で整理したフォルダーは索引です。
• 一取引に二枚の画面キャプチャー ：計画記入時と決済後に保存します。意図的に計画を外れたときには三枚目を撮ります。そのとき画面で何を見たかは、取引データだけでは再現できないからです。
• 口座履歴を定期的にエクスポートする。 ターミナルや顧客画面で取得できる履歴の期間は、ブローカーと口座種類によって異なります。口座仕様で一度確認し、余裕を持ってエクスポートを設定します。二年前のデータが取得できないと分かってからでは遅いからです。

7. 振り返りと、記録した決定に基づくプロセス変更

振り返りには周期の異なる三つのループがあり、さらに重要なのは対象も異なることです。混同すると、「毎週振り返っている」が事実でも、効果がまったく出ないことになります。

各ループは、振り返り自体の日付と識別子を付けた記載を残します。一定していれば形式は自由です。例えば週次振り返りなら REV-2026-W34 を使えます。この印がなければ、結果は出所不明の記載になり、結論のない振り返りと未実施の振り返りが台帳上で同じに見えます。

週次ループには、見落としやすい重要な区別があります。 有利な逸脱も、逸脱である。予定より早く決済して利益になったポジションも、無効化水準を動かす行為と同じ分類です。損失に終わった逸脱だけを数えるなら、測っているのは執行の順守ではなく損益です。

四半期ループが扱うのは結果ではなくプロセスです。この境界を守ります。戦略の結果、指標の定義、エクイティ曲線の読み方は 記事11.6の範囲です。プロセスの振り返りは別の問いに答えます。どの手順を行い、何を省き、どれだけ時間がかかり、何が不要になったかです。

変更には決定だけでなく記録が必要な理由。 同じ履歴で試す候補を増やすほど、最も良く見える候補が偶然そう見える確率も高まります。文献では戦略検証の分野で説明されている現象です^[5]。この脚注が裏付けるのはその分野だけですが、プロセスルールにも類似の選択問題が生じ得ます。同じ三十取引で評価する十回目の手順修正は、十個目の結論ではなく十回目のくじ引きです。変更カードは安価なカウンターになり、ルールを何回、どんな根拠で変えたかを示します。

8. 手動とシステム型のワークフロー：二つの構成

第2節の同じ経路でも、人が判断する場合とコードが判断する場合では姿が異なります。違いはツールの数ではありません。固有の故障点がどこにあり、それをどう見つけるかです。

手動型 は五つのブランドではなく五つの機能を基盤にします。発注場所は、ブローカーのサーバーにつながるターミナルです（記事11.1）。分析とアラートの場所はチャート環境です（記事11.2）。カレンダーの情報源とサイズ計算器は 記事11.3で扱い、利用できる計算器は ツール集にあります。第五の機能は計画と結果の記録先、つまり第3節の台帳です。

セッション前の準備は時間帯ではなく、成果物の一覧です。 執行時間を開く前に、四つの記録が必要です。読み取ったタイムゾーン付きで計画に転記した発表時刻、その日について確定し日付付きで保存した監視リスト、通知文が計画台帳を参照する一式のアラート、そして取引予定の各セットアップについて第5節の七項目を満たした計画です。判定は二択です。四つが記録されているか、準備がなかったかです。チャートを見た時間は関係ありません。執行時間中はアラートごとに、計画へ意思決定記録を追記します。見送りの場合も、むしろその場合こそ記録します。セッション後の成果物は一つ、決済した各ポジションの完成した日誌記録です。

常勤の仕事がある人向けとセッション時間内で働く人向けを分けた、日次・週次予定のひな型は、 チェックリストと週次ワークフローのツールキット項目にあります。ここに写すと重複し、趣旨からも外れます。予定は他人ではなく、自分のカレンダーから決めるものだからです。

システム型 は九要素で成り、リスクの配置も異なります。データ → コードリポジトリー → 実行環境 → 過去検証 → フォワードテストまたはデモ口座 → 導入 → 監視 → ログ → 振り返り、という流れです。意思決定段階がコード変更時に移るわけではありません。コード変更は第十一段階、プロセス変更です。取引判断は今もリアルタイムで行われますが、判断するのがルールになり、次の連鎖が痕跡として残ります。 シグナル → アルゴリズムの判断 → 上限検証 → ブローカーへのリクエスト送信 → サーバー応答。どの接点でプロセスが途切れたか後で特定できるよう、各接点を別々に記録します。一方、バージョン管理は第十一段階の話です。そこでは良い慣行にとどまらず、その週に自動化がどのルールで動いていたかを再現する条件になります。再現可能な環境は 記事11.8で扱い、テスト手順と、例えばMetaTrader 5テスターでの独立したフォワード期間は 記事11.7で扱います^[6]。導入、ログ、自分のポジションの識別、稼働の継続性は 記事11.5の範囲です。

9. 最小構成と、余分なツールのテスト

構成はブランドではなく機能で説明します。発注場所、分析とアラートの場所、カレンダーの情報源、サイズ計算場所、計画と結果の記録先という五機能です。一つのアプリが二機能を担えば、構成は五つでなく四つになります。タスクバーのアイコン数は何の尺度にもなりません。五機能それぞれに担当場所があり、それが一つに定まっているかが尺度です。

構成例を四つ。 以下は推奨やランキングではありません。各例は明示した一基準から作り、基準が構成にどう反映され、何を代償とするかを示します。基準を示さない「最良のツール」は検証できず、意味を持ちません。

余分なツールのテスト。 一か月停止し、それなしでは行えない手順を書き出します。一か月は慣例的な期間で、週次振り返りを数回含むよう選んだ出発点の案です。該当する手順がなければ、そのツールはプロセス内ではなく脇にあります。「役に立つか」という質問より優れる理由は一つです。テスト結果は四半期後にも示せる手順一覧になりますが、質問への答えは資料のない宣言です。追加判断は逆向きに行います。今うまくできていない手順と、その変わり方を示せたときに新しいツールを導入します。「皆が使うから」は手順の指摘ではありません。

テストの対象外。 保有監視、第11節の緊急経路、台帳のバックアップ、決定的な上限やキルスイッチを維持するものは停止対象にしません。安全策はプロセスのコピーやデモ口座で試し、保有のある実口座で無効化して試してはいけません。余剰性テストの目的は脇にあるツールの特定であり、安全策なしでどこまで耐えられるかの実験ではありません。

10. 反復的で低リスクな作業を自動化する

基準は一つですが、四条件を同時に満たす必要があります。反復的である、決定的である、エラーを検出できる、エラーの結果を元に戻せる、という条件です。一つでも満たさなければ、手作業の所要時間にかかわらず自動化候補にしません。

「はい」側には退屈だからこそ価値のある作業があります。通知の配信、履歴の日誌へのインポート、台帳・設定・画像のバックアップ、手でも再現できる数式計算、記録した定義に基づく指標の定期報告などです。共通点は自動でエラー検出できることですが、その確認を自動化に組み込む必要があります。気持ちだけでは不十分です。インポート件数と出所の件数の比較、バックアップのチェックサム、予定時刻にファイルがない場合の警報などを設けます。「すぐにエラーが分かる」原則には例外があります。壊れた、または不完全なバックアップは、復元する瞬間まで正常に見えます。そのため自動確認に加え、第11節の定期復元テストを残します。

少なくとも現段階で「いいえ」側に残るのは三つです。第一は売買の開始・終了判断で、ルールが 記事11.7の検証手順に合格するまでです。第二は自分の逸脱の分類です。欄を埋めることではなく、判断を要することに価値があります。第三は自分で手作業できないすべての活動です。自動化が悪いからではなく、誤って実行し始めても気付けないからです。

自動化は良い方向にも悪い方向にもプロセスを拡大します。ルールが誤っていれば、その結果を速く、ためらわずに繰り返します。決定的な上限、キルスイッチ、監視は最初の故障後でなく導入前に用意します。 記事11.5で扱い、実行コードの側からは 記事11.8で扱います。

11. 非常時手順と設定のバックアップ

故障は特別な事件ではなく、頻度の低い出来事です。つまり発生時には手順に不慣れになっています。だから短く書き残す必要があります。ツール層の手順は五段階で、順番自体も手順の一部です。

1. 故障した経路以外で口座状態を確認する。 モバイルアプリ、ブラウザーの顧客画面、ブローカーへの電話など、同じ要素を使わない経路なら構いません。予備経路の設定と制約は 記事11.4で扱います。
2. 修復を始める前に自動化を停止する。 取引権限の無効化やプロセス停止は診断より速く、原因の理解も不要です。動かしたまま診断すると、調べている間に条件が変わります。
3. ブローカー側で保有と未約定注文を確認する。ローカルコピーだけを見ません。通信切断後のターミナル表示は最後に把握した状態で、それが現状とは限りません。
4. インシデントは発生中に記録する。 タイムゾーン付き時刻、故障箇所、見たこと、行ったこと、口座の前後の状態を記します。一時間後には印象しか残らず、それはログや口座履歴と照合できません。
5. ブローカー側の状態と自分の記録が一致したと確認してから再開する。 照合前に自動化を再起動すると、ポジションの重複につながります。

事例の振り分け、連絡先カード、インシデント票、四半期テスト記録を含む完全な非常時計画は、 ツールキットの非常時計画にあります。ここでは本部の範囲に当たるツール層だけを扱います。

非常時でないときに一度確認しておくべきことがあります。 どの保護条件がブローカーのサーバーにあり、どれがアプリの稼働を必要とするか。電源断や通信断の後に保有がどうなるかを決める違いです。答えはプラットフォーム、方式、ブローカーによって異なります。具体的構成は 記事11.4 と 記事11.5で 確認します。

設定のバックアップ は同じ手順のもう半分で、パソコンを失った後、環境再構築にどれだけかかるかに答えます。再構築すべきものは思うほど多くありません。監視リスト、チャートテンプレート、通知文を含む有効なアラート群、第3節の三台帳、添付資料保管庫、そしてテキストファイルではなくパスワード管理ソフトに保存する認証情報です。保存場所は環境次第で、些細な違いではありません。コピーできるファイルがある環境も、ファイル自体がない環境もあります。次の表は2026年8月22日に提供元文書で確認した状態です。自分の構成では、バックアップ完了と判断する前に再確認してください。

実務的な結論は一つです。「設定ファイルをコピーする」だけではバックアップ手順を記述できません。一部の環境には、そのファイルがないからです。アカウントに設定を持つ環境では、復元手順に、安全を確保したアカウントへのアクセスと、アカウントだけでは復元できないものの独立した記録を含めます。特にアラート通知文と計画への対応関係が重要です。

12. ワークフロー監査：印象ではなく四つの測定

四半期のプロセス振り返りは、数値で終わって初めて意味を持ちます。「良くなった気がする」は前期と比較できず、監査結果ではありません。以下の四測定は最低限の案で、網羅的な一覧ではありません。それぞれ測定量の定義、範囲、データ源を示し、意味を持つ場合に分母と慣例的な閾値を加えます。五要素がそろうのは四つのうち二つです。所要時間には絶対的閾値がなく、ツールの余剰性には分母がないことを表で明示します。測定量、範囲、出所の定義がなければ前期との比較はできません。最初の二つは既存の台帳から直接計算できます。残る二つには、日付付き時間記録と日付付き余剰性テスト結果を一つずつ追加し、どちらもプロセス台帳に収めます。以下の閾値は慣例的な値で、自分との比較の出発点であり、実測による標準ではありません。

四測定は意図的に結果ではなくプロセスを記述します。余剰性も他の三つと同じくプロセスを測ります。悪いプロセスでも結果は良くなり得ます。取引の少ない四半期なら十分起こります。逆も同様で、忠実に実行したプロセスでも損失の四半期を防げません。この二評価を分けて初めて、不調期の後に、たまたま手元にあったツールを取り替えるのではなく、本当に失敗した部分を変えられます。

先へ進む前に一つ確認します。直近五取引を取り出し、建玉前に計画台帳の記載があったものを数えます。その割合を百分率で示したものが出発点です。記録完全性とまったく同じ定義を、四半期ではなく五取引に適用し、次の四半期に初めて比較する数値にします。画像と分類付き記録も併せて確認しますが、別に記します。単位の異なる別測定であり、この値と合算できないからです。

ここで述べたプロセスは、他者が決めた条件下で動きます。執行価格、取得できる履歴期間、使えるプラットフォーム、送信後の注文の扱いはブローカーの決定です。そこから 講座の次の部が 始まります。