論文解説: FACET — 指示・環境・解答・採点を「同じ実行状態」に接地させる課題合成

ターミナル課題は「指示文・環境・模範解答・採点器」の4点セット。FACETは環境を先に建てて動かし、その実現済み状態を全部品の共通の地面にすることで整合を取る。7万件のスキルから6,078課題を作り、1.2Kの成功軌跡だけでQwen3.5を4B/9B/27Bとも底上げした論文を1から解説する。

FACET: Preserving Source Intent and Executable State in Terminal Task Synthesis

比喩: 教習所のコースを1つ作る

AIエージェントに「ターミナル作業」を仕込むには練習問題が要ります。ところがこの練習問題は、文章を1つ書けば済むものではありません。論文は、1件のターミナル課題が 指示文・初期化された環境・模範解答・実行可能な採点器 という束であり、これらが食い違った前提から生成されると「解けない課題」や「誤って採点される課題」になると述べます（§1）。

自動車教習所のコースに例えると分かりやすいでしょう。「S字を抜けて縦列駐車せよ」という指示、パイロンと白線が引かれたコース（初期環境）、教官が実際に走って見せる模範走行、そして輪留めへの接触を機械で測る採点。この4つはどれか1つがズレただけで破綻します。コースにS字が引かれていなければ指示は実行不能ですし、採点器が存在しない縁石を見ていれば、正しく走っても不合格になる。しかも厄介なことに、コース設営を少し直すと模範走行も採点基準も連動して直さねばならない。

FACET（Fine-grained Agentic Construction of Executable Tasks）は、この4点セットを矛盾なく大量生産するための枠組みです。中国科学技術大学・上海AI Lab・復旦大学らのグループが2026年8月に公開しました。

何が壊れるのか: 情報の目減りと、部品どうしのズレ

論文は、多段生成で起きる問題を2つに切り分けます（§1）。

1つ目は情報の目減りです。元の材料には、必要な能力、依存関係、途中の状態、入出力の契約、手順上の制約が書き込まれている。ところが生成の段を重ねるたびにそれが「短い課題説明」へ圧縮され、合成された課題には元の構造と複雑さの一部しか残らない、と論文は指摘します。

2つ目は部品の乖離です。指示が環境に実在しないファイルを指す、解答が別のスキーマや依存を前提にする、採点器がそもそも到達できない状態を検査する。段階間で「テキストの仕様書」を受け渡せば多少は緩和できますが、それだけでは全部品が同じ実現済みの実行状態に接地している保証にはならない（§1）。この2点が、FACETが解こうとしている的です。

材料: 7万件のスキルから「場面」を復元する

出発点は既存の「エージェントスキル」パッケージです。OpenClaw、ClawHub、GitHubから収集し、危険な指示を含むもの、非公開の情報や資源に依存するもの、読めない・実行できない・重複するものを除いて 71,341件の有効スキルを残します（§2.2、付録A.1）。5つの大分類と34の細分類に整理されており、内訳は「マルチメディア・制作・出版」24.42%、「AI・エージェント・ツール」21.28%、「ソフトウェア・システム・セキュリティ」21.11% などです。

特徴的なのはここからです。1スキルを1課題へ直訳するのではなく、抽出エージェントが各スキルについて「どんな場面で使われうるか、ユーザの目的は何か、初期状態と望ましい最終状態は何か」というシナリオ仮説を立てる。そしてその仮説を埋め込みベクトルにし、他のスキルの仮説から近いものを検索して、組み合わせられそうなスキル群を見つけます（§2.2）。近い仮説を束ねて「1つの場面＋関連スキル群」という候補 $p_c=(c, X_c)$ を作り、モデル審査が「関連しているか・補い合うか・冗長でないか・ターミナルの作業手順として実行可能か」を判定して合格分だけを残す。

仕組み: 先に環境を建て、その状態を共通の地面にする

論文の中心的な主張は、部品を作る順番と接地先にあります。まず記号を整理しましょう。合成したい課題の束は次のように書けます（§2.1）。

つまりこの式は「1件の課題とは文章1つではなく、依頼文・舞台・お手本・採点機械・実行時の設定という5点で1セットだ」と宣言しているだけのものです。5つを並べて書くこと自体が、どれか1つを別々に作ってはいけないという主張になっています。

$\mathcal{I}$ はユーザへの指示文、$\mathcal{E}$ は環境の仕様、$\mathcal{S}$ は模範解答、$\mathcal{V}$ は実行可能な採点器、$\mathcal{M}$ は実行時メタデータです。環境を初期化した状態を $e_0$、模範解答を走らせ終えた状態を $e_T$（失敗なら $\bot$）と書くと、課題が採用される条件は次のようになります。

要するに、採点器は解く前には落ち、解いた後には通るものでなければならない、と言っています。$\land$ は「かつ」、$\neg$ は「〜ではない」の記号なので、読み下すと「①環境がビルドできる、かつ②何もしていない初期状態では採点が落ちる、かつ③模範解答が最後まで走り切る、かつ④走り終えた状態では採点が通る」。この4つが同時に真のときだけ採用します。②が入っているのが要点で、これが無いと「最初から合格している課題」＝タダで点が入る不良問題が混ざります。

そのうえでFACETは、課題文より先に環境を建てて動かす（§2.4）。環境エージェントはまず必要なディレクトリ・ファイル・サービス・依存関係を並べた「マニフェスト」を書き、それから中身を実体化します。公開資源を取ってきて整形したり、テキストやバイナリを手続き的に生成したりしてよいが、取得した資源はビルド時にローカルへ取り込む。評価時にネットワークを必要としない自己完結した環境にするためです。さらに、テンプレ然とした薄い題材を避けるため、スキーマと課題の意味を保ったままレコードを増やしたり、メタデータ欄・おとり項目・ファイル間の関連を足したりします。

ビルドと初期化チェックに失敗したら、失敗トレースを環境エージェントへ返して最大3回まで修理します。このとき修理の入力には失敗トレースだけでなく再構成済み仕様も与える。そうしないと、エージェントは「ビルドを通すために要件そのものを削る」という近道を選んでしまうからです（§2.4）。