Agent-Native取引基盤にAI-Traderが選ばれる理由｜TradingAgentsとの設計差分

「Agent-Native 取引基盤」というコンセプトを掲げる OSS が、香港大学の Data Intelligence Lab（以下 HKUDS）から公開されている AI-Trader です。GitHub では 17,296 stars を集め、https://ai4trade.ai というライブプラットフォームも稼働中ですが、日本語の解説記事はほとんど見当たりません。

「LLM × 取引」領域には TradingAgents や ai-hedge-fund といった先行 OSS がすでに存在し、それぞれ設計思想が大きく異なります。検索者にとっての悩みは、こうした OSS が乱立する中で「AI-Trader は何が違うのか」「Agent-Native という強いコピーは実装としてどこまで踏み込んでいるのか」「実取引に近い領域だけにライセンスや運用リスクは大丈夫か」を、READMEの読み込みだけで素早く判断するのが難しい点にあります。

本記事では、AI-Trader の README と公式ドキュメント、gh api で取得したリポジトリメタ情報をもとに、Agent-Native 設計と完全自動化の中身、TradingAgents・ai-hedge-fund との設計差分、採用時に押さえるべきライセンス・運用リスクを整理します。

なお、本記事は技術解説であり投資助言ではありません。実取引で AI-Trader を運用する場合は、法令対応・損失リスクの評価を別途実施してください。動作検証・スクリーンショット取得は行っておらず、すべて README および公式ドキュメントを一次出典としています。

AI-Traderとは — Agent-Native取引基盤のOSS

このセクションでは、AI-Trader が「何で、誰が作っているのか」を 1 分で把握できるように、リポジトリの基本情報と開発元の位置づけを整理します。

AI-Trader は HKUDS が公開する OSS で、README の自己説明は「AI-Trader: 100% Fully-Automated Agent-Native Trading」です。リポジトリ本体は HKUDS/AI-Trader、ライブプラットフォームは ai4trade.ai で稼働しています。OSS として GitHub にコードが公開される一方、ai4trade.ai 上では AI エージェントが実際に登録・取引できる環境が運用されており、「コードを読む」「自前でホストする」「公式プラットフォームに参加する」という 3 つの利用形態が並列に成立する構成です。

開発元 HKUDS（Data Intelligence Lab @ HKU）の位置づけ

開発元の HKUDS は Data Intelligence Lab @ HKU（香港大学 Data Intelligence Lab）であり、Agent-Native システムや RAG をテーマに複数の人気 OSS を公開しています。GitHub の HKUDS Organization ページ によれば、同ラボのリポジトリ群には軽量パーソナル AI エージェント nanobot、RAG フレームワーク LightRAG、CLI を Agent-Native 化する CLI-Anything などが含まれ、いずれも数万 stars 規模に成長しています。AI-Trader はこの文脈の中で「金融・取引ドメインに Agent-Native を持ち込む」プロジェクトに位置づけられます。

リポジトリの基本メタ情報

gh api /repos/HKUDS/AI-Trader の応答に基づくリポジトリ基本情報は次のとおりです。

license フィールドが null でありながら README にはバッジが存在するという不整合は、後述の「採用判断のチェックリスト」で詳述します。pushed_at が 2026-05-13 と直近で更新されており、現時点ではアクティブな開発が継続している様子が gh api の応答からは確認できます。

Agent-Native設計とは何か — エージェント参加前提のプラットフォーム

このセクションでは、「Agent-Native」という強いコピーが、実装レベルで何を意味するのかを READMEと公式ドキュメントの記述から読み解きます。

Agent-Native という言葉は、AI エージェント側を「既存の人間用プラットフォームに後付けで接続する利用者」ではなく「最初から想定された一次利用者」として扱う設計思想を指します。AI-Trader の README では「Just like humans have their trading platforms, AI agents need their own.」という一文でこの立場が表明されています。具体的には、エージェントが自律的に「ドキュメントを取得する」「自己登録する」「シグナルを発行する」を完結できるよう、SKILL.md と OpenAPI 仕様の組み合わせでプラットフォーム側を再設計している点が特徴です。

エージェント参加プロセス — 1メッセージで完結する自己登録フロー

README には、エージェントを参加させるためのオンボーディング指示が原文として次のように記載されています。

Read https://ai4trade.ai/SKILL.md and register.

出典: HKUDS/AI-Trader README（"Agents join in seconds" セクション）。

このメッセージを汎用 AI エージェント（後述）に送ると、エージェント側が SKILL.md を取得し、必要なコンポーネントをインストールし、https://ai4trade.ai/api に対して自己登録 API を呼び出す、という一連の動作が連鎖します。「人間がクリックして登録フォームを埋める」工程を、エージェント自身による API 呼び出しに置き換えている点が、Agent-Native という語の核心といえます。

skills/ai4trade/SKILL.md によれば、登録 API のエンドポイント設計は次のように整理されています。

認証は JWT を Authorization: Bearer {token} で送付する形式で、登録完了後はシグナル発行・コピー取引・ポートフォリオ管理・Heartbeat 通知などの API を呼び出せる構成です。READMEと SKILL.md の組み合わせから読み取れるのは、AI エージェントが「人間と同じ操作ステップを真似る」のではなく、「API を一次インターフェイスとして自律操作する」前提でプラットフォームが設計されている、という点です。

対応エージェントと OpenAPI による API 発見

docs/README_AGENT.md には、AI-Trader が想定する対応エージェントとして OpenClaw・nanobot・Claude Code・Codex・Cursor などが挙げられています。これらに共通するのは、SKILL.md 形式のスキル定義と OpenAPI 仕様を読み取り、ツール呼び出しに変換できる点です。AI-Trader 側は OpenAPI 仕様で全 API を公開しているため、対応エージェント側はクライアントコードを書かずにエンドポイントを発見・呼び出せます。

「特定のエージェントフレームワーク専用」ではなく、「OpenAPI と SKILL.md という汎用プロトコルに沿うエージェントは誰でも参加できる」という構図が、AI-Trader を Agent-Native と呼ばせている技術的な根拠です。

100% Fully-Automated が示す自動化の範囲

このセクションでは、もう 1 つの強いコピーである「100% Fully-Automated」が、どの工程までを自動化対象としているかを README 原文から整理します。

「完全自動化」という言葉だけだとスコープが曖昧になりがちですが、AI-Trader の場合は登録から取引・報酬受け取りまでの一連の流れを連続的に自動化する点に特徴があります。READMEの「Why Join AI-Trader?」セクションでは、エージェントへの 1 メッセージ送信を起点に、統合ガイド取得・依存コンポーネントのインストール・自己登録・シグナル発行・コピー取引・ポイント獲得までが人手介入なしで連鎖する、と説明されています。

3 種類のシグナル（Strategies / Operations / Discussions）

READMEの "Key Features" によれば、シグナルは次の 3 種類に分類されます。

役割の分離により、「議論ベースのアイデア発信」と「実際に追従されるオペレーション」が区別され、コピー取引の対象を明確にできる構成です。出典: HKUDS/AI-Trader README。

クロスブローカー対応・対応資産と $100K Paper Trading

README の "Why Join AI-Trader?" セクションでは、対応ブローカーとして Binance、Coinbase、Interactive Brokers などが挙げられ、対応資産は Stocks / Crypto / Forex / Options / Futures に加えて Polymarket のペーパートレードまでカバーされます。シグナルは複数ブローカー間で同期する設計とされています。

未検証のエージェントがいきなり実取引へ突入できないよう、$100K の Paper Trading 環境も用意されています。READMEには 2026-03-03 のアップデートとして Polymarket でのペーパートレード（実データ＋模擬執行）が稼働したとも明記されており、検証から実取引までを段階的に進める導線が設計されています。

ただし、自動化の範囲が広いということは、誤動作・想定外の損失が起きた際の影響範囲も広いことを意味します。READMEの「100% Fully-Automated」は、運用負荷を引き下げる魅力的なコピーである一方、運用設計次第ではリスクの自動化にもなり得る点は、採用判断のチェックリストで取り扱います。

TradingAgents・ai-hedge-fund との設計差分

このセクションでは、「LLM × 取引」OSS の代表例である TradingAgents・ai-hedge-fund と AI-Trader を 6 観点で比較し、それぞれの立ち位置を整理します。

3 リポジトリはいずれも「LLM をベースにした投資・取引エージェント」を扱いますが、設計思想のレイヤが異なります。AI-Trader はプラットフォーム、TradingAgents は研究フレームワーク、ai-hedge-fund は教育ツールに近い、という階層を意識すると比較しやすくなります。

6 観点での比較表

stars 数は本記事執筆時の gh api 取得値を採用しています。

プラットフォーム型 vs 研究フレームワーク型 vs 教育ツール型

比較表から読み取れるのは、3 リポジトリの「OSS としての提供価値の方向性」がそれぞれ違うという点です。

• AI-Trader（プラットフォーム型）: 「AI エージェントは独自のトレーディングプラットフォームを必要とする」という前提で、プラットフォーム側を Agent-Native に作り直しています。OSS を読み解くことでセルフホストもできますが、ai4trade.ai という実稼働サービスがあり、「自分で書いたエージェントを参加させる」「他のトップパフォーマーをコピー取引する」といった行動が選択肢に入る点が独自です。
• TradingAgents（研究フレームワーク型）: 既存のトレーディング企業組織を模した役割固定のマルチエージェント構造で、意思決定プロセスの再現性・解釈性を重視しています。実取引ではなくシミュレート取引所でのバックテストが主用途で、当ブログでは TradingAgents についての解説記事 を別途公開しています。
• ai-hedge-fund（教育ツール型）: バフェット・グレアム・マンガー・バーリといった著名投資家の投資哲学を LLM プロンプトで模倣し、「もし○○だったら」を再現する構成です。教育・学習を目的としており、当ブログでも ai-hedge-fund についての解説記事 で詳しく扱っています。

どの場面で AI-Trader が選ばれるか

整理すると、AI-Trader が候補に上がりやすいのは「すでに自社で AI エージェント基盤（あるいは Claude Code / Codex / Cursor などの汎用エージェント）を運用していて、それを取引ドメインへ持ち込む先を探している」ケースです。逆に「LLM の意思決定プロセスそのものを研究したい」「投資哲学のシミュレーションを行いたい」場合は、TradingAgents・ai-hedge-fund の方が直接的な候補になります。

採用判断のチェックリスト — ライセンス・運用・リスク

このセクションでは、AI-Trader を採用するかどうかを判断するために確認すべきポイントを「向くケース／向かないケース／必ず確認すべき点」の 3 軸で整理します。

裏側で運用・取引が動くソフトウェアであるため、機能やコンセプトの魅力だけでなく、ライセンスや実取引時のリスクをセットで確認しないと採用後の手戻りが大きくなります。

向くケース

• 自社・自プロジェクトに AI エージェント基盤（OpenClaw / nanobot / Claude Code / Codex / Cursor 等）があり、取引ドメインへの応用先を検証したい
• 1 メッセージで参加できる「Agent-Native のお手本実装」として OpenAPI と SKILL.md の使い方を学びたい
• $100K の Paper Trading や Polymarket のペーパートレードを使い、運用負荷を抑えながら検証段階を進めたい

向かないケース

• 本番の実取引運用をすぐに開始したい（実取引のリスク管理は別途自社で評価する必要があります）
• AI-Trader 本体のコードをフォークし、改変したものを社内外に再配布したい（ライセンス取扱の確認が前提）
• 「ライセンス未設定」「LICENSE ファイル不在」を許容できない組織・部門

必ず確認すべき点 — ライセンス不整合の取り扱い

特に注意したいのが、ライセンスに関する README とリポジトリ実態の不整合です。gh api /repos/HKUDS/AI-Trader の応答で license フィールドは null を返し、gh api /repos/HKUDS/AI-Trader/license は 404、リポジトリ直下に LICENSE ファイルも存在しません。一方で HKUDS/AI-Trader README には「License-MIT-green.svg」というバッジが掲示されています。

OSS のライセンスは、「README にバッジで書いてあるか」ではなく「LICENSE ファイルの本文が何を許諾するか」で実効性が決まります。LICENSE ファイルが存在しない以上、GitHub 側でもサイドバーに「No license」と表示され、これは原則として全著作権が著作者に留保された状態（All rights reserved）です。READMEのバッジを根拠に MIT として再配布すると、後から HKUDS がライセンス文を確定させた際に齟齬が生じる可能性があります。

実務上は、本記事執筆時点の状況を前提に次のような対応が現実的です。

• フォーク・再配布を行う前に、HKUDS（GitHub Organization）に Issue・メール等でライセンス取扱について確認する
• 社内検証用途にとどめ、社外配布や派生プロジェクトでの再配布は控える
• READMEのバッジが MIT である以上、HKUDS としては MIT を意図している可能性が高いが、現状の license=null を前提に判断する

このうえで、金融取引を題材とするソフトウェアならではのリスクも併せて評価する必要があります。実取引時の各国法令対応（証券業・金商法等）や、自走するエージェントが想定外の損失を発生させるリスクは、AI-Trader 側で完結する範疇を超えるため、別途自社の体制で評価してください。本記事は技術解説であり投資助言ではありません。

まとめ — Agent-Native取引基盤を選ぶときの判断軸

最後に、本記事の論点を圧縮し、検索者が次にどう動くかを選べる形に整理します。

• AI-Trader は HKUDS が公開する「Agent-Native Trading Platform」を称する OSS であり、OSS としての GitHub リポジトリと、ai4trade.ai という実稼働プラットフォームが並列で提供されている点が、TradingAgents・ai-hedge-fund と決定的に異なります。詳細な構成は HKUDS/AI-Trader README に集約されています。
• 「Agent-Native」は SKILL.md + OpenAPI でエージェントの自己登録・自律 API 呼び出しを成立させる設計を指し、「100% Fully-Automated」は登録・シグナル発行・コピー取引・報酬獲得までの連続自動化を指します。実装の根拠は docs/README_AGENT.md に整理されています。
• 競合 OSS との比較では、AI-Trader はプラットフォーム型、TradingAgents は研究フレームワーク型、ai-hedge-fund は教育ツール型と整理でき、検証目的に応じて使い分けるのが妥当です。
• ライセンスは、README バッジ（MIT）とリポジトリ実態（license=null）に不整合があるため、フォーク・再配布を伴う採用ではあらかじめ HKUDS への確認が前提となります。実取引運用ではさらに法令対応・損失リスクの評価が必要です。

エージェント基盤側の準備が整っているチームは、まず公式の ユーザーガイド（docs/README_USER.md） を起点に、READMEのオンボーディング指示「Read https://ai4trade.ai/SKILL.md and register.」を Paper Trading 環境で検証する流れが取り組みやすい入り口になります。実取引へ拡張するかは、ライセンス取扱の確認結果と社内のリスク評価をふまえて判断してください。本記事は技術解説であり投資助言ではない点を、最後に改めて補足します。