この動画はOpenAIの開発者向けセッション「Build Hour」の2025年第1回目で、エージェンシックツール呼び出しをテーマとしている。OpenAIのスタートアップマーケティング責任者Sarah Urbonusと開発者体験チームのAlainが、新しく登場したCodexやo1-03などの最新AI技術を紹介し、推論能力とツール活用を組み合わせたエージェント開発の実践的な手法を解説する。セッションでは理論的な概念説明から始まり、実際にPythonとFlaskを使ってタスクシステムのバックエンドを構築し、フロントエンドとの統合まで行うライブコーディングデモンストレーションが展開される。長期的なタスクの実行、進捗の可視化、並列処理などの実装方法を具体的に示し、開発者が自社でエージェントシステムを構築する際の実践的なガイダンスを提供している。
Build Hour開始
皆さんこんにちは、またもやBuild Hourへようこそ。これは実は私たちの2025年最初の回で、今日皆さんと一緒にいられることを本当に嬉しく思っています。私はSarah UrbonusでOpenAIでスタートアップマーケティングを担当しています。今日はAlainと一緒にお送りします。
ええ、私はElanです。開発者体験チームにいます。
私たちはいつもBuild Hourを始める時に、なぜここにいるのかという目標から始めるのが好きで、それは皆さんに私たちのAPIとモデルを使って会社を拡大するためのベストプラクティス、ツール、AI専門知識を提供することなんです。今、このシリーズは本当に皆さんのためのものなんです。ですから皆さんからのフィードバック、何をもっと聞きたいか、何を構築しているか、そういったものを参考にしていて、うまくいけばこれが皆さんの週の本当に価値ある1時間となり、この後に皆さんがOpenAIで構築し創造していることを加速できればと思います。
新しいページがあります、webinar.openai.com/buildhourです。皆さんから今後のBuild Hourを集約した場所が欲しいというフィードバックをいただいたので、それを宣伝したいと思います。これで実際に今後予定されているすべてのトピックを見ることができます。私たちは2025年も忙しくしています。若い人たちの言葉を借りると、私たちは料理をしていました。今年リリースしたものがたくさんあり、何をリリースしたか、それが何をするのか、そして皆さんにとって何を意味するかもしれないかを簡単に高レベルで示したいと思います。
新機能とモデルの概要
Responses API、o1、o3、o4 mini、Codex CLI、Codexがありました。これのスクリーンショットを撮ることができます。残念ながらこの1時間で全部を説明する時間はありません。そうしたらしばらくここにいることになってしまいますが、今日は可能な限り多くの新機能とモデルをお見せしようと思います。明らかに、このリストから欠けている大きなものが一つあります。私たちがローンチしたimage genです。
そしてそれが皆さんから多くの注目を集めたことを知っています。来週、実際にimage genに関するBuild Hourを行い、皆さんが構築しているもののためにAPIをどう活用できるかについて話します。そして、はい、そのBuild Hourの間にStudio Ghibliの画像を1つか2つ作るかもしれません。
でも今日は本当にフラッグシップモデル、コンテキストの増加、そしてCodexとそれを今日から始めて構築する方法に焦点を当てます。議題として、まず基本的な概念から始めます。新しいことについて話し、Codexでタスクを設定し、それから基本概念に入り、推論、エージェンシックツール呼び出し、タスクについて話します。
Build Hourではいつものように、これを実践的にして皆さんを私たちのコードベースに導きたいと思っています。ですから、実際に今日のセッションのほとんどをデモに固定します。チャットでコードリポジトリを共有したと思うので、Alainが構築していることを追って、うまくいけばこの後に皆さん自身で構築できるでしょう。
まず、タスクの実装方法についてデモを行い、タスクシステムのインターフェースとバックエンドをライブで構築します。それから委譲について少し話し、評価についていくつかの方向性のあるガイダンスを共有します。ここで深掘りできることはたくさんありますが、うまくいけば始めるためのいくつかのヒントをお渡しできるでしょう。そして最後にいつものようにQ&Aで終わります。今日は新しいプラットフォームを使っているので、Q&Aをクリックするとテキストフィールドがポップアップするはずなので、質問をしてください。ここに何人かの方がいて答えてくれますし、最後にAlainがライブで答えます。
実践的デモンストレーション
そうですね、絶対に。準備はいいですか、コーディングをしましょう。やりましょう。では、どうぞ。
やあ皆さん。そうですね、新しいものがたくさんあり、始めに、今年ローンチしたエージェントのいくつかを確認するだけです。今年の初めにDeep Research o3 Codexをローンチしました。2025年はエージェントの年で、それが本当に起こっているのを見ています。そして始めに、Codexの簡単なデモをしましょう。皆さんの中にはこれをすぐに使いたい方もいるかもしれません。
では、手始めに。ここに実際にCodex CLIのリポジトリがありますが、これは私がお見せするデモではありません。代わりに、ChatGPTでCodexを使う方法をお見せします。
でも、これを開いている理由は、サンプルタスクを取得してCodexをどう使えるかをお見せするためです。ここに誰かが指摘した問題があり、Codexが他のベンダーの環境変数を通じてAPIキーを尊重していないということです。これは良くないので、私がすることは問題全体をハイライトしてCodexにドロップすることです。「これを修正できますか」と言って、少しコンテキストを与え、タイトルも与えます。見ての通りCodexが有効になっています。そうすると、これが行うのは、操作できるこのリポジトリのローカルコピーを持ち、実際にテストを実行してコードを書けるということです。これを開始します。そして始まります。バックグラウンドで、この問題のすべての異なる部分をチェックし、できる変更を行います。
このログで何が起こっているかを見ると、リポジトリをダウンロードしています。全体を見るつもりはありませんが、これがCodexで期待するインターフェースの種類で、最終状態を与える長期タスクがあります。これが私がやりたいことで、やり方を見つけてくださいと言うと、始まって環境を使います。
最後にそれに戻ります。でもこれはCodexのちょっとした先行きです。もうすぐ使えます。今日のBuild Hourにこれが関連している理由は、皆さんがすぐに自分のエージェントを実装するからです。そしてこれらのエージェントを持ち出している理由の一部は、皆さんのものがどのように見えるかの背景を与えることです。なぜなら、内部でo1 o3 Codexのすべてに使用した技術は、実際にほとんど公開されており、皆さんも構築できるからです。
エージェンシックツール呼び出しの概念
これが皆さんがエージェントを構築する方法です。Responses APIは非常に強力なAPIです。特に昨日、ホスティングツールMCPをローンチしたことで、たくさんのものがあります。残念ながら、ローンチしたすべてのものに入る時間はありませんが、基本的に単一のAPI呼び出しで、エージェントがファイルをクエリしたり、MCPサーバーを呼び出したりするイベントの全体的なシーケンスを開始できます。
エージェントSDKは、同じループを実装する本当に便利な方法ですが、ローカル関数呼び出しを行える場所で、ハンドオフのような他の機能もいくつかあります。そしてもちろん、MCPでホスティングツールがあり、これらは構築に使えるツールの一部です。
今日は、エージェンシックツール呼び出しについて話します。そして、私たちが話したすべてのことが本当にこの一つのアイデアに集約されます。
では、エージェンシックツール呼び出しとは何でしょうか。それは実際に推論とツールに帰結します。Deep Research、Codex、o3のようなものは、ツールを使った推論を通過するだけと考えることができます。でもなぜこれが面白いのでしょうか。これの大きな部分は本当に推論です。昨年、私たちはモデルに初めて推論することを本当に教えたo1を訓練しました。
これが意味することは、ここに段階的にタスクを行う方法を示して、私たちの例から学習することを期待する代わりに、推論しながら解決策にたどり着く方法を見つけ出させたということです。そして私たちは正しいか間違っているかを評価するだけでした。強化学習を通じて、o1は自分の思考の連鎖を洗練し、使用する戦略を精練することを学びます。
これがエージェンシックツール呼び出しの最初の構成要素である推論です。私たちはモデルを構成するステップではなく、解決策で訓練しました。彼らがステップを見つけ出し、推論が現れるのです。そして関数呼び出しやツール呼び出しを取り、そこでアクションを取り、情報を取得し、それらを組み合わせると、エージェンシックツール呼び出しが得られます。
この図で見ることができるのは、基本的に今モデルが行っているこの推論、この思考の連鎖の中で、物事について考える方法を見つけ出す場所で、今度はツールへのアクセスも与えているということです。そうすると、物事について考える方法だけでなく、物事を行う方法も見つけ出せるのです。パラダイムは非常に似ています。
私たちは特定のステップでこの思考の連鎖で訓練したのではなく、取りたい具体的なステップについて。結果で訓練し、それらの結果を実際に達成するためのアクションを取ることを学習します。これが強化学習の本当に強力な部分で、思考だけでなく行動についても今モデルに持ち込んでいます。そして見えるのは、本当に本当に強力な長期エージェンシーです。これが私たちがエージェンシックツール呼び出しと呼んでいるもので、結果は目標指向のモデルです。機知に富んでいます。求められたものを得る方法を見つけ出します。回復に対して非常に堅牢です。
ツール中に失敗を得ても、実際にコース修正して最後まで到達できます。そして長期的なタスクで本当に一貫しています。実際に行に数十数百の関数呼び出しを持つことができます。Codexはこの程度のオーダーで行うと思い、一貫性を保ちます。これがエージェンシックツール呼び出しの力です。
タスク指向の新しいパラダイム
このエージェンシックツール呼び出し機能で、実際に新しいプリミティブや新しい抽象化であるタスクについて考え始めることができます。すべてが非常にチャットベースでした。そして今、長期タスクの世界に入っています。長期タスクに何が入るか、またはそれをどう考えるか。ここから理論から実際のタスクをまとめるのに何が必要かという実践的な土地に少し移ります。
もちろん、エージェントがあります。これらについて話すと、エージェントがあり、これはタスクが何をするかを説明します。インフラストラクチャーがあり、これは実際にそれをどう実行するか、どうやってそれを行うかです。プロダクトがあり、これはユーザーがそれをどう使うか、どう相互作用するかです。そして評価があります。それが望んだことをしたか、どれだけうまくやったかです。
エージェントについては、目標仕様について考えることになり、これは以前とは少し異なります。何が起こることを望むかを段階的に指定する代わりに、望む最終状態が何かを指定する必要があります。また、ツールも指定したいでしょう。これにより、持っている異なるリソースへのアクセスが与えられ、このようにエージェントが自分のシステムと相互作用できるようになります。これは委譲も使いたい場所です。もう一つのエージェントと話して完了を待つだけではありません。
他のタスクも開始できるかもしれません。そして非同期長時間実行関数呼び出しとヒューマンループとの相互作用をどう選ぶかです。インフラストラクチャーでは、これらの並列タスクと並列実行、そして一つのエージェントとプロダクトとバックエンド間の状態管理方法について考え始めます。ランタイム環境もあります。
Codexは持っている異なるリポジトリのそれぞれにランタイム環境を持っており、皆さんも一つを設定したいかもしれません。そしてこれは障害、再試行をどう処理するかを選ぶ場所でもあります。これは、エージェントがあり、これらの概念があり、どう実際にそれらを実行するか、そしてコードと皆さんのバックエンドアーキテクチャでどのように見えるかという細部です。
それから、ユーザーがどう相互作用し、何を見るかを選ぶプロダクトがあります。ここで進捗を表面化できます。エージェントが何をしているかをどうユーザーに情報を提供し続けるかです。これはまた、タスクを実際に達成するためにエージェントが必要とするすべてのコンテキストを提供するためにユーザーと基本的に作業する場所です。
これはユーザーに聞くことで明示的にするかもしれませんし、コンテキスト自体やアプリケーションコンテキスト自体から収集するという明示的な方法かもしれません。そしてこれは、タスクをどう視覚化するかを選ぶことができる場所でもあります。Codexは下にこのタスクのリストがあり、それを開くと、これらの素敵なアニメーションでやっていることすべてを見ることができます。
これは実際に楽しむことができる場所です。ユーザーをどう楽しませ続け、何が起こっているかへの洞察を与えるかです。どこからのものか思い出せませんが、舞台裏で何が起こっているかわからず、ただ待っているユーザーは、a より多くのストレスを感じ、いらいらし、b 実際に何が起こっているかを見ていなければ、出力をより信頼しないということは非常に直感的だと思います。
最後に、評価があります。ここで評価が入ります。例を収集し、どう評価したいかを定義したい場所です。これは以前とは少し異なり、チャット会話でターンバイターンで評価することを本当に望んでいました。これは使用していた最も一般的な方法でした。
今、タスクでは、実際に最終結果により興味があり、モデルが取った各ターンがどうだったかにはそれほど興味がありません。ルーブリックを与え、探している基準を説明する、しばしばLLMベースのグレーダーのようなものを設定したいかもしれません。
企業と働く際に人々と一緒に座り、「これは良いですか？」と聞いて、イエスかノーを言ってもらい、「なぜですか？」と聞いて、質問し、本当にタスクを分解し、何が何かを良くするのかを聞くのが好きです。ここでのちょっとした先取りは、もしいくつかの例があれば、実際にモデルを微調整してグレーダーにすることができることです。
これは実際に、ローンチした強化ファインチューニングの素晴らしいケースで、良いゴールデン例のセットがあればそれで訓練できます。そして最後にトレーシング、これらすべてを行うために、評価は単に評価を実行することだけでなく、ユーザーとの相互作用中にオンラインで監視、評価することも重要です。
これらは本当にタスクに入る部分で、それらをどう構築するかを考える時です。これで十分だと思います。そして、ええ、ここで異なるグループに物事を置きましたが、すべては本当につながっています。非同期とヒューマンループはインフラストラクチャーで長時間実行するタスクを継続することと関係があるかもしれませんし、プロダクトは委譲を含むかもしれません。
これは4つの角と言いましょうが、それらの間に明確な線はありません。それを踏まえて、コーディングを始める時だと思います。
ライブコーディングデモ
では、タスクの実装に挑戦してみましょう。今日のプロンプトは、たくさんのチケット、チケットのバックログがあるとしましょう。顧客フィードバックなど。それらを実際に受け取って解決できるエージェンシックタスクシステムを構築しましょう。
これは少し広範ですが、実践でこれらのエージェントがどれだけ広範囲に働くかを示すためです。これは問題を無視しましょう。これが大まかに私たちが目指しているものです。いくつかの異なるタスクを持つこの顧客サービスポータルやフィードバックポータルがあるとしましょう。
実装したいのは、実際にこれらのタスクを取って操作できるこのシステムです。そしてこれは、エージェントの定義、それを実行するインフラストラクチャーの定義、そしてユーザーが持つ相互作用やそれをどう見るかの定義が必要になります。
非常にシンプルな方法でエージェントから始めましょう。これは実際に既に非常に強力なAPI呼び出しです。レスポンスを指定する時、実際にホスティングツールを与えて、バックグラウンドで実行させることができます。昨日、この多くを取って少し簡単にするバックグラウンドモードをローンチしたので、これを追加しました。ローカル関数呼び出しを使わず、MCPとホスティングツールだけを行っている場合です。通り抜けることがたくさんあるので、今はこれをスキップします。
最初のことは、アシスタンス、すみませんエージェントSDKを使うことです。このSDKが行うのは、実際に私の最初のBuild Hourで実装したこのループをラップすることで、それはエージェントの実装でした。
非常に似ていて、swarmを知っていればそれに基づいています。ここに最もシンプルなエージェントがあり、どんな相互作用かを見るために早速実行してみましょう。
こんにちは。今日見ている皆さんに挨拶してもらえますか。見ての通り、結果をストリームでき、推論を見ることができます。素晴らしい。o3はかなりフレンドリーです。
この点に到達するのに前回は実際にたくさんの作業がかかったのが面白いですが、今はエージェントSDKがあるので、本当にクイックエージェントをまとめるだけです。では、いくつかのツールを追加し始めましょう。これに戻ると、タスクの一つを見てみたいかもしれません。「顧客が月額サブスクリプションで二回請求されたと報告している」と言っています。
では、エージェントが使用するツールを構築し始めましょう。ツールと、プロンプトと目標の指定方法について考える必要があります。コードを準備してありますが、皆さんと一緒にライブでやるのが好きです。では、いくつかの関数を入力し始めましょう。
カーソルがここで非常に役立ちます。私が何をしたいかをすでに知っているようです。ウェブを検索するのではなく、代わりにユーザーデータを取得できるアクセスを与えたいと言いましょう。ユーザー名を取ることができ、いくつかのモックデータを返すことができ、最近の注文履歴を含むように聞きましょう。
これで、ユーザーをクエリする時、swarmと似て、Pythonで関数を指定するだけで、実際にこれを取って適切なスキーマに変換し、モデルに与えて実行します。これを行う非常に素敵な方法です。
この最初の関数があります。これを本当に早く試してみましょう。私は、ミランです、私は動揺しています、なぜなら、実際にこれは全くゴールではありません。ゴールを選びましょう。ユーザーデータがあり、それから払い戻しのような他の関数を追加しましょう。払い戻し。モックアウトしましょう。そして注文のものを作りましょう。注文詳細を取得します。
カーソルは実際に素晴らしいです。ここで設定したのは、最近の注文を取得するこの能力を持ちたいということです。それからこれらの注文を取って価格を含む詳細を返すことができます。このフローで、モデルが払い戻しを実行できるようにしたい場合、関数、問題を指定し、すべてを理解させたいと思います。これはすべてライブなので、何でも起こり得ます。でも見てみましょう。
私は最後に得たものが本当に嫌いでした。払い戻しが欲しいです。モデルが推論しています。私の最近の注文をチェックしてもらえますか？今、最初の関数を使って注文を取得します。私にそれらを示します。ここで見ているのはかなりまだ相互作用的です。これは通常のアプローチです。でも指示を追加しましょう。
これが最終状態を指定することがステップを指定するよりも重要な理由です。必要なすべてのコンテキストを前もって取得してください。それから、さらに求めずにタスクを完了まで実行してください。もう一つ追加しましょう。必要なものがすべて揃っていれば、とにかく進んでください。これは皆さんが本当にしたいことではないかもしれませんが、これは私が言えることを示すためです。私はElanで、最後の注文で払い戻しが欲しいです。見てみましょう。
ユーザーデータを取得しています。注文詳細を取得しています。払い戻しを叩いています。以上です。最終状態を指定することで、実際にツールだけに基づいてそこに到達するのに必要なステップをモデルに見つけ出させることができることを示すためです。これがシンプルなスタートでした。では、プロダクトと実際の統合に移りましょう。
バックエンド統合
このフロントエンドがある場合、実際にバックエンドに接続したいでしょう。現在PythonにあるエージェントSDKを使い続けるために、JavaScriptのものも間もなく登場します。非常にシンプルなFlaskセットアップのようなものを設定したいでしょう。手動でやってこれを皆さんにお見せします。
クイックサーバーをしましょう。ここに一つありますね。Flaskから始めましょう。非常に基本的なFlaskサーバーです。タスクエンドポイントがあるとしましょう。ここで実際にタスクを実行するためにエージェントを実行したいと思います。このパターンと結果をストリームで返します。
このパターンは何と呼べばいいかわかりませんが、前景タスクのようなものかもしれません。基本的に、フロントエンドがそれに接続する時、接続がタスクを生き続けさせるものだということを意味します。スライドに戻ると、これがこれになるもので、各新しい接続が実際に自分のタスクを開始し、接続がフロントエンドから管理されます。
これは、まず第一に実装が非常にシンプルで、第二に、このように実装すれば、接続する時に基本的にそのタスクのイベントのストリームを受け取ることになるので有用です。
実際にここでシンプルサーバーから始めましょう。歩いていきます。通常のライブBuild Hourでタイプするよりも少しコードが多いので、簡単に、ゆっくり行きましょう。最初にSSEエンドポイントになるエンドポイントを定義します。ボディから入力項目と前のレスポンスIDを取得します。アシスタンスAPI runner.runstreamsを使います。それが行うのは、エージェントが行っているすべてのイベントのストリームを与えてくれることです。定義したエージェントを渡します。
定義した場所はどこだったか、one_agentにあったと思います。そこからインポートします。そう、50/50です。そのインポート名を気に入っていません。大丈夫です。別の実装済みのものがあります。それを使います。すぐにお見せします。でも基本的に、このランナーがあり、実行でき、
それからイベントのそれぞれに対して、エージェントSDKから異なる種類のイベントを実際に取得します。生のレスポンスイベントを取得したく、これはエージェントSDKがデフォルトでResponses APIに支えられているため、Responses APIから来る実際のイベントを表します。このイベントストリームで定義していることは、それを実行し、それらを返してSSEでエンコードすることです。
これはほぼパイピングですが、この中に何が入るかをお見せすることが重要だと思います。最後にdoneのようなものをyieldし、それからストリームを返します。既にこれで、フロントエンドからバックエンドへの接続を作り、イベントを実行し、すべてが戻ってくるのを待つようなものを実装しています。
プロトタイピングや何かを作っている場合には、これは始めるのに良い場所です。しかし実際には、バックグラウンドで作成され、それから切断されるタスクを処理できるようにしたいかもしれません。これはChatGPTで見ることができ、何かを入力して完全に閉じ、後で戻ってくると完了しているでしょう。
これは、バックグラウンドタスクビューとは異なるアプローチで実装されています。実際に使用するフロントエンド用に、このアーキテクチャを歩くのに少し時間を取りましょう。
フロントエンドがあり、これはタスクを持つバックエンドと歩調を合わせる必要があります。できることは、バックエンドへのイベント接続を開いて、バックエンドからすべての新しいタスクイベントを受信することです。これらのイベントとは何でしょうか。これは、タスクに新しい項目を追加したり、ToDoを更新したり、基本的にこれらのタスクの状態を変更する任意のものです。
では、これを実際にどう開始するのでしょうか。タスクエンドポイントを使用できます。ここで黄色でラベル付けしたものは開いたままにしておくことを意図したSSEエンドポイントです。グレーでラベル付けしたものは単なるPOSTリクエストで、これはバックグラウンドタスクの形を持ちます。ストリームを開始するPOSTリクエストを作るだけで、それで終わり、切断し、実際にどこからでもこのタスクを開始できます。
このアーキテクチャは実際にうまく拡張できます。バックエンドを持っていれば実装できることは、実際にエージェントを実行する責任を持つタスクキューにタスクを送信することです。それからそこから出てくる任意のイベントを取り、どのタスクに関連するかと関連付けて、ストリームで戻します。
これがメインアーキテクチャです。実装が実際にどのように見えるかを歩いて行きましょう。たくさんのことが進行中なので、ゆっくり行きます。これは定義しているタスクオブジェクトです。IDを持ちたいだけです。この項目リストは、実際にエージェントの会話履歴またはアクション履歴を構成する項目を表します。
少しの間ToDoに入ります。今これを削除しましょう。そしてこのステータスがあります。ここで持っているグローバル変数は、実際にはどこかに永続化したいかもしれませんが、このデモでは行いません。それらは、そのIDからマップされた実際のタスクです。この非同期ioイベントQ、これは基本的にバックグラウンドで考慮しているものを実行させてくれます。
それから私たちのfast APIです。一番下まで行って、持っている2つのルートをお見せします。これが先ほど図で示した2つのルートです。最初のものはイベントルートです。見ての通り、それは非常にシンプルです。少しフォローするのが難しいかもしれませんが、基本的にそれが行うのは、永遠に、接続を開始するとすぐに、これらのイベントを永遠にストリームすることです。
このイベントQが何かを受信するのを待ち、それをフロントエンドに転送します。それだけです。このイベントQから取ってフロントエンドに送信するだけです。これが重要な理由がわかるでしょう。このイベントQがある時、フレンドが接続できるこのエンドポイントがあれば、このイベントQにプッシュするものがフロントエンドにルーティングされることを保証するだけです。
できることは、任意のエージェントからこのイベントQまでの更新をプッシュすることです。それがイベント、イベントエンドポイントです。では、タスクエンドポイントを見てみましょう。
以前と同じように、ボディを取り、解析し、項目を取り出し、前のレスポンスIDを取り出します。慣れていない場合、これは前の要求が何であったかを指定する非常に便利な方法で、毎回コンテキストを渡す必要がありません。これは、この思考の連鎖ツール呼び出しを行いたい時に本当に重要になります。モデルが関数を呼び出している時に、実際にその履歴に思考の連鎖の残りを持っていることを確認したいからです。
それで本当に思考の連鎖内の関数呼び出しです。このタスクオブジェクトを作成し、タスクに保存できます。ここが重要な部分です。公開でき、この関数はすぐにお見せしますが、タスクを作成し、タスクIDが何かを公開できます。公開にスクロールアップすると、行っているのは前に話していたイベントQを取り、イベント自体を与え、フロントエンドが取ってデコードできるようにSSEとしてエンコードすることです。
最後に、タスクを作成したら、残っているのは実際に私たちのワーカーを開始することです。エージェント、タスクを開始します。このタスクは実際に少しオーバーロードされています。これはasync.ioライブラリの一部である関数にすぎません。
タスクを私たちの類推に非常にうまく適合するバックグラウンドタスクのように考えます。async.ioワーカーを取り、すぐに入るワーカー関数を与え、バックグラウンドで開始し、それからフロントエンドが持てるようにタスクIDを返すことができます。
これが美味しい部分が起こる場所です。ワーカーで何が起こっているのでしょうか。以前に持っていたものと非常に似ています。行っているのは、ランナーを取り、プロンプトと定義されたツールを含むエージェントを与え、ユーザーからの入力である入力項目を与え、前の会話と一貫性を保てるように前のレスポンスIDを与え、コンテキスト変数でタスクを与えることです。これは後で重要になります。自分のタスクを変更できるようにするためです。
これはエージェントSDKの素敵なパターンで、エージェントランナーにオブジェクトやコンテキストを供給できるようにし、エージェントが実行している時にLLMのコンテキストには含まれませんが、関数呼び出しでアクセス可能になります。モデルはデフォルトでそれを見ませんが、メモリバンクのように使用できます。
メモリには見えませんが、それに変更を加えることができます。単に便利な方法です。クロージャや、この実行と一緒に追跡される任意の種類の状態を表す方法です。それから以前にあったもので、すべてのイベントに対してフィルターアウトし、レスポンスイベントであるすべてのものについて、フロントエンドがそれらを実際にレンダリングできるように公開します。max_turnsも100に設定します。これは望む任意の値に設定できます。
素晴らしい。これはエージェントが完了するまで実行し、それからタスクを完了に設定し、更新をプッシュダウンします。このパターンがよく見えるでしょう。タスクオブジェクトに更新を行い、それから同じ更新をフロントエンドにプッシュダウンし、それは同期を保つためです。
バックエンドで表すタスクは、フロントエンドで表すものと同じです。これはたくさんありましたが、実際に持っているすべてです。実際にタスクを開始してタスクIDを返すタスクエンドポイント、フロントエンドをバックエンドに接続してすべてのタスクからすべてのイベントをストリームするイベントエンドポイント、そして実際のワーカーがあり、ランナーを取ってストリーミングモードで実行し、それからすべてのイベントを公開してフロントエンドが持てるようにします。
図に戻ってこれがどのように見えるかを見ることができるでしょう。これが作ったものです。タスクを開始でき、タスクビューに渡し、エージェントを実行し、それからイベントを戻すシステムを作りました。
では見てみましょう。最高のショットを持てるように、すべてをリフレッシュします。左側で、フロントエンドを実行しているので、再度実行します。ここにバックエンドがあります。嘘をついていないか確認しましょう。実際のワンサーバーを実行します。現在エージェントをインポートしていますが、すでに定義したものがとても素晴らしかったので、これを使いましょう。
本当にこれを取って引き込むことができます。これは最高のベストプラクティスではありませんが、名前をmy_agentに変更します。ここからmy agentができます。素晴らしい。これはすべてライブです。動くかもしれませんし、動かないかもしれません。でも基本的にここで行ったことは、先ほど定義したエージェントを実行してフロントエンドで見ることです。
server Qは、これもインポートしたでしょうか。これをkillしましょう。再実行しましょう。フロントエンドに戻ります。これを再実行します。すべてが正しく起こったなら、調査開始をヒットする時、今ウェブサイトに接続した時、実際にサーバーでウェブサイトからバックエンドへのget eventsの呼び出しが送信されたのを見ることができます。
イベントの受信を開始し、現在何もストリームしていません。でも調査開始をヒットすると、コンテキストを提供し、タスクを開始し、イベントが実際にバックエンドからストリーミングされているのを見ることができます。すべてを一緒に提供したので、ユーザーデータを取得するつもりです。それから正しいツールを与えなかったので、何かできないと言うかもしれません。
そう、私たちがこのウェブサイト用にこのエージェントを設計していなかったので、いくつかの応答をくれました。では、実際にこのウェブサイト用にエージェントを設計しましょう。これのために、先ほど定義したこのエージェントに入ります。
プロンプトを見ると、あなたは役立つアシスタントです。今はToDoを無視します。非対話モードで実行しています。最終出力。素晴らしい。ここで言っているのは、完了するまで続けるということです。ToDoについて何も削除します。すぐにそれに入ります。でもすべてをリフレッシュすれば。
すべての動きについて申し訳ありません。それなら実際にこの新しいエージェントを使っているはずです。このエージェントは何ができるでしょうか。天気を取得、オープンチケットを検索、ドキュメントを読む、カテゴリ別にランブックを取得、ポリシーを検索、メールを取得、チケットを追加、ドキュメントを書く。これらの関数を上に指定しました。基本的にこれらすべてに対してモックデータを返すこのモックAPIを作りました。
これは先ほど行っていたことの延長にすぎません。実際には、明らかにモックAPIを叩く代わりに、本物のAPIを叩くでしょう。すべては同じように動作するでしょう。これを試してみましょう。ここで開始すると、タスクを開始します。今は進捗を無視してください。それが次にすることです。でも推論が起こっているのを見ることができるはずです。
ストリームしているすべてのイベントから、実際に複数のタスクを並行して実行できます。ここで推論が起こっているのを見ることができます。ユーザーデータを取得。ロードしています。これについては、異なるプロセスを通ります。すぐにあきらめるつもりでしょうか。たぶんそうでしょう。スイッチアウトしなかったのでしょうか。申し訳ありません。
ここに行って、これを使うことからserver agentsを再び使うことに戻りましょう。これをします。素晴らしい。今、定義した関数を実際に通り、段階的に進んでいるのを見ることができ、いくつかの進捗を見ることができます。でも、より多くの洞察を持てるといいでしょう。
プロダクト面での進捗表示
ここでプロダクト面に戻ります。どうユーザーに進捗を表示するかです。思考の連鎖イベントはそれを行う素敵な方法で、それをレンダリングする他の方法もあります。でもToDoを作ったり、モデルに基本的にユーザーに進捗を表示する関数を持たせるクールなパターンがあります。
これをどう実装するでしょうか。できることは、タスクオブジェクトを取ってこのToDoフィールドを追加することです。このToDoフィールドを追加したら、今のところ何もしません。でも魔法は、モデルにこのToDoフィールドを更新する関数を与える時に起こります。
これは先ほど実装していたものと同じような新しい関数ですが、少しメタです。実際に先ほど渡したコンテキストのタスクを使用します。モデルは実行したい実際のタスクを供給できます。ToDoのテキストのそれぞれに対して、新しいToDoを作成します。実際のタスクに追加して、それを公開し戻します。それからToDoをチェックオフする関数も与えます。
何をしたでしょうか。これら2つの追加関数を宣言し、それからToDoを追加し、ToDoを設定するためにエージェントに追加します。これは非常に小さなことですが、動作する時には非常に魔法的に感じます。それを見てみましょう。削除したものを追加したいかもしれません。
Now everything about to-dos is there. 常にToDoでプランを作成し、常にToDoを設定することから始め、進むにつれてチェックオフします。指をクロスします。同じタスクを再度試してみましょう。運が良ければ、モデルが望んだことを行えば、サスペンスが私を殺しています。
タダー！今いくつかのToDoがあります。フロントエンドでそれらを見ることができます。実際に私たちの進捗とアイドルを駆動できます。モデルが進むにつれて、どのくらい進んでいるかに対するこの種の魔法的な洞察を得られます。監視システムや他の部分を構築することなく。モデルに進み、チェックオフしてもらうだけです。以前と同じように、複数を並行して開始でき、実際に、私はチャットインターフェースの大ファンではありません。クリックするのが好きです。
すべてのコンテキストを取得して押し込むこの方法。モデルが必要とするすべてを持つのは、私の意見では非常に楽しいユーザー体験です。とにかく、今通り抜けたのを見ることができます。
ToDoをチェックする関数呼び出しを見ない理由を疑問に思うかもしれませんが、答えは、フロントエンドで明示的にそれらをフィルターアウトしているからです。これが魔法の一部を保つ方法です。ユーザーにそれをどう行っているかを見せなければ、進み続けて、ToDoをチェックオフすることなく、より自然に見えるでしょう。
でも、少し時間を取って、これを受け入れてください。これが皆さんのプロダクトにとって何を意味するでしょうか。これらの長期タスクや目標の達成、複数のよりオープンエンドのステップを必要とする任意のものから利益を得る場所があれば、これは実際に非常に有用で、バックグラウンドでタスクを実行し、進捗を表示するこれらのパターンは本当に便利になります。
委譲について
戻ると、委譲についての全体的な他の部分があります。あまり深く入らないかもしれません。本当に早く話し合うかもしれません。委譲は、今私が手動でタスクを開始しているという概念です。このタスクがある前のように。
モデルにそれらを開始してもらいたい場合はどうでしょうか。クリックする代わりに、実際に私はクリックが大好きですが、誤解しないでください、でもChatGPTや皆さんのエージェントに実際にタスクを開始させたいが、それと話し続けることができる場合はどうでしょうか。コンテキスト収集を前面に出すこのパターンを実装できます。フォローアップ質問を聞きます。
Deep Researchを使った場合、これは長いタスクを開始する前に感じるものです。十分な情報を持っているかを確認します。即座に返る関数呼び出しでそのタスクを開始し、それと話し続けることができます。
一方で、タスクは、実行したものに類似したアーキテクチャでバックグラウンドで実行されています。それと話し続けることができます。それは非ブロッキングです。これはオプションですが、私がかなり気に入るアプローチで、それから完了すると実際に戻ってきて更新してくれます。委譲の例を含めました。本当に早く進む十分な時間があると思います。なぜそうしないのでしょうか？
これは再びテキストベースです。このためのUIを構築しませんでしたが、話さないと言いました。多分そうするでしょう。これをバックグラウンドで実行するシステムが必要です。例えばo3を呼び出す関数呼び出しをするだけの場合。フロントエンドでは、例えばGPT-4o miniと話しているかもしれません。これを有効にしていない場合、例えばここに行って言うと、画面に持っているものを思い出させるために、現在設定されていないツールを持たないエージェントがあります。
o4 miniです。この2つのツールを設定しましょう。これらのタスクは何をしているのでしょうか。この関数は入力でResponses APIを呼び出すだけです。それからget tasksでこれを取得できます。今これはあまり面白くありません。何か難しいことをお願いします。詩を書いてください。すべての単語が次のプライム数で始まるように、アルファベットにインデックスしていたら、そのようなものです。
o4 miniにこれを求めた場合、おそらくできないでしょう。でも、これでタスクを開始してくださいと言います。これに戻ると、実際にo3を呼び出すつもりです。これが動作するか見てみましょう。本当に試しただけでした。
指示を言います。ユーザーが何か難しすぎることを聞いた場合、それでタスクを開始してください。
それを再度試してみましょう。これを入力したくないので、コピーします。実際に良い仕事をしたかもしれません。わお、o4 miniは良いモデルです。でもこの例では、本当に関数を呼び出すだけにしたかったのです。タスクを開始します。このタスクは何をしているのでしょうか。o3からの応答を待っています。o3はこれを非常に非常に慎重に行うつもりです。
実際にそのための作業の一部をしました。わお、o4は本当に良いモデルです。でもブロックしています。o1 o3が完了するまで、ここに座って話し続けることはできません。しかし、バックグラウンドタスクを有効にすると、できることは非常に似ていることですが、今すぐに返るはずです。これを言います。タスクを開始し、それから続けることができるはずです。なぜ私を喜ばせないのでしょうか。500。昨日ローンチしました。今はこれを無視します。
でもここでお見せしたいのは、OpenAIに依存しているか、自分で実装したもののようなバックグラウンドシステムを持っている場合、関数呼び出しを使ってバックグラウンドで起こるタスクを基本的にハンドオフではなく委譲でき、それからメインエージェントに更新をチェックしたりプッシュしたりできることです。
ユーザーへの体験は非ブロッキングで、それと話し続けることができ、それらにサービスできることです。残念ながら今お見せできませんでした。見てみましょう。シンプルサーバーを持っているかもしれません。これを試すべきでしょうか？少し、いいえ、これはブロックします。他のものでできますが、あまりライブで混乱したくありません。
もう少しやりすぎました。でもバックエンドシステムがあることを信じてもらえるでしょうか。できることは、すぐに返る開始する関数を持つことで、動作し続けるでしょう。
質問と回答セッション
ここで終わりたいと思うので、質問に直接入ることができます。話さなかった、話したかったいくつかのことがあります。後でより多くのリソースを共有しますが、質問に飛びましょう。
やりましょう。デッキを戻してくれれば、実際にいくつか入れました。更新してもらえますか？そうです。
逐次および条件付きツール呼び出しを調整する最も効率的な方法は何でしょうか。時々この質問を受けます。エージェンシック呼び出しの要点は、逐次や条件付きのような期待を持たないということで、モデルに何でもしてほしい、解決策にたどり着く方法を見つけ出してほしいだけということなので、常に興味深い質問です。
それは言ったものの、逐次や条件付きのようなものが欲しい場合、Pythonを使ってください。コードは逐次および条件付きのことを表現する素晴らしい方法です。o3に3つの関数を連続で常に呼び出してほしい場合、それらの3つの関数を呼び出すことを期待する代わりに、これもより高いレイテンシーでより高価になります、すべてを一つに入れて、その関数に望んだ3つのことを行わせるだけです。
私の答えはPythonが非常に強力で、このようなタスクが欲しい場所でコードを使うということです。プロンプトでも列挙できます。o3は本当にこれらの指示に従うのが得意です。
長期タスクを処理するエージェントで、メモリはどう管理すべきでしょうか。別の良い質問です。多くの異なる方法があります。自分のコンテキストはかなり良いメモリバンクです。明示的なメモリシステムを持つこともできます。ToDoを作成し、ToDoをチェックオフしていた非常に似た方法で、モデルが実際に見ることができない外部状態で、コンテキストにありません。
必要に応じて後で物事を記憶し、事実を保存し、それらを呼び出す方法をモデルに与えるメモリシステムを実装したいかもしれません。ベクターストアや類似のものを使って。実際にChatGPTのメモリの元のバージョンで非常に似ることをしました。言ったことに基づいて事実を保存することを明示的に選択でき、後でプロンプトに類似の事実を持ち込むことができました。
それを行う方法は、これらのベクター比較、埋め込み比較を行うことです。あまり詳しく入りませんが、多くの方法があります。外部メモリストアが有用です。
ツールが多すぎるのは何個でしょうか。かなり多く取ることができます。20個以下にとどまるようにしています。これは非常に非常に非常にヒューリスティックです。でもその時点では、それが処理できるかどうかということではありません。本当に何を説明しているのかということです。エージェントSDK、ここで入りませんでしたが、ハンドオフの概念を持っています。
エージェントとアシスタンスBuild Hourでこれをチェックアウトすると、より深く入りますが、基本的に最適なツールを持つものが毎回再ルーティングされる必要がない方法でそれを得る、お互いに会話を渡したりハンドオフしたりできる複数の異なるエージェントを指定できます。20個ぐらいかもしれません。
OpenAIのホスティング関数を自分のカスタム関数と一緒に使用できますか？もちろんです。これは実際に本当に素晴らしいパターンで、ここでは実装しませんでしたが、例えばコードインタープリターを使ってデータベースクエリからの結果を分析したい場合、絶対にできます。特定の情報を取得したり、例えば数値や表をロードする関数を持つことができ、それからモデルがそれを行うことを選択し、コードインタープリターを使って実行し、結果を与えます。はい、これらを一緒に使うことは実際に強く推奨されます。
Responses APIはMCPをサポートしていますか？昨日の時点で、はい。昨日の時点で、任意のリモートMCPサーバーを実際にResponses APIに追加でき、それらのリモート呼び出しを行います。これが実際にバックグラウンドモードの魔法が入る場所です。通常、Responses APIがエージェントが完了する前に戻ってくる唯一の理由は、自分のローカル関数を実行してほしい時です。
でも、ローカル関数がなく、リモートMCPサーバーですべてを実装している場合、実際にそれを実行してbackgroundをtrueに設定し、忘れて後でチェックインするだけです。それは基本的に、これらすべての異なることを行える一つの非常に長いResponses API呼び出しになります。
MCPファイル検索、画像生成など。オーキードーキー。この人に気づきました。これはかわいいです。これを追加する必要がありました。本当に甘いです。質問に答えている部屋のみんながこれで笑顔になりました。ですから、これが役立ったことを嬉しく思いますし、エージェントの仕方を教える時間を取っていただいて本当に感謝しています。
それが大好きでした。これはかわいい。かわいいです。気に入りました。他にありますか？それとも最後でしたか？いいえ、それが最後でした。時間通りに完璧に進んでいます。リソースの次のスライドに行ってください。
Alainが以前に構築したことのない多くのことをライブで行い、この素晴らしい1時間の構築を祝福してくれてありがとう。いいえ、これをすべて構築しているOpenAIのみんなに祝福されています。これはOpenAIのみんなのおかげで可能です。
リソースとまとめ
そうです。そうですね。幸せなメモで終わるなんて。いくつかのリソースでフォローアップします。前のBuild Hourからすべてのリポジトリを持つGitHubを共有します。
録画されたBuild Hourと同様に、ランディングページで今後のBuild Hourを見ることができます。Alainともっと時間を過ごしたい場合、アシスタンスとエージェントについて話す彼の以前のBuild Hourを見ることができます。それからエージェント構築のための実践的なガイドのリンクも送ります。チャットから入ってきていたいくつかの質問については、これが本当に良い出発点になると思います。
次のBuild Hourは来週で、Image GenとAPIについてすべてです。通過する多くの本当にエキサイティングなデモ、共有する顧客ストーリーがあり、より多くのBuild Hourで皆さんにお会いできることを楽しみにしています。ご視聴ありがとうございます。ハッピービルディング。
コメント