AIモデルのファイルに潜む不正な処理をOSS「AIsbom」はどう見つけるのか

「社員がAIモデルを公開の置き場から自由に取ってきて試しているが、ファイルそのものが危ないことはあるのか」「取り込んだモデルの利用条件を、誰がどこで確かめているのか分からない」——AIの開発や検証を社内で始めた企業の、セキュリティと法務の担当者からは、こうした声が聞こえてきます。モデルのファイルは、計算に使う数値が詰まっただけのデータだと思われがちです。しかし実際には、形式によっては読み込んだ瞬間に、仕込まれた処理が動くものがあります。この記事では、モデルのファイルを読み込まずに中身を調べ、危険な処理や利用条件の制約を見つけて一覧にするOSS「AIsbom」を取り上げ、仕組み、見つけられない範囲、既定で外へ送られる情報、運営元の実績を含めた注意点、企業が導入前に決めておくことを整理します。導入や操作の手順は扱いません。

AIsbomとは何か。2026年10月時点で確かめられる事実

AIsbomは、GitHubで公開されているOSSです。リポジトリの説明では、機械学習のモデルのファイルを対象にした静的な（実行せずに調べる）セキュリティの検査の道具とされ、READMEでは、モデルのファイルに隠れた不正なプログラムとライセンスの危険を、読み込む前に、実行せずに見つけるものと説明されています。名前の後半は、ソフトウェアの部品表を指すSBOMに由来します。

公開元は、Lab700xOrgという組織のアカウントです。このラインが精査した2026年10月20日時点で、リポジトリの作成は2025年12月7日、最後の更新は10月18日でした。スターは83、派生は7で、1日あたりのスターの伸びは約0.3件です。ライセンスはApache-2.0で、商用を含めて使える条件です。正式なリリースは登録されており、最新は2026年9月14日の1.6.0版でした。6月の1.1.0版から3か月ほどで10回のリリースを重ねており、開発は活発に続いていることが分かります。

READMEによると、手元のコマンドとして動かす使い方のほか、単体で動く実行ファイル、GitHubの自動化の仕組みに組み込む部品、運営元が提供する履歴管理の画面が用意されています。このうち履歴管理の画面は任意で、使う場合は検査の結果が運営元の基盤に送られます。日本語での紹介は、確認した範囲では見当たりませんでした。

なぜモデルのファイルが危険になりうるのか

READMEは、AIのモデルはただの文章のファイルではなく、実行できるプログラムであり、知的財産でもあると位置づけています。たとえば、PyTorchの標準的な保存形式は圧縮ファイルの中にPickleと呼ばれるPythonの保存形式のデータを収めたもので、READMEは、悪意のあるモデルは読み込んだ瞬間に任意のプログラムを動かせると説明しています。

Pickleは、Pythonの中の物を保存し、読み込むときに組み立て直す仕組みです。組み立て直す過程でPythonの機能を呼び出せるため、ファイルの作り手が呼び出す先を選べば、読み込んだ側の計算機で好きな処理を動かせてしまいます。これは個別の不具合ではなく形式そのものの性質なので、直す更新を待てば解決する種類の問題ではありません。READMEも、こうした発見には共通の脆弱性番号が付かない、ファイルそのものが攻撃の中身だからだ、と書いています。

危険はPickleに限りません。READMEは、科学計算でよく使われる保存形式の多くが内部でPickleを使っていること、Kerasの形式では層の定義に任意の処理を埋め込めること、GGUFの形式では会話の型紙（チャットテンプレート）が推論のたびに動くことを、それぞれ別の入り口として挙げています。モデルの置き場から取ってきたファイルを開くことは、見方を変えれば、作り手の分からないプログラムを社内で動かすことでもあるのです。

読み込まずに調べる「静的解析」という考え方

AIsbomの中心にあるのは、ファイルを読み込まずに中身の並びを読む静的解析です。READMEによると、Pickleのデータを命令の列として分解し、システムの操作、外部の命令の実行、文字列からのプログラムの実行、通信といった危険な機能への参照を探します。そして、モデルは一度も読み込まれず、仕込まれた中身も一度も実行されないと明記しています。

参照の探し方には工夫があります。READMEによると、危険な名前そのものは出てこなくても、無害に見える機能を経由して同じ結果に至る間接的な経路も対象にしており、危険な部品の下位の部品や、実行を思わせる名前の操作は、通り道によらず指摘する規則を置いています。一方で、正規のモデルが普通に使う部品を誤って危険と判定しないよう、実際のモデルが持つ参照と照らし合わせて確かめたとも書いています。本物のモデルに警告を出す検査は使われなくなるため、見逃しより悪い結果になる、というのが公開元の考え方です。

より厳しい運用のために、知られた危険を探す方式から、許可した部品以外をすべて重大とみなす方式に切り替える厳格な設定も用意されています。ただし、許可の対象はREADMEに書かれた一部の部品に限られるため、独自の部品を使うモデルは警告が増えると考えられます。どちらの方式を使うかは、取り込むモデルの種類と、警告を確かめる人手に合わせて決めることになります。

形式ごとに何を見ているのか

READMEには、対象の形式と、それぞれで何を確かめるかが一覧で示されています。要点を、危険の入り口とあわせて表にまとめました。表の内容はすべてREADMEの記載に基づきます。

形式	危険の入り口	AIsbomが確かめる点
PyTorch・Pickle	読み込み時の組み立て直し	危険な機能への参照。連結されたデータもすべて調べ、標準外の圧縮形式は重大として名指しする
joblib・dill・NumPy	内部で使うPickle	圧縮の方式によらず中のPickleを取り出して調べる。数値の塊の後ろに置かれた参照も探す
Keras	層に埋め込まれた処理	任意の処理を持つ層と、埋め込まれたプログラムの断片を重大として指摘する
GGUF	推論のたびに動く会話の型紙	型紙の中の、安全な実行の枠から抜け出す書き方を探す。ライセンスと構造の情報も読む
ONNX	外部のデータの参照と独自の演算	モデルの置き場の外を指す参照を重大、独自の演算を中程度として示す
SafeTensors	仕組み上、処理を持たない	先頭の情報、数値の一覧、ライセンスを読む

表のうち、SafeTensorsは仕組み上プログラムを含まない形式とされ、READMEでも安全な形式として扱われています。社内で扱う形式をこちらに寄せることは、検査の道具を入れる前からできる最も効果の大きい守りの一つだと言えます。逆に、昔の形式のファイルを読み込まざるをえない場面が、検査と隔離を手厚くすべき場所になります。

もう一つ見ておきたいのが、読めなかったファイルの扱いです。READMEは、判定の「低」は、ファイルを開いて危険が見つからなかったという主張だと説明しています。ところが変更履歴によると、途中で切れたファイルや中身のない置き換えのファイルが「低」と判定されて検査を通る問題があり、これを直す変更は、まだ公開されていない1.7.0版に入る予定とされています。公開済みの版を使う場合は、読めなかったファイルが安全に見える可能性を前提に結果を読む必要があります。

ライセンスの危険も同じ一覧で示す

AIsbomは、安全面の危険と並べて、法務の危険も示します。READMEは、開発者が非商用に限るモデルを取ってきて、そのまま製品に載せてしまう例を挙げています。こうした利用条件はファイルの先頭の情報に書き込まれていることがあり、一般的な部品表の道具はそこを見落とすと公開元は説明しています。

READMEの検査結果の見本では、ファイルごとに安全面の判定と法務面の判定が並び、非商用の条件が付いたモデルには法務上の危険の印が付いています。モデルの置き場から直接調べる場合は、置き場に登録された説明の情報から、用途や構造、学習に使ったデータの名前も読み取るとされます。なお、依存する部品のライセンスについてREADMEは、申告された情報であって、判定ではないと書いています。

ここで注意したいのは、ファイルの中に書かれたライセンスは、作り手が書いた申告にすぎないという点です。書かれていなければ「不明」になり、書かれていても実際の条件と一致する保証はありません。法務の判断は、検査の結果を手がかりに、配布元の利用条件の本文を人が確かめて行うものです。「法務の印がない」は「使ってよい」という意味ではないことを、社内の利用者にも伝えておく必要があります。

部品表と「影響の有無」の文書を作る機能

検査の結果は、部品表の標準形式で書き出されます。READMEによると、既定はCycloneDXの1.7版で、ファイルごとの指紋（ハッシュ値）とライセンスの情報が入ります。もう一つの標準であるSPDXにも対応し、3.0版ではAI向けの項目を使った形式で出力できるとされます。AI向けの項目のうち、根拠を持たない消費電力や評価指標などは、空の値で埋めずに省く方針だと説明されています。

あわせて、発見ごとに実際に影響があるかを記す文書も作れます。READMEは、部品表は中に何があるかを示し、この文書はそのうちどれが本当に問題になるかを示すものだと説明しています。たとえば処理を持たない形式のモデルには、Pickleの危険の影響を受けないという記述が付きます。依存する部品については、公開の脆弱性の情報源と照らし合わせて既知の脆弱性を記しますが、影響がないとは決して書かない、とされます。使っている部品が脆弱な箇所を通るかどうかは、道具からは見えないからです。

READMEは、こうした文書を欧州のAI規則や、製品のサイバーセキュリティに関する欧州の規則、米国の医療機器の審査で求められる証拠として位置づけています。ただし、規制の要件を満たすかどうかを判断するのは、提出する企業と審査する側です。道具が出す文書は材料の一つであり、規制への適合を道具が保証するわけではありません。

前回との違いを比べる機能と、文書の充実度の採点

運用の場面で役立ちそうなのが、二つの検査結果を比べる機能です。READMEによると、新たに重大な危険が現れたとき、危険の度合いが上がったとき、確かめたファイルの指紋が変わったときに、違いとして知らせます。同じ名前のまま中身がすり替わったファイルに気づく手がかりになるため、取り込んだモデルを定期的に見直す運用と相性がよい機能です。

もう一つは、作った部品表そのものを採点する機能です。部品の特定、指紋、ライセンス、モデルの説明、学習データの出どころ、影響の有無の文書、文書自体の来歴の7つの観点で、合計100点に換算して評価します。READMEは、これを判定ではなく、どこを埋めれば点が上がるかの作業一覧だと説明しています。モデルの置き場から直接調べた場合はファイル全体を読まないため指紋が作れず、最高でも80点になる、と自ら書いている点も誠実です。

ただし、点数が高いことは、モデルが安全であることを意味しません。採点しているのは文書の項目がそろっているかどうかで、危険の有無と、記録の充実度は別の物差しです。監査の資料として点数を使う場合も、その違いを資料の読み手に説明しておく必要があります。

見つけられないものは何か：公開されている限界

AIsbomの資料で評価できるのは、見逃しを隠さずに公開している点です。リポジトリには、既存の検査の道具をすり抜けるとしてセキュリティ企業や研究者が公表した手口を再現し、AIsbomで調べた結果の表が置かれています。それによると、11件の手口のうち9件を、少なくとも一つの設定で捉えたとされます。再現に使ったファイルは無害な中身に置き換えたもので、実行はしていないと説明されています。

残る2件は部分的な検出にとどまります。1件は、標準と違う形式で圧縮されたファイルで、重大とは判定するものの、理由は入れ物の形式であって中身を解析した結果ではありません。もう1件は、通常のモデルでも使う名前を悪用する手口で、どのPickleにも付く基準の警告しか出ないと公開元は書いています。そのうえで、これは許可リストに頼る静的解析の限界だと認めています。

READMEは、守りを二層で考えるよう勧めています。一層目が読み込む前の静的な検査、二層目が、危険を含みうる昔の形式のファイルを読み込まざるをえない場合の隔離した環境での実行です。静的な検査は速いが複雑な偽装には破られうると、README自身が書いています。なお、この表は公開元が自ら作ったもので、第三者による検証の結果は確認できませんでした。

安全性の評価：注意付きとした根拠

このラインでは、紹介するOSSを公開されている事実だけで精査しています。OSSを入手したり動かしたりはしていません。AIsbomの判定は「注意付き」です。

問題が見つからなかった点から挙げます。ライセンスはApache-2.0で、利用の条件に独自の制限はありません。GitHub上にこのリポジトリのセキュリティ勧告は登録されていません。リポジトリの直下にあるのは利用者が自分で使う作業用の設定ファイルで、取り込んだだけで自動的に動く処理は確認されませんでした。スターの伸びも1日あたり約0.3件で、不自然な水増しの兆候は見られませんでした。

注意付きとした理由は、運営元の実績が乏しいことです。所有する組織のアカウントは2025年2月5日に作られ、公開リポジトリは3件、フォロワーは6です。会社名の欄も空欄で、READMEの末尾に米国の都市名があるほかは、運営の体制を示す情報は限られます。また、確認した範囲では、脆弱性の報告の窓口を定めた方針の文書は見当たりませんでした。なお、勧告がないことや問題が見つからなかったことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

既定で外へ送られる情報と、共有の機能の注意点

守りの道具を社内に入れるときに必ず確かめたいのが、外への通信です。READMEによると、AIsbomは利用状況の匿名の情報を既定で送信する設定になっています。送るのは検査した形式の種類、最も高い危険の度合い、所要時間、ファイルの数などで、ファイルの場所や名前、モデルの名前、指紋は送らないとされます。利用者を見分けるために、計算機の物理的な識別番号から作った匿名の値が付き、運営元の中継の仕組みを経てGoogle Analyticsに送られると説明されています。

このほかにも既定で動く通信があります。依存する部品の一覧に版が固定された部品があれば、部品の名前と版を公開の配布元に問い合わせてライセンスを読みます。モデルの置き場の保存の形のまま置かれたファイルを調べると、置き場にファイルの一覧と説明の情報を問い合わせます。READMEは、すべての通信を止める設定も用意していると説明しています。閉じた環境で使う場合や、問い合わせ先の記録が残ること自体を避けたい場合は、どの通信を止めるかを導入前に決めて固定する必要があります。

特に注意が要るのが、結果の共有の機能です。共有を選ぶと、部品表が運営元の基盤に送られ、30日間、推測しにくい宛先を知っていれば誰でも見られる形で公開されます。変更履歴によると、GitHubの自動化の部品では、2026年9月7日の1.4.0版より前は、設定にかかわらず毎回この共有が行われていました。それより前の版を組み込んだままの環境では、ファイル名や指紋、ライセンス、検査の結果が外に出ていた可能性があるため、版を確かめる価値があります。

悪用されうるリスク

AIsbomは守りのための道具で、攻撃のための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「検査を通ったから安全なモデルだ」という安心が独り歩きすることです。公開元自身が見逃しのある手口を示しており、検査の結果が「低」でも、読み込みを安全にしたことにはなりません。

次に挙げるのは推測ですが、検討の材料になります。見逃しの表が公開されていることは利用者にとって誠実な情報である一方、攻撃者にとっても、どの手口なら警告が弱いかを知る手がかりになりえます。そのため、一つの検査の道具だけに頼る構成は避けるのが無難です。また、部品表や共有の結果には、社内で使っているモデルの一覧と弱点の情報がまとまるため、その置き場所と見られる人の範囲も守るべき対象になります。

もう一つは、道具そのものの入手の経路です。配布されている名前はリポジトリの名前と少し異なり、単体の実行ファイルは、READMEによると一部の環境向けに電子署名がされていません。紛らわしい名前の偽物や改変された実行ファイルが出回った場合に見分けにくくなる可能性があります。なお、AIsbomが実際に悪用された事例は、2026年10月20日時点で確認した一次情報からは見つけられませんでした。

導入を検討するときに確かめること

検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、どのモデルを、どの形式で、誰の確認を経て社内に入れるかを、導入する側が先に決めることです。検査の道具は、その決まりを守るための手段の一つにすぎません。

企業が取るべき対策

一つ目は、モデルの取り込みを、ソフトウェアの部品の取り込みと同じ管理に乗せることです。誰が何をどこから取ってきたかを記録し、モデルのファイルも、外部から持ち込むプログラムとして扱う考え方を社内の規程に入れます。AIsbomを使うかどうかにかかわらず、この前提が守りの土台になります。

二つ目は、読み込む場所の分離です。検査の結果にかかわらず、昔の形式のファイルを読み込む作業は、社内の重要な情報や認証の鍵に届かない隔離された環境で行います。READMEが勧める二層の守りのうち、二層目を省かないことが、見逃しへの備えになります。三つ目は、検査を複数の手段で重ねることです。モデルの置き場が提供する検査や、別の検査の道具と組み合わせ、一つの道具の見逃しがそのまま素通りにならないようにします。

四つ目は、法務の確認の流れを決めることです。非商用などの制約の印が出たときに、法務の担当へ回す経路と、利用条件の本文を確かめる手順を決めておきます。五つ目は、調達のときの確認です。外への通信の設定、共有の機能を使わない取り決め、運営元の体制の確認を、導入の記録に残します。守りの道具も、外から持ち込むソフトウェアの一つとして、ほかの道具と同じ審査にかけることが大切です。

AIに任せる範囲と、人が決める範囲

AIsbomの判定は、言語モデルではなく決まった規則で行われます。その点で判定のぶれは少ないものの、何を危険とみなすかの規則は公開元が決めたものです。社内でこの結果を、AIのモデルを使った別の仕組みに読ませて取り込みの可否まで自動で決めさせる構成も考えられますが、取り込むかどうかの最終判断はAIに任せないことを勧めます。

AIに手伝わせるなら、検査の結果を読みやすくまとめさせる、判定の根拠になった項目を書き出させる、といった用途にとどめます。そのうえで、重大の判定、読めなかったファイル、法務の印のどれかが出たときは、人が確かめる範囲として先に決めておきます。AIには根拠を書かせ、可否は人が決めるという線引きです。次のような運用は避けてください。

• 検査の結果が「低」なら、隔離せずに業務用の計算機でそのまま読み込む
• 法務の印が出なかったモデルを、利用条件の本文を確かめずに製品に組み込む
• AIのまとめだけを見て、根拠の項目を人が確かめずに取り込みを許可する
• 結果の共有の機能を、社外秘のモデルの一覧が含まれることを意識せずに使う

どれも、道具の結果を「判断」として扱ってしまう例です。道具の結果は判断の材料であり、判断を下すのは、社内の規程に責任を持つ人です。

よくある疑問：規制対応の証拠として使えるのか

READMEは、出力される文書を欧州のAI規則や製品のサイバーセキュリティに関する規則、米国の医療機器の審査で使う証拠として位置づけています。ただし、これは公開元の説明です。規制のどの要件にどの文書が当たるかは、規制の本文と、所管する機関の指針で確かめる必要があります。道具が対応をうたっていることと、自社の提出物が要件を満たすことは別の問題です。

もう一つよく出る疑問が、モデルの置き場がすでに検査をしているのではないか、というものです。公開元は、人気のモデル上位50件を毎週調べた結果を自社のサイトで公開しているとREADMEに書いていますが、置き場側の検査との比較は確認できませんでした。いずれにしても、置き場の検査と社内の入り口の検査は、守る範囲と責任の持ち主が違うため、片方があれば足りるとは言えません。

• この記事の内容は、2026年10月20日時点でGitHubのリポジトリ、README、変更履歴、回避の手口の検証表を確かめた範囲に基づきます。
• OSSは入手・実行しておらず、検出の性能を自社で検証したものではありません。版の更新により機能や既定の設定は変わりえます。

まとめ

AIsbomは、AIモデルのファイルを読み込まずに調べ、仕込まれた処理や利用条件の制約を見つけて部品表にまとめるOSSです。対象の形式の広さ、見逃しの表を公開する姿勢、読めなかったファイルを安全と扱わないための修正など、検査の限界を自ら示す点は評価できます。一方で、運営元の実績は乏しく、匿名の利用情報の送信が既定で有効で、読めなかったファイルの扱いの修正もまだ公開前の版にとどまります。

企業がまず取り組むべきなのは、道具を選ぶことよりも、モデルのファイルを外部から持ち込むプログラムとして扱い、取り込みの経路と確認の担当を決めることです。そのうえで、検査は入り口の一層として使い、読み込む環境の隔離と人による確認を重ねます。AIsbomを検討するなら、通信の設定と版の管理を導入前に決め、結果を判断の材料として扱う運用から始めるのが現実的です。

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