GPT-6 Astra導入で迫られるResponses API移行の判断

実務で判断すべきなのは、移行にどこまで開発工数を割くか、そして新しい制御機能によって、エージェント実行時の待機・修正・再実行にかかるコストを減らせるかです。

実際に何が変わったのか

リリース前に明らかになっていたAstraの姿は、アクセスが制限された研究モデルでした。9月のリリースでは、公開モデルID gpt-6-astra が付与され、料金が設定され、Chat CompletionsとResponsesの両方で利用できるようになりました。提供はOpenAIのTrusted Access Programに参加する企業から始まり、APIとより幅広いプランへのアクセスも数日中に順次拡大されます。

どのエンドポイントを選ぶべきかは、アプリケーションの用途で決まります。テキストだけを扱うChat Completions連携ならAstraを利用できます。一方、Astraから独自関数やOpenAIホスト型ツールを呼び出す連携では、Responses APIが必須です。

Responsesでは、アプリケーションとの契約そのものが変わります。Chat Completionsが受け取るのはメッセージのリスト、返すのは選択肢のリストです。対してResponsesは、型を持つItemをやり取りします。メッセージが1つのItem、function_callが別のItemとなり、ツールの実行結果は元のcall_idを付けたfunction_call_outputとして返します。

移行時には、見落としやすい点が2つあります。previous_response_idで処理をつないでも、トップレベルのinstructionsは引き継がれないため、毎回送り直す必要があります。また、Structured Outputsの指定先はresponse_formatからtext.formatへ移ります。移行ガイドには、パーサー、状態、ツール、ストリーミングに関する変更点が網羅されています。

Responses API移行では、2つの予算を考える

1つ目は開発工数です。本番環境のツールループは、エンドポイント、リクエストスキーマ、出力パーサー、関数定義、結果の対応付け、状態管理、ストリーミングイベント、ログ、リトライ、評価にまたがります。モデル名だけを変えても、必要な移行作業の大半は残ったままです。

2つ目は、完了したジョブ1件あたりのコストです。GPT-6 AstraのStandardにおける短いコンテキストの料金は、入力100万トークンあたり$10.00、キャッシュ済み入力が$1.00、キャッシュ書き込みが$12.50、出力が$50.00です。GPT-5.6 Solの現行プロモーション料金は、同じ4項目でそれぞれ$4.00、$0.40、$5.00、$20.00です。トークン量が同じなら、どの項目でもAstraは2.5倍になります。

エンドポイント自体に別料金はありません。請求額を構成するのは、モデルのトークン、従量課金の組み込みツール、自社のツール基盤、リトライ、そして途中で破棄された作業です。入力が272,000トークンを超えるプロンプトでは、Astraリクエスト全体の入力料金とキャッシュ料金が2倍、出力料金が1.5倍になります。現在の料金ページにあるこれらの数字を、パイロット導入の予算に織り込んでください。

コスト増を相殺できる可能性はありますが、自社データでの検証が欠かせません。OpenAIは、社内テストにおいてResponsesのキャッシュ利用効率がChat Completionsより40%〜80%高かったと報告しています。また、Astraはトークン単価が高い一方、出力トークンが少なかったため、複数の評価でタスクあたりのAPI推定コストが低下したともしています。ただし、どちらもあらゆる用途で節約を保証する主張ではありません。

代わりに、次の指標を測ります。

cost per completed job = model tokens + built-in tool fees + your tool costs + retries + operator time

重要なのは分母です。単価の安い実行でも、終盤の修正で最初からやり直せば、完了結果1件あたりでは、有用な作業を維持できる高単価の実行より高くつくことがあります。

非同期ツール呼び出しで「待つ」ループが変わる

通常の関数呼び出しでは、アプリケーションが結果を返すまでモデルは一時停止します。Astraでは、アプリケーション側で実行する関数またはカスタムツールにasync: trueを指定できます。モデルは呼び出しを発行した後も推論を続け、別の独立したツールを呼び出したり、アプリケーションがジョブを実行している間に、依存しない部分へ回答したりできます。

それでも、処理の責任は自社サーバー側にあります。サーバーはジョブを開始してレジストリで管理し、元のcall_idを保存したうえで、後続のResponsesリクエストから結果を渡さなければなりません。結果が届く前に別のターンが進んだ場合、継続には最新のレスポンスIDを使いつつ、ツール出力は元の呼び出しIDを参照します。

リサーチ製品なら、時間のかかるデータプロバイダーへのリクエストを走らせながら、Astraがすでに入手済みのソースを整理できます。社内業務向けエージェントなら、互いに独立した2件のアカウント照会を早めに開始し、その結果に依存しないレポート部分をモデルが先に作成できます。得られるのは待機時間の短縮であり、実行コストが無料になるわけではありません。

ターン途中のステアリングで「やり直す」ループが変わる

ターン途中のステアリングを使うと、Astraの処理中でもユーザーがジョブを修正できます。アプリケーションは、同じResponses WebSocket上でresponse.steerイベントを送り、previous_response_idで実行中のレスポンスを指定して、新しい指示を渡します。サーバーは現在の出力Itemと、すでに動いているホスト型ツールの処理を終えた後、その更新内容を反映した継続レスポンスを作成します。

たとえば、代理店の担当者がレポートの対象市場の誤りに気づいた場合や、開発責任者が進行中の移行計画をより小さな範囲に絞る必要が生じた場合に役立ちます。ターン全体の終了を待たずに軌道修正できます。

ただし、すでに消費した処理は戻りません。ステアリングは、配信済みの出力を書き換えることも、以前のアクションを取り消すことも、開始済みのツールをキャンセルすることもできません。トークン上限とツール呼び出し上限は、元のレスポンスと継続レスポンスに別々に適用されます。ビジネス上の価値は、修正が遅れても全面的な再実行を減らせる点にありますが、十分な効果が得られる頻度かどうかは測定が必要です。

ステアリングはAstra専用で、Responses WebSocketが必要です。キューに入ったステアリングはその接続上にしか存在しないため、アプリケーション側で受理された更新をすべて記録し、切断後は慎重に復旧しなければなりません。OpenAIはWebSocket接続を60分に制限しています。ツール呼び出しが20回以上あるWebSocket導入では、WebSocketガイドが、エンドツーエンドの実行時間を最大約40%短縮できると報告しています。ただし、これは通信方式による結果であり、ステアリングによる削減効果を保証するものではありません。

実際に試せるResponses API移行手順

まずは、リスクの低い関数フローを1つ選びます。本番環境で最も利用の多いエージェントから始めるべきではありません。

OpenAIのクイックスタートに従い、現行のPython SDKをインストールして、環境変数を設定します。

pip install openai
export OPENAI_API_KEY="your_api_key_here"

以下は、デモ用の気象データを使ったOpenAI公式の実行可能な非同期ツール例です。APIプロジェクトでAstraへのアクセスが有効になったら実行してください。

import json
from concurrent.futures import ThreadPoolExecutor

from openai import OpenAI
from openai.types.responses import FunctionToolParam

def get_weather(city):
    # Demo data. Replace this function with your weather service.
    weather = {
        "Paris": {
            "city": "Paris",
            "temperature_c": 22,
            "condition": "Clear",
            "source": "demo weather snapshot",
        }
    }
    return weather[city]

worker = ThreadPoolExecutor()

def main():
    client = OpenAI()
    model = "gpt-6-astra"
    tools: list[FunctionToolParam] = [
        {
            "type": "function",
            "name": "get_weather",
            "description": "Read the demo weather snapshot for a city.",
            "async": True,
            "strict": True,
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
                "additionalProperties": False,
            },
        },
    ]

    instructions = (
        "Start the weather lookup and answer the independent packing "
        "question without waiting. Use the actual tool result when it "
        "arrives; never invent it. Identify the weather as demo data."
    )
    response = client.responses.create(
        model=model,
        tools=tools,
        instructions=instructions,
        input=(
            "Check the demo weather in Paris. Meanwhile, "
            "list three essentials for any city trip."
        ),
    )

    call = next(item for item in response.output if item.type == "function_call")
    arguments = json.loads(call.arguments)
    if call.name != "get_weather" or arguments != {"city": "Paris"}:
        raise ValueError("Expected a weather lookup for Paris")

    latest_response_id = response.id
    if call.async_:
        job = worker.submit(get_weather, **arguments)
        print(response.output_text)
        # Independent work or conversation turns can happen here.
        # Update latest_response_id after each continuation.
        result = job.result()
    else:
        result = get_weather(**arguments)

    response = client.responses.create(
        model=model,
        tools=tools,
        instructions=instructions,
        previous_response_id=latest_response_id,
        input=[
            {
                "type": "function_call_output",
                "call_id": call.call_id,
                "output": json.dumps(result),
            },
        ],
    )
    print(response.output_text)

if __name__ == "__main__":
    try:
        main()
    finally:
        worker.shutdown(wait=True)

見落とされやすいのがcall_id: call.call_idの行です。後続の会話ターンによって最新のレスポンスIDが変わっていても、後から届く結果は元のツール呼び出しに属します。

機能ごとに向いているチーム

すでに関数呼び出しを使っているバックエンドチーム

その経路でAstraを採用する前に、Responses移行の予算を確保します。エンドポイント、パーサー、モデルを同時に変更してデバッグするのではなく、ログと評価結果を比較できる状態で段階的に切り替えられます。

遅いサービスを待つSaaSエージェント

非同期化するのは、本当に独立して進められる処理だけです。CRM照会、社内検索、文書エクスポートなら、Astraが別の分岐を処理している間に開始できます。次の判断を阻む依存処理は同期のままにするか、明示的な待機ツールを使うべきです。

長時間の処理を監督する運用・代理店チーム

従来ならキャンセルと再実行が必要だった修正に、ステアリングを提供します。実際に防げた再実行の件数と、修正によって保持できた完了済み作業量を追跡してください。単なる機能デモではなく、導入価値を示す根拠になります。

Zero Data Retentionを利用する規制対象企業

Responses WebSocketモードはstore: falseおよびZero Data Retentionと併用できますが、状態管理は自社の責任になります。必要に応じて暗号化された推論Itemを保持し、レスポンスIDが利用できなくなった場合はコンテキスト全体を再送できるようにします。ステアリングをユーザーへ提供する前に、その復旧経路を設計してください。

現実的に見ておくべきこと

Astraへのアクセスは、まだ段階的な提供中です。移行準備は今から進められますが、本番環境を全面的に切り替えるのは、プロジェクトでアクセスが有効になり、ワークロード固有の評価が済んでからにすべきです。

非同期ツールにはジョブレジストリと順不同で届く結果への対応が加わります。ステアリングには接続状態、継続処理、復旧の実装が必要です。どちらも無駄な待機や再実行を減らせる一方、障害要因となり得るコードも増えます。

料金面の結論は、テレメトリがそろうまで出せません。同じトークン量なら、AstraはGPT-5.6 Solの現行プロモーション料金の2.5倍です。キャッシュ効率の向上、出力トークンの減少、再実行の削減によって、一部のジョブでは差を埋められる可能性があります。パイロットには厳格な利用上限を設定し、完了ジョブあたりのコストとオペレーターの作業時間でAstraを評価してください。

月曜日に着手すること

• アプリケーションがChat Completionsでツールを呼び出しており、Astraを使いたい場合は、本番フローを1つ棚卸しし、今週中にResponsesのシャドーパスへ予算を付けます。
• テキスト専用のアプリケーションは、アクセス拡大を待ちながら現状を維持します。その経路にエンドポイント移行の強制はありません。
• 遅いツールが所要時間の大半を占めるなら、関数を1つ非同期化し、待機時間、失敗、完了ジョブあたりのコストを測定します。
• 人による終盤の修正が再実行を招いているなら、WebSocketの再接続・再送テストに合格してからステアリングを試作します。
• 測定による相殺効果を考える前の段階で、Astraの2.5倍のトークン料金では採算が合わないなら、そのワークロードはGPT-5.6 Sol、Terra、またはLunaで運用を続けます。

次のプラットフォーム変更も、実行手順と予算判断まで整理して受け取りたい方は、ニュースレターにご登録ください。