OpenAI Agents APIとは？
MCP・Coding Agentとの違い｜AIエージェント設計の入口

2026年9月10日、OpenAIはAgents APIをパブリックベータとして公開しました。

名前だけを見ると、「AIエージェントを作るための新しいAPI」くらいに見えるかもしれません。

しかし、このAPIで重要なのは、単に新しいModelを呼べるようになったことではありません。

ここでいうModelとは、文章生成や状況判断を担うAIモデル本体（LLM）のことです。またAgentとは、目的に向かって状況を判断し、必要に応じてToolを使いながら複数ステップの仕事を進めるAIシステムを指します。

これまで開発者側で用意することが多かった、

• Agentが仕事を続ける仕組み
• Toolを使う順序の管理
• 長くなったContext（AIが判断に使う対話や履歴情報）の整理
• Subagent（仕事を分担する別のAIエージェント）への役割の割り振り
• 失敗した処理からの復旧
• FileやCodeを扱う実行環境

といった、「AIを長時間働かせ続けるための実行基盤（Infrastructure）」までOpenAI側が担うようになったことが大きな変化です。

なお、ここでいうToolとは、検索・API・ファイル操作・コード実行など、Agentが外部へ働きかけるための手段です。

ただし、ここでいきなり、

• Session（仕事を保持する入れ物）
• Orchestration（仕事の進行管理）
• Context Compaction（情報の整理）
• Recovery（問題からの復旧）

と言われても、初めて読む人には具体的な意味が分かりません。

この記事では、こうした用語を一つずつ平易に整理しながら、

• 普通のOpenAI APIと何が違うのか
• Responses APIとは何が違うのか
• Agents SDKとは何が違うのか
• CodexやClaude Codeとは何が違うのか
• MCP（外部ツール接続規格）とは競合するのか
• なぜAgent設計を学ぶ必要があるのか

まで順番に整理します。

仕事を受け取る
  ↓
Sessionとして保持する
  ↓
必要なModelやToolを動かす
  ↓
結果を見て次の処理を決める
  ↓
Contextが長くなれば整理する
  ↓
問題が起きれば復旧する
  ↓
仕事を完了する

1. そもそもOpenAI Agents APIとは？

従来のLLM APIでは、基本的に、

入力する
  ↓
Modelが考える
  ↓
出力を受け取る

という一回のやり取りが中心でした。

もちろん現在のResponses APIでも、

• Function Calling（外部関数の呼び出し）
• Web Search
• File Search
• Computer Use
• Code Interpreter
• MCP（Model Context Protocol：外部ツール接続規格）

などを利用できます。

しかし、Agentに長い仕事を任せようとすると、それだけでは足りません。

たとえば、

「このリポジトリの問題を調べて、必要なら修正し、テストが通るまで対応して」

という仕事では、

コードを調べる
  ↓
原因を推測する
  ↓
Toolを使う
  ↓
コードを修正する
  ↓
テストする
  ↓
失敗
  ↓
原因を調べ直す
  ↓
再修正する
  ↓
完了

という処理になります。

一回Modelを呼び出して終わりではありません。

この「仕事を続ける部分」まで扱うのがAgents APIです。

2. 「Harness」とは何なのか

Agents APIを理解するうえで最初に知っておきたいのが、Agent Harnessという言葉です。

Harnessを簡単に言えば、

Modelを「答えるAI」から「仕事を続けるAgent」へ変えるための制御機構

です。

Model単体なら、

Input → Model → Output

です。

Agent Harnessが加わると、

Goal → Model → 次に何をするか判断 → Toolを選ぶ → 実行 → 結果を確認 → Contextを更新 → 次の判断

というループ（Agent Loop：判断と行動を繰り返すサイクル）を管理できます。

さらに、

• Contextが長くなったら整理する
• 必要ならSubagentへ仕事を渡す
• 失敗した処理から復旧する
• 長時間にわたる仕事の状態（State）を保持する

といったことも必要になります。

つまりHarnessとは、Modelを「仕事を続けられるシステム」にする部分だと考えると分かりやすくなります。

3. Agents APIを理解するための4つの基本概念

Agents APIには、まず理解しておきたい4つの基本概念があります。

• Agent
• Environment
• Session
• Events / Items

です。一つずつ見ていきます。

Agent

Agentは、どんなAIとして働かせるかを定義する部分です。

たとえば、

• どのModelを使うか
• どんなInstruction（指示文）を与えるか
• どんなToolを使えるか
• どのMCP Serverへ接続できるか

などを決めます。

料理にたとえるなら、「何を作る料理人なのか」「何を使ってよいのか」を決める部分です。

Environment

Environmentは、Agentが実際に作業する場所です。

AgentはEnvironment内で、

• Fileを読む
• Fileを書く
• Commandを実行する
• Codeを動かす
• Skillを利用する

といった仕事を行えます。

EnvironmentにはOpenAI-hostedを使うことも、自分で用意したself-hosted環境を接続することもできます。また、Agents API側にSandboxやFilesystemを持たせない場合は、Environmentなし（None）も選択できます。この場合でも、Application側のFunction ToolやRemote MCPなどを利用する構成は可能です。

Session

Sessionは、一つの仕事を継続して保持するための入れ物です。

たとえば、

「この資料を調査して」
  ↓ 調査
「この点も追加で確認して」
  ↓ 追加調査
「最後にレポートにして」
  ↓ レポート作成

という仕事を、同じSessionの中で続けられます。

Sessionの内部では、いくつかの単位が登場します。

Session
├ Turn
│  ├ Item
│  └ Item
├ Turn
│  ├ Item
│  └ Item
├ Subagent
│  └ Turn / Item
└ Artifact

ここも順番に整理します。

Turn

Turnは、Sessionの中でAgentがひとまとまりの仕事を行う単位です。

Sessionが仕事全体なら、Turnはその中の1工程だと考えると分かりやすいでしょう。

Session
├ Turn 1：調査する
├ Turn 2：追加情報を確認する
└ Turn 3：レポートを修正する

というイメージです。

Item

Itemは、AgentがTurnの中で行ったこと・生成したものを記録する単位です。

たとえば、

• Message（ユーザーとのやり取り）
• Tool Call（ツールの呼び出し）
• Toolの結果
• Command（実行したコマンド）
• Agentの出力

などがItemとして記録されます。

つまり、Agentが実際に何をしたのかを後から追える記録だと考えると分かりやすくなります。

Subagent

Subagentは、Main Agentから一部の仕事を任された別のAgentです。

たとえば、

Main Agent
├ Research Agent（調査）
├ Coding Agent（実装）
└ Review Agent（レビュー）

のように、調査・実装・レビューを分担できます。Subagent自身も独自のTurnやItemを持ちます。

Artifact

Artifactは、Agentが作ったファイル成果物を扱う仕組みです。

OpenAI-hosted Environmentでは、Agentが出力したFileを公開されたArtifactとして保持し、Environmentが終了した後でも取得できます。

たとえば、

• Report（レポート文書）
• CSV（集計データ）
• Script（作成したスクリプト）
• PDF / ZIP

などを成果物として残す場合です。

つまりSessionは単なるChat Historyではなく、

仕事全体
  ↓
Turnとして処理を重ねる
  ↓
Itemとして行動を記録する
  ↓
必要ならSubagentへ分担する
  ↓
Artifactとして成果物を残す

という、Agentの仕事全体を保持する単位です。

Events / Items

Agentが長時間動く場合、「いま何をしているのか」が見えないと困ります。

Agents APIでは、Agentの進行状況がEventとして記録されます。Streamingを利用すれば、そのEventを実行中にリアルタイムで受け取り、Agentが今どの処理を進めているかを追跡できます。また、Sessionの状態変化はWebhookで受け取ることもできます。

たとえば、

• Turnが始まった
• Itemが追加された
• Textを生成している
• Turnが完了した
• Turnが失敗した

といった状態です。

Itemが保存される仕事の記録だとすれば、Eventは仕事の進行中に起こった変化を知らせる通知と考えると分かりやすくなります。

4. OpenAIが管理する4つの仕組み

ここまで来ると、冒頭に出てきた4つの用語の意味が分かりやすくなります。

Session

先ほど説明した通り、Agentが一つの仕事を継続するための単位です。

Orchestration

Orchestrationとは、Agentの仕事全体を進行させることです。

たとえば、

Modelを呼ぶ
  ↓
Toolを使う
  ↓
結果を見る
  ↓
次のModel Call
  ↓
必要ならSubagentへ委任
  ↓
再び結果を確認

という流れを調整します。

オーケストラで指揮者が各パートを動かすように、Model・Tool・Subagentをどう動かすかを管理するため、Orchestrationと呼ばれます。

Context Compaction

Agentが長時間仕事をすると、過去の会話、Toolの結果、判断内容などが増え続けます。

（ここでいうContextとは、Agentが現在の判断に使う入力情報のことです。）

すべてをそのまま保持してModelへ渡し続けると、Contextが大きくなりすぎます。

そこで、過去情報を整理し、今後の仕事に必要な情報を残す処理が必要になります。これがContext Compactionです。

単に古い情報を捨てるのではなく、Agentが仕事を続けるために必要な情報を残しながら整理すると考えると分かりやすいでしょう。

Recovery

長時間のAgentでは、途中で問題が起こる可能性があります。

たとえば、

• Tool Callに失敗する
• Commandがエラーになる
• 一時的に処理が止まる
• Environmentとの接続に問題が起きる

といったケースです。

そのたびに仕事全体を最初からやり直していては、長時間Agentは実用になりません。

Recoveryは、途中で問題が起きても、可能な範囲で仕事を継続・復旧できるよう支える仕組みです。

この4つをまとめると、

• Session → 仕事を保持する
• Orchestration → 仕事を進める
• Context Compaction → 情報を整理する
• Recovery → 問題から復旧する

となります。この部分までOpenAI側へ任せられることが、Agents APIの重要な特徴です。

5. 普通のLLM APIと何が違う？

通常のLLM APIをかなり単純化すると、

Prompt → Model → Response

です。

一方、Agentでは、

Task → Model → Tool → 結果 → 次の判断 → 別のTool → Context更新 → 必要なら再試行 → 完了

となります。

このループ全体を管理する必要があります。

Agents APIは、Model Callより一段上にある、Agent Loop全体を扱うAPIと考えると分かりやすくなります。

6. Responses APIとは何が違う？

Responses APIも、Toolを使える強力なAPIです。

Function Calling、Web Search、File Search、Computer Use、Code Interpreter、MCPなどを組み合わせられます。

大まかには、

Responses API
  ↓
ModelとToolを使って Applicationを自分で組む

です。

一方Agents APIは、

Agents API
  ↓
OpenAI管理のAgent Harnessを利用して 長時間Agentを動かす

という位置づけです。

つまり、Responses APIはModel＋Toolを扱う基盤、Agents APIはAgentの仕事を継続させる基盤と考えると違いが見えます。

7. Agents SDKとは何が違う？

もう一つ混同しやすいのがAgents SDKです。

Agents SDKでは、Agent、Tool、Handoff（別のAgentへの処理の引き継ぎ）、Guardrail（Agentの動作を制約するルール）、Tracing（Agentの実行経路の追跡）、Sandbox（隔離された実行環境）などをApplication Code側で組み合わせます。

つまり、

• Agents SDK：自分のCodeを中心にAgent Architecture（Agentの設計構成）を組み立てる
• Agents API：OpenAI管理のAgent Harness / InfrastructureをAPIとして利用する

という違いがあります。

どちらが上位という話ではありません。Agentの実行やOrchestrationを、どこまで自分で持つかの違いです。

8. なぜAgents APIが必要になったのか

Agentの仕事は、一回のModel Callよりはるかに長くなる可能性があります。

たとえば、

Task開始
  ↓
調査
  ↓
Subagentへ仕事を分担
  ↓
File生成
  ↓
Code実行
  ↓
失敗
  ↓
再試行
  ↓
数時間後に完了

ということが起こります。

これを安定して動かすには、

• State（状態管理）
• Context（文脈）
• Session（仕事単位）
• Environment（実行環境）
• Retry（再試行）
• Recovery（復旧）
• Storage（保存領域）

などが必要になります。

つまりAgent時代では、Modelの性能だけでなく、Modelを働かせ続ける実行基盤（Infrastructure）が重要になります。

Agents APIは、その部分をAPIとして提供するものだと考えると理解しやすくなります。

9. Codexとは何が違う？

Agents APIはCodexと深く関係しています。

しかし、Agents API = Codex ではありません。

Codexは、Software Developmentという用途があらかじめ設定されたCoding Agentです。

一方Agents APIは、開発者が自分のAgentを作るための基盤です。

整理すると、

Codex
  ↓
完成されたCoding Agentを使う

Agents API
  ↓
Agent Infrastructureを使って 独自Agentを作る

となります。

10. Claude CodeなどのCoding Agentとは何が違う？

Claude Code、Codex、Antigravityなどは、Software Developmentを進めることに特化したAgentです。

すでに、

• Fileを読む
• Codeを書く
• Commandを実行する
• Testする
• 結果を確認する

といった仕事ができるよう設計されています。

一方Agents APIでは、Customer Support、Research、Data Analysis、Operationsなど、Agentの用途そのものを開発者が決めます。

つまり、

• Coding Agent = 用途が決まっているAgent製品
• Agents API = 任意のAgentを作るためのPlatform

です。

11. MCPとは何が違う？

MCP（Model Context Protocol）は、外部Systemが持つToolやDataをAgentへ接続するための共通Protocolです。

Agents APIは、Agentそのものを実行・管理するためのInfrastructureです。

したがって競合ではありません。

Agents API
  ↓
Agent
  ↓
MCP
  ↓
External Tool / System

という関係になります。

Agentを動かす仕組みと、Agentを外部世界へつなぐ仕組み。役割が違います。

MCPそのものの詳細については、「MCPは学ぶべき？AIエージェント時代に必要なAPI・Git・CLIとの違い」で詳しく整理しています。

12. Function Callingとは何が違う？

Function Callingは、ModelからApplication側のFunction（関数）を呼び出す仕組みです。

つまりToolを使うための仕組みの一つです。

Agents APIでは、

Agent
  ↓ Tool
  ├ Function Calling
  ├ MCP
  └ Built-in Tool

のように、複数のToolを使いながら仕事全体を進めます。

Function Callingは「Toolを呼ぶ仕組み」。Agents APIは「そのToolを使いながら仕事を続ける仕組み」。という違いです。

13. Subagentとは？

一つのAgentにすべての仕事をさせず、一部を別のAgentへ渡すことがあります。それがSubagentです。

Main Agent
  ├ Research Agent
  ├ Coding Agent
  └ Review Agent

のような構成です。

ただし、「Agentを増やせば無条件に性能が上がる」という意味ではありません。

Agent間の調整や状態共有も必要になります。仕事を独立して分割する明確な意味がある場合に使うべきです。

詳しくは、シリーズ第4回「Single vs Multi-Agentの違い」で整理します。

14. Sessionが重要なのはなぜ？

Agents APIでは、SessionがAgent実行の中心になります。

一回の回答ではなく、一つの仕事を継続する単位だからです。

Sessionには、Turn、Item、Subagent、Artifactなどが紐づきます。

そのため、

調査する
  ↓
追加指示
  ↓
再調査する
  ↓
Fileを作る
  ↓
修正する

という長い仕事を、同じSessionの中で続けられます。

Session / Context / Memoryの違いについては、シリーズ第5回「Agentの「状態」とMemory設計」で詳しく整理します。

15. Context CompactionとRecoveryが重要な理由

長時間Agentでは、時間が経つほどContextが増えます。また、途中で失敗する可能性もあります。

そのため、

Context Compaction
  ↓
必要な情報を残しながら Contextを整理する

Recovery
  ↓
途中で問題が起きても 仕事を継続できるようにする

という仕組みが重要になります。

これは、短いやり取りのChatbotではそれほど意識しなかった、AIを長時間働かせ続けるための設計です。

16. Sandboxとは？

AgentがCodeやFileを扱う場合、どこでその処理を実行するのかも重要になります。

ここでいうSandboxとは、外部システムやホストOSから実行範囲を隔離した実行環境のことです。

Agents APIではOpenAI-hosted sandboxを利用できます。

Sandbox内で、

• Fileを作る
• Fileを編集する
• Scriptを実行する

といった処理ができます。

ただし、「Sandboxがある＝完全に安全」ではありません。

• 何のToolを許可するか
• どのPermission（権限）を与えるか
• 何をSandbox内だけに制限するか
• どこでHuman Approval（人間の承認）を入れるか
• 何をLogging（実行記録の保存）するか

まで含めて安全性を設計する必要があります。

詳しくは、シリーズ第6回「AgentのSandboxと安全設計」で整理します。

17. Agents APIはCloud Agentなのか？

Agents APIのHarnessはOpenAI側で管理されます。

しかし、AgentがCodeやFileを扱う場所まで、必ずOpenAI Cloudとは限りません。

大きく、

OpenAI managed
  ├ Agent Harness
  ├ Session
  ├ Orchestration
  ├ Context Compaction
  └ Recovery

Execution Environment
  ├ OpenAI-hosted（クラウド隔離環境）
  ├ Self-hosted（自社サーバー・ローカル環境）
  └ None（作業場所なし）

と分けて考える必要があります。

たとえば、

Agent Harness → OpenAI Cloud
Tool / File操作 → Local System

というHybrid（CloudとLocalを組み合わせる構成）も可能です。またself-hosted Environmentを接続する構成も選べます。

詳しくは、シリーズ第8回「Local vs Cloud Agentの使い分け」で整理します。

18. Agents APIがあればAgent設計は不要になる？

むしろ逆です。

InfrastructureをOpenAIへ任せられるからこそ、開発者は、「Agentに何をさせるのか」という設計へ集中することになります。

たとえば、

• どのToolを与えるか
• Instructionをどうするか
• Single AgentにするかMulti-Agentにするか
• Stateを何として保持するか
• どこでHuman Approvalを入れるか
• 何をEval（評価）するか

は、Agents APIが自動的に決めてくれるものではありません。

（ここでいうEvalとは、Agentが意図通りの成果を出しているかを測定・テストする評価設計のことです。）

つまり、Agent PlatformとAgent Designは別物です。

19. Agents APIを学ぶ前に知っておきたいこと

Agents APIのMethodを暗記する前に、

Goal → Agent → Tool → State → Environment → Execution → Evaluation

という基本構造を理解しておく方が重要です。

CORE SPECでは、それぞれを次のシリーズ記事で体系的に整理しています。

• #02 AIエージェントとは？設計の基本
• #03 AIエージェントのToolとは？Function Calling・MCPとの違い
• #04 Single vs Multi-Agentの違い
• #05 Agentの「状態」とMemory設計
• #06 AgentのSandboxと安全設計
• #07 AIエージェントのEvalとテスト設計
• #08 Local vs Cloud Agentの使い分け

製品名やAPI仕様が変わっても、この基本構造は普遍的に残ります。

20. Agents APIはAgentの「完成形」ではない

Agents APIはOpenAIの実装です。Agentという概念そのものではありません。

Google、Anthropic、Open Source Frameworkなどには、別のAgent Architectureがあります。

また、2026年9月23日時点でAgents APIはPublic Betaです。

そのため、「APIのMethod名だけを覚える」よりも、

• なぜSessionが必要なのか
• なぜContextを整理する必要があるのか
• なぜToolやSandboxを分離するのか

を理解する方が長く役に立ちます。

21. Agents APIが示している大きな変化

これまでAI APIでは、

AIに入力する
  ↓
答えを受け取る

という考え方が中心でした。

Agentでは、

仕事を渡す
  ↓
Agentが継続して処理する
  ↓
必要ならToolやSubagentを使う
  ↓
成果物を受け取る

へ変わります。

つまり設計対象が、「AIに何を質問するか」から、「仕事のどこまでをAIへ任せるか」へ移っています。

ここがAgents APIを見るうえで最も重要なポイントです。

22. 「任せられる」と「任せるべき」は違う

Agents APIを使えば、多くの処理をAgentへ任せられます。

しかし、技術的に自動化できることと、自動化すべきことは同じではありません。

たとえば、

• 検索 → 自動
• File Read → 自動
• Production Deploy（本番環境へのデプロイ） → Human Approval（人間の承認必須）

という設計もできます。

Agent Designで重要なのは、どこまでAIへ判断を委任し、どこから人間が責任を持つかです。

まとめ

OpenAI Agents APIとは、

Codexを支えるAgent Harnessと、長時間Agentを動かすためのManaged Infrastructureを、開発者がAPIとして利用できる仕組み

です。

重要な違いを整理すると、以下のようになります。

そして、最も重要なのは、

Agents APIそのものを覚えることではなく、その裏側にあるAgent設計を理解すること

です。

Agents APIは、AI開発が、

Modelを呼ぶ

だけの世界から、

仕事を継続的に任せる

世界へ移りつつあることを、分かりやすく示しています。