
AIのゴールポストは毎週のように動いているように感じます。少し前まで、私たちはまともな会話ができるチャットボットに慣れ始めたばかりでした。今や、議論は実際に物事を実行し、タスクを計画し、ツールを使い、複雑なプロジェクトを自力で完遂できるAIエージェントへと一気に進んでいます。
OpenAIはこの変化の真っただ中にいます。最近発表されたAgentKitは、旧来のAssistants APIを置き換える予定であり、これは非常に大きな出来事です。
これは開発者向けのニッチなアップデートのように聞こえるかもしれませんが、企業、特にカスタマーサポートチームが自動化について考える方法に大きな波及効果をもたらします。すべては一つの問いに集約されます。AgentKitとAssistants APIの現実世界での違いは何であり、この変更は実際に時間とコストを節約できるものを構築しようとしている人にとって何を意味するのでしょうか?
詳しく見ていきましょう。
OpenAI Assistants APIとは何だったのか?
Assistants APIは、開発者が会話を記憶し、ツールを使用できるAIアプリケーションを構築するのを支援するためのOpenAIの最初の本格的な試みでした。これは、単純なQ&Aボットよりも高性能なものを作成するための基盤でした。その主な機能は、AIに記憶を持たせるための会話履歴を処理する「スレッド」と、AIが行動を起こせるようにする「ツール」(コードインタープリターや関数呼び出しなど)でした。
確かに強力でしたが、同時に扱うのが非常に面倒でした。
Assistants APIで何か便利なものを構築するには、コードを多用するプロジェクトになりました。開発者は、異なる部分を接続し、エージェントの動作を管理し、ツールからの出力を処理するためだけに、大量の「グルーコード」を書かなければなりませんでした。それはまるで、ラベルのない部品の箱から自動車のエンジンを組み立てようとするようなものでした。複雑で、遅く、フラストレーションがたまるものでした。
その開発者からのフィードバックに基づき、OpenAIはAssistants APIを非推奨にすると発表し、2026年半ばまでに完全に廃止する計画です。これにより、Assistants APIが引き起こしたまさにその頭痛の種を解決するために設計された、全く新しいアプローチであるAgentKitへの道が開かれました。
OpenAIのAgentKitとは何か?
AgentKitは、単に古いAPIの新しい名前ではありません。エージェントを構築するプロセス全体を簡素化することを目的とした、本格的なツールキットです。Assistants APIが原材料を提供したとすれば、AgentKitは作業場全体を提供するように設計されています。これは、誰もが足踏みしていた複雑さに対するOpenAIの答えです。
それはいくつかの重要なアイデアに基づいて構築されています:
-
Agent Builder: 何行ものコードを書くことなく、コンポーネントをドラッグ&ドロップしてエージェントのワークフローを設計、テスト、調整できるビジュアルキャンバス。
-
Connector Registry: エージェントが必要とする可能性のある他のアプリやデータソース(Google DriveやSharePointなど)への安全な接続を管理するための中央の場所。
-
ChatKit: ユーザー向けのフロントエンドを迅速に立ち上げるために埋め込むことができる、あらかじめ構築されたチャットUIコンポーネントのセット。
-
Evals & Guardrails: エージェントのパフォーマンスをテストし、プロンプトを微調整し、暴走を防ぐための安全ルールを追加するための組み込みツール。
目的は明らかです。かつて何ヶ月もかかった骨の折れる開発プロジェクトを、数日で出荷できる可能性のあるものに変えることです。目標は、エージェント型AIをよりアクセスしやすくすることです。
AgentKitとAssistants APIの文脈でOpenAI AgentKitの価格体系を理解するために、Agent Builder、ChatKit、Evals、Connectorsの関係を示す図。
主な違い:AgentKit vs Assistants API
詳しく見ると、Assistants APIからAgentKitへの移行は、単なる機能のアップデート以上のものであり、全く新しい考え方です。本当に重要な分野で両者を比較してみましょう。
使いやすさと導入までのスピード
最も顕著な違いは、コードファーストからビジュアルファーストへのアプローチの転換です。Assistants APIでは、エージェントのロジックのすべてのステップをPythonやJavaScriptで書き出す必要がありました。AgentKitのビジュアルなAgent Builderでは、キャンバス上でノードを接続することでそのフローをマッピングでき、より多くの人が始めやすくなることは間違いありません。
しかし、「簡単になった」からといって、突然楽になったわけではありません。
AgentKitは依然として開発者向けのツールです。ワークフローを管理し、カスタムツールを接続し、必然的に壊れたときに何が問題だったのかを突き止めるには、技術的なノウハウが必要です。一部の初期ユーザーは、エージェントの実行を監視するのがまだ少し不便であると指摘しており、1つのステップが何をしたかを確認するためだけに異なる画面間を移動しなければなりません。信頼性の高いエージェントを構築するという中核的なエンジニアリングの課題は依然として存在し、それらがより良いインターフェースで包まれただけです。
制御、カスタマイズ、ワークフローのオーケストレーション
AgentKitのバージョン管理システムとビジュアルキャンバスは、Assistants APIで必要だったスクリプトのもつれた塊と比較して、エージェントがどのように動作するかをはるかに明確に把握できます。それだけでも、チームでの共同作業や長期的なメンテナンスにとって大きな改善です。
しかし、トレードオフがあります。その性質上、AgentKitはOpenAIのモデルを使用することに固定されます。他のモデル(ClaudeやGeminiなど)が特定のタスクで優れている可能性がある世界では、その柔軟性の欠如は深刻な欠点になり得ます。その上、AgentKitは汎用ツールです。多くの異なるルールを持つ複雑なサポートチケットのトリアージシステムのような特定のビジネスプロセスに合わせてカスタマイズする必要がある場合、結局はカスタムコードが必要になります。
カスタマーサポートのような重要な機能では、一般的な制御だけでは不十分です。細部にわたる制御が必要です。ここで専門的なプラットフォームが真価を発揮します。eesel AIのワークフローエンジンを使えば、AIの正確なペルソナとトーンを設定し、ルールに基づいてどのチケットを処理するかを正確に選択し、リアルタイムデータから情報を引き出すカスタムアクションを作成できます。これにより、汎用エージェントが暴走するのを防ぎ、顧客対応業務を安心して自動化できます。
エコシステム、統合、ナレッジソース
Assistants APIでは、外部データへの接続は完全に手動で、しばしば苦痛なプロセスでした。AgentKitの新しいConnector Registryは素晴らしいアップグレードで、一般的なツールに接続するための中心的でより安全な方法を提供します。しかし、これもまた新しい機能なので、OpenAIが構築・維持することを決定したコネクタに縛られることになります。
さらに重要なことに、どちらのフレームワークも、どのサポートチームにとっても最も価値のある知識源、つまりチーム自身の履歴を見過ごしています。これらは、ナレッジベースの記事やドキュメントを手動で収集、クリーンアップ、アップロードすることを期待しています。チームがすでに顧客が抱えているのと全く同じ問題を解決した何千もの実際の会話から学ぶことはできません。
現代のサポートチームは、Wikiだけで運営されているわけではありません。彼らの真の知識は、過去のチケット、マクロ、そしてランダムなドキュメントに埋もれています。eesel AIは、それらすべてを即座にまとめるために構築されています。Zendesk、Freshdesk、Intercomのようなプラットフォームでの過去の会話から自動的に学習し、初日からあなたのブランドの声とソリューションを完璧に再現します。また、Confluence、Google Docs、Slackなどの他のナレッジソースにもシームレスに接続し、AIに単一の統合された頭脳を与えます。
OpenAIの従量課金モデル
古いAssistants APIを使用していたか、新しいAgentKitに移行するかにかかわらず、価格設定は同じです:使用した分だけ支払います。これには、トークンごとのコスト(送信するものと受信するものの両方)と、ツール使用などのための別途料金が含まれます。たとえば、ファイル検索ストレージは1日あたり1GBあたり0.10ドルかかります。
サイドプロジェクトでいじっている開発者にとっては、それで全く問題ありません。しかし、予算を守ろうとしている企業にとっては悪夢です。それは完全な予測不能性を生み出します。ある月、サポートの量が2倍になれば、OpenAIの請求額もそれに伴って2倍になります。このモデルは基本的に、成長したことを罰し、コストを予測することを不可能にします。
OpenAIの価格設定ページのスクリーンショット。AgentKitとAssistants APIのコスト構造に関する議論の視覚的補助となります。
機能/コンポーネント | 価格モデル | 予測不能なコストの可能性 |
---|---|---|
モデル使用量(トークン) | トークンごとの支払い(入力/出力) | 高 |
ツール使用量(例:ファイル検索) | クエリごと + GB/日ごとのストレージ | 中 |
AgentKitコンポーネント | API使用量に含まれる | 高(トークン/ツール使用量を増加させる) |
企業は自分たちが何を費やしているかを知る必要があります。だからこそ、eesel AIのようなプラットフォームは、明確で定額の月額または年額プランを提供しています。一定数のAIインタラクションを利用でき、解決ごとに課金することはありません。忙しくなっても、コストは安定的で予測可能です。
開発者向けのツールキットであり、ビジネスソリューションではない
明確にしておきましょう:AgentKitはAssistants APIからの大きな飛躍です。カスタムAIエージェントをゼロから構築したい開発者にとって、より完全で、強力で、ユーザーフレンドリーなツールキットです。それはAIワークフォースという考えをより現実的なものに感じさせます。
しかし、それが落とし穴です。それは開発者フレームワークなのです。カスタマーサポートの自動化のようなビジネス上の問題を解決するための、すぐに使えるソリューションではありません。AgentKitは素晴らしいレゴブロックのセットを提供してくれますが、城を設計し、建設し、壊れたときに修理するのは依然としてあなた自身です。ほとんどのサポートチームにとって、それは彼らが時間も人員も割けない、数四半期にわたるエンジニアリングプロジェクトです。
応答時間の短縮、CSATの向上、そしてより重要な仕事のために人間のエージェントを解放するなど、今日問題を解決する必要があるチームにとって、専門的で完全に管理されたプラットフォームは、はるかに迅速で戦略的な方法です。
AgentKit vs Assistants APIを超えて:eesel AIで今日から実用的なAIエージェントを構築
サポートワークフローに効果的で自律的なAIを最も迅速に導入する方法を探しているなら、eesel AIはあなたのために作られました。エンジニアリングの頭痛の種ではなく、ビジネスの成果を出すために設計されています。
他とは違う点は次のとおりです:
-
数分で稼働開始: ヘルプデスクとのワンクリック統合を備えた、真のセルフサービスプラットフォームです。営業電話も、必須のデモもありません。サインアップしてすぐに始められます。
-
完全なコントロール: 強力でありながら直感的なワークフローエンジンを使用して、AIの個性、アクション、そしてどのチケットを処理すべきかを正確に定義します。
-
すべての知識を統合: 過去のチケット、ヘルプセンター、内部ドキュメント、マクロから自動的に学習します。手動でのアップロードは不要です。
-
リスクなく展開: 強力なシミュレーションモードを使用して、過去の何千ものチケットでAIをテストします。顧客が一度もやり取りする前に、そのROIを証明できます。
-
予測可能な価格設定: 当社の定額で透明性のあるプランは、成功したことであなたを罰することはありません。驚きは一切ありません。
開発者フレームワークと格闘するのはやめましょう。本当のビジネス問題を解決し始めましょう。
eesel AIの無料トライアルを開始するか、デモを予約して、数ヶ月ではなく数分でサポートを自動化する方法をご覧ください。
よくある質問
AgentKitは、エージェント構築を簡素化するための、より完全で視覚的なツールキットとして設計されており、古いAssistants APIの複雑さや「グルーコード」の問題に対処しています。新しいAgent Builderやその他のコンポーネントを通じて、エージェント開発をよりアクセスしやすく、迅速にすることを目指しています。
AgentKitは、Assistants APIのコード中心のアプローチに代わるビジュアルなAgent Builderを導入しており、エージェントのワークフローの設計とテストを大幅に簡素化します。依然として開発者ツールではありますが、この転換はコンセプトから導入までの時間を短縮することを目的としています。
OpenAIはAssistants APIを非推奨とし、2026年半ばまでに完全に廃止する計画です。これは、AgentKitが機能改善された後継として設計されているため、既存のユーザーは最終的にプロジェクトをAgentKitまたは別のソリューションに移行する必要があることを意味します。
その性質上、AgentKitは主にOpenAIのモデルを使用することに固定されます。視覚的なワークフローのオーケストレーションを提供しますが、ClaudeやGeminiのような他の大規模言語モデルに簡単に切り替えたり、統合したりする柔軟性を本質的に提供するものではありません。
AgentKitとAssistants APIはどちらも従量課金モデルを採用しており、トークンごとおよびツール使用量ごとに課金されます。費用が使用量に直接比例して増減するため、これは企業にとって予測不能なコストにつながる可能性があり、コスト予測を困難にします。
AgentKitは、すぐに導入できるビジネスソリューションではなく、強力な開発者フレームワークおよびツールキットとして位置づけられています。カスタムAIエージェントの作成を大幅に支援しますが、カスタマーサポートの自動化のような特定のビジネスニーズに合わせて調整・管理するには、依然としてかなりのエンジニアリング作業が必要です。
AgentKitはConnector Registryにより統合を改善し、Assistants APIの手動プロセスと比較して、一般的なツールにリンクするためのより安全な方法を提供します。しかし、どちらのフレームワークも依然として一般的に知識の手動での収集とアップロードを想定しており、過去のサポート会話から自動的に学習する能力を見過ごしがちです。