fastlaneでAPI Keyに対応しているApp Store Connect操作は、まずAPI Keyを使ってください。必要な操作が未対応の場合に限り、その処理にApple ID認証を残します。ビルドのアップロード、メタデータの更新、配信などを一括りにせず、実際に使う各アクションの対応状況を確認してください。
対象読者：手作業の提出を自動化したい個人開発者、リモートMacやCIで公開工程を保守する小規模チーム向けです。
既存のfastlane構成で認証範囲や追加のApple ID認証が曖昧な場合にも役立ちます。
01 まず、公開フローを操作単位に分ける
fastlane deliverはApp Store Connect API Keyで使えますか？
対応する認証方法はアクションごとに確認します。fastlaneのApp Store Connect API対応一覧では、API Keyが使えるツールと、まだ対応していないツールが区別されています。deliverの設定はアクションの公式ドキュメントで確認してください。
「API Keyで認証できた」ことは、公開フローのすべてがAPI Keyだけで動く証明にはなりません。たとえば、ビルドのアップロードとストア情報の更新は別の処理として扱い、実行するアクションごとに認証方法を割り当てます。
- ビルドを作成し、アップロードする
- アプリの説明文やスクリーンショットなどの情報を更新する
- TestFlightへの配信など、公開に続く処理を行う
- プライバシー情報など、追加のApp Store Connect情報を変更する
プライバシー情報の更新を含める場合は、fastlaneのプライバシー情報アクションの説明も確認してください。必要な機能がAPI Keyに未対応なら、そのアクションだけApple IDを使う構成を検討します。
02 API Keyの範囲は種類とロールで決まる
App Store Connect API Keyには、Team KeyとIndividual Keyがあります。AppleのAPI Key作成と権限の説明に従い、鍵の種類だけでなく、割り当てるロールと対象アプリの範囲も確認してください。Team Keyは個別のApp単位でアクセスを隔離する鍵として扱えません。
Individual Keyはユーザーの権限範囲に結びつくため、誰の権限で作成され、どのアプリを操作できるかが重要です。どちらの種類でも、作業に必要な権限だけを選びます。権限不足が出たら、最初に「必要なアクション」「対象アプリ」「キーの種類」「付与されたロール」を照合してください。権限を広げる前に、実行タスク自体がAPI Keyに対応しているかも再確認します。
fastlaneのAPI Keyで権限エラーが出たときは、何を確認しますか？
キーの種類とロール、対象アプリ、実行するアクションの対応状況を順番に確認します。API Keyの権限を追加しても、未対応アクションが対応するようにはなりません。AppleのAPI Keyの権限に関する説明とfastlaneの対応一覧を並べて確認してください。
03 認証情報の保管責任を分ける
API Keyで使う情報は、.p8秘密鍵、Key ID、Issuer IDです。AppleのJWT生成に関する仕様では、JWTの有効期間は最大20分です。これはトークンの有効期間であり、秘密鍵を一定時間後に安全な保管場所から出してよいという意味ではありません。
Apple ID認証では、Apple IDの資格情報や、方式によってアプリ用パスワードなどを管理します。fastlaneは認証方法とアプリ用パスワードの説明を公開しています。アプリ用パスワードを、メタデータ管理を含むすべての操作で使える共通認証と見なさず、各アクションの要件を確認してください。
.p8をリポジトリにコミットしないでください。CIの秘密情報として保存し、ログやエラーメッセージに値が出ないことを確認します。担当者の交代時には、誰が鍵を管理しているか、不要になった鍵をどう失効するかも引き継ぎます。
リモートMacで自動公開するなら、どちらを基本にしますか？
対応操作にはAPI Keyを基本として割り当てます。対話的な認証を必要とする処理が残る場合は、Apple IDをその処理に限定し、実行時に再認証が必要かを実環境で確かめます。認証の安定性は「API Keyなら必ず成功する」と判断せず、使用するfastlaneアクションとCIの実行条件で確認します。
04 アップロード後は状態を段階ごとに確かめる
fastlaneの認証成功、バイナリの転送完了、App Store Connectでの処理完了、審査やTestFlightの状態は、それぞれ別の確認項目です。Appleのビルドアップロード手順を参照し、選択したアップロード経路も確認してください。Transporterなどの転送方法と、fastlaneアクションが受け付ける認証方式は同じ判定ではありません。
fastlaneがエラーなく終了すれば、ビルドは公開準備完了ですか？
そうとは限りません。App Store Connectで対象ビルドが表示され、処理状態が完了していることを確認します。その後、TestFlightへの配信や審査提出を行う場合は、それぞれの状態を別に確認してください。認証成功や転送完了だけで、審査通過や配信開始を判断しないでください。
05 公開前の受け入れチェック
認証方式を変えたあとは、次の項目を実行環境で確認します。
- [ ] 実行するfastlaneアクションを洗い出し、API Key対応状況を公式資料で確認した
- [ ] Team KeyまたはIndividual Keyを選び、対象アプリと必要ロールを照合した
- [ ]
.p8、Key ID、Issuer IDをソースコードやログに露出させていない - [ ] Apple IDが必要な処理を特定し、API Keyだけで動くと誤認していない
- [ ] 脱敏したプロジェクトと正式公開ではないタスクで、認証からアップロードまで実行した
- [ ] App Store Connectで対象ビルドの表示と処理状態を確認した
- [ ] TestFlight配信や審査提出を行う場合、それぞれの完了状態を別に確認した
この確認で失敗した箇所を、認証、権限、転送、処理状態に分けて記録してください。問題の層が分かれば、必要以上に権限を広げたり、Apple ID認証を全工程に戻したりせずに修正できます。
すでに使えるMacがあり、公開頻度も低いなら、手元の環境を維持する方法が適しています。一方、継続的にmacOS環境を確保する必要がある場合、自前のMacでは購入費用や保守を負担し、既存の非Mac環境だけでは公開工程に必要なmacOS作業を完結できないことがあります。リモートMacの利用条件を比較したい場合はCALMVPSの料金案内を確認し、必要な期間だけ環境を使う選択肢と購入を比べてください。契約前にはCALMVPSの申込み案内で利用条件を確認し、自分のfastlaneアクション、秘密情報の保管方法、公開後の検証手順に合うか判断してください。