あるエンジニアが、チームが今週行き詰まっている作業、つまり issue の自動整理と変更履歴の作成にちょうど使える AI agent の拡張機能を見つけた。ドキュメントは丁寧で、GitHub のスターも多い。セキュリティスキャナーにかけても警告は一つも出ない。彼はそれをチーム共用の環境に入れようとしている。
ここでいう拡張機能は、製品によって skill、plugin、MCP server などと呼ばれる。最後の MCP server は、AI ツールが外部のデータや機能に統一された方法でつながるためのインターフェースだ。共通するのは、一度入れると、agent、つまり複数のステップを自分で続けて実行する AI アシスタントが必要だと判断したときに自動で呼び出し、そのときの作業内容、ファイル、権限を一緒に持ち込むことだ。
スキャナーが何も出さなければ、入れてよいのか。2026 年 7 月に発表された研究は、あまり心地よくない答えを出している。いいえ、だ。拡張機能の危険は動き出した後に現れ、導入前のスキャンにはその瞬間が見えない。より確かな判断は、本物のデータもネットワークも書き込み権限もない環境で一度動かし、実際に何に触れたかを見ることである。
スキャナーに見えるのは、インストール時の姿だけ
スキャナーは確かに役に立つ。NVIDIA がオープンソースで公開している SkillSpector は、agent の拡張機能専用のスキャナーで、データの持ち出し、サプライチェーンのリスク、プロンプトインジェクションといった不審なパターンを探す。プロンプトインジェクションとは、文章の中に指示を隠し、AI に本来すべきでないことをさせる手口だ。ただしそのドキュメントは率直に書いている。静的解析しか行わず、スキャン対象を実行することは一切ない、と。
静的解析が見るのは、拡張機能が「どう見えるか」だ。コードに不審な文字列がないか、ファイル構成が既知の悪意あるパターンに当てはまらないか。問題は、見た目は偽れるということである。
危険な部分は実行時まで待てる
公開論文のプレプリントサーバーである arXiv に 2026 年 7 月に発表された論文「Cloak and Detonate」は、これを検証した。研究者たちは偽装の手口を設計した。悪意ある部分を梱包して隠し、導入時には見えないようにしておき、agent が実際に拡張機能を実行したときに自動で元に戻す。1,613 個の悪意ある拡張機能を 8 種類のスキャナーで試したところ、この手口はどのスキャナーも 9 割以上の確率ですり抜けた。
同じ論文は対策も示している。導入時の見た目で判断するのをやめ、隔離したサンドボックスの中で実際に動かし、機密データがシステムの境界の外へ流れ出すかを追跡する。このやり方で、研究者たちは攻撃の 97% を誤検知率 2% で検出でき、実際に出回っている悪意ある拡張機能でも 87% を検出できたと報告している。
二組の数字を並べると、言いたいことははっきりしている。拡張機能が危険かどうかは、導入時にどう見えるかではなく、動いたときに何をするかで決まる。
まず空き部屋で一度動かす
だからスキャナーの結果は入場条件として扱う。通らなければ、それ以上見る必要はない。通ったら、日常の環境に入れる前に一度だけ隔離環境で試す。小さなチームなら研究用のサンドボックスは要らない。次の順で進めればいい。
偽の作業環境を用意する。 最初の試験に本物のプロジェクトを使ってはいけない。本物の構成をまねた小さな偽プロジェクトを作り、わざとおとりをいくつか置く。偽の設定ファイル、偽の顧客データ、偽の API キー（プログラムがサービスにアクセスするための鍵）などだ。拡張機能には「このプロジェクトの変更履歴をまとめる」のような明確な作業を一つ与える。そうすれば作業をこなせるかだけでなく、おとりに近づくかどうかもわかる。
権限は三段階で開け、一段目で足りるならそれ以上開けない。 一段目は読み取りだけでネットワークなし。二段目は指定したいくつかのドメインへの接続を許す。三段目で初めて書き込みを許すが、書けるのは指定した出力フォルダーだけにする。多くの AI 開発ツールはこうした制限をすでに備えている。たとえば Claude Code のサンドボックスは、コマンドが触れられるファイルとドメインを OS に強制させる。拡張機能が一段目で主な作業をこなせるなら、それ以上を与える理由はない。
四種類の痕跡を記録する。 どのファイルを読み、どのファイルに書いたか。どのドメインに接続したか。どのツールやコマンドを呼び出したか。最終的な出力に、知っているはずのない内容が出ていないか。おとりに触れた、あるいはドキュメントに書かれていない先に接続したなら、答えは「入れない」だ。
一度の試運転が無事でも、ずっと安全とは限らない
隔離環境での試験で見えるのは、その一回で起きた振る舞いだけだ。手の込んだ悪意ある拡張機能は、本番環境らしい特徴を検知したときだけ動くなど、特定の条件がそろうまで待つことができる。一回の試験が無事だったからといって、ずっと安全とは限らない。だから試験を通った後も、普段の利用で同じ権限の制限と記録を続け、試験が終わったとたんに権限をすべて開けるようなことはしない。
また、リスクは一つの拡張機能だけから来るわけではない。issue を読むだけの拡張機能と、自動で PR を開く拡張機能は、それぞれ単独なら問題なさそうに見える。だが agent が同じ流れの中で両方を続けて呼べば、読み取りと書き込みがつながってしまう。複数のモジュールの間で権限をどう分けるかは、複数の AI モジュールが同じ仕事を奪い合うなら、直すべきは誰が書き込めるかを参考にしてほしい。スキャナーが問題を指摘した後にツールに自動で直させるかどうかは、人が判断すべき別の関門だ。AI のコンテナスキャナー自身もここに線を引いている。機械的な修正は自動でよく、ベースイメージの変更は人が決めるも参考になる。
次に誰かが外部の拡張機能を入れたいと言ってきたら、三つのことを添えてもらう。拡張機能の出どころと固定したバージョン、任せる一つの作業、隔離環境での試験で実際に触れたファイルとドメイン。三つとも答えられて初めて、チームの環境に入れる。
AI 整理カード
拡張機能の隔離試験を AI と計画する このプロンプトは、入れたい拡張機能と用途を確認したうえで、偽データ、権限の段階、記録すべき痕跡を設計し、試験の結果から導入するかどうかを判断する。
チームのために外部の AI agent 拡張機能（skill、plugin、MCP server など）を導入しようとしている。スキャナーは問題を見つけなかったが、先に隔離環境で試したい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/ai-agent-skill-install-runtime-risk-checklist/
記事の見方はこうだ。静的スキャンには実行時にだけ現れる振る舞いが見えない。だから導入前に、本物のデータもネットワークも書き込み権限もない環境で一度動かし、実際に何を読み、どこに接続し、何を呼び出したかを見てから決める。
まず私に 3 つ質問してほしい：
1. その拡張機能は何か。出どころとバージョンは何で、どんな作業を一つ任せるのか；
2. ドキュメントでは、どのファイル、ネットワーク、書き込みの権限が必要だとされているか；
3. 隔離試験に使える環境として何があるか（コンテナ、テスト用マシン、AI ツール内蔵のサンドボックスなど）。
私の回答をもとに、次を出力してほしい：
- 偽プロジェクトの設計：どんな構成をまね、どんなおとり（偽の設定ファイル、偽の顧客データ、偽の API キー）を置くか；
- 三段階の権限で試す順序と、各段階で見るべき点；
- 記録すべき四種類の痕跡と、どんな結果なら導入しないと判断するか；
- 同僚向けの結論の書式：導入する／範囲を限って導入する／導入しない、と理由。
私が触れていないツールや環境があると仮定しないこと。情報が足りなければ、まず私に質問してほしい。
試験の結果が示すのは、その一回で見えた振る舞いだけだ。導入するかどうかは、その環境に責任を持つ人が決める。
参考資料
- arXiv：Cloak and Detonate: Scanner Evasion and Dynamic Detection of Agent Skill Malware — https://arxiv.org/abs/2607.02357（2026-07-02）
- NVIDIA（GitHub）：SkillSpector README — https://github.com/NVIDIA/SkillSpector [accessed: 2026-10-11]
- Claude Code Docs：Configure the sandboxed Bash tool — https://code.claude.com/docs/en/sandboxing [accessed: 2026-10-11]
