OpenAI AgentKitの終了対象と移行ガイド：停止日までにやること

OpenAI AgentKitは、エージェントの構築・デプロイ・評価に使うツール群でした。その構成要素であるAgent Builderは、2026年11月30日にサービスを終了する予定です。Agents SDKとChatKitは引き続き利用できますが、Agent Builderをバックエンドに使うChatKitアプリには、自前の代替バックエンドが必要になります。既存の評価は10月31日に読み取り専用となり、その後11月30日にEvalsのダッシュボードとAPI、再利用可能なプロンプトオブジェクトを扱うv1/prompts APIが終了する予定です。

2026年10月14日時点のOpenAI公式ドキュメントで確認済みです。 移行で守るべきものは、ワークフロー、そのプロンプト、そして正しく動くことを確かめるテストです。それぞれを独立した移行タスクとして扱い、担当者を決めましょう。日程の根拠はOpenAIの廃止スケジュールです。本記事のチェックリストでは、その日程を具体的な作業の節目に落とし込みます。

OpenAI AgentKitでは何が終了し、何が残るのか

ホスト型のビルダーは終了しますが、OpenAIのエージェント開発基盤は継続します。 AgentKitは、エージェントの構築・デプロイ・評価に使うツールをまとめたものでした。OpenAI Agent Builderがビジュアルなワークフローエディターを、ChatKitが埋め込み用のチャット画面を、Evalsがテスト環境を提供していました。移行では、これらを個別に扱う必要があります。

設備のそろった作業場をイメージすると分かりやすいでしょう。作業場が編集や実行の環境を提供し、ワークフローはそこで行う仕事の内容を定めています。作業場がなくなれば、別の場所で仕事を続ける必要があります。使っていたツールをすべて捨てたり、モデルの提供元を変えたりする必要はありません。

終了日はOpenAIの廃止予定ページ、継続する実行環境の選択肢はエージェントの概要に記載されています。これらの告知は2026年6月3日に公開されました。10月の読み取り専用化と11月のサービス終了は、別の節目です。

今回の告知でResponses APIが廃止されるわけではありません。 ただし、リクエストで再利用可能なプロンプトオブジェクトを参照しているResponsesアプリは影響を受ける可能性があります。呼び出すエンドポイントと、その処理が依存する保存済みリソースは分けて考える必要があります。

今すぐ対応が必要なのは誰か

稼働中のワークフローがAgent Builder、マネージドのEvals、保存済みプロンプトオブジェクトのいずれかに依存していれば、今から対応が必要です。 移行先は製品名の似ているものを選ぶのではなく、その仕事をどこで動かすべきかで判断します。

顧客向けアプリの開発者： ワークフローをエクスポートし、実行環境の担当者を決めます。自社製品に組み込むサポートチャットボットには、ホスト型ワークフローの終了後も動くアプリケーションサービスが必要です。画面だけを移しても、肝心の依存関係は解消しません。

社内業務の運用担当者： その仕事を社内のChatGPTワークスペース内で完結できるなら、ChatGPT Workspace Agentsを検討します。公開Webサイトへの組み込みよりも、定期的な顧客概要の作成や社内向けリサーチアシスタントに適しています。業務の責任者が出力の内容を、ワークスペース管理者がアクセス権を確認する体制にしましょう。

これから導入する発注担当者： 今の段階で、今後も利用できる構成を選びます。Agent Builderを前提とした提案をベンダーから受けているなら、実装を承認する前に、終了後の実行環境、移行の成果物、受け入れ基準を確認しましょう。移行期間中にデモが動くことだけでは、これらの問いへの答えになりません。

すでにSDKやResponsesを直接利用している場合： Builderからの移行自体が不要な可能性もあります。ただし、アプリに影響がないと判断する前に、評価パイプラインと保存済みプロンプトへの参照を確認してください。それらへの依存もなければ、今回の告知だけを理由にアプリを書き直す必要はありません。

Agent BuilderのワークフローをAgents SDKへ移行する

OpenAI Agent Builderからはワークフローのコードをエクスポートでき、自分たちで運用するアプリケーションの出発点にできます。 現行の移行ガイドでは、PythonとTypeScriptでのエクスポートが案内されています。変更を加える前にエクスポート一式を保存しておけば、後から元の内容と比較できます。移行手順。

1. 1

   エクスポートしたワークフローを保存する

   ワークフローを開き、上部ナビゲーションのCodeからAgents SDKを選び、PythonまたはTypeScriptを選択します。エクスポート内容をすべてリポジトリにコピーし、どのデプロイ済みワークフローを置き換えるものか記録します。

2. 2

   アプリケーションを実行できる状態にする

   選んだ言語に対応するSDKを、現行のクイックスタートに沿ってインストール・設定します。ワークフローが必要とするツールと認証情報を接続します。代替サービスとして扱う前に、デプロイ、ストレージ、実行環境それぞれの担当を明確にしてください。

3. 3

   業務上必要な動作を検証する

   代表的な入力を代替実装に与え、選択される分岐、ツールに渡す引数、承認の動作、最終結果を確認します。ワークフローの受け入れ基準を満たしてからデプロイします。

OpenAI Agents SDKはエージェントの実行ループを担い、デプロイ、ストレージ、ツール、承認はアプリケーション側で管理できます。 継続して実装の参考にする資料は、SDKの概要です。

SDKを選ぶ際の課題は、運用責任を引き受けることです。ファイルをコピーしただけでは、本番デプロイ、再起動時の動作、状態の永続化は用意されません。サポート業務のワークフローなら、注文照会がタイムアウトした場合、承認が却下された場合、同じリクエストが再び届いた場合の動作を定義しましょう。これらは実装して検証すべき受け入れテストの項目であり、エクスポートボタンが保証するものではありません。

実行環境の運用を誰に任せるかも見直すなら、OpenAI Agents APIとAgents SDKの比較を参考にしてください。OpenAIの現行Builder移行ガイドが挙げる移行先は、SDKとWorkspace Agentsです。別のマネージド実行環境であるAgents APIへ、自動的にインポートできるとは考えないでください。

ノーコードの社内業務をChatGPT Workspace Agentsへ移す

ChatGPT Workspace Agentsは、自然言語で組み立てたワークフローをチーム内で共有するために、公式ドキュメントで案内されている移行先です。 OpenAIの移行ガイドでは、エージェントへのアクセスと作成権限があるBusiness、Enterprise、Eduのいずれかのワークスペースが必要とされています。Builderのワークフローをエクスポートし、そのコードをワークスペースのエージェントビルダーに貼り付け、ワークフローの再作成を依頼します。ワークスペースへの移行要件。

OpenAIのワークスペースエージェントの解説では、接続済みアプリ、再利用可能な指示、スケジュール実行、ワークスペース内の共有という運用形態が示されています。完成した内容を担当者が確認できる、社内向けの顧客概要作成ワークフローに適した形です。

注意すべき制約は、元の動作を忠実に再現できるかどうかです。OpenAIは、同じ条件では必ず指定された同じ経路をたどるといった、強い決定性を求めるワークフローは、忠実に移行できない可能性があると警告しています。接続先と権限を確認し、代表的な入力でPreviewを試し、検証後にCreateを選びます。これはワークフローを再作成する手順であり、すべてのノードや接続がそのまま変換される保証ではありません。

たとえば、社内向けリサーチアシスタントなら、最終的なレポートが要件を満たす限り、調査経路が変わっても許容できる場合があります。一方、顧客レコードを変更する前に必ず承認を得なければならないワークフローでは、その条件が守られるかを明示的に検証する必要があります。厳密な分岐が業務の前提なら、そのロジックはアプリケーションコードに残し、まずSDKによる移行を検証することを勧めます。

ChatKitは継続し、ホスト型バックエンドを置き換える

ChatKitはチャットのフロントエンドとして引き続き使えますが、その背後で動く代替サーバーはアプリケーション側で用意する必要があります。 OpenAIは、新規プロジェクトと既存のBuilderを使うアプリに、自前のサーバーとの統合を案内しています。既存のホスト型ワークフローがサポートされるのは、移行期間中のみです。ChatKitの移行案内。

変わるのは、チャット画面の裏側の処理です。今後の構成では、ブラウザーが自分たちのChatKitサーバーへリクエストを送り、そのサーバーがエージェントの実装とツールを実行し、結果を画面に返します。見た目を維持しても、従来のホスト型環境での実行経路まで維持されるわけではありません。

高度な統合ガイドでは、実装に必要な要素として、ChatKitServer、HTTPエンドポイント、本番のスレッドとメッセージを永続化するストレージ、アップロードに対応する場合のファイルストア、ユーザーの識別と権限を扱うサーバーコンテキストが挙げられています。Agents SDKとの接続方法も用意されています。

カスタマーサポート用アプリの受け入れ確認は、返答が届くかどうかだけでは足りません。ログイン中の顧客が意図された会話だけを閲覧できること、必要な場面で添付ファイルを引き続き利用できること、許可されたツールが実行されること、エスカレーションが適切な宛先に届くことを確認します。既存の会話履歴をどう扱うかも計画してください。ワークフローのエクスポートに履歴まで含まれると思い込まないことです。

ChatKitでチャットボットを構築するガイドでは、製品として担うべき責任をより広く扱っています。今回の移行で判断の決め手になるのは、想定したアクセス制御と操作ルールを守りながら、代替バックエンドを通じて実際の会話を完了できるかどうかです。

期限から逆算する移行チェックリスト

まず評価の基準となるデータを保存し、サービス終了までに実行環境とプロンプトを移します。 ここでいう評価の基準とは、代替実装が正しく動くかを判断するための入力例と、許容できる結果の組み合わせです。これがなければ、コードを移せても、利用者が頼りにしていた動作を失うおそれがあります。

2026年10月31日まで：評価データを取り出して保存する

今のうちに評価の担当者を決めます。テスト入力、期待する結果、評価器の定義、プロンプトのバージョン、モデル設定、現在の動作を理解するために重要な既存の評価結果を保存してください。今のワークフローでエクスポートできるものは取り出し、エクスポート機能がないものは設定をコピーして、プラットフォームの外で再作成します。

10月31日は読み取り専用になる日であり、公式に示されたエクスポートの最終期限ではありません。 本記事では、移行中に使える評価基準を確保するため、それまでにバックアップを終えることをプロジェクトの目標として勧めています。

OpenAIのEvals移行ガイドはPromptfooを推奨し、プロンプト、プロバイダー、テストケース、アサーションを手動で再作成する手順を説明しています。OpenAI Evalsのエクスポート機能を前提とする手順ではありません。再作成した評価器は、スコアを判断材料に使う前に再実行して検証してください。OpenAIも、システムが変わると採点結果が異なる可能性を指摘しています。

引き継ぐべき成果物は、実行できる評価スイートと、何を失敗と判定するかの説明です。過去のスコアのスクリーンショットは参考履歴にはなりますが、評価スイートの代わりにはなりません。

2026年11月30日まで：ワークフローとプロンプトオブジェクトを移す

予定されているサービス終了までに、次の作業を完了させます。

• エクスポートしたSDKのワークフローをデプロイするか、代替となるWorkspace Agentを検証して作成します。
• Agent Builderをバックエンドに使うChatKitアプリを、すべて代替サーバーへ移します。
• 再利用可能なプロンプトの内容を、マネージドのプロンプトオブジェクトから取り出します。
• 代替の評価プロセスを実行し、動作の変化を調べます。
• 終了するサービスへの本番環境の依存を解消し、新しい運用の担当者を決めます。

プロンプトオブジェクトへの参照は、アプリケーション内を別途検索して確認する必要があります。 ワークフローが正常に動いていても、別の機能が保存済みプロンプトIDに依存している場合があるからです。OpenAIのプロンプト移行ガイドでは、プロンプト本文をソースコードへ移し、変数を関数の引数に置き換え、生成したメッセージをマネージドのpromptオブジェクトではなくResponses APIのinputに渡します。プロンプトはアプリケーションと一緒にバージョン管理し、可能な範囲で、動的な値より前に共通の固定プレフィックスを保ちましょう。

請求業務のアシスタントなら、引き継ぐ成果物は指示一式、変数の置換内容、代表的なケースに対する期待する応答です。画面に見えている文章だけをコピーして変数を落としたり、保存済みの別バージョンを選んでしまったりすれば、移行は不完全です。

テストが失敗した場合に調査する余裕を残し、ベンダーの期限より前に自分たちの切り替え日を設定します。残りの移行期間中に使える代替手順も文書化しておきましょう。ただし、終了するサービスに依存した代替手順では、サービス終了後の問題には対応できません。

過大評価や誤解を避けるための注意点

「AgentKitが終了する」という表現だけでは、エンジニアリング上の判断には大ざっぱすぎます。 告知は製品と保存済みリソースを具体的に挙げています。SDK、ChatKit、Responses API、そして別の選択肢であるAgents APIのドキュメントは引き続き提供されており、移行が必要なのは対象となるホスト型サービスです。

エクスポートできても、同じ動作を再現できた証明にはなりません。 生成された代替実装がもっともらしい回答を返しながら、承認を必要とする分岐を飛ばしてしまうこともあり得ます。新しい図やコードが見慣れた形かどうかではなく、実際の動作を元の要件と照らし合わせてください。

ChatKitの継続は、Builderのホスティング継続を意味しません。 画面を維持しながら、処理を担うサービスを変更できます。フロントエンドの新設が必要だと決めつけず、変更後にエンジニアが担う運用も含めて予算を考えましょう。

Evalsが終了しても、評価の必要性はなくなりません。 変わるのは、テストを維持する責任の所在です。同様に、プロンプトをコードへ移してもResponses APIが終了するわけではありません。アプリケーションからAPIへ指示を渡す方法が変わります。

今のAgentKitについてよくある質問

OpenAI AgentKitは無料で使えますか？

AgentKitを単一の無料製品だと考えて、移行計画を立てないでください。まず今後も使える実行環境を選び、そのうえでモデル、ツール、インフラの現行料金を確認します。終了告知から、すべての移行に共通する費用が分かるわけではありません。

OpenAIのエージェントはどう使えばよいですか？

既存のAgent Builderワークフローは、Agents SDKへエクスポートするか、Workspace Agentとして再作成します。新規アプリでは、現在利用できる実行環境を選び、業務に必要なツールと権限をテストしてください。ChatKitの画面を使う場合も、サーバー側の実装が必要です。

OpenAIのエージェントでは何ができますか？

エージェントはツールを使い、複数の手順にわたるタスクを進められます。移行では、社内向けレポートの作成や認証済みユーザーからのサポート依頼への回答など、すでに業務で使っている具体的な仕事を出発点にします。その仕事に必要な動作を、新しい実行環境でも維持することが大切です。

まず着手すべきこと

移行の責任者を決め、稼働中の代表的なワークフローを選びます。 エクスポート、プロンプトの内容、評価の基準を保存し、代替実装を最初から最後まで動かしてください。その結果を使って、残りの移行対象の作業量を見積もります。最初の成果物は、必要な権限と期待する結果を満たしながら、実際の業務を完了できるという証拠です。その後で、残りを移すための日程入りの計画をまとめます。

AIワークフローの構築・運用に役立つ最新情報は、ニュースレターでお届けしています。