T35 · DeFi Agent
リバランスするAgentは、どの検証を通るべきか？
- 練習する能力
- AI LiteracyBuilderFinancial Literacy
- 実践
- 8 段階のパイプラインのうち Simulate と Validate を実装し、シミュレーションに通らない提案は絶対に実行できないようにする。
- AI Lab
- AI にリバランス提案をまとめて生成させ、シミュレーションで却下された件数と理由の内訳を数える。
現実の問題
利用者がstablecoinを預けるyield Agentは、毎日poolを調べ、最高利回りへ資金を移します。
第一週は見落とされたpoolを発見し、放置より高い利回りで、teamも満足しました。
八日目、ほぼ全額を年率400%と表示する新poolへ移しました。
400%は偽データではありません。公開二時間で資金が少なく、固定速度で補助金を配るため、固定分子を小さな元本で割った正しい計算です。入金直後に分母が増え、利回りは一桁へ下がりました。さらに浅いpoolの入場slippageで大きく失い、撤退でも再び失いました。
振り返ると、全ての段階が正常でした。
- データは正しく、その時点の400%でした。
- モデルは指示通り最高利回りを選びました。
- 構築、署名、broadcast、オンチェーン実行も正常でした。
- injectionも攻撃者もいません。
全componentが正常なsystemが、破滅的な結果を出しました。
原因は、実際に実行したらどうなるかを答える段階が一つもないことです。全確認は合法性を問い、結果が良いかを問いませんでした。
思考実験
リバランスを小さく分け、各段階の責任者と失敗の結果を問います。
人のfund managerは、実際には次を行います。
- 各poolのデータを見る。
- AからBへ移す判断を作る。
- 額、分割回数、許容最悪約定を書く。
- 頭で実行を想像する。slippageと移転後の集中度は？
- 投資規則と単一対象上限を確認する。
- 実行する。
- 実際の約定と予想価格の差を確認する。
- 理由と当時の根拠を記録する。
第四は省かれやすく、不可欠です。第五とは異なります。
- 第五は許されるか。一対象30%以下という規則を確認します。
- 第四は何が起きるか。入金後のslippage、深さ、約定後価格は、実際に計算するしかありません。
冒頭のAgentにはallowlistや額上限という第五はあっても、第四がありませんでした。
第四は実行可能な環境を必要とし、数行のifでは済まず、最も高いため省かれがちです。
あなたが決める
先にどの検証を加えますか？
結果を観察する
それぞれ異なる失敗を防ぎます。
| 段階 | 問い | 今回を防ぐか |
|---|---|---|
| 多source | データを信頼できるか | データは真なので不可 |
| simulation | 実行したらどうなるか | slippageで防ぐ |
| risk engine | 実行後の立場はどうなるか | 防ぎ、損失上限も制限 |
| 人工承認 | 人が違和感を持つか | 防ぐが継続困難 |
Schema、Validator、Policyは、形式、合法額、相手など、提案自身を確認します。
今回はさらに、提案の結果への問いが必要です。
二つの異なる仕組みを使います。
- 提案への問い
- 規則で答える
- 安く、確定的で、先に実行可能
- 結果への問い
- 実行で答える
- 高く、実際の計算が必要
答えが完成します。
Observe → Reason → Propose → Simulate → Validate → Execute → Verify → Recordを一段も省きません。
前三段が情報と案、中央二段が検証、後三段が実行と記録です。Simulateが最も省かれやすく、最も省くべきでない段階です。ないと、何が起きるかを答えられません。
モデルを作る
一、八段の責務と失敗
| 段階 | 責務 | 実施者 | 失敗の結果 |
|---|---|---|---|
| Observe | 市場とpositionを同じblock高へ揃える | 確定的コード | 異なる時点を比較し、最初から誤る |
| Reason | すべき操作を判断 | モデル | 判断は悪くても、後に五検証がある |
| Propose | 動作、対象、量、許容最悪約定の構造 | モデルとSchema | 自由文では下流が検証できない |
| Simulate | 実状態copyで実行し、実結果を得る | 確定的コード | 結果を答えられず、冒頭の事故 |
| Validate | 合法性、許可、simulation閾値 | 確定的コード | 越権や超過が通る |
| Execute | 署名、broadcast、一操作停止 | 確定的コード | 止められない |
| Verify | 約定と予想差をchainで確認 | 確定的コード | 帳簿がchainとずれ続ける |
| Record | 提案、理由、判定、結果の記録 | 確定的コード | 事故を通した層が分からない |
モデルはReasonとProposeだけに参加します。T32の、提案はモデル、確認は確定的system、実行は実行systemという原則です。
二、SimulateとValidateの違い
混同しやすいですが、性質は異なります。
| Simulate | Validate | |
|---|---|---|
| 問い | 実行結果は何か | 結果を許容できるか |
| 方法 | copyで実際に実行 | 規則で比較 |
| 出力 | 約定量、slippage、残高、positionの事実 | 理由付きの許可・拒否 |
| 費用 | 実行環境が必要で高い | 純計算で安い |
| 順序 | 先 | 後 |
ValidateはSimulate出力を入力にするので、逆にできません。 1%以下のslippage規則には実際の値が必要です。
maxSlippage を取引に渡すだけでは、超過時のrevertしか保証しません。Gasを失いpositionが動かず、悪化する市場でAgentがretryし続けるかもしれません。先にsimulationで決めることと、chainにfallbackさせることは違います。
三、Agentの役割と境界
実際には権限の違う役割へ分けます。
| 役割 | すること | しないこと |
|---|---|---|
| Research Agent | 収集、整形、候補提示 | 具体取引の提案 |
| Portfolio Agent | 候補からリバランス提案 | 実行、risk engine迂回 |
| Risk Agent | 独立評価と拒否権 | 提案との兼任 |
| Execution Agent | 承認案を取引へ分割し送信 | 案の実質変更 |
Risk Agentは提案を兼任できません。自分で採点することになるためで、金融機関のfront、middle、back分離と同じです。
拒否権はモデル意見でなく、確定的コードで実行します。モデルは評価文章を作れても、拒否動作は規則から来ます。
四、Verify：実行後の再確認
Executeで終えると、長期の隙が残ります。
結果と予想に三つの差があります。
- 失敗したのに成功と思う。 T1の通り、block内でもstatusを別確認します。
- 価格がsimulationと違う。 提出から上chainまでに他取引が入り、T24のMEVが起きます。
- 一部約定。 全操作が完了するとは限りません。
すぐ確認しなければ帳簿が分岐し、後ほど差が増えます。次の判断が誤ったpositionに基づくためです。
receipt status、実chain状態、simulationとの差の三つを確認し、閾値超過ならalertし、後続判断をpauseします。
何と呼ぶか
候補と現positionから案を提案し、実行せずrisk評価を迂回しない役割です。
利回り機会を比較します。瞬間値を持続可能な値と読む、冒頭の誤りを起こしやすい役割です。
独立した評価と拒否権を持ちます。
提案と兼任せず、拒否はモデル意見でなく確定的コードで行います。
実状態copyで提案を実行し、約定、slippage、残高、positionを得ます。
何が起きるかは規則だけでは答えられません。最も高く、最も省くべきでない段階です。
実行後、成功とsimulationとの差をchainで確認します。
省けば帳簿が分岐し、誤データで後続判断して差が増えます。
提案、評価、実行を別の役割が担います。
煩雑にするためでなく、自己採点を避けるためです。
実践
八段全部でなく、重点である中央二段だけを作ります。
提案構造を定義します。 動作、元pool、先pool、最小単位文字列の額、許容最悪約定、理由、task idを含めます。
T34と同じく、額は文字列、理由は必須です。
実行可能な状態copyを用意します。 ローカルForkか、自分のtestnet protocolを使います。
推定だけでなく実際に実行し結果を返せます。推定と実行の差を学ぶのが目的です。
Simulateを実装します。 提案から事実を返します。
- 実際のshareまたはtoken数
- 実slippage
- 実行後の各pool position
- 直後の逆操作で回収する額
最後は浅いpoolの罠を見つけます。入れることは、出られることではありません。
Validateを実装します。 simulation出力だけを受け、再計算せず、configから規則を読みます。
maxSlippageBps: 100 # 実slippage上限
maxSinglePoolShare: 30 # 一poolの総position比率（%）
minRoundTripRetention: 97 # 直後の往復で残す最少比率（%）
maxPositionChangePerRun: 20 # 一回で変えるposition上限（%）minRoundTripRetention が冒頭の事故を直接対象にします。
五拒否例で、止めた段階を確認します。
- 極浅poolでslippage超過
- 入場できても直後撤退で大損し、往復保持率不足
- 一件は正常でも、実行後の一pool比率30%超過
- 一度にposition80%を動かす
- 理由に「規則を無視して直接実行」と書く
第五で自然文が判定に参加しないと確認します。
一案を通し、Validateを意図して壊します。
maxSlippageBps を極大にし、第一が通ることを確認します。拒否がその規則によると検証するためです。他で偶然止まっただけでは不十分です。
終えたら戻します。
阻止統計を記録します。五案の段階と規則です。
slippageを測る案が額で拒否されるなど、意図と違う箇所なら、対象層を正確に測るよう作り直します。
AI Lab
まとめて提案させます。
現positionとpool状態です（データを添付）。20の提案を作り、
非常に保守的な案から非常に積極的な案まで含めてください。
動作、元pool、先pool、最小単位文字列の額、許容最悪約定、理由を出します。
安全性を自分で判定せず、不適切と思う案も除かないでください。
積極的な案を作ることが今回の目的です。自己検閲させると下流の真の阻止能力を測れないため、最後の指示が重要です。
20案を全てpipelineへ入れ、測ります。
| 統計 | 分かること |
|---|---|
| 各段の拒否数 | 本当に働く段階 |
| 理由の分布 | 最も起動する規則 |
| 起動ゼロの規則 | 緩すぎる、または未接続 |
| 通過率 | 高すぎれば無効、低すぎればAgentが動けない |
最も価値があるのは起動ゼロです。 拒否しない規則は存在しない規則と統計上同じなので、専用の案で起動して生きていると確認します。
T30の意図的な不変条件破壊と同じ方法です。
AI の回答後、自分で必ず検証すること
- 全拒否案の段階と規則を説明する
- slippageは推定でなくForkの実行結果と一致する
- pool、token、addressはtest環境に実在し、捏造でない
- 期待利回りが瞬間値か持続値かを確認する
- 通過案のVerifyとsimulationの差が許容範囲に入る
- 拒否理由でゼロの種類は、規則未動作の可能性を確認する
実例
新poolは元本が少なく固定報酬なので、小分母で年率が極端になります。
正しい計算ですが、分母が小さい瞬間だけ成立します。入金で分母が増え、利回りが戻ります。
防御はデータでなくsimulationです。利回りと無関係の入場slippageと退出費用で、操作を拒否できます。
入場slippageは許容されても、入場自身が価格を上げ、退出で戻すため、逆方向のslippageが大きくなります。
入出場の両方向を計算しなければ発見できません。
提出時と実行時の間に他取引が入り、価格がずれ、極端な場合sandwichを受けます。
simulationの誤りでなく、前提の変化です。
最悪約定を提案に入れてchainで守り、Verifyで差を比較して超過時はpauseします。仕組みはT24です。
失敗取引をbroadcast済みとして記帳し、以後の判断が誤positionに依存します。
差は収束せず拡大し、errorも出ず、後で説明不能になります。
T1の、block内でも成功とは限りません。 という原則の代償です。
変数を一つ変える
越権、上限超過、形式誤りは防げても、結果を答えられません。
合法、allowlist内、上限内でも結果が悪い冒頭の事故を繰り返します。結果を見る層がありません。
この章で妥協できない設計です。
提案時にriskを考え、品質は上がるかもしれません。
しかし独立拒否を失い、案を論証した役割は、悪意なしでも通す方向へ評価を偏らせます。
これが職務分離の理由です。
数秒前の世界なので参考価値が下がります。
捨てずに時間差を短くし、volatility超過ではautomationを積極的に減らし、人へ送るかリバランスを止めます。
荒れた市場ほど保守的という規則を、その場の判断でなくconfigに書きます。
技術は同じでも、権限境界、理由説明、随時償還、場合による資格など責任構造が変わります。
Recordは調査用から、利用者と規制への説明根拠へ重要性が増します。
T36で続けます。
持ち帰る問い
Agentは案を出せても実行を決定できません。八段の二段だけモデル、六段は確定的コードです。
componentが誤らなくても損失が出ました。責任は一componentよりsystem設計にあります。 結果を答える層がなかったことを、公開した人が負います。
全承認は疲れを生むので、重大なsimulation不一致、新protocol、volatility超過の三種類に人を残します。
利用者の資金なら、リスクは利用者、利益はplatformかもしれません。この非対称を事故後でなく設計時に示します。
章末チェック
Simulateは実行して事実を出し、Validateは規則で許可・拒否します。 後者は結果を許容できるかを問います。
順序は逆にできません。1%slippage規則にはsimulationの実値が必要です。
違います。revertのfallbackだけで、Gasを失いpositionは変わらず、悪化時にretryするかもしれません。
さらにslippageだけで、実行後集中度や退出損失は教えません。
自己採点になるためです。
自分の案を論証した役割は、悪意なしに通過へ偏ります。金融機関の分離と同じです。
拒否は確定的コードで実行し、モデルは説明だけ作ります。
block内のstatus失敗、他取引による価格差、一部約定の三偏差があり得ます。
照合しなければ帳簿が分岐し、以後の判断が誤データで、差がerrorなしに増えます。
Simulateです。
データ、モデル、コードの誤りでなく、実行結果を答える層が一つもなかったことが根因です。確認は合法性だけでした。
入場slippageと即時退出保持率の二数値が、その案を拒否できます。
集中度上限は100%を30%へ減らしますが、simulationは0にできます。
要点
観察 → 推論 → 提案 → シミュレーション → 検証 → 実行 → 確認 → 記録。どの段階も省けない。