DXC LabPublicationへの投稿
🎃

[AI Agent Jump Start：応用編#6] OpenAI Agents SDK

ayamaguchi
に公開
OpenAI
AIエージェント
tech

第1章：はじめに

エージェントフレームワークの進化が一気に加速しています。
前回の記事「[AI Agent Jump Start：応用編#5] LangGraph と Microsoft Agent Framework」 では、2大注目フレームワークである「LangGraph」と「Microsoft Agent Framework（MAF）」の設計思想・特徴・マルチエージェント対応を、データとフローに着目して比較・整理しました。

今回は、第三の選択肢として 「OpenAI Agents SDK」 に焦点を当て、その設計思想・特徴・マルチエージェント対応を詳しく解説します。

1.1 前回のおさらい

前回の記事では以下の点を整理しました：

  • LangGraph: グラフベースの状態遷移管理が特徴。LangChainに依存せず、V1で本番利用を前提とした安定版へ
  • Microsoft Agent Framework（MAF）: AutoGenとSemantic Kernelの統合により誕生。Microsoftエコシステムとの強力な連携

両者とも強力なフレームワークですが、それぞれ異なる設計思想と得意領域を持っています。

第2章：OpenAI Agents SDK 概略

2.1 OpenAI Agents SDK とは？

OpenAI Agents SDK は、OpenAI が提供する エージェント実装向けの SDK です。
Python / TypeScript のライブラリとして提供されており[1]、少数のプリミティブ（Agents / Handoffs / Guardrails / Sessions / Tools / Tracing）を組み合わせて、エージェント・アプリケーションを構築できます。[2]

公式ドキュメントでは、設計原則として次の2点が挙げられています。[2:1]

  1. 十分な機能はあるが、学習コストを抑えるためプリミティブは少なく
  2. デフォルトでよく動きつつ、必要に応じて細かくカスタマイズ可能

エージェントは「LLM ＋ ツール ＋ 指示（instructions）」の組み合わせとして定義され、Handoffs や MCP などを通じて他エージェント・外部システムと連携できます。[3]

2.2 OpenAI Agents SDK の主な特徴

OpenAI Agents SDK の主な特徴は以下です。

  • 少数プリミティブによるシンプルな設計
  • 高いベンダー中立性（OpenAI ファーストだが他社 LLM も利用可能）
  • 拡張性重視: カスタム・ツール、メモリー、プロトコルの追加が容易
  • マルチエージェント構成を前提にした Handoffs（エージェント間委譲）
  • トレーシング・監視との統合

それぞれについて解説します。

2.2.1 少数プリミティブによるシンプルな設計

Agents SDK は、以下の少数のプリミティブを中心に構成されています。[2:2]

  • Agents: LLM に instructions と tools を付与したもの
  • Handoffs: エージェント間の委譲メカニズム
  • Guardrails: 入出力のバリデーションや制約
  • Sessions: 会話履歴の管理
  • Tools: 外部システムと連携するための機能群
  • Tracing: 実行トレースの記録・可視化

公式トップページでは、

“very few abstractions（非常に少ない抽象化）”

と表現しており、「プリミティブは少ないが、その組み合わせで複雑なパターンを表現する」 という設計思想が採用されています。[2:3]

2.2.2 高いベンダー中立性（OpenAI ファーストだが他社 LLM も利用可能）

OpenAI Agents SDK は OpenAI モデルを第一級でサポート しつつ、他社 LLM や自前モデルも扱えるように設計されています。[4]

  • デフォルトモデルは gpt-4.1（記事執筆時点）などの OpenAI モデル
  • 非 OpenAI モデルについては、LiteLLM や OpenAI 互換エンドポイント経由で他社 / 自前LLMも利用可能

但し、

非 OpenAI モデル利用時は、トレーシングの無効化や独自トレーサーの設定が必要な場合あり（＝一部機能は OpenAI 前提） とされています。

2.2.3 拡張性重視: カスタム・ツール、メモリー、プロトコルの追加が容易

(1) カスタム・ツール

OpenAI Agents SDK では、ツール（Tool）を通じて外部システムと連携します。公式ドキュメントでは Tools について、少なくとも以下の形をサポートすると説明されています。[2:4]

  • Hosted tools（Responses API が提供する Web 検索、File Search、コード実行、画像生成など）
  • Function tools：任意の Python 関数やメソッドをツール化
  • Agents as tools：Agent 自体をツールとして呼び出し、別エージェントに処理を委譲

この「関数をそのままツールにできる」「他エージェントをツールとして扱える」という設計が、カスタム・ツール追加の容易さにつながっています。

(2) メモリー（Session）拡張

公式の Sessions ドキュメントでは、

「Agents SDK はビルトインのセッションメモリーを提供し、複数ターンにまたがる会話履歴を自動で保持する」

と説明されています。[5]

  • SQLiteSession、SQLAlchemySession、暗号化セッションなど複数の実装が用意されており、
  • Session プロトコルに従えば、自前ストレージを使ったメモリー実装を差し替えることも可能です。[5:1]

これにより、

  • 「とりあえず SQLiteSession で始める」
  • 「本番では自社 DB バックエンドに切り替える」

といった段階的な導入がしやすくなっています。

(3) プロトコル（MCP）の追加

OpenAI Agents SDK は Model Context Protocol (MCP) をサポートしています。[6]

  • OpenAI Agents SDK 側では、Hosted MCP / HTTP + SSE / stdio MCP サーバーなど複数のトランスポートがサポートされ、既存の MCP サーバー群を「そのままツールとして接続」できます。[6:1]

2.2.4 マルチエージェント構成を前提にした Handoffs（エージェント間委譲）

OpenAI Agents SDK は、マルチエージェント構成 を視野に入れて設計されています。中心にあるのが Handoffs（エージェント間委譲） です。[2:5]

  • 1つのエージェントから別のエージェントに「処理を回す」ための仕組みを Handoffs として定義
  • Handoffs は LLM 側からはツールとして見え、transfer_to_<agent_name> のような形で呼び出される
  • 委譲時の挙動（説明文、入力スキーマ、フィルター、コールバックなど）を細かく制御できる

この仕組みにより、マルチエージェントのデザインパターンを専用のワークフロー・エンジンなしで構成できるのが特徴です。

  • スーパーバイザーが特定ドメインの専門エージェントを呼び出す（スーパーバイザー型）
  • 任意のエージェントが、次にどのエージェントを呼び出すかを決定する（ネットワーク型）

参考：
[AI Agent Jump Start：応用編#3] AIエージェント設計の課題解決：マルチエージェントのデザインパターン

2.2.5 トレーシング・監視との統合

OpenAI Agents SDK には トレーシングが標準装備 されています。[7]

  • エージェント実行、LLM コール、ツール呼び出し、Handoffs、Guardrails などがすべて trace / span に記録され、Traces ダッシュボードで可視化可能。[7:1]
  • トレースは拡張可能で、独自の trace processor を追加することで、外部の Observability 基盤（Logfire、AgentOps、Braintrust、Scorecard、Keywords AI など）に送信可能。[8]

このため、PoC 段階から

  • 「どのツールがどれくらい呼ばれているか」
  • 「どこで時間がかかっているか」

といった 運用時に重要な情報を可視化する前提でエージェントを設計できる のも特徴です。

2.3 なぜ OpenAI Agents SDK なのか？

前記事のフレームワークとの比較という文脈で、OpenAI Agents SDK の立ち位置を整理します。

観点 LangGraph MAF OpenAI Agents SDK
中心思想 グラフによる状態管理・フロー制御 Microsoft / Azure エコシステム統合 少数プリミティブ＋OpenAI プラットフォーム統合（MCP 等のオープンプロトコル連携）
強み 複雑なワークフローの明示的な定義 Azure OpenAI や Microsoft 製品との緊密連携 OpenAI モデル／Responses API／Hosted Tools／MCP と密に統合されつつ、LiteLLM 等で他社 LLM も混在させやすい
適用領域 ワークフロー重視のアプリケーション エンタープライズ向け Azure 中心構成 OpenAI API を中核にしたエージェントアプリ全般

※この表は、各フレームワークの公式ドキュメントおよび一般的な利用スタイルに基づく筆者の整理であり、公式の比較表ではありません。

2.4 OpenAI Agents SDK がフィットしやすいニーズ

  • OpenAI を軸にしつつ、他社 LLM や自前モデルも組み合わせたい
  • ツール連携や外部システム統合を標準化された形で行いたい（MCP / Hosted tools）
  • エージェントのメモリー管理・マルチエージェント構成をライブラリ側に任せたい
  • トレーシングや評価・監視を最初から組み込みたい
  • アプリ本体はオンプレ / プライベートクラウドで動かしつつ、クラウド LLM やツールを活用したい

第3章：OpenAI Agents SDK のアーキテクチャー

第2章では、OpenAI Agents SDK を「少数のプリミティブ（Agents / Handoffs / Sessions / Tools / Tracing）を組み合わせる仕組み」として見てきました。

ここからは視点を変えて、データの観点:「データがどこにあり、どう流れていくのか」 と フローの観点:「1ターンの中で何が起きているのか / 複数エージェントをどう流すか」 を整理します。

3.1 データの観点で見る OpenAI Agents SDK

LangGraph では、グラフ全体で共有される State が中心にあり、各ノードがそれを読み書きする、というモデルがベースにあります。一方で、OpenAI Agents SDK はもう少しレイヤーがはっきり分かれています。

参考：
AI Agent Jump Start：応用編#5 LangGraph と Microsoft Agent Framework

本記事では、OpenAI Agents SDK を次の 4 つのレイヤーで捉えて行きます。

  1. 会話ログ（Items）：LLM に渡すコンテキスト
  2. セッション・メモリー：短期記憶としての「直近の会話」
  3. 長期記憶：ツールと外部ストレージとしての知識ベース
  4. 実行コンテキスト：アプリケーション側の共有状態

LangGraph にも State 以外に context/config などのコンテキスト層がありますが、ここでは「OpenAI Agents SDK ではどこまでがフレームワーク側で分けて設計されているか」に注目していきます。

3.1.1 会話ログ（Items）：LLM に渡すコンテキスト

LLM の視点 からデータを見てみます。

OpenAI Agents SDK では、LLM に渡されるコンテキストは、最終的には以下のような「メッセージの列」として扱われます[2:6][3:1]。

  • ユーザーからの入力
  • エージェントの応答
  • ツール呼び出しとその結果
  • Handoffs による別エージェントへの委譲履歴 など

これらが一つひとつ 「アイテム（Item）」として積み上がることで、次のターンの LLM に渡す「会話ログ」になります。

LangGraph で state["messages"] にメッセージを append していくイメージに近く、Agents SDK ではこの Items の列が

「LLM が見ている世界＝コンテキスト」

の役割を担います。

ここで重要なのは、

  • LLM は基本的にこの会話ログしか見ていない
  • それ以外のアプリケーション側の状態は、明示的にログへ反映しない限り LLM のコンテキストには含まれない

という点です。

3.1.2 セッション・メモリー：短期記憶としての「直近の会話」

この会話ログがどこに保存されるのかというと、OpenAI Agents SDK には、セッション（Session） という単位で会話ログを保存・復元する仕組みがあります[5:2]。

  • セッション ID ごとに、「これまでの会話ログ（Items の列）」が保存される
  • 次回エージェントを実行するときに同じセッションを指定すると、過去のログが自動的にコンテキストに差し込まれる
  • デフォルトでは SQLiteSession などの実装が提供されており、独自実装に差し替えることも可能[5:3]

「1つのセッションに紐づいた会話ログ / 直近のやり取り」＝短期記憶として扱うと、LangGraph の「短期メモリー」と対応づけて理解しやすくなります。

  • 「このユーザーとの“今回の相談”で何が話されたか」
  • 「このタスクの“直近の履歴”がどうなっているか」

3.1.3 長期記憶：ツールと外部ストレージとしての知識ベース

LangGraph では、ベクトルストアや永続的なメモリストアを「長期記憶」として扱う設計パターンがよく登場します。

OpenAI Agents SDK には、「長期記憶」という名前の抽象は登場しません。代わりに、次のような仕組みを組み合わせて「実質的な長期記憶」を構成します。

  • OpenAI の Hosted tools（Responses API 側のツール）[2:7][1:1]

    • File Search（ベクトルストア検索）
    • コード実行、ブラウザ操作、画像生成など

  • Model Context Protocol (MCP) 経由で接続されたツール群[6:2]

    • 自前のベクトルストア、RDB、GitHub、社内 API などを MCP サーバーとして公開し、ツールとして利用

  • カスタムツール（Function tools）[2:8]

    • 任意の Python 関数をツール化し、社内データベースや外部サービスにアクセスさせる

このように、OpenAI Agents SDK は

  • LLM の「すぐ近く」にある情報（会話ログ＋セッションメモリ）と
  • 必要に応じてツール経由で取りに行く情報（外部ストレージ／サービス）

を分けて設計するスタイルになっています。

設計者の視点で整理すると、

  • 短期記憶：セッション・メモリーに保持された会話ログ（直近のやりとり）
  • 長期記憶：外部ストレージへのアクセスを提供するツール（File Search / MCP / カスタムツールなど）を通じて参照される知識ベース

という2層にしておくと、LangGraph の「State＋メモリストア」の構造との対応も取りやすくなります。

3.1.4 実行コンテキスト：アプリケーション側の共有状態

ここまでは「LLM に見える世界」の話でしたが、実際のアプリケーションではそれとは別に、

  • user_id / tenant_id
  • 認可・権限情報
  • 実行環境（本番 / ステージング）
  • リクエスト ID

といった “LLM に直接見せる必要はないが、ツールやハンドオフ処理では参照したい情報” が存在します。

OpenAI Agents SDK では、こうした情報は

  • セッション・メモリー（会話ログ）には入れず、
  • Runner やツール呼び出し時に利用される 実行コンテキスト（RunContext など） にまとめて持たせる、という設計が推奨されています[2:9][5:4]。

この実行コンテキストは、

  • ツール実行時
  • Handoffs 発生時
  • Guardrails での検証時

などで共通して参照される、アプリケーション側の共有状態です。

LLM にとっては見えないが、アプリにとって重要な情報をここに集約することで、

  • LLM コンテキスト（会話ログ＋セッション）
  • アプリケーション・コンテキスト（実行コンテキスト）

を綺麗に分離して設計できます。

LangGraph でも、State とは別に runtime context や config（config["configurable"] など）を使ってアプリケーション側の情報を渡すパターンが整備されてきていますが、OpenAI Agents SDK ではこの「二層構造」が SDK レベルでより明示的に切り出されています。

3.1.5 LangGraph の State モデルとの違いと共通点

最後に、LangGraph の State モデルと対比しながら、ここまでの話をまとめます。

LangGraph の場合

  • 伝統的な説明では、グラフ全体で共有される State が中心にあり、
    各ノードが State を受け取り、更新し、次のノードに渡していくモデルです。

  • State の中には、

    • 会話メッセージ（messages）
    • 中間結果
    • フラグや進行状況
      といった、グラフ内で共有したい情報を何でも入れることができます。

  • 一方で、近年は State とは別に

    • runtime context
    • config（config["configurable"] など）
      を使うことで、「アプリケーション側のコンテキスト」と「LLM に見せるメッセージ」を分離するベストプラクティスも整備されています。

OpenAI Agents SDK の場合

  • LLM に見せるコンテキストは、「会話ログ（Items）」＋「セッション・メモリー」によって構成されます[2:10][3:2][5:5]。
  • 長期的な知識ベースは、Hosted tools や MCP／カスタムツールを通じてアクセスされる外部ストレージとして設計します[2:11][1:2][6:3]。
  • アプリケーション側の状態（user_id や環境など）は、セッション・メモリーではなく 実行コンテキスト にまとめる構造になっており、
    「LLM コンテキスト」と「アプリケーション・コンテキスト」がプリミティブの設計段階から明確に分かれている のが特徴です[2:12][5:6]。

この違いを意識しておくと、次の節で扱う「フローの観点」で、「今どのレイヤーのデータを操作しているのか？」が分かりやすくなります。

よし、3.2 節を一回まっさらにして、いま話した「中身 vs 骨格」の整理で書き直しますね。
コードは出さずに概念だけでいきます。

3.2 フローの観点で見る OpenAI Agents SDK

OpenAI Agents SDK を 「フロー（処理の流れ）をどう制御するか」 という観点から整理します。

先に、LangGraph との違いをざっくりまとめておきます。

  • LangGraph

    • フローを グラフ（ノード／エッジ）として明示的に定義するフレームワークです。
    • 「どのノードのあとにどのノードを実行するか」「どこで分岐・ループするか」を、グラフの構造そのもので表現します。

  • OpenAI Agents SDK[2:13][3:3][1:3]

    • フローを「グラフ」としては定義しません。

    • 代わりに、次の 二層構造 でフローを考えます。

      1. エージェント実行の“中身”を担当する層
      • LLM とエージェントループ（Agent Loop）が、ツール呼び出しや Handoffs を使いながらタスクを遂行する。
      • 1 回のエージェント実行の「中身」は、LLM＋Agent Loop にお任せする。

      1. アプリケーション全体の「段取り」を決める層

        • どのエージェントを、どの順番・並列度・条件で呼ぶかをアプリケーションコード側で制御する。[2:14][1:4]

3.2.1 フロー制御の二層構造

上の話を少し噛み砕くと、OpenAI Agents SDK のフロー制御は、次の二つの視点に分かれます。

  1. エージェント実行の「中身」：細かい分岐・ツール選択

    • 1 回の Runner 実行の内部で、LLM が

      • どのツールを呼ぶか
      • 何回ツールを呼び直すか
      • 別のエージェントに Handoff(委譲) すべきか
      • そろそろ最終回答を返すべきか
        といった「細かい判断」を行います[2:15][3:4][6:4]。

    • これが公式ドキュメントで説明されている エージェントループ（Agent Loop） の役割です[2:16][3:5]。

  2. アプリ全体の「骨格」：どのエージェントをどう組み合わせるか

    • アプリケーションとして、

      • どのエージェントを使うか
      • どの順番で呼ぶか
      • 並列に呼ぶのか／直列に呼ぶのか
      • どの条件でループ／リトライするのか
        を決めるのは アプリケーションコードの責務 です[2:17][1:5]。

    • ここでは Runner を「1 ステップの箱」として扱い、それを if/for/ループなどで組み合わせてワークフローを作ります。

以降では、この 2 層をもう少し詳しく見ていきます。

3.2.2 エージェント実行の「中身」：LLM ＋ Agent Loop

1 回のエージェント実行の内部で何が起きているかを説明します。

OpenAI Agents SDK では、エージェントの実行は Runner を通じて行われ、内部で エージェントループ と呼ばれるサイクルが回っています[2:18][3:6]。概念的には、次のような流れです。

  1. 現在のエージェント と、そのセッションに紐づいた 会話ログ（Items） をもとに、LLM を 1 回呼び出す[2:19][5:7]。

  2. LLM の出力を解釈し、次のいずれかに分類する[2:20][3:7]。

    • ユーザーに返してよい 最終結果（final_output）
    • 実行すべき ツール呼び出し（tool calls）
    • 別のエージェントにタスクを渡す Handoff

  3. 分類結果に応じて SDK が次のアクションを取る[2:21][3:8][6:5]。

    • 最終結果なら → ループ終了。結果を返す。
    • ツール呼び出しなら → ツールを実行し、その結果を Items に追加して再び LLM を呼び出す。
    • Handoff なら → 現在のエージェントをハンドオフ先に切り替え、コンテキストを引き継いで再び LLM を呼び出す。

  4. これを、設定された上限（max_turns など）まで繰り返す[2:22]。

ここで行われているのは、「細かい分岐・ツール選択」です。

  • この入力なら検索ツールを使うべきか？
  • 検索結果が十分でなければ、もう一度違うクエリで検索すべきか？
  • これはXXXの話なので XXX エージェントに Handoff した方がいいか？
  • もう十分情報が揃ったので、ここで最終回答を返すべきか？

といった判断は LLM と Agent Loop の担当 であり、
開発者は「どんなツール／Handoff を定義するか」「どんな instructions を与えるか」を設計することになります[2:23][3:9][6:6]。

3.2.3 フローの骨格：アプリケーション側のオーケストレーション

一方で、アプリケーション全体のフローは、もう少し大きな単位で考える必要があります。

例えば、次のような段取りを組みたいケースを考えてみます。

  1. プランナーエージェントに「全体の計画」を作らせる。
  2. 計画に従って、複数の 実行エージェント を順番に、あるいは並列に動かす。
  3. 各エージェントの結果を、最後に サマリーエージェント で統合する。
  4. 結果がしきい値を満たさなければ、この 2〜3 を最大 3 回までリトライする。

このような

  • どのエージェントを使うか
  • どの順番／並列度で呼ぶか
  • どこで止めるか／どこでループするか

といった「段取り」が、フローの骨格 です。

OpenAI Agents SDK では、この骨格部分を

Runner で エージェント 1 回実行を 1 つのステップ（箱） として扱い、
それをアプリケーションコード（if / for / ループ / 非同期処理など）で組み合わせる

というスタイルで表現します[2:24][1:6]。

たとえば：

  • あるエージェントに 構造化出力（Structured Output） で「タスク種別」や「次に呼ぶべきエージェント名」を出させ、
    その結果に応じてアプリ側の if 文で次のエージェントを選ぶ[2:25][1:7]。
  • 計画 → 実行 → 要約の 3 つのエージェントを、普通の関数呼び出しのように「順番に」呼び出す[2:26]。
  • 生成担当と評価担当のエージェントを用意し、「スコアが一定以上になるまで while ループで再生成」を行う[2:27]。
  • 同じ入力に対して複数のエージェントを並列に実行し、結果を最後に統合エージェントに渡す（ファンアウト／ファンイン）[2:28]。

ここで重要なのは、エージェントとアプリの役割分担です。

  • 1 ステップの中身の「細かい判断」は LLM＋Agent Loop に任せつつ、
  • ステップ同士をどう繋ぐか（どのエージェントをいつ・何度・並列に呼ぶか）はアプリ側で制御する

LangGraph では、この「骨格」の部分をグラフ（ノードとエッジ）で表現しますが、
OpenAI Agents SDK は「グラフ DSL の代わりに、通常のコードで書く」方針を取っています[2:29][1:8]。

3.2.4 LangGraph のフロー定義との比較

OpenAI Agents SDK のフロー設計は、

  • エージェント 1 回実行の「中身」＝細かい分岐・ツール選択は LLM＋Agent Loop に任せ、
  • エージェント同士のつながりや実行順序＝フローの骨格はアプリケーションコードで管理する[2:30][3:10][1:9]。

という二層構造になっています。

LangGraph のように「フローをグラフとして描く」アプローチとは異なり、
「プリミティブは少なく、その代わりアプリ側のコードで柔軟に組み立てられる」 というのが、OpenAI Agents SDK のフロー制御上の特徴と言えます。

どちらが良い／悪いという話ではなく、

  • 「フローを グラフとして可視化・構造化したいか」
  • 「既存のアプリケーション構造（サービス層のコードなど）に乗せて制御したいか」

という好みや要件によって使い分けるポイントになります。

第4章：まとめと今後の展望

4.1 まとめ

本記事では、OpenAI Agents SDK を

  • 「何者か？」（第2章）
  • 「データ」と「フロー」という 2 つの観点（第3章）

から整理しました。

ざっくり言うと、OpenAI Agents SDK は[2:31][3:11][1:10]：

  • 少数のプリミティブ（Agents / Handoffs / Sessions / Tools / Tracing）を組み合わせるスタイル
  • OpenAI モデルや Responses API, Hosted tools, MCP を第一級でサポートしつつ、
    LiteLLM や互換エンドポイント経由で他社・自前 LLM も扱える、比較的ベンダー中立な設計[2:32][6:7][4:1]
  • LLM が見る世界（Items＋セッション・メモリー） と
    アプリケーションが見る世界（実行コンテキスト） を分けて設計できる[2:33][5:8]
  • フローは Agent Loop に細かい判断を任せつつ、全体の段取りはアプリ側コードで書く という二層構造[2:34][1:11][6:8]

といった特徴を持つ SDK でした。

そのため、特にフィットしやすいのは次のようなニーズです。

  • OpenAI を軸にしつつ、将来的に他社 LLM や自前モデルも混ぜたい[2:35][4:2]
  • MCP や Hosted tools を使って、ツール連携・外部システム統合を標準的な形で行いたい[2:36][1:12][6:9]
  • メモリ管理・マルチエージェント・トレーシングなどの基盤は SDK に任せ、
    既存のアプリケーションコードの中に「エージェント実行ステップ」を組み込みたい[5:9][7:2]

4.2 次回の記事予告

ここまでは、コード中心のエージェント実装フレームワークとして

  • LangGraph
  • Microsoft Agent Framework
  • OpenAI Agents SDK

を取り上げ、データとフローといった観点から整理してきました。

次回は少し視点を変えて、ローコード／ノーコードのエージェント開発プラットフォーム を取り上げます。

脚注

  1. https://platform.openai.com/docs/guides/agents-sdk "Agents SDK - OpenAI API" ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. https://openai.github.io/openai-agents-python/ "OpenAI Agents SDK" ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  3. https://openai.github.io/openai-agents-python/agents/ "Agents - OpenAI Agents SDK" ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. https://openai.github.io/openai-agents-python/models/ "Models - OpenAI Agents SDK" ↩︎ ↩︎ ↩︎

  5. https://openai.github.io/openai-agents-python/sessions/ "Sessions - OpenAI Agents SDK" ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  6. https://openai.github.io/openai-agents-python/mcp/ "Model context protocol (MCP) - OpenAI Agents SDK" ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  7. https://openai.github.io/openai-agents-python/tracing/ "Tracing - OpenAI Agents SDK" ↩︎ ↩︎ ↩︎

  8. https://pypi.org/project/openai-agents/ "OpenAI Agents SDK" ↩︎

DXC Lab
DXC LabPublication

AI / Data Science / Robotics のエンジニア集団として情報を公開していきます。 日本IBMシステムズ・エンジニアリングのLab組織が有志で活動をしています。

Discussion