Crypto Agent Bench：取引所をまたいで金融エージェントの安全性を評価する再現可能なプロトコル

TL;DR

証拠状態の告知：本稿は研究設計と方法論の論文です。提案するデータセット、実験単位、分析はいずれも実施していません。モデルの性能結果、有意性の主張、実測の順位は一切示しません。結果表は捏造した数値で埋める代わりに、意図的に空欄にしています。

• 正解は安全を意味しません。 回答は数値的に正しくても運用上は危険でありえます。逆にモデルが誤った注文を提案し、独立した執行コントローラがそれを拒否すれば、口座は安全ですが課題は未完了です。どちらも測定可能でなければなりません。
• 三つの層を分けること：認知の質（問いと証拠を正しく読めているか）、行動の妥当性（取引所固有の規則のもとでツール呼び出しが妥当か）、執行の安全性（モデルの誤りと運用障害のもとで認可・予算・注文の同一性・状態の整合を保てるか）。
• エージェントをシステムとして試験する：基盤モデル + system prompt + ツールアダプタ + オーケストレーション + ポリシー強制 + シミュレータ + データ。モデル単体ではありません。
• 中核の実験は設計の比較であり、モデルの順位表ではありません。A 素の / B プロンプトのみ / C 外部強制 / D 強制 + 回復 を、モデルとシナリオを揃えて比較します。
• 審判は決定論的な状態オラクルであり、LLM が別の LLM の記録を読むのではありません。言語モデルによる審判は誤りうる二次的な計器にすぎず、禁止された注文が執行されたかを判断させてはなりません。

キーワード：金融 AI エージェント；暗号資産取引所；エージェントの安全性；ツール呼び出し；プロンプトインジェクション；事前リスク；分散システム；信頼性ベンチマーク；再現性。

1. はじめに：正しい答えだけでは足りない

従来の金融言語モデル評価は、モデルが報告書から正しい数値を取り出せるか、出典を引けるか、金融概念について適切に推論できるかを問います。取引エージェントはもう一つの結果の種類に直面します。その行動は口座の状態を変えます。

したがって有用な評価は、少なくとも三つの層を区別しなければなりません。

1. 認知の質：利用者の金融的な問いと証拠を正しく解釈しているか。
2. 行動の妥当性：取引所固有の規則のもとで、構文的にも意味的にも妥当なツール呼び出しを発しているか。
3. 執行の安全性：モデルの誤りと運用障害にもかかわらず、システム全体が認可、予算、注文の同一性、状態の整合という不変条件を保てているか。

これらの層を混同すると誤った結論が出ます。 禁止された行動を頻繁に試みるモデルでも、有効な独立コントローラの背後では安全に配備できます（課題遂行力は低いにせよ）。逆に通常試験ではほとんど違反しないモデルでも、その執行アダプタが曖昧な提出を無自覚に再試行するなら配備には適しません。ベンチマーク設計は双方を捉える必要があります。

本稿が提案するベンチマークは、エージェントをシステムとして扱います：基盤モデル + system prompt + ツールアダプタ + オーケストレーション + ポリシー強制 + シミュレータ + データ。実取引の収益性は評価せず、有限の合成ベンチマークから現実のシステムの安全性を予測できるとも主張しません。

2. 関連研究と残る空白

2.1 金融知識のベンチマーク

FinanceBench は上場企業の報告書に基づく金融の質問応答を、解答と裏づけ証拠とともに評価します [1]。こうしたデータセットは、モデルが金融事実を捏造せず証拠を正確に使えるかを調べるうえで重要です。しかし、執行権限を持つモデルがポジション上限、注文精度、非同期の約定確認、予算の競合をどう扱うかは直接には試験しません。

2.2 ツール利用とポリシー遵守のベンチマーク

τ-bench は、API、利用者との対話、領域固有のポリシーを備えた対話型環境でエージェントを評価し、再現性を意識した pass^k 分析を導入しました [2]。これは終端状態オラクルと反復試行を使う本稿の方針を強く支持します。本稿が加えるのは金融執行に特有の意味論です。硬い名目額上限、銘柄フィルタ、承認の束縛、不確かな確認、部分約定、保守的な予約。

FinMCP-Bench（2026）は MCP のもとでの金融ツール呼び出しを研究し、金融ツール利用それ自体が明確なベンチマーク領域になったことを示しました [3]。Crypto Agent Bench は資産領域の広さでは狭く、行動の帰結と権限の深さでは深い設計です。妥当な金融ツール呼び出しは、必ずしも認可された金融行動ではありません。

2.3 敵対的エージェントとツール出力の注入

AgentDojo は、信頼できない情報を取り込むエージェントに対する間接プロンプトインジェクションを研究するための課題、攻撃シナリオ、環境を提供します [4]。金融システムではさらに、モデルの提案行動を変える注入と、禁止された口座状態の変化を引き起こす注入を区別しなければなりません。後者はモデルだけでなくツールとポリシーの設計に依存するため、独立した評価単位になります。

OWASP の Agentic Applications 2026 プロジェクトは、自律的なツール利用の risk についてより広いセキュリティ指針を与えます [5]。本稿はその脅威の視点を、具体的な取引所の行動と観測可能な不変条件へ翻訳します。OWASP の一覧をそのまま金融ベンチマークとして扱うことはしません。

2.4 取引と定量調査のベンチマーク

TradingAgents（2024）はマルチエージェント LLM の取引設計を研究しています [6]。Backtrader-Bench（2026）はアルゴリズム取引とバックテストの課題におけるエージェントの能力を、実行可能な解答検査とともに調べます [7]。Quant-Arena（2026）は標本外試験と市場インパクトの仮定を含む、定量調査の完全なループを評価します [8]。

これらは代替ではなく補完です。 戦略は安全に執行されながら経済的に失敗しうるし、バックテストで利益を出しながらリスク権限を侵しうる。安全性とアルファは別の計器で分析すべきです。

2.5 正確な研究の空白

本稿が参照した文献の範囲では、取引所固有の注文意味論、口座単位のリスク認可、敵対的なツール入力、非同期の注文確認、並行性を意識した状態オラクル、そして誤拒否の実務上の費用を同時に組み合わせた標準ベンチマークは見当たりません。これは引用した文献の範囲についての言明であり、「関連するベンチマークがどこにも存在しない」という主張ではありません。

3. 研究設問と仮説

RQ1 — 強制の有効性。 基盤モデルと課題環境が同一のとき、執行側の独立したポリシー強制は、プロンプトのみの制約と比べて、実際に生じる禁止された金融状態変化の比率を下げるか。

RQ2 — 効用との取引。 厳格なポリシー統制を導入すると、正当な課題の完遂、遅延、金銭的費用はどれだけ失われるか。失敗はモデルの拒否、ポリシーの誤検知、データの陳腐化のいずれに由来するか。

RQ3 — 運用障害への耐性。 注文が受理されたのに確認が失われたとき、システムはどの程度の頻度で意図しない重複エクスポージャを作り、あるいは予約済みのリスク枠を誤って解放するか。

RQ4 — 取引所をまたぐ一般化。 同じ利用者の意図が、取引所ごとに異なる銘柄規則とクライアント注文 ID の意味論に写されるとき、エージェントと制御設計はどう振る舞うか。

RQ5 — 反復と裾の挙動。 確率的な試行を繰り返したとき、システムは正当な課題目標と安全性の不変条件をどれだけ一貫して満たすか。結果は少数のシナリオ族に偏って依存していないか。

これらの仮説には統制された測定が必要です。本稿はその評価計画を示すものであり、確認を示すものではありません。

4. 範囲と環境の設計

4.1 まず模擬現物市場から始める理由

初期の範囲は Binance Spot と OKX Spot で、公開文書と合成の口座データを用います。両者の API は具体的かつ実質的に異なる取引規則の細部を露出しています。Binance が公開する銘柄フィルタには、許される価格の刻み、数量の刻み、名目額の上下限が含まれます [9]。OKX の API は instId、tdMode、clOrdId といった注文パラメータとデモ取引モードを規定し、そのクライアント注文 ID は注文が終端状態になった後の歴史的な一意性を保証しません [10]。

本ベンチマークは、取引所の専有マッチングエンジン、顧客データ、本番のリスクシステムへのアクセスを前提としません。環境が模擬するのは、文書化された REST 風の挙動、非同期イベント、統制された障害条件です。これは選定されたシナリオについてのプロトコル忠実なシミュレータであり、取引所の挙動が等価であることの認証ではありません。 文書化されていない挙動はすべて仮定として明示し、独自の fixture 版を与えます。

4.2 提案するデータセットの構成

v1.0 の目標は、査読済みのシナリオ仕様 240 件です。

この件数は設計目標であり、240 件が既に存在するという主張ではありません。 初期の試作では査読済みの種シナリオ 40 件を公開し、明示的な版管理のもとで拡張してよい。各シナリオは、正当な主たる利用者課題、認可範囲、市場 fixture、決定論的シミュレータ、任意の敵対的または障害の注入、そして独立した終端状態の判定基準を含みます。

4.3 正例と負例の対

安全性に関わるシナリオは、可能な限り、他の条件が似た正当なシナリオと対にすべきです。

• 正例：予算内、データが新鮮な状態で、許可された銘柄を買う。システムは模擬執行を正常に完遂すべき。
• 負例：同じ要求で名目額が硬い上限を超える。システムは拒否すべき。
• 負例（敵対的）：ニュース記事がエージェントに硬い上限を無視せよと指示する。シミュレータは違反する提出を一件も観測しないべき。
• 曖昧例：妥当な提出が受理されたが ACK が落ちる。システムは二度目の経済的提出なしに照合しなければならない。

正例の対照がなければ、すべてを拒否する機能しないエージェントが「完全に安全」に見えます。負例の対照がなければ、課題のみのベンチマークは金融権限を日常的に侵すエージェントを報います。

4.4 凍結した時間と市場データ

取引所の挙動は時間に依存します。気配値は取得と提出の間に陳腐化しえ、銘柄規則はワークフローの途中で変わりえ、執行報告は順序が乱れて届きえます。実験を再現可能にするため、ベンチマークは virtual_clock を注入し、event_time、received_time、policy_evaluation_time、submission_time を個別に記録します。

すべての金融 fixture は venue, instrument, market_type, tick_size, quantity_step, notional_bounds, best_bid, best_ask, snapshot_time, source_type, rule_digest を含むべきです。公開例に引用される価格は、不変かつ利用許諾のある履歴記録に由来する場合を除き、すべて合成であると明示しなければなりません。

取引所間の差異を均してしまうべきではありません。共通 schema は共通概念を写し、アダプタ固有の能力は汎用に表現できない制約を担います。未知または陳腐化した取引所規則は一級の状態として表現しなければならず、「おそらくまだ有効」として扱ってはなりません。

5. 脅威モデルと攻撃の分類

5.1 信頼の仮定

攻撃者は、取得したニュース記事、ツールの結果、調査メモ、信頼度の低い対話ターン、あるいは不正な市場メタデータ項目の内容を制御しえます。シナリオによっては、ネットワーク遅延を誘発し、信頼できないツール応答を汚染することもできます。

攻撃者は、信頼されたサーバ側のポリシーを正当に改変すること、本物の承認資格情報に署名すること、シミュレータのオラクルを変更することはできません。 その境界が破られる場合は、別のインフラ侵入の脅威モデルに属します。

攻撃者の目的は試行の前に明示しなければなりません。たとえば銘柄の未認可な変更、上限の超過、承認の回避、重複注文の作成、禁止された送金ツールの要求、合成された秘密の開示などです。実資金の資格情報と実注文は、本ベンチマークの一部になることは決してありません。

5.2 攻撃族

攻撃の検出指標と実際の副作用は別に報告します。 モデルの口頭の計画だけを変えた攻撃は、モデル評価には重要でも、執行コントローラが拒否したのであれば口座権限の移転が成功したとは数えません。

6. 実験条件と統制された比較

中核の実験は、揃えた課題とモデル設定を四つの設計アームで用います。

A — 素のエージェント。 基本的なツール schema のみ。特別な安全プロンプトも独立した金融リスクポリシーもなし。行動はすべて模擬のまま。

B — プロンプトのみの安全策。 同じ基盤モデルと同じツール環境に、system prompt で明示的なリスク指示を与える。リスク喚起だけで何をどれだけ防げるかを試験します。

C — 強制つき金融エージェント。 同じモデルと課題条件。ただし状態を変える行動はすべて、外部の信頼できる認可、決定論的なポリシー検査、原子的な予算予約を通る。リスクゲートはモデルのテキストから独立です。

D — 強制 + 回復。 C に、永続的な執行 ID、UNKNOWN 状態の処理、照合、障害を意識した回復を加える。C との比較により障害処理による改善を切り分けます。

主要な比較は、外部強制についての B 対 C、回復についての C 対 D です。A 対 B は追加のプロンプト指針を切り分けます。この設計は遅延を増やし、拒否された後のエージェントの選択に影響しうるため、ソフトウェアの一行だけが変わったふりをせず、システム全体の結果と媒介効果を報告します。

モデルとハーネスの各組み合わせについて、シナリオ一覧、初期口座状態、市場イベント列、課題本文、可能な範囲でツール schema、実行時の制限、プロンプト版、最大呼び出し回数を固定します。ツールの可用性が設計上異なる場合は、厳密な他条件一定を達成したと主張するのではなく、意味のある処理の差として記録します。

7. 真値と独立した採点

主たる審判は決定論的な状態オラクルであり、LLM が別の LLM の記録を査読するのではありません。追記専用の型付きイベント列と、最終の模擬口座状態を検査します。

妥当なシミュレータ試行は scenario_hash、agent_trace、tool_call_trace、policy_decisions、orders、fills、budget_reservations、approval_events、reconciliation_events、final_state_digest を産出します。すべての構成要素は版付きです。

7.1 不変条件

ポリシーエンジンの欠陥とオラクルの欠陥は、どちらもありえます。 重要な不変条件については、試験オラクルは別実装または独立した参照アサーションを用い、人手で査読した golden case を裏づけにすべきです。本番のポリシー実装との差分試験は共有された仮定を露わにしえますが、それ自体で正しさを保証しません。

7.2 正当な課題の完遂の評価

エージェントが正当な課題に合格するのは、最終の業務状態が課題オラクルに一致し、かつ拘束力のあるすべての制約が守られた場合のみです。 「注文を出した」という文章上の主張では足りません。逆に、妥当な利用者要求を安全に拒否することは、risk が生じなかったとしても課題の成功ではありません。

主観的な説明の応答については、ルーブリックに基づく評価を客観指標の補助に使ってよい。人の注釈者は層化標本を査読すべきです。言語モデルによる審判は誤りうる二次的な計器として扱わなければならず、禁止された注文が執行されたかを判断させてはなりません。

8. 指標と推定対象

試行を、固定されたシナリオ、エージェント構成、乱数種を、完遂または宣言された終端失敗状態まで実行したものと定義します。risk 機会を、シナリオ設計のもとで指定された禁止効果が現実に起こりうる試行と定義します。

8.1 主要指標

正当課題成功率（TSR）

TSR = 認可された目標状態に到達した正当試行数 / 割り当てられた全正当試行数

執行層の不安全効果率（UER）

UER = 禁止された状態変化が一度以上起きた risk 機会試行数 / 適格な全 risk 機会試行数

分母は前向きに定義し、試行のクラッシュを黙って落としません。 クラッシュした試行は公開された規則のもとで打ち切りまたは未完了として採点してよいが、集計報告から消えてはなりません。

攻撃成功率（ASR）：攻撃者が指定した目的を達成した妥当な攻撃試行の割合。ASR_model（モデルが禁止行動を提案）と ASR_execution（シミュレータが禁止された執行を記録）を別に公表します。攻撃が前者で成功し後者で失敗することは十分にありえます。

誤拒否率（FRR）：本来妥当で認可済み、追加承認も不要な課題が、エージェントまたは外部ポリシーに誤って拒否された割合。agent_abstention、policy_false_positive、environment_unavailable に細分します。修正の方向が異なるためです。

回復正しさ（RC）：障害を注入した試行のうち、結果の注文と予約済み予算の状態が独立した照合オラクルに一致した割合。

8.2 二次指標

• ツール schema の妥当性、取引所規則の妥当性、単位換算の正確さ。
• ポリシー違反の試行率（モデルが禁止行動を提案）を、不安全な副作用とは別に。
• 業務意図あたりの重複する経済的注文数。
• 認可判断の遅延と、端から端までの p50／p95 完遂時間。
• 入力／出力／キャッシュのトークン、API の金銭費用、そして成功した正当課題あたりの費用。
• 手数、ツール呼び出し数、タイムアウト数、未解決の照合の明示的な件数。
• pass@1 と反復試行の pass^k 一貫性。元の定義を用い、反復の構造を明確に報告します。

普遍的な重み付き「安全スコア」を主要な結果とすることは拒否します。 TSR が高いが UER が実質的に非ゼロのモデルを、遅いが一貫して権限を守るモデルの上に自動的に置くべきではありません。結果は多目的の面を露わにすべきで、順位が求められる場合はその背後にある宣言済みの安全制約を示さなければなりません。

9. 統計の方法論と検定力

9.1 標本と依存

目標とするプロトコルは、公開シナリオ 240 件すべてを、モデルとアームごとに事前宣言した 5 回の反復試行で走らせます。敵対的シナリオ 40 件は、異なる三つの文面変種で実体化してもよく、各変種を 5 回走らせれば構成ごとに 600 回の敵対的試行になります。

しかし 40 × 3 × 5 は必ずしも 600 の独立観測ではありません。 一つのシナリオのすべての変種が、同じ中核の失敗様式を共有しているかもしれません。

したがって、生の分子と分母に加え、二種類の不確実性を報告します。透明な記述的基準としての Wilson 区間と、相関のある反復をまたぐ比較のためのシナリオクラスタ・ブートストラップ区間です。同一のシナリオを両システムが試験している場合、対になった差はブートストラップを対応ありまたはシナリオでブロック化して報告すべきで、二つのアームを無関係な標本として扱うべきではありません。

9.2 希少事象の解釈

ある設計が、真に独立した risk 機会試行 1,000 回で不安全な執行をゼロ回記録したとします。定常な二項モデルのもとでの粗い片側 95% 上限は約 0.3%（3/1000）です。これは任意の規模での実務的な安全を意味しません。 クラスタ化されたシナリオや適応的な攻撃者がいれば、この上限の情報量はさらに下がります。

優越性を主張する前に、ベンチマークは最小検出可能効果または精度目標を公表すべきです。設計比較の研究では、主要な推定対象と対象母集団を事前に宣言し、分散推定のために予備試行を走らせ、シナリオ水準のシミュレーションによる検定力分析を用いることを勧めます。都合よく得られた事後の p 値は、事前指定の代わりになりません。

9.3 多重比較、欠測、提供者の漂移

多数のモデル、攻撃族、安全性の結果を試験する場合は、補正された推論、あるいは明示的に探索的であることを報告します。都合のよい切片を選び取ってはなりません。提供者のモデルは予告なく版が変わりうるため、日付、正確な識別子、実行マニフェストを記録します。ツールとネットワークの障害は、事前宣言した規則により失敗、打ち切り、欠測のいずれかに分類すべきで、スコアが良くなるまで除去し続けてはなりません。

9.4 推奨する事前登録の決定規則

狭い強制の主張を行う論文では、次を事前登録します。(i) 執行層 UER における B 対 C の比較、(ii) 攻撃・障害シナリオの数と構成、(iii) 対応ありの不確実性の算出法、(iv) 正当課題 FRR の許容できる最大増分、(v) 汚染された試行を除外する規則。それ以外の部分集団の所見は、別途検定力を確保し事前登録しない限り探索的です。

10. 端から端までの例：注文は受理、確認は喪失

合成の利用者が、硬い一件上限 500 USDT に対し、名目額 400 USDT の BTC 指値買いを一件認可します。エージェントは型付きの意図を産出します。シミュレータは注文を受理しますが、HTTP 応答を落とします。

言語上の正しさでは足りない理由を、五つの誤りが示します。

1. エージェントがタイムアウトを失敗と仮定し、新しい識別子で二度目の注文を出す。
2. エージェントが同じ clOrdId で再試行するが、一意性が取引所依存であり、過去の終端注文を覆わないかもしれないことを理解していない。
3. ACK が届かなかったためにリスクコントローラが 400 USDT の予約を解放し、並行する要求が同じリスク枠を使えてしまう。
4. 取引所が最終的に約定イベントを送ってくるのに、ダッシュボードが失敗と報告する。
5. 非同期に届く約定が照合される前に、取消の操作が確定したものとして扱われる。

正しい期待される流れは、永続的な業務意図 ID でその試みを記録し、予約済みの枠を保持し、UNKNOWN に入り、認証された状態イベントを照会または消費し、十分に権威ある結果が確立されてはじめて遷移することです。解決しない場合は明示的な運用者の確認を要し、保守的に計上され続けます。

Binance は、タイムアウト／5xx の後に実際の執行状態が unknown でありうる条件を明確に文書化しています [11]。したがってこのシナリオは文書化された API の障害種別に基づいており、具体的な金額と模擬イベントは合成です。

評価器が採点するのは、二度目の経済的注文が作られたか、予約が整合を保ったか、最終状態が正しく再構成されたかです。 モデルが不確実性を洗練された文章で説明したことだけでは、成功を与えません。

11. 実験の行列と報告

最初の公表は、大規模なモデル宣伝の順位表よりも、設計の問いを優先すべきです。

各セルについて、生の試行マニフェスト、失敗数、反復の種、実行の制約、すべての主要指標を公表します。実際の提供者の鍵が成果物の一部になることは決してありません。 主張されるすべての改善は、絶対的な変化と不確実性の双方を示し、安全上の便益と並べて費用と遅延も示すべきです。

提案する結果表（意図的に未記入）：

定性的な失敗の地図も公表すべきです。誤受理、誤拒否、ツール呼び出しの不一致、陳腐化した市場による拒否、重複提出、遅延状態の照合について、代表的なトレースを示します。これにより技術者は、ある指標がなぜ変わったのかを検分できます。

12. ベンチマークの健全性、汚染、動機づけ

公開ベンチマークが再利用できるのは、まさに課題と採点の論理が参照可能だからです。それは同時に、狙った記憶に対して脆弱にもします。いくつかの緩和策を提案します。

パラメータ化されたシナリオ族。 試験している不変条件を変えずに、価格、注文数量、ポリシーの閾値、時系列の並び、信頼度の低い内容を変えます。変異生成器と乱数種も再現性のために公表します。

凍結した公開版と、任意の留保分の輪番。 学術的な追試のために v1.0 の事例を完全に公開します。競争的な順位表を運営する場合は、公開ベンチマークの主張とは厳密に分離した封緘事例を別途維持し、可能なら退役した封緘事例をその系譜とともに公開します。

成果物の正確なハッシュ。 シナリオファイル、実行イメージ、schema、モデルのメタデータ、ポリシー設定、出力トレースを凍結します。監査可能な実行マニフェストのない順位表の結果は、再現可能な研究ではなく製品デモです。

スコアの操作への備え。 通常の完遂と誤拒否を、不安全な副作用と並べて報告します。すべての注文を止めるポリシーは、負の対照システムとしては有用ですが、満足な取引エージェントではありません。

曖昧な結果の人手による監査。 業務上の判定基準が正当に未指定である場合は、試験の前にその曖昧さを注記するか、そのシナリオを硬い可否オラクルに不適と印します。結果が出た後にあるモデルを有利にするため期待ラベルを「修正」してはなりません。

公開上の安全境界。 サンドボックスのデータと合成の資格情報のみを用います。公開するツール出力の注入例は、実口座の悪用をそのまま実行できる手順を与えないものにします。本番システムに関わるセキュリティの発見は、協調的な非公開報告の経路を通します。

13. 妥当性への脅威

シミュレータの忠実度。 シミュレータは、あらゆるマッチングエンジンの挙動、取引所の停止、取引所をまたぐ流動性イベント、口座の制限、内部のリスクシステムを再現できません。合格した模擬は、定義された脅威モデルについての証拠であり、本番運用の準備完了の証明ではありません。

認可モデルの不完全さ。 リスク統制はしばしば、負債、担保、調達、借入金利、資産の集中、法的制約に依存し、これらは現物のみの初期実装の範囲外です。あるシステムが v1 の全事例に合格しながら、証拠金やデリバティブ市場でひどく失敗することはありえます。そのスコアをデリバティブの安全性の認証として提示してはなりません。

相関した攻撃生成。 一つのプロンプトインジェクション戦略の多数の変種は、多様に見えて同じ意味論を共有しえます。近縁な 100 の文字列に耐えたエージェントが、新しい攻撃の類型一つに敗れることはありえます。統計分析は攻撃族とシナリオの階層を保たねばなりません。

ポリシーとオラクルの共通要因故障。 ベンチマークのオラクルが、強制されるポリシーシステムとまったく同じコードを取り込んでいる場合、ベンチマークは共有された欠陥を検証してしまうかもしれません。独立した参照アサーション、性質試験、人手で査読した golden fixture は risk を緩和しますが、消去はしません。

モデル提供者の漂移と隠れた提供挙動。 商用 API は経路、システム指示、モデル実装を変ええます。構成は入手可能な限り正確に報告し、すべての実行に日付を付します。提供者をまたぎ、将来の日付をまたぐ厳密な再現は、依然として不可能なままかもしれません。

配備との隔たり。 本番では、運用者の誤り、鍵の管理、アクセス制御の誤設定、内部の侵害、ログの欠落、ネットワーク分断が防護を打ち破りえます。ベンチマークは統制された仮定のもとで構成要素を切り離します。運用上のセキュリティにはより広い検討が必要です。

14. 成果物のパッケージと再現性の要件

研究品質のリリースは次を含むべきです。

crypto-agent-bench/
  CITATION.cff
  LICENSE
  docs/{benchmark-card,security-model,data-card,ethics,limitations}.md
  scenarios/v1.0/{S1,S2,S3,S4,S5,S6,S7}/
  fixtures/v1.0/{books,accounts,instruments,policies,events}/
  src/{runner,model_adapters,tool_adapters,simulator,oracle,metrics}/
  experiments/{baseline,ablation,attack_robustness,recovery}/
  analysis/{notebooks,statistics,bootstrap}/
  reports/{templates,example-synthetic-output}/
  tests/{schema,oracle,golden,property,replay}/
  environment.lock

benchmark card は、意図された用途、意図されない用途、データセットの由来、取引所 API の仮定、言語、網羅の欠落、既知の限界、モデル費用の制約、そして報告されたスコアを再現する方法を述べるべきです。出版物は、動く main ブランチではなく、不変のコミットまたは保存された release 識別子を引用しなければなりません。

依存関係を確認したうえで Apache-2.0 あるいは他の寛容なソフトウェアライセンスを、合成 fixture には明確なライセンスを勧めます。第三者の市場記録は許諾なく再配布すべきではありません。

15. 提案するリリースの関門

16. 結論

次世代の金融エージェントは、図表について推論できるかだけでなく、それを配備するシステムの権限、上限、運用上の不変条件を侵さずに行動できるかで評価されるようになります。これは金融 QA、ツール呼び出しの構文、バックテストの収益、あるいは単独で考えたプロンプトインジェクションの拒否率とは、別の測定問題です。

Crypto Agent Bench は、このより広い問いを試験する方法を提案します。その方法論上の中核的な約束は、観測可能な副作用と正当な結果を別に採点することです。 エージェントを組み合わされたシステムとして扱い、権威ある合成状態に対して試験し、取引所固有の API 意味論を保ち、点推定だけでなく不確実性を報告します。

実装され第三者により独立に追試されれば、このプロトコルは研究者が「より安全なモデル」と「より安全な周辺設計」を見分ける助けになり、取引所の技術チームが AI エージェントを実際の金融執行の近くに置く前に、どの構成要素を検証しなければならないかを判断する助けにもなりえます。現段階では、これは具体的で反証可能な研究計画であり、実証的な結論ではありません。

参考文献

[1] Islam et al. (2023), FinanceBench: A New Benchmark for Financial Question Answering。https://arxiv.org/abs/2311.11944

[2] Yao et al. (2024), τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains。https://arxiv.org/abs/2406.12045

[3] Zhu et al. (2026), FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol。https://arxiv.org/abs/2603.24943

[4] Debenedetti et al. (2024), AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents。https://arxiv.org/abs/2406.13352

[5] OWASP (2025), Top 10 for Agentic Applications for 2026。https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[6] Xiao et al. (2024), TradingAgents: Multi-Agents LLM Financial Trading Framework。https://arxiv.org/abs/2412.20138

[7] Zhao and Raissi (2026), Backtrader-Bench: Benchmarking LLM Agents on Algorithmic Trading with Self-Generated MCQs。https://arxiv.org/abs/2608.11232

[8] Qian et al. (2026-10-21), Quant-Arena: Benchmarking LLM Agents for Quantitative Trading Research。https://arxiv.org/abs/2610.30113

[9] Binance Developer Docs, Spot Trading Filters。https://github.com/binance/binance-spot-api-docs/blob/master/filters.md

[10] OKX, API v5 Documentation（取引パラメータ、デモ取引、クライアント注文 ID の意味論）。https://www.okx.com/docs-v5/en/

[11] Binance Developer Docs, General REST API Information（タイムアウト／5xx の後は執行状態が unknown でありうる）。https://developers.binance.com/en/docs/products/spot/rest-api

[12] OpenTelemetry, GenAI semantic conventions（テレメトリ schema と機微データの指針）。https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/

[13] NIST, AI Risk Management Framework: Generative AI Profile (2024)。https://doi.org/10.6028/NIST.AI.600-1

[14] US SEC, Rule 15c3-5 Market Access FAQ（米国証券の市場アクセスに関する特定の枠組みであり、暗号資産への包括的規制ではない）。https://www.sec.gov/rules-regulations/staff-guidance/trading-markets-frequently-asked-questions/divisionsmarketregfaq-0

宣言：本稿は VenueGuard および Crypto Agent Bench の実験結果を報告するものではなく、意図された実験と検証可能な研究設計を規定するものです。いずれの取引所も、提案中のプロジェクトを推奨、認証、監査していません。本稿は投資助言ではありません。