7:12 - 8:39

管理されたスキルと改善のライフサイクル

この章では、AIエージェントが仕事を進めるための「スキル（skill）」を、組織でどのように管理するかを見ます。ここでいうスキルは、単なる一回分のプロンプトではありません。作業の手順や判断の進め方をまとめた、再利用できるエージェント用の手続きです。

ツールとスキルは違います

まず、ツールとスキルを分けて考える必要があります。MCPなどのツールは、エージェントが何を実行できるかを示します。たとえば、リポジトリを検索する、チケットを読む、依存関係を更新する、といった操作です。

一方、スキルは、複数の操作をどのような順番で、どんな注意を払って組み合わせるかを示します。たとえば、あるサービスの所有者を確認し、そのサービスの依存ライブラリを調べ、安全な更新を作り、検証してレビューに出す、という流れです。ツールが「呼び出せる操作」なら、スキルは「目的を達成するための手順」です。

これは、料理にたとえると分かりやすいでしょう。包丁や鍋はツールです。レシピはスキルです。道具がそろっていても、使う順番や確認方法がなければ、同じ品質の料理を安定して作れません。

個別の工夫を、見つけられるカタログへ

話し手によると、Uberではスキルを、中心チームが管理するものと、各ドメインのチームが管理するものに分けています。中心チームのスキルは、広い範囲で共通に使う手順です。ドメイン固有のスキルは、たとえば特定のサービスや業務に詳しいチームが持つ手順です。

このような分担には理由があります。別々のエンジニアが似たスキルをそれぞれ作ると、同じものが重複します。また、すでにあるスキルを見つけられなかったり、設定方法が分からなかったりします。管理されたマーケットプレイスは、スキルを一つのカタログに集め、再利用の入口を作ります。

ただし、一覧に載せるだけでは不十分です。カタログが大きくなるほど、次の三つが重要になります。

品質：その手順は、実際の仕事で安全かつ正しく動くか。
発見性：必要な人やエージェントが、適切なスキルを見つけられるか。
所有権：問題が起きたとき、誰が内容を直し、品質を保つか。

話し手は、Uberのマーケットプレイスに約2,500のスキルがあると説明しています。この数字はカタログの規模を示します。しかし、数が多いことだけで、スキルの正しさや価値が証明されるわけではありません。選択しやすい分類、明確な所有者、継続的な検証が必要です。

公開から利用までの品質ゲート

スキルは、作った瞬間に組織全体で使えるようにするのではなく、品質ゲート（quality gate）を通して管理されます。計画では、リンター、評価、モデルによるゲートが示されています。リンターは、形式や構造上の問題を検出します。評価（evaluation）は、決めたケースでスキルの振る舞いを試します。モデルによるゲートは、スキルの内容や実行結果を、さらにモデルで確認する段階です。

図：リンター、評価、モデルのゲートを通ってから、スキルがカタログへ配布されます。
図では、スキルを管理された形で公開するための確認段階が見えます。これは、登録されたスキルが必ず正しいという意味ではありません。自動で利用可能になることと、自動的に正しくなることは別です。ゲートは既知の問題を早く見つける仕組みであり、実際の利用から得られる追加の証拠も必要です。動画の該当箇所（7:46）

公開の流れを、三つの段階に分けると理解しやすくなります。

公開する：中心チームまたはドメインチームがスキルを作り、品質ゲートを通します。
インストールする：利用する環境やエージェントに、そのスキルを届けます。
選択して実行する：コマンドやペルソナ（persona）を通して、目的に合うスキルを選びます。

これらは同じ問題ではありません。公開時の品質不良、インストール時の設定ミス、実行時の選択ミスは、それぞれ別の失敗です。したがって、「マーケットプレイスにある」だけでは、目的のエージェントが正しいスキルを正しく使ったとは言えません。

コマンドとペルソナによる配布

計画では、スキルの配布方法として、コマンドまたはペルソナが挙げられています。コマンドは、利用者やエージェントが特定の手順を明示的に呼び出す入口です。ペルソナは、ある役割やチーム向けに、振る舞い、プロンプト、能力を設定したものです。

ここでペルソナが付くからといって、権限が無制限になるわけではありません。ペルソナは、どの手順を選びやすくするか、どのように仕事を進めるかを整えます。実行できる操作の範囲や承認の条件は、別に管理する必要があります。

たとえば、サービスの依存ライブラリを更新するエージェントを考えます。ツールだけがある場合、エージェントは「依存関係を変更する」操作を呼び出せます。しかし、スキルがあれば、まずサービス所有者を確認し、変更範囲を限定し、テストを実行し、結果を添えてレビューに出す、という手順を再利用できます。スキルは権限そのものではありません。権限を持つ操作を、安全な順序で扱うための手引きです。

実行の証拠がスキルを改善する

管理は、公開して終わりではありません。スキルが複数のエージェント・ハーネス（agent harness）で繰り返し実行されると、実行トレース、利用者のコメント、継続的な評価から情報が集まります。トレースは、どの手順をどの順番で実行したかを記録します。コメントは、利用者やレビュー担当者が見つけた問題を示します。継続的な評価は、変更後も決めたケースで品質を測ります。

この情報が、スキルの修正につながるとき、マーケットプレイスは単なる一覧ではなく、学習する仕組みになります。たとえば、あるスキルが頻繁に実行されても、毎回同じ確認を飛ばすなら、そのトレースから手順の不足が分かります。レビューで同じ注意を受け続けるなら、そのコメントを評価ケースに加え、修正版のスキルを再び検証できます。これは、実行、観察、評価、修正というフィードバックループです。

図：トレースやコメントなどの信号が、評価とスキルのパッチにつながります。
図は、実行後の情報が評価や修正へ戻る流れを示しています。つまり、スキルを使うこと自体が改善の材料になります。ただし、トレースが記録されるだけでは学習にはなりません。誰かがその証拠を読み、評価や保守された手順に反映する必要があります。動画の該当箇所（8:17）

話し手は、スキルが一日に20,000回を超えて実行されているとも報告しています。この数字は、利用が大きな規模に達していることを示す材料です。一方で、実行回数は品質や事業上の効果そのものではありません。多く使われるからこそ、失敗の種類を追跡し、重要なコメントを評価に変え、所有者が修正を続けることが大切になります。

まとめ

この章の中心は、スキルを「便利なプロンプトの置き場」としてではなく、管理された手順の製品として扱うことです。

ツールは実行できる操作を提供し、スキルは操作を組み合わせる手順を提供します。
中心チームとドメインチームの所有権は、共通性と専門性を分担します。
約2,500のカタログでは、品質、発見性、所有権が重要になります。
品質ゲート、公開、インストール、選択、実行は別々の段階です。
トレース、コメント、継続的な評価を修正へ戻すことで、スキルのライフサイクルが完成します。

したがって、エージェントの能力を組織で広げるには、スキルを増やすだけでは足りません。正しい手順を見つけ、適切な権限のもとで使い、実行の証拠から次の改善につなげる運用が必要です。