GPT-6 Astraの実行中ステアリング：最初からやり直さずにタスクを変える

実行中ステアリングが変更するもの

公式ステアリングドキュメントは、Responses APIへのWebSocket接続によるGPT-6 Astraの対応を説明しています。ステアリングと過去の操作の取り消しは明確に区別されます。配信済みの出力は書き換えられず、開始したツールも自動ではキャンセルされません。

画面設計にもこの違いを反映しましょう。「要件を変える」と「操作を止める」は別の意味である必要があります。外部への書き込み中に対象が変わっても、アプリケーションは元の書き込みが行われなかったと仮定できません。

適切な状態表示は、まだ保留中の内容と完了した内容を伝えます。元の依頼を黙って置き換え、最後の操作にどの指示が適用されたかを推測させるより、「新しい要件は次の作業に適用されます」と示す方が明確です。

ステアリングのイベント順序を理解する

ストリーミングは到着した出力を順次表示します。ステアリングは後続作業を導く指示を変更します。一方に対応する製品が、もう一方も提供するとは限りません。

ドキュメントのWebSocketフローでは、response.createで開始し、response.createdを待ちます。同じ接続で、応答IDをprevious_response_id、修正した指示をinputとしてresponse.steerを送ります。response.steer.acceptedが示すのは更新がキューに入ったことであり、変更後の作業がすべて終わったことではありません。必要なツール結果や許可が不足する場合はresponse.steer.pendingがそれを示します。続行される作業は元の応答と分けて追跡してください。

完了後の通常の追加メッセージも、応答の実行中に更新する操作とは異なります。レビュー担当者が経緯を再構成できるよう、アプリケーションのログで両者を区別します。

GPT-6 Astraガイドは実行中ステアリングを新しいワークフロー機能として紹介しています。ただし、すべてのチャット画面や他社アプリが必要なイベント処理を実装しているわけではありません。表示されたモデル名だけでなく、利用するインターフェースを確認しましょう。

アプリの画面では「更新を受信」と「新しい作業が完了」を分け、実行中の操作の横に有効な要件を表示します。これは推奨する設計であり、APIが完成したタスク管理画面を提供するという意味ではありません。

有用な作業を残せる更新を書く

有用な途中変更は、何を変え、何を維持し、次に何をしてはいけないかを伝えます。

例えば「既存のデスクトップレイアウトは維持して。次はタッチ操作に集中して。現在のビルドは公開も置き換えもしないで」と依頼します。役立つ文脈を保ちながら次の行動を絞れます。

一方、「違うものにして」だけでは、新しい目的、見た目の修正、停止のどれかを推測させます。画面に現在の目的を示し、具体的な要件を編集できるようにすると助けになります。

更新が完了済みの作業と矛盾するときは、その事実を明示します。修正を望んでいても、それは固有の範囲と影響を持つ新しい操作です。

プロトタイプのキーボード操作をレビュー中に、デザイナーがモバイル要件を追加したとします。「全部やり直して」より、「ゲームプレイの目的は残し、次にタッチ入力を調べ、既存のキーボード動作は変えないで」が有用です。

以前の観察結果も活用できます。新しいテストではタッチ領域、意図しない連続入力、画面の向きの変更、同じ操作に対する反応の一貫性を確認します。これらは推奨チェックであり、Astraの実測性能を示すものではありません。

タッチ操作の依頼を具体化するには、アーケードゲームでタップ、長押し、素早い連続操作がどう表現されるかを観察しましょう。次のレビューの仕様に生かし、ゲームをどのモデルが作ったか、あるいはモデルを使ったかは推測しないでください。

要件変更を扱うタスク状態モデル

アプリケーションの記録では、予定、実行中、完了を区別できるようにします。

次の表は設計を補助するもので、APIのイベント仕様の代わりではありません。すべてのタスクを編集可能な文章のように扱う誤りを防ぎます。

ツール結果は、それを生んだ操作に関連付けます。遅れて届いた結果を、新しい要件の下で得た根拠と取り違えないでください。古くなって次の判断に使えない結果も、記録する必要がある場合があります。

要件Aで読み取りを開始し、ユーザーが要件Bを送り、その後Aの結果が届く例を考えます。結果はAに保存し、Bにも答えられるか判断します。新しい確認結果として付け替えてはいけません。例えばキーボード処理の結果は、タッチ操作の正常動作を証明しません。

実際の変更をアプリケーション側で管理する

曖昧な更新と影響の大きい操作の間で、モデルだけを唯一の防護にしないでください。アプリは書き込み案をキューで管理し、大きな影響のある段階で許可を求め、その許可が最新のタスクに対応するか確認できます。

例えば下書きのアップロードを許可した後に対象プロジェクトが変わった場合、以前の許可を新しい対象へ黙って移すべきではありません。対象と内容を再確認します。

外部メッセージ、購入、削除、デプロイにも同じ原則が当てはまります。ステアリングは修正された目的の理解を助けますが、トランザクション機構やロールバックの保証は提供しません。

読み取り専用なら遅い結果は主に無駄な作業や混乱につながりますが、書き込みなら実際の状態変更が起こり得ます。別々に設計し、テストしましょう。

扱いにくいタイミングで更新を試す

以下は連携テスト計画の提案です。本稿のために実行したものではありません。

各例で、ユーザーに示す状態、新しい操作を開始してよいか、完了をどう記録するかを定義します。モデルがメッセージを認識したかだけでなく、一貫した動作で成功を判定しましょう。

• ツールが始まる前に更新が届く。
• 読み取り専用ツールの実行中に届く。
• 書き込みの進行中に届く。
• 相反する要件の更新が二つ届く。
• 確認が表示される前に接続が切れる。
• 古いタスク版のツール結果が遅れて届く。

次の行動を見えるようにする

信頼できるステアリング体験は、現在の目的、完了した作業、許可を待つ次の行動を示します。長い会話記録からユーザーに推測させないことが大切です。

実務上の利点は不要なやり直しを減らすことであり、無制限の自律性ではありません。変更をレビュー可能にし、起きたことを正確に残しましょう。

新しい操作の依頼書を作るなら、ゲームライブラリを見て、調べる操作を一つ選びましょう。維持する内容、変える内容、許可を待つ内容を途中でも正確に説明できる範囲に絞ります。