DEV Community

Cover image for AIはAPIテストを代替できるか？AIエージェントの能力と限界
Akira
Akira

Posted on • Originally published at apidog.com

AIはAPIテストを代替できるか？AIエージェントの能力と限界

エージェントがテストを作成し、Cursorが見落としやすい3つのエッジケースを提案し、Copilotがリクエストボディを埋め、Claudeが一連のテストを実行してグリーンを報告する。ここで自然に浮かぶ疑問があります。エージェントがここまでできるなら、AIはAPIテストを完全に置き換えられるのでしょうか？

今すぐApidogを試す

答えは「いいえ」です。AIはAPIテストそのものを置き換えませんが、テストを作成する作業の多くを置き換えられます。 エージェントは、テストケースのドラフト、エッジケースの提案、リクエストボディの生成に向いています。一方で、毎回同じ条件でテストスイートを実行すること、結果でマージをブロックすること、契約が正しいかを判断することはできません。そこには決定論的なツールと人間のレビューが必要です。

この線引きが重要です。AIが担える領域と担えない領域を理解すれば、次の両極端を避けられます。

  • エージェントの判断をそのままマージゲートとして信頼する
  • エージェントがテスト作成を大きく効率化できるにもかかわらず、テストでは役に立たないと切り捨てる

AIエージェント時代にも、APIツールは必要です。ただし役割は変わります。AIはテストを作る側、決定論的なツールはテストを実行・検証する側です。

ハウツーガイドとの違い

具体的なセットアップ手順を探している場合は、AIエージェントをAPIテストに利用するガイドを参照してください。こちらでは、エージェントにエンドポイントや仕様を渡し、テストを生成する方法を解説しています。

この記事で扱うのは「どう実装するか」ではなく、どこまでAIに任せるべきかです。

エージェント支援のテストフローを構築するときは、次のように分けて考えてください。

  1. AIにテストの下書きを作らせる
  2. 人間が意図・契約・重要なアサーションをレビューする
  3. 決定論的なランナーでCIごとに同じテストを実行する
  4. 終了コードでマージを許可またはブロックする

AIが現在のAPIテストで得意なこと

AIエージェントは、テスト成果物を生成する「オーサリング作業」に強みがあります。

仕様やサンプルからテストケースをドラフトする

エンドポイント、OpenAPI定義、サンプルレスポンスを渡すと、エージェントは短時間で最初のテストスイートを作れます。

たとえば、次のような情報があれば十分です。

POST /users

{
  "email": "user@example.com",
  "name": "Taro"
}
Enter fullscreen mode Exit fullscreen mode

エージェントは、少なくとも以下のような確認項目を提案できます。

  • 201 Created が返ること
  • id が返却されること
  • email が入力値と一致すること
  • createdAt が存在すること
  • 必須項目が欠けた場合は 400 が返ること

空のエディタから始める代わりに、レビュー可能なドラフトから始められる点が大きな利点です。

見落としやすいエッジケースを提案する

エージェントには、次のように依頼できます。

この POST /users エンドポイントに対して、
失敗しやすい入力・認可・境界値・タイムゾーンに関する
エッジケースを列挙してください。
Enter fullscreen mode Exit fullscreen mode

優れたモデルは、次の候補を出せます。

  • 空配列や空文字列
  • 必須フィールドの null
  • 不正なメールアドレス
  • 期限切れ・欠落・形式不正のトークン
  • 同一リソースの重複作成
  • 最大文字数・最小文字数の境界値
  • 日付境界やタイムゾーン差異
  • レート制限時の 429
  • 一時障害時の 500 やタイムアウト

すべてのケースを自動で見つけるわけではありません。しかし、いつものハッピーパスと定番の異常系だけに偏ることを防ぐには有効です。

リクエストボディとフィクスチャを生成する

フィールド数が多いペイロードや、現実的なテストデータの作成もAIに向いています。

{
  "email": "taro.yamada@example.com",
  "name": "山田 太郎",
  "role": "member",
  "profile": {
    "department": "Engineering",
    "timezone": "Asia/Tokyo"
  }
}
Enter fullscreen mode Exit fullscreen mode

ただし、AIだけに任せると存在しないフィールドや不正な列挙値を作る可能性があります。これを避けるには、Model Context Protocol を通じて実際の仕様をエージェントに渡します。仕様を参照できれば、推測ではなく定義済みのフィールドに基づいてペイロードを作成できます。

最初のアサーションを記述する

「レスポンスが有効なユーザーであることを確認する」という要求を、具体的なアサーションに落とし込む作業もAIに任せられます。

expect(response.status).toBe(201);
expect(response.body.id).toBeDefined();
expect(response.body.email).toBe(request.body.email);
expect(response.body.createdAt).toBeDefined();
Enter fullscreen mode Exit fullscreen mode

重要なのは、これを完成品ではなくレビュー対象の下書きとして扱うことです。AIが生成したアサーションに対して、少なくとも次を確認してください。

  • 本当に重要なビジネスルールを検証しているか
  • 存在確認だけでなく、値や型を確認しているか
  • 実装詳細ではなく契約をテストしているか
  • テストデータが偶然通っているだけではないか

依然として決定論的なツールが必要なこと

AIが苦手なのは、同じ入力に対して常に同じ結果が求められる作業です。

すべてのコミットで同じスイートを実行する

マージゲートには、次の性質が必要です。

同じコミット、同じテスト、同じ環境であれば、同じ合否になること。

エージェントはテストを実行して要約できます。しかし、複数回実行すると、異なる説明、異なる判断、場合によっては異なる結論を返すことがあります。

探索や調査では問題にならなくても、CIのゲートには使えません。CIでは、保存済みのテストケースを固定された条件で実行するランナーが必要です。

CIを実際の終了コードでゲートする

CIが必要とするのは「問題なさそうです」というチャット上の要約ではありません。必要なのは、機械が判定できる終了コードです。

# 成功時は 0、失敗時は非 0 の終了コードを返すことが重要
api-test-runner run ./tests
Enter fullscreen mode Exit fullscreen mode

GitHub ActionsなどのCIは、コマンドの終了コードをもとにジョブを成功または失敗にします。

- name: Run API tests
  run: api-test-runner run ./tests
Enter fullscreen mode Exit fullscreen mode

ここでエージェントの自然言語による評価を挟むと、マージルールとしての信頼性が下がります。CIには、毎回同じコマンドを実行し、失敗時に確実に非ゼロ終了する仕組みが必要です。

契約とスキーマをアサートする

「このレスポンスは、すべてのコンシューマが依存するOpenAPI契約と一致しているか」は、モデルの意見ではなく固定定義に対する検証です。

たとえば、以下のような破壊的変更を確実に検出する必要があります。

  • 必須フィールドが消えた
  • フィールド型が string から number に変わった
  • 列挙値が変更された
  • レスポンスのネスト構造が変わった
  • ステータスコードが変わった

契約は OpenAPI Specification などで定義し、固定されたルールとして検証してください。フィールドの欠落があれば、毎回同じように失敗する必要があります。

失敗した呼び出しを正確に再現する

障害調査では、AIの要約だけでは足りません。必要なのはワイヤー上で実際に送受信された情報です。

  • HTTPメソッド
  • URLとクエリパラメータ
  • リクエストヘッダー
  • リクエストボディ
  • レスポンスステータス
  • レスポンスヘッダー
  • レスポンスボディ
  • 呼び出し順序

「有効なトークンを送ったはず」というエージェントの説明と、実際に期限切れトークンを送っていたクライアントは、ログを確認するまで区別できません。デバッグでは、要約ではなく再現可能なリクエストとレスポンスが必要です。

2026年の区分け：AIが得意なこと vs 決定論的なツールが必要なこと

テストタスク 今日のAIエージェント 理由
最初のテストスイートをドラフトする 得意 仕様からのオーサリングはパターン作業である
エッジケースを提案する 得意 幅広いパターンから候補を出せる
リクエストボディとフィクスチャを生成する 得意 高速で、仕様が接続されていれば精度も上がる
最初のアサーションを記述する できるがレビューが必要 良い出発点だが、最終判断ではない
すべてのコミットで同じ方法でスイートを実行する 決定論的なランナーが必要 モデル出力は実行ごとに変わり得る
合否に基づいてCIをゲートする 決定論的なランナーが必要 マージルールには実際の終了コードが必要
契約とスキーマの形状をアサートする 決定論的なツールが必要 固定仕様に対する固定チェックである
失敗した呼び出しを正確に再現する 検査可能なクライアントが必要 要約はワイヤートゥルースではない
契約が正しいと判断する 人間が必要 プロダクトと利用者への影響を判断する作業である

最初の4項目は、AIを積極的に活用できる領域です。残りの項目は、AIだけではマージゲートとして成立しない理由を示しています。

モデルがゲートになれない理由

モデルがゲートに向かないのは、性能が低いからではありません。動作原理が異なるためです。

LLMは出力をサンプリングします。温度、サンプリング設定、モデル内部の非決定論的な処理により、同じプロンプトでも実行ごとに異なるテキストが生成される可能性があります。

これはテストのアイデア出しや説明文の作成には有用です。しかし、マージをブロックする判定には不向きです。

良いゲートは退屈です。

  • グリーンなら、毎回同じ条件を満たしている
  • レッドなら、毎回同じ壊れた契約を指している
  • 実行する人やタイミングで結果が変わらない
  • 失敗理由をログから追跡できる

モデルが要約を言い換えたり、重要度の判断を変えたりする余地があるなら、それは探索支援には使えてもCIゲートには使えません。

したがって、役割は分離するべきです。

AIエージェント:
  テストをドラフトする
  ↓
人間:
  テスト意図と契約をレビューする
  ↓
決定論的ランナー:
  保存済みテストを実行する
  ↓
CI:
  終了コードでマージをゲートする
Enter fullscreen mode Exit fullscreen mode

この区分けを無視した場合の失敗パターンについては、なぜAIエージェントが本番環境で壊れるのかも参照してください。

Apidogの役割：検査し、検証する

Apidogは、AIエージェントの代わりに意思決定するツールではありません。API作業における決定論的な検証と、実行内容の検査を担うレイヤーです。

Apidogはエージェントフレームワークでも、エージェントランタイムでも、オープンソースでもありません。役割は主に次の2つです。

  1. エージェントが実際に送受信したAPI通信を検査する
  2. 保存済みテストをヘッドレスで実行し、CIで検証する

AI Agent Debugger：エージェントのAPI通信を検査する

2026年5月に出荷された Apidog AI Agent Debugger は検査インターフェースです。

次のような実行内容を可視化できます。

  • LLM呼び出し
  • MCPツール呼び出し
  • 複数ターンのやり取り
  • APIレイヤーで失敗した呼び出し
  • エージェントが送信したリクエストと受信したレスポンス

これはデバッガであり、エージェントのランタイムではありません。エージェントを構築・実行するのではなく、実行されたAPI通信を確認するために使います。

Apidog CLI：CIで決定論的にテストを実行する

Apidog CLIは、保存済みのテストケースをヘッドレスで実行するためのランナーです。

CIでは、次のような構成にします。

# 保存済みのAPIテストをヘッドレス実行する
apidog-cli run ./api-tests
Enter fullscreen mode Exit fullscreen mode

CI側では、このコマンドの終了コードを評価します。

name: API Tests

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  api-test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run API tests
        run: apidog-cli run ./api-tests
Enter fullscreen mode Exit fullscreen mode

契約が壊れた場合にCLIが非ゼロ終了コードを返せば、ビルドは失敗します。この仕組みが、AIがドラフトしたスイートを信頼できるマージゲートに変えます。

Apidog CLIはログインなしで実行できるため、サインイン前でもパイプラインへ接続できます。

MCPで実際の仕様をエージェントに渡す

AIに存在しないエンドポイントやフィールドを推測させないためには、実際のOpenAPI定義を接続します。

npx apidog-mcp-server
Enter fullscreen mode Exit fullscreen mode

これにより、OpenAPI定義をCursor、Copilot、Claude Codeなどから利用できます。エージェントは架空のAPIではなく、実際のエンドポイント、パラメータ、スキーマを参照してテストをドラフトできます。

Apidog MCP Serverは、試用時にアカウントを必要としません。

加えて、Apidogのスマートモックは、必要に応じて 429、500、タイムアウトを返せます。これにより、エージェントやクライアントコードが次のような回復パスを適切に処理できるかをテストできます。

429 Too Many Requests
500 Internal Server Error
Request Timeout
Enter fullscreen mode Exit fullscreen mode

Apidogをダウンロードして、実際のAPI仕様、モック、CIテストを接続してみてください。これらは無料ティアで利用できます。

役割分担は明確です。

エージェント: テストをドラフトする
Apidog AI Agent Debugger: エージェントが何を送受信したかを確認する
Apidog CLI: 保存済みテストを実行し、結果をCIで保証する
人間: 契約とプロダクト要件が正しいか判断する
Enter fullscreen mode Exit fullscreen mode

AIとスクリプトで十分な場合

すべてのケースで専用ツールが必要なわけではありません。次の条件であれば、エージェントと curl による確認でも十分です。

  • 使い捨てスクリプトをテストしており、1リクエストで必要な確認が完結する
  • 一人でプロトタイプを作っており、APIが2〜3エンドポイント程度である
  • 他チームや外部コンシューマが契約に依存していない
  • 出荷物が他人のコードや本番経路に入らない

たとえば、次のような確認です。

curl -i \
  -X POST "https://api.example.com/users" \
  -H "Content-Type: application/json" \
  -d '{"email":"user@example.com","name":"Taro"}'
Enter fullscreen mode Exit fullscreen mode

この段階では、AIが作ったチェックリストと手動確認で十分なこともあります。

ただし、次のいずれかに当てはまる時点で、決定論的な検証レイヤーを追加する価値があります。

  • CIで実行したい
  • 他の開発者へ配布する
  • 他チームがAPI契約に依存している
  • 本番障害がコストや利用者影響につながる
  • 回帰を継続的に防ぎたい
  • 失敗時に正確なリクエスト・レスポンスを追跡したい

よくある質問

AIはAPIテストを完全に置き換えられますか？

いいえ。エージェントはテストのドラフト、エッジケースの提案、リクエストボディの生成に優れています。しかし、すべてのコミットで同じスイートを同じ方法で実行すること、結果に基づいてマージをゲートすること、契約が正しいと判断することには、決定論的なツールと人間が必要です。

テストの作成はAIに大きく移行していますが、テストの検証は移行していません。

AIエージェントはAPIテストで何ができますか？

主に次の4つです。

  1. 仕様から最初のテストスイートをドラフトする
  2. 見落としやすいエッジケースを提案する
  3. 有効なリクエストボディとフィクスチャを生成する
  4. レビュー対象となる最初のアサーションを記述する

いずれもオーサリング作業であり、モデルが強い領域です。

なぜエージェントはCIゲートになれないのですか？

CIゲートは、同じ入力に対して毎回同じ結果を返す必要があるためです。LLMは出力をサンプリングするため、実行ごとに異なる結果を生成する可能性があります。

マージルールが読むべきなのは、次回に言い換えられるかもしれないチャットの要約ではありません。決定論的なランナーが返す実際の終了コードです。

これはAPIテストにおけるAIエージェントのハウツーと同じですか？

いいえ。ハウツーガイドは、エージェントからテストを生成する具体的な手順を扱います。

この記事は、AIがテスト作業をどこまで置き換えられるか、その境界線を扱っています。一方は方法、もう一方は役割分担です。

Apidog AI Agent Debuggerはエージェントを実行しますか？

いいえ。Apidog AI Agent Debuggerは、LLM呼び出し、MCPツール呼び出し、複数ターンのやり取りを検査し、APIレイヤーで何が起きたかをデバッグするためのインターフェースです。

エージェントを構築・運用するランタイムではありません。

CIでテストを実行するためにログインは必要ですか？

いいえ。Apidog CLIは、保存済みテストケースをアカウントなしでヘッドレス実行できます。実際の終了コードを返し、契約が壊れた場合はビルドを失敗させられます。

本当の境界線

「AIはAPIテストを置き換えられるか」という問いには、実際には2つの質問が含まれています。

  1. AIはテストを書けるか

    はい。ますます高い精度で書けます。

  2. AIはテストを毎回同じ方法で実行し、マージをゲートし、契約を保証できるか

    いいえ。そこには決定論的なツールと人間の判断が必要です。

AIがテストドラフトを作る能力を無視する必要はありません。同時に、AIの自然言語による判断をCIゲートとして扱うべきでもありません。

実装では、次の分担を採用してください。

  • エージェントにテストスイートのドラフト、エッジケースの提案、リクエストボディの生成を任せる
  • 人間がプロダクト要件とAPI契約をレビューする
  • 決定論的なツールで保存済みテストを実行する
  • CIでは終了コードに基づいてマージをゲートする
  • 失敗時はワイヤー上のリクエスト・レスポンスを確認する

まずは次のコマンドで、実際の仕様をエージェントへ接続できます。

npx apidog-mcp-server
Enter fullscreen mode Exit fullscreen mode

続いて、Apidog CLIで保存済みテストをCIに接続するか、Apidogを無料で試してください。

Top comments (0)