GPT‑LiveをCodexで最速検証。iOSデモを数時間で作ってみた。

GPT‑Liveの仕組みとAPI実装を整理し、CodexでiOSデモを開発。会話速度・割り込み・タスク化まで一気に確かめる

新しい音声モデル「GPT‑Live」がAPIへ

こんにちは！ChatGPT・Codexの管理者をしている Codex ambassadorの鷹雄です。
最新の機能をいろいろテストしていたりするのですが、その中でリリースされたばかりのAPIについてデモアプリを作ってみた際の知見を共有できればと思います。

2026年7月、OpenAIは新しい音声モデルGPT‑Liveを発表し、ChatGPT Voiceで提供を開始しました。そして今回、開発者もAPIからこの新しい音声体験をアプリへ組み込めるようになりました。

OpenAIからは新しいモデルやサービスが次々と登場しています。気になる情報は増える一方で、日々の開発を進めながら、すべての新機能を自分で触って確かめるのは、なかなか簡単ではありません。

そこで今回は、発表資料を読むだけで終わらせず、Codexと検証用iOSアプリをつくりました。確かめたかったのは、会話のテンポ、返答への割り込み、会話からアプリの操作へつなぐ感覚です。まずGPT‑Liveと音声APIの仕組みを整理し、その後に実装とデモを紹介します。

GPT‑Liveは、何が新しいのか

GPT‑Liveは、ChatGPT Voiceを支える新世代の音声モデルです。特徴は、入力と出力を同時に扱うfull‑duplexの設計にあります。ユーザーの音声を受け取り続けながら、話す、聞き続ける、一時停止する、割り込む、ツールを呼ぶ、といった判断を継続的に行います。

一問一答ではなく、会話そのものを扱う

従来の音声UIは、「話し終える、文字にする、考える、読み上げる」という処理を順番に進めるものが中心でした。GPT‑Liveは会話を細かなターンへ分断せず、相づち、短い間、言い直し、割り込みを含む連続したやり取りとして扱います。

会話を続けながら、深い処理を委譲する

検索や深い推論が必要なときは、その処理を別のモデルへ委譲しながら、GPT‑Liveは会話の流れを維持できます。音声の応答速度と、複雑な処理の能力を一つのモデルへ無理に詰め込まない点も大きな特徴です。

どんなものをつくれるのか

• 音声エージェント：問い合わせ対応や予約を、会話しながらツール実行へつなぐ
• ハンズフリー操作：料理中、移動中、作業中に、声だけでアプリを操作する
• ライブ通訳・文字起こし：会話を止めず、翻訳音声や字幕をストリーミングする
• 会話から業務データへ：タスク、メモ、注文候補などを会話から構造化して確認する

公開されたAPIを、どう使うのか

GPT‑Liveは音声モデル、Realtime APIはアプリと音声モデルをつなぐための仕組みです。一度のリクエストで回答を待つREST APIとは異なり、会話中はステートフルなRealtimeセッションを維持し、音声とイベントを双方向にやり取りします。

• 接続：モバイルやブラウザはWebRTC、サーバー側の音声処理はWebSocket、電話はSIPを用途に応じて選びます。
• セッション：会話中は接続を維持し、音声、イベント、指示、会話状態を双方向に更新します。
• 音声対話：入力音声を送りながら出力音声を受け取り、発話検知や割り込みを一つの会話体験として扱います。
• Function calling：モデルが返した関数名とJSON引数をアプリ側で検証・実行し、結果を会話へ戻します。

モデルへ関数を登録すると、会話の中からfunction callとして関数名と引数を受け取れます。アプリ側は引数を検証して処理を実行し、必要なら結果を会話へ返します。今回のデモでは、この経路を「タスク候補をつくる」操作へつなぎました。

iOSアプリから保存までの全体像

1. バックエンドが標準APIキーを保持し、短命なクライアント認証情報をiOSへ渡す。
2. iOSアプリとOpenAIのRealtimeセッションが音声とイベントを双方向に送受信する。
3. モデルがタスク候補をfunction callとしてアプリへ返す。
4. アプリが引数を検証し、重複を除外して確認キューへ追加する。
5. ユーザーが承認した候補だけをローカルへ保存する。

実装に必要な6つの要素

1. 音声の入出力：マイクを取得し、会話向けの音声形式へ変換して送信。返ってきた音声を低遅延で再生する。
2. リアルタイム接続：会話セッションを開始し、音声とイベントを双方向にストリーミングする。
3. セッション設定：役割、話し方、発話検知、利用可能なツール、行動してよい境界を指定する。
4. Function calling：関数の引数を検証し、アプリの処理を実行して、その結果を会話へ返す。
5. 割り込みと状態管理：再生中の応答を止め、未再生音声や会話状態を矛盾なく扱う。
6. 確認と保存：モデルの出力を即時保存せず、候補として表示し、人の承認後に確定する。

重要なのは、モデルが返した内容をそのまま確定データにしないことです。function callingの引数をアプリ側で検証し、保存や送信などの書き込み操作ではユーザー確認を残す設計にしました。

Codexで検証用iOSアプリをつくってみた

今回の目的は、タスクアプリを完成させることではありません。GPT‑Liveの会話速度、割り込み、会話からアプリ操作へつなぐ感覚を短時間で確かめることです。その検証用UIとして、買い物について会話しながら、決まった内容だけをタスク候補にできるiOSアプリ「後で」をCodexとつくりました。

要件決定とレビューは自分で行いながら、設計、実装、デバッグ、実機検証をCodexと進め、数時間で動くプロトタイプまで到達しました。アプリは主役ではなく、新しい技術を実際に触って理解するための道具です。

1. 失敗させたくない条件を先に言葉にする

「会話中は保存しない」「決まった行動だけ候補にする」など、体験の境界を要件としてCodexへ伝えました。

2. 音声、UI、テストを小さな単位で進める

SwiftUIの画面、音声入出力、候補キュー、重複判定を分けて実装し、テスト結果と差分を確認しました。移動中はCodex Remoteから指示とレビューを続けました。

3. 実機の会話を、そのまま修正材料にする

「おすすめを聞いただけなのにタスクになる」といった具体的な失敗例を渡し、プロンプト、確認UI、重複排除を調整しました。

実際に動いた50秒デモ

ここからは、短時間の検証でどこまで動いたかをデモで確認します。スーパーで買いたいものを自然に話し、途中でおすすめの果物について相談しています。最初の発話からは5件の買い物候補が生成され、その後の会話で決めた「いちごを買う」だけが新しい候補として加わります。

▼相談から候補生成、会話の継続までを収録した50.7秒のデモ。

実機で確かめた、3つのポイント

仕様を読んだだけでは分からなかったのが、実際の会話でどの程度自然に感じられるか、そして音声からアプリの状態を安全に変えられるかでした。実機で繰り返し会話し、次の3点を確認しました。

1. 返答へ割り込んでも、会話を続けられる

相談の途中で言い直したり、モデルの返答へ割り込んだりしても、前後の文脈を保ったままやり取りを続けられました。音声UIを一問一答ではなく、会話のリズムとして設計できる感覚があります。

2. 会話を止めずに、候補をつくれる

対話を続ける役割と、発話からタスク候補を構造化する役割を分けました。候補作成の処理中も会話を止めないことで、「操作のために話す」のではなく「話していたら操作につながる」感覚に近づきます。

3. 会話の文脈を、アプリの状態へつなげられる

会話中は文脈を保つため、「それ」「じゃあ追加して」といった指示を扱いやすくなります。一方で、会話の文脈と保存すべきアプリの状態は分け、モデルの出力をそのまま確定データにはしません。

音声UIで大切なのは、賢い返答だけではありません。話すテンポを壊さず、行動へつなげられることです。

会話から保存まで、5つの境界を置く

音声モデルにすべてを任せず、候補化と保存の間にユーザー確認を残しました。モデルが返すのは「保存済みタスク」ではなく、あくまで候補です。

1. マイク入力：端末の音声を会話向けのPCMへ変換
2. 連続対話：話す・聞く・割り込むを一つの流れで扱う
3. タスク判定：実行意思が固まった発話だけを構造化
4. 確認キュー：候補を重複排除し、保存前に人が確認
5. 端末へ保存：承認されたタスクだけをローカルに追加

実装で工夫した3つの境界

プロトタイプで時間を使ったのは、通信をつなぐことだけではありません。普通の雑談と実行意思をどう分けるか、複数の候補をどう重複させないか、会話の速さを損なわずに安全な確認をどう挟むかを繰り返し調整しました。

1. 「おすすめ」はタスクにしない

「果物なら何がいい？」は相談で、「じゃあ、いちごを買う」は実行意思です。その境目が明確になるまでは会話を続けます。

2. 一つの発話から複数候補を分ける

にんじん、卵、じゃがいもを一つの長いタスクにせず、それぞれ追加・見送りできるカードへ分割します。同じ品物の言い換えは重複として除外します。

3. 保存前に、必ず人へ返す

音声認識や意図判定は間違える可能性があります。確認キューを設け、ローカル保存の直前にユーザーが判断できるようにしました。

LiveAudioIO.swift

let wireFormat = AVAudioFormat(
  commonFormat: .pcmFormatInt16,
  sampleRate: 24_000,
  channels: 1,
  interleaved: false
)

let converter = AVAudioConverter(
  from: inputFormat,
  to: wireFormat
)

inputNode.installTap(
  onBus: 0,
  bufferSize: 2_048,
  format: inputFormat
) { buffer, _ in
  guard let pcm16 = convert(buffer, using: converter) else { return }
  onInputAudio(pcm16)
}

ConfirmationQueue.swift

struct LiveTaskConfirmationQueue {
  private(set) var items: [PendingTaskConfirmation] = []

  mutating func enqueue(
    _ confirmation: PendingTaskConfirmation
  ) -> Bool {
    guard isActionable(confirmation.draft),
      !items.contains(where: {
        areDuplicates($0.draft, confirmation.draft)
      })
    else { return false }

    items.append(confirmation)
    return true
  }
}

実際のSwiftコードから、公開用に識別子の一部を簡略化して抜粋。接続処理や認証処理は含めていません。

公開アプリで必要になる認証と運用

標準APIキーはクライアントへ埋め込まず、公開アプリではバックエンドに保持します。Realtime APIでモバイルクライアントを接続する場合は、バックエンドが発行する短命なクライアント認証情報を使い、端末からWebRTCで接続する構成が公式に案内されています。さらに、接続の再開、タイムアウト、割り込み時の再生停止、エラー時の復帰までをアプリ側の状態として設計する必要があります。

Realtime API with WebRTC

Codexなら、新しいOpenAIサービスをすぐ試せる

新しいサービスが出るたびに、ドキュメントを読み、環境を整え、最小構成をつくるだけでも時間がかかります。Codexを検証パートナーにすると、調査、設計、実装、テスト、実機での修正という最初のループを短くできます。

今回も、GPT‑Liveの説明を読むだけではなく、「割り込めるか」「会話から操作へつながるか」という確認項目をCodexへ渡し、動くアプリにすることでサービスの特徴を具体的に理解できました。重要なのは完成品を一度で任せることではなく、何を確かめたいか、人が判断すべき境界はどこかを明確にすることです。

Codexへの依頼例

「この新しいAPIで何ができるか理解できる、最小のデモをつくってください。確認したいのは○○です。まず仕組みと必要な実装を整理し、その後に実装と検証を進めてください。」

最新のOpenAIサービスを、Codexと試してみよう

最初から製品を完成させる必要はありません。知りたい体験が一つ分かる小さなデモなら、新しいサービスを知識ではなく、動く体験として理解できます。気になるAPIやモデルが登場したら、ぜひCodexと一緒に試してみてください。

参考リンク

• OpenAI: Introducing GPT‑Live
• OpenAI API Docs: Changelog
• OpenAI API Docs: Realtime and audio
• OpenAI API Docs: Voice agents
• OpenAI API Docs: Realtime function calling