第33章 · AI AgentがCryptoを必要とする可能性

現実の問題

毎朝、前日の業界動向を一ページにするソフトウェアを書いた。

三つのデータAPI、当日の有料概要、モデル用の十分の計算資源、ときどき不確かな情報を人に確認してもらうことが必要だ。

最初で止まる。APIの画面には、カード情報を入力してくださいとある。

自分のカードを入れると便利に動いたが、問題が続く。

第一、カードは自分のものだ。 全支出が自分の枠と明細に入り、ソフトウェアが何に使ったか一目で分からない。

第二、相手は誰か知らない。 高頻度で呼ぶカード利用者としか見えず、第三日に不正利用らしいとして止まる。電話で二十分説明した。

第三、有料概要は月額購読だ。 月四回しか読まなくても一か月分を買い、未使用分を払う。

第四、確認する人は国外だ。 一件は数十セント程度だが、送金費用は数十倍で書類も多く、結局できなかった。

第五、最大の問題は40個動かしたいことだ。 個別の予算、記録、上限が要る。一カードでは無理で、銀行へ40口座を申請する欄も書けない。所有者は人か企業が必要だが、ソフトウェアはどちらでもない。

一文にまとめる。

支払側になるため足りないのはお金より、識別でき、独立記帳でき、上限を設定できる身元だ。

身分証のないソフトウェアは、どう口座を開き、払うか。

宣伝として読まれやすいため、先に半分答える。五問題の一部は、既存の従来方式で十分解ける。 必須と論証するより、オンチェーンが適する条件と、高価で面倒になる条件の境界を探す。後半も同じくらい重要だ。

思考実験

計算できる場面へ絞る。

一日に4000回払う。4000ドルでなく4000回だ。 APIごとに一セント未満を払い、総額は十数ドル程度。

三方式がある。

第一、毎回カードで払う。

すぐ成立しなくなる。多くのカード網には金額に依存しない最低固定費があり、一セント未満では数十〜数百倍になる。4000回なら固定費も4000件だ。

少し高いというより、構造的に成立しない。 数十ドルを日に数回払うための網を、貨物船で手紙を送るように使っている。

第二、前払い口座。 百ドルを入れ、都度残高から引き、月末に明細を出す。

とても使いやすく、今のAPIの大半が採用する。 実際の支払いは一度で、4000回の消費に固定費を薄められる。

問題は費用より構造だ。六サービスなら六口座と入金と照合が必要になる。 登録、法的主体への紐付け、残高管理が各々必要で、40ソフトウェアなら240残高になる。

入金後は、自分のお金より相手の債務になる。 廃業すれば、第1章の王さんの受領証と同じ状況だ。

第三、オンチェーン口座でステーブルコインを都度払う。

まず解くのは費用より、身元だ。 申請も承認も不要で、口座自体がソフトウェアを表し、支払者は台帳で分かる。40口座は数分で作れる。

次は境界だ。 入れた額が予算で、尽きれば止まり、他の資金に触れない。

第三は相手だ。 国外の人やソフトウェアへ、関係を先に作らず少額を数分で渡せる。

未解決も重要だ。 ネットワーク費用が一セント未満の支払いを上回るチェーンや時刻がある。4000送金も成立しない。カードと同じ場所で、桁だけ違って止まる。

実際には第四へ進む。一度のオンチェーン決済と、間の4000回の軽い計量だ。 チェーンはマイクロペイメントそのものより決済を解く。計量は別層で、第35章で扱う。

表へ展開する。

回収不可は、真剣に選ぶ取捨選択だ。 数十年かけて作られた拒付は、払ったのに届かない場合を守る。許可不要と即時決済のため、この保護を除く。

どちらが良いかは相手との関係で決まる。 次で判断する。

あなたが決める

40ソフトウェアに個別に支払わせる。

結果を観察する

支払側には五つ全てが要る。

第一、第二が根だ。口座は法的主体に属するという、長く良く機能した制度で、技術制約ではない。全口座に責任者を求める。

ソフトウェアは今も、予見できる将来も法的主体ではない。

人・企業の名義へ置くか、法的主体不要の台帳を探すかの二道になる。

後者は第5章の、許可なくアドレスを作れ、台帳は身元を問わない性質だ。検閲耐性として語られるものが、ソフトウェア自身で持てる口座という実用になる。

まとめる。

BlockchainはAgentへ身元、ウォレット、支払、決済、監査可能性を提供する。

場面が合うことが前提で、合わなければ同じ五点の高価な版になる。

モデルを作る

一、四条件で経路を選ぶ

最も持ち帰るべき表で、両側が同じくらい重要だ。

三項目以上なら、ほぼ決まる。

大額、低頻度、信頼がある場合は、従来がほぼ全側面で良い。 費用比率、争い、法的回収、窓口、会計対応、新実装不要などだ。

会社からクラウド事業者への月一回の大きな支払は、オンチェーンにすべきではない。 契約、会計、電話窓口があり、替えると争い処理と照合の便利さを失い、重要でない速さだけ得る。

支持という立場より判断力が重要だ。 不適切な場合を説明できなければ、適切な場合も説明できない。

二、五種類の支払先

性質は違う。

第四はほぼ空白だ。 世界各地の個人へ微小労働の数十セントを払う従来経路は、手数料、書式、銀行口座、越境対応で通らない。

四条件に合う、極小、企業口座なし、未知、越境の場面だ。本当の主要用途は、目立つ自動取引よりここかもしれない。

三、身元は三問題

曖昧な一語を分ける。

漏れた鍵で本人と盗んだ人を区別できない。 従来の紛失、凍結、争い、補償に代わるものは、事前の権限設計だ。第34章で扱う。

四、過小評価される監査可能性

前四つより見落とされるが、多数Agentでは最も役立ち得る。

時刻、送付元、相手、金額が公共台帳にあり、協力なしで調べられる。

自然に成立するのでシステム構築が不要だ。40個の完全な支出記録に、照合、明細請求、他者の記録への信頼が要らない。

全員へ公開される面もある。支出、購入先、関係を他者も見られる。第1章の透明性とプライバシーの衝突が、企業の計算購入規模を誰でも測れる形で鋭くなる。

五、使うべきでない場面を真剣に書く

将来改善するという言葉で避けられない、実際の弱点だ。 同じ重要性を持つ。

一、長期の信頼関係。 柔軟な支払期日、交渉できる争い、明細が欲しく、三つとも弱くなる。

二、大額、低頻度。 固定費の優位が消え、不可逆の代償が増す。誤宛先は全損となり、銀行なら回収できることが多い。

三、争い処理が必要。 払って未受領は普通で、拒付、担保取引、法律回収は必要だから存在する。既定ではどれもない。

四、完全な会計手順を持つ企業。 請求書、契約番号、会計期間の記帳が要り、コイン送付は省く以上の仕事を作る。

五、鍵管理ができない。 漏れれば数秒で消え、救済なし。第5章の代償がソフトウェア数倍になる。

六、法令要件が明確でも経路が不明。 匿名アドレスへの送金は、規制事業では将来へ送れない実問題だ。

両面を合わせる。

オンチェーンは常に良い支払より、特定条件で唯一成立する支払だ。

極小額、極高頻度、未知の相手、非法律主体、プログラム処理、越境が条件だ。満たさなければ、通常、従来が明らかに良い。

何と呼ぶか

まとめる。

Blockchainは、少額、高頻度、未知の相手、非法律主体の場面で、Agentへ身元、ウォレット、支払、決済、監査可能性を提供する。

合わなければ、争い、費用比率、接続費用は通常、従来が明らかに良い。

実践

計算とモデル：
データとAPI：
内容と権利：
人の労働：
オンチェーン操作：

一回のおおよその額：桁が分かればよい
一日の回数：
相手：企業 / 個人 / ソフトウェア / 不明
現在の方式：カード / 前払い / 購読 / 払えない

□ 極小で固定費が主要
□ 一日数百回以上の高頻度
□ 契約や長期関係のない未知の相手
□ 企業口座を持つ会社ではない相手

最低入金：
最低消費か月額：
対応する支払方式：

内容：                    国外の個人へ数十セントなど
今できない理由：          手数料 / 口座なし / 法令 / 全て
オンチェーンで解く段階：
解けない部分：            必須。中心となる行
行わなければ課題はどうなるか：

失うもの：請求書 / 契約関係 / 争い処理 / 会計対応 /
          窓口 / 回収可能性 / 明確な法令経路

AI Lab

AI Agentの経済活動にはオンチェーン支払が必須、という命題を論証してください。
1. 六理由を挙げ、各々が依存する具体的な性質を示す。
2. 非チェーンの代替があるか、あればなぜ不十分かを示す。
3. 名称、版、規格、項目名を創作しない。方式だけ説明する。
4. 市場規模や成長予測の具体的数字を引用しない。
5. 最後に成立しない条件を別節にする。

場面：額、頻度、関係まで
従来が良い理由：具体的な仕組み
替えると失うもの：具体的な一つ

□ 大額、低頻度、契約ありの企業間支払い
□ 請求書と記帳が必要な支出
□ 払っても未受領が起きる取引
□ 完全な会計を持つ相手
□ 鍵管理が不足するチーム
□ 明確な法令要件の規制事業

不一致1：
  賛成：
  反対：
  判断に必要な情報：

実例

変数を一つ変える

持ち帰る問い

章末チェック