ChatGPTプラグインの理解

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
ChatGPTは、ユーザーの入力内容を理解し、応答できる強力な言語モデルです。多くの便利な機能が組み込まれていますが、標準では利用できない追加機能が必要となる場合があります。そこでプラグインの出番です。
プラグインは、ChatGPTの機能を拡張するアドオンです。ユーザーのリクエストに応じて、最新情報へのアクセス、計算の実行、サードパーティサービスとの連携を可能にします。例えば、特定のウェブサイト内の情報を検索する機能を追加したり、ユーザーのCRMソフトウェアと連携したりするプラグインが考えられます。
あるいは、ChatGPT用のカレンダープラグインは、ユーザーがチャットインターフェース内で直接イベントやリマインダーをスケジュールできるように機能します。例えば、ユーザーが「金曜日の午後2時にジョンと会議をスケジュールして」と入力すると、ChatGPTはその意図を認識し、カレンダープラグインと連携してイベントを作成できます。
0:00/1×
Instacart ChatGPTプラグインの活用事例
ChatGPT用のInstacartプラグインは、ユーザーがチャットインターフェースを離れることなく、レシピの材料をInstacartのカートに簡単に追加できる既存のプラグインです。例えば、ユーザーが「ラザニアを作るにはどんな材料が必要ですか?」と尋ねると、ChatGPTはラザニアに必要な材料のリストを提供し、それらをユーザーのInstacartカートに追加することを提案できます。ユーザーは簡単なクリックで注文を確定でき、Instacartプラグインは必要な材料すべてを自動的にカートに追加します。
プラグインの仕組み
プラグインを作成するには、開発者は自身のウェブサイトを通じてAPIを公開し、APIを標準化された方法で記述したマニフェストファイルを作成します。ChatGPTはこれらのファイルを読み取り、AIモデルが開発者によって指定されたAPIと通信できるようにします。一般的なプラグインには以下が含まれます。
- API、
- API用のOpenAPI JSONまたはYAML形式のスキーマ、
- JSON形式のプラグイン用マニフェストファイル。
ChatGPTは、マニフェストファイルとOpenAPIスキーマを使用して、プラグインが何をするのか、どのように連携するのかを理解します。ユーザーがChatGPTにプロンプトを出すと、リクエストを達成するためにアクティブなプラグインと連携する必要があるかどうかを判断し、ユーザーのリクエストを達成するために適切なエンドポイントを呼び出します。他の言語モデルにプロンプトを出すのと同様に、マニフェストとAPIスキーマで複数のプロンプトと記述を試して、何が最適かを確認することをお勧めします。
OpenAIは、PineconeのようなベクトルDBを検索し、関連ドキュメントを返すことができるサンプルプラグインのコードを提供しています。ユーザーのプロンプトに答える際、ChatGPTは、関連ドキュメントをクエリすることで、このプラグインを使用して知識を補完する場合があります。例えば、組織内では、ChatGPTは会社に関する質問に答えるために、社内文書をクエリする必要があるかもしれません。
このドキュメント検索プラグインの場合、という名前のマニフェストファイルは ai-plugin.json 次のようになります。

次のようなフィールドがあることに注目してください。 description_for_model と description_for_human。この description_for_model 属性を使用すると、モデルにプラグインの一般的な使用方法を指示できます。全体として、ChatGPTの基盤となる言語モデルは、自然言語を理解し、指示に従う能力が非常に高いです。したがって、ここはプラグインが何をするのか、モデルがそれを適切にどのように使用すべきかについての一般的な指示を記述するのに適した場所です。
プラグインのデプロイ
上記の検索プラグインをTrueFoundryにデプロイし、ChatGPTと連携させます。このプラグインは、Pineconeのようなベクトルデータベースを検索し、関連するドキュメントを返すことができます。
💡
プラグインを作成するには、ChatGPTプラグインへのアクセスが必要であることに注意してください。アクセスは こちらからリクエストできます。
GitHubリポジトリのクローン
このアプリケーションをデプロイするには、このリポジトリをクローンする必要があります。これは、デプロイされたプラグインアプリケーションのURLでOpenAPIスキーマとマニフェストを更新する必要があるためです。
ベクトルDBのセットアップ:Pinecone
Pinecone は、速度、規模、そして早期の製品化のために構築されたマネージドベクトルデータベースです。Pineconeをベクトルデータベースプロバイダーとして使用するには、まず アカウントを登録してAPIキーを取得してください。APIキーは、ダッシュボードのサイドバーにある「API Keys」セクションからアクセスできます。Pineconeはハイブリッド検索もサポートしており、本稿執筆時点ではSPLADEスパースベクトルをネイティブにサポートする唯一のデータストアです。
リトリーバルプラグインのPinecone版に関する完全なJupyterノートブックのウォークスルーは、 こちら。また、 こちらのビデオウォークスルー。
アプリを初めて実行すると、Pineconeインデックスが自動的に作成されます。インデックスの名前を選び、アプリケーションのデプロイ時に環境変数として設定するだけです。
TrueFoundryへのアプリケーションのデプロイ
それでは、TrueFoundryにアプリケーションをデプロイしましょう。
- で無料アカウントを作成し、 TrueFoundry 、ユニークな名前で新しいワークスペースを作成してください。
2. PineconeベクターDBを使用する際には、以下の環境変数が必要になります。ベアラートークンは、エンドポイントへのリクエストを認証するために使用されます。
名前必須説明DATASTOREはいデータストア名。pineconeに設定してください。BEARER_TOKENはいAPIへのリクエストを認証するための秘密トークン。OPENAI_API_KEYはいtext-embedding-ada-002モデルで埋め込みを生成するためのOpenAI APIキー。PINECONE_API_KEYはいPineconeコンソールで見つかるPinecone APIキー。PINECONE_ENVIRONMENTはいPineconeコンソールで見つかるPinecone環境(例:us-west1-gcp、us-east-1-awsなど)。PINECONE_INDEXはい選択したPineconeインデックス名。注:インデックス名は小文字の英数字または'-'で構成されている必要があります。
TrueFoundryの シークレットコンソールにアクセスしてください。新しい シークレットグループ を作成し、環境変数として使用するシークレットを作成します。

3. デプロイコンソールにアクセスしてください。ワークスペースで新しいサービスを作成します。
4. サービス作成フォームで、ソースをクローンしたばかりのリポジトリURLに、ビルドをDockerFileビルドに設定してください。
5. フォームでポートを8080に設定し、サービスに適したエンドポイントを選択します。

6. 環境変数を追加し、作成したシークレットに設定します。

7. デプロイすると、プラグインのウェブアプリとエンドポイントが デプロイタブに表示されます。ここで生成されたエンドポイントを使用して、OpenAIにプラグインを登録し、ChatGPTで使用します。

8. GitHubリポジトリに移動し、OpenAPIスキーマとマニフェストの両方でアプリケーションURLを更新します。これらは ./well-known フォルダにあります。更新後、TrueFoundryでデプロイを編集して最新のコミットに合わせ、 デプロイタブから再デプロイできます。

プラグインのテスト
API、マニフェストファイル、およびAPIのOpenAPI仕様を作成したら、ChatGPT UIを介してプラグインを接続する準備が整いました。
の場合、 ChatGPT UIまず「Develop your own plugin」を選択して設定し、次に「Install an unverified plugin」を選択して自分用にインストールします。
まず、APIサービスのエンドポイントを提供する必要があります。これはTrueFoundryの デプロイタブから取得できます。次に、APIリクエストの認証に使用するベアラートークンを提供する必要があります。これが完了すると、プラグインはChatGPTで使用できるようになります(未検証のため、あなたのみが使用できます!)。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.


















.webp)
.webp)


.png)

.png)














