何が起きたか
Alibabaの研究チームが、多数のツールを扱うAIエージェントの「ツール選択」問題に取り組むフレームワークSkillWeaverを発表しました。従来のように全ツールをプロンプトに詰め込むのではなく、タスクを分解して必要な「スキル」だけを組み合わせる「compositional skill routing(構成的スキルルーティング)」という考え方を採用しています。
処理は3段階で進みます。まずDecomposeでLLMがユーザーの複合的な要求をサブタスクに分解し、次にRetrieveでMiniLMとFAISSによるベクトル検索が候補ツールを絞り込み、最後にComposeでプランナーが入出力の整合性を検証し、依存関係を表すDAG(有向非巡回グラフ)として実行計画を組み立てます。並列実行可能な処理は同時に走らせる設計です。
なぜ重要か
SkillWeaverの核心は、**Skill-Aware Decomposition(SAD)**というフィードバックループにあります。LLMが暫定的なプランを立て、それをもとに予備検索で近そうなスキルを探し、その結果を「ヒント」としてもう一度分解をやり直す仕組みです。この一手間で、Qwen2.5-7Bモデルの分解精度は51.0%から67.7%へ、Qwen-Maxでは92%へと跳ね上がりました。特に4〜5個のスキルを組み合わせる難タスクでは精度が50%改善しています。
興味深いのは、14BモデルがSADなしでは7Bモデルより精度が下がった事実です。大きなモデルほどタスクを微細に分割しすぎ、「過剰分解」に陥る傾向があり、SADのフィードバックがそれを現実的な粒度に引き戻したのです。
MCPエコシステムとの関係
評価ベンチマークCompSkillBenchは、Model Context Protocol(MCP)の公開エコシステムから集めた24カテゴリ・2,209個の実在ツールと、300件の複合クエリで構成されています。MCP経由でツール数が爆発的に増えつつある現状において、SkillWeaverの「必要な分だけ渡す」アプローチは実務的な意味を持ちます。全ツール名を投げるLLM-Directでは、Qwen-Maxでも正しいカテゴリの検索成功率はわずか21.1%。ReAct方式に至っては複合タスクの分解精度が0%でした。
実装上の注意
ソースコードは未公開ですが、all-MiniLM-L6-v2やLangChain、LlamaIndexなど既存の部品で再現可能です。2,209スキルの埋め込み・インデックス化は15秒、クエリあたりの検索遅延は15ミリ秒未満と軽量です。ただし、上位10候補に正解が入る確率は約70%でも、1位に正解が来る確率は約37%にとどまるため、cross-encoderなどによる再ランキングが実用上ほぼ必須です。もう一つの制約はエラー回復機構がないこと。途中でAPI呼び出しが失敗すると連鎖全体が壊れるため、フォールバックとリトライは自前で組み込む必要があります。
💼 事業会社視点：これは自社にどう効くか
事業責任者はどう読むべきか
MCP対応が進むSaaSや社内ツール統合を進める日本の事業会社にとって、SkillWeaverは「AIエージェントのコスト構造」を根本から変える示唆を含みます。
受託開発・SIerにとっては、顧客のSaaS群(Salesforce、kintone、Slack、社内DBなど)を横断するAIエージェントを提案する際、「全ツールをプロンプトに載せる素朴実装」がいかに非効率かを数字で示せる材料になります。88.4万トークン→1,160トークンという99.9%削減は、月額のAPI課金で桁違いの差になり、PoCから本番運用への移行判断を左右します。
自社でAIエージェントを開発するSaaS事業者は、ツール数が20を超え始めた段階でSkillWeaver型の設計に切り替える判断基準を持つべきです。特にQwen2.5-7Bのような小型モデルでも67.7%の精度が出た点は重要で、GPT-4クラスに頼らずコストを抑える設計余地が広がります。
経営者が今動くべきことは3つ。(1)自社の生成AI基盤で「ツールを全部プロンプトに詰めている」実装がないか棚卸しする、(2)MCP対応をロードマップに載せているベンダーの設計思想を、この論文の3段階アーキテクチャで問い直す、(3)エラー回復機構は自前実装が必要なため、AIエージェントのSLA設計を運用チームと今から詰めておく——ここまで踏み込めば、来年のエージェント本格投入で先行できます。