CodexのPluginsとMCPの違い｜連携の注意点

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

Codexに外部ツールをつなぎたいと思って調べると、Plugins、MCP、Skillsという言葉が並びます。プラグインを入れれば使えるのか、MCPサーバーの設定が必要なのか。さらに、CLIでは使えたのに別の環境では見つからないとなると、どこから確認すればよいか迷いますよね。

この記事では、CodexのPluginsとMCPの違い、外部連携を選ぶ基準、公式ドキュメントを読む小さな導入例、認証や接続エラーの確認方法を整理します。2026年10月9日に確認したOpenAI公式資料とXの公開投稿をもとにした調査記事です。私自身の導入体験や時短の実測ではなく、業務例は説明用として示しています。

記事のポイント

• Skills・Plugins・MCPの役割を区別できる
• 外部連携と既存CLIを目的から選べる
• 登録・接続・ツール呼び出しを順に確認できる
• 動かないときの確認先と実行範囲が分かる

CodexのPluginsとMCPの違い

最初に整理したいのは、作業の手順、配布するまとまり、外部との接続という三つの役割です。違いが分かると、必要なものを一つずつ選べます。

Skills・Plugins・MCPの役割

Skillsは繰り返す仕事の手順、Pluginsは機能をまとめて導入する単位、MCPはツールや情報へ接続する仕組みと考えると整理しやすいです。たとえば週報を作る場合、何を調べ、どの形式でまとめるかという手順をSkillにします。社内の文書を検索する道具へつなぐ部分はMCPで提供でき、その手順と道具をチームで配りやすくまとめるのがPluginです。三つの名前が同じ画面に出てきても、それぞれの役割は異なります。

OpenAIの公式資料では、PluginはSkillsだけ、MCPサーバーだけ、または両方を含む構成を取れます。つまり、Pluginを入れたから必ず外部サービスへ接続するとは限りませんし、MCPを使うために自分でPluginを開発する必要があるとも限りません。週報の書式をそろえるだけなら手順の再利用で足りる場面もあります。先に必要な作業を決めると、機能名を一通り覚えるために立ち止まる時間を減らせますね。

また、Skillに「文書を検索する」と書いても、その文書へアクセスする権限が増えるわけではありません。使える検索ツール、対象アカウント、閲覧できるフォルダが必要です。逆に、検索ツールが接続済みでも、どの期間を調べて何を成果物にするかが曖昧なら、欲しい週報にはなりません。まず道具と手順を分けて確かめ、必要なところだけ組み合わせましょう。手順を作る部分は、CodexのSkillsの作り方と使い方で詳しく整理しています。

週報作成での役割の例

• Skill：対象期間、まとめ方、確認の順番
• MCP：文書検索や情報取得の道具との接続
• Plugin：必要な手順や接続機能をまとめた導入単位

「何をするか」と「どこへアクセスできるか」の両方がそろって、実際の作業へ進めます。

MCPが向く仕事とCLIで足りる仕事

MCPを使うか迷ったら、今の仕事にどんな道具が足りないかを考えましょう。外部の文書を検索する、デザイン情報を取得する、テストの結果を受け取るといった作業では、対応するツールをCodexから呼べると便利です。ただし、すでに使い慣れたCLIで同じ結果を取得できるなら、それを続ける選択もあります。MCPの導入そのものを目標にせず、欲しい情報へ迷わず到達できるかを基準にしたいですね。

たとえばリポジトリ内のファイルを探すだけなら、手元の検索コマンドで十分なことがあります。わざわざ別の検索サーバーを立てると、起動方法や認証など、確認する場所が増えます。一方、権限付きの社内文書を検索したい場合は、単なるファイル検索では届かないため、接続先に合った道具が必要です。表はどちらが優れているかの評価ではなく、この記事で提案する選び方です。作業の場所と情報源が決まれば、候補を絞れます。

比較するときは、同じ小さな仕事で結果を見ましょう。「指定した文書から更新日と要点を三つ取得する」など、成果物をそろえるのがおすすめです。結果の正確さ、出典を追えるか、エラーが分かるか、設定を維持できるかを確認します。新しい連携が増えたから作業が必ず速くなる、という保証はありません。必要な機能を一つ加えて、今の方法より扱いやすくなるかを確かめてから広げる方が、導入の手間を判断しやすくなります。

選ぶ前に書き出す三つ

• 取得したい情報は何か
• 現在の道具で取得できるか
• 新しい接続の保守を誰が行うか

同じ結果を得られるなら、確認しやすい方法を残してよいと思います。

Xの利用例と比較意見を読む

Xの公開投稿では、MCPを使ってCodexへ専門的な道具を渡す紹介が見られます。2026年10月9日に確認したLuan Gomesさん（@99LuanGomes）の投稿は、REAという調査用MCPの紹介でした。catmanさん（@catmanyau）の返信では、Maestro MCPとYAMLによるUIテストが取り上げられていました。これらは、コードを生成するだけでなく、調査やテストへ接続する用途を考える材料になります。ただし、投稿だけで製品の互換性や実際の効果を保証することはできません。

別の観点として、4月11日付のKyutaroさん（@kyutaro15）の投稿には、CLIのフラグをモデルが選びやすいという比較意見がありました。これは個人の考えで、すべての仕事でCLIが優れると示す実験結果ではありません。それでも「すでに明確なコマンドで扱える道具まで、MCPへ移す必要があるのか」という問いは役立ちますね。前の節の判断表も、こうした反論を踏まえ、目的に合う方法を選ぶために用意しています。

今回、接続エラーや動かないケースも検索しましたが、現行CodexのPlugins・MCPで再現できる失敗手順までは取得できませんでした。古い設定や別製品の話を現在の不具合としてまとめるのは避け、後半では公式に示された設定項目を使って確認の順番を提案します。Xの観察は少数の紹介と意見であり、普及率、成功率、時短の実測ではありません。試す候補を見つけるときに利用し、導入条件は提供元の最新資料で照合してください。

投稿から読み取る範囲

• 活用紹介：どんな仕事へつなぐかの参考
• 比較意見：今の道具で十分か考える材料
• 失敗報告：環境と再現手順が分かる範囲で確認

紹介されたツールをこの記事で実機検証したわけではなく、osuke本人の利用実績としても扱っていません。

Pluginsを選ぶときの確認点

Pluginを選ぶときは、名前や紹介文に加えて、今回の仕事に必要な機能が入っているかを見ます。たとえば文書の要約が目的なら、対象文書を検索できるか、本文を取得できるか、出典を残せるかが重要です。「業務を自動化できる」という説明だけでは、欲しい情報へ到達できるか分かりません。まず一つの仕事を決め、その入力と結果に対応する機能があるかを詳細ページで確かめましょう。

次に、自分が使う画面で対応しているかを確認します。確認日時点の公式資料では、Pluginの導入先としてデスクトップアプリやCodex CLIが案内され、IDE拡張ではPluginsが利用できない旨が記載されています。IDE拡張のMCP対応とは別の話です。画面や提供条件は変わるため、これを永久的な制限と考えるより、使う環境の現行表示で確認するのがよいですね。「同じCodexなのに見つからない」場合は、先に利用環境を比べます。

外部アカウントへつなぐPluginなら、接続するサービスとアカウントも見ます。個人用の文書を調べたいのに会社アカウントへ接続すると、結果が違うだけでなく、扱う情報の範囲も変わります。初回は公開資料やテスト用の文書など、対象を確認しやすい仕事が向いています。提供元、対応環境、必要な接続、利用する機能をメモしておくと、あとで見直しやすくなります。便利そうなPluginを一度に増やすより、一つの仕事で使えるかを確かめましょう。

導入前の確認メモ

• 目的：どの仕事を完成させるか
• 機能：検索、取得、更新のどれが必要か
• 環境：今使うアプリやCLIで対応しているか
• 接続：どのサービスとアカウントを使うか
• 保守：提供元の更新情報を確認できるか

必要な機能が分からない場合は、まず読み取りだけの依頼へ絞ると判断しやすくなります。

ローカルとクラウドの接続先

ローカルで使えた道具をクラウドでも使いたい場合は、どこでサーバーが動き、どこにデータがあるかを確認します。公式のMCP資料では、ローカルのプロセスとして動くSTDIO方式と、URLで接続するStreamable HTTP方式が説明されています。自分のパソコン内のプロセスやファイルは、別の実行環境から同じように見えるとは限りません。接続方式の名前より、実際の呼び出し元と情報源の場所を把握することが先です。

たとえば、手元のフォルダに置いた議事録を読む道具と、共有サービス上の議事録を読む道具を考えます。前者はローカルのフォルダへ届く必要があり、後者はサービスへの認証と対象文書のアクセス権が必要です。どちらも「議事録を読む」作業ですが、接続の条件は違います。作業を移したときに結果が空になっても、すぐデータが消えたと判断せず、その環境から同じ情報源へ届くかを確認してください。

また、設定の共有と接続の成功は分けて考えます。公式資料では同じCodexホストのローカルクライアント間でMCP設定を共有する仕組みが案内されていますが、外部アカウントの権限やクラウドでの接続条件まで無条件に同じになるわけではありません。この記事では、作業環境を変えたら一件だけ読み取りを試し、元の環境と同じ文書が取れるかを確認する方法を提案します。取得できた情報源を示してもらえば、違うフォルダを読んでいる行き違いにも気づきやすいですね。

作業場所を変えるときの確認

• 呼び出し元：ローカルかクラウドか
• サーバー：どこで動いているか
• 情報源：ファイルか外部サービスか
• 認証：その環境で対象アカウントへ接続できるか

移行後は、一件の取得結果と出典で接続先を確かめます。

CodexのPluginsとMCPを使う手順

ここからは、導入を小さく試す方法と、途中で止まったときの確認先です。設定できたことに加えて、目的のツールが実際に呼び出され、必要な情報を取れたことまで確かめます。

公式Docs MCPから小さく試す

最初のMCPは、取得する情報と結果が分かりやすいものを選ぶと試しやすいです。公式Docs MCPは、OpenAIの開発者ドキュメントを検索・取得する読み取り用のサーバーです。情報を読むための接続であり、OpenAI APIを代わりに実行するものではありません。記事の説明例には、OpenAI公式のDocs MCP導入ガイドにあるCLIでの追加方法を使います。既に登録済みの場合は、まず現在の一覧を確認してください。

codex mcp list

# 未登録の場合に追加する公式の例
codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp

# 登録内容を確認
codex mcp list

このコマンドは読者が試すための例で、今回の調査で利用環境へ設定を追加した実行記録ではありません。追加すると設定が変わるため、自分の使うCLIで実行することと、登録済みの同名サーバーがないことを確認します。また、一覧に名前が載った段階は登録を確認しただけです。次はCodexのセッションでツールを使い、公式ページから情報を取得できるかを確かめます。段階を分けておくと、設定と通信のどちらで止まったかが見えやすくなります。

試す依頼は、「OpenAI公式Docs MCPでMCPの対応接続方式を調べ、根拠のページと確認できた内容を示してください」のように、情報源と成果物を限定するとよいと思います。返されたリンクを開き、要約が本文に対応するかも見ます。一般的な知識から答えられただけでは、接続テストの完了にはなりません。ツールを呼べなかった場合は、そのことを報告してもらいましょう。成功の条件を一つの質問で確認してから、調査する範囲を広げます。

最初の接続テストの完了条件

• 対象サーバーが登録されている
• セッションで対象ツールを呼び出せる
• 取得した公式ページのリンクが分かる
• 要約と元のページを照合できる

名前が一覧にあることと、仕事を完了できることを順に確認するのがポイントです。

インストール後に接続を確認する

Plugin経由で導入する場合は、詳細を見て追加し、必要な外部接続を済ませ、新しい会話やセッションで確認する流れを取ります。確認日時点の公式資料では、CLIのPluginブラウザーは/pluginsで開き、導入後は新しいセッションから使うと案内されています。外部サービスへの認証が導入時に求められる場合も、初回利用時に求められる場合もあります。インストールの表示だけを見て、すべての道具が使えると判断しないようにしましょう。

たとえば共有文書を扱うPluginを入れたなら、最初に「テスト用の議事録を一件取得し、タイトルと保存場所を示す」と依頼します。認証できたか、目的のフォルダを見られるか、本文を取得できたかが分かれば、その後に要約を任せやすくなります。必要な文書が見つからないときは、検索条件が狭すぎるのか、違うアカウントなのか、対象への権限が足りないのかを比べます。何も返らなかったことだけでは、原因は決まりません。

継続して使うなら、接続先をメモしておくと便利です。「業務用アカウント、プロジェクトAのフォルダ、直近七日間、最大三件」のように書けば、次回の検索範囲をそろえられます。これはこの記事で提案する依頼の作り方で、Pluginが自動的にその範囲へ制限されるという意味ではありません。実際のアクセス制御は接続先の権限で確認します。取得した文書の出典と、取得できなかった範囲を残すことで、週報に抜けがあっても後から確認しやすくなります。

架空の文書検索の依頼例

• 対象：プロジェクトAのテスト用フォルダ
• 期間：直近七日間
• 件数：最大三件
• 出力：タイトル、更新日、要点、出典
• 補足：取得できなかった範囲を明記

最初は変更や送信を含めず、取得結果を確かめる仕事に絞ります。

MCPが動かないときの切り分け

MCPが動かないときは、「登録されていない」「接続できない」「ツールが使えない」「対象データが取れない」を分けると確認先が絞れます。いきなり設定全体を書き換えるより、最初に失敗した段階を一つ見つけましょう。登録一覧にはあるのにセッションで見つからないなら、有効状態や使う環境を確認します。ツールが呼べても文書を取れないなら、検索条件や対象アカウントの権限へ進む、という順番です。

この表はエラーの原因を断定するものではなく、調べる順番の提案です。たとえば検索結果が空なら、存在が分かっているテスト文書のタイトルで一件だけ検索してみます。それも取れなければ、アカウントやフォルダの権限を確認しやすくなります。接続先が返すエラーの内容も重要ですが、共有する際は認証情報や文書本文を含めないようにしてください。必要なのは失敗した段階、対象ツール、発生時刻など、原因を追うための情報です。

公式設定には、サーバーの有効状態、ツールの許可・除外、起動時とツール実行時の待ち時間などがあります。ただし、時間を延ばせばすべて直るわけではありません。URLの間違いや不足する権限を、待ち時間で解消することはできないからです。値を変更する前に一つの確認結果を取り、変更後も同じ仕事で比較しましょう。接続先を無効にして元の方法へ戻せるよう、現在の設定を把握しておくことも大切です。承認そのものの仕組みは、Codexの権限とサンドボックスの注意点へ分けてあります。

切り分けで残す情報

• 利用環境と対象サーバー
• 失敗した段階とエラーの種類
• 変更した設定項目
• 同じテストを再実行した結果

複数の設定を一度に変えず、結果が変わった理由を追える状態にします。

書き込みを任せる前の判断

文書を読む作業から、共有サービスの更新や送信へ進む場合は、対象と変更内容を具体的にします。議事録の要約を作ることと、その要約をチームへ送ることでは、完了の意味が違います。最初は下書きを保存して内容を確認し、その後に送信先と件数を確かめる流れが分かりやすいですね。Pluginの接続や認証が済んだことを、その後のあらゆる操作への許可と受け取らないことが大切です。

架空の例として、三件の議事録から週報を作り、一つのチャンネルへ投稿する仕事を考えます。取得した三件が正しい対象か、抜けた文書がないか、宛先が正しいか、公開してよい情報だけになっているかを確認します。投稿する本文と宛先がそろえば、何を実行するかを具体的に判断できます。「週報をよろしく」だけで対象や送信先を推測させるより、完成した下書きを見て最後の操作を決める方が、利用者も結果を確認しやすくなります。

さらに、更新処理の結果が分からないときの扱いを決めます。返事が途切れても、サービス側では投稿済みの可能性があります。再実行前に投稿履歴や対象データを確かめ、結果不明のまま同じ操作を繰り返さない設計が必要です。これはMCP固有の保証ではなく、接続先の機能と運用で確認する内容です。公式のセキュリティ資料も、必要な権限に絞ることや、サーバー側で入力を検証することを説明しています。読めた情報に別の操作を促す文章があっても、依頼の範囲を広げる根拠にはしません。

週報の投稿前にそろえるもの

• 確認できる完成本文
• 対象のサービスと送信先
• 今回変更する件数と範囲
• 成功を確認する方法
• 結果不明の場合の確認先

依頼済みの範囲を明確にすると、必要な作業を進めながら最終結果を確かめやすくなります。

CodexのPluginsとMCPの要点

CodexのPluginsとMCPを使うときは、今回完成させたい仕事から必要な道具を選びます。Pluginsは機能をまとめて導入する単位、MCPは道具や情報へ接続する仕組み、Skillsは繰り返す手順です。この関係を押さえれば、機能を増やす前に、自分に足りないものを見つけやすくなります。まずは文書を一件取得するなど、小さな仕事で登録、接続、ツール呼び出し、取得結果の四段階を確かめましょう。

導入後に使えない場合も、失敗した段階が分かれば確認先を絞れます。サーバーを起動できないのか、認証が必要なのか、特定のツールが無効なのか、対象データの権限がないのかを順に見ます。ローカルからクラウドへ移す場合は、情報源と接続先が同じかも確認してください。Xの紹介は使い道を知る材料ですが、自分の環境の対応状況や不具合の原因を決める根拠には足りません。現行の公式資料と一件の取得結果を照合することが近道です。

今日試すなら、公式Docs MCPなど読み取り範囲が明確な道具で、質問を一つに絞るのがおすすめです。接続先、取得したページ、確認できた内容が分かれば、次にSkillへ組み込むか、Pluginでチームへ配るかを判断できます。既存のCLIで十分な仕事は、その方法を続けても構いません。Codex全体の作業の進め方から見直したい方は、Codexのできることと使い方の全体ガイドも確認してください。自分の仕事に合う一つの接続を、確かめながら育てていきましょう。

最初の一歩

1. 完成させたい仕事を一文で決める
2. 必要な読み取りツールを一つ選ぶ
3. 登録と接続の状態を確認する
4. 一件の取得結果と出典を確かめる
5. うまくいった手順を再利用できる形で残す

この五つがそろってから対象を増やすと、何を任せられるかが分かりやすくなります。