テストは何のために書くのか。AIが書いたコードほど「期待値」を先に決める

📌 あわせて読みたい: AIの実装を受け取った後の確認項目は「動いた」以外に確認する4つのことへ。この記事はその前段、そもそもテストは何を確認するもので、なぜ自分で書くのかだけを扱います(テストの書き方・フレームワークの手順ではありません)。

AIが書いたコードを実行して、画面が出た。エラーも出ない。ここで手が止まります——「これ、自分でテストを書く意味あるの?」と。動いて見えることと、期待した通りに動くことは別の話です。その差を埋めるのがテストの役割です。

結論:テストは「入力に対して期待する応答」を先に置くコード

テストケースは、特定の入力集合に対する特定の応答を確認する、テストの個別単位です。つまりテストとは、「この入力なら、この結果になるはず」という期待を人が決めて、コードの形で置いておくものです。

AIが作った変更にも、この期待結果を人が決めてテストにしておけば、意図と異なる変更を検出する入口ができます。ただし、テストが通ったことは、安全性やすべての要件が満たされたことを示すものではありません。

テストケースが確認しているもの

Pythonのunittestは、テスト自動化、セットアップと後片付けの共有、テストの集約を支援する単体テストフレームワークです。その中でテストケースは、特定の入力集合に対する特定の応答を確認する個別単位として定義されています。テストランナーはテストを実行し、その結果を利用者へ提供します。

ここで押さえたいのは、確認される対象が「書いた入力と期待値」に限られるという点です。書いていない入力について、テストは何も言いません。

期待値を先に決める意味

先に期待値を決めるのは、実装を見てから「まあこうなるよね」と後付けするのを避けるためです。実装の出力を見てからテストを書くと、テストは実装が現にそうなっていることを書き写すだけになります。それでは、意図とのズレは見つかりません。

依頼した内容を、入力と期待する結果の形に言い換えられるか。これはAIに実装を依頼する時点の整理そのものでもあります。

AI生成コードに適用する順序

順序としては、期待する入力と結果を人が決め、それをテストとして置き、AIが出した変更をそのテストに通す、という並びになります。GitHubは、テストを「変更がマージされる前に検証する自動チェック」として説明しています。変更を取り込む前に機械的な確認を通す、という置き方です。

当社の運用でも、検証はAIの自己採点ではなくコードで行う方針を取っています。AIに「問題ありません」と言わせるのではなく、実行結果で確かめるということです。

テストで確認できない範囲

テストが通ってもバグ・脆弱性・要件漏れがないと言えるわけではありません。テストが確認できるのは、書かれた入力と期待値の範囲だけです。そのためAIが書いたコードを採用するときは、テストの結果に加えて、依頼した要件と合っているか、差分が意図した範囲に収まっているか、秘密情報が混ざっていないかを別途確認する必要があります。この範囲の切り分けは、当社の検証方針に沿った編集上の整理です。

なお、テストが必要なのはAIが書いたコードだけではありませんし、特定の言語やフレームワークが唯一の正解ということもありません。この記事のPythonの例は、テストケースとテストランナーという用語を確認するために挙げています。

🔗 次に読む

• テストの後、人が何を見るかは「動いた」以外に確認する4つのことへ。
• AIの業務活用の全体像は生成AIの業務活用 完全ガイドへ。
• (公開後に追加)変更履歴の残し方 / CIによる自動チェック

※本記事は2026年7月22日確認時点のPython公式ドキュメント・GitHub公式ドキュメントおよび当社の運用記録に基づく整理です。テストの成功は、安全性・正確性・要件の充足を保証するものではありません。