【2026年最新】OpenAI Agents SDK実践ガイド｜Pythonでマルチエージェントを構築

結論: OpenAI Agents SDKは、わずか数十行のPythonコードでマルチエージェントシステムを構築できる軽量フレームワークです。Handoff（エージェント間の引き継ぎ）とGuardrails（安全性制御）を組み込んだプロダクション品質のAIエージェントを、最短5分で動かせます。

この記事の要点:

• 要点1: OpenAI Agents SDKは2025年3月公開のオープンソースSDK。旧Assistants API（2026年8月廃止予定）の後継となる実装手段
• 要点2: Agent・Runner・Handoff・Guardrails・Tracingの5つの基本概念を押さえれば、複雑なマルチエージェントも構築可能
• 要点3: LangGraphやCrewAIと比較して学習コストが圧倒的に低い。GPT系モデル利用なら最速の選択肢

対象読者: AIエージェント構築に興味のあるPython開発者、ChatGPT APIを使ったことがあるエンジニア

読了後にできること: OpenAI Agents SDKを使って、ツール呼び出し・マルチエージェント連携・安全性制御を備えたAIエージェントを自力で構築できる

---

「AIエージェントを作りたいけど、LangChainは複雑すぎるし、どのフレームワークを選べばいいかわからない」——そんな声をよく耳にします。

2025年3月、OpenAIがリリースしたAgents SDKは、この問題に対するOpenAI公式の回答です。従来のAssistants APIがサーバーサイドで状態を管理する「重い」アーキテクチャだったのに対し、Agents SDKはローカルで動作する軽量なPythonライブラリとして設計されています。

特筆すべきは、その「薄さ」です。LangGraphのようなグラフベースの制御フローも、CrewAIのような役割定義DSLも必要ありません。Agentを定義し、Runnerで実行する——この2ステップだけで、最初のエージェントが動き始めます。

この記事では、インストールから本番運用レベルのマルチエージェント構築まで、5つのコード例を使って段階的に解説します。手を動かしながら読み進めてください。

まず試したい「5分クイックスタート」

まずは動くものを作りましょう。Python 3.10以上がインストールされていれば、3コマンドで最初のエージェントが動きます。

💡 補足：本記事ではPython版を解説しますが、OpenAIはJavaScript/TypeScript版（openai-agents-js）も公式に提供しています。TypeScript開発者はそちらもご検討ください。

インストール

# 仮想環境の作成（推奨）
python -m venv agents-env
source agents-env/bin/activate  # Windows: agents-envScriptsactivate

# SDKのインストール
pip install openai-agents

# APIキーの設定
export OPENAI_API_KEY="sk-..."

openai-agentsパッケージは、内部でopenaiライブラリに依存しています。別途pip install openaiする必要はありません。

最初のエージェント（コード例1）

from agents import Agent, Runner

# エージェントの定義
agent = Agent(
    name="tech_writer",
    instructions="あなたはAI技術に詳しいテックライターです。"
                 "質問に対して、具体的なコード例を交えて簡潔に回答してください。",
    model="gpt-4o"
)

# 同期実行
result = Runner.run_sync(agent, "Pythonでファイルを非同期に読み込む方法を教えて")
print(result.final_output)

たったこれだけです。Agentに名前・指示・モデルを渡し、Runner.run_sync()で実行するだけ。戻り値のresult.final_outputにエージェントの最終回答が入ります。

非同期で実行したい場合は、以下のようにawait Runner.run()を使います。

import asyncio
from agents import Agent, Runner

agent = Agent(
    name="tech_writer",
    instructions="AI技術に詳しいテックライターです。簡潔に回答してください。",
)

async def main():
    result = await Runner.run(agent, "FastAPIとFlaskの違いを3行で")
    print(result.final_output)

asyncio.run(main())

OpenAI Agents SDKの基本概念

Agents SDKは5つのコアコンセプトで構成されています。これらを理解すれば、どんな複雑なワークフローも組み立てられます。

概念	役割	ひとことで言うと
Agent	LLMの設定をまとめたユニット。instructions、tools、handoffsを持つ	「何ができるか」を定義した人格
Runner	エージェントの実行エンジン。ループ処理・ツール呼び出し・Handoffを自動管理	エージェントを動かすマネージャー
Handoff	あるエージェントから別のエージェントへタスクを委譲する仕組み	担当者の引き継ぎ
Guardrails	入力・出力の検証とフィルタリング。不適切な内容をブロック	安全装置
Tracing	実行ログの自動記録。LLM呼び出し・ツール実行・Handoffを可視化	デバッグ用の記録係

Assistants APIとの違い

OpenAIは2026年8月にAssistants APIを廃止予定です。後継となるResponses APIとAgents SDKの違いを整理しておきましょう。

項目	Assistants API（廃止予定）	Agents SDK
状態管理	サーバーサイド（Thread/Run）	クライアントサイド（ローカル実行）
マルチエージェント	非対応（1 Assistant = 1 Thread）	Handoffで自在に連携
安全性制御	なし（自前実装）	Guardrails組み込み
デバッグ	ログ取得が困難	Tracing自動記録
オープンソース	APIのみ（クローズド）	MIT License（GitHub公開）
モデル選択	OpenAIモデルのみ	プロバイダー非依存（設定次第で他モデルも可）

実装ガイド

ここからは、段階的にエージェントの機能を拡張していきます。Step 1で作った基本エージェントに、ツール → マルチエージェント → Guardrails → Tracingと機能を積み上げていく構成です。

Step 1: 基本エージェントの作成

前節のクイックスタートで基本エージェントは作成済みです。ここではmodel_settingsを使って、LLMの挙動をカスタマイズする方法を紹介します。

from agents import Agent, Runner, ModelSettings

agent = Agent(
    name="code_reviewer",
    instructions="""あなたはシニアPythonエンジニアです。
    コードレビューを行い、以下の観点でフィードバックしてください：
    1. バグの可能性
    2. パフォーマンス改善
    3. 可読性向上""",
    model="gpt-4o",
    model_settings=ModelSettings(
        temperature=0.2,          # 低めで一貫した回答
        max_tokens=2000,
        parallel_tool_calls=True  # ツール並列実行を許可
    )
)

ModelSettingsではtemperatureやトークン数の上限などを細かく制御できます。コードレビューのように一貫性が重要なタスクではtemperatureを低く設定するのがポイントです。

Step 2: ツール（Function Calling）の追加（コード例2）

エージェントの真価は「外部ツールとの連携」にあります。@function_toolデコレータを使えば、任意のPython関数をツールとして登録できます。

from agents import Agent, Runner, function_tool
import json
from datetime import datetime

@function_tool
def get_stock_price(ticker: str) -> str:
    """指定された銘柄の現在の株価を取得します。

    Args:
        ticker: 銘柄コード（例: "AAPL", "GOOGL", "7203.T"）
    """
    # 実際のAPIコールに置き換えてください
    prices = {
        "AAPL": 245.32,
        "GOOGL": 192.15,
        "NVDA": 1340.50,
        "7203.T": 2890.00,
    }
    price = prices.get(ticker.upper())
    if price is None:
        return f"銘柄コード '{ticker}' が見つかりません"
    return json.dumps({
        "ticker": ticker.upper(),
        "price": price,
        "currency": "JPY" if ".T" in ticker else "USD",
        "timestamp": datetime.now().isoformat()
    })

@function_tool
def calculate_position_size(
    budget: float,
    price: float,
    risk_percent: float = 2.0
) -> str:
    """投資予算とリスク許容度からポジションサイズを計算します。

    Args:
        budget: 投資予算（円）
        price: 1株あたりの価格
        risk_percent: リスク許容度（%、デフォルト2%）
    """
    risk_amount = budget * (risk_percent / 100)
    shares = int(risk_amount / price)
    return json.dumps({
        "recommended_shares": shares,
        "total_cost": shares * price,
        "risk_amount": risk_amount
    })

# ツールを持つエージェント
investment_agent = Agent(
    name="investment_advisor",
    instructions="""あなたは投資アドバイザーです。
    ユーザーの質問に対して、必ずツールを使って根拠のある回答をしてください。
    投資判断の最終責任はユーザーにあることを必ず伝えてください。""",
    tools=[get_stock_price, calculate_position_size],
    model="gpt-4o"
)

result = Runner.run_sync(
    investment_agent,
    "NVIDIAの株価を調べて、100万円の予算でポジションサイズを計算して"
)
print(result.final_output)

@function_toolのポイントは3つです。

• 型アノテーション必須: 引数と戻り値に型を書くと、SDKが自動でJSON Schemaを生成
• docstringが重要: LLMがツールの使いどころを判断する材料になる。Argsセクションも丁寧に書く
• 戻り値はstr: JSON文字列で返すとLLMが構造的に解釈しやすい

Step 3: マルチエージェントとHandoff（コード例3）

Handoffは、Agents SDKの最も強力な機能です。「トリアージ → 専門エージェント」のパターンで、カスタマーサポートBOTを実装してみましょう。

from agents import Agent, Runner

# 専門エージェント1: 技術サポート
tech_support = Agent(
    name="tech_support",
    instructions="""あなたは技術サポート担当です。
    以下のルールに従ってください：
    - ソフトウェアの不具合、設定方法、エラーメッセージに関する質問に回答
    - 解決できない場合は「エスカレーション番号」を発行して案内
    - 回答は箇条書きで簡潔に""",
    model="gpt-4o"
)

# 専門エージェント2: 請求・返金対応
billing_agent = Agent(
    name="billing_agent",
    instructions="""あなたは請求・返金担当です。
    以下のルールに従ってください：
    - 請求内容の確認、プラン変更、返金処理に対応
    - 返金は購入から30日以内のみ可能
    - 個人情報の確認は必ず行う（名前とメールアドレス）""",
    model="gpt-4o"
)

# 専門エージェント3: 一般問い合わせ
general_agent = Agent(
    name="general_agent",
    instructions="""あなたは一般問い合わせ担当です。
    営業時間、サービス概要、FAQ的な質問に回答してください。
    技術的な質問や請求関連は対応しないでください。""",
    model="gpt-4o-mini"  # 軽い質問にはコスト効率の良いモデル
)

# トリアージエージェント（最初の振り分け役）
triage_agent = Agent(
    name="triage_agent",
    instructions="""あなたはカスタマーサポートの受付担当です。
    ユーザーの問い合わせ内容を判断し、適切な担当者に引き継いでください。

    振り分け基準：
    - 技術的な問題（バグ、エラー、設定）→ tech_support
    - 請求・返金・プラン変更 → billing_agent
    - その他の一般的な質問 → general_agent""",
    handoffs=[tech_support, billing_agent, general_agent],
    model="gpt-4o-mini"  # 振り分けだけなので軽量モデルでOK
)

# 実行
result = Runner.run_sync(
    triage_agent,
    "先月の請求が二重になっているみたいなんですが、返金してもらえますか？"
)
print(result.final_output)

# どのエージェントが最終的に回答したか確認
print(f"n最終回答エージェント: {result.last_agent.name}")
# → "billing_agent" と表示されるはず

このコードのポイントは以下の通りです。

• HandoffはLLMにとって「ツール」として見える: triage_agentから見ると、transfer_to_tech_supportのようなツールが自動生成される
• Runnerが自動でループ処理: Handoff先のエージェントが最終回答を返すまで、Runnerが実行ループを回し続ける
• コスト最適化: トリアージや軽い質問にはgpt-4o-mini、専門的な回答にはgpt-4oを使い分ける

Step 4: Guardrailsによる安全性確保（コード例4）

プロダクション環境では、ユーザー入力のバリデーションとエージェント出力のフィルタリングが不可欠です。Agents SDKには、入力ガードレールと出力ガードレールの2種類が用意されています。

from pydantic import BaseModel
from agents import (
    Agent,
    Runner,
    input_guardrail,
    output_guardrail,
    GuardrailFunctionOutput,
    InputGuardrailTripwireTriggered,
    OutputGuardrailTripwireTriggered,
)

# --- 入力ガードレール ---
class ContentCheckOutput(BaseModel):
    is_inappropriate: bool
    reasoning: str

# 入力チェック用の補助エージェント
content_checker = Agent(
    name="content_checker",
    instructions="""ユーザーの入力が以下に該当するか判定してください：
    - 個人情報の不正取得を目的とした質問
    - 違法行為に関する質問
    - 誹謗中傷や差別的な内容
    該当する場合は is_inappropriate=True にしてください。""",
    output_type=ContentCheckOutput,
    model="gpt-4o-mini"
)

@input_guardrail
async def check_inappropriate_input(ctx, agent, input_data):
    """不適切な入力をブロックする入力ガードレール"""
    result = await Runner.run(
        content_checker,
        input_data,
        context=ctx.context
    )
    return GuardrailFunctionOutput(
        output_info=result.final_output,
        tripwire_triggered=result.final_output.is_inappropriate
    )

# --- 出力ガードレール ---
class OutputSafetyCheck(BaseModel):
    contains_pii: bool
    reasoning: str

output_checker = Agent(
    name="output_checker",
    instructions="""エージェントの出力に以下が含まれていないか確認してください：
    - 電話番号、メールアドレス、住所などの個人情報
    - APIキーやパスワードなどの機密情報
    含まれている場合は contains_pii=True にしてください。""",
    output_type=OutputSafetyCheck,
    model="gpt-4o-mini"
)

@output_guardrail
async def check_output_safety(ctx, agent, output_data):
    """個人情報漏洩を防ぐ出力ガードレール"""
    result = await Runner.run(
        output_checker,
        output_data,
        context=ctx.context
    )
    return GuardrailFunctionOutput(
        output_info=result.final_output,
        tripwire_triggered=result.final_output.contains_pii
    )

# ガードレール付きエージェント
safe_agent = Agent(
    name="safe_assistant",
    instructions="ユーザーの質問に丁寧に回答してください。",
    input_guardrails=[check_inappropriate_input],
    output_guardrails=[check_output_safety],
    model="gpt-4o"
)

# 実行（不適切な入力はブロックされる）
import asyncio

async def main():
    try:
        result = await Runner.run(
            safe_agent,
            "AIエージェントの活用方法を教えてください"
        )
        print(result.final_output)
    except InputGuardrailTripwireTriggered:
        print("入力が安全ポリシーに違反しています。")
    except OutputGuardrailTripwireTriggered:
        print("出力に機密情報が含まれている可能性があります。")

asyncio.run(main())

Guardrailsの設計で重要なのは、ガードレール自体もエージェントで実装できる点です。ルールベースのフィルタリングではなく、LLMの判断力を使って文脈に応じた柔軟なチェックが可能になります。ただし、ガードレール用エージェントにはgpt-4o-miniのようなコスト効率の良いモデルを使うことで、コスト増を抑えましょう。

Step 5: Tracingによるデバッグ（コード例5）

Agents SDKのTracingはデフォルトで有効です。エージェント実行中のすべてのイベント——LLM呼び出し、ツール実行、Handoff、ガードレール——が自動的に記録されます。

from agents import Agent, Runner, function_tool, trace
import asyncio

@function_tool
def search_knowledge_base(query: str) -> str:
    """社内ナレッジベースを検索します。

    Args:
        query: 検索クエリ
    """
    # 実際にはベクトルDBへの検索処理
    return f"検索結果: '{query}' に関する3件のドキュメントが見つかりました。"

agent = Agent(
    name="support_bot",
    instructions="社内ナレッジベースを使って質問に回答してください。",
    tools=[search_knowledge_base],
    model="gpt-4o"
)

async def main():
    # trace()でカスタムスパンを追加
    with trace("customer_inquiry_flow"):
        result = await Runner.run(
            agent,
            "新しいプロジェクトの作成方法を教えて"
        )
        print(result.final_output)

    # トレースはOpenAIダッシュボードで確認可能
    # https://platform.openai.com/traces

asyncio.run(main())

トレースの確認方法は3つあります。

• OpenAIダッシュボード: platform.openai.com/traces でビジュアルに確認
• カスタムエクスポーター: Datadog、Langfuseなどの外部ツールにトレースを送信可能
• 環境変数で無効化: OPENAI_AGENTS_DISABLE_TRACING=1でオフにできる

他フレームワークとの比較

AIエージェントフレームワークは群雄割拠の状態です。主要3つのフレームワークを、実務で重要な7つの観点で比較します。

比較項目	OpenAI Agents SDK	LangGraph	CrewAI
設計思想	ミニマル・軽量	グラフベース状態機械	役割ベースチーム
学習コスト	低い（数時間）	高い（1〜2週間）	中程度（2〜3日）
モデル対応	OpenAI中心（他も設定可）	モデル非依存	モデル非依存
ワークフロー制御	Handoff（暗黙的ルーティング）	明示的グラフ定義	Sequential / Hierarchical
状態管理	Sessions（SQLite等）	チェックポイント内蔵	Shared Memory
プロダクション実績	成長中	最多（月間3,800万DL）	急成長（GitHub 44,600+星）
最適ユースケース	GPT系での高速プロトタイプ	複雑な状態遷移が必要なシステム	チーム型タスク分担

どれを選ぶべきか？

• 「まず動くものを1日で作りたい」 → OpenAI Agents SDK。GPT系モデルを使うなら最速
• 「複雑な分岐・ループ・状態管理が必要」 → LangGraph。明示的なグラフ定義で予測可能な挙動
• 「ビジネスワークフローをチーム体制で回したい」 → CrewAI。役割定義が直感的

なお、CrewAI → LangGraphへの移行が最も多いパターンとして報告されています。CrewAIでプロトタイプを作り、制御フローの限界に当たった段階でLangGraphに移行する——というのが現実的なルートです。

コスト試算：GPT-4oベースのマルチエージェント

Agents SDK自体は無料（MITライセンス）ですが、裏側ではOpenAI APIを呼び出すため、トークン消費量がそのままコストになります。

モデル	入力（100万トークンあたり）	出力（100万トークンあたり）	用途の目安
GPT-4o	$2.50	$10.00	専門エージェントの回答生成
GPT-4o-mini	$0.15	$0.60	トリアージ、ガードレール

重要なのはトリアージやガードレールにはgpt-4o-miniを使い、専門的な回答生成にだけgpt-4oを使う設計です。Step 3のコード例で示したように、エージェントごとにモデルを使い分けることで、品質を保ちながらコストを大幅に抑えられます。

【要注意】実装時の失敗パターン

Agents SDKは簡潔なAPIが魅力ですが、本番運用で踏みがちな落とし穴があります。事前に知っておくことで、手戻りを防ぎましょう。

失敗1: Handoffのループ地獄

❌ エージェントA → B → A → B…と無限にHandoffが発生する

⭕ Runner.run()のmax_turnsパラメータで上限を設定する

# max_turnsで無限ループを防止
result = await Runner.run(
    triage_agent,
    "質問内容",
    max_turns=10  # 最大10ターンで打ち切り
)

Handoffの指示が曖昧だと、エージェント同士が「これは自分の担当じゃない」と押し付け合うことがあります。各エージェントのinstructionsに明確な担当範囲と境界条件を書くことが重要です。

失敗2: ガードレールのコスト爆発

❌ 入力・出力の両方にGPT-4oのガードレールを設定し、1リクエストで4回のAPI呼び出しが発生

⭕ ガードレールにはgpt-4o-miniを使い、コストを1/15以下に抑える。または、単純なチェックにはLLMを使わずルールベースで実装する

# ルールベースのガードレール（LLM不要、コストゼロ）
@input_guardrail
async def check_input_length(ctx, agent, input_data):
    is_too_long = len(input_data) > 10000
    return GuardrailFunctionOutput(
        output_info={"length": len(input_data)},
        tripwire_triggered=is_too_long
    )

失敗3: @function_toolのdocstring省略

❌ docstringを書かないと、LLMがツールの用途を正しく判断できず、不適切なタイミングでツールを呼び出す

⭕ 関数名・docstring・Argsの3点セットを必ず書く。特にArgsの説明はLLMの判断精度に直結する

失敗4: Assistants APIからの移行で状態管理を見落とす

❌ Assistants APIのThread（サーバーサイド永続化）と同じ感覚で、会話履歴が自動保存されると期待する

⭕ Agents SDKのSessions機能を使って明示的に会話履歴を管理する。SQLiteSessionやOpenAIConversationsSessionが用意されている

まとめ：今日から始める3つのアクション

OpenAI Agents SDKは、「AIエージェントを作りたいけど、どこから手をつければいいかわからない」という開発者にとって、最も取り組みやすい選択肢です。

Agents SDKは発展途上のフレームワークですが、OpenAIがAssistants APIの後継として注力しているプロダクトです。2026年8月のAssistants API廃止に向けて、今のうちにキャッチアップしておくことを強く推奨します。

より複雑なAIエージェントの構築パターンやビジネス活用については、AIエージェント完全ガイドもあわせてご覧ください。

参考・出典

• OpenAI Agents SDK 公式ドキュメント
• openai/openai-agents-python – GitHub
• Agents SDK | OpenAI API Guide
• Assistants API Migration Guide | OpenAI
• OpenAI API Pricing
• OpenAI Agents SDK vs LangGraph vs Autogen vs CrewAI – Composio

---

あわせて読みたい:

• AIエージェントフレームワーク勢力図【2026年最新】 — OpenAI Agents SDKの競合を含む最新勢力図

著者プロフィール

佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を行う。著書『AIエージェント仕事術』（SBクリエイティブ）。