Responses API を使用すべき理由

以下の記事が面白かったので、簡単にまとめました。

1. Responses API 

「GPT-5」が登場した今、「Responses API」はGPT-5を統合するための最良の方法です。Reasoningモデルとエージェントに特化して設計されています。

「OpenAI API」の設計は、常にモデル自体の動作に基づいてきました。最初の 「Completions API」(/v1/completions) はシンプルでしたが、制限がありました。モデルにプロンプ​​トを与えると、モデルは単に考えを最後まで言い終えるだけでした。開発者はFew-Shotなどの手法を用いて、JSON出力や質問への回答といった処理をモデルに指示しようと試みましたが、これらのモデルは今日のものよりもはるかに能力が低いものでした。

その後、「RLHF」「ChatGPT」「ポストトレーニング」の時代が到来しました。モデルは書きかけの文章を完成させるだけでなく、会話パートナーのように応答するようになりました。これに追随するため、「Chat Completions API」(/v1/chat/completions) を構築しました。system、user、assistantといったロールを与えることで、カスタム指示とコンテキストを備えたチャットインターフェースを構築するための基盤を提供しました。

モデルは進化を続け、モデルは見たり、聞いたり、話したりするようになりました。2023年後半に導入された「Function Calling」は、最も好評な機能の1つとなりました。同時期に、「Assistant API」のベータ版をリリースしました。これは、コードインタープリタやファイル検索などのホスト型ツールを備えた、完全なエージェントインターフェースへの最初の試みでした。一部の開発者からは好評を得ましたが、「Chat Completion API」に比べてAPI設計の制限が多く、導入が困難だったため、大規模な導入には至りませんでした。

2024年後半には、統合が必要であることが明らかになりました。「Chat Completions API」のように使いやすく、「Assistant API」のように強力でありながら、マルチモーダルでReasoningモデルに特化したもの。そこで 「Responses API」(/v1/responses) が登場しました。

2. Responses API は エージェントループ

「Chat Completions API」はシンプルなターンベースのチャットインターフェースを提供していましたが、「Responses API」は、Reasoningと行動のための構造化されたループを提供します。これは、探偵に依頼するのに似ています。証拠を提示し、探偵は調査を行い、専門家 (ツール) に相談し、最終的に報告します。探偵は各ステップ間で個人的なメモ (Reasoning状態) を保持しますが、依頼者には決して渡しません。

そして、ここでReasoningモデルが真価を発揮します。「Responses API」は、各ターンを通してモデルのReasoning状態を保持します。「Chat Completions API」では、探偵が部屋を出るたびに手がかりを忘れてしまうように、各通話間でReasoningは中断されます。「Responses API」はノートブックを開いたままにするため、段階的な思考プロセスは次のターンまで保持されます。これはベンチマーク (TAUBench +5%) や、キャッシュ利用率とレイテンシの向上に表れています。

「Responses API」は、モデルが言ったことだけでなく、モデルが行ったことを含む複数の出力項目を生成することもできます。ツール呼び出し、構造化出力、中間ステップなどのレシートを取得できます。完成したエッセイとスクラッチパッドの計算結果の両方を入手できるようなものです。デバッグ、監査、そしてよりリッチなUIの構築に役立ちます。

・Chat Completions API
「Chat Completions API」は、リクエストごとに1つのメッセージを送信します。メッセージの構造には制限があります。

{
  "message": {
    "role": "assistant",
    "content": "I'm going to use the get_weather tool to find the weather.",
    "tool_calls": [
      {
        "id": "call_88O3ElkW2RrSdRTNeeP1PZkm",
        "type": "function",
        "function": {
          "name": "get_weather",
          "arguments": "{\"location\":\"New York, NY\",\"unit\":\"f\"}"
        }
      }
    ],
    "refusal": null,
    "annotations": []
  }
}

・Responses API
「Responses API」は多態的なアイテムのリストを出力します。モデルが実行するアクションの順序は明確です。開発者は、これらのうちどれを表示するか、ログに記録するか、あるいは完全に無視するかを選択できます。

  {
    "id": "rs_6888f6d0606c819aa8205ecee386963f0e683233d39188e7",
    "type": "reasoning",
    "summary": [
      {
        "type": "summary_text",
        "text": "**Determining weather response**\n\nI need to answer the user's question about the weather in San Francisco. ...."
      },
  },
  {
    "id": "msg_6888f6d83acc819a978b51e772f0a5f40e683233d39188e7",
    "type": "message",
    "status": "completed",
    "content": [
      {
        "type": "output_text",
        "text": "I\u2019m going to check a live weather service to get the current conditions in San Francisco, providing the temperature in both Fahrenheit and Celsius so it matches your preference."
      }
    ],
    "role": "assistant"
  },
  {
    "id": "fc_6888f6d86e28819aaaa1ba69cca766b70e683233d39188e7",
    "type": "function_call",
    "status": "completed",
    "arguments": "{\"location\":\"San Francisco, CA\",\"unit\":\"f\"}",
    "call_id": "call_XOnF4B9DvB8EJVB3JvWnGg83",
    "name": "get_weather"
  },

3. ホスト型ツールによるスタックの上位化

「Function Calling」の初期の頃、重要なパターンに気づきました。開発者はモデルを使ってAPIを呼び出すだけでなく、ドキュメントストアを検索して外部データソース (現在ではRAGと呼ばれています) を取り込んでいました。しかし、開発をはじめたばかりの開発者にとって、検索パイプラインをゼロから構築するのは困難でコストのかかる作業です。「Assistant API」では、file_searchとcode_interpreterという最初のホスト型ツールを導入しました。これにより、モデルはRAGを実行し、要求された問題を解決するコードを記述できるようになりました。「Responses API」ではさらに進化し、「Web検索」「画像生成」「MCP」を追加しました。ツール実行は、コードインタプリタやMCPなどのホスト型ツールを通じてサーバ側で行われるため、すべての呼び出しを独自のバックエンドにバウンスする必要がなく、レイテンシとラウンドトリップコストを削減できます。

4. Reasoningを安全に保持

ではなぜモデルの生の「CoT」(Chain of Thought) を難読化するために、これほどの手間をかける必要があるのでしょうか。「CoT」を公開して、クライアントが他のモデル出力と同様に扱えるようにする方が簡単ではないでしょうか。簡単に答えると、生の「CoT」を公開すると、幻覚や最終的なレスポンスでは生成されない有害なコンテンツなど、いくつかのリスクが生じます。そして OpenAI にとっては、競争上のリスクも生じます。

昨年末に 「o1-preview」をリリースした際、チーフサイエンティストの Jakub Pachocki がブログに次のように書いています。

「Responses API」は、以下の方法でこの問題に対処します。

5. Responses API が最適である理由

「Responses API」は、ステートフルでマルチモーダル、効率的になるよう設計されています。

6. Chat Completions API の今後

「Chat Completions API」は廃止されることはありません。もしうまく機能しているなら、使い続けてください。しかし、持続的なReasoning、ネイティブな感覚のマルチモーダルインタラクション、そしてダクトテープを必要としないエージェントループを求めるなら、「Responses API」こそが未来への道です。

7. 今後の展望

「Chat Completions API」が「Completions API」に取って代わったように、「Responses API」は開発者がOpenAIモデルを使って構築する際のデフォルトの方法になると考えています。「Responses API」は、必要なときにはシンプルに、必要なときには強力に、そして次のパラダイムが私たちに投げかけるどんな課題にも対処できるほど柔軟です。

「Responses API」は、今後数年間にわたってOpenAIが構築していくAPIになります。