iTunes Lookup APIによる公開状況の自動チェックを
実装1週間で手動運用に戻した話

2026年7月31日に設計したiTunes Lookup APIでの自社アプリ公開判定の自動化は、8月2日付で運用ルールから正式に外した。原因はAPIの仕様やレート制限ではなく、日次バッチを実行しているサンドボックス環境のアウトバウンド通信ポリシーがitunes.apple.comへのCONNECTそのものを403で拒否していたことだった。1週間で結論を出せたので、切り分けの過程を残しておく。

症状は「レスポンスが返らない」ではなく「接続自体が張れない」だった

実装直後の数日はresultCountが常に0を返し続け、全アプリが「未公開」と判定された。当初はbundleId不一致かレート制限を疑ったが、実際にログに残っていたのは200番台のHTTPレスポンスではなく、TLSのCONNECTトンネル自体が確立できていないというエラーだった。

実行環境のアウトバウンド通信はホワイトリスト方式だった

日次バッチを動かしているサンドボックスは、外部通信をゲートウェイ経由のプロキシに強制しており、許可リストに載っていないホストへのCONNECTは403で機械的に拒否される仕組みだった。npmレジストリやGitHub、PyPIなど開発に必須のホストは許可リストに入っている一方、itunes.apple.comは最初から対象外で、これはAPI側の障害でも一時的な不調でもなく、環境側の恒常的なポリシーだと確認できた。

• 許可リストに載っていないホストへのCONNECTは、リクエストを送る前にゲートウェイ側で拒否される
• 拒否はHTTPレスポンスではなくTLSトンネル確立の失敗として現れるため、通常のステータスコード判定ロジックでは検知できない
• この挙動はitunes.apple.com固有ではなく、許可リスト外のホスト全般に対して同様に発生する

「動かない」原因を確定させてから、初めて撤退を判断した

自動化の設計自体は7月31日の記事の通り筋が良かったが、実行環境を変えない限り解決しない種類の失敗だと判明した時点で、この日次バッチの中でAPIチェックを続ける判断は撤回した。原因不明のまま「たまに動く」状態で残すよりも、失敗の原因を確定させてから機能ごと外す方が、後任(未来の自分を含む)が同じ調査を繰り返さずに済む。

1. 症状(0判定が続く)を再現させ、レスポンスの中身ではなく通信ログを確認した
2. bundleId・パラメータ・レート制限という「よくある原因」を順に消去した
3. 接続自体が拒否されている証拠(403 CONNECT)を確認し、環境起因と確定させた
4. 機能を無効化し、判定ロジックとレジストリファイルの記述をリポジトリから削除した

Related

iTunes Lookup APIで自社アプリの公開状況を自動チェックする仕組みを設計した話 →

← ブログ一覧に戻る