個人用 Claude Code Skill をチームに展開したら、運用 1.5 ヶ月で 10 の進化が起きた話

自分用に毎日の技術記事収集を仕組み化する Claude Code Skill を作っていました。これをチーム共有用に展開して、Server / iOS / Android / QA の 4 職種が毎日チェックする Notion DB に技術記事を自動投入する仕組みに育てています。

「個人で動いているものをチームに渡すだけ」のはずが、運用 1.5 ヶ月で 想定外の進化が 10 起きました。先に白状しておくと、厄介だったのは技術ではなく "文章の主語" や "編集方針" の問題。AI ツールをチームに展開するときに何が起きるかの事例集として読んでください。

そもそも collect-feed Skill とは

全体像は 1 枚にするとこうなります。

カテゴリ・巡回先・通知先・イベントの設定は 5 つの YAML に分離していて、Skill 本体（SKILL.md）は手順だけを持ちます。公開日はスニペットの年号を信用せず、本文を WebFetch して検証します。allowed-tools は当初 WebFetch / WebSearch / notion-* / slack-* / Bash(date *) だけに絞り、収集 Skill が想定外のシェルコマンドを叩く事故を構造的に防いでいました（Phase 8 でこの絞り込みを意図的に緩めることになります）。

ここから 10 の進化を順に書きます。

個人 → チーム移行の罠（Phase 0〜2）

Phase 0: 個人版の誕生

きっかけは「SRE を本気で目指す」と決めて、毎日の情報収集を仕組み化したくなったこと。検索スニペットの年号で公開日を誤判定する問題に初日からぶつかり、初版から公開日検証のステップが入っています。その後も重複排除や緊急度レベルを足しながら、個人ツールとしてはこれで完成だと思っていました。

Phase 1: チーム展開と即時 fix

「これチームでも使えそう」となり、v1.0.0 としてチーム共有用に切り出しました。このとき重要度判定の軸を「自分のキャリア視点」から「チーム軸」へ転換しています。

展開 2 日で fix が 2 件。Slack チャンネル ID の読み込み失敗を握りつぶしていて例外、そして「## 要約」セクションを Agent が「冗長」と判断して勝手に省略。どちらも個人運用では顕在化しなかった "暗黙の仕様" が、チーム運用で初めて露出した形です。

Phase 2: 個人視点の文章が漏れ出す（最大の罠）

展開 5 日後、Notion のメモに「あなたの今 Q 目標と一致」「○○さんの構成にハマる」といった個人指向の文章が混じり始めました。チーム共有 DB に「あなたの〜」が入るのは事故です。最初に見つけた時は背筋が冷えました。

原因は個人版の DNA でした。categories.yml の重要度基準に「今 Q 目標との一致度」が残り、SKILL.md のテンプレ例文にも個人視点の言い回しがあり、Agent はそれを忠実に再現していただけ。重要度基準・例文・テンプレを全部チーム軸に書き換えて解消しました。

学び: 個人ツールをチームに展開すると、文章の主語の統一が一番難しい。判定ロジックの書き換えだけでは不十分で、プロンプト内のテンプレ文言・例示文まで全部洗わないと「あなたの〜」が漏れ出す。

これは Skill に限らず、プロンプトを資産化するすべての AI 活用に共通する話だと思います。

網羅性と偏りの問題（Phase 3〜4）

Phase 3: 大型イベントを取りこぼす

クラウド系カンファレンスの開催週に、主要発表をごっそり取りこぼしました。技術ブログを 1 件ずつ巡回する設計には「公式ロールアップ記事（全発表の目次）を見に行く」動作がなかったからです。

events.yml に 23 イベント（WWDC, re:Invent 等）を登録し、開催 ±2 週間は公式ロールアップを直接取得する Step を追加しました。巡回ソースを増やすだけでは網羅性は出ない、情報源の "種類" を増やす必要がある、というのがここでの学びです。

Phase 4: 職種偏りの是正

Server / SRE / AI ばかり集まり、モバイル・QA が 0 件の日が続出しました。原因は 2 つで、モバイル・QA のアクティブな技術ブログ自体が少ないこと、そして全カテゴリ一律の閾値だと母数の少ない職種が ★★ に届かないこと。4 職種構成のチームで半分のメンバーに何も届かないのは、ツールとして死んでいます。

ソース拡張（モバイル 4 → 11 サイト、QA 新設）に加えて、職種バランスのルール化（iOS / Android / QA 各最低 1 件、サーバー系は上限 8 件）と、母数の少ない職種だけ閾値を緩和する調整を入れました。「全職種対応」を謳うなら、量の偏りと質の閾値の両方を職種ごとに調整しないと、声の大きいカテゴリに飲まれる。

編集方針の進化（Phase 5〜7）

Phase 5: 重要度別に "届け先" を分ける

🚨確認必須（本番障害リスク・使用中 OSS の侵害）の記事が Notion 登録止まりで、朝一で Notion を見ない日は対応が半日遅れる問題が出ました。「即アクション要」だから 🚨 なのに、届け先が他の記事と同じでは意味がありません。

v1.1.0 で 🚨 だけ Slack に即時通知するよう分離。「収集 → 登録」で完結させると重要度の高い情報ほど遅延する構造になる、通知設計は収集設計と同じくらい大事だ、というのが学びです。

Phase 6: 技術スタック軸だけでは「一生効く記事」が拾えない

収集軸が iOS / Android / Server / AI といった技術スタック軸に寄っていて、設計原則・リファクタリング論・プロダクト開発思想・チーム開発論のような普遍的開発教養がどこにも分類されず落ちていました。

そこで普遍的中核 5 領域（プログラミング/コード品質・アーキテクチャ/設計・プロダクト開発・スクラム/アジャイル・EM/開発組織）を最上位に置き直し、技術スタック軸はその下に再配置。技術トレンドは半年で陳腐化しますが、設計論・組織論は陳腐化しません。

Phase 7: カテゴリの 3 層 Tier 構造化

チームの中期方針に直結する 7 カテゴリ（AI エージェント基盤・越境/フルスタック等）を足して 23 カテゴリまで拡張したら、今度は判定の重みが等価になって優先度がぼやけました。全カテゴリ同じ重みで「該当すれば ★★」では、Agent はカテゴリ間の優先度を判断できません。

Tier 1（普遍的中核 5 領域）/ Tier 2（中期方針 4 領域・優先取得と明記）/ 横断的補助 3 領域、の 3 層に構造化して、同スコアなら Tier 2 優先とルール化しました。カテゴリ設計はフラットにせず層を持たせる、が 23 カテゴリまで膨らませた末の結論です。

当初の経緯メモはここまでの 7 つで締めるつもりでした。ところが Skill は「収集して届ける」の外側へ伸び始めます。

「収集して届けて終わり」からの脱却（Phase 8〜10）

Phase 8: 🚨記事の「影響調査」まで自動化する

🚨 の Slack 通知は機能していたものの、受けた側は結局「で、うちのリポジトリは影響あるの?」を手で調べることになります。サプライチェーン攻撃系の記事では、侵害パッケージ名を控えて組織内リポの lockfile を grep して回る作業が毎回発生していました。通知は届いているのに、アクションまでの距離が遠い。

そこで Step 9.5 を新設して、調査そのものを Skill に組み込みました。

このために allowed-tools へ Bash(gh *) / Bash(rg *) / Bash(fd *) を追加しました。冒頭に書いた「ツールを絞って事故を防ぐ」設計の、意図的な緩和です。絞り込みは目的ではなく手段なので、必要が生まれたら理由つきで開ける。逆に言うと、理由なしには開けない状態を保てていることが大事なのだと思います。

落とし穴も 1 つ踏みました。初版は全リポ × 全依存ファイルを取得しに行く作りで、GitHub の Secondary Rate Limit に抵触しかける。リポ一覧を言語情報付きで取得し、npm 系の侵害なら TypeScript / JavaScript のリポだけに絞るよう修正しました。これを指摘したのは人間ではなく、PR に付けている AI レビュー（Gemini Code Assist）。AI が作った Skill の PR を AI がレビューして直る光景が、日常になりつつあります。

Phase 9: 「対人スキル」カテゴリと、メンションの設計

ファシリテーション・1on1・テックリード論のような対人スキル系の記事が、EM/開発組織カテゴリに吸われて埋もれるか、どこにも該当せず落ちるかになっていたため、24 番目のカテゴリとして追加しました。効いたのは境界の定義で、「制度・組織構造寄りは EM、対人・実践スキル寄りはソフトスキル」と判定基準に明文化しています。カテゴリを足すこと自体は 1 行でも、隣との境界を書かないと判定が揺れる。

あわせて、Phase 8 の調査結果が「対応必要」のときだけ担当チームへメンションを付けるようにしました。Phase 5 が重要度で届け先を分けたのに対し、ここではアクション要否でメンションを分けています。全部に付けると「またか」で読み飛ばされるので。

Phase 10: チームメンバーが Skill を進化させ始めた

直近の進化は、私が書いたものではありません。ソース巡回の並列実行を Claude Code の Workflow ツール（Dynamic Workflows）+ 構造化スキーマに置き換える PR を、チームメンバーが出してくれました。

技術的な学びも 1 つ。Workflow のサブエージェントは SKILL.md 本文を読めないため、各 Agent の担当定義をプロンプト文字列にインライン展開しないと、巡回指示が曖昧になって対象ソースを取りこぼします。Skill から別の実行コンテキストを呼ぶときに必ず踏む類の罠です。

ただ正直なところ、実装内容より「チームメンバーが Skill を育て始めた」こと自体が一番嬉しい進化でした。展開した時点ではまだ "私のツールをみんなが使っている" 状態だったのだと、PR をもらって初めて気付きました。

10 の進化を並べてみて見えたこと

時系列で並べると、進化は 4 種類に分かれます。前半は個人ツールの DNA との戦い、中盤は「ある条件下では届かない」ことの発見、後半は届け先・軸・優先度といった編集方針の作り直し、そして最後が「収集して届けた後」への拡張とチーム化でした。

特に Phase 5 以降、技術的な実装はほぼ簡単で、難しいのは「何を優先するか」「どこに届けるか」「どう構造化するか」という編集方針です。AI ツールはつい収集精度やソース数といった入力側の最適化に目が行きますが、運用で効いたのは、届け先を分ける・優先度に階層を入れる・主語とトーンを統一する、という編集側の調整でした。

まとめ

もし同じことをやる人がいるなら、見ておくポイントは絞られます。テンプレ文言から個人視点の言い回しが消えているか。大型イベント時の別ルートがあるか。母数が少ない属性への閾値調整があるか。重要度に応じた届け先と、アクション要否に応じたメンションが分かれているか。カテゴリに優先度の階層があるか。そして「届けたあとに残る手作業」を次の自動化対象として見ているか。私が 1.5 ヶ月かけて踏んだのは、つまるところこの 6 つでした。

一番伝えたいのは、「個人ツールをチームに広げると、技術 < 編集方針の問題になる」 ということです。Skill そのものの実装より、何を集めて、どう分類して、どこに届けるかという設計のほうが、運用品質を決める割合が大きい。これから Claude Code Skill をチームで運用する人の参考になれば嬉しいです。