OpenAIがPrompt・Evals・Agent Builderを11月30日終了、AI開発資産をコードへ戻す理由

OpenAIは2026年6月3日、再利用可能なPromptオブジェクト、Evalsプラットフォーム、Agent Builderの廃止予定を公表した。3つの機能はいずれも2026年11月30日に停止する。Evalsはそれより早い10月31日に既存評価が読み取り専用となる。

表面的には別々の製品終了だが、実務上は一つの問題として扱うべきである。PromptはAIの判断規則、Evalsは品質の測定基準、Agent Builderは実行手順を保持している。3つを同時に失うと、AIシステムの「仕様」「試験」「実装」がまとめて移行対象になる。

移行先を選ぶだけでは足りない。ダッシュボードに保存された暗黙知を、ソースコード、設定、データ、テスト、監査記録として再構成する必要がある。

終了スケジュール

最初の実務期限は11月30日ではなく、Evalsが読み取り専用になる10月31日である。評価定義や採点器の修正が必要な場合、この日以降は旧環境で調整できない。

三つの資産を分けて移行する

Promptは文章ではなく実行仕様

Promptオブジェクトには、単なる指示文以外の情報が含まれることがある。

• システムメッセージ
• 変数名と型
• few-shot例
• モデル指定
• 推論設定
• ツール説明
• 出力形式
• バージョン
• 作成者
• 利用環境

本文だけをコピーすると、変数展開、デフォルト値、モデル設定、出力制約が失われる可能性がある。

移行後は次のような構成が望ましい。

prompts/
  support-answer/
    prompt.md
    schema.json
    examples.jsonl
    config.yaml
    CHANGELOG.md

Prompt本文と実行設定を分離し、バージョン番号を付ける。モデルIDやAPIキーはPromptへ埋め込まず、環境別設定として管理する。

Evalsは品質判断の根拠

Evalsから移行すべきものは、入力例だけではない。

• 評価データセット
• 正解ラベル
• Graderの指示
• 採点関数
• 合格閾値
• モデル設定
• 実行結果
• 失敗例
• 比較対象
• 実行日時
• 担当者の判断メモ

評価結果の平均点だけを保存しても、後から再現できない。どのモデル、Prompt、データ、採点器を組み合わせた結果かを残す必要がある。

{
  "eval_id": "support-ja-v4",
  "dataset_sha": "...",
  "prompt_version": "2.3.1",
  "model": "...",
  "grader_version": "1.4.0",
  "threshold": 0.92,
  "run_at": "2026-07-12T11:00:00Z"
}

Agent Builderは実行グラフ

Agent Builderの画面をスクリーンショットで保存するだけでは移行できない。各ノードについて、次を抽出する。

• 入力と出力
• Prompt
• モデル
• ツール
• 接続先
• 認証方式
• 分岐条件
• リトライ
• タイムアウト
• 状態
• 人間承認
• ガードレール
• ログ
• エラー時の経路

見た目が同じフローでも、再試行や状態保持が異なれば挙動は変わる。移行先でノード数を再現するのではなく、業務上の不変条件を再現するべきである。

まず作るべき資産台帳

台帳の目的は数を数えることではない。Prompt、Eval、Agentの依存関係を追跡できるようにすることである。

Agent A
  -> Prompt support-answer v2.3
  -> Eval support-ja-v4
  -> Tool CRM-search
  -> Model policy production-default

この関係が分からないと、Prompt移行後にどの評価を再実行すべきか判断できない。

Prompt移行で必要な設計

ソース管理

PromptをGitへ保存し、変更理由をコミットに残す。レビューでは文章表現だけでなく、権限、データ送信、出力制約への影響を確認する。

テンプレート検証

変数の欠落、未使用変数、型の不一致、長すぎる入力をCIで検出する。

required: customer_name, issue_summary
optional: locale
forbidden: api_key, access_token

変更の影響範囲

Prompt更新時に自動で関連Evalを実行する。Promptだけを更新して本番へ反映する経路を作らない。

ロールバック

本番リクエストにPromptバージョンを記録し、問題発生時に旧バージョンへ戻せるようにする。モデルのレスポンスだけでは、どのPromptが原因だったか分からない。

Evals移行で失敗しやすい点

Graderの移植性を過大評価する

LLM-as-a-judgeは、使用する採点モデルが変わるとスコアも変わる。旧Evalsで0.9だったことと、新環境で0.9であることは同じ意味ではない。

移行時は、人手ラベル付きの固定セットを使い、旧Graderと新Graderの一致率、偽陽性、偽陰性を測る。

集計値だけを比較する

平均点が同じでも、重大な失敗が増えている可能性がある。セキュリティ、法務、個人情報、誤操作などは個別のゲートとして扱う。

総合品質: 92%以上
個人情報漏えい: 0件
無許可ツール実行: 0件
重大誤案内: 0件

評価データを本番ログから無制限に作る

本番ログには個人情報、秘密情報、契約上の制限が含まれる可能性がある。評価用に抽出する前に、利用目的、匿名化、保持期間、アクセス権を定義する。

旧実行履歴を捨てる

過去の評価結果は、新環境が同等かを判断する基準になる。少なくとも代表リリースの入力、出力、採点理由、設定を保存する。

Agent Builder移行の本質

Agent BuilderからAgents SDKへ移す場合、画面上のノードがコードになる。自由度は上がるが、責任も増える。

アプリケーション側で管理すべき要素は次の通りである。

• 状態遷移
• 同時実行
• 冪等性
• タイムアウト
• 再試行
• キャンセル
• 権限
• 監査
• コスト上限
• 人間承認
• モデル切り替え

特に重要なのはツール実行である。モデルが同じでも、ツールの引数検証、認可、重複実行防止が変われば、業務リスクは大きく変わる。

返金エージェントなら、次のような不変条件を仕様化する。

• 10万円超は必ず人間承認
• 同じ注文への返金は1回だけ
• 顧客IDと注文IDの一致を確認
• 実行前に金額と理由を表示
• 失敗時に自動再実行しない
• すべての判断とツール結果を記録

この不変条件をテストし、旧Agent Builderと新実装で比較する。

Agents SDKとWorkspace Agentsの選択

Agents SDKだけが移行先ではない。利用者が社内のChatGPT環境で作業し、公開APIや独自UIを必要としない場合は、ChatGPT Workspace Agentsが適する可能性がある。

移行先は技術の近さではなく、利用チャネルと統制要件で決める。

推奨する移行工程

第1段階: 直ちに書き出す

• 全Promptの本文と設定
• Evalsの定義、データ、Grader、結果
• Agent Builderの構成、ツール、分岐、権限
• 所有者と利用システム

停止直前まで待つ理由はない。エクスポート手段や権限が変更される可能性を考え、原本を早期に保全する。

第2段階: 正規化する

ダッシュボード固有IDを内部IDへ変換し、Git、オブジェクトストレージ、データベースへ配置する。

openai_prompt_abc123 -> support-answer@2.3.1
openai_eval_xyz789 -> support-ja-v4
agent_builder_flow_456 -> refund-agent@1.0.0

第3段階: 移行先を再構築する

Promptはコード、EvalsはPromptfoo等、AgentはAgents SDKまたはWorkspace Agentsへ移す。3つを独立プロジェクトにせず、共通のバージョンとリリース手順で結ぶ。

第4段階: 並行評価する

同じ入力を旧環境と新環境へ送り、次を比較する。

• 最終回答
• ツール選択
• 引数
• 実行回数
• レイテンシー
• コスト
• エラー率
• 人間承認率
• Grader結果

外部への副作用があるツールは、シャドー環境で実行するかモックへ置き換える。

第5段階: 本番を段階移行する

内部利用者、低リスク業務、一部トラフィックの順で移す。旧環境へ戻す期限を、Evals読み取り専用日の前に設定する。

よくある誤判断

Prompt本文をコピーすれば完了

変数、モデル設定、ツール、出力スキーマ、バージョンが抜ける。Promptは実行仕様として移行する。

Evalsは後で再作成できる

過去の入力、採点理由、閾値が失われると、同等性を証明できない。10月31日より前に確定する必要がある。

Agent Builderの画面を同じ形で再現する

必要なのは見た目ではなく、状態、権限、副作用、失敗時動作の再現である。

一度のテストで移行を判断する

確率的なAIシステムでは、複数回実行、境界例、障害注入が必要である。

3つを別々の担当へ分ける

Prompt変更がEvalとAgent挙動へ影響する。共通のリリース責任者と依存関係管理が必要である。

編集部分析

今回の同時終了は、AI開発の重要資産をベンダーのダッシュボード内だけで管理するリスクを示している。

従来のソフトウェア開発では、コード、テスト、設定はリポジトリへ保存する。一方、生成AI導入では、Promptは画面、評価は別サービス、エージェントはビジュアルビルダーへ分散しやすい。結果として、リリースされたシステムの完全な仕様がどこにも存在しない状態が生まれる。

移行後に目指すべきなのは、すべてを自社実装することではない。外部サービスを使いながらも、再構築に必要な原本を自社で保持することである。

Prompt、評価データ、ワークフローの定義を移植可能にしておけば、モデルや実行基盤を変更しても比較できる。逆に、これらが特定ダッシュボードにしか存在しない場合、製品終了のたびに設計意図から作り直すことになる。

また、Evalsの終了を単なるツール移行として扱うべきではない。評価基盤はAI変更管理の中核である。モデル、Prompt、ツール、データのどれかを変えたときに、自動で品質と安全性を再確認できる仕組みへ変えるべきである。

この移行を正しく行えば、11月30日の停止対応だけでなく、将来のモデル変更、料金変更、規約変更にも耐えやすい開発基盤になる。

実務チェックリスト

• [ ] すべてのReusable Promptを列挙した
• [ ] Prompt本文、変数、設定、例、所有者を書き出した
• [ ] PromptをGitでバージョン管理した
• [ ] Prompt変更時に関連Evalが自動実行される
• [ ] すべてのEval定義とデータを保存した
• [ ] Grader、閾値、過去結果を保存した
• [ ] 重大リスクを平均点とは別のゲートにした
• [ ] Agent Builderの全フローを列挙した
• [ ] 各ノード、ツール、分岐、権限を仕様化した
• [ ] 副作用のあるツールに冪等性と承認を設けた
• [ ] Agents SDKとWorkspace Agentsを要件で比較した
• [ ] 新旧環境を同一入力で並行評価した
• [ ] 2026年10月31日より前にEvals移行版を確定した
• [ ] 2026年11月30日より前に本番切り替えを完了した

一次情報

• OpenAI API deprecations
• Migrate from prompt objects
• Moving from OpenAI Evals to Promptfoo
• Migrate from Agent Builder