作って終わりにしない — 標準化を「ルール」から「ループ」に変えた話

スキルを作って終わりにしない、棚卸しループの実践に取り組んだ事例を紹介します。

Transcript

1. SAFIE×CANLY AI NIGHT#2 作って終わりにしない — 標準化を「ルール」から「ループ」に 変えた話 株式会社カンリー SREチーム / CTO室 井上 慶人 2026.08.05 Copyright © Canly, Inc. All rights reserved. Tech Talk / 15min
2. 自己紹介 経歴 2022年5月 カンリー入社。SREチームのEM・CTO室を兼務。 SREとしての取り組み 開発チームへのイネーブリング ・セキュリティ啓蒙 ・プラットフォームエンジニアリング の 実践を推進 井上 慶人 株式会社カンリー ／ SREチーム / CTO室 直近の仕事 Claude Code を中心としたAI駆動開発の社内基盤整備・ガードレール設計 と、 エンジニア組織内のプロセス整備 に従事 Copyright © Canly, Inc. All rights reserved. 02
3. SREチームの取り組み — sre-plugin によるスキル配布 SREチームは、各開発チームが SREを自律的に実践できるよう、イネーブリング を行っています。 その一環として、 SREプラクティスをスキルという形で標準化・展開し、 sre-plugin というプラグインにまとめて全社のエンジニアに配布しています。 プラグイン sre-plugin つくる SREチームが 標準をスキル化 まとめる → 運用手順・規約・調査手順などを 再利用可能なスキルに スキル一式を1つのパッケージとして 管理・バージョン更新 ・トラブル調査 （クラウド内サービスの異常確認・ログ分析） つかう 配布 → 全社のエンジニアが 日常業務で利用 導入するだけで組織の標準が AIの手に載る ・IaC のレビュー ・その他、運用の様々な手順をスキル化して収録 今日の話は、この sre-plugin の運用から得た知見です。 Copyright © Canly, Inc. All rights reserved. 03
4. 50個のスキルと、使われないスキル スキル ＝ 組織の標準・手順をAIに実行させる、再利用可能なパッケージ（指示書＋参照資料） 標準化のためにスキルを作り続けたら、 気づけば 50個。 そして—— 一度も使われないスキルが、出はじめた。 利用実績あり 一度も使われていない 「作りすぎの歯止め」 と「使いたいときに使える可用性」 を、どう両立するか？ Copyright © Canly, Inc. All rights reserved. 04
5. AI資産のコスト構造 — 常時ロードとオンデマンドの 2層 各スキルの name・description・when_to_use の一覧が、毎回AIのコンテキスト（作業記憶）に載る 。 AIはこれを見て「今どのスキルを使うか」を選ぶ——本体（body）は発火判定には効かない。 常時ロード スキル一覧 （name＋description＋when_to_use＝メタデータ） frontmatter ×1 ×2 ×3 …… × スキル ＝ スキル数に比例する固定費 オンデマンド スキル本体 本体は使うときだけ 読み込まれる。 → 使うまで、コストはゼロ。何個あっても本体は増分費用にならない。 （指示書＋参照資料） 「作りすぎ」の議論で効いてくるのは、上の段 ——常時ロードされる一覧 のほう。 Copyright © Canly, Inc. All rights reserved. 05
6. 実測 — メタデータはコンテキストのわずか 0.5% 50個のスキル一覧（メタデータ）＝ 5.2k tokens ＝ コンテキスト全体の 0.5% コンテキストウィンドウ全体 ＝ 100% ← スキル一覧の全部（ 5.2k tokens）＝ 上限のまだ半分 ↑ スキル一覧の予算上限（デフォルト：全体の 1%） この実測が意味すること 当初仮説「トークン節約のために間引くべき」は、我々の環境では 実測で否定された 。 ※ ただし上限は有限 ——単純比例なら 100スキル前後で予算超過圏。「無限に増やせない」根拠は次のスライドへ。 Copyright © Canly, Inc. All rights reserved. 06
7. 増やしすぎてはいけない、本当の理由 では、上限まで増やしてよいのか？ —— No。ただし理由は「トークンがもったいない」ではない。 機構的事実 説明が薄いスキルは、静かに呼ばれなくなる 。 実測で観測済み 意味が重なるスキル同士は「票を取り合う」 。狙ったほうが選ばれない。（次スライドで実例） 仮説（未検証） 数が増えること自体で精度が落ちるかは、まだ分からない 。 確実な利益 整理すれば壊れたスキルの誤発火 を防げる。 問題は「量」ではなく、 意味が重なっていること 。 Copyright © Canly, Inc. All rights reserved. 07
8. 「票の取り合い」の実例 — 12週間、一度も選ばれなかった ユーザーの依頼（汎用トリガー） 「不審な通信 がないか調べて」 AIの選択 → 隣接スキル A（ログ分析・汎用） 票を獲得 ✓ 隣接スキル B（メトリクス異常確認） 票を獲得 ✓ 隣接スキル C（トラブル調査・汎用） 票を獲得 ✓ セキュリティ調査系スキル（狙い） 12週間 0票 狙い：セキュリティ調査系スキル （通信ログの分析手順を収録） 意味空間が重なる候補どうしで票が割れ、汎用トリガーは負け続ける ——候補の「数」ではなく「意味の重なり」 が原因。 Copyright © Canly, Inc. All rights reserved. 08
9. ルールからループへ — 転換点 命名規約や description のルールを一度決めても、 ルーティングの精度は静かに落ちていく （票の取り合い）。 ✕ ルールを作って終わり ◦ 実測しながらブラッシュアップ 一度決めたルールを固定運用。精度低下に気づく手段がない —— 次に気づくのは、誰かが困ったとき。 → OTel で実測 し、ルール・プロセス自体を継続的に見直す。 ルールは一度作って終わりではなく、 回し続けるもの 。 ここから先の標準は、すべてこの ループの一部 として運用する。 Copyright © Canly, Inc. All rights reserved. 09
10. 入口の標準 — 作成ゲート 4問 スキルを 作る前に 、この4問を通す。 1つでも No なら作らない。 1 2 3 4 反復性 アップリフト 区別可能性 オーナーと寿命 その作業は、もう 繰り返し起きた か？ 素のAIに頼むより、 明確に良くなるか？ 隣のスキルの when_to_use と、 発火が重ならないか？ 誰が保守し、いつ見直すか？ 同じ結果なら、スキルにする意味がない 命名規約と弁別語（ネガティブルーティン グ）で担保。重なると静かに死ぬ（→後半の 実例） 先回りの投機的作成が、 未使用スキルの最大要因 オーナー不在のスキルは、 壊れても気づけない ベンチマークで測ると、スキルの差は 組織固有の規約項目 に集中し、ツールの基本能力では差が出なかった。 スキルの価値 ＝ 組織の標準を強制すること （詳細数値は次のスライド） Copyright © Canly, Inc. All rights reserved. 10
11. ベンチマーク内訳 — アップリフトの実証 評価項目 スキルあり 素のモデル 総合スコア 100%（分散0） 67.8%（±11.7%） 出力先規約（組織固有） 9/9 0/9 成果物配置手順（組織固有） 9/9 0/9 環境変数命名（組織固有） 6/6 0/6 ツールの基本能力 ほぼ満点 ほぼ満点 注記（必読） 読み方 数値は採点設計に依存 します。規約項目の重み付けを変えれば、 総合値は変わります。 差は組織固有の規約項目 に集中し、基本能力では差が出ない。 • → スキルの価値 ＝ 組織の標準を強制すること。 • 社内タスク・社内採点基準による参考値であり、一般化はできません。 この計測は skill-creator benchmark [skill名] で誰でも再現できる。 Copyright © Canly, Inc. All rights reserved. 11
12. 区別可能性の担保 — 命名規約と when_to_use 「隣と発火が重ならないか」を、 2つの仕組み で具体的に担保する。 when_to_use 命名規約 G1／G2 の2系統＋allowlist 弁別語（ネガティブルーティング） G1 対象起点：{対象}-analysis/assessment/review… G2 動詞起点：create/setup/connect-{対象} 「〜のときに使う」 ＋「〜の場合は別 skillへ／対象外」 動作語彙を allowlist に限定し、 兄弟スキルがいる場合、決定打となる弁別語のみ を簡潔に入れる。 同義語の乱立 （analysis/investigation/analyzer…）を止める。 詳細な切り分けは body 側の「適用範囲外」節へ。 これは「票の取り合い」の予防策 そのもの ——意味の重なりを、命名と記述の両輪で先に潰す。 Copyright © Canly, Inc. All rights reserved. 12
13. 出口の標準 — 「使われない」の 3分類 「使われないスキル」は一枚岩ではない。 診断してから 手を打つ。 ① ② ③ 発火していないだけ 出番が来ていない 作るべきでなかった 機能は必要とされているのに、description が引っ 低頻度だが重要な作業（障害対応・四半期作業な 反復も需要もなかった投機的作成。 かからず呼ばれていない。消すと損失。 ど）。消すのは 早すぎる 。 ここで初めて、間引く判断が正当化される。 → description を直す → 待つ → 廃止 間引いてよいのは、③だけ。 Copyright © Canly, Inc. All rights reserved. 13
14. 利用計測の基盤 — OpenTelemetry × BigQuery 各端末の Claude Code から OpenTelemetry でログ・メトリクス を収集し、 BigQuery に集約しています。 発生源 各端末の Claude Code 計装・収集 収集 → エンジニア各自の端末で動く AIコーディングエージェント OpenTelemetry OTel の設定は remote-config として 全端末に配布——設定漏れなく統一計測 分析基盤 集約 → BigQuery 一元集約。SQLで横断的に異常確認・ ログ分析ができる この後の 利用計測・棚卸しゲート は、この基盤の上で回っています。 Copyright © Canly, Inc. All rights reserved. 14
15. 計測の落とし穴 — 未発火はログに出ない ✕ ログの集計だけ（穴あき） ◦ 在庫（スキル一覧）を母集団に突合（完全） スキルA 12回 スキルA 12回 稼働中 スキルC 4回 スキルB 0回 導入以来 0 スキルE 0回 休眠（過去利用あり） スキルC 4回 稼働中 スキルB？ —— 記録なし 9回 スキルD リポジトリの在庫を母集団にすれば0回が現れる。 導入日で「導入以来0」と「休眠」を区別。 未発火のスキルは、ログに1行も出ない 。集計だけでは永久に漏れる 。 連続0週を、週次で自動レポート → 連続 10週 で棚卸しゲート発動 Copyright © Canly, Inc. All rights reserved. 15
16. 週次で届く、棚卸しレポートの実物 休眠・棚卸し（在庫 =model-invocable のみ／連続 0週数・週境界 =JST月曜始まり ・report_week=2026-08-03） レポートの読み方 棚卸し対象（10週以上連続0）：4件。 母集団 在庫のうち model-invocable のみ（明 示起動専用は除外） 週境界 JST 月曜始まり。導入週を起点に連続0 週を数える 状態 現役／様子見／長期休眠／導入以来0 の4分類 状態＝ 現役(0週)／様子見(1〜9週)／長期休眠 (≥10週・過去に利用あり)／ 導入以来0(一度も起動なし)。 スキル 連続0週 最終利用日 状態 トリアージ （SLO分析系） 12 — 導入以来0 棚卸し対象（継続/廃止判断） （コスト分析系） 11 — 導入以来0 棚卸し対象（継続/廃止判断） （フィードバック系） 10 — 導入以来0 棚卸し対象（継続/廃止判断） 連続 10週 以上 ＝ 棚卸し対象 （セキュリティ調査系） 10 — 導入以来0 棚卸し対象（継続/廃止判断） オーナーに割り当て、3分類のどれかを診断する。 この （IaC構築系） 8 — 導入以来0 様子見（導入間もない） （構成準拠チェック系） 7 — 導入以来0 様子見（導入間もない） 棚卸しゲート 時点では 4件。 在庫を母集団にしているので、 一度も呼ばれていないスキルも必ず行として現れる 。 ※ 公開用にスキル名は領域名へ抽象化しています。 Copyright © Canly, Inc. All rights reserved. 16
17. ループの実例 — 検出と診断 STEP 1 ｜ 検出 棚卸しゲートが検出 デイリーレポート系スキル 導入以来 0回・連続 10週 到達 STEP 3 ｜ 真因 STEP 2 ｜ 仮説の棄却 診断 → 機能が不要？ —— No デイリーの報告需要は 現場に実在していた 原因 週次レポート系スキルと 発火文脈が同じ → ＝ 作成ゲート③「区別可能性」の欠如。 AIは常に週次側を選んでいた。 デイリー／週次は、別スキルではなく ——パラメータ だった。 Copyright © Canly, Inc. All rights reserved. 17
18. ループの実例 — 削除ではなく統合 AFTER ｜ 1スキル BEFORE ｜ 2スキル create-daily-alert-report 統合 → create-weekly-alert-report create-alert-report mode: daily mode: weekly 候補数は減り、機能は全部残った 。 棚卸しは、削除リストの生成器ではなく ——診断器。 Copyright © Canly, Inc. All rights reserved. 18
19. 持ち帰り 3点 1 2 3 施策より先に、 実測 根拠の置き場所を間違えると、同じ施策でも結論が逆になる。 使われない ≠ 廃止 3分類（発火していない／出番が来ていない／作るべきでなかった）で診断してから、手を打つ。 効くのは量ではなく、 意味の重なり スキルは静かに選ばれなくなる。エラーは一切出ないので、計測していなければ永久に気づけない。 Copyright © Canly, Inc. All rights reserved. 19
20. CLOSING 作って終わりにしない。 AI資産にも、ソフトウェア資産と 同じ ライフサイクル管理を。 株式会社カンリーは、ヒトとAIの力で「店舗経営を支えるインフラ」を つくっています。 採用情報・技術発信 → biz.can-ly.com 同じ内容をブログでも公開しています zenn.dev/canly/articles/43bef1eacdae44 Copyright © Canly, Inc. All rights reserved. 20