Agents APIとは｜OpenAIに預ける範囲の決め方

「AIエージェントの実行基盤を、自社で持つべきか、OpenAIに預けるべきか」——Agents APIの発表を見て、まずこの線引きで迷った方は多いはずです。

結論から言うと、Agents APIはエージェントを動かし続ける面倒（セッション管理・文脈の圧縮・中断からの復帰）をOpenAIが引き受ける代わりに、データの置き場所・請求の内訳・実行の記録という3つを手放す仕組みです。決めるべきはモデルではなく、どこまで預けてどこを手元に残すかです。

株式会社Fyveは中小企業のAI活用を月額で伴走しており、私たち自身も常時起動のMac miniで無人のAIジョブを毎日回しています。この記事では公式ドキュメントで確認した仕様と、自分で無人運用をしてきた経験の両方から、Agents APIを導入判断の目線で整理します。

Agents APIとは｜3行で言うと

Agents APIは、OpenAIが2026年9月10日にパブリックベータとして公開したエージェント構築用のAPIです。公式の変更履歴には「managed Codex harness（OpenAIが運用するCodexの実行機構）でエージェントを構築でき、セッションのオーケストレーション・コンテキストの圧縮・復旧はOpenAIが担う」と記載されています。

要点を3行にすると次のとおりです。

• OpenAIがエージェントの「実行係」を預かる。モデル呼び出しとツール呼び出しのループ、セッションの保持、文脈があふれたときの要約を、自分で書かなくてよくなります
• 作業場所（サンドボックス）は3択。OpenAI側に用意させる／自社インフラを繋ぐ／作業場所を持たない、から選びます
• ベータであり、制約が明示されている。データの保存場所は米国のみ、ゼロデータ保持（ZDR）は非対応、実行トレースの外部持ち出しはベータAPIの範囲外です

「AIエージェントのフレームワークがまた1つ増えた」と読むと本質を外します。これは実行環境の所有権をどちらが持つかという話で、選択の重さはフレームワーク選定よりも、サーバーを自社で持つかクラウドに置くかという判断に近いものです。

まず決めるのは「どのランタイムを使うか」

OpenAIは公式のAgentsガイドで、エージェントを動かす選択肢を3つ並べ、比較表を載せています。ここを読み飛ばすと、後から移行コストの高い選択をしてしまいます。

公式の説明を私の言葉に置き換えると、判断基準はこうなります。

• 数十分〜数時間かかる作業を、途中経過ごと預けたい → Agents API
• 実行の制御・保存先・承認フローを自分の手元に置きたい → Agents SDK
• 1回のやりとりで終わる処理を安く確実に回したい → Responses API

なお、managed harnessが提供する機能として公式が挙げているのは、サンドボックス内でのコマンド・コード実行、スキルと指示の適用、ツールやMCP経由の外部データ接続、作業中のエージェントへの軌道修正、文脈ウィンドウ管理のための過去作業の要約、サブタスクへの分解とサブエージェントへの委譲、中断したセッションの再開です。

このうち「過去作業の要約」と「中断からの再開」は、自前で作ると地味に重い部分です。私も無人ジョブで長時間の処理を回していますが、文脈があふれたときに何を捨てて何を残すかの判断は、正解が業務ごとに違うため作り込みが効きません。ここを預けられるのは実務上ありがたい一方、要約で何が落ちたかは自分からは見えなくなることも同時に受け入れることになります。

環境（environment）の3択が設計の本体

Agents APIの設計判断が集中するのは、モデル選択ではなくenvironment.typeです。公式のアーキテクチャ解説では、構成要素を「Harness（OpenAIがホストする実行機構）」「Environment（コマンドやファイル操作を行う場所）」「Application server（自社のコード）」の3つに分けています。

none｜作業場所を持たない

質問に答える、外部サービスをツール経由で叩く、といった用途なら計算資源もファイルも不要です。その場合はenvironment.typeをnoneにします。

ただし公式は明確に制約を書いています。環境を持たない場合、組み込みのBashツールとapply-patchツール、ワークスペース上のファイル、executor経由のMCPは使えません。リモートのMCPツールはharnessが直接呼べますが、関数ツール（function tools）は自社コードが呼び出しを受けて実行し、結果を返す形になります。

openai_hosted｜OpenAIにサンドボックスを用意させる

スクリプトを走らせる、ファイルを編集する、成果物を作る、といった作業が必要ならこちらです。パッケージ・ファイル・ネットワークアクセスを指定すると、OpenAIがセッション用のサンドボックスを作って管理します。

self_hosted｜自社インフラを繋ぐ

自社のネットワーク内やカスタムのソフトウェアが必要な場合はこちらです。ただし公式は責任範囲をはっきり書いています。プロビジョニング・再接続・シャットダウン・残したいファイルの保全は、すべて自社の責任です。

そしてここが誤解されやすいところですが、自社サンドボックスを選んでもZDR（ゼロデータ保持）の対象にはなりません。この点は後述します。

ネットワークは3モード｜restrictedの書き方に癖がある

OpenAIホスト環境ではnetwork.accessを3つから選べます。

• enabled：外向き通信を許可。テンプレートのポリシーを継承しない限り、これが既定値です
• disabled：外向き通信を遮断
• restricted：allowed_domainsに列挙したホストのみ許可

restrictedは1〜100個の正確なホスト名を受け付けますが、公式は書き方の制約を細かく指定しています。ワイルドカード・プロトコル・パス・ポートは書けません。サブドメインとリダイレクト先はそれぞれ個別に登録が必要です。また、stdio方式のホスト型MCPサーバーを使う場合はenabledが必要とされています。

既定がenabledである点は、実務では最初に潰すべき設定です。私は自社の無人ジョブでも、外に出る必要がない処理はそもそも外へ出られない状態にしています。「出さない」より「出られない」ほうが、事故率は構造的に下がります。

サンドボックスは1時間で消える

運用設計に直結する仕様があります。接続中のサンドボックスにはキープアライブが送られますが、活動とキープアライブが1時間止まるとサンドボックスは削除され得ます。このタイムアウトは設定変更できません。

ファイルの扱いも押さえておく必要があります。セッションごとに別のワークスペースが用意され、サンドボックスが存在する間はターンをまたいでファイルが残ります。そして/workspace/outputs配下のファイルは、ターン完了時に変更不可の成果物（immutable artifacts）として公開され、サンドボックスが消えた後もダウンロードできます。

つまり残したいものは明示的に/workspace/outputsへ置くのが作法です。ここを知らずに作業ディレクトリ直下で成果物を作ると、1時間の空白で消えます。

料金｜「追加料金なし」は半分だけ正しい

発表を扱った記事では「追加料金なし、使ったトークンとツールの分だけ」と要約されがちです。公式ドキュメントに当たると、もう少し正確な姿が見えます。

3つの課金が重なる

Agents APIの概要ページには、課金が3系統あると書かれています。

• モデル利用：選んだモデルのAPI料金
• OpenAI製ツール：各ツールの標準料金
• OpenAIホストのサンドボックス：標準のコンテナ料金

「Agents APIという名目の追加料金はない」は正しい一方、サンドボックスを使えばコンテナ課金が乗ります。ここを見落とすと見積もりがずれます。

コンテナ料金の実額

公式の価格ページには、Hosted ShellとCode Interpreterを含むコンテナ料金として次の記載があります（2026年9月12日時点で私が確認した内容です）。

単位はコンテナ1つあたり20分のセッションです。ここでのGBはバイナリギガバイト（1 GB＝2の30乗バイト）と注記されています。あわせて「対象となるコンテナセッションは分単位で課金され、1セッションあたり5分が最低課金」とも書かれています。

数字が小さいので軽く見えますが、効いてくるのは同時実行数です。1コンテナ20分あたり0.12ドル（4 GB）でも、10本のセッションを8時間走らせれば計算は変わってきます。エージェントの見積もりは「1回いくら」ではなく「同時に何本、何分」で立てるべきだ、というのが料金表から読み取れる設計思想です。

usageは請求書ではない

ここがこの記事でいちばんお伝えしたい部分です。Agents APIはusageフィールドでトークン消費を返しますが、公式は次のように明記しています。

• usageはベストエフォート。不明なときはnullになり得る
• 記録された値は会計情報が届くにつれて変わり得る
• usageが無いことは、消費がゼロであることを意味しない
• これらのカウントは最終的な請求ではない

さらに踏み込んだ記述もあります。キャッシュ書き込みの料金が適用されるモデルについて、Agents APIのusageフィールドはキャッシュ書き込み数を別建てで出さないため、正確なモデル課金額を判定できないと公式が認めています。

もう1つ、コスト管理で誤解されやすい点にも釘が刺されています。「キャッシュ入力の比率が高いことは、タスク全体のコスト削減を意味しない」。キャッシュされた入力も課金対象であり、呼び出しを繰り返せば長い履歴を毎回処理することになるためです。

実務的な意味はシンプルです。Agents APIのコストは、APIのレスポンスからは確定できません。管理画面の請求と突き合わせる運用を前提に置く必要があります。

預ける前に確認したい3つの落とし穴

①ZDR非対応・データの置き場所は米国のみ

公式の概要ページの末尾に、重要な注記があります。Agents APIは現時点でデータレジデンシーが米国のみに対応し、ZDR（Zero Data Retention、ゼロデータ保持）には対応していません。そして自社ホストのサンドボックスを選んでもZDR対象にはなりません。

セッションの状態は保持され、ターンをまたいで会話文脈を組み直さずに作業を続けられます。不要になればセッションと公開済みの成果物は削除できますが、「そもそも保持しない」という選択肢が現時点では無いということです。

これは中小企業の導入判断で効きます。社内規程や取引先との契約で「データは国内保管」「AIベンダー側にデータを残さない」と約束している場合、サンドボックスを自社に持ってきても条件を満たせません。自社インフラを繋げば国内に閉じる、という直感は通用しない設計です。

②事前にも事後にも金額が確定しにくい

前述のとおり、モデル・ツール・コンテナの3系統が重なり、usageは最終請求ではありません。加えて公式は、ルートのエージェントだけでなくサブエージェントの作業とリトライ、さらにツール・サンドボックスの計算資源・サードパーティのサービス料金も勘定に入れるよう求めています。

エージェントは1つのタスクを終えるまでに複数回モデルを呼びます。見積もりは1回の呼び出しではなく、タスク完了までの全呼び出しで立てる——これが公式の指示です。

③実行トレースを自社の監視基盤へ持ち出せない

可観測性のページには、見落としやすい制約が1行で書かれています。トレースの取得（trace retrieval）と外部のトレースエクスポーターは、パブリックベータのAPIには含まれていません。

セッションのイベントストリームやターンごとのusageはAPIで取れます。一方、記録されたモデル応答・ツール呼び出し・サブエージェントの活動を詳しく追うトレースは、OpenAIのダッシュボード上で見る形になります。

自社の監視基盤に集約して、異常を機械的に検知したい場合は、現時点では自前でイベントを拾って記録する設計が必要です。エージェントの監視をどう組むかは、それ自体が独立した設計課題です。

AI業務効率化AIエージェントの監視設計｜OpenAIが見逃した1週間

私が無人でエージェントを回して学んだこと

ここからは公式ドキュメントではなく、自分の運用から得た話です。私は常時起動のMac miniで、情報収集・下書き生成・通知といった無人ジョブを10種類ほど登録し、1日9〜10本のペースで走らせています。エージェントを「預ける」判断をするうえで、実際に効いた観点を3つ挙げます。

境界は文章ではなく、鍵の粒度で作る

無人で動くものに対して「ここは触らないこと」と指示文に書いても、境界にはなりません。私が実際に採った方法は2つです。

• 鍵の権限そのものを削る。運用中のCMSに渡している鍵は取得・作成・更新の権限のみで、削除は禁止されています。指示ではなく権限として不可能にしてあるので、記事が消えるという事故は構造的に起こりません
• 書き込み先をシェル側で固定する。ジョブの成果物を保存する先を1つのフォルダに限定し、そこ以外への書き込みは記録せず破棄したうえで、通知チャンネルに警告として名指しで流しています

Agents APIに置き換えると、これはnetwork.accessとAPIキーのスコープの話になります。公式のクイックスタートは、セッション操作にapi.agents.readとapi.agents.write、モデル推論にapi.responses.writeを付与するよう案内したうえで、「このキーはエージェントのサンドボックスの外に置くこと」と明記しています。エージェント自身に、自分を動かす鍵を触らせないという発想です。

AI業務効率化AIにメール・予定を任せる境界の作り方

無人運用は「止まる」のではなく「静かに間違える」

これがいちばん高くついた教訓です。私の環境で、公開前の検査工程が認証切れで機能しなくなり、25回の実行・9日間にわたって検査が通らない状態が続いたことがあります。厄介だったのは、ジョブ自体は正常終了（exit=0）していた点です。仕組みの外側からは何も異常が見えませんでした。

似た事故がもう1つあります。画像生成の主経路が認証エラーで落ちていたのに、予備経路が成功し続けたため、38日間気づけませんでした。フォールバックは止まらないぶん、故障を隠します。

対策として入れたのは、実行ログを固定の文字列で機械的に走査して警告を鳴らす仕組みです。設計思想は1つで、AIの自己申告に頼らないこと。AIが壊れているときこそ、AI自身には報告できないからです。

Agents APIで言えば、公式が挙げる注意点がそのまま該当します。関数ツールのハンドラが応答しなければ、エージェントは結果を待ち続ける可能性がある。イベントストリームを閉じてもタスクはキャンセルされない。どちらも「エラーにならずに、進まない・止まらない」型の壊れ方です。失敗の検知より、無言の停滞と無言の継続の検知を先に設計してください。

並列は「3つの天井」を別々に見る

Agents APIではmulti_agentを有効にしてmax_concurrent_subagentsを指定すると、サブエージェントへの委譲ができます。公式のサンプルでは4が指定されています。

私が別のエージェント環境の運用で学んだのは、並列の上限は1つの数字ではなく3つの軸で別々に決まるということです。1セッションで生成できるサブエージェントの累計、同時に走る数、入れ子にできる深さ——この3つは別物で、実際に詰まる場所は環境ごとに違いました。

加えて、コスト面では同時実行数がそのままコンテナ課金に効きます。「速くしたい」で並列数を上げると、料金と障害時の影響範囲が同時に増えます。私が自社のジョブで採っている方針は、ジョブ同士を直列化するロックを噛ませて、基本は1本ずつしか走らせないというものです。無人運用では、速度より「何が起きたか後から分かること」を優先しています。

中小企業が検討するときの5つの質問

導入の可否を判断するとき、私がヒアリングで必ず確認する順番で並べます。

1. 扱うデータは米国保管とベンダー側保持を許容できますか。契約や社内規程でNGなら、現時点のAgents APIは選択肢から外れます。自社サンドボックスでも回避できません
2. 作業は何分かかりますか。数秒〜数十秒で終わるならResponses APIで足ります。数十分以上かかり、途中経過を保存したいならAgents APIの価値が出ます
3. 同時に何本走らせますか。コンテナ課金も障害の影響範囲も、ここで決まります
4. 失敗したことを、誰がどうやって気づきますか。トレースの外部持ち出しがベータ範囲外である以上、検知は自前で設計する前提になります
5. エージェントに渡す鍵は、何ができる鍵ですか。削除・送信・決済ができる鍵を渡していないかを、権限の一覧で確認してください

逆に、この5つに答えられない段階でモデルの比較検討を始めているなら、順番が逆です。エージェント導入で事故が起きるのは、モデルの性能不足ではなく、境界と検知の設計不足がほとんどです。

よくある質問

Agents APIとAgents SDKは、どちらを使うべきですか

公式の比較表に沿うなら、OpenAIにエージェントの管理と進捗保存を任せたいならAgents API、デプロイ・保存・承認・ランタイム統合を自社で制御したいならAgents SDKです。組み込みの手間はAgents APIが「低い」、SDKが「中くらい」と記載されています。手軽さと制御可能性のトレードオフだと考えてください。

Agents APIを使うのに追加のヘッダーは必要ですか

必要です。公式はリクエストにOpenAI-Beta: agents=v1ヘッダーが必要と記載しています。OpenAIの各SDKは自動で付与しますが、cURLで直接叩く場合は明示的に含める必要があります。

ベータであることのリスクはどう見ればよいですか

パブリックベータは仕様変更と提供終了の両方があり得る段階です。特にベータのエンドポイントを本番業務の中核に置くときは、移行先を先に決めておくのが安全です。APIの提供終了に備える棚卸しの考え方は別記事にまとめています。

AI業務効率化AIのAPI提供終了に備える｜廃止予定の調べ方と棚卸し手順

サンドボックスを使わない構成でも意味はありますか

あります。environment.typeをnoneにすれば、コンテナ課金は発生せず、モデルとツールの料金だけになります。外部サービスをツールやMCP経由で叩いて答えを返す用途なら、これで足りるケースは多いはずです。ただしBashやファイル操作が使えないので、「調べて答える」は可能でも「作って動かす」はできないと理解してください。

まとめ

Agents APIは2026年9月10日にパブリックベータとして公開された、OpenAIがエージェントの実行を預かる仕組みです。押さえるべき点を整理します。

• 預けられるもの：セッション管理、ツール呼び出しのループ、文脈の圧縮、中断からの復帰。自前で作ると重い部分がそのまま消えます
• 料金の構造：モデル＋OpenAI製ツール＋コンテナの3系統。コンテナは1つあたり20分で1 GB 0.03ドル〜64 GB 1.92ドル、分単位課金で最低5分
• 手放すもの①：データレジデンシーは米国のみ、ZDR非対応。自社サンドボックスにしてもZDR対象にはならない
• 手放すもの②：usageはベストエフォートでnullもあり得る値であり、最終請求ではない。キャッシュ書き込み数が出ないため正確な課金額を判定できないと公式が明記
• 手放すもの③：トレースの取得と外部エクスポーターはベータAPIの範囲外。監視は自前で設計する前提
• 運用上の急所：サンドボックスは活動が1時間止まると削除され得る（設定変更不可）。残すものは/workspace/outputsへ置く。network.accessの既定はenabled

エージェントの導入判断は、性能比較よりも「何を預け、何を手元に残し、壊れたことにどうやって気づくか」の設計で決まります。私自身が無人運用で痛い目を見たのは、いずれも性能ではなく検知の設計が足りなかった場面でした。

なお本記事の仕様・価格は2026年9月12日時点に私が公式ドキュメントで確認した内容です。OpenAIの仕様と価格は更新が早いため、実装・契約の判断をされる際は公式のAgents API概要と公式の価格ページで最新の条件をご確認ください。

株式会社Fyveでは、こうした新しい基盤を「自社の業務に当てはめると何を預けることになるのか」まで具体化したうえで、境界の設計と検知の仕組みづくりまで伴走しています。カタログ比較で止まらず、事故が起きたときに気づける形まで作り切ることが、エージェント導入で遠回りしない近道だと考えています。