OpenAIのAgent APIとは何がすごいのか　業務自動化が変わる理由

この記事のまとめ

OpenAIのAgent API（Agents API）は、Codexを動かしているハーネスを、OpenAIが管理する形で開発者に届ける仕組みです。オーケストレーションや長時間セッション、コンテキスト管理をOpenAI側が引き受けるので、開発者は自社ならではの部分に集中できます。ここでは4つのポイントで要点を整理します。

提供はパブリックベータで、すべての開発者が利用できます。Agents API自体に追加料金はなく、エージェントが使ったトークンとツールの分を支払います。
中核機能として、コンテキストの自動圧縮、ツール検索とプログラム的ツール呼び出し、サブエージェントの並列実行が組み込みで使えます。
実行環境は、OpenAIホスト型サンドボックス、セルフホスト、パートナーの環境から選べ、環境を使わない構成もあります。
運用面では、トレースで実行内容を確認できます。データ所在は米国のみで、Zero Data Retentionには対応していません。

Agent APIの基本と提供範囲

エージェントとAgent APIの関係

まずは、エージェントという言葉の意味と、Agent APIがどんな部品でできているのかを見ていきます。「エージェント」という言葉は最近あちこちで使われていますが、定義が揺れているため、OpenAIがどう整理しているかを最初に押さえておくと理解が早いです。

エージェントは、ユーザーに代わって仕事を進めるシステムです。OpenAIの実践ガイドは、従来のソフトウェアがユーザー自身によるワークフローの効率化や自動化を助けるものだと整理しました。

一方でエージェントは、高い自律性をもって、ユーザーに代わって同じワークフローを実行できるとの整理です。同ガイドはエージェントを、ユーザーに代わってタスクを自律的に達成するシステムと定義しました（参照*1）。

Agent APIは、4つの概念で組み立てられています。公式ドキュメントによると、1つ目のエージェントは、モデル、指示、ツール、そのエージェントが使えるMCPサーバーを指します。2つ目の環境は、エージェントがファイルにアクセスし、スキルを読み込み、コマンドを実行する、省略できるサンドボックスやコンピューターです。

3つ目のセッションは、タスクに取り組み、入力に応答する、長く保たれるエージェントの実体です。4つ目のイベントとアイテムは、エージェントに送る入力と、セッション中に生まれる出力を指します（参照*2）。

OpenAIが担う範囲と単一API呼び出し

OpenAIがどこまで引き受けるのかは、Agent APIの実務的な意義を理解するうえで重要な部分です。

Agents APIは、Codexを支えるハーネスとインフラを、シンプルで柔軟なAPIとして開発者に届けるものです。OpenAIは、Codexを動かしているのと同じハーネスとインフラを開発者に提供するAgents APIを、パブリックベータで発表しました（参照*3）。

OpenAIの案内では、オーケストレーション、長時間実行されるセッション、コンテキスト管理はOpenAIが担当し、開発者はエージェント独自の特徴に集中できるとしています（参照*4）。

作り始め方も、まとまった1回の呼び出しから始められる形です。OpenAIは、タスク、モデル、ツール、環境を指定することで、本番対応のエージェントを単一のAPI呼び出しで作成できると説明しました。ハーネスはOpenAIが運用と保守を担い、エージェントの計算環境は、OpenAI管理のサンドボックス、自社のインフラ、サンドボックスパートナーのいずれかから開発者が選びます（参照*3）。

この「インフラをOpenAIが持つ」という設計は、開発者にとって大きな意味を持ちます。従来、エージェントを自前で組もうとすると、コンテキスト管理やオーケストレーション、サンドボックスの準備といった「エージェントを動かすための仕組み」を自分で実装する必要がありました。そこに多くの工数が取られ、本来作りたい機能に手が回らないという状況が生まれやすい。Agent APIはその部分をOpenAI側に移し、開発者が「何を作るか」に集中できる構造に変えようとしています。

パブリックベータと料金体系

使い始める条件と、料金の考え方も押さえておきます。

Agent APIは、すべての開発者がパブリックベータで利用できます。OpenAIのコミュニティ投稿によると、Agents APIの使用に追加料金はかかりません。

支払うのは、料金ページで説明されているとおり、エージェントが使用したトークンとツールの料金だけです（参照*4）。費用は、エージェントが実際に使った分に応じて決まります。

あわせて、ベータという段階の意味も確認しておきたいところです。OpenAIは、一般提供へ向けて、パブリックベータの期間は利用者からのフィードバックをもとに素早く改善を重ねるとしました（参照*3）。つまり、今の仕様は改善が続いている途中の段階です。仕様変更が起きる前提で、本番利用の設計を組むことが求められます。

業務自動化を変える中核機能

長時間セッションとコンテキスト管理

長い時間の作業をどう支えるのかは、業務自動化を考えるうえで最初に気になる部分です。「途中でコンテキストが切れる」問題は、エージェントを実務に使おうとしたときに最初にぶつかる壁の一つです。

Agent APIには、長いセッションをまたいで必要な情報を運ぶためのコンテキスト管理が組み込まれています。OpenAIは、モデルが数時間にわたって作業できるように、コンテキスト管理を作ったと説明しました。

セッションがコンテキストの上限に近づくと、Agents APIが以前のコンテキストを自動的に圧縮し、エージェントの作業継続に必要な情報を残す仕組みです。開発者は、自前の圧縮処理を実装しなくても、複数のコンテキストウィンドウにまたがるワークフローを組み立てられます（参照*3）。

セッションの状態そのものも保たれます。公式ドキュメントによると、Agents APIはセッションの状態を保持するため、ターンをまたいで作業を続けるときに会話のコンテキストを作り直す必要がありません。必要がなくなったセッションや公開した成果物は、削除できます（参照*2）。

ツール検索とプログラム的ツール呼び出し

ツールの扱い方にも、Agent APIならではの仕組みがあります。

ツール検索は、必要なツールの定義をそのつど読み込みます。OpenAIの説明では、ツール検索は関連するツール定義を必要に応じて読み込み、モデルのキャッシュを保ちながら、トークン使用量とコストを抑えるのに役立ちます（参照*3）。

プログラム的ツール呼び出しは、コードの中でツールの結果を扱えるようにします。OpenAIによると、ツールが使える状態になれば、エージェントは呼び出しを並列で実行し、関連する操作をつなげ、コードの中で結果を絞り込んだり組み合わせたりできます。

これにより、大量のデータを処理しながら、関係する結果だけをコンテキストに戻せるとの説明です。Agents APIは、MCP、カスタム関数、そしてWeb検索のような組み込みツールに対応します（参照*3）。

サブエージェントによる並列実行

複雑な作業は、分けて同時に進めるという考え方も使えます。

マルチエージェント対応により、Agent APIはタスクを分けてサブエージェントに任せられます。OpenAIによると、Agents APIは複雑なタスクを独立した部分に分け、並列で動くサブエージェントに委任します。各サブエージェントは自分のコンテキストを保ち、担当する仕事に集中しやすくなります。

メインのエージェントは、それぞれの作業を調整して結果をまとめる役割です。OpenAIは、自前のオーケストレーションを作らなくても、並列作業が向いているリサーチ、分析、コーディングのタスクを速められるとしています（参照*3）。

導入した企業からは、具体的な数字も示されています。CiridaeのCTOであるJack Weissenberger氏は、Agents APIによって自社の評価スコアが0.71から0.85になったと述べました。

同氏は、APIのサブエージェント対応がワークフローを大幅に速めたとし、以前の構成では手間がかかっていたサブエージェントの観察と調整について、新しいAPIで4倍のレイテンシー削減が得られたと語りました（参照*3）。これは同社による自社評価です。

エージェントの実行環境の選択肢

OpenAIホスト型サンドボックス

エージェントがコードを動かす場所は、目的に合わせて選べます。

OpenAIホスト型サンドボックスは、OpenAIが用意して管理する実行環境です。OpenAIは、素早く始めて効率よく広げたい開発者向けにOpenAI hosted sandboxを提供し、CodexとChatGPTを支えるのと同じサンドボックス基盤を使うと説明しました。OpenAIがサンドボックスのプロビジョニングと管理を行い、エージェントはコードの実行、ファイルの操作、成果物の作成ができます（参照*3）。

使い方は、環境の設定で切り替えます。公式ドキュメントでは、エージェントがスクリプトを実行したり、ファイルを編集したり、成果物を作ったりする必要がある場合に、environment.typeをopenai_hostedに設定するとしています。

このとき、OpenAIがセッション用のサンドボックスを作成し、管理する仕組みです。一方、質問に答えたり、ツールで外部サービスにアクセスしたりするエージェントは、独自の計算資源やファイルを必要としない場合があり、environment.typeをnoneに設定します（参照*5）。

環境は、エージェントがファイルにアクセスし、スキルを読み込み、コマンドを実行する場所で、省略できる位置づけです（参照*2）。

セルフホストとパートナー統合

自社の環境を使う道も、外部のプロバイダーにつなぐ道もあります。

セルフホストは、自社のインフラやプライベートネットワークを使う構成です。公式ドキュメントによると、エージェントに自分のインフラストラクチャ、プライベートネットワーク、またはカスタムソフトウェアが必要な場合は、environment.typeにself_hostedを使います。

この構成では、プロビジョニング、再接続、シャットダウン、保持する必要があるファイルはアプリケーションの管理対象です。その管理は、アプリケーションサーバーやWebhookハンドラーが担えます（参照*5）。

サンドボックスは、自前で用意しても、プロバイダーに接続してもかまいません。OpenAI Devsの投稿では、CPU、GPU、メモリの選択肢、フルマネージドの環境や自社VPC内へのデプロイ、ファイルとシークレットの保存方法といった条件から、作業に合う環境を選べるとしています（参照*6）。

OpenAIは、Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercelを含むエコシステムのプロバイダーと連携し、さまざまな用途に向けた統合を提供するとしました（参照*3）。

具体例として、Cloudflare Containersを使う構成があります。Cloudflareの更新情報によると、Cloudflare ContainersはOpenAI Agents API向けにセルフホスト型の実行環境を提供できるようになり、オープンソースのOpenAI Agents API Workersテンプレートがリファレンス実装を提供します。WorkerはCodexセッションごとにCloudflare Containerを維持し、進行中の作業を継続し、フォローアップの入力があれば再接続し、アイドル状態になると自動的にシャットダウンします（参照*7）。

運用で押さえる制約と安全策

トレースによる実行の可視化

エージェントが実際に何をしたのかを、後から確認する仕組みも用意されています。

トレースを使うと、実行の中身をステップごとに追えます。公式ドキュメントによると、トレースダッシュボードには、各ステップの記録された入力、出力、所要時間、ステータスなど、エージェントが実行した内容が表示されます。

新しいセッションでは、トレースが既定で有効になっています。ただし、パブリックベータのAPIでは、トレース設定や外部トレースエクスポーターは公開されていません（参照*8）。

表示されるトークン使用量には、読み方の条件があります。同ドキュメントは、使用量がターンの終了後に届くことがあるとしています。

空白の値やnullは数が不明であり、エージェントがトークンをまったく使用しなかったことを示すものではないという意味です。利用できる使用量が増えると数値は変わることがあり、最終的な請求額ではありません（参照*8）。

セッション管理とデータの扱い

セッションの持ち方と、データの置かれる場所も運用では効いてきます。

セッションIDは、アプリケーション側で保存して使います。公式ドキュメントは、各セッションIDをアプリケーションのデータストアに保存し、セッションの現在の状態を取得したり、エージェントからのリクエストを処理したり、セッションを削除したりするために使うとしています。

アプリケーションで不要になったセッションは削除でき、削除するとセッションはAPIから取り除かれる仕組みです。物理的な削除は、非同期に続く場合があります（参照*9）。

データの所在には制約があります。Agents APIは現在、米国でのみデータ所在に対応し、Zero Data Retention（ZDR）は非対応です。セルフホストのサンドボックスを選んでも、Agents APIがZDRの対象になるわけではありません（参照*2）。

ガードレールと人の介在

安全に動かす設計は、エージェント構築全般をまとめたOpenAIの実践ガイドが参考になります。

ガードレールは、層として重ねる防御と位置づけられています。同ガイドは、ガードレールを層状の防御メカニズムと考えるように示しました。1つだけでは十分な保護を提供できない可能性があり、複数の専門的なガードレールを組み合わせることで、より回復力のあるエージェントを作れるとしています（参照*1）。

人が引き継ぐ場面も、あらかじめ決めておく形です。同ガイドは、人間の介入が必要になる主なトリガーを2つ挙げました。1つ目は失敗のしきい値を超えた場合で、エージェントの再試行やアクションに上限を設け、たとえば複数回試しても顧客の意図を理解できないときに人間の介入へエスカレーションします。

2つ目は高リスクのアクションで、機密性が高い、取り消せない、または重大な影響を伴う操作では、エージェントの信頼性に対する確信が高まるまで人間による監督をトリガーする形です。例として、ユーザーの注文のキャンセル、高額な返金の承認、支払いの実行が挙げられています（参照*1）。

実務での活かし方と展望

エージェント化に向くワークフロー

どんな業務がエージェント化に向くのか、判断の軸が示されています。

OpenAIの実践ガイドは、従来の方法で問題が生じ、これまで自動化に抵抗してきたワークフローを特に優先するようすすめています。1つ目の軸は複雑なワークフローで、微妙な判断、例外、意思決定を伴うものです。例として、顧客サービスのワークフローにおける返金承認が挙げられています。

2つ目の軸は保守が難しいシステムで、広範なルールによって扱いにくくなったものです。複雑なルールセットは、更新にコストがかかり、エラーも起きやすくなります。こちらの例は、ベンダーのセキュリティレビューの実施です（参照*1）。

3つ目の軸は、非構造化データへの依存です。同ガイドは、自然言語の解釈、文書からの意味の抽出、ユーザーとの会話によるやり取りを伴うシナリオを挙げ、例として住宅保険の請求処理を示しました。

そのうえで、エージェントの構築を決める前に、ユースケースがこれらの基準を明確に満たせるか検証するよう求めています。満たさない場合は、決定論的なソリューションで十分かもしれないとしています（参照*1）。

ハーネスの品質が成果を分ける理由

モデルの性能だけで、エージェントの出来が決まるわけではないという整理があります。この点は、生成AIを業務に導入するときに見落とされがちな論点です。「どのモデルを使うか」の議論ばかりになりがちですが、実際には「どう動かすか」の設計が成果を左右します。

ハーネスは、エージェントの動きを決める運用の層です。研究論文は、ハーネスをエージェントが何を観察し、記憶し、計画し、呼び出し、検証し、実行するかを決める運用層と位置づけました。そのため、能力はモデルの重みだけでなく、モデルとハーネスの組み合わせの特性だと整理しています（参照*10）。

評価でも、ハーネスの違いが差を生んだ結果が報告されています。金融のエンドツーエンドなスプレッドシート課題を扱う評価では、同じ基盤モデルを固定した場合、独自ハーネス上のAPIエージェントよりも、独自ハーネス上のGUIおよびCODEエージェントの方が大幅に優れました。論文によれば、これはハーネスの品質が性能差の大部分を生み出していることを示す結果です。

一方で、タスクの難易度が上がるとエージェントの性能は低下し、レベル4のタスクでは最も高いエージェントでも100点満点中72.6点で、レベル2の92.4点から下がりました。最も強力なエージェントでさえ、経験豊富なモデル作成者に期待される専門基準を安定して達成できていないと報告しています（参照*11）。

この結果は、エージェントを実務に投入する際の過信を戒める意味で重要です。私が企業へのAI導入を支援する中でも、「エージェントに任せたら後は自動で動く」という期待が強い場面をよく見かけます。しかし、難易度の高いタスクでは人間の確認工程が不可欠で、エラーが起きたときの監査可能性をどう設計するかが実務上の本題になります。

OpenAIは、そのハーネスを自ら維持し、改善していくとしています。OpenAIの説明では、Agents APIはモデルのリリースごとに、バージョン管理された形でこれらの機能へのアクセスを提供します。

モデルと並行してハーネスを保守し、継続的に改善することで、アップグレードのたびにエージェントがより高い性能を得られるよう手助けするとの説明です。Agents APIはオープンソースのCodexハーネスで動いており、開発者はモデル呼び出しやツール、コンテキストを調整する中核ロジックを確認し、その公開コードベースから学べます（参照*3）。

おわりに

Agent APIが変えるのは、開発者が手をかける場所です。オーケストレーション、長時間実行されるセッション、コンテキスト管理はOpenAIが担当し、開発者はエージェント独自の特徴に集中できるとOpenAIは案内しています（参照*4）。逆に言えば、「何を作るか」の定義が曖昧なまま導入しても、便利な実験で終わるリスクがあります。目的、成果物の形、品質基準、確認工程を先に整理してからAPIを触り始めるほうが、実務への定着は早いと考えています。

提供はパブリックベータの段階で、OpenAIは一般提供に向けてフィードバックをもとに改善を重ねるとしました（参照*3）。実行環境の選び方、トレースでの確認、セッションとデータの扱いは、運用設計として合わせて見ておく項目です。特にデータ所在が米国のみでZDR非対応という制約は、企業が実装を判断するうえで見落とせない条件です。仕様が変わる前提で、今の段階で何を検証しておくかを決めておくことが重要です。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））