株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。
ヘンリーでは以前から開発にClaude Codeを用いていましたが、最近はSkillの活用などでClaude Codeの性能をもっと引き出そうとする動きが活発になっており、ブログでの発信も増えてきています。
Claude Code を活用した電子カルテの外部連携仕様書メンテナンス自動化の取り組み - 株式会社ヘンリー エンジニアブログ
今回は私が以前に作成したSkillをチームの共有物として管理・展開する際に気付いたSkill管理の課題と対策について話そうと思います。
以前作ったSkillの紹介
起票されたIssueの中身を確認・追加調査をしたうえで実装からPR作成までを全自動で行うOrchestrator型のSkillです。（以降 dev Skillと表現）
このdev Skill作成は元々チームへの展開も前提として考えながら作成を進めていました。
試行錯誤を経て組み立て終わったdev Skill。続いてチーム展開について考えるステップへと進む予定でしたが、ここに1つ問題がありました。
チーム展開の引っかかり
チーム展開をした以降はSkillのメンテナンスも私個人ではなくチームで行う想定でしたが、いざチームへの展開について考ると「このSkill、自分以外の人がメンテするの？」という親心のような気持ちが私の中に生まれていました。
他の人からPRが来ることを想像すると少し抵抗を感じる。通常業務のコード修正とSkill修正で何が違うのか。
この感覚を整理・言語化しないままチームに展開をすると無秩序な管理状態になるかもしれません。そこでチーム展開の作業は一旦手を止め、Skill管理について課題や見落としが無いかを考え直すことにしました。
課題整理
課題1: 変更内容の評価が難しい
通常業務のコード修正であれば既存実装の設計や社内での知見があるため、ある程度正解と呼べるものが導きやすいです。そのため実装者とレビュアーの間で認識も揃えやすく、基本的にApproveまでは進めやすいと言えます。
しかしSkillはまだ設計と言えるほど成熟したパターンが確立できてなく、皆手探りという状況です。指示はどれだけ長い/短い方が良いかの1点だけでもXで日々議論が起きています。
そのためSkillやプロンプトについてはまだ正解といえるものが無く、変更内容への評価は主観に頼らざるを得ないと言えます。通常のコードとは違う部分でApproveのハードルが高い理由がここにあります。
課題2: 何をSkillに行わせたいかが利用者によって変わる
またSkillに何を行わせたいかが人によるという課題もあります。
Aさんが入れたい変更をPRで出したとしても、他の人にとっては入れてほしくない内容かもしれません。Skillに何を行わせるか、チームのSkillを使う人が増えるほど意見の衝突は起きやすくなると考えました。
かといってSkillのオーナーを設けたりSkillの書き方を厳密にしたりすると、Skillの更新が停滞するという別の問題も生まれてしまいます。 これはSkillを活用して働き方を変えようとする今の動きにとって足かせとなってしまいます。
課題3: スキルのポータビリティ
レビューとは別の文脈ですが、Skillを完全にチームの管理とする場合この問題が生まれます。
Skillを使った開発はとても便利で、導入して1ヶ月ですが既にこれなしでの開発は考えられない状態です。
このときSkillを完全にチームのものとして育てていくと、それまで積み立ててきた便利なSkillが環境の変化によって持ち出せなくなるという問題があります。例えば転職や組織異動の際に、日々の開発を支えてきたSkillが使えなくなる状況です。
活用しているSkillは、もはやその人自身の開発能力と言って良いと私は考えています。よく使うSkillの中身はほとんど汎用的なプロンプト設計のノウハウであり、特定の業務ロジックとは異なります。個人の作業効率を高めるための環境構築の一部という性質のものです。キャリアにおけるスキルのポータビリティという観点から、その人の開発能力であるSkillがリセットされる状況はできれば避けたいと考えました。
課題への対策
Skill管理の課題について整理を終えたので、続いてその対策を考えます。 今回は2つの方針を対策として採りました。
対策1: 個人SkillとチームSkill を別で管理する
そもそもSkillの本質は何かを考えると、その中身は汎用的なプロンプト設計のノウハウであり、特定の業務ロジックとは異なります。dotfilesやエディタ設定と同じく、個人の作業効率を高めるための環境構築の一部です。
この前提に立てば、Skillは個人の開発環境として扱うのが自然です。個人の環境を改善していくことが前提であり、そのうえで作られたSkillや知見をチームに還元するという流れです。
そこでチーム展開用のSkillとは別で、個人用のSkillリポジトリを用意する方針を取りました。より正確に表すと、元々個人用に作成したSkillをチームのリポジトリにも展開するというイメージになります。
対策2: チームSkillをStarter Kitと位置づける
Skillのチーム展開を最初に意識した時は、作成したSkillの導入について半ば義務化するような考えを持っていました。チームのSkillを使うことを当たり前にすれば、各自の開発力が高まり会社の生産性も高まると考えてのことです。
そのためSkillのレビューを厳密にするか、意見の衝突をどうするかという問題が生まれましたが、ここで重視したのはSkill作成が活性化する方向に倒すことです。
Skillの作成はヘンリー内でも新しい取り組みで、まだ知見が十分に溜まっていない段階です。この時期にレビューを厳密化してしまうと、Skill作成そのものが停滞しかねません。今は多少の性能低下を許容してでも、Skill作成・変更が活発に行われる状況を優先すべきと考えました。
そこでチームSkillは「Starter Kit」として位置づけることにしました。Skill環境をまだ用意できていない人が、これを入れればとりあえず開発速度を上げられる出発点です。使用は任意とし、変更のハードルも下げる方針を取りました。
そのまま使い続けても問題はありませんが、スキルのポータビリティの観点からも、ゆくゆくは自分のSkillsを育てていく方が望ましいです。管理はチームSkillを活用する人たちで基本的には行います。
ただし「個人Skillを使う自分はチームSkillは無関係」という考えは持つべきではありません。
個人Skillを使う人も、Skill作成の過程で得た学びをチームSkillに反映したり、勉強会で知見を共有したりと、チームへの還元を推奨としています。
個人で得た知見をチームに共有し、お互いの学びを循環させることで全体のAI活用力を底上げする。この「個人で試す → 効果を確認する → チームに還元する」というサイクルを回すことこそが、Starter Kitという位置づけの本質的な狙いです。
個人Skillのセキュリティについて
今回チームSkillsとは別で個人Skillsを持つ対応を取りましたが、このパターンにはセキュリティ上の課題が残ります。
個人リポジトリでSkillを管理する以上、会社の機密情報が外部に漏れないよう注意が必要です。Skillの内容次第では、リポジトリ構造やワークフローの詳細など、機密性の高い情報が含まれる可能性があります。
そのため個人Skillに含めるのは汎用的なプロンプト設計のノウハウに限定しています。「情報収集をしてIssueを更新する」「実装前にテスト方針を立てる」といった、どのプロジェクトでも通用する手順や思考パターンです。社内のAPI仕様、環境固有の設定、業務ロジックに関わる記述は個人Skillには含めず、それらはチームSkill側に閉じる運用としています。
この線引きを守る限り、個人Skillの機密性は一般的な個人の開発環境設定と同程度に収まると考えています。ただし、業務中に試行錯誤する中で境界が曖昧になるリスクはゼロではなく、この点については社内でも議論、整理を行ってきました。
実際に導入してみて
今回考えた課題と対策をもとに、実際にSkillをチームに展開してみました。
嬉しいことにチーム展開したdev Skillがかなり好評で、現状のSkillをそのまま活用してくれているようです。そのため、懸念していた意見の衝突やレビュー負荷といった問題はまだ顕在化していません。
一方で、個人Skillの運用を切り離したことによるメリットは早くも実感しています。
チーム展開後も私自身のSkill改善は止まっていません。個人Skillリポジトリがあることで、試したいアイデアをチームへの影響を気にせず自由に試行できています。もしSkillがチームの管理下にしかなかったら、「この変更、チーム全体にとって有用か？」という判断が毎回必要になり、個人の実験的な改善は確実に停滞していたと思います。
対策で狙っていた還元のサイクルも動き始めています。ただし現時点では、Skillの作成者である私自身が個人Skillの改善をチームSkillに取り込むケースが中心です。他のメンバーが同じサイクルを自然に回せるかはこれからの課題ですが、まずは1人でも実際に回っている事実は、この仕組みの可能性を示せていると考えています。
おわりに
今回Claude Code Skillsのチーム展開を考えるにあたり、Skill管理が持つ課題に向き合い、個人SkillsとチームSkillsを分けて管理する方針を採りました。
個人の実験と改善を止めず、そこで得た知見をチームに還元するサイクルを回すことが、この仕組みの狙いです。
