QA業務でCodexをよく使った7つの場面

1位：不具合の収集・整理・起票

複数の相談や作業メモから事象を集め、共通点と違いを整理するために使いました。問い合わせの文面をそのままチケットにすると、発生条件や影響が分かりにくいことがあります。起きていること、再現条件、期待結果、実際の結果を分けて書く作業が中心でした。

回避策がある場合は、それで影響をどこまで減らせるかも整理しました。似た報告でも、原因が同じとは限りません。一つにまとめられそうな報告と、別件にしたほうがよさそうな報告を挙げてもらい、人が確認する材料にしていました。

2位：不具合・仕様差分の原因切り分け

エンジニアの環境で再現しないときは、環境、データ、画面側の変換、APIレスポンスなど、何を比べるかを整理しました。次にどこを調べるかが分かると、確認のやり取りを進めやすくなります。

たとえばDevToolsのNetworkで対象のリクエストを確認し、返ってきた値と画面表示を比べます。「APIの値は期待と一致しているが、表示変換に差がありそう」という仮説が出たら、対応する処理と再現条件を追います。回答を原因確定として扱わず、次に確かめる候補として使いました。

3位：仕様・AC・テストケースの確認

要件定義書、受入条件（AC）、既存のテストケースを使って、機能の前提や確認する観点を整理しました。一般的な機能の説明では、そのプロダクトだけの条件が抜けてしまうことがあります。

実際、最初の回答が一般論に寄ったため、参照した資料を確認し、ACやテストケースを使ってFAQと確認観点を作り直したことがありました。それ以降は、対象資料を指定し、どの記載から判断したかを一緒に示してもらうようにしました。

4位：テスト環境・URL・アカウントの確認

テストに入る前に、対象の環境、確認用URL、利用するテストアカウントの条件を整理しました。過去の案内が複数あると、どの情報を使えばよいかの確認に時間がかかります。

環境名、用途、情報が更新された時点を並べると、確認し直したい箇所も分かります。外部の資料を使う場合は、接続している連携機能と権限で参照できる範囲を確認します。認証情報そのものを記事や共有メモに書き写す必要はありません。

5位：DB・データ確認

同じ登録日時のデータはどう並ぶのか、日付の条件によってどのタスクが表示されるのか。画面だけでは判断しにくいことについて、確認用SQLの案や、比較するデータを整理しました。画面の状態と保存された値を、同じ条件で見比べるために使っています。

確認用SQLでも、対象環境、抽出条件、結果の意味を確かめる必要があります。データを書き換える検証を行うなら、読み取りとは分けて、テスト用データと実行手順を決めます。

6位：QA業務改善ツールの作成

証跡作成の手間を減らすため、画像のクリック箇所に赤枠を付けて保存するChrome拡張や、ページ全体のスクリーンショットで固定ヘッダーが重ならないようにする改善に使いました。頻度は高くなくても、繰り返す作業へ使える点が印象に残っています。

ツールが動くようになった後は、保存される画像に問題がないか、操作が分かりやすいか、ページによって挙動が違わないかを確認しました。自分で作ったツールにも、QAの観点で確認を行いました。

7位：QAの判断や進め方の相談

主要機能が動かないとき、テストを続けるか、いったん開発へ戻すかで迷うことがあります。新機能が使えず以前の運用で回避している場合も、何を課題として残すかを考える必要があります。そうした場面で、判断するための論点を整理しました。

影響、まだ済んでいない検証、回避策、確認が必要な担当者を書き出すと、チームで相談しやすくなります。最後は、そのプロダクトの品質基準や業務の事情を踏まえて、人が判断します。

この記事で紹介しているのは私の利用例です

OpenAIの公式資料では、Codex CLIでローカルのファイルを調べたり編集したり、コマンドを実行したりできることが説明されています。一方、この記事で書いた利用頻度や効果は、私自身の振り返りです。公式の性能評価や、利用者全体のランキングとして紹介しているものではありません。