OpenAI AssistantsでAIエージェントを構築する方法（現在はResponses API）
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
OpenAIのAssistants APIは、永続的な会話スレッド、ファイル検索、コード実行、関数呼び出しを備えたagent型アプリケーションを、状態管理をすべて手作業で行わなくても構築できるようにしました。重要な存在でしたし、既存の連携は現在も動いています。しかしOpenAIは2025年8月26日に非推奨化を発表しており、完全な終了日は2026年8月26日です。新規開発はすべて、Responses APIとAgents SDKに移すよう案内されています。新しいプロジェクトを始めるなら、そちらで構築してください。このガイドでは、Assistants APIの機能、後継となるもの、そしてOpenAIの現行ツールで実際にagentを構築する方法を解説します。
Assistants APIとは何だったのか、なぜ終了するのか
2023年のOpenAI開発者会議で発表されたAssistants APIは、開発者に4つの基本要素を提供しました。Assistant（指示とツールを設定したagent）、Thread（永続的な会話）、Run（スレッドに対するassistantの1回の実行）、Run Steps（実行中に行われた個々のアクション）です。アップロードしたファイルに対する検索、コードインタープリター、関数呼び出しもまとめて提供されていたため、ツールを使う状態保持型のagentを、基盤部分を自作せずに立ち上げる最速の手段でした。
問題は、OpenAI自身の言葉を借りれば複雑さでした。同社は2025年3月にResponses APIを公開した際、Assistantsのすべての機能をよりシンプルなこのAPIに取り込み、元のAPIを終了する計画だと明言しました。その言葉どおり、2025年8月26日に開発者へ非推奨の通知が出され、ちょうど1年後にAPIから削除されます。OpenAIの移行ガイドによると、移行で失われる機能はなく、機能は再編成されるだけで削除されません。
後継となるもの：Responses APIとAgents SDK
Responses APIは単なる名称変更ではなく、本当にシンプルになったモデルです。入力アイテムを送れば出力アイテムが直接返ってきて、Runオブジェクトのステータスが変わるまでポーリングする必要はありません。Assistantsの4つの概念が、Responsesの4つの概念に対応します。
| Assistants API | Responses APIでの対応概念 | 変わった点 |
|---|---|---|
| Assistants | Prompts | 設定はAPI呼び出しだけで管理する方式から、組み込みのバージョン管理を備えたダッシュボード上に移りました |
| Threads | Conversations | メッセージだけでなく、ツール呼び出し、出力、そのほかのアイテムも保存できるように拡張されました |
| Runs | Responses | 入力を送れば出力が直接返ります。ポーリングのループは不要です |
| Run steps | Items | レスポンスに含まれうるさまざまなデータを扱えるように汎用化されたオブジェクトです |
Responses APIには、自分で作る必要のない5つの組み込みツールも用意されています。Web検索、ファイル検索、コードインタープリター、コンピューター操作、リモートMCPサーバー接続です。ファイル検索は、Assistants APIの検索機能の直接の後継で、AIエージェントのためのRAGで解説しているのと同じドキュメント根拠づけのパターンです。パターンのレベルでは、RAGアシスタントパターンにあたります。
単一のagentを超える用途には、OpenAIがAgents SDKも提供しています。これは、以前の実験的な「Swarm」フレームワークを本番運用向けに発展させた後継です。Responses APIが提供するのは基本部品、つまり1回の入力に対して1回のレスポンスを返す仕組みです。Agents SDKはその周囲のオーケストレーションを提供します。Agents（モデルに指示とツールを加えたもの）、Handoffs（あるagentが別のagentにタスクを委任する仕組み）、Guardrails（入力と出力の検証）です。OpenAI自身の整理は明快で、agentのループを自分で管理したいならResponses API、SDKにそのループを任せたいならAgents SDKを使います。2026年にSDKへ追加された機能には、音声agent向けのRealtime APIとのネイティブ統合や、Model Context Protocolサーバーの標準サポートがあります。MCPに対応したツールなら、独自の連携コードなしで接続できる機能になります。
構築手順
- ループを誰が管理するかを決めます。 比較的単純な単一のagentなら、Responses APIを直接呼び出し、入力、出力、関数呼び出しのサイクルを自分のコードで処理します。複数のagentを連携させる場合や、そのループを自分で書きたくない場合は、Agents SDKから始めます。
- agentの指示を書きます。 AIエージェントの構築方法の役割とルールの構成要素を、システムプロンプトとして記述します。agentが担当すること、絶対にしてはいけないことを明記します。
- 必要に応じて組み込みツールを接続します。 自社ドキュメントから回答する必要があるならファイル検索、最新情報が必要ならWeb検索、計算にはコードインタープリターを使います。コンピューター操作は、UIを実際に操作する必要がある場合に限ります。
- 自社システム用のカスタム関数呼び出しツールを組み込みます。 各関数についてJSONスキーマ（名前、パラメータ、説明）を定義します。モデルが特定の引数を指定して呼び出しを要求し、アプリケーションのコードがCRM、データベース、APIに対して実際に実行して、モデルが推論を続けられるよう結果を返します。このツール呼び出しの仕組みは、AIエージェントはどのようにツールを使うかで詳しく解説しています。
- セッションをまたいで保持する必要があるものには、Conversationsを使います。 Assistants Threadsの直接の後継です。
- 仕事が専門のagent間にきれいに分かれるなら、Handoffsを追加します。 マルチagentシステムで解説しているのと同じオーケストレーションパターンです。
- 入力と出力を検証するGuardrailsを追加し、トレーシングも追加します。 SDKのSentryネイティブ連携か自前のログを使い、実際の処理量を任せる前に、どのツールがなぜ実行されたのかを正確に確認できるようにします。
- 自社のバックエンドの背後にデプロイします。 ここにはビジュアルなホスティング環境はありません。サーバー、認証、リトライのロジックは自社で用意します。
実装は、ループの管理と指示から始まり、ツール、永続的な状態、ハンドオフ、ガードレール、トレーシングへと進みます。
実例：AIナレッジベースagent
ナレッジベースagentは、Responses APIに自然に合います。独自の検索コードではなく、組み込みのファイル検索ツールに直接頼れるからです。
ユーザーが質問をします。agentの指示は、ファイル検索ツールで接続された、アップロード済みでインデックス化された社内ドキュメントだけを根拠に回答するよう制限しています。agentは検索して関連する箇所を見つけ、単なる主張ではなく、出典ドキュメントへの引用を付けて回答します。ファイル検索で確信の持てる一致が返らなかった場合は、推測せずその旨をはっきり伝えるよう指示に書かれています。また、カスタムの関数呼び出しツールにより、答えられない質問を人間の対応キューにエスカレーションできます。
これは、AIナレッジベースagentのブループリントが詳しく定めているルールとガードレールの構成と同じです。承認済みのソースに限定し、回答の出どころを引用し、推測せずにエスカレーションします。Responses APIで構築する場合、実際の作業はファイル検索ツールとエスカレーション関数を接続することが中心です。それぞれをいつ使うかは、モデル自身の推論に任せます。
コストと制約
OpenAIのAPIはトークンで課金されます（入力と出力は別料金で、モデルによって異なります）。組み込みツールにはそれぞれ独自の課金体系があります。Web検索とファイル検索は呼び出しごと、または保存したドキュメントの量に応じて課金され、コードインタープリターとコンピューター操作は実行した計算時間に応じて課金されます。料金は頻繁に変わるため、ここに書かれた数字を最新のものと見なさず、OpenAIの料金ページで直接確認してください。計画のうえで重要なのは、コストの構造です。単一の固定料金ではなく、複数の別々の従量課金メーターが組み合わさっています。小規模なパイロットの請求額から、常時稼働する重いagentのコストを見積もる前に、AIの総所有コストを読んでください。
多くのチームにとって、より大きな制約はコストではなく、この道ではビジュアルビルダーがまったく使えないことです。n8n、Make、Lindyが代わりにやってくれること（ホスティング、リトライ、非エンジニアがagentを調整するためのUI）は、ここではすべて自社チームの仕事になります。このトレードオフははっきり認識しておく価値があります。OpenAIのモデルとツールに、APIとの間の抽象化が最も少ない形で一次アクセスできる代わりに、ランタイム全体を自分で管理することになります。また、既存のAssistants API連携がある場合、移行は任意ではありません。2026年8月26日までに、上記の対応表に従って移行しなければ、連携は完全に動かなくなります。
この選択肢と他の選択肢の選び方
| 求めるもの | 選ぶべきもの |
|---|---|
| OpenAIのモデルを直接使ったコードでの完全な制御、最小限の抽象化、チームがすでにソフトウェアを書いている | OpenAIのResponses APIとAgents SDK |
| コードなしで、最短で動くagentを手に入れたい | Lindy |
| ビジュアルビルダーで、事前構築済みのアプリカタログが最も幅広い | Make |
| ビジュアルキャンバスとコードへの抜け道を備えたセルフホスト | n8n |
これらは厳密に排他的な選択肢ではありません。n8n、Make、Lindyはいずれも、各プラットフォーム上で構築したagentの推論エンジンとしてOpenAIのモデルを呼び出せます。選んでいるのはオーケストレーション層であり、OpenAIのモデルそのものから離れるとは限りません。チームがすでにコードを出荷していて、アプリケーションとモデルの間の層をできるだけ減らしたい場合は、Responses APIとAgents SDKで直接構築します。低レベルの制御をいくらか手放して、素早い反復と非エンジニアも触れるビルダーを優先したい場合は、ビジュアルプラットフォームを選びます。この選択に急ぐ理由があるのは事実です。Gartnerは、2026年末までにエンタープライズアプリケーションの40%がタスク特化型のAI agentを搭載すると予測しており、2025年の5%未満から急増する見込みです。このような普及曲線のなかでは、OpenAIが積極的に終了させようとしているプラットフォーム上で構築するのは、いま選ぶべきでない賭けです。
Key Facts
- OpenAIは2025年8月26日にAssistants APIの非推奨化を発表しました。完全な終了日は2026年8月26日です。新規プロジェクトはResponses APIで構築してください。
- Responses APIは、Assistantsの4つの概念を置き換えます。AssistantsはPrompts、ThreadsはConversations、RunsはResponses、Run stepsはItemsになります。
- Responses APIには5つの組み込みツールがあります。Web検索、ファイル検索、コードインタープリター、コンピューター操作、リモートMCPサーバー接続です。
- Agents SDKは、OpenAIの実験的なSwarmフレームワークを本番運用向けに発展させた後継で、複数のagentを連携させるためのAgents、Handoffs、Guardrailsを加えます。
- Gartnerは、2026年末までにエンタープライズアプリケーションの40%がタスク特化型のAI agentを搭載すると予測しています。2025年は5%未満でした。
OpenAI AssistantsでAIエージェントを構築することに関するよくある質問
OpenAIのAssistants APIは2026年でもまだ使えますか？
はい。ただし2026年8月26日の終了日までです。その後はAPIから完全に削除されます。既存の連携はそれまで動き続けますが、OpenAIは2025年8月26日に非推奨化を発表して以来、新規開発はすべてResponses APIとAgents SDKに移すよう案内しています。
Assistants APIの後継は何ですか？
Responses APIです。同じ機能（永続的な状態、検索、コード実行、関数呼び出し）を統合して簡素化し、入力アイテムを送れば出力アイテムが直接返る形にしています。Runオブジェクトのポーリングは不要です。複数のagentを連携させる場合は、Responses APIの上にOpenAIのAgents SDKがあり、ハンドオフとガードレールを加えます。
既存のAssistants API連携は移行する必要がありますか？
はい、2026年8月26日までに必要です。OpenAIの移行ガイドは、Assistantsのすべての概念をResponses APIでの対応概念に対応づけています（AssistantsはPrompts、ThreadsはConversations、RunsはResponses、Run stepsはItems）。失われる機能はなく、再編成されるだけだと明記されています。
Responses APIとAgents SDKの違いは何ですか？
Responses APIは基盤となるプリミティブです。リクエストを送ってレスポンスを受け取り、それを繰り返し呼び出して関数呼び出しを実行し、結果を戻すループは自分で管理します。Agents SDKはその上に構築されており、ループを代わりに実行し、マルチagentのハンドオフと入出力のガードレールを加えます。単一のagentのロジックが複雑になり、そうした構造が欲しくなったときに役立ちます。
コードを書かずに、OpenAIのモデルでAIエージェントを構築できますか？
OpenAI自身のAPIを直接使う方法では難しいです。ビジュアルビルダーがないためです。n8n、Make、Lindyなどのプラットフォームは、ビジュアルに構築するagentの推論エンジンとしてOpenAIのモデルを呼び出せます。オーケストレーションのコードを自分で書いてホスティングしたくないチームには、こちらのほうが取り組みやすい方法です。
次のステップ
チームがすでにソフトウェアを書いていて、コードとOpenAIのモデルの間の層をできるだけ減らしたいなら、Responses APIとAgents SDKが適切な出発点です。ただし、終了するAPIではなく、そちらで構築してください。ビジュアルで構築したい場合は、制御と速度のどちらをどれだけ重視するかに応じて、n8nでAIエージェントを構築する方法、MakeでAIエージェントを構築する方法、LindyでAIエージェントを構築する方法をご覧ください。OpenAI自身のツールとホスト型プラットフォームを比較している段階なら、開発ツールの一覧とAIチャットボットプラットフォームの選び方のガイドが次の参考になります。
