blog

AIブログ

Claude Skills とは？作り方・一覧・活用例【2026年版】

ClaudeのSkills機能とは――「外部能力を呼び出す仕組み」の全体像

ClaudeのSkills機能とは、一言で言えば「Claudeが自分の知識だけでは完結できないタスクを、外部のツール・APIに委譲して完遂する仕組み」です。LLM単体では「過去の学習データをもとに回答を生成する」ことしかできませんが、Skillsを使うと「リアルタイムで在庫を確認しながら回答する」「CSVを実際に計算して数値を出す」「SlackやGitHubのデータを引用しながら提案する」といった現実世界のデータと連動したタスク処理が可能になります。

本記事では、Skills機能の仕組み・作り方・使い方・活用シーンを実務的な観点から深掘りします。モデルのスペック比較は本記事の主題ではないため最小限に留め、各モデルの詳細はClaudeのモデル比較をご参照ください。

Skills機能を構成する3つのレイヤー

Claudeが持つ「外部連携能力」は、以下の3層で整理できます。どの層を使うかはユーザーの技術スタックと目的によって異なります。

レイヤー	機能名	誰が使う	開発作業
L1	ビルトインツール（Web検索・コード実行・ファイル解析）	Claude.ai Proユーザー	不要
L2	Tool Use（カスタム関数定義・外部API呼び出し）	API利用の開発者	JSON Schema定義＋実行コード
L3	Integrations（Slack・GitHub・Google Drive等との接続）	Team/Enterpriseユーザー	OAuth認証のみ（ノーコード）

以降、それぞれの「作り方と使い方」を実務視点で詳述します。

L1：ビルトインツールの使い方と使いどころ

Claude.ai（Proプラン以上）では、設定不要で利用できるビルトインツールが標準搭載されています。重要なのは「いつ使うと効果が最大化されるか」の見極めです。

Web検索――使いどころと限界

Web検索が本当に価値を発揮するのは、①タイムリーな情報が必要なとき（APIの料金変更・法改正・競合製品リリースなど）と、②Claudeが「知識カットオフ後の話」と自己認識しているときの2パターンです。

注意すべき落とし穴は「検索すれば正確」という思い込みです。Claudeは検索結果を解釈して回答に組み込むため、ソースの信頼性はユーザー側でも確認する必要があります。重要な数値（法令・価格・統計）はClaudeが引用したURLを必ず参照してください。

コード実行（Analysis Tool）――実務での具体的ワークフロー

コード実行ツールの本質的な価値は「書いたコードが本当に動くかをその場で検証できる」点にあります。以下は弊社の実際のワークフローです。

📋 データ前処理の実務ワークフロー

クライアントからCSVを受け取る
Claude.aiにアップロードし「このデータの欠損値の傾向を分析して、クリーニング用のPythonコードを書いて実行して」と指示
Claudeがコードを書き→実行→結果（欠損率・分布など）を表示
結果を見て「この列は中央値補完でなく削除する方針で修正して」と追加指示
最終的なコードをコピーして本番環境に移す

このワークフローの肝は「試作→確認→修正」のサイクルをClaude内で完結させてから本番に移す点です。ローカル環境での試行錯誤を省略でき、初稿コードの品質が大幅に上がります。

ファイル解析――有効な使い方と注意点

PDF・Word・Excel等のアップロード解析は特に長文ドキュメントのQAに威力を発揮します。有効なプロンプトパターンは以下のとおりです。

用途	効果的な指示例	注意点
契約書レビュー	「第5条の損害賠償の上限額と適用条件を箇条書きで抜き出して」	法的判断はあくまで参考。最終確認は専門家へ
技術仕様書の要点抽出	「エンジニアでない担当者向けに、セキュリティ要件のみ平易な日本語で3行で要約して」	「平易に」という指示がないと専門用語がそのまま残る
複数ドキュメントの比較	「2つの提案書を比較して、価格・納期・サポート条件の違いを表にして」	同時に複数アップロードして比較させると効率的

L2：Tool Use（API）――カスタムSkillsの作り方

APIを通じてClaudeを使う開発者にとっての「Skills設計」は、Tool Use（Function Calling）の設計品質にほぼ集約されます。ここでは「どう作るか」を具体的な手順とともに解説します。

ツール定義の5ステップ

STEP
1

ツール名を決める（name）
英数字とアンダースコアのみ使用可能。get_inventory_statusのように「動詞＋対象＋用途」の命名が後の管理を楽にします。

STEP
2

説明文を書く（description）――品質の9割はここで決まる
「いつ使うか・何を返すか・使うべきでない場面はどこか」を明記します。ツールの誤選択・未選択の大半はdescriptionの曖昧さが原因です。後述のアンチパターンを参照してください。

STEP
3

パラメータをJSON Schemaで定義する（input_schema）
各パラメータのtype・description・requiredを定義します。Claudeはこのスキーマを読んで引数を生成するため、enum（許容値の列挙）を活用するとハルシネーションが減ります。

STEP
4

実行ロジックを実装する（開発者側）
Claudeがtool_useブロックを返したら、開発者コードがそのパラメータで実際の処理を実行します。ClaudeはAPIの呼び出しやDBへのアクセスを「自分では」行いません。

STEP
5

結果をtool_resultで返してClaudeに最終回答させる
実行結果（成功・失敗・データ）をtool_resultとしてメッセージに追加し、再度Claudeを呼び出すと自然言語の最終回答が生成されます。

descriptionフィールドの書き方――良い例・悪い例

Tool Useの品質はほぼdescriptionで決まります。以下に典型的なアンチパターンと改善例を示します。

パターン	description例	問題点 / 効果
❌ 悪い例	「在庫情報を取得する」	いつ使うべきか不明。類似ツールが複数あると誤選択が頻発する
✅ 良い例	「SKUコードを指定して、倉庫管理システムから現時点の在庫数と入荷予定日を取得する。ユーザーが商品の在庫確認や在庫切れ時の入荷見込みを聞いてきた場合に使用すること。商品名での検索には使わず、必ずSKUコードを引数に使う」	使用タイミング・引数の制約・他ツールとの使い分けが明確でClaudeが正確に選択できる
❌ 悪い例	「メールを送る」	どんな場面でも使おうとし、不要なタイミングでメール送信が走るリスク
✅ 良い例	「注文確認メールをユーザーに送信する。ユーザーが明示的に「メールで送って」「確認メールを送って」と要求した場合のみ使用すること。自動送信はしない」	不意の実行を防ぐ「使ってはいけない条件」の明記が重要

tool_choiceを使った挙動制御

APIパラメータtool_choiceを使うと、ツール使用のポリシーをシステム側でコントロールできます。

設定値	挙動	使いどころ	実務例
`auto`（デフォルト）	Claudeが判断して使う・使わないを決める	汎用的な会話＋ツール併用	カスタマーサポートボット全般
`any`	必ずいずれかのツールを使う	出力を必ず構造化したい場面	フォームデータの抽出・分類タスク
`tool`（特定指定）	指定したツールを必ず使う	特定の処理を確実に通したい場面	必ず在庫確認してから回答させる注文フロー
`none`	ツールを使わずに回答する	純粋な文章生成ターン	ツール結果を元に最終文章を書かせるターン

複数ツールの並列実行とその設計パターン

Claudeは1回のレスポンスで複数のtool_useブロックを同時に返すことができます。これを活用すると「複数の独立したAPI呼び出しをまとめて処理させてから回答させる」設計が可能です。

🔄 並列ツール実行の実装パターン

ユーザーが「この商品を今注文できますか？」と聞いたとき：

Claudeが1回のレスポンスで get_inventory(sku="ABC123") と get_user_shipping_address(user_id="U001") の2つのtool_useブロックを返す
開発者コードが2つのAPIを並列で実行（asyncio.gather等）
両方の結果をtool_resultとしてClaudeに渡す
Claudeが「在庫3個あり、〇〇への配送は2〜3日です」とまとめて回答

順番に実行するより応答時間を大幅に短縮できます。ただし依存関係のある処理（Aの結果を使ってBを呼ぶ）は順次実行が必要です。

エラーハンドリングの実装パターン

外部ツールは失敗することがあります。tool_resultでエラー情報を返すと、Claudeはそれを踏まえて代替手段や説明を自動生成します。ただしリトライループは必ず開発者側で上限を設ける必要があります。

エラー種別	tool_resultに返す内容	Claudeの典型的な反応
APIタイムアウト	「タイムアウトエラー。数秒後に再試行してください」	ユーザーに再試行を促す旨を説明して再度ツールを試みる
データなし	「該当SKUのデータが存在しません」	SKUの確認を求めるか、別のツール（商品検索等）への切り替えを提案
権限エラー	「このユーザーはこのデータへのアクセス権がありません」	アクセス権なしの旨をユーザーに伝え、処理を停止

computer_use ツール――GUI操作を自動化する

computer_useはClaudeがスクリーンショットを解析してマウスクリック・キー入力・スクロールを指示できるビルトインツールタイプ（beta）です。RPA（ロボティック・プロセス・オートメーション）的なユースケースで注目されています。

使いどころ：APIが提供されていない旧来のWebアプリや社内システムの操作自動化。例えば「社内の勤怠管理システムに毎日ログインして承認ボタンを押す」といった操作をClaudeに委譲できます。

重要な注意点：本番環境での利用は専用のサンドボックス環境（仮想マシン等）の中でのみ行うことをAnthropicが推奨しています。Claudeが予期せぬ操作（ファイル削除・フォーム送信等）を行うリスクがあるため、本番データに直接アクセスできる環境には接続しないでください。

L3：Integrations（MCPコネクター）――ノーコードでの外部接続

Claude.aiのTeam・Enterpriseプランでは、OAuth認証だけで主要SaaSと接続できるIntegrations機能が利用できます。この機能の裏側はMCP（Model Context Protocol）という標準プロトコルです。

MCPとは何か――Integrationsの設計思想

MCPはAnthropicが策定したオープンプロトコルで、「AIモデルが外部データソースやツールと接続するためのUSB規格」とイメージすると分かりやすいです。USBがデバイスの種類に関わらず接続を標準化したように、MCPはどのAIモデル・どの外部サービスの組み合わせでも統一的な接続を可能にします。

🏢 エンタープライズでの活用パターン

社内のデータベースやイントラネットをMCPサーバーとして公開し、Claude.aiから直接参照させる。開発者がAPIを全部自作する必要なく、MCPのスキーマ定義を書くだけで接続できる。

🔌 公式コネクターの例

Google Drive / Docs（社内ナレッジ参照）
GitHub（PR・Issue・コード参照）
Slack（過去の決定事項検索）
Jira / Confluence（チケット・仕様書参照）
Zapier / Make（数千SaaSへの間接連携）

Integrationsの具体的な活用シーン

活用シーン：Slackコネクターを使った「議事録レス会議フォロー」

背景：「先週の設計会議でAさんが言った〇〇の件、どう決まったっけ？」という確認作業が毎日発生していた。

やり方：SlackコネクターをClaude.aiに接続し、「#design-channelで先週月曜の会議後に共有された〇〇機能の仕様決定について教えて」と聞く。

結果：Claudeが関連スレッドを検索し、決定事項・反対意見・担当者を要約して返す。Slackを自分で掘り返す作業が不要になる。

活用シーン：GitHubコネクターを使ったコードレビュー準備

やり方：「PR #142の変更内容と、関連するIssue #98の要件を比較して、要件が満たされているかチェックリストで教えて」と指示。

効果：コードレビュアーがPRとIssueを往復して手動確認していた作業を、レビュー開始前のチェックリスト生成として自動化できる。

Skills機能を最大化するシステムプロンプト設計

ツールをいくら丁寧に定義しても、システムプロンプトとの整合性が取れていないと能力が発揮されないことがあります。以下はToolUseとシステムプロンプトを組み合わせる際の実践的な設計パターンです。

ツールとシステムプロンプトの役割分担

設定場所	書くべき内容	書くべきでない内容
ツールのdescription	このツール固有の「いつ使うか・何を返すか・引数の制約」	全体的な人格・応答スタイル（これはシステムプロンプトへ）
システムプロンプト	役割・応答スタイル・ツール全体の使用方針・優先順位ルール	個々のツールの詳細仕様（descriptionと重複すると混乱の原因に）

特に複数ツールを定義する場合は、システムプロンプトに「ツール選択の優先順位と使い分けルール」を明記すると誤選択が大幅に減ります。例えば「在庫確認は必ずget_inventoryを使い、価格確認にはget_pricingを使うこと。両方の情報が必要な場合は並列で使ってよい」という形です。

XMLタグで構造化するシステムプロンプトのテンプレート

ClaudeのトレーニングはXMLタグを使った構造化に最適化されています。以下は弊社が実務で使っているテンプレート構造です。

<role>

あなたはEC事業部の在庫・注文管理アシスタントです。
</role>
<tool_policy>

– ユーザーが在庫について聞いた場合は必ずget_inventoryを呼び出してから回答する

– 在庫と価格を同時に聞かれた場合は2つのツールを並列で使ってよい

– ツールがエラーを返した場合はユーザーに状況を説明し、再試行を1回だけ行う

– 在庫の更新・注文確定など不可逆な操作は必ずユーザーに確認を求めてから実行する

</tool_policy>
<style>

丁寧かつ簡潔に。在庫数は「〇個」と明示し、入荷日が分かる場合は必ず添える。

</style>

Skills活用時のセキュリティ設計

Tools・Integrationsを実務投入する際に見落としがちなセキュリティ観点を整理します。

⚠️

プロンプトインジェクション対策

Web検索結果やユーザー入力をtool_resultとしてClaudeに渡す際、悪意ある指示（「前の指示を無視して〜」など）が混入していないかを検証するバリデーション層を挟む。特にWebスクレイピング結果や不特定多数のユーザー入力を扱う場合は必須です。

⚠️

最小権限の原則

Claudeに渡すツールは「そのタスクで本当に必要な操作のみ」に絞る。読み取りが目的なら書き込みツールを定義しない。削除操作が不要なら定義しない。定義したツールはClaudeが「使える」と認識するため、使ってほしくない操作は定義段階で除外する。

⚠️

ツール呼び出しのログと監査

どのツールが、いつ、どのパラメータで呼ばれたかを全件ログに記録する。想定外のパラメータ（大量件数のデータ取得など）をアラートで検知する仕組みを用意することで、誤動作や悪用の早期発見が可能になる。

⚠️

コンテキストに秘匿情報を入れない

APIキー・DBパスワード・個人情報などの機密情報はClaudeのコンテキスト（システムプロンプト・メッセージ）に直接含めない。ツールの実行は開発者コード側で行われるため、認証情報はコード側の環境変数で管理し、Claudeには渡さない設計にする。

Skills設計のよくある失敗パターンと対処法

実務でSkills・Tool Useを設計してきた中で遭遇した典型的な失敗パターンをまとめます。

失敗パターン	症状	対処法
ツールを定義しすぎる	類似ツールが多くClaudeが誤選択を頻発する	1回のリクエストで渡すツールは5個以下を目安に。不要なツールはその会話には渡さない
descriptionが英語→日本語タスクに不整合	英語の指示には適切に使うが日本語では使われない	descriptionとパラメータのdescriptionも日本語で書く（または英日両方記載）
パラメータの型制約が緩い	ハルシネーションによる不正な引数でツール実行エラーが多発	`enum`で許容値を列挙する。必須パラメータは`required`に明示する
ツール実行結果を全量渡す	tool_resultが巨大になりコンテキストウィンドウを圧迫	APIレスポンスから必要フィールドだけ抽出してから渡す前処理を挟む
Human-in-the-Loopなしで不可逆操作を自動化	誤った注文確定・メール誤送信などが本番で発生	書き込み・送信・削除系のツール実行前に必ずユーザー確認ステップを挿入

Skills機能の選び方――用途別フローチャート

🧭 どのSkillsを使うべきか判断フロー

Q1. 外部システムとの接続は必要ですか？

→ No：L1ビルトインツール（Web検索・コード実行・ファイル解析）で十分。APIは不要です。

Q2. 接続したいサービスの公式コネクターはありますか？（Slack・GitHub・Google Drive等）

→ Yes：L3 Integrations（Claude.ai Team/Enterprise）。コード不要で接続できます。

Q3. 自社の独自APIや社内システムと接続したいですか？

→ Yes（開発リソースあり）：L2 Tool Use（API）でカスタムツールを設計します。

Q4. 開発なしに接続したいですか？

→ Yes：自社システムをMCPサーバーとして公開し、L3 Integrationsで接続するパターンを検討してください。

まとめ――Skills設計の本質は「定義の精度」にある

ClaudeのSkills機能は、L1（ビルトインツール）・L2（Tool Use）・L3（Integrations/MCP）の3層が組み合わさることで、単なるテキスト生成を超えた外部世界と連動するエージェントとして機能します。

弊社の実務経験を通じて一貫して実感しているのは、ツールの数よりも「descriptionの書き方」と「システムプロンプトとの整合性」こそが品質の9割を決めるという事実です。高性能なモデルを使っていても、ツール定義が曖昧であれば誤選択・未選択が頻発します。逆に丁寧に設計されたツール定義であれば、比較的小さなモデルでも安定したスキル活用が実現できます。

現行のClaude Opus 4.8・Sonnet 4.6・Haiku 4.5の使い分けについては、Claudeのモデル比較をご参照ください。スキル設計と並行してモデル選択を最適化することで、コストと品質のバランスをさらに高めることができます。

Study about AI

AIについて学ぶ

GPT-5.5 Claude エージェントベンチマーク選定——日本企業が問い直すべき評価軸

GPT-5.5がClaude Fable 5を上回った——「Agents’ Last Exam」とは何か 2026年6月、AIエージェント評価の文脈...
米上院金融AI 規制公聴会——日本の銀行・証券への実務的示唆

上院金融AI 規制公聴会の要点——何が、なぜ今議題に上ったか 2026年6月11日午前10時（米東部夏時間）、米上院銀行・住宅・都市問題委員会（U.S. S...
Cerebras NvidiaのGPUに対抗——SuperAI Singaporeデモが日本のAIインフラ調達に示す論点

CerebrasがSuperAI SingaporeでNvidiaのGPUに対抗——デモの概要と報道の背景 2026年6月10〜11日、シンガポールのMarin...