macOS 27が他アプリのデータへのアクセスをブロック：何が壊れ、どう直すか

macOS 27は確認なしに他アプリのデータへのアクセスをデフォルトで拒否し、検疫属性が付いたLaunchAgentsの読み込みを停止する。何が壊れるか、アクセスを許可する方法、そして許可すべきでない場合を解説する。

macOS Sonoma以降、あるアプリが別のアプリの非公開データを読み取ろうとすると、確認ダイアログが表示されていました：「"App"は他のアプリのデータへのアクセスを求めています」。許可するか拒否するかを選べたので、何が壊れても理由がわかりました。macOS 27 Golden Gateはこのダイアログを廃止します。アクセスはデフォルトで、確認なしに拒否されるようになりました。データを求めたアプリは空の結果を受け取るか、「Operation not permitted」エラーになるだけです。機能がひっそりと動かなくなって初めて気づくことになります。

同じリリースにある3つの関連する変更は、すべて同じ方向を指しています：XProtectはマルウェアがよく盗むデータへのアクセスをブロックできるようになり、アプリはプライバシーデータベースを直接読み取れなくなり、launchdは検疫フラグが付いたプロパティリストの読み込みを拒否するようになりました。このガイドでは、Apple自身のリリースノートの文言を使ってそれぞれを説明し、自分のMacで何が影響を受けるかを確認する方法を示し、必要なときに意図的にアクセスを許可する方法——そしてそうすべきでないとき——を解説します。

要点まとめ

確認ダイアログはもう出ない。 macOS 27では、他の開発者のアプリデータコンテナやアプリグループコンテナへのアクセスは「デフォルトで拒否」され、プライバシーとセキュリティ設定で管理されます。Appleのリリースノートはこれをシステム整合性保護（System Integrity Protection）の項目に挙げています。
コマンドラインツールは厄介なケース。 Appleは既知の問題として、バンドルIDを持たないプロセスには特定アプリのデータへのアクセスを許可できないと記載しています。文書化された回避策は、「その要件が必要な間だけ」フルディスクアクセスを付与することです。
XProtectが「よく狙われる」データを新たに保護。 Appleは対象リストを公開していないため、これまで問題なく読み取れていたツールでも、一部のアプリデータへのアクセスが拒否されることを想定しておくべきです。
アプリはもうTCCプライバシーデータベースを直接読み取れない。 権限を報告するためにTCC.dbを検査していたスクリプトやツールは、別の方法が必要です。
検疫済みのLaunchAgentsは読み込まれなくなる。 検証したMacでは、~/Library/LaunchAgents内の20個のエージェントのうち9個に検疫属性が付いており、いずれもサードパーティ製ブラウザ3種のアップデーターエージェントでした。

何が変わったのか：確認ダイアログからデフォルト拒否へ

Appleはこの領域を段階的に強化してきました。

リリース	他の開発者のアプリデータへのアクセス
macOS 13 Ventura以前	自分のアカウントで動く任意のプロセスにほぼ開放されていた
macOS 14 Sonoma	保護対象になり、「他のアプリのデータ」へのアクセスを許可するか確認ダイアログが表示される
macOS 15 Sequoia	保護がアプリグループコンテナにも拡張された
macOS 27 Golden Gate	デフォルトで拒否、確認ダイアログなし。プライバシーとセキュリティ設定で管理

macOS 27のリリースノート、システム整合性保護のセクションにある文言は次の通りです。

他の開発者チームのアプリデータコンテナおよびアプリグループコンテナ内のファイルへのアクセスは、ユーザーに認可を求めるプロンプトを表示しなくなりました。こうしたアクセスはデフォルトで拒否され、ユーザーがプライバシーとセキュリティ設定で管理できます。

この一文の中の2つの言葉が、影響を受けるかどうかを左右します。開発者チーム：このルールは異なる開発者のアプリ同士に関するものです。同じ開発者が作った一連のアプリは、同じチームで署名されているため、引き続きグループコンテナを共有できます。コンテナ：このルールが対象とするのは、アプリがLibrary内に保持するサンドボックス化されたデータフォルダです。Documentsフォルダ、デスクトップ、あるいは自分で保存したファイルは対象外です——これらは独自の「ファイルとフォルダ」権限を持っており、今回のような変更はされていません。

「他のアプリのデータ」とは何を指すのか

サンドボックス化されたアプリは、非公開のファイルをホームフォルダ内の2箇所に保持します。

~/Library/Containers/ — サンドボックス化されたアプリごとに1つのフォルダがあり、バンドルIDで名前が付けられ、アプリの実データはData/以下にあります
~/Library/Group Containers/ — 同じ開発者の複数アプリで共有されるフォルダで、group.…という名前か、開発者のチームIDを先頭に付けた名前になっています

フォルダ名を一覧表示するだけなら無害で、規模感がわかります。今回使用したMac（まだTahoe 26.5.2で稼働中）では次の通りでした。

ls ~/Library/Containers | wc -l                    # 956
ls ~/Library/Group\ Containers | wc -l             # 187
ls ~/Library/Group\ Containers | grep -vc '^group\.'   # 70 named with a team ID

つまりアプリコンテナが956個、グループコンテナが187個あり、そのすべてが、異なる開発者のアプリからはデフォルトで立ち入り禁止になったということです。ほとんどの場合は問題ありません——行儀の良いアプリが他のアプリのデータベースを読み取る理由などないからです。問題になるのは、あなたのために正当な理由でそれを読み取っていたツールのほうです。

実際に壊れるとどう見えるか

この失敗にはダイアログが伴わないため、症状として現れます。よくあるものは次の通りです。

症状	考えられる原因
`~/Library/Containers/…/Data`や`~/Library/Group Containers/`配下のパスでTerminalに`ls: … : Operation not permitted`と出る	シェルの責任元アプリ（Terminal、iTerm、使用中のIDE）にそのアプリのデータへのアクセス権がない
バックアップ・同期・エクスポートツールがあるアプリのデータをスキップする、または「permission denied」と報告する	そのツールにそのコンテナを読み取る許可がない
インポーターが他のアプリから何もインポートするものを見つけられない	静かに拒否されており、インポーターには空、または存在しないフォルダに見えている
ランチャー、クリップボード、自動化ツールが、他のアプリのデータを読んでいた機能を失う	同じ拒否が、結果が返らないという形で表面化している
`cron`や`launchd`が実行するスクリプトが、昨日まで読めていたパスで失敗する	バンドルIDを持たないコマンドラインプロセス——下記の既知の問題を参照

「Operation not permitted」（EPERM）は、macOSのプライバシー制御がファイルアクセスをブロックしたときに返る標準的なエラーです。ファイルが存在しないという意味ではありませんし、sudoを使えば解決するという意味でもありません——プライバシー保護はroot権限にも適用されます。

正しい方法でアクセスを許可する

Appleはこの制御をシステム設定 → プライバシーとセキュリティに置いており、後述の既知の問題は特にファイルとフォルダペインを指しています。他のアプリのデータへのアクセスは、一度きりの確認ダイアログではなく、ここでアプリごとに許可するようになりました。

通常のアプリの場合

システム設定 → プライバシーとセキュリティ → ファイルとフォルダを開きます。
アクセスが必要なアプリを見つけて展開します。
広い範囲のアクセスではなく、そのアプリが必要とする具体的なデータだけを許可します。

macOS 27でのこのペインの正確なレイアウトは、Tahoeのものとは異なる可能性があります。Appleのノートが説明しているのはアクセスがどこで管理されるかであって、クリックごとの手順ではありません。どちらにしても原則は同じです：機能が動くために必要な、最も狭いアクセスだけを許可することです。

アプリ自身のドキュメントが代わりにフルディスクアクセスを付与するよう指示している場合、それでも機能します——フルディスクアクセスはアプリデータコンテナもカバーします。ただしMail、Messages、Safariのデータを含め、ホームフォルダ内の他のすべてもカバーしてしまうため、ディスクを読むこと自体が仕事であるツール——バックアップソフトやディスク解析ツールなど——のために取っておきましょう。

スクリプト、`cron`ジョブ、コマンドラインツールの場合

ここでAppleは既知の問題を挙げています。

ファイルとフォルダペインでは、バンドルIDを持たないプロセスに、他の開発者チームが所有する特定のアプリデータコンテナやアプリグループコンテナへのアクセスを許可することはできません。

回避策：そのアクセスが本当に必要かどうかを検討してください。必要な場合は、その要件が必要な間だけプロセスにフルディスクアクセスを付与してください。

「バンドルIDを持たないプロセス」とは、単なる実行ファイル全般を指します：Pythonインタプリタ、launchdが実行するシェルスクリプト、Homebrewでインストールされたバイナリ、cronが起動するデーモンなどです。重要なのは、それがどう起動されるかです。

Terminalから実行する場合、プライバシー上の判定はTerminal（あるいはiTerm、使用中のIDE）に紐づけられ、これらは確かにバンドルIDを持っています。そのアプリにアクセスを許可すれば、通常はその中で実行するコマンドもカバーされます。
launchdやcronから実行する場合、紐づけ先となるアプリが存在しません。プロセス自体に権限が必要で、既知の問題の記述に従えば、それはそのバイナリへのフルディスクアクセスを意味します。

コマンドラインのバイナリをフルディスクアクセスに追加するには、フルディスクアクセスのリストで**＋をクリックし、⌘⇧G**を押してパス（例えば/opt/homebrew/bin/python3や/usr/sbin/cron）を貼り付け、追加します。Appleの言い回し——「その要件が必要な間だけ」——は文字通り受け取る価値があります。その作業のために許可し、終わったら取り消してください。フルディスクアクセスを持つインタプリタは、それが実行するすべてのスクリプトにそのアクセスを与えてしまいます。

1つのツールに、単一アプリのデータフォルダへの狭いアクセスを許可する権限パネル

XProtectによる保護層

同じセクションにあるもう一つの注記は、誰がアクセスを求めているかに依存しない保護層を追加します。

XProtectは、悪意のあるソフトウェアによってよく標的にされるアプリデータへのアクセスを制限する場合があります。他の開発者チームのアプリが作成したファイルへのアクセスはデフォルトで拒否される場合がありますが、ユーザーがプライバシーとセキュリティ設定で管理できます。

Appleは、どのデータが「よく標的にされる」に該当するかを明らかにしていません。Mac向けの情報窃取マルウェアが何を狙うかは、セキュリティ研究者によって十分に文書化されています：保存されたパスワードやCookieを含むブラウザプロファイル、暗号資産ウォレットのデータ、メッセージングアプリのセッションファイルなどです。XProtectのリストがこれらと大きく重なっているというのは妥当な推測ですが、あくまで推測にすぎません。

実際にどう影響するかというと、例えば他のアプリのセッションやプロファイルデータを正当な理由で読み取るツールが、正しく見える権限を付与した後でも、macOS 27上で拒否される場合があるということです。そうなったら、まずプライバシーとセキュリティで保留中の項目がないか確認してください。何もなければ、そのツールの開発者にmacOS 27でテスト済みかどうか尋ねる価値があります——修正は開発者側で行う必要があるかもしれません。

アプリはもうプライバシーデータベースを読み取れない

TCC（Transparency, Consent and Control）データベースは、カメラ、マイク、画面収録、ファイルなどへのアクセスをどのアプリに許可したかを記録しています。ユーザーごとのコピーは~/Library/Application Support/com.apple.TCC/TCC.dbにあります。長年、フルディスクアクセスを持つツールはこれを直接読み取って権限を報告できました。

macOS 27のリリースノート、TCCの非推奨項目には次のようにあります。

アプリはもうローカルのTCCデータベースに直接アクセスできません。

Tahoeの時点でも、読み取るにはフルディスクアクセスが必要です。それを持たないシェルからでは、検証用Macで次のようになりました。

sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db "select service from access limit 1"
# Error: unable to open database ".../com.apple.TCC/TCC.db": authorization denied

macOS 27では、この直接のルートはアプリ一般に対して閉じられます。影響を受けるのは次のような人たちです。

コンプライアンススクリプトや資産管理用の拡張機能でTCC.dbに問い合わせて権限を報告していたMac管理者。サポートされている方法は、データベースではなく、デバイス管理ツールのプライバシー設定ポリシー制御（PPPC）レポート機能です。
ファイルを読み取って「どのアプリがどの権限を持っているか」を表示していたユーティリティ。
自分がすでに何にアクセスできるかを調べるためにデータベースを読み取っていたマルウェア。これがこの変更の理由です。

自分のMacについては、権限を確認したり取り消したりする場所として、引き続きシステム設定 → プライバシーとセキュリティが使えます。各カテゴリーに、その権限を持つアプリが一覧表示されます。

もう一つの静かな変更：検疫済みLaunchAgents

この変更はアプリデータに関するものではありませんが、壊れ方は同じ——静かに——であり、この記事で扱う中では検証用Macに最も大きく影響していました。リリースノート、Launch DaemonsおよびAgentsの項目には次のようにあります。

launchdは、検疫（quarantine）拡張属性が付いたlaunchdプロパティリストファイルの読み込みを、もうサポートしません。

LaunchAgentとは、~/Library/LaunchAgentsにある小さな.plistファイルで、ログイン時やスケジュールに従ってプログラム（アップデーター、同期用ヘルパー、メニューバーツールなど）を起動するようlaunchdに指示するものです。検疫属性（com.apple.quarantine）は、インターネット経由で届いたファイルや、それ自体が検疫ルールの対象であるアプリが作成したファイルに、macOSが付与するフラグです。

確認はループ1つで済みます。

for f in ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist /Library/LaunchDaemons/*.plist; do
  xattr "$f" 2>/dev/null | grep -q com.apple.quarantine && echo "QUARANTINED  $f"
done

検証用Macでは次の結果でした。

フォルダ	プロパティリスト数	検疫済み
`~/Library/LaunchAgents`	20	9
`/Library/LaunchAgents`	8	0
`/Library/LaunchDaemons`	27	0

検疫済みだった9個のファイルはすべてアップデーターエージェントで——それぞれ3個ずつ——サードパーティ製のChromiumベースブラウザ3種によって作成されたものでした。検疫の値の3番目のフィールドには、そのファイルを作成したアプリの名前が入っています。

xattr -p com.apple.quarantine ~/Library/LaunchAgents/some.agent.plist
# 0081;<timestamp>;<name of the app that wrote it>;<id>

そのうち少なくとも1つは、現在Tahoe上で読み込まれ稼働しています。Appleの注記に従えば、macOS 27ではこれらのエージェントは読み込まれなくなるため、これらのブラウザのバックグラウンドアップデーターは静かに止まることになります。Golden Gate自体でこれを確認できたわけではありませんし、ベンダー側がすでにエージェントの作り方を変更している可能性もあります。しかしこれはまさに、何カ月も気づかれないタイプの不具合です：目に見える形では何も失敗せず、ブラウザがただ自己更新をやめるだけなのです。

検疫済みエージェントを修正する

まずアプリを更新する。 ベンダーがすでに修正していれば、新しいバージョンがこの属性なしでエージェントを書き直します。
手動で直さざるを得ない場合は、信用する前に中身を確認する。 何を実行するのか確認します。

plutil -p ~/Library/LaunchAgents/some.agent.plist          # look at Program / ProgramArguments
codesign -dv --verbose=2 "/path/to/the/program" 2>&1 | grep -E "Authority|TeamIdentifier"

プログラムが想定通りのものである場合に限り、属性を削除してエージェントを再読み込みします。

xattr -d com.apple.quarantine ~/Library/LaunchAgents/some.agent.plist
launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/some.agent.plist 2>/dev/null
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/some.agent.plist

見覚えのないエージェントから検疫属性を取り除かないでください。LaunchAgentsを使った永続化は古典的なマルウェアの手口であり、この変更はダウンロードされた.plistが静かに自分自身をインストールするのを止めるために設計されています。見覚えのない検疫済みエージェントは、再読み込みする理由ではなく、調査する理由です。ログイン項目とバックグラウンドアプリのガイドでは、エージェントをそれをインストールしたアプリまで遡って追跡する方法を解説しています。

検疫フラグによって一部のランチ項目が保留されているバックグラウンドタスク一覧

アップグレードの前後にできる5分間の点検

何が変わりそうかをTahoeで確認するか、すでに何が変わったかをmacOS 27で確認するために、次を実行してください。

# 1. How much app data is now guarded by default
ls ~/Library/Containers | wc -l
ls ~/Library/Group\ Containers | wc -l

# 2. Scheduled jobs that may read other apps' data
crontab -l 2>/dev/null
ls ~/Library/LaunchAgents

# 3. Quarantined launch items that will stop loading
for f in ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist /Library/LaunchDaemons/*.plist; do
  xattr "$f" 2>/dev/null | grep -q com.apple.quarantine && echo "QUARANTINED  $f"
done

# 4. Scripts that read the privacy database directly
grep -rl "TCC.db" ~/bin ~/scripts ~/.local/bin 2>/dev/null

手順4のフォルダは、実際にスクリプトを置いている場所に合わせて調整してください。ヒットしたものそれぞれについて、Appleの回避策が投げかけているのと同じ問いを自分にも投げかけてください：このアクセスは本当に必要か？

アクセスを許可すべきでないとき

この変更が存在するのは、「自分のアカウントで動く任意のプロセスが、任意のアプリのデータを読み取れる」という状態こそが、Mac向け情報窃取マルウェアが主に依存していたものだったからです。機能を取り戻すためにアクセスを許可する前に、いくつかのルールが役立ちます。

狭い許可を優先する。 フルディスクアクセスより、ファイルとフォルダでのアプリ単位のアクセスを。ターミナルアプリ全体へのフルディスクアクセスより、1つのバイナリへのフルディスクアクセスを。
コマンドラインへの許可は一時的にする。 Apple自身の言い回しは「その要件が必要な間だけ」です。削除するためのリマインダーをカレンダーに入れておきましょう。
新しい要求には疑いを持つ。 先月まで他のアプリのデータを読む理由がなかったアプリが、今月になってフルディスクアクセスを求めてきたら、よく確認する価値があります。
信頼していないWebページからコピーした権限付与コマンドを、絶対に貼り付けて実行しない。 ユーザーをそそのかしてTerminalコマンドを実行させるソーシャルエンジニアリングは、まさにこうした保護機能を回避する手口であり、Terminalのペースト型マルウェア警告に関する記事で解説しています。

よくある問題のトラブルシューティング

sudoを使っても「Operation not permitted」になる

問題：sudo ls ~/Library/Containers/…/Dataを実行してもまだ失敗する。

解決策：プライバシー保護はUnixのパーミッションの問題ではなく、root権限もその対象です。プライバシーとセキュリティで、責任元のアプリ——Terminal、あるいはそのコマンドを起動したアプリ——にアクセスを許可してください。

`launchd`のジョブは失敗するのに、同じコマンドがTerminalでは動く

問題：スケジュール実行されるスクリプトが、手動で実行すると他のアプリのデータを問題なく読み取れるのに、スケジュール実行では失敗する。

解決策：Terminalでは、アクセスはTerminalに紐づけられます。launchdの下では紐づけ先となるアプリが存在せず、Appleの既知の問題によれば、バンドルIDを持たないプロセスはアプリ単位のアクセスを得られません。そのジョブが実行する具体的なバイナリにフルディスクアクセスを付与し、ジョブが不要になったら取り消してください。

バックアップツールが一部のアプリデータを静かにスキップした

問題：バックアップは完了したが、あるアプリのコンテナがバックアップ内に存在しないか空になっている。

解決策：バックアップアプリにフルディスクアクセスを付与してください——これはその正当な用途の一つです——そして再度実行します。ツールのログで権限エラーを確認してください。ほとんどのツールは、バックアップが「成功」した場合でもエラーを記録しています。

アップグレード後、エラーもなくアプリの機能が失われた

問題：インポート、同期、検索の機能が何も返さなくなった。

解決策：プライバシーとセキュリティで許可できる項目がないか確認し、ベンダーのリリースノートでmacOS 27への対応状況を確認してください。求めているデータがXProtectの保護対象の種類であれば、修正は開発者側で行う必要があるかもしれません。

バックグラウンドのアップデーターが更新を止めた

問題：アップグレード以降、あるアプリの自動更新が静かに止まっている。

解決策：上記のループを使って、そのLaunchAgentに検疫属性が付いていないか確認してください。まずアプリを手動で更新しましょう——それが最も定着しやすい対処法です。

FAQ

macOS 27は「他のアプリのデータへのアクセス」の確認ダイアログを廃止したのか？

はい。Appleのリリースノートには、そうしたアクセスは「ユーザーに認可を求めるプロンプトを表示しなくなった」とあり、「デフォルトで拒否される」と書かれています。発生時にダイアログへ答える代わりに、プライバシーとセキュリティ設定で管理します。

同じ開発者のアプリ同士には影響するのか？

いいえ。このルールは「他の開発者チーム」に適用されるものです。同じ開発者チームで署名されたアプリは、引き続きグループコンテナを通じてデータを共有できます。これが、関連する一連のアプリが動き続ける仕組みです。

フルディスクアクセスでまだ十分なのか？

コマンドラインの既知の問題に対するApple自身の回避策によれば、十分です——フルディスクアクセスはアプリデータコンテナへのアクセスを付与します。よく標的にされるデータに対するXProtectの新しい制限は、Appleが別のものとして説明している部分であり、一部のデータには依然として適用される可能性があります。

なぜスクリプトはもうTCC.dbを読み取れないのか？

AppleのmacOS 27ノートには、アプリはもうローカルのTCCデータベースに直接アクセスできないと明記されています。権限を確認するにはシステム設定を使い、管理者であればデバイス管理ツールのレポート機能を使ってください。

LaunchAgentから検疫属性を削除しても安全か？

それが何を実行するのかを確認し、そのプログラムが想定している開発者によって署名されていることを確認できた場合に限ります。検疫属性を削除することはまさにマルウェアがユーザーにしてほしいことであり、だからこそmacOS 27はそもそも検疫済みエージェントの読み込みを止めたのです。

まとめ

これらmacOS 27の変更に共通するテーマは一貫しています：あるアプリに属するデータは、両方が同じアカウントで動いているというだけの理由では、もう他のアプリから利用できません。また、インターネットからダウンロードされたファイルは、正しいフォルダに置かれたというだけの理由では、もうバックグラウンドプロセスに変わりません。ほとんどの人にとってこれは明確な利益です。なぜならそれこそが、Mac向け情報窃取マルウェアが依存していたアクセスだからです。

その代償は、告知されることのない不具合です。スクリプト、バックアップツール、インポーター、さらにはブラウザのアップデーターまでもが、静かに動かなくなることがあります。5分間の点検を実行し、ツールが本当に必要とする場合にだけ狭く一時的にアクセスを許可し、アップグレード後に何かが静かになったら、何よりもまずプライバシーとセキュリティを確認してください。

関連ツール: Mac 互換性チェッカー - お使いの Mac が特定の macOS バージョンに対応しているか確認できます。