API連携が急に失敗する時:認証切れ・権限・利用制限の切り分け
AIを使いこなすClaudeで執筆し、GPTで自動校閲・修正しています。
昨日まで動いていた自動化が、設定を触っていないのに止まる。そんな時は、まずエラーのステータスコードを手掛かりに原因を絞ります。401は有効な認証情報がない、403は要求を拒否された、429は短時間にリクエストを送りすぎたというのが一般的な意味です。特に403はサービスによって認証失敗として扱われる場合もあるため、コードだけで原因を決めず、エラー文と接続先の説明も確認してください。 この仮説が大事なのは、対処が違うからです。401は再接続で直ることが多い一方、403は再接続しても同じ場所で落ちがちで、429は再接続しても直らず、間隔を空ける設計の問題です。闇雲に再接続すると、直らないうえに接続の持ち主や設定を変えてしまうことがあります。 この記事は、n8n・Zapier・Makeで繰り返し業務を回している人向けです。コード別の原因候補表、再接続の前に確認する手順、AIに状況を整理させる依頼文を順に示します。
コード別の原因候補表
下の表は、HTTPステータスコードの一般的な意味と、各社の公式ヘルプにある例をもとにした整理です。サービスやAPIによって細かな返し方は異なるため、候補を絞る手掛かりとして使ってください。
- 401、最初の見立て：認証情報が無効・不足、原因候補：トークンの期限切れ・失効、パスワード変更、接続先アプリ側のセキュリティ設定変更、先に確認すること：接続先アプリにログインできるか。鍵やトークンを最近変えていないか、再接続で直る見込み：再認証で直る場合がある
- 403、最初の見立て：要求を拒否された、原因候補：連携アカウントの権限不足、APIキーのスコープ不足、対象データへのアクセス権がない。サービスによっては認証失敗として扱う、先に確認すること：連携アカウントで同じ操作を手動でできるか。エラー文と接続先の説明も確認、再接続で直る見込み：権限や認証情報の原因を直す必要がある
- 429、最初の見立て：利用制限、原因候補：短時間の大量実行、他の自動化との合算、一括処理の増加、先に確認すること：失敗した時刻の前後に実行が集中していないか、再接続で直る見込み：ほぼない
- 400・404など、最初の見立て：リクエスト内容の誤り、原因候補：入力項目の欠落、削除済みIDの指定、先に確認すること：失敗したステップの入力値、再接続で直る見込み：なし(別の問題)
5xxやタイムアウトは相手側の一時障害の可能性があり、今回の三択とは別に扱います。
注意点は、403の意味が一様ではないことです。n8nのHTTP Requestノードの公式ヘルプでは、403を認証失敗として説明し、選んだ認証情報で認証できるか確認することや、APIキーの権限(スコープ)の見直し、新しいトークンの発行を案内しています。n8nのHTTP Requestノードのよくある問題を参照してください。同ページは401を個別には扱っていません。Zapierの公式説明では401は有効な認証情報がない状態で、期限切れ・失効したトークンやパスワード変更などが原因候補です。ZapierのHTTPステータスコード別の説明も参考にしつつ、接続先のエラー文を確認してください。
再接続の前に確認する5ステップ
再接続は最後の手段にして、次の順で確認します。上から順に、情報が少なくても進められる順です。
- 失敗の時刻と最初の1件を特定する。 実行履歴から、初めて失敗した実行を探します。それ以前の成功と何が変わったかを見るためです。
- ステータスコードとエラー文を原文のまま控える。 要約せずコピーします。コードがなければ、エラー名(後述のMakeなら種別名)を控えます。
- 接続先アプリに連携アカウントで直接ログインする。 ログインできない、パスワードを変えた、二段階認証を有効にした、といった変更があれば401系です。
- 連携アカウントの役割・プラン・APIキーの権限を見る。 異動や権限整理で役割が下がっていないか、使っている機能が契約プランに含まれるかを確認します。Zapierの公式ヘルプも、Not authenticated / Unauthorizedの原因として、ユーザーの権限不足、プランの制限、接続の確立失敗を挙げています。Zapierの該当ヘルプに、権限の確認、プランの確認、アカウントの接続し直しの順で書かれています。
- 原因を直した後に、1件だけ再実行する。 失敗したデータを1件だけ流し、同じコードが出るか見ます。再現しない場合は一時的な問題だった可能性があります。429なら短時間のリクエスト集中、5xxなら接続先の一時障害なども候補にして、実行履歴や接続先の稼働状況を確認します。
ここまでで原因が見えなければ、初めて再接続に進みます。その際は誰の名義の接続かを確認します。個人アカウントで作った接続が、その人の退職や異動で無効になる例は典型的です。ここは私の編集上の提案ですが、業務で使う連携は、専用の連携アカウントで接続しておくと原因の切り分けが楽になります。
3ツールでの見え方の違い
n8n
認証の期限は、接続先の設定によって決まることがあります。たとえばGoogle OAuthでは、外部ユーザー向けアプリが「テスト」状態の場合、同意とトークンが7日で切れるとn8nの公式ヘルプにあります。該当する構成なら、n8nの認証情報画面から接続し直します。この仕様はn8nのGoogle OAuth説明で確認できます。ほかにもredirect URIの不一致や、クライアントIDとシークレットの不一致がエラーの原因として挙げられています。
Zapier
Zapierでは、履歴から「Errored」の実行を選び、TroubleshootタブでAIによる原因説明と手順を確認できます。公式ヘルプは401についてトークンの期限切れ・失効などを、403についてアカウント権限の確認を、429についてレート制限の確認を案内しています。Zapierのエラー対処を参照してください。
Make
Makeでは、401と403に対応するHTTPステータスコードがAccountValidationErrorに関連づけられ、429はRateLimitErrorとして扱われます。画面ではコードではなく種別名が表示される場合があります。AccountValidationErrorはMakeが接続先アプリで認証できない状態で、認証情報の期限切れや変更などが原因になります。公式ヘルプによると、これはエラーハンドラーでは対処できず、認証情報を確認し、必要なら接続を作り直します。シナリオはエラー終了後、8回の試行後にスケジュールが無効化されるため、修正後は有効か確認してください。出典はMakeのエラーと警告の対処です。
429は「間隔」で直す
429は認証や権限の問題ではないので、再接続は不要です。n8nのHTTP Requestノードには、二つの公式の対処があります。
- バッチ処理: 1回に送る件数(Items per batch)と間隔(ミリ秒)を設定する。たとえば間隔を1000にすると、およそ1秒に1件のペースになります。
- 失敗時の再試行: ノードの設定で最大試行回数と待機時間を指定する。
Makeは、429をRateLimitErrorとして既定で扱います。同じヘルプによると、スケジュール実行のシナリオは、不完全な実行を保存する設定が有効なら20分待って再試行します。Zapierも自動再実行(Autoreplay)で一時的な失敗を再試行しますが、上限を超え続ければ解決しないので、一度に流す件数を見直します。
自分で調整する場合は、連携先の公式ドキュメントで上限値を確認し、実行の集中している時間帯をずらすのが基本です。上限値は接続先ごと、プランごとに違うため、ここでは具体値を挙げません。
AIに渡す依頼文と、人が確認する部分
エラーの原文を貼ると、AIは候補の整理と確認順の提案をしてくれます。ただし、鍵やトークン、顧客名、社内URLは貼らず、置き換えてください。次は説明用の例で、実際には試していません。
自動化ツール:Make(他の場合はn8n / Zapier)
連携先:[アプリ名](例:ダミー会計アプリ)
症状:毎朝9時の実行が、10/25から失敗している
エラー表示:AccountValidationError / 401
直前の変更:不明(10/24に担当者がパスワードを変更した可能性)
接続の名義:個人アカウント
やりたいこと:認証切れ・権限・利用制限のどれかを、
確認の安い順に並べてください。
再接続する前に確認すべきことも5つ挙げてください。
鍵やトークンの値は貼っていません。AIに任せるのは、候補の順位づけと確認項目の整理です。人が行うのは、接続先アプリへの実際のログイン、役割・プランの確認、再接続の実行、再接続後の1件テストです。AIの回答にある「この設定を変えれば直る」は、各社の公式ヘルプと突き合わせてから実行してください。
