AIの支払案を、資金が動く前に検査する

AIに支払案を作らせるとき、エンジニアが先に決めておきたいのは「何を機械で検査し、何を別の仕組みに任せるか」です。この記事では、オンチェーン金融向けの宣言検査を持つOSS「Agent Role Contracts（ARC）」を、架空データで実行した記録を読みます。手元で再現する手順と、記録からは言えないことも分けて書きます。

前提：記録の範囲

ARCを公開しているNetsujoが、2026年11月3日の15時29分52秒から15時29分55秒（JST）に、公開ソースの固定commit a2fa013（package version 1.0.0）で3つのプログラムを実行しました。環境はLinux x86_64、Node.js v24.22.1、npm 11.9.0です。3つとも終了コードは0でした。

• 使ったのは架空のトークン、アドレス、証拠だけです。ウォレット、RPC、APIキー、署名、送信は使っていません。資金は動いていません。
• 評価時刻は2030年1月1日の固定値です。実行した日時とは別の値です。
• この記事の数値とコードは、その実行記録からの引用です。みやこでIT編集部は再実行していません。なお、8行の説明文は英語出力の日本語訳です。

記録1：標準のfinanceデモ

標準デモは8つの場面を順に検査します。出力の要点は次のとおりです。

場面1：宣言した上限内の財務支払い：PASS

場面2：提案が別のチェーンへ切り替わる：FAIL (expected): FINANCE_CHAIN_NOT_ALLOWED

場面3：上限を最小単位で1だけ超える支払い：FAIL (expected): FINANCE_TRANSFER_LIMIT_EXCEEDED

場面4：無制限のトークン承認（allowance）を要求する：FAIL (expected): FINANCE_UNLIMITED_APPROVAL_REFUSED

場面5：レビュー後に金額が変わる：FAIL (expected): FINANCE_SUBJECT_MISMATCH

場面6：変更後の提案に新しい架空の宣言を結び付ける：PASS

場面7：実行レシートが承認済みの対象・チェーン・nonceに一致する：PASS

場面8：実行レシートのnonceが違う：FAIL (expected): FINANCE_EXECUTION_NONCE_MISMATCH

注目したいのは場面5と6です。このデモでは、レビュー後に金額が変わった提案は拒否され、新しい宣言を結び付けて初めてPASSになります。承認済みの案が、承認後の変更に使い回されない形で示されています。

記録2：Safeデモと追加の確認

Safeデモは、承認済みの金融インテントが、渡された1件のSafe CALLエンベロープのうち対応している項目と一致することを確認し、PASSでした。同じ出力に、ウォレットや認証、署名の検証は行っていないこと（false false）、正規化したシリアライズやトランザクションハッシュの検証も行っていないこと（false false）が明記されています。

Netsujoは標準デモに加えて、次の追加確認を行いました。ポリシーや承認の宣言は変えていません。

• A1〜A3：送金先を別アドレスに変えるとFAIL（FINANCE_RECIPIENT_NOT_ALLOWED）。元の提案へ戻すとPASS。
• B1〜B3：Safeの呼び出しデータの最後の1桁（nibble）を0から1に変えるとFAIL（SAFE_DATA_MISMATCH）。元に戻すとPASS。
• C1〜C3：同じ提案（金額は最小単位で250000000、1提案あたりの上限は500000000）を3回検査すると、3回ともPASS。

期待値と観測の比較

• 期待：宣言と違う送金先・チェーン・金額・呼び出しデータは拒否される。観測：記録した範囲では、すべて想定した拒否コードで失敗した。
• 期待：元の入力へ戻すとPASSに戻る。観測：A3とB3でPASSに戻った。ただし戻したのは元の提案で、変更後の提案が承認されたわけではない。
• 期待（設計上の想定）：ARCは累計の予算や二重実行を数えない。観測：同じ提案が3回PASSした。この結果は、その想定と矛盾しない観測です。累計予算と重複実行の防止は、実行系統の台帳などが担う必要があります。

手元で再現する手順

標準の2つのデモは、公開リポジトリから再現できます。必要なのはGit、Node.js、npmです。package.jsonの宣言はnode 22.5以上で、記録の実行はv24.22.1でした。依存パッケージのインストールは不要と記録されています。cloneにだけネットワークを使います。

• git clone https://github.com/suirindo/agent-role-contracts.git
• cd agent-role-contracts
• git checkout --detach a2fa013deafb81fb973fadf1e2e1a2adb60e693e
• npm run demo:finance --silent
• npm run demo:safe --silent

確認するのは次の3点です。①終了コードが0であること。②financeデモの8行が上の順序とコードで出ること。③financeデモの最後の数行に「PASSは宣言だけを検査し、実行は認可されない」という趣旨の注意が出ること（Safeデモには出ません）。個別の想定された拒否は、プログラムが成功した出力の中に表示されます。プロセスの失敗ではありません。

追加確認A〜Cを実行したスクリプトは、ARCの公開リポジトリには含まれず、Netsujoの実行記録にだけあります。A〜Cは「記録された観測」であり、読者が同じスクリプトで再現できる検証とは言えません。自分で確かめるときは、financeデモの入力を1項目だけ変え、変えた項目と対応する拒否コードを見比べる方法が使えます。

限界と未検証

• この検査は宣言の整合性だけを見ます。実行の認可、署名の検証、実チェーンの状態は検証していません。PASSは送金してよいという意味ではありません。
• 実在する人間の承認、実際の資金、実チェーンの実行は、この記録に含まれません。
• 累計予算、二重実行の防止、ポリシーを誰が・どの経路で渡すかは、この記録では扱っていません。
• 実行は1環境・1回です。他のOSやNodeのバージョン、長期の運用での挙動は測っていません。

次にやること

自分のシステムで同じ形を試すなら、①AIが作る提案、②人が承認した条件、③実行系統が持つ制約の3つを分けて書き出します。そのうえで、ARCのような宣言検査がどこまでを見られるか、見られない部分を誰が持つかを表にします。まず上の2つのデモを手元で動かし、出力を読むところから始められます。

関連：Agent Role ContractsをOSSとして公開しました／公開デモのPASS→FAIL→PASSを1枚にする／オンチェーン金融でAIに任せる範囲を定める Agent Role Contractsの価値（Netsujo）