まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

指値の導入・移行で起きる失敗と防ぎ方:未約定注文の扱いと切替前の確認

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • 指値の移行の失敗は、注文が消える、別の条件で残る、周りの計算や判定が変わるという形で現れる
  • 未約定の注文は、取引所へ取次済みか事業者側に留め置き中か、切替日をまたぐ期間指定かで分けて扱いを決める
  • 引き継ぐか出し直すかは、利用者に判断を戻せるか、期限の扱い、再入力の負担、誤りの広がり方で選ぶ
  • 突合は件数だけでなく一件ずつの価格・期限・状態まで行い、切替時刻をまたぐ注文でリハーサルする
  • 停止条件は差異の種類ごとに事前に決め、出し直し方式では取消前の告知と再注文の手段が実質的な保全策になる

IT professional working on a computer in a modern office setting, focused on coding and tasks.
▽ 写真の出典元

指値の移行で実際に起きる失敗は、注文の取消と前提条件の変化

旧システムの最終営業日に置いていた指値注文が、切替後の画面で消えていたり、期限や価格が違っていたりすると、注文を出した利用者は約定の機会を逃すか、意図しない約定を抱えることになります。
確認できた事業者の移行では、予約中の注文を一律に取り消して再注文を求めました。
あわせて、証拠金の計算方法が変わることによるロスカットの可能性も告知していました1。
防げるかどうかは、切替前の準備で決まります。
注文を状態と期限種別で棚卸しし、移すか出し直すかを先に決め、突合とリハーサルで確かめ、止め方と戻し方まで決めておけるかどうかです。

予約注文が一律取消になる例

指値注文とは、売買する価格をあらかじめ指定しておき、相場がその価格に届いたときに約定させる注文です。
移行で問題になるのは、この「まだ約定していない注文」が切替の瞬間にどこにあり、新しいシステムで同じ意味のまま生き続けるかどうかです。
約定済みの取引は履歴として移せば済みます。
未約定の指値は、これから相場に応じて執行される予定なので、扱いを誤ると利用者の売買結果そのものが変わります。

公開されている移行事例として、トレイダーズ証券が2016年に行ったFXのシステムリニューアルがあります。
同社は移行にあたって予約中の注文をすべて取り消し、移行後は新しい取引ツールで改めて注文を出すよう利用者に案内しました1。
注文を新システムへ移さず、一度ゼロにして利用者自身に出し直してもらう形です。

この方式なら、旧システムの注文が新システムで別の意味に化ける心配はなくなります。
その代わり、出し直しを忘れた利用者は、想定していた価格に相場が届いても約定しません。
指値を置いておくのは「この価格になったら売買したい」という意図を事前に預けておくことなので、取消はその意図をいったん失わせることになります。
失敗と呼ぶべきなのは取消そのものより、取消があることを利用者が知らないまま切替を迎えることや、再注文の手段や時間が足りないことのほうです。

この例は国内のFX事業者一社の告知です。
証券の現物株などの移行で同じ扱いが取られるとは限らず、取消方式が業界で一般的かどうかもこの一例からは判断できません。
ここでは、取消方式を採ったときに利用者側で何が起き得るかを読み取るのにとどめます。

証拠金計算の変更など注文以外の前提の変化

同じ告知では、注文の扱いとは別に、必要証拠金の計算がリアルタイムの価格を基準にする方式へ変わることも知らされていました1。
移行明けの月曜日の開始価格によっては、ロスカット(証拠金が不足したときに建玉を強制的に決済する仕組み)になる可能性があるという注意です1。

ここから分かるのは、注文データを一件も欠かさず移せたとしても、注文や建玉を評価する計算の前提が変われば、利用者の損益に影響が出得るということです。
この移行は土曜日に実施されたため、新しい計算方式が最初に市場の価格と出会うのは週明けでした1。
週末をまたいで価格が動けば、旧方式では余裕のあった口座が、新方式の最初の計算で不足と判定されることもあり得ます。

導入担当者の目線で言い換えると、移行の失敗は「データが欠けた」だけでは捉えきれません。
注文が消える、注文が別の条件で残る、注文は正しいが周りの計算や判定が変わる、という三つの形で現れます。
前の二つには注文データの棚卸しと突合で備え、最後の一つには新旧で変わる計算・判定の規則を洗い出して利用者へ伝えることで備えます。

指値の移行で利用者に影響が出る三つの形(公開された一事例にもとづく模式図)
注文が消える、注文が別の条件で残る、周りの計算や判定が変わるという三つの形が、約定機会の喪失、意図しない約定や失効、ロスカットの可能性につながることを示した図
▼ 図の内容を文字で読む
  • 注文が消える
    • 予約中の注文を一律取消
    • 再注文しなければ指定価格に届いても約定しない
  • 注文が別の条件で残る
    • 期限や価格の解釈違い
    • 意図しない約定や失効
  • 周りの計算や判定が変わる
    • 必要証拠金の計算方式の変更
    • 週明けの開始価格次第でロスカットの可能性

自社のどの注文が危ないか:状態・期限・価格条件で見分ける

取次済みの注文と事業者側で留めた注文

移すか出し直すかを考える前に、いま残っている未約定の指値注文が、どこで待っているのかを分けておく必要があります。
証券の注文には、事業者から取引所へすでに取り次がれて取引所側で待っている注文と、事業者のシステムの中に留め置かれている注文があります。
同じ「未約定の指値」でも、この違いによって、誰が取り消せるのか、どこで執行されるのかが変わります。

三菱UFJ eスマート証券(旧社名:auカブコム証券)が2021年に出した、取引所の売買システム障害時の注文の取扱いの案内が、この違いをよく示しています2。
取引所へ取り次いだ後に取引所で取り消された注文は失効扱いとなり、売買再開後に改めて取り次がれません2。
一方、事業者側で留めていた未取次の指値・逆指値などは、取引所が取り消せないため復旧後に順次取り次がれ、その間は利用者が取消や訂正をできるとされていました2。

これは障害時の扱いで、システム移行の規則ではありません。
それでも、注文がどこにあるかで結果が逆の方向に分かれるという点は、移行の棚卸しに使える視点です。
事業者側のシステムを入れ替える場合、取次済みの注文を切替後もそのまま有効とするのか、切替に合わせて取り消すのかは、取引所との接続の扱いを含めて決める必要があります。
留め置き中の注文は自社のデータだけで完結しているぶん、移行時の変換が結果を直接左右します。

期間指定注文の扱い

期間指定注文とは、当日限りではなく、有効期限を先の日付まで指定して出しておく注文です。
先ほどの障害時の案内では、取引所で取り消された注文は失効するのが原則でも、期間指定注文は翌営業日以降に改めて取り次ぐとされていました2。
同じ出来事に対して、当日限りの注文と期間指定注文とで扱いが分かれていたわけです。

移行に置き換えると、切替日をまたいで有効期限が残っている注文が、もっとも扱いを決めにくい集団になります。
当日限りの注文は旧システムの最終営業日に期限を迎えるので、切替日へ持ち越す必要がありません。
期間指定注文は、利用者が切替後も有効だと思って置いている可能性があり、取り消すなら個別の告知が、引き継ぐなら期限の正確な変換が要ります。

棚卸しでは、注文の総数より先に、期限が切替日より後に設定されている注文がどれだけあり、どの利用者が持っているかを把握しておくと、後の方式選びと告知の範囲がはっきりします。

価格・数量・期限の変換でずれやすい点

状態と期限種別で注文を分けたら、新システムへ移す予定の注文について、項目ごとに旧システムと新システムで意味が同じかを確かめます。
以下は仮定の例で、実際の項目定義は自社の新旧システムと接続先の仕様書で照らし合わせることになります。

たとえば、旧システムが期限を「何営業日後まで」という形で持ち、新システムが日付で持っている場合、変換時に休日の数え方がずれると、期限が一日早まったり遅れたりします。
価格についても、旧システムで保持していた小数点以下の桁数と、新システムで受け付ける価格の刻みが違えば、丸めによって指定価格がわずかに動きます。
指値は「この価格までなら売買してよい」という利用者の線引きなので、わずかな丸めでも、本来なら約定しなかった価格で約定する原因になり得ます。

数量や売買の区別、口座の区分も同じです。
旧システムで一つの項目にまとめて持っていた情報を新システムで別々の項目に分ける場合、分け方の規則が一つでも食い違えば、注文の意味が変わります。
危ないのは、件数も画面の見た目も合っているのに、項目の解釈だけがずれている注文です。

未約定の指値注文を所在と期限種別で分ける棚卸しの模式図
未約定の指値注文を、取引所へ取次済みか事業者側に留め置き中かで分け、それぞれを当日限りと期間指定に分け、移す注文で確かめる項目を示した図
▼ 図の内容を文字で読む
  • 取引所へ取次済みの注文
    • 当日限り
    • 期間指定(切替日をまたぐか)
  • 事業者側に留め置き中の注文
    • 当日限り
    • 期間指定(切替日をまたぐか)
  • 移す注文で意味の一致を確かめる項目
    • 価格の桁と刻み
    • 数量と売買区分
    • 期限の表し方

未約定注文は移すか出し直すか、切替方式はどう選ぶか

出し直し方式の実例

棚卸しで注文を集団に分けたら、それぞれについて「新システムへ引き継ぐ」か「切替前に取り消し、利用者に出し直してもらう」かを決めます。
確認できた実例は、トレイダーズ証券の出し直し方式です1。
同社は予約中の注文をすべて取り消して新ツールでの再注文を案内し、切替を土曜日に行ったうえで、週明けの開始価格による影響にも注意を促していました1。

出し直し方式の利点は、旧システムの注文の意味を新システムで再現しなくて済むことです。
前節で見た期限や価格の変換のずれは、注文を新システムで一から入力し直せば入り込みにくくなります。
その代わり、約定させるかどうかの判断を、いったん利用者の手に戻すことになります。
取消に気づかない、再注文が間に合わないという利用者が出れば、その分の約定機会は失われます。

引き継ぎ方式はその逆で、利用者は何もしなくても注文が残りますが、変換と検証の責任をすべて導入側が負います。
どちらの方式が一般に優れているかを示す資料はなく、自社の注文の構成と、利用者へ確実に連絡できるかどうかで選ぶことになります。

方式を分ける観点

一つめは、約定させるかどうかの判断を、いったん利用者に戻してよいかです。
相場を見ながら自分で発注し直す利用者が中心のサービスなら、取消と再注文は受け入れられやすいでしょう。
反対に、長い期限で注文を置いたまま普段はあまり画面を見ない利用者が多いなら、取消は気づかれないまま約定機会を失わせるおそれがあります。

二つめは、期間指定注文が切替日をまたぐかどうかです。
またぐ注文がほとんどなければ、取消による影響は限られます。
またぐ注文が多い場合、引き継ぐなら期限の変換を導入側が保証しなければならず、取り消すなら利用者ごとに、どの注文がいつ消えるのかを伝える必要があります。

三つめは、取消後の再入力の負担です。
注文を多く置いている利用者ほど出し直す手間が大きく、急いで入力すれば価格や数量の入力ミスも起きやすくなります。
出し直し方式は、変換の誤りを減らす代わりに、入力の誤りを利用者側へ移す面があります。

四つめは、切替直後に差異が見つかったときの影響範囲です。
引き継ぎ方式で変換規則に誤りがあれば、その誤りは引き継いだすべての注文に同じ形で広がり、市場が開いた時点で執行され得ます。
出し直し方式では、誤りは利用者ごとの入力に分散しますが、全員に再注文を求める以上、告知が届かなかった影響は広く出ます。

観点を並べると、注文の集団ごとに方式を分けるという選び方も見えてきます。
たとえば、当日限りの注文は旧システムの最終営業日で期限を迎えさせ、切替日をまたぐ期間指定の注文だけを取消と再注文の対象にして、持っている利用者へ個別に知らせる、といった組み合わせです。
これは考え方の一例で、自社の約款や取引所との取り決めのうえでそうした扱いができるかは、別に確かめる必要があります。

一括で切り替えるか、段階的に移すかという進め方も、同じ観点で考えられます。
段階的に移す場合、新旧の両方に注文が存在する期間ができるため、ある利用者の注文がどちらのシステムにあるのかを取り違えない仕組みが別に要ります。

観点 引き継ぐ 取り消して出し直す
約定させるかの判断 利用者の操作なしで注文が残る 利用者が改めて判断して出す
切替日をまたぐ期間指定注文 期限の変換を導入側が保証する 対象者への個別の告知と再注文が要る
再入力の負担 導入側の変換と検証に集中する 利用者側に生じる
切替直後の誤りの広がり方 変換誤りが全注文に同じ形で及ぶ 告知漏れや入力誤りが利用者ごとに出る
未約定の指値注文を引き継ぐ場合と出し直す場合の違い(考え方を整理した模式図)
引き継ぐ方式と取り消して出し直す方式で負担や誤りが生じる場所の違いと、集団ごとに方式を分ける組み合わせの例を示した図
▼ 図の内容を文字で読む
  • 引き継ぐ
    • 利用者の操作なしで注文が残る
    • 期限の変換を導入側が保証する
    • 変換誤りが全注文に同じ形で及ぶ
  • 取り消して出し直す
    • 利用者が改めて判断して出す
    • 対象者への個別の告知と再注文が要る
    • 告知漏れや入力誤りが利用者ごとに出る
  • 集団ごとに分ける組み合わせの例
    • 当日限りは最終営業日で期限を迎えさせる
    • 切替日をまたぐ期間指定だけ取消と再注文にする
    • 約款や取引所との取り決めで可否を別に確かめる

移行前後の突合とリハーサルで確かめること

突合する項目

方式を決めても、それが実装どおりに動くかは別の問題です。
AWSのデータベース移行のガイドでは、移行フェーズでデータを移行して検証し、変換・移行・テストを何度も繰り返す反復的なプロセスとして説明されています3。
売買注文に固有の手順ではありませんが、一度の作業で正しさを確かめきるのではなく、繰り返して差異を潰していくという前提は、指値の移行でも出発点になります。

突合では、移行前の旧システムの注文と、移行後の新システムの注文を一件ずつ対応させます。
具体的な項目は自社で決める部分ですが、考え方としては、まず注文の件数が集団ごとに一致するかを見ます。
次に一件ごとの価格・数量・売買区分・期限・状態が一致するかを見て、最後に引き継ぐ注文と取り消す注文の区分が棚卸しのとおりになっているかを確かめます。

件数が合っていても安心はできません。
前節で挙げた丸めのずれは、画面の表示では同じ値に見えることがあります。
価格や期限を一致と判定するときは、表示される値ではなく、システムが保持している値どうしで比べるほうが、解釈のずれを見落としにくくなります。

出し直し方式を採る集団では、新システムに注文が無いことが正しい状態です。
この場合の突合の相手は、取消対象の一覧と実際に取り消された注文です。
取消漏れが旧システムに残っていないか、取消を知らせる連絡を対象の利用者全員に送ったかを、送付の記録と照らして確かめます。

切替時刻をまたぐ注文でのリハーサル

リハーサルは、本番と同じ手順を検証環境で通して行う予行演習です。
指値の移行で特に試しておきたいのは、切替の時刻をまたいで生きている注文です。
旧システムの最終営業日に出され、期限が切替日より後に設定された期間指定の指値を用意し、移行後にその注文が決めたとおりの状態、つまり引き継ぐなら有効、出し直すなら取消済みになっているかを確かめます。

週末を挟む切替では、新しい計算が最初に動くのは週明けの開始価格に対してです1。
リハーサルで、旧システム最後の価格から大きく離れた開始価格を仮に置いて新しい計算を動かしてみると、どの口座が不足と判定されるかが事前に見えます。
結果は、利用者への注意喚起を誰に重点的に送るかを決める材料になります。

リハーサルで見つかった差異は、種類ごとに記録しておきます。
変換規則の誤り、仕様の解釈の違い、計算方式の変更による想定内の差、というように分けておくと、切替後にどの差異が出たら止めるかという基準づくりにそのまま使えます。
繰り返す回数や期間に決まった目安はありません。
差異の種類が出尽くし、前回までの修正で同じ差異が再発しないことを確かめられた時点を、区切りとして考えます。

指値の移行で繰り返す変換・移行・突合の流れ(汎用の移行ガイドの考え方を当てはめた模式図)
変換規則の見直し、検証環境への移行、一件ずつの突合、切替時刻をまたぐ注文でのリハーサル、差異の記録を経て、再び変換規則の見直しに戻る繰り返しを示した図
▼ 図の内容を文字で読む
  1. 変換規則の見直し
  2. 検証環境への移行
  3. 一件ずつの突合
  4. 切替時刻をまたぐ注文でのリハーサル
  5. 差異を種類ごとに記録

切替後に問題が出たときの止め方と戻し方

切替前に決めておく停止条件

AWSのガイドでは、機能テストとパフォーマンステストを終えたあとに新しいデータベースへカットオーバーできるとされています3。
テストの完了を切替の前提にするという考え方で、同じページは切替後に戻す手順までは扱っていません。
止め方と戻し方は、自社で事前に決めておく部分です。

一つの方法は、リハーサルで記録した差異の種類ごとに、本番で出たら新規の注文受付を止めるものと、記録したうえで運用で対応するものの線を引いておくことです。
たとえば、引き継いだ指値の価格や期限が一件でも旧システムと違えば止め、表示上の書式の違いなら続行する、といった分け方です。
指値の価格と期限は利用者の約定に直結するので、厳しい側に寄せておくほうが、切替の最中に迷わずに済みます。

止める判断を誰が下すか、どの時点までに判断するかも、あらかじめ決めておきます。
週末に切り替えるなら、週明けに市場が開くまでが確認に使える時間です。
市場が開いてからでは、引き継いだ注文が執行され始めるため、止めても取り戻せない結果が残ります。

取消済み注文は戻せないという前提

戻し方を考えるとき、出し直し方式には特有の事情があります。
旧システムで注文を取り消した後に新システムで問題が見つかり、旧システムへ戻すことにしても、取り消した注文が自動で復活するとは限りません。
取消は利用者への連絡も含めてすでに外へ出た行為で、システムの状態だけを巻き戻しても、利用者が受け取った案内や、すでに出し直された注文との整合は取れなくなります。

そのため出し直し方式では、戻すことを当てにせず、取消の前に利用者が確実に知り、再注文できる状態を整えておくことが、実質的な保全策になります。
トレイダーズ証券の告知は、取消と再注文の依頼に加えて、切替翌週の開始価格による影響まで事前に知らせていました1。
利用者が自分の注文と口座に何が起きるかを、切替の前に判断できる材料を渡していた点が参考になります。

引き継ぎ方式では、戻す余地は比較的残ります。
旧システムの注文データを切替時点の状態で保管しておけば、新システムを止めて旧システムで受付を再開する道があり得ます。
ただし、切替後に新システムで約定した注文や、利用者が新システムで訂正・取消した注文があれば、戻した先の旧システムにはその変化がありません。
戻すかどうかの判断期限を、新システムで最初の約定が起きる前に置くと、この食い違いを抑えやすくなります。

20代前半の日本人女性が会議室の全景をしている場面

どちらの方式でも、戻すかどうかを決める材料は、リハーサルで見た差異と本番で出た差異が同じ種類かどうかです。
リハーサルで一度も出なかった種類の差異が本番で出たなら、変換規則か前提の理解のどこかに見落としがある合図として受け止め、止める側に判断を寄せるのが安全です。

注文の所在や期限種別ごとの扱いは、約款、取引所との接続、新旧システムの仕様が絡むため、担当者だけでは線を引きにくい部分です。

棚卸しした注文の集団ごとに、引き継ぐか出し直すかの判断の筋道と、告知が必要になる利用者の範囲を一緒に整理できます。無料相談で要件を整理する

要点の整理

軸 基準
注文の所在 取引所へ取次済みか、事業者側に留め置き中か
期限種別 当日限りか、切替日をまたぐ期間指定か
方式の選び方 利用者に判断を戻せるか、変換を導入側で保証できるか
突合 件数だけでなく一件ずつ価格・数量・期限・状態を保持値で比べる
リハーサル 切替時刻をまたぐ注文と週明けの開始価格を想定して試す
停止条件 差異の種類ごとに、止めるか続けるかを切替前に決める
戻し方 出し直し方式は取消前の告知と再注文の手段が保全策
Close-up of a hand writing on a digital checklist using a stylus on a tablet, enhancing productivity.
▽ 写真の出典元

停止条件や戻す判断の期限は、切替の最中に決めようとすると迷いが生じやすく、事前に第三者の目で見直しておく価値があります。 リハーサルで出た差異の種類をもとに、本番で止めるものと続けるものの線引きと、判断の期限を切替前に確かめられます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

期間指定の指値注文は、システム移行の切替日をまたぐとどう扱われやすいですか

移行時の扱いについて、業界で共通の決まりを示す資料はありません。
参考になるのは取引所の障害時の案内で、取引所で取り消された注文は失効扱いでも、期間指定注文は翌営業日以降に改めて取り次ぐとされていました2。
移行ではこうした扱いが自動で適用されるわけではないので、切替日をまたぐ期間指定注文は、引き継ぐのか取り消すのかを集団として決め、持っている利用者に個別に伝えるのが確実です。

未約定の指値注文を全部取り消して出し直す場合、利用者への告知で何を伝えるべきですか

最低限、どの注文が取り消されるのか、いつ取り消されるのか、いつからどの手段で再注文できるのかを伝えます。
あわせて、注文以外に変わる前提も知らせます。
実例では、取消と再注文の依頼に加えて、必要証拠金の計算方式の変更と、移行明けの開始価格次第でロスカットになる可能性が告知されていました1。

切替直後の確認では、どの注文属性から先に見ればよいですか

まず状態、つまり有効か取消済みかが、決めた方式のとおりになっているかを見ます。
次に価格と期限です。
この二つは利用者の約定に直結し、丸めや日付の数え方のずれが画面の見た目では分かりにくいため、保持している値どうしで旧システムと突き合わせます。
数量や売買区分はその後に確かめます。

購買・発注の「希望単価指定」の移行も、売買の指値と同じ考え方でよいですか

旧システムと新システムで注文の意味が変わらないかを確かめる、という考え方自体は共通して使えそうです。
ただし、この記事で扱った事例は証券・FXの売買注文に限られ、取引所への取次や証拠金の計算といった前提は購買・発注にはありません。
どの属性が危ないか、取消と出し直しのどちらが現実的かは、購買側の業務と契約の条件に照らして別に確かめる必要があります。

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

> プロフィールの詳細を見る

  1. 1 出典:トレイダーズ証券株式会社「システムリニューアルに関するお知らせ(みんなのシストレ)」(2016年)
  2. 2 出典:三菱UFJ eスマート証券株式会社(旧社名:auカブコム証券)「取引所の売買システム障害時の注文の取扱いについて」(2021年)
  3. 3 出典:Amazon Web Services「AWS 規範ガイダンス データベース移行戦略 フェーズ3:移行」

画像の出典元

  1. IT professional working on a computer in a modern office setting, focused on coding and tasks./Photo by cottonbro studio on Pexels
  2. Close-up of a hand writing on a digital checklist using a stylus on a tablet, enhancing productivity./Photo by Jakub Zerdzicki on Pexels

Photos provided by Pexels

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top