1 年前、OpenAI は、開発者や企業が実用的で信頼できるエージェントを構築するための基盤として Responses API を発表しました。モデルがホスト型のツールを使えるようになったことで、AI はチャットで応答するアシスタントから、ユーザーに代わって行動できるシステムへと進化しました。現在の Responses API は、エージェントのワークフローを支えるさまざまなツールに加え、より高性能なモデルを使った開発に向けて設計された新機能や基本要素を提供しています。
現在、数千人の開発者が Responses API を活用し、カスタマーサポート、法務、ライフサイエンス、旅行など、幅広い分野で生産性を高めています。これまでにも各分野の成功事例を数多く紹介してきました。今回は、この 1 年間に Responses API を使ってプロダクトを開発した人々に焦点を当て、これまであまり語られてこなかった 5 つの事例を紹介します。
AI エージェントの不具合の検出と修正
Raindrop AI の Alexis Gauba 氏と Ben Hylak 氏
ツール： 自社開発ツール
モデル： GPT-5.2（GPT-5.4 をテスト中）
Raindrop は、世界の先進的な AI 企業が、本番環境でエージェントの挙動が想定から外れたことを検知するために使っている監視プラットフォームです。エージェントの複雑化に伴い、こうした不具合の影響も大きくなっています。
Responses API がなければ、このような監視システムを構築するのははるかに難しく、信頼性も大きく劣っていたでしょう。
Raindrop は Vercel AI SDK 経由で Responses API を利用し、バックグラウンドで分析を実行します。この構成なら、モデルのプロバイダーが異なってもツールを共用でき、システムを別の環境に移すこともできます。分析ワークフローは通常とは異なる挙動を捉えます。問題が起きると、システムは開発者に通知し、原因の特定を支援します。
このプラットフォームの中核をなすのは、次の 3 つのシステムです。
- エージェントの挙動の監視
- 不具合の検出と通知
- 開発者向けの調査・デバッグツール
これらを組み合わせることで、チームは AI エージェントの問題を発見して追跡し、本番システムに影響が及ぶ前に修正できます。
監視アーキテクチャ
この構成により、チームはエージェントの挙動を継続的に監視し、問題の発生時にすばやく対応できます。
1. エージェントの挙動の監視
システムはエージェントの挙動を継続的に評価し、想定どおりに動作しているかを判定します。
開発者は、どのような結果を望ましくないと判断するかを条件として設定できます。その条件が満たされたときに、プラットフォームがアラートを発することができます。
2. 不具合の検出と通知
異常を検出すると、Raindrop は開発者に通知し、調査に必要な関連情報を提示します。
プラットフォームには、次の作業に使えるツールが用意されています。
- エージェントのバージョン間での挙動の変化を追跡
- 不具合のきっかけとなったプロンプトやシステムの変更を特定
- 推論のトレースやツール呼び出しを確認
これにより、開発者は不具合の根本原因をすばやく特定し、修正をデプロイできます。
3. 調査・デバッグツール
Raindrop は、エージェントのワークフローで発生した問題の診断を支援するツールも提供しています。これらを使うことで、チームは不具合の検出をシステムの改善につなげられます。
Raindrop AI は、バックグラウンドで長時間実行するすべての分析ワークフローに Responses API を使用しています。この API がなければ、こうした監視システムの実装ははるかに難しくなっていたでしょう。
複雑なデータを深く分析する推論ワークフロー
Repo Prompt の Eric Provencher 氏
使用ツール： App Server と MCP を組み合わせた Codex、ウェブ検索
使用モデル： GPT-5.3-Codex
計画やレビューの際、必要な情報を探すだけでリーズニングモデルのコンテキストウィンドウを浪費してしまうことがあります。そこで、別のエージェントがあらかじめコンテキストを選び、整理するようにしました。こうすれば、リーズニングモデルは課題の解決にできるだけ多くの推論能力を割けます。
Eric Provencher 氏が構築したシステムは、大量の文書や大規模なコードベース、データセットを詳しく分析する開発者や研究者を支援します。
Repo Prompt が重視するのはコンテキストエンジニアリングです。関連情報を自動的に収集、整理し、リーズニングモデルが効果的に分析できるように構造化します。
多くのエージェントシステムがデータ収集に重点を置く一方、Provencher 氏はコンテキストの収集と深い推論を切り分けました。まずエージェントのワークフローで関連するコンテキストをまとめ、選び抜いた情報を分析専用のリーズニングモデルに渡します。
このプラットフォームは OpenAI の Responses API を使い、次のような用途で、長時間にわたるエージェントのワークフローや推論ジョブの実行を調整しています。
- 大規模なコードベースの分析とアーキテクチャの設計
- コードを詳細にレビューするワークフロー
- 大量の文書を対象とした調査・分析
- 医学・科学文献の分析
システムは、コンテキストを構築するエージェントのワークフロー、深い推論を担うリーズニングモデル（「Oracle」ワークフロー）、調査と分析を繰り返すループという 3 つの要素を中心に構成されています。
1. コンテキスト構築エージェントのワークフロー
最初の段階を担うのは、コンテキストを構築するエージェントです。このワークフローでは、大規模なデータリポジトリを分析し、どの情報が与えられたクエリに関連するかを判断します。
エージェントは Responses API を通じてツールとモデルの推論能力を活用し、関連するファイルや文書間の関係、資料の中で特に重要な箇所を特定します。
この段階で得られるのは、コンテキストを構造化してまとめたパッケージです。これが次の推論段階への入力になります。
2. 「Oracle」の深い推論ワークフロー
コンテキストを構築するエージェントとは異なり、深い推論を担う「Oracle」モデルはツールを呼び出したり、情報を追加で取得したりしません。選別・整理されたコンテキストを受け取り、その分析に専念します。
調査と推論を分けることで、モデルは推論能力のすべてを問題の理解に充てられます。多くのワークフローでは、推論段階を長時間実行し、与えられたコンテキストに含まれる複雑な関係を分析できます。
3. 調査と分析を繰り返すループ
このシステムでは、推論を繰り返すこともできます。リーズニングモデルが結果を出すと、別のエージェントがその内容を確認し、追加調査が必要かどうかを判断できます。
必要に応じて、システムは再びコンテキストを収集し、推論を実行します。このループにより、長時間にわたる調査で、段階的に分析の精度を高められます。
反復型ワークフロー
システムを支える Responses API の主な機能は次のとおりです。
- バックグラウンドジョブ：数分から数時間にわたる推論タスクを実行
- エージェントのオーケストレーション：コンテキストの収集、推論、検証を担うエージェントのループを調整
- オブザーバビリティ：長時間にわたる推論ワークフローを実行中に監視・管理
このプラットフォームでは、Codex モデルが関連するコンテキストを収集して構造化し、さらに高性能なリーズニングモデルがその情報を受け取って詳しく分析します。こうした機能が、エージェントのワークフローと深い推論を担うモデルを組み合わせたハイブリッドな構成を可能にしています。
レコードコレクターのための対話型インターフェース
Collxn の Ash Ryan Arnwine 氏
ツール： ウェブ検索と 16 個のカスタムツール
モデル： GPT-5.4、GPT-5 nano
検索拡張生成のシステムを一から構築するといった方法に比べて、Responses API を使うと、自分の手で行う作業が減ったと感じました。
Ash Ryan Arnwine 氏が開発した「Collxn」（「コレクション」にちなんだ名前です）は、小さなサービスながら大きな目標を掲げています。コレクターが自分の棚にあるレコードの魅力を再発見し、その一枚と対話できるようにすることです。
コレクターの多くは Discogs で膨大な数のレコードを管理しており、数千枚を所有する人もいます。Collxn はそのコレクションと連携し、「Daily Drop」というメールを毎日配信します。日替わりでレコードを 1 枚取り上げ、アーティストの情報とともに紹介することで、すでに持っている音楽を聴き直すきっかけを作ります。
レコードをめくりながら気になったことを尋ねられたら、楽しみはさらに広がります。そこで Collxn は OpenAI の Responses API を使い、ユーザーが文字どおりレコードと会話できるチャットインターフェースを実現しました。
ツール呼び出しを使った対話型インターフェース
このアプリは Responses API を使い、「Ask This Drop」というチャットインターフェースを提供しています。ユーザーは Daily Drop で紹介されたレコードについて質問できます。
モデルには Discogs API を使うツールへのアクセス権があり、質問に答える際に Discogs から直接情報を取得できます。
たとえば、次のような質問ができます。
- このレコードの今の相場はいくらですか？
- このアーティストはほかにどんなアルバムを出していますか？
- このプレス盤はどのくらい珍しいですか？
Ask This Drop を使うと、Collxn ユーザーはチャットを通じて自分のレコードと対話できます。
コレクターが質問すると、Discogs のリアルタイムデータと、自分のレコードコレクションから得られるコンテキストを組み合わせた回答が返ってきます。
こうして、一覧として眺めていたレコードコレクションが、より広い音楽の世界とつながる対話の場に変わります。
Daily Drop とアーティストのニュース
Collxn は OpenAI Agents SDK も利用し、Daily Drop のメールで取り上げるアーティストの「最新ニュース」欄を生成しています。
Collxn の Daily Drop では、OpenAI Agents SDK を使ってアーティストのニュース欄を生成しています。
この機能では、エージェントがウェブ検索を使ってアーティストに関する最近の記事や新しい情報を探し、毎日のメールに加えます。レコード収集を楽しみながら音楽界の今の動きにも触れられるため、ニュース欄はベータ版ユーザーの間でたちまち人気機能のひとつになりました。
最終的に Arnwine 氏は「Ask This Drop」の提供に向けて、Collxn を Responses API に移行しました。これにより、会話の中で複数段階の推論を行い、組み込みツールとカスタムツールの両方を呼び出せるようになりました。Collxn では Responses API の組み込みウェブ検索ツールを使って、チャット内でアーティストのニュースを検索します。これに加え、Discogs API の操作やユーザーの Collxn アカウントへの照会などに 16 個のカスタムツールを使用しています。
Collxn の「Ask This Drop」では、Responses API のウェブ検索ツールを使い、その場でアーティストの最新ニュースを調べられます。
Responses API が会話の状態を保持できるため、複数ターンにわたるチャットも、より簡単かつ高速に処理できます。Arnwine 氏によると、検索拡張生成（RAG）システム全体を自前で構築する場合に比べ、Responses API を使うことでアーキテクチャを簡素化できたといいます。
画面録画から対話型の製品デモへ
Arcade チームの Nick Sorrentino 氏と Pawel Wszola 氏
ツール： コンピューターの使用
モデル： GPT-5.2、computer-use-preview
API を使ったコンテンツ生成を組み込んだことで、デモの公開に必要な手順が 50% 減り、公開率と製品の利用率が大幅に上がりました。
Arcade は、多くのチームが日頃から行っている画面録画を、完成度の高い対話型の製品デモに変えます。製品を実演しながら説明したり、手順を一つずつ文書にまとめたりする代わりに、チームは一連の操作を一度録画するだけです。あとは Arcade が処理します。
Arcade は内部で録画を分析し、それぞれのステップで何が起きているかを説明する操作ガイドを自動生成します。
デモ生成のワークフロー
録画からデモができるまでの流れは次のとおりです。
- ユーザーが一連の操作を行いながら画面を録画します。
- デスクトップやブラウザでは、Arcade がクリック、文字入力、スクロールなどの操作を構造化データとして直接記録します。
- モバイルでは、iOS のサンドボックスにより、アプリがシステム全体の操作を記録できません。そのため、ユーザーはアプリの画面を通常の動画として録画します。
- 録画を OpenAI の Responses API に送信すると、「コンピューターの使用」ツールが動画の各フレームを分析し、どのような操作が行われたかを推定します。
- システムは推定した操作を構造化されたステップに変換します。
- Arcade が説明文と、視聴者が操作しながらデモを進めるためのホットスポットを生成します。
こうして各ステップが自動的に組み合わさり、ユーザーが実際に操作できるガイドになります。
続いて、構造化された操作データを Chat Completions API に渡すと、デモの各所に表示するタイトルとホットスポットの説明文が生成されます。ユーザーは組み込みの AI 編集ツールを使って、文章を短くしたり、表現を書き換えたりできます。
デモ公開までの操作数を半減
デモの説明文の作成を自動化したことで、製品の操作ガイドを公開するまでの手間が大幅に減りました。
API を使ったワークフローの導入後、次の変化が見られました。
- 公開までに必要な操作数の中央値が 50% 減少
- 操作数の 80 パーセンタイル値が約 230 回から約 120 回に減少
- デモの公開率と製品の利用率が向上
デモ作成の手間が減り、チームは録画した素材から完成度の高い対話型デモを作るまでの時間を大幅に短縮できるようになりました。
AI の回答におけるブランド露出の測定と改善
Hexagon の Tunde Adeyinka 氏と Ramon Silva 氏
使用ツール： ウェブ検索
使用モデル： GPT-5.2 Chat
Tunde Adeyinka 氏と Ramon Silva 氏は、小売業者が直面する新たな問いに答えるために Hexagon を設立しました。AI アシスタントは自社の商品をどのように紹介しているのでしょうか？
消費者が商品を見つける過程で、AI アシスタントの影響力が増しています。Hexagon は、AI が生成する回答の中で自社ブランドがどのように取り上げられているかを企業が把握し、継続的に改善できるよう支援します。
このプラットフォームは OpenAI の Responses API を使って、中核となる 3 つのシステムを動かしています。
1. 回答シミュレーションのアーキテクチャ
Hexagon は、商品に関する質問に AI アシスタントがどう答えるかを測定するため、シミュレーションのパイプラインを毎日実行しています。消費者が実際に入力しそうなプロンプト、おすすめの商品を尋ねるプロンプト、買い物に関するクエリを毎日数千件生成し、Responses API に送信します。得られた出力を分析し、AI の回答全体でブランドがどれだけ取り上げられているかを追跡します。
この結果から、小売業者は自社の商品が登場する頻度と、回答の内容が時間とともにどう変化するかを確認できます。
2. 複数のエージェントによるコンテンツ生成パイプライン
Hexagon は分析に加え、AI の回答でブランドが取り上げられやすくなるよう最適化したコンテンツの生成にも Responses API を活用しています。
このシステムには 4 つのエージェントがあり、それぞれがパイプラインの特定の工程を担当します。各エージェントが結果を次の工程に引き渡し、最終的なコンテンツの生成と公開まで進めます。公開前には、エージェント同士が非決定的なループを通じてやり取りし、コンテンツを繰り返し改善します。
3. ダッシュボードと顧客向けツール
このプラットフォームには、Responses API の Function Calling を使って構築したチャットボット「Hexi」もあります。顧客は Hexi と対話しながら分析結果を掘り下げ、AI の回答における自社ブランドの露出データを自分で要約できます。Hexagon は分析結果を小売業者向けのダッシュボードに表示し、AI の回答で商品がどのように取り上げられているかを追跡できるようにしています。
Hexagon は、製品全体で実態に即した有用なシミュレーションを行うために、Responses API の次の機能を活用しています。
- ウェブ検索：ChatGPT と同様に、ウェブを閲覧して得た情報に基づく回答を再現します。
- ユーザーの位置情報パラメーター：異なる地域からのクエリをシミュレーションし、地域による回答の違いを検証します。
- 推論強度：回答の深さと複雑さを調整します。
- 最大出力トークン数：長文を出力する際に回答の長さを制限します。
- コンテキストの保持：複数の呼び出しにわたってコンテキストを保持し、複数のエージェントによるワークフローを可能にします。
Responses API を使うことで回答の質が向上し、複数の呼び出しにわたってコンテキストをより確実に保持できるようになりました。どちらも、Hexagon のプラットフォームを支える複数段階のパイプラインには欠かせません。
おわりに
提供開始から 1 年が経ち、Responses API は、エージェントを活用したソフトウェアを開発するうえで中核となる基盤になりました。
今回紹介した 5 つの事例からは、開発の現場で何が実現しているかが見えてきます。複数のエージェントが連携してツールを使い分け、バグを検出し、ワークフローを実行する仕組みが生まれ、開発者は AI を活用したプロダクトを世に送り出しています。
プラットフォーム自体も急速に進化しています。オーケストレーション機能が向上し、ツールのエコシステムも充実してきました。たとえば、ネットワーク接続に対応した OpenAI のホスト型コンテナやシェルツールが新たに加わりました。
使えるツールが増えています。
できることが広がっています。
そして、私たちがまだ思いついていないものを形にする開発者も増えています。
2 年目には開発者の手から何が生まれるのか、楽しみです。