これは何の論文か
この論文は、LLMエージェントの「スキル」を、ただの自然言語メモではなく、検索や監査に使える構造として表すための研究である。
SKILL.md のような文書は、人間にもモデルにも読みやすい。一方で、使うべき条件、手順、分岐、制約、ツール呼び出し、触るリソース、副作用が同じ文章の中に混ざりやすい。スキルが少ないうちはそれでも読めるが、数が増えると「どのスキルを呼ぶべきか」「危ない操作を含むか」「似たスキルと何が違うか」が見えにくくなる。
そこで著者らは、Scheduling-Structural-Logical、略して SSL という表現を提案する。ざっくり言うと、スキルを三つの面に分ける。
- いつ呼ぶか
- どんな手順で進むか
- どの行動やリソース利用が起きるか
評価では、既存のスキル文書を LLM で SSL 表現へ変換し、スキル検索とリスク判定の二つで比べる。結果として、スキル検索の MRR は 0.573 から 0.707 に、リスク判定の macro F1 は 0.744 から 0.787 に改善した。
この論文の読みどころは、自然言語スキルを否定していない点にある。人間が読む本文は残しつつ、その上に機械が使える索引と監査面を重ねる。スキルが増えて腐っていく問題に対して、「もっと良い文章を書く」だけではなく「探せる、比べられる、危険を見つけられる形に分ける」という方向を示している。
何が問題だったのか
問題は、スキルが文章として読めることと、運用で使いやすいことが別物だという点である。
スキル検索では、名前や本文の近さだけでは足りない。「CSVを整形するスキル」と「公開前にCSV由来の表を検査するスキル」は、似た語を含んでいても使う場面が違う。逆に、言葉は違っても同じ呼び出し条件を持つスキルもある。
リスク確認でも同じである。本文のどこかに「外部APIを叩く」「ファイルを書き換える」「ユーザー承認が必要」と書いてあっても、それが手順説明に埋もれていると機械的に拾いにくい。
つまり、スキル文書には少なくとも二つの読み方がある。
- 人間が意図や背景を理解するための読み方
- エージェントや管理システムが、呼び出し・手順・副作用を判断するための読み方
この論文は後者を支える構造を作ろうとしている。
既存のスキル運用は、自然言語の説明、全文検索、埋め込み検索に寄りやすい。これらはスキルの候補を見つける入口としては有効だが、スキルの内部構造までは分けない。
また、従来の知識表現研究には、場面、行為、前提条件を構造化する考え方がある。著者らは、Schank and Abelson のスクリプト理論や概念依存表現を参照しながら、それを現代の LLM エージェントスキルに接続する。
足りなかったのは、スキルを「便利な文章」としてではなく、「いつ呼び、どう実行し、何に触るかを持つ操作単位」として扱う表現である。
提案手法の中身
入力は、自然言語で書かれたスキル文書である。論文はそこから SSL 表現を作る。
Scheduling は、そのスキルをいつ呼ぶべきかを表す。対象になるタスク、ユーザーの意図、環境条件、前提、呼び出してはいけない条件をここに寄せる。
Structural は、実行の流れを表す。手順、分岐、小さな目標、途中で確認すべき状態などを扱う。
Logical は、具体的な行動やリソース利用を表す。どのツールを呼ぶか、どのファイルや外部サービスに触るか、どんな副作用や制約があるかを分けて取り出す。
この三層を、人間がすべて手で書くのではなく、LLM を使って既存スキル文書から抽出する。抽出された構造は、スキル検索やリスク判定に使われる。
どうやって確かめたのか
評価は二つのタスクで行われる。使われるコーパスは、6,184 件のスキル、403 件のタスク問い合わせ、500 件のリスクラベル付きスキルである。
一つ目はスキル検索である。与えられたタスクに対して、どのスキルが適切かを見つける。比較対象は、自然言語本文だけを使う検索と、構造化されたスキル表現を使う検索である。
二つ目はリスク判定である。スキルがどのリソースに触り、どんな危険や制約を持つかを判定する。測る指標は、検索精度、リスク分類の正確さ、本文だけでは見落とす権限や副作用を拾えるかである。
結果はどうだったのか
スキル検索
SSL 表現を使うと、MRR が 0.573 から 0.707 に改善した。呼び出し条件や実行構造を分けておくことで、本文全体の近さだけに頼るより適切なスキルを見つけやすくなる。
リスク判定
macro F1 は 0.744 から 0.787 に改善した。ツール呼び出し、リソース利用、副作用、制約が構造として分かれている方が、危ないスキルを見つけやすい。
実務上の意味
SSL は、エージェントスキルの最終標準ではない。自然言語スキルを、検索しやすく、監査しやすく、運用に乗せやすくするための中間表現として読むのがよい。
限界・注意点
- SSL はスキル管理の完成形ではない。スキルの作成、重複統合、廃止、更新判断まで全部を自動化するものではなく、スキル文書を扱いやすくする表現である。
- LLM による抽出に依存するため、作られた構造が常に正しいとは限らない。本文が曖昧だったり、副作用が暗黙だったりすると、SSL も不完全になる。
- 評価はスキル検索とリスク判定に絞られている。実際のエージェントがそのスキルを使ってタスク成功率を上げるか、スキル台帳を長期運用できるかまでは直接見ていない。
- 自然言語スキルの強みは残る。人間が読み、修正し、文脈を補えることは重要なので、SSL は SKILL.md を捨てる話ではなく、本文の上に機械が読める構造を重ねる話として読むのがよい。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントでは、スキルが増えるほど「どれをいつ使うか」「どれが危ないか」「どれが古いか」が問題になる。
この論文を使うなら、スキル本文とは別に、呼び出し条件、必要な権限、触るリソース、副作用、検証方法、最終レビュー日を持たせる設計が考えられる。そうすると、スキル検索だけでなく、危険な操作を含むスキルの承認、古いスキルの見直し、似たスキルの統合にも使える。
注意点は、構造を足せば自動で運用が良くなるわけではないこと。抽出された構造を信じすぎず、危険な副作用や外部公開に関わるスキルでは、人間の確認やテストと組み合わせる必要がある。
Q&A
この論文の中心問いは？
自然言語中心のエージェントスキル成果物を、検索や risk review に使いやすい構造としてどう表現するか。
なぜスキル text だけでは足りないの？
呼び出し条件、実行手順、制約、ツール呼び出し、リソース利用、副作用が同じ文章面に混ざり、スキル検索やリスク判定で必要な証拠を取り出しにくいから。
SSL とは？
Scheduling-Structural-Logical の略。エージェントスキルを、呼び出し信号、実行構造、行動 / リソース利用 証拠の三層に分ける表現である。
Scheduling layer は何を見る？
そのスキルをいつ呼ぶべきか、どんなタスク、ユーザー意図、環境条件が呼び出し条件になるかを見る。
Structural layer は何を見る？
スキルがどんな場面、手順、分岐、小さな目標、制御の流れを持つかを見る。
Logical layer は何を見る？
具体的な行動、ツール呼び出し、リソース利用、制約、副作用のような、監査や実行に効く証拠を見る。
評価結果は？
スキル Discoveryの MRRは 0.573から 0.707に、Risk Assessmentの macro F1は 0.744から 0.787 に改善した。
この論文は SKILL.md を捨てる話？
違う。自然言語スキルの読みやすさを残しつつ、その上に 機械可読 な index、構造、リスク面 を重ねる話である。
記憶とスキルの劣化 とどうつながる？
スキル台帳が増えるほど、検索、リスク確認、重複統合、古さの管理が難しくなる。SSLは、その劣化を防ぐための構造化されたスキル表現として読める。
一言でいうと？
エージェントスキルは読めるだけでは足りない。呼び出し、構造、副作用を分けて、探せて監査できる形にする必要がある。
関連する記事
- この論文は、SKILL.md のような自然言語スキルを否定するものではなく、自然言語本文に構造化された索引と監査面を足す話として読むとよい。
- 関連して、反実仮想トレースでエージェントを監査する と並べると、スキルを構造化する話と、実行トレース上でスキルの影響を監査する話がつながる。
- スキルの維持・退役・拡張を管理する と並べると、スキルを retain、退役、expand するライフサイクルと、SSL のようなスキルメタデータがどう接続できるかを考えやすい。
- 実務に引くなら、既存スキルに呼び出し条件、リソース利用、副作用、リスク分類、最終レビュー日を持たせる設計から試すのが近い。