要約： VAONでは、Claude Codeで書いたコードを、単体テストとE2Eテストと同じプルリクエストに入れて提出します。実装計画の完了条件がテストケースになります。AIが書いたテストは、業務ルールを確かめているか実装をなぞっているだけか、必ず通るテストはないか、モックが実際の動きを隠していないか、失敗時のケースが抜けていないか、の4つの問いで読みます。
目次
- なぜAIが書いたコードとテストを同じプルリクエストに入れるのか
- 実装計画の完了条件は、どうテストケースになるのか
- AIが書いたテストを、エンジニアはどんな問いで読むのか
- テスト付きのプルリクエストは、お客様に何を残すのか
- AIが書いたテストでは代わりにならないこと
- よくあるご質問
1. なぜAIが書いたコードとテストを同じプルリクエストに入れるのか
テストを同じプルリクエストに入れるのは、レビュアーが「コードが何をするか」と「それが正しいという根拠」を同時に確認する必要があるためです。テストが後回しになると、何も証明されないままコードがマージされてしまいます。VAONではメインブランチを保護しており、レビューを経ないとマージできません。
AIはテストを速く書けるので、「テストは後で」という理由はもうありません。問題は、そのテストが確かめるべきことを確かめているかどうかに移ります。すべて緑のテスト結果も、要件に結びついていなければ、ほとんど意味を持ちません。
テスト付きのプルリクエストは、VAONのClaude Codeを使った開発フローの6番目と7番目のステップにあたります。このフローは現在、多くの案件で適用している基準ですが、すべての案件ではまだありません。
2. 実装計画の完了条件は、どうテストケースになるのか
実装計画の完了条件は、一つにつき少なくとも一つのテストケースになります。エンジニアはコードを読む前に、完了条件からテストケースを書き出します。完了条件は、実装計画のレビュー（仕様との照合）の段階で、確かめられる文に直してあります。
次の表は説明のための例であり、特定のお客様の案件から取ったものではありません。
| 完了条件（例） | 単体テスト | E2Eテスト |
|---|---|---|
| 承認基準額以上の注文は「管理者承認待ち」になる | 状態を決める関数を、基準額未満・ちょうど・超過の3通りで確認 | 担当者が大口注文を登録し、管理者の承認待ち一覧に表示される |
| 担当者は他拠点の注文を閲覧できない | すべての検索条件に拠点での絞り込みが入っている | 拠点Aの担当者でログインし、拠点Bの注文URLを直接開くと拒否される |
| 「保存」を2回押しても注文は1件だけ | 同じリクエストIDの再送は1回だけ記録される | 「保存」を続けて2回押し、一覧に1件だけ表示される |
単体テストは関数ごとのルールを確かめ、速く動くため、「基準額ちょうど」のような境界値に向いています。E2Eテスト（実際の利用者と同じ流れで画面を通しで確認するテスト）は部品のつながりを確かめますが、遅く、結果が不安定になりやすいテストです。VAONでは主要な流れと権限の確認に絞って使っています。
Anthropic社のClaude Codeでテストを扱う手順でも、テストを依頼するときは確かめたい振る舞いを具体的に伝えるよう勧めています。完了条件が、その「具体的な振る舞い」にあたります。
3. AIが書いたテストを、エンジニアはどんな問いで読むのか
VAONのエンジニアは、AIが書いたテストを4つの問いで読みます。AIが書くテストは、要件よりも、直前に生成したコードに合わせた形になりやすいためです。
| 兆候 | よくある形 | エンジニアの問い |
|---|---|---|
| ルールではなく実装を確かめている | 期待値をコードと同じ計算式で出している。内部関数の呼び出し回数を数えている | 期待値の数字は、仕様から来たのか、コードから来たのか |
| 必ず通る | 比較がない、自明なことを比較している、例外を捕まえて無視している | わざとコードを壊したら、このテストは落ちるか |
| モックが実際の動きを隠している | テストが期待する値をそのまま返すモック、確かめたい部分そのものをモックにしている | モックに置き換えた部分こそ、確かめるべき部分ではないか |
| 失敗時のケースがない | 成功する流れだけで、空のデータ、重複、権限なしのケースがない | 操作が失敗したとき仕様は何と言っているか、どのテストがそれを確かめるか |
最も気づきにくいのは1つ目です。コードと同じ計算式で期待値を出すテストは、計算式が誤っていても通ります。エンジニアは期待値を仕様から手で書きます。
テストが落ちたときは、コードが誤っているのか、テストが誤っているのかを、仕様を読んだエンジニアが判断します。テストが通るまでAIに書き換えさせることはしません。わざとコードを壊してテストを確かめる方法は、AIが書いたコードのレビュー手順でご説明しています。
4. テスト付きのプルリクエストは、お客様に何を残すのか
テスト付きのプルリクエストは、あとから確認できる根拠を残します。どの完了条件をどのテストで確かめたか、どのコマンドを実行し、結果がどうだったかです。プルリクエストの説明欄には、完了条件と対応するテストを並べ、まだテストがない条件があれば、その理由も書きます。
Claude Codeのベストプラクティスでも、実行したコマンドとその出力という「根拠」をClaudeに求めるよう勧めています。ドキュメントによれば、「すべてのテストが通った」という一言だけでは、ほとんど何もわかりません。
VAONのエンジニアは、Claude CodeとGitHub Copilotを日常的に使っています。テストの作成やコードの読み直しはAIが行い、リリース前には人が確認します。すべての案件で、プルリクエストごとにシークレットスキャン、依存パッケージのスキャン、静的解析を自動で実行しています。マージ後は、お客様にお渡しする前に、専用の環境でテストします。レビューとテストの記録はすべての案件で保存しており、お客様もご覧いただけます。「AIが書いたコードは誰が確認するのか」は、2026年にお客様からいただいた質問で特に多かったものの一つです。承認者の名前が残るテスト付きのプルリクエストは、その答えの一部です。
5. AIが書いたテストでは代わりにならないこと
AIが書いたテストは仕様に書かれたことしか確かめられないため、代わりにならないものがあります。
- お客様の受入テスト。 仕様から漏れたことは、テストからも漏れます。利用者視点のチェックリストでの確認は引き続き必要です。
- 明文化されていない業務ルール。 AIは知らないルールのテストを書けません。
- レビュアーの判断。 カバレッジの数字が高くても、中身が必ず通るテストばかりということはあり得ます。VAONは一律のカバレッジ率をお約束していません。
ほかにも限界があります。E2Eテストは不安定になりやすく、不安定なテストは次第に無視されるため、数を絞って安定させます。コードをAIツールに渡す許可をいただいていない案件では、エンジニアが自分でテストを書くため、時間がかかります。QAチームの側からの検証の流れは、QAにおけるAI活用の進め方にまとめています。
6. よくあるご質問
テストのカバレッジは何パーセントあれば十分ですか。 VAONは一律のカバレッジ率をお約束していません。カバレッジからわかるのは、テスト中にどの行が実行されたかであり、テストが正しいルールを確かめているかではありません。より役に立つのは、計画の完了条件ごとに対応するテストがあるか、ない場合はなぜか、という問いです。
プログラミングがわからなくても、テストを確認できますか。 テストのコードを読む必要はありません。プルリクエストの説明欄で、どの完了条件をどのテストで確かめたか、直近の実行結果がどうだったかをご覧ください。誰が注文を承認できるかなど、貴社にとって大切なルールを一つ選び、どのテストで確かめているかを開発チームに尋ねていただくのも有効です。
AIがコードもテストも書くと、自分で自分を採点することになりませんか。 その危険はあります。VAONでは3つの点で対処しています。テストケースはコードではなく計画の完了条件から作ります。期待値はエンジニアが仕様から書きます。そのうえで別のエンジニアがプルリクエストをレビューし、チームリーダーがマージを判断します。メインブランチはレビューを経ていないコードを受け付けません。
E2Eテストがあれば、受入テストは不要ですか。 受入テストは必要です。E2Eテストは、開発チームが仕様から書いたシナリオに沿って動きます。受入テストは、実際に業務を行うお客様が、日々の仕事の流れで確かめる工程で、見つかる不具合の種類が違います。VAONでは、利用者視点のチェックリストで、項目ごとに結果の画面キャプチャを残していただいています。
コードと一緒にテストを書くと、開発費は上がりますか。 繰り返しの多いテストはAIで速く書けるため、その部分の工数は下がります。一方で、テストを読み、直す作業にはエンジニアが必要で、VAONはこの作業を削りません。そのため、一律の削減率はお約束していません。お見積りは確定した要件定義書の範囲にもとづいて作成し、テストもその範囲に含まれます。
今日からできることが一つあります。貴社の案件で最近のプルリクエストを一つ開き、仕様の完了条件を一つ選んで、開発チームに「この条件はどのテストで確かめていますか。コードが誤っていたら、そのテストは落ちますか」と尋ねてみてください。
テスト付きのプルリクエストが貴社の案件でどう運用されるか、無料相談（60分）でご説明します。CEOが同席します。資料のご準備は不要で、ご契約を前提としたものではありません。
参考資料
- Claude Code Docs「Common workflows：Work with tests」：https://code.claude.com/docs/en/common-workflows（2026年10月29日確認）
- Claude Code Docs「Best practices：Give Claude a check to run」：https://code.claude.com/docs/en/best-practices（2026年10月29日確認）
