OpenAIのエージェントがブラウザ操作へ。承認はサイト単位、実行環境は20分課金

AI エージェントの見積もりでいちばん揉めるのは、トークン以外の費用である。2026 年 9 月 29 日の DevDay で、OpenAI が Agents API に「コンピュータ操作（computer use）」を追加した。エージェントが OpenAI 側がホストするブラウザの中で作業を進め、サイトへのアクセス承認とログインは呼び出し側のアプリが受け持つ、という形になっている。

技術の話に聞こえるが、発注側に効くのは 2 点である。承認の粒度がサイト単位になったことと、実行環境が時間とメモリで課金される領域が増えたこと。どちらも見積書の行と検収条件に直接関わる。

公表されている事実

OpenAI の API 変更履歴と料金表に記載されている内容は次のとおりである。

• 2026 年 9 月 29 日、Agents API にコンピュータ操作が追加された。エージェントは OpenAI がホストするブラウザの中でタスクを実行する。サイトへのアクセス承認とサインインは呼び出し側のアプリケーションが管理する
• Agents API 自体は 2026 年 9 月 10 日にパブリックベータとして公開されており、利用にはベータ指定のヘッダ（OpenAI-Beta: agents=v1）が必要とされている
• 承認はオリジン（サイト）単位である。1 度許可したサイトの中では、個々の操作ごとの確認は入らない仕組みになっている
• サインインの画面はアプリ側で作る。メールアドレス・パスワード・確認コードには対応し、パスキーと QR コードによるサインインには対応しないとされている。認証を要求できるのは主たるエージェントのみで、サブエージェントからは要求できない
• ホスト型サンドボックス（コンテナ）の料金は 20 分のセッション単位で、1 GB が 0.03 ドル、4 GB が 0.12 ドル、16 GB が 0.48 ドル、64 GB が 1.92 ドル。Code Interpreter もこのコンテナ料金に含まれる
• ウェブ検索ツールは 1,000 回あたり 10.00 ドル＋検索内容のトークン分がモデル単価で課金される
• GPT-6.1 Sol（2026 年 9 月 29 日公開）の標準ティア単価は、短いコンテキストで入力 100 万トークン 2.00 ドル・出力 10.00 ドル、キャッシュ読み取り 0.10 ドル。長いコンテキストでは入力 4.00 ドル・出力 15.00 ドル

公表されていないものも押さえておく。ホスト型ブラウザのセッション料金・提供リージョン・レート制限・セッションの最長時間は、いずれも公表されていない。また、購入・削除のような取り返しのつかない操作の前に確認を挟むかどうかは API 側では強制されず、アプリ側の責任とされている。

ここまでが事実である。以下は見立てになる。

論点 1. 「トークンだけ」の見積もりが成り立たなくなる領域が広がった

エージェント案件の運用費は、長いあいだトークン単価の掛け算で済んでいた。ここに時間課金とメモリ選択が入る。

20 分 0.03 ドル（1 GB）は小さく見えるが、課金の単位が時間であるぶん、効く条件が変わる。

課金の形	月額が増える要因	設計で効く対策
トークン（入力・出力）	処理件数、1 件の文字数	プロンプト短縮、キャッシュ
コンテナ（20 分・メモリ別）	同時に動くセッション数、1 件の所要時間	待ち時間の排除、セッションの使い回し
ツール呼び出し（検索 1,000 回 10 ドル）	1 件あたりの検索回数	検索を挟む条件の絞り込み

とくに注意したいのは、「待っている時間」も時間課金に乗る点である。ログイン待ち、確認コードの入力待ち、相手サイトの応答待ち。人の確認を挟む設計にすると安全にはなるが、セッションを開いたまま待てば実行環境の費用が立つ。安全と費用がここで正面からぶつかる。

メモリの選択も同じで、1 GB と 16 GB は 16 倍の差である。どのメモリで動かす想定なのかが見積書に書かれていなければ、月額の桁が変わる。試算の手順はAI APIの料金体系と月額の試算方法にある。

論点 2. サイト単位の承認は、権限設計を発注側の問題にする

オリジン単位の承認は、実装を軽くするうえで理にかなっている。1 操作ごとに人へ確認を出すエージェントは、使い物にならないことが多い。

ただし裏側で起きるのは、「このサイトの中では何をしてもよい」という許可を出す設計になるということである。社内の基幹システムや取引先のポータルがその対象になった場合、許可の範囲は画面単位ではなくサイト単位になる。

実務で決めなければならないのは次の 3 つだと考えられる。

1. どのサイトを許可するか。 参照だけのサイトと、登録・変更ができるサイトを同じ扱いにしない
2. 取り返しのつかない操作の前に、人の確認を挟むか。 API は強制しないので、挟むなら発注側が要件として書く必要がある
3. ログイン情報を誰が預かるか。 サインイン画面はアプリ側で作る仕様なので、ID とパスワード、確認コードの受け取り口は発注側のシステムに置かれる

3 つめは見落としやすい。自社の認証がパスキー必須になっている場合、この仕組みではそのままログインできない。パスキー運用を崩して ID とパスワードに戻すのは、セキュリティの観点では逆行である。ここは「エージェントを入れるために認証を弱める」判断を避けるべき場所で、外部へ出してよいデータと認証の線引きはAI開発で外部APIに送ってよいデータの決め方で整理した。

論点 3. 相手サイトの利用規約が、設計の前提として残る

ブラウザの中で人の代わりに操作する仕組みは、相手先のサイトが自動アクセスを認めているかという前提の上に成り立つ。提供元が機能を出したことは、相手サイトの許諾とは別である。ここはAmazonがMetaのAIエージェントを遮断で扱った論点がそのまま当てはまる。

自社システムを操作させる場合は社内の話で済む。だが取引先のポータルや外部サービスを操作させる設計は、規約の確認が設計前の作業になる。確認せずに作ると、動くものはできても使えない。

発注者・企業への影響

第一に、見積書に「実行環境費」の行を立てさせる。トークン費とは別に、コンテナの時間課金とツール呼び出し課金を分けて書いてもらう。1 件あたりの想定セッション時間とメモリ量が書かれていれば、月額は自分で検算できる。

第二に、ホスト型ブラウザの料金・リージョンが未公表であることを前提に置く。現時点では価格が読めないので、ブラウザ操作を前提にした案件は月額に上振れの幅を持たせるか、価格が公表されるまで対象を絞るのが安全だと考えられる。データの保存先が気になる業種では、リージョンが未公表という事実そのものが判断材料になる。

第三に、承認の粒度を検収条件に書く。「サイト単位で許可する」「購入と削除の前には人の確認を挟む」「確認を挟む操作の一覧」を、仕様書か検収条件のどちらかに落とす。API が強制しない以上、書かなければ実装されない。

第四に、レート制限が未公表なので、処理が詰まったときの挙動を聞く。同時セッション数の上限が読めない状態では、ピーク時にどう振る舞うかが設計の論点になる。上限の種類はレート制限・スループットとはで整理した。エージェント案件の費用が高くなる構造そのものはAIエージェント開発の費用相場にある。

見積依頼に書く 3 行

1. 1 件あたりの所要時間とメモリ量を書かせる。 「20 分セッション × 何回・何 GB」で月額を出す
2. 人の確認を挟む操作を列挙する。 購入・送信・削除・承認。ここは発注側が決める
3. ログイン方式を明記する。 パスキー必須の社内システムが対象なら、そもそも操作させない範囲を先に切る

この 3 行は条件として書き出せるので、複数社に同じ文面で聞ける。無料で相見積もりの案件票では処理量と外部連携の条件を選択式で揃えているため、各社の運用費の前提を同じ形で比べられる。

まとめ

今回の変更で、エージェント案件の費用はトークン・実行環境の時間・ツール呼び出しという 3 本立てに整理されつつある。トークン単価は下がる傾向にあるが、時間課金は下がる理由がない。同時に動く数と 1 件の所要時間が月額を決めるので、設計の良し悪しが費用に出やすくなると考えられる。

承認の粒度がサイト単位になったことは、実装の軽さと引き換えに権限設計の責任を発注側へ寄せる変更でもある。「どのサイトで、何をさせないか」を決めるのは、ベンダーではなく業務を持っている側である。

参考・出典

• OpenAI「API Changelog」（computer use in Agents API・2026 年 9 月 29 日） https://developers.openai.com/api/docs/changelog
• OpenAI「API Pricing」（コンテナ料金・ツール料金・モデル単価） https://developers.openai.com/api/docs/pricing