チームの AI スキルは多すぎる。残すものを決める 2 つのルール
スキルは人が意図して押すボタンです。毎週使われ、人の判断が必要なものだけを残し、それ以外は自動化・廃止・削除し、知識は共有コンテキストに戻します。

チームの全員が AI エージェントを持つと、全員がそれぞれスキルを書き始めます。コーディング用のスキル、顧客への返信用のスキル、週報用のスキル。半年後に「チームにスキルはいくつある?」と聞いても、誰も答えられません。「実際に使われているのはいくつ?」と聞けば、答えはもっと厳しくなります。
一緒に取り組んできたチームのほとんどがこの状況に陥り、私たち自身もそうでした。AI をチームで機能させるにはで、導入が深まるほどスキルは減っていくと書きました。この記事はその実践編です。スキルは何のためにあるのか、なぜ増えるほど悪くなるのか、そしてどれを残すかを決める 2 つのルールを紹介します。
スキルとは何か
スキルとは、SOP に、その背後にある知識と基準を加えたものです。仕事をどう進めるか、何をもって良しとするか、何をしてはいけないか。いまでは多くのエージェントが、SKILL.md を含むフォルダという共通のオープン形式 Agent Skills を読めるので、1 つのスキルを Claude Code、Codex、Cursor などで共通して使えます。
これはスキルの中身の説明にはなっても、スキルが独立して存在すべき理由にはなりません。私たちの答えはこうです。スキルはボタンである。 人が「このやり方でやってほしい」と AI に明示的に頼む起点です。エージェントが行うそれ以外のことは、チームの共有コンテキストから自分で判断できます。スキルが独立して存在する価値は、誰かが意図してそれを押すことにあります。
ボタンとして見ると、スキルが多すぎることの問題ははっきりします。
スキルが増えるほど悪くなる理由
- 押されないボタンが増える。 スキルが 1 つ増えるたびに、同じ人数がより多くのボタンに分散します。スキルが多いほど 1 つあたりの利用者は減り、誰も触らないものが増えていきます。
- 同じ仕事に 10 のバージョン。 全員が自分のコーディングスキルを書けば、同じ仕事に 10 個のスキルができ、どれもチーム全体の知恵を集めたものになりません。1 つの強いやり方が、10 個の弱いやり方に分かれてしまいます。
- 知識が間違った場所に閉じ込められる。 顧客リスト、ブランドルール、価格、製品情報がスキルごとに貼り付けられます。コピーはそれぞれずれていき、次のスキルはまたゼロから書くことになります。
- 誰も引き継げない。 100 個のスキルを書いた同僚が辞めたとします。どれが重要なのか誰にもわからず、他人の 100 個のファイルを保守したい人もいません。
スキルはセンスを軸に設計する
スキルを書く前に、1 つだけ問いかけてください。人の判断が必要な仕事はどれか。 キャンペーンの承認、顧客への返信が送れる品質かどうかの判断、どの要望をロードマップに入れるかの決定。こうした仕事にはボタンが必要です。人がループの中にいなければならないからです。
それ以外は、チームの共有コンテキストに置くべき知識か、自動で動かすべき純粋な実行のどちらかです。
2 つのルール
残すスキルは、次の 2 つを両方満たす必要があります。
- 毎週、誰かが使っている。 今週誰もボタンを押していないなら、そのスキルは存在する必要がありません。
- 人の判断が必要である。 純粋な実行なら完全に自動化し、人にボタンを押させるのはやめます。
2 つを組み合わせると、すべてのスキルは 4 つのマスのどれかに入ります。
| 人の判断が必要 | 純粋な実行 | |
|---|---|---|
| 毎週使われている | 残す。 担当者を決め、毎週改善する。 | 自動化する。 スケジュールやトリガーで動かし、ボタンはなくす。 |
| 毎週は使われていない | スキルをやめる。 中の知識を共有コンテキストに移す。 | 削除する。 |
残るものの少なさに、たいていのチームは驚きます。それが狙いです。残った数個は、チームのセンスが宿る仕事であり、仕事の進め方の中核そのものです。
棚卸しの進め方
最初の 1 回は、午後半日あれば十分です。
- すべてのスキルを洗い出す。 個人のエージェントのフォルダ、リポジトリ、共有ドライブ。本人も忘れていたものも含めます。
- スキルごとに 3 つ書き出す。 直近 2 週間で誰が使ったか、人にどんな判断を求めているか、中にどんな知識が貼り付けられているか。
- 知識を外に出す。 顧客、製品、ブランド、価格に関する事実はチームの共有コンテキストに移し、すべてのエージェントとスキルが同じものを読むようにします。スキルに残すのは方法だけです。
- 重複をまとめる。 10 個のコーディングスキルのうち、誰のやり方を残すか。これはマネジメントの判断であり、センスの問題です。一番新しいファイルが自然に勝つのではなく、意図して決めてください。
- 2 つのルールを当てはめる。 残す、自動化する、やめる、削除する。
スキルが減っても、手間を減らしていいわけではない
残ったスキルはチームの資産です。資産として扱いましょう。
- それぞれに担当者を置く。 成果の質を気にかける、高い基準を持った人が理想です。
- 毎日の入口にする。 肝心なステップに置き、みんなが毎日実際に開いて応答するようにします。
- 少なくとも週に 1 回は改善する。 変わらなくなったスキルは、使う人から学ぶのをやめたスキルです。
- 共有のコピーは 1 つだけ。 全員が同じバージョンを使い、変更は 1 回レビューすれば全員に反映されます。
コミュニティやコースにある何百ものスキルはどう考えればいいでしょうか。たくさんのスキルを眺めるのは、やり方を学びアイデアを得るには良い方法です。ただ、1 つの会社の中では、ボタンを絞り込み、知識は誰でも手の届く場所に戻してください。
Busabase での扱い
Busabase では、スキルはワークスペースの中にスキルノードとして置かれ、説明対象のデータのすぐ隣に保存されます。そのため、ここまでのルールが自然とデフォルトになります。
- 全員が同じものを使う。 接続したすべてのエージェントが同じスキル本文を読むので、スキルが誰の PC にあるかで結果が変わりません。
- 変更のレビューは 1 回。 スキルの編集は変更リクエストを通り、マージされるとすべてのエージェントに同時に反映されます。
- リポジトリごとのコピーは不要。
busabase-cli skill linkは、使うときに本文を取りに行く小さなポインタファイルだけを書き込むので、5 つのリポジトリに 5 つのずれたコピーができることはありません。 - エージェントが自分でボタンを探す。 仕事を始める前に、エージェントはワークスペースから合うスキルを探すので、名前のよいスキルは使われます。見つけてもらえる名前と説明の付け方は Agent Playbooks を参照してください。
- 作った人が辞めてもスキルは残る。 スキルは書いた人ではなく、ワークスペースのものです。
ツール選びより先に、棚卸しから始めてください。今週スキルの数を数え、2 つのルールを当てはめ、何が残るかを見てみましょう。残ったスキルを置く共有の場所が必要なら、Busabase Cloud を無料で始められます。
ボタンは少なく、より良く。