この記事について

エージェントが別のエージェントに作業を委ね、その対価を支払う場面では、費用見積 → 同意 → 実行・計量 → 請求・決済 → 照合 の一連の流れが要ります。認可（AP2）と決済（x402／MPP／カード網）は2025年9月〜2026年7月に急速に標準化されました。本稿は、それらを置き換えずに、その前後へ「実行してみないと費用が確定しない作業の見積」「A→B→C と下請けする多段委任の枠管理」「決済記録を利用明細へ落とす照合」を足すシーケンス仕様の草案です。

名称：AECS（Agent Estimate, Consent & Settlement）v0.1
位置づけ：AP2 のマンデートと制約（金額上限・予算・支払先・実行期間）を再利用し、各決済レール（x402／MPP／カード／請求書）を選択可能なレールとして扱う上位シーケンス。AECS が独自に規定するのは、見積の不確実性、実行中の計量と再見積、下請け費用の責任関係、ACUS への照合
明細の写像先：前稿「AI利用・課金明細の共通スキーマ ACUS v0.1」のデータセットA
記法：要求水準は 必須／推奨／任意、一次資料で未確認の箇所は ※
基準日：2026年9月10日

本稿は筆者個人の仕様書案であり、Linux Foundation・Google・各決済事業者の公式仕様ではありません。AP2・x402・MPP は改版が速いため、参照時点を明記しています。

1. 背景

1.1 2026年9月時点の状況

取り組み	役割	状態
AP2（Agent Payments Protocol）v0.2	同意（認可）の署名証明。direct モード（人が確定チェックアウトを承認）と autonomous モード（事前署名の open マンデートが後の承認を制約）。Checkout Mandate と Payment Mandate の2種、それぞれ open／closed。Payment Mandate には Amount Range・Budget・Agent Recurrence・Allowed Payee・Allowed Payment Instrument・Reference・Execution Date 等の制約型があり、独自の制約型も定義できる	2026年4月28日に v0.2 を告知。エージェント間のマンデート委任は現行仕様の範囲外と明記
x402	HTTP 402 応答に支払指示（金額・通貨・宛先）を載せ、署名済み支払いをヘッダに付けて再要求する従量決済	2026年4月2日に Linux Foundation が x402 Foundation の設立と Coinbase からの拠出方針を発表、7月14日に運営開始（40組織、Premier に Adyen・AWS・Amex・Circle・Cloudflare・Coinbase・Fiserv・Google・Mastercard・Shopify・Stripe・Visa 等）
A2A x402 拡張	A2A 上で支払要求・支払提出・決済結果を扱う参照実装。AP2 と組み合わせた承認証跡の連携を想定	参照実装公開
MPP（Machine Payments Protocol）	Tempo と Stripe が共同開発した HTTP ネイティブの決済プロトコル。一回払いの Charge と、上限を事前認可して少額決済を継続する Session を持ち、ステーブルコイン・カード等の複数決済手段に対応。取消可能性と確定時点は選んだ決済手段に依存する	2026年3月18日開発者公開
UCP（Universal Commerce Protocol）	商品発見〜チェックアウト〜購入後の商取引語彙。AP2 と互換、A2A 上で運べる。Google・Shopify 等が共同開発	2026年1月公開（2026-01-11版）
A2A v1.0	エージェント間のタスク交換。Agent Card の署名を定義するが署名は任意（MAY）。「何を交渉するか」の語彙は定めない	2026年3月12日 v1.0.0
MCP 認可仕様	ツール接続の OAuth 認可。トークンのパススルー禁止	2025年11月25日版セキュリティ文書

1.2 本稿が参照した範囲で確認できなかった相互運用部分

既存仕様や個別実装には、上限付きの同意、実行中の計量、事後精算、複数レールの証跡がそれぞれ存在する（16章）。本稿が追加を試みるのは、次の4点を一連のプロファイルとしてつなぐ部分である。

不確定消費の見積語彙：AP2 の Amount Range／Budget は「上限」を表すが、「見込み範囲と信頼度」「実行中の完了予測」「見積と実績の差異」を運ぶ構造は確認できなかった
多段委任の枠管理：AP2 はエージェント間のマンデート委任を現行仕様の範囲外としている。A→B→C の下請けで、親の上限を子に分割し、二重予約を防ぎ、責任の連鎖を保つ規則が要る
明細への照合：署名付き決済記録があっても、それを ACUS のような利用明細に落とし、見積差・計測差・単価差を分類する共通の写像は確認できなかった
取消可能性の非対称：カードには紛争処理があるが、決済済みステーブルコイン送金にはチャージバックがないため、統制は送金前に置く必要がある。レールごとの reversible／finality を見積の段階で明示する

2. 用語

用語	定義
本人（Principal）	費用を最終的に負担し、同意に署名する主体（人または組織）
依頼エージェント（Requester）	本人に代わって作業を依頼し、見積を受け、同意を運ぶエージェント
提供エージェント（Provider）	作業を実行し、見積・計量報告・受領証を発行するエージェント
下請けエージェント（Subprovider）	提供エージェントからさらに部分作業を受けるエージェント
検証者（Verifier）	同意（マンデート）の署名・制約を検証する主体。AECS の抽象役割であり、AP2 の各検証主体（加盟店、決済処理者、ネットワーク等）をまとめたもの
決済レール（Rail）	x402、MPP、カード網、請求書払い、組織内台帳など、実際に価値を移転する仕組み
上限（Cap）	同意で許容される費用の絶対上限（not-to-exceed）。AP2 の Amount Range／Budget に対応する
受領証（Receipt）	提供エージェントが署名して発行する利用・費用受領証。使用量・費用・決済参照を含む。AP2 や MPP の決済証跡（支払済み証明）とは別物で、必ずしも同じではない
確定性（finality）	決済が取り消し不能になる条件と時点。単なる請求締日ではない
照合（Reconcile）	受領証を利用明細（ACUS）へ写像し、見積・計測・請求の差異を分類すること

AP2 の文脈で MPP は Merchant Payment Processor（加盟店決済処理者）を指すことがある。本稿では Machine Payments Protocol のみを MPP と書き、AP2 の役割は「加盟店決済処理者」と書く。

3. 適用範囲

対象

エージェント間の有償作業委託（推論・検索・データ処理・ツール実行など、費用が実行後に確定するもの）
単発タスク、および上限付きで継続するタスク
人が居る（human-present）場合と居ない（autonomous）場合の両方
多段委任（提供エージェントが下請けに出す場合）
支払前に履行確認（検収）を置く運用

対象外

決済レールそのもの（x402・MPP・カード網の内部仕様）
同意の署名形式（AP2 マンデートの構造を参照するに留める）
物品の商取引（UCP の領域）
作業品質の評価・SLA 違反時の減額（v0.3 以降の検討事項）

4. 役割と信頼モデル

役割	署名する対象	検証する対象
本人	Consent	Quote、Receipt
依頼エージェント	QuoteRequest（任意）	Quote、MeterReport、Receipt、sub_receipts の下請け署名
提供エージェント	Quote、MeterReport（任意）、Receipt	Consent
下請けエージェント	Quote（sub）、Receipt（sub）	SubConsent
検証者	—	Consent の署名と制約
決済レール	決済結果	SettlementRequest の冪等キー・上限

信頼の前提は次の3点に置く。

エージェントの識別：A2A では Agent Card の署名は任意である。AECS の採用プロファイルでは Agent Card の署名検証と、信頼する鍵・発行者の判定を別途必須とする。署名があることは、その発行者を信頼する根拠の代わりにはならない
同意の有効性：AP2 マンデートの検証に委ねる。AECS の Consent は AP2 マンデートへの参照と、AP2 の制約に対応する値、AECS 固有の制約（超過方針・委任方針）を持つ。実行条件は「AP2 の制約と AECS の制約の両方を満たすこと」
費用の根拠：受領証の明細行で示し、明細の語彙は ACUS（x_ModelId／x_AccessPath／x_TokenType／ConsumedQuantity／PricingUnit）を用いる

5. 全体シーケンス

フェーズは 見積（6章）→ 同意（7章）→ 実行・計量（8章）→ 請求・決済（9章）→ 照合（10章） の5つ。多段委任は11章、状態遷移は12章で扱う。事前認可・資金確保が必要なレール（MPP Session、x402 の支払認証等）では、その手順を実行開始の前提に置く。

6. フェーズ1：見積（Quote）

6.1 見積の4類型

類型 `quote_type`	内容	適する作業	上限の扱い
`fixed`	確定額	定型処理、成果物が事前に定義できるもの	Consent.cap は確定額に一致させる
`unit_rate`	単価のみ提示（数量は事後確定）	API 中継、従量課金の透過的な転嫁	Quote に cap なし。Consent 側で cap 必須
`capped`	見込み額＋上限額（not-to-exceed）	推論を伴う非定型作業	Quote に cap を含む
`estimated`	見込み範囲と信頼度のみ	探索的作業、初回依頼	Quote に cap なし。Consent 側で cap 必須

capped を既定とする。unit_rate／estimated は Consent で cap が補われない限り実行に進めない（規則 Q4）。

6.2 QuoteRequest

{
  "aecs_version": "0.2",
  "quote_request_id": "qr-7f3a",
  "requester": {"agent_id": "did:example:req-01", "on_behalf_of": "did:example:principal-01"},
  "task": {
    "task_id": "task-2026-09-10-0042",
    "description": "国保システム不具合に関する報道25件を要約し、時系列表にまとめる",
    "inputs": {"documents": 25, "approx_input_chars": 180000},
    "deliverable": "markdown_table"
  },
  "constraints": {
    "max_cost": {"amount": "5.00", "currency": "USD"},
    "deadline": "2026-09-10T12:00:00Z",
    "data_residency": "JP",
    "preferred_rails": ["mpp", "invoice"],
    "require_reversible": true
  },
  "reporting": {"meter_interval_pct": 25, "meter_basis": "budget", "warn_threshold_pct": 80}
}

reporting.meter_basis は、報告しきい値を進捗率（progress）で測るか予算消費率（budget）で測るかを指定する。

6.3 Quote

{
  "aecs_version": "0.2",
  "quote_id": "q-1c9e",
  "quote_request_id": "qr-7f3a",
  "provider": {"agent_id": "did:example:prov-01"},
  "task_ref": {"task_id": "task-2026-09-10-0042", "description_ref": "qr-7f3a#task.description"},
  "quote_type": "capped",
  "price": {
    "currency": "USD",
    "estimate": {"low": "0.90", "expected": "1.12", "high": "1.80", "confidence": 0.8},
    "cap": "2.00",
    "unit_rates": [
      {"acus_ref": {"x_ModelId": "anthropic/claude-sonnet-5", "x_AccessPath": "direct", "x_TokenType": "input"}, "pricing_unit": "1000000 Tokens", "unit_price": "2.00"},
      {"acus_ref": {"x_ModelId": "anthropic/claude-sonnet-5", "x_AccessPath": "direct", "x_TokenType": "cache_read"}, "pricing_unit": "1000000 Tokens", "unit_price": "0.20"},
      {"acus_ref": {"x_ModelId": "anthropic/claude-sonnet-5", "x_AccessPath": "direct", "x_TokenType": "output"}, "pricing_unit": "1000000 Tokens", "unit_price": "10.00"}
    ],
    "price_sheet_ref": "acus-price-sheet://anthropic/2026-09-01",
    "fees": [{"kind": "orchestration", "amount": "0.20"}]
  },
  "assumptions": {
    "expected_input_tokens": 260000, "expected_output_tokens": 40000, "tokenizer": "anthropic-2026",
    "basis": "expected は単価×想定トークン＋手数料の単純計算値。high は過去の同種タスクの上位分位"
  },
  "settlement_options": [
    {"rail": "mpp", "method": "card", "intent": "session", "reversible": true, "finality": "authorize_then_capture", "preauth_required": true},
    {"rail": "invoice", "method": "bank_transfer", "intent": "charge", "reversible": true, "finality": "monthly_invoice", "preauth_required": false}
  ],
  "sub_quotes": [],
  "valid_until": "2026-09-10T10:00:00Z",
  "signature": {"alg": "EdDSA", "kid": "prov-01-key-2026", "value": "..."}
}

金額はすべて説明用の架空値。expected（1.12）は assumptions の単純計算値（0.52＋0.40＋0.20）に一致させ、予備費は high に持たせる。settlement_options の reversible／finality は、このプロバイダーが選んだ決済手段・実装プロファイルの値であり、レール一般の性質ではない（9.2）。

6.4 見積の規則

ID	規則	水準
Q1	Quote は提供エージェントが署名し、`valid_until` を持つ	必須
Q2	`unit_rates` の各行は ACUS の `x_ModelId`／`x_AccessPath`／`x_TokenType` で識別し、`pricing_unit` は FOCUS UnitFormat（例：`1000000 Tokens`）に従い、`price_sheet_ref` で定価表を参照する	必須
Q3	`estimate` は `low`／`expected`／`high` と `confidence`（0〜1）を持つ。算出根拠（単純計算か、過去分布か、入力量推定か）を `assumptions.basis` に記す	必須
Q4	`quote_type`＝`estimated` または `unit_rate` の Quote は、Consent 側で `cap` が補われない限り実行に進めない	必須
Q5	下請けを使う場合は `sub_quotes` に下請けの Quote を内包し、自らの `cap` は下請け分を含む合計とする	必須
Q6	`settlement_options` には各選択肢の `method`／`intent`、`reversible`（取消可能性）、`finality`（確定性）、`preauth_required`（事前認可・資金確保の要否）を明示する	必須
Q7	QuoteRequest の `task.description` および Quote が保持する説明フィールドには本人の個人情報を含めない。必要なら参照IDに置き換える	推奨

7. フェーズ2：同意（Consent）

7.1 同意の種類と AP2 マンデートの対応

AECS `mode` × `consent_type`	AP2 v0.2 の対応	用途
`human_present` × `closed`	direct モード、closed マンデート	確定額（`fixed`）の承認
`human_present` × `open`	人が上限付き open マンデートに署名する。これはその後の autonomous 利用のための事前承認であり、direct とは区別される	`capped` の承認
`autonomous` × `open`	autonomous モード、事前署名の open マンデート	定常的な委任、夜間バッチ等
`autonomous` × `closed`	エージェントが open マンデートの範囲内で closed を生成	個別決済の確定

AP2 の Checkout Mandate（購入認可）と Payment Mandate（支払認可）の分離は AECS でも維持し、Consent は両者への参照を持つ。AP2 の初期発表（2025年9月）では Intent／Cart 等の名称が使われたが、本稿は v0.2 の Checkout／Payment を参照する（旧名称からの再編経緯の全体は未確認※）。マンデート自体のスキーマ版は vct の数値接尾辞で識別されるため、mandate_ref.version に加えて実マンデートの vct と署名・委任チェーンを版対応アダプターで検証する。

7.2 AECS の制約と AP2 制約の対応

AECS 要素	AP2 の対応	扱い
`cap`（単一取引の上限）	Payment Mandate の Amount Range（`payment.amount_range`）	両方を満たすことが実行条件。AECS の `cap` は AP2 の `max` 以下
ルート同意をまたぐ累積上限	Budget（`payment.budget`、Agent Recurrence と併用）	AP2 側の累積管理を上書きしない
継続タスク	Agent Recurrence（`payment.agent_recurrence`）	期間・回数は AP2 に従う
支払先	Allowed Payee（`payment.allowed_payees`）	提供エージェント・下請けの受取先を許容集合に含める
決済手段	Allowed Payment Instrument／Allowed PISP	`accepted_rail` の文字列と同一ではない。選択した手段がマンデートで許可されることを確認
Quote との束縛	Reference（`payment.reference`）	`quote_id` 文字列だけでなく、open Checkout へのハッシュ参照で束縛
実行期間	Execution Date（`payment.execution_date`）と JWT の有効期限	Quote 有効期限・Consent 有効期限・決済実行期限を同義にしない
`overage_policy`、`delegation`	AP2 に同名の標準制約は確認できず	AECS 固有の制約型として定義し、AP2 の拡張規約に従い衝突しない名前空間（例：`org.example.aecs.overage_policy`）で表す。署名対象に含め、参照IDだけで外付けしない

AP2 の金額単位（最小通貨単位の整数か小数表記か）は仕様本文の表と例で表記が揃っていない※。AECS の金額から AP2 の金額へ変換する際は、採用版の正式スキーマと適合試験に合わせ、小数ドルをそのまま最小通貨単位の整数欄へ転記しない。

7.3 Consent

{
  "aecs_version": "0.2",
  "consent_id": "c-58b2",
  "root_consent_id": "c-58b2",
  "amendment": null,
  "quote_id": "q-1c9e",
  "mode": "autonomous",
  "consent_type": "open",
  "mandate_ref": {"protocol": "ap2", "version": "0.2", "checkout_mandate_id": "cm-...", "payment_mandate_id": "pm-...", "vct": "..."},
  "cap": {"amount": "2.00", "currency": "USD"},
  "overage_policy": {"mode": "requote", "auto_up_to": null},
  "delegation": {"allow_sub": true, "sub_cap_total": "0.50", "max_depth": 1},
  "accepted_rail": {"rail": "mpp", "method": "card", "intent": "session"},
  "budget_ref": "budget:2026:info-policy:ai-research",
  "acceptance_required": false,
  "valid_until": "2026-09-10T12:00:00Z",
  "signer": {"principal_id": "did:example:principal-01", "signed_at": "2026-09-10T09:05:00Z"},
  "signature": {"alg": "EdDSA", "kid": "principal-01-key", "value": "..."}
}

overage_policy.mode の値は次の3つ。いずれも cap を超える実行・請求は許さない。

値	残枠しきい値に達したときの挙動
`reject`	しきい値到達時点で停止し、部分成果を返す
`requote`	提供エージェントが追加分を再見積し、追加 Consent（`amendment`）を待つ（既定）
`auto_up_to`	警告しきい値を超えても `auto_up_to`（`cap` 以下）まで自動継続する。`cap` の引上げには再見積・再同意が必要

追加 Consent は root_consent_id で元の同意を指し、amendment＝{"type": "increment", "parent_consent_id": "..."} または {"type": "replace", ...} で増分か置換かを明示する。

7.4 同意の規則

ID	規則	水準
C1	Consent は Quote を一意に参照し、Quote の `valid_until` 内に署名される	必須
C2	`cap` は、Quote に `cap` がある場合はその値以下、QuoteRequest に `max_cost` がある場合はその値以下。`fixed` では確定額に一致させる	必須
C3	`autonomous` モードでは `overage_policy` を必須とし、`auto_up_to` を使う場合は `cap` 以下の値を本人が事前署名する	必須
C4	下請けを許す場合は `delegation.allow_sub`＝true とし、`sub_cap_total`（下請け合計上限、`cap` 以下）と `max_depth`（委任段数）を定める	必須
C5	`budget_ref` により組織の予算枠に紐づける。複数 Consent の `cap` 合計が予算枠を超えないかは依頼側の統制で担保する	推奨
C6	提供エージェントは Consent を検証者に検証させてから実行する。検証結果は Receipt に含める	必須
C7	Consent の内容は構造化データとしてのみ扱い、プロンプト経由で上限や方針を変更させない。上限の判定はモデルの外側で行う	必須
C8	追加 Consent は `root_consent_id` と `amendment` を持ち、同じ Consent を一度だけ反映する。累積上限＝ルートの `cap`＋各 `increment` の合計（`replace` はその時点の総額に置換）	必須
C9	ルート同意ごとに「確定費用＋実行中の予約額＋下請けへの予約額」が累積上限以下であることを原子的に管理し、超えるものは開始しない	必須
C10	AP2 の制約と AECS の制約は両方を満たすことを実行条件とし、AECS 固有の制約は署名対象に含める	必須

8. フェーズ3：実行と計量（Execute & Meter）

8.1 MeterReport

{
  "aecs_version": "0.2",
  "consent_id": "c-58b2",
  "root_consent_id": "c-58b2",
  "task_id": "task-2026-09-10-0042",
  "seq": 3,
  "at": "2026-09-10T09:40:00Z",
  "progress_pct": 75,
  "usage": [
    {"x_ModelId": "anthropic/claude-sonnet-5", "x_AccessPath": "direct", "x_TokenType": "input", "consumed_unit": "Tokens", "consumed_quantity": 210000},
    {"x_ModelId": "anthropic/claude-sonnet-5", "x_AccessPath": "direct", "x_TokenType": "cache_read", "consumed_unit": "Tokens", "consumed_quantity": 90000},
    {"x_ModelId": "anthropic/claude-sonnet-5", "x_AccessPath": "direct", "x_TokenType": "output", "consumed_unit": "Tokens", "consumed_quantity": 31000}
  ],
  "usage_source": "provider_billable",
  "cumulative_cost": {"amount": "0.948", "currency": "USD"},
  "reserved_cost": {"amount": "0.150", "currency": "USD"},
  "cap_remaining": {"amount": "1.052", "currency": "USD"},
  "projected_final": {"expected": "1.10", "high": "1.40"},
  "sub_reports": []
}

cumulative_cost はトークン費用 0.748（0.420＋0.018＋0.310）＋手数料 0.200 の厳密値。reserved_cost は開始済みで未確定の操作の最大見込額。丸めは表示時にだけ行い、報告値は小数3桁以上の厳密値とする（規則 M7）。

8.2 しきい値と再見積

8.3 計量の規則

ID	規則	水準
M1	提供エージェントは QuoteRequest の `meter_interval_pct`（`meter_basis` の基準）ごと、および `warn_threshold_pct` 到達時に MeterReport を送る	必須
M2	`usage` は課金対象の量（プロバイダー応答の使用量）で報告し、`usage_source` に `provider_billable`／`self_measured` を明示する	必須
M3	`cumulative_cost`＋`reserved_cost`＋次に開始する操作の最大見込額が累積上限を超える操作は開始しない。最大額を拘束できない操作は、開始前の追加承認または提供側負担等の契約条件を要する	必須
M4	`projected_final.high` が累積上限を超えると予測された時点で `overage_policy` に従う。累積上限を超えて実行を継続してはならない	必須
M5	追加 Consent の反映後は累積上限を更新し、MeterReport の `cap_remaining` を更新後の値で報告する	必須
M6	実行が中断された場合も、その時点までの使用量は Receipt に載せ、`status`＝`partial` とする	必須
M7	金額は小数3桁以上の厳密値で持ち、丸めは表示時と決済時にだけ行う。決済時の丸め残差の累積・最終精算規則を 9.3 の S8 に従って定める	必須

9. フェーズ4：請求・決済（Settle）

9.1 Receipt

{
  "aecs_version": "0.2",
  "receipt_id": "r-9a11",
  "consent_id": "c-58b2",
  "root_consent_id": "c-58b2",
  "quote_id": "q-1c9e",
  "task_id": "task-2026-09-10-0042",
  "provider": {"agent_id": "did:example:prov-01"},
  "status": "completed",
  "period": {"start": "2026-09-10T09:06:00Z", "end": "2026-09-10T09:52:00Z"},
  "lines": [
    {"x_ModelId": "anthropic/claude-sonnet-5", "x_AccessPath": "direct", "x_TokenType": "input", "consumed_unit": "Tokens", "consumed_quantity": 240000, "pricing_unit": "1000000 Tokens", "pricing_quantity": "0.24", "unit_price": "2.00", "cost": "0.480"},
    {"x_ModelId": "anthropic/claude-sonnet-5", "x_AccessPath": "direct", "x_TokenType": "cache_read", "consumed_unit": "Tokens", "consumed_quantity": 110000, "pricing_unit": "1000000 Tokens", "pricing_quantity": "0.11", "unit_price": "0.20", "cost": "0.022"},
    {"x_ModelId": "anthropic/claude-sonnet-5", "x_AccessPath": "direct", "x_TokenType": "output", "consumed_unit": "Tokens", "consumed_quantity": 38000, "pricing_unit": "1000000 Tokens", "pricing_quantity": "0.038", "unit_price": "10.00", "cost": "0.380"},
    {"kind": "fee", "x_UsageType": "fee", "description": "orchestration", "cost": "0.200"}
  ],
  "total": {"amount": "1.082", "currency": "USD"},
  "settled_amount": {"amount": "1.08", "currency": "USD", "rounding": "half_even_2dp", "residual": "0.002"},
  "cumulative_cap": {"amount": "2.00", "currency": "USD"},
  "verification": {"verifier_id": "did:example:verifier-01", "result": "ok", "at": "2026-09-10T09:05:30Z"},
  "settlement": {"rail": "mpp", "method": "card", "intent": "session", "tx_ref": "mpp-session-...", "idempotency_key": "c-58b2:1", "reversible": true, "finality": "authorize_then_capture", "settled_at": "2026-09-10T09:53:00Z"},
  "sub_receipts": [],
  "signature": {"alg": "EdDSA", "kid": "prov-01-key-2026", "value": "..."}
}

lines の合計 1.082 は total に一致し、累積上限 2.00 以下。settled_amount は決済レールの最小単位に丸めた決済額で、残差 0.002 は次回精算に繰り越す（S8）。

9.2 決済レールの抽象化

reversible／finality はレール一般の性質ではなく、選んだ決済手段（method）と実装プロファイルで決まる。Quote の settlement_options に選択肢ごとの値を書く。

`rail`	実体	`intent` の例	`reversible`／`finality`	事前認可・資金確保
`x402`	HTTP 402 ベースの決済（ステーブルコイン等）	1リクエストごとの支払	決済手段に依存。オンチェーン確定後は原則不可逆	支払認証が要求ごとに必要
`mpp`	Tempo・Stripe 共同開発の HTTP ネイティブ決済。Charge（一回払い）と Session（上限事前認可＋継続少額決済）	`charge`／`session`	決済手段に依存（カード経由なら承認→確定、ステーブルコイン経由なら確定後不可逆）	Session は上限の事前認可・預託を要する
`card`	カード網（エージェント向けトークン化）	1取引	承認→清算。紛争処理あり	承認（オーソリ）が事前確保に相当
`invoice`	請求書払い（組織間）	期間集約	月次確定。訂正は請求書の再発行	不要
`internal`	組織内台帳（部門間振替）	任意	任意	不要

9.3 請求・決済の規則

ID	規則	水準
S1	ルート同意に紐づく全 Receipt の `total` 合計は累積上限を超えてはならない。単票が上限以下でも累計超過は拒否する	必須
S2	SettlementRequest は `idempotency_key`（`root_consent_id`＋連番）を持つ。失敗後の再試行は同一キーを再使用し、新しい連番は別の正当な決済にだけ割り当てる。決済レールは同一キーの再要求を二重決済しない	必須
S3	Receipt は提供エージェントが署名し、`lines` は ACUS の語彙で書く。`unit_price` は合意済み Quote の `unit_rates` に一致させる。Quote に明示された可変単価条件を適用する場合を除き、単価変更は追加 Quote と Consent で承認する。`notes` は承認済み変更または異常の説明であり、変更の認可に代わらない	必須
S4	QuoteRequest で `require_reversible`＝true が指定された場合、`reversible`＝false の選択肢は選べない	必須
S5	中断（`partial`）の場合も Receipt を発行し、決済額は実使用分に限る	必須
S6	決済結果（`tx_ref`）を Receipt に含め、依頼側が決済レール側の記録と突合できるようにする	必須
S7	上限・署名・単価・累計の検証は決済要求の前にも行い、不合格なら決済せず `disputed` に遷移する（12章）	必須
S8	決済額は決済レールの最小単位に丸め、`settled_amount` に丸め方式と残差を記す。残差は同一ルート同意内で累積し、最終 Receipt で精算する	必須
S9	検収を置く運用（Consent の `acceptance_required`＝true）では、依頼側の履行確認後に決済要求を出す	条件付き必須

10. フェーズ5：照合（Reconcile）

10.1 Receipt → ACUS 行への写像

本例は「定価＝契約価、枠控除・税・償却・通貨換算なし」の最も単純なケース。一般には BilledCost／EffectiveCost を FOCUS の定義どおり別計算する。

Receipt の要素	ACUS v0.2（データセットA）の列
`lines[].x_ModelId`／`x_AccessPath`／`x_TokenType`	同名列
`lines[].consumed_unit`／`consumed_quantity`	`ConsumedUnit`／`ConsumedQuantity`
`lines[].pricing_unit`／`pricing_quantity`／`unit_price`	`PricingUnit`／`PricingQuantity`／`ListUnitPrice`（データセットBで検証）
`lines[].cost`	`ListCost`＝`ContractedCost`＝`BilledCost`＝`EffectiveCost`（本例の前提）。Σ が `total` に一致
`lines[].kind`＝`fee`	`x_UsageType`＝`fee`、`ChargeDescription`＝`description`
`settled_amount` と `total` の差	`ChargeCategory`＝Adjustment の行（丸め残差）または次回精算に繰越
`period.start`／`end`	`ChargePeriodStart`／`ChargePeriodEnd`
`task_id`	`x_WorkflowId`
`consent_id`／`receipt_id`	`x_ConsentId`／`x_ReceiptId`
`settlement.rail`／`tx_ref`	`x_SettlementRail`／`x_SettlementRef`
`provider.agent_id`	`x_ProviderAgentId`
`sub_receipts[]`	別行に展開し `x_LineRole`＝`breakdown`、`x_ParentReceiptId` で親を参照。`BilledCost`／`EffectiveCost` は NULL（非加算）
`total.currency` と請求通貨の差	`PricingCurrency*` 列と `x_FxRate`／`x_FxRateDate`
Receipt の `status`	`Tags` に `aecs_status` として保持

本人側の請求明細には親 Receipt だけを x_LineRole＝billed として計上し、子明細は根拠内訳として非加算で持つ。提供者側の仕入台帳（下請けへの支払）は別の請求主体として分離する。

10.2 差異の分類

種別	定義	主な原因
見積差	Quote `expected` と Receipt `total` の差	入力量推定の誤り、キャッシュヒット率の変動
計測差	Receipt `consumed_quantity` と依頼側自己計測の差	トークナイザ差、システムプロンプト等の見えない入力
単価差	Receipt `unit_price` と Price Sheet の差	価格改定、修飾子（バッチ等）の適用漏れ
丸め差	`total` と `settled_amount` の差	決済レールの最小単位
為替差	単価通貨と請求通貨の換算差	レート基準日
未請求	MeterReport はあるが Receipt がない	提供側障害、決済失敗
二重請求	同一 `idempotency_key` で複数の決済記録	レール側の冪等性違反
上限超過	Receipt 累計が累積上限を超過	規則 S1 違反。支払拒否の根拠

11. 多段委任

ID	規則	水準
D1	提供エージェントは親 Consent の `delegation.allow_sub`＝true のときのみ下請けに出せる	必須
D2	SubConsent は親 Consent を参照し、その `cap` は親の `sub_cap_total` から予約した範囲内で分割する。兄弟の下請けを同時に承認する場合も、予約合計が `sub_cap_total` を超えないよう原子的に管理する（C9）	必須
D3	委任段数は親 Consent の `max_depth` を超えない。下請けがさらに下請けする場合も同じ	必須
D4	下請けの MeterReport と Receipt は提供エージェントが合算・内包して依頼側に返す。親の `total` は子費用を含み、`sub_receipts` は内訳である。依頼側は内包された sub_receipts を展開して照合できるが、集計には親だけを含める（10.1）	必須
D5	本人に対する費用の責任は提供エージェントが負い、下請けとの精算は提供エージェントと下請けの間で完結させる（本人は下請けと直接契約しない）	必須
D6	`sub_receipts` は下請けの署名を保ったまま内包し、依頼側が下請けの署名を直接検証できるようにする	推奨

12. 状態遷移

Cancelled が直接終端になるのは課金対象の使用量がゼロの場合だけ。使用済みなら partial として Completed に進み、Receipt と精算を行う（M6／S5）
Requoting へ進むのは overage_policy＝requote の場合。reject／auto_up_to は Executing 内で処理する
Disputed は決済前（上限超過・単価不一致・署名不合格）と決済後（差異申立）の両方から入る

13. セキュリティと監査

項目	要件
署名対象	Quote・Consent・Receipt の署名対象には、版・当事者・Quote 本文またはそのダイジェスト・同意ID・通貨・上限・期限・委任条件を含める。JSON の正規化方式と鍵解決方式は署名プロファイル（15章）で定める
リプレイ防止	Quote は `valid_until`、Consent は `valid_until` と `quote_id` の一意参照、SettlementRequest は `idempotency_key` で防ぐ。認可済み Consent の使用状態（未使用／実行中／消費済み）を永続管理し、有効期限内の再使用と、ID が指す Quote 本文の差替えを検出する
上限の強制	上限の判定は提供エージェントの実行制御（モデルの外側）で行う。プロンプトインジェクションで上限や方針が変更されないよう、Consent は構造化データとしてのみ扱う。実行中の未確定費用は予約として上限に算入する（M3）
識別	Agent Card の署名検証と、信頼する鍵・発行者の判定を採用プロファイルで必須にする。署名の存在は信頼の根拠にならない
最小ログ	`quote_id`／`consent_id`／`root_consent_id`／`receipt_id`／`task_id`／累積上限／`total`／`settled_amount`／`rail`／`method`／`tx_ref`／検証結果を、少なくとも会計上の保存期間だけ保持する
個人情報	Quote・Receipt の説明フィールドに本人の個人情報を書かない。作業内容は参照IDで指し示す
鍵の失効	Agent Card の鍵が失効した場合、その鍵で署名された未決済の Quote は無効とし、再見積を要する

14. 公会計との対応（試案）

地方公共団体の会計手続に当てはめると、AECS の各要素は「権限ある者の正式な手続を支える記録候補」として次のように読める。Consent の署名や提供側の Receipt だけで法定手続が成立するわけではない。現行条文・個別自治体の会計規則・国の会計法令との逐条照合は未了（※）。

会計上の行為	AECS の要素（記録候補）
予算（歳出予算の範囲内）	Consent の `budget_ref` と、複数 Consent の `cap` 合計の統制（C5）
支出負担行為	上限付き open Consent の署名
支出命令	closed Consent、または検収後の決済承認
検収（給付の完了確認）	`acceptance_required`＝true の運用での履行確認（S9）。Receipt の検証（署名・明細・成果物）
精算・過不足の処理	Reconcile（見積差・計測差・丸め差の分類と処理）
前金払・概算払	履行前に支払うか、金額確定前に暫定払いするかで判定する。`reversible` は決済の巻戻しに関する独立の属性であり、前払いの有無とは別軸。完了後決済の既定シーケンス（5章）は前払いに当たらないが、MPP Session の預託や x402 の要求ごと支払は前払い相当になりうるため、適用要件を別途確認する※

15. 未決事項

見積の算出方法：提供エージェントが estimate をどう出すか（過去分布、入力量推定、モデル別のトークン膨張率）。見積精度の開示義務をどこまで課すか
中断時の費用負担：reject で部分成果になった場合、依頼側は実使用分を全額負担するのか、成果物の有用性で減額するのか
署名プロファイル：JSON 正規化（JCS 等）、鍵解決（Agent Card／DID）、署名対象の範囲、SD-JWT との関係
AP2 金額単位の変換：最小通貨単位の整数と小数表記の扱い※
多通貨の上限：cap と unit_rates の通貨が異なる場合の換算基準日
下請けの信頼：D6 の署名内包で足りるか、下請け Receipt の偽装検知に追加の手段が要るか
取消不能レールでの紛争：x402 等で決済後に差異が見つかった場合の是正手段（返金要求プロトコルの要否）
継続タスク：定常監視のような終わりのないタスクに対する Consent の期間・上限の再設定サイクル（AP2 の Agent Recurrence との分担）
MCP ツール課金：MCP 自体に価格語彙がないため、ツール呼び出し課金を Quote の unit_rates にどう載せるか
A2A 拡張としての表現：拡張 URI・Agent Card への能力宣言の書式
旧マンデート名称からの再編経緯：AP2 の初期3マンデート構成から v0.2 への変換表※

16. 関連する取り組み

名称	確認した機能	AECS との重なり・差分
AP2 v0.2	金額上限・累積予算・支払先・実行期間を制約した署名済みマンデート。独自制約型の拡張規約	同意と上限は AP2 を再利用。エージェント間委任は AP2 の範囲外
x402／x402 Foundation	HTTP 402 ベースの要求ごと支払	決済レールの一つ。見積・計量は扱わない
MPP（Tempo・Stripe）	Charge／Session、複数決済手段、支払証跡	Session の事前上限は AECS の `cap` と重なる。見積分布・多段委任・明細照合は扱わない
UCP（Google・Shopify 等）	商取引のチェックアウト語彙	物品商取引側。AECS は作業委託側
IETF Internet-Draft「The Payment HTTP Authentication Scheme」	HTTP 認証による支払要求と Payment-Receipt	支払要求・証跡の既存ドラフト（RFC ではない）。見積・多段委任は扱わない
Agent Commerce Kit（Catena Labs）ACK-Pay	支払要求・期限・支払選択肢・受領証サービス	支払要求と証跡で重なる。不確実見積と枠管理は確認できず
Nevermined	見積と実費による動的価格、x402 上の委任と支払上限	「見積＋上限」の個別実装例。ベンダー横断の明細写像は扱わない
Skyfire KYAPay	識別・支払用トークン、提供後の請求	委任支払・事後精算で重なる。多段の上限管理は確認できず
Agentic Commerce Protocol（Stripe・OpenAI）	チャット内チェックアウト	商取引側。IBM の Agent Communication Protocol（通信プロトコル）とは別物
W3C Payment Request API	ブラウザーの支払要求（Candidate Recommendation Draft）	人向けチェックアウト。エージェント間の原価予測・下請け責任は対象外

参考資料

AP2 仕様本文 https://ap2-protocol.org/ap2/specification/
AP2 Payment Mandate（制約型の定義） https://ap2-protocol.org/ap2/payment_mandate/
AP2 Agent Authorization Framework https://ap2-protocol.org/ap2/agent_authorization/
Google「Agent Payments Protocol and FIDO Alliance」（v0.2 告知、2026年4月28日） https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/
Google Cloud「Announcing Agent Payments Protocol (AP2)」（初期発表、2025年9月16日） https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol
A2A x402 拡張（参照実装） https://github.com/google-agentic-commerce/a2a-x402
Linux Foundation「Launching the x402 Foundation」（2026年4月2日） https://www.linuxfoundation.org/press/linux-foundation-is-launching-the-x402-foundation-and-welcoming-the-contribution-of-the-x402-protocol
Linux Foundation「Operational Launch of x402 Foundation」（2026年7月14日） https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications
Stripe「Introducing the Machine Payments Protocol」（2026年3月18日） https://stripe.com/blog/machine-payments-protocol
MPP ドキュメント https://mpp.dev/
Universal Commerce Protocol（2026-01-11版） https://ucp.dev/2026-01-11/specification/overview/
A2A Protocol v1.0 発表（2026年3月12日） https://a2a-protocol.org/latest/announcing-1.0/
A2A Protocol Specification v1.0.0 https://a2a-protocol.org/v1.0.0/specification/
MCP Security Best Practices（2025-11-25版） https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices
IETF Internet-Draft「The Payment HTTP Authentication Scheme」 https://datatracker.ietf.org/doc/draft-ryan-httpauth-payment/
Agent Commerce Kit — ACK-Pay Payment Request https://www.agentcommercekit.com/ack-pay/payment-request-payload
Nevermined — Dynamic pricing https://nevermined.ai/docs/integrate/patterns/dynamic-pricing
IBM「What is Agent Communication Protocol?」 https://www.ibm.com/think/topics/agent-communication-protocol
前稿「AI利用・課金明細の共通スキーマ ACUS v0.1 仕様書案」https://qiita.com/k2_naka/items/7271004a9d071b08ffd7

制作クレジット

問題設定・選定：筆者
起草・最終稿：Claude Fable 5.1（Anthropic）
事実検証・検証メモ：GPT-6 Astra Pro（OpenAI）
検証メモの精査と一次資料の再照合：Claude Fable 5.1