本動画は、AIエージェントの能力を向上させるためのスキルマークダウンファイルを自動生成する新しいフレームワークであるTrace2Skillに関する論文解説である。人間が手動で記述したスキルファイルや、LLMの内部知識のみに依存して生成されたスキルファイルが抱える限界を指摘し、多数の並列サブエージェントを用いて実際のタスク実行の軌跡から効果的なスキルを抽出・統合する画期的な手法を紹介している。さらに、大規模モデルで生成されたスキルが小規模モデルにどの程度転移可能かという検証結果も解説しており、モデルの知能とツール活用のバランスについて深い洞察を提供している。
小さなモデルのスキルは大きなモデルで使えるのか？
皆さんこんにちは、またお会いできてとても嬉しいです。今日は私たちのスキルマークダウンファイルを改良していきたいと思います。というのも、小さなLLM向けに最適化されたスキルMDファイルは、巨大なLLMモデルでも機能するのか、それともモデルと互換性がなくなってしまうのか、という素朴な疑問があるからです。さっそく見ていきましょう。結論から言うと、一般的に人間はスキルMDファイルを全く書くべきではないということが分かってくると思います。なぜなら、はるかに優れた、素晴らしい解決策があるからです。この動画では、人工知能によるその方法を正確にお見せします。
すでにご存知のように、数週間前に私たちはスキルMDだけでは不十分であり、経験やその他多くのものが必要であることを発見しました。そして、人間が書いたプロンプトはAIにとって最も複雑なものであるということをお見せしましたね。それでは、詳しく見ていきましょう。スキルMDファイルがシステムプロンプトの先頭に追加されると、それはコンテキスト内の条件付けとして機能します。これはモデルの学習ではなく、テンソル重みの構造には一切触れられず、変更もされません。したがって、標準作業手順や、何かを送信する前に必ず実行すべきことなどを明示的にリストアップすることで、スキルはLLMが取り得るアクションの広大なツリーを刈り込み、数学的には有効であってもタスクには不適合な経路をエージェントが取るのをブロックするのです。私はこの定義がとても気に入っています。
では、前回の動画を振り返ってみましょう。前回はスキルMDだけでなく、完全なフォールバック状態が機能するかどうかについても皆さんに問いかけました。その動画もぜひ楽しんでいただきたいのですが、今回は新しい論文があります。AlibabaのQwenアプリケーションビジネスグループと、チューリッヒ大学、北京大学、浙江大学による素晴らしい論文で、彼らはTrace2Skillというものを発表しました。彼らは今、軌跡という局所的な教訓から、転移可能なエージェントのスキルMDファイルを抽出しているのです。これは非常に興味深い内容になりそうですよね。2026年3月26日の論文です。
人間によるスキル作成の限界とAIによる解決策
彼らによると、スキルMDファイルを手作業で順序付けることは深刻なスケーラビリティのボトルネックを生み出すとのことです。また、自動化されたスキル生成は、LLM自身の浅いパラメトリックな知識に依存するか、あるいは局所的な教訓からの一般化できない軌跡に過剰適合してしまうため、脆弱で断片的な結果をもたらすことが多いということを示してくれます。では、どうすればいいのでしょうか。この研究の著者たちは素晴らしい解決策を見つけました。
通常スキルを抽出する場合、私たちが持っている軌跡から抽出しますが、彼らが今回行っているのは、幅広い軌跡の局所的な教訓を並列で分析することです。そして、これらの並列な教訓を分析し、共通のパターンを単一の包括的なエージェントスキルとして抽出するのです。多様な実行プールを分析するためにサブエージェントの強力なフリートを活用するという、美しく強力なアイデアですね。彼らは、何が起きようとも確実に対応できるようにしたいと考えています。この研究では、考えられるすべてのパターンを発見するために、128個のサブエージェントを並列に実行させています。
Trace2Skillは自動スキル作成のためのフレームワークであり、彼らによると、すでに存在する強力なベースラインを大幅に改善するとのことです。さらに、スプレッドシートの自動化に焦点を当てた場合、公式のAnthropicのXLSXスキルを凌駕するスキルMDを作成することさえできるのです。私がこの論文を読み始めたとき、本当に素晴らしいと思いました。公式にAnthropicから公開されているスキルMDファイルよりも優れた結果を達成できる、非常にシンプルなメカニズムを持つことができるなんて驚きです。これがスプレッドシート操作のためのXLSXスキルMDファイルです。
スキルMDファイルを開いてみると、そこにはすでにベストプラクティスと呼べる多くの情報が含まれていることがわかります。彼らがこれを機能させるために数週間から数ヶ月の経験を注ぎ込んでいることが見て取れますよね。そして今、AIを使って、Anthropicの公式スキルMDを大幅に上回るものを作ることができるというのです。では、どのように行うのでしょうか。それは純粋な計算能力、つまり128の並列エージェントによるものです。彼らは想像し得るあらゆることをただ検証していきます。
Trace2Skillの仕組み：128のサブエージェントによる軌跡の分析
まずは最初から説明しましょう。ここに凍結されたエージェント、私たちのパイデータ、戦略、ポリシーがあります。初期スキルであるスキル・ゼロを使用して、循環するセット上で展開していきます。人間の手による初期化とLLMが作成した初期化の両方のケースをお見せしますね。これによりラベル付きの軌跡が生成され、これらの軌跡、つまりTまたはタウは、うまく機能した成功した軌跡となります。スプレッドシートがある場合、このスプレッドシートでの操作がまさに私たちが望んでいたものかどうかをここで確認できます。プラスかマイナスか、つまりエラートレースがあるわけです。
そして第2段階では、並列に128個のサブエージェントを解放します。これらはエラーと成功のアナリストです。成功アナリスト、エラーアナリストといった具合に、彼らはそれぞれ独自の個別の軌跡を独立して処理し、修正や最適化など、自らの軌跡に対してのみスキルのパッチを提案します。これでパッチが揃いました。素晴らしいですね。
ここからが主要なタスクです。すべてを単一のパッチにまとめなければなりません。このためのプロンプトをお見せしますが、シンプルで簡単なので、すぐに自宅でも試すことができます。プログラムによる競合防止機能を備えた帰納的推論を通じて、すべてを単一の統合されたアップデートにマージするのです。これは素晴らしいですね。
これがエラーアナリストの出力に対する軌跡レベルのパッチの正確な例です。どうするかというと、アナリストに単一のエラー記録を推論させるだけです。各アナリストは、先ほどお見せしたように、単一の軌跡に対する構造化されたパスを生成します。次の例は、エージェントが指定された範囲外の行を削除してしまった1つの失敗した軌跡を処理するエラーアナリスト、またはマイナスからのものです。このパッチは、行操作の安全性に関する新しいスキルMDセクションを追加することを提案しています。そしてこのパッチは、失敗を引用した他の50のパッチとともに、後にSOPへと統合されます。非常にシンプルなプロセスであることがお分かりいただけるでしょう。
そして先ほどお話ししたマージ操作のプロンプトをお見せします。あなたはスキル編集コーディネーターです。スキルフォルダへの変更を提案する複数の独立した提案パッチを受け取ります。あなたの仕事は、それらを一貫性のある、冗長性のないパッチにマージすることです。そして、以下の6つのガイドラインと条件があります。とてもシンプルなプロンプトですね。
モデルサイズとスキルの転移性
しかし、ここで最も興味深い疑問が生じます。このように生成されたスキルMDは、AIモデルに固有のスキルなのでしょうか。たとえば、820億のフリーな学習可能パラメータを持つモデルからこの新しい方法論でスキルMDを生成したとします。このスキルの複雑さは、1220億のモデルでも機能するのでしょうか。小さなモデルから巨大なAIモデルへのスキルMDファイルの転移性の基準とは一体何なのでしょうか。
それでは早速、結果を見てみましょう。彼らは2つのモデル、Qwenの3.5 20億（10億アクティブのMixture of Experts）と、Qwenの3.5 350億（30億アクティブ）を使用しました。スプレッドシートのベンチマークと、分布外のWiki用のベンチマークがありますね。素晴らしいです。
まず、スキルMDが全くない場合を見てみましょう。これは裸のLLMを使いたい場合ですね。27.67という結果です。次に、人間が書いたスキルMDファイルがある場合、1220億の大きなモデルでは、モデルのパフォーマンスが本当に向上しているのがわかります。しかし、350億のモデルを見てみると、人間が書いたスキルMDファイルはパフォーマンスを大幅に低下させ、半分にしてしまっています。これは非常に興味深いことです。
人間であるあなたが何を書くか、あるいはあなたの思考プロセスの複雑さがどうであれ、もしあなたが1220億やそれより小さいモデルを使い慣れている場合、同じ手書きのスキルMDファイルが全く逆の効果をもたらす可能性があるのです。人間が書いたものについては、モデルに大きく依存するということです。そしてパラメトリックなものについては、後で詳細を見る必要がありますが、人間が書いたベースラインは1220億のエージェントにとっては強力で、良い数字に達していることが読み取れると思います。
スキルの深化とパラメトリック知識からの作成
彼らは今回、2つの進化モードをテストしました。これは興味深いです。彼らはスキルの深化を目指し、初期化を人間の専門家が書いたプロンプトから始めることにしました。そして、パイプラインはスキル・ゼロに、Tマイナスからの失敗に特化したガイダンス、つまりエラーを追加するか、Tプラスからの効果的な戦略、つまり成功ケースを強化することによって洗練されていきます。これが深化のプロセスです。
彼らはまた、ゼロからの作成のみによるアプローチも持っています。この場合、タスクの軌跡には一切アクセスせず、LLMのパラメトリックな知識のみからドラフトされたスキルを使って初期化します。これがパラメトリックな知識です。さて、スキルの作成とスキルの深化が何であるかが分かったところで、次を見てみましょう。
彼らは6つの条件を評価していると述べており、これを本当に理解しようとしています。スキルなしはスキル文書がない状態、人間が書いたものは公式のAnthropicの公式XLSXスキル文書です。そして最も興味深いのがパラメトリックで、これはパラメトリックな知識のみからQwen 3.5 122Bにプロンプトを出すことで生成された基本的なスキルです。これらが主要な3つのカテゴリーです。そして、エラーアナリストのみを含むTrace2Skillのエラー、成功アナリストのみを含む成功、そして両方のアナリストタイプを追加した結合版があります。
このパラメトリックについて、絶対に明確にしておきましょう。これは特定の実験的なベースライン条件です。エージェントは、評価やジョブ、タスクを行う前に読むべきスキルMD文書を与えられます。しかし、この文書は他のタスクや実行を見る前に、LLM自身によって書かれたものです。研究者たちは単に1220億のLLMに対して、パラメトリックモデルとして知っていることに基づいて、スプレッドシートの操作と最適化のための基本的なガイドラインのようなものをプロンプトとして与えただけです。
このLLMは軌跡を少しも学習していないため、実際にこの特定のタスクを練習して、現実において何が機能し何が機能しないかを確認したわけではありません。事前学習データから直接引き出された一般的な常識的なアドバイスを吐き出しただけなのです。これが私たちがパラメトリックと呼んでいるものです。スキルMDファイルは存在しますが、これは環境との接触なしにパラメトリックな知識から生成されたものです。これは本当に美しい検証だと思います。
モデル間のスキル互換性と実環境の重要性
なぜなら、見てください。ここにスキルユーザーである私たちの122Bと、スキルユーザーである35Bがあります。そしてここにスキル作成者、つまりLLMである120Bがあります。これが私たちの深化にエラー、成功、そして結合を追加したものです。そしてこれがエラー、成功、結合による作成です。これを見てみましょう。
もし、スキルMDを書く作成者が1220億のフリーな学習可能パラメータを持つ大きなモデルであり、それを使用するスキルも同じサイズの122Bだとしましょう。深化については、エラーからの洞察がパフォーマンスを向上させます。成功ケースのみを狙うと逆効果になり、パフォーマンスが落ちます。結合した場合は、全体としてパフォーマンスは向上します。
さて、この122Bによって書かれたスキルMDファイルをスキルの深化のために使用し、それを350億のモデルに適用した場合を見てください。すべてグリーンです。素晴らしいですね。すべてが最適化されています。しかし、スキルMDファイルの作成について見てみると、興味深いことに、122Bから122Bへの適用では依然としてマイナスのパフォーマンスが見られます。エラーと成功の軌跡要素を組み合わせた場合、正直なところ、この特定のマイナス9.23がどこから来ているのか理解できませんが、これが彼らの測定結果です。それ以外はすべてグリーンで素晴らしいです。
つまり一般的に言って、122BモデルがスキルMDファイルを書こうと、35Bモデルが書こうと、35Bモデルは概ねプラス21、プラス8、プラス1と承認するでしょう。もし122BがスキルMDファイル書き、それが同じ122Bモデルで使用された場合、注意しないと、成功事例のみに焦点を当ててもパフォーマンスは低下し、組み合わせても一部のパラメータでパフォーマンスは低下します。
では、逆の場合はどうでしょうか。スキル作成者が35Bモデルで、その35Bモデルによって書かれたスキルMDを1220億のモデルで使用した場合はどうなるでしょうか。先ほどと全く同じで、成功のみの場合はパフォーマンスが下がります。そしてご覧の通り、ここでの作成においても、完全なソフトスプレッドベンチマークもマイナスになっています。したがって一般的に言って、122Bのために書く35Bは問題を抱えていると言えます。
一方で、35Bのために書く35B、あるいは35Bで実装されたものは、全体的にパフォーマンスが向上しています。つまり、ここでのスキルMDは機能しているということです。一般的に言えるのは、スキル作成者が122Bであれば、35Bのような小さなモデルにも使用でき、絶対的な改善が見込めるということです。素晴らしいですね。あるいは、35Bをスキル作成者として持ち、それを35Bで使用しても改善は見られますが、注意してください。これはスプレッドシートのベンチマークという1つのタスクに限定された話です。これは非常に興味深いことです。他のケースでは、転移性はありませんでした。
知能の境界とパラメトリック知識の限界
これは何を意味するのでしょうか。著者たちは、複雑なエージェントの経験は、パラメータの更新や外部の検索モジュールを必要とせず、高度に転移可能なスキルMDという宣言的なスキルにパッケージ化できることを結果が示していると述べています。そして彼らは、知能の転移の最低限の境界を350億パラメータのモデルとして定義しています。
そこで私は、80億パラメータのモデルだったらどうなるのかと考えました。どうやら、35Bほどうまく機能しないことを示す兆候があるようです。これはあくまで解釈であることを強調しておきたいのですが、このスプレッドシートベンチマークの複雑さにおいて、35Bが下限の1つであるように思われます。許容できるパフォーマンスを得たいのであれば、おそらく35Bを下回るべきではないでしょう。もちろん、これはタスクや複雑さ、スプレッドシートなどあらゆるものに依存しますが。
まずは、ここでのパフォーマンスの広がりをお見せしたいと思います。分布外のWikiでは、35Bが13%のパフォーマンスを示しています。100億アクティブのMixture of Expertsである120Bは、13%から21%です。したがって、1220億のモデルに費用を払うか、それとも35Bモデルの13.3%というパフォーマンスで満足するかは、皆さんが決めることです。純粋なスプレッドシートベンチマーク、つまり難しい方を選択した場合、これは4%から17%への大きなジャンプとなります。モデルを本当にスケールアップすれば、より高いパフォーマンスが得られることがお分かりいただけるでしょう。
さて、ここからが本当に興味深いポイントです。スキルなし、人間が書いたもの、そしてパラメトリックのところに戻りましょう。パラメトリックの参照が何であるかを正確に理解した今、これを見てください。ここの線に注目してください。パラメトリックのベースラインは全体的にスキルなしに非常に近い位置に留まっており、パラメトリックな知識だけでは有用なスキルコンテンツを生み出せないことを確認しています。
これはどういう意味でしょうか。つまり、パラメトリックな知識自体に、この知識を提供してスキルMDファイルを書いてくれと頼んだとしても、環境とのコンテキストからの洞察が単に欠けているということです。合成ベンチマークだけで進めても、環境との実際の接触、実際の仕事、実際のアプリの実装における実際のフィードバックの代わりにはならないのです。これは、エージェント自身の想像や事前学習のみから純粋に作成されたスキル文書をエージェントに与えても、全く役に立たないことを示しています。
なぜこれが重要なのでしょうか。これは、LLMに優れた指示のセットを書くように頼み、それが機能することを期待することはできないという証明になると思います。LLMの生のパラメトリックな知識には、事前学習からのかなり高レベルで一般的な概念が含まれています。特定のトレーニングを受けていないのであれば、事前学習の中には完全に非常に具体的な指示は含まれていません。そうした具体的な指示が欠けており、たとえばデータシートやSQLデータベースのような非常に特定のタスク環境のニュアンスも欠けているのです。
つまり、あなたの複雑さのレベルで、あなたの職場環境で、あなたの仕事に特化して本当に機能する有用なスキル文書を得るためには、LLMが物理的に環境と相互作用しなければならないということです。失敗し、なぜ失敗したのかを分析し、その具体的な経験に基づいてルールを書かなければならないのです。これこそが、AIによる役に立たないパラメトリックなスキルMDファイルのドラフトから、本日の出版物で見られるような、高度に効果的で軌跡に基づいたTrace2Skill文書への移行なのだと思います。
人間の視野の狭さとTrace2Skillによる克服
なぜでしょうか。人間が座ってスキルMDファイルを書くとき、私は非常に具体的なケースを念頭に置いています。1つの状況にレーザーのように焦点を当てますが、エージェントがタスクで実際に示すべき考え得るすべての行動の統計的な分布は考慮しません。あるいは、特定の整数の表現で進めようと考えるかもしれませんが、実際には実数かもしれませんし、複素数を扱う可能性だってあります。これらの他のすべての可能性も考慮しなければならないのです。
したがって、私という人間がスキルMDを書く場合、すべての可能な組み合わせについて考えているわけではありません。しかし、AIが128のサブエージェントを並列に解放すれば、私が見逃している考え得るすべてのリンクを見つけ出してくれます。私の解釈では、このTrace2Skillは、何百もの実際の実行軌跡を分析し、エージェントがどこで成功し、さらに重要なこととして、現実のどこで失敗しているのかに注目し、失敗が正確に何であるか、どうすればそれに対処し改善できるかを理解することで、人間の「すべてを考えきれない」という問題を修正しているのです。このフレームワークは、いわばこれらの一般的なパターンを特定し、それらを高度にターゲットを絞ったスキル文書へと抽出するのです。
AIファイルシステムは新たな知能を解き放つか？
さて、論文の最後になりますが、ここからは私の解釈です。これを3時間前に録画したときに、皆さんにお聞きしたことがありました。「コンテキストエンジニアリングだけではAIには不十分であり、Anthropicはすべての新しい知識と新しいスキルをこのファイルシステムに外部委託する美しいファイルシステムを開発したことは皆知っている。そこで、これらの新しいエージェントの所有者に関してシンプルな質問がある。AIファイルシステムは新しい知能を解き放つことができるのか？それとも、ファイルシステムはより複雑な推論を提供できないのか？」と。
これがコミュニティの皆さんの受け止め方であり、私自身の見解でもあります。私は、スキルMDファイルが知能を向上させるとは思いません。それは既存のLLMの知能の活用を最大化するものです。なぜなら、LLMの構造化されておらずエラーを起こしやすいパラメトリックな知識を、高度に決定論的なステップバイステップの状態機械へと変換するからです。このスキルMDファイルにある何百、何千行にも及ぶ詳細な指示のすべてをご覧になったでしょう。これこそが、私が決定論的なステップバイステップの状態機械と呼んでいるものです。
そして、今日のこのプレプリントは、小さなモデルには自分自身のためのチェックリストを書くためのメタ認知的キャパシティが本質的に欠けていることを証明していると思います。もし大規模なLLMモデルが小さなモデルにチェックリストを提供すれば、小さなLLMはより正確にこの指示に従い、複雑な問題を解決するのに十分すぎるほどの知能と指示追従能力を持っています。
しかし、現在Anthropicが企業やユーザーにより多くの価値を提供しようとしているこの方法が本当に報われるのか、それとも私たちは既存の知能の活用を最適化するというループを繰り返す状態に行き詰まっているのか、あるいは本当により強力なLLM、つまり新しいLLMが必要なのかは興味深いところです。活用方法の最適化と、より高い複雑さ、より高い知能パターンのためのLLMの最適化の間で、興味深いバランスの取り合いになるでしょう。
少しでも楽しんでいただき、有益で新しい発見があったなら幸いです。次回の動画でお会いできるのを楽しみにしています。
コメント