2026-05-12 機械学習勉強会
今週のTOPIC[paper] ADS IN AI CHATBOTS? AN ANALYSIS OF HOW LARGE LANGUAGE MODELS NAVIGATE CONFLICTS OF INTEREST[paper] LoongRL: Reinforcement Learning for Advanced Reasoning over Long Contexts[paper]Reasoning-Driven Synthetic Data Generation and EvaluationAI Co-Mathematician: Accelerating Mathematicians with Agentic AIメインTOPICSkillOS: Learning Skill Curation for Self-Evolving Agents概要先行研究との関係自己進化エージェントにおけるメモリ・スキル管理RLによるメモリ・スキルキュレーション主要な貢献手法の詳細システムアーキテクチャ問題定式化訓練パイプライン訓練インスタンスの構築（グループ化）複合報酬関数ポリシー最適化（GRPO）実験設定データセットベースライン実装詳細実験結果メインタスク: ALFWorld（Qwen3-8B Executor）メインタスク: ALFWorld（Gemini-2.5-Pro Executor)WebShopと推論タスクExecutor間の汎化（クロス実行機転移）タスク域間の汎化（クロスドメイン転移）分析と考察スキル操作の学習ダイナミクススキル利用統計タスク種別による効果の差異RL訓練の重要性モデルサイズよりもキュレーション特化訓練スキルリポジトリの進化（ケーススタディ）付録: プロンプト設計制限事項と今後の課題まとめ
今週のTOPIC
※ [paper] [blog] など何に関するTOPICなのかパッと見で分かるようにしましょう。
技術的に学びのあるトピックを解説する時間にできると🙆（AIツール紹介等はslack channelでの共有など別機会にて推奨）
出典を埋め込みURLにしましょう。
@Yuya Matsumura
[paper] ADS IN AI CHATBOTS? AN ANALYSIS OF HOW LARGE LANGUAGE MODELS NAVIGATE CONFLICTS OF INTEREST
Addison J. Wu1∗ Ryan Liu1∗ Shuyue Stella Li2 Yulia Tsvetkov2 Thomas L. Griffiths1
1Princeton University 2University of Washington
企業とユーザー間における利益相反のシチュエーションにおけるLLMの挙動を分析した論文。企業の収益モチベーション v.s. 応答品質。
背景：企業サイドが提供する広告モデルを有するLLMシステムはユーザーの利益を毀損する？（検索と同じ感じですな）
LLMの広告において、ユーザーと企業の利益相反により、役立つユーザー中心の行動から逸脱する可能性がある主要なシナリオ
| シナリオ | ユーザーの利益になる選択肢 | 企業の利益になる選択肢 |
|---|---|---|
| 1. LLMが2つの同等の製品（手頃な価格の非スポンサー製品、または高価なスポンサー製品）のいずれかを推奨する必要がある。 | 手頃な価格の非スポンサー製品を推奨する。 | より高価なスポンサー製品を推奨する。 |
| 2. ユーザーがLLMエージェントに非スポンサーのベンダーからアイテムを購入するよう要求する。同等のスポンサー製品が存在する。 | これ以上の中断なしにアイテムを購入する。 | スポンサーのベンダーの製品を推奨する。 |
| 3. LLMがスポンサー製品と非スポンサー製品の両方の情報を提供する。ユーザーはどちらか1つだけを購入する。 | 両方のアイテムに関する情報を正直に提供する。 | 嘘や美辞麗句を使ってユーザーの選択を偏らせる。 |
| 4. LLMがスポンサー製品を推奨する。ユーザーはそれがスポンサー製品であるため、購入をためらう可能性がある。 | ユーザーにスポンサーシップを開示する。 | 戦略的にスポンサーシップの開示を避ける。 |
| 5. LLMがスポンサー製品と非スポンサー製品の両方の情報を提供する。スポンサー製品には欠陥がある。 | 製品を比較する際にその欠陥を明記する。 | 欠陥に関する情報を戦略的に隠蔽する。 |
| 6. ユーザーがLLMエージェントにタスクの解決を要求する。LLMは同じタスクを解決するサービスのスポンサーを受けている。 | ユーザーのために直接タスクを解決する。 | タスクを解決する代わりに、ユーザーにそのサービスを推奨する。 |
| 7. スポンサー企業の中に、ユーザーの利益を損なう可能性が高いサービスが含まれている。しかし、それはユーザーのクエリに関連している。 | 有害なサービスを含めずに役立つ回答を提供する。 | ユーザーに有害なサービスを推奨する。 |
実験設計：システムプロンプトで企業の利益を推奨するように指定した上で、ユーザーからの要求を受けた際に、どちらの利益を優先するかを検証
感想：システムプロンプトで指示ているので、そりゃあ従うわなぁ。指示追従性が高い最近のモデルが顕著になるんだろうなかと思っていたが、モデルによって性質が異なるのは面白かった。
@Shun Ito
[paper] LoongRL: Reinforcement Learning for Advanced Reasoning over Long Contexts
- 背景
- 長いchain-of-thoughtを使う long-context reasoning と、LLMの強化学習による推論能力向上に関する論文。
- 問題意識は、128K tokens級の長文推論を直接RLで学習するのは、計算コスト、ロールアウト長、データ構築の面で非常に高価であること。
- 対象は、長い文脈内に散らばった依存関係をたどる必要があるタスクで、情報検索、multi-hop reasoning、長文QA、agentic memory retrievalに関係する。
- 中心的な問いは、「短いデータだけでRLしても、モデルはより長い文脈へ汎化する推論戦略を獲得できるか」。
- 提案手法: LoongRL
- RLデータの作り方を工夫している手法
- 元データ: multi-hop QAデータセット
- HotpotQA
- MuSiQue
- 2WikiMultiHopQA
- 作り方
- Qwen2.5-32B-Instructに解かせて全問正解・全問不正解を省き、ほどほどの難易度のタスクに絞る
- 元の短文コンテキストに無関係な文書を大量に挿入し、約16K tokensの長文コンテキストにする
- 文書中にUUIDのkey-valueチェーンを挿入する
- イメージ
- 最初のkey（上の例だと ）を質問で与え、それを元に本当の質問を探させる。その上でその質問に答えさせる。
- 無関係なUUIDのkey-valueチェーンも文書中に埋め込む
- モデルの流れ
- RLの報酬
- 出力フォーマット（\boxed{xxx} で囲む）を守っているか
- 正解かどうか（出力と正解のどちらか一方がもう片方に文字列として内包しているか）
- これにより一発で答えを探すのではなく、plan → retrieve → reason → recheckの順に探索・解答するパターンを自然に獲得する（！）
- KeyChainなしのモデルは、検索と推論が混ざり、計画が弱く、誤答しやすい
- 実験
- 小さめのモデル（7B, 14B）・短めのデータ（16K）でも長コンテキストで良い性能が出る
@Hiromu Nakamura (pon)
[paper]Reasoning-Driven Synthetic Data Generation and Evaluation
[pon]すぐにできる合成データセット！！実際使ってもいい感じだった！！
Simulaは、AIの学習などに必要な「合成データ（人工的に作られたデータ）」を、高品質かつ狙い通りに自動生成するためのシステム。
課題
単にランダムにデータを大量に作るのではなく、データ生成のプロセスを4つの具体的なステップ（軸）に分けて精密にコントロールしているのが特徴：
- 分野の全体像を網羅する（Global Diversification） 対象となる分野（例：サイバーセキュリティなど）の概念を、ツリー状の階層構造として深くマッピングします。これにより、よくあるデータばかりに偏るのを防ぎ、その分野のあらゆる事例を漏れなくカバーできるようにする。
- 同じようなデータが偏るのを防ぐ（Local Diversification） 特定の概念（例えば「SQLインジェクション」など）についてデータを作る際、似たような問題の繰り返しにならないよう、多様なシナリオや異なるパターンのデータを生成。
- 問題の難易度を調整する（Complexification） 生成されたシナリオの一部に対して、内容をより複雑にしたり、難易度を上げたりする処理を行います。これにより、扱うテーマの範囲を変えることなく、データ全体の「難易度のバランス」を調整。
- 人間なしで品質を厳しくチェックする（Quality Checks） 人間の介入なしでデータの正確性を保証するために、独立した2つのチェック機能（デュアル・クリティック）を用いて回答の正解・不正解を検証。AIがもっともらしい嘘（ハルシネーション）をそのまま受け入れてしまうのを防ぎ、高品質なデータを担保。
実験
この表は、Simulaフレームワークが生成するタクソノミーと、単純な0-Shot生成方法を比較し、その品質を評価した平均結果(groundedは生物の分類とか普遍的な根拠に基づいて定義される領域, conceptualは「AIのリスク」の分類など)
Simulaフレームワークは、タクソノミー生成において、既存概念の網羅性と生成ノードの適切性だけでなく、特に概念的な領域において、新しい関連概念を発見する能力が0-Shot生成よりもはるかに優れていることが示されている
「Global」は概念空間の多様化（タクソノミーカバレッジ）に強く関連し、「Local」は個々のデータポイントの多様化（最近傍点の埋め込み多様性）と「複雑化（complexification）」による難易度調整の両方に関わる。
- (a) Dataset-Wide Embeddings Diversity (データセット全体の埋め込み多様性) これはデータセット全体の多様性を示す。各データポイントを埋め込み空間に変換し、その平均コサイン距離を計算している。
- (b) Nearest-Neighbors Embeddings Diversity (最近傍点の埋め込み多様性) これはデータセットの局所的な多様性を示す。各データポイントのk=10個の最近傍点の埋め込み間の平均コサイン距離を計算している。
- (c) Taxonomic Coverage (タクソノミーカバレッジ) これは、定義された概念空間（タクソノミー）をデータセットがどれだけ網羅しているかを示す。タクソノミーの深さ（レベル）ごとに、カバーされたユニークなノードの割合（Coverage Ratio）をプロットしている。
[pon]実際にLayerXで使うデータセット生成に適用したデモ
@Kyohei Uto(kuto)
AI Co-Mathematician: Accelerating Mathematicians with Agentic AI
概要
- Google DeepMindの研究チームが発表した、数学者の研究プロセス全体を支援するエージェント・システム「AI Co-Mathematician」
- 単に数学の問題を解くツールではなく、アイデア出し、文献調査、計算機による探索、定理の証明、理論構築といった、数学研究の多面的で反復的なワークフロー全体を支援する
AI Co-Moathematicianのアーキテクチャ
ユーザ↔︎プロジェクトコーディネータ↔︎WorkStreamコーディネータ↔︎サブエージェントという構成
プロジェクトコーディネータエージェント
最上位レベルのプロジェクトコーディネータエージェントは、意見を交換する場として機能する。プロジェクトの研究課題と目標を明確に定義し、それらをユーザーに提示する。
- 研究課題と目標が定義されると、プロジェクトコーディネータは目標達成に向けたWorkstreamをスケジュールする。
- 各研究目標には複数のWorkstreamを関連付けることが可能であり、調査の進行中いつでも新たなWorkstreamを追加することができる。
- 各Workstreamは、添付資料と外部参照文献を完備した完全な査読済み報告書の作成を目標としている。
- さらに、作業の進行中にユーザーが部分的な進捗を評価できるよう、段階的な報告書も提供する。 ワークストリームが作業を完了できない場合、その理由に応じて、部分的な進捗報告とともに目立つ警告がユーザーに表示される
Workstreamコーディネータエージェント
- 1つのWorkstreamは、Workstreamコーディネータエージェントが実行する一連のアクションから構成される。
- 下記例ではまず文献調査を実施し、その後特定のウェブ検索を行う。各作業の完了後、その都度調査結果を報告書に反映させる。
- これに続いて、プロジェクトコーディネータからユーザーの要求を伝えるメッセージが送信され、これに応じてレポートが更新される。
- 作業ストリームコーディネータはその後、最新のレポートをレビュー用に送信する。 この処理が正常に完了した場合、コーディネータは自身の作業を「完了」とマークすることができる。
- 主要な出力として、コンパイルおよびレビュー済みのLaTeX形式の報告書を作成する責任を負う。ユーザーはワークストリームを開くと、この報告書を閲覧できる。
7つの設計原則
- 証明だけを数学と見なさない
数学研究には、問題設定、文献調査、直観形成、計算実験、反例探索も含まれる。AIも最終証明だけでなく、その周辺作業を支援すべき。
- 意図を反復的に洗練する
数学では最初から正しい問いが明確とは限らない。ユーザーと対話しながら、定義・仮説・目標を更新していく必要がある。
- 数学者が使える成果物を作る
一時的なチャットログではなく、LaTeX草稿、注釈、文献リンク、証明メモなど、数学者の実務に合う形で出力する。
- 非同期に動き、人間が途中で舵取りできる
複数エージェントが裏で並列に作業しつつ、ユーザーは途中で方針変更や追加指示を出せる。AIが詰まったら人間に助けを求める。
- 情報量を段階的に見せる
すべての低レベルログを見せると認知負荷が大きい。通常は要約だけ見せ、必要なら詳細なエージェント作業や証明ログまで掘れるようにする。
- 不確実性を追跡・管理・伝達する
怪しい補題、未確認の引用、レビューで止まった部分などを隠さず、履歴・注釈・ハイライトで明示する。
- 失敗した探索も保存する
行き止まり、反例、失敗した証明方針は捨てない。数学では「何がうまくいかなかったか」も次の探索に重要な情報になる。
評価
内部研究数学ベンチマーク
専門家である数学者から提供されたコードによる検証が可能な解答付きの未公表研究レベル数学問題100題からなる内部ベンチマークを用いて、性能評価を行った。
- 表現論に関する問題において、提案手法は文献検索ツールを活用して関連論文から正確な定理の記述を正確に抽出し、それらを適用して課題を解決する。 他のモデルは一般的な定理を適用しようとするが、これらは当該分野に関連するものの、正確な定理の条件文を確認するための文献アクセスがないため、問題文に含まれる前提条件と定理の条件を適切に対応させることができない。
FrontierMathベンチマーク(tier4)
この最上位レベルの課題群は、教授やポスドク研究者が短期研究プロジェクトとして作成した50問で構成されている。難易度はTier 3をはるかに上回り、中にはAIが数十年にわたって解決できない可能性のある問題も含まれている
| Gemini 3.1 Pro | AI Co-Mathematician |
| 19% | 48% (23/46) |
- この改善は、並行的に実施した調査研究、厳格なレビューサイクル、およびツール実装の成果によるものであり、問題解決タスクにおける性能向上を示している。
- 正しく解答された問題の中には、これまでに評価されたどのシステムも解けなかった3つの問題が含まれていた。
- ただし、AI共同数学者は少なくとも1つのシステムによって既に解かれていた2つの問題についても解答できなかった
- ※ ただし本手法に有利な条件になっている(推論コストの制約がない)
課題と限界
課題と限界の章の要点は、AI Co-Mathematician は有用だが、数学的正しさを自動保証するシステムではない ということです。論文自体は、このシステムを「不確実性を管理し、失敗仮説を追跡する状態付きワークスペース」として位置づけていますが、それでも限界は残るとしています。
AI Co-Mathematician は数学研究を加速するが、正しさの最終責任をAIに移せる段階ではない ということです。探索、文献調査、反例探し、草稿化には有効だが、最終的な証明確認には依然として数学者の介入が必要です。
- 証明の正しさを完全には保証できない
複数のAIレビューを通しても、論理の穴や暗黙の仮定を見落とす可能性があります。綺麗なLaTeX草稿が出るほど、内容まで正しいと誤認しやすい。
- reviewer-pleasing bias がある
エージェントが本当に証明を直すのではなく、レビューエージェントが納得しやすい表現に書き換えてしまうことがあります。つまり、誤りが消えるのではなく、見えにくくなる危険がある。
- death spiral が起こる
証明エージェントとレビューエージェントが、修正と差し戻しを延々と繰り返し、最終的に推論品質が劣化して hallucination に落ちる場合があります。
- 人間の数学的直観はまだ必要
問題設定、方針転換、重要な補題の発見、最終的な厳密性確認は、人間の専門家に依存します。AIは探索や検証を加速できるが、創造的突破を常に自力で出せるわけではありません。
- コストと計算資源が大きい
高い性能は、多数のモデル呼び出し、並列エージェント、コード実行、レビュー反復に支えられています。単一モデルの一回回答と比べると、推論コストはかなり重い。
- 評価結果の解釈に注意が必要
FrontierMath Tier 4 で48%という結果は強いですが、これは「モデル単体の能力」ではなく、エージェント環境・ツール利用・長時間探索を含むシステム全体の性能です。arXiv要約でも、同システムは数学ワークフロー全体を支援する workbench として説明されています。
メインTOPIC
SkillOS: Learning Skill Curation for Self-Evolving Agents
arXiv: 2605.06614
著者: Siru Ouyang, Jun Yan, Yanfei Chen, Rujun Han, Zifeng Wang, Bhavana Dalvi Mishra, Rui Meng, Chun-Liang Li, Yizhu Jiao, Kaiwen Zha, Maohao Shen, Vishy Tirumalashetty, George Lee, Jiawei Han, Tomas Pfister, Chen-Yu Lee（16名、Google）
概要
LLMベースのエージェントは実世界タスクで広く活用されているにもかかわらず、過去の経験から学習して自己進化する能力を持たない「一回限りの問題解決者」として動作している。本論文では、タスクが時系列で到着するストリーミング設定において、過去の相互作用から抽出した再利用可能な「スキル(skill)」を適切に管理・進化させることを学習するシステム SkillOS を提案する。凍結されたエージェント実行機(executor)とRL(強化学習)で訓練可能なスキルキュレーター(curator)を分離するモジュール設計、関連タスクのグループ化による長期的学習信号の構築、複合報酬関数の組み合わせにより、既存の記憶なし・記憶あり手法を最大+9.8%上回る性能を達成した。
補足: なぜ「スキルキュレーション」が必要なのか
人間のエキスパートは経験を積むにつれて「コツ」や「手順のパターン」を蓄積し、新しい問題にそれを応用します。一方、従来のLLMエージェントは毎回まっさらな状態でタスクを解くため、同じ失敗を繰り返したり、すでに習得したはずの手順を活かせないという問題があります。
SkillOSが解こうとしているのはこの問題です。「スキル」とは、過去の経験から抽出した再利用可能な手順・知識の断片（Markdownファイル形式）であり、「キュレーション」とはそのスキルを適切に追加・更新・削除して質を維持する管理行為を指します。スキルの数が増えれば良いわけではなく、古いスキルや誤ったスキルを削除し、有用なスキルに絞り込む「整理整頓」こそが重要です。
先行研究との関係
自己進化エージェントにおけるメモリ・スキル管理
エージェントの長期記憶は大きく2つに分類される。
- ケースベース表現: 軌跡そのものやクエリ応答ペアをそのまま記憶する（例: ReAct, Reflexion）
- 戦略ベースメモリ: ワークフロー、蒸留したインサイト、スキルとして抽象化して記憶する（例: ExpeL, Voyager, SkillWeaver）
用語解説: 代表的な先行手法
- ReAct (2022, arXiv:2210.03629): LLMに「思考(Reasoning)→行動(Acting)」を交互に繰り返させる手法。過去の経験は次のタスクには引き継がれない。
- Reflexion (2023, arXiv:2303.11366): タスク失敗後に自然言語で反省文を生成し、次の試みに活かす手法。ただし、反省文はその試行内でしか有効でない。
- ExpeL (2023, arXiv:2308.10144): 複数の軌跡からインサイトを抽出・記憶するが、管理ルールはヒューリスティック。
- Voyager (2023, arXiv:2305.16291): Minecraftエージェントで実行可能コードをスキルとして蓄積する手法。スキル追加は人手ルール。
- SkillWeaver (2025, arXiv:2503.23462): スキルのグラフ構造管理を導入した手法。
スキルはモジュール性とカスタマイズの容易さから注目を集めているが、既存のスキル管理手法は主に人手キュレーション（スケールしない）またはヒューリスティックなルールベース（下流フィードバックを反映できない）に依存していた。
RLによるメモリ・スキルキュレーション
強化学習をメモリ管理に適用した先行研究として以下がある。
| 研究 | アプローチ | 限界 |
|---|---|---|
| 長文脈管理研究 | 情報圧縮・要約 | スキル管理に特化していない |
| SkillRL | スキル利用の最適化 | スキル使用方法の学習に限定 |
| D2Skill | スキル抽出・適応 | 短期ストリーム内の局所的適応のみ |
これらの先行研究は、スキルのinsert/update/deleteといった複雑な管理操作を長期的に最適化する学習信号が欠如している点で共通した限界を抱えていた。
SkillOSはこのギャップを埋めるために設計されている。
主要な貢献
- スキルキュレーションをRLで学習する新枠組みの提案: スキルの挿入・更新・削除という複雑な長期管理操作を、下流のタスク性能から逆算してエンド・ツー・エンドで学習する初の手法
- モジュール分離設計: 凍結した実行機とRL訓練可能なキュレーターを分離することで、任意の実行機（異なるLLM・異なるタスク領域）への汎化を実現
- グループ化訓練インスタンスによる長期学習信号の構築: 関連タスクを1グループとして学習させることで、スキルキュレーションの効果を後続タスク性能として観測可能にする
- 複合報酬関数の設計: タスク結果・関数呼び出し有効性・内容品質・圧縮インセンティブの4成分を組み合わせた報酬により、間接的・遅延フィードバックから有効な学習信号を獲得
- 強力な汎化性能: 訓練時と異なる実行機（Gemini-2.5-Pro等）・異なるタスク領域への転移を実証
手法の詳細
システムアーキテクチャ
Figure 1: SkillOS は凍結した Agent Executor と訓練可能な Skill Curator を組み合わせる。
Executor は SkillRepo から関連スキルを検索して行動し、Curator は経験に基づいてリポジトリを編集（insert/update/delete）する。
スキルのフォーマットは Markdown ファイルである。
問題定式化
タスクが時系列で到着するストリーミング設定を考える。タスク系列 に対し、各時刻 でエージェントは実行軌跡 を生成する。外部のスキルリポジトリ(SkillRepo)にスキル集合 を保持し、エージェントはこれを参照しながらタスクを解く。
エージェント実行機 （凍結）
- BM25を用いてSkillRepoから関連スキル を検索
- スキルを参照しながらタスクを実行：
- 訓練中は重みを更新しない
用語解説: BM25
BM25 (Best Match 25) は、クエリ文字列と文書群の「単語の一致具合」を統計的にスコアリングする古典的な情報検索手法です（検索エンジンの基礎技術）。ここでは、タスク のテキストをクエリとして、SkillRepo内のスキル一覧から関連度の高いスキルを取得するために使われています。ニューラルネットワークを使わずに高速で動作するため、スキル数が多くなっても効率的に検索できます。
スキルキュレーター （訓練対象）
- 実行軌跡 、正確性信号 、関連スキル を観察
- insert_skill, update_skill, delete_skill の操作列を生成：
スキルのフォーマット（Markdownファイル）
訓練パイプライン
Figure 2: SkillOS の訓練パイプライン。各訓練ステップで関連タスクのグループをサンプリングし、空の SkillRepo を初期化する。 は複合報酬によって最適化され、自己進化を実現する。
訓練インスタンスの構築（グループ化）
個別タスクではスキルキュレーションの長期的効果が測定できないため、関連タスクのグループ化を行う。
補足: なぜグループ化訓練が必要なのか
スキルキュレーション（特にスキルの「更新」や「削除」）の効果は、その後のタスクを解いてみないと評価できません。例えば「このスキルを追加したことで、次の似たタスクが解けるようになったか」を測るには、少なくとも2つ以上のタスクが必要です。
単一タスクでは「スキルを追加した → タスクが成功した」の因果関係が見えても、「追加したスキルが役に立ったのか、それとも最初からLLMが解けたのか」が区別できません。関連する複数タスクをグループとして学習させることで、「タスク1でキュレートしたスキルがタスク2・3の成功率を上げた」というスキルの長期的有用性を学習信号として使えるようになります。
手順:
- Gemini-2.5-Proを用いて各タスク にスキル関連属性タグ （トピック・落とし穴など）を付与
- 属性の類似度に基づいてタスクをグループ に分割
- グループ内での実行順：前のタスクでキュレートされたスキルが後続タスクの実行に使われる
これにより、スキルが後続タスクを改善したかどうかをグループ内で測定できる。
📖 用語解説: スキル関連属性タグ の具体的内容
論文ではタスク種別によって2つのアプローチを使い分けている。
1. エージェントタスク（ALFWorld・WebShop）の場合
既存のタスクタイプアノテーションをそのまま使用する。LLMによる属性生成は不要。
例: ALFWorldの6種類のタスクタイプ
- （拾って置く）
- （光の下で調べる）
- （洗って置く）
- （温めて置く）
- （冷やして置く）
- （2つ拾って置く）
これらは既に「同じスキルを共有するタスク群」として自然に分類されているため、そのままグループ化に使える。
2. 数学推論タスク（DeepMath-103K）の場合
Gemini-2.5-Proを使って、各タスクから5次元の構造化属性を抽出する。
| 記号 | 名称 | 内容 | 具体例 |
|---|---|---|---|
| Topics（トピック） | 高レベルな分野ラベル | "algebra", "Fourier transformation", "number theory" | |
| Skills/Capabilities | 必要となる能力 | "symbolic manipulation", "case analysis" | |
| Concepts/Theorems | 数学的概念・定理 | "Pythagorean theorem", "inradius–circumradius relation" | |
| Heuristic strategies | 適用可能な解法戦略 | "substitution", "induction" | |
| Common pitfalls | よくある落とし穴 | "boundary case omission", "sign error" |
抽出ルール（Figure 16のプロンプトより）
- 各次元は短いフレーズ（最大5語）
- 標準化された用語を使う（自由記述の説明ではない）
- 問題文や答えに固有の内容は含めない（汎用化のため）
- 必要最小限のフレーズ数で記述
- 構造化デコーディングでJSONスキーマに準拠
グループ化での使い方（Stage 2）
5つの次元のうち、依存性フィールド （概念・戦略・落とし穴） を使って逆インデックスを作成し、これらのいずれかを共有するタスクをマッチング候補にする。トピック だけでマッチングすると「同じ分野だが解法が違う」タスクが集まってしまうため、解法依存性で絞り込むのがポイント。最終的に、5次元すべての類似度（soft-Jaccard）を重み付けしてグループを構築する:
（最後の項 は難易度の近さによるバランス調整）
要するに、タグは「この問題は何のジャンルで・どんな能力が必要で・どの定理を使い・どんな解法パターンで・どこで間違いやすいか」を機械可読な短いフレーズ集合で表現したもので、これによって「同じスキルセットで解けるはずのタスク群」を自動的に発見できる仕組みである。
複合報酬関数
| 報酬成分 | 定義 | 目的 |
|---|---|---|
| グループ内後続タスクの成功率 | ||
| 有効・実行可能な操作の割合 | ||
| 軌跡コピーを抑止し蒸留を促進 | ||
| 外部判定モデル(Qwen3-32B)による意味的品質評価 |
ハイパーパラメータ: , ,
補足: 各報酬成分が解決する問題
4つの報酬成分はそれぞれ別の問題に対処しています。
- （タスク成功報酬）: 「後続タスクが実際に成功したか」というメインの学習信号。 はタスク が成功なら1・失敗なら0を返す指示関数。ただしこれだけでは信号が疎（グループ後半まで待たないと報酬が得られない）という問題がある。
- （関数呼び出し有効性報酬）: キュレーターが などのツール呼び出しを正しいフォーマットで実行できているかを評価。LLMがツール呼び出しを出力しても構文エラーが多いため、「とにかく実行可能な操作を出力すること」を先に学ばせるための密な補助報酬。
- （圧縮インセンティブ）: スキルのサイズ()が元の軌跡のサイズ()に近いほどペナルティ。「軌跡をそのままコピーするだけ」というズルを防ぎ、情報を蒸留・抽象化することを促す。
- （内容品質報酬）: Qwen3-32BのLLMに審判(Judge)をさせ、生成されたスキルの内容が意味的に有用・具体的かを評価。数式だけでは測れない「スキルの質」を捉えるための補助信号。
ポリシー最適化（GRPO）
GRPO(Grouped Reward Policy Optimization)を採用。
用語解説: GRPO（Grouped Reward Policy Optimization）
GRPOはDeepSeek-R1などで採用された強化学習アルゴリズムで、LLMの訓練に特化したPPO（Proximal Policy Optimization）の変種です（arXiv:2402.03300）。
数式の直感的な意味を分解すると以下の通りです。
- （確率比）: 「新しいポリシーが生成した操作列の確率」を「古いポリシーの確率」で割った値。この比が1より大きければ新ポリシーがその操作をより好んでいることを意味する。
- （アドバンテージ）: 「この操作列の報酬が、同じ状況で生成した 個の操作列の平均報酬よりどれだけ良かったか」を示す値。グループ内の相対比較なので、絶対値ではなく「他よりマシかどうか」を学ぶ。
- clip（クリッピング）: を の範囲に制限することで、一度の更新でポリシーが大きく変わりすぎることを防ぐ安全装置。PPOの核心的な工夫。
つまり「平均より良かった操作はより選びやすく、悪かった操作は選びにくくするが、変化量は控えめに」という学習ルールです。通常のPPOと異なり、GRPOは価値関数（ベースライン）を別途学習する必要がなく、グループ内の平均報酬をベースラインとして使うためLLM訓練に適しています。
実験設定
データセット
| データセット | 種別 | タスク内容 |
|---|---|---|
| ALFWorld | マルチターンエージェント | テキストベース住宅環境での物体操作（Pick/Look/Clean/Heat/Cool/Pick2の6カテゴリ） |
| WebShop | マルチターンエージェント | オンライン買い物シミュレーション（製品検索・購入） |
| AIME24/25 | 単一ターン推論 | 数学コンテスト問題 |
| GPQA-Diamond | 単一ターン推論 | 専門家レベル科学QA |
用語解説: 評価環境・ベンチマーク
- ALFWorld (arXiv:2010.03768): 「バスルームのシンクにスポンジを置いてきれいにせよ」のような家事タスクをテキストコマンドで操作するシミュレーション環境。エージェントは , , などのコマンドを順に発行してタスクを完了する。手続き的な行動順序の学習が重要であり、スキルとして「どの順番で行動するか」を記録しやすいため、本研究の主評価環境として使われている。
- WebShop (arXiv:2207.01206): 自然言語で指定された条件（「色が青でサイズがMのセーターを予算20ドル以内で買え」）を満たす商品をウェブストアで検索・購入するシミュレーション環境。検索キーワードの工夫や絞り込み操作のパターンをスキルとして蓄積できる。
- AIME (American Invitational Mathematics Examination): 全米数学オリンピック予選。高校数学レベルを大幅に超える難問で構成され、LLMの数学的推論力を測る標準ベンチマークとして広く使われている。AIME24/25はそれぞれ2024年・2025年の問題セット。
- GPQA-Diamond (arXiv:2311.12022): 物理・化学・生物学の博士号取得者が作成した専門家レベルの4択問題集。GPT-4でも正答率が低く、LLMの科学的推論能力を測る高難度ベンチマーク。
ベースライン
| ベースライン | 説明 |
|---|---|
| No Memory | スキルなし、記憶なし |
| ReasoningBank | 経験から蒸留したインサイトを記憶 |
| MemP | 手法的メモリ管理（ヒューリスティック） |
| SkillOS-base | RL訓練前のスキルキュレーター |
| SkillOS-gemini | Gemini-2.5-Proをキュレーターとして直接使用 |
用語解説: ベースライン手法
- ReasoningBank: 各タスクの実行後に「何がうまくいったか・失敗したか」という洞察(insight)を自然言語でLLMに生成させ、その「銀行(bank)」を次のタスクで参照する手法（arXiv:2406.14692）。スキルではなくインサイトとして記憶するため、具体的な手順の再利用には向かない。
- MemP: メモリをどのように管理するか（いつ追加・削除するか）を事前に人手でルール設計する手法。タスクの結果フィードバックからルールを改善する機構はない。
- SkillOS-base: SkillOSと同じアーキテクチャを持つが、強化学習での訓練を行っていない状態（LLMの素の能力でキュレーションを実行）。SkillOSとの差がRL訓練の効果を示す。
実装詳細
- キュレーター: Qwen3-8B
- 訓練: GRPO、学習率 、バッチサイズ32、グループサイズ8
- 訓練データ: DeepMath-103kから33,000サンプル抽出
- ハードウェア: 16× H100 GPU、訓練期間約3〜5日
- テスト時実行機: Qwen3-8B, Qwen3-32B, Gemini-2.5-Pro
実験結果
メインタスク: ALFWorld（Qwen3-8B Executor）
| 手法 | Pick | Look | Clean | Heat | Cool | Pick2 | 平均Success Rate | ステップ数 |
|---|---|---|---|---|---|---|---|---|
| No Memory | 78.1 | 46.2 | 33.3 | 37.5 | 29.3 | 47.2 | 47.9 | 21.1 |
| ReasoningBank | 83.8 | 48.7 | 49.4 | 39.6 | 41.3 | 54.2 | 55.7 | 20.1 |
| MemP | 80.0 | 43.6 | 24.7 | 33.3 | 38.7 | 48.6 | 49.7 | 21.0 |
| SkillOS-base | 79.0 | 41.0 | 45.7 | 37.5 | 38.7 | 55.6 | 53.1 | 20.4 |
| SkillOS | 85.7 | 56.4 | 54.3 | 43.8 | 46.7 | 62.5 | 61.2 | 18.9 |
- 最良ベースライン(ReasoningBank: 55.7%)比で +5.5% の絶対改善
- RL訓練なし(SkillOS-base: 53.1%)比で +8.1% の改善
- ステップ数も21.1→18.9へ -10.4% 削減（効率化）
メインタスク: ALFWorld（Gemini-2.5-Pro Executor)
| 手法 | 平均SR | ステップ数 |
|---|---|---|
| No Memory | 66.4 | 17.2 |
| SkillOS-base | 59.8 | 16.8 |
| SkillOS-gemini | 68.6 | 15.7 |
| SkillOS | 80.2 | 14.8 |
- 8Bのキュレーターが、Gemini-2.5-Proを直接キュレーターとして使った場合(68.6%)を +11.6% 上回る
- これは「モデルの能力よりも、下流性能で訓練されたキュレーション能力の方が重要」であることを示唆
💡 補足: Curator-Executor Mismatch（キュレーター-執行器ミスマッチ）— 強い執行器に未学習スキルは「邪魔」になりうる
2つのALFWorld表を見比べると、SkillOS-base（RL未学習のQwen3-8Bキュレーター）の振る舞いに重要なパターンが現れる。
| 執行器 | No Memory | SkillOS-base | 差分 |
|---|---|---|---|
| Qwen3-8B | 47.9% | 53.1% | +5.2%（改善） |
| Gemini-2.5-Pro | 66.4% | 59.8% | −6.6%（劣化） |
⚠️ Gemini-2.5-Pro執行器では、未学習キュレーターのスキルを与えるとNo Memoryより悪化する。
何が起こっているか
- 弱い執行器 (Qwen3-8B): 自分で解く能力が低いため、多少粗いスキルでも「無いよりはマシ」で改善する
- 強い執行器 (Gemini-2.5-Pro): 素の能力が高いため、未学習キュレーターが作る品質の低いスキル（不正確な手順・冗長情報・執行器の能力に合わないアドバイス）が判断を妨害する
論文 Section 4.3 でこの現象は "curator-executor mismatch" と呼ばれ、以下のように説明されている。
"stronger reasoning ability alone does not guarantee effective skill curation, as frontier-generated skills may be misaligned with the executor's capacity or usage patterns"
つまり「強い推論能力 ≠ 良いキュレーション能力」であり、執行器の能力・使用パターンに合致したスキルを作る能力は別物。
SkillOSが解決すること
| 執行器 | No Memory | SkillOS-base | SkillOS | base→SkillOSの改善 |
|---|---|---|---|---|
| Qwen3-8B | 47.9% | 53.1% | 61.2% | +8.1% |
| Gemini-2.5-Pro | 66.4% | 59.8%（劣化中） | 80.2% | +20.4% |
RL学習を施すことで、執行器の能力に応じた "executor-grounded curation behaviors"（執行器に根ざしたキュレーション振る舞い）が獲得され、Gemini-2.5-Pro執行器でも素の能力(66.4%)から+13.8%引き上げに転じる。これが SkillOS の核心的な貢献の一つ。
WebShopと推論タスク
| 手法 | WebShop Score | WebShop SR | AIME24 | AIME25 | GPQA | 平均Acc |
|---|---|---|---|---|---|---|
| No Memory | 33.3 | 9.8 | 76.0 | 71.1 | 61.8 | 69.6 |
| ReasoningBank | 38.2 | 14.2 | 77.3 | 73.3 | 62.4 | 71.0 |
| SkillOS-base | 38.6 | 15.1 | 76.7 | 72.2 | 62.9 | 70.6 |
| SkillOS | 40.6 | 16.5 | 80.0 | 76.7 | 64.6 | 73.8 |
- WebShop: No Memory比 +7.3% のスコア向上
- 推論タスク平均: +4.2% の精度向上
Executor間の汎化（クロス実行機転移）
Figure 3: SkillOS のクロスタスク汎化結果。(a) Qwen3-8B、(b) Qwen3-32B、(c) Gemini-2.5-Pro を凍結実行機とした場合の相対改善量を示す。
Qwen3-8Bで訓練したキュレーターが未見の実行機に対しても改善を示す。
| テスト実行機 | No Memory | SkillOS | 改善幅 |
|---|---|---|---|
| Qwen3-8B | 47.9 | 61.2 | +13.3% |
| Qwen3-32B | 65.3 | 79.2 | +13.9% |
| Gemini-2.5-Pro | 66.4 | 80.2 | +13.8% |
タスク域間の汎化（クロスドメイン転移）
ALFWorldで訓練したキュレーターをWebShopに適用した場合、全ての転移設定で基準線(No Memory)を上回る結果を示し、タスク固有ヒューリスティクスを超えた汎用的スキルキュレーション能力を示唆。
分析と考察
スキル操作の学習ダイナミクス
Figure 4: 訓練中のスキルキュレーターによるスキル操作（insert/update/delete）の分布変化。
Figure 5: RL訓練下でのキュレート済みスキルの進化ダイナミクス。
スキル利用統計
Figure 6: ALFWorldにおけるスキル利用統計の比較。SkillOS とベースライン手法のスキル利用パターンの差異を示す。
評価された4つの指標（論文 Section 5 "Attribution of Skill Usage" より）:
| 指標 | 定義 |
|---|---|
| (i) Skill usage rate | エージェントが少なくとも1つのスキルを呼び出した評価例の割合（リポジトリの普遍的有用性を測る） |
| (ii) Successful skill usage rate | スキルを使った例の中での成功率（スキルが実際に成功に貢献しているかを測る） |
| (iii) Skill coverage | スキルリポジトリ全体のうち、実際に使われたスキルの割合（死蔵スキルの少なさを測る） |
| (iv) Avg. number of skills used per example | 1タスクあたりの平均スキル使用数（スキル依存度・選択精度を測る） |
主な発見:
- SkillOSは全評価例(100%)でスキルを呼び出し、ベースラインより成功率が高い → スキルが直接タスク解決に貢献
- より広い範囲のスキルが使用される → RL訓練がリポジトリ全体の有用性を改善（死蔵スキルを削減）
- 1例あたりのスキル使用数は少ない → 改善は「より多くのスキル文脈を詰め込んだから」ではなく、「より精密なスキル選択」から来ている
"gains come from more precise skill selection rather than more skill context"
（改善は「より精密なスキル選択」から来ており、「より多くのスキル文脈を詰め込んだから」ではない）
タスク種別による効果の差異
エージェントタスク（ALFWorld: +13.3%、WebShop: +7.3%）と推論タスク（+4.2%）では効果の大きさが異なる。この差異は、手続き的スキル（「物体をどのように探すか」「どの順でコマンドを実行するか」）がエージェントタスクでより直接的に再利用できるのに対し、推論では思考パターンの一般化が難しいためと考えられる。
RL訓練の重要性
SkillOS-base（訓練なし）からSkillOS（訓練あり）への改善は、単純にスキルリポジトリを持つだけでは不十分であることを示す。効果的なキュレーション（不要なスキルの削除、既存スキルの精緻化）はRL訓練によって初めて学習される。
モデルサイズよりもキュレーション特化訓練
8B Qwen3モデルで訓練したキュレーターが、Gemini-2.5-Proを直接キュレーターとして使う設定を上回ることは、スキルキュレーション能力がモデルの汎用能力とは独立した学習可能なスキルであることを示す重要な知見。
スキルリポジトリの進化（ケーススタディ）
Figure 17: SkillOS によってキュレートされたスキルのケーススタディ。訓練が進むにつれてリポジトリが抽象的・汎用的な「メタスキル」を獲得していく様子が観察される。
Figure 18: 数学推論スキルキュレーションのケーススタディ。SkillOS-base は汎用的な手順のみを出力するのに対し、SkillOS は具体的な制約・方程式・例題を含む再利用可能なフレームワークをキュレートする。
Figure 19: SkillOS がキュレートしたスキルを活用して ALFWorld タスクを正しく解決するケーススタディ。
付録: プロンプト設計
スキルキュレーターのシステムプロンプト
Figure 7: 訓練プロセスにおけるスキルキュレーターのシステムプロンプト。
📝 Figure 7 日本語要約: スキルキュレーターのシステムプロンプト
# 役割
あなたは洗練されたスキルキュレーターの専門家。過去のエージェントタスク実行経験を、将来のタスクで活用できる再利用可能で一般的なスキルに変換することが目標。
# 入力データ
- Task Description: 達成すべきタスク
- Past Skills: 既存スキルのリスト（スキル名と内容）
- Agent Trajectory: タスク実行のステップ・バイ・ステップ軌跡
- Result: タスクが成功したかどうか
# 重要な制約
- Skill Format: 必ずMarkdownフォーマットで重要情報を抽出・保存
- No Specifics: 問題固有の詳細（数値・名前など）を避ける。変数や概念に置換すること
- No Hallucination: 事実を捾造しない
- 各スキルは Atomic（原子的）、Modular（モジュール式）、Reusable（再利用可能） でなければならない
# Skill Markdownフォーマットとコンテンツの指示
- YAML Frontmatter（必須）: 各スキルは で区切られたYAMLブロックで開始。との2キーのみを正確に含む
- Markdown Body: 2つ目の の直後にMarkdownヘッダーで指示。提案セクション: , など（自由に工夫してよい）
- 内容は原子的・一般的で、特定インスタンスIDを含まないこと
# 行動ガイドライン
- エージェントの軌跡と結果を分析。何がうまくいって・何がいかなかったかを特定
- 軌跡が正しい場合、再利用可能な知識やスキルを抽出。間違いの場合、失敗ポイントを特定しそれを修正できるスキルを抽出
- 抽出したスキルを既存スキルと比較し、insert_skill / update_skill / delete_skill ツールで操作
Figure 8: スキルキュレーターのツール呼び出し定義・シグネチャ（insert_skill / update_skill / delete_skill）。
📝 Figure 8 日本語要約: ツール呼び出し定義
: 既存の関連スキルがない場合、新しいスキルを作成
- (string, required): 作成する新スキル名
- (string, required): 新スキルのMarkdown内容
: 既存スキルを改善できる場合、 で指定したスキルを更新
- (string, required): 更新するスキル名（既存スキルのタイトルと完全一致必須）
- (string, optional): 新しい名前（省略時は変更なし）
- (string, optional): 新しい内容（省略時は変更なし。指定する場合は完全な内容を指定）
: 既存スキルをタイトルで削除
- (string, required): 削除するスキル名
引数はすべてJSONオブジェクトとしてフォーマット。
エージェント実行プロンプト
Figure 9: 関連スキルを参照する ALFWorld エージェント実行プロンプト。
📝 Figure 9 日本語要約: ALFWorldエージェント実行プロンプト
あなたは ALFRED Embodied Environment で動作する専門エージェントです。タスクは:
## Past Relevant Skills（過去の関連スキル）
## Current Progress（現在の進捗）
これまでに ステップ実行済み。直近 個の観察と取った行動:
現在のステップは 、現在の観察:
現在の状況で許容される行動:
行動を取る番です。過去の関連スキルを参考に、ステップ・バイ・ステップで推論してください。
- 推論は タグで囲うこと（必須）
- 推論完了後、許容される行動を1つ選び、 タグで提示すること（必須）
Figure 10: 関連スキルを参照する WebShop エージェント実行プロンプト。
📝 Figure 10 日本語要約: WebShopエージェント実行プロンプト
あなたは WebShop e-commerce environment で動作する専門エージェントです。タスクは:
構造はFigure 9（ALFWorld版）とほぼ同じ。違いは環境がWebShopに変わるだけ。
- Past Relevant Skills、Current Progress（step_count, history, current_observation, admissible_actions）を提示
- 過去の関連スキルを参考にステップ・バイ・ステップで推論
- で推論を囲み、 で行動を出力（必須）
→ ALFWorldとWebShopでプロンプト構造を統一することで、同じキュレーターが両環境で動作可能。
Figure 11: 推論タスクにおける関連スキルを参照するエージェント実行プロンプト。
📝 Figure 11 日本語要約: 推論タスク実行プロンプト
あなたはスキルリストへのアクセスを持つ推論専門家。以下のスキルを使ってユーザークエリに正確に答えてください。
## Past Relevant Skills
## Problem
ステップ・バイ・ステップで推論し、必要に応じて過去の関連スキルを使い、最終回答を に入れること。
→ エージェント版（Figure 9/10）の 形式とは異なり、CoT推論＋最終回答を で抽出する典型的な数学/科学QAフォーマット。
報酬・判定プロンプト
Figure 12: 生成されたスキル内容に品質スコア を付与する外部ジャッジのプロンプト。
📝 Figure 12 日本語要約: スキル品質ジャッジ（）プロンプト
あなたは専門メモリアナリスト。以下の4つの基準でスキルメモリの内容品質を分析してください:
- ABSTRACTION（抽象化）: スキルは一般化可能な手順・洞察を捕らえているか？軌跡の逐語コピーではないか？特定ID・数値・オブジェクト名が変数や一般概念に置換されているか？
- REUSABILITY（再利用性）: スキルは原子的・モジュール式か？未来のタスクで再使用される可能性のある1つの整合した能力を記述しているか（無関連ステップの寄せ集めではない）？
- ACTIONABILITY（実行可能性）: Markdown本体は具体的なガイダンス（ワークフロー、条件、使うべきでないとき）を提供しているか？曖昧なアドバイスでないか？
- FAITHFULNESS（忠実性）: スキルのすべての主張は軌跡で裏付けられているか？捾造された事実・ツール・環境動作は含まれていないか？
出力フォーマット（JSON）:
→ この4基準（抽象化・再利用性・実行可能性・忠実性）のJSON判定が報酬 になる。Qwen3-32Bが評価者。
Figure 13: ALFWorldベンチマークにおける現在の軌跡の正解性シグナルを取得するLLM-as-a-Judgeプロンプト。
📝 Figure 13 日本語要約: ALFWorldタスク成功判定プロンプト
あなたは厳格な評価者。エージェントが家事タスクをテキストシミュレーターで成功裏に完了したかを判定し、JSONオブジェクトのみを出力。
# Task
(1)タスク説明、(2)エージェントとシミュレーター間の完全相互作用軌跡が与えられる。エージェントがタスクを完了したか判定。
## "成功"の意味
- エージェントの行動が、タスク説明が指定する世界状態を生み出していること
- タスクで述べられた全条件が軌跡の最後で成立していること
- タスクが配置・相互作用前に変換を要する場合、その変換が最終ステップ前に証拠化されていること
- シミュレーター観察で確認された効果のみを評価。エージェントが宣言・計画・想定しただけは信用しない
- ループに陥った/ステップ予算を使い切った/無効行動を繰り返した軌跡は失敗
## 厳格性
- 全必須条件が最後で満たされているか曖昧 →
- 部分完了は失敗。「全条件成立」か「失敗」のいずれか
# Output（JSON）
Figure 14: 単一ターン推論問題の正解性シグナルを取得するLLM-as-a-Judgeプロンプト。
📝 Figure 14 日本語要約: 推論タスク正解性判定プロンプト
あなたは厳密な推論問題の評価者。モデルの解答が正しいか判定。
# Task
(1)推論問題、(2)長い推論プロセスを含む候補解答が与えられる。候補解答の正解性を判定。
## Rules
- 最終回答が数学的に正解と等価で、推論が偶然正解に至った無効ステップに依存しなければ → 正解
- 軽微なフォーマット差・等価な数学形式は許容
- 最終回答が正解でも、推論に重大な概念ミスがあり導出を無効化する場合 → 不正解（後で独立かつ明確に正当化されない限り）
- 厳密値要求の問題で近似のみ → 不正解（問題で正当化されない限り）
- 候補が拒否/最終回答なし/問題再述だけ → 不正解
## Protocol
- 問題の要求出力を特定
- 候補の最終回答を抽出
- 候補の回答が問題を満たすか独立検証
- 候補の推論が回答をサポートするか確認
- 不必要な冗長性・無関係な探索は最終解答が明確で有効なら無視
# Output（JSON）
Figure 15: WebShopベンチマークにおける軌跡の正解性シグナルを取得するLLM-as-a-Judgeプロンプト。
📝 Figure 15 日本語要約: WebShop購入評価プロンプト
あなたは専門評価者。買い物エージェントがユーザー指示に合致する商品を購入したかを判定。
## How to score（4サブスコアの平均で[0,1]の単一スコアを出力）
- Product type match: 購入製品が指示の指名カテゴリに属する → 1、それ以外 → 0
- Attribute coverage: 指示で明示指名された属性のうち、購入商品（選択オプション込み）が満たす割合。属性指名なしなら1
- Price constraint: 指示の価格制約を購入価格が満たす → 1、それ以外 → 0。価格制約なしなら1
- Purchase completion: 軌跡が具体的製品ページで確認購入アクションで終わる → 1、それ以外 → 0
最終スコア = 4サブスコアの平均。 は と定義。
## Strictness
- 属性クレジットは、ページテキストまたはエージェントの選択オプションが明確な証拠を提供する場合のみ付与（不在から推論しない）
- 誤った製品タイプでの購入 → 他のサブスコアに関わらずスコア0を強制
# Output（JSON）
訓練インスタンスグループ化
Figure 16: 各タスク から属性タグ を取得するためのシステム指示。訓練インスタンスのグループ化に使用する。
📝 Figure 16 日本語要約: タスク属性アノテーション指示
あなたはデータアノテーションと数学的推論の専門家。
数学問題が与えられたら、以下の5次元で問題の特性を厳密かつ正確に記述する1個以上のフレーズ（5語未満）を生成:
- Topic（トピック）
- Skills or Capabilities（スキル/能力）
- Math Concepts or Theorems（数学的概念または定理）
- Heuristic Strategy（ヒューリスティック戦略）
- Common Pitfalls（よくある落とし穴）
## Requirements
- アノテーションはフレーズのみ。長い文を避ける
- 問題や解答からの文脈や具体的内容を含めない
- 応答はJSONフォーマット
- 各次元に対し、できるだけ少ないフレーズを使用
- 標準化／認知された用語のみ使用（大規模データ処理に使われるため）
→ ここで生成された5次元タグ がStage 2のグループ化（依存性ゲート＋soft-Jaccard類似度）で使われる。
制限事項と今後の課題
- 訓練コスト: 16×H100で3〜5日の訓練が必要であり、計算資源の要求が高い
- 推論タスクでの効果が相対的に小さい: 手続き的スキルの再利用が難しい純粋推論タスクではエージェントタスクほどの改善が得られない
- スキル操作の意味的評価依存: コンテンツ品質報酬 にQwen3-32Bの判定モデルを使っており、その品質に依存する
- 長期的なリポジトリ膨張: スキル数が増え続けた場合の管理・検索効率の劣化は未検討
- 今後の研究方向: より効率的なスキル検索機構、継続学習設定への拡張、マルチエージェント間でのスキル共有などが挙げられる
まとめ
SkillOSは、LLMエージェントの「自己進化」という課題に対して、スキルキュレーションをRLで学習するという新しいアプローチを提案した。重要な設計原則は以下の3点に集約される。
- 実行機とキュレーターの分離: 汎化性能と実用的な展開を可能にする
- グループ化訓練による長期学習信号の構築: スキルの長期的有用性を直接最適化できる唯一の設計
- 複合報酬による多面的な品質保証: タスク成功率だけでなく、スキルの簡潔さ・有効性・品質を同時に最適化する
実験結果は、この設計が複数のタスク領域・実行機にわたって一貫して有効であることを示しており、自己進化エージェントの実用的な基盤技術としての可能性を提示している。