AIエージェントがスキルを実装する仕組み：クロスプラットフォーム完全比較

はじめに

すべてのAIエージェントフレームワークは、同じ根本的な問題に直面しています：LLMを特定のタスクに長けたものにするにはどうすればよいか？モデル自体は幅広い一般知識を持っていますが、コードレビュー、インフラのデプロイ、Minecraftのナビゲーションなど、特定のタスクを実行するには、専門的な指示、ツールアクセス、ドメインコンテキストが必要です。

これがスキル注入問題です。そして、主要なフレームワークはそれぞれ異なる方法で解決しています。

一部のプラットフォームはすべてをシステムプロンプトに事前に投入します。他のプラットフォームは遅延読み込みを使用し、エージェントが必要とする場合にのみ機能を明らかにします。いくつかのプラットフォームはベクトルデータベースを使用して、セマンティック類似性に基づいて関連するスキルを取得します。これらの違いは学術的なものではありません。トークンコスト、エージェントの信頼性、エージェントが現実的に扱えるスキル数に直接影響します。

私たちは11の主要AIエージェントプラットフォームを分析し、スキルがプロンプトのどこに配置されるか、いつ読み込まれるか、トークンコストはどれくらいか、コンテキストウィンドウがいっぱいになった時にどう維持されるかを正確に把握しました。これは表面的な機能比較ではありません。ソースコード、ドキュメント、アーキテクチャ図を精査し、各プラットフォームの正確な注入メカニズムをマッピングしました。

マスター比較表

詳細に入る前に、全体像を把握しましょう。

注入メカニズム：どこで、いつ、どのように

永続性、トークンコスト、常時オン動作

ビジネスを成長させる準備はできましたか？

今日から無料トライアルを開始し、数日で結果を確認しましょう。

デモをリクエスト ログイン

「スキル注入」が実際に意味すること

比較に入る前に、問題空間を定義しましょう。AIエージェントのコンテキストウィンドウ — 各呼び出し時にLLMが参照するテキスト全体 — には固定サイズがあります。指示、会話履歴、ツール定義、取得データのすべてのトークンが、そのウィンドウ内のスペースを競合します。

エージェントのコンテキストにおける「スキル」とは、エージェントの動作を変える構造化された専門知識パッケージです。これには以下が含まれます：

• 指示：特定のドメインへのアプローチ方法をエージェントに伝える（コードレビューガイドライン、デプロイチェックリスト）
• ツール定義：エージェントに呼び出し可能な関数を提供する（API統合、ファイル操作）
• Few-shot例：良い出力がどのようなものかをエージェントに示す
• 取得された知識：ベクトルデータベースや外部ドキュメントからの情報

注入メカニズム — このコンテンツがいつどこでコンテキストに入るか — は、3つの重要な特性を決定します：

1. トークン効率：スキルはどれだけのトークンを消費するか、そのコストはスキルが不要な場合でも発生するか？
2. 信頼性：エージェントは関連する場合にスキルを一貫して使用するか、それとも見逃す可能性があるか？
3. スケーラビリティ：コンテキストの膨張がパフォーマンスを低下させる前に、エージェントはいくつのスキルにアクセスできるか？

すべてのフレームワークはこれら3つの次元で異なるトレードオフを行っています。それぞれを詳しく見ていきましょう。

注入スペクトラム：常時オンからオンデマンドまで

11のプラットフォームすべてにおいて、スキル注入アプローチは「すべてを事前に読み込む」から「明示的に必要になるまで何も読み込まない」までのスペクトラム上に位置します。

一方の端では、CrewAI、SuperAGI、CAMEL-AIのようなプラットフォームが、アクティベートされたすべてのスキルの完全なコンテンツをすべてのLLM呼び出しに注入します。エージェントは常に完全な専門知識を利用できます。シンプルで信頼性が高いですが、トークンコストが高くなります。

もう一方の端では、Claude Code、LangChain Deep Agents、OpenAIのResponses APIが段階的開示を使用します。エージェントは起動時にスキル名と短い説明のみを参照し、完全なコンテンツはオンデマンドで読み込まれます。効率的でスケーラブルですが、エージェントがスキルの必要性を認識する必要があります。

中間には、AutoGen TeachabilityとVoyagerがセマンティック検索を使用して、ターンごとに最も関連するスキルのみを注入し、動的でコンテキストに応じた注入パターンを作成しています。

そして独自のアプローチもあります：DSPyは最適化されたfew-shot例をオフラインでコンパイルし、モジュールプロンプトに恒久的に組み込みます。MetaGPTはスキルをアクションテンプレートとしてエンコードし、特定のロールが特定のアクションに遷移した場合にのみアクティベートされます。

それぞれを詳しく見ていきましょう。

ニュースレターに登録

最新のヒント、トレンド、お得な情報を無料で入手。

メールアドレス

登録する

Claude Code：3層の段階的開示

Claude Codeは、認知度とトークン効率のバランスをとる3層の段階的開示システムを使用した、最も洗練されたスキル注入アーキテクチャの1つを実装しています。

第1層：コンテキストに常時存在

セッション開始時に、利用可能なすべてのスキルの名前と説明がsystem-reminderメッセージ — モデルが常に参照するメタデータブロック — に注入されます。これにはスキルあたり約250文字のコストがかかり、すべてのスキル説明を合わせてコンテキストウィンドウ予算の約1%を消費します（フォールバック予算として約8K文字、SLASH_COMMAND_TOOL_CHAR_BUDGET環境変数でオーバーライド可能）。

同様に、完全なJSONスキーマがまだ読み込まれていない遅延ツールは、system-reminderブロックに名前のみのリストとして表示されます。Claude Code v2.1.69時点では、Bash、Read、Edit、Write、Glob、Grepなどの組み込みシステムツールもToolSearchの背後で遅延され、システムツールのコンテキストが約14〜16Kトークンから約968トークンに削減されています。

エージェントは完全な定義のトークンコストを支払うことなく、利用可能なものを把握するのに十分な情報を得られます。

第2層：アクティベーション時

ユーザーがスラッシュコマンド（例：/commit）を入力するか、モデルが説明に基づいてスキルを自動マッチした場合、完全なSKILL.md本体がSkillツール経由で会話メッセージとして読み込まれます。この本体には完全な指示が含まれ、時には数千トークンの詳細なガイダンスが含まれます。

重要な詳細：シェルの前処理が最初に実行され（スキルファイル内の!commandディレクティブが実行され、その出力がディレクティブを置き換えます）、読み込まれたスキル本体はセッションの残りの間、会話に残ります。

第3層：オンデマンド

追加リソース — 参考ドキュメント、スクリプト、アセットファイル — は、モデルがReadツールを使用してアクセスすることを明示的に決定した場合にのみ読み込まれます。これらは自動的に読み込まれることはありません。

コンテキスト圧縮時の動作

会話がコンテキスト制限に近づき圧縮がトリガーされると、Claude Codeはスキルあたり5Kトークン、合計最大25Kの予算で最近呼び出されたスキルを再添付します。最近呼び出されたスキルが優先されます。古いスキルは完全にドロップされる場合があります。

この3層アーキテクチャにより、20以上の利用可能なスキルを持つエージェントは最小限の初期コストを支払いつつ、単一のターン内でいずれのスキルの完全な専門知識にもアクセスできます。

CrewAI：すべてのタスクプロンプトへの完全注入

CrewAIは段階的開示とは正反対のアプローチを取ります。スキルがエージェントに対してアクティベートされると、その完全なコンテンツがエージェントが実行するすべてのタスクプロンプトに注入されます。

仕組み

CrewAIのスキルは自己完結型のディレクトリで、それぞれにSKILL.mdファイルが含まれており、YAMLフロントマター（名前、説明、ライセンス、互換性、許可ツール）とマークダウン本体で構成されています。スキルシステムはスキルとツールを区別します：スキルはエージェントの思考方法を形作る指示とコンテキストを注入し、ツールはアクションのための呼び出し可能な関数を提供します。

エージェント初期化時に、Agent.set_skills()がdiscover_skills()を呼び出してメタデータレベルでスキルディレクトリをスキャンし、次にactivate_skill()で完全なスキル本体を読み込みます。タスク実行時には、_finalize_task_prompt()がアクティベートされた各スキルに対してformat_skill_context()を呼び出し、フォーマットされたすべてのスキルコンテンツをタスクプロンプトに追加します。

LLMが受け取るのは：[システムメッセージ] + [タスクプロンプト + すべてのスキル本体]

トークンへの影響

CrewAIはスキルあたり50,000文字でソフト警告を設けていますが、ハードリミットはありません。ドキュメントでは、大きなプロンプト注入がモデルの注意力を希釈するため、スキルを焦点を絞って簡潔に保つことを推奨しています — これはコンテキスト劣化に関する研究を考えると現実的な懸念です。

トレードオフは明確です：エージェントは常に完全な専門知識を利用できますが（高い信頼性）、トークンコストはタスクあたりのスキル数に比例して増加します（低い効率性）。1〜2つの焦点を絞ったスキルを持つエージェントにはうまく機能します。幅広い機能セットを必要とするエージェントにとっては、急速にコストが増大します。

タスク間の永続性なし

各タスクは新規注入を受けます。タスク間でスキルコンテンツの蓄積はありません — これは実際にはバグではなく機能です。各タスクがクリーンなコンテキストで開始されるため、セッションベースの永続化が生じうる陳腐化の問題を回避できます。

LangChain Deep Agents：SkillsMiddlewareによるエージェント制御の読み込み

LangChain Deep Agentsは、エージェント自体が完全なスキルコンテンツをいつ読み込むかを決定する、洗練されたミドルウェアベースのスキルシステムを実装しています — エージェントがアクティベーションを制御する真の段階的開示モデルです。

3つのティア

ティア1（インデックス）： SkillsMiddlewareが起動時にすべてのSKILL.mdフロントマターを解析し、軽量なインデックスをシステムプロンプトに注入します。このインデックスには名前と説明のみが含まれ、完全なコンテンツの3,302トークンに対してスキルあたり約278トークンのコストです。

ティア2（完全なコンテンツ）： エージェントがスキルが関連すると判断すると、スキルのSKILL.mdパスに対してread_file()を呼び出します。これは通常のツール呼び出しです — フレームワークが本体を注入するのではなく、エージェントが意図的に読み込む決定をします。完全なコンテンツはツール結果として会話履歴に入ります。

ティア3（ディープダイブ）： 補足資料、参考ドキュメント、スクリプトは、エージェントが明示的に読み取った場合にのみアクセスされます。

実際のトークン効率

12のスキルがある場合、段階的開示により約30,000トークン（すべて読み込み）から約600トークン（インデックスのみ）に削減され、特定のタスクで関連スキルが読み込まれると2,000〜5,000に拡大します。これはスキル関連トークン消費量の83〜98%の潜在的な削減です。

複数のスキルソースをレイヤー化でき、名前が衝突した場合は最後のソースが優先されます。10MBを超えるファイルは自動的にスキップされます。

Claude Codeとの主な違い

Claude Codeが専用のSkillツールを使用して読み込みをトリガーするのに対し、Deep Agentsはエージェントの既存のread_fileツールを再利用します。つまり、読み込みメカニズムは透過的です — エージェントは他のファイルと同じようにスキルファイルを読みます。欠点は、特別な圧縮動作がないことです：会話履歴に入ったスキルコンテンツは、優先処理なしで標準のLangChainメッセージトリミングの対象となります。

OpenAI Responses APIとAgents SDK：プラットフォーム管理の遅延読み込み

OpenAIは、Responses APIのtool_searchツールタイプとAgents SDKのToolSearchToolという、2つの異なるが思想的に一致したメカニズムを通じてスキル注入を実装しています。

Responses API：tool_search

tool_searchツールタイプ（GPT-5.4+で利用可能）により、開発者は大規模なツールサーフェスをランタイムまで遅延できます。3つの遅延戦略が利用可能です：

• 個別関数の遅延： @function_tool(defer_loading=True) — モデルは関数名と説明を参照しますが、パラメータスキーマは遅延されます。パラメータレベルのトークンを節約します。
• 名前空間の遅延： tool_namespace(name=..., description=..., tools=[...]) — 関数を単一の名前空間にグループ化します。モデルは名前空間の名前と説明のみを参照し、大幅にトークンを節約します。
• MCPサーバーの遅延： HostedMCPTool(tool_config={..., "defer_loading": True}) — MCPサーバー全体のツールサーフェスを遅延します。

モデルが特定のツールが必要だと判断すると、tool_search呼び出しを発行します。APIは3〜5の関連ツール定義を返し、プロンプトキャッシュを維持するためにコンテキストウィンドウの末尾に注入されます。

Agents SDK：ToolSearchTool

Agents SDKはプログラマティックな同等機能を提供します。ツール名前空間は登録されますが読み込まれません：

crm_tools = tool_namespace(
    name="crm",
    description="CRM management tools",
    tools=[...]
)
agent = Agent(tools=[*crm_tools, ToolSearchTool()])

実行時、エージェントは名前空間名のみを参照します。ToolSearchTool("crm")を呼び出して完全なスキーマを発見・読み込み、その後その名前空間内の個別ツールを呼び出せます。

クロスリクエストの永続性なし

各APIリクエストは独立しています。発見されたツールはコール間で永続化されません。これは今回の比較で最もステートレスなアプローチです — クリーンで予測可能ですが、ツールが変更された場合はリクエストごとに再発見が必要です。

AutoGen Teachability：ターンごとのセマンティック検索

AutoGenのTeachability機能は、この比較の他のすべてのフレームワークとは根本的に異なるアプローチを取ります。静的なスキルコンテンツを注入する代わりに、毎ターンChromaDBベクトルデータベースから関連する「メモ」を動的に取得します。

ターンごとの検索ループ

Teachabilityはprocess_last_received_messageにフックを登録し、エージェントが処理する前にすべての受信ユーザーメッセージを傍受します：

1. TextAnalyzerAgentが受信メッセージからキーコンセプトを抽出
2. これらのコンセプトを使用してChromaDBにクエリ（デフォルトでSentence Transformer埋め込みを使用）
3. 上位K件の最も関連するメモを取得（max_num_retrievalsで設定可能、デフォルト10）
4. 取得したメモをメッセージテキストに追加してからエージェントに渡す

重要な点として、変更されたメッセージは保存された会話履歴には伝播しません — 元のメッセージのみが保存されます。これにより、メモのコンテンツがターン間で複合的に増加することを防ぎます。

学習ループ

LLMが応答した後、2番目のフックが応答を分析して新しい学習を抽出します：

1. TextAnalyzerAgentが応答内の新しい知識を特定
2. 新しいメモがキー・バリューペア（入力テキスト → 出力テキスト）として抽出
3. これらのメモがChromaDBに保存され、将来のターンやセッションで利用可能に

これにより、エージェントが時間とともに専門知識を蓄積する真の学習ループが生まれます。

クロスセッション永続化

AutoGen Teachabilityは、今回の比較でセッション間でスキルを永続化する3つのプラットフォーム（VoyagerとDSPyと並んで）のうちの1つです。ChromaDBデータベースはディスク上に存在するため、エージェントは月曜日のインタラクションから学び、金曜日にその知識を適用できます。

recall_thresholdパラメータ（デフォルト1.5）は、保存されたメモに対するメッセージの類似度の閾値を制御し、reset_dbは必要に応じてメモリ全体をクリアできます。

トークン効率

ターンごとに関連するメモのみが注入されるため（通常3〜5件）、メモデータベースがどれだけ大きくなっても、トークンコストは自然に制限されます。10,000件の保存メモを持つエージェントでも、現在のターンに最も関連する少数分のみのコストを支払います。

Semantic Kernel：常時存在のツール定義としてのプラグインスキーマ

MicrosoftのSemantic Kernelは直接的なアプローチを取ります：プラグインはKernelに登録されたKernelFunctionオブジェクトのコレクションであり、それらのスキーマは関数呼び出しツール定義としてLLMに公開されます。

2つの注入パス

関数呼び出し： ToolCallBehavior.AutoInvokeKernelFunctionsが設定されている場合、すべての登録済み関数がすべてのAPIリクエストで利用可能なツールとしてLLMに送信されます。LLMがどれを呼び出すかを決定し、Semantic Kernelが呼び出しと結果のルーティングを処理します。

プロンプトテンプレート： Semantic Kernelのテンプレート構文（{{plugin.function}}、Handlebars、またはLiquid）により、プロンプトレンダリング中に関数をインラインで呼び出すことができます。結果はLLMに到達する前にプロンプトテキストに直接埋め込まれます — 遅延ツール呼び出しではなく、先行評価の一形態です。

段階的開示なし

すべての登録済みプラグインのスキーマがすべてのAPI呼び出しに含まれます。組み込みの遅延読み込み、名前空間グループ化、オンデマンドアクティベーションはありません。ドキュメントでは、トークン消費と誤呼び出しを減らすために、特定のシナリオに必要なプラグインのみをインポートすることを明示的に推奨しています。

これにより、Semantic Kernelは最も予測可能なプラットフォームの1つになりますが — エージェントが何にアクセスできるかを常に正確に把握できます — スケーラビリティが制限されます。50の登録済み関数を持つエージェントは、すべての呼び出しで完全なスキーマコストを支払います。

永続性

プラグイン登録はKernelインスタンスごとでメモリ内です。クロスセッションのスキル永続化のための組み込みメカニズムはありません。

MetaGPT：ロールベースSOP内のアクションテンプレート

MetaGPTはスキルを独立したパッケージとしてではなく、ロールの動作を管理する標準業務手順（SOP）に埋め込まれたアクションテンプレートとしてエンコードします。

ロールとアクションのアーキテクチャ

MetaGPTの各Roleは、プロンプトに注入されるペルソナプレフィックスとActionクラスのセットを持ちます。各Actionにはaask()経由で呼び出されるLLMプロキシが含まれ、自然言語プロンプトテンプレートを使用してLLM呼び出しを構造化します。

Role._act()が発火すると、3つの反応モードをサポートします：

• "react"： LLMが思考-行動ループでアクションを動的に選択
• "by_order"： アクションが予め決められた順序で順次実行
• "plan_and_act"： エージェントがまず計画を立て、計画に従ってアクションを実行

狭い注入ウィンドウ

任意の時点でアクティブなのは現在のアクションのプロンプトテンプレートのみです。エージェントは他のアクションのテンプレートを参照しません — ロールプレフィックスと特定のアクションのコンテキストのみを参照します。これは今回調査したフレームワークの中で最も狭い注入ウィンドウです。

Actionクラス内のコンテキスト解析関数が入力から関連情報を抽出するため、各アクションは完全な会話履歴ではなく、利用可能なコンテキストの厳選されたサブセットを受け取ります。

シングルターンの永続性

テンプレートは各アクション実行時に新しくレンダリングされます。蓄積やクロスセッションの永続化はありません。これにより各アクションは焦点が絞られますが、単一のワークフロー内で以前に読み込まれたスキルコンテンツの上に構築することはできません。

Voyager：生涯学習のための埋め込みベースのスキル検索

NVIDIAとCaltechのMinecraft探索エージェントであるVoyagerは、最もエレガントなスキル注入アーキテクチャの1つを実装しています：埋め込み類似性によって検索される、検証済みプログラムの成長するライブラリです。

スキルライブラリ

Voyagerが自己検証に合格するコードを書くと（生成されたMineflayer JavaScriptが実際にゲーム内で動作する）、コードとそのドキュメント文字列がベクトルデータベースに保存されます。ドキュメント文字列の埋め込みが検索キーになります。

タスクごとの検索

自動カリキュラムが提案する各新しいタスクで：

1. タスク説明と環境フィードバックが埋め込まれる
2. すべての保存済みスキル埋め込みに対するコサイン類似性検索
3. 上位5件の最も関連するスキルが取得される
4. 取得されたスキルコードがアクションエージェントのプロンプトにfew-shot例として含まれる

プロンプトは以下のようになります：

You are a Minecraft bot. Here are some relevant skills you've learned:

// Skill: mineWoodLog
async function mineWoodLog(bot) { ... }

// Skill: craftPlanks
async function craftPlanks(bot) { ... }

Now write code to: build a wooden pickaxe

生成されたコードは取得されたスキルを名前で呼び出すことができ、構成的なスキル構築を可能にします — より単純で検証済みのプリミティブから構築される複雑な動作。

生涯の永続化

スキルライブラリは核となる「生涯学習」メカニズムです。エージェントの全生涯にわたって成長し、新しいスキルは古いスキルの上に構築されます。ほとんどのフレームワークでスキルが人間によって作成されるのとは異なり、Voyagerのスキルはエージェント自体によって生成、検証、保存されます。

トークンコストは自然に制限されます：ライブラリに50件あっても5,000件あっても、各タスクは最も関連する5件の検索分のコストのみを支払います。

DSPy：凍結されたスキルとしてのコンパイル済みFew-Shot例

DSPyは他のすべてのフレームワークとは根本的に異なるアプローチを取ります。ランタイムでスキルを注入する代わりに、DSPyは最適なfew-shotデモンストレーションをオフラインでコンパイルし、モジュールプロンプトに恒久的に組み込みます。

コンパイルプロセス

2つの主要なオプティマイザがコンパイルを処理します：

BootstrapFewShot： ティーチャーモジュールを使用してプログラムを通じたトレースを生成します。ユーザー定義のメトリックに合格したトレースがデモンストレーションとして保持されます。プログラム内の各dspy.Predictモジュールは、独自のキュレーションされたデモンストレーションセットを取得します。

MIPROv2（Multi-prompt Instruction Proposal Optimizer v2）： 3フェーズのプロセス：

1. ブートストラップ： 候補デモンストレーションセットを生成
2. 提案： データ分布とデモンストレーションの両方を考慮した候補指示テキストを生成
3. 検索： すべてのモジュールにわたる指示 × デモンストレーションの結合空間でのベイズ最適化

max_bootstrapped_demos（生成例）やmax_labeled_demos（トレーニングデータから）などのパラメータが、各モジュールのプロンプトに含まれる例の数を制御します。

コンパイル後は固定

コンパイルされると、デモンストレーションは各Predictモジュールのdemos属性に保存され、すべてのLLM呼び出しでプロンプトにフォーマットされます。ランタイムでは変更されません — 「スキル」は凍結されています。

つまり、DSPyのスキルは今回の比較で最も予測可能です：トークンコストはコンパイル後に既知、ターン間の分散なし、エージェントは常に同じデモンストレーションを参照します。欠点は柔軟性のなさです — スキルを変更するには再コンパイルが必要です。

永続性

コンパイル済みプログラムはすべてのデモンストレーションを含めてJSONにシリアライズされます。完全に永続化され、セッション間で読み込み可能で、DSPyを最も耐久性の高いスキルストレージメカニズムの1つにしています。

SuperAGI：ツールキットベースの事前登録

SuperAGIは、エージェント初期化時にすべてのツールが登録される従来のツールキットパターンを使用します。

各ツールキットはBaseToolkitを以下で拡張します：

• nameとdescription属性
• BaseToolインスタンスのリストを返すget_tools()メソッド
• 必要な環境変数のためのget_env_keys()

ツールキットはSuperAGIのツールマネージャーを通じてGitHubリポジトリからインストールされます。エージェント初期化時に、BaseToolkit.get_tools()がすべてのツールを返し、完全なスキーマが関数呼び出し定義としてLLMに公開されます。

遅延読み込み、段階的開示、ターンごとのフィルタリングはありません。すべての登録済みツールのスキーマがすべての呼び出しに存在します。これは最もシンプルな注入モデルで、焦点を絞った小さなツールセットを持つエージェントにはうまく機能しますが、数十の機能を必要とするエージェントにはスケールしません。

CAMEL-AI：ChatAgentツール登録

CAMEL-AIも同様の事前登録パターンに従います。さまざまなツールキット（例：MathToolkit、SearchToolkit）からのツールが、初期化時にChatAgent(tools=[...])にリストとして渡されます。

フレームワークは、モデルが使用方法を理解できるように、カスタム関数には明確な引数名と包括的なdocstringが必要であることを強調しています — ツールスキーマがモデルに見える唯一の「スキル」コンテンツです。別個の指示注入メカニズムはありません。

最近の追加にはMCPToolkit経由のMCP（Model Context Protocol）サポートがあり、ChatAgentがMCPサーバーに接続して外部ツールを登録できます。これにより利用可能なツールサーフェスは拡大しますが、注入モデルは変わりません — 発見されたすべてのMCPツールは依然として事前に登録されます。

クロスプラットフォーム比較

スキルが注入されるタイミング

永続化モデル

コンテキスト圧縮時の維持

段階的開示パターン

これらのプラットフォームにおける最も重要なアーキテクチャトレンドは、段階的開示の採用です — 必要に基づいて情報を段階的に明らかにするUIデザインから借用した概念です。

段階的開示が重要な理由

スキル注入への素朴なアプローチ — すべてを事前に読み込む — は2つの問題を引き起こします：

1. トークンの無駄： ほとんどのスキルはほとんどのターンで関連しません。ターンごとに1〜2個しか必要ない時に20個の完全なスキル本体を読み込むと、スキル関連トークンの90%以上が無駄になります。
2. 注意力の希釈： コンテキスト劣化に関する研究は、コンテキストに大量の無関係な情報が含まれるとLLMのパフォーマンスが低下することを示しています。コンテキスト内のスキルが増えると、実際にはスキル適用の品質が低下する可能性があります。

段階的開示は、利用可能なスキルの軽量インデックスを維持しながら、必要な場合にのみ完全なコンテンツを読み込むことで、両方の問題を解決します。

実装のバリエーション

Claude Codeは専用システムを使用します：system-reminderメッセージ内のスキルメタデータ、アクティベーション用のSkillツール、遅延ツールスキーマ用のToolSearch。フレームワークが優先度ベースの圧縮で注入を自動管理します。

LangChain Deep Agentsはエージェントの既存のファイル読み取り機能を使用します：SkillsMiddlewareがインデックスを注入し、エージェントがread_file()で完全なコンテンツを読み込みます。これはより透過的ですが、フレームワークレベルの最適化は少なくなります。

OpenAI Responses APIは名前空間ベースのグループ化とプラットフォーム管理の検索を使用します：ツール名前空間が高レベルの説明を提供し、tool_searchが関連するスキーマを返します。プラットフォームが検索ロジックを完全に処理します。

実際のトークン削減

数字は説得力があります。12のスキルで：

• 常時オン注入（CrewAI/SuperAGIスタイル）：約30,000トークン
• 段階的開示インデックスのみ：約600トークン
• インデックス + アクティベートされた2スキル：約2,000〜5,000トークン

これはターンあたりのスキル関連トークン消費の83〜98%の削減です。数百ターンの長いセッションでは、節約は劇的に複合されます。

アーキテクチャパターンとトレードオフ

11のプラットフォームすべてを見渡すと、4つの明確なアーキテクチャパターンが浮かび上がります：

パターン1：常時オン注入

使用： CrewAI、SuperAGI、CAMEL-AI、Semantic Kernel

仕組み： 完全なスキルコンテンツまたはツールスキーマがすべてのLLM呼び出しに存在。

メリット：

• 最大の信頼性 — エージェントは常に完全な専門知識を利用可能
• 最もシンプルな実装 — アクティベーションロジック不要
• 予測可能なトークンコスト — 毎ターン同じ

デメリット：

• トークンコストがスキル数に比例して増加
• 多くのスキルでの注意力希釈
• エージェントあたり約5〜10スキルを超えるとスケールしない

最適な用途： 常に関連する1〜3のコアスキルを持つ焦点の絞られたエージェント。

パターン2：段階的開示

使用： Claude Code、LangChain Deep Agents、OpenAI Responses API/Agents SDK

仕組み： 軽量メタデータが常時存在、完全なコンテンツはオンデマンドで読み込み。

メリット：

• 数十から数百の利用可能なスキルにスケール
• スキルが不要な場合の最小トークンコスト
• 完全なスキーマが末尾に追加される際のプロンプトキャッシュの維持

デメリット：

• エージェントが関連スキルをアクティベートするキューを見逃す可能性
• アクティベーションステップによる追加レイテンシー
• より複雑なフレームワーク実装

最適な用途： 多くの機能にアクセスする必要があるが、タスクごとに少数しか使用しない汎用エージェント。

パターン3：セマンティック検索

使用： AutoGen Teachability、Voyager

仕組み： ベクトルデータベースクエリが、現在のコンテキストとのセマンティック類似性に基づいて関連するスキル/知識を表面化。

メリット：

• ライブラリサイズに関係なく自然に制限されたトークンコスト
• ライブラリが成長するにつれてコンテンツの関連性が向上
• クロスセッションの学習と蓄積
• 明示的なアクティベーション不要 — 関連性は自動計算

デメリット：

• 検索品質が埋め込みモデルの品質に依存
• 古い情報や微妙に誤った情報を取得するリスク
• ベクトルデータベースインフラが必要
• 予測しにくい — ターンごとに異なるコンテンツが読み込まれる

最適な用途： 経験から学び、時間とともにドメイン知識を蓄積する必要があるエージェント。

パターン4：コンパイル済み/静的注入

使用： DSPy、MetaGPT

仕組み： スキルが固定プロンプトコンテンツにコンパイル（DSPy）されるか、厳格なアクションテンプレートを通じてアクティベート（MetaGPT）。

メリット：

• 最も予測可能な動作 — 毎回同じコンテンツ
• オフラインで最適化可能（DSPyのコンパイル）
• スキル選択のランタイムオーバーヘッドなし
• 明確に定義された反復可能なタスクに効果的であることが実証済み

デメリット：

• 柔軟性がない — スキルの変更に再コンパイル（DSPy）またはコード変更（MetaGPT）が必要
• コンパイルされた例の外の新しい状況に適応できない
• DSPyのコンパイルプロセス自体に多くのLLM呼び出しが必要

最適な用途： 信頼性が柔軟性より重要な、明確に定義されたタスクを持つ本番パイプライン。

エージェントビルダーへの実践的な示唆

適切なパターンの選択

適切なスキル注入アーキテクチャは、エージェントのプロファイルによって異なります：

エージェントが狭く明確に定義された役割を持つ場合（例：コードレビューボット、1製品のカスタマーサポートエージェント）、常時オン注入（CrewAI/SuperAGIパターン）が最もシンプルで信頼性が高いです。2〜3の常時存在スキルのトークンコストは管理可能で、アクティベーションロジックの複雑さを回避できます。

エージェントが幅広い機能を必要とするがインタラクションごとに少数しか使用しない場合（例：開発者アシスタント、汎用自動化エージェント）、段階的開示（Claude Code/Deep Agentsパターン）が明確な勝者です。大規模での83〜98%のトークン削減は無視できないほど重要です。

エージェントがインタラクションから学習し改善する必要がある場合（例：パーソナルアシスタント、知識を蓄積するドメインエキスパート）、セマンティック検索（AutoGen Teachabilityパターン）が他のパターンにない学習ループを提供します。ナレッジベースに入る情報の品質管理を確保してください。

エージェントが明確に定義されたパイプラインを実行する場合（例：データ処理、レポート生成、標準化されたワークフロー）、コンパイル済み注入（DSPyパターン）が最も予測可能で最適化された動作を提供します。

ハイブリッドアプローチ

エージェントがすぐに機能する必要がある本番エージェントチームには、ハイブリッドアプローチを推奨します：

コアスキル（エージェントあたり1〜2、主要なドメイン専門知識を定義）：CrewAIスタイルで常にシステムプロンプトに注入。エージェントが毎ターン必要とする交渉の余地のない機能です。

拡張スキル（エージェントが必要とする可能性のある追加機能）：システムプロンプトにはメタデータのみ、必要に応じて検索/読み込みメカニズムで読み込み、Deep Agentsスタイル。関連しない場合にトークンコストを支払うことなく、エージェントの機能セットを拡張します。

学習された知識（蓄積されたドメイン専門知識）：ベクトルデータベースに保存され、ターンごとにセマンティックに検索、AutoGenスタイル。手動でスキルを作成することなく、エージェントが時間とともに改善できます。

この階層化アーキテクチャは、システムプロンプトの構築方法に自然にマッピングされます：日付 → ペルソナ → システム指示 → コアスキル → スキルインデックス → ロール/チームコンテキスト。コアスキルとインデックスが予測可能で管理可能なトークンコストを追加し、完全なスキル本体は必要な場合にのみ表示されます。

フレームワーク全体のトークン予算ベストプラクティス

どの注入パターンを使用するかに関係なく、以下のトークン管理戦略は普遍的に適用されます：

キャッシュフレンドリーな順序付け

変更されないコンテキスト（システム指示、ツールスキーマ）をプロンプトの先頭に配置します。プロンプトキャッシュをサポートするプロバイダーでは、キャッシュされたトークンのコストが75%削減されます。Claude CodeとOpenAIはどちらも、静的プレフィックスのキャッシュヒットを維持するために、発見されたツールスキーマをコンテキストの末尾に注入します。

オフローディング

完全な結果をコンテキストに保持するのではなく、ツールレスポンスを要約します。完全なデータはエージェントがオンデマンドで読み取れる外部参照に保存します。これは、セッションあたり多くのツール呼び出しを行うエージェントにとって特に重要です。

削減

要約によって会話履歴を圧縮します。長いやり取りから重要な事実を凝縮された表現に抽出します。セッションベースの永続化を持つすべてのフレームワークは、積極的な履歴管理の恩恵を受けます。

事前読み込みよりも検索

すべてを事前に読み込むのではなく、ランタイムで関連情報を動的にフェッチします。これはスキル、ナレッジベース、さらには会話履歴にも適用されます。研究では、これによりプロンプトサイズが最大70%削減できることが示されています。

分離

各エージェントのコンテキストが焦点を保つように、特定のタスクにサブエージェントを使用します。1つのエージェントに20のスキルを与える代わりに、各4スキルの5エージェントのチームを作成します。各エージェントがリーンなコンテキストウィンドウを維持し、チーム全体で完全な機能セットをカバーします。

まとめ

AIエージェントフレームワークがスキルをコンテキストに注入する方法は、エージェント設計における最も重要なアーキテクチャ上の決定の1つです — しかし、このレベルの詳細で議論されることはほとんどありません。

この分野は、汎用エージェントの推奨パターンとして段階的開示に明らかに収束しており、Claude Code、LangChain Deep Agents、OpenAIのすべてが独立して類似の3層アーキテクチャに到達しています。一方、セマンティック検索（AutoGen、Voyager）やコンパイル済み注入（DSPy）などの特化パターンは、段階的開示だけでは対応できない重要なニッチを満たしています。

今日エージェントシステムを構築する実践者にとっての重要な洞察は、スキル注入は万能の問題ではないということです。適切なアプローチは、エージェントの役割、必要なスキルの数、時間とともに学習する必要があるかどうか、トークンコストと信頼性のトレードオフに対する許容度によって異なります。

最も堅牢な本番システムは、おそらく複数のパターンを組み合わせることになるでしょう — コア機能には常時オン、拡張スキルには段階的開示、蓄積された知識にはセマンティック検索 — 効率的かつ専門的なエージェントを生み出します。