GPT-6 Astra、待ち時間に作業を進め途中で指示も足せる

AIに社内資料を集めさせて報告書を作らせる、という機能を考えてみる。資料の取得には時間がかかるし、作業が始まったあとで「比較する期間は直近3年に絞ってほしい」と条件を足したくなることもある。

OpenAIが2026年9月3日のAPI更新で示したGPT-6 Astraには、この2つに関わる機能がある。資料が届く前でも決められることは先に進め、作業の途中で足した条件を後続の作業へ渡せる。報告書づくりの例を通して、何ができるのか、アプリ側で何を用意するのかを見ていく。Astraのモデルガイド

資料を待つ間に報告書の章立てを決める

先に役割を分けておく。GPT-6 Astraは、調査、コード修正、ブラウザー操作など複数の工程をまたぐ仕事に対応するモデルだ。作業の進め方はモデルが判断するが、資料を実際に取ってくるのはツールと呼ばれる外部の機能で、独自のツールを実行して結果をモデルへ返す部分はアプリ側が担う。非同期ツールの基本仕様

報告書づくりを、この役割分担で追ってみる。モデルは、依頼を読んでどの資料が要るかを判断し、資料を取ってくるツールを呼び出す。呼び出しを受けたアプリが社内システムへ問い合わせ、返ってきた内容をモデルへ渡す。モデルはその内容を読んで報告書を組み立てる。時間がかかるのは、たいてい2番目のアプリ側の処理だ。

通常のツール呼び出しでは、モデルはこの結果が返るのを待ってから次へ進む。取得に3分かかるなら、その3分は何も進まない。非同期ツールでは、取得処理を始めたあとも、その結果に依存しない仕事を進められる。アプリが定義する関数や独自ツールに async: true を付けて使う。

では、資料を待つ間に何ができるのか。報告書の例なら、読者と報告の目的が決まっていれば、資料が届く前でも決められることがある。

同じ時間帯に2本の作業が並ぶところが、非同期ツールで変わる部分になる。仕様はAsync tool callingの説明によるもので、帯の長さは所要時間を測った値ではない。

左下の帯に入るのは、依頼の時点ですでに条件が揃っている作業だ。誰に向けた報告で、何と何を比べるのかが決まっていれば、章立ては資料の中身を見なくても組める。右下の表と結論は、資料の数字が入って初めて決まる。これは仕組みを説明する仮の例だ。

待ち時間に進められる作業の量は、頼んだ仕事の中に資料から独立した部分がどれだけあるかで決まる。すべての工程が同じ資料に依存する仕事では、先に進められる部分は少なくなる。

頼み方によって、この余地は広げられる。報告書の例で、依頼の一文が「この資料をまとめて」だけなら、誰に向けた何の報告かは資料を読むまで決まらない。最初に読者と目的、比較したい項目まで伝えておけば、資料が届く前に決められる作業がそのぶん増える。

評価するときは、まだ手元にない数字を埋めずに準備を進めたかを見るとよい。

途中で足した条件は後続の作業に渡る

同じ報告書づくりの途中で、比較する期間を直近3年に絞ってほしい、と条件を足す場面を考える。mid-turn steeringは、応答が完了する前に追加の指示を渡す機能だ。Astraでは、接続を保ったまま双方向に通信するWebSocket経由で使う。途中指示の公式仕様

指示を送ったあとの流れは、次のようになる。まず、送られた指示は待ち行列へ入る。アプリには response.steer.accepted という受理の通知が返る。そのうえで、後続の作業に条件が反映される。報告書ができあがってからまとめて直すのに比べて、手戻りを減らせる。

response.steer.accepted は、指示を待ち行列へ入れたことを知らせる通知だ。アプリの画面では「条件を受け付けました」と見せ、反映した結果は後続の応答で示すと、利用者に進み具合が伝わる。

条件が届くのは、まだ実行していない作業だ。条件を足す前に5年分の資料の取得が始まっていれば、その取得はそのまま進む。だから条件は早く送るほど、後続の多くの作業に反映される。

両機能ともアプリ側の実装が要る

どちらの機能も、モデル名を変えるだけでは使えない。ツールを実行するのがアプリである以上、非同期にする判断も、途中指示を受け取る通信も、アプリ側の実装が要る。ツールを使うアプリはResponses APIの仕様を確認する。APIで指定するモデルIDは gpt-6-astra だ。公式モデル仕様、APIの変更履歴

根拠は非同期ツールと途中指示の個別仕様。call_id で対応付けるのは、結果を待たずに次へ進む以上、複数の取得処理が同時に走りうるからだ。3件の資料取得を並行して始めれば、返ってくる順番は依頼した順とは限らない。どの結果がどの呼び出しへの返答かを、アプリが示す必要がある。非同期に指定するのは、アプリが定義する関数や独自ツールで、OpenAIが提供する組み込みツールとは扱いが分かれている。

待ち時間に別の作業を進めることも、途中で条件を足すことも、意味を持つのは工程が複数に分かれ、しかも時間のかかる仕事だ。一往復で答えが返る質問なら、待ち時間に進める作業も、途中で条件を足す場面もほとんどない。逆に、資料の取得や外部システムの操作をはさむ仕事では、待っている時間と、作業中に気が変わる場面の両方が生じる。Astraが複数の工程をまたぐ仕事を想定したモデルとして説明されているのは、この2つの機能の前提でもある。

導入前に試すなら、報告書のように、時間のかかる取得処理と結果に依存しない準備の両方を含む課題がよい。資料を待つ間に準備が進むかを見て、作業中に条件を追加し、後続の成果物にその条件が入るかを確かめる。

まとめ

• 非同期ツールでは、取得結果に依存しない作業を待ち時間に進められる。依頼の時点で読者や目的、比較項目を伝えるほど、先に進められる作業が増える。
• 途中指示では、作業中に足した条件を後続の作業へ渡せる。早く送るほど多くの作業に反映され、完成後にまとめて直す手戻りを減らせる。
• ツールを実行するのはアプリなので、非同期としての定義、call_id での結果の対応付け、WebSocketでの受信はアプリ側で用意する。