本動画は、OpenAIのエンジニアが新しいResponses APIの機能と利点を詳細に解説するビルドアワーセッションである。従来のChat Completions APIからの進化として、Responses APIはエージェント構築に最適化された設計となっており、複数のツール呼び出しや推論の保持、マルチモーダルワークフローを1つのAPIリクエスト内で実現できる。デモでは、チャットアプリケーションの移行方法、MCP(Model Context Protocol)を活用したLinearボードとの連携、Web検索や画像生成ツールを組み合わせた複雑なエージェント動作などが実践的に示される。さらに、推論サマリー機能やストリーミングイベントの改善、プロンプトキャッシングによるパフォーマンス向上など、開発者がエージェントアプリケーションを構築する際の実用的なテクニックが網羅的に紹介されている。
Responses APIへようこそ
皆さん、こんにちは。私はクリスティンです。また別のビルドアワーへようこそお越しくださいました。私はスタートアップマーケティングチームに所属しており、今日はスティーブと一緒にお届けします。
はい、こんにちは。私の名前はスティーブです。APIチームのエンジニアをしています。
素晴らしいですね。今日はResponses APIについてすべてお話しします。もしこれが初めてのビルドアワーであれば、簡単にお知らせしておきますが、この1時間の目標は、OpenAIのAPIとモデルを使って構築できるよう、ライブデモとすぐに使えるコードリポジトリでサポートすることです。そのリンクを画面右側のチャットにドロップしておきますね。
そして、今後のすべてのビルドアワーはホームページとYouTubeで確認できるようになりました。皆さんのフィードバックを聞きました。これらを簡単に検索できるようにしてほしいとのことでしたので、OpenAIのYouTubeチャンネルに行けば、過去7回のビルドアワーすべてが含まれたプレイリストが見られます。GPT-5、音声エージェント、コーデックス、組み込みツールなど、たくさんあります。
先ほど申し上げたように、これはデブデイの直後に行う初めてのビルドアワーです。Apps SDKやAgent Kitのような本当にエキサイティングな製品ローンチを見ましたし、エージェント構築という素晴らしいテーマも見ました。だからこそ、今日はResponses APIについて話しているわけです。
ビルドアワーといえば、カスタムミームなしには語れませんね。これはResponses APIがなぜこれほど重要なのか、特にエージェント構築に関連してお話しする必要があるかを示しています。では、今日何を期待できるかご説明します。
まず、なぜResponses APIなのかについて簡単な説明をします。それから、まだ移行していない方のために、ライブデモでResponses APIへの移行方法をお見せします。そして、このデモは本当に楽しいものになります。OpenAIエンジニアの日常の舞台裏をちょっと覗く感じになるでしょう。
それから、これはデブデイ後初のビルドアワーなので、10月29日のビルドアワーでより深く掘り下げる前に、Agent Kitの少しプレビューをお見せします。そして、私のお気に入りの部分は常にQ&Aです。画面の右側に、チャットとQ&A機能が表示されています。
Q&A機能では、質問を投稿できます。室内にいる私たちのチームがチャット経由で回答したり、最後にライブでチャットするためにいくつか保存したりします。では、スティーブ、お願いします。
なぜResponses APIを構築したのか
素晴らしい。では、今日は少しお話ししたいのですが、なぜResponses APIを構築したのか、なぜ従来のChat CompletionsからこれまでのコアAPIプリミティブを、多くの新機能を可能にする全く新しいものへと進化させる必要があると感じたのかについてです。Chat Completions APIで人々が経験していた設計上の細かな問題の多くを修正できることを願っています。
本題に入る前に、少し歴史から始めたいと思います。2020年に、私たちは最初のAPI、V1 completionsをローンチしました。これは、モデルが単にあなたの考えを完成させる時代のために本当に構築されたものでした。
プロンプトがあり、それはあなたが終わったところから正確に始まり、完了するかトークンが尽きるまで続きました。そして、私たちにはそのためのAPIがありました。それはview and completionsと呼ばれていました。そして、もしこの時代のOpenAIビルダーだった方なら、当時のモデルを覚えているかもしれません。GPT-3、text da Vinci、Adaのようなモデルが、当時のLLMのフロンティアのようなものでした。
しかし、2022年に私たちはChatGPTをローンチし、APIではGPT-3.5 Turboをローンチしました。これは会話形式でポストトレーニングされた最初のモデルでした。つまり、あなたが終わったところから拾って続けるのではなく、会話パートナーのようにあなたに応答するようにトレーニングされており、単なる文章補完装置とはまったく異なるものでした。
そして、このAPIは、有名な話として金曜日に設計して火曜日に出荷したものですが、すぐにLLM APIの事実上の標準となりました。その後すぐに、Chat Completions APIにツール呼び出しやビジョンのような機能を追加し、モデルがより高度になるにつれてレベルアップを支援しました。
しかし、今年初めの01、03、そして今のGPT-5のリリースから始まって、私たちはこれらの非常に異なるモデルを持っています。それらはエージェント的で、高度にマルチモーダルです。
そして、単純なテキスト入出力リクエストから、数分間続く可能性のある高度にエージェント的な長いロールアウトまで、すべてを可能にするAPIが必要でした。では、少しお話ししたいのですが、そうですね、Responses APIは本当にチャット補完のシンプルさと、よりエージェント的なタスクを実行する能力を組み合わせています。
Responses APIは、ツール使用、コード実行、状態管理を含むワークフローを簡素化できます。そして、モデルの機能が進化するにつれて、Responses APIがエージェントアプリケーションを構築するための柔軟なプラットフォームになることを願っています。そして、本当にこの核心部分は、私たちが出荷した多くの組み込みツールです。
以前assistanceユーザーだった方なら、これらのいくつかを昔から覚えているかもしれません。Assistance APIでファイル検索とコードインタープリターを出荷しました。そして、これらをResponses APIに持ち込み、Web検索、コンピューター使用、リモートMCP、画像生成など、多くの新しいツールに加えて、もちろん誰もが知っていて愛している関数呼び出しもあります。そして、Responses APIがモデルが進化するにつれて、将来的にOpenAIプラットフォームを効果的に強化するのに役立つと信じています。
Responses APIの特徴
さて、Responses APIをChat Completionsと本当に差別化し、本当に異なるものにするいくつかのことについてお話ししたいと思います。まず、Responses APIの核心は、私たちがエージェントループと呼ぶものです。Responsesの核心哲学は、繰り返しになりますが、これはエージェントプリミティブであるということです。1つのAPIリクエストの範囲内で複数のことができる必要があります。
比較すると、Chat Completionsは、n個の選択肢があり、それぞれ1つのメッセージがあるという設計ですが、これはリクエストごとにモデルから1回しかサンプリングできません。しかし、responsesでは、モデルから複数回サンプリングできます。
では、その例は何でしょうか。モデルにコードを書いてもらい、そのコードを使って最終的な答えを出してもらいたいとしましょう。つまり、モデルにコードインタープリターツールへのアクセス権を与えて、5億276の平方根は何かと尋ねることができます。そして、モデルができることは、コードを書くことです。それを実行でき、そのコードをサーバーサイドで実行できます。
そして、そのコードの出力が何だったかをモデルに示すことができ、それからモデルは再びサンプリングして、コードインタープリターが与えたものに基づいた最終的な答えを出すことができます。つまり、これがエージェントループと言うときの意味です。モデルが最終的に「はい、終わりました。これが最終的な答えです」と言うまで、ループ内で複数のことができます。
2番目の大きなことは、アイテムインとアイテムアウトという概念です。Responses APIでは、すべてがアイテムと呼ばれます。では、アイテムとは何でしょうか。アイテムは、モデルができることと、モデルが言えることを表すタイプの一種の共用体です。
比較すると、Chat Completions APIでは、すべてがメッセージでした。関数呼び出しのような概念は、メッセージの概念に何とか取り付けられていたので、モデルが何かをしていて、かつ何かを言っているのではなくケースを処理するのは少し難しく、コードもあまりきれいに見えませんでした。Responses APIでは、これらを別々のタイプとして分けました。
つまり、メッセージはアイテムのタイプであり、関数呼び出しはアイテムのタイプであり、MCP呼び出しはアイテムのタイプである、といった具合です。そして、これによってコーディングがはるかに簡単になります。これらの複数の出力アイテムを取得すると、forループを書いてswitch文を書くのが非常に簡単になり、UIに表示したり、バックエンドに保存したり、アプリケーションが望むことを何でもできるようになります。
では、これがどのように見えるか簡単な例をお見せしましょう。ターミナルを開いて、左側でGPT-5 nanoでresponsesを呼び出して、プロンプトは単にジョークを言ってくださいというものです。それから右側で、同じプロンプトでchat completionsを呼び出します。
左側では、outputキーがあり、その中に2つのアイテムがあることがわかります。最初のものはreasoningアイテムです。タイプreasoningで示されており、基本的にそれは、モデルがジョークを出す前に少し考えたというレシートのようなものです。私たちの古典的な「なぜ科学者は原子を信頼しないのか」というジョークです。それから右側のChat Completions世界では、モデルが何か推論をしたというレシートはありません。設計では、これらの種類のものをステップごとに補充することは実際には許可されていないので、コンテンツ付きのこの1つのメッセージが得られるだけです。モデルがツールを呼び出している場合、それはここにインラインで表されます。
これは、Responses APIがアイテムイン、アイテムアウトであると言うときの意味の少しの例です。これらのアイテムを取得して、次のリクエストに直接渡すことができ、すべてが再補充されます。
次に進みますが、Responses APIは推論モデル専用に構築されています。Responses APIを使用すると、リクエストからリクエストへと推論を保持できます。
先ほどの例では、responseがreasoningアイテムを出力しているのを見ました。したがって、Responses APIを再度呼び出して、同じアイテムを渡すと、前のリクエストから思考の連鎖を再補充でき、モデルがそれを見て後続のリクエストで使用できるようにすることができます。
これはステートレスでもステートフルでも機能します。Responses APIはデフォルトでステートフルです。つまり、箱から出してそのまま使用していて、これらのアイテムを渡している場合、私たちはデータベースからこの思考の連鎖を再補充し、それをモデルに渡すことができます。そして、私たちが目にするのは、これが実際にツール呼び出しのパフォーマンスを本当に向上させるということです。
たとえば、私たちの主要なツール呼び出し評価であるtobenchでは、Chat Completions APIと比較して、Responses APIで5%のパフォーマンス向上が見られます。
次はマルチモーダルワークフローです。画像やその他の種類のマルチモーダルコンテンツを扱うことをはるかに簡単にするために、設計を本当に更新しました。
ビジョンで何かをしたい場合、Base64または外部URLをResponses APIでモデルに渡すのは本当に簡単です。また、コンテキストスタッフィングのサポートも追加しました。ファイルをAPIに渡すことができます。PDFです。たとえば、PG請求書があって、9月にPG請求書がなぜこんなに高かったのかと尋ねたい場合、そのPDFを直接Responses APIに渡すだけで、コンテンツを抽出し、モデルに表示し、モデルはその月に家で何が起こっていたかを理解するのを助けてくれます。
これは、これらのマルチモーダルワークフローを設計する本当にクールな方法です。次に、私たちはストリーミングを根本から本当に再考しました。Chat Completions APIでは、APIはオブジェクトデルタと呼ばれるものを出力していました。これは、開発者として、APIから出てくるすべてのイベントを蓄積し、それらをすべて積み重ねて、最後に何が起こったかの全体像を得ることを強制するパターンのようなものです。
しかし、Responses APIは、何が起こったかを理解するためにすべてを見る必要のない、有限数の強く型付けされたイベントを出力します。Responses APIに精通している方なら、本当に一般的なものをいくつか認識するかもしれません。これらは、モデルが出力している増分トークンを見たいだけの場合の出力テキストデルタのようなものです。
また、応答がいつ開始され、いつ終了したか、または失敗したかを知りたいだけの場合、それらは聞くことができるイベントです。これについてswitch文を書くのは本当に簡単で、コードは非常に扱いやすく、推論しやすいものです。少し後で、これがどのように見えるかの例を見ます。
そして最後のポイントは、リクエストからリクエストへコンテキストを再補充できるため、実際にP50でこれらの長いマルチターンロールアウト、つまりモデルが複数の関数を呼び出してから最終的に答えを出すResponses APIでのロールアウトが、実際には20%速く、また、モデルが出力するトークンが少なくて済むため、安価であることがわかります。
パフォーマンスと効率性
では、なぜでしょうか。Responses APIでは、モデルが行うことは、一度計画してから関数を呼び出し、それからあなたが応答し、その後、私たちは元の思考の連鎖を再補充できるので、次の関数に直接進むことができる、といった具合です。この連鎖を保持できるため、ロールアウトをすばやく進めてから終了できます。
一方、Chat Completionsでは、リクエストからリクエストへこの思考の連鎖を保持する方法がないため、モデルはすべてのステップで再び考えることを余儀なくされ、これがはるかに多くの出力トークンをもたらします。また、すべてのステップで思考の連鎖を削除しているため、キャッシュヒット率が悪化し、その共通プレフィックスが失われるようなものです。
これらは、Responses APIで私たちが異なる方法で考えたことのいくつかの理由です。そして、最終的に、開発者がこれらのエージェントアプリケーションを構築する方法を簡素化する必要があることを本当に認識しました。
それで、エージェントプラットフォームでデプロイメントをどのように変更しているかを見たいと思います。中心にあるのは本当にResponses APIとAgents SDKです。
これらは、アプリケーションに埋め込み可能でカスタマイズ可能なUIを構築できるようにする、私たちのコアビルディングブロックのようなものです。デブデイに参加した方や、直接そこにいた方は、エージェントビルダーとチャットキットをローンチしたのを見たでしょう。これらは、これらのワークフローをアプリケーションに構築し、少しの作業でドロップインするのを本当に簡単にします。そして、これらはResponses APIに基づいて構築されています。
また、これを改善フライホイールと呼ぶものの中核と見なしています。responsesをステートフルに使用している場合、すでに持っているデータのコーパスに基づいて構築し、蒸留や強化ファインチューニングのようなことを行うことができます。
また、このデータの上にタスク用のevalを構築することもでき、これが本当に簡単になり、これらすべてを中心に置きます。そして、これらすべてに加えて、Web検索、ファイル検索など、モデルの能力を強化する本当に素晴らしいツールがすべてあります。
Chat CompletionsからResponses APIへの移行デモ
素晴らしい。では、まだChat Completionsを使っている方がResponses APIに移行する方法について、少しデモをお見せしたいと思います。APIを移行することはあまり楽しい作業ではないことは知っています。ですから、これが実際にどれほど簡単かをお見せしたいと思います。
では、Cursorに切り替えて、ここに私が構築した本当にシンプルなチャットアプリケーションがあります。これは単に、最悪な見た目のChatGPTのようなものです。「ねえ、ジョークを言って」と言えます。
それからCursorに戻ると、これを動かすためにChat Completions APIを使っていることがわかります。以前にAPIでチャットアプリケーションを構築したことがある方なら、これの多くが本当に馴染みがあるでしょう。組み込みのSDKメソッドを使用しているだけです。そして、これは単一のReactファイルのようなものです。
アプリケーションをResponses APIに移行するのを本当に簡単にするために私たちが行ったことは、一種の移行パックを構築することです。これは何かというと、あるAPIから別のAPIにアプリを移行するために、エージェントコーディング用のCLIであるCodexの上で使用するプロンプトとガイドのコレクションのようなものです。
始めるための最も簡単な方法は、このbashコマンドをコピーすることです。それから、これを開始して、どのように見えるかをお見せします。これを貼り付けて、エンターを押します。どのリポジトリを移行したいか尋ねられます。現在のものだけにします。モデル参照をGPT-5に移行しますか。もちろん、どうして嫌なんでしょうか。ブランチ名。いいですね。それから、危険なアクセスで続行しますか。そして、これはライブデモなので、明らかにします。
これが行うことは、実行を開始することです。ここでCodexをヘッドレスモードで実行します。それから、ブラウザに戻って、あるAPIから別のAPIへの統合を効果的に移行するのを助けるために、このパックに組み込んだ異なるもののいくつかをお見せします。
私たちは多くの素晴らしいプロンプトを組み込みました。2つのAPI間の高レベルの違い、いくつかのガードレール、いくつかの受け入れ基準のようなものです。また、いくつかのドキュメントも提供しています。
これらは移行ノートのようなもので、Chat Completionsの1つの概念に精通していた場合、その概念はresponsesでどのように見えるか、いくつかのフォーマットの違い、コンテンツアイテム、私が以前話したこれらの哲学的な変更のいくつかのような一般的なことです。これらすべてをCodexにフィードし、それが本当に取り組んで、終わったら戻ってくるようにします。
これは本当にシンプルなアプリケーションですが、数分しかかからないはずですが、実際には大規模なアプリケーションにも非常にうまくスケールします。最初の数回実行したとき、約10分かかりました。だから、実際にここで停止します。それから、オーブンから新鮮なものを取り出します。そして、すでに終了したブランチに切り替えます。それから、簡単なdiffを行って、何ができるか見てみましょう。おっと、逆でした。
はい、素晴らしい。Codecが実際に何をしたかを見ることができます。会話マッピングをメッセージではなく入力アイテムに切り替えました。ここにいくつかの追加フィールドを追加しました。もちろん、モデルをGPT-5に切り替えました。推論アイテムの暗号化されたコンテンツを含めました。
これは、リクエストからリクエストへ思考の連鎖を再補充できると言ったときの意味のようなものです。たとえあなたがZDR顧客であっても、Responses APIをステートレスに使いたい場合でもです。それから、Chat Completionsのものではなく、responsiveストリーミングイベントで動作するようにストリーミング処理を変更しています。
アプリに戻ると、非常に似た体験が得られますが、今はGPT-5でChat Completions APIに基づいて構築されています。再びジョークを言ってと言うことができ、モデルは少し考えてから、戻ってきてジョークを言ってくれます。
これは、今日非常に深いChat Completions統合がある場合に、アプリケーションをResponses APIに移行し始める本当に簡単な方法のようなものです。移行が非常に簡単であることを願っていますが、移行を可能な限り簡単にするためにできるだけ多くのツールとガイドを提供したいと思っています。なぜなら、移行することには本当にたくさんの利点があると思うからです。
OpenAIシミュレーターゲームのデモ
それでは、次のデモに移りたいと思います。これは、私たちが作った小さなゲームのようなもので、Responses APIを使ってこのゲームにクールなエージェント機能を追加する方法についてお話ししたいと思います。
週末に、OpenAIシミュレーターと呼ぶこの小さなゲームを作りました。OpenAIエンジニアの日常をシミュレートするようなものです。このマップを作るのにどれだけの時間を費やしたかは正確には言いませんが、少し恥ずかしいです。でも、OpenAIのAPIフロアがどのように見えるかをかなり忠実に表現しています。
たくさんのキャラクターがいて、インタラクトしたい2つの主要なキャラクターがいます。私のチームのエンジニアであるWendy Jがいて、彼女は画像生成やファイル検索のような皆さんが知っていて愛している素晴らしいツールのいくつかを構築しました。そしてもちろん、OpenAIのCEO、Sam Altmanがいます。
彼はAGIを構築し、従業員がそこに到達するのを助け、成功へと導くことに本当に興味を持っています。Cursorに戻って、これがどのように構成されているかを見て、ここのコードのいくつかを見ていきましょう。
2つのエージェントがあります。1つはSamで、もう1つはWendyです。ここにいくつかのリクエストオプションがあります。両方にモデルをフィードしており、それはGP5です。Samにはかなり基本的な指示があります。Wendyにも基本的な指示があります。そして、これらは単に、少しの背景、どのように行動すべきか、どのように振る舞うべきかのようなものです。
ゲームに戻って、「ねえSam、AGIへのクリティカルパスには何がありますか」と言うと、Samは少し考えてから、最終的に私たちに応答します。ここで開発者ツールを開くと、私たちに返されるさまざまなストリーミングイベントを見ることができます。
最初にresponse.createがあり、進行中です。出力アイテムが追加されました。しかし、これの問題は、Samが実際に私たちに応答するまでに少し時間がかかることです。そして、フロンティアモデルアーキテクチャ、エージェントツール、メモリについて話し始める前に、私たちは少し宙ぶらりんで、あまりエキサイティングな体験ではありません。
だから、私たちが本当にしたいのは、Samが実際に話し始める前に、Samが考えていることを見ることができるように、推論サマリーを出力する能力をSamに与えることです。
コードに戻って、ここでコードを更新しましょう。推論ブロックを追加して、effortはmedium、summaryはautoと言います。これが行うことは、API内で推論サマライザーを有効にすることです。これは基本的に、モデルから出てくる思考の連鎖を見て、要約する価値があるかどうかを判断し、もしそうなら、ユーザーが消費できる方法で思考の連鎖を要約するサイドラインサンプリングプロセスを開始し、それをストリーミングバックし始めます。
右側に行くと、さまざまなストリーミングイベントを処理しているforループが見えます。これを最小化しますが、今は3つのハンドラーしかありません。出力アイテムがいつ完了したかを見ています。この部分には後で戻ります。テキストデルタを見たいときです。
これは、モデルが新しいトークンを出力するときの最終メッセージのようなものです。基本的にそれをUIに出力したいので、そのビジュアル処理を与えるためにタイプをtextと言っています。そして、別のものがここにあります。完了したときに最終的な応答をログに記録できるようにです。
では、ここに新しいケースを追加しましょう。caseはresponse.reasoning summary part deltaと言います。それから、これを異なるビジュアル処理を与えるためにreasoningに変更します。それから、ゲームに戻って、「ねえSam、AGIを構築するクリティカルパスには何があると思いますか」と言います。
Samは考えます。バックグラウンドで推論トークンを出力し、うまくいけば、それらのトークンの要約を開始し、すぐに推論サマリーが見え始めるでしょう。
オーケー、素晴らしい。彼はクリティカルパスの優先順位について考えています。私たちのUIはここではあまり素晴らしくありません。要約すべき思考の連鎖が少ししかないので、彼は要約します。そのサマリーの少しが得られ、それから彼は最終的な答えにすぐに飛び込みます。
とにかく、モデルが考えるのを待っている間に、特にGPT-5を使っている場合、推論サマリーを使ってUIをもう少しインタラクティブにする方法のちょっとしたプレビューです。
MCPツールとLinear連携
優れたエージェントには、現実世界でできるツールや物事がないと完成しません。そして、SamはAGIの構築に非常に集中しているので、彼が導かれ、何をすべきかを知っていることを確認したかったのです。
それで、AGIへのクリティカルパスにあると思われるタスクのいくつかを持つLinearボードを作成しました。AGIがトースターとして長時間ロールプレイするときのメモリリークや、別れのテキストを書くためのサポート、お願い認識など、基本的なもののいくつかです。
SamにこのLinearボードへのアクセス権を与えて、ここから引き出してゲームで私にやるべきことを与えられるようにしたいと思います。IDEに戻って、ここにツールを追加しましょう。このMCPツールへのアクセス権を彼に与えます。
これは何かというと、このMCPサーバーにAPIサーバーを接続したい方法を定義する単純なツール定義です。タイプを与えます。タイプはMCPです。サーバーラベルを与えます。
これは、MCPサーバー内の関数が名前空間化される方法のようなものです。サーバーURL、もちろん簡単な説明、そして私が見たばかりのこのプロジェクトの所有者であることを識別する認証トークンを与えます。それから、許可されたツールをいくつか与えることができます。
これらは、get issue、list issue、create issueのようなものです。これらは、モデルが呼び出せるようにしたいツールの許可リストのようなものです。多くのツールがありますが、監視なしで機能する方法でエージェントを常に信頼できるわけではないので、時には呼び出せるツールを制限できるようにしたいことがあります。
それから、常に承認を要求すると言います。右側では、これを処理するためにすでに書いたコードのいくつかを見てみましょう。ここでは、出力アイテム完了イベントを見ています。
取得したアイテムのタイプがMCP承認リクエストの場合、ウィンドウを開いて、はい、そのタスクを実行したいことを確認します。それから、基本的にそれを自動承認してから、サンプリングを続けます。
では、戻りましょう。実際には、ストリーミングイベント用のswitch文にいくつかのアイテムをもう少し追加したいと思います。response.mcp list tools in progressと言って、それからツールのリストのように見えるものをUIに出力します。素晴らしい。
それから、ツールを実際に呼び出しているときに別のイベントを出力できるように、ここに別のものを追加したいと思います。もしevent itemのtypeがMCP callなら、再びUIにどのツールが呼び出されているかを説明するイベントを出力したいと思います。
callingと言って、それからevent item server labelドットevent item nameと言えます。モデルが呼び出している関数の名前を出力します。これを追加したのは、バックエンドでAPIが何をしているかを知りたいからです。
MCP対応のresponsesに最初にリクエストを行うと、最初に行うことは、サーバーが公開しているツールをリストすることです。これは、MCPサーバーが動的である可能性があるためです。ツールはリクエストからリクエストへと変化する可能性があります。
そして、どのレベルの認証があるかによって、制限された特権ユーザーの場合、より特権のある管理者ユーザーよりも少ないツールにアクセスできる可能性があります。だから、UIを本当に新鮮に保ち、何が起こっているかを知るために、これがいつ起こっているかを知りたいだけです。
では、それを保存して、MCPサーバーの使い方を指示する特定の指示をSamに追加します。ゲームに戻って、Samのところに行って、「ねえSam、AGIに取り組むのが本当に楽しみです。AGI Linearボードにある問題をいくつかリストしてもらえますか。私が取り組めそうなもの」と言います。そう思います。見てみましょう。
彼がツールをリストしているのが見えます。彼は、物をフェッチする方法について少し考えるつもりです。ここで小さなポップアップが表示され、list issuesを実行すると言われ、「はい」と言います。
Samは再び考えています。うまくいけば、すぐにこのツールを実行するでしょう。linear MCP server list issuesを呼び出しています。少し見づらいですが、下の方に見えるかもしれません。彼は風変わりな問題のリストを持っています。実際にはかなり深刻だと思いますが、それでいいです。
オーケー、素晴らしい。彼はボードから引き出すことができました。「はい、AGIがSkyrim NPCユニオンを調整する問題があります。トースターの件でメモリリークがあります。お願い認識などです」と言いました。
そして私は、「ねえSam、実際にAGIがMacBookとWindows PCを区別できるようにすることに本当に興味があります。これのためにボードにタスクを追加してもらえますか」と言います。
Samは再び考えます。全体が既存のテキストで覆われているので、しかし、ボードに実際に問題を作成するためのプロンプトを取得する必要があります。
彼は少し考えて、それから実際にボードに問題を作成するためのプロンプトを取得する可能性があります。彼はプロジェクトの簡潔な説明を作成する方法について考えています。MacBookとWindows PCをどのように区別するか。彼は私に知らせる方法について考えています。
彼はcreate issueを実行したいと言っています。オーケーと言います。それで今、linear MCP serverのcreate issueを呼び出しています。
完了したら、彼が何をしたかを要約し、それから彼が何をしたかを教えてくれるはずです。オーケー、素晴らしい。彼は32のMacBook対Windows PCを区別することを作成できました。
Linearボードに来ると、彼が実際にこれを行うことができたことがわかります。クリックすると、実際にこれを正確に行う方法のかなり徹底的な説明をしてくれています。
これは素晴らしい。これに取り組むことができます。これは、MCPのようなものを使用して、インターネットの他の部分、皆さんが知っていて愛しているサービスから、アプリケーションに本当に豊富な情報をもたらす方法の例のようなものです。
そして、これは見たように、Responses APIで一級のサポートがあります。また、これらの複数ターン、複数ツールのロールアウトを1つのAPIリクエストで行う方法について少しお見せしたいと思います。これは、モデルが複数のことを行ってから、最終的に戻ってきて最終的な答えを与える能力です。
Web検索と画像生成のデモ
そのために、ゲームの他のキャラクター、Wendyと話します。コードに戻って、Wendyにいくつかのツールへのアクセス権を与えましょう。また、これらの設定の一部をここにコピーします。Wendyに2つのツールへのアクセス権を与えます。Web検索ツールと画像生成ツールへのアクセス権を与えます。
これらは2つのクールなツールで、モデルがインターネットを検索できるようにし、また、誰もが大好きな素晴らしい画像生成モデルにアクセスできるようにします。
彼女にこれら2つのツールへのアクセス権を与えます。Web検索、これはかなりシンプルです。本当にローカライズされた結果が必要な場合は、ユーザーがどこにいるか、都市、州、タイムゾーンのようなものをここに追加することもできます。それから、画像生成ツールへのアクセス権を与えます。
GPT image oneモデルを使用しています。小さな画像、小さな正方形の画像、スピードのための低品質です。それから、これを保存して、ああ、実際にこれらのツール呼び出しがいつ起こっているかを知りたいでしょう。だから、switch文にいくつかのケースステートメントをもう少し追加します。
caseはresponse web search call in progressと言います。そして、何をしたいか、いくつかのものをコピーします。Webを検索していますと言います。素晴らしい。それから、画像を生成するための別のものを行いたいと思います。
caseはresponse image generation call in progressと言います。ここで同様のことをします。ここではreasoningタイプを使用して、UIでその青いビジュアル処理を与えるだけです。画像を生成していますと言います。保存します。そこに保存します。
ゲームに戻って、Wendyのところに行って話します。「ねえWendy、フレンチブルドッグを見たことがありません。どんな見た目か調べるためにWebを検索してもらって、それから私に絵を描いてもらえますか」と言います。
素晴らしい。Wendyは少し考えます。そして、私がしたいことは、開発者ツールを開いて、進行中のストリーミングイベントを見ることができるようにすることです。
Wendyは画像生成ツールについて考えています。彼女は、自分が何をしたいかについて考え、計画しています。3つか4つのクエリに抑えるつもりで、うまくいけばそれで十分でしょう。
彼女はWebを検索しています。開発者ツールに戻ると、これの記録が見えます。出力アイテム完了があります。ここに推論呼び出しがあります。Web検索呼び出しが進行中です。Web検索呼び出しが検索中です。
本質的に、任意の時点でツール呼び出しで何が起こっているかを教えてくれるこれらのステートマシンイベントが得られます。Web検索呼び出しが完了しました。それから、Web検索呼び出しを表すこれらのイベントの1つをクリックすると、モデルが何を検索したかを実際に見ることができます。
AKCを探しています。American Kennel Clubだと思います。フレンチブルドッグの品種標準、外観、耳、コンパクトなサイズ、色などです。Wendyが実際にこれを数回行って、正確な写真を私に与えるために必要なすべてのものを本当に集め、それから最後に、うまくいけば彼女がどのように見えるかを私に示すことができるのが見えます。
彼女は複数回Webを検索します。ここにハンドラーにいくつかのコードを追加しました。出力アイテムがいつ完了したかを見ており、特に画像生成呼び出しを探しています。それらの呼び出しには、画像を表すBase64データが直接ストリーミングバックされます。
そして、すでに書いたコードが行うことは、完全な呼び出しが完了したときに新しいタブでその画像を開くことです。
Wendyに、何が起こる必要があるかについてすべて考える時間を与えましょう。それから、オーケー、素晴らしい。彼女は画像プロンプトについて考え始めています。オーケー、これは素晴らしい。
彼女はフレンチブルドッグの写真を描きに行きます。とてもかわいいです。
これは、Responses APIがアプリケーションを本当にレベルアップし、複数のホストされたツール、アプリケーション外からの情報を利用し、キャラクターやアプリを本当に生き生きとさせる方法についての本当に簡単な例です。
エージェントビルダーのプレビュー
最後にお見せしたいのは、実際にエージェントビルダー製品のプレビューです。DevDayに参加した方や、DevDayに直接いた方は、Christinaがエージェントビルダー製品で物事を行う方法の概要を説明するのを見ました。
エージェントビルダーで今構築したものの一部を再作成する方法の簡単な例をお見せしたいと思います。ここに本当にシンプルなワークフローがあります。ノードをクリックして、何が起こっているかを説明します。
最初のノードは、Web検索決定エージェントのようなものです。ここに同じ背景の一部があります。基本的に、指示は、尋ねられているクエリがWeb検索を必要とするかどうかを決定することです。
もしそうなら、このユーザーがWebを検索したいと言う構造化データと、もしそうなら検索クエリが何かを出力したいと思います。それから、このif else文があります。これは基本的に前のノードからの出力を見て、Web検索ツールが有効になっているこのエージェントを呼び出すか、ここでこれらのローカライズされた設定のいくつかを設定しました。
または、単に会話的に応答することが仕事である別のエージェントを呼び出します。これを試してみましょう。プレビューをクリックして、「ねえ、私の近くの天気はどうですか」と言います。
ワークフローを進めるにつれて、ノードがアクティブになるのが見えます。最初のものが私のクエリをWeb検索を望むものとして分類し、クエリが私の近くの現在の天気であることがわかります。
if else文が通過し、それから実際にWebを検索できるこのエージェントに移動します。彼は私がどこにいるかを知っており、サンフランシスコは実際にかなり暖かい日で、すべてを考慮すると華氏67度、またはアメリカ以外の方には摂氏20度だと教えてくれます。
しかし、戻ってジョークを言ってくださいと尋ねることができます。そして、逆が起こるのを見ることができます。
ここの決定ノードはfalseを返すはずで、それから会話エージェントに流れ込みます。ここでいくつかのジョークが得られます。Kit Katの広告のものも含まれています。それは見たことがありません。いいですね。
オーケー、素晴らしい。これはエージェントビルダー製品がどのように見えるかのちょっとしたプレビューです。次のビルドアワーでは、これについて本当に本当に深く掘り下げます。
しかし、この製品は、これらのドラッグアンドドロップワークフローを構築し、多くのコードを書く必要なく、アプリケーションに直接ドロップできるようにするのに本当にクールです。それでは、Q&Aに行けると思います。
Q&Aセッション
素晴らしい。はい。ここで簡単な更新をするだけです。オーケー、オーケー、素晴らしい。オーケー、素晴らしい。
この人は、「GPT-5 miniを使用して例の出力をモデルに渡す最良の方法は何ですか。構造化JSONを返したいのですが、幻覚を起こすこともよくあります」と尋ねています。
これは興味深いです。人々がfewショットプロンプティングでモデルに本当に成功していることがわかります。これは、これらのチャットモデルの最初の世代にまでさかのぼる一種の技術ですが、現在の世代のモデルでも非常にうまく機能します。
幻覚を起こしていることがわかった場合、モデルがどのように振る舞うべきかについて本当に明確な指示を与えたい場合は、いくつかの異なる多様な例を与えたいかもしれません。
これが私のユーザーメッセージ、これが入力、これがアシスタントメッセージだと言います。それはあなたがそれに言ってほしいことの良い標準的な例のようなものです。いくつかの異なる例を与えて、多様になるようにします。これにより、モデルは、そのシナリオで実際に何をしてほしいか、実際に何をしてほしいかについて本当に明確なアイデアを得ることができます。
fewショットプロンプティングを試すことをお勧めします。幻覚が、自分のコンテキストの外から見つけることができるデータを作り出しているようなことに関連していることがわかった場合、Web検索のようなツールを追加して、外部のWebからデータを持ち込み、何かをでっち上げないようにすることを試みるかもしれません。素晴らしい質問です。
素晴らしい。Chat CompletionsとResponses APIの間にパフォーマンスの違いはありますか。はい、これは素晴らしい質問です。Responses APIは、モデルがしばらく考えてから連続して多くの関数を呼び出すような、これらの長いツール呼び出しロールアウトで本当に本当に繁栄していることがわかります。
多くのリクエストにわたるこれらのロールアウトのエンドツーエンドのパフォーマンスは、実際にはChat Completionsでの場合よりもはるかに短いことがわかります。Chat Completionsでは、モデルはすべてのステップの間に再び考える必要があります。なぜなら、最初のステップから推論を保持できないからです。
Responsesでは、モデルは少し考えてからツールを呼び出すことができ、それからあなたは応答でき、それからあなたが応答するとき、私たちは元の考えるコンテンツを再補充でき、それからモデルは「ああ、オーケー、それが私の計画だった。次のツール呼び出しに進むことができる」と知ります。
一方、Chat Completionsでは、元のコンテンツを保持する方法がありません。だから、それは削除されます。モデルは続ける前に再び考える必要があります。そして、この考えるプロセスは、より多くのトークンを出力していることであり、時間がかかります。
それで、それをする必要がないことによって、実際に中央値で約20%の時間を節約し、また少し安価で、より良いキャッシュヒット率が得られることがわかります。
また、Responses APIがステートフルクエリを可能にするのが少し優れていることもわかりました。以前に行っていたようなものがある場合、ホストされたツールの1つが実装できる何かをした関数呼び出しのようなツールがある場合、RAG関数があるとしましょう。
ファイルのコーパスから何かを検索したい場合、それをラウンドトリップする必要があります。「オーケー、ファイルを検索して」という関数呼び出しを取得します。それから、自分のサーバーで何かを行い、それからAPIに送り返す必要があります。
そのラウンドトリップは少し追加のレイテンシを発生させますが、ホストされたツールとResponses APIはすべてタイトなループで起こることができ、そこで少し時間を節約します。もちろん、私たちの検索スタックは本当に細かく調整されています。
Responses APIがChat Completionsよりも良いパフォーマンスが得られる可能性があるいくつかの例です。
オーケー、素晴らしい。前のアイテムは新しいレスポンスリクエストにどのように渡されますか。これはドキュメントで言及されている会話か何か他のものですか。多くのリクエストにわたって思考の連鎖を再補充することに興味があります。
オーケー、これは本当に良い質問で、実際にはこれを行うためのいくつかの異なる方法には触れませんでした。実際にはいくつかあります。最も簡単なものは、過去にChat Completionsを使用したことがある場合、おそらくおなじみのものです。これは、会話を表すアイテムのリスト全体を取得して、次のリクエストに渡すだけです。
そのリストに物を追加し続けて、それを戻すだけです。これは、過去にChat Completionsを使用していた方法のようなものです。それをしたくない場合、previous response IDと呼ばれるヘルパーもあります。
これにより、前のレスポンスから連鎖し、1つまたは2つの増分入力アイテムを追加するだけです。それが行うことは、前のレスポンスをロードし、そこからすべてのコンテキストをフェッチし、それから渡したものを追加してから、そこから続行します。
会話の先頭へのポインタを保持したいだけで、コンテキスト状態を自分で管理する必要がない場合、これは簡単な方法です。
数ヶ月前にConversations APIもローンチしました。以前にassistanceユーザーだった方は、おそらくthreadオブジェクトの概念に精通していたでしょう。conversationオブジェクトは、Responses APIのためのそれの再想像のようなものです。
post v1 conversationsを実行してconversationを作成できます。オブジェクトIDが返されます。それをResponses APIに渡すことができ、それから会話が進むにつれて、増分入力アイテムをv1 responsesへの呼び出しに渡すだけです。
conversation IDはこれで、それから入力アイテムはAとBですと言うかもしれません。それから、私たちはそれらのアイテムを取得してconversationに追加します。
conversationは時間とともに成長し、変化し、それから作成した1つのconversationオブジェクトへの参照を保持するだけです。チャットUIを構築している場合、UIをレンダリングしたい場合は、その会話の中のものをリストするだけで本当に素晴らしいです。本当に簡単な方法のようなものです。
特定のアプリケーションと、実際にどれだけコンテキストを自分で管理したいかに応じて、リクエストからリクエストへコンテキストを再補充するためのいくつかの異なる方法があります。
そして、繰り返しになりますが、responsesをステートフルに使用している場合、conversationオブジェクトを使用していて、私たちのサーバーで物が永続化されている場合、思考の連鎖の再補充は自動的に行われています。
ステートレスに使用している場合、storeパラメータを使用してfalseに設定している場合、暗号化されたコンテンツを含めて、その暗号化された推論をラウンドトリップできるようにすることができます。そのため、思考の連鎖を再補充する利点を得ることができます。
または、ZDRカスタマーの場合、同じことです。そのincludeパラメータを使用して、そのようなものを再補充できるようにすることができます。
素晴らしい。テンプレートはOSSとして利用可能になりますか。テンプレート、もしかしたら、今日お見せしたすべてのものはすべて、ビルドアワーGitHubに置きます。だから、そのようなものはすべて利用可能になるはずです。
はい、うまくいけば今日見たすべてのものがGitHubで利用可能になります。素晴らしい。複数のエージェントと役割、患者、傍観者、ディスパッチャーなどを使用した救急隊員シミュレーターに取り組んでいます。このコードを投稿する可能性はありますか。素晴らしいジャンプスタートのように思えます。
はい、まさに。私たちがまとめたこのゲームは、ビルドアワーGitHubで利用可能になります。自由にフォークして、好きなようにすることができます。人々が本当に日常を生きることに興味があるように聞こえたので、それらを追加しました。
いいですね。はい、まさに。はい、かなり楽しいと言えます。自分のものにすることができます。まさに。時間が残っているので、更新をしたければ、さらに2つの質問を追加しました。素晴らしい。オーケー、素晴らしい。
プロンプトキャッシングはどのように機能しますか。プロンプトキャッシングを利用するためにプロンプトをどのように編集できますか。はい、かなり簡単です。基本的に、動作する方法は、すべてのコンテキストを渡すと、トークンで基礎となる表現のようなものを構築し、それからすべてのトークンを取得してモデルに送信します。
そして、モデルレベルには、基本的に渡したトークンの一定量で基本的にプレフィックスマッチの一種を実行しようとするキャッシュのようなものがあります。すでにキャッシュにあるものと一緒に。
Responses APIを呼び出して、ジョークを言ってと言ったとしましょう。その会話をトークン化し、モデルに送信します。そのモデルのキャッシュにその正確なプレフィックスが見つかった場合、それらはキャッシュトークンとしてカウントされ、それらの入力トークンに対して割引価格を支払うことになります。
プロンプトキャッシングを本当に利用する方法は、リクエストの間でコンテキストの初期部分を変更しないことです。なぜなら、3つのアイテムを削除した場合、基本的にプレフィックスが変更され、その後に来るものはすべて失われるからです。プレフィックスが少し異なるため、トークンのセットが異なります。
キャッシュを最も効果的に利用する方法は、コンテキストを追加専用リストのようなものとして扱い、それにものを追加し続けることです。フローの初期で何かを変更すると、プロンプトキャッシングの利点の少しを失うことになります。
素晴らしい。Responses APIを使用する際に見られる最も一般的な間違いは何ですか。これは良いものです。私たちが確かに目にするのは、Responses APIが提供する最大のものは、リクエストからリクエストへ思考の連鎖を再補充できるこの利点のようなものだと思います。
それで、デフォルトでステートレスであるZDRカスタマーにとっての一般的な落とし穴のようなものを見ます。暗号化されたコンテンツをリクエストして、それを再補充して戻せるようにするための追加のオプトインステップのようなものがあります。
それをしない場合、デフォルトではそれを利用できないでしょう。ですから、responsesをステートレスに使用している場合、またはZDRカスタマーの場合は、常にその暗号化されたコンテンツをリクエストして、それを戻して推論モデルの完全な能力を利用できるようにすることを強くお勧めします。
私たちが目にする別のことは、考えようとしています。私たちが目にする別のことは、確かに、私たちが持っているホストされたツールの独自バージョンを展開しようとしている人々です。
本当に本当に素晴らしいホストツールを提供していると思いますし、それらは始めるのを非常に簡単にします。特に、モデルがドキュメントのコーパスを検索できるようにしたいRAGパイプラインのようなものを構築している場合。これは本当にうまくやるのが非常に難しいことで、私たちのチームはそれを正しくやることに多くの時間を費やしてきました。
ですから、可能な限り、特に始めたばかりで、それほど多くのノブが必要でない場合は、組み込みツールを利用し、プラットフォームからすべてのパワーを引き出して、本当に迅速に立ち上がることを強くお勧めします。
私たちが本当に人々にやってもらいたいもう1つのことは、Responses APIエコシステムの他のオブジェクトのいくつかを試してみることです。conversationオブジェクトについて少し話しました。これは、特にチャットインターフェースのようなものを構築している場合、始めるための本当に簡単な方法です。
数ヶ月前に出荷した本当に素晴らしいもう1つのオブジェクトは、promptオブジェクトです。APIにタスクがある場合、またはアプリケーションにタスクがある場合、これを翻訳してくださいとか、これはあなたのキャラクターの概要で、私たちが見たゲームの例かもしれません。
ダッシュボードでpromptオブジェクトを作成できます。これは、説明するステープルオブジェクトのようなものです。指示を与えることができます。あなたはキャラクターXYZですとか、あなたの仕事は以下のコンテンツを英語からスペイン語に翻訳することですと言うことができます。
いくつかのツールを与えることができ、これは基本的にタスクを定義し、それからprompt IDでResponses APIでそれを参照できるようにします。これらのプロンプトをバージョン管理し、それらを反復することができ、タスクでヒルクライムするのに本当に役立ちます。
この特定のもののためのevalがあって、それをより良くしたいかもしれません。プロンプトを変更し、保存し、新しいバージョンを取得し、Responses APIにドロップするだけで、すべてのアプリケーションにそのようなものをハードコーディングする必要なく、すべての呼び出しがそれのすべての利点を得ることができます。
いくつかの一般的な落とし穴と、以前にそれらのオブジェクトを試したことがない場合のいくつかのアイデアです。
まとめとリソース
素晴らしい。これらは私たちのリソースのいくつかです。Q&Aが盛り上がっています。最後の質問にもう1つ時間がありますか。これは、MCPツール呼び出しがResponses APIでどのように、いつ発生するかを説明してもらえますか、そしてその機能で人々が何をしているのを見たかについてです。
完全に。はい。MCPは本当にクールです。Responses APIでサポートできることに本当に興奮しています。基本的に動作する方法は、responsesでMCPサーバーを有効にすると、最初に行うことは、MCPサーバーに連絡して、「ねえ、私のユーザーが使用できるツールは何がありますか」と言うことです。
基本的に、関数呼び出しを使用したことがある場合、関数呼び出しに非常に非常に似ています。私たちはそれをリモート関数呼び出しのようなものと呼んでいます。それで、基本的に関数定義の束を返します。
それらをモデルにフィードし、持っているすべての関数のリストがここにありますと言います。そして、それらはすべて名前空間化されています。私たちは、あなたが提供した関数と、処理するためにあなたに制御を戻す必要があるもの、および実行するためにそのサーバーに連絡する必要があるMCP関数との違いを見分けることができます。
Linearの例では、たくさんの関数があります。40個の関数のようなものがあります。そのうちのいくつかしか見ませんでした。しかし、標準的な例は、リクエストを行うことです。Responses APIはMCPサーバーを呼び出して、これが私のユーザー認証トークンですと言います。このユーザーはどの関数を使用できますか。このリストを返します。それをモデルに示します。
私のプロンプトに応じて、XYZボードにこの説明のための問題を作成してくださいのようなことを言うと、モデルは正しいツールを識別できます。それは、呼び出したいツールと引数がここにありますと言うJSONを出力します。それから、それを取得してMCPサーバーに送り返します。
その関数でLinearに連絡しています。そのJSONでLinear MCPサーバーはそれで何かをします。この場合、プロジェクトに問題を作成するかもしれません。それから、オーケー、素晴らしい、作成した問題の表現がここにありますと言う確認を私たちに返します。
モデルはそれを見て、それから最終的な答えで何をしたかを要約できます。MCPがフードの下でどのように機能しているかについて少しです。
MCPで行われているのを見たクールなことは、人々がエージェントコーディングツール、つまりCodex CLIのようなものに、引き出さなければならない可能性のある他の部分、他のものへのアクセス権を与えるのが本当に好きだということです。再び、Linearは素晴らしい例です。
Codexを起動して、ねえ、Linearからこの問題を引き出してもらえますか、それはすでにその中にものがあります、またはこれら5つの問題を処理してほしいと言うとします。それは、いくつかのターンごとに止まってプロンプトする必要なく、Linearと協力していくつかのものを引き出してから、独立して作業することができます。
Codex CLIはResponses APIに基づいて構築されており、それによってすべてのクールな機能を得ることができます。
素晴らしい。スティーブ、本当にありがとうございました。これは本当に役立ちました。たくさんの質問が寄せられるのを見るのが大好きです。チャットとライブですべてに答えようとしています。
しかし、今回質問が回答されなかった場合、さらにビルドアワーがあります。次のスライドに進んでください。素晴らしい。
10月29日はすべてAgent Kitについてです。今日見たものの本当により深い掘り下げです。Responses APIについてさらに質問がある場合は、そこに質問を持ってきてください。そこでもそれらに対応します。
それから11月5日はすべてAgent RFTについてです。エージェントを構築したら、どのようにそれらをより良くしますか。それから12月3日はエージェントメモリパターンについてです。そのためにとても興奮しています。
すべてのビルドアワーはYouTubeとオンデマンドでホームページで利用可能で、そこで他のすべての将来のビルドアワーにサインアップできます。それでは、ご参加いただきありがとうございました。次回お会いしましょう。
コメント