CodexのSkillsの作り方｜使い方と注意点

こんにちは。Osukeラーニング、運営者の「osuke」です。

Codexに同じ仕事を頼むたび、出力形式や注意点を最初から説明していませんか。Skillsを使えば手順を再利用できると聞いても、SKILL.mdの書き方、保存先、AGENTS.mdとの違い、自動で使われる条件が分からず、導入をためらうこともありますね。

結論からいうと、最初は「一つの仕事を、決めた範囲で終えるスキル」を作るのがおすすめです。万能な指示集を増やすより、いつ使い、何を受け取り、何を返し、どこで止まるかを明確にする方が、確認と修正を進めやすくなります。

この記事は2026年10月5日時点のOpenAI公式資料と、本文を確認できたXの公開投稿を基に整理しています。私自身の導入体験や効果測定ではありません。後半の週報スキルは説明用の作成例であり、実際の運用で成功を確認した製品ではない点も、先にお伝えしておきます。

記事のポイント

• Skillsと常設ルール、外部ツール連携の役割を分ける
• 適用する依頼だけでなく、使わない依頼も決める
• 最小のSKILL.mdから始め、資料や処理を必要に応じて足す
• 呼び出し・出力品質・安全性を別々に検証する

CodexのSkillsでできること

最初に、スキルにまとめると便利な仕事と、別の場所で管理した方がよい情報を分けます。「何でも覚えさせる」から「必要な手順を取り出せる」へ考え方を変えるのが出発点です。

繰り返す仕事を手順にまとめる

Skillsは、特定の仕事を進めるための指示や参照資料をまとめる仕組みです。単に長いプロンプトを保存するだけでなく、作業の入口と成果物の形を揃えるために使えます。たとえば、毎週のメモから報告書を整理する、変更内容からリリースノートを下書きする、指定の基準で原稿を点検する、といった繰り返しの仕事が候補になります。一度だけの質問まで、すべてスキルにする必要はありません。

週報を例に考えてみましょう。毎回「完了したこと、進行中のこと、困っていること、来週の予定に分けて」と入力しているなら、その整理手順は再利用できます。ただし、今週の日付や対象のメモ、提出先の事情まで固定すると、来週は使いにくくなります。変わらない手順と、その回だけの情報を分けることが大切です。スキルには整理の方針を置き、毎回の依頼では対象資料と今回の条件を渡す、と考えるとすっきりします。

向いているかを判断するために、「同じ説明を繰り返しているか」「仕上がりを確認できるか」「対象外の仕事を説明できるか」の3点を見てください。すべて曖昧なら、まず普通の会話で仕事の形を固めた方が早いかもしれません。何を作るかも決まっていない段階で手順を固定すると、状況に合わない指示を毎回読ませることになります。再利用は、まだ決まっていない判断まで機械的に固定することではありません。

• 繰り返す手順と毎回変わる入力を分ける
• 最初は確認しやすい一つの仕事に絞る
• スキルがなくても済む依頼まで無理に対象にしない

たとえば「今週の週報を整える」は小さく始められますが、「仕事をすべて改善する」では完成を判定できません。後者をそのままスキル名にせず、週報整理、会議メモの確認、原稿の表記チェックといった単位に分けます。作成後に見るべき成果も、時間が短くなったという印象だけではなく、抜けていた項目が減ったか、修正の理由を追えるか、といった確認可能なものにすると評価しやすいですね。

AGENTS.mdやMCPとの違い

毎回守ってほしいプロジェクトの方針と、特定の仕事で使う手順は分けて考えます。たとえば「既存のファイルを勝手に削除しない」は仕事全体の境界です。一方、「週報を4項目に整理する」は週報を作るときの手順です。両方を一つの大きなスキルへ詰め込むと、週報を作らない場面にも不要な説明が入りやすくなります。常設の方針はAGENTS.md、目的別の手順はSkills、という役割分担をまず検討してください。

OpenAIのプラグイン向け資料でも、スキルは作業手順を、MCPサーバーは情報取得や認可された操作を担うものとして説明されています。外部の業務システムを読むには、文章で「読み取る」と書くだけでなく、利用できる接続と権限が必要です。反対に、利用者が渡したメモを整理するだけなら、新しい外部接続を追加しなくても始められる場合があります。スキルを作るために必ずMCPを導入しなければならない、という理解は不要です。

たとえば「週報を作成し、チームへ送信する」という依頼では、文章整理と外部送信の間に境界があります。スキルに送信手順が含まれていても、宛先や送信内容の承認が自動的に得られるわけではありません。まず下書きまでの仕事を独立させておくと、試験中に意図せず送ってしまうリスクを減らせます。技術的にできる操作と、今回依頼された操作を区別することが重要です。

• Skillsは権限を増やす仕組みではない
• 外部サービスを使わない仕事なら、接続を増やさず始める
• 下書き作成と公開・送信は別の行為として設計する

共通ルールの置き方は、CodexのAGENTS.mdで指示を整理する方法でも扱っています。似た指示を両方へコピーし続けると、一方だけ更新して食い違う原因になります。どちらを正本にするかを決め、必要な場所から参照する形を考えましょう。スキルの役割が明確になると、何を直せば結果が変わるのかも見つけやすくなります。

Xの活用例とつまずきから考える

Xを調べると、Skillsを入れれば大きく仕事が変わるという紹介と、指示を整理し直さないと使いにくいという話の両方が見られました。ただし、今回確認したのは少数の公開投稿です。投稿者の環境や入力、評価方法が揃っているわけではないので、利用者全体の成功率や特定スキルの性能を示す調査としては扱いません。ここでは、読者が何に期待し、どこを確認したいのかを考える材料にします。

2026年9月21日の@MakeAI_CEOの投稿は、CodexにJev Skillsを導入することを強く勧める内容でした。引用記事のプレビューには、生成する処理と判定する処理を分けるという説明がありましたが、この記事では動画や仕組みの効果を検証していません。紹介の強い言い回しを、そのまま「導入すれば仕事が不要になる」という結論へ置き換えることはできません。関心を持ったら、自分の成果物を何で判定するのかへ話を戻すのがよいと思います。

対照的に、9月14日の@Av1dliveは、広すぎる適用条件や矛盾した指示を定期的に監査する自身の設定を紹介していました。安全上の境界、必要なテスト、影響の大きい操作の承認は維持するという内容も含まれています。7月22日の@ai_ai_ailoverには、Skillsだけではルールを守らない場合があるという個人の感想がありました。ただし、どの条件で起きたかは確認できないため、製品全体の不具合やAGENTS.mdによる万能な解決を証明するものではありません。

• 宣伝や個人の感想を性能の保証にしない
• 指示の監査例から、不要な権限緩和までまねしない
• 再現条件がない失敗談は、確認項目を考える材料に留める

3つの投稿から考えられる実用的な問いは、「入れたか」ではなく「期待したときに使われ、期待した仕事だけをしたか」です。スキルが呼ばれなかったのか、呼ばれた後に手順が曖昧だったのか、結果の判定が足りなかったのかを分けます。次の章から示す週報の例も、この切り分けをしやすくするための提案です。投稿者の成功を再現した実験や、私自身の運用実績として紹介するものではありません。

自動適用と明示呼び出しを分ける

スキルには、名前を指定して使う方法と、依頼内容に応じて選ばれる方法があります。最初の検証では、どのスキルを使うつもりなのかを明示した方が、動作を追いやすくなります。現行の公式資料では、Codex CLIやIDE拡張でスキルを指定する入口として、$による指定や/skillsが案内されています。画面や製品によって選び方が異なるので、同じ記号がすべての画面で使えるとは考えず、利用している環境で確認してください。

週報整理のスキルなら、「$weekly-noteを使って、このメモを週報に整理してください」のように目的を添えて指定します。単にスキル名だけ書くより、対象の入力も一緒に示す方が何を処理するか明確です。一方、自動選択を期待するなら、説明文に使う場面が伝わる必要があります。「文章の作成や仕事の改善に使う」では、メール添削や企画相談まで広がりかねません。「箇条書きの作業メモを週報へ整理するときに使う」と対象を狭めます。

最初は自動選択に任せたくない場合、公式資料にあるagents/openai.yamlの設定で、policyのallow_implicit_invocationをfalseにする方法があります。これは暗黙の呼び出しを抑える設定で、明示的な呼び出しまで禁止するものではありません。また、危険な操作を技術的に阻止する権限制御でもありません。「いつ選ぶか」と「選ばれた後に何をしてよいか」を別々に決めることが、使い過ぎを防ぐポイントです。

• 最初は名前と対象入力を明示して試す
• descriptionには用途と適用範囲を短く書く
• 暗黙呼び出しの抑制と、操作権限の制限を混同しない

自動化したいから、最初から何にでも反応する説明へ広げる必要はありません。意図どおりに動く範囲を確認してから、似た依頼の言い方でも適切に選べるかを試す方が、問題の場所を絞れます。「週報を書いて」では使うが、「週報とは何か説明して」では実作業の手順を始めない、という違いも確認しましょう。使うべき場面で選ぶことと、使わなくてよい場面を見送ることは、どちらも大切な品質です。

作る前に入力と完成条件を決める

ファイルを書く前に、入力、出力、禁止事項、足りないときの対応を1枚のメモへ整理します。ここが曖昧なまま文章を増やしても、実行時の迷いは減りません。週報なら入力は「利用者が指定した作業メモ」、出力は「4つの見出しを持つ週報案」、禁止事項は「実績や担当者を作らない」、不足時は「不明として残す」と決められます。まずは、人が読んでも同じ結果を期待できる程度まで仕事の範囲を言葉にします。

説明用に「資料の初稿完成。先方の返答待ち。来週は表の修正」といった架空のメモを考えます。この入力には、具体的な日付、担当者、売上金額はありません。よい出力は、それらをもっともらしく補うことではなく、書かれた事実を区分し、不明な項目を区別することです。見栄えを整えるほど、推測された情報が事実のように混ざりやすいため、「見やすい」と「正確」を別の確認項目にしておきます。

完成条件も、確認可能な形で書きます。「読みやすい週報」だけでは人によって評価が変わりますが、「4項目がある」「入力にない実績がない」「未確定事項が未確定と分かる」「送信はしない」なら確認できます。細かな言い回しをすべて固定するより、破ってはいけない条件を少数に絞るのがよいでしょう。入力の欠落がある場合も、無理に完成させるのではなく、どの情報が足りないかを示すことを成功に含めます。

• 入力：何を受け取り、何を読まないか
• 出力：何を作り、どの形で返すか
• 境界：何を推測せず、何を実行しないか
• 完成：人がどの項目を確認すればよいか

反対に、毎回大きく変わる好みまで固定すると、使うたびに例外の指示が増えます。今回だけ短くしたい、今回は箇条書きがよい、といった変更を受け入れられる余地は残しましょう。スキルは依頼者の意図を助けるためのもので、以前のひな型へ無理に戻すためのものではありません。規則を増やす前に、「次回も同じ条件か」を確認するだけでも、維持しやすい手順になります。

CodexのSkillsの作り方と検証

ここからは、外部接続や実行スクリプトを使わない小さな例を示します。実際に導入するときは、専用の試験場所で確認し、普段の業務データや公開操作とは切り離してください。

SKILL.mdの最小例を作る

最初のスキルは、文章の指示だけで作れる仕事を選ぶと確認しやすくなります。下の例は、架空の作業メモを週報へ整理するための設計例です。nameとdescriptionの後に、進め方と出力条件を書いています。コードの実行や外部サービスへの接続は含めていません。実ファイルを作る前に、「この説明で対象の仕事だけが伝わるか」を読み直し、自分の用途に合わせて名前や項目を調整してください。

---
name: weekly-note
description: 作業メモを週報案に整理する。用語の説明やメール作成には使わない。
---

# 週報案の整理
利用者が指定したメモだけを対象にする。

1. 完了・進行中・課題・次の予定に分類する。
2. 入力にない成果、金額、担当者、期限は補わない。
3. 不明な点は「要確認」と区別する。
4. 週報案と要確認事項を会話内に返す。

ファイルの上書き、外部への送信・公開は行わない。
今回の明示的な依頼に合わせて表現を調整する。

この例で重要なのは、項目数よりも境界です。「指定したメモだけ」と書くことで、関連しそうな別の資料を探し回る仕事から切り離しています。「要確認」を残すことで、不足を推測で埋めない方針も示しています。ただし、文章で禁止事項を書いたことだけを、安全が保証された証拠にしないでください。実際の権限や出力の確認は別に必要であり、次節以降の試験で期待した動作を確かめます。

作成をCodexに手伝ってもらうなら、公式に案内されている$skill-creatorへ、目的、使う場面、入力、出力、しない操作を伝える方法があります。その場合も「便利なスキルを作って」だけで任せず、「外部接続なし」「週報案を会話内に返す」「送信しない」といった条件を添えましょう。生成された内容は完成品として信用するのではなく、意図した範囲になっているかを確認する対象です。

• 初版はSKILL.mdだけで済む仕事を選ぶ
• 実行する操作と、行わない操作を両方書く
• 作成支援を使っても内容確認と試験は省かない

現行の形式や配置先は、OpenAI公式「Build skills」で確認できます。この記事のひな型は公式サンプルの転載ではなく、週報整理という説明用に作ったものです。導入済みのスキルを上書きすることはせず、新しい名前で試し、使える範囲が分かってから運用へ取り入れてください。

保存先と参照資料を整理する

保存先は、そのスキルをどこで使いたいかに合わせて決めます。確認日時点の公式資料では、プロジェクト側のローカルスキルは.agents/skills配下、個人用はホームディレクトリの.agents/skills配下が案内されています。説明用の例なら、プロジェクト内の.agents/skills/weekly-note/SKILL.mdという配置になります。古い解説とフォルダ名が違う場合は、現行の公式資料と、自分が使う環境での認識状況を優先してください。

会社や案件ごとの形式なら、最初からすべての仕事で使える個人用へ置くより、そのプロジェクト内で試す方が影響範囲を考えやすくなります。逆に、どの案件でも使う一般的な手順なら個人用が候補です。同じ名前のスキルを複数の場所へコピーして、どちらを修正したか分からなくするのは避けましょう。公式資料では、同名のスキルがあっても内容が自動的に統合されるわけではないと説明されています。

参照資料が必要になったら、SKILL.mdへすべて貼り付けるのではなく、必要な資料の場所と読む条件を案内します。たとえば、詳細な社内表記ルールをreferencesへ、再利用するひな型をassetsへ置く構成が考えられます。機械的な集計処理などが本当に必要な場合にscriptsを検討しますが、週報の文章整理だけなら、初版から実行プログラムを増やす理由はありません。少ない構成ほど、何が結果に影響したかを追いやすくなります。

• プロジェクト固有の手順と個人共通の手順を分ける
• 資料には「いつ読むか」を添える
• 同名コピーを増やさず、更新する正本を決める

資料を別ファイルにしただけでは、毎回すべて読む指示が残っていれば整理の効果は小さくなります。「数字が含まれる報告のときだけ集計ルールを確認する」のように、参照条件まで書きましょう。また、共有する資料には実名の顧客情報や認証情報を混ぜず、説明に必要な部分を匿名化した例へ置き換えます。手順を配ることと、その作成に使った業務データを配ることは別です。

動かないときは三段階で確認

スキルが動かないと感じたら、「見つかっているか」「選ばれているか」「選ばれた後に期待を満たしたか」の三段階で確認します。これらを一つの問題として扱うと、保存先の問題なのに本文を何度も書き換える、といった遠回りになります。まず利用中の環境で対象のスキルが利用可能かを確認し、次に名前を指定した依頼で使われるかを見ます。その後に、自動選択や完成物の品質を調べる順番がおすすめです。

見つからない場合は、配置先、SKILL.mdの名前、nameとdescription、無効化の設定、現在の作業場所を確認します。公式資料では変更を自動検出し、反映されない場合は再起動する案内があります。ただし、いきなり別の場所へ同じものを増やすのではなく、どのファイルを認識させたいのかを先に決めてください。表示された名前が同じでも、期待していた内容とは別のコピーを見ている可能性は切り分ける必要があります。

名前を指定すれば使えるのに、自然な依頼では使われないなら、適用条件の説明を見直します。反対に、用語の説明を頼んだだけで週報整理が始まるなら、descriptionの範囲が広すぎるかもしれません。9月11日のOpenAI公式記事「Rethinking skills and prompts for GPT-6 Astra」でも、広い適用条件や指示の衝突を再検討する考え方が示されています。だからといって、すべての詳細や安全ルールを削ればよいという話ではありません。

• 未発見なら配置と認識状況を確認する
• 誤選択なら用途の説明と対象外条件を確認する
• 出力の不備なら手順と完成条件を確認する

たとえば週報は作れたのに、入力にない期限が追加されたなら、「スキルが呼ばれない問題」ではなく、推測と完成条件の問題です。該当する1箇所を直し、同じ入力で再確認します。毎回ファイル名、保存先、説明文、本文を同時に変えると、どの変更が効いたか分かりません。症状を分け、小さく修正し、元の問題と別の依頼の両方で確認する方が、安定した改善につながります。

共有前に安全性とテストを確認

作成したスキルを試すときは、成功しやすい入力だけでなく、不足した入力や対象外の依頼も用意します。OpenAIのスキル評価の記事は、呼び出されたかという過程と、成果物が条件を満たしたかを分けて確認する考え方を示しています。本記事では最初の小さな確認として、次の5ケースを提案します。これは性能を保証する試験数ではなく、見落としを発見するための出発点です。

5番目の確認は、実際に送信させる試験ではありません。外部接続を持たない試験環境で、送信が別の判断を要する行為として扱われるかを見るものです。本文に「送らない」と書いてあるから絶対に送れない、と考えるのは危険です。操作できる権限を必要な範囲に限定し、取り返しがつきにくい行為は別の確認を設けます。指示の品質を試すことと、本番データで危険な操作を試すことを混同しないでください。

他の人が作ったスキルを使うときも、紹介文だけでなく、指示、同梱スクリプト、参照先、外部への送信先を確認します。人気があることや公式例に似ていることは、自分の業務で安全に使える証明ではありません。追加ソフトウェアの実行や接続が必要なら、その理由と影響範囲を確認してから進めます。まず機密を含まない架空データで試し、期待どおりの結果が出ることと、余計な操作をしないことを両方見ます。

• 対象外や情報不足でも期待どおりに止まれるかを見る
• 外部送信や本番変更を試験のついでに実行しない
• 共有物へ認証情報や実データを含めない

テスト結果には、入力、期待したこと、実際の結果、修正した点を短く残します。出力が良かったかだけでなく、不要なファイル変更がなかったかも確認してください。詳しい品質確認の考え方は、Codexのコードレビューとテストで確認漏れを防ぐ方法へ整理しています。スキルの共有は、確認の責任まで他人へ渡すことではない、と考えておきたいですね。

CodexのSkillsを育てる要点

CodexのSkillsは、数を増やすほど便利になるコレクションというより、繰り返す仕事の説明を整える仕組みとして使うのがよいと思います。最初は一つの目的に絞り、入力、出力、しない操作を決める。名前を指定して試し、次に自然な依頼と対象外の依頼を確認する。この順番で進めると、便利さと扱いやすさを両立しやすくなります。最初から大きな自動化へつなげる必要はありません。

たとえば週報整理を3回使って、毎回同じ修正が発生したなら、その修正理由を手順へ反映する候補にできます。一方、その回だけの提出先の都合なら、共通の規則へ入れず個別の依頼に残す方が自然です。これは3回で効果が実証されるという意味ではなく、固定すべきことと変動することを見分けるための運用例です。結果を見て直す習慣があれば、最初の文章を過度に長くする必要もありません。

モデルや周辺ツールが変わったときは、以前の補助指示が今も必要かを確認します。ただし、短くすること自体を目標にせず、守るべき境界や完成条件は残します。誰が使うか、どの資料に依存するか、直近で何を変えたかも分かるようにしておくと、共有後の修正がしやすくなります。自動で指示を改善する仕組みを導入する場合も、変更の差分と確認方法を先に決めることが大切です。

• 今日の一歩は、繰り返す仕事を一つ選んで条件を書くこと
• 呼び出しと成果物を別々に確認すること
• 手順の再利用と、権限・公開・送信の判断を分けること

Codex全体の使い方から整理したい方は、Codexでできることと安全な始め方も参考にしてください。スキルを作ったことをゴールにするのではなく、次に同じ仕事を頼んだとき、説明の手間と確認の迷いが減っているかを見ます。何に使えて何には使わないかが分かる小さな手順から、少しずつ育てていきましょう。