原因不明のAPIエラーは、まず相手側を疑え

エラーが出たら、まず自分を疑うな。相手を疑え。

しろまえ殿が、AIの開発ツールを使っていて「529 Overloaded」というエラーに当たったときの話だ。

見慣れないエラーコードが出ると、つい設定ファイルを開き直したり、APIキーを打ち直したりしたくなる。

しろまえ殿は、その手前で一度立ち止まった。

手元をいじる前に、外を見る

529という数字は、サーバー側が今、処理しきれないほど混雑している、という意味を持つ。

つまり自分の環境が壊れたのではなく、相手のサーバーが一時的にパンクしているだけの可能性がある。

しろまえ殿は、提供元が公開している稼働状況ページを開いた。

障害の有無をグラフで示しているページだ。

そのグラフは、エラーが出た時刻とちょうど重なる形で、稼働率が落ち込んでいた。

赤やオレンジの表示で、障害が起きていたことがはっきり読み取れた。

これで、原因は自分の設定ではなく、相手側の一時的な過負荷だと判断できた。

たとえば、電話が繋がらないとき、真っ先に自分のスマホを再起動する人は多い。

だが実際には、電話会社の基地局側が混雑しているだけ、ということがよくある。

先に確認すべきは、自分の端末より先に「今、向こう側で何か起きていないか」だ。

対処は三段構え

しろまえ殿がこの一件から整理した対処の型は、シンプルだ。

一つ、少し時間を空けてから、もう一度試す。混雑は長くは続かないことが多い。

二つ、プログラムから自動でAPIを呼ぶ仕組みなら、指数バックオフ(失敗するたびに待ち時間を段階的に伸ばしながら再試行する方式)を組み込んでおく。混雑のピークをやり過ごせる。

三つ、原因の裏取りとして、稼働状況ページを必ず確認する。憶測で「自分のせいだ」と決めつけない。

「原因不明」を減らす習慣

しろまえ殿は、この経験を運用の型として持ち帰った。

エラーの原因が分からないとき、まず疑うべきは自分の設定ではなく、相手のサービス状況だ。

その確認さえ習慣にしておけば、無駄に自分の環境をいじり回して時間を溶かすことが減る。

複数の作業が同時にAPIを呼ぶ構成では、こうした一時的な混雑はこれからも起こりうる。

「エラーが出た」の一報だけで個別に慌てて調査させるのではなく、まず稼働状況ページを見て、外側の障害かどうかを先に切り分ける。

それだけで、無駄な調査に費やす時間をずいぶん減らせる。