AgentKits Marketingには28個のスキルがある。だが一度に読み込むのは常に5個まで

「断る」ために作られたレジストリ

AgentKits Marketingの「Enterprise Skill System」の中心にあるファイルskills-registry.jsonは、28個のスキルを5つのカテゴリー——コアとなるマーケティングの基礎知識、コンバージョン率最適化(CRO)、コンテンツ、SEO/グロース、ドキュメント作成——に分類してカタログ化している。だがこのファイルは、それより目立たない、もう1つのものも同時に記録している。dependencyGraphというオブジェクトで、どのスキルが実行前にどの他のスキルを必要とするかを表している。signup-flow-croはform-croを必要とし、form-croはpage-croを必要とする。paywall-upgrade-croはpage-croとpricing-strategyの両方を必要とする。ab-test-setupはpage-croとanalytics-attributionを必要とする。レジストリの各エントリにはtriggersという配列もあり、「funnel」「TOFU」「bounce rate」「signup flow」といった、リクエストと照合されるプレーンなキーワードが並ぶ。

こうした仕組みは、エージェントがより多くのスキルを見つけられるようにするために存在するのではない。むしろ、より少なく読み込ませるために存在する。このアルゴリズムを文章で説明した付随ファイルdependency-graph.mdは、その第3ステップで目的をはっきり述べている——「コンテキストを制限する——コンテキスト・ロットを避けるため、最大3〜5個のスキルまでしか読み込まない」。カタログ化されているスキルは28個。だが1つのタスクが実際に触れるのは、そのうち意図的に選ばれた3〜5個だけであり、棚全体を一度に持ち出すことは想定されていない。

レジストリの背後にある調査文書

この問題を最初に名指ししたのはレジストリではない。docs/improvement-research-260201.md——現在のレジストリが実装されるより数か月前、2026年2月1日付の文書——には、そこに至った理由がすでに書き込まれている。「Semantic Skill Selection (RAG Pattern)」と題されたセクションで、問題ははっきりと述べられている——「スキルが多すぎることは『コンテキスト・ロット』と意思決定疲れを引き起こす」。これはElasticがAIエージェントのコンテキストエンジニアリングについて公開している文章を引用したものだ。この文書が提案した解決策はリトリーバル(検索)パイプラインだった——すべてのスキルの説明文を埋め込みベクトルとしてインデックス化し、ユーザーのリクエストと意味的にマッチングさせ、「上位3〜5個の関連スキルのみを返す」というものだ。同じ文書はMuleSoftによる「エージェント型エンタープライズ」アーキテクチャの捉え方も引用しており、そこでは正式なスキルカタログとケイパビリティ・マーケットプレイスをファーストクラスのインフラとして持つべきだとされている。さらにAgent Skillsオープン標準そのものにも直接言及し、AgentKits自身のYAMLフロントマター付きSKILL.md形式がすでにこの標準と一致していると指摘していた。

だが実際に実装されたのは、その提案を縮小したバージョンだった。/skills:selectコマンドの実体であるcommands/skills/select.mdは、埋め込みモデルもベクトルストアも呼び出さない。その「選択アルゴリズム(Selection Algorithm)」は、手動のスコアリング方式によるキーワード・トリガー照合だ——完全一致のトリガーには1.0、部分一致には0.5、カテゴリー一致には0.3の重みを付け、その後dependencyGraphを深さ優先で辿って前提スキルを取り込み、最後に上限を課す——「コンテキストの過負荷を避けるため、最大5個のスキルまで」。このコマンド自身のフロントマターは使用可能なツールをReadとGrepの2つだけに制限している——スキル選択のプロセス全体は、エージェントがskills-registry.jsonとdependency-graph.mdを直接読み、その内容について推論することで進むのであって、そのために検索インフラを新たに立てるわけではない。調査文書が求めていたのはセマンティック検索だったが、実際にリポジトリにあるのは、どんな貢献者でも2つのMarkdownファイルを最初から最後まで読めば理解できる、文書化された監査可能なヒューリスティックに近いものだ。それでいて、レジストリが本来目指していたもの——境界のある、順序立った読み込み——は、埋め込みパイプラインなしに達成されている。

この問題は社内だけの話ではない

「コンテキスト・ロット」という言葉は、このプロジェクトが作った造語ではない。これはChromaが、GPT-4.1、Claude 4、Gemini 2.5、Qwen3を含む現行の18モデルが入力長の増大にどう反応するかを検証した、自社のテクニカルレポートに付けた名前だ(Chroma, “Context Rot: How Increasing Input Tokens Impacts LLM Performance”)。ここで重要な発見は、長い入力がそのまま失敗を引き起こすということではない。そうではなく、明示されたコンテキストウィンドウの上限にまったく達していない段階でも、検索のようなあえて単純化されたタスクにおいてさえ、入力長が伸びるにつれてモデルの性能が不均一かつ予測不能に劣化していく、という点だ。このレポートの結論——大きなコンテキストウィンドウは、そこに何を入れるかを注意深く選ぶことの代わりにはならない——は、AgentKitsのレジストリが自らの「スキル5個」という上限について挙げている根拠と、ほぼ同じものだ。しかも両者はおよそ1年の隔たりを置いて、互いに独立にたどり着いている。

同じ発想は、いまでは一企業内のローカルルールというより、業界標準そのものになりつつある。Anthropicが2025年10月に開発者向け機能として公開し、その後オープン標準として発表したAgent Skillsも、名前は違えど同じ形のトレードオフの上に組み立てられている——プログレッシブ・ディスクロージャー(段階的開示)だ。この標準についての報道は、3つの段階を説明している——発見(discovery)の段階では、エージェントはスキルの名前と短い説明文だけを目にする。起動(activation)の段階では、マッチしたタスクが完全な指示内容をコンテキストに引き込む。実行(execution)の段階では、付随するスクリプトや参照ファイルは、実際にその作業で必要になったときにだけ読み込まれる——こうすることで、巨大なスキルライブラリを抱えていても、実際に関連するものが現れるまではごくわずかなコンテキストしか消費しない(Anthropic, “Equipping agents for the real world with Agent Skills”)。AgentKits自身のSKILL.md形式は、レジストリが存在するより前からすでにこの形に合致していた——だからこそ、あの改善提案の調査文書はファイル形式自体を変える提案はせず、オープン標準との一致をただ指摘するだけで済んだのだろう。

これで得られるもの、得られないもの

AgentKitsのスキルシステムが今実際にどう作られているかを正直に言い表すなら——本来セマンティック検索が担うはずだった役割を、キーワードと依存関係によるヒューリスティックが代わりに担っている、そしてそれは、業界自身の研究がいまや仮説ではなく現実の制約として扱っている、コンテキスト予算の制約に応えるためのものだ、ということになる。これは技術的に可能な中で最も洗練されたスキル選択の形ではない——2月1日付のあの調査文書自体、埋め込みベースのマッチングを、まだ手をつけていない、より工数のかかる作業として挙げたままにしている。しかしこれは、読んで理解できる形であり、エージェントがすでに持っているツールの上で動く形であり、そして「どうやって5個を選ぶか」よりも「28個ではなく5個である」という1つの数字の方が実は重要だ、というコンテキスト・ロット研究の指摘を、確実に強制する形になっている。

---

AgentKitsはオープンソースであり、MITライセンスの下で永久に無料だ。スキルレジストリと選択アルゴリズムはagentkits-marketingリポジトリで自分の目で確認できる。今後の展開はagentkits.netで追うか、[email protected]まで連絡してほしい。