Agents SDKは有料ですか？オープンソースですか？

SDK自体はMITライセンスの無料オープンソースプロジェクト（pip install openai-agents）ですが、OpenAIのモデルやホステッドツール（Code Interpreter、File Search）を利用するとAPI料金が発生します。Code Interpreterは1セッション$0.03、File Searchは1GB/日あたり$0.10に加え、1,000回呼び出しごとに$2.50です。

ClaudeやGeminiをAgents SDKと組み合わせて使えますか？

可能ですが、条件があります。SDKのモデル推論レイヤーはOpenAI互換APIやLangDBなどのサードパーティアダプターを通じてClaude、Geminiなどのモデルに接続できます。ただし、Threads、Vector Stores、File Searchなどのホステッドツールを使用している場合、これらの機能はOpenAIプラットフォーム上でのみ動作し、モデルと一緒に移行することはできません。

サンドボックスはどれが一番安いですか？E2B、Modal、Daytonaの選び方は？

開発テストにはE2B（$100の無料クレジット）、本番デプロイにはModal（月$30の無料クレジット、秒単位課金で最低料金なし）、エンタープライズコンプライアンスにはDaytona（$200の無料クレジット、セルフホスティング対応）がおすすめです。月額$20-50の個人開発者には、Modalの秒単位課金モデルが最もコスパに優れています。

旧Assistants APIとの違いは？Assistants APIはまだ使えますか？

Agents SDKはAssistants APIの進化版です。主な違いはharness/compute分離アーキテクチャとオープンソースによる制御性です。Assistants APIは現在も利用可能ですが、OpenAIの開発重点は完全にAgents SDKに移行しています。新規プロジェクトではAgents SDKの採用を推奨します。

Pythonが分かりません。TypeScriptでAgents SDKを使えますか？

Agents SDKにはTypeScript版がありますが、2026年4月時点で全ての新機能（sandbox、harness、code mode、subagents）はPythonのみ対応です。TypeScriptサポートは「将来のバージョンで予定」とされていますが、具体的なスケジュールは未定です。これらの新機能が必要な場合、現状ではPythonを使うしかありません。

OpenAI Agents SDK 個人開発者実践ガイド（2026年4月版）

AI Agentでサイドプロジェクトを作りたいのに、トレーシング、サンドボックス、マルチエージェント連携といったインフラの組み立てに時間を取られていませんか。OpenAI Agents SDKは2026年4月に大型アップデートをリリースし、これらバラバラだったピースを一つの統合APIにまとめました。ただし、pip installする前に、公式ドキュメントが直接教えてくれないことがいくつかあります。

TL;DR

Agents SDKは無料のオープンソース（MITライセンス）。ただしホステッドツールとモデル呼び出しには費用が発生し、コスト構造は非線形
「Model-agnostic」には条件あり：推論レイヤーは差し替え可能だが、ホステッドツールを使うとOpenAIプラットフォームにロックイン
2026年4月の新機能はすべてPython限定：sandbox、harness、code modeにTypeScript版なし
真のアーキテクチャ革新はharnessとcomputeの分離であり、sandbox自体ではない
月額$20-50の開発者向け：テストはE2B、デプロイはModal、Manifestで自前ストレージを接続しベンダーロックインを回避

Agents SDKはmodel-agnosticだと思っていた？その自由度には条件がある

OpenAIの公式ドキュメントはAgents SDKが100以上のLLMに対応すると謳っています。技術的にはその通りです。SDKのモデル推論レイヤーは、OpenAI互換APIを通じてClaude、Gemini、DeepSeekなどのモデルに接続でき、LangDBなどのサードパーティアダプターには詳細なチュートリアルもあります。

しかし、ここで重要な区別があります：モデルの差し替えはプラットフォームの差し替えではないということです。

Threads、Vector Stores、File Search、Code Interpreterといったホステッドツールを使い始めると、エージェントのデータはOpenAIのプラットフォーム上に保存されます。これらのツールには汎用的なインターフェースがなく、Vector Storeのインデックスを直接Pineconeにエクスポートしたり、Threadの会話履歴を他のフレームワークに移行したりすることはできません。

個人開発者にとって、現実的な戦略は以下の通りです：

推論レイヤー：OpenAIモデルで始めて問題なし。後から切り替えできることを知っておく
データレイヤー：各ホステッドツールを慎重に評価し、自前の代替手段があればそちらを使う
ストレージレイヤー：ManifestでS3/GCSをマウントし（後述）、データのポータビリティを確保

真のアーキテクチャ革新はsandboxではなく、harnessとcomputeの分離にある

多くのメディアは「sandbox新機能」に焦点を当てましたが、The New Stackの技術分析はより深い設計思想を指摘しています：今回のアップデートの核心はharness（制御層）とcompute（実行層）の分離です。

なぜこれが重要なのか。従来のアーキテクチャでは、APIキー、データベースパスワード、サードパーティのトークンがエージェントコードと同じ実行環境に存在していました。モデルがプロンプトインジェクション攻撃を受けた場合、攻撃者はエージェントにクレデンシャルを漏洩させる可能性がありました。

harness/compute分離は基本的な前提に基づいて設計されています：脅威は必ず発生すると想定する（assume threats will occur）。クレデンシャルは常にharnessレイヤーに留まり、モデル生成コードが実行されるサンドボックス環境には入りません。サンドボックスが突破されても、攻撃者はキーを取得できません。

テスト時、Modalサンドボックス環境内でimport os; print(os.environ.get("OPENAI_API_KEY"))を実行し、harnessレイヤーで設定したAPIキーの読み取りを試みました。結果はNoneで、harnessレイヤーの隔離が有効であること（harnessのクレデンシャルがsandboxの環境変数に注入されない）を確認できました。個人開発者にとっては、自前のクレデンシャル隔離メカニズムを構築する必要がなくなり、SDKがアーキテクチャレベルで解決してくれるということです。

この設計は、社内のセキュリティチームを説得する強力な論拠にもなります。「sandboxを追加しました」ではなく、「攻撃は必ず起こると想定し、機密データを実行環境に一切置かない設計にしています」と説明できます。

ゼロから最初のAgent：Indie Makerの最速パス

まずはインストールしましょう。Agents SDKの現行バージョンはv0.14.2です（本記事はこのバージョンを基準にしています。SDKは急速に進化中のため、最新APIは公式ドキュメントで確認してください）。Python 3.10+が必要です：

pip install openai-agents

前提条件：OpenAI APIキー（環境変数OPENAI_API_KEYに設定済み）とPython 3.10+がインストール済みであること。

最小限のエージェントはわずか数行で作れます：

from agents import Agent, Runner

agent = Agent(
    name="idea-validator",
    instructions="あなたはサイドプロジェクトのアイデア検証アシスタントです。ユーザーのアイデアを分析し、市場での実現可能性の評価と推奨するMVP機能リストを提供してください。"
)

result = Runner.run_sync(agent, "AIで週報を自動生成するSlack botを作りたい")
print(result.final_output)

これが最小版です。しかし、Agents SDKで本当に時間を節約できたのはAgent自体ではなく、設定不要の組み込みトレーシングです。Runner.run()の呼び出しごとに、各ツールコールの入出力、トークン消費量、レイテンシを含む完全な実行軌跡が自動記録されます。OpenAI Dashboardですべて確認できます。

LangChainでエージェントを構築した経験があれば、LangSmithのトレーシング設定にどれだけ時間がかかるか分かるでしょう。Agents SDKはこれをゼロ設定にしてくれます。週末しかサイドプロジェクトの時間がない人にとって、節約できるのはセットアップ時間だけでなく、デバッグ時間でもあります。

ツールの追加も直感的です：

from agents import Agent, Runner, function_tool

@function_tool
def check_domain(domain: str) -> str:
    """ドメイン名が利用可能かチェック"""
    # チェックロジック
    return f"{domain} は利用可能です"

agent = Agent(
    name="idea-validator",
    instructions="あなたはサイドプロジェクトのアイデア検証アシスタントです。ドメイン名の利用可否を確認できます。",
    tools=[check_domain]
)

インストールからツール付きエージェントの初回実行まで、実測30分以内でした（APIキーとPython 3.10+環境が既にある前提）。

エージェントがコード実行、ファイル読み書き、シェルコマンドの実行を必要とする場合、サンドボックスが必要です。Agents SDKはv0.14.0でSandboxAgentを組み込み、複数のサンドボックスプロバイダーを公式サポートしています。以下は月額$20-50の個人開発者向けの選定ガイドです：

比較項目	E2B	Modal	Daytona
無料クレジット	$100（一回限り）	月$30	$200（一回限り）
課金方式	秒単位	秒単位	秒単位
単価目安	1 vCPU 約$0.05/hr	CPU $0.059/hr〜	実際のcompute量に応じて
最大セッション	無料版1時間	ハードリミットなし	プランにより異なる
適した用途	開発テスト、プロトタイピング	本番デプロイ、散発的利用	エンタープライズコンプライアンス、セルフホスティング
個人開発者おすすめ度	入門に最適	本番デプロイに最適	コンプライアンス要件がなければオーバースペック

実際の選択：開発段階ではE2Bの無料クレジットで素早く検証し、エージェントの動作が安定してからModalにデプロイを切り替えました。Modalの秒単位課金と月$30の無料クレジットは、週末に数時間だけ動かすサイドプロジェクトにとって非常に経済的です。

E2Bの無料クレジットがなくなったら：E2Bの$100クレジットは一回限りで、使い切った後は有料です（課金方式も秒単位、1 vCPU約$0.05/hr）。開発テスト段階が終わったら、E2Bに課金し続けるよりもModalに切り替えることを推奨します。Modalの無料クレジットは毎月リセットされるため、低頻度利用のサイドプロジェクトに適しています。

コストの全体像：エージェントの費用はトークンだけではない

Agents SDKのコストはトークン料金だけだと思っている人が多いですが、実際には3つの次元が積み重なります：

1. モデルのトークン費用：基本コストで、選択するモデルによって異なります。

2. ホステッドツールの固定費用：

Code Interpreter：$0.03/セッション（各20分のコンテナ）
File Search：$0.10/GB/日（ストレージ）+ $2.50/1,000回呼び出し

3. マルチステップワークフローによるトークン膨張：各エージェントターンで完全なコンテキストが再送信されます。5ステップのワークフローでは、予想の3-4倍のトークンを消費する可能性があります。

コスト試算例（見積もりであり計画参考用です。実際の費用は利用パターンにより異なります）：

コードレビューエージェントを構築し、レビューごとに5ステップ、各ステップ平均2,000入力トークン+500出力トークン（コンテキスト再送含む）、GPT-4oを使用し、1回のCode Interpreterセッションを実行する場合：

モデルトークン（GPT-4o：$2.50/M入力、$10/M出力）：約$0.025-0.05/回
Code Interpreterセッション：$0.03/回
コンテキスト再送による膨張（マルチステップでのコンテキスト累積）：追加$0.02-0.06/回
1回のレビュー合計コスト：約$0.075-0.14

1日20回テストすると、1日$1.5-2.8、月額$45-84になる可能性があります。サンドボックスプロバイダーの費用はまだ含まれていません。

コストガードレールの推奨事項：

OpenAI Dashboardで月間利用上限を設定
max_turnsパラメータでエージェントの最大実行ステップ数を制限
開発段階では安価なモデル（GPT-4o-miniなど）を使用し、フロー確認後に高性能モデルに切り替え
File Searchのストレージ料金は日単位で課金されるため、テスト後はVector Storeをクリーンアップ

TypeScript開発者の現実：2026年4月の新機能はすべてPython限定

これが現在のAgents SDK最大の弱点だと考えています。TechCrunchとOpenAI公式の発表が確認しています：sandbox、新しいharnessアーキテクチャ、code mode、subagents——今回のアップデートのすべてのコア新機能はPython SDKが先行。TypeScript版は「将来のバージョンで対応予定」ですが、具体的な時期は明示されていません。

TypeScriptを好む個人開発者には、3つの現実的な選択肢があります：

待つ：ただしETAなし。数週間かもしれないし、数ヶ月かもしれない
新機能のためにPythonを学ぶ：Agents SDKのPython APIは非常にPythonicに設計されています。JSの基礎があれば学習曲線はそれほど急ではありません。週末を1日使って公式クイックスタートを実践すれば、基本的に使えるようになります
TypeScript + REST APIで回避：TypeScriptでメインロジックを書き、REST API経由でOpenAIのホステッドツールを呼び出す。動作はしますが遠回りで、SDKレベルのトレーシングや型安全性は享受できません

私の推奨は：sandboxとharnessの機能が必要なら、Pythonを使うことです。回り道で失う時間は学習コストを大きく上回ります。

マルチエージェント連携：handoffの現状とsubagentsの進捗

Agents SDKのマルチエージェント機能は現在2つのパートに分かれています——1つは利用可能、もう1つはまだロードマップ上：

利用可能：Handoff（シーケンシャルオーケストレーション）

Handoffはエージェント間の引き継ぎロジックを定義できます。例えば、「トリアージエージェント」がユーザーの意図を判断し、適切な「専門エージェント」に会話を引き渡します：

# 注意：importパスは最新の公式ドキュメントで確認してください。SDKは急速に進化中です
from agents import Agent, handoff

billing_agent = Agent(name="billing", instructions="請求関連の問い合わせに対応")
tech_agent = Agent(name="tech-support", instructions="技術的な問題に対応")

triage_agent = Agent(
    name="triage",
    instructions="ユーザーの問題タイプを判断し、適切な専門家に引き渡す",
    handoffs=[handoff(billing_agent), handoff(tech_agent)]
)

Handoffはシーケンシャルです：一度に実行されるエージェントは1つだけで、完了後に制御を引き渡します。ほとんどのインディーメーカーのユースケースでは、これで十分です。

ロードマップ上：Subagents（並列タスク分解）

複数のエージェントに異なるタスクを同時実行させたい場合（例：1つがデータ調査、1つがコード作成、1つがテスト実行）、subagents機能はまだロードマップ上です。

現時点で並列実行を行うには、asyncioを自分で管理する必要があります：

import asyncio
from agents import Runner

async def parallel_agents():
    results = await asyncio.gather(
        Runner.run(research_agent, "市場データを調査"),
        Runner.run(code_agent, "MVPコードを生成"),
    )
    return results

動作はしますが、SDKレベルのトレーシング統合やエラーハンドリングはありません。新しいプロジェクトのアーキテクチャを設計する際は、subagentsが利用可能だと想定しないでください。後でリライトが必要になることを避けましょう。

上級編：Manifestでベンダーロックインを回避

OpenAIエコシステムへのロックインが心配なら、Manifestが現時点で最も実用的な脱出口です。

ManifestはAgents SDKの抽象レイヤーで、エージェントのワークスペース（ファイルシステム、環境変数、リソースマウント）を特定のコンピュートプロバイダーに縛られることなく定義できます。重要なのは、Manifestを通じて自前のクラウドストレージをマウントできることです。

ハイブリッドアーキテクチャ戦略：

+----------------------------------+
|  あなたの管理範囲                  |
|  +-----------+  +--------------+ |
|  | Harness   |  | 自前         | |
|  | + Tracing |  | ストレージ    | |
|  | (SDK)     |  | (S3 / GCS)  | |
|  +-----+-----+  +------+------+ |
|        |    Manifest    |        |
|        +-------+--------+        |
+-----------------+----------------+
                  |
          +-------+--------+
          |    Sandbox      |
          | (E2B / Modal)   |
          +----------------+

この戦略の核心：

SDKのharness + tracingを活用：これらはAgents SDKのコアバリューであり、データロックインには関与しない
ストレージは自前のS3/GCSを使用：Manifestでマウントし、sandbox内のエージェントが自前ストレージに読み書き
ホステッドツールへのデータ依存を回避：File Searchは自前のベクトルデータベースで代替し、エクスポートできないコアデータをVector Storesに保存しない

Manifest最小例（概念的な例示です。最新APIは公式ドキュメントで確認してください）：

from agents.sandbox import SandboxAgent, Manifest

# エージェントのワークスペースを定義し、自前のS3ストレージをマウント
manifest = Manifest(
    filesystem={
        "/data": {"type": "s3", "bucket": "my-bucket", "prefix": "agent-output/"}
    },
    env_vars={}  # 機密クレデンシャルはharnessに保管し、manifestには含めない
)

agent = SandboxAgent(
    name="data-processor",
    instructions="/dataディレクトリ内のデータファイルを処理",
    manifest=manifest
)

注意：Manifest APIはまだ更新中です。最新情報は公式サンドボックスドキュメントを参照してください。上記は概念的な例示であり、マウント方法の理解を助けるものです。実際の構文は最新ドキュメントで確認してください。

こうしておけば、将来フレームワークを切り替えたくなっても、トレーシングデータはエクスポートでき、ストレージは自分の手元にあり、書き直す必要があるのはエージェントロジックだけです。

Agents SDK vs LangGraph vs CrewAI：選定マトリクス

Composioのフレームワーク比較と実際の使用経験に基づいて、開発者のバックグラウンドごとに適したツールは異なります：

判断基準	Agents SDK	LangGraph	CrewAI
学習曲線	低い（Python開発者向け）	中〜高（グラフ概念の理解が必要）	低い（ロールベースDSL）
トレーシング統合	組み込み、設定不要	LangSmithが必要	自前構築またはプラグインが必要
セキュリティ隔離	harness/compute分離	自前構築が必要	自前構築が必要
マルチエージェント	Handoff利用可、subagents開発中	完全なDAGサポート	成熟したロールベース連携
モデル柔軟性	条件付きmodel-agnostic	完全なmodel-agnostic	完全なmodel-agnostic
コミュニティ	急成長中（PyPI 30日間1,470万ダウンロード、公式発表）	成熟	活発だが規模は小さい

どれを選ぶべきか？

個人開発者、最速でMVPを出したい：Agents SDK。統一API + 組み込みトレーシング + 低い学習曲線で、自前インフラ構築の時間を節約
複雑なDAGワークフローが必要（例：分岐判断、条件ループ、並列実行）：LangGraph。グラフオーケストレーションはAgents SDKより成熟
エンジニア以外がエージェントを作る場合（PM、プロダクト担当者）：CrewAIのロールベースDSLの方が直感的で、async programmingの深い理解は不要
既存のLangChainシステムからの移行を検討中：移行コストを先に評価。主にトレーシングとシンプルなチェーンを使っているならAgents SDKに乗り換える価値あり。LangGraphのDAG機能に強く依存しているなら、短期的な移行は非推奨

リスク開示

ベンダーロックインリスク：ホステッドツール（File Search、Vector Stores、Code Interpreter）の使用はプラットフォーム依存を生みます。開発初期からManifest + 自前ストレージのハイブリッドアーキテクチャを計画しましょう
コストリスク：マルチステップのエージェントワークフローのトークン消費は非線形です。月間利用上限とmax_turns制限を必ず設定してください
機能ギャップリスク：TypeScriptの新機能に明確なタイムラインなし。subagentsはまだロードマップ上。ロードマップの機能を前提にアーキテクチャを設計しないでください
セキュリティリスク：harness/compute分離はセキュリティを大幅に向上させますが、ゼロリスクではありません。サンドボックス権限の設定には引き続き最小権限の原則に従ってください

リリース前チェックリスト：Agents SDK プロダクションチェックリスト

エージェントサイドプロジェクトを本番環境にデプロイする前に、以下の10項目を確認してください：

まとめ

OpenAI Agents SDKの2026年4月アップデートは、AI Agent開発の敷居を一段階引き下げました。harness/compute分離によるセキュリティ、組み込みトレーシング、統一ツールAPI——これまで自前で数週間かけて構築していたインフラが、pip install一つで手に入ります。

ただし、銀の弾丸ではありません。model-agnosticには条件があり、TypeScriptサポートは遅れており、コスト構造には隠れた非線形の膨張があります。これらの制約を理解してこそ、正しいアーキテクチャ判断ができます。

月額$20-50の個人開発者であれば、私の推奨は：Python + Agents SDKで最小版のエージェントを作り、E2Bの無料クレジットでテストし、検証後はModalにデプロイし、初日からManifestで自前ストレージを接続する。このパスなら最小コストでアイデアを検証しつつ、将来フレームワークを切り替える自由を保てます。

さあ、pip install openai-agentsで、ずっと温めていたあのAIサイドプロジェクトを始めましょう。