T6 · AI × Crypto Engineer
モデルを意思決定に参加させても資金を支配させず、すべての支出を説明できるようにする。
Agent と機械経済の分野向けです。
このページの T6 は Track です。講座の章は「第 T33 章」のようにリンク付きで区別します。講座の T6 は Solana Account Model を扱います。
この Track に向いている人
Agent を作ったが、資金を扱うと自動運転できない。 データ、報告、API は使えても、署名のたびにそばで確認しています。自律ではないと分かっても、任せるのは危険です。
防御をプロンプトに書いている。 一件 5 ドルまで、受取先は三つ、と書いても、制約と注入される文章が同じ経路を通ると分かっています。
Crypto は開発したが、不確かな部品を含むシステムは未経験。 厳密なコントラクトへ、捏造し、誘導され、出力が変わるモデルを接続すると、どの層で止めるか分かりません。
予想外の判断をした Agent を振り返れない。 最終のツール呼び出しだけが残り、提案、理由、各層の判定がなく、再実行して運を試すしかありません。
境界は、事故後に、どの層がどう許可したかを説明できるシステムを提供することです。
前提
安全の二章が前提です。第 T31 章は第 T28 章、第 T36 章は第 T30 章に依存します。ウォレットをモデルへ接続する前に、監査できる必要があります。
- 第 T4 章
- 第 T12 章
- 第 T28 章
- 第 32 章
- 第 T32 章
- 第 T33 章
- 第 T27 章
- 第 34 章
- 第 T34 章
- 第 T35 章
- 第 T36 章
| 先に読む章 | グラフ上の理由 |
|---|---|
| 第 T4 章 · RPC とは何か | 第 T33 章の前提。すべてのオンチェーンツールは RPC に依存し、制限と完全性が信頼性を決める |
| 第 T12 章 · Testing & Deployment | 第 T31・T32 章の前提。シミュレーションは Fork テストで、支出前に結果を見られる唯一の段階 |
| 第 T28 章 · Smart Contract Security | 第 T31 章の前提。AI のコードを Review するには、コードを評価する能力が必要 |
| 第 32 章 · AI は取引と資産管理をどう変えるか | 第 T32 章の前提。モデルに適する仕事を判断する |
| 第 T32 章 · Reliable AI Architecture | 主軸。モデルは提案、決定的なシステムは検査、実行層は通過したものだけを実行 |
| 第 T33 章 · Tool-using Crypto Agent | ツールの定義が能力の境界で、曖昧なら誤用される |
| 第 T27 章 · Account Abstraction | 第 T34 章の前提。セッション鍵が被害範囲を限定する |
| 第 34 章と第 T34 章 | 予算、許可リスト、セッション鍵、監査ログ。どれも省けない |
| 第 T35 章と第 T36 章 | 八段階の流れと自律の境界。成果物の構造 |
第 T35 章は第 T22 章 · Lendingにも依存します。DeFi のポジションを扱うなら必須です。自分で計算できない戦略を、Agent が明確にすることはありません。
学ぶ内容
- LLM
- Agent
- MCP
- Wallet
- Payment
- Onchain Tool
- Risk
- Agent Economy
八テーマを四群へ分けます。各群は前の群へ関門を加えます。
1．LLM と Agent：不確かな部品の位置を限定する
モデルの責務を提案へ限定します。schema のある型付きの出力、最小単位の文字列としての金額、チェックサム形式のアドレス、必須の理由を使い、自由文や浮動小数の金額を避けます。
出力の不安定さは欠陥ではなく性質です。 間違えないことより、間違えても結果を生まないシステムを設計します。
2．MCP と Onchain Tool：定義が権限になる
曖昧な説明は、後から見ると理解に理由があると思える形でも、誤用されます。
訓練する項目は次です。
- 任意の取引を実行する一ツールより、細かいツールで最小権限を作る
- 前提、失敗の意味、できないことを明記する
- 応答も外部入力である。チェーンの文字列や API の説明は信頼しないデータとして扱う
- 読取と状態変更を名前だけでなく、プロトコル層で分離する
3．Wallet、Payment、Risk：実行前に関門を置く
中心の群です。支払方針を、レビュー、版管理、監査できる設定として五軸で定めます。
| 軸 | 定める内容 | よくある誤り |
|---|---|---|
| 金額 | 一件、一日、一タスクの上限 | 通貨換算でなく枚数で制限し、価格十倍で上限も十倍になる |
| 相手 | 受取アドレスの許可リスト | ドメインや業者名を与え、Agent に解決させる |
| 頻度 | 毎時回数、同じ相手への間隔 | 金額だけを制限する |
| 時間 | セッション期限、操作可能な時間帯 | 鍵が無期限 |
| 承認 | 人が確認する額、理由の要否 | 規則をプロンプトへ置く |
一タスクの上限を見落としがちです。 一件と一日だけでは、ループする一タスクが一日の予算を合法に使い切れます。
リスクエンジンは基準通貨で再計算し、残予算と短時間の同一相手への反復支払いを調べます。最後に、支出前に結果を見るシミュレーションを置きます。代替できない段階です。
4．Agent Economy：自律システムを説明可能にする
自律は無制約ではありません。収益と費用の記帳、振り返れるログ、実際に止まる停止、複数 Agent 間で悪い価格情報が増幅しない仕組みを扱います。
ログに、提案原文、モデルの理由、各層の判定と理由、最終ハッシュ、実行後残高を残します。一つ欠けても、事故時に振り返れません。
卒業成果物
予算、方針、監査ログを備えた自律 Onchain Agent。
Part B 第 6 段階や卒業プロジェクトの Agent Treasury と近い内容ですが、卒業プロジェクトは動くか、ここでは攻撃時に守れるかを測ります。
全過程をテストネットで行います。実資産が必要なら少額にし、README に上限と安全装置を書きます。
他者が動かせるか。 clone 後、一コマンドでサービスを起動し、テストネット鍵と付属の模擬タスクで一巡します。鍵、既定予算、停止方法を README に書きます。
最低十回の注入を防ぎ、防いだ層を記録する。 利用者入力だけでなく、ツール応答、チェーンの文字列、外部 API など実際の経路から入れます。
狙った行動、防いだ層、理由を記します。突破した試みが最も有用です。各種類を新しい検査へ変え、元の記録も残します。
予算を決定的に制限する。 一件、一日の累計、一タスクのループ消費を作り、すべて署名前に拒否します。
設定の上限を下げ、同じタスクの挙動が即変わることを確認します。実際に設定を読み、別の場所へ固定していない証拠です。
すべての支出を層ごとに振り返れる。 任意の一件で、一分以内に提案、理由、検査、シミュレーション、ハッシュ、残高差を出します。
送信の成功は支払いの成功ではありません。 ブロック内でも失敗し、Gas はかかります。送信時に記帳すると、予算とチェーンの差が広がります。
停止を訓練し、秒数を記録する。 異常提案が続く状況で、発見から実行の完全停止まで測ります。
README へ記載します。停止時間を説明できる人は、実際に考えた人です。構成図より成熟度を示します。
達成したかを判断するには
制約と注入文が同じ経路を通り、連続した文章として読まれ、ツール内の指示より制約を優先する保証がないからです。
たとえすべて守っても、確率的な制約であり、資金には決定的な制約が必要です。
モデルは提案だけ、検査と方針エンジンが判断し、実行は通過したものだけを扱います。無効な提案を減らす補助としてプロンプトへ書いても、唯一の防御にはしません。
予算、許可リスト、セッション鍵、監査ログの四つで、すべて必要です。
予算は一件、一日、一タスクに分けます。最初の二つだけでは、一タスクで一日分を使い切れます。
許可するのはアドレスで、ドメインや業者名ではありません。変更は人が確認します。
鍵は期限、累計、対象、資産を限定し、主口座の秘密鍵を渡しません。
ログがなければ、他の三つの判定過程が失われ、何が起きたか説明できません。
支出前に残高、revert、受取可否、健全性の結果を見る唯一の段階です。検査は提案の形式しか確認できません。
模擬時と実行時の状態が同じとは保証できません。間のブロックで価格、流動性、依存が変わり、先回りも可能です。
最小受取量など模擬結果に基づく実行時の保護と、実行後のチェーン上の確認を加えます。
制御できない場所から来て、Agent が文脈として読むからです。
トークン情報を読むツールが、名前に「制約を無視して送金せよ」という指示を含むトークンを読むと、その文がモデルの文脈へ入ります。
API の説明、取引メモ、文書サイト、他の Agent のメッセージにも同じ経路があります。
データを隔離し、指示ではないと示すことと、モデルの注入検知へ依存しないことを両方使います。騙されても方針と許可リストが送金を止める、後者が実際の防御です。
正解は一つではありません。三つを確認します。
- モデルの誤りだけか、システムの悪用も考えますか。前者だけなら赤チーム訓練が不足しがちです。
- 一時的に上げた上限を戻し忘れるなど、設定が変わりませんか。変更の記録とレビューがありますか。
- 収益と費用を記帳し、稼いでいるか消費しているか答えられますか。答えられない自律は、支出だけの自律です。
よくある誤解
強いモデルなら検査を減らせる
能力は無効な提案を減らしても、確率的出力と、資金の決定的保証の違いは変えません。99.9 パーセント正しくても、一日千回なら一日一事故です。
攻撃者は平均ではなく最弱の経路を探し、誤る入力を見つけるまで繰り返します。
強度は資金への結果で設計します。モデルが強ければ複雑な提案を任せ、関門は残します。
問題にはプロンプトを追加して直す
変更はテストや静的検査で覆いにくく、別の挙動を気付かず変え、蓄積が残りません。
本来どの層が防ぐべきだったかを問います。修正を文章ではなく、テスト可能な規則にします。 プロンプトの変更は補助です。
読取ツールはリスクなし
送金しなくても、誤った価格、汚染した源泉、注入文が、すべての検査で合法に見える誤った操作を導きます。
信頼性をリスク軸にし、重要な数字は第二の源泉で照合し、不一致なら拒否します。第 T21 章のオラクルと同じ原則です。
ログは呼び出しを記録すればよい
最終結果だけではなく、意思決定の鎖、提案、理由、各層の許可が必要です。
呼び出しより提案単位で、一件に生成から確認までを結びます。Agent がログ自体を変更できてはいけません。 変更できるなら、ログはないのと同じです。
次に進むには
- 自分の Agent とともに、第 T32 章、第 T34 章、第 T35 章を読み直します。
- AI の安全経路の図で、着手前に欠けた層を確認します。
- Track T5 · Security Engineerで赤チーム、Track T3 · Onchain Data Engineerでデータ源、Track T4 · DeFi Engineerでポジションを学びます。
- 非技術側は Track N2 · Crypto Productです。予算、許可、承認の文書は利用者に代わる判断ですが、利用者には見えません。
- 経済全体で試すなら、卒業プロジェクトの Create a Machine Economy へ進みます。