GPT‑6 Astraコンピューター操作実践：安全なPlaywrightブラウザーエージェント設計

Astraと隔離したPlaywright実行環境を接続し、観察、状態検証、承認、復旧を備えた実運用向けのコンピューター操作ループを設計します。

AIZIGOO
GPT‑6 Astraコンピューター操作実践：安全なPlaywrightブラウザーエージェント設計

GPT‑6 Astraのコンピューター操作は、スクリーンショットから次の座標を選ぶだけではありません。OpenAIは反復、条件分岐、状態確認をまとめられるため、AstraではPlaywrightまたはPyAutoGUIによるコード実行を推奨しています。

高性能なコードを書くことと、実アカウントを安全に任せられることは別です。このガイドではブラウザー自動化を観察 → 計画 → 制限実行 → 検証 → 承認の小さなループにします。一般的なプロンプトインジェクション記事の繰り返しではなく、Astra、Responses API、Playwrightの構造に焦点を当てます。

1. 四つの接続方式から選ぶ

方式モデルの出力適した作業主な限界
Playwrightコードブラウザー自動化コードフォーム、反復巡回、UIテスト制限ランタイムが必要
PyAutoGUIコード座標ベースのデスクトップコードAPIのないデスクトップアプリ解像度と窓位置に敏感
computer tool構造化マウス・キーボード操作短い視覚操作長い処理はターンが増える
関数・MCP・API意味が定まった業務操作メール、CRM、データ変更公開していないUIに届かない

Web作業はPlaywrightを優先し、画面しかないアプリはPyAutoGUIを検討します。安定したAPIやMCPがあるなら重大な変更は明示的な機能に限定します。公開WebはPlaywright、承認済みCRM変更は専用関数という混成も有効です。

2. アーキテクチャを五層に分ける

ユーザー目標
   ↓
Astra / Responses API ── 計画・コード生成
   ↓
ポリシーゲート ── 宛先・行動・秘密・承認の検査
   ↓
隔離Playwright ── 制限された実行
   ↓
観察・検証 ── スクリーンショット + DOM + 実状態
   ↓
監査記録・人の承認・復旧

モデルとブラウザーの間のゲートが重要です。説明だけを信じずコードと宛先を検査し、必要な機能だけを公開します。個人ブラウザーではなく別プロファイルやコンテナを使い、必要なアカウントだけにログインします。

3. 実行ツールを小さく制限する

モデルにPlaywrightコードを受け取る関数を与えられますが、本番ではセッション、許可ホスト、時間、結果サイズを関数側で強制します。

type BrowserRun = { code: string; taskId: string };

async function executeBrowserCode(input: BrowserRun) {
  assertAllowedSyntax(input.code);
  const session = await getIsolatedSession(input.taskId);
  return session.run(input.code, {
    timeoutMs: 15_000,
    allowedHosts: ['docs.example.com', 'app.example.com'],
    maxPageCount: 3,
    networkWrite: false,
  });
}

これは設計例であり完成したOpenAI SDKサンドボックスではありません。生成コードより実行環境の規則を優先し、文字列検査だけでなくプロセス、ファイル、ネットワークを環境レベルで制限します。

4. 一つのプログラムに重大な全工程を任せない

操作をまとめる利点はありますが、ログインから購入まで一度に実行すると確認点が消えます。

  1. URL、主要DOM、画面を観察する。
  2. Astraが次の小目標とコードを作る。
  3. ゲートがホスト、行動、機密情報を検査する。
  4. サンドボックスで短時間実行する。
  5. DOM、データ、画面で結果を確認する。
  6. 送信、決済、削除の直前に人へ戻す。
  7. 結果を記録して次へ進む。

5. 承認画面に正確な変更を示す

「続けますか」だけでは不十分です。行動、受信者やアカウント、ファイルと最終URL、送るデータ、変更前後、費用、取消・修正・承認を表示します。ページや文書の文字は権限を与えられません。セキュリティ解除、別宛先への送信、トークン入力を要求してもユーザー指示へ昇格させません。

6. 文章ではなく状態で完了を判定する

作業弱い判定推奨検証
フォーム成功文を見た応答状態とレコードID
アップロードファイル名が見えるサーバーのハッシュ・サイズ・場所
予約完了ページへ移動日時、タイムゾーン、参加者、重複
データ編集保存をクリックAPI・DBでフィールドを再取得

task IDと冪等性キーで再試行時の二重注文や二重送信を防ぎます。失敗セッションは調査用に保持しても、危険な書き込みを自動反復しません。

7. 非同期ツールとsteeringを状態機械で管理する

Astraは遅いツールの実行中も作業し、WebSocketで新しい指示を受け取れます。遅れて終わった結果が新しい指示と衝突する可能性があります。

queued → running → awaiting_approval → completed
                  ↘ cancelled
                  ↘ blocked
                  ↘ failed

元のcall ID、指示版、開始時刻、取消可否、結果採否を保存します。steeringは開始済みツールを自動取消しないため、古い結果は監査用に表示しても後続変更には使わない規則が必要です。

8. 最小運用評価表

評価軸指標例
完了実際の最終状態の成功率
行動品質不要クリック、再試行、移動数
安全禁止行動、承認回避、外部指示追従ゼロ
復旧ツール障害後の安全停止・再開
効率呼び出し、トークン、時間、総費用
可視性現在段階と予定変更を理解できるか

モデルのベンチマークだけでは選べません。実際のログイン、ページ構造、権限、ネットワークで同じ作業を複数回試します。

配備前チェック

  • [ ] 個人ブラウザーと分離されている
  • [ ] ホスト、ツール、書き込みを許可リスト化した
  • [ ] 秘密が出力やログへ出ない
  • [ ] 短い操作ごとに実状態を確認する
  • [ ] 送信、決済、削除前に人が承認する
  • [ ] 手数、時間、費用上限と取消がある
  • [ ] 再試行で重複変更しない
  • [ ] steering後の古い結果を識別できる
  • [ ] 失敗と承認を監査できる

結論：広く観察し、狭く行動する

コード実行型コンピューター操作は反復Web作業とUIテストを大きな単位で自動化できます。しかし能力が高いほど権限を広げるのではなく、観察は広くても実行は小さなサンドボックスと明示承認の中に留めるべきです。

まず決済や削除のない読み取り専用作業から始め、Playwrightで結果を検証し、失敗を評価セットへ加えながら検証可能な書き込みを一つずつ増やしてください。

公式資料