開発するプラグインの構成

MCP を利用するプラグインには、次の 3 つの構成要素があります。

• MCP サーバー。ツールを定義し、データを返し、認証やアクセス制御を行います。UI リソースがある場合は、その参照先を ChatGPT に伝えます。
• 任意のウェブコンポーネント。ChatGPT の iframe 内に表示されます。React を使っても、HTML、CSS、JavaScript だけでも構築できます。
• モデル。開発者が指定したメタデータに基づいて、プラグインのツールをいつ呼び出すかを判断します。

これらの構成要素にまつわる定型的な開発作業を任せると、Codex を効果的に活用できます。

• 公開するツールとメタデータの設計
• サーバーとウィジェットのひな形の作成
• ローカルで起動するためのスクリプトの設定
• 認証とデプロイに必要な変更の段階的な実装
• プラグインが ChatGPT で動作することを繰り返し確認できる検証手順の作成

プラグイン開発に Codex が適している理由

• MCP を利用するプラグインは、サーバー、任意の UI、モデルが判断して行うツール呼び出しに分けて開発できます。
• Codex へのプロンプトは、タスクが明確で、範囲が限定され、結果を容易に検証できるときに最も効果を発揮します。プラグイン開発はこの条件によく合います。
• スキルと AGENTS.md を使うと、繰り返し使える指示やプロジェクトのルールを Codex に伝え、それに沿って作業を進められます。

スキルのインストール方法と使い方については、スキルのドキュメントを参照してください。

使い方

前提条件

• 製品全体をチャットに移植しようとせず、まずはユーザーが達成したい主な目的を 1 つに絞ります。
• 技術スタックを先に決めます。サーバーには TypeScript または Python を使います。ウィジェットには React を使うか、HTML、CSS、JavaScript だけで構築します。
• ngrok や Cloudflare Tunnel など、開発中に HTTPS で接続する方法を決めます。
• 一部の設定では、MCP サーバーへの接続に以前の名称が使われています。ローカルでテストするときは、その名称を登録済みのサーバーを指すものとして読み替えてください。

1. プラグインで達成したい目的を具体的なもの 1 つに絞り、名前、説明、入力、出力が明確なツールを 3～5 個提案するよう Codex に依頼します。
2. 初版はデータを返すだけで十分か、ウィジェットが必要かを判断します。依存関係を追加する前に、リポジトリの既存の実装パターンに沿って MCP サーバーと、必要に応じてウィジェットのひな形を作成します。
3. ローカルの MCP サーバーを起動して HTTPS でアクセスできるようにし、ChatGPT のカスタム MCP サーバーの追加から接続します。ツールの利用を直接依頼する場合、間接的に必要とする場合、呼び出すべきでない場合を含む少数のプロンプトでテストします。
4. ChatGPT 内で基本の読み取りフローが安定して動作するまで、メタデータ、状態の扱い、structuredContent と _meta のペイロードを調整します。
5. ユーザー固有のデータや書き込み操作で必要な場合に限り、OAuth 2.1 を追加します。匿名で利用するフローや読み取り専用のフローはシンプルに保ちます。
6. 安定した /mcp エンドポイントを持つプレビュー環境をホスティングし、ストリーミングと UI アセットの配信を検証します。プラグインを共有または提出する前に、公開前のチェックリストを確認します。

プロンプトの例

この開発手順で効果的なプロンプトには、次の要素が含まれます。

• 明確な目的を 1 つ。プラグインを使ってユーザーが ChatGPT 内で何をできるようにしたいかを伝えます。
• 具体的な技術スタック。サーバーには TypeScript と Python のどちらを使うか、ウィジェットには React を使うか、軽量な構成にするかを指定します。
• 各ツールの役割。ツールごとに役割を 1 つに絞り、少数のツールを提案または実装するよう Codex に依頼します。
• 認証要件。初版は匿名で利用できればよいか、アカウント連携や書き込み操作が必要かを明示します。
• ローカル開発時の接続方法。ChatGPT から HTTPS でテストする際に使うトンネルやホスティング方法を指定します。
• 検証手順。実行するコマンド、テストに使うプロンプト、結果を確認するために報告してほしい内容を Codex に伝えます。

計画、実装、認証、デプロイ、提出、仕上げを 1 つの長いプロンプトで一度に依頼するのは避けましょう。作業を小さな段階に分けて進めます。

ひな形を作成する前のプラグイン設計

動作する初版のひな形の作成

基本フローの動作確認後の認証の追加

プラグインのデプロイとレビューの準備

公開前の確認事項

• プラグインの目的が、ユーザーにとってわかりやすいもの 1 つに絞られています。
• ツールは少数に絞られ、それぞれのメタデータ、入力、出力が明示されています。
• MCP サーバーがエンドツーエンドで動作し、簡潔な structuredContent を返します。ウィジェットだけが使うデータは _meta に格納されています。
• ウィジェットが必要な場合は、ChatGPT 内に正しく表示されます。
• カスタム MCP サーバーを ChatGPT に接続した状態で、ローカル環境での HTTPS 経由のテストを繰り返し実行できます。
• ツールの利用を直接依頼する場合、間接的に必要とする場合、呼び出すべきでない場合を含む少数のプロンプトでテストし、いずれも会話の流れとツールのペイロードが想定どおりです。
• 認証は、ユーザー固有のデータや書き込み操作で必要な箇所にのみ追加されています。
• プラグインを共有または提出する前に、デプロイ計画と公開前レビューの両方で、メタデータ、ツールのヒント、プライバシー、テスト用プロンプトを確認しています。

よくある落とし穴

• 製品全体を ChatGPT に移植するよう Codex に依頼してしまう。ユーザーが達成したい主な目的を 1 つに絞り、ツール 3～5 個と役割を限定したウィジェット 1 つを依頼しましょう。
• 最初から長いプロンプトで実装をまとめて依頼してしまう。計画、ひな形の作成、認証、デプロイ、レビューに分けて進めましょう。
• ツールの入出力仕様が明確になる前に UI を実装してしまう。まず公開するツールとレスポンスのスキーマを設計し、その後でウィジェットを作成しましょう。
• 公式ドキュメントによるグラウンディングを省いてしまう。$chatgpt-apps と $openai-docs を併用し、プラグイン開発の最新のガイダンスに沿ってひな形を作成しましょう。
• メタデータを後回しにしてしまう。ツールとパラメーターの説明を早い段階で書き、それを使って一連のテスト用プロンプトを再実行しましょう。
• 匿名で利用するフローや読み取り専用のフローを検証する前に認証を追加してしまう。まず基本のツール呼び出しが動作することを確認し、実際に必要なツールにだけ OAuth を追加しましょう。
• ChatGPT 内でテストする前にプラグインを完成と判断してしまう。ChatGPT にカスタム MCP サーバーを接続し、ツールのペイロードを調べて、実際の会話の流れを確認しましょう。