最近、ClaudeでExcelファイルを作成すると、以前より格段に品質が上がっていると感じませんか？
実はこれ、Anthropic公式の「Skills」が裏側で自動的に発動しているからなんです。
ClaudeのSkills（Agent Skills）は2025年10月に登場し、12月にはオープンスタンダードとして公開されました。公式ドキュメントによると、Excel、Word、PowerPoint、PDFなどのドキュメント作成機能の強化は「Anthropic Skills」として提供されており、関連するタスクを依頼すると自動的に呼び出されます。
つまり、私たちは知らないうちにSkillsの恩恵を受けているわけです。
では、自分でカスタムSkillsを作るべきケースはどんなときか？今回は、私がClaudeとの対話の中でSkillsについて深掘りした結果、「これはSkillsにした」「これはSkillsにしなかった」という判断と、その理由を共有します。
Skillsとは何か
簡単に言うと、Claudeに「専門的な手順書」を渡せる機能です。
公式ドキュメントによると、Skillsは「一度うまくいったやり方をパッケージ化し、コンテキストが合えばClaudeが自動的に適用する」仕組みです。毎回同じ説明を繰り返す必要がなくなります。
Skillsの種類
Anthropic Skills（公式提供）
- Excel、Word、PowerPoint、PDFのドキュメント作成機能
- すべてのユーザーが利用可能
- 関連タスクで自動的に発動
Custom Skills（カスタムスキル）
- 自分で作成する専門的なワークフロー
- Pro/Max/Team/Enterpriseプランで利用可能
ポイント
- 必要なときだけ読み込まれる（コンテキストを節約）
- 定型的な処理を安定して実行できる
- 自分でカスタムスキルを作成できる
- オープンスタンダードで他のAIツールでも使える
オープンスタンダード化のメリット
2025年12月、AnthropicはSkillsの仕様をagentskills.ioでオープンスタンダードとして公開しました。
これにより：
- ベンダーロックインを回避：作成したSkillsがClaude専用にならない
- 他のAIツールでも動作：Microsoft（VS Code、GitHub）、Cursor、Gooseなどが採用
- 資産として蓄積：AIツールを乗り換えても、Skillsはそのまま使える（場合がある）
Claudeのパーソナライゼーション機能の全体像
Skillsを理解するには、Claudeのパーソナライゼーション機能の全体像を把握する必要があります。
Profile Preferences（プロフィール設定）
アカウント全体に適用される設定です。「質問する前に確認して」「簡潔に説明して」といった、すべての会話に共通する好みを設定します。
私の場合、Profile Preferencesは、かなりしっかり設計しています。 基本プロフィール、Claudeの役割設定、時系列確認プロセス、最新情報の取得判断、文字数カウントの手順、特殊なファイル処理方法など、約4,200文字分の指示を入れています。これにより、どの会話、どのプロジェクトでも一貫した品質で作業できるようにしています。
一方で、長すぎるProfile Preferencesは「Lost in the Middle」問題（コンテキスト中間部の情報が見落とされやすい現象）を引き起こす可能性があります。
※重要な指示は最初か最後に配置するのがベターです。
Project Instructions（プロジェクト指示）
特定のプロジェクト内でのみ適用される指示です。プロジェクト固有のコンテキストや要件を設定します。
ChatGPTでは、Custom GPTsを利用するとユーザーのCustom Instructionsが事実上無効化されがちな印象ですが、Claudeではプロジェクト内で作業していてもProfile Preferencesは引き続き適用されます。つまり、プロジェクト固有の指示と、アカウント全体の好みを両立できる設計になっています。
Skills（スキル）
特定の作業タイプで自動的に発動します。Profile PreferencesやProject Instructionsとは違い、関連するタスクを依頼したときだけ読み込まれます。
公式ドキュメントの説明：
Unlike custom instructions, Skills can contain far more detail. They can include extensive instructions, complete reference libraries and detailed frameworks that would otherwise clutter custom instructions.Skills are also specific to certain types of work and activate only when relevant. .
（Skillsはカスタム指示よりもはるかに詳細な内容を含めることができます。詳細な指示、完全なリファレンスライブラリ、詳細なフレームワークを含めることができます。また、Skillsは特定の種類の作業に固有であり、関連性がある場合にのみ有効になります。）
Skillsにすべきケース、すべきでないケース
Claudeとの対話の中で、具体的な判断基準が見えてきました。
✅ Skillsに向いているもの
- 入力→定型処理→出力のパターンがある
- トリガーが明確（「〇〇を作成して」で発動）
- 手順が決まっている
- 複数のプロジェクトで横断的に使いたい
❌ Skillsに向いていないもの
- 対話しながら要件を詰める作業
- 毎回異なる出力が求められる
- 思考プロセス自体に価値がある
- 蓄積・履歴が重要
私がSkillsにしたもの：Project Instructions生成
私は「プロンプト工場」という、ClaudeプロジェクトのProject Instructions（プロジェクト指示）を作成するためのプロジェクトを運用していました。
新しいClaudeプロジェクトを立ち上げるたびに、このプロジェクトに移動してProject Instructionsを作成し、それを新プロジェクトにコピーする──という流れです。
最初の判断：Skillsにしない
最初は「Skillsにしない方が良い」と考えました。
理由：
- 対話しながら要件を詰める作業だから
- 蓄積された履歴・文脈に価値があるから
転換点：ワークフローを見直した
しかし、実際の業務フローを考え直しました。
理想のワークフロー：
- 新しいClaudeプロジェクトを立ち上げる
- プロジェクトナレッジにファイルを収納する
- 最初のチャットで「Project Instructionsを作成して」と依頼
- 完成した指示文をProject Instructionsにセット
- 新しいチャットで本作業を開始
このワークフローなら、わざわざ別プロジェクト（プロンプト工場）に移動する必要がありません。どのプロジェクトでも「Project Instructionsを作成して」と言えば同じ品質で生成される方が便利です。
結論：Skillsにした
改めて判断基準に照らすと：
- ✅ トリガーが明確：「Project Instructionsを作成して」
- ✅ 出力が定型的：決まった構成の設定文
- ✅ 手順が決まっている：ナレッジ分析→ヒアリング→生成
- ✅ 横断的に使いたい：全プロジェクトで使う
Skillsに向いている条件をすべて満たしていました。
私がSkillsにしなかったもの
一方で、以下の2つはSkillsにしませんでした。
1. 特殊形式のPDFを解析する処理
私のProfile Preferences（プロフィール設定）には、「2in1形式PDF」という特殊なPDFファイルを解析する手順が含まれています。これは実際にはZIPアーカイブになっているPDFで、通常の方法では読み取れません。
Skillsにしなかった理由：
- 発動の確実性を重視：Skillsは自動判定なので、発動しないリスクがある。Profile Preferencesなら毎回読み込まれるので確実
- すでに機能している：現状の運用で問題なく動作している
- 他の処理と組み合わせる：PDF処理だけでなく、プロジェクト全体の文脈で使うことが多い
2. 厳密な文字数で文章を生成するプロセス
文字数指定がある場合に、Pythonのlen()関数を使って3段階で調整するプロセスも、Profile Preferencesに含めています。
Skillsにしなかった理由：
- トリガーが曖昧：「文字数指定がある場合」は様々な文脈で発生する
- 他の作業と組み合わせて使う：単独で発動するより、常に参照できる方が良い
- 発動の確実性：文字数指定があるときに確実に動いてほしい
プランによる判断の違い
ここで重要なのは、私がClaude Maxプランを使っているという点です。
会話のたびに読み込まれるProfile Preferencesが4500文字（約3,000トークン）でも許容範囲と考えています。
しかし、もしProプランにダウングレードするなら、判断が変わるかもしれません。
Proプランはコンテキストを節約する意識がMaxより必要なため、「2in1 PDF処理」や「文字数カウント」のような「たまにしか使わない機能」はSkillsに切り出して、Profile Preferencesを軽量化する価値が出てきます。
判断のポイント
Skillsにするかどうかの判断は、以下のポイントで考えると良いでしょう。
Skillsにすべきサイン：
- 毎回同じ説明を繰り返している
- 複数のプロジェクトで同じ処理をしたい
- Profile Preferencesが肥大化している
- Lost In Middle問題が発生している気がする
- トリガーが明確で、単独で完結する処理
Skillsにしなくて良いサイン：
- 現状の運用で問題なく動いている
- 発動の確実性を重視したい（確実に動いてほしい）
- 他の機能と組み合わせて使うことが多い
- プランに余裕がある（Maxなど）
まとめ
Skillsを使うかどうかの判断基準をまとめます。
Skillsにする
- 特定のトリガーで発動する定型処理
- 複数プロジェクトで横断的に使いたい
- Profile Preferencesが肥大化している
Skillsにしない
- 現状の運用で問題なく動いている
- 発動の確実性を重視したい
- 毎回の会話で必要な指示（→ Profile Preferences）
- 特定プロジェクト固有のコンテキスト（→ Project Instructions）
「便利そうだからSkillsにしよう」ではなく、今の運用で困っているかどうかを基準に判断することが大切です。
そして、一度「Skillsに向いていない」と判断しても、ワークフローを見直すことで判断が変わることもあります。また、利用しているプランによっても判断は変わります。「どう使いたいか」「どのプランを使っているか」を具体的にイメージすることが、正しい判断につながります。
この記事はnoteでも公開しています。
実装支援・DX推進・生成AI活用のご相談は、お気軽にお問い合わせください。
→ お問い合わせはこちらから