OpenAI Responses API で AI の社会実装をよりシンプルに！ Chat Completions API と Assistants API から進化した公式推奨 API

AIの社会実装が急速に進む現在、企業がAIを実ビジネスに組み込む際の障壁の一つに「実装の複雑さ」があります。優れたAIモデルが存在しても、それを実際のサービスに統合するには専門的な知識と多くの工数が必要でした。

この課題に対する解決策として、OpenAI が2025年3月に正式リリースした Responses API が注目を集めています。従来の Chat Completions API と Assistants API の両方を1つに統合したこの新しい API は、開発負荷を大幅に減らし、AIの社会実装を加速させる可能性を秘めています。

本記事では「なぜ Responses API が今後の標準になるのか」を解説しながら、Google Colab でそのまま動く従来 API との比較コードを通じて、AIの社会実装がよりシンプルになる様子を垣間見ます。

Google Colab の使い方につきましては、以下の記事を参照ください。

👉 【AI入門 #2】Google ColabでChatGPTを動かそう！

目次

1. Responses API の登場
    1-1. Chat Completions API が抱える課題
     1-1-1. Chat Completions API とは
     1-1-2. 課題①: 履歴の再送
     1-1-3. 課題②: Function Calling の往復
    1-2. Assistants API が抱える課題
     1-2-1. Assistants API とは
     1-2-2. 課題①: 煩雑な ID 管理
     1-2-3. 課題②: ポーリングの手間
    1-3. Responses API による解決
     1-3-1. Responses API の登場
     1-3-2. これからのスタンダード
2. Chat Completions API vs Responses API
    2-1. 履歴再送
    2-2. Function Calling の往復
3. Assistants API vs Responses API
    3-1. 煩雑な ID 管理
    3-2. ポーリングの手間
4. まとめ

1. Responses API の登場

Responses API を理解するには、まず従来の Chat Completions API と Assistants API がどのようなものかを整理する必要があります。本章では両 API のコンセプトを踏まえたうえで課題を洗い出し、Responses API がそれらをどう統合しているのかについて紹介します。

1-1. Chat Completions API が抱える課題

まずは、ChatGPT と同じような挙動を簡単に再現できる Chat Completions API について、その概要と課題を確認します。

1-1-1. Chat Completions API とは

Chat Completions API は「メッセージのリストをまとめて入力として受け取り、モデルが生成した新たなメッセージを出力する」API です。

ChatGPT を使用していると、モデルは会話の履歴を自動的に記憶しているように見えますが、実際には裏で今までの会話の履歴を「メッセージのリスト」として毎回モデルに送り直しています。

Chat Completions API は、このような ChatGPT 風の対話体験を開発者が簡単に再現できる基本的な API といえます。

メッセージには以下の3種類のロールを付与できます。ロール付きのメッセージをまとめて送ることで、各メッセージが user によって発信されたものなのか、それとも assistant によって応答されたものなのかを判別できます。

1-1-2. 課題①: 履歴の再送

1つ目の課題は「履歴の再送」です。

モデル自体にはステートレス（状態を保持しない）という特性があり、各リクエスト間で会話コンテキストを保持できません。そのため開発者は毎回のリクエストで全会話履歴を送信する必要があります。例えば10ターンの会話では、10番目のリクエスト時に前9回分の全履歴を含める必要があるのです。

Chat Completions API でも同様に、下記のコードのように、会話履歴の管理を開発者が必ず自前で行うことになります。

どのようなケースにおいても、モデルに何かを問い合わせるときは毎回、今までの会話履歴を一度まとめてから伝えるしかありませんでした。

import os
from google.colab import userdata
from openai import OpenAI

os.environ["OPENAI_API_KEY"] = userdata.get("OPENAI_API_KEY")
client = OpenAI()

messages = [{"role": "system", "content": "あなたは有能な BizDev です。"}] # 管理する対象の会話履歴

def ask(q: str):
    messages.append({"role": "user", "content": q})
    res = client.chat.completions.create(model="gpt-4.1-nano", messages=messages)
    messages.append({"role": "assistant", "content": res.choices[0].message.content})
    print("送信メッセージ数:", len(messages))  # 今までの会話を都度まとめる必要あり -> 雪だるま式に増加していく
    return res.choices[0].message.content

response1 = ask("新規事業とは？")
print("回答1:", response1)

print("\n---------------------------\n")

response2 = ask("その難しさとしてどのような点が挙げられますか？")
print("回答2:", response2)

1-1-3. 課題②: Function Calling の往復

2つ目の課題は Function Calling にあります。

Function Calling とは、モデルに外部の関数を使わせて回答させる仕組みです。

例えば「仙台の天気は？」と質問したとき、モデルは現在の天気を知らないため、直接回答する代わりに外部の関数を呼び出すことを開発者に提案します。開発者はその提案を受け、実際に天気を取得する関数を呼び出して「仙台は26°C、晴れ」というデータを取得し、その結果をモデルに戻します。すると、モデルはこの情報を使って「仙台は現在26°C、晴れています」のように自然な返答を作成できます。

Chat Completions API では、どのようなケースにおいても、この一連の流れを「中間応答（関数の呼び出しを提案）→ 最終応答（関数の呼び出し結果を考慮）」という2ラウンドのリクエストとして実装する必要がありました。

import os
import json
from google.colab import userdata
from openai import OpenAI

os.environ["OPENAI_API_KEY"] = userdata.get("OPENAI_API_KEY")
client = OpenAI()

# 呼び出し可能な関数を定義
tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "都市の現在の天気を取得する",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "都市名"}
            },
            "required": ["city"]
        }
    }
}]

# ユーザーからの質問を受け取る
user_question = "仙台の天気は？"
messages = [
    {"role": "system", "content": "あなたは天気情報を提供するアシスタントです。"},
    {"role": "user", "content": user_question}
]

# モデルへの質問（第1ラウンド）- どの関数を呼び出すべきか提案してもらえるかも
first_response = client.chat.completions.create(
    model="gpt-4.1-nano",
    messages=messages,
    tools=tools
)

# モデルの回答を確認
assistant_message = first_response.choices[0].message
print(f"ユーザーの質問: {user_question}")

if assistant_message.tool_calls:
    # モデルが関数呼び出しを提案
    tool_call = assistant_message.tool_calls[0]
    function_name = tool_call.function.name
    arguments = json.loads(tool_call.function.arguments)
    
    print(f"モデルの提案: {function_name}関数を使うべきです。")
    print(f"関数の引数: {arguments}")
    
    # 関数の呼び出し（サンプルとしてダミーデータを返す）
    weather_data = {"city": arguments["city"], "temperature": "26°C", "condition": "晴れ"}
    print(f"関数の実行結果: {weather_data}")
    
    # 関数の呼び出し結果をモデルに戻す
    messages.append(assistant_message)  # モデルの提案をメッセージ履歴に追加
    messages.append({
        "role": "tool",
        "tool_call_id": tool_call.id,
        "name": function_name,
        "content": json.dumps(weather_data)
    })
    
    # モデルへの質問（第2ラウンド） - 最終的な回答
    second_response = client.chat.completions.create(
        model="gpt-4.1-nano",
        messages=messages
    )
    
    # 関数の呼び出し結果を踏まえた最終的な回答
    print(f"モデルの回答: {second_response.choices[0].message.content}")
else:
    # 関数を呼び出さずに直接回答
    print(f"モデルの回答: {assistant_message.content}")

ちなみに、上記のコードサンプルにおける user_question = "仙台の天気は？" を user_question = "好きな食べ物は？" に変更すると、モデルは関数の呼び出しを提案せずに直接回答してきます。

1-2. Assistants API が抱える課題

この節では、サーバ側で履歴とツールを管理する Assistants API の構造と、その実装コストを確認します。

1-2-1. Assistants API とは

Chat Completions API では、会話履歴を自前で保持し、ツールも自分で定義して呼ぶ必要がありました。そこで 2023 年 11 月に β 提供が始まったのが Assistants API です。
OpenAI 公式は次のように説明しています。

“The Assistants API enables developers to easily build powerful AI assistants within their apps.
It removes the need to manage conversation history and adds access to OpenAI-hosted tools like Code Interpreter and File Search.”

つまり Assistants API は

• 会話履歴の保存・管理をサーバ側に任せられる
• Code Interpreter（Python 実行）や File Search (ファイル検索) などの組み込みツールをサクッと一度の呼び出しで使える

という新たな特徴を有していました。

Assistants API は Assistant（設定オブジェクト）、Thread（会話履歴）、Run（応答生成ジョブ） という3種類のオブジェクトで構成されます。

1-2-2. 課題①: 煩雑な ID 管理

開発者は Assistant ID、Thread ID、Run ID を同時に扱う必要があります。3種類のオブジェクトを常に並行して管理しながらモデルとやりとりすることになるので、なかなかに煩雑です。

以下の例では3種類のオブジェクトを生成し、その ID を取得しています。

import os
from google.colab import userdata
from openai import OpenAI

os.environ["OPENAI_API_KEY"] = userdata.get("OPENAI_API_KEY")
client = OpenAI()

# アシスタントに指示を追加
assistant = client.beta.assistants.create(
    model="gpt-4o-mini",
    instructions="あなたは役立つアシスタントです。"
)

thread = client.beta.threads.create()

# スレッドにメッセージを追加
message = client.beta.threads.messages.create(
    thread_id=thread.id,
    role="user",
    content="こんにちは"
)

# 実行
run = client.beta.threads.runs.create(
    thread_id=thread.id,
    assistant_id=assistant.id
)

print(assistant.id, thread.id, run.id)

1-2-3. 課題②: ポーリングの手間

Run はバックグラウンドで進行するため、完了を確認するまで状態を取得し続ける（ポーリングする）必要があります。

import os, time
from google.colab import userdata
from openai import OpenAI

os.environ["OPENAI_API_KEY"] = userdata.get("OPENAI_API_KEY")
client = OpenAI()

assistant = client.beta.assistants.create(
    model="gpt-4o-mini",
    tools=[{"type": "code_interpreter"}])
thread = client.beta.threads.create()

client.beta.threads.messages.create(
    thread_id=thread.id,
    role="user",
    content="Pythonのバージョンを確認し、インストールされている主要なパッケージの一覧を表示するコードを書いて実行してください。")

run = client.beta.threads.runs.create(thread_id=thread.id, assistant_id=assistant.id)
while run.status != "completed":
    time.sleep(1)
    run = client.beta.threads.runs.retrieve(thread_id=thread.id, run_id=run.id)
print("Run 完了:", run.status)

# アシスタントの応答を取得して表示
messages = client.beta.threads.messages.list(thread_id=thread.id)
for message in messages.data:
    if message.role == "assistant":
        print("\nアシスタントの応答:")
        for content in message.content:
            if content.type == "text":
                print(content.text.value)

1-3. Responses API による解決

ここでは、上記に列挙した従来の API にまつわる課題を Responses API がどのようにシンプルにするかを示します。

1-3-1. Responses API の登場

2025年3月に正式リリースされた Responses API は、Chat Completions API の手軽さと Assistants API のツール連携を 1 つの API に統合したものです。client.responses.create() を 1 回呼び出すだけで、会話の保持・ツール呼び出し・最終応答生成までをまとめて処理できます。

たとえば、会話履歴の管理を OpenAI のバックエンドに任せることができ、開発者は会話履歴の管理を必ずしも自前で行わなくてよくなりました。（👉 後述の 2-1 節を参照）

また、OpenAI の組み込みツールを呼び出す際は、バックエンドが使うべきツールの提案から結果の応答までを1ラウンドの呼び出しで自動で行ってくれます。（👉 後述の 2-2 節を参照）

Responses API で利用可能な OpenAI の組み込みツールとしては、現在だと以下のようなものがあります。

• Web search (インターネットを検索して回答)
• File search (アップロードされたファイルを文脈として回答)
• Computer use (コンピューターの操作を実行）

他にも、Assistants API よりもシンプルなインターフェースとなっており、格段に開発がしやすくなりました。（👉 後述の 3-1 節と 3-2 節を参照）

1-3-2. これからのスタンダード

OpenAI は「Chat Completions API は今後も無期限でサポートする」と表明しつつ、新機能は基本的に Responses API に追加していく方針です。その一方で Assistants API は 2026 年前半に提供終了する計画が示されており、機能の完全統合が済み次第、正式な廃止告知が行われます。

移行ガイドラインは次のとおりです。

• 新規開発: 最初から Responses API を採用することが推奨されます。
• Chat Completions API を利用中のプロジェクト: 履歴が肥大化したり複数ツールを併用したりする場面で順次 Responses API に置き換えると、管理コストを抑えられます。
• Assistants API を利用中のプロジェクト: 2025 年中にパイロット移行を開始し、2026 年前半までに本番環境を切り替えるスケジュールが推奨されています。OpenAI はコード変換 CLI と詳細ドキュメントを順次公開予定です。

要するに、Chat Completions API は残るものの、今後の拡張は Responses API が中心となり、Assistants API については 2026年に終了することになります。これが現時点での公式ロードマップです。

2. Chat Completions API vs Responses API

Chat Completions API と Responses API を比較してみましょう。

2-1. 履歴の再送

Chat Completions API では全ての会話履歴を手動で管理していましたが、Responses API ではこれを OpenAI のバックエンドに管理を一任させることが可能です。

開発者はstore=True オプションでバックエンドに履歴の保持を依頼し、次のターンの会話は単に previous_response_id を指定して引き継げばいいだけになりました。

import os
from google.colab import userdata
from openai import OpenAI

os.environ["OPENAI_API_KEY"] = userdata.get("OPENAI_API_KEY")
client = OpenAI()

# 最初のリクエスト - store=True で会話履歴を保存
first = client.responses.create(
    model="gpt-4.1-nano",
    input="新規事業とは？",
    store=True  # 会話履歴をサーバー側に保持させる設定
)
print(first.output_text)

print("\n---------------------------\n")

# 二回目のリクエスト - previous_response_id で前回の会話を参照
second = client.responses.create(
    model="gpt-4.1-nano",
    previous_response_id=first.id,  # 前回の応答IDを指定するだけで履歴を継承
    input="その難しさとしてどのような点が挙げられますか？"
)
print(second.output_text)

2-2. Function Calling の往復

Chat Completions API では2ラウンドのリクエスト往復が必要だった Function Calling も、Responses API では1回のリクエストで完結する場合があります。それは web_search_preview (Web検索) や file_search (ファイル検索) といった OpenAI の組み込みツール (関数) を Function Calling の対象とする場合です。

これらの便利なツールの呼び出しにおいては、OpenAI のバックエンドで Function Calling が自動的に処理されるため、開発者はたった1回のリクエストで完全な応答を得ることができます。エラーハンドリングも簡素化され、実装コードは約半分になるため、開発効率と保守性が飛躍的に高まります。

import os
from google.colab import userdata
from openai import OpenAI

os.environ["OPENAI_API_KEY"] = userdata.get("OPENAI_API_KEY")
client = OpenAI()

result = client.responses.create(
    model="gpt-4.1-mini",
    tools=[{"type": "web_search_preview"}],
    input="最新の Node.js の安定版は？ 出典付きで")
print(result.output_text)

Chat Completions API ではそもそも開発者が独自に定義する関数 (先程の例でいう get_weather)しか Function Calling の対象とすることができず、呼び出しに至るまでは必ず2ラウンドの冗長なやりとりを実装する必要がありました。

3. Assistants API vs Responses API

ここでは Assistants API の煩雑な ID 管理とポーリングが、Responses API によってどのように改善されるかを簡単に示します。

3-1. 煩雑な ID 管理

Responses API では Assistant や Thread 、Run といったオブジェクトを個別に定義する必要がなくなりました。

組み込みツールも簡単に呼び出すことができます。

import os
from google.colab import userdata
from openai import OpenAI

os.environ["OPENAI_API_KEY"] = userdata.get("OPENAI_API_KEY")
client = OpenAI()

result = client.responses.create(
    model="gpt-4.1-mini",
    tools=[{"type": "web_search_preview"}],
    input="Open AI API で利用可能な最新モデルは？ 出典付きで")
print(result.output_text)

3-2. ポーリングの手間

Responses API では Run という概念がなく、応答は同期的に返るためポーリングは不要です。上記コードのように 1 リクエストで結果が取得できます。非常に簡単となりました。

この同期的な仕組みはコードを大幅に簡略化しますが、注意点もあります。特に処理時間が長くなる可能性がある場合（複雑な関数呼び出しや大規模なWeb検索を伴う場合など）は、リクエストのタイムアウト設定に注意が必要です。実運用では、クライアント側でのタイムアウト処理やユーザーへの適切なフィードバック表示などを検討することが重要となるでしょう。

また、同時に多数のリクエストを処理する高負荷なアプリケーションの場合は、非同期処理や適切なバックグラウンドジョブ管理を組み合わせて実装することも検討すべきです。シンプルさと拡張性のバランスを取りながら設計することが、本番環境での安定稼働には欠かせません。

4. まとめ

Responses APIの最大の魅力は、その圧倒的な簡潔さにあります。

従来の API と比較して簡単に迷わず LLM と統合できるシンプルさは、開発スピードの向上と保守のしやすさに直結します。

AI の社会実装において、開発スピードは単なる効率化ではなく、ビジネス成功の鍵です。市場のニーズや技術トレンドが急速に変化する現代においては、アイデアを素早く MVP として形にし、ユーザーからのフィードバックを得て改善を繰り返すサイクルが重要になります。

株式会社 Biz Freak では、AIの社会実装と新規事業に特化したアジャイル開発「バクソク」を提供しています。

👉 <News> 新規事業開発の体験そのものをアップデートする「バクソク」において、Biz Freak 独自の製品である「バクソクボード」が、このたび特許を取得しました：https://bizfreak.co.jp/news/4fvfgv3tpou

Responses API のような最新技術を活用しながら、ONE TEAM な伴走型アジャイル開発を回すことで、新規事業のアイデアをより早く着実に PMF へと導きます。