ModelScanでAIモデルを調べる4工程｜外のモデルを持ち込む前に

「研究開発の部署が、公開されているAIモデルを次々に試している。社内のサーバーに置く前に、何か確かめるべきなのか」「モデルはデータの塊だと思っていたが、開くだけで危ないことがあると聞いて驚いた」——AIの活用を進める会社で、情シスやAIガバナンスの担当から聞こえてくる声です。公開モデルを社内で試し、業務の仕組みに組み込む場面は、ここ数年で大きく増えました。そして、モデルのファイルは、保存の形式によっては、読み込んだ瞬間に中のコードが動くプログラムになりえます。これは使ってよいモデルかを選ぶ話ではありません。本当は、社外から来たファイルを社内に通す前に、検査の工程と、引っかかったときに判断する人を決めておく話です。この記事では、オープンソースの検査の道具 ModelScan を例に、持ち込む前の4工程と責任の分け方を、2026年10月時点の公式情報をもとに整理します。

ModelScanは何をする道具か

ModelScan は、機械学習のモデルのファイルに、危険なコードが含まれていないかを調べる道具です。公式GitHubの説明によれば、ファイルを読み込んで動かすのではなく、中身を1バイトずつ文字列のように読み、危険なコードの痕跡を探す仕組みです。検査の段階でモデルを動かさないので、検査そのものが事故の引き金になることを避けられます。

2026年10月時点の公式GitHubでは、対応する保存の形式として、H5、Pickle、TensorFlow の保存形式が挙げられています。対応表には、PyTorch、TensorFlow、Keras のほか、Pickle の仕組みを使って保存する古典的な機械学習の道具も並んでいます。検査の結果は、見つかった問題の深刻度に応じて、重大・高・中・低の4段階に分けて示されます。

ライセンスは Apache-2.0 で、誰でも無償で使えます。2026年10月時点の最新の版は2026年2月に出た 0.8.8 で、公式GitHubに終了やアーカイブの告知はありません。つまり ModelScan は、社外から来たモデルのファイルを、使う前に機械的にふるいにかけるための部品です。何を通し、何を止めるかを決める仕組みそのものではない、という点を最初に押さえておきます。

作っている会社と、国内でまだ知られていない理由

ModelScan を公開しているのは、AIのモデルとアプリの安全を専門にする米国の Protect AI です。2025年7月22日、米国のセキュリティ大手パロアルトネットワークスが Protect AI の買収を完了したと公式に発表しました。発表では、Protect AI の技術と人員を同社のAIセキュリティの基盤の中核に据えるとし、モデルのファイルの検査、AIへの模擬攻撃、動いている間の保護などを挙げています。

一方で、オープンソースの ModelScan や、商用版として案内されてきた Guardian が今後どう扱われるかは、買収の発表には書かれていません。2026年10月時点でも ModelScan の公式GitHubは公開され続けていますが、商用版を検討するなら、契約の相手と製品の名前がどこになっているかを営業担当に確かめる必要があります。

日本語で ModelScan を紹介した記事は、2026年10月時点でほとんど見当たりません。確かめられる範囲で理由を挙げると、まず公式の説明がすべて英語で、利用者として機械学習の技術者を想定した書き方になっています。もう一つは、国内ではモデルを持ち込む場面の多くが、研究開発の部署や外注先の手元で完結していて、情シスやガバナンスの担当が「モデルのファイルを検査する」場面そのものがまだ少ないことです。ただ、公開モデルを社内の仕組みに組み込む会社が増えるほど、この工程は避けて通れなくなります。

モデルのファイルが「開いただけで動くもの」になりうる理由

AIモデルのファイルは、学習で得た数値の塊だと思われがちです。ところが、Python の世界で広く使われてきた Pickle という保存の仕組みは、数値だけでなく、読み込むときに実行される命令も一緒に保存できる作りになっています。Hugging Face の公式ドキュメントも、Pickle のファイルを読み込むと任意のコードが実行されうると明記し、信頼できる相手から受け取ったものだけを読み込むよう勧めています。

ModelScan の公式GitHubは、この性質を突く手口を「モデルのシリアライズの攻撃」と呼び、配布される前の保存の段階で悪意のあるコードを足す攻撃だと説明しています。起きうることとして挙げられているのは、認証情報の窃取、データの窃取、データの汚染、モデルの汚染の4つです。手口の細部はこの記事では扱いません。押さえておくべきなのは、危険がどこにあるかです。

危険は、モデルを業務に使った後ではなく、ファイルを読み込んだ瞬間にあります。研究開発の担当が試しに読み込んだ端末やサーバーには、社内のデータや鍵が置かれていることが多く、そこで中のコードが動けば、被害はモデルの外に広がります。だから検査は、読み込む前に置く必要があります。読み込んだ後のAIの振る舞いを確かめる話や、AIへの命令の乗っ取りの話は、別の対策の領域です（隔離した環境で動かす考え方やプロンプトインジェクションへの備えは、それぞれ別の記事で扱っています）。

持ち込みの経路は、管理側が思っているより多い

社外のモデルが社内に入ってくる経路は、情シスが申請を受けて導入する道だけではありません。研究開発の担当が公開の置き場から直接取ってくる、外注先が納品物の中に公開モデルを含めてくる、業務アプリの部品として公開モデルが取り込まれている、といった経路が並びます。部品や委託先を含めた調達の経路全体の点検は別の記事で整理しているので、ここではモデルのファイルに絞ります。

モデルのファイルに絞って見たときの問題は、誰がいつ、どのモデルのどの版を社内に置いたかが、どこにも残っていないことです。担当者の手元で試しただけのつもりでも、そのファイルが共有のサーバーに置かれ、別の担当がそのまま使い始める、ということが起きます。後で危険が見つかっても、どこまで広がったかをたどれません。

もう一つは、モデルを使う人と、ファイルの安全に責任を持つ人が分かれていないことです。研究開発の担当は性能を見て選び、情シスはサーバーの管理だけを見ている、という分かれ方だと、ファイルを検査する工程が、誰の仕事にもなっていない状態になります。これから説明する4工程は、この空白を埋めるための順番です。

持ち込む前の4工程の全体像

社外のモデルを持ち込む前の工程は、次の4つに分けると整理しやすくなります。それぞれの工程で、道具が担えることと人が決めることを分けておくのが要点です。

工程	道具（ModelScan など）がやること	人が決めること	決める人の例
1 入口を1つにする	なし（仕組みの外の決めごと）	社外のモデルを置いてよい場所と、置く前の申請の窓口	情シスとAIガバナンスの担当
2 読み込む前に検査する	ファイルを実行せずに読み、危険なコードの痕跡を探して深刻度で分ける	どの時点で検査するか、検査できない形式をどう扱うか	情シス（検査の運用）
3 深刻度ごとに扱いを決める	結果を4段階で示す	段階ごとの扱い、使用の可否、例外の承認	セキュリティの責任者と、使いたい部署の責任者
4 記録と再検査	検査のたびに結果を出す	記録する項目、再検査の時期、記録の保管	情シスとAIガバナンスの担当

表のとおり、道具が担うのは工程2と工程4の一部だけです。入口を決めること、結果から使用の可否を決めること、例外を認めることは、どれも人の仕事として残ります。道具を入れただけで工程ができたと考えると、検査の結果が出ても誰も読まない、という状態になりかねません。

この4工程は、検査の道具を入れる前に、紙の上で先に決めておくのが順番です。とくに工程3の扱いは、引っかかってから決めようとすると、使いたい部署の都合に引きずられます。どの段階なら止めるか、誰が例外を認めるかを、平時に決めておきます。

工程1：持ち込むモデルの入口を1つにする

最初の工程は、社外のモデルが社内に入る入口を1つにすることです。具体的には、社外から取ってきたモデルのファイルを置いてよい場所を、検査を通す専用の置き場に限ります。研究開発の担当の手元の端末や、共有のサーバーに直接置くことは認めません。

入口を1つにする理由は、検査を漏れなく通すためです。入口が複数あると、どの入口にも検査を置かなければならず、どこかで必ず抜けが出ます。置き場を1つに絞れば、検査の工程もそこに1つ置けば足ります。申請の窓口も同じ場所にまとめ、どの部署の誰が、何のために、どのモデルを持ち込みたいのかを記入してもらいます。

ただし、入口を厳しくしすぎると、担当者は窓口を通さずに手元で試すようになります。申請の項目は、持ち込む人、目的、モデルの名前と取得元、版の4つ程度にとどめ、検査の結果が出るまでの目安の日数も示しておくと、窓口が迂回されにくくなります。試すだけなら、社内のデータを置かない試験用の環境を用意するのも一つの手です。

工程2：読み込む前に検査する

2つ目の工程が、ModelScan のような道具での検査です。公式GitHubは、検査を置く位置として3つを挙げています。学習済みのモデルを読み込んで追加の作業をする前、自社で学習させた後、本番の環境に配備する前の3つです。

3つのうち、持ち込みの判断に直接かかわるのは最初の「読み込む前」です。工程1で決めた専用の置き場に入ったファイルは、読み込む前に必ず検査を通し、結果が出るまでは誰も読み込まないという決まりにします。検査の担当は、モデルを使いたい部署ではなく、情シスの側に置くのが望ましいです。使う側が自分で検査すると、急いでいるときに省かれやすいからです。

検査では、道具が対応していない形式のファイルが出てくることがあります。その場合は、検査できなかったこと自体を結果として扱い、「検査できない形式は、例外の承認がない限り持ち込まない」と決めておきます。検査できなかったものを黙って通すと、入口を1つにした意味がなくなります。

検査で分かること、分からないこと

ModelScan が見ているのは、ファイルの中にある危険なコードの痕跡です。逆に言えば、それ以外のことは検査の対象ではありません。持ち込みの判断に使う前に、検査の守備範囲を関係者で共有しておきます。

• 分かること：対応する形式のファイルに、既知の危険なコードの痕跡が含まれているかどうか
• 分かること：見つかった問題の深刻度（重大・高・中・低の4段階）
• 分からないこと：道具が知らない新しい手口や、対応していない形式のファイルの中身
• 分からないこと：モデルの性能、回答の偏り、学習データの出どころ
• 分からないこと：モデルの許諾の条件と、社内で使ってよい用途
• 分からないこと：配布元が信頼できる相手かどうか

ここで最も大切なのは、検査で何も出なかったことを「安全の証明」として扱わないことです。Hugging Face の公式ドキュメントも、自社の置き場で行っている検査について「100%確実ではない。安全かどうかを確かめるのは利用者の責任」と明記しています。検査の道具は、既知の危険を機械的に拾う網であって、網の目より小さいものは通ります。

性能や回答の偏りの確かめ方は、モデルを選ぶ段階の話で、ここでは扱いません。許諾の条件は、オープンモデルの利用条件を整理した別の記事に譲ります。ファイルの検査、性能の評価、許諾の確認は、別々の担当が別々に持つ3つの関門だと考え、1つの関門を通ったことで残りの2つを省かないようにします。

工程3：深刻度ごとに扱いを決める

3つ目の工程は、検査の結果の深刻度ごとに、モデルの扱いを決めることです。ModelScan は結果を4段階で示しますが、それぞれの段階で何をするかは道具は決めてくれません。公式GitHubは、問題が見つかったらモデルの作者にすぐ連絡して原因を確かめるよう勧めています。

扱いの決め方の一例を挙げます。重大と高の結果が出たものは、原則として持ち込まず、ファイルを置き場から隔離して、取得元と作者に確認する。中と低の結果が出たものは、セキュリティの責任者が中身を確かめ、使ってよいかを個別に判断する。何も出なかったものは、残りの関門（性能の評価と許諾の確認）に進める、という分け方です。

公式GitHubは、再現しやすくするためにモデルの中にコードを埋め込む作者もいるが、それは攻撃の余地を開くので判断して使うように、とも書いています。つまり、引っかかったものの中には、悪意のないものも混ざるということです。だからこそ、結果を機械的に一律で止めるのではなく、段階ごとに人が判断する枠を決めておく必要があります。

この扱いの表は、引っかかる前に、セキュリティの責任者とAIガバナンスの担当で合意して文書にしておきます。結果を見てから扱いを決めると、そのモデルを急いで使いたい部署の声が判断に入り込み、段階の線が案件ごとに動いてしまいます。

引っかかったときに、誰が使用可否を決めるか

検査で問題が見つかったとき、最も揉めやすいのが、誰が使ってよいかを決めるかです。モデルを使いたい部署は「このモデルでないと目的を果たせない」と言い、情シスは「危ないものは入れられない」と言います。どちらも正しいので、決める人を先に決めておかないと、話が止まります。

おすすめは、役割を3つに分けることです。持ち込みを申請した部署の責任者は、なぜそのモデルが必要かと、代わりのモデルがないかを説明する。セキュリティの責任者は、検査の結果から危険の大きさを判断する。AIガバナンスの担当は、両者の判断を記録し、例外を認める場合の条件と期限を文書にする。最終的に使ってよいかを決めるのは、セキュリティの責任者とします。

例外を認める場合は、条件と期限を必ず付けます。たとえば、社内のデータを置かない隔離した環境でだけ使う、配布元の作者に確認が取れるまでの期間に限る、同じモデルの安全な形式の版が出たら差し替える、といった条件です。期限のない例外は、いつの間にか通常の扱いになります。例外の承認は人が出し、期限が来たら見直すという線を、運用の決まりに書いておきます。

工程4：記録と再検査

4つ目の工程は、検査の記録と再検査です。記録には、モデルの名前、取得元、版、ファイルの指紋（ファイルの中身から計算した固有の値）、検査した日、検査に使った道具の版、結果、使用の可否、判断した人を残します。ファイルの指紋を残しておくと、後で同じ名前の別のファイルにすり替わっていないかを確かめられます。

再検査が必要になる場面は3つあります。1つ目は、検査の道具が新しい版になったときです。道具が新しい手口を知れば、前は何も出なかったファイルから問題が見つかることがあります。2つ目は、モデルを本番の環境に配備する前です。公式GitHubが挙げるとおり、置き場に保管した後で書き換えられていないかを確かめます。3つ目は、同じモデルの新しい版に入れ替えるときです。

記録は、モデルを使っている部署ではなく、情シスかAIガバナンスの担当が一か所で持ちます。商用版の Guardian は、検査とその結果の記録をまとめて残す機能を公式GitHubで案内していますが、オープンソースの ModelScan だけで運用する場合は、記録の置き場と様式は自社で用意する必要があります。社内のAIの台帳を持っている会社なら、モデルの行に検査の記録をつなげておくと、どのモデルが今どこで使われているかと一緒にたどれます。

保存の形式で、危うさの大きさが変わる

検査の工程を回していると、そもそも危うさの大きい形式のファイルを持ち込まないほうが早い、という場面が出てきます。Hugging Face は、Pickle の危うさへの対策の一つとして、重みだけを保存する単純な形式の SafeTensors を開発しています。同じモデルが複数の形式で配られている場合、読み込むときにコードを実行する余地の小さい形式を選ぶのが基本です。

そこで、工程1の申請の段階で、同じモデルに重みだけを保存した形式の版があれば、そちらを優先すると決めておきます。Pickle の形式しかないモデルを持ち込む場合は、その理由を申請に書いてもらい、検査の結果に加えて例外として扱うかを判断します。形式を選ぶ段階で危うさを減らせば、工程3で人が判断しなければならない件数そのものが減ります。

ただし、形式を選んだからといって検査を省いてよいわけではありません。ファイルの名前や拡張子は書き換えられますし、モデルと一緒に配られる付属のコードや設定のファイルにも目を向ける必要があります。形式を選ぶことは危うさを小さくする工夫であって、検査の工程を置き換えるものではないと位置づけておきます。

公開の置き場の検査と、自社の検査の関係

公開モデルの主な置き場である Hugging Face も、自前の検査を行っています。公式ドキュメントによれば、置き場に上げられたファイルには、ウイルスの検査と、Pickle のファイルが何を取り込もうとしているかを調べる検査が走り、怪しいものは画面上で目立つように表示されます。

そのため、「置き場が検査しているのだから自社で検査する必要はない」と考える人もいます。しかし、同じ公式ドキュメントは、その検査が完全ではなく、安全かどうかを確かめるのは利用者の責任だと書いています。置き場の検査は置き場の側の努力であって、自社の持ち込みの判断を代わりに引き受けるものではありません。

また、署名つきの更新の仕組みについても、同じドキュメントは、署名はファイルの安全を保証しないが出どころは保証する、と説明しています。出どころが分かることと、中身が安全なことは別の話です。置き場の表示や署名は、工程3で人が判断するときの材料の一つとして記録に残し、自社の検査の結果と並べて判断するのが妥当な扱いです。

無料の道具で足りるか、商用版を検討するか

ModelScan はオープンソースで無償ですが、運用にかかる手間は自社が持ちます。検査を回す環境の用意、道具の更新、結果の記録、再検査の管理は、すべて自社の担当の仕事になります。持ち込むモデルが年に数本なら、この形で十分に回ります。

持ち込みの件数が増え、複数の部署が日常的に公開モデルを使うようになると、商用版の検討が視野に入ります。公式GitHubでは、商用版の Guardian の機能として、新しい検査と広い形式への対応、Hugging Face のモデルが社内に入る前に規則を当てる仕組み、自動の組み立てと配備の流れへの組み込み、検査と結果の記録が挙げられています。工程1から工程4のうち、記録と再検査の手間を道具の側に寄せたいときに意味を持つ選択肢です。

費用の増え方は、オープンソースの場合は担当者の時間、商用版の場合は契約の条件で決まります。金額はこの記事では扱いませんが、比べるときは、持ち込みの件数と再検査の回数を同じ前提にそろえます。あわせて、先に触れたとおり買収の後の製品の扱いがどうなっているかを確かめ、契約の相手、製品の名前、提供の継続の見通しを記録に残してから判断します。

やってはいけない運用

ここまでの内容を、避けたい運用としてまとめておきます。どれも、検査の道具を入れていても起きる失敗です。

• 検査で何も出なかったモデルを、性能の評価や許諾の確認を省いてそのまま本番に使う
• モデルを使いたい部署に検査を任せ、急ぐ案件では検査が省かれる
• 検査できない形式のファイルを、結果が出ないまま黙って通す
• 重大や高の結果が出たのに、使いたい部署の都合で例外を期限なしに認める
• 検査の記録を担当者の手元に残すだけで、どのモデルがどこで使われているかをたどれない
• 道具の版を上げても、過去に持ち込んだモデルを検査し直さない

こうした失敗を防ぐのは、道具の設定ではなく、入口・検査の担当・扱いの表・例外の承認者・記録の置き場の5つを先に決めておくことです。道具はその決めごとの中で、機械的なふるいとして働きます。

よくある質問

ModelScan で何も出なければ、そのモデルは安全と言えますか

言えません。ModelScan は、対応する形式のファイルに既知の危険なコードの痕跡があるかを調べる道具です。道具が知らない手口や、対応していない形式のファイル、モデルの性能や回答の偏りは検査の対象外です。何も出なかったことは、次の関門に進めてよいという合図にとどめます。

社内で試すだけなら、検査を省いてもよいですか

おすすめしません。危険はファイルを読み込んだ瞬間にあり、試しに読み込んだ端末やサーバーに社内のデータや鍵が置かれていれば、被害はそこから広がります。試すだけの場合も、読み込む前に検査を通すか、社内のデータを置かない試験用の環境に限って試すようにします。

外注先が納品したシステムに公開モデルが入っていた場合は

納品物の中のモデルのファイルも、工程2の検査の対象にします。発注の段階で、公開モデルを使う場合は名前・取得元・版を報告すること、検査の結果を添えることを依頼の条件に入れておくと、受け入れのときに慌てずに済みます。

ModelScan は今後も使い続けられますか

2026年10月時点で、公式GitHubに終了やアーカイブの告知はなく、Apache-2.0 で公開されています。ただ、提供元の Protect AI は2025年7月にパロアルトネットワークスに買収されており、オープンソースの道具の今後の扱いは発表に書かれていません。記録の様式を道具に依存させすぎず、別の検査の道具に入れ替えられる形にしておくと安心です。

まとめ

ModelScan は、社外のモデルのファイルを実行せずに読み、危険なコードの痕跡を探して深刻度で分ける、オープンソースの検査の道具です。持ち込む前の工程は、入口を1つにする、読み込む前に検査する、深刻度ごとに扱いを決める、記録して再検査する、の4つです。検査は道具に任せ、使ってよいかの判断と例外の承認は人が持つ。検査で何も出なかったことを安全の証明として扱わない。この線を決めてから、道具を入れてください。

• ModelScan の機能・対応形式・深刻度の段階・検査を置く位置・商用版の機能は、Protect AI の公式GitHubの ModelScan のページを2026年10月16日に確かめた範囲に基づきます。版や対応形式は更新されることがあるため、利用前に最新の原文を確かめてください
• 買収の時期と内容はパロアルトネットワークスの公式の発表（2025年7月22日）、Pickle の危うさと公開の置き場の検査は Hugging Face の公式ドキュメントに基づきます。実際の運用は、自社のセキュリティの責任者と確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。