AIモデルに『改ざんされていない証明』を付ける──OpenSSF Model Signing (OMS)の署名フォーマットを読む

AIモデルの重みファイルがダウンロードから配布までの間に改ざんされていないか、そのモデルを本当に主張している組織が作ったのかを、誰でも検証できるようにする仕組みが必要になっている。OpenSSF（Open Source Security Foundation）のAI/ML Security Working Groupが業界連携で策定した「OpenSSF Model Signing（OMS）」仕様のリポジトリを確認すると、モデルの署名フォーマットとして、特定のPKI基盤に依存しない柔軟な設計になっていることが分かる。

3行まとめ

• OMSは、モデルフォルダ内に配置される「デタッチ署名（detached signature）」形式で、裸鍵（bare key）・PKI証明書チェーン・Sigstoreによるキーレス署名のいずれにも対応する。署名・検証プログラム自体はこの仕様には含まれず、実装はsigstore/model-transparencyなど別リポジトリが担う
• 署名対象は単一ファイルではなく、モデル重み・設定ファイル・トークナイザー・データセットなど複数の関連ファイルをまとめた「バンドル」で、各ファイルはハッシュ（既定SHA-256、代替でBLAKE2bにも対応）で参照される。フォーマットはSigstore Bundle Formatに準拠する
• 適合スイート（conformance suite）が79件のテスト（31件の往復検証＋48件の検証）を含む形でGitHub Actionとして公開されており、ossf/model-signing-spec/conformance@mainとして再利用できる

署名が「保証しないこと」を明記する誠実さ

OMSのREADMEで目を引くのが、モデル署名で「できないこと」を先に列挙している点だ。

Model signing is not: A replacement for secure model development practices [...] A guarantee of model quality, fairness, or ethical behavior: A cryptographic signature attests to authenticity and integrity, not to the inherent quality or ethical characteristics of a model. A perfectly signed model may still produce biased results, make inaccurate predictions, or behave unethically if trained on problematic data or with flawed objectives. [...] A comprehensive security solution on its own

（モデル署名は次のものではない。安全なモデル開発プラクティスの代替ではない。モデルの品質・公平性・倫理的な振る舞いの保証ではない。暗号署名が証明するのは真正性と完全性であり、モデル本来の品質や倫理的特性ではない。完璧に署名されたモデルでも、問題のあるデータや欠陥のある目的関数で訓練されていれば、偏った結果を出したり、不正確な予測をしたり、非倫理的に振る舞ったりしうる。それ単体で包括的なセキュリティソリューションではない）

署名は「改ざんされていない」ことと「主張された作成者が作った」ことを証明するだけであり、モデルの中身の善し悪しとは無関係だ、という限界を明示している。

バンドル構造——複数ファイルを1つの検証可能な単位にまとめる

OMSの署名ファイルの中身は、次のように説明されている。

The OMS files are detached Sigstore bundles containing: DSSE Envelope > In-Toto Statements > Manifest: Describes all files in the bundle with their cryptographic hashes. Embedded Metadata: Optional additional predicates with information like model version, training data sources, and hardware used. > Signature: Cryptographically signs the in-toto statement for tamper-proofing.

（OMSファイルは、デタッチされたSigstoreバンドルであり、DSSEエンベロープの中にin-totoステートメント（すべてのファイルを暗号学的ハッシュとともに記述するマニフェスト、モデルバージョン・訓練データの出所・使用ハードウェアなどの情報を含むオプションの埋め込みメタデータ）と、そのin-totoステートメントに署名して改ざん防止するための署名を含む）

PKIについても「裸鍵」「自己署名証明書」「信頼された認証局（CA）を使うプライベート鍵基盤プロバイダー」「Sigstore（公開または非公開のSigstoreサービスを使った署名・検証）」の4方式に対応する、と幅広く設計されている。

モデル署名は何を可能にするか——5つの保証とPKI 4方式

READMEはさらに、モデル署名が下流の利用者に何を検証可能にするかを5項目で整理している。

PKI対応は「裸鍵」「自己署名証明書」「信頼されたCAを使うプライベート鍵基盤プロバイダー」「Sigstore」の4方式で、いずれも特定のPKI基盤への依存を避ける設計だと明記されている。

リファレンス実装sigstore/model-transparencyを実際に開いて確認した

「実際の署名・検証プログラムの中身までは確認していない」としていたが、この記事のためにsigstore/model-transparency（Pythonのリファレンス実装）のREADMEを直接取得して読んだ。CLIはmodel_signing sign/model_signing verifyの2つのサブコマンドを持ち、署名方式はsigstore（デフォルト）・key・certificateの3つから選べる。README内のデモは、Hugging Faceからbert-base-uncasedモデルを実際にクローンし、.gitディレクトリを除外した上でSigstoreを使って署名するチュートリアル形式になっていた。これは実装のデモンストレーションであり、Hugging Face自体がOMS形式での署名配布を採用しているという意味ではない、という点は明確にしておきたい。

なお、pip install model-signingというコマンドは、この記事で以前扱ったNVIDIAの公式Agent Skillsカタログ「NVIDIA/skills」の署名検証手順（model_signing verify certificate）の中でも登場しており、AIモデルの署名という文脈を超えて、Agent Skillsという別の成果物の署名検証にも同じツールが再利用されている実例をこの記事の外で確認済みだ。

READMEとTEST_CASES.mdで、テスト数の記載が食い違っていた

適合スイートの詳細ページ（conformance/TEST_CASES.md）も直接取得して確認したところ、テスト総数の記載がトップのREADME.mdと一致していないことに気づいた。

同じリポジトリの同じmainブランチ内で、トップのREADMEが示す数字とテスト項目一覧の実数が一致していない。テストが追加された際にTEST_CASES.mdは更新されたが、トップのREADME.mdの要約文が追随していない、という更新漏れの可能性が高い。加えてTEST_CASES.mdの「Not covered」表を見ると、仕様が定義するハッシュアルゴリズムのうちBLAKE2bとBLAKE3は、トップのREADMEには存在自体が書かれていない（READMEはSHA-256とBLAKE2bの2つのみ言及）にもかかわらず、TEST_CASES.md側にはBLAKE3への言及があり、しかもどちらも「アダプターCLIが--hash-algorithmフラグを公開していないため、適合テストの対象外」と明記されている。仕様のドキュメントが複数階層に分かれており、階層ごとに更新のタイミングがずれている状態が、この記事の確認時点（2026年8月31日）で実際に観測できた。

採用実績までは確認していない

この記事を書いている自分自身は、Sigstoreやin-totoを使ったソフトウェアサプライチェーンのセキュリティ実務に関わった経験がなく、この署名フォーマットが実際にどこまで普及しているかの評価はできない。OMSの利用実績（どのモデル配布元が実際にこの形式で署名しているか）についても、この記事ではリポジトリ本文以上の裏取りをしていない。TEST_CASES.mdが挙げていた2つ目のリファレンスアダプター（sampras343/model-transparency-goというGo実装）についても、この記事ではリンク先の存在をREADME記載から把握したのみで、実際にそのリポジトリを開いて中身を確認してはいない。日本語ではZenn・Qiitaともに、OMS単体を扱った記事は検索時点で見当たらなかった。

関連記事: AIセキュリティリスク──プロンプトインジェクション・データ漏洩対策【2026年】

感想・指摘はコメント欄へ。