Loopがパスポートとウォレットを手に入れました：Loopエンジニアリングと従量課金制ウェブの融合

本ブログでは、これまでループエンジニアリングを内部的な規律として2度取り上げてきました。 最初のループエンジニアリングに関する投稿 では、自己継続的なループはガバナンスの効いたランタイムに属すべきだと論じ、 フリートランタイムに関する投稿 では、その議論を単一のループから多数のループへと拡張しました。これに関連する外部的な問題は、2025年後半から2026年中盤にかけてより具体化しました。2025年10月、IETFはWeb Bot Authワーキンググループを設立し、主に人間向けに設計されたウェブサイトにアクセスする自動化クライアントのための暗号学的認証手法の開発に着手しました（現在のプロトコル草案；ワーキンググループの 設立通知、 承認された憲章）。2026年4月2日、Linux Foundationは、HTTPネイティブ決済のためのオープンなx402プロトコルを管理するx402 Foundationを立ち上げました。Linux FoundationのCEOであるジム・ゼムリン氏は立ち上げ時に、このプロトコルの「オープンでコミュニティ主導の拠点」であると述べています（linuxfoundation.org）。そして2026年7月1日、Cloudflareは発表済みのMonetization Gatewayのウェイティングリストを公開しました。これは、同社のネットワーク背後にあるページ、データセット、API、またはMCPツールに対して、AIエージェントを含むあらゆる呼び出し元に課金し、x402で決済を行うことを計画するもので、「エージェントは必要な入力に対して対価を支払うべきである」と明言しています（blog.cloudflare.com）。これらを総合すると――本稿の編集上の統合としてこれらを読み解くと――一部のオリジンやサービスは、自動化クライアントに対して明確な身元証明や支払い条件を提示し始めています。すなわち、 身元を証明すること、そして 従量課金すること計画、実行、検証、継続を繰り返すエージェントループは、その出口において、ますます多くのゲートやメーターに直面するようになっています。これにより、ループエンジニアリングには、ループ内部のランタイムと、それを取り巻くフリートに続く、第3の規律が生まれます。 イグレス（出口管理） — 企業が制御できないネットワーク上での、ループのアイデンティティ、コスト、および挙動を管理すること。

研究開発に注力する企業のプラットフォームエンジニアであるアマラは、 2つのログの間に生じたギャップから問題に気づきました。彼女のチームが運用する競合インテリジェンスループ（研究課題を計画し、ソースを取得し、それに基づいて主張を検証し、チェックリストが満たされるまで継続するスケジュール実行型エージェント）が、引用リストが不自然に少ない、自信に満ちた要約を返すようになったのです。エージェント自身のトレースにはエラーが見当たらず、計画、取得、執筆の各プロセスは正常でした。しかし、イグレスログが事の真相を物語っていました。取得リクエストの多くが、ボット対策を強化したサイトから「403」エラーで返され、一部はパートナー企業の新たに導入された従量課金制APIから「402」エラーで返されていたのです。彼女のリトライロジックは「402」を一時的なエラーと見なしていたため、ループは同じ有料リソースに対して11回も律儀に再リクエストを繰り返し、最終的に諦めてそのギャップを無視して回答を作成していました。システムはクラッシュせず、アラートも鳴りません。ループはただ静かになり、リトライによってモデルとオーケストレーションのリソースを浪費し、不完全で根拠の薄い出力を返すようになっただけでした。アマラが残した一行のインシデント要約こそが、本稿の主張です。 ループの内部は管理されていたが、外部は管理されていなかった。 （アマラは説明のための架空の人物ですが、ここで挙げた障害のパターンは現実のものです。）

1. 時代が求める転換：Webが提示する条件

個々の動向はそれぞれ異なる範囲で進んでおり、それぞれを正確に把握しておく必要があります。 x402が中立的なガバナンス体制を獲得。 2026年4月2日、Linux Foundationは「x402 Foundation」を立ち上げました。これは、Coinbase、Cloudflare、Stripeが主導して開発し、Google、Visa、Microsoftなど約20のテクノロジー企業や決済関連組織が初期支援を表明したx402プロトコルの運営母体です（linuxfoundation.org）。このプロトコルの仕組みは、HTTPで長らく休眠状態にあった「402」ステータスコードを復活させるものです。クライアントが支払いが必要なリソースを要求すると、サーバーが価格と支払い手順を返答し、クライアントが支払いを済ませて証明を添付したリクエストを再送するという流れです。 実験から製品へと移行するメータリング（従量課金）。 Cloudflareの「Pay Per Crawl」は、AIクローラーにコンテンツの対価を請求するプライベートベータ実験として2025年7月に開始されました（blog.cloudflare.com）。2026年7月1日、同社は「Monetization Gateway」のウェイティングリストを公開しました。これは、リクエストごとの課金対象をクローラーからあらゆる呼び出し元へと広げ、対象もページだけでなく、データセット、API、そして本シリーズで特に重要なMCPツールへと拡大する計画です（announcement）。Cloudflareによると、同社のネットワーク上のサイトでは、コンテンツや商用プロパティにアクセスしようとするボットやクローラーに対し、1日あたり10億件以上のHTTP 402レスポンスが送信されています（blog.cloudflare.com）。これらは支払いを要求する応答であり、取引の完了ではありません。また、Cloudflareは2026年9月15日より、新規にオンボーディングされたドメインにおいて、広告を表示するページ上の「トレーニング」および「エージェント」カテゴリをデフォルトでブロックする設定に変更すると発表しました。一方、「検索」は引き続きデフォルトで許可され、顧客が設定を変更することも可能です（blog.cloudflare.com）。 そして、Web Bot AuthがIETFの標準化プロセスに入りました。 Web Bot Auth（ボットやエージェントがリクエストに暗号署名を行うというCloudflareの2025年の提案）は、2025年10月にIETFワーキンググループを立ち上げました。2025年に初めて公開され、2026年5月および6月にAmazonの共同著者を加えて改訂された「Signature Agent Card」レジストリのドラフトや、主要なAIプロバイダーによる初期の署名実装などが、ドラフトおよびセクション2の報道で確認されています。これら単体でウェブが作り変えられるわけではありません。しかし、これらを合わせると、機械によるトラフィックの一部に対して、より明示的なアクセス権や支払いポリシーを課すための起源やサービスが生まれつつあることがわかります。その条件とは、 あなたは誰で、誰が支払っているのか？

本稿を通じて一貫した注意点として、これら2つのレールは同一のシステムではないという点があります。IETFの憲章に基づき、Web Bot Authは、以下にアクセスする自動化クライアントの暗号学的な識別を扱います。 主に人間向けのウェブサイト — これはHTTP API、エージェント間インターフェース、およびエージェントの背後にいるエンドユーザーの識別を明示的に除外しています。一方で、x402形式の支払いシステムは、ページ、データセット、API、MCPツールなど、HTTPでアドレス指定可能なより広範なリソースに適用されつつあります。本稿では、これら2つの取り組みの範囲が異なることを認識しつつ、ループの出口（egress）において明示的な身元確認や支払いポリシーに遭遇する機会が増えていることの証左として、両者を読み解きます。

2. パスポート：Web Bot Authと識別されたループ

30年間、「これはどのボットか？」という問いに対する答えは、誰でも入力できるユーザーエージェント文字列と、誰でも借りられるIPアドレス範囲に依存していました。Web Bot Authは、そのような推測を超えた暗号学的な証拠を追加します。現在のプロトコルドラフトでは、自動化クライアントは各リクエストに秘密鍵で署名し（HTTPメッセージ署名、RFC 9421）、Signature-Agentヘッダーを通じて自身を通知し、公開鍵を既知のディレクトリ（key-directoryドラフト）で公開することで、どのオリジンでも独立して署名を検証できるようにしています（現在のプロトコルドラフト）；リファレンス実装は以下を参照してください。 github.com/cloudflare/web-bot-auth）。これを取り巻く仕組みは2025年から2026年にかけて成熟しました。Cloudflareは2025年7月にメッセージ署名を「Verified Bots」プログラムに統合し（blog.cloudflare.com）、同年8月には署名付きエージェントのトラックを開始しました（blog.cloudflare.com）また、エージェントの識別情報、オペレーター、想定リクエストレート、鍵を保持する「Signature Agent Card」レジストリのドラフトが2025年に初めて公開され、2026年5月および6月に改訂されました。このドラフトにはCloudflareの著者に加えAmazonの著者も参加しており、現在もInternet-Draftとして進化を続けています（現在のドラフト）。導入はまだ初期段階であり、普及状況もまちまちです。Cloudflareによると、OpenAIのChatGPTエージェントはWeb Bot Authを使用してリクエストに署名を行っています（ソース）、AmazonはAgentCore Browserプレビューで署名サポートを提供しており（AWSドキュメント）、VercelはWeb Bot Authトラフィックの検証をサポートしています（Vercelの変更履歴）— これらは実装例であり、普遍的な普及には至っていません。しかし、現状の統計よりも重要なのはその方向性です。オリジン（配信元）は、信頼できる方法で選択したエージェントを許可し、それ以外を拒否する手段を獲得しつつあります。ループにとって、この影響は構造的なものです。エージェントやオーケストレーション層がアクセス失敗を飲み込んでしまう場合、識別情報を持たないループは、ゲートで保護されたWeb上で明確なエラーを返さない可能性があります。署名がない、あるいは拒否されたリクエストは、目に見える致命的なエラーではなく、不完全なソース取得につながる恐れがあります。これは、業界がすでに弱点として認識している「検証」という部分に直接的なダメージを与えます。対照的に、識別されたループは、Web側がサービスを提供するかどうかを選択できるループです。そこには署名だけでなく、どの署名クライアントがどのオペレーターに関連付けられているかという、暗号学的な証拠に基づいた責任の所在（系譜）が含まれています。エンドユーザーの権限管理は、Web Bot Authの目的の範囲外であり、引き続き個別の企業IDおよび委任制御の領域となります。

3. ウォレット：HTTP 402とループの新たな意思決定

決済の側面は、ループの制御フローをより根本的に変えます。なぜなら、それはループの最も基本的な反射行動である「リトライ（再試行）」の内部に組み込まれるからです。x402対応のやり取りでは、402レスポンスは単なる失敗ではなく、構造化された支払いリクエストとして機能します。MPP（Monetization Protocol for Payments）は関連するものの異なるフローを定義しており、サービスが支払いリクエストを返し、エージェントがリソースを受け取る前に支払いを承認するという仕組みですが、Stripeの公開ドキュメントでは、このフローをHTTP 402ベースとは定義していません。x402では、サーバーが価格と支払い詳細を提示し、クライアントが支払うかどうかを判断します。承認された場合、クライアントは支払い証明を添えてリクエストを再送します。これを自己完結型のループに組み込むと、いくつかの結果が生じます。 価格がステップレベルのシグナルとなる。 ループが提示されたコストに直面した際、そのフェッチ、API呼び出し、あるいはMCPツール呼び出しが、タスクの残りの予算に見合う価値があるかどうかを、実行中に判断する必要が出てくるかもしれません。これは以前であれば、請求の段階で（あるいは全く考慮されずに）行われていた判断です。 失敗のモードが逆転する。 価格設定されたエンドポイントに対するアマラの11回にわたる丁寧なリトライは、良性な例です。しかし、自動支払いポリシーが、適切なべき等性、重複排除、予算チェックなしに、繰り返しまたは個別のリクエストを承認してしまうと、高コストな問題が発生します。未払いの402に対して単にリトライを繰り返すクライアントは、何も購入せずに呼び出しを浪費するだけですが、新しい見積もりのたびに再承認を行うポリシーは支出を増大させます。これは、私たちが以前の フリートに関する投稿 で検証したファンアウト経済が、すべての分岐にメーターが取り付けられた状態で再現されることを意味します。 キャッシュが購入戦略となる。 組織がすでに購入したものを再購入することは、すでに計算したものを再計算することと同義です。有料のレスポンスは、鮮度、ライセンス、プライバシー、および認可の制約が許す限り、記憶しておく価値のある資産となります。 そして、領収書が運用の説明責任の一部となる。 支払い記録が暗号学的および運用上の観点からリクエストや呼び出し元のIDと結びついている場合、要求されたリソース、承認された金額、決済が試行されたか完了したかを示す監査証跡をサポートできます。ただし、これ自体が配信の成功、ソースの品質、出力の正確性を証明するものではありません。その記録は、財務上の目的だけでなく、運用上の説明責任を果たすために必要なコストやアクセスの記録としても、それが伴うツール呼び出しと同じステップごとのトレースに含まれるべきです。これには、特定の決済レールが勝者になると信じる必要はありません。必要なのは、ループの送信エッジがトランザクションのセマンティクスを獲得し得ること、そしてガバナンスのないトランザクションのセマンティクスこそが、パイロット版が請求書へと変わる仕組みであることを認識することです。

4. イーグレス（Egress）：Loop Engineeringの第3の規律

ループに関する最初の投稿では、ループはサンドボックス、認証情報、ゲート、記録といったランタイムに属するものであると論じ、フリートに関する投稿では、ランタイムは制御を増やすことなく多くのループへとスケールしなければならないと論じました。これらはどちらも内部に向けたものです。メーター制ウェブが加えるのは外部に向けたものであり、それは一つの規律として呼ぶに十分な一貫性を持っています。私たちのフレームワークがそうであるように、これは確定した教義ではなく、編集上の統合として提示するものです。 イーグレスエンジニアリング とは、ループがエンタープライズの境界外で行うすべてのことをガバナンスに基づいて管理することであり、その構成要素は内部のセットと見事な対称性を成しています。 ID（Identity）： ループは自身が何者であるかを示します。レールがサポートしている場合は署名付きリクエストを用いますが、より根本的には、エージェントごとに仲介され、その背後にユーザーごとの委任を伴うIDを使用するため、「誰がこれを行ったか」という問いに対して、単なるキーよりも深い回答が得られます。 ポリシー（Policy）： ループが何を購入できるか、誰から購入できるか、そして上限はいくらか。これはツール許可リストの外部版といえるものです。 強制（Enforcement）： 月末の締め後に調整するのではなく、リクエストパス内で支出を制限します。発見のための警告のみのモード、本番環境のためのハードモード、上限に達する前に発動するしきい値などが含まれます。 記録（Record）： 領収書とアクセス決定をループのステップごとのトレースに結合することで、実行コスト、ソース、権限を一つの場所から説明できるようにします。この対称性こそが議論の核心です。企業はループ内でのガバナンスのない認証情報を受け入れませんでした。同様に、特に参加エッジがリクエストごとに課金できるようになった今、その境界でガバナンスのないIDや支出を受け入れる理由はありません。

5. TrueFoundryと本稿の関連性

まず精緻な注釈を付け加えます。本シリーズは製品セクションの範囲を定めることでその価値を築いているためです。TrueFoundryの機能セットには、最新のドキュメントからわかるように、x402決済やWeb Bot Authのリクエスト署名は含まれていません。ここでの論点はより狭く、構造的なものです。どのレールが勝者になるにせよ、有料またはIDゲートによるマシンアクセスが拡大するにつれて重要性を増すガバナンスパターン（エージェントごとに仲介されるID、パス内で制限される支出、ステップごとに監査可能なアクティビティ）こそが、TrueFoundryが現在提供しているゲートウェイプレーンの文書化された姿です。 IDと委任： エージェントは埋め込みキーではなく仲介された認証情報で動作し、エンタープライズIDプロバイダーに対するRBAC（役割ベースのアクセス制御）とユーザーごとの委任を行い、機密性の高いアクションには承認ゲートを利用できます（Agent Harnessのドキュメント; MCPゲートウェイの認証とセキュリティ）。 支出の強制管理： テナントやチーム単位での予算設定に加え、ユーザー、モデル、仮想アカウント、メタデータによる細分化が可能です。さらに、ユーザー、モデル、アプリケーションごとのレート制限も設定できます。組織がそのマッピングを採用している場合、エージェントや環境を仮想アカウントやメタデータで表現することも可能です。また、警告のみを行うモードや、予算超過を厳格に制限するモード、予算のマイルストーン通知機能も備えています（予算に関するドキュメント）— これは、リクエストごとの課金リソースが広く採用されるようになれば、さらに重要性を増すインパス（通信経路上）のガバナンスパターンです。 記録： リクエストごとのコスト、トークン、レイテンシの属性管理。OpenTelemetryエクスポートによるエージェント実行のステップごとのトレース。エージェントおよびツールの活動に関する監査可能な記録（ゲートウェイに関するドキュメント）。また、第1セクションの展開は、既存の領域に直接関わってきます。Cloudflareが発表したMonetization Gatewayは、顧客がMCPツール呼び出しに対して課金できるようにする計画です。有料のツールアクセスが拡大すれば、MCPゲートウェイは、どのツールをどのIDや予算で呼び出し、どのような監査記録を残すかを決定するための妥当なガバナンスポイントとなる可能性があります。TrueFoundryの既存の MCPゲートウェイ は、そのようなガバナンスを構築するためのレジストリ、認証、アクセス制御、および可観測性レイヤーを提供します。ループの内側が前回の投稿の第5セクションであり、フリートの制御が第2セクションであったように、上記の出口（エグレス）コンポーネントは同じ平面上に集約されます。つまり、「どこで実行するか」という問いに対して厳格な回答を求める組織向けに、VPC内、オンプレミス、またはエアギャップ環境でのデプロイが可能です（デプロイメントの構成）。

6. 制限

5つ。議論がその証拠の範囲内に留まるようにするためです。 成熟度はコンポーネントによって異なります。 Monetization Gatewayは現在ウェイティングリスト形式であり、Pay Per Crawlはベータ版の系譜にあります。Chainalysisの報告によると、2026年第1四半期までにBase上でのx402トランザクションは1億件を超えましたが、その初期の急増の多くは投機的な活動によるものであり、本格的な普及にはまだ時間がかかると指摘されています（chainalysis.com）。 標準化の競争はまだ決着していません。 競合するプロトコルはすでに存在します。StripeとTempo（StripeとParadigmがインキュベートする決済ネットワーク）が共同開発したMachine Payments Protocolなどがその例です。本稿の主張は意図的に特定の基盤に依存しないものですが、読者は特定の勝者を想定すべきではありません。 アイデンティティの導入はまだ初期段階です。 Web Bot Authのワーキンググループ、レジストリのドラフト、初期のプロダクション署名者は存在しますが、広範な普及には至っていません。 そして、このフレームワークは私たちが構築したものです。 「Egressエンジニアリング」、パスポートとウォレットという枠組み、そして対称性の議論は、TrueFoundryによる編集上の統合であり、読者が判断できるよう情報源を明示しています。TrueFoundryの機能に関する記述は執筆時点の公開ドキュメントを反映しており、Amaraは例示のための架空の人物です。

決済プロトコルのセキュリティは発展途上にあります。最近の研究では、x402の実装において、リプレイ攻撃、認可バインディング、並行処理、支払い済みにもかかわらず拒否されるといった障害モードの可能性が指摘されています（arXiv preprint）；これらの知見は、エコシステム全体で確定した結論というよりは、新たな研究成果として扱うべきものです。

結び

Loopエンジニアリングは、ループを仕事の単位として真剣に捉えることでその名を得ました。最初の投稿ではループの内部を制御し、2番目の投稿ではそれをフリート全体にスケールさせました。ウェブの一部では、自動化されたアクセスに対して、より明確なアイデンティティや支払い条件を付与する動きが始まっています。エージェントループを運用する企業にとって、これは実用的な設計上の問いを投げかけます。各ループは、外部からの新たな2つの問いに対して、その場しのぎではない回答ができるでしょうか。 「私は何者か」および「私はどの予算内で行動しているか」？ どちらの回答もガバナンスの成果物であり、プロンプトではなくレイヤーに属するものです。そして、どちらも最初の請求書が届く前に導入しておく方が容易です。

参考文献

• 決済 — Linux Foundation、x402 Foundation設立、2026年4月2日（運営団体：Coinbase/Cloudflare/Stripe。Google、Visa、Microsoftなど20社以上が初期支持を表明。Zemlin氏の引用）： linuxfoundation.org；Cloudflare Monetization Gatewayウェイティングリスト、2026年7月1日（「エージェントは必要な入力に対して対価を支払うべき」という方針、MCPツール価格設定の計画）： blog.cloudflare.com; Pay Per Crawl プライベートベータ版、2025年7月： blog.cloudflare.com; 402ボリューム、プライマリ（ボットおよびクローラーに対する1日あたり10億件以上のレスポンス）： blog.cloudflare.com/x402; 9月15日のクローラーカテゴリのデフォルト設定、プライマリ： blog.cloudflare.com; x402トランザクションボリューム（2026年第1四半期までにBase上で1億件以上、導入に関する注意点）： chainalysis.com; マシン決済プロトコル（StripeおよびTempo共同執筆）： stripe.com。
• ID — Webボット認証 現在のプロトコル草案; HTTPメッセージ署名ディレクトリ草案; ワーキンググループ 結成通知 および 憲章; Signature Agent Cardレジストリドラフト; Cloudflare 責任あるAIボットの原則と実装のエビデンス および signed-agents お知らせ; AWS AgentCoreブラウザプレビューのドキュメント; Vercel Web Bot Auth認証に関するお知らせ; Cloudflareリファレンス実装
• TrueFoundryドキュメント — Agent Harness、 MCP Gatewayの認証とセキュリティ、 予算制限（警告のみ、強制執行、マイルストーンアラート）、 AI Gateway、 MCPゲートウェイ、 デプロイメントの姿勢。
• シリーズのコンパニオン — エンタープライズグレードのループエンジニアリング （ループのランタイム）、 フリートのためのループエンジニアリング （大規模なループ）、 エージェントの収束 （2026年中盤の期間）、 AI FinOps、 セマンティックキャッシング、 エージェントコマースのガバナンス。

Amaraとそのリサーチループは、特定の個人、組織、または出来事ではなく、例示的な合成モデルです。すべての統計および引用は、記載された日付にリンク先の情報源によって報告された通りであり、15語未満の引用部分は出典を明記しています。二次的な報道として記載された数値は、本文中でその旨を明示しています。「Egressエンジニアリング」および「パスポートとウォレット」という枠組みは、TrueFoundryによる編集上の統合です。TrueFoundryの機能は、執筆時点の公開ドキュメントを要約したものです。最新のドキュメントで確認してください。TrueFoundryのドキュメントにはx402やWeb Bot Authのサポートに関する記述はなく、それらを主張するものでもありません。TrueFoundryは、Cloudflare、Linux Foundation、IETF、Amazon、または引用された出版物とは提携していません。

‍