非常時でも損失を最小化する“3段構え”が要点
外為オンラインのiサイクル2取引™運用中に、発注不能・約定遅延・価格配信遅れ・スプレッド拡大などのトラブルに直面したら、初動（止血）→記録（証跡）→連絡（復旧・照合）の順で淡々と進めるのが定石です。本記事は初動テンプレ、スクショ・ログの残し方、問い合わせフロー、復旧後の照合と再発防止KPIまで、実務でそのまま使える形に整理しました。
この記事で分かること
- 障害種別（発注不能・遅延・配信遅れ・スプレ拡大）の初動テンプレ
- iサイクル2取引™の安全停止・縮小ルールと切替運用
- 証跡として使えるスクショ・ログ・時系列メモの残し方
- 問い合わせ内容テンプレと連絡フロー（電話/チャット/メール）
- 復旧後の約定照合ステップと再発防止KPI設計
まずは“止血”：障害別・初動テンプレ
- 発注不能（エラーで通らない）：成行は封印→残存の予約は維持→新規は一時停止→回線/端末を切替→時刻・通貨・数量・エラー文言をメモ。
- 約定遅延：連打禁止→1本/30秒などに制限→ログ保存→スリップ増大が続けばロット半減＋新規休止。
- 配信遅れ・途切れ：チャートが止まったら監視のみ→予約は広め、新規・成行は見合わせ→バックアップ回線へ。
- スプレッド拡大：拡大幅のスクショ→新規休止→保有はOCO維持→落ち着いたらロット25%で試し再開。
iサイクル2取引™の安全停止・縮小ルール
自動運転ゆえ、「そのまま走らせない」判断が重要です。以下の簡易ルールを事前にメモしておき、迷わず実行します。
- 段階縮小：新規停止→稼働本数を50%→25%へ段階的に縮小。
- 再開基準：配信遅れ/スプレ拡大が30分連続で収束、平均滑りが平常±30%以内で25%再開→問題なければ当日100%へ。
- 保護：保有はOCO継続、成行禁止。逆指値は広すぎない位置に再調整。
証跡の残し方：スクショ・ログ・時系列メモ
- スクショ：画面全体（時刻・通貨・数量・価格・スプレッド・エラー文言・電波/回線表示）を撮影。
- ログ：アプリの約定履歴・注文履歴・通知ログを保存（日時と端末名をファイル名に）。
- メモ：「時刻→症状→対応→結果」を1行で時系列化。連絡時の伝達ミスを減らせます。
問い合わせフローとテンプレ
公式サポート（電話/チャット/お問い合わせフォーム）の最新の窓口・受付時間は、外為オンラインの公式サイトでご確認ください。連絡時は以下テンプレをそのまま使えます。
問い合わせテンプレ（コピー用）
【口座番号】（下4桁） 【氏名】（カナ） 【発生日時】（例：2025/05/10 21:03） 【端末/回線】（例：iPhone/4G→Wi-Fi切替も同様） 【ツール】（例：アプリ／PCツール／Web） 【通貨・数量】（例：USD/JPY 1万） 【症状】（例：発注エラー／配信遅れ／スプレ拡大） 【対応】（例：新規停止・ロット半減・再ログイン・端末/回線切替） 【証跡】（添付：スクショ/履歴ログ） 【要望】（例：当該時刻のサーバー状況と約定照合の依頼）
切替運用：回線・端末・ツールの“二系統化”
- 回線二重化：モバイル回線＋Wi-Fi。通信不安なら即切替。
- 端末二重化：スマホ＋タブレット/PC。ログイン情報は安全管理の上で事前登録。
- ツール二重化：アプリ＋Webツール。いずれかが重いときに迂回。
- 最小ロット試験：復旧確認は最小ロット1本で。
復旧後の約定照合：差分検出の手順
- 障害時間帯の注文履歴・約定履歴を抽出（CSVやスクショ）。
- 想定価格帯（自分の根拠足・板/気配）と比較。
- 平均滑り（pips）を平常期と比較。平常±30%超なら要精査。
- 不一致の疑いがあれば、時刻・通貨・価格を明示してサポートに照会。
再発防止KPI：数値で管理して“判断を短縮”
| 指標 | 定義 | 目安/トリガー | 対応 |
|---|---|---|---|
| 平均滑り | （約定価格−指値/成行板）の平均pips | 平常±30%超で異常警戒 | ロット半減→新規休止→照会 |
| 配信遅延 | ティック更新間隔の平均/最大 | 最大2秒超が連続 | 監視のみ→回線/端末切替 |
| スプレッド拡大率 | 拡大幅/通常幅（%） | 200%超が継続 | 新規停止→保有はOCO維持 |
| 停止回数 | 月内の運用停止回数 | 月2回以上 | レンジ/本数/ロットの再設計 |
障害シーン別のやっていい／ダメ早見表
“迷い”を減らすため、場面別に可否と代替行動を整理しました。成行は最後の手段、まずは予約と新規停止で守りを固めます。
| 場面 | やってよい | やってはいけない | 代替アクション |
|---|---|---|---|
| 発注エラー多発 | 新規一時停止／予約は広め維持 | 同一発注の連打・成行多用 | 端末/回線/ツール切替→最小ロットで検証 |
| 約定遅延 | IFD/OCOのみに限定 | 逆指値の過度な後追い移動 | ロット50%→25%へ段階縮小 |
| 価格配信遅れ | 監視のみ・記録強化 | 板が薄い時間の成行 | バックアップ回線・別端末へ即時切替 |
| スプレッド拡大 | 保有はOCO継続 | 新規の成行・想定外のナンピン | 拡大幅のスクショ→安定後に25%再開 |
| メンテ/告知あり | 事前の縮小・停止 | 終了直後のフル再開 | 最小ロットで通信確認→段階再開 |
連絡チャネルの使い分けと優先順位
窓口は状況で使い分けます。緊急＝電話／準緊急＝チャット／記録重視＝メールが基本の並びです（受付時間は公式で最新をご確認ください）。
| チャネル | 向く状況 | 強み | 弱み | ひと言メモ |
|---|---|---|---|---|
| 電話 | 執行中/即時相談 | 初動が早い・切替提案 | 混雑時に待ち | 要点を結論→状況→要望で簡潔に |
| チャット | 準緊急/文章で整理 | ログが残る・画像添付 | 機密照会は不可な場合 | テンプレで穴なく送る |
| メール | 照合・後日対応 | 証跡/添付が万全 | 返信に時間 | 件名は「要約」＋日付＋通貨 |
ケーススタディ（A〜D）：現場での判断を具体化
4つの代表例で、停止・縮小・再開・照会までの一連の流れを具体化します。
ケースA：米雇用統計でスプレ拡大
- 新規を60分前停止→保有はOCO維持
- 拡大幅を時刻つきでスクショ
- 安定確認30分→25%→50%→100%再開
ケースB：配信遅れと発注不能が併発
- 新規停止→端末/回線/ツールを順に切替
- 最小ロットで試験約定→平均滑りを記録
- 継続なら電話→照会、記録を添付
ケースC：深夜帯の板薄＋成行多用
- 成行封印→予約限定へ切替
- ロット50%縮小、レンジは広め
- 朝の流動性回復後に段階復帰
ケースD：復旧後の照合で乖離懸念
- 想定価格との乖離一覧を作成
- 時刻・通貨・価格を明記しメール照会
- 返信はPDF保存→改善KPIへ反映
※スマホは横にスライドしてカードを確認できます。
停止→再開テンプレ（コピペOK）
【停止トリガー】配信遅延2秒超が連続／平均滑りが平常±30%超／スプレッド拡大200%超が10分継続 【初動】新規停止→ロット50%縮小→成行禁止→記録（スクショ・履歴・メモ） 【切替】回線→端末→ツールの順で切替、最小ロットで試験 【再開】指標後30分＆KPI収束→25%再開→問題なければ当日100%へ 【照会】疑義があればテンプレで電話/メール。返信はPDF保管
証跡のフォルダ構成テンプレ
/Incident_YYYYMMDD_HHMM/ ├─ 01_Screenshots/ （画面全体・スプレ・エラー・時刻） ├─ 02_Logs/ （約定履歴CSV・通知ログ・アプリログ） ├─ 03_Notes/ （時系列メモ：時刻→症状→対応→結果） ├─ 04_Contact/ （送信文・受付番号・担当者・録音/要点） └─ 05_Response/ （返信メールPDF・照合結果・社内共有）
安全運用の最小セット（チェックリスト）
- 回線（4G/5G＋Wi-Fi）・端末（スマホ＋PC/タブ）・ツール（アプリ＋Web）の二系統化
- 停止/再開の数値トリガーを事前定義（遅延・滑り・スプレ拡大）
- 予約限定を標準、成行は例外に限定
- 毎週のKPIレビューで改善（平均滑り・停止回数・復帰時間）
- 問い合わせテンプレ・フォルダ構成を事前に準備
復旧後の照合と再発防止チェックリスト
障害が落ち着いたら、実害の有無と次回に備える仕組み化を淡々と進めます。以下を上から順に確認してください。
- 約定照合：発注ID・時刻・通貨・数量・価格を履歴CSVで確認。想定との乖離を一覧化。
- 損益差分：乖離に起因する損益影響を試算（平均滑り・拡大スプレッドを別列で管理）。
- ログ保存：スクリーンショット・通知ログ・問い合わせ履歴・回答PDFを日付フォルダへ。
- KPI更新：平均滑り、停止回数、停止〜再開の所要時間、エラー率を週次ダッシュボードに反映。
- ルール調整：停止トリガー・段階再開の閾値・成行禁止条件・ロット縮小率を数値で再定義。
- バックアップ訓練：月1回、回線／端末／ツール切替のリハーサルを実施（最小ロットで）。
| KPI | 目安 | 改善アクション |
|---|---|---|
| 平均滑り（pips） | 平常時の±30％以内に収束 | 悪化でロット50％→25％へ段階縮小、予約限定へ統一 |
| 停止回数/週 | イベント週：1〜3回 / 平常週：0〜1回 | 停止トリガーを「遅延・配信・スプレ拡大」に分解し閾値を見直し |
| 停止→再開の所要 | 30〜120分（イベント規模に依存） | 通信確認の手順短縮、25%→50%→100%の復帰段階を自動化（テンプレ運用） |
| 問い合わせ応答SLA | 当日〜翌営業日で一次回答 | テンプレ送信で不足情報ゼロ化、受付番号・担当・要点の即メモ |
まとめ
- 初動は「新規停止・成行禁止・記録開始」を即時実行し、迷いを排除する。
- 連絡チャネルの使い分け：緊急＝電話／準緊急＝チャット／記録重視＝メール（証跡は必ず保存）。
- 段階再開：25%→50%→100%の順で徐々に復帰し、各段階でKPI（滑り・遅延・スプレッド）を確認。
- 定量照合：発注ID・想定/実約定・差分を一覧化し、乖離の影響額を算出して問い合わせに添付。
- ルールの数値化・更新：停止トリガー、成行禁止条件、ロット縮小率を数値で管理し、事後に改訂。
- 冗長化訓練：回線・端末・ツールの切替を定期リハーサルし、非常時の所要時間を短縮。
よくある質問（FAQ）
Q1. 停止トリガーは何を基準に決めればいいですか？
目安は「通常比の明確な悪化」です。例：
・平均スプレッドが通常の2倍超／配信の明確な遅延が継続
・平均滑りが平常±30％を大きく逸脱
・アプリやWebのエラー頻発
いずれかを満たしたら新規停止・成行禁止を即時実行します。
・平均スプレッドが通常の2倍超／配信の明確な遅延が継続
・平均滑りが平常±30％を大きく逸脱
・アプリやWebのエラー頻発
いずれかを満たしたら新規停止・成行禁止を即時実行します。
Q2. 停止中の保有ポジションはどう扱うべき？
原則はOCO（利確/損切り）の維持です。むやみに触らず、逆指値の有効性と証拠金維持率だけ確認。システムの挙動が不安定な間は新規・成行は禁止が無難です。
Q3. 再開の目安は？成行はいつ解除できますか？
25%→50%→100%の段階復帰で、各段階ごとに平均滑り・配信遅延・スプレッドが平常域へ戻っているかを確認。
成行の解除は平常KPIが連続で良化した後に限定的に実施し、基本は予約（指値/逆指値）中心を推奨します。
成行の解除は平常KPIが連続で良化した後に限定的に実施し、基本は予約（指値/逆指値）中心を推奨します。
Q4. サポートへの問い合わせは何を送ればいい？
テンプレ例：
「口座番号下4桁／時刻／通貨・数量／注文種別／想定価格→実約定価格／差分（pips）／発生画面（端末・OS）／スクショ3枚」
発注IDと履歴CSVを添付すると検証が早まります。
「口座番号下4桁／時刻／通貨・数量／注文種別／想定価格→実約定価格／差分（pips）／発生画面（端末・OS）／スクショ3枚」
発注IDと履歴CSVを添付すると検証が早まります。
Q5. 障害による損失は補填されますか？
一般に補填は約款・個別判断となります。
まずは事実関係を定量化（乖離一覧・スクショ・ログ）し、受付番号を取得したうえで回答を待つのがセオリーです。
まずは事実関係を定量化（乖離一覧・スクショ・ログ）し、受付番号を取得したうえで回答を待つのがセオリーです。
Q6. 週末やメンテに備えて事前にできることは？
予定表の確認→段階縮小→ログ出力→バックアップ動作確認が基本です。
具体的には、保有の軽量化、履歴CSVの保存、代替回線・端末の接続テスト、二段階認証の再確認までをチェックします。
具体的には、保有の軽量化、履歴CSVの保存、代替回線・端末の接続テスト、二段階認証の再確認までをチェックします。
コメント