MicrosoftのBuild開発者カンファレンスでは、開発者がCopilotアプリケーションにカスタムコンテンツやアプリケーション統合を追加する方法について、その概要が明らかになりました。このアプローチにより、Copilotアプリケーションの関連性が高まり、開発者の成果が特定のタスクに集中し、軌道から外れる可能性が低くなるはずです。
GPT-4のような大規模言語モデルは、一度学習すると、焦点を維持するために追加のデータが必要になることを理解することが重要です。そのため、Microsoftの様々なCopilotは、GitHub、Power Platform、Microsoft Graph、そして最も明白なBingといった独自のデータソース上に構築されています。これは、幻覚やプロンプトのオーバーランのリスクを軽減する、概ね成功したアプローチですが、それでもなお、Microsoftが定義したAIプラットフォームへの制限を課しています。
現状、BingのCopilotはBingの検索データベースに関する質問にしか答えられません。膨大なデータ量ではありますが、ユーザーのファイアウォール内やユーザーが利用したいアプリケーションのデータに関する質問には答えることができません。これらの回答を他のアプリケーションに送り込み、追加の結果を使って出力をフォーマットしたり、ユーザーに代わってインタラクションを実行したりすることができません。ユーザーはBing Chatにニューオーリンズのおすすめレストランを教えたり、3日間の旅行の日程表を教えてもらうことはできますが、席を予約することはできません。
ジャンプ先:
- AI支援のためのプラグインの追加
- プラグインを素早く構築する
- プラグインをより良くする
- 既存のMicrosoft Teamsアプリをプラグインに変換する
AI支援のためのプラグインの追加
ここでプラグインが役に立ちます。追加のデータソースと新しいインタラクションを提供します。ユーザーは既にChatGPT用に構築されたプラグインを使用でき、Microsoftは新しいBingプラグインにも同じプラグインアーキテクチャを採用しています。当初はOpenTableとWolfram Alphaのサポートを提供し、Expedia、Instacart、Zillow、TripAdvisorなどのサービスのプラグインも今後追加される予定です。例えば、Instacartプラグインを使用している場合、Bingのメニューを買い物リストに簡単に変換し、さらに戸棚にない食材の配達注文を作成できます。興味深いことに、これらのプラグインにはChatGPT自体のプラグインも含まれています。
Microsoftはさらに一歩進んでいます。この共通プラグインモデルは、Microsoft 365のCopilotやMicrosoft EdgeブラウザのAIツールにも使用されています。LLMプラグインに共通モデルを採用することは非常に理にかなっています。一度コードを記述すれば、ユーザーの様々なアプリケーションで再利用できるようになります。
標準プラグイン アーキテクチャを使用すると、ユーザーは自分のコードを他のユーザーや組織に提供できるため、Salesforce アプリを Bing Chat と統合できるツールを構築した場合は、それを製品として販売したり、オープン ソースにして共有したりできます。
プラグインを素早く構築する
では、ユーザーはChatGPTプラグインをどのように構築するのでしょうか？プラグインとは、既存のアプリケーションAPIとChatGPT間のインターフェースであり、使用するAPIのマニフェストとOpenAPI仕様を備えています。Bing Chatサービスはオーケストレーションツールとして機能し、必要に応じてAPIを呼び出し、自然言語ツールを使用して応答をフォーマットします。
これらのツールを使えば、ユーザーは「第1四半期に成立した取引をすべて教えていただけますか？」と質問するだけで、Bing Chat を顧客関係管理システムに接続させ、売上データから必要な情報を取得してチャット応答として表示させることができます。その後、原材料の追加発注が必要かどうかを尋ねたり、別のプラグインをエンタープライズリソースプランニングプラットフォームにリンクさせて在庫レベルを確認し、必要な材料や部品の発注を承認するかどうかを尋ねたりといったフォローアップも可能です。
その結果、ユーザーが普段使用しているアプリケーションでの作業をサポートし、インタラクションを調整し、複雑なタスクをマイクロワークに変換して、他のタスクに深く取り組むことができるようになります。
既存のAPI定義と標準定義フォーマットを基盤とした拡張機能を構築することで、開発が簡素化されます。ユーザーがREST APIのOpenAPI定義をまだ構築していない場合は、Postmanなどのツールを使用して自動生成できます。OpenAPI定義の説明フィールドは、BingやChatGPTがクエリの前後にテキストを生成し、使用するAPIの選択を支援するのに役立ちます。生成されたプラグイン定義はLLMのプロンプトに追加されます（チャットUIからは非表示）。ただし、プラグインはコンテキストにカウントされ、トークンを消費します。プラグインはユーザーが直接呼び出す必要があるため、すべてのクエリで使用できるわけではないことに注意してください。
まず最初に、YAMLまたはJSONでプラグインのマニフェストを作成します。ユーザーは、ドメインの最上位にある特定のフォルダに、定義済みの名前を付けてホストします。これにより、GPTホストが簡単に見つけることができます。OpenAIプラグイン仕様には、認証処理方法が含まれているため、認証されたユーザーのみが内部APIにアクセスできるようにすることができます。OpenAPI記述を使用すると、ユーザーはAPI定義を編集して不要な呼び出しを非表示にできるため、GPTによるAPIへのアクセスを制限できます。例えば、更新と削除の機能を持つAPIに対して、読み取りのみを許可するといったことが可能です。
プラグインをより良くする
プラグインはBingやChatGPTにデータを追加するのではなく、出力に方向性と焦点を当てるものであり、ユーザーからのリクエストがあった場合にのみ実行され、元のクエリへの応答の一部であるデータのみを返します。ユーザーは自然言語による応答を返さないようにする必要があります。GPTモデルはAPIからのデータに基づいて独自の応答を生成します。
プラグインマニフェストの便利な機能の一つに、「モデルの説明」属性があります。これにより、API記述から生成されるプロンプトをユーザーが調整し、より多くの指示を追加できるようになっています。ユーザーはプラグインをテストする際に、この属性を使用してプラグインの使用方法をさらに細かく制御できます。ChatGPTは、リクエストとレスポンス（通常はJSON形式）を表示することで、プラグインをデバッグする方法を提供しています。これにより、AIがアプリケーションからどのようなデータを使用しているか、あるいはそのデータがどのように使用されているか、あるいは元のリクエストがどのように生成されたかを正確に把握することはできなくても、理解しやすくなります。
より複雑なプラグインは、ベクターデータベースと連携してドキュメントを抽出・利用できます。このアプローチは、ユーザーのドキュメントストアと連携する必要があるアプリケーションに最適です。これらのドキュメントストアは、埋め込みによる前処理とベクター検索によるインデックス付けが可能で、複雑なビジネス情報へのアクセスを高速化できます。これらの情報に基づいてドキュメントを生成し、最も関連性の高いコンテンツに基づいてテキストを構造化します。
既存のMicrosoft Teamsアプリをプラグインに変換する
もう一つの興味深い選択肢は、既存のTeamsメッセージ拡張機能をMicrosoft 365 Copilotと連携させることです。このアプローチにより、既存のTeamsボットにAIを迅速に追加し、ボットフレームワークを介してユーザーのWebサービスをCopilotにリンクできます。ここで最も重要なのは、アプリの説明とスキルパラメータが、拡張機能内のコンテンツリクエストと共にCopilot LLMプロンプトの構築に確実に使用されることです。出力は、チャットセッションに埋め込まれたアダプティブカードとして配信されます。拡張機能を改変して完全な会話型システムにし、ほとんどのMicrosoft Copilotの基盤となるGPT-4モデルを活用することも可能です。
Bingやその他のCopilotを拡張するというMicrosoftのアプローチは、今のところ良いものです。生成AIはまだ初期段階であるため、標準的なプラグイン形式を持つことは非常に理にかなっています。これにより、APIが複数のAIプラットフォームをサポートできるようになり、同じプラグインを何度も構築する必要性が軽減されます。ChatGPTで動作するコードは、Bing Chat、Microsoft 365、そしてMicrosoftが将来Copilot機能を追加するあらゆるプラットフォームで動作します。
