この論文は、複雑な作業をこなすためにエージェントが使う「スキル」をどのように選んで組み合わせるかを自動で決める方法を示します。ここでいうスキルは、手順や説明、補助コードなどをまとめた再利用可能なモジュールです。研究者たちは、どのスキルを使うか、何個使うか、どの順番で実行するかの三点は切り離せないと指摘し、それらを同時に予測する枠組みを提案しました。提案手法はSkillComposerと呼ばれます。LLMは大規模言語モデルの略です。

研究チームは問題を「タスクに条件付けられたスキル列の予測」として定式化しました。SkillComposerはライブラリ中のスキル識別子を語彙として受け取り、制約付きの逐次生成（オートレグレッシブ）で有効なスキル列を一つずつ出力します。これにより、使うスキルの集合（どれを選ぶか）、必要な数（何個使うか）、実行順序（どの順で使うか）が一回の生成で同時に決まります。出力語彙は実際に実行可能なスキル識別子だけなので、生成結果はそのまま下流のエージェントに読み込ませられます。

学習データは実際の人手で管理されたスキルライブラリから作られました。研究者はスキルのメタデータと観察されたワークフローの共起からスキル依存グラフを構築し、層状の合成とフィルタリングで単一スキルと複数スキルの両方に対する教師データを得ています。論文中の例ではスキルライブラリの大きさはK=196で、具体的な予測列として(s104,s184,s55)のような順序が示されています。各スキルは名前、適用条件、手順方針、終了条件、外部インターフェースの有無といった要素を持ちます。

評価は二面で行われました。一つは保持した検証データ上での構成（組合せ）品質の評価。もう一つは下流タスクの成功率で、ベンチマークはSkillsBenchです。実験は二つの実用的なコーディング用エージェント（GPT-5.2-CodexとGemini-3-Pro-Preview）で行われ、SkillComposerは「スキルを使わない」基準と比べて合格率をそれぞれ+23.1ポイント、+18.2ポイント向上させました。さらに上位3件の単純な検索（top-3 retrieval）を超え、最高のスキル検索上限（gold-skill retrieval）に匹敵する性能をより少ないプロンプト・トークンで達成したと報告しています。

この研究が重要な理由は、スキルライブラリが大きくなると「どのスキルをどう組むか」が実行時のボトルネックになる点を扱っていることです。SkillComposerはスキル間の依存を自然にとらえ、計画を可視化できるシーケンスとして出すため、実際のエージェント運用で効率化やデバッグの助けになります。

ただしいくつか注意点があります。論文は「与えられた人手で整備されたスキルライブラリ」を前提にしています。スキルはAPIのような型付きの署名を持たないため、依存関係は明示的でなく論理的に潜在している点があり、この粒度の違いは設計上の難しさを生みます。また、評価はSkillsBench上と二種類のコーディングエージェントに限定されているため、他のタスク領域やより大規模なライブラリでの一般化については追加検証が必要です。論文では長尾（ロングテール）スキルや依存性を考慮したデータ構築を試みていますが、実運用での網羅性はケースによって変わる可能性があります。