#45 AIの手順書を「学習率」で磨く時代

AIエージェントが現場で使う「やり方マニュアル（スキル文書）」を、ディープラーニングの最適化と同じ規律（学習率、検証ゲート、ミニバッチ）で自動的に磨き上げる、初の体系的な「テキスト空間のオプティマイザ」を実現した研究。

最近のAIは単なる「質問応答」ではなく、ツールを使い、ファイルを操作し、複数ステップで仕事をこなす「エージェント」として動くことが増えています。こうしたエージェントを特定の業務に適応させるには、モデル本体の重みを書き換える必要はなく、「手順書（スキル文書）」を渡すだけでよい——というのが最近の潮流です。

ところが、このスキル文書の作り方は驚くほど雑でした。人間が手書きするか、AIに一発で書かせるか、雑な自己改訂ループで進化させるか。いずれも「前より本当に良くなったか」を検証する仕組みがなく、書き換えるたびに性能が落ちる可能性もありました。​ディープラーニングのような規律ある最適化をスキル文書に適用した研究は、まだ存在しなかったのです。

SkillOpt の発想はシンプルで、「スキル文書を、凍結したエージェントの“外部パラメータ”として訓練しよう」というものです。ディープラーニングとの対応関係がきれいに整理されています：

• パラメータ → スキル文書そのもの
• 勾配 → 実行ログから導かれる「編集の方向」
• 学習率 → 1ステップで許される編集の最大数（例：4箇所まで）
• 検証セット → 別データでスコアが上がった編集だけを採用する「ゲート」
• モメンタム → エポック単位の「ゆっくり更新」で長期的な教訓を保持

具体的には、別のフロンティアモデル（最適化担当）がエージェントの成功・失敗ログを読み、「追加・削除・置換」という限定された操作で編集案を出します。編集案は検証スコアが厳密に上がった場合のみ採用され、却下された編集は「次は同じ失敗をしないように」とバッファに記録されます。乱暴な書き換えで前バージョンの良い部分が消えないよう、ステップごとの変更量を制限している点が肝です。

6つのベンチマーク × 7つのモデル × 3つの実行環境（合計52条件）すべてで、SkillOptがベスト（または同点1位）を獲得しました。

GPT-5.5 を直接対話で動かすと、スキルなしと比べて平均で +23.5ポイント 改善。たとえば：

• スプレッドシート操作: 41.8% → 80.7%
• オフィス文書QA: 33.1% → 72.1%
• 数学ベンチマーク: 37.6% → 66.9%

人間の専門家が書いたスキル、ワンショットでAIに書かせたスキル、競合の最適化手法（TextGrad、GEPA、EvoSkillなど）と比べても、平均で +5.4ポイント 上回りました。さらに、訓練済みスキルを別のモデル・別の実行環境・近い別のベンチマークに転用しても効果が残ることが確認されています（例：Codex環境で訓練したスプレッドシートスキルをClaude Code環境に持ち込んでも、ベースラインから +59.7ポイント改善）。

驚くべきことに、最終的なスキル文書は 300〜2,000トークン程度​（数百字〜数千字）で、​わずか1〜4回の編集 で大きな改善が得られています。

これは「AIを業務に組み込む」現場にとって、かなり実用的なメッセージを持っています。

第一に、モデルを再訓練しなくていい。​ GPTやClaudeのような閉じたフロンティアモデルは重みを触れませんが、テキストの手順書を磨くだけで業務性能が大幅に上がるなら、コストとリスクは桁違いに小さくなります。

第二に、成果物が「読める」。​ 出来上がるのは最大2,000トークン程度のMarkdownファイル。人間が監査でき、編集でき、別のプロジェクトに流用できます。「AIが何を学んだか分からない」というブラックボックス問題への現実的な答えです。

第三に、再利用性が高い。​ 1回訓練したスキルが、より小さいモデル・別のツール環境・近隣タスクで効くことが示されています。つまり、強力なAIで一度スキルを磨いておけば、それを安いモデルで使い回す——という運用が可能になります。

第四に、運用コストが推論時にかからない。​ 最適化は訓練時のみで、デプロイ後は単なるテキストファイルが追加されるだけです。

業務AIの導入で「何度プロンプトを書き直しても良くならない」と感じたことがある人には、特に響く論文だと思います。プロンプトエンジニアリングが「職人芸」から「再現可能な最適化プロセス」になりつつある、と言ってもよさそうです。