3行でいうと

  • 入れる前に確かめられるのは、おもに「誰が出したか」（来歴）と「途中で変わっていないか」（完全性）です。「中身が安全か」は、署名やスキャンの保証の外にあり、別の評価が要ります。
  • 形式で防げる危険もあります。pickle形式の重みは読み込むだけでコードが走りえますが、safetensors形式は仕組みの上でコードを持ちません。ただし値の中の悪意（バックドア）までは別の話です。
  • プラグインとMCPサーバーは、コードを動かすものです。Claude Codeの公式文書は、版の固定（コミットSHA、アーカイブのsha256）、入れてよい供給元の許可リスト、入れる前の読み取りを、具体的な手段として示しています。

この記事は、実際に使って確かめた記録ではありません。この記事は、公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月16日に確認しました。変わることがあります。

先に結論

前提：何が「入ってくる」のか

供給網（サプライチェーン）は、自分の作ったものに入ってくる、他人の作ったものの流れです。OWASPの文書によると、AIでは、従来のソフトの部品（ライブラリ）に加えて、第三者の学習済みモデルとデータも対象に入り、そこが改ざんされたり、毒を混ぜられたりしえます。リスクの分類には、LoRAアダプターや端末内のAIも挙がっています。

入れるもの 入ったときに起きること（公式文書の記載）
モデルの重み 形式しだいで、読み込み時にコードが走る。値の中の悪意は、中身を見ても分かりにくい
プラグイン フック（シェルコマンド）、MCPサーバー、bin/の実行ファイルなどが、利用者の権限で動きうる
MCPサーバー 手元で動くものは、利用者のマシンの上のプロセス。遠隔のものは、外部のサービス

モデル：形式と署名で防げることと、防げないこと

pickle形式は、読み込むだけで危ない

Hugging Faceの公式文書によると、pickleはPythonのデータの保存形式で、PyTorchの重み（.bin、.pt）の既定です。読み込み（unpickle）の途中で、任意のコードを実行できる、と説明されています。仕組みは、保存データの中に「このモジュールを読み込め」「この関数をこの引数で呼べ」という命令を入れられるためです。

Hubは、置かれた全ファイルを検査しています。ウイルス対策ソフトのClamAVの検査と、pickleが読み込もうとするモジュールを、実行せずに一覧にして、怪しいものを印として表示する検査（Pickle Import scan）の2つです。ただし文書自身が、ClamAVはpickleの悪用を対象にしておらず、検査は完全ではなく、安全かの確認は利用者の責任で、安全・危険の一覧もベストエフォートだと書いています。署名つきのコミットは、ファイルの出所は保証しても、安全は保証しない、とも書かれています。

文書の推奨は、pickleを避けること、信頼できる利用者や組織から読み込むこと、指摘されたモジュールを確認することです。

safetensors形式は、コードを持てない

safetensorsは、その代わりの形式です。READMEによると、ファイルは、ヘッダの長さ、JSONのヘッダ（テンソルの名前、型、形、位置）、生のバイト列でできています。READMEの比較表は、任意のコードを実行しない形式として挙げています（形式の説明に実行コードの入れ場所が出てこない、というのは僕らの読みです）。ヘッダは100MBが上限で、バイト列の範囲は重ならないよう決められています。

一方、READMEは限界も書いています。テンソルの値は検証されず、NaNや無限大が入りうること、重複キーを禁じていても、すべての解析器が守るとは限らないことなどです。僕らの読みでは、これは「開くだけで他人のコードが走る」危険を避ける形式で、重みの値に仕込まれた振る舞い（バックドア）を見つける道具ではありません。OWASPは、バックドアが安全性の評価を通りうること、モデルは「バイナリのブラックボックス」で静的な検査の保証は限られることを書いています。

署名は「誰が」と「改ざんなし」を示す

Sigstoreのmodel-transparencyは、モデルの署名と検証の道具です（READMEの説明）。署名では、モデルのファイル群のハッシュ（中身から計算した指紋）の一覧を作り、それに署名します。検証では、署名が有効かを確かめ、ファイルのハッシュを計算し直して、署名時と一致するかを比べます。Sigstoreを使う場合は、署名者の身元が、短期の証明書と、追記専用のログで記録されます。

READMEが明記している制約は、次のとおりです。

READMEが保証として挙げているのは、署名が有効なこと、ファイルが署名時のハッシュと一致すること、ログに記録され身元に結びつくことです。モデルの中身が安全かどうかは、この保証の中に入っていません。これは僕らの読みで、READMEに「保証しないこと」の節はありません。

OWASPも、検証できる出所のモデルだけを使い、署名、ファイルのハッシュ、完全性の確認を行うことを、対策の1つに挙げています。別の対策に、署名つきの在庫（SBOM、AI BOM）の整備があります。SBOMは部品表で、OWASPはCycloneDXを出発点に挙げています。

プラグイン：コードが動く前提で、固定と許可リスト

Claude Codeの公式文書は、プラグインを入れることを、利用者の権限で任意のコードを動かしうることだと、最初に書いています。具体的には、次のものが動きます。

権限のルールとサンドボックスが対象にするのは、Claudeのツール呼び出しで、プラグインが自分で動かすコードは対象外、とも書かれています。警告文は、Anthropicがプラグインの中身を管理せず、検証もできない、という趣旨です。

公式文書が挙げる、確かめる手段は次のとおりです。

  1. 供給元を見る。 追加したマーケットプレイスのソースを確認する。マーケットプレイスの名前は、発行元の層（公式・コミュニティ・第三者）を示すが、中のプラグインが何をするかは示さない。公式を装う名前は拒否され、公式名は、Anthropicのリポジトリ由来のものだけが使える。
  2. 入れる前に読む。 詳細画面の「Will install」で構成を見る。フックが何を実行するかは、hooks/hooks.json、.mcp.json、bin/のファイルを自分で読む。
  3. 版を固定する。 GitHubなどのgit由来のソースには、ブランチやタグを指すrefと、40文字のコミットSHAのshaを指定できる。両方あるときはshaが使われる。claude-communityのカタログは、ほぼ全項目をコミットSHAに固定していて、別のコミットのインストールは拒否される、と書かれている。アーカイブ（archive）には、sha256を指定でき、一致しないと拒否される。
  4. npm由来のものは、インストール用のスクリプトが実行されない。 取得時に依存関係もインストールされない、と書かれている。

refとshaは公式の記載にある項目名です。ほかの項目名は、読んだ記録では確認できていないため、この記事で補った例です（値は架空で、動作確認はしていません）。

{
  "name": "formatter",
  "source": {
    "source": "github",
    "repo": "your-org/formatter",
    "ref": "v2.0.0",
    "sha": "（40文字の小文字のコミットSHA）"
  }
}

組織としては、管理設定で、入れてよい供給元を絞れます。許可リスト（strictKnownMarketplaces）、禁止リスト（blockedMarketplaces）、--plugin-dirなどの直接読み込みを拒否するdisableSideloadFlagsがあります。許可リストは、取得の前と起動時の両方で適用され、空のリスト[]はすべての供給元を拒否します。許可リストが見るのは供給元で、その中の個別のプラグインではないため、個別に止めるときは、enabledPluginsでfalseにする、と書かれています。

MCPサーバー：レジストリは名前の持ち主を確かめるが、コードは確かめない

公式のMCPレジストリは、公開されているMCPサーバーのメタデータの中央リポジトリで、サーバーのコードは持ちません（現在はプレビューで、破壊的変更やデータの初期化がありうると表示されています）。コードは、npm、PyPI、Docker Hubなどのパッケージレジストリにあり、レジストリは、そこを指す情報を持ちます。

出所の確認として働くのは、名前空間の認証です。サーバーの名前は、io.github.user/server-nameやcom.example/serverのような、逆DNSの形で、GitHubアカウントやドメインの所有を確かめた人だけが、その名前で公開できます。

セキュリティの検査は、別の場所に委ねられています。公式のページによると、レジストリは、下のパッケージレジストリと、下流のマーケットプレイス（アグリゲーター）が検査や評価を行うことに任せ、自分の役割は名前空間の認証とメタデータの提供、と書いています。悪意のあるものは、管理者が手動で削除できます。また、利用側のアプリは、レジストリを直接ではなく、同じ仕様の下流のレジストリを使う想定です。

つまり、レジストリに載っていることは、「名前の持ち主が確認されている」ことを示すにとどまり、そのコードが安全だとは、公式のページは書いていません。

見立て：入れる前の確認表と台帳

ここからは僕らの見立てです。公式の文書を、入口の確認表にまとめます。

確認 モデルの重み プラグイン MCPサーバー
誰が出したか 出し元の組織のアカウント。似せた名前に注意 マーケットプレイスの供給元、リポジトリ レジストリの名前空間、公式ドメイン
変わっていないか ファイルのハッシュ、署名があれば検証 コミットSHA、sha256で固定 パッケージの版の固定
実行で何が起きるか safetensorsを選ぶ。pickleは避ける フック、.mcp.json、bin/を読む 手元で動くか、遠隔か。渡す権限（別記事で扱っています）
あとで変わるか 版を固定 自動更新を止めるか、固定 版の固定と、変更の通知
中身の評価 自分の評価データで試す。レッドチーム 試用環境で 試用環境で

それと、台帳を1枚持つことを勧めます。入れたものごとに、名前、種類、出所、固定した版かハッシュ、承認した人、更新の方針を書きます。OWASPが勧める在庫（SBOM／AI BOM）の、社内版の最小形です。

OWASP LLM03:2025の対策10項目（要約）

OWASPの文書は、供給網の対策を次の10項目で挙げています。

  1. データの供給元とサービスの提供元を審査する（利用規約とプライバシーポリシーを含む）。
  2. 古い部品などの脆弱性を管理する。
  3. 第三者のモデルを選ぶ前に、AIのレッドチームと評価を行う。ベンチマークは、追加学習で操作されうるため。
  4. SBOM、AI BOM、ML SBOMで、最新の署名つき在庫を維持する（CycloneDXが出発点として挙げられている）。
  5. ライセンスを、ソフトウェア、ツール、データセットについて棚卸しする。
  6. 検証できる出所のモデルだけを使い、署名、ファイルのハッシュ、完全性の確認を使う。
  7. 共同開発の環境を監視、監査する。
  8. モデルとデータに、異常検知と頑健性のテストを行う。
  9. パッチの方針を持ち、支援されているAPIとモデルに依存する。
  10. 端末内のモデルは、暗号化と整合性の確認を行う。

リスクの分類は、第三者パッケージ、ライセンス、古いモデル、事前学習モデル、弱い来歴、LoRAアダプター、共同開発と変換サービス、端末内、利用規約の9つです。例には、PoisonGPT、偽のWizardLM、モデルの形式変換サービスを使ったマルウェア混入などがあります。これらはOWASPの文書の記述で、元の報告までは確認していません。

Claude Codeのプラグインのソースの種類と、固定の項目（公式の記載）
ソースの種類 固定・検証に使える項目 補足
github ref、sha（40文字の小文字のコミットSHA）
url ref、sha
git-subdir ref、sha （補足は読んだ記録になし）
npm version インストール用スクリプトは実行されない
archive sha256（64桁の16進） httpsのみ。一致しないダウンロードは拒否
command （読んだ記録に項目の記載なし） 利用者のマシンでコマンドを実行してディレクトリを作る。管理者はdisableCommandPluginSourcesで止められる

refとshaの両方を指定すると、shaがチェックアウトされます。

気をつけること

出典

更新履歴