{ freetool24 }
Developer Tools

APIテストガイド：基礎から自動化ワークフローまで

REST APIを効果的にテストする方法を学ぶ — HTTPクライアントを使った手動テストから、自動テストスイート、ステータスコード、認証戦略まで。

8分で読めます

開発者が画面でAPIドキュメントを確認している

APIはソフトウェアシステム間の契約です。APIが壊れれば、それに依存するすべてが壊れます。それにもかかわらず、APIテストはしばしば後回しにされがちです — デプロイ直前にブラウザのタブで手動確認する程度のものとして扱われることも少なくありません。適切なAPIテスト戦略は、バグを早期に発見し、期待される動作をドキュメント化し、自信を持ってリリースできる環境を整えてくれます。

APIテストとは何か？

APIテストはHTTPリクエストを送信し、レスポンスに関して何かをアサートします：

  • ステータスコード — 200 OK が返ってきたか、それとも 404 Not Found か？
  • レスポンスボディ — データ構造は正しいか？値は正しいか？
  • ヘッダー — Content-Type は正しく設定されているか？認証ヘッダーは存在するか？
  • レスポンスタイム — エンドポイントは許容範囲内に応答しているか？
  • エラーハンドリング — 不正な入力が来たときはどうなるか？意味のあるエラーが返ってくるか？

必ず知っておくべきHTTPステータスコード

コード 意味 発生するケース
200 OK GET、PUT、PATCHの成功時
201 Created リソースを作成するPOSTの成功時
204 No Content DELETEやボディを返さないアクションの成功時
400 Bad Request 不正な入力、不正なJSON、必須フィールドの欠如
401 Unauthorized 認証トークンがないまたは無効
403 Forbidden 認証済みだが権限がない
404 Not Found リソースが存在しない
409 Conflict リソースの重複、バージョン競合
422 Unprocessable Entity 正しいJSON上のバリデーションエラー
429 Too Many Requests レート制限を超過
500 Internal Server Error サーバー側のバグ
503 Service Unavailable サーバーのダウンまたは過負荷

401 は「あなたは誰ですか？」を意味し、403 は「あなたが誰かはわかっていますが、それはできません」を意味します。

API Request Builderを使った手動テスト

自動化する前に、エンドポイントを手動で理解しておきましょう。API Request Builder では以下のことができます：

  • HTTPメソッド（GET、POST、PUT、PATCH、DELETE）の設定
  • ヘッダーの追加（Authorization、Content-Type、カスタムヘッダー）
  • URLエンコードを手動で行わずにクエリパラメータを構築
  • シンタックスハイライト付きのJSONリクエストボディの記述
  • ヘッダーやタイミングを含むレスポンス全体の確認

これは、新しいAPIの調査、特定エンドポイントのデバッグ、または修正の素早い確認に最適です。

REST APIのテスト：完全なCRUDサイクル

仮の /users APIに対して、完全なテストスイートは以下をカバーします：

作成 (POST)

POST /users
Content-Type: application/json

{
  "name": "Alice Chen",
  "email": "alice@example.com",
  "role": "editor"
}

アサート内容：

  • ステータス 201 Created
  • レスポンスボディに生成された id を持つ作成済みユーザーが含まれている
  • Location ヘッダーが新しいリソース（例：/users/42）を指している

読み取り (GET)

GET /users/42
Authorization: Bearer <token>

アサート内容：

  • ステータス 200 OK
  • ボディが作成済みユーザーと一致している
  • id が 42 である

更新 (PUT / PATCH)

PATCH /users/42
Content-Type: application/json

{ "role": "admin" }

アサート内容：

  • ステータス 200 OK
  • レスポンス内の role が "admin" になっている
  • 他のフィールドが変更されていない

削除 (DELETE)

DELETE /users/42
Authorization: Bearer <token>

アサート内容：

  • ステータス 204 No Content
  • その後の GET /users/42 が 404 を返す

ネガティブテスト：多くの人がスキップするテスト

ポジティブテストは正常系を検証します。ネガティブテストは、APIが不正な入力を適切に処理できるかを検証します：

  • 必須フィールドの欠如 → 明確なエラーメッセージ付きの 400
  • 不正なデータ型（"age": "twenty"）→ 400
  • 存在しないリソース（GET /users/99999）→ 404
  • 期限切れトークン → 401
  • 他のユーザーのデータへのアクセス → 403
  • 10 MBのペイロード送信 → 413 Payload Too Large
  • レート制限を超過 → Retry-After ヘッダー付きの 429

よく設計されたAPIは、予測可能かつ情報豊かに失敗します。

認証テストのパターン

Bearerトークン（JWT）

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

テストシナリオ：

  • 有効なトークン → 正しいレスポンス
  • 期限切れトークン → "Token expired" メッセージ付きの 401
  • 改ざんされたトークン（1文字変更） → 401
  • ヘッダーの欠如 → 401
  • 別環境向けのトークン → 401

手動テスト中にトークンを検査して有効期限を確認するには、JWT Decoder を使用してください。

APIキー

X-API-Key: sk_live_abc123

テスト内容：間違ったキー、キーの欠如、権限が不十分なキー。

OAuth 2.0フロー

OAuth は複雑さが増します — トークン交換エンドポイントをリソースエンドポイントとは別にテストしてください。

レスポンスボディのバリデーション

ステータスコードだけ確認するのではなく、レスポンスの構造も検証しましょう：

// Jest + supertest を使用
test("GET /users/:id returns the correct user", async () => {
  const response = await request(app).get("/users/42").set("Authorization", `Bearer ${token}`);

  expect(response.status).toBe(200);
  expect(response.headers["content-type"]).toMatch(/json/);
  expect(response.body).toMatchObject({
    id: 42,
    name: expect.any(String),
    email: expect.stringMatching(/^[^\s@]+@[^\s@]+\.[^\s@]+$/),
    role: expect.oneOf(["admin", "editor", "viewer"]),
  });
});

より大きなレスポンススキーマには、JSON Schema Validator を使ったJSON Schemaバリデーションを活用してください。期待する形式を一度定義すれば、すべてのエンドポイントに対してテストできます。

コントラクトテスト

マイクロサービスにおいて、コントラクトテストはコンシューマーとプロバイダーがAPIの形式について合意していることを保証します。コンシューマーが必要なものを定義し、プロバイダーがそれを満たしていることを検証します。Pactなどのツールがこれを自動化します。

これは、異なるチームがそれぞれのサービスを担当している場合に特に有効です — フィールドの名前変更や削除が行われた瞬間に、インテグレーション前にコントラクトテストが失敗します。

パフォーマンスと負荷テスト

機能テストはAPIが動くかどうかを教えてくれます。パフォーマンステストは負荷がかかった状態でどれだけうまく動くかを教えてくれます：

  • ベースライン — シングルユーザー時のp50/p95/p99レスポンスタイムはどれくらいか？
  • 負荷テスト — 予想されるピーク時トラフィックでのパフォーマンスはどうか？
  • ストレステスト — どのポイントで障害が発生し始めるか？
  • スパイクテスト — 突然トラフィックが10倍になった場合はどうなるか？

一般的な目標値：予想ピーク負荷時のp95が 200ms 未満。

APIテストチェックリスト

  • 各リソースのすべてのCRUD操作をテストする
  • ネガティブケースをテストする：不正な入力、認証なし、リソースが見つからない
  • レスポンスボディをスキーマに対して検証する（ステータスコードだけでなく）
  • 認証のエッジケースをテストする：期限切れ、欠如、改ざんされたトークン
  • エラーレスポンスに有用なメッセージが含まれていることを確認する
  • ページネーション、フィルタリング、ソートが正しく機能することを確認する
  • レート制限の挙動をテストする
  • エラーレスポンスに機密データが漏洩していないことを確認する
  • 予想負荷時のレスポンスタイムを確認する

優れたAPIテストは、リファクタリングのための安全網であり、持てる最高のドキュメントでもあります — 各エンドポイントが何をするのか、何を期待しているのかを正確に示してくれます。

すべての記事に戻るツールを閲覧