OpenAI Agents APIとは？AI SaaS開発は「エージェント基盤」の時代へ
- 著者
- SaaS Shift 編集部
- 公開
- 最終更新
- 読了時間
- 約6分
この記事の要約
OpenAI Agents API（Public Beta）を起点に、LLMアプリとAIエージェントの違い、開発が難しかった理由、MCPやLangGraphとの関係、SaaS競争優位の移り変わりを実務目線で解説します。
AI SaaS開発は、「LLM APIを呼び出して応答を返す」段階から、「目的達成までツールを使い続けるエージェントを安定稼働させる」段階へ移りつつあります。OpenAIが2026年9月10日にPublic Betaとして発表したAgents APIは、その変化を象徴します。Codexなどで使われているagent harnessをAPI経由で使えるようにしたもので、単純なモデルAPIではなく長時間動くエージェントの実行基盤として捉えるのが近いです。
この記事でわかること:
- LLMアプリとAIエージェントの違い
- エージェント開発がPoCと本番で分かれる理由
- Agents APIが吸収する基盤と、MCP・LangGraphとの関係
- SaaSの競争優位がどこへ移るか
仕様はPublic Betaで変わり得ます。最終判断はOpenAI公式を優先してください（本稿は2026年9月時点）。会社データは自社のセキュリティ規則を優先してください。
- OpenAI Agents APIAgents API
Codexなどで使われているmanaged Codex harnessをAPI経由で利用できる実行基盤です。OpenAIがセッション、オーケストレーション、コンテキスト圧縮（compaction）、復旧を管理し、アプリ側はツールと実行環境を提供・選択します（Agents API overview）。
OpenAI Agents APIとは
OpenAI Agents APIとは、AIエージェントを長時間・安定して動かすためのマネージド実行基盤です。 1回の質問応答APIではなく、ツール呼び出し・サンドボックス・セッション継続を含む「エージェントのループ」をOpenAI側が回します。
公式の要点は次のとおりです。
- Codex harnessをOpenAI管理のAPIとして提供
- セッション、オーケストレーション、compaction、recoveryをOpenAIが担当
- アプリはツールとEnvironment（実行環境）を選択
- Public Betaで全開発者向け。Agents API自体の追加料金はなく、モデル・ツール・ホスト型サンドボックス（container）が課金対象（Community発表）
中核概念は Agent（モデル・指示・ツール・MCP）、Environment（サンドボックス等）、Session（継続する作業）、Events / items（入出力）です。「モデルが賢い」ことと「長時間壊れない」ことは別問題で、Agents APIが狙うのは後者に近いレイヤーです。
そもそもAIエージェントとは何か
AIエージェントとは、LLMを推論エンジンとして使い、目的達成のためにツールや外部システムと複数ステップでやり取りする実行体です。 LLMと別物ではなく、LLMが「考える部分」を担い、周りに実行環境が付いた形です。
従来型:
User → Application → LLM API → Response
エージェント型:
User → Agent
├─ LLM（推論・計画）
├─ Web Search / MCP / Database
├─ Code Execution / SaaS API
└─ Sub Agents
たとえば「ログを集計→Slack要約→異常時はJira起票」は、従来型だと下書きまでは得意でも完了までには接着コードが要ります。エージェントはツールを選び、外部とやり取りし、成果まで進めます。
LLMは推論器、Agentはその推論をループ中心に置いた実行システム——対立ではなく包含関係です。
なぜAIエージェント開発は難しかったのか
難しかった主因は、モデル精度より「本番で長時間・安全に回す基盤」を自前で組む必要があったことです。 PoCのデモと、顧客テナントでの安定稼働は別問題です。
| 領域 | 何が難しいか |
|---|---|
| Context management | 履歴が窓を埋め、性能・コストが崩れる |
| Tool calling | 失敗・再試行・権限・スキーマずれがアプリ責務 |
| Memory | セッション内と永続化の設計分離 |
| Sandbox | 生成コード実行の隔離と運用 |
| MCP | 規格に加え認証・監査・障害対応 |
| Sub-agent orchestration | 分割・委譲・統合の制御 |
| Long-running tasks | 切断・再開・承認待ち |
| Observability / Security | 追跡不能な障害、過剰権限、秘密情報 |
従来は LLM + LangChain/LangGraph + Tools + Sandbox + Memory + Orchestration を組み合わせていました。基盤が製品価値に直結しないのに工数の大半を食う、というのがここ数年の実態でした。
Agents APIで何が変わるのか
変わるのは、「エージェントを動かし続ける裏側の仕組み」を、自前で全部作らずに済ませやすくなることです。
たとえばタクシー配車アプリを作るとき、地図・GPS・決済まで全部自社開発する必要はなく、地図APIや決済サービスを「買う／借りる」判断が普通にあります。AIエージェントでも同じです。これまで開発者が自作しがちだったのは、次のような裏側です。
- 調べる → ツールを呼ぶ → 結果を見て次を決める、という繰り返しの手順
- 途中で止まっても続きから再開できる作業の持ち方
- 長く動いても忘れない／壊れにくいようにする運用の土台
Agents APIは、この裏側をOpenAI側のサービスとして使えるようにします。一方で、「自社の業務で何をするか」「画面をどうするか」までは作ってくれません。厨房の設備は借りやすくなったが、メニューと接客は自社、という分担です。
| これまで | Agents API利用時 |
|---|---|
| エージェントループを自前実装 | OpenAIがモデル・ツール・コンテキストを協調 |
| 長時間セッションと再開を設計 | Sessionで継続・steering・再開 |
| コンテキスト溢れ対策を自作 | compactionをharnessが支援 |
| サンドボックスを自前調達 | hosted / self-hosted / プロバイダを選択 |
| サブエージェント委譲を自作 | multi_agentで委譲を有効化可能 |
つまり、OpenAIが「動かし続ける仕組み」を担い、開発者は自社固有の業務と体験に集中する、という分担です。
Agents APIの主要機能
各機能は「自前で抱えていた運用部品」をマネージド化する、と読むと実務判断しやすいです。
| 機能 | Before（自前） | After（Agents API） |
|---|---|---|
| OpenAI-hosted sandbox | 隔離環境の調達・監視 | LinuxワークスペースをOpenAIが提供。コード実行・ファイル・artifacts可（docs） |
| self-hosted / VPC | 社内網必須だとマネージドを諦める | 自前環境やBlaxel、E2B、Modal、Vercel等のプロバイダ接続（self-hosted） |
| 長時間セッション | 状態再構築・途中介入を自作 | Sessionが状態保持、steering可能 |
| Context compaction | 履歴要約を自作 | harnessが窓を管理 |
| Tool search | 全ツール定義を毎回載せる | 必要時に探索・ロード（Tool search） |
| Programmatic tool calling | 連続呼び出しの分岐をアプリで記述 | モデルがJSでツール連携を組み立て実行（PTC） |
| MCP / functions / Web search | 個別実装してループに接着 | tools に載せてharness配下で利用 |
| Subagents | 役割分割と統合を自作 | multi_agentで委譲を有効化 |
MCPとは何が違うのか
MCPとAgents APIはレイヤーが違います。
- MCP（Model Context Protocol）MCP
AIと外部ツール・データソースを接続するための規格です。「どう繋ぐか」の共通言語です。
- Agents APIAgent runtime
エージェントを実行・管理する基盤です。「どう動かし続けるか」のランタイムです。
Agents API（実行基盤）
→ AI Agent
→ MCP（接続規格）
→ Salesforce / Slack / DB / 社内システム
通信規格がなければ外部と話せません。規格だけあっても長時間プロセスを回す基盤がなければ本番運用はできません。MCPは前者、Agents APIは後者に近い役割です。
LangChain・LangGraphは不要になるのか
不要になる、とは言い切れません。 Agents APIはManaged基盤として強力ですが、独自オーケストレーションやベンダー非依存が重要ならLangGraph等の価値は残ります。勝敗ではなく Build vs Buy / Managed vs Custom の設計判断です。
| 観点 | Agents API（Managed寄り） | LangGraph等（Custom寄り） |
|---|---|---|
| 向くケース | 早く本番寄りの実行基盤が欲しい | 複雑な状態機械・独自ポリシーを細かく制御したい |
| オーケストレーション | OpenAI harnessに寄せる | 自前グラフで分岐・並列・人間介入を設計 |
| ベンダー依存 | OpenAI実行基盤が前提 | モデルやランタイムを差し替えやすい |
| インフラ | hosted / self-hostedの公式選択肢 | 自社K8s等に合わせて自由配置 |
| 観測・監査 | プラットフォームイベントに乗りやすい | 自社標準のトレースに合わせやすい |
| コスト感 | 立ち上げは速い／ロックインを評価 | 初期は重い／資産が自社に残る |
最初はAgents APIで立ち上げ、差別化コアだけLangGraphに残すハイブリッドも現実的です。
SaaS企業にとって何が重要になるのか
重要になるのは、基盤そのものより、その上の自社固有価値です。
これまで: LLM組込 → Agent基盤を自社構築 → 業務ロジック → UX
これから: Agent Platform利用 → 自社データ・業務・UXに集中
契約書レビューSaaSなら、サンドボックス運用より条項ライブラリ、過去指摘、法務承認、CLM連携、レビューUXが製品本体です。基盤が揃うほど、そこに投資を寄せられます。
AI SaaSの競争優位はどこへ移るのか
「誰でも作れるから差別化がなくなる」ではありません。 基盤がコモディティ化するほど、差別化は上位へ移ります。
Model + Agent Harness + Tools + Company Data + Workflow + UX
下層（Model / Harness）は大手が急速に良くします。差が残りやすいのは 独自データ、業界知識、Workflow（承認・監査）、UX、Distribution、既存Integration です。導入で勝つのは「一番賢いデモ」より、「業務に刺さり、権限と監査が説明でき、現場が使い続ける」製品でした。この構造は大きく変わりません。
今後のAI SaaS市場をどう見るか
ここからは予測・考察です。
- Agent Infrastructureのコモディティ化 — 土台の差別化余地は縮む
- 開発コスト低下 — 少人数でも垂直特化を出しやすくなる
- Vertical AI SaaSの増加 — 業界ワークフロー深耕型が増える
- MCP ecosystem拡大 — 「エージェントから使われる接続」整備が進む
- Agent Security / Governanceの重要性増加 — 権限・監査・ログが製品要件化
データレジデンシーやZDR非対応は、業界によっては採用のブレーキにもなります。技術進歩と導入制約はセットで見る必要があります。
よくある質問
- OpenAI Agents APIとは何ですか？
- Codexなどで使われているmanaged Codex harnessをAPI経由で利用できる、AIエージェントの実行基盤です。セッションやオーケストレーション、コンテキスト管理をOpenAIが担い、アプリはツールや実行環境を選択します。2026年9月10日にPublic Betaとして発表されました。
- LLMアプリとAIエージェントの違いは？
- LLMアプリは主に一往復の入出力で応答します。AIエージェントはLLMを推論部分として使い、検索・MCP・DB・コード実行などのツールを選びながら複数ステップで目的達成を目指します。対立ではなく、LLMがエージェントの中核推論を担う関係です。
- MCPとAgents APIの違いは？
- MCPは外部ツール・データへの接続規格、Agents APIはエージェントの実行・管理基盤です。Agents API上のエージェントがMCP経由でSalesforceやSlack、DBへ接続する、という関係で整理できます。
- LangChainやLangGraphは不要になりますか？
- 必ずしも不要ではありません。複雑な状態管理、ベンダー非依存、独自インフラが強い場合は引き続き有効です。Build vs Buy、Managed vs Customの設計判断として捉えるのが実務的です。
- Agents APIで差別化はなくなりますか？
- 基盤構築のハードルは下がりますが、差別化はなくなりません。独自データ、業界知識、ワークフロー、UX、流通、既存連携の重要性が増します。
まとめ
OpenAI Agents APIは「新しいモデル」の話ではなく、エージェントを本番で動かす実行基盤がAPIとして買えるようになった話です。コンテキスト管理、サンドボックス、長時間セッション、ツール連携、サブエージェント委譲の一部がOpenAI側へ寄ります。MCPは接続規格、LangGraph等はカスタムオーケストレーションとして残ります。
問いは「基盤を自作するか」から「どのデータ・業務・体験に集中するか」へ移っています。まずはAgents API overviewで試し、「基盤に寄せる部分」と「自社に残す部分」を切り分けるのが現実的です。
参考・出典
- Agents API overview（OpenAI） 2026-09
- Introducing the Agents API and hosted sandboxes（OpenAI Developer Community） 2026-09-10
- OpenAI-hosted sandboxes（OpenAI） 2026-09
- Self-hosted sandboxes（OpenAI） 2026-09
- Data controls in the OpenAI platform（OpenAI） 2026-09
- Tool search（OpenAI） 2026-09
- Programmatic Tool Calling（OpenAI） 2026-09