まず結論：スキルはAI向けの"仕事の手順書"
AIに同じ仕事を頼むたびに、目的、手順、注意点、出力形式を説明していませんか。スキルは、その説明を一度整理して、何度でも使える形にしたものです。
プロンプトがその場の依頼なら、スキルは繰り返し使う業務マニュアルです。
たとえば「毎週の競合調査をして、根拠URLつきで3行に要約する」「社内の文体に合わせてリリースノートを書く」といった仕事を、判断手順ごとAIに渡せます。
スキルの中身は何でできている？
多くのAI開発環境では、スキルはフォルダとして管理します。中心になるのは SKILL.md という説明書です。ここに、少なくとも次のことを書きます。
- いつ使うスキルなのか
- 何を入力として受け取るのか
- どの順番で考え、どのツールを使うのか
- してはいけないこと
- 最後にどんな形で返すのか
必要なら、参考資料、テンプレート、チェックリスト、定型処理用のスクリプトも同じフォルダに置けます。AIは最初から全てを抱え込むのではなく、依頼が合ったときに詳しい手順を読み込みます。これを「必要なときだけ開く引き出し」と考えると分かりやすいでしょう。
図のイメージは「依頼 → 手順書 → ツールを使った成果」。スキルそのものが答えを保存するのではなく、どう仕事を進めるかを再利用します。
プロンプト、MCP、エージェントとはどう違う？
似た言葉が多いので、役割で分けると混乱しません。
- プロンプト：今回だけの依頼。例「この会議メモを要約して」
- スキル：依頼を安定してこなすための再利用可能な手順。例「会議メモから決定事項・担当・期限を抽出し、指定フォーマットにする」
- MCP／コネクタ：AIが外部の情報を取得したり、操作したりするための接続口。例「カレンダーを読む」「CMSに下書きを作る」
- エージェント：目的に向けて、推論し、スキルやツールを組み合わせて動く主体
スキルは"仕事の進め方"、MCPは"手足"、エージェントは"それらを使う担当者"です。
この分担にすると、社内ルールはスキルに、権限管理や最新データへの接続はMCPに置けます。手順と権限を一つの長いプロンプトに混ぜないことが、あとで安全に育てるコツです。
スキルを作ると何が変わる？
1. 品質のばらつきが減る
人によって頼み方が違っても、スキルに確認項目と出力形式があれば、最低限守るラインを揃えられます。たとえば記事作成なら、キーワード設計、一次情報、ファクトチェック、公開前確認を毎回通すようにできます。
2. 長い指示を毎回貼らなくてよくなる
長いプロンプトを保存するだけでも便利ですが、スキルは「いつ使うか」と「補助ファイルをどの順で読むか」まで含められます。更新場所も一か所に集まります。
3. 改善が資産になる
一度失敗した仕事で「この確認を先にすべきだった」と分かったら、スキルへ追記できます。次回からは、同じ落とし穴を避ける仕組みになります。
ClaudeとCodexのスキルは同じ？違う？
結論から言うと、基本思想はかなり近いです。どちらも、AIに再利用可能な手順・参考資料・補助ファイルを渡し、関連する依頼で使わせる仕組みです。SKILL.md を中心に据える設計も共通しています。
ただし、使う場所や操作感には違いがあります。製品の更新で変わりうるため、導入時は必ず公式ドキュメントを確認してください。
Claude Codeの場合
Claude Codeでは、スキルをプロジェクト用・個人用・プラグイン用などの場所に置けます。関連する依頼で自動的に読み込ませるほか、/スキル名 のように明示して呼び出す使い方があります。Claude Codeは、呼び出し制御、サブエージェント実行、動的な文脈注入など、スキルに追加できる拡張機能も案内しています。
Codexの場合
Codexでも、スキルは SKILL.md と必要な資料・スクリプトを含むフォルダです。依頼内容に合えば自動選択され、Codex CLIやIDEでは明示的にスキルへ言及して呼び出すこともできます。公式ドキュメントでは、プロジェクト・ユーザー・管理者・システムという複数の配置範囲が説明されています。
比較で大事なのは名称より運用
「Claude用」「Codex用」と分けて考えすぎる必要はありません。まずは、目的、入力、手順、禁止事項、出力という核を共通のMarkdownで書くのがおすすめです。その上で、各製品固有の呼び出し方法や権限設定だけを分けます。
移植しやすいスキルは、特定の画面操作ではなく、仕事の判断基準を中心に書かれています。
最初の1本は、小さくて繰り返す仕事にする
最初から「営業を全部自動化する」ような大きなスキルを作る必要はありません。次の条件がそろう仕事から始めると成功しやすいです。
- 週に何度も発生する
- 手順がある程度決まっている
- 失敗したときに人が確認できる
- 入力と完成形を具体的に言える
例としては、議事録の整形、提案書のたたき台、定例レポート、リサーチのチェックリスト、CMS記事の下書き作成などです。
良いスキルにする5つのコツ
- トリガーを具体的に書く
「何でも手伝う」ではなく、「競合調査を根拠URLつきで要約したいとき」のようにします。
- 入力の不足時にどうするか決める
推測してよい範囲と、必ず確認する項目を分けます。
- 確認順を固定する
たとえば「一次情報 → 下書き → ファクトチェック → 公開前確認」の順にします。
- 出力の完成形を見せる
見出し、箇条書き、JSONなど、受け取りやすい形式を指定します。
- 失敗をスキルへ戻す
うまくいかなかった依頼を、次回のための注意事項に変えます。
今日の一歩：まずは自分の"いつもの説明"を一つ選ぼう
次にAIへ長い説明を貼り付けるとき、それはスキル候補です。
- その説明は月に何回使うか
- 毎回必ず確認したいことは何か
- 完成したら、どんな形で受け取りたいか
この3つを書き出せば、最初のスキルの骨組みになります。スキルはAIを魔法のように賢くするものではなく、あなたの仕事のコツを再利用可能にする仕組みです。
参考資料
- OpenAI Developers: Skills（確認日: 2026-08-17）
- OpenAI Developers: Build skills（確認日: 2026-08-17）
- Claude Code: Extend Claude with skills（確認日: 2026-08-17）
