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の説明によるもので、帯の長さは所要時間を測った値ではない。

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

逆に言えば、この分け方が成り立たない仕事もある。依頼の目的が資料を読まないと決まらない調査や、すべての工程が同じ資料に依存する仕事では、待ち時間にできることは限られる。非同期にできるかどうかは、モデルの性能ではなく、頼んだ仕事の中に独立した部分があるかで決まる。

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

そして、評価するときに見るべきなのは、AIが何かを書き続けていることではない。まだ手元にない数字を埋めずに準備を進めたかどうかだ。存在しない実績を先に書いて報告書が完成しても、仕事が早く済んだことにはならない。

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

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

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

ここで区別したいのは、受理と反映だ。response.steer.accepted は、指示を待ち行列へ入れたという通知であり、条件どおりの成果物ができたという通知ではない。利用者の画面に「指示を反映しました」と出してしまうと、まだ何も直っていない段階で完了したように見える。

さらに、この機能には、実行済みの操作を巻き戻したり、開始済みのツールを取り消したりする働きはない。条件を足す前に5年分の資料の取得がすでに始まっていれば、その取得は止まらない。取得された5年分をどう扱ったのかは、できあがった報告書を見て確かめることになる。

条件を足す早さによって結果が変わるのは、この点に理由がある。作業の序盤で送った条件は後続のほとんどに効くが、終盤で送った条件が届く範囲は、まだ実行していない作業だけだ。アプリの画面でも、追加条件を受け付けた段階と、それを反映した結果は分けて見せたい。

アプリ側で用意するもの

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

使う機能	アプリ側の主な仕事
非同期ツール	ツールを非同期として定義し、処理を実行する。結果は元の call_id に対応付けて返す
途中指示	WebSocketで追加指示を送り、受理通知と後続の応答を処理する

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

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

導入前に試すなら、報告書のように、時間のかかる取得処理と結果に依存しない準備の両方を含む課題がよい。準備を進めたか、未取得の事実を書かなかったかを見る。そのうえで作業中に条件を追加し、受理の通知だけで終わらせず、後続の成果物と、すでに実行した操作の扱いまで確認する。

各アカウントでの利用可否、ChatGPTやCodexのプラン別の提供状況、実際の時間や費用は今回確認していない。手元のアプリで使えるかどうかは、そのアプリの対応とアクセス条件を確かめることになる。

まとめ

• 非同期ツールでは、取得結果に依存しない作業を待ち時間に進められる。進められる作業があるかどうかは、頼んだ仕事に独立した部分があるかで決まる。
• 途中指示は後続の作業へ条件を渡す機能。response.steer.accepted は受理の通知で、実行済みの操作や開始済みのツールは取り消されない。
• ツールを実行するのはアプリなので、非同期としての定義、call_id での結果の対応付け、WebSocketでの受信はアプリ側で用意する。