TL;DR
- OpenAI の Agents API は、公式ドキュメントの言葉で 「The Agents API gives your application access to the Codex harness through an OpenAI-managed API.」（
公式値/ 2026-09-15 確認）です。エージェントの実行基盤そのものが API になりました。 - 公式が定義する構成要素は 4 つです。
Agent/Environment/Session/Events and items。この 4 つが、これまで各社が自前で書いていた層とほぼ 1:1 で対応します。 - 「では自前の harness は要らなくなるのか」を、このブログのリポジトリで数えました。
.agents/spec/scripts/tests/の合計は 60,841 行（社内データ/ 2026-09-16 時点・90e3983）。そのうち Agents API が引き受ける層に相当する行は、ほぼ 0 行でした。 - 理由は単純で、このリポジトリはすでに harness を買っているからです（Claude Code）。それでも 60,841 行が積まれている。つまり Harness as a Service が来ても、この列は減りません。
- 外注できるのは loop / session / sandbox / subagent の実行です。手元に残るのは 「何をもって完成とするか」の規約と、それを機械で落とすガードです。うちでは
scripts/42 本のうち 18 本がガードで、tests/には 12,543 行あります。 - 判断は「使うか使わないか」ではなく 列ごとに分かれます。公式ドキュメント自身が Agents API / Agents SDK / Responses API を integration effort が Low / Medium / High の 3 択として並べており、置き換え関係としては書いていません。
- この記事は提言ではなく、1 つのリポジトリで列を数えた記録です。組織がどう投資すべきかには踏み込みません。
はじめに：Model API の次の層が来た
AI アプリケーションを書いてきた人なら、同じものを何度も実装した覚えがあるはずです。モデルを呼ぶ、tool call を受け取る、実行する、結果を戻す、また呼ぶ。この agent loop を自前で書く話は、このブログでもagent loop を自前実装するで扱いました。状態が落ちる問題はagent loop durable workflow実装で書きました。
その「何度も実装していた層」が、そのまま API になりました。
ここで反射的に出る問いが 2 つあります。「自前 harness は捨てられるのか」と「捨てたら何が残るのか」。この記事は後者から答えます。前者に答えるには、先に列を分けて数える必要があるからです。
なお、この記事では Agent のセキュリティ設計そのものは扱いません。権限と被害範囲の話はAIエージェントの権限は影響範囲で設計するに分けてあります。ここで扱うのは「どの層の保証を誰が持つか」という責務の所在までです。
1. Agents API は何を API 化したのか
まず公式ドキュメントの記述を確認します。以下はすべて公式開発者ドキュメントからの引用です（2026-09-15 取得）。
構成要素は 4 つと明記されています。
| 公式の用語 | 原文の定義 |
|---|---|
Agent | The model, instructions, tools, and MCP servers available to the agent |
Environment | An optional sandbox or computer where the agent accesses files, loads skills, and runs commands |
Session | A durable instance of an agent that works on tasks and responds to input |
Events and items | The inputs sent to an agent and the output produced during a session |
Environment の定義に runs commands が入っていることに注目してください。ファイルを置く場所ではなく、コマンドが走る場所まで含めて 1 つの構成要素になっています。
そして誰が何を持つかも、同じページに書かれています。
OpenAI manages sessions, orchestration, context compaction, and recovery while your application provides tools and chooses its execution environment.
sessions, orchestration, context compaction, and recovery が向こう側、tools と実行環境の選択がこちら側です。この 1 文が責務の分界線そのものです。
呼び出しはセッションを作る形です。エンドポイントは POST https://api.openai.com/v1/agents/sessions です。以下は公式ドキュメントの例に合わせた形です。
curl https://api.openai.com/v1/agents/sessions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "OpenAI-Beta: agents=v1" \
-H "Content-Type: application/json" \
-d '{
"agent": {
"model": "gpt-6-astra",
"instructions": "You are a careful repository maintainer.",
"tools": [{ "type": "web_search" }],
"multi_agent": {
"enabled": true,
"max_concurrent_subagents": 4
}
},
"environment": { "type": "openai_hosted" },
"input": [
{
"role": "user",
"content": [
{ "type": "input_text", "text": "Summarize the failing tests." }
]
}
]
}'
モデル ID は公式例で使われている gpt-6-astra をそのまま置いています。Agents API で選べるモデルの一覧は公式ページ上で確認できなかったため、この記事では「この ID なら使える」という保証はしません。自分の環境で試すときは公式の最新例を確認してください。
注目すべきは multi_agent.max_concurrent_subagents です。subagent の並列度が、自前で書くオーケストレーションではなくリクエストの 1 フィールドになりました。subagent の設計論はこのブログでもClaude Code サブエージェント設計で扱いましたが、その実行側が設定値に落ちたわけです。
sandbox は 2 系統あります。公式の用語は OpenAI-hosted sandbox と self-hosted sandbox です。「managed sandbox」という言い方は公式ドキュメントには出てきません（managed が付くのは harness と API 側です）。この記事で用語を公式に合わせているのは、責務の所在を語るのに用語のズレが致命的だからです。
2 系統は設定できる項目も違います。OpenAI-hosted 側で指定できるのは packages / setup_commands / files / env / skills / plugins / capability_directories / environment_template_id / network で、作業ディレクトリは /workspace 固定と書かれています。workspace_directory を指定できるのは self-hosted 側です。「hosted を選ぶ = 環境の細部を渡す」ということが、指定できるフィールドの差としてそのまま出ています。
self-hosted 側の実行体は codex exec-server で、接続の向きが明記されています。
All connections are outbound. The executor reconnects if the connection drops.
つまり自社インフラ側に inbound を開けません。環境キーの権限範囲も明示されています。CODEX_API_KEY は 「only permits connecting environments. It cannot authorize any other API action.」 と書かれています。ここは「買う側が何を保証してもらえるか」の具体例として読めます。
一方で、現時点の制約も公式に書かれています。
The Agents API currently supports data residency only in the United States and does not support Zero Data Retention.
この 1 行は build-vs-buy の判断に直接効きます。買えるかどうかが技術的な好みではなく、扱うデータの制約側から決まるケースがあるということです。
告知ページについての但し書き
一般向けの告知ページ（https://openai.com/index/introducing-the-agents-api/）は、今回の作業環境からは bot 保護により本文を機械取得できませんでした。したがって 本記事では告知日・「public beta」という文言・sandbox パートナーの社数を事実として書きません。本文で引用しているのは、実際に本文を取得できた開発者ドキュメントの記述だけです。取得できなかったものを取得できたことにしない、というのはこのブログの運用ルールです。
2. 「Harness」と呼ばれているものを 5 列に分ける
Agents API が引き受ける範囲を評価するには、ひとまとめに「harness」と呼んでいるものを分解する必要があります。このブログでは以下の 5 列で見ています。
| 列 | 中身 | Agents API の扱い |
|---|---|---|
| A. 実行ループ | observe / plan / act / verify の反復、リトライ、打ち切り | 引き受ける（Codex harness） |
| B. セッション永続 | 長時間タスクの状態、途中再開、イベント列 | 引き受ける（Session は durable と明記） |
| C. 実行環境 | ファイルが置かれる sandbox、コマンド実行 | 引き受ける（hosted / self-hosted の 2 択） |
| D. 責務分割 | subagent をいくつ、どの役割で回すか | 半分（並列度は API、役割設計は自分） |
| E. 完成の定義 | 何を満たしたら done か、その検査 | 引き受けない |
A〜C が実行基盤、D が設計、E が規約です。Agents API が明確に引き受けるのは A〜C で、公式ドキュメントの Session / Environment がそこに対応します。
E だけが浮いています。これが次節の測定対象です。
3. うちの harness を列ごとに数えた
このブログのリポジトリ（記事 230 本）で、harness 相当のディレクトリを数えました。すべて commit 90e3983e51f9ef46fc12e624251298871e3891b4（2026-09-16 時点） の作業ツリーの実測です（社内データ）。行数は毎日動くので、日付だけでなく ref を添えないと再現できません（初版は別の commit で測っており、後続のマージで値が失効しました）。
find .agents/skills -type f -name '*.md' -exec wc -l {} + | tail -1 # 20298（161 ファイル）
find .agents/agents -type f -name '*.md' -exec wc -l {} + | tail -1 # 4204（25 ファイル）
find spec -type f -name '*.md' -exec wc -l {} + | tail -1 # 10029（51 ファイル）
find scripts -type f -not -path '*__pycache__*' -exec wc -l {} + | tail -1 # 13767（42 ファイル）
find tests -type f -name '*.py' -exec wc -l {} + | tail -1 # 12543（27 ファイル）
scripts/ の -not -path '*__pycache__*' は必須です。付けないと .pyc を巻き込んで 14,879 行になります。一度でも pnpm test を回した作業ツリーで数字がずれる、という地味な罠です。本数と行数は同じ母集合で数えています（ファイル数 = 上のコマンドが数えたファイル数）。
| 対象 | ファイル数 | 行数 | 5 列のどれか |
|---|---|---|---|
.agents/skills/（.md） | 161 | 20,298 | E（手順と品質基準） |
.agents/agents/（.md） | 25 | 4,204 | D（役割定義） |
spec/（.md） | 51 | 10,029 | E（契約・ゲート） |
scripts/ | 42 | 13,767 | E（うちガード 18 本） |
tests/（.py） | 27 | 12,543 | E（ガードのガード） |
| 合計 | 306 | 60,841 | — |
単位をディレクトリで数えると別の顔になります。.agents/skills/ 直下のディレクトリは 90 本、SKILL.md は 91 本です。「スキル 90 本」と「20,298 行」は同じものを別の単位で見た値で、行数のほうは各スキルの参照ドキュメントを含みます。数える単位を混ぜると簡単に嘘になるので、以降は行数で話します。
そして A〜C に相当する自前コードは、このリポジトリに 1 行もありません。agent loop も session 永続も sandbox も書いていないからです。理由は明快で、このリポジトリはすでに harness を買っている（Claude Code を使っている）からです。
ここが今回の測定でいちばん効いた点です。
すでに harness を外注している状態で、なお 60,841 行が積まれている。
Harness as a Service が選択肢に増えても、この 60,841 行は 1 行も減りません。減るのは、A〜C を自前で書いていた組織のその部分だけです。しかもこのリポジトリでは、AI Harnessの技術的負債と削る基準で測ったとおり、harness の行数は変更があった 9 か月すべてで増えていました。実行基盤を買ったことは、規約が減る理由にはなっていません。
内訳をもう一段見ると、E の性質がはっきりします。scripts/ 42 本のうち 18 本は接頭辞が check_ / validate_ / audit_ のガードです。記事の frontmatter を検査する、title の重複を落とす、画像の実在を確認する、ショート動画の成果物が追跡されているかを見る。どれも **このブログ固有の「完成の定義」**であって、汎用のエージェント実行基盤が代わりに持てるものではありません。
権限についても同じことが言えます。このリポジトリの Claude Code 設定は allow 72 件 / deny 19 件 / ask 0 件です（社内データ）。この 91 行は「うちで何を自動で許すか」という判断そのもので、実行基盤を差し替えても中身は変わりません。
4. 買っても手元に残るもの
「実行基盤を買ったうえで、何を自分で持つ必要があるか」の良い実例が、Next.js チームの issue triage の記録です。ここは公式ブログの本文を取得して確認しています（2026-09-15 取得）。
数字は次のとおりです（公式値）。
| 項目 | 値 |
|---|---|
| 2026-08-10 時点の open issue | 2,244 件 |
| 約 3 週間でクローズした件数 | 1,462 件 |
| 同期間の新規流入 | 218 件 |
| 週あたりの新規報告（平均） | 36 件 |
注意点として、記事タイトルは 1,500 ですが本文の実数は 1,462 件です。また「maintainer が今回のレビュー外でクローズしたものを含む」と本文に明記されています。数字を借りるときは、丸められた見出しではなく本文の値を取るべきところです。
そのうえで、彼らが基盤ではなく自分側に置いたものが 3 つあります。
- sandbox の外では read-only。本文の表現は「We made the agent read-only outside its sandbox.」です。
- issue 本文やリポジトリの内容に書かれた指示を無視するよう設定。prompt injection 対策として明記されています。
- 自動クローズに人間側の上限。スコア 80 以上でも第 2 のエージェントが再確認し、自動クローズは週最大 25 件から始めています。
3 つとも、Agents API の Session や Environment が代わりに決めてくれる種類のものではありません。どこまで自動で確定させるかは、その組織の許容範囲の問題だからです。同じ構造はIssue Triage Agentを安全に作る役割分離でも、証拠収集と判定を分けるという形で扱いました。
5. Build vs Buy を 3 つの問いに落とす
公式ドキュメント自身が 3 択を並べています。以下は Agents ガイドの比較表から Use for / Agent integration effort / Execution environment の 3 行をそのまま転記したものです（公式値、2026-09-16 取得）。
| 選ぶもの | Use for | Agent integration effort | Execution environment |
|---|---|---|---|
| Agents API | Long-running tasks where OpenAI manages the agent and saves its progress | Low | OpenAI hosted sandbox, self-hosted sandbox, or no sandbox |
| Agents SDK | Building agents with custom tools and workflows in your application | Medium | Your runtime and sandbox provider integrations |
| Responses API | Calling models directly or building an agent from scratch | High | Your own execution environment |
同じページの「Choose your starting point」カードは、この 3 つを 1 行ずつ Run an agent with the Codex harness managed by OpenAI / Control the agent loop in your application with reusable agents, tools, and handoffs / Work directly with model responses and control your integration と説明しています。カードの文と比較表のセルは別物なので、引用するときは出所を混ぜないほうが安全です。
重要なのは、この表のどこにも「置き換え」と書かれていないことです。Agents API の overview ページには Responses API も Chat Completions も Assistants API も登場しません。つまり公式の記述に忠実に読むなら、併存する 3 つの抽象度です。「Responses API は終わる」と書いている記事があれば、それは公式記述ではありません。
そのうえで、このリポジトリで判断に使っている問いは 3 つです。
問い 1: その層を自前で持つことが、自分たちの差別化になっているか。 loop の書き方で差がつくと言える組織は多くありません。うちは A〜C を 1 行も持っていませんが、それで困ったことは無いというのが実測です。
問い 2: データの制約が先に効かないか。 前述のとおり、現時点の公式記述では data residency は米国のみ、Zero Data Retention は非対応です。ここが効く領域では、技術比較より先に結論が出ます。
問い 3: 買ったあとに残る E 列を、誰が書くのか。 これが一番見落とされます。A〜C を外注すると、手元に残るのは E 列だけになります。つまり「何をもって完成とするか」を定義して機械で落とす仕事の比率が上がります。うちの 60,841 行はその形をしています。外注の効果は「作業が減る」ではなく「残る仕事の種類が変わる」です。
6. この記事で扱わなかったこと
測定と主張の範囲を明示しておきます。
- 告知ページの日付・「public beta」表記・パートナー社数は書いていません。 本文を取得できなかったためです。
- セキュリティ設計そのものは扱っていません。 sandbox は責務の所在としてだけ触れ、脅威モデルや egress 設計には踏み込んでいません。
- 性能・コストの実測はありません。 このリポジトリで Agents API を実運用した実績が無いため、体感値を書けません。書けるのは公式記述と、自リポジトリの行数だけです。
- 1 リポジトリ・記事 230 本・実質 1 人運用のサンプルです。 60,841 行という数字を一般則として読まないでください。しかもこの値は特定 commit（
90e3983e51f9ef46fc12e624251298871e3891b4）のスナップショットで、翌日には動きます。示せるのは「すでに harness を買っていても E 列は積み上がる」という 1 事例です。
まとめ
- Agents API は Codex harness を managed API として開放しました。構成要素は公式に
Agent/Environment/Session/Events and itemsの 4 つです。 - harness を 5 列（実行ループ / セッション永続 / 実行環境 / 責務分割 / 完成の定義）に分けると、引き受けてもらえるのは A〜C、残るのは E です。
- このリポジトリは既に harness を外注していますが、E 列に 60,841 行が積まれています。実行基盤を買っても、この列は減りません。
- 公式ドキュメントは Agents API / Agents SDK / Responses API を integration effort Low / Medium / High の併存する 3 択として提示しています。置き換えではありません。
- 判断するときは、自分のリポジトリで A〜E を列ごとに
wc -lしてみてください。どの列が厚いかで、買って効く量が決まります。
FAQ
Agents API を使えば自前の harness は捨てられますか
捨てられるのは実行ループ・セッション永続・sandbox の層です。このリポジトリではその層を元々自前で持っていなかったため、捨てられる行は 0 行でした。逆に「完成の定義」を書いた層は 60,841 行あり、こちらは外注先がありません。まず自分のリポジトリを列ごとに数えるのが先です。
Responses API は Agents API に置き換わるのですか
公式ドキュメントにそのような記述はありません。Agents API の overview ページには Responses API という語自体が出てきません。選択ガイドでは integration effort が Low / Medium / High の 3 択として並んでおり、制御を自分で持ちたいほど Responses API 側に寄る、という整理です。
sandbox は OpenAI 側に任せるしかないのですか
いいえ。公式には OpenAI-hosted sandbox と self-hosted sandbox の 2 系統があります。self-hosted では codex exec-server を自分の環境で動かし、接続はすべて outbound と明記されています。接続用のキーは環境の接続だけを許可し、他の API 操作を認可しないとも書かれています。
Agents API を使えない場合はどんなときですか
公式記述の範囲で明確なのは、データの所在に制約がある場合です。現時点では data residency が米国のみ、Zero Data Retention は非対応と書かれています。ここに要件がぶつかる場合、技術的な比較より先に選択肢が絞られます。最新の記述は必ず公式ドキュメントで確認してください。
subagent は API に任せれば設計しなくてよくなりますか
並列度は multi_agent.max_concurrent_subagents という 1 フィールドになりましたが、どの役割に分けるかは設定値になっていません。Next.js の事例でも、自動クローズの前に第 2 のエージェントを置く、週の上限を 25 件にするといった判断は自分側に残っています。分けられたのは実行であって、責務設計ではありません。
