
Anthropic実践講座 第34回 AIエージェント入門 ── Responses APIとAgents SDKの違い
こんにちは、コハクのAI研究室です!🧪
「AIに質問して答えを返してもらう」だけなら、APIを1回呼び出せば始められます。
しかし、AIがツールを使い、結果を読み、次の行動を決めるようになると、処理は複数ステップになります。
このとき迷いやすいのが、Responses APIを直接使うか、Agents SDKを使うかです。
今回は、両者の違いを「どちらが高機能か」ではなく、実行ループを誰が管理するかという視点で整理します。
1.AIエージェントは「答える」より「進める」仕組みです 🤖
ここでいうAIエージェントは、モデルが一度答えて終わる仕組みではありません。
目的に合わせてツールを選び、ツールの結果を受け取り、必要なら次の呼び出しへ進みます。
たとえば、問い合わせ対応を自動化するなら、次の流れが考えられます。
問い合わせ内容を読む
社内FAQを検索する
注文情報が必要か判断する
必要なら業務システムの関数を呼ぶ
得られた情報から回答を作る
自信がない場合は人へ引き継ぐ
重要なのは、モデルだけで仕事が完結するわけではないことです。
ツール実行、状態の保持、停止条件、エラー処理、人の承認といった周辺の仕組みが必要になります。
OpenAIの公式資料では、Responses APIはモデル応答を直接扱い、エージェントを一から組み立てる入口として説明されています。
一方、Agents SDKはアプリケーション内で実行ループ、ツール、handoff、guardrails、sessionsなどをまとめて扱うための、より高い抽象度の実装手段です。
🔍 コハクの注目ポイント
最初に決めるべきなのは「エージェントという名前を使うか」ではなく、何回の判断と実行が必要かです。
2.Responses APIは、実行ループを自分で組み立てたいときに向きます 🔧
Responses APIを直接使う場合、モデルへ入力を渡し、返ってきた出力をアプリケーション側で読み取ります。
ツール呼び出しが返ったら、そのツールを実行し、結果を次の入力としてモデルへ返します。
つまり、次の流れを自分のコードで管理します。
ユーザー入力
↓
Responses APIを呼ぶ
↓
最終回答か、ツール呼び出しかを判定
↓
ツールを実行して結果を戻す
↓
必要なら再度Responses APIを呼ぶこの方式の利点は、制御の場所が明確なことです。
「何回まで繰り返すか」「どのツールを許可するか」「どの操作で人の承認を求めるか」を、アプリケーションの要件に合わせて細かく決められます。
一方で、ループ、状態、例外、ログ、再開処理なども自分で設計する必要があります。
短い処理や、すでに独自のワークフロー基盤があるシステムでは、この自由度が強みになります。
実務例:社内FAQを1回検索して答える
検索は最大1回、回答できなければ担当者へ回す、と決まっている場合を考えます。
このような短い流れなら、Responses APIを直接呼び、ツール呼び出しの有無をアプリケーション側で判定する構成が分かりやすいでしょう。
停止条件も単純なので、追加の抽象化を入れずに全体を追跡できます。
🔍 コハクの注目ポイント
Responses APIを選ぶ理由は「簡単だから」だけではありません。
ループの各段階を自分の責任範囲として明示したい場合にも向いています。
3.Agents SDKは、複数ステップの実行管理を任せたいときに向きます 🧭
Agents SDKでは、`Agent`に指示やツールを持たせ、`Runner`を使って実行します。
Runnerは、モデルの出力が最終回答か、ツール呼び出しか、別のエージェントへのhandoffかを判定しながらループを進めます。
公式ドキュメントでは、ツール呼び出しならツールを実行して結果を追加し、handoffなら現在のエージェントを切り替え、最終出力なら終了する流れが示されています。
さらに、Agents SDKには次の仕組みがあります。
Function tools:Python関数をツールとして扱う
Handoffs:専門エージェントへ処理を引き継ぐ
Guardrails:入力や出力を検査する
Sessions:実行中の文脈を保持する
Human in the loop:実行途中に人を関与させる
Tracing:処理の流れを可視化し、確認しやすくする
これらを毎回ゼロから作らず、共通の実行基盤として使えるのがAgents SDKの強みです。
ただし、SDKを使っても業務ルールが自動で決まるわけではありません。
許可するツール、最大ターン数、失敗時の扱い、承認を求める操作は、開発者が設計します。
実務例:問い合わせを分類し、専門担当へ引き継ぐ
問い合わせを受けた一次対応エージェントが、請求、技術、契約のどれかへ振り分ける処理を考えます。
各専門エージェントが別の指示とツールを持ち、必要に応じてhandoffするなら、Agents SDKの実行管理が役立ちます。
処理が複数段階になり、どの担当へ移ったかを追跡したい場合にも相性がよい設計です。
🔍 コハクの注目ポイント
Agents SDKは「モデルを賢くする道具」ではなく、複数ステップの実行を整理する道具です。
4.選び分けは、制御・長さ・運用で判断します ⚖️

判断するときは、次の4つを確認します。
| 判断軸 | Responses APIを直接使う | Agents SDKを使う |
|---|---|---|
| 実行ループ | 自分で管理したい | Runnerへ任せたい |
| 処理の長さ | 短い、分岐が少ない | 複数ステップ、分岐が多い |
| 状態管理 | 既存基盤に合わせたい | SDKのsessions等を使いたい |
| 運用確認 | 独自ログで追跡する | tracingを活用したい |
どちらか一方に統一する必要はありません。
公式資料でも、Agents SDKはOpenAIモデルに対して既定でResponses APIを使う高位の実行基盤として説明されています。
同じサービスの中で、短い処理はResponses APIを直接呼び、複数ステップの処理はAgents SDKで管理する構成も可能です。
🔍 コハクの注目ポイント
「あとで複雑になるかもしれない」だけで最初から大きな仕組みにしないことも大切です。
現在の処理に必要な抽象度から始めます。
5.最初の設計では、停止条件と人の関与を先に決めます 🛡️
エージェント実装で危険なのは、ツールを使えること自体ではありません。
終わり方と権限が曖昧なまま、自動実行を広げることです。
最初の設計では、少なくとも次を決めます。
最大何ターンで停止するか
失敗時に再試行するか、人へ渡すか
読み取りと書き込みを分けるか
外部送信や削除の前に承認を求めるか
実行履歴をどこに残すか
最終回答の品質をどう確認するか
Agents SDKのRunnerには最大ターン数を扱う仕組みがありますが、適切な値は業務によって異なります。
Responses APIを直接使う場合も、同じ観点を自分のループへ実装します。
📝 補足
OpenAIのエージェント関連製品には、管理方式の異なる選択肢もあります。
本記事では、構成案に沿ってアプリケーション内で使うResponses APIとAgents SDKの違いに絞っています。
🧪 実験してみました
同じ「問い合わせを調べて回答する」処理を、2つの構成に分けて設計しました。
構成A:Responses APIを直接使う
検索ツールは1つ
検索は最大1回
見つからなければ人へ引き継ぐ
状態は既存データベースへ保存する
処理が短く、停止条件も明確なので、直接呼び出す構成が読みやすくなりました。
構成B:Agents SDKを使う
一次対応、技術、契約の3担当
担当ごとに異なるツールを持つ
handoffで担当を切り替える
guardrailsで入力と出力を確認する
tracingで処理経路を振り返る
分担と引き継ぎが増えるため、Runnerがループを管理する構成のほうが役割を整理しやすくなりました。
この比較から、選択基準はモデルの性能ではなく、実行管理をどこまで自分で持つかだと分かります。
まとめ🧪
Responses APIは、モデル応答とツール実行のループを自分で制御したいときに向いています
Agents SDKは、Runner、handoff、guardrails、sessions、tracingなどを使い、複数ステップを整理したいときに向いています
Agents SDKはResponses APIと対立する別物ではなく、より高い抽象度の実行基盤として利用できます
どちらを使っても、停止条件、権限、承認、ログは人が設計します
小さく始め、必要な抽象度だけ選ぶことが大切です
最初に作るなら、あなたの業務は「短い1本の流れ」と「複数担当へ引き継ぐ流れ」のどちらに近いでしょうか?
参考資料
OpenAI公式:Agents overview
https://developers.openai.com/api/docs/guides/agentsOpenAI公式:OpenAI Agents SDK
https://openai.github.io/openai-agents-python/OpenAI公式:Running agents
https://openai.github.io/openai-agents-python/running_agents/OpenAI公式:Conversation state
https://developers.openai.com/api/docs/guides/conversation-state