論文解説: Repo-To-Skill — GitHubリポジトリを「AIのためのスキル」に蒸留する

モデルでもハーネスでもない第三の層「運用知識」を、1000本のGitHubリポジトリから5,353個の検証済みスキルへ蒸留する DisCo と AREX-Skill ライブラリ。MLE-bench 31.11%→72.89% という結果と、その内訳・効かなかった場合を一次資料から読み解く。

Repo-To-Skill: Distilling GitHub Repositories Into AI4AI Skills

「方法を知っている」と「動かせる」は別物

配属初日のエンジニアを思い浮かべてください。教科書は読んでいるしアルゴリズムも説明できる。それでも初日は何も動かせません。社内のどのライブラリを使うのか、そのAPIがどんな形のデータを期待するのか、どの設定にすると学習が静かに壊れるのかを知らないからです。先輩が横から「それ、そのままだと落ちるよ」と一言添える、あの知識。教科書に載っていないのに成果の大半を決めています。

この記事で扱う論文の原題は "Repo-To-Skill: Distilling GitHub Repositories Into AI4AI Skills"（arXiv:2609.02749、2026年9月2日公開、Beijing Academy of Artificial Intelligence ほか）。48ページ・3図の技術報告で、コードは github.com/VectorSpaceLab/AREX-Skill にあります。

要旨を日本語でまとめます。機械学習(ML)研究を端から端まで自動で回すエージェントは、これまで「モデル本体」と「計画・実行・記憶・検証を担うハーネス」の2部品で説明されてきました。しかしこの構成では、分野固有のノウハウがエージェントの外に置き去りになります。著者らはこの欠けた層を operational knowledge（運用知識）——「方法を知っていること」と「それを動かせること」を分ける知識——と名づけます。その知識は分野に無いのではなく、リポジトリや論文の中にあります。ただし人間の読者向けに書かれ、タスク実行中に丸ごと読むには大きすぎる。ならばあらかじめ小さく検証済みのスキルに蒸留しておけば、毎回ゼロから再発見せずに使い回せる。それを行うエージェントが DisCo です。蒸留はタスク非依存（広く使われるリポジトリを事前に凝縮する）とタスク指向（目の前の課題が要求するスキルをその場で作る）の2形態で走ります。前者を開かれたエコシステム全体に適用した結果が AREX-Skill ライブラリで、1,000本の広く使われるMLリポジトリから5,000超の検証済みスキルを蒸留し、20領域・178の能力ファミリに整理したものです。GPT-5.5 のバックボーン、研究ハーネス、下流の実行予算を固定したうえで、スキルを持つエージェントはスキル無しの同一エージェントより MLE-bench で134.3%、PaperBench で34.4%、FrontierCS で9.2%、PassNet で14.0% 高いスコアを出した、というのが論文の主張です。

モデルでもハーネスでもない、第三の層

論文はまず研究タスクを $\tau=(q,\mathcal{D},\mathcal{E},g)$ と形式化します(§2.1)。$q$ は問題文、$\mathcal{D}$ は一緒に渡されるデータや材料、$\mathcal{E}$ は作業環境（使えるツールと予算上限を含む）、$g$ は満たすべき目標。「何を、何を使って、どこで、どこまでやるか」の4点セットです。

これを自力で解くエージェントは従来 $\mathcal{A}=(M_{\theta},H)$ と書かれました。$M_{\theta}$ が理解・推論・計画・実行を担うLLM本体、$H$ がオーケストレーション・記憶・検証・反復改善を担うハーネスです。論文の指摘は、ML研究が専門性集約的で「どの手法とツールを、いつ、どう正しく使うか」を知らないと成功しないのに、この2部品のどちらもその専門性を運んでいない点にあります。バックボーンの事前知識は広いが固定されており、ハーネスは手順を制御するが分野の中身を供給しない(§2.2)。そこで第三項を足します。

この式が言っているのは要するに、エージェントを「頭（モデル）＋段取り（ハーネス）」の2点セットで数えるのをやめ、そこに着任時点で持っている現場の知識を第三の項として足す、ということです。増えたのは項が1つだけで、前の2つは書き換えていません。

$\mathcal{K}$ が運用知識で、エージェントに明示的な「作業文脈」として渡されます。行動選択は $a_{t}\sim\pi_{\theta}(a\mid\tau,h_{t},H,\mathcal{K})$ となり、履歴 $h_t$ とハーネスに加えて $\mathcal{K}$ が判断材料に入るだけ。制御ループは一切変えません。 著者らは「ハーネスはエージェントがどう研究するかを決め、運用知識は研究開始時点で何を知っているかを決める」と繰り返します(§1, §7)。

$\mathcal{K}$ が無いときの損失は2つ(§1)。タスク内では、パッケージの挙動を試行錯誤で推測するしかなく、設定ミスは予算を使い切ってから表面化する。タスク間では、そうして得た発見が再利用可能な文脈として残らない。同じ授業料を毎回払い直しているわけです。実際のライブラリでは、5,353個のスキル全部を文脈に載せるのではなく、タスクに近い枝だけをルータが引いてきます(§4.2)。この「近いものだけ手元に引く」感覚は下の図で体感できます。

スキルという器: 3層フォルダ

$\mathcal{K}$ の実体として論文が採用するのは Agent Skills 形式のスキルです(§3.1)。1つのスキルは3層で構成されます。

つまり1つのスキルは「表紙・資料棚・道具箱」の3点セットだ、ということです。表紙だけは必ず読まれ、資料棚と道具箱は必要になったときだけ開かれます。

SKILL.md は知識インターフェース。唯一「最初に読まれる」層で、何のためのもので、いつ当てはまり、どう進めるかを述べます（目標・主要概念・ツールの使い方・実例・既知の失敗モード）。references/ は知識基盤で、APIドキュメントやアルゴリズムの詳細など、必要になったときだけ開く深い材料。scripts/ は実行インターフェースで、入出力の定まった実行可能ラッパー。エージェントは再実装せず呼ぶだけで済みます。

この分割が効くのは、冒頭だけ読んで必要なものだけ開く（progressive disclosure、段階的開示）ため、数千個を保持しても文脈を圧迫しないからです。1つの情報源からは1スキルに収まらない量が出るので、同じ情報源のスキル群はスキルグラフ $\mathcal{G}=(\mathcal{S},\mathcal{L})$ として束ねられます。入口のエントリスキルが範囲を述べ、そこから各工程のコンポーネントスキルへリンクを張る。エージェントは入口を読み、必要なリンクだけ辿り、残りは開きません(§3.1)。