先に結論
OpenAI の Responses API は、今回の更新で 「API 直叩きでも agent らしい仕事をかなり完結できる層」 に一段近づきました。
特に大きいのは次の3点です。
- remote MCP で外部ツールや SaaS 連携を built-in に寄せやすくなった
- Code Interpreter で Python sandbox を同じ Responses API から呼べるようになった
- background mode で長い reasoning job を非同期に逃がせるようになった
つまり、いま見直すべきなのは「Agents SDK が不要になったか」ではありません。どこまでを Responses API 単体で持ち、どこから orchestration 層を足すか です。
単発 workflow や薄い agent なら、Responses API だけで前よりかなり進めやすくなりました。逆に、長い state 管理、handoff、人間レビューの骨格まで欲しいなら、OpenAI Agents SDK vs Responses API の判断がまだ残ります。
何が追加されたのか
OpenAI は 2026-05-21 の announcement で、Responses API に remote MCP、Code Interpreter、image generation、file search 改善を追加しました。さらに runtime 側の拡張として background mode、reasoning summaries、encrypted reasoning items も案内しています。
この更新は、単なる tool 数の追加ではありません。tool 呼び出し、長時間実行、reasoning の引き継ぎまで、Responses API の中で扱える範囲が広がった ことに意味があります。
特に o3 と o4-mini では、Responses API 上で tool や function を reasoning の途中から呼びやすくなったと OpenAI は説明しています。agent 的な実装を API 直叩きで組みたいチームには、ここが一番効きます。
まず押さえるべき5つの変化
1. remote MCP が built-in で使える
Responses API は mcp tool を通じて、公開された remote MCP server や OpenAI 製 connector を呼べるようになりました。
これで変わるのは、外部ツール連携の置き場所です。これまでは Agents SDK や自前 orchestration 側で吸収していた MCP 接続を、Responses API 側へかなり寄せられます。
ただし、何でも安全になったわけではありません。OpenAI の MCP guide でも、remote MCP server は信頼できる相手だけ使うべき と強く書かれています。model の context に入った情報が外部 server へ渡る可能性があるからです。
また、公開 internet に出ていない private MCP server は、この機能だけではそのままつながりません。その要件は Secure MCP Tunnel 側の話です。private 接続を見たいなら、Claude Managed Agents の self-hosted sandbox と MCP tunnel ガイド のような比較視点も持っておくとズレにくいです。
2. Code Interpreter が Responses API の標準 tool になった
Code Interpreter は、Python を sandbox で実行する built-in tool です。データ分析、数式処理、ファイル変換、画像の切り抜きや回転まで 1 API 呼び出しで扱えるようになりました。
ここで重要なのは、単にコードを走らせられる ことではありません。Responses API の reasoning model が、必要に応じて Python を何度か書き直しながら問題を解く流れを作りやすくなったことです。
OpenAI docs では、container は自動作成も明示作成もでき、20分未使用で失効します。生成ファイルは container file として返るので、アプリ側で回収導線を作る必要があります。
sandbox provider の細かい比較が必要なら、OpenAI Agents SDK sandbox provider 比較 も合わせて読む価値があります。Responses API に Code Interpreter が入っても、外部 sandbox が不要になるとは限りません。
3. background mode で長時間 job を非同期にできる
background mode は、Responses API の長時間処理を非同期で実行する仕組みです。response を queued や in_progress で持ち、後から retrieve や event stream で追いかけられます。
実務で効くのは、長い reasoning task を HTTP timeout 前提で抱え込まなくてよくなることです。調査、変換、重い tool call を含む workflow ではかなり扱いやすくなります。
ただし、ここは制約も明確です。OpenAI docs では background mode は response data を約10分保持するため ZDR 互換ではない と案内されています。ZDR 前提の enterprise は、便利だからとそのまま採用しないほうが安全です。
4. reasoning summaries で監査とデバッグがしやすくなった
reasoning summaries は、モデル内部の chain-of-thought そのものではなく、自然言語で短く要約した reasoning の説明 を返す機能です。OpenAI は追加料金なしと案内しています。
これが効くのは、ユーザー説明とデバッグです。なぜその tool を呼んだか、何を見てその結論に寄ったかを、完全な生思考より扱いやすい形で見せられます。
特に enterprise では、丸ごとの chain-of-thought を求めるより、まず summary で説明責任を満たせるかを見るほうが現実的です。
5. encrypted reasoning items は ZDR と相性がよい
encrypted reasoning items は、background mode と逆で ZDR や stateless 運用に寄せたい時に見る機能 です。
OpenAI docs では、include: ["reasoning.encrypted_content"] を使うと、後続 request に引き継げる暗号化済み reasoning item を受け取れます。これにより reasoning model の文脈を保ちつつ、OpenAI 側へ平文で保持させない運用がしやすくなります。
ここを誤解すると危ないです。background mode は長時間ジョブ向け、encrypted reasoning items は stateless / ZDR 文脈向けで、役割はまったく違います。
誰に関係ある更新か
今回いちばん恩恵が大きいのは、OpenAI を使って agent を組りたいが、できるだけ層を増やしたくない開発チーム です。
具体的には次のようなチームです。
- API 直叩きで workflow を組み、必要なら後から SDK を足したい
- MCP で SaaS 連携を増やしたい
- Python sandbox を別基盤なしで試したい
- 長時間 job を queue 化したい
- reasoning model のコストと説明責任を両方見たい
逆に、最初から multi-agent orchestration、review / resume、複雑な state machine が中心なら、Responses API だけで全部やる前提にはしないほうが安全です。
料金はどう見るべきか
料金は「新機能が増えた」だけで見ると誤解しやすいです。今回の要点は次の通りです。
- remote MCP: 追加の固定料金はなし。MCP 定義や tool call に使う token が課金対象
- Code Interpreter: pricing docs では 1GB container が 20分セッションごとに $0.03。4GB は $0.12、16GB は $0.48、64GB は $1.92
- file search: storage は $0.10 / GB / day、tool call は $2.50 / 1k calls
- reasoning summaries: announcement では追加料金なし
announcement では Code Interpreter を $0.03 per container と案内していますが、pricing docs では memory tier ごとの差が明記されています。実装見積もりでは pricing docs を基準にしたほうが安全です。
いま何を試すべきか
最初の検証は、全部盛りにしないほうがうまくいきます。
1. まずは既存 workflow を1本だけ Responses API に寄せる
最初は、既存の agent 基盤を全部置き換えるより、tool 呼び出しが1〜2個で済む workflow を1本移すほうが安全です。
たとえば、MCP で CRM を読み、Code Interpreter で CSV を整形し、最後に要約を返す程度なら今回の更新の価値が見えやすいです。
2. background mode は ZDR 要件を先に確認する
enterprise チームなら、機能検証より先に data policy を見たほうがいいです。background mode は便利ですが、ZDR と両立しません。
ZDR が必須なら、background mode ではなく encrypted reasoning items を含む stateless 設計から先に試したほうが筋が良いです。
3. remote MCP は approval 設計から入る
OpenAI の MCP guide では、承認付きで tool call を通す流れが前提になっています。信頼できる server だけ require_approval: never に寄せるのが基本です。
いきなり全部自動許可にすると、便利さより先に監査が壊れます。
Agents SDK との関係はどう変わるか
今回の更新で、Responses API はかなり厚くなりました。それでも Agents SDK の役割が消えたわけではありません。
見るべき分岐はまだこのままです。
- 単発 workflow、薄い orchestration、既存アプリへの組み込み → Responses API が有力
- 長い state 管理、handoff、review / resume、multi-agent 設計 → Agents SDK も検討する価値が高い
違いを先に整理したいなら、OpenAI Agents SDK vs Responses API が土台になります。
まとめ
今回の更新で、Responses API は agent 実装の入口 ではなく、かなり本番寄りの runtime 候補になりました。
特に重要なのは、remote MCP、Code Interpreter、background mode が同時に入ったことです。これで外部連携、sandbox 実行、長時間 job の3点を、OpenAI の API レイヤーでまとめて試しやすくなりました。
ただし、そのまま全部採用してよいわけではありません。background mode と ZDR、remote MCP と承認設計、Code Interpreter と外部 sandbox の役割差は残ります。
結論としてはこうです。Responses API だけでどこまで進められるかを、いま一度見直す価値は大きい。ただし、enterprise 制約と orchestration 境界を先に切ってから試すべき です。