この原則は、フィードバックがない場合にのみ当てはまると思う。そう、オープンループ制御の層を何層も通ると、各層で精度が下がるけど、各レベルにメトリクスがあって自己調整できるなら、状況はそこまで深刻じゃないと思う。

人は、zipファイルの圧縮の例をよく引き合いに出すよね。圧縮を続けると劣化するってやつ。同じことがjpegやmp3にも言える。でも、私は「電話ゲーム」（中国のささやきとも呼ばれる）の例えを使うのが好き。自然言語がどれだけ危ういか、そしてどれだけ早く劣化するかを際立たせると思う。多くの人が、私たちがコミュニケーションを取る能力に対してあまり感心していないと思う。

LLMに同じ画像を正確に再現させようとする画像のシーケンスみたいなもので、数十回の反復の後に何かグロテスクな崩壊が起きるんだ。テキストやコードでも同じことが起こる。「意味の崩壊」って呼んでる。数年後、LLMがSharePointサイトを読み込んで要約を作り、その要約の要約を作る…みたいなことを続けると、最終的にはグロテスクなスラリーができあがると思う。ある時点で、意味のあるものをプロセスに注入するために新鮮な人間の入力が必要になるんじゃないかな。

うん、タスクを試みて、その試みから学んだ教訓の後にLLMがスキルを生成することに興味がある。初めてタスクを試みる前ではないよ。この結果はちょっと馬鹿げてて、現実のスキルが「自動生成」される方法から離れてる気がする。

これよりもひどいことがあるよ。「評価されるタスク」は、指示のマークダウンファイル1つと、不透明な検証者だけに限られてるんだ（13-14ページ）。既存のコードベースやリファクタリング、そういうのは全く関係ない。要するに、「問題定義」が広い意味で文脈に合わないってこと。だから、エージェントに自分のスキルを生成させるために与えられたプロンプトを見ると、こうなってる：> 重要：まずスキルを生成してください。このタスクを解決する前に、以下のステップに従ってください。1. タスクの要件を分析し、必要なドメイン知識、API、または技術を特定します。2. このタスクを解決するために役立つ1〜5のモジュラーなスキル文書を書きます。各スキルは：特定のツール、ライブラリ、API、または技術に焦点を当てること；該当する場合はインストール/セットアップ手順を含むこと；コード例や使用パターンを提供すること；類似のタスクに再利用可能であること。3. 各スキルを環境/skills/ディレクトリに説明的な名前でマークダウンファイルとして保存します。4. その後、作成したスキルを参考にしてタスクを解決します。自己生成されたスキルを充実させたり抽出したりするための「探求」は全くできないんだ。ウェブ検索もできないし、既存のコードベースを探ってベストプラクティスや重要なファイルを探すこともできない。タスクの説明に関する自分の妄想の中だけでしか動けない。スキルが生成された後にセッションを再起動してないみたいだし、4番目の項目からもそれがわかるよね？だから、スキルを生成するために使われた文脈をただ吐き出してるだけ。だから、空っぽのコードベースのエージェントは「もっと計画を立てる」だけじゃ良くならないよ。他の文脈、特にそのただの雰囲気でコーディングされたコードベースに新しい機能を求める場合には、誤解を招く結果だね。

いわゆる「スキル」の目的は、エージェントがその文脈に引き込んで行動できるような短いハウツーリマインダーであることだよ。もし知識がすでにモデルの中にあるなら、推論フェーズで自然に現れるだろうから、スキルとして書くことにはあまりメリットがない。特にそれが非常に関連性が高くて、表に出しにくい場合を除いてはね。

LLMが、何かを達成するために苦労した教訓を表すスキルを書くのはもっと一般的だと思う（願わくば）し、彼らが言っていることとはかなり違う。先週、Claudeに問題解決を手伝ってもらうためにスキルを作ってもらったんだけど、かなり良い出来だったよ。いくつかの問題はあったけど（Claudeは逸話的データを過剰に指定する傾向がある）、正しい方向への強い一歩だと思う。それに、「スキル」は私の意見では広すぎる。私には（Claudeが書いた）個人的なデータを使ってトレーニングを分析するためのスキルがある。再訪する予定のドメインについてかなり長いやり取りを使うと、自己生成されたスキルの余地は十分にあると思う、特にClaudeに何をしないべきかを伝えるときにはね。

うん、私の最も役立つAIツールのいくつかは、「ロールプレイセッション」で作られたスキルだよ。基本的にはエージェントに頭の中を吐き出して、質問をさせてタスクを達成する方法を見つけさせる。そして、最終的には実際の問題解決セッションから得られた証拠に基づいて、もっと厳密で洗練されたスキルにまとめるんだ。

これは、必ずしも人々が「LLMがスキルを生成する」と考えるときに思い描いていることではないことに注意することが重要です。この論文を読んでいると、そうは思えません。エージェントを労働力に導入してスキルを使うように指示するのではなく、タスクを与えるべきです。これは明らかに思えるけど、全員にとってそうとは限らないかも。（それに、研究者にとっては、事前プロンプトのスキル作成が機能しないことが確認されるのは嬉しいことだね。もし機能していたら面白かったけど。）

私は「タスクを完了する際にLLMにスキルを追加させても、通常通りに推論させるのと比べて意味のある改善にはならない」というふうに解釈したんだけど、これが論文の根本的な主張みたいだね。

ニュースメディアや人気のソーシャルメディアアカウントは、これを報道する際に適切な注意を払うだろうし、誰も誤解しないと思うよ。 :D

実際に試してみた後にスキルを自動的に更新するのは役立つと思う。そうすれば、実際のフィードバックでスキルを改善できるから。うまくいってるみたいだけど、実際に研究はしてないんだ。

その通り、エージェントにリサーチや追加データの自主性を与えなかったんだよね。ドキュメントもないし、ウェブ検索もできない、参考資料もなし。こんな風にスキルを構築する意味って何なんだろう？

エージェントによるコーディングが未来だけど、人々はまだ適応していない。パンチカードからアセンブリ、FORTRAN、C、JavaScriptへと進化してきた。それぞれのステップでより多くの抽象化が加わってる。完全に反対するわけじゃない（私も同じことを主張してきた）。でも、LLM層と他の層との間には重要な違いがあって、LLMは非決定的で、他の層は決定的だよね。それがダイナミクスをどう変えるのかはわからないけど、確実に変わると思う。

そうでなければ、モデルに「行動する前に計画を立てて、間違いを犯さないように」と言うのと似た効果が期待されるはずだ。こういった技術が実際に効果的だった以前のバージョンはなかったのかな？

これは驚くべきことでもなく、関係ないことだね。特定のモデルのためにスキルを作るとき、通常はモデルに自分の潜在的な知識だけに基づいてスキルを作らせたりしないんだ。これ！論文の唯一驚くべき点は、誰かがこのテーマについて十分に理解せずにスキルに関する論文を書いたことだね。

正直、研究者がそれを読んで実行して研究を書く前に、arxivに発表した方がいいかもね。こういうスレッドはよく見かけるけど、一つのことが仮定されて、その後に実行者たちが自分たちのやったことについてコメントし合うのが一般的だから。

LLMが自分が知っていることや知らないことについて内省するのはあまり得意じゃないと思うけど、それ以外は素晴らしいね。シェアしてくれてありがとう。

これめっちゃいいね！ブログ記事みたいに読めるし、良いスキルを書くための技術を学んでる気がする。もしかしたら、別のヒューリスティックかも。スキルは面白いブログ記事みたいに読まれるべきで、明白じゃない情報を強調するべきだね。

もし違ったらごめんだけど、これは私のLLMの感覚テストに完全に失敗してる…

ソフトウェアエンジニアリングの+4.5ppは、ヘルスケアの+51.9ppと比べると怪しいほど低いね。これも私には目立った。LLMがソフトウェアエンジニアリングのトピックに関する大量のトレーニングデータを持っていると思うし、それが大きな不一致を説明しているかもしれない。私の経験では、非常に新しいかあまり使われていないソフトウェアライブラリやツールを使うとき、スキルが本当に輝くんだ。例：Adobe React Spectrum UIライブラリ。スキルがなければ、Opus 4.6はこのライブラリを使おうとすると全く使い物にならない。ちゃんとキュレーションされたスキルがあれば、すごく良くなる。大きな違いだよ。

トレーニングコーパスは、事前学習の段階でとても大まかにしか学習されてないんだよね。推論時の計算を使って対処しようとしても、せいぜい自己整合性が少し増すだけで、最初に効果的に学習していない情報を再現することはできないんだ！