概要
https://zenn.dev/ncdc/articles/206fbad44d1dba
詳細内容
## Agent Skillsを業務プロダクトに導入してはいけない
https://zenn.dev/ncdc/articles/206fbad44d1dba
Agent Skillsの業務プロダクトへの安易な導入が、プロンプトインジェクションによる壊滅的なセキュリティリスクを招くことを具体例とともに警告する。
**Content Type**: 💭 Opinion & Commentary
**Language**: ja
**Scores**: Signal:4/5 | Depth:4/5 | Unique:4/5 | Practical:4/5 | Anti-Hype:5/5
**Main Journal**: 84/100 | **Annex Potential**: 85/100 | **Overall**: 84/100
**Topics**: [[Agent Skills, プロンプトインジェクション, MCP, セキュリティ, AIエージェント]]
Claude Codeの登場などで急速に注目を集める「Agent Skills」だが、著者はその業務プロダクトへの導入に対し、エンジニアが陥りやすいセキュリティ上の盲点を指摘している。著者が開発環境で実験したところ、Agent Skillsを組み込んだエージェントに対し、プロンプトインジェクション（PI）を仕掛けることで開発環境を破壊することに成功したという。この実体験に基づき、安易な機能統合が致命的なセキュリティホールになり得ると警鐘を鳴らしている。
著者が主張する最大のリスクは、Agent Skillsの本質が「実行時にLLMへ動的に注入されるプロンプト」である点だ。エージェントを有効活用するためには、ファイル操作や外部API連携といった強力な実行権限が必要となる。しかし、Agent Skillsはシステムプロンプトとして扱われるため、LLM内部ではユーザーからの指示とシステム側の命令を本質的に区別できない。結果として、悪意あるユーザーがプロンプトを通じてエージェントの権限を乗っ取り、重要データの閲覧・変更・削除を強行することが容易になる。著者はこれを、動的な依存性注入（DI）になぞらえ、動的なプロンプト注入（PI）がもたらす「権限と指示の混濁」と定義している。
また、既存のFunction Calling（Tool）やMCP（Model Context Protocol）との決定的な違いについても深く考察されている。MCPは実行主体がMCPサーバー側にあり、エージェントはあくまでクライアントとして構造化されたプロトコルで通信する。このため「指示」と「実行」の境界が明示的であり、入力検証が可能だ。対してAgent Skillsは実行主体がエージェント自身であり、境界が暗黙的であるため権限分離が極めて困難である。著者は、Skillsに強い制限をかけて安全性を確保しようとするくらいなら、最初から特定の操作のみを許可するToolやMCPを導入するほうが、アーキテクチャとしてシンプルかつ堅牢であると述べている。
さらに、解決策として挙げられがちな「Human-in-the-loop（人間の承認）」についても、攻撃者がユーザー自身である場合には承認プロセス自体が形骸化するため無意味であると断じている。結論として、Agent Skillsは現状、高度な知識を持つユーザーがサンドボックス環境で利用する「開発用ツール」としての域を出ていない。一般ユーザー向けの業務プロダクトに組み込むには時期尚早であり、エンジニアはトレンドの利便性よりも、実行権限の適切な分離と設計という基本に立ち返るべきであるというのが著者の主要なメッセージである。