サプライチェーンのデータ共有｜必要な項目だけ渡す方法とブロックチェーンの要否

ある完成品メーカーで、製品の不具合が見つかりました。品質保証部門は原因を調べるため、部品メーカーに依頼を出します。「部品番号AのロットL-204について、検査の結果を見せてほしい」。

依頼を受けた部品メーカーの情報システム担当は、ここで迷います。この取引先に、自社のデータを閲覧できる権限を会社単位で渡してしまってよいのか。そうすると、別の案件の単価や、ほかの顧客向けの生産量まで見えてしまうかもしれません。しかも、一度渡した値は、後から取り消せません。

決めるべきなのは「どの会社に見せるか」ではありません。「この依頼1件に、どの項目を、いつまで渡すか」です。そして、渡した値は取り消せない前提で、渡す量そのものを減らします。

設計は「どのデータを共有したいか」の一覧から始めるのではありません。まず、何のために使い、何に使ってはいけないか、データの責任者は誰か、どこまでを信頼するか、どの単位で渡すか、失効の後と障害のときにどう扱うかを決めます。

以下では、このL-204の品質調査を例に、依頼の受け付けから、渡し方の選択、失効、監査、障害時の扱いまでを順に追います。サプライチェーンでブロックチェーンを使う全体像は「サプライチェーンにブロックチェーンが必要な理由とは」「サプライチェーン可視化とは」で解説しており、ここで扱うのはその設計の詳細です。

共有の依頼1件に、何を書いておくか

会社単位の閲覧権限だと、同じ取引先が、別案件の単価や別の顧客向けの生産量まで取れてしまいます。これでは見せすぎを防げません。そこで、依頼1件ごとに少なくとも次のことを書いておきます。L-204の調査なら、こうなります。

この判定には、ABACの考え方が使えます。NISTのABACは、主体、対象、求められた操作、環境の条件といった属性と、判定のルールを照らして、許可を決める方式です（NIST SP 800-162）。

サプライチェーンでは、相手の企業、契約、製品・ロット、役割、目的、地域、時刻を属性にできます。ただし、purpose=quality_investigation（目的は品質調査）は、依頼する側の自己申告です。それだけで許可せず、調査チケットや取引関係と結びつけて確かめます。

依頼1件を処理する6つの段階

L-204の依頼が届いてから、部品メーカーの側では次のように処理が進みます。

まず、依頼してきたのが本当に完成品メーカーの品質保証部門かを確かめます。次に、L-204が実際にその会社へ納めたロットで、調査チケットと契約が有効かを確かめます。そのうえで、渡してよい項目と期限を決め、検査記録から合否などだけを切り出します。切り出したものは暗号化し、期限付きで渡します。その後も、いつ取得されたか、期限や契約の終わりに止まったかを追います。

6つの段階で行うことは、次のとおりです。

1. 認証：組織と、依頼を送ってくるシステム（ワークロード）を互いに認証する。依頼者の短い期限の資格情報と、委任元も確かめる。取引先の法人・担当者・署名鍵を受け入れ時にどう登録するかは「サプライヤー受入時のID・鍵管理」で扱います。
2. 関係の確認：対象のロット、発注・納入の関係、調査チケット、契約の版が合っているかを、取引関係を管理する台帳で確かめる。
3. 判定：許可か拒否かに加えて、どの項目を、どの細かさで、いつまで渡してよいかを決める。ほかへ転送してよいか、透かしを入れるかも決める。
4. 切り出し・証明の作成：正本から、許可された項目だけを取り出す。必要なら、集計値、合否、署名付きの証明書（credential）、暗号の技術を使った証明に変える。
5. 暗号化して渡す：受け取る人と用途に結びつけた、短い期限のURLや暗号文を渡す。復号の鍵は、データ本体とは別の手段・別の権限で管理する。
6. 監査・失効：依頼、判定、配送、取得、拒否、失効を、同じ要求IDで追う。契約の終了や事故のときは、この先の取得を止める。

サービス間の通信を相互TLS（双方が証明書で相手を確かめる暗号化通信）にしても、認可の判定は別に必要です。NIST SP 800-204Bは、マイクロサービスの環境で、相互認証とABACによる細かな認可を組み合わせる構成を示しています（NIST SP 800-204B）。

判定をAPIゲートウェイだけで行う場合は、抜け道がないかを確かめます。データの書き出し、一括処理、管理画面、バックアップからの復元が、同じ制約をすり抜けないかです。

相手が何を判断したいかで、渡し方を選ぶ

渡し方は、相手が何を判断したいかで選びます。項目の値そのものか、合否か、証明書の一部か、統計か、計算結果だけか、です。

クリーンルームは元データを出さずに共同で集計する場、差分プライバシーは集計結果から個別の値を推測しにくくする技術です。MPC（秘密計算）とTEE（隔離された実行環境）は、中身を見せずに計算する方法です。

方式ごとに、相手が手にする情報は次のとおりです。

• 項目・行単位のAPI応答：許可された値と署名
• 署名付きの証明：発行者、対象、判定、時点
• SD-JWT・BBS系の選択的開示：選んだ項目と、確かめるための証明
• 集計・クリーンルーム：合計・分布など
• MPC・TEE・ゼロ知識証明：共同で計算した結果、または命題の証明

選択的開示には標準があります。RFC 9901: Selective Disclosure for JWTsが定めるSD-JWTでは、発行者が項目を開示用の断片（disclosure）に変えます。持っている人は、選んだ断片だけを確かめる側に見せます。

W3CのData Integrity BBS Cryptosuites v1.0は、署名済みの証明書から一部の記述だけを示す派生証明（derived proof）を作る方式です。規格の段階は、参考資料の欄に記しました。

どちらも、「元データが本当か」「共有の目的が正当か」を自動で保証するものではありません。誰が測ったか、校正、対象のロット、失効の情報は、別に確かめます。証明書を使う仕組み全体は「DID・VCの導入設計」、ゼロ知識証明の基礎は「ゼロ知識証明とは」で解説しています。

失効しても、すでに渡した値は消せない

L-204の検査結果は、72時間の期限が来たり、契約が終わったりすれば、URLを止められます。しかし、完成品メーカーの側ですでに保存された合否までは消せません。

アクセス用のトークンや暗号鍵を失効させても、受け取った側が取得済みの平文や、画面のキャプチャまでは回収できないのです。そこで失効の効き目を、次の4つに分けて考えます。

• この先の取得を止める：トークン、購読、問い合わせ、ダウンロードURLを無効にする。
• この先の復号を止める：短い期間や依頼ごとのデータ暗号鍵を使い、鍵の配布を止める。
• 証明を無効にする：証明書の状態と失効の時刻を、確かめる側が確認できるようにする。
• 取得済みのデータを管理する：契約、目的の制限、保持期限、受け取った側のログ、監査、削除の証跡で管理する。

一度渡せば、技術的に完全には回収できません。ですから機密度が高い処理は、「データを渡す」から「部品メーカーの側で問い合わせを実行し、結果だけ返す」に切り替えます。

転送を制限したいとき、配布物に受け取った人のIDと要求IDを埋め込むのは、抑止と追跡に役立ちます。ただし、それは機密を守ることそのものの代わりにはなりません。

判定や監査の仕組みが止まったら、どうするか

判定のサービスが止まったとき、「前回は許可したから通す」とすると、その後の契約の終了や緊急の失効が反映されません。ですから、そうしてはいけません。

データの区分ごとに、止める条件を決めておきます。機密度の低いデータなら、署名付きの判定結果を短時間だけ使い回す。機密度の高いデータなら、判定できなければ拒否する、といった形です。

監査の基盤が止まったときも、配送を続けるか保留するかを前もって決めます。後から記録を書き足したように見えないよう、連番と時刻の証明を残します。依頼の状態の持ち方は、後半にまとめました。

ブロックチェーンを使うべきとき、使わなくてよいとき

1つの運営者、または契約で信頼されたデータハブが、認証、判定、監査を担えるとします。参加者がその記録を受け入れるなら、通常のPKI、IAM、データベース、改ざんに気づけるログで足ります。

ブロックチェーンが候補になるのは、独立した複数の会社が、1つの管理者を全面的には信頼しない場合です。参加・失効・判定ルールの版・監査のルート値の順番を、共同で確かめる必要があるときです。

許可型のブロックチェーンでも、参加ノード、複製、インデクサー、バックアップが平文を持てば、機密は守れません。チャネルや非公開データの仕組みを使う場合も、次の点を試します。

• メタデータから結びつけて推測されないか
• 参加者の追加、鍵の更新、離脱した後の過去データ
• ノードの運営者が見られる範囲

製品パスポートの識別子・イベント・オンチェーンに置く範囲は「デジタル製品パスポートのデータ設計」も参照してください。

PoCでは、うまく共有できるかより、漏れる道を試す

1. 見せすぎ：同じ会社の別部門、別の契約、別のロット、別の目的で、拒否されるか。
2. 推測：少人数の集団への繰り返しの問い合わせ、差分の比較、件数0/1の応答から、機密の値を推し量れないか。
3. 失効の遅れ：契約の終了、鍵の漏えい、担当者の異動の後に、API、キャッシュ、購読、ダウンロードが止まるか。
4. 再送：配送のタイムアウトの後に同じ配布物だけが返り、監査記録や課金が二重にならないか。
5. 運営側の侵害：データスペースの運営者、クラウドの管理者、ノードの運営者が、平文や鍵を取れる範囲を説明できるか。
6. 監査の再現：当時の契約の版・判定ルールの版・属性・失効状態から、許可や拒否の理由を計算し直せるか。

合格の条件は「APIが200を返す」ではありません。次の4つです。

• 不要な項目が、応答・ログ・エラー・バックアップに残らない
• 失効の目標時間内に、すべての経路が止まる
• タイムアウトの後の結果を照会できる
• 運営者を含めて、誰が何に責任を持つかがはっきりしている

実装前の確認項目

• データ項目ごとに、正本、責任者、機密区分、共有目的、禁止用途、保持期限がある。
• 要求主体、対象、目的、操作、期間、契約の根拠を、1つの要求IDで追跡できる。
• 会社・役割だけでなく、製品、ロット、取引関係、時間、環境を判定の入力にしている。
• 実際の値、合否、集計、選択的開示の証明、共同計算の中から、最小の方式を選んでいる。
• 正本、共有用の写し、暗号鍵、判定方針、監査ログを分離している。
• 失効が、将来の取得、将来の復号、証明、取得済みの写しのどこまで効くかを明記している。
• 判定方針・監査・鍵管理の停止時に、機密区分ごとの保留／拒否の条件がある。
• 通常のPKI・IAM・DBでは足りない共同検証の要件がある場合だけ、ブロックチェーンを比較している。

設計担当者向けの詳細

正本・配布物・記録を、どこに置くか

正本、渡すための写し、監査の記録は、同じ保存先に置きません。ブロックチェーンに載せる候補は、版IDやハッシュなどごく一部だけです。

SIEMはログを集めて監視する仕組み、Merkleルートは多数の記録を1つにまとめた要約値です。

標準と公的な手引きとの関係

GS1 EPCIS 2.0は、サプライチェーンの「何を・いつ・どこで・なぜ・どのように」を表すイベントと、その登録・照会のインターフェースを標準化しています（GS1 EPCIS and CBV 2.0）。

共通の語彙は相互運用に役立ちます。しかし、EPCISイベントの全項目を全参加者へ公開する理由にはなりません。出荷元（source）、出荷先（destination）、取引（bizTransaction）、センサーデータなどを、相手・対象・目的に応じて絞り込みます。原本と共有用の表示は分けます。EPCISとブロックチェーンの役割分担は「EPCIS 2.0とブロックチェーン」を参照してください。

日本のIPAが公開する、サプライチェーン共通のデータ連携の手引きも、営業秘密の保護、トレーサビリティ、持続可能な運営を含む業務・機能要件の整理を目的としています（IPA: データ連携の仕組みに関するガイドラインの手引き サプライチェーン共通編）。

営業秘密に当たるかどうかや、個別の契約の判断は、判定のルールに機械的に置き換えません。法務・知財の担当者の判断を、入力として受け取る設計にします。

依頼の状態と、異常時の扱い

冪等キーは、同じ依頼が何度届いても1回分として扱うための識別子です。

XTELAができること

私たちは、サプライチェーンの関係者とデータの責任表、共有要求のスキーマ、認証・認可、選択的開示、暗号鍵、監査記録、失効と障害時の状態を設計し、PoCと実装仕様まで落とし込んでいます。貴社と取引先の間で、まず1種類の共有要求を選び、「必要な項目だけを期限付きで渡す」流れを通して検証できます。技術構成の整理はお問い合わせからご相談ください。

参考資料

• IPA: データ連携の仕組みに関するガイドラインの手引き サプライチェーン共通編（2026年9月24日確認）
• IPA: Ouranos Ecosystem Dataspaces Reference Architecture Model（2026年9月24日確認）
• NIST SP 800-162: Guide to Attribute Based Access Control
• NIST SP 800-204B: Attribute-based Access Control for Microservices
• NIST SP 800-207: Zero Trust Architecture
• IETF RFC 9901: Selective Disclosure for JWTs
• W3C Verifiable Credential Data Integrity 1.0
• W3C Data Integrity BBS Cryptosuites v1.0（2026年9月24日時点では勧告候補の草案、Candidate Recommendation Draft）
• GS1 EPCIS and CBV 2.0

資料の確認日と注意

標準・公的資料は2026年9月24日に確認しました。ここで述べたのは一般的な技術・業務設計の解説です。営業秘密・契約・個人情報に関わる個別の判断は、弁護士と連携して確認してください。