alpaca-trading-paper-trading-cli

Name: alpaca-trading-paper-trading-cli
Author: alpacahq

github.com/alpacahqその他157101 回インストール1 週間前に更新

リポジトリ

alpaca-trading-paper-trading-cli について

Alpacaのペーパートレード口座を使うユーザー向けに、Alpaca CLIで注文をプレビュー、送信、管理する手順を示すスキルです。戦略と注文設定を確認し、取引前にalpaca doctorでペーパー用エンドポイントを検証します。

主な機能

01戦略と注文設定の確認
02alpaca doctorによるペーパー用接続先の検証
03実行するCLIコマンド付き注文プレビュー
04注文送信と状態確認
05株式・オプション・暗号資産に対応

活用シーン

01ペーパー口座で取引戦略を試す
02送信前に注文パラメーターとリスク制御を確認
03注文ID・状態・送信内容を個別に検証
04約定・拒否・取消を追跡

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/alpacahq/alpaca-skills --skill alpaca-trading-paper-trading-cli

インストール後、Claude Code で/alpaca-trading-paper-trading-cliを入力して読み込まれたか確認します。

同梱ファイルreference.md

詳細

Alpaca ペーパートレーディング — CLI バージョン

Alpaca CLI を使って、ペーパートレーディングの注文をプレビュー、送信、確認、管理する場合に、このスキルを使用してください。

このスキルは、独自の Alpaca ペーパートレーディング口座、CLI プロファイル、ローカルワークスペースを使用する Trading API ユーザー向けです。エージェントはすべての操作を alpaca コマンドラインツールで実行するため、すべてのコマンドとその出力を完全に確認できます。

これは CLI 専用バージョンです。実装に依存しない汎用バージョンと、MCP サーバー版も関連スキルとして用意されています。

0 - AI エージェントによるこのスキルの使用方法

シグナルの情報源から始めます。 トレードアイデアの発生元（バックテストの結果、手動のアイデア、スケジュールされたトリガー、戦略の出力など）を特定します。
戦略のロジックを説明し直し、確認を求めます。 投資の根拠、想定される動作、注文が実行される条件を要約します。先に進む前に、ユーザーの確認を待ちます。
すべての設定を収集して確認します。 タイミング、資産クラス、シンボル、売買方向、数量／想定元本、注文タイプ、TIF、指値／逆指値価格、時間外取引フラグ、リスク管理、証拠金の使用など、すべてのパラメーターを明示して確認します。
CLI がペーパーエンドポイントを参照していることを確認します。 alpaca doctor を実行し、Trading: の行が https://paper-api.alpaca.markets であることを確認します。ライブエンドポイントが表示された場合は、直ちに停止してユーザーに知らせます。
書式を整えた表で注文の全容をプレビューします。 実行する CLI コマンドも正確に記載します。
注文ごとに明示的な確認を求めるかどうかを尋ねます（デフォルト：ON）。セッション中はユーザーの希望に従います。
ペーパープロファイルを使って、alpaca order submit で注文を送信します。
注文 ID、ステータス、送信したペイロード、次回の確認用コマンドを返し、ユーザー自身で確認できるようにします。
alpaca order get で注文のライフサイクルを監視します。ポートフォリオへの影響とともに、約定、拒否、キャンセルを報告します。
ライブ取引は絶対に行いません。 注文を送信する前に、毎回、接続先がペーパーエンドポイントであることを確認します。環境に少しでも曖昧な点があれば、停止します。

1 - 前提条件

Alpaca CLI がインストールされ、PATH に設定されていること

alpaca version

必要に応じてインストールします：

# Homebrew (macOS / Linux)
brew install alpacahq/tap/cli

# Or with Go — requires $GOPATH/bin (typically ~/go/bin) on your PATH
go install github.com/alpacahq/cli/cmd/alpaca@latest

CLI はアルファプレビュー版です。リリースによってコマンド、フラグ、出力形式が変わる場合があるため、エージェントはこのファイル内の一覧を信頼せず、実行時にフラグを確認します。

ペーパープロファイルが設定されていること

alpaca profile login
# or with API key
alpaca profile login --api-key

ログイン方法を確認します：

alpaca profile login --help

接続が検証済みであること

alpaca doctor

エージェントは、取引セッションのたびに開始前にこれを実行します。失敗した場合、注文は送信されません。

資産クラスごとの要件

資産クラス	要件
米国株式	ペーパー口座が有効であること
オプション	ペーパー口座でオプション取引が有効であること
暗号資産	ペーパー口座で暗号資産取引が有効であること

環境

Go を使ってインストールする場合のみ Go ツールチェーンが必要です。Homebrew のフォーミュラにはビルド済みバイナリが含まれており、Go は必要ありません
クライアント注文 ID 用の uuidgen または同等のツール

外部の jq は不要です。CLI には、独自の JSON 出力をフィルタリングする組み込みの --jq フラグが用意されています。

2 - 入力を収集する

エージェントは注文の構築に進む前に、以下の情報を収集します。

パラメーター	説明	デフォルト	必須
`signal_source`	取引アイデアの発生元（バックテスト、手動、スケジュール、戦略）	—	はい
`symbol`	ティッカーシンボル（例：AAPL、BTC/USD、AAPL250718C00200000）	—	はい
`asset_class`	`us_equity`、`us_option`、`crypto`	`us_equity`	はい
`side`	`buy` または `sell`	—	はい
`qty`	株式／契約／コインの数量	—	はい（または notional）
`notional`	金額（端株）。`day` TIF の成行注文のみ対応し、`qty` と併用できません	—	はい（または qty）
`order_type`	`market`、`limit`、`stop`、`stop_limit`、`trailing_stop` — 対応する値は資産クラスによって異なります	`market`	はい
`time_in_force`	`day`、`gtc`、`ioc`、`fok`、`opg`、`cls` — 対応する値は資産クラスによって異なります	株式およびオプションでは `day`、暗号資産では `gtc`	はい
`order_class`	`simple`、`bracket`、`oco`、`oto`（株式）；`simple`、`mleg`（オプション）；`simple`（暗号資産）	`simple`	いいえ
`limit_price`	limit／stop_limit に必須	—	条件付き
`stop_price`	stop／stop_limit に必須	—	条件付き
`trail_percent`	trailing_stop 用	—	条件付き
`trail_price`	trailing_stop 用	—	条件付き
`extended_hours`	プレマーケット／アフターマーケットでの約定を許可します	`false`	いいえ
`client_order_id`	冪等性キー。最大128文字	省略した場合、Alpaca が自動生成します	いいえ
`profile`	Alpaca CLI のプロファイル名。セッション全体に適用するには、`ALPACA_PROFILE` 環境変数で設定します。`-p`／`--profile` フラグでは設定しないでください。手順10の警告を参照してください	現在有効なペーパープロファイル	いいえ
`output_format`	デフォルトは JSON。CSV の場合は `--csv`、絞り込みには `--jq '<expr>'` を使用します	JSON	いいえ
`confirmation_mode`	各注文の前に明示的な「はい」の確認を必須にします	`ON`	いいえ
`max_position_pct`	ポートフォリオの単一ポジションに割り当てる最大割合	なし	いいえ
`max_order_value`	単一注文の notional に対する上限	なし	いいえ

戦略確認チェックリスト

注文を構築する前に、エージェントは以下を確認します。

戦略のロジックが明確に示されている
注文がどのような処理を行うか理解している
エントリー条件を満たしている（バックテスト／シグナルに基づく場合）
イグジット条件／ストップロス計画について話し合っている
ポジションサイズが意図的に決められている
リスク管理策を確認している

3 - 信頼できる情報源

エージェントは、検証に以下の信頼できる情報源を使用します。

情報源	URL	用途
注文の作成	https://docs.alpaca.markets/us/reference/postorder	注文パラメーター、資産クラスごとの制約、ステータスコード
Alpaca CLI ドキュメント	https://docs.alpaca.markets/us/docs/alpacas-cli	CLI コマンド、フラグ、構文
注文タイプ	https://docs.alpaca.markets/us/docs/orders-at-alpaca	注文タイプの動作と要件
ペーパートレード	https://docs.alpaca.markets/us/docs/paper-trading	ペーパー環境の詳細
オプション取引	https://docs.alpaca.markets/us/docs/options-trading	オプション注文の要件と承認レベル
暗号資産取引	https://docs.alpaca.markets/us/docs/crypto-trading	暗号資産注文の詳細
Alpaca の開示事項	https://alpaca.markets/disclosures	開示に関する文言

CLI の確認ルール

エージェントはこのファイルを鵜呑みにせず、実行時にフラグを確認します。

alpaca --help-all              # full command tree with every flag
alpaca order submit --help     # flags for one command
alpaca order submit --schema   # response shape, without calling the API

CLI は Alpha Preview のため、フラグや出力形式はリリースごとに変わる可能性があります。このスキルの記載が --help の出力と矛盾する場合、その記載は古くなっています。CLI の内容を優先してください。

4 - ワークフロー

フェーズ 1：戦略の確認

ステップ 1 — シグナルの発生元を特定します。

エージェントが次のように尋ねます。「このトレードアイデアはどこから来たものですか？」選択肢は次のとおりです。

完了したバックテスト（利用可能であれば、実行フォルダーへのリンク）
あなたが説明した手動のトレードアイデア
スケジュールされた、または定期的に実行される戦略トリガー
別のスキルまたはシステムからの出力

ステップ 2 — 戦略のロジックを再確認します。

エージェントが次の内容を要約します。

投資仮説（このトレードを行う理由）
期待される結果
時間軸
決済条件または損切り計画

ステップ 3 — 解釈を確認します。

エージェントが次のように尋ねます。「この解釈で正しいですか？注文の設定に進んでもよいですか？」

フェーズ 2：設定の確認

ステップ 4 — 資産クラスとシンボルを確認します。

エージェントがシンボルの形式を検証します。

株式：AAPL、MSFT
オプション：OCC 形式 AAPL250718C00200000
暗号資産：BTC/USD、ETH/USD

形式は必要条件ですが、それだけでは十分ではありません。形式が正しいシンボルでも、取引できない場合や上場廃止になっている場合があります。エージェントは資産レコードと照合して確認します。

alpaca asset get --symbol-or-asset-id AAPL

status = active および tradable = true が必要です。また、名目金額または端株数量で注文を提案する前に、fractionable を確認します。オプションの場合は、OCC 文字列を手作業で組み立てるのではなく、alpaca option contracts --underlying-symbols AAPL を使って実際の契約を解決します。

ステップ 5 — 売買の別、数量、注文タイプを確認します。

ステップ 6 — 有効期間と価格設定パラメーターを確認します。

有効期間は資産クラスによって異なります。API が無効な組み合わせを拒否するため、エージェントはコマンドを作成する前に組み合わせを検証します。

資産クラス	注文タイプ	有効期間	注文クラス
米国株式	`market`、`limit`、`stop`、`stop_limit`、`trailing_stop`	`day`、`gtc`、`opg`、`cls`、`ioc`、`fok`	`simple`、`bracket`、`oco`、`oto`
米国オプション	`market`、`limit`、`stop`、`stop_limit`（`stop` タイプは単一レッグのみ）	`day`、`gtc`	`simple`、`mleg`
暗号資産	`market`、`limit`、`stop_limit`	`gtc`、`ioc` — ただし、`stop_limit` は `gtc` のみ、`ioc` は `market` と `limit` のみに適用	`simple`

CLI はシンボルの形式に基づいて有効期間のデフォルトを設定します。/ を含むシンボル（暗号資産ペア）は gtc、それ以外は day がデフォルトです。そのため、--time-in-force を指定せずに暗号資産の注文を送信すると、day ではなく gtc が送信されます。

Alpaca の公式情報源ではオプションの行に食い違いがあるため、絶対的な制約ではなく指針として扱ってください。OpenAPI 仕様の TimeInForce／OrderType の説明では、オプションは market／limit のみで、有効期間は day のみとされています。一方、Options Trading ページと Placing Orders の一覧表では、どちらも gtc が許可され、どちらも単一レッグ注文で stop／stop_limit が許可されています。2 つの製品ページは仕様の記述と異なり、互いには一致しているため、この表では製品ページに従っています。それでもエージェントは安全策として day をデフォルトにし、一覧表で許可されている注文を事前にブロックせず、Alpaca に拒否させます。

注文タイプをまたいで適用される追加制約は次のとおりです。

時間外取引には、有効期間が day または gtc の limit タイプが必要です。それ以外のタイプと有効期間はすべて拒否されます。
トレーリングストップで使用できる有効期間は day と gtc のみです。
名目金額注文は、有効期間が day の成行タイプのみです。qty と組み合わせることはできず、注文の置き換えもできません。代わりに、キャンセルして再送信してください。
Bracket、OCO、OTO クラスで使用できる有効期間は day または gtc のみです。時間外取引には対応せず、株式専用です。
オプションは時間外取引に一切対応していません。マルチレッグ戦略では最大 4 レッグの mleg 注文クラスを使用します。また、stop／stop_limit タイプは単一レッグのみです。

ステップ 7 — 時間外取引とクライアント注文 ID の設定を確認します。

Alpaca は通常取引時間外に 3 つのセッションをサポートしており、いずれも指値注文で extended_hours: true が必要です。

セッション	時間帯（ET）	曜日
オーバーナイト	8:00pm – 4:00am	日曜日から金曜日
プレマーケット	4:00am – 9:30am	月曜日から金曜日
アフターアワーズ	4:00pm – 8:00pm	月曜日から金曜日

すべての資産がオーバーナイト取引に対応しているわけではありません。エージェントは対応可能と決めつけず、資産レコードで適格性を確認します。

ステップ 8 — リスク管理を確認します。

エージェントは、ポジションサイズや最大評価額に関する制約を提示し、次の項目を検証します。

注文の名目金額と購買余力
新規ポジションのポートフォリオに対する集中度
同じシンボルへの既存エクスポージャー

ステップ 9 — 設定の最終確認を行います。

エージェントはすべてのパラメーターをまとめた表を表示し、「すべてのパラメーターを確認しましたか？」と尋ねます。

フェーズ 3：CLI によるペーパー口座の確認

ステップ 10 — CLI がペーパー取引エンドポイントを解決することを確認します。

alpaca doctor

alpaca doctor は、Connectivity: の下に完全に解決された取引エンドポイントを出力します。

Connectivity:
  Trading:  https://paper-api.alpaca.markets

エージェントは、この行が https://paper-api.alpaca.markets であることを確認する必要があります。プロファイル名では代用できません。CLI は固定された順序でペーパーとライブを解決します。最初に ALPACA_LIVE_TRADE、次にアクティブなプロファイルの live_trade フィールド、最後にペーパーをデフォルトとして使用します。そのため、ALPACA_LIVE_TRADE=true がエクスポートされていると、名前が「paper」のプロファイルでもライブエンドポイントに直接送信されます。alpaca doctor は、この一連の処理の結果を報告します。

⚠️ alpaca doctor は -p／--profile フラグを無視します。 フラグを受け付けますが、値を黙って破棄し、常にデフォルトのプロファイルを報告します。他のすべてのコマンドは -p を尊重します。そのため、alpaca doctor -p live は ペーパー エンドポイントを報告する一方、alpaca order submit -p live は ライブ で取引し、チェックを通過したまま注文がライブで送信されます。

したがって、エージェントはどのコマンドにも -p／--profile を 決して渡しません。 デフォルト以外のプロファイルを指定するには、セッション全体に対して ALPACA_PROFILE を一度設定します。これは doctor も尊重するため、チェックと注文で同じエンドポイントが解決されます。セッション内のいずれかのコマンドに -p が渡されようとしている場合、エージェントはその時点で停止します。

Trading: の行に https://api.alpaca.markets と表示されている場合、エージェントは直ちに停止します。

⚠️ ライブエンドポイントを検出しました。エージェントは続行しません。ALPACA_LIVE_TRADE の設定を解除するか（または false に設定すると、ライブプロファイルでもペーパーが強制されます）、alpaca profile switch <paper-profile-name> でペーパープロファイルを選択してから、再起動してください。

ステップ 11 — 同じ alpaca doctor の出力から接続を確認します。

エージェントは、すべてのチェックに合格したことを確認します。いずれかが失敗した場合は、その失敗を報告して続行しません。alpaca doctor は再実行しません。1 回の実行で、このステップとステップ 10 の両方をカバーします。すべてのチェックに合格した場合、alpaca doctor は終了コード 0 を返し、いずれかのチェックが失敗した場合は 1 を返します。

ステップ 12 — 口座のステータスを取得します。

alpaca account get

エージェントは次の値を解析して確認します。

status = ACTIVE
account_blocked = false
trading_blocked = false
trade_suspended_by_user = false
multiplier — 証拠金の分類であり、口座オブジェクトに含まれる PDT の唯一のシグナルです。1 は証拠金が制限された現金口座タイプ、2 は Reg T 証拠金口座、4 は日中の購買力が 4 倍の PDT 口座を示します。

Trading API の口座オブジェクトには、pattern_day_trader フィールドも daytrade_count フィールドもありません。エージェントはこれらを参照せず、代わりに multiplier から PDT ステータスを推定する必要があります。

ステップ 13 — 購買力を確認します。

alpaca account get --jq '.buying_power'

エージェントは、注文の推定価値を利用可能な購買力と比較します。不足している場合は、続行する前に警告します。

ステップ 14 — オプション注文の場合は、承認レベルを確認します。

alpaca account get --jq '{options_approved_level, options_trading_level, options_buying_power}'

エージェントは options_trading_level を基準に判断します。これは実効レベルであり、options_approved_level と口座設定の max_options_trading_level のうち、低い方です。設定でそれより低い上限が定められている場合、承認されているだけでは取引は許可されません。

レベル	許可される取引
`0`	オプション取引は無効
`1`	カバードコール、キャッシュセキュアード・プット
`2`	ロングコールおよびロングプット（レベル 1 の取引に追加）
`3`	スプレッドおよびストラドル（レベル 2 の取引に追加）

スプレッドにはレベル 2 ではなく、レベル 3 が必要です。

ステップ 15 — 口座の概要を表示します。

エージェントは次の内容を提示します。

┌─────────────────────────────────────┐
│ Paper Account Summary               │
├─────────────────────────────────────┤
│ Endpoint:      paper-api (PAPER)    │
│ Profile:       my-paper             │
│ Status:        ACTIVE               │
│ Equity:        $50,000.00           │
│ Buying Power:  $100,000.00          │
│ Multiplier:    2 (Reg T margin)     │
│ Options Level: 2 (effective)        │
│ Crypto:        ACTIVE               │
└─────────────────────────────────────┘

フェーズ 4：注文プレビュー

Step 16 — CLI コマンドを組み立てますが、まだ実行しません。

エージェントがコマンド全体を組み立てて表示し、次に --dry-run で検証します。これにより、送信せずに CLI が送信するリクエスト本文が出力されます。

alpaca order submit \
  --symbol AAPL \
  --side buy \
  --qty 10 \
  --type limit \
  --limit-price 185.50 \
  --time-in-force day \
  --client-order-id a1b2c3d4-e5f6-7890-abcd-ef1234567890 \
  --dry-run

プレビューで表示するコマンドは、後で実行するコマンドと --dry-run を除いて完全に同一でなければなりません。

Step 17 — 書式付きの注文プレビューテーブルを表示します。

┌─────────────────────────────────────────────┐
│ ORDER PREVIEW — NOT YET SUBMITTED           │
├─────────────────────────────────────────────┤
│ Symbol:         AAPL                        │
│ Side:           BUY                         │
│ Quantity:       10 shares                   │
│ Order Type:     LIMIT                       │
│ Limit Price:    $185.50                     │
│ Time in Force:  DAY                         │
│ Extended Hours: No                          │
│ Est. Value:     $1,855.00                   │
│ Buying Power:   $100,000.00 → $98,145.00   │
│ Client ID:      a1b2c3d4-...               │
│ Endpoint:       paper-api (PAPER)           │
├─────────────────────────────────────────────┤
│ ⚠️  This is a PAPER trade — no real money   │
└─────────────────────────────────────────────┘

Step 18 — 確認が ON の場合：先へ進む前に、明示的な「yes」を待ちます。

Step 19 — 確認が OFF の場合：プレビューを表示してから、自動的に送信します。

フェーズ 5：注文の送信

Step 20 — CLI コマンドを実行します。

CLIENT_ORDER_ID="$(uuidgen)"

alpaca order submit \
  --symbol AAPL \
  --side buy \
  --qty 10 \
  --type limit \
  --limit-price 185.50 \
  --time-in-force day \
  --client-order-id "$CLIENT_ORDER_ID"

コマンドが応答を出力する前に異常終了しても注文を追跡できるよう、エージェントは送信前に CLIENT_ORDER_ID を取得します。

Step 21 — 生の CLI 出力を実行フォルダーに保存します。

# Output saved to runs/<timestamp>-paper-trading-cli/raw/order_submit_response.json

Step 22 — 応答を解析し、主要なフィールドを取得します。

id（注文 ID）
status（想定値：new または accepted）
created_at
filled_at（保留中の場合は null）
filled_qty
filled_avg_price

Step 23 — 失敗した場合：

stderr から構造化 JSON エラーと CLI の終了コードを取得します — 0 は成功、1 はエラー、2 は認証失敗です
解決方法を提示します（例：「買付余力不足」、「銘柄が見つかりません」、「市場が閉まっています」）
エラーを runs/<timestamp>/raw/error.json に保存します
修正方法を提案します

失敗が曖昧な場合 — タイムアウト、プロセスの強制終了、または注文が Alpaca に到達したかエージェントが判断できない状況 — 再送信してはなりません。Step 20 で生成したクライアント注文 ID で注文を検索します。

alpaca order get-by-client-id --client-order-id "$CLIENT_ORDER_ID"

検索結果があれば注文は存在しており、再送信すると重複します。再試行が正当化されるのは、注文が見つからないことを確認できた場合のみです。

フェーズ 6：送信後の監視

Step 24 — 注文状況を確認します。

alpaca order get --order-id {order_id}

エージェントは次の情報を報告します。

現在のステータス
約定の進捗（部分約定）
平均約定価格

Step 25 — 状況を把握するため、最近の注文を一覧表示します。

alpaca order list --status open

Step 26 — 注文の概要を返します。

┌─────────────────────────────────────────────┐
│ ORDER SUBMITTED ✓                           │
├─────────────────────────────────────────────┤
│ Order ID:      abc-123-def-456              │
│ Status:        NEW                          │
│ Symbol:        AAPL                         │
│ Side/Qty:      BUY 10                       │
│ Type:          LIMIT @ $185.50              │
│ Submitted:     2026-07-26T14:30:00Z         │
├─────────────────────────────────────────────┤
│ Next commands:                              │
│  alpaca order get --order-id abc-123      │
│  alpaca order cancel --order-id abc-123     │
│  alpaca position list                     │
└─────────────────────────────────────────────┘

Step 27 — 注文ライフサイクルの更新：

イベント	エージェントの対応
`filled`	約定価格を報告し、指値との差を計算して、ポジションへの影響を表示します
`partially_filled`	約定数量、残数量、平均価格を報告します
`rejected`	拒否理由を示し、修正方法を提案します
`canceled`	キャンセルを確認し、最終状態を表示します
`expired`	期限切れ（TIF の経過）を報告し、再エントリーを提案します
`replaced`	置換後のパラメーターを確認し、新しい注文 ID を表示します

フェーズ 7：ポートフォリオへの影響

Step 28 — ポジションを取得します。

alpaca position list

特定の銘柄を指定する場合：

alpaca position get --symbol-or-asset-id AAPL

Step 29 — 更新後の口座情報を取得します。

alpaca account get

Step 30 — ポートフォリオのリスク概要を表示します。

┌─────────────────────────────────────────────┐
│ PORTFOLIO IMPACT                            │
├─────────────────────────────────────────────┤
│ New Position:   AAPL — 10 shares @ $185.30  │
│ Position Value: $1,853.00                   │
│ Portfolio %:    0.74%                       │
│ Buying Power:   $98,147.00 (was $100,000)   │
│ Total Equity:   $250,000.00                 │
│ Open Orders:    1                           │
└─────────────────────────────────────────────┘

フェーズ 8：注文管理

Step 31 — 特定の注文をキャンセルします。

alpaca order cancel --order-id {order_id}

エージェントはキャンセルを確認し、注文の最終状態を報告します。

Step 32 — すべての未決済注文をキャンセルします。

cancel-all の対象範囲は口座全体です。このセッションで作成していない注文も含め、口座上のすべての未決済注文をキャンセルします。CLI は独自の確認プロンプトを表示せずに直ちに実行するため、エージェントが確認のゲートを設けます。まず、キャンセルされる注文を正確に表示します。

alpaca order list --status open --jq '[.[] | {id, symbol, side, qty, type, limit_price}]'

エージェントは対象の注文を一覧表示し、件数を伝え、明示的な「yes」を求めます。confirmation_mode が OFF の場合も同様です。この設定が対象とするのは注文の発注であり、一括キャンセルではないためです。その後に限り、次を実行します。

alpaca order cancel-all

エージェントはキャンセルした注文の合計数を確認し、対象となった注文を一覧表示します。同じ確認ゲートは、ポートフォリオ全体を清算する alpaca position close-all にも適用されます。

Step 33 — 注文を置換します（価格／数量を変更）。

まず利用可能なフラグを確認します。

alpaca order replace --help

次に実行します。

alpaca order replace --order-id {order_id} --qty 5 --limit-price 186.00

エージェントは新しい注文 ID と更新後のパラメーターを報告します。

フェーズ 9：デプロイのガイダンス（要望に応じて）

自動化について尋ねると、エージェントは次のようなガイダンスを提供します。

Bash スクリプトラッパー。 無人での注文送信は、注文する前にペーパー用エンドポイントであることを確認するラッパーを経由します。スケジュールされた処理から alpaca order submit が直接呼び出されることはないため、どのスケジューラーから起動されてもガードを回避できません。

#!/bin/bash
# /usr/local/bin/paper-trade.sh
set -euo pipefail

SYMBOL="${1:?usage: $0 SYMBOL SIDE QTY}"
SIDE="${2:?usage: $0 SYMBOL SIDE QTY}"
QTY="${3:?usage: $0 SYMBOL SIDE QTY}"

# Verify the CLI resolves to the paper endpoint
if ! alpaca doctor | grep -q 'Trading:.*https://paper-api\.alpaca\.markets'; then
  echo "ERROR: CLI is not pointed at the paper endpoint. Exiting." >&2
  exit 1
fi

alpaca order submit \
  --symbol "$SYMBOL" \
  --side "$SIDE" \
  --qty "$QTY" \
  --type market \
  --time-in-force day \
  --client-order-id "$(uuidgen)"

Cron ジョブ。 Cron は生の CLI ではなく、ラッパーを呼び出します。

# /etc/cron.d/paper-trade
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
ALPACA_PROFILE=paper
0 9 * * 1-5 root /usr/local/bin/paper-trade.sh AAPL buy 1 >> /var/log/paper-trades.log 2>&1

Cron はほぼ空の環境で実行され、シェルプロファイルも読み込まないため、PATH、ALPACA_PROFILE、認証情報を明示的に設定する必要があります。上記のように crontab で設定するか、ジョブのユーザーだけが読み取れるファイルをラッパー内で読み込んでください。何も引き継がないスケジュール済みジョブで、ガードのない注文送信を実行するのは最も危険なケースです。監視するオペレーターも確認プロンプトもないため、エンドポイントのチェックはスケジュールではなくスクリプト内に置く必要があります。

systemd タイマー／launchd plist： エージェントは、同じラッパーを指定する、お使いの OS に適したサービスファイルを生成します。

CI/CD パイプライン。 CLI をインストールし、ランナーのシークレットストアから認証して、同じラッパーを呼び出します。alpaca order submit を単独のステップとして実行してはいけません。

- name: Submit paper order
  env:
    ALPACA_API_KEY: ${{ secrets.ALPACA_PAPER_API_KEY }}
    ALPACA_SECRET_KEY: ${{ secrets.ALPACA_PAPER_SECRET_KEY }}
    ALPACA_PROFILE: paper
  run: ./scripts/paper-trade.sh AAPL buy 1

CI は誤ってライブ環境を使い始めるのが最も簡単な場所です。ランナーにはお使いのプロファイルがなく、キーは誰かが設定したシークレットから取得され、ペーパー用という名前のシークレットにライブキーが入っていても、呼び出し箇所では正しいキーと見分けがつきません。シークレットに PAPER という名前を付けても何の証明にもなりません。そのため、エンドポイントを確認するのは変数名ではなく、ラッパーの alpaca doctor チェックです。

自動化に関する重要事項：

CLI は確認を求めることはありません。自動化でも対話操作でも、「本当によろしいですか？」というダイアログは表示されません。そのため、このスキルにおける確認ゲートを担うのは CLI ではなくエージェントです。
--quiet は警告、ヒント、色を抑制します。出力を機械可読にするためのオプションではありません。JSON は、これを指定するかどうかにかかわらずデフォルトです。ログをすっきり保つため、cron や CI で使用してください。
ALPACA_OUTPUT=json|csv を設定すると、スクリプト全体のデフォルト出力形式を指定できます。
無人で実行されるすべての経路（cron、systemd、launchd、CI）では、ガード付きラッパーを経由して注文を送信します。スケジューラーやパイプラインから alpaca order submit が直接呼び出されることはないため、新しいトリガーを追加してもエンドポイントチェックを省略できません。
監査証跡として、すべての出力を記録してください。
再試行時の冪等性を確保するため、--client-order-id を使用してください。

5 - 実行ルール

一般ルール

ペーパーのみ。 ライブエンドポイントに対して注文を送信してはいけません。送信する前に、解決されたエンドポイントを必ず確認してください。
送信前に確認。 デフォルトでは明示的な確認が有効です。ユーザーの希望に従ってください。
意図を維持。 明示的な同意なしに注文パラメーターを変更してはいけません。
アトミックな操作。 各注文の送信は独立しています。失敗がほかの注文に影響することはありません。
完全な透明性。 実行の前後に、CLI コマンドをすべて表示してください。
冪等性。 再試行時の重複送信を防ぐため、常に --client-order-id を生成してください。
金融アドバイスの禁止。 エージェントはユーザーの指示を実行します。取引を推奨することはありません。

CLI 固有のルール

どのコマンドにも -p／--profile を指定しないでください。 alpaca doctor はこれを無視するため、ペーパー取引の確認と注文で異なるプロファイルが解決される可能性があります。代わりに、セッションで ALPACA_PROFILE を使用してください。
デフォルトの JSON 出力を解析してください。 すべてのコマンドは、すでに構造化された JSON を返します。絞り込みには --jq '<expr>' を使用し、人が読むテーブルに限り --csv を使用してください。--quiet は警告、ヒント、色を抑制しますが、データ形式は変更しません。
外部の jq へのパイプは使用しないでください。 組み込みの --jq フラグで、依存関係を 1 つ減らしながら同じ処理ができます。
構文を想定する前に、--help、--help-all、--schema で必ずフラグを確認してください。 CLI はアルファプレビュー段階のため、バージョンによって変更される可能性があります。
CLI の生出力はすべて実行フォルダーに保存してください。 各コマンドの stdout と stderr は raw/ に保存します。
alpaca doctor が失敗した場合は、続行しないでください。 失敗を報告して停止してください。
概要ではプロファイルの詳細とトークンを伏せてください。 出力ファイルで API キーやシークレットを公開しないでください。
CLI の終了コードを処理してください。 0 は成功、1 はエラー、2 は認証失敗です。stderr を取得して提示してください。
レート制限に対する独自の再試行ループを追加しないでください。 CLI はすでに 429 および 5xx の応答を最大 3 回再試行し、Retry-After に従います。その上にさらにバックオフ処理を重ねると、レート制限された 1 回の呼び出しが大幅な遅延につながります。CLI の再試行後もコマンドが失敗する場合は、エラーを提示して停止してください。
送信前に --dry-run でプレビューしてください。 注文を送信せずに、正確なリクエスト本文を表示します。
対象を限定しない破壊的なコマンドは制御してください。 order cancel-all と position close-all はアカウント全体に影響します。confirmation_mode にかかわらず、明示的な確認を求めてください。

6 - 出力仕様

すべてのペーパー取引セッションで、次の実行フォルダーが生成されます。

runs/<YYYYMMDD-HHMMSS>-paper-trading-cli/
  notes.md                        # Session narrative: strategy, decisions, outcomes
  raw/                            # Saved raw CLI outputs
    account.json                  # Account state at session start
    order_submit_response.json    # Raw submission response
    order_status.json             # Order status checks
    positions.json                # Position state after fills
    clock.json                    # Market clock at submission time
    error.json                    # Error output (if any)
  orders.json                     # Structured order records
  order_log.csv                   # Tabular log: timestamp, action, order_id, status, details
  positions_snapshot.json         # Position state post-trade
  portfolio_summary.md            # Human-readable portfolio impact
  review.md                       # Session review: what worked, issues, next steps

notes.md の構成

# Paper Trading Session — <timestamp>

## Signal Source
<origin of trade idea>

## Strategy
<strategy logic as confirmed>

## Orders Submitted
| # | Symbol | Side | Qty | Type | Status | Fill Price |
|---|--------|------|-----|------|--------|-----------|

## Portfolio Impact
<post-trade portfolio state>

## Issues / Notes
<any errors, warnings, or observations>

order_log.csv の列

timestamp,action,order_id,symbol,side,qty,type,limit_price,stop_price,tif,status,fill_price,fill_qty,error

7 - 検証とテスト

エージェントは実行中に次のチェックを行います。

送信前の検証

チェック	コマンド	合格条件
CLI がインストール済み	`alpaca version`	終了コードが 0
接続	`alpaca doctor`	すべてのチェックに合格
ペーパー取引エンドポイント	`alpaca doctor`	`Trading:` の行に `https://paper-api.alpaca.markets` と表示される
アカウントが有効	`alpaca account get`	status=ACTIVE で、ブロックされていない
購買余力	`alpaca account get --jq '.buying_power'`	注文に十分
市場が開いている	`alpaca clock`	`is_open=true`（時間外取引または GTC の場合を除く）
シンボルが有効で取引可能	`alpaca asset get --symbol-or-asset-id X`	`status=active`、`tradable=true`

送信後の検証

チェック	コマンド	合格条件
注文が受け付けられた	`alpaca order get --order-id X`	ステータスが rejected ではない
約定を受信した	同上	filled_qty > 0
ポジションが更新された	`alpaca position get --symbol-or-asset-id X`	新しいポジションが反映されている

8 - 開示、安全性、データの取り扱い

開示事項

ペーパートレードのみ。 このスキルは Alpaca のペーパートレード環境でのみ動作します。実際の資金が危険にさらされることはありません。
金融アドバイスではありません。 エージェントはお客様の指示を実行します。投資に関する推奨、市場予測、取引アドバイスは提供しません。
ペーパー取引 ≠ ライブ取引。 約定シミュレーションが簡略化されているため、ペーパー取引の約定はライブ取引と異なる場合があります。ペーパー取引の結果がライブ取引のパフォーマンスを予測すると想定しないでください。
お客様の責任です。 ペーパー取引で選択する戦略については、お客様が責任を負います。エージェントはツールであり、アドバイザーではありません。
開示事項の全文。 alpaca.markets/disclosures で Alpaca の開示事項と契約をご確認ください。

重要な開示事項： この資料は、情報提供、教育、調査のみを目的としています。投資アドバイス、有価証券、オプション、暗号資産、その他の金融商品の売買に関する推奨、申し出、勧誘ではありません。すべての投資と取引には、元本を失う可能性を含むリスクがあります。ペーパートレードはシミュレーションであり、約定、市場への影響、流動性、手数料、レイテンシー、その他の要因においてライブ取引と異なる場合があります。https://alpaca.markets/disclosures で Alpaca の開示事項をご確認ください。

安全制御

制御	実装
ライブ取引の防止	送信前に毎回、解決済みエンドポイントを確認
確認ゲート	デフォルトで ON — 明示的な承認が必要
購買余力の確認	送信前の検証
接続の検証	セッション開始時に `alpaca doctor` を実行
エラーの分離	失敗をログに記録し、連鎖させない
冪等性	`--client-order-id` で重複を防止

データの取り扱い

ローカルのみ。 すべての実行データは runs/ の下にあるローカルワークスペースに保存されます。
テレメトリなし。 エージェントが取引データを送信する外部サービスは、Alpaca API のみです。
認証情報の保護。 API キーがログに記録、表示、ファイルに書き込まれることはありません。共有出力ではプロファイル名が伏せられます。
監査証跡。 すべての CLI コマンドと応答が raw/ に保存され、確認できます。

9 - アンチパターン

エージェントは以下を絶対に行ってはいけません。

アンチパターン	理由	正しい方法
本番エンドポイントに注文を送信する	実際の資金が危険にさらされます	まず `alpaca doctor` がペーパーエンドポイントを報告することを必ず確認します
モードが ON のときに確認を省略する	制御できなくなります	必ず確認設定に従います
注文パラメーターを黙って変更する	意図に反します	パラメーターを変更する場合は必ず再確認します
取引の助言をする	責任問題につながり、エージェントの役割ではありません	指示を実行し、推奨はしません
CLI フラグをハードコードする	アルファプレビューのため、バージョン間でフラグが変更される可能性があります	`--help`、`--help-all`、`--schema` で確認します
出力を外部の `jq` にパイプする	CLI にすでにある機能に依存関係が追加されます	組み込みの `--jq` フラグを使います
`--quiet` を JSON 切り替えオプションとして扱う	JSON がデフォルトです。`--quiet` は警告、ヒント、色を抑制するだけです	デフォルトの出力を直接解析します
`pattern_day_trader` または `daytrade_count` を読み取る	Trading API のアカウントオブジェクトに、どちらのフィールドも存在しません	`multiplier` = `4` から PDT を推定します
429 エラー用の再試行ループを追加する	CLI はすでに 3 回再試行し、`Retry-After` に従います	再試行に失敗した後、エラーを通知します
指示を求めずに `cancel-all` または `close-all` を実行する	対象範囲が限定されず、このセッションで作成されていない注文やポジションにも影響します	影響を受ける項目を一覧表示し、明示的な確認を求めます
Alpaca CLI を迂回して直接 HTTP 呼び出しを行う	これは CLI 版です	`alpaca` コマンドのみを使用します
CLI の終了コードを無視する	エラーを見落とします	終了コードを確認し、stderr を取得します
`alpaca doctor` が失敗した後も続行する	接続を確認できていません	停止して失敗を報告します
API キーを実行フォルダーに保存する	セキュリティリスクがあります	すべての認証情報を伏せます
市場の取引時間を決めつける	延長取引の場合や、暗号資産のように 24 時間 365 日取引できる場合があります	`alpaca clock` を確認します
購買余力を確認せずに注文を送信する	注文が拒否されます	まず購買余力を検証します
プログラムによる解析に `--csv` 出力を使う	JSON より構造化されていません	デフォルトの JSON を `--jq` でフィルタリングして解析します

10 - 関連ファイル

ファイル	目的
`reference.md`	詳細なリファレンス：注文タイプ、TIF、ライフサイクル、資産クラス、エラー

基本情報

作者: alpacahq
リポジトリ: alpacahq/alpaca-skills
カテゴリ: その他
インストール数: 101
GitHub スター: 157

問題を報告

スキル	説明
`alpaca-trading-backtest`	Alpaca CLI による過去データのバックテスト — このスキルで実行できるシグナルを生成します
`alpaca-trading-paper-trading`	実装に依存しない汎用のペーパートレード用スキル
`alpaca-trading-paper-trading-mcp`	このスキルの MCP サーバー版