Responses APIとは?
Responses APIとは、OpenAIが2024年春に発表し、2025年5月からAzure OpenAI Serviceでもプレビュー提供が開始された新しい「ステートフルAPI」です。
このAPIは、従来のChat Completions APIやAssistants APIで実現していた会話履歴の管理・ツール連携・コード実行などの機能を、さらに洗練された形で統合しています。 特にAzure OpenAI Serviceでは、Responses APIを使うことで会話履歴や操作状態をサーバー側で管理でき、複雑なAIエージェントや業務自動化ボットの開発が一段と容易になります。
Azure AI FoundryからもGUIベースで設定可能で、大規模なマルチターン対話やツール連携を伴うユースケースで高い柔軟性を発揮します。
ステートフルAPIとは?従来のステートレスAPIとの違い
Responses APIの特徴を理解するために、まずはResponses APIが採用しているステートフルAPIという仕組みについてご説明します。
ステートフルAPIとは、サーバー側で状態を管理し、会話の文脈や操作の進行状況を追跡する仕組みを持つAPIです。この仕組みにより、クライアント側での実装が簡素化され、複雑なタスクや外部ツールとの連携が容易になります。
一方、従来のステートレスAPIは、各リクエストが独立しており、サーバー側で状態を保持しない設計のAPIです。 そのため、クライアント側でリクエストごとに必要な情報をすべて提供する必要がありました。
ステートフルAPIではサーバー側で会話履歴を保持するため、ユーザーの意図を理解し、適切な応答やアクションを提供できます。また、ツール呼び出しやデータベース検索、コード実行といった複雑な操作も、単一のAPI呼び出しで実現可能です。
これにより、Responses APIでは、開発者が状態管理を意識することなく、より高度なAIエージェントを構築できるようになります。
Chat Completions APIやAssistants APIとの違い
Responses API開発元のOpenAIは、Responses APIの発表以前にChat Completions APIとAssistants APIという2つのAPIを発表しています。
Responses APIは、これら2つのAPIの利点を統合し、さらに進化させた設計となっています。
- Chat Completions API ユーザーからの入力に対して即座に応答を返すシンプルな仕組みを持つAPIです。各リクエストは独立しており、会話の文脈を保持しないため、FAQボットや単発の質問応答に適しています。
- Assistants API 会話の文脈を保持し複数ターンの対話やタスクの実行が可能なAPIです。会話履歴を保持することで文脈を理解した応答が可能であり、コード実行やファイル検索などのツールとの連携も可能です。 ただし、実装が複雑で初期設定や管理が必要であり、リソース消費が大きいという課題がありました。
このように、Responses APIは、Chat Completions APIのシンプルさとAssistants APIの高度な機能を兼ね備え、単一のAPIで多様なタスクを実現します。 また、OpenAIは2026年中頃までにAssistants APIを段階的に廃止し、Responses APIに完全に統合する計画を発表しています。
【関連記事】
【Azure OpenAI】Assistants APIとは? AIアシスタント開発を加速する機能を徹底解説
Responses APIの主な機能
Responses APIは、従来のChat Completions APIやAssistants APIと比べて、AIエージェント開発をより柔軟かつシンプルにする“次世代型API”です。
その主な特徴と強みは以下の3点に集約されます。
1. サーバーサイドでの会話状態管理(ステートフルAPI)
Responses API最大の特徴は、会話の文脈や状態(履歴・タスクの進行状況)をAPI側=サーバーサイドで自動的に管理する点です。 これにより、従来はクライアントアプリ側で煩雑に管理していた“マルチターンの会話履歴・プロセス状態”を、APIリクエストごとに手軽に引き継ぎ、複雑なAIエージェントも簡単に構築できます。
- 一度作ったエージェントが、途中で別のタスクや会話を挟んでもスムーズに文脈を理解します。
- 「ユーザーが前回どこまで進んだか」をAPI側が自動で覚えてくれるので、チャットやワークフロー自動化の開発効率が向上します。
2. ツール呼び出しの統合フレームワーク
Responses APIは、AIモデル単体の対話だけでなく、さまざまなツール(プラグイン的な外部機能)を1つのAPIから呼び出せる設計になっています。
この枠組みの中で、2025年6月時点でAzureが公式対応している代表的な組み込みツールは以下です。
- File Search 企業内の文書、PDF、DBなどをAIが自動検索し、回答根拠として引用・参照を付与(RAGの一種)。
- Code Interpreter Python等によるデータ処理・統計計算・可視化など、本格的なスクリプト実行が可能。
- Computer Use(Computer-Using Agent:CUA) WindowsアプリやWebアプリのGUI操作もAIエージェントが自動化。 画面の操作・ボタンのクリック・フォーム入力・PCの設定変更などを自動実行できます(※利用申請が必要)。
これらをAPIの単一リクエストで同時に利用・連携できるため、「単なるチャットボット」では実現できなかった複雑な業務フローの自動化や、LLM×RPAのような業務支援も手軽に実装できます。
3. 今後の拡張性と連携力
Responses APIは今後、より多様なツールや外部サービスの統合にも順次対応が予定されています。
また、Microsoft Copilot StudioやAzure Logic Apps、Power Platformとの統合も進み、AIエージェントが社内外の業務プロセスを横断的に自律実行するエージェントプラットフォームとしての進化が期待されています。
Responses APIの料金
Responses APIの料金体系は従量課金制で、利用したモデルのトークン消費量および各種機能の使用量に応じて課金されます。
以下に、主な料金をまとめます。
利用項目 | 料金 |
|---|---|
モデルのトークン消費 | 選択したモデルに準拠 |
コンピューター操作の自動化(Computer Use) | 入力: $3 / 100万トークン 出力: $12 / 100万トークン |
ファイル検索(File Search) | $2.5 / 1,000 回の呼び出し |
ファイル検索用のストレージ | $0.1 / 1GB / 日 (※最初の1GBは無料) |
コードインタープリター(Code Interpreter) | $0.03 / セッション(最大1時間の実行環境ごと) |
表中の「トークン」とは、モデルがテキストを処理する最小単位のことで、1トークンで処理できる量は英語で約4文字に相当します。
※上記の内容は、2025年6月時点の情報です。最新情報や、モデルのトークン消費料金について詳しくは、Azure OpenAI Service公式サイトをご覧ください。
Responses APIの利用手順
ここでは、Responses APIを利用するための基本的な手順を解説します。
- 利用申請 2025年6月現在、「コンピューター操作の自動化(Computer Use)」は、Microsoftへの申請が必要です。こちらのリンクから申請を行うことができます。
申請の受理まで時間がかかる場合もあるため、利用を検討している場合は早めに申請しましょう。
- Azure OpenAI Serviceの準備
Azureポータルにアクセスし、Azure OpenAI Serviceのリソースを作成しましょう。サブスクリプションやリソースグループなど必要事項を入力します。
Azure OpenAI Serviceリソースの作成
- モデルのデプロイ Azure OpenAI Serviceにアクセスし、モデルのデプロイを行います。デプロイが完了したら、「アシスタントの作成」をクリックしましょう。
モデルのデプロイ
- Responses API機能の有効化 ツールタブのトグルスイッチをオンにすることで、Responses APIの機能を有効化できます。ファイル検索のためのデータリソースの追加や、コードインタープリターのファイル追加もこちらで行いましょう。

- コードの取得 実際にResponses APIを呼び出すためのコードを取得します。ウィンドウ上部の「コードの表示」をクリックすることで取得可能です。Pythonなど、お使いの環境に合わせたコードを取得しましょう。
コードの取得
上記のステップで、アプリケーションからResponses APIを呼び出すことができます。
複雑なAPI設定や外部サービスとの煩雑な連携コードを書く必要がないため、すぐにAIエージェント機能をアプリケーションに組み込めます。
Responses APIの活用デモ
ここでは実際にResponses APIのコードインタープリター機能を活用し、「独自の統計処理コードを利用し、複数ファイルにまたがったデータから業務報告書を作成するAIエージェントの開発」というユースケースで活用デモを行います。
1. 事前準備
まずは、以下のような簡単な統計処理を行うPythonコードを用意しました。
【統計処理コード】
import pandas as pd
import numpy as np
def weighted_mean(values: pd.Series, weights: pd.Series) -> float:
"""Return the weighted mean of *values* with *weights*."""
values = values.astype(float)
weights = weights.astype(float)
return (values * weights).sum() / weights.sum()
def coefficient_of_variation(series: pd.Series) -> float:
"""Coefficient of variation (std / mean)."""
return series.std(ddof=0) / series.mean()
def detect_outliers_zscore(series: pd.Series, thresh: float = 3.0) -> pd.Series:
"""Return a boolean Series marking outliers using the z‑score method."""
z = (series - series.mean()) / series.std(ddof=0)
return z.abs() > thresh
def monthly_growth_rate(df: pd.DataFrame, value_col: str, date_col: str) -> pd.Series:
"""Month‑over‑month growth rate for *value_col* based on *date_col*."""
df = df.copy()
df[date_col] = pd.to_datetime(df[date_col])
monthly = df.groupby(pd.Grouper(key=date_col, freq="M"))[value_col].sum()
growth = monthly.pct_change().fillna(0)
return growth
weighted_mean(values: pd.Series, weights: pd.Series) -> float加重平均を計算します。各valuesに対応するweightsを掛けて合計し、重みの合計で割っています。coefficient_of_variation(series: pd.Series) -> float変動係数(母集団の標準偏差 ÷ 平均)を計算します。データの相対的なばらつきを測っています。detect_outliers_zscore(series: pd.Series, thresh: float = 3.0) -> pd.SeriesZスコア法(平均からの距離を標準偏差単位で測ったもの)を使って外れ値を検出します。Zスコアの絶対値がthreshより大きい値を外れ値とみなします。monthly_growth_rate(df: pd.DataFrame, value_col: str, date_col: str) -> pd.Series月ごとの成長率(パーセンテージ変化)を計算します。
上記のPythonコードを、Azure OpenAI Service上に追加します。
コードの追加
これで、事前に定義した独自の統計処理をAIエージェントが実行できるようになりました。
2. AIエージェントの動作を定義
次にAzure OpenAI Service上でAIエージェントの動作を定義します。以下のように手順を記述しました。
手順の記述
「コードの表示」をクリックすると、以下のようにサンプルコードが出力されるのでコピーします。
【Responses API呼び出しのサンプルコード】
import os
import time
import json
import requests
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from openai import AzureOpenAI
# Initialize Azure OpenAI client with entra-id authentication
token_provider = get_bearer_token_provider(
DefaultAzureCredential(),
"https://cognitiveservices.azure.com/.default"
)
client = AzureOpenAI(
azure_ad_token_provider=token_provider,
azure_endpoint=os.getenv("AZURE_OPENAI_ENDPOINT"),
api_version="2024-05-01-preview"
)
assistant = client.beta.assistants.create(
model="gpt-4o", # replace with model deployment name
name="Assistant",
instructions=
"1.ワークスペース上のファイルの内容をすべて確認してください。2.コードインタープリターでcustom_stats.pyを実行し、売上・成長率・外れ値フラグを取得してください。3.製品ごとの地域別平均顧客満足度、製品ごとの生産稼働時間、2で取得したデータをまとめ、json形式で出力してください。
",
tools=[{"type":"code_interpreter"}]
,tool_resources={"code_interpreter":{"file_ids":["assistant-8FnctHgMh9RPaH2ozk1oFn"]}},
temperature=1,
top_p=1
)
print(f"Assistant created: {json.dumps(assistant)}")
3. 動作確認
上記のコードに、jsonからグラフと表を出力する処理を追加し、アプリケーションを作成しました。
デモを行うためのワークスペース上に、以下のようなファイルを用意しました。
顧客満足度と苦情件数
生産稼働ログ
販売実績
これらは、csvファイル、jsonファイル、xlsxファイルで、業務報告に必要なデータが各ファイルに散乱している状態です。
実際に作成したアプリケーションをワークスペース上で実行し、プロンプトで「業務報告書を作成して」と指示すると、以下のようにグラフと表が出力されました。
出力された表とグラフ
さらに、以下のようにチャット形式で対話しながらデータ分析を行うことも可能です。
今回は以下のようにプロンプトを送りました。
統計処理したデータから、製品Gearについて得られた洞察を教えて
すると以下のように返答が送られました。
Gear製品に関する主なインサイトは以下のとおりです。
| 観点 | インサイト | 補足データ |
| ----------- | ------------------------------------------------------------------------------------- | ---------------------------- |
| **売上規模** | Gearは全製品売上の約 **30 %** を占める主要商材(約 75.2 万 USD/全体 246.5 万 USD)。 | Gear総売上 751 k USD |
| **成長率** | 直近の月次成長率は **-26 %** と大幅なマイナス。市場環境の悪化か販売施策の停滞が示唆される。 | growth\_rate -0.262 |
| **地域別売上上位** | **North** が最大(32.1 万 USD、構成比 43 %)。次いで **East**(17.8 万 USD)。 | North 321 k USD › East 178 k |
| **顧客満足度** | Gear平均は **2.90**(全製品平均 2.94)でわずかに下回る。<br>地域差が大きく、**West** が最高 3.14、**East** が最低 2.54。 | scale 1-5 |
| **生産稼働時間** | Gearの累計稼働は **717 h**(全体の約 30 %)。North と East が突出して高稼働。 | North 218 h › East 208 h |
| **外れ値** | 売上外れ値フラグは **West** のみ検出。販促キャンペーンやデータ誤計上の可能性を要確認。 | any\_outlier=True |
追加のドリルダウン(期間別トレンド、顧客セグメント別分析など)が必要でしたらお知らせください。
このように、複雑なAPI呼び出しや外部ツールの連携を行うことなく、AIエージェントを開発することができました。LLMを用いたチャット機能と、事前に定義したコードを組み合わせることで、高度な機能を提供できます。
Responses APIの利用時のポイント
このセクションでは、Responses APIを効果的に活用するためのポイントを詳しく解説します。
タイムアウトや再試行の仕組みを備えておく
Responses APIは、モデルとの対話をステップ単位で繰り返す構成になっています。通信エラーや操作の失敗が発生することも想定し、以下のような設計を加えることが推奨されます。
- 応答が空の場合のリトライ処理
- 明示的な「何もしない」アクションに対する処理中断
- 長時間操作が止まっているときのタイムアウト終了
一定の完了条件やエラーハンドリング条件を定義しておくと、安定した運用がしやすくなります。
明示的なプロンプトを指定する
Responses APIに渡す指示は、自然言語として柔軟である一方、曖昧な指示では適切なアクションが得られないこともあります。そのため、以下のような具体的なプロンプトが推奨されます。
以下は、プロンプトの比較表です。
曖昧な指示 | より明確な表現 |
|---|---|
「画面を確認してください」 | 「 |
「設定を確認して」 | 「設定画面に移動し、『通知を有効にする』のチェックを確認してください」 |
ユーザーの意図を逐次モデルに伝えることで、意図しない行動を抑止できます。連携システム側で明示的な目的を持たせる工夫が重要です。
安全性チェックと確認プロセスを組み込む
Responses APIは、ユーザーの代わりに操作を行えるという性質上、意図しない操作やリスクのある挙動を避けるための安全性チェックが実装されています。
以下に、安全性チェックの主な項目を示します。
チェック項目 | 内容の概要 |
|---|---|
malicious_instructions(悪意のある指示) | システムに不正な操作を指示しようとする内容 |
irrelevant_domain(無関係なドメイン) | 対象としていないサイトへのアクセス検出 |
sensitive_domain(機密性の高いドメイン) | 金融・個人情報など、取り扱い注意の領域 |
これらのチェックに該当した場合に、次回リクエスト時に確認を返すプロセスを組み込むことで安全性を担保できます。
Responses APIの活用シーン
では、Responses APIは、どのような場面で活躍するのでしょうか。 効果的な場面に利用することで、AIエージェントによる業務の自動化や効率化を実現できます。
データベースを参照した問い合わせ対応
例えば、社内に蓄積されたデータに対して、質問した場合に蓄積されたデータを参照して、回答する仕組みを構築できます。
Responses APIを用いることで、単に技術資料のPDFを参照するだけでなく、データベース内をFile Searchツールで検索し、内容に基づいた正確な情報を抽出することが可能です。 また、問い合わせ内容が複雑な場合も、データベース上のファイルを横断的に参照して回答を生成できるため、業務ナレッジの活用効率が向上します。
社内独自のコードを使った業務分析の自動化
データをもとに、自動で統計処理や可視化処理を行うことができます。 従来のAIエージェントでは、処理を行う関数やコードをAI自身が定義して実行していましたが、Responses APIのCode Interpreterを使うことで、事前に定義したコードを用いた処理を容易に利用することが可能です。
社内で利用している独自のワークフローを崩さず、適用できるという利点があります。
ヘルプデスクの自動化
ユーザーが入力した自然言語の問い合わせに対して、AIが実際のPC環境で問題を特定し、適切な手順を実行することも可能です。
たとえばアプリケーションのインストール作業を代行したり、設定パネルを開いて特定のオプションを有効にするといった操作を自動で実行できます。Responses APIのComputer Useを利用することで人間と同様にUIを解釈して動作するため、Power Automateなどの自動化ツールだけでは難しかった動的画面にも柔軟に対応できます。
上記で紹介したResponses APIの活用シーン以外にも、Responses APIの各機能を組み合わせることで、単機能のチャットボットでは対応できなかったような複雑な業務フローの構築が実現するでしょう。
Responses API利用時の注意点
Responses APIは有用なツールですが、運用にあたって注意すべき点もいくつか存在します。ここでは、Responses APIを利用する際の注意点をご紹介します。
提供状況と安定性
Responses APIは2025年6月現在プレビュー提供中の新機能です。そのため今後仕様が変更されたり、予期せぬ不具合が見つかる可能性があります。現段階では本番環境で処理を任せるより、まずは検証目的で試用することを推奨します。
Microsoft公式ドキュメントやアップデート情報を常にチェックしましょう。
AIの誤動作・リスク対策
Responses APIはAIに自律性を与えるため、その誤動作やリスク管理には十分注意が必要です。たとえばComputer UseではGUI操作を誤ると意図しない画面遷移やデータ入力をする可能性が考えられます。
Azureでは、有害なタスクや不正操作を拒否する仕組みや、実行モニタリングによるポリシー違反検知など多層的なセーフガードを実装しています。 ユーザー自身も、運用時にはAIの挙動を定期的にレビューし、問題があればすぐに対処できる体制を整えましょう。
コストパフォーマンス管理
Responses APIは使い方によっては思わぬコスト増に繋がる可能性があります。たとえばAIが不要に何度もファイル検索を呼び出したり、膨大なコード実行を行った場合、都度料金が発生します。 開発段階でツール使用の頻度やトークンの使用量を分析し、不要な処理がないかチェックしましょう。
また、Azureの料金上限設定やモニタリングアラートを活用し、予算を超えないよう管理することも大切です。
レギュレーション遵守
AIに処理を任せる際、そのアウトプットが規程に反しないか確認することも重要です。たとえば、自動返信メールの内容がコンプライアンス上問題ないか、AIが利用するデータが個人情報保護規則に触れないか、など人間がチェックすべきポイントがあります。
Azure OpenAI Serviceではコンテンツフィルタリング機能も組み込まれており、不適切な表現やデータの検出に努めています。
しかし最終的な責任はユーザー側にあるため、AIのアウトプットをレビューするプロセスや、問題発生時に速やかに修正できる体制を整えましょう。
まとめ
Responses APIは、AIエージェント開発の複雑さを軽減し、コンピューター操作の自動化やファイル検索、独自コードの実行などを単一APIで実現します。これにより、従来は煩雑だった業務自動化やデータ分析、ヘルプデスク対応などが、よりシンプルに構築できるようになりました。
現在はAzureAI Foundry上で利用できるプレビュー機能として提供されているため、仕様変更のリスクや、AIの誤動作など、運用上の注意点も存在します。Microsoftのガイドラインやセーフガードを活用しつつ、開発したAIエージェントを適切に運用する体制が重要です。
今後もResponses APIの進化に注目し、業務効率化や新たなAI活用の可能性を広げていきましょう。
東京エレクトロンデバイスは、Azure AI FoundryをはじめとするAzure AIソリューションの企業導入をサポートしています。





