Mac が画面収録の許可を何度も求めてくる：本当に効く対処法
Mac が画面収録の許可を繰り返し要求する、あるいは許可済みのはずの権限が効かなくなる。macOS の TCC の実際の仕組みと、両方の症状の直し方を解説します。
Zoom を開いて画面共有をクリックすると、先月見たのとまったく同じダイアログが表示され、Zoom に画面を収録させてよいかと macOS が尋ねてきます。もう「はい」と答えたはずです。システム設定を開いてみると、確かにありました。Zoom は「画面とシステムオーディオの収録」のリストに入っていて、スイッチもオンになっています。壊れているところはどこにもありません。それでも、また尋ねられたのです。
一週間後、今度は別のことが起こります。バックアップツールが Mail フォルダを読み取れません。フルディスクアクセスを確認すると、アプリはちゃんとリストにあり、オンになっていて、あるべき姿そのままです。それなのにアプリは権限をまったく持っていないかのように振る舞います。同じような気持ちにさせられますが、これは先ほどとは別の問題です。
世の中で見つかるアドバイスのほとんどは、この 2 つの状況を一つのものとして扱っています。だからこそ、そのアドバイスの多くが機能しないのです。1 つ目は意図的な設計です。Apple は画面キャプチャの権限に定期的な再確認を組み込んでおり、それをオフにするスイッチは存在しません。2 つ目は本物の不具合で、特定可能な明確な原因があります。そしてその原因はほぼ必ず一つに行き着きます。ディスク上のアプリが、あなたが権限を与えたアプリと同一であると macOS がもはや認識していない、ということです。
この記事では両者を切り分け、その下にあるサブシステムを説明し、それぞれに対する正しい対処法を示します。さらに、このテーマで最もよく見かけるアドバイス、つまり chmod でファイル権限を変更するとか、何らかのアクセス権修復を実行するといった助言が、なぜ関係するシステムとまったく無関係なのかも説明します。以下で示した内容はすべて、macOS 26.5.2、ビルド 25F84、System Integrity Protection 有効の Mac で検証しています。
この記事の要点
- 見た目が同じ 2 つの異なる問題がある — 画面キャプチャの定期的な再確認は仕様であり無効化できないが、許可済みなのに機能しない権限は明確な原因のある本物の不具合。
- TCC は権限をアプリのパスではなくコード署名 ID に紐付ける — アップデート後、アプリを移動した後、あるいは同じアプリのコピーがディスク上に 2 つ存在するときに、権限が黙って効かなくなるのはこのため。
- Apple が提供するコマンドは
tccutil resetだけ — Terminal から権限を付与する方法は存在せず、バンドル識別子を付けずにresetを実行すると、その権限が Mac 上のすべてのアプリから消える。 - プライバシーデータベースは
lsすら通らない — SIP が有効な検証機で TCC のどちらのディレクトリを一覧表示してもOperation not permittedが返る。これは通常のファイル権限ではないことの何よりの証拠。 - Apple はサービス名の一覧を公開していない —
ScreenCaptureやSystemPolicyAllFilesといった名前はコミュニティの知見であり、これを公式ドキュメントとして提示しているガイドは推測で書いている。
TCC とは何か、そして何ではないか
アプリが画面を収録してよいか、Mail フォルダを読んでよいか、マイクを使ってよいか、他のアプリを制御してよいかを判断するサブシステムは TCC と呼ばれます。頭文字は Transparency, Consent and Control（透明性、同意、制御）を表します。これまであなたがクリックしてきた「"App" が…にアクセスしようとしています」というダイアログをすべて生み出しているのがこれであり、システム設定のプライバシーとセキュリティ配下のすべてのリストを埋めているのもこれです。
この領域における唯一のコマンドラインツールについて、Apple の man ページは 1 文でこう説明しています。NAME には「tccutil – manage the privacy database」とあり、DESCRIPTION ではそれをこう展開しています。「The tccutil command manages the privacy database, which stores decisions the user has made about whether apps may access personal data.」
この文言は正確で、システム全体の形を教えてくれるので、注意して読んでください。TCC が保存しているのは 判断 です。それは同意の記録です。ファイルの説明ではなく、アプリケーションと保護対象データのカテゴリとの 関係 の説明なのです。
プライバシーデータベースはファイルシステムではない
これは他のどんな誤解よりも多くの時間を浪費させる勘違いなので、真っ先に片付けておく価値があります。
従来の Unix ファイル権限は、ファイル自体に保存された属性です。所有者、グループ、読み書き実行のビットがあり、chmod や chown で変更します。それが答えるのは「どのユーザーアカウントがこのファイルに触れてよいか」という問いです。
TCC はまったく別の問いに答えます。「どの アプリケーション に、このカテゴリのデータを読むことをユーザーが同意したか」です。主語はユーザーアカウントではありません。アプリケーションです。The Eclectic Light Company の Howard Oakley は 2025 年 11 月のアクセス権とプライバシーに関する解説記事で、この違いをうまく言い表しています。「privacy protection operates outside of file attributes, using a rule-based system applied to each app.（プライバシー保護はファイル属性の外側で動作し、アプリごとに適用されるルールベースのシステムを使う）」
実務上の帰結は絶対的です。あなたのユーザーアカウントはすでに ~/Library/Mail を所有していて、POSIX ビットもあなたが読んでよいと言っています。だからこそ、あなたとして実行したターミナルのコマンドはそれを読めるのに、あなたとして実行した GUI アプリは読めないのです。ファイル権限は最初から障害ではありませんでした。障害は TCC です。
したがって、どれだけ chmod を打っても TCC の問題は直りません。「アクセス権を修復する」たぐいの処理も同様です。あれは APFS 以前の時代にレシートデータベースに対して行われていた概念で、Apple は何年も前にディスクユーティリティから削除しています。画面収録のプロンプトを止めたい一心でホームフォルダ全体に sudo chmod -R 755 を実行しても効果はなく、Library フォルダを壊す可能性があります。やらないでください。
一覧表示すらできないデータベース
TCC のデータベースは 2 つあります。ユーザーごとのものは ~/Library/Application Support/com.apple.TCC/ にあり、あなたのアカウントに適用される判断を保持します。システム全体のものは /Library/Application Support/com.apple.TCC/ にあり、管理者や MDM プロファイルが設定できるものを含め、マシン全体に適用される判断を保持します。
議論に決着をつける実証がこれです。SIP が有効な検証機で、次の 2 つを試しました。
ls ~/Library/Application\ Support/com.apple.TCC/
ls /Library/Application\ Support/com.apple.TCC/どちらも Operation not permitted を返しました。POSIX の失敗で出る「permission denied」ではなく、System Integrity Protection がアクセスを完全に遮断したときにカーネルが返す応答です。SIP が有効であることも確認済みで、csrutil status は System Integrity Protection status: enabled. を返しました。
これらのディレクトリを一覧表示することも、中のデータベースを読むことも、編集することもできません。TCC.db を SQLite ブラウザで開いて行を挿入せよと書いているガイドがあれば、それは SIP を無効にしたマシンの話です。そして権限ダイアログを回避するために SIP を無効にするのは、ダイアログボックス一つを解決するために Mac の防御アーキテクチャの大部分を差し出す行為です。この記事ではそのやり方は説明しません。
できる のは、システム設定の画面から権限を付与すること、tccutil で判断をリセットすること、MDM プロファイルに判断を書き込ませることです。扉はこの 3 つだけです。4 つ目はありません。
なぜこの設計なのか
もし TCC の判断が普通の編集可能なファイルに置かれていたら、ホームフォルダへの書き込み権限を持つあらゆるアプリが、自分自身に画面収録権限、カメラアクセス、Mail フォルダの自由な閲覧を黙って与えられてしまいます。保護は無価値になります。そこで Apple は判断を SIP の背後に置き、唯一サポートされる書き込み経路をシステムが描画するダイアログへのユーザー操作に限定し、コマンドラインツールには動詞をちょうど 1 つ、reset だけ与えたのです。
これは筋の通った設計です。そして、夜 11 時に壊れた権限を直そうとしている人間から見れば、極めて小さな道具箱でもあります。この記事の大部分は、その道具箱をうまく使うための話です。macOS が Gatekeeper、公証、SIP、TCC をどう積み重ねているかという広い文脈については、macOS Tahoe のセキュリティとプライバシー完全ガイドで周辺のアーキテクチャを扱っています。
2 つの異なる問題
ここから、この記事の残りが依拠する切り分けに入ります。
問題その 1：意図的な再確認プロンプト
2024 年の macOS 15 Sequoia ベータ期間中に、Apple は画面とオーディオのキャプチャに対する定期的な再確認を導入しました。画面をキャプチャするアプリはすべて、一定の周期で再確認を求められ、オプトアウトの手段はありません。
ベータ初期の挙動は週次で、しかも再起動のたびに再確認を求めるものでした。これには相当な批判が集まりました。MacRumors は 2024 年 8 月に「popups for screen recording app permissions have been showing weekly up throughout the beta testing process, but Apple has tweaked the frequency in response to user feedback（画面収録のアプリ権限ポップアップはベータテスト期間を通じて週次で表示されてきたが、Apple はユーザーからのフィードバックを受けて頻度を調整した）」と報じ、ベータが月次の再承認に変更されたと伝えました。9to5Mac と iDownloadBlog も同じベータでの同じ変更を報じています。再起動ごとのプロンプトも同時に廃止されました。ダイアログには「1 か月間許可」ボタンとシステム設定を開くオプションがあり、MacRumors は当時「it does not appear that there is a way for users to permanently give screen recording access to recording functionality, but a monthly popup is at least more convenient than a weekly popup.（ユーザーが収録機能に画面収録アクセスを恒久的に与える方法はないようだが、月次のポップアップは少なくとも週次よりは便利だ）」と述べています。
ここからは正直に書きます。macOS 26 世代における現在の周期は、どの権威ある情報源からも確認できませんでした。 このペインに関する Apple 自身のサポートページ、macOS Tahoe 26 の Mac ユーザガイドにある「アプリに画面とオーディオの収録を許可する」は、ペインの開き方とダイアログへの答え方を説明しているだけで、定期的な再承認については一言も触れていません。macOS 26 について論じている二次情報源は互いに矛盾しており、週次の再確認と書くものもあれば月次と書くものもあり、どれも出典を示していません。
そこで、自信を持って言えることと言えないことを整理します。確認済み： 定期的な再確認は Sequoia のサイクルで導入され、画面とシステムオーディオのキャプチャに適用され、1 か月の許可を提示し、ユーザー側にオフスイッチはありません。確認済み： このペインに関する Apple の現行サポートドキュメントは、この件にまったく触れていません。未確認： macOS 26 世代における正確な間隔。もしあなたの Mac がおおよそ月に一度再確認してくるなら、それは Apple が Sequoia で出荷した挙動と一致します。もっとずっと頻繁にプロンプトが出るなら、以下の不具合診断を読んでください。頻繁な再確認は別の問題です。
問題その 1 について知っておくべき最も有用なことは、これは不具合ではなく、直すべきものは何もない ということです。「許可」をクリックするのに 1 秒しかかかりませんし、ダイアログそのものが再確認なので、システム設定で何かを切り替え直す必要はありません。月次のプロンプトに対してリセットや再インストール、何かの編集を勧めるガイドはすべて、健康な患者に薬を売っているのです。
開発者側の例外が 1 つあります。Apple には com.apple.developer.persistent-content-capture というエンタイトルメントがあり、繰り返しのプロンプトを抑制します。Michael Tsai のブログが 2024 年 8 月にこれをめぐる開発者の議論をまとめています。これはリモートコントロールや VNC 系のアプリケーションを対象とした管理型の機能で、開発者が Apple に申請して付与される必要があります。ユーザーが有効化することはできません。これは、ごく一部のリモートアクセスアプリが決してうるさく尋ねてこない理由を説明するだけのものです。
問題その 2：定着しない許可
こちらは本物の不具合です。症状としては、ペインに載っていてオンになっているのに権限がまったくないかのように振る舞うアプリ、アップデート後にペインから消えるアプリ、終了して再起動するまでは動く権限、同じアプリ名の 2 つのエントリ、+ で追加してもペインに現れないツール、月に一度ではなく起動のたびに出るプロンプトなどです。
これらにはすべて原因があり、その多くは単一の原因を共有しています。それが次の大きなセクションです。
このリストに含まれそうに見えて実は 含まれない ものが 1 つあります。ログインキーチェーンのパスワードを繰り返し求めてくる Mac です。それはキーチェーンのサブシステムであって TCC ではなく、この記事のどの内容も解決しません。それがあなたの症状なら、ログインキーチェーンのパスワード要求の対処法が正しい範囲をカバーしています。
あなたはどちらの問題か
| 症状 | どちらの問題か | 対処 |
|---|---|---|
| 画面キャプチャのプロンプトがおおよそ月に一度、「許可」をクリックすればアプリは動く | 仕様 | 「許可」をクリック。異常はありません。 |
| 起動のたびにプロンプトが出る | 不具合 | 署名 ID または重複コピーの問題。以下を参照。 |
| ペインでオンなのにアプリが動作しない | 不具合 | 古い ID に紐付いた陳腐なエントリ。クリーンな再付与を。 |
| アップデート後にアプリがペインから消えた | 不具合 | 署名が変わった。再付与を。 |
| ペインに同じ名前のエントリが 2 つある | 不具合 | ディスク上にコピーが 2 つ。見つけて 1 つ削除。 |
| CLI ツールは動くがペインに一度も現れない | 既知の macOS 26.1 の不具合 | コマンドラインのセクションを参照。 |
| プロンプトが出て「許可」を押しても何も起きない | 不具合 | アプリが完全に終了していないことが多い。クリーンな再付与を。 |
| プロファイルの注記付きでスイッチがグレーアウト | 管理対象の Mac | 端末を管理している担当者に連絡。 |
| キャプチャ以外の権限が毎月再確認してくる | 不具合 | 定期的な再確認があるのは画面キャプチャだけ。 |
macOS 26 世代で各権限がある場所
これらのペインはすべて同じ場所の配下にあります。システム設定を開き、サイドバーでプライバシーとセキュリティをクリックし、カテゴリを選びます。この記事に関係するカテゴリは以下のとおりです。
- 画面とシステムオーディオの収録。 macOS 26 世代で名称変更されました。以前は画面収録でした。Apple の説明は 1 行です。「Allow apps to record your screen and audio, or just your audio. The listed apps have access.（アプリに画面とオーディオ、またはオーディオのみの収録を許可します。リストにあるアプリがアクセスできます）」
- フルディスクアクセス。 システム全体にわたる保護されたユーザーデータ。Mail、メッセージ、Safari のデータ、Time Machine バックアップ、他アプリのコンテナフォルダなどです。
- アクセシビリティ。 あなたの Mac を制御する能力。ポインタを動かす、クリックする、ウインドウの内容を読む、他のアプリケーションのインターフェイスを操作するといったことです。
- オートメーション。 ある特定のアプリが別の特定のアプリに Apple イベントを送る権利です。フラットなリストではなくペアとして構成されている唯一のペインです。
- ファイルとフォルダ。 きめ細かなフォルダアクセス。デスクトップ、書類、ダウンロード、リムーバブルおよびネットワークボリュームなど。フルディスクアクセスを持つアプリはここに項目を必要としません。
- 入力監視。 アプリが最前面にないときでもキー入力を見られるようにします。
- カメラ と マイク。 名前のとおりです。特にマイクの調子がおかしい場合、入力権限の連鎖には独自の癖があり、macOS Tahoe 26.5 で Mac のマイクが動かなくなったときの対処のガイドで扱っています。
- ローカルネットワーク。 比較的新しく、混乱の元になりがちです。ローカルネットワークの権限がブロックされると、プライバシーの問題にはまるで見えない症状が出るためです。応答しなくなったプリンタが典型例で、AirPrint とローカルネットワークのプライバシー問題の解決法で順を追って説明しています。
後で効いてくる構造的な事実が 2 つあります。あなたが見ているリストはデータベースの レンダリング であり、後述する macOS 26.1 の不具合は、データベースが正しくてもレンダリングが誤りうることを証明しました。もう 1 つ、- ボタンでエントリを削除すると、アプリを拒否するのではなく判断そのものが削除されるため、次にアプリが尋ねてきたときには新しいプロンプトが出ます。この違いこそがクリーンな再付与手順の土台です。
許可済みの権限が効かなくなる理由
仕組みはこうです。この 1 点さえ理解すれば、この領域の紛らわしい挙動のほとんどが予測可能になります。
TCC はパスや名前ではなくコード署名 ID に紐付く
アプリに権限を与えるとき、macOS は「/Applications/Foo.app にあるファイルは画面を収録してよい」とは記録しません。記録するのはアプリの コード署名 ID、つまりその識別子と、誰が署名したかを記述する暗号学的な要件に紐付いた判断です。Apple のテクニカルノート TN3127「Inside Code Signing: Requirements」が、その要件がどう構成されるかの参照資料です。
その帰結が、誰も教えてくれないことです。署名 ID が変わると、macOS はそのアプリを、何も付与されたことのない別のアプリケーションとして扱います。 古いエントリはペインに残り、許可されているように見えたまま、データベースが記憶している形ではもはや存在しないアプリを指し示します。あなたにはオンになったスイッチが見えます。システムには見知らぬ他人が見えています。
アプリの ID は自分で確認できます。検証機での例です。
codesign -dv --verbose=2 /System/Applications/Utilities/Terminal.app出力には、システムが使うバンドル識別子である Identifier 行（Terminal なら com.apple.Terminal）、署名した証明書を示す Authority 行の連なり、そして TeamIdentifier 行が含まれます。Apple 自身の同梱アプリでは TeamIdentifier は not set と表示されます。Apple はサードパーティ開発者とは異なる認証局チェーンでシステムソフトウェアに署名しているためです。サードパーティ製アプリなら、10 文字のチーム識別子と Developer ID 証明書を含む認証局チェーンが見えるはずです。
このチーム識別子が安定したアンカーです。チーム識別子を持たないアドホック署名のアプリは、コードハッシュだけで識別されます。そしてコードハッシュはビルドのたびに変わります。Developer ID で署名されたアプリは、アップデートを越えて維持される安定したチーム ID を持ちます。一部のアプリがアップデートのたびに再確認してきて、大半のアプリがそうならないのはこのためです。
では、個別のケースを見ていきます。
ケース 1：アプリがアップデートされ、署名が変わった
アプリが新しいバージョンを出しました。新しいビルドが別の証明書で署名された、開発者がアドホック署名から Developer ID に移行した、あるいはその逆、または証明書の期限が切れて新しいもので再署名した、といったことが起きています。
見分け方： タイミングがアップデートとぴったり一致し、アプリはペインから消えたか、2 つ目のエントリが増えています。
対処： 陳腐なエントリを削除して再付与します。他にすることはありません。TCC から見れば、そのアプリは本当に新しいアプリだからです。
ケース 2：同じアプリのコピーがディスク上に 2 つある
これが「オンなのに動かない」症状の最も一般的な原因であり、最も見落としやすいものです。
アプリをダウンロードし、~/Downloads から一度実行して権限を与え、その後 /Applications にドラッグした。あるいは、すでに 1 つ持っているところに Homebrew Cask がコピーをインストールした。あるいは、/Applications にリリースビルド、~/Applications にベータを置いている。ペインにはアプリの名前とアイコンの行が 1 つ表示されますが、その行がどちらのコピーを指しているかは教えてくれません。あなたは ~/Downloads のコピーに対する許可を見ながら、/Applications のコピーを起動しているのです。
見分け方： ディスク上のすべてのコピーを探します。
mdfind "kMDItemKind == 'Application'" -name "AppName"または、Spotlight がインデックスしていないかもしれないコピーも含めて洗い出すなら、
find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null複数のパスが返ってきたら、それが答えです。
対処： 不要なコピーを削除し、ちょうど 1 つだけ残してから、残った方でクリーンな再付与を行います。削除を省略しないでください。2 つ目のコピーをディスクに残せば、1 か月後にまた同じ場所に戻ってくることになります。
ケース 3：許可後にアプリが移動された
ケース 2 と関連しますが別物です。コピーは 1 つしかないのに、それが移動しました。署名要件の書かれ方や、埋め込みヘルパーのパスが親の構造に焼き込まれているかどうかによって、これを問題なく乗り切るアプリもあれば、乗り切れないアプリもあります。
見分け方： 動いていたアプリが、アプリケーションフォルダを整理したり移行から復元したりした後に壊れた。
対処： 新しい場所でクリーンな再付与を行います。/Applications の中のサブフォルダに移動したのなら、まずトップレベルに戻してみてください。自己アップデート機構を持つ一部のアプリはサブフォルダで挙動が悪くなります。
ケース 4：不完全なアップデートが署名を無効にした
アップデートが中断された、同期ツールがバンドルに触れた、アンチウイルス製品が中のファイルを隔離して復元した、バックアップからの復元がバンドルを不完全に再構成した。署名がもはや検証を通りません。
見分け方：
codesign --verify --deep --strict --verbose=2 /Applications/AppName.app健全なバンドルなら、ディスク上で有効であり指定された要件を満たしている旨で終わる短いレポートが出ます。破損している場合は、失敗した特定のファイル名が示されます。ここで失敗が出たなら、権限をいじっても何の役にも立ちません。macOS がそのバンドルをまったく信頼しないからです。
対処： 開発者のオリジナルのダウンロードから再インストールします。これは「アプリを再インストールする」が肩をすくめる代わりではなく本当に正しい答えである数少ないケースの 1 つです。同じ根本的な破損がより目に見える形で現れるのが「アプリが壊れているため開けません」というダイアログで、Gatekeeper と検疫属性の対処ガイドで詳しく扱っています。
ケース 5：自分のバンドルを置き換える Sparkle 系の自己アップデータ
App Store 外で配布される Mac アプリの多くは、Sparkle フレームワークやそれに類する仕組みで自分自身をアップデートします。新しいバージョンをダウンロードし、実行中に自分のバンドルをその場で入れ替えるのです。
これが正しく動けば、新しいバンドルは同じチーム識別子を持ち、TCC は引き続きそれを認識します。うまくいかない場合、つまりアップデートが異なる署名で行われた、入れ替えの結果バンドルが書きかけで残った、アプリがわずかに違うパスに自分を置き換えた、といった場合には、次に保護された機能を使ったときに再確認プロンプトが出るか、黙って失敗します。
見分け方： アプリが App Store 外で自己アップデートしており、権限の問題がアップデートの瞬間の周辺に集中している。
対処： アップデート完了後にクリーンな再付与を行います。毎回のアップデートで起きるなら、開発者の署名設定に問題があり、開発者側で修正可能なので報告する価値があります。
一般的な診断手順
「許可済みなのに動かない」ケースに直面したら、次の 3 つの問いをこの順に立ててください。このアプリのコピーはディスク上にいくつあるか（mdfind）、バンドルは検証を通るか（codesign --verify）、アップデート直後に壊れたか。この 3 つの答えは、ほぼ毎回、上記 5 つのケースのいずれかを指し示します。
Terminal のツール：tccutil にできることとできないこと
このサブシステム向けのコマンドラインツールはちょうど 1 つだけで、その能力は多くのガイドが匂わせているよりはるかに狭いものです。
reset が唯一のコマンド
macOS 26.5.2 で引数なしに tccutil を実行すると、使用方法の文字列が表示されます。
tccutil: Usage: tccutil reset SERVICE [BUNDLE_ID]これがインターフェイスのすべてです。Apple の man ページは「one command is currently supported（現在サポートされているコマンドは 1 つ）」と明言し、こう説明しています。
reset Reset all decisions for the specified service, causing apps to prompt again the next time they access the service. If a bundle identifier is specified, the service will be reset for that bundle only.
man ページにある Apple 自身の例は tccutil reset AddressBook と tccutil reset All com.apple.Terminal です。
ほとんどのガイドが飛ばす帰結を引き出しましょう。付与コマンドは存在しません。 Terminal から権限を承認することはできません。reset は判断を忘れさせてアプリが再度尋ねるようにするだけで、あなたの代わりに「はい」と言うものではありません。「はい」と言える方法は、システム設定の画面と MDM の構成プロファイルだけです。フルディスクアクセスを付与する tccutil の呪文を主張するガイドを見つけたら、それは間違いです。
最も重要なバンドル ID の警告
これは Terminal セクション全体の実務的な核心なので、独立した項目を割きます。
# DANGEROUS - resets screen recording for EVERY app on the Mac
tccutil reset ScreenCapture
# Correct - resets it for one app only
tccutil reset ScreenCapture com.example.appnameバンドル識別子は構文上は省略可能ですが、実務上は必須です。省略すれば、そのマシン上のすべての画面収録の判断を忘れるよう macOS に指示したことになります。Zoom、Slack、Discord、Teams、スクリーンショットツール、収録ソフト、リモートサポートのクライアント。次に使うときにそのすべてがプロンプトを出します。恒久的に壊れるものはありませんが、アプリ 1 つを直そうとして自分のためにダイアログボックスだらけの午後を作り出したわけです。
バンドル識別子なしの tccutil reset All はさらに悪く、すべてのアプリのすべてのサービスのすべての判断を忘れます。ガイドがそれを最初の手順として勧めているなら、そのガイドは閉じてください。
必ずバンドル識別子を付けてください。 例外なく、毎回です。
引数の検証順序と、それがタイプミスを隠す理由
これは直接検証した挙動で、エラーの読み方に影響します。tccutil は サービス名よりも先にバンドル識別子を検証します。でたらめなサービスとでたらめなバンドル ID を一緒に渡すと、
tccutil reset ZZZNotAService com.example.nonexistent.zzzこう返ってきます。
tccutil: No such bundle identifier "com.example.nonexistent.zzz": The operation couldn't be completed. (OSStatus error -10814.)明らかに不正なサービス名ではなく、バンドルについて文句を言っています。バンドル ID なしででたらめなサービスを渡すと、
tccutil reset ZZZNotAServiceこう返ります。
tccutil: Failed to reset ZZZNotAService実務上の帰結はこうです。バンドル識別子のタイプミスは常に明快で具体的なエラーを返します。これは良いことです。しかし サービス名 のタイプミスは、バンドル識別子も間違っている場合には隠れてしまいます。ツールがそこまで到達せず、文句を言えないからです。-10814 エラーが出たら、まずバンドル識別子を直し、それからコマンドを再実行して、サービス名も間違っていなかったか確認してください。
そこから導かれる系はこうです。コマンドを組み立てる前にバンドル識別子を確認すること。
アプリのバンドル識別子を調べる方法
信頼できる方法が 2 つあります。1 つ目は検証機で確認済みで、osascript -e 'id of app "Terminal"' は com.apple.Terminal を、osascript -e 'id of app "Safari"' は com.apple.Safari を返しました。
osascript -e 'id of app "AppName"'Finder に表示されるとおりのアプリ名に置き換えてください。これが最も手早い方法で、Howard Oakley のプライバシー保護の概説記事のコメント欄で読者が挙げ、本人も認めた方法です。
2 つ目の方法はバンドルを直接読むもので、アプリが標準的な場所にない場合や AppleScript が名前を解決できない場合に有用です。
defaults read /Applications/AppName.app/Contents/Info.plist CFBundleIdentifierあるいは、署名機関も同時に見られるコード署名のビューを使い、その Identifier= 行を読みます。
codesign -dv --verbose=2 /Applications/AppName.app好きなものを使ってかまいませんが、いずれかは必ず使ってください。アプリ名から識別子を推測してはいけません。逆引き DNS 形式の命名は慣習であってルールではなく、推測とはまったく似ても似つかない識別子を持つアプリはいくらでもあります。
サービス名は Apple のドキュメントではなくコミュニティの知見
ここは網羅性よりも誠実さが重要な箇所です。
Apple は tccutil reset が受け付けるサービス名の一覧を公開していません。 man ページが例として挙げているのはちょうど 2 つ、AddressBook と All です。これがこの件に関する Apple のドキュメントのすべてです。
流通している名前はコミュニティ由来です。Howard Oakley は 2025 年 3 月のプライバシー保護の概説記事で、次のようなものを含む一覧を公開しました。
Accessibility、AddressBook、All、AppleEvents、AudioCapture、BluetoothAlways、Calendar、Camera、ContactsFull、ContactsLimited、DeveloperTool、FocusStatus、MediaLibrary、Microphone、Motion、Photos、PostEvent、Reminders、RemoteDesktop、ScreenCapture、SpeechRecognition、SystemPolicyAllFiles、SystemPolicyDesktopFolder、SystemPolicyDocumentsFolder、SystemPolicyDownloadsFolder、SystemPolicyNetworkVolumes、SystemPolicyRemovableVolumes。
このうち 2 つが、この記事が最も関心を寄せるペインに対応します。画面とシステムオーディオの収録は ScreenCapture、フルディスクアクセスは SystemPolicyAllFiles です。
検証機でこれらの名前を総当たりで試すことは、意図的にしませんでした。tccutil reset が 成功 すればマシンの実際の権限が消えるので、名前が有効だと確認する唯一の方法は、守ろうとしていたものを破壊することです。そして失敗する名前を試しても何も分かりません。上記の一覧は出典のしっかりしたコミュニティの知見であり、現場の実務者が使っているものと一致します。しかしそれは Apple のドキュメントではなく、権威あるものとして提示するくらいなら、そう明言しておきたいのです。
そこから 2 つのことが導かれます。tccutil reset が何もしていないように見えたら、システムが壊れていると結論づける前に、サービス名が間違っている可能性を検討してください。そして可能ならシステム設定の経路を選んでください。ペインにはスペルの問題が起こりようがないからです。
コマンドラインバイナリとヘルパーツール
ここは「1 つのアプリ、リストに 1 つのエントリ」というモデルが最も激しく破綻する領域であり、しかも十分に記録された macOS 26 の不具合が一時期、事態をかなり悪化させた場所でもあります。
素の実行ファイルにはバンドル識別子がない
.app はバンドルです。定められた構造を持つディレクトリで、その中の Info.plist が CFBundleIdentifier などを宣言しています。/usr/local/bin に置かれたコンパイル済みバイナリにはそのどれもありません。ただの Mach-O 実行ファイルです。
TCC のモデルはバンドルを前提に作られています。素の実行ファイルにも権限を与えることはできますが、キーにするバンドル識別子がありません。だからこそアプリのようにペインに現れないことがあり、tccutil reset Service bundle.id にも対象がないのです。
macOS 26.1 の表示不具合と、そこから分かったこと
2025 年後半、Apple Developer Forums の複数のスレッドが、異なる権限にまたがって同じ現象を報告しました。Apple 自身のエンジニアが診断を確認しており、その顛末はペインとデータベースの関係について長く通用する知見を教えてくれるので、順に見ていく価値があります。
スレッド 807898「Issue: Plain Executables Do Not Appear Under 'Screen & System Audio Recording' on macOS 26.1 (Tahoe)」は、画面収録を要求する素の実行ファイルが通常どおりプロンプトを受け取り、許可されればちゃんと画面をキャプチャするのに、システム設定のリストには一度も現れないと報告しました。投稿者のまとめはこうです。「macOS 26.1 (Tahoe) appears to require app bundles for an item to be shown in the Screen Recording privacy UI. Plain executables: still request and receive permission, still function correctly after permission is granted, but do not appear in the System Settings list.（macOS 26.1 (Tahoe) は、画面収録のプライバシー UI に項目が表示されるためにアプリバンドルを要求するようだ。素の実行ファイルは、依然として権限を要求して取得し、付与後も正しく機能するが、システム設定のリストには現れない）」同じコードを .app バンドルとしてパッケージすると正常に表示されました。Apple の DTS エンジニアである Quinn "The Eskimo!" はこう返信して確認しています。「IMO this is a bug and I encourage you to file it as such.（私見ではこれはバグであり、そのように報告することを勧めます）」
スレッド 807323「Background Unix executable not appearing in Screen Recording permissions UI (macOS Tahoe 26.1)」は、同じ症状を別の角度から報告しました。CGRequestScreenCaptureAccess() を呼ぶバックグラウンドの Unix 実行ファイルが 26.0.1 では動作し、26.1 で UI に現れなくなったというものです。投稿者は、+ ボタンで実行ファイルを手動追加すると「grants permission internally, but the executable still doesn't show in the UI（内部的には権限が付与されるが、実行ファイルは依然として UI に表示されない）」ため、ユーザーは「cannot verify or revoke permissions.（権限を確認することも取り消すこともできない）」と指摘しました。このスレッドには Apple からの返答はなく、別の開発者による裏付けだけがありました。スレッド 809549 はフルディスクアクセスについて同じ問題を提起し、コマンドラインバイナリが「fail to appear under the FDA settings, even after selection（選択後でも FDA の設定に表示されない）」と報告しました。Quinn はこれを既存の集約スレッドに誘導し、モデレータがスレッドをロックしました。
その集約スレッド 806187 に、決着があります。重要な発見はこうです。権限はずっと正しく記録されていたのです。データベースは正しく、リストが間違っていました。ある参加者はこう表現しています。「CLI apps can have full disk access or other permissions, but you cannot see it in the list.（CLI アプリはフルディスクアクセスやその他の権限を持てるが、リストでは確認できない）」26.1 で追加された「Background Security Improvements」という機能が、設定画面をバンドル済みアプリケーションのみ表示するように変更していました。
暫定的な回避策は「drag the binary from Finder to the full disk access list in System Settings window. The permission will be given, but it won't show in the list.（Finder からバイナリをシステム設定ウインドウのフルディスクアクセスのリストにドラッグする。権限は付与されるが、リストには表示されない）」というものでした。長く通用する推奨は、別の DTS エンジニアである Kevin Elliott から出ています。「The better solution is to embed that tool inside an app bundle. I don't mean 'make your command-line tool act like an app', I mean 'take your command-line tool and stick it inside an app bundle, then use it exactly the way you were using it before'.（より良い解決策は、そのツールをアプリバンドルの中に埋め込むことだ。『コマンドラインツールをアプリのように振る舞わせろ』という意味ではなく、『コマンドラインツールをアプリバンドルの中に入れて、これまでとまったく同じように使え』という意味だ）」
複数の参加者が、この表示不具合は macOS 26.3 ベータで修正されたと確認しています。またスレッド 807898 では、26.1 と 26.2 ベータに存在した同じ問題のアクセシビリティ版も 26.3 で解決したという報告がありました。
26.1 を過ぎていてもこれがあなたに関係する理由： ペインはデータベースのビューであり、ビューは嘘をつくことがあります。アプリやツールが明らかに権限を持っているのにリストに現れないなら、権限が欠けていると決めつけないでください。リセットを始める前に、実際の挙動を確かめましょう。
Terminal から起動したアプリが Terminal の権限を引き継ぐ理由
これは開発者を絶えず躓かせますが、ルールを知れば不思議ではなくなります。
TCC は単純に「どのバイナリがこの要求をしているか」を問うのではありません。Howard Oakley が「an attribution chain that traces up through the call chain to an app that is responsible for the privacy settings to be applied.（適用されるべきプライバシー設定に責任を持つアプリまで、呼び出し連鎖をさかのぼる帰属の連鎖）」と表現するものをたどります。システムは 責任を持つ プロセスを探し、それは通常、連鎖の最も深いプロセスではなく、ユーザーが起動したアプリです。
したがって Terminal からプログラムを実行すると、通常は Terminal が責任プロセスになります。あなたのプログラムの画面キャプチャ要求は、Terminal の画面キャプチャ要求になります。Terminal が権限を持っていればあなたのプログラムは動き、持っていなければプロンプトにはあなたのプログラムではなく Terminal の名前が出ます。これはスレッド 807898 の投稿者が観察したとおりです。VS Code や Terminal など別のアプリから起動した場合、「the parent app appears in the list instead, not the executable itself.（実行ファイル自身ではなく、親アプリの方がリストに現れる）」
日常での帰結が 3 つあります。ターミナルエミュレータに権限を与えるということは、そこで実行するすべてのツールがその許可を引き継ぐということです。便利である一方、実際の権限拡大でもあるので、気軽に行う前に考える価値があります。同じスクリプトでも、Terminal から起動した場合、LaunchAgent から起動した場合、ダブルクリックしたアプリのラッパーから起動した場合で挙動が変わります。それぞれ責任プロセスが異なるからです。そして、ターミナルエミュレータを乗り換えると最初からやり直しになります。iTerm2、Ghostty、Warp、Kitty、Terminal.app はそれぞれ別の ID だからです。
ヘルパーツール、XPC サービス、ログイン項目
現代の Mac アプリは、しばしば複数の実行ファイルから成ります。メインのアプリ、場合によっては /Library/PrivilegedHelperTools にある特権ヘルパー、バンドルに埋め込まれた XPC サービス、ログイン時に動く launch agent などです。
適切に署名されたバンドル内に埋め込まれた XPC サービスは、連鎖がアプリに解決されるため、一般に親アプリの帰属の下で動作します。別途インストールされるヘルパーや launch daemon はしばしばそうなりません。アプリのプロセスツリーの外側で独自の ID を持って動くため、それ自身の許可が必要です。一部のアプリが権限の承認を 2 回、アプリ用とヘルパー用に求めてくるのはこのためであり、root としてインストールされたヘルパーが、ユーザーごとのデータベースではなく システム のデータベースにエントリを必要とする場合があるのもこのためです。
アプリが中途半端にしか動かない、つまりインターフェイスは反応するのにバックグラウンドの機能が黙って失敗する場合、権限のないヘルパーが有力な容疑者です。どのヘルパーに何が必要かを知る最速の経路は、そのアプリ自身のサポートドキュメントです。ペインからは判別できないからです。
画面収録に特有の話
ペインはシステム設定 → プライバシーとセキュリティ → 画面とシステムオーディオの収録です。Apple の説明は原文どおりこうです。「Allow apps to record your screen and audio, or just your audio. The listed apps have access.」
この権限に固有のポイントは次のとおりです。
定期的な再確認があるのはこの権限だけです。 他のどの TCC カテゴリもタイマーで再確認してくることはありません。カメラの権限やフルディスクアクセスが毎月尋ねてくるなら、それは設計された挙動ではなく、不具合を抱えています。
切り替えには通常アプリの再起動が必要です。 多くのアプリはキャプチャ能力を起動時に一度だけ読み取ります。アプリが動いている間にスイッチをオンにしても、再起動するまで気づかないことがあります。「有効にしたのに何も起きない」という報告のかなりの部分は、これだけで説明がつきます。
システムオーディオと画面はまとめられているが同一ではありません。 ペインは両方を扱います。オーディオだけを要求するアプリもあります。画面はきちんとキャプチャできるのに無音で録音されるなら、そもそもシステムオーディオのキャプチャを要求したのかを確認し、アプリ自身のオーディオデバイス設定も見てください。仮想オーディオデバイスの欠落は TCC とはまったく別の問題だからです。Mac での画面収録 完全ガイドがオーディオ側を詳しく解説しています。
正直に報告する、現実の難しいケース。 Microsoft の Q&A スレッドに、macOS Tahoe 26.4、ビルド 25E246 上の Teams for Mac が画面共有の権限プロンプトでループする事例が記録されています。報告した管理者は、人が確認できることをすべて確認していました。正しいコード要件を伴う com.microsoft.teams2 を対象とした MDM 配信の PPPC プロファイル、kTCCServiceScreenCapture に対して auth_value=2 を示すシステムレベルの TCC レコード、同じ内容を示すユーザーレベルのレコード、そして Teams がオンになっていてプロファイルによって設定されている旨の注記が付いたシステム設定。キャッシュのクリア、レガシーな com.microsoft.teams 識別子の削除、MDM 経由での再インストール、プロセスの強制終了と再起動、そして Mac の再起動もすでに行っていました。
提示された回答は標準的な対処でした。「fully quit Teams, remove and re-add or re-toggle the Teams entry in Screen Recording, then restart Teams and re-attempt sharing so macOS can re-prompt and re-bind the permission（Teams を完全に終了し、画面収録の Teams エントリを削除して再追加するか切り替え直し、Teams を再起動して共有を再試行し、macOS が再度プロンプトを出して権限を再バインドできるようにする）」、それでも駄目ならクライアントログを添えて Microsoft サポートにエスカレーションせよ、というものです。3 週間後、報告者は有効な解決策は提供されなかったと述べ、代わりに Web 版を使っていると書きました。あらゆる層で本当に権限が付与されていて、アプリケーション側のバグが原因ということもあるのです。どこでやめるかを知ることも技術のうちです。
フルディスクアクセスに特有の話
フルディスクアクセスはシステム内で最も広範な権限です。バックアップツール、移行ユーティリティ、セキュリティソフト、管理作業に使うターミナルエミュレータが必要とするものです。
ファイルとフォルダのエントリとは別物です。 ファイルとフォルダは特定のフォルダへのアクセスを与えます。フルディスクアクセスはマシン全体の保護されたデータ、つまり Mail、メッセージ、Safari の閲覧データ、Time Machine バックアップ、他アプリケーションのコンテナディレクトリへのアクセスを与えます。フルディスクアクセスを持つアプリは、ファイルとフォルダに何も必要としません。
ほぼ必ずアプリの再起動が必要です。 他のどの権限よりも、フルディスクアクセスはプロセス開始時に評価される傾向があります。付与したら、アプリを終了して起動し直してください。まさにそうするよう指示するダイアログを出すアプリも多くあります。その言葉を信じてください。
プロンプトで要求することはできません。 アプリは、承認するとフルディスクアクセスが付与されるダイアログを出すことはできず、ペインへ誘導することしかできません。これを必要とするアプリがシステムダイアログではなく手順の説明を表示するのはこのためであり、「許可をクリックしたのにまだ動かない」という報告がよくあるのもこのためです。クリックすべき「許可」など存在しなかったのです。
ターミナルエミュレータにとって、この付与は広範です。 Terminal や iTerm2 にフルディスクアクセスを与えるということは、先に述べた帰属の連鎖を通じて、そこで実行するすべてのコマンドがその到達範囲を持つということです。管理者にとってはまさにそれが望みであることも多いでしょう。自分が何をしているかを理解しておいてください。
コマンドラインツールは前述の 26.1 の表示不具合の影響を受けました。 修正は 26.3 ベータで入りました。26.1 または 26.2 を使っていて、追加した CLI ツールがリストに現れないなら、それは既知の不具合であり、ツールは実際には権限を持っている可能性が十分にあります。リストを信じるより、実際の挙動を確かめてください。
アクセシビリティとオートメーションに特有の話
この 2 つは似た種類の混乱を生むため、まとめて扱います。
アクセシビリティ はアプリにあなたの Mac を制御する能力を与えます。ウインドウマネージャ、テキスト展開ツール、クリップボードマネージャ、キーボードリマッパー、自動化ツール、リモートサポートソフトはいずれもこれを必要とし、macOS はこれを強力な付与として扱います。
その特徴的な挙動として、多くのアプリは変更が反映されるまでに完全な終了と再起動を必要とし、一部はスイッチをオフにして再度オンにする必要があります。アクセシビリティに依存するアプリがアップデート後に動かなくなったら、まず前述のコード署名 ID のケースを確認してください。アクセシビリティも macOS 26.1 の表示不具合の影響を受けたペインの 1 つで、スレッド 807898 にはアクセシビリティ版が「has now been fixed in 26.3 Beta.（26.3 ベータで修正された）」という報告があります。
オートメーション は他のどのペインとも構造的に異なります。アプリのリストではなく ペア のリストなのです。「アプリ A がアプリ B を制御しようとしています」という各ペアが、それぞれ別の判断です。スクリプトが 3 つのアプリケーションを制御するなら、判断は 3 つ、エントリも 3 つになります。
そこから 2 つのことが導かれます。オートメーションの権限が壊れているというのは、複数あるペアのうち 1 つが欠けているという意味であることが多く、どれが欠けているかを見られるのはペインだけです。そして tccutil reset AppleEvents com.example.controller でオートメーションをリセットすると、そのコントローラのペアリングが一度にすべて消えるため、スクリプトが次に各対象に触れたときに再承認することになります。行き詰まったオートメーションの状態から抜け出す最速の手段であることが多いのですが、プロンプトの連続に備えてください。
もう 1 つ挙げておきたい罠があります。AppleScript を Terminal から実行すると、記録される許可はあなたのスクリプトが対象アプリを制御するというものではなく、Terminal が対象アプリを制御するというものになります。スクリプトを別のターミナルエミュレータに移すか、アプリとしてラップすれば、また承認することになります。これは帰属の連鎖が設計どおり働いているだけなのですが、だからといって初回の驚きが減るわけではありません。
クリーンな再付与の手順
本物の不具合だと特定できたら、次の手順を実行します。順番どおりに従ってください。各ステップには理由があり、1 つ飛ばすことが「この手順は効かない」という結論につながります。
1. アプリを完全に終了する。
ウインドウを閉じるだけでは足りません。Cmd-Q で終了し、何も残っていないことを確認します。
pgrep -fl "AppName"プロセスが残っていれば、それらが古い権限状態を保持しており、この後に行うことはすべて陳腐化したメモリ上の判断に対して評価されます。
理由： 実行中のプロセスは自身の権限状態をキャッシュしています。生きたプロセスの下でデータベースをリセットすると一貫性のない挙動になり、幻を追いかける羽目になります。
2. ディスク上にアプリのコピーがちょうど 1 つだけあることを確認する。
mdfind "kMDItemKind == 'Application'" -name "AppName"使っていないコピーは削除します。
理由： コピーが 2 つ存在すると、間違った方に再付与してしまい、出発点に逆戻りする可能性があります。ここが皆が飛ばすステップであり、手順が失敗する理由です。
3. バンドル識別子を確認する。
osascript -e 'id of app "AppName"'理由： 識別子が間違っていれば、良くて -10814 エラーが出ますし、最悪の場合はリセットコマンドから識別子ごと外したくなる誘惑に駆られます。それが破壊的な道です。
4. ペインからアプリのエントリを削除する。
システム設定 → プライバシーとセキュリティ → 該当するペインを開き、アプリを選択して - をクリックします。管理者認証を求められたら入力します。
理由： これはサポートされた方法で陳腐な判断を削除する操作です。スイッチをオフにするのとは違います。オフにすると判断の削除ではなく 拒否 が記録されます。拒否されたアプリは、再度あなたにプロンプトを出すことも許されません。
5. そのバンドル識別子に対してサービスをリセットする。
tccutil reset ScreenCapture com.example.appname正しいサービス名と識別子に置き換えてください。フルディスクアクセスなら SystemPolicyAllFiles、アクセシビリティなら Accessibility、オートメーションなら AppleEvents です。
理由： 26.1 の不具合が決定的に示したとおり、ペインとデータベースは食い違うことがあります。画面からの削除とリセットの両方を行えば、システムが実際にどちらを参照していても対応できます。ここでバンドル識別子は省略可能ではありません。
6. アプリを起動し直す。
理由： キャッシュされた判断のない新しいプロセスであり、前回の実行の残滓もありません。
7. その権限を必要とする操作を実行する。
画面共有を始める。フォルダを開く。Apple イベントを送る。システム設定に戻ってスイッチを先にオンにしないでください。
理由： 現在の署名 ID を判断に結び付ける仕組みがプロンプトそのものだからです。その結び付けこそが、この一連の作業の目的すべてです。ペインでスイッチを先に入れると、適切に結び付いていない判断が書き込まれることがあり、それが「スイッチはオンなのにアプリが動かない」という報告の正体です。
8. プロンプトで承認する。
「許可」をクリックするか、フルディスクアクセスのように直接プロンプトを出せないカテゴリのアプリなら、システム設定を開いてそこで有効にします。
9. もう一度アプリを終了して起動し直す。
理由： 多くのアプリは自身の権限セットを起動時にしか読みません。このステップが「付与された」を「実際に使える」に変え、この手順全体で最もよくある偽陰性を排除します。
ステップ 9 を終えてもアプリが動かないなら、問題は権限ではありません。次のセクションに進んでください。
それでも解決しないとき
新規ユーザーアカウントでテストする
システム設定 → ユーザとグループで新しい管理者アカウントを作り、そこにログインしてアプリをインストールまたは起動し、そのアカウントで権限を付与します。
このテスト 1 つで問題の空間がきれいに二分されます。
- 新しいアカウントでは動く： 不具合はあなたのユーザーアカウントの状態にあります。ユーザーごとの TCC データベース、古い環境設定、あるいは干渉しているログイン項目が最有力です。アプリもシステムも問題ありません。
- 新しいアカウントでも失敗する： 不具合はシステム全体か、アプリ自体にあります。あなたのアカウントは原因ではなく、今から試そうとしていた「環境設定を削除する」たぐいのアドバイスの多くは、あなたの夜を無駄にしていたでしょう。
5 分で済み、1 時間の推測よりも価値があります。
完全な再インストールが本当に答えである場合
再インストールは何にでも出てくる反射的な答えで、たいていは間違いです。本当に正しいのは次の 3 つの状況です。
codesign --verifyがバンドルの破損を報告する場合。 署名が検証を通らず、その下流にあるものは何も直せません。バックアップからではなく、開発者のオリジナルのダウンロードから再インストールしてください。バックアップこそが破損の元かもしれないからです。- アプリが改変を加えるソースからインストールされた場合。 再パッケージされたインストーラ、アプリバンドルにパッチを当てるツール、一部の企業向け配布機構は、署名が開発者のものと一致しなくなったバンドルを残します。開発者からクリーンなコピーを入手してください。
- アプリ自身のサポートドキュメントが、あなたの症状に対してそう指示している場合。 権限状態に関する既知の問題を抱え、独自の状態ディレクトリをクリアする手順を含む再インストール手順を文書化しているアプリもあります。
この 3 つ以外では、再インストールは一般にすでに持っているのと同じバンドルを再現するだけであり、署名 ID が変わらなければ権限の状況も変わりません。
再起動は、正しい理由のときに
再起動はプロセスの状態をクリアし、launch daemon を読み込み直し、メモリ上のキャッシュをリセットします。特にきれいに再読み込みされないバックグラウンドヘルパーが絡む場合など、行き詰まった権限状態のうち一定の種類は本当に解決します。しかしコード署名の不一致、ディスク上の重複コピー、破損したバンドル、アプリケーションのバグは直しません。早い段階で一度だけ再起動し、その後は診断に戻ってください。
やってはいけないこと
検索結果に絶えず現れるものなので、はっきり書いておきます。SIP を無効にしないこと。ダイアログボックス一つを回避するためにシステム全体の保護を取り除く行為です。TCC.db を編集または削除しないこと。SIP が有効なら不可能ですし、無効にしてまでやりたいことでもありません。ホームフォルダに chmod -R をかけないこと。このサブシステムには何の影響もなく、Library フォルダを壊しかねません。そして、バンドル識別子なしで tccutil reset All を実行しないこと。その日の残りを「許可」のクリックに費やしたいのでなければ。
管理対象の Mac
あなたの Mac が勤務先や学校によって管理されている場合、ルールが変わります。最初から勝ち目のないスイッチと 1 時間戦う前に、自分がそれに該当するかどうかを知っておく価値があります。
自分の Mac が管理対象かどうかの見分け方
チェックは 3 つです。第 1 に、システム設定 → 一般 → デバイス管理を見ます。プロファイルがインストールされていれば、そこに一覧表示されます。第 2 に、プライバシーのペイン自体にある注記を探します。管理されたエントリには、その設定がプロファイルによって構成されている旨のテキストが表示され、スイッチは通常グレーアウトしています。第 3 に、Terminal から次を実行します。
profiles status -type enrollment管理されていない検証機ではこう返りました。
Enrolled via DEP: No
MDM enrollment: No管理対象の Mac では、代わりに登録済みであることが報告されます。
プロファイルにできることとできないこと
MDM は Privacy Preferences Policy Control ペイロード、通常 PPPC プロファイルと呼ばれるものを通じて権限を付与します。これはシステム全体の TCC データベースに直接判断を書き込みます。管理対象の Mac で、誰も何もクリックしていないのに権限が現れるのはこのためです。
制限もあり、画面キャプチャはその 1 つです。PPPC の変更に関する記事が Mac 管理者の間で広く引用されている MDM ベンダーの Kandji は、その仕組みをこう説明しています。画面キャプチャと入力監視については「IT can use MDM to pre-allow certain apps to be approved even by standard users to enable screen capture or input monitoring.（IT 部門は MDM を使って、特定のアプリを標準ユーザーでも承認できるよう事前許可し、画面キャプチャや入力監視を有効にできる）」これは、黙って付与するのではなく承認をユーザーに委譲する認可値を使います。つまりプロファイルは画面キャプチャを完全に 拒否 することはでき、標準ユーザーに承認させることもできますが、フルディスクアクセスやアクセシビリティに対してできるような黙示的な付与は行わない、というのが文書化された挙動です。
このニュアンスは断定しすぎないでおいてください。前述の Microsoft の Q&A の事例では、管理者が MDM ポリシーを示す認可理由付きで kTCCServiceScreenCapture のシステムレベル TCC レコードを報告していたからです。この 2 つの説明はきれいには噛み合いませんが、都合の良い方を選ぶのではなく、両方を報告しておきます。
管理対象の Mac を使っている場合
グレーアウトしたスイッチを回避しようとしないでください。成功しませんし、多くの環境ではその試み自体がログに記録されます。プロファイルで管理されたエントリに対する tccutil reset は、失敗するか、次の管理チェックインで再適用されます。端末群を運用している担当者に連絡してください。修正は担当者側のプロファイル変更であり、1 分で終わります。
管理対象の Mac を運用している場合
PPPC ペイロードのコード要件を、配布するバージョンのアプリに対して codesign が実際に報告する内容と一致させてください。前述の Teams の事例が示唆に富むのは、まさに管理者がこれを検証したうえで壁に突き当たったからです。正しいプロファイルは必要条件ですが、常に十分条件とは限りません。Teams のようにアプリがバージョン間でバンドル識別子を変更した場合は、両方を残すのではなく、レガシーな識別子をプロファイルから削除してください。
よくあるトラブルの解決法
アプリがリストにあってオンなのに収録できない
Problem: ペインにはアプリが有効と表示されています。しかしアプリは権限がないかのように振る舞います。
Solution: そのエントリは、ディスク上のアプリともはや一致しない署名 ID に紐付いています。まず最も一般的な原因である 2 つ目のコピーの有無を mdfind "kMDItemKind == 'Application'" -name "AppName" で確認し、余分なものを削除します。次に、ペインからの削除とバンドル識別子付きの tccutil reset の両方を含む、クリーンな再付与の手順を最後まで実行します。単にスイッチをオフオンしないでください。それは拒否の記録に続けて紐付けのない承認を記録することになり、まさにそれがこの状態を招いた原因です。
アップデート後にアプリがリストから消えた
Problem: 昨日はペインにあったアプリが今日はなく、変わったことといえばアップデートだけです。
Solution: 新しいビルドが異なる署名で作られたため、macOS には履歴のない新しいアプリケーションに見えています。修復すべきものはありません。アプリを起動し、保護された操作を実行して、新しく出るプロンプトを承認してください。プロンプトを出せないフルディスクアクセスを使うアプリなら、+ ボタンで追加します。これがアップデートのたびに起きるなら、開発者の署名設定が不安定なので報告する価値があります。
月に一度ではなく起動のたびにプロンプトが出る
Problem: 画面キャプチャのダイアログが、想定される周期ではなくアプリを開くたびに現れます。
Solution: これは設計された再確認ではなく不具合です。考えられる原因は、ビルドのたびにコードハッシュが変わるアドホック署名のアプリ、自分のバンドルを繰り返し置き換える自己アップデータ、あるいは毎回異なる起動パスです。アプリに対して codesign -dv --verbose=2 を実行し、TeamIdentifier 行を見てください。サードパーティ製アプリでそれが not set なら、そのアプリは Developer ID で署名されておらず、開発者が署名を修正するまで安定した権限は実現できません。
同じアプリ名のエントリが 2 つある
Problem: ペインに同じアプリが 2 回、ときには同一のアイコンで表示されます。
Solution: 署名 ID かパスの異なるコピーがディスク上に 2 つ存在します。find /Applications ~/Applications ~/Downloads ~/Desktop -maxdepth 3 -name "AppName.app" 2>/dev/null ですべて見つけてください。1 つを残して他を削除し、両方のペインのエントリを削除してから、残った方に再付与します。ベータチャンネルとリリースビルドを意図的に併用しているなら、エントリが 2 つあることを想定して受け入れてください。
コマンドラインツールがリストに現れない
Problem: + ボタンでバイナリを追加しても表示されません。
Solution: macOS 26.1 と 26.2 では、これは前述の確認済み表示不具合で、Apple の DTS エンジニアも認めており、26.3 ベータで修正されたと報告されています。リストに出ていなくても権限は記録されている可能性が非常に高いので、さらにトラブルシューティングする前に実際の挙動をテストしてください。どのバージョンであれ、素の実行ファイルはバンドル識別子を持たず、このインターフェイスでは元々一級市民ではありませんでした。長く通用する答えは、スレッド 806187 の Kevin Elliott の言葉どおり、ツールをアプリバンドルの中に入れて、これまでとまったく同じように使い続けることです。
プロンプトが別のアプリケーションの名前を表示する
Problem: スクリプトを実行すると、権限のダイアログにあなたのスクリプトではなく Terminal や VS Code、スクリプトエディタの名前が出ます。
Solution: これは帰属の連鎖が正しく働いている証拠です。責任プロセスはあなたが起動したアプリであり、権限はそちらに付きます。そのホストアプリケーションに権限を与えて、その中で実行するものすべてが許可を引き継ぐことを受け入れるか、ツールを独自のアプリバンドルとしてパッケージして責任プロセスにするかのどちらかです。ターミナルエミュレータを乗り換えれば付与し直しになることも覚えておいてください。それぞれが別の ID だからです。
スイッチがグレーアウトしている
Problem: スイッチを変更できず、プロファイルに関する注記が出ていることもあります。
Solution: 判断が構成プロファイルによって設定されています。profiles status -type enrollment で確認し、システム設定 → 一般 → デバイス管理も見てください。管理対象の Mac なら管理者に連絡します。変更はプロファイル側で行う必要があります。個人の Mac に想定外のプロファイルが表示されている場合は、そこに何がインストールされているか確認してください。自分で入れた覚えのないプロファイルは精査に値します。
権限が効いていたのにスリープや長時間の使用後に効かなくなる
Problem: 朝は画面共有が動くのに、Mac がスリープした後は失敗します。
Solution: まず、見えているものが別のウインドウの背後に現れた定期的な再確認ダイアログではないかを確認してください。見えなかったプロンプトは、黙って失敗しているのとまったく同じに見えます。すべてのウインドウを前面に出して確認しましょう。プロンプトがなければ、アプリを完全に終了し、pgrep -fl "AppName" で確認してから起動し直します。復帰後に再読み込みに失敗したヘルパープロセスが通常の犯人だからです。それでも続くなら Mac を一度再起動します。毎日再発するなら、そのアプリにはスリープ復帰の処理にバグがあり、開発者への報告に値します。
FAQ
画面収録の定期的なプロンプトをオフにできますか？
いいえ。Apple はこれを無効化するユーザー向けの設定を提供しておらず、抑制するサポートされたコマンドも存在しません。これを取り除く唯一の仕組みは com.apple.developer.persistent-content-capture エンタイトルメントですが、これは開発者が Apple に申請する必要のある管理型の機能で、リモートコントロール系のアプリケーションを対象としています。ユーザーが有効化できるものではありません。
macOS はどのくらいの頻度で画面収録の許可を再確認しますか？
Apple はその間隔を一度も文書化していません。この挙動は Sequoia のサイクルで週次として始まり、批判を受けて Apple がそのベータ期間中に月次へ変更しました。MacRumors と 9to5Mac が 2024 年 8 月に報じています。Apple の現行のサポートページは再確認について一切触れておらず、macOS 26 での周期は権威ある情報源から確認できませんでした。
権限をリセットするとデータは消えますか？
いいえ。tccutil reset は記録された同意の判断を削除するだけで、それ以外は何もしません。ファイルも設定もアプリのデータも触れられません。代償は手間です。影響を受けたすべてのアプリが、次にその権限を必要としたときに再びプロンプトを出します。その代償はリセットの範囲に比例して大きくなります。だからこそ、必ずバンドル識別子を付けるべきなのです。
自分のアプリが Terminal では動くのに単体では動かないのはなぜですか？
TCC は要求を責任プロセスに帰属させるためで、Terminal から起動したプログラムの場合、それは通常 Terminal 自身だからです。あなたのプログラムは Terminal の許可を借りています。単体では権限を持っておらず、アプリバンドルではなく素の実行ファイルであれば、権限を与えるためにペインに現れることすらないかもしれません。
フルディスクアクセスを与えるのは危険ですか？
macOS が提供する中で最も広範な権限であり、Mail、メッセージ、Safari のデータ、Time Machine バックアップ、他アプリのコンテナを対象とします。そのすべてを預けてもよいと思えるソフトウェアにのみ与えてください。また、ターミナルエミュレータに与えると、そこで実行するあらゆるコマンドにまで到達範囲が広がることに注意してください。
権限を変更した後、Mac を再起動する必要はありますか？
通常は必要ありません。該当アプリの終了と再起動でほぼ常に十分ですし、多くのアプリが起動時にしか権限を読まないため、これは必須の手順です。完全な再起動が役立つのは、きれいに再読み込みされないバックグラウンドヘルパーや launch daemon という、より限定的なケースです。一度だけ再起動して、その後は診断に戻ってください。
まとめ
この領域の苛立ちの大半は、「権限」という 1 つのラベルを 1 つのものとして扱うことから生まれます。それは少なくとも 3 つあります。chmod が支配し、ここまでの話とは何の関係もない POSIX ファイル権限。アプリのコード署名 ID に紐付き、あなたには読めないデータベースに保存される TCC のプライバシー判断。そして管理対象の Mac では、ローカルで変更できる内容を上書きするプロファイル由来のポリシーです。
一度切り分けてしまえば、判断の樹は短いものです。周期的に届く画面キャプチャのプロンプトは意図的なもので、オフスイッチはなく、正しい対応は「許可」をクリックして自分の一日を続けることです。それ以外はすべて不具合であり、不具合には原因があります。ディスク上にある 2 つ目のコピー、アップデートで変わった署名、もはや検証を通らないバンドル、独自の許可を必要とするヘルパー、あるいはあなたのスクリプトではなくターミナルエミュレータを指している帰属の連鎖です。
ツールは本当に貧弱です。tccutil の動詞は 1 つ、Apple は受け付けるサービス名を公開しておらず、ペインはデータベースのビューにすぎず、実際に間違っていた前例もあります。macOS 26.1 の表示不具合では、リストが表示を拒む一方で権限は正しく記録されていたことを、Apple 自身のエンジニアが認めました。その制約の中でやりくりしましょう。コマンドを組み立てる前にバンドル識別子を確認する。reset には必ず識別子を付ける。クリーンな再付与の手順を順番どおりに実行する。行き詰まったら新規ユーザーアカウントでテストする。そして、やめどきを知ることです。付与を検証し、署名を検証し、重複を排除し、クリーンなアカウントでテストしてもなお駄目なら、macOS Tahoe 26.4 の Teams の報告者がそうだったように、残っている問題はあなたが直すべきものではありません。報告して、待つ間は回避策を使いましょう。
関連記事: macOS Tahoe 26.5 で Mac のマイクが動かない · macOS Tahoe のセキュリティとプライバシー：完全ガイド