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

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

「個人で動いているものをチームに渡すだけ」のはずが、運用 1.5 ヶ月で 想定外の進化が 7 つ起きました。本記事ではその全過程を時系列で残します。技術 Tips というより、AI ツールをチームに展開するときに何が問題になるかの事例集として読んでもらえると嬉しいです。

ポイントを先に書くと:

• 技術的な問題よりも、"文章の主語" や "編集方針" の問題のほうが厄介
• 収集対象を増やすだけでは網羅性は出ない。優先度を構造化する設計が要る
• 「Notion に登録した」だけでは情報は届かない。重要度に応じた届け先を分ける
• 個人ツールの DNA は予想以上に残る。プロンプト・テンプレ文言まで全部書き換えないと漏れる

そもそも collect-feed Skill とは

Claude Code の Skill 機能で、こんなことをしています。

1. 設定ファイル（YAML）に書いたカテゴリ・ソース・キーワードに従って、Agent を並列で走らせて記事を収集
2. 各記事の 公開日を WebFetch で本文取得して確認（スニペットの年号は信頼しない）
3. 重要度を 4 段階で判定（🚨確認必須 / ★★★ / ★★ / ★）
4. ★★ 以上を Notion DB に登録、🚨は Slack にも即時通知

設定は 5 つの YAML で切り分けています:

• categories.yml — カテゴリ定義・キーワード・重要度基準
• sources.yml — 巡回対象（技術ブログ + Web 検索クエリ）
• channels.yml — Slack チャンネル一覧
• notion.yml — Notion DB 設定
• events.yml — 大型イベント一覧（公式ロールアップ URL を含む）

Skill のフロントマターでは allowed-tools を絞り込んでいて、WebFetch / WebSearch / notion-* / slack-* / Bash(date *) だけが使える状態にしています。これによって「収集 Skill が想定外のシェルコマンドを叩く」事故を構造的に防いでいます。

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

Phase 0: 個人版の誕生

最初は完全に個人ツールでした。

きっかけは「キャリアの方向性として SRE を本気で目指す」と決めたタイミングで、毎日の情報収集を仕組み化したいと思ったこと。検索結果のスニペットの年号で誤判断する問題に最初からぶつかっていて、初版から「公開日検証」のステップが入っています。

その後、Notion 重複チェック、URL ベース重複排除、直近 1 週間の関心トピック確認、🚨緊急度レベル追加と、収集精度を上げる方向で進化させていました。個人の情報収集ツールとしては、これで完成だと思っていました。

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

チームメンバーに紹介したところ「これチームでも使えそう」となり、v1.0.0 としてチーム共有用に切り出しました。個人版はリネームして名前衝突を回避しています。

この瞬間にやった一番大きい意思決定は、重要度判定の軸を「自分のキャリアロードマップ視点」から「チーム軸」に転換したことでした。これが後で Phase 2 に効いてきます。

展開直後、運用 2 日で 2 つの即時 fix が必要になりました。

• Slack チャンネル ID が null で例外 — channels.yml の読み込み失敗を握りつぶしていた
• 「## 要約」セクションが時々省略される — SKILL.md の指示が曖昧で、Agent が「冗長」と判断して飛ばしていた

地味ですが、個人運用では気付かなかった "暗黙の仕様" がチーム運用で初めて顕在化するという典型例でした。SKILL.md に「省略禁止」「最低 3 行」と明示して解決。

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

ここから本番です。チーム展開後 5 日くらいで気付いたのですが、Notion 登録時のメモに 個人指向の文章が混じる現象が出ていました。

たとえばこんな出力です。

• 「あなたの今 Q 目標と一致」
• 「SRE ロードマップに直結」
• 「○○さんのサブエージェント構成にハマる」

チーム共有 DB に「あなたの〜」「○○さんの〜」が入るのは事故です。原因は明白で、個人版の DNA が残っていた。

• categories.yml の重要度基準に「今 Q 目標との一致度」「SRE ロードマップ関連」という表現が残っていた
• SKILL.md のテンプレ例文に個人視点の言い回しがあった
• Agent はそれを忠実に再現していた

対応として:

• categories.yml の重要度基準を「今 Q 目標」→「チーム全体の目標」、「SRE ロードマップ関連」→「SRE/インフラ改善に関連」に書き換え
• SKILL.md の Step 8 に「個人名禁止」「個人キャリア視点禁止」を明示
• テンプレ例文をチーム軸に全部書き直し

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

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

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

クラウド系の大型カンファレンス開催週に、通常巡回経由では主要発表（新サービス・新基盤・MCP 系の発表など）を取りこぼしました。

イベント期間中は各社の公式ブログが大量の発表記事を出します。collect-feed は技術ブログを 1 件ずつ巡回する設計だったので、「公式ロールアップ記事（全発表の目次）」を見に行く動作がなかったのが原因です。個別ブログを巡回するだけでは、大型イベントの全貌はカバーできません。

対応:

• config/events.yml を新設し、チームの技術スタックに関連する 23 イベントを登録（WWDC, re:Invent, GopherCon, Next.js Conf, Laracon 等）
• SKILL.md に Step 3.5 を新設: 本日 ±2 週間にイベント該当時は、公式ロールアップ URL を直接 WebFetch + WebSearch で取得
• イベント該当時は記事数上限（15 件）を緩和（+10 件まで）

学び: 「巡回ソースを増やす」だけでは網羅性は出ない。イベントカレンダーを明示的に持って「公式ロールアップを取りに行く」動作を組み込まないと、大事な発表ほど落ちる。情報源の "種類" を増やす視点が必要。

Phase 4: 職種偏りの是正

運用してみると Server / SRE / AI 系記事ばかり集まり、モバイル・QA が 0 件の日が続出しました。これは大きく 2 つの原因が絡んでいます。

• 母数の問題 — モバイル系・QA 系のアクティブな技術ブログが、サーバー系に比べて圧倒的に少ない
• 重要度判定基準の問題 — 全カテゴリ一律の ★★ 閾値を適用すると、母数の少ないモバイル・QA はそこに届きにくい

Server / iOS / Android / QA の 4 職種構成のチームで、モバイル・QA メンバーが毎日 0 件を見る状態は失敗です。「全職種対応」と謳いながら半分のメンバーに何も届かないのはツールとして死んでいる。

対応:

• categories.yml に QA / テスト自動化カテゴリを追加（11 → 12 カテゴリ）
• iOS/Android のキーワードを実スタック寄せ（TCA, SwiftUI, Jetpack Compose, KMP 等）
• sources.yml のモバイル系を 4 → 11 サイトに拡張、QA セクション新設
• SKILL.md の Agent 構成を 4 → 5 に再編（B = モバイル専任、C = QA + RSS + Web）
• 職種バランス確保ルール追加: iOS / Android / QA 各最低 1 件、サーバー系は 15 件中 8 件まで
• モバイル / QA は母数が少ないため ★ 閾値を緩和（Server / AI / セキュリティは厳格適用）

学び: 「全職種対応」を謳うなら、量の偏り（記事の母数）と質の閾値（重要度判定基準）の両方を職種ごとに調整しないとダメ。一律ルールで運用すると、声の大きいカテゴリに飲まれる。

ここまでが「個人 → チーム展開での 4 つの罠」で、当初はこの 4 つを書く想定で経緯メモを残していました。けれど、運用を続けるとさらに 3 つの進化が起きます。

Phase 5: 重要度別に "届け先" を分ける（v1.1.0）

🚨確認必須レベル（本番障害リスク・使用中 OSS の侵害・即アクション要）の記事を Notion 登録止まりにしていたのですが、これが構造的な問題を抱えていました。

Notion を朝一で見ない日があると、半日〜1 日対応が遅れる。

🚨は「即アクション要」だから 🚨なのに、登録先が Notion だけでは届かない。重要度のラベリングと届け先が噛み合っていなかった。

対応:

• 🚨確認必須記事だけ Slack の指定チャンネルにも即時通知
• channels.yml に notification 用チャンネルを追加
• Skill の allowed-tools に mcp__plugin_slack_slack__slack_send_message を追加

これを v1.1.0 としてリリースしました。

学び: 「収集 → 登録」で完結させると、重要度の高い情報ほど遅延する構造になりやすい。重要度別に届け先を分けるのが正解（★ 以下は Notion のみ、🚨は Slack 即時通知）。通知設計は収集設計と同じくらい大事。

Phase 6: 技術スタック寄りすぎ問題の修正（中核領域の再編）

ここまでの収集軸は iOS / Android / Server / SRE / AI といった 技術スタック・職種軸 に寄っていました。これも数週間運用して気付いたのですが、この軸だと 長く価値の続くテーマが拾えないんです。

具体的には:

• リーダブルコード論・設計原則・リファクタリング論
• アーキテクチャの選定論・モジュール設計
• プロダクト開発思想・ユーザー体験設計
• スクラム / アジャイル / チーム開発論
• エンジニアリングマネジメント

こういう 普遍的開発教養 にあたる記事が、技術スタック軸のカテゴリだとどこにも分類されない。結果、「読んでおくと一生効く記事」が漏れる構造になっていました。

対応として、普遍的中核 5 領域（プログラミング/コード品質・アーキテクチャ/設計・プロダクト開発・スクラム/アジャイル・EM/開発組織）を最上位に置き直しました。技術スタック軸はその下に再配置。

学び: チーム共有用の収集軸は、特定技術のキーワードよりも先に「普遍的開発教養」を据えるべき。技術トレンドは半年で陳腐化するが、設計論・組織論は陳腐化しない。新しいトレンドだけ追っていると、チームの基礎体力につながる記事が拾えない。

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

Phase 6 で中核領域を再編しつつ、AI エージェント基盤・クロスプラットフォーム・越境 / フルスタック・シフトレフト/要件定義 など チームの中期方針に直結する 7 カテゴリを追加して、最終的に 23 カテゴリ体系に拡張しました。

ただ、カテゴリを増やすほど 判定の重みが等価になって優先度がぼやける問題が出ます。23 カテゴリ全部に同じ重みで「該当すれば ★★」と判定していると、Agent はカテゴリ間の優先度を判断できません。

そこで 3 層構造を導入しました。

• Tier 1: 普遍的中核 5 領域 — 長期的価値。プログラミング/コード品質、アーキテクチャ/設計、プロダクト開発、スクラム/アジャイル、EM/開発組織
• Tier 2: 中期方針 4 領域 — チーム中期方針直結。AI エージェント基盤、クロスプラットフォーム/コード共通化、越境/フルスタック、シフトレフト/要件定義
• 横断的補助 3 領域 — キャリア/スキル成長、DevEx/開発環境、オブザーバビリティ

SKILL.md の収集方針で Tier 2 を明示的に「優先取得」と記述することで、Agent の判断にバイアスを与えています。同じスコアの 2 件があったら Tier 2 を優先する、というルールです。

学び: カテゴリは増やすほど判定が曖昧になる。「何を優先するか」を Tier として構造化することで、Agent の判断にバイアスを与えられる。カテゴリ設計はフラットではなく、必ず層を持たせる。

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

時系列で並べると、性質の違う 3 種類の問題が混ざっていました。

特に思うのは、Phase 5 以降は技術的な実装はほぼ簡単で、難しいのは 「何を優先するか」「どこに届けるか」「どう構造化するか」という編集方針だったということ。

AI ツールを作るときって、つい「収集精度を上げる」「カテゴリを増やす」「ソースを増やす」みたいな 入力側の最適化ばかりに目が行きがちです。でも実際に運用してみると、効くのは:

• 重要度に応じて 届け先を変える
• カテゴリに 優先度の階層を入れる
• 文章の 主語・トーンを統一する

といった 編集方針側でした。

まとめ: 個人ツールをチームに展開するときのチェックリスト

経験を踏まえて、もし同じことをやる人がいるなら、こんなチェックリストを作って事前に潰しておくと早いと思います。

• 判定基準・テンプレ文言から 個人視点の言い回し（「あなたの」「○○ロードマップ」等）が消えているか
• 大型イベント時の挙動を別ルートで設計しているか（公式ロールアップ巡回など）
• 対象ユーザーの偏りに対する閾値調整があるか（母数が少ない属性へのケア）
• 重要度ラベルに応じた 届け先が分かれているか
• カテゴリ設計に 優先度の階層があるか（Tier 化）
• 設定ファイル（YAML / JSON）と プロンプト本文の両方をチームレビューにかけたか

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

これから Claude Code Skill をチームで運用する人の参考になれば嬉しいです。