症状：外注開発者にMacを渡すため、Appleの主アカウントや公開用の署名鍵まで共有しようとしている。
最短解：独立した本人用IDを作り、作業単位で必要な権限だけ付与します。公開用の認証情報を分離できない場合は、署名と正式アップロードをプロジェクト側に残してください。
独立開発者：コード修正やビルドを委託したいものの、Appleアカウントや公開資格情報は渡したくない方。
小規模チームの責任者：リモートMac、リポジトリ、App Store Connectのアクセスを個別に管理し、終了後の撤回まで確認したい方。
外注プロジェクトの技術責任者：作業範囲と成果物を事前に決め、個人の開発環境とチーム共有環境を混同したくない方。
開工前に作業と権限の境界を決める
コード変更、構築・テスト、署名、正式公開は別々の作業です。外注先にすべてを任せる前提にせず、担当者と必要な資源を作業ごとに割り当てます。
| 作業 | 必要な資源の例 | 権限を持つ担当 | 完了確認 |
|---|---|---|---|
| ソースコードの修正 | 対象リポジトリ、必要なブランチ | 外注開発者 | 対象外リポジトリへアクセスできない |
| ビルド・テスト | 対象プロジェクトのMac環境 | 外注開発者 | 指定した構築・テストを実行できる |
| 署名済み成果物の受け渡し | 受け渡し先、成果物の確認手順 | 外注開発者とプロジェクト側 | 成果物の場所と受領者を記録する |
| 正式な提出・公開 | App Store Connect、公開用の認証情報 | 原則としてプロジェクト側 | プロジェクト側のアカウントで状態を確認する |
Apple Developer Programのアカウント種別によって、追加したユーザーが利用できるチーム資源は同じではありません。個人アカウントに追加したApp Store Connectユーザーと、組織チームのメンバーを同一の権限として扱わず、Appleのアカウント種別と役割の説明で対象チームの条件を確認してください。
外注開発者にApple Developerアカウントを渡す必要がありますか？
所有者のApple Accountを共有する必要はありません。各自の識別できるアカウントを使い、必要な場合だけ適切なチームやApp Store Connectへのアクセスを付与します。役割名だけで可能な操作を推測せず、Appleの役割とアクセス範囲を作業内容と照合してください。
担当表には、誰が許可したか、何のためのアクセスか、何をもって確認するか、いつ無効にするかも書きます。担当者の変更、契約終了、端末紛失時に誰が停止処理を行うのかを決めておけば、口頭の約束だけでアクセスが残る事態を避けられます。
初回接続では本人別のIDと期限を設定する
リモートMac、コードリポジトリ、Apple関連のチーム権限は別々に管理します。Macにログインできることは、リポジトリやApp Store Connectにもアクセスできることを意味しません。その逆も同じです。
リモートMacに外注担当者専用のアカウントを作れますか？
主アカウントを使い回すのではなく、担当者を識別できる個別のログインを用意する方法を優先します。ただし、macOSアカウントを分けただけで、署名鍵やすべての秘密情報が隔離されるとは限りません。実際のホスト設定と保存場所を確認してから、アクセス範囲を決めてください。
| 資源 | 付与前に記録する項目 | 確認する証拠 |
|---|---|---|
| リモートMac | 対象アカウント、許可する作業、失効条件 | ログインアカウント一覧、接続方法 |
| コードリポジトリ | 対象プロジェクト、必要な操作範囲 | メンバー一覧、アクセス設定 |
| App Store Connect | ユーザーの役割、対象Appの範囲 | ユーザー一覧、Appアクセス設定 |
| APIキー・署名資産 | 利用目的、保管者、撤回担当 | キー管理記録、保管・撤回手順 |
GitHubを使う場合は、組織への所属と個別リポジトリへのアクセスを分けて確認します。リポジトリごとの権限はGitHubの組織リポジトリに対するアクセス管理に沿って設定し、作業対象外のコードが見えないかも確かめてください。
接続の案内は本人別に送り、所有者のパスワード、秘密鍵、完全なトークンを送らないでください。接続記録には利用者、対象ホスト、付与日、停止担当者を残します。アクセスを許可した証拠が残らない場合は、作業開始前に設定を見直します。
認証情報や画面記録を共有する必要がある場合は、アカウント名、ホスト名、リポジトリ名、Bundle ID、Team ID、Key IDを伏せてください。秘密鍵や完全なトークンは、スクリーンショットやログにも含めない運用にします。
初回ビルドで必要な範囲だけ通るか検証する
いきなり本番公開を依頼せず、指定プロジェクトを取得し、合意した構築またはテストを実行する低リスクの作業で確認します。協力者が作業できることに加えて、別プロジェクトやシステム管理設定へ不要にアクセスできないことも確認対象です。
App Store Connectでは、ユーザーの役割とAppへのアクセス範囲を分けて見ます。アカウントを追加しただけで「必要なAppだけに限定された」と判断しないでください。AppleのAppアクセス設定を確認し、対象Appの範囲が意図どおりか、プロジェクト側のアカウントで照合します。
Apple Developerチームへの参加とApp Store Connectの役割は同じですか？
同じものとして扱わないでください。Developer Programのチーム資源、App Store Connectのユーザー役割、個別Appへのアクセスはそれぞれ確認する項目です。担当者が「ログインできた」と報告しただけでは、必要な範囲に限定できた証明になりません。
この段階で記録するのは、許可した人、対象資源、許可の目的、確認した証拠、失効条件です。想定外のプロジェクトが見える、または管理権限まで必要と言われた場合は、その理由を確認するまで範囲を広げないでください。
公開前に署名と正式提出の担当を分ける
外注開発者に依頼する範囲は、ソースコードの修正、開発用ビルド、署名済み成果物の受け渡し、正式アップロードに分けて決めます。公開用の証明書や秘密鍵、APIキーを通常のプロジェクトファイルとして共有するのは避け、必要性と保管方法を先に確認してください。
公開用の署名証明書に触れさせずにビルドを依頼できますか？
依頼できます。開発者が実装と構築まで行い、プロジェクト側が管理する環境で署名や正式提出を行う形を検討してください。ビルド後の成果物の形式や受け渡し方法は、使うワークフローに合わせて事前に合意します。資格情報を分離できない場合は、署名と提出をプロジェクト側に残すのが安全側の判断です。
App Store Connect APIキーが必要な場合は、キーの種類、許可する操作、保管者、撤回担当を確認します。Appleの説明では、チームAPIキーと個人APIキーはアクセス範囲が異なります。作成前にAPIキーの作成条件を読み、利用目的に合うものを選んでください。
また、AppleはAPIキーを撤回できる一方、撤回後のキーは復元できないと説明しています。運用中の提出処理に影響する可能性を確認せず、本番公開の直前に一律で取り消さないでください。App Store Connect APIのキー管理と撤回手順を確認し、代替キーや処理の切り替えが必要か判断します。
協力開始前に引き渡しを演習する
本作業の前に、低リスクのタスクで「接続、コード取得、構築、成果物の受け渡し、アクセス停止」を一通り試します。成功条件は、外注担当者が約束した作業を完了できることと、未許可の資源にアクセスできないことの両方です。
- [ ] 担当者本人のIDでリモートMacへ接続できる
- [ ] 合意したリポジトリだけを取得できる
- [ ] 指定したビルドまたはテストを実行できる
- [ ] 成果物の保存先と受領者を双方で確認できる
- [ ] App Store Connectの役割と対象Appが合意どおりである
- [ ] 署名資産やAPIキーの保管者と撤回担当者が明確である
- [ ] 停止後に以前の接続方法やアカウントで入れないことを確認できる
接続方法、成果物の置き場所、資格情報の管理者、緊急時の停止連絡先を引き継ぎ記録にまとめます。ログインが一度成功しただけでは、権限設計の合格にはなりません。
契約終了時に全経路を撤回して確認する
終了後はMacのログインアカウントだけでなく、リモート接続方法、リポジトリの協力者、App Store Connectユーザー、APIキー、プロジェクト内の一時資格情報を個別に点検します。ひとつのアカウントを削除しても、別の経路でアクセスが残っている可能性があります。
外注作業が終わったら、どのアクセスを停止しますか？
事前に記録した資源を一つずつ照合し、プロジェクト側のアカウントからメンバー一覧と有効な接続方法を確認します。必要なビルド成果物と引き継ぎ記録を保存してから、不要なアクセスを停止してください。共有済みの認証情報や利用範囲が不明なキーがあれば、影響を調べてから公式手順で交換・撤回します。
最終確認では、協力者側の報告だけでなく、プロジェクト側から旧アクセスが無効になったことを確かめます。停止できた証拠、残す成果物、撤回した資格情報を記録すれば、後任者への引き継ぎにも使えます。
個人所有のMacを共有する方法は、購入費用を抑えられる一方で、私用環境と業務データが混ざりやすく、空き容量や常時稼働の確保、担当者ごとの権限整理にも手間がかかります。専用機の購入を検討する場合は、Mac miniの注文案内も参考にし、自前の実機が必要な運用かを見極めてください。すでに専用のMac環境があり、長期的に安定した重い処理や物理接続が必要なら、自前の実機が適する場合もあります。
外注期間だけ独立したmacOS環境が必要なら、プロジェクト側でアカウント分離、アクセス方法、撤回手順を確認したうえで、MACCOMEのリモートMac案内を選択肢として確認できます。利用条件や構成を確認し、作業終了後に誰がどの権限を回収するかまで合意できる場合に限り、レンタル環境を協力者の開発・構築に使うか判断してください。