なぜAPI監視は特別なのか#

ウェブサイトが「稼働中」でも、APIが壊れていることがあります。ユーザーには問題なく読み込まれるホームページが表示されますが、依存しているアプリ機能はまったく動作しません。

例:チェックアウトページは読み込まれます(サイトは稼働中 ✅)が、決済APIが失敗します(サイトは壊れている ❌)。顧客は購入を完了できません。売上が止まります。

API監視はこうした見えない障害を検出します。

API監視が必要な対象#

決済ゲートウェイ(Stripe、PayPal、Square)
認証エンドポイント(ログイン/ログアウト)
データAPI(商品リスト、ユーザーデータ)
Webhook(サードパーティからの受信データ)
検索エンドポイント
メディアアップロードAPI

APIにおけるHTTPステータスコード#

APIはウェブサイトとは異なる方法でHTTPステータスコードを使用します。

ウェブサイト:

200 OK:ページが読み込まれる
500 Server Error:サイトが壊れている

API:

200 OK:リクエスト成功
400 Bad Request:クライアントが誤ったデータを送信
401 Unauthorized:認証失敗
403 Forbidden:権限がない
404 Not Found:エンドポイントが存在しない
429 Too Many Requests:レート制限
500+ Server Error:バックエンドが壊れている

重要な違い:APIは200 OKを返しながら、JSONボディ内でエラーを返すことがあります。

例:

{
  "status": 200,
  "success": false,
  "error": "Payment processing failed"
}

HTTPは「OK」と言っていますが、API自体は失敗しています。基本的なアップタイム監視ではこれを見逃します。

API監視の設定方法#

ステップ1:重要なAPIエンドポイントを特定する#

ビジネスにとって重要なすべてのAPIエンドポイントをリストアップします。

/api/auth/login(これが失敗するとユーザーはログインできない)
/api/payments/create(これが失敗するとユーザーはチェックアウトできない)
/api/users/profile(これが失敗するとアプリがクラッシュする)
/webhooks/stripe(これが失敗すると決済が記録されない)

ステップ2:レスポンス検証を決定する#

各エンドポイントについて、何をもって「稼働中」とするかを決めます。

基本チェック(HTTPステータス):

エンドポイントが200または201を返す = OK

中級チェック(ステータス + レスポンスタイム):

エンドポイントが200を返し、かつ1秒未満で応答する

上級チェック(ステータス + ボディ内容):

エンドポイントが200を返し、かつレスポンスボディに期待されるデータが含まれる

ステップ3:監視ツールを設定する#

Nova Uptimeでの設定:

ドメインを追加:https://api.yourdomain.com
重要な各エンドポイントを個別のモニターとして追加:
- /api/auth/login
- /api/payments/create
- など
利用可能であればレスポンスボディ検証を設定する
アラートのしきい値を設定する(アラート前に2回連続で失敗)

上級編:レスポンスボディの検証

一部のエンドポイントは特定のレスポンス形式を要求します。

例:決済作成エンドポイント

期待されるレスポンス:

{
  "success": true,
  "payment_id": "pay_12345",
  "amount": 99.99
}

監視の設定:

レスポンスに"success": trueが含まれているか確認する
含まれていない場合、HTTPステータスが200であってもエンドポイントは「壊れている」と判定する

Nova UptimeのEmail Health Checkerはレスポンスボディを検証します。同じ原則がAPI監視にも当てはまります。

API監視における認証トークン#

ほとんどのAPIは認証を必要とします。それらを監視するには:

オプション1:テスト用APIキーを作成する

監視専用のテストAPIキーを生成する
すべての監視リクエストでこのキーを使用する
このキーは読み取り権限のみ(データの変更は不可)
監視ツールでこのキーを使用する

オプション2:公開エンドポイント

一部のAPIには認証不要のエンドポイント(ヘルスチェック、ステータス)があります
代わりにそれらを監視する
例:GET /api/health(公開、認証不要)

Webhookの監視#

Webhookは少し厄介です。Webhookは受信するもの(自分が送信するのではなく受け取るもの)だからです。

Webhookを受信するエンドポイントを監視する:

例:Stripeがhttps://yourdomain.com/webhooks/stripeにPOSTを送信する

監視方法:

テスト用Webhook送信元を作成する(手動でトリガー)
エンドポイントが受け入れて200を返すことを確認する
ログでWebhookが処理されたことを確認する

または合成監視を利用する:

Webhookエンドポイントへの合成POSTリクエストを設定する
テスト用ペイロードを含める
受信および処理されたことを確認する

レスポンスタイムの監視

APIは稼働しているか/停止しているかだけが問題ではありません。速度も重要です。

遅いAPI = 壊れたAPI(ユーザーから見れば)。

レスポンスタイムのしきい値を設定する:

認証エンドポイント:200ms未満
決済エンドポイント:500ms未満
検索エンドポイント:1000ms未満(より複雑)

エンドポイントが応答に5秒かかると、たとえ「動作」していても、ユーザーはタイムアウトを経験して離脱します。

レート制限への配慮

APIは悪用を防ぐためにレート制限を設けていることが多いです。

**問題:**監視は1分ごとにチェックを送信します。1,000のモニターがあると、1分あたり1,000リクエストになります。APIが1分100リクエストでレート制限している場合、監視はブロックされます。

解決策:

監視用の別のAPIキーを作成する(高いレート制限を設定)
またはチェック頻度を下げる(1分ごとではなく5分ごとにチェック)
またはレート制限のかからない内部の/healthエンドポイントを使用する

API監視でよくある間違い#

間違い1:破壊的な操作で本番環境を監視する#

これらは監視しないでください:

POST /api/users/delete    ← チェックのたびにユーザーを削除する
POST /api/billing/charge  ← チェックのたびにカードに課金する

代わりに読み取り専用の操作を監視します:

GET /api/users/{id}
GET /api/health

間違い2:認証情報をURLに含める#

これはやめましょう:

GET /api/endpoint?auth_token=SECRET

これはシークレットをログに残してしまいます。代わりにヘッダーを使用します:

Authorization: Bearer SECRET_TOKEN

間違い3:Webhookエンドポイントをテストしない#

Webhookは重要ですが、しばしば未テストのままです。Webhookプロセッサが完全に壊れていても、気づかない可能性があります。

対策:定期的にテスト用Webhookを送信し、処理されることを確認しましょう。

API依存先の監視#

APIは外部サービスに依存していることがあります:

データベース(ダウンするとAPIもダウンする)
メッセージキュー(Redis、RabbitMQ)
キャッシュ(Memcached)
外部API(Stripe、Twilio)

それぞれを個別に監視する:

データベースのヘルスチェックエンドポイント
キャッシュのステータスエンドポイント
サードパーティAPIのステータスページ

API障害のアラート設定#

API監視が障害を検出した場合:

アラートに含めるべき情報:

どのエンドポイントが失敗したか
障害の内容(タイムアウトか500エラーか)
いつ始まったか
最近の変更(利用可能であれば)

アラートの重要度:

Critical:決済/認証API(ユーザーがブロックされる)
High:検索/データAPI(ユーザーが不満を抱く)
Medium:アナリティクス/ロギング(ユーザーに見えるエラー)

Nova UptimeでのAPI監視#

Nova UptimeはウェブサイトのアップタイムとあわせてAPIのアップタイムも監視します:

APIドメインを追加:https://api.yourdomain.com
エンドポイント監視を設定する
メール/Slackでアラートを受け取る
インシデント履歴とレスポンスタイムを確認する
障害発生時の自動スクリーンショット(デバッグ用)

さらにメール配信ヘルスの監視も。APIがトランザクションメールを送信する場合、Nova Uptimeは同じダッシュボードでSPF/DKIM/DMARCを自動的にチェックします。

まとめ

重要なAPIエンドポイントをリストアップする
それぞれにとって「稼働中」とは何かを定義する(ステータスコード、レスポンスタイム、ボディ内容)
それぞれに対する監視を作成する
レスポンスタイムのしきい値を設定する
依存先(データベース、キャッシュ、サードパーティ)を監視する
Webhookを定期的にテストする
障害が発生したら直ちにアラートを出す

今日からAPIの監視を始めましょう:Nova UptimeのAPIモニタリング。同じダッシュボードでアップタイム + メール配信ヘルスを提供します。🚀

APIのアップタイムモニタリング:エンドポイントとWebhookの監視