AIを使った業務自動化に興味はあるけれど、プログラミングはできないし、ワークフローツールも難しそう。
そんな方にこそ知ってほしいのがClaude Skillsです。
まつ「この指示何回もしているな」と思ったことはありませんか？
skillsを使うことで、1つのファイルに指示やルールを全てまとめておき、必要に応じてAIがskillsを参照して作業をしてくれるようになります。
うっかり社員構築の手間が少ない割に、skillsを使いまわせれば、すごく時間が浮きますね。
Skillsは自然言語で指示書を書くだけで始められるAI自動化の仕組みであり、Skillsを使いこなす力はあらゆるAI自動化の土台になります。
この記事では、Skillsの基本から、良いSkillを作る7つの原則、実践的な作成手順、さらにその先のステップまでを解説します。
Skillsとは？非エンジニアのためのAI自動化の入り口
Skillsとは、AIへの指示書をファイル化して何度でも再利用できる仕組みです。Claude.aiでは設定（Settings）の機能（Features）の中にSkillsの項目があり、ここからSkillの追加や管理ができます。
普段Claude.aiを使っているとき、WordやPDF、PowerPointの作成を依頼すると、Claudeが自動的に適切な手順でファイルを生成してくれることに気づいた方もいるかもしれません。実はこれも裏側でSkillsが動いています。Anthropicがあらかじめ用意したドキュメント作成用のSkillsをClaudeが自動的に読み込み、その指示に従ってファイルを生成しているのです。
Skillsの実体は、SKILL.mdという名前のMarkdownファイルです。このファイルの中に、Claudeへの指示内容を自然言語で記述します。プログラミング言語ではなく、日本語や英語で「こういうときはこうしてほしい」と書くだけです。Claudeはタスクに取り組む際に利用可能なSkillsの一覧を確認し、関連性が高いSkillがあれば自動的にその指示を読み込んで従います。
あなたの繰り返し作業をSkillsが肩代わりする
Skillsを使う最大のメリットは、Claudeに毎回同じ説明をする必要がなくなることです。一度Skillとして指示を保存すれば、以降は関連するタスクのたびにClaudeが自動的にその指示を読み込みます。
毎回同じ指示を打ち直す必要がなくなる
Claudeとの会話は基本的にセッションごとにリセットされます。そのため、前回の会話で伝えた前提条件や出力フォーマットの指定は、新しい会話では引き継がれません。Skillsはこの問題を根本的に解決します。一度作成したSkillは会話をまたいで永続的に利用でき、毎回のコピペや前提条件の再説明が不要になります。
あなただけの専門アシスタントを作れる
Skillsを使えば、自分の業務ルール、会社の用語、好みの出力形式に特化したClaudeを構築できます。たとえば、自社のブランドガイドラインをSkillにまとめておけば、資料を作るたびにClaudeが自動的にそのガイドラインに従います。汎用的なAIを、自分の業務に最適化された専門アシスタントに変えられるのがSkillsの本質です。
作ったSkillは共有・再利用できる
作成したSkillはファイルとしてエクスポートでき、チームメンバーに共有できます。つまり、自分が試行錯誤して作り上げた業務ノウハウを、そのままAIの能力としてチーム全体に展開できます。新しいメンバーが入ってきたときも、Skillを渡すだけでClaudeが同じ品質で業務をサポートしてくれます。
こんな場面ではSkillsを作った方がいい
Skillsはあらゆる場面で役立つわけではありません。Skillを作るべきかどうかの判断基準は、その作業に繰り返しのパターンがあるかどうかです。
同じ指示を何度もコピペしている
Claudeに毎回同じプロンプトを貼り付けているなら、それはSkill化の最も明確なサインです。たとえば、毎回「箇条書きではなく文章で書いて」「ですます調で統一して」「結論を最初に書いて」といった指示を繰り返しているなら、それをSkillにまとめましょう。
出力のフォーマットや品質にばらつきがある
Claudeの出力が毎回微妙に異なり、手作業で修正する手間が発生しているなら、出力形式をSkillで固定することで解決できます。たとえば報告書のテンプレート、メールの構成パターン、データ分析の出力フォーマットなどをSkillに定義しておけば、一貫した品質の出力が得られます。
社内の独自ルール・用語を毎回Claudeに教えている
Claudeは一般的な知識は豊富ですが、あなたの会社の固有名詞、業界特有の用語、社内独自の業務フローは知りません。これらを毎回説明し直しているなら、Skillにまとめておくことで大幅に効率化できます。ブランドガイドライン、専門用語集、承認フローの手順書など、Claudeが本来知り得ない情報こそSkillに書くべき内容です。
まつ余談ですが、ChatGPTのGPTsや、AntigravityのSkillsも似たような仕組みで動作します。別のツールを使う際もSkills作成で培った経験を横展開できます。
Skillsを極める人はAI自動化を極める
AI自動化にはさまざまなアプローチがありますが、Skillsはその最も合理的な出発点です。理由は3つあります。
- 学習コストが最も低い（Markdownで指示を書くだけ）
- リスクの性質が理解しやすい（テキスト指示のみなら外部接続が発生しない）
- プロンプト設計力という、すべてのAI自動化に通じる中核能力が身につく
この3つの理由を、AI自動化の全体像の中でSkillsがどこに位置するかを踏まえて解説します。
AI自動化の3段階とSkillsの位置づけ
AI自動化は、大きく3つの段階に分けて考えることができます。それぞれの段階で求められる知識やリスクの性質が異なり、Skillsは最初の段階に位置します。
第1段階：Skills（プロンプトのファイル化）←今ここ
Skillsは、自然言語の指示書をMarkdownファイルに書くだけで始められる自動化です。プログラミング知識は不要で、外部サービスとの連携も必要ありません。Claude.aiの設定画面からSkillの名前、説明文、指示内容の3つを入力するだけで作成できます。必要なのはClaudeにわかりやすく伝える文章を書く力だけです。
第2段階：ワークフロー自動化（n8nなど）
n8nやMake、Zapierなどのワークフロー自動化ツールでは、複数のサービスをノードで接続し、データの流れを設計します。たとえば「メールを受信したら→内容をAIで要約して→Slackに投稿する」といった自動化を、ノードをつなげて構築します。この段階ではAPI認証、データ変換、エラーハンドリングなど、プログラミング的な思考が必要になります。
第3段階：エージェンティックAI（Claude Code、Agent SDKなど）
エージェンティックAIでは、AIが自律的にツールを選び、計画を立て、実行します。Claude Codeではターミナル上でClaudeがコードを書き、テストを実行し、ファイルを操作します。Agent SDKを使えば、複数のエージェントが連携して複雑なタスクをこなすシステムも構築できます。最も自由度が高い反面、設計・監視の難易度も最も高い段階です。
なぜSkillsが最適な出発点なのか
3つの段階を比較すると、Skillsが自動化の出発点として最適である理由が明確になります。
学習コストが低い
Skillsに必要なのはMarkdownで指示を書く力だけです。Markdownは見出しに#、箇条書きに-を使うだけのシンプルな記法で、HTMLのような複雑なタグは不要です。一方、ワークフローツールではAPI連携やデータマッピングの概念を理解する必要があり、エージェンティックAIではさらにプログラミングの基礎知識が求められます。
リスクの性質が理解しやすい
Skillsの基本形はテキストの指示書であり、スクリプトを含めなければ外部への接続やファイルシステムの操作は発生しません。
一方で、Skillsにスクリプトを含めた場合はリスクの範囲が広がる点には注意が必要です。Anthropicの公式ドキュメントでも、Skillsにコードが含まれる場合はツールの悪用やデータ流出のリスクがあることが明記されており、信頼できるソースからのSkillのみを使用するよう警告しています。
ただし、ワークフローツールやエージェンティックAIと比較すると、テキスト指示のみで構成したSkillsのリスク範囲は限定的です。ワークフローツールはAPI経由で外部サービスと常時接続し、エージェンティックAIはファイルシステムやターミナルへの広範なアクセス権を持ちます。
プロンプト設計力がすべての段階の共通基盤になる
ここが最も重要なポイントです。ワークフローツールでもエージェンティックAIでも、AIに何をさせるかは最終的にプロンプトで指定します。
n8nのAIエージェントノードにはシステムプロンプトを設定する欄があり、ここに指示を書いてAIの振る舞いを制御します。実際にn8nのテンプレートには、GitHubリポジトリからSKILL.mdファイルを取得し、それをAIエージェントのシステムプロンプトに注入するワークフローも公開されています。
つまり、Skillsで磨くプロンプト設計力は、ワークフローツールやエージェンティックAIに進んだときにもそのまま活きます。指示の構造化、自由度の設計、理由の説明といったスキルは、Skillsに固有のものではなく、AI自動化全般に通じる根幹の能力です。
良いSkillを作る7つの原則
良いSkillと悪いSkillの差は歴然です。Anthropicの公式ベストプラクティスと公式skill-creatorを分析すると、優れたSkillに共通する原則が浮かび上がります。ここではそのエッセンスを設計思想、指示の書き方、発見される仕組み、品質の担保という4つの軸に整理して解説します。
設計思想：Skillをどう設計するか
Skillの品質は、指示の文面を書き始める前の設計段階で大部分が決まります。ここでは、Skillの構造そのものに関わる2つの原則を解説します。
原則1：段階的開示：コンテキストウィンドウは公共財
Claudeが一度に処理できる情報量（コンテキストウィンドウ）には上限があります。この限られた容量を、Skill、会話履歴、他のSkillのメタデータ、ユーザーのリクエストすべてで共有しています。
この制約に対応するために、Skillsは3層の段階的開示という仕組みで設計されています。第1層はメタデータ（nameとdescription）で、これはClaude起動時に常に読み込まれます。第2層はSKILL.mdの本文で、Skillが実際に使われるときだけ読み込まれます。第3層はreferencesやscriptsといった外部ファイルで、必要になった時点でClaudeがファイルシステムから読み取ります。
この設計を意識すると、Skillの書き方が変わります。SKILL.mdの本文には概要と「どのファイルに何が書いてあるか」の案内を書き、詳細な手順書やテンプレートは別ファイルに分離します。
実務的なディレクトリ構成の例を示します。
my-skill/
├── SKILL.md （メインの指示書）
├── reference.md （詳細な参照情報。必要時だけ読み込まれる）
└── scripts/
└── validate.py （実行スクリプト。実行結果だけがClaudeに渡される）
重要なのは、参照ファイルはSKILL.mdから直接リンクする1階層までに留めることです。reference.mdの中からさらに別のファイルを参照する入れ子構造にすると、Claudeがファイルを部分的にしか読まなくなるリスクがあります。
原則2：自由度を設計する：狭い橋か、開けた野原か
Claudeへの指示には「どこまで具体的に縛るか」という自由度の設計が必要です。公式ドキュメントでは、わかりやすい比喩が使われています。
崖に挟まれた狭い橋を想像してください。一歩でも踏み外せば落ちてしまう場所では、正確な手順を一つずつ指定する必要があります。これが低自由度の指示です。たとえばデータベースの更新手順のように、手順を間違えるとデータが壊れる作業には、具体的なスクリプトやコマンドを記述します。
一方、開けた野原を想像してください。どの方向に進んでも目的地に着ける場所では、方向性だけ示してClaudeの判断に任せる方がうまくいきます。これが高自由度の指示です。たとえばコードレビューや文章の校正のように、状況に応じた判断が求められる作業では、チェック観点だけを示して具体的な対応はClaudeに委ねます。
非エンジニアの方が陥りがちなのは、すべてをガチガチに指定してしまうパターンです。Claudeは文脈を理解できるAIです。縛りすぎると、想定外の入力が来たときに柔軟に対応できなくなります。
自由度の設計に迷ったら、「この作業で手順を間違えたら取り返しのつかない問題が起きるか」を基準にしてください。取り返しがつかないなら低自由度、そうでなければ高自由度が適切です。
指示の書き方：Claudeにどう伝えるか
Skillの構造を決めたら、次は指示の中身を書く段階です。ここでは、Claudeに最も効果的に伝わる書き方の原則を2つ解説します。
原則3：WHYを書け、MUSTを書くな
公式skill-creatorの指示の書き方に関する核心は明確です。重厚なMUSTの羅列ではなく、なぜそれが重要なのかの理由を書くことが推奨されています。
たとえば、議事録Skillを書くとします。悪い例と良い例を比べてみましょう。
悪い例（MUSTの羅列）
MUST: 発言者名を必ず記載すること
MUST: 決定事項は箇条書きにすること
MUST: 未決事項は別セクションに分けること
ALWAYS: 日付をヘッダーに入れること
NEVER: 個人の感想は記載しないこと
良い例（WHYの説明）
議事録の目的は、参加していなかった人が会議の結論と次のアクションを
5分で把握できることです。
そのために以下の点を重視してください
- 発言者名を記載する（誰が何を言ったかがわかると、後から確認や
質問がしやすくなるため）
- 決定事項と未決事項を明確に分ける（読み手が「結局何が決まったのか」
を一目で判断できるようにするため）
- 個人の感想や主観的な評価は省く（事実と決定だけを記録することで、
参照資料としての信頼性を保つため）
今のLLMは非常に賢く、理由を理解すれば想定外の状況でも適切に判断できます。MUSTの丸暗記を強いると、ルールに書かれていない状況に遭遇したときに適切な判断ができません。理由を理解しているClaudeは、新しい状況でもその理由に基づいて正しく行動できます。
skill-creatorの原文では、ALWAYSやNEVERを大文字で書きたくなったらそれは黄色信号だと表現されています。ルールを強制する代わりに、なぜそうすべきかを説明し直すことで、より強力で柔軟な指示になります。
原則4：Claudeが知らないことだけ書く
公式ベストプラクティスの冒頭に明確に記されている原則があります。Claudeは既に非常に賢いので、Claudeがまだ持っていない情報だけを追加するという考え方です。
まつ自分の作業特有のルールがまさにこれ。
どういう手順で、どういうアウトプットが欲しくて、何をしてはいけないのか、というのは、職場や作業内容によって異なります。
このルールを記入することで、個別最適化されたアウトプットを安定的に得られます。
具体的には、すべての記述に対して「Claudeは本当にこの説明が必要か」「Claudeが既に知っている内容ではないか」「この段落はコンテキストウィンドウを消費する価値があるか」と問い直すことが推奨されています。
公式ドキュメントに掲載されている比較例を紹介します。
簡潔な例（約50トークン）
## PDFからテキストを抽出する
pdfplumberを使ってテキストを抽出します
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
冗長な例（約150トークン）
## PDFからテキストを抽出する
PDF（Portable Document Format）は、テキスト、画像、その他の
コンテンツを含む一般的なファイル形式です。PDFからテキストを
抽出するには、ライブラリを使用する必要があります。PDF処理用の
ライブラリは多数ありますが、pdfplumberが推奨されます。
なぜなら使いやすく、ほとんどのケースに対応できるからです。
まずpipを使ってインストールし、次に以下のコードを使用してください…
簡潔な例は、ClaudeがPDFの概念やライブラリの仕組みを既に知っていることを前提にしています。Skillに書くべきは、Claudeが判断できない情報だけです。
この原則は非エンジニアの方にも直接当てはまります。Claudeに「ビジネスメールとは何か」を説明する必要はありません。書くべきは「うちの会社では件名に案件番号を入れるルールがある」「社外メールでは必ず部署名を署名に入れる」といった、あなたの組織固有の情報です。
発見される仕組み：Claudeにいつ使わせるか
Skillをどれだけ丁寧に書いても、Claudeがそのスキルを使ってくれなければ意味がありません。ここでは、Claudeにスキルを確実に発動させるための原則を解説します。
原則5：descriptionがすべてを決める
SkillのYAMLフロントマターに書くdescriptionフィールドは、Skillの発動条件そのものです。Claudeは起動時にすべてのSkillのnameとdescriptionを読み込み、ユーザーの依頼内容と照合してどのSkillを使うかを判断します。SKILL.md本文は、descriptionによってSkillが選ばれた後に初めて読み込まれます。
つまり、descriptionが曖昧だと、どれだけ優れた指示を本文に書いていてもClaudeはそのSkillを使ってくれません。descriptionには「何をするか」と「いつ使うべきか」の両方を明記する必要があります。
悪い例
description: ドキュメントを手伝います
良い例
description: PDFファイルからテキストや表を抽出し、フォームに記入し、
ドキュメントを結合します。PDFファイルを扱う場合や、ユーザーがPDF、
フォーム、ドキュメント抽出に言及した場合に使用します。
さらに重要な点があります。Claudeにはスキルを使わない方向に偏る傾向があります。公式skill-creatorでも「descriptionは少し押し気味に書くこと」が明確に推奨されています。たとえば「ダッシュボードを作成する」だけでなく「ユーザーがダッシュボード、データ可視化、社内指標に言及した場合や、何らかのデータを表示したい場合に、明示的にダッシュボードと言っていなくても使用すること」まで書く方が、Skillの発動率が上がります。
品質の担保：どう良くしていくか
Skillは一度書いて終わりではありません。実際に使いながら改善を重ねることで、はじめて実用的な品質に到達します。ここでは、Skillを継続的に良くしていくための2つの原則を解説します。
原則6：一般化せよ、特定の例を過学習するな
Skillを改善するとき、テストで使った特定の入力パターンにだけ最適化してしまう罠があります。公式skill-creatorにはこの点について重要な指摘があります。Skillは何百万回も多様なプロンプトに対して使われる可能性がある一方で、テスト時には数個の例しか見ていない。その数個の例にだけ効く細かい修正を入れるのではなく、より一般的に通用するアプローチを探すべきだ、という考え方です。
たとえば、メール返信Skillをテストして「お客様への謝罪メールの返信」がうまくいかなかったとします。このとき「謝罪メールの場合は必ず冒頭にお詫びの言葉を入れる」という狭い修正を加えるのではなく、「メールの文脈（感謝、謝罪、依頼、報告など）を読み取り、それに応じたトーンで返信する」という一般的な指示に書き換える方が、幅広い状況に対応できます。
skill-creatorでは、さらにこう述べられています。しつこい問題がある場合、細かい修正を追加するよりも、別のアプローチや比喩で書き直してみる方がうまくいくことがある。試行コストは比較的低いし、もしかしたら素晴らしい結果が得られるかもしれない、と。
「この指示は、自分がテストした3パターン以外でも正しく機能するか」と常に自問することが、過学習を防ぐ最もシンプルな方法です。
原則7：フィードバックループを組み込む
優れたSkillは、実行して終わりではなく、実行結果を検証し、問題があれば修正するサイクルを指示の中に組み込んでいます。
具体的には、Skillの指示を「作業を行う→結果を検証する→問題があれば修正→再度検証する→問題がなければ完了」というサイクルで構成します。
たとえば、報告書作成Skillであれば「本文を作成する→チェックリストに沿って確認する（用語の統一性、必須セクションの有無、フォーマットの準拠）→問題が見つかれば修正する→再度チェックリストで確認する→すべてクリアしたら完成」という流れを指示に明記します。
まつ私もよく使うskillsは何度かアップデートしています。
「この指示何回もしているな」「これはやって欲しくないよな」など、使っているうちに課題が明らかになります。そのタイミングで修正をするようにすると、細かい修正なしのアウトプットを得られるようになります。
フィードバックループが重要なのは、Claudeが最初の出力で常に完璧な結果を出すとは限らないからです。検証と修正のサイクルを指示に組み込むことで、最終的な出力品質を大幅に引き上げることができます。
Skill自体の改善サイクルも同様です。公式ベストプラクティスでは、Claude Aという一つの会話でSkillを作成・改善し、Claude Bという別の会話でそのSkillを実際のタスクに使い、Claude Bの挙動を観察してClaude Aにフィードバックするという開発手法が推奨されています。この「作る→使う→観察する→改善する」のサイクルを回すことで、Skillは実用的な品質に到達します。
観察すべきポイントとしては、Claudeがファイルを想定と異なる順序で読んでいないか、重要な参照ファイルを見落としていないか、同じファイルを何度も繰り返し読んでいないかといった点が挙げられます。こうした実際の挙動を根拠にして改善することが、想像に基づいた改善よりもはるかに効果的です。
はじめてのSkillを作ってみよう（実践ガイド）
7つの原則を理解したら、実際にSkillを1つ作ってみましょう。Claude.aiではSkillを作る方法が3つあります。それぞれの方法を紹介した上で、身近な例で実際のSkillの中身を見ていきます。
Skillを作る3つの方法
Claude.aiでSkillを作る方法は3つあり、それぞれ適した場面が異なります。初めて作る場合は方法1か方法3から始めるのがおすすめです。
方法1：会話の中でClaudeにSkillを作ってもらう
最もシンプルな方法は、Claudeとの会話の中で「この作業をSkillにして」と依頼することです。たとえば、Claudeと一緒にメールの返信文を何度か作成した後に「今やった作業をSkillにまとめて」と伝えれば、ClaudeがSKILL.mdファイルを生成してくれます。
生成されたファイルをダウンロードし、zipに圧縮した上でClaude.aiの設定（Settings）→ 機能（Features）→ Skills → Add → Upload a skillからアップロードすれば、以降の会話で自動的に使えるようになります。
この方法の利点は、実際に行った作業の文脈をClaudeが理解した上でSkillを生成してくれる点です。自分で一から構造を考える必要がありません。
まつ「今やった作業をSkillにまとめて」と伝えて作る場合は、個別具体的なSkillsになるので、同様の作業を全てカバーするよう適度に一般化することが大事。
方法2：設定画面から手動で作成する
Claude.aiの設定（Settings）→ 機能（Features）→ Skills → Add → Write skill instructionsから、直接Skillを作成することもできます。入力する項目は3つです。
- Skill name（スキル名）です。スキルの識別名を英数字とハイフンで入力
- Description（説明文）です。原則5で解説したように、何をするかといつ使うべきかを具体的に記述
- Instructions（指示内容）です。Claudeに従ってほしい手順やルールを自然言語で記述
この方法は、自分が何をSkillにしたいか既に明確にわかっている場合に向いています。他の人が共有したSkillの指示をそのままコピーして使う場合にも便利です。
方法3：公式skill-creatorを使う（対話形式）
Anthropicが作成した公式のskill-creatorは、Skillを作るためのSkillです。Claude.aiにプリインストールされているため、追加のインストールは不要です。このSkillを使うと、Claudeが対話形式でヒアリングしながらSkillを構築してくれます。
skill-creatorを使うと、Claudeは「このSkillで何ができるようにしたいですか」「どういうときに発動してほしいですか」「出力形式はどうしますか」といった質問を投げかけてきます。これに答えていくだけで、適切な構造のSKILL.mdが出来上がります。
skill-creatorの大きな利点は、原則1の段階的開示や原則5のdescription設計といったベストプラクティスが組み込まれている点です。自分で構造を設計する必要がなく、対話に答えるだけでベストプラクティスに沿ったSkillが完成します。
身近な例で作ってみる
実際のSkillがどのような構造になっているか、身近な例で見てみましょう。
例：メール返信Skill
社外向けビジネスメールの返信を支援するSkillの例を示します。7つの原則がどのように反映されているかも確認してください。
---
name: business-email-reply
description: 社外向けビジネスメールの返信を作成します。
メールの返信、ビジネスメール、お礼メール、お詫びメール、
依頼メール、報告メールなどに言及した場合に使用します。
メール文面の作成やレビューを求められた場合にも使用してください。
---
# 社外向けビジネスメール返信
## 目的
受信したメールの内容と文脈を読み取り、適切なトーンと構成で
返信文を作成する。
## 返信作成の考え方
相手のメールのトーン（感謝、不満、依頼、報告など）を読み取り、
それに応じた返信を組み立てる。相手が急いでいるなら簡潔に、
丁寧な文面なら同等の丁寧さで返す。
返信で最も重要なのは、相手の問いかけや依頼に対する回答を
明確に含めることである。回答が曖昧なまま「ご検討ください」で
終わるメールは、やり取りを無駄に増やしてしまうため。
## 構成
1. 冒頭の挨拶（相手のメール内容への言及を含める）
2. 本題（相手の問いかけへの回答、または伝えたい内容）
3. 次のアクション（誰が何をいつまでにするか）
4. 締めの挨拶
## 当社ルール
- 署名には必ず部署名と内線番号を含める
- 件名は「Re:」を残し、変更しない
- 社外メールでは「お世話になっております」から始める
このSkillの中に7つの原則がどう反映されているかを確認します。descriptionには何をするかといつ使うかが具体的に書かれています（原則5）。返信の考え方はなぜそうするかの理由で説明されており、MUSTの羅列にはなっていません（原則3）。ビジネスメールの一般的なマナーについての説明はなく、Claudeが知らない当社固有のルールだけが記載されています（原則4）。構成の指定は方向性を示す程度で、具体的な文言までは縛っていません（原則2）。
例：週次報告Skill
もう一つ、定期業務の例を見てみましょう。フィードバックループの組み込み方にも注目してください。
---
name: weekly-report
description: 週次業務報告書を作成します。週報、週次報告、
進捗報告、業務報告の作成や下書きを求められた場合に
使用します。毎週の振り返りやチーム共有資料の作成にも
使用してください。
---
# 週次業務報告
## 目的
今週の成果と来週の予定を、上長やチームメンバーが3分で
把握できる報告書にまとめる。
## レポート構成
### 今週の成果
- 完了したタスクを重要度順に記載
- 各タスクには「何を」「どうなったか」を1〜2文で添える
- 数値で測れる成果があれば含める（売上、件数、完了率など）
### 課題・懸念事項
- 未解決の問題を記載
- 各課題に対する現在の対応状況または方針案を添える
（課題だけ列挙して対応案がない報告は、読み手に
不安を与えるだけで建設的でないため）
### 来週の予定
- 予定しているタスクを優先度順に記載
- 他メンバーの協力が必要なタスクは明示する
## 作成後の確認
レポートを作成したら、以下を確認して必要に応じて修正する
- 各セクションに具体性があるか（「いろいろ対応した」で
終わっていないか）
- 課題に対する方針案が書かれているか
- 来週の予定が具体的なタスクレベルで書かれているか
問題があれば修正し、再度確認する。
このSkillでは、末尾の「作成後の確認」セクションがフィードバックループ（原則7）にあたります。Claudeに「作って終わり」ではなく「作った後に自分で確認して修正する」ところまで指示しています。
作ったSkillを試す・改善する
Skillを作成したら、実際にいくつかのタスクで使ってみてください。そのとき、以下のような問題が起きていないかを確認します。
Skillが発動しない場合は、descriptionの記述が曖昧である可能性が高いです。原則5に立ち返り、具体的なキーワードや使用シーンを追記してください。
出力がイマイチな場合は、指示が冗長すぎる（原則4に違反）か、縛りすぎている（原則2に違反）可能性があります。Claudeが既に知っている情報を削除し、自由度のバランスを見直してください。
特定のケースでしかうまくいかない場合は、原則6の過学習が起きています。指示をより一般的な表現に書き換えてください。
改善は一度に大きく変えるのではなく、1つの変更を加えるたびにテストするのが効果的です。何が効いて何が効かなかったかを把握しやすくなります。
公式Skillsリポジトリを活用する
自分でゼロからSkillsを作らなくても、AnthropicがGitHubで公式のSkill集を公開しています。ここには、ドキュメント処理やコーディング支援、データ分析など、高品質なSkillsが多数格納されています。
このリポジトリは宝の山です。以下の2つの使い方がありえます
そのまま使う・改良する
使いたいSkillのフォルダにある SKILL.md をダウンロードし、自分のClaudeにアップロードするだけですぐに利用できます。また、それを土台にして「自分専用のルール」を書き足せば、短時間で高機能なSkillが手に入ります。
プロの書き方を盗む
ここにある SKILL.md は、Anthropicのエンジニアが作成したお手本です。どのように指示を構造化しているか、どのような言い回しでClaudeを制御しているか。その中身を読むことは、解説記事を読む以上に実践的な勉強になります。
Skillsの次へ：Claude Codeとワークフロー自動化への発展
Skillsで身につけたプロンプト設計力は、より高度なAI自動化に進む際の確かな基盤になります。ここでは、Claude.aiの次のステップとなるClaude Codeとワークフロー自動化への発展を紹介します。
Claude CodeでSkillsを活用する
Claude CodeはAnthropicが提供するターミナルベースのAIツールで、ファイルの操作、コードの実行、テストの自動化など、Claude.aiではできない高度な作業を行えます。SkillsはClaude Codeでも同じ仕組みで動作しますが、いくつかの追加機能が利用できます。
ファイルシステムベースのSkill管理
Claude Codeでは、プロジェクトフォルダ内の.claude/skills/ディレクトリにSkillのフォルダを置くだけで自動的に認識されます。Claude.aiのように設定画面からアップロードする手順が不要で、テキストエディタで直接SKILL.mdを編集して即座に反映させることができます。
さらに、プロジェクト単位でSkillを管理できるため、プロジェクトごとに異なるSkillセットを使い分けることが自然にできます。Gitでバージョン管理すれば、チーム全員が同じSkillを共有することも容易です。
Claude Codeだからできること
Claude CodeのSkillsには、Claude.aiにはない機能がいくつかあります。スラッシュコマンドとしてSkillを呼び出す機能、サブエージェントを使った並列実行、実行コンテキストの分離（context: fork）などです。
たとえば、コードレビューSkillを作成してcontext: forkを設定すれば、レビュー作業が独立したサブエージェントで実行され、メインの会話には影響を与えません。また、allowed-toolsフィールドでSkillが使えるツールを制限することで、安全性を高めることもできます。
非エンジニアの方がいきなりClaude Codeを使うのはハードルが高いかもしれませんが、Claude.aiでSkillsの仕組みに慣れた後であれば、Claude Codeへの移行は格段にスムーズです。Skillの構造（SKILL.md、frontmatter、本文の指示）はまったく同じであり、Claude.aiで作ったSkillをそのままClaude Codeに持ち込むこともできます。
ワークフロー自動化への接続
SkillsはClaude製品の枠を超えて、ワークフロー自動化ツールとも接続できるポテンシャルを持っています。
ワークフローツールとSkillsの関係
n8nのようなワークフロー自動化ツールでは、AIエージェントノードにシステムプロンプトを設定してAIの振る舞いを制御します。このシステムプロンプトに、SKILL.mdの内容を読み込ませることで、ワークフローの中でSkillsのノウハウを活用できます。
実際にn8nのコミュニティでは、GitHubリポジトリからSkillsのディレクトリ一覧を取得し、ユーザーのリクエストに応じて適切なSkillの内容をAIエージェントのプロンプトに注入するテンプレートが公開されています。
Skillsで身につけたプロンプト設計力は資産になる
この記事で解説した7つの原則は、Skills固有のテクニックではありません。段階的開示はコンテキストウィンドウを持つあらゆるLLMに通じる設計思想であり、自由度の設計はどんなAIへの指示にも必要な判断です。
WHYで伝える技術、必要な情報だけを書く原則、フィードバックループの組み込みは、n8nのAIエージェント設定でも、Claude CodeのCLAUDE.mdファイルでも、OpenAIのカスタムGPTでも、同じように威力を発揮します。
だからこそ、AI自動化を極めたいなら、まずSkillsから始めるのが最も合理的な選択です。Skillsは最もシンプルな環境で、最も汎用的な能力を磨ける場所です。ここで身につけた力は、どのツールに進んでも、どの段階に到達しても、あなたのAI活用の中核であり続けます。
まとめ
Claude Skillsは、AIへの指示書をファイル化して繰り返し使える仕組みであり、プログラミング不要で始められるAI自動化の入り口です。
良いSkillを作るには、コンテキストウィンドウを意識した段階的開示、適切な自由度の設計、MUSTではなくWHYで伝える書き方、Claudeが知らない情報だけを書く簡潔さ、具体的なdescriptionによる発動設計、テストパターンへの過学習の回避、そしてフィードバックループの組み込みという7つの原則が鍵になります。
Skillsで身につくプロンプト設計力は、ワークフロー自動化やエージェンティックAIなど、あらゆるAI自動化の段階で通用する中核能力です。まずは1つ、自分の繰り返し作業をSkillにしてみてください。
