外注先が自社端末で作業し、コードの保存先や署名権限を追いにくいなら、まずアクセス境界を決めてください。
外注iOSチーム向けリモートMacの選定では、企業コードに触れる担当者には個別の遠隔Macを優先し、共有環境は信頼関係と権限分離を確認できる場合に限ります。正式な署名と公開は、開発者のデスクトップ権限から切り離し、企業が管理するCIで実行してください。
この記事が役立つ方
企業IT担当者：外注開発者のmacOS環境を用意し、アクセスと回収を管理したい方。
技術・調達責任者：独立環境、共有Mac、自前端末のどれを採用するか決めたい方。
外注開発の環境を決める前に、作業と権限を分ける
リモート接続の手段を用意するだけでは、企業データの分離や操作記録が保証されるわけではありません。画面共有、SSH、Webコンソールは接続方法であり、誰がどのホストやファイルにアクセスできるかは別途設計が必要です。
判断を誤りやすいポイントは、主に次のとおりです。
- 自前端末では管理範囲が限られる：端末の設定やデータ保存先、契約終了後の消去を企業側で確認しづらい場合があります。
- 共有ホストは自動でチーム分離されない：別アカウントを発行しても、共有ディレクトリや認証情報、管理者権限の範囲によっては他チームのデータへアクセスできる可能性があります。
- Runnerはホスト権限を持ち得る：GitHub Actionsの自ホストRunnerでは、実行するワークフローの安全性や、Runnerに渡す権限を考慮する必要があります。詳しくは自ホストRunnerのセキュリティ上の考慮事項を確認してください。
- 署名できる人が増えると公開管理も複雑になる：コードを閲覧・修正できる権限と、正式な署名や公開を実行できる権限は同じにしないでください。
- 離任時の回収漏れが残りやすい：端末へのログインだけでなく、CIの登録、秘密鍵、作業データ、個別に発行した認証情報まで棚卸しが必要です。
環境の選択肢をプロジェクト条件で比べる
| 選択肢 | 向いている状況 | 企業が管理しやすい点 | 主な注意点 |
|---|---|---|---|
| 外注担当者ごとの独立したリモートMac | 企業コードに触れる、案件が継続する、環境を企業側で渡したい | 接続先と作業環境を担当者単位で管理しやすい | アカウント、ホスト権限、データ保管、終了時の清掃は別途設計が必要 |
| 複数チームで使う共有Mac | 信頼関係が明確で、作業領域と権限を検証できる | 環境をまとめて管理できる | 共有アカウントや共通の秘密情報を置かない。分離をテストしてから利用する |
| 外注担当者の自前端末 | 企業データに触れない限定作業、または企業が端末管理を確認できる | 開発者側の既存環境を利用できる | 端末の状態、保存データ、終了後の回収を企業が統制できるか確認する |
短期案件だから自前端末が常に適切、とは限りません。プロジェクトの期間だけでなく、扱うコードの機密度、環境障害時に誰が支援するか、契約終了時にどこまで証跡を残すかで決めます。
外注チームが並行するなら、共有Macの境界を先に検証する
複数の外注先が同じMacを使う場合、ログイン画面で別ユーザーを選べることだけをもって隔離済みとは判断できません。各チームの信頼範囲と、他チームの情報へ到達できないことを実際の権限で確認します。
GitHub ActionsのRunner Groupsでは、どのリポジトリやワークフローがRunnerを利用できるかを管理できます。ただし、Runner Groupの設定はホスト上のユーザーデータやプロセスを自動的に分離する仕組みではありません。Runner Groupsの利用範囲と設定を確認したうえで、ホスト側のアクセス境界も別に検証してください。
| 確認する境界 | 検証方法 | 不合格なら行うこと |
|---|---|---|
| アカウントと管理権限 | 各チームのアカウントでログインし、不要な管理操作ができないか確認する | 管理者権限を限定し、チーム単位の環境を検討する |
| 作業領域とファイル | 別チームの作業ディレクトリや成果物へ到達できないか確認する | 共有パスや共通アカウントを見直し、環境を分ける |
| 認証情報 | 他案件のトークン、秘密鍵、設定ファイルを参照できないか確認する | 共用領域から認証情報を取り除き、発行・保管を分離する |
| CIの実行範囲 | 対象外のリポジトリからRunnerを使えないか確認する | Runnerの利用許可と登録先を見直す |
共有Macを採用するなら、外注チームごとに別のテスト用アカウントを使い、相互のファイルや認証情報が見えないことを確認してから案件を開始してください。確認できない境界は、運用上の約束ではなく未解決のリスクとして扱います。
未レビューコードの実行と、本番署名・公開を分離する
外部開発者が提出したコードをレビューすること、CIでビルドやテストを行うこと、正式な署名・公開を許可することは、それぞれ異なる信頼レベルの作業です。未レビューのコードを扱う環境に本番用の署名資産を持ち込まず、レビュー後の公開工程を企業側の承認に結び付けます。
GitHubは、自ホストRunnerを利用する場合に、実行されるワークフローやリポジトリの信頼性を考慮するよう案内しています。外部からの変更を処理するRunnerに機密情報を渡す運用は、GitHub Actionsの安全な利用に関する説明に沿って再点検してください。また、自ホストRunnerの管理方法を参照し、登録先や稼働環境の管理責任も明確にします。
| 工程 | 外注担当者に許可する作業 | 企業側で保持する制御 |
|---|---|---|
| コード作成・レビュー | 担当範囲のソースコード閲覧、変更、レビュー提出 | リポジトリのアクセス範囲とレビュー承認 |
| 構築・テスト | 承認済みの範囲でCIを実行し、結果を確認 | Runnerの利用対象、実行権限、ログ確認 |
| 正式署名・公開 | 原則として本番署名資産を直接利用させない | 署名担当、公開承認、実行時の証跡 |
Appleの説明では、コード署名は署名に使う証明書と秘密鍵に関わります。証明書ファイルが存在することと、秘密鍵を使って署名できることを同じ意味で扱わず、コード署名証明書の仕組みと署名および検証の解説を基に、鍵の保管者と署名を承認する担当者を決めてください。
画面共有・SSH・CI成果物は用途別に使い分ける
外注担当者が画面を見ながら設定を相談するなら画面共有、ビルドログやファイルを確認するならSSH、成果物の受け渡しならCIを使うなど、作業に応じて経路を選びます。いずれの接続方法も、それ自体がホスト分離や安全なアクセス範囲を証明するものではありません。
導入時は、次のマイルストーンを順に通過させてください。
- 受け入れ前：対象のリポジトリ、担当者、必要な開発作業、禁止する操作を明記します。
- 環境準備：担当者別アカウント、作業領域、接続方法、CIの利用範囲を用意します。アクセス権の決定を、接続方法の選択だけで済ませないでください。
- アクセス確認：担当者のアカウントで接続し、許可されたリポジトリと作業領域だけを扱えるか確認します。記録すべき操作と確認担当者も決めます。
- CIと署名の分離確認：外注担当者がコード変更とテストを行える一方、本番署名・公開は企業側の承認を経ることを試します。
- 運用・終了確認：問い合わせ時の対応責任を決め、契約終了時にはアカウント、認証情報、作業データ、Runner登録を照合して回収します。
チーム共有の権限管理を詳しく整理する場合は、VMSPINの案内ページで提供内容を確認し、必要な管理条件と照らし合わせてください。契約前には、利用できる環境や条件を実際の案内で確認し、企業側のアクセス設計と混同しないことが重要です。
契約終了ではコード・アカウント・Runnerを照合する
外注先の交代時は、コードの引き継ぎだけで完了とせず、旧担当者が使ったアクセス経路を一覧で照合します。環境の提供元がアカウントやファイルを自動で削除する、と想定せず、企業が確認する項目と実施責任者を決めてください。
離任記録には、担当者と無効化したアカウント、返却・移管したコード、削除または保全した作業データ、認証情報の更新、CI Runnerの登録解除、署名・公開権限の確認を残します。旧アカウントで接続を試し、アクセスできないことを確認すれば、次の外注先へ同じ手順を再利用できます。
外注先の自前端末では、企業が把握しにくい保存データや設定が残る場合があります。共有Macはチーム境界の確認が欠かせず、社内購入では短期案件でも機器の調達・保守を自社で担います。外部開発者向けの環境を一時的に追加するなら、リモートMacのレンタルも比較対象です。まず一つの外注案件で接続、権限、CI、終了時の回収を検証し、条件が合えばVMSPINの利用条件と料金案内を確認して、チーム拡大に進むか判断してください。
よくある質問
外注のiOS開発者に会社のMacを用意するべきですか？
企業コードにアクセスする担当者には、企業側で管理できる独立したリモートMacを優先します。自前端末を使う場合は、コードの機密度だけでなく、データ保存先、端末設定、契約終了時の確認責任を決めてください。企業が管理範囲を確認できないなら、利用可能なリポジトリや作業内容を限定する設計が必要です。
複数の外注チームで一台のMacを使えますか？
信頼関係が明確で、アカウント、作業領域、認証情報、CI利用範囲をチームごとに分け、その境界を実際にテストできる場合に限って検討できます。別アカウントの発行だけでは、ホスト上の分離が確認できたことにはなりません。相互の可視性を検証できなければ、環境自体を分けてください。
外注担当者に署名証明書や秘密鍵を使わせない方法はありますか？
コード閲覧・変更やテストの権限と、正式な署名・公開の権限を分けます。未レビューコードを扱う環境から本番用の署名資産を外し、企業が管理するCIで承認後に公開処理を行う構成にしてください。秘密鍵の保管先、利用を許可する担当者、承認記録を合わせて定めることが大切です。
外注契約が終わった後、何を無効化すればよいですか？
リモートMacのアカウントと認証情報だけでなく、コードや作業データの引き継ぎ、CI Runnerの登録、署名・公開権限も確認します。担当者ごとに実施者と確認者を記録し、旧アクセス経路が使えないことを確かめてください。確認記録を次の外注先の環境準備にも使えば、回収漏れを見つけやすくなります。