開発ログ2026年9月12日by K.hirano

ChatGPT WebをAPI代わりにして大丈夫？Codexブラウザ自動化の境界線

Codex CLIやPlaywrightからChatGPT Webへ質問を送り、回答を回収するのは規約上大丈夫なのか。公式情報と実務判断を分け、個人開発で迷いやすい12例をやさしく整理します。

#codex#chatgpt#ブラウザ自動化#個人開発

こんにちは。9月も半ばに入り、夏のあいだ後回しにしていた手作業を、そろそろ自動化で片付けたくなる頃ですね。

先に私の答えを書くと、ChatGPT Web（ブラウザで開くいつもの ChatGPT の画面）を API（プログラムから呼び出すための正式な窓口）の代わりにして、無人で何度も回す構成は採用しません。OpenAI の公式 Computer Use（AI がパソコンの画面を操作する機能）は、ChatGPT 自身を自動操作できない仕様になっていて、公式が挙げる理由は「ChatGPT のセキュリティポリシーを迂回する可能性があるため」です。一方で、「ブラウザ自動化は全部規約違反」「一度でも自動入力したら即アウト」とまで断言できる資料も、今回確認した公式ドキュメントにはありませんでした。

Codex CLI（OpenAI の、ターミナルで動く AI コーディング道具）からブラウザを開き、ChatGPT Web に質問を入力して、返ってきた回答を自動で回収する。技術的には作れそうですし、「自分の契約、自分のブラウザならいいのでは？」と思う気持ちも分かります。私も最初は、どこが普通の自動化と違うのか引っかかりました。この記事では、話を必要以上に怖くせず、個人開発で迷いやすい12例を3段階に分けて整理します。

判定は3段階。法律の判定ではなく実務の判断です

12例は、次の3段階で振り分けます。

問題なし：OpenAIが用意した公式経路、または通常のブラウザ利用
避けたい：明確な許可を確認できず、ChatGPT自身の自動化に踏み込む
かなり危険：API代替、無人反復、上限や保護機能の回避

これは法律上の判定ではなく、2026年9月12日時点の公式情報を踏まえた、個人開発者向けの実務判断です。公式資料が直接説明していない外部ツールの扱いは、確認済みの事実から安全側へ寄せた推測であることも、ここで明記しておきます。

「ブラウザを使える」と「ChatGPTを自動操作できる」は別の話

最初につまずきやすいのがここです。

Codexにはブラウザを操作する機能があります。公式のBrowserドキュメントでも、ページを開く、クリックする、入力する、画面を確認するといった操作が案内されています。自分で作ったWebアプリの表示確認や、一般のWebサイトを使う作業は想定内です。

出典: OpenAI公式 Browser（2026年9月12日確認）

ただ、ブラウザで開けるページなら何でも自動化してよい、という意味にはなりません。公式のComputer Useドキュメントは、ChatGPT自身の自動操作について別の線を引いています。

出典: OpenAI公式 Computer Use（2026年9月12日確認）

大事なのはブラウザという道具ではなく、何を、どの経路で、どこまで自動化するかです。この記事では、操作対象、公式経路、無人反復、上限回避の4点を順に確かめて判定していきます。

同じ「ブラウザが開く」でも、ログインと質問の自動入力は中身が違う

`codex login`でブラウザが開くのは公式の認証で、問題なし

Codex CLIで codex login を実行するとブラウザが開き、ChatGPTアカウントでログインします。これは公式の認証フローです。

このときブラウザは本人確認のために開いていて、ChatGPTの会話画面へ質問を投げるためではありません。ログインが済むと認証情報がCodexへ戻り、以後はCodex CLIを正式なクライアントとして使います。

OpenAIはCodexの利用方法として、次の2つを公式に案内しています。

ChatGPTでサインインし、サブスクリプション経由でCodexを使う
APIキーでサインインし、従量課金で使う

出典: OpenAI公式 Authentication（2026年9月12日確認）

Codex CLI の権限まわりの変化は Codex CLI 0.112.0→0.114.0 で権限設計が変わった。request_permissions が実務で効く理由にまとめているので、あわせて読むと今回の論点とのつながりが見えやすいと思います。

ChatGPT Webへ質問を自動入力するのは、Web画面を非公式APIにする構成

一方、PlaywrightやSelenium（どちらもブラウザを自動で操作するための道具）で chatgpt.com の会話画面を開き、質問の送信から回答の取得まで自動化するのは、認証フローではありません。

見た目は「ブラウザで文字を入れているだけ」でも、プログラム側から見るとChatGPT Webを呼び出し口にしています。これを繰り返せば、実質的にはWeb画面を非公式APIとして使う構成になります。2つが同じなのは「ブラウザを使う」という表面だけで、中身はまったく違います。

個人開発で迷う12パターンを判定する

1. Codex CLIをChatGPTアカウントで使う

判定：問題なし

codex loginから公式フローでログインし、Codex CLIの中で調査や実装を進める形です。ChatGPTの契約をCodexで使う正式な方法として案内されています。「定額契約をCLIで使うのは大丈夫？」という疑問なら、まずこの経路を選べばよいです。

2. APIキーで自作リサーチエージェントを作る

判定：問題なし

自分のプログラムからOpenAI APIを呼び、必要に応じてWeb検索ツールを使う構成です。呼び出し回数やエラーをコードで扱いやすく、無人実行にも向いています。料金はAPI側で発生しますが、プログラムから使うために用意された正面玄関です。

3. Codexで自作Webアプリを開いて動作確認する

判定：問題なし

自分のPCの中で動かしている開発用サイト（localhost）の画面を開き、ボタンを押し、表示崩れやフォームの動きを確かめる。これはCodexのBrowserが想定している代表的な使い方です。ChatGPTを操作しているのではなく、ChatGPTに自分のアプリをテストしてもらっている形ですね。

4. Codexで企業サイトや公式ドキュメントを調査する

判定：おおむね問題なし

製品仕様、料金、リリースノート、論文などを読ませて要点をまとめる使い方です。ただし、調査対象のサイト側の利用規約、ログイン条件、アクセス制限は別に確認する必要があります。「Codexがブラウザを使うこと」と「相手のサイトが自動アクセスを許可していること」は別問題です。

5. ChatGPT Webで自分が質問し、結果を手でコピーする

判定：問題なし

これは通常のChatGPT利用です。調査結果を自分の目で確かめ、必要な部分をエディタへ移すだけなら、今回問題にしている無人の疑似API化とは違います。

6. マクロでChatGPT Webへ定型文を一度貼り付ける

判定：避けたい

ここから境界があいまいになります。人が見守りながら、単発で文章を貼り付けるだけなら、無人のバッチ処理より危険度は低いでしょう。

ただ、今回確認した公式資料には「一回だけなら許可」といった線引きはありません。ChatGPT自身を自動操作する構成である以上、私は常用しません。

7. Playwrightで質問送信から回答取得まで自動化する

判定：避ける

入力だけでなく、生成が終わるのを待ち、回答のテキストを取り出して次の処理へ渡すところまで作ると、ChatGPT Webを呼び出しAPIとして扱っています。なので、この構成は避けます。

小さな個人ツールでも、構造としてはAPIの代わりです。最初は1件でも、便利なのでキュー、再試行、並列実行を足したくなるんですよね。後から公式APIへ移すより、最初から公式経路で作るほうが楽です。

8. Web版Deep Researchを自作バッチから連続実行する

判定：かなり危険

たとえば商品名をCSVから読み込み、ChatGPT WebのDeep Researchへ順番に投入し、レポートを保存する構成です。

人間向けのWeb機能を、自作システムの裏方に置き換えています。無人、反復、結果の回収が揃うため、個人開発でも採用しないほうがよい領域です。

9. ChatGPT Webの回答をCodexへ戻し、次の質問を自動生成する

判定：かなり危険

Codex → ChatGPT Web → Codexというループです。2つのエージェントを組み合わせたくなる発想は自然ですが、ChatGPT Web側は依然として非公式な呼び出し口です。モデル同士を協調させたいなら、それぞれのAPIや、公式に提供されているエージェント連携機能を使います。

10. 複数アカウントで利用上限を分散する

判定：NG判断

ここは迷いにくいところです。目的が上限の回避になっています。ブラウザ操作かどうか以前に、その設計は採用しないでください。

11. CAPTCHAや確認画面を自動回避する

判定：NG判断

確認画面やCAPTCHA（相手が人間かどうかを確かめる仕組み）は、ただ面倒な画面ではなく、保護や本人確認のために置かれています。突破する方法を組み込んだ時点で、安全側の説明は難しくなります。

12. Business／EnterpriseでCodexアクセストークンを使う

判定：問題なし

OpenAIは、信頼された非対話型（人が画面の前で応答しない）のCodex CLIや、Codexを別のプログラムから操作するapp server向けに、Codexアクセストークンを案内しています。現在はBusiness／Enterprise向けです。

出典: OpenAI公式 Access tokens（2026年9月12日確認）

一般的なモデルAPIを呼びたいならPlatform APIキー、Codexの非対話型実行には対応するCodexアクセストークン、と役割を分けて使います。

自分の構成は、ツール名ではなく4つの質問で判定する

Playwrightだから危険、Codexだから安全、という単純な話ではありません。ツール名で判断すると混乱するので、実装する前に次の4つを順番に確かめてください。

1. 操作対象はChatGPT自身か

自作サイトや一般サイトの調査なのか、ChatGPTの会話画面なのか。後者なら慎重側へ寄せます。

2. 公式の呼び出し口があるか

Codex CLI、OpenAI API、正式なアクセストークンで実現できるなら、そちらを使います。Web画面をAPI化する理由が「API代を払いたくない」だけなら、設計を見直したほうがよいです。

3. 人が確認する単発操作か、無人の反復処理か

単発の操作補助と、夜間バッチで100件流す仕組みは同じではありません。回数が増えるほど、画面の変更で壊れる技術的なリスクも、利用上のリスクも大きくなります。

4. 上限や保護機能を避ける目的がないか

複数アカウント、CAPTCHA回避、確認画面の自動承認などが必要になったら、その時点が止めるサインです。

AIブラウザ自動化の判断フロー。操作対象、公式経路、無人反復、上限回避の順に確認する

ツール名ではなく、対象・経路・自動化の強さ・回避目的の4点で判断する

自作リサーチエージェントなら、公式の3構成から選ぶ

小さく始めるなら Codex CLI＋公式ログイン

コード、ローカルファイル、Web調査をひと続きの作業として進めたいなら、まずCodex CLIを公式ログインで使います。個人開発ではいちばん手軽です。

定期実行するなら OpenAI API＋Web検索

毎朝のニュース収集、複数商品の比較、JSONでの保存など、プログラムとして繰り返すならAPIが向いています。予算の上限、実行回数、タイムアウト、引用URLの保存も自分で管理できます。

組織で回すなら正式なトークンと管理機能

Business／EnterpriseでCIや社内の実行環境からCodexを動かすなら、アクセストークンやワークスペースの権限を使います。誰が実行したかを追える構成にしておくと、後から困りません。

「規約違反か」は二択で言い切れない。でも実装の判断は簡単

今回の公式資料から、はっきり言えることは2つです。

ひとつは、Codex CLIのChatGPTログイン、API、正式なアクセストークンという公式経路があること。もうひとつは、OpenAI自身のComputer Useでは、ChatGPTの安全ポリシーを迂回し得るためChatGPT自身を自動化できないことです。

そこから先、外部のマクロを一度使っただけで規約違反になるのか、何回ならアカウント措置になるのかは、確認した資料からは断定できません。だから「絶対セーフ」も「即BAN」も言いすぎです。

それでも、実装の判断はもっと簡単にできます。

ChatGPT WebをAPI代わりにしない。自動化したいなら、最初から公式CLIかAPIを選ぶ。

これで十分です。ブラウザの画面の部品を追いかけるコードも、ログイン切れの復旧も、画面変更への追従も要りません。グレーな近道を選ぶより、結果として個人開発が長持ちします。

この記事を書いた人

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！