同じ画面を何週間も触り続けると、初見ユーザーがつまずく箇所を見落としやすくなります。
この記事では、OpenAIのコーディングエージェント「Codex」を使い、SaaSを実際の利用者の視点で検証する手順を解説します。コードレビューでは拾えないUIの不具合やUX上の問題を、エージェントに探索させて洗い出す方法がわかります。
この記事でわかること
- Codexに初見ユーザー視点の探索テストを依頼するプロンプト例
- Computer Useによる「見て・クリック・入力」の動作原理
- ログイン済みセッションを使うChrome拡張機能の活用法
- Playwright CLIを併用してトークン消費を抑えるコツ
- 従来の自動テストやClaude Codeとの使い分け
開発者の盲点がSaaS品質を下げる
ソロ開発や少人数チームでは、機能追加と修正に追われ、テスト工数が後回しになりがちです。自分で作ったプロダクトほど「このボタンはここにある」と前提を知っているため、ローディング表示の欠落や画面間の挙動の不一致を見逃しやすくなります。
XDA Developersの執筆者は、CodexにSaaSのフロントエンドを初見顧客として操作させたところ、数週間見落としていた問題が次々と報告されたと述べています（参考）。ローディング状態の不備、壊れた機能、オンボーディングの混乱、信頼感を損なうUIなどが挙がり、再現手順付きで返ってきたため、修正の優先順位をつけやすかったとのことです。
Codexに渡すプロンプトの型
Codexはソースコードを読むのではなく、画面を見ながら操作します。執筆者が使ったプロンプトは次のとおりです。
Test this application using the existing logged-in session. Act as a first-time customer. Create a new project, complete the primary workflow from start to finish, and identify bugs, UX issues, UI inconsistencies, confusing copy, broken flows, trust issues, and anything that would prevent adoption. Focus on the most important findings and provide clear reproduction steps where applicable.
ログイン済みセッションの利用、初見顧客としての振る舞い、バグだけでなくUX・信頼感まで評価対象に含める——この3点を押さえておくと報告の質が上がります。再現手順の要求を入れておくと、報告がそのまま修正タスクに変換しやすくなります。
Computer Useが従来テストと違う理由
CodexのComputer Useは、OpenAIが「see, click, and type（見て、クリックし、入力する）」と説明する機能です。画面を認識し、ボタンを押し、フォームに入力し、遷移後の結果を観察します。
PlaywrightやSeleniumのスクリプトは「Aをクリック→Bをクリック→Cのテキストを検証」という固定手順です。Codexは「初見ユーザーとして主要フローを完了せよ」という目標だけ渡すと、自分でクリック先や探索ルートを決めます。この探索型の動きが、定型テストでは拾えない問題の発見につながります。
典型的な流れは次のとおりです。
- 操作目標をCodexに伝える
- アプリを開き、現在の画面を認識する
- 文脈に合った操作（クリック、入力、待機）を実行する
- 想定外の挙動を記録し、タスク完了まで探索を続ける
ログインが必要なSaaSをテストする
GoogleログインやメールOTPなど、パスワードなしの認証だけを採用しているSaaSでは、自動テストがログイン画面で止まることが多いです。CodexはChrome拡張機能で、すでにログイン済みのブラウザ状態を共有できます。
セットアップはCodexデスクトップアプリのPluginsからChromeプラグインを追加し、拡張機能がConnectedと表示されるまで権限を承認します。拡張機能はサインイン済みのタブをCodexと共有するため、OTPやOAuthの壁を迂回せず、実際の利用環境のまま検証できます。OpenAIの公式ドキュメントでは、LinkedInやSalesforce、Gmail、社内ツールなど、ログインが必要なサイト向けの用途として位置づけられています。
ローカル開発サーバー（localhost）の検証には、アプリ内ブラウザを使うのが推奨です。Chrome拡張機能は本番相当の認証済みWebアプリ向け、という使い分けが公式に示されています。
Playwright CLIでトークン消費を抑える
ブラウザ操作はページの再読み込みや要素の解析が繰り返されるため、通常のコーディングタスクよりトークンを多く消費します。執筆者はPlaywright CLIの併用で効率化したと報告しています。
PlaywrightはCookieやセッション情報を保持したまま操作を続けられるため、毎回ログインからやり直す必要がありません。プロジェクトごとにブラウザプロファイルを分ければ、複数SaaSの検証環境も切り替えやすくなります。
CLIベースの操作は、大きなツール定義やアクセシビリティツリー全体をコンテキストに載せるより、必要な結果だけを返す点でも有利です。Codex向けのPlaywright CLIスキルでは、ページを開く→スナップショットで要素参照を取得→操作→再スナップショット、という流れが推奨されています。
Claude Codeや定型テストとの位置づけ
Claude Codeは注目を集めていますが、CodexはUI探索テストの文脈で独自の強みがあります。執筆者はCodex Proプラン（月20ドル）で、Claude Codeより余裕のある利用枠を実感していると述べています。
使い分けの目安は次のとおりです。
- Codex + Computer Use：初見ユーザー視点の探索的QA、認証済みWebアプリの操作
- Playwrightテストスイート：リグレッション防止、CI/CDへの組み込み
- Claude Code：コードベース中心の開発・リファクタリング
定型テストは「決まった手順が壊れていないか」を守り、Codexの探索テストは「想定外の使い方で何が起きるか」を探ります。両方を組み合わせるのが現実的です。
検証を習慣にする
CodexにSaaSを触らせるワークフローは、新機能リリース前の最終チェックや、長期間触れていない画面の定期点検に向いています。プロンプトに「初見顧客」「主要フローの完走」「再現手順の提示」を入れ、認証が必要ならChrome拡張機能、トークン節約にはPlaywright CLIを併用する——この3点を押さえれば、開発者の盲点を補う第三の視点として機能します。