HiddenLayerでAIを検査する方法｜取り込む前に誰が止めるか

「公開されている有名なサイトから落としたモデルだから、中身は安全だろう」「AIの安全対策は、変な質問に答えないようにする設定のことだと思っていた」——AIモデルや外部のエージェントを業務に取り込み始めた会社で、開発や情シスの担当者からよく聞く言葉です。けれども、AIモデルの安全は、答えの中身だけでなく、モデルのファイルそのものと、それを動かす経路にもかかっています。モデルのファイルには、読み込んだ瞬間に動くプログラムを仕込めますし、エージェントは外部の道具を呼ぶたびに新しい入り口を作ります。この記事では、この領域の専業として2026年9月に大型の資金調達を発表した米国の HiddenLayer を題材に、外から取り込むAIモデルとエージェントを社内に入れる前の検査を誰が持ち、無料の点検の道具で足りる範囲と商用の基盤を入れる判断、検知したときに止める権限をどう決めるかを、場面ごとに整理します。

HiddenLayer は、AIモデルとエージェントを狙う攻撃を見張る米国の製品

HiddenLayer は、米国テキサス州オースティンに本社を置く、AIの安全を専業にする会社です。報道によれば2022年の創業で、AIモデルそのものを狙う攻撃に早くから取り組んできました。製品は「AIの安全の基盤」としてまとめられており、公式の発表では、組織の中にあるAIの把握、AIの部品の検査、攻撃の模擬、稼働中の保護の四つの領域を一つの仕組みで扱うと説明しています。

それぞれを日本語で言い換えると次のようになります。AIの把握は、社内のどこでどんなAIが使われているかを見つけ、許可されていない利用を洗い出す機能です。部品の検査は、モデルのファイルを解析して、悪意のあるプログラムや改ざんの跡、弱点を含む依存関係を探す機能で、モデルを構成する部品や学習に使ったデータの一覧であるAI部品表を作る機能も含まれます。攻撃の模擬は、実際の攻撃に近い入力を継続的に試して弱点を探す機能です。

稼働中の保護は、動いている生成AIのアプリへの入力と出力を見張り、悪意のある入力を止め、不適切な出力が利用者に届く前に止める機能です。2026年8月には、この保護をAIのコーディング用エージェントの実行環境に広げる新しい製品を出しました。国内の報道は、エージェントの振る舞いを操る攻撃、道具の不正な利用、権限のない操作への対策を進めるものと紹介しています。

2026年9月の1億ドルの調達と、この1年で増えた機能

HiddenLayer は2026年9月2日、1億ドルのシリーズBの調達を発表しました。公式の発表によれば、主導したのはデルタブイ・キャピタルで、テン・イレブン・ベンチャーズ、モルガン・スタンレー、Microsoft の投資部門である M12、ブーズ・アレン・ハミルトンの投資部門が加わっています。資金は、稼働中のエージェントを守る機能の強化、欧州などへの展開、人員の採用に充てると説明しています。

同じ発表で、年間の継続収益がこの1年で10倍を超えたこと、証券、銀行、保険、行政、製薬、航空、米国の防衛などの分野で50社を超える新しい顧客を得たこと、週に7億人を超える利用者を持つ大手のモデル提供元を支えていることを挙げています。いずれも提供元の公表値で、第三者の検証値ではありません。また、2024年5月には、Microsoft の Azure AI が、自社で選んだ外部の公開モデルの検査に HiddenLayer の検査の仕組みを使い始めたと発表されています。検査の対象は、悪意のあるプログラム、既知の弱点、裏口の跡、モデルの層や部品の改ざんとされ、大手のクラウド事業者が、自社で配るモデルの関所として外部の検査を使っている例として参考になります。

機能の面では、2026年3月に稼働中の保護へエージェント向けの機能を加え、8月にコーディング用エージェントの保護を単独の製品として出しています。資金調達の発表から見ても、会社の重心はモデルのファイルの検査から、動いているエージェントの監視へ移りつつあると読めます。提供終了や受付停止の告知はなく、公式サイトの発表も続いています。

• 顧客数、収益の伸び、利用者数はいずれも提供元の公表値です
• 国内の販売代理店や日本語でのサポートの有無は、公式の発表では確かめられませんでした。検討する場合は、問い合わせの段階で確かめてください

誤解：有名な公開サイトから落としたモデルなら安全

社内でAIモデルを使うとき、多くの会社は Hugging Face のような公開サイトから、利用者の多いモデルを選びます。ダウンロード数が多く、評判のよいモデルなら安全だと考えがちですが、公開サイトに置かれていることは、中身が検査されていることを意味しません。公開サイトは誰でもモデルを置ける場所であり、有名なモデルを少し変えた複製や、名前をまねたモデルも混じります。

危険の典型が、Python の Pickle という保存の形式です。PyTorch などで広く使われてきたこの形式は、ファイルを読み込むときに任意のプログラムを実行できる仕組みを持っています。悪意のある人がモデルのファイルに命令を仕込めば、開発者がモデルを読み込んだだけで、社内の端末やサーバーで命令が動きます。答えの中身を試す前に、被害は起きているわけです。安全な保存の形式として SafeTensors が広がっていますが、すべてのモデルがこの形式で配られているわけではありません。

もう一つの危険は、ファイルの形は正常でも、学習の段階で裏口を仕込まれたモデルです。特定の言葉が入力されたときだけ、意図しない答えを返すように作られている場合、普段の試験では見つかりません。HiddenLayer が検査の対象として挙げているのも、悪意のあるプログラム、裏口を仕込まれた重み、弱点を含む依存関係です。ここから先は、こうした危険が実際に社内へ入る経路を場面で見ていきます。

外から入るAIの経路は四つある

「外部のAIを検査する」と言っても、入ってくる経路によって、検査できるもの、検査の持ち主が変わります。BtoBの会社で考えられる経路は、大きく四つです。

経路	例	検査できるもの	主な持ち主
公開モデルの取り込み	公開サイトから落としたモデルを社内で動かす	モデルのファイルそのもの	開発部門
委託先が作ったモデル	外注で作った需要予測や分類のモデルを受け取る	納品されたファイルと部品表	発注した部門と調達
業務の仕組みに組み込まれたAI	買った業務の道具にAIの機能が入っている	ファイルは見られない。提供元の説明と稼働中の振る舞い	情シス
エージェントが呼ぶ外部の道具	AIエージェントが MCP サーバーなどの道具をつなぐ	道具の定義、権限、呼び出しの記録	利用部門と情シス

表から分かるのは、ファイルを検査できるのは上の二つの経路だけだということです。三つ目と四つ目は、ファイルが手元に来ないため、提供元への確認と、動いている間の見張りで守るしかありません。HiddenLayer がファイルの検査から稼働中の監視へ重心を移しているのは、この現実に合わせた動きと言えます。自社のAIがどの経路から入っているかを先に数えることが、どの検査を誰に持たせるかを決める出発点になります。

シナリオ1：開発部門が公開モデルを取り込んで、社内の分類に使う

一つ目の場面は、開発部門が公開サイトから文章の分類のモデルを落とし、問い合わせの振り分けに使うケースです。開発者は手元の端末でモデルを読み込み、試験したうえで社内のサーバーに置きます。この流れで危険が起きるのは、最初に読み込んだ瞬間です。Pickle の形式に命令が仕込まれていれば、試験の前に開発者の端末で動きます。

ここで必要なのは、読み込む前にファイルを検査する関所です。公開サイトからの取り込みを、検査を通した社内の置き場からに限り、検査を通らないファイルは置き場に入れない。HiddenLayer のような製品では、モデルの置き場や開発の自動化の流れに検査を組み込めると説明されていますが、最初の一歩は、無料の点検の道具でも作れます。この場面は、商用の基盤がなくても守れる範囲が比較的広い場面です。

この場面でよく起きる失敗は、次のようなものです。どれも悪意ではなく、急いでいる現場の近道として起きます。

• 検査を通した置き場を作ったのに、試すだけだからと開発者が手元の端末で公開サイトから直接読み込む
• 有名なモデルの名前に似た、別の人が置いた複製を、ダウンロード数だけを見て選ぶ
• 一度検査したモデルの新しい版を、同じ名前だからと検査せずに差し替える
• 安全な保存の形式に変換したから安心と考え、変換の作業そのものを検査前の端末で行う

最後の例は見落とされがちです。Pickle の形式を SafeTensors に変換するには、元のファイルを一度読み込む必要があります。変換の作業も、隔離した環境で、検査を通したあとに行うのが筋です。

持ち主は開発部門です。ただし、検査の結果を見て「このモデルは使わない」と決めるのを開発者本人に任せると、締め切りに追われた判断になりがちです。検査で危険の兆候が出たモデルは、開発の責任者と情シスの二者で確かめてから使う、という線を引いておくと、現場の判断に頼りすぎずに済みます。

シナリオ2：委託先が作ったモデルを、マーケの需要予測に入れる

二つ目の場面は、マーケ部門が外部の会社に需要予測のモデルの開発を委託し、納品されたモデルを広告の予算配分に使うケースです。モデルのファイルは手元に来ますが、受け取る側のマーケ部門には検査の手段も知識もありません。委託先がどの公開モデルを元にし、どんなデータで学習したかも、説明されなければ分かりません。

この場面で効くのが、AI部品表です。ソフトウェアの部品の一覧である SBOM と同じ考え方で、モデルの元になった公開モデル、学習のデータ、依存する部品を一覧にします。HiddenLayer は検査したモデルについてこの一覧を作る機能を持つと説明していますが、受け取る側の会社が先にやるべきことは、委託の契約に、部品表の提出と、納品前の検査結果の添付を条件として書くことです。道具を持っているかどうかより、契約で求めるほうが先です。

持ち主は、発注したマーケ部門と調達の部門です。とはいえ、マーケ部門が検査結果を読めるとは限りません。情シスか開発部門に読む役を頼み、マーケ部門は「検査結果と部品表がそろうまで本番の予算配分には使わない」という判断だけを持つ。役割を分けておけば、AIに詳しくない部門でも、外から入るモデルを止められます。

シナリオ3：マーケ部門が使うAIエージェントが、外部の道具を呼ぶ

三つ目の場面は、マーケ部門がAIエージェントに、競合の調査やリードの整理を任せ、エージェントが外部の MCP サーバーや拡張の道具を呼ぶケースです。ここで危ないのは、道具の説明文や、道具が返す結果に仕込まれた指示です。エージェントはそれを命令として読み、顧客の一覧を外に送る、権限のない操作をする、といった動きを始める可能性があります。

この経路では、ファイルの検査は役に立ちません。必要なのは、エージェントが呼ぶ道具を事前に確かめることと、動いている間に、エージェントの操作を見張って止める仕組みです。HiddenLayer が2026年に加えたエージェント向けの機能と、8月のコーディング用エージェントの保護は、この場面を狙ったものです。エージェントの身元の渡し方や鍵の管理は別の記事で扱っているため、ここでは検査と監視の持ち主に絞ります。

持ち主は、エージェントを使う利用部門と情シスの二者になります。マーケ部門は「どの道具をどの業務に使うか」を決め、情シスは「その道具を社内につないでよいか」を決める。道具の追加を、利用部門だけの判断で済ませないことが、この場面の最低限の線です。稼働中の監視を商用の基盤に任せるかどうかは、エージェントの数と、扱う顧客データの量で判断します。

シナリオ4：稼働中のチャットボットに、外から細工した入力が届く

四つ目の場面は、自社のサイトに置いた問い合わせのチャットボットに、外部の利用者が細工した入力を送るケースです。社内の資料を読ませているチャットボットであれば、指示を上書きする入力によって、公開していない価格表や手順書の中身を引き出される恐れがあります。検査済みのモデルを使っていても、この危険は残ります。

HiddenLayer の稼働中の保護は、この場面で入力と出力を見張り、悪意のある入力を止め、不適切な出力が利用者に届く前に止めると説明されています。ただし、何を「不適切」とするかは、会社が決めることです。公開してよい情報と、チャットボットに答えさせない情報の線を先に引かなければ、見張りの基準が作れません。

もう一点、見張りの道具は誤って止めることも、見逃すこともあります。止めたときに顧客にどう返すか、見逃した疑いが出たときに誰がチャットボットを止めるかを決めておくことが、道具の性能より大事です。攻撃して弱点を探す演習の手順は別の記事で扱っているので、ここでは稼働中に止める判断の持ち主を決めることだけを強調しておきます。

無料の点検の道具で足りる範囲と、商用の基盤を入れる判断

モデルのファイルの検査であれば、無料で使える点検の道具もあります。たとえば、モデルのファイルに危険な命令が含まれていないかを調べる ModelScan のような道具は、公開モデルを取り込む関所としては十分に役立ちます。AIエージェントの設定や依存関係を調べる点検の道具も、同じ種類の記事で紹介してきました。

判断の観点	無料の点検の道具で足りる	商用の基盤を検討する
検査する経路	公開モデルの取り込みが中心	委託先のモデル、エージェント、稼働中のアプリまで
件数	月に数本のモデル	部門ごとに多数のモデルとエージェントがある
稼働中の監視	不要、または小規模	顧客に面したAIや、顧客データを扱うエージェントがある
記録と報告	検査結果を人が保管すれば足りる	取引先や監査に、検査と監視の記録を継続的に示す必要がある
運用の人手	開発部門が自分で回せる	専任の担当を置けず、まとめて任せたい

目安としては、検査の対象がファイルだけなら無料の道具から始め、稼働中の監視と記録が必要になった段階で商用の基盤を比べるという順番が無理のない進め方です。商用の基盤を選ぶ理由は、検査の精度よりも、検査・監視・記録を一つの画面と一つの契約にまとめられることにあります。逆に言えば、経路が一つしかない会社にとっては、まとめる利点が小さいということです。

検査を誰が持つか：情シス・開発・調達・利用部門の分担

検査の道具を入れても、結果を誰が読み、誰が判断するかが決まっていなければ、警告は誰にも読まれません。次のように役割を分けておくと、責任の空白ができにくくなります。

1. 検査の仕組みの持ち主は情シス：検査の道具の設定、検査の基準、結果の保管を受け持つ
2. 取り込みの申請は開発部門・利用部門：使いたいモデルや道具の出どころと用途を申請する
3. 契約での要求は調達・法務：委託先と提供元に、部品表と検査結果の提出を求める
4. 使ってよいかの判断は、情シスの責任者と利用部門の責任者の二者：検査結果と用途を合わせて、使う・条件付きで使う・使わないを決める
5. 稼働中の停止は情シスの当番：見張りの警告を受けて、モデルやエージェントを止める

この分担で大事なのは、申請する人と判断する人を分けることです。使いたい人が自分で安全だと判断する形にすると、検査の結果は都合よく読まれます。逆に、情シスだけで判断すると、用途を知らないまま止めすぎて、現場が申請を避けるようになります。判断を二者にするのは、速さを落とすためではなく、片方の都合で結論が決まらないようにするためです。

マーケ部門の立場では、自分たちが使うAIが検査の対象になることを前提に、道具の追加や外注のモデルを、申請の流れに乗せることが求められます。手間に感じられますが、申請の記録がそのまま、取引先から「御社はAIの安全をどう確かめているか」と聞かれたときの答えになります。

検知したときに止める権限を、先に書いておく

稼働中の監視で最も揉めるのは、止める判断です。顧客に面したチャットボットや、営業の業務で使っているエージェントを止めれば、業務が止まります。止めたあとで誤検知と分かれば、止めた人が責められます。この構図のままでは、現場は警告が出ても止めなくなります。

そこで、止める権限と、止める条件を、事前に書面にしておくことが欠かせません。たとえば「顧客データの外部への送信を検知したら、情シスの当番が利用部門の承認なしにエージェントを止めてよい」「入力の上書きの疑いが一定の件数を超えたら、チャットボットを定型の応答に切り替える」といった形です。止めた人を責めないことも、決まりの一部として書いておきます。

止めたあとの戻し方も決めておきます。誰が原因を確かめ、誰が再開を承認するか。再開までのあいだ、顧客や社内の利用者にどう伝えるか。止める手順だけあって戻す手順がないと、一度止めたAIがそのまま使われなくなり、結果として監視を外したいという声が強まります。

AIに判定させない範囲：検査結果は「材料」

検査や監視の道具にも、AIによる判定が入っています。HiddenLayer の公式の説明では、モデルの重みや入力、顧客のデータを外に出さずに検知できるとしていますが、判定の仕組みの詳しい中身は公開されていません。検査の結果は、使ってよいかを決めるための材料であって、結論ではないという位置づけを崩さないことが大事です。

具体的には、検査で問題が出なかったことを、安全の証明として扱わないことです。未知の手口は検査の基準に入っていませんし、裏口を仕込まれたモデルは、特定の条件でしか正体を見せません。反対に、検査で警告が出たモデルでも、用途によっては条件付きで使える場合があります。どちらの判断も、用途と扱うデータを知っている人が下すべきものです。

また、検査の結果を記録に残すときは、使ってよいと判断した理由を人の言葉で書いておきます。「検査で問題なし」だけでは、半年後に別の担当者が見ても判断の根拠が分かりません。どの版のモデルを、どの基準で検査し、誰が何を理由に使ってよいとしたか。根拠を書かせるのはAIではなく、判断した人です。

社内に入れてよいか：データの流れ、費用、契約

HiddenLayer を入れるときに確かめたいのは、まずデータの流れです。モデルのファイルを検査するとき、ファイルが提供元の環境に送られるのか、自社の環境の中で検査できるのか。稼働中の監視で、入力と出力の中身がどこに送られ、どれだけ保存されるのか。公式の説明では、知的財産や重み、入力、顧客のデータを外に出さずに守れるとしていますが、自社の契約の形でそれが成り立つかは、見積の段階で構成図をもらって確かめる必要があります。

費用は公開されておらず、見積で決まります。増え方は、検査するモデルの数、監視するアプリやエージェントの数、通信の量で変わると考えておくのが妥当です。顧客に面したAIが増えれば監視の対象が増え、費用も上がります。小さく試す段階では、対象を一つの経路に絞って見積をとると、比較の物差しが作れます。

契約では、検査や監視の記録を契約終了時に書き出せるか、その後いつ消されるかを確かめます。また、HiddenLayer は大型の資金調達を終えたばかりで、機能の追加が速い段階にあります。機能の名前や範囲が変わる可能性を前提に、契約の対象となる機能を書面で特定しておくと、のちの食い違いを防げます。

入れる前に確かめる項目一覧

ここまでの内容を、導入を検討する前に確かめる項目として並べます。すべてに答えが出ていなくても構いませんが、答えの出ていない項目が多いうちは、商用の基盤より先に社内の決まりを整える段階です。

• 自社のAIが、公開モデル、委託先のモデル、組み込みのAI、エージェントの道具のどの経路から入っているかを数えた
• 公開モデルの取り込みを、検査を通した社内の置き場からに限っている
• 委託の契約で、部品表と納品前の検査結果の提出を求めている
• エージェントが呼ぶ道具の追加を、利用部門だけで決めない流れがある
• チャットボットに答えさせない情報の線が引かれている
• 検査の結果を読み、使ってよいかを決める人が指名されている
• 検知したときに止める権限と条件、止めた人を責めない決まりが書面になっている
• 止めたあとの原因の確認と、再開の承認の手順がある
• 検査の対象のファイルや監視の中身が、どこに送られ、どれだけ保存されるかを確かめた
• 契約終了時に記録を書き出せるか、いつ消されるかを確かめた

小さく試す手順

商用の基盤を入れると決めた場合でも、いきなり全社の経路を対象にしないことです。次の順で、一つの経路から始めます。

まとめ

AIモデルの安全は、答えの中身だけでは決まりません。モデルのファイルに仕込まれた命令、学習の段階の裏口、エージェントが呼ぶ外部の道具、稼働中のアプリへの細工した入力と、危険は経路ごとに違う形で入ってきます。HiddenLayer は、これらを検査・監視・記録の一つの基盤で扱う製品で、2026年9月の1億ドルの調達を機に、動いているエージェントの監視へ重心を移しつつあります。ただ、道具を入れる前に決めることがあります。自社のAIがどの経路から入っているかを数え、経路ごとに検査の持ち主を決め、検査の結果を材料として人が判断し、止める権限を書面にしておく。ファイルの検査だけなら無料の点検の道具から始め、稼働中の監視と記録が必要になった段階で商用の基盤を比べる。この順番であれば、検査の道具は警告を出すだけの箱ではなく、外からAIを取り込むための関所として働きます。

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