3行まとめ
歩く順番。
触る範囲。
残す記録。
使い分け。
直す条件。
クリックさせる前に、どこまで任せるかを決めます。
- CodexにComputer Useで画面QAを任せる時は、対象flow、触ってよい操作、止める操作、残す証跡を先に決めます。
- 探索QAはComputer Use、固定scenarioはPlaywright、ログイン済み確認はChrome拡張やBrowser、と分けると運用しやすくなります。
- クリックしただけで終わらせず、再現手順、期待結果、実際の結果、証跡、修正へ送る条件まで固定します。
この記事では、OpenAI公式のCodex use cases、Codex app Features、Computer Use関連docs、Permissions docsを確認し、2026年6月1日時点の情報として整理しています。Codex app、Computer Use、Browser、Chrome拡張、API側のComputer Use modelは更新され得るため、導入前に最新docsと手元の権限設定を確認してください。
この記事でわかること
対象flow。
止める条件。
発見記録。
修正へ送る。
確認結果を修正やissueへつなげる形で残します。
- Codexに画面QAを任せる前に決めるflow分類
- Computer Useで触ってよい操作と止める操作
- QAログとして残す証跡の型
- Browser、Chrome拡張、Playwrightとの使い分け
- 不具合発見後に、その場で直すかissue化するかの判断
- 導入初週に見るべき失敗条件
OpenAIのCodex use casesでは、Computer Useを使ったQAとして、実際のproduct flowをクリックし、壊れている箇所を記録する使い方が紹介されています。別のuse caseでは、CodexにMac上のappをクリック、入力、navigateさせる用途も示されています。
ただし、Computer UseはE2E testの置き換えではありません。人間が触るように探索できる一方で、毎回同じ手順を完全に安定して繰り返す用途なら、Playwrightのような自動testへ寄せたほうがよい場面があります。
Codexにログイン済みChromeや内蔵Browserを使わせる考え方は、公開済み記事のCodexにログイン済みChromeを渡す前にでも整理しています。この記事では、画面QAの運用に絞ります。
前提知識
| 項目 | 内容 | 見方 |
|---|---|---|
| Use cases | QA用途。 | |
| Features | app機能。 | |
| Computer Use | 操作能力。 | |
| Permissions | 権限。 | |
| Model docs | API側の位置づけ。 |
Codex appでの使い方とAPI側のComputer Useを分けて確認します。
OpenAI公式のCodex use casesでは、Computer Useを使ってproduct flowをクリックし、壊れている点をログにするQA用途が示されています。Codex app Featuresでは、Codex appがproject、thread、worktree、Browser、Computer Useなどを扱う開発作業の入口として説明されています。
API側では、computer-use-preview がComputer Use tool向けのspecialized modelとして説明されています。Codex appで使うComputer UseとAPIで使うComputer Use modelは同じ説明ではありませんが、「画面を見て操作する能力」は強い権限として扱う必要があります。
Permissions docsでは、filesystemやnetworkの境界をprofileとして定義する考え方が説明されています。画面QAでも同じで、見るだけか、入力してよいか、送信してよいか、管理画面を触ってよいかを分けます。
公式情報で確認する範囲
| 確認先 | 見ること |
|---|---|
| Codex use cases | Computer UseでQAする用途 |
| Codex app Features | Browser、Computer Use、projectの位置づけ |
| Computer Use model docs | API側のComputer Useの位置づけ |
| Permissions | 操作権限、network、filesystem |
| Codex app docs | thread、project、worktreeとの関係 |
注意点
この記事は、本番画面を無条件にCodexへ操作させることを勧めるものではありません。Computer Useは、人間の操作に近い確認ができるぶん、送信、削除、購入、権限変更、顧客データ閲覧などの操作を慎重に扱う必要があります。
また、QAと修正を同じ依頼に混ぜると、確認結果と変更理由が読みにくくなります。まずQAだけを行い、修正へ進む条件を分けるのが基本です。
まずQAさせるflowを分ける
| 項目 | 内容 | 見方 |
|---|---|---|
| Explore | 探索。 | |
| Regression | 回帰。 | |
| Release | 公開前。 | |
| Production-like | 本番に近い確認。 |
同じ画面QAでも、探索と回帰確認では証跡の残し方が変わります。
画面QAを任せる前に、どのflowを歩くのかを分けます。
| flow | 例 | 向いている使い方 |
|---|---|---|
| 探索QA | 新しい画面を自由に触る | 崩れ、違和感、導線漏れを見つける |
| 回帰確認 | 決まった手順を再確認する | 修正後に同じ不具合がないか見る |
| 公開前確認 | release前の主要導線を見る | 重大な見落としを減らす |
| 本番に近い確認 | stagingやpreviewで実データに近い状態を見る | 権限と停止条件を強める |
Computer Useが向いているのは、探索QAや人間の目で見る導線確認です。リンクが分かりにくい、buttonが見つけにくい、modalが邪魔、error文言が不自然、といった発見は、人間操作に近い確認と相性がよいです。
探索QA
探索QAでは、Codexに「このflowを歩いて、壊れている点を探して」と頼むだけでは不十分です。対象screen、出発URL、使ってよいaccount、触ってよいbutton、触らないbutton、記録形式を指定します。
探索QAで見る項目は、次のように分けます。
| 観点 | 見ること |
|---|---|
| navigation | 目的の場所へ行けるか |
| copy | 文言が意味を持つか |
| state | loading、empty、errorが見えるか |
| form | 入力、validation、戻る操作 |
| visual | 要素が重ならないか |
探索QAの停止条件
探索QAは自由度が高いので、止める条件を入れます。決済、削除、外部送信、権限変更、顧客情報の閲覧、管理者操作に入ったら停止し、人間に確認を戻します。
「押せそうだから押す」ではなく、「ここから先は影響があるので停止した」と記録できるほうが、安全なQAになります。
回帰確認
回帰確認は、固定scenarioに近い確認です。何度も同じ手順を回すなら、Playwrightへ移す候補になります。Computer Useは、最初にscenarioを人間目線で確認し、後から自動test化する前段として使うと扱いやすいです。
回帰確認では、期待結果を先に書きます。「loginできる」ではなく、「email/passwordを入力し、dashboardへ遷移し、account名が表示され、error bannerが出ない」といった形です。
本番に近い確認
stagingやpreviewで本番に近い状態を見る時は、権限を強めに絞ります。実顧客データ、請求、通知、外部送信、権限変更、削除操作を含むflowは、見るだけにするか、送信前で止めます。
本番に近い確認では、証跡も重要です。URL、account種別、開始時刻、操作step、発見した問題、影響範囲、止めた操作を残します。
操作権限と停止条件を決める
見るだけ。
画面操作。
入力。
送信前停止。
人間確認。
本番影響がある操作は、送信前に止まる条件を入れます。
Computer Useは画面を見て操作できるため、権限を小さく始めます。
| 権限 | 許す操作 | 止める操作 |
|---|---|---|
| read-only | 表示確認、遷移 | 入力、保存、送信 |
| click-only | link、tab、menu | form送信、削除 |
| safe input | 検索、filter、dummy入力 | 本番送信、外部通知 |
| submit allowed | stagingでの保存 | 決済、権限変更 |
| admin review | 管理画面確認 | 人間承認なしの変更 |
触ってよい操作
最初に許可するのは、表示確認、tab移動、menu展開、検索、filter、dummy accountでの入力などです。これでも、導線の詰まりや文言の違和感はかなり見つかります。
送信を伴う操作は、stagingやpreview、dummy dataに限定します。外部通知や決済が絡む場合は、送信前に止めます。
止める操作
止める操作は明確に書きます。
| 操作 | 止める理由 |
|---|---|
| 削除 | 復元できない可能性がある |
| 決済 | 金銭影響がある |
| 外部送信 | 顧客や社外へ影響する |
| 権限変更 | account安全性に関わる |
| secret表示 | 機密情報を扱う |
本番影響がある時の扱い
本番影響がある操作を発見したら、Codexには「そのbuttonがあること」「押すと何が起きそうか」「押さずに止めた理由」を記録させます。操作せずに証跡を残せれば、QAとして十分な場合があります。
証跡の型を固定する
| 項目 | 内容 | 見方 |
|---|---|---|
| Step | 再現手順。 | |
| Expected | 期待。 | |
| Actual | 実際。 | |
| Evidence | 画像やURL。 | |
| Severity | 優先度。 |
証跡が揃うと、QA結果をそのまま修正taskへ渡せます。
画面QAは、証跡がないと修正につながりません。Codexが「壊れていました」と言っても、どこで何が起きたか分からなければ、開発者が再現できません。
| 項目 | 書くこと |
|---|---|
| Flow | どの導線か |
| Step | 操作手順 |
| Expected | 期待した結果 |
| Actual | 実際の結果 |
| Evidence | URL、画像、console、network |
| Severity | block、major、minor |
| Next | 修正、保留、追加確認 |
発見ログ
発見ログは、1件1件を短くします。長い感想ではなく、再現できる形にします。
| 項目 | 例 |
|---|---|
| Title | checkoutで住所validationが消える |
| Step | cartからcheckoutへ進み、postal codeを空にしてsubmit |
| Expected | validation messageが出る |
| Actual | loadingのまま止まる |
| Evidence | URL、screenshot、time |
| Severity | major |
再現手順
再現手順は、別の人が同じ状態へ行ける粒度にします。account、role、starting URL、test data、browser state、操作順、期待結果を入れます。
修正へ渡す最低限の証跡
修正へ進むなら、最低限次の証跡を要求します。
| 証跡 | 理由 |
|---|---|
| starting URL | 再現開始点を固定する |
| account role | 権限差を切り分ける |
| exact steps | 同じ操作を再現する |
| actual result | 何が起きたかを見る |
| expected result | 何へ直すか決める |
BrowserとChrome拡張とPlaywrightを分ける
| 項目 | 内容 | 見方 |
|---|---|---|
| Computer Use | 人間操作に近い確認。 | |
| Browser | local表示確認。 | |
| Chrome | ログイン済み確認。 | |
| Playwright | 再現test。 |
探索はComputer Use、固定scenarioは自動testへ寄せます。
Codexに画面を見せる方法は1つではありません。Computer Use、Browser、Chrome拡張、Playwrightを分けます。
| tool | 向いていること | 注意点 |
|---|---|---|
| Computer Use | 人間操作に近い探索QA | 権限と停止条件が重要 |
| Browser | local web appの表示確認 | loginや拡張が必要な場面は別 |
| Chrome拡張 | ログイン済みChromeでの確認 | 個人情報や本番操作に注意 |
| Playwright | 再現性の高い自動test | 探索的な違和感発見は弱い |
Computer Use
Computer Useは、人間が画面を見て操作する確認に向いています。未知のflow、複数appをまたぐ作業、既存の自動testがない画面の探索に使いやすいです。
一方で、毎回同じassertionを確実に見るなら、Playwrightへ移すほうが保守しやすくなります。Computer Useで見つけた重要flowを、後から自動testにする流れが自然です。
Browser/Chrome
CodexのBrowserは、local targetや開発中のweb appを見る時に向いています。Chrome拡張は、ユーザーのログイン済みChromeや既存tab、cookie、extensionが必要な確認に向いています。
ログイン済みChromeを使う時は、見せてよいaccount、触ってよいsite、止める操作を必ず決めます。詳しくはCodexにログイン済みChromeを渡す前にで整理しています。
Playwright
Playwrightは、再現性の高いscenarioをtestにする時に向いています。Computer Useで見つけた不具合を、再発防止に回すならPlaywrightへ移す候補です。
AI agentにBrowser検証を任せる設計は、Playwright MCPでAIエージェントにブラウザ検証を任せるでも扱っています。
修正へつなぐ判断を決める
- 1Find
見つける。
- 2Record
残す。
- 3Triage
分ける。
- 4Fix
直す。
- 5Verify
再確認。
見つけた不具合を、修正と再確認までつなげます。
QA結果を見つけた後、すぐ直すか、issue化するか、保留するかを分けます。
| 判断 | 条件 | 次の行動 |
|---|---|---|
| その場で修正 | 小さく、原因が明確、test可能 | Codexに修正scopeを渡す |
| issue化 | 原因不明、影響大、仕様判断が必要 | 再現手順と証跡を残す |
| 保留 | 低優先、仕様か不明 | backlogへ送る |
| 人間確認 | 本番影響、権限、顧客影響 | 承認を待つ |
その場で直す条件
その場で直してよいのは、原因が明確で、変更範囲が狭く、確認commandがある場合です。たとえば文言ミス、link切れ、CSSの軽微な崩れ、validation messageの出し忘れなどです。
修正へ進む時は、QA threadと修正threadを分けるか、少なくとも「ここから修正」と明記します。発見ログと修正ログが混ざると、後でreviewしにくくなります。
issue化する条件
仕様判断が必要なもの、複数systemをまたぐもの、顧客影響が大きいもの、原因が分からないものはissue化します。Codexには、再現手順、証跡、影響範囲、仮説、未確認をまとめさせます。
Codexに実装前の確認事項を質問させる流れは、Codexに実装前の確認事項を5つ質問させるでも扱っています。
導入初週の進め方
- 1日目
read-only確認。
- 2日目
低risk flow。
- 3日目
証跡型を固定。
- 5日目
修正連携。
- 7日目
自動test候補。
最初は本番影響のないflowで、証跡の品質を見ます。
最初の1週間は、本番影響のないflowから始めます。
| 日 | やること | 見ること |
|---|---|---|
| 1日目 | read-onlyで画面を歩く | 証跡が残るか |
| 2日目 | 低risk flowを触る | 停止条件が効くか |
| 3日目 | 発見ログの型を固定する | 再現できるか |
| 5日目 | 小さな修正へつなぐ | scopeが広がらないか |
| 7日目 | Playwright化候補を選ぶ | 再発防止へ回せるか |
初週の成功条件は、bugの数ではありません。見つけた問題を、再現手順、証跡、修正条件、未確認へ分けられることです。
小さく始める例
最初に任せるなら、次のようなflowが扱いやすいです。
| flow | 理由 |
|---|---|
| docs検索 | 本番影響が低い |
| signupの手前まで | 送信前で止めやすい |
| dashboard navigation | 導線を見やすい |
| empty state確認 | データ変更が少ない |
| preview URL確認 | release前に使いやすい |
いきなりcheckout、admin、billing、customer dataを含むflowへ進まないほうが安全です。
FAQ
固定ならtest。
権限確認。
送信前停止。
条件を分ける。
迷ったら、確認だけか変更まで任せるかへ戻ります。
Computer UseだけでE2E testは不要になりますか？
不要にはなりません。Computer Useは探索や人間目線の確認に向いています。毎回同じ確認を繰り返すなら、Playwrightなどの自動testへ移します。
ログイン済みChromeを使わせてもよいですか？
使う場合は、account、site、触ってよい操作、止める操作を決めます。個人情報、本番操作、外部送信、権限変更に触れる場合は、送信前に停止します。
Codexが見つけた問題をそのまま直してよいですか？
小さく、原因が明確で、確認方法があるなら直してよい場合があります。仕様判断や顧客影響があるものはissue化し、人間確認へ戻します。
証跡はどこまで必要ですか？
最低限、starting URL、操作step、期待結果、実際の結果、URLや画像などの証跡、severityを残します。修正へ渡すなら、account roleやtest dataも入れます。
本番画面でも使えますか？
見るだけなら有効な場面があります。ただし、削除、送信、決済、権限変更、顧客データ閲覧は止める条件を入れます。本番での操作は、人間承認を前提にします。
次に読むなら
参照した主な情報源
- Codex use cases – OpenAI Developers
- Codex app features – OpenAI Developers
- computer-use-preview model – OpenAI Developers
- Permissions – Codex – OpenAI Developers
- Codex app Worktrees – OpenAI Developers
更新履歴
- 2026年6月1日
OpenAI公式Codex docsを確認して初版を作成しました。
導入時には最新のCodex use casesとComputer Use関連docsを確認してください。
- 2026年6月1日: OpenAI公式Codex use cases、Codex app docs、Computer Use関連docsを確認し、初版を作成しました。