よくある質問

Q: 数量とロットの違いは何ですか？

A: このサーバーはロットではなく単位（units）での数量を使用します。

各銘柄のロットサイズ（1 標準ロットあたりの単位数）は、get_symbols ツールで取得できます。銘柄名を指定して get_symbols を呼び出し、ロットサイズを確認してください。

変換方法: 銘柄カタログから 数量 = 希望ロット数 × lotSize。

注文を発注する前に、必ず get_symbols を呼び出して実際のロットサイズを確認してください。

Q: 銘柄の FIX Symbol ID を見つけるにはどうすればよいですか？

A: 最も簡単な方法は、ctrader://symbols リソースを読むか get_symbols を呼び出すことです。 ID、ロットサイズ、桁数、資産クラスを含む完全な銘柄カタログが返されます。

または、cTrader で:

Active Symbol Panel（アクティブ銘柄パネル）を開きます
Symbol info ドロップダウンをクリックします
一番下にある FIX symbol ID を確認します

Symbol ID はブローカー固有です。EURUSD はあるブローカーでは ID 1、別のブローカーでは ID 100 の場合があります。必ずご自身のブローカーで確認してください。

参考: https://help.ctrader.com/fix/getting-credentials/

Q: ペーパーモードとライブモードの違いは何ですか？

観点	ペーパー	ライブ
リスクチェック	全 8 件実行	全 8 件実行
ジャーナルログ	あり	あり
ブローカーへの注文送信	なし	あり
実執行	なし	あり
実資金のリスク	なし	あり

ペーパーモードはテスト用です。注文は検証およびログ記録されますが、ブローカーには送信されません。ライブモードは実際の金銭的影響を伴う実注文を送信します。

Q: ペーパーモードからライブモードに切り替えるにはどうすればよいですか？

A: 運用モードは接続時に OAuth 認証情報フォームで設定されます。変更するには:

MCP コネクタを切断します（Claude Desktop: Settings → MCP Servers → 削除/切断、claude.ai: インテグレーションを切断）
再認可 — 再接続して再度 OAuth フォームを通過します
Trading Mode を paper から live に変更します
“Connect” をクリックします

異なる設定（モード、リスク制限など）で再認可すると、サーバーは自動的に古いセッションを無効化し、新しいセッションを作成します。同じ設定で再接続した場合、既存のセッションが再利用されます。

再接続後、check_health を呼び出して mode: "live" を確認してください。

重要: ライブモードでは、すべての注文が実資金で執行されます。まずペーパーモードで十分にテストしてください。

Q: キルスイッチはどのように機能しますか？

A: キルスイッチがアクティブになると、すべての取引をブロックします。

自動トリガー:

当日の確定損失がデイリーロス制限を超過
状態リコンサイリエーションで不整合を検出（サーキットブレーカー）

解除:

デイリーロストリガーは 17:00 EST に自動リセットされます

Q: 取引したい銘柄が利用できません。どうすればよいですか？

A: 利用可能な銘柄はサーバー管理者が管理しています。get_symbols を使用して、現在設定されているものを確認してください。必要な銘柄がない場合は、サーバー管理者に連絡して追加してもらってください。管理者がブローカーの銘柄カタログから銘柄をインポートできます。

Q: FIX 接続が切断されたらどうなりますか？

A: サーバーは 2 つのメカニズムで切断を処理します:

自動再接続（指数バックオフで最大 10 回試行）:

接続喪失を検出（ハートビートタイムアウトまたは TCP エラー）
状態が DISCONNECTED に遷移
自動再接続試行が開始されます（5 秒、10 秒、20 秒… 最大 60 秒）
再接続時: Logon → リコンサイリエーション → Active
リコンサイリエーション中はトレーディングがブロックされます（RECONCILING エラー）
ACTIVE になると、トレーディングは通常通り再開します

手動再接続（自動再接続を諦めた後）: 10 回の自動再接続試行がすべて失敗した場合は、reconnect_trade_session または reconnect_quote_session を使用して、新規接続を強制してください。週末明けで市場がクローズしていた場合によく見られます。

check_health は現在のセッション状態と最後の切断理由を表示します。

ポジションと当日 PnL はディスクに永続化されるため、再起動後も保持されます。

Q: 週末またはネットワーク障害の後に再接続するにはどうすればよいですか？

A: check_health を呼び出して現在のセッション状態を確認します。fixState が “ACTIVE” でない場合:

reconnect_trade_session を呼び出します — 古い接続を破棄し、新しい接続を開き、ブローカーからポジション/注文をリコンサイルします
ライブクォートも必要な場合は reconnect_quote_session を呼び出します — 再接続し、すべての銘柄購読を復元します

両方のツールはべき等です — セッションがすでにアクティブな場合は “already connected” を返します。

Q: デイリー PnL はいつリセットされますか？

A: 17:00 EST（東部標準時）で、これは標準的な FX 市場のロールオーバー時刻です。これは設定変更できません。キルスイッチのデイリーロストリガーもこの時刻にリセットされます。

Q: PnL はどの通貨で報告されますか？

A: すべての PnL 値（realizedPnL、unrealizedPnL）は、商品のクォート通貨にかかわらず USD で報告されます。たとえば USDJPY トレードの PnL は、ライブミッドプライスを使用して JPY から USD に変換されます。

各レスポンスには透明性のために、USD 値と生のクォート通貨値の両方が含まれます:

realizedPnL — USD（主要、意思決定に使用）
realizedPnLRaw — クォート通貨での元の値
quoteCurrency — 商品のクォート通貨（例: “JPY”）
conversionRate — 使用されたレート: rawPnL × conversionRate = usdPnL
pnlCurrency — 変換された場合は “USD”、変換不可だった場合はクォート通貨コード

QUOTE セッションがダウンしているか、変換ペアが利用できない場合、PnL は生のクォート通貨値にフォールバックし、pnlCurrency は実際の通貨（“USD” ではなく “JPY” など）を示します。

Q: QUOTE セッションはどのように機能しますか？

A: サーバーは 2 つの別々の FIX 接続をサポートしています:

TRADE セッション: 注文、ポジション、トレード確認
QUOTE セッション: リアルタイムのビッド/アスク市場データ

QUOTE セッションはデフォルトで有効です。ブローカーの Price ゲートウェイ（通常は同じホスト、異なるポート）に接続し、設定された銘柄の市場データを購読します。

get_quote は QUOTE セッションから単一銘柄のライブビッド/アスク価格を返します。複数銘柄の価格を 1 回の呼び出しで取得するには、get_quotes（複数形）を使用します（最大 50 件）。 QUOTE セッションが無効または切断されている場合、両ツールはトレード履歴の最終約定価格にフォールバックします。

QUOTE セッションのステータスを確認するには: ctrader://health リソースを読み、 quoteSession オブジェクトを確認してください。

Q: サーバーが正常か確認するにはどうすればよいですか？

A: check_health ツールを呼び出すか、ctrader://health リソースを読みます。どちらも同じデータを返します:

全体ステータス: HEALTHY / DEGRADED / UNHEALTHY
TRADE セッション FIX 接続状態
QUOTE セッション状態（有効時）: 接続、購読、キャッシュサイズ
ポジションおよび注文数
デイリー PnL とリスク制限使用率
キルスイッチステータス

check_health ツールは AI エージェントが能動的に呼び出せるため推奨されます。

Q: ClOrdID とは何ですか？

A: クライアント注文 ID（ClOrdID）は、各注文に対してサーバーが自動生成する一意の識別子です。注文レスポンスの clOrdId フィールドに返され、注文を追跡および参照するために使用されます（modify_order、cancel_order で使用）。ご自身で作成する必要はありません。

Q: 市場がクローズしているため MARKET 注文が拒否されました。何ができますか？

A: MARKET 注文は即時執行のためにアクティブな取引セッションを必要とします。市場がクローズしている場合（週末、祝日、取引時間外）、拒否されます。

代わりに保留中注文を使用してください:

LIMIT — 特定価格で買い/売りを発注し、市場が開いて価格が一致したときに執行
STOP — 市場が開いた後にストップ水準に達したときにトリガー
注意: STOP_LIMIT は cTrader ブローカーでサポートされていません

timeInForce: "GTC" を設定すると、保留中の注文は市場が再開して約定するまで（または手動でキャンセルするまで）持続します。

例: 市場が再開したときに EURUSD を 1.0800 で買う:

{
  "symbol": "EURUSD",
  "side": "BUY",
  "volume": 100000,
  "orderType": "LIMIT",
  "price": 1.0800,
  "timeInForce": "GTC"
}

Q: ポジションが古く見える / 最近のトレードが反映されていません。どうすればよいですか？

A: ポジションデータはローカル状態にキャッシュされ、このサーバーを通じて発注されたトレードによってのみ更新されます。 cTrader で直接、別のツールで、または別の Claude チャットで行われたトレードは、自動的には反映されません。

ブローカーから最新の同期を強制するには、refresh: true を指定して get_positions を呼び出してください:

{ "refresh": true }

これはブローカーから新鮮なポジションデータを取得し、返す前に現在のポジションスナップショットを待ちます。MCP サーバーセッションの外部で取引プラットフォームとやり取りした場合は、いつでもこれを使用してください。

Q: ポジションに SL/TP を設定するにはどうすればよいですか？

A: 3 ステップのリンク注文ワークフローを使用します:

ポジションをオープン: MARKET 注文を発注 → レスポンスに positionId が含まれます
ストップロスを設定: ステップ 1 で得た positionId で STOP 注文を発注（反対サイド、SL 価格で）
テイクプロフィットを設定: 同じ positionId で LIMIT 注文を発注（反対サイド、TP 価格で）

positionId パラメーターは保留中の注文をポジションにリンクするため、STOP または LIMIT がトリガーされたときに、新しいポジションを開く代わりにポジションをクローズします。

例（EURUSD を BUY、SL 1.0750、TP 1.0950）:

1. place_order: BUY MARKET EURUSD 100000 → positionId: "12345"
2. place_order: SELL STOP EURUSD 100000, stopPrice: 1.0750, positionId: "12345"
3. place_order: SELL LIMIT EURUSD 100000, price: 1.0950, positionId: "12345"

OCO: ポジションがクローズしたとき（SL/TP 約定または close_position）、サーバーは残りのリンクされたすべての保留中注文を自動的にキャンセルします — 手動クリーンアップは不要です。

Q: このサーバーが使用する FIX のバージョンは何ですか？

A: cTrader がサポートする FIX 4.4 です。

Q: サーバーは AI エージェントが計算に注意するようにどう保証していますか？

A: サーバーは、エージェントの動作を導くために複数の MCP プロトコルメカニズムを使用しています:

サーバーの instructions: MCP 初期化時に AI エージェントに送信されます（システムプロンプトに追加）。必須ルールを含みます: 数量計算をステップバイステップで表示、銘柄カタログから LOT_SIZE を確認、ゼロの位置をクロスチェック、トレード前にユーザーから明示的な確認を取得。
ツールの annotations: トレーディングツール（place_order、modify_order、close_position、cancel_order）は destructiveHint: true および idempotentHint: false でマークされています。MCP クライアントはこれらのヒントを使用して、執行前に明示的なユーザー確認を要求できます。
ツールの説明: 各トレーディングツールには、呼び出し前に数量を計算および検証することをエージェントに思い出させる “CALCULATION SAFETY” セクションが含まれています。
トレード前チェックリストプロンプト: pre-trade-checklist プロンプトには、LOT_SIZE、数量計算式、小数点クロスチェックのためのステップバイステップのチェックを含む “Calculation Verification” セクションがあります。
サーバーサイド検証: 入力スキーマは有効な数量、正の価格、銘柄パターンを強制します。リスクガードは最大数量およびポジションサイズ制限を含む 11 件の自動チェックを追加します。

重要: これらのメカニズムは AI を導きますが、正確性を保証することはできません。特にライブモードでは、トレードを確認する前に常にエージェントの計算をレビューしてください。

Q: ツールアノテーションとは何で、MCP クライアントはどう使うのですか？

A: ツールアノテーションは、MCP プロトコル仕様で定義されたメタデータヒントです:

アノテーション	意味	トレーディングツール	読み取り専用ツール
`readOnlyHint`	ツールは状態を変更しない	`false`	`true`
`destructiveHint`	ツールは不可逆的な変更を引き起こす可能性がある	`true`	`false`
`idempotentHint`	繰り返し呼び出しても追加効果はない	`false`	`true`
`openWorldHint`	ツールは外部システムと相互作用する	`true`	場合による

MCP クライアント（Claude Desktop、Cursor など）はこれらを以下のために使用できます:

破壊的操作の前にユーザー確認を要求
読み取り専用ツール呼び出しを自動承認
非べき等ツールが繰り返し呼び出された場合に警告

Q: 過去のトレードを確認するにはどうすればよいですか？

A: get_trade_history を呼び出すと、最近クローズされたポジションを損益、決済理由、継続時間、およびオプションで集計統計（勝率、プロフィットファクター）と共に確認できます。

{ "limit": 10, "includeStats": true }

トレード履歴はメモリに保持されます（セッションごとに最大 200 件）。セッションが終了するとリセットされます。

Q: get_positions で unrealizedPnL が常に 0 なのはなぜですか？

A: cTrader は建玉ポジションの P&L データを直接提供しません。これは FIX プロトコルの既知の制限です。

サーバーは QUOTE セッションがアクティブで、銘柄のクォートがプライスキャッシュにある場合、ライブビッド/アスク価格から評価損益を自動的に計算します。

修正方法: get_positions を呼ぶ前にプライスキャッシュをウォームアップしてください:

get_positions → オープン中の銘柄を発見
get_quotes ["EURUSD", "XAUUSD", ...] → すべての銘柄のプライスキャッシュを 1 回の呼び出しでウォームアップ
再度 get_positions → unrealizedPnL がライブ価格から計算される

（個別に銘柄ごとに get_quote を呼ぶこともできますが、複数銘柄には get_quotes の方が高速です。）

レスポンスの各ポジションには priceSource フィールドが含まれます:

"live_quote" → P&L は正確（ビッド/アスクから計算）
"unavailable" → ライブ価格なし、先に get_quote を呼んでください

Q: マルチテナント HTTP モードはどのように機能しますか？

A: サーバーは複数のユーザーをサポートし、それぞれが独立したセッションを持ちます。認証は OAuth で処理されます — 各ユーザーがブラウザフォームに認証情報を入力し、サーバーが暗号化して安全に保存します。プログラム的クライアントには、ヘッダーベース認証もサポートされています。

各セッションは専用の FIX 接続、トレーディング状態、リスクガード、ジャーナルを取得します。セッションは分離されています — あるトレーダーのポジションおよびリスク制限は、他のトレーダーに影響しません。

Q: トレード中に HTTP セッションが切断されたらどうなりますか？

A: ブローカーへの FIX 接続は、最後の MCP リクエストから 30 分間オープンのまま保持されます（アイドルタイムアウト）。その期間内に同じ認証情報で再接続すると、同じ FIX セッション、同じ状態、同じポジションを取得します。

30 分後、セッションはクリーンアップされ、再接続時には新規の FIX ログオンが必要になります。新規ログオン中にサーバーはブローカーからポジションをリコンサイルするため、トレードデータは失われません。

Q: FIX 認証情報はサーバーに保存されますか？

A: OAuth を使用する場合（デフォルト）、認証情報は暗号化されて安全に保存されます。 FIX 接続を開く必要があるときにのみ復号され、平文で保存されることはありません。

ルーティングおよびロギングには一方向のセッション識別子が使用されます — 生の認証情報はログ、ジャーナル、メトリクスに出現することはありません。

ヘッダーベース認証では、認証情報はリクエストごとに渡され、まったく保存されません。

Q: 複数のブローカーで同時に使用できますか？

A: はい — 各 OAuth コネクタセッションは専用の FIX 接続を取得します。異なるブローカーを使用する複数のトレーダーが同じサーバーインスタンスに同時に接続できます。各コネクタセッションは、独自のポジション、リスク制限、ジャーナルで完全に分離されています。

Q: スクリプティングやアルゴリズム取引に使用できますか？

A: この MCP サーバーは、Claude Desktop または claude.ai を介したインタラクティブな AI 支援トレーディング向けに設計されています。スクリプティング、アルゴ取引、プログラム的統合には、代わりに axiory:connect Claude Code プラグインを使用してください — 自動ワークフロー向けに最適化された同じ FIX 接続性を提供します。

Q: ゲストモードとは何ですか？

A: 認証情報なしで接続した場合（OAuth フロー完了前）、サーバーはゲスト MCP セッションを作成します。

ゲストセッションでは以下が公開されます:

2 つのツール: get_symbols および get_knowledge（読み取り専用、FIX 依存なし）
12 のリソース: ナレッジベースおよび銘柄は通常通り動作。状態リソース（positions、orders、health）は、セットアップ手順を含む “not_connected” メッセージを返します
3 つのプロンプト: すべてのプロンプトが動作します。特に setup-guide は認証情報の設定をガイドします

これにより、AI エージェントは認証情報を提供する前にサーバーの機能を発見し、接続方法を学習できます。完全なトレーディングセッションにアップグレードするには、OAuth フローを完了してください。

Q: サーバーに接続するにはどうすればよいですか？

A: 2 つの方法で接続できます:

OAuth（推奨）: サーバー URL (https://mcp.axiory.ai/mcp) を MCP クライアントに追加します。クライアントは認証情報入力のためにブラウザを開きます。トークンは自動更新されます — 手動ローテーションは不要です。Claude Desktop、claude.ai、Cursor、Windsurf、Cline、およびほとんどの MCP クライアントで動作します。

ポータルトークン（フォールバック）: クライアントが OAuth フローを完了できない場合、ブラウザで https://mcp.axiory.ai/token-portal にアクセスし、FIX 認証情報を入力し、生成されたトークンをコピーします。これをクライアント設定に Bearer トークンとして貼り付けてください。ポータルトークンは 30 日間有効です。

クライアントごとの詳細なセットアップ手順（Cursor、Manus、Windsurf など）は、getting-started ナレッジトピックをお読みください。

Q: OAuth セッションはどのくらい持続しますか？

A: アクセストークンは 1 時間で期限切れになります。リフレッシュトークンは 7 日間有効です。

Claude Desktop はリフレッシュトークンを使用してアクセストークンを自動更新するため、認証情報を再入力することなく最大 7 日間接続を維持できます。7 日後にはブラウザフォームで再認可する必要があります。

Q: OAuth アクセスを取り消すことはできますか？

A: はい。クライアント（Claude Desktop または claude.ai）から MCP コネクタを切断し、再接続してください。再認可すると、サーバーは自動的に古いトークンを取り消し、新しいセッションを作成します。

アクセストークンは 1 時間後、リフレッシュトークンは 7 日後に期限切れになります。セキュリティ上の理由で即時取り消しが必要な場合、同じまたは異なる認証情報で再接続することで、古いセッションの自動無効化がトリガーされます。

Q: FIX パスワードを変更した場合はどうなりますか？

A: FIX パスワードを変更した後:

クライアントから MCP コネクタを切断します
再接続 — OAuth フローがブラウザを再度開きます
新しい FIX 認証情報を入力します

サーバーは認証情報が変更されたことを検出し、古いセッションを自動的に無効化します。

Q: セッション中にコネクタ設定（モード、リスク制限、サーバー、アカウント）を変更するにはどうすればよいですか？

A: reset_session ツールを使用します。これは現在のセッションを無効化し、再認証をトリガーします。そこで、トレーディングモード、リスク制限、FIX サーバー、アカウントなど、すべてのパラメーターを再設定できます。

リセット時に発生すること:

アカウントのすべてのアクティブセッション（他の接続済みクライアントを含む）が即座に終了
アクティブなクォート購読がドロップ
メモリ内のトレード履歴とセッション状態がクリア
他のセッションの実行中のツール呼び出しが中断される可能性

影響を受けない内容:

ブローカー側の建玉ポジション
ブローカー側の保留中注文
ディスク上のジャーナルエントリ

エッジケース: リセットウィンドウ中にポジションがクローズした場合、リンクされた OCO 注文（ストップロス/テイクプロフィット）は自動キャンセルされない可能性があります — 再接続後に手動で確認・キャンセルしてください。

リセット後、任意のツール（例: check_health）を呼び出してください — これにより自動的に再認証がトリガーされ、ブラウザに設定ページが開きます。

reset_session は HTTP マルチテナントモード（OAuth が有効なデプロイメント）でのみ利用可能です。

Q: セッションごとにカスタムリスク制限を設定できますか？

A: はい。OAuth（ブラウザフォーム）経由で接続するときに、“Risk Limits” セクションを展開してリスクガードレールをカスタマイズできます:

Max Position Size（資産クラスごと） — FX、Indices、Crypto、Commodities、Stocks の別個の制限
Max Open Positions — 同時にオープンできるポジション数（デフォルト: 20）
Daily Loss Limit — その日のキルスイッチをトリガーする確定損失閾値
Max Orders per Minute — 注文送信レートを制限

ルール:

すべてのフィールドはオプション — 空のままにすると合理的なデフォルトが使用されます。
各フィールドには誤設定を防ぐための最大許容値があります。
セッション中に制限を変更するには、切断して再認可する必要があります（制限は接続時に設定されます）。
異なる設定で再認可すると、古いセッションは自動的に無効化されます。

接続後、check_health を呼び出します — riskLimits.configured セクションに有効な制限が表示されます。

Q: バグを報告したり機能をリクエストしたりするにはどうすればよいですか？

A: submit_feedback ツールを使用してください。バグの場合は、まず check_health を呼び出して、出力を environment フィールドに含めてください。ツールはフィードバック ID を返します — get_feedback_status を使用して更新を確認してください。

ベストプラクティス、レート制限、フィードバックの処理方法の詳細については、feedback ナレッジトピックをお読みください: get_knowledge({ topic: "feedback" })。

Q: FIX ホストが拒否されたのはなぜですか？

A: サーバーは明示的に設定されたブローカーサーバーへの接続のみを許可します。OAuth フォームのドロップダウンにホストがない場合、まだ設定されていません。サーバー管理者に連絡してブローカーサーバーを追加してもらってください。

各サーバーは独自の銘柄カタログを必要とします（ID はブローカー環境ごとに異なります）。新しいサーバーを追加することは設定変更です — サーバー管理者に連絡してください。

Q: クライアントで OAuth が動作しない場合はどうすればよいですか？

A: フォールバックとして Token Portal を使用してください:

ブラウザでトークンポータル URL にアクセスします
FIX 認証情報を入力します（OAuth と同じフォーム）
“Generate Token” をクリックして 30 日間有効な Bearer トークンを受け取ります
トークンをコピーしてクライアント設定に追加します

このトークンは、カスタム HTTP ヘッダーをサポートする任意の MCP クライアントで動作します。環境変数に保存してください（例: AXIORY_TOKEN） — トークンを設定ファイルにハードコードしないでください。

すべてのポータルトークンを取り消すには、再度トークンポータルにアクセスして “Revoke All Portal Tokens” ボタンを使用してください。

Q: ポータルトークンはどのくらい持続しますか？

A: ポータルトークンは作成から 30 日後 に期限切れになります。トークンポータルにアクセスすればいつでも新しいトークンを生成できます。古いトークンは期限切れまたは取り消されるまで有効です。

アカウントあたり最大 5 つのアクティブポータルトークンを持つことができます。6 つ目を生成すると、最も古いものが自動的に取り消されます。

Q: サポートされている AI エージェントクライアントは何ですか？

A: サーバーは任意の MCP 互換クライアントで動作します。テスト済みおよびドキュメント化されたクライアントには以下が含まれます:

Claude Desktop / claude.ai — OAuth（組み込みコネクタ）
Claude Code CLI — OAuth または Bearer トークン
Cursor — OAuth または Bearer トークン
Windsurf — OAuth または Bearer トークン
Cline — OAuth または Bearer トークン
Continue — Bearer トークン
OpenAI / ChatGPT — OAuth または Bearer トークン（Developer Mode）
Google Gemini CLI — OAuth または Bearer トークン
Perplexity — OAuth または API キー
Manus — OAuth または Bearer トークン
OpenClaw — Bearer トークン

すべてのクライアントは StreamableHTTP トランスポート経由で同じサーバー URL に接続します。

Q: 接続フォームで誤った認証情報を入力するとどうなりますか？

A: サーバーはトークンを発行する前に、ブローカーに対して認証情報を検証します。パスワードが間違っているか誤ったサーバーを選択した場合、成功ページではなくフォーム上に即座にエラーメッセージが表示されます。

2 種類のエラーが発生する可能性があります:

“Credentials rejected by broker” — パスワードまたは SenderCompID が正しくありません。FIX API パスワード（cTrader アカウントパスワードではありません）および SenderCompID を再確認してください。
“Could not reach broker” — サーバーがブローカーに接続できませんでした。正しいサーバーを選択していること、および FIX API アクセスが有効になっていることを確認してください。

5 回連続で失敗すると、ブルートフォース攻撃を防ぐためにアカウントが 15 分間一時的にロックされます。

Q: アクティブなセッションがあるときに再認証の挙動が異なるのはなぜですか？

A: cTrader ブローカーは SenderCompID ごとに 1 つの FIX 接続のみを許可します。アクティブなセッションがあるときに再認証する場合、サーバーは認証情報を検証するために 2 つ目の接続を開けません — 拒否されてしまうためです。

サーバーはスマートロジックでこれを処理します:

同じ設定（モード、リスク制限、サーバーが変更なし）: 検証は完全にスキップされます。アクティブなセッションが既に認証情報の有効性を証明しています。
設定が変更された場合（例: paper から live モードへの切り替え）: サーバーは既存の FIX セッションをまずクローズし、その後新しい認証情報を検証します。新しい認証情報が失敗した場合、次のメッセージが表示されます: “Your previous session was closed. New credentials were rejected by broker.”
パスワード変更: ブローカーで FIX パスワードを変更すると、異なるアイデンティティが作成されます。サーバーはクローズすべき古いセッションを見つけられません。古いセッションが期限切れになる（アイドルタイムアウト）まで待つか、ブローカーでパスワードを変更する前に既存セッションから reset_session を使用してください。

Q: これはローカルサービスですか、クラウドサービスですか？

A: これはクラウドホスト型のリモート MCP サービスです。OAuth または Bearer トークン経由で HTTPS で接続します。サーバーはマネージドクラウドインフラストラクチャ上で動作します — 基盤となるサーバー、コンテナ、プロセス、環境変数、ログ、ファイルシステムへのアクセスはありません。

すべてのやり取りは MCP ツールを通じてのみ行われます。詳細なアーキテクチャおよびトラブルシューティングについては、service-model ナレッジトピックをお読みください: get_knowledge({ topic: "service-model" })。

Q: サービスが応答しないときに何ができますか？

A: 組み込みリカバリツールを次の順で使用してください:

check_health — 現在の状態を診断
reconnect_trade_session — TRADE FIX セッションがダウンしている場合
reconnect_quote_session — QUOTE セッションがダウンしている場合
クライアント設定で MCP コネクタを切断して再接続
問題が続く場合は、submit_feedback を使用して報告

プロセスの再起動、ログの確認、その他のサーバーサイド操作を試みないでください — サーバーインフラストラクチャへのアクセスはありません。

Q: サーバーを再起動したりログを確認したりできないのはなぜですか？

A: これはマルチテナントクラウドサービスです。任意の Web サービスに接続するのと同じ方法で接続します — URL 経由です。SSH アクセス、Docker アクセス、サーバーインフラストラクチャと対話する方法はありません。サービスはプラットフォーム運営者によって管理されています。

問題が発生している場合は、check_health で診断し、再接続ツールでリカバリしてください。継続する問題については、submit_feedback で報告してください。

Q: 接続の問題をトラブルシューティングするにはどうすればよいですか？

A: 次のエスカレーションパスに従ってください:

check_health を呼び出す — fixState および quoteSession.state を確認
fixState != “ACTIVE” の場合 → reconnect_trade_session を呼び出す
quoteSession.state != “ACTIVE” の場合 → reconnect_quote_session を呼び出す
再接続が失敗する場合 → 30 秒待ってリトライ（ブローカーが一時的に到達不能の可能性）
まだ失敗する場合 → 市場がクローズしている可能性があります（週末: 金曜夜 → 日曜夜）、またはブローカーがメンテナンス中の可能性
最後の手段 → クライアント設定で MCP コネクタを切断して再接続し、新しいセッションを取得