エージェント開発でいちばん骨が折れるのに、いちばん差別化にならない部分——それは「ハーネス」でした。モデルを呼び、ツールを実行し、会話履歴を管理し、文脈が溢れそうになれば圧縮し、失敗すれば立て直す。この“接着剤”のコードを各社が車輪の再発明のように書いてきました。2026年9月10日、OpenAI はその接着剤を1本のAPIにまとめた Agents API を公開ベータで公開しました（OpenAI）。自社の Codex を動かしているハーネスそのものを、マネージドサービスとして開発者に開いた形です（MarkTechPost, 2026-09-10）。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、PoC から本番運用・内製化までを支援しています。その視点から見ると、この発表の要点は「便利なAPIが増えた」ことではありません。エージェント構築の主導権が“オーケストレーション”から“実行環境の選択と統制”へ移った——企業が本当に考えるべき論点が動いた、という点にあります。
Agents API とは何か——ハーネスを丸ごとマネージドに
Agents API は、HTTP でタスクを投げると OpenAI 側がエージェントを走らせる仕組みです。モデル呼び出し・ツール実行・会話履歴・文脈圧縮・サブエージェントの調停までをサービス側が引き受けます（OpenAI Docs）。設計は4つの概念で整理されています。
| 概念 | 役割 |
|---|---|
| Agent | モデル・指示・使えるツール・MCPサーバーの定義 |
| Environment | エージェントがコードを実行しファイルを触る任意のサンドボックス |
| Session | 数時間〜数日走り続けられる“持続するエージェント実体” |
| Events / Items | エージェントへの入力と、返ってくる出力の単位 |
技術的に効いてくるのがセッションの持続性です。Session は本番で連続稼働するエージェントに、状態管理・クラッシュからの復旧・多段実行の器を与えます（datastudios）。文脈が上限に近づけば自動で過去のコンテキストを圧縮し、開発者が圧縮ロジックを書く必要はありません。ツール定義は必要になったときだけ読み込むツール検索でトークンとコストを抑え、キャッシュを保ちます。複雑なタスクはサブエージェントに分割され、各サブエージェントが自分の文脈を持ち、主エージェントが束ねて結果を統合します。
課金は明快で、ハーネス自体には別料金がなく、支払うのはモデルトークン・ツール・サンドボックスの実行分だけです（MarkTechPost）。同じ9月10日には、承認済みの社内データを分析する Data agent が ChatGPT Work に加わり、Redshift・BigQuery・Databricks・Snowflake・MongoDB などのデータソースへ接続できるようになりました（InfoWorld, 2026-09-10）。方向性は一貫しています——エージェントを企業の実データに、より深く結線しにいく、という方向です。
いちばん重要な設計思想は「ハーネスと実行環境の分離」
Agents API のもっとも本質的な設計は、機能の多さではありません。管理ハーネス（誰がオーケストレーションするか）と、実行環境（どこでコードが動くか）を明確に切り離したことです（The New Stack）。OpenAI がハーネスをホストして維持する一方、エージェントのコンピュート環境は企業が選べる——ここが要点です。選択肢は大きく3つあります（OpenAI、InfoWorld）。
| 実行環境 | 何が起きるか | 統制上の含意 |
|---|---|---|
| OpenAI 管理サンドボックス | プロビジョニングも運用も OpenAI 任せ | 最速。ただし実行の場は自社の外 |
| 自社インフラ / 自社VPC | 秘密情報の保管とコンピュート構成が社内IT管理下に留まる | データ主権・コンプライアンス要件に対応しやすい |
| パートナーサンドボックス（9社） | Blaxel・Cloudflare・Daytona・DigitalOcean・E2B・Modal・Oracle・Runloop・Vercel | 既存のクラウド関係を活かしつつ実行を分離 |
自社VPCで走らせる選択肢では、シークレットの保管場所とコンピュート構成が社内IT部門のコントロール下に残ると明記されています（InfoWorld）。セキュリティやコンプライアンスの要求が強い組織は、エージェントを内部インフラで実行できる——つまり、モデルとハーネスはベンダーに預けても、実データに触れる“実行の場”は自社に置けるという設計です。
ポイントは「マネージドか、セルフホストか」の二択ではなくなったことです。オーケストレーション（ハーネス）はベンダーに預け、データに触れる実行環境（サンドボックス）だけを自社側に引き取る——この“分離”が現実的な選択肢になりました。統制を語るときの単位が、アプリ全体から「どのレイヤーをどこに置くか」へ細かくなっています。
コモディティ化する層と、企業に残る論点
Agents API が示すのは、より大きな地殻変動です。OpenAI の API 戦略は Responses API を中心に収斂しつつあり、オーケストレーションのハーネスはモデルベンダー自身が提供する標準部品になりつつあります（DevelopersIO）。ハーネスの自作が競争優位だった時代は、静かに終わりに向かっています。
ここに、日本企業にとっての実務的な示唆があります。コモディティ化する層に自社の工数を張っても、差はつきません。文脈圧縮やリトライの実装は、いずれ標準機能に吸収されていきます。では、何が残るのか——実行境界と統制です。
- 実行境界: エージェントの実行はどこで起きるか。実データ・シークレット・社内システムに触れるコンピュートは、自社の管理下（VPC）にあるか、外にあるか。
- データの持ち出し: どのデータが、どのモデル/サンドボックスへ、どの経路で流れるか。DLP と egress の制御が効くか。
- 承認と監査: 危険な操作の前に人が止められるか。「誰が・いつ・何を承認したか」が構造化された証跡として残るか。
- 可搬性: 特定ベンダーのハーネスに寄せた結果、モデルや実行環境を乗り換えられなくなっていないか。
「マネージドで速い」は魅力ですが、実データに触れる実行環境まで既定で外部に預けると、後からデータ主権や監査要件で作り直しになりがちです。速く始めることと、実行境界を自社に残せる余地を確保しておくことは、最初から両立させて設計すべきです。
homula はどう設計するか
homula の基本方針は「速く始めて、統制は構造で担保する」です。Agents API のようなマネージド・ハーネスが登場した今、その方針はむしろ実装しやすくなりました。
- PoC は素早く: まずは価値検証を優先し、対象業務を絞る。マネージド・ハーネスは立ち上げを速めます。AIエージェント・ブートキャンプでは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結させます。
- 実行境界を最初に決める: 実データやシークレットに触れる実行環境を、外部の管理サンドボックスに置くのか、自社VPCに引き取るのか。この線引きは後から動かしにくいので、PoC の段階で意思決定します。
- 統制と監査を後付けにしない: Agens は MCP を活用したエンタープライズ向け統合プラットフォームで、200以上のツールと構築ゼロで接続できます。その上で Agens Control が承認フロー・DLP・RBAC・5年分の監査ログを提供し、ハーネスがどこで動こうと「誰が・何を・いつ実行/承認したか」を証跡として残します。ベンダーのハーネスを使いつつ、統制の主導権は手放さない設計です。
ハーネスの機能はベンダーに任せてよい。しかし、実行境界・データ経路・承認証跡は自社の設計判断として握り続ける——これが可搬性と統制を両立させる勝ち筋です。エージェントの実行を「自社の中」に留める論点は自己ホスト実行の境界設計でも、統制点の置き方はツール単位の承認ゲートでも扱っています。
まとめ
OpenAI Agents API は、エージェント開発の景色を一段変えました。
- Codex のハーネス（オーケストレーション）が1本のAPIになり、モデル呼び出し・ツール実行・文脈の自動圧縮・持続セッション・サブエージェントがマネージドで手に入る。ハーネス自体に別料金はない。
- 最重要の設計思想はハーネスと実行環境の分離。企業は OpenAI 管理サンドボックス／自社VPC／9社のパートナーサンドボックスから、コンピュートの置き場所を選べる。VPC ならシークレットとコンピュート構成は社内IT管理下に残る。
- ハーネスがコモディティ化する一方で、差がつくのは実行境界・データの持ち出し・承認と監査・可搬性という、より企業側の論点へ移った。
- homula の設計順序は変わらない——速く始め、実行境界を最初に決め、統制と監査は構造で担保する。
「どのモデルか」「どのフレームワークか」に続く問いは、もはや「どこで実行し、誰がデータと証跡を握るのか」です。ハーネスは借りてよい。境界と統制は、手放さない。
マネージド・ハーネスを活かしつつ、実行境界と統制設計を自社に残したい方は、まずは現状の要件を持ち寄る無料相談からご相談ください。