OpenAI で業務自動化を実装する — Assistants から Responses / Agents SDK へ

OpenAI の Assistants API は、会話状態の保持とツール実行を API 側で引き受けることで、問い合わせ対応や社内アシスタントといった業務自動化を短いコードで組めるようにした仕組みでした。ただし現在、Assistants API は非推奨（deprecated）となり、後継の Responses API および Agents SDK への移行方針が示されています。Assistants API 自体は 2026 年半ばにサンセット（提供終了）が予定されているため、これから新しく自動化を作るなら Responses API と Agents SDK を前提に設計するのが妥当です。

本記事では、Assistants API が担っていた「会話状態の管理」と「ツール実行」という2つの機能を整理したうえで、それらを現行の Responses API・Agents SDK でどう実装するかを、問い合わせ対応・社内アシスタント・バッチ処理という実務パターンに沿って解説します。コード例は現行の OpenAI SDK（Python）を用いた Responses API 系の呼び出しで示します。

Assistants API とは何だったか、なぜ移行するのか

Assistants API は、Assistant（役割とツールを定義した存在）、Thread（会話の入れ物）、Message（発言）、Run（実行）という複数のオブジェクトを組み合わせて動く設計でした。会話履歴は Thread に蓄積され、file search や code interpreter といったツールは OpenAI 側でホストされるため、開発者はベクトルストアの構築やコード実行環境の管理を自前で持たずに済みました。この「状態とツールをサーバー側に寄せる」という発想自体は、業務自動化の実装コストを大きく下げるものでした。

一方で、Thread・Run・ステップといったオブジェクトを都度作成・ポーリングする構造は冗長になりがちで、単純な一往復の処理にも複数回の API 呼び出しが必要でした。後継の Responses API は、この複雑さを一つのエンドポイントに畳み込み、テキスト生成・ツール実行・会話の継続を同じ呼び出しの中で扱えるように再設計されています。Assistants API の利点を引き継ぎつつ、より少ないコードで同じことを実現できる、というのが移行の基本的な動機です。

したがって既存システムの保守以外で Assistants API を新規採用する理由は薄く、サンセットの期限もあるため、新規開発はもちろん既存資産についても計画的な移行対象として扱うのが現実的です。

スレッドと会話状態の管理

業務自動化で最初に問題になるのが、会話状態をどこで持つかという設計です。一問一答で完結しない問い合わせ対応や、前の分析結果を踏まえた追加依頼では、過去のやり取りをモデルに引き継ぐ必要があります。Assistants API では Thread がその役割を担っていました。

Responses API では、状態管理の方法が二つ用意されています。一つは、直前の応答 ID を previous_response_id として次のリクエストに渡し、OpenAI 側に保持された会話を継続する方式です。もう一つは、会話履歴を自分のデータベースで管理し、毎回 input にまとめて渡す方式です。前者は実装が単純で、Assistants API の Thread に近い感覚で使えます。後者は履歴の保存先を自社側に置けるため、監査要件やデータ保持ポリシーが厳しい場合に向きます。

from openai import OpenAI

client = OpenAI()  # OPENAI_API_KEY を環境変数から取得

# 最初の応答
first = client.responses.create(
    model="gpt-5.1",
    input="第3四半期の売上データの傾向を要約してください。",
)
print(first.output_text)

# 直前の応答を引き継いで会話を継続する
followup = client.responses.create(
    model="gpt-5.1",
    previous_response_id=first.id,
    input="では来四半期に取るべき施策を3つ挙げてください。",
)
print(followup.output_text)

どちらの方式でも、会話 ID をユーザーやセッションに紐づけて保存しておけば、後から同じ文脈で処理を再開できます。自動化の設計では、この会話 ID をどのキー（顧客 ID、チケット番号など）に対応させるかを最初に決めておくと、後段の実装が整理しやすくなります。

ツール — function calling、file search、code interpreter

Responses API のもう一つの核は、モデルに外部処理を実行させるツール機能です。Assistants API と同様に、代表的なツールは function calling、file search、code interpreter の3つです。これらは tools パラメーターに列挙するだけで有効になります。

function calling — 自社のデータベース照会や基幹システムの API 呼び出しなど、独自の処理をモデルから起動させる仕組みです。モデルは引数を JSON で組み立てて関数呼び出しを要求し、実際の実行はアプリケーション側が行います。次の例では、注文番号から配送状況を返す関数を定義しています。

tools = [{
    "type": "function",
    "name": "get_order_status",
    "description": "注文番号から現在の配送状況を返す",
    "parameters": {
        "type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"],
    },
}]

response = client.responses.create(
    model="gpt-5.1",
    input="注文 A-1024 の配送状況を教えてください。",
    tools=tools,
)

# モデルが関数呼び出しを要求したら、アプリ側で実行し
# 結果を previous_response_id とともに返して会話を続ける
for item in response.output:
    if item.type == "function_call":
        args = item.arguments  # {"order_id": "A-1024"} 相当
        # ここで自社システムを呼び出し、結果を tool 出力として返す

file search — 社内マニュアルや規程などのドキュメントをベクトルストアに登録しておき、質問に関連する箇所を検索して回答に使わせる仕組みです。いわゆる RAG（検索拡張生成）を、検索インフラを自前で構築せずに利用できます。code interpreter — サンドボックス上で Python を実行し、集計・可視化・ファイル処理を行わせるツールです。表形式データの分析や簡単なレポート生成に向きます。

response = client.responses.create(
    model="gpt-5.1",
    input="就業規則で定められた有給休暇の付与日数を教えてください。",
    tools=[
        {"type": "file_search", "vector_store_ids": ["vs_company_docs"]},
        {"type": "code_interpreter", "container": {"type": "auto"}},
    ],
)
print(response.output_text)

ツールは複数を同時に渡せます。モデルは質問内容に応じて必要なツールを選び、必要なら複数を組み合わせて回答を構成します。どのツールを許可するかは、自動化の用途とセキュリティ要件に合わせて絞り込むのが基本です。

実務での自動化パターン

Responses API とツールを組み合わせると、業務自動化の多くは次の3つのパターンに整理できます。

問い合わせ対応

カスタマーサポートや社内ヘルプデスクでは、file search で FAQ・マニュアルを参照させ、function calling で基幹システムの状態（注文、契約、在庫など）を照会させる構成が基本になります。会話状態を保持することで、一次回答で解決しなかった場合の追加質問にも文脈を保ったまま応答できます。判断が難しい案件は、担当部門へエスカレーションする関数を用意しておき、モデルにその呼び出しを任せる設計が有効です。

社内アシスタント

規程・議事録・仕様書といった社内文書を横断して検索・要約する用途では、file search を中心に据えます。従業員からの「この制度の申請方法は」「この仕様の根拠はどこか」といった問い合わせに、出典を伴って回答できるのが利点です。扱う文書に機密が含まれる場合は、ベクトルストアへのアクセス権限を部門単位で分離し、会話履歴の保存先を自社管理下に置く方式を選ぶ判断が現実的です。

バッチ処理

大量の問い合わせメールの分類、契約書からの項目抽出、レビューの要約といった処理は、対話ではなくバッチとして流すのに適しています。1件ごとに独立した Responses API 呼び出しを行い、会話状態を持たせずに入力と出力だけを対応させる構成が明快です。件数が多くリアルタイム性を要さない場合は、非同期のバッチ実行を使うことで単価を抑えられます。処理結果は構造化出力（JSON スキーマ指定）で受け取り、そのまま後段のシステムに流し込むと自動化がつながります。

Assistants から Responses / Agents SDK への移行

既存の Assistants API 実装を移行する際は、Assistants の各オブジェクトが Responses API のどの概念に対応するかを対応付けるところから始めます。Assistant（役割・指示・ツール定義）は、Responses API のリクエストパラメーター（instructions、tools、モデル指定）へ展開します。Thread と Message による会話履歴は、previous_response_id による継続、または自社側での履歴管理へ置き換えます。Run のポーリングは不要になり、単一の呼び出しで応答を受け取る形に単純化されます。file search のベクトルストアは概ねそのまま引き継げるため、ドキュメント資産を作り直す必要は基本的にありません。

複数の役割を持つエージェントを連携させたり、処理を段階的にオーケストレーションしたい場合は、Agents SDK を併用します。Agents SDK は、エージェントの定義・ツールの登録・エージェント間の引き継ぎ（ハンドオフ）・実行ループの制御を枠組みとして提供し、内部では Responses API を利用します。次は、社内問い合わせに答え、判断できない場合はエスカレーションするエージェントの最小例です。

from agents import Agent, Runner

support_agent = Agent(
    name="社内サポート",
    instructions=(
        "社内規程に基づいて従業員の問い合わせに回答する。"
        "規程で判断できない場合は担当部門へのエスカレーションを促す。"
    ),
)

result = Runner.run_sync(support_agent, "経費精算の締め日を教えてください。")
print(result.final_output)

移行は一度に全体を切り替える必要はありません。新規機能から Responses API で実装し、既存の Assistants 実装は影響範囲を確認しながら段階的に置き換えるのが安全です。サンセットの期限を見据え、どの機能をいつまでに移行するかのスケジュールを早めに引いておくことをおすすめします。

まとめ

Assistants API が示した「会話状態とツールをサーバー側に寄せて自動化を組む」という考え方は、後継の Responses API と Agents SDK に引き継がれ、より少ないコードで実現できるようになりました。これから業務自動化を作るなら、会話状態の管理方式を先に決め、function calling・file search・code interpreter を用途に応じて組み合わせ、問い合わせ対応・社内アシスタント・バッチ処理のどのパターンに当てはまるかを見極めるのが出発点になります。既存の Assistants API 実装を持つ場合は、サンセットまでの移行計画を早めに立てておくと安全です。

エンハンスド株式会社では、LLM を使った業務自動化の設計から実装・運用までを支援しています。Assistants API からの移行、Responses API・Agents SDK を用いた問い合わせ対応や社内アシスタントの構築、既存システムとの連携まで、要件整理の段階からご相談いただけます。自社の業務にどう組み込めるか検討したい方は、お気軽にお問い合わせください。

このテーマの全体像は .NET × AI 活用 完全ガイド にまとめています。