macOS 27 Platform SSO：共有リモートMacのローカルアカウントを廃止すべきか？2026

最終更新：2026年8月23日。AppleのmacOS向けPlatform SSOの公式展開資料とWWDC26の認証連携資料を確認しています。なお、資料内の一部機能は正式版まで変更される可能性があるプレビュー扱いです。

症状： 共有リモートMacのローカルアカウントを一括廃止し、SSOだけで運用したくなる。
最短解法： 全廃止ではなく、臨時利用者はAuthenticated Guest Mode、固定メンバーは受管ローカルアカウント、CIと緊急管理者は専用アカウントに分けます。

この記事は、外注担当者や輪番開発者が使う共有Macを管理する企業IT担当者、iOS CI/CDノードを運用するプラットフォーム担当者、FileVaultと離職時のアクセス回収を監査するセキュリティ担当者向けです。個人用Macのログイン設定や、単独開発者向けのSSO入門は対象外です。

4種類のIDを同じモデルで管理しない

macOS 27 Platform SSOは、組織のIdP認証とmacOSログインを統合するための基盤です。しかし、組織IDを連携できることと、すべてのローカルIDを削除できることは同じではありません。AppleのPlatform SSO展開ガイドでも、認証方式、管理サービス、SSO拡張の組み合わせが前提になっています。

Platform SSOで扱えるのは、ログイン、パスワード同期、認証ポリシー、IdPグループとの連携などです。root権限、署名鍵、Keychainの内容、ビルド成果物、遠隔再起動、復旧時の認証経路は別の管理対象として残ります。

臨時利用者と固定メンバーで残すデータが違う

Authenticated Guest Modeは「使い捨て作業」に限定する

Authenticated Guest Modeは、共有リモートMacへ臨時利用者を組織のIdPで入場させ、セッション終了後のローカルユーザーデータを残しにくくする用途に向いています。外注作業、輪番対応、短期の動作確認など、作業後に個人の開発環境を保存しないケースが候補です。

一方、ログアウト時にアプリのキャッシュ、外付けストレージの内容、ネットワーク上のリポジトリや成果物まで消えるとは限りません。消去対象はAppleのデバイス管理構成に関する資料と実機の検証結果を突き合わせてください。

次の条件を満たさない場合は、ゲスト方式を採用しない方が安全です。

• セッション終了後に作業データを保存する必要がある
• XcodeやSDKの個人設定を継続して使う
• オフライン時にも同じ利用者がログインする必要がある
• 外部ストレージや別のビルド領域にデータが残る
• 誰が、いつ、どのIdPグループで入ったかを記録できない

固定メンバーには永続ワークスペースが必要

固定メンバーは、按分して作成するローカルアカウント、管理サービスが事前に用意する受管アカウント、Platform SSOで認証する組織IDを組み合わせます。Platform SSOで退職者の認証を止めても、ローカルディスクのデータ移管、SSH鍵、Keychain、個別の管理者権限が自動的に整理されるわけではありません。

最低限、アカウントのライフサイクルを次の証拠で追えるようにします。

• 作成：端末識別子、申請者、IdPグループ、作成日時
• 認可：標準ユーザーか管理者か、sudoやroot相当の範囲
• 変更：所属変更、端末変更、権限変更の履歴
• 停用：IdP無効化、ローカルアカウント処理、トークン失効
• 移管：ホームディレクトリ、署名関連データ、成果物の保管先

共有Macの権限設計をさらに細かく確認する場合は、チーム向けMacアカウント管理の考え方も併読してください。Platform SSOは認証の入口を統一できますが、端末内に残るデータの所有者までは決めません。

CIサービスアカウントと緊急管理者を分離する

無人ビルドは開発者のSSOセッションを使わない

Jenkins、GitHub Actions、GitLab RunnerなどのCIジョブが、開発者のPlatform SSOセッションや一時ゲストディレクトリに依存すると、ログアウト、トークン失効、再起動のたびにビルドが止まります。さらに、開発者のリポジトリアクセス権や署名資格情報が、無人ジョブへ過剰に広がる危険があります。

CI用には、目的ごとに専用アカウントとKeychainを割り当てます。コード取得用トークン、App Store関連の資格情報、署名証明書、プロビジョニング情報は、対話型ユーザーのホームディレクトリに置かないでください。

判断は次の条件で行います。

• 人が画面操作する作業はPlatform SSO側で管理する
• 無人ジョブは専用サービスアカウントで実行する
• 署名と配布に必要な資格情報だけをCIへ渡す
• 再起動後にジョブが復旧するかを確認する
• ノードを共有する場合は、ジョブ間のワークスペース消去を検証する

Macを打ち合わせ用の共有端末とCIノードで兼用する構成では、ビルド資格情報の露出範囲が広がります。長時間稼働するiOSビルド用途では、ベアメタルと仮想化macOSの違いを確認し、対話型利用とビルド専用ノードを分けられるか検討してください。

障害時のbreak-glassは後門ではなく復旧手順にする

IdP、DNS、プロキシ、SSO拡張のいずれかが停止すると、ログイン画面やFileVault解除前の認証に影響する可能性があります。AppleはmacOS 27のPlatform SSO更新で、Web認証、Touch ID方針、ログイン画面のネットワーク機能、Authenticated Guest ModeとFileVaultの連携を示していますが、導入可否は管理サービスとIdP拡張の対応状況に依存します。Appleの認証連携更新で、正式機能かプレビュー機能かを確認してください。

注意：FileVaultに対応しているという記述だけで、すべての再起動障害から自動復旧できるとは判断しないでください。ログイン前ネットワーク、復旧鍵、遠隔コンソール、管理者用の別経路を一つずつ実機で確認します。

break-glassアカウントは、日常管理者や管理サービスが作成する管理アカウントと分離します。保管担当者を限定し、利用時のアラート、チケット番号、操作ログ、終了後の認証情報ローテーション、事後レビューを必須にしてください。オフライン時の認証猶予やローカルアカウントの例外は、AppleのPlatform SSOプレビュー資料に記載された範囲を超えて一般化しないことが重要です。

監査担当者は3つのノード池で放量を判断する

共有リモートMacを増やす前に、環境提供者または社内運用チームへ次を確認してください。

• 端末が監視対象・管理対象として登録されているか
• Apple Silicon上で対象のSSO拡張が動作するか
• FileVault解除前にIdPへ到達できるか
• 遠隔再起動後も管理サービスへ戻れるか
• 復旧鍵の保管者と復旧テストの記録があるか
• セッション終了後のユーザーデータ清除範囲が証跡化されているか
• root権限、SSH、VNC、管理者権限の境界が契約と運用記録に一致しているか

判断は、次の3つのノード池に分けると曖昧になりません。

• 臨時利用者池：Authenticated Guest Modeを基本とし、ログアウト後の清除結果を確認します。
• 固定利用者池：永続ローカルアカウント、IdPグループ、個人ワークスペースの移管手順を管理します。
• CIノード池：サービスアカウント、署名資格情報、ジョブ間隔離、再起動復旧を専用基準で検証します。

固定利用者とCIの同時実行でCPU、メモリ、ディスクI/O、ログイン待ちが競合するなら、単一MacへIDを追加し続けるより独立ノードを増やす方が監査しやすくなります。Mac miniを打ち合わせ用とビルド用に分ける案を検討する場合は、Mac miniのレンタル構成ガイドで、必要な作業を固定ワークスペースと無人処理に切り分けてください。

FAQ：導入前に役割ごとに確認すること

macOS 27 Platform SSOだけでローカルアカウントをなくせますか？

全面的な廃止は推奨しません。Platform SSOは組織の認証情報とmacOSのログインを連携する仕組みですが、固定メンバーの永続ワークスペース、CIの秘密情報、障害時の緊急復旧まで自動的に置き換えるものではありません。臨時利用者だけAuthenticated Guest Modeを評価し、ほかの役割は分離して管理します。

共有Macで臨時利用者のデータをログアウト後に消すには何を確認しますか？

Authenticated Guest Modeを使う場合は、ログアウト後にローカルユーザーデータが保持されない設計かを確認します。ただし、アプリケーションキャッシュ、外部ストレージ、ネットワーク側の作業データまで自動消去されるとは限りません。対象範囲を実機で確認し、消去ログと再ログイン後の初期状態を記録してください。

FileVaultの解除前にPlatform SSOが必要とする接続条件は何ですか？

ログイン前に認証サービスへ到達できるネットワーク経路が必要になる場合があります。管理サービス、IdP、SSO拡張が対応していても、データセンター側の経路、DNS、プロキシ、再起動後の接続可否は別に検証が必要です。オフライン時の猶予やローカル認証の扱いも、Appleの現行資料と実機で確認します。

CIサービスアカウントもPlatform SSOへ統合すべきですか？

開発者の対話型ログインをそのままCIへ流用する設計は避けてください。Jenkins、GitHub Actions、GitLab Runnerなどのジョブには、専用のサービスアカウント、Keychain、リポジトリアクセストークン、署名用資格情報を割り当てます。Platform SSOは人のアクセス管理に使い、無人実行の権限境界や再起動復旧は別に設計します。

IdPへ接続できないリモートMacに緊急ログインする方法はありますか？

障害時だけ有効化するbreak-glassアカウントを、通常の管理者アカウントとは分けて用意します。認証情報は限定された担当者が保管し、使用時のアラート、利用理由、作業内容、終了後のパスワード変更とレビューを必須にします。SSOを恒久的に回避するアカウントとして残さないことが重要です。

自社購入のMacだけでこの設計を組む場合、端末ごとの初期登録、FileVault復旧、故障交換、リモート再起動、アカウント消去の証跡を自社で持ち続ける必要があります。共有端末へ臨時利用者、固定メンバー、CIを詰め込むほど、認証障害時の切り分けと資格情報の隔離も難しくなります。

まず臨時利用者数、固定開発者数、CIの同時実行数、IdPと管理サービスの制約を整理してください。そのうえで、MacDateのレンタル環境を候補にするなら、独立ノードの有無、root権限の範囲、ログイン方式、遠隔復旧、環境リセットの記録を確認し、コストだけでなく監査可能性を比較するのが適切です。