「テストは書いた方がいい」と分かっている。分かっているけど、書けない——そういう状況に、心当たりがないだろうか。
機能の実装に追われていると、「テストは後で書こう」という気持ちになる。後でと思いながら、気がつけばそのままリリースになる。テストがないコードが積み上がっていく。この繰り返しを、私は何年も続けていた。
転機になったのは、Codexにテスト作成を任せてみた日だった。半信半疑で「このコードのユニットテストを書いてください」と渡してみたら、思っていた以上のものが返ってきた。そして使い続けていくうちに、テストへの向き合い方だけでなく、開発の進め方そのものが変わっていった。
この記事では、Codexにテスト作成を任せることで何が変わったか、どう使えばよいか、そして限界はどこか、を正直に書いていく。
結論から言うと、Codexにテストを書いてもらうことは、テストをサボる言い訳をなくしてくれるだけでなく、自分のコードの設計を問い直すきっかけになる。ただし、Codexが生成するテストをそのまま信頼するのは危険で、必ず自分のレビューが必要だ。
そもそも、なぜテストは億劫になるのか
テストが書けない理由を、開発者に聞くと大体こんな答えが返ってくる。「時間がない」「どこからテストすればいいか分からない」「コードが変わるたびにテストも直すのが面倒」——。どれも正直な理由だが、その根っこには共通した構造がある。
テストを書く時間がない、という感覚
「時間がない」というのは、半分本当で半分思い込みだと今は思っている。実装が終わった直後に同じコードのテストを書くのは、確かに時間がかかる。しかし、テストなしで進めた結果、バグが出てから修正する時間の方が、多くの場合ずっと長くなる。
問題は「テストを書く時間がない」のではなく、「テストを書くことに入れる気力がない」ということかもしれない。実装が終わった後の頭で、同じコードをもう一度テストの視点から考え直すのは、思っている以上に消耗する作業だ。
「テストを書く」という作業の心理的コスト
テストを書くことの心理的コストは、実装よりも見えにくい形で高い。実装は「作るものが決まっている」から進みやすい。でもテストは「何を、どの粒度で、どんな観点で」を自分で考える必要がある。この「設計の余白」が、億劫さの原因の一つだ。
また、テストは「動くもの」が増えるわけではないため、プロダクトの進捗として見えにくい。チームのレビューで「テスト書きましたか？」と聞かれるまで、後回しにしやすい。
Codexはこの「テストを考える」という心理的コストを、大幅に下げてくれる。コードを渡せば、ある程度の観点は自動で考えてくれる。自分がやるべきことは「Codexが考えたテストを検証する」という作業に変わる。これは、同じ内容の仕事でも全く違う感覚だ。
Codexにテスト作成を頼むとはどういうことか
Codexとは、OpenAI社が提供するAIコーディングエージェントのことだ。コードを読み取り、自然言語の指示に従ってテストを含む各種コードを生成することができる。
Codexへのテスト依頼の基本的な方法
Codexにテストを依頼するときの基本的な渡し方は、シンプルだ。テストしたいコードをそのまま貼り付け、「このコードのユニットテストを書いてください」と指示する。使っているテストフレームワーク（pytestやJestなど）を指定すると、そのフレームワークに合ったコードが返ってくる。
より精度の高いテストを得るためには、以下の情報を一緒に渡すと効果的だ。
- 使っている言語・テストフレームワーク（例：Python・pytest）
- そのコードが何をするかの説明（一言でよい）
- カバーしてほしい観点があれば指定（エラー系・境界値など）
- モックが必要な外部依存があれば伝える
たとえば、「このPython関数のpytest形式のユニットテストを書いてください。正常系・異常系・境界値のケースを含めてください」という形で渡すと、対応するテストケースを網羅した形で返ってくることが多い。
どんなテストを生成してくれるか
Codexが生成するテストの典型的な構成は、以下のようなものだ。
- 正常系テスト（期待される入力と出力の組み合わせ）
- 異常系テスト（Noneや空文字、型が違う値などを入れたときの挙動）
- 境界値テスト（最小値・最大値・ゼロ・マイナス値など）
- 例外が発生するべきケースの確認
関数が単純であるほど、生成されるテストの精度は高い。副作用が少なく、入力と出力が明確な純粋関数に対しては、ほぼそのまま使えるテストが返ってくることが多い。
一方、外部APIの呼び出しやデータベースとのやりとりが含まれる関数は、モックの扱い方をCodexが判断しきれないこともある。こういった場合は「この部分はモックしてください」と具体的に指定することで、精度が上がる。
実際にCodexにテストを作らせてみた
実際に使ってみて分かったことは、「便利さ」だけではなかった。Codexが生成したテストを読む作業を通じて、自分のコードへの見方が変わっていった。
ユニットテストの生成
最初に試したのは、日付の計算を行うPythonの関数だった。入力値として日付文字列を受け取り、特定のフォーマットに変換して返す、という比較的シンプルなものだ。
Codexに渡したところ、正常系のテスト（標準的な日付文字列）、異常系のテスト（不正な形式の文字列、None、空文字）、境界値のテスト（うるう年、月末など）が一度に返ってきた。自分でテストを設計した場合、うるう年のケースを最初から思いつけたかどうか、正直怪しいと思った。
生成されたテストをそのまま実行してみると、2件がパスせず失敗した。1件は私のコードのバグで、もう1件はCodexが誤った期待値を設定していたケースだった。この「2件の失敗」から、自分のコードに実はバグがあったことと、Codexの生成物も検証が必要だということを、同時に学んだ。
エッジケースの発見という副産物
Codexのテスト生成で最も意外だったのは、「自分では思いつかなかったエッジケース」を指摘してくれる場面があったことだ。
たとえば、リストを受け取って処理する関数を渡したとき、空のリスト・1要素のリスト・重複要素があるリストの3パターンをテストに含めてきた。自分でテストを書いていたとき、空のリストのケースは気にしていたが、重複要素については意識していなかった。Codexが生成したテストを通じて、「重複があったときにこの関数は何を返すべきか？」という仕様の曖昧さに気づいた。
Codexが生成するテストは、コードの動作確認だけでなく、仕様の抜け漏れを浮かび上がらせるツールにもなる。この副産物の価値は、使い始めてから気づいたことだ。
Codexのテスト生成で気づいた、開発の進め方の変化
Codexでテストを書くようになってから、開発のスタイルそのものが少しずつ変わってきた。その変化を整理する。
テストファーストの意識が生まれた
以前は「実装が終わったらテストを書く（書けたら）」という後付けのスタイルだった。Codexを使うようになってから、「実装前にCodexにテストを作ってもらい、それを満たすコードを書く」という流れを試してみた。
完全なTDD（テスト駆動開発）とは少し違うが、「この関数はどんな入出力を持つべきか」を先にCodexと整理してからコードを書くと、実装がぶれにくくなることに気づいた。Codexが生成したテストが「仕様書の代わり」として機能してくれるイメージだ。
特に、関数の設計が曖昧なまま実装を始めてしまうことが多かった私にとって、先にテストを作ることで「何を作るか」を言語化するプロセスが強制されるのは、意外に大きな変化だった。
コードの設計を見直すきっかけになる
Codexにテストを頼んでいると、生成がうまくいかない場面がある。そういうとき、多くの場合はコード自体の問題だということに気づいた。
テストしにくいコードには、共通した特徴がある。副作用が多い、外部への依存が関数の中に直接書かれている、1つの関数が複数のことをやっている——などだ。Codexがテストを生成しようとすると、こういった問題が「テストが書きにくい」という形で表面化する。
「Codexがテストを作れない関数は、設計に問題がある関数だ」という判断基準が、自然と身についてきた。テストのしやすさとコードの品質は相関しているという原則を、Codexを通じて実感として理解できた。
Codexが生成するテストの限界と注意点
Codexのテスト生成は強力だが、万能ではない。使っていて分かった限界と、注意すべき点を整理する。
テストの内容を自分でレビューする必要がある
Codexが生成したテストは、必ず自分でレビューしてから使うことを強く勧める。Codexは「テストらしいコード」を生成するが、それが「正しいテスト」であるかどうかは別の話だ。
よくある問題として、期待値が間違っているケースがある。コードの実際の動作ではなく、「こうあるべき」という推測で期待値を設定してしまうことがある。この場合、実装にバグがあっても、テストが間違った期待値で「成功」としてしまう。
また、テストのアサーション（検証内容）が弱すぎるケースもある。「エラーが出なければ成功」というテストは、コードが正しく動いているかどうかをほとんど検証できていない。Codexの生成物を見て、「何を確認しているテストか」を自分で理解することが必須だ。
ビジネスロジックのテストはAIが苦手
技術的なテスト（型のチェック・例外の発生・計算の正確さなど）はCodexが得意だが、ビジネスルールに依存するテストは精度が下がる。
たとえば、「このユーザーはキャンペーン対象か判定する関数」のテストを書いてもらおうとすると、Codexはキャンペーンのルールを知らないため、テストケースの設計が的外れになることがある。ビジネスロジックに関わるテストケースは、Codexに「観点を洗い出してもらう」ことはできても、「テスト内容の正否を判断する」のは人間が行う必要がある。
また、テストデータ（フィクスチャ）の作成は、実際のデータモデルに依存する部分が多いため、Codexだけでは完結しないことが多い。テストコードの骨格はCodexに作ってもらい、テストデータと期待値は自分で埋めるという分担が、現実的な使い方だと感じている。
よくある質問（FAQ）
Q1. テストを書いたことがない初心者でも、Codexでテスト作成はできますか？
はい、むしろ初心者にこそ効果的な使い方があります。Codexが生成したテストを読むことで、「テストとはこういう構造で書くものか」という学習材料になるからです。コードとテストを対応させて読む経験を積むことで、テストの書き方が徐々に身についていきます。最初は「Codexの生成物を読む・実行する・エラーを直す」だけでも十分です。
Q2. どんな種類のテストを生成できますか？
主にユニットテスト（関数・メソッド単位の検証）が得意です。結合テスト（複数のコンポーネントをまたいだテスト）やE2Eテスト（ユーザー操作をシミュレートするテスト）も生成できますが、外部依存が多いほど精度は下がります。「pytest形式のユニットテスト」「Jestを使った関数のテスト」のように、フレームワークを明示して依頼すると、使えるコードが返ってきやすいです。
Q3. Codexが生成したテストをそのまま使っても大丈夫ですか？
必ず自分でレビューしてから使うことを推奨します。Codexのテストは「テストらしい構造」を持っていますが、期待値が正しいかどうかは自分で確認が必要です。生成されたテストを実行し、パスしたケースもアサーションの内容を読んで「何を検証しているか」を把握してから使うのが安全です。特にエラー系・境界値のテストは、実際の挙動と照らし合わせて確認することを勧めます。
Q4. どの言語・フレームワークに対応していますか？
Python（pytest・unittest）、JavaScript・TypeScript（Jest・Mocha・Vitest）、Go（testing パッケージ）、Ruby（RSpec）、Java（JUnit）など主要な言語とテストフレームワークに対応しています。指定しない場合はCodexが判断して生成しますが、「pytest形式で」「Jest を使って」のように明示した方が使いやすいコードが返ってきます。
Q5. モック（外部依存の置き換え）が必要な場合も対応できますか？
対応できますが、明示的に指定する必要があります。「この関数はDBに接続しているので、DBへの呼び出しをモックしてください」「外部APIの呼び出し部分をpatch/mocking してください」のように、モックすべき対象を具体的に指定すると精度が上がります。モックの書き方はフレームワーク依存なので、使っているツール（unittest.mock、jest.fn()など）を一緒に指定するとよいです。
Q6. テストカバレッジを上げるためにCodexを使うことはできますか？
できます。カバレッジレポートを確認して「この関数のテストが不足している」と分かったら、その関数のコードをCodexに渡して「カバレッジが低い部分のテストを追加してください」と依頼できます。ただし、カバレッジを高くすることがテストの目的ではありません。Codexはカバレッジを機械的に上げることが得意ですが、テストが「意味ある検証をしているか」は人間が判断する必要があります。
Q7. GitHub Copilotのテスト生成とCodexのテスト生成は何が違いますか？
GitHub Copilotはエディタに統合されており、コードを書きながらリアルタイムでテストの補完を受け取れます。一方、OpenAI CodexはCLIや対話形式で使うもので、コード全体を渡して「このコードのテストを一式作ってほしい」という形で依頼するスタイルが合っています。Copilotは「書きながら補完」に向いており、Codexは「書き終えたコードのテストをまとめて生成する」作業に向いている印象です。両者を組み合わせて使うのが現実的な選択肢です。
まとめ：テストへの億劫さを、Codexは下げてくれる
Codexにテスト作成を任せてみる前と後で、自分の中で変わったことを整理する。
以前は、テストを書くことの「始めるまでの重さ」が最大の障壁だった。何をどこからテストすればいいか考えることが、すでに億劫だった。Codexを使うようになってから、その「最初の重さ」がなくなった。コードを渡せばひとまず土台が返ってくる。あとはそれを読んで、修正して、足りないところを自分で補う。この流れは、ゼロから書くよりはるかに始めやすい。
そして気づけば、テストを書くことへの心理的な壁が以前より低くなっていた。Codexを使う前と比べて、テストを書く頻度が上がったことは間違いない。
もちろん、Codexが生成するテストは完璧ではない。期待値の誤りやビジネスロジックのカバー不足は、自分で補う必要がある。「Codexが書いたから大丈夫」ではなく、「Codexが作った素材を、自分がレビューして完成させる」というスタンスが正しい使い方だと今は思っている。
テストを書くことの億劫さは、技術的な難しさよりも、最初の一歩を踏み出すエネルギーの問題だ。Codexはその最初の一歩を、驚くほど軽くしてくれる。
テストが積み上がっていないコードに心当たりがある方は、まず手近な関数一つをCodexに渡してみることをおすすめする。返ってきたテストを読むだけでも、何かが変わるかもしれない。
