「ちょっと聞いてみたい」だけでもOK！ ツールや業務効率化についての相談をすべて1対1で丁寧にお答えします。 まずはお気軽にメッセージをどうぞ！LINE公式アカウントはこちら！
「Claudeに毎朝同じような指示を貼り付けている」——そんな悩みをお持ちの中小企業の現場担当者は少なくないはずです。議事録の整形、請求書文面のチェック、求人原稿のドラフト。毎日コピペしている指示文を「Skills」というファイルに閉じ込めると、肩の力が一段抜ける構造になっています。これが Anthropic 公式の Agent Skills の根本価値なんですよね。
旧版（2026年4月初旬執筆）は、Anthropic が 2025年10月に正式公開した直後の Agent Skills を解説した記事でした。2026年4月以降のドキュメント整理で「progressive disclosure（段階的開示）」「Level 1〜3 のロード戦略」「pre-built Agent Skills の4種類（pptx／xlsx／docx／pdf）」が公式ドキュメント上で明確化されたため、本記事ではその仕様を反映して全面リライトしました[要確認：4月の docs 更新履歴の正確な日付]。
- ●「毎朝Claudeに同じ前提条件を貼っている。なんとかしたい」
- ●「Skills を作ると言われても、YAML フロントマターの書き方で詰まる」
- ●「2026年4月以降の Skills 仕様（progressive disclosure・pre-built）を整理しておきたい」
本記事では、Anthropic 公式ドキュメント（platform.claude.com/docs）に記載されている内容と、公式 skills リポジトリ（github.com/anthropics/skills）の公開事例のみを根拠に、Skills の構造・これまでとの違い・業種別の使い道・5ステップの導入手順をまとめました。地道ラボは「明日から試せる具体的な一歩」を渡す場なので、自分の業種に近い使い道からコピペで試せる粒度を意識しています。
Claude Code Skills とは「同じ指示を覚えさせる」仕組み
Skills とは何かを一行で言い切ります。Skills は「同じ前提・同じ手順」を Claude に覚えさせて、毎回コピペする手間を消すための仕組みです。Anthropic 公式ドキュメントには次のように記載されています。「Agent Skills are modular capabilities that extend Claude’s functionality. Each Skill packages instructions, metadata, and optional resources (scripts, templates) that Claude uses automatically when relevant.」——要は「Claude に追加できる業務テンプレの単位」と理解すれば、最初は十分なんですよね。
実体は、ファイルシステム上の1つのディレクトリです。Claude Code であれば `~/.claude/skills/
公式の YAML 仕様書（Skills overview ページ）を読み込むと、`description` の書き方には明確な制約があります。「The description should include both what the Skill does and when Claude should use it.」と明記されていて、「何をするか」と「いつ使うか」の両方を入れる前提なんですよね。これを「議事録を整える」とだけ書いてしまうと、トリガー条件が曖昧になって発動精度が落ちる、というのは公式 docs から読み取れる重要なポイントです。
指示文例（Skill 雛形を Claude Code に作らせる）：
「私は中小企業の経理担当です。月末の請求書発行時に、消費税区分（10%／軽減8%／不課税）と支払いサイトの整合性をチェックする SKILL.md を、`.claude/skills/invoice-check/SKILL.md` の場所に作ってください。YAML フロントマターには name と description を必ず入れて、description には『請求書の文面を経理担当者向けにチェックする。請求書・インボイス・消費税区分の話題で発動』と書いてください。」
指示文例（既存の指示文例を Skill 化する）：
「以下は、私が毎週貼っている『商談議事録の整形指示』の本文です。これを Skills 形式に変換して、`.claude/skills/meeting-minutes/SKILL.md` を生成してください。description は『商談議事録を4項目（決定事項／宿題／論点／次回アクション）に整形する。営業会議・商談議事録・打ち合わせメモの話題で発動』としてください。」
| 項目 | 公式仕様 | 必須／任意 |
|---|---|---|
| name | 小文字英数とハイフン・最大64文字・予約語「anthropic」「claude」NG・XMLタグ不可 | 必須 |
| description | 非空・最大1024文字・XMLタグ不可・「何を／いつ使うか」を含める | 必須 |
| SKILL.md 本文 | 手順・前提・出力形式・注意点（5,000トークン以下が目安） | 必須 |
| 追加 Markdown（FORMS.md／REFERENCE.md 等） | 細かい仕様・参考資料 | 任意 |
| scripts/ ディレクトリ | 実行スクリプト（Python など）— bash 経由で実行 | 任意 |
ここで一つ、覚えておくと得な前提があります。公式 docs に「Cannot contain reserved words: ‘anthropic’, ‘claude’」と明記されているため、`name` に「claude-meeting」のような命名はそもそも通らない仕様なんですよね。最初に予約語入りで命名して詰まる、というのは公式の制約を読み飛ばすと起こりがちな落とし穴です。
SKILL.md は最初から完璧を目指さないほうがいい設計です。公式ドキュメントの best-practices ガイドにも「描写を曖昧にしないこと」と書かれていて、最初は description と本文 5〜10 行から始めて、使いながら手順を足していく運用が想定されています。完成度60点で出して、3週間使い倒して育てる、くらいの温度感でちょうどいいと感じます。
これまでとの違い — 4月以降の Skills で明文化された3つの点
ここからが今回のリライトで一番加筆したパートです。2026年4月以降の Skills 公式ドキュメント整理で明文化されたのは、ざっくり3つ。progressive disclosure（段階的開示）の正式な仕様化、Level 1〜3 のロード戦略の明文化、pre-built Agent Skills（pptx／xlsx／docx／pdf）の正式提供の3点です[要確認：「Skills 2.0」という公式呼称は現時点の docs では確認できず、本記事では便宜呼称として扱う]。
公式ドキュメントには次のように書かれています。「This filesystem-based architecture enables progressive disclosure: Claude loads information in stages as needed, rather than consuming context upfront.」——要は 「Skill が大量にあっても、使うときだけ本文を読み込むので context window が圧迫されない」設計なんですよね。旧版（4月初旬執筆）の段階では「Skill 本文が常時ロードされる」前提で書いていた箇所があり、ここを刷新する必要が出てきました。
公式 docs が示す Level 1〜3 の構造は次のとおりです。Level 1 はメタデータ（name と description、約100トークン／Skill）が常時ロード、Level 2 が SKILL.md 本文（5,000トークン以下）でトリガー時にロード、Level 3 が追加ファイルやスクリプト（実質無制限）で必要時にロード——という3段構成。各 Skill のメタデータだけが常時ロードされて、本文はトリガーされたときに初めて読み込まれます。
指示文例（Level 3 のスクリプトを使う Skill を作る）：
「`.claude/skills/invoice-pdf/` ディレクトリに、SKILL.md と scripts/generate.py を配置してください。SKILL.md には『請求書情報を JSON で受け取り、scripts/generate.py を実行してPDFを出力する』という手順を書いて、scripts/generate.py には reportlab で PDF を生成する Python コードを置いてください。」
指示文例（progressive disclosure の動きを確認する）：
「私の Claude Code に登録されている Skills の一覧を出してください。それぞれについて『Level 1 として常時ロードされている分（メタデータ）の概算トークン数』と『トリガーされた場合に追加で読み込まれる本文の概算トークン数』を表で示してください。」
| 観点 | 旧版（〜2026年3月の解説記事） | 新版（2026年4月以降の公式 docs ベース） |
|---|---|---|
| ロード戦略の説明 | 本文も常時ロードされる前提の解説が散見 | Level 1〜3 の段階的開示として公式 docs に明記 |
| YAML フィールドの仕様 | name／description の存在中心 | name 64文字・description 1024文字・予約語制約まで明文化 |
| 追加リソース構成 | SKILL.md 単体の説明が中心 | FORMS.md／REFERENCE.md／scripts/ など複数ファイル構成の例示 |
| pre-built Skills | 言及はあったが用途が不明確 | pptx／xlsx／docx／pdf の4種が公式に整備（API・claude.ai） |
| API 連携 | Claude Code 中心 | Claude API（skill_id 指定）／claude.ai／Claude Code の3面で利用可 |
| セキュリティ警告 | 言及は分散 | 「信頼できるソースのみ」のガイドラインが明文化 |
ここで一つ、地味に大事な公式仕様があります。公式 docs には「Pre-built Agent Skills are available to all users on claude.ai and via the Claude API」と書かれていて、pptx・xlsx・docx・pdf の4種類が用意されています。中小企業の現場で一番効くのが Excel・Word・PowerPoint・PDF の自動生成で、自前で Skill を作らなくても Anthropic 公式のものをそのまま呼び出せる設計なんですよね。最初の Skill を自作する前に、まず公式 pre-built を試してみるのが、肩の力が抜ける入り方だと感じます。
公式 docs の “Cross-surface availability” 項に「Custom Skills do not sync across surfaces」と明記されています。claude.ai にアップロードした Skill は API 側では使えず、Claude Code の Skill は claude.ai に出ません。同じ Skill を3面で使いたいときは、それぞれにアップロードが必要になる仕様です。
公式ドキュメントの “Sharing scope” 項には、「Claude.ai: Individual user only」「Claude API: Workspace-wide」「Claude Code: Personal (`~/.claude/skills/`) or project-based (`.claude/skills/`)」と、3面それぞれの共有範囲がはっきり分かれて書かれています。チームで Skill を共有したい場合は API 側の Workspace スコープを使う、個人運用は Claude Code の `~/.claude/skills/`、というのが公式の想定なんですよね。
具体的な使い道 — 公式 pre-built と業種別 Skills テンプレ
ここからが、地道ラボの読者からのリクエストが多かったパートです。「自分の業種だとどう使うか」のテンプレを、まず公式 pre-built Skills の用途、次に経理・営業・人事の3部門で1つずつ示します。全部一気に作る必要はなくて、自分の部門に近いテンプレからコピペして、その日のうちに動かす想定でまとめました。
| 公式 pre-built Skill | 主な用途（公式 docs 記載） | 提供面 |
|---|---|---|
| pptx | Create presentations, edit slides, analyze presentation content | API・claude.ai |
| xlsx | Create spreadsheets, analyze data, generate reports with charts | API・claude.ai |
| docx | Create documents, edit content, format text | API・claude.ai |
| Generate formatted PDF documents and reports | API・claude.ai |
各業種別テンプレは、`.claude/skills/
指示文例（経理：請求書文面チェック Skill を作らせる）：
「`.claude/skills/invoice-check/SKILL.md` を作成してください。フロントマターは name: invoice-check、description: ‘請求書の文面を経理担当者向けにチェックする。請求書・インボイス・消費税区分・支払いサイトの話題で発動’。本文には『①敬称・宛名表記の揺れ、②消費税区分（10%／軽減8%／不課税／非課税）の整合性、③支払いサイト（締め日・支払日）の明記、④振込先・押印欄の漏れ』の4観点でチェックする手順を書いてください。最後に確認チェックリストを表で出す指示も含めてください。」
指示文例（営業：商談議事録 Skill を作らせる）：
「`.claude/skills/sales-minutes/SKILL.md` を作成してください。description は ‘商談議事録を4項目に整形する。営業会議・商談議事録・打ち合わせメモの話題で発動’。本文には『①決定事項、②宿題（誰が・何を・いつまでに）、③論点（合意できなかった点）、④次回アクション』の4項目に整形する手順を書いてください。BANT（Budget／Authority／Need／Timing）の観点で営業所感を末尾に1段落追加する指示も含めてください。」
指示文例（人事：求人原稿 Skill を作らせる）：
「`.claude/skills/jd-writer/SKILL.md` を作成してください。description は ‘求人原稿（JD）のドラフトを作成する。求人票・JD・採用ペルソナ・スカウト文の話題で発動’。本文には『①職務概要（150字）、②具体業務（5〜7項目）、③必須要件・歓迎要件、④働き方（リモート可否・コアタイム）、⑤キャリアパス』の5ブロック構成で作成する手順を書いてください。差別表現（年齢・性別・国籍・家族構成・容姿）が混入していないかの自己チェックも末尾に含めてください。」
| 業種 | Skill 名（推奨） | 主な業務 | 適用シーン |
|---|---|---|---|
| 経理 | invoice-check | 請求書文面・消費税区分・支払いサイトのチェック | 月末の請求書発行時 |
| 経理 | monthly-comment | 月次集計レポートのコメント文ドラフト | 月次決算後 |
| 営業 | sales-minutes | 商談議事録の4項目整形＋BANT 所感 | 商談直後 |
| 営業 | competitor-watch | 競合のリリース・価格改定の定点観測 | 月次レビュー |
| 人事 | jd-writer | 求人原稿（JD）の5ブロック構成ドラフト | 新規求人起案時 |
| 人事 | review-comment | 評価面談コメントのトーン調整・差別表現チェック | 評価面談前 |
公式 skills リポジトリ（github.com/anthropics/skills）には、Anthropic が公開している open-source Skills のサンプルが置かれています。公式 docs には 「Claude API: Provides Claude with up-to-date API reference material, SDK documentation, and best practices for 8 programming languages.」という Claude API 用 Skill の記述があり、自分で書く前にここを読むと、SKILL.md の温度感が掴めるんですよね。自前で Skill を作る場合も、まず公式リポジトリの構成を一度眺めてから書き始めるのが、遠回りに見えて一番早い経路だと感じます。
業種別テンプレを作るときのコツは、「自社固有の前提（取引先名・取扱商材・採用基準）」を SKILL.md の冒頭に箇条書きで5〜10行入れること。これは公式 docs の best-practices にも書かれている「Skill ごとに onboarding guide を作る感覚」に対応しています。冒頭の前提条件で出力が「うちの会社らしさ」に寄ります。
人事 Skill の差別表現チェックは、「差別表現がないか確認して」とだけ書くと出力の粒度が粗くなりがちなパートです。「年齢」「性別」「国籍」「家族構成」「容姿」の5項目を明示する書き方にすると、チェック結果の抜け漏れが減る、というのは公式 docs の best-practices の「Be specific about what to check」の考え方に沿った設計なんですよね。
ステップバイステップ手順 — 5つのステップで Skills を立ち上げる
「いざ Skills を始めよう」となったときに、5ステップで何をやるかを順番に整理しました。全部一気にやろうとすると、SKILL.md を何本も書いたところで力尽きるんですよね。最初の30日は「1つだけ動かす」を目標にすると、ちょうどいい温度感で続けられます。
| ステップ | やること | 到達目標 | 所要時間目安 |
|---|---|---|---|
| ステップ1 | Skills の構造（YAML／トリガー／本文／追加リソース）を理解 | 公式 docs の Level 1〜3 の表を読める | 1時間 |
| ステップ2 | 1つ目の Skill を作る（指示文例＋YAML テンプレ） | 最初の SKILL.md を1本動かす | 2時間 |
| ステップ3 | 追加 Markdown（FORMS.md 等）や scripts/ を足して連携させる | Level 3 リソースの感触を掴む | 2時間 |
| ステップ4 | Skill ライブラリ全体の管理運用（命名規約・description 改善） | 3〜5本の Skill を月次で回す | 週1時間 |
| ステップ5 | 旧 Skill を 4月以降の docs ベースで見直し | Level 1〜3 観点で本文・description を再構成 | 本数次第 |
ステップ1：Skills の構造を理解する——公式 docs の Skill structure セクションと「Three types of Skill content, three levels of loading」を読み込みます。Level 1 がメタデータ・Level 2 が SKILL.md 本文・Level 3 が追加リソース、という3層を頭に入れるのがスタートライン。ここを飛ばして書き始めると、本文を肥大化させて Level 2 の 5,000トークン以下推奨を超えがちなんですよね。
ステップ2：1つ目の Skill を作る——`.claude/skills/
指示文例（最初の Skill 候補を Claude に選ばせる）：
「私は中小企業の○○部門の担当者です。毎週／毎月、同じような指示を Claude に貼っているのですが、最初に Skill 化すべき業務を3つ提案してください。判断基準は『①週1回以上発生する、②指示文の前提条件が固定、③出力形式が決まっている』の3点です。」
指示文例（既存の Skill を改善する）：
「以下は、3週間使ってみた SKILL.md の本文です。発動はしているのですが、出力のばらつきが大きいです。ばらつきの原因になりそうな箇所を3つ挙げて、それぞれに修正案を併記してください。」
ステップ3：追加 Markdown や scripts/ を足して連携させる——SKILL.md だけで完結しなくなったら、FORMS.md や REFERENCE.md に切り出します。Python スクリプトが必要なら scripts/ ディレクトリに置く。公式 docs には 「scripts provide deterministic operations without consuming context」と書かれていて、コードを Claude に毎回生成させずに、決まった処理は scripts/ に閉じ込めるのが推奨設計なんですよね。
ステップ4：Skill ライブラリ全体の管理運用——3〜5本に増えてきたら、命名規約と description のメンテに時間を回します。`name` は最大64文字・小文字英数とハイフン、予約語禁止という制約を踏まえた命名ルールを自分の中で決めておくと、後から見たときに迷わないんですよね。
ステップ5：旧 Skill を 4月以降の docs ベースで見直す——2026年3月以前に作った Skill は、Level 1〜3 の観点で本文・description を見直すのがおすすめです。SKILL.md 本文が肥大化しているなら、FORMS.md／REFERENCE.md に切り出して Level 3 に回す。description が曖昧なら、「何を／いつ使うか」を明示する形に書き直す。
公式 skills リポジトリ（github.com/anthropics/skills）には、Claude API の使い方を含む open-source Skills が公開されています。最初は「読んで参考にする」だけでも、自分で Skill を書くときの肌感が掴めると感じます。実装に踏み込む前の素振りに最適です。
指示文例（旧 Skill を 4月以降の docs ベースで見直す）：
「以下は、私が2026年3月に作った SKILL.md です。公式 docs の Level 1〜3 のロード戦略と best-practices に沿って、改善案を3点ずつ提示してください。本文を分割すべき箇所があれば、FORMS.md や REFERENCE.md として切り出す提案も含めてください。」
ここで一つ、踏み込んだ話をしておきます。Skills は「書いて終わり」ではなく「使いながら育てる」設計なんですよね。最初の SKILL.md は60点でいいので、3週間ほど実業務で使ってみて、出力のズレを直していく。この「育てる」プロセスを最初から想定して始めるのが、肩の力が抜けて続けられる入り方だと感じます。
5ステップ運用で得られる成果物・メリット — 「コピペが消えた先」に何が残るか
ステップバイステップ手順を一通り回したあと、現場担当者の手元に何が残るのかを最後に整理しておきます。手順を提示して終わりだと「やってみたけど何が良くなったのか分からない」という宙ぶらりんになりがちなので、公式 docs の記載に沿って成果物とメリットを5観点で言語化しました。
まず得られる成果物から。5ステップを回し終わると、`.claude/skills/
| Skill レベル | 得られる成果物 | 主なメリット |
|---|---|---|
| Level 1（メタデータ・約100トークン） | name と description のセット | 軽量に複数 Skill を待機可能・context 圧迫を回避 |
| Level 2（SKILL.md 本文・5,000トークン以下） | 業務手順・前提・出力形式を記述した Markdown | トリガー時のみ読み込み・指示の再現性が上がる |
| Level 3（追加リソース・実質無制限） | FORMS.md／REFERENCE.md／scripts/ などの補助ファイル | 大規模な参考資料・決定的な処理を Skill 内に閉じ込められる |
| Sub-skill 連携 | 複数 Skill を組み合わせた業務フロー | 「議事録 → 宿題抽出 → JD ドラフト」のような連鎖を段階的に構築可能 |
| pre-built（pptx／xlsx／docx／pdf） | Anthropic 公式提供の4種 Skill | 自作不要で Office 文書の自動生成が即日使える |
次に業務面のメリット。一番分かりやすいのは「同じ指示を毎回書かなくていい」という点で、これは Skills の目的そのものなんですよね。加えて、業務テンプレが Markdown ファイルとして残るため、Git で版管理できる副次効果がついてきます。「いつ・誰が・どの観点で description を変えたか」が履歴として追える状態は、属人化しがちな業務テンプレを「資産」に変える効果が期待できる、と感じます。
品質面のメリットは、チーム展開したときに効いてきます。全員が同じテンプレで運用するため、出力品質が均質化されること、個々人の改善が共有資産として蓄積されること、チェック観点を明示することで抜け漏れが減ること——この3点は、人事 Skill（jd-writer）の差別表現5項目チェックや、経理 Skill（invoice-check）の4観点チェックの設計が、そのまま品質ガードレールとして機能する効果が期待できる構造なんですよね。
Skills を運用してみると、「テンプレが Markdown として残る」ことの副次効果が想像以上に大きいと感じます。新しいメンバーが入ってきたときに、SKILL.md を渡すだけで「うちの会社の経理チェック観点」が伝わる状態になります。これは公式 docs の best-practices にある「Skill ごとに onboarding guide を作る感覚」とも重なる設計で、属人化していた業務知識が文書化される副産物が一番大きい、と感じる現場担当者は少なくないはずです。
拡張面のメリットとして、Skills は単独で使うだけでなく、Sub-skill で複雑な業務フローを段階的に構築できる点が公式 docs にも示されています。たとえば「商談議事録 Skill → 宿題抽出 Sub-skill → 提案書ドラフト Sub-skill」のように、業務の流れに沿った Skill 連鎖を作れる設計なんですよね。さらに pre-built Skills（pptx／xlsx／docx／pdf）と組み合わせれば、議事録から提案書 PowerPoint を生成する、といった一連のフロー全体を Skill 化できる効果が期待できます。公式 docs の “Cross-surface availability” 項に書かれている通り、claude.ai／Claude Code／API の3面で同じ思想の Skill を使い分けられる設計も、運用拡張の余地を残しています。
コスト面のメリットは、progressive disclosure の設計が直接効いてくる部分です。Level 1（約100トークン／Skill）で軽量に複数 Skill を待機させ、Level 2（5,000トークン以下）でトリガー時のみ詳細処理を呼び出す設計のため、Skill を10本以上ぶら下げても context への圧迫は限定的に抑えられる、という効果が期待できる構造なんですよね。公式 docs の 「Claude loads information in stages as needed, rather than consuming context upfront.」という記述は、まさにこのコスト最小化の思想を示しています。
「コピペが消える」だけでも十分な成果ですが、運用が3〜4週間続くと、副次効果のほうが本命に感じられてくる場面が出てきます。Markdown で版管理できる業務テンプレ、チーム展開時の品質均質化、Sub-skill での業務フロー全体テンプレ化、progressive disclosure による低コストでの複数 Skill 待機——この4つは、最初の SKILL.md を1本書いただけでは見えない景色ですが、5ステップを一周すると確実に手元に残る成果だと感じます。
ここで一つ、見落としがちな前提を補足します。Skills の効果は「使い始めた瞬間」ではなく「運用が定常化した3〜4週間後」に現れる設計なんですよね。最初の1本目は60点でいいので、ステップ4の「Skill ライブラリ全体の管理運用」まで辿り着く頃には、業務テンプレが資産として手元に残っている状態を目指す——という時間軸で運用すると、5つのメリットが立体的に立ち上がってきます。
旧版から差し替えた箇所と、変えなかった核
旧版を読んでくださっていた方向けに、何を変えて何を変えなかったかを明示しておきます。旧版（2026年4月初旬執筆）は、Skills の正式公開直後（2025年10月）の情報をベースに書いていたので、いま読み返すと公式 docs の更新で補足が必要な箇所がいくつかありました。
旧版で一番ズレていたのが「Skills 本文は常時ロードされる」前提の説明でした。公式 docs を読み込むと、実際には Level 1（メタデータ）だけが常時ロードで、本文は呼び出されたときに初めて読まれるという設計が明文化されています。この理解の差は、Skill を10本以上ぶら下げたときの設計に直結します。常時ロード前提だと「Skill を増やすほど context が圧迫される」と思って絞り込みがちですが、Level 1 メタデータが約100トークンで済むなら、複数本ぶら下げても context への影響は限定的に抑えられる、という見方に変わるんですよね。
| 項目 | 旧版（4月初旬） | 新版（4月以降の公式 docs ベース） |
|---|---|---|
| ロード理解 | 本文も常時ロードと誤認していた箇所あり | Level 1〜3 の段階的開示で正確に |
| Skill 本数の目安 | 「絞り込む」推奨 | メタデータが軽いなら複数本でも実用域 |
| 業種別テンプレ | 議事録・請求書・記事ワークフローの3例 | 経理2／営業2／人事2 の6例＋ステップバイステップ手順 |
| UIスクショ | 1枚 | 5枚（公式 docs／Level 表／管理画面ツリー／公式リポジトリ／API docs） |
| 図解 | なし | 1枚（Level 1〜3 の構造図／progressive disclosure ラベル） |
| pre-built 言及 | 用途が不明確 | pptx／xlsx／docx／pdf の4種を公式 docs 引用で明示 |
| セキュリティ | 軽く触れる | 「信頼できるソースのみ」の公式警告を引用で明示 |
指示文例（自分の Skill ライブラリ全体を整理する）：
「`.claude/skills/` 配下にある全 Skill のディレクトリ構成と SKILL.md の冒頭メタデータを一覧で出してください。description が曖昧で発動精度が低そうなものを3つ指摘して、それぞれに改善案を提示してください。」
指示文例（公式 pre-built を試す）：
「Anthropic 公式の pre-built Agent Skills（pptx／xlsx／docx／pdf）のうち、私の業務に一番効きそうな1つを選んでください。私の業務は『月次の請求書発行と、四半期の役員向けレポート作成』です。選んだ Skill を試すための最小の指示文例も併せて出してください。」
逆に、変えなかったのは「Skills の本質は同じ指示を覚えさせる仕組み」という結論。Skills の正式公開直後（2025年10月）から 2026年4月以降の docs 整理を経ても、Skill を作る目的（毎朝コピペを消す）は変わっていなくて、変わったのは「context window との付き合い方」と「pre-built の整備度合い」のほうなんですよね。
2026年4月以降に整理された公式 docs の Skills セクションは、2025年10月の正式公開時点よりも仕様が一段階明確になっています。一度試して挫折した方こそ、いま改めて公式 docs を読み直す価値がある内容です。
なお、Skills を信頼できないソースから入手する場合の注意も、公式 docs に明確に書かれています。「We strongly recommend using Skills only from trusted sources: those you created yourself or obtained from Anthropic.」——自作したもの、または Anthropic が提供しているもの以外の Skill を使う場合は、SKILL.md・スクリプト・画像など全ファイルの監査が前提という設計なんですよね。社内に Skill を配布するときの運用ルールにも直結する話です。
関連記事として、5月最新の Claude Code エンジニアリング動向をまとめたClaude Code 最新ニュース（C1）（2026年5月時点）と、講師業向けに Skills を「AI助手」として組み込む7パターンをまとめたClaudeを「AI助手」にする — 個人講師・オンライン家庭教師の7パターン（C2）、定期実行で Skills を起動するClaude Code Routines × Cron で定期実行するを併せて読むと、Skill を月次運用に組み込むイメージが具体になります。
明日のひとつから、自分専用の Skill を起動する
ここまで Skills の構造・これまでとの違い・業種別の使い道・5ステップの導入手順を見てきましたが、全部やる必要はないんです。自分の業種の指示文から、ひとつだけ選んで、その日のうちに `.claude/skills/
「ちょっと聞いてみたい」だけでもOK！ ツールや業務効率化についての相談をすべて1対1で丁寧にお答えします。 まずはお気軽にメッセージをどうぞ！LINE公式アカウントはこちら！
地道ラボでは、経理・営業・人事の3部門それぞれの Skills テンプレ集（SKILL.md のフルテキスト＋自社らしさを足すための前提条件テンプレ）をLINEで配布しています。コピペして `.claude/skills/
申し込みはLINEで「Skillsテンプレ」とメッセージを送るだけです。
大げさなコンサルティングではなく、明日から試せる具体的な一歩をお伝えするのが私たちのスタイルです。「Claude を業務に組み込む」という大きな目標を、自分の部門のひとつの Skill に落とすところから始めませんか。
次の一歩として、まずは「あなたの部門で、毎週／毎月コピペしている指示文を1つだけ」教えてください。その指示文に合わせた SKILL.md ドラフトと、最初の3週間の運用設計を、具体的に提案します。
コメント
コメント一覧 （3件）
[…] 詳細はClaude Code Skills完全ガイド（地道ラボ）をご参照ください。 […]
[…] たとえば、営業チームが毎週作成する「商談レポートの要約」や、バックオフィスが処理する「請求書の確認項目チェック」といった繰り返し作業をSkillとして定義しておけば、担当者が変わっても品質が安定します。Skillsの詳細な活用方法については、地道ラボ「Claude Code Skills完全ガイド」を参照してください。 […]
[…] Claude Code の Skills とは、繰り返し使う処理パターンをテンプレートとして保存し、再実行できるようにする仕組みです。詳細な活用方法は「Claude Code スキルガイド」をご参照ください。 […]