AI APIは長いあいだ、「入力を投げたら答えが返る」ものだった。
OpenAIが9月10日に公開ベータとして発表したAgents APIは、その前提を少し崩す。CodexやChatGPT Workで使われているハーネスと基盤をAPIとして提供し、長時間タスク、ファイル、コード実行、ツール、サブエージェント、中間成果物を扱う。
モデルに一問するAPIというより、AIに仕事場を貸して、途中で道具を渡し、何時間・何日単位の仕事を管理するAPIに近い。
「どのモデル？」より「どう働かせる？」
モデル性能が上がると、次のボトルネックが目立つ。
- 長い仕事の途中で文脈が崩れる
- 道具を使う順番が悪い
- ファイルをどこに置いたか分からなくなる
- サブタスクを分けても統合できない
- 失敗した地点から再開しにくい
人間の会社でいえば、優秀な人を採用したのに机も共有フォルダも進捗管理もない状態だ。
OpenAIは、実用的なエージェントには文脈管理、効率的なツール利用、サブエージェント調整、ファイルやコードを扱える環境、長時間安定して動くインフラが必要だとしている。
つまり「AIエージェント」という商品が、モデル本体から現場監督と作業場のセットへ移っている。
これは“自作エージェント地獄”への回答でもある
企業がAI自動化を作り始めると、最初は簡単だ。APIを呼ぶ。ツールを1個つなぐ。結果をDBへ保存する。
半年後、リトライ、状態管理、権限、ログ、ファイル、並列処理、承認、コスト上限、失敗復旧が増える。気づくと「AIを使う機能」より「AIを壊れず動かす周辺コード」のほうが大きい。
Agents APIが狙うのは、かなりその層だ。
AIエージェントを5個入れたら仕事が増えるで書いた通り、複数AIの問題は知能より配線に出やすい。ハーネスが商品化されるのは自然な流れだ。
便利になるほど、責任の境界は太く書く
長時間動くAIは、短いチャットより失敗の半径が大きい。
一回の回答ミスなら閉じれば終わる。数時間走るエージェントがファイルを変更し、外部サービスへ書き込み、別エージェントを呼び、最後に公開するなら、途中の権限設計が重要になる。
最低でも、次は分けたい。
- READ: 調査、参照、検索
- WRITE: 下書き、ブランチ、ドラフト
- PUBLISH: 本番反映、送信、削除
- EVIDENCE: 実行後のreadback
全部を一つのトークン、一つの権限、一つの「自動化」で包むと、速い代わりに事故も速い。
APIの次の競争は、モデルではなく運転免許
今後、AI基盤を選ぶときに見るべきはベンチマークだけではない。
長時間タスクをどこまで再開できるか。ツール権限を細かく切れるか。人間承認をどこに置けるか。ログが追えるか。コスト上限を持てるか。別モデルや外部サービスとどう接続するか。
AIが一発回答から業務運転へ進むほど、価値は「賢い脳」から「安全に働かせる仕組み」へ分散する。
Agents APIはその象徴だ。
チャットボットのAPIではなく、AI労働のインフラAPIが始まっている。