MUSE-Autoskill

本レポートの読み方

出典区分バッジについて

本レポートは 論文の事実・著者の主張・本レポートによる解釈・不明点 を色分けバッジで明示します。研究レポートの信頼性をスキャンしやすくするための仕組みです。

• Fact論文本文・表・図に直接記載された事実。
• Claim著者が明示的に述べている主張・解釈（検証は読者に委ねられる部分を含む）。
• InterpretHermes / Claude Code（本レポート）による解釈・実務的な含意。原論文の記述ではありません。
• Unknown論文で扱われていない、または本文（PDF抽出）からは確認できない事項。

出典は arXiv の HTML/PDF。本レポートは30ページPDFのテキスト抽出（PyMuPDF）に基づくため、図中の数値や表のレイアウトに抽出上の誤差が含まれる可能性があります（各所で注記）。

Problem Setting / 問題設定

既存「AutoSkill」の4つの欠落

LLMエージェントは、手順・コード・ドメイン知識をカプセル化した再利用単位＝スキルを必要とする。Voyager 以降、スキルを自動生成する研究（AutoSkill, EvoSkill, SkillGen など）や、RLで最適化する研究（Skill1, SkillOS など）が増えてきた。

Claimしかし著者は、これらがライフサイクルの一部しかカバーしていないとし、4つの実務的ギャップを挙げる。

Skill Lifecycle / 5段階

スキルのライフサイクル

FactMUSE はスキルを統一ライフサイクルで組織化する。エージェントは ReAct ループ（計画→行動→観測）の中で動き、起動時のビルトインスキルは skill_create と web_search のみ。それ以外の能力はすべてこの仕組みで動的に作られる。

1. 作成 (Creation) — 既存スキルで不足なら、目的・入力・出力の仕様を渡して skill_create がパッケージを生成。
2. 記憶 (Memory) — 短期・長期・スキル単位の3層メモリに、観測・教訓・利用履歴を追記。
3. 管理 (Management) — メタデータで索引化し、カタログをプロンプトに注入。改善・統合・剪定で品質を保つ。
4. 評価 (Evaluation) — tests/ のユニットテストと実行フィードバックで正しさを検証。
5. 改善 (Refinement) — テスト失敗時に update_skill でパッチし、再テスト。自己進化ループを回す。

Skill Package / スキルの実体

スキルパッケージの構造

Fact1スキル＝kebab-case名のディレクトリ。Anthropic の Agent Skills 形式に準拠し、SKILL.md が必須、サブディレクトリは任意。コードの要らない「SKILL.md のみ」が実際には支配的なパターン。

# 既定では $HOME/.autoskill（AUTOSKILL_HOME で変更可）
pdf-form-update-redaction/
  SKILL.md      # frontmatter(name, description) + 本文
  .memory.md    # スキル単位メモリ（遅延生成・転送対象外）
  scripts/      # 任意: 実行コード(Python/shell/Node)
  tests/        # 任意: pytest互換。登録のゲートになる
  resources/    # 任意: データ/参照文書
csv-summarize/
  SKILL.md      # 典型的な "doc-only" スキル

カタログ・ルーティング（プログレッシブ開示）

Factタスク開始時にプロンプトへ注入されるのは各スキルの name と description だけ。本文は read_skill で必要になってから読む。この2段階探索により、スキルバンクのサイズに対して1回あたりの入力コストがほぼ一定に保たれる（100スキルでもカタログは約5〜10Kトークンで、全本文ロードの約500Kを回避）。

Creation & Evaluation / 作成と評価

create → evaluate → register ループ

Fact新スキルは skill_create で生成される。まず SKILL.md（インターフェース）を作り、内部構造（scripts/ / resources/ / tests/）を計画し、ファイルを生成する。

Fact生成後は評価ゲートを通る：サンドボックス内で tests/ を実行し、全テスト合格時のみスキルバンクに登録。失敗時はエラートレースを調べて update_skill でパッチし、再テストする。これにより信頼できるスキルだけがバンクに入る。

実行（Skill Execution）

Fact実行はエージェントの ReAct ループ内で、汎用のサンドボックス・ライフサイクルツール（create_sandbox, sandbox_run, sandbox_upload/download, close_sandbox）を介して行う。各サンドボックスは独立プロセス／コンテナで、失敗・副作用・リソース使用がスキル起動ごとに隔離される。専用の実行エンジンを別途持たず、エージェントが普段使うツールを再利用する設計。

Multi-level Memory / 3層メモリ

スキルレベルメモリが新規性

FactMUSE は MemGPT / Generative Agents / Reflexion などの階層メモリを土台にしつつ、各 SKILL.md に紐づくスキル単位のメモリ層を加えた点が新しい。

Management / 管理

改善・統合・剪定でバンクを維持

Fact各スキルは SKILL.md のメタデータ（name, description, inputs, outputs）で索引化され、タスク開始時にカタログがシステムプロンプトへ注入される（プログレッシブ開示）。エージェントは計画時にカタログから最も関連するスキルを選ぶ。

検索に加え、3つの継続メンテ機構でバンクを健全に保つ：

• 改善 (Refinement) — テスト失敗や誤出力時に、エラーフィードバックを基に修正・再生成。
• 統合 (Merging) — 新スキルが既存と大きく重複する場合、より汎用な1つに統合して冗長を排除。
• 剪定 (Pruning) — 一貫して失敗する、または長期間使われないスキルをバンクから除去。

これらにより、スキルが増えてもバンクをコンパクト・信頼性・スケーラブルに保つ、と説明される。

Context Management / 文脈管理

会話DAG＋2段階の適応的圧縮

Fact文脈は会話ノードのDAGとして保持される。各ノードは1ターン分の応答・ツール呼び出し・観測・トークン使用量を記録し、2組のポインタを持つ：可変の parent_id（LLMへ送る現アクティブ鎖）と、不変の history_prev/next（元の全履歴）。

Fact先頭 KEEP_FIRST = 5・末尾 KEEP_LAST = 5 ターンは常に逐語で固定し、中間だけが圧縮対象。圧縮はアクティブ鎖のみに作用し、不変の履歴ポインタは書き換えないため、セッションを跨いだ再開やトラジェクトリの再生が可能。セッション終了ごとに全状態をスナップショット永続化する。

Unknown図4の模式図では KEEP_FIRST/LAST=2 と描かれているが、実験の実設定（Table 8）は 5/5。図はあくまで説明用と解される（PDF図の数値は抽出上の注意点）。

Experiments / 実験設定

SkillsBench での評価

FactSkillsBench は実世界タスクのベンチマーク。各タスクは独立したDockerコンテナで動き、最終出力ファイルだけを自動検証器が採点し、報酬を [0,1] で与える。MUSE は全94タスクのうち 51タスク（全エージェントが環境エラーなく完走できるもの）を、4つのスーパードメインで評価する。

Fact3エージェント（MUSE-Autoskill / Codex / Hermes）はすべて同じバックボーン GPT-5.5（04/24/2026）を provider 既定設定で使用。temperature 等は未指定。各タスクを独立Dockerで5回実行し、タスク平均→51タスクのマクロ平均で報告する。性能差はモデル能力ではなくエージェント設計の差を反映する。

Result 1 / スキル利用の効果（Table 2）

人手スキルは全エージェントを底上げ

Fact全エージェントが人手スキルで13〜15pp向上。MUSE はスキルあり・なし両方で最高精度。

Result 1b / ドメイン別（Table 3）

4ドメイン中3つで首位

Fact人手スキルありのドメイン別精度。MUSE は Data Analysis・Document Processing・Ops & Planning で首位。Science & Engineering のみ Codex が5.7pp上回る（検証器が仕様で固定されていない手法選択を罰した3件の境界失敗が原因と説明）。

数値は人手スキルあり条件（%）。太字＝各行の首位。

Result 2 / 自作スキル生成（Table 4）

自作スキルは人手の上限を超える

Fact2フェーズ手順：Phase 1 でスキルなしで解き（5回）、1回でも成功したタスクは最良トラジェクトリから skill_create でスキルを蒸留。Phase 2 でそのスキルを再注入し再評価（5回）。51タスク中 35タスク（68.6%）でスキル生成に成功。

Result 3 / クロスエージェント転送（Table 5）

生成スキルは別エージェントへ移植できる

FactMUSE が生成したスキルファイルを無改変で Hermes に注入。Hermes は 47.89% → 58.40%（+10.51pp）に向上し、人手スキルとの差の79%を埋めた。同じ生成スキルを使うと Hermes(58.40%) は MUSE(60.35%) に約1.95ppまで接近する。

Result 4 / コストと効率（Table 6, Fig.5/7）

生成スキルは Pareto 最適

Factスキル生成は1回 ≈383Kトークン・164秒・7ターン（1回払い）。生成スキルの利用は人手スキルより安くつく：MUSE は 615K/656s → 493K/411s（−20%トークン・−37%レイテンシ）、Hermes は 186K/369s → 97K/257s（−48%トークン・−30%レイテンシ）。

中央値（35タスク）。レイテンシは検証器・Docker準備を除く。

Fact図5では、両エージェントとも生成スキル利用が「高報酬・低レイテンシ・少トークン」の唯一の Pareto 最適点。MUSE は +11.0pp（76.9→87.9%）、Hermes は +15.3pp（69.8→85.1%）。生成コスト383Kは、1回あたり約122Kの節約に対し ≈3回の再利用で損益分岐する。

Case Studies / 事例（成功3＋退行1）

生成スキルが運ぶドメイン知識

• Factadaptive-cruise-control（離散PID制御）：ベースライン40%。生成スキルが離散PID式・アンチワインドアップ・ゲイン調整ヒューリスティック・検証器要求のJSON形式を成文化 → Phase 2 で100%。Hermes も 20%→60%。
• Factflink-query（Apache Flink Java ジョブ）：ベースライン20%。生成スキルがスキーマ解析・AppBase拡張プロトコル・イベント時刻セッショントリガ・Maven検証手順を同梱 → 100%。
• Factweighted-gdp-calc（Excelの2条件ルックアップ＋SUMPRODUCT）：生成スキルが openpyxl を正しいツールとして指定し、検算ステップを追加 → 20%→100%。同じ記述で Hermes も無改変で誘導。
• Claim退行：hvac-control（一次熱シミュレータのPI制御）：80%→20%。元トラジェクトリのキャリブレーション手順がそのシミュレータのノイズ特性に依存し、再実行時のばらつきで安定余裕外のゲインを生むことがある。「一度は効いたが、試行錯誤のベースラインより頑健でない手順」を符号化した例。

Analysis / スキル解剖と監査（Fig.6）

人手 vs 生成スキルの違い

Fact35の生成スキルと249の人手スキルを比較。生成スキルの SKILL.md 中央値は 326行（15.8KB）vs 人手146行（6.6KB）＝約2.2倍。長さの中身は冗長ではなく手続き的（入出力スキーマ・失敗モード・手順を明示）。「SKILL.md のみ」が支配的（人手69% / MUSE 91%）。

品質監査（リーク検査）

Fact35スキルを手動検査した結果、検証器の期待出力をハードコードしたり、タスクIDで分岐したり、正解ファイルを読むスキルは皆無。ただし一部のスキルは固定ファイル名・パス・数値範囲など元実行依存の前提を含み、これはカンニングではないが分布外（OOD）入力への汎化を制限しうる。

Unknown図6Bの各サブディレクトリ含有率（scripts/ 等の正確な%）は棒グラフからの読み取りで、PDFテキスト抽出では厳密値を確定できない。本文記載の「約22%」「約9%」を採用。

Deployment / 実運用（Section 5）

3つの本番システムで採用

Claimライフサイクル抽象はベンチマーク特有ではなく、すでに本番システムで採用されている、と著者は述べる。

• SkillMarket — スキル生成パイプラインをエンドユーザーに公開し、成功トラジェクトリを自己テスト済みスキルに蒸留。スキル管理・更新を追加予定。
• ArkClaw — スキル検索を find-skill 機能として統合。新規合成前に既存スキルを探す。エージェント全体を呼び出し可能なサブエージェントとして扱う拡張を計画。
• SkillHub — 作成・評価・記憶・管理・改善のフルライフサイクルをホスト型サービスとして運用。チームでスキルと経験を共同管理。

Practical Interpretation / 実務への示唆

AIエージェント／Hermes のスキル設計へ

この節は 論文の事実・著者の主張・本レポートの解釈を明示的に分けて、実務（特に Hermes のスキル設計）への含意を整理します。Hermes は本論文で転送先として実測された当の third-party ランタイムである点に注意。

• Factカタログには name と description だけが eager に載り、本文は read_skill で遅延ロードされる。Interpret ⇒ Hermes のスキルでも frontmatter の description がルーティング精度の生命線。トリガ条件と適用範囲を description に凝縮するのが費用対効果が高い。
• Facttests/ 合格を登録ゲートにすると、信頼できるスキルだけがバンクに入る。Interpret ⇒ 自動生成スキルを採用するなら、「テストが通るまで登録しない」ゲートを CI 的に組み込むのが現実的な品質担保。
• FactMUSE 生成スキルは人手より約2.2倍長いが、中身は手続き的（入出力スキーマ・失敗モード・手順）。Interpret ⇒ スキルは「短く曖昧」より「長くても手順が具体的」な方が、推論トラジェクトリを置換してターン数とトークンを減らしうる。
• Fact無改変の生成スキル注入で Hermes が +10.51pp 向上した。Claimスキルは外部化された移植可能資産。Interpret ⇒ あるエージェントで蒸留したスキルを別エージェントに横展開する運用は、本論文の範囲では有望。
• Fact.memory.md は配布物から除外され、経験は転送されない。Interpret ⇒ 「共有する手順（SKILL.md）」と「各環境ローカルの経験（.memory.md）」を分離する設計は、スキルの可搬性とプライバシ／文脈依存の両立に有効。
• Facthvac-control は生成スキルで 80%→20% に退行（元実行特有のキャリブレーション依存）。Interpret ⇒ 単一の成功トラジェクトリから蒸留したスキルはOOD で脆い恐れ。固定値・パス・数値範囲を一般化するクリーニング工程を入れるべき。
• Factプロンプトキャッシュが限界入力コストの約半分を吸収。Interpret ⇒ スキルカタログ／システムプロンプトを安定させキャッシュヒットを最大化すれば、スキル導入のトークン増は実費ベースで見かけより小さい。

Checklist / 再現・評価チェックリスト

追試するなら何を確認するか

Interpret本レポートによる、再現・評価時の確認項目。論文のAppendix（B〜I）の設定値を基に構成。

• バックボーン固定 — 3エージェントとも GPT-5.5(04/24/2026)、temperature 等は provider 既定。モデル能力差を排除できているか。
• タスク選定の確認 — 全94中51タスク（全員が環境エラーなく完走できるもの）。除外タスクの偏り（難易度上振れ）を意識する。
• 採点プロトコル — 各タスク5回×独立Docker、最終出力ファイルのみ検証、無出力は報酬0、Phase1失敗タスクは分母に0で算入。
• 圧縮設定 — COMPRESS_TOKEN_THRESHOLD=180K / NODE_=15K / KEEP_FIRST=KEEP_LAST=5。Level-1優先・Level-2は>50ターンで稀。
• タイムアウト階層 — TOOL 300s > VERIFY_COMPLETION 120s > TERMINAL=EXEC_CODE 60s、MODEL 300s、MAX_RETRY 5。
• スキルの素性 — 各スキルは単一の成功トラジェクトリから蒸留。固定ファイル名・パス・数値範囲などOOD前提が混入していないか監査。
• 転送の方向 — 検証済みは MUSE→Hermes の片方向のみ。他方向・他エージェントは未検証。
• 統計的頑健性 — 5回/タスクでは個別タスクの信頼区間は広い（特に二値報酬）。再実行で分散を確認。

---
name: <kebab-case 識別子; ディレクトリ名と一致>
description: <1段落の自然文; 呼ぶか否かの判断材料>
---
# <Title Case のスキル名>
## When to use   # 起動すべきタスク種別
## Core principles # 実装が守るべき不変条件
## Recommended tools # 具体的なライブラリ/CLI/サンドボックスツール
## Workflow       # 実行時にたどる手順

Limitations & Unknowns / 限界と不明点

限界・未確認事項

著者が明示する限界

• Claim評価は94中51タスク。除外タスクはDocker環境が複雑で難しい傾向があり、システム全体性能を過大評価しうる。
• Claimスキル生成成功は68.6%（35/51）のみ。各スキルは単一の成功トラジェクトリ由来で、最も汎用な解とは限らない。
• Claimクロスエージェント転送は MUSE→Hermes のみ検証。より広い汎化は未確認。
• Claim5回/タスクでは個別タスクの信頼区間が広い（特に二値報酬）。
• Claim自己生成実験は「同一タスクの1成功トラジェクトリで作り、同一タスクで再評価」する構造のため、検証器が決定的でもタスク内利得を過大に見せる可能性がある。

本レポートが指摘する不明点

• Unknown図中の散布図・棒グラフの細部数値（図5/6/7/8）はPDF抽出では厳密確定できない。本文・表の値を優先採用。
• UnknownGPT-5.5 以外のバックボーンでの挙動、SkillsBench 以外の独立ベンチでの汎化は未評価（著者も今後の課題として明記）。
• Unknown「本番採用（SkillMarket/ArkClaw/SkillHub）」の定量的成果は本文に数値がなく、規模・効果は検証不能。
• Unknown本論文は arXiv プレプリント v1。査読状況・最終版での数値変更は不明。