説2025――ECLA（Electronic Commerce Law Architecture）モデル

電子商取引・プラットフォーム取引の商法的再設計：スマートコントラクト／ブロックチェーン／デジタル商品と電子契約法の接続、仲介者責任の再編

要旨：商法の中核概念（商人・商行為・商業登記・売買・運送・倉荷証券）を**「記録移転（record‑based transfer）」と「監査可能性（auditability）」に据えて電子化する。プラットフォームの責任は統制（Control）×便益（Benefit）×役割（Role）に比例し、三層責任（Conduit／Market‑maker／Merchant‑of‑Record）で明確化する。スマートコントラクトは法律殻（legal shell）×コード核（code core）×オラクル鉗子（oracle clamp）×救済フック（remedy hook）の四層契約として法的位階化し、コード不可逆性と商事救済**を両立させる。

序　—　何が「商法」を電子化で再設計させるのか

電子商取引は、二面市場・アテンション経済・アルゴリズム仲介・分散台帳・AI補助に支配されつつある。商法の古典（指名債権の譲渡、倉荷証券、船荷証券、商人の指名）は、紙の外形と人の会計に依拠してきた。しかし現代では、ハッシュと鍵とログが、人と紙に代わる「外形」と「証拠」になっている。山崎説は、商法を「コードとログが回る世界」に再配置する提案である。

第1章　射程と課題地図

1. スマートコントラクト／ブロックチェーン取引　— 当事者意思の表現主体は誰か。コードのバグ・オラクル改竄・再編（reorg）時の危険負担は。

2. デジタル商品・権利の売買　— 有体物でない対象の「引渡し」「適合」「瑕疵」「所有権／準占有」の扱い。

3. 電子契約法との接続　— 同意の有効性、誤入力保護、ダークパターン、AI要約の誤導。

4. プラットフォーム事業者の義務・責任　— 仲介者責任、表示義務、適合保証、隠れ自己優遇（self‑preferencing）、レビュー操作、API障害。

5. 証拠法・国際私法・決済法　— 鍵支配主義と管轄、ログの証拠力、資金移動規制との境界。

結論の方向感：「所有」よりも「記録移転」、「説明可能性」よりも「監査可能性」、**「形式当事者」よりも「統制・利得」**で責任を配る。

第2章　ECLAの基本設計：五つの再定義

2.1 商人（Merchant）の再定義

• 商人＝記録移転の中核を握る者。①商品・権利の記録移転を直接制御（鍵・承認権・凍結権）、②代金フローを実質管理、③リスク・情報の非対称性を利用、の三つのうち二つ以上を満たす者は、Merchant‑of‑Record（MoR）として商人責任の基礎を負う（後述三層責任）。

2.2 商行為（Commercial Act）の再定義

• 「外形がログに現れる経済行動」。スマコンのデプロイ、プールへの流動性提供、オンチェーンの譲渡指図、プラットフォームAPIによる取引仲介などログで認識できる行為を商行為とみなし、**商事推定（善意・迅速）**の特則を適用。

2.3 引渡し（Delivery）の再定義

• 有体物：従来どおりの占有移転。

• デジタル：e‑Delivery＝(i)鍵に基づくコントロール移転（署名権限の移行、マルチシグ閾値変更）、(ii)台帳記録の状態変化が監査可能な形で完了すること。監査可能性を満たさない移転は引渡し未了として扱う。

2.4 瑕疵担保（適合性）の再定義

• デジタル適合＝機能（機能要件）×相互運用（API/SLA）×真正（署名・出所）。物的瑕疵を三面のデジタル適合に翻訳し、法定適合保証を最低ラインとして課す（EUデジタルコンテンツ指令に近い概念だが、商法上の特則として整序）。

2.5 価格・リスクの再定義

• コード・オラクル・ブリッジの障害を商事危険として契約で配賦。ただし不可逆性（巻戻せない）を理由に救済を閉ざすことは不可。救済フックの設計を法的要件にする（後述）。

第3章　スマートコントラクトの四層契約（LCA：Layered Contract Architecture）

3.1 四層の構造

1. 法律殻（Legal Shell）：人間言語の合意／準拠法／争議解決／不可抗力・危険配分／消費者特則。

2. コード核（Code Core）：実際の履行ロジック（移転・決済・条件）。

3. オラクル鉗子（Oracle Clamp）：外部情報の取込み・検証・フェイルセーフ。

4. 救済フック（Remedy Hook）：緊急停止／エスクロー／自動返金／手動ロールバックの手段とSLA。

ドラスティック提案：救済フックは商法上の「適合性要件」に格上げ。救済手段ゼロの不可逆コントラクトは、商人間取引においても原則として「適合欠缺」（特約で明示免責しない限り）と推定する。

3.2 エンジニア視点の要件化

• 不変（immutability）＝善、は半分。観測（observability）と退避（reversibility）を備えないコードは商事不適合。

• 最小救済：①エスクロー、②タイムロック、③アップグレードガバナンスの証跡、④オラクル冗長化（3/5等）、⑤緊急停止（Pause）。

• 監査証跡：コミットハッシュ、監査レポートID、デプロイ署名、運用ログ。

3.3 危険負担（reorg・フォーク・oracle fail）

• 危険配分の法定推定：

  • reorg／フォーク：最終性閾値前は共同危険（当事者折半推定）、閾値後は履行側負担（MoR負担）。

  • oracle fail：オラクル選定・冗長化の裁量が大きい側に一次負担。

  • ブリッジ障害：ブリッジ発行体／運営体をMoRに準じる地位として第一次負担。

第4章　デジタル商品・デジタル権利の商法的編成

4.1 客体区分

• ネイティブ資産（チェーン上に本体がある）：暗号資産、NFT（固有トークン）。

• 代表／記録化資産（オフチェーン権利の記録）：トークン化証券、RWA、ストアクレジット。

• サービス型コンテンツ：SaaSライセンス、ゲーム内アイテム（中央集権型）。

4.2 移転と引渡し

• ネイティブ：鍵コントロール移転＋記録更新＝e‑Delivery完了。

• 代表：記録更新は引渡し的一部に過ぎず、原権利への対抗要件（帳簿書替・名義書換）が別途必要。MoRは二重売買防止の適合保証を負う。

• サービス型：利用権の付与にすぎず、停止可能性・SLAが適合性の主軸。

4.3 適合保証（デジタル）

• 真正（Authenticity）：署名・発行体真正・改竄不可。

• 機能（Functionality）：仕様どおり動作、互換性。

• 相互運用（Interoperability）：API、バージョン、後方互換。違反時救済：修補／置換／値引／解除に加え、オンチェーン返金・回収関数等の技術的救済を第一選択に（迅速性）。

第5章　プラットフォーム責任の三層モデル（Conduit／Market‑maker／MoR）

5.1 役割と統制

• Conduit（伝送）：純仲介。掲載・マッチングのみ。決済・履行・オラクル・鍵の統制は持たない。

• Market‑maker（市場形成）：KYC・決済・紛争解決・レビュー管理・レコメンド・在庫一時保管など市場品質を実質統制。

• MoR（記録上の販売者）：代金受領者・領収書発行者・回収／返金の当事者。多くのデジタル取引で実質はプラットフォームがMoR。

5.2 統制・利得・役割に比例する責任（CBR式）

Liability Sharei=Ci⋅Bi⋅Ri∑jCj⋅Bj⋅Rj\text{Liability Share}_i=\frac{C_i\cdot B_i\cdot R_i}{\sum_j C_j\cdot B_j\cdot R_j}Liability Sharei​=∑j​Cj​⋅Bj​⋅Rj​Ci​⋅Bi​⋅Ri​​

• CCC：Control（返品裁量、凍結権、オラクル・ブリッジ選定、在庫／配送）

• BBB：Benefit（手数料率、広告、自己優遇利益）

• RRR：Role（Conduit=1, Market‑maker=1.5, MoR=2 など）

原則：MoR＞Market‑maker＞Conduit。統制高／利得高ほど重く。レビュー操作・自己優遇は**B↑C↑**で倍率上げ。

5.3 責任の中身

• 仲介者責任：通知・削除・差止の義務（違法出品／偽情報）、到達性の証拠（AIログ）。

• 保証責任（MoR）：デジタル適合保証の一次的負担。

• 瑕疵責任：隠れ欠陥（セキュリティ脆弱性・サプライチェーン改竄）について実質統制者に負担。

• 安全配慮義務：アルゴリズム推奨の危険低減（偽医療品・詐欺アプリの露出抑制）。

• 透明性義務：レコメンドの主要因子、広告と自然検索の区別、自己優遇指標の開示。

第6章　AIエンジニア視点の監査可能性義務（必須化）

6.1 取引層のログ

• オファー提示、同意画面、価格変動、クーポン適用、SLA表示、バージョン。

• Consent‑Receipt（同意レシート）：スクリーンハッシュ＋時刻印＋署名。

6.2 履行層のログ

• e‑Deliveryのハッシュ、オラクル入力、ブリッジTx、エスカレーション。

• Remedy‑Receipt：返金・交換のオンチェーン証跡。

6.3 アルゴ層のログ

• レコメンド要因、ランキング変動、自己優遇フラグ、除外理由。

• 監査API：裁判所・ADR向けにサンプリング公開。

法効果：ログ不備は適合違反の推定・CBR倍率アップ。技術要件：改ざん検知、アクセス制御、保存（最低3年）。

第7章　電子契約法との接続：監査可能同意とダークパターン禁止

7.1 「意思」ではなく「位相」をみる（F0〜F6）

• F0知覚／F1注意／F2理解／F3決心／F4表明／F5伝達／F6登録。

• F0〜F2故障＝同意の欠缺（無効寄り）、F3〜F4故障＝瑕疵（取消寄り）。

• CR（理解率）／ACI（注意捕獲）／DPI（ダーク指数）／APS（圧力）が閾値超なら設計側に逆転負担。

7.2 スマコン特有の同意問題

• コード同意：Legal Shellで明示し、バージョン固定、重大変更時は明示同意（Opt‑in）。

• AI要約：誤誘導はF2故障で適合違反。要約ログを証拠化。

第8章　救済と責任：技術的救済優先の商事原則

8.1 救済メニュー（Least‑Restrictive Remedies）

• L1：ディランキング／警告／露出停止（プラットフォーム）。

• L2：返金／再供給／鍵再発行／代替アクセス。

• L3：オンチェーン回収関数の作動／ブリッジ凍結。

• L4：アカウント停止／契約解除／損害賠償。原則：技術的救済（L2/L3）を先に、法的救済（L4）で締める。

8.2 損害算定の補正式

Loss=(直接損害+復旧費)×(1+λ⋅再拡散率)\text{Loss}=(\text{直接損害}+\text{復旧費})\times(1+\lambda\cdot \text{再拡散率})Loss=(直接損害+復旧費)×(1+λ⋅再拡散率)

再拡散率はログから算出（再配布・再表示）。ログ欠落はλ\lambdaλ上振れ。

第9章　国際私法・管轄

• 支配主義（Key‑Control）：ネイティブ資産の「所在地」は鍵の支配地＋合意管轄で擬制。

• 記録支配地：プラットフォームのMoR拠点が商事管轄の基軸。

• 消費者保護：消費者地法の強行規定を優先（適合保証・撤回権）。

第10章　DAO・プロトコル・「誰が商人か」

• DAO：トークン保有者の議決・報酬・運営裁量が高ければ、Market‑makerまたはMoRの商人性を認定しうる（CBRのC/B/R評価で按分）。

• プロトコル財団：ガバナンス鍵・トレジャリー・アップグレード権を持つなら、救済フックの提供義務を負う。

第11章　支払・決済・資金移動の境界

• プラットフォーム内ウォレット：前払式／資金移動のライセンス境界。

• スマコン清算：エスクロー・デリバリーバリデーションは支払サービスに準ずるが、MoRが一次責任。

• チャージバック：オンチェーンは不可逆→救済フック（二段階清算・可逆期間）を商事標準に。

第12章　モデル条文（抄）

第1条（定義）電子商取引とは、電子的方法により締結・履行される商行為をいう。デジタル商品の引渡しとは、鍵コントロールの移転及び台帳記録の更新が監査可能な形で完了することをいう。

第2条（スマートコントラクトの構成）スマートコントラクトは、法律殻・コード核・オラクル鉗子・救済フックの四層から成るものと推定する。救済フックを欠く契約は、特段の合意がない限り適合性を欠くものと推定する。

第3条（プラットフォームの三層責任）プラットフォーム事業者の責任は、その統制・利得・役割に比例して定まる。記録上の販売者（MoR）はデジタル適合保証の一次責任を負う。

第4条（監査可能性義務）事業者は、申込みの提示・同意・引渡し・救済の各過程について、改ざん検知可能な記録を保存し、当事者・裁判所・ADR機関の請求に応じて提供しなければならない。

第5条（相互運用保証）デジタル商品の適合性は、機能・真正・相互運用の三面から評価する。

第6条（危険配分の推定）台帳再編前の履行は共同危険、再編確定後は履行者の危険と推定する。オラクル故障は選定・冗長化の裁量を有する者の危険とする。

第7条（技術的救済の優先）裁判所は、可能な限り技術的救済を優先して命じ、これにより目的を達し得るときは法的救済を最小限にとどめる。

第13章　実装ガイド（プラットフォーム向け）

• 契約：四層構造の明記、救済フック（Pause/Refund/Recall/Arbitration）のSLA、MoRの範囲。

• 技術：Consent‑Receipt、Delivery‑Receipt、Remedy‑Receiptの三領収API。

• 監査：年1回の独立監査、自己優遇・ランキングの透明性報告。

• ADR：オンチェーン証拠提出に対応した手続、24/72時間の暫定救済。

• 国際：消費者向けは地法適用・撤回権に整合、B2BはLEX ELECTRONICA条項（監査可能性・救済フック義務）を標準化。

結語　—　「外形」は紙からログへ、「商人」は看板から統制へ

電子商取引の商法は、紙の署名や物理的引渡しを基準に組み立て直すのではなく、ログ・鍵・ハッシュを基礎単位に設計し直すべきである。スマートコントラクトは四層契約として位置づけ、救済フックを適合性要件に格上げする。プラットフォームは、Conduit／Market‑maker／MoRの三層で責任を負い、統制・利得・役割に比例して分担する。デジタル適合保証は、機能×真正×相互運用の三面で測る。このECLAモデルは、AIエンジニアの「運用可能性」と商法学の「規範性」を接続し、速く・公正に・可監査であることを商事規範の第一原理に据える。不可逆のコードと可逆の救済――矛盾を調停するのが商法の役目である。

付録A　チェックリスト（商事条項の雛形・抜粋）

• 定義：e‑Delivery、デジタル適合、救済フック、MoR

• 危険配分：reorg閾値、オラクル冗長化、ブリッジ障害

• 適合保証：機能・真正・相互運用、SLA数値

• 監査：Consent/Delivery/Remedy‑Receiptの提供と保存年限

• プラ責：三層責任、自己優遇の禁止・開示

• ADR：オンチェーン証拠、緊急救済（24/72h）

付録B　エンジニア向け要件（最小）

• リリースごとのコミットハッシュと監査IDの契約添付

• タイムロック＋マルチシグ＋緊急停止

• オラクル3/5冗長、フェイルクローズ

• 再現可能ビルド、監査ログ、鍵管理（MPC）

一文で：「商法の“可視の外形”をログに置き換え、責任の“主体”を肩書ではなく統制・利得で測る。コードの不可逆性は救済フックの義務化で中和する。」