「またこの指示、書いてるな」

Claude Code のターミナルに、ぼくは今日も同じプロンプトを打ち込もうとしていました。

議事録の要約。コードレビュー。メールの返信下書き。SNS投稿のたたき台。週に20回は同じ前置きから書き始めている。

毎回30秒。1日10回で5分。月20営業日で100分。

「この5分、本当に毎日払う必要あるか」

そう自問したのが、Skill 機能を本気で触り始めたきっかけです。

Claude Code には .claude/skills/ というフォルダがあります。ここに業務ごとの指示書を置いておくと/議事録要約 のような短いコマンドで呼び出せる。プロンプトは1回書けば、あとは1単語で再利用できます。

毎回30秒書いていた指示が、3秒で呼び出せる。

最初に5本の Skill を整えてから、ぼくの作業時間は 1日30〜40分ほど浮きました。月にすると10時間分。

この記事は、その Skill 機能を自分の業務向けに自作して、回し始めるまでの実装書です。

具体的に何が変わるのか。

- 毎日の議事録要約が「議事録を貼って /議事録要約 を呼ぶだけ」になる

- チーム共通のレビュー観点が /コードレビュー 1つに集約される

- メールの返信下書きが「相手の文面を貼って /メール下書き」で形になる

- SNS 投稿のたたき台が「ネタを貼って /SNS投稿」で文体ごとに出る

- リサーチのまとめが「URLとメモを渡して /リサーチまとめ」で揃う

呼び出し1単語で、いつも通りの観点で、いつも通りのフォーマットで返ってくる状態。これが Skill の本質です。

こんな状態で詰まっていませんか

Claude Code を入れて2週間〜2ヶ月の中級者に聞きます。

- 毎日 Claude Code に「議事録を3カテゴリでまとめて」のような長い前置きを打っている

- 同じ指示をテキストファイルに保存しておいて、毎回コピペしている

- 自分のチーム用のレビュー観点があるのに、毎回プロンプトに書き直している

- Claude Code の .claude/ フォルダはなんとなく触っているが、Skill は使えていない

- ネットで「Skill を使うと便利」とは見るが、具体的な作り方の解説が薄い

- チームの他のメンバーにも同じ Skill を配って統一したいが、共有方法がわからない

- メモアプリにプロンプトを保存しているが、必要な時に出てこなくて結局1から書いている

- 毎週やる定例業務の指示を、毎週律儀に書き直していて少し疲れている

3つ以上当てはまるなら、この実装書はあなた向けです。

ぼく自身、半年前まで全部当てはまっていました。Claude Code は触っているのに、毎日同じ前置きを書いている矛盾。それを Skill で1つずつ片付けていった記録が、この記事の中身です。

なぜ今、Skill を自分の業務向けに作るのか

Claude Code は、もうエディタ拡張やコマンド補助の枠を超えています。

「指示書を渡せば、自分の代わりに作業する道具」になりつつある。プロンプトを毎回書き直す段階から、プロンプトを資産として置いておく段階に移っているのが今です。

その資産の置き場所が .claude/skills/ で、置き方を覚えれば一気に作業が変わります。

ぼくが調べた限り、Skill の使い方をまとめた日本語の実装解説は、まだほとんどありません。英語のドキュメントに断片的にあるくらい。

「動かして見せる」レベルの解説が少ないので、自分で手を動かして体系化するのは、今やる価値があります。

理由はもう一つあります。

業務指示というのは、自分の頭の中で「こういう順序でやる」と暗黙にやっている手順を、言葉で書き出す行為です。Skill を作る過程は、自分の業務手順を言語化する過程そのもの。

書き出してみると、思った以上に自分の手順がブレていることに気付きます。「議事録要約」を10人がやると、10種類のフォーマットが出てくる。自分自身の中でも、月曜の要約と金曜の要約でフォーマットが違っていたりする。

Skill を1本作るたびに、自分の業務の輪郭がはっきりしてくる。これは AI に頼らずとも、その後の自分の仕事の速度を上げる副作用です。

SaaS の業務テンプレ集（月¥3,000〜¥10,000のもの）と比べると、Skill は無料で、自分の業務に合わせて完全にチューニングできます。

しかも、自分のチームで共有もできる。Git リポジトリに .claude/skills/ を含めておけば、チーム全員が同じ Skill を使える状態を作れます。

「自分の業務手順を、自分のチーム用にカスタムした AI 指示書として持っておく」

これが、Skill 自作の本質的な価値です。

さらにもう1つ、見落とされがちな価値があります。

「指示の品質が、人ではなく組織のものになる」点です。

例えばコードレビューの観点。ベテランのレビュアーが頭の中で持っている「ここを最初に見る」「この書き方は要注意」というチェックリストは、その人が抜けると一緒に失われます。

これを Skill に書き出して .claude/skills/code-review.md として残しておくと、新しいメンバーが入ってきても、同じ観点で初日からレビューに参加できる状態が作れる。

「個人の暗黙知 → 組織の明示資産」への変換が、Skill 1本ごとに進みます。

これは AI を導入する本当の意味でもあります。プロンプトの書き方を学ぶことではなく、自分たちの業務手順を AI 経由で再利用可能な形に整理することの方が、長期的にはずっと効きます。

ぼくが Skill 自作に振り切った理由

ここは盛らずに書きます。

ぼくは Claude Code を1年弱使っています。最初の半年は、ターミナルから対話的にプロンプトを打つだけの使い方でした。

「便利だな」とは思っていたけど、便利の上限が見えていない感覚もありました。

転機は、自分の Claude Code の履歴を見返した時です。同じプロンプトの冒頭文字列がほぼ毎日出てくる。「以下の議事録を、3カテゴリでまとめてください。重要トピック・決定事項・次回までの宿題」のような前置きを、月に60回打っている。

時間にして、月30〜40分。これを再利用可能にしないのは、シンプルにもったいない。

その日のうちに .claude/skills/ を初めて開いて、まず「議事録要約」の Skill を1本作りました。Markdown ファイル1枚です。中身は今までターミナルに打っていたプロンプトをそのまま貼り付け、頭にメタ情報を足しただけ。

それで /議事録要約 と打つと、議事録を貼り付けるだけで要約が返るようになりました。

最初は半信半疑でした。「これ、本当に再現性あるのか」「呼び出すたびに微妙にフォーマットが揺れるんじゃないか」と疑っていました。

1週間使ってみて、揺れは思ったよりずっと小さかった。むしろ毎回プロンプトを書き直していた頃の方が、自分の指示文が日によって揺れていたのだと気付きました。

ここから、ぼくの業務指示は次々と Skill に切り出されていきました。

- コードレビューの観点（チーム用）

- メールの返信下書き（敬語の調整含む）

- SNS投稿のたたき台（プラットフォームごとに文体調整）

- リサーチ結果のまとめ（参照元の整形含む）

5本作ったあたりで、Claude Code に向かう時の心理的なコストが大きく下がりました。

「コマンド1つで、いつも通りの指示が走る」状態。これは、自分が日常的に使っているツールが「自分仕様」に育つ感覚で、地味だけど効きます。

副次的な効果として、自分のチームの新人さんに「この観点でレビューするとよい」を口頭で説明する手間も減りました。.claude/skills/code-review.md を見ておいて」で済む。

実装が安定するまでに踏んだ落とし穴は、後の章に全部書きます。Skill の書き方そのものは難しくないですが、「再利用可能性が高い書き方」と「すぐに陳腐化する書き方」の差は大きい。その差を分ける設計判断を、章3と章4で実例ベースで渡します。

教材の章立て

全5章で構成しています。

「最初の1本を動かす → 業務テンプレを5パターン作る → チームで運用化する」の3段階で進みます。