医療情報システムの乱数は、暗号鍵の生成に限らず、仮IDや外部アプリの認証値にも使われる。厄介なのは、生成器の予測困難性が失われても、文字数、文字種、重複の有無といった通常の機能試験には合格しうる点だ。処理は成功し、監視画面にもエラーが出ないまま、安全性の前提だけが崩れる。

この失敗の形は、ハードウェアウォレットColdcardで明らかになった乱数生成の問題と共通する。設定値の解釈違いから意図しない疑似乱数へ処理が流れ、外形上はシードの生成が続いた。製品側の根因と影響範囲は、本サイトの「Coldcardの秘密鍵を弱めた乱数生成　設定値『0』を見逃した5年」で整理している。本稿が扱うのは、同じ「静かな劣化」を医療情報システムの設計と監査でどう見つけるかである。

仮IDの問題──法的な区分と生成方式を分ける

医療データから氏名などを外し、別の識別子へ置き換える運用は珍しくない。ただし、「仮名加工情報」「匿名加工情報」「研究用の仮ID」は同義ではない。どの情報を残し、元データとの対応表を誰が持ち、第三者へ何を渡すかによって法的な扱いが変わる。仮IDも、暗号学的乱数、秘密鍵を使った決定論的な変換、管理された対応表など複数の方法で作られうる。乱数を使うこと自体が法制度上の定義ではない。

個人情報保護委員会のガイドラインは、匿名加工情報を作る際に氏名などを仮IDへ置き換え、置換アルゴリズムと乱数などのパラメータを保有していれば元の個人情報と容易に照合できるとして、作成後にそのパラメータを破棄するよう求めている。ここで守る対象は仮IDの文字列だけではない。置換を再現する情報、元データとの対応関係、加工方法を含む一連の管理である。

乱数で仮IDを作る実装では、候補空間が狭い、同じ初期値が再利用される、予測可能な時刻を種にするといった欠陥が識別リスクを押し上げる。一方で、十分な乱数を使えばデータ全体が自動的に安全になるわけでもない。年齢、地域、受診歴など残した属性の組み合わせから本人を絞れる場合がある。NISTIR 8053は、非識別化を複数の手法から成る取り組みと位置づけ、非識別化されたデータでも再識別される場合があると整理している。乱数品質の監査と、データセット全体の再識別リスク評価は別の作業になる。

SMART on FHIR──二つの予測不能な値

SMART on FHIR（Substitutable Medical Applications, Reusable Technologies on FHIR）は、電子カルテなどのFHIRサーバーへ第三者アプリが接続するための認可の枠組みだ。アプリはOAuth 2.0の認可コードを受け取り、それをアクセストークンと交換して、許可された範囲の医療情報へアクセスする。

HL7 InternationalのSMART App Launch 2.2.0は、全SMARTアプリにProof Key for Code Exchange（PKCE）への対応を求め、サーバーはS256方式に対応し、plain方式を受け入れてはならないと定めている。さらに、セッションごとに作るstateには最低122ビットのエントロピーを求める。stateはクロスサイト・リクエスト・フォージェリやセッション固定への対策であり、PKCEは認可コードの横取りや注入への対策だ。用途は異なるが、どちらも値が予測されにくいことを前提にする。

PKCEでは、アプリが元の文字列code_verifierを作り、そのSHA-256ハッシュからcode_challengeを生成する。認可要求ではchallengeだけを送り、トークン交換時にverifierを提示する。サーバーは両者の対応を確かめてからトークンを発行する。

IETFのRFC 7636は、この仕組みが攻撃者にcode_verifierを知られず、推測もされないことに依存すると明記し、暗号学的にランダムで最低256ビットのエントロピーを持つ値の生成を推奨している。弱い生成器でも、アプリが作ったverifierとchallengeは数学的には対応する。サーバーから見れば検証は成功するため、認可フローの正常終了は乱数品質の証明にならない。

code_verifierからcode_challengeを作り、認可コードをアクセストークンに交換するPKCEの流れを示す図

乱数らしい見た目とエントロピーは別物

単発の出力から、生成器が攻撃者にとって予測困難かどうかを判定するのは難しい。決定論的な生成器でも、出力の文字列は毎回違って見える。ハッシュ処理を重ねれば分布の偏りも見えにくくなるが、元の候補数が増えるわけではない。形式検査、重複検査、一般的な機能試験だけでは生成経路の取り違えを見落とす。

NIST SP 800-90Bは、乱数ビット生成器に入るエントロピー源について、設計原則、最小エントロピーの評価、検証試験を規定している。健全性試験は調整処理の前にノイズ源のサンプルへ適用し、起動時には連続する1024サンプル以上を継続的健全性試験にかける。永続的な異常を検出した場合は出力を停止する要件も置く。これは「大量の最終出力を眺めて乱数らしさを確かめる」という検査とは対象が違う。

確認点は三つに分かれる。第一は設計時で、どの機能がどの乱数APIとエントロピー源に依存し、代替経路へ切り替わる条件は何かを記録する。第二はビルドと更新時で、有効化フラグ、ライブラリーの結合先、失敗時の挙動を自動試験で固定する。第三は運用時で、エントロピー源の健全性試験が実際に動き、異常時に利用側へエラーを返して出力を止めるかを監視する。三つは異なる故障を対象とし、互いの代用にはならない。

修正後に残るものを洗い出す

生成器の欠陥が見つかったとき、コードの修正と過去の影響調査は分けなければならない。CoinkiteはColdcardの安全公告で、ファームウェアを更新しても既存のシードは変更も修復もされないと説明している。同じ原理は、予測困難性が必要な値をすでに発行したシステムにも当てはまる。修正版が守るのは新しい出力であり、過去の出力は自動的に強くならない。

仮IDなら、影響期間、生成方式、配布先、対応表やパラメータの保管状況を調べ、再発行やデータセットの差し替えが必要かを判断する。PKCEのcode_verifierやstateは短命だが、過去のアクセスログ、トークンの有効期間、異常な利用の有無を確認する余地がある。値の種類、保存期間、外部提供の範囲が違うため、すべてを同じ手順で処理するのは適切でない。

厚生労働省は2026年6月に「医療情報システムの安全管理に関するガイドライン」第7.0版を公表し、医療機関などに同ガイドラインの順守を求めている。ただし、国内の医療情報システムで仮IDやSMART認証値の乱数品質を原因とする事故を個別に示す公的資料は、本稿の執筆時点で確認できていない。本稿の三つの確認点は、国内事故の発生を示すものではなく、国際標準と公開事例から導いた設計・監査上の論点である。

乱数生成を設計時、ビルド時、運用時の三段階で確認する項目を並べた図

よくある質問

仮IDは必ず乱数で作るのか
必ずしもそうではない。暗号学的乱数を使う方式のほか、秘密鍵を使う決定論的な変換や、厳格に管理した対応表を使う方式もある。確認すべきなのは方式名ではなく、推測や照合への耐性、対応情報の保管、利用目的に合った法的な区分である。

PKCEでS256を使えば乱数の問題は解消するのか
解消しない。S256はcode_verifierからcode_challengeを作る方法であり、元のverifierに十分なエントロピーがあることを前提にする。元の候補が少なければ、ハッシュ後の文字列が長く見えても推測への耐性は増えない。

乱数の統計検定に合格すれば安全なのか
合格だけでは足りない。必要なのは、エントロピー源の最小エントロピー評価、起動時と継続運用中の健全性試験、生成器までの結合経路、異常時の停止動作を一体で確認することだ。最終出力の見た目は、その一部しか示さない。

生成器を直した後に何を調べるのか
影響を受けた版と期間、その間に作った値の種類、保存期間、外部への提供先を特定する。仮IDの再発行、研究データの差し替え、トークンやセッションの失効など、必要な対応は値の用途ごとに変わる。