サプライヤーの登録と署名鍵の管理｜担当者の退職・鍵の失効と過去データの扱い

ある部品メーカーが、取引先からの出荷データや製品情報を受け取る基盤を作りました。取引先ごとに署名用の鍵を登録し、署名付きで届いたデータはいちいち確認せずに受け入れる仕組みです。

運用を始めてしばらくして、取引先A社から連絡が来ました。データを送っていた担当者が退職した、というのです。部品メーカーのDX責任者は困りました。その担当者の鍵で署名された過去の出荷データは、まだ信じてよいのか。A社の登録は、最初からやり直しになるのか。

答えは、登録の作り方で決まります。担当者の異動や鍵の紛失のたびに、法人登録と過去データの検証をやり直さないためには、最初に2つを決めておきます。

• 法人・担当者・署名鍵を、別々の台帳で管理すること
• 鍵が失効したとき、過去の署名をどう扱うかのルール

冒頭の基盤は、届いたデータをいちいち確認せずに受け入れていました。これは確認をなくしたのではありません。確認のタイミングを「データを受け取るたび」から「登録時と、その後の失効の見張り」へ移したのです。取引先の受け入れ（サプライヤーオンボーディング）とは、この移す作業です。移した先の運用を考えないまま登録だけを整えると、失効・更新・復旧が起きたときに判断の根拠がなくなります。

以下では、この部品メーカーの例で、制度が求めることと鍵の実際の扱い方を、1つの手順にまとめて見ていきます。

サプライチェーンでブロックチェーンを使う全体像は「サプライチェーンにブロックチェーンが必要な理由とは」、デジタル製品パスポートの制度の基礎は「デジタル製品パスポート（DPP）とは」で解説しています。

何を、なぜ別々に登録するのか

分けて登録するのは「法人の身元」「担当者の権限」「署名鍵」の3つです。3つを分けるのは、変わる速さがまるで違うからです。変わる頻度は2桁違います。

会社の登記は、数年に一度しか変わりません。担当者は異動のたびに変わります。鍵は、端末を入れ替えたり漏えいの疑いが出たりするたびに変わります。もし3つを1つのIDにまとめていると、鍵を1本替えるだけで会社の登録からやり直しです。そのたびに、相手先の管理部門に手間をかけることになります。

登録時に確かめる事実と、失効のきっかけは後半にまとめています。

分けておくと、失効したときに影響する範囲を狭くできます。冒頭のA社のように担当者1名が退職しても、A社の過去データを全件確かめ直す必要はありません。逆に3つを1つのIDにまとめていると、どれが失効したのかを後から見分けられません。念のため全件を疑う運用になりがちです。

EUの制度も同じ方向です。EUにはデジタル製品パスポート（DPP）という仕組みがあります。製品の材料・修理・リサイクル情報を、電子的に見られるようにするものです。その登録簿を定めた実施規則（EU）2026/1778では、事業者の「検証済み」の状態に期限があります。

検証済みの状態は、検証から3年たつと切れます。証明に使った電子的な身元証明が先に切れれば、その時点で終わります。切れたら、検証をやり直すまで新しいパスポートを登録できません（同規則第4条・第5条）。少なくともこの制度では、法人の登録がずっと有効だとは考えられません。

取引先を、どの番号で登録するか

最初に迷うのは、どの番号を取引先の主な番号にするかです。法人を指す番号、拠点や役割を指す番号、鍵に結び付く番号は、出す機関も更新のルールも違います。そのため実務では、1つの番号だけでは足りません。主な番号を1つ決めたうえで、ほかの番号との対応表を持つのが現実的です。

番号ごとの向き不向きは次のとおりです。

発行・管理する機関と検証の方法は、後半の表にまとめています。

DIDやアカウントアドレスが示すのは「鍵を持っていること」までです。「その鍵の持ち主が実在の取引先であること」は示しません。この差を埋めるのが、受け入れ時の実在確認です。確認の結果は、後から機械で参照できる形で残します。識別子と検証可能な主張の関係は「DID・VCの導入設計」で整理しています。

EUの制度が求める確認の強さ

どこまで確かめればよいかは、EUの制度が参考になります。実施規則（EU）2026/1778では、検証済みになるための証明手段が、個人と法人で分かれています。

• 個人事業者などの個人：eIDAS規則（規則（EU）910/2014。EUの電子的な本人確認と署名の規則）に基づく適格電子署名、保証レベル「高」の電子的識別手段、またはEU法に基づく属性の電子証明で身元を証明する。
• 法人：適格電子シール（法人が付ける電子的な印）、またはEU法に基づく適格な属性の電子証明で、身元と設立の事実を証明する（EU域内での設立が求められない場合は、該当する範囲で）。

「メールアドレスと会社名を自己申告すれば登録できる」水準とは、求められる証拠の強さがはっきり違います。

見落とされやすいのが、登録を代わりに行うケースです。同規則第19条(4)は、検証済みの事業者が第三者へ登録作業を任せることを認めています。ただし、その第三者も第5条に基づく検証を受ける必要があります。内容の責任は、任せた事業者に残ります。代行入力を受け付けるなら、「誰が入力したか」と「誰が責任を負うか」を別々の欄に残しておきます。そうすれば、後から責任の分担を示せます。

担当者の権限は、どう管理するか

「A社が送ってきたデータ」と「A社の調達担当Bさんが送ってきたデータ」は、監査の場面では意味が違います。前者だけを記録していると、退職した担当者の操作を後から特定できません。そこで担当者の権限は、法人の身元とは別の期限で持ちます。やり方は大きく3つです。

• 役割の証明書（役割クレデンシャル）を出す: 法人の身元の証明とは別に、「この人がこの役割で法人を代表する」ことを示す証明を出す方式です。GLEIFのvLEI（検証可能なLEI）がこの形です。法人の代表者の授権にもとづいて、担当者の役割を証明する仕組みです。役割を失効させても、法人の証明には影響しません。
• 基盤側の権限表で持つ: 取引先の法人登録に対して、操作できるアカウントを基盤側が管理する方式です。ERC-3643のように、「誰が任命したか」と「誰が実行したか」を分ける構造にできます。
• 鍵に権限を埋め込む: 特定の操作・期間・上限だけを実行できる委任用の鍵を出す方式です。担当者ごとに配り、期限が来れば自動で失効します。

どれを選ぶかは、権限の失効を誰が実行できるべきかで決まります。

• 取引先側で人事異動をすぐ反映したい：役割の証明書か、委任用の鍵
• 自社が最終的に止める権限を持ちたい：基盤側の権限表

3つを併用することもできます。ただし、止める手段が増えるほど、「どこで止めたか」の記録をそろえる必要が出てきます。それぞれの仕組みの詳細は後半にまとめています。

鍵の預かり方は、取引先の体力に合わせて選べるようにする

取引先には、専任のセキュリティ担当がいる大手もあれば、業務用の端末が数台の会社もあります。鍵の保管方法を1つに決めて全社に求めると、対応できない会社が出ます。そういう会社は「担当者の個人端末に鍵ファイルを置く」といったやり方に流れがちです。結果として、想定より弱い状態が生まれます。

保管方法を複数用意し、取引先ごとに選べるようにする方が、全体として実際の安全性は上がります。

取引先側の初期の負担と、責任の分かれ方は後半の表にあります。

MPCとスマートアカウントの組み合わせ方はMPCとアカウント抽象化の併用解説、資産を伴う場合の保管設計は機関投資家向けカストディ設計、HSMやMPCで署名鍵を本番運用するときの権限と復旧はHSM・MPCを使った署名鍵の本番運用で扱っています。

取引先がスマートアカウント（プログラムで動くアカウント）を使う場合も注意が要ります。スマートアカウントは秘密鍵を持たないため、通常の手順では署名を確かめられません。受け入れるなら、確かめる側の実装を分ける必要があります。また、既存のアカウントが途中からスマートアカウントのように振る舞える仕組みもあります。登録時の形を前提に固定しないようにします。詳しくは後半で説明します。

鍵を替える日に備えて、何を先に用意するか

NISTの鍵管理の指針（SP 800-57 Part 1）は、鍵ごとに使用期間（cryptoperiod）を決める考え方を示しています。鍵は端末の入れ替えや漏えいの疑いでも替わりますし、暗号の方式そのものの入れ替えも、将来の更新の理由になります。つまり鍵は、必ずいつか替わります。たまに起きる事故ではなく、定例作業として計画しておきます。

安全に替えるための定番の工夫が「事前ローテーション」です。鍵を替えるときに備え、次に使う鍵の“指紋”だけを先に登録しておきます。今の鍵が盗まれても、次の鍵を持たない攻撃者は乗っ取れません。KERIやdid:webvhといった仕組みがこの考え方を採っています。

決めておくことは3つです。

• 誰が「鍵を替える」と言えるか。その申し出を何で確かめるか
• 替えたことを、どこに記録するか
• 古い鍵の署名を、いつまで有効とみなすか

3番目が、いちばん影響の大きい決めごとです。次の章で扱います。

証明書（クレデンシャル）を使う場合は、失効をどう伝えるかも先に決めます。W3Cの標準には、失効や停止の状態をビット列で配る方法があります。状態リストの運用設計は「VCの失効設計」、発行者を信頼する根拠の管理は「VCの信頼レジストリ設計」で扱っています。

失効したあと、過去に受け取った署名済みデータをどう扱うか

冒頭のA社の問いに戻ります。この論点は実装の直前まで先送りされがちです。しかし後から方針を変えると、過去データを確かめ直すことになります。取れる立場は3つです。

それぞれに弱点があります。署名時点主義は、実はもっと前に鍵が漏れていたとき、誤って有効と扱います。現時点主義は、鍵を更新しただけで過去の記録が無効になります。理由別は、取引先が理由を正しく申告することが前提です。

実務では「理由別」が扱いやすい方法です。ただし理由別を選ぶには、最初から2つの欄が要ります。「失効理由」と「漏えいが始まったと推定される時刻」です。後から欄を足しても、過去分の理由は取引先の記憶に頼るしかありません。

もう一つ、変えられない技術上の制約があります。確定したブロックや追記専用のログに書いた記録は、後から消したり書き換えたりできません。そのため「過去の署名を無効にする」とは、元の記録を消すことではありません。無効だと示す新しい記録を追加し、確かめる側がその両方を読んで判定する、という形になります。

確かめ直しが必要と判定されたデータをどうするかは、業務側の判断です。選択肢は次のようなものです。

• 取引先に、今の鍵で署名し直してもらう
• 別の記録で裏付ける
• 影響を受ける製品ロットを特定して開示する

どれを選ぶかは、データの用途と取引契約によります。設計の段階でできるのは、確かめ直しが必要な範囲を機械で抜き出せるようにしておくことまでです。受け取ったデータを確かめる順番は後半にまとめています。

複数社でデータを共有する基盤での開示範囲と責任分担は、複数企業間トレーサビリティのデータガバナンスで扱っています。共有相手ごとに見せる範囲を変える場合は、「サプライチェーンのデータ共有設計」と「年齢・資格証明の選択的開示設計」も参考になります。

取引先ごとに、受け入れの段階を変える

取引先が数十社を超えると、鍵を自社で管理できる会社とそうでない会社が必ず混ざります。全社が同じ水準になるまで始めないと、開始時期はいちばん遅い1社に合わせることになります。段階を決め、段階ごとに扱えるデータと責任の分担を変える方が、実際には早く運用に入れます。

段階ごとの鍵のありかとデータの位置づけは、後半にまとめています。

大事なのは、段階の違いをデータの側にも残すことです。同じ形式で保存されていても、代行入力したデータと、取引先が自社の鍵で署名したデータでは、後から主張できる強さが違います。この区別を残していないと、監査や紛争の場面で、全データが弱い方の水準にそろってしまいます。

運用を始めたあと、何を見張り続けるか

受け入れは、登録で終わりません。期限のあるものが複数あるので、期限の見張りと棚卸しが定例業務として残ります。次の項目は、運用を設計するときに担当と頻度を決めておけます。

• 取引先の検証状態の期限（実施規則（EU）2026/1778の枠組みでは、検証済みの事業者の地位は最長3年で失効します）
• 鍵の使用期間の満了予定と、事前ローテーションの実施状況
• 担当者の在籍・役割の変更と、権限表との突き合わせ
• 失効状態を配る仕組み（状態リストや登録簿）が取得できること
• 受託管理している鍵の範囲と、受託をやめた取引先に残った設定
• 登録を代行している第三者の検証状態
• 確かめ直しが必要と判定されたデータの処理状況

実施規則（EU）2026/1778の第19条は、事業者に2つのことを求めています。提出する情報の正確さと完全さへの責任。そして、ITシステムとアクセス用の資格情報を守る措置です。資格情報の保護は、登録時の一度きりの作業ではありません。担当者の交代や端末の更新のたびに確かめ直すものです。

どこまで自動で見張るかは、取引先の数と扱うデータの性質から判断します。基盤側の運用監視や障害時の手順は、スマートコントラクトの本番運用解説で扱っています。

よくある質問

取引先にウォレットを持たせずに、ブロックチェーンを使う基盤へ参加してもらえますか

参加できます。基盤運営者が鍵を預かって管理し、取引先はログインして操作する形が一般的です。ただしこの場合、鍵を守る責任は運営者側に寄ります。「取引先自身が署名した」という主張も、取引先が自社の鍵で署名した場合より弱くなります。署名が誰のものかが争われうる用途では、受託管理から始めて、自社鍵での署名へ移る段階を最初から計画に入れておく方法があります。

法人番号やGLNがあるのに、なぜLEIやDIDも必要になるのですか

必要かどうかは、取引の範囲と、確認をどこまで自動にするかによります。日本国内の取引先だけを扱い、確認を人が行うなら、法人番号で足りる場合があります。海外の取引先が含まれる場合や、相手のシステムが自動で確かめる必要がある場合は、国際的に発行・検証できる番号が求められます。GS1のGLNは取引の当事者や拠点を識別する13桁の番号です。ただし法人と拠点で番号が分かれるので、どの粒度を主な番号にするかを取り決め、対応表を持つのが現実的です。

担当者が退職したとき、その人が署名した過去のデータは無効になりますか

自動的には決まりません。設計で決めた判定ルールによって変わります。署名した時点で権限が有効なら有効のまま、というルールなら、退職は過去データに影響しません。一方、鍵が漏れた状態で退職した場合は、漏えいの推定時刻より後の署名を確かめ直す、という扱いが考えられます。この使い分けには、失効理由と漏えい推定時刻の欄を最初から用意しておく必要があります。判定ルールを後から変えると、過去データ全件の確かめ直しが発生します。

取引先の鍵が漏えいしたとき、過去の記録を取り消すことはできますか

確定したブロックや追記専用のログに書かれた記録は、後から消したり書き換えたりできません。運用で選べる方針ではなく、技術上の制約です。実際の対応は、無効だと示す新しい記録を追加する形になります。確かめる側は、元の記録と打ち消しの記録の両方を読んで判定します。この打ち消しの記録を確かめる手順は、検証の仕組みを作る時点で入れておく必要があります。

EUのデジタル製品パスポート登録は、日本の取引先にも関係しますか

関係する場合があります。対象はEU市場へ製品を出す事業者です。その供給網に含まれる日本企業にも、情報提供や識別子の整備という形で要求が及ぶことがあります。

実施規則（EU）2026/1778は、登録簿の運用と、利用者の検証手順を定めています。2026年7月16日に採択、同月17日に官報で公表され、公表から20日目に発効しました。個別の製品カテゴリーにいつから適用されるかは、対応する委任規則の採択と、その後の移行期間によります。自社製品の時期は、該当する委任規則の採択状況で確かめます。登録簿側のデータ設計は「デジタル製品パスポートのデータ設計」で扱っています。

実装する人向けの詳細

ここからは、部品メーカーの基盤で検証の仕組みを作る技術者向けに、登録項目・権限の仕組み・署名の検証・鍵の更新をまとめます。

3つの層で登録時に確かめる事実と、失効のきっかけ

識別子ごとの発行主体と検証方法

担当者の権限を表す3つの仕組み

• vLEIの役割クレデンシャル：法人の代表権限を持つ担当者（LAR）が、発行機関（QVI）へ授権クレデンシャルを渡します。それに基づき、公式な組織上の役割を示すOORクレデンシャルをQVIが発行・失効します。一方、「サプライヤーの担当者」のような業務上の役割を示すECRクレデンシャルは、法人自身が発行することも、法人の授権を受けたQVIが発行することもできます。
• 基盤側の権限表：ERC-3643（許可制トークンの標準）では、所有者が任命したエージェントという役割に、発行・焼却・凍結などの運用操作が割り当てられています。投資家が秘密鍵を失った場合に、本人のオンチェーンID契約へ紐づけたまま新しいアドレスへ資産を移す復旧関数も定義されています。任命者と実行者が分かれるこの構造は、トークン以外の業務基盤でも流用できます。仕組みはERC-3643の許可制トークン設計で詳述しています。
• 委任鍵：スマートアカウントで、特定の操作・期間・上限だけを実行できる委任鍵を発行します。設計上の考え方はセッションキーの設計解説で扱っています。

鍵の保管方式ごとの初期負荷と責任分界

スマートアカウントの署名を確かめるには

スマートアカウントは秘密鍵を持たないため、通常の署名検証の手順では確かめられません。検証側はERC-1271が定める isValidSignature(bytes32,bytes) を呼び出します。戻り値が定められたマジックバリュー 0x1626ba7e と一致するかを確認します。

これは運用で選べる方針ではありません。契約アカウントを受け入れるなら、検証側の実装を分けるしかない、という制約です。同標準は、呼び出し時にガス上限を固定値で埋め込まないよう注意を促しています。実装によって消費量が大きく変わる点も、設計時に考慮できます。

2025年5月7日、イーサリアムのPectraアップグレードでEIP-7702が有効になりました。これにより、既存の外部所有アカウント（秘密鍵で直接操作する通常のアカウント）が、委任先のコントラクトコードを指定して契約アカウントのように振る舞えます。ERC-4337のEntryPointではv0.8でこの仕組みへの対応が取り込まれ、後続のv0.9にも引き継がれています。

取引先のアカウントが途中でこの形に切り替わる可能性があります。「登録時は外部所有アカウントだった」という前提を、検証ロジックに固定しない方が安全です。両者の関係はERC-4337とEIP-7702の比較で整理しています。

鍵の使用期間と事前ローテーションの仕組み

SP 800-57 Part 1は、2020年5月公開のRevision 5に続き、Revision 6の初版ドラフトが2025年12月5日に公開されました。意見募集は2026年2月5日に終わっています。このドラフトでは、FIPS 203・204・205で標準化された耐量子計算機暗号アルゴリズムの取り込みが、更新点として挙げられています。

KERI（鍵イベント受信基盤）は、各確立イベントに次回使用する鍵のダイジェストを含めます。これにより、今の鍵が漏れても、攻撃者がまだ公開されていない次の鍵を持たない限り、識別子の支配権を奪えません。

鍵の更新履歴は、鍵イベントログ（KEL）として検証できる形で連なります。同じ順序番号については最初に観測されたイベントを正とするので、攻撃者が別の更新履歴を示す道も塞げます。同じ考え方は、did:web に検証できる履歴を加えたdid:webvhにもあります。事前ローテーション用の鍵と、更新を承認するウィットネス（任意の立会い役）という仕組みです。

実装時に決める3点を具体的に書くと、次のとおりです。

1. 更新の申告経路
   誰が「鍵を替える」と言えるか（取引先の代表者 / 基盤運営者 / 両者の合意）
   その申告自体を何で検証するか（旧鍵の署名 / 事前コミットした次鍵 / 帯域外の確認）

2. 更新の記録先
   更新イベントをどこへ書くか（検証可能なログ / 基盤の登録簿 / 両方）
   更新時刻をどう証明するか（ブロック番号 / タイムスタンプ / 監査ログ）

3. 旧鍵の扱い
   旧鍵の署名を、いつの時点まで有効と見なすか
   その判断を「更新理由」によって変えるか

失効の伝え方については、W3Cが2025年5月15日にVerifiable Credentials Data Model 2.0を勧告として公開しました。同じ勧告群のBitstring Status List v1.0が、ビット列で失効や停止の状態を配る方法を定めています。

失効時の立場ごとに必要な材料と弱点

受け取ったデータを確かめる順番（例）

検証ロジックは、記録があるかだけでなく、それを打ち消す記録がないかまで確かめる作りにします。

1. 署名の形式検証：外部所有アカウントなら通常の署名検証を行い、契約アカウントならERC-1271のisValidSignatureを呼んでマジックバリューを照合します。
2. 鍵が主体へ結び付いているかの確認：署名鍵 → 担当者 → 法人の対応が、署名時点の登録内容と一致するかを確認します。
3. 打ち消し記録の確認：鍵の失効記録、担当者の権限の失効記録、法人の登録抹消記録を順に確認します。
4. 判定：失効がなければ有効。定期更新による失効なら、署名時点で有効だったものは有効を維持。漏えいによる失効なら、推定時刻より後の署名は要再確認。法人の登録抹消なら、以後の受け取りを停止し、過去分は個別に判断します。

受け入れの段階ごとの鍵のありかとデータの位置づけ

XTELAができること

私たちは、取引先の受け入れにおける識別子の対応表、鍵の保管方式の選び方、失効時の判定規則、受領データの検証ロジックを、貴社と一緒に設計・実装しています。代行入力から自社鍵署名までの段階的な受け入れをPoCで通し、既存の基幹システムとの接続方式まで具体化できます。技術構成の整理はお問い合わせからご相談ください。

主要参考資料

• Commission Implementing Regulation (EU) 2026/1778（デジタル製品パスポート登録簿の実施規則）（2026年9月24日確認）
• European Commission: Digital Product Passport — Economic operators（2026年9月24日確認）
• W3C: Verifiable Credentials Data Model v2.0（2025年5月15日勧告）
• W3C: Bitstring Status List v1.0
• Smith, Key Event Receipt Infrastructure (KERI)
• KERI: Next Key Commitment (Pre-Rotation) Commentary
• The did:webvh DID Method Specification v1.0
• GLEIF: Introducing the verifiable LEI (vLEI)（2026年9月24日確認）
• GS1: Global Location Number (GLN)（2026年8月16日確認）
• ERC-1271: Standard Signature Validation Method for Contracts
• ERC-3643: T-REX — Token for Regulated EXchanges
• eth-infinitism/account-abstraction リリースノート（EntryPoint v0.8以降）（2026年9月24日確認）
• NIST SP 800-57 Part 1 Rev. 6（初版公開ドラフト、2025年12月5日）（2026年9月24日確認）
• 経済産業省: ウラノス・エコシステム（2026年8月16日確認）

資料の確認日と注意

法令・規格・仕様の一次資料は2026年9月24日に確認しました（GS1と経済産業省のページは2026年8月16日確認）。2026年9月24日時点で、SP 800-57 Part 1 Revision 6の最終版は未公開です。同じく2026年9月24日時点で、did:webvhの最新版はv1.0です。

これは2026年9月24日時点の公開情報に基づく技術・運用設計の解説です。法令への適合や契約上の責任配分の判断は、弁護士と連携して確認してください。