法人デジタルIDと委任の確認｜署名が本物でも権限がない相手を見抜く方法

ある会社の受注システムに、取引先から電子署名付きの発注書が届きました。署名を確かめると、正しい鍵で署名されています。ところが署名したのは、先月その取引先を退任した役員でした。署名は本物でも、この人にはもう発注する権限がありません。

法人の電子署名が正しくても、それだけで「契約してよい」とは言えません。その人が今もその法人を代表できるのか。この契約を結ぶ権限を任されているのか。これは署名とは別に確かめる必要があります。

確かめるのは、次の5つです。

• 法人：その法人は存在し、今どんな状態か
• 操作している人：今操作しているのは誰か
• 関係：その人は法人の代表者か、従業員か、委託先か
• 委任：誰が誰に、何を任せたか
• 取引：今回の操作は、任された範囲と条件の中か

5つを別々に確かめ、すべてに当てはまる範囲だけを認めます。以下では、法人間の契約や行政手続を例に、委任のデータ、確かめる順番、状態の扱い、障害時の処理、本番前の試験を順に設計していきます。

VC（検証可能な証明書）の基礎は「Verifiable Credentialsとは」、VCを業務に組み込む全体設計は「DID・VCの導入設計」で解説しています。

5つを分けて確かめると、何が防げるか

「本人確認OK」の一言で済ませてしまうと、2つの事故を見逃します。本物の社員が、任されていない契約を結んでしまう場合。そして、退任した代表者が出した古い委任が、まだ生きている場合です。

これを防ぐため、確かめる仕組み（検証サービス）は、5つの結果をそれぞれ別に返します。どれか1つだけでは分からないことがあるからです。

それぞれの根拠になる記録（正本・証拠）は、後半の「実装する人向けの詳細」にまとめています。

VCを使う場合はどうでしょう。W3C Verifiable Credentials Overviewは、確かめる作業を2段階に分けて説明しています。まず、証明書（Credential）や提示（Presentation）の署名が正しいかを暗号で確かめる（verification）。そのあと、検証者（Verifier）が自社の業務ルールで、発行者（Issuer）、所持者（Holder）、主体（Subject）、用途が妥当かを確かめる（validation）。VCを採用しても、「この契約を結んでよい」という判断のルールは自動では手に入りません。

委任を、機械で判定できる形にするには

デジタル庁の電子委任状法及び関係法令は、電子委任状を次のように定めています。法人の代表者等が、使用人等へ代理権を与えたことを表示する電磁的記録です。

この記録をPDFや署名データ、自由記述のまま保管していると、「500万円以下」「特定プロジェクトのみ」といった条件を、機械で安定して比べられません。そこで実装では、受け取る側が「今回の行為に使えるか」を判定できる項目に分けて持ちます。最低限、次の項目を持たせます。

• 誰が：委任元の法人、授権者、受任者
• 何を：行為、対象、上限、再委任してよいか
• いつまで・どう確かめるか：発効・終了の時刻、状態の参照先、適用する判定ルールの版

人が読む文書と、判定に使う構造化データを、同じ版に結び付けておきます。データの例は後半に載せています。

再委任で、権限が広がらないようにするには

代表者から部門長へ、部門長から担当者へ、と委任を重ねることがあります。このとき、それぞれの段で使えるのは、親の委任と子の委任の重なる部分だけです。後ろの委任で、前の委任より広い権限を作ることはできません。

• 親が購買契約だけを許していれば、子は銀行口座の変更を追加できません。
• 親の上限が500万円なら、子へ1,000万円を指定しても、有効なのは500万円以下です。
• 親の終了、取消、一時停止は、そこから派生した委任にも伝えます。
• 再委任できない委任から作られた子の委任は、署名が正しくても拒否します。

最後の受任者の証明書だけを見ていると、途中の委任が失効した後も権限が残ってしまいます。そこで各段について、発行者、署名、状態、期間、範囲を確かめます。委任を重ねられる段数にも上限を設けます。

発注内容を確定させてから、8つの順番で確かめる

確かめる側（検証者）は、次の8つの順番で判定します。

1. 取引の内容を確定させる：要求ID、検証者ID、行為、対象、金額、法域、時刻を、決まった形にそろえます。
2. 提示をこの取引に結び付ける：この取引専用の使い捨ての値（nonce）と、検証者の識別子を確かめます。別の取引からの使い回しは拒否します。
3. 操作している人を認証する：署名と鍵の持ち主を確かめ、必要な保証の水準を満たすか判定します。
4. 法人を確かめる：法人ID、登記・認定の状態、識別子と名称の対応を確かめます。
5. 授権者の根拠を確かめる：代表権、または上位の委任が、発効の時点で有効かを確かめます。
6. 委任の連なりを評価する：行為、対象、上限、期間、再委任、条件の重なりを計算します。
7. 今の状態を確かめる：取消・停止・期限切れと、状態情報の新しさを確かめます。
8. 判定と証拠を残す：許可・拒否・人の確認のどれにしたか、その理由、参照した版を、最小限の監査ログに残します。

OpenID for Verifiable Presentations 1.0 Finalは、提示を検証者の識別子（client_id）と新しいnonceに結び付けるよう求めています。返ってきた証明書と提示は、検証者自身が確かめます。この結び付けは、提示の使い回し（リプレイ）への対策です。委任の範囲や、社内の決裁規程の代わりにはなりません。

判定の結果は「有効」の一言にまとめず、どの確認で失敗したかを残します。ただし、監査ログに委任状の全文、住所、要らない証明書の属性を写してはいけません。残すのは、識別子、版、結果、時刻、理由のコードに絞ります。

取消が届くまでの時間差を、どう扱うか

委任には5つの状態があります。許可の候補になるのは「有効」だけです。

• 発効前（PENDING）：まだ使えない
• 有効（ACTIVE）：範囲内なら許可の候補
• 一時停止（SUSPENDED）：原則拒否か、人が確かめる
• 取消（REVOKED）：効力の時刻以降は拒否。元に戻さず、新しい委任で置き換える
• 期限切れ（EXPIRED）：使えない

注意したいのは、取消が「効いた時刻」と、それが「こちらに届いた時刻」がずれることです。その間に通してしまった取引を後で洗い出せるよう、2つの時刻を別々に記録しておきます。

状態の情報を手元にどれだけ置いておいてよいか（キャッシュの最大経過時間）は、取引のリスク別に決めます。たとえば高額の契約では、状態を取れなければ止める。リスクの低い照会では、少し前の署名付きの控えを短時間だけ使ってよい。このように、はっきり分けます。

状態ごとの記録や移り変わりの設計、届く遅れの扱いは「VCの信頼レジストリ設計」で詳しく扱っています。委任状を発行する側の認定も、そこで管理します。個々の証明書の失効を配る仕組みは「VCの失効設計」を参照してください。

デジタル庁の電子委任状取扱業務の認定でも、取扱事業者が委任状を保管・提示し、受け取る側が権限を確かめられる仕組みが示されています。ただし、制度上の効力や必要な確認方法は、手続によって違います。状態を問い合わせた結果だけで、個別の法的な判断を置き換えない設計にします。

ブロックチェーンは要るか

1社の運営者と契約関係があり、署名付きのレジストリを高い可用性で配れるなら、ブロックチェーンがなくても、通常のDBと透明性ログ（過去の変更の改ざんを検知できる記録）で十分です。

比べる価値があるのは、複数の企業が共同で委任の状態を更新し、特定の1社に履歴の変更を任せられない場合だけです。そのときに、許可型ブロックチェーンや、公開チェーンへのハッシュの記録（アンカー）を比べます。ただし、台帳の合意は、元の委任の意思、代表権、入力データの正しさを保証しません。情報ごとの置き場所は、後半の表にまとめています。

EUのRegulation (EU) 2024/1183は、個人・法人向けのウォレットに加えて、代表権（powers of representation）と電子委任（e-mandates）をはっきり定めています。相互運用の大事な制度例です。ただし、日本の電子委任状制度や個別の契約に、そのまま当てはまるという意味ではありません。

確認できないときは「OK」にしない

障害のときに「分からない」を「有効」として扱ってはいけません。場面ごとの扱いは次のとおりです。

• 状態を問い合わせる窓口が止まった：最後に受け取った署名付きの控えの版と期限を確かめます。決めた経過時間を超えたら、リスクの高い取引を拒否します。
• 取消の知らせが遅れた：取消が効いた時刻以降、知らせが届く前に許可した取引を探し、人の確認に回します。
• 時計がずれている：検証者、発行者、レジストリの時刻の差を見張ります。境界の近くでは、決めた許容幅を使うか、人が確かめます。
• 記録の重複・順番の逆転：記録の番号と版を使い、何度届いても結果が同じになるようにします。古い「有効」の記録が、取消の後に権限を復活させないようにします。
• 鍵が漏れた：操作している人の鍵、委任、法人の状態を分けて扱い、影響する範囲だけを止めます。
• 判定ルールの障害：黙って前の版に戻しません。署名・承認済みの版と、戻した理由を記録します。

e-Taxで利用可能な電子委任状では、代表者が作って署名する委任状と、受任者の名義の電子証明書による手続が分かれています。この例からも、委任の文書が本物かどうかと、実際に操作する受任者の認証は、別々に確かめる必要があると分かります。

PoCでは、権限が残ってしまう失敗を先に試す

1つの法人、1つの手続、1段の委任から始め、次の試験を自動で回します。

• 正しい社員の署名でも、権限外の行為・対象・金額を拒否する。
• 親の委任より広い子の委任、再委任できない委任から作られた子の委任、途中が期限切れの連なりを拒否する。
• 同じ提示を、別の検証者や別の要求へ再送しても拒否する。
• 取消の記録が遅れたり、重複したり、順番が逆になったりしても、権限が復活しない。
• レジストリが止まったとき、取引のリスクごとに停止や人の確認が働く。
• 判定のログから、使った法人の状態、委任の連なり、判定ルールの版、状態情報の新しさを再現できる。
• ログ、分析基盤、ブロックチェーンに、委任状の本文や要らない個人の属性が残らない。

この試験が通れば、署名の正しさと権限の有無を分けて判定できていることを、実データで示せます。

実装する人向けの詳細

ここからは、判定の仕組みを実際に作る担当者向けに、データの形と項目名をまとめます。

検証対象ごとの正本・証拠

• 法人：法人番号、商業登記、認定済みの法人ID
• 操作主体：本人確認済みのアカウント、認証器、鍵
• 関係：登記、人事・取引先の台帳、属性の証明
• 委任：電子委任状、権限付与の記録、承認履歴
• 取引：金額、対象、法域、時刻、判定方針の版

委任データの例

{
  "grant_id": "dg_01J...",
  "principal_org": "jp-corporate-number:1234567890123",
  "delegator": "person-or-role-id",
  "delegate": "person-or-system-id",
  "actions": ["submit_purchase_order"],
  "resource": {"project": "P-204", "amount_jpy_max": 5000000},
  "valid_from": "2026-08-01T00:00:00+09:00",
  "valid_until": "2026-09-30T23:59:59+09:00",
  "status_endpoint": "https://authority.example/status/dg_01J...",
  "policy_version": "procurement-v4"
}

これは実装例であり、法定の様式ではありません。

委任の連なりで有効になる範囲

各段で許可される範囲は、親の委任、子の委任、検証者の判定方針の交差部分です。

effective_scope = parent_scope ∩ child_scope ∩ verifier_policy

判定結果の例

{
  "subject_authentication": "valid",
  "organization_status": "active",
  "delegation_chain": "valid",
  "scope_match": true,
  "amount_within_limit": true,
  "status_freshness_seconds": 18,
  "policy_version": "procurement-v4",
  "decision": "allow",
  "reason_codes": []
}

valid=true一つにまとめず、どの確認が失敗したかを残します。

状態と時刻の項目

業務上の効力が変わった時刻（effective_at）と、検証者が状態を取得できた時刻（published_at）を分けて持ちます。そうすれば、取消が届くまでに許可した取引の再確認範囲を求められます。障害時の取消通知の遅延では、effective_at以降かつ配信前に許可した取引を検索します。記録の重複・順序の逆転には、event_idと版で冪等に処理し、古いACTIVEの記録が取消後に権限を復活させないようにします。

情報ごとの置き場所

XTELAができること

私たちは、法人IDと委任権限について、検証用のデータモデル、委任チェーンの交差計算、状態の扱い、検証者の判定方針、API、障害試験を設計し、PoCと実装仕様まで落とし込んでいます。貴社の手続を一つ選び、一段の委任から「署名は正しいが権限はない」ケースを確実に止める仕組みを一緒に作れます。技術構成の整理はお問い合わせからご相談ください。

主要参考資料

• デジタル庁 電子委任状法及び関係法令（2026年9月24日確認）
• デジタル庁 電子委任状取扱業務の認定（2026年9月24日確認）
• 国税庁 e-Taxで利用可能な電子委任状（2026年9月24日確認）
• W3C Verifiable Credentials Data Model v2.0（W3C Recommendation、2025年5月15日）
• W3C Verifiable Credentials Overview
• OpenID for Verifiable Presentations 1.0 Final（2025年7月9日）
• Regulation (EU) 2024/1183

資料の確認日と注意

制度・仕様は2026年9月24日に確認しました。一般的な技術・運用設計の解説であり、代表権・代理権の法的効力や個別取引の適法性の判断は、弁護士と連携して確認してください。