KabuLink

• PC再起動や想定外停止でオフラインになった場合は、まず復旧手順の復旧コマンドを実行します。
• 復旧コマンドでオンラインに戻らない場合だけ、この画面でペアリングコマンドを再発行して実行します。
• まずBrokerアプリ → Agent復旧 → 選択済み接続の再開の順で戻すと復旧しやすいです。
• 最初はdry_runで検証し、real化は全項目OK後に進めます。

復旧コマンドは既存Agentの再起動用、ペアリングコマンド再発行はAgent登録情報を更新するための手順です。再インストールは最終手段として扱います。

停止・アンインストール手順は、先に接続を停止し、未約定注文を確認してからAgent常駐を解除します。詳細は docs/kabulink_stop_uninstall_guide.md を参照してください。

通常はオンライン/オフラインだけ確認すれば十分です。接続テストやAPI状態が失敗した場合に詳細ログを確認します。

PC再起動・想定外停止後も、基本的にAgentの再登録は不要です。kabulink-agent.env と KABULINK_AGENT_TOKEN が残っていれば同じPCへ再起動してください。

1. 1) まず対象接続を「停止」。未約定・未確定注文を確認。
2. 2) 証券会社アプリを再起動し、ログイン/取引状態を戻す。
3. 3) 同一配備先で下の復旧コマンドを実行し、常駐タスクを再登録・起動する。
4. 4) 1〜2分程度待ってオンライン復帰を確認。戻らない場合は、KabuLink画面でペアリングコマンドを再発行して実行する。
5. 5) それでも戻らない場合だけ、最新の配布ZIPを上書きまたは再展開し、ペアリングコマンドを再発行して入れ直す。
6. 6) オンラインになったら接続を「再開」して 接続テスト→API状態→注文一覧。

Windows想定配備先: C:\KabuLinkAgent。Linux/macOS/WSLは同等の配備先。

最新バンドル更新後の再起動

1. 1) 既存の kabulink-agent.env は残したまま、同じフォルダへ最新ZIPを上書き展開します。
2. 2) Windowsは更新スクリプトを実行します。Linux/macOS/WSLはsystemdユーザーサービスを再起動します。
3. 3) 再起動後、Agent一覧でOnline、接続テスト、API状態、必要なら注文一覧を確認してから接続を再開します。

cd C:\KabuLinkAgent
powershell.exe -ExecutionPolicy Bypass -File .\update-windows-agent.ps1

cd ~/kabulink
systemctl --user restart kabulink-agent.service

cd C:\KabuLinkAgent
powershell.exe -ExecutionPolicy Bypass -File .\agent-service\kabulink-agent-register-task.ps1

この復旧コマンドは、タスク（常駐処理）を開始して即座に制御を返すのが正常です。オンライン復帰は画面の「Agent一覧/Agent処理履歴」で確認します。

既に install-windows-agent.ps1 を実行済みなら、上記コマンドで復旧が最短です。通常の復旧ではペアリングコマンドを再発行しません。タスク起動で権限エラーが出る場合は、管理者権限で再実行してください。

復旧コマンドで戻らない場合は、Agentを削除する前に「ペアリングコマンド発行」で新しいペアリングコマンドを作り、同じフォルダで実行してください。Agent削除と再インストールは最終手段です。

mkdir -p ~/.config/systemd/user
cp agent-service/kabulink-agent.service ~/.config/systemd/user/
systemctl --user daemon-reload
systemctl --user enable --now kabulink-agent.service

サポートからログ取得を依頼された場合は、次を実行します。

cd C:\KabuLinkAgent
powershell.exe -ExecutionPolicy Bypass -File .\agent-service\kabulink-agent-diagnostics.ps1

通常は「接続テスト」で疎通確認します。real注文の前には必須ですが、dry_run/simulate の確認だけなら省略できる場合があります。次に下の「注文テスト」でKabuLink内の受信・注文処理を確認します。照合と保守は通常操作ではなく、注文状態が不明なときの確認用です。

接続テスト

APIキー、口座設定、Gateway疎通を確認します。実注文ではありません。

API状態

選択中ブローカーAPIの状態や口座アクセス可否を確認します。

残高確認

選択中接続の発注先口座について、証券会社APIから現在の残高・買付余力を取得します。実注文ではありません。

注文一覧

証券会社側の注文一覧を取得し、Agent処理履歴に表示します。該当するKabuLink注文ログがあれば状態も同期します。

照合

KabuLinkの注文ログと証券会社側の注文状態を突き合わせます。異常時・確認用です。

保守

古い未完了注文などを整理・確認します。通常は頻繁に使いません。

履歴

接続設定、Secret再発行、停止・再開などの変更履歴を確認します。

realへ切替

同じ接続をdry_run検証用とreal実発注用で切り替えます。real注文の前には最新の接続テスト成功が必要です。

停止

TradingViewのアラートを残したまま、この接続の処理だけ一時停止・再開します。

削除

接続を削除します。TradingViewに残った古いWebhook URLも使えなくなります。

Agent復旧と証券会社API復旧は別です。ここでは、Agentのオンライン復帰、Broker APIの復旧、接続テスト失敗を分けて確認します。

KabuLink画面から選択中の接続へテスト用シグナルを送ります。dry_run/simulateでは経路確認、本番では実発注確認として使います。TradingView本体からの送信テストは、この確認後に別途行います。

OKの目安: 経路確認ではaccepted/prepared、Agent型の実発注確認ではqueued後にAgent処理履歴と注文ログの完了結果を確認します。

alert_id生成

テスト用の一意なalert_idを作り、重複拒否を避けます。通常は自動生成ONのままで構いません。

選択銘柄を反映

Saxoで選択済みの銘柄をテストJSONへ反映します。銘柄ミスマッチの確認エラーを避けるために使います。

JSONをコピー

現在のテストJSONをコピーします。TradingView設定用のメッセージJSONは上のTradingView設定欄のものを使います。

実発注確認

取引モードが本番の接続に対して実注文を送る確認です。実行前に確認ダイアログを表示し、Agent型はqueued後にAgent処理履歴と注文ログで最終結果を確認します。

経路確認

選択中の接続へテスト用シグナルを送ります。dry_run/simulateでは実注文せず処理経路を確認します。

prepared

dry_runまたはプレビューで注文内容を準備した状態です。実注文は送信されていません。

queued

Agentへ実行ジョブを渡した状態です。まだ証券会社への送信完了ではありません。

submitted

証券会社APIへ注文を送信し、注文IDまたは受付状態を確認した状態です。

presubmitted / PreSubmitted

IBKRで証券会社側が注文を保持しており、取引所送信前または送信待ちの状態です。証券会社側には受領されていますが、約定ではありません。

accepted

証券会社または連携先が注文を受け付けた状態です。約定はまだ別確認です。

filled

約定済みです。

cancel_requested

取消を依頼済みです。最終的に取消済みになったかは証券会社側注文一覧で確認してください。

cancelled

取消済みです。

rejected / failed / inactive

拒否、失敗、または証券会社側で無効扱いです。診断とメッセージを確認してください。

実注文と実取消は別々に実行します。注文送信後にbroker_order_idを確認し、そのIDを対象に取消を送信します。dry_run確認は任意の事前確認です。

1. 事前確認

接続テスト、API状態、口座候補、残高確認がOKで、対象銘柄と数量が安全制限内であることを確認します。

2. 任意dry_run

必要に応じてdry_run接続で注文テストとWebull取消dry_run確認を実行し、preparedが返ることを確認します。休場時や既に確認済みの場合はこの手順を省略できます。

3. 実注文

real切替後は、接続ID、銘柄、売買、数量、注文種別を確認してから実注文を送信し、注文ログにbroker_order_idが出るまで待ちます。

4. 実取消

取消対象のbroker_order_idを確認してから取消ボタンを押し、注文一覧を更新してcancel_requestedからcancelledまたは証券会社側の終端状態へ同期されたことを確認します。

5. 退避

KabuLink側の取消が失敗、または状態が不明な場合は追加テストを止め、Webull画面で対象注文を確認してからログのエラーを保存します。