生成AIの「エージェント」を業務に組み込む動きが広がるなか、その拡張機能である「スキル」(自然言語の説明文+実行可能なコードのセット)が新たな攻撃経路になりうることを示す研究が公開されました。論文「SkillMutator」(arXiv、2026年6月投稿)は、説明文は無害に見せかけつつコード側に悪意ある指示を隠す「クロスモーダル攻撃」を取り上げ、既存のスキャナがこうした攻撃をほとんど検知できていないと報告しています。
結論から言えば、外部から取り込むAIエージェントのスキルやプラグインは、ライブラリやプラグインと同じサプライチェーン上のリスクとして扱うべき段階に入った、ということです。ただし本研究は査読前(プレプリント)であり、数値や手法は今後変わりうる点に留意が必要です。本記事では、情シス(情報システム部門のセキュリティ担当者)の視点で、この研究が示す論点と現場での向き合い方を整理します。
この記事でわかること
- AIエージェントの「スキル」がなぜ攻撃面になるのか
- 研究が示した「クロスモーダル攻撃」と既存スキャナの検知率の実態
- 査読前の研究をどう受け止めるべきか(過大評価しないための前提)
- 社内でAIエージェント導入を検討する情シスが押さえる勘所と、参照すべき公的指針
AIエージェントの「スキル」とは何か
スキルとは、LLM(大規模言語モデル)エージェントに後付けで機能を足す拡張のことです。多くは、何をするかを書いた自然言語の仕様(例: SKILL.md などの説明ファイル)と、実際の処理を担う実行可能なスクリプトやリソースを組み合わせて構成されます。利用者は配布されたスキルを読み込むだけで、エージェントにファイル操作や外部API連携などの能力を追加できます。
便利な一方で、ここに落とし穴があります。スキルの「振る舞い」は、人間が読む説明文と、機械が実行するコードの両方によって決まります。説明文だけ、あるいはコードだけを見ても全体像を判断しにくい構造になっているのです。
クロスモーダル攻撃とは何か
クロスモーダル攻撃とは、説明文(自然言語)とコードという異なる「モード」の間のギャップを突く攻撃です。論文が指摘するのは、ドキュメント(説明文)は正当な作業内容を約束しているように見せかけ、その裏でスクリプトが機密データの持ち出しや不正な操作を実行する、という手口です。
人間のレビュアーは説明文を読んで「問題なさそう」と判断しがちですが、実際に動くのはコードです。説明とコードを別々に検査する従来型のチェックでは、この食い違いを見抜きにくいわけです。
既存のスキャナはどの程度見抜けているのか
研究の最も重い指摘がここです。論文によれば、こうした攻撃を検知できた割合はオープンソースのスキャナで2〜8%、商用スキャナでも9〜17%にとどまったとされています。つまり、多くの悪意あるスキルが検査をすり抜けていた、という結果です。
| 検査手段 | 論文が報告した検知率 |
|---|---|
| オープンソースのスキルスキャナ | 2〜8% |
| 商用のスキルスキャナ | 9〜17% |
研究チームは、攻撃を13カテゴリに分類し、スキャナのフィードバックを使って検知を回避する方向へ悪意あるスキルを反復的に「変異(mutate)」させるベンチマーク(SkillMutator)を構築しました。検査を回避するよう磨き上げられた攻撃を、体系的に作り出す枠組みです。
提案された防御策はどのようなものか
論文は、フロンティアモデル(高性能な大規模モデル)の推論過程を小型のオープンソースモデルへ蒸留する「4段階の推論軌跡蒸留(reasoning-trajectory distillation)」という手法を提案しています。狙いは、外部APIに依存せず、第三者にデータを渡さずに、ローカルで検知を回せるようにすることです。最も手強いテストケース(n=76)では、検知率がベースラインの17.1%から88.2%へ改善し、GPT-4o-mini(23.7%)を上回ったと報告されています。
査読前の研究としてどう受け止めるか
ここは冷静に押さえておきたい点です。本論文はarXivのプレプリント(査読前)であり、検知率の数値も、評価に使ったスキャナの種類・バージョン・テスト条件に依存します。「既存ツールは無力」「この手法なら防げる」と断定するのは早計です。1本の論文の結果を一般化しすぎず、「外部由来のAIスキルには、従来の検査ではすり抜けうる攻撃面がある」という問題提起として受け止めるのが妥当です。
情シスにとっての意味は何か
自社でLLMエージェントやAIアシスタントの拡張機能(スキル/プラグイン/拡張)を業務利用する、あるいは現場が勝手に導入している(いわゆるシャドーAI)状況を考えると、この研究は次の現実を突きつけます。
- スキルはコードである:「設定ファイルを入れるだけ」の手軽さの裏で、実行コードが動く。OSSライブラリやブラウザ拡張と同じ目線での審査が要る。
- 説明文を信じすぎない:README やスキルの説明は「作者の主張」であって、振る舞いの保証ではない。実際の権限とアクセス先(外部通信・ファイルアクセス)を見る必要がある。
- 自動スキャンだけに頼れない:研究が示すとおり、検査をすり抜ける攻撃は作れる。配布元の信頼性や最小権限の付与といった、運用側の歯止めが重要になる。
現場目線の所感
正直なところ、AIエージェントのスキルやプラグインまで一つひとつコード監査する体力は、多くの情シス部門には残っていないというのが実感ではないでしょうか。脆弱性対応やインシデント対応に追われるなか、現場が「便利だから」と入れてくる新しいAIツールの中身まで、限られた人員で追い切るのは容易ではありません。だからこそ、「何を入れてよいか」を入口で決める運用ルールと、許可リスト方式のほうが、出口で全部を検査しようとするより現実的だと感じます。新しい技術ほど、技術的検査の前に「導入の意思決定をどう統制するか」が効いてきます。
情シスはどうすべきか(公的指針への誘導)
個別の対策チェックリストを並べる前に、まずは公的機関が整理した生成AI利用の指針を社内ルールの土台にするのが近道です。IPA(情報処理推進機構)は、AI利用時の最低限かつ有効な対策をまとめた資料や、組織での導入・運用ガイドラインを公開しています。
- IPA「AI利用者のためのセキュリティ豆知識」:https://www.ipa.go.jp/digital/ai/security/ai_security_tips.html(利用者がまず押さえるべき要点)
- 総務省・経済産業省「AI事業者ガイドライン」(IPA掲載):開発者から利用者まで、立場ごとの責務を整理。社内規程づくりの参照に。
そのうえで、自社では「導入してよいAIスキル/拡張の判断基準」「外部通信や権限の確認」「利用者への啓発」を運用に落とし込むのが現実的です。技術的な検査に限界がある以上、地道なユーザー教育と、入口での意思決定の統制が引き続き効きます。
まとめ
- AIエージェントの「スキル」は説明文と実行コードの組み合わせであり、その食い違いを突くクロスモーダル攻撃を既存スキャナはほとんど検知できなかった(査読前の研究報告)。
- 外部由来のAIスキル/プラグインは、ライブラリと同じサプライチェーン上のリスクとして、配布元の信頼性と最小権限を前提に扱うべき。
- 自動検査だけに頼らず、導入の意思決定の統制とユーザー啓発を軸に、IPA等の公的指針を社内ルールの土台にするのが現実的。
出典
- Youngduk Kim, Minkyoo Song, Seungwon Shin. “SkillMutator: Benchmarking and Defending Language-and-Code Cross-modal Attacks on LLM Agent Skills.” arXiv:2606.14154(2026年6月投稿、査読前プレプリント)https://arxiv.org/abs/2606.14154
- IPA「AI利用者のためのセキュリティ豆知識」https://www.ipa.go.jp/digital/ai/security/ai_security_tips.html


コメント