Codex の Skills を部門で作って共有する方法｜手順書を「呼び出せる形」にする

Codex Skills は、部門で繰り返す手順を「毎回プロンプトに貼る」のではなく、呼び出せるワークフローとして整理するための仕組みです。議事録の整形、週報作成、レビュー観点の統一など、部門ごとの暗黙知を扱いやすくできます。本記事では、Codex Skills の作り方を、構造・呼び出し方・配布と制限の観点で整理します。

Codex Skills とは何か：手順書を「再利用できる単位」にする

Codex Skills は、特定のタスクやワークフローに必要な指示、補助資料、必要に応じたスクリプトをまとめる仕組みです。公式ドキュメントでは、Skill は「特定のタスクまたはワークフローのための指示と支援リソースをパッケージ化するもの」と説明されています。毎回同じテンプレート、観点、禁止事項、出力形式をプロンプトに貼る代わりに、Skill として定義しておくことで、ChatGPT や Codex が該当タスクで同じ手順を参照しやすくなります。Skills & Plugins

部門利用で考えると、対象は高度な開発作業に限りません。たとえば、会議メモから議事録を整える、週報を指定フォーマットにまとめる、社内ドキュメントの表現を統一する、といった「成果物の型が決まっている業務」が候補になります。重要なのは、Skill を「何でもできる便利箱」にしないことです。公式ドキュメントでも、良い Skill は単一の焦点を持つタスクから始めることが推奨されています。Build skills

また、Skill と Plugin は役割が異なります。Skill は再利用可能な指示やワークフローを設計する単位です。一方、Plugin は Skill や MCP サーバーなどを含められるインストール可能な束として説明されています。部門内でまず手順を固める段階では Skill、複数の Skill や接続機能をまとめて配布したい段階では Plugin を検討する、という整理がしやすいでしょう。Skills & Plugins

Skill の基本構造：SKILL.md を中心に、資料を分けて置く

Codex Skills の基本は、Skill 用のディレクトリを作り、その中に必須ファイルである SKILL.md を置くことです。公式ドキュメントでは、Skill は SKILL.md に加えて、任意で scripts/、references/、assets/、agents/openai.yaml などを含められる構造として示されています。SKILL.md には name と description が必要です。Build skills

meeting-followup/
  SKILL.md
  references/
  assets/

SKILL.md の最小構成は、次のように考えると分かりやすいです。

---
name: meeting-followup
description: 会議メモから議事録とフォローアップ事項を作成する必要があるときに使う。
---

目的:
会議メモをもとに、決定事項、未決事項、担当者が必要な確認事項を整理する。

入力:
- 会議メモ
- 参加者名が分かる場合はその情報
- 出力フォーマットの指定がある場合はそのテンプレート

手順:
- メモから議題、決定事項、未決事項を分ける
- 曖昧な内容は断定せず、確認事項として残す
- 担当者や期限が不明な場合は「要確認」とする

出力:
- 議事録
- フォローアップ事項
- 確認が必要な点

description は特に重要です。Codex は、ユーザーが明示的に Skill を指定する場合だけでなく、依頼内容が description に合うと判断した場合にも Skill を使えます。そのため、「いつ使うか」「いつ使わないか」が短く分かる説明にしておく必要があります。範囲が広すぎる説明にすると、意図しない場面で呼び出される可能性があるため、部門名や成果物名だけでなく、対象となる入力と出力も書くと運用しやすくなります。Build skills

Codex での呼び出し方：明示呼び出しと自動選択を使い分ける

Codex で Skill を使う方法は、明示的に呼び出す方法と、依頼内容に応じて Codex が選ぶ方法に分けられます。公式ドキュメントでは、Codex CLI や IDE extension では /skills を実行するか、$ を入力して Skill をメンションできるとされています。また、タスクが Skill の description と一致する場合、Codex が Skill を選ぶこともあります。Build skills

明示呼び出しは、部門で標準化したい作業に向いています。たとえば、議事録整形 Skill を作った場合、依頼文は次のようになります。

$meeting-followup
以下の会議メモを、部門の議事録フォーマットに整理してください。

一方、自動選択を期待する場合は、description が曖昧だと安定しにくくなります。公式ドキュメントでは、暗黙的な一致は description に依存するため、説明文は簡潔で範囲と境界が明確なものにすることが推奨されています。特に、多くの Skill が入っている環境では、Codex が最初に参照する Skill 一覧の説明が短縮される場合があるとされています。そのため、重要な用途やトリガー語は説明文の前半に置く設計が有効です。Build skills

部門導入では、最初から自動選択に頼りすぎないことも大切です。利用者に「この業務はこの Skill を $ で呼ぶ」と周知し、実際の出力を見ながら SKILL.md を調整していくと、手順の抜けや過剰な指示を発見しやすくなります。Codex をチームで使う観点は、Codex の Skills・Automations・Worktrees をチームで使う考え方もあわせて確認してください。

部門で作る手順：まず「単一業務」に絞って試す

Skill 作成では、最初に対象業務を絞ります。公式ドキュメントでは、週次更新、キャンペーンブリーフ、会議後のフォローアップなど、手順と形式を一定にしたい作業が最初の候補として示されています。部門であれば、議事録整形、週報作成、社内共有文の下書き、問い合わせ内容の分類などが近い考え方です。Skills & Plugins

このとき、既存の手順書をそのまま貼るだけでは不十分な場合があります。人間向けの手順書は前提知識を省いていることが多いため、Skill では「何を入力として受け取り、どの順番で処理し、どの形で返すか」を命令文として書き直します。たとえば「きれいにまとめる」ではなく、「決定事項、未決事項、確認事項に分ける」のように、処理可能な粒度にします。

開発チームでは、リポジトリ全体の方針や作業ルールを別文書で管理する場面もあります。Skill と周辺文書の役割分担を考える際は、Codex AGENTS.md の書き方ガイドも参考にしてください。

配布と制限：ローカル Skill、Workspace Skill、Plugin を混同しない

部門で共有する際に注意したいのは、Skill の配布経路によって管理境界が異なる点です。公式ドキュメントでは、ChatGPT workspace Skill、ローカルファイルシステム Skill、Plugin は、それぞれライフサイクルとアクセス制御が分かれていると説明されています。ある配布経路に Skill を移しても、ChatGPT workspace の所有権、共有、役割、Plugin のインストール状態、コネクタ認可などが自動的に移るわけではありません。Skill controls

ローカルファイルシステム Skill の場合、Codex は複数の場所から Skill を読み込みます。リポジトリ内の .agents/skills、ユーザーの $HOME/.agents/skills、管理者向けの /etc/codex/skills、OpenAI によってバンドルされる system Skill などが示されています。リポジトリ配下に置くと、その作業フォルダに関連する Skill として扱いやすく、管理者向けの場所に置くと、同じマシン上の利用者に既定の Skill を用意する用途に向くとされています。Build skills

配布の考え方	向いている用途
リポジトリ内の Skill	特定の業務フォルダや開発対象に紐づく手順
ユーザー配下の Skill	個人が複数の作業で使う手順
管理者向け場所の Skill	同じ環境の利用者に既定で用意する手順
Plugin	Skill や接続機能をまとめて配布したい場合

制限の考え方としては、ローカルでは ~/.codex/config.toml の [[skills.config]] で Skill を削除せず無効化できるとされています。また、agents/openai.yaml の allow_implicit_invocation を false にすると、Codex はプロンプト内容に基づく暗黙的な呼び出しを行わず、明示的な $skill 呼び出しは引き続き使えるとされています。部門で運用する場合は、「自動選択してよい Skill」と「明示指定に限る Skill」を分けると、想定外の適用を抑えやすくなります。Build skills

運用時のチェックポイント：増やす前に説明文と責任範囲を整える

Skill は増やしやすい一方で、部門内に似た Skill が乱立すると、どれを使うべきか分かりにくくなります。公式ドキュメントでは、同じ name の Skill があっても Codex はそれらをマージせず、両方が Skill セレクターに表示される場合があるとされています。そのため、命名と説明文の管理は部門運用で重要です。Build skills

チェックしたい観点は、次の通りです。

観点	確認すること
目的	対象業務が広すぎないか
入力	利用者が何を渡すべきか分かるか
出力	完成物の形式が明確か
説明文	暗黙的に呼ばれてよい範囲か
禁止事項	断定してはいけない内容や確認扱いにする条件があるか
配布場所	リポジトリ、ユーザー、管理者向け場所、Plugin のどれが適切か

また、Skill は「作って終わり」ではありません。現場で使った結果、出力のぶれや不足が見つかれば、SKILL.md を更新していきます。Codex は Skill の変更を自動検出するとされていますが、更新が表示されない場合は再起動するよう公式ドキュメントに記載されています。運用ルールとして、誰が更新し、どの入力例で確認し、どの部門に共有するかを決めておくと、Skill が属人化しにくくなります。Build skills

チーム利用全体の整理としては、Skill だけでなく、関連する作業分離やチーム運用の考え方も重要です。部門展開を検討している場合は、Codex の Skills・Automations・Worktrees をチームで使う考え方もあわせて読むと、位置づけを整理しやすくなります。

まとめ

Codex Skills は、部門で繰り返している手順を、呼び出せる形に変えるための仕組みです。まずは議事録整形や週報作成のように、入力と出力が明確な業務から始めるのが現実的です。SKILL.md には、名前、説明、目的、入力、手順、出力、避けるべきことを具体的に書き、必要に応じてテンプレートや参考資料を分けて置きます。

呼び出しは、Codex では $ による明示指定と、description に基づく暗黙的な選択があります。部門運用では、最初は明示呼び出しを基本にし、説明文と出力を確認しながら調整するのが安全です。また、配布経路は ChatGPT workspace Skill、ローカルファイルシステム Skill、Plugin で管理境界が異なるため、どの経路で共有するかを先に決めておくことが重要です。Skill を増やす前に、命名、説明文、責任範囲、無効化や暗黙呼び出しの扱いを整理しましょう。

デジライズでは、部門ごとの業務手順を棚卸しし、Codex Skills として整理するための導入コンサルティングや、実務担当者向けの法人研修を支援しています。既存の手順書をどこまで Skill 化すべきか、リポジトリや管理者向け配布をどう分けるべきかを検討したい場合は、無料相談からご相談ください。

関連記事

• Codex の Skills・Automations・Worktrees をチームで使う考え方
• Codex AGENTS.md の書き方ガイド