Anthropicが2024年10月にローンチしたスキル機能は、当初個人向けの設定ツールと見なされていたが、現在では企業の組織インフラとして急速に進化している。スキルは人間ではなくエージェントによって呼び出されることが主流となり、Microsoft、OpenAI、Anthropicが共通の標準フォーマットとして採用したことで、エコシステム全体に浸透しつつある。単なるマークダウンファイルでありながら、エージェントが読み取り可能な永続的なコンテキストレイヤーとして機能し、プロンプトのコピー&ペースト地獄から解放される手段となっている。個人の生産性向上から、チーム全体の専門知識の共有、さらにはエージェント主導のワークフロー自動化まで、スキルの活用範囲は飛躍的に広がっており、今後のAI活用における基盤技術として注目される存在である。
スキルの進化：個人設定から組織インフラへ
Anthropicは2024年10月にスキル機能をローンチしましたが、それ以降、LLMやエージェント、そしてOpenAIの動向によって、スキルに対する私たちの考え方は大きく変化してきました。しかし、私たちはまだそのことに追いついていないように思います。なぜなら、エージェントについて語るとき、私たちはOpenAIのことを話題にすることが多いからです。
私たちが気づいていないのは、スキルが、企業や私たち個人が仕事を成し遂げるために必要とする、正確で永続的かつ予測可能な成果の基盤となりつつあるということです。しかし、私たちは依然として、スキルを秋にローンチされた個別のものとして考え続けています。
ですから、この動画は、エージェントが読み取り可能なスキルについて最新情報をお届けするものです。この概念が初めての方は、ぜひ最後までご覧ください。10月以降に解放された主要な変化についてお話しします。そして、スキルを構築するための実用的な方法についても触れていきます。
そうです、私はスキルのリポジトリを持っています。それは私のスキルだけではなく、コミュニティの皆さんもスキルを投稿できる場所です。そこで私たちは一緒に、意味のある仕事を成し遂げるのに役立つスキルの構築方法を学んでいくことができます。
6ヶ月間で起きた4つの大きな変化
それでは、まず何が変わったのでしょうか。第一に、大きなトレンドです。スキルは6ヶ月前の個人設定から、今日では組織のインフラへと変化しました。10月の時点では、スキルは自分自身のために構築するものでした。プロンプトを入力して、作業を行う。それだけでした。
今では、チームや企業の管理者が、スキルを職場全体に展開しています。スキルは単一のアップロードとして扱われ、バージョン管理され、サイドバーから利用でき、Excel、PowerPoint、Claude、Copilotの中から呼び出すことができます。
組織の方法論は、もはや個人が頭の中にスキルを持っているというものではありません。今では、スキルをエージェントと人間の両方が読み取れるものとして、インフラレイヤー全体にわたってどう考えるかということになっています。
第二に、スキルの呼び出し元が変わりました。これは私たちが見逃していたポイントだと思います。10月には、大部分は人間がスキルを呼び出していました。しかし今では、スキルの大半はエージェントによって呼び出されています。なぜでしょうか。それは、エージェントが1回の実行で何百回ものスキル呼び出しを行うことができるからです。
私たち人間は、特定の会話の中でせいぜい数回のスキルを呼び出す程度でした。人間にとっては、計算が合わないのです。私たちは、スキルをエージェント優先で考える必要があります。
第三に、スキルは開発者だけのものではありません。これは、スキルが最初に登場したときに私が話した内容で、人々が驚いた点です。ここで改めて強調しておきます。スキルはターミナルの中だけで使うものではありません。コードを実行するためだけのスキルでもありません。
スキルは、ビジネス人生の残りの部分、そして率直に言えば個人生活の残りの部分でも使えるものなのです。そして大企業もこれに同意しています。AnthropicとMicrosoftは、スキルをCopilotに導入するためのパートナーシップを結んでいます。OpenAIがリリースを行うときにもスキルが登場します。なぜなら、スキルは今やオープンスタンダードだからです。
根本的に、スキルは、予見可能な将来にわたってAIの動作の多くを支える共通のインフラ手段として考える必要があります。
第四に、スキルが業界横断的な標準になりつつあるということは、AI時代におけるアルファの働き方について、大きく異なる考え方をする必要があるということです。私たちは、アルファがクローズドソースであるという概念に慣れており、オープンソースのものには価値がないと考えがちです。
数日前、私はエンジニアとして今非常に大きな価値を見出せる場所の1つについて話しました。それは、エージェントAI分野で構築しているプロジェクトをオープンソース化することです。そうすることで、誰もがそれを見ることができ、あなたが高レベルの人材であることが分かります。それは履歴書として機能し、その後大きなアクハイヤーのオファーを受けることができます。
同じように、マークダウンとしてのスキルは、多くの人がクローズドソースで保ちたいと考えるものだと思われるかもしれません。しかし実際に見られるのは、人々がキャンプで野球カードを交換するように、スキルを交換し合っているということです。
私たちは皆、一緒に学んでいます。私のコミュニティだけでなく、インターネット全体としてコミュニティとして、エージェントのためにスキルをどう機能させるかを学んでいます。そして、控えめなマークダウンファイルを、実際に私たちがやりたい仕事のためのエージェント呼び出し可能なコンテキストレイヤーとして機能させる方法を学んでいるのです。
ベストプラクティスは発見されるもの
私たちはそれを集団で学ぶ必要があります。なぜなら、ベストプラクティスは既知のものではなく、発見されるものだからです。1990年代にMicrosoftからCD-ROMを受け取り、プログラム全体が印刷されていたとき、プログラムは既知のものでした。取扱説明書がありました。
しかしLLMでは、私たちは皆で一緒に取扱説明書を発見していきます。そしてそれは、ツールやスキルと共にそれらをどう使うかについても同様です。私たちは皆で一緒に発見していきます。そして、コミュニティで発見すれば、それはより速く進みます。
だからこそ、そのことについてお話ししたいのです。今日スキルを使っている人々の具体例、エージェント的な未来において理にかなった使い方、エージェント向けスキルの構築方法、私が見ていて他の誰も話していないこと、そしてその理由について話したいと思います。
そして、いくつかの具体的で実行可能なステップ、スキルの実践をレベルアップするためにできることについてお話しします。
スキルとは何か：シンプルな基本構造
さて、まず10秒バージョンです。スキルとは、テキストファイルが入ったフォルダです。それだけです。必要なファイルは1つだけで、skill.mdというファイルです。そして、2つのパートがあります。上部に少しメタデータが必要で、その下に方法論と指示が必要です。
この動画では、いくつかの落とし穴について触れます。これらのファイルを構築し始めたときに遭遇する落とし穴や、過去6ヶ月間のコミュニティの学習に基づいて、壊れることが分かっているものについてお話しします。しかし、それがシンプルなバージョンです。それが何をするかです。
そして、それが行うのは、一連の平易な英語の指示をエンコードして、特定の入力セットを使って予測可能な方法で何か有用なことをするためのコンテキストをLLMに与えることだけです。つまり、これは非常にシンプルなプリミティブです。シンプルでありながら、非常に強力です。なぜなら、ほぼあらゆることについてスキルを作ることができるからです。
実際の活用例：専門家スタックと不動産業務
では、人々はこれらのスキルで何を作っているのでしょうか。Claudeにおける最も一般的な本番パターンは、私が「専門家スタック」と呼んでいるものです。開発者は、プロジェクトにスキルがいっぱい入ったフォルダをドロップできます。
1つのスキルは、曖昧な指示をPRDに変換するかもしれません。別のスキルは、PRDをGitHubのイシューに分解します。さらに別のスキルは、コードのテストを書くのを手伝います。そういったことです。
そして、この全体のコンセプトは、スキルがプロンプティングのニュアンスや苦痛の多くを取り除くということです。これは、スキルがローンチされたときにトップで呼びかけたことですが、これによって2025年における厳格なプロンプティングに関する要件の多くが緩和されます。なぜなら、今では専門家基盤としてそのスキルパックをドロップする開発者は、基本的にCursorのエージェントに「この機能を構築して」と伝え、その後Cursorは選択したLLMでスキルを呼び出して、仕事に取りかかることができるからです。
言い換えれば、エージェントは専門的な指示を必要としません。なぜなら、専門的な指示がファイルの中にあるからです。
さて、これを開発者のコンテキストから取り出して、他の多くのことに使うこともできます。Texas PaintbrushというXで知られる不動産GPの例を挙げたいと思います。彼は自分のビジネスの運営のために同じパターンを構築しました。
彼は50のリポジトリにわたって5万行以上のスキルを持っており、家賃ロール標準化、比較分析、キャッシュフロー処理、チームメンバー間の引き継ぎプロトコル、エージェントの実行などをカバーしています。そして美しいのは、はい、エージェントが実行してそれらのスキルを呼び出し、彼のビジネスで予測可能に運営を行うことができるということです。
しかし、それらすべてを書き留めることは、人間にとっても役立つことが分かったのです。新しい人をオンボーディングするとき、何が起こっているのかを理解するために掘り下げることができる、素晴らしいコンテキストレイヤーのスキルがあります。方法論はもはや誰かの頭の中にあるのではなく、リポジトリの中にあるのです。
オーケストレータースキルと高度な活用
そして、それはもっと洗練されたものになります。オーケストレータースキルを持つこともでき、より洗練されたチームが今それらを構築しています。良い例として、これはReddit全体で文書化されていますが、より良い言葉がないのでオーケストレーターと呼ばれるスキルを持つことができます。
それは、あらゆる受信リクエストを分析し、そのマスターオーケストレータースキルから呼び出すことを学習したスキルに基づいて、そのリクエストを処理するために異なるサブエージェントを生成します。リサーチに取り組むかもしれません。コーディングに取り組むかもしれません。UIやドキュメントに取り組むかもしれません。
そして、エージェントに対する単一の高レベルリクエストが、オーケストレータースキルが予測可能にするため、確実に多くのサブエージェントに配分されて仕事を完了させることができます。
そして、スキルが基盤になるという美しい点は、それらと作業を始めると、それらを中心に結集するエコシステム全体の恩恵を受けられることです。つまり、Excel、PowerPoint、Copilot、Claude、ChatGPTで同じように機能するのです。誰もがそれらを使うので、価値があるのです。
プロンプトからスキルへ：複利効果の重要性
さて、プロンプトパターンに話を戻すと、この動画の少し前に、10月にはプロンプトが個別のタスクについてやや重要性が低くなったという考えについて話しました。なぜなら、私たちの最高の仕事を取って、それをスキルにパッケージ化することで、予測可能な結果を得ることができたからです。
今日でも、人々は自分の最高の仕事の例を取って、「これをスキルに変えてください。そうすれば、この出力を確実に生成できます。私は自分でやりました。例を示しましたなど」と言います。
さて、ここで強調したいことがあります。私たちはこれを6ヶ月間やってきました。スキルを構築してきた人々は、それらを複利化してきました。なぜなら、スキルを改善できるからです。「これは正しくありません。XやYでスキルファイルを更新してください。私はこれが好きではないので」と言うことができます。そして、そのスキルが生成できるものを磨き、洗練させているのです。
そして、ずっとプロンプトを使ってきた人々は、同じものをコピー&ペーストしているだけです。言い換えれば、スキルはあなたのために複利化されます。スキルは、エコシステムへの業界投資の重みと、何かを行うための予測可能なパターンを持ち、それを書き留めることへのあなた自身のコミットメントの重みによって複利化されます。
プロンプトは同じようには複利化されません。プロンプトは優れています。プロンプトの使い方を学ぶことには依然として価値があります。疑いの余地はありません。しかし、プロンプトは世界の他の人々にとって基本的な4×4のレゴブロックになりつつあります。
あなたが望む城の残りを構築するためには、まだ特殊なレゴブロックが必要です。同じように、単なるプロンプティングから、再利用できるスキルへと移行する方法を見つける必要があります。
エージェント対応スキルの構築方法
ですから、これが新しい概念である場合、私たちはあなたをエージェント対応スキルへと飛び越えさせ、途中でよくある落とし穴のいくつかを紹介します。では、機能するスキルをどう構築するのでしょうか。
第一に、最も重要なこと。説明文は、ほとんどのスキルが失敗する場所です。悪い説明文とは何でしょうか。曖昧さです。「競合分析に役立つ」と書いたとしても、それはClaudeに全く役に立つ情報を与えません。具体性に欠けすぎて何か非常に具体的なものとマッチしませんし、関連する何にでも引っかかってしまいます。あまり役に立ちません。
良い説明文は、生成するドキュメントタイプやアーティファクトタイプを名指しします。「競合他社を分析する」や「この市場のプレイヤーは誰か」のような実際のトリガーフレーズを含みます。出力がどのように見えるべきかを述べます。
Anthropic自身のガイダンスは、実際にこの点で非常に明確です。平均して、スキルは過剰にトリガーされるよりも、トリガーされないことの方が多い傾向にあります。ですから、彼らはスキルを積極的にする説明文を書いてほしいと思っています。つまり、Claudeが自信を持ってそれを使えるようにです。
さて、ここで私が話していた落とし穴の1つを挙げます。知っておく価値のある技術的制約は、スキルの説明文は必ず1行に収まらなければならないということです。もしコードフォーマッターがスキルの説明文を複数行に分割してしまうと、Claudeはそれを正しく読み取りません。Claudeは2行目を読まず、問題が発生します。
方法論本体の5つの必須要素
次に方法論本体です。これはスキルを呼び出したら、それで何をするのかということです。5つのことが必要です。
第一に、単なるステップではなく、推論が必要です。Claudeにフレームワーク、品質基準、決定の背後にある原則を与えてください。線形的な手順しか持たないスキルは、非常に非常に脆いスキルです。認識しないケースに遭遇すると壊れてしまいます。推論は、Claudeがこの領域で一般化するのに役立ちます。
第二に、指定された出力形式が必要です。「要約を作成する」では曖昧すぎます。それはマークダウンですか。Excelですか。PDFですか。カバーしたい正確なフィールドやセクションがありますか。ここで具体的にしてください。さもないと後悔することになります。
第三に、どうかどうか、Claudeに明示的なエッジケースを与えてください。人間が常識で処理することはすべて、書き留める必要があります。Claudeが経験豊富な人間のように動作して、それらのエッジケースを知っているだけだと仮定しないでください。Claudeはそうしません。エッジケースを書き留める必要があります。
第四に、Claudeにパターンマッチングのための例を与えて、何が良いかを知ることができるようにしてください。だからこそ、スキルフォルダに複数のファイルを入れることができるのです。
そして、これは直感に反するように聞こえるかもしれませんが、今リストしたことがたくさんあるので言いますが、スキルは簡潔に保ってください。確実に起動する短いスキルは、競合する指示を持つ長いスキルを上回ります。
ですから、十分な時点を認識するための規律も必要です。そして、私はたくさんのスキルを書いてきたので、いくつかのヒントを差し上げます。ほとんどの場合、コアとなるClaudeスキルファイルに100行か150行以上を費やすべきではありません。
フォルダ内の他のファイルにいくつかの例を入れることはできますが、Claudeがそれを取得してコンテキストウィンドウを膨張させなければならないような大きなフォルダであってはいけません。
そして、その説明フィールドに注意の80%を投資して、確実にトリガーするようにすべきです。そして残りの20%は、一般的な目的の推論において非常に明確であり、Claudeがこの本体全体にわたって何をすべきか、どう推論すべきかを理解していることを確認することです。
それ以外のすべて、つまり、それは最後の数パーセントポイントに入ることができます。「ここにいくつかのエッジケースがあります。ここに良い例があります」と言えます。そして、やりすぎないでください。なぜなら、それらはClaudeが正確にトリガーする原因となるものだからです。
ちなみに、私がClaudeと言うのは、それがClaude固有だからですが、それはChatGPTでも同じです。Coworkでも同じです。呼び出す場所ならどこでも同じです。トリガーで明確である必要があり、一般的な目的の推論で明確である必要があります。そうすることで、LLMがその空間にわたってどう推論するかを知ることができます。
エージェント時代の失敗パターン
さて、人々が注意を払っていないことがあります。スキルの最大の変化の1つは、今やスキルが人間が呼び出すよりもエージェントが呼び出す方が多いと言ったのを覚えていますか。つまり、失敗が今では異なるということです。
なぜなら、過去には何かがドリフトするのを人間として見たとき、その場で修正してスキルを調整することができました。実際、この動画の前半でそのことについて話しました。今では、エージェントがスキルを使って仕事を完了させようとしますが、エージェントが間違えた場合、回復ループがない可能性があり、それは非常に高くつく可能性があります。
ですから、特にエージェントを使ってスキルを駆動することを検討している場合、行う必要があることの1つは、スキルがエージェントに対応できる準備ができていることを確認するために、スキルのパフォーマンスを定量的にテストし始める必要があるということです。
スキルに対して実行するテストスイートが必要です。それを変更する必要があります。テストのバスケットが必要です。エージェントパイプラインを真剣に受け止めるほど、エージェントが有用なツールを呼び出す能力を真剣に受け止めるべきです。
そして、スキルは有用なツールの中で王様です。エージェントに、実戦で鍛えられたスキルを与えることができるべきです。それらはテストされ、定量化されるべきです。
それが何を意味するか分からない場合、私はあなたのために説明しています。テストのバスケットを実行し、結果を定量化し、バージョン番号のようにスキルを変更し、そして戻ってきてより良い仕事をするかどうかを確認する必要があります。
スキルは常に予測可能な方法で変化するわけではありません。スキルの言葉遣いは、トランスフォーマーモデルの潜在空間の特定の部分をトリガーし、予測が難しい方法で応答できるようにします。
ですから、例えばPowerPointで「美しい」をどう言うかをいじり始めると、例があっても、会社の美学にマッチする正確な応答セットを得るために、3つか4つの異なる言葉遣いを試す必要があるかもしれません。そして、それに時間をかけてください。なぜなら、正しく設定して、会社として週に100のPowerPointを作成している場合、多くの時間を節約できるからです。
エージェント主導の設計原則
さて、エージェントベースの設計についてもう少し踏み込みたいと思います。なぜなら、私たちはこれを十分に名指ししていないと思うからです。エージェント専用にスキルを設計している場合、単にテストしているだけではありません。エージェントを主要な呼び出し元として考え始めています。
そして、それはスキルのセクションの構造について考える方法を変えます。説明文はラベルではなく、ルーティング信号になります。基本的に、その小さな説明文を通じて、エージェントにワークフローのどこに行くべきかを伝えているのです。
ですから、あなたの説明文には、エージェントがその目標で探すように与えられた結果とマッチする言葉遣いが含まれるべきです。それをより具体的に結びつける必要があります。
第二に、エージェントには契約が必要です。彼らは契約に対して目標を設定します。彼らは契約の観点で考えます。スキルの出力を契約としてフレーム化する必要があります。そして、開発者であれば、これをAPIコントラクトとして考えてください。これがSLAです。これが特定のものが提供するものです。これらが制御可能なフィールドなどです。
同じように、エージェントはスキルを見て、「これがこのスキルで得られるものです。これが得られないもので、これがこのスキルで達成できることで、これが特定の目標に対してこのスキルで進める場所です」と言う必要があります。
それが契約の意味です。それは本質的に、エージェントがスキルについて簡単に発見できる宣言的合意であり、エージェントが自信を持って正しい選択をすることを可能にします。
第三に、そして10月にはエージェントが同じ方法ではなかったので考えなかったことですが、構成可能性がエージェント第一のスキルの中核にある必要があります。言い換えれば、スキルを問題を解決するものとして考えるのではなく、むしろ、チェーンの下流で他のことをしている別のエージェントやサブエージェントに引き渡される必要がある出力を生成する必要があるものとして考えてください。
チケットが複数のステップを経る必要があるビジネスプロセスを経て、エージェントがそれを処理する必要がある場合、各ステップで、エージェントがスキルを呼び出す場合、そのスキルと連携するエージェントによって生成された出力が、次のエージェントに引き渡すのに正しいものか、またはエージェントがそれを読み、理解し、必要に応じて別のスキルを呼び出すためにプロセスを進めるために引き渡すのに正しいものかを考える必要があります。
エージェントとスキルのエンドツーエンドの体験を考え抜いてください。なぜなら、もしそうしなければ、1つの出力としてだけ考えれば、引き渡しに問題が発生する可能性が高いからです。
最後になりますが、私はこれをよく言いますが、ハードワイヤリングは重要です。エージェントの動作をハードワイヤリングしようとしている場合は、スキルではなくスクリプトを使用してください。スキルは単なる平易な英語です。
エージェントはそれらを尊重します。エージェントはしばしばそれらに従います。しかし、本当にハードワイヤリングしたい場合は、より決定論的に進んでください。スクリプティングの世界に入ってください。そして、それを恥じないでください。それはあなたがAIが苦手だという意味ではありません。それは、あなたがAIが何ができるかを知っているということです。
エージェントが強力である理由の一部は、より大きな問題セットを解決するための汎用ツールだからです。それは、全体的なソリューションの一部として、途中で決定論的ツールを呼び出すことができないという意味ではありません。
チームとスキル：3層のアプローチ
それが、エージェントとスキルについての考え方です。チームとスキルについてはどう考えるべきでしょうか。そして、これは実際に重要です。なぜなら、私たちは今、人間とエージェントを一緒にチームで行っているからです。私たちのチームは今、多くのビジネスプロセスにおいて、人工知能と人間の混合で構成されています。
その世界では、スキルが何をするかというと、すぐに実行可能なコンテキストとして機能します。私はここに立って、あなたのコンテキストレイヤー全体がスキルである必要があると言うつもりはありません。それは明らかに間違っています。なぜなら、非常に多くのコンテキストがスキルの形をしていないからです。
しかし、物事を成し遂げる必要がある場合、そして仕事の多くは処理して次に進むことに関するものです。スキルは、エージェントが特定の正しいスキルをコンテキスト効率的な方法で呼び出し、特定の正しい結果を得ることができる方法で文書化し、人間もそれを読むことができる限り、しばしば非常に便利な方法です。それがマークダウンの強力な点の1つです。エージェントと人間の両方が読めるのです。
私はあなたに提案したいのですが、高パフォーマンスのチームは、スキルの扱い方について3つの層を持っています。第1層は、私が標準スキルと呼んでいるものです。それらは組織全体でかなり一貫しています。ブランドボイスがここに入ります。フォーマットルール、承認されたテンプレート、そういったことです。いつも同じようにやることです。
それらのスキルは非常に一貫しており、Claudeを含む多くのAIのチームおよびエンタープライズアカウント、Copilotもこれをやっていると思いますが、それらのスキルを広く提供できます。「私たちのブランドボイスはこれです。これが私たちのブランドボイススキルです。みんな使ってください」と言えます。完全に理にかなっています。多くの人がやっています。まだやっていない場合は、やることを考えてください。
第二に、方法論スキルです。それが第2層です。これは、組織やチームが高価値の仕事をどのように実行するかです。そして、予測可能にやりたいのです。それは、クライアント成果物をどう構造化するか、またはシニアプラクティショナーが通常どのように仕事を成し遂げるかのようなものです。彼らの技術を動かすもの。
第2層スキルを考えてください。これらの方法論スキルを、新入社員に伝えたいこと、そうでなければ学ぶのに数ヶ月かかることの良い例として考えてください。それが第2層スキルであるべきものの良い例です。
ちなみに、これはエンタープライズ管理者が展開するのが簡単なものではありません。なぜなら、エンタープライズ管理者は通常、第2層の高技術方法論スキルの種類には精通していないからです。それらは通常、会社全体の個別チームのシニアプラクティショナーの頭の中に存在し、それらの頭から出て、より共有可能なものになる必要があります。
なぜなら、しばしばそこにアルファがたくさんあるからです。チームで最も熟練したプロダクト担当者からプラクティショナースキルを得ることができれば、残りのPMチームが恩恵を受けます。エンジニアリングも同様、カスタマーサクセスも同様、そういったことです。
さて、第3層、そしてこれは私たちの多くがやっていることですが、個人のワークフロースキルです。私たちが行う、机の下で行われるようなもので、日々の仕事に役立つものです。せいぜいチームが理解できるものが必要ですが、実際には組織の生産性のためにこれを表面化していません。
第3層スキルについて警告したいことの1つは、ラップトップにだけ置いておきたくなるかもしれないということです。机の下に、どこかのダウンロードフォルダに。どうかそれをしないようにしてください。
その理由は、休暇中や病気のとき、または仕事で何かが起こったときに、誰かがあなたが設計した方法でツールを使って仕事を完了させられることを願うことがいつになるか分からないからです。代わりに、彼らは掘り起こして、悪態をつき、パスワードを尋ね、スキルを機能させるために誰が何をするか分からないことになります。
よりシステム的に考えたいのです。あなたの世界を、本質的にスキルが確実にキャプチャできるアクションやプロセスとして考え、人間やエージェントが読むことができるものとして考えてください。そして、その専門知識に対してどのレベルのアクセスを望むのか。スキルは本質的に専門知識をエンコードします。
コミュニティスキルリポジトリの構築
さて、多くのスキルマーケットプレイスがあり、多くのスキルGitHubがあるのに、なぜNateが別のものを始める必要があるのか疑問に思うかもしれません。それは公正な質問です。
最もシンプルな答えはこれだと思います。私たちはたくさんのスキルを持っています。もしあなたがテクニカルエンジニアなら、私たちはドメインスターターパックスキルのようなものをたくさん持っています。私たちが欠けていると思うのは、実際の問題を解決するためのドメイン固有のスキルです。
ですから、家賃ロール分析を行っているテキサスの不動産業者の例を挙げると、それはドメイン固有のスキルであり、ランダムなGitHubリポジトリで見つかる可能性が低いものです。
ですから、面白い機会の1つだと思うのは、コミュニティ内で非常に幅広い領域が代表されているので、「みんなで集まって、私たちにとって本当に並外れた価値を加えていると感じている有用なスキルを共有しましょう。そして、みんなで野球カードを交換しましょう」と言い、必要なスキルを手に入れて、お互いから学び始めることです。
これは、OpenBrainをGitHubに置いたときに取ったアプローチとまったく同じです。そして、これは実際にOpenBrainのセクションとして存在することになります。ですから、OpenBrainを使っている場合、これはあなたのためにOpenBrainに直接統合され、非常に簡単になります。同じGitHubリポジトリに入り、呼び出すことができます。問題はありません。
Simon Willisは10月に、スキルはMCPよりも大きな問題になると思うと書いていました。私は彼が正しいかもしれないと思いますが、今のところ、それを実現するための流暢さを持っていないと思います。
そして、私がこのビデオを作っている理由の一部は、スキルがどこに進化する必要があるのか、スキルを作成する際の私たちの流暢さがどこに進化する必要があるのかについて、私たちは特に眠っていると思うからです。エージェントと人間のための真に実行可能なコンテキスト基盤であるスキルを持つことができる地点に到達するためにです。
それが私が行きたい場所であり、だからこそ私はコミュニティスキルリポジトリを作成しています。それは単なるプラクティショナーライブラリです。知識作業があります。ワークフロータイプごとに整理されています。そこにあるすべてのスキルに対して一貫して適用されるエージェント可読性バーがあります。ですから、それらは精査され、競合分析、財務モデルレビュー、取引メモ草案、研究統合、会議統合など、非常に非常に具体的なものに入り込みます。
そして、できる限り広範囲にカバーするつもりです。そうすることで、コマンドラインから気にするスキルを呼び出すことができ、そのスキルパックから必要なスキルだけを追加でき、そのエージェント可読性バーの一部が組み込まれているものを持っていると自信を持つことができます。
実践的なアクションステップ
さて、いくつかの実行可能なヒントを残したいと思います。ここで迷子になりやすいと思います。第一に、スキルをどこから始めるかで苦労している場合、このGitHubリポジトリのすべてが頭の上を越えているように感じる場合は、繰り返し行ってきたことを見て、自問してください。「これを週に1回、2回、3回やっている場合、これをスキルに変えることができるだろうか」と。
そして、好みのAIと話してください。正直なところ、今ではすべてスキルができます。そして、あなたが行った会話からskill.mdを作るのを手伝ってもらうように頼んでください。それらの会話からの情報をフィードし、うまくいったと思ったこと、うまくいかなかったと思ったことを伝え、レースを始めましょう。
さて、もう少し先に進んでいる場合、「いや、分かっている。GitHubリポジトリにいる。待ちきれない」という場合。素晴らしい。エージェント対応スキルについてあなたの言葉で考え、自問してください。それらの引き渡しを考え抜いていますか。最終的な出力を考え抜いていますか。契約の考え方を中心にスキルを構造化していますか。
それらは、私たちが今スキルについて眠っていると思うことであり、もっと真剣に受け止める必要があると思います。
チームやエンタープライズレベルを見ている場合は、私が話した階層化について考えてください。これは個人規模のものですか。これはチームで最高の人の専門知識を表すものですか。それはどこにでもある必要があるブランド標準のようなものですか。それは、展開方法や考え方を形作ります。
この動画の前半で述べたことに戻ります。スキルについて重要なのは、それらが複利化するということです。スキルは本質的に、エージェントや人間が従うことができるワークフローの成功した実行の学習記録を表しています。
そして、そのことをより上手に行うにつれて継続的に進化させれば、将来のよりスマートなエージェントや将来のチームが、その過程でそのスキルを実行し、プロンプティングに戻ることなく構築できる記憶可能な方法を持つことになります。
コピー&ペースト地獄から解放されます。そして、それがスキルが実際に行うことです。プロンプトは会話から消えると蒸発してしまいます。消えてしまいます。再度貼り付けなければなりません。プロンプトライブラリを掘り返さなければなりません。
スキルは永続するものであり、正しく設定すること、特にエージェントが今まで以上にスキルを呼び出している世界では、それが重要です。幸運を祈ります。
これらのスキルに関するヒントが役立つことを願っています。私はあまり見つけられませんでした。これを掘り下げましたが、スキルに関する非常に多くのヒントが個人の生産性に焦点を当てています。私はここで全範囲をカバーしたかったのです。チームに入りたかった。エージェントに入りたかった。人々が壊れることを発見している具体的なことや、人々が機能することを発見していることに入りたかったのです。
ですから、これが多かった場合は、このトランスクリプトをChatGPTに貼り付けてください。それを解析して、今週実行できる何か実行可能なものを持って戻ってきてください。
コメント