プロダクト開発現場における Claude Skills の育て方と活用事例

はじめに

こんにちは！UPSIDER 支払い.com事業部の村上です。

2026年3月19日（木）に渋谷で開催された「渋谷でビール片手にLT会！第3木曜LT会 #17」で登壇をしてきました。

「プロダクト開発現場における Claude Skills の育て方と活用事例」というテーマで、チームで Skills を共有・運用するための方法と、実際に Skills を活用して業務課題を解決した事例について紹介しました。

発表の背景

Claude Code がリリースされて1年ちょっとですが、すっかり日々の開発に欠かせないツールになっているんじゃないでしょうか。かく言う自分も毎日使っています。

そんな中、自分用の Skill をいくつか作って便利に使っていたのですが、ふと「これ、他のメンバーも似たようなの作ってるんじゃないか？」と気になり始めました。

でも Skills を共有・管理する仕組みはチーム内にはまだないし、別のリポジトリで使いたい場合にどうすればいいかも分からない。

実際に聞いてみたら、やっぱり各自がローカルで似たような Skill を持っていたんです。

それなら管理の仕組みを整えて共有しよう ── そう思ったのが今回の発表のきっかけでした。

Claude Skills の育て方（管理方法と運用ルール）

Plugins と Marketplaces による配布

共有方法を考えるにあたって活用したのが、Claude Code の Plugins と Marketplaces の仕組みです。

Plugins は Skill・MCP・Agent・Hook をまとめたパッケージで、Marketplaces 機能を使うことでチームや Organization 内に配布できます。

公式でも Notion、Slack、Figma などの Plugins が提供されています。

Organization プライベートリポジトリでの管理

社内では既にプライベートリポジトリで Skills を一元管理しようという動きがあり、自分たちのチームもその取り組みに合流する形で Skills の共有を始めました。

なぜ独立リポジトリなのか

Skills の管理方法としては、既存リポジトリの .claude/ 内で管理する方法と、独立リポジトリで管理する方法があります。

自分たちは以下の理由から、独立リポジトリを選びました。

	`.claude/` 内	独立リポジトリ
適用範囲	全員に強制適用	使いたい人だけ
レビュールール	プロダクトと同じ基準	独自のルール

.claude/ 内だと検証段階の Skill が全メンバーに影響するリスクがありますし、プロダクトのレビュー基準を適用するとレビュアーの負荷が上がり、共有が滞ってしまいます。

独立リポジトリにすることで、これらの課題を回避できました。

運用ルール ── ハードルを下げて試す文化

具体的な運用ルールはシンプルです。

新規作成・マージは自由（レビュー不要）
更新時は Skill 作成者（オーナー）にレビュー依頼をして品質を担保

ポイントは、まず共有できる環境を作ることを最優先にしたところです。

AI 時代は変化のスピードが非常に早く、レビューのハードルが高いと誰も新しい Skill を作らなくなってしまいます。

各自がローカルに持っている Skill を持ち寄ることで、チーム内の知見を広げたいと考えていました。

活用事例

ここからは、実際にチームで作って活用している Skills を2つ紹介します。

事例1 ── DB クエリ Skill

事業に関わる数値や DB のデータを確認したい場面は日常的にあります。

簡単なものならビジネスサイドで完結できますが、複雑なクエリが必要になるとエンジニアに SQL 作成を依頼することになります。

エンジニアの作業は中断されますし、ビジネス側にも回答待ちの時間が発生します。

双方にとって地味に負担でした。

そこで作ったのが DB クエリ Skill です。構成は以下の通りです。

8つのアクション定義: スキーマ確認、クエリ作成、レビュー、最適化、解説など
resources 配下にテーブル定義: テーブル一覧・分類・各テーブルのスキーマ情報

これにより、ビジネスメンバーが Claude を通じて自らデータにアクセスできるようになりました。

ただし、最新の DB スキーマにどう追従するかは残課題で、現在良い方法がないか模索しています。

事例2 ── UX ライティング Skill

プロダクト内の文言は、大枠をビジネスサイドと決めた上で、細かい言葉遣いは実装者がその場で判断していました。

そうすると、例えばある画面では「振込日」、別の画面では「送金日」のように、同じ意味なのに表記が揺れてしまう可能性があります（これはあくまでイメージ例で、実際にこの表記揺れが発生したわけではありません）。

この課題に対応するために作ったのが UX ライティング Skill です。

💡 📝 この Skill の具体的な内容は、以下のテックブログ記事でも詳しく紹介しています。
tech.up-sider.com

レビュー観点と出力形式の指定: どんな基準でチェックし、どんなフォーマットで結果を返すか
表記揺れしやすいワードの定義と正解: 誤りがちな用語とその正しい表記
コンポーネントごとのルール: 「ですます調」か「体言止め」かなど、コンポーネントの種類に応じたルール

実装時やコードレビュー時にこの Skill を実行すると、表記揺れを検出して修正案を提示してくれます。

地味ですが、UI の一貫性を保つ上で確実に効果がありましたし、実装者が文言で悩む時間も減りました。

まとめ

今回の発表でお伝えしたかったことは、大きく3点です。

Plugins と Marketplaces 機能を使うことで、チームへの共有が可能になる。全員に強制するのではなく、必要な人が選べる仕組みが大切
共有の活性化と品質担保は並行して進める。変化の早い時代だからこそ、ルールを重くしすぎないこと。まず共有できる環境を作り、品質は skill-creator などで担保しつつ、精度は継続的に向上に取り組む必要がある
属人性が高い業務や定型作業は Skill 化するチャンス。今回紹介した DB クエリや UX ライティングのように、特定の人に依頼が集中しがちな作業こそ、Skill にすることでチーム全体の生産性が向上する