Appleの公式仕様では、個人用のApp Store Connect API Keyはユーザー1人につき有効なものを1つだけ保持できます。作成条件と制限を先に確認すると、低頻度で指定Appだけを扱うなら個人用を優先し、無人運用でProvisioning関連などの対象外機能が必要な場合だけ、最小ロールのチーム用キーへ切り替える判断ができます。
この記事を読むべき人
自分でビルドとTestFlightへのアップロードを行い、Apple Accountのログイン情報を自動化へ持ち込みたくない独立開発者向けです。
複数Appの公開権限を分けたい小規模チーム、常駐する遠隔Macでfastlane、Transporter、自作スクリプトを動かす管理者にも適しています。API Keyの作成手順を最初から説明するのではなく、担当者ごとの選択と撤回範囲を決めるためのrunbookとして整理します。
最初に権限の境界を固定する
App Store Connect API Keyは、macOSへのログイン権限やコード署名用の秘密鍵そのものではありません。次の四つを別物として管理しないと、APIキーを撤回したのにビルド環境へ入れる、または証明書を消したのにApp Store Connect側のアクセスは残る、といった誤認が起きます。
- App Store ConnectのAPI権限：App情報、ビルド、TestFlight、提出処理などへの操作権限です。
- Certificates、Identifiers、Profilesの権限：証明書、App ID、Provisioning Profileを扱うための別の能力です。
- 遠隔Macのログイン権限：VNC、SSH、コンソールなど、ホストへ入る入口です。
- コード署名素材：証明書と秘密鍵、Provisioning Profile、キーチェーン内の関連情報です。
個人用キーを選ぶ担当者の条件を確認する
個人開発者が自分のAppを低頻度でArchiveし、アップロードし、TestFlightの配布操作を行うだけなら、まず自分のユーザー権限に紐づく個人用キーを検討します。個人用キーは発行者の権限とAppへのアクセス範囲を引き継ぐため、チーム全体へ広い権限を新設せずに済む可能性があります。
ただし、個人用キーが使えるかはツール名だけで決められません。fastlaneのlane、Transporterの認証方式、自作スクリプトのエンドポイントを一つずつ確認し、証明書やProvisioning Profileの作成・更新まで自動化するなら、個人用キーでは不足する可能性を公式ドキュメントで確認します。
個人用キーには運用上の制約もあります。Appleの作成説明にあるとおり、ユーザーごとに有効な個人用キーは1つなので、開発用MacとCI用Macへ別々の個人キーを同時に発行して切り替える設計には向きません。用途を分けたい場合は、まず実行環境を整理し、それでも分離が必要ならチーム用キーや専用ユーザーを検討します。
小規模チームはロールとApp分離を分けて考える
チーム用API Keyは、チーム内で選択したロールに基づいて動作します。公開担当、日常開発者、リリース自動化の実行主体を分けても、チーム用キー自体を特定のAppだけへ限定することはできません。
ここが、複数Appを持つ小規模チームで最も見落とされやすい制約です。Appごとにチーム用キーを複数作っても、キー単位のApp分離にはなりません。Appの範囲を絞る必要がある工程では、対象Appへ限定できる独立ユーザーに個人用キーを発行できないかを先に評価します。
人員別に選択を確定する決定条件
次の条件を上から確認してください。最初に条件を満たした選択肢を採用し、満たさない場合だけ次の段階へ進みます。
- [ ] 指定したAppのビルド送信とTestFlight操作だけで足りるなら、対象ユーザーの個人用キーを選びます。
- [ ] 個人用キーで必要なエンドポイントを呼べないなら、専用のチーム用キーへ切り替えます。
- ] チーム用キーが必要でも、公開処理だけならAdminを初期値にせず、[ロール別の公式権限一覧で最小ロールを選びます。
- [ ] 複数Appの境界が必須なら、チーム用キーを増やすのではなく、ユーザー単位のアクセス設計を見直します。
- [ ] 外部協力者が対象Appだけを扱うなら、共用キーではなく独立ユーザーを用意します。
- [ ] 誰が撤回を承認するか決められないなら、発行を止め、Account HolderまたはAdminが責任者を記録してから作成します。
権限の評価は「アップロードが成功したか」だけでは不十分です。Appleのビルドアップロード手順に沿って送信し、App Store Connect上で対象ビルドとTestFlightの状態まで確認します。
外部協力者には三つの入口を渡さない
外部開発者が指定AppへTestFlight用ビルドを送るだけなら、チーム共用の長期キーを渡す設計は避けます。対象Appに必要なユーザー範囲を設定し、個人用キーを使える条件ならその方式を優先します。個人用キーで足りない自動化機能がある場合だけ、用途を明記した専用チーム用キーを短期間運用します。
遠隔Macを使う場合は、App Store Connectのユーザー権限、ホストへのログイン、署名素材を別々に付与します。MacへログインできることはApp Store Connectへアクセスできることを意味せず、APIキーを撤回してもSSHやVNCの認証情報、キーチェーン内の証明書が自動で無効になるわけではありません。
契約や作業が終わったら、次の順で引き継ぎ処理を行います。
- App Store Connectのユーザーを削除または権限変更します。
- 使用した個人用またはチーム用キーを撤回します。
- 遠隔Macのアカウント、SSH鍵、VNC資格情報を無効化します。
- 署名証明書、Provisioning Profile、一時配置した秘密鍵を消去します。
- CI設定、環境変数、ログ、キャッシュ、シェル履歴に秘密情報が残っていないか確認します。
継続的インテグレーション管理者は秘密情報を分離する
常駐する遠隔MacでfastlaneやTransporterを動かす場合、「無人実行」という理由だけで最高権限を与えないことが重要です。まずArchive、ビルド送信、TestFlight管理、メタデータ更新、証明書・Profile操作のうち、どこまで自動化するかを確定します。
Key IDとIssuer IDは識別情報であり、秘密鍵本文とは危険度が異なります。秘密鍵はリポジトリ、ビルド成果物、設定ファイルの公開領域、標準出力や失敗ログへ書き込まず、CI実行時だけ保護された環境変数や権限を限定したファイルとして注入します。秘密鍵ファイル名、パス、Bundle ID、Team ID、Key ID、Issuer IDは、手順書やサンプルでは<PRIVATE_KEY_FILE>、<BUNDLE_ID>、<TEAM_ID>のような明確な置換文字列にします。
JWTを使う場合は、AppleのJWT生成仕様に従い、発行時刻、Issuer ID、Key ID、秘密鍵を混同しないようにします。
JWTの有効期限は最大20分です。長時間のビルド全体を1つのトークンだけで覆えるとは限らないため、認証、Archive、アップロード、TestFlight確認の各段階で再認証が必要になる構成もあります。トークンの期限や失敗理由をログへ出す場合も、JWT本文、秘密鍵、完全なAuthorizationヘッダーは必ず伏せます。
遠隔Macで発行前後を検証する
本番Appではなく、影響範囲を管理できるテスト用のBundle IDとリリース手順で検証します。サーバーやMacの設定を先に増やすのではなく、権限不足がどの工程で発生したか分かる粒度で実行してください。
- Apple側でAPIアクセスの利用条件、キーの種類、担当者、ロールを記録します。秘密鍵本文は記録へ貼り付けません。
- Key ID、Issuer ID、秘密鍵ファイルの参照先を別々に設定し、リポジトリへ含まれていないことを確認します。
- fastlane、Transporter、または自作スクリプトで認証だけを実行し、ログが秘密情報を露出しないことを確認します。
- XcodeでArchiveを作成し、署名、Bundle ID、Provisioning ProfileがAPIキーだけで代替されていないことを確認します。
- Apple公式のアップロード手順に従ってテストビルドを送信します。
- App Store Connect上でビルドの表示、TestFlightでの利用可否、必要なコンプライアンス処理を確認します。
- 意図的に旧キーを撤回し、処理が失敗すること、更新後のキーだけで再実行できることを確認します。
よくある判断をFAQで切り分ける
個人用キーを使えるかは、担当者ではなく処理単位で決める
個人開発者が自分のAppだけを扱う場合でも、App Store Connect API Keyの種類だけを見て判断してはいけません。実際のエンドポイント、TestFlight操作、メタデータ更新、Certificates・Identifiers・Profiles関連の処理を分解し、個人用キーで満たせない機能が一つでもあれば、チーム用キーの必要性を再評価します。
「チーム用」はApp単位の隔離を意味しない
小規模チームでプロジェクトごとにチーム用キーを作る方法は、App単位の権限分離にはなりません。Appを限定したいなら、独立ユーザーのアクセス範囲と個人用キーを組み合わせます。それで自動化機能が足りない場合だけ、専用チーム用キーに不足分を集約します。
遠隔MacではホストとApple側の撤回を別々に行う
遠隔Mac上の秘密鍵を消しても、App Store Connect側のキーは自動撤回されません。反対にAPIキーを撤回しても、Macのログインアカウントや署名用キーチェーンは残ります。協力者の終了時には、Apple側、ホスト側、署名素材の三系統を個別に確認します。
料金より先に運用境界を決める
個人用キーは指定Appの低頻度作業と相性がよく、不要なチーム権限を増やさずに済みます。一方、複数Appをまたぐ無人処理や個人用キー非対応のProvisioning関連機能が必要なら、最小ロールの専用チーム用キーが現実的です。ただし、複数のチーム用キーを作ってもApp単位の隔離にはならないため、人数とプロジェクトの境界を先に設計します。
すでにMacを常時稼働させている場合、電源管理、環境更新、ログイン権限、秘密鍵の消去確認を自分で維持する負担が残ります。自宅のMacでは回線断、再起動後の復旧、ディスク不足、外部協力者へのアクセス分離がボトルネックになりやすく、単にAPIキーを正しく作るだけでは継続公開の安定性は確保できません。
発行したチーム用キーを長期の無人公開に使うと判断したなら、MACGPUのMacレンタル案内で、独立した管理権限、秘密情報の注入方法、常時稼働、環境復旧の条件を確認してください。さらに、MシリーズMacを使う構成や新しいビルド環境への移行条件を確認したい場合は、Macの構成選びに関する案内も判断材料になります。
自前のMacを長期に固定運用したい場合や物理USB機器が必須の場合は購入が適しますが、発行周期が不定期で、隔離された遠隔Macを必要な期間だけ使うなら、MACGPUのレンタルを選択肢に入れる方が管理対象を増やさずに済みます。