QuantDinger v5は取引アイデアを運用可能なPython戦略へつなぐ

AI取引OSという位置づけ

QuantDingerは、暗号資産、株式、為替の市場データとAI調査を、Python戦略、バックテスト、ペーパー取引、ライブ実行、監視へつなぐオープンソースの自ホスト型スタックです。READMEはブラックボックスのシグナル配信ではなく、戦略コード、リスク設定、認証情報、デプロイを運用者が保持する製品だと説明しています。README上の機能説明は広いものの、収益性や投資成果を示す資料ではありません。

v5で分かれた実行責任

v5ではHTTP APIが長時間の取引ループやスケジューラを所有せず、backend、trading-worker、scheduler-worker、Celery workerなどに役割を分けます。PostgreSQLは状態と耐久的なコマンド、Redisはキャッシュとジョブで用途を分離します。まずCompose定義とPROCESS_ROLES_AND_TASKS.mdを読み、どのプロセスが注文、ハートビート、再試行を担当するかを確認するのが筋です。

戦略作成から注文まで

READMEにはマルチプロバイダーの市場調査、Strategy API V2、サーバー側バックテスト、実験ワークフローが列挙されています。調査結果をそのまま実注文にする機能として読むのではなく、生成されたPythonコード、入力データ、リスク設定、バックテスト結果を別々に保存して比較する運用が必要です。ライブ注文は明示的に有効化したときに送信されるため、鍵の権限と対象口座を実行前に限定します。

導入時に読むべき入口

Docker Compose v2を前提に、READMEはLinuxまたはmacOSでinstall.shを実行する手順を示します。初回管理者情報と秘密値を生成し、Webは8888、モバイルH5は8889、APIヘルスは5000番で確認します。curlでスクリプトを取得する方式なので、採用時は対象コミットやリリース版を固定し、生成された設定とsecretsの権限を記録してから起動します。

監視と更新の境界

任意のobservability overlayではJSONログ、リクエストID、Prometheus、Grafana、Alertmanagerが利用できます。production overlayには非root実行、読み取り専用ルートファイルシステム、能力削除、リソース制限が記載されていますが、これらは設定の存在を示す説明であり、実環境の安全性を保証しません。VERSIONとGitタグ、DBマイグレーション、注文再照合を更新前後で確認します。

採用判断と具体的な確認

MITではなくApache-2.0のライセンスで、READMEは市場や法域ごとのコンプライアンス確認を運用者に求めています。最初の検証では/api/healthの応答、PostgreSQLの状態、trading-workerのハートビート、ペーパー注文の履歴、Celeryジョブの再試行を同じ時刻で記録します。READMEにないブローカー互換性や性能は断定せず、対象市場の小さな検証ケースで判断します。

評価用の最小ケースは、同じ銘柄と期間の市場データを固定し、AI調査を使う場合と使わない場合で生成されたStrategy API V2のコード差分を保存するところから始めます。バックテストの注文履歴、手数料、リスク設定を読み取り、ペーパー取引の約定履歴と時刻を突き合わせます。trading-workerを再起動した後に保留注文が二重送信されないか、scheduler-workerのスケジュールが重複しないかも確認対象です。ライブ取引へ移る場合は、APIキーを読み取り専用または取引限定にし、引き出し権限を与えません。READMEにない税務や法域の判断は別途専門家へ確認します。

QuantDingerでは、調査、戦略、注文、監視を同じ画面の便利さだけで評価しないことが重要です。バックテストの期間を変えたときに結果がどの程度変わるか、欠損データをどう扱うか、ペーパー口座の約定が実注文と別の経路で記録されるかを確認します。APIから耐久コマンドを送った後にワーカーが停止した場合の再開も試します。監視のアラートが発火した時刻と注文履歴の時刻を比較し、ログだけでなくPostgreSQLの状態も保存します。これらを確認できない段階では、AI分析の便利さを理由に取引範囲を広げません。

記録には、利用したリリースタグ、Composeファイル、環境変数の一覧、データ期間、注文モードを含めます。特にライブ実行の切り替えは画面操作だけに依存せず、設定値と注文結果の両方で確認します。

QuantDingerの検証では、注文を送る権限と分析だけの権限を分けます。調査結果、コード、約定、監視の各記録を同じ版へ結び付け、再現できない数字は採用根拠にしません。

導入前には、対象版のリリースと実行環境を記録します。入力と出力を固定した小さな試験を作り、成功だけでなく失敗時の状態も保存します。設定ファイルの既定値を確認し、変更した値を一覧にします。権限は必要な範囲に絞り、管理者操作と通常利用を分けます。ログには時刻、版、対象、結果を残します。外部サービスを使う場合は通信先と認証の境界を確認します。更新時は同じ試験を再実行し、以前の結果との差を見ます。素材にない性能や安全性を数値として補いません。READMEの機能説明と実際の動作が異なる場合は、動作を優先して原因を調べます。

編集部の結論

向いているのは、Pythonで戦略を管理し、データ、認証情報、注文処理を自分の環境で統制したい個人や小規模チームです。投資判断そのものを委ねたい人には合いません。最初はDocker Composeでペーパー取引を行い、VERSION、APIヘルス、ログ、注文の照合を確認してから、限定権限の鍵で次の段階へ進むべきです。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes