OpenAI APIを全部比較してみた — Responses API・Chat Completions・Agents SDK・AgentKit、結局どれを使えばいい？
はじめに
OpenAIのAPIって、気づけばかなり増えていませんか？
「Web検索やCode Interpreterを使うエージェントを作りたい」と思って調べ始めたら、Responses API、Chat Completions API、Assistants API、Agents SDK、AgentKit……と選択肢が多すぎて、どれを使えばいいのか迷ってしまいました。
この記事では、2026年6月時点でのOpenAI APIの全体像を整理し、「結局どれを選べばいいのか」の判断基準をまとめます。
OpenAIのAPI、全部並べてみる
まず全体像を把握するために、2026年6月時点で提供されている主要なAPIを一覧にしました。
| API | ステータス | 主な用途 |
|---|---|---|
| Responses API | 推奨（デフォルト） | 組み込みツール（Web検索、Code Interpreter、ファイル検索）、エージェントループ、MCP、Deep Research、Computer Use |
| Chat Completions API | サポート中 | シンプルなリクエスト/レスポンス。組み込みツールなし、会話状態は自前管理 |
| Assistants API | 非推奨（2026/8/26 シャットダウン） | ステートフルアシスタント — Responses APIに置き換え |
| Realtime API | アクティブ | 低レイテンシ音声エージェント（speech-to-speech）、SIP電話、画像入力 |
| Batch API | アクティブ | 非同期の大量処理、50%コスト削減、Webhook駆動 |
| Legacy Completions API | 終了 | 旧 /v1/completions エンドポイント |
そしてAPI上に構築されるフレームワーク/ツールキットとして：
| ツール | ステータス | 位置づけ |
|---|---|---|
| Agents SDK | アクティブ（オープンソース） | Python/TSライブラリ。エージェントのオーケストレーション |
| AgentKit | 一部サンセット予定 | ビジュアルツールキット（Agent Builder + ChatKit + Connector Registry） |
意外だったのは、APIだけで6種類、さらにフレームワーク層が2つあること。ただ実際には「新規プロジェクトでまず検討すべきか」で絞ると、かなりシンプルになります。
Responses API vs Chat Completions API — 何が違う？
最も多くの開発者が迷うのがこの2つの比較です。調べてみると、差は想像以上に大きいことがわかりました。
| 観点 | Responses API | Chat Completions API |
|---|---|---|
| 状態管理 | サーバー側で管理可能 | 自前で会話履歴を送信 |
| 組み込みツール | Web検索、Code Interpreter、ファイル検索 | なし |
| MCP対応 | あり | なし |
| Deep Research | あり | なし |
| Computer Use | あり | なし |
| コスト | キャッシュ効率40-80%改善 | ベースライン |
| 推論モデル性能 | SWE-benchで+3%（GPT-5使用時） | ベースライン |
特に注目すべきはコスト差です。Responses APIはサーバー側で会話状態を保持できるため、キャッシュヒット率が大幅に向上します。内部テストで40〜80%のキャッシュ効率改善が報告されています。
いつChat Completions APIを使うか
Chat Completions APIが適しているケースもあります：
- シンプルな1回限りのリクエスト/レスポンス
- 既存のChat Completions統合をすぐに移行する必要がない場合
- サードパーティのLLMプロバイダーとの互換性を重視する場合（Chat Completions形式は業界標準に近い）
ただし、OpenAIとMicrosoftの両社とも、新規プロジェクトにはResponses APIをデフォルトで推奨しています。
Assistants APIはなぜ消えるのか
Assistants APIは2024年に登場し、ステートフルなアシスタントを構築するためのAPIとして期待されました。しかし、Responses APIがその機能を上位互換で吸収したため、2026年8月26日をもってシャットダウンされます。
移行のポイント：
- Assistants APIの「Threads」による会話管理 → Responses APIの
previous_response_idパラメータで同等の機能 - Assistants APIの「Tools」 → Responses APIの組み込みツールに統合
- Assistants APIの「Files」 → Responses APIのファイル検索ツールに統合
既にAssistants APIを使っているプロジェクトは、OpenAI公式の移行ガイドを参照して計画的に移行することを推奨します。
Agents SDK vs AgentKit — コード派 vs ローコード派
エージェントを構築する際、もう一つ迷うのがAgents SDKとAgentKitの選択です。
| 観点 | Agents SDK | AgentKit |
|---|---|---|
| アプローチ | コードファースト | ローコード / ドラッグ&ドロップ |
| 主要コンポーネント | Agents, Handoffs, Guardrails, Tools, Sessions | Visual Canvas, Connector Registry, ChatKit, Evals |
| マルチエージェント | Handoffsでコード内委譲 | ビジュアルノード構成 |
| 外部連携 | ツール/MCP経由で自前実装 | Connector Registry（Slack, Google Drive等）組み込み |
| UIコンポーネント | 自前構築 | ChatKit提供 |
| プロバイダーロックイン | なし（他モデルも使用可） | OpenAIエコシステムのみ |
| 将来性 | アクティブに開発中 | Agent Builder & Evals 2026/11/30 サンセット |
重要な注意点：AgentKitの一部サンセット
2026年6月3日、OpenAIはAgent BuilderとEvalsプロダクトの終了を発表しました。2026年11月30日以降、OpenAIプラットフォーム上で利用できなくなります。
これは大きな判断材料です。AgentKitのビジュアルビルダーに依存したワークフローは、半年以内に別の手段への移行が必要になります。
判断基準
Agents SDKを選ぶべきケース：
- エージェントロジックをコードで制御したい
- マルチエージェントのHandoffs、型付きツール、スキーマ検証が必要
- OpenAI以外のモデルも使いたい（プロバイダー非依存）
- Sessionsによる長期タスクを扱いたい
- 本番システムで「ワークフロー = コード」として管理したい
AgentKitを選ぶべきケース：
- クイックプロトタイピング
- 非エンジニアチームがシンプルなエージェントを構築したい
- ChatKitで組み込みチャットUIを素早く実装したい
- 既存SaaSとの連携をConnector Registryで簡単に設定したい
正直なところ、AgentKit一部サンセットの発表を考えると、長期的にはAgents SDKが安全な選択です。AgentKitはプロトタイピングや短期プロジェクトには便利ですが、本番で依存するにはリスクがあります。
まとめ：2026年6月時点の選択ガイド
調べてみた結果、判断はシンプルにまとめられます：
| やりたいこと | 選ぶべきAPI/ツール |
|---|---|
| 新規プロジェクト全般 | Responses API |
| シンプルな1回リクエスト | Chat Completions API（でも新規ならResponses推奨） |
| 音声エージェント | Realtime API |
| 大量バッチ処理 | Batch API |
| エージェント構築（コード） | Agents SDK |
| エージェント構築（ローコード） | AgentKit（サンセット注意） |
| 既存Assistants API | 2026/8/26までにResponses APIへ移行 |
OpenAIのAPI戦略は「Responses API中心」に収束しつつあります。Chat Completions APIも引き続きサポートされますが、組み込みツール、MCP、状態管理などの新機能はResponses APIでのみ提供されます。
新規プロジェクトではResponses API + Agents SDK の組み合わせが、現時点で最も将来性のある選択と言えるでしょう。
