LASSIC Media らしくメディア
外部エンジニアのAPIタイムアウト調査、性能改善で見落とす要因
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- APIタイムアウト調査を頼む前に、呼ぶ側と呼ばれる側の両方のログ、応答時間の計測値、各層の待ち時間の設定をそろえます。
- 構成図にはネットワーク機器や負荷分散装置も入れ、調査をアプリの中だけに絞るかどうかを先に決めます。
- 報告では、時間を使った場所とその根拠、当面の対処と恒久的な直し方の区別、確かめられなかった点を書いてもらいます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
外部のサービスを呼ぶ処理が、ときどき時間切れで失敗する。もう一度実行すれば通るので、原因が分からないまま日が過ぎていく——。APIタイムアウト調査とは、API（システム同士がデータをやり取りするための窓口）の呼び出しが、決められた待ち時間のうちに応答を受け取れなかったときに、どこで時間がかかったのか、なぜそうなったのかを確かめる作業を指します。性能改善のための調査を外部エンジニアに頼むときは、待ち時間の設定を伸ばすかどうかより先に、時間を使った場所を探してもらうことになります。
本記事では、IPA（情報処理推進機構）の「情報処理システム高信頼化教訓集（ITサービス編）」から、応答の遅れや時間切れが絡んだ3つの事例を取り上げ、発注側が渡すもの、調査の範囲、報告の受け取り方を整理します。どれもAPIそのものの事例ではありませんが、原因がアプリケーションの外にあった点で、APIのタイムアウトを調べる手がかりになります。なお、調査を頼めば原因がすぐに見つかって直る、という性質の作業ではありません。
目次
APIタイムアウト調査とは
タイムアウトは、呼ぶ側が決めた待ち時間を超えたという結果です。原因そのものではありません。APIの呼び出しには、呼ぶ側のアプリ、ネットワーク機器、負荷分散装置、呼ばれる側のサーバー、その先のデータベースといった、いくつもの層が関わります。それぞれの層が自分の待ち時間を持っていることも多く、どこで遅れても、呼ぶ側からは「時間切れ」という同じ形で見えます。
そのため調査では、大きく3つのことを確かめてもらいます。どの層で時間を使っていたのか。なぜそこで時間がかかったのか（処理するデータの量が増えた、上限に当たった、機器が不調だった、設定が合っていなかった、など）。そして、当面の対処と恒久的な直し方をどう分けるのか、です。待ち時間を伸ばすのは対処の一つですが、伸ばした分だけ利用者を待たせる時間も長くなります。場所が分からないまま値だけを変えると、次に起きたときの手がかりも残りません。
手がかりにするIPAの教訓集は、システムの障害事例の情報を分析し、そこから導いた教訓をまとめたものです。*4 各教訓は、問題、原因、対策、効果、教訓の順に書かれています。取り上げるのは、データの量が増えて応答が遅れた教訓T14、監視に出ないまま遅れが続いた教訓T11、時間切れが連鎖して止まった教訓T23の3つです。順に見ていきます。
データの量が増えて遅れた事例
教訓T14のA社では、企業サイトの中の特定のサービスBにアクセスしにくくなり、応答の遅れによって多くの顧客がサービスBを使えなくなりました。きっかけは、サービスBのトップページのコンテンツの更新です。リリースの直後から、利用者がトップページを開くと応答に長い時間がかかり、サービスBの本体に接続できない例が多く出ました。障害に気づいたのは、DDoS（大量のアクセスで相手を止める攻撃）の検知装置が反応したことと、利用者からの問い合わせでした。*1
直接の原因は、業務部門の担当がトップページを大規模にリニューアルした結果、1顧客当たりのダウンロードサイズが従来の約4倍に増えたことです。データの量が増えたことによる応答速度への影響を確かめないままリリースしたため、アクセスが集まるとネットワークの帯域が逼迫し、応答の遅れからスレッド枯渇が起きました。もう一つ、サイトの大部分のページは高速ネットワークサービスを経由していたのに、このトップページは経由していませんでした。*1
暫定の対策として、コンテンツを更新前のものに戻してサービスを再開し、ネットワークの帯域と受付のスレッド数を広げました。そのうえで、トップページへのアクセスを高速ネットワークサービス経由に変えて出し直し、コンテンツの変更量を自動で確かめる仕組みを入れて、コンテンツの量とアクセスの量を見えるようにしています。
APIに置き換えると、応答で返すデータの量が増える変更と、機能ごとに通る経路の違いが、調査の入口になります。外部エンジニアには、時間切れが出始めた前後のリリースの一覧と、応答の大きさの変化を渡します。
監視に出ないまま続いた遅れ
教訓T11のA社では、あるWebサービスで、障害がはっきり検出されていないのに性能が落ちる「サイレント障害」が起きました。教訓集は、通常の運用監視の仕組みでは検出されないまま性能の劣化などが起きることをこう呼び、発生した場所や原因の特定に多くの時間と労力がかかることが多いと説明しています。
このシステムは、1台の負荷分散装置の下に3〜6台のサーバーを置いたセットを、いくつも並べた構成でした。負荷分散装置でセッション数の超過によるリクエストの廃棄と再送が起き、応答速度が落ちましたが、サービス監視からの通知はありませんでした。社員から指摘を受けるまで、遅れは見つかっていません。*2
直接の原因は、負荷分散装置のファームウェアの不具合です。使っていた版では、受け付けるセッション数の上限が設定値の1/4までしか許されない「仕様」になっており、それを知らないまま上限を設定していました。監視は、リクエストが一定回数連続して廃棄されたときに知らせる設定で、しきい値には届いていませんでした。対策として、ファームウェアを更新し、一定の時間内に一定回数以上廃棄されたら知らせる条件に改めています。*2
この事例から言えるのは、監視が鳴っていないことは、遅れが無いことの証しにはならない、という点です。APIの時間切れを調べてもらうときは、監視で何をしきい値にしているかと、負荷分散装置などの機器の版まで渡しておくと、調べる側が見落としを減らせます。
時間切れが連鎖した事例
教訓T23のA社の基幹システムは、24時間365日動くオンラインシステムで、DBサーバーは4重化されていました。ある日、そのDBサーバー4台すべてが順番に止まりました。
このシステムでは、1台のDBサーバーでデータが更新されると、ネットワークスイッチを通じて他のDBサーバーへ同期の更新を送ります。この同期の更新がタイムアウトすると監視サーバーに知らせが行き、送った側のDBサーバーを止める仕組みでした。別に、各DBサーバーが自分自身にSQLを投げて、返事があるかどうかで動いているかを調べる監視を45秒ごとに行っていました。*3
直接の原因はネットワークスイッチのキャッシュメモリの故障でしたが、スイッチはエラーメッセージを出さなかったため、検知できませんでした。同期の更新が正常に行われず、3台のDBサーバーが順に止まりました。最後の1台で運用を続けられるはずでしたが、その1台が投げた監視用のSQLが同期の更新のタイムアウトに巻き込まれてタイムアウトになり、これも止まりました。教訓集は、2つの監視機能の実行タイミングが重なったことで全台が止まったと説明しています。*3
対策の一つは、自分自身を調べる監視について、タイムアウトの待ち時間を延ばす、何回か再試行する、といった手を打ち、そのうえで他の監視機能との組み合わせに同じような問題がないかを確かめて試験することでした。*3 待ち時間の値は、単独ではなく、他の仕組みの待ち時間と組み合わさって働きます。値を変える提案を受けたら、組み合わせを確かめたかどうかを聞いておきます。
依頼の前にそろえるもの
3つの事例に共通するのは、時間を使っていた場所が、症状が見えた場所とは別だったことです。外部エンジニアが短い時間で当たりを付けられるよう、社内で次の記録をそろえておきます。
| 記録 | 中身の例 | 関わる事例 |
|---|---|---|
| 発生の記録 | 時間切れになった日時、呼び出し先、件数、返ってきたエラーの内容、再実行で通ったかどうか | 3つとも |
| 両側のログ | 呼ぶ側と呼ばれる側のアプリのログ。サーバーごとの時刻のずれも書き添える | T23 |
| 応答時間の計測値 | 平常時と発生時の応答時間、同じ時間帯の呼び出しの件数 | T11・T14 |
| 待ち時間の設定 | 呼ぶ側のアプリ、負荷分散装置、呼ばれる側のサーバー、データベースそれぞれの待ち時間と再試行の回数 | T23 |
| 構成図 | ネットワーク機器と負荷分散装置まで入れた経路。経路が機能ごとに違うならその違いも | T14・T23 |
| 直前の変更 | リリース、応答のデータ量が変わる変更、機器のファームウェアの更新 | T11・T14 |
| 監視の条件 | 何をしきい値にして、どんな条件で通知するか | T11・T23 |
なかでも手間がかかるのが、両側のログの突き合わせです。呼ぶ側のログには「何時何分に時間切れになった」と残っていても、呼ばれる側でその呼び出しが届いていたのか、届いて処理に時間がかかったのかは、呼ばれる側のログを見ないと分かりません。サーバーごとに時刻がずれていると突き合わせが難しくなるので、ずれの有無も伝えておきます。
不具合の原因調査を頼むときの一般的な準備は「外部エンジニアに不具合の原因調査を頼む手順」で、メモリの使用量が増え続ける場合は「メモリリーク調査で渡す記録」でまとめています。
調査の範囲をどう決めるか
最初に決めておきたいのは、どの層まで見てもらうかです。アプリのコードとデータベースだけを見てもらうのか、ネットワーク機器や負荷分散装置の設定とログまで含めるのか。教訓T11と教訓T23は、どちらも原因がアプリの外の機器にありました。範囲をアプリの中だけに絞るなら、機器の側は社内か別の担当が見る、と決めておかないと、どちらからも見られない層が残ります。機器の保守を別の会社が持っている場合は、問い合わせの窓口も先に伝えておきます。
次に、本番の環境で何をしてよいかを決めます。計測のための設定を足してよいか、負荷をかける試験をしてよいか、行うならどの時間帯か。ログに個人データが含まれるなら、社外へ持ち出してよいか、社内の端末で見てもらうかも先に決めます。
原因の調査は、いつまでに原因が見つかるかを約束しにくい作業です。作業時間の上限と、途中で状況を知らせてもらう時点を決めておくと、見通しが立たないまま時間だけが過ぎることを避けやすくなります。どこまでの作業を頼めるか、結果をどう扱うかは、契約と相手の提供範囲で確かめてください。
報告の受け取り方
報告には、どの層で時間を使っていたかと、それを示す根拠（計測値やログの該当箇所）を書いてもらいます。あわせて、確かめられなかった点も書いてもらいます。教訓T11のように、使っている機器の版の「仕様」が原因だった例もあります。*2 調べ切れなかった層が分かっていれば、次に誰が何を見るかを決められます。
対策は、当面の対処と恒久的な直し方を分けて書いてもらうと、社内で判断しやすくなります。教訓T14では、更新前に戻す、帯域と受付のスレッド数を広げる、という暫定の対策のあとに、経路の変更と変更量の自動チェック、さらに手順書の見直しという再発の防止までが分けて書かれています。*1 待ち時間や再試行の回数を変える提案なら、教訓T23のように他の仕組みとの組み合わせを確かめた結果も添えてもらいます。
監視の条件を見直す案も、報告に入れてもらう価値があります。教訓T11では、連続した回数ではなく、一定の時間内の回数で知らせる条件に改めました。本番への反映や利用者への知らせは社内で決めることなので、報告を受けたら、反映の順番と担当を社内で決めます。
まとめ：APIタイムアウト調査を頼むときの3つの点
APIのタイムアウトで性能改善のための調査を外部エンジニアに頼むとき、確かめておきたい点は3つです。第一に、呼ぶ側と呼ばれる側の両方のログ、応答時間の計測値、各層の待ち時間の設定、直前の変更、監視の条件をそろえていること。第二に、ネットワーク機器や負荷分散装置まで調査の範囲に含めるかどうかと、本番の環境でしてよいことを決めていること。第三に、時間を使った場所とその根拠、当面の対処と恒久的な直し方、確かめられなかった点を報告に書いてもらうことです。IPAの3つの事例では、原因はどれも症状が見えた場所の外にありました。調査を任せられる人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
タイムアウトの値を伸ばせば解決しませんか
症状が収まることはあります。ただ、伸ばした分だけ利用者を待たせる時間も長くなり、どこで時間を使っていたかは分からないままです。教訓T23でも待ち時間を延ばす対策が取られましたが、他の監視機能との組み合わせを確かめて試験することと一緒に行われています。*3 値を変えるのは、時間を使っている場所に当たりが付いてからにするのが扱いやすい順番です。
監視で異常が出ていなくても、調査を頼んでよいですか
頼んでかまいません。教訓T11では、監視のしきい値に届かないまま応答の遅れが続き、社員から指摘を受けるまで見つかりませんでした。*2 利用者からの声や、時間切れのエラーの件数が増えていることも、調査を始める理由になります。
社内にネットワーク機器の担当がいない場合はどうしますか
調査の範囲に機器の設定とログまで含めてもらえるかを、外部エンジニアに先に確かめます。機器の保守を別の会社が持っているなら、その会社への問い合わせを誰が行うかも決めておきます。どこまで頼めるかは、契約と相手の提供範囲で確かめてください。
調査の範囲が決まったら相談
APIのタイムアウトについて、どの記録を渡し、どの層まで見てもらいたいかが決まっていれば、そのままご相談いただけます。範囲を決めきれていない段階でも構いません。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」3.14 Webページ更新時の性能に関する教訓（T14）（PDF）（https://www.ipa.go.jp/archive/files/000049551.pdf）。出典：問題（サービスBへのアクセス障害の経緯）、原因（直接的な原因と根本的な原因）、対策（暫定的な対策・直接的な対策・類似障害の再発防止策）、効果、教訓を参照（確認日2026年10月2日）（2026年10月確認）
- *2 参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」3.11 サイレント障害に関する教訓（T11）（PDF）（https://www.ipa.go.jp/archive/files/000049548.pdf）。出典：問題（サイレント障害の説明、システムの構成、障害発生の経緯）、原因（負荷分散装置のファームウェアの不具合とサービス監視の条件）、対策を参照（確認日2026年10月2日）（2026年10月確認）
- *3 参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」3.23 障害監視機能のあり方に関する教訓（T23）（PDF）（https://www.ipa.go.jp/archive/files/000056881.pdf）。出典：問題（DBサーバーの4重化と障害監視の機能）、原因（ネットワークスイッチの故障と全DBサーバー停止の経緯）、対策1・対策2を参照（確認日2026年10月2日）（2026年10月確認）
- *4 参考：IPA「情報処理システム高信頼化教訓のリンク集（ITサービス編）」（アーカイブ）（https://www.ipa.go.jp/archive/digital/iot-en-ci/system/lesson.html）。出典：教訓の一覧（教訓T11・T14・T23の種類とタイトル）を参照（確認日2026年10月2日）（2026年10月確認）
