LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

アプリの画面キャプチャ防止とは — 機密表示を守る仕組み

画面キャプチャ防止とは、口座残高・カルテ・社内資料といった機密情報を表示する画面で、スクリーンショット・画面録画・画面共有（ミラーリングやAirPlay等）による情報の持ち出しを抑止・検知する実装を指します。金融アプリの残高画面や医療アプリの問診情報、社内業務アプリの人事データなど、表示するだけで情報漏えいのリスクになる画面が主な対象です。

この領域は、コードの難読化や改ざん検知を行うRASP（Runtime Application Self-Protection）や、脆弱性診断とは目的が異なります。RASPやセキュリティ診断がアプリ自体の改ざん・攻撃耐性を扱うのに対し、画面キャプチャ防止は「表示された画面をユーザー自身の操作でどこまで複製・共有できないようにするか」というOS機能の範囲の話です。本稿ではこの画面キャプチャの抑止・検知に絞って解説します。

画面キャプチャ防止の設計で最初に押さえておきたいのは、AndroidとiOSでOSが提供する機能の性質がまったく異なる点です。Androidはウィンドウ単位でスクリーンショット・録画・非セキュアディスプレイ表示を事前に抑止するフラグを提供しているのに対し、iOSはスクリーンショット自体を事前に禁止する公式APIを提供していません。この非対称性を理解しないまま「両OSで同じことができる」という前提で要件定義を進めると、実装段階で計画の見直しが必要になります。

AndroidのFLAG_SECURE — スクショ・録画・画面共有を抑止する

AndroidにはWindowManager.LayoutParamsのFLAG_SECUREというウィンドウフラグが用意されています。このフラグを立てたウィンドウは、スクリーンショットの取得を許可せず、テレビやプロジェクターへのキャスティングのような非セキュアディスプレイへの表示も防止する仕組みです^*1。銀行アプリやパスワード管理アプリなど、機密情報を扱うアプリでの利用が想定されている機能です^*1。

実装は1行、対象はウィンドウ単位

実装自体はシンプルで、対象のActivityが持つWindowに対してsetFlagsメソッドでFLAG_SECUREを設定するだけです^*1。アプリ全体ではなくウィンドウ（画面）単位で制御する仕組みのため、機密情報を表示する画面だけに絞って設定し、それ以外の画面ではユーザーが通常どおりスクリーンショットを使えるようにする、という粒度の使い分けが可能です。

Android 11以前は完全な信頼を置きにくい注記がある

公式ドキュメントには、Android 11（API 30）以前の端末ではFLAG_SECUREが設計どおりに機能するのは全体の約7割程度にとどまるという注記があり、一部端末ではキーボード入力が記録される場合があるとされています^*1。特定端末や特定OSバージョンでの挙動を過信せず、対象とする画面の重要度に応じて実機検証を行う判断軸を持っておくことが実務上は欠かせません。

Android 14からのスクリーンショット検知API

Android 14（API 34）では、FLAG_SECUREとは別に、ユーザーがスクリーンショットを撮影したことをアプリ側で検知するためのAPIが追加されました^*2。DETECT_SCREEN_CAPTUREパーミッションを宣言したうえで、ActivityのonStart時にScreenCaptureCallbackを登録し、onStop時に登録解除する実装です^*2。このコールバックは実際のスクリーンショット画像を渡すものではなく、撮影されたという事実だけを通知する点、ハードウェアボタンの組み合わせ操作以外（ADBコマンドやインストルメンテーションテスト経由）は検知対象外である点には注意が必要です^*2。抑止したい画面にはFLAG_SECUREを、撮影の事実だけ把握したい画面には検知APIを、という役割分担で設計するのが現実的です。

iOSでできること・できないこと（録画検知とスクショ検知）

iOSの画面キャプチャ対策で最初に共有しておくべき前提は、スクリーンショットの撮影自体をOSレベルで禁止する公式APIが存在しないという点です。Appleの開発者フォーラムでも、スクリーンショットはユーザーが常に使える機能として意図されており、これを妨げる仕組みは提供しない立場が繰り返し説明されています。iOSではAndroidのFLAG_SECUREに相当する「事前抑止」の手段がなく、検知と事後対応が対策の中心になります。

画面録画・ミラーリングはisCapturedで検知できる

UIScreenのisCapturedプロパティは、システムが画面を録画・ミラーリング・AirPlayによって別の宛先へ配信しているかどうかを示すブール値です^*3。値がtrueのときは、画面の内容が外部に複製されている状態を意味します^*3。この値が変化したタイミングはcapturedDidChangeNotificationで通知されるため、録画やミラーリングが始まった瞬間にアプリ側で表示内容を切り替える、あるいは再生を一時停止するといった対応が可能です^*3。ここで検知できるのはあくまで録画・ミラーリング・AirPlayの状態であり、静止画のスクリーンショットは対象に含まれません。

スクリーンショットは「撮影後の通知」のみ

スクリーンショットについては、userDidTakeScreenshotNotificationという通知が用意されています。この通知はユーザーが端末でスクリーンショットを撮影した後に送信される仕組みで、撮影そのものを止める効果はありません。開発者フォーラムでのAppleの回答でも、スクリーンショットを検知するAPIはあっても防止する公開APIはないという説明が一貫しており、事前抑止ではなく事後の検知・記録・警告表示までがiOSで設計できる範囲です。

できることとできないことを混同しない

録画・ミラーリングの「検知」とスクリーンショットの「事後通知」は似ているようで前提が異なります。前者はキャプチャが継続している間ずっと状態を把握できるのに対し、後者は撮影という一瞬の出来事を後から知るだけです。iOSアプリの要件定義では、この2つのAPIが担える範囲を混同せず、「完全に防げる」という表現を避けて、検知できた場合にどう振る舞うかという設計に力点を置く必要があります。

秘匿表示のテクニック（secureTextEntry・オーバーレイ・アプリスイッチャー対策）

iOSでは事前抑止の公式APIがない代わりに、特定のUI部品が持つ副次的な性質を利用して秘匿性を高めるテクニックが使われます。ここではその代表例を整理します。

isSecureTextEntryはパスワード欄以外にも応用できる

UITextInputTraitsのisSecureTextEntryは、本来パスワード入力欄で文字を伏字表示にするためのプロパティです^*5。このプロパティをtrueにした入力欄は、コピーを無効化するほか、録画・配信時に内容が正しく描画されない挙動を持つことが知られています。この性質を利用し、口座番号や個人情報など「一度に少量のテキストを表示する」用途で転用するテクニックが銀行系アプリなどで見られます。ただし本来の用途から外れた応用のため、OSアップデートで挙動が変わる可能性を織り込んだうえで採用するかどうかを判断する必要があります。

アプリスイッチャー（タスク切り替え画面）でのサムネイル対策

iOSはホームボタン操作やアプリ切り替え時に、直前の画面をサムネイルとしてキャプチャしてアプリスイッチャーに表示する仕様があります。機密情報を表示したままバックグラウンドへ遷移すると、このサムネイルに情報が写り込むおそれがあります。アプリがバックグラウンドへ遷移する直前にオーバーレイビューを重ねて機密情報を覆い隠し、フォアグラウンドに復帰した際にオーバーレイを外すという実装が、この対策の定番パターンです。

オーバーレイ表示は録画中の一時的な代替表示にも使える

isCapturedがtrueになったタイミングで、機密情報の代わりに「録画中のため非表示にしています」といったメッセージを重ねて表示する実装も、事前抑止ができないiOSでの現実的な代替策です。完全に情報を隠しきれる保証はありませんが、ユーザーの意図しない録画・共有に気づかせ、被害を最小化する効果は期待できます。Androidでも、FLAG_SECUREを使わない一部の画面や、対応していないOSバージョンへの補完としてこの手法を組み合わせるケースがあります。

要件定義の勘所（どの画面を・どのレベルで守るか）

画面キャプチャ防止の実装で最も手戻りが起きやすいのは、要件定義の段階で保護対象と保護レベルを具体化しないまま設計に入ってしまうケースです。

画面単位でリスクの高さを仕分ける

アプリ内のすべての画面に一律でFLAG_SECUREを設定すると、ユーザーが業務メモとして残したい画面までスクリーンショットが撮れなくなり、利便性を損ないます。口座残高・個人情報・診療記録のように第三者に見られると実害が生じる画面と、一覧画面や設定画面のようにリスクが相対的に低い画面を仕分け、保護を適用する画面を絞り込む作業が要件定義の起点になります。

「抑止」と「検知」のどちらを目指すかを先に決める

Androidでは抑止（FLAG_SECURE）と検知（ScreenCaptureCallback）のどちらも選べますが、iOSでは抑止という選択肢自体が存在しません。この前提を踏まえ、iOS側でも同水準の防御を求めるのか、検知と事後対応で妥協するのかを、企画・法務・セキュリティ担当を交えて合意しておく必要があります。合意が曖昧なまま実装に入ると、リリース直前になって「iOSでも完全に防いでほしい」という要望が出て手戻りにつながりかねません。

MDM・業務端末前提かBYOD前提かで対策の幅が変わる

社内業務アプリの場合、会社支給端末にMDM（モバイルデバイス管理）を導入しているか、私物端末（BYOD）での利用を許容しているかによって、追加できる対策の幅が変わります。MDM管理下であれば、OS標準機能に加えて外部カメラでの盗撮対策や端末制限ポリシーを組み合わせられる一方、BYOD環境ではアプリ側の機能だけで対応する前提を置く必要があります。この違いを要件定義の早い段階で確認しておくと、後工程での前提のズレを防げます。

外注時に確認すべき実装範囲と引き継ぎの論点

画面キャプチャ防止の実装をアプリ開発会社に外注する場合、「画面キャプチャ対策を入れてください」という抽象的な依頼だけでは、期待した保護レベルと実装内容がかみ合わないことがあります。確認しておきたい論点を整理します。

内製するには何が必要か

内製で対応する場合、Android・iOS双方のOS機能の違いを正しく理解したうえで、画面ごとの保護方針を設計できるエンジニアが必要です。特にiOS側は「防げない前提でどう検知・代替表示するか」という設計判断が求められるため、単に既存のサンプルコードを移植するだけでは、想定外の画面でキャプチャが素通りする事態が起こり得ます。

発注先への確認

提案書に「画面キャプチャ対策を実装します」とだけ書かれている場合、どの画面にFLAG_SECUREを適用するのか、iOS側は検知後にどのような振る舞いをするのか、アプリスイッチャーのサムネイル対策を含むのかを具体的に質問する必要があります。「iOSでも完全に防げます」という回答があった場合は、事前抑止の公式APIが存在しないという前提と矛盾するため、実装内容を詳しく確認したほうがよいでしょう。

契約明記の3小見出し

契約段階では、保護対象画面の一覧、Android/iOSそれぞれで実現する機能の範囲、OSアップデートによる挙動変化が起きた場合の保守対応方針の3点を明記しておくことが望ましいです。特にiOSのsecureTextEntryを応用したテクニックは非公式な使い方であるため、将来のOSアップデートで挙動が変わった際の追加対応が有償か保守範囲内かを事前に取り決めておくと、後々のトラブルを避けやすくなります。

納品物には、どの画面にどの機能を適用したかを一覧化した実装対応表を含めてもらうよう依頼しておくと、引き継ぎや将来の改修時に既存実装を1つずつ調査し直す手間を減らせます。

まとめ：画面キャプチャ防止を機能させる3つの判断軸

本稿では、AndroidのFLAG_SECUREとiOSの検知系APIを軸に、アプリの画面キャプチャ防止の実装について整理しました。要点を3つに集約します。第一に、AndroidはFLAG_SECUREでスクリーンショット・録画・非セキュアディスプレイ表示を事前に抑止できるのに対し、iOSには同等の事前抑止APIが存在せず、isCapturedやuserDidTakeScreenshotNotificationによる検知・事後対応が中心になるという非対称性を正しく理解する必要があります。第二に、この違いを踏まえたうえで、どの画面を・どのレベルで守るかを要件定義の段階で具体化し、抑止か検知かの方針を関係者間で合意しておくことが手戻りを防ぎます。第三に、外注する場合は「完全に防げる」といった曖昧な説明を鵜呑みにせず、画面単位の実装範囲とOSアップデート時の保守方針を契約に明記する姿勢が、長期的な運用品質を左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Android「Secure sensitive activities」（Fraud prevention）https://developer.android.com/security/fraud-prevention/activities
2. *2　出典：Android「Detect when users take device screenshots」（Android 14 features）https://developer.android.com/about/versions/14/features/screenshot-detection
3. *3　出典：Apple「isCaptured」（UIScreen, UIKit）https://developer.apple.com/documentation/uikit/uiscreen/iscaptured
4. *4　出典：Apple「userDidTakeScreenshotNotification」（UIApplication, UIKit）https://developer.apple.com/documentation/uikit/uiapplication/userdidtakescreenshotnotification
5. *5　出典：Apple「isSecureTextEntry」（UITextInputTraits, UIKit）https://developer.apple.com/documentation/uikit/uitextinputtraits/issecuretextentry

Tweet