ひとことで言うと {#one-liner}
いまの OpenAI Plugins は、「ChatGPT と Codex で同じように見つけ・入れ・使える配布パッケージ」です（Plugins 公式ドキュメント）。
中身はだいたい次の組み合わせです。
Plugin
├── Skills（いつ・どう進めるかの手順）
└── MCP server（任意）
├── Tools / 構造化結果
└── UI resources（任意）前編の MCPとは何か で扱った「外部接続のエンジン」に、手順（Skills）と配布単位を載せたものがプラグインです。
「GPTのプラグインを作る」＝ 自分のドメイン知識とサービスを、会話の中にインストール可能な体験として届ける ことです。
プラグインの4つの形 {#four-shapes}
プラグインアーキテクチャ では、用途に合わせて形を選べます。
| 形 | 向いているとき |
|---|---|
| Skillsのみ | 手順・テンプレ・判断基準だけで足りる（既存ツールで完結） |
| MCPのみ | 自前サービス接続・認証・操作が本命で、追加の手順説明は薄い |
| Skills + MCP | 「この順番で、このツールを使え」と誘導したい |
| MCP + UI | 比較・編集・確認・地図など、見て触った方が明らかに良い |
ポイントは、最初から全部載せないことです。Skillsだけで勝てるユースケースは多く、MCPやUIは後から足せます。
ユーザー側で増えること {#what-users-get}
プラグインがあると、会話体験は次のように変わります。
- 発見・インストール
ChatGPT / Codex の共通ディレクトリから同じ一覧を見つけられる（配布の考え方） - 再現できるワークフロー
「会議のフォローアップ」「見積の取り方」など、毎回同じ品質の手順が走る - ライブデータと操作
在庫・価格・予約状況など、静的な知識では足りない情報を MCP 経由で取る - 必要なら画面
表・地図・編集フォームなど、テキストだけでは辛い部分だけコンポーネントを出す - ヘッドレスでも成立
UIなしでもツール結果だけで答えを返せる設計が推奨される
つまり「チャットにボタンを足す」だけではなく、手順・権限・最新データ・（任意で）画面までを一つの製品として届けられます。
作ると実現できること（具体例） {#concrete-use-cases}
抽象語を具体に落とします。
1. 社内／自社データの「対話フロント」
- JAN・型番から製品スペックと相場を返す
- 法人番号から会社概要を要約する
- FAQ・仕様書・公開カタログを Resources として読ませる
CDNTのようなデータ基盤は、まさに MCP ツール化しやすい領域です。
2. 読み取りを超えた「代行オペレーション」
- 見積リクエストの下書き作成
- チケット起票・社内フォームの一次入力
- 予約候補の列挙と、確定前の確認フロー
操作系は必ず権限・認可・「勝手に確定しない」設計が要ります（MCPの認可）。
3. 業界特化の「手順パッケージ」（Skills中心）
- 会議メモ → アクション抽出 → 顧客向けメール
- ダイス表記
3d6を解釈してツールを正しい回数呼ぶ、のような小さな特化体験 - ポリシー・テンプレ・禁止事項を
references/に置き、毎回同じ判断基準で動かす
Skillsは「モデルに手順を教える」部品です（Build skills）。
4. 比較・確認が必要な業務（MCP + UI）
- 候補商品の並べ比較
- スケジュールの編集
- 地図上での拠点選択
テキストで全部やらせるより、触れる方がミスが減る場面だけ UI を足します（UI追加）。
5. コマース（チェックアウト）
物販などでは、会話の中から購入導線を付けられます。
- 推奨は 外部チェックアウト（自社ドメインで決済）
- 保存済み支払方法の表示や、ChatGPT決済シートは用途・パートナー条件あり
詳細は Checkout API を参照。プラグイン＝即決済という意味ではなく、体験の最後に購入を乗せられる、という位置づけです。
6. 開発者向け（Codex側）
同じプラグインが Codex でも使えます。ライフサイクルフックなど実行環境依存の機能は、Webに入れただけでは動かない場合がある点だけ注意が必要です。
SkillsとMCPの役割分担 {#skills-vs-mcp}
混同しやすいので、切り分けを固定します。
| Skills | MCP | |
|---|---|---|
| 役割 | いつ使うか・手順・出力形式・やってはいけないこと | ライブデータ、認証、制御された操作 |
| 成果物 | SKILL.md と周辺ファイル |
Tools / Resources / Prompts |
| 単独で成立？ | はい（手順だけで足りるとき） | はい（接続が本命のとき） |
| 組み合わせ | 「このツールをこの順で呼べ」と誘導 | Skillsの指示どおりに実行 |
Skillsは トリガー条件（description）と手順の質 が勝負です。曖昧だと誤起動が増え、厳しすぎると起動しません。代表的な依頼・間接表現・不足入力・起動すべきでない依頼でテストするのが定石です。
任意UIとチェックアウト {#ui-and-checkout}
UIは必須ではありません。公式の方針ははっきりしています。
- まず テキスト／構造化結果だけで意味が通る ツールにする
- 比較・編集・確認・ナビが明らかに改善するときだけ UI
- ヘッドレス（画面なし）経路も残す
チェックアウトも同様で、「会話で選ぶ → 自社で払う」が当面の本流です。決済シート連携は対象が限られるため、最初からそこに依存しない設計が安全です。
公開・配布の位置づけ {#publish}
作っただけでは終わりません。提出・公開 ではだいたい次が求められます。
- 公開用のリスティング情報（名前・説明・ポリシーURLなど）
- Skills・MCP・スタータープロンプト・テストケース
- リモートMCPなら安定した公開 HTTPS エンドポイント
- 認証ありならレビュー用のデモ資格情報
- 組織／個人の検証や Apps Management 権限
ローカルだけのMCPは、そのままでは提出しにくいです。公開URLに載せるか、OpenAI側のローカル支援を使う必要があります。
ディレクトリに載ると、ChatGPTとCodexの両方から同じ製品として見つけてもらえる、というのが配布側のゴールです。
小さく始める順番 {#start-small}
実装の順番のおすすめです。
- ユースケースを1つに絞る（誰が、何を、どんな成功条件で）
- Skillsだけで試作（手順とテンプレが価値の中心ならここで十分なことも多い）
- 足りない接続だけ MCP 化（検索・取得・下書き作成など、スキーマを小さく）
- 誤起動とエッジケースを直す
- UIは最後（見て触る必要がある工程だけ）
- 提出用に HTTPS・ポリシー・テストケースを整える
「全部入りの巨大プラグイン」より、1つのはっきりした成果の方が審査も利用も通りやすいです。
関連記事 {#related}
- 前編: MCP（Model Context Protocol）とは何か
- 実装: MCPサーバー完全構築
- 公式: OpenAI Plugins / アーキテクチャ / 提出
