「人の目で確認すれば大丈夫」という幻想
先月、僕のチームで起きた出来事です。
ChatGPTでAPIコードを生成して、いつものように手動でテストしていました。「AIが作ったコードでも、最後は人がチェックすれば問題ない」そう思っていたんです。
ところが、ある日突然、手動テストが完全に破綻しました。
APIの変更スピードが速すぎて、テストが全然追いつかない。気づいたら、「確認したつもり」のAPIが本番で次々とエラーを起こすという最悪の事態に。
「なんで今まで大丈夫だったのに、急にダメになったんだろう？」
その答えが分かったとき、問題は僕のスキルじゃなくて、時代構造そのものが変わったことだと理解しました。
この記事では、僕が実際に体験した「手動APIテストの破綻」から学んだ10の教訓を共有します。
もしあなたも「まだ手動で大丈夫」と思っているなら、この話は他人事じゃないかもしれません。
僕が体験した破綻の瞬間
1. AIのコード生成速度に人間が追いつけない現実
これが一番ショックでした。
ChatGPTに「ユーザー管理APIを作って」と頼むと、5分でエンドポイント10個分のコードが出てくる。でも、それを手動でテストしようとすると、1日かかっても終わらない。
- エンドポイントが30分で5個増える
- リクエスト構造が1時間で3回変わる
- 影響範囲の確認だけで半日潰れる
「あれ？なんで僕だけこんなに遅いんだろう」って思ったけど、問題は僕のスキルじゃなくて、構造そのものだったんです。
2. AI生成コードの「罠」にハマった話
AIが作ったAPIって、見た目はめちゃくちゃ完成度が高いんですよ。
// ChatGPTが生成したAPI（一見完璧に見える）
app.post('/api/users', async (req, res) => {
const { name, email } = req.body;
const user = await User.create({ name, email });
res.json({ success: true, user });
});
「おお、動いた！完璧じゃん！」って思って、手動で正常系だけテストして終了。
でも後で分かったんですが、
- 空文字列の処理が抜けてる
- メールアドレスの重複チェックなし
- エラーレスポンスの形式がバラバラ
手動テストだと「動いたからOK」で終わっちゃうんですよね。境界値とか異常系とか、面倒だから後回しにしがち。
3. テストケースの更新地獄
これも辛かった。
AIでAPI仕様をガンガン変更していくと、テストケースの更新が全然追いつかない。
- 月曜日：仕様書更新
- 火曜日：実装変更
- 水曜日：「あれ？テストケースどうなってる？」
- 木曜日：「何をテストしてるか分からない」
結果として、古いテストケースで新しいAPIをテストするという意味不明な状況に。
4. 人によってテスト結果が変わる問題
チーム開発で一番困ったのがこれ。
- 僕：「このAPIは正常に動作します」
- 同僚A：「エラーが出ました」
- 同僚B：「レスポンスが遅いです」
同じAPIなのに、テストする人によって結果が違う。
手順書を作っても、
- 環境の違い
- 確認ポイントの違い
- データの作り方の違い
で結果が変わってしまう。これじゃあ品質保証になりません。
破綻の根本原因を分析してみた
5. テスト結果が「消える」問題
手動テストの結果って、どこに残ります？
- 僕のローカル環境のPostman
- Slackの「動きました！」メッセージ
- 手書きのメモ
全部一時的なんですよね。次の日には「あれ？昨日何をテストしたっけ？」状態。
AIで開発スピードが上がるほど、この「消える」問題が致命的になります。
6. CI/CDから完全に取り残される
これも痛かった。
チームではGitHub ActionsでCI/CDを回してるんですが、手動テストだけ完全に蚊帳の外。
- コードはプッシュで自動デプロイ
- でもAPIテストは手動
- 結果として「デプロイ後に問題発覚」
「テストは最後に時間があったらやる作業」になってしまいました。
7. 複数API連携のテストが現実的じゃない
AIが作るAPIって、単体じゃなくて複数のAPIが連携する前提のものが多いんです。
- ユーザー登録 → 認証 → プロフィール更新
- 商品検索 → カート追加 → 決済処理
これを手動で毎回テストするのは、現実的じゃない。
8. 「テスト設計」が属人化する悪循環
一番怖いのがこれ。
AIがコードを書く → 人がテスト設計を考える → 特定の人しか全体を把握していない
僕が休んだら、誰もAPIテストができない状況になってしまいました。
分断された開発フローの問題
9. 仕様・テスト・実装がバラバラ
これが破綻の最大の原因だったと思います。
- 仕様書：Notion
- テスト：Postman
- 実装：AI生成コード
全部別々の場所にあるから、整合性が取れない。
仕様が変わっても、テストケースの更新を忘れる。実装が変わっても、仕様書の更新を忘れる。
この分断を解消するために、最終的にAPI仕様とテストを同じ場所で管理できるツール（Apidogとか）に移行しました。
実際、Apidogを使い始めてから、
- 仕様変更 → テストケース自動更新
- テスト実行 → 結果が履歴として残る
- CI/CD連携 → 自動化テストが回る
という流れができて、「どこを、何を確認しているのか分からない」状況はかなり減りました。
10. 「確認できてるつもり」の恐怖
一番危険だったのは、安心感でした。
「人が見てるから大丈夫」「触って動いたから問題ない」
でも実際は、人が全部を見ること自体が不可能になってたんです。
手動テストは「安心材料」のつもりだったけど、実は「盲点」になってました。
手動テストを完全否定するわけじゃない
誤解してほしくないんですが、手動テスト自体が悪いわけじゃありません。
今でも、
- 新機能の初期検証
- UIとの連携確認
- ユーザビリティのチェック
では手動テストが重要です。
ただし、手動テストを「メイン」にし続ける構造が破綻するんです。
実際、僕も以前は仕様書・テスト・実行結果がそれぞれ別の場所に分かれた状態で運用していました。最初は手動でも回りますが、API変更が増えた途端に「確認しているつもり」だけが残る状態になります。
僕が見つけた解決策：一元化された前提
結局、以下を同じ前提で管理することが重要でした：
- API仕様
- テストケース
- モックデータ
- 実行結果
最近では、これらをAPI仕様を中心にまとめて管理するアプローチが取られることも増えています。
例えば、API定義とテストを同じ前提で扱えるツール（Apidogなど）を使うことで、AI生成コードとのズレを早期に検知しやすくなるケースもあります。
※あくまで一例であり、重要なのは「構造として破綻しない仕組み」を持つことです。
まとめ：変えるべきは「前提」そのもの
AI時代に見直すべきなのは、
- 手動か自動か
- どのツールを使うか
じゃありません。
「人が全部確認できる」という前提そのものです。
僕も最初は抵抗がありました。でも、その前提を手放したとき、APIテストのやり方も自然と変わっていきました。
もしあなたも「手動テストの限界」を感じているなら、一度立ち止まって考えてみてください。
問題は個人のスキルじゃなくて、時代構造そのものが変わった結果かもしれません。
Top comments (0)