腾讯 SkillHub：10 万スキルから有用な 20% を見つける仕組み

オリジナル記事：テックメディア「騰訊プログラマー」より

2026年8月10日 17時36分 広東省

AI 時代におけるコミュニティコンテンツのガバナンスと配信戦略

AI の普及により、オンラインコミュニティで生成されるコンテンツは爆発的に増加しています。その結果、情報の質を維持し、ユーザーに価値ある情報を届けるための「ガバナンス」と「配信」が以前にも増して重要になっています。

まず、ガバナンスの観点から考えましょう。従来のルールベースや人間による手動審査だけでは、膨大な量の投稿に対応しきれません。AI を活用した自動モデレーションシステムの導入が不可欠です。具体的には、自然言語処理（NLP）技術を用いて、誹謗中傷、スパム、誤情報などをリアルタイムで検知・フィルタリングします。ただし、AI による判定は必ずしも完璧ではありません。文脈の理解や文化的なニュアンスの把握において限界があるため、重要なケースでは人間の審査員が最終判断を下す「ハイブリッド型」のアプローチが効果的です。

次に、配信（ディストリビューション）についてです。ユーザー一人ひとりの興味関心は多様化しており、画一的なアルゴリズムでは満足度を高めることが難しくなっています。AI を活用したパーソナライズドレコメンデーションシステムの構築が鍵となります。ユーザーの行動履歴、閲覧時間、エンゲージメント（いいね、コメント、シェアなど）を分析し、その人の好みに合わせたコンテンツを最適化して表示します。

しかし、ここで注意すべきは「フィルターバブル」現象です。AI がユーザーの既存の興味ばかりを強調すると、視野が狭まり、多様な意見に触れる機会が失われる恐れがあります。そのため、アルゴリズムには「意外性」や「多様性」を組み込む工夫が必要です。例えば、定期的に異なるジャンルのコンテンツを混ぜて表示したり、コミュニティ全体の健全性を保つためのバランス調整を行ったりすることが求められます。

さらに、透明性と説明可能性も重要な要素です。なぜそのコンテンツがおすすめされたのか、ユーザーにわかりやすく説明できる仕組みが必要です。これにより、ユーザーはアルゴリズムへの信頼を高め、プラットフォームに対する不満を軽減できます。

まとめると、AI 時代におけるコミュニティ運営では、AI を活用した効率的なガバナンスと、人間中心の配慮を組み合わせたスマートな配信戦略が不可欠です。技術の進化に合わせて柔軟に対応し、常にユーザー体験の向上を目指していくことが成功への道筋となります。

著者：趙秀雯

AI 時代、プラットフォームはどのようにコンテンツのガバナンスと配信を行っているのか？Skill Hub は国内最大級の Skill コミュニティの一つとして、従来のコンテンツコミュニティである小红书（紅書）、知乎、App Store と比較して、プロモーションや検索においてどのような違いがあるのだろうか。また、ユーザーが本当に価値のある 20% の Skill をいかに迅速に見つけ出すか。本稿では、Skill Hub がこれらの課題に対して抱く考えと実践を深く解読し、順を追って解説する。

SkillHub は中国ユーザー向けに最適化された AI スキルコミュニティです。今年3月のサービス開始以来、OpenClaw エコシステムの急速な発展に伴い、大きな注目を集めています。

国内最大のスキルコミュニティの一つとして、当コミュニティで最も頻繁に寄せられる質問があります。

「プラットフォームには多くのスキルが揃っていますが、どれが本当に使いやすいのか見極められません。おすすめのスキルはありますか？」

実は3ヶ月前、SkillHub に登録されていたスキルの数は約5万件でした。その時点でユーザーは選択肢の多さに迷走し、「どのスキルをインストールすべきか」で頭を抱えていました。

膨大な資産を持つプラットフォームにおいて、供給されるスキルの数と、それらがもたらす価値は必ずしも比例しません。AI の登場により、この問題はさらに顕在化しました。

かつてはスキル制作自体に一定のハードルがありましたが、現在では AI が文章作成、コーディング、コンテンツ制作のコストを劇的に低下させました。クリエイターは AI を使って数行の指示でスキルを生成し、即座に SkillHub に公開します。その際、スキルの唯一無二の識別子を先に確保してしまうのです。

まるで500年前のドメイン名争奪戦のような状況です。

よく言われる通り、二八の法則が示すように、真に価値のあるコンテンツは全体の 20% に過ぎません。プラットフォームが急成長する中で、私たちは初期段階で粗放的に行っていた供給拡大から、より体系的な推薦・配信・ガバナンスへと転換を迫られています。この過程において、消費者、クリエイター、そしてプラットフォームの三者関係をどう調整するかが、SkillHub にとって極めて重要な課題となります。

消費者は、信頼性が高く自分に合った Skill を素早く見つけたいと考えています。クリエイターは、質の高い作品が公平に評価され、有効なフィードバックを得られることを望んでいます。一方、プラットフォーム側は、供給の増加、配信効率、そしてコミュニティの信頼性のバランスを保つ必要があります。

現在までに、SkillHub には 10 万個以上の AI Skill が登録され、月間のダウンロード数は 1,000 万回を超えています。データは今もなお上昇傾向にあります。そこで本稿では、この経験から得られた教訓を振り返り、AI 時代生まれのネイティブコミュニティである SkillHub が、急増するコンテンツの中で「本当に価値のある Skill」をどう見つけ出し、検証し、広めていったのかについて解説します。

この課題に対し、私たちは主に三つの取り組みを行いました。

一つ目は、信頼できる品質の評価基準（コординート）を確立することです。

二つ目は、限られた露出機会を、より価値のある供給に優先的に割り当てることです。

三つ目は、こうした発見機能を人間だけでなく AI 自体も直接利用できるようにすることです。これが、AI 時代における従来のコミュニティとの最大の違いと言えます。

一、コミュニティの伝統的な手法は依然として有効だが、SkillHub はもう一つ問われる必要がある

SkillHub の実践を語る前に、最も基本的な問いに戻ってみましょう。一般的なコミュニティでは、コンテンツのガバナンスと配信問題をどう解決しているのでしょうか？成熟したコミュニティが膨大な供給を扱う際、通常は以下の四つの手法を採用しています。

第一に、「供給を整備する」ことです。チャンネルやカテゴリ、タグ、検索機能を活用し、無秩序な状態にあるコンテンツをユーザーが理解しやすい構造の中に整理します。例えば、豆瓣（ドゥバン）や知乎などが該当します。

第二に、「トラフィックを配分する」ことです。人気ランキング、新着リスト、パーソナライズされた推薦、編集者の厳選などを通じて、限られた表示枠を消費される可能性が高いコンテンツに割り当てます。「何をまず見るべきか」という問いへの回答です。App Store がその典型例です。

第三に、「ガバナンスの门槛（しきい値）を設ける」ことです。公開審査、信用認証、通報機能、権限制限、削除などの仕組みを用いて、明らかに質が低いまたはリスクのある供給をフィルタリングします。「何を可視化すべきではないか」という問いへの回答です。小红书（シャオホンシュー）がこの手法を採用しています。

第四に、「フィードバックの循環構造を作る」ことです。クリック、滞在時間、購入、お気に入り登録、評価などの行動データが継続的にプラットフォームに戻り、コンテンツが真にニーズを満たしているかを判断する材料となります。同時に、クリエイターには次の改善点を示す役割も果たします。淘宝（タオバオ）がこのモデルの代表格です。

SkillHub にとって、これらのコミュニティ製品における従来のメソドロジーは依然として有効です。道路の交通手段が自転車やガソリン車から電気自動車へと移行したように、車両が変わっても、信号機、標識、横断歩道といったルール自体には変化がありません。

しかし、この手法を SkillHub に適用しようとした際、一つの疑問が浮かびました。記事が読了されたり商品が購入されたりすれば、プラットフォームは比較的明確な消費シグナルを得ることができます。一方、Skill の真の使用は、ユーザーが SkillHub からダウンロードし、Agent 上で実行して初めて成立します。つまり、Skill のフィードバックには時間遅れ（ラグ）が生じるのです。クリックやダウンロードが行われたからといって、その Skill がタスクを成功裏に完了したとは限りません。

したがって、SkillHub においては、カテゴリ分類、ランキング、行動データが依然として重要である一方で、それだけでは不十分です。「どのように推薦するか」を議論する前に、従来のコミュニティでは深く扱う必要のなかった能力を補完する必要があります。つまり、「その Skill は本当に良いのか？その根拠は何か？」という問いに答える仕組みです。

二、品質評価基準（TRACE）の確立：「良い Skill とは何か」を定義する

如果把 Skill 比作代码，那么审核 Skill 的过程就类似于进行 Code Review。

在最初面对如何判断上架后的 Skill 是否值得推荐这一问题时，我们主要考虑了两个核心因素：一是缺乏统一标准会导致评估结果因人而异；二是随着平台内容供给的激增，如何持续高效地评估数万量级的内容也成为必须解决的难题。

TRACE 评测体系的构建正是源于这些思考。我们的目标是将“这个 Skill 好不好、是否值得信赖”这种模糊的主观感受，转化为可量化、可解释的质量坐标。在设计这套体系时，我们既参考了业内如 Anthropic 发布的 Skill 规范标准，更基于对用户痛点的深刻洞察以及对 SkillHub 定位的深入思考。

SkillHub 创立之初，国内尚未形成规模化的 Skill 社区。当时我所在的团队——腾讯轻量云，于今年 1 月完成了对 OpenClaw（龙虾）的云端部署适配并上线市场；到了 3 月，我们在深圳腾大楼下举办了一场公益装机活动，让“龙虾”彻底火到了老年人群体中。彼时，整个 Agent 和 Skill 生态仍以海外为主，用户的首选往往是 ClawHub。然而，这里存在一个非常显著的问题：海外的 Skill 未必适用于国内环境，它们可能面临内容合规性风险、安全隐患，或是因海外产品/API 无法在国内调用而导致功能失效。

因此，首要任务是对每个 Skill 进行安全检测与环境适配性评估，这也正是我们将 Trust（可信任度）置于整个测评体系首位的原因。这一举措深刻体现了 SkillHub 的核心定位——一个专为中国用户优化的 AI Skills 社区。

在 TRACE 体系的制定过程中，我与开发团队反复打磨了多个版本。Skill 看似简单，本质上不过是封装了场景使用定义规范和产品 API 的纯文本文档。但在实际使用中，许多问题却是用户在选型时容易忽视、却极为关心的痛点：例如是否考虑了渐进式披露（Progressive Disclosure），导致用户消耗过多的 token；或者在 Agent 调用 Skill 时，由于自然语言 Prompt 过于发散，Skill 能否准确识别用户意图并妥善处理能力边界……这些都是直击用户的硬伤。

基于此，我们构建了 TRACE 评测体系，将模糊的评估问题拆解为五个独立的观测维度，对每个 Skill 进行打分：

TRACE 维度及其子维度主要回答的问题

Trust（可信任度）

国内适配性、安全性扫描

关注元数据的真实性、声明与实现的一致性、来源可信度以及安全边界。

Reliability（可靠性）

异常处理、功能完整性、运行稳定性

检查依赖完整性、异常处理机制、重试策略、超时表现及潜在的实现缺陷。

Adaptability（适用性）

能力边界定义、触发方式

评估参数兼容性、异常路径覆盖、版本差异适应度、环境容忍度与边界条件处理能力。

Convention（规范性）

反模式与 FAQ、文档质量、渐进式披露、结构清晰

检查文档结构、参数 Schema、目录命名规范及依赖声明是否符合工程标准。

Effectiveness（有效性）

输出准确性、内容完整度、创造力与增值、开箱即用度

判断产物是否正确、是否符合用户意图，以及 Skill 能否真正高效完成目标任务。

有了这份评测体系后，接下来的挑战是：如何让平台内数万个 Skill 快速且稳定地通过这套检查？为此，我们重点建设了以下基础设施。

2.1 从单体串行，走向五路并行

従来の評価プロセスでは、単一のエージェントが 5 つの次元を順次処理していました。この手順は理解しやすいものの、各次元が増えるごとに待機時間が長くなり、プラットフォームが大量の Skill を扱う際にはスループットのボトルネックとなります。

クリエイターは Skill のアップロード直後に公開したいと考えており、プラットフォーム側も公開前に TRACE 評価でスコアリング・審査を行いたいと考えています。そのため、評価にかかる時間を短縮することが最優先課題でした。

そこで私たちは T、R、A、C、E を 5 つの並列パスに分割しました。これらは同じ Skill コンテキストを共有し、それぞれが判断を行い、最後に構造化された検証、競合処理、結果集約を行います。典型的なシナリオでは、評価目標にかかる時間が約 10 分から約 1 分に短縮されました。各次元は独立して拡張・最適化が可能であり、新しいルールを追加する際にも既存の体系を根本から作り直す必要はありません。

image 2.2 メモリレベルでの読み込みで、Agent が Skill の理解に集中

評価におけるもう一つの技術的課題は、Agent がどのように Skill を読み込むかです。

もし 5 つの評価パスがそれぞれファイルを解凍・読み込むとすれば、それは 5 人の検査員が各自コピーを手に取っている状態と同じで、処理が遅く、バージョンの不整合も発生し得ます。私たちは Skill パッケージを一度メモリにロードし、list_files や read_file といった制御されたツールを通じて必要な分だけ読み込むようにしました。

これにより重複操作が減り、5 つの次元が同じ内容を確認できるため一貫性が保たれます。また、読み込み範囲は現在の Skill パッケージ内に限定され、評価システム自体もセキュリティ境界を遵守します。

2.3 各評価に「工番」を付与して追跡可能に

1 回のモデル呼び出しでレポートを生成することはできても、継続的な運用には不十分です。新バージョンの自動再評価、失敗したタスクのリトライ、異常結果の手動処理などが必要です。そのため、プロセスを「検出—キュー登録—スケジューリング—評価—審査—データベース保存」の 6 つのステップに分割しました。各 Skill には固有の評価タスクとステータスが割り当てられ、どの段階で失敗しても記録・復旧・追跡が可能です。

これにより TRACE は、単発的な AI 判断から、長期間運用可能な品質生産システムへと進化しました。

現在、私たちは Trace の評価機能を活用し、SkillHub に登録されている数万件のスキルを一つずつスキャンしました。その結果、各スキルについて簡易な評価レポートを生成し、ユーザーが質の高いスキルを迅速に選別・見極められるよう支援しています。

同時に、クリエイター向けにはより詳細な評価レポートを提供し、クリエイター管理画面に統合しました。これにより、クリエイターはスキルの全体像や各細分化された項目での具体的な得点、そして改善のためのアドバイスが明確に把握できます。その結果、質の高いスキルを効果的に継続して進化させることが可能になります。

この仕組みは、クリエイターの作品継続的な最適化を支援するだけでなく、プラットフォーム側でも高品質なスキルの蓄積を促します。最終的には、利用者（消費者）、クリエイター、そしてプラットフォームの三者がWin-Winとなる関係を実現することを目指しています。

三、TRACE は「健康診断報告書」のようなものだが、Skill が本当に使えるかどうかをどうテストするか？

これまでの TRACE 評価では、主に静的解析を通じて Skill の信頼性を判断してきました。しかし、これだけでは Skill が「何を書いているか」は分かりますが、「実行時に実際に何をするか」まで証明することはできません。

例えば、インストールスクリプトが実行できない場合や、依存ライブラリのバージョンが互換性を持たないケースがあります。

また、ドキュメントでは特定の機能がサポートされていると謳っていても、実際の Agent がその機能をどのように呼び出せばいいか分からないという問題も起こり得ます。

さらに、結果を生成することはできても、それが本当に課題解決につながっていないケースもあります。

そこで私たちは、「クローズドなテスト環境」——つまりクラウド上で隔離された実行環境——を整備しました。開発者は SkillHub 内で直接 Skill を試走し、Agent 内での動作を確認できます。また、特に優れた実装例については、その成果を詳細ページ上の「運用事例」として蓄積・公開することも可能です。

開発者は SkillHub でスキルを直接試行し、実際の会話や実行結果を確認できます。

3.1 一度の試運転で実際に何が行われるのか

クラウド上で隔離された実行環境は、対象バージョンを解析し、Skill ファイルを隔離されたワークスペースに配置します。その後、エージェントが SKILL.md を読み込み、その指示に従ってスクリプトや資料、ツールを呼び出します。環境から「準備完了」の信号が返されるまで、タスクは開始されません。これにより、「実行していないのに実行しているように見せる」という一般的な誤動作を防ぎます。つまり、モデルが Skill の名前を知っており、それらしい回答を生成できても、実際にロードされて使用されていないケースを排除できるのです。

ファイルの読み書きや依存関係のインストール、ターミナルコマンドの実行などは、すべて独立したワークスペース内で実行されます。プラットフォーム上の業務サービスと信頼できないコードは互いに隔離されており、タスク終了後には必ずクリーンアップと検証が完了し、環境を安全に再利用できるようになります。こうした複雑な隔離設計の究極的な目的は一つです。ユーザーが目にする結果が、まさにこの Skill の実際の実行によって得られたものであることを保証することです。

imageユーザーがプロセスを理解し、切断された後でも再開できるようにする

エージェントによるタスク実行は、分析、ファイル読み込み、ツール呼び出し、回答生成といった複数の段階を経ます。私たちはこれらの基盤となるイベントを整理し、ユーザーが理解しやすい実行トレースとして提示します。「現在どのステップにいるか」「ツールの呼び出しは成功したか」「タスクは正常に完了したのか、それとも予期せぬ中断があったのか」です。これにより、ユーザーは結果がどのように生成されたかを判断でき、問題の特定も迅速に行えます。

実際のセッションでは、ネットワーク切断やサービス切り替え、環境のリスタートといった事象も発生します。プラットフォームはメッセージ、ファイル、そして重要な実行状態を保存し、条件が整った場合に元のタスク現場を復元します。ここで最も重要で、かつシンプルな判断基準があります。「チャット履歴が残っているからといって、実行環境が生きているわけではない」という点です。ページ上で「再開可能」が表示されたとしても、ワークスペースと実行権限が実際に回復していることが必須条件となります。

3.3 実行環境の結果を可視化するための「デモケース」の蓄積

現在、私たちはクラウド隔離実行環境の機能を開発者に開放する計画を進めています。開発者が Skill をアップロードすれば、プラットフォーム上でその Skill が実際の環境でどのように動作するかを直接検証できます。また、実行環境内でデモケース（展示用事例）を生成する機能も提供し、利用者が Skill の使い方を素早く理解できるようにしています。

このため、SkillHub では「セッション」と「公開ケース」を異なるオブジェクトとして設計しました。実行環境におけるセッションはリアルタイムで継続可能であり、完全なコンテキストと実行状態を含みます。一方、デモケースとは、実際のセッションから選ばれたメッセージやファイルのスナップショットです。

フロントエンドでは、Skill 作成者はエージェントとの多輪対話を通じて思考プロセスやツール呼び出しを観察できます。その後、選択モードに入り、最も効果を示す回答を選び抜きます。さらに、ケースのタイトルと補足説明を入力することで、デモケースが生成されます。

image作成者は、実際の実行環境から代表的な質問と回答を選び抜き、Skill 詳細ページで表示されるデモケースとして蓄積できます

TRACE（追跡機能）、クラウド隔離実行環境、そしてデモケースは、それぞれ異なるレベルの問題を解決しています。

• レベル：解決する問題 / 形成された証拠
• TRACE：プロセスの可視化 / 実行の経路と状態を示すログ
• クラウド隔離環境：安全な実行保証 / 実際の動作結果と検証データ
• デモケース：ユーザーへの理解促進 / 具体的な使用例と成果物の提示

TRACE 测评：这个 Skill 是否可信、规范且易于理解

• 结构、依赖关系、说明文档和静态扫描结果

云端隔离运行环境：该 Skill 在真实环境中能否被 Agent 正确使用

• 执行轨迹、工具调用记录、工作区变化及最终结果

效果案例：此次成功运行是否值得其他用户参考与复用

• 经过筛选、审核并持久化保存的真实会话快照

四、有了质量底座，接下来如何让更多优质 Skill 获得曝光？

大多数内容社区依靠点击、收藏、下载等行为数据进行排序。这些指标能在一定程度上反映内容的受欢迎程度，毕竟都是用户用脚投票的结果。但正如前文所述，SkillHub 与普通内容社区不同：用户来到这里不仅是为了浏览内容，核心诉求是将某个 Skill 中定义的能力整合进 Agent，以完成真实任务。因此，在构建榜单时，我们不仅挖掘用户行为数据，还结合 TRACE 测评等多维度指标，生成最终的榜单结果：

• 榜单类型：想解决的问题
• 推荐榜：找到近期质量和数据都相对稳定的 Skill
• 飙升榜：捕捉时效性更强的新趋势
• 下载榜：保留最直观的长期热度入口
• 最新榜：给新品机会，同时过滤明显噪音

具体执行中，长期霸榜的“装机必备”类 Skill 已在下载榜充分体现其长期热度。因此我们在榜单设计时，对推荐榜和飙升榜中的此类内容适度降权，为近期优质供给腾出空间。最终，人工运营始终存在：新品需要冷启动，垂直内容需要被“捞取”，热点需要专题承接，头部固化需要人为校准。规则、算法与运营共同将海量供给压缩成用户可选择的有限集合。

专题案例：与微信团队合作的微信小程序 AI 开发专区

如果说榜单像实时路况，标签则更像是地图。

刚开始做标签调研时，我发现几乎所有同类产品都设有分类。正如正文开头提到的，这是社区常规手段之一——“别人有，我们也做一个”。但深入思考后我们会问：在 SkillHub，标签究竟要解决谁的什么问题？

标签分类更像是一张地图，将庞大的 Skill 世界划分为可理解的区域。我们一开始并未把标签做成一组任意扩张的词汇，而是建立了受控、分层的分类体系：

• 12 个一级主分类，回答“我该去哪里逛”；
• 每个 Skill 归属 1 个一级分类、1 至 3 个二级类目，回答“它具体能做什么”；
• 行业类目回答“它适合哪个行业”；
• “需要 API Key

Skill 界には、統一された分類タグ体系を持たず、AI に任せて意味理解に基づき自動でタグ付けするコミュニティも存在します。効率優先の時代においては、これは一見すると合理的な解法のように思えます。迅速にリリースし、設計について深く考える必要がないからです。

しかし、私が見る限り、競合他社の結果を比較した際、このアプローチには明らかな欠陥があります。プラットフォーム上の Skill は膨大ですが、タグ体系が恣意的で、中には「なぜこれがタグになるのか」理解できないものさえあります。その結果、ユーザーが適切な Skill を見つける効率は向上せず、むしろ理解コストが増大してしまいました。

もう少し自制し、プラットフォーム側でタグ体系を統一的に定義すべきです。また、タグ分類は多すぎないよう制限する必要があります。現在、SkillHub では「おすすめ」「急上昇」「ダウンロード数」「最近の新作」などの視点から閲覧でき、「ソース」「シーン分類」「API Key が必要か」といった条件で絞り込みも可能です。詳細ページでは、1 次分類と 2 次カテゴリが明確に表示されます。

ランキング、検索、特集記事、コンテスト、そして今後のエージェント（Agent）による検索まで、すべてが同じ「言語」を話すようになりました。

五、人間に優しいだけでなく、AI も Skill を見つけられるようにする

Skill の対象者は誰でしょうか？もしユーザー自身が Skill を探すのではなく、代わりにエージェント（Agent）が探すとしたらどうなるでしょう。

実際の利用シーンでは、ユーザーは SkillHub サイト上で Skill を閲覧・検索するだけでなく、エージェントを通じて AI に直接 Skill の推薦や発見を依頼します。

現在、海外で最も広く支持されている Skill 用オープンソースプラットフォーム「skills.sh」には、「find skill」という機能があり、ユーザーが適切な Skill を発見するのを支援しています。そのロジックは非常に明確です。まずタスクとドメインを理解し、人気ランキングを優先して確認します。その後、CLI（コマンドラインインターフェース）でのキーワード検索を行います。推薦を行う前には、インストール数やソースの信頼性、GitHub のスター数を重点的にチェックし、最後に候補となる Skill とそのインストール方法を提示します。

「skills.sh」の検索機能は、単語に対しては部分一致を、複数語のクエリに対しては意味検索（セマンティックサーチ）を採用しており、ランキングは主にインストールデータに基づいています。

この方法は、GitHub や開発者エコシステムを中心とした供給源には適しています。しかし、SkillHub が直面しているのは、大量の中国語による自然言語でのニーズや、クロスシーンなタスク、そして既に確立された分類・評価・ソース体系です。そのため、単に「検索コマンド」をコピーするのではなく、中国語特有の Skill 発見戦略を一連のプロセスとしてパッケージ化し、独自の「find skill」を実現しました。

具体的には以下の手順で行います：

1. ユーザーの発言からタスクの意図、ドメイン分類、および中英語の候補単語を抽出します。
2. 原句を一度だけ検索するのではなく、同義語や上位概念に対して 2〜4 グループの拡張を行います。
3. SkillHub のリスト API を複数回呼び出し、必要に応じて 1 次分類と属性タグを重ね合わせます。その後、slug（各 Skill の一意な識別子）を用いて重複を除去します。
4. 名称、中国語の説明、タスクとの適合度を基準に再排序し、同順位の場合はダウンロード数やインストールの熱狂度（人気度）を参考に加味します。
5. 最も適切な結果を 3〜5 件に絞り込み、そのマッチング理由を説明します。ユーザーが確認した上で、インストール処理へと進みます。

例えば、「上司に自動で週報を送る」という依頼は、単なるキーワードの羅列として扱われるわけではありません。エージェントはまずこれを「業務効率化」のシナリオと理解し、「週報」「業務報告書」「日報」「weekly report」などの候補語を拡張します。もし特定の分類内で結果が多すぎる場合はさらに絞り込みを行い、逆に結果がない場合は分類制限を外して同義語や上位概念を用いて検索範囲を広げ、より多くの候補を回収します。

これが SkillHub と一般的なスキルカタログの決定的な違いです。カタログは収録を、市場は取引を、コミュニティは交流を担当します。しかし、エージェント向けの SkillHub は最終的に「機械が理解し、呼び出せる能力の索引」として機能する必要があります。

SkillHub の「find skill」機能をリリース後、何らのプロモーションも行いませんでしたが、わずか 3 日で急上昇ランキング 1 位を達成し、1 週間ではインストール数が 8,000 を突破しました。

imageエージェント内で find skill を使用し、関連スキルを推薦する様子

結び：本当に注目すべき 20％のスキルを見つけるには？

振り返ってみると、TRACE の構築やスキルの試行運用、ランキング、タグ付け、そして find skill の導入は、一見すると異なる 5 つの機能に見えますが、その根底にあるのはすべて同じ課題への取り組みです。

「供給が極めて豊富になった今、いかにしてユーザーがプラットフォーム内で注目すべきスキルを効率的に発見できるか」

ユーザーには試行錯誤のコストを下げてほしいし、作者には品質に見合った露出を得てほしい。また、プラットフォームとしては「悪いコインが良質なものを追放する」現象を防ぎたい。さらに、エージェントにとっては曖昧なタスクを確実に実行可能な能力へとマッピングする必要があります。

そこで私は、SkillHub の推薦機能を「信頼と配布のインフラストラクチャー」として捉えています。

• 評価や試行運用で証拠を積み上げます
• ランキングとタグで供給を整然と整理します
• 検索と推薦で注目を配分します
• find skill でこれらの能力を AI に開放します
• そして、実際の呼び出し結果は再び評価やソートにフィードバックされます

この仕組みはまだ構築途上です。評価は新しいエージェントの形態に合わせて継続的に適応させる必要があり、スキル側でもより完全な成果物の検証が求められます。タグも実需に応じて進化し続けるでしょう。また、クリエイターにはさらなる露出とインセンティブが必要で、これらがプラットフォームをさらに完善させる原動力となります。

しかし、少なくとも一つの方向性は明確になりつつあります。スキル数が数百から数万へと増大する中で、単に「ここには何でも揃っている」と証明するだけでは不十分です。ユーザーやエージェントが、質が高く適切なスキルをより迅速に見つけられるように手助けすることが、いっそう重要になっています。これはプラットフォームの価値そのものに直結する課題であり、SkillHub がコンテンツガバナンスと配布において最も重視すべき製品観と言えるでしょう。

ぜひ公式サイトで体験してみてください：

https://skillhub.cn/

WeChat で開くにはこちらへ