AIを使ったプログラミングは、驚くほど速くなりました。
Claude CodeやCodex、CursorのようなCoding Agentへ「この機能を追加して」「このエラーを直して」「このページを実装して」と依頼すると、複数のファイルを読み解き、コードを書き、必要ならコマンドを実行しながら実装を進めてくれます。以前なら数時間から数日かかっていた実装が、わずか数分で終わることも珍しくありません。
すると、自然と次のような意見が出てきます。「人間はもうコードを書けなくてもいいのではないか？」
たしかに、エディタに向かって一文字ずつ構文をタイピングする作業は激減していくでしょう。しかし、実際にAIエージェントと一緒にプロダクトを作り続けていると、まったく逆の現実に直面します。
「実装コストがゼロに近づくほど、そのコードが本当に正しいかを検証し、壊れた原因を突き止める仕事の比重が跳ね上がる」ということです。
AIがコードを書くことと、そのコードが意図どおりに正しく動くことは、決して同じではありません。
AIは「動くコード」を速く作れるが、「正しいこと」と同じではない
Coding Agentが得意なのは、既存のコードベースを読み、似た実装パターンを探し、複数ファイルを一括で変更することです。これは極めて強力な能力です。
しかし、Agentは次のような点まで常に完璧に把握しているわけではありません。
- ボタンを押したとき、データベースの状態が本当に期待どおり更新されているか
- 新機能を追加したことで、別の画面の既存処理を壊していないか
- エッジケースや想定外のユーザー入力が行われたとき、安全にエラー処理できるか
- 権限のないユーザーが不正にデータへアクセスできてしまわないか
コードが生成され、構文エラーが出ず、画面が一見表示されたとしても、それだけで「正しく実装された」とは言えません。
かつては「コードを書く速度」が開発の大きなボトルネックのひとつでした。しかしCoding Agentによってコード生成コストが下がった結果、開発では「人間が確認しなければならない変更量の増大（検証のボトルネック）」の比重が大きくなっています。
テストとは「期待値の定義」、デバッグとは「問題の縮小」
テストやデバッグと聞くと、難解なテストコードを大量に書く高度な専門職を想像するかもしれません。しかし、その本質は非常にシンプルです。
テストの本質は「期待値」を決めること
テストとは、「こういう入力を与えたら、こうなるはずだ」という期待値と、実際の結果を突き合わせる作業です。
例えばログイン画面なら、
- 正しいメールアドレスとパスワードを入力したら、マイページへ遷移する（正常系）
- パスワードが間違っていたら、「認証に失敗しました」と警告が出る（異常系）
- 空欄のまま送信ボタンを押しても、システムがクラッシュせず入力エラーが表示される（境界値）
人間側が「何が正しい状態なのか」という合格基準をあらかじめ決めているからこそ、テストが成立します。AIがテスト設計を支援できるようになっても、最終的な期待値を定義する判断は人間側に残ります。
デバッグの本質は「原因の範囲を狭める」こと
一方デバッグとは、期待した結果にならなかったときに「原因の所在を絞り込んでいく作業」です。
画面が真っ白になった、ボタンを押しても反応しない、計算結果がずれる。そのとき、
- どのブラウザ・どの端末で起きているのか
- どんな入力値を与えたときに毎回再現するのか
- 直前のどのコミット（変更）から発生し始めたのか
- ログにはどんなエラーが出ているのか
- フロントエンド、API、データベースのどの層が関係しているのか
をひとつずつ切り分けていきます。
Coding Agentへ「なんか動きません、直して」と原因が曖昧なまま依頼すると、Agentが不要な変更範囲まで広げてしまう可能性があります。しかし、「この条件で実行すると、期待値Aに対して結果Bになる。関連するのはこの2ファイルのエラーログ」と再現条件を絞って渡せば、Agentは修正対象をより正確に絞り込みやすくなります。
つまりデバッグ力とは、人間が自力でコードを直すためだけの技術ではなく、「AIへ精度の高い修正指示を渡すための必須スキル」なのです。
Gitとテストは役割が違う──セットで効く検証体系
AIコーディングではGitも不可欠ですが、Gitとテストは役割が異なります。
- Gitは、何が変更されたかを記録し、壊れたら安全に元に戻す（変更管理の安全弁）
- テストは、その変更によって意図した動作になっているか、既存機能を壊していないかを確認する（正しさの判定）
- デバッグは、テストが落ちたときに原因の場所を小さく狭める（原因の特定）
例えばAgentが20個のファイルを一括で書き換えたとします。Gitがあれば「どのファイルの何行目が変わったか（Diff）」は一目瞭然です。しかし、「その差分によってアプリが壊れていないか」まではGitは教えてくれません。
そこでテストを実行して動作を検証し、もし不具合があればGit差分とログを突き合わせながらデバッグする。この「Git × テスト × デバッグ」の三位一体が整って初めて、AIコーディングを安全に実用化できます。
※ Gitの基礎や差分の考え方については、「AI時代にGit・GitHubは必要？」でも整理しています。
AIコーディングで最低限確認したい5つの項目
すべての大規模な自動テストを最初から組む必要はありません。ただし、Coding Agentを使って動くものを作るなら、最低限以下の5項目は確認する習慣をつけましょう。
| 確認項目 | 何を確認するか | 見落とした場合のリスク |
|---|---|---|
| 1. 正常系 | 正しく操作したとき、期待どおりの結果や表示になるか | 基本機能がそもそも動いていない |
| 2. 異常系・境界値 | 空欄入力、極端に大きな数値、不正な形式でエラーハンドリングできるか | 画面がクラッシュする、データが不正保存される |
| 3. 既存機能（デグレード） | 新機能を追加した影響で、以前動いていた他の画面やボタンが壊れていないか | 知らぬ間に他の主要機能が動作不能になる |
| 4. 変更差分（Diff） | Agentが指示していないファイルや不要なコメントを勝手にいじっていないか | 余計な依存関係の混入、セキュリティ設定の破壊 |
| 5. エラーとログ | ブラウザのコンソールやサーバーログに警告や例外が吐き出されていないか | 潜在的なバグが裏で蓄積し、本番で障害を起こす |
🔄 AIコーディングの標準検証サイクル
Agentへ「直して」と指示する代わりに、「この条件を再現するテストを書き、それが落ちることを確認した上でコードを直し、既存テストを含めてすべて通して」と依頼できるようになると、AIコーディングの修正精度を高めやすくなります。人間がコードを書く代わりに、「成功条件を設計してAIに解かせる」というアプローチです。
AIによるコードレビューの活用と、人間に残る「最後の保証」
現在は、AI自身にコードレビューをさせる仕組み（GitHub Copilot code reviewなど）も実用化されています。Pull Request上の差分をAIが解析し、セキュリティ上の弱点や構文の改善案を提案してくれる非常に便利な機能です。
しかし、GitHub公式のガイダンス（Review AI-generated code / About GitHub Copilot code review）でも明確に説明されている通り、「AIコードレビューがすべての問題を発見できる保証はなく、人間による検証で補完すること」が前提となっています。
GitHub公式では、AI生成コードをレビューする際の原則として以下を推奨しています。
- 自動テストと静的解析の先行実行：人間やAIが目で読む前に、まず自動テスト・リンター・型チェックを実行して基本動作を機械的に保証する
- 設計意図との整合性確認：プロジェクトの本来の要件や設計方針、命名規則に合致しているかを人間が判断する
- 依存関係とセキュリティの監査：不要な外部ライブラリが勝手に追加されていないか、脆弱性がないかをチェックする
AIがコードを書き、AIがテストを書き、AIがレビューする。どれほど自動化が進んでも、「そもそも何を作るべきか」「何を安全基準とするか」を決める責任だけは、常に人間の側に残ります。
テスト・デバッグはどこまで学べばいい？ 3つの学習段階
CORE SPECでは、テスト・デバッグの学習範囲も以下の3段階（Level 1〜3）で整理することをおすすめします。
正常系・異常系の動作確認ができる。Git Diffを見て意図しない変更を検知できる。エラー時に「どの操作で起きるか」を特定してAIへ指示できる。
Unit Test（単体テスト）やIntegration Test（結合テスト）をAIに書かせ、CLIから実行できる。リンターや型チェックを導入し、回帰テストでデグレードを防げる。
GitHub Actions等で自動テストとデプロイを連携させる。E2Eテスト、セキュリティスキャン、本番ログ監視、障害時のロールバック運用まで設計・統括できる。
MCP（外部ツール接続）の安全性とも表裏一体
AIエージェントがMCP（Model Context Protocol）などを通じて外部システムやデータベースへ接続するようになると、検証の対象はコード単体にとどまらなくなります。
「Agentが意図しないツールを呼び出していないか」「想定外のデータを書き換えていないか」をログや監査証跡から検証する能力が不可欠になります。MCPが「AIに何を使わせるか」を広げる技術なら、テストとデバッグは「AIが行ったことは正しいか」を担保する技術です。この2つは、AI時代の開発において完全に対をなす重要テーマです。
まとめ：コードを書く価値が下がっても、正しさを判断する価値は下がらない
AIがコードを書く速度は、今後さらに加速していくでしょう。人間が構文を暗記し、1行ずつ実装する時間は確実に減っていきます。
しかし、
- 何を作りたいのか（要件の輪郭）
- どうなれば完成なのか（期待値の定義）
- 何を守らなければならないのか（品質とセキュリティ）
- 出力された結果は本当に信頼できるのか（検証と監査）
という判断の価値は、下がるどころかますます高まっています。
AIコーディング時代にテストやデバッグが不要になるのではありません。「コードを書くコストが下がったからこそ、正しさを確かめる仕事の価値が最大化されている」のです。人間の役割は、コードを書く作業者から、AIが作ったものを育て、検証し、完成させる監督者へと進化しています。
よくある質問
AIがテストコードも書けるなら、人間はテストを学ぶ必要がありますか？ +
はい、学ぶ必要があります。テストコード自体の実装はAIに依頼できますが、「そもそもこの機能は何を満たせば正しいのか」という期待値（仕様）を定義する判断は人間に残るからです。実装したAIとテストを書いたAIが同じ誤解をしていれば、間違った実装に対して合格するテストを書いてしまうリスクもあります。
プログラミング初心者でもテストは必要ですか？ +
必要です。ただし、最初から高度な自動テストフレームワークを使いこなす必要はありません。正常系（正しく入力したときに動くか）、異常系（空欄や不正値でクラッシュしないか）、既存機能（新機能を追加して以前の機能が壊れていないか）の3点を意識して手動確認し、エラー時に再現条件を小さく絞れるだけでも大きな安全性につながります。
Gitとテストは何が違いますか？ +
役割が完全に異なります。Gitは「何が変更されたかを記録し、安全に以前の状態へ戻す」ための変更管理の仕組みです。一方テストは「その変更によってシステムが期待どおりに動いているか、壊れていないか」を確認する正しさの検証です。Gitで差分を把握し、テストで正しさを確かめ、失敗したらデバッグするという組み合わせで機能します。
AI生成コードはどこまで確認すべきですか？ +
公開または本番運用するコードであれば、最低限「正常系・異常系の動作」「既存機能のデグレード有無」「Git差分（意図しないファイル変更がないか）」「エラーログの有無」の確認が必要です。GitHub公式のガイダンスでも、AI生成コードに対してはまず自動テストと静的解析を行い、その上で人間が意図やセキュリティをレビューすることが推奨されています。