「人の目で確認すれば大丈夫」という幻想

先月、僕のチームで起きた出来事です。

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テストのやり方も自然と変わっていきました。

もしあなたも「手動テストの限界」を感じているなら、一度立ち止まって考えてみてください。

問題は個人のスキルじゃなくて、時代構造そのものが変わった結果かもしれません。