この記事で解決する課題

Claude Code の Skills を作ってはみたものの、「便利なショートカット集」以上のものになっていない——そういう状態の人向けの記事です。

2026年7月24日に Findy AI+ が、ダイニー・ディップ・LayerX・タイミーの4社から「社内でよく使われている Claude Code Skills トップ5」を集めた記事を公開しました。4社ぶんのランキングを横に並べると、Skills をどう位置づけると効果が出るのかについて、かなりはっきりした傾向が見えます。この記事ではその傾向を整理し、自分の Skill 構成を見直すための観点に落とします。

出典: 【Claude Code活用特集】あの会社で一番使われてるSkillsは？Claude Codeの利用Skills Top5を大公開！ | Findy AI+
公式ドキュメント: Extend Claude with skills

先に注意: 4社の数字は直接比較できない

考察に入る前に、元データの前提を押さえておきます。ここを飛ばすと「A社よりB社のほうが使われている」のような無意味な比較をしてしまいます。

会社	計測期間	集計軸
ダイニー	2026/04/14 - 07/16	利用者数順(エンジニア職のみ)
ディップ	2026/04/27 - 07/16	運用期間ベース
LayerX	2026/06/01 - 06/30	Fintech事業部(エンジニア約7名)
タイミー	2026/06/07 - 07/07	利用回数順(ジャンル統合)

期間も集計軸も母集団もバラバラです。特にダイニーは「起動数順だと一部ヘビーユーザーの個人 Skill が上位に来る」ため、あえて利用者数順にしたと明記しています。この判断自体が示唆的で、**Skill の価値を測るなら「何回叩かれたか」より「何人に定着したか」**という考え方が背景にあります。

したがって以下で見るのは順位の大小ではなく、4社に共通して現れる「カテゴリ」です。

4社の Top5 を並べる

	ダイニー	ディップ	LayerX	タイミー
1	データ分析(bigquery)	Issue起票	PR自動レビュー	データ分析(BigQuery系20種)
2	システムログ分析(cloud-logging)	アイデア壁打ち	QA項目書生成	Git操作・コミット(28種)
3	AIコードレビュー(rai-review)	作業計画書作成	BigQuery分析アシスタント	テスト・品質保証(16種)
4	エラーログ分析(sentry)	実装〜PR作成	リリースPR作成	PR作成・コードレビュー(24種)
5	リリースブランチ判定	レビュー対応	コード簡素化レビュー	設計・ハンドブック(35種)

見えてくる3つの構造

1. 上位はレビュー・QA — ボトルネックが「書く」から「読む」に移っている

4社すべてで、PR レビューまたは QA 系の Skill が Top5 に入っています(ダイニー3位・ディップ5位・LayerX 1位・タイミー4位)。ディップの記事にはその理由がはっきり書かれていました。

AIエージェントがメンバーの手元に入り、個人の作業速度は確かに上がりました。けれども同時に、開発フローのボトルネックは「個人がコードを書く時間」から「他のメンバーがレビューする時間」に移動しました。

これは Skills に限らず、コーディングエージェント導入後に必ず起きる構造変化だと思います。書く速度だけが上がると、差分がレビュー待ち行列に積み上がるだけで、チームのスループットは変わらない。だから各社は「人間のレビュー前に機械的な指摘を潰す」(ダイニー rai-review)、「観点ごとに専門エージェントを分割して一貫した深さでレビューする」(LayerX claude-code-pr-review)という形で、Skill をレビュー側に投入しています。

Skill を「自分が速くなるため」だけに作っていると、この移動したボトルネックには手が届きません。

2. データ分析 Skill の主役は「SQLを書かない職種」

3社で BigQuery 系のデータ分析 Skill が上位に入っています。そしてタイミーでは、PdM・アナリストの利用率がエンジニアの約2倍だったと報告されています。

タイミーの背景説明が具体的です。PdM や事業企画が「先週のリピート率を地域別に見たい」程度の集計でもエンジニアへの依頼が必要で、その待ち時間が意思決定のボトルネックになっていた、と。ダイニーも同様に、障害の一次調査が「環境ごとの接続先、ログフィルタの書き方、クエリのコスト管理」といった前提知識のせいで一部メンバーに属人化していた、と書いています。

つまりデータ分析 Skill が効くのは、SQL が書けないからではなく、「どのテーブルを、どの環境で、どういうコスト前提で叩くのか」という暗黙知が Skill に入っているからです。汎用の SQL 生成では代替できません。

3. Skill の中身は「テクニック」ではなく「自社固有のルール」

並べてみて一番はっきりしたのはこれです。上位に来ている Skill の説明を読むと、そのほとんどが自社固有の取り決めを内蔵しています。

ダイニーの identify-release-branch: 週次でリリースブランチをカットするメインラインモデルの運用ルールを内蔵し、「この修正はどのブランチに向けるべきか」を判定する
タイミーの Git 系 28種: プロジェクト固有のコミットメッセージ規約・ブランチ命名規則に準拠
LayerX の qa-sheet: 差分から QA 観点を洗い出し、そのまま貼れる TSV 形式で出力
タイミーの設計・ハンドブック系 35種: Design Doc やバックエンド開発ハンドブックを Skill 化

汎用的に便利なプロンプトは、そもそも Skill にしなくてもモデルが勝手にやってくれます。Skill にする価値があるのは「そのモデルが絶対に知り得ない、自分たちの決めごと」のほうだ、ということです。

これは公式ドキュメントの説明とも整合します。ドキュメントには、同じ指示・チェックリスト・手順を繰り返し貼り付けているとき、あるいは CLAUDE.md の一節が「事実」ではなく「手順」に育ってしまったときが Skill を作るタイミングだ、と書かれています。加えて Skill の本文は使われるときにだけ読み込まれるため、長いリファレンスを抱えても普段のコストはほぼゼロです。だから「分厚い自社ルール」を入れるのに向いています。

もう1つの論点: 個人設定に置かない

ディップは Skill を「ローカルの個人設定ではなく、部の共通資産として配布」し、複数プロジェクトで同じものが動く状態を維持していると書いています。

前述のボトルネック論と組み合わせると理由がわかります。A さんが Skill パイプラインを通して PR を作っても、レビューする B さんが同じパイプラインを知らなければ、判断軸も速度も揃わない。Skill が配布されて初めて、それは「標準」になるわけです。

~/.claude/skills/ に置いたままの Skill は、どれだけ優れていても個人の時短ツールで終わります。リポジトリの .claude/skills/ に入れてコミットするかどうかは、思っているより大きな分岐点です。

明日からやること(3ステップ)

自分の Skill を「汎用/自社固有」で仕分ける。 汎用側は消していい。モデルが勝手にやる
レビュー・QA 側に1つ作る。 個人の実装速度ではなく、レビュー待ち行列を短くする方向に投入する
~/.claude/skills/ にあるものをリポジトリに移す。 配布されていない Skill は標準にならない

なお Findy の記事の末尾には、自分の Claude Code ログから利用 Skills の Top5 を出す分析プロンプトが無料で公開されています。まず現状を数えるところから始めるなら、そちらが手っ取り早いです。

まとめ

4社のランキングから読み取れたのは、Skills が効いている組織では Skill が「便利なショートカット」ではなく「組織の決めごとを実行可能な形にしたもの」として扱われている、という点でした。レビューに投入されていること、SQL を書かない職種が主役になっていること、中身が自社固有のルールであること、そして配布されていること。この4つが揃ったときに、個人の時短が組織のスループットに変わっているように見えます。

なお本記事は公開された4社のデータを読んだ整理であって、筆者が同じ体制を組んで検証したものではありません。数字の扱いには冒頭に書いた前提の違いがあることをあらためて添えておきます。