Crypto OS における AI の位置づけ
五つの役割、六段階の能力、一つの AI Safety Stack。モデルは提案し、決定的なシステムが検証します。
AI は、このコースの最後に追加する一章ではありません。各章に登場しますが、役割は常に同じです。
AI は仮説を出し、あなたは事実を検証します。
このページでは、この原則が各場面で具体的に何を意味するかを説明します。
五つの役割
同じ「AI を使う」でも、役割によってリスクは大きく異なります。
複雑な概念を説明してもらい、理解できるまで随時質問する。
検索、整理、比較、抽出、検証、監視を行う。
PRD、コード、テスト、デバッグ、監査、ドキュメントを書く。
プロトコル、ウォレット、市場、リスク、ガバナンス、ニュースを継続監視する。
身元、ウォレット、予算、戦略、実行能力を持ち、経済主体になる。
最初の三つの役割では、間違いの代償は時間の浪費です。最後の二つでは、資金を失う可能性があります。そのため、このコースでは四つ目の役割から、対応する制約を必須にしています。
六段階の能力
| レベル | AI にできること | 必要な制約 |
|---|---|---|
| L0 AI を使わない | 基礎知識を自分で理解する。 | — |
| L1 AI Assistant | 質疑応答と説明。 | 結論は事実ではなく仮説として扱う。 |
| L2 AI Copilot | 調査、執筆、コード。 | 一次情報と照合し、コードは必ず自分でレビューする。 |
| L3 Tool Agent | 検索、API、RPC、データベース、閲覧専用ウォレットを呼び出す。 | ツール権限を許可リストで制限し、すべての呼び出しを記録する。 |
| L4 Financial Agent | 分析、取引、支払い、資産管理を行う。 | 予算の上限、アドレスの許可リスト、事前シミュレーション、上限超過時の手動承認。 |
| L5 Autonomous Economic Agent | 自律的に収入を得て、サービスを買い、費用を払い、ほかのエージェントと協力する。 | ポリシーエンジン + リスクエンジン + 監査可能なログ。ワンクリックで停止できることも必須。 |
目安は、自分が検証できるレベルまでしか進まないことです。モデルが提案したコントラクト呼び出しの正しさを判断できなければ、Level 3 より上で動かすべきではありません。モデルの能力ではなく、間違いを自分で発見できないことが問題です。
AI Safety Stack
資金を扱うすべての AI システムは、この流れ全体を通す必要があります。T32 の中心テーマであり、すべての Agent 課題の受け入れ基準です。
この流れの責任分担は、次の三つです。
- モデルの責任：Proposal。
- 決定的なシステムの責任：Validation。
- 実行システムの責任：Execution。
三つを一つにまとめてはいけません。モデルの出力が直接実行を起こせるようになると、その間にある検証はすべて意味を失います。
絶対に禁止する構成
このコースで禁止する構成
- Prompt
- LLM
- Private Key
- Send Transaction
モデルに秘密鍵を直接渡し、確認なしに取引させてはいけません。この構成を含む課題は不合格です。
この構成の問題は安全性が足りないことだけではなく、誤りを発見できる場所が一つもないことです。一度のハルシネーション、プロンプトインジェクション、単位の誤記で資金を失い、あとから原因さえ確かめられない場合があります。
このコースの課題でこの構成を使った場合は、受け入れ基準を満たしません。
各章の AI Lab の読み方
各 AI Lab には、AI に任せる作業と、自分で必ず検証するリストの二つがあります。
リストの項目には理由があります。モデルが間違えやすい、次の四つの種類に対応しています。
| 誤りの種類 | どのようなものか | 検証方法 |
|---|---|---|
| 事実の捏造 | 存在しないプロトコルのパラメータ、インターフェース、報告書 | 一次資料を開き、一つずつ照合する |
| 古い情報 | 変更済みのパラメータ、廃止されたバージョン、攻撃を受けたプロトコル | 文書の更新日とチェーン上の現状を見る |
| 定義の誤り | インセンティブを収入に含める、FDV を時価総額として扱う、TVL を収入と見なす | 主要な数値を自分で計算し直す |
| 相関を因果と見なす | 「A が原因で B が起きた」と説明するが、実際は同時に起きただけ | A が起きても B が起きなかった反例を探す |
十数回実践すると、どの問いではモデルを信頼でき、どの問いでは注意深く確認すべきかという感覚が身につきます。その感覚自体が、このコースで育てる AI Literacy です。
よくある誤解
制約が必要なのは、モデルの能力を補うためだけではなく、資金操作の間違いは元に戻せないからです。
オンチェーン取引には取り消しボタンがありません。誤りの確率が千分の一でも、自動実行するシステムではいつか発生します。その一回で、元本をすべて失うかもしれません。これはモデルの強さではなく、不可逆性の問題です。
人間の承認が有効なのは、承認する内容を人間が本当に理解しているときだけです。
毎日 200 回承認を求めるシステムは、承認がないのと同じです。人は考えずに確認を押し始めます。そのため、ポリシーエンジンが大部分のリクエストを自動承認または自動拒否し、本当に判断が必要なものだけを人に提示する必要があります。
必ずしもそうではありません。第 33 章で詳しく考える問いです。
当事者がお互いを信頼し、金額が大きく、頻度が低いなら、通常は従来の決済手段の方が適しています。オンチェーン決済の強みが生きるのは、金額が極めて小さく、頻度が高く、相手を知らず、プログラムによる決済が必要な場面です。まず場面を判断してから手段を選びます。
それでは、自信を持って話す検索エンジンを使うだけになります。
このコースで育てたいのは、AI を使う能力だけでなく、AI がいつ間違った説明をしているかを見抜く能力です。後者は、何度も自分で検証することでしか身につきません。
関連する章
| テーマ | Part A | Part B |
|---|---|---|
| AI が調査方法を変える | 第 31 章 | T31 |
| AI、取引、資産管理 | 第 32 章 | T35 |
| Agent に Crypto が必要な理由 | 第 33 章 | T33 |
| Agent Wallet と権限 | 第 34 章 | T34 |
| 機械の決済プロトコル | 第 35 章 | T34 |
| 信頼できる AI の構成 | — | T32 |
| 自律的なオンチェーン経済 | 第 36 章 | T36 |