401エラーとは？原因と直し方、403・429・500との違いも

「昨日まで動いていた連携が、急に401で止まった…」

「403、429、500…数字は出ているのに、何が悪いのか分からない！」

APIのエラーが出て、業務が止まって困っていませんか？

開発に詳しくないと、どれも「エラー」とひとくくりにしがちです。誰に何を伝えればよいか分からず、問い合わせの往復で復旧が遅れることもよくあります。

本記事では、現場でよく出る401・403・429・500の意味と、それぞれの解決の手順、開発会社やベンダーに伝えることを、API連携を作っている開発会社の立場で解説します。

APIエラーの悩み：こんなことありませんか？

APIのエラーで困るのは、数字が出ても「誰が何をすれば直るか」が分からないことです。社内システムとSaaSの連携、チャットボット、RPA、データ連携の仕組みでよく起きる困りごとは次の3つです。

昨日まで動いていた連携が、急に止まる

設定も触っていないのに、朝来たら夜間の連携が失敗している。401や403は、鍵の期限切れや、誰かが別の画面で変えた設定がきっかけで起きることが多いエラーです。

エラーの数字を見ても、誰に聞けばよいか分からない

自社の設定の問題なのか、相手のサービスの障害なのかが分からないと、問い合わせ先が決まりません。数字ごとに「まず疑う所」が違います。

ベンダーとのやり取りが何往復もかかる

「いつから」「どの連携で」「どんな条件で」が伝わらないと、調べる側は何度も聞き直します。最初に伝える中身をそろえるだけで、復旧は早くなります。

APIエラーとは？数字で「誰の問題か」の当たりがつく

APIエラーの数字は、相手（または自社）のサーバーが返す「HTTPステータスコード」で、原因の当たりをつける手がかりです。400番台は「頼み方・鍵・権限・量」が合っていないことが多く、500番台は「サーバー側で処理に失敗した」ことが多い、という目安になります。

ただし、500が返っていても、原因が自社の送ったデータにあることもあります。数字だけで「相手が悪い」と決めつけず、下の表で最初に見る所を決めます。

どのコードでも、次の3つをそろえると調査の半分は終わります。「いつ」「どの連携で」「どの条件で」失敗したかです。

• 再現条件：誰が・どの画面やバッチで・何をしたら起きたか（同じ操作で再現できるか）
• どの呼び出しか：API名、呼び出し先のURL、時間帯、返ってくればリクエストID
• 返ってきた中身：ステータスコード、エラーメッセージの本文、レスポンスヘッダー

SaaS同士をつなぐ連携ツール（iPaaS）では、裏で複数のAPIが順につながっています。表に見えているエラーが本当の原因とは限らないので、連携ツールの実行履歴で「どのステップで止まったか」を先に確かめてください。

401エラーとは？認証できていない（鍵が違う・期限切れ）

401 Unauthorized は「あなたが誰か確かめられないので処理できません」という意味です。APIキー、アクセストークン、Basic認証などの認証情報が無い・間違っている・期限が切れているときに返ります。認証方式の違いは、API認証（APIキー/OAuth/JWT）の違いと使い分けで解説しています。

401のレスポンスには、サーバーが求める認証のしかたを示す WWW-Authenticate ヘッダーが付きます（例：Bearer ならアクセストークンが必要）。出典：MDN「401 Unauthorized」（2026年10月時点）

401エラーの解決の手順

1. 認証のしかたを確かめる：APIキーか、OAuth（ログインして許可するしくみ）か、Basic認証か
2. 設定されている場所を特定する：連携ツールの接続設定、サーバーの環境変数、GitHub Actions など
3. 再認証・キーの貼り直しをする：連携ツールやSaaSの管理画面に「接続を更新」「再認証」のボタンがあれば、まずそこを押す
4. 本番と検証の取り違えを確かめる：キーと呼び出し先のURLが同じ環境のものか

ここまでで直らなければ、開発会社やベンダーに渡します。要点は「どの認証情報で、いつから、どの環境で」失敗しているかです。

• 対象のAPIと環境（本番・検証）、失敗し始めた日時
• 認証のしかた（APIキー、OAuth、JWTなど）と、設定している場所
• 直前の変更（キーの再発行、連携設定の変更、権限の変更、IP制限の設定など）
• レスポンスの本文（できれば全文）

401を繰り返さないための管理

鍵とトークンの扱いを決めておくと、401の多くは防げます。「誰が発行し、どこに保管し、どう更新するか」を書き残し、担当者が替わるときの引き継ぎに入れます。期限のあるトークンは、切れる前に知らせる仕組みを入れます。認証情報はプログラムの中に書かず、クラウドの秘密情報の管理機能（Secret Manager など）にまとめます。鍵の保管と更新の決め方は、APIキーの安全な管理方法で解説しています。

401と403の違い：「誰か分からない」か「許可されていない」か

401は「認証」の失敗、403は「権限」の不足です。401は鍵を直したり再認証したりすれば直ることがありますが、403は認証し直しても結果は変わりません。出典：MDN「403 Forbidden」（2026年10月時点）

なお、権限の無い相手にデータがあること自体を知らせたくない場合、サーバーは403の代わりに404（見つからない）を返すこともあります。権限を変えた直後に404が出たら、権限も疑ってください。

403エラー：認証はできたが権限が足りない

403 Forbidden は「あなたが誰かは分かったが、その操作は許可されていません」という意味です。権限（ロール）の不足、契約プランの制限、アクセス元の制限（IP制限など）が原因で、設定の変更や契約の変更のあとに急に出ることが多いエラーです。

まず「誰の権限で呼んでいるか」を確かめる

API連携は、人ではなく連携専用のアカウント（サービスアカウント）で動いていることがよくあります。この場合、操作している担当者の権限を上げても直りません。連携設定の画面に出ている接続ユーザーや、APIキーを発行したユーザーを確かめ、SaaSの管理者に権限を聞くのが最短です。

通る操作と断られる操作の差をメモする

同じAPIでも「読み取りは通るが書き込みは403」なら、権限やスコープ（OAuthで許可した範囲）が足りません。成功する操作と失敗する操作の差をメモして渡すと、調査は一気に早くなります。ベンダーには次を伝えます。

• どの操作（参照・登録・更新・削除）で403になるか
• 呼び出しに使っているアカウントの種類（人のアカウントか、サービスアカウントか）
• 直前の変更（権限、組織の移行、IP制限、WAF、契約プラン）
• 相手の管理画面で見える権限設定のスクリーンショット（出せる範囲で）

サービスアカウントの権限は、強すぎると情報漏れのおそれが増え、弱すぎると業務が止まります。必要な分だけに決めて書き残し、権限・IP制限・WAF・契約を変えるときは「連携への影響」を確かめる項目をチェックリストに入れてください。

429エラー：呼び出しが多すぎる（レート制限）

429 Too Many Requests は「短い時間に呼び出しが多すぎます。少し待ってください」という意味です。多くのAPIには、一定の時間に呼べる回数の上限（レート制限）があります。429は、仕組みは正しく動いているのに、量が増えて上限を超えたサインです。429は RFC 6585 で決められたコードです。出典：MDN「429 Too Many Requests」（2026年10月時点）

今すぐできる対処：連打せず、待つ時間を延ばす

まず、レスポンスに「何秒待つか」を示す Retry-After ヘッダーがあるかを確かめ、あればその時間を待ちます。手で再実行するときも連打はやめ、時間を置きます。連携ツールに「再試行の間隔」「最大回数」「指数バックオフ（失敗のたびに待つ時間を延ばす）」の設定があれば、その場で見直せます。

恒久の対策：呼び出しの回数そのものを減らす

変わった分だけ取る、まとめて送れるAPI（バルク）を使う、処理の時間をずらす、同じデータを何度も取りに行かない、といった作りの見直しで429は減ります。ベンダーには、発生する時間帯、ピーク時の呼び出し回数、再送の設定（間隔・回数・同時に動く数）、相手のレート制限の仕様（契約プランでの違いを含む）を伝えます。作り方の詳しい話はREST APIとGraphQLの違いと選び方｜レート制限（429）で止まらないAPI連携の作り方で解説しています。

500エラー：相手先（または自社）の内部処理が落ちた

500 Internal Server Error は「サーバーの中で想定外のエラーが起きました」という意味です。相手の障害のこともあれば、自社が送ったデータが想定外で、相手がうまく処理できずに500を返していることもあります。送ったデータとタイミングを含めて切り分けます。

対処の順番：稼働状況→間隔を空けた再試行→データの分割

最初に、相手のサービスの稼働状況ページや障害・メンテナンスのお知らせを確かめます。障害中なら自社でできることは少ないので、手入力に切り替える、翌朝に再実行する、処理を止める、といった業務側の判断をします。障害の知らせが無ければ、連打せず間隔を空けて再試行します。

同じデータで何度も500なら、原因の1件を探す

同じデータで毎回500になるなら、送った中身が引き金です。「顧客名の記号で落ちる」「備考欄が長すぎる」「日時の形式がずれている」などです。まとめて送って500になる場合は、データを分けて送り、どの1件で落ちるかを絞ります。原因の1件が分かると、復旧も再発防止も一気に進みます。

500はログが決め手です。ベンダーには、発生時刻、対象のAPI、リクエストID（返ってくれば）、送ったデータの見本（個人情報は伏せる）、起きる条件（特定のデータだけか、全件か、時間帯か）、社内の回線やプロキシの変更の有無を伝えます。

一次対応の進め方：エラーが出たら最初にやること

エラーが出たら「業務を止めない手当て」と「原因を調べるための記録」を同時に進めます。401・403・429・500のどれでも、次の4ステップで動きます。

ステップ①：影響の範囲を確かめる

どの業務が止まり、何件・どの部署に影響しているか。締め処理や請求など、期限のある業務かどうかも確かめます。

ステップ②：エラーの情報を残す

ステータスコード、画面のエラー文、ログ、リクエストID、いつから起きているか、直前に変えた設定を残します。再試行の前に残しておかないと、記録が消えることがあります。

ステップ③：再現するかと、仮の回避を決める

同じ操作で再現するか、特定のデータや時間帯だけか。並行して、手作業への切り替え、バッチの停止、実行時間の変更、対象を分けての再実行など、仮の回避を決めます。

ステップ④：決まった形で連絡する

社内の開発担当や外部のベンダーへは、下の形で連絡します。短くても要点がそろっていれば、往復が減ります。

特に、401・403は認証と権限の情報、429は呼び出しの量と時間帯、500はリクエストIDとデータの見本が要ります。

再発を防ぐ：止まらない連携にするコツ

APIのエラーは、作り方と運用の決めごとで減らせます。データの量や使い方が変わるほど、作ったときには出なかったエラーが出るようになります。

このほか、送る前に形式を確かめる（入力チェック）、失敗が続いたら一時的に呼ぶのを止める（サーキットブレーカー）、失敗した分を後で送り直せるよう順番待ちに入れる（キュー）、手作業に切り替える手順を決めておく、といった作りにすると、相手の障害でも現場が混乱しにくくなります。429の回数や処理時間を記録しておけば、「データが増えたのか」「再送が暴走したのか」を後から判断できます。

連携の作り直しを社外に頼むときの比べ方は、システム開発の外注先（開発会社）の選び方で解説しています。