OpenAI Agents SDKとは｜使い方とLangGraphとの違い

OpenAI Agents SDKとは何か

結論から言えば、Agents SDKは「LLMの実行ループを肩代わりするランタイム」です。

LLMにツールを持たせると、実装者は似たようなループを毎回書くことになります。モデルを呼ぶ、ツール呼び出しが返ってきたら実行する、結果を履歴に戻してもう一度モデルを呼ぶ。この繰り返しです。Agents SDKはこのループを巻き取り、開発者が書く部分を「エージェントの定義」と「ツールの中身」に絞り込みます。

OpenAIが以前実験的に公開していたSwarmの後継にあたる位置づけで、本番利用を想定したパッケージとして整理されたものです。Pythonは openai-agents、Node.js / TypeScriptは @openai/agents として配布されています。SDK自体は無償で、費用はモデルAPIの従量課金のみ。

AgentKitの中でのAgents SDKの位置

OpenAIのエージェント関連ツール群は、ドキュメント上でAgentKitとして整理されています。この中でAgents SDKが担うのはランタイムとオーケストレーションの層です。

ここで注目したいのがAgent Builderの扱いです。本記事執筆時点のOpenAI公式Agent Builderガイドでは提供終了日が明示されており、既存ユーザーは移行期間中のみ継続利用できるとされています。日付や移行方針は公式側で更新されうるため、実務で判断する際は公式ページで最新の案内を確認してください。ドラッグ&ドロップで組まれたワークフローを維持したい企業は、コードベースへの作り直しを迫られることになります。

エンジニア側から見れば、「動いているものを、同じ挙動のままSDKへ載せ替える」という輪郭のはっきりした作業が発生しうる局面です。移行需要がどの程度の案件数になるかは現時点では読めませんが、対象ワークフローを抱える組織では検討が進みやすい状況ではあります。

ミニFAQ｜Agents SDKはOpenAIのモデル専用ですか？

いいえ。ただし「接続できる」ことと「OpenAIモデルと同等に使える」ことは別です。他社モデルにも接続できますが、Responses API前提の機能は制限が出る場合があります。Chat Completions互換のエンドポイントなら接続先を差し替えられ、LiteLLM経由で複数プロバイダにルーティングする構成も公式ドキュメントに記載があります。使う予定のツールが互換経路で動くかは、採用前に確認が要ります。

Agents SDKの6つのコア概念

Agents SDKを読む上での最短ルートは、6つの概念を「どのタイミングで動くか」で並べ直すことです。

Agent｜指示とツールを束ねた実行単位

エージェントは、名前・指示文（instructions）・使用モデル・ツール一覧・出力型を持つオブジェクトです。出力型にPydanticのモデルを指定すれば、最終出力を構造化データとして受け取れます。自由記述のテキストをパースする手間がなくなるため、後続の処理に渡す前提なら最初から型を切っておくほうが楽です。

構造化出力そのものの考え方はLLMの構造化出力とは｜JSON出力とFunction Callingの使い分けで整理しています。

実行は Runner が担当します。Runner.run() が非同期、Runner.run_sync() が同期版で、戻り値の final_output に最終結果が入ります。

Tools｜関数をそのままツールにする

Pythonの関数に @function_tool デコレータを付けるだけで、ツールとして登録できます。引数の型ヒントからスキーマが自動生成され、docstringがそのまま説明文として使われます。JSON Schemaを手書きする必要はありません。

関数ツールのほかに、OpenAI側で実行されるホスト型ツールも用意されています。

• WebSearchTool：Web検索

• FileSearchTool：OpenAI Vector Storesからの検索

• CodeInterpreterTool：サンドボックス内でのコード実行

• ImageGenerationTool：画像生成

• HostedMCPTool：リモートMCPサーバーのツールをモデルに公開

• ComputerTool：GUI・ブラウザ操作の自動化（実行環境側の実装が必要）

MCPへの対応は実務上の意味が大きい部分です。社内システムをMCPサーバーとして切り出しておけば、Agents SDKからもClaudeからも同じツール群を再利用しやすくなります。ただし認証・権限制御はクライアントごとに別途設計が必要で、そのまま共用できるとは限りません。仕組みはModel Context Protocolとは｜MCPの仕組み・活用事例をエンジニア視点で解説とMCPサーバーの作り方｜自作の実装手順とMCP開発案件の単価で解説しています。

もう一つ、as_tool() でエージェント自体をツール化する方法もあります。中央のエージェントが専門エージェントを「呼び出す」構成で、処理の主導権を渡さずに済むのが特徴です。

Handoffs｜処理そのものを別のエージェントへ渡す

ハンドオフは、モデルから見れば単なるツール呼び出しです。エージェント名が Refund Agent なら、transfer_to_refund_agent という名前のツールとしてモデルに提示されます。モデルがそれを選ぶと、以降のターンは引き渡し先のエージェントが処理します。

既定では、引き継いだエージェントはそれまでの会話履歴をすべて参照できます。これは便利な一方で、渡したくない情報まで流れる経路でもあります。handoff() の input_filter で履歴を加工できるので、個人情報や内部プロンプトを含む構成では必ず確認してください。

指示文側の準備も要ります。agents.extensions.handoff_prompt に RECOMMENDED_PROMPT_PREFIX が用意されており、prompt_with_handoff_instructions() でエージェントの指示に組み込めます。これを省くと、ハンドオフが選ばれにくくなることがあります。

as_tool() とハンドオフの違いは、処理が戻ってくるかどうかです。

設計パターン全体の整理はマルチエージェントとは｜設計パターン5つと単一エージェントの違いにまとめています。

Guardrails｜入力と出力を別々に検証する

ガードレールは入力用と出力用があり、動く場所が決まっています。

• 入力ガードレール：チェーンの最初のエージェントでのみ実行

• 出力ガードレール：チェーンの最後のエージェントでのみ実行

検証関数は GuardrailFunctionOutput を返し、tripwire_triggered が True になると例外（InputGuardrailTripwireTriggered / OutputGuardrailTripwireTriggered）が送出されて処理が止まります。

運用でつまずきやすいのが実行モードです。入力ガードレールは既定でエージェント本体と並列に走ります。レイテンシは稼げますが、遮断が決まった時点ですでにトークンを消費している可能性があります。コストを優先するなら run_in_parallel=False でブロッキング実行に切り替えます。この挙動はGuardrails - OpenAI Agents SDKに明記されています。

ガードレールの設計そのものはLLMのガードレールとは｜出力制御の実装パターンとツール選定、入力側の攻撃対策はプロンプトインジェクション対策｜LLMアプリのセキュリティ実装ガイドを参照してください。

Sessions｜会話履歴の置き場所を選ぶ

セッションは、ターンをまたいだ履歴を保持するレイヤーです。実装が複数あり、どこに保存するかを選べます。

SQLiteSession はファイルパスを渡さなければインメモリで動き、プロセス終了とともに消えます。開発中はこれで十分。本番でワーカーを複数立てるなら、Redisなど共有できる置き場所に移します。

Tracing｜既定で有効になっている記録機構

トレースは既定で有効です。モデル呼び出し、ツール実行、ハンドオフ、ガードレールがそれぞれスパンとして記録され、OpenAIのダッシュボードから実行単位で追えます。記録範囲と送信内容は設定や実行環境で変わるため、本番利用の前に送信内容と無効化可否を必ず確認してください。

ここは案件で必ず論点になります。トレースにはプロンプトと応答が含まれるため、顧客データを扱うシステムでは「何が送信されるのか」を説明できなければなりません。無効化や送信先の切り替えが可能かどうかを、設計段階でTracing - OpenAI Agents SDKにあたって確認しておくのが安全です。

ミニFAQ｜6つ全部を最初から使う必要はありますか？

ありません。最小構成はAgentとRunnerだけです。ツール、履歴、委譲、検証は必要になった順に足していけば足ります。むしろ最初からハンドオフを入れると、どこで挙動が変わったのか追いにくくなります。

インストールから最初の実行まで

手順は5つ。環境を切って、入れて、キーを通して、エージェントを書いて、動かすだけです。LLM APIを触った経験があるエンジニアなら、最初のレスポンスまで15分程度が目安になります。

実際に貼り付けて動かせるコードは、Quickstart - OpenAI Agents SDKに掲載されている10行前後のサンプルがそのまま使えます。まずはこれを写経してから、以下の各手順の意味を確認していくのが早道です。

1. プロジェクト用のディレクトリを作り、python -m venv .venv で仮想環境を用意する

2. 仮想環境を有効化する（macOS / Linuxは source .venv/bin/activate、Windowsは .venv\Scripts\activate）

3. pip install openai-agents でSDKを導入する

4. 環境変数 OPENAI_API_KEY にAPIキーを設定する

5. Agentを定義し、Runner.run_sync() で実行して final_output を表示する

TypeScriptで進める場合は npm install @openai/agents を使います。TypeScript版はRealtime APIや音声エージェント関連の公式ガイドが比較的充実しており、ブラウザや電話連携を前提とするならこちらから調べ始めるほうが情報にたどり着きやすくなります。フロントエンド寄りの構成ならVercel AI SDKとは｜使い方とLLMアプリ開発の始め方も合わせて検討対象になります。

使用モデルの指定について

モデルはエージェント単位でも実行単位でも指定できます。既定モデルはSDKのバージョンによって変わるため、本番構成では明示的に指定しておくことをおすすめします。暗黙の既定に乗ったままだと、SDK更新のタイミングで挙動とコストが変わりかねません。

OpenAIモデルには2つの経路があります。Responses API を使う OpenAIResponsesModel が推奨で、Chat Completions API を使う OpenAIChatCompletionsModel は互換エンドポイント向けという位置づけです。公式のModels - OpenAI Agents SDKでも、同一ワークフロー内で両形式を混在させることは推奨されていません。

LangGraphとの違いはどこにあるか

違いの核心は状態の持ち方です。 Agents SDKは会話履歴を前提に進み、LangGraphはグラフ全体で共有するStateを各ノードが読み書きします。短く言えば、Agents SDKは会話型エージェントを早く立ち上げたいとき向き、LangGraphは複雑な分岐や承認フローを厳密に設計したいとき向きです。

実装の自由度という意味ではLangGraphが上です。「このノードを通ったら必ずこの検証を挟む」といった決定論的な制御を書けるため、審査や承認が絡む業務ほど向いています。一方でAgents SDKは、書く量が少なく読み手も追いやすい。要件が固まりきっていない立ち上げ期など、実装量と学習コストを抑えてPoCを回したい場面では利点になります。

LangGraph側の詳細はLangGraphとは｜LangChainとの違い・エージェント構築の基本に、CrewAIやAutoGenも含めた横断比較はAIエージェント開発フレームワーク比較｜LangGraph・CrewAI・AutoGenにまとめてあります。本記事はAgents SDK単体の使い方に絞っているため、3者以上を並べて選びたい場合は後者を参照してください。

どちらを選ぶかの判断軸

次の問いにYesが多いほどLangGraph寄りです。

• 処理の途中で人間の承認を挟む必要があるか

• 失敗したステップだけを再実行したいか

• 分岐条件を仕様として文書化し、レビュー対象にしたいか

• 1回の実行が数分以上かかるか

逆に、対話型のアシスタントで、ツールを数個持たせて窓口を振り分ける程度ならAgents SDKで足ります。両方を学ぶ順番としては、Agents SDKで6概念に慣れてからLangGraphのグラフ設計に進むほうが、つまずきが少なくなります。

ミニFAQ｜両方を併用する構成はありますか？

あります。LangGraphでワークフロー全体の骨格を組み、個々のノードの中でAgents SDKのエージェントを呼ぶ構成は成立します。ただし状態管理が二重になるため、どちらが履歴の正本かを決めておかないと保守が苦しくなります。

本番投入で詰まりやすい3つのポイント

PoCが動いたあとに問題化しやすい箇所を挙げます。いずれも設計段階で潰せるものです。

トレースの送信内容を説明できない

トレースは既定で有効です。この前提を共有しないまま顧客環境に入れると、セキュリティレビューで止まります。何が記録され、どこへ送られ、どう無効化できるのか。この3点は着手前に確認しておきます。

ガードレールのコストが想定を超える

入力ガードレールの並列実行は、遮断されるケースでも本体のトークンを消費しえます。遮断率が高いユースケース（社内規程に反する質問が多い等）では、ブロッキング実行のほうが総コストは下がる場合があります。実際の遮断率を測ってから決めるのが確実です。

ハンドオフ後に履歴が膨らむ

既定で履歴が丸ごと引き継がれるため、委譲を重ねるほど入力トークンが増えます。input_filter で不要なターンを落とす、あるいは委譲先を浅く保つ設計が要ります。多段のハンドオフを組む前に、1段で済ませられないかを検討してください。

ミニFAQ｜エージェントの品質はどう評価しますか？

ツール呼び出しの成否、ハンドオフの妥当性、最終出力の正確性を分けて測ります。トレースに記録されたスパンを突き合わせると、失敗が「モデルの判断ミス」なのか「ツール側のエラー」なのかを切り分けられます。評価設計の考え方はLLM評価（Evals）とは｜LLM-as-a-Judgeと品質保証の実務まで解説を参照してください。

学習ステップと案件への結びつけ方

順番としては、6概念の素振り→小さな実装→運用要素の追加、の3段階が現実的です。 以下の所要目安は、Python実務経験があり公式クイックスタートに沿って進めた場合の想定で、既存システムとの連携が絡む案件ではこれより長くなります。

本番導入寄りの案件では、段階3まで自分の言葉で説明できると評価されやすくなります。首都圏中心の主要フリーランスエージェント数社の公開案件を2026年10月時点で見る限り、エージェント開発の募集ではフレームワーク名の指定より「本番で動かした経験」「評価と監視をどう設計したか」を要件に挙げる書き方が目立ちます。もっとも、PoC支援や技術調査が中心の案件もあり、一律ではありません。

ポートフォリオとして見せるなら、動くデモよりも設計判断の記録のほうが効きます。なぜハンドオフではなくas_tool()にしたのか、ガードレールをどの層に置いたのか。こうした判断の説明は、コードを読まなくても力量が伝わります。

案件動向と単価について

AIエージェント開発の案件は、首都圏中心の主要フリーランスエージェント数社の公開案件欄を2026年10月時点で確認した限りでは、LLMアプリ開発の一角として募集が見られます。ただしフレームワーク名を限定した募集は多くなく、「LangChain / LangGraph / Agents SDKのいずれか」といった括りで書かれているケースが目立ちます。特定SDKの習熟より、エージェント設計の経験そのものが評価軸になりやすい領域です。

単価レンジや必要スキルの詳細はAIエージェント開発案件の単価相場｜必要スキル・獲得ルートを解説で整理しています。自分の経験でどのくらいの単価を狙えるか確かめたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？にまとめています。

実装前チェックリスト

着手時に確認しておくと手戻りが減る項目です。

• 使用モデルをエージェント定義に明示したか（既定任せにしていないか）

• Responses API と Chat Completions API のどちらを使うか決めたか

• トレースの有効・無効と送信内容を、顧客側と合意したか

• 入力ガードレールを並列実行にするか、ブロッキングにするか決めたか

• セッションの保存先が、想定するワーカー構成に合っているか

• ハンドオフの履歴引き継ぎ範囲を input_filter で制御する必要があるか

• 出力型を構造化（Pydanticモデル）すべき箇所を洗い出したか

• Agent Builderから移行する案件の場合、既存ワークフローの分岐条件を書き起こしたか

まとめ

Agents SDKは「概念を6つ覚えればエージェントの実行ループを任せられるフレームワーク」であり、分岐やループを自分で設計したい要件ではLangGraphのほうが適します。

• 迷ったら、まず1体のエージェントを早く動かしたいならAgents SDK、複雑な分岐や承認フローを厳密に設計したいならLangGraph

• 中核はAgents・Tools・Handoffs・Guardrails・Sessions・Tracingの6つ。立ち上げは15分、素振りは2〜3時間が目安（LLM API経験者の場合）

• LangGraphとの差は状態の持ち方。会話履歴ベースか、共有Stateと有向グラフか

• トレースは既定で有効。送信内容を説明できないまま顧客環境に入れない

• 入力ガードレールの並列実行はコストに跳ねる。遮断率を測ってから実行モードを決める

• ハンドオフは履歴が丸ごと引き継がれる。input_filterでの制御を前提に設計する

• Agent Builderの終了日は2026年11月30日。移行案件は分岐条件の書き起こしから始める

• 案件評価を分けるのは「本番で動かしたか」。ガードレールと評価設計まで触れておく

次のステップとしては、クイックスタートを一度通したうえで、自分の業務ドメインでツールを3つ作ってみるのが現実的です。そこまで進めば、LangGraphとの比較も自分の言葉で説明できるようになります。

参照元・一次情報

• OpenAI Agents SDK 公式ドキュメント

• Quickstart - OpenAI Agents SDK

• Guardrails - OpenAI Agents SDK

• Sessions - OpenAI Agents SDK

• Models - OpenAI Agents SDK

• Agent Builder - OpenAI Developers

• OpenAI Agents SDK for TypeScript