# GPT-6 Astraでコンピュータ操作を実装する：APIの制御ループと安全設計

> アクセス権を分けて確認し、実行方式を選び、最後は対象システムで結果を確かめる。AstraのPC操作を安全に組み込むための実装判断を整理します。

- URL: https://blog.laozhang.ai/ja/posts/gpt-6-astra-computer-use-api
- Published: 2026-09-04
- Updated: 2026-09-04
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ja/about)
- Topic: ChatGPT と OpenAI
- Tags: GPT-6 Astra, OpenAI API, Computer Use, Responses API, ブラウザ自動化

---
GPT-6 AstraによるPC操作は、モデルと開発者側のアプリケーションが処理を分担します。モデルが返した操作やスクリプトをアプリケーションが隔離環境で実行し、その結果をResponses APIへ返す仕組みです。この往復を安全に続け、最後に対象システムを調べて初めて「作業が終わった」と判断できます。

2026年9月4日時点の `gpt-6-astra` は段階提供中です。[OpenAIのリリース情報](https://learn.chatgpt.com/docs/whats-new#take-on-demanding-work-with-gpt-6-astra)では、まずTrusted Access Programの企業に提供し、APIとChatGPT Plus、Pro、Business、Enterpriseへのアクセスを今後数日に広げるとしています。これは、各プランの全利用者がすでに使えるという意味ではありません。以下の実装を始める前に、実際に使う場所の権限を確認してください。

## ChatGPTとAPIのアクセス権は別に確認する

ChatGPTのモデル選択欄にAstraがあっても、その表示だけでAPIキーに権限が付くわけではありません。APIの認可は、そのキーが属する組織とプロジェクトに従います。逆に、APIから利用できてもChatGPTワークスペースで有効とは限りません。

初期のEnterprise提供では、組織にDaybreakアクセスが必要で、管理者がAstraを有効にします。また、最初の2週間は既定で無効です。これらはEnterprise固有の初期条件であり、他のプランへ一般化できません。現在の扱いは[Enterprise向けモデル提供条件](https://learn.chatgpt.com/docs/enterprise/workspace-model-availability#gpt-6-astra-in-enterprise)で確認できます。

ChatGPTのデスクトップ版で使うComputer Useも、APIのcomputer useとは別の製品経路です。対応地域のmacOSおよびWindows上のChatGPT WorkとCodexで提供され、アカウントのモデル選択欄にAstraがある場合に、難しい画面判断を伴う作業でAstraが推奨されています。ここでもOS権限、アプリへのアクセス、ワークスペース設定は残ります。最新条件は[ChatGPTのComputer Useガイド](https://learn.chatgpt.com/docs/computer-use#when-to-use-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更新ガイド](https://developers.openai.com/api/docs/guides/latest-model#gpt-6-astra-update-api-and-model-parameters)がこの境界を明記しています。

推論の強度は `low`、`medium`、`high`、`xhigh`、`max` に対応します。Responsesでは `reasoning.effort` を使います。`none` と `minimal` はAstraでは使えず、`none` はHTTP 400になります。移行時はまず `low` から始めるのが公式案内です。独自の `temperature`、`top_p`、`top_logprobs` や `logprobs` 出力もサポート対象ではありません。旧モデルの設定をそのままコピーせず、[モデルページ](https://developers.openai.com/api/docs/models/gpt-6-astra)と更新ガイドに合わせてリクエストを組み直します。

## まず三つの状態を分ける

コンピュータ操作の不具合は、状態を一つだと思うと切り分けにくくなります。アプリケーションは少なくとも次の三つを別々に持ちます。

1. **モデルとの会話状態**：Responsesの応答と `previous_response_id` で続く文脈。
2. **実行環境の状態**：ブラウザのタブ、ログイン、現在の画面、デスクトップ、ファイル、実行中の変数。
3. **現実の作業結果**：フォームの登録、予定の作成、ファイルの保存、権限の変更など、対象サービス側に残る状態。

`previous_response_id` はモデルの文脈を継続しますが、消えたブラウザセッション、ログイン状態、デスクトップ画面、ランタイムの変数を復元しません。モデル文脈に以前の画面情報が残っていても、実行環境を作り直せば、その情報は現状と一致しなくなります。したがって、アプリケーションはモデル側の応答IDと、同じブラウザまたはデスクトップセッションを対応づけて保持する必要があります。

さらに、APIの応答や `computer_call.status: "completed"` も、モデルがその呼び出しの生成を終えたことしか示しません。アクションが実行されたこと、まして業務上の結果が成立したことまでは証明しません。[OpenAIのcomputer useガイド](https://developers.openai.com/api/docs/guides/tools-computer-use#use-code-execution)も、会話状態と実行環境の状態を別に維持する前提で制御ループを説明しています。

![モデルとの会話、実行環境、現実の作業結果を三つに分け、確認を挟む制御ループを示す図](https://blog.laozhang.ai/posts/ja/gpt-6-astra-computer-use-api/img/three-states-control-loop.webp)

## 新しいAstra統合ではコード実行が推奨される

OpenAIは、新しくGPT-6 Astraでコンピュータ操作を組み込む場合、コード実行（code execution）を推奨しています。ここでいうコード実行は、OpenAIが開発者のPC上で任意のコードを直接動かす機能ではありません。開発者が通常の関数ツール（function tool）を用意し、PyAutoGUIやPlaywrightのスクリプトを受け取れる、隔離された永続実行環境を自分で運用します。

制御ループは次の対応関係で考えると崩れにくくなります。

1. アプリケーションが、利用できる操作を限定したカスタム関数とタスクをResponses APIへ渡す。
2. Astraが `function_call` としてスクリプトを返す。
3. アプリケーションが権限、対象、実行時間を検査し、許可されたコードだけを隔離環境で実行する。
4. 実行結果を、同じ `call_id` を持つ `function_call_output` として返す。必要な観察はテキストまたはスクリーンショットにする。
5. `previous_response_id` でモデル文脈を続け、実行可能な呼び出しがなくなるか、失敗・上限到達・取消のいずれかまで繰り返す。
6. ループ終了後、モデルの最終文ではなく対象システムを読み直し、成功条件を満たしたか確認する。

一つのスクリプトには複数アクション、条件分岐、ループを含められます。往復回数を減らせる一方、スクリプト内で多くの操作が一度に進む可能性があります。だからこそ、権限検査をプロンプトだけに任せず、公開するヘルパーと実行環境の両方で制限します。[コード実行の統合手順](https://developers.openai.com/api/docs/guides/tools-computer-use#use-code-execution)に登場する `execute_in_sandbox` は、OpenAIが提供するエンドポイントではなく、アプリケーション側が用意するサービスの例です。

この実行サービスは、APIクライアントや認証情報から分離した、破棄可能かつ最小権限のコンテナまたはVMで動かします。呼び出し元を認証し、ネットワークとリソースを絞り、ランタイム内部に期限を設けます。クライアント側のタイムアウトは「待つのをやめる」だけで、暴走した処理を停止するとは限りません。また、Node.jsの `vm` やPythonのrestricted globalsは、それ自体ではセキュリティ境界になりません。[実行サービスの安全要件](https://developers.openai.com/api/docs/guides/tools-computer-use-integration#connect-to-your-execution-service)をホスティング設計にも反映させます。

## `computer`ツールを選ぶ場合は画面を正しく返す

ネイティブの `computer` ツールもAstraでサポートされています。コード実行の古い名前ではなく、モデルが座標ベースのアクションを返し、アプリケーションが順に実行する別方式です。Responsesの `tools` 配列には `[{ type: "computer" }]` を指定します。

応答の `computer_call` には、順序を持つ `actions[]` がまとまって入ります。アプリケーションは許可されたアクションだけを実行し、更新後の画面を取得して、元の `call_id` と対応する `computer_call_output`、`computer_screenshot` を返します。続行時は `previous_response_id` も維持します。応答が不完全・失敗である、アクション生成が途中である、アプリケーション側のステップ数や時間上限に達した、といった場合はループを止めます。[ネイティブループの仕様](https://developers.openai.com/api/docs/guides/tools-computer-use-integration#repeat-the-computer-use-loop)は骨格を示していますが、権限確認と取消処理はアプリケーション側で追加する必要があります。

座標を正確に合わせるため、スクリーンショットは通常 `detail: "original"` で返します。画像を縮小する場合、モデルが返す座標を実行環境の元の座標系へ変換しなければなりません。大きな画像は入力トークンを増やし、30,000パッチを超えたスクリーンショットは拒否されます。`original` を選んでもモデル側の上限で調整される場合があるため、万能な固定解像度を決めるのではなく、実際の画面と座標変換を一組で検証します。詳細は[スクリーンショット取得の注意点](https://developers.openai.com/api/docs/guides/tools-computer-use-integration#capture-screenshots)にあります。

二つの方式の違いを、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の指針](https://developers.openai.com/api/docs/guides/tools-computer-use#run-safely)と[確認・同意の実装指針](https://developers.openai.com/api/docs/guides/tools-computer-use-integration#handle-user-confirmation-and-consent)は、これらをモデルへの指示だけでなくアプリケーションと実行環境の制御として求めています。

![権限、実行方式、監督と確認、実行結果の検証を順に確かめるAstra導入チェックリスト](https://blog.laozhang.ai/posts/ja/gpt-6-astra-computer-use-api/img/implementation-safety-checklist.webp)

Astraの非同期misalignment monitoringが会話を停止または警告する場合もありますが、安全機構の代わりにはなりません。問題を見逃すことも、正当な作業を検出することもあり、検出前に済んだ操作を元に戻す機能でもありません。`misalignment_policy_violation` は自動再試行せず、処理を止めて人が状況を確認します。適用範囲と制約は[misalignment monitoringの仕様](https://developers.openai.com/api/docs/guides/safety-checks/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統合ガイド](https://developers.openai.com/api/docs/guides/tools-computer-use-integration)にある移行表は、Astraへの直接移行を示していません。

新しくAstraを組み込む場合は、その移行表を流用せず、新規統合で推奨されているコード実行を第一候補にします。既存previewを保守する場合は、短い予告期間でも移行できるように準備します。OpenAIはpreviewモデルの告知期間が、例として2週間ほどまで短くなり得るとしており、これは `computer-use-preview` の具体的な終了日を公表したという意味ではありません。[モデル廃止の告知方針](https://developers.openai.com/api/docs/deprecations#model-deprecation-notice-periods)でpreviewの扱いを確認できます。

GPT-6 Astraのコンピュータ操作で最初に決めるべきなのは、華やかなデモの再現方法ではありません。利用権限をどこで確認するか、誰の環境で何を実行するか、どの操作を人が承認するか、そして何をもって現実の完了とするかです。この四点をアプリケーション側で明文化できれば、モデルの応答と実際の業務状態を混同せずに導入判断を進められます。

## 参考資料

本文で参照している外部ページを、登場順に並べています。最終更新日：2026-09-04。

- [OpenAIのリリース情報](https://learn.chatgpt.com/docs/whats-new) (learn.chatgpt.com)
- [Enterprise向けモデル提供条件](https://learn.chatgpt.com/docs/enterprise/workspace-model-availability) (learn.chatgpt.com)
- [ChatGPTのComputer Useガイド](https://learn.chatgpt.com/docs/computer-use) (learn.chatgpt.com)
- [AstraのAPI更新ガイド](https://developers.openai.com/api/docs/guides/latest-model) (developers.openai.com)
- [モデルページ](https://developers.openai.com/api/docs/models/gpt-6-astra) (developers.openai.com)
- [OpenAIのcomputer useガイド](https://developers.openai.com/api/docs/guides/tools-computer-use) (developers.openai.com)
- [実行サービスの安全要件](https://developers.openai.com/api/docs/guides/tools-computer-use-integration) (developers.openai.com)
- [misalignment monitoringの仕様](https://developers.openai.com/api/docs/guides/safety-checks/misalignment-monitoring) (developers.openai.com)
- [モデル廃止の告知方針](https://developers.openai.com/api/docs/deprecations) (developers.openai.com)