kabuステーションAPIでOCOが使えない｜損切りを生き残らせる設計

2026年8月10日

投資

株の自動売買を作ろうとして、三菱UFJ eスマート証券のkabuステーションAPIを調べていくと、わりと早い段階でぶつかる壁があります。

利確と損切りを、ひとつの注文で両立させる方法が用意されていないことです。

取引ツールの画面には「W指値」という機能があるのですが、僕が公式のAPIリファレンスを確認した範囲（2026年8月時点）では、発注APIにこれに相当する指定は見当たりませんでした。つまり自動化するなら、利確と損切りの両立を自分で作る必要があります。

これが、思っていたより厄介でした。設計をどうしたか、なぜそうしたかを書きます。

目次 [ close ]

この記事の位置づけ（先に明記します）

段階	状態
コードを書いた	✅ 済
実際のAPIに接続してテストした	❌ まだ
本番で運用した	❌ まだ

まだ一度も動かしていません。 API利用を申請したところで、これから検証環境での確認に入ります。以下は「動かしてみた結果」ではなく、設計と、その理由の話です。動かせば想定外の問題が出る可能性は高いと思っています。結果は分かり次第この記事に追記します。

参考：kabuステーションAPI 公式リファレンス／ W指値の公式説明

そもそもOCOとW指値は、別物だった

調べていて最初に整理が必要だったのが、ここでした。

一般的なOCOは、「利確の指値」と「損切りの逆指値」を2つの注文として同時に出し、どちらかが約定したらもう片方を自動で取り消す仕組みです。

一方、三菱UFJ eスマート証券の「W指値」は、公式の説明を読む限り作りが違います。指値注文を出しておき、株価が指定した水準に達したら、その指値を訂正するという注文です。公式サイトには「760円の指値注文を出しつつ、株価が680円まで下がったら指値を678円に訂正する」という例が載っています。

目的は近いのですが、内部の動きは同じではありません。 そして僕にとって重要だったのは、どちらにせよAPIからは指定できないという点でした。

なお、逆指値そのものはAPIで発注できます。「OCOが無い＝逆指値も使えない」ではないので、そこは分けて考える必要があります。

自分で作るということは

利確と損切りの両立を自前で組むということは、

1. 利確の注文と損切りの注文を、別々に出す 2. どちらかが約定したことを、自分で検知する 3. もう片方を、自分で取り消す

を、全部自前で書くということです。

そしてこの3番で失敗すると、注文が二重に生きたままになります。二重決済、注文の拒否、取消の遅延——想定していない注文状態が発生しえます。

最初に考えて、やめた案

素直に考えると、こうなります。

利確も損切りも、両方とも自分のプログラムで監視する。株価が利確ラインに来たら成行で返済、損切りラインに来ても成行で返済。注文は事前に出さない。

これなら二重に注文が生きることはありません。実装もシンプルです。

でもこれは採用しませんでした。

理由は一つです。自分のPCやプログラムが落ちたら、ポジションが無防備になるからです。

自動売買を作る動機は「人間が見ていなくても損切りが実行される状態を作ること」でした。それなのに、損切りを自分のプログラムに依存させたら、動機と矛盾します。 ネットが切れた、Windowsが再起動した、kabuステーションが落ちた——どれか一つで、建玉が裸になります。

採用した設計：役割を分ける

そこで、こう分けました。

	どこに置くか	理由
損切り	証券会社側に逆指値として置く	自分のPCやプログラムが落ちても、証券会社側に注文が残るから
利確	手元で監視して、到達したら成行返済	注文として置けないから。落ちたときの被害が相対的に小さいから

※逆指値を出したあとの有効期限や、kabuステーション終了時の扱いは、実機と公式仕様で必ず確認が必要です。「置いておけば絶対に生き残る」と決めつけないようにしています。

考え方は単純です。落ちたときに困る方を、証券会社側に置く。

損切りが消えたら、最悪の場合は資金が飛びます。利確が消えた場合は、利確の機会を逃したうえで、その後は証券会社側の逆指値まで損益が悪化しうる——という被害に留まります。同じ「注文が消える」でも、下限があるかどうかが決定的に違うので、守り方を変えました。

順序を間違えると、事故になる

ここが一番慎重に作った部分です。

利確ラインに到達したとき、損切りの逆指値が証券会社側に残っています。 これを放置したまま利確の返済を出すと、注文が二重になります。

なので、取り消してから利確を出すのですが、この順序が決定的に重要です。

❌ やってはいけない順序

1. 利確の返済を発注
2. 逆指値を取り消す

2で取り消しに失敗すると、返済注文が二重に生きた状態になります。

⭕ 採用した順序

1. 逆指値を取り消す
2. 取り消しが「確定」したことを、注文照会で確認する
3. 確認できたら、利確の返済を発注する
   → 確認できなければ、利確を出さない

ここで2行目が重要です。取消APIが成功を返しても、それは「取消要求を受け付けた」という意味でしかありません。発注のときに「受付は約定ではない」と考えるのとまったく同じで、取消も、注文照会で最終状態を確認するまで確定扱いにしないようにしています。

そして3行目。確認が取れなければ、利確をあきらめます。

ただし、ここも慎重に扱う必要があります。「取消に失敗した＝逆指値が確実に残っている」とは限りません。 通信がタイムアウトしただけで、証券会社側では取消が成立している可能性があるからです。

なので実際の扱いはこうしています。

結果が確定できないときは「状態不明」として扱い、新規の発注を止めて、注文照会と建玉照会で状態を取り直す。逆指値が有効だと確認できるまでは、保護済みとみなさない。

つまりこの順序は、失敗したときにどちら側に転ぶかで決めています。

失敗したときに「無防備になる」設計にしない。失敗したら「儲け損なう」側に倒す。

自動売買のコードを書くとき、正常系はだいたい誰が書いても動きます。差が出るのは、失敗したときにどうなるかでした。

他にハマったところ

設計を詰める過程で、危ないと気づいた点がいくつかあります。

「受付」は「約定」ではない

APIに注文を出すと、成功のレスポンスが返ってきます。でもこれは「注文を受け付けた」という意味であって、「約定した」ではありません。

ここを取り違えると、まだ約定していない数量に対して逆指値を置くことになります。逆指値は、約定照会で確定した数量に対して置かなければいけません。

「注文した数量」と「持っている数量」を混同しない

1,000株の注文が、600株だけ約定して残りが未約定、ということは普通に起きます。

ここで数量を取り違えると危険です。この時点で建玉になっているのは、約定した600株だけです。未約定の400株はまだ建玉ではないので、損切りの対象ではありません。

なので、

約定済みの600株に対して逆指値を置く
残り400株が追加で約定するたびに、保護する数量を増やしていく

という形にしました。

返済側でも同じ問題が起きます。返済注文が部分約定した場合は、 保有数量 −（返済の約定数量）−（まだ有効な返済注文の数量） を計算しないと、二重に返済を出してしまいます。

状態がおかしくなったら、続行せずに止める

どのポジションを保護しているかを、プログラムはファイルに記録しています。

このファイルが壊れていたり読めなかったりしたとき、「空っぽとして続行する」のは最悪の選択です。実際には建玉があるのに「何も持っていない」と誤認して動きます。

なので、読めなかったら停止するようにしました。動き続けるより、止まる方が安全な場面があります。

保護を外したのに掛け直せないときは、全部止める

一番怖いのがこの状態です。逆指値を取り消したあと、何らかの理由で新しい注文を置けなかった——ポジションだけがあって、損切りが無い状態です。

このときは通知して終わりにせず、キルスイッチを入れて全面停止するようにしました。

ただし正直に書くと、キルスイッチだけでは足りません。 全面停止で防げるのは「新しいポジションが増えること」だけで、今まさに裸になっている建玉は守られないままです。

なので停止と同時に、

1. 人間にすぐ通知して確認させる 2. 建玉と注文の状態を、APIから強制的に取り直す 3. 必要なら手動で返済するか、逆指値を出し直す

という復旧手順まで含めて、はじめて対策になります。ここは自動化しきれない部分だと考えています。

ついでに、資金管理もコードで強制した

ここまで書いてきたのは「出口」の話ですが、同じ考え方で入口にも仕組みを入れました。

僕は少し前に、自分で決めた資金管理ルールを破って、決算発表後の20分で18万円を失っています。1ポジション65万円と決めていたのに、467万円と516万円の建玉を持ちました。上限の約7.2倍と約7.9倍です。

→ 関連記事：決算発表後の20分で18万円の損失｜急騰に2回飛び乗った記録

このとき痛感したのは、「守るつもり」では守れないということでした。ルールを紙に書いても、その場の感情には勝てません。

なので、発注する前に必ず通るチェック層を作りました。ここで拒否されたら、プログラムは注文を出しません。

キルスイッチ（ファイルが存在したら全面停止）
1ポジションの金額上限
同時保有銘柄数の上限
1単元が上限を超える銘柄は、そもそも対象外にする
損切り注文の必須化と、損切り幅・損失額の上限
当日の実現損失の上限
同一銘柄への短時間の連続発注の抑止

太字にした2つは、実際にやらかしたことへの対策です。1単元が上限を超える銘柄に手を出したこと、損切りした直後に同じ銘柄を買い直したこと——どちらも、人間の意思では止められませんでした。

この設計が正しいかは、まだ分かりません

冒頭に書いたとおり、ここまではすべて設計と実装の段階で、実際のAPIには繋いでいません。動かせば想定外の問題が出る可能性は高いと思っています。結果は分かり次第、この記事に追記します。

自動化を進める順番についての考え方は、こちらに書きました。

→ 関連記事：株の自動売買は「出口」から考える｜個人が進める5段階の順番

よくある質問

Q. kabuステーションAPIでOCOは本当に使えないのですか？

僕が公式のAPIリファレンスを確認した範囲（2026年8月時点）では、発注APIにOCOやW指値に相当する指定は見当たりませんでした。一方で、逆指値そのものは発注できます。ツールの画面から使える機能と、APIから使える機能は別なので、そこは分けて考える必要があります。仕様は変更される可能性があるので、実装前に必ず最新の公式情報をご確認ください。

Q. 逆指値を置いておけば、損失は限定できますか？

限定はできません。逆指値は「その価格に達したら発注する」仕組みなので、寄り付きで大きく窓を開けた場合や流動性が薄い場面では、想定より不利な価格で約定します。逆指値は損失をゼロにする道具ではなく、判断を自分の裁量から外すための道具だと考えています。

Q. なぜ利確の方を手元で監視するのですか？逆ではダメですか？

逆にすると、プログラムが落ちたときに損切りが消えます。それは自動化する目的そのものを失う状態です。「落ちたときにどちらが困るか」で考えると、証券会社側に置くべきなのは損切りの方でした。

Q. プログラミングができなくても同じことはできますか？

証券会社のツールの画面からなら、W指値のような条件付き注文が使える場合があります。まずは自分が使う証券会社の注文機能で、どこまでできるかを確認するのが先です。画面でできることを、わざわざAPIで作り直す必要はありません。

※この記事の内容は個人の見解・設計記録であり、投資助言ではありません。記載のAPI仕様・機能は2026年8月時点で筆者が確認したものであり、変更される可能性があります。実際の利用にあたっては各証券会社の公式情報および利用規約を必ずご確認ください。自動売買プログラムの不具合による損失は利用者の責任となります。信用取引は元本を超える損失が生じる可能性があります。

決算発表後の20分で18万円の損失｜急騰に2回飛び乗った記録