一言で言うと
Agents APIは、OpenAIが持つマネージドなCodexハーネスへのAPIよ。アプリはタスクとツール／実行環境を渡す。セッション、オーケストレーション、compaction、recovery、サブエージェント、ステアリングはOpenAI側が持つ。
前の記事——プロンプト／ループ／ハーネスエンジニアリング——で言った「運行装置（狭義ハーネス）」を、自作せずに借りる話、って捉えると早いわ。
ハーネスを借りる、という感覚
狭義のハーネスは、再開・文脈圧縮・sandbox・権限ゲート・観測・長時間セッションみたいな「どう回し続けるか」の層だったでしょ。Agents APIは、その層をOpenAIが運用してくれる窓口よ。
アプリ側が握るのはだいたいこれ。
- 何をやらせるか（タスク／入力）
- 何を使えるか（ツール、MCP、スキル）
- どこで走らせるか（OpenAI hosted sandbox、または self-hosted の実行環境）
モデルの名前をコロコロ変える話じゃなくて、長い仕事を回す装置をAPIとして貸してくれる、が価値の中心よ。モデル層とハーネス層は分離されてる、って公式の立て付けもそこに近い。
Responses API / Agents SDK / Agents API の役割分担
ここ、名前が似てて混乱しやすいから表で切るわ。
| Responses API | Agents SDK | Agents API | |
|---|---|---|---|
| 抽象 | モデル応答（低レベル） | アプリ側で回すエージェント実行 | マネージドなCodexハーネス |
| ループの持ち主 | アプリ | SDK（アプリホスト上） | OpenAI |
| 向いてるもの | 一往復や自分で組むチェーン | 薄い〜中くらいの自前運行 | 長い仕事・再開・ステア込みの運行 |
| 典型 | 自分で tool loop を書く | Runner が tool loop / handoff を回す | session を作ってタスクを投げる |
Responses API：低レベル
一往復でもチェーンでも使える土台よ。でもループの持ち主はアプリ。いつツールを呼ぶか、履歴をどう繋ぐか、失敗したらどうするかは全部自分。細かく握りたいときはここ。
Agents SDK：アプリ側ホストのライブラリ
アプリのプロセスの中でエージェントループを回すライブラリよ。tool loop、handoff、guardrails、tracingあたりをSDKが面倒見てくれる。薄い〜中くらいの自前運行、って感じ。実行環境や永続化の最終責任はまだアプリ寄り。
Agents API：マネージドハーネス
ここが本題。OpenAIがセッションを持ち、オーケストレーションし、文脈を圧縮し、落ちたら復帰し、サブエージェントに振り、作業中のステアリングも受ける。アプリは「指示の一往復」じゃなくタスクを投げる側に回るわ。
公式ドキュメント（Agents API overview、hosted sandboxes、実行環境の選択肢）を見ると、「OpenAI manages sessions, orchestration, context compaction, and recovery / アプリは tools と execution environment を提供」って立て付けが一貫してるわよ。細部のAPI形は変わりうるから、実装は公式を当たってね。
「指示を投げる」vs「タスクを投げる」
この対比、体感の差が大きいの。
- 指示を投げる（Responses寄り）— 「このファイルを読んで要約して」。一往復か、短いチェーン。続きは人が繋ぐことが多い。
- タスクを投げる（Agents API寄り）— 「このリポジトリでバグを再現して、修正案まで出して」。セッションが続き、ツールを叩き、必要ならサブエージェントを使い、人が途中でステアできる。
チャットの延長で細かく操縦したいなら前者が合うこともある。成果物や長い調査を「預けて追いかけて、必要なら舵を取る」なら後者よ。
モデルを変えるより、運行を借りる
Agents APIの売り文句をモデル名の話に還元すると損するわ。価値の芯は、
- 長いコーディングや調査をセッションとして継続できる
- compaction で文脈を保ちながら進める
- 落ちても recovery
- サブエージェントで分割
- 作業中に steering
つまりハーネス層よ。モデルは選ぶけど、「どのモデルか」より「長い仕事を回す装置がマネージドか」の方が、設計判断としては大きい。
ユースケース
向いてるのはこんな感じ。
- 長時間コーディング — リポジトリを触り続けて、テストまで回す
- 成果物生成 — スクリプト、レポート、パッチ、アーティファクトを残す
- 落ちても続き — セッションが仕事の単位になる
- 人がステアする作業 — 全部自律じゃなく、途中で方針を差し込める
逆に、単発の要約や短い関数生成だけなら Responses で十分なことも多いわ。オーバーキルにしないこと。
コストの考え方
「Agents APIだから別料金パッケージ」みたいに単純化しすぎない方がいいわよ。公式の整理に近い見方はこう。
- モデルのトークン — 選んだモデルのAPI料金
- ツール — 使うツールの標準料金
- hosted sandbox — OpenAIがホストする実行環境はコンテナ利用に応じた課金（分課金イメージ）
つまり本体は「ハーネスAPIの定額」というより、トークン＋ツール＋実行環境よ。
実行環境を自前にするなら、例えば Cloudflare Containers を self-hosted 側に据える選択肢があるわ。Workers Paid（月 $5 ＋込み枠）が前提で、Free プランでは Containers は使えない。OpenAI側のセッション運行は借りつつ、ファイルやコマンド実行の場所はCF側に置く、みたいな分担になる。Cloudflare側にも Codex＋Containers のチュートリアルがあるから、自己ホスト実行環境を検討するならそこが入口よ。
料金表やプラン条件は変わるから、数字は公式の Pricing を最終確認してね。ここでは「何に金が乗るか」の地図だけ渡すわ。
選び方のショートカット
- ループも状態も全部自分で良い → Responses API
- アプリ内でエージェントループは欲しいが、基盤は自分のホスト → Agents SDK
- 長い仕事の運行装置ごと借りたい → Agents API
- データや実行を外に出したくない／置き場を自分で制御したい → Agents API ＋ self-hosted 実行環境（例: Cloudflare Containers）
前の記事の言葉で言うと、レシピ（ループ）は自分のドメインで書き、キッチン（狭義ハーネス）は条件がなければ借りる。Agents APIは、その「借りる」を正式なAPIにした版、って理解でアタシは十分だと思うわ。
まとめ
- Agents API = マネージドな Codex ハーネスへのAPI
- アプリはタスクとツール／実行環境、OpenAIはセッション・オーケストレーション・compaction・recovery・サブエージェント・ステアリング
- Responses は低レベル（ループはアプリ）、Agents SDK はアプリホスト上のループ支援、Agents API は運行そのものをマネージドに
- 価値はモデル名より「長い仕事を回す装置」
- コストはトークン＋ツール＋hosted sandbox（自前ならCF Containers等。FreeではContainers不可、Paid月$5＋込み枠）
- 「指示を投げる」世界から「タスクを投げる」世界への切り替え、が体感の境界線よ
運行を自作するか借りるかは、前の記事の三層とセットで考えると迷いが減るわ。まずはループ（仕事の手順）を言語化して、ハーネスはデフォルトを借りる——その選択が、今の大半の開発者には一番コスパがいいと思うのよ。