Agents APIとComputer useの使い方 承認と復旧の設計
ブラウザーを操作するAIを製品に組み込むときは、クリックの正確さだけでは判断できない。どこで実行するのか、利用者にいつ判断を求めるのか、通信が切れた後に操作を重複させず復旧できるのかも重要になる。Agents APIとComputer useは、この設計を考えるための題材である。
本稿は2026年9月30日に確認した公式開発文書を基に、仕組みと導入手順を説明する。稼働中のサービスで測定した性能評価や完成済みの運用コードではない。以下の業務例は理解のために作成した提案であり、導入時には最新の仕様と利用条件を確認する必要がある。
管理型の実行基盤を理解する
Agents APIはCodexの実行基盤を管理型サービスとして提供する。単発の質問と回答だけでなく、セッションを維持しながら作業を進められる。実行の調整や文脈の整理などをOpenAIが担当し、開発者は必要なツールと環境を構成する。
構造は3つに分けて考える。Agentはモデルと指示とツールの設定、Environmentはファイルやコマンドを扱う実行空間、Sessionは継続する作業の状態である。イベントが入力や進行状況と結果をアプリにつなぐ。
例えば公開ヘルプ3件を比較する機能なら、比較基準と対象サイトを指定し、根拠のURLと結果を表示する画面を用意する。ただしAPIを利用できることは、すべてのサイトの内容を収集して再掲載してよいという許可にはならない。
個人のPC操作との違い
ここで扱うComputer useは、OpenAIがホストするブラウザーでWeb画面を操作する機能である。利用者の既存ブラウザーや個人PC全体を無制限に遠隔操作するものとして紹介してはいけない。
設定ではcomputer_useツールとopenai_hosted環境、desktopの有効化が必要になる。必要な通信先をネットワーク設定で許可し、セッションを作成した後に作業入力とイベントの確認を行う。セッションの作成だけで作業完了とは判断しない。
許可されたページの閲覧や試験用Web画面の確認など、画面操作が必要な用途を検討できる。同じ情報を安定した専用APIから取得できる場合は、より狭い権限で実現できないかも比較するとよい。
読み取り専用の例から試す
最初の導入例として、指定したヘルプページの見出しと更新日を読み、出典URLを整理する仕事を提案する。ログイン、投稿、支払い、データ変更は試験対象から外し、結果を人が確認する。
確認項目は3つに整理できる。指定したサイトを使ったか、回答とページの内容が一致しているか、承認待ちやエラーが利用者に分かる形で表示されるかである。クリックが一度成功しただけでは運用準備が整ったとはいえない。
変更機能を追加する前には、試験環境や変更権限のないアカウントで危険の範囲を狭める。変更を禁止する指示文と、変更できない実行環境は同じ強さの制御ではない。
サイト承認と個別操作の承認を分ける
新しいサイトのoriginへアクセスするときには利用者の承認が必要で、公開サイトも対象になる。ネットワークを有効にしても、この承認が済んだことにはならない。目的地と要求の理由を示し、利用者が許可や拒否を選べる画面を構成する。
特に、サイトへのアクセス承認だけでは、購入や削除などの前に確認が行われることは保証されない。サイトを開く許可を、その中で可能なすべての行動の許可として扱ってはいけない。
確認を必ず保証したい場合は、その操作を実行できない資料や環境に限定するか、開発者が制御できる実行環境と承認機構を使う。モデルに確認用ツールを呼ぶよう指示するだけでは、強制される承認手順とはいえない。
ページ内の文章は信頼できない外部入力として扱う。Webサイトの指示によって利用者の依頼が上書きされたり、新しい権限が与えられたりする設計を避ける。
認証要求を独立した画面にする
ログインが必要なら、認証先と入力項目を示す専用画面を作る。通常の作業チャットにパスワードを貼り付けさせず、どのサービスにどのアカウントで認証するのか利用者が確認できるようにする。目的地を検証できなければ中止する。
現在の仕組みではメール、パスワード、確認コードを扱えるが、パスキーやQRログインには対応しない。認証要求は主エージェントが出すもので、サブエージェントは直接要求できない。したがって、どのサービスでもログインできるとは説明しない。
認証の取り消しは、進行中の作業自体の停止とは別である。利用者がログインを拒否した場合に作業を終えるのか、公開情報だけに範囲を変えて続けるのかを明確にする。
接続復旧では既存セッションを確認する
セッションIDと処理待ちの要求IDを保存する。応答が届かなくなっただけで別のセッションを作って同じ仕事を再実行すると、すでに行われた操作が重複する可能性がある。
まず既存セッションを取得し、現在どの入力が必要かを確認する。認証の応答が受理されたか不明なら、成功とも失敗とも決めつけない。認証要求は5分で期限切れになるため、以前のログイン画面をそのまま復元してはならない。
ブラウザーの一つの操作が終わることと、主エージェントの作業が終わることも別である。最終結果と完了状態を確かめてから成功を表示する。正常時の閲覧とは別に、通信切断と受理結果が不明な場合を試験する。
記録と料金を管理する
進行画面をアプリに表示する場合は、ツールのinclude_screenshots設定を検討する。APIの出力には初期状態でスクリーンショットが含まれないが、エージェントが画面を観察できなくなるわけではない。画面には顧客情報が含まれ得るため、保存期間と閲覧者を限定する。
費用はモデルのトークン料金だけではない。モデル、対象ツール、ホストされた実行環境を分けてAPI価格表で確認する。個人のChatGPT契約が、このAPIの定額利用枠を提供すると考えてはいけない。
作業後は必要な成果を回収し、セッションを削除して環境の片付けを要求する。削除は外部サービスですでに行った変更を元に戻す機能ではないため、先に結果と状態を確認する。
運用の合格条件を定める
導入の判断は、許可範囲を守ったか、承認画面が正しく機能したか、切断後に無条件の再実行をせず復旧できたかで行う。公開資料の読み取りから始め、重要な変更は強制可能な制御を整えてから追加する。
Agents APIは継続する作業の実行基盤であり、Computer useはその中でブラウザー画面を扱うツールである。この役割を分ければ、同意、記録、結果検証、費用に関するアプリ側の責任を具体化しやすくなる。
出典と編集上の注記
本稿はOpenAIと提携していない独立した機能解説である。製品名は各権利者の商標を識別目的で使用している。図は説明用のイラストと概念図であり、実際の製品画面やOpenAIの公式画像ではない。
出典: OpenAI Developers — Agents API overview · Computer use · Environment configuration · API pricing
