エージェントスキル
エージェントがモノリシックなプロンプト・ツールシステムからモジュール型アーキテクチャへ進化するにつれて、重要な設計課題が浮かび上がります。エージェントの能力をどのように整理し、発見し、組み合わせるべきでしょうか。 その答えは、再訓練なしに読み込み、組み合わせ、入れ替えられる、離散的で再利用可能な振る舞いの単位である スキル という概念へ、ますます収束しています。
この考え方はVoyager（G. Wang et al. 2023）によって広まりました。Voyagerは、Minecraft内のLLMエージェントが、実行可能なコードスキルのライブラリを増やし、それぞれを検証して後で再利用できるよう保存できることを示しました。同じ原理は本番エージェントにも当てはまります。スキルは、単一のプロンプトが保持できる範囲を超えてスケールする、組み合わせ可能でバージョン管理可能な形式に分野の専門知識をカプセル化します。スキルはツールアクセスのためにMCPサーバー（章7）をラップすることが多く、スキル抽象化を標準化されたツール層へ接続します。
スキルとは何か
スキル とは、特定の分野やタスクに関する専門性をエージェントに与える、自己完結型の能力モジュールです。単一の関数を公開する生のツールとは異なり、スキルは次を含みます。
-
システムプロンプトの拡張: エージェントのコンテキストへ注入する、分野固有の指示、制約、ペルソナ要素。
-
ツールバインディング: スキルが必要とする1つ以上のツール（API、MCPサーバー、ローカルコマンド）。
-
知識: エージェントがスキルを正しく実行するために必要な参考資料、例、少数ショットのデモンストレーション。
-
ワークフローロジック: 複雑なタスクでエージェントを導く、多段階手順、決定木、条件分岐フロー。
-
ガードレール: スキル固有の安全制約、出力形式の要件、検証ルール。
Important
スキル、ツール、エージェントの比較
概念 範囲 例 ツール 単一の関数呼び出し web_search(query)スキル 一貫した能力（プロンプト＋ツール＋知識） 「リサーチアナリスト」スキル エージェント 複数スキルを持つ自律的な主体 コーディングアシスタント ツールはハンマーです。スキルは家をどう建てるかを知っていることです。エージェントは、どのスキルを適用するか選ぶ大工です。
スキルアーキテクチャのパターン
静的なスキル読み込み
最も単純なパターンです。設定に基づいてエージェントの初期化時にスキルを読み込みます。エージェントは常にすべてのスキルへアクセスできます。
# Pseudocode -- framework-agnostic pattern
agent = Agent(
model="claude-sonnet-4-20250514",
skills=["code-review", "documentation", "testing"],
# Each skill adds prompts, tools, and knowledge to the agent
)
長所: 単純で予測可能、低レイテンシです。
短所: スキルを使わない場合にコンテキストウィンドウを浪費し、数百のスキルへはスケールしません。
動的なスキル発見
エージェントは現在のタスクに基づいて、どのスキルを有効化するか選びます。スキルルーター（軽量な分類器や埋め込みベースのマッチャーであることが多い）が関連性を判定します。
# Pseudocode -- framework-agnostic pattern
relevant_skills = skill_router.match(
user_request=message,
available_skills=skill_registry,
max_skills=3
)
agent.activate(relevant_skills)
長所: 大規模なスキルライブラリへスケールし、コンテキスト効率が高いことです。
短所: ルーティングエラーで関連スキルを見逃す可能性があり、レイテンシが増えます。
階層的なスキル合成
スキルは他のスキルに依存してDAGを形成できます。高レベルのスキル（例: 「アプリケーションを配置」）が、サブスキル（「テストを実行」、「Dockerイメージをビルド」、「DNSを更新」）を呼び出すことがあります。
-
スキルは依存関係を明示的に宣言します。
-
オーケストレータは実行前に依存グラフを解決します。
-
サブスキルは複数の親スキルで共有できます。
ケーススタディ：Anthropicのエージェント設計
Anthropicのエージェントアーキテクチャへのアプローチ（Anthropic 2024a）は、本番環境におけるスキルベースのエージェント設計を最も明確に説明するものの1つです。その思想は、 複雑さより単純さ 、 モノリシックなフレームワークより組み合わせ可能な構成要素 を重視します（これらのパターンは、オーケストレーションの観点からも章5で扱います）。
中核原則
-
最も単純な解決策から始めます。 より単純なアプローチ（単一のLLM呼び出し、検索＋生成）を試して不十分だと分かるまで、エージェントパターンに手を伸ばしません。
-
ワークフローとエージェント。 Anthropicは次を区別します。
-
ワークフロー: LLM呼び出しの事前定義されたオーケストレーション。特定のノードにLLMステップを持つ決定論的な制御フローです。より予測可能で、デバッグも容易です。
-
エージェント: LLMが次に行うことを動的に決定します。ツール選択、反復回数、停止基準のすべてがモデル駆動です。より柔軟ですが、制御は難しくなります。
-
-
拡張LLMを原子単位とします。 プリミティブは決して裸のモデルではなく、検索ソース、呼び出し可能なツール、永続メモリを束ねたモデルです。この複合単位は、実際にはスキルを備えたモデルです。
構成要素のパターン
Anthropicは、スキルテンプレートとして機能する5つの組み合わせ可能なワークフローパターンを特定しています。
| パターン | 仕組み | 使う場面 |
|---|---|---|
| プロンプトチェーン | 各ステップの出力を次のステップへ渡す、LLM呼び出しの逐次実行。ステップ間のゲートが中間結果を検証します。 | 分解が明確な多段階変換 |
| ルーティング | 分類器またはLLMが、タスク種別に基づいて入力を専門ハンドラ（スキル）へ振り分けます。 | 異なる専門性が必要な明確なタスクカテゴリ |
| 並列化 | 複数のLLM呼び出しを同時実行します。分割（タスクを分ける）または投票（同じタスクを集約）のいずれかです。 | 独立したサブタスク、または合意による信頼度向上 |
| オーケストレータ・ワーカー | 中央LLMがタスクをサブタスクへ分け、ワーカーLLMに委譲し、結果を統合します。 | サブタスクを事前に予測できない複雑なタスク |
| 評価器・オプティマイザ | 1つのLLMが生成し、別のLLMが評価します。品質しきい値に達するまで反復します。 | 品質基準が明確なタスク（コード、文章） |
Anthropicの組み合わせ可能なエージェントパターンです。
拡張LLM
Anthropicの捉え方では、基本単位は裸のモデルではなく 拡張LLM です。
\[ \text{Augmented LLM} = \text{Model} + \text{Retrieval} + \text{Tools} + \text{Memory} \]
これはスキルの概念に直接対応します。各スキルは、特定のタスクでモデルがアクセスできる検索ソース、ツール、メモリストアを設定します。スキル境界は、特定の呼び出しの中でモデルが見たり実行したりできることを定義します。
実務上の含意
Tip
Anthropicの重要な洞察
最も効果的なエージェントは、最も複雑なエージェントではありません。 優れたツールを持つ単純なループ です。
while not done: action = llm.decide(context, tools) result = execute(action) context.append(result) done = llm.should_stop(context)知性は、手の込んだオーケストレーションロジックではなく、(1)モデルの能力、(2)ツール説明の品質、(3)タスクの枠組みの明確さから生まれます。スキルは(2)と(3)の構造を提供します。
Anthropicのアプローチから得られる設計上の推奨事項
-
エージェントループを単純に保つ: 制御フローを過剰設計せず、モデルに判断させます。
-
ツールの品質に投資する: 詳細で曖昧さのないツール説明は、複雑なルーティングロジックより価値があります。
-
構造化出力を使う: モデルにパース可能な形式（JSON、関数呼び出し）で判断を出力させ、スキル実行エラーを減らします。
-
復旧を組み込む: スキルは、異なるパラメータで再試行する、明確化を求める、人間へエスカレーションするなど、エラーを適切に処理すべきです。
-
スキルごとの範囲を制限する: 何でもしようとするスキルは、何もうまくできません。狭く明確に定義されたスキルの方が、広範なスキルより組み合わせやすくなります。
スキルのライフサイクル
-
発見: システムが利用可能なスキルを特定します（レジストリ、マーケットプレイス、ローカル定義）。
-
選択: ユーザー要求に基づき、関連スキルをマッチングして読み込みます。
-
有効化: スキルのプロンプト、ツール、知識をエージェントのコンテキストへ注入します。
-
実行: エージェントがスキルの能力を使ってタスクを達成します。
-
無効化: 後続タスクのためにコンテキストウィンドウの空間を空けるべく、スキルのコンテキストを削除します。
-
学習: 実行結果によって、スキルの少数ショット例を更新したり、ルーティングをファインチューニングしたりできます。
スキルレジストリとマーケットプレイス
本番用のスキルシステムには、次のインフラが必要です。
-
スキルマニフェスト: 自動発見とルーティングを可能にする構造化された説明（名前、能力、必要なツール、入出力スキーマ）。
-
バージョン管理: スキルは進化するため、エージェントは再現性のために特定バージョンを固定する必要があります。
-
依存関係の解決: スキルは特定のMCPサーバー、APIキー、他のスキルを必要とする場合があります。
-
権限モデル: すべてのエージェントがすべてのスキルへアクセスすべきとは限りません（セキュリティ、コスト、能力の境界）。
-
マーケットプレイス: 組織がスキルを公開、共有、インストールできます。コード向けパッケージマネージャーに相当します。
Note
スキルマニフェストの例
スキルマニフェストは、オーケストレータがスキルを読み込み、呼び出すために必要なすべてを宣言します。業界標準のスキーマはまだ存在しません。以下は、実際の実装（Anthropic MCP、OpenAIの関数仕様、LangChainのツール定義）に共通するフィールドを捉えた説明用の形式です。
// Illustrative schema -- not a specific SDK format { "name": "code-review", "description": "Review code changes for bugs, style, and security issues", "version": "2.1.0", "requires": { "tools": ["file_read", "grep", "git_diff"], "mcp_servers": ["github"], "models": ["claude-sonnet-4-20250514"] }, "input_schema": { "type": "object", "properties": { "repo": {"type": "string"}, "pr_number": {"type": "integer"} } }, "prompts": ["skills/code-review/system.md"], "knowledge": ["skills/code-review/style-guide.md"] }
スキルとファインチューニングの比較
自然な疑問は、なぜモデルをファインチューニングする代わりに実行時のスキル注入を使うのか、ということです。
| 観点 | スキル（コンテキスト内） | ファインチューニング |
|---|---|---|
| 配置速度 | 即時 | 数時間〜数日 |
| 柔軟性 | 実行時に入れ替え／組み合わせ | 訓練時に固定 |
| コンテキストコスト | コンテキストウィンドウを使用 | 実行時コストゼロ |
| 深い挙動変化 | コンテキスト長に制限される | 深いパラメータ変化 |
| マルチテナント | ユーザーごとに異なるスキル | 全員で同じモデル |
| 保守 | テキストファイルを更新 | 新しいデータで再訓練 |
能力追加におけるスキル（コンテキスト内）とファインチューニングの比較。
実際には、この2つのアプローチは補完的です。ファインチューニングが基礎能力（指示追従、ツール利用形式、推論）を提供し、スキルが実行時にその上へタスク固有の専門性を重ねます。