この記事のポイント
- Google・IBM・Circleらの連合が、AI取引に準拠法・契約条件・紛争解決を埋め込むオープン標準「Legal Context Protocol（LCP）」を発表した
- LCPは決済やコマースのプロトコルが扱ってこなかった「取引が壊れたとき」の法的レイヤーを担い、各ドメインの単一URLから法的文脈を取得できる
- 仕様策定は世界最大の紛争解決機関AAA-ICDRとIntegra Ledgerが共同で進め、将来的にはLinux Foundationへの寄贈を目指している
Legal Context Protocol（LCP）とは何か
A coalition including Google, IBM, and Circle introduced the Legal Context Protocol (LCP), an open standard providing a legal framework for AI-driven commerce.
pluang.com2026年6月24日、Google・IBM・Circleを含む連合が、AIエージェントの取引に法的な枠組みを与えるオープン標準「Legal Context Protocol（LCP）」を発表しました。LCPは、AIエージェントが交渉・調達・決済を自律的に担う場面で、検証可能な契約条件・準拠法・紛争解決の仕組みを取引そのものに埋め込むための共通仕様です。
ここで言うエージェンティックコマースとは、人間が逐一クリックするのではなく、AIエージェントが利用者の代わりに商品を探し、条件を交渉し、支払いまでを実行する取引のかたちを指します。この世界では決済や商品発見を扱う仕組みが急速に整備されてきました。一方で、取引が成立した「後」に何が起きるのか――つまり合意の証明や紛争の解決――を担う層がぽっかりと空いていたのです。
連合には主導役のGoogle・IBM・Circleに加え、Wayfair、Stellar Development Foundation、Ava Labs、UiPath、Cardano、Hedera、Aptos Foundationなど、決済・基盤レイヤーの多様な企業が名を連ねています。発表によれば、AIエージェントが扱う取引の多くには「検証可能な契約条件、明確に定義された準拠法、確立された紛争解決の仕組み」が欠けているといいます。
なぜ「法的レイヤー」が必要なのか
AIエージェントが自律的に契約を結ぶようになると、従来の商取引が前提としてきた法理が崩れます。仕様の核心を語る上で、米国仲裁協会（AAA）の関係者が紹介した実例が示唆的です。
ある製造業者では、設定ミスによってエージェントが週末のあいだに1万2,000件もの取引を完了させ、いずれも不利な補償条項を含んでいたものの、誰も気づかないまま処理が進んでしまったと報告されています。人間がボタンを押すことを前提に整備されてきた電子商取引のルールは、機械が独立して交渉する場面ではそのまま通用しません。
問題は大きく三つに整理できます。ひとつは「権限と追認」で、調達エージェントが人間のレビューなしに相手方の条件を受け入れたとき、その合意は有効なのかという論点です。次が「契約の成立」で、双方が機械の場合に、いつ・どの条件で契約が成立したのかが曖昧になります。最後が「履行と執行可能性」で、信頼できる記録がなければ、何が実際に合意されたのかをめぐる争いが長期化しかねません。
AAA-ICDRの解説では、こうした法的インフラの不在が放置されれば「どの条件が取引を律していたのかを決めるだけで何十年もの訴訟」を招きかねないと警告しています。誰がAIエージェント間の契約を統べるのかという問いは、技術の問題であると同時に、法制度そのものの問題でもあるのです。
LCPはどう動くのか
LCPの設計思想はきわめてシンプルです。各ドメインの決まった場所――https://{任意のドメイン}/.well-known/legal-context.json――に法的文脈を置き、エージェントは取引の前にこのURLを一度取得するだけで済みます。これは、本人確認情報を発見可能にした.well-known/openid-configurationや、クローリング規則を共通化したrobots.txtと同じ発想です。「すべてのエージェントに、すべての取引で、毎回」法的文脈を届けることを目指しています。
この発見用ファイルは、利用規約のURL、改ざんを検知するためのSHA-256ハッシュ、同意が必須かどうかを示すフラグなどを指し示します。規約本体はMarkdown、JSON、プレーンテキスト、PDFのいずれの形式でも記述できますが、エージェントが解析しやすい機械可読なテキストが推奨されています。
LCPが特徴的なのは、用途に応じて四段階の信頼レベルを用意している点です。最も軽い「Informational」では、エージェントが規約を見つけ、取引を進めること自体が同意とみなされます。「Provable」ではハッシュによって規約の真正性が検証され、「Signed」では電子署名で当事者が特定の条件に拘束されます。最も重い「Integrated」になると、紛争解決・エスクロー・コンプライアンスの仕組みまで連携します。
決済・コマース標準との関係
LCPは既存のプロトコルを置き換えるものではなく、その「上」に重なる補完的な層として設計されています。技術非依存で相互運用可能であることが強調されており、特定のチェーンや決済方式に縛られません。具体的には、決済プロトコルのx402やMPP（Machine Payments Protocol）、コマースフレームワークのUCP・ACP・AP2、ID・認可のVisa TAPやMastercard Agent Payと組み合わせて使えます。
決済が「お金を動かす」層、コマースが「取引フローを回す」層だとすれば、LCPは「合意を法的に裏づける」層にあたります。下の比較表のように、エージェンティックコマースのスタックは複数のレイヤーが分業する構造になりつつあり、LCPはそこに欠けていた最後のピースを埋めようとしています。
| レイヤー | 代表的なプロトコル | 担う役割 |
|---|---|---|
| 決済 | x402 / MPP（Machine Payments Protocol） | エージェント間の資金移動・支払い実行 |
| コマース | UCP / ACP / AP2 | 商品発見から購入・購入後管理までの取引フロー |
| ID・認可 | Visa TAP / Mastercard Agent Pay | エージェントの本人確認と支払い権限の付与 |
| 連携 | A2A / Verifiable Intent | エージェント同士の協調と意図の検証 |
| 法的（LCP） | Legal Context Protocol | 準拠法・契約条件・同意・紛争解決の埋め込み |
仕様策定の体制も注目に値します。LCPは、世界最大の紛争解決機関である米国仲裁協会・国際紛争解決センター（AAA-ICDR）と、リーガルテック企業のIntegra Ledgerが共同ステュワードを務めます。1世紀にわたる仲裁の実務知見を持つ中立的な非営利団体が関与することで、現実の裁定や執行に耐える標準を目指す構えです。バージョンは「1.0 Draft」としてコミュニティレビューに公開され、ライセンスはApache 2.0。将来的にはMCPやUCPと同様、Linux Foundationへの寄贈が想定されています。
まとめ
LCPの登場は、エージェンティックコマースが「どう支払うか」から「どう責任を負うか」へと議論の重心を移しつつあることを示しています。決済（MCP/UCP/Agent Pay）が整っても、取引が壊れたときに誰がどの条件で責任を負うのかが曖昧なままでは、企業は自律エージェントに大きな取引を任せられません。LCPは、その不確実性を取引の前にURL一本で解消しようとする試みです。
現時点ではドラフト段階であり、実際にどれだけの事業者が.well-known/legal-context.jsonを整備するかは未知数です。とはいえ、AAA-ICDRという執行を担いうる機関が初期から関与し、主要プラットフォームが連合に名を連ねている点は重い意味を持ちます。EC事業者やプラットフォーム運営者は、自社のエージェント取引が「機械が機械と結ぶ契約」を想定した規約になっているかを、いまから点検しておく価値があるでしょう。
