9月10日、OpenAIはAgents APIのパブリックベータを公開し、「Codexを支えているものと同じハーネスとインフラを、シンプルかつ柔軟なAPIを通じて開発者へ提供」し始めました。9月29日のDevDayではComputer Use機能、AWSネイティブな兄弟サービス、そして新たな仲間が加わりました。ChatGPTの新しい常時稼働型エージェント「dots」も、この同じCodexハーネス上で動いています。
エージェント製品を開発している開発者の視点で見れば、これは朗報です。自前で書いて不具合に悩まされるはずだったハーネスを、他者に任せられるようになったからです。しかし、すでに実際のコードベースでClaude CodeやCodexをチーム運用しているエンジニアの視点で見ると、問いは一変します。このAPIは「エージェントを数時間連続して動かし続けるにはどうすればいいか？」という疑問には答えてくれますが、「6つのエージェントが何をしたのかをチームはどう把握するのか？」「そのうちの1つがログインしたウェブサイトを誰が承認したのか？」には答えてくれません。Sharklyが向き合っているのは、まさにこの2つ目の問いです。
TL;DR（要約）
Agents APIは、耐久性のあるセッション（durable sessions）、コンパクション、ツール検索、サブエージェント、そしてOpenAI・自社インフラ・9社のパートナーから選べるサンドボックスなど、Codexのハーネスを提供します。費用はトークン、ツール、コンテナ時間以外にはかかりません。DevDayでは、アプリケーションが新しいウェブサイトのオリジンやサインインを都度承認するComputer Use（オリジンの承認は個々のアクションの承認ではありません）や、AWS内でコア機能を実行するBedrock Managed Agentsが追加されました。しかし、そのいずれも「チームレイヤー」は担っていません。つまり、誰がタスクを割り当てたのか、どのエージェントが担当しているのか、何が完了し、何が失敗し、誰がその成果物を受け入れるのかという領域です。
Agents APIとは何か、そしてOpenAIは何を実行するのか
OpenAIの概要によると、このAPIは4つの構成要素に集約されます。Agentは「エージェントが利用できるモデル、指示、ツール、およびMCPサーバー」です。Environmentは「エージェントがファイルにアクセスし、スキルをロードし、コマンドを実行する任意のサンドボックスまたはコンピューター」です。Sessionは「タスクに取り組み、入力に応答する、耐久性のあるエージェントインスタンス」です。そしてEvents and itemsは「送信する入力と返される出力」です。
エージェントの設定を指定してセッションを作成し、環境の準備が整ったらタスクを与え、ストリーミングやWebhookで進捗を追跡し、必要に応じて同じセッションにさらなるタスクや指示（steering）を送信します。ドキュメントのコード例（一部省略）：
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions: "Use the docs MCP and web search. Delegate independent research to subagents when useful.",
tools: [
{ type: "programmatic_tool_calling" },
{ type: "mcp", server_label: "openai_docs", transport: { type: "http", server_url: "https://developers.openai.com/mcp" } },
{ type: "web_search" },
],
multi_agent: { enabled: true, max_concurrent_subagents: 4 },
},
environment: { type: "self_hosted", workspace_directory: "/workspace" },
input: [{ role: "user", content: [{ type: "input_text", text: "Research how to connect an MCP server to an OpenAI agent and summarize the setup." }] }],
});
注目すべきポイントの多くはこの2行にあります。multi_agentは並行数の上限を設定してサブエージェントへの分散処理を有効にし、environment.typeはコードを実行する場所をopenai_hosted、self_hosted、またはパートナーのサンドボックス（Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercel）から決定します。
ドキュメントでは、この役割分担が次の一文でまとめられています。「OpenAIがセッション、オーケストレーション、コンテキストのコンパクション、リカバリを管理し、アプリケーション側がツールを提供して実行環境を選択する」。
| OpenAIが実行するもの | 依然としてユーザーが用意するもの |
|---|---|
| エージェントループ：モデル呼び出し、ツール利用、リトライ | タスク、および完了の定義（Definition of Done） |
| セッションの上限が近づいた際のコンテキストのコンパクション | ツール：MCPサーバー、関数、組み込みツール |
| ツールの検索と読み込み | 認証情報（Vault ID経由） |
| サブエージェントのタスク分解と連携調整 | 環境の選択とそのセットアップ |
| セッションの再開とステアリング（指示出し） | セッション終了後に発生するすべて |
モデルの使用料金は各モデルのAPIレート、ツールは標準レート、OpenAIホストのサンドボックスはコンテナレートで課金され、ローンチ時の投稿には「Agents APIの利用に追加料金は発生しません」と記載されています。また、ドキュメントには2つの境界が明確に示されています。このAPIは「現在、データレジデンシーを米国のみでサポートしており、Zero Data Retention（ZDR：データ保持ゼロ）はサポートしていません」。そして、セルフホストのサンドボックスを選択してもZDRの対象にはなりません。コンプライアンス要件においてどちらかが重要な場合、サンドボックスを自社内に移してもこの制約は変わりません。
DevDayで何が追加されたのか
Computer Use。 computer_useツールを追加し、OpenAIホスト環境でデスクトップを有効にすると、エージェントがホストされたブラウザを操作できるようになります。Computer Useガイドでは、承認イベント（approval events）を中心にフローが設計されています。ブラウザは、公開サイトを含め、新しいWebサイトのオリジンにアクセスするたびにユーザーの承認を求めます。サインインは個別のリクエストとして届き、アプリケーション側でメールアドレス、パスワード、認証コードの入力フィールドを表示します。パスキーやQRコードによるサインインはサポートされておらず、認証情報を要求できるのはメインエージェントのみで、サブエージェントは要求できません。ここで特に注意深く読むべき一文があります。「オリジンの承認は、個々のアクションの前に確認を強制するものではありません。」購入処理や破壊的な変更を伴う操作について、ドキュメントでは、そうした操作を実行できないリソースにホスト型ブラウザを制限するか、自身が管理するブラウザランタイムを使用することを推奨しています。DevDayの振り返り記事によると、Computer Useは「API経由、ならびにPro 500およびEnterpriseプランのCodexとChatGPT Work」で利用可能とされています。
OpenAIを搭載したBedrock Managed Agents。 OpenAIとAmazonは「Agents APIのコア機能」を取り入れ、AWS上でネイティブに動作するようカスタマイズを加えました。AWSの製品ページではプレビュー版として公開されており、エージェントランタイムとモデルの推論はAWS内に留まり、各エージェントが独自のAWS IDと権限を保持すると説明されています。
同じハーネスで動作する「dots」。 Decryptの報道によると、Codexのハーネスは「現在dotsを支えており、オープンソース化されている」とのことです。dotsはChatGPTの常時稼働型エージェントであり、それぞれが独自のクラウドコンピューターを持っています。これらが何を得意としているのかについては、当社のdotsの解説記事で詳しく説明しています。
こうして、単一のループがコーディングエージェント、APIセッション、AWSエージェント、そして常時稼働アシスタントを動かすようになりました。ハーネスは統合されつつあります。一方で、チームに重くのしかかるのが承認イベントです。承認イベントは1つのセッション内での問いかけに過ぎず、そのストリームを開いている人が誰であれ回答することになります。しかし、5つのセッションから同時に承認が求められた場合、誰がどのオリジンを承認してよいのか、そしてその決定をどこに記録するのかを誰かが決めなければなりません。これは承認ゲート（approval gate）の問題であり、当社ではコンピューター操作側の観点からGPT-6 AstraにおけるComputer Useのガードレールで詳しく考察しました。
何が実行されないのか：チームレイヤー
セッションは自分自身の状態しか把握していません。他に3つのセッションが同じリポジトリを変更していることも、4つ目のセッションの成果物が火曜日から未読のまま放置されていることも知りません。これらは管理上の問題であり、複数の人間が複数のエージェントを動かし始めた瞬間に発生します。
このAPIが設計上、未解決のまま残している5つの問い：
- 誰がこのタスクを割り当て、どのチケットに対応しているのか？ セッションが持つのはIDと、コードが書き込んだメタデータだけです。オーナー、スプリント、あるいは元となったIssueへのリンクは、自前で意図的に設定しない限り存在しません。
- どのリポジトリとブランチを変更したのか？ 生成されたdiff（差分）は、レビュアーが確認できる場所へ持っていく必要があります。
- 何が完了し、何が失敗し、何が待機中なのか？ イベントは受信している間にストリーミングされるか、Webhook経由で届きます。人間の確認を待つキューとして成果物が自動的に蓄積されることはありません。
- 誰がその成果物を承認（アクセプト）するのか？ 承認イベントの対象はWebサイトへのアクセスやサインインであり、作業成果そのものではありません。承認フローを自前で構築しない限り、「セッションが終了した」ことと「人間が証跡を確認して承認した」ことは区別されません。
- OpenAI製以外のエージェントはどうするのか？ 特定の作業にはClaude Codeを使い、別の作業にはCodexを使うとなれば、2つのセッションモデルが存在し、確認すべき場所も2つに分かれてしまいます。
これら5つの要素はすべて、イベントを基盤にして自前で構築することは可能です（ボード、Webhook、ステータスフィールド、レビュー列など）。しかしその後、「エクスポート機能の修正って結局リリースされたんだっけ？」と誰かが尋ねたとき、その答えは誰も保存していないターミナルのログの彼方に消えているかもしれません。AIエージェントのタスク管理では、自前で構築する場合のアプローチについて解説しています。
セッション内のサブエージェントか、ボード上のタスクか？
max_concurrent_subagentsという設定項目は、並行処理に対するこのAPIの回答であり、適した種類の作業にとっては優れた選択肢です。これは、Codexがサブエージェントの上限を64に引き上げた際に私たちが述べたトレードオフと同じです。サブエージェントは親エージェントを共有し、1つの統合された回答として報告し、単一の成果物としてレビューされます。
各タスクが読み取り中心で、互いに独立しており、統合された回答だけが重要な場合には、セッション内のサブエージェントを使用するのが適しています。例えば、4つのAPIを調査する、コードベースをスキャンして特定のパターンを探す、インシデントの証拠を収集するといったケースです。
一方で、それぞれの作業でコードの書き込みが発生し、個別にレビューする必要がある場合は、個別のTaskに分けるべきです。例えば、マイグレーション、特定モジュールの新機能開発、共有ファイルに手を加えるバグ修正などがこれに該当します。Sharklyでは、各実行ごとにユーザーが所有するComputer上に独立したGitワークツリーが割り当てられ、各成果物はdiff、実行ログ、レビュアー情報とともに個別のTaskへと返されます。コード変更を伴う4つのタスクを1つのサブエージェントの要約に押し込めてしまうと、4つの決定事項が1つの影に隠れてしまうことになります。
よくある質問（FAQ）
Computer Useはどのモデルで動作しますか？ ドキュメントの例ではgpt-6-astraが使用されています。他のモデルでもcomputer_useツールが動作すると判断する前に、ガイドを確認してください。
SharklyはAgents APIのセッションを実行しますか？ Sharklyは、ユーザーのComputersにインストールされたCodexやClaude CodeなどのCLIコーディングエージェントをRuntime（ランタイム）として実行します。Agents APIのセッションはホスト型サービスであり、インストール型のRuntimeではないため、別の実行パスとして扱ってください。
人間のレビューはどこで行われますか？ Agents APIでは、自前で構築した場所で行われます。承認イベントがカバーするのはWebサイトへのアクセスやサインインであり、成果物の検収・承認ではありません。Sharklyでは、エージェントがタスクを「人間のレビュー待ち」の状態にしておくことができ、そのリクエストは担当者のInboxに届きます。担当者は応答、実行ログ、およびdiffを確認した上でステータスを変更します。
各レイヤーが担うべき役割
OpenAIのインフラ上で動作する耐久性のあるセッションは、今回のリリースで最も利便性が高く、同時に最もロックインされやすい要素です。エンジニアリングチームにとってこれは極めて重要です。なぜなら、最強のコーディングエージェントは常に変わり続けるものであり、レビューの状態や割り当てルールが特定のベンダーのセッションストアに依存しているチームは、覇権エージェントが変わるたびにワークフローを再構築しなければならなくなるからです。
エージェントを活用した製品やバックエンドサービスを開発しているのであれば、Agents APIは最適なレイヤーであり、AWS環境内で完結させる必要があるチームにとってはBedrock Managed Agentsも同様の有力な選択肢です。ハーネスを保守する手間なく利用でき、サンドボックスのプロビジョニングも不要になります。この場合、タスクボードは一切不要かもしれません。アプリケーション自体がボードの役割を果たすからです。
しかし、エージェントが自社のコードベース上で働くチームメンバーであり、人間によって実行され、人間によってレビューされ、既存のリポジトリやイシュートラッカーを通じてリリースされるのであれば、話は別です。CodexやClaude Codeが担うのは実行です。Sharklyは、これらのツールを横断して、チームレベルでのタスク割り当て、接続されたComputers、タスクのコンテキスト、進捗状況、ブロッカー、成果物、そして人間のレビューを管理します。SharklyはいずれのRuntimeの代替でもなく、Agents APIの代替でもありません。これと同じ「どこに配置すべきか」という問いはCodex自体にも当てはまり、それについてはCodexクラウド vs 自社Computersで詳しく取り上げています。
エージェントを構築するならハーネスを借りる。エージェントを管理・運用するなら、管理レイヤーは自社で保持し、プロバイダー中立にしておく。
すでに複数のエージェントを運用しているなら、Sharklyを使えばそれらのタスクと成果物を1か所で一元管理できます。Sharklyはトークンを販売していません。モデルの使用料は、接続したツール側で設定されているサブスクリプションまたはAPIキーを通じて継続して請求されます。
