エージェント構築のための新しいツール
(openai.com)- OpenAIは、本番運用向けエージェントの開発を容易にするため、Responses API、組み込みツール、Agents SDK、オブザーバビリティツールを公開した
- Responses APIは、Chat Completions APIのシンプルさとAssistants APIのツール利用機能を組み合わせ、Web検索・ファイル検索・コンピュータ操作を1つのフローで扱えるようにする
- 新しい統合ではResponses APIの利用を推奨しており、Assistants APIは機能同等性を確保した後、2026年半ばの終了を目標として廃止プロセスに入る予定
- 組み込みツールは、最新のWeb情報、大規模ドキュメント検索、マウス・キーボードベースのコンピュータ作業自動化を支援するが、computer useは特にブラウザ外の環境で人による監督が推奨される
- 開発者は、API、ツール、SDK、トレース・評価機能を1つのプラットフォーム上で組み合わせ、エージェントを構築・配備・最適化できる
エージェント開発のための新コンポーネント
- OpenAIはエージェントを、ユーザーに代わって作業を自律的に実行するシステムと捉えている
- 過去1年間で、高度な推論、マルチモーダルな相互作用、新しい安全技術が導入され、複雑な多段階タスクを処理する基盤が整ってきた
- 顧客は、これらの機能を本番対応のエージェントへ変換する過程で困難に直面していた
- 広範なプロンプト反復が必要
- カスタムのオーケストレーションロジックを自分で作る必要がある
- 十分な可視性と組み込みサポートが不足している
- 今回公開されたコンポーネントは以下の通り
- Responses API: Chat Completions APIのシンプルさとAssistants APIのツール利用機能を組み合わせる
- 組み込みツール: web search, file search, computer use
- Agents SDK: 単一エージェントおよびマルチエージェントのワークフローをオーケストレーションする
- オブザーバビリティツール: エージェントワークフローの実行を追跡・検査する
Responses API
- Responses APIは、OpenAIの組み込みツールを活用してエージェントを作るための新しいAPIの基本単位
- Chat CompletionsのシンプルさとAssistants APIのツール利用機能を組み合わせている
- 1回のResponses API呼び出しの中で、複数のツールと複数のモデルターンを使い、より複雑なタスクを処理できる
- 初期対応ツールは以下の通り
- Web検索
- ファイル検索
- コンピュータ操作
- 使い勝手の改善も含まれる
- 統合されたitemベース設計
- よりシンプルな多相性
- 直感的なストリーミングイベント
response.output_textのようなSDKヘルパー
- 複数のAPIや外部ベンダーを個別に統合せず、OpenAIモデルと組み込みツールをアプリに組み込みたい開発者向けに設計されている
- OpenAIにデータを保存すれば、トレースと評価機能によってエージェント性能の評価が容易になる
- OpenAIはデフォルトではビジネスデータをモデル学習に利用せず、データがOpenAIに保存されている場合も同様
- すべての開発者が本日から利用でき、追加料金はなく、トークンとツールは価格ページの標準料金で課金される
- 入門ドキュメントはResponses API quickstart guideで提供される
既存APIとの関係
- Chat Completions APIはOpenAIで最も広く採用されているAPIであり、今後も継続してサポートされる
- 組み込みツールを必要としない開発者は引き続き利用できる
- 組み込みツールや複数モデル呼び出しに依存しない機能の新モデルは、今後もChat Completionsに投入される
- Responses APIはChat Completionsの上位集合であり、同等の性能を提供するため、新しい統合にはResponses APIを推奨する
- Assistants APIのベータフィードバックはResponses APIに反映され、より柔軟で高速かつ使いやすくなっている
- Assistantライクなオブジェクト、Threadライクなオブジェクト、Code Interpreterツールを含め、Assistants APIとResponses APIの完全な機能同等性の実現が進行中
- 機能同等性が完了した時点で、Assistants APIの廃止を正式発表する計画
- 目標終了時期は2026年半ば
- 廃止発表時には、データ保持とアプリケーション移行が可能なマイグレーションガイドを提供する予定
- 正式な廃止発表までは、Assistants APIにも新モデルを継続提供する
- OpenAIは、Responses APIをOpenAI上でエージェントを構築する将来の方向性と位置付けている
Responses APIの組み込みツール
-
Web検索
- 開発者は、Webから高速で最新性のある回答を明確な出典引用付きで得られる
- Responses APIでは、Web検索は
gpt-4oおよびgpt-4o-mini利用時のツールとして提供され、他のツールや関数呼び出しと併用できる - 初期テストでのユースケースは、ショッピングアシスタント、リサーチエージェント、旅行予約エージェントのように最新のWeb情報を必要とするアプリとして現れている
- Hebbiaは、Web検索ツールを使って、資産運用会社、プライベートエクイティ・クレジット企業、法律実務家が大規模な公開・非公開データセットから実行可能なインサイトを迅速に抽出できるよう支援している
- APIのWeb検索は、ChatGPT searchで使われているものと同じモデルを基盤としている
- SimpleQAでGPT‑4o search previewは90%、GPT‑4o mini search previewは88%の精度を記録した
- APIのWeb検索レスポンスには、ニュース記事やブログ投稿などの出典リンクが含まれる
- Webサイトやパブリッシャーは、API Web検索に表示されることを選択できる
- Web検索ツールはResponses APIで全開発者にプレビュー提供される
- Chat Completions APIでは、
gpt-4o-search-preview、gpt-4o-mini-search-previewにより検索モデルへ直接アクセスできる - 価格はGPT‑4o searchが1,000クエリあたり30ドル、4o-mini searchが1,000クエリあたり25ドルから
-
ファイル検索
- 改良されたfile searchツールにより、大規模な文書から関連情報を簡単に検索できる
- 複数のファイル形式、クエリ最適化、メタデータフィルタリング、カスタム再ランキングをサポートする
- Responses APIでは数行のコードで統合可能
- ユースケースは以下の通り
- カスタマーサポートエージェントがFAQにアクセスする
- 法務アシスタントが有資格の専門家向けに過去事例を素早く参照する
- コーディングエージェントが技術文書を参照する
- Navanは、AIベースの旅行エージェントでfile searchを使用し、会社の出張ポリシーのようなナレッジベース文書から正確な回答を迅速に提供している
- 組み込みのクエリ最適化と再ランキングにより、追加のチューニングや設定なしでRAGパイプラインを構築できる
- ユーザーグループごとの専用ベクトルストアを用意すれば、アカウント設定やユーザー権限に応じた回答を提供できる
- file searchはResponses APIで全開発者が利用可能
- 利用料金は1,000クエリあたり2.50ドル、ファイル保存は1日あたりGB単位で0.10ドル、最初の1GBは無料
- Assistants APIでも引き続き提供される
- Vector Store APIオブジェクトに新しい検索エンドポイントが追加され、他のアプリケーションやAPIで利用するデータを直接照会できる
-
コンピュータ操作
- computer useツールは、Responses APIでコンピュータ作業を行うエージェントを作成するための機能
- このツールは、Operatorを実現したComputer-Using Agent(CUA)モデルによって駆動される
- 研究プレビューのモデルは以下のベンチマーク結果を記録している
- OSWorld: コンピュータ操作全体のタスクで38.1%
- WebArena: 58.1%
- WebVoyager: Webベースの相互作用で87%
- 組み込みのcomputer useツールは、モデルが生成したマウスおよびキーボード操作をキャプチャする
- 開発者はこの操作を、自身の環境で実行可能なコマンドに変換してコンピュータ作業を自動化できる
- ユースケースは、Webアプリの品質保証や、レガシーシステム間のデータ入力といったブラウザベースのワークフロー自動化
- Unifyは、エージェントが意図把握、アカウント調査、購買担当者への接触を行う売上成長向けシステムでcomputer useツールを利用している
- APIでアクセスできなかった情報も、エージェントが活用できる
- 例として、不動産管理会社がオンライン地図を通じて事業者の不動産規模拡大の有無を確認できる
- Luminaiは、APIや標準化データのないレガシーシステムを持つ大企業の複雑な業務ワークフロー自動化にcomputer useツールを統合している
- ある大規模コミュニティサービス組織のパイロットでは、申請処理と利用者登録手続きを数日で自動化した
- 従来型のRPAでは、同じ作業を数か月試みても達成が難しかった
- CUAをOperatorとして公開する前に、誤用、モデルエラー、フロンティアリスクという3領域について広範な安全テストとレッドチーム演習を実施した
- APIでCUAを通じてOperator機能がローカルOSに拡張されるリスクに対応するため、追加の安全評価とレッドチームも実施された
- 開発者向けの緩和策も追加された
- プロンプトインジェクション防御のための安全チェック
- 機微な作業に対する確認プロンプト
- 環境分離を支援するツール
- 潜在的なポリシー違反に対する強化された検知
- 緩和策はリスクを下げるものの、モデルは特にブラウザ外環境で意図しないミスを起こす可能性がある
- OSWorldでの38.1%という性能は、OS作業自動化においてまだ高い信頼性に達していないことを示しており、この場合は人による監督が推奨される
- APIごとの安全対策の詳細は、更新されたsystem cardで確認できる
Agents SDKとワークフローオーケストレーション
- エージェントには中核ロジックとツールアクセスだけでなく、ワークフローオーケストレーションも必要
- 新しいオープンソースのAgents SDKは、マルチエージェントワークフローのオーケストレーションを簡素化する
- 昨年公開された実験的SDK Swarmより改善されている
- 主な機能は以下の通り
- Agents: 明確な指示と組み込みツールを備えた、簡単に設定できるLLM
- Handoffs: エージェント間で制御権をインテリジェントに引き継ぐ
- Guardrails: 入出力検証のための設定可能な安全チェック
- Tracing & Observability: エージェント実行のトレースを可視化し、デバッグと性能最適化を支援する
- 適用可能な実際のユースケースには、カスタマーサポート自動化、多段階リサーチ、コンテンツ生成、コードレビュー、営業リード発掘がある
- Coinbaseは、Agents SDKを使って、AIエージェントが暗号資産ウォレットやオンチェーン活動と相互作用できるようにするAgentKitを迅速にプロトタイプ・配備した
- 数時間でDeveloper Platform SDKのカスタムアクションを完全動作するエージェントへ統合した
- AgentKitの簡素化されたアーキテクチャにより、新しいエージェントアクションの追加が容易になった
- Boxは、数日でWeb検索とAgents SDKを活用するエージェントを構築し、Box内の非構造化データと公開インターネットソースから検索・照会・インサイト抽出を可能にした
- 企業顧客は、最新情報だけでなく、内部権限とセキュリティポリシーに従った形で社内の独自データを検索できる
- たとえば金融サービス企業は、Boxに保存された社内市場分析とWeb上のリアルタイムニュース・経済データを組み合わせるカスタムエージェントを作成できる
- Agents SDKはResponses APIとChat Completions APIで動作する
- Chat CompletionsスタイルのAPIエンドポイントを提供していれば、他プロバイダーのモデルとも併用できる
- Pythonコードベースにはすぐ統合でき、Node.js対応は近日提供予定
- OpenAIはAgents SDKの設計において、Pydantic、Griffe、MkDocsの取り組みから着想を得ている
- Agents SDKをオープンソースフレームワークとして継続的に構築し、コミュニティがアプローチを拡張できるようにする計画
エージェントプラットフォームの拡張方針
- OpenAIは、エージェントがまもなく労働力の中核要素となり、産業全体の生産性を大きく高めると見ている
- 企業による複雑な作業へのAI活用需要が高まる中、開発者と企業が実際にインパクトを生む自律システムを構築できるコンポーネント提供に注力している
- 今回の公開は、信頼性が高く高性能なAIエージェントを、より簡単に構築・配備・拡張するための最初のコンポーネント群である
- モデル機能がよりエージェント指向へ進化するにつれ、OpenAIはAPI全体でのより深い統合と、本番エージェントの配備・評価・最適化を支援する新ツールへの投資を続ける計画
- 目標は、あらゆる業界の多様な作業を支援できるエージェントを作るためのシームレスなプラットフォーム体験を提供すること
1件のコメント
Hacker News の意見
実際の製品に OpenAI を組み込もうとしている開発者にとって、こうした API の変動がどれほど役に立つのか分からない
会話、メッセージ、プロンプトの受け渡しなどを扱うベンダー管理の状態機械は、自分の用途では結局不足していたり、前提を置きすぎていたり、邪魔になったりした
結局、構造化出力だけを有効にした Chat Completions APIを使うことになり、その中でもツール利用、再帰的な会話、RAG などは十分にできている
自分の「エージェント」の状態管理をサードパーティに任せる価値は感じないし、こういうものはローカルに置いたほうがはるかに自律的でいられる
要は、何らかの文字列リテラルをブラックボックスに入れると、新しい文字列、できれば JSON のような指定した形式で受け取る、というだけのこと
毎回適切な文字列を組み立てるという視点に集中すれば、残りは消えて、データベース上のビジネス状態から高度に構造化された文字列を作る作業と同じになる
PHP で Web ページをサーバーサイドレンダリングするのと実質的に同じ作業で、本当の違いは提供方法だけ
単純な 構造化生成呼び出しの上に、自分に必要なものを足してくれるエージェントフレームワークはまだ見つけられていない
LLM リクエストの大半は「プロンプト入力、構造化出力」であるべきで、これは一つのことをうまくやるという Unix 哲学にも合っている
エージェントフレームワークは時期尚早で、まだ一般的ではない設計パターンの束を抽象化した層にすぎない
誰もが車輪を再発明しているのが明らかなときにだけ抽象化を作るべきだが、エージェントには発明すべき車輪はなく、すべて単純な言語モデル呼び出しだ
「言語モデルはコードの中でいちばん面白くない部分であるべきだ」とよく言っている
ほとんどの時間は実際のソフトウェアとツールを作ることに使うべきで、LLM はソフトウェアの小さな構成要素であるべきだ
エージェントフレームワークは、自分の好みからするとコードベース内での言語モデルの存在感を大きくしすぎる
OpenAI の function calling という抽象化でさえ、パラメータやスキーマを幻覚するし、JSON Schema 自体も冗長すぎて、ごく単純な関数呼び出し 5 個より少し複雑になるだけで完全に崩れる
すでに壊れているブラックボックス抽象化の上にさらに積み上げているように見え、実際のアプリケーションにはあまり役に立たない
小さな概念実証アプリを素早く作るには役立つかもしれない
こういう API の上に会社を築こうとするなら、ナイーブでないと無理だ
LLM はコモディティになるだろうし、OpenAI は企業価値と今後も必要になる投資規模を正当化するには、その運命に抗うしかない
Assistant API の上に作っていたなら、ヒントを受け取って Responses API にただ書き直すのではなく、自分の製品を所有すべきだ
今日の LLM はブラックボックスとして包んでおくほうがいい
「Chat Completions を使う場合、モデルは常に応答前に Web から情報を取得します。gpt-4o や gpt-4o-mini のようなモデルに、必要な場合だけ web_search_preview をツールとして呼び出させたいなら、Responses API に移行してください」という部分のせいだ
新しい Responses API へ移植するのは簡単ではないし、こちらにはすでに履歴、RAG、アシスタントに必要なものがそろっている
function calling と構造化出力だけで複数の エージェントを開発し、1 年以上本番環境で動かしている
以前はこれをエージェントとすら呼んでいなかった
今回のものは、すでにエージェントフレームワークと OpenAI API を併用している人たちを狙ったもののように見える
新しい API の設計者が、いくつかの設計判断の背景を説明している良い Twitter スレッドがある: https://twitter.com/athyuttamre/status/1899541471532867821
Twitter にログインしていない人向けの代替リンクもある: https://nitter.net/athyuttamre/status/1899541471532867821
こうした AI エージェントの試みは、核心からずれているように思う
新しいやり方を作るのではなく、既存システムの中で人間を置き換えようとしているからだ
経済も生活も、すべては結局 人と人との相互作用に関するものなので、根本的に近視眼的だ
現在の AI エージェントのアプローチは、「一文を AI が長くもっともらしいメールに引き伸ばし、受け取る側の AI がその長いメールをまた一文に要約する」という冗談の変奏のように見える
既存システムの作業を自動化する有用性は理解できるが、本当の機会は既存システムの大半を取り除くことにある
人間はそこまで悪くない
AI で人間向け UI を作り、さらに AI にその UI を操作させることが、本当に前に進む道なのか疑問だ
手で折った木の枝で編んだかごはどれくらい使っている？
歴史は、自動化できるものは自動化され、より安く、より速く作れるものもそうなることを示している
たとえば B2B SaaS エコシステムで、組織内の上級ユーザーが顧客設定やプロジェクト管理タスクをマクロ化できる補助的なユーザー体験として使う、といった形だ
抽象化、文脈、ユーザー集合がうまく限定されていれば、ツール利用はかなり安定し得る
目立って抜けているもの: Model Context Protocol
https://www.anthropic.com/news/model-context-protocol
エージェントには常に何らかの形の通信プロトコルが必要で、エージェント型フレームワークの世界はロゴの海なので、オープン標準がないと難しくなる
今はCometにいて、MCP実装作業も自分で行い、Agent SDKにもネイティブ統合とテストスイート改善という形で貢献した
https://github.com/comet-ml/opik-mcp
https://github.com/openai/openai-agents-python/pull/91
最近の統合は初日にすぐリリースした
https://www.comet.com/docs/opik/tracing/integrations/openai_...
OpenAIが向かっている核心は、使いやすいコンポーネントを通じて開発者にシンプルさを提供する方向だと思う
戦略や価格については言わないが、開発者の観点で最初に見たとき、SDKのシンプルでモジュール式のアプローチと無駄のなさは新鮮だった
これは汎用ではなく、mcp.runのツール呼び出しをOpenAIモデルと一緒に使うためのもの
それでもMCPを直接サポートしないのは、開発者に最も敵対的な動きに近く、OpenAIなら驚きはしない
追加されればとても良いだろう
「Agents SDKはMCP接続をサポートしますか？ MCPのクライアント・サーバー接続で、特定のエージェントにツールを簡単に与えられますか？」という質問に対し、「必要なツールを定義できるので、function callingでMCPツールを実装できる」という回答
要するに、多少の配管作業は自分でやる必要がある
関連Issue: https://github.com/openai/openai-agents-python/issues/23
swyxです
新API全般について、API/DXチームに事前に見せてもらい、よくある質問を尋ねる時間があった
https://latent.space/p/openai-agents-platform
面白い核心は、今やレスポンスがデフォルトで無料保存されるので、Responses APIをデータベースのように濫用できるのかという点
HNの人たちが好みそうな質問もある
Web検索のハイパーパラメータ、つまりDIY Deep Researchを作るときに検索の深さと幅を調整する方法
OAIがResponses APIの一部としてRAGと再ランキングを標準提供するようになった今、いつ自前でRAGを作るべきか
個人的には、誰かがFiles APIのRAG性能をベンチマークすべきだと思う。コミュニティの印象はAssistants APIの初回リリース時からあまり更新されていないようだ
Agents SDKとOAI Swarmの違いは、おおよそ型、トレーシング、差し替え可能なLLM
search-previewとcomputer-use-previewのファインチューニングがGPT5に統合されるのかも気になる0 - https://ai.pydantic.dev/
こうしたAI検索ツールを自分で作る主な理由の一つは、深さと幅を完全に制御でき、ローダーも欲しいデータやサイトに合わせてカスタマイズできるから
現在のWeb検索では、どのサイトに全文がなく、どのサイトではスニペットだけを使っているのかが透明ではない
コンピュータ操作とWeb検索を一緒に持つのは確かに強力。本質的にはOpenAIのDeep Researchのようなもの
発表では価格を公開していなかった
非常に高額になることを分かっていたからである可能性が高い
ウェブ検索 [0]: GPT‑4o search と 4o-mini search は 1,000クエリあたりそれぞれ $30、$25
ファイル検索 [1]: 1,000クエリあたり $2.50、ファイル保存は $0.10/GB/日、最初の 1GB は無料
コンピュータ使用ツール（computer-use-preview モデル）[2]: 入力 100万トークンあたり $3、出力 100万トークンあたり $12
[0] https://platform.openai.com/docs/pricing#web-search
[1] https://platform.openai.com/docs/pricing#built-in-tools
[2] https://platform.openai.com/docs/pricing#latest-models
この API が https://www.anthropic.com/news/model-context-protocol よりどう優れているのか、よく分からない
動機は「ユーザーにとってどうすればより有用になるか」よりも「どうすればもっと稼げるか」だったように見える
気に入った、大胆な動きだ
Google の動きの遅い人たちがようやく追いつく頃には、Google にとっては手遅れかもしれない
ウェブを検索してかなりうまく動くスクリプトも書いた。vercel ai sdk を使っている [1]
[0] - https://brave.com/search/api/
[1] - https://gist.github.com/bramses/41e90b27d156590154bcefd4119f...
Responses API よりはるかにシンプルで強力なバージョンを自分で作っており、すべての LLM プロバイダーで動作する
https://github.com/Anilturaga/aiide
見栄えがよく、本当に良さそうだ
「Assistant API のサポート終了を正式に発表する予定で、目標終了時期は2026年半ば」という文言がある
新しい Responses API は、組み込みの「handoff」機能まで含め、正しい方向への一歩だ
ただしエージェント型のユースケースにはまだ少し制約があるように感じられ、公式のガードレール・状態機械ロジックが不足している
「開発者がエージェントを作れるシームレスなプラットフォーム体験を提供することが目標」と述べていたが、このプラットフォームへどう移行していくのか興味深い
数カ月以内にグラフベースの制御フローを見ることになりそうだ
今でもオープンソースの解決策は無数にあるが、多くは不十分だったり、不要な不透明さと複雑さを加えたりしている
ツール呼び出しと JSON レスポンスの組み合わせでエージェント型フローを作ることはできたが、まだ誰もきちんと解けていない上位の構成要素が欠けている
ここで言及されている Computer Use の進歩が印象的なので、すでにユーザビリティテストに活用できるほど成熟しているのか気になる
一般に、AI が探索しにくい UI なら人間にとっても相対的に難しい可能性が高く、何らかの形で単純化または改善すべきサインだと見なしてよいのだろうか？
LLM が UI と相互作用する様式と、人間が UI を使う方法は大きく異なる
リンクされている Agents SDK が 404 になる
参考までに、MindRoot には task API を使って Responses と File Search の一部に似たものがある: https://github.com/runvnc/mindroot/blob/main/api.md
これは mr_kb プラグインの query_kb ツールと組み合わせることができ、複数の KB 検索を許可するため、実際には File Search より優れているかもしれない
私のプログラムを手伝ったり、プラグインを作ったり、PR を送ったりしたい人は、GitHub、メール、Discord/Telegram（runvnc）で気軽に連絡してよい
ログインしているからかもしれない