CodexのSkillsはなぜ.codexではなく.agents配下にあるのか — Agent Skillsというオープン仕様の話

.claudeと.codexで置き場所が違う、という違和感

Claude Codeでは、プロジェクトに追加する拡張は .claude 配下に集まります。サブエージェントもスキル（Skills）も、置き場所は .claude の中。「Claude Codeに関するものは .claude を見ればいい」という、覚えることの少ない分かりやすい世界です。

同じ感覚でCodexのフォルダ構成を見ると、途中で手が止まります。.codex 配下にいるのはサブエージェントだけで、Skillsが見当たらないのです。CodexのSkillsの置き場所は .agents/skills——製品名とは別の名前のフォルダにあります。当社で最初にこの構成を確認したときも、率直に「なぜ自分の名前のフォルダに揃えないのか」という違和感がありました。

しかし調べていくと、これは置き忘れでも設計の乱れでもなく、明確な意図を持った判断でした。背景には、ツールの垣根を越えて広がりつつあるオープン仕様があります。

答えはAgent Skillsというオープン仕様

結論から言うと、CodexのSkillsはCodex固有の形式ではありません。ベースになっているのは、Anthropicが2025年12月に公開した「Agent Skills」というオープンな共通仕様です。スキルの実体は、SKILL.mdという自然言語の手順書を中心に、必要に応じてスクリプトやテンプレートを同梱できる1つのディレクトリ。特定の製品に依存しない、いわば「AIエージェント向けマニュアルの標準フォーマット」です。

この仕様は公開後まもなくOpenAI（ChatGPT・Codex）やMicrosoft（VS Code）が対応し、2026年春時点では30以上のツールが同じ形式のスキルを読めるようになっています。そして仕様側の慣習として、チームで共有するスキルはリポジトリの `.agents/skills/` に置くことになっています。Codexはこの慣習にそのまま従っているだけ——だから .codex ではなく .agents なのです。Codex専用の場所に置かないことで、同じスキルをAgent Skillsに対応する他のツールからもそのまま再利用できます。

.agentsと.codexの役割分担 — 能力と設定を分ける

この前提に立つと、Codexのフォルダ構成は一貫した切り分けとして読めます。.agents に置かれるのは「エージェントが使う、再利用可能な能力」。.codex に置かれるのは「Codexというツール固有の実行設定」。整理すると次のようになります。

同じ「エージェント関連のファイル」でも、どのツールでも通用する資産なのか、このツール専用の設定なのかで住所が分かれている——そう捉えると、最初の違和感はむしろ設計の明快さに変わります。ツール横断の共通形式という意味では、作業フォルダのルールを書くAGENTS.mdも同じ発想に立つ仕組みです（具体的な書き方はAGENTS.mdの書き方で解説しています）。

設計思想の違い — 製品単位でまとめるか、資産を分離するか

では、.claude 配下にすべてを置くClaude Codeの設計は古いのかというと、そうではありません。「このツールに関するものはこのフォルダを見ればよい」という分かりやすさは導入初期の迷いを確実に減らしますし、そもそもAgent Skillsの発案元はAnthropic自身です。製品単位でまとめる構成には、それはそれのはっきりした合理性があります（Claude Code側でのスキルの作り方はClaude CodeのSkillsの作り方で解説しています）。

一方Codexは、ポータブルなAgent資産（.agents）とCodex固有設定（.codex）を分離する構成を選びました。フォルダがひとつにまとまる分かりやすさよりも、書いたスキルを他のツールでも使い回せることを優先した形です。どちらが正しいという話ではなく、「製品単位でまとめる」か「資産の持ち運びやすさで分ける」かという整理の哲学の違い——両方を知っておくと、2つのツールのフォルダ構成がすっと頭に入ります。

実務への示唆 — スキルは特定ツールに縛られない会社の資産になる

ここまでの話は、フォルダ構成の豆知識にとどまりません。企業のAI活用にとって重要なのは、業務手順をスキルとして書き溜めたものが、特定ツールにロックインされない「会社のナレッジ資産」になりうるという点です。

AIツールの導入判断には「いま選んだツールが2年後も最適とは限らない。乗り換えたら、それまでの蓄積が無駄になるのではないか」という迷いがつきものでした。Agent Skillsのようなオープン仕様の広がりは、この迷いに対する業界としての答えです。手順書という資産をツールから切り離し、持ち運べるようにする——業界はいま、その方向に向かっています。だからこそ、スキルを書くときも「持ち運べる資産」になるよう意識しておくと価値が長持ちします。

• 手順そのものを自然言語で書く — 特定ツールの操作ではなく「何を・どの順で・どう判断するか」を中心に書くと、ツールが変わっても通用します
• チーム共有はリポジトリの `.agents/skills/` に置く — 仕様側の慣習に合わせておけば、対応ツールが増えるほど再利用の選択肢が広がります
• ルールと手順を分ける — どの仕事でも毎回守る原則はAGENTS.mdに、繰り返し業務の手順はスキルに。この分担は資産の棚卸しもしやすくします

当社自身、40以上の業務をAIエージェントに任せる中で、繰り返し業務の手順を1つずつスキルに落としてきました。その経験から言えるのは、スキル化の本質はツールの操作ではなく業務の言語化だということです。どの業務からスキルにするか、手順をどの粒度で書くか、書いたスキルをどう育てるか——当社のCodex研修・導入伴走支援では、貴社の実業務を題材に、スキル化する業務の選定から手順書の初版づくり、運用の定着までを一体でご支援しています。