OpenAI「AgentKit」の現在と移行ガイド:Agent Builder終了前に確認すべきこと【2026年版】

close up photo of monitor
Photo by energepic.com on Pexels.com

OpenAIは2026年6月3日、Agent BuilderとEvalsプラットフォームの提供終了予定を発表しました。2026年9月5日時点では、Agent Builderは11月30日に終了予定です。Evalsは10月31日に既存評価が読み取り専用となり、ダッシュボードとAPIは11月30日に終了予定です。一方、ChatKitは継続します。期限は変更される可能性があるため、作業前にOpenAIの廃止予定一覧を確認してください。

そのため、現在の判断は「Agent Builderで新しく作るか」よりも、「既存ワークフローを何へ移し、同じ動作をどう検証するか」が中心です。この記事では、2025年の発表内容を短く振り返ったうえで、既存利用者が移行時に確認すべき項目を順番に整理します。

AgentKitとは何だったのか

AgentKitは単一のSDKではなく、OpenAIが2025年10月に発表した、エージェントの設計、組み込み、評価、改善を支える一群のツールです。発表時点では、視覚的にワークフローを組むAgent Builder、会話画面を製品へ組み込むChatKit、接続先を管理するConnector Registry、データセットやトレース採点を扱うEvalsなどが紹介されました。

当時の全体像は、2025年10月6日のOpenAI発表を整理した記事でも確認できます。ただし、現在は構成要素ごとに提供方針が分かれています。「AgentKitが使えるか」という一問ではなく、利用中の機能を一つずつ確認する必要があります。

現在の提供状況

機能 現在の位置づけ 利用者が確認すること
Agent Builder 廃止予定。2026年11月30日に終了予定 既存ワークフローの書き出しと移行先の決定
Evalsプラットフォーム 廃止予定。10月31日に既存評価が読み取り専用となり、11月30日にダッシュボードとAPIが終了予定 評価ケース、採点基準、結果履歴の退避と代替評価環境の準備
ChatKit 継続 Agent Builderのホスト型ワークフローに依存している場合は、独自のサーバー側実装へ接続し直す
Agents SDK コードで構築する移行先 書き出したコードを自社の実行環境で設定し、挙動を再検証する
ChatGPT Workspace Agents 自然言語で構築し、チームで共有する移行先 アプリへ組み込む必要があるか、チーム内利用で足りるかを判断する

提供状況の根拠は、更新されたAgentKit発表ページとAgent Builderの現行ドキュメントです。特にEvalsはAgent Builderと日程が一部異なるため、同じ締切だと考えないほうが安全です。

移行先は用途で選ぶ

製品や業務システムへ組み込むならAgents SDK

Agents SDKは、エージェント、ツール、処理の分岐をコードとして実装するための選択肢です。自社のアプリケーションで動かし、認証、データ接続、承認処理、監視を実装したい場合に向きます。OpenAIの移行ガイドでは、Agent Builderの画面からTypeScriptまたはPythonのコードを書き出し、Agents SDKで継続する手順が案内されています。

ただし、書き出しはワークフロー図をそのまま変換する機能ではなく、すべての動作を同じ状態で引き継ぐ保証もありません。接続先、環境変数、認証、例外処理、人の承認条件を見直し、移行前と同じテストケースで比較する必要があります。

チーム内で使うならWorkspace Agents

ChatGPT Workspace Agentsは、自然言語でエージェントを構築し、チームで共有する用途に向く移行先として案内されています。独自アプリへの埋め込みや細かな実行制御が必要ならAgents SDK、ChatGPT内での共同利用が目的ならWorkspace Agentsという切り分けが出発点になります。

会話画面を残すならChatKit

ChatKitは提供が継続されます。既存の画面を捨てる必要はありません。ただし、Agent Builderがホストするワークフローへ接続している構成は移行対象です。新規構築や移行では、ChatKitの現行ガイドが案内する独自サーバー連携を使い、サーバー側のエージェント実装へ接続します。

移行を進める6つの手順

  1. 利用箇所を棚卸しする
    ワークフローID、公開中の版、接続ツール、データの入出力、ChatKitとの接続、Evalsの評価セットを一覧にします。止まったときに影響する業務と担当者も対応づけます。
  2. 移行先を決める
    アプリへの組み込みとコード管理が必要ならAgents SDK、ChatGPT内のチーム利用が中心ならWorkspace Agentsを候補にします。ChatKitは画面、Agents SDKはサーバー側の処理というように、役割を分けて考えると判断しやすくなります。
  3. Agent Builderからコードを書き出す
    対象ワークフローを開き、上部の「Code」からAgents SDKを選び、TypeScriptまたはPythonの完全な書き出しを取得します。書き出した時点の版と日時を記録し、その後の変更と混ざらないようにします。
  4. 接続と制約を再実装する
    API認証、権限、タイムアウト、再試行、禁止操作、人への引き継ぎを確認します。画面上のノードがつながっているだけでは、本番環境の認証や障害時の処理まで再現されたとは限りません。
  5. 同じ評価ケースで差分を測る
    代表的な正常系だけでなく、入力不足、権限不足、接続先エラー、危険な依頼も試します。回答の正確さだけでなく、正しいツールを選んだか、禁止操作を止めたか、人へ引き継いだかを確認します。
  6. 段階的に切り替える
    検証環境で動かした後、一部の利用者や低リスク業務から切り替えます。旧構成を止める条件と切り戻す条件を先に決め、監視できる状態で移行します。

Evals終了前に残すもの

評価環境を変えても、これまでの改善材料は引き継げます。Evalsを利用している場合は、読み取り専用になる予定日の前に、次の情報を手元で再利用できる形に整理します。

  • テスト入力と期待する結果
  • 合否を判断する採点基準
  • 人が付けた注釈と誤答の分類
  • ツール呼び出しを含む実行記録
  • 版ごとの結果と、合格とする基準

評価ケースは件数だけを増やすより、実際に困った失敗を残すほうが役立ちます。たとえば、配送状況を答えるエージェントなら、「注文番号がない」「他人の注文番号が入力された」「配送APIが応答しない」といった境界条件を分けます。これにより、回答文の自然さと、業務として安全に完了できるかを別々に判定できます。

実務で使える設計例

用途 接続する対象 人へ戻す条件 評価する項目
問い合わせ対応 社内ナレッジ、受注、配送 本人確認ができない、返金判断が必要、根拠を取得できない 回答の正確さ、根拠の提示、引き継ぎの妥当性
調達と経費 商品台帳、見積、承認システム 金額や品目が規程外、承認者が不明、発注直前 項目抽出、承認経路、重複起票、禁止操作
開発支援 課題管理、リポジトリ、CI 本番変更、権限変更、テスト失敗、仕様が不明 課題と差分の対応、テスト結果、説明の再現性

この表は特定の製品機能を保証するものではなく、移行後にも残すべき業務要件の例です。ツールを替えても、誰が承認するか、どこで止めるか、何を合格とするかは消えません。生成AI導入全体の準備は、生成AIを業務に入れる前に決めるべきことでも整理しています。

安全性と運用で外せない確認

  • 最小権限:エージェントへ渡す権限を、読む、作る、更新する、削除するに分け、必要な操作だけを許可します。
  • 人の承認:支払い、返金、本番変更、アカウント停止など影響の大きい操作は、実行前に担当者が確認する設計にします。
  • 入力データ:個人情報や機密情報を扱う範囲、保存先、保持期間を決めます。
  • 攻撃への備え:外部文書やWebページに含まれる指示をそのまま実行しないよう、プロンプトインジェクションとデータ漏えいをテストします。
  • 観測:最終回答だけでなく、選んだツール、エラー、人への引き継ぎを追える記録を残します。

よくある質問

AgentKitそのものが11月30日にすべて使えなくなるのですか

すべての構成要素が同時に終了するわけではありません。Agent BuilderとEvalsプラットフォームは終了予定ですが、ChatKitは継続します。利用中の機能名と接続関係を分けて確認してください。

Agent Builderから書き出せば、そのまま移行できますか

そのまま同じ動作になる保証はありません。公式の移行ガイドも、書き出しがワークフロー図を変換するものではなく、すべての挙動を変わらず移す保証はないと説明しています。接続設定と例外処理を整え、回帰テストを行います。

ChatKitを使っている画面も作り直す必要がありますか

ChatKit自体は継続します。ただし、背後でAgent Builderのホスト型ワークフローを利用している場合は、独自のサーバー側実装へ接続し直す必要があります。

移行時にRFTを行うべきですか

最初に確認するのは、移行前の動作を再現できるかです。強化学習による微調整は別の改善手段であり、接続、権限、停止条件、評価ケースの再構築を代替しません。まず回帰テストを通し、その後に必要性を判断します。

移行判断のまとめ

既存のAgent Builder利用者は、終了予定日から逆算してコードを書き出し、Agents SDKまたはWorkspace Agentsへ移す準備を始める段階です。Evals利用者は、より早い10月31日の読み取り専用化を意識し、評価資産を先に整理します。ChatKitは継続できますが、背後のAgent Builder依存は解消します。

移行で守るべきものは製品名ではなく、業務の完了条件、権限、人の承認、評価ケースです。この四点を先に固定すれば、移行先の技術を選びやすくなり、切り替え後の不具合も見つけやすくなります。

公式情報

AgentKitの移行では、製品名に縛られず、業務フローと評価基準を整理し直す必要があります。株式会社greedenは、生成AIを用いた施策について、ツール選定から業務フロー改善、システム実装、定着支援まで伴走します。

投稿者 greeden

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)