Signal Trader インタビュー要約とイベントソーシング設計草案

現在は 2026年3月12日、木曜日、午後です。

本日は、LOGS/71 に関する Signal Trader の設計について、エンジニアリング実装に焦点を当てたインタビューを実施しました。目標は、理念的な制約を実現可能なシステムルールへと収束させること、特に複数投資家の損益計算精度、分離原則、および監査可能な再現能力についてです。

本回で確定した中核的制約

1. Signal Trader は資本持久戦の原則に従う必要があります：損失に基づくポジション決定、リスクの厳格な制約、資本効率の最大化。
2. シグナルの最小セマンティクスは product_id + direction(-1/0/1) です。stop_loss_ratio はオプションです。時間は Signal Trader が受信した時刻を基準とします。
3. 名目価値の決定権は Signal Trader に完全にあり、シグナル側はポジションサイズの自由度を注入できません。
4. direction=0 は強いセマンティクスです：現在のポジションを即時決済し、強制的にノーポジションを維持します。
5. direction=0 は強いセマンティクスです：現在のポジションを即時決済し、強制的にノーポジションを維持します。
6. ポジション建てにストップロスが必要だが stop_loss_ratio が欠落している場合、ポジション建てを拒否します。
7. 同一銘柄に対する複数シグナルはネット額で統合して実行します。完全に相殺される場合は板の mid 価格を用いて統一決済します。
8. 複数の購読単位が存在する場合、「購読ID」を損益計算の粒度とします。1人の投資家が同一シグナルを複数購読することが可能です。
9. 分離原則は破壊できません。投資家が即時資金引き上げによって生じるコストは、当該投資家が単独で負担します。
10. システムは複数投資家の損益計算精度を最優先で最適化します（MVP の最優先事項）。

資金と損益計算ルール

投資家別独立バッファープール

• 残差は共通プールに入らず、投資家次元の独立したバッファープールに入ります。
• バッファープールの資金は常に当該投資家に帰属し、最小精度の制限により一時的に引き出しができない可能性があるだけです。
• バッファープールは当該投資家の VC 体系の一部であり、「VC に戻す」という追加アクションは存在しません。

VC 計算のトリガー

• 複数種類のイベント（シグナルトリガー、購読変更、照会、定期実行）による Lazy Evaluate を許可します。
• 中核的な制約は頻繁な資金移動アクションを避け、台帳計算を優先し、ブロックチェーン上/外部の資金アクションを後回しにすることです。

執行と約定戦略

1. 現段階では、約定を優先的に保証するため、成行注文での追従を優先します。
2. 記帳は二段階で行います：
   • 注文発注成功時に執行イベントを記録。
   • 約定報告時に約定イベントとポジション台帳の変化を記録。
3. 完全な内部相殺（外部約定なし）の場合：
   • 板の mid 価格を用いて統一決済を行います。
   • mid 価格の取得元と取得時刻を監査ログに記録します。

例外処理の原則

• ポジション保有中は、システムが能動的に決済することはできません（シグナルが明示的に direction=0 を指示した場合を除く）。
• シグナル側のジッターに対してクールダウン時間は設定しません。VC 資金が枯渇するまでは、人為的に頻度を下げません。
• direction=0 が到着した際、ポジションがなくても成功監査イベントを記録し、シグナル連携の健全性検証に使用します。
• 重点アラート項目：短期間内の大量注文拒否。

監査システム：Action / Reducer 再現メカニズム

本回で明確に採用する方針：監査ログがイベントストリームであり、状態は reducer による再現で得られる。

これは本質的に Event Sourcing です：

• 監査ログは追加のみ（append-only）で、物理的なロールバックは行いません。
• システム状態（ポジション、VC、損益計算）はイベントの再現によって得られます。
• 同一のイベントストリームと同一の reducer バージョンでは、確定的に一貫した状態が得られなければなりません。

イベント階層化の提案

1. Intent*：シグナル意図層（例：シグナル受信、目標ポジション変更）。
2. Execution*：執行層（注文発注、注文拒否、約定報告）。
3. Ledger*：台帳層（ポジション/VC/損益計算結果の記帳）。

注文拒否のセマンティクス（重要）

注文拒否は「履歴の削除」ではなく、「補償イベントの追加」です：

1. IntentCreated を記録。
2. 執行を試み、注文が拒否された場合は OrderRejected を記録。
3. 占有リソースを解放する補償イベント（例：IntentReleased）を追加。
4. ポジション台帳は約定事実によってのみ駆動され、拒否された意図によって変更されることはありません。

これにより、以下の3点を両立できます：

• 監査の追跡可能性（履歴が失われない）
• 台帳の一貫性（失敗した執行を成功したポジションとして記帳しない）
• 再現可能な障害調査（各ステップでなぜ約定しなかったかを説明できる）

v1 最小イベントリスト（草案）

1. SignalReceived
2. IntentCreated
3. OrderSubmitted
4. OrderRejected
5. OrderAccepted
6. OrderFilled
7. InternalNettingSettled
8. PositionUpdated
9. InvestorLedgerUpdated
10. BufferAdjusted
11. SubscriptionUpdated
12. SignalForcedFlatHandled (direction=0 パス)
13. MidPriceCaptured
14. AlertTriggered

次のステップ

1. まず、イベントスキーマ（フィールド、べき等キー、バージョン番号）を確定させます。
2. reducer ステートマシン（Intent/Execution/Ledger の3層に分割）の図を作成します。
3. 「再現可能な一貫性」に関する回帰テストケース（注文拒否、部分約定、完全相殺、資金引き上げ残差）を追加します。
4. 「複数投資家の損益計算精度」を第一の受け入れ基準として、実装を推進します。

今回のインタビューの価値は、「理念の正しさ」を「システムとして証明可能な正しさ」へと前進させた点にあります。この基盤の上に立って、Signal Trader は初めて、監査可能、拡張可能、実戦投入可能なエンジニアリング段階へと進むことができます。