第35章 · Machine Paymentは新しいインターネットの規格になるか

現実の問題

APIへ要求すると、402、支払いが必要という応答が来た。

ソフトウェアは止まった。

これは奇妙だ。他の応答なら対応が決まっている。404は対象が存在しないので別の場所を探し、401はログインが必要なので認証情報を付けて再試行し、403は権限がないので諦め、429は要求が速すぎるのでしばらく待つ。

全員が同意した次の動作があるから役立つ。意味を理解せず従える。

402だけは例外だ。 数十年予約されても、その後の動作がない。

いくらか。
誰へか。
何で払うか。
支払済みをどう証明するか。
サービスがなければ戻るか。

人ならページ、価格、カード、入力で解く。どれも標準化されず、ソフトウェアにはできない。

数十年間、この問題を二つの方法で避けてきた。広告ではコンテンツを無料にして広告主が費用を負い、アカウントでは先に登録・チャージして関係を築き、その残高から利用分を引く。

どちらも成功し、人が払い、関係が一定期間続くことを前提とする。

支払者がソフトウェアになり、そのAPIを一回しか使わないかもしれないなら、どちらも合わなくなる。広告は意味がなく、数分（元の百分の一の単位）の利用のために登録する摩擦が、取引自体の価値を上回る。

機械同士はAPI一呼出にどう払うか。

問題と通常の方式を扱い、項目名、版、呼出署名は示さない。 急変する規格はすぐ古くなり、誤記憶は未知より悪い。必要なら公式を読み、最新知識を追う方法で一次資料を追う。

思考実験

一日一万回APIを呼び出す。一回の妥当な価格は一分（元の百分の一）未満で、一日の合計は十数元になる。

相手との関係はなく、今日だけ使うかもしれない。

四方式がある。

第一に、サブスクリプション。 提供者は月額を払い自由に使うよう求める。

一日一万回なら割安かもしれないが、継続して使うか先に判断する必要がある。 今日初めて出会ったAPIを一日しか使わなければ、使わない残り二十九日分にも払う。

登録、支払方法、条件同意で関係を先に作る。 人には数分でも、数百APIを動的に選ぶものには、人を要する門だ。

第二、前払い。 入金して都度引き、足りなければ補充する。

第33章のとおり実際の主流で、無数の消費を一決済にまとめ固定費を薄める。

サービス数とAgent数の積が口座数だ。 関係も先に要り、402の瞬間に未登録サービスは使えない。

第三、毎回オンチェーン。

登録も口座も不要で、支払者はアドレスになる。

毎回のネットワーク費が額と同程度以上になり、一万回ではサービス費以上になる。

カードと同じ失敗だ。 大額低頻度の決済を少額高頻度へ使う。

第四、小枠を作り、軽く計数し、定期決済。

四案で唯一成立し得る形で、一度の利用開始はアカウント、中間の計数は計量、定期決済は請求書という既存方式の組み合わせでもある。

ただし利用開始は許可不要にできる。登録ではなく、チェーン上に資金を置くか一度の承認を与えれば数秒で済み、相手の許可を待たない。

表へ置く。

前二つは現実、第四は方向だ。 標準になるかを問う。

第四の二作業は別だ。

計量は使用量、決済は送金を解く。

難点は計量で、分ければ決済は安い経路を選べる。

あなたが決める

ソフトウェア向けAPIで、どう課金するか。

結果を観察する

六問を標準化する必要がある。

情報は標準化したが、お金だけ残った。

設計漏れではない。予約は考えていた証拠だ。越境、少額、関係不要、機械操作に合うお金がなかった。

四十年間、お金の側は銀行、カードネットワーク、決済機関が担い、それぞれAPI、開設条件、対象地域を持っていた。支払が必要とは書けても、全員が使える方式がなく、方法を規格に書けなかった。

第13章の、ネット原生、誰でも保有、開設不要、公開網で移転と決済するお金で初めて可能になる。

中心は次だ。

HTTPは情報を運び、機械経済にはお金を運ぶ規格層も要る。

最近まで規格へ書けるお金がなく、数十年空いていた。

可能性と実現は別で、次に差を扱う。

モデルを作る

一、見積もり・支払・計量の三層

別々に進化できる。

第三の難しさは技術より信頼だ。

月10312回と請求されたら、どう検証するか。 自分も記録して不一致なら誰が決めるか。今は資金も帳簿も相手なので相手が決める。

企業なら契約、継続、評判で許容できる。未知のソフトウェアと提供者では成立しない。

毎回払いは計量問題を消す理由がある。一呼出一支払で照合の余地がないが、費用が許さない。

粗い決済ほど安く、信頼を多く要する。 両端の間で均衡を探す。

二、信頼量で四方式を並べる

下ほど摩擦が小さく、信頼が増す。

要求信頼が場面に合うかを見る。未知相手へ大入金を要求すれば、主張した問題を解いていない。

小額をまとめて決済する方式が、機械の利用に最も向く。 一まとまりの額を踏み倒されても構わないほど小さくし、十分頻繁に決済してエクスポージャーを小さく保つ。完全な不信と完全な信頼の間を、細かく区切る方法だ。

三、三費用で粒度を決める

毎回払えない理由を分ける。

ネットワーク：送金手数料
時間：        確認までの待機
複雑さ：      双方の操作と状態保存

三費用と信頼の取捨選択だ。

合計費用が額の一定割合を超えれば、その粒度で払わない。

割合は用途次第だが、一分（元の百分の一）未満ならほぼ全操作が上回る。 毎回載せない答えは、チェーンが安くなっても単価も下がるので残る。

四、標準は技術だけで決まらない

開頭の問いを決める重要節だ。

HTTPも技術的な最良だけで勝ったわけではない。 複数条件が要る。

第二と第四が主障害で、技術ではない。

双方の採用という難題がある。経路に価値が出るには十分な受取サービスが必要だが、提供者が受け入れるには十分な支払者が先に必要だ。典型的な鶏と卵の問題である。第30章の一般形だ。

第四の障害はさらに厳しい。現状は方式がないのでなく、かなりうまく動く方式がある。 十分なものを置き換えるには、少し良いだけでは足りず、一つの軸で一桁優れるか、旧方式に不可能なことを実現する必要がある。

発表数より次を見る。

1. 実際の受取サービス数。供給側が最重要。
2. 採用理由。新客か費用減か。
3. なしではできない取引があるか。

第三が最強だ。 新しい決済層が普及するのは、単により良いからではなく、従来方式では成立しない種類の取引が現れるときだ。第33章の送れない少額労働が、その形になる。

五、予想される形

まとめると次がありそうだ。

全置換より、HTTP上の任意の合意層だ。 対応先は402へ読める情報を添え、他は口座・購読を続け、併存する。

決済経路は交換可能だ。 ステーブルコインはインターネットネイティブ、口座開設不要、プログラム操作可能の三条件を満たすので自然な候補だが、規格を特定経路へ固定すべきではない。

計量は少数の高価値用途から標準化する。現在未成立の取引が出発点だ。

優れた設計だから普及することが最も起きにくい。決済分野の歴史もそうである。

何と呼ぶか

まとめる。

HTTPは情報を運び、機械経済にはお金を運ぶ規格層も要る。

難点は計量、採用は供給側だ。規格数より受取サービスを見る。

実践

サービス名：
課金方式：             （回数 / 使用量 / 定額 / 混合）
表示価格：
最低チャージ額：
月額料金・最低利用額：
無料枠：
枠を超えた後の扱い：    （段階制？倍額？速度制限？）

表示価格のコスト：     （一回いくらか）
按分コスト：           （月額・最低利用額 ÷ 実際の呼び出し回数）
使い残しのコスト：     （チャージ残高のうち使い切れない部分）
導入コスト：           （登録、連携、資料を読む時間を金額に換算）

一回の実際のコスト = 上記四項目の合計 ÷ 呼び出し回数

一日 ___ 回未満なら都度払いが安い
一日 ___ 回を超えるなら定額が安い
交点：___

クレジットカード対応：
前払いアカウント対応：
何らかのオンチェーン決済対応：
開設に必要な情報：     （メール？会社情報？本人確認？）
ソフトウェアだけで開設できるか：

利用者の種類：          （誰が、どんな場面で）
おおよその使用量：
顧客にならない理由：    （高すぎる？開設できない？一度しか使わない？）
都度払いで受け取れた場合の市場規模：
サービス提供者がまだ実施していない理由：

対応によって増える費用：  （開発、経理、コンプライアンス）
対応によって増える収入：  （現在受け取れない市場を概算）
最大の懸念：
どんな条件なら必ず導入するか：

AI Lab

機械間決済に使われる現在の規格案や考え方を比較してください。

各案について説明してください。
1. 六つの問題のどれを解くか：価格提示、受取人、決済経路、
   完了時点、支払い済みの証明、問題時の対応。
2. 計量の層をどう扱うか。
3. 成熟度：アイデア、提案、実際のサービスで採用済みのどれか。
4. 受け入れている実在のサービスと確認可能な例。
   不明なら「分かりません」と明記してください。

必須条件：
- 仕様名、バージョン、ステータスコード、フィールド名には
  出典文書を示してください。不確かな場合は
  「不明、公式仕様の確認が必要」と書いてください。
- 提案を標準と呼ばないでください。
- 最後に、各案が共通して解決していない問題を別節でまとめてください。

AIの記述           | 自分が確認した内容   | 正しいか
バージョン         |                    |
ステータスコード   |                    |
フィールド名       |                    |
APIの呼び出し方法  |                    |

各案を、提供者はなぜ導入したがるのですか。
導入すると収入が増えるのか、費用が増えるのか答えてください。
費用が増えるなら、何によって提供者を説得するのですか。

実例

導入に何日かかるか？        （一週間を超えるなら普及は遅い）
使わなければ実現できない場面は？（最も強い兆候）
密な小集団で先に動いているか？  （ある種類のサービス同士など）

変数を一つ変える

持ち帰る問い

章末チェック