Agent SkillsとMCPの信頼境界設計について、業務導入における統制設計の実装要件
1. はじめに：本稿の目的と対象読者
「Agent Skillsを業務プロダクトに導入してはいけない」という主張が話題になっている。この主張は一定の警鐘を鳴らすものだが、技術記事としては論理の飛躍がある。
本稿の目的は、形式論争（Skills vs MCP）を超えて、業務導入における技術的判断軸を提示することである。対象読者は、AIエージェントの業務導入を検討する開発者・アーキテクトである。
結論を先に述べる。危険なのは「Agent Skills」という形式ではなく、「統制不能な副作用実行器をLLMに直結する設計」である。これはSkillsでもMCPでも同様に発生しうる。ただし、両者には信頼境界（Trust Boundary）の設計しやすさにおいて技術的差異が存在する。
2. 用語と実行モデルの定義
議論の前提として、SkillsとMCPの技術的実体を定義する。
2.1 Agent Skillsとは何か
Agent Skillsは、LLMエージェントの能力を拡張するための動的プロンプト注入とコード実行の仕組みである。
| 要素 | 内容 |
|---|---|
| 定義ファイル | Markdown、YAML、またはスクリプト形式で記述 |
| 注入タイミング | 実行時にシステムプロンプトまたはコンテキストとして動的に追加 |
| 実行権限 | エージェントと同一プロセス、同一権限で実行されることが多い |
| 実行経路 | LLMの判断 → Skill選択 → 引数生成 → 直接実行 |
Skillsの特徴は、エージェント本体と同一の信頼境界内で動作することが多い点である。
2.2 MCPとは何か
MCP（Model Context Protocol）は、LLMエージェントと外部ツールをプロトコル経由で接続する仕組みである。
| 要素 | 内容 |
|---|---|
| 定義 | JSON-RPC 2.0ベースのプロトコル仕様 |
| サーバー分離 | MCPサーバーは別プロセスとして動作 |
| インターフェース | 事前定義されたスキーマに基づくツール呼び出し |
| 実行経路 | LLMの判断 → プロトコル経由でリクエスト → MCPサーバーで実行 → レスポンス返却 |
MCPの特徴は、プロセス分離により信頼境界を明確に設定できる点である。
2.3 両者の根本的違い：信頼境界の位置
┌─────────────────────────────────────────────────────────────┐
│ Agent Skills │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ LLM Agent │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Skill A │ │ Skill B │ │ Skill C │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ │ 同一プロセス・同一権限 │ │
│ └──────────────────────────────────────────────────────┘ │
│ 信頼境界が曖昧 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ MCP │
│ ┌────────────────┐ ┌────────────────────────┐ │
│ │ LLM Agent │ Protocol │ MCP Server │ │
│ │ │◄────────►│ ┌──────┐ ┌──────┐ │ │
│ │ │ │ │Tool A│ │Tool B│ │ │
│ └────────────────┘ │ └──────┘ └──────┘ │ │
│ └────────────────────────┘ │
│ ▲ ▲ │
│ └──────── 信頼境界 ─────────────┘ │
└─────────────────────────────────────────────────────────────┘
この差異が、以降で論じる「強制点の配置」「爆発半径」「監査可能性」に直結する。
3. 脅威モデル：何が、どう危険か
業務導入を検討する際、まず脅威モデルを明確にする必要がある。
3.1 攻撃者モデル
| 攻撃者タイプ | 説明 | 主な攻撃ベクトル |
|---|---|---|
| 外部攻撃者 | プロンプトインジェクション経由でエージェントを操作 | 悪意あるユーザー入力、汚染されたWebコンテンツ |
| 内部不正 | 正規ユーザーによる権限濫用 | 本来アクセス不可のデータへの誘導 |
| サプライチェーン | Skills/MCP定義ファイルの改ざん | 配布経路への攻撃、署名なし更新 |
3.2 保護対象資産
- 顧客データ（PII、決済情報）
- 認証情報（APIキー、トークン、資格情報）
- システム整合性（設定ファイル、実行環境）
- 監査証跡（ログの完全性）
3.3 侵入経路と爆発半径（Blast Radius）の差異
爆発半径とは、攻撃が成功した際に影響を受ける範囲のことである。
| 実装形態 | 爆発半径 | 理由 |
|---|---|---|
| Skills（分離なし） | 大 | エージェントと同一権限。ファイルシステム、環境変数、ネットワークに直接アクセス可能 |
| Skills（サンドボックス） | 中 | 実行環境は隔離されるが、設計次第で穴がある |
| MCP（プロセス分離） | 小〜中 | プロトコル経由のため、MCPサーバーの権限に制限される |
| MCP（コンテナ分離） | 最小 | 物理的隔離により爆発半径を限定 |
4. 比較軸：SkillsとMCPの技術的差異
「SkillsかMCPか」という形式ではなく、以下の比較軸で評価すべきである。
4.1 強制点（Enforcement Point）の配置
強制点とは、「LLMが何かをしたいと判断しても、システム側で拒否できる地点」である。
| 実装形態 | 強制点の有無 | 説明 |
|---|---|---|
| Skills（素朴な実装） | なし | LLMの判断がそのまま実行される |
| Skills（ポリシー層追加） | あり | 実行前にポリシー評価を挟む設計が必要 |
| MCP | 構造的にあり | プロトコル層でスキーマ検証、MCPサーバーで権限検証 |
Skillsで強制点を設けることは可能だが、設計者が意識して実装しなければ存在しない。MCPはプロトコル仕様として強制点が組み込まれている。
4.2 権限の最小化と分離可能性
| 実装形態 | 最小権限の実現 | 難易度 |
|---|---|---|
| Skills | エージェント全体の権限を絞る必要あり | 高 |
| MCP | 各MCPサーバーごとに権限を限定可能 | 中 |
Skillsで最小権限を実現するには、Skill Aが読み取り専用、Skill Bがネットワークアクセス可能、といった分離が難しい。同一プロセス内で動作するためである。
4.3 監査可能性と再現性
| 実装形態 | 監査可能性 | 再現性 |
|---|---|---|
| Skills | 実装依存（ログ設計が必要） | LLMの非決定性により困難 |
| MCP | プロトコルレベルでリクエスト/レスポンスを記録可能 | 入力固定なら再現可能 |
インシデント発生時、「何が起きたか」を確定するには、LLMの思考プロセスと実行されたシステムコールを紐付ける必要がある。MCPはプロトコル層で構造化されたログを取りやすい。
4.4 これは「程度の差」か「質的な壁」か
結論：「質的な壁」に近いが、超えられない壁ではない。
Skillsでも、以下を実装すればMCPに近い安全性を確保できる：
- 実行前のポリシー評価層
- サンドボックス化された実行環境
- 構造化されたログ出力
- 署名付きSkill配布
ただし、これらを実装するコストは、MCPを採用するコストを上回ることが多い。「Skillsでもできる」は正しいが、「Skillsでやるべきか」は別問題である。
5. 失敗パターン集：こうして破綻する
実際に発生しうる失敗パターンを具体的に示す。
5.1 権限昇格の連鎖
Skill A: ファイル読み取り（無害に見える）
Skill B: 設定ファイル編集（限定的に見える）
Skill C: 外部API呼び出し（便利）
攻撃シナリオ:
1. プロンプトインジェクションでSkill Aを誘導
2. 認証情報を含むファイルを読み取らせる
3. Skill Cで外部サーバーに送信
→ 個別のSkillは「安全」でも、組み合わせで権限昇格が発生
5.2 サプライチェーン汚染
1. 社内で共有されているSkillリポジトリ
2. 署名検証なし、レビューなしで更新可能
3. 悪意ある開発者（または侵害されたアカウント）がSkillを改ざん
4. 全エージェントが汚染されたSkillを実行
→ Skill配布経路がセキュリティホールになる
5.3 監査不能な非決定性
インシデント発生:「顧客データが外部に送信された」
調査:
- どのSkillが実行された？ → ログ不十分で不明
- どの入力が原因？ → LLMの非決定性で再現不可
- いつから発生していた？ → 特定不能
→ 責任追及も再発防止も不可能
5.4 「社内だから大丈夫」の罠
前提:「社内ツールなのでセキュリティは緩くてよい」
現実:
- 社内システムこそ横展開（Lateral Movement）の踏み台
- 社内ネットワークは外部より監視が甘いことが多い
- 「開発効率化のため」で導入したSkillsが本番環境に接続
- 内部不正のリスクは外部攻撃より検知困難
→ ゼロトラストの原則に反する
6. 業務導入の判断フレームワーク
6.1 導入可否を決める3つの問い
以下の問いに「Yes」と答えられない場合、導入は見送るべきである。
| 問い | 説明 | 検証方法 |
|---|---|---|
| ロールバック可能か？ | 非決定的な出力による副作用を、システム側で自動的に元に戻せるか | 破壊的操作のテスト実行とリカバリ訓練 |
| 強制点が存在するか？ | LLMが生成した命令を、実行前にポリシー照合できるか | アーキテクチャレビュー、ポリシー定義の存在確認 |
| 完全な監査証跡を残せるか？ | インシデント発生時、LLMの思考と実行を紐付けて追跡できるか | ログ設計レビュー、インシデント対応訓練 |
6.2 データ機微度×権限レベルのマトリクス
権限レベル
低 中 高
┌─────────┬─────────┬─────────┐
低 │ ✓ │ ✓ │ △ │
機微度 中 │ ✓ │ △ │ ✗ │
高 │ △ │ ✗ │ ✗ │
└─────────┴─────────┴─────────┘
✓ = 導入可（標準統制）
△ = 条件付き導入可（強化統制必須）
✗ = 導入不可（アーキテクチャ変更が必要）
6.3 導入NG条件の明確化
以下のいずれかに該当する場合、その形態での導入は不可である：
- Skills/MCPの配布経路に署名検証がない
- 実行時権限がエージェント全体で共有され、分離できない
- 監査ログが欠落しており、事後追跡が不可能
- 変更管理（レビュー・承認）なしにSkillsを追加できる
- ロールバック手順が存在しない
7. 統制設計の実装パターン
7.1 実行と認可の分離
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ LLM Agent │────►│ Policy Layer │────►│ Executor │
│ （提案生成） │ │ （認可判定） │ │ （実行） │
└──────────────┘ └──────────────┘ └──────────────┘
│
▼
ポリシー定義
（Allow/Denyリスト）
LLMは「何をしたいか」を提案するだけ。実際の実行は、ポリシー層での認可を経てから行う。
7.2 ランタイム隔離
| 技術 | 隔離レベル | 適用場面 |
|---|---|---|
| Deno/Node.js permission flags | プロセス内 | 軽量なスクリプト実行 |
| gVisor | コンテナレベル | Skill実行環境の隔離 |
| Firecracker | microVM | 高セキュリティ環境 |
| WASM | サンドボックス | ポータブルな隔離実行 |
7.3 許可リスト方式とポリシー評価点
# policy.yaml
allowed_operations:
- type: file_read
paths:
- "/data/public/**"
deny:
- "**/.env"
- "**/credentials*"
- type: http_request
domains:
- "api.internal.example.com"
methods:
- GET
denied_operations:
- type: file_write
- type: shell_execute
- type: network_listen
7.4 段階的導入とロールバック設計
Phase 1: 読み取り専用Skills
- 情報取得のみ
- 副作用なし
- 監査ログ確認
Phase 2: 限定的な書き込み
- 下書き作成、一時ファイル
- 人間の承認後に確定
- ロールバック訓練
Phase 3: 自動実行
- 定義済みワークフローのみ
- 異常検知アラート
- 自動停止機構
各Phaseで問題発生時:
→ 前Phaseにロールバック
→ 原因分析
→ 対策実装後に再試行
8. まとめ：エンジニアが持つべき判断軸
「SkillsかMCPか」ではなく「信頼境界をどこに置くか」
元記事の「Agent Skillsを業務プロダクトに導入してはいけない」という主張は、警鐘としては有効だが、技術記事としては粗雑である。
正しい問いは：
「LLMという非決定的なシステムに、どこまでの権限を、どのような統制のもとで委譲するか」
この問いに対する答えは、SkillsかMCPかという形式ではなく、信頼境界の設計で決まる。
統制不能な副作用実行器をLLMに直結しない
以下の設計原則を守れば、SkillsでもMCPでも業務導入は可能である：
- 強制点を設ける: LLMの判断と実行の間にポリシー評価層を挟む
- 権限を最小化する: 各ツール/Skillに必要最小限の権限のみ付与
- 実行を隔離する: サンドボックス、コンテナ、別プロセスで爆発半径を限定
- 監査を完備する: 全ての実行を追跡可能な形でログ出力
- ロールバックを担保する: 失敗時に元に戻せる設計
コストとリスクの等価交換を厳密に評価せよ
最終的な判断は、以下のトレードオフである：
| 選択肢 | メリット | コスト |
|---|---|---|
| Skills（統制設計あり） | 柔軟性、開発速度 | 統制設計・実装・運用の負担 |
| MCP | 構造的な安全性、標準化 | プロトコル学習、サーバー実装 |
| Skills禁止 | リスク回避 | 開発効率の低下、機会損失 |
「Skillsだからダメ」でも「MCPなら安心」でもない。自組織の技術力、運用体制、リスク許容度に応じて、適切な統制レベルを設計せよ。
Discussion