Codex Computer UseでLPを点検：リンク・フォーム・画面幅の確認手順

ランディングページの点検では、「問題なさそう」という感想ではなく再現できる記録が必要です。この練習には、リンク切れ、保存せずに成功を表示するフォーム、狭い画面で確認すべきレイアウトを含む架空のページと、その修正版を用意しました。

QA練習キットをダウンロード。Pythonサーバー、両ページ、テスト、結果記録用CSV、答え合わせ用の説明を含みます。画面は英語です。本記事では実ブラウザーでの操作や表示確認が済んだとは主張していません。

ローカルで起動する

Python 3.9以降を用意し、解凍した qa-kit フォルダーで実行します。

python3 -B server.py --port 8876

サーバーは 127.0.0.1 のみで待ち受けます。使用が許可されたブラウザーで、ターミナルに表示されたURLを開きます。ポートが使用中なら空いている番号に変更し、手順内のURLも統一します。ただし、アクセス拒否を回避する目的で変更してはいけません。終了時はCtrl-Cで停止します。

/ が問題を含むページ、/fixed が修正版、/submissions が受信記録です。@example.test で終わる架空アドレスのみを使用してください。実際の連絡先、購入、外部へのフォーム送信は必要ありません。

最初は答えを渡さない

Codexにはナビゲーション、フォーム、1440・390・320 CSSピクセル幅でのレイアウトを確認させます。期待する結果と実際の結果、証拠を保存し、ページは修正しないよう指示します。初回はソースと答え合わせ用説明を渡さず、観察を記録させてください。

それでもこれは教材であり、盲検ベンチマークではありません。意図的な少数の不具合から、一般のサイトに対する検出率は求められません。

最初の点検に使う指示を用意する

次の指示だけを最初のテスターに渡します。この後にある故障の説明やソース、解答は初回の点検に含めないでください。許可済みのブラウザーを選び、環境に応じた操作方法で実行します。

http://127.0.0.1:8876/ のローカル演習ページを点検する。
ソースや解答は読まず、ページを変更しない。
ブラウザーのバージョン、時刻、URL、実際のビューポート寸法を記録する。
1. /submissions の現在の記録を開始時点の基準として保存する。
2. Working guide と Pricing を開き、最終URL、タイトル、内容の適切さを記録する。
3. 空欄、not-an-email、qa-run1@example.test を別々に試す。
   毎回表示を記録し、/submissions を再読込して受信結果を保存する。
4. 幅1440、390、320 CSSピクセルで欠け、ページ全体の横はみ出し、操作性を確認する。
   寸法を設定・取得できない場合はpendingとし、見た目で推測しない。
5. 手順、期待値、実測結果、証拠の場所を報告する。未実行は合格にしない。
6. /fixed では開始時点の記録を改めて保存し、qa-run2@example.testを使って繰り返す。
7. 一時的な表示設定を戻す。実在の連絡先は送信しない。
拒否された対象では停止する。観察と推測を分け、回避しない。
成功表示だけで保存済みとせず、幅変更だけで実機検証済みとしない。

証拠は run-01/original/ と run-01/fixed/ に分け、receiver-before.json、receiver-after.json、各幅の画像、報告書を置くと比較しやすくなります。これは推奨するファイル構成であり、今回撮影済みの画像があるという意味ではありません。

リンク先の意味も確認する

Working guide と Pricing を別々に開き、最終URLとページタイトルを記録して戻ります。404だけでなく、200を返しても無関係な内容なら問題です。修正版のPricingは、単に存在するページではなく、架空の料金説明に到達する必要があります。

フォームは3種類の入力で試す

別タブで /submissions を開き、操作前の件数を確認します。フォーム操作後に受信タブを再読込し、古い表示を結果と取り違えないようにします。

修正版には qa-run2@example.test を使い、以降も毎回新しいアドレスにします。表示だけで保存成功と判断せず、件数と内容を両方確認します。重複保存も問題として扱います。

問題版が保存せずに成功を表示するのは、ソースに設定された教材上の性質です。ブラウザーがその問題を発見したという実測結果ではありません。

件数だけでなく受信記録の中身を比べる

次のJSONは判定ルールの説明用データです。ブラウザーで収集した結果ではありません。

{
  "before": [{"email": "old@example.test"}],
  "after": [
    {"email": "old@example.test"},
    {"email": "qa-run1@example.test"}
  ]
}

1件から2件になっただけでは合格にできません。以前の記録が変わらず、新しい記録が今回のアドレスと一致することを確認します。同じアドレスが2件追加されれば重複、別のアドレスなら別試行の可能性があります。実際の証拠は時刻を含む完全な記録を保存し、この例に合わせて情報を削らないでください。

空欄・不正形式では説明のあるエラーと追加ゼロ、修正版の形式が正しい架空のアドレスでは一致する追加1件が期待値です。画面と受信側を組み合わせると入力検証、誤った成功表示、保存処理を区別できます。他の本番フォームの信頼性を証明するものではありません。

幅を指定して表示を調べる

各幅で指標カード、ナビゲーション、入力欄、ボタンを確認します。横方向にはみ出していないか、文字が隠れていないか、ボタンや入力欄を操作しにくくないかを観察し、実際のビューポート寸法とともにスクリーンショットを保存します。

デスクトップブラウザーの幅変更は画面幅のシミュレーションです。実機のタッチ、キーボード、性能まで検証したことにはなりません。終了後は一時設定を戻します。

原版と修正版を同じ表で検証する

以下はソースから分かる設計上の挙動です。ブラウザー実行後に、別途「実際の結果」を記入してください。

390と320の幅では、カードを見るだけでなく入力欄やボタンに到達して操作できるかも調べます。表が専用コンテナー内で横スクロールする状態と、文書全体がはみ出す状態を区別してください。MDNのoverflow解説はその仕組みの参考であり、この演習の表示が合格した証拠ではありません。

再現可能な不具合報告にする

URL、環境、入力、手順、期待値、実際の結果、証拠の参照先を残します。空欄を受け付ける、誤形式を受け付ける、偽の成功を示すという症状が同じ処理に由来する場合、別々の根本原因として数を増やさないでください。

初回の後で答え合わせをし、見落としと誤検出も記録します。新しい入力で /fixed を再確認し、別のタスクから同じ説明だけで再現できるかも確かめます。

不具合報告を具体的に書く

次はソースを基に作った教材用の報告例です。ブラウザーが発見した不具合や撮影済みスクリーンショットを装ったものではありません。

自分の報告ではソース上の説明を実際の観察で置き換え、同じ試行の証拠を添えます。受信側を確認できなければ保存状態は未確認です。画像がない、またはタブが古いことだけでバックエンド故障と判断しません。3つの入力ケースが同じ根本原因に由来することもあるため、ケース数と欠陥数を分けます。

結果がはっきりしないときの確認先

記録はローカルの submissions.jsonl に保存されるため、再起動だけで消えるとは限りません。証拠は保存し、新規状態が必要なら別の展開先を使います。競合調査の手順でも、確認できた事実と未解決項目を分けて残します。

確認済みなのはオフラインテスト

Python 3.9.6とNode.js 24.13.0で、7件のPythonハンドラーテストと9件のJavaScriptシミュレーションが通過しました。新しく解凍したコピーでも同じ結果でした。

python3 -B -m unittest discover -s . -p 'test_*.py' -v
node test_form.mjs

Python側は不正な長さやJSON、架空アドレスの検証、書込み、ルート、テンプレートを検査します。JavaScript側は模擬の document と fetch でフォームコードを実行します。ブラウザー起動やネットワーク通信はありません。

したがって、実際の送信、レイアウト、Codexによる発見能力は未検証です。3つの幅のスクリーンショットと修正前後のブラウザー比較も未実施です。アクセシビリティ、安全性、性能、実機横断の監査を置き換えるものでもありません。

結果をコードで判定する例はオフラインコントローラー、接続で困る場合は権限の確認手順を参照してください。