Agents API とは、OpenAI の自律エージェント構築用APIです。
OpenAI が2026年9月11日、Agents API をパブリックベータとして公開しました。数時間にわたって動き続け、コードを実行し、ファイルを処理するAIエージェントを、ChatGPT や Codex と同じ基盤の上で構築できるようになります。追加料金はなく、課金はトークン消費のみです。EC業務自動化の現場から見ると、これまで「デモは動くが本番で止まる」と言われてきた長時間処理のエージェント化が、インフラ側から一段現実的になった発表だと受け止めています。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル(うるチカラ運営)が解説します。
Agents API で何ができるようになったのか
Agents API の要点は、エージェントを動かすための土台をOpenAI側が丸ごと提供する点にあります。The Decoder によると、このAPIは ChatGPT と Codex を動かしているものと同じインフラ上で稼働し、クラウド上のエージェントが数時間単位で自律的に走り続けられます。
機能として挙げられているのは4つです。1つ目が自動コンテキスト管理で、長時間の処理でも会話履歴や作業状態の持ち回りを開発者が自前で組まなくてよくなります。2つ目が並列ツール利用、3つ目がサブエージェントへのタスク委譲で、大きな仕事を小さく割ってから同時に流す設計が標準機能として入りました。4つ目がコード実行とファイル処理で、CSVの読み込みや加工をエージェント自身の手で完結させられます。
実行環境は、OpenAIがホストするサンドボックスを使うか、Cloudflare、Vercel、Oracle といったパートナーの環境を選ぶかを開発者が決められます。そして費用面では、サンドボックス利用に対する追加料金は設定されておらず、請求はトークン使用量のみに基づくとされています。土台部分は、オープンソースとして公開されている Codex harness を基礎にしており、MCP(モデルと外部ツールを接続するための共通規格)、カスタム関数、Web検索などの組み込みツールに対応します。
日本のEC事業者にとっての3つの論点
EC事業者が押さえるべき論点は3つあります。いずれも、自社で直接APIを書くかどうかとは別に、使っているツールの中身が変わるという意味で効いてきます。
1つ目は、「数時間動き続ける」が効く業務はどこか、という論点です。これまで生成AIが得意だったのは、1回のやり取りで完結する翻訳や文章生成でした。数時間動けるようになると、レビュー数千件を全件読んで論点ごとに仕分けする、競合の価格とポイント倍率を定点観測して変化だけを報告する、数百SKUの商品説明を一括で棚卸しして規約違反の表現を洗い出すといった、これまで人が張り付いていた「量が多くて終わりが見えない」仕事が対象に入ってきます。楽天市場やAmazon、Shopify、Yahoo!ショッピングのどれを運営していても、この手の作業は必ず残っているはずです。
2つ目は、課金構造の論点です。追加料金なしでトークン課金のみという設計は、月額固定のサンドボックス費用を払わずに小さく試せることを意味します。一方で、トークン消費は実行時間と処理量におおよそ比例しますから、「止め忘れたまま一晩動いていた」という事故のコストは従来のチャット利用より大きくなります。導入するなら、1回の実行あたりの上限トークン数と、想定外に長引いたときの打ち切り条件を先に決めておくべきです。
3つ目は、MCP対応が持つ意味です。MCPに対応したということは、外部システムとの接続を個別実装ではなく共通規格で繋ぐ設計が取りやすくなったということです。楽天のRMSやAmazonのSP-API、ShopifyのAdmin APIといった店舗側のデータを、MCPサーバを自社またはベンダー側で用意して繋ぎ込む構成が現実的な選択肢になります。ただし、各モールのAPI利用規約と認証情報の管理責任は従来どおり事業者側にあります。エージェントに広い権限を渡したまま自動実行させる構成は、在庫や価格の誤更新に直結しますので、書き込み系の操作は人の承認を挟む設計を推奨します。
初動として何をすべきか
まず押さえておきたいのは、今回の公開はパブリックベータであるという点です。仕様や料金が今後変わる前提で扱うべきで、受注処理や在庫連携のような、止まると売上が直接毀損する基幹処理にいきなり接続するのは避けるのが安全です。
そのうえで、初動としては3つを勧めます。1つ目は、自社で最も時間を食っている「量の多い定型作業」を1つだけ選び、現状の人手工数を実測することです。比較対象の数字がないと、導入後の効果を誰も判断できません。2つ目は、既存のAIツールやシステムを提供しているベンダーに対して、実行環境をどこに置くのか、1回あたりのトークン上限をどう設計するのか、途中で失敗したときの再実行と重複防止をどうするのか、の3点を質問することです。3つ目は、書き込み権限の棚卸しです。読み取りだけで完結する業務から始め、更新系は人の確認を経る運用に固定しておくと、初期の事故をほぼ防げます。
なお、日本語ドキュメントの整備状況、国内リージョンでの実行可否、入力データの取り扱いに関する詳細は、本稿執筆時点の公開情報からは確認できていません。この3点は自社の要件に関わりますので、導入検討時に要確認としてください。
まとめ
Agents API の公開で変わるのは、AIが賢くなったかどうかではなく、AIを長時間・安定して走らせるための土台を誰が用意するのかという分担です。EC事業者にとっての実利は、量が多くて終わりが見えなかった定型作業を切り出せる点にあります。まずは読み取り系の業務を1つ選び、現状工数を測ることから始めるのが、無理のない入り口になります。
参考文献
- The Decoder・OpenAI’s new Agents API gives developers the infrastructure behind Codex and ChatGPT
- OpenAI・Agents API overview(公式ドキュメント)
- OpenAI・Agents API OpenAI-hosted environments(公式ドキュメント)
- GitHub・openai/codex(Codex harness オープンソース実装)
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
引用元: The Decoder
【監修】齋藤竹紘(株式会社オルセル代表 / 19年・5,000社のEC支援実績)

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。