- 公開日
モデルファイルのハッシュは、信頼できる配布元から確認した同じ版の基準値と照合します。一致すれば、選んだ基準との整合を確認する材料になりますが、その基準を誰が出したかまではハッシュ比較だけで分かりません。基準元が未確認、対象版が違う、不一致がある場合は、モデルの読み込みを保留して入手経路へ戻ります。
ハッシュ照合で調べるのは、ファイルの内容に対する整合性です。提供元の真正性、モデルの無害性、性能、ライセンスは別の確認です。ダウンロードできたことやハッシュが一致したことだけで、利用を承認しないようにします。
ハッシュは何と何を比べるのか
ハッシュは、ファイルの内容から計算するダイジェストという値です。NIST FIPS 180-4は、ダイジェストを生成した後の変更を検出する用途を説明しています。例えばSHA-256を使うなら、基準値も取得したファイルの計算値も同じアルゴリズムで揃えます。
基準にする値が、単に手元のファイルから自分で計算した値だけなら、取得時点の正しさは分かりません。その値を保存して後日と比べれば、手元での変化を調べる材料にはなりますが、最初から意図しない配布物だった可能性は残ります。
確認する単位は、モデル名だけでは足りません。同じ名称でもリリース、形式、量子化の種類などが違えば、ファイルは別になります。分割された重みなら、どのファイルの集合を使うかも固定します。配布元が圧縮ファイルのハッシュを示しているのに、展開後の重みだけを計算すれば、比較する対象が違います。基準が配布アーカイブ、個々の重み、設定一覧のどれを指すかを確認します。
似た名前の別ファイルを照合して不一致になった場合、直ちに改竄と判断するのではなく、対象の取り違えを確認します。
| 照合前に固定する項目 | 必要な理由 |
|---|---|
| 提供元と公式の入口 | 誰の配布物を入手するつもりかを確定する |
| リリースや改訂の識別情報 | 変更され得る最新版という呼び方だけに依存しない |
| ファイル名、形式、構成 | 別形式や分割ファイルの混在を防ぐ |
| ハッシュのアルゴリズムと基準値 | 同じ方法で同じ対象を比較する |
| 基準値の出所と確認日 | 後から判断の根拠と時点を追う |
ファイルと基準値が一緒に差し替わる場合
攻撃者が配布ページとファイルの両方を変えられる場合、差し替えたファイルに合うハッシュを同じ場所へ置くこともできます。この状態では、一致したという事実だけでは本来の提供元の配布物か判断できません。ハッシュ値の計算が正しくても、比較の基準を信用できるかが残ります。
対策では、既に確認した公式の入口、保護されたリリース情報、信頼する提供元の署名など、基準を認証する材料を確かめます。NIST SSDF v1.1のPS.2.1は、完全性の確認を支える実装例として、保護された場所でのリリースハッシュ公開やコード署名を挙げています。特定の方式だけがすべての用途で必須という意味ではありません。
デジタル署名は、内容の変更検出と署名者の認証に使われます。NIST FIPS 186-5も、その役割を説明しています。ただし、署名ファイルが置かれているだけでは検証完了になりません。検証に使う鍵や識別情報が、信頼する提供元へ結び付くことを確認する必要があります。
別のURLに同じ値があるだけで、独立した信頼の裏付けが増えたとは限りません。同じ配布経路を複製したミラーなのか、事前に確認した提供元の記録なのかを区別します。照合の基準をどの手順で信頼したかが説明できることを重視します。
署名と検証用の情報を、出所不明のファイルに添付されたものだけで完結させると、誰を信用したのかが不明になります。利用する配布方式が示す検証手順に従い、対象版と署名者との対応を確かめます。手順や信頼する鍵を確定できなければ、真正性は未確認として扱います。
同じモデル候補を三つの状態で判断する
以下は架空のモデル「Sample Model」のリリースR1を入手する模擬例です。実モデルやファイルは取得しておらず、ハッシュ計算、署名検証、モデルの読み込みも実行していません。表の「基準値A」「計算値A」は比較関係を示す記号で、実際のハッシュ文字列ではありません。
前提は、R1の指定形式に含まれる重みファイルを照合し、成功しても別途定めた利用審査を経て読み込むことです。条件を変えるのは、基準元の確認状態と照合結果です。
| 模擬の状態 | 確認できた内容 | 残る確認 | 次の対応 |
|---|---|---|---|
| 信頼する基準値Aと計算値Aが一致 | 対象ファイルが選んだ基準と整合する | 利用条件、必要な他ファイル、読み込み環境 | 審査の次段階へ進む |
| 信頼する基準値Aに対し計算値B | 対象と基準が一致していない | 版の違い、転送破損、取り違えなどの原因 | 読み込みを止め、対象と取得元を確認 |
| 出所未確認の基準値Aと計算値Aが一致 | 手元の値同士は一致する | 基準が意図した提供元に由来するか | 真正性未確認として保留 |
二行目を「攻撃が確認された」、三行目を「安全なモデル」と表現しないことが重要です。不一致は原因調査のきっかけであり、悪意を立証した結果ではありません。一致も、基準の由来が不明なら提供元の確認にはなりません。
実際の照合では、コピーした値の一部だけでなく、完全なダイジェストを比較します。基準の取得先、対象の識別情報、使用したアルゴリズム、計算結果、判定を一組に残します。計算がエラーになった、ファイルが読めなかった、対象の一部しか確認できなかった場合は、合格や不一致へ無理に分類せず、照合未完了として扱います。
不一致があれば、読み込まずに対象を確かめる
不一致のときは、まずファイル名だけでなく版と形式を照合します。別の量子化版、更新後のファイル、分割ファイルの一部を取り違えていないかを確認します。取得が途中で止まった場合も、完了したファイルとみなして読み込まないようにします。
次に、基準情報自体が対象版に対応するかを確かめます。ページの表示だけが更新され、手元には以前の版がある場合など、照合対象の組合せが違う可能性もあります。理由を確定しないまま、手元の計算値で基準を書き換えて一致させることは避けます。
再取得する場合も、確認した経路と対象を使い、取得後に改めて照合します。同じ出所不明の場所から取り直して一致しても、基準元の問題は解消しません。原因を確認できない、公式情報と食い違う、署名の検証が成立しない場合は、提供元や組織の担当者へ確認を引き継ぎます。
調査中のファイルは、合格したファイルと区別して扱います。誤って通常の読込先へ置かれないよう、運用上の隔離方法と再開条件を決めます。削除や上書きで調査材料を失う前に、組織の手順に従って対象と結果の記録を残します。
重みだけで利用全体の確認を終えない
分割された重みを使う場合は、一部のファイルの一致を全体の一致と呼ばないようにします。モデル構成、トークナイザー、必要な設定、追加コードなどが利用に関わるなら、どの成果物を審査対象に含めたかを一覧にします。今回の重みファイルの照合が、対象外のファイルの由来まで確認したことにはなりません。
照合後に別のファイルへ置き換わったり、読込処理が別の場所を参照したりすれば、確認した対象と実際に使う対象がずれます。保存場所、版の識別、更新手順を管理し、読込前に参照対象を確認します。ハッシュを記録していても、その記録と実際の利用を結び付ける運用が必要です。
ハッシュや署名の確認が成立しても、配布元が意図したモデルに望ましくない挙動がないとは限りません。用途への適合、利用許諾、読み込み方式、実行環境の制約は別に判断します。「同じ配布物であることを確かめた」と「業務で使ってよいと判断した」を分けて記録することが、照合結果の過大評価を避ける要点です。
量子化したモデルを速度と品質・安全性で比べる方法は「量子化の速度・メモリ効果と品質・安全性をどう比べるか」で解説しています。
Open Weightモデルの自己ホストとAPI利用の責任分担は「Open Weightの自己ホストとAPI利用で責任分担を比べる」、Air-Gapped環境でモデルや脆弱性情報を更新する方法は「Air-Gapped環境でモデル・脆弱性情報をどう更新するか」で解説しています。
オンプレミスLLMが適する条件と運用負担は「オンプレミスLLMが適する条件と運用負担を比較する」で解説しています。
