GPT-6 AstraにPC操作を任せるとは、モデルが開発者の端末を直接乗っ取ることではありません。モデルは操作またはスクリプトを返し、開発者側のアプリケーションが隔離された環境で実行し、観察結果をResponses APIへ返します。この往復を安全に続け、最後に対象システムを調べて初めて「作業が終わった」と判断できます。
2026年9月4日時点の gpt-6-astra は段階提供中です。OpenAIのリリース情報では、まずTrusted Access Programの企業に提供し、APIとChatGPT Plus、Pro、Business、Enterpriseへのアクセスを今後数日に広げるとしています。これは、各プランの全利用者がすでに使えるという意味ではありません。以下の実装を始める前に、実際に使う場所の権限を確認してください。
ChatGPTとAPIのアクセス権は別に確認する
ChatGPTのモデル選択欄にAstraがあっても、その表示だけでAPIキーに権限が付くわけではありません。APIの認可は、そのキーが属する組織とプロジェクトに従います。逆に、APIから利用できてもChatGPTワークスペースで有効とは限りません。
初期のEnterprise提供では、組織にDaybreakアクセスが必要で、管理者がAstraを有効にします。また、最初の2週間は既定で無効です。これらはEnterprise固有の初期条件であり、他のプランへ一般化できません。現在の扱いはEnterprise向けモデル提供条件で確認できます。
ChatGPTのデスクトップ版で使うComputer Useも、APIのcomputer useとは別の製品経路です。対応地域のmacOSおよびWindows上のChatGPT WorkとCodexで提供され、アカウントのモデル選択欄にAstraがある場合に、難しい画面判断を伴う作業でAstraが推奨されています。ここでもOS権限、アプリへのアクセス、ワークスペース設定は残ります。最新条件はChatGPTのComputer Useガイドを基準にしてください。
APIで確認すべき対象は、契約プラン名ではなく、実際にリクエストを送る組織・プロジェクトとAPIキーです。まだ権限がなければ、ローカルのモデル名を書き換えても解決しません。段階提供を待つか、アカウント担当者から指定された初期設定がある場合はその手順を完了します。
ツールを使うならResponses APIが必要
GPT-6 AstraはResponses、Chat Completions、Batchの各エンドポイントに対応しています。ただし、コンピュータ操作を含むツール呼び出しはResponses APIでのみ利用できます。Chat Completionsでモデルから文章が返ることと、そこでfunctionやcomputerを呼べることは別です。既存のChat Completionsベースのツール統合は、Astraのツールを使う前にResponsesへ移す必要があります。AstraのAPI更新ガイドがこの境界を明記しています。
推論の強度は low、medium、high、xhigh、max に対応します。Responsesでは reasoning.effort を使います。none と minimal はAstraでは使えず、none はHTTP 400になります。移行時はまず low から始めるのが公式案内です。独自の temperature、top_p、top_logprobs や logprobs 出力もサポート対象ではありません。旧モデルの設定をそのままコピーせず、モデルページと更新ガイドに合わせてリクエストを組み直します。
まず三つの状態を分ける
コンピュータ操作の不具合は、状態を一つだと思うと切り分けにくくなります。アプリケーションは少なくとも次の三つを別々に持ちます。
- モデルとの会話状態：Responsesの応答と
previous_response_idで続く文脈。 - 実行環境の状態：ブラウザのタブ、ログイン、現在の画面、デスクトップ、ファイル、実行中の変数。
- 現実の作業結果：フォームの登録、予定の作成、ファイルの保存、権限の変更など、対象サービス側に残る状態。
previous_response_id はモデルの文脈を継続しますが、消えたブラウザセッション、ログイン状態、デスクトップ画面、ランタイムの変数を復元しません。モデル文脈に以前の画面情報が残っていても、実行環境を作り直せば、その情報は現状と一致しなくなります。したがって、アプリケーションはモデル側の応答IDと、同じブラウザまたはデスクトップセッションを対応づけて保持する必要があります。
さらに、APIの応答や computer_call.status: "completed" も、モデルがその呼び出しの生成を終えたことしか示しません。アクションが実行されたこと、まして業務上の結果が成立したことまでは証明しません。OpenAIのcomputer useガイドも、会話状態と実行環境の状態を別に維持する前提で制御ループを説明しています。
新しいAstra統合ではコード実行が推奨される
OpenAIは、新しくGPT-6 Astraでコンピュータ操作を組み込む場合、コード実行（code execution）を推奨しています。ここでいうコード実行は、OpenAIが開発者のPC上で任意のコードを直接動かす機能ではありません。開発者が通常の関数ツール（function tool）を用意し、PyAutoGUIやPlaywrightのスクリプトを受け取れる、隔離された永続実行環境を自分で運用します。
制御ループは次の対応関係で考えると崩れにくくなります。
- アプリケーションが、利用できる操作を限定したカスタム関数とタスクをResponses APIへ渡す。
- Astraが
function_callとしてスクリプトを返す。 - アプリケーションが権限、対象、実行時間を検査し、許可されたコードだけを隔離環境で実行する。
- 実行結果を、同じ
call_idを持つfunction_call_outputとして返す。必要な観察はテキストまたはスクリーンショットにする。 previous_response_idでモデル文脈を続け、実行可能な呼び出しがなくなるか、失敗・上限到達・取消のいずれかまで繰り返す。- ループ終了後、モデルの最終文ではなく対象システムを読み直し、成功条件を満たしたか確認する。
一つのスクリプトには複数アクション、条件分岐、ループを含められます。往復回数を減らせる一方、スクリプト内で多くの操作が一度に進む可能性があります。だからこそ、権限検査をプロンプトだけに任せず、公開するヘルパーと実行環境の両方で制限します。コード実行の統合手順に登場する execute_in_sandbox は、OpenAIが提供するエンドポイントではなく、アプリケーション側が用意するサービスの例です。
この実行サービスは、APIクライアントや認証情報から分離した、破棄可能かつ最小権限のコンテナまたはVMで動かします。呼び出し元を認証し、ネットワークとリソースを絞り、ランタイム内部に期限を設けます。クライアント側のタイムアウトは「待つのをやめる」だけで、暴走した処理を停止するとは限りません。また、Node.jsの vm やPythonのrestricted globalsは、それ自体ではセキュリティ境界になりません。実行サービスの安全要件をホスティング設計にも反映させます。
computerツールを選ぶ場合は画面を正しく返す
ネイティブの computer ツールもAstraでサポートされています。コード実行の古い名前ではなく、モデルが座標ベースのアクションを返し、アプリケーションが順に実行する別方式です。Responsesの tools 配列には [{ type: "computer" }] を指定します。
応答の computer_call には、順序を持つ actions[] がまとまって入ります。アプリケーションは許可されたアクションだけを実行し、更新後の画面を取得して、元の call_id と対応する computer_call_output、computer_screenshot を返します。続行時は previous_response_id も維持します。応答が不完全・失敗である、アクション生成が途中である、アプリケーション側のステップ数や時間上限に達した、といった場合はループを止めます。ネイティブループの仕様は骨格を示していますが、権限確認と取消処理はアプリケーション側で追加する必要があります。
座標を正確に合わせるため、スクリーンショットは通常 detail: "original" で返します。画像を縮小する場合、モデルが返す座標を実行環境の元の座標系へ変換しなければなりません。大きな画像は入力トークンを増やし、30,000パッチを超えたスクリーンショットは拒否されます。original を選んでもモデル側の上限で調整される場合があるため、万能な固定解像度を決めるのではなく、実際の画面と座標変換を一組で検証します。詳細はスクリーンショット取得の注意点にあります。
二つの方式の違いを、APIの返却単位で整理すると次のようになります。
| 判断点 | コード実行 | computerツール |
|---|---|---|
| モデルが返すもの | function_call 内のスクリプト | computer_call.actions[] |
| 開発者が実行する単位 | 複数操作や条件分岐を含められるコード | 順序づけられたアクション群 |
| 観察の返し方 | 同じ call_id の function_call_output | 同じ call_id の computer_call_output と computer_screenshot |
| 保持すべきもの | モデル文脈と永続実行環境 | モデル文脈と同じ画面セッション |
| 権限確認を強制する場所 | カスタム関数、ヘルパー、実行環境の内部 | バッチ内の危険な操作を実行する直前 |
画面中心の既存アダプターを保つ理由があるなら computer は有効です。新規のAstra統合で、UI操作をコードとしてまとめ、条件分岐や観察を開発者側で管理したいなら、推奨されるコード実行から検討します。「サポートされる」と「推奨される」を同じ意味にしないことが重要です。
確認はモデルの文章ではなく実行直前に置く
モデルが「実行してよい」と書いても、それは利用者の許可ではありません。画面、メール、PDF、チャット、ツール結果に書かれた指示も第三者コンテンツであり、権限付与として扱えません。許可判定は、アプリケーションが実際の操作を実行する前に行います。
特に、購入、データ送信、削除、権限変更では、その時点で利用者に対象と影響を示して確認を求めます。入力欄へ機密情報を打ち込むこともデータ送信です。computer_call.actions[] のバッチに危険な操作が含まれるなら、その最初の操作の前で止めます。コード実行では一つのスクリプトが多数の処理を行えるため、カスタム関数を呼ぶ前の確認だけでなく、ファイル操作、ネットワーク送信、クリックなどを担うヘルパー内部でも権限を強制します。
パスワード変更の確定や、ブラウザ・サイトの安全警告を回避する操作は人に引き継ぎます。許可対象はドメイン名だけでなく、実行してよい操作まで絞ります。ページ内の命令は信頼せず、APIクライアントの資格情報を実行環境へ渡さず、ステップ数・時間・費用を制限し、利用者が途中で取り消せる経路を用意します。OpenAIの安全なcomputer useの指針と確認・同意の実装指針は、これらをモデルへの指示だけでなくアプリケーションと実行環境の制御として求めています。
Astraの非同期misalignment monitoringが会話を停止または警告する場合もありますが、安全機構の代わりにはなりません。問題を見逃すことも、正当な作業を検出することもあり、検出前に済んだ操作を元に戻す機能でもありません。misalignment_policy_violation は自動再試行せず、処理を止めて人が状況を確認します。適用範囲と制約はmisalignment monitoringの仕様に従います。
成功条件は対象システムから読み戻す
モデルの最終メッセージは作業報告であって、完了証明ではありません。スクリーンショットも「その瞬間に何が見えたか」を示すだけで、サーバー側の保存や後続処理までは保証しません。実行前に、対象システムで観察できる成功条件と失敗条件を決めておきます。
たとえばフォーム送信なら、送信ボタンを押したことではなく、対象サービスが返す受付番号や保存済みレコードを確認します。カレンダー作成なら、予定一覧を読み直して日時・参加者・タイムゾーンが一致するかを見る。ファイル保存なら、目的の場所に存在し、開けて、内容と形式が意図どおりか確かめます。確認手段がない場合は「完了」ではなく「未検証」として止めるほうが安全です。
終了判定には少なくとも、API応答が完全であること、未処理の function_call または computer_call が残っていないこと、アプリケーションの上限や取消に触れていないこと、対象システムの成功条件が成立したことを含めます。どれか一つでも満たさなければ、同じ操作を無条件に再実行せず、現在の環境と外部状態を読み直します。二重送信や重複作成を防ぐには、「モデルが何と言ったか」より「何がすでに存在するか」を基準にします。
旧previewの公式移行先はAstraではない
既存のpreview統合には、Astraとは別の公式移行手順があります。現在の対応は、モデルを computer-use-preview から gpt-5.6-sol へ、ツール種別を computer_use_preview から computer へ変え、単一の action をバッチ化された actions[] として扱い、以前必須だった truncation: "auto" を外すものです。公式のcomputer use統合ガイドにある移行表は、Astraへの直接移行を示していません。
新しくAstraを組み込む場合は、その移行表を流用せず、現在の別方針であるコード実行を第一候補にします。既存previewを保守する場合は、短い予告期間でも移行できるように準備します。OpenAIはpreviewモデルの告知期間が、例として2週間ほどまで短くなり得るとしており、これは computer-use-preview の具体的な終了日を公表したという意味ではありません。モデル廃止の告知方針でpreviewの扱いを確認できます。
GPT-6 Astraのコンピュータ操作で最初に決めるべきなのは、華やかなデモの再現方法ではありません。利用権限をどこで確認するか、誰の環境で何を実行するか、どの操作を人が承認するか、そして何をもって現実の完了とするかです。この四点をアプリケーション側で明文化できれば、モデルの応答と実際の業務状態を混同せずに導入判断を進められます。
