tick-stock-panel: A株の選別・監視・検証を自前で回すための構成を読む

TSPが埋めようとしている穴はデータ経路の断絶である

A株の個人向け量化ツールは、選別・監視・検証のどれか一つに寄りがちである。選別だけできても手元のデータが更新されなければ翌日に使えないし、検証だけできても監視に流し込めなければ日中の判断に間に合わない。tick-stock-panel（以下TSP）は、この三つを一つのローカル環境に同居させることを狙っている。READMEの冒頭には「自托管、零运维」とあり、サーバを借りて常時動かすのではなく、手元で完結させる方向が明示されている。対象は、A株の板情報や分足を自分で調達でき、Pythonを読み書きできる利用者である。README自身が「小白请绕路」と書き、投資ソフトや相場ソフトの代替ではないと断っている。つまり、証券会社のアプリを置き換える製品ではなく、データとロジックを自分で握りたい人向けの作業台という位置づけになる。

能力ルーティングという考え方が構成の中心にある

一般的な相場ツールはデータ提供元を一つに固定する。TSPはこれを能力単位で分解する。日K、除権（権利落ち調整）、リアルタイム、分足、板情報、財務というデータセットごとに、どの源から取るかを独立に決められる。READMEの表現では「多数据集…按源能力独立路由,任选组合」となる。この設計の効き目は、ある源が分足だけ弱いという場合に、その部分だけ別の提供元へ差し替えられる点にある。代償もある。源が増えるほど、銘柄コードや時刻の表記、欠損の埋め方が源ごとにずれる。READMEはこの吸収をプラグイン側の責務としており、docs/custom-data-source.mdに仕様が置かれている。設定画面には「能力路由矩阵」と「档位徽章」があり、どの源がどの能力を持つかをUIで確認する作りだ。能力の有無を宣言させ、実行時にルーティングする方式は、データ源の契約が変わったときに影響範囲を局所化しやすい。

指標は68列を一度に落とし、以後はParquetを読む

選別のたびにMAやMACDを計算し直すのは無駄である。TSPはMA、EMA、MACD、RSI、KDJ、ブリンガー、量比などを含む68列の指標と信号を、一度のスキャンでenriched Parquetとして書き出す。以降の選別・回測・監視はこのParquetを読む。READMEでは「一次扫表落盘 enriched Parquet」と説明されている。計算エンジンはPolarsで、全A株のスキャンについてREADMEは「毫秒级」と記述する。これは著者による主張であり、当サイトが計測した数値ではない。重要なのは速度の数字よりも、指標の生成と消費を分離した点である。ストラテジは指標列を前提に書けるので、指標定義を変えたときはenriched Parquetを作り直す必要がある。データの再生成コストを見積もっておかないと、指標を一つ足すたびに全銘柄を再計算することになる。

回測はT+1と費用を前提に組まれている

A株の回測で最も壊れやすいのは約定条件である。TSPの回測はT+1、手数料、スリッページ、損切りを制約として組み込み、結果はSSEで進捗を流す。READMEが挙げる研究ビューは四つある。因子回測はIC/IR、分層収益、多空組合せを見る。戦略回測は純資産曲線、ドローダウン、シャープ、勝率、損益比、モンテカルロドローダウンを出す。分足戦略回測は各取引日を再生し、分足終値で入場する。検証はパラメータ感度と滚动样本外を扱う。結果はCSV（概要・純資産・取引明細・銘柄別統計）に書き出せ、保存した候補を「一键载入复测」で読み戻せる。研究の往復が閉じているのは評価できる。ただし、指標の再計算が必要な変更を加えた場合、この閉ループはenriched Parquetの再生成を挟むことになる。

因子平台と挖掘は自動運用ではなく候補提示で止まる

因子平台はDSLで独自因子を書く。エディタには25の演算子が点選でき、試算と版本管理があり、因子ライブラリから「一键生成排名策略」でストラテジに変換できる。逆方向もあり、ストラテジのトリガーが因子条件を参照し、回測では勝ち負けのエントリー日における因子値を比較する帰因を出す。因子挖掘は入れ子の样本外探索で、訓練区間で因子の方向を推定し直し、相関で重複を除き、複数因子のランキング組合せを探す。ここで注目すべきは、候補が「显式发布、永不自动上线」と明記されている点である。自動で本番のストラテジを差し替える仕組みは持たない。研究補助としての線引きが明確で、この方針はREADMEの「不内置AI荐股」という宣言とも整合する。挖掘の結果をそのまま売買に結びつける使い方は、設計上想定されていない。

導入はDockerと設定キーから始まる

リポジトリのルートにはDockerfileがあり、GitHub Actionsのdocker.ymlがビルドを行う。READMEのバッジもDeploy: Dockerを示す。起動手順そのものは提供された範囲では確認できないため、実際のコマンドはリポジトリのREADMEとdocker-compose定義を直接参照してほしい。設定はアプリ内の「设置」ページに集約されており、そこでデータ源と能力検出（能力路由矩阵、档位徽章）、AI接口、实时监控、扩展页面、菜单を扱う。拡張データはYAMLで定義する方式がdocs/custom-data-source.mdに記載され、任意の第三者フィールドを一級メニューとして同台分析に載せられる。時系列テーブル（例として人气排行）は日付パラメータを接口に渡して日単位で遡及取得する。つまり、設定キーとYAMLが実質のインターフェースであり、GUIの設定画面はその上に乗る確認用の表示と考えると読みやすい。

向かない場面と、代わりに検討する構成

第一の制約はデータ調達の責任が利用者側にあることだ。データ源はプラグイン化されており、TickFlow、fuyao、stock-sdkといったアダプタとYAML定義の独自源が挙げられているが、いずれも契約や認証情報は利用者が用意する。データ取得ごと任せたい人には、この構成は手間が大きい。次に、READMEが「小白请绕路」と書く通り、PythonとPolarsの読み書きが前提になる。第三に、リリースが取得できておらず、バージョン番号に基づく互換性の判断ができない。代わりに検討すべきものとして、クラウド側でデータ取得と計算を完結させるマネージド型の量化プラットフォームがある。違いは責任の所在である。マネージド型はデータ経路を提供側が保守し、利用者はストラテジに集中できる。その代わり、指標の定義や保存形式を自分で差し替えられず、提供元が対応しないデータセットは使えない。TSPは逆で、経路の自由度と引き換えに調達と保守を引き受ける。どちらが良いかは、自分でデータ契約を書けるかどうかで決まる。

MITライセンスと個人プロジェクトとしての保守コスト

ライセンスはMITで、リポジトリのLICENSEファイルを参照する形になっている。MITは改変と再配布を許すが、著作権表示と許諾表示の保持が条件になる。法的助言ではないので、配布や商用利用を考える場合は各自で確認してほしい。READMEは「仅供学习研究使用，严禁商业用途」と書いており、MITの条文とこの但し書きの関係は整理されていない。ここは採用前に読むべき箇所である。保守の面では、データ源アダプタとYAML定義が外部契約に依存するため、提供元の仕様変更がそのまま保守作業になる。指標定義やストラテジを増やせばenriched Parquetの再生成が必要になり、その時間は銘柄数と指標数に比例する。AI機能を使う場合は別途APIキーと費用が発生する。個人開発であり、リリースも取得できていないため、破壊的変更の予告を前提にした運用は難しい。バージョンを固定して動かし、更新は差分を読んでからにする判断が現実的である。

編集部の結論

採用を検討すべきなのは、A株の日足・分足データを自分で取得でき、PolarsとDuckDBを扱える個人または少人数の研究チームである。同梱のデータ源アダプタとYAML定義の拡張機構を読んで自前のデータ経路を書けることが前提になる。逆に、データ取得そのものを任せたい人、投資判断の根拠を外部に求める人には向かない。着手前に確認するのは、docs/custom-data-source.mdの能力ルーティング定義と、各自が契約するデータ源の利用条件がこの構成で満たせるかどうかである。

公式情報源

1. Issues
2. License: MIT
3. README
4. shy3130/tick-stock-panel on GitHub