APIテストの進め方｜画面テストとの違い・確認する6観点・自動化の始め方

画面のテストは通っているのに、本番で連携が壊れる。
そうした不具合は、API の境界で起きていることがあります。

画面からは、限られた入力しか送れません。
一方、API には想定外の値や順序で要求が届きます。

API テストは、画面を通さずにサーバー側の振る舞いを直接確かめるテストです。
不具合の原因を特定しやすく、実行も速くなります。

この記事では、確認する観点と進め方を整理します。
自動化の始め方と、つまずきやすい点まで解説します。

APIテストとは｜画面を介さずに応答を検証する

API テストは、要求を直接送り、応答が仕様どおりかを確かめます。
確認するのは、状態コード、本文、ヘッダー、応答時間です。

対象は、Web API だけではありません。
社内システム間の連携や、外部サービスとの接続も含みます。

テストレベルで言えば、多くは結合テストに位置づきます。
単体テストと、画面を通す E2E テストの中間です。

比較軸	単体テスト	APIテスト	E2Eテスト
対象	関数・クラス	エンドポイント	画面を含む一連の流れ
実行速度	速い	比較的速い	遅い
原因の特定	容易	比較的容易	難しい
利用者視点の再現	低い	中程度	高い
壊れやすさ	低い	低い	高い（画面変更に弱い）

E2E テストの基礎は、E2Eテストとは？基礎知識から実装まで完全解説で解説しています。

なぜ画面テストだけでは足りないのか

画面には、入力の制限があります。
文字数制限や選択肢によって、不正な値は送信されません。

しかし実際には、他システムやツールからも要求が届きます。
画面の制限を通らない入力に、サーバーが耐えられるかは別問題です。

画面のバリデーションは、サーバー側の検証を省く理由になりません。
両方を確かめる必要があります。

APIテストで確認する6つの観点

観点を決めずに始めると、正常系だけで終わります。
次の6つを軸にすると、抜けを減らせます。

1．正常系の応答内容

想定どおりの要求に、正しい応答を返すかを見ます。
状態コードだけでなく、項目名、型、件数まで確認します。

2．入力値の検証

必須項目の欠落、型違い、桁あふれを送ります。
境界値と同値分割で、送る値を設計します。

エラー時に何を返すかも仕様です。
状態コードとエラーコードの対応を確認します。

3．認証と認可

トークンなしの要求が拒否されるかを見ます。
期限切れのトークンや、改ざんしたトークンも試します。

権限のない利用者が、他人のデータを取得できないかも重要です。
ここは不具合が本番障害と情報漏えいに直結します。

4．データの整合性と冪等性

登録や更新では、データベースの状態まで確認します。
応答が成功でも、保存されていない場合があるためです。

同じ要求を2回送ったときの挙動も確かめます。
通信の再送で二重登録が起きないかを見ます。

5．異常時の振る舞い

連携先が応答しない、遅い、エラーを返す状況を作ります。
タイムアウトの値と、再試行の回数が仕様どおりかを見ます。

6．性能と上限

応答時間の目標値と、同時要求数の上限を確認します。
件数の多い一覧取得は、ページ分割の挙動も見ます。

負荷の観点は、負荷テストとは？目的・種類・やり方を全体像で解説で詳しく扱っています。

APIテストの進め方5ステップ

手順を決めておくと、担当が変わっても品質がぶれません。
次の5段階で進めます。

ステップ	やること	成果物
1．仕様の確認	エンドポイント、要求・応答の定義を集める	API 仕様書（OpenAPI 定義など）
2．対象の選定	影響と利用頻度でテスト対象を絞る	対象一覧と優先度
3．ケース設計	6観点にもとづき、正常系と異常系を作る	テストケース
4．実行	ツールで要求を送り、応答を検証する	実行結果と証跡
5．自動化	回帰対象を CI に組み込む	自動テストと実行ログ

仕様書がない場合は、通信の記録から作ります。
その際は、現状の挙動が正しいとは限らない点に注意します。

資料が不足している状況での進め方は、資料なしのテスト代行は可能｜依頼前の準備と進め方にまとめています。

テストケースの具体例

会員登録の API を例に、ケースの粒度を示します。
1ケース1確認を基本にすると、失敗時の原因が分かります。

観点	入力	期待する結果
正常系	すべての必須項目が正しい	201 を返し、登録されている
必須欠落	メールアドレスなし	400 を返し、対象項目名を含む
型違い	年齢に文字列	400 を返し、登録されない
桁あふれ	名前に上限＋1文字	400 を返す
重複	登録済みのメールアドレス	409 など仕様どおりの応答
認証	トークンなし	401 を返す
認可	他人の ID を指定	403 を返し、情報を返さない
再送	同一要求を2回送信	二重登録されない

期待結果は「エラーになる」では不十分です。
状態コードと、返す情報の範囲まで書きます。

エラー応答に、内部の詳細を含めていないかも確認しましょう。
スタックトレースやSQL文の露出は、攻撃の手がかりになります。

自動化とCI連携の始め方

API テストは、自動化との相性が良い領域です。
画面に依存しないため、変更に強く実行も速いためです。

ツールの種類	代表例	向いている場面
GUI 型	Postman	探索的な確認、仕様の理解
コマンド型	curl、Newman	CI での実行、簡易な確認
コード型	REST Assured、supertest、pytest + requests	複雑な検証、既存テストとの統合

最初から全件を自動化する必要はありません。
回帰で毎回実行する範囲から着手します。

• 主要導線の正常系を自動化する
• 過去に不具合が出たケースを追加する
• プルリクエストごとに実行する
• 失敗時に通知し、原因の切り分け手順を決めておく

自動化の進め方は、Webアプリのテスト自動化入門｜ツール選定とE2E導入手順もあわせて参考にしてください。

つまずきやすい3つの落とし穴

API テストは、始めやすい反面で維持が難しくなります。
次の3点は、早い段階で決めておきましょう。

テストデータが実行ごとに変わる

登録系のテストは、実行するたびにデータが増えます。
2回目から重複エラーになり、失敗が常態化します。

実行前にデータを初期化するか、一意の値を生成します。
後片づけまでを、テストの一部として設計します。

外部サービスに依存している

決済や外部認証は、毎回本物へ接続できません。
模擬サーバーに置き換える範囲を決めます。

ただし、すべてを模擬にすると連携不具合を見逃します。
結合時に、一度は本物へつなぐ計画を残します。

仕様変更が共有されない

項目の追加や既定値の変更は、告知なく入ることがあります。
API 仕様書を版管理し、変更を通知する経路を決めます。

まとめ｜6観点で設計し、回帰から自動化する

API テストは、画面テストの前段で不具合を減らします。
原因の特定が速く、費用対効果の高い工程です。

• 正常系・入力検証・認証認可・整合性・異常時・性能の6観点で設計する
• 期待結果は状態コードと本文まで書く
• 認可の確認は、情報漏えいの予防として優先する
• テストデータの初期化と後片づけを設計に含める
• 回帰で毎回使う範囲から自動化する

まずは主要な1エンドポイントで、認可のケースを1本作ってみてください。
他人のデータが取得できないことを確かめるだけでも、リスクの把握が進みます。

次に読むならこの記事

• スモークテストとは？目的・サニティテストとの違い・項目の選び方を解説
• サニティチェックとスモークテストの違い｜実施タイミングと項目例

テストの手戻りを減らしたい方へ

テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

テスト仕様書テンプレートを無料DL テスト代行について相談する