Codexを使い始めると、「Skills」「MCP」「プラグイン」という言葉をよく目にします。
どれもCodexの機能を広げる仕組みに見えるため、「結局、何が違うの？」「全部入れないと自動化できないの？」と混乱しやすいところです。
僕自身、noteやWordPress、メルマガの制作を仕組み化する中で、この3つを同じもののように考えていた時期がありました。しかし、役割を分けて考えると、構築の順番が一気に分かりやすくなります。
Skillsは仕事のレシピ、MCPは外部サービスへ渡る橋、プラグインは必要な機能をまとめた道具箱です。
この記事では、CodexのSkills・MCP・プラグインの違いを、専門用語をできるだけ使わずに解説します。後半では、僕がWordPress投稿やGmail通知にどう使っているか、初心者がどこから導入すればよいかも紹介します。
- Skills・MCP・プラグインの役割と違い
- それぞれが必要になる具体的な場面
- 3つを組み合わせた須賀の活用例
- 導入時に確認すべき権限と安全性
- 初心者におすすめの導入順序
Skills・MCP・プラグインの違いを最初に整理
最初に結論から整理します。3つの違いは「何を提供する仕組みか」で考えると理解しやすくなります。
| 仕組み | ひと言で表すと | 主な役割 |
|---|---|---|
| Skills | 仕事のレシピ | 正しい手順・判断基準・テンプレートを教える |
| MCP | 外部へ渡る橋 | ブラウザや外部サービス、社内データなどへ接続する |
| プラグイン | 道具箱 | Skillsや接続機能などをまとめて導入・配布する |
料理で例えるなら、レシピだけあっても材料や調理器具へアクセスできなければ料理は完成しません。反対に、立派な道具があっても作り方が曖昧なら、毎回違う仕上がりになります。
つまり、3つは競合する機能ではありません。役割の異なる部品を必要に応じて組み合わせる関係です。
↓繰り返し使う仕事ルールを保存するAGENTS.mdはこちら↓
CodexのAGENTS.mdとは何かを初心者向けに解説。配置場所、読み込み範囲、目的・入力・手順・完了条件・禁止事項の…
Skillsとは？繰り返す仕事をレシピ化する仕組み
Skillは、特定の仕事を安定して行うための指示、参考資料、必要に応じたスクリプトなどをひとつにまとめたものです。
OpenAI公式ドキュメントでは、Skillは基本となる「SKILL.md」に加え、任意でscripts、references、assetsなどを持てると説明されています。Codexは依頼内容とSkillの説明が一致すると、必要な指示を読み込みます。
Skillが向いている仕事
- 毎回同じ構成で記事を書く
- PowerPointを決められたデザインで作る
- 画像を指定サイズで生成する
- PDFやWord文書を作り、表示崩れまで確認する
- 決まった品質チェックを繰り返す
たとえば「WordPress記事を作るSkill」なら、文字数、HTML装飾、画像サイズ、検品項目をまとめられます。
Skillの価値はAIを賢くすることではなく、仕事の再現性を高めることにあります。
AGENTS.mdとの違い
AGENTS.mdは、そのプロジェクトやフォルダで守る基本ルールです。一方のSkillは、文書作成、画像生成、ブラウザ操作など、特定の作業方法を再利用するためのパッケージです。
「この部署では公開しない」がAGENTS.md、「WordPress記事をどう作り、どう検品するか」がSkill、と考えると分かりやすいでしょう。
Skillは必要なときだけ詳しい手順を読み込める
すべての作業手順を最初からプロンプトへ詰め込むと、本当に重要な条件が埋もれてしまいます。Skillは、最初に名前と説明を手掛かりとして示し、該当する仕事を行うときに詳しいSKILL.mdを読み込む設計です。
たとえば普段は記事作成だけを行い、PowerPointを頼まれたときだけ資料作成Skillを読む、といった使い分けができます。専門部署のマニュアルを、担当する日だけ書庫から取り出すようなイメージです。
ただし、Skillの説明が曖昧だと、必要なときに選ばれなかったり、関係のない依頼で呼び出されたりします。「何をするときに使い、何には使わないか」を短く明確に書くことが大切です。
MCPとは？Codexと外部サービスをつなぐ橋
MCPはModel Context Protocolの略で、AIモデルを外部のツールや情報へ接続するための共通規格です。
OpenAI公式ドキュメントでは、MCPによってCodexが第三者のドキュメントを参照したり、ブラウザやFigmaなどの開発ツールを操作したりできると説明されています。
Skillが「作業手順」を与えるのに対し、MCPは「作業に必要な手足や情報源」を与えます。
MCPが必要になる場面
- 外部サービスの最新データを読みたい
- Google Driveや業務システムの情報を取得したい
- ブラウザや開発ツールを操作したい
- 社内データベースへ決められた方法で問い合わせたい
ただし、接続しただけで正しい仕事が完成するわけではありません。「何を読み、どこまで変更し、最後に何を確認するか」という作業ルールは別に必要です。
読み取りだけか、書き込みも可能か、どのアカウントへ接続するかを確認してから利用しましょう。
MCPと通常のAPIは何が違う？
APIは、サービスごとに決められた方法でデータを取得・更新する仕組みです。MCPサーバーは、そのAPIや社内システムなどをAIが扱いやすい「ツール」として見せる役割を持ちます。
非エンジニアの方は、MCPを「さまざまな外部サービスをAIへつなぐ共通の差し込み口」と理解すれば十分です。ただし、接続先ごとの認証や利用制限がなくなるわけではありません。
外部サービス側のアカウント、OAuth認証、アクセスできるデータ範囲などは個別に確認が必要です。また、接続先の仕様変更や一時的な障害に備え、取得失敗と「データが存在しない状態」を区別するルールも役立ちます。
プラグインとは？機能をまとめて導入できる道具箱
プラグインは、CodexやChatGPTで使う機能を再利用可能な形にまとめたパッケージです。Skillsだけを含むものもあれば、GmailやGoogle Driveのような接続機能、MCPツール、ブラウザ拡張などを組み合わせるものもあります。
公式ドキュメントでは、プラグインはSkills、コネクター、MCPサーバー、ブラウザ拡張、フック、スケジュール用テンプレートなどを含められるとされています。
つまり、プラグインは新しい「役割」そのものではなく、必要な能力や接続をひとまとめにして導入・共有しやすくする器です。
プラグインが便利な場面
たとえばGmailを扱いたいとき、メール検索や送信の接続機能と、正しい操作手順を個別に用意するのは大変です。信頼できるプラグインなら、必要な部品をまとめて追加できます。
一方で、インストール前には提供元、要求権限、外部送信の有無を確認する必要があります。便利さと権限はセットで考えましょう。
プラグインはインストール後の確認も必要
プラグインを追加したら、いきなり本番データを扱わせるのではなく、小さなテストから始めます。読み取り結果が正しいか、意図しない書き込みを行わないか、失敗時にどこで止まるかを確認します。
また、プラグインが更新されると、利用できる機能や要求される権限が変わる可能性があります。定期的にインストール済み一覧を見直し、使っていないものは無効化または削除する運用も重要です。
「有名だから安全」「公式一覧にあるから何を任せてもよい」と決めつけず、自分の作業範囲に対して必要な権限かを判断しましょう。
3つの役割を比較すると迷わなくなる
「どれを使うべきか」で迷ったら、今足りないものを確認します。
- 手順が毎回ぶれる：Skillを検討する
- 外部データやサービスを扱えない：MCPやコネクターを検討する
- 複数人・複数環境へまとめて配りたい：プラグインを検討する
ここで注意したいのは、「プラグインを入れれば自動化が完成する」と考えないことです。道具を入れても、目的、入力、手順、完了条件、禁止事項が曖昧なら、期待する結果にはなりません。
僕のプロジェクトでも、最初に担当フォルダとAGENTS.mdを作り、出力形式を固めました。その後、画像生成やブラウザ操作、Gmail通知など、必要になった能力を追加しています。
よくある3つの勘違い
1つ目は「Skillを入れれば外部サービスを操作できる」という勘違いです。Skillは手順を提供できますが、接続や権限がなければ外部データを読むことはできません。
2つ目は「MCPを入れれば仕事の品質が上がる」という勘違いです。MCPは使える道具を増やしますが、記事の構成や確認基準までは自動で決めてくれません。
3つ目は「プラグインはSkillの別名」という勘違いです。Skillはプラグインに含められる構成要素のひとつです。プラグインには接続機能やMCPツールなども一緒に入る場合があります。
↓Codexが実際にどこまで仕事を進められるかはこちら↓
Codex Windowsアプリの始め方・使い方を初心者向けに解説。準備、サインイン、画面の見方、プロジェクトフォルダ、…
初心者におすすめの導入順はSkills→接続→プラグイン
初心者の方には、次の順番をおすすめします。
ステップ1：まず仕事をひとつ決める
「AIを自動化したい」では広すぎます。「記事の構成案を作る」「画像を600×400pxで作る」など、開始と完了が分かる単位にします。
ステップ2：手順をSkillまたはルールへ落とす
入力、手順、出力、確認項目を文章にします。最初は専用Skillを作らず、AGENTS.mdやルールファイルで試しても構いません。繰り返し使える形になったらSkill化します。
ステップ3：必要な接続だけ追加する
記事をファイルへ保存するだけならMCPは不要かもしれません。WordPressへ下書き保存したい、Gmailで通知したい、という段階で対応する接続を追加します。
ステップ4：再利用・配布したくなったらプラグインを検討する
自分だけで使う間は、個別のSkillや接続で十分です。チームへ配布したい、複数の能力を一括で導入したい場合にプラグインが役立ちます。
須賀の実例：記事作成からGmail通知までの組み合わせ
僕が作った「SUGA AI Content Engine」では、note、WordPress、メルマガ、SKY通信、コラム、Threadsを別部門として管理しています。
WordPress部門では、テーマ選定、SEO調査、タイトル、構成、本文、画像、内部リンク、メタ情報、品質確認、投稿という10工程に分けました。
この中で、AGENTS.mdとルールファイルが「部署の就業規則」、文書や画像のSkillsが「専門的な仕事のレシピ」、ブラウザ操作やGmail連携が「外部へ働きかける手足」という関係になっています。
- 公式情報と既存資料を調査する
- 決められたHTML形式で本文を作る
- アイキャッチとH2画像を生成する
- 内蔵ブラウザでWordPressへ入力する
- 公開せず下書き保存する
- 保存内容を再検品し、Gmailで完了を知らせる
最初から完成していたわけではありません。画像が入らない、ブラウザ接続が切れる、同じテーマが別媒体で重複するといった失敗を一つずつルールへ戻しました。
自動化の中心は特別なツールではなく、失敗を記録して次の手順へ反映する運用設計です。
同じ道具でも担当ごとに完了条件を変える
ブラウザ操作という同じ能力を使っても、note担当はnoteの下書き保存、WordPress担当はクラシックエディターへのHTML入力、メルマガ担当はマイスピーへの原稿登録が完了条件です。
そのため、僕は「ブラウザを使えるようにすること」と「各媒体で正しく作業を終えること」を分けて考えています。接続機能は共通化しても、仕事の手順や検品項目は担当別に持たせるわけです。
この分離をしておくと、接続方法を内蔵ブラウザから別の経路へ変えても、記事の品質基準や保存条件を作り直さずに済みます。
導入前に確認したい権限と安全性
外部サービスへ接続するほど便利になりますが、同時に確認すべき範囲も増えます。
権限は必要最小限にする
閲覧だけでよい作業に削除権限まで与える必要はありません。メール、カレンダー、ファイル、ブラウザなど、接続先ごとに何ができるのかを確認します。
公開・送信・削除には人の確認点を置く
僕のWordPress運用では、Codexは下書き保存までです。公開は僕が記事を確認した後に行います。メールも配信原稿を下書きへ入れ、実配信前に目視します。
接続が切れたときの復旧ルールを決める
再試行回数、代替ブラウザ、途中状態の保存場所、重複下書きを作らない条件を決めておくと、無人運転でも事故を減らせます。
必要最小限の権限・人が判断する最終操作・途中から再開できるチェックポイント。この3つを最初に決めておきましょう。
秘密情報をルールファイルへ書かない
パスワード、認証コード、APIキーなどをAGENTS.mdやSkillの参考資料へ平文で残すのは避けます。ルールには「ログイン済みの環境を使う」「認証が必要なら停止する」と書き、秘密情報そのものは安全な認証機構で管理します。
また、送信先や投稿先を固定する場合でも、本番実行前に対象を照合します。下書き保存のつもりで公開する、テスト宛てのつもりで全読者へ送る、といった事故を防ぐためです。
初心者が今日から始める3ステップ
最後に、これからCodexを使う方が今日からできることをまとめます。
- 繰り返している仕事を1つ選ぶ：記事構成、画像作成、メール下書きなど、小さな仕事で構いません。
- 作業手順を5項目で書く：目的、入力、手順、完了条件、禁止事項を明文化します。
- 外部接続は必要になってから追加する：まずローカルの成果物で試し、下書き保存や通知が必要になった段階で接続します。
Skills、MCP、プラグインは難しい専門用語に見えますが、考え方はシンプルです。
仕事のやり方を教えるのがSkills。外部へつなぐのがMCP。必要な能力をまとめて届けるのがプラグイン。
この違いが分かれば、流行している機能を片っ端から導入する必要はなくなります。今の仕事に何が足りないのかを見て、一つずつ追加していきましょう。
↓Codexを使った非エンジニア向けの活用例はこちら↓
非エンジニア向けのCodex活用法7選を実例で解説。ブログ、note、メルマガ、SNS、画像、PowerPoint、定期…
参考：OpenAI公式「Build skills」「Model Context Protocol」「Plugins」。機能や提供画面は変更される可能性があるため、導入時は公式の最新情報をご確認ください。