OpenAI 新API：Responses API と Agent SDK

1. はじめに

OpenAIは2025年3月、AIエージェント開発を強力に支援するResponses APIとAgent SDKを発表しました。

そもそもAIエージェントとは、以下の図のように、AI自身が必要なツールを必要なときに使用して自律的に実行してくれるプログラムのことです。

本記事では、エンジニア・プロダクトマネージャー・CTOなど、最新のAIエージェント技術を自社のシステムに統合したい方を対象に、Responses APIとAgent SDKの概要や技術仕様、実装方法、ユースケースとメリット・リスク、そして両者の連携が市場に与える影響について解説します。

実際のPythonコード例を示しながら具体的に紹介するため、業務効率化や自動化を検討している企業担当者も含め、今後の導入・検証の参考にしていただければ幸いです。

2. OpenAI Responses API の解説

2-1. 概要と主要機能

OpenAI Responses API は、従来のChat Completions APIの機能を発展させた新しい対話型APIです。

1回のリクエスト内でモデルがマルチターンのやりとりを行い、必要に応じて外部ツールも自動呼び出しできる点が最大の特徴です。

具体的には、以下のような機能が強化されています。

• マルチターン対話
  通常の質問応答に加え、複数のやりとりをまとめて1回のAPIコールで完了させる仕組みを提供します。
  モデルは内部で思考プロセスを持ち、ユーザーの意図を理解しながら追加のツール呼び出しや再応答を行い、最終回答を返します。

• ツール呼び出しの統合
  Web検索・ファイル検索・コンピュータ操作といった組み込みツールを、単一のAPI呼び出しから利用できます。
  モデルが外部情報を動的に取得し、より正確かつ実用的な回答を生成可能です。

• ストリーミング応答
  大きな応答を部分ごとにリアルタイム送信するストリーミングにも対応。
  生成の途中経過を逐次処理でき、ユーザー体験を向上させます。

• Chat Completions APIとの比較
  Responses APIは既存のチャットAPIと上位互換の位置づけです。
  シンプルな会話だけならChat Completions APIでも問題ありませんが、ツール呼び出しやマルチターンの自律対話が必要な場合はResponses APIの利用が推奨されています。

2-2. 技術仕様・料金体系・利用事例

技術仕様と利用条件

• RESTエンドポイント: POST https://api.openai.com/v1/responses
• 主要パラメータ:
  • model: 使用するモデル (例: gpt-4o、gpt-4o-mini)
  • input: ユーザー入力
  • tools: 有効にしたいツールの指定
  • store / previous_response_id: 会話の継続に利用
  • stream: ストリーミング応答の有無
• 認証: OpenAI APIキーが必要
• 課金形態: トークン消費量 + ツール使用量に応じた従量課金

組み込みツールと料金

Responses APIには、以下の3つの組み込みツールが提供されています。
ツールごとに利用料が加算される点に注意が必要です。

ツール名	機能概要	料金体系 (2025年3月発表時点)
Web検索	インターネット検索を行い、最新情報を取得。 GPT-4世代の検索特化モデルを使用	- GPT-4o: $30 / 1000クエリ - GPT-4o-mini: $25 / 1000クエリ
ファイル検索	アップロードしたドキュメントから関連情報を検索。 RAG (Retrieval-Augmented Generation) に有効	- $2.50 / 1000クエリ - ストレージ課金: $0.10 / GB / 日 (1GBまでは無料)
コンピュータ操作	PC上のアプリ操作やフォーム入力などRPA的な処理を実行。 Operator機能をAPI化したモデル	- 入力トークン: $3 / 100万 - 出力トークン: $12 / 100万

※上記料金に加え、回答生成時のモデル使用量（トークン課金）も発生します。

利用事例と導入メリット

• Unify社: 営業支援エージェントとして導入。Web検索ツールで店舗拡大状況を自動収集し、顧客アプローチを最適化。
• Luminai社: レガシーシステム操作をコンピュータ操作ツールで自動化。従来のRPAでは数か月かかった作業を数日で実現。
• Box社: 企業の機密文書(内部Boxデータ) + 外部情報(ニュースサイト)を横断検索し、自動レポート生成するエージェントを短期間で開発。

こうした事例から、ツールを組み合わせた高機能エージェントが既に導入され、大幅な業務効率化や新たな知見獲得につながっていることが分かります。

2-3. Chat Completions APIとの比較

Responses APIは従来のChat Completions APIを包含する上位APIです。
主な違いは以下のとおりです。

• マルチターン対話の自然な実行: 単一リクエストで複数ターンのツール呼び出しまで完結
• ツール呼び出しが標準統合: Web検索・ファイル検索・コンピュータ操作をAPI内で扱える
• ストリーミングや構造化出力サポートの強化: 開発者がモデルの思考過程を細かく取得しやすい

今後、新規開発にはResponses APIが推奨される方針です。
Chat APIは引き続きサポートされますが、より高度なエージェント機能が必要であればResponses APIを検討する価値があります。

3. OpenAI Agent SDKの解説

3-1. SDKの全体像と目的

OpenAI Agent SDKは、Responses APIと連携してエージェントワークフローを統合的に管理・実行するためのオープンソース開発キットです。
複数のLLMエージェントを役割分担させたり、ツール呼び出しを自動オーケストレーションしたり、安全対策やトレーシングを組み込みながら高度なエージェントを素早く構築できるよう設計されています。

• 複数のエージェント間でのハンドオフ
  あるエージェントが判断し、別のエージェントにタスクを引き継ぐ（handoffs）機能が標準搭載。問い合わせ内容の振り分けなど高度なマルチエージェント連携が容易です。

• ツール統合とガードレール
  Python関数を簡単にツール化し、エージェントがそれを呼び出せる仕組みを提供。出力フォーマットや入力検証をガードレールで制御し、安全かつ信頼性あるエージェントを開発できます。

• トレーシング機能
  各エージェントがどのタイミングでどんなツールを使ったか、最終回答に至るまでのプロセスを可視化・記録。複数エージェントの連携が増えるほど重要になるデバッグや性能最適化を支援します。

3-2. 主要機能（エージェント定義、ハンドオフ、ツール統合、ガードレール、トレーシング）

エージェント定義

エージェント(Agent)オブジェクトに、以下の要素を設定します。

• 名前・役割（例: 「ショッピング支援エージェント」「カスタマーサポートエージェント」）
• システム指示（instructions）: モデルがどう振る舞うかを明示
• 利用可能ツール（tools）: Web検索ツール、ファイル検索ツール、カスタム関数等
• ハンドオフ先のエージェント（handoffs）: タスクに応じて委譲すべき相手エージェント

これにより、1つのエージェントが 「どんな目的で、どんなツールを使って、どんな役割を果たすか」 を明確に定義できます。

ハンドオフ

エージェント間の制御権受け渡しを自動化する機能です。
入力内容を見て、「これは自分ではなく別のエージェントが得意そうだ」と判断すれば自動的にハンドオフが行われます。

例えば、問い合わせ内容が 「製品案内」ならショッピング支援エージェントに、「返品・クレーム対応」ならサポートエージェントに任せる、といった振り分けをモデルが自律的に行うイメージです。

ツール統合

Python関数や外部APIを @function_tool デコレータで簡単にエージェントのツール化できます。
引数や戻り値の型情報から自動で JSONスキーマ が生成され、LLMは正確な形式で関数を呼び出します。

以下は例です。

from agents import Agent, Runner, WebSearchTool, function_tool

@function_tool
def get_weather(city: str) -> str:
    """天気を取得するダミー関数"""
    return f"{city}の天気は晴れです。"

weather_agent = Agent(
    name="Weather Assistant",
    instructions="天気に関する質問に答えるエージェントです。",
    tools=[get_weather, WebSearchTool()]
)

result = Runner.run_sync(weather_agent, "東京の天気は？")
print(result.final_output)

WebSearchToolやFileSearchTool、ComputerToolなどの組み込みツールも同様に設定できます。

ガードレール（Guardrails）

入出力のフォーマット検証やコンテンツ安全チェックを設定し、エージェントが逸脱した回答をしないよう制御する仕組みです。
機密情報が含まれた場合にマスクする、特定のNGワードをブロックするなど、要件に合わせて柔軟に定義できます。

トレーシング（Tracing）

エージェントの実行過程をログやダッシュボードで可視化します。
各ツール呼び出しの内容、ハンドオフ先の選択経緯などを詳細に追跡できるため、複雑なマルチエージェントシステムでもデバッグ・改善が容易です。

3-3. Pythonサンプルコードによる実装例

以下では、複数エージェントを連携させる一例を示します。
言語判定エージェントがユーザーの入力を振り分け、英語担当エージェントまたはスペイン語担当エージェントへ処理をハンドオフするイメージです。

from agents import Agent, Runner

english_agent = Agent(
    name="English Agent",
    instructions="I only speak English."
)

spanish_agent = Agent(
    name="Spanish Agent",
    instructions="Respondo en español."
)

router_agent = Agent(
    name="Language Router",
    instructions="英語かスペイン語か判定して、該当エージェントにハンドオフしてください。",
    handoffs=[english_agent, spanish_agent]
)

result = Runner.run_sync(router_agent, "Hola, ¿cómo estás?")
print(result.final_output)
# => スペイン語エージェントが応答し、スペイン語の回答が表示される

このようにRouterエージェントが入力内容を判断し、英語エージェントまたはスペイン語エージェントに処理をバトンタッチする仕組みを極めて簡単に実装できます。

今まではLangChainなどのサードパーティのライブラリを使うことができましたが、OpenAI自身がライブラリを作ったというイメージです。

3-4. ユースケースとメリット・リスク

メリット:

• 開発生産性向上: エージェント間連携やツール呼び出しをフレームワークが自動管理してくれる
• 保守性の向上: 役割ごとにエージェントを分割でき、機能追加・変更が容易
• 安全性向上: ガードレールやトレーシングにより不正操作・誤答リスクを軽減
• 他モデルへの拡張性: OpenAI以外のLLMでもChat Completions互換なら利用可能

リスク・課題:

• LLMの不確実性: 幻覚や誤答、誤ったツール呼び出しが起こり得る
• セキュリティ上の懸念: コンピュータ操作ツールなどは誤用されると危険
• コスト増大: ツール呼び出しやマルチターンでAPI利用量が増えがち
• 未知の不具合: 新興技術ゆえのSDKバグや仕様変更の影響

これらを踏まえ、導入初期は限定ユースケースでパイロットを行い、人間による監視・承認フローを組み合わせる運用が推奨されます。

エージェントとツール呼び出しのフロー図解

以下は、ユーザー→エージェント→ツール呼び出し→最終回答、という一連の流れを示す例です。

エージェントは複数回ツールを呼び出すことも可能で、Web検索結果をさらに要約して別ツールを使い…といったマルチステップ処理を自律的に実行します。

4. 両者の連携と市場への影響

4-1. Responses APIとAgent SDKの相乗効果

• 高機能エージェントが簡単に作れる
  Responses APIが提供する 「マルチターン+ツール呼び出し」の基盤を、Agent SDKがエージェント定義や連携ロジックの自動管理 でサポート。従来は複雑だったコードを大幅に削減できます。

• 市場活性化
  多くの開発者が短期間でAIエージェントを実装できるようになり、業務効率化やサービス高度化が一気に進む可能性が高いです。他社も類似フレームワークを強化する動きがあり、業界全体の標準化・進化が加速すると見られます。

4-2. 導入戦略・業務改善への提言

• ステップ1: 小規模パイロットから開始
  まずは比較的リスクの低い定型業務やFAQ対応などで試験運用し、エージェントの振る舞いやコストを確認。

• ステップ2: 人間との協調を保つ
  エージェントが誤った判断をした際に人間が介入できる設計を導入初期は維持。最終回答の承認フローを設けるなど、重要業務の自動化は段階的に進める。

• ステップ3: 継続的最適化
  トレーシングログを分析し、不要なツール呼び出しやコストの無駄を把握。用途に合わせて安価な軽量モデルと高精度モデルを使い分け、ランニングコストを管理。

4-3. 今後の展望と技術的課題

• 更なるツール追加: Code Interpreter相当や音声認識/画像解析など、外部API統合が今後拡大。
• モデルの信頼性向上: 幻覚や安全性を改善するためのLLMアップデートが期待される。
• 標準規格の可能性: 多社のエージェントフレームワークも参入し、エージェント間通信プロトコルの共通化が進む可能性あり。

5. まとめ

• OpenAI Responses API:
  従来のChat Completions APIを強化し、マルチターン対話とツール呼び出しを単一リクエストで実行可能。業務効率化や高度な情報検索を実現し、導入事例が増えつつあります。

• OpenAI Agent SDK:
  複数エージェントの連携やツール統合を自動オーケストレーションするフレームワーク。エージェント定義、ハンドオフ、ガードレール、トレーシング機能など、開発・運用の生産性を大幅に向上させます。

• 両者の組み合わせで市場に与える影響は大きく、あらゆる業界のエージェント技術普及が加速する可能性があります。しかし、LLMの不確実性やセキュリティリスク、コスト管理など運用面の課題には注意が必要です。

• 導入の手順としては、まずはリスクの低い範囲でのパイロット運用を行い、人間との協調フローを設けつつ効果を検証していくことが現実的です。トレーシングやガードレール機能を活用して安全性と信頼性を確保しながら、徐々に自動化範囲を拡張していくことで大きなビジネス価値を創出できます。

AIエージェントは今後、業務効率化の切り札になり得る技術です。
Responses APIとAgent SDKは、その導入ハードルを大幅に下げる強力なプラットフォームと言えます。
ぜひ自社のユースケースに合わせ、小さく始めて大きく育てるアプローチで検証を進めてみてください。

---

参考文献（URL）

• OpenAI: New tools for building agents
• OpenAI releases new tools to help developers build AI agents (Neowin)
• OpenAI's newest developer API brings search capabilities to AI agents (SiliconANGLE)
• GitHub: openai/swarm
• GitHub: openai/openai-agents-python
• OpenAI Help Center: Error Types Guidance
• OpenAI unveils Responses API, open source Agents SDK (VentureBeat)