Web3 × AI
オンチェーン金融の「実行の信頼」を支えるOSSを公開
Agent Role Contractsは、AIの役割・権限・実行範囲・引き継ぎの宣言を実行前に検査する汎用OSSです
公開日：2026年10月1日 更新日：2026年10月5日 著者：飯田 友広（Tomohiro Iida）
この記事の結論
Agent Role Contractsは、AIの役割・権限・実行範囲・レビュー・引き継ぎの宣言を実行前に検査する汎用OSSである。オンチェーン金融は、権限設計の重要性が特に表れるユースケースの一つだ。
オンチェーン金融でAIエージェントが価値を動かすなら、お金の実行条件だけでなく、何をどこまで実行してよいかという権限も機械的に扱える設計が必要になる。
Identityは主体を識別しても、実行範囲・承認条件・レビュー分離・引き継ぎまでは決めない。Authorization→Execution→Verification→Auditを分けて設計する必要がある。
Agent Role Contractsは、stable 0.5.0をnpm latestで公開している。宣言整合性を検査する層で、runtime権限強制や金融取引の安全性を保証しない。
Netsujoは、AIエージェントの役割・権限・レビュー分離・実行範囲・引き継ぎの宣言を、実行前に検査するオープンソースソフトウェア（OSS） Agent Role Contracts を公開した。
v0.1.0は、エージェントを起動せず、role、authority、review separation、task routing / write scope、handoffの宣言を静的に検査する最初の公開版だった。2026年10月6日、G0〜G3を含む0.5.0をnpmのlatestで安定版として公開した。
2026年9月25日には、金融庁が「AI時代を見据えたオンチェーン金融フォーラム」の立ち上げを公表し、9月30日に第1回会合を開催した。公式発表では、ブロックチェーンを基盤とするオンチェーン金融の社会実装と、金融機関等におけるAIの健全な利活用を横断的に検討するとしている。
同じ時期に、Netsujoでは隣接する問題を詰めていた。AIエージェントが仕事を実行する前に、「誰が何を担当し、どこまで変更してよく、誰がレビューし、別のエージェントへ何を引き継いでよいか」を機械的に検査できないか、という問題だ。
この記事ではオンチェーン金融を前面に置く。ただし、Agent Role Contracts自体はオンチェーン金融専用ではない。 金融は、AIへ権限を渡したときの結果が資産移動や契約実行として明確に現れる、重要なユースケースの一つである。
オンチェーン金融専用ではない
Agent Role Contractsは、ウォレットを操作するライブラリでも、スマートコントラクトを実行する仕組みでもない。ブロックチェーン接続を前提にせず、AIエージェントへ渡すrole、authority、task scope、review separation、handoffの宣言が互いに矛盾していないかを検査する。
そのため、対象は金融に限られない。たとえば、次のような場面へ適用できる設計になっている。
- ソフトウェア開発で、実装担当の書き込み範囲とレビュー担当の分離を検査する
- バックオフィス自動化で、エージェントへ許可した操作範囲とタスク要求の矛盾を検査する
- データ処理で、対象scopeが許可範囲を超えていないかを検査する
- 複数AIエージェントの協調で、routingとhandoffの整合性を検査する
つまり、「AIに何をどこまで任せるか」を実行前に機械的に確認する汎用部品として公開している。
オンチェーン金融を入口にするのは、この問題が最も具体的に見えやすいからだ。AIが価値を動かすなら、曖昧な権限設計のコストはコードレビューの手戻りだけでは済まない。
お金がプログラム可能になった
ブロックチェーンとスマートコントラクトは、価値移転の条件をソフトウェアとして記述できる。送金、交換、担保、清算、権利移転を、コードが定めた条件に従って実行できる。
お金を動かす条件をコードで定義できるようになると、次に問われるのは、そのお金を動かす主体の側だ。
価値移転が24時間動き、APIやスマートコントラクトから呼べるだけでは、AIエージェントへ金融行為を任せる設計としては足りない。実行主体が何を許可されているかを同じレベルで機械的に扱えなければ、実行速度だけが上がる。
AIエージェントが実行主体になりつつある
AIエージェントは、回答を生成するだけのソフトウェアから、目的を受け取り、外部ツールを呼び、作業を進める実行主体へ変わっている。
メールを送れる。コードを変更できる。クラウドや業務システムを操作できる。その延長線上には、支払い、資産移転、契約の実行、トレジャリー運用がある。
ここで問題になるのはモデルの知能だけではない。
そのエージェントは、何をしてよいのか。誰がそれを許可したのか。どこまでなら自動実行でき、どこから人間や別のレビュアーへ戻すのか。
この問いは、プロンプトに「慎重に操作してください」と書いても解決しない。
次に設計すべきは、AIに与える権限
企業の財務エージェントを仮定する。
残高照会は自動でよい。一定額以下の支払いは自動実行できる。上限を超えれば人間承認が必要。新規送金先への初回送金は別のレビュアーが確認する。投資判断をした主体と最終送金を承認する主体は分ける。
こうした条件は、単なる業務ルールではない。AIが経済行為を実行するなら、実行権限そのものの仕様になる。
お金の実行条件をコードで扱うほど、そのお金を動かすAIの権限も、機械的に定義・検査できる必要がある。
本人確認だけでは、実行権限は決まらない
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に矛盾がある、といった状態を検知してFAILを返す。
v0.1.0の厳密なPASS範囲、CLI、終了コード、npmでの再現方法は、別記事 Agent Role ContractsのPASSが保証すること・しないこと に切り出している。
2026年10月6日、0.5.0をnpmのlatestで安定版として公開した。0.5.0では汎用コアを保ったままG0〜G3が利用でき、G1はtask/actionの宣言上の紐付け、G2は任意のfilesystem-write mapping検査、G3はlifecycle宣言の整合性を扱う。オンチェーン金融とSafeは用途別の任意機能であり、汎用コアの前提ではない。G2は実ファイルを書かず、G3はControllerや実行状態機械ではない。いずれのPASSもruntime権限、本人性、実際のreview/approval、成果物の実バイト、実行成功、金融安全性を保証しない。
ここで重要なのは、チェッカーが何をしないかだ。Agent Role Contractsは、runtime権限を付与しない。Identityを検証しない。秘密鍵を保管しない。スマートコントラクトを実行しない。Evidenceの真正性を証明しない。金融機関向けのセキュリティ製品でもない。
それでも実行前の宣言検査を独立させる意味がある。wallet policyやsmart contractが正しく強制されていても、そこへ渡す実行意図やタスクが最初から自己矛盾していれば、強い実行制御層が誤った要求を忠実に実行する可能性があるからだ。
権限 → 実行 → 検証 → 監査を分ける
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宣言の自己矛盾を検知し、FAILを返す
- wallet / account / smart contract側でruntime policyを強制する
- 実行後はtransaction、receipt、署名、外部状態を使って意図との一致を検証する
- 監査証跡を残し、必要なら人間が照合する
これは現在のAgent Role Contractsがそのまま金融システムに入る、という主張ではない。むしろ逆だ。静的契約検査、Identity、runtime enforcement、署名、オンチェーン実行、実行後の検証を別々の責任として設計しなければならない。
Netsujoが別記事で扱っている Authority Continuity は、このうち「昨日は有効だった権限を、状態が変わった今日も使ってよいのか」という時間軸の問題を担当する。この記事ではそこへ踏み込まず、実行前のauthorityを機械可読な契約として扱う入口に絞る。
オンチェーンだからこそ、実行前が重要になる
ブロックチェーンは、実行後の状態を第三者が検証できる強い基盤を提供する。
しかし、実行前のauthorityが曖昧なら、結果が透明になるだけで、判断が正しくなるわけではない。
誤った送金も、過大な権限で行った操作も、オンチェーンなら後から追跡できる。追跡できることと、止められることは別だ。
だから、AIエージェント時代のオンチェーン金融で必要になる「信頼」は、単一の技術では成立しない。
Identityで始まり、Authorizationを機械可読にし、Executionを制約し、Verificationを独立させ、Audit可能なEvidenceを残す。
Agent Role Contractsは、そのうち最初の一部をOSSとして公開したものだ。
プログラム可能なお金の次へ
お金をコードで扱える領域が広がり、AIエージェントが経済行為へ近づくほど、問われるのは「AIがどれだけ賢いか」だけではなくなる。
誰が、どの権限で、何を実行し、誰が検証し、その証拠を後から確認できるのか。
Netsujoは、この問題をAI Agent OperationsとWeb3の交点にある「実行の信頼」として扱っていく。
まず公開したのが、Agent Role Contractsだ。
この記事の著者
飯田 友広
代表取締役
Netsujo株式会社 代表取締役。Technical BizDev / AI Deploymentとして、顧客の業務課題、AI適用領域、PoC、実装チームとの要件、本番導入後の評価をつなぐ。京都発の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. オンチェーンなら実行記録が残るので、事前検査は不要ではないか
実行記録が残ることと、誤った権限や実行意図を実行前に検知できることは別です。事前と事後の検証を分離します。
上記いずれかが該当する場合、初回30分の壁打ち相談で論点整理に対応します。記事に書ききれない個別事情を踏まえた判断材料が必要な段階こそ、壁打ちが活きやすいフェーズです。
Web3・AIエージェント設計のご相談
「誰が何を実行してよいか」から設計する
AI Agent OperationsとWeb3を別々に考えず、Authority・Execution・Verificationの責任境界から整理します。