Swift Concurrencyのactorまわりの整理が一段落し、次は毎回App Store Connectの画面を手動で確認していたレビュー件数やダウンロード数の把握を効率化したくなり、App Store Connect APIに挑戦しました。
1. 通常のログイン情報で使えると思っていた
最初、App Store Connectにログインしているアカウント情報をそのままAPIリクエストに使えるものだと思い込んでいました。
App Store Connect APIの認証に必要なもの:
Issuer ID / Key ID / 秘密鍵ファイル（.p8）実際にはApp Store Connectの管理画面から専用のAPIキーを発行する必要があり、ユーザー名やパスワードとは別の認証情報（Issuer ID、Key ID、秘密鍵）を組み合わせて使う仕組みでした。発行画面にたどり着くまでにも少し迷いました。
2. JWTトークンの生成でつまずいた
APIキーを発行した後、そのまま毎回のリクエストに使えるものだと思っていたのですが、実際には自分でJWT（JSON Web Token）を生成し、そのトークンを使ってリクエストする仕組みだと分かりました。
JWTに含める主な情報:
Issuer ID、Key ID、有効期限（発行から最大20分）
秘密鍵で署名有効期限が最大20分と短く、長時間のバッチ処理では途中でトークンを再生成する必要があることも見落としがちなポイントでした。最初は有効期限切れによる認証エラーの原因が分からず、しばらく調査に時間を使いました。
3. 取得できるデータの範囲を勘違いしていた
APIを使えば、App Store Connectの画面で見られる情報は何でも取得できるものだと思い込んでいました。
実際にはエンドポイントごとに取得できるデータの範囲が決まっており、例えば売上や一部の詳細な分析データは別の仕組み（レポート用のAPIやダウンロード形式）を使う必要がありました。画面上で見えている情報とAPIで取れる情報が必ずしも一致しないと気づくまで、目的のデータになかなかたどり着けませんでした。
4. リクエストの頻度制限に引っかかった
動作確認のために短時間で何度もリクエストを送っていたところ、途中からエラーが返ってくるようになり、最初はコードの不具合だと思い込んでしまいました。
レート制限に達した場合のレスポンス:
一定時間はリクエストが拒否されるApp Store Connect APIにはリクエスト頻度の制限があり、短時間に集中してテストを繰り返したことが原因でした。動作確認時はリクエストの間隔を空ける、必要なデータをまとめて取得するなど、頻度を意識した使い方に切り替えて解決しました。
まとめ
- 認証にはApp Store Connect専用のAPIキー（Issuer ID・Key ID・秘密鍵）が必要。通常のログイン情報とは別物
- リクエストにはJWTトークンが必要で、有効期限は最大20分。長時間の処理では再生成を考慮する
- 画面で見られる情報とAPIで取得できる情報の範囲は必ずしも一致しない。目的のデータがどのエンドポイントにあるか事前に確認する
- リクエスト頻度には制限がある。動作確認時も間隔を空けて実行する
手作業での確認を自動化できる魅力的な仕組みですが、認証まわりの独自ルールを理解するまでに一手間かかる実装でした。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント