--- title: "DifyとChatGPT（OpenAI）を連携する手順｜プラグイン導入とモデル選定【2026年8月版】" url: "https://www.issoh.co.jp/column/details/2256/" published: 2024-05-22 updated: 2026-08-13 categories: ["AI"] publisher: "株式会社一創" --- # DifyとChatGPT（OpenAI）を連携する手順｜プラグイン導入とモデル選定【2026年8月版】 Difyの設定画面を開いてもモデルプロバイダーにOpenAIが並んでいない。Dify 1.0以降は、ここで手が止まります。モデルプロバイダーが本体から切り出され、使う前にプラグインとして導入する方式へ変わったためです。2024年頃に書かれた手順は、この最初の1段階がまるごと抜けています。 この記事ではDify 1.16.1とOpenAIプラグイン1.0.3を前提に、プラグインの導入からAPIキーの登録、ChatGPTと同じモデルの選び方、2026年内に停止するモデルの移行先、そしてDifyアプリをChatGPT側のコネクタとして公開する逆方向の連携までを、公式ドキュメントとプラグインの定義ファイルの記述に沿って整理します。 ## まとめ：導入はプラグインとAPIキーの2段階、モデルはchat-latestかgpt-5.6系から選ぶ 結論から置きます。Dify 1.xでOpenAIを使う手順は2段階です。「統合」から「モデルプロバイダー」を開いてOpenAIプラグインをインストールし、カードの「セットアップ」でAPIキーを登録します。APIキーはChatGPTの会話画面からは発行できません。プラグインのヘルプが指す発行先は`platform.openai.com/account/api-keys`、つまりOpenAI Platform側のアカウントです。 モデルは目的で分かれます。ChatGPTと同じ応答傾向を再現したいなら`chat-latest`、本番アプリで推論の深さやコストを制御したいなら`gpt-5.6-sol`などgpt-5.6系の実体IDです。そして2024年の記事どおりに`gpt-4o-2024-05-13`を指定したまま動かしている環境には期限があります。このスナップショットは2026年10月23日にAPIから削除されます。以下、設定項目と根拠を順に見ていきます。 ## Dify 1.xでOpenAI連携がプラグイン方式へ変わった経緯 ### モデルプロバイダーがプラグインへ切り出された時期と現行バージョン 2025年2月28日にリリースされたDify 1.0.0が転換点です。リリースノートは、拡張可能なツールとモデルをDify本体から分離し、プラグインとして導入できるようにしたと説明しています。0.x時代の「設定を開けば最初からOpenAIのカードが並んでいる」画面は、現在は存在しません。 2026年8月時点の版は、Dify本体が1.16.1（2026年7月28日リリース）、OpenAIプラグインが`langgenius/openai`の1.0.3です。プラグイン側は2026年7月10日のコミットで1.0系へ全面的に書き換えられ、8月4日にgpt-5.6-lunaとgpt-5.6-terraの単価修正を含む1.0.3が公開されています。Marketplaceでのインストール数は81万件を超えており、Difyでモデルを使う経路としては事実上の標準です。 ### OpenAI・OpenAI-API-compatible・Azure OpenAIの使い分け基準 Marketplaceには紛らわしい名前のプラグインが並びます。選び方は接続先で決まります。 - **OpenAI**（`langgenius/openai`）… OpenAI本家のAPIキーを持っている場合はこれです。対応するモデル種別はLLM・テキスト埋め込み・音声認識・モデレーション・音声合成の5つです。 - **OpenAI-API-compatible** … ローカルで動かしているLLMサーバーや、OpenAI互換のインターフェースを持つ他社サービスを繋ぐ場合に使います。 - **Azure OpenAI** … Azure上にデプロイしたモデルを使う場合の別プラグインです。エンドポイントとデプロイ名の指定方法が本家と異なります。 迷いやすいのは、社内プロキシを経由して本家APIを叩く構成です。この場合は互換プラグインへ乗り換える必要はありません。本家プラグインの認証フォームにAPI Base URLの欄があるため、そこを差し替えれば足ります。 ## OpenAIプラグインの導入とAPIキー認証の設定手順 ### APIキーの発行元と認証フォームの入力項目 手順は、ワークスペースの「統合」から「モデルプロバイダー」を開き、未インストールならその画面またはMarketplaceからOpenAIを導入し、カードの「セットアップ」を押して認証情報を入力する流れです。保存時にDifyが資格情報を検証してから有効化するため、キーが無効なら保存の時点で弾かれます。 プロバイダー認証（セットアップ）の入力欄は、プラグインの定義ファイルで5つに決まっています。 | 項目 | 必須 | 既定値 | 用途 | | -------------- | -- | ------------- | -------------------- | | API Key | 必須 | なし | OpenAI Platform発行のキー | | Organization | 任意 | なし | 組織IDの明示 | | API Base URL | 任意 | 本家に接続 | プロキシ経由の指定 | | Validate Model | 任意 | なし | 資格情報の検証用モデル名 | | API Protocol | 任意 | Responses API | Responses / Chat切替 | 4つ目のValidate Modelは見落としやすい欄です。プレースホルダーには`gpt-4o-mini`が例示されており、保存時の資格情報チェックにどのモデルを使うかを指定します。プロジェクトの権限設定で特定モデルしか許可していない環境では、ここを許可済みのモデル名にしないと、キー自体は正しいのに保存で弾かれます。なお「モデルを追加」から個別モデルを登録するときのフォームはこれとは別物で、Validate Modelを除いた4項目になります。 セルフホスト環境でOpenAIのカード自体が現れない、あるいはインストールが途中で失敗する場合は、キーの問題ではなくプラグイン基盤側の問題です。署名検証やパッケージ容量の制限が原因になりやすく、切り分け方は[Difyのプラグインがインストールできない原因と対処法【署名検証・容量・バージョン】](/tech/details/7098/)にまとめています。 ### API Base URLとAPI Protocolを変更する条件 この2つは、埋めなくてよい欄をむやみに埋めると事故になります。基準を持っておきます。 API Base URLは空欄が既定で、その場合はOpenAI本家へ直接接続します。中継プロキシ、社内のAPIゲートウェイ、リージョン別のエンドポイントを挟む構成になって初めて記入します。末尾の`/v1`は付けても付けなくても構いません。プラグインのREADMEに「The API base may be entered with or without the trailing `/v1`.」と明記されており、ここは表記ゆれで動かなくなる箇所ではありません。 API Protocolの既定値はResponses APIです。プラグインのヘルプは「Responses API is the default. Select Chat Completions only when required by a legacy model or compatible endpoint.」と書いており、Chat Completionsへ落とすのは互換エンドポイント側がResponses APIを実装していないときだけ、という設計思想が読み取れます。動かないから念のため切り替える、という使い方をする欄ではありません。切り替えで失うものは後述します。 ### ワークスペース既定モデルとカスタムモデルの追加 認証が通ったら、画面右上の「デフォルトモデル」でワークスペース全体の既定を決めます。設定できるのはシステム推論モデル・埋め込みモデル・Rerankモデル・音声-to-テキストモデル・テキスト-to-音声モデルの5種類です。 ここが後から効いてきます。公式ドキュメントは、モデルを明示していないアプリやノードはワークスペースの既定へフォールバックすると説明しています。アプリ側でモデルを変えたのに挙動が変わらない場合、最初に疑うのはこのフォールバックです。そのアプリがモデルを指定しておらず、既定を見ているだけという状態が考えられます。 定義済みの一覧に無いモデルを使いたい場合は、カードの「モデルを追加」から登録します。OpenAIプラグインはpredefined-modelとcustomizable-modelの両方の設定方式をサポートしているため、発表直後で一覧に載っていないモデルやファインチューニング済みモデルも、モデル名を直接指定して使えます。 ## ChatGPTと同じモデルを指すchat-latestの位置づけ 「ChatGPTと連携したい」の中身が「ChatGPTで得られるのと同じ応答をDifyでも出したい」である場合、それを満たす専用のモデルIDがあります。OpenAIのモデルドキュメントは`chat-latest`を「chat-latest points to the latest Instant model currently used in ChatGPT」と定義しています。ChatGPTで現在使われているInstantモデルを指すエイリアスです。OpenAIプラグインの定義済みモデル一覧にも含まれており、表示順はgpt-5.6系4種の直後に置かれています。コンテキストは400,000トークン（入力上限272,000、出力上限128,000）で、パラメータはtemperatureやtop\_p、presence\_penalty、frequency\_penaltyといったChat Completions系の項目を持ちます。 ただし業務アプリの本番モデルにこれを選ぶのは避けてください。公式が「スナップショットは定期的に更新される」と明記しているエイリアスであり、こちらが何もしなくても中身が入れ替わります。OpenAI自身も同じページで「We recommend leveraging GPT-5.6 for production API usage.」と、本番のAPI利用にはGPT-5.6を推奨しています。chat-latestが向くのは、ChatGPTでの手応えをDify上で再現できるか確かめる検証フェーズです。単価はgpt-5.6-solと同額なので、コスト面の利点もありません。 移行先を選ぶときは、Difyの一覧に並ぶ`gpt-5.6`もエイリアスである点に注意してください。このIDはリクエストを`gpt-5.6-sol`へ振り分ける別名で、指定した世代が固定されるわけではありません。実体を指したいなら`gpt-5.6-sol`を選びます。`gpt-5.5-2026-04-23`のような日付入りスナップショットまで固定する運用もできますが、5.6系には日付入りの定義がまだ無く、プラグインの定義済み一覧にも`gpt-5.6`と3種のバリアント（sol・terra・luna）しかありません。 ## Responses API既定化で使えるパラメータの範囲 1.0系への書き換えで、対応モデルの既定プロトコルがResponses APIになりました。これはプロトコルの内部事情にとどまらず、Difyの画面に出てくるパラメータの選択肢を変えています。gpt-5.6の定義を例に取ると、次の項目が並びます。 | パラメータ | 選択肢 | 既定 | 備考 | | ------------------ | ---------------------------------------- | -------- | ---------------------- | | reasoning\_effort | none / low / medium / high / xhigh / max | medium | 関数ツールと併用可 | | reasoning\_mode | standard / pro | standard | Responses APIのみ | | reasoning\_context | auto / current\_turn / all\_turns | auto | Responses APIのみ | | reasoning\_summary | auto | 未指定 | Responses APIのみ | | verbosity | low / medium / high | medium | 回答の詳細度 | | service\_tier | auto / default / flex / priority | auto | flexは低コスト、priorityは低遅延 | | enable\_stream | true / false | true | ストリーミング出力 | ここから、API ProtocolをChat Completionsへ落とす判断の代償が具体的に見えます。プラグインの実装は、Chat Completions経路に入るときreasoning\_summary・reasoning\_mode・reasoning\_contextの3つを検査し、値が入っていれば`requires the Responses API`というエラーで即座に弾きます。しかも判定は「空でないこと」なので、proに変えていなくても、yamlの既定値であるstandardが入っているだけで失敗します。切り替えるならこの3つを空にしてから、という順序になります。 影響はパラメータだけに留まりません。プラグインはChat Completions経由のエラーを検出すると「cannot use tools with reasoning enabled through the Chat Completions API」という案内を返し、API ProtocolをResponsesへ戻すよう促します。推論を有効にしたまま関数ツールを併用する構成が成立しないためです。ドキュメント入力も同様にResponses API側でしか受け付けません。DifyでAgentやワークフローのツール呼び出しを組んでいるなら、chatへの切り替えはそれらを止める選択になります。 reasoning\_summaryにはもう1つ前提があります。プラグインのREADMEは、推論サマリーを返す前にOpenAIが組織の認証（organization verification）を求める場合があると注記しています。設定を入れたのにサマリーが出てこないときは、パラメータではなくPlatform側のアカウント状態を確認してください。 reasoning\_contextのall\_turnsにも前提があります。過去の推論項目を再利用する指定なので、previous\_response\_idかConversation、あるいは完全な履歴の再送のいずれかで先行応答を渡す必要があります。Difyのワークフローで会話履歴の受け渡しを組んでいない状態で選んでも意図した効果は出ません。ノード単位の変数の引き回しは[Difyワークフローの基本機能と使い方の詳細](/tech/details/4679/)で扱っています。 ## モデル選定の判断材料と2026年の廃止スケジュール ### コンテキスト長と単価の実数比較 プラグインの各モデル定義に書かれたコンテキスト長と単価を並べます。単価は100万トークンあたりの米ドルです。 | モデル | コンテキスト | 入力 | 出力 | | ----------------- | --------- | ----- | ------ | | gpt-5.6-sol | 1,050,000 | $5.00 | $30.00 | | gpt-5.6-terra | 1,050,000 | $2.00 | $12.00 | | gpt-5.6-luna | 1,050,000 | $0.20 | $1.20 | | chat-latest | 400,000 | $5.00 | $30.00 | | gpt-5.4-mini | 400,000 | $0.75 | $4.50 | | gpt-4.1 | 1,047,576 | $2.00 | $8.00 | | gpt-4o-2024-08-06 | 128,000 | $2.50 | $10.00 | | gpt-4o-mini | 128,000 | $0.15 | $0.60 | この表をそのまま月額見積もりに使わないでください。gpt-5.6系4種の定義ファイルには、この価格が「入力272,000トークンまでの直接API呼び出しに対する標準レート」であり、キャッシュ読み出し・キャッシュ書き込み・リージョン別・ロングコンテキストの各レートは表現できていないという注記が入っています。実際、gpt-5.6-solの公式価格表はショートコンテキストが入力5.00ドル・出力30.00ドルなのに対し、ロングコンテキストは入力10.00ドル・出力45.00ドルと倍近い水準です。長いドキュメントを丸ごと投げるRAG構成では、表の単価と請求額がずれます。 選定の目安としては、社内ナレッジ検索のように入力が長く出力が短い用途なら入力単価の低いgpt-5.6-terraかgpt-5.6-luna、判断精度が要る用途ならgpt-5.6-solという分け方になります。gpt-4o系は単価が中位でコンテキストが128,000と一桁狭く、いま新規に選ぶ理由が見当たりません。 ### 停止日と推奨移行先の対応表 ここが2024年に構築したDify環境の実務上の期限です。OpenAIの廃止一覧に掲載されている停止日と移行先を抜き出します。 | 停止日 | モデルID | 推奨移行先 | | ----------- | --------------------- | ---------------- | | 2026年10月23日 | gpt-4o-2024-05-13 | gpt-5.6-sol | | 2026年10月23日 | gpt-4-turbo | gpt-5.6-sol | | 2026年10月23日 | gpt-4.1-nano | gpt-5.6-luna | | 2026年12月11日 | gpt-5-2025-08-07 | gpt-5.6-sol | | 2026年12月11日 | gpt-5-mini-2025-08-07 | gpt-5.6-terra | | 2026年12月11日 | gpt-5-nano-2025-08-07 | gpt-5.6-luna | | 2026年12月11日 | o3-2025-04-16 | gpt-5.6-sol | | 2026年12月11日 | o3-pro-2025-06-10 | gpt-5.6-sol（pro） | | 2027年1月20日 | gpt-4o-audio | gpt-audio-1.5 | | 2027年1月20日 | gpt-4o-realtime | gpt-realtime-2.1 | o3-proの「pro」はgpt-5.6-solを`reasoning_mode`のproで使う意味です。gpt-4o-mini-audioとgpt-4o-mini-realtimeも同じ2027年1月20日に止まります。 プラグイン側の追随は一様ではありません。1.0.3の定義済みLLMは40件で、エイリアスの`gpt-4o`は既に削除済みです。残る4o系は`gpt-4o-mini`、`gpt-4o-2024-08-06`、`gpt-4o-2024-11-20`、`gpt-4o-mini-2024-07-18`の4件だけなので、2024年の解説記事どおりに「gpt-4oを選ぶ」ことはもうできません。逆に`gpt-4.1-nano`は2026年7月21日のコミットで定義済みモデルへ復活登録されており、10月23日に止まるのに一覧から選べます。プラグインに載っている＝当面使える、とは読めない状態です。 移行の進め方には順序があります。ワークフローのLLMノードを片端から開いて確認するより、先にワークスペースの「システム推論モデル」を移行先へ切り替えるほうが早く終わります。モデルを指定していないアプリとノードはこの既定に追随するので、残る作業は明示指定しているノードの洗い出しだけ。棚卸しの範囲がここで一気に狭まります。 ## 連携が失敗するときの切り分け順序 「連携できない」の原因はプラグイン基盤・キー・モデル指定の3層に分かれます。上から順に潰します。 **第1層はプラグインです。**モデルプロバイダーの一覧にOpenAIのカードが無ければ、キーの話に進む前にインストールが済んでいません。セルフホストで導入自体が失敗する場合の原因は署名検証やパッケージ容量が中心です。 **第2層はキーです。**Difyを経由せず直接叩いて、キー単体で通るかを先に確定させます。 ``` curl https://api.openai.com/v1/responses \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"gpt-5.6-sol","input":"ping"}' ``` モデル名はプロジェクトで利用を許可しているものに置き換えてください。権限外のモデルを指定すると、キーが有効でも権限エラーになり切り分けの意味がなくなります。これが失敗するならDify側の設定は無関係です。逆にここが通るのにDifyの保存で弾かれる場合は、Validate Modelに権限外のモデルを書いていないか、API Base URLの記入ミスか、プロキシがDifyのコンテナから見えていないかの順に疑います。Difyは資格情報を検証してから有効化する仕様なので、保存できた時点でキー自体は生きています。 **第3層はモデル指定です。**保存は通るのにアプリの実行だけが失敗する場合、指定しているモデルIDが定義済み一覧に存在しないケースが大半です。廃止済みのスナップショットや、プラグインがまだ取り込んでいない新モデルが該当します。「モデルを追加」からカスタムモデルとして登録すれば通ります。互換エンドポイント経由で、かつ相手がResponses APIを実装していない場合に限り、API ProtocolをChat Completionsへ切り替えます。その際は前述のとおり推論系3パラメータを空にし、関数ツールと推論の併用をあきらめる前提で構成を見直してください。 コンテナやストレージなど環境側に起因する不調は、この3層とは別に切り分けます。セルフホスト環境の構築手順は[AWS EKSにDifyを導入するための事前準備と環境構築のポイント](/tech/details/7097/)にまとめています。 ## DifyアプリをChatGPTのコネクタとして公開する逆方向の連携 ここまではChatGPTのモデルをDifyから呼ぶ方向でした。2026年時点では逆方向、つまりDifyで作ったアプリをChatGPTの会話から呼び出す構成も組めます。両者を繋ぐのはMCP（Model Context Protocol）です。 Dify側では、アプリをMCPサーバーとして公開できます。アプリごとに`server_code`が払い出され、公開エンドポイントは次の形になります。 ``` POST https://dify.example.com/mcp/server/{server_code}/mcp ``` ChatGPT側では、設定の「セキュリティとログイン」で開発者モードをオンにし、ChatGPTのプラグイン画面のプラスボタンから、リモートMCPサーバーを指す開発者モードのアプリ（従来カスタムコネクタと呼ばれていたもの）を作成します。対応トランスポートはSSEとストリーミングHTTP、認証はOAuth・認証なし・両者を組み合わせるMixed Authenticationの3方式です。Mixedは初期化とツール一覧の取得を無認証で通しつつ、個々のツールはメタデータの指定に従わせる方式で、社内向けDifyアプリを段階的に開放したい場合の中間解になります。対象は2026年8月時点でPro・Plus・Business・Enterprise・Educationのweb版ですが、条件は変わるため有効化前に公式を確認してください。 設計上の注意を1点。開発者モードのアプリは、登録したサーバーが公開するツールを書き込み系も含めて会話から呼べる状態にします。既定では書き込み前に確認ダイアログが入るものの、会話単位で承認を記憶させる操作ができ、記憶させた後は無確認で実行されます。OpenAIのドキュメント自身が、この機能を強力だが危険（powerful but dangerous）と書き、プロンプトインジェクションに注意すること、承認の記憶は信頼できるアプリに限ることを求めています。社外から到達できるDifyのエンドポイントを認証なしで登録する構成は避け、OAuthを挟むか公開範囲をネットワーク側で絞ってください。 MCPをDifyのツールとして使う側の実装例は[Playwright MCPとは？設定・使い方からDify連携まで実務ガイド【2026年版】](/tech/details/6172/)で扱っています。 ## よくある質問 ### モデルプロバイダーにOpenAIが表示されないのはなぜですか？ Dify 1.0でモデルプロバイダーが本体から分離され、プラグインとして導入する方式に変わったためです。「統合」から「モデルプロバイダー」を開き、その画面またはMarketplaceからOpenAIプラグインをインストールすると、カードが表示されて「セットアップ」に進めるようになります。インストール操作自体が失敗する場合は署名検証や容量制限が原因のことが多く、[Difyのプラグインがインストールできない原因と対処法【署名検証・容量・バージョン】](/tech/details/7098/)で対処法を整理しています。 ### ChatGPTで使っているアカウントのままAPIキーを発行できますか？ ChatGPTの会話画面からは発行できません。OpenAIプラグインのヘルプが指す発行先は`platform.openai.com/account/api-keys`で、OpenAI Platform側で発行したキーを使います。利用料はモデルごとのトークン単価で計上され、gpt-5.6-solなら100万トークンあたり入力5.00ドル・出力30.00ドルです（入力272,000トークンまでの標準レート）。 ### gpt-4oを指定したままのDifyアプリは動き続けますか？ 期限があります。GPT-4oは2024年5月13日に公開された、テキストと画像と音声を同じモデルで扱う世代のモデルですが、そのスナップショット`gpt-4o-2024-05-13`は`gpt-4-turbo`とともに2026年10月23日にAPIから削除される予定で、いずれも推奨移行先は`gpt-5.6-sol`です。加えて、OpenAIプラグイン1.0.3の定義済みモデル一覧にはエイリアスの`gpt-4o`自体が残っておらず、新規に選ぼうとしても候補に出てきません。 ### ローカルLLMやOpenAI互換のプロキシをDifyから使うにはどうしますか？ OpenAI-API-compatibleプラグインを使うか、本家プラグインの認証フォームでAPI Base URLを互換エンドポイントに差し替えます。相手がResponses APIを実装していない場合のみ、API ProtocolをChat Completionsへ切り替えてください。その場合はreasoning\_summary・reasoning\_mode・reasoning\_contextの3パラメータが`requires the Responses API`で弾かれ、既定値のstandardが入ったままでも失敗します。推論を有効にしたまま関数ツールを併用することもできません。 ### アプリごとにモデルを変えたのに挙動が変わらないのはなぜですか？ そのアプリやノードがモデルを明示指定しておらず、ワークスペースの既定を見ている可能性が高いです。公式ドキュメントは、モデルを選んでいないアプリとノードはワークスペースの既定へフォールバックすると説明しています。右上の「デフォルトモデル」でシステム推論モデルを確認してください。ワークフロー上のノード単位の設定は[Difyワークフローの基本機能と使い方の詳細](/tech/details/4679/)で解説しています。 ## 関連記事 - [Difyのプラグインがインストールできない原因と対処法【署名検証・容量・バージョン】](/tech/details/7098/) - [最近話題の「Dify」で社内チャットボットを作成しよう！概要と魅力](/tech/details/2758/) - [Difyワークフローの基本機能と使い方の詳細](/tech/details/4679/) - [Playwright MCPとは？設定・使い方からDify連携まで実務ガイド【2026年版】](/tech/details/6172/) - [AWS EKSにDifyを導入するための事前準備と環境構築のポイント](/tech/details/7097/) --- 出典: [DifyとChatGPT（OpenAI）を連携する手順｜プラグイン導入とモデル選定【2026年8月版】]()（株式会社一創）