BlogClaude CodeCodexAIエージェントAI開発

AIコーディングエージェントの「社内ルール」をどう配るか：Claude Code / Codex のプラグインと組織配布

Claude Code や Codex をチームに入れたのに、使い方が人ごとにバラバラで、レビュー方針は CLAUDE.md や AGENTS.md に書いたきりになっています。そんな開発リーダー・CTO 向けに、ルールを文章ではなく「エージェントが読む Skills」と「実行を縛る hooks」で配り、プラグインとして束ねて組織に配布する仕組みを、Claude Code と Codex の一次ソースを確認しながら整理します。他ツールとの比較表と、フィールフロウが社内 marketplace と OSS 公開を並走させている構図も紹介します。

著者
岡崎 太
CTO / AIアーキテクト
公開日
読了時間
23分で読めます
Share

Claude Code や Codex を開発チームに入れた会社から、似た相談を受けるようになりました。「使い方が人ごとにバラバラで、誰のエージェントがどう動いているのか分からない」「レビューの方針やコーディング規約は CLAUDE.md や AGENTS.md に書いてあるのに、エージェントがそれを守っているかは誰も確かめていない」。CLAUDE.md はセッションのたびに読み込まれますが、読んだからといって守るとは限りません。破ったことを指摘すれば個人の端末の自動メモリに残ることはありますが、それはチームの規範として配られるものではありません。

フィールフロウも同じ問題を通ってきました。私たちはいま、社内向けのプラグイン群を Claude Code と Codex の両方へ配り、その一部を OSS として公開しています。この記事はプラグインシリーズの第1回として、「ルールを文章で配る」のではなく「エージェントが読む形式と、実行を縛る形式で配る」という選択肢を、中小企業の開発リーダー・CTO が判断に使える粒度で整理します。marketplace（プラグインのカタログ）や版管理の設計は第2回に寄せ、ここでは仕組みの地図と、組織配布の機能が各ツールでどこまで揃っているかに絞ります。

結論：ルールは「読ませる」と「縛る」に分けて、プラグインで配る

要点：エージェントに守らせたいルールは、判断を助ける知識（Skills）と、逸脱を機械的に止める制約（hooks）に分けて配ります。両者を束ねて配布・更新する単位がプラグインで、Claude Code のプラグイン形式は Codex も読めます（実装上の互換で、Codex 公式の正式形式は別。詳細は後述）。

先に結論を書きます。「PR を作ったら、複数の観点の AI レビューを通してからマージする」のような手順や判断基準は、エージェントが必要なときに読み込む知識として配ります。この形式が Skills（スキル）です。一方、「main ブランチで直接編集しない」のように破られたら困るものは、エージェントの意思に頼らず、ツール実行の前後で機械的に止めます。この形式が hooks（フック）です。

この2つを1つの箱に入れて配り、版を上げ、全員に更新を届ける単位がプラグインです。Claude Code のプラグイン形式は、実装上は Codex でも読めるので、ハーネス（エージェントを動かす実行環境）が混在するチームでも配布物を1つにできます。

なぜ CLAUDE.md に書くだけでは足りないのか

要点：CLAUDE.md（Codex なら AGENTS.md）はエージェントが毎回読む文書ですが、読んだ後の振る舞いを強制する力はなく、作業の場面に合わせて必要な知識だけを出す形式でもありません。組織全体に1枚を配ることはできても、リポジトリや作業の単位で配り分けて版を追う仕組みはなく、守られない原因はルールの内容ではなく配り方にあります。

理由は3つあります。

第一に、読んでも強制力がありません。CLAUDE.md に「テストを通してからコミットする」と書いても、エージェントがテストを飛ばしてコミットすることを、文章は止められません。人間のメンバーなら README のような文書に書いておけば、破ったときに指摘できます。エージェントに指摘しても、残るとしても個人の端末の自動メモリで、チーム全体の遵守を強制する力にはなりません。Anthropic の公式ドキュメントも、CLAUDE.md は「文脈であって強制される設定ではない」と明記しています。

第二に、作業の場面に合わせて読む仕組みではありません。ルート直下の CLAUDE.md はセッションの最初に全文が読み込まれます。公式ドキュメントは1ファイル200行以内を推奨し、長くなるほど守られにくくなると明記しています。ファイルパスに紐づけて条件付きで読ませる仕組み（.claude/rules/ やサブディレクトリの CLAUDE.md）はありますが、「PR を作るときだけ、この手順を読む」のように、操作の場面に合わせて必要な知識だけを出す形式ではありません。

第三に、リポジトリや作業の単位で配り分けて版を追う経路がありません。CLAUDE.md はリポジトリごとのファイルで、個人用の ~/.claude/CLAUDE.md はメンバーごとのファイルです。組織全体に配る managed policy の CLAUDE.md もあり、端末管理ツール（MDM）で配るほか、Team / Enterprise プランなら管理画面の server-managed settings（claudeMd キー）から配信して、起動時と1時間ごとの取得で更新を届け、claude doctor で反映を確かめられます。ただしこれは端末単位で全リポジトリに効く1枚の文書で、リポジトリや作業の単位で配り分ける仕組みではありません。リポジトリごとの CLAUDE.md は import や symlink で共有ファイルを参照できますが、端末をまたいだ配布と版管理は別途設計が要ります。各メンバーが自分の設定へコピーして使い始めると、ルールを直したときに誰の環境が古いままか追えなくなります。人数とリポジトリが増えるほど、この問題は大きくなります。

解決の型：Skills で「読ませる」、hooks で「縛る」

要点：Skills は「この状況ではこう考え、この手順を踏む」という知識を、エージェントが必要なときに読み込む形式です。hooks はツール実行の前後に走るスクリプトで、禁止操作を止めたり検査を挟んだりします。

Skills：エージェントが読む知識

Skills は、1つのフォルダに SKILL.md という文書を置く形式です。文書の冒頭に「名前」と「どんなときに使うか」を書き、本文に手順や判断基準を書きます。エージェントは作業中に「どんなときに使うか」を見て、該当する状況になったら本文を読み込みます。起動時に全文が読み込まれるルートの CLAUDE.md と違い、必要なときに必要な知識だけが読まれます。

この形式は Agent Skills という公開仕様になっています。Anthropic が策定してオープンな標準として公開したもので、Claude Code だけでなく Codex、GitHub Copilot、Cursor、Gemini CLI などが同じ SKILL.md を読みます（各社の対応状況は、後述の「他ツールとの比較」節の本文でまとめます）。

フィールフロウでは、PR のセルフレビュー手順、Issue の起票手順、マージ後の後片付けの手順などを Skills にしています。「レビューは複数のモデルで行い、指摘は1つの修正コミットに束ねる」といった社内の作法を、人がその都度説明しなくてもエージェントが読める形にしたものです。

hooks：実行を縛る仕組み

hooks は、エージェントがツール（シェルコマンドやファイル編集など）を実行する直前・直後に走るスクリプトです。条件に合えば実行を拒否したり検査を挟んだりし、その理由をエージェントに返します。

フィールフロウのコーポレートサイトのリポジトリでは、次のような hooks が動いています。「develop や main ブランチ上で直接ファイルを編集しようとしたら拒否する」「PR 作成コマンドを直接叩いたら拒否し、レビュー状態を検証するラッパー経由に誘導する」「ゲート付きコマンドの終了コードをパイプで潰す書き方を拒否する」。どれも、文章で注意しても繰り返された失敗を、機械的に止める形へ変えたものです。

MCP と marketplace

残る2つの部品にも短く触れます。MCP（Model Context Protocol）は、エージェントに外部ツールやデータソースを接続する規約です。社内の仕様書検索やチケット管理システムへの接続は、ここに載せます。marketplace は、プラグインのカタログです。Git リポジトリを1つ用意して所定のファイルを置けば作れ、メンバーはそこからプラグインを入れます。

仕組みの地図：4層を経営判断の粒度で

要点：Skills（知識）と MCP（接続）をプラグインが束ね、marketplace が配ります。経営判断で見るべきは、各層で「誰が書き、誰が有効化を決め、更新をどう追わせるか」です。

層 何をするか 判断で見る点
Skills エージェントが必要なときに読み込む手順・判断基準。SKILL.md 1枚から始められる公開仕様 誰が書き、誰がレビューするか
MCP 外部ツール・データソースへの接続。社内の検索やチケット管理をエージェントから使えるようにする 権限とデータの出口をどこまで開けるか
プラグイン Skills / hooks / MCP 設定 / サブエージェント定義を1つに束ねた配布単位。版番号を持つ 版管理と更新の単位をどう切るか
marketplace プラグインのカタログ。Git リポジトリ1つで作れ、メンバーはここから入れる 誰が登録・有効化を決めるか。社外に見せるか

hooks はプラグインの中身の1つで、Skills と並んで配られます。表で独立した層にしていないのは、Skills と MCP がプラグインの外でも公開仕様・規約として単体で成り立つのに対し、hooks はハーネス固有の仕組みで、単体の公開仕様を持たないためです。

Claude Code と Codex は同じプラグインを読む

Claude Code のプラグインは、フォルダの中に .claude-plugin/plugin.json という定義ファイルを置き、skills/、hooks/、.mcp.json、agents/ を並べる形式です（Claude Code Docs: Plugins reference）。

OpenAI の Codex がこれを読むかどうかは、公式ドキュメント、ソースコード、手元の環境の3段で確認しました。

まず公式ドキュメントです。OpenAI のプラグイン作成ガイドが正式な形式として説明しているのは、フォルダ直下に plugin.json を置く Agent Plugins 形式と、互換用の .codex-plugin/plugin.json です。同じページには「レガシーな形式と Claude 互換の定義ファイルも受け付ける」という趣旨の記述があります。ただし、.claude-plugin/plugin.json というパスそのものは本文に出てきません。

次にソースコードです。Codex の公開リポジトリには、プラグイン定義ファイルを探す順序を並べた定数があります。そこには .codex-plugin/plugin.json、.claude-plugin/plugin.json、.cursor-plugin/plugin.json の3つが列挙されています（openai/codex: protocol.rs）。つまり「Codex が Claude Code 形式のプラグインを読む」は、実装上は事実で、公式ドキュメントが正式形式として保証しているものではありません。

最後に手元の環境です。2026年9月17日時点で、Codex CLI 0.153.2 のプラグインキャッシュに入っているフィールフロウのプラグインは .claude-plugin/plugin.json しか持たず、.codex-plugin/ はありません。それが Codex 側でプラグインとして登録され、動いています。

ただし、Codex 側には制約もあります。公式の hooks のドキュメントによれば、Codex で実行される hooks はコマンド型と MCP ツール型の2種類で、プロンプト型とエージェント型の hooks は読み込まれても実行されません。Claude Code の agents/（サブエージェント定義）を Codex がどう扱うかは、公式ドキュメントで確認できなかったため未確認です。また Codex のプラグインのドキュメントは、IDE 拡張ではプラグインを使えないと明記しています。

判断としては、「Claude Code 形式で作れば両方に配れる」を今日の事実として使いつつ、長期の運用では公式形式（フォルダ直下の plugin.json）を併置する余地を残しておく、と考えておくのが安全です。

組織配布：誰が有効化を決め、更新をどう追わせるか

要点：見るべき問いは3つです。管理者が「入れさせる／入れさせない」を強制できるか、更新が自動で届くか、個人が勝手に追加するのを止められるか。Claude Code と Codex はどちらも管理者向けの仕組みを持ちますが、CLI 向けとクラウド向けの2系統に分かれています。

Claude Code：managed settings で強制する

Claude Code には、組織の管理者が配る managed settings という設定層があります（Managed settings）。端末管理ツール（MDM）で所定の場所へファイルを配る方式と、MDM を使わない組織向けに claude.ai の管理画面から配る方式（Server-managed settings。Team / Enterprise プランの Owner が設定）があります。

この設定層でプラグインを制御するキーは、Settings reference に列挙されています。

  • enabledPlugins：managed で true にしたプラグインは強制有効（メンバーが無効化できない）、false にしたものはどのスコープからも入れられない
  • extraKnownMarketplaces：marketplace を自動登録する。managed では自動更新の指定もできる
  • strictKnownMarketplaces：追加・インストールできる marketplace の許可リスト。空にすれば完全に閉じられる
  • allowManagedHooksOnly：組織が配った hooks 以外を実行しない
  • strictPluginOnlyCustomization：Skills / agents / hooks / MCP を、プラグインまたは managed 経由のものに限定する

更新の追わせ方については、プラグインの利用ガイドに、バックグラウンドで自動更新が見つかっても動いているセッションは起動時に読み込んだ版を使い続ける、という趣旨が明記されています。更新は再起動か /reload-plugins で反映されます。裏を返すと、「版を上げたのに古い挙動をしている人がいる」という状況は仕組み上あり得るので、更新を配ったら再起動を促す運用が要ります。

未確認事項も書いておきます。managed の enabledPlugins: true がインストールまで自動で行うかは、ドキュメントに明文がありませんでした。

もう1つ、Claude Code の CLI とは別系統として、Claude の Web / デスクトップ / Cowork 向けに「組織のプラグインディレクトリ」があります（Manage plugins for your organization）。管理者が GitHub リポジトリから同期して配り、「Required（アンインストール不可）」「Installed by default」などの配布設定を選べます。ただし GitHub 同期の対象は Private または Internal リポジトリに限られ、Public リポジトリは指定できません。この2系統は別の仕組みなので、「Claude で組織配布した」と言うときは、どちらの話かを揃える必要があります。

Codex：ワークスペース設定と端末側設定の2層

Codex の組織配布は2層です。

1層目はワークスペース設定（クラウド側）です。Plugin management によれば、ワークスペース管理者は GitHub リポジトリの marketplace をインポートして最新に保ち、役割ごとに「Available（自分で入れられる）」「Installed（既定で入る）」を選べます。適用範囲は ChatGPT の Web / デスクトップ / モバイル、デスクトップアプリ内の Codex、Codex CLI で、IDE 拡張は対象外です（Skill controls）。

2層目は端末側の管理設定です（Managed configuration）。/etc/codex/managed_config.toml などに置く設定で、プラグインの取得元を許可リストに限定する restrict_to_allowed_sources、組織が配った hooks のみ許可する allow_managed_hooks_only などがあります。

未確認事項は2つです。端末側設定に「必須インストール」に相当するキーがあるかは確認できませんでした（クラウド側の Installed がもっとも近い機能です）。また、これらの機能が Business プランで使えるかは、該当ヘルプページを取得できなかったため未確認です。

他ツールとの比較

Claude Code と Codex 以外の主要ツールについて、「管理者が有効化を強制できるか」「更新をどう追わせるか」の2つの問いに、「Claude Code 形式のプラグインを読むか」を加えた3列で整理します。3つ目の問いだった「個人が勝手に追加するのを止められるか」は、取得元の限定として1列目に含めています。「確認済み」は公式ドキュメントで裏取りできた項目です。「未確認」は筆者が調べていないという意味ではなく、公式ドキュメントに該当する記述を見つけられなかった項目です（2026年9月15日と17日時点）。

ハーネス 管理者が有効化を強制できるか 更新をどう追わせるか Claude Code 形式のプラグインを読むか
Claude Code 確認済み：managed settings の enabledPlugins で強制有効・禁止、strictKnownMarketplaces で取得元を限定 確認済み：セッションは起動時の版を保持。再起動か /reload-plugins で反映。managed で自動更新指定可 本家
Codex 確認済み：ワークスペース設定の Installed（既定導入）と端末側の取得元許可リスト。「削除不可」に相当するキーは未確認 確認済み：ワークスペース側で marketplace を同期。CLI は codex plugin marketplace upgrade 確認済み（実装上）。公式ドキュメントの保証は別形式
GitHub Copilot 確認済み：Enterprise の managed-settings.json で既知の marketplace と既定有効のプラグイン（自動インストール）を定義 未確認：公式ドキュメントに更新追随の記述を見つけられず 確認済み（対応）
Cursor 確認済み：Team Rules の強制（メンバーが無効化不可）、Team Marketplace の「Required」 確認済み：Team Marketplace の GitHub 自動同期 未確認：公式ドキュメントに記述を見つけられず
Gemini CLI 確認済み：システム設定ファイルで全ユーザーの設定を上書き。拡張機能の配布・許可リストは未確認 未確認：公式ドキュメントに更新追随の記述を見つけられず 確認済み（非対応）

比較して見えることは2つです。

1つは、SKILL.md（Agent Skills）が事実上の共通言語になっていることです。上表の GitHub Copilot、Cursor、Gemini CLI に加えて、Windsurf と Kiro も公式ドキュメントで Agent Skills 標準への対応を確認できました（2026年9月17日確認）。Amp と Cline は同じ SKILL.md 形式のスキルを読み、Claude Code の .claude/skills/ も読み込み対象にしていますが、公式ドキュメントに Agent Skills 標準への言及はありません。ルールを Skills として書いておけば、ツールが変わっても書き直しは最小で済みます。

もう1つは、「束ねて全社に押し込む」層は各社バラバラだということです。プラグインの配布まで含めて中央から強制できる仕組みが揃っているのは Claude Code、Codex、GitHub Copilot、Cursor で、その形式はそれぞれ違います。プラグインの形式についても、Agent Plugins という別の標準化の動きがあり、初期の技術運営委員会には Amazon、Cursor、Microsoft、OpenAI、Vercel が名を連ねています（同サイトの記載に Anthropic は含まれていません。この動きは8月の記事で詳しく書きました）。Claude Code 形式との関係は今後変わる可能性があります。配布の設計は「今どのツールを使っているか」で決めつつ、Skills の部分は移せる形で書いておく、というのが現時点での現実的な判断です。

フィールフロウの現在地

要点：社内向けは feelflow-plugins（Private、9プラグイン）を Claude Code と Codex の両方へ展開し、開発全般に共通する仕組みだけを ff-dev-toolkit として OSS（Apache-2.0）で公開しています。

私たちの構図は次のとおりです。

社内向けには、GitHub の Private リポジトリ feelflow-plugins を marketplace にしています。2026年9月17日時点で9つのプラグインが登録されており、開発ワークフロー（Issue 起票、レビュー、マージ後の後処理、知見の蓄積）を担うもの、生成AIコンサルティングの支援、思考・分析・ストーリーのフレームワーク群、書籍や記事の校正支援などが入っています。この1つの marketplace を、Claude Code と Codex の両方に登録して使っています。プラグイン群で開発の品質をどう支えているかは、FeelFlow AI Plugins による組織コントロールの記事にも書きました。

そのうち、開発全般に共通する仕組みだけを切り出したのが ff-dev-toolkit です。Public リポジトリで、ライセンスは Apache-2.0 です。社内リポジトリからは、公開してよいファイルの許可リストと禁止パターンの検査を通した一方向の同期で内容を写しており、公開側への反映は人が確認して行います。前節で触れたとおり、Claude の組織プラグインディレクトリの GitHub 同期は Private / Internal リポジトリ限定なので、Public の ff-dev-toolkit をそのまま組織配布の同期元にはできません。組織で配る場合は Private リポジトリへ複製して同期元にする、という注記を README に置いています。

配ってみて分かったことも1つ書いておきます。前述の「セッションは起動時の版を保持する」仕様のため、手元のプラグインキャッシュには複数の版が同居します。2026年9月17日時点で、私の環境の Claude Code 2.1.270 には ff-dev-toolkit のキャッシュが6つの版に分かれて並んでいました。動いているセッションを壊さないための仕様どおりの挙動ですが、「版を上げたのに直っていない」という問い合わせの原因にもなります。私たちは、レビュー手順の中に「動いている版を確認する」手順を入れて対処しています。ff-dev-toolkit が何を強制し、何を学習させているかの中身は、第3回で書きます。

最初の一歩：1チームで1プラグインから

要点：守らせたいルールを1つ選び、「読ませる」か「縛る」かを決め、Skills 1本と hook 1本のプラグインを Private リポジトリから1チームに配ります。全社展開の前に、更新の流れを1チームで回してみることが要点です。

全社の管理設定から始めると、設計の手戻りが大きくなります。私が勧める順序は次のとおりです。

  1. ルールを1つ選ぶ。 「PR を作ったら、複数の観点の AI レビューを通してからマージする」のように、破られると困り、破られたことが分かるルールを選びます。
  2. 「読ませる」と「縛る」に分ける。 レビューの手順の部分は Skills に、「レビュー未実施の PR をマージしない」の部分は hook に書きます。
  3. プラグインにする。 .claude-plugin/plugin.json と skills/、hooks/ を持つフォルダを1つ作り、社内の Private リポジトリに置いて marketplace にします。
  4. 1チームに配る。 メンバーに marketplace を登録してもらい、プラグインを入れてもらいます。管理者による強制は、まだ使いません。
  5. 更新の流れを回す。 ルールを1回直し、版を上げ、メンバーが再起動して反映されるまでを1周します。ここで「誰が版を上げるか」「反映をどう確認するか」が決まります。

この5つが回ってから、managed settings やワークスペース設定による強制、marketplace の許可リストへ進みます。順序を逆にすると、強制の仕組みを設計している間に、肝心のルールの中身が固まらないままになります。

次回（第2回）は、1つのリポジトリで複数のAIエージェントに配るための marketplace と版管理の設計を書きます。「Claude Code と Codex で同じものを配る」を、実際のディレクトリ構成と版の上げ方の粒度で扱う予定です。

FAQ

要点：Claude Code 用のプラグインは Codex でも動きますが、公式の正式形式ではありません。管理者による強制は Claude Code / Codex ともに可能で、範囲と方式が異なります。外注先への配布は、marketplace のリポジトリへのアクセス権が単位になります。

Q. Claude Code 用に作ったプラグインは、Codex でそのまま動きますか？

2026年9月時点では、実装上は動きます。Codex のソースコードが .claude-plugin/plugin.json を探索対象に含めており、手元でも実際に動作しています。ただし公式ドキュメントが正式形式としているのは別（フォルダ直下の plugin.json と .codex-plugin/）なので、長期運用では公式形式の併置を検討してください。hooks はコマンド型と MCP ツール型のみ実行され、サブエージェント定義の扱いは未確認です。

Q. 管理者が強制すれば、メンバーはプラグインを外せなくなりますか？

Claude Code では、managed settings で enabledPlugins を true にしたプラグインはメンバーが無効化できません。Codex では、ワークスペース設定の「Installed」で既定導入にでき、端末側では取得元を許可リストに限定できます。Codex 側で「削除不可」に相当する設定があるかは未確認です。

Q. 社内ルールをプラグインにすると、外注先にも配れますか？

marketplace は Git リポジトリなので、そのリポジトリへの読み取り権限を持つ相手には同じプラグインを配れます。外注先に社内ルールを渡す場合は、公開してよい部分を切り出した別リポジトリにするか、リポジトリの権限管理でアクセス範囲を決めることになります。フィールフロウが社内の marketplace と OSS の ff-dev-toolkit を分けているのも、この線引きのためです。

まとめ

要点：CLAUDE.md に書くだけで守られないのは配り方の問題です。ルールを「読ませる」Skills と「縛る」hooks に分け、プラグインとして束ねて marketplace から配れば、Claude Code と Codex の両方に同じものを届けられます（Codex 側は実装上の互換）。管理者による強制と更新の追わせ方は、ツールごとに範囲が異なるので、確認済みの範囲で設計します。

AIコーディングエージェントの社内ルールが守られない原因は、ルールの内容ではなく配り方にありました。CLAUDE.md に書くだけでは、エージェントを縛る強制力も、作業の場面に合わせて必要な知識だけを出す仕組みも、リポジトリや作業の単位で配り分けて版を追う経路もありません。ルールを「読ませる」Skills と「縛る」hooks に分け、プラグインとして束ねて marketplace から配れば、Claude Code と Codex の両方に同じものを届けられます。管理者による強制の範囲と方式はツールごとに異なり、未確認の点も残るので、確認済みの範囲で設計します。

最初の一歩は、1チームで1プラグインからです。社内ルールをエージェントに配る設計や、Claude Code / Codex の導入についてご相談があれば、お問い合わせからご連絡ください。

参考資料・データソース

確認範囲：各公式ドキュメントとソースコードの記述を2026年9月15日に確認し、記事で引用した URL の到達と主要な記述を2026年9月17日に再確認しました。GitHub Copilot / Cursor / Amp / Windsurf / Kiro / Cline の Skills 対応は2026年9月17日に公式ドキュメントで確認しました。ローカルの CLI 版とプラグインキャッシュの観測は2026年9月17日時点のものです。

Claude Code / Claude

  • Claude Code Docs. How Claude remembers your project. CLAUDE.md の読み込み範囲と配置場所（managed policy を含む）、AGENTS.md は @AGENTS.md の import で読む仕様、.claude/rules/ のパス条件付き読み込み、import / symlink による共有、1ファイル200行以内の推奨、自動メモリが端末ローカルであること。
  • Claude Code Docs. Plugins reference. プラグインの構成要素（.claude-plugin/plugin.json、skills/、hooks/、.mcp.json、agents/）。
  • Claude Code Docs. Discover and install plugins. セッションが起動時の版を保持する仕様と、/reload-plugins による反映。
  • Claude Code Docs. Managed settings / Server-managed settings. 組織が配る設定層の配置と、MDM を使わない配布方式（claudeMd キー、起動時と1時間ごとの取得、claude doctor での確認）。
  • Claude Code Docs. Settings reference. enabledPlugins / extraKnownMarketplaces / strictKnownMarketplaces / allowManagedHooksOnly / strictPluginOnlyCustomization の説明。
  • Claude Help Center. Manage plugins for your organization. 組織のプラグインディレクトリ、GitHub 同期が Private / Internal 限定であること、Required などの配布設定。
  • Agent Skills. agentskills.io. Anthropic が策定した Skills の公開仕様。

OpenAI Codex / ChatGPT

  • OpenAI Developers. Package your plugin. 正式なプラグイン形式（フォルダ直下の plugin.json、.codex-plugin/ の互換フォールバック）。
  • openai/codex（GitHub）. codex-rs/exec-server-protocol/src/protocol.rs. プラグイン定義ファイルの探索パスに .claude-plugin/plugin.json が含まれる実装。
  • OpenAI. Plugins. ChatGPT と Codex が同じプラグインカタログを使うこと、IDE 拡張では使えないこと。
  • OpenAI. Hooks. 実行される hooks の種類（コマンド型・MCP ツール型）。
  • OpenAI. Plugin management / Skill controls. ワークスペース管理者による marketplace のインポートと Available / Installed の配布設定、適用範囲。
  • OpenAI. Managed configuration. 端末側の管理設定（取得元の許可リスト、管理 hooks のみ許可）。
  • Agent Plugins. agent-plugins.org. プラグイン形式の標準化の動きと、初期の技術運営委員会の構成。

他ツール

  • GitHub Docs. About agent skills / Copilot CLI plugin reference / About enterprise plugin standards. Agent Skills 仕様への対応（.claude/skills も読む）、Claude Code 形式の互換読み込みと、Enterprise の managed-settings.json による既知 marketplace と既定有効プラグインの定義。
  • Cursor Docs. Skills / Plugins / Rules. Agent Skills 標準への対応（.claude/skills/ は互換読み込み）、Team Marketplace の Required 設定と Team Rules の強制。
  • Gemini CLI Docs. Extensions reference / Skills. 拡張機能の形式と Agent Skills 対応。
  • Amp Docs. Skills. SKILL.md 形式のスキルの置き場所（.claude/skills/ も読む）と、ワークスペース管理者が管理するスキルリポジトリ（Agent Skills 標準への言及は無い）。
  • Windsurf Docs. Skills. Agent Skills 仕様への参照と、システム領域に置く企業向けスキル。
  • Kiro Docs. Skills. Agent Skills 標準への対応。
  • Cline Docs. Skills. SKILL.md 形式のスキルの置き場所（Agent Skills 標準への言及は無い）。

フィールフロウ

  • feel-flow/ff-dev-toolkit（GitHub、Public、Apache-2.0）. インストール手順と、組織のプラグインディレクトリで配布する場合の注記。
  • 社内 marketplace feelflow-plugins（Private）の登録プラグイン数と、Codex CLI 0.153.2 / Claude Code 2.1.270 のプラグインキャッシュの内容は、2026年9月17日に筆者の環境で確認。