QuantMind: 金融知識を型付き成果物に変換するパイプラインとエージェント向けハーネス

QuantMind が埋めようとしている穴は「出典の切れた金融知識」

金融分野の情報処理で厄介なのは、要約の質よりも、その要約がどの資料のどの部分に基づくのか、そしていつ時点の情報なのかが失われることだ。README は QuantMind を「information processor for quantitative finance」と位置づけ、生の金融情報を、下流の検索と推論が信頼できる構造化知識へ精錬すると説明している。ポイントは、すべての知識が型を持ち、引用を保持し、タイムスタンプを知っているという設計方針で、これによって成果物が単体で永続化でき、時点を指定した問い合わせができるとしている。対象読者は、こうした精錬フローを組む開発者と、その開発者を支えるコーディングエージェントだ。リポジトリは agent-oriented に設計されており、チェックアウトを開いて欲しいパイプラインを記述すると、エージェントがリポジトリの契約、スキル、決定的な検証に沿ってそれを組み上げる、という使い方を想定している。同時に通常の import 可能な Python ライブラリとしても使える。

決定的な前処理と、モデルを挟む工程の分離

README の Knowledge Engineering 節は、処理を二層に分けている。一つは fetch、parse、format、clean からなる決定的な前処理で、ここにはモデルが入らない。そのため値はソースに忠実で、来歴が正確になり、再生可能だと説明されている。もう一つがモデルを伴う精錬で、こちらは cfg によって知識の形状が決まる。この分離は実務上かなり効く。パースやクリーニングの段階でモデルを呼ぶと、同じ入力から同じ出力が出る保証がなくなり、差分の追跡が難しくなる。QuantMind はその部分をモデルから切り離し、モデルに依存する工程だけを設定で差し替え可能にしている。ただし README には、前処理がどの程度のファイル形式やレイアウトの揺れに対応するのかは書かれていない。arXiv の PDF のような比較的構造が安定した入力を想定していると読めるが、スキャン画像や表組みの多い開示資料でどこまで耐えるかは、この資料からは判断できない。

cfg の型が知識の形を決める: PaperStructureCfg と PaperSemanticCfg

QuantMind の中心にあるのは PaperFlow で、これは一つの arXiv PDF を自己完結した paper artifact に精錬する。重要なのは、cfg の型そのものが知識の形状を選ぶという点だ。README の記述では、PaperStructureCfg は PaperStructureTree を、PaperSemanticCfg は PaperSemanticResult を生成する。構造ツリーはページ引用を持つノードの階層で、文書全体を木として扱いたい場合に向く。セマンティック形状はページを意識したチャンク集合と、引用付きのグローバル要約を組み合わせたもので、埋め込みを作って検索させたい場合に向く。コード例では PaperFlow(PaperStructureCfg(model="gpt-5.6-luna")) のように cfg をバインドし、await flow.build(ArxivIdentifier(id="1706.03762v7")) でツリーを得て、tree.id と len(tree.nodes) を確認している。設定を一度バインドして入力ごとに適用する、というのがこの API の考え方だ。

batch_run と collect_news が担う「繰り返し」の扱い

単発の変換よりも、多数の入力を同じ設定で処理する方が実際の運用では多い。README は config-driven operations として三つを挙げている。PaperFlow(cfg).build(input) は不変のビルド設定を一度バインドして入力ごとに適用する。collect_news は再生可能なソースウィンドウを収集する。batch_run は任意の操作を入力のリストに展開する。README はこの部分について「You never write asyncio.gather boilerplate」と述べていて、並行処理の記述を利用者から隠す意図が読み取れる。ここで注意したいのは、collect_news が「replayable source window」を集めるという表現だ。ニュースは後から配信元のページが書き換わったり消えたりするため、収集時点のウィンドウを固定して保存する設計になっていると解釈できる。ただし、収集対象のソース一覧や更新頻度、レート制限への対応は README からは分からない。

rag/ と library/ と mind/ の三層は何を分担するのか

精錬した知識を引くための層として、README は三つを挙げている。rag/ はチャンキングと BM25 または類似度による検索。library/ はローカル永続化と意味ベースの検索。mind/ はエージェント的で推論に基づく検索。これらを合わせて RAG、Agentic RAG、deep research、data-MCP serving に供すると説明されている。三層の分け方には意味がある。BM25 のような語彙一致は固有名詞や数値に強く、埋め込み検索は言い換えに強い。金融の問い合わせはこの両方の性格を持つため、片方だけでは取りこぼす。mind/ が推論ベースとされているのは、単一の検索結果を返すのではなく、複数回の検索と判断を経て答えを組み立てる層という位置づけだろう。ただし README には、これら三層がどう接続されるのか、mind/ がどのモデルをどう呼ぶのかまでは書かれていない。設計の意図は読めるが、実装の詳細は contexts/ 配下のページを読む必要がある。

「import するな、開け」という harness engineering の主張

このリポジトリで最も意見が強いのは、Vision の節だ。引用すれば「Don't import it. Open it.」であり、リポジトリ自体が製品の表面だと宣言している。仕組みとしては、AGENTS.md と CLAUDE.md が常時有効なルールを一箇所に書き、contexts/ が Quick Summary と Contents のプレビューを持つ progressive disclosure のページ群として、エージェントが必要な一ページだけを読むようにし、quantmind-dev というポータブルスキルが Claude と Codex 向けにミラーされ、両エージェントで同一のフックスクリプトを共有することで、ルールの二重管理を避けている。最後に scripts/verify.sh が lint、型、import 境界、テストを固定順で高速に失敗させ、CI も同じスクリプトを実行する。ここで掲げられている賭けは「a weak model in a good harness beats a strong model running bare」というものだ。モデルの性能ではなく、モデルを取り巻く制約の設計で出力品質を決めるという立場である。

エージェント前提の設計が向かないケース

この設計には明確な代償がある。第一に、AGENTS.md、CLAUDE.md、contexts/、スキル、フック、verify.sh という層は、人間が自分の手でパイプラインを書き、テストも自分で回すチームにとっては間接費でしかない。エージェントにリポジトリを開かせて作業させる運用をしないなら、これらのファイルは読まれないまま保守対象になる。第二に、README が示す例は arXiv の識別子を渡すものが中心で、ニュースや決算資料の取り込みは collect_news の名前と説明以上のことが書かれていない。手元のデータソースが arXiv でも一般的なニュースでもない場合、どの程度そのまま使えるかは資料からは判断できない。第三に、README にはリリース一覧がなく、master ブランチの最終更新は 2026-08-15 と記録されている。バージョン番号で固定して導入する道が用意されているかどうかは、この資料からは確認できない。ライセンスは MIT と明記されており、表示義務は緩いが、同梱の assets や contexts/ に含まれる文書の扱いについては各ファイルを確認する必要がある。これは法的助言ではない。

比較対象としての LlamaIndex と、設計思想の差

同じ「文書を取り込んで検索させる」目的なら、LlamaIndex が最初に思い浮かぶ比較対象になる。違いは抽象化の置き場所だ。LlamaIndex は reader、node parser、index、retriever といった部品をライブラリとして提供し、利用者はそれらを import して自分のアプリケーションに組み込む。QuantMind は逆で、リポジトリという作業場を提供し、その中でエージェントにパイプラインを書かせる。知識の型と cfg の対応、verify.sh による検証、contexts/ による段階的な文脈供給が製品の一部であり、Python パッケージとしての API はその副産物に近い。どちらが優れているという話ではない。既存のアプリケーションに検索機能を足したいならライブラリ型の方が素直に収まる。一方、金融文書の精錬手順そのものをチームの資産として固定し、エージェントに同じ品質で再現させたいなら、契約と検証をリポジトリに置く QuantMind の考え方に利がある。README が arXiv:2509.21507 として NeurIPS 2025 GenAI in Finance Workshop の論文を挙げているのも、この設計を研究上の主張として提示しているためだ。

編集部の結論

採用を検討すべきなのは、arXiv 論文やニュースを出典付きの構造化データに落とし、その上で RAG やエージェント検索を組みたいチーム。特に、コーディングエージェントにリポジトリを開かせてパイプラインを書かせる運用に関心がある場合、AGENTS.md と contexts/ と scripts/verify.sh の組み合わせは参考になる。逆に、単発の要約やチャットボット用途で十分な場合、この型付き成果物と検証スクリプトの層は過剰になる。最初に確認すべきは、PaperStructureCfg と PaperSemanticCfg のどちらの形状が自分の検索要件に合うか、そして scripts/verify.sh が手元の環境で通るかどうか。README にはリリース一覧がなく、破壊的変更の履歴は追えないため、master を追う前提で使うかどうかを決める必要がある。

公式情報源

1. Issues
2. License: MIT
3. LLMQuant/quant-mind on GitHub
4. Project website
5. README