こんにちは！KIYOラーニング株式会社でQAエンジニアをしている坪根です。
生成AIの活用、こんなところで止まっていませんか？
- 便利なプロンプトを作っても、自分のローカルにしかない
- チームに配っても、更新が誰かのフォルダで止まる
私たちQAグループも同じ壁にぶつかり、半年かけて個人技をチームの仕組みに変えました。
本記事で伝えたいのは、ツールではなく「個人技を組織の資産にし、育てて捨てるまでを回す運用」 です。職種を問わず応用できると思います。
この記事で分かること
- 運用の核心 ＝ 「昇格管理」（個人スキルをどう"昇格"させ、何を"廃止"するか）
- 「全部はプラグイン化しない」段階的配布の設計
- 流出バグの再発防止ループが回り始めた事例と、あえて「やらない」と決めたこと
結論：整えたのは「ツール」ではなく「育てる仕組み」
成果につながったのは、Claude Codeそのものではなく個人技を育てて配って捨てる仕組みでした。差がついたのは次の運用です。
- 目録化：誰が何を持っているかをNotion DBで可視化
- 段階的配布：いきなり全員配布せず、触れる粒度を4段階に分ける
-
昇格管理：
未確認 → 個人スキル → プラグインスキル → 廃止のライフサイクルで育てる/捨てる
このうち ③昇格管理が本記事の核心です。①②は他社事例にも近いものがありますが、「個人スキルをプラグインへ昇格させ、使われないものを廃止するライフサイクル」まで運用に落とし込みました。
前提：技術の進化は「困りごと」とだけ一致させた
業界の進化（プロンプト→スキル→プラグイン）が、私たちの困りごとの解き方と一致していました。全機能を追わず、困りごとと一致する部分だけ取り入れたのがポイントです。
| 壁 | 困りごと | 取り入れた仕組み |
|---|---|---|
| 手間の壁 | Notion→エディタへ毎回手動コピペ |
スキル化（/コマンドで呼べる） |
| 配布の壁 | ファイルを配っても更新が止まる | プラグイン＋社内マーケットプレイス |
| 連携の壁 | 課題管理／Notion／自動化ツールを手動往復 | MCPサーバーで直接読み書き |
この3つの「仕組み」自体は、いまや一般的な手法です。具体的なやり方は折りたたみに留めます。
技術的な土台（プロンプト→スキル→プラグイン、MCP連携）のやり方（クリックで展開）
「コピペするプロンプト」→「/コマンドで呼べるスキル」→「全員に自動配布されるプラグイン」へ段階的に移行しました。
| 段階 | やったこと |
|---|---|
| プロンプト | 「目的・材料・条件・出力」の4要素テンプレで型化し、Notionに集約・DB化 |
| スキル | 作成支援ツール（skill-creator）で、対話5項目に答えるだけで作成。YAML不要 |
| プラグイン | 定着したスキル群を束ね、社内マーケットプレイス経由で配布 |
プラグイン化すると、追加は1クリック、更新はマーケットプレイス更新だけで全員最新化、旧版へのロールバックも可能になります。VS Codeに導入しておけば、あとはスラッシュコマンドを打つだけで同梱スキルを誰でも呼び出せます。MCPサーバーを導入して課題管理／自動化ツール／Notionを連携し、手動往復の手間を解消しました。
本記事の核心：個人技をチーム資産に変える「3つの工夫」
工夫1：Notion DBで「目録化」する
誰がどんなスキルを持っているかと、そのスキルを業務のどの工程で利用できるかをNotion DBで可視化しました。それにより、「Notionを開けば誰でも業務でどのスキルを利用できるかが分かる」状態にしました。
Notion DBでの管理例（クリックで展開）
スキルDB
スキルを一覧・管理し以下の情報にアクセスできます。
- ステータス（未確認 / 個人スキル / プラグインスキル / 廃止）で管理
- 取得方法（プラグイン/Zipファイル）
- 概要・主な用途・参照URL・タグ・管理者
テスト設計手順
テスト設計業務の工程ごとに、どのスキルを利用できるかを管理します。
工夫2：触れる粒度を「段階化」する（全部はプラグイン化しない）
4レベルを用意し、全スキルを無理にプラグイン化しない方針にしました。
| Level | 内容 | 位置づけ |
|---|---|---|
| 0 | 既存スキルを実行（合言葉を打つだけ） | 全員必須 |
| 1 | 作成支援ツールで個人スキルを作る | 奨励 |
| 2 | スキルDBに説明＋Zipを添付し、使いたい人が手動導入 | 軽量に共有 |
| 3 | 複数人が常用する定着スキルだけプラグインに反映して自動配布 | 定着してから |
思いつきで作ったスキルを全部プラグインに載せると、誰も使わないスキルで溢れて逆に使いづらくなります。「定着してから昇格」 が現実的と判断しました。
工夫3：ステータスで「昇格パス」を管理する
各スキルにステータスを持たせ、ライフサイクルを仕組みにしました。
未確認 → 個人スキル → プラグインスキル → 廃止
（14個） （26個＝昇格） （3個） ※記事投稿時点のスキル数
- 昇格の条件を明確に：Level 2（手動導入）の利用実績で「複数人が実際に使っている」ことを確認してから Level 3（プラグイン）へ昇格。
- 廃止も仕組みに：使われなくなったスキルは「廃止」に落とし、プラグインから外す。
昇格は、作った本人の熱量ではなく 「使われている事実」 で判断します。差がつくのは、便利なスキルを作れるかではなく、いつ・誰が・何を根拠にチーム標準へ昇格させ、いつ捨てるかを決めておくことだと思います。
実例：再発防止のループが回り始めた
QAテスト後にある不具合が流出したのをきっかけに、メンバーが 「ブランチ差分からデグレ・副作用を検出するプロンプト」を作成。スキル化し、Level 2で数人が有効性を確認 → Level 3（プラグイン）へ昇格させ、全員が/コマンド一発で呼べるようにしました。その後、別の改修で実際に対応漏れを検知でき、本番流出を未然に防げました。
つまり 「流出バグ → 再発防止プロンプト → スキル化 → 昇格 → 配布 → 次の流出を未然防止」 のループが回り始めました。個人が作った再発防止策が、昇格管理を通じてチーム全員の標準装備になりました。
このスキルが見る4観点（クリックで展開）
-
条件分岐トレース：変更変数が
if/switchにどう影響するか -
型／キャスト：
null/''/'0'/0で挙動が変わらないか -
DB書き込み副作用：
INSERT/UPDATEの他処理への影響 -
SQL影響：
WHERE/JOINの結果セットの変化
まとめ
- 整えるべきは「ツール」ではなく、それを育てて配って捨てる仕組み（①目録化 ②段階的配布 ③昇格管理）
- 核心は昇格管理：
未確認 → 個人 → プラグイン → 廃止を、熱量でなく使われている事実で回すこと
KIYOラーニング株式会社について
当社のビジョンは『世界一「学びやすく、分かりやすく、続けやすい」学習手段を提供する』ことです。革新的な教育サービスを作り成長させていく事で、オンライン教育分野でナンバーワンの存在となり、世界に展開していくことを目指しています。
プロダクト
- スタディング：「学びやすく・わかりやすく・続けやすい」オンライン資格対策講座
- スタディングキャリア：資格取得者の仕事探しやキャリア形成を支援する転職サービス
- AirCourse：受け放題の動画研修がついたeラーニングシステム（LMS）
KIYOラーニング株式会社では一緒に働く仲間を募集しています