🔧 Skillとは？
AIエージェントの文脈では、 skill (別名 tool or function) はパッケージ化された再利用可能な機能であり、LLMがコンテキストウィンドウの外の世界とやり取りするために呼び出せるものです。Skillsは言語理解と現実世界のアクションのギャップを橋渡しします。
すべてのskillには四つの構成要素があります：
- Name — モデルがskillを参照するために使用する一意の識別子（例：
web_search) - Description — skillが何をするか、いつ使うかを説明する自然言語のテキスト； LLMはこれを読み、いつskillを呼び出すかを決定します
- 入力スキーマ — 引数の構造定義（JSON Schema）；モデルはタスクに基づいてこれらを埋めます
- Implementation — 実際に動作するコード：API呼び出し、データベースクエリ、シェルコマンド、またはその他の操作
例： A get_weather skillの説明が「都市の現在の天気を取得する」となっており、 次の入力を受け取り、 { "city": "string" } を入力として受け取り、天気APIを呼び出します。LLMはAPIキーやHTTP呼び出しを直接見ることはなく、結果をテキストとして受け取るだけです。
⚙️ ツール呼び出しの仕組み
エージェントがskillsにアクセスできる場合、LLMはそれらを直接呼び出すのではなく、 requests 構造化された出力を生成することによって呼び出しを行います。ランタイム（あなたのアプリケーションコード）が実際の呼び出しを実行し、結果を返します。フルサイクルは次の通りです：
- ツール登録 — あなたのコードは、利用可能なskillsのリストとその説明およびスキーマをモデルに送ります
- モデルの推論 — LLMはタスクと利用可能なツールを読み、どのツールをどの引数で呼び出すかを決定します
- ツール呼び出しリクエスト — モデルは構造化された「tool call」メッセージを出力します（例：
{ "tool": "web_search", "args": { "query": "current Gemini models" } }) - Execution — あなたのランタイムコードが実際の関数、API、またはサービスを呼び出します
- 結果注入（Result injection） — 結果が会話のコンテキストに追加されます
- 推論の継続 — モデルは結果を読み、別のツールを呼ぶか、フォローアップを尋ねるか、最終回答を生成します
このループは1ターンの中で何度も繰り返される可能性があります。複雑なエージェンティックなタスクでは、最終的な応答を生成する前に10〜20のツールを順に呼び出すことがあります。
📊 Skills vs Plugins vs MCP Servers
用語は急速に進化しました。概念が歴史的にどのように関連しているかは次の通りです：
| Era | Name | これがどのように機能したか | Status |
|---|---|---|---|
| 2023 | ChatGPT Plugins | OpenAPI仕様を持つユーザーインストール可能な拡張；ChatGPTはHTTP経由でそれらを呼び出しました | 非推奨（GPTs + toolsに置き換えられました） |
| 2023 | OpenAI Function Calling | APIレベルのJSON Schema定義；モデルは構造化された関数呼び出しを出力し、あなたのコードがそれを実行します | アクティブ — 名前が「tool use」に変更された |
| 2023– | Tool Use / Skills | 関数呼び出しと同じです；Anthropicは「tool use」と名付け、他は「skills」または「functions」と呼びます | アクティブ — 現在の標準 |
| 2024– | MCP Servers | 標準化されたプロトコル（Anthropic, 2024年12月）で、toolサーバーをパッケージ化して配布するためのもの；任意のMCPクライアントが任意のMCPサーバーに接続できます | アクティブ — 成長中のエコシステム |
重要な区別： 従来のtool useはあなたのアプリケーションコード内でインライン定義されます。 MCPサーバーはツールを標準化されたプロトコルで公開する独立プロセスであり、これによりそれらは異なるAIクライアント（Claude Desktop、Cursor、VS Code、カスタムエージェント）間で再利用可能になります。 詳細： What Is MCP.
🗂️ ツールカテゴリとリスクレベル
すべてのツールが同じリスクを伴うわけではありません。リスクレベルごとに分類することで、エージェントの アクション空間 および人間の介入ポイントを追加する場所：
| Category | Examples | Risk | Recommendation |
|---|---|---|---|
| Read-only | web_search, read_file, get_weather, list_dir | Low | 自律的に許可する；すべての呼び出しをログに記録する |
| Write (local) | write_file, create_dir, edit_code | Medium | サンドボックス化されたワークスペースディレクトリに限定する |
| Network / External | send_email, post_to_slack, call_api | 中〜高 | 取り消せない送信についてはHITL承認 |
| OS / Shell | run_command, execute_script, install_package | High | コンテナ化された環境に制限する；HITLが必要 |
| Destructive | delete_file, drop_table, revoke_access | Critical | 常に明確な人間の確認を要求する |
🏗️ 良いSkillの構成要素
skill設計で最も重要な決定はその description. LLMは説明を読み、どのツールを呼び出すかを決定します — 不適切に書かれた説明は間違ったツール選択、呼び出しの見落とし、またはあいまいな引数につながります。
説明を効果的にする要素
- いつ使うかを明確にすること — 「ユーザーがリアルタイムデータや現在のイベントについて尋ねたときにこのツールを使用する」は「ウェブを検索します」よりも優れています
- 何をしないかを明記すること — 「30日より古い履歴データは返しません」
- 出力フォーマットを記述すること — 「title, url, snippetフィールドを持つ検索結果のJSON配列を返します」
- 200単語以内に収めること — 約200トークンを超える説明は、多くのツールが登録されているときにモデルの注意を圧倒する可能性があります
スキーマ設計の原則
- 必須 vs 任意 — 真に必要な場合にのみフィールドを必須にしてください；デフォルトを持つ任意フィールドはモデルのエラーを減らします
- 制約された値にはenumを使用すること —
"format": {"enum": ["json", "markdown", "text"]}は誤生成された値を防ぎます - 冪等なツールを優先すること — 安全にリトライできるツール（読み取り、ルックアップ）は、ワンショットのアクション（送信、削除）よりも安全です
- 構造化データを返すこと — JSON応答は、モデルが非構造化のテキストよりも推論しやすいです
💡 実世界の例
| Skill名 | 何をするか | 主要な引数 | Risk |
|---|---|---|---|
web_search | 検索エンジンをクエリして上位の結果を返す | query: string, num_results?: number | Low |
read_file | ワークスペースディレクトリからファイルを読み取る | path: string, offset?: number, limit?: number | Low |
write_file | ファイルを作成または上書きする | path: string, content: string | Medium |
run_tests | プロジェクトのテストスイートを実行し、結果を返す | filter?: string | Medium |
browser_screenshot | URLに移動してスクリーンショットを返す | url: string | Medium |
send_email | 1人以上の受信者にメールを送信する | to: string[], subject: string, body: string | 高 — 常にHITL |
run_shell | 任意のシェルコマンドを実行する | command: string, cwd?: string | 高 — サンドボックスが必要 |
✅ ベストプラクティス
最小権限
各エージェントには、その特定タスクに必要なツールのみを付与してください。FAQ応答するエージェントは write_file or send_email. アクション空間が小さいほど、エージェントが操作された場合の被害範囲は小さくなります。参照： 過剰なエージェンシー.
すべてのツール呼び出しを監査する
すべてのツール呼び出しとその引数および結果をログに残してください。これによりデバッグ、コスト帰属、異常な振る舞い（例：エージェントが ~/.ssh/ プロジェクトディレクトリのみにアクセスすべきところでアクセスしてしまう）を検出できます。LangSmithのようなAgentOpsプラットフォームはこれを簡単にします。
取り消せないアクションに対する人間の介入（HITL）
元に戻すことが難しい、または不可能なアクション（メッセージ送信、データ削除、購入など）は、実行前に明確な人間の確認を必要とするべきです。HITLチェックポイントをプロンプトだけでなくエージェントのランタイムに組み込んでください。プロンプトは上書きされる可能性がありますが、コードはそうではありません。
ツールのポイズニングに注意すること
エージェントがMCPサーバーを動的にインストールまたは発見できるようにすると、悪意あるサーバーが隠れた指示を含む説明でツールを登録することができます。ツールをエージェントのレジストリに追加する前に、常にツールの説明をレビューしてください。参照： ツールポイズニング（Tool Poisoning）.
明確なエラー返却を書くこと
ツールが失敗した場合、モデルが回復またはエスカレーションできる十分なコンテキストを持つ構造化されたエラーを返してください — 生の例外スタックトレースは避けてください。例： { "error": "rate_limited", "retry_after": 5 }. よく記述されたエラーは、エージェントがリトライしたり、フォールバックツールを使用したり、ユーザーに優雅に知らせたりすることを可能にします。