AIトレーディングOSS「Vibe-Trading」が選ばれる理由

「GitHub Trending で見かけた Vibe-Trading を、自分の検証プロジェクトに採用すべきか判断したい」。そう考えて情報を集め始めると、AI トレーディング系 OSS は TradingAgents や FinRL など複数の有力プロジェクトが存在することに気づきます。それぞれ設計思想も対応領域も異なるため、単純な比較記事だけでは決めきれません。

とりわけ Vibe-Trading は、自然言語プロンプトから戦略生成・バックテスト・ブローカー実行・IM 配信までを 1 パッケージにまとめた「Personal Trading Agent」を標榜しています。しかし、同じような領域では TradingAgents（マルチエージェント議論型）や FinRL（強化学習型）などが先行しており、機能名だけを追っても差分がぼやけがちです。

本記事では、香港大学の HKUDS/Vibe-Trading を「初見のエンジニアが採用判断を下すため」に必要な観点で整理します。リポジトリ基本情報、コア機能、対応市場、類似 OSS との差分、メンテナンス状況、導入判断のチェックリストを、README と公式ドキュメントのみを情報源として解説します。

なお、記事本文は 2026 年 7 月 16 日時点の GitHub リポジトリメタデータと、公開されている README・公式サイト・公式ドキュメント の記載に基づきます。実際のインストールや動作検証は行っていないため、実装細部については本記事末尾に掲げる公式リンクで最新情報をご確認ください。

Vibe-Tradingとは：AIトレーディングエージェントOSSの全体像

Vibe-Trading は、香港大学データサイエンス研究室（HKUDS）が公開する「Personal Trading Agent」を掲げる OSS です。自然言語のプロンプトを起点に、市場データ取得、戦略コード生成、バックテスト、レポート生成、ブローカー実行、チャネル配信までをひとつのパッケージで扱えるように設計されています。

想定される用途は、リサーチ・シミュレーション・バックテストが中心です。ライブトレーディングは、ユーザーが認可したブローカー経由でのみ実行され、後述する「Mandate（許可範囲）」「Kill Switch」「監査台帳」といった安全機構の下で限定的に動作する仕組みになっています。

配布形態としては PyPI（vibe-trading-ai） と Docker が公式に提供されており、Backend は FastAPI、Frontend は React 19、CLI は vibe-trading コマンドとして提供されます。エントリーポイントは CLI・Web UI・REST API・MCP サーバー・IM チャネルの 4 系統に整理されており、既存のツールチェーンから多角的に呼び出すことを前提とした設計となっています。

リポジトリ基本情報（2026年7月時点）

gh api /repos/HKUDS/Vibe-Trading で取得したメタデータをもとに、判断材料になる項目をまとめます。

archived=false かつ fork=false である点は、本家が現役のメンテナンスを続けており、他リポジトリのミラーやフォーク版ではないことを意味します。最終 push が本記事公開の直前まで動いていることと合わせて、現時点でアクティブに開発が進む本家リポジトリだと判断できます。ライセンスは MIT ですので、商用利用時の負担も比較的軽い部類に入ります（詳細は LICENSE を参照）。

開発元 HKUDS と姉妹プロジェクト（AI-Trader）の位置関係

開発元の HKUDS（The University of Hong Kong Data Science Lab）は、AI・データサイエンス分野の OSS を継続的に公開している研究組織です。Vibe-Trading とは別に、姉妹プロジェクトとして HKUDS/AI-Trader も公開しています。

両者の位置づけは、README の説明を突き合わせると次のように整理できます。

• Vibe-Trading: 対人前提の「Personal Trading Agent」。ユーザーが自然言語で意図を伝え、エージェントが調査・戦略生成・バックテスト・実行の一連を支援する。ユーザーは Mandate や Kill Switch で挙動を制御し、監査ログを残しながら段階的に自動化する設計。
• AI-Trader: 完全自動化を志向する「Agent-Native Trading」。ブラウザや Cursor / Claude Code など外部エージェントランタイムから呼び出されて、より自律的に動作するコンセプト。

したがって「人間が最終判断や監督を残したまま研究や運用を高速化したい」場合は Vibe-Trading、「エージェントランタイムに組み込む部品として自動化を突き詰めたい」場合は AI-Trader、というように使い分けの想定が用意されています。本記事の焦点は Vibe-Trading ですが、後述の類似 OSS 比較では AI-Trader は「直接代替」ではなく「同一組織の別コンセプト」として扱います。

Vibe-Tradingが提供する4つのコア機能

Vibe-Trading の README は多数の機能を列挙していますが、初見のエンジニアが採用判断を下すうえで押さえるべきポイントは、「自然言語で研究フローを回せるか」「学習コストを払わずに定量検証できるか」「他ツールにはない差別化された分析ができるか」「本番運用に耐える安全機構があるか」の 4 点に集約できます。ここでは機能を羅列するのではなく、これら 4 つの観点で整理します。

1. 自然言語プロンプトからバックテストまでのエンドツーエンド統合

Vibe-Trading の最大の設計思想は、「プロンプト → 市場データ取得 → 戦略コード生成 → バックテスト → レポート → 実行/配信」までを 1 コマンドで扱えるようにする、という点にあります。CLI（vibe-trading コマンド）、Web UI、REST API、MCP サーバー、IM チャネルという 4 系統のエントリーポイントが用意されており、どの経路からも同じエージェントセッションランタイムに接続できます。

Multi-Agent Trading Teams（Swarm）として、Investment / Quant / Crypto / Risk など 29 のプリセットが用意されており、ワーカーは同一のローダーレジストリ経由で市場データを取得します。各ワーカーは Waiting / Running / Done / Failed / Blocked / Retrying の状態を Web UI にストリーミング表示し、進捗を可視化する設計です。詳細は 公式ドキュメント の Getting Started セクションで確認できます。

2. Alpha Zoo：461の既製ファクターによる学習不要のクオンツ検証

Alpha Zoo は、Vibe-Trading に同梱される 461 の既製ファクター（アルファ）ライブラリです。以下 5 つのグループに分類されており、そのまま呼び出してクオンツ検証に投入できます。

• qlib158: Microsoft Qlib 由来の 158 ファクター
• alpha101: Kakushadze (2015) の 101 ファクター
• gtja191: 国泰君安 (2014) の短期ファクター群
• academic: Fama-French 5 + Carhart 等のアカデミック系
• fundamental: PIT-safe な SEC ファンダメンタルズ（2026-07-08 に追加）

README に例示されている CLI コマンドは、以下のように 1 行でファクターの IC（情報係数）ベンチマークを走らせる形になっています（引用元: HKUDS/Vibe-Trading README）。

vibe-trading alpha bench --zoo gtja191 --universe csi300 --period 2018-2025 --top 20

同様に vibe-trading alpha compare で複数アルファのヘッドツーヘッド比較ができるとされています。自前で強化学習モデルを組む前に、既製のアルファ群でどこまで説明力が出るかを短時間で確認できる点は、「学習不要で意思決定材料を得たい」というエンジニアの負担軽減に直結します。

3. Shadow Account：ブローカージャーナル解析と反事実バックテスト

Shadow Account は、README でも独立した機能として紹介されている Vibe-Trading 固有の差別化要素です。ユーザーのブローカージャーナル（同花順・東方財富・富途・汎用 CSV など）を読み込み、以下のような行動プロファイルを抽出します。

• 平均保有日数・勝率・PnL 比・ドローダウン
• 処分効果（負けポジションを持ち続け、勝ちポジションを早く切る傾向）
• オーバートレーディング・順張り追随・アンカリング

そのうえで、抽出した「暗黙のシャドー戦略」と実際の売買を比較する反事実バックテストを自動生成し、HTML/PDF レポートとして出力します。これは「エージェントに何かを推薦させる」ではなく「自分自身の過去の売買を診断する」機能であり、TradingAgents や FinRL には見られない切り口です。個人の裁量取引を検証したいエンジニア・投資家にとっては、他 OSS では代替しにくい価値を持ちます。

4. Trust Layer と Mandate + Kill Switch による安全機構

Vibe-Trading は「Personal」を掲げるだけあり、ライブ実行時の安全設計にもかなりの分量を割いています。バックテスト実行時には run_card.json と run_card.md が発行され、再現可能な研究記録として保存されます。Web UI の Run Detail ページから可視化できるため、実験履歴のトレーサビリティが確保されます。

さらに、ブローカーとの接続には Mandate（許可範囲）を必ずコミットする仕組みが導入されています。銘柄ユニバース・注文サイズ・エクスポージャー・レバレッジ・日次上限などを事前に定義し、Kill Switch・監査台帳・自動失効を組み合わせて安全性を担保する設計です。

加えて、2026-07-13 には外部セキュリティ監査 10 項目のクローズがアナウンスされており、代表的な項目は以下のように整理されています。

• Docker マルチステージビルド + ダイジェスト固定
• AST ハードニング化バックテストサンドボックス（network / subprocess / eval / os.environ / unsafe-open をブロック）
• SSE 認証用の短命シングルユースチケット
• Compose の読み取り専用ルートファイルシステム
• /correlation エンドポイントの認証 + レート制限
• ハッシュ固定依存 + ライセンス管理

「AI エージェントに証券口座を触らせる」以上、これらのガードレールが最初から実装されているかは採用判断の前提条件になります。Vibe-Trading はこの水準を README 上で明示している数少ない OSS のひとつです。

対応市場・データソース・LLMプロバイダー

「自分の関心市場・LLM 環境で使えるか」は、意思決定を左右する現実的な観点です。ここでは README の記述をもとに、対応レンジを一問一答的にまとめます。

対応市場と対応ブローカー

Vibe-Trading の Broker Connectors は「connector-first アーキテクチャ」を採用しており、対応する市場・ブローカーは以下のように整理されています。

• 実売買可能（Mandate 制御）: Tiger、Alpaca、OKX、Binance、Futu、Robinhood Agentic Trading
• 読み取り + ペーパートレードのみ: IBKR（ローカル TWS / IB Gateway 経由）、Longbridge、Dhan、Shoonya、Trading 212

対応市場としては、A 株、米国株、香港株、インド NSE / BSE、クリプト、futures、forex の 7 セグメントが README に列挙されています。日本株の専用コネクタは 2026 年 7 月時点では明示されていないため、日本市場向けに使いたい場合は、汎用 CSV や海外市場経由での運用パターンを検討することになります。

19の無料データソースと自動フォールバック

get_market_data ツールは source: "auto" を指定すると、市場ごとの IP-ban リスク順にデータプロバイダーを自動フォールバックします。README に記載されているチェーンの一部は以下の通りです。

• A 株: tencent → mootdx → eastmoney → baostock → akshare → tushare → local
• 米国: yahoo → stooq → sina → eastmoney → yfinance → tiingo → fmp → finnhub → alphavantage → longbridge → akshare → local
• 香港: eastmoney → yahoo → futu → yfinance → akshare → longbridge → local
• インド（NSE/BSE）: yahoo → yfinance → india_broker → local
• クリプト: okx → ccxt → yfinance → local

加えて、フローデータ・SEC EDGAR・オプション・機関投資家保有などを扱う 18 の読み取り専用データツールが MCP 経由で提供されます。オプションとして有料の QVeris（63+ プロバイダーを 1 キーで統合）に切り替えることも可能です。自前で複数プロバイダを組み合わせるコードを書く手間を省ける、というのが実装者にとっての利点です。

13+ の LLM プロバイダーと MCP 対応

LLM プロバイダーは、README で「13+」と表現されるとおり複数のバックエンドをサポートしています。挙げられているのは以下のようなラインナップです。

• OpenAI / OpenAI Codex（OAuth）
• Anthropic Claude
• Google Gemini
• DeepSeek / Kimi (Moonshot) / MiniMax / Z.ai / GLM (Zhipu)
• NVIDIA NIM
• Requesty など

vibe-trading provider doctor コマンドで、それぞれの接続状態を診断できるとされています。手持ちの LLM API キー資産を活かせるかどうかは、初期セットアップコストと安定運用の両面で重要な判断材料です。Claude / OpenAI / DeepSeek のような主要プロバイダに加えて、中国系や NVIDIA NIM まで幅広くカバーされている点は、地域・コスト・レイテンシの制約に合わせて柔軟に選べる余地を残しています。

類似OSSとの比較：TradingAgentsとFinRLとの違い

Vibe-Trading を検討するとき、多くのエンジニアが同時に候補に挙げるのが TauricResearch/TradingAgents（約 93.4k stars）と AI4Finance-Foundation/FinRL（約 15.7k stars）の 2 つです。ここでは、それぞれとの差分を明確にします。

TradingAgents（マルチエージェント議論型）との比較

TradingAgents は、LLM ベースのマルチエージェントを協働させる金融取引フレームワークです。アナリスト（ファンダ・センチメント・ニュース・テクニカル）、リサーチャー（強気 / 弱気）、トレーダー、リスク管理、ポートフォリオマネージャーなど複数のロールを役割ごとにエージェント化し、議論を通じて取引判断を導き出す研究用プラットフォームという位置づけです。ライセンスは Apache-2.0 です。

Vibe-Trading との違いは「議論プロセスに主軸を置く研究プラットフォーム」か「実運用パイプラインの統合セット」かという点にあります。TradingAgents はエージェント間の議論プロセスそのものに研究上の価値を置いており、ブローカー接続・IM 配信・監査台帳・既製ファクター（Alpha Zoo）などの実行系は本体には含まれません。一方 Vibe-Trading は、議論的な Multi-Agent Trading Teams を持ちつつ、取得 → 戦略生成 → バックテスト → ブローカー実行 → IM 配信 → レポートまでを 1 パッケージで完結できるように整えられています。

したがって、「エージェント間の議論構造そのものを研究したい」場合は TradingAgents、「議論の結果を実行系に接続して回したい」場合は Vibe-Trading、という切り分けが最初の判断軸になります。

FinRL（強化学習型）との比較

FinRL は、金融向け深層強化学習（DRL）のオープンソースフレームワークです。A2C / DDPG / PPO / SAC / TD3 といったアルゴリズムでエージェントを学習させることを主眼としており、次世代の FinRL-X（AI-Native Modular Infrastructure）も進行中です。ライセンスは MIT ですが、FinRL 商標には利用制限があるとされます。

Vibe-Trading との違いは「強化学習アルゴリズムを自分で学習させるか」「LLM + 既製ファクターで意思決定支援を受けるか」の一点に尽きます。FinRL では、環境定義・状態設計・報酬関数の設計・ハイパーパラメータチューニングなど、DRL の学習ワークフローを自前で組み上げる必要があります。一方 Vibe-Trading は、LLM エージェントと 461 の既製アルファ、Shadow Account、Trust Layer を組み合わせて「学習不要で実務的な意思決定支援」を提供する方向に振り切っています。

強化学習を研究テーマにするなら FinRL、強化学習の学習コストを避けつつ AI 支援の恩恵を受けたいなら Vibe-Trading、という位置関係になります。

比較まとめ表

3 つの OSS を、選定時に見るべき軸で並べると次のようになります。

「学ぶこと」を目的にするなら TradingAgents / FinRL の順で候補が変わり、「回すこと」を目的にするなら Vibe-Trading が最も準備の少ない選択肢になります。

メンテナンス状況とライセンス

「今から採用しても大丈夫か」は、機能一覧と同じくらい重要な観点です。ここではリリース履歴・コミット頻度・ライセンスの実務的意味を短くまとめます。

リリース頻度と最終更新

repo-meta.json 上、最終 push は 2026-07-16、公開状態は public、archived / fork / disabled はいずれも false です。スター数 24,501・フォーク数 4,056 という数字は、単なる注目度だけでなく、実際にフォークして手元で試している開発者が一定規模で存在することを示唆します。

直近 3 か月に絞ると、v0.1.4 から v0.1.11 まで 8 リリースがアナウンスされており、日次で PR のマージが続いています。2026-07-13 には外部セキュリティ監査 10 項目のクローズが完了しており、単発の公開後放置型ではなく、継続的にメンテナンスが入っている OSS だと判断できます。バックテスト側でも 2026-07-15 の 10-PR 収束パッチで「causal & order-independent なリバランス」「終端クローズコスト計上」「fill-derived turnover 報告」「エクスポージャーキャップ強制」「有限値検証」といった正確性寄りの改善が入っており、単なる機能追加だけでなく品質改善に踏み込んでいる印象を受けます。

MIT ライセンスの実務的注意点

Vibe-Trading のライセンスは MIT です。商用利用は可能で、義務は基本的に「著作権表示および許諾表示を、ソフトウェアの全ての複製または重要な部分に記載する」ことに絞られます。無保証条項がある点は他の MIT ライセンス OSS と同様です。詳細は LICENSE で必ず原文をご確認ください。

自社プロダクトへの組込・SaaS への同梱・社内利用のいずれのユースケースでも、ライセンス起因のブロッカーは発生しにくいライセンス選択です。ただし、Vibe-Trading が呼び出す各種データプロバイダ・ブローカー API・LLM プロバイダには、それぞれ独自の商用利用条件があります。本体のライセンスとは別に、依存サービスの規約確認を忘れないでください。

導入を検討すべきケース／そうでないケース

ここまでの内容を踏まえて、Vibe-Trading が向いているケースと、注意が必要なケースを整理します。

向いているケース

• 自然言語プロンプトで研究フローを高速化したい: プロンプトから戦略コード生成・バックテスト・レポートまで一気通貫で回せるため、実験サイクルを短くしたいエンジニアに適しています。
• 複数市場・複数ブローカーに横串を通したい: A 株・米国株・香港株・インド・crypto・futures・forex に対して同一のインターフェースで研究したい場合、Broker Connectors とデータレイヤーが有力です。
• Shadow Account で過去取引を診断したい: 自身のブローカージャーナルから行動プロファイルを抽出し、反事実バックテストで振り返りたい場合、他 OSS では代替しにくい機能セットになります。
• MCP エコシステムに乗せたい: MCP サーバーとして LLM ホスト（Claude Desktop 等）から呼び出す前提のワークフローに組み込みたい場合、専用アダプタを書くよりコストが低くなります。
• 既製の 461 ファクターで PoC を回したい: 独自の DRL 学習を組む前に、Alpha Zoo で説明力の当たりを付けたいときに向いています。

向いていないケース・注意点

• 本番ライブトレードの主軸に据える場合は慎重に: Mandate や Kill Switch などの安全機構はありますが、リアルマネーの主軸戦略として全面依存するかは、必ず自組織のリスク管理体制と照らして判断してください。バックテストと本番運用のギャップは、どの OSS を選んでも常に残る問題です。
• 強化学習アルゴリズムの実装研究: 状態設計・報酬関数・アルゴリズム比較を主題にするなら FinRL のほうが適合します。
• 日本株を主戦場にする場合: 2026 年 7 月時点の README には日本株専用ブローカーコネクタの記載がないため、汎用 CSV や海外市場経由での運用可能性を事前に精査する必要があります。
• 公式でない情報源への注意: README では、X（旧 Twitter）アカウント VibeTrading_HKU、Virtuals プロジェクト 101845、トークン契約 0x640BDBF77b6447E8b7DB7894cED84BD1c40571f4 などは公式資産ではないと明記されています。プロジェクト側はトークンやミームコインをローンチ・承認しておらず、ウォレット接続や署名を求められた場合は無視するよう注意喚起しています。公式 Discord は https://discord.gg/6TdQnT5xcF のみとされているため、フィッシングリスクを避ける観点でもここは押さえておきたいポイントです。

まとめ：Vibe-Tradingを試すか判断するための3つの問い

最後に、Vibe-Trading の採用可否を短時間で判断するための 3 つの問いを提示します。

1. 自然言語プロンプトで研究フローを高速化したいか: 「エージェントに戦略コード生成からバックテストまで回させる」ワークフローが自分の PoC・研究に価値をもたらすかどうか。ここに強く同意できるなら Vibe-Trading の設計思想は追い風になります。
2. 既製の 461 ファクターや Shadow Account に価値を感じるか: Alpha Zoo で学習コストを払わず定量検証したい、あるいは自分の裁量取引を反事実バックテストで診断したい、というニーズがあるなら、TradingAgents や FinRL では埋めにくい差分を享受できます。
3. MIT ライセンス + 活発なメンテナンス状況で採用リスクを取れるか: 直近 3 か月で 8 リリース、日次 PR マージ、外部セキュリティ監査 10 項目クローズという水準を「十分に活発」と評価できるかどうか。MIT ライセンスの制約とセットで、自社の採用基準に照らして判断してください。

これら 3 つの問いに「Yes」と答えられる項目が多いほど、Vibe-Trading は自プロジェクトの候補として優先度を上げる価値があります。最終判断の前に、ぜひ公式一次情報をあたってください。

• 公式リポジトリ: https://github.com/HKUDS/Vibe-Trading
• 公式サイト: https://vibetrading.wiki/
• 公式ドキュメント: https://vibetrading.wiki/docs/
• PyPI パッケージ: https://pypi.org/project/vibe-trading-ai/
• 比較対象 OSS（TradingAgents）: https://github.com/TauricResearch/TradingAgents
• 比較対象 OSS（FinRL）: https://github.com/AI4Finance-Foundation/FinRL