OpenAIの開発チームがエージェントキットという新しい開発プラットフォームを発表した。このツールセットは、エージェントワークフローの構築、デプロイ、最適化を統合的に行える環境を提供する。エージェントビルダーではドラッグアンドドロップでビジュアルにワークフローを設計でき、チャットキットは事前構築されたUIコンポーネントを提供し、評価とトレーシング機能でワークフローの監視と最適化が可能となる。デモでは半導体トラックメーカーの保守問い合わせ対応システムを実例として、クラウドホスティングからセルフホスティングへの切り替え、そして評価システムによる継続的な最適化までを実演している。従来は数週間から数ヶ月を要した開発作業が、このプラットフォームにより数分から数時間で完結できるようになった点が強調されている。
エージェントキットの紹介
皆さんこんにちは、私はジェームズと申しまして、フォワードデプロイドエンジニアリングチームのテックリードを務めています。本日はエージェントキットをご紹介いたします。これは、エージェントワークフローを構築、デプロイ、最適化するための完全な構成要素のセットとなります。
今日のセッションでは、エージェントキットの3つの中核コンポーネントについてお話しします。1つ目はエージェントビルダーです。私たちのプラットフォームでは、キャンバス上にノードをドラッグアンドドロップして、ワークフローを視覚的に設計することができます。そして、それらを私たちのプラットフォーム上でホストして実行することも、コードとしてエクスポートして独自のスタック上で実行することもできます。
2つ目はチャットキットです。チャットキットは、エージェントワークフロー用の新しいフロントエンドとなります。ゼロからUIを構築する代わりに、チャットインターフェース、ストリーミング、カスタマイズ可能なウィジェットなどの事前構築されたコンポーネントを、アプリケーションに直接埋め込むことができます。
最後に、更新された評価とトレーシングのパターンをリリースします。トレーシングと評価はエージェントキットの第一級のコンポーネントであり、エージェントワークフローの監視と最適化が格段に簡単になりました。
実際のデモンストレーション
では、実際にこれを動かしてみましょう。私たちがセミトラックメーカーを運営していて、毎日何千もの保守に関する問い合わせを受けているとしましょう。エージェントキットを使って構築されたエージェントワークフローを実行して、保守エンジニアがこれらの問題を解決するのを支援します。
私たちの保守エンジニアが直接使用するために構築したアプリケーションに移動します。何を見ているのでしょうか。右側にはチャットインターフェースがあります。これはチャットキットを使って構築されました。
では、手を挙げていただきたいのですが、複雑なエージェントワークフロー用の動的なUIを構築したことがある方はいらっしゃいますか。はい、たくさんの手が挙がっていますね。では、それを一つのバグもなく本番環境にデプロイしたことがある方は。はい、手が少なくなりましたね。とても安心しました。
私と同じような経験をお持ちなら、これらの本当に複雑で動的なワークフロー用のUIを構築するのは非常に難しいことをご存知でしょう。しかし、チャットキットを使えば、それがただ動作するのです。事前構築されたコンポーネントを埋め込むだけです。そして、今日公開リリースしていますが、OpenAIはしばらくの間これを使用してきました。私たちのヘルプセンター全体がすでにチャットの上に構築されているのです。
右側にチャットインターフェースがあります。そして左側には、トラックブラザーズのロゴがあります。ロゴについて簡単に補足しますと、炎があるのはかっこいいからであって、トラックが火を噴いているわけではありません。念のため申し上げておきます。
これがロゴで、ワークフローを開始すると、これが消えて、ワークフローのさまざまなステップを視覚化するUIコンポーネントが表示されます。私たちが求めているのは、発見した保守上の問題を入力し、ワークフローを実行すると、保守エンジニアが従うべき一連の指示と、修理に必要なすべての部品が返されることです。
顧客から寄せられた問題を入力します。ミンラの燃費が非常に悪くなっているとのことです。ワークフローを送信できます。これで、エージェントキットで構築したワークフローに到達します。保守手順のすべてのファイルを検索して、最も関連性の高い手順を取得します。燃料フィルターの交換に関するこちらの手順が得られました。良さそうですね。問題はこれのようです。
次に、その手順に関連するすべての部品を見つけます。その手順IDに対して、燃料フィルターを交換するためのすべての部品のマッピングを取得しましょう。素晴らしい。部品が得られました。最後にガードレールを実行しましょう。このガードレールは、指示と部品が私たちが持っている実際のデータに基づいているかどうかをチェックしているだけです。
はい、それがクリアされたようです。結果がストリーミングで返されているのが見えます。低燃費に対処するには、これらの指示に従ってください、と書かれています。素晴らしい。部品のリストです。ここで部品を再確認できます。えーと、燃料サンプル瓶がここに記載されています。はい、良さそうです。指示は、ページ上の内容と一致しているようです。素晴らしい。
これは素晴らしく見えます。実行されましたが、出力があまり気に入りません。少し消化しにくいと感じますし、少し華やかさを加えましょう。エージェントビルダーに移動して、ワークフローを調整できます。
エージェントビルダーでの編集
今、プラットフォームにいて、これがエージェントビルダービューです。右側には、今実行したワークフローがあります。左側にはノードピッカーがあり、ここでLLMエージェントや、ファイル検索やMCPなどのツール、そしてwhileループやif else文のような論理ノードをドラッグアンドドロップして、ワークフローを分岐させることができます。
このワークフローを説明しますが、デモのために最後のいくつかのノードを削除して、それらを再構築します。入力から始まります。これは私がチャットに入力したテキスト入力、つまりこの場合は燃費が低いというような内容です。
それはクエリ拡張エージェントに直接送られます。これは単にクエリを拡張して、意味的にもう少し豊かにするだけで、より良い検索結果が得られます。そして、それをこのファイル検索ノードに送ります。
ファイル検索ノードでは、以前にすべての修理のPDFをOpenAIのホストされたベクトルストアにアップロードしており、トラックブラザーズの修理マニュアルを検索するだけです。クエリ拡張ステップから書き直されたクエリを入力し、上位の結果を取得します。
次にデータ変換を行います。これは本当に、取得したPDFから手順IDのメタデータを抽出するだけです。そして、それをMCPツールを使用するエージェントに渡します。これは単にGraphQLクエリを実行しているだけで、その特定の手順IDに関連するすべての部品を取得します。
MCPサーバーにアクセスし、それを合成エージェントに渡します。これは本当に、修理の方法に関する明確な指示のセットを返すことになっています。では、ガードレールを追加しましょう。これをドラッグして接続します。その入力は最後のノードからの出力、つまり出力テキストにします。
そして、ハルシネーションを選択します。同じベクトルストア、つまり修理マニュアルを配置します。任意のモデル、任意の信頼度閾値を選択できます。それで良さそうです。最後に、サマリーエージェントを配置します。これは最終的な応答を提供するだけです。
しかし、デブデイなので、このワンライナーを追加しています。少なくとも数語の巧妙なデブデイのダジャレを作って、もう少し視覚的に面白くしましょう。基調講演でウィジェットスタジオについて話していたのを知っています。事前にウィジェットを構築しました。
ウィジェットを選択します。ウィジェットをアップロードします。これは事前に構築してあります。簡単なプレビューを見ることができます。指示、修理の名前、そして必要な部品が表示されます。
そして、公開をクリックするだけです。これを公開して本番環境にデプロイします。そして、アプリに戻ってページを更新し、新しいプロンプトを入力できます。この場合、オイル警告灯が点灯したという別の質問を受けたとしましょう。
これを送信します。同じワークフローを開始しており、バックエンドで新しいホストされたワークフローを実行しているのがわかります。オイル警告灯に関連するファイルを検索しています。オイルレベルの確認のようなこのチェックオイル手順が返されました。
次に、その手順に関連するすべての部品を見つけます。MCPサーバーにアクセスする同様の作業です。はい。正しい部品を取得しました。良さそうです。そして、今追加したガードレールを実行しています。同じことです。これが根拠に基づいているかを確認するために、このハルシネーションガードを実行しています。
では、落ち着いてデブデイを楽しみましょう。ダジャレはあまり気に入りませんが、デブデイには言及しました。そして、指示のリストと、エンジンオイルディップスティックや流体補充用じょうごなどの必要な部品があるのがわかります。はい、これは正しいようです。
素晴らしい。これで良いと思います。オイルディップスティックを取り出します。はい、正しそうです。素晴らしい。これは視覚的にもう少し面白く、保守エンジニアにとって消化しやすくなっているのがわかります。
では、ここで行ったことをまとめましょう。エージェントビルダーとチャットキットを使用して構築されたエージェントワークフローをお見せしました。そして、エージェントビルダーに入り、いくつかのノードを調整し、ウィジェットを追加し、プロンプトを変更し、デプロイをクリックしました。そして、わずか数秒後、ページを更新するだけで、更新された本番環境対応のワークフローを実行できました。
これにより、エージェントキットを使用して非常に迅速に構築およびデプロイすることがいかに簡単かがお分かりいただけたと思います。それでは、仲間のトラックブラザーであるロハンに引き継ぎます。彼は、独自のスタック上でエージェントワークフローをデプロイする方法と、全ユーザーベースに拡張する際にワークフローを最適化する方法について説明します。ロハン、お願いします。
セルフホスティングとスケーリング
ありがとう、ジェームズ。そして皆さんこんにちは。私はロハンです。OpenAIのソフトウェアエンジニアで、エージェントキットに取り組んできました。お聞きしたいのですが、エージェントワークフロー、今日何回聞きましたか。たくさん聞いたと思いますが、私はあと数回言うつもりです。
これまで見てきたのは、ジェームズがエージェントビルダーを使用してワークフローを構築し、コードを書いたりインフラを管理したりすることなく、OpenAIのクラウドにデプロイしたことです。それは素晴らしいことですが、セルフホスティングする必要がある場合はどうでしょうか。コンプライアンス上の理由でそうする必要がある場合や、クラウド内でのみ利用可能なデータにアクセスしたい場合があるかもしれません。
良いニュースは、エージェントキットのすべてがそのユースケースをサポートするように設定されており、独自のサーバーをバックエンドとして使用できることです。必要なのは、主にメッセージを受信して出力を送信するチャットプロトコルを実装することだけです。
エージェントビルダーは、ワークフローをコードにエクスポートできるようにすることで、実際にこれを支援します。お見せしましょう。エージェントビルダーに戻ると、上部のこのコードボタンをクリックでき、このワークフロー全体をJavaScriptまたはPythonコードとしてエクスポートできます。
これは、今年初めにリリースしたオープンソースライブラリであるOpenAI agents SDKを使用して構築されています。そして、チャットキットのセルフホスティングへの切り替えがいかに簡単かを証明するために、今すぐデモを移行します。
エディタに移動すると、このコードがPythonでここに貼り付けられているのがわかります。そして、ジェームズが設定したのと同じものがすべて含まれています。ホストされたMCPツール、さまざまなエージェント、ツールなどです。エージェントビルダーからエクスポートできた相当量のコードです。
彼が持っているこのMCPツールは、パブリックインターネット上で実行されるように設定されています。しかし、これが実際にはプライベートクラウド内でのみ利用可能なデータにアクセスしているため、パブリックインターネット上にはないと想像してみましょう。代わりにローカルツールに切り替えます。
ここで、ローカルホストで実行されているSSEサーバーを設定したのがわかります。つまり、もうインターネット上にはありません。そのツールを使用していたエージェントに入り、サーバーに接続して、物事が実際にローカルで実行されている証拠として、ツールのリストを出力します。
そして最後に、ホストされているものではなく、ローカルで実行されているMCPサーバーを使用するように切り替えます。バックエンドコードに関しては、以上です。他にやるべきことは、チェックキットにopeni.comのAPIではなく、ローカルチェックキットを使用して、今書いたバックエンドにアクセスするように指示することだけです。
この関数を見せると、中にはあまり多くはありません。APIエンドポイントを指しているだけで、それはスラッシュapiスラッシュジャケットです。では、アプリを再起動して、ジェームズが入力したのと同じクエリの1つを入力します。
ターミナルに戻ると、今書いたコードが実行されています。このクエリ拡張エージェントから始まり、ファイル検索エージェントに移り、MCPツールなどについて出力しているのがわかります。
ここでの力は、エージェントビルダーを使用してワークフローを視覚的に構築できることです。バージョン管理できます。OpenAIプラットフォーム内でプレビューして実行できます。そして、これらのワークフローの構築について同僚と協力することさえできます。
デプロイする時が来たら、コードとしてエクスポートし、エディタに貼り付けるだけで、準備完了です。これがセルフホスティングです。そして、ストリーミングトークン、推論サマリー、ウィジェットなど、チャットがサポートするすべての機能は、プラットフォーム内で引き続きサポートされています。
したがって、代わりにセルフホスティングすることで何も失うことはありません。ウィジェットさえ機能したのがわかります。物事は期待通りに機能しています。では、この講演のタイトルに注目を戻したいと思います。大規模なエージェントのオーケストレーション。
トレーシングと評価による最適化
スケールで何が起こるか知っていますか。予期しない動作、バグ、何千または何百万ものユーザーがいるときに物事がうまくいかなくなります。そして、それらの問題を見つけることができるだけでなく、ワークフローを最適化してより良くすることができるようにしたいのです。
このセッションの残りの部分では、ここの機能を使用してそれを行う方法をお見せします。エージェントビルダーに戻り、この評価ボタンをクリックすると、トレースが読み込まれます。今見ているのは、トレースの高レベルビューのようなものです。
チェックキットやプレビューウィンドウ、その他の場所でワークフローが実行されるたびに、自動的にトレースが作成されます。そして、今見ているこのトレースは、何が起こったかの概要です。どのエージェントがどの順序で実行されたか、どのくらい時間がかかったか、そのすべての情報がわかります。
そして、実際にこれらのエージェントのいずれかをクリックして、何が起こったかの詳細を確認できます。この場合、使用されたモデル、トークン数、入力、出力、知っておく必要があるほとんどすべてのことです。
ご想像のとおり、私はセミトラックの燃料フィルターの問題を解決する方法について、これが正しい答えであるかどうか、また専門家ではありません。だから、GPT-5にこれを採点してもらいます。
最終出力が正しくて読みやすかったかどうかを尋ねる採点者を追加しました。何が起こっているかというと、モデルはこの完全なトレースとその中のすべてのコンテキストを見て、物事がうまくいったかどうかを判断できるのです。
私が追加したような複雑な採点者を追加できます。これは、ワークフローをエンドツーエンドで見て、物事がうまくいったかどうかを採点する、やや広範なものです。より具体的なものを追加することもできます。
たとえば、カスタマーサポートエージェントを構築している場合、返金エージェントが返金をユーザーに与える前に常にスーパーバイザーに確認したかどうかを尋ねることができます。私たちの場合、合格したようで、物事はうまくいきました。
しかし、これの本当の力は、1つはトレースを調べて物事がどうなっているかの感覚をつかむことができることですが、2つ目は、右上のすべて採点ボタンを押すことで、この1つのワークフローだけでなく、すべてのワークフローを採点できることです。
1日に何百または何千ものトレースが入ってくる場合、これにより、本番環境で物事がどうなっているかの鳥瞰図を得ることができ、これは本当に強力です。では、いくつかのトレースを見て、いくつかの問題を見つけたと想像しましょう。どのように最適化しますか。
私の両親が私が育つ間ずっと与えてくれたアドバイスをお伝えします。彼らは言っていました。「ロハン、あなたのエージェントワークフローは、最も弱いエージェントと同じくらい強いだけです」と。
だから、やりたいことは、ワークフローに行って、各個別のエージェントを可能な限り良くなるように最適化することです。それを行う方法は、これらのエージェントのいずれかをクリックして、この評価ボタンをクリックすることです。そうすると、ビジュアル評価ビルダーが開きます。
これが読み込まれている間に、製品の評価を構築したことがある方はどれくらいいますか。たくさんの手が挙がっていますね。上級者の聴衆です。そして、評価を構築することが楽しくて簡単だと思う方はどれくらいいますか。一つも手が挙がっていません。
まあ、願わくば、私たちが評価の構築を少し良く、もう少し楽しくしたと思います。見ているものを説明しましょう。この画面の左側、いや右側、いや左、はい、画面の左側では、ビルダーで構成したエージェントを見ています。プロンプト、ツール、そのすべてのものが見えます。
そして、プロンプトに変数があることに気付くでしょう。そして右側では、最初の列は私が事前に入力したサンプル入力で、それが変数です。つまり、ユーザーからの入力です。2番目の列は、解決しようとしている実際の問題に関するいくつかの正解データです。これを使用して、出力を採点できます。
3番目の列は、入力が与えられた場合にモデルが実際に出力したものです。そして、いくつかの採点者を追加しました。最初の採点者はフォーマット採点者で、モデルが生成した出力が実際に保守エンジニアにとって理解可能で使用可能かどうかを採点します。
2番目は正確性採点者です。これをクリックすると、私が示したプロンプトが、問題を考慮して出力が正しいと思われるかどうかがわかります。したがって、採点者は正解データと実際の出力の両方を見て、物事がうまくいっているかどうかを判断できます。
ワークフローを見ると、実際にはあまりうまくいっていないようです。フォーマットが40%というのはあまり良いことではありません。これをより良くしたいです。ワークフローを最適化する標準的な方法は、プロンプトを編集することです。
いくつかのツールを編集したり、モデルを変更したりすることもできます。しかし今のところ、モデルの出力を変更するためにここにいくつかの指示を追加します。そして、出力を生成をクリックします。これにより、それらの入力に対するモデル出力が再生成されます。
これにより、物事が良く見えるかどうかを健全性チェックする機会が得られます。これでいくつかのものが生成されました。物事はだいたい大丈夫です。大丈夫そうです。さて、実際に物事を良くしたかどうかを知りたいです。
できることは、採点者を再実行することです。今、フォーマット採点者が40%の時間で合格しています。私の希望は、私の更新によりこれが良くなり、おそらく60、80、あるいは100%になることです。そして、これが実行されている間、評価の本当の力は、時間の経過とともに、最初は5つの例から始めるかもしれませんが、それは本当に良いことですが、時間の経過とともに、ユーザーが入力した非常に大きなデータセットを持つようになります。
また、採点者もいて、これらの採点者のそれぞれが、ワークフローの実際のパフォーマンスを判断します。したがって、時間の経過とともに、ワークフローを最適化し、新しいノードを追加し、それを繰り返すときに、バイブに頼るのではなく、物事が良くなっているかどうかを理解するために、冷徹で確かなデータに頼ることができます。
私たちの例では、実際に40から80%にジャンプしました。これは本当に素晴らしいことです。さて、それは強力です。手動で物事を編集できます。しかし、もう一つ本当にクールなことは、ここのこの最適化ボタンをクリックできることです。
保守エンジニア向けにワークフローを最適化するのが実際に非常に難しいと思う正確性採点者のようなものの場合、その最適化ボタンをクリックすると、より良くなるようにプロンプトを自動的に最適化します。
それを行う方法は、画面に表示されているすべてのもの、プロンプト、正解データ、採点者の結果、さらには物事が合格または不合格だった理由についての考えさえも見ることです。そして、そのすべてのコンテキストが与えられると、プロンプトをより良くなるように最適化します。
物事をどのように最適化すればよいかわからない最も難しいクエリに対して、これを試してみることを本当にお勧めします。そして、物事をより良くするために、すべての採点者のすべてのものを同時に最適化することができます。
では、ここまでで行ったことについて話を締めくくりたいと思います。20分足らずで、エージェントビルダーを使用してワークフローを構築しました。次に、OpenAIクラウド上で実行されているチャットキットにデプロイしました。
したがって、サーバーなどを管理する必要はありませんでした。次に、ローカルチェックキットに切り替え、トレースを見て、本番環境で物事がどうなっているかを確認し、最後にいくつかの評価を構築して最適化しました。
かつては何週間あるいは何ヶ月ものカスタムエンジニアリングを要したことが、今ではOpenAIプラットフォームという1つの場所で、数分または数時間で行えるようになりました。
このセッションの後、Discordで質問にお答えしますし、デブデイ会場にもおります。質問があれば、ぜひ私たちを見つけてください。以上がエージェントキットです。気に入っていただけることを心から願っています。そして、皆さんがこれで何を構築されるか、待ちきれません。ありがとうございました。
コメント