エージェントスキルとMCPサーバー：意思決定フレームワーク

エージェントスキルとMCPサーバーは、AIエージェントを拡張する競合する2つの方法として提示されることがあります。この捉え方は誤りです：スキルはエージェントに作業方法を教え、MCPサーバーはライブ機能への管理されたアクセスを提供します。

有用な質問は「どちらの標準が勝つか？」ではなく、「この責任はどこに置くべきか？」です。このガイドは、コンテキストサイズ、長時間接続、認証情報、運用安全性が整ったデモよりも重要になるHermes AgentやOpenClawのようなホスト型アシスタント向けにその答えを提供します。

これは学術的な比較ではなく、両方のメカニズムの実際のデプロイ経験から構築された実践的な意思決定フレームワークです。エージェントが本番環境で動作し始めた後にのみ明らかになるコンテキストコストのトレードオフも含みます。マルチエージェントシステムを構築している場合は、同じ問題領域の別の軸をカバーするA2A vs MCPプロトコル比較も読むことをお勧めします。

エージェントスキルとMCPサーバーの比較表

手順、判断力、再利用可能な運用知識にはスキルを使用します。権威ある状態、保護された操作、安定した能力契約にはMCPサーバーを使用します。

私のデフォルトは意図的に保守的です：作業がローカルで、読み取り重視、手順的な場合はスキルから始めます。エージェントが信頼境界を越えたり、変化する外部状態に接触したり、モデルが混乱しても正しいままであるべき操作が必要な場合はMCPサーバーを追加します。

核心的な違い：手順と能力

エージェントスキルはSKILL.mdを中心としたディレクトリで、オプションのスクリプト、参照、アセットを含みます。Agent Skills仕様は必須メタデータとプログレッシブディスクロージャーモデルを定義しています：ホストは小さな名前と説明を最初に発見し、関連するときに完全な指示を読み込み、必要な場合にのみサポートファイルをフェッチできます。

このため、スキルはインシデント基準、リリースチェックリスト、研究方法、既存のコマンドラインツールの使用方法の指示に優れた場となります。その中心的な価値はエンコードされた手順です：シーケンス、判断力、制約、例、良い結果の定義。Hermes固有の著者詳細、フロントマター構造、条件付きアクティベーションについてはHermes Agent Skill Authoringを参照してください。

MCPは異なる問題を解決します。Model Context Protocol仕様はクライアントとサーバーにJSON-RPCベースの契約を提供し、ツール、リソース、プロンプトを含む能力、標準的なトランスポートと発見動作を可能にします。MCPサーバー in PythonやMCPサーバー in Goの実用的な実装ガイドは、プロトコルが重い作業を処理した後、統合レイヤーがいかに簡単になるかを示しています。

したがってMCPサーバーは、チケットシステム、クラウドコントロールプレーン、ソースオブトゥースデータベース、内部検索サービスなどの境界として適しています。そのシステムへの到達のメカニズムを所有し、モデルの文章指示の外で検証、認可、タイムアウト、レート制限、監査動作を強制できます。

より正確なルール

責任がモデルが指示を覚えていなくても正しいままである必要があるかどうかを尋ねてください。答えがyesの場合は、それは決定論的なコードまたはサーバーポリシーに属し、SKILL.mdだけでなくそこに置くべきです。

例えば、「エスカレーション前に3つのサポートシグナルを集める」は有用なスキル指示ですが、「呼び出し元にインシデントマネージャーの範囲がない限りステータス変更を拒否する」は、スキルがルールを繰り返しても、サービスまたはMCPサーバーによって強制されるべきです。

これが重要な境界です：

• スキルはエージェントにアクションが適切なタイミングを伝えられます。
• MCPツールは型付きインターフェースを通じてアクションを可能にできます。
• バッキングサービスはアクションが実際に許可されているかどうかを決定する必要があります。

MCPサーバーはプロンプトも公開できるため、標準は境界で重複します。それでも、巨大なツール説明に完全な運用手順を置くことは通常脆い能力カタログを生み出し、スキル内のシェルスクリプトに隠れた特権APIクライアントを置くことは通常避けるべきセキュリティ問題を生み出します。

SKILL.mdが十分な場合

エージェントが必要なすべてに安全なアクセスを持っており、欠けている要素がノウハウである場合にスキルは十分です。リポジトリ分析、ドキュメント変換、レポート生成、成熟したCLIコマンドに基づくローカルワークフローでは一般的です。

データがローカルまたはユーザーによって提供されている場合

エージェントをチェックアウトされたリポジトリを検査し、読み取り専用のリンターを実行し、設定ファイルを比較し、移行レポートを作成する必要があると仮定します。ファイルはすでに作業環境にあり、ホストはすでにファイルシステムとプロセスツールを公開しているので、別のネットワークサービスはほとんど価値を追加しません。

スキルはどのファイルを検査するか、コマンド順序、失敗処理、必要な証拠を説明できます。バンドルされたスクリプトは出力を正規化できますが、ホストの既存のサンドボックスとコマンド権限が実際の実行境界のままです。

ワークフローが判断力に依存する場合

スキルは技術的に有効なアクションが複数存在するが、組織が1つの運用方法を好む場合に特に有用です。コードレビュースキルはどのリスクがブロッキングコメントを必要とするか、いつ再現を要求するか、正確性の問題と好み問題をどのように分離するかを説明できます。

これらのルールはチームが学ぶにつれて変化します。それらをバージョン管理された文章と小さな参照として保持することは、すべての編集調整のためにサーバーを再コンパイルまたは再デプロイするよりも明確な場合が多いです。

ポータビリティが中央制御よりも重要である場合

オープンなAgent Skillsフォーマットはリモートランタイムではなくポータブルフォルダとして設計されています。適切に範囲設定されたスキルは、その指示、例、サポートアセットを保持したまま互換性のあるホスト間で移動できますが、ツール名とサンドボックス動作はまだホスト固有のテストを必要とします。

このポータビリティは、方法を共有するが必ずしも同じデプロイメントではないHermes AgentやOpenClawワークフローに有用です。最初の違いでコア手順をフォークするのではなく、ホスト固有の注記を短い参照に保持してください。OpenClawスキルエコシステムガイドはどのスキルがインストール価値があり、エージェントロールごとに安全にゲートする方法をカバーしています。

既存のCLIがすでに能力を提供している場合

信頼できるローカルコマンドをラップするためにサーバーを構築しないでください。シングルユーザーアシスタントがすでに認証、構造化出力、エラーを処理する狭いCLIを呼び出せる場合、スキルはより小さく保守しやすいソリューションかもしれません。

注意点として重要なことは：CLIはローカルだからといって自動的に安全ではありません。広範なシェルインターポレーションを避け、構造化出力を優先し、書き込み可能なターゲットを制限し、スキルの提案ツール許可リストを完全な認可システムとして扱わないでください。

MCPサーバーが必要な場合

問題が単に何をするか覚えることではない場合にMCPを選択します。エージェントが持続的、型付き、管理可能な変更システムへのブリッジを必要とするときにMCPサーバーは価値を持ちます。

状態がライブで権威ある場合

顧客チケット、デプロイメントステータス、在庫、請求記録、本番メトリクスは2つのモデルターン間で変化できます。その状態をスキルにコピーすることは設計上陳腐にし、モデルにインターフェースをスクレイプさせることは不安定な契約を生み出します。

MCPリソースまたはツールは実行時に現在のレコードを取得できます。サーバーはアップストリームの癖を正規化し、ベンダー応答全体をモデルに公開する代わりにコンパクトな結果を返すことができます。

認証情報やユーザーIDが関与する場合

認証情報はSKILL.md、例、バンドルされたヘルパースクリプトに置くべきではありません。リモートHTTPデプロイメントの場合、MCP認可仕様はOAuthベースのモデルを定義し、ローカルstdioサーバーの場合、認証情報はプロセス環境または別のホスト制御メカニズムを通じて提供できます。公式のMCP認可ガイドを参照してください。

サーバーを使用するより深い理由は秘密ストレージだけではありません。サーバーはIDを範囲にマッピングし、テナントを制限し、フィールドを隠蔽し、誰がミューテーションを要求したかを記録できますが、文章指示はモデルに振る舞いを求めるだけです。

ライトが必要なトランザクション保証の場合

請求書作成、チケットステータス変更、デプロイメント開始は、可能性のあるJSONオブジェクトよりも多くを必要とします。操作には冪等性キー、楽観的並行処理、サーバーサイド検証、持続的な監査記録が必要かもしれません。

これらの特性はモデルの下に属します。スキルは承認ポリシーを定義できますが、MCPサーバーは無効なトランジションを拒否し、再試行リクエストを安全にするべきです。

複数のエージェントが同じ能力を必要とする場合

共有MCPサーバーは複数のエージェントホスト、言語、モデルプロバイダーに1つの契約を提供できます。これはプラットフォームチームにスキーマの改善、アップストリームAPI動作のパッチ、統合ロジックを各スキルにコピーせずにアクセス制御の適用を可能にする中央場所を与えます。

中央化は無料ではありません。サーバーはバージョン管理、可観測性、可用性、インシデントレスポンス義務を持つ運用依存関係になり、アーキテクチャの熱意ではなく実際の境界でその存在を正当化するべきです。

コンテキストコストの問題

コンテキストコストは頻繁に「スキルはプログレッシブ、ツールは常にロードされる」というスローガンに還元されます。実際のホストはより微妙で、違いは拡張フォーマットから想定するのではなくシリアライズされたモデル入力として測定されるべきです。

Agent Skillsドキュメントはスキルごとに約100トークンの発見メタデータを説明し、アクティベートされた指示を5,000トークン以下に保つことを推奨し、参照をオンデマンドでロードすることを許可します。単純な計画見積もりは：

C_skill = discovery metadata + activated instructions + selected references

MCPクライアントはサーバーからツール定義を発見しますが、プロトコルはすべての発見されたスキーマがすべてのモデル呼び出しに出現することを要求しません。ホストはツールをフィルタリング、延期、キャッシュ、ルーティングできるので、実用的な見積もりは：

C_mcp = tool schemas exposed to this turn + tool results retained in context

MCPツール仕様はまた、安定したツール順序がプロンプトキャッシュ動作を改善できることに注意しています。キャッシュは繰り返し処理コストを減らす可能性がありますが、過剰なカタログをモデルにとって選択しやすくするわけではありません。

例示的なトークン予算

インストールされた20のスキルを持つホスト型アシスタントを検討してください。Agent Skillsドキュメントの近似発見コストで、コンパクトなスキルインデックスは約2,000トークンです；焦点の絞られたトリアージスキルをアクティベートするとさらに1,200トークンと1つの600トークンの参照が追加されるかもしれません。

次に2つのMCP設計を比較します。4つの簡潔なスキーマを持つ薄いチケットサーバーは500-800トークンにシリアライズする可能性がありますが、35の冗長なツールを持つ広範なエンタープライズサーバーは結果が届く前に数千トークンを消費する可能性があります。

これらは例示的な計画数値であり、プロトコル保証やベンチマークではありません。スキーマの冗長さ、説明、ルーティング、結果保持、トークナイザー選択が合計を大幅に変える可能性があるため、ホストによって生成される正確なプロンプトを測定してください。

実用的な結論は「スキルは安価」または「MCPは高価」ではありません。プログレッシブディスクロージャーと能力選択はアーキテクチャ機能です：スキルメタデータを識別的に保ち、関連する指示のみをアクティベートし、最小限の有用なツールセットを公開し、生データではなく投影を返してください。

薄いサーバーパターン：MCPを下に、スキルを上に

最も耐久性のある設計はしばしば両方のメカニズムを組み合わせます。小さな能力境界をMCPに置き、それを呼び出すスキルに運用方法を置きます。

Hermes AgentまたはOpenClawのいずれからでも使用されるサポートインシデントワークフローを検討してください。エージェントはチケットを読み、証拠を集め、重大度を分類し、オペレーターノートを草案し、必要な承認後にのみステータスを変更する必要があります。

MCPサーバーが所有するもの

サーバーインターフェースを狭く、文字通り保ってください：

サーバーは段落長の説明と一握りの無関係なフラグを持つtriage_everythingというツールを含むべきではありません。4つの境界操作は認可、テスト、観察、再利用が容易です。

スキルが所有するもの

スキルはシーケンスと判断力を所有します。コンパクトなSKILL.mdはこのようになります：

---
name: incident-triage
description: Triage support incidents using ticket evidence and the severity rubric.
---

1. Read the ticket and its current version.
2. Collect at least two independent signals before assigning severity.
3. Separate observed facts from hypotheses in the note.
4. Ask for operator approval before any customer-visible note or status change.
5. Re-read the ticket before a write; stop if its version changed.
6. End with severity, evidence, uncertainty, and recommended next action.

このファイルは読みやすく、レビュー可能で、トリアージポリシーが変更されたときに容易に改訂できます。リンクされた参照は重大度基準を保持でき、メイン指示はオペレーションハンドブックを各ターンに引きずり込むことなくアクティベートできる十分な短さを保てます。

Hermes Agentでの実行方法

Hermes AgentのネイティブMCPドキュメントは起動時の発見、永続接続、stdioとStreamable HTTPトランスポート、名前空間付きMCPツールを説明しています。その現在の構成はまたstdioサーバーのために環境をフィルタリングし、明示的に設定された変数を渡すので、意図しない秘密継承に対する有用な防御となります。

この設計では、Hermesは4つのチケットツールを発見し、インシデントスキルは関連するリクエストのみにアクティベートされます。モデルはスキルに従い、MCPサーバーは境界操作を実行し、チケットサービスが最終的な権威のままです。

OpenClawでの実行方法

OpenClawのスキルドキュメントはAgent Skills構造に従い、モデルのために適格スキルのコンパクトなリストを構築します。同じインシデントフォルダはコア手順を保持でき、利用可能なチケットツール名を説明する短いホスト固有の参照を持ちます。

チケットトークンを共有スキルに置かないでください。OpenClawは明示的に共有スキルを秘密ストレージではなく入力として扱い、サードパーティスキルは有効にする前に信頼できないコードとしてレビューされるべきです。

なぜ分割が変化に耐えるか

サポートチームが重大度基準を改訂したら、スキルを更新します。チケットベンダーが認証またはページネーションを変えたら、運用ポリシーを書き直さずにMCPサーバーを更新します。

2番目のエージェントホストが届いたら、同じMCP契約を再利用し、スキルの小さなホスト固有レイヤーに適応できます。この分離は、各手順編集をサービスデプロイメントに変えることなく重複した統合ロジックを減らします。

5ステップの意思決定フレームワーク

以下のシーケンスは、最先端の拡張タイプを最初に選ぶよりも信頼性があります。

1. トゥースの源を特定する

ワークフローが接触するすべての入力と出力を書き出してください。静的なガイド、リポジトリファイル、ユーザー提供ドキュメントはスキルに傾き、変更可能なリモートレコードと権威あるシステムはMCPに傾きます。

すべての状態がサーバーを正当化するわけではありません。ローカルビルドアティファクトは状態ですが、既存のサンドボックス付きCLIはすでに十分な境界を提供しているかもしれません。

2. 信頼境界を見つける

認証情報、テナントID、特権データ、不可逆的なアクションが現れる場所をマークしてください。エージェントがその線を越える場合、決定論的な強制ポイント、通常はサービス認可によってサポートされるMCPサーバーを導入してください。

モデルとスキルをリクエストプランナーとして扱い、ポリシーエンジンとして扱わないでください。許可されたアクションを提案できますが、自分の指示を変更して権限を再定義できるべきではありません。

3. 能力とポリシーを分離する

型付き入力を持つ狭い動詞として能力を命名してください：チケットを取得、ノートを追加、ステータスを変更。それらの動詞を選択する条件、証拠基準、優先シーケンスをスキルに置きます。

いくつかのポリシーは異なる理由で両方のレイヤーに存在する必要があります。「デプロイ前にユーザーに尋ねる」は相互作用品質のためにスキルに属し、「承認トークンなしでデプロイを拒否する」は強制のためにコードに属します。

4. コンテキストと運用コストを見積もる

実際のプロンプトトレースを取得し、スキルメタデータ、アクティベートされた指示、ツール定義、返されたデータをカウントしてください。次にMCPサービスの非トークンコストを追加：デプロイメント、認証、モニタリング、バージョン管理、オンコール所有権。

30ツールのカタログが1つのワークフローをサポートする場合、タスク固有のサブセットを公開するか、一貫した能力ドメインによってサーバーを分割してください。スキルが繰り返し200ページの参照をロードする場合、自己称賛ではなく取得ステップまたは小さな参照を作成してください。

5. まず境界をテストし、次に動作をテストする

MCPサーバーをソフトウェアとして、スキルをエージェント動作としてテストしてください。それらは異なる方法で失敗し、単一のハッピーパスチャットトランスクリプトは両方の欠陥クラスを隠します。

ツール安全性のために、MCP仕様は入力検証、アクセス制御、レート制限、出力サニタイズ、タイムアウト、敏感操作の確認、監査ログを推奨しています。ツール注釈はヒントであり、操作が読み取り専用または無害であることの信頼できる証拠ではありません。A2AとMCPエージェントセキュリティガイドはプロンプトインジェクションとツールポイズニングを含むより広範な脅威モデルをカバーしています。

スローガンには収まらないセキュリティルール

スキルは一部のサーバーの必要性を減らしますが、リスクを除去しません。スキルはスクリプトを含み、エージェントに強力なホストツールを呼び出すように説得できるので、その指示と実行可能ファイルをコードとしてレビューし、信頼できるバージョンをピン留めし、セッションに利用可能なホストツールを制限してください。

MCPは別の境界を追加します：独自の依存関係、入力、出力、認証情報を持つローカルサブプロセスまたはリモートサービスです。最小特権を適用し、リモート認可のためにリソースオーディエンスを検証し、HTTPSを使用し、信頼できないコンテンツをサニタイズし、重要な書き込みのために承認を可視化してください。

最も重要なのは、発見可能性と権威を混同しないでください。ツールのカタログに出現することは、現在のユーザーがその説明するすべての操作を実行するべきであることを意味しません。

一般的なアンチパターン

スキル内にリモートAPIクライアントを隠す

静的ベアラートークンを読み取り本番APIを呼び出すシェルスクリプトはデモで動作するかもしれません。それはまた手順、認証情報、ネットワーク動作、認可をエージェントホストによってコピーされ読むことを設計されたパッケージに混在させます。

保護された統合を狭いサーバーまたは既存の承認済みCLIの背後に移動してください。スキルにはワークフローと呼び出しガイドのみを保持してください。

ワークフローをツール説明にエンコードする

ツール説明はモデルに能力を選択し、そのスキーマを埋めるのを助けるべきです。例、例外、エスカレーションルール、出力慣習を持つマルチステップ運用手順の悪い代替品です。

長い説明はツールが公開されるすべてのターンを膨張させ、サービス契約を再利用しにくくします。手順をスキルに置き、ツールセマンティクスを精密に保ってください。

execute_anythingツールを構築する

一般的なシェル、SQL、HTTPプロキシは多くの権限を1つの監査困難な能力に圧縮します。それは検証をモデルに移し、最小特権をほとんど架空にします。

実際のビジネスアクションと一致する操作を公開してください。専門オペレーターが本当にエスケープハッチを必要とする場合、それを分離し、制限し、より強い承認とログを要求してください。

キッチンシンクMCPサーバーを公開する

数十の無関係なツールを持つサーバーは選択、スキーマコンテキスト、権限、保守に負担をかけます。一貫したドメインによって分割するか、ホストが現在のタスクのために関連サブセットを公開させるべきです。

Hermes AgentのFastMCPガイドラインは健全な開始推奨を提供します：1-3の高価値エンドポイントから始め、明確な名前とスキーマを持つ薄いサーバーを優先してください。公式のFastMCPスキルドキュメントを参照してください。

ツールヒントをセキュリティポリシーとして扱う

実験的なallowed-toolsフィールドやツールの読み取り専用注釈はホスト動作を改善できますが、どちらもサンドボックスとサーバーサイド認可を置き換えるものではありません。メタデータは陳腐化、誤設定、または信頼できないコンポーネントによって提供される可能性があります。

ヒントを使用してインターフェースを改善してください。境界を強制するためにコードとインフラを使用してください。

静的知識のためにMCPを使用する

手順や参照がリポジトリとともにのみ変化する場合、リモートラウンドトリップは情報がより権威あるものにすることなくデプロイメントと可用性コストを追加します。簡潔な材料をスキルとパッケージ化し、ワークフローとともにバージョン管理してください。

コーパスが大きく、アクセス制御され、独立して更新され、本当に検索を必要とする場合にのみ取得サービスを導入してください。アーキテクチャはアクロニムではなくデータライフサイクルに従うべきです。

最終決定：スキル、MCPサーバー、それとも両方？

難しい部分が何をすべきかを知ることである場合はエージェントスキルを選択してください。難しい部分が安全に変更されるもの、別の信頼ドメインに属するもの、または契約を強制する必要があるものに到達することである場合はMCPサーバーを選択してください。

実際のワークフローが保護された能力の上に判断力を必要とする場合は両方を選択してください。それは重複ではありません：スキルはエージェントを有用にし、サーバーは統合を管理可能にし、バッキングシステムは最終的な決定を権威あるものにします。

ほとんどのホスト型アシスタントにとって、最善の最初のアーキテクチャは控えめです：1つの焦点スキル、ライブアクセスが必要な場所にのみ小さなMCP表面、コンテキストコストを検証するためのキャプチャされたプロンプトトレース。境界が明確になる前に、その後で複雑さを追加してください。

参考文献

• Agent Skills仕様
• Model Context Protocol仕様
• MCP認可ガイド
• Hermes AgentネイティブMCPドキュメント
• OpenClawスキルドキュメント
• FastMCPスキルドキュメント