これは何の論文か
SkillOpt は、エージェントに渡す自然言語のスキル文書を、凍結したモデルの外側で改善していく論文である。
ここでいうスキルは、単なるプロンプトの一部ではない。タスクの進め方、ツールの使い方、出力形式、失敗しやすい点をまとめた、再利用できる手続きの文書である。論文はこのスキル文書を「一度書いたら終わりのメモ」ではなく、実行結果を見ながら更新する対象として扱う。
図で見ると、Figure 1 が一番わかりやすい。現在のスキルでタスクを実行し、その実行ログを別の optimizer モデルが読み、スキル文書への追加・削除・置換を提案する。候補スキルは保留データで検証され、良くなったものだけが採用される。最後に残るのは、推論時にそのまま使える best_skill.md である。
つまり SkillOpt は、モデルをファインチューニングする論文ではない。モデル重みは固定したまま、外側にあるスキル文書を、実行、反省、編集、検証のループで育てる論文である。
評価対象が通常の対話だけではない点も重要である。論文は direct chat だけでなく、Codex と Claude Code のようなエージェント型ループも含めて検証している。Table 1 では、6 ベンチマーク、7 対象モデル、3 実行ハーネスにまたがる 52 セルすべてで、SkillOpt が最高または同率最高だったと報告している。
何が問題だったのか
エージェントスキルは、作ることよりも育て続けることが難しい。
たとえば失敗ログを見て「次はこうする」とスキルに追記するだけなら簡単である。しかし、その追記が本当に効いたのか、別のタスクで邪魔にならないのか、古いルールと矛盾しないのかは分かりにくい。自然言語のスキルは読みやすい一方で、少しの文言変更でモデルの行動が変わる。成功例に合わせすぎると過適応し、失敗例に反応しすぎるとスキル文書が長くなり、推論時のノイズになる。
論文が問題にしているのは、スキル更新に「学習率」や「検証ゲート」に相当する規律がないことである。何を足すのか、何を消すのか、どの編集を採用するのか、採用しなかった編集をどう扱うのかを決めないと、自己改善はただの自己追記になる。
この背景は、Figure 2 のパイプラインを見ると具体化する。訓練データでロールアウトを集め、成功と失敗をミニバッチで反省し、編集予算の範囲で候補スキルを作り、選択データで改善した場合だけ採用する。つまり SkillOpt は、スキルを「感想の追記先」ではなく、検証しながら更新する外部状態として扱う。
提案手法の中身
入力は、初期スキル文書、対象エージェント、タスク集合、各タスクの採点結果である。対象エージェントのモデル重みは固定し、更新するのは外側にある自然言語スキルだけにする。
まず、現在のスキルをエージェントに渡してタスクを解かせる。ここで、成功した実行、失敗した実行、スコア、途中の行動が集まる。SkillOpt はこの実行証拠を、スキルのどこが効いていて、どこが足りないかを見る材料にする。
次に、optimizer モデルが成功例と失敗例を読み、スキル文書への編集案を作る。編集はスキル全体の書き換えではなく、追加、削除、置換の小さな操作に制限される。これは、自然言語スキルの更新幅を抑える textual learning-rate のような役割を持つ。
作られた候補スキルは、訓練に使った実行だけではなく、保留データで検証される。訓練実行では良く見えても、保留データで改善しなければ採用しない。ここが、単なる自己反省による追記との大きな違いである。
採用されなかった編集は捨てっぱなしにせず、reject buffer に残す。同じような悪い編集を繰り返さないための負の証拠として使い、optimizer が次の候補を作る時の判断材料にする。
反復の最後には、検証で最も良かったスキルが best_skill.md として出力される。推論時には optimizer を呼ばず、通常のエージェントにこのスキル文書を渡すだけで使える。
どうやって確かめたのか
評価は、6 ベンチマーク、7 対象モデル、3 実行ハーネスで行われる。ハーネスには 通常の対話 だけでなく、Codex ループと Claude Code も含まれる。これは、スキルが単純なチャット回答だけでなく、実際のエージェント型ループでも効くかを見るためである。
比較では、SkillOpt が作った 最適化されたスキルと、既存のスキル改善・自己反省系の設定を比べる。重要なのは、訓練実行 で良く見えた編集をそのまま採用せず、保留データでの検証で改善した場合だけ 最良のスキルとして残す点である。
測る指標は、モデル / ベンチマーク / ハーネスの各セルでの成功率、スキルなしからの改善幅、編集予算や拒否編集バッファを外した時の差、最終スキルが別モデル、別実行環境、近いベンチマークへ転用できるかである。
結果はどうだったのか
SkillOpt は、52 個のモデル / ベンチマーク / ハーネスセルすべてで best または tied-best と報告されている。単発チャットだけでなく、Codex ループや Claude Code を含む実行ハーネスでも効いた点が重要である。
GPT-5.5 では、通常の対話、Codex ループ、Claude Code の各設定で平均改善が報告されている。つまり、最適化されたスキルは、チャット用の説明文ではなく、実行ループの中で使える手続き知として働いている。
最適化されたスキル成果物は、モデルスケール、実行環境、近いベンチマークをまたいで転用する傾向がある。これは、検証つきで磨いた自然言語スキルが、単一タスクの小技に閉じず、ある程度再利用可能な外部知識になっていることを示す。
推論時に追加の最適化器呼び出しを必要としないため、改善後のスキルは通常のエージェント実行に組み込みやすい。
限界・注意点
- optimizer モデルの品質に依存する。悪い反省や編集提案が出ると、検証ゲートがあっても探索効率は落ちる。
- 検証 design が重要である。保留データでの検証が狭いと、スキルがその検証セットへ過適応する可能性がある。
- 自然言語スキルの編集は可読性と性能が両立するとは限らない。長くなりすぎたスキルや局所ルールの蓄積は、別途整理が必要になる。
- これはモデル重みの学習ではなく、外部スキル成果物の最適化である。未知の能力を獲得するというより、手続き知を外側で整える手法として読むのがよい。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントでは、スキルは運用の中心になる。しかし、毎回の失敗をそのまま追記すると、スキルはすぐ読みにくくなり、古いルールや局所的な例外で重くなる。
SkillOpt 的に運用するなら、スキル更新は小さな編集として扱う。追加、削除、置換を分け、代表タスクで検証し、改善しない編集は reject buffer に残す。これにより、「なぜ採用しなかったか」も運用知識になる。
個人向けエージェントでは、好みや作業手順が自然言語で増える。だからこそ、スキルをメモではなく検証つき成果物として扱い、推論時には軽く、更新時には厳しく見るのが効く。
Q&A
この論文の中心問いは？
エージェントスキルを手書きメモや一回生成の補助ではなく、評価つきで改善できる 改善可能な成果物として扱えるか、という問いである。
SkillOpt はモデルを ファインチューニング するの？
しない。対象エージェントのモデル重みは凍結し、外部の自然言語スキル文書 を最適化する。
何を入力して何を出す？
入力は初期スキル、タスク実行、スコア、失敗や成功の証拠。出力は検証で改善が確認された best_skill.md である。
普通の自己反省型スキル更新と何が違う？
制約つき編集、検証ゲート、却下編集のバッファ、編集予算を持つ点が違う。思いつきで追記するのではなく、optimizer として制御する。
なぜ Codex / Claude Code で評価している点が大事？
スキルが単発チャットだけで効いても、実際のエージェントループで効くとは限らない。Codex / Claude Code を含めることで、実行ハーネス内の手続き知として効くかを見ている。
作業支援エージェントにはどう効く？
ログ振り返り、スキル更新、知識ベースのルール更新を、単なる追記ではなくロールアウト証拠、編集、検証、reject buffer のループとして設計する材料になる。
注意点は？
検証集合が狭いとスキルが過適応する可能性がある。また、性能改善だけを追うとスキル文書が長く複雑になり、運用上の可読性が落ちる。
関連する論点は？
From Raw Experience to スキル Consumption とセットで読むのがよい。SkillOpt が最適化手法なら、そちらはスキルライフサイクルと negative 転用 の地図になる。