OpenAI Agents API入門：AIエージェントを作る前に確認したいこと

まず結論：Agents APIで変わること

OpenAIは2026年9月10日、Agents APIの公開ベータを発表しました。Codexの背後で使われてきた長時間タスク向けのハーネスを、開発者がサービスとして利用できるようにするものです。エージェントループ、コンテキスト管理、ツールの調整、セッションの進行をすべて自作する代わりに、OpenAIへ実行基盤を任せ、エージェントに許可する能力を設計できます。OpenAIによれば、ベータ期間中にAgents APIの追加料金はありませんが、トークンとツールの通常料金は発生します。

ただし、管理されたAPIがすべての案件に合うわけではありません。重要なのは所有権です。独自ストレージ、アプリ側の承認、非公開の実行環境、決定的なオーケストレーションが必要なら、Agents SDKやResponses APIの方が適しています。反対に、ファイル、コード、ツール、サブエージェントを使う長い作業を安定して動かしたいなら、管理ハーネスは多くの基盤実装を省けます。

この発表がソフトウェア開発に与える意味

公式のAgents API発表は、オープンソースのCodexハーネスを基盤にしたクラウドエージェントを説明しています。OpenAIが基盤を運用し、開発者は公開された土台を確認しながら独自機能を接続できます。エージェントは、プロンプトを添えたモデル呼び出しではなく、進捗、ツール、コンテキスト、実行環境、失敗からの復旧を持つ実行システムになります。

OpenAIの資料では三つの入口が示されています。Agents APIの概要は、OpenAIがハーネスを管理し進捗を保存する長時間タスク向けです。Agents SDKはコード中心で、デプロイ、保存、ツール、承認をアプリケーションが管理します。Responses APIは、モデル呼び出しと独自オーケストレーションをより直接的に制御する方法です。

この比較はOpenAI以外の製品を選ぶときにも役立ちます。実際に問うべきなのは、誰が実行基盤を所有し、どこまで検査、交換、監査できるかです。

管理ハーネスが肩代わりする作業

本番エージェントには、良い指示だけでは足りません。ツール呼び出し後の継続、状態の保持、長いコンテキストの圧縮、専門エージェントの調整、ファイル処理、進捗表示が必要です。短いデモではこれらが隠れているため、実装量を小さく見積もりがちです。

Agents APIはこの運用層を提供する設計です。発表では長時間セッション、ツール、コンテキスト管理、中間結果、ファイルやコードを扱う環境が強調されています。現在の概要には自動コンテキスト圧縮、マルチエージェント、プログラムによるツール呼び出し、MCP、任意のサンドボックスも記載されています。

研究アシスタント、コード保守、データ分析、障害対応、社内業務を早く試したいチームには魅力的です。一方で、トークンとツールの費用、権限、データ境界、障害復旧、継続的な評価は残ります。

三つのAPIをどう使い分けるか

長時間動作し、ツールを使うエージェントの運用が課題なら Agents API を検討できます。Codex型の管理ハーネスを使える代わりに、実行基盤の細かな所有権は減ります。

アプリケーションがループと製品ロジックを持つ必要があるなら Agents SDK が合います。独自データベース、人による承認、専用のツールルーター、プライベートなデプロイ、TypeScriptやPythonへの密な統合に向いています。公式クイックスタートは、エージェントを定義して実行し、必要に応じてツール、ハンドオフ、ガードレール、トレースを追加する流れです。

リクエスト、状態、ツール呼び出し、独自の処理グラフを直接制御したいなら Responses API です。マルチエージェントのガイドでは、ルートエージェントが独立した作業をサブエージェントへ分け、アプリケーションが関数を実行して結果を返す方法が説明されています。

最初の失敗を想像すると選びやすくなります。長い作業で文脈が失われるなら管理セッションが役立ちます。機密ツールを誤って呼ぶことが問題なら、アプリ側のオーケストレーションが重要です。

サンドボックスはセキュリティ境界

ファイルを読み、コードを実行し、外部サービスへ接続できるエージェントは実用的ですが、同時にセキュリティ境界になります。アクセスできるデータ、コードの実行場所、許可するネットワーク先、秘密情報の扱い、想定外入力への対応を明文化してください。

OpenAIは管理サンドボックス、自社インフラ、パートナー、サンドボックスなしという選択肢を示しています。これは単なる設定項目ではありません。試作では広い権限を許せても、本番では最小権限、明確な承認、監査ログ、危険な操作を繰り返さない復旧策が必要です。

MCPとプログラムによるツール呼び出しは統合を簡単にしますが、権限範囲も広げます。最初は読み取り専用ツールに限定し、厳密なスキーマで曖昧な引数を拒否し、書き込みは承認後に行い、調査に必要な入出力を記録しましょう。

導入前の評価項目

1. 長時間の継続: タイムアウト、ツール失敗、コンテキスト圧縮から再開できるか。
2. ツールの規律: 必要なツールだけを正しい引数で呼び、停止条件を守るか。
3. 人の管理: 重要な操作を承認、拒否、編集、中断できるか。
4. データ処理: 保持、学習利用、暗号化、削除、地域処理が説明されているか。
5. 可観測性: トレース、サブエージェント、ツール、費用、結果を見られるか。
6. 費用制限: 予算、同時実行数、暴走ループを管理できるか。
7. 移行性: ベータの変更時に指示、ツール、状態、評価ケースを移せるか。
8. 品質の証拠: 印象的なデモではなく実タスクと回帰テストがあるか。

開発や生産性のソフトウェアを探すときは、BTTCソフトウェアディレクトリで候補を集め、実際のデータと権限に近い条件で試してください。ディレクトリは発見の入口であり、セキュリティ審査の代わりではありません。

今のAgents APIに向く仕事

複数ソースの調査、ワークスペースを使うコード作業、運用分析、長い社内ワークフローを素早く検証する用途に向いています。短く決定的な処理、規制の強い処理、通常のAPI呼び出しで十分な処理では利点が小さいかもしれません。

最初は一つの明確な仕事、少数のツール、見える予算、人による確認点に絞るのが安全です。独立した作業を並列化できるときだけサブエージェントを追加します。OpenAIの資料も、並列化は集中と速度を高める一方、トークンを増やし、依存関係のある手順では効果が薄いと説明しています。

導入を小さく始めるための設計

最初の実験では、エージェントに与える権限を仕事の目的に合わせて限定します。調査だけなら検索と読み取りだけにし、ファイルの更新や外部サービスへの送信は別の承認段階に分けます。ツールの説明文も自然言語だけに頼らず、入力形式、失敗時の意味、再試行できる条件、絶対に実行してはいけない条件を記述します。こうするとモデルの能力だけでなく、製品の境界もテストできます。

ログは成功した最終回答だけでなく、途中の判断とツールの入出力を追える形にします。長いタスクでは、どの情報が要約され、どの情報が削除されたかを確認できなければ、再現できない失敗が増えます。人間が介入した箇所、拒否された操作、費用、実行時間を同じ評価ケースに保存すると、ベータ版の更新前後を比較しやすくなります。

また、社内導入では「自律性が高いほど良い」と考えないことが重要です。問い合わせの分類や資料の下書きのように、誤りを人が簡単に確認できる仕事から始めます。送金、削除、契約変更、顧客への確定連絡のような操作は、エージェントが提案し、人が最終的に承認する流れを残します。これは速度を少し下げても、復旧コストを大幅に下げます。

実装前に決める運用ルール

エージェントを導入する前に、成功と失敗を人が判定できる形にします。たとえば調査エージェントなら、引用元の数、事実と推測の分離、更新日の表示、確認が必要な項目を合格条件として記録します。コードエージェントなら、テストの実行、変更ファイルの一覧、差分の確認、ロールバック手順を条件にします。自然な文章が返っただけでは、仕事が完了したとは判断しません。

ツールは能力の一覧ではなく、契約として設計します。引数の範囲、認証の境界、時間制限、再試行の回数、重複実行の扱いを明記し、読み取りと書き込みを分離します。書き込み操作には idempotency key や確認画面を用意すると、ネットワーク再試行が二重登録や二重送信につながる危険を減らせます。

人間の確認画面には、エージェントの短い結論だけでなく、変更対象、根拠、予想される影響、使ったツール、失敗した試行を表示します。承認者が内容を理解できなければ、承認ボタンは安全装置として機能しません。重要な業務では、承認を記録し、後から誰が何を見て判断したかを追跡できるようにします。

ベータ段階では、サービスの制限やAPIの挙動が変わる可能性もあります。固定した評価ケースを毎週実行し、成功率だけでなく遅延、費用、手動介入率、危険なツール呼び出しの数を比較します。性能が上がっても費用や監査可能性が悪化していれば、単純なアップグレードとは言えません。

よくある質問

Agents APIとAgents SDKは同じですか？

いいえ。Agents APIはOpenAIのサービス内で管理ハーネスを動かします。Agents SDKはアプリケーション内で動き、デプロイ、保存、ツール、承認をより細かく管理できます。

管理ハーネスを使えば評価は不要ですか？

不要にはなりません。実タスク、安全テスト、費用監視、回帰確認は引き続き必要です。

最初から複数のサブエージェントを使うべきですか？

通常は一つの限定されたエージェントから始めます。独立作業を並列化する価値がある場合だけ増やします。

公開ベータは無料ですか？

9月10日の発表では、ベータ中のAgents API追加料金はないとされています。ただしトークンとツールの費用は発生します。

まとめ

Agents APIはエージェント基盤をソフトウェア選択に変えました。管理ハーネス、アプリ内のAgents SDK、低レベルのResponses APIを、状態、ツール、承認、実行、観測、復旧の所有権で比較しましょう。重要なシステムにつなぐ前に、狭い仕事、厳しい権限、実データに近い評価、移行計画で検証してください。