「PoC で動いたエージェントを本番に載せたら、謎のエラーで止まる・メモリが汚染される・暴走するの 3 連発で止まった」——この典型パターンに対する回答として、OpenAI が Agents SDK のアップデート（4 月 16 日）でサンドボックス実行とメモリ制御を追加しました。
これまで受託で手作りしていた「本番で壊れないエージェント」の設計ピースが、SDK 側に寄ってきた格好です。本記事では、v2 で増えた 2 つの機能をどう使い、受託案件のスコープをどう組み直すかを整理します。
何が変わったか
OpenAI Agents SDK v2 での主要な追加は 3 点です。
- サンドボックス実行環境：ツール呼び出しと生成コードを隔離環境で実行できる
- 階層化メモリ：短期 / 長期 / セッション共有の 3 層で状態を管理
- 失敗時リプレイ：途中で失敗したセッションを、直前の安全状態からやり直せる
これまで Claude Code ルーチン や 私たちが整理した「次世代エージェントの harness」 のなかで、受託側がフレームワークを自作して補っていた領域です。SDK の標準機能に寄ったことで、自作コードの保守負担が減り、受託案件の利益率が上がるという副次効果があります。
サンドボックスの実装パターン
最小構成
from openai_agents import Agent, Sandbox
sandbox = Sandbox(
network="egress-deny", # 外部通信はホワイトリストのみ
fs="ephemeral", # ファイルシステムはセッション終了で破棄
cpu_limit="500m",
memory_limit="1Gi",
timeout=30,
)
agent = Agent(
name="invoice-processor",
tools=[query_db, send_email],
sandbox=sandbox,
)ネットワーク egress をデフォルトで閉じ、必要な外部通信だけを個別に許可するのが定石です。Firebase キーが露出して 13 時間で 54,000 ユーロ吹き飛んだ事件 のような事故は、この egress 制御で 9 割防げます。
権限分離の 3 階層
本番運用では、サンドボックスを権限別に 3 階層で切ります。
| 層 | 権限 | 用途 |
|---|---|---|
| Read-only | DB 読み取り・外部 API 読み取り | ダッシュボード生成・集計 |
| Write-guarded | DB 書き込み（HITL 必須） | 受注処理・ステータス更新 |
| Privileged | 送金・対外送信 | 監督者承認 + 監査ログ必須 |
3 層を跨いだ呼び出しは SDK が拒否するので、プロンプトインジェクションで権限昇格させようとする試みも自然に止まります。
メモリ制御の 3 層設計
v2 の階層化メモリは、次のように使い分けます。
| メモリ種別 | 保持期間 | 用途 | 例 |
|---|---|---|---|
| Short-term | 1 セッション | 会話の流れを保つ | 「さっきの顧客」「その次」 |
| Long-term | ユーザー単位で永続 | 個人の好み・過去対応履歴 | 「金額は税込で表示」「担当 CS は田中」 |
| Shared | チーム単位で共有 | 業務ナレッジ・FAQ | 「この製品のリコール手順」 |
設計ミスで多いのが、Long-term に個人情報を入れすぎるケースです。電話番号・メールアドレスなどは Long-term に保存せず、実行時に MCP 経由で取得する設計にします。
メモリ汚染を防ぐ 3 つの原則
- 書き込みゲート：ユーザー発言をそのまま Long-term に入れず、要約と信頼度スコアで篩にかける
- TTL 設定：古い情報は自動失効（顧客情報は 90 日 / 業務ナレッジは 1 年など）
- 監査可能化：どの発言がどのメモリに入ったかを追跡できるログを残す
この 3 つは、PoC では省略されがちで、本番投入 2〜3 ヶ月目に「なぜか AI が変な回答をする」事象として表面化します。
失敗時リプレイで SRE コストを下げる
v2 では、エージェントの実行履歴が「チェックポイント」として残り、失敗時は直前の安全点からやり直せます。従来は冪等性を自力で確保する実装が必要でしたが、SDK 側の機構に寄せられる範囲が広がりました。
try:
result = agent.run(task, checkpoint=True)
except SandboxError as e:
# 直前の安全状態からリプレイ
result = agent.resume_from_last_checkpoint(task)このリプレイ機構を使うと、夜間バッチで失敗したセッションを翌朝に再実行するオペレーションが、運用担当の手作業から1 コマンドに縮みます。私たちが Langfuse による AI 開発の観測基盤 で書いた、観測 → リプレイ → 再発防止のループがようやく現実的になります。
受託スコープの更新
Agents SDK v2 の登場で、受託案件のスコープは次のように変わります。
| 案件の型 | 期間（旧） | 期間（v2 採用） | 単価帯 |
|---|---|---|---|
| エージェント PoC | 6〜8 週 | 4〜6 週 | 250〜450 万円 |
| 本番運用への移行 | 3〜5 ヶ月 | 2〜3 ヶ月 | 800〜1,500 万円 |
| SRE 運用伴走 | 月額 60〜150 万円 | 月額 40〜100 万円 | — |
サンドボックスとメモリ制御の自作コードが消えるぶん、PoC → 本番の期間が 2〜4 週間短縮され、結果として顧客の年間支払も下がります。これは受託として一時的に単価を下げる代わりに、より多くの案件を同じ体制で捌けることを意味し、ポートフォリオ全体では有利に働きます。
導入の前提チェック
v2 を採用する前に、次の 4 点を確認します。
- 既存エージェントが OpenAI API / Azure OpenAI を使っている
- 本番化前の PoC 段階、または本番化後の大規模リファクタ期にある
- 社内にサンドボックス運用（コンテナ・監査ログ）の素地がある
- 個人情報 / 決済系の処理が含まれる（= 安全性投資の ROI が出る）
4 点のうち 3 点以上該当すれば、v2 移行は投資回収しやすいフェーズです。
まとめ — 「自作の harness」は SDK に寄せる
受託でエージェントを組むとき、自作 harness のコード量が受託側の保守負担として年単位で効いてきました。v2 はこの負担をベンダー側に押し返す転換点です。私たちは今後、サンドボックス・メモリ制御・リプレイをSDK 標準に寄せ、自作は本当にドメイン特化した部分だけに限定する方針に切り替えます。
弊社では、Agents SDK v2 への移行設計、サンドボックス・メモリ設計、SRE 運用伴走を受託で提供しています。「PoC は動くが本番化で詰まっている」「自作フレームワークの保守が重い」というご相談は、お問い合わせフォーム からお気軽にどうぞ。
