OpenAIがAgents APIを公開、サンドボックスとMCP接続を標準装備
OpenAI Agents API
OpenAIがAgents APIのドキュメントを公開した。セッション管理やイベント処理、OpenAIホスト型と自己ホスト型のサンドボックス、Web検索・Functions・MCP接続・Plugins・Vaultsといったツール群、マルチエージェント構成、トレーシングまでを一つのAPIで扱える。従来のAgent BuilderはLegacy APIsへ移され、移行ガイドも用意されている。
エージェント構築における安全性
HNでの議論
154- bluesnowmonkey
エージェントを製品として提供するための正しい抽象化はまだ模索中だと思う。
- LLMは素晴らしい基盤だが、自前のハーネスを構築するのは途方もない作業で、深い沼だ。
- オープンソースライブラリとして利用可能なハーネスもあるが、それでも環境に結合している。状態はどこに永続化する？例えば自分がCloudflare Workerでファイルシステムすらないかもしれない。
このようなAgent as a Serviceなら、必要なツールをプラグインして好きな種類のエージェントにできる。しかし、メモリやコンテキスト管理など、すべてのエージェントが必要とするハーネスの本当に深い部分は、彼らがカプセル化して改良し続けることができる。
とはいえ、今のところ私のお金はOpenAIやAnthropicの提供するものには賭けていない。彼らは自社のプロプライエタリなフロンティアモデルを使わざるを得ず、それらは実際には今のほとんどのエージェントにとって最良の選択ではないからだ。LLMラボではない競合は、その時々の市場から自由に選べる。例えば、今エージェント関連のほとんどのことにはGLM 5.3 Flashを使いたいはずだ。
- andrewchambers
最近、通常のqemu VMでcodexを実行し、codexのリモートコントロールを使ってスマホから会話するのがとてもうまくいっている。
正直、パーソナルアシスタントとして極めてよく機能する。
API化する意味はわかるが、自分でVMをセットアップできるならロックインされる必要はないかもしれないと心得ておいてほしい。
- brap
通常のLLM「エンドポイント」とエージェント/ハーネスの境界は、無意味な区別になるまでどんどん曖昧になっていくと思う。
ChatGPT/Claude/Geminiなどを使っているとき、あなたは基本的にすでにツールなどを備えた何らかのバックエンドハーネスと対話しているのであって、生のLLMではない。ただコンピュータを与えて終わりにすればいい。
コーディングとは無関係のタスクでも、ClaudeやGeminiの代わりにClaude Code / Antigravity（ウェブ経由）を使っている自分にすでに気づいている。なぜ制限されたバージョンを使うのか？
- monneyboi
このベンダーロックインを推進する代わりに、私たちが金を払っている推論トークンを返してくれ。ありがとう。
- 6thbit
そこに埋もれているが、サンドボックスをセルフホストする選択肢があることに注意してほしい
https://developers.openai.com/api/docs/guides/agents-api/env...
これでずっと魅力的になるし、プロバイダー間の移行も容易になる可能性がある。
- varenc
彼らのショーケース例[0]はGitHubにリンクしているが、リンクが404になる。例えばSlackエージェントのこれ：https://github.com/OpenAI-Early-Access/agents-api-python-pre...
これはまだ一般公開できる状態ではない早期リリースなのだろうか？興味深いのは「OpenAI-Early-Access」というGitHubユーザーが存在することだが、もちろん公開リポジトリはない。おそらく実際に公開されるときには、サンプルエージェントのリポジトリを別のGitHubユーザーに移すのだろう。
[0] https://developers.openai.com/showcase/agents-api-slack-bot
編集：OAIの誰かが私のコメントを見たのか、リンクが修正された！そしてopenai orgの下の公開リポジトリを指している：https://github.com/openai/openai-cookbook/tree/main/examples...
- chairhairair
あなたのデータをプログラム的に盗みたいときに最適。
- jumploops
エージェント比較ページ[0]にcodexのapp-serverが選択肢として載っていないのは興味深い。
生のResponses APIやAgents SDKと比べて、app-serverが最も柔軟だと感じている。
確かに、ここでの正しいインターフェースはまだみんな模索中のように見える。
また注目すべきは、GPT-5.5あたりから、CodexはResponses APIを意図されたようには使っておらず、代わりにコンテキストをより手動で管理する「lite」バージョン（完全なトランスクリプトを送信したり、提供された`web_search`ツールの代わりにカスタムのweb.runツールを使ったり）を使っている。
ドキュメントに従うと、多くの善意の機能に導かれるが、それらのほとんどは彼らの最も成功したハーネスでは捨て去られている。
[0]https://developers.openai.com/api/docs/guides/agents#compare...