OpenAI AgentKitとは？Agent Builder終了予定後の移行先・ChatKit・Agents SDKを解説【2026年8月版】

※最終更新：2026年8月7日。Agent BuilderとEvals platformの終了予定、ChatKitの提供状況、Agents SDK・Responses APIの役割、既存ワークフローの移行方法を確認・更新しました。

「AgentKitで作ったエージェントは、今後もそのまま使えるのか」

「これから社内向けAIエージェントを作るなら、Agent Builder、Agents SDK、Responses APIのどれを選べばいいのか」

2025年10月のDevDayで発表されたAgentKitは、AIエージェントの開発を、設計・画面・評価まで一続きで扱う構想として注目されました。ただし、発表時の中心だったAgent BuilderとEvals platformは、現在は移行期限を意識して扱う必要があります。

2026年8月時点で、Agent Builderは2026年11月30日に終了予定です。Evals platformも同日に終了予定で、10月31日には既存利用者向けに読み取り専用となる予定です。これから新規開発を始めるなら、Agent Builderの画面を前提にした手順ではなく、Agents SDK、Responses API、ChatKitをどう組み合わせるかから考えます。

この記事の要点

OpenAI AgentKitとは

AgentKitは、OpenAIが2025年10月6日に発表した、AIエージェントの構築、展開、改善を支えるツール群です。発表時のOpenAIの案内では、視覚的なワークフロー設計、チャットUIの組み込み、評価、データ接続をまとめて扱う構成として紹介されました。

当時のAgentKitは、主に次の要素で語られていました。

重要なのは、AgentKitという言葉だけで「今も同じ画面・同じ手順で作れる」とは言えないことです。発表当時の構成と、今から採るべき開発手段を分けて考えます。

Agent Builderは終了予定、ChatKitは継続

ChatKitの公式ガイドでは、Agent Builderは移行期間中に既存ユーザーが使えるものの、2026年11月30日に終了予定と案内されています。ChatKit自体は継続します。

そのため、既存のAgent Builderワークフローを持つ企業では移行の準備が必要です。新規案件では、Agent Builderのworkflow IDを中心に組む旧来の構成を選ばず、自社のサーバー側でエージェントを動かし、必要ならChatKitを表示層としてつなぐ設計を起点にします。

Evals platformも移行期限を確認する

OpenAIのEvalsガイドでは、Evals platformは2026年10月31日に読み取り専用となり、11月30日に終了予定と案内されています。

これは「エージェントの評価が不要になる」という意味ではありません。むしろ逆です。新しい環境でも、代表的な入力、期待する出力、失敗例、合否基準を持ち、更新時に比較する運用が必要です。評価の場所や道具が変わるので、評価データと判断基準を特定画面へ閉じ込めないことが大切です。

新規開発では何を選ぶか

今からエージェントを作る場合の中心は、Agents SDKかResponses APIです。どちらもOpenAI APIを使いますが、処理の流れを誰が管理するかが違います。

Agents SDKが向くケース

Agents SDKの公式ガイドでは、複数の専門担当へ振り分ける処理、ツールを何度か呼ぶ処理、承認待ちを挟む処理などをSDK側で扱えます。

たとえば社内問い合わせエージェントなら、質問を受けた後に、規程検索担当、顧客情報確認担当、返信文作成担当へ分けることがあります。各担当に異なる指示と利用可能なツールを渡し、最後に回答責任を持つ担当へ戻す構成です。

手作業で処理のループをすべて組むより、Agentの定義、ツール、handoff、ガードレール、セッションを一つの実装へまとめたい場合に向いています。

Responses APIが向くケース

Responses APIは、モデルへの入力、ツールの実行、結果の返却、次の応答を自社で組み立てます。

たとえば、問い合わせの種類ごとに必ず社内データベースを検索する、返金処理は人の承認を受けてからだけ実行する、複数の外部システムへ決まった順に書き込む、といった細かい制約をアプリ側で管理したい場合です。

自由度は高くなります。その分、ツールの呼び出し失敗、無限ループ、タイムアウト、承認待ち、会話履歴、監査ログまで実装側で扱う範囲が広がります。

APIの基本、Responses API、費用の考え方は、OpenAI API入門で先に確認すると全体像をつかみやすくなります。

ChatKitは画面を担う

ChatKitは、エージェントと利用者が会話する画面を自社サービスへ組み込むための仕組みです。エージェントの業務ルール、社内システムへの接続、権限判定までをChatKitだけで完結させるものではありません。

新規開発では、サーバー側にAgents SDKまたは独自のResponses API実装を置き、ChatKitはその会話UIとして接続する考え方が基本です。画面を早く作れることと、業務エージェントが安全に動くことは別の論点です。

既存のAgent Builderワークフローを移す方法

Agent Builderを使っている場合は、終了予定日まで待つのではなく、代表的なワークフローから移行テストを始めます。公式の移行ガイドでは、Agent BuilderからAgents SDKのコードをエクスポートし、Agents SDKまたはChatGPT Workspace Agentsへ移す方法が案内されています。

移行先は2つある

エクスポートは移行作業の出発点です。ワークフロー図がそのまま完全に変換されるわけではありません。公式も、フローの制御、トリガー、ツール、認証、権限をテストし、期待どおりに動くか確認するよう案内しています。

先に残すものを決める

画面を作り直す前に、次の情報を確保します。

• 何を入力すると、どの結果を返すエージェントなのか

• どのツールや社内データへ接続しているか

• 誰が使い、誰が管理するか

• どの操作に承認が必要か

• 正常な出力例と、失敗として扱う出力例

• 現在の利用回数、エラー、有人対応への切り替え条件

この情報がないまま画面やコードだけを移すと、動くようには見えても、以前と同じ業務品質を保てているか判断できません。

移行テストは代表ケースから始める

すべての利用パターンを一度に検証しようとすると、移行が止まりやすくなります。利用頻度が高いケース、間違えると影響が大きいケース、社内データへアクセスするケースを優先します。

エージェント開発で決めるべきこと

エージェントは、チャット画面を置くだけでは業務に定着しません。特に社内データへつなぐ場合は、業務の境界を先に決めます。

1．任せる判断と、人が承認する判断

最初から「何でもできるエージェント」を作ると、権限も評価も曖昧になります。

検索、要約、下書き、分類、候補抽出はエージェントへ任せやすい業務です。一方、発注、契約、金額変更、顧客への送信、個人情報の公開などは、実行前に人が確認する設計を基本にします。

2．接続するデータを絞る

便利そうだからと共有ドライブ全体を接続すると、答えの根拠も権限管理も崩れます。まずは部署、フォルダ、文書種別、更新責任者を限定します。

社内データを使うAIの設計は、社内AI（社内GPT・RAG）の作り方で詳しく扱っています。検索対象を増やす前に、データの正本、更新日、閲覧権限、回答で引用してよい範囲を確認してください。

3．最小権限で始める

エージェントに外部サービスへ書き込む力を与えるときは、読み取りと書き込みを分けます。書き込みも、下書き保存だけ許すのか、送信まで許すのか、対象の部署やシステムを限定するのかを決めます。

認証情報をプロンプトへ書かない、個人アカウントを共用しない、退職・異動時に権限を見直す、といった基本も必要です。生成AIの社内利用全体に関する確認は、生成AI・ChatGPTの情報漏洩リスクと対策も参照してください。

4．評価は公開後ではなく、公開前から始める

評価用データは、難しい仕組みから始めなくて構いません。代表的な質問、正しい回答例、避けたい回答例を表にします。

モデルやプロンプト、接続先を変えたら、同じテストデータで前後を比べます。評価は「精度が高いか」だけでなく、業務で使えない回答を早く見つけるための仕組みです。

▶️ サービス資料のダウンロード（資料請求）

費用は何で変わるか

AgentKitの名称だけで、固定料金を決めることはできません。費用は、選ぶモデル、会話量、ツール呼び出し、検索やファイル処理、データ保存、外部サービス、監視、開発と運用の人件費で変わります。

見積もりで最初に測るべきなのは、月間の利用者数よりも1回の処理の内訳です。1つの問い合わせで何回モデルを呼ぶのか、どのツールを何回使うのか、承認待ちや再試行がどれくらいあるのかを確認します。

たとえば「社内規程を検索して回答する」エージェントと、「複数の社内システムを横断し、最終的に顧客へ送信する」エージェントでは、必要なモデル利用量も、認証と承認の実装も大きく変わります。初期段階で固定の料金表を作るより、少数の利用者で実測し、採用された回答1件当たりの総コストを見る方が判断しやすくなります。

失敗しにくい始め方

1つ目．業務を一つに絞る

最初は、社内規程の検索、営業メモの整理、問い合わせ分類など、入力と期待する出力を定義しやすい業務を選びます。部門横断の万能アシスタントは、データ、権限、例外処理が増え、検証前に複雑になります。

2つ目．正解と失敗を集める

過去の問い合わせ、担当者が手作業で作った回答、差し戻された文面を集めます。これがプロンプトの材料であり、公開前のテストデータになります。

3つ目．読み取りだけで試す

初期は、検索、要約、分類、下書きに限定します。送信、登録、支払、削除のような変更操作は、出力を確認する運用が安定してから追加します。

4つ目．利用者の声とログを一緒に見る

利用回数だけでは、役立ったか分かりません。回答を採用したか、どこを修正したか、質問を諦めたか、有人対応へ渡したかを確認します。ログだけを見ても、業務上の背景は読み取れません。

5つ目．横展開は条件をそろえてから行う

最初の部署で、データの更新責任者、権限、評価セット、承認条件、問い合わせ窓口を決めます。その型を持たずに対象部署を増やすと、同じ不具合を広げることになります。

ChatGPTやAPIを配ったのに現場で使われない原因と定着の進め方は、ChatGPTを導入したのに社内で使われない7つの原因で整理しています。

導入・移行チェックリスト

• Agent Builderを使っている場合、終了予定日と対象ワークフローを把握している

• Agent Builderからエクスポートする前に、入力、出力、ツール、接続先、権限を記録している

• Agents SDKとResponses APIのどちらが自社の処理に合うか決めている

• ChatKitは画面、エージェント実装はサーバー側という役割を分けている

• エージェントに任せる業務と、人が承認する業務を分けている

• 接続するデータの範囲、更新責任者、閲覧権限を決めている

• 読み取り権限と書き込み権限を分けている

• 代表的な質問、正解例、失敗例をテストデータにしている

• 変更後に同じテストで品質を比較できる

• 失敗時の有人対応、停止、問い合わせ先を決めている

• モデル、ツール、接続先、運用工数を分けて費用を測る

よくある質問（FAQ）

Q. AgentKitはもう使えないのですか？

A. AgentKitという発表と、その構成要素すべてが同時に終了するわけではありません。Agent Builderは2026年11月30日に終了予定ですが、ChatKitは継続します。新規開発ではAgents SDKやResponses APIを中心に検討します。

Q. Agent Builderのワークフローは自動で移行できますか？

A. Agents SDKのコードをエクスポートできますが、すべての挙動が自動で完全移行するわけではありません。制御フロー、ツール、認証、権限、接続先を確認し、代表ケースでテストしてください。

Q. Agents SDKとResponses APIはどちらを選べばよいですか？

A. 専門担当への振り分け、繰り返すツール呼び出し、承認待ち、トレースをSDKに任せたいならAgents SDKが向きます。処理順や分岐を自社で細かく決めたいならResponses APIを選びます。

Q. ChatKitだけで社内エージェントを作れますか？

A. ChatKitは主に会話UIを担います。業務ルール、社内データ、認証、権限、承認は、サーバー側のエージェント実装と運用設計で扱います。

Q. Evals platformが終了すると評価できなくなりますか？

A. 評価の必要性は変わりません。代表質問、期待する回答、失敗例、合否基準を保ち、Datasetsなどの現行手段で継続して評価します。

Q. エージェントの費用はどのように見積もりますか？

A. モデル利用量、ツール呼び出し、外部サービス、ログ保管、開発・運用工数に分けます。少数の利用者で実測し、採用された回答1件当たりの総コストを見ると判断しやすくなります。

Q. 最初から複数部署へ展開してもよいですか？

A. まず1部署・1業務で、権限、評価、承認、障害時対応を固めます。同じ条件で運用できるようになってから対象を広げます。

Q. どの業務から始めるべきですか？

A. 検索、要約、分類、下書きのように、入力と期待出力を定義でき、人が最終確認できる業務から始めます。変更や金額、対外送信を伴う操作は後段に置きます。

AIエージェントを業務に定着させるために｜AIworkerの支援

エージェント開発で成果が分かれるのは、画面を作れるかではありません。業務のどこを任せるか、どのデータに接続するか、誰が確認するか、失敗したときにどう止めるかを決められているかです。

AIworkerでは、業務の棚卸し、PoC、評価、運用設計、必要に応じたエージェント開発まで支援します。最初から全社の情報をつなぐのではなく、1つの業務で回答品質と確認手順を作り、現場で回ることを確認してから広げます。

AIネイティブX研修｜現場で使える力を身につける

利用者側が、エージェントへ何を依頼し、どこを確認し、どう改善依頼を出すかを身につけます。単なるツール操作ではなく、業務で使える入力と判断の型を整えます。

AIネイティブX伴走｜定着とツール変更への対応力をつくる

実際の業務を見ながら、データ範囲、権限、承認、評価、ログ確認のルールを整えます。特定の製品機能が変わっても、業務の判断基準とテストデータが残る状態を目指します。

業務AIプロ｜自社業務に合ったAIを構築する

社内データ検索、問い合わせ対応、定型処理など、自社の業務に合わせたエージェントを構築します。権限と承認を含めて小さく実装し、品質と運用負荷を確かめながら対象を広げます。

「Agent Builderからの移行範囲を整理したい」「エージェントに任せる業務を選びたい」といった相談では、現在の業務フローと利用データを確認し、着手範囲を整理します。

最後まで読んでいただきありがとうございます。励みになりますので、参考になったらスキをお願いします。

▶️ サービス資料のダウンロード（資料請求）

▶️ 無料カウンセリング・AI活用診断のご予約