構築内容

MCP 対応の各プラグインは、次の3つの要素で構成されます：

• ツールを定義してデータを返し、認証を強制し、UI リソースの参照先を ChatGPT に示す MCP サーバーです。
• ChatGPT の iframe 内にレンダリングされる、必要に応じて追加できる Web コンポーネントです。React のほか、プレーンな HTML、CSS、JavaScript でも構築できます。
• 指定したメタデータに基づき、プラグインのツールを呼び出すタイミングを判断するモデルです。

これらの要素に関する反復的なエンジニアリング作業を Codex に任せると、特に効果的です：

• 提供するツールの構成とメタデータを計画します。
• サーバーとウィジェットをスキャフォールドします。
• ローカル実行用スクリプトを設定します。
• 認証とデプロイの変更を、対象を絞った工程に分けて追加します。
• プラグインが ChatGPT で動作することを実証する検証ループを作成します。

Codex との相性がよい理由

• MCP 対応プラグインは、サーバー、必要に応じた UI、モデル主導の ツール呼び出しという要素に明確に分けられます。
• Codex は、タスクが明確で範囲が限定され、 検証しやすい場合に最も効果を発揮します。これは、プラグイン構築作業によく当てはまります。
• スキルと AGENTS.md は、Codex がプロジェクトに即して作業するために必要な、再利用可能な指示とプロジェクトルールを提供します。

スキルのインストール方法と使用方法について詳しくは、こちらをご覧ください：スキルのドキュメント。

利用方法

前提条件

• 製品全体をチャットに移植しようとせず、まずはユーザーが得たい中核的な成果を1つに絞ります。
• 最初にスタックを決めます。サーバーには TypeScript または Python、ウィジェットには React またはプレーンな HTML、CSS、JavaScript を使用します。
• 開発中に使用する HTTPS 接続経路を決めます。たとえば、ngrok や Cloudflare Tunnel です。
• 一部の設定では、MCP サーバー接続に今も従来の用語が使われています。ローカルテストでは、 それらのラベルが登録済みサーバーを指すものとして扱ってください。

1. まずはプラグインで実現する成果を1つに絞り、明確な名前、説明、入力、出力を備えたツールを3～5個提案するよう Codex に依頼します。
2. v1 をデータのみで構成できるか、ウィジェットが必要かを判断します。その後、依存関係を追加する前に、リポジトリ内の既存パターンに従って MCP サーバーと必要に応じてウィジェットをスキャフォールドします。
3. MCP サーバーを HTTPS 経由でローカル実行し、ChatGPT の開発者モードで接続して、直接、間接、否定の各ケースを含む小規模なプロンプトセットでテストします。
4. ChatGPT 内で中核的な読み取りフローが安定して動作するまで、メタデータ、状態管理、structuredContent、_meta ペイロードを繰り返し調整します。
5. 匿名フローや読み取り専用フローを複雑にすることなく、ユーザー固有のデータまたは書き込み操作に必要な場合にのみ OAuth 2.1 を追加します。
6. 安定した /mcp エンドポイントを備えたホスト型プレビューを用意し、ストリーミングと UI アセットのホスティングを検証してから、プラグインを共有または申請する前にローンチチェックリストを確認します。

おすすめのプロンプト

このワークフローで効果的なプロンプトには、共通して次の要素があります：

• 明確な成果を1つ：プラグインを使ってユーザーが ChatGPT 内で何をできるようになるのかを示します。
• 具体的なスタック：サーバーで TypeScript と Python のどちらを使うか、ウィジェットで React を使うか軽量な構成にするかを指定します。
• 明確なツール境界：ツールごとに役割を1つだけ持つ少数のツールを提案または構築するよう Codex に依頼します。
• 認証の想定：初版を匿名で利用できるか、アカウント連携と書き込み操作が必要かを明記します。
• ローカル開発経路：ChatGPT での HTTPS テストに使用する予定のトンネルまたはホスティング経路を記載します。
• 検証手順：実行するコマンド、テストするプロンプト、結果を裏付けるために報告する情報を Codex に指示します。

計画、実装、認証、デプロイ、申請、仕上げを一度に求める巨大なプロンプトは避けます。代わりに、作業を小さなマイルストーンに分けます。

スキャフォールド前のプラグイン設計

最初の動作版のスキャフォールド

コアフローの動作確認後にのみ認証を追加

デプロイとレビューに向けたプラグインの準備

リリース準備

• プラグインで実現できることが 1 つに絞られており、ユーザーにとって明確です。
• ツールの数が抑えられ、メタデータ、入力、出力が明確に定義されています。
• MCP サーバーはエンドツーエンドで動作し、簡潔な structuredContent を返し、ウィジェット専用データは _meta に格納します。
• ウィジェットが必要な場合は、ChatGPT 内で正しくレンダリングされます。
• ChatGPT の開発者モードを使って、ローカル HTTPS テストを繰り返し実行できます。
• 直接・間接・ネガティブの各ケースを含む小規模なプロンプトセットで、会話フローとツールペイロードが想定どおりになることを確認できています。
• ユーザー固有のデータまたは書き込み操作で必要な場合にのみ、認証が追加されています。
• プラグインを共有または申請する前に、デプロイ計画とリリース準備レビューで、メタデータ、ツールヒント、プライバシー、テスト用プロンプトを確認します。

よくある落とし穴

• 製品全体を ChatGPT に移植するよう Codex に依頼すること。改善策：ユーザーが達成したい中核的な目的を 1 つ、ツールを 3～5 個、用途を絞ったウィジェットを 1 つ依頼します。
• 最初から大規模な実装プロンプトを使うこと。改善策：作業を計画、スキャフォールディング、認証、デプロイ、レビューの各段階に分けます。
• ツール仕様が明確になる前に UI を作ること。改善策：まずツールの構成とレスポンススキーマを設計してから、ウィジェットを作成します。
• 公式ドキュメントによるグラウンディングを省くこと。改善策：スキャフォールドが最新のプラグインガイダンスに沿うように、$chatgpt-apps と $openai-docs を組み合わせて使用します。
• メタデータを後回しにすること。改善策：ツールの説明とパラメーターのドキュメントを早い段階で作成し、それらを基にプロンプトセットを再実行します。
• 匿名または読み取り専用のフローを検証する前に認証を追加すること。改善策：まずツールのコアフローを動作させ、その後、実際に認証が必要なツールにだけ OAuth を追加します。
• ChatGPT 内でテストする前にプラグインが完成したと判断すること。改善策：MCP サーバーを開発者モードで接続し、 ツールペイロードを調べて、実際の 会話フローを検証します。