現実世界を動かす技術をシェアしよう！～身近なものづくりから最先端テクノロジーまで大募集！～

Signalを削除しても読まれるのか ― iPhoneの通知ログに残る平文を、実機フォレンジックで追いかけた

Last updated at 2026-09-20Posted at 2026-09-20

TL;DR (Too Long; Didn't Read)

Signal の消えるメッセージを使い、アプリも削除していたのに、FBI が iPhone の通知の保存領域から受信メッセージを復元した事例がある。暗号は破られていない
パッチ（iOS 26.4.2）で過去分が消えると明言したのは Signal であって Apple ではない。Apple のアドバイザリは2文だけで、消去が完全かどうかは書かれていない
そこで筆者が実機で検証した。結果は「消えていた」でも「残っていた」でもなく、個人には確かめようがない構造（三重の壁）の確定だった
確かめられない以上、「消したから安全」という発想は成り立たない。確実なのは 存在しないデータは抜けない という一点だけだ
結論は、本当に秘匿したい内容はテキストでやり取りしない。テキストは必ず受信側の端末にも平文を生み、そこは自分の設定では守れない

本記事の立場：紛失・盗難・不正アクセスから自分のプライバシーを守るための、防御側の読み物である。正当な法的手続に対する証拠隠滅を勧めるものではない。記録義務があるやり取りは、むしろ記録を残すべきだ。

時点：本記事の調査は 2026年9月時点の公開情報と筆者の実測に基づく。フォレンジックツールの対応状況・販売条件・法制度・各社の仕様はいずれも変動する。

本記事の射程：扱うのは Signal と iOS（iPhone）本体の通知機構に限る。問題の本質は「ロック画面に出た通知が端末内にキャッシュされること」であり、通知を出す他のアプリにも当てはまりうるが、他アプリ個別の挙動や Android は本記事では検証していない。

情報の格付け：本文中の断定には、根拠の強さを示すタグを付けている。出典は脚注番号から参照できる。

タグ	意味
【公式に記載あり】	当事者（Apple、捜査機関など）の公式文書に記載がある
【実例報告あり】	報道や専門家の報告はあるが、当事者の確認はない
【推測】	根拠からの推論で、裏付けはない

1. 導入 ― 「消えるメッセージにしてるから大丈夫」は本当か

1-1. アプリを消しても読まれた

2025年7月4日、米テキサス州アルバラドの ICE 収容施設（Prairieland）で起きた事件がある。9人が起訴され、2026年2月から3月にかけて連邦地裁で公判が開かれた。3月10日の公判で、ある被告の iPhone から復元されたメッセージが証拠として提出された。¹² この件は4月に報じられ、英語圏では the Prairieland case と呼ばれている。

被告の iPhone では Signal がすでに削除されていた。それでも FBI は、ロック画面に表示された通知が端末内のデータベースに保存されていたことを利用して、受信メッセージの内容を取得した。【実例報告あり】³¹ 報道によれば、被告はメッセージを消える設定にもしていた。【実例報告あり】⁴

被告の支援者サイトが公開した証拠の要約によれば、取れたのは受信メッセージだけで、送信側は含まれていなかった。【実例報告あり】⁵⁶² この事実は第6章で効いてくるので覚えておいてほしい。

1-2. 通知という「第二の記録」

Signal の暗号は一切破られていない。狙われたのは暗号の外側だ。

[送信者] ──E2EE──> [受信者のSignalアプリ]
                      │ 復号（ここで平文になる）
                      ▼
                通知を出す
                      │ 「名前とメッセージ」表示の場合
                      ▼
            ┌──────────────────────┐
            │ iOS 側の通知機構      │ ← Signalの管轄外
            │（本文の平文コピー）    │
            └──────────────────────┘
Signalがメッセージを消しても、ここは Signal には消せない

ロック画面にプレビューを出すため、iOS はメッセージ本文を OS 側の通知機構に受け取る。この瞬間、E2EE とも消えるメッセージとも無関係に、OS 側に平文の第二の記録ができる。

1-3. CVE-2026-28950

2026年4月22日、Apple は iOS 26.4.2（旧系統は 18.7.8）を臨時配信し、Notification Services の問題 CVE-2026-28950 を修正した。【公式に記載あり】⁷

ただし、この CVE が Prairieland の事件で使われた問題そのものであることを、Apple は確認していない。悪用済みの脆弱性としても扱っていない。【公式に記載あり】⁷⁸ 報道と時期が一致しているというのが現時点の事実だ。

2. 疑問 ― パッチで本当に消えたのか

2-1. 誰が何を言ったか

ここは主体を混同すると議論が崩れる。表で分ける。

主体	言ったこと	格付け
Apple（公式アドバイザリ）	「削除対象としてマークされた通知が、予期せず端末上に保持される場合があった」「ログの問題をデータリダクションの改善で対処した」。この2文のみ	【公式に記載あり】⁷
Signal（公式声明）	パッチを当てれば、意図せず保持された通知はすべて削除され、今後も削除済みアプリの通知は保持されない	【公式に記載あり】⁹

一部の報道は「Apple が既存のキャッシュも削除した」と書く。¹⁰ だが Apple 公式のアドバイザリにその記述はない。遡及削除を明言したのは Signal だ。 Apple は保持期間も、消去の完全性も、復元可能性の技術詳細も公表していない。¹¹

もう一つ、時期の誤解も多い。削除が走るとされる起点は修正版の iOS 26.4.2 を当てた時点だ。その後の 26.5.x は通常の更新で、削除の起点ではない。

2-2. ユーザー側で検証できない

整理するとこうなる。

過去に残っていたかどうか → Apple は語っていない
パッチで消えたかどうか → 明言したのはプラットフォームの持ち主ではない
消えたかどうかを確かめる手段 → 一般ユーザーには案内されていない

報道の自由財団（FPF）も、読者向けの注意喚起の中で、Apple がキャッシュの保持期間を厳しく制限することへの期待を述べている。¹ 裏を返せば、保持期間は外からは分からないということだ。

「消えたはず」を信じるしかない状態だ。だから筆者は自分で確かめにいった。

3. 検証 ― 実機で追いかけた

3-1. 環境

項目	内容
対象端末	現行世代（A19）の iPhone／iOS 26.5.2（パッチ後）
未パッチ期間の露出	iOS 26.0〜26.4.1 の期間に使用していた
解析基盤	Windows 11 + WSL2 + Python 3.12
ツール	iLEAPP v2026.3.0-dev.0（OSS の iOS フォレンジックツール）¹²
取得手段	暗号化ローカルバックアップ（iTunes 経由。数百GB）
保存先	暗号化した外付けドライブ

暗号化を選んだのには理由がある。暗号化なしのバックアップには通知系のデータがそもそも入らない。一般ユーザーが合法的に取れる経路の中で、最も多くを吸い出せるのが暗号化ローカルバックアップだ。本検証はここを「個人の最高到達点」と置いている。

補足として、スピニング HDD 上で iLEAPP のフル解析を回すと I/O で固まった。対象パスだけを抜くターゲット抽出の方が安定した。

3-2. 平文が落ちうる二つの場所

通知の平文が残りうる場所は二つある。ここの区別が検証の成否を分ける。

区分	実体	形式	性質
表層ストア	`UserNotifications` 配下の `DeliveredNotifications.plist`	plist	「今まさに出ている通知」の置き場。タップ・消去・アプリ起動で日常的に消える。回転が速い
永続ログ	`userNotificationEvents/local/`（Duet 系）、`Biome/streams/public/Notification/local/`（Biome 系）	SEGB	追記型のログ。削除してもレコードの枠は残る

永続ログのうち userNotificationEvents には、通知のタイトルや本文が SEGB 形式で記録されることが、フォレンジック界隈で報告されている。【実例報告あり】¹³ Prairieland 事件以後に注目を集めたのもこのストリームだ。¹⁴

そのうえで、CVE-2026-28950 の本体はこの永続ログ側だと推定される。【推測】根拠は、後述する SEGB の構造が「削除対象なのに保持される」という Apple の記述と一致すること。ただし Apple は技術詳細を出しておらず、CVE とこのストリームの対応は確認されていない。

3-3. SEGB の「削除」は何を残し、何を消すのか

SEGB は追記型のバイナリ形式だ。各レコードは状態フィールドを持つ。iLEAPP のヘルパー実装ではこう定義されている。¹²

class EntryState(enum.IntEnum):
    Written = 1
    Deleted = 3
    Unknown = 4

レコードを削除しても状態フィールドが Deleted に変わるだけで、レコードの枠自体はファイルに残り続ける。オフセット、タイムスタンプ、状態は読める。つまり「ここに何かが記録され、後で消された」という事実は追える。

ではその本文は読めるのか？ここで筆者は誤った推測をした。追記型なのだから生バイトも残っているはずだと考えたのだ。

実際には残らない。公開されている実装を見る限り、削除済みレコードのペイロードはゼロ埋めされている。iLEAPP 自身が、ペイロードの先頭バイトがゼロであることを削除判定に使っている。¹²

if data[0:1] == b'\x00':
    state = 'Deleted'
else:
    state = 'Written'

本文の生バイトが残っているなら、この判定は成立しない。フォレンジックツールの解説でも、削除済みレコードから得られるのはオフセット・タイムスタンプ・状態であり、内容ではないとされている。【実例報告あり】¹⁵

そのうえで、iLEAPP の通知系パーサーの挙動を見ておく。レコードが Deleted だと、本文フィールドをすべて None にして捨てる。

elif record.state == EntryState.Deleted:
    data_list.append((segb_time, None, None, ... None, filename, offset))

この None 化は、捨てるものが無いから捨てているにすぎない。当初、筆者はここを iLEAPP の盲点だと考え、自前でデコードすれば読める余地があるという前提で検証を進めた。この前提そのものが誤りだった。

したがって、SEGB から「消えた本文」を読み出す経路は、この時点で閉じている。残るのは、Apple が言う「保持された通知」が具体的にどの状態のレコードを指すのかという問いだけだ。生きている（Written の）レコードとして残っていたのなら読める。その確認には、結局ファイルそのものが要る。

3-4. 手順

暗号化ローカルバックアップ取得
        │
        ▼
iLEAPP で復号（-t itunes、パスワードは環境変数経由で渡す）
        │
        ├─> ① 表層ストアを直接抽出（plist）
        │
        └─> ② Manifest.db（バックアップの全ファイル目録）を検索
                 → 永続ログ（SEGB）がバックアップに含まれるかを確認

3-5. 表層ストア：空だった。だが何も証明しない

UserNotifications 配下のアプリ別フォルダ 23個を復号し、DeliveredNotifications.plist の実体まで到達した。

結果、全23個が 228／219 バイトの空配列だった。平文通知の残存はゼロ。

ここで「残っていなかった、安全だ」と書きたくなる。だが違う。これは回転の速い置き場で、空なのが自然な状態だ。パッチの効果でも、安全の証明でもない。 そもそも CVE の対象とみられる場所ですらない。

3-6. ポジティブコントロールを先に立てる

本命の永続ログを探す前に、一つ決めたことがある。「見つからなかった」を意味のある結論にするには、探し方が正しいことを先に証明しなければならない。

検索して 0 件だったとき、それが「対象が無い」のか「クエリが間違っている」のかは区別できない。そこで、確実に存在するものを先に探した。

表層ストアは 3-5 で実際に抽出できている
よって Manifest.db を UserNotifications で検索すれば、必ずヒットするはず
ヒットすれば「クエリ手法は正しい」と言える
そのうえで通知系 SEGB のパスが 0 件なら、本物の陰性と確定できる

検索は Python 標準の sqlite3 で行った（WSL に sqlite3 コマンドが無かったため）。

import sqlite3
c = sqlite3.connect("<復号後の出力先>/Manifest.db").cursor()

def cnt(pattern):
    c.execute("SELECT count(*) FROM Files WHERE relativePath LIKE ?", (pattern,))
    return c.fetchone()[0]

for p in ["%UserNotifications%",     # ポジティブコントロール
          "%Biome%", "%streams%", "%Notification%",
          "%userNotificationEvents%", "%.segb%"]:
    print(p, cnt(p))

3-7. 結果

パターン	件数	判定
`%UserNotifications%`（ポジコン）	756	クエリ手法は正しい
`%Biome%`	5	実データストアはゼロ（後述）
`%streams%`	50	通知系はゼロ（後述）
`%Notification%`	1,239	すべてアプリ個別のストア（後述）
`%userNotificationEvents%`	0	Duet 系永続ログ、なし
`%.segb%`	0	※判定に使えない（後述）

件数だけで終わらせず、中身を目視した。

%Biome% の5件：設定用 plist と、無関係な語のヒットだけ。Biome の実データ（streams）はゼロ
%Notification% の1,239件：アプリが自前で持つ通知ストア。iOS 本体の SEGB 通知ログではない
%streams% の50件：メディア再生イベント、写真共有、パーソナライズ系など。通知に関係する stream は1件もない

結論：本検証のバックアップには、通知系の永続ログが一切含まれていなかった。

3-8. `.segb = 0` を証拠に使ってはいけない

自分への戒めとして書いておく。SEGB ファイルは通常、拡張子を持たない。先頭のマジックバイト SEGB で識別され、連番やタイムスタンプの名前で置かれる。拡張子検索では原理的に引っかからない。

「SEGB が無い」と言える根拠は .segb = 0 ではない。streams 全50件の目視で通知系がゼロ、userNotificationEvents がゼロ、Biome の実データがゼロ、この合わせ技だ。

3-9. 一度、誤って一般化しかけた

検証の途中で「iOS はシステムの stream 系を一律にバックアップから外している」と書きかけた。これは誤りだった。 反例が同じ結果の中に写っていた。

HomeDomain | Library/PersonalizationPortrait/streams/portraitFeedback/local/<id>
HomeDomain | Library/PersonalizationPortrait/streams/portraitFeedback/local/tombstone/<id>

PersonalizationPortrait/streams/ は、SEGB／Biome とそっくりの stream 構造を持つ。削除済みレコードの墓標である tombstone/ まで含めて、バックアップに入っている。

正確な言い方はこうなる。

誤：iOS はシステムの stream 系を一律にバックアップ対象外にしている
正：Biome 名前空間と通知系 stream という「個別の経路」が、
    バックアップ対象に含まれていない

「除外ポリシーだから安全」ではない。「通知系という特定の経路が、たまたま含まれていない」という個別の事実に留める。

4. 反転 ― 確かめられなかった。そしてそれが結論だった

4-1. 三重の壁

永続ログがバックアップに無いなら、別の手段で取りに行けばいい。そう考えて経路を一つずつ潰した。結果、独立した三つの壁が同時に立っていることが分かった。

壁	内容	格付け
① バックアップ非到達	通知系の永続ログは暗号化ローカルバックアップに含まれない。個人の最高到達点でも対象ファイルが吸い出されない	筆者の実測（第3章）
② 到達手段が個人に閉じている	バックアップに無いデータに届くには、フルファイルシステム抽出が要る。そのための商用ツールは個人には売られていない。自作も成立しない（後述）	後述
③ 時間的に手遅れ	端末はすでにパッチ後。仮にいま全領域を見られても、映るのはパッチ後の状態だけ。パッチ前の状態は二度と再現できない	論理的帰結

壁②を補足する。

商用ツール：代表的な iOS 抽出ツールの GrayKey は、販売先を法執行・公共安全・防衛機関に限り、民間には販売しないと販売元が明記している。購入希望者は審査を受ける。【公式に記載あり】¹⁶ 他の商用ツールの販売条件は、本記事では確認していない
自作：個人が使える公開のブート段エクスプロイト checkm8 の対象は A5〜A11 だ。【公式に記載あり】¹⁷ 対象は A19 で、公開されたブート段エクスプロイトは筆者の調べた範囲では存在しない。パスコードは Secure Enclave 内で鍵導出され、総当たりにハードウェア的な遅延と回数制限がかかる。個人が張り合える土俵ではない

壁①の手前で考えていた「iLEAPP の None 化を自前デコードで回避する」案も、ここで意味を失う。回避すべきファイルがそもそも手元に無い。

4-2. 「見れなかった」と「見れないことを確定させた」は違う

ここが本記事の差別化ポイントだ。

CVE-2026-28950 を扱った記事の多くは、パッチを当てて通知設定を変えれば終わり、という結論で閉じる。日本語の記事は CVE の紹介が中心で、英語にはフォレンジック視点の実機記事があるが、立場は捜査する側だ。報道の自由財団（FPF）のような防御側の専門組織も、注意喚起と設定変更の案内までで、実際に消えたのかの検証には踏み込んでいない。¹ 追ってみて分かったのは、消えたかどうかは、個人には原理的に確かめられないという事実だった。

これは弱い結果ではない。「Apple は保持期間も消去の完全性も文書化しておらず、ユーザー側で検証できない」という出発点の疑問を、手を尽くして技術的に裏付けたということだ。

4-3. 言えること、言えないこと

言える
  ・暗号化ローカルバックアップには、CVE の標的と推定される
    通知系の永続ログが含まれない
  ・したがって、この手段では残存を確認も否認もできない

言えない
  ・「端末に残っていない」        ← バックアップに無い ≠ 端末に無い
  ・「Apple が消したから安全」     ← Apple は消去の完全性を明言していない
  ・「パッチ後に消えた＝パッチが消した」 ← 前後関係は因果ではない

5. 転回 ― 検証できないなら、「守る」という発想が間違っている

5-1. 「消えたはず」も「残っているはず」も言えない

多くの対策記事は「設定を変えれば守れる」と書く。だが設定変更に遡及効果はない。過去に生まれた記録を消す手段は、初期化して新規にセットアップすることだけだ。そして、その過去分が実際に残っているかどうかは確かめられない。

確認できないものを「守れているはず」と見なすのは、対策ではなく希望だ。

5-2. フォレンジックは二値ではない

フォレンジックは「抜ける／抜けない」の二値ではない。コスト・時間・成功確率の関数だ。

たとえば端末の状態一つで難度は桁違いに変わる。一度もロック解除していない起動直後（BFU）は堅く、使用中（AFU）は脆い。長いランダムな英数字パスコードは、総当たりを現実的でない時間に押し上げる。これらは効く。ただし確率を下げる対策であって、ゼロにする対策ではない。ツールと OS はいたちごっこを続けている。

5-3. 唯一100%確実な層

では確率ではなく確実に言える防御はあるのか。一つだけある。

存在しないデータは、どんなツールでも抽出できない。

隠す（存在するものを覆う）
  例：強いパスコード、暗号化、BFU 運用
  → 突破されうる。突破されなかったことも確かめにくい

作らない（そもそも存在させない）
  例：通知に本文を載せない、消えるメッセージ、そもそも送らない
  → 突破しようがない

両者は守る対象が違う。「隠す」は端末が割られる確率を下げる。「作らない」は割られても平文が無いことを保証する。片方で片方は代替できない。

6. 結論 ― 最上位の対策は「テキストを発生させない」

6-1. これまでの対策は、テキストが存在する前提だった

通知に本文を出さない。消えるメッセージを使う。どれも正しい。だがすべて「テキストが存在する」ことを前提に、その痕跡を減らす技術だ。

そして最大の穴は別の場所にある。

6-2. テキストは受信側の端末にも平文を生む

1-1 で触れた事実を思い出してほしい。Prairieland の事件で取れたのは受信メッセージだった。つまり、読まれたのは被告以外の誰かが送ったテキストだ。

送った側がどれだけ自分の端末を固めていても関係ない。テキストは送った瞬間に、相手の端末にも平文を生む。 相手が短い数字のパスコードで、通知プレビューを全開にしていれば、そこから抜ける。相手の設定は、自分には制御できない。

テキストをやめることは、この制御不能な相手側の攻撃面を消す唯一の手段だ。

対策の階層（上ほど確実）

  1. テキストを発生させない（機微な話は通話で）  ← 唯一、相手側も守れる
  2. 作らない・載せない（通知に本文を出さない、消えるメッセージ）
  3. 物理層でコストを上げる（長いランダム英数字、BFU 運用、有線接続の制限）
  4. 確かめられない過去分は、リスクとして受け入れる

6-3. 通話は何を消し、何を消さないか

代替として音声通話（FaceTime 等）を置く。ただし「通話なら安全」で止めると、また思考停止になる。攻撃面を分解する。

攻撃面	E2EE の効果	FaceTime の場合
① 通信経路（回線・キャリア）	守られる	Apple は法執行機関向けガイドラインで、転送中の通話を復号できず傍受できないとしている【公式に記載あり】¹⁸
② サービス提供者	守られる	Apple が保持するのは通話招待ログのみ。このログは通話が成立したことを示さない。保持期間は米国向けガイドラインで最大25日、日本・アジア太平洋向けで最大30日【公式に記載あり】¹⁸¹⁹
③ 端末（自分・相手）	守られない	米国の刑事弁護士は、捜査機関は Apple から内容を得られないため、通信傍受令状と端末側の傍受手法を組み合わせるのが実務だと解説している【実例報告あり】²⁰

通話で消えるのは①と②だ。残るのは次のものになる。

端末側からの傍受：E2EE は転送中しか守らない
メタデータ：誰といつ何分話したかは残る。内容は守れても関係性は守れない
相手側の録音：相手の意思だけで成立し、こちらからは検知も防止もできない
鍵配布の構造的懸念：FaceTime や iMessage は複数の端末で使えるため、Apple が利用者の認証情報で別の端末を設定すれば傍受できてしまう、という暗号研究者 Matthew Green の指摘がある。²¹ ただしこれは2013年時点の指摘で、現行の FaceTime にどこまで当てはまるかは本記事では確認していない。実行された証拠も見つかっていないが、陰性は非証明だ【推測】

加えて、FaceTime は Apple 製品同士でしか使えない。記録が必要なやり取り（合意事項など）には向かない。

よって正確な言い方はこうなる。

誤：FaceTime なら安全／通話なら残らない
正：通話は「通信経路」と「サービス提供者」という攻撃面を消し、
    残る攻撃面を端末1点に絞り込む

絞り込まれた1点は、第5章の物理層と「作らない」が効く領域だ。対策を1か所に集中できる。ただしこの1点の安全は、本検証では確かめていない。

6-4. 実務チェックリスト

機微な内容はテキストで送らない。通話で済ませる
記録が必要な内容は、逆に記録が残る手段を選ぶ（秘匿と記録義務を混同しない）
Signal：設定 → 通知 → 通知内容 → 「名前もメッセージも非表示」
Signal：消えるメッセージの既定時間を設定する
パスコードを長いランダムな英数字にする（実在する単語を混ぜない）
設定 → プライバシーとセキュリティ → セキュリティ → 有線アクセサリ → 「常に確認」（iOS 26 の初期値は緩い側）
危険を感じたら電源を切る操作を体で覚えておく
過去分まで消したい場合は初期化しかない、と理解したうえで判断する

7. 補強 ― 金をかけた専用端末は解決策ではない

「なら、もっと堅い専用端末を買えばいい」と考える人もいるだろう。過去の事例がその答えを出している。

サービス	どう終わったか	格付け
Phantom Secure	2018年、米司法省が CEO らを起訴。ネットワークは停止された	【公式に記載あり】²²
EncroChat	フランス当局が、同社のアップデート配信の仕組みを通じて端末にマルウェアを送り込み、メッセージを収集した	【実例報告あり】²³²⁴
Sky ECC	ベルギー・オランダ当局がネットワークに侵入し、約3週間にわたり通信をライブで読んだ（侵入手法は公表されていない）	【実例報告あり】²⁵²⁶
ANOM	FBI が豪州警察と組んで自ら運営していた。1万2,000台超の端末が100カ国以上の300超の犯罪組織に渡り、2,700万件のメッセージを傍受。800人以上を逮捕	【公式に記載あり】²⁷²⁸

そして決定的なのは、どれも暗号が破られたのではないという点だ。

破綻の原因は二つある。一つは単一事業者への完全な信頼。事業者が落ちれば全員が同時に落ちる。もう一つはクローズドで監査できないコード。外から検証できない。ANOM に至っては、サービスそのものが罠だった。（それアリなんだ？と、思った）

検証できないものは信頼できない。本記事の検証がたどり着いた原則と、ちょうど同じ場所に行き着く。

皮肉なことに、無料で公開されているSignalの方が、構造としては壊れにくい。中身の暗号化がアプリ同士で完結するため、運営を信じる必要がないからだ。
よくある専用端末はこの逆で、OSの導入も設定も業者が済ませており、買った側には確かめる手段がない。そこで買っているのは安全ではなく、業者一社への信頼の集中だ。業者が破られれば、その端末を持つ全員が同時に破られる。EncroChatもSky ECCもANOMも、そうして一括で落ちた。あなたが持っている一般的に名前もあまり聞かないような端末は、何を信じて手元に置いていますか？
少なくとも自身で説明ができないなら購入するべきではないと筆者は考える。判断軸については稿を改める。

金をかけた端末は全滅した。一方で本丸は、無料の設定と「そもそも送らない」という判断だった。

8. まとめ

通知は第二の記録である。 E2EE も消えるメッセージも、OS 側に渡った平文には届かない
パッチで過去分が消えたかは、個人には確かめられない。 遡及削除を明言したのは Signal で、Apple ではない。実機で追っても三重の壁に阻まれる
「見えなかった」は「無い」ではない。 陰性は非証明。バックアップに無いことは、端末に無いことを意味しない
確実な防御は「作らない」だけ。 隠す対策は確率を下げるにとどまる
最上位の対策はテキストを発生させないこと。 受信側の端末は自分では守れない。機微な話は通話で済ませ、通話の限界（端末・メタデータ・録音）も理解しておく

最後に

ここからは筆者の考えになる。この問題に引っかかるのは、無関心な人ではない。むしろ関心が高く、金も払い、自分は対策できていると思っている人だ。専用端末を買う人がまさにそれにあたる。

対策と検証は別の行為だ。対策は金で買えるが、検証は自分でやるしかない。買った時点で満足が完結するため、確かめる動機がそこで消える。意識が高いほど、消えるのが早い。

買い手の中に確かめる人が一人もいない市場では、価格と実質が離れても誰も気づかない。これは誰かの悪意の話ではなく、市場構造の話だ。検証者のいない市場は、売り手が善良でも歪む。悪意があれば、なお歪む。そして歪みが大きい市場ほど、参入する側から見れば効率が良い。

本記事の検証も、金はかけていない。かけたのは手間と、確かめられなかったという結論を受け入れる覚悟だけだ。

個別の事業者を名指しするつもりはない。代わりに、買う側が自分で使える判断軸を次回書く。誰が悪いかではなく、何を確かめれば済むかの話にする。（需要があればの話

参考ソース

Freedom of the Press Foundation：FBI pulls deleted Signal texts from iPhone notifications（2026-04-15） ↩ ↩² ↩³ ↩⁴
Support the Prairieland Defendants：March 10 federal trial day 12（証拠158の記載元） ↩ ↩²
404 Media：FBI Extracts Suspect's Deleted Signal Messages Saved in iPhone Notification Database（2026-04-09。冒頭以降は会員限定） ↩
BGR：Apple Fixed An iPhone Flaw That Allowed The FBI To Read Deleted Notifications（404 Media の報道として、消える設定とアプリ削除に言及） ↩
9to5Mac：FBI used iPhone notification data to retrieve deleted Signal messages（支援者サイトの証拠要約を引用） ↩
SOFX：FBI Recovered Deleted Signal Messages From iPhone Via Notification Database（傍聴者・弁護人のメモに言及） ↩
Apple：About the security content of iOS 26.4.2 and iPadOS 26.4.2 ↩ ↩² ↩³
SANS ISC：Apple Patches Exploited Notification Flaw（Apple が悪用済みとしていない点） ↩
Privacy Guides：Apple Releases Patch for the Signal Notification Issue（Signal 公式声明の引用） ↩
Techzine：Apple patches iOS bug that allowed the FBI to read Signal messages ↩
SOC Prime：CVE-2026-28950: Apple Fixes iOS Data Retention Flaw（技術詳細・フォレンジック指標が公開されていない点） ↩
iLEAPP（abrignoni/iLEAPP） ↩ ↩² ↩³
Forensafe：iOS User Notification Events（userNotificationEvents の SEGB にタイトル・本文が記録される点） ↩
blog.digital-forensics.it：After the Signal Fix: Exploring Apple's notificationAndSuggestionDB.db（2026年に userNotificationEvents が注目された点） ↩
OpenText：Biome SEGB Record Parser（削除済みレコードが null バイトのみである点） ↩
Magnet Forensics：How to Get GrayKey from Magnet Forensics ↩
CERT/CC：Apple devices vulnerable to arbitrary code execution in SecureROM（VU#941987） ↩
Apple：Legal Process Guidelines（米国・法執行機関向け） ↩ ↩²
Apple：Legal Process Guidelines（日本・アジア太平洋の法執行機関向け） ↩
Todd A. Spodek：Can Law Enforcement Listen to Your FaceTime Calls?（2025-12。刑事弁護士による解説） ↩
CSO Online：Apple end-to-end encryption far from bulletproof（2013年） ↩
米司法省：Chief Executive and Four Associates Indicted…（Phantom Secure）（2018-03） ↩
Computer Weekly：Revealed: Cyber spies used malware from GitHub to hack EncroChat cryptophone network（2026-08） ↩
Vice：Emails Show Shadow Structure Behind Encrypted Phone Network Encrochat ↩
Computer Weekly：Police crack world's largest cryptophone network as criminals swap EncroChat for Sky ECC ↩
The Record：Belgian and Dutch police take down encrypted criminal chat platform Sky ECC ↩
Europol：800 criminals arrested in biggest ever law enforcement operation against encrypted communication ↩
FBI：FBI's Global Partners Announce Results of Operation Trojan Shield ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up