Web3 × AI
AIエージェントの権限を検査するOSS「Agent Role Contracts」を公開
オンチェーン金融に必要な「実行の信頼」を考える
公開日：2026年10月1日 著者：飯田 友広（Tomohiro Iida）
この記事の結論
オンチェーン金融でAIエージェントが価値を動かすなら、programmable moneyだけでなく、何をどこまで実行してよいかを機械的に扱うprogrammable authorityが必要になる。
Identityは主体を識別しても、実行範囲・承認条件・レビュー分離・引き継ぎまでは決めない。Authorization→Execution→Verification→Auditを分けて設計する必要がある。
Agent Role Contracts v0.1.0は、実行前の役割・権限・タスク・レビュー・handoff宣言の矛盾を静的に止めるOSSであり、runtime権限強制や金融取引の安全性を保証する製品ではない。
オンチェーンが実行結果を検証可能にしても、実行前のauthorityが曖昧なら「透明に間違える」だけになりうる。
2026年9月25日、金融庁は「AI時代を見据えたオンチェーン金融フォーラム」の立ち上げを公表し、9月30日に第1回会合を開催した。公式発表で掲げられているのは、ブロックチェーンを基盤とするオンチェーン金融の社会実装と、金融機関等におけるAIの健全な利活用を横断的に検討することだ。
その直前まで、Netsujoでは別の角度から同じ境界を詰めていた。AIエージェントが仕事を実行する前に、「誰が何を担当し、どこまで変更してよく、誰がレビューし、別のエージェントへ何を引き継いでよいか」を機械的に検査できないか、という問題だ。
そこで公開したのが、OSSの Agent Role Contracts である。
v0.1.0は、エージェントを起動しない。role、authority、review separation、task routing / write scope、handoffの宣言を静的に検査し、自己矛盾した計画を実行前に止める。これは金融取引を実行する製品ではない。それでも、AIとオンチェーン金融が接続するほど、この「実行前にauthorityを検査する」という考え方は重要になると考えている。
Money is programmable
ブロックチェーンとスマートコントラクトは、価値移転の条件をソフトウェアとして記述できる。送金、交換、担保、清算、権利移転を、コードが定めた条件に従って実行できる。
この変化を「programmable money」と呼ぶなら、次に問われるのは、そのmoneyを動かす主体の側だ。
価値移転が24時間動き、APIやスマートコントラクトから呼べるだけでは、AIエージェントへ金融行為を任せる設計としては足りない。実行主体が何を許可されているかを同じレベルで機械的に扱えなければ、実行速度だけが上がる。
Agents are becoming autonomous
AIエージェントは、回答を生成するだけのソフトウェアから、目的を受け取り、外部ツールを呼び、作業を進める実行主体へ変わっている。
メールを送れる。コードを変更できる。クラウドや業務システムを操作できる。その延長線上には、支払い、資産移転、契約の実行、トレジャリー運用がある。
ここで問題になるのはモデルの知能だけではない。
そのエージェントは、何をしてよいのか。誰がそれを許可したのか。どこまでなら自動実行でき、どこから人間や別のレビュアーへ戻すのか。
この問いは、プロンプトに「慎重に操作してください」と書いても解決しない。
次にprogrammableにすべきものはAuthority
企業の財務エージェントを仮定する。
残高照会は自動でよい。一定額以下の支払いは自動実行できる。上限を超えれば人間承認が必要。新規送金先への初回送金は別のレビュアーが確認する。投資判断をした主体と最終送金を承認する主体は分ける。
こうした条件は、単なる業務ルールではない。AIが経済行為を実行するなら、実行権限そのものの仕様になる。
Moneyがprogrammableになるほど、そのMoneyを動かすAuthorityもprogrammableにする必要がある。
Identityだけでは足りない
Identityは重要だ。DID、VC、ウォレット署名などによって、「誰であるか」「どの資格や属性を証明できるか」を扱える。
ただし、本人性が確認できても、その主体が今この操作をしてよいかは別問題である。
- どの操作まで許可されているか
- どの資産、契約、環境が対象か
- 金額・時間・相手先などの上限は何か
- 誰が実装し、誰がレビューするか
- 別エージェントへ仕事を渡すとき、何を引き継いでよいか
- 実行結果を、何の証拠で後から確認するか
Identityの次にAuthorizationがある。その先にExecutionがあり、さらにVerificationとAuditがある。
Identity → Authorization → Execution → Verification → Audit
この層を分けずに一つの鍵や一つのエージェントへ押し込むと、事故が起きたときに「誰が」「何を許可され」「何を実行し」「どこで逸脱したか」を切り分けにくい。
Agent Role Contractsを公開した理由
Netsujoが公開したAgent Role Contracts v0.1.0は、このスタック全体を実装するものではない。
担当するのは実行前の宣言整合性だ。
role、authority、review separation、task routing / write scope、handoffをJSONとして宣言し、その宣言に矛盾がないかを静的に検査する。
たとえば、読み取り専用のreviewerに書き込み権限が混じっている、実装者が自分自身をreviewerとして宣言している、タスクが許可範囲外への書き込みを要求している、委譲関係やhandoffに矛盾がある、といった状態を実行前に拒否する。
v0.1.0の厳密なPASS範囲、CLI、終了コード、npmでの再現方法は、別記事 Agent Role ContractsのPASSが保証すること・しないこと に切り出している。
ここで重要なのは、チェッカーが何をしないかだ。Agent Role Contractsは、runtime権限を付与しない。Identityを検証しない。秘密鍵を保管しない。スマートコントラクトを実行しない。Evidenceの真正性を証明しない。金融機関向けのセキュリティ製品でもない。
それでも実行前の宣言検査を独立させる意味がある。wallet policyやsmart contractが正しく強制されていても、そこへ渡すintentやtaskが最初から自己矛盾していれば、強いexecution layerが誤った要求を忠実に実行する可能性があるからだ。
Authorization → Execution → Verification → Audit
AIエージェントとオンチェーン金融を接続する場合、私たちは少なくとも次のレイヤーを分けて考える。
| レイヤー | 問うこと | Agent Role Contracts v0.1.0 |
|---|---|---|
| Identity | 誰か、何を証明できるか | 対象外 |
| Authorization | 何を、どの条件で実行してよいか | 宣言整合性の一部を検査 |
| Execution | 実際に何を実行したか | 対象外 |
| Verification | 実行が条件・意図に一致したか | 対象外 |
| Audit | 後から誰が何を確認できるか | 対象外 |
Agent Role Contractsが有効なのは、この表の一行だけを埋めるからではない。逆に、一行しか埋めないことを明確にしたまま、他の層と接続できるからだ。
Authorizationを検査する道具がExecutionまで勝手に担わない。Executionを行うwalletがIdentityの唯一の正本にならない。Verificationを実行主体自身だけに任せない。こうした境界が、経済的な影響が大きくなるほど効いてくる。
オンチェーン金融に置くと、何が見えるか
たとえば企業の支払いエージェントなら、次のような設計が考えられる。
- Identityで企業・担当・エージェントの関係を確認する
- Authorizationで対象資産、上限額、相手先、期限、review requirementを宣言する
- Agent Role Contractsのような事前検査で、役割・タスク・review/handoff宣言の自己矛盾を止める
- wallet / account / smart contract側でruntime policyを強制する
- 実行後はtransaction、receipt、署名、外部状態を使って意図との一致を検証する
- 監査証跡を残し、必要なら人間がreconcileする
これは現在のAgent Role Contractsがそのまま金融システムに入る、という主張ではない。むしろ逆だ。静的契約検査、Identity、runtime enforcement、署名、on-chain execution、post-execution verificationを別々の責任として設計しなければならない。
Netsujoが別記事で扱っている Authority Continuity は、このうち「昨日validだったgrantを、stateが変わった今日も使ってよいのか」という時間軸の問題を担当する。この記事ではそこへ踏み込まず、実行前のauthorityを機械可読な契約として扱う入口に絞る。
オンチェーンだからこそ、実行前が重要になる
ブロックチェーンは、実行後の状態を第三者が検証できる強い基盤を提供する。
しかし、実行前のauthorityが曖昧なら、結果が透明になるだけで、判断が正しくなるわけではない。
誤った送金も、過大な権限で行った操作も、オンチェーンなら後から追跡できる。追跡できることと、止められることは別だ。
だから、AIエージェント時代のオンチェーン金融で必要になる「信頼」は、単一の技術では成立しない。
Identityで始まり、Authorizationを機械可読にし、Executionを制約し、Verificationを独立させ、Audit可能なEvidenceを残す。
Agent Role Contractsは、そのうち最初の一部をOSSとして公開したものだ。
Programmable moneyの次へ
Programmable moneyが広がり、AIエージェントが経済行為へ近づくほど、問われるのは「AIがどれだけ賢いか」だけではなくなる。
誰が、どの権限で、何を実行し、誰が検証し、その証拠を後から確認できるのか。
Netsujoは、この問題をAI Agent OperationsとWeb3の交点にある「実行の信頼」として扱っていく。
まず公開したのが、Agent Role Contractsだ。
この記事の著者
飯田 友広
代表取締役
Netsujo株式会社 代表取締役。京都発のWeb3・AI実装スタートアップを2023年6月に創業。Webサイトを営業基盤として捉え、経営・営業・検索・生成AI・コンバージョン・計測を横断して課題と改善優先順位を整理する「Netsujo SIGNAL」を設計・運営。さらに、ChatGPT・Codex・Claude Codeを状態再構築、競合回避、独立QC、Exact-head検証、停止、復旧まで含む制御ループで運用する社内AI開発基盤「Netsujo Agent OS」を設計・実運転。Netsujoとして京都ビッグデータ活用プラットフォームに参画(小規模企業会員（ベンチャー）)し、同プラットフォーム発のワーキンググループ「Chain Up KYOTO」にも参画(2026年3月10日〜)。IVS2026サイドイベント「なぜ京都でWeb3.0ビジネスなのか」はNetsujoとして京都府庁旧議場で主催・企画・登壇・運営(2026年7月2日／京都府 総合政策環境部 デジタル政策推進課は共催)。京都美術工芸大学・龍谷大学での講義に加え、京都高度技術研究所（ASTEM）、旅館業界、就労支援施設、Open Source Conference等で登壇実績。ITコミュニティ「みやこでIT」(connpassメンバー639名・イベント176件・2019年2月から運営)運営。NPO法人NEMTUS理事、BAR KRYPTO運営。Netsujoはソーシャル企業認証制度「S認証」の認証企業(2026年2月認証・2026年4月公表)。技術領域はWeb3/ブロックチェーン/DID/NFT/生成AI/コミュニティ運営。
プロフィールを見るこの記事が向いている方
AIエージェントを支払い・資産移転・契約実行へ接続する構想を持つ事業責任者
Web3とAIの間で、Identity・権限・実行・監査の責任境界を設計したい技術責任者
Agent Role Contractsがオンチェーン金融のどの問題に関係し、どこから先は別の仕組みが必要か判断したい開発者
— 壁打ち相談
読者のよくある相談
記事を読んだ後に「自分の状況だとどう判断すべきか」を整理するための壁打ち相談を受け付けています。下記のような相談例が当てはまる方は、お気軽にご連絡ください。
Q. Identityを確認できれば、AIエージェントに金融操作を任せてよいのか
Identityは出発点です。操作範囲、上限、承認条件、レビュー分離、実行後の検証はAuthorization以降の別レイヤーとして設計します。
Q. Agent Role Contractsはウォレットやスマートコントラクトの権限を強制するのか
しません。v0.1.0は実行前の宣言整合性を静的に検査します。runtime enforcementは別の仕組みが必要です。
Q. オンチェーンなら実行記録が残るので、事前検査は不要ではないか
実行記録が残ることと、誤った権限やintentを実行前に止められることは別です。事前と事後の検証を分離します。
上記いずれかが該当する場合、初回30分の壁打ち相談で論点整理に対応します。記事に書ききれない個別事情を踏まえた判断材料が必要な段階こそ、壁打ちが活きやすいフェーズです。
Web3・AIエージェント設計のご相談
「誰が何を実行してよいか」から設計する
AI Agent OperationsとWeb3を別々に考えず、Authority・Execution・Verificationの責任境界から整理します。