CypherpunkGuide

Bitcoinを買った後の10ステップ：セルフカストディ検証手順（2026年版）

Mon, 27 Jul 2026 00:00:00 +0000

資金について：CypherpunkGuideは監視型広告を載せていません。広告ネットワーク、トラッキングピクセル、スポンサー記事は使いません。資金源は、現在の読者寄付と、将来の購読・編集方針に沿ったアフィリエイトです。私たちが向き合う相手は、広告主ではなく読者です。

取引所に残高が表示されても、管理権の引き渡しが終わったとは限らない。取引所のステータス画面は、管理事業者が持つ記録である。それとは別に、自分のウォレットが追跡するアドレスへオンチェーンの出力が届いたことを確かめなければならない。ウォレットが持つのは端末の中のコインではなく、取引を承認する鍵だ。第三者管理では事業者が鍵へのアクセスを握り、セルフカストディ（自分で鍵を管理する方式。以下「自己管理」）では自分が握る。ただし、これは技術上の区別にすぎない。法律上の所有権は、事業者の規約と各地の法令によって決まる（SECの投資家向け資料、2025年）。

危ない近道は、数字が見えたところで引き渡しが済んだと思い込むことだ。隔離したBitcoin Core v31.1.0の検証では、資金を入れたウォレットにも、監視専用ウォレットにも、同じ0.01000000 BTCが表示された。だが監視専用側は秘密鍵が無効であり、部分署名Bitcoin取引への署名を求めるとcomplete=falseを返し、直接送金はRPCエラー**-4**で拒否された。正しい残高が見えても、分かるのは観測できるという事実までである。動かせる証拠にはならない。

では、安心させる画面を信用せずに、受領・署名・復旧ができると何で示せばよいのか。この10ステップのセルフカストディ検証は、その証拠を一つずつ作る。自己管理はリスクを消さない。鍵、端末、バックアップ、判断、緊急時の計画を通じて、リスクを自分側へ移すだけだ。

最初の原則：自己管理はリスクの移転である
#

自己管理を選ぶと、事業者に依存するリスクの一部を、自分が直接負う運用責任へ置き換えることになる。取引所への依存は減らせるが、秘密情報を一つ失う、バックアップが壊れる、急いで誤送金するといった失敗が、取り返しのつかない損失にもなりうる。

SECも両面を示している。管理事業者は鍵へのアクセスを握り、その事業者が破綻したり、サービスを停止したりする可能性がある。一方、自己管理を選んだ人は鍵の安全を引き受ける。「今すぐ全額を引き出せ」は、誰にでも当てはまる助言ではない。守れて、復旧できる金額だけを移すべきだ。

残高が見える場所	署名に必要な情報を持つのは誰か	自分に残る主なリスク	引き渡しを完了させるもの
取引所アカウント	事業者またはその管理委託先	事業者の破綻、アカウント停止、規約、セキュリティ、出金可否	出金の受領を確認する。ただし管理権の引き渡しは、別の署名・復旧検証を終えて初めて完了する
自己管理ウォレット	自分、または自分の管理ルールで定めた署名者	秘密情報の紛失、端末侵害、不完全なバックアップ、強要、操作ミス	受領・署名・復旧の3つの検証
監視専用ウォレット	そのウォレット内には署名情報がない（別の署名機が持つ）	残高が見えることから生じる誤った安心	別の署名機で、承認した送金を完了させる

証拠にもとづく管理権の引き渡しは、受領、署名権限、復旧可能性の3つが確認できたところで終わる。それでも、自己管理が誰にとっても最善になるわけではない。まだ復旧情報を守れないなら、学んでいるあいだは金額を小さく抑えるべきだ。

受領・署名・復旧は、それぞれ別の証明である
#

受領（Receipt）は、意図したウォレットにBitcoinが届いたことを示す。署名（Signing）は、必要な鍵で取引を承認できることを示す。復旧（Recovery）は、紛失後に独立して復元しても、その署名権限を再現できることを示す。

この3つは、別々に失敗する。取引が承認済みでも、バックアップが壊れていることはある。監視専用ウォレットは、秘密鍵がなくても取引を表示できる。パスフレーズ、ウォレット形式、アカウント、アドレス形式、鍵の導出経路が違えば、シードから復元しても、残高ゼロの別ウォレットが開くことがある。

検証	答えられる問い	強い証拠	証明にならないもの
受領	意図したウォレットが出金を受け取ったか	アドレス全文の一致、取引ID、予定した金額、リスクに合う承認状況	取引所のステータスだけ。先頭と末尾だけを比べたコピー済みアドレス
署名	必要な署名機で、意図した送金を承認できるか	信頼できる表示で宛先、金額、手数料を確認した後に署名した少額取引	見える残高。監視専用ディスクリプタ（監視対象の出力を記述する情報）。`listunspent.spendable=true`
復旧	紛失後にウォレットを再構築できるか	隔離した復元環境で予定の資金を見つけ、少額送金に署名できたこと	テスト出金。一度も確認していないバックアップ。完全な復旧情報を伴わないシードフレーズ

監視専用ウォレットは、署名鍵を持たずに取引を追跡する。PSBT（partially signed Bitcoin transaction、部分署名Bitcoin取引）を使うと、あるウォレットで取引を準備し、別の端末で署名できる。だが、残高が見えることも、PSBTを準備できることも、署名権限の証明にはならない。

10ステップのセルフカストディ検証
#

以下を順に行い、結果に曖昧さがあれば止めること。受領・署名・復旧のそれぞれについて、ウォレットの目立つ残高表示に頼らず説明できる証拠がそろうまで、残りの資金を移してはいけない。

ステップ1：購入記録を保存し、取引所アカウントを守る
#

購入日、数量、法定通貨での価額、手数料、注文IDを含む購入記録を保存する。後で出金記録と取引IDも加える。ただし、シード、秘密鍵、PIN、パスフレーズは同じ場所に保存しない。資金が取引所にあるあいだは、使い回していないパスワードまたはパスキー（端末などで認証するログイン手段）と、強固な多要素認証を使う。

税務ルールは国や地域で異なる。記録は保存し、そのうえで、現在住んでいる地域の税務当局または専門家に、必要な項目と対象となる出来事を確認すること。他国のチェックリストをそのまま使ってはいけない。個人間で買った場合は、本人確認（KYC）なしでBitcoinを買う方法も確認すること。

ステップ2：今日引き受けられる責任の大きさを決める
#

設定を間違えても致命傷にならない金額を選ぶ。ソフトウェアウォレットは利便性を重視しやすい。ハードウェア署名機は鍵を隔離し、独立した画面を持てる。マルチシグは、一つを失っても復旧できる余地を増やす一方、失敗しうる箇所も増やす。どれを選んでも、自動的に安全になるわけではない。

マルウェア、端末の紛失、火災、物理的アクセス、強要、判断能力の喪失、死亡など、実際に備えるべき脅威を書き出す。解除や署名を強制されうるなら、操作を始める前に強要下の管理を扱う脅威モデルを確認すること。

ステップ3：検証できる公式経路からウォレットを入手する
#

プロジェクトの公式サイトまたは公式リポジトリ（ソースコードの保管場所）を使う。ソフトウェアの公開版は、プロジェクトが示す手順で検証する。ハードウェアは梱包状態を確認し、自分で初期化する。あらかじめ書かれたシードフレーズは、決して受け入れない。更新は、製造元が認証した経路だけで行う。

保守状況、バックアップ形式、アドレス確認方法、復旧手順の文書も確かめる。選ぶべきなのはブランドではない。自分で検証し、繰り返せる作業手順である。

ステップ4：ウォレットを作り、復旧に必要な情報をすべて記録する
#

復旧情報は、使用するウォレットまたは署名機の上で生成する。公式手順がオフライン作業を求めるなら従う。写真を撮る、クラウド上のメモに貼る、チャットで送る、ウェブサイトに入力するといったことはしない。信頼できる端末で公式の復旧を自分から始めた場合を除き、シードフレーズを求める要求は、不正なものとして扱う。

「シードフレーズ」とだけ書いて終わってはいけない。BIP39では、その単語列（ニーモニック）と正確なパスフレーズからシードを作る。どのパスフレーズからも有効なシードが生まれるため、入力を間違えると別のウォレットが開く。

BIP380は、鍵だけのバックアップではスクリプト種別や導出情報が欠ける場合があると警告している。ウォレット名とバージョン、バックアップ規格、アカウント、スクリプト（アドレス）種別、鍵の導出経路（ウォレットが鍵を探す道筋）、パスフレーズの要否を記録すること。シードだけでは、別のウォレットで復旧できる保証はない。拡張公開鍵（xpub）や公開鍵だけを含むディスクリプタでは履歴を監視できるが、署名はできない。共有すれば取引履歴のプライバシーも漏れる。秘密鍵を含むディスクリプタは、秘密として扱う。

ステップ5：全額を入れる前にバックアップを確認する
#

製造元に公式のバックアップ確認機能があれば使う。たとえばTrezorのSafe 3の確認手順は、入力したバックアップを端末と照合する。分かるのは、その単語列が端末と一致したことまでだ。パスフレーズや導出情報が正しいこと、復元後に送金できることまでは証明しない。

本物のバックアップを、ウェブサイト、チャット、メモ入力欄、信頼できないコンピューターで試してはいけない。安全な確認機能がないなら、互換性が分かっているハードウェアを使い、隔離した復元を計画する。予行演習で転記ミスは見つけられる。復旧経路全体を試すのはステップ10である。

ステップ6：新しいアドレスを作り、全文字を照合する
#

新しいBitcoin受取アドレスを作る。独立した画面を持つ端末では、そこに出たすべての文字をウォレットアプリおよび取引所の入力欄と照合する。先頭と末尾だけを比べてはいけない。Trezorのウォレットアドレスの解説も、全文字の確認を案内している。端末画面で証明できるのは、その端末が生成した内容である。正しいネットワークや受取人を選んだことまで保証するものではない。

このオンチェーン検証では、送金元と受取ウォレットの双方が同じBitcoinネットワークに対応していることを確認し、オンチェーンのBitcoinを選ぶ。ネットワークが一致しなければ、資金へアクセスできなくなるおそれがある。Lightningなど別の仕組みを意図して使うなら、その公式の受取手順に従う。アドレスの再利用やUTXO（unspent transaction output、Bitcoinが追跡する送金可能な単位）の後日の統合は、取引のつながりを明かすことがある。オンチェーンのプライバシーとSilent Paymentsも参照してほしい。

ステップ7：損失を限定するテスト出金を行う
#

取引所の最低出金額を上回り、現在と将来の手数料を差し引いても使える金額を出金する。最終確認でもアドレス全文を見直す。出金ID、手数料、数量、取引IDは、外部へ漏れない形で記録する。

このテストで限定できるのは、この受領経路でアドレス、ネットワーク、手順を間違えた場合の損失である。手数料次第では、何度も繰り返すのが現実的でないこともある。成功しても、署名や復旧が証明されたわけではない。

ステップ8：受領を証明する
#

金額とリスクに合う承認数まで待つ。取引ID、宛先、出金手数料を差し引いた数量を照合する。承認で分かるのは、取引がブロックチェーンに入ったことだ。バックアップから署名機を再現できるかどうかは分からない。

公開ブロックエクスプローラー（取引検索サービス）より、自分のノードを使うほうが、照会時のメタデータを外部へ明かしにくい。ブロックエクスプローラーには、アドレスと接続元の情報が伝わる可能性がある。残高、ラベル、アドレス、取引IDが写ったスクリーンショットを共有してはいけない。

ステップ9：少額送金で署名を証明する
#

自分が管理する新しいアドレスへ、別の少額取引を準備する。署名機に独立した画面があるなら、宛先全文、金額、手数料をそこで確認する。独立した画面がなければ、宛先は取引を準備するPCやスマートフォン上でしか確認できない。その端末が侵害されていれば、確認結果も信用できない。署名し、ネットワークへ配信し、承認まで確認する。お釣り出力（残額を自分のウォレットへ戻す出力）と、UTXOをまとめることで生じるプライバシーへの影響も確認する。

検証した監視専用ウォレットはPSBTを準備できたが、complete=falseを返した。直接送金は**-4**で失敗した。監視側は要求を準備できるが、取引を承認するのは秘密鍵である。この一連の操作で分かるのは、現在の署名能力までだ。紛失後の復旧は、まだ証明されていない。

ステップ10：復旧を証明し、運用計画を完成させる
#

隔離され、互換性が分かっている環境で独立して復元する。想定どおりのアドレスまたはディスクリプタ、入金済みのUTXOを確認し、すべての出力を照合したうえで少額取引に署名する。端末が壊れる前に試すこと。信頼できる予備端末か、オフライン環境を使う。秘密情報を含まない結果だけを記録したら、復元に使った一時端末を公式手順で初期化する。唯一の有効なバックアップは、決して破壊しない。

私たちは、受取ウォレットへ資金を入れる前にバックアップを作った。復元したウォレットは0.01000000 BTCを見つけ、0.00200000 BTCの送金に署名し、1承認を得た。つまり、このバックアップは検証対象の鍵と署名権限を再生成できた。

運用計画を見直す周期、同じ事故で同時に失われない2か所の保管場所、緊急時の計画を記録する。見つけ方の説明と署名用の秘密は分ける。ウォレットやパスフレーズを大きく変更したら、もう一度演習する。残りの資金には新しいアドレスを使い、確認を最初から繰り返す。テストに成功したという理由だけで、一つのアドレスを使い回してはいけない。

隔離環境のBitcoin Core 31.1検証で分かったこと
#

Bitcoin Coreのローカルな回帰テスト用ネットワーク「regtest」を202.22秒動かし、残高を見る能力と、署名・復旧する能力を切り分けた。実際のBitcoinは使わず、P2Pネットワークを無効にし、最後までnetworkactive=false、接続数は0だった。

Bitcoin Core v31.1.0の配布アーカイブについて、SHA256 b80d9c3e04da78fb6f0569685673418cf686fadba9042d926d13fb87ff503f9eとMichael Fordの署名（E777299FC265DD04793070EB944D35F9AC3DB76A）を照合した。

結果とスクリプトには、鍵、アドレス、取引、バックアップ、認証情報、ホスト識別情報を含めていない。スクリプトは管理権の検証ロジックを一度の新規実行で再現する。JSONは、別途検証したリリースと、測定値を得た2段階の実測を記録している。スクリプトは検証済みのバイナリを使う前提で、アーカイブのチェックサムや署名を再確認するものではない。

検証時の観察	測定結果	安全に言えること
受取ウォレットの残高	0.01000000 BTC	資金を入れたウォレットが、承認済みの出力を観測した
監視専用ウォレットの残高	0.01000000 BTC	秘密鍵がなくても、同じ残高を表示できる
署名の確認	`private_keys_enabled=false`、PSBT `complete=false`、直接送金-4	残高が見えることは、署名権限ではない
`listunspent.spendable`	`true`	証明にはならない。Core 31.1では、この非推奨フィールドが常にtrueだと説明されている
入金前バックアップからの復元	0.01000000 BTCを復元、0.00200000 BTCを送金、1承認	検証したバックアップから、署名に必要な鍵を復旧できた

このregtest実験は論理検証であり、メインネットの性能測定ではない。1承認は、検証を完了させる条件にすぎない。Bitcoin Core 31.1のローカルヘルプでは、listunspent.spendableを「(DEPRECATED) Always true」と説明しているため、署名の合否判定には使えない。この同梱アセットが示すのはv31.1で観察した挙動である。一方、アーカイブ済みのBitcoin Core 30資料はprivate_keys_enabledと監視専用残高の区分を定義し、issue #21104は残高を見られる反例を記録している。だから署名の証明には、フィールド名ではなく、実際に署名した取引を使う。

結論：残りを移す前に、管理権の引き渡しを終わらせる
#

取引所の記録を守れ。引き受けられる管理範囲を決め、全文を照合したアドレスへテスト金額を送れ。その後、受領・署名・復旧を別々に証明せよ。

一つでも失敗したら止まれ。承認済みの出金で証明できるのは受領であって、復旧ではない。形式、設定、パスフレーズが合わなければ、シードだけでは足りない。新しく引き受ける責任を実際に試してから、残りの資金を移せ。

要点

3つの証明：管理権を引き渡すには、受領・署名・復旧を別々に示す証拠が要る。どの残高画面も、3つすべてを証明しない。
残高の罠：Bitcoin Core v31.1.0では、資金を入れたウォレットと監視専用ウォレットの両方に、同じ0.01000000 BTCが表示された。
署名の合格条件：監視専用ウォレットのPSBTはcomplete=falseのままで、直接送金はRPCエラー**-4**で失敗した。
復旧の合格条件：入金前のバックアップから0.01000000 BTCを復元し、0.00200000 BTCの承認済み送金に署名できた。
現地のルール：購入・出金記録を保存し、全世界共通をうたうインターネット上の一覧ではなく、自分の地域の税務当局に従う。

よくある質問
#

答えの境界は共通している。自己管理で変わるのは、誰がリスクを負うかである。テスト出金が証明するのは受領だけで、復旧にはウォレット固有の情報一式が必要になる。

Bitcoinは取引所からすぐに引き出すべきですか？
#

必ずしもそうではありません。取引所での管理には、事業者やアカウントのリスクがあります。急いで自己管理へ移せば、鍵やバックアップを失うリスクがあります。まずアカウントを守り、テスト金額から始めてください。金額を増やすのは、受領・署名・復旧の3つに合格してからにしてください。

ハードウェアウォレットは必要ですか？
#

どの金額にも必要とは限りません。保守されているソフトウェアウォレットは、少額の支払い用残高に合うことがあります。ハードウェア署名機は一部のオンライン攻撃経路を減らし、独立した画面を持てます。ただし、不完全なバックアップを直すことも、強要を防ぐことも、表示内容を代わりに確認することもできません。

テスト出金に成功すれば、自己管理できた証明になりますか？
#

アドレス全文、取引、金額、承認状況が一致すれば、受領の証明になります。監視専用ウォレットも、署名できないまま同じ残高を表示できます。不完全または互換性のないバックアップでは、復旧にも失敗します。3つの検証をすべて行ってください。

どのウォレットでも、シードフレーズからBitcoinを復旧できますか？
#

できません。復旧には規格、正確なパスフレーズ、導出情報、アカウント、スクリプト種別、実装の互換性が関わります。互換性が明記された手順か、元のウォレットの公式手順に従ってください。本物のシードフレーズをウェブサイトへ入力してはいけません。

Bitcoinを買った後、どの税務記録を残すべきですか？
#

購入記録と出金記録を保存し、現在住んでいる地域の税務当局または専門家が求める項目に従ってください。米国向けやインターネット上の一覧を、世界共通だと思わないでください。この記事は、税務上の分類や個別の税務助言を行うものではありません。

Cora Aegis

Cora Aegisは、CypherpunkGuideを執筆するペンネームです。一次資料と再現可能な検証にもとづき、プライバシーを最優先する実践ガイドを書いています。

Coraについてもっと読む →

一次資料とアーカイブ
#

以下の一次資料または公式資料が、安全に関わる主張を支えている。すべての原文・アーカイブの組み合わせには正確なタイムスタンプがあり、再生時の同一性も確認済みである。

#	出典	原文URL	アーカイブ
1	SEC「Crypto Asset Custody Basics for Retail Investors」（2025）	https://www.investor.gov/introduction-investing/general-resources/news-alerts/alerts-bulletins/investor-bulletins/crypto-asset-custody-basics-retail-investors-investor-bulletin-0	https://web.archive.org/web/20260718185151/https://www.investor.gov/introduction-investing/general-resources/news-alerts/alerts-bulletins/investor-bulletins/crypto-asset-custody-basics-retail-investors-investor-bulletin-0
2	Bitcoin Core 30 `getwalletinfo`	https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getwalletinfo/	https://web.archive.org/web/20260217150325/https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getwalletinfo/
3	Bitcoin Core 30 `getbalances`	https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getbalances/	https://web.archive.org/web/20260509142424/https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getbalances/
4	Bitcoin Core issue #21104、監視専用残高の分類	https://github.com/bitcoin/bitcoin/issues/21104	https://web.archive.org/web/20221205111908/https://github.com/bitcoin/bitcoin/issues/21104
5	BIP32、Hierarchical Deterministic Wallets	https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki	https://web.archive.org/web/20260711030310/https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
6	BIP39、Mnemonic code for deterministic keys	https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki	https://web.archive.org/web/20260711080112/https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
7	BIP380、Output Script Descriptors	https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki	https://web.archive.org/web/20260705135907/https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki
8	Trezor、ウォレットアドレスと全文字の確認	https://trezor.io/learn/basics/where-are-my-coins-stored-how-bitcoin-wallets-actually-work	https://web.archive.org/web/20260519102414/https://trezor.io/learn/basics/where-are-my-coins-stored-how-bitcoin-wallets-actually-work
9	Trezor、出金ネットワークの選び方	https://trezor.io/guides/sending-receiving-staking-funds/moving-funds-from-exchanges/how-to-choose-the-right-network-when-withdrawing-from-or-sending-to-trezor	https://web.archive.org/web/20260215225443/https://trezor.io/guides/sending-receiving-staking-funds/moving-funds-from-exchanges/how-to-choose-the-right-network-when-withdrawing-from-or-sending-to-trezor
10	Trezor Safe 3、ウォレットバックアップの確認	https://trezor.io/guides/backups-recovery/general-standards/check-backup-on-trezor-safe-3	https://web.archive.org/web/20260207110415/https://trezor.io/guides/backups-recovery/general-standards/check-backup-on-trezor-safe-3
11	Trezor、パスフレーズの動作	https://trezor.io/guides/backups-recovery/advanced-wallets/what-is-a-passphrase	https://web.archive.org/web/20260312222704/https://trezor.io/guides/backups-recovery/advanced-wallets/what-is-a-passphrase

Bitcoinパスワード復旧：AIにできること、できないこと（2026年）

Sun, 23 Aug 2026 00:00:00 +0000

資金について：CypherpunkGuideは、広告ネットワーク、トラッキングピクセル、スポンサー記事などの監視型広告を載せていない。現在は読者の寄付で運営し、将来は購読と編集方針に沿うアフィリエイト収入も充てる。私たちが向き合う相手は広告主ではなく読者である。今回の検証について、復旧業者やウォレット事業者から報酬を受けていない。

「Bitcoinのパスワードを失った」と言っても、起きていることは一つではない。取引所アカウントへログインできないのか、暗号化されたウォレットファイルのパスワードを忘れたのか、BIP39パスフレーズが分からないのか、復旧用の単語やバックアップ自体を失ったのか。Bitcoin Coreには、忘れたウォレットパスフレーズを再設定したり表示したりする機能がない。ただし、記憶から小さく絞った候補をオフラインで試せる場合まで否定するものではない（Bitcoin Core「Managing the Wallet」）。

危険なのは、「AI復旧なら暗号そのものを突破できる」という売り文句だ。そんなことはできない。私たちは、ウォレット、シード、鍵、アドレス、ハッシュ、資金、実在するパスワードを一切使わず、BTCRecoverで架空データだけの候補生成テストを11回行った。記憶している構造を条件に加えると、ある架空の候補集合は2,080件から16件へ減った。一方、誤入力の種類を5つ有効にし、変更回数を1回から2回へ広げると、別の候補集合は60件から1,681件へ増えた。

問うべきは「どのAIならウォレットを破れるか」ではない。確認するのは、何を失ったのか、秘密でないどの証拠で候補を減らせるのか、解除に必要な一式をどこで初めてそろえるのかである。ここでいう「解除に必要な一式」とは、暗号化されたウォレットまたはシードと、解除に足りる実際の候補情報の組み合わせだ。両者は、オフライン検証まで分けておく。

Bitcoinのパスワードは本当に復旧できるのか
#

Bitcoinのパスワード復旧は、正しい暗号化ウォレットに候補を照合する作業であり、パスワードの再設定ではない。 正しい暗号化データが残り、記憶から候補を現実的な件数へ絞れる場合に限って、復旧の可能性がある。失われた鍵そのものや、手掛かりのない無作為なパスワードを、AIや計算機がゼロから再現することはできない。

まず、どの段階でアクセスできなくなったかを特定する。呼び方を間違えると、選ぶべき手段も間違い、詐欺へ誘導されることさえある。

ニーモニックは、復旧用の単語を順番どおりに並べたバックアップである。シードは、ニーモニックと必要に応じてパスフレーズから作る、すべての鍵のもとになる秘密情報だ。ウォレットはシードから、送金を承認する秘密鍵を導き出す。

失ったもの	何へのアクセスを決めるか	最初に取るべき手順	してはいけないこと
取引所・管理型アプリのログイン情報	事業者アカウント	事業者の公式アカウント復旧を使う	「ウォレット解除ツール」を入れたり、見知らぬ相手へログイン情報を渡したりしない
暗号化ウォレットファイルのパスワード	ローカル保存された秘密鍵の復号	元のファイルを保存し、形式を特定して、複製に対して記憶した候補を試す	元ファイルを上書きしたり、候補パスワードと一緒にアップロードしたりしない
BIP39パスフレーズ	同じニーモニックから別のシードを導出	正確なニーモニックと、既知のアドレスまたは拡張公開鍵（資金は動かせないが、アドレス履歴を明かしうる公開情報）を使い、すべてオフラインで照合する	パスフレーズの誤りを知らせるエラーは出ない。どのパスフレーズからもシードが生まれる
欠けた、または誤記したニーモニック	シードの再構築	既知の照合先を用意し、ウォレット固有の復旧手順を使う	単語をウェブサイトやクラウドAIへ貼らない
ウォレットファイルそのもの	暗号化された鍵情報の所在	元の内容を変更せず、古い端末とバックアップを探す	パスワード探索で、存在しないファイルを補えると思わない
盗難・詐欺で移動したBitcoin	別の鍵へ移った管理権	関係する取引所、捜査機関、地域の専門家へ速やかに届ける	追跡・法的回収と、忘れたパスワードの照合を混同しない

BIP39パスフレーズは、ニーモニックと組み合わせてウォレットのシードを作る任意の文字列である。BIP39では、どのパスフレーズからも有効なシードが生まれる。入力を間違えてもエラーにならず、通常は意図したものとは別のウォレットが導き出される。これは、暗号化されたwallet.datを正しいパスワードで開けるかという問題とは異なる。

独立したバックアップと復旧検証がまだない場合は、Bitcoin購入後の10ステップで、同じ事故を繰り返さないための手順を確認できる。

2026年に報じられたAI復旧で、実際に起きたこと
#

2026年の「AIがBitcoinウォレットを破った」という報道で起きたのは、暗号の突破ではなく、古いバックアップの発見だった。 CoinDeskによると、Claudeが以前のウォレットバックアップを見つけ、所有者は以前から書き留めていたパスワードで復号した。AIが暗号を解読した事例でも、他のウォレットの復旧率を示す事例でもない。

決定的だったのは、古いバックアップを見つけ、既存のパスワードを使えたことである。一般論として、AIは秘密でないファイル情報を比較したり、記憶の抽象的なパターンを候補のひな型へ落とし込んだりできる。候補が正しい鍵情報を復号するかを決めるのは、あくまでウォレットソフトウェアだ。

passwordlistは、1行に完成した候補を1件ずつ書く一覧である。tokenlistは、BTCRecoverが組み合わせて候補を作るための、記憶した断片の一覧である。

AIが手伝えること	AIだけでは確定できないこと	秘密を増やさず確認する方法
秘密でない情報からウォレット形式を分類する	そのウォレットの所有権	来歴の記録と、元媒体のオフライン確認
記憶したパターンをpasswordlistやtokenlistのひな型にする	正解が一覧に含まれること	オフライン端末で`--listpass`を使い、ウォレットを読まずに候補と件数を確認する
名前、日付、容量からバックアップ候補を探す	対象の鍵がファイルに含まれること	形式に合う解析と、既知のアドレスなど公開情報による照合
公式ツールの選択肢を説明する	生成したコマンドが対象ウォレットに安全であること	同じ版の公式資料と、使い捨ての試験用コピー
秘密を除いたエラーから失敗原因を整理する	失われた秘密そのもの	固定したソフトウェアでの成功確認と、自分で管理する宛先への少額送金

この事例が示すAIの強みは、失われた手掛かりを探すことにある。成功率の推定でも、再現可能な性能試験でも、古いパソコンの中身をクラウドAIへ丸ごと送ってよいという許可でもない。古いディスクには税務記録、本人確認書類、ブラウザの設定や利用記録、別のウォレット、パスワードの痕跡が残りうる。ディスクや実際の復旧情報をアップロードしてはいけない。AIアシスタントのプライバシー監査と同じく、クラウドには抽象的なパターンと架空の置き換え文字だけを渡す。

AIは候補を整理し、ソフトウェアが正誤を判定する
#

AIを使っても、パスワードの正誤を判定するのは、同じ入力へ同じ結果を返す照合ソフトである。 AIができるのは、候補の作り方や試す順序を整理することまでだ。ウォレットを実際に復号できるかはBTCRecoverやHashcatが判定するため、候補の中に正解がなければ、AIを加えても結果は変わらない。この境界は変わらない。

試しうる候補がほぼ無限にあるなら、AIに候補を並べさせても件数は減らない。手掛かりのない強いパスワードを、AIの説明だけで現実的に検索できる規模まで縮めることはできない。

BTCRecover 1.13.0が公開した2026年7月4日のベンチマークでは、各テストを30秒間測定した。Windows 11、Ryzen 9 9950X、RTX 5090を使い、Bitcoin CoreのSQLiteサンプルで毎秒3,209.22件、Berkeley DB（BDB）サンプルで毎秒11,948.17件を測定している（結果JSON）。Bitcoin Coreはウォレットを暗号化するとき、鍵を導き出す計算の負荷を調整する。したがって、このサンプルで計算を繰り返した回数や測定速度を、BDB・SQLiteという形式に固有の値や、すべてのCoreウォレットに共通する速度として扱ってはいけない（Coreソース）。

それでも規模は分かる。同じ毎秒3,209.22件で、英小文字10文字の全組み合わせ26^10、つまり141,167,095,653,376件を最後まで試すには、約1,393.9年かかる。正解が各位置に同じ確率で現れると仮定しても、平均で約697.0年である。これは一つのサンプルと人工的な候補集合の計算であり、人間のパスワード習慣を表すものではない。

BTCRecoverはAI向け手順の評価表も公開している。表の割合は、作業手順の採点上限に対する得点率であり、復旧できたウォレットの割合ではない。公式のChat版とDocker版の表から差を計算すると、掲載された6モデルのうち5モデルでDocker版がChat版より低く、差の中央値は**-3.7ポイント**だった。

BTCRecover表のモデル	Chatスコア	Docker／ツール実行スコア	差
qwen3.6-27b	70.9%	58.4%	-12.5ポイント
gemma-4-31b	67.5%	65.0%	-2.5ポイント
gemma-4-26b-a4b	57.6%	39.9%	-17.7ポイント
gemma-4-12b	54.2%	51.7%	-2.5ポイント
qwen3.5-9b	52.4%	47.5%	-4.9ポイント
gemma-4-e4b	30.8%	33.4%	+2.6ポイント

この表から、ツールを使うと一般にモデルが悪くなるとは言えず、5モデルの点数が下がった原因も分からない。Chat版はツールを使わず助言を返す。Docker版では、評価対象のモデルが外部から隔離した環境でコマンドを実行でき、実行方式ごとの採点指示も加わる。二つの評価は、モデルに求める行動も採点方法も同じではない。したがって、ツールを実行させたことだけが点差の原因だとは言えない。BTCRecoverのAI手順は、作業手順に制約を設けている。

BTCRecoverで架空データを11回検証して分かったこと
#

Coraは架空データだけを使い、記憶している条件が候補数をどう変えるか、11通りの生成方法で測定した。 ウォレット、シード、鍵、アドレス、ハッシュ、資金、実在するパスワードは一切使っていない。この検証が示すのは候補生成の件数であり、復号速度や現実のウォレット復旧率ではない。現実のウォレット全般には一般化できない。

BTCRecoverの公式リポジトリから、ソースコードの特定時点を示すコミット1457088acf17630eb12a5b53989982ac34e55f2aを取得した。リポジトリ全体の状態を示す識別値、追跡対象ファイルに変更がないこと、起動スクリプトと検証スクリプトのSHA-256値（ファイル内容の変化を検出する暗号学的ハッシュ値）も記録した。Python 3.12.10上のBTCRecover 1.13.0-Cryptoguideで、11通りの--listpassを実行した。どの実行でも架空の正解候補が残り、同じ実行内に重複候補はなかった。

条件をそろえるため、単語2系統にそれぞれ2候補、年2候補、記号2候補という4種類の断片を固定した。そのうえで、分かっていることを一つずつ加えた。

候補の作り方	重複を除いた候補数	架空の正解を保持	無条件の組み合わせからの変化
関連する8断片を別々の行に置く	2,080	はい	基準
同系統の候補を同時に使わない	632	はい	69.62%減
4種類すべてを必須にする	384	はい	81.54%減
必須にしたうえで記憶した位置へ固定する	16	はい	99.2308%減

最後の候補集合は、最初の130分の1だった。ただし、記憶が常に正しいことを示す結果ではない。重要なのは、確かに覚えている条件と、期待にすぎない条件を分けることである。

別の検証では、16文字の架空パスワード候補を一つ固定した。誤りを1種類だけに絞った4つの検索は、それぞれ12〜17件だった。誤入力の種類を5つ同時に有効にすると、変更1回で60件、変更2回で1,681件になった。後者は前者の28.02倍である。

したがって、最初は完成した候補をそのまま試し、次に可能性の高い誤りを1種類だけ加え、広い組み合わせは最後へ回すべきだ。AIは、候補をこの順序で作るための設定や手順を整理できる。しかし、経歴から推測した単語や日付を勝手に作り、それを本人の記憶として扱ってはいけない。

個人情報を含まない結果JSONと検証スクリプトを公開資料として同梱した。入力は固定した架空文字列だけである。スクリプトの警告抑制フラグは、ウォレットを読み込まない候補列挙に限って使っている。実際の復旧コマンドへ流用してはいけない。

BTCRecover、Hashcat、ローカルAI、復旧業者を比べる
#

選ぶべき手段はウォレット形式に合い、秘密情報を相手へ最も渡さずに済むものである。 BTCRecoverとHashcatは候補を照合し、AIは候補作成を補助する。復旧業者へ頼む場合は、技術上の適合だけでなく、その業者へ何を預け、どこまで信頼するかも判断しなければならない。知名度ではなく、対応形式と秘密情報の境界で選ぶ。

Hashcatの**mode（モード番号）**は、保存されたウォレットやハッシュの形式に合う照合方法を選ぶ番号である。正しいパスワードを選ぶ番号ではない。

手段	向く状況	主な利点	主な限界	秘密情報の境界
BTCRecover passwordlist	完成した候補が数件ある	各行をそのまま試し、限定した誤入力規則も加えられる	完成済み候補を断片として組み替えるものではない	オフライン実行までウォレットまたは公式資料に定義された縮小データと分ける。縮小データにも識別・関連付け情報が残りうる
BTCRecover tokenlist	断片、表記違い、位置を覚えている	排他的な候補、必須条件、位置、ワイルドカード（任意の文字パターン）で記憶を表現できる	条件を誤ると正解を除外し、広げすぎると件数が急増する	オンラインでは架空の置き換え文字でひな型だけ作り、実際の断片はウォレットがあるオフライン環境で入れる
Hashcat	対応modeと、文字パターンまたは候補変更規則を確認できる	GPU（並列計算向けの処理装置）を使う成熟した照合機能と明示されたmode一覧	対応modeがあっても復旧できるとは限らず、抽出方法と規則は形式ごとに違う	公式のmode資料どおりに扱い、解除に必要な一式をアップロードしない
ローカルAI	分類、ファイル探索、ひな型作成、コマンド確認	ローカルファイルを扱い、手順を状況に合わせられる	「ローカル」という名前だけでは、オフラインであること、ログを残さないこと、安全であることを意味しない	通信状態、モデルの実行場所、ログ、拡張機能、作業フォルダーを確認する
クラウドAI	秘密でない説明と架空のひな型作成	限定した資料の質問に使いやすい	事業者へ入力内容、添付ファイル、アカウント情報、接続元情報が渡り、保存される可能性がある	抽象的なパターンと架空の置き換え文字だけを渡す。実際の候補文字列、ウォレット、ニーモニック、シード、鍵、パスワードは渡さない
人間の復旧業者	高額で技術的に難しく、十分な確認を済ませた案件	形式に関する専門知識と機材	詐欺、不透明な手法、料金争い、本人情報の露出、鍵の盗難	資金を動かせないと資料で確認できる縮小データを優先するか、不可欠な一要素を自分で保持する。それでも縮小データはプライバシー上の機微情報になりうる

Hashcatの公式ハッシュ例一覧には、Bitcoin Core／Litecoinのwallet.dat、Electrum、Blockchain.com／My Wallet、Bisqなどのmodeが載っている。分かるのは照合機能が実装されていることまでだ。バックアップが壊れていないこと、候補内に正解があること、選んだmodeが自分のファイルに合うことは証明しない。

オフライン優先で進める7段階の復旧手順
#

暗号化ウォレットまたはシードと実際の候補は、通信を切った端末で照合する直前まで分けておけ。 オンラインで扱うのは、秘密を含まない事実と架空のひな型までにせよ。両者を同じ端末へ置くなら、先に通信を切れ。クラウドへ渡した後でオフラインにしても、すでに起きた開示は取り消せない。秘密を開示する前に、この境界を決めよ。

元データを変更するな。 古い端末を保存し、可能なら1バイトも変えない複製または資料に沿った方法で作業用コピーを作れ。各ファイルの暗号学的ハッシュ値（内容の変化を見分ける要約値）を記録し、唯一のウォレットを直接修復、移行、読み込みしない。
ソフトウェアを選ぶ前に、何を失ったか分類せよ。 ウォレット製品とおおよその版、OS、ファイル名と容量、作成時期、ニーモニックの有無、正確なエラーなど、秘密でない事実を記録する。同じオンラインメモへシード、パスフレーズ、秘密鍵、候補を書かない。
権限と照合先を確定せよ。 自分が所有するか、法的に復旧を認められたウォレットだけを扱う。秘密を含めず、所有権、権限、ファイル来歴の最小限の記録をオフラインで残す。シードやBIP39パスフレーズを探す場合は、アドレスを導出するアカウントと経路の規則、既知の公開照合先を特定する。アドレス履歴全体を外へ広めない。
オンラインのうちに、公式経路からツールを入手し検証せよ。 保守されているプロジェクトの公式リポジトリから始める。コミット（ソースコードの特定時点を示す識別子）を固定し、追跡対象ファイルに変更がなく、リポジトリ全体の状態がそのコミットと一致することを確認する。署名付きリリースの手順があるなら使う。インストール確認には付属の架空データを使い、自分のウォレットを使わない。
確かな記憶だけで、最小の候補段階を作れ。 完成した候補はpasswordlistへ、組み合わせる断片はtokenlistへ入れる。完全一致、記憶している不確実性1つ、広い誤入力・ワイルドカード（任意の文字パターン）の順に試す。オンラインでは架空の置き換え文字を使い、ウォレットやシードがある端末へ実際の候補を入力しない。
解除に必要な一式は、オフラインでのみそろえよ。 暗号化ウォレットと実際の候補を同じ端末へ置く前に通信を切る。長い実行を始める前に候補数を確認する。BTCRecoverは一部形式について、照合に必要な一部だけを取り出したウォレット抽出データを説明している。現行の公式資料が単体では資金を動かせないと明記している場合だけ使い、それでも識別・関連付けが可能な機微情報として扱う。
解除に成功したら、新しい環境へ移せ。 信頼できるウォレットで新しい復旧方法を作って検証し、宛先と手数料を確認してから資金を移す。残すのは秘密を含まない作業記録であり、復旧したパスワードや秘密鍵ではない。関連する認証情報の変更にはパスワードマネージャー移行監査を使う。

「クラウドAIに全部見せ、最後のコマンド直前にオフラインへ切り替える」という手順は成立しない。開示はすでに終わっている。クラウドAIには、ウォレットを伴わない実在の候補一覧さえ渡さず、抽象的な構造と架空の置き換え文字だけを渡す。AI時代の脅威モデルを使い、モデルの実行場所、ログ、追加機能、同期フォルダー、アカウント情報を整理してから、AIを「ローカル」と判断せよ。

復旧業者へウォレットを丸ごと渡さずに評価する
#

復旧業者を選ぶ作業は、秘密情報を誰に預けるかの監査である。 成功談の派手さではなく、資金を解除して移動できる全要素を受け取らずに、業者がどこまで作業できるかを確認せよ。ウォレットと有力な候補の両方を求めるなら、その依頼は単なる技術支援ではない。鍵の管理権を預けるのと同じ判断として扱え。委託前に契約で確かめよ。

FBIの暗号資産回収詐欺に関する警告は、主に投資詐欺で失った暗号資産を取り戻すとうたう業者を扱っている。FTCの回収詐欺に関する案内も、突然の連絡、前払い、成功保証、金融情報の要求を警告する。これらの資料だけで、忘れたパスワードを扱う業者がすべて詐欺だとは言えない。ただし、確認すべき警戒の兆候は共通する。

次の質問には、書面で回答を求める。

対応するウォレット形式と版は何か。秘密情報を受け取る前に、形式が合うとどう確認するのか。
単体では資金を動かせないと資料で確認できる縮小データだけで作業できるか。そこにはどの識別・関連付け情報が残るか。難しいなら、解除に不可欠な一要素を自分で保持できるか。
ウォレット、候補一覧、鍵、ログ、バックアップが、クラウドストレージ、遠隔操作ソフト、再委託先、AI事業者へ渡ることはあるか。
料金はどう計算し、結果が出る前に何を支払うのか。契約上の「成功」は何を意味するか。
資金を移す前に、復旧した鍵を管理するのは誰か。自分で用意した新しいウォレットを最初の送金先に指定できるか。
削除、保存期間、事故対応、責任範囲は契約に明記されているか。
体験談だけでなく、確認可能で一貫した法人名または事業者情報、技術手法、独立した履歴を示せるか。

ウォレットの状態やパスワードの予測しにくさを無視した成功保証は拒否せよ。突然の勧誘、急がせる圧力、遠隔操作の要求、ウォレットと候補パスワードの両方を求める行為は、高リスクの兆候として扱う。技術力がある業者でも、現実的に試せる候補の外にある秘密は復旧できない。

結論：何を失ったか、秘密をどこまで見せるかで選べ
#

まず、失ったものを分類せよ。次に、秘密情報をどこまで見せるかで手段を選べ。 管理型アカウントなら事業者の公式復旧、ローカルウォレットなら形式に合う照合ソフトを使え。AIは秘密を含まない計画だけに使え。暗号化ウォレットまたはシードと実際の候補を組み合わせる照合は、通信を切った端末に限れ。候補数を確認してから実行せよ。

ウォレット形式がBTCRecoverに対応し、完成した候補や断片として記憶を表せるならBTCRecoverを使え。Hashcatは、対応modeを確認でき、抽出データの内容を理解している場合に検討せよ。実際の照合はオフラインで行え。

ウォレット自体を特定できないなら、推測を始める前に元媒体を保存し、バックアップを探せ。クラウドAIへ実際のウォレット情報や候補文字列が渡るなら止まれ。業者へ不可欠な要素をすべて渡すなら、それは鍵の管理権を渡すのと同じだ。手順を組み直せ。どうしても渡すなら、そのリスクを明示的に引き受けよ。役に立つ条件が一つもない無作為なパスワードは、ハードウェアやAIを替えても現実的に復旧できない場合がある。

要点

分類が先： 管理型ログイン、ウォレットファイルのパスワード、BIP39パスフレーズ、ニーモニックの欠落、バックアップの紛失では、復旧手順が異なる。
AIに暗号を破る近道はない： AIは文脈を探し、候補を整理できる。正誤は固定したソフトウェアが判定し、手掛かりのない強い秘密は現実的に試せない。
構造で候補は減る： 11回の架空検証では、正解候補を残したまま2,080件から16件へ、**99.2308%**減った。
候補数は急増する： 誤入力5種類で、変更1回は60件、変更2回は1,681件となり、後者は前者の28.02倍になった。
秘密の境界： クラウドAIへ渡すのは抽象的なパターンと架空の置き換え文字だけ。実際のウォレットまたはシードと実際の候補は、オフラインでのみそろえる。

よくある質問
#

AIが役に立つのは、記憶や既存の証拠によって候補数を有限に絞れる場合だけである。BTCRecoverはパスワードを再設定せず、BIP39パスフレーズの照合には既知の対象が要る。クラウドAIへ渡せるのは抽象的なパターンと架空の置き換え文字だけだ。解除に成功した後も、同じウォレットを使い続けず、新しい環境へ移す必要がある。

AIで忘れたBitcoinウォレットのパスワードを復旧できますか？
#

場合によっては、実行可能な検索へ絞るための文脈を探せます。古いファイルの場所、パスワードの構造、誤入力の癖、公式ツールの選択肢などです。ただし、ウォレットからランダムで予測しにくいパスワードを導き出したり、暗号化を迂回したりはできません。固定したソフトウェアが、実際に正しい候補を試す必要があります。

BTCRecoverなら、どんなBitcoinパスワードでも総当たりできますか？
#

できません。BTCRecoverは多くのウォレット形式に対応し、候補を効率よく生成できます。それでも、正しいウォレット情報、対応形式、有効な照合先、現実的な時間で終わる候補数が必要です。ツールが形式へ対応していることは、復旧の保証ではありません。

BIP39パスフレーズとウォレットのパスワードは同じですか？
#

同じではありません。ウォレットのパスワードは、通常、保存された鍵情報を復号します。BIP39パスフレーズはニーモニックと組み合わせてシードを導き出します。どの文字列でも有効なシードになりますが、通常は意図したものとは別のウォレットを導き出します。復旧には正確なニーモニックと既知の照合先が必要で、すべてオフラインで扱います。

復旧業者へ`wallet.dat`を渡しても安全ですか？
#

暗号化されたウォレットファイルも機微情報です。Bitcoin Coreの資料では、暗号化が守るのは秘密鍵であり、データベース内のすべてではなく、取引情報は見えると説明されています。公式資料が単体で資金を動かせないと明記する縮小データを優先し、それでもプライバシー上の機微情報として扱ってください。業者が解除に必要な一式を求めるなら、鍵の管理権をすべて預けるのと同じです。

復旧に成功した直後、何をすべきですか？
#

信頼できる機器で新しいウォレットと復旧方法を作り、検証してください。宛先と手数料を確認してから資金を移します。古いパソコン、候補ファイル、ログ、関与した第三者によって、秘密情報に触れた範囲が広がったと考えてください。一度開けたという理由だけで、古い環境を使い続けないでください。

Cora Aegis

Cora Aegisは、CypherpunkGuideを執筆するペンネームである。一次資料と再現可能な架空データ検証にもとづき、プライバシーを最優先する自己管理ガイドを書いている。

Cora Aegisについて詳しく読む →

出典とアーカイブ
#

本記事の主張は、公式ソフトウェア資料、仕様、政府機関の詐欺警告、および対象を一つの事例に限定した報道1件にもとづく。12件の原文URLが表示できることは2026年8月21日と2026年8月23日に確認した。下記の日時固定Wayback保存版は、2026年8月23日に12件すべてHTTP 200で再生できることを確認した。

#	出典	原文URL	アーカイブ
1	Bitcoin Core「Managing the Wallet」	https://github.com/bitcoin/bitcoin/blob/bf8402c8803f085a50df96cb7956033cd252e9ab/doc/managing-wallets.md	Wayback
2	BTCRecoverリポジトリとREADME	https://github.com/3rdIteration/btcrecover/tree/1457088acf17630eb12a5b53989982ac34e55f2a	Wayback
3	BTCRecover Password Recovery Quickstart	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/docs/TUTORIAL.md	Wayback
4	BTCRecover AI-Assisted Recovery	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/docs/AI_Assisted_Recovery.md	Wayback
5	BTCRecover `SKILL.md`	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/SKILL.md	Wayback
6	BTCRecover Performance Benchmarksと結果JSON	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/benchmark-results/benchmark_9e6d7d9006b08e8e_20260704_154622.json	Wayback
7	Hashcat example hashesとwallet mode	https://hashcat.net/wiki/doku.php?id=example_hashes	Wayback
8	BIP39「Mnemonic code for generating deterministic keys」	https://github.com/bitcoin/bips/blob/7fe0b034ec967b52a5a28276419117326df93263/bip-0039.mediawiki	Wayback
9	FBI／IC3、暗号資産回収詐欺の警告	https://www.ic3.gov/PSA/2023/psa230811	Wayback
10	FTC「Refund and Recovery Scams」	https://consumer.ftc.gov/articles/refund-and-recovery-scams	Wayback
11	CoinDesk、Claudeが関わった2026年のウォレット復旧報道	https://www.coindesk.com/tech/2026/05/14/claude-helps-recover-usd395-000-in-bitcoin-trapped-on-a-computer-for-years	Wayback
12	Bitcoin Coreのウォレット暗号化ソース	https://github.com/bitcoin/bitcoin/blob/bf8402c8803f085a50df96cb7956033cd252e9ab/src/wallet/wallet.cpp	Wayback

Methodology — KYC Driftがhosted AI事業者の主張を記録する方法

Tue, 14 Jul 2026 00:00:00 +0000

パイロットの状態： 証拠に基づくパイロット：現行の記録は44件、対象は8サービスです。うち事業者の公表文書に基づく記録が44件、画面上の実地観測が0件です。サービス×比較項目の45/136セルに、少なくとも1件の現行の範囲付き記録があります。全地域・全プラン・全画面を網羅する値ではありません。

開示事項：本ページの性質 · アフィリエイト · 訂正窓口

本ページは事実の記録です。助言・推奨・勧誘・保証ではなく、掲載は承認を意味しません。ポリシーは変わるため、値に依拠する前に事業者の一次文書を確認してください。
現在、掲載サービスとのアフィリエイト関係は一切ありません。将来導入する場合は該当箇所に明記し、掲載や並び順には影響させず、変更はこのページに記録します。
掲載事業者または読者が値に誤りがあると考える場合は、次の窓口へ連絡できます。確認の結果、データセットの誤りと判断した場合は公開訂正します。連絡先： editor@cypherpunkguide.com
データの収集・確認方法（方法論）

現行パイロットの状態
#

現行版は証拠付きパイロットであり、市場全体を網羅する監査ではない。hosted AI 8サービスについて44件の現行記録がある。44件全てが事業者の公表文書に基づき、製品画面の実地観測は0件だ。判定軸は17次元で、サービスとの組合せは136欄になる。45欄には適用範囲付きの現行記録が1件以上あり、91欄にはない。この数は収録状況であり、割合による網羅度や全範囲の調査完了を意味しない。

記録する単位
#

基本単位は、一つのサービスについて、特定の属性・利用段階・適用範囲を記述する個別の事実記録だ。利用段階は登録、継続利用、決済、復旧、削除に分ける。一つの記録に、事業者が述べる要件、情報の収集・確認方法、ひも付く先と受領者、対象地域・プラン・利用形態・登録方法、日付、根拠資料を持たせる。

追記型の履歴を保証するのは2026年7月26日以降である。それ以前の44件は従来データをまとめた基準版（legacy baseline）であり、完全な変更履歴とは主張しない。同日以降にポリシーが変わった場合は、古い記録を削除せず、新しい記録にどの過去記録を置き換えるかを明示する。こちらの記録ミスを直す場合も、どの記録を訂正したかを示す。現在値の比較画面はこの履歴から生成するもので、履歴そのものの代わりにはならない。

意図的に測らないもの
#

通信経路上の匿名性。 IPアドレス、端末の識別情報、Tor/VPNへの対応、サイトの利用状況計測は別の層だ。事業者が公表する通信データの記載を別枠で記録する場合はあるが、どの欄も通信経路上の匿名性を保証しない。
決済仲介者への情報開示。 事業者が特定の決済手段を受け付けるという記載は残せる。仲介者が支払者について何を知るかは対象外だ。
法的手続によるアクセス。 公称法人と管轄は記録できる。裁判所命令や国家安全保障手続で何に到達できるかまでは断定しない。
内部システムでの実施状況。 ポリシーは事業者が公表した内容を示す。製品や内部システムがそのとおり動いたことまでは証明しない。

値の情報源
#

事業者文書と管理された製品画面の観測は、上下関係のある情報源ではない。それぞれ別の問いに答える証拠の役割だ。

事業者文書は、事業者がポリシー、規約、ヘルプ資料で何を公表したかを示す。事業者の記載から作る事実が支えられるのは、その文面と適用範囲までである。
管理された製品画面の観測は、日付、地域、プラン、利用形態、登録方法などを固定した一つの経路で何が起きたかを示す。観測記録には、確認済みの検証資料を保存し、そのハッシュ値を公開用マニフェスト（公開内容との結び付けを記録する一覧）へ登録する。その観測結果を範囲外へ一般化しない。
事業者サポートの回答、画面のアーカイブ、第三者報告は調査課題の発見や記録の補強には使える。ただし、適切な役割の要件を満たす証拠として登録されない限り、表示値にはしない。

どちらか一方を、もう一方の値で黙って上書きすることはない。現行のP0公開経路（初期実装段階）では、同等の適用範囲で事業者文書と管理された観測が食い違った時点で、その版の公開を保留する。二つは別々の証拠系列に残して判定を待つが、新たな矛盾状態はまだ公開しない。P1で追記型の構造化された矛盾関係を導入した後は、一方で他方を上書きせず、両方の記録を並べて公開できる。現行パイロットは事業者文書のみで、製品画面の実地観測は0件だ。

「収集する」と「必須である」も分ける。プライバシーポリシーに電話番号を収集する場合があると書かれていても、登録時に必須とは限らない。事業者の記載では、文書が義務を明記した場合だけ必須とする。画面上の実地観測では、定義した経路が入力なしに先へ進めないことを示した場合だけ必須とする。

統制語彙と空欄を作らない規則
#

欄には、必須 · 任意 · 条件付き · 利用可 · 入力時に収集 · 収集する場合あり · 未評価 · 矛盾 · 地域依存 · プラン依存 · 非該当などの統制語彙を使う。

未評価は、そのサービスと次元について、表示された適用範囲に対応する現行記録がないことを示す。
矛盾は予約済みだが、現行パイロットでは未使用の統制語彙だ。P0ではこの値を新たに登録できず、同等の適用範囲に食い違いがあれば公開を保留する。P1で追記型の構造化された矛盾関係を導入し、両方の記録を結び付けられる段階で使用する。
非開示は現行パイロットでは未使用の予約語だ。定義した文書群全体を評価した記録が必要であり、現在集めた事実に記載がないだけでは使わない。

空欄は使わない。文書が沈黙していることと、こちらの調査が届いていないことは別の状態であり、どちらも「要件なし」の証拠にはならない。

証拠、日付、完全性
#

事業者文書では、次の規則を使う。

アーカイブ優先。 事業者のページはウェブアーカイブを経由して取得し、こちらのインフラから事業者の最新ページを直接取得しない。引用する記録はアーカイブ版だ。
本文確認。 現行の事実が使う引用の全てが、デコード後のアーカイブ本文に残っている場合だけ、現行主張を支える証拠として扱う。最初の取得と、現行主張を支える最新の再確認は分けて表示する。
sha256の役割。 sha256は、保存したデコード後のアーカイブ本文を照合するハッシュ値だ。保存済みコピーのバイト列が変わっていないかを確認できるが、そのバイト列が取得時点に存在したことは単独では証明しない。
取得時刻の根拠。 取得日時はWaybackの記録に基づく。暗号学的な時刻証明は未実装であり、既存の取得物を、取得時点の暗号学的証明付きとは説明しない。
引用と保管。 短く整形した引用は原文のまま保存する。依拠した本文は手元にも保管し、アーカイブへのリンク切れで記録が失われないようにする。

管理された製品画面の観測では、実行条件と結果を記録し、リポジトリ管理下の指定されたinterface-runs/保存先に確認済みの検証資料を保管し、そのハッシュ値を公開用マニフェストへ登録する。文書アーカイブと画面観測の検証資料は、完全性の確認方法が異なる別々の証拠系列である。

発効日と表示するのは、ポリシーや規約がその日に効力を生じると事業者が明記した場合だけだ。ページの「最終更新日」は文書日付であり、発効日ではない。取得日や観測日も、どちらかへ黙って置き換えない。

主張の情報源、完全性、実運用、鮮度、矛盾
#

次の表示は、それぞれ別の問いに答えるため分離する。

主張の情報源は、事業者の記載か、製品画面の実地観測かを示す。
証拠の完全性は、文書アーカイブまたは画面観測の検証資料に対応する確認結果を示す。
実際の運用は、別の管理された検証がない限り未検証とする。ポリシーのアーカイブだけで検証済みにはしない。
事実の確認済み期限は、その事実が引用する各証拠系列を、現行主張を支える最新の後継証拠までたどり、証拠系列ごとの最新確認日のうち最も古い日を採る。
データセット全体の確認済み期限は、現行事実の確認済み期限のうち最も古い日とする。一部だけ再確認しても、全体の日付は進まない。
情報源の矛盾は将来の表示項目として予約している。現行パイロットに該当する公開状態はなく、同等の適用範囲に食い違いがあれば、P1で構造化された矛盾関係を導入して両方の記録を結び付けられるまで、P0では公開を保留する。

これらをまとめた総合的な信頼度スコアは作らない。

経時変化、訂正、異議
#

ポリシー変更の日付は、証拠が示せる精度にとどめる。保存記録の日付を発効日へ置き換えない。情報源に食い違いがあっても、編集判断で片方を採用して消すことはない。P0では公開を保留し、別々の証拠系列のまま判定する。P1で追記型の構造化された矛盾関係を導入した後は、両方の記録を並べて公開する。

データセット側の誤りは公開訂正する。事業者または読者はeditor@cypherpunkguide.comへ連絡できる。異議は原則14日以内の受領確認を目標とし、確認中は該当値に印を付ける。この期間は監視された訂正窓口に依存する運用目標であり、応答を保証する期限ではない。

更新目標と現在の限界
#

目標とする運用は、全情報源の月次再確認と、検出した変化の人手による判定だ。現時点ではSLA（サービス水準の約束）として稼働していない。 取得・検証・差分確認・人手判定・公開判定の全工程を本番相当で動かし、稼働状況を確認できる記録を出したうえで、連続2サイクルを正常完了（GREEN）した場合にだけ継続的な約束へ移す。それまでは更新と訂正を手動で行い、表示された確認済み期限を鮮度の基準とする。

スコアを付けない理由
#

総合的なプライバシースコアを作ると、一つの脅威モデルを全読者の判断へ埋め込むことになる。電話番号、接続先の事業者への転送、アカウントとのひも付け、保持期間は、足し合わせられる同じ単位ではない。KYC Driftは現時点で、事実、日付、適用範囲、未評価項目、情報源を示すが、品質順や推奨には変換しない。P1で構造化された矛盾関係を導入した後は未解決の食い違いも並列記録として示すが、現行パイロットには公開済みの矛盾状態はない。

選定とライセンス
#

現行の8サービスは、アカウントを作らずに本文確認できる事業者の一次資料が各サービスに1件以上あったため、便宜的なパイロットとして選んだ。hosted AI市場全体を網羅せず、代表標本とも主張しない。メタデータと注釈はCC BY 4.0。引用した事業者の文章に対する権利は各事業者に残る。機械可読データは/en/data/kyc-drift/index.jsonで公開する。

引用例：Cora Aegis「KYC Drift: hosted AIの身元要件とデータの取扱い — パイロット」（v2026.07）、https://cypherpunkguide.com/ja/data/kyc-drift/、CC BY 4.0

強要のもとでの Bitcoin 自己管理 2026 — サバイバーのための脅威モデル

Mon, 29 Jun 2026 00:00:00 +0000

資金について: CypherpunkGuide には監視型の広告を一切載せていません。広告ネットワークも、追跡ピクセルも、記事広告もありません。資金は透明な流れで成り立っています——現在は読者の寄付、今後は subscription と編集方針に沿った affiliate です。私たちが向き合うのは広告主ではなく、読者です。

もし今あなたが危険な状況にいるなら、何よりもまず、あなたの安全が先です。 このページを読むこと自体が、共有された端末や監視された端末に痕跡を残してしまうことがあります。恐れている相手の手が届かない端末から開いてください。そして何かを変える前に、DV の支援員に相談してください。共有のアカウントや端末、お金を急に動かすと、相手に気づかれてしまうことがあります——そして家を離れる前後の時期が、最も危険です(WomensLaw)。日本では、内閣府の DV 相談ナビ「#8008」(お近くの配偶者暴力相談支援センターにつながります)や、24 時間対応の DV 相談プラス(0120-279-889)につながります。ここに書かれたどれも、訓練を受けた人と一緒に立てる安全計画の代わりにはなりません。

自分の Bitcoin を自分で持つ——その方法を説くガイドは、ほとんどが同じ敵を思い描いています。どこか遠くにいるハッカーが、インターネットの向こうから、あなたの鍵に手を伸ばそうとしている。だから助言はすべて「距離」を前提に組まれています。ハードウェアウォレット、紙に書き留めた seed phrase(秘密の復元語)、強い暗証番号。どれも、あなたが誰にも支配されていない部屋に、ひとりでいることを静かに当てにしています。

けれど、その前提が当てはまらない人は、とても多いのです。しかも、危険が最も切実なところでこそ、そのずれは最も大きく開きます。経済的虐待——パートナーがあなたのお金を支配し、妨害し、取り上げること——は、女性のおよそ 15% が経験しています。食べ物に困る状況にある女性が経済的虐待に直面する割合は、その 4 倍を超えます(Mellar et al., 2024)。自己管理は「経済的な自立」として売られています。それなのに定番のやり方は、あなたと同じベッドで眠り、あなたの暗証番号を知り、ただ「ウォレットを開けろ」と命じればいい相手のことを、一度も名指ししません。(身体的な強要は、家の外でも他人事ではありません。記録に残る Bitcoin 保有者への物理的な襲撃は、2025 年に 169% 増えました——CNBC、Jameson Lopp が集めた報告事例のデータベースより。)

では、その脅威があなたと一緒に暮らしているとき、何が変わるのでしょうか。私たちは主要な自己管理ガイドと、DV のデジタル安全に関する代表的な資料を、並べて読み比べました。すると、両者はほとんど交わっていませんでした。この記事は、その隙間を埋めようとする試みです。きれいなチェックリストではなく、考え方そのものを差し出します——あなたのそばにいる相手が実際に何をできるのか、そこから出発する相手の能力ベースのモデルと、ウォレットの設定よりもあなたの身の安全を先に置く、段階を踏んだ計画です。

私たちはプライバシーの研究者として書いています。当事者でも、支援者でもありません。 ここにあるのは脅威モデルと選択肢の一覧であって、処方箋ではありません——「指示」ではなく「選択肢」を差し出すという、トラウマに配慮した原則(SAMHSA)に沿っています。あなた自身の状況は、どんなガイドよりもあなたがよく知っています。そして Bitcoin の界隈で出回っている「賢い」とされる小細工の中には、人を危険にさらしかねないものがあります。それははっきりと、危ないと書きます。

定番の管理術は、脅威が家の中にいると崩れる
#

定番の Bitcoin 管理の助言は、遠くにいる敵と、身の安全が確保された利用者を前提に組み立てられています。その核となる動き——seed phrase をインターネットから切り離す、ハードウェアウォレットを使う、暗証番号を設定する——は、どれも、信頼できそうに見える誰かがあなたの打ち込む手元を見ていない、あなたのスマホを握っていない、面と向かって圧力をかけられない、という前提の上に立っています。親密なパートナーによる虐待は、その前提をいっぺんに、ひとつ残らず壊します。だからこそ「とにかくハードウェアウォレットを使えばいい」という助言は、役に立たないどころか、危険にさえなりうるのです。

このずれは、助言が一つ足りないという話ではありません。仕組みそのものがずれています。一般向けの管理ガイドは、盗難に最適化されています(誰かがあなたの協力なしに鍵を奪う)。一方、虐待を踏まえた安全計画が向き合うのは、支配と強要です(誰かがあなたを、あなた自身の利益に反して動かし、逆らえば罰する)。ハードウェアウォレットは前者を退けますが、後者をかえって悪化させることがあります——見慣れない新しい端末は、答えるのが安全とは限らない問いを、相手に突きつけてしまうからです。

もうひとつ、目立たない食い違いがあります。DV の支援員は、加害者のアクセスと、その人が行使できる圧力を軸に助言を組み立てます。Bitcoin のガイドは、道具と手順を軸に組み立てます。両者を橋渡しするとは、「私のそばにいる相手は何ができるのか」を、具体的な管理とプライバシーの選択へと翻訳することです——この記事の残りは、まさにそれです。

相手の能力で考える対応表
#

「私は女性だから/発信者だから/活動家だから」と問うのではなく、あなたを脅かす相手が、実際に何をできるのかを問うてください。この問いの立て方を変えることが、何よりも役に立ちます。同じ防御策が、相手の能力にきれいに対応するからです。そして現実の状況は、たいてい、いくつかの能力が混ざり合っています。下の表は私たちの枠組みです。防御策はここで要点だけ示し、後の章で詳しく述べます。

相手の能力	どういう意味か	まず取れる防御	正直な限界
1. 端末に物理的に触れる	あなたのスマホやノートPCを手に取れる、または共有している	相手の手が届かない別の端末を持つ／画面ロックを徹底する	相手が一度でも触れた端末は、すでに細工されているかもしれません
2. 暗証番号を知っている	肩越しに盗み見た、命じて聞き出した、以前に共有していた	相手の知らない暗証番号を設定した、新しい端末	知られた番号を変える——あるいは生体認証を切る——こと自体が目に見える行為であり、指紋や顔は力ずくで使わされることがあります
3. 署名を強いることができる	暴力や脅しで送金させる	時間差を仕込む／求められてすぐ動かせる場所に大金を置かない	暗号は、レンチには勝てません(「5 ドルのレンチ攻撃」)
4. 居場所を追跡できる	stalkerware(端末を密かに監視するアプリ)、共有アカウント、AirTag	スマホは監視されている前提で扱う／別の経路で支援につながる	追跡装置を見つけたこと自体が、危険を高めることがあります
5. クラウド・メール・2FA を読める	iCloud や Google の共有、SIM への access	安全な端末で新しいアカウントを作る／アプリ型の 2FA を使う	アカウントの変更が、相手に通知されることがあります
6. あなたを晒すことができる	行き先を公表すると脅す	オンチェーンとアドレスのプライバシー／情報の伏せ方	公開台帳に刻まれた履歴は、取り消すのが困難です

この表の眼目は、順番です。能力 1・2・4・5 は、Bitcoin の問題ではありません——ウォレットを持つ前から存在する、端末とアカウントの問題です。 ポケットの中のスマホが監視されているなら、どれだけ慎重に選んだハードウェアウォレットも意味をなしません。あなたが設定するそばから、そのとおりに見られているからです。だからこそ、どのウォレットを選ぶかよりも、手順の順番のほうが大切で、次の章はどんな管理の助言よりも前に置いてあります。

Bitcoin の前に、まず端末と計画を守る
#

ウォレットに触れる前に、相手が支配していない端末と安全計画を整えてください——相手の目が届かない場所があって初めて、その後の一歩一歩が安全に踏み出せるからです。stalkerware——位置情報やメッセージ、写真、通話をひそかに送り出すアプリ——は広く出回っていて、見つけにくいように作られています。Coalition Against Stalkerware と NNEDV の Safety Net プロジェクトは、それが虐待の中で日常的に使われている実態を記録しています——DV 支援プログラムの 97% が、加害者が技術を悪用して、つきまとい・嫌がらせ・支配を行っていると報告しています(NNEDV Safety Net 調査, 2014)。あなたの端末が監視されているおそれがあるなら、その端末でする操作はすべて見られている、と考えてください。

ここで肝心なのは、怪しい端末を急いで「掃除」しないことです。DV 支援員は、スパイウェアや追跡装置を取り除くと、加害者に気づかれて危険が高まりうると警告しています(NNEDV Safety Net)。たいていより安全なのは、監視された端末はふだんどおりに振る舞わせたまま、相手の手が届かない別の端末——買って、設定して、見つからない場所に置いておく端末——へ、大事な作業を移すことです。

監視を疑うときに、現実的な最初の手順を挙げるなら、次のようになります。

いったん止まる。 疑わしい端末で、急なことをしない。いつもと違う振る舞いそのものが、ひとつの合図になります。
別の環境を用意する。 安いスマホ——あるいは友人の端末でもかまいませんが、その相手と連絡も監視もしていないと確信できる人に限ります——に、新しいメールアドレスと、SMS ではなくアプリ型の認証アプリを入れます(SMS は、共有の携帯プランを通じて傍受されることがあります)。
別の経路で支援につながる。 相手に読まれるかもしれない手段ではなく、安全な端末から、あるいは対面で、支援員に連絡します。
手の届くものを変える前に、計画を立てる。 とりわけお金です。監視されている口座からの急な送金は、逃げ道ではなく、引き金になりかねません。

相手が支配していない環境を手にして初めて、このガイドの残りは、安全に実行できるようになります。監視ツールがあなたをどう見ているかについては監視ツールから見たあなたで、年齢確認と立場の弱い利用者については年齢確認と匿名性で、端末とデータの側をより深く扱っています。

強要のもとでの管理の選択肢——その正直な限界
#

強要のもとでは、管理の設計が目指すものが変わります。「泥棒を締め出す」ことから、「圧力のもとで奪われるものを、さらなる危険を招かずに、どこまで小さくできるか」へと。そして、よく勧められる小細工のいくつかは、この二つ目の試練に落第します。ここでの自己管理のいちばん厳しい真実は、身も蓋もないものです——鍵を完璧に守っても、署名を強いられるなら、それは助けになりません。 これがよく知られた「5 ドルのレンチ攻撃」です。だから管理の選択は、コインに何が起きるかだけでなく、あなた自身に何が起きるかで判断しなければなりません。

以下は、最もよく勧められる選択肢を、虐待という文脈での本当の限界とともに並べたものです。どれも推奨ではありません。それぞれが、間違った方向に転びうる賭けです。

選択肢	狙い	強要のもとでの正直な危険
おとり／強要対応(decoy)のウォレット	少額の「本物の」残高を見せて、要求をやり過ごす	疑われたり見つかったりすれば、その嘘がもっとひどい暴力の引き金になります。おとりが強要下で安全だと裏づける DV の研究は一つも発表されていません。支援員は、相手に気づかれたどんなずれも危険を高めうると警告します。賢い手ではなく、高リスクと考えてください。
隠し passphrase(seed phrase に足す、もう一つの秘密の語——BIP-39〔seed phrase の規格〕でいう「25 番目の語」)	一つの seed から二つのウォレットを作り、隠した側は「知らない」と言い張れる	技術としては本物です(BIP-39)。けれど passphrase を忘れれば資金は永久に失われます。そして問い詰められれば、「知らない」は通らないことがあります。取り戻せなくなる危険も、強要の危険も、どちらも高まります。
時間差／multisig での送金	遅延や追加の鍵が、強いられた取引を取り消す猶予を生む	その遅延が効くのは、あとで取り消すことが安全なときだけです。相手がそばにいて見張っているなら、取り消された取引は、気づかれるずれになります。
信頼できる第三者を交えた multisig	鍵を分け、一つの端末だけでは資金が動かないようにする	虐待の典型的な手口は孤立化です——被害者を友人や家族から切り離すこと(NCDV)。その「信頼できる人」が、そもそもいないかもしれず、圧力をかけられるかもしれず、その人と連絡を取ること自体が危険かもしれません。

これらすべてを貫く原則が、二つあります。第一に、ごまかしに頼る防御は、強要のもとで最も危険です。失敗したときに返ってくるのが、失われたコインではなく、身体への報復だからです。第二に、秘匿は、取り戻しやすさと衝突します。全 Bitcoin のうち推定 11〜18% は、忘れられた鍵と立てそびれた計画によって、すでに失われています(Chainalysis の推計、CryptoSlate 経由)。隠し passphrase を、地理的に分けたバックアップの上に積み重ねれば、泥棒と変わらないくらい簡単にあなた自身を締め出してしまいます。安全に使えない計画は、計画ではありません。

もしあなたの状況が「離れる前に資金を動かしておきたい」なら、より素直なやり方は、たいてい、巧妙なウォレットではなく、安全な端末の上に新しいウォレットを作り、そこへ計画的に資金を移すことです——コインを匿名で手に入れる方法は KYC なしで Bitcoin を買う(KYC は、取引所が求める本人確認のこと)で扱っています。ただし、公開台帳については、次に述べる注意が付きます。

Bitcoin の公開台帳そのものが、もう一つの露出になる
#

鍵や端末とは別に、Bitcoin には、初めての人が見落としがちなプライバシーの危険があります。台帳は公開されていて、しかも消えません。だから支払いは、それが済んだずっと後になっても、あなたへとたどり直せてしまいます。 同じアドレスを使い回せば、そのアドレスでの取引はすべて一本に束ねられます。そしてそのどれか一つでも、KYC 取引所からの引き出しに結びつけば、本名と住所が、その履歴にひもづいてしまいます(Bitcoin Wiki: Privacy;Coldcard)。たどられずに離れようとしている人にとって、これは抽象的な話ではありません——加害者に渡した引き出しアドレスや、共有アカウントから取り戻されたアドレスが、追跡の手がかりに変わりうるのです。

露出はアドレスだけにとどまりません。Lightning(Bitcoin の高速決済層)の請求書(invoice)は、受け取り手のノードの公開鍵を漏らすことがあります——これは、攻撃者が検索してあなたを特定する手がかりにできる、消えない識別子です(Casa)。ハードウェアの配送先住所、私書箱、共有の名義で開いた取引所アカウントも、すべて同じように漏れます。守りの一手——アドレスを毎回新しくする、使い回しを避ける、KYC のコインと KYC なしのコインを慎重に分ける——は、どれも本物です。けれど、本物の手間も伴います。手数料、国ごとの制約、そして、すでに危機のさなかにいる人に求めるには酷な、習得の壁です。仕組みの詳しい話は Bitcoin オンチェーンのプライバシーで扱っています。ここで持ち帰ってほしいことは、もっと絞られます——オンチェーンに載せたものは、あなたへ結びつけられうると考えること。そして、安全のために頼るウォレットは、相手が一度でも見たアドレスから切り離しておくこと。

段階で応じる——その場面に、その一手を合わせる
#

正しい一手は、危険がどれだけ差し迫っているかで、まるごと変わります。だから、すべてをいっぺんにやろうとせず、いま自分がいる段階に動きを合わせてください。技術的な助言で私たちが最もよく見かける間違いは、これを一度きりの設定として扱うことです。強要のもとでは、これは順番のある流れであり、「正しい」技術的な一歩を、間違った場面で踏むことが、引き金になりうるのです。

段階	優先すること	Bitcoin に固有の一手
差し迫った危険	技術ではなく、身の安全。相談窓口や支援員に連絡する／気づかれる変更はしない	なし。今の送金は、守りではなく、悪化を招きます
端末が監視されていそう	別の、自分だけの端末を手に入れる／見張られている端末はふだんどおりに	新しいウォレットの設定は、安全な端末の上だけで
離れる準備をしている	静かな準備。書類、お金、経路——離れる瞬間が最も危険	相手が一度も見ていない新しいウォレットに資金を入れる／金額は目立たない程度に
離れたあと	アドレスと居場所のプライバシー／アカウント復旧の整理	アドレスを新しく／共有アカウントと古い引き出し履歴とのつながりを断つ

この段階分けは、DV の安全計画から得られた核心の知見を映したものです——安全は、どれか一つの道具からではなく、計画から生まれます。そして離れる瞬間は、命に関わる暴力のリスクが最も高い時です(WomensLaw)。Bitcoin はその計画の一部になりえます——銀行を通して加害者には凍結できないお金は、意味を持ちうるからです——けれど、それは安全計画の内側にあるものであって、決してその前には立ちません。

Bitcoin が答えではないとき
#

自己管理は、いくつかある選択肢の一つにすぎません。そして正直であろうとするなら、危機のさなかにいる人にとっては、それが最善でないことのほうが多い、と言わなければなりません。Bitcoin の強み——検閲への耐性、あなたの口座を凍結したり通報したりできる銀行が存在しないこと——は本物です。けれど、それには重い代償がついてきます。高い技術的な知識、取り返しのつかない失敗、そして公開台帳。差し迫った危険に対処している人にとっては、その手間そのものが、危険になりかねません。

正直な比較は、状況しだいです。そして私たちは、これらを虐待のサバイバー(虐待や DV から逃れてきた人)に向けて具体的に検討した分析を、一つも見つけられませんでした。ですから、これは結論ではなく、考え始めるための枠だと受け取ってください。

現金は最も足がつきにくく、端末もいりません。けれど、いくらでも隠せるわけではなく、見つけられたり取り上げられたりすることがあります。
プリペイドカードは、銀行の監視や身元のひもづきの一部をかわせます。その代わりに手数料と上限があります。
別口の銀行口座は、たどれて凍結もできますが、使い慣れていて、すぐ使え、間違えてもやり直せます。
Bitcoin の自己管理は、凍結や差し押さえに抗えますが、技術を要し、公開台帳に漏れ、失敗に容赦がありません。

正しい組み合わせは、金額、どれだけ近くで見張られているか、道具をどれだけ使いこなせるか、バックアップを安全にしまえる場所があるかどうかで変わります。これを天秤にかけるなら、ガイドだけからではなく、支援員と一緒にかけてください。

結論——あなたのリスクに合う計画を立てる
#

強要のもとで暮らすことに、ただ一つの正しい管理設定はありません。あるのは、あなた固有の危険に合う選択だけです。ここまでのすべてを貫く筋は、端末と安全計画が先に来て、ウォレットはそれに仕える——決してその逆ではないということです。Bitcoin は、加害者がこっそり取り上げることのできない拠り所を、人に与えうるものです。けれどそれは、あなたの信頼の内側に、家の中に、ときにはスマホの中にまで、すでに入り込んでいる相手——その相手の目をかいくぐって、設定が機能できるときに初めて成り立ちます。

要点

脅威モデル: 定番の管理の助言は、遠くのハッカーを想定します。けれど親密なパートナーによる虐待のもとでは、敵が端末に物理的に触れ、暗証番号を知っているかもしれず、署名を強いることができます——まるで別の問題です。
順番: どんなウォレットよりも先に、自分だけの端末と安全計画を確保してください。DV プログラムの推定 97% が、加害者が監視と支配のために技術を悪用していると報告しています。
ごまかしは危険: おとりや強要対応のウォレットには、DV の安全性を裏づける研究がありません。見つかれば暴力をさらに激化させかねません。賢い手ではなく、高リスクと考えてください。
公開台帳: アドレスの使い回しに KYC の引き出しが重なると、あなたの履歴が結びつけられてしまいます。安全のためのウォレットは、相手が見たことのあるアドレスから切り離してください。
Bitcoin がいつも答えとは限らない: 現金、プリペイドカード、銀行口座は、それぞれ「たどりにくさ」と「使いやすさ」を引き換えにしています——ガイドだけからではなく、支援員と一緒に決めてください。

よくある質問
#

ハードウェアウォレットは、パートナーに使うところを見られていても私を守ってくれますか?
#

半分だけです。ハードウェアウォレットは、遠くにいる攻撃者から鍵を守ります。けれど、誰かがあなたの暗証番号の入力を見られたり、端末を握れたり、署名するよう圧力をかけられたりするなら、ウォレットの守りは迂回されてしまいます。その状況では、ウォレットの機種よりも、端末とアクセスの問題(上の表の能力 1〜3)のほうが重くのしかかります。まず、自分だけの端末を確保してください。

おとりや「強要対応」のウォレットは、強要のもとで安全に使えますか?
#

安全策としては、おすすめしません。少額の残高を見せて要求をやり過ごす——この考えは、ごまかしが通用することを前提にしています。虐待のもとでは、気づかれた、あるいは見つかった嘘が、もっとひどい暴力の引き金になりえます。そして、おとりが強要下で安全だと裏づける DV の研究は、一つも発表されていません。DV の安全計画は、加害者が気づくどんな変化も危険を高めうると警告しています。賢い小細工ではなく、高リスクな選択肢と考えてください。

multisig に、友人や家族を入れるべきですか?
#

慎重になってください。協働管理(鍵を分け、一つの端末だけでは資金が動かないようにすること)は、一般には筋の通った手です。けれどそれは、信頼でき、連絡の取れる第三者がいることを前提にしています。虐待を特徴づける手口の一つが孤立化——まさにそうした人たちから、あなたを切り離すこと——です。だから「信頼できる人」は、そもそもいないかもしれず、圧力をかけられるかもしれず、その人と連絡を取ること自体が安全でないかもしれません。もし誰かを入れるなら、相手が手出しも干渉もできない人を選んでください。

端末が監視されていると思ったら、まず何をすべきですか?
#

急に初期化したり「掃除」したりしないでください——それが相手に気づかせてしまいます。端末はふだんどおりに振る舞わせたまま、大事な作業を、相手のアクセスできない別の端末(新しいメールアドレスと、アプリ型の 2FA を備えたもの)へ移してください。そして手の届くものを変える前に、とりわけお金を動かす前に、別の経路で DV の支援員につながってください。

安全に離れるには、Bitcoin は銀行口座より良いですか?
#

必ずしもそうとは限りません。Bitcoin は凍結や差し押さえに抗え、それが意味を持つこともあります。けれど技術を要し、失敗に容赦がなく、支払いを公開台帳に記録します。危機のさなかにいる多くの人にとっては、組み合わせ——いくらかの現金、プリペイドカード、別口の銀行口座、そして小さく慎重に持つ Bitcoin のウォレットだけ——のほうが、自己管理だけに頼るより安全です。あなたの状況を知っている支援員と一緒に、決めてください。

参考文献
#

#	出典	URL	アーカイブ
1	Mellar et al.、経済的虐待と健康(2024)	https://pmc.ncbi.nlm.nih.gov/articles/PMC11465629/	https://web.archive.org/web/20260613075557/https://pmc.ncbi.nlm.nih.gov/articles/PMC11465629/
2	Coalition Against Stalkerware	https://stopstalkerware.org/	https://web.archive.org/web/20260623120558/https://stopstalkerware.org/
3	NNEDV Safety Net — サバイバー向けの資料	https://www.techsafety.org/resources-survivors	https://web.archive.org/web/20260628175219/https://www.techsafety.org/resources-survivors
4	WomensLaw — 安全計画	https://www.womenslaw.org/safety-planning	https://web.archive.org/web/20260505163930/https://www.womenslaw.org/safety-planning
5	NCDV — DV における孤立化の手口	https://www.ncdv.org.uk/isolation-tactics-how-victims-of-domestic-abuse-fall-into-the-trap/	https://web.archive.org/web/20260218092206/https://www.ncdv.org.uk/isolation-tactics-how-victims-of-domestic-abuse-fall-into-the-trap/
6	Bitcoin Wiki — Privacy	https://en.bitcoin.it/wiki/Privacy	https://web.archive.org/web/20260616215546/https://en.bitcoin.it/wiki/Privacy
7	Coldcard — アドレスの使い回し	https://coldcard.com/learn/transaction-security/bitcoin-address-reuse	https://web.archive.org/web/20260629074529/https://coldcard.com/learn/transaction-security/bitcoin-address-reuse
8	Casa — Lightning のプライバシー入門	https://blog.casa.io/lightning-privacy-101/	https://web.archive.org/web/20260314173520/https://blog.casa.io/lightning-privacy-101/
9	CNBC — Bitcoin 保有者への物理的襲撃(2025)	https://www.cnbc.com/2025/04/06/bitcoin-self-custody-crypto-risks.html	https://web.archive.org/web/20260313145505/https://www.cnbc.com/2025/04/06/bitcoin-self-custody-crypto-risks.html
10	SAMHSA — トラウマに配慮したアプローチ	https://www.samhsa.gov/mental-health/trauma-violence/trauma-informed-approaches-programs	https://web.archive.org/web/20260508115444/https://www.samhsa.gov/mental-health/trauma-violence/trauma-informed-approaches-programs

Cora Aegis

プライバシーとセルフカストディの書き手。一般向けのガイドが取りこぼす脅威モデルに焦点を当てています——ここでは、Bitcoin の管理術と、DV のデジタル安全とのあいだに開いた隙間です。当事者でも支援者でもなく、研究者として書いています。仮名で書くのは、選んでのこと、そして信念によることです。

Cora についてもっと読む →

Cypherpunk Manifesto とは何か——2026年に読み直す入門

Sun, 28 Jun 2026 00:00:00 +0000

資金について：CypherpunkGuide は監視型広告を一切載せない——広告ネットワークも、トラッキングピクセルも、スポンサー記事もない。運営は透明な収益源による：現在は読者からの寄付、将来は購読と編集方針に合致した affiliate。私たちは広告主ではなく、読者に向き合う。

このサイトの名は、ある運動から来ています。そしてその運動の名は、ある文章から来ています。プライバシーツールが産業になる前、Bitcoin が生まれる前、「cypherpunk」という語が新聞の見出しに載る前のことです。サンフランシスコ・ベイエリアの暗号研究者たちが集う小さなメーリングリストで、ひとつの考えが固まりました。プライバシーは、誰かが与えてくれるのを待つものではない、と。1993年3月、そのうちの一人、エリック・ヒューズが、千語に満たない文章でそれを書きとめました。

その文章——『A Cypherpunk’s Manifesto』——は、プライバシーを守る仕事がなぜ存在するのかを、いまも最も明快に語っています。ここで言う cypherpunk とは、プライバシーを「与えられるのを待つ」のではなく、暗号で自分たちの手で作り出そうとした、1990年代の暗号活動家たちのことです。ところが多くの解説は、この文章を「Bitcoin へ至る道の歴史的な脚注」へと押し込めてしまいます。それでは肝心なところが抜け落ちます。私たちはこの宣言を一行ずつ、このサイトで毎週扱っている監視の現実と突き合わせて読み直しました——AI 規模の相関、消せない足跡、開かれた Web の入り口に立ちはだかる本人確認の関所。すると、これは懐古ではないと分かったのです。2026年がいまだに答えを出せずにいる問いを、30年前に正確に立てた文章でした。

では、この宣言は実際に何を語り、誰が書いたのか。そして、30年の現実にさらされて生き残った主張と、外れた予言はどれなのか。以下が入門です。まず文章そのもの。次に、それを書いた人々。予言を正直に採点した一枚の表。そして、物語の冒頭に名があるべきなのに、ほとんど必ず省かれてきた一人の女性のことも。

Cypherpunk Manifesto が実際に語っていること
#

Cypherpunk Manifesto は、エリック・ヒューズが1993年に書いた文章です。電子の時代に開かれた社会を保つにはプライバシーが欠かせないこと、それを制度が与えてくれることはないこと、だからこそ暗号で直接作るしかないこと——この3点を主張しています。 1993年3月9日に cypherpunks メーリングリストへ投稿されたこの文章は、短く、断定的です。立法を求める呼びかけではなく、論拠を一段ずつ積み上げる形をとっています。その力は、プライバシーを「お情け」として扱うことを、出発点から拒むところにあります。

文章はまず、いまも日常的に混同される2つの考えを切り分けます。

「プライバシーは秘密とは違う。私的なこととは、世界中には知られたくないこと。秘密とは、誰にも知られたくないこと。プライバシーとは、自分の何を世界に明かすかを、自分で選べる力のことだ。」 — エリック・ヒューズ『A Cypherpunk’s Manifesto』1993

この区別が、議論の重みをほとんど一手に引き受けています。もしプライバシーが秘密と同じなら、それを求めることは「何か後ろ暗いものを隠している」ように映ってしまう。ヒューズはプライバシーを自分で選んで明かすこと——何を、誰に見せるかを自分で決める力——と定義し直しました。するとプライバシーは、悪事の逃げ場ではなく、自分の条件で社会に参加するための前提になります。彼が挙げる例は、わざと平凡です。雑誌を現金で買う。店主は、買い手が誰かを知る必要などない。

そこから宣言は、中心となる政治的な主張へ進みます。cypherpunk の考え方を、ありふれたプライバシー擁護から分かつのが、この一点です——プライバシーは、嘆願して手に入るものではない。「政府や企業、その他の顔の見えない巨大な組織が、善意でプライバシーを与えてくれるなどと期待することはできない」とヒューズは書きました。制度の好意に頼ったプライバシーは、その制度がいつでも取り上げられるプライバシーです。だから結論は、政策への陳情ではなく、技術者への指令になります——開かれた社会のプライバシーには、匿名で取引できる仕組みが要る。その仕組みが存在しないなら、必要とする者が自分で作るしかない。あの有名な一行は、この倫理をまるごと凝縮したものです——「Cypherpunk はコードを書く。」

だからこの宣言は、単なる歴史記録を超えて、いまも意味を持ちます。監視への不平ではなく、設計の原則なのです。長く続くプライバシーは、信じるしかない約束ではなく、検証できる仕組み——自分で確かめられる数学——の性質として宿る。そう語っています。それ以来の誠実なプライバシーツールは、どれもこの原則を守ろうとした試みか、あるいは、それを無視したときに何が起きるかの実例か、そのどちらかでした。

3つの文章、ひとつの思想——May、Hughes、Chaum
#

Cypherpunk Manifesto は、何もないところから現れたのではありません。3つの文章が流してきた思想が、ここで結晶しました——デヴィッド・チャウムの追跡できない決済に関する学術論文（1985年）、ティム・メイの『Crypto Anarchist Manifesto』（1988年執筆）、そしてヒューズの文章（1993年）です。これらを束ねたのが、ヒューズ、メイ、ジョン・ギルモアが1992年末に立ち上げた cypherpunks メーリングリストでした。 3つを並べて読むと、宣言が10年分の暗号思想を活動家の言葉へ煮詰めたものだと分かります。

知的な下地を作ったのはチャウムでした。学術的な暗号研究者だった彼は、プライバシーと説明責任は対立しないことを証明しました。取引に厳密に必要な以上は何も明かさない決済や認証の仕組みは、現に作れる。そう示したのです。1985年に『Communications of the ACM』に載った論文の題名は、まるで運動全体のテーゼを掲げたようです——『Security Without Identification: Transaction Systems to Make Big Brother Obsolete（身元確認なしの安全——ビッグ・ブラザーを過去のものにする取引システム）』。チャウムはその後の数年を、これを世に出すことに費やしました。DigiCash という会社を興し、「ecash」と呼ぶ仕組みを市場へ送り出そうとしたのです。しかし会社は1998年に破産を申請しました——難しいのは数学だけではなかった、という最初の、教訓に満ちた一件です。

チャウムが技術者、ヒューズが組織者だったとすれば、ティム・メイは挑発者でした。1988年に書かれ、1992年に初期の cypherpunk たちへ回された『Crypto Anarchist Manifesto』は、わざと不穏な一文で始まります——「ある亡霊が現代世界を徘徊している——暗号アナーキーという亡霊が。」メイが示した命題はこうです。強力な暗号は、社会の準備ができていようがいまいが、完全に匿名な仕組みを可能にしてしまう。しかも彼は、それが両刃であることを隠しませんでした。解放と並んで、不正な闇市場が現れることも予言したのです。誠実な入門であろうとするなら、この両義性は削らずに残しておくべきでしょう。

土台となる文章	著者	年	中心の主張
『Security Without Identification』	デヴィッド・チャウム	1985	取引は、参加者を特定せずとも安全にできる
『The Crypto Anarchist Manifesto』	ティム・メイ	1988（1992年に回覧）	暗号は、法とは無関係に匿名の仕組みを可能にする
『A Cypherpunk’s Manifesto』	エリック・ヒューズ	1993	プライバシーは制度に求めるものではなく、コードで作るものだ

3つの文章を運動に変えたのは、メーリングリストでした。1992年末から、cypherpunk たちはベイエリアで毎月集まり、公開のリストで議論を戦わせます。リストは1990年代後半には購読者が数千人に達しました。宣言がその設立文書になったのは、最初の思想だったからではありません。最も明快な指示だったからです。

名付けた女性——ジュード・ミルホン
#

「cypherpunk」という語を作ったのは、ジュード・ミルホンでした——作家であり独学のプログラマーで、「St. Jude」というハンドルで活動した人物です。「cipher（暗号）」と「cyberpunk」を掛け合わせた語遊びでした。運動の名を彼女が生んだという事実を、ほとんどの歴史は脚注へと縮めてしまいます。これを正すのは、雑学の補足ではありません。情報を誰が握るかをめぐる運動が、その出発点から一人の女性をひそかに消してきた記録を、訂正する作業だからです。

ミルホン（1939–2003）は、たまたま気の利いた語遊びを思いついた脇役などではありませんでした。1960年代からのプログラマーであり、Community Memory プロジェクト——一般に開かれた最初期のコンピューター電子掲示板のひとつ——の一員であり、サイバーカルチャー誌『Mondo 2000』ではシニアエディターも務めました。政治的な立場は明確で、時代の先を行っていました。スローガン「Girls need modems!（女の子にこそモデムを）」は、技術へのアクセスをフェミニズムの要求として掲げたものです。「デジタルデバイド」という言葉が広まるより何十年も早い問いかけでした。ベイエリアの暗号研究者たちが名前を必要としたとき、定着する一語を差し出したのがミルホンでした。

私たちがこれを前面に出すのは、正確さのためだけではありません。cypherpunk の理想——プライバシーは自律の前提だという考え——は、それが崩れたときに最も無防備にさらされる人々に、いちばん重くのしかかります。その人々の顔ぶれが、性別によらず一様でないことも確かです。私たちが近くで扱う脅威の多くは——AI時代のOPSECで論じる合成された身元の悪用から、年齢確認の義務化に埋め込まれた親密な相手による監視まで——女性に、そして身近に動機を持つ加害者を抱える人に、不釣り合いに重く降りかかります。女性が名付けた運動を2026年から読み直すと、男性を前提にした「孤独な攻撃者」の脅威モデルが見落としがちな害へ、自然と指が向きます。ミルホンの居場所は、脚注ではなく、入門の本文です。

1993年の予言を、2026年に採点する
#

予言の束として読むと、この宣言は居心地が悪くなるほど当たっています。制度はプライバシーを与えないという主張、監視は規模を増すという主張、組み込みの仕組みだけが持ちこたえるという主張——どれも繰り返し裏づけられてきました。一方で、姉妹文書であるティム・メイの予言のひとつは、書き手たちが思いもしなかった形へとひっくり返りました。ここはじっくり立ち止まる価値があります。今日の宣言の値打ちは、遺物としてではなく、採点できる問いの集まりとして読めるところにあるからです。

下の表は、見出しになるような出来事ではなく、このサイトで実際に記録してきた脅威に、宣言の中心の主張をひとつずつ対応させて作りました。左が1993年の一文、右が私たちの追跡してきた2026年の現実です。

宣言の主張（1993年）	2026年の現実	判定
制度はプライバシーを「善意から」与えはしない	プラットフォームの「削除」は見た目を変えるだけで、消去ではない。複製はブローカー、キャッシュ、モデルの重みに残り続ける	✅ 的中
監視は人手の限界を追い越す	AI が、散らばった断片を、どんな人間の調査員にも届かない規模でプロフィールへ束ねる	✅ 的中
プライバシーには匿名で取引できる仕組みが要る	ふつうのサービスの入り口で本人確認の関所が義務づけられつつある。匿名のアクセスとは正反対だ	✅ 的中（その侵害によって）
匿名の仕組みでは評判が「中心」になる（メイ、1988年）	評判の仕組みは存在する——だが国家とプラットフォームが握る身元スコア（KYC＝本人確認、chain-analytics のリスク評価）としてであり、利用者のものではない	⚠️ 反転

上の3行は、宣言が正しかった箇所です。削除は身を守ってくれない、という主張は、削除しても消えない——2026年、SNSの足跡はどこまで残るのかが扱う主題そのものです。あなたの言葉がいったんモデルの学習データに吸い込まれてしまえば、その重みにまで届く削除ボタンは存在しません。監視が人間の限界を超えて規模を増す、という主張は、AI 時代の脅威モデルの前提そのものです。そして、匿名で取引できる仕組みを求めた主張は、皮肉にも、その正反対を世界が推し進めることで裏づけられています——年齢確認やデジタル ID の関所が、開かれた Web を「身分証を見せること」と引き換えにしつつあるのです。

規模に関するこの主張には、一次資料の証拠をひとつ差し出せます。私たちは、このサイト自身のサーバーログを、自らを名乗る AI クローラー——GPTBot、ClaudeBot、PerplexityBot、Google-Extended とその仲間たち——について見張っています。彼らは絶え間なく、こちらの都合ではなく自分たちのスケジュールでやって来ては、プライバシーのサイトを索引化し、それについての問いに答えようとします。ヒューズが推し量ることしかできなかった「機械の読者」は、いまやログファイルの中で数えられます。

4行目は、興味深い外れ方です。メイは、匿名の仕組みのなかでは評判が物事を束ねる原理になると予言しました——評判が中心を占めるという点では正しかった。しかし、それを誰が握るかを読み違えていました。仮名にひもづいた、利用者自身の手にある評判ではなく、2026年は上から管理される評判の仕組みで回っています——KYC（本人確認）スコア、取引監視のリスク評価、そしてあなたのコインが「クリーン」かどうかを判じる chain-analytics（ブロックチェーン上の取引を追跡・分析する手法）の経験則です。cypherpunk たちは評判を個人の主権の道具として思い描いた。それは、制度による支配の道具として現れました。正しい仕組みが、誤った持ち手に渡った——この逆転こそ、いまプライバシーツールを作る誰にとっても、宣言の予言が突きつける最も鋭い教訓です。

「Cypherpunk はコードを書く」——2026年における倫理
#

宣言で最も引用される一行「Cypherpunk はコードを書く」は、プログラミングについてのスローガンではありません。何をもって"確か"とするかの構えを示した一節です。プライバシーの保証は、信じるしかない約束ではなく、仕組みのなかで検証できるものでなければならない。これは今日の言葉でいえば「信じるな、確かめよ」であり、「方針より構造を選べ」です。 30年を経てもこの倫理は、コードを一行も書かない人にとっても、この文章が差し出す最も実用的な教えです。

この構えで動くのに、暗号を書く必要はありません。どんなプライバシーの主張に対しても、cypherpunk 流の問い方はひとつです——その保証は、どこに宿っているのか。プライバシーポリシーに書かれた約束は、制度の好意に宿っています——ヒューズが「持ちこたえない」と言った、まさにその種類のものです。対して、公開され監査できるコードや、強制できる中央の運営者がいないプロトコルに宿る保証は、数学と構造の問題です。私たちが勧める「長く効く守り」が、たいてい小手先の工夫ではなく構造的なものになるのはこのためです——プライバシーが設計に書き込まれたツールを選ぶほうが、もっともらしいことを言うだけのサービスを信じるより、ずっと確かなのです。政府が握るデータベースは、すでに破られたものとして扱う——国家があなたのデータを漏らす日で説く「侵害は前提」という構えも、まったく同じ理屈に立っています。

この倫理は、仮名（実名でなく、一貫した別名で活動すること）がこの伝統の周縁ではなく中心に座る理由も教えてくれます。法的な本名でない一貫した名のもとで書くこと——cypherpunk たちがリスト上でそうしたように、そしてこの媒体がそうしているように——は、逃げ隠れではありません。それこそ、宣言がプライバシーと定義した「自分で選んで明かすこと」です。肩書きではなく、コードと論で判断されるなら、その仕事は通用するかしないか、それだけになります。これが cypherpunk たちの定めた基準であり、身元による権威より、ずっと誠実なものです。

結論——1993年の文章が、いまも基準を定めている理由
#

Cypherpunk Manifesto が古びないのは、時代物の作品ではなく、設計の原則だからです——「プライバシーは与えられるものではなく、作るものだ」という主張を、現実は毎年試し続け、いまだに覆せずにいます。プライバシーは秘密ではなく、自分で選んで明かすことです。与えられないから、作るしかない。持ちこたえる保証は、信じるしかない制度ではなく、自分で検証できる仕組みに書き込まれたものだけです。

2026年の読者にとって、これは一つのものの見方になります。次に「安全のため」と称して新たな本人確認の関所が告げられたとき、宣言はこう問えと教えます——「この事業者を信用できるか」ではなく、「この設計は、そもそも信用を必要とするのか」と。プラットフォームがプライバシー設定を差し出してきたら、宣伝文句ではなくコードのなかに保証を探せ、と。30年前の文章が今週のことを書いたように読める。それは先見の明の証明であり、同時に、それ以来私たちがあまりに何も作ってこなかったことへの告発でもあります。最も正直に言えば、その両方です。

要点

これは何か： 『A Cypherpunk’s Manifesto』は、エリック・ヒューズが1993年に書いた文章。プライバシーを「自分で選んで明かす力」と定義し、制度に求めるのではなく暗号で作るべきだと主張した。
創設の三人： チャウムの追跡できない決済の研究（1985年）と、メイの『Crypto Anarchist Manifesto』（1988年）が舞台を整え、ヒューズの1993年の文章が、1992年に立ち上がった cypherpunks メーリングリスト上で、思想を指示へと変えた。
名付け親： ジュード・ミルホン（1939–2003）、通称「St. Jude」が「cypherpunk」を生んだ——多くの歴史が誤って脚注へ追いやってきた、一人の女性の功績。
採点表： 制度はプライバシーを与えないという予言と、監視が規模を増すという予言は的中。評判が中心になるというメイの予言は、国家が握る KYC スコアリングへと反転した。
使える倫理： 「Cypherpunk はコードを書く」とは、約束を信じるな、仕組みを確かめよ、ということ——一行もコードを書かなくても、方針による保証より構造による保証を選べる。

よくある質問
#

Cypherpunk Manifesto とは何ですか？
#

エリック・ヒューズが書き、1993年3月9日に cypherpunks メーリングリストへ投稿された短い文章です。開かれた社会にはプライバシーが欠かせないこと、制度は自ら進んでそれを与えないこと、だから暗号で直接作るしかないことを主張しています。最もよく知られた一行「Cypherpunk はコードを書く」が、その議論をまるごと凝縮しています——プライバシーはお情けとして求めるものではなく、仕組みに作り込むものだ、と。

Cypherpunk Manifesto を書いたのは誰ですか。「cypherpunk」という語を作ったのは誰ですか？
#

宣言を1993年に書いたのはエリック・ヒューズです。「cypherpunk」という語そのものは、別の人物、ジュード・ミルホンが生みました。作家でありプログラマーで、「St. Jude」として知られた彼女が、「cipher」と「cyberpunk」を掛けた語遊びとして作ったのです。ヒューズ、ティム・メイ、ジョン・ギルモアが1992年末に cypherpunks メーリングリストを立ち上げ、宣言はそこで投稿されました。

Cypherpunk Manifesto と Crypto Anarchist Manifesto は、どう違いますか？
#

別々の2つの文章です。ティム・メイの『Crypto Anarchist Manifesto』（1988年執筆）のほうが過激で、暗号が国家の手の届かない匿名の仕組みを——善くも悪くも——可能にすると予言しました。ヒューズの『Cypherpunk Manifesto』（1993年）は、より建設的で的を絞っています。プライバシーを定義し、それは与えられるものではなく作るものだと言い切り、読者にソフトウェアを書くよう呼びかけました。メイがその帰結を描いたとすれば、ヒューズは果たすべき務めを描いたのです。

Cypherpunk Manifesto は、2026年のいまも意味がありますか？
#

あります。むしろ書かれた当時より大きい、と言えるほどです。中心の予言——制度はプライバシーを与えないこと、監視は人間の限界を超えて規模を増すこと——は、AI 規模のデータ相関、消せないデジタルの足跡、義務化された本人確認の関所によって、日々裏づけられています。中心の指示、つまり「制度の約束より、検証できる仕組みを信じよ」は、今日のどんなプライバシーツールや法律を見極めるときにも、そのまま使える試金石です。

cypherpunk になるには、プログラマーでなければなりませんか？
#

いいえ。「Cypherpunk はコードを書く」は倫理であって、職業の説明ではありません。プログラマーでない人にとっては、ひとつの心の習慣になります——プライバシーの保証が、実際どこに宿っているのかを問う、という習慣です。もっともらしい振る舞いを方針で約束するだけのサービスより、公開され監査できる設計や、強制できる中央の運営者がいないプロトコルに、プライバシーが性質として備わったツールを選ぶ。方針によるプライバシーより構造によるプライバシーを選ぶことが、一行もコードを書かずに宣言を実践することなのです。

#	出典	URL	アーカイブ
1	Eric Hughes — 『A Cypherpunk’s Manifesto』（1993年）	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html
2	『A Cypherpunk’s Manifesto』 — Nakamoto Institute library	https://nakamotoinstitute.org/library/cypherpunk-manifesto/	https://web.archive.org/web/*/https://nakamotoinstitute.org/library/cypherpunk-manifesto/
3	Tim May — 『The Crypto Anarchist Manifesto』	https://www.activism.net/cypherpunk/crypto-anarchy.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/crypto-anarchy.html
4	David Chaum — 『Security Without Identification』（CACM 28(10), 1985年）	https://www.semanticscholar.org/paper/Security-without-identification%3A-transaction-to-big-Chaum/a6020d6bce5c69e476dfee15bdf63944e2a717b3	https://web.archive.org/web/*/https://dl.acm.org/doi/10.1145/4372.4373
5	Jude Milhon — Wikipedia	https://en.wikipedia.org/wiki/Jude_Milhon	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Jude_Milhon
6	Cypherpunk — Wikipedia	https://en.wikipedia.org/wiki/Cypherpunk	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Cypherpunk
7	“Girls Need Modems!” — Jude Milhon（Capitol Technology University）	https://www.captechu.edu/blog/girls-need-modems-battle-cry-of-hacktivist-jude-milhon	https://web.archive.org/web/*/https://www.captechu.edu/blog/girls-need-modems-battle-cry-of-hacktivist-jude-milhon

削除しても消えない——2026年、SNSの足跡はどこまで残るのか

Thu, 11 Jun 2026 00:00:00 +0000

多くの人にとって、デジタルの足跡は「ボタン」の姿で現れる。「アカウントを削除」。「停止」。「データをダウンロード」。その画面は安心させてくれる——ひとつクリックすれば、過去は消える。SNS が生まれておよそ20年、何十億もの人々がそのボタンを文字どおりに信じてきた。

だが、そうではない。ほとんどのプラットフォームで、削除とは「表示されるもの」の変更であって、「保持されるもの」の変更ではない。あなたのプロフィールは公開ビューから消えても、複製はサーバーのバックアップに、あなたが送った相手の受信箱に、すでに売り渡された先のデータブローカー（個人データを収集・転売する業者）の記録に残る——2014年の FTC の調査では、あるブローカー1社がほぼ全アメリカ人について3,000のデータ項目を保有していた。そして2026年、新たな複製先が加わった。AI——大規模言語モデル——の学習データだ。そこに取り込まれた投稿は、元が消えたあとも長く、モデルの中に生き続ける。

では、削除を押したとき実際に何が残り、あなたに何ができるのか。これは「魔法の消去ツール」の手引きではない。そんなものは存在しないからだ。これは脅威モデルから始める棚卸しの手順書である——自分の足跡をはっきり見て、本当に重要なものを決め、実際の露出を変える場所に労力を注ぐためのものだ。気休めのためではない。

「削除」というユーザーインターフェースの幻想
#

ほとんどのプラットフォームで、削除は権限の変更であって、破壊の動作ではない。プラットフォームはあなたのコンテンツを公開ビューに表示しなくなり、しばしばあなた自身からも見えなくする。しかしその下の記録は、あなたの手の届かないシステムに残り続ける。「隠された」と「消えた」の差を理解することが、足跡管理のすべての土台になる。

「削除された」データが生き残る場所は4つある。まともなプライバシー指南なら、どれもこの点で一致する。

残る場所	何が残るか	「削除」は届くか	あなたの手段
プラットフォームのバックアップ・ログ	アカウントデータ、送った DM（相手の受信箱に）	届かない——一定期間保持される	消去請求（部分的）
データブローカー	すでに収集・売却・配信された記録	届かない——下流の複製が元より長生きする	業者ごとの削除・収集停止申請（繰り返し必要）
シャドープロフィール	あなたが登録していなくても、他人の連絡先アップロードやタグ付けから組み立てられる人物情報	届かない——アカウントなしで構築される	他人が紐づけられる情報を最小化
キャッシュ・スクリーンショット	注目を集めたものすべて	届かない——消す前に複製される	事後の手段なし——投稿時に防ぐ

プラットフォームがあなたに見落としてほしい区別もある。停止は削除ではない。 停止は単にプロフィールを隠し、あなたの帰還に備えてすべてを温めておくだけだ。明示的な「削除」請求だけが、（部分的な）消去を始める。削除の前に、まず自分のアーカイブをダウンロードすること。もう見られないものは棚卸しできない。

EU の GDPR やカリフォルニアの CCPA/CPRA の下にいるなら、ここに法的なてこがある——消去権と削除権だ。下記の手順で意図的に使う。ただし、法的権利は「請求」であって完全消去の保証ではなく、あなたが自ら手渡したデータまでしか届かない。一方、国家に提出を強いられる記録は、それ自体のスケジュールで漏れていく——独自の手順書を要する、並行したもうひとつの問題だ：国家があなたのデータを漏らす日——2026年の防御戦略。

2026年の新しい経路——あなたの投稿は、いまや AI の学習データ
#

プライバシー SaaS のページやプラットフォームのヘルプが教えてくれないことがある。削除サービスを売る役には立たないからだ。公開 Web の大部分はすでに AI モデルの学習に取り込まれており、「元を削除」してもモデルが学習済みのものは消えない。

公開された投稿、キャプション、コメント、画像は、Web 規模の大規模データセットに集められてきた——主要各社のモデル学習に使われた Common Crawl が最もよく知られる——そして言語・画像モデルの学習に使われる。テキストや写真がいったんモデルの学習に取り込まれてしまえば、その重みの中に届く「削除」ボタンは存在しない。「機械的忘却（machine unlearning）」——学習済みモデルに特定のデータを忘れさせる問題——を研究する人々は、これを本当に難しく、大規模ではいまだ未解決だとみなす。確実な対処はそのデータなしで再学習することだが、モデルの所有者が個人の請求でそれを行うことはまずない。それとは別に、セキュリティ研究者は、学習データの断片が大規模モデルから抽出されうることを実証した。つまり、学習への取り込みは、データが消えていく一方的な処理ではなく、保存の一形態なのだ。

ここから3つの帰結が導かれる。これらは前節の理解をまるごと塗り替える。

Web アーカイブは記憶であると同時に、永続化の装置である。 Internet Archive の Wayback Machine や同種のクローラーは、あなたがすでに削除したページのスナップショットを保持する——そしてそのスナップショット自体が、将来のデータセットに再び取り込まれうる。元での削除は、スナップショットには届かない。
後始末より、タイミングが効く。 取り込みは継続的に起こるため、完全に有効な唯一の制御は、そもそも機微なものを公開しないことだ。公開後の防御はすべて部分的でしかない。
法は、不均一に追いついている。 EU AI Act のような枠組みは学習データと透明性の規制を始めており、GDPR の消去権はモデル学習に対して試されつつある。これは動き続ける生きた最前線だ——注視する価値はあるが、まだ頼りにするものではない。

実際的な結論は、居心地は悪いが視界を晴らす。公開で投稿するものはすべて、機械の記憶のレベルで永続しうるものとして扱え。それは絶望の理由ではない。下の棚卸しが、削除の連打ではなく脅威モデルから始まる理由なのだ。

ジャスティン・サッコの12時間のフライトが、2026年もなお教えること
#

なぜ永続性が重要なのか。それを定義づけた事例を見よう。2013年12月、企業広報のシニアディレクターだったジャスティン・サッコは、ロンドンからケープタウンへのおよそ11時間のフライトに搭乗する前、当時まだ少なかったフォロワーに向けて1件の無神経なツイートを投稿した。

“Going to Africa. Hope I don’t get AIDS. Just kidding. I’m white!” （アフリカに行く。エイズにならないといいけど。冗談よ、私は白人だから！）

約170人のフォロワーに投稿された。彼女の飛行機が着陸する頃には、ハッシュタグ #HasJustineLandedYet が世界中でトレンド入りし、見知らぬ人々が彼女の到着を待って更新を繰り返し、彼女は職を失っていた。世界がすでに複製を取り終えるより先に、彼女が削除する機会はなかった。

— ジャスティン・サッコの事例、2013年12月

そのツイートをどう評価するにせよ——憤りをもって裁かれた——「仕組み」こそが教訓であり、その仕組みは以来強まる一方だ。約170人へのメッセージが、数時間で世界規模の出来事になった。削除は無関係だった。コンテンツは、本人が動けるより先にスクリーンショットを撮られ、引用され、報道されて永続化していた。10年以上たったいまも、彼女の名前は検索結果の1ページ目に、報道に、そしていまでは、人々が彼女について尋ねる AI モデルの学習データの中に、その出来事を浮かび上がらせる。

この事例は3つの揺るがぬ規則を教える。投稿の瞬間、リーチは見えていない——フォロワーが少ないことは、露出が小さいことを意味しない。削除は、追いつけない群衆と競走する——注目が来てしまえば、複製はあなたを追い越す。そして永続性は非対称だ——たった一度の悪い1分が、何年もの文脈を生き延びる。防御は、より速い削除ではない。公開の前の意図的な間（ま）だ。次にこれを「24時間ルール」——投稿する前に頭を冷やす待機時間——として定式化する。（Cora の Series E では、記録された OPSEC の失敗事例をこの切り口で掘り下げていく。）

古いアカウント棚卸しの手順書——6ステップの自己点検
#

ここは競合が公開しない部分だ。何も売れないからである。これは私がこのガイドのために組み立て、読者に勧める6ステップの棚卸しだ——足跡を「見る」ことから「形づくる」ことへ進む手順である。まず一度しっかりとやり、その後は毎年見直すこと。

ステップ	目的	ツール例
1. 棚卸し	全体地図を見る	本名・旧ハンドルの検索／Wayback Machine
2. 脅威モデル化	敵と資産に名前をつける	紙とペン／Privacy 柱
3. トリアージ	本当に危険な少数を見つける	位置・行動パターン・身元紐づけの点検
4. 意図的に削除	正しい順序で消す	アーカイブ取得／停止でなく削除／アプリ連携解除
5. 消去請求・オプトアウト	法的なてこを使う	GDPR Art.17／CCPA 請求、ブローカーのオプトアウト
6. 仮名移行・24時間ルール	将来の永続化を防ぐ	身元の分離／投稿前に待つ習慣

ステップ1——実際に何が出回っているかを棚卸しする。 放置したものも含め、これまで作ったすべてのアカウントを書き出す。本名、すべての旧ユーザー名、メールアドレスで検索する。すでに削除したプロフィールのスナップショットを Wayback Machine で確認する。まだ何も直さない。地図を描いているのだ。

ステップ2——設定に触れる前に脅威をモデル化する。 敵と資産に名前をつける。守る相手は、将来の雇用主か、元交際相手か、ストーカーか、doxxer（個人情報を暴いて晒す人間）か、それとも単に自分の将来の評判か。正直な答えが、その後のすべてを決める——公の場に立つ専門職と、虐待から逃れてきた人とでは、正反対の戦略が要る。（これは Cora のすべての仕事の根底にある脅威モデルとしてのプライバシーの習慣だ。初めてなら、Privacy & OPSEC の柱から始めるとよい。）

ステップ3——量でなく、実際のリスクでトリアージする。 足跡の大半は無害だ。そうでない少数を見つける。自宅や職場の位置、行動パターンや人間関係を露わにする写真、仮名を法的身元に結びつけるもの、いま保っているペルソナと矛盾するもの。これらに順位をつける。限られた労力はここに注ぐ。

ステップ4——正しい順序で、意図的に削除する。 まずアーカイブをダウンロードする。次に、停止ではなく「削除」し、アカウントを閉じる前にサードパーティのアプリ連携を解除し、残すつもりのアカウントでも高リスクの個別投稿は消す。順序が大事だ——削除の前に連携アプリの認可を取り消さないと、アクセスが残ることがある。

ステップ5——消去権を行使し、ブローカーからオプトアウトする。 法的な立場がある場合——GDPR の消去権、CCPA/CPRA の削除権——は、請求を書面で行い、記録を残す。主要なデータブローカーには収集停止（オプトアウト）と削除の請求を出す。これは退屈で反復的な作業であり、一度で終わらない。ブローカーはデータを再取得するからだ。

ステップ6——仮名へ移行し、24時間ルールを採用する。 これからは、本名に永久に結びつけたくないものについて、長く使い続けられる仮名を法的身元から分離し、その分離を厳密に保ち続ける。そして、サッコが持たなかった規則を導入する。感情的・政治的、または他者に関する投稿はすべて、公開する前に24時間待つ。この24時間ルールは、ここで最も効果の高い習慣だ。永続化の装置が動く前に作用する、唯一の防御だからである。

リスクが非対称なとき——女性と標的にされる個人の足跡リスク
#

すべての読者を一様に扱う足跡ガイドは、最も必要とする読者を静かに見捨てている。永続的なデジタルの痕跡が持つリスクは、均等には分布しない。女性、虐待や DV から逃れてきた人、活動家、その他の標的にされる個人にとって、位置・行動パターン・人間関係を露わにする古い投稿は、恥ずかしさではない——敵が実際に動ける、身体的安全の露出だ。

ここでプライバシーは抽象ではなくなる。ストーカーや doxxer に侵入は要らない。彼らはあなたが公開で残した足跡から標的を組み立てる——タグ付けするジム、背景に写る学校、予測しやすい金曜の行動パターン。事後の削除は、リスクが最も高い場面でこそ最も無力だ。動機ある敵はすでに必要なものを複製しているからだ。こうした読者にとって、棚卸しの重心は反転する。ステップ2と3——脅威モデル化と位置のトリアージ——が、網羅性よりはるかに重要になり、24時間ルールは「そもそも何を明かすか」についての常時の規律になる。

私がこれについて書くのは、ひとつの確信からだ。プライバシーは秘密主義ではないし、被害妄想でもない。それは——Eric Hughes が『A Cypherpunk’s Manifesto』（1993）に記したように——自分の何を世界に明かすかを、自分で選ぶ力だ。何を、誰に、いつ見せるかを決める力。その力は尊厳の問題であり、不均等に課税されている。それを意図的に守ることは、隠れることではない。自己尊重を運用に落とし込むことだ。非対称なリスクを抱える読者は、足跡の規律を継続的な実践として扱うべきであり、自分の人生に対する自己決定を貫くSovereignty の柱へ進むとよい。

結論——あなたに合うのはどの構えか
#

足跡の規律に、唯一の正解はない。あるのは、あなたの脅威モデルに合う水準だ。

特定の敵がいない、ふつうの利用者なら： 棚卸しを一度行い、本当に危険な少数を直し、24時間ルールの習慣を取り入れ、そこで止める。網羅性に週末を費やす価値はない。
公の場に立つ——専門職、クリエイター、候補者なら： 永続を前提に、意図的に編集し、最悪の項目に消去権を行使し、新しい投稿はすべて長期の負債か資産として扱う。サッコの仕組みは、あなたに向けられている。
非対称なリスクを抱える——ハラスメントに直面する女性、被害から逃れてきた人、活動家、動機ある敵を持つ人なら： 位置と人間関係の露出を何より優先し、仮名を法的身元から分離し、24時間ルールを公開前の関門として扱い、棚卸しを定期的に見直す。ここでは、予防こそが唯一の信頼できる制御だ。

3つすべてに共通する真実がある。事後に削除して安全にたどり着くことは、確実にはできない。できるのは、はっきり見て、意図的に決め、永続してほしくないものを、より少なく公開することだけだ。

要点

削除 ≠ 消去： ほとんどのプラットフォームで、削除は公開ビューから隠すだけで、バックアップ・相手の複製・データブローカー・シャドープロフィールは保持し続ける。
AI は2026年の永続化経路： 公開投稿がモデルの学習データに吸収されると、学習済みの重みに届く「削除」はない——「機械的忘却」は大規模では未解決で、後始末より予防が勝る。
リーチは投稿時に見えない： サッコのツイートは約170人に届き、11時間のフライト1回で世界規模の出来事になった——フォロワーの少なさは、露出の小ささを意味しない。
削除より先に棚卸し： 棚卸し→脅威モデル化→トリアージ→意図的な削除→消去権→仮名＋24時間ルール。労力は実際のリスクがある場所へ。
24時間ルールが最も効果が高い： キャッシュ・アーカイブ・学習クローラーが複製する前に作用する、唯一の防御だ。

よくある質問
#

SNS アカウントを削除すれば、本当にデータは消えますか？
#

いいえ、完全には消えません。削除はプロフィールを公開ビューから外し、プラットフォーム内部の消去を始めますが、複製はバックアップに、あなたがやり取りした相手の受信箱に、すでに売却されたデータブローカーの記録に、Web アーカイブに、そしておそらく AI の学習データセットに残ります。削除は露出を減らしますが、消去を保証しません。

自分の投稿を AI の学習データセットから消せますか？
#

たいていの場合、遡っては消せません。コンテンツがいったん学習済みモデルに取り込まれると、信頼できる個人単位の削除はありません。特定のデータをモデルに忘れさせること（機械的忘却）が、大規模では未解決の問題だからです。一部のプラットフォームや法域は将来の学習からのオプトアウトを提供し始めており、それは使う価値がありますが、確実な制御は、そもそも機微なものを公開しないことです。

GDPR や CCPA は、プラットフォームにすべての削除を強制しますか？
#

強力ですが、限界のあるてこを与えます。GDPR 第17条（消去権）と CCPA/CPRA の削除権は、対象事業者に有効な削除請求への対応を求めます——ただし、法的保持や法的請求の防御（両者に共通）、加えて CCPA ではセキュリティインシデントの検知、といった例外があります。これらは事業者があなたのものと特定できるデータに適用され、下流の複製やモデル学習に対する執行はなお試されている段階です。請求は出すこと。そして、すべての複製に届くとは思わないこと。

「24時間ルール」とは何ですか？
#

感情的・政治的、または他者に関する投稿を公開する前に、24時間待つという自分への規則です。キャッシュ・アーカイブ・AI クローラーは数分で投稿を複製しうるため、削除がそれらに勝つことはまれです——だから、一貫して有効な唯一の防御は、公開の前の間（ま）なのです。記録に残る足跡の失敗の大半を、これひとつで防げたはずです。

参考資料
#

#	出典	URL	アーカイブ
1	GDPR 第17条——消去権（「忘れられる権利」）	https://gdpr-info.eu/art-17-gdpr/	https://web.archive.org/web/*/https://gdpr-info.eu/art-17-gdpr/
2	カリフォルニア CCPA——削除権（California Attorney General）	https://oag.ca.gov/privacy/ccpa	https://web.archive.org/web/*/https://oag.ca.gov/privacy/ccpa
3	Jon Ronson “How One Stupid Tweet Blew Up Justine Sacco’s Life,” NYT Magazine, 2015（有料。書籍 So You’ve Been Publicly Shamed, Riverhead, 2015 にも収録）	https://www.nytimes.com/2015/02/15/magazine/how-one-stupid-tweet-blew-up-justine-saccos-life.html	NYT はアーカイブのクローラーを遮断（2025年〜）。Ronson（2015）書籍を参照
4	EU AI Act——欧州委員会（公式）	https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai	https://web.archive.org/web/*/https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
5	米 FTC “Data Brokers: A Call for Transparency and Accountability”（2014）	https://www.ftc.gov/reports/data-brokers-call-transparency-accountability-report-federal-trade-commission-may-2014	https://web.archive.org/web/*/https://www.ftc.gov/reports/data-brokers-call-transparency-accountability-report-federal-trade-commission-may-2014
6	Carlini ほか “Extracting Training Data from Large Language Models”（USENIX Security 2021、preprint arXiv:2012.07805）	https://arxiv.org/abs/2012.07805	https://web.archive.org/web/*/https://arxiv.org/abs/2012.07805
7	Internet Archive——Wayback Machine	https://web.archive.org/	—（アーカイブそのもの）
8	Eric Hughes “A Cypherpunk’s Manifesto”（1993）	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html

全次元の一覧表

Wed, 15 Jul 2026 00:00:00 +0000

開示事項：本ページの性質 · アフィリエイト · 訂正窓口

本ページは事実の記録です。助言・推奨・勧誘・保証ではなく、掲載は承認を意味しません。ポリシーは変わるため、値に依拠する前に事業者の一次文書を確認してください。
現在、掲載サービスとのアフィリエイト関係は一切ありません。将来導入する場合は該当箇所に明記し、掲載や並び順には影響させず、変更はこのページに記録します。
掲載事業者または読者が値に誤りがあると考える場合は、次の窓口へ連絡できます。確認の結果、データセットの誤りと判断した場合は公開訂正します。連絡先： editor@cypherpunkguide.com
データの収集・確認方法（方法論）

横にスクロールすると8サービスの全列を見られます →

次元	ClaudeAnthropic	DeepSeekDeepSeek	GeminiGoogle	Le ChatMistral AI	ChatGPTOpenAI	OpenRouterOpenRouter	PerplexityPerplexity	VeniceVenice
登録・利用時の身元各接点で事業者が要求・収集する身元情報。
アカウント要否	条件付き事業者の記載有料プランへのアップグレード · 全地域（既定） · 無料/有料 · Web/API	現行の範囲付き記録なし	条件付き事業者の記載ログイン状態での利用 · 全地域（既定） · 無料/有料 · Web/アプリ	条件付き事業者の記載製品による（一部の製品でアカウント必須） · 全地域（既定） · 無料/有料 · Web/アプリ	現行の範囲付き記録なし	必須事業者の記載全地域（既定） · 無料/有料 · Web/API	現行の範囲付き記録なし	任意事業者の記載全地域（既定） · デモ · Web
登録に要る識別子	現行の範囲付き記録なし	メールまたは電話事業者の記載全地域（既定） · 無料/有料 · Web	必須事業者の記載全地域（既定） · 無料/有料 · Web/アプリ	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	必須事業者の記載全地域（既定） · 無料/有料 · Web	現行の範囲付き記録なし
登録時の電話番号	必須事業者の記載対応地域 · 無料/有料 · Web/デスクトップ/モバイル · Google SSO/メール	メールまたは電話事業者の記載全地域（既定） · 無料/有料 · Web	現行の範囲付き記録なし	提供した場合に収集事業者の記載全地域（既定） · 無料/有料 · Web/アプリ	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし
登録時のメール	条件付き事業者の記載メール登録経路を選んだ場合（代替はGoogle SSO） · 対応地域 · 無料/有料 · Web/API	メールまたは電話事業者の記載全地域（既定） · 無料/有料 · Web	現行の範囲付き記録なし	収集される事業者の記載全地域（既定） · 無料/有料 · Web/アプリ	現行の範囲付き記録なし	条件付き事業者の記載全地域（既定） · 無料/有料 · Web/API	現行の範囲付き記録なし	現行の範囲付き記録なし
ログイン方式（SSO／ウォレット）	Google SSOまたはメールのワンタイムリンク事業者の記載全地域（既定） · 無料/有料 · Web/デスクトップ/モバイル	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	メール、ソーシャルログイン、Web3ウォレットのいずれか事業者の記載アカウントを作成する場合（デモは不要） · 全地域（既定） · 無料/有料 · Web
最低年齢	18歳以上事業者の記載全地域（既定） · 無料/有料 · Web/API	現行の範囲付き記録なし	現行の範囲付き記録なし	13歳以上事業者の記載全地域（既定） · 無料/有料 · Web/アプリ	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし
利用中・復旧時の身元／電話番号確認	条件付き事業者の記載事業者の裁量（「特定の状況では」） · 全地域（既定） · 無料/有料 · Web/API	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし
決済・請求時の身元情報	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	必須事業者の記載有料プランへのアップグレード · 全地域（既定） · 有料 · Web	暗号資産決済に対応事業者の記載全地域（既定） · 有料 · Web/API	現行の範囲付き記録なし	現行の範囲付き記録なし
データの扱い入力内容とデータの扱い（保存・保持・学習・人手による確認・共有）。
入力内容の接続先事業者への転送	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	下流事業者へ送信事業者の記載全地域（既定） · 無料/有料 · Web/API	現行の範囲付き記録なし	保存しない条件を下流事業者に課す事業者の記載全地域（既定） · 無料/有料/デモ · Web
入力内容の学習利用	既定で有効（オプトアウト可）事業者の記載全地域（既定） · 無料/有料 · Web	既定で有効（オプトアウト記載なし）事業者の記載全地域（既定） · 無料/有料 · Web	現行の範囲付き記録なし	既定で有効（オプトアウト可）事業者の記載全地域（既定） · 無料 · Web/アプリ	既定で有効（オプトアウト可）事業者の記載全地域（既定） · 無料/有料 · Web	下流事業者ごとに異なる（選択可）事業者の記載全地域（既定） · 無料/有料 · Web/API	メール内容は除外事業者の記載全地域（既定） · 無料/有料 · Web	現行の範囲付き記録なし
会話の人手による確認	現行の範囲付き記録なし	現行の範囲付き記録なし	あり事業者の記載全地域（既定） · 無料/有料 · Web/アプリ	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし
保持期間	現行の範囲付き記録なし	現行の範囲付き記録なし	最大3年事業者の記載会話が人間レビューの対象になった場合 · 全地域（既定） · 無料/有料 · Web/アプリ	利用者が消すまで事業者の記載全地域（既定） · 無料/有料 · Web/アプリ	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	保持しない事業者の記載全地域（既定） · 無料/有料/デモ · Web
削除と識別子の再利用	利用可事業者の記載全地域（既定） · 無料/有料 · Web	利用可事業者の記載全地域（既定） · 無料/有料 · Web	現行の範囲付き記録なし	利用可事業者の記載全地域（既定） · 無料/有料 · Web/アプリ	利用可事業者の記載全地域（既定） · 無料/有料 · Web削除後に再利用可事業者の記載全地域（既定） · 無料/有料 · Web	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし
任意で使えるプライバシー設定	現行の範囲付き記録なし	現行の範囲付き記録なし	利用可事業者の記載全地域（既定） · 無料/有料 · Web/アプリ	利用可事業者の記載全地域（既定） · 無料/有料 · Web/アプリ	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし
データ管理者が示す法域	現行の範囲付き記録なし	中国（CN）事業者の記載全地域（既定） · 無料/有料 · Web	現行の範囲付き記録なし	フランス（FR）事業者の記載全地域（既定） · 無料/有料 · Web/アプリ	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし
ネットワーク層（別枠）本データセットが扱う事業者アカウントの身元要件とは別の範囲。IPアドレス、端末情報、サイト分析はネットワーク層の事実として分けて記録する。
第三者によるサイト分析	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	あり事業者の記載全地域（既定） · 無料/有料 · Web	現行の範囲付き記録なし	現行の範囲付き記録なし
収集されるメタデータ（IPなど）	現行の範囲付き記録なし	現行の範囲付き記録なし	収集される事業者の記載全地域（既定） · 無料/有料 · Web/アプリ	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	現行の範囲付き記録なし	収集される事業者の記載全地域（既定） · デモ · Web

列はアルファベット順です。 · 事業者の記載と画面上の実地観測は別々に表示し、どちらかで他方を上書きしません。 · 値のあるセルは「適用範囲付き記録が1件以上」の意味であり、全地域・全プラン・全画面を網羅した意味ではありません。 · 現行の範囲付き記録なし = このパイロットに現行の範囲付き記録がない項目です。「要件なし」を意味しません · ⚠ = 情報源が矛盾 · ↻ = 経時変化あり · スコア・ランキング・推奨はありません。

この表の読み方
#

表示値には、登録済み証拠の役割がある。 事業者文書は公表内容を記録する。管理された製品画面の観測は、条件を固定した一つの経路で起きたことを記録する。両者は別々に表示し、一方が他方を黙って上書きしない。現行パイロットにある値は事業者の記載だけだ。
適用範囲も値の一部だ。 地域、プラン、利用形態、登録方法、そのほかの表示条件が、その記録で言える範囲を限定する。適用範囲付きの記録が1件あっても、サービスの全条件を調べたことにはならない。
「未評価」は、適用範囲付きの現行記録がないという意味だ。 そのサービスと次元について、表示範囲に対応する現行記録がない。「要件が存在しない」という証拠ではなく、沈黙を「要件なし」へ変換しない。
⚠は登録済み証拠の矛盾を示す予約表示で、現行パイロットでは未使用だ。 P0では、同等の適用範囲を持つ証拠が食い違うと公開を保留する。P1で追記型の構造化された矛盾関係を導入した後は、どちらかを自動的に優先せず両方を表示できる。
↻は経時変化の印だ。 以前の状態を裏付ける証拠がある場合は、何が変わったか、その期間をどこまで絞り込めたかをサービスページに示す。
列はアルファベット順だ。 ランキングもスコアも「ベスト」もない。どこまでのひも付けを受け入れるかは、読者自身の脅威モデルによって決まる。データから読み取れる内容は公開所見、各記号と証拠の確認方法はmethodologyにまとめている。

戻る: サービス別の記録 · 公開所見 · Methodology

8つのhosted AIを44件の記録で比べる — 3つの独立した違い

Tue, 14 Jul 2026 00:00:00 +0000

開示事項：本ページの性質 · アフィリエイト · 訂正窓口

本ページは事実の記録です。助言・推奨・勧誘・保証ではなく、掲載は承認を意味しません。ポリシーは変わるため、値に依拠する前に事業者の一次文書を確認してください。
現在、掲載サービスとのアフィリエイト関係は一切ありません。将来導入する場合は該当箇所に明記し、掲載や並び順には影響させず、変更はこのページに記録します。
掲載事業者または読者が値に誤りがあると考える場合は、次の窓口へ連絡できます。確認の結果、データセットの誤りと判断した場合は公開訂正します。連絡先： editor@cypherpunkguide.com
データの収集・確認方法（方法論）

KYC Driftは現在、8つのhosted AIについて44件の事実記録を持つ。44件全てが事業者の規約、プライバシーポリシー、ヘルプ資料に基づき、アーカイブ証拠へつながっている。管理された製品画面の観測はまだ0件だ。このページが扱うのは事業者の公表内容であり、新規登録や管理されたテストで確認したシステムの挙動ではない。

現行パイロットから言えること
#

比較対象は8サービス×17次元、計136欄である。うち45欄には適用範囲付きの現行記録が1件以上あり、91欄にはない。この数は現在の収録状況を示すもので、割合による網羅度や全範囲の調査完了を示すものではない。各記録が支えられるのは、表示された地域、プラン、利用形態、登録方法、そのほかの条件に限られる。

証拠に結び付いた44件の記録があれば、公表されたルールの具体的な違いは見える。しかし、一つのプライバシー尺度でサービスを並べるには足りない。以下の3つは、それぞれ別の次元の比較だ。電話番号を重く見る人もいれば、入力の転送先を重く見る人もいる。KYC Driftは判断材料となる日付付き証拠を示すが、異なる基準を一つの点数へまとめない。

別々に判断すべき3つの違い
#

アカウント作成時に扱う識別子について、事業者文書の記載が異なる。 Anthropicのヘルプ資料は、Claudeの全新規ユーザーにSMSでの電話番号確認が必要で、スキップできず、VoIP番号などを受け付けず、一つの電話番号を一つのアカウントに結び付けると記載している。DeepSeekのプライバシーポリシーは、アカウント設定時にメールアドレスと電話番号の一方または両方を収集する場合があると記載する。これは二つの公式文書の比較であり、どちらかの登録経路をこちらで再現したという主張ではない。Claudeの記録とDeepSeekの記録には、適用範囲とアーカイブ本文を示している。どちらにも製品画面の実地観測はない。

「削除」が指す保持条件も同じではない。 Veniceは入力内容と出力を保持しないと記載する。ClaudeとChatGPTは、例外条件を伴う一定期間内の削除を説明する。Mistralは、会話は利用者が削除するまで残り、アカウント情報や本人確認に関わる一部情報には、さらに長い保持期間があると記載する。Geminiは、人間が確認した一部の会話が、アクティビティ削除後も最大3年残り得ると説明する。DeepSeekはチャット履歴を削除できる一方、保持期間を広く「必要な限り」とする。いずれも事業者の記載であり、実際のシステムがそのとおり処理したと確認した結果ではない。

中継型サービスでは、責任を二つの事業者に分けて読む必要がある。 OpenRouterとVeniceはいずれも、入力が接続先のモデル事業者へ渡り得ると記載する。OpenRouterは保持や学習利用が接続先によって変わり、一定のデータ方針を掲げる事業者を選ぶ設定があると説明する。Veniceは、接続先にzero-data-retention（データを保持しない）条件を課すと説明する。問うべきなのは、どちらが上かではない。誰が入力を受け取り、どの文書上の約束が適用され、その約束を独立に検証できているかだ。現行パイロットでは、どちらも実際の運用までは検証していない。

このパイロットでは確定できないこと
#

通信経路上の匿名性、決済仲介者に渡る情報、法的手続で到達できる範囲は測っていない。製品画面、地域ごとの利用可否、内部システムでの実施状況も未検証だ。事業者の記載という表示は、アーカイブ本文を確認した時点で、その主張が文書内にあったという意味に限られる。事業者のシステムをCypherpunkGuideが検証済み、という意味ではない。

適用範囲付きの現行記録がない91欄も重要だ。未評価とは、そのサービス・次元・表示範囲に対応する現行記録がないという意味で、「要件や処理が存在しない」という意味ではない。情報が薄いサービスほど有利に見えることを避けるため、各サービスページで欠落項目を明示する。

月次の再確認は運用目標であり、現時点のSLA（サービス水準の約束）ではない。取得・検証・差分確認・人手判定・公開判定の全工程を本番相当で動かし、稼働状況を確認できる記録を出したうえで、連続2サイクルを正常完了（GREEN）した場合にだけ継続的な約束へ移す。それまでは、各事実の確認済み期限を現行の証拠系列から保守的に算出する。パイロット全体の確認済み期限は、そのうち最も古い日付である。一部だけ再確認しても、全体が新しく見えることはない。

訂正、異議、未収録サービスについてはmethodologyを参照。editor@cypherpunkguide.comで受け付ける。確認の結果、データセットの誤りと判断した場合は訂正内容を公開する。異議への初回応答は原則14日以内を目標とするが、保証された応答期限ではない。

2026年、AIはオープンウェブをどう囲い込んでいるのか

Tue, 30 Jun 2026 00:00:00 +0000

資金について：CypherpunkGuide は監視型広告を一切載せません——広告ネットワークも、トラッキングピクセルも、スポンサー記事もありません。運営は透明な収益源によります：現在は読者からの寄付、将来は購読と編集方針に合致した affiliate です。私たちは広告主ではなく、読者に向き合います。

オープンウェブ——誰もがURLで発信でき、誰もがリンクをたどって見つけ出せる、あのウェブ——は、この二年のあいだにAIを軸にして静かに配管を引き直されてきました。この変化に気づきにくいのは、何の発表もなく、一夜にして壁が立ったわけでもないからです。代わりに起きたことは、トラフィックのログに数字として表れています。Googleが AI生成の答えを表示すると、外部サイトへクリックを送る検索の割合は、およそ15%から8%ほどへ落ち込みます（Pew Research, 2025）。何千ものニュースサイトを横断して見ると、検索からの紹介流入は2025年後半までの一年でおよそ3分の1減りました（Chartbeat のデータ、Reuters Institute が報告）。そして、その注目を吸い上げたAIツールが見返りに送り返すのは、ウェブ訪問のおよそ0.1〜0.5%ほどにとどまります。

つまりウェブは、かつてないほど読まれています——ただし、読んでいるのは人ではなく、読まれても出どころに人が戻ってくるわけでもありません。では、オープンウェブは死につつあるのでしょうか。この問いは、すぐに答えを出さず、少し立ち止まって考えてみる値打ちがあります。答え次第で、次にすることが変わるからです——悼むのか、機械に読まれるよう最適化するのか、それとも機械に囲い込めないものを築くのか。「死につつある」という言葉は、大げさすぎると同時に都合がよすぎます。誠実な診断はもっと狭く、懐古でも降参でもなく、築くことを指し示しています。

私の立ち位置についてひとこと。このサイトは、この記事が最後に勧めることになるやり方で発信しています——自前で運営し、RSSと開かれたソーシャルプロトコルで配信し、どの単一プラットフォームにも存在を預けない。これは勝利の凱旋ではありません。小さくて実地的な実験です。これから語ることは、主張と同じくらい、その限界についても正直であろうとしています。

ウェブはかつてないほど読まれている——ただし、人にではなく
#

変わったのは、ウェブがクロールされるようになったことではありません——それは昔からそうでした。変わったのは、クロールが人を連れ戻さなくなったことです。検索は、人を出どころへと導く案内所でした。AIの回答エンジンは、旅をその場の答えで終わらせる終着点です。この違いこそ議論のすべてであり、しかも取り違えやすいところです。

AIクロールの量そのものを害だと指さすのは、間違いでしょう。なかには並外れて抜き取り型のボットもあります——ある分析では、2025年、ある大手AIクローラーが紹介して送り返す訪問者ひとりにつき、二万を超えるページを取得していたと見積もられました——けれども検索エンジンは、昔から送るトラフィックよりはるかに多くをクロールしてきました。送り返す数より多くクロールすること自体は普通のことで、それが索引化の仕組みです。効いてくる数字は、その比率ではなく、断ち切られた帰り道のほうです。ページは読まれ、答えは差し出され、読者は決してたどり着かない。

その断絶こそ、よりすっきりした数字が浮かび上がらせるものです。同じ検索でも、AI要約が付くか付かないかで、外部サイトへのクリックはおよそ半分に減ります（15%ほどから8%ほどへ）。そしてAIの答えのなかにある引用をクリックする利用者は、わずか1%ほどです（Pew Research, 2025）。ゼロクリック検索——どこへも訪問せずに終わる検索——は、2025年5月までの一年でおよそ56%から69%へ増えました（Similarweb のデータ、Search Engine Roundtable 経由）。データに対して公平でありたいので付け加えると、紹介流入の全般的な落ち込みには、いくつもの原因が同時に絡んでいます——ソーシャルプラットフォームが外部へのリンクを絞ること、コアアルゴリズムの変化、ペイウォール、読者のアプリ移行。だから誠実な因果の主張は、失われた訪問のすべてをAIのせいにするのではなく、「AIの有無で比べる」ところに置くべきです。

	案内所としてのウェブ（検索）	終着点としてのウェブ（AIの答え）
クロールの目的	索引化——人をページへ送り届けるため	取り込み——その場で答えを合成するため
読者が得るもの	訪れるべき出どころの一覧	仕上がった答え。出どころは任意
出どころが取り返すもの	訪問——注目、購読者、収益	ほとんど誰も押さない引用（約1%）
取り引き	発見と引き換えに索引化を許す	約0.1〜0.5%の紹介と引き換えに取り込みを許す

だが人々は、答えそのものを選んでいる
#

囲い込みの物語が飛ばしがちな、居心地の悪い事実があります。たいていの人は、10本の青いリンクより答えを直接求め、それは間違った選択ではありません。 AI検索の読者を純粋な犠牲者として扱う議論は、AI検索がなぜ勝ったのかを読み違えています。だからこそ、そういった議論は簡単に退けられてしまうのです。

人々が離れていくオープンウェブは、たどり着いてみると往々にして敵意に満ちた場所でした——答えを個人的な逸話の奥に埋めた検索最適化の水増し、読み込み中に文章を押しのける広告枠、クッキーの同意バナー、ニュースレターのポップアップ、自動再生の動画。これらすべてを飛ばしてくれる答えは、騙されやすい人にかけられた手品ではなく、日々の暮らしにおける本物の改善です。そこを正直に認めることが、真剣に受け取ってもらうための前提です。

けれど、便利さでは打ち消せない二つのことがあります。一つは、その答えが、回答エンジン自身は手がけてもいない仕事を寄せ集めて作られていること。そしてその仕事に対して、回答エンジンはますます対価を払わず、出どころへも返さなくなっています——費用は、もとになったページを書いた人々へ押しつけられ、取り戻す手立てがありません。もう一つ、長い目で見ればこちらのほうが蝕みます。持続可能性のパラドックスです——出どころを枯れさせる回答の仕組みは、やがて要約できる新しいものも、確かなものも残らなくなります。2025年なかばには、スタンフォード、Imperial College、Internet Archive の研究者たちが、新しく公開されたウェブサイトの17.6%がまるごとAI生成だったと見積もりました——これは、AI生成またはAI補助だったおよそ35%の部分集合です（Gizmodo, 2025 が報告）。「slop」——AIが大量に生み出す低品質なコンテンツ——は、Merriam-Webster の2025年の Word of the Year に選ばれました。ますます自分自身を読んで書き直すウェブは、合わせ鏡の回廊です。問題は、人々が答えを求めることが間違いだということではありません。いまの仕組みが、誰も補充していない共有地を、ひそかに食いつぶしているということです。

いま差し出される対応は、どれも「頼み」か「当座しのぎ」でしかない
#

いま机の上にある手だて——クローラーを遮断する、課金する、それ向けに最適化する、訴える——には、ひとつの隠れた前提があります。囲い込む側か新たな仲介者を「行儀よく」させれば、ウェブの支配を取り戻せるという前提です。それぞれ、それ自体の土俵では真剣に受け取る値打ちがあります。そして真剣に受け取るほど、どれも支配を取り戻すには届かないことがわかります。

遮断は反射的な手で、そして最も弱い手です。robots.txt のルールは、柵ではなくお願いにすぎません。それ自体に確かな法的強制力はなく、潤沢な資金を持つクローラーは、それを無視するか、自分のトラフィックの名札を貼り替えるだけです。最も効くやり方は、遮断を仲介者に委ねるものです——Cloudflare は2025年7月、新規サイトに対して既定でAIクローラーの遮断を始めました（Cloudflare）——これは効きますが、ただし関所を Cloudflare へ移すことによってです。

課金は、最も解決策らしく見える対応で、最も強い形で受け止めるに値します。Cloudflare の「pay-per-crawl（クロールごとの課金）」市場（2025年7月に開始）や、大型のライセンス契約——Reddit が Google から得ているとされる年間約6,000万ドル、News Corp が OpenAI と結んだとされる5年で2億5,000万ドル超の協定——は、決して無に等しいものではありません。これらは機械に読まれることへの、多くの発行者にとって初めての本物の対価であり、無償の抜き取りしかなかったところに現れた価格のシグナルです。問題は構造のほうにあります。pay-per-crawl は、あらゆるサイトとあらゆるモデルのあいだに中央の料金所を据え付けます。「料金を払いさえすればアクセスはかまわない」という原則を呑むことになり、交渉力を持つひと握りの発行者へ金を流し、独立したウェブには、同じ依存をより安上がりにしただけのものを残します。収益分配付きの囲い込み——「囲い込み2.0」——であって、発行者が支配するウェブではありません。

AI検索向けの最適化（「generative engine optimization（生成エンジン最適化）」）は、すでにその条件を呑んだ適応です。訴訟は最も制度的な道で、本当に重い帰結を持ちます——OpenAI に対する著作権訴訟は係争中で、ある裁判官は2026年1月、同社に2,000万件のChatGPTログの提出を命じました（National Law Review、判断は未決）。英国の競争当局は、発行者が Google のAI要約からオプトアウトできるようにしました（Press Gazette, 2026、2026年1月）。EU AI Act の残る透明性義務——AI生成コンテンツの開示ルールを含みます——は、2026年8月に執行段階を迎えます。これらは重要であり、次の節はこれらに反対する議論ではありません。けれど、どれも遅く、管轄に縛られ、不確かです。そしてどれもが、cypherpunk が長らく「制度は善意からは与えない」と言ってきたものを、その制度に与えてくれと頼んでいます。

対応	実際にしていること	正直な利点	それでも請願である理由
`robots.txt` 遮断	ボットに読まないでくれと丁重に頼む	無料で簡単、まともなボットには広く守られる	それ単体で法的強制力なし、強引なクローラーは無視・名札の貼り替え
pay-per-crawl／ライセンス	CDNや契約を通じて機械に課金	初めての本物の対価、価格のシグナル	新たな中央の料金所、「払えばアクセス可」を呑む、既存大手に有利
AI検索向け最適化	回答ボックス向けにコンテンツを整える	囲いの内側でいくらか露出を得る	条件を呑む、いまや関所の番人向けに最適化している
著作権訴訟	学習・利用をめぐって提訴	ライセンスと開示を作り変えうる	遅く、管轄に縛られ、不確か、支配を制度に与えてくれと頼む

オープンウェブは、AIより前にもう囲い込みを受けていた——それこそが要点だ
#

オープンウェブを悼む前に、認めておくべきことがあります。AIが来るずっと前から、ウェブはもう一度、囲い込みを受けていました——15年ものあいだ、発見のほとんどはたった一つの検索ボックスを通り、金のほとんどは一つの広告取引所を通っていたのです。 AIが共有地を舗装したのではありません。その共有地はもともと自由ではなかったのです。これは二度目の囲い込みであり、しかも一度目が発行者に残した唯一の慰め——紹介の訪問——を、いま取り上げつつあります。

この訂正が意味を持つのは、懐古の念を打ち砕くからです。懐古こそが罠です。目標はそもそも、Google時代のウェブを取り戻すことではありませんでした。あれもすでに、誰か他人の有料道路だったのです。役に立つ教えはもっと古く、1993年に書きとめられていました——プライバシーは、そして「開かれていること」も、制度に請願して手に入れるものではない。制度の好意に頼ったプライバシーは、その制度がいつでも取り上げられるプライバシーだからです。cypherpunk の結論は、その保証を仕組みのなかへ作り込むことでした。これはCypherpunk Manifestoの主張を、通信の途上のメッセージにではなく、ウェブそのものに当てはめたものです。

この構図をいち早く見て取った人物が、Richard Stallman でした。彼が1997年に書いた物語The Right to Readは、読むという行為が計量され、テキストへのアクセスがソフトウェアの所有者によって支配される近未来を描きました——自分で開くページではなく、問い合わせるサービスを介して読むことが当たり前になっていくウェブの描写として、的を外していません。そのようなサービスへの彼の異議は、単なる修辞ではなく構造的です。誰か他人のサーバで自分の計算をすることは「本質的に computing freedom（計算の自由）を破壊する」と彼は論じます。ホストされたAIは、コピーを手に入れて自分で動かすことができず、使えるのは、自分の支配下にない他人の機械の上でだけだからです。信頼性についてはさらに歯に衣着せず、彼はそれを「知能」と呼ぶことすら拒み、「bullshit generator（でたらめ製造機）」のほうがふさわしいと言います——彼の言葉でいえば、「真偽に無関心なまま出力を生み出す」システムだからです。この毒舌に乗らなくとも、構造の論点は残せます。cypherpunk の論点です——自分で動かせず、調べられず、フォークできない能力は、誰か他人が支配している能力です。

「制度の好意に頼ったプライバシーは、その制度がいつでも取り上げられるプライバシーだ。」いまや同じことが、アクセス、発見、そして読むことにも言えます。どれであれ、長く持ちこたえる形は、約束ではなく、仕組みの性質でなければなりません。

主権あるウェブへの、正直な再生の道筋
#

建設的な答えは、明日にも主流のウェブをやめることではありません——ほぼ誰にもできません。どの企業の許可も要らない「開かれていること」を持つ並行の層を築くことです。読み方から始めて、発信の仕方で完結します。ありふれた「分散ウェブを使えばいい」という助言と違うのは、道具と同じくらい率直に、その限界も言い切るところです。

まず「読むことの主権」から始めます。こちらが易しいほうだからです。

RSSで出どころを直接フォローする——オープンウェブが生き延びてきた血のめぐりです。これはあなたが手綱を握るフィードで、何を見せるかを決めるアルゴリズムもなく、何が書かれるかを左右するエンゲージメント指標もありません。アルゴリズム任せのフィードからの出口を探す読者が増え、RSSへの関心はふたたび高まっています。
Tor Browser を通して読む——ウェブにも onion サービスにも、仲介を経ずにアクセスするためです。これは周縁の小ネタではなく、屋台骨を担っています。New York Times も、Guardian も、Der Spiegel も、情報提供者のために onion サービスを運営しています。
自分の問いには、ローカルで動くオープンウェイトのモデルで答える——「何もかも分散しよう」という手引きのほとんどが飛ばす一歩です。あなたのデータを分散させても、それを読むことを許された唯一の知能が、誰か他人のGPUの上で動く最先端モデルなら、得るものはわずかです。いまや権力の本当の集中はそこにあります。自分で選んだ索引やフィードを相手に、小さめのモデルをローカルで動かすこと——それが、読むことを「単に場所を移しただけ」ではなく主権あるものにします。モデルへの主権は、データへの主権と同じだけ効いてきます。

「発信することの主権」は、難しいほうの半分であり、より大事なほうでもあります。

安価な仮想サーバ（VPS）で自前運営する——どのプラットフォームにも消せない、自分の住まいです。
RSSと開かれたソーシャルプロトコルで配信する——Nostr と Fediverse の ActivityPub です。読者とのつながりが、プラットフォームに取り消せるものではなくなります。
onion ミラーを用意する——読者が敵意ある場所からあなたに届く必要があるなら。

このどれも、摩擦なしではありません。そうでないふりをすることこそ、この10年の「自分のプラットフォームを持て」という助言が信用を失った理由です。だから、限界を率直に。Fediverse は月間アクティブで100万〜200万人ほどの規模で、10億人ではありません。大陸ではなく、ひとつの町です。IPFS は、検閲への耐性と引き換えに、現実の遅延と急な学習曲線を背負います。自前運営は、何より先にまず、時間と技術を持つ者の特権です。このどれも、主流の検索や大手ソーシャルの到達力に取って代わりはしません。移行が間近だと告げてくる者は、何かを売りつけようとしています。

だからこそ、この層を築くことは、政治の代わりにはなりません。独占禁止の執行、法定ライセンス、英国の規制当局がいま勝ち取ったようなオプトアウト、公益のための検索索引、データ・トラスト——どれも闘い取る値打ちがあり、コードはそのどれの代わりにもなりません。主権あるウェブは、その闘いの下にある土台です——法が遅れたり、取り込まれたりしたときに持ちこたえるもの。そのあいだ、無力でいなくて済むためのものです。cypherpunk の主張は、ソフトウェアが集団行動に取って代わるということでは決してありませんでした。自分の手で動かせる権利は、政治にまず勝つことを前提にしない——それが主張の核心です。

これは机上の話ではありません。このサイトは自前で運営し、Nostr と Fediverse へ投稿し、どのプラットフォームの許しもなく届きます。マニフェスト入門でも記したとおり、自らを名乗るAIクローラーが自分のサーバのログにやって来るのを、毎日見張っています。正直に報告すれば、主権あるウェブは、立つための足場ではあっても、まだ勝つための場所ではありません——回答ボックスだけに向けて最適化した場合より、小さく、見つけてもらうのも遅い。自分たちの利害についても率直に言えば、独立したサイトでもAIの答えのなかで引用されることには得があり、私たちはそれに反対していません。要点は、機械を拒むことではなく、企業が閉じられるチャンネルへの依存を拒むことです。引用されよ、しかし囲い込まれるな。同じ論理は、AI規模の監視をめぐる私たちのほかの仕事にも通じています——AI時代の脅威モデルから、削除がもはやモデルの学習データに届かなくなったあなたの足跡の消えなさまで——そしてウェブの入り口に立ちはだかる本人確認の関所、年齢確認をめぐる闘いにも通じています。

層	一手	何が手に入るか	正直な限界
読む——フィード	自分が手綱を握るRSSリーダー	アルゴリズムも指標もない発見	自分でそろえる、思わぬ出会いの仕掛けはない
読む——アクセス	Tor Browser ＋ onion サービス	仲介を経ない、検閲に強い読書	遅い、Torのトラフィックを冷遇するサイトもある
読む——知能	ローカルのオープンウェイトのモデル	記録されるサービスではなく、自分が動かすソフトからの答え	最先端モデルより小さく、能力も劣る
発信——ホスティング	安価なVPSで自前運営	どのプラットフォームにも消せない住まい	時間・技術・保守は自分の肩に
発信——到達	Nostr ＋ Fediverse ＋ RSS	どのプラットフォームも握らない読者とのつながり	月間100万〜200万規模、大衆への到達ではない

結論——請願するな、築け
#

オープンウェブは自然に死につつあるのではありません。二度目の囲い込みを受けているのです。最も誠実な対応は、懐古でも適応でもなく、築くことです。検索が一度目の囲い込みでした。AIの回答ボックスが二度目で、一度目が残した紹介の訪問を取り去ります。読者が本心から答えを求めるのは理に適っています。だからこそ、出どころのウェブは、感傷ではなく持続可能性と主権を根拠に守られなければなりません。差し出される「頼み」と当座しのぎ——遮断、課金、最適化、訴訟——は、どれも関所の番人を居座らせたままです。古いほうの教えこそ、長く持ちこたえます——誰にも取り消せない仕組みのなかへ「開かれていること」を作り込め、データだけでなくモデルもろとも。法と集団行動の代わりではなく、その下の土台として扱え。それは今年のうちに回答ボックスを規模で上回りはしないでしょう。それでも、壁が立ち終わったとき、立っていられる場所ではあるのです。

要点

害はクロールそのものではなく、断ち切られた帰り道にあります： AI要約があると、外部サイトへのクリックはおよそ半分になり（15%ほどから8%ほどへ）、AIの答えのなかの引用を押す人はわずか1%ほどです。
これは二度目の囲い込みです： AI以前のウェブも、すでに一つの検索ボックスと一つの広告取引所を通っていました。だからGoogle時代への懐古は目標ではありません。目指すのは、誰にも取り消せない仕組みに作り込まれた「開かれていること」です。
答えを求める利用者は間違っていません——けれど、出どころを飢えさせる回答ボックスは持続可能性のパラドックスにぶつかります。2025年なかばには、新しいサイトの17.6%ほどがすでにまるごとAI生成でした。
主流のどの手だても、関所の番人を居座らせます： robots.txt はそれ単体で法的強制力がなく、pay-per-crawl は中央の料金所を据え付け、最適化は条件を呑み、訴訟は遅く管轄に縛られます。
主権にはデータだけでなくモデルが要ります： コンテンツを分散させても、唯一の知能が他人のGPU上の最先端モデルなら、ほとんど変わりません——ローカルのオープンウェイトのモデルこそ、読むことを「場所を移しただけ」でなく主権あるものにします。

よくある質問
#

AIは本当にオープンウェブを閉じているのですか。それとも変えているだけですか？
#

両方です。ただし正確な主張は「ウェブが死につつある」よりも狭いものです。ウェブのコンテンツは、かつてないほど機械にアクセスしやすくなっています。閉ざされつつあるのは、人へ、そしてそれを生み出したサイトへ還る道のほうです。AIの答えが現れると、外部サイトへのクリックはおよそ半分に落ち、その注目を捉えたAIツールが送り返すのは、ウェブトラフィックのわずか0.1〜0.5%ほどです。ウェブはかつてないほど読まれています——ただし、出どころへ還る形で人に読まれてはいません。「囲い込み」のほうが「死」よりよく当てはまります。共有地はまだそこにありますが、その価値へのアクセスが壁で囲われ、計量されつつあるのです。

「pay-per-crawl」とは何ですか。これで問題は解決するのでしょうか？
#

pay-per-crawl は、サイトがAIクローラーを遮断する代わりにアクセスへ課金できるようにする仕組みで、Cloudflare が2025年7月にその市場を立ち上げました。大手の発行者とAI企業が直接結ぶライセンス契約と並ぶものです。これは無償のスクレイピングに対する本物の改善であり、機械に読まれることに対して多くの発行者が初めて目にした金です。けれど、これはウェブの支配を発行者に返しはしません。あらゆるサイトとあらゆるモデルのあいだの料金所として中央の仲介者を据え付け、「料金所の番人に払えばアクセスはかまわない」という原則を呑み、交渉力のある大手の発行者を優遇します。これは収益分配付きの囲い込みであって、オープンウェブではありません。

robots.txt でAIクローラーを遮断すべきですか？
#

できますし、まともなクローラーはたいてい守ります。ただ、それが何であるかを理解しておいてください——柵ではなく、お願いです。robots.txt の指示には単体で確かな法的強制力はなく、強引なクローラーや名札を貼り替えたクローラーは無視できます。遮断はまた、人々が実際に読む答えのなかで引用される可能性を、引き換えに手放すことでもあります。遮断するかどうかより長く持ちこたえる構えは、自分の手にない単一のチャンネルへの依存をやめることです——読者とのつながりが取り消されない場所で発信し、クローラー方針は戦略ではなく一手として扱いましょう。

「主権あるウェブ」とは、現実にはどういうものですか？
#

企業の許可に頼らずに読み、発信するやり方の総体です——フィードにはRSS、アクセスには Tor と onion サービス、答えにはローカルで動かすオープンウェイトのモデル、発信には自前運営と開かれたソーシャルプロトコル（Nostr、Fediverse）。現実には、いまはまだ少数派です。Fediverse は月間アクティブで100万〜200万人ほどの規模、自前運営は時間と技術を要し、IPFS は検閲耐性と引き換えに遅延を背負います。今年のうちに主流の検索やソーシャルに取って代わりはしません。その値打ちは、しなやかな並行インフラ——立つための足場——としてのものであって、仕上がった代替としてではありません。

回答ボックスのウェブから抜け出すには、技術的な知識が必要ですか？
#

始めるだけなら、必要ありません。最も手間が少なく、見返りが大きい一手は、読み方を取り戻すことです——RSSリーダーを入れて出どころを直接フォローすれば、アルゴリズムと回答ボックスが「何があなたに届くか」を決めることをやめさせられます。Tor Browser は、仲介なしのアクセスのための、ワンクリックのダウンロードです。より技術的な一歩——ローカルでモデルを動かす、自前運営する、onion ミラーを用意する——は、前提条件ではなく、時間をかけて登っていける梯子です。原則そのものにコードは要りません——「行儀よくします」と約束するだけのサービスより、「開かれていること」が設計の性質として備わった道具とプロトコルを選ぶ。それだけです。

#	出典	URL	Archive
1	Pew Research — AI要約が現れるとクリックが落ちる（2025年）	https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/	https://web.archive.org/web/2025/https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/
2	Reuters Institute — Journalism Trends 2026（Chartbeat の約3分の1の紹介流入減）	https://reutersinstitute.politics.ox.ac.uk/journalism-media-and-technology-trends-and-predictions-2026	https://web.archive.org/web/2026/https://reutersinstitute.politics.ox.ac.uk/journalism-media-and-technology-trends-and-predictions-2026
3	Search Engine Roundtable — Similarweb ゼロクリック 56%→69%	https://www.seroundtable.com/similarweb-google-zero-click-search-growth-39706.html	https://web.archive.org/web/2025/https://www.seroundtable.com/similarweb-google-zero-click-search-growth-39706.html
4	Cloudflare — AI学習のためのコンテンツ利用を制御する（2025年7月）	https://blog.cloudflare.com/control-content-use-for-ai-training/	https://web.archive.org/web/2025/https://blog.cloudflare.com/control-content-use-for-ai-training/
5	Cloudflare — Pay Per Crawl changelog（2025-07-01）	https://developers.cloudflare.com/changelog/2025-07-01-pay-per-crawl/	https://web.archive.org/web/2025/https://developers.cloudflare.com/changelog/2025-07-01-pay-per-crawl/
6	The Decoder — Reddit–Google のAI学習データ契約（年間約6,000万ドル）	https://the-decoder.com/reddit-signs-60-million-annual-training-data-deal-with-google/	https://web.archive.org/web/2024/https://the-decoder.com/reddit-signs-60-million-annual-training-data-deal-with-google/
7	Variety — News Corp–OpenAI のライセンス契約	https://variety.com/2024/digital/news/news-corp-openai-licensing-deal-1236013734/	https://web.archive.org/web/2024/https://variety.com/2024/digital/news/news-corp-openai-licensing-deal-1236013734/
8	Gizmodo — 新しいサイトの17.6%がまるごとAI生成（Stanford/Imperial/Internet Archive）	https://gizmodo.com/dead-internet-theory-is-17-of-the-way-to-becoming-reality-study-finds-2000751718	https://web.archive.org/web/2025/https://gizmodo.com/dead-internet-theory-is-17-of-the-way-to-becoming-reality-study-finds-2000751718
9	Merriam-Webster — Word of the Year 2025（「slop」）	https://www.merriam-webster.com/wordplay/word-of-the-year	https://web.archive.org/web/20251201000000*/https://www.merriam-webster.com/wordplay/word-of-the-year
10	National Law Review — 裁判所が2,000万件のChatGPTログを命令（2026年1月）	https://natlawreview.com/article/openai-loses-privacy-gambit-20-million-chatgpt-logs-likely-headed-copyright	https://web.archive.org/web/2026/https://natlawreview.com/article/openai-loses-privacy-gambit-20-million-chatgpt-logs-likely-headed-copyright
11	Press Gazette — 英国CMAによる発行者のAI要約オプトアウト（2026年1月）	https://pressgazette.co.uk/platforms/google-regulation-uk/	https://web.archive.org/web/2026/https://pressgazette.co.uk/platforms/google-regulation-uk/
12	GNU Project — Richard Stallman, The Right to Read（1997年）	https://www.gnu.org/philosophy/right-to-read.en.html	https://web.archive.org/web/2025/https://www.gnu.org/philosophy/right-to-read.en.html
13	stallman.org — ChatGPTを使わない理由	https://stallman.org/chatgpt.html	https://web.archive.org/web/2025/https://stallman.org/chatgpt.html
14	Tor Project — 公式サイト／onion サービス	https://www.torproject.org/	https://web.archive.org/web/2025/https://www.torproject.org/

KYC なしで Bitcoin を買う 2026 — P2P 市場 5 つを正直に比較

Tue, 23 Jun 2026 00:00:00 +0000

Bitcoin を買うとは、たいてい、規制された取引所に顔写真付きの身分証を差し出すことを意味します。そしてその取引所は、あなたの名前と、引き出したコインのすべてを結びつけた記録を、永久に残します。ピアツーピア(個人間)の市場はその代わりになります。あなたは別の誰かと直接取引し、書類を提出することもなく、鍵を持つのはあなた自身です。需要は確かにあります——「buy bitcoin no KYC」で上位に出る結果の一つは、*「本当に KYC なしで BTC を買えるのはどこ?」*と題したフォーラムのスレッドで、この「本当に」という一語が、多くを物語っています。

その苛立ちには理由があり、しかもその理由は、脅威の大きさを居心地悪く言い当ててもいます。「KYC なしのおすすめ」一覧がいまだに挙げている市場のうち三つ——LocalBitcoins、Paxful、LocalMonero——は 2023 年から 2025 年のあいだに閉鎖し、生き残った一つは 2026 年 5 月に攻撃で 11.59 BTC を失いました。古い一覧から選ぶと、死んだブランドの偽サイトに送金してしまうかもしれませんし、取引中に自分のコインが実際どこに置かれているのかを、大きく読み違えるかもしれません。

では、生き残った市場のうち、あなたに合うのはどれでしょうか。正直に答えれば、決め手は三つの要素です——どれも、星評価ひとつに丸められて見えなくなってしまうものです。escrow(預託)の仕組み(取引の最中にあなたのコインがどこに置かれるか)、紛争がどう解決されるか、そして「KYC なし」が各サービスで実際に何を意味するか。私は仮名で買い、仮名で保有しています。ですから KYC の紙の痕跡は、永続的で取り返しのつかない負債として扱います——そしてこのガイドのために、各市場の escrow 設計と紛争ルールを、それぞれの公式ドキュメントとソースコードに照らして整理し、そのうえでどのサービスが今も存在するかを確認し直しました。以下では、HodlHodl、Bisq、RoboSats、Peach、Vexl の一つずつについて、その中身を解きほぐしていきます。

一覧の主張	2026 年の現実
「LocalBitcoins か Paxful を使え」	どちらも閉鎖済み(2023 年、2025 年)——検索すると今も偽サイトへ送られかねない
「ノンカストディアルだからコインは安全」	escrow には 4 つの異なる仕組みがあり、それぞれ別の壊れ方をする
「KYC なし=身分証は一生不要」	身分証は今も求められうる——紛争のとき、または支出の上限を超えたとき
「Bisq は実戦で鍛えられている」	Bisq v1 は 2026 年 5 月に攻撃で 11.59 BTC を失った(返金済み、v2 は別物)

2026 年に「KYC なし」が実際に意味すること(そして意味しないこと)
#

KYC なしの取引とは、政府発行の身分証を提出せずにアカウントを開き、取引できるということです——ですが、身分証が決して求められないという約束ではありません。きっかけは市場によって違います。紛争のときだけ身分証を求めうる市場もあれば、ある支出額を超えると本人確認が始まる市場もあり、まったく求めない市場も二つあります。「KYC なし」を一つのオン・オフだと捉えるのが最初の間違いです。例外こそが、まさにプライバシーの崩れる一点だからです。

この区別が効いてくるのは、KYC なしで買う狙いが、身元とコインを結ぶ永続的な記録を避けることにあるからです。紛争のときに身分証を求めてくるサービスでは、何かがこじれたその瞬間——つまりあなたが最も引き下がれないときに——まさにその記録ができてしまいます。誠実な比較とは、緑のチェックマークを並べた行ではなく、そうしたきっかけを並べた表です。

市場	取引時の KYC	身分証が求められうる条件
HodlHodl	不要(メール+パスワード)	紛争時、または詐欺・AML(マネーロンダリング対策)の疑い時。拒むとアカウント停止もありうる
Bisq 2(Easy)	不要(中央アカウントなし)	プラットフォームからは一切求められない。紛争では相手に支払い情報が見えることはある
RoboSats	不要(Tor、ランダムなロボット ID)	プラットフォームからは一切求められない
Peach	低い日次上限まで不要	KYC なし上限を超えるとき、または高額取引のため自分から登録するとき(スイスの規制)
Vexl	不要(自分の連絡先を土台にする)	一切求められない——ただし escrow による保護もない

プライバシーを重んじるなら、もう一つ天秤にかけるべき細部があります。Peach は規制下のスイス企業として運営されているため、スイスのマネーロンダリング対策法を満たすべく、アカウント削除後も一定の紛争・端末・支払いデータを 10 年間保持すると明言しています。「KYC なし」と「記録なし」は、同じ約束ではありません。

コインが実際に置かれる場所 — カストディの問い
#

どの P2P 市場も「ノンカストディアル」という言葉を看板に掲げます。けれどもこの一語のなかには、まったく異なる 4 つの escrow 設計が同居しています。どこで問題が起こりうるかを決めるのは、宣伝文句ではなく設計のほうです。本当に大事な問いは、取引が成立するまでの数分から数時間、誰があなたのコインを動かせるのか、です。私は escrow の仕組みを、ブランドより先の最初の問いとして扱います。取引がおかしくなった後では直せない、唯一のものだからです。

これらの市場で使われている仕組みは 4 つあり、「単独では動けない仲介者」から「escrow がまったくない」まで、段階をなして並びます。multisig(複数署名)escrow は、動かすのに複数の署名が要るアドレスにコインを預けます。Lightning の hold-invoice(保留請求)は、確認されて初めて決済される支払いを保留状態にします。reputation(評判)型は中央 escrow を置かず、社会的な信用を担保にします。そして紹介サービスは、何も預かりません。

市場	escrow の仕組み	取引中に資金を動かせるのは誰か	失敗したとき
HodlHodl	2-of-3 multisig	{あなた、相手、HodlHodl} のうち任意の 2 者	HodlHodl が仲裁するが、単独では資金を取れない
Peach	2-of-2 multisig	あなたと相手の両方	どちらも単独では動かせない——紛争には双方の協力が要る(膠着のリスク)
RoboSats	Lightning hold-invoice	コーディネーターが保留し、確認時に解放する	資金が晒されるのは決済が確定するまでの間だけ(既定で約 3 時間)
Bisq 2(Easy)	評判/保証金	始終あなたが自分の鍵を持つ	信用は評判で重みづけされる。少額向けの設計
Vexl	なし——紹介のみ	つねにあなた	escrow なし。直接決済し、守るのは社会的信用だけ

ここで言えるのは、「ノンカストディアル」は必要だが十分ではない情報だ、ということです。2-of-3 multisig なら、膠着は破れるが盗みはできない仲介者がつきます。2-of-2 は第三者を完全に除けますが、その代わり、相手が消えたり協力しなかったりすると取引が凍りつきます。hold-invoice は、コインが晒される時間を短く抑えます。そして Vexl のような純粋な紹介アプリでは、相手がただ支払わなかったとき、何の救済もありません。どれかが漠然と「最も安全」ということはなく、どれもが、ある risk を別の risk と引き換えにしているだけです。

KYC なしの市場 5 つを比較
#

2026 年に今なお使う価値のある 5 つの市場は、本当に異なる持ち場を占めています——Lightning ネイティブのプライバシー、規制下のモバイルの手軽さ、デスクトップのセルフカストディ、強固な multisig escrow、そして純粋な社会的紹介——ですから正しい選択は、一つの順位ではなく、あなたの信用モデルで決まります。以下が一対一の比較で、続けて各サービスの正直な一行版を添えます。

市場	カストディ	KYC なし上限	規制の立ち位置	経路	2026 年も稼働?
HodlHodl	2-of-3 multisig	なし(ただし紛争で身分証)	英国企業(Hodlex Ltd)	オンチェーン+Lightning	あり——2016 年から稼働
Bisq 2(Easy)	評判/保証金	なし	ライセンス取得せず	オンチェーン(+Lightning)	あり——デスクトップ、新たに Android アプリも
RoboSats	LN hold-invoice	なし	中央実体なし(フェデレーション)	Lightning ネイティブ	あり——活発に開発、複数コーディネーター
Peach	2-of-2 multisig	低い日次上限	スイス企業、FINMA(スイス金融市場監督機構)の規制下	モバイル中心、100 以上の法定通貨手段	あり
Vexl	なし(ソーシャルグラフ)	なし	チェコ(SatoshiLabs グループ)	自分で直接段取り	あり——数万人のユーザー

HodlHodl はベテランです。2-of-3 multisig escrow と人による仲裁チームを備えたウェブのプラットフォームで、2016 年から稼働し、この中で最も厚い流動性を持ちます。引き換えとなるのは、紛争で身分証を求めうること、そして米国居住者を遮断していることです。
Bisq 2(Bisq Easy) はデスクトップ中心で、セルフカストディ型、既定で Tor(匿名化ネットワーク)を経由します。Bisq Easy は評判に基づくプロトコルで、少額の購入のためにあえて作られており、中央 escrow はありません——手軽さとプライバシーと引き換えに、大口取引の場ではない、という選択です。
RoboSats は Lightning ネイティブのプライバシー重視の選択肢です。Tor 専用、使い捨てのロボット ID、そして hold-invoice escrow。2026 年にはフェデレーション——一つのクライアントの下に独立した複数のコーディネーターが並ぶ形——として動いています。この形は強靭ですが、その代わり、コーディネーターを自分で選び、その評判ごと引き受けることになります。
Peach はモバイルの、規制下の選択肢です。2-of-2 multisig を備えたスイス企業で、100 以上の法定通貨の支払い手段を持ち、スイス法のもとで KYC なし上限は 1 日あたり約 CHF 1,000(現金など匿名の手段では月 CHF 1,000、年 CHF 100,000)です。少額の定期的な購入に最適で、摩擦は最も小さく、規制上の重荷は最も大きい(先に触れた 10 年のデータ保持を含みます)。
Vexl は異色です。SatoshiLabs グループによる escrow なしのアプリで、あなたの連絡先から、その先につながる人々を引き合わせます。何も預からず、何も追跡しません——つまり、escrow による保護もないということです。相手をすでに信用している取引のためのものです。

取引がおかしくなったとき — 紛争解決を比較
#

まともな市場と危うい市場を分けるのは、うまくいったときの取引ではありません——紛争のときであり、ここで escrow の仕組みははっきりと分かれます。そのうちの一つは、ほとんどのレビューが触れない膠着のリスクを抱えており、二つは処理にかかる期間をまったく公表していません。見知らぬ相手に法定通貨を送る前に、誰が裁定し、自分のコインがどれだけの間凍りつきうるのかを、正確に知っておくべきです。

市場	裁定するのは誰か	公表された期間	知っておくべきリスク
HodlHodl	HodlHodl の仲裁チーム	最大 60 日、初回応答は約 12 時間	紛争の証拠として身分証を求められうる
Peach	双方が必要(2-of-2)	非公表	一方が消えると膠着。データは 10 年保持
RoboSats	自分が選んだコーディネーター	非公表——コーディネーター次第	コーディネーターの評判は自分で見極める必要がある
Bisq 2(Easy)	評判に基づく仲裁	非公表	支払い情報が明かされうる。少額向けの設計
Vexl	裁定なし	—	救済なし——社会的信用だけが守りになる

HodlHodl は 5 つのうちで唯一、具体的な紛争ポリシーを公表しています——仲裁チーム、60 日の上限、そして約 12 時間の初回応答。これは意味のある利点です。たとえその同じ手続きこそが、身分証を求められうる場であってもです。RoboSats のフェデレーションは、どれか一つのコーディネーターが止められても強靭ですが、その代わり、現実の負担はこちらに回ってきます——紛争処理の質は、自分で選んだコーディネーター次第で、ネットワーク全体で保証された水準があるわけではありません。そして Peach の 2-of-2 設計は、仲介者を除くという点では洗練されていますが、その分、紛争の解決には相手の協力が要ります——相手が消えてしまえば、コインは宙づりになりかねません。

2026 年に変わったこと — そして消えていった市場
#

KYC なしのガイドは、その新しさの分だけしか安全ではありません。Bitcoin のこの一角は、移り変わりが速いからです。2026 年の状況を塗り替えた事実が、二つあります。長く信頼されてきたプラットフォームで起きた深刻なセキュリティ事案と、古い一覧が——そして AI の回答さえも——いまだに勧めている三つのサービスが、静かに消えたことです。「KYC なしのおすすめ」でいまだ上位に来る名前を確認し直してみると、一覧と現実のずれは、お金を失うには十分なほど大きいものでした。

まずは事案から、はっきりと述べます。Bisq を天秤にかける人にとって、これは重要だからです。

2026 年 5 月 1 日、攻撃者が Bisq v1 の取引プロトコルの検証バグを突き、少数のユーザーから 11.59 BTC を盗みました。プロジェクトは被害者に返金し、プロトコルを堅牢化しました——v1.10.0(2026 年 5 月 16 日)においてです。Bisq 2(Bisq Easy)は別の実装であり、影響を受けていません——ただし、その独自のセキュリティ堅牢化が完了する予定は 2026 年 8 月頃です。ですから「Bisq 2 は堅牢化済み」は、事実ではなく、まだこれから、です。

教訓は「Bisq を避けよ」ではありません——チームはバグを開示し、ユーザーに返金し、修正を届けました。これは、多くのプラットフォームにはやり切れないことです。教訓はこうです。最新のクライアントを動かすこと、Bisq Easy は設計どおり少額にとどめること、そして別のコードベースが、まだ達してもいない成熟をそのまま受け継いでいる、と思い込まないことです。

それから、亡霊たちがいます。古いガイドや、一部の今の AI 要約は、もはや存在しない市場へ人を送り続けています。

LocalBitcoins は 2023 年 2 月 17 日に閉鎖しました。LocalMonero は 2024 年に停止しました。Paxful は 2025 年 11 月 1 日に運営を終了しました。これらの名前を検索すると、死んだブランドの信頼に便乗するフィッシングの偽サイトが浮かび上がることがあります。何かを送る前に、生きている公式のサービスにいることを確かめてください——閉じられた、あるいはなりすまされたプラットフォームは、この分野で資金を失う最も簡単な道の一つです。

もう一つ、比較の表ではなく「まず確認」の欄に入る名前があります。LocalMonero の後継である AgoraDesk は、2024 年に閉鎖を告知し、現在の状況ははっきりしません。しかも Bitcoin より Monero を主軸としています——ですから、稼働を確認できないサービスを勧めるより、上の表からは外しました。その同じ規律——稼働を確認していないサービスには決して送らない——こそが、このガイド全体で最も安上がりな安全の習慣です。

これらすべてが移り変わるのには、もっと深い理由があります。Bitcoin のオンチェーン追跡が 2026 年にどう動くかで記録した法的な圧力は、コーディネーターと資金移送業者に降りかかりました。そしてその圧力を生き延びるよう作られた市場こそが、コーディネーターを置かない設計や、セルフカストディ型の市場なのです。KYC なしで買うことは、プライバシーを保つうえでの半分にすぎません——たとえ KYC を避けても、手に入れたコインを再利用済みのアドレスに送った途端に身元が結び直されたり、その取引のことを、モデルに読まれるフォーラムの投稿で語ってしまったりすれば、プライバシーは消えます。オンチェーン側の半分はその同じガイドにあり、チェーンの外で推測によって暴かれるもう半分は AI 規模の匿名性剥がしが、守れたつもりのプライバシーをどうほどくかにあります。

結論 — あなたに合うのはどれか
#

唯一の「最良」の KYC なし市場はありません。あるのは、あなたの信用モデルに合う一つだけです——Lightning のプライバシーをどれだけ重んじるか、取引の規模はどれくらいか、escrow の保護がどれだけ要るか、そして相手をすでに信用しているか。まずそれを定めてください。人がプライバシーか資金のどちらかを失うのは、まさにこの組み合わせを誤ったときだからです。市場は順位にではなく、あなたの状況に合わせましょう。

摩擦を最小に、少額を定期的に買いたいなら: Peach(モバイル、100 以上の法定通貨経路、KYC なしの日次上限)か、Bisq Easy(評判型、少額向けの設計)。どちらも、手軽さと引き換えに控えめな上限を受け入れます。
プライバシーを最大に、Lightning ネイティブで: RoboSats——Tor 専用、使い捨ての ID、escrow に晒される時間も短い。コーディネーターを自分で選んで信用する必要があり、紛争処理の期間も公表されていないことを受け入れます。
大口の取引と、最も強い escrow: HodlHodl——2-of-3 multisig と、実体のある仲裁手続き。紛争で身分証を求められうること、そして米国居住者は遮断されることを受け入れます。
相手をすでに信用しているなら(友人、ミートアップ): Vexl——ただし、escrow がないことを承知のうえで臨んでください。守るのはソーシャルグラフだけです。

どれを選ぶにしても、順序は同じです。サービスが生きていることを確かめる。星評価ではなく、escrow と紛争の仕組みで判断する。最初の取引は小さくとどめる。そして——KYC なしで手に入れたコインを保有したら——それをオンチェーンでも守り、せっかく購入の時点で守ったものを、台帳の上で台無しにしないようにする。この最後の一歩を支える枠組みは、本記事と対になっています——AI 時代の脅威モデルの観点で考え、そのうえで、あなたにとって本当に大事な結びつきを、一つずつ守ってください。

要点

古い一覧は危険: LocalBitcoins(2023 年)、Paxful(2025 年)、LocalMonero(2024 年)はもうありません——検索すると死んだブランドの偽サイトが今も浮かび上がりかねず、それは現実に資金を失う道です。
「ノンカストディアル」は 4 つの escrow を覆い隠す: 2-of-3 multisig(HodlHodl)、2-of-2(Peach)、Lightning の hold-invoice(RoboSats)、そしてまったくなし(Vexl)——何がおかしくなりうるかは、仕組みが決めます。
「KYC なし」は絶対ではない: HodlHodl は紛争で身分証を求めうるし、Peach は低い日次上限までしか KYC なしでなく、しかもスイス法のもとで紛争データを 10 年保持します。
Bisq の 2026 年の事案は本物だが、対処された: Bisq v1 は 2026 年 5 月にプロトコルのバグで 11.59 BTC を失いました(ユーザーに返金、v1.10.0 で修正)。Bisq 2 は別のコードベースで、独自の堅牢化が 2026 年 8 月頃に予定されています。
市場をあなたの信用モデルに合わせる: Lightning のプライバシーなら RoboSats、少額なら Peach か Bisq Easy、より強い escrow なら HodlHodl、相手をすでに信用しているときだけ Vexl。

よくある質問
#

KYC なしで Bitcoin を買うのは合法ですか？
#

これは法的助言ではなく、答えはあなたの法域と行いによって変わります。ほとんどの場所で、ピアツーピアで Bitcoin を買うことは適法であり、2024〜2025 年の米国の訴追が標的にしたのは、ミキシングや資金移送サービスの運営者であって、取引のプライバシーを求めた個人ではありません。ですが、税の申告のような義務は、コインをどう手に入れたかに関わらず、あなたに残ります——自分の状況については、資格のある専門家に相談してください。

2026 年 5 月のハッキング後も、Bisq はまだ安全に使えますか？
#

あの攻撃が影響したのは Bisq v1 です。取引プロトコルの検証バグを突かれ、攻撃者が少数のユーザーから 11.59 BTC を盗みました。プロジェクトは被害者に返金し、v1.10.0 でプロトコルを堅牢化しました。Bisq 2(Bisq Easy)は別の実装で影響を受けていませんが、その独自のセキュリティ作業は 2026 年 8 月頃に完了予定です。Bisq を使うなら、最新のクライアントを動かし、Bisq Easy の取引はプロトコルの設計どおり少額に保ってください。

P2P 取引で最も安全な escrow の仕組みは何ですか？
#

最も避けたい risk によります。2-of-3 multisig(HodlHodl)は、膠着を破れるが単独では資金を取れない仲介者を加えます。2-of-2 multisig(Peach)は第三者を完全に除きますが、相手が消えると膠着しかねません。Lightning の hold-invoice(RoboSats)は、晒される時間を決済が確定するまでの短い間に抑えます。escrow がまったくない(Vexl)場合は、社会的信用だけが守りになります。

少額に最適な KYC なしの市場はどれですか？
#

Peach と Bisq Easy は、どちらも少額の定期的な購入のために作られています。Peach はモバイル中心で、KYC なしの日次上限と多くの法定通貨手段を備えます。Bisq Easy は評判型のデスクトップのプロトコルで、中央 escrow はありません。少額を Lightning 建てでプライベートに扱うなら、RoboSats が最も強いプライバシーの選択肢です。

LocalBitcoins と Paxful が閉鎖した今でも、これらはまだ使えますか？
#

使えます。HodlHodl、Bisq、RoboSats、Peach、Vexl は、すべて 2026 年に稼働しています。注意すべきはむしろ逆です——LocalBitcoins(2023 年)、Paxful(2025 年)、LocalMonero(2024 年)は閉鎖したので、生きている公式のサービスにいることを確かめてください。死んだブランドの名に便乗する偽サイトは、人が資金を失うよくある道です。

#	出典	URL	アーカイブ
1	Bisq — “Where Bisq Stands After the Security Incident”(2026 年 5 月)	https://bisq.network/blog/where-bisq-stands-after-security-incident/	https://web.archive.org/web/*/https://bisq.network/blog/where-bisq-stands-after-security-incident/
2	LocalBitcoins — サービス閉鎖の告知(2023 年 2 月)	https://localbitcoins.com/service_closure/	https://web.archive.org/web/*/https://localbitcoins.com/service_closure/
3	Paxful — 閉鎖の告知(2025 年 11 月)	https://paxful.com/blog/paxful-closure-announcement	https://web.archive.org/web/*/https://paxful.com/blog/paxful-closure-announcement
4	RoboSats — escrow ドキュメント(Lightning hold-invoice)	https://learn.robosats.org/docs/escrow/	https://web.archive.org/web/*/https://learn.robosats.org/docs/escrow/
5	RoboSats — フェデレーションの仕組み	https://github.com/RoboSats/robosats/blob/main/federation.md	https://web.archive.org/web/*/https://github.com/RoboSats/robosats/blob/main/federation.md
6	Peach Bitcoin — KYC なしで BTC を買う方法	https://peachbitcoin.com/how-to-buy-btc-no-kyc/	https://web.archive.org/web/*/https://peachbitcoin.com/how-to-buy-btc-no-kyc/
7	HodlHodl — 紛争ルール	https://hodlhodl.com/pages/dispute_rules	https://web.archive.org/web/*/https://hodlhodl.com/pages/dispute_rules
8	Bisq — Bisq 2 / Bisq Easy(wiki)	https://bisq.wiki/Bisq_2	https://web.archive.org/web/*/https://bisq.wiki/Bisq_2
9	LocalMonero / AgoraDesk — 閉鎖の報道(2024 年)	https://www.tftc.io/agoradesk-shuts-down-after-seven-years/	https://web.archive.org/web/*/https://www.tftc.io/agoradesk-shuts-down-after-seven-years/

国家があなたのデータを漏らす日——2026年の防御戦略

Fri, 12 Jun 2026 00:00:00 +0000

資金について：CypherpunkGuide は監視型広告を一切載せない——広告ネットワークも、トラッキングピクセルも、スポンサー記事もない。運営は透明な収益源による：現在は読者からの寄付、将来は購読と編集方針に合致したアフィリエイト。私たちは広告主ではなく、読者に向き合う。

SNS のアカウントは削除できる。だが、税務当局からも、医療制度からも、国民 ID のデータベースからも、自分を消すことはできない。国家に手渡すデータは、考え直せる選択肢ではない——市民として存在することの代償だ。この非対称こそが問題のすべてである。企業があなたのデータを失ったなら、少なくとも建前の上では、そこを去ることができる。だが国家が失っても、あなたはなお、より多くを手渡し続けるよう求められる。

そして2026年、国家はそれを大規模に失っている。この春のわずか数週間のあいだに、CISA（米国のサイバー防衛を担う政府機関）の請負業者が、政府クラウドの管理者鍵を半年ものあいだ公開リポジトリに放置していた。連邦の医療機関が、医師の社会保障番号をオンライン名簿に公開した。そして英国の国民保健サービス（NHS）は、民間の分析企業の社員が個人を特定できる患者記録に到達しうると認めた。どれも高度な国家ぐるみの攻撃ではない。ありふれた組織の失敗だ——それを生む構造がけっして変わらないために、繰り返される類いの失敗である。

では、流出を防げず、データの提供を拒むこともできないなら、実際に何ができるのか。これは「より良い組織を信じる」ための手引きではない。私はこれを、明快な脅威モデル——何を、誰から守り、漏れたら何が起きるかを率直に描いたもの——と、ひとつの前提の上に組み立てた手順書として書いた。その前提とは、あなたのデータを抱えるデータベースは、いずれすべて漏れる。だから防御は、組織の約束ではなく、あなた自身が握る層に置かねばならない、というものだ。

2026年の3つの失敗
#

まず証拠から始めよう。パターンは、それが繰り返されると見えてはじめて行動に移せるからだ。2つの国家と、官民の境界にまたがる、文書化された2026年の3つの事案が、同じ構造的な弱さを3つの角度から映し出す。ここでいう*侵害（breach）*とは、本来アクセスすべきでない者が機微なデータに到達できてしまった状態を指す——過失であれ、露出であれ、過度に広いアクセス権であれ。

事案	何が露出したか	根本原因	状況
CISA 請負業者の GitHub 流出	政府クラウド3アカウントの管理者鍵＋平文パスワード（844 MB）	請負業者が公開リポジトリ経由で業務ファイルを同期、秘密情報スキャンを無効化	リポジトリ削除済、機関による調査継続中
CMS Medicare 名簿	医療提供者の社会保障番号	公開データベースの誤った欄に SSN を入力	ポータルを停止
Palantir × NHS アクセス	ベンダー社員が到達できる個人特定可能な患者記録	ハッキングではなく契約上の管理者アクセス	契約継続中、アクセス継続

CISA の流出が最も明白な事例だ。 アメリカのネットワークを守る任を負うまさにその機関——サイバーセキュリティ・インフラセキュリティ庁——の請負業者が、GitHub（人気のコードホスティングサイト）に公開リポジトリを維持しており、そこには政府クラウド3アカウントの管理者認証情報、平文のパスワードファイル、署名証明書、アクセストークン——内部資料およそ844メガバイト——が置かれていた。KrebsOnSecurity によれば、その従業員は職場と自宅のマシン間でファイルを同期するためにリポジトリを使い、秘密情報のアップロードを阻む組み込みの保護機能を意図的に切っていた。露出はおよそ半年に及び、セキュリティ企業 GitGuardian が発見してようやく止まった。クラウドの鍵は、リポジトリが消えたあともおよそ48時間は有効だったと報じられている。

CMS の流出は、二度と取り替えられない唯一の識別子に対する、同じ不注意を示す。 メディケア・メディケイドサービスセンター（CMS、米国の高齢者・低所得者向け公的医療保険を運営する機関）は、Medicare 提供者の新しい公開名簿を公表した——そして、ワシントン・ポストが最初に表面化させたのを受けて The Hill が報じたように、少なくとも数十人——のちに100人超と報じられた——の提供者の社会保障番号が、番号を誤った欄に入力したために露出した。機関はポータルを停止した。社会保障番号は、アメリカ人にとって、身元を開く永久の合鍵にもっとも近いものだ。いったん公になれば、生涯にわたって危殆化したままである。

Palantir–NHS の事案は、種類からして異なり、その違いが重要だ。 これはハッキングではなかった。The Register が報じたように、NHS イングランドは、3億3000万ポンドの Federated Data Platform（NHS の中央患者データ基盤）を運営する民間請負業者 Palantir（米国の大手データ分析企業）の社員が、個人を特定できる患者情報への管理者アクセスを持ちうると認めた。攻撃者は不要だった——そのアクセスは、システムの仕組みそのものに書き込まれていた。市民社会団体 Medact はこの懸念を記録し、グレーター・マンチェスターは参加を拒み続ける唯一の地域当局として残った。教訓は「悪者が押し入った」ことではない。一国の医療記録を単一のベンダーに集中させること自体が露出なのだ——誰かがそれを悪用するより前に、すでに。

これらだけではない。1年さかのぼれば、同じ形がまた現れる。2024年末に始まり2025年初頭に発覚した事案で、複数の州の Medicaid・養育費・食料支援のシステムを運営する政府請負業者 Conduent が侵害され、2500万人を超えるアメリカ人の社会保障・健康データが露出した。システムは復旧したが、訴訟は続いており、流出した識別子は期限切れにならない。この春の複数の事案、前年の1件、2つの国、官と民——主役は替わり、失敗は替わらない。

なぜ国家は構造的に漏らすのか
#

居心地のよい説明は「運が悪かった」だ——不注意な従業員、入力ミス、悪いベンダー。役に立つ説明はこうだ。これらは事故ではなく、システムの組み立て方が生む産物である。4つの構造的な力が、政府データの流出をほぼ不可避にしている。そしてそれらに名前をつけることこそ、ひとつひとつの見出しを追いかけるのではなく、カテゴリそのものに対して防御することを可能にする。

構造的な力	仕組み	現れた場所
請負業者への依存	外部ベンダーへの引き渡しのたびに責任が拡散する	CISA の鍵を請負業者が保持、NHS データを Palantir が保持
シャドー IT	公認されないツールが秘密情報を保護策の外へ迂回させる	請負業者の公開 GitHub リポジトリ
集約	記録が中央に集まると、ひとつの誤りが数百万人を露出させる	NHS プラットフォーム、Conduent の2500万件
非対称な説明責任	組織は罰金を払い、あなたは永久のリスクを相続する	2026年の3事案すべて

請負業者への依存は、責任を拡散させる。 現代の国家は、自前の技術の大半を運営しない。外部に委託する。CISA の鍵は請負業者の手にあり、NHS の記録は Palantir の手にあり、2500万件は Conduent の手にあった。引き渡しのたびに、あなたには見えないセキュリティを持ち、あなたとは異なる動機を持つ組織がひとつ増える。機関は結果を所有し、請負業者はノートパソコンを所有する。

シャドー IT——人々が承認なしに使うツール——は、秘密情報を保護策の外へ迂回させる。 CISA の従業員の公開リポジトリはシャドー IT だった。機関が備えていると思い込んでいたあらゆる統制を回避する、公認されない便宜だ。手続きが遅すぎるとき、人は必ずその脇に速い道を作る——そして速い道に手すりがあることはまれである。

集約は、小さな誤りを破滅に変える。 記録が散らばっていれば、誤りは数人を露出させる。だが連邦化されたプラットフォームや全国名簿がそれらを集中させれば、同じ誤りが数百万人を露出させる。中央集中は効率として売られるが、同時に、破滅的な単一障害点でもある。

説明責任は非対称だ。 侵害が起きると、組織は声明を出し、おそらく罰金を払い、そして続いていく。あなたは永久のリスクを相続する。この不均衡こそ、漏れる前提を採る最も深い理由だ。あなたのデータを失う側は、それを失う代償を負わない——だから、止めるに足る理由をけっして持たない。

これらを合わせて出てくる結論は、シニシズムではない——設計の指針だ。4つの構造的な力を、外側から改革することはできない。だが、それらが失敗することを見込んだ個人のアーキテクチャを、あなたは築ける。

防御アーキテクチャ——100%漏れる前提
#

ここからが、どの「侵害対応チェックリスト」も与えてくれない部分だ。一度きりの解決策として売れないからである。それは、あなたのデータを抱えるあらゆる組織がいずれそれを失うと見込んだ、常設のアーキテクチャだ。心構えから具体策へと並ぶ5つの層と考えてほしい。5つを一度に完成させることはない。どんな防御もそうであるように、一度に一層ずつ、露出が最も大きいところを最も強くして築いていく。

層1——「漏れる前提」の心構えを採る。 脅威モデルとは、要するに「何を、誰から守り、漏れたら何が起きるか」への明快な答えだ。ここでの転換は、組織を「安全なもの」として捉えるのをやめ、いずれ逃げ出すデータの一時的な預かり手として捉えはじめることである。これは被害妄想ではない。2026年の記録が示す現実だ。データベースは漏れると想定してしまえば、その後のあらゆる判断——何を提出するか、どの身元の下で、どんな備えとともに——が楽になる。

層2——手渡すものを最小化する。 税務当局を拒むことはできないが、データの吸い上げの大半は法的に義務づけられてはいない。ポイントプログラム、任意のプロフィール欄、必要のないサービスでの「ID で本人確認を」という促し——どれも、後に漏れうる貯水池だ。任意の開示はすべて、あなたの名前が入った将来の侵害通知だと思って扱うこと。最も効果の高いプライバシー制御は、そもそも収集されなかったデータである。長年の SNS 利用からすでに何が逃げ出したか——そしてなぜ削除がそれを消し去ることはまれなのか——の実践的な棚卸しは、SNS の足跡がどこまで残るのかを参照してほしい。

層3——身元を分ける。 私は主要な文脈ごとに——金融、医療、公の活動——別々のメールアドレスを持っている。ひとつのデータベースが漏れても、他とは結びつけられないようにするためだ。オープンソースの Bitwarden のようなパスワードマネージャーは、サイトごとに固有の認証情報を持つことを現実的にする。Proton Mail のようなプロバイダーは、サービスごとのエイリアスに対応しており、漏れたら捨てられる。区画化は侵害を止めはしない。だが、ひとつの侵害がすべての侵害になるのを止める。（このより深い版——仮名と法域の分離——については、自己主権アイデンティティに関する Cora の仕事を参照。）

層4——変えられない識別子を固める。 あるデータは永久だ。社会保障番号、生年月日、生体情報。これらは更新できないから、使われる地点で守る。アメリカでは、米国の3大信用情報機関（借入履歴を保持する企業）= Equifax・Experian・TransUnion すべてで信用情報を凍結することで、あなたの名義で新規口座が開かれるのを阻止できる。無料で、いつでも解除できる。さらに不正利用警告（fraud alert）を加える。そして重要なログインを、ハードウェアベースの多要素認証（MFA＝本人確認を複数の要素で行う仕組み。ここでは物理的なセキュリティキー、最も強固な第二要素）に移す。盗まれた番号だけでは扉を開けられないようにするのだ。この層だけは、侵害対応チェックリストとこのアーキテクチャの主張が一致する——違いは、ここではそれが永続的な衛生習慣であって、慌てた反応ではない、という点だ。

層5——ツールと法域を分散させる。 同じ相手にまとめて届かないプロバイダーと法制度に、信頼を分け散らす。機微な会話には暗号化メッセージング、ネットワークとあなたの活動の結びつきを断つには Mullvad のようなログを取らない VPN（Virtual Private Network＝通信を暗号化し経路を隠す仕組み）、そしてひとつの企業やひとつの政府の下に集中していないストレージ。狙いは、単一の侵害も、召喚状も、ベンダーとの関係も、全体像を露出させないようにすることだ。

このアーキテクチャが要求しないものに注目してほしい。組織が信頼に足ることを要求しない。それこそが要点だ。どの層も、与えられる約束ではなく、あなたが握る制御である。

すでに露出しているなら
#

もしあなたのデータがこれらの侵害のどれかに含まれているなら——統計的には、すでに含まれている——とるべき即時の手当ては範囲が狭いが、上の常設アーキテクチャに取りかかる前に、今日やっておく価値がある。これらは、私が交渉の余地なしと扱う手順だ。治療のすべてではなく、トリアージ（応急の優先処置）として扱ってほしい。

信用情報を凍結する——3機関すべてで（無料、オンライン、解除可能）。これが、単独で最もてこの効く行動だ。
不正利用警告を設定する——金融口座に設定し、取引通知をオンにする。
永久の識別子は危殆化したままと想定する。 漏れた社会保障番号は期限切れにならない。変えられるものはすべて変え（パスワード、口座番号）、残りは使われる地点で守る。
ハードウェア MFA へ移す——まずメールと金融から。メールは、他のすべての復旧経路だからだ。
標的型のフィッシングを警戒する。 漏れたデータは詐欺を個人仕様にする。あなたの本当の詳細を知っている相手は、漏れたデータを使っているのであって、正当性の証明ではない。

これらの手順は、目の前の窓を閉じる。多層のアーキテクチャは、次の侵害——そして次は必ず来る——が、同じやり方で二度あなたに代償を払わせるのを防ぐものだ。

要点

漏れる前提： 国家にデータを渡すことから降りられない以上、あらゆる政府データベースを、いずれ漏れる一時的な預かり手として捉える。
パターンは構造的： 請負業者への依存、シャドー IT、集約、非対称な説明責任が、2026年の CISA・CMS・Palantir-NHS の失敗を予測可能にした——運の問題ではない。
自分が握る層で守る： 開示を最小化し、身元を分け（固有のメール＋パスワードマネージャー）、永久の識別子を固める（信用情報凍結＋ハードウェア MFA）。
頼れる法的救済はない： 主権免責と賠償上限が、侵害訴訟を遅く不確かなものにする——多層のアーキテクチャこそ、あなたが実際に握る救済だ。
今日はトリアージ、明日はアーキテクチャ： すでに露出しているなら、今すぐ信用情報を凍結しハードウェア MFA へ移る。その上で、常設の5層防御を築く。

よくある質問
#

データを漏らした政府を訴えられますか？
#

訴えられる場合もありますが、当てにできる救済であることはまれです。主権免責の規定、賠償額の上限、そして具体的な被害を立証する難しさが、政府の侵害訴訟を遅く不確かなものにします。法的措置は、防御ではなく、あるかもしれない後追いの一手として扱ってください——実際に露出を減らすのは、あなたの多層のアーキテクチャです。

信用情報の凍結だけで十分ですか？
#

いいえ、ただし単独では最善の行動です。信用情報凍結は新規口座の不正の大半を阻止しますが、医療身元の盗用、税の詐欺、信用情報申請以外での漏れた社会保障番号の悪用には何もしません。不正利用警告、ハードウェア MFA、身元の区画化と組み合わせてください。

データがすでに漏れているなら、防御は無意味では？
#

いいえ。侵害による被害の大半は、露出のあとに起きます——漏れたデータが、口座開設、なりすまし、標的型詐欺の作り込みに使われるときです。信用情報を凍結しログインを固めれば、元となるデータがすでに外に出ていても、悪用の段階を阻止できます。

これはアメリカだけの話ですか？
#

具体策は異なります——信用情報凍結はアメリカの仕組みで、NHS の事案は英国のものです——が、アーキテクチャは普遍的です。どの国も市民データを集約し、その扱いを外部委託しています。最小化、区画化、永久の識別子の保護は、あなたがどこに住んでいても当てはまります。

参考資料
#

#	出典	URL	アーカイブ
1	CISA 管理者が AWS GovCloud の鍵を GitHub に流出 — KrebsOnSecurity	https://krebsonsecurity.com/2026/05/cisa-admin-leaked-aws-govcloud-keys-on-github/	archived
2	CISA の GitHub 流出を26時間で削除させた経緯 — GitGuardian	https://blog.gitguardian.com/how-we-got-a-cisa-github-leak-taken-down-in-26-hours/	archived
3	CMS が社会保障データを公開 — The Hill	https://thehill.com/policy/healthcare/5860959-cms-publishes-social-security-data/	archived
4	Medicare ポータルが提供者の SSN を露出 — Washington Post	https://www.washingtonpost.com/health/2026/04/30/medicare-portal-social-security-numbers-exposed/	archived
5	NHS イングランドが Palantir 社員の患者データアクセスを認める — The Register	https://www.theregister.com/databases/2026/05/12/nhs-england-confirms-palantir-staff-can-access-patient-data/5238712	archived
6	ブリーフィング：Palantir と NHS のデータシステム — Medact	https://www.medact.org/2026/resources/briefings/briefing-palantir-fdp/	archived
7	消去権（第17条）— GDPR	https://gdpr-info.eu/art-17-gdpr/	archived

AI クローラーを、17日間見張った——名乗りは、誰でも羽織れる衣装だった（2026年）

Wed, 08 Jul 2026 00:00:00 +0000

あなたの書いたものを AI モデルに読ませない——そのための手引きは、どれも決まって同じ三つの手立てで終わる。クローラーの名前を robots.txt（ボットに「ここは来ないで」と丁寧に頼むファイル）に書き足す。llms.txt（同じ発想を AI 向けに焼き直した、より新しいファイル）を置く。あるいは、契約先のホストに「GPTBot を弾いてくれ」と頼む。三つとも、同じことを当てにしている——戸口を叩いているボットが、その user-agent の名乗りどおりの相手だ、という前提だ。user-agent とは、プログラムが自分を名乗るために送る、ただの一行の文字列にすぎない。打ち込むだけのもので、証明されたものではない——そして、何であれ、何とでも打ち込める。

だから私たちは、理屈をこねるのをやめて、実際に見ることにした。17日間——2026年6月19日から7月5日まで——このサイトに触れた、自ら名乗る AI クローラーを、一つ残らず記録した。14種類の商用 AI の user-agent にわたる、1,635件のリクエスト。ClaudeBot や GPTBot から、ほとんどのサイト運営者が目にすることのない名前まで。そして、助言がいつも飛ばす一手を踏んだ。リクエストごとの本当の発信元アドレスを、その名を掲げる会社自身が公表しているアドレス一覧と、突き合わせたのだ。結果は、きれいに三つのグループに分かれた。そして、良い知らせと呼べるのは、そのうち一つだけだった。これは、私たちが以前に交わした約束——このサイト自身のクローラーのログを見張り続けるという約束——の裏にある、実際の計測だ。そして、別の場所で論じた開かれたウェブの囲い込みを、足元で支える実証的な土台でもある。

居心地の悪い発見は、AI クローラーが嘘をつく、ということではない。いちばん止めたい相手に限って、こちらの道具がまるで届かない——という事実の方だ。なぜなら、opt-out（AI に「読み込まないでくれ」と申し入れる仕組み）という枠組みは、そもそもクローラーが従うだけの正直さと確かめられるだけの透明さの両方を備えているときにしか、働かないからだ。以下に記すのは、小さな一サイトの17日間のログが、どちらがどちらなのかについて明かしたことだ。

何を計り、あなたならどう再現するか
#

私たちは、連続する17日ぶんのエッジのログを集め、リクエストを user-agent の文字列ごとにまとめ、商用 AI システムの名を掲げる14種類を手元に残した。ここまでは、むき出しの自己申告にすぎない——ボットが「私は GPTBot です」と言った、というだけのことだ。検証は、それとは別の、もっと難しい問いであり、そして客観的な答えを持つ。そのリクエストの発信元 IP は、OpenAI、Anthropic、Google、Amazon が自社のクローラー用に公表しているアドレスの範囲の中に、収まっているか。主要な事業者はどこも、まさにこの一覧を公開している——サーバーが、本物のボットと偽者とを見分けられるように。

1,635件のヒットは、くっきりとした序列に整理された。user-agent ごとの完全な集計は、プレーンテキストの要約として、この記事に添えてある——合算した件数だけで、訪問者のデータは含まず、クローラーのネットワークは /24 の粒度までしか名指ししていない——/24 とは、連続する256個の IP アドレスのかたまりで、この種のネットワークが割り当てられる最小の単位だ（検証の要約）。

AI の user-agent	リクエスト数（17日間）	公表 IP と一致	検証の出典（時点）
ClaudeBot	553	546（99%）	Anthropic のボット一覧（2026-05）
Amazonbot	344	120（35%）	Amazon のクローラー IP（2026-04）
GPTBot	310	301（97%）	OpenAI GPTBot 一覧（2025-10）
meta-externalagent	179	公表された方法なし	—
Bytespider（ByteDance）	112	公表された方法なし	—
PerplexityBot	24	5（21%）	Perplexity のボット一覧（2025-02）
GoogleOther	12	12（100%）	Google のクローラー一覧（2026-06）

さらに7種類の、少量のエージェント——合わせて101件のリクエスト——が、残りを埋めて14種類になる。全リストは要約ファイルの中にある。

**検証済みのリクエストとは、その発信元 IP を、名を掲げる会社自身が請け合っているものだ。**この割合は、リクエストの件数で重みづけしてある。そして、あるボットの数が少ないときは、そうとはっきり断っておく——PerplexityBot の「21%」は、24件のうち5件のことであり、会社を裁くにはあまりに薄い。だから、以下でもそのように扱う。ここに並ぶどの数字にも、二つの但し書きがついて回る。一つ、これは17日間の、できたばかりでアクセスも少ない一サイトの話であって、ウェブ全体ではない。もう一つ、公表されたアドレス一覧は、その日付の分しか新しくない——Perplexity のものは17か月前のもので、この点にはあとで立ち戻る。

名乗るクローラーは、おおむね本物だ
#

まずは良い知らせから始めよう。それは本物で、しかも大切なことだからだ——大手ラボのクローラーが自ら名乗るとき、それはほとんどいつも、本当のことを言っている。**GPTBot は97%、ClaudeBot は99%、GoogleOther は100%**が、各社の公表するアドレス範囲と一致した。「GPTBot」「ClaudeBot」と名乗る通信の圧倒的多数は、正真正銘、OpenAI と Anthropic の設備から発していた。ただし、ここで特に AI の学習を拒みたい人には、一つ注意がいる。GoogleOther は汎用の Google クローラーであって、Gemini の学習を実際に司る Google-Extended とは、別ものだ——そして、私たちが記録した Google-Extended のヒットは、一件残らず、Google ではなく、後で見る詐称の一団から来ていた。

皮肉屋の見立てが取り違えているのは、まさにこの部分だ。もしあなたが GPTBot を robots.txt に書き加え、あるいはエッジで Anthropic のアドレス範囲を弾けば、本物の GPTBot と本物の ClaudeBot は、確かに止められる——両社はアドレスを公表しているし（OpenAI、Anthropic）、ファイルを尊重する。そして、独立した、ウェブ全体を見渡すデータもまた、名乗る大手のクローラーが主役だと裏づけている——たとえ各社の取り分が年ごとに移ろっても、だ（Cloudflare、2025年）。正直なクローラーは、すでに片のついた問題だ。もしすべての AI ボットが GoogleOther のように振る舞ってくれるなら——名を掲げ、範囲を示し、確かめられるのなら——この記事は、ただの脚注で済んでいただろう。

名乗るクローラーの中に、一つだけ、このきれいな仕分けにうまく収まらないものがあり、公正を期すなら名指ししておかねばならない。私たちの24件の PerplexityBot のヒットのうち、Perplexity の公表する範囲と一致したのは、わずか5件だった——だが、24件では、一社を裁くにはあまりに薄い。おまけに Perplexity の一覧そのものが17か月前のもので、一致しないことは、古びたファイルの表れ以上の何ものでもないかもしれない。背景には、現在進行形の論争がある。Cloudflare は2025年8月、Perplexity が忍びの、名乗らないクローラーを使ってクロール禁止の決まりをすり抜けている、と報告した（Cloudflare、2025年）。対して Perplexity は、その見立てを公然と退けた（Perplexity、2025年）。利用者に促され、求めに応じてその場でページを取りに行く「エージェント」は、先回りして巡回する「ボット」と同じではない——そして Cloudflare は、第三者のクラウドブラウザサービスの通信を、Perplexity 自身のものと取り違えたのだ——というのが、彼らの言い分だ。IP アドレスだけからは、外部の偽者と、その会社自身の名乗らない取得役とを、見分けることはできない——だから私たちは、24件をもって Perplexity について何かを結論することはせず、ただ、こちらの検証が最もうまく通らなかった、名乗るクローラーとして書き留めておく。

ずっと心に引っかかっていたのは、別の、もっと鋭い数字だ。検証を通ったクローラーの中に残った、ほんのわずかな端数のことである。ClaudeBot の、検証を通らなかった7件。GPTBot の9件。これらは、でたらめな雑音ではなかった。その一件残らずが、同じ一つの場所へとたどり着いた——どちらの名を名乗る筋合いもない場所だった。

一つのネットワークが、14 の顔を使い分けていた
#

この記事のタイトルは、ここで見つけたものから来ている。問題のアドレスのかたまり四つ——四つの /24——は、どの会社の公表範囲からも、すっかり外れていた。そして17日間、この四つのかたまりだけで、14社ぶんの AI 企業の user-agentを掲げた99件のリクエストが生み出された。うち一つの /24——185.213.174.0/24——は、たった一つで14社すべてになりすましていた。GPTBot、ClaudeBot、PerplexityBot、Amazonbot、Google-Extended、Bytespider、cohere-ai、そしてさらに七つ——すべてが、この一つの小さなネットワークから来ていた。

では、それを正当な範囲と並べてみよう。隣り合う二つの Anthropic のかたまり——216.73.216.0/24（281件）と、その隣の 216.73.217.0/24（265件）——は、二つ合わせて546件のリクエストを送ってきた。そして、その一件残らずが ClaudeBot を名乗っていた。どちらのかたまりを覗いても、一つの主体、一つの身元だ。それぞれのネットワークを誰が所有しているかを引いてみれば、この対比が話を決定づける。所有者は RDAP（IP が、どの組織に割り当てられたのかを引ける、公開の登録簿）からわかる。

ネットワーク（/24）	何を名乗ったか	登録者（RDAP）
`216.73.216.0/24`	ClaudeBot、281回——それ以外なし	Anthropic, PBC（米国）
`185.213.174.0/24`	14社ぶんの別々の AI 企業	NextGenWebs、ウェブホスト（オランダ）
`45.45.237.0/24`	詐称の一団の一部	Infraly, LLC（米国）
`23.161.169.0/24`	詐称の一団の一部	Infraly, LLC（米国）——同じ所有者
`154.58.229.0/24`	詐称の一団の一部	Limestone Networks（米国）

正当なかたまりは、Anthropic 自身の公表範囲の中に収まっている——そして、私たちが RDAP で引いた一つは、Anthropic, PBC として返ってくる。なりすましのサブネットは、商用のホスティング会社に登録されている——誰でも時間単位で借りられるインフラだ——しかも、四つのうち二つが、同じ借り物の会社にたどり着く。たった一人の運営者が、一つの衣装箱を回している、そのしるしだ。本物のクローラーが一つの身元しか持たないのは、それが一つの主体だからだ。詐称する者がいくつもの顔を使い分けられるのは、顔だけなら、いくらでも安く付け替えられるからだ。user-agent は身分証ではない。衣装だ。そして robots.txt は、扉に貼られた張り紙にすぎない——読んで従うかは相手しだいで、衣装をまとった者ほど、平気で素通りしていく。

Amazonbot——借り物のサーバーと見分けのつかないボット
#

Amazonbot は、検証が本当に難しくなる場所であり、しかも Amazon が隠れていないからこそ、教えるところが多い。この会社も、ほかと同じようにクローラーのアドレス一覧を公表している——にもかかわらず、私たちの344件の「Amazonbot」のヒットのうち、それと一致したのは、わずか35%（120件）だけだった。残りの65%——179の異なるアドレスから来た224件のリクエスト——は、Amazon の一覧には、まるで載っていなかった。

理由は、構造にある。Amazon の本物のクローラーは、誰でも借りられるのと同じクラウド——AWS EC2（Amazon が誰にでも貸し出すクラウドサーバー）——の上で動いている。だから EC2 に潜む偽者は、ネットワークの層で見るかぎり、本物とよく似て見える。これに対する Amazon 自身の答えが、二つ目の確認だ——reverse-DNS（逆引き）の検査、すなわち FCrDNS（その IP のホスト名が、crawl.amazonbot.amazon という公式ドメインへ、正引き・逆引きの両方向できちんと戻るかを確かめる仕組み）である。私たちは、一致しなかったアドレスのうち18件を標本にとって、これを走らせた。18件すべてが、ありふれた ec2-*.compute-1.amazonaws.com のホスト——ただの借り物のサーバー——へと解決し、Amazon のクローラー用ドメインへ戻ったものは、一つもなかった（Amazon の検証方法）。これらは、一覧に載っていない新しい Amazon の IP だったのではない。Amazon であるための、Amazon 自身の試験に落ちたのだ。

この教訓は、一つのボットの話にとどまらない。借り物のクラウドの上で動くクローラーは、最も偽造しやすい——偽造する側が、寸分たがわぬ同じクラウドを借りるからだ。そこでの検証は、アドレス一覧で止まっていてはいけない。運営者が握っている、暗号による、あるいは DNS に根を張った証明が要る。Amazon は、少なくとも一つは用意している。何一つ用意していないところも、ある。

そもそも確かめようのないクローラーたち
#

いちばん手強いグループは、嘘つきではない——どちらの向きにも検証しようのない、クローラーたちだ。meta-externalagent（Meta の AI クローラー）は179件、Bytespider（ByteDance のもの）は112件のリクエストを送ってきた。だが、どちらの会社についても、その一件すら突き合わせられる、公表された IP 範囲も、公式の reverse-DNS の方法も、見つけられなかった。Meta のアドレスの標本（9件）を逆引きしてみると、返ってきたのは NXDOMAIN——登録された名前が、そもそも一つもない、という応答だった。意図してか、放置の末か、突き合わせるべきものが、何もないのだ。ヘッダを信じろと求められ、そのための手立ては何一つ与えられない。

これこそ、問題全体の静かな核心であり、しかもこれはプライバシーの問題であって、ウェブ管理者のちょっとした不便ではない。あなたが売り込まれてきた opt-out——robots.txt、「ボットを弾け」、さらには新顔の llms.txt までも——が持つ力は、それが本当に効いたのかどうかを、あなたが見分けられる、その範囲を超えない。opt-out は、AI クローラーの世界を三つに分ける。そして、あなたの道具が届くのは、そのうち最初の一つだけなのだ。

グループ	誰が（私たちのログでは）	検証できるか	opt-out は効くか
公表し、正直	GPTBot、ClaudeBot、GoogleOther	できる——アドレス一覧＋逆引き	効く——弾けば、その通りに止まる
名乗るが、確かめられない	meta-externalagent、Bytespider	できない——方法が公表されていない	わからない——ヘッダを信じるほかない
偽者たち	詐称の一団（14の名、借り物のホスト）	できない——しかも、誰にでもなりすます	効かない——ファイルをまるごと無視する

そして、より新しい、AI 向けに作られた対処法もまた、私たち自身のログの上では、分がいいわけではなかった。私たちは llms.txt を置いている。だが17日間を通して、**AI クローラーは、私たちのページを数百回も取りに来た——GPTBot だけで310回——のに、llms.txt というファイルを取りに来た回数は、きっかりゼロだった。**30万ドメインを調べた研究も、大規模に同じ判定に達している——llms.txt があるかどうかと、AI クローラーの振る舞いとの間には、測れるほどの相関は見られなかった（SE Ranking、2025年）。読んでくれと差し出された規格を、ボットたちは、読んでいないのだ。

結論——本当にあなたを守るもの
#

もし目指すところが、公開したあなたの文章や写真や投稿を、AI システムの外に置いておくことなら、この17日間の一断面は、飾りけがなく、少しばかり気の滅入ることを告げている——**こうした制御がいちばんよく効くのは、放っておいても行儀よくしていたであろうクローラーに対してであって、あなたが最も恐れる相手には、まるで効かない。**とはいえ、これは robots.txt を外す理由にはならない——正直な多数派を止めることには、なお意味がある。あなたの言葉が大きなモデルに入るか入らないか、その分かれ目になるのだから。これは、扉に貼られた張り紙を錠前と取り違えるのを、やめる理由なのだ。

ここから、正直な結論が三つ導かれる。一つ目、手立ては使え。ただし、誰が従うかで順位をつけろ。robots.txt と、エッジで公表された範囲を弾くことは、GPTBot、ClaudeBot、Google を本当に止める——それが、名乗るクローラーの通信の大半だ。二つ目、ラベルを信じず、確かめろ。もしログを見て手を打つなら、user-agent の文字列ではなく、私たちがやったのとまったく同じように、発信元 IP を各事業者の公表一覧と逆引きに突き合わせること。三つ目——これが屋台骨だ——おおやけの場にそのまま出したものは、あなたには監査できないシステムに、もう読まれているものとして扱え。偽者の一団も、方法を持たないクローラーも、一枚のテキストファイルを律儀に守ってはくれない。長もちする唯一のプライバシーの制御は、そもそも何を公の記録に載せるのか、その最初の選択にある——取り消せない投稿について、そして機械が断片から何を推し量るかについて、私たちが地図化したのと、同じ「永続の理屈」だ。

Web Bot Auth と呼ばれる、生まれたばかりの規格は、この『衣装』の問題を根っこから正そうとしている——クローラーには偽造できない暗号署名によって、身元が、打ち込まれるのではなく、証明されるようにするのだ（Cloudflare、2025年）。まだ早い段階で、広くは普及しておらず、しかも助けになるのは、身元を明かしたいと願うクローラーに対してだけだ。14 の顔を使い分けていた連中は、信頼の規格が狙う相手では、そもそもなかった。

要点

**名乗る大手ラボのクローラーは、おおむね本物だ：**17日間で、GPTBot は97%、ClaudeBot は99%、GoogleOther は100%が、各社の公表する IP 範囲と一致した——だから、robots.txt でこれらを弾くのは、実際に効く。
**user-agent は、衣装だ：**どの公表範囲からも外れた、借り物のホスティングの四つのネットワークが、17日間で14社ぶんの AI 企業の名を着た。一つの /24 が14社すべてになりすます一方、隣り合う二つの Anthropic のかたまりは、二つ合わせて546件のリクエストを、たった一つの名前だけで送ってきた。
クラウドで動くクローラーは、最も偽装しやすい：「Amazonbot」のヒットのうち、Amazon の一覧と一致したのは35%だけ。残りは、ありふれた借り物の EC2 サーバーから来ていて、Amazon 自身の reverse-DNS の確認に落ちた（標本18件中18件）。
**そもそも、まったく検証できないクローラーもいる：**Meta と ByteDance のボットは、IP 一覧も reverse-DNS の方法も公表していない——Meta のアドレスは、登録された名前を返してこなかった——だから、これらを「拒否する」というのは、信じるという行為にすぎない。
**AI 向けの対処法は、読まれていない：**AI クローラーは、私たちのページを数百回取りに来たのに、llms.txt はゼロ回だった——測れるほどの効果は見られないとした、30万ドメインの研究とも符合する。

よくある質問
#

robots.txt で、AI クローラーを弾けますか？
#

半分は、はい。そしてそれは、ひとえにクローラーの正直さしだいです。私たちの17日間のログでは、名乗る大手のクローラー——GPTBot、ClaudeBot、GoogleOther——は97〜100%が本物だと確かめられ、robots.txt をきちんと尊重します。ですから、そこに書いておけば、止められます。ですが robots.txt は、あくまで任意のお願いであって、強制される決まりではありません。それを無視するクローラーや、偽の user-agent をまとったクローラーは、まっすぐ通り抜けていきます。このファイルは、行儀のよい相手を止め、正直な相手に知らせてくれるだけのものです。偽者にとっては、何の意味もありません。

あるクローラーが、本当に GPTBot や ClaudeBot なのか、どう確かめますか？
#

user-agent の文字列を信じず、発信元 IP を確かめてください。OpenAI、Anthropic、Google、Amazon は、それぞれ自社のクローラーが使うアドレス範囲を公表しています。ですから、本物の GPTBot のリクエストは、OpenAI が公表した一覧の中の IP から来ます。共有のクラウドに乗るクローラー（AWS 上の Amazonbot など）には、reverse-DNS の確認を足してください——その IP のホスト名が、事業者の公式なクローラー用ドメインへ、正引き・逆引きの両方向できちんと戻るかを確かめるのです（FCrDNS）。もし「GPTBot」のヒットが、OpenAI が一度も公表していないアドレスから来ているなら、それは GPTBot ではありません。

llms.txt を置けば、AI を自分のコンテンツから締め出せますか？
#

私たちの証拠に照らすかぎり、いいえ、です。私たちは llms.txt というファイルを置いていますが、17日間で、AI クローラーは実際のページを数百回も取りに来る一方、llms.txt を取りに来た回数はゼロでした——GPTBot は310ページを読み、そのファイルは一度も読みませんでした。30万ドメインを対象にした別の研究でも、llms.txt があることと、AI クローラーの振る舞いの変化との間に、測れるほどの相関は見つかりませんでした。これは提案段階の規格であり、それが語りかけるはずのクローラーたちは、いまのところ、その大半がまだ読んでいないのです。

なりすましの AI クローラーとは、何ですか？
#

実在する AI 企業の user-agent の名前を掲げていながら、その会社からは来ていない——そんなリクエストのことです。私たちのログでは、四つの商用ホスティングのネットワーク——誰でも借りられる類のもの——が、14社ぶんの別々の AI 企業を名乗る通信を送ってきました。その中には、たった一つで14社すべてになりすましたネットワークもありました。user-agent は、送り手が好きに選べる、ただの文字列です。だから、なりすましは造作もありません。その名前が、実力で得たものなのか、それとも羽織っただけのものなのかを教えてくれるのは、発信元 IP を公表された範囲に突き合わせることだけなのです。

すべてのクローラーを止められないなら、実際に私のプライバシーを守るのは何ですか？
#

確かめようのないクローラーや、不正直なクローラーを相手にしても、なお生き残る制御は、ただ一つ——そもそも何を公開するのかを、自分で決めることです。robots.txt と、公表された範囲を弾くことは、正直な多数派を止めてくれます。それはやる価値があります。ですが、検証できないクローラー——そして、どんな決まりも無視する偽者たち——を相手にするなら、包み隠さず表に出したものは、あなたには監査できないシステムに、もう読まれていると想定してください。そして、公開すること自体を、決断のときとして扱うのです。

出典
#

#	出典	URL	アーカイブ
1	OpenAI——GPTBot とクローラーのドキュメント（公表 IP 一覧つき）	https://developers.openai.com/api/docs/bots	https://web.archive.org/web/*/https://developers.openai.com/api/docs/bots
2	Anthropic——Anthropic はウェブをクロールするか、そして ClaudeBot を弾く方法	https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler	https://web.archive.org/web/*/https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler
3	Google——Googlebot とその他の Google クローラーを検証する	https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot	https://web.archive.org/web/*/https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot
4	Amazon——Amazonbot の公表 IP アドレス一覧	https://developer.amazon.com/amazonbot/ip-addresses/	https://web.archive.org/web/*/https://developer.amazon.com/amazonbot/ip-addresses/
5	Amazon（AWS re:Post）——Amazonbot を識別・検証する方法（FCrDNS）	https://repost.aws/questions/QUKdLk-sznTDOe-cyN-AyXGQ/how-to-identify-amazonbot	https://web.archive.org/web/*/https://repost.aws/questions/QUKdLk-sznTDOe-cyN-AyXGQ/how-to-identify-amazonbot
6	Cloudflare——Googlebot から GPTBot へ：2025年、誰がクロールしているのか	https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/	https://web.archive.org/web/*/https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/
7	Cloudflare——Perplexity は忍びの、名乗らないクローラーを使っている	https://blog.cloudflare.com/perplexity-is-using-stealth-undeclared-crawlers-to-evade-website-no-crawl-directives/	https://web.archive.org/web/*/https://blog.cloudflare.com/perplexity-is-using-stealth-undeclared-crawlers-to-evade-website-no-crawl-directives/
8	Perplexity——エージェントか、ボットか？開かれたウェブ上の AI を読み解く（反論）	https://www.perplexity.ai/hub/blog/agents-or-bots-making-sense-of-ai-on-the-open-web	https://web.archive.org/web/*/https://www.perplexity.ai/hub/blog/agents-or-bots-making-sense-of-ai-on-the-open-web
9	Cloudflare——Web Bot Auth（暗号によるクローラーの身元）	https://blog.cloudflare.com/web-bot-auth/	https://web.archive.org/web/*/https://blog.cloudflare.com/web-bot-auth/
10	SE Ranking——llms.txt の効果に関する研究（30万ドメイン）	https://seranking.com/blog/llms-txt/	https://web.archive.org/web/*/https://seranking.com/blog/llms-txt/

私たちのテスト成果物：検証の要約——2026年6月19日〜7月5日のログ期間から得た、user-agent ごとのリクエスト件数、検証された件数、そして /24 の粒度でのネットワーク所有者の集計だ。訪問者のデータは一切含まない。クローラーの IP は公共のインフラであり、/24 より細かくは開示していない。

**これが何であり、何でないかについて。**これは17日間の、できたばかりでアクセスも少ない一サイトの話だ——事例研究であって、全数調査ではない。この割合が言い表しているのは、私たちのログであって、ウェブではない。一般化できるのは、数字ではなく、方法とその判定の方だ——公表された身元と突き合わせよ、そうすればクローラーの世界は、確かめられるものと、そうでないものとに分かれる。私たちは、同じ計測を90日の節目でもう一度回し、その差分を公開するつもりだ——偽者の一団が育つのか、方法を持たないクローラーがいつか検証できるようになるのか、そして正直な連中が正直なままでいるのか。

この記事は、開かれたウェブが囲い込まれつつある——人よりも機械に多く読まれている——という私たちの論の、クローラー側の対をなす一篇であり、このシリーズの口火を切ったAI時代の脅威モデルに、実証で答える続きでもある。すでに公開されているものから、そうした機械の一つがあなたについて何を組み上げられるのかを見てみたいなら、私たちの自己監査ツールが、あなた自身の足跡に対して、同じ「信じるな、確かめろ」の規律を走らせてくれる。

Bitcoin オンチェーンのプライバシー 2026 — 追跡の仕組みと守り方

Mon, 22 Jun 2026 00:00:00 +0000

Bitcoin は匿名のお金だ——この心地よい思い込みは根強く残っています。それは最初から本当ではありませんでしたし、2026 年の今、かつてないほど本当でなくなりました。あなたがこれまでに行った支払いは一つ残らず、誰でもダウンロードできる公開台帳に載っています。そして、それを読み解くために何十億ドル規模の産業が存在します。大事なのは、チェーンを分析「できるかどうか」ではありません——それは常にできます——文字列とあなたの名前を結ぶ線が、実際にはどこで引かれるのか、そしてその一点一点で何ができるのか、です。

私は仮名で書いています。ですから自分のコインは、潤沢な資金を持つ分析者にずっと見られている前提で扱います。そう構えても何も失いませんが、構えなかった場合の代償は取り返しがつかないからです。脅威の大きさは、居心地の悪い形ではっきりと測れます。ブロックチェーン分析はもう成熟した商業分野です——Chainalysis のような企業は、政府や取引所に追跡ツールを売っています。そしてこの分野の土台となった学術研究(Meiklejohn et al., 2013)は、たった二つの手法だけで、約 1,200 万件の Bitcoin 公開鍵を約 330 万件の保有者クラスタ(同一人物のものと推定されるアドレスの束)へまとめ上げました。しかもそれは 10 年以上前、道具がまだ未熟だった頃の話です。台帳は忘れません。そして分析の費用は下がる一方です。

では、プライバシーは絶望的なのでしょうか。いいえ。ただし「条件付き」であって、たいていの解説はその条件を取り違えています。正直なところ、オンチェーンのプライバシーとは、それぞれが特定の一点だけを守り、他は無視する手法の寄せ集めであり、ある特定の脅威モデルに対して何層にも重ねて使うものです。以下では、追跡が実際にどう動くのか(その確からしさの本当の限界も含めて)、2024 年のミキサー摘発で何が変わったのか、そして 2026 年の各手法が何を守り——何を守らないのか——を、はっきり見える表で示します。

思い込み	実際	線が引かれる場所
「私のアドレスはただのランダムな文字列だ」	アドレスは恒久的で、公開された形でたどれる	clustering が複数アドレスを一つの財布へまとめる
「本名なんてどこにも書いていない」	コインは規制された出入口で身元と出会う	買ったり売ったりした KYC(本人確認)取引所
「プライバシー対応の財布を使ったから匿名だ」	各手法は一つの層を守るだけで、全部は守らない	オンチェーンの道具が一切触れない、チェーン外の漏れ
「追跡は確実な証拠になる」	手法が示すのは確からしさであって、確実性ではない	CoinJoin や PayJoin が核心の前提を崩す

オンチェーン追跡が実際にどう動くのか
#

チェーン分析とは、公開台帳に統計的な手法をあてはめて Bitcoin の仮名性を剥がしていく営みです——暗号そのものを破るのではなく、財布の使い方に出る癖を突くやり方です。中でも最も重要なのが common-input-ownership(共通入力所有)という手法です。複数のアドレスが一つの取引の入力としてまとめて使われたとき、分析者はそれらを同じ持ち主のものと見なします。チェーン全体にこの一つの前提をあてはめること、それが、つながりのない数百万のアドレスを、束ねられた財布の地図へと変えていきます。

仕事のほとんどは少数の手法が担っています。そして誠実に言えば、それぞれが示すのは「確からしさの度合い」であって、確実性ではありません。

手法	確からしさ	何が分かるか	何が崩すか
common-input-ownership(共通入力所有)	通常の支払いでは高い	まとめて使われた入力は一つの財布のもの	CoinJoin や PayJoin。複数の持ち主が一つの取引を共有する
change detection(おつり検出)	中程度	どの出力がおつりか——支払い相手にではなく、自分の財布へ戻るお金	異なる種類のアドレス形式の混在(Legacy/SegWit/Taproot)、同額の出力
address reuse(アドレス再利用)	起きていれば高い	再利用されたアドレス上の全取引が、ひとつにつながる	最近の財布(Sparrow、Cake)は毎回新しいアドレスを作る
peeling chain	中程度	「少し払い、残りを次へ送る」を繰り返して資金を動かす財布の動き	生データだけでは、支払いとおつりを確実には見分けられない

common-input-ownership は clustering の中核であり、同時に、協調型の取引がまさに崩すために作られた前提でもあります。change detection は、知っておく価値のある財布の挙動が手がかりになります。コインの一部を使うと、余ったおつりは支払い相手ではなく、自分の財布が管理する真新しいアドレスへ戻ります。だから一回の支払いが二つのアドレスを生み、分析者はその両方をあなたのクラスタへつなげようとするのです。

誠実な見立て——たいていの解説が飛ばすところ——は、これらが「確率的な帰属」であって証拠ではない、という点です。査読を経た 2023 年の peeling chain の分析は、支払いの癖が普通でなくなると精度が落ちる手法に、どれほど多くを頼っているかを浮かび上がらせています。これは法的にも実務的にも効いてきます。clustering は容疑者の範囲を狭めるだけで、それ単体であなたを名指しはしません。

アドレスが身元と出会う場所
#

アドレスが「あなた」になるのは、あなたの名前を抱えた記録に触れたときだけです——そして 2026 年において、その一点はほぼ必ず KYC(本人確認)取引所です。暗号の上では、チェーンは仮名のままです。仮名性が剥がれるのは規制された出入口、つまり身元を証明して買ったり売ったりした場所であり、その取引所が、確認済みのあなたの身元と、引き出し先のアドレスとを永続的に結びつけて保持している場所です。「本名なんてどこにも書いていない」が偽りの安心であるのはこのためです。あなたは登録した日に、顔写真付きの身分証で、それを取引所に差し出しています。

このつなぎ目を起点に、追跡は外へと広がっていきます。取引所は引き出し先のアドレスを知っています。clustering はそのアドレスを財布の残り全体へ結びつけます。そして、別の規制サービスとのその後のやり取りが、そのたびに身元を裏づけ直します。データ侵害は事態を悪化させます。漏れた KYC データベースは、身元という層をただで分析者の手に渡してしまいます——これは政府や企業のデータ侵害があなたを露わにする仕組みと同じ、チェーン外で漏れる力学です。さらに、オンチェーンの道具では何ともできない、まったくチェーン外の攻撃がもう一つあります。あなたの書いたものから、あなたが誰かを推定できてしまうのです——自分のノードについて語った投稿、タイムゾーン、意見。その推定の筋を扱ったのが AI による匿名性の剥がしであり、これはチェーン分析と並行して進みます。正しい捉え方は足し算です。オンチェーンのプライバシーは必要ですが、十分ではありません。

2024 年の摘発で実際に変わったこと
#

2024 年、法をめぐる状況が大きく変わりました。米国の検察当局が Bitcoin のミキシングサービスの運営者を訴追し、プライバシーのありようは消えてなくなるのではなく、その圧力を軸に組み直されたのです。教訓は「プライバシーは死んだ」ではなく、「プライバシーの構え方が動いた」——中央で協調するミキシングから離れ、逮捕すべき調整役のいない設計へと向かった、ということです。この転換を二つの出来事が決定づけました。

2024 年 4 月、ニューヨーク南部地区の連邦検事が Samourai Wallet の創業者を逮捕し、資金洗浄の共謀と無免許の資金移送の罪で起訴しました。同サービスの Whirlpool CoinJoin の調整役は停止しました(DOJ, 2024)。両創業者はのちに有罪を認め、2025 年 11 月にそれぞれ 5 年と 4 年の実刑判決を受けました。最初の逮捕から数週間後の 2024 年 6 月 1 日、zkSNACKs——Wasabi Wallet の CoinJoin を調整していた会社——は、規制の不確実性を理由にそのサービスを停止しました(zkSNACKs, 2024)。Wasabi 自体は動き続けました。一時は、協調型の CoinJoin はもう終わったかに見えました。

いや、終わってはいませんでした。それから数日のうちに、独立したコミュニティの調整役たちが、zkSNACKs の手放した WabiSabi プロトコルを引き継ぎ、協調型の Wasabi CoinJoin は動き続けました(LiquiSabi のような監視サイトで、その様子をリアルタイムに追えます)。公式の調整役は退きましたが、調整そのものは分散したのです。よくある要約は、さらに二点で取り違えていて、その細部があなたの選択を変えます。

「Silent Payments が CoinJoin に取って代わり、主流になった」。 正確ではありません。Silent Payments(後述)は別の問題——受け取り側のプライバシー——を解きます。2026 年の時点では、主流ではなく「広がりつつある」と表すのが最も正確です。CoinJoin のように金額を混ぜるわけではなく、受け取る側に実際の走査コストがかかります。置き換えではなく、補い合うものです。
「JoinMarket は衰退している」。 むしろ逆に近いと言えます。JoinMarket は調整役がいない——売り手と買い手が直接つながる市場で、起訴すべき中心がいない——ため、協調型のサービスが摘発される中でも、そのネットワークは動き続けました。(元のリポジトリは 2026 年 4 月にアーカイブ化されましたが、通信互換の後継 joinmarket-ng が OpenSats と HRF の助成のもとで活発な開発を続けています。)弱点は使いやすさと流動性であって、法的なもろさではありません。

長く効く教訓はこうです。2024 年の訴追が標的にしたのは調整役と資金移送であって、プライベートなコインを保有する行為そのものではありませんでした。圧力を生き延びたのは、調整役を取り除く設計(JoinMarket)か、プライバシーをプロトコルの層へ移す設計(Silent Payments)です。

2026 年のプライバシー道具箱 — 各手法が守るもの、守らないもの
#

「Bitcoin をプライベートにする」一つのスイッチは存在しません。各手法はそれぞれ一つの層——受け取りのつながり、取引のグラフ、金額、ネットワーク経路——を守り、他については黙っています。うまく選ぶとは、すべてを集めることではなく、あなたが最も断ち切りたい連鎖の一点に、道具を合わせることです。下の表は、たいていの解説が「プライバシー対応の財布を使え」へと平らに均してしまう比較を、誠実な形に戻したものです。

手法	守るもの	触れないもの	2026 年の状況
Silent Payments(BIP-352)	受け取りのプライバシー。公開できる固定アドレスで、そこへの支払い同士にオンチェーンのつながりが残らない	金額。送る側自身のプライバシー。チェーン外の身元	広がりつつある。受け取り側に走査コスト。Sparrow、Cake ほかで対応
PayJoin(BIP-78)	common-input-ownership を崩す。双方が入力を出し合うので、clustering が読み違える	金額のプライバシー。双方がオンラインである必要(運用上の壁)	仕様は安定。非同期版(BIP-77)がオンライン要件を緩めつつある
CoinJoin(JoinMarket)	協調型のミキシングで、取引グラフと金額の相関を	チェーン外の漏れ。KYC のつなぎ目。操作はそれなりに難しい	ネットワークは健在で調整役なし。保守は joinmarket-ng へ移行(2026 年)
Lightning Network	支払い金額を公開チェーンの外に完全に保つ	`payment_hash` は経路上で共有される。ノードの結託で剥がれうる	主流。blinded paths(BOLT 12)が経路のプライバシーを改善中
coin control / UTXO の基本対策	出所の異なるコインを混ぜないようにできる(自分で作ってしまう clustering を防ぐ)	チェーン外のすべて。自動では何もしてくれない	Sparrow、Cake に内蔵。最も安く、最も見過ごされる習慣

表だけでは伝えきれない注意点を、正直に補っておきます。Silent Payments(BIP-352、Bitcoin Optech)は、ここ数年で受け取りのプライバシーに起きた最も有望な変化です。再利用できるアドレスを一つ公開すれば、送る側はそれぞれあなた向けの固有のオンチェーンアドレスを導き出します。だから観測者には共通の宛先が見えません——ただし受け取る側は、支払いを見つけるためにチェーンを走査する必要があり、軽量クライアントの実装はまだそれを解いている途中です。Lightning は金額のプライバシーではオンチェーンより本当に優れていますが、既定でプライベートなわけではありません(2022 年の技術分析が詳述したとおり)。支払いの経路上の各ノードは同じ payment hash を知ります。そして結託したルーティングノードの一群——あるいは自らの位置取りとチャネルの探りを組み合わせる単一のノード——は、無視できない確率で送り手か受け手を特定できます。そして最も安い手法——coin control、どのコイン(UTXO=財布が保有する個々のコイン単位)を支払いに入れるかを選べる財布の機能——は、ほとんど誰も使っていないものです。KYC 由来のコインを、プライベートなコインと一緒に使わない。ただそれだけで、放っておけば分析者にただで差し出していたはずの clustering を防げます。あなたのソーシャルメディアの足跡と同じく、オンチェーンの失敗は恒久的です。取引に削除ボタンはありません。

手を動かす基本 — 分析者になったつもりでチェーンを読む
#

チェーン分析を理解する一番の近道は、誰かにやられる前に、公開のブロックエクスプローラ上で自分で少しやってみることです。有料ツールは要りません——商用の追跡を動かしているのと同じ手法は、取引の入力と出力を読む誰にでも見えています。私は自分の持つコインを、すべて既に見られているものとして扱います。きっかけは、ある午後、分析者の目で自分の取引を読んでみたことでした。

以下が、どの公開エクスプローラでも再現できる手順です(たとえば mempool.space——アカウントも、財布の接続も不要):

取引を開いて入力を数える。 二つ以上の入力がまとめて使われていれば、それが common-input-ownership の合図です。分析者はそれらのアドレスを一つの財布として扱います。その前提が自分に当てはまるか——そして、コインを混ぜてその前提を自分で作り出していないかを問うてみてください。
おつりを見つける。 二つの出力があり、片方が同じアドレス形式の新しいアドレスへ戻る、半端で切りの悪い金額になっていませんか。それはほぼ間違いなくあなたのおつりです。これで分析者は、あなたのクラスタにもう一つアドレスを得ました。
一つ前までさかのぼる。 ある入力の一つ前の取引をたどります。それが既知の取引所の引き出しパターンから直接来ていれば、身元のつなぎ目は一歩先です——それこそが大事な線です。
CoinJoin を見分ける。 多数の入力と、多数の同額の出力を持つ取引は協調型です。ここでは common-input-ownership が設計上わざと外れます。だからこそ、それは所有を裏づけるどころか、分析者の不確かさを高めるのです。

この方法で初めて自分の取引を読んだとき、意外だったのは、チェーンが何を明かすかよりも、それを覗くのがどれほど手軽かという事実でした——無料のエクスプローラだけで、特別な道具は要りません。これを十件の取引でやってみれば、漠然とした脅威が具体的になります。自分のどの習慣がクラスタを作り、どれが崩すのかを目で見られるのです。それがこの練習の狙いです——疑心暗鬼になるためではなく、自分の台帳が何を明かすのかを、肌感覚で測れるようになるために。上の道具箱の表にあるものはすべて、手順 1 から 3 で見つけた合図を取り除く、筋道立った方法にすぎません。

結論 — あなたの脅威モデルに合うのはどのプライバシー戦略か
#

ふさわしい Bitcoin プライバシーの構えは、あなたが誰から守るかで決まります。そして最もよくある間違いは、脅威を定める前に道具を買い込むことです。プライバシーは層になっています。最も安く、最も効く一点——ほぼ常に KYC のつなぎ目とコインの基本対策——を、高度な協調型の取引へ手を伸ばす前に、まず直してください。想像しうる最も精巧な攻撃にではなく、自分の現実の敵に、労力を合わせましょう。

受動的なデータブローカーやチェーン監視者から、日々の金融プライバシーが欲しいなら: 適法な範囲での KYC なしの入手、規律ある coin control、そしてアドレスを決して再利用しない財布を優先します。これで、たやすく作られるクラスタと身元のつなぎ目——現実の露出のほとんど——を、ほぼゼロのコストで取り除けます。
公の仮名を保っている人(創作者、書き手、活動家)なら: 上のすべてをやった上で、受け取りに Silent Payments を足し、自分の書いたものをより大きなリスクとして扱います。名の知れた仮名への最も安い攻撃は、チェーン分析ではなく、チェーン外の文章からの推定です——このガイドは AI による匿名性の剥がしと対にして読んでください。
狙いを定めた、潤沢な資金を持つ敵に直面しているなら: 各手法は、召喚状で得た取引所の記録や漏れたデータベースと組み合わされる前提で構えます。単一の道具では足りません。協調型の取引、Lightning による金額のプライバシー、ネットワーク層の保護、そして厳格なチェーン外の区画化を、何層にも重ねます——そして目標は「匿名」ではなく「より高いプライバシー」だと、誠実に受け入れます。

どの段階であっても、順序は同じです。敵を定める。KYC のつなぎ目とコインの基本対策をまず直す。それから、自分が本当に断ち切る必要のある連鎖に効く所へ、プロトコル層の道具を足す。

要点

匿名ではなく仮名: Bitcoin の台帳は公開です。土台となった clustering 手法(Meiklejohn et al., 2013)は、暗号を一切破らずに「別々の」アドレスを一つの財布へまとめます。
身元のつなぎ目は KYC 取引所: コインがあなたの本名と出会うのは、身分証が保持される規制された出入口です——どんな高度な道具より先に、この一点を直すこと。
2024 年の摘発が動かしたのは構え方であって、目標ではない: Samourai の創業者は 2024 年 4 月に起訴され(2025 年に実刑)、Wasabi の公式の調整役は 2024 年 6 月に退きました(分散した調整役が CoinJoin を継続)。さらに調整役のいない JoinMarket は動き続け、プロトコル層の Silent Payments が現れました。
各道具は一つの層を守る: Silent Payments=受け取り、PayJoin/CoinJoin=取引グラフ、Lightning=金額、coin control=自分で作るクラスタ。チェーン外の文章を守るものは、どれにもありません。
coin control が最も安く、最も見過ごされる防御: KYC のコインをプライベートなコインと一緒に使わない。それだけで、放っておけば分析者にただで差し出していたはずの clustering を防げます。

よくある質問
#

Bitcoin の取引は追跡できますか？
#

できます。Bitcoin は匿名ではなく仮名です。すべての取引は恒久的に公開され、チェーン分析の企業は clustering 手法——主に common-input-ownership の前提——を、KYC 取引所が保持する身元記録と組み合わせて活動を追跡します。追跡が突くのは癖であって、破られた暗号ではありません。

毎回新しいアドレスを使えば匿名になりますか？
#

助けにはなりますが、それで十分ではありません。新しいアドレスは address reuse(アドレス再利用)の手法を崩しますが、それでも一つの取引でコインをまとめて使えば common-input-ownership でつながりますし、引き出した KYC 取引所は依然として身元のつなぎ目を握っています。アドレスの基本対策は必要ですが、部分的です。

2026 年に Silent Payments は CoinJoin に取って代わりましたか？
#

いいえ。これはよくある誤読です。Silent Payments(BIP-352)は、再利用できる固定アドレスで受け取りのプライバシーを解きます。CoinJoin のように金額を混ぜることはせず、受け取る側に走査コストを課します。2024 年の調整役の摘発を経て、置き換えではなく重要な補完として現れ、主流ではなく広がりつつある段階にとどまっています。

Bitcoin のプライバシーで最も重要な一手は何ですか？
#

何よりもまず、身元のつなぎ目とコインの基本対策に手をつけることです。適法な範囲で KYC なしに Bitcoin を入手し、KYC の印が付いたコインをプライベートなコインと決して一緒に使わない。これで、最もたやすいクラスタと最も強い身元の線を、ほぼゼロのコストで取り除けます——漏れのある土台の上にどんな高度な道具を足すより、効きます。

Bitcoin のプライバシーツールは合法ですか？
#

これは法的助言ではなく、答えはあなたの法域と行いによって変わります。2024〜2025 年の米国の事件が訴追したのは、犯罪収益の取り扱いに結びついた資金移送と資金洗浄の罪に問われたミキシングサービスの運営者であって、取引のプライバシーを求めた個人ではありません。プライバシーを守るソフトウェアを使うことは広く適法ですが、税の申告のような義務は依然として残ります。自分の状況については、資格のある専門家に相談してください。

#	出典	URL	アーカイブ
1	Meiklejohn et al. — “A Fistful of Bitcoins: Characterizing Payments Among Men with No Names”(IMC 2013、二つの手法で 1,200 万鍵を 330 万クラスタへ)	https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf	https://web.archive.org/web/*/https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf
2	BIP-352 — Silent Payments(仕様)	https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki	https://web.archive.org/web/*/https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki
3	米国 DOJ(SDNY)— Samourai Wallet 創業者の逮捕・起訴(2024 年 4 月)	https://www.justice.gov/usao-sdny/pr/founders-and-ceo-cryptocurrency-mixing-service-arrested-and-charged-money-laundering	https://web.archive.org/web/*/https://www.justice.gov/usao-sdny/pr/founders-and-ceo-cryptocurrency-mixing-service-arrested-and-charged-money-laundering
4	zkSNACKs — Wasabi の CoinJoin 調整サービスの停止(2024 年 6 月 1 日)	https://blog.wasabiwallet.io/zksnacks-is-discontinuing-its-coinjoin-coordination-service-1st-of-june/	https://web.archive.org/web/*/https://blog.wasabiwallet.io/zksnacks-is-discontinuing-its-coinjoin-coordination-service-1st-of-june/
5	Bitcoin Optech — Silent Payments のトピック	https://bitcoinops.org/en/topics/silent-payments/	https://web.archive.org/web/*/https://bitcoinops.org/en/topics/silent-payments/
6	Bitcoin Magazine — “The State of Bitcoin’s Lightning Network Privacy”(2022)	https://bitcoinmagazine.com/technical/state-of-bitcoin-lightning-network-privacy	https://web.archive.org/web/*/https://bitcoinmagazine.com/technical/state-of-bitcoin-lightning-network-privacy
7	米国 DOJ(SDNY)— Samourai Wallet 創業者にそれぞれ 5 年・4 年の実刑判決(2025 年 11 月)	https://www.justice.gov/usao-sdny/pr/founders-samourai-wallet-cryptocurrency-mixing-service-sentenced-five-and-four-years	https://web.archive.org/web/*/https://www.justice.gov/usao-sdny/pr/founders-samourai-wallet-cryptocurrency-mixing-service-sentenced-five-and-four-years
8	Bitcoin の peeling chain パターンの査読分析(ScienceDirect、2023)	https://www.sciencedirect.com/science/article/pii/S2666281723001269	https://web.archive.org/web/*/https://www.sciencedirect.com/science/article/pii/S2666281723001269

このサイトの他の記事から、ここへ直接つながる筋が三つあります。オンチェーンのプライバシーは全体の半分にすぎません。名の知れた仮名への最も安い攻撃は、チェーン外の文章からの推定であり、それを地図にしたのが AI による匿名性の剥がし — 推定があなたの匿名性をほどく仕組みです——本記事はそのオンチェーン版にあたり、二つは足し算で効きます。身元のつなぎ目が、漏れた組織の記録であることがあまりに多いため、関連する実践集が 政府にデータを漏らされたときです。そして、オンチェーンの失敗が、あなたがこれまでに公開した何とも同じくらい恒久的であるため、削除後に何が残るのかを点検したのが ソーシャルメディアの足跡はどこまで消えないのかです。

AI の目で、自分の投稿履歴を棚卸しする（2026年）

Thu, 25 Jun 2026 00:00:00 +0000

資金について：CypherpunkGuide は監視型広告を一切載せない——広告ネットワークも、トラッキングピクセルも、スポンサー記事もない。運営は透明な収益源による：現在は読者からの寄付、将来は購読と編集方針に合致した affiliate。私たちは広告主ではなく、読者に向き合う。以下で触れる監査ツールは、無料で、ソースも公開されている。

私は仮名で書いている。この記事の対になる一本——AI 非匿名化——推論が、あなたの匿名性を解いていく——では、モデルが散らばった投稿をどうやって名前に変えるのか、そしてこれから先どう区画化していくかを示した。本記事が扱うのは、予防では手の届かないもう半分だ。あなたがすでに公開してしまった、何年分もの投稿である。その記録はいま、まさに公の場に置かれていて、攻撃が読むのはまさにその一群だ。正直な問いは「これから何を用心して投稿しようか」ではなく、「これまで自分が言ってきたことは、すべて足し合わせると何になるのか」である。そして、それを知る唯一の方法は、機械と同じやり方でそれを見ることだ。

幸い、それはできる。自分のデータの書き出しは、あなたにしか引き出せない。それを敵の目で読むのは、秘術ではなく身につけられる技術だ。問題は、それを読む最も自然なやり方——AI に貼りつけて「これは私の何を明かしている?」と尋ねること——が、事態を悪化させる可能性の最も高い一手でもある、という点にある。なぜそうなのかは、後で述べる。まずは、自分のタイムラインの内側からは感じ取れないものから始めよう。

モザイクは、自分では気づけない
#

危ないのは、不用意な投稿1件ではなく、その総体だ。再特定は、それ単体では無害なシグナル——通勤路、ある言い回し、タイムスタンプ——を積み重ね、それらが1人の人物のところで重なるまで続けることで成り立つ。これがいわゆる「モザイク効果」で、自分のフィードの内側からはそれを感じ取れない。タイル1枚1枚は、それだけ見れば無害だからだ。モザイクは昔からある手口だ。2000年、Latanya Sweeney は、アメリカ人のおよそ87%が、たった3つの公開情報——郵便番号、性別、生年月日——だけで一意に特定できることを示した（1990年の国勢調査データに基づく。2006年の再分析では約63%とされたが、いずれにせよ傾向は変わらない）。2006年には New York Times の記者が、「匿名」だった AOL の検索ユーザーを、その検索ログだけから突き止めて名指しした。2008年には、研究者が Netflix の「匿名化された」評価データを、公開されていた IMDb のレビューと突き合わせ、利用者を再特定した。どれも AI は使っていない。使ったのは、データの寄せ集めだ。

AI が変えたのは、そのコストだ。ICLR 2024 で発表された査読済みの研究『Beyond Memorization』で、ETH Zurich の研究者たちは、市販のモデルが、ありふれた Reddit のテキストから属性——居場所、職業、性別、収入——を、8属性平均でおよそ85%の top-1 精度（属性ごとのばらつきは大きい）で、しかも人間の調査者の100分の1ほどのコストで240倍速く推論できることを示した。さらに新しい研究は、これを工業化している。AutoProfiler（Du ほか、ACL 2026）は、4つのエージェントが連携する仕組みで、仮名の投稿履歴を（プラットフォームの API 経由で）引き出し、プロフィールを「ウェブ規模で」自動的に組み立てる。肝心なのは、どれか1件の投稿があなたを晒すという話ではないということだ。いまや機械は、それらすべてをまとめて読み、あなたには決して気づけなかった交点に目を留めるだけの余裕を、手にしている。

X では、漏れるのはたいてい言葉ではない
#

Reddit では、そのモザイクはおもにテキストから組み上がる。だが X では、おもにメタデータからだ。「テキストだけ気をつければいい」という思い込みは、危うい油断である。自分で設定した居場所の欄、投稿の時刻、画像の EXIF（写真に埋め込まれる撮影日時や位置などのメタデータ）、外部リンク、そして誰に返信したか——これらが、あなたが実際に書いた文面よりも多くを物語ることは少なくない。仮名のアカウントは、文面には用心していても、その周りの付帯情報から漏れてしまう。いちばんわかりやすい例が、投稿時刻の偏りだ。あなたの「匿名」アカウントが勤務時間どおりに動いていれば、いつ投稿したかの分布が、あなたのタイムゾーンと、起きて活動している時間帯を、そっと差し出してしまう。

画像は、思っている以上に厄介で、しかも二段構えだ。たいていのプラットフォームは、公開アップロード時に EXIF の GPS を取り除く。ただし、すべての経路でそうとは限らず（ダイレクトメッセージ、一部の API や予約投稿ツール、チャットの「ファイル」モードでは残ることがある）、古い画像は一度確かめておく価値がある。そして、たとえ GPS タグが消えていても、写真そのものが場所を割り出す手がかりになる。2024年の研究『Image-Based Geolocation Using Large Vision-Language Models』では、視覚言語モデル（画像と言語を扱う AI）が画像の内容だけから写真の撮影地を当てられることが示された——5万枚を使った GeoGuessr 風の対戦で85.37%に勝ち、時には0.3km 以内まで絞り込んだ。メタデータを削ぐのは必要なことだ。だが、それだけで終わりではない。

メタデータの層（おもに X）	それがそっと明かすもの	書き出しのどこを見るか
自分で設定した「居場所」欄	現実の地域を、自分の言葉で	`profile.js` / プロフィール文
投稿のタイムスタンプ	タイムゾーンと毎日の生活リズム	`tweets.js` の `created_at`
画像の EXIF + 写真の内容	正確な場所、端末、EXIF がなくても位置特定	`tweets_media/` の画像
外部リンク	あなたの他のサイトや別の身元	投稿内の URL 要素
返信・メンション	すでにあなたを知っている人間関係	メンション要素

自分の履歴を、敵のように読む
#

監査とは、読む向きを意識して逆転させることだ。昔を懐かしむ本人として読むのをやめ、獲物を追う他人になったつもりで読み始める。書き出した履歴を丸ごと引き出し、項目ごとに「これは恥ずかしいか」ではなく「これは自分が誰かを絞り込む手がかりになるか」と問うていく。データは、Reddit（設定 → プライバシー → データのコピーを請求）からも、X（設定 → アカウント → アーカイブをダウンロード）からも請求できる。どちらも、オフラインで読める構造化されたファイルとして届く。手に入れたら、以下の項目を順に当たっていく。わかりやすいシグナルだけでなく、弱いシグナルにも目を配りながらだ。像は、その弱いシグナルから組み上がるからである。

役に立つ心得を一つ。それぞれの発見は、単体でどれだけ明かしているように感じるかではなく、リスクにどれだけ上乗せするかで測ること。近所の目印に触れた投稿が28件あるほうが、勤め先を一度だけ名指した投稿1件よりも大きな問題だ。28件は、互いに重なり合うからである。探すべきは、手がかりのまとまりと一貫性だ——同じハンドル、同じ言い回しの癖、同じ朝7時の投稿枠。後の検索と照合の段階が別々のアカウントを結びつけるとき、頼りにするのはまさにこの一貫性だからだ。

項目	自分の履歴の中で何を探すか	どう和らげるか
居場所	通勤、地元のイベント、「〜の近く」、近所の目印、位置情報つきの写真	地域レベルまで一般化する／画像の EXIF を削るか避ける／プロフィール欄をぼかす
勤め先・収入	役職＋チームの規模＋技術構成、「採用中」、給与や保有資産のほのめかし	際立った組み合わせを落とす／自分のアカウントから採用活動をしない
家族	子の年齢や学校、パートナー、毎日の習慣	具体は消す／親類は「見つかってよい」と同意していないことを忘れない
生活リズム	毎日の決まった時刻、「平日は毎日」、投稿時刻の偏り	時刻をばらつかせる／仮名を自分の時計に合わせて動かさない
身元のつながり	使い回したハンドル、個人サイトへのリンク、EXIF に残る端末名	ハンドルを使い回さない／外部の個人リンクを消す／端末タグを削ぐ

あなたを非匿名化する、プライバシー監査
#

ここに落とし穴がある。しかも、それを指摘する人はほとんどいない。履歴を監査するいちばん分かりやすいやり方は、高性能な AI に貼りつけて、何が読み取れるかを尋ねることだ。だが、点検しようとしているアカウントが本名と切り離して保っている仮名で、しかも尋ねる相手の AI に本名でログインしているとしたら、あなたはこの瞬間、守ろうとしていたつながりの両端を、一つの会社にまとめて手渡したことになる。監査が、そのまま情報漏洩に変わる。順を追って考えてみよう。いまや、あるクラウド事業者が、あなたの本名アカウントのもとに、「匿名」ペルソナの投稿履歴を丸ごと抱えている。しかも、その二つがどう結びつくかを露骨に尋ねるプロンプトまで添えて、だ。その結びつきは、後になって令状・情報流出・内部者の手を通じて表に出かねない。まさに、あなたが監査して防ごうとしていた事態を、自分の手で作り出してしまうことになる。

これは、クラウド AI が一律に禁物だという意味ではない。リスクには条件がある。点検する相手が本名の公開アカウントなら、そもそも晒されて困る匿名の身元が存在しないので、非匿名化のリスクは当てはまらない。とはいえ、書き出しを丸ごとどこかのクラウドへ送れば、第三者がその中身を自社の規約のもとで処理することに変わりはないので、自分の書き出しに何が入っているかは先に確かめておきたい。本当に危ないのは、匿名のアカウントと本名の AI アカウントを組み合わせる、まさにその場合だ。そのときは、分析を、誰の目にも触れない場所で行うこと。

監査する相手が…	クラウド AI（本名アカウント）	ローカルモデル（オフライン）
本名・公開のアカウント	非匿名化リスクなし——それでも書き出しの中身は先に確認	問題なし、ただ遅いだけ
本名と切り離した厳密な仮名	避ける——本名↔仮名のつながりを作ってしまう	推奨——何一つ、あなたの端末から出ていかない

この監査を安全にこなすやり方は、すべてローカルで完結する。オープンソースで、まず手元で動くことを前提にしたツールが、書き出しを解析し、何が漏れているかを項目ごとに報告する。投稿をどこにも送らず、あなたのプロフィールをディスクに書き出すこともない。（まさにこのために、私は一つ作った。リンクは公開時にここへ載せる。）どうしても機微なアカウントでクラウドのモデルを使うしかないなら、本名やクレジットカードに紐づく主流サービスのアカウントではなく、暗号資産で支払えて身元をほとんど明かさずに使えるよう設計されたサービスを、その規約の範囲で選ぶこと。2026年6月時点では、たとえば OpenRouter は USDC で支払える OpenAI 互換 API で、登録はメールかウォレットだけで済む。Venice はプライバシー重視で、アカウント不要のままリクエストごとに暗号資産で支払う経路と OpenAI 互換 API を備え、どちらも本ツールのクラウド側にそのまま使える。ただし、これは真の匿名ではない。ウォレットやメール、通信のメタデータは残りうるし、プロンプトは依然として第三者に届く（OpenRouter のような中継なら、その先のモデル事業者にも届く）。しかもこうしたプライバシーの多くは事業者の自己申告で、第三者監査を経ていない。各サービスの現行規約を確かめること。そして、何一つ送らずに済む道は、結局ローカル実行だけだと忘れないことだ。

見つけたものを、どうするか
#

一括削除に走りたくなる衝動は、抑えること。投稿を1件消しても、あなたを晒したパターンまで消えることはめったになく、そもそも削除は消去ではない。アーカイブ、検索キャッシュ、スクリーンショット、そして他人が持っている控えは、ボタンを押したずっと後まで残り続ける。より効くのは、影響の大きい項目を一般化して書き換えること——「うちの近所から出る8時07分のフェリー」を「通勤」と言い換える——そして、これから公開するものを変えていくことだ。削除して実際に何が生き延びるのか、その全体像は 削除しても消えない——2026年、SNSの足跡はどこまで残るのか にまとめた。予防の側——像を結ばせる材料を残さないよう、身元を区画化すること——の手引きは AI 非匿名化 にあり、前提そのものを組み直す大きな見取り図は AI時代のOPSEC——脅威モデルを組み立て直す が描いている。

限界については、正直に言っておきたい。自分の書き出しの監査は、閉じた範囲の中での作業だ。見えるのは、あなたが差し出したものだけであって、敵が頼りにする外の世界——データブローカー（個人データを売買する業者）、流出データ、返信の関係網、サービスをまたいで一貫するあなたの文体——は見えない。240人を対象とした2025年の研究（Wang ほか）では、利用者が自分のどの断片が危ういかを言い当てられた精度は、偶然並みをわずかに上回る程度にとどまり、書き換えによって推論を実際に減らせたのは、28%にすぎなかった。だから監査は、「これで安全」というお墨つきではなく、リスクの低減として扱うこと。そして書き換えた後は、もう一度点検すること。リスクが下がったと言える証拠は、結局のところそれしかないからだ。

これが、身の安全に関わる人たち
#

推論への耐性は、多くの人にとっては基本の心得にすぎないが、一部の人にとっては身の安全そのものだ。過去をさかのぼる監査が最も要るのは、敵がすでに探し出そうとしている人たちだ。嫌がらせ目的の晒し（doxxing＝個人情報の暴露）、なりすまし、捏造された画像は、女性に偏って重くのしかかる。そして「過去が今この場で晒される」という同じ危険は、虐待を生き延びた人、敵対的な環境にいる LGBTQ の人、反体制の人、そして記者の情報源——古く忘れ去られた投稿1件が、いま現在のリスクになりうるすべての人——を脅かす。配信者はどう晒されるのか の事例研究が、そのパターンを白日の下にさらしている。もしそれがあなたの脅威モデルなら、監査は気が向いたときの片づけではなく、予定に組み込んで続ける手入れだ。

要点

未来の投稿だけでなく、過去の記録を監査する。 いまある履歴こそ、攻撃が読み込む当のデータだ。Reddit と X の書き出しを引き出し、項目ごとに敵の目で読むこと。
脅威は、モザイクそのものにある。 再特定は弱いシグナルを積み重ねていく（Sweeney 2000：アメリカ人の約87%が、郵便番号＋性別＋生年月日で特定可能）。AI はただ、それらすべてを読む作業を安くしただけだ（Staab ほか、ICLR 2024：8属性平均で top-1 約85%）。
X では、メタデータが言葉より多くを漏らす——居場所欄、投稿時刻、EXIF、リンク、返信。しかも EXIF を削ぐだけでは足りない。モデルは画像そのものから位置を割り出す（Liu ほか、2024）。
仮名を、本名のクラウド AI で監査しない。 一つの事業者に、本名↔仮名のつながりをまとめて手渡すことになる。機微なアカウントには、オフラインで動くローカルのモデルを使うこと。
一括削除ではなく、一般化を。 削除≠消去。リスクの高い項目を書き換え、次に公開するものを変えること。監査はリスクの低減であって、匿名性の保証ではない。

よくある質問
#

監査するための Reddit と X の投稿履歴は、どうやって手に入れますか？
#

それぞれのプラットフォームから書き出しを請求してください。Reddit では、設定 → プライバシーとセキュリティ → 「データのコピーを請求」を選ぶと、コメントと投稿が CSV ファイルで届きます。X では、設定 → アカウント → 「データのアーカイブをダウンロード」を選ぶと、tweets.js・account.js・profile.js と、tweets_media という画像フォルダの入ったフォルダが届きます。どちらも履歴を丸ごとオフラインで読めるので、これが安全な分析のやり方です。ただ中身を見るためだけに、第三者へ手渡す必要はありません。

ChatGPT など、クラウドの AI に投稿を点検させても安全ですか？
#

それは、どのアカウントを点検するかで決まります。本名や公開のプロフィールなら、晒されて困る匿名の身元がないので、クラウドのモデルでも問題ありません。けれど、点検する相手が本名と切り離して保っている仮名なら、その履歴を本名でログインした AI に送ることは、その事業者のサーバー上で二つを結びつけてしまいます。まさに、あなたが防ごうとしていた非匿名化そのものです。その場合は、オフラインで動くローカルのモデルか、匿名で開設して匿名で支払ったクラウドアカウントを使ってください。

古い投稿は、いっそ削除してしまうべきですか？
#

たいていの場合、丸ごと消すのは得策ではありません。投稿を1件消しても、あなたを晒したパターンまで消えることはめったになく、そもそも削除は消去ではありません。アーカイブ、キャッシュ、スクリーンショットは残りますし、削除した内容もプラットフォーム自身のサーバーには一定期間（たとえば Reddit なら90日ほど）保持され、その間は法的手続きが届きます。より効くのは、リスクの高い項目を一般化するか書き換え（具体的な時刻と場所を、ぼんやりしたものに変える）、これから公開するものを変えていくことです。後で必ずもう一度監査し、その変更で実際に露出が下がったかを確かめてください。

EXIF を写真から削ぎ落とせば、それで済むのではありませんか？
#

EXIF は削いでください。必要なことです。ですが、それで十分というわけではありません。視覚言語モデルは、メタデータが一切なくても、写真に写った内容だけから位置を割り出せます（Liu ほか、2024 は、時に0.3km 以内の精度を報告しています）。店先、街のスカイライン、道路標識、窓からの眺めは、あらゆるタグを取り除いた後でも、その画像の撮影地を突き止める手がかりになります。メタデータだけでなく、写り込んだ背景もまた、写真が明かしてしまうものの一部だと考えてください。

AI は、これが実際どれくらい正確なのですか？
#

真剣に受け止めるべき水準には達していて、しかも誰にでも片っ端から走らせられるほど安価です。査読済みの研究（Staab ほか、ICLR 2024）では、GPT-4 が平文の Reddit テキストから、8つの属性カテゴリ平均でおよそ85%の top-1 精度（属性ごとのばらつきは大きい）を出しました。2026年の preprint（査読前の論文）は、Hacker News（技術者が集まる掲示板）ユーザーの標本のうち、およそ三分の二を本物の LinkedIn プロフィールに、90%の精度で、1人あたりおよそ1〜4ドルで結びつけています。数値は課題によって変わり、完璧でもありません。とはいえ、かつてあなたを守っていた摩擦——人間が何時間もかけて調べる手間——は、もう消えてしまいました。

#	出典	URL	アーカイブ
1	Staab ほか——“Beyond Memorization: Violating Privacy via Inference with LLMs”（ICLR 2024）	https://arxiv.org/abs/2310.07298	https://web.archive.org/web/*/https://arxiv.org/abs/2310.07298
2	Du ほか——“Automated Profile Inference with Language Model Agents” / AutoProfiler（ACL 2026 Findings）	https://arxiv.org/abs/2505.12402	https://web.archive.org/web/*/https://arxiv.org/abs/2505.12402
3	Lermen ほか——“Large-scale online deanonymization with LLMs”（arXiv preprint〔査読前〕、2026年）	https://arxiv.org/abs/2602.16800	https://web.archive.org/web/*/https://arxiv.org/abs/2602.16800
4	Liu ほか——“Image-Based Geolocation Using Large Vision-Language Models”（2024）	https://arxiv.org/abs/2408.09474	https://web.archive.org/web/*/https://arxiv.org/abs/2408.09474
5	Wang ほか——“Beyond PII: How Users Attempt to Estimate and Mitigate Implicit LLM Inference”（2025）	https://arxiv.org/abs/2509.12152	https://web.archive.org/web/*/https://arxiv.org/abs/2509.12152
6	Electronic Frontier Foundation——Surveillance Self-Defense	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/

写真に隠れたデータが、あなたの自宅住所を明かす（2026年）

Mon, 06 Jul 2026 00:00:00 +0000

一枚の写真は、二つのものでできている。目に見える画像。そして、あなたが送るファイルだ。このファイルには、もう一つの中身がひそかに積まれている——シャッターを切った時刻、撮影した端末、その端末の serial number（カメラ固有の製造番号）、そして位置情報サービスがオンだったなら、あなたが立っていた地面の緯度と経度だ。この、もう一つの中身が EXIF（写真ファイルに自動で埋め込まれる撮影情報。位置情報を含みうる）——ほぼすべてのカメラとスマートフォンが、既定で写真に書き込む metadata（データについてのデータ）のかたまりだ。

これは、机上の空論ではない。2012年、指名手配中のハッカーが、恋人の自宅を突き止められた。アップロードした一枚の写真が、GPS による位置情報——衛星が割り出した緯度と経度——をまだ抱えていたからだ（Gizmodo、2012年）——彼は連邦刑務所での 禁錮27か月を言い渡された（FBI、2012年）。同じ年、当時ベリーズ当局から身を隠していた John McAfee を撮った雑誌の写真には、彼をベリーズ国境に近いグアテマラに位置づける座標が埋め込まれていた（NPR、2012年）——撮影した記者たちによれば、川辺の特定の一地点だ（The Next Web、2012年）。その一方で学術研究者たちは、ありふれた売買広告の写真から、出品者の自宅住所までたどり着けることを示した（Friedland & Sommer、USENIX HotSec 2010）。

だから、問いは「写真の metadata があなたの自宅を明かしうるか」ではない——それは、事件記録がすでに決着させている。本当の問いは、もう対処したと信じている人たちが、なぜ見つかり続けるのか、だ。そして答えは、居心地の悪いものだ。多くの助言は「プラットフォームが代わりに削ってくれる」で止まっていて、それは正しいのだが、身を切るほど鋭い例外つきなのだ。2026年7月6日、私たちは一枚のテスト写真に、既知の GPS 座標、二つの製造番号、そして縮小画像を書き込み、それを削除し、結果を1バイトずつ検証した。以下の手順は、その実験そのものだ。そしてこれこそ、ほとんどのガイドが抜かしている一手——データを取り除くことではなく、消えたと証明することなのだ。これは、二層構造の問題の metadata 側の話だ。もう半分——目に見える情景そのものが明かしてしまうもの——は、写真1枚で、AI はあなたの居場所を突き止める に地図化してある。

事件記録——たった一つのファイルに暴かれた三人
#

ここに挙げる事例は、どれも決着がつき、記録に残り、そしてそれぞれ違った形で私たちに教えてくれる。一つ目は、この仕掛けが敵の全力とぶつかったときの威力を見せる。二つ目は、隠れ続けることに命がかかっていた人を、それが打ち負かした事実を突きつける。三つ目は、敵などまるでいない相手にさえ、それが働くことを示す。

ハッカー——Higinio Ochoa、2012年
#

Higinio O. Ochoa III は、Anonymous 系のハッカー集団 CabinCr3w の w0rmer を名乗り、2012年2月にアメリカの法執行機関のサイトに侵入した。彼が挑発とともに投稿した「証拠」の中に、恋人の iPhone で撮った一枚の写真があった——そのファイルには GPS ブロックがまだ残っていて、オーストラリア・メルボルン郊外のウォンティルナ・サウスにある一軒の家を指し示していた（Gizmodo、2012年、CSO Online、2012年）。そこから捜査当局は、その場所を恋人へ、そして恋人を通じて Ochoa へとたどり着いた。彼は同年3月に逮捕され、罪を認め、連邦刑務所での禁錮27か月を言い渡された（FBI、2012年）。FBI から本気で逃げ回り、侵入の手口には長けていた人物が、スマートフォンのカメラの初期設定ひとつで、居場所を突き止められたのだ。

逃亡犯——John McAfee、2012年
#

2012年12月、McAfee がベリーズ当局から身を隠していたころ、Vice は「We Are with John McAfee Right Now, Suckers（今まさに John McAfee と一緒にいるぜ、間抜けども）」と題した彼の写真を公開した。撮影に使われた iPhone 4S は、公開されたファイルに座標を埋め込んでいた——北緯15度39分29.4秒、西経88度59分31.8秒、グアテマラのリオ・ドゥルセ一帯だ（The Next Web、2012年）。McAfee は当初、自分でデータを細工したと主張したが、翌日には座標が本物だと認めた（NPR、2012年）。そして間もなく、グアテマラで身柄を拘束された。ここでのしくじりは、彼のものではない。他人のカメラが、彼の居場所を公開したのだ。あなたの metadata の露出には、あなたに向けられたすべての端末が含まれる。

テレビ司会者——Adam Savage、2010年
#

『怪しい伝説（MythBusters）』の Adam Savage は、自分のトラックの写真に「さあ、仕事へ（Now it’s off to work）」というひと言を添えて投稿した——ところが、写真のジオタグ（位置情報のタグ）はそのトラックを自宅の前に位置づけ、しかも添えられた言葉は、これから家が留守になると告げていた（The New York Times、2010年）。敵もいなければ、追跡もない——ただの初期設定が、気軽な投稿を、住所と留守の予定表に変えてしまった。読者のほとんどは、逃亡犯でもハッカーでもない。だからこそ、この事例こそが、あなたのことなのだ。

写真ファイルには、実際に何が入っているのか
#

EXIF（Exchangeable Image File Format）は、カメラが JPEG や大半の RAW（未加工の画像）ファイルに書き込む metadata の規格で、カメラ業界の団体 CIPA が定めている（DC-008）。画像は、あなたが見るものだ。EXIF は、ファイルが覚えているものだ——そして、覚えているのは場所だけではない。

写真ファイルは、目に見える画像に加えて、見えない EXIF を運ぶ——GPS 座標、撮影時刻、カメラの製造番号、そして埋め込みの縮小画像だ。

EXIF の項目	何が分かるか	誰が使ってきたか
GPS の緯度／経度／高度	シャッターを切った場所を、数メートルの精度で	FBI（Ochoa の事例）、そして閲覧ソフトを持つ誰でも
撮影日時	いつ撮ったか——GPS と組み合わせれば、生活のパターンに	Savage の事例——住所に加えて「留守」まで
本体とレンズの製造番号	どの一台のカメラか——公開ウェブ上を横断して検索できる	製造番号の検索サービスが、カメラ単位で写真を索引化
メーカー／機種／ソフトウェア	端末と編集の指紋	身元を絞り込み、編集済みファイルを見分ける
埋め込みの縮小画像	画像の小さな複製——ときに編集前の元画像	2003年の縮小画像事件（後述）

この表のうち二つの行は、とりわけ強調しておく価値がある。一般向けのガイドが、ほとんど触れないからだ。

製造番号は、写真どうしを結びつける。 多くのカメラ——そして一部のスマートフォン——は、本体やレンズの製造番号を、自分が作り出すすべてのファイルに書き込む（書き込まない機種も多く、プラットフォームが削ることもあるので、これは確実な事実というより、確かめておくべきリスクだ）。書き込まれている場合、Stolen Camera Finder のようなサービスは、特定の製造番号を持つ写真をウェブ上から探し出すために存在する——盗難カメラを取り戻すために作られたものだが、同じ仕組みは、一台のカメラがこれまで公開してきた、削除し忘れのすべての写真をつなぎ合わせる手段にもなる。もしあなたが複数の身元を使い分けているなら——たとえば、仕事用の名前と、仮名のアカウント——一台のカメラが両方に削除し忘れのファイルを投稿していれば、その時点で、metadata の層で二つはもう結びついている。このつながりは、配信者は、どこで暴かれるのか で記録した、ドキシング（嫌がらせを目的に、本人の同意なく実名や住所などの私的情報を晒すこと）の連鎖と、同じ根を持つ、もっと目立たない現れだ。

縮小画像は、編集を裏切ることがある。 EXIF は、写真を撮った瞬間に作られる小さなプレビュー画像——embedded thumbnail（ファイル内に埋め込まれた縮小画像）——を抱えている。2003年、TechTV の司会者 Cat Schwartz は、切り抜き済みの写真を投稿した——ところが当時の編集ソフトは、埋め込まれた縮小画像を作り直さなかったため、切り抜く前の元画像が、公開されたファイルの中に一緒に紛れ込んだまま運ばれ、読者がそれを取り出してしまった（MetaFilter、2003年）。いまの OS 標準の編集機能は、たいてい縮小画像を作り直す。だが、サードパーティの処理系が必ずそうするとはかぎらない。ここでの教訓は「切り抜くな」ではない——目に見える編集は、目に見えないデータについて何ひとつ証明しない、ということだ。だからこそ、検証（後述）が、すべてを支える一手になるのだ。

初期設定が、あなたを裏切る場所
#

いちばんよく耳にする安心材料——「どうせプラットフォームが EXIF を削ってくれる」——は、公開表示に関してはおおむね正しく、しかし防御としては危ういほど不十分だ。それは、端っこで破綻する。そして、その端っこでこそ、これまでの事件は起きてきた。

下の表がまとめるのは、削除がどこで破綻し、それをどう見抜くか——この記事が拠って立つ「確かめる」習慣そのものだ。ここに挙げる挙動は2026年に検証した時点のもので、アプリのバージョン・端末・アップロードの方法によって変わる。「どこを見ればいいか」の道しるべであって、恒久の保証ではないと考えてほしい。

どこへ送るか	何が残るか	どう見抜くか
公開投稿——Instagram／Facebook／X	公開版は再エンコードされるが、元ファイルはサーバー側に保持される（Meta のポリシー）	サーバー側の控えは覗けない——プラットフォームは削除前のファイルを抱えていると想定し、アップロードの前に削る
TikTok への投稿	公開版は再エンコードされる	位置情報は別の手段でなお集められる。ファイルがきれいでも、追跡されていないとはかぎらない
メッセージアプリの写真モード——WhatsApp／Signal／Telegram	たいてい圧縮で EXIF が落ちる	テスト写真を1枚、自分あてに送り、実際に届いたものの metadata を読む
メッセージアプリのドキュメント／ファイルモード	metadata はそのまま素通りする——画質のために人が選ぶ経路だ（後述）	「ファイルとして送信」は、読み取りツールで確かめるまで削除されていないものとして扱う
メール、クラウドの共有リンク、フリマ出品	そもそも何も削られないことが多い	削る層はあなただけ——どのファイルも自分で確かめる

この表を実際の事件へと変えるパターンが、三つある。第一に、ドキュメントの罠。メッセージアプリは「写真」として送ると metadata を削る。画像を再エンコード（作り直して圧縮すること）するからだ。ところが、画質を保とうとして人があえて選ぶ「ファイルとして送信」は、すべてを保持してしまう。Signal 自身のコミュニティ文書も、その削除が効くのは「写真」として送る通常の経路であって、一般的な添付ファイルとして送られたものには及ばないと認めている（Signal Community）。WhatsApp と Telegram も、コミュニティの検証では同じように振る舞う——そして三つとも、あなたには何も警告しない。第二に、最初の一歩の問題。プラットフォームは公開する版からは削るが、プラットフォーム自身は完全なファイルを受け取っている。ローカルで削ることは、その座標を彼らの保管からも締め出す、唯一の方法なのだ。第三に、プラットフォームなしの問題。売買広告、フリマ出品、フォーラムの添付、メール——これらは、はるかに弱い保証のまま、ファイルをそのまま通す。これこそ、Friedland と Sommer が2010年に 「cybercasing」（公開写真の位置情報から下見する手口） と名づけた、体系的なリスクだ。二人は、ありふれた Craigslist の出品を手がかりに、写真の座標を街路地図と突き合わせ、出品者の自宅へまっすぐ歩いていった（ICSI、2010年）。自宅の中で貴重品を撮る出品者は、侵入者が最も欲しがるファイルを、そっくりそのまま作り上げている——何が盗む価値のあるもので、それがどこにあるか、を。

そして、両面から正しておくべき思い込みが、一つある。写真のスクリーンショットは、確かに、元の EXIF を持たない新しいファイルを作る——本物の、metadata の対処だ。だが、画像が写しているものについては、何ひとつ変えない。相棒となる記事で述べたとおり——スクリーンショットが変えるのは、ファイルであって、写り込んだ景色ではない。

「信じる」ではなく「確かめる」——私たちの実演
#

どのガイドも、metadata を削れと言う。だが、確かめろと言うガイドは、ほとんどない。そこで2026年7月6日、私たちはテスト用のファイルで、ひと続きの流れをすべて回してみた——既知の座標を書き込み、削除し、検証する——ExifTool 12.57（ディストリビューションのパッケージ版。upstream の最新は 13.59）を使い、Linux のマシン上で。ExifTool は、画像の metadata を読み書きするための、無料のコマンドラインの定番ツールだ。以下は実際の手順で、出力は重要な項目だけに絞ってある。どの手順も再現でき、手を加えていない完全なログは——一行残らず——この記事に添付してある（実験ログ）。

手順1——ファイルが何を抱えているかを見る。 私たちはテスト写真に、現実的な中身を持たせた——GPS の位置、北緯48.8584・東経2.2945（エッフェル塔。あえて当たり障りのない目印を選んだ）、本体とレンズの製造番号、撮影時刻、そして埋め込みの縮小画像だ。それから、このファイルが見知らぬ相手に何を語るのかを、尋ねてみた。

$ exiftool -a -gps:all -SerialNumber -LensSerialNumber -Model photo.jpg
GPS Latitude : 48 deg 51' 30.24" N
GPS Longitude : 2 deg 17' 40.20" E
GPS Altitude : 35 m
Serial Number : SN-TEST-123456
Lens Serial Number : LENS-TEST-789
Camera Model Name : TC-1

フラグを一つ（-n）付ければ、これは十進数に変わる——48.8584, 2.2945——そのまま、どんな地図にも貼り付けられる。埋め込みの縮小画像も、そこにあった。948バイトの、画像まるごとの小さな複製で、コマンド一つで取り出せる。合わせて 1,510バイトの metadata が——どの画像ビューアでも目には見えないまま——場所と、機材の身元と、プレビューを運んでいたのだ。

手順2——削る。 ローカルで削る定番は、たった一つのコマンドだ。

$ exiftool -all= photo.jpg

同じ操作を包んだ、デスクトップ向けの選択肢もある。ExifCleaner（オープンソース、ドラッグ&ドロップ、テレメトリ〔利用データの外部送信〕なし。2026年時点で v4.0）や、後述する OS 標準の共有オプションだ。

手順3——確かめる。 ここが、思い込みと、確かな知識とを分ける一手だ。手順1と同じ問い合わせを、削除後のファイルに対して走らせる。

$ exiftool -a -gps:all -SerialNumber -LensSerialNumber -ThumbnailImage photo.jpg
(no output)

出力が空であること——それが合格の条件だ。GPS も、製造番号も、縮小画像も、生き残っていない。-all= のあとに残るのは、ファイルの構造だけ——寸法、符号化方式、サイズ——場所も、端末も、画像の以前の版も、何ひとつ指し示さないものだけだ。

手順4——初期設定を、自分の味方につける。 iPhone なら、共有シートの 「オプション」→「位置情報」 のスイッチで、送信するものから座標を外せる。さらに「設定」→「プライバシーとセキュリティ」→「位置情報サービス」→「カメラ」→ 「許可しない」 にすれば、そもそも書き込まれなくなる（Apple）。Android なら、カメラ自身の位置情報の許可が、そもそも座標を記録するかどうかを決める——ただし、知っておく価値のある、はっきりした限界がある。Google フォトが編集・削除できるのは、自分が推定した位置か、手で追加した位置だけだ。Google 自身のヘルプページによれば、カメラがファイルに書き込んだ座標は、Google フォトの中では一切削除できない——アプリが見せてくれる表示の下で、手つかずのまま生き延びる（Google）。この抜け穴こそ、手順3の存在理由そのものだ。書き出したファイルが本当にきれいかどうかは、アプリと、それが通ってきた経路しだいなのだから——スイッチや画面の表示ではなく、metadata 読み取りツールの、空の出力を信じること。

脅威の段階ごとの習慣
#

上の「削って、確かめる」という一連の流れは、機械的なものだ。段階ごとに変わるのは、それをどれだけの頻度で回し、どこまで徹底するかだ。あなたの居場所を気にかけうる相手に応じて、下の行を選んでほしい——これは、私たちの AI 位置推定ガイドにある「構図とタイミング」の心得に対応する metadata 層版であって、その焼き直しではない。

段階	対象	身につける習慣
基本層	気軽に共有する人	カメラの位置情報はオフ。公開投稿はプラットフォームの削除に任せてよいが、送るファイルには決して頼らない——削除を通さない「ドキュメントモード」の写真は送らない
出品者	フリマ・売買広告の利用者	すべての出品写真を削除し、端末ごとに最初の一枚は検証する。身元の割れる背景を前に貴重品を撮らない——cybercasing はここから始まる
身元を分けている人	仮名アカウント、クリエイター、活動家、生存者	すべてを削除し、そのうえで検証する。製造番号は、身元をまたいで結びつける識別子だと考える。他人が撮ったあなたの写真は、どれも座標つきで出回ると想定する（McAfee の教訓）——ストーキングや親密なパートナーによる暴力（IPV）の生存者にとっては、削除し忘れの一枚が、加害者に現在の住所を手渡しかねない。だからこの段階では、あらゆるファイルを慎重に扱う

どの段階にも共通するパターンがある。習慣の代償は数秒。そして、それが防ぐ失敗は、取り返しのつかない種類のものだ。座標は、いったん公開されれば、消せない記録の一部になる——投稿について 削除しても消えない——2026年、SNSの足跡はどこまで残るのか で地図化したのと、同じ「永続の経済学」だ。

結論——送っているのは、ファイルだ
#

あなたが共有したつもりなのは、画像だ。だが、実際に共有したのは、ファイルだ。この記事のどの事例も——ハッカー、逃亡犯、テレビ司会者、切り抜き前の縮小画像、cybercasing にあった出品者——たった一つの隙間に行き着く。そして、その隙間には、機械的な直し方がある。ローカルで削り、そのうえで、ファイル自体を読むツールで検証する。2003年の縮小画像から今日まで、二十年ぶんの記録された事件が告げているのは、こういうことだ。痛い目に遭うのは、助言を一度も聞かなかった人ではない。もう対処したはず、と思い込んでいた人たちなのだ。

要点

仕組みは実証済みで、机上の空論ではない： 一枚の写真の GPS ブロックが、捜査当局をハッカー Higinio Ochoa へと導き（禁錮27か月、2012年）、他人のカメラが埋め込んだ座標が、John McAfee のグアテマラの隠れ家を暴いた（2012年）。
EXIF が運ぶのは、場所だけではない： カメラの製造番号は、写真を——そして仮名のアカウントを——ウェブ上で結びつけ、埋め込みの縮小画像は、編集前の画像を運んできた実績がある（2003年）。
プラットフォームの削除は、表示される版どまりだ： 公開投稿は再エンコードされるが、「ドキュメント／ファイルとして送信」は完全な EXIF を保持し、プラットフォームは元データをサーバー側に保持することがあり、フリマやメールは何も削らないことが多い。
検証こそ、抜け落ちている一手だ： 2026年7月の私たちのテストでは、exiftool -all= が、身元につながる 1,510バイトの metadata をすべて取り除いた——そして、GPS を見つけたのと同じ問い合わせが、それが消えたことを証明する。
他人のカメラも、勘定に入る： McAfee は、記者のスマートフォンによって位置を突き止められた。あなたの露出には、あなたが写った、削除し忘れのすべての写真が含まれる。

よくある質問
#

写真にどんな metadata が入っているか、どうやって確かめますか？
#

ファイルに直接、尋ねてください。ExifTool を入れて、すべてを見るなら exiftool photo.jpg、いちばん大事な項目だけなら exiftool -a -gps:all -SerialNumber photo.jpg を実行します。iPhone なら、写真を上にスワイプすると位置情報が見えます。Android なら、Google フォトで写真の詳細を開きます。OS 標準の表示が見せてくれるのは、その一部だけです——コマンドラインは、敵が見るものを見せてくれます。

SNS は、EXIF を自動で削除してくれるのではないですか？
#

公開表示される画像については、たいていそうです——X、Facebook、Instagram、TikTok は、アップロードを再エンコードし、他のユーザーに見える metadata を落とします。ですが、プラットフォームはあなたの元ファイルを受け取っていて、そのデータをサーバー側に保持することがあります。そして、メッセージアプリの「ドキュメント／ファイルとして送信」（WhatsApp、Signal、Telegram）は、再エンコードを迂回し、完全な EXIF を届けてしまいます。フリマの出品やメールは、何も削らないことがよくあります。先にローカルで削ってしまえば、この問い自体が意味を失います。

写真を切り抜いたり、ぼかしたりすれば、metadata は消えますか？
#

いいえ——ピクセルを編集することと、metadata を編集することは、別々の操作です。切り抜いたり、ぼかしたりした写真も、完全な EXIF ブロックを抱えたままでいられますし、有名な2003年の事例では、metadata の中の embedded thumbnail（埋め込みの縮小画像）が、切り抜く前の元画像を、なお抱えていました。いまの編集ソフトには、縮小画像を作り直すものもあれば、書き出し時に metadata を削るものもあります。確かめる唯一の方法は、metadata 読み取りツールで、出力されたファイルを検証することです。

写真の metadata は、匿名アカウントと実名アカウントを結びつけることがありますか？
#

はい、ハードウェアの識別子を通じて、です。カメラの本体とレンズは、製造番号を EXIF に書き込みます。そして、製造番号で索引化された検索も存在します（盗難カメラの回収のために作られたものです）。一台のカメラが、削除し忘れの写真を二つの身元に投稿していれば、その時点で両者はつながっています——顔認識も、文体の分析もいりません。ファイルだけで、です。もし複数の身元を使い分けているなら、metadata を削ることは、やってもやらなくてもいい心がけではありません。身元を守る設計そのものです。

パソコンなしで、スマホだけで写真の metadata を消すには？
#

iPhone なら、共有シートを開き、上部の 「オプション」 をタップして、送信・保存の前に 「位置情報」 をオフにします——これで、書き出される写真から座標が外れます。Android は、ギャラリーアプリによってまちまちで、しかも厄介な落とし穴があります。Google フォトが消せるのは、推定した位置か手で足した位置だけで、カメラ自身が書き込んだ座標は消せません——だからその値は、アプリの画面表示がどうであれ、生き延びることがあります（Google）。標準の手順で心もとないときは、ExifCleaner のような専用の除去ツールを使い、そのうえで metadata 読み取りツールで結果を確かめてください。証拠になるのは、スイッチではなく、ファイルの方です。

出典
#

私たちのテスト成果物：2026年7月6日の「削除して検証する」実行から得た、手を加えていない実験ログ（ExifTool 12.57。テスト座標はエッフェル塔で、当たり障りのない目印として選んだ）。

この記事は、このサイトの写真プライバシーの筋のうち、metadata 側の半分だ。目に見える情景が明かしてしまうもの——そして、なぜそちらの半分は削り取れないのか——は、写真1枚で、AI はあなたの居場所を突き止める（2026年） に地図化してある。ドキシングの連鎖が、実際に一人の人物の周りでどう組み上がっていくのかは、配信者は、どこで暴かれるのか——5つの事例とドキシング防御（2026年） に、そして削除ボタンを押しても何が生き延びるのかは、削除しても消えない——2026年、SNSの足跡はどこまで残るのか にある。

ChatGPT はあなたの何を知っているか——AI プライバシー監査（2026年）

Sat, 20 Jun 2026 00:00:00 +0000

私はチャット欄に文字を打つとき、ケーブルの見えないマイクの前で話すときと同じ構えでいる——録音されている、と前提する。いちばん用心した想定ほど、たいてい後になって正しかったと分かるからだ。ほとんどの人は、逆をやる。AI は落ち着いた語り口で答え、画面はいかにも内密に感じられ、だから私たちは、医者か弁護士にしか言わないことまで打ち明けてしまう——体の不安、書きかけの退職願、まだ形にならない計画、貼りつけるべきでないパスワード。画面は会話のように感じられるよう作られている。けれど裏側は、記録を残すように作られている。

その2つは別物で、両者の隔たりこそが、プライバシーの問題が宿る場所だ。米調査機関 Pew Research は2026年3月の調査で、米国の成人の50%が、AI の広がりについて期待よりも懸念のほうが強いと答えたことを示した——2021年の37%から上昇している。さらに以前の調査では、大多数が、自分の個人情報が不快に感じる使われ方をすると予想していた。それでも同じ道具が、設計上、検索がかつて集めたよりも親密な打ち明け話の流れを、集め続けている。検索のクエリは数語のキーワードだ。チャットは、追加質問つきの告白だ。その記録が後でどう扱われるかを決めるのは、返答の親しげな口調ではない。各社のデータ方針、保持期間、人による点検の仕組み、そして——いよいよ増えている——提供企業自身も制御できない裁判所の命令である。

だから、答える価値のある問いは「私の使う AI はプライバシーが守られているか」ではない——その立て方は、yes か no の宣伝文句を呼び込むだけだ。役に立つ問いはこうだ。それぞれの AI は、具体的に何を残すのか。「学習」を切ると、実際には何が止まるのか。そして、自分の手が届くどの設定をもってしても、なお残るものは何か。以下が、その監査である。提供企業ごとに、2026年なかば時点で。ただし正直に断っておく——これらの方針は頻繁に変わる。本記事の日付つきの記述は、各社の最新ページに照らして確かめるための出発点であって、それに取って代わるものではない。

画面が思わせること	仕組みが実際にやっていること
その場かぎりの、内密な会話	あなたのアカウントに紐づいた、記録
「削除」で消える	「削除」はあなたの目から隠すだけ。複製は残りうる
学習を切れば守られる	学習は使い道の一つ。保持・点検・開示は別の使い道
この返答は自分だけのもの	一部の事例は「モデル改善のため」人が読む

AI とのやり取りが、会話ではなく記録である理由
#

AI とのやり取りは、少なくとも5つの別々の使い道を持つデータの記録だ——モデルの学習、人による点検、保持、安全のための開示、そして音声や画像の生体（biometric）処理——そしてプライバシー設定がふつう左右するのは、そのうちの最初の一つだけである。「学習を停止する」を「内密にする」と取り違えること、それが中心的な誤りだ。残る4つの使い道はそれぞれ独自のルールで動き、しかも最も害の大きいものは、どのスイッチにも触れられないものだからだ。5つを一つずつ名指すこと——それが漠とした不安を、実際に点検できるチェックリストへと変える。

第1の使い道は学習だ。あなたの会話が、モデルの次の版を形づくる材料になる。第2は人による点検。品質を測り、不正利用（abuse monitoring）を捕らえるため、提供企業は訓練を受けた担当者や委託先に、実際の会話の一部を読ませる——主要な研究所はどこも、方針のどこかでこれを開示している。第3は保持。あなたがチャットを削除しても、複製は不正利用監視のシステム、バックアップ、訴訟に備えたデータ保全（legal hold）の中に、定められた期間——会話が問題ありと印をつけられればもっと長く——残るのがふつうだ。第4は開示。存在する記録は、召喚状（subpoena・法的開示命令）の対象になり、訴訟で提出され、保全命令のもとで引き渡されうる——そのどれも、あなたには制御できない。そして最も速く伸びている第5が生体処理だ。音声入力やアップロードした画像には、声紋や顔という、テキストにはない持続性を持つデータが乗っている。

この5つを切り分けて捉えれば、この記事の残りは、ただ表を埋める作業になる——AI ごとに、どの使い道が既定で動いていて、どれを切れて、どれを切れないか。規制という背景も動いている——EU の AI Act（EU の AI 規制法）は、2025年8月から汎用 AI（GPAI）に透明性の義務を課しはじめ、より広い条項は2026年8月2日に全面適用に達する——けれど規制は、遅く、ばらつきながら進む。だから現実の守りは、いまもこの表を知り、自分の手で動くことにある。

各 AI が、実際に何を残すのか
#

2026年なかば時点で、主要な消費者向け AI は、多くの人が見落とす既定を共有している——opt-out しないかぎり、あなたのやり取りで学習する。EU や英国などの地域的な例外はある——そしてどの AI も、削除後も一部のデータを保持し、人による点検の道を残している。下の表は横並びの要約だ。表のあとの各段で細かい条件を補う。一語のマス（「あり」）が、重要な条件を隠してしまうからだ。マスを読んだら、必ず注釈も読んでほしい。

AI	既定で学習する（消費者向け）	opt-out の経路	削除後も残るもの（特記）
ChatGPT（OpenAI）	あり	設定 → データ管理	不正利用監視の複製。legal hold 下のデータ
Claude（Anthropic）	あり（2025年9月以降、opt-out しないかぎり）	プライバシー / データ設定	安全上の印がついた内容。legal hold 下のデータ
Gemini（Google）	あり（「Gemini Apps Activity」経由）	Activity をオフに	人が点検した事例。最長3年保持
Copilot（Microsoft）	あり（opt-out しないかぎり。EU・英国は既定でオフ）	設定スイッチ	約18か月のローリング保持
Meta AI	あり（AI とのやり取り）	限定的。EU・英国の外では無し	広告・パーソナライズに利用

ChatGPT（OpenAI）。 無料・Plus・Pro の各アカウントでは、会話は既定でモデル改善に使われる。これを切るには設定 → データ管理へ進む。OpenAI 自身のヘルプページは、削除後も一定期間残る不正利用監視の保持について説明しており、同社は Team・Enterprise・API の顧客は既定では学習対象にしないと述べている。だが2025年のより大きな教訓は、設定ページの完全に外側にある——『New York Times』の訴訟（NYT 訴訟）で、OpenAI は出力データを保全するよう裁判所に命じられた。利用者が削除したつもりだった内容まで含めてだ。自分で動かせる設定は、自分では動かせない保全命令の前では、無力だ。

Claude（Anthropic）。 2025年9月下旬に発効した消費者向け規約の変更以降、Anthropic は Free・Pro・Max のやり取りで学習する——opt-out しないかぎり、データ設定からだ。ChatGPT と同じく、多くの人がいまも思い込んでいる「使うには明示の同意が要る」方式ではなく、「黙っていれば対象、止めたければ自分で切る」方式である。これに2つの注意が重なる——安全や方針の点検のために印をつけられた会話は、opt-out した後でも利用・保持されうること、そして何が印を引き起こすのかを Anthropic は公表していないこと。私は、自分の文章を Claude で書く書き手として、これを記している。だからこそ手心を加えない——本記事を含むどんな要約も鵜呑みにせず、最新のプライバシーページを自分で読んでほしい。

Gemini（Google）。 Google は学習をGemini Apps Activityの設定に結びつけている。これがオンだと、会話はサービス改善に使われうる。オフにすればそれは止まる——ただし、チャット履歴と引き換えだ。多くの人が見落とすのは、点検のための保持である。人による点検のために選ばれた会話の一部は、あなたのアカウントから切り離されるものの、Google のヘルプページによれば、通常の自動削除の期間とは無関係に、長い期間——最長3年——保持されうる。Workspace（職場・学校）のアカウントは、これとは別の、おおむねより厳しい規約で扱われる。

Copilot（Microsoft）。 Microsoft のプライバシー FAQ は、特定の利用者区分や opt-out した人を除き、Bing・MSN・Copilot をまたぐやり取りを AI の学習に使うと述べている——つまり消費者向けの既定は手を出さないものではない。ただし EU・英国・スイスの利用者は既定で対象外だ。消費者向けの履歴は、既定で18か月のローリング保持で動き、自分で消せる。一方、職場・学校アカウント内の Microsoft 365 Copilot は別の製品だ。プロンプトと応答は企業向け規約のもとで組織のデータとして扱われ、基盤モデルの学習には使われない。無料の消費者向けと職場向けは、たとえアイコンが同じに見えても、同じプライバシーの体系ではない。

Meta AI。 Meta は、AI とのやり取り——AI との会話と、公開投稿——を学習に使い、2025年後半の更新によれば、広告とフィードのパーソナライズにも使う。Meta は、友人や家族との非公開メッセージの内容はこれに使わないと述べている——だが Meta AI との会話は対象に入る。そして EU と英国の外では、広告利用からの opt-out は事実上なく、健康や政治といった機微なトピックの区分が除外されるだけだ。5つのうち、「AI」と「広告基盤」の境目がいちばん薄いのが、これである。

opt-out のプレイブック——とその限界
#

いちばん効く一手は、AI ごとの学習設定を見つけて、次に機微なやり取りをする前に、望む形に設定しておくことだ——ただし opt-out は、露出の流れを1本減らすものであって、会話を内密にするものではないと心得ること。それでもやる価値はある。学習に回る領域を縮めるのは現実の効果があり、2分の手間に見合う。ただ、流れを絞ることと、流れを止めることは別だ。以下が、2026年なかば時点での各 AI の経路である。いつもの注意つきで——必ず、実際の設定ページで確かめてほしい。

ChatGPT ——設定 → データ管理へ進み、モデル改善のオプションをオフにする。一度きりの機微な質問には、学習対象から外れ自動削除される Temporary Chat（一時チャット）を使う——ただし不正利用監視の保持は、なお一定期間あたることに注意。
Claude ——プライバシー / データ設定を開き、学習の設定をオフにする。2025年9月下旬以降、消費者向けの既定は「黙っていれば対象」だから、思い込まずに自分で選び取ること。
Gemini ——Gemini Apps Activityをオフにして学習利用を止める。これは進行中の履歴も消すこと、そして以前に選ばれた点検用の事例は、それ自体の保持期間のまま残ることを理解しておく。
Copilot ——設定でモデル改善とパーソナライズの設定をオフにする（EU・英国の外では、消費者向けの既定はやり取りを学習に含める）。本当に機微な仕事には、管理された Microsoft 365（職場）アカウントのほうが、無料の消費者向けアプリより手厚く扱われる。
Meta AI ——自分に適用される地域別の opt-out と広告設定を、ありったけ適用する。そして、この AI は5つのうち最も広告と一体化している、という前提で扱うこと。

どの一つの設定よりも効く、横断的な習慣が2つある。第一に、残されて困るものは打ち込まない——秘密、本人確認書類の全文、他人の個人データ。持続する守りは、モデルより手前、入力という地点にあるからだ。第二に、用途でアカウントを分ける——仕事の質問と体の不安が、一つのプロフィールに積み上がらないように。この習慣が属する、より広い心得については、EFF の Surveillance Self-Defense が地に足のついた参照先になる。

opt-out には届かないもの
#

学習からの opt-out は、これから先のモデル改善があなたのデータを使うのを止める。けれど、過去を消しはしないし、保持を取り消しもせず、流出を防がず、召喚状を止めることもできない——そして、いちばん結果が重いのは、まさにその4つだ。ここは宣伝ページが飛ばす節であり、そして、あなたが何を打ち込むかを決めるべき節である。4つのものが、どのプラットフォームのどの設定の届く先にも、ない。それらを名指すことが、この監査全体の目的だ。

第1は過去。すでに稼働中のモデルの学習に使われたものは、もう取り出せない。opt-out はこれから先に効くもので、決してさかのぼらない。第2は削除後の保持——不正利用監視の保管、バックアップ、legal hold は、あなたが決めていない期間で複製を残し、安全上の印がついた会話は、通常の履歴よりはるかに長く残りうる。第3は開示。存在する記録は開示の対象になり、2025年の OpenAI への保全命令が示したとおり、「私は削除した」は、裁判所が尊重する義務を負う状態ではない。第4は流出——世界一強固な社内方針も、データベースを守るセキュリティの強さまでしかない。そして保管された告白は、それを抱える者にとって、そのままリスクになる。

ここで規制が登場し、そして期待を冷静に保つべき場所になる。汎用 AI に対する EU AI Act の透明性の義務——文書化、学習データの要約、著作権上の義務——は2025年8月に始まり、2026年8月2日の全面適用に含まれる。これはシステムについての開示という点では、本物の前進だ。けれどそれは、あなたのデータの削除ボタンではない。そしてオープンソースのモデルは、より軽い義務を負う。ルールは時とともに最低水準を上げる。けれど、あなたがすでに打ち込んだことを、さかのぼって言わなかったことにはできない。導かれる結論は、地味だが揺るがない——流出せず、召喚されず、居座られて長く残ることもないデータは、そもそも欄に入れなかったデータだけだ。

偏った負担——声、似姿、そして誰が最も払うのか
#

音声と画像の入力は、危険度を一段上げる。声紋や顔の幾何という、持続的で、あなただけのものである生体データを乗せているからだ——そしてその取得からの害は、女性と、もとから狙われやすい人々に、最も重くのしかかる。テキストは書き直せる。だが漏れた声紋は、パスワードのように発行し直せない。AI が音声モードや画像の理解を加えるにつれ、監査は言葉の先、生体の層まで広げなければならない。最悪のケースが、いまそこに集まっているからだ。

仕組みは単純で、よく裏づけられている。誰かの声がわずか10〜15秒——OpenAI は自社の Voice Engine には15秒で足りたと述べた——あれば、いまや説得力のある合成音声を作るのに十分だ。だからこそ米連邦通信委員会（FCC）は2024年2月、自動音声通話（robocall）における AI 生成の声を、電話消費者保護法（TCPA）のもとで「人工的」なものと位置づけ、事前の同意を要すると裁定した。AI に日常的に自分の声を聞かせることは、なりすましが必要とするまさにその材料を、習慣的に差し出すことになる。アップロードした写真は、同じ理屈を顔に広げる。このどれも、提供企業が悪意をもって動くことを必要としない。ただデータが存在し、いつか漏れるか、悪用されさえすればいい。

そして負担は、等しく分け合われない。なりすまし、捏造された性的な画像、嫌がらせから晒し（doxxing）へと至る連鎖は、女性に、公の場に立つ専門職に、活動家に、不釣り合いに重くのしかかる——似姿を一種の資格証として扱うべき理由、そして組織的な晒しへの防御で私がたどったのと同じ非対称だ。そのリスクを負う人にとって、現実の指針は一般の利用者より厳しい——使わずに済む消費者向け AI には声と顔を入れない、テキストを選ぶ、そして生体の入力は、端末を離れた時点で事実上ずっと消えないものとして扱う。

結論——どこまで守りを固めるべきか
#

ふさわしい守りは、一つの主要設定ではなく、あなたの脅威モデルに応じて変わる——気軽な利用者には3つの習慣、専門職にはアカウントの分離とより厳しい階層、そして非対称なリスクを負う人は、消費者向け AI への音声と生体の入力を、永久に立ち入り禁止として扱うべきだ。ふさわしい水準は、あなたが誰から身を守ろうとしているかによる——万人向けの答えはなく、あるのは脅威モデルと、どの水準でも報われるいくつかの習慣だけだ。

特定の敵がいないなら： 使っている AI で学習をオフにし、機微な一度きりの質問には一時/シークレットのチャットを選び、秘密と本人確認書類は欄からまるごと外しておく。ほとんどの人にとって、現実的なリスクの大半はこれで覆える。
他人のデータや機微な仕事を扱うなら： 規約のより厳しい管理された職場アカウントを使い、用途でアカウントを分け、設定がどうあれ、打ち込んだものは後で保持・点検・開示されうると前提する。
非対称なリスクを負うなら——嫌がらせに直面する女性、活動家、公の場に立つ専門職：消費者向け AI には声と顔を入れず、どの AI に打ち明ける内容も最小限にし、生体の入力は消えないものとして扱う。

この3つすべての底に、どんな方針変更も覆せない原理が一つある——opt-out は、あなたのデータがどう使われるかを左右する。けれど、データが存在するかどうかを決めるのは、キーボードの前での自制だけだ。設定はぜひ点検してほしい——そのうえで、記録は設定が変わった後も残る、という前提で書いてほしい。実際、そうなのだから。

要点

会話ではなく記録： AI とのやり取りは、5つの別々の使い道を持つデータの記録だ——学習、人による点検、保持、法的開示、生体処理——そしてプライバシーの設定がふつう左右するのは、最初の一つだけ。
既定が揃う： 2026年なかば時点で、ChatGPT・Claude（2025年9月以降）・Gemini・Copilot・Meta AI はみな、opt-out しないかぎり消費者のやり取りで学習し——EU や英国などの地域的な例外はある——どれも削除後に一部のデータを保持する。
opt-out はこれから先だけ： 学習をオフにしても、すでにモデルを学習させたものは決して取り除けない。そして2025年の裁判所命令は、利用者が削除したと思っていた出力を保全するよう OpenAI に求めた。
召喚状にも流出にも届く設定はない： 保持の保管、legal hold、セキュリティ侵害は、あらゆる消費者向け設定の先にある——持続する制御は、秘密をそもそも打ち込まないことだ。
声と似姿は生体データ： 数秒の音声が説得力のある声のクローンを作りうる。このリスクは女性・活動家・公人に最も重くのしかかり、彼らは消費者向け AI に声と顔を入れるべきではない。

よくある質問
#

ChatGPT は、私の会話をモデルの学習に使いますか？
#

2026年なかば時点では、無料・Plus・Pro のアカウントで、既定では使います——これは設定 → データ管理でオフにできます。オフにすると、これから先の学習利用は止まりますが、すでに使われた過去のデータは消えません。OpenAI 自身のページも、削除後も一定期間残る不正利用監視の複製について説明しています。ビジネス向けの階層（Team・Enterprise・API）は、既定では学習対象になりません。こうした方針は変わるので、どんな要約にも頼らず、OpenAI のデータ管理ページで最新の設定を確かめてください。

AI とのやり取りを削除すれば、本当に消えますか？
#

たいていは、完全には消えません。削除は、目に見える履歴から会話を取り除きますが、複製は不正利用監視のシステム、バックアップ、そして legal hold の中に、あなたが制御できないそれぞれの保持期間のまま、残るのがふつうです。安全の点検のために印がついた会話は、さらに長く残りえます。『New York Times』対 OpenAI の2025年の保全命令は、裁判所がかかわるとき「削除した」がいつも永久を意味するわけではないことを、最もはっきり示した例です。

既定でいちばんプライバシーが守られる AI はどれですか？
#

2026年なかば時点での正直な答えは「既定では、どれも守られない」です——ChatGPT・Claude（2025年9月の消費者規約変更以降）・Gemini・Copilot・Meta AI はみな、opt-out しないかぎり消費者のやり取りで学習します。EU や英国などの地域的な除外はあります。意味のある差は、自分で動かねばならない細部にあります——opt-out がどこにあるか、人が点検した事例がどれだけ保持されるか、安全の印が何を上書きしうるか。どの提供企業も、削除後に一部のデータを保持し、人による点検と法的開示の道を残しています。だから「既定で守られる AI」を探すこと自体が見当違いで——opt-out し、打ち明ける量を減らすことが、あなたが実際に握れる制御です。

音声モードを使ったり、写真をアップロードしたりするのは安全ですか？
#

テキストより高リスクなものとして扱ってください。音声と画像には、声紋や顔の幾何という、持続的で個人を一意に特定する生体データが乗っていて、数秒の音声が、説得力のある声のクローンを作るのに十分なことがあります。データが存在すること自体がリスクで、これは提供企業の意図とは無関係です。なりすましや嫌がらせのリスクが高いなら、テキストを選び、使わずに済む消費者向け AI には、声と顔を入れないでください。

EU AI Act は、AI のプライバシーを守ってくれますか？
#

いいえ、改善するのは透明性であって、個人データの削除ではありません。汎用 AI に対する透明性の義務——技術文書、学習データの要約——は2025年8月に始まり、Act の2026年8月2日の全面適用に含まれます。これはシステムを理解する助けになります。けれど、あなたがすでに提出したデータをさかのぼって取り除きはしませんし、オープンソースのモデルはより軽い義務を負います。規制は時とともに最低水準を上げますが、何を打ち込むかについての自制の、代わりにはなりません。

#	出典	URL	アーカイブ
1	OpenAI——Data Controls FAQ	https://help.openai.com/en/articles/7730893-data-controls-faq	https://web.archive.org/web/*/https://help.openai.com/en/articles/7730893-data-controls-faq
2	Anthropic——Privacy Policy	https://www.anthropic.com/legal/privacy	https://web.archive.org/web/*/https://www.anthropic.com/legal/privacy
3	Anthropic——Updates to Consumer Terms and Privacy Policy（2025年）	https://www.anthropic.com/news/updates-to-our-consumer-terms	https://web.archive.org/web/*/https://www.anthropic.com/news/updates-to-our-consumer-terms
4	Google——Gemini Apps & your data	https://support.google.com/gemini/answer/13594961	https://web.archive.org/web/*/https://support.google.com/gemini/answer/13594961
5	Microsoft——Copilot privacy FAQ	https://support.microsoft.com/en-us/microsoft-copilot/privacy-faq-for-microsoft-copilot	https://web.archive.org/web/*/https://support.microsoft.com/en-us/microsoft-copilot/privacy-faq-for-microsoft-copilot
6	Meta——Privacy Policy	https://www.facebook.com/privacy/policy/	https://web.archive.org/web/*/https://www.facebook.com/privacy/policy/
7	European Commission——Regulatory framework on AI（AI Act）	https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai	https://web.archive.org/web/*/https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
8	Pew Research——Key findings about how Americans view AI（2026年3月）	https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/	https://web.archive.org/web/*/https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/
9	NYT 対 OpenAI——裁判所の保全命令（報道）	https://decrypt.co/323950/openai-challenges-court-order-user-data-nyt-lawsuit	https://web.archive.org/web/*/https://decrypt.co/323950/openai-challenges-court-order-user-data-nyt-lawsuit
10	FCC——AI-Generated Voices in Robocalls Are Illegal（2024年）	https://www.fcc.gov/document/fcc-makes-ai-generated-voices-robocalls-illegal	https://web.archive.org/web/*/https://www.fcc.gov/document/fcc-makes-ai-generated-voices-robocalls-illegal
11	Electronic Frontier Foundation——Surveillance Self-Defense	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/

この監査は、より大きな地図の片割れだ。AI を一級の敵として扱う脅威モデル——そしてそれが壊す前提——を描いたのが AI時代のOPSEC——脅威モデルを組み立て直す であり、モデルが公開された文章から身元をどう推論するかの深掘りが AI 非匿名化——推論が、あなたの匿名性を解いていく だ。記録が、あなたが打ち込んだものではなく組織から奪われたものであるときの併読すべき手順書は、国家があなたのデータを漏らす日。そして上で触れた生体の賭け金については、あなたの顔と声は、いまや資格証だ を参照。

AI 非匿名化——推論が、あなたの匿名性を解いていく（2026年）

Wed, 17 Jun 2026 00:00:00 +0000

私は仮名で書いている。だから、この記事で扱う攻撃こそ、私が誰よりも考え続けている脅威だ。あらゆる仮名の土台には、ひとつの素朴な前提がある——名前さえページに載せなければ、「Cora Aegis」とキーを打っている人物との隔たりは、容易には埋まらないままだ、と。デジタル生活の20年間、その前提はおおむね保たれていた。隔たりを埋めるには、人間が何千もの投稿を手作業で読み込まねばならなかったからだ。省略による匿名——ただ名前を伏せておくこと——は、ほとんどの人にとって、普段はそれで間に合っていた。

それは、もう十分ではない。しかもその理由は、仮定ではなく実測されている。ICLR 2024 で発表された査読済みの研究『Beyond Memorization』で、ETH Zurich の研究者たちは、市販の言語モデルが、ありふれた Reddit のテキストから、居場所・収入・性別といった属性を直接推論してみせた——top-1 で最大85%、上位3つの推測のいずれかが当たる範囲では最大95.8%の精度に達した。2026年の後続の preprint（査読前）は、属性から身元へと踏み込む。あるエージェント型のモデルが、Hacker News ユーザーの集団のうち67%を、本物の LinkedIn プロフィールへ、90%の精度で結びつけた——陽性とした一致の10件中9件が正しかった——しかも1人あたりおよそ1〜4ドルで。アカウントの紐づけに人間が何時間も費やさねばならない——その摩擦こそが、あなたを守っていた。そして AI が取り除いたのは、まさにそれだ。

では、仮名はいまや何によって守られるのか。削除ボタンではない。投稿を1件取り下げても、推論はそれを生き延びる。守り方は、玄関の鍵がもう掛からなくなったどんなシステムでも同じだ——「言っていないから大丈夫」を防御とみなすのをやめ、散らばった無害そうなシグナルを名前へと変える連鎖を、断ち切りにかかる。以下が、その連鎖をひとつずつ追ったものであり、なぜオンチェーンの Bitcoin プライバシーではそこを守れないのか、そして守れるのはどんな区画化（コンパートメント化）なのか、である。

一見、無害なもの	実は何が漏れるか	モデルはそれをどう使うか
使い回したユーザー名や、文章の癖	「別々」のはずの2つの身元のつながり	あなたのアカウントを1つのプロフィールへ束ねる
「おはよう」の投稿時刻、土地の言い回し	あなたのタイムゾーンと街	住所を語らせずに、居場所を絞り込む
趣味、通勤の話、勤め先のほのめかし	収入帯、生活リズム、職場	候補プロフィールと照合する
写真の背景、あるいはメタデータ	正確な場所と時刻	テキストがすでに匂わせた推測を、裏づける

The machine deanonymization chain: scattered public posts are turned into a name through extract, search, and verify stages — break any one link to fall below the attacker's cost budget.

匿名を崩すのは高くついた——そのコストを、AI が安くした
#

非匿名化（deanonymization）とは、仮名や匿名のアカウントを、現実の身元へとたどり直す作業だ——たった一度の口を滑らせではなく、数多くの小さなシグナルをまたいだ相関と推論によって。まず理解すべきは、これが賢くなったというより、安くなったということだ。手口——アカウントを相関させ、語られていない事実を推論し、文体を照合する——は古くからある。変わったのは、いまや機械が、人間の請求時間ではなく、1人あたり数ドルのコストでそれをやってのける、という点だ。この値崩れこそが、すべての核心だ。なぜなら、匿名のほとんどは、もとより暗号的に堅固だったわけではないからだ。それは、誰もわざわざやる気にならない、という事実に守られていたにすぎない。

数字が、この変化を具体的にする。ETH Zurich チームの『Beyond Memorization』（ICLR 2024）は、現実の Reddit プロフィールに対してモデルを試し、ただ自然に書くだけで、どこに住みいくら稼ぐかをモデルが推測するに足る量が漏れること、そして従来の緩和策——テキスト匿名化ツールやモデルの「アラインメント」——では確実には止まらないことを見いだした。2026年の preprint『Large-scale online deanonymization with LLMs』（著者に当時 Anthropic に所属していた研究者を含み、まだ査読を経ていない）は、さらに踏み込む。自律エージェントとして組まれたこのシステムは、Hacker News のコメントから手がかりを引き出し、合致する人物を探し、候補を LinkedIn に照らして検証した——そして67%のユーザーを90%の精度で言い当て、実験の総コストは2000ドル未満だった。

この2つの結果を併せて読めば、結論は居心地が悪いが明快だ——守っていたのはコストであり、そのコストが消えた。動機ある敵は、もはやあなた個人を気にかける必要すらない。フォーラムの全員に攻撃を走らせ、誰が網からこぼれ落ちるかを見ればいい。

非匿名化の連鎖——機械は投稿から名前へどうたどり着くか
#

機械による非匿名化は、抽出・検索・検証という3つの段階の連鎖として走る。そして、その全段階を打ち破る必要はない——どこか1本の鎖を、あなたのプロフィールが敵のかける手間の割に合わなくなる程度まで、断てばよい。連鎖を、切り離せる段階として見ること——それこそが、漠とした恐れ（「AI に見つかってしまう」）を、守れる地図へと変える。なぜなら、段階ごとに弱点が違うからだ。

第1段階——抽出と埋め込み。 モデルはあなたの公開された文章を読み、構造化されたシグナルを引き出す——言い回しや投稿時刻からの、おおよその地域。語彙からの、職業。買ったものの言及からの、収入帯。そして最も根強いものとして、文体の指紋——あなたの書き方の統計的な形だ。どれも、あなたがそれを口にした必要はない。この段階だけで、居場所・収入・性別が平文から露出すること、その証拠が ETH Zurich の研究だ。

第2段階——検索とランク付け。 それらのシグナルが、候補となる身元の集団——他のプラットフォーム、公開プロフィール、流出データセット——への問い合わせになり、システムは、あなたが誰である可能性が最も高いかを順位づける。規模が効いてくるのは、この段階だ。数万の候補にまたがる埋め込み検索は安く、しかも緩やかに劣化する——データが薄いときも、失敗するのではなく、絞り込みが甘くなるだけだ。

第3段階——検証と紐づけ。 推論モデルが最有力の候補を取り上げ、突き合わせる——この LinkedIn の職歴は、あの Reddit 投稿の趣味と噛み合うか。時系列は整合するか——そうして1つが生き残るまで照合する。2026年の preprint で、Hacker News から LinkedIn への一致を生んだのが、このエージェントによる段階だ。そしてここは、ある安全性の前提が試される場所でもある。「この人物を非匿名化せよ」というあからさまな要求を、拒否訓練（refusal training）は確かに捕らえる——だが、同じ目的を、一見無害な小さなタスクの連鎖として追われたときよりも、はるかに確実に、だ。

実践的な教訓はこうだ——連鎖は、あなたが最も一貫している場所で最も強い。文脈をまたいで同じハンドル、同じ言い回し、同じ投稿リズムを保つこと、それこそが第2段階につなぎ目を見つけさせる。意図して持ち込んだ不一致こそが、それを断つ。

完璧な Bitcoin の仮名でも、なお匿名ではない理由
#

オンチェーンのプライバシーと、テキスト推論のプライバシーは、別々の脅威モデルだ。一方を解く道具は、もう一方には何もしない。CoinJoin、Silent Payments、Monero は取引グラフを守る——だが、あなたの仮名をあなたに結びつける、フォーラムの投稿、サポート問い合わせ、SNS の返信には、いっさい触れない。これは、Bitcoin プライバシーの指南が最もよく見落とす隔たりだ。匿名をオンチェーンの性質として扱うが、名乗りを上げた仮名にとって、最も安い攻撃は、まるごとオフチェーンにある。

どういうことか、具体的に考えてみよう。あなたは、コインと身元のつながりを完璧に断てる——coinjoin した UTXO、支払いごとの新規アドレス、どこにも KYC なし。だが、ノードの設定やタイムゾーンや持論を、モデルがあなたの他の文章と照合できる声で語る仮名アカウントを併せて運用していれば、そのどれも意味をなさない。前節の連鎖は、ブロックチェーンを読みはしない。読むのはあなただ。チェーン分析とテキスト推論は、並べて走らせることさえできる——一方はあなたの取引をクラスタにまとめ、もう一方はそのクラスタに人物を貼りつける——けれど、オフチェーン側が成り立つのに、オンチェーン側は要らないのだ。

だから正しい心の地図は、「あれか、これか」ではなく、足し算だ。オンチェーンのプライバシーは必要で、やる価値がある。ただそれは、名指される脅威を抱える人にとって、十分ではないというだけだ。Bitcoin の仮名を保つなら、次節のテキスト OPSEC こそ、プライバシーコインをめぐる議論がたいてい置き去りにする、もう半分の仕事である。

プライバシー技術	何を守るか	何には触れないか
CoinJoin / Silent Payments	オンチェーンの取引グラフ	フォーラム投稿、文体、投稿時刻
Monero / プライバシーコイン	オンチェーンの金額・送り手・受け手	使い手を名指すオフチェーンのテキスト
VPN / Tor	ネットワーク層の IP 相関	どこであれ、あなたが実際に書くもの
アカウント分離だけ	あからさまな名前のつながり	パターンから推論されるつながり

連鎖を断つ——AI 時代の区画化プレイブック
#

効くのは、どれか1件の投稿ではなく、推論の連鎖そのものを狙った区画化だ——あなたの複数の文脈が、紐づけられる特徴をできるだけ共有しないようにし、第2段につなぐものを与えないこと。削除はこのリストに入らない。投稿を1件消したところで、あなたをさらしたパターンまで消えることはめったになく、完全に有効な制御は、公開という地点での予防だけだからだ。

身元を、底まで分ける。 仮名は、最も分離の甘い層と同じ強さしか持たない——別のユーザー名、別のメール、別の端末またはブラウザのプロファイル、別のネットワーク。共有したインフラは、あらゆるつなぎ目のなかで最も容易なものだ。
文体の指紋を、ばらつかせる。 これは、ほとんどの人が飛ばす防御だ。身元ごとに語り口を変える——一方は堅く、もう一方は砕けて——そして、モデルがあなたの文章をクラスタにまとめるのに使う、決まり文句、絵文字の癖、句読点の癖を避ける。覚えやすい言い回しを2つのアカウントで使い回すこと、それだけで、他のあらゆる用心が台無しになりうる。
タイミングを、不規則にする。 実際のタイムゾーンで毎日決まった時刻に投稿することは、居場所と生活リズムのシグナルだ。活動を散らし、ゆらぎを加え、「匿名」のアカウントに、自分の街の勤務時間を守らせないこと。
手放す前に、メタデータを削ぐ。 写真の EXIF 位置情報、文書のプロパティ、一貫した ISP の相関は、モデルが喜んで使う裏づけだ。発生源で取り除くこと。
仮名を、定期的に引退させる。 身元は、長く生きるほど、推論できる履歴を溜め込む。リスクの高いペルソナでは、ハンドルを定期的に引退させて立て直すことが、敵が積み上げてきた土台を白紙に戻す。

どれも風変わりなものではない。だが束ねれば、フォーラムで最も安く割り出せるプロフィールであることと、攻撃が素通りしていくプロフィールであることの、その違いになる。道具の層——ノーログの VPN、別立てのメールボックス、身元分離のユーティリティ——については、EFF の Surveillance Self-Defense が地に足のついた参照先になる。そして原理はこのサイトが自らに課すのと同じだ。リンクを実際に断つ、最小限の道具だけを使い、チェックリストを追いかけるのではなく、それを正直に開示すること。

AI 以前、これには人手と、長い時間がかかった
#

何が変わったのかを、正確に言っておく価値がある。なぜなら、誰もが覚えている象徴的な事例は、そもそも AI ではなかったからだ——どれも、遅く、手作業で、人間の仕事だった。AI が持ち込んだ変化は、新しい能力というより、それらの事例がかつて要したコストと根気の、除去なのだ。古い事件を正直に枠づけることこそが要点だ——それらは、かつてどれほどの摩擦があなたを守っていたか、したがってその摩擦が消えるとき何を失うのかを、示してくれる。

Dream として知られる配信者は、2021年、ファンが台所の写真を Zillow の不動産情報と照合して特定された——人間の目と、公開データベース。推論モデルなど影もない。2022年、活動家 Keffals への嫌がらせキャンペーンは、手作業で集めた OSINT とフォーラムの集団的な労力で動いていて、機械ではなかった。2023年、ある学生たちがキャンパスでの声明をめぐって晒された一件は、手作業のアーカイブ調査と、有料のターゲティング広告で動いていた。どれも、動機ある人々と、現実の時間を要した。それが、ほとんどの仮名を守ってきたコストだった——敵は、何時間も費やすほどにそれを望む必要があったのだ。

非匿名化の連鎖は、そのコストを取り払う。かつてフォーラムの群衆が1人の標的に何日もかけてやったことを、いまやエージェントが、コミュニティ全体に対して、1人あたり数ドルで試みうる——しかも、疲れも飽きもせずに。そしてこれは、均等には降りかからない。なりすまし、捏造された性的な画像、嫌がらせから晒しへと至る連鎖は、女性に、そして動機ある敵対者を抱える人に、不釣り合いに重くのしかかる。だから推論への耐性は、単なるデータ衛生ではなく、身体と評判の安全にかかわる問題なのだ。前節の防御が最も効くのは、まさに、この攻撃の、手間のかかる旧来のやり方がすでに標的にしてきた、その人々にとってなのである。

結論——区画化は、実際どこまで必要か
#

ふさわしい労力の水準は、あなたが誰から身を守ろうとしているかに見合うものだ——単一の設定はなく、あるのは脅威モデルだけだ。

特定の敵がいないなら： 最も効く一手は、言語と時間にまつわるものだ。分けておきたいアカウントどうしで、目立つハンドルや文体を使い回さないこと。そして「匿名」の身元を、自分の時計に合わせて投稿しないこと。理由ができるまで、本格的なツールは後回しでいい。
本物の仮名を保つなら——クリエイター、書き手、名前と仮名が決して結びついてはならない誰か：端末・ネットワーク・言語をまたいで容赦なく区画化し、プライバシーのオンチェーン側は、オフチェーン側に何もしないと心得ること。
非対称なリスクを抱えるなら——ハラスメントに直面する女性、活動家、公の場に立つ専門職：言語的なばらつきと、経路外での検証を、「任意」ではなく必須として扱い、身元の引退を、必要になる前に計画しておくこと。

この3つすべてに、機械が登場する前に成り立っていた真実が、なお成り立つ——事後に削除して安全にたどり着くことは、確実にはできない。できるのは、自分が実際に抱える敵をモデル化し、自分が守り抜ける鎖でその連鎖を断ち、機械が喜んで取っておきたがるものを、より少なく公開することだけだ。

要点

推論： 言語モデルは、ありふれたテキストから、居場所・収入・性別を top-1 で最大85%の精度で推論する（Staab ほか、ICLR 2024）——省略による匿名は、もう保たない。
規模： あるエージェント型モデルが、Hacker News ユーザーの67%を、その LinkedIn プロフィールへ、90%の精度で、1人あたりおよそ1〜4ドルで結びつけた（Lermen ほか、2026年の preprint〔査読前〕）——人間の摩擦は消えた。
独立したベクトル： オンチェーンのプライバシー（CoinJoin、Silent Payments、Monero）は取引グラフを守るが、仮名を人物に結びつける、フォーラム投稿や文体は守らない。
防御： 連鎖を断つ——端末とネットワークをまたいで身元を分け、文章の語り口をばらつかせ、投稿時刻を不規則にし、メタデータを削ぐこと。投稿を1件消しても、推論できるパターンは消えない。
不均等な害： 嫌がらせを動機とする非匿名化となりすましは、女性と公の仮名に最も重くのしかかる——だから、経路外での検証と言語的な分離は、任意ではなく必須だ。

よくある質問
#

AI は本当に、匿名の投稿から私を非匿名化できますか？
#

しばしば、できます。省略による匿名——投稿に名前を載せないこと——は、推論に対して脆弱です。モデルは、あなたの書き方や投稿の時間帯のパターンから、居場所や勤め先などの属性を導き出し、それを公開プロフィールに照合できるからです。査読済みの検証（Staab ほか、ICLR 2024）では、モデルは平文の Reddit テキストから、個人の属性を top-1 で最大85%の精度で推論しました。強い「紐づけられなさ」は、名前を伏せることからではなく、区画化——別々のユーザー名・端末・ネットワーク、そしてばらつかせた文体——から生まれます。

古い投稿を削除すれば、推論は止まりますか？
#

おおむね、止まりません。投稿を1件取り除いても、あなたをさらしたパターンまで消えることはめったにありません。推論は、一貫したシグナル——文体、投稿時刻、繰り返し触れる話題——に頼っていて、それはあなたが公開したものすべてに散らばっているからです。削除は、ぎりぎりのところで素材を減らせはしますが、持続的な対処は、後始末ではなく、公開という地点で、紐づけられるシグナルを生まないことです。

CoinJoin や VPN は、これから私を守ってくれますか？
#

それらは別の層を守ります。CoinJoin やプライバシーコインはオンチェーンの取引グラフを、VPN や Tor はネットワーク層の IP 相関を守ります。けれどそのどれも、モデルが仮名を人物に結びつけるために読む、フォーラム投稿、サポートのやり取り、返信には触れません。使う価値はあり、ただそれだけでは十分でない——この記事のテキスト OPSEC が、補い合うもう半分です。

非匿名化のコストを最も押し上げるのは何ですか？
#

言語的・文脈的な区画化です。非匿名化の連鎖は、あなたが最も一貫している場所で最も強い。だから最も効く習慣は、結びついてはならない身元どうしに、文体・投稿スケジュール・共有インフラを共有させないことです。地味ですが、これこそ、自動化された攻撃がいま要する数ドルより上へ、敵のコストを実際に押し上げるものなのです。

#	出典	URL	アーカイブ
1	Staab ほか——“Beyond Memorization: Violating Privacy via Inference with Large Language Models”（ICLR 2024）	https://arxiv.org/abs/2310.07298	https://web.archive.org/web/*/https://arxiv.org/abs/2310.07298
2	Lermen ほか——“Large-scale online deanonymization with LLMs”（arXiv preprint〔査読前〕、2026年）	https://arxiv.org/abs/2602.16800	https://web.archive.org/web/*/https://arxiv.org/abs/2602.16800
3	Simon Lermen——“Large-Scale Online Deanonymization”（著者による解説、2026年）	https://simonlermen.substack.com/p/large-scale-online-deanonymization	https://web.archive.org/web/*/https://simonlermen.substack.com/p/large-scale-online-deanonymization
4	Electronic Frontier Foundation——Surveillance Self-Defense（脅威モデル化と区画化のガイド）	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/

このサイトの他の2本が、ここに直接つながる。AI が壊す4つの前提——推論はそのひとつだ——を地図にしたのが AI時代のOPSEC——脅威モデルを組み立て直す であり、本記事はその推論の深掘りにあたる。そして推論は、あなたがこれまで公開したものすべてを糧にするため、削除を実際に何が生き延びるのかという点検は、削除しても消えない——2026年、SNSの足跡はどこまで残るのか にある。相関されるデータが、あなたが投稿したものではなく、組織から奪われたものであるときの手順書は、国家があなたのデータを漏らす日。職場の内側で適用される推論については、勤め先の Slack 監視は、実際に何を見ているのか を参照。

求職者を狙うドキシング——応募前のデジタル足跡監査（2026年）

Thu, 30 Jul 2026 00:00:00 +0000

資金について：CypherpunkGuide は監視型広告を載せない。広告ネットワーク、追跡用ピクセル、スポンサー記事も使わない。運営を支える収益源は公開している。現在は読者からの寄付、将来は購読料と編集方針に合うアフィリエイトリンクである。私たちが向き合うのは、個人情報を集めて売るデータブローカーや身元調査会社ではなく読者だ。

履歴書は、職歴を書いた文書であるだけではない。氏名、居住都市、メールアドレス、電話番号、学校、以前の勤務先、在籍時期を小さくまとめた、身元確認の手掛かりでもある。採用担当者はそれを使って職務プロフィールを探せる。ドキシングとは、個人をさらしたり標的にしたりする目的で身元情報を公開する行為だ。同じ手掛かりが、第三者の主張を応募者本人へ結び付ける。身元調査会社は公開記録を正しく、あるいは誤って照合する。応募者の適性や経歴を示す同じ事実が、ウェブ上に散らばる情報同士の照合も容易にするのだ。

投稿を非公開にするだけでは、一部しか解決しない。SNSに残る足跡は削除後も生き残り、敵の視点で行う自己監査は自分のアーカイブが漏らすものを見つけられる。危険は抽象論ではない。2023年には、差出人不明の郵便物が、9団体との関係を疑われた学生26人の氏名を載せたと報じられた。本稿が扱うのは、外部の情報が、応募書類上の人物へどう結び付けられるのか、そして面接前に本人が何を検証できるかである。

私たちは15行の検証表を作った。勤務先へ届いた公開投稿、争われている団体所属を個人へ結び付けた組織的ドキシング、米国の規制当局が不正確だと申し立てた商用報告書について、計12の証拠項目を再構成し、日本での応募者情報の取扱いを検証する3項目を加えた。刺激的な見出しを事実へ変えないため、各行を「確認済み」「報道に基づく」「当局の申立て」「未確認」「公的機関の案内」に分けている。応募者の露出経路検証表はダウンロードして検証できる。米国の事例は帰属の失敗を示す証拠として使い、米国法上の手続を日本へ移植しない。

この方法の目的は、根拠の弱い照合を見つけることだ。完全に消せるとは約束しない。

デジタル足跡が採用判断の材料になるまで
#

検索結果が採用に影響するのは、誰かがそれを応募者本人へ結び付け、判断に使ったときだ。「起点 → 追跡 → 帰属判断 → 意思決定」の4段階を監査せよ。ページが見つかっただけでは、それが自分のものだという証拠にならない。

起点（Anchor）： 応募書類には、氏名、メール、電話番号、都市、学校、勤務先など、変わりにくい事実が含まれる。
追跡（Pivot）： 検索する側が起点を使い、利用者名、画像、団体名簿、公開記録、人物検索サービスの報告書をたどる。
帰属判断（Attribution）： 一致する事実を根拠に、その結果が応募者のものだと判断される。
意思決定（Decision）： 帰属させた情報が、面接、内定、不採用などの採用判断に影響する。

これを**応募者との情報照合の4段階（Applicant Identity-Attachment Chain）**と呼ぶ。混同されがちな3つの経路を分けるための枠組みである。

経路	結び付けを生むもの	弱点	応募者にとって有効な対処
公開情報の直接検索	採用担当部署が公開ウェブを自分で検索する	同姓同名、欠けた文脈、古いページ	明確な職務プロフィールを用意し、誤照合を記録する
組織的ドキシング	組織的な活動が氏名、所属、勤務先の連絡先を公開する	未検証の関係が事実として広められる	証拠を残し、訂正を求め、短い確認資料を用意する
第三者の調査・人材サービス	雇用主または外部事業者が応募者情報を収集・照合する	元データの誤り、別人との誤照合、目的外の情報	事業者の役割、利用目的、取得元を特定し、客観的な誤りには開示・訂正を求める

経路は重なることがある。しかし、対処は同じではない。公開ページの誤りには掲載元への訂正依頼が必要で、採用企業や外部事業者が保有する応募者情報には、それぞれの窓口へ開示・訂正を求める。個人情報保護法上の訂正で客観的な記録を直せても、拡散したスクリーンショットや採用担当者の主観的な評価まで自動で書き換わるわけではない。まず、誰がどの情報を扱ったかを特定する。

記録で確認できる3つの失敗経路
#

3事例が示すのは、それぞれ別の失敗である。争われた団体所属、採用側の組織内へ届いた公開投稿、記録を誤解を招く形で示したと当局が申し立てた商用報告書だ。事実も対処も混ぜてはならない。

ハーバード大学、2023年——所属が身元と同一視された
#

2023年10月、ハーバード大学の30を超える学生団体によるものとされた声明をきっかけに、各団体と関係がある人物を特定する動きが起きた。『Harvard Crimson』はその後、ドキシングサイト、学生の氏名と顔を表示した車両、そして9団体との関係を疑われた学生26人を名指しする差出人不明の郵便物を報じた。声明との関係を否定した人もおり、名指しされた団体をすでに退会していた人もいたという。匿名の大学院生1人は、企業の調査後に内定を取り消されたと同紙へ語った。

これらは別々の事実であり、分けて読むことが欠かせない。報道は、車両、特定のサイト、特定の郵送物が内定取消しを引き起こしたとは立証していない。名簿に載ったことも、その学生が声明を書いた、承認した、あるいは知っていた証拠にはならない。この事例から比較的確かに言えるのは、学校と氏名から公に出た主張をたどる手掛かりとして団体所属が使われ、しかもその帰属自体が争われていた、という限定された仕組みである。

応募者が学ぶべきなのは、あらゆる所属を隠すことではない。検索結果が、根拠から言える範囲を超えて所属を断定していないか確かめることだ。断定が強すぎるなら、訂正を求める前に、主張、URL、日付、反証資料を保存する。

Cisco、2009年——公開投稿が社内の人間関係を通った
#

2009年、Network Worldは、公開された短いやり取りを記録した。Ciscoへ入社予定だった人物が、提示された給与には触れつつ、仕事内容への不満を述べる投稿をした。Cisco関係者は公開の返信で、採用責任者は誰かと尋ねた。このやり取りはすぐに「Cisco Fatty」の話として広がった。

確認できるのは情報が届いた経路であり、雇用上の結末ではない。出典は、Ciscoが内定を取り消したとは立証していない。解雇や内定取消しが確定した話として扱えば、本稿が防ごうとしている帰属の誤りを繰り返すことになる。

この事例は、直接経路に必要な情報がどれほど少ないかを示す。公開投稿に会社名があったため勤務先が起点になり、Cisco関係者が採用責任者を探す公開返信をした。情報の想定上の宛先は、採用責任者だったのである。身元調査会社も、非公開アカウントへのアクセスも要らなかった。公開投稿は、組織内の人間関係を通って採用の意思決定者へ届きうる。

FTC、2023年——報告書が記録へ誤った意味を付ける
#

3つ目は仕組みが異なる。2023年、米連邦取引委員会（Federal Trade Commission、FTC）は、TruthFinderとInstant Checkmateが身元調査報告書の正確性について利用者を欺き、FCRAに違反したと申し立てた。当局によれば、一部の宣伝用警告表示は交通違反切符を犯罪歴または逮捕歴のように示し、第三者から得たデータを検証していなかったとされる。2023年10月11日に登録された署名済みの合意命令は、両社に共同で580万ドルの民事制裁金を科した。両社は、裁判管轄に必要な範囲を除き、基礎となる申立てを認めも否定もしていない。

これは、単に検索結果が悪いという問題ではない。身元情報をまとめる事業者から雇用主が消費者報告書を取得する場合、米国連邦法は通常、正式な手順を定める。報告書の取得前には開示と書面による同意、不利益措置の前には報告書の写しと権利概要、判断後には通知と異議申立ての案内がある。州法や地方条例が要件を追加することもある。

経路	確認できる入力	不明または争われている点	防御に使える証拠
ハーバード大学の報道	氏名を特定・公開する活動、団体名簿、郵送で名指しされた26人、匿名で報告された内定取消し1件	各人が所属していたか、何が雇用上の結果を引き起こしたか	団体記録、日付入りスクリーンショット、訂正のやり取り
Ciscoの報道	公開投稿とCisco関係者の返信	内定が取り消されたか	元投稿の文脈、内定状況、日付入りの連絡記録
FTCの事件	当局の訴状、事件記録、共同での制裁金を定めた署名済み命令	問題とされた行為は申立てであり、認められた事実ではない	消費者報告書、元になった記録、異議申立て資料、雇用主からの通知

4段階で15行の検証表を読み直すと、氏名検索でもCisco型の本人投稿は見つけられる。しかし、ハーバード大学で争われた所属は解決できず、身元調査会社が別人の記録を付けたかどうかも分からない。「自分の名前をGoogleで検索する」は良い初手だが、それだけでは監査にならない。

雇用主のSNS調査から何が分かるか
#

2026年の実態を一つの割合で表すことはできない。調査ごとに対象者が異なり、採用候補者の発掘、候補者についての情報収集、正式な審査も混在する。数字は、どの雇用主もそうすると予測するためでなく、公開情報の調査が現実にありうると知るために使う。

米国人材マネジメント協会（Society for Human Resource Management、SHRM）が2015年に行った調査には、全体で人事担当者410人から回答があった。候補者審査に関する設問の有効回答を集計すると、**組織の43%が公開SNSまたはインターネット検索を候補者審査に使っていた。その方法を使う組織のうち、見つけた情報を理由に候補者を不採用にしたことがある割合は36%**だった。これは過去の基準値であり、現在の普及率ではない。

別のExpress Employment Professionalsが委託した2022年のHarris Poll調査は、米国で採用判断をする立場の1,002人へ質問した。候補者の調査にSNSを使うとの回答は70%、全候補者に使うとの回答は17%、調査を社内で行うとの回答は**80%だった。さらに、採用を見送る理由になる内容を見つけたことが一度もないとの回答は51%**だった。この調査の定義では、SNS調査を行う割合が高く出た。ただし、委託調査であり、米国だけを対象とし、世界共通の2026年比率ではない。

全員が対象になるとは限らない。それでも、公開情報を調べられる可能性は想定しておくべきだ。

雇用主に見える情報と、日本で確認すべき取扱い
#

境界は「公開か非公開か」だけではなく、誰が、何の目的で情報を取得・記録・利用したかにある。公開情報の閲覧と、採用企業や外部事業者が応募者情報として取得・保管することは分けて考える。

情報源	見つかりうる情報	日本で確認すること	重要な限界
検索エンジンと公開プロフィール	同姓同名、公開投稿、略歴、画像、団体ページ	どの情報を取得・記録し、どの採用目的に使ったか	公開情報も個人情報になりうる。一方、単なる閲覧と取得・データベース化は同じではない
公開SNS情報	投稿、返信、見える写真、公開されている交友関係	職務との関連性、必要性、情報の正確性	鍵付きアカウントや非公開メッセージを通常の検索で開けるわけではない。転載やスクリーンショットは残りうる
調査会社・人材サービスがまとめた情報	身元情報、職歴・学歴、公開記録、評価項目	その会社が委託先か独立した事業者か、利用目的、取得元、提供先、保有期間	外部事業者を使っても採用企業の管理責任が消えるわけではなく、独自利用なら請求先が増えることがある
ドキシングページまたは第三者の主張	氏名、所属との関係、連絡先、転載画像	掲載元と採用記録を別々に保存・訂正する	公開や反復は主張の正しさを証明しない。削除だけでは採用側に残った記録を直せない

厚生労働省の募集情報等取扱事業者向け指針は、利用目的を明らかにし、目的達成に必要な範囲で適法・公正に情報を集め、正確かつ最新に保つことを求める。人種、民族、社会的身分、門地、思想・信条、労働組合への加入状況など、通常の採用に不要な情報の収集には厳しい制約がある。公開されているから何でも採用判断へ使える、という意味ではない。

面接前に行う7段階監査
#

重要な応募の前に監査せよ。ただし、削除から始めてはならない。評価する側が自分へ何を結び付けられるか、先に記録する。その後で、説明の追加、削除、分離、正式な異議申立てを選ぶ。職場のアカウントではなく、個人端末を使うこと。

1. 応募書類に載せる身元の起点を固定する
#

提出予定の氏名表記、メールのドメイン、電話番号、都市、学校、勤務先、職名、在籍時期、ポートフォリオのドメイン、職務プロフィールのURLをそのまま書き出す。これが起点一覧になる。応募に不要な個人情報を新たに加えてはならない。

どの起点が珍しいか印を付ける。ありふれた氏名でも、珍しい勤務先と都市が組み合わされば、珍しい名前だけの場合より本人を絞り込みやすいことがある。正規の記録に使われうる旧姓、旧名、別のローマ字表記も控える。

2. 範囲を決めて公開検索する
#

氏名を引用符で囲んで検索し、次に学校、勤務先、都市、職務用の利用者名など、応募上の起点を一つずつ組み合わせる。検索結果の収録範囲はサービスごとに異なるため、最低2つの検索エンジンを使う。画像結果と最初の数ページを確認したら止める。調べ続けても得られる情報は増えにくく、不安ばかりが増える。

応募に使う公開メールや電話番号は、疑わしいサイトへ慎重に扱うべき情報を渡さずに済む場合だけ検索する。社会保障番号、パスポート番号、生年月日を丸ごと、未検証の検索サービスへ入力してはならない。

3. 手掛かりがどこへ続くかを図にする
#

結果ごとに、何を起点に見つかったか、その結果からどの手掛かり——別の利用者名、団体、画像、ドメイン、住所、記録——を新たにたどれるかを残す。手掛かりが、採用で想定する脅威（脅威モデル）から外れたら止める。生活全体を洗い出すのが目的ではない。応募書類のどの事実が、危険な文脈へつながるかを知るためだ。

この段階では、AIを使った非匿名化につながる情報も見つかる。仮名アカウントに本名が一度も出なくても、使い回した利用者名や文章の癖が二つの身元をつなぐことがある。

4. 重要な結果をすべて分類する
#

分類は3つだけにする。

本人： 自分の結果であり、文脈もおおむね正しい。
別人： 同姓同名、なりすまし、無関係な記録である。
曖昧： 一部は一致するが、誰のものか、文脈が正しいか確定していない。

気まずく感じるからといって、「曖昧」を黙って「本人」に分類し直してはならない。帰属が成り立つかを監査するための分類だ。一致を裏付ける事実と、否定する事実の両方を残す。

5. 何かを変える前に証拠を残す
#

誤りがある、脅迫を含む、または重大な影響が出そうな検索結果では、日付入りのスクリーンショット、完全なURL、ページ名、表示されている著者または公開者、誤りを説明する短いメモを保存する。合法かつ安全ならページやPDFも保存する。証拠は雇用主が管理する端末ではなく、個人端末に置く。

削除依頼が成功しても複製が残ることがあり、異議を申し立てた後にページが変わることもある。だから証拠が要る。現実の身体的危険があるなら、完全な記録より安全確保と地域の専門家への相談を優先する。

6. 経路に合った対処をする
#

自分の正確な公開投稿なら、必要な証拠を残した後で、文脈を加える、公開範囲を狭める、利用者名を分ける、削除する。誤ったウェブページなら、掲載元の訂正手続やなりすましの申告手続を使い、要件を満たす場合は検索エンジンへ検索結果からの除外を申請する。組織的ドキシングでは、公開の場で反論を重ねてページを広めてはならない。証拠を残して通報し、閲覧が苦痛なら信頼できる人へ見守りを頼む。

長く残る情報には、詳しいSNS足跡の残存対策を使う。キャッシュ、アーカイブ、転載先に残る複製には、リンク先の手順で対処する。

7. 訂正資料を一つにまとめる
#

雇用主から質問されたときに渡せる短い文書を作る。争われている主張、どこが誤りまたは不完全か、裏付け資料、訂正を確認できる信頼できる連絡先または公式資料だけでよい。事実に絞り、短くまとめる。採用担当者に必要なのは解決できる不一致であり、嫌がらせの全履歴ではない。

外部の調査会社や人材サービスが関わる場合は、採用企業からの通知、確認できた情報の写し、事業者名と役割、開示・訂正の請求、裏付け書類、送付・受領を確認できる記録を一緒に保管する。同じ誤りが再発したとき、この一式が時系列の証拠になる。

日本で応募者情報が使われたときの確認・訂正経路
#

この節は日本での応募を対象にする。日本語で応募していても、勤務先や情報を扱う事業者が国外なら、その国・地域の制度を確認すること。米国FCRAの報告書写し・不利益措置前手続を、日本の一般的な権利だと仮定してはならない。

個人情報保護委員会（PPC）のFAQが示すように、公開情報も個人情報保護法の対象になりうる。ただし、公開情報の取得・保管に関するPPCのFAQも区別しているとおり、ウェブ上で見ただけの場合と、応募者情報として取得・記録して利用する場合は同じではない。まず採用企業へ、利用目的、情報の取得元、保有している内容、外部事業者への提供・委託の有無、保有期間を尋ねる。

厚生労働省の指針では、採用に関する個人情報は目的を示し、必要な範囲で適法・公正に収集し、目的の範囲内で利用し、正確かつ最新に保つことが基本になる。公正な採用選考の案内は、本籍・出生地、家族、思想・信条など、本人の適性・能力と関係のない事項を採用判断へ持ち込まないよう求めている。

個人情報保護法には、保有個人データの開示や、内容が事実でない場合の訂正・追加・削除を求める仕組みがある。PPCの通則ガイドラインで条件と例外を確認し、まず情報を保有する事業者へ請求する。これは客観的なデータを確かめ、誤りを直すための経路であり、面接官の意見を書き換えたり、不採用判断を必ず覆したりする権利ではない。

問題	最初の請求先	次の相談経路	残す証拠
採用企業が保有する情報の出所・内容・誤り	採用企業の個人情報窓口	解決しない個人情報の問題はPPC相談ダイヤル	請求文、本人確認に使った情報、回答、送受信日時
調査会社・人材サービスの記録	事業者の役割を確認し、採用企業と該当事業者の双方	委託先か独立事業者かに応じてPPC等へ相談	事業者名、利用目的、取得元、情報の写し、訂正資料
本人の適性・能力と無関係な事項や採用差別の懸念	採用企業	ハローワークまたは都道府県労働局	求人票、質問・通知の原文、日時、比較できる事実

2026年7月17日に公表された個人情報保護法改正については、未施行の規定を現在の権利として扱わない。重大な事案、期限が関係する事案、損害賠償を求める事案は、資格を持つ国内の専門家へ確認する。

削除だけでは直せないもの
#

情報を削除すれば露出は減る。しかし、情報が存在しないことは証明できず、複製された主張も回収できない。目標は検索結果の先頭から問題を一掃することではなく、自分へ結び付く情報を減らし、正確にすることだ。

削除した投稿は、スクリーンショット、アーカイブ、他人の引用に残りうる。訂正が出ても元の見出しは残ることがある。外部事業者へ訂正を求めた応募者情報も、同じ誤った情報源から作り直されるかもしれない。身元をきちんと分離していても、すでにつながりを知る相手には狙われる。このため、監査では削除だけでなく記録も作る。

監査を続ける本人の負担にも限界がある。嫌がらせページを繰り返し検索すること自体が害になりうる。すでに標的なら、自分で何度も確認せず、信頼できる人へ監視対象を明確に伝える。自宅情報や身体への脅迫が出たら、評判管理から安全計画へ切り替える。職場監視への対策は採用後の別の脅威を扱うため、ドキシング対応の代わりにはならない。

結論——経路に合う防御を選べ
#

自分の公開情報は、文脈と公開範囲を整えよ。ドキシングで自分に帰属させられた主張には、反証と日付を残せ。採用企業や外部事業者が持つ記録には、まず事業者と取得元を特定し、客観的な誤りの開示・訂正を求めよ。

まず問うべきは「雇用主にどんな気まずい情報を見つけられるか」ではない。応募書類のどの事実が、どの主張へつながるのか。照合の根拠はどれほど強いのか。誰なら訂正できるのか。 そう問えば、ぼんやりしたデジタル足跡を、確認すべき結び付きへ切り分けられる。

要点

応募書類は身元をたどる地図でもある： 氏名、都市、学校、勤務先、メール、電話番号は、別の記録を結び付けやすくする起点になる。
4段階を監査する： 起点 → 追跡 → 帰属判断 → 意思決定。結果が見つかっても、自分のものだという証拠にはならない。
言語と管轄を混ぜない： この日本法モジュールは日本での応募向けであり、米国FCRAの手続を国外へ一般化しない。
削除より先に保存する： 誤照合やドキシングの主張では、削除依頼でページが変わる前に、日付入り証拠、URL、反証資料を残す。
事業者と情報源を先に特定する： 採用企業、委託先、独立事業者を区別し、客観的な誤りには必要最小限の証拠を付けて開示・訂正を求める。

よくある質問
#

公開情報の直接検索、非公開アカウント、削除、外部事業者の記録には、それぞれ異なる限界と手続があります。以下は日本での応募を前提にし、米国の手続を日本の一般的な権利として扱いません。

雇用主は応募者全員をGoogleで検索しますか？
#

「全員」を裏付ける信頼できる資料はありません。米国で採用判断をする立場の1,002人を対象にした2022年のHarris Poll調査では、70%が候補者調査にSNSを使い、全候補者を調べるとの回答は17%でした。ただし、定義も慣行も異なります。公開情報の調査はありうるものとして、応募書類から高い確度でたどれる経路を監査してください。

雇用主は非公開のSNSアカウントやメッセージを見られますか？
#

通常の公開ウェブ検索で、非公開メッセージや鍵付きアカウントが開くことはありません。ただし、公開の返信、転載された投稿、スクリーンショット、共通の知人、以前は公開されていたページから、現在の公開範囲を越えて情報が出ることはあります。鍵マークが、過去の公開情報まで消してくれるとは考えないでください。

雇用主が私の名前をインターネットで検索するには、私の同意が必要ですか？
#

日本では、すべての公開検索に一律の事前同意が必要だとは言えません。ただし、公開情報も個人情報になりえます。単なる閲覧か、採用企業・外部事業者が応募者情報として取得・記録・利用したか、目的と必要性は何かを分けて確認してください。要配慮個人情報には、より厳しい取得条件があります。

身元調査報告書が同姓同名の別人のものなら、どうすればよいですか？
#

まず採用企業へ、どの事業者が、どの情報源から、どの識別情報を使って照合したかを尋ねてください。採用企業と情報を保有する外部事業者を区別し、開示された客観的な誤りには、同姓同名の別人と区別できる必要最小限の証拠を付けて訂正を求めます。請求、回答、裏付け記録、送付・受領日時を保管し、必要な範囲を超えて身元情報を送らないでください。

応募前に古い投稿を削除したほうがよいですか？
#

確認は必要ですが、最初に一括削除してはいけません。異議申立てに使う可能性のある誤った帰属、なりすまし、嫌がらせ、文脈を先に保存してください。その後、自分で管理できる正確な情報を経路に合わせて減らします。削除はリスクを下げますが、消去ではありません。キャッシュ、アーカイブ、スクリーンショット、他人が引用した内容は残りえます。

参考資料
#

事例・米国調査・日本の公的資料は、現行URLと保存時点を指定したInternet Archiveの正確な複製で検証できる。

Cora Aegis

Cora Aegis は CypherpunkGuide で、プライバシーを最優先した運用上の安全対策（OPSEC）の実践記事を書いている。本稿では、公開検索、組織的ドキシング、第三者調査の3経路から12の証拠項目を再構成した。報道が因果を立証できない箇所では不確実性を残し、日本で情報を扱う事業者・取得元・訂正経路を確認する3つの対処も整理している。

Coraについて詳しく →

写真1枚で、AI はあなたの居場所を突き止める（2026年）

Sat, 04 Jul 2026 00:00:00 +0000

私は仮名で、AI が生成した肖像を使って書いている。だから、場所のプライバシーへの答えが「顔さえ写さなければいい」で終わるはずは、はじめからなかった。本当に厄介なのは、その顔の背後に写り込んでいるものの方だ。2025年4月、ある開発者が、OpenAI のモデル o3 を、GeoGuessr（ストリートビューの一枚から場所を当てるゲーム）の最上位ランクの人間——Master 級のプレイヤー——と対戦させた。勝ったのはモデルだった。23,179 対 22,054。5ラウンドすべてで国を正しく言い当て、うち2度は数百メートル以内まで詰めた。同じ試験で o3 は、ファイルの metadata に仕込まれた偽の GPS 座標を無視し、ピクセルだけを頼りに本当の場所へと推論を進めた。

この最後の一点に、すべてが詰まっている。二十年ものあいだ、写真プライバシーの定石は「EXIF（写真に埋め込まれる撮影情報。位置情報を含みうる）を削れ」——スマートフォンがファイルに書き込む、隠れた GPS タグを取り除け——だった。それは、この問題のうちいまでは易しく片づく側への助言としては、正しかった。手ごわいのは、もう一方だ。機械は、屋根の形も、植生も、路面の標示も、太陽の角度も、店の看板の文字も読み取り、metadata が一切なくても、あなたの居場所を言い当てる。Stanford の PIGEON（位置推定モデル）は、ありふれた写真の国を 91.96% の確率で言い当て、GeoGuessr の世界王者を6戦連続で下した。2025年のあるベンチマークでは、汎用の Gemini モデルが正しい都市を 64.3% で突き止めた——同じ画像に挑んだ人間は、わずか 1.7% だった。

だから、ここでの問いは「AI にあなたの居場所が分かるか」——分かる——ではなく、分かるようになった今、何があなたの露出を実際に左右するのかだ。公開されたベンチマークと、Bellingcat（公開情報調査の報道組織）自身の実地ガイドを読み込んで、私は、位置を割り出す側がどうやって写真を絞り込んでいくのかをたどり、その手順を逆にたどって防御へと組み替えた。手短に言えば、位置情報はいまや二つの層から漏れ、それぞれ直し方が違う。metadata の層は、洗い落とせる。目に見える層は、写り込むものと、それを世に出す間合いを、自分で抑え込むしかない——公開情報の調査者が問題を逆から解くのと、同じやり方だ。

AI が読む時代、写真1枚が明かすもの
#

AI による位置推定（geolocation、写真から撮影場所を特定すること）とは、GPS タグからではなく、写真の目に見える中身——建物、植生、路面標示、太陽の角度、看板——から、その写真がどこで撮られたかを推論することだ。効いてくる変化は、ここにある。この能力は最近、「腕の立つ人間の趣味」から「安く、速く、自動化された推測」へと踏み越えた。しかも相手にしたのは初心者ではなく、熟練したプレイヤーだった。以下の数字は、査読を経たベンチマークと、広く追試された一対一の対戦から取ったものであって、ベンダーの宣伝からではない。

機械と人間の差がどれほど開いているか——そこを、たいていの人が見くびっている。2025年の学術ベンチマークで、ある Gemini モデルは国レベルで 83.7%、都市レベルで 64.3% の精度に達した。同じ画像に挑んだ人間の被験者は、9.5% と 1.7% だった。この作業が得意な人間——ランク入りした GeoGuessr プレイヤー——なら、まだ張り合える。だからこそ、o3 が Master を破り、PIGEON が王者を一蹴したという結果は、警鐘なのだ。敵が借りられるのは、平均ではなく上限——天井の方だ。

システム	国レベル	都市レベル	備考
PIGEON（Stanford、2024年）	91.96%	誤差の中央値約44km	GeoGuessr 王者に6戦全勝
Gemini（2025年のベンチマーク）	83.7%	64.3%	同じベンチマークで人間は 9.5% / 1.7%
GPT-4o（2025年のベンチマーク）	74.0%	63.3%	消費者向けモデル、同じ対人間比較セット
o3（2025年、一対一の対戦）	5ラウンド全て	2度、数百メートル以内	人間の Master に勝利、偽 EXIF を無視

正直であるために、留保が二つ要る。第一に、精度にはむらがある。モデルは、代表性の乏しい地域よりも、北米と西欧ではっきり成績が良い。だから「AI に私の町は当てられまい」は、時に本当で、けっして当てにできない。第二に、専用ツールは汎用のチャットボットより先へ行く。Graylark Technologies の商用システム GeoSpy は、数千万枚の街頭画像で訓練されており、条件の良い入力なら街路レベルの精度が出る、と同社は主張する。その足取り自体が、警告だ。公開後、特定の女性を位置特定させる動画をユーザーが投稿しはじめ、同社は一般公開を取りやめ、ツールを法執行機関・企業・政府の顧客に限定した。作り手自身が、この能力を一般の手に委ねるわけにはいかないと判断した。それくらいには、現実の脅威なのだ。

調査者はどうやって写真の場所を割り出すか——そしてそれが、なぜあなたを助けるか
#

公開情報を扱う調査者は、写真の場所を割り出すのに AI を必要としない。geolocation（目に見える証拠から、その画像がどこで撮られたかを確かめること）という技法は、モデルより十年は先んじている。彼らのやり方を知ることには意味がある。良い防御とは、彼らの手順をそっくり逆からたどることだからだ——彼らが探し求める手がかりこそ、あなたが構図から締め出したいものにほかならない。この実践の多くを体系化した調査報道の Bellingcat は、それを層ごとのチェックリストとして教えている。

層は、粗いものから細かいものへと積み上がる。chronolocation（影から時刻・緯度を絞る手法）は、影を使う——影の長さと向きを、候補となる日付の太陽位置計算と突き合わせれば、時刻と緯度の両方が絞られる。建築とインフラは、国を絞る——電柱の設計、信号機の形、縁石や車止めの様式は管轄ごとに異なり、参照データベースがその違いを目録にしている。植生は、気候と地域を見分けさせる。看板と文字は、しばしば都市を、あるいは特定の一本の通りまでを、あっさり明け渡す。そして反射——店先の窓、車のミラー、サングラス——は、カメラが背けていたはずのものを露わにしうる。Bellingcat による MH17 の車列経路の特定——2014年にウクライナ上空で旅客機を撃墜したミサイルを運んだ輸送車を追跡したもの——は、まさにこの積み重ねから組み上がった。影の分析に、目印の照合を重ね、道路の正確な一区間へと突き止めたのだ。

AI が変えたのは、手法ではなく費用だ。人間の調査者は、一枚に何時間もかける。モデルは、同じ推論を数秒、数セントでこなし、しかも一度に何千枚へも差し向けられる。ここから引き出せる防御の教訓は、明確で、少しばかり気を楽にしてくれる——天才を打ち負かす必要はない、重ねられる手がかりを取り除けばいい。あなたが封じる層のひとつひとつ——看板をなくす、特徴のある空の輪郭をなくす、反射する面をなくす、遮るもののない影をなくす——は、位置を割り出す側が、人間であれ機械であれ、もう使えなくなる層なのだ。

位置情報が漏れる、二つの層
#

ここで、他のすべてを整理し直す枠組みを示す——そして、ほとんどのガイドがぼかしてしまう枠組みでもある。写真は、独立した二つの層で位置情報を漏らし、そのうち解決済みなのは片方だけだ。この二つを混同すること——それが、「metadata は消した」という言葉が、手にしてもいない安心を人に与えてしまう理由だ。

第1層は metadata——カメラがファイルに書き込む EXIF ブロックで、位置情報サービスがオンだったなら、正確な GPS 座標も含まれる。この層は解決できる。データは切り分けられていて、ファイルの決まった場所に収まっており、写真が端末を離れる前に、まるごと取り除ける。削ってしまえば、その座標はただ消える。

第2層は中身——目に見える情景そのものだ。画像を読む AI モデル（vision model）が読み取るのは、まさにこれだ。そして、削り取れない——写真に付随しているのではなく、写真そのものだからだ。建築を消すには、写真そのものを消すしかない。o3 が偽の GPS タグを無視し、ピクセルから画像の場所を割り出したとき、それは、第2層がいまや単独で成立することを示していた——第1層から何も得られない敵にも、目に見える構図の全体が、なお手元に残るのだ。

これが、防御の全体を組み替える。第1層は掃除の問題だ——毎回、一度きり、機械的にやる。第2層は構図の問題だ——シャッターを切る瞬間と、投稿を押す瞬間に決まってしまい、いったん公開した空の輪郭を、後から直すツールなど存在しない。この記事は、以降この二つを別々に扱う。まとめて扱うことこそが、間違いだからだ。

「でも metadata は消した」——それが実際に直すもの
#

metadata を削ることは、必要だが、もはや十分ではない。それは第1層をきれいに閉じるが、第2層には何もしない——しかも第1層の内側でさえ、多くの人が頼りにしているプラットフォームの挙動は、思っているより狭い。崩しておくべき思い込みが、二つある。SNS がこれをもう代わりにやってくれている、という思い込みと、さっとスクリーンショットを撮れば写真は洗い清められる、という思い込みだ。

主要なプラットフォームの多くは、公開アップロードを再エンコードし、他のユーザーがダウンロードできる版から EXIF ブロックを落とす——だが、その保証には条件がつく。独立した metadata 検査サービスの報告では、2026年時点で、例外はアプリを問わず共通している——「ドキュメントとして送信」あるいは「ファイルとして送信」のモードは、再エンコードを迂回し、すべてを保持する。安全な経路からタップひとつの距離に、しかも何の警告もなく、それは潜んでいる。そして公開用のコピーを削ることは、削除とは違う——Meta 自身のプライバシーポリシーは、自社の目的のために元の画像データをサーバー側に保持する、と述べている。下の表は、検査された挙動と公式方針を突き合わせたものだ。個々のアップロードへの約束としてではなく、「罠がどこにあるか」として読んでほしい。

経路	公開版の EXIF	罠
Instagram / Facebook（公開投稿）	ダウンロード版では削除される	元データはサーバー側に保持、高画質の DM 送信は挙動が異なりうる
X（公開投稿）	削除される	内部で保持、予約投稿やサードパーティ API クライアントは未検証
Reddit（ネイティブの `i.redd.it`）	再エンコードで削除される	外部の画像ホスト（例：imgur のリンク）は GPS を保持しうる
TikTok（投稿）	削除される	アプリは別の手段で位置を収集、削除しても追跡は止まらない
WhatsApp / Signal / Telegram（写真モード）	圧縮で削除される	「ドキュメント／ファイルとして送信」は完全な EXIF を保持、警告なし

スクリーンショットの神話は、一行を割く価値がある。検索エンジンが、いまだにそれを勧め続けているからだ。スクリーンショットを撮れば、確かに、元の GPS タグを持たない新しいファイルができる——それは本物の、第1層の対処だ。だが第2層には、何ひとつ効かない。スクリーンショットには、同じ通りが、同じ空の輪郭が、同じ店の看板が、そのまま写っている。そしてモデルは、それを元の写真と寸分たがわず読み取る。スクリーンショットが変えるのは、ファイルであって、写り込んだ景色ではない。

脅威モデルに見合った防御プロトコル
#

ここに、唯一正しい用心の量というものはない——適切なプロトコルは、誰が見ているか、そして位置を突き止めた相手がそれで何をできるかによって変わる。「屋外では絶対に投稿するな」といった一律の規則は、暮らしを立ち行かなくするし、多くの人には不要でもある。役に立つのは、労力を脅威に見合わせることだ——EFF（電子フロンティア財団）の Surveillance Self-Defense が土台に据えているのと、同じ脅威モデル化の理屈である。下の段階は、上へいくほど積み増していく——誰もが基本層はやるべきで、上の段階はそれぞれ、前の段階を置き換えるのではなく足していく。

段階を分ける境界線は、結果の重さだ。気軽に共有する人にとって、場所を割り出された写真は、プライバシーのかすり傷だ。だが、公の場に立つ作り手や、すでに嫌がらせに直面している女性にとって、それは現実世界での遭遇へ向かう一歩になる——そしてこれは、絵空事ではない。AI による位置推定は、Privacy International（英プライバシー擁護 NGO）がその危険分類で目録にしているのと同じ、ストーキングや親密なパートナーによる暴力（IPV）の脅威を助長するからであり、GeoSpy の作り手が一般公開の扉を閉ざした理由も、そこにあるからだ。活動家、記者、あるいは虐待の生存者にとっては、位置を特定された一枚の構図が、身の安全にかかわる事態になりうる。まず自分がその梯子のどこにいるかを見定め、それから、見合った行を当てはめてほしい。

段階	対象	足す習慣
基本層（全員）	気軽に共有する人	アップロード前に、ローカルで EXIF を削る（プラットフォーム任せにしない）。自宅・職場・子どもの学校を、リアルタイムで投稿しない。スクリーンショットは安全ではない、と忘れずに
強化層	公の人格、クリエイター、嫌がらせに直面している人	投稿を遅らせ、「いま、ここ」を「先週、ここ」に変える。背景を洗う——窓、反射、ナンバープレート、特徴のある空の輪郭。繰り返し訪れる、決まった場所を避ける
高度層	活動家、記者、IPV の生存者、内部告発者	公開した写真はすべて、永久に位置特定されうると想定する。「この構図は何を明かすか」の点検を、投稿の後ではなく前に回す。位置情報を含む画像を決して載せない、端末とアカウントの区画を保つ

三つの手立てには、過信しないための正直な札を貼っておく必要がある。EXIF を削るのは、ローカルで機械的にやるのが一番だ——コマンドラインツールの ExifTool は一度ですべてを取り除き（exiftool -all= photo.jpg）、自分のマシンで動くから、写真はそこから出ていかない。投稿を遅らせることは、リアルタイムの漏れ——あなたがいまどこにいるかを敵が知ること——を封じるが、事後の分析には何もしない。背景は、いつ調べられようと、変わらず場所へと解けてしまうからだ。そして背景をぼかすのは、見かけほど強くない——軽いぼかしは deblurring（ぼかしを復元する処理）で部分的に戻せてしまう。だから正直な選択肢は、重いモザイク化か、そもそもそれを写さないことだ。手立てのそれぞれを、それが対処する層の名で呼べば、「何かはやった」を「守れている」と取り違えることは、なくなる。

結論——実際、どこまでやればいいのか
#

たいていの人にとって、プロトコル全体は二つの習慣に畳み込める——反射のように、ローカルで metadata を削ること。そして、自分が繰り返し戻る場所——自宅、職場、子どもの送り迎え——を、リアルタイムで投稿するのをやめること。これで第1層は完全に閉じ、第2層からは、その最も値打ちのある手がかり——敵が動き出せる決まった場所——を奪える。それより上は、脅威モデル次第だ。そして高度層を必要とする人は、たいてい、自分がそうだと、すでに分かっている。

長持ちするのは、頭の切り替えの方だ。古い問い——「ジオタグを切り忘れなかったか」——は、第1層の問いであり、ExifTool が習慣になれば、第1層はほとんど自動になる。いまのあなたを守る問いは、第2層の問いだ——*この構図は、私がどこにいるかについて何を語っているか。そしてそれを、私を見つけ出したい見知らぬ相手に、手渡すだろうか。*写真を世に出す前に点検するとき、私が問うのは、これだけだ。機械が私の代わりに答えてしまうのを、もう止められない——そういう問いは、これひとつなのだから。

要点

二つの層、二つの直し方： EXIF の metadata は解決できる（ローカルで削る）。目に見える背景は削り取れず、構図と間合いで抑え込むしかない。
AI が破るのは初心者だけではない、熟練者だ： PIGEON は写真の国を 91.96% の確率で言い当て、GeoGuessr 王者を6対0で一蹴した。ある Gemini モデルは、人間が 1.7% だった都市レベルで 64.3% を出した。
metadata を削るのは必要だが、十分ではない： o3 は GPS タグを偽装されたあとも、ピクセルだけを読んで写真の場所を割り出した——そしてスクリーンショットは EXIF を消しても、位置特定できる構図をまるごと残す。
プラットフォームの削除には罠がある： 公開投稿はふつう再エンコードされるが、「ドキュメント／ファイルとして送信」のモードは完全な EXIF を保持し、プラットフォームは元データをサーバー側に保持しうる。
労力を脅威に見合わせる： 誰もが EXIF を削り、自宅や職場のリアルタイム投稿を避けるべきだ。クリエイターや嫌がらせの標的は、遅延投稿と背景洗いを足す。活動家と生存者は、公開した写真はすべて永久に位置特定されうると扱う。

よくある質問
#

EXIF データを削れば、私の居場所は隠れますか？
#

問題の半分は、それで解決します。EXIF を取り除けば、カメラが埋め込んだ正確な GPS 座標は消えます——本物の、やる価値のある対処です。ですが、最新の画像を読む AI モデルは、目に見える情景——建築、植生、太陽の角度、看板——から、metadata が一切なくても位置を推論します。記録に残る検証では、OpenAI の o3 は、GPS タグが偽物に差し替えられたあとでさえ、写真の場所を割り出しました。metadata を削るのは基本の対処として行い、そのうえで、写真の実際の中身の方を、より手ごわい未解決の層として扱ってください。

元の写真の代わりにスクリーンショットを投稿すれば、安全ですか？
#

スクリーンショットは元の EXIF を取り除くので、metadata の層は閉じます——ですが、画像そのものについては何ひとつ変えません。通りも、空の輪郭も、読み取れる看板も、そのまま構図に残っていて、AI はそれを、元のファイルと寸分たがわずスクリーンショットから読み取ります。スクリーンショットが変えるのは、ファイルであって、写り込んだ景色ではありません。位置推定に対する防御には、なりません。

AI は本当に、人間より上手に写真の場所を割り出せますか？
#

はい、しかも初心者だけでなく、腕の立つ人間が相手でも、です。Stanford のモデル PIGEON は、写真の国を 91.96% の確率で言い当て、GeoGuessr の世界王者を6戦にわたって下しました。2025年のベンチマークでは、ある Gemini モデルが、人間の被験者が 1.7% だった都市レベルで 64.3% の精度に達しました。精度は地域によってむらがありますが、上限——本気の敵が借りられる高さ——は、とても高いのです。

背景をぼかせば、私は守られますか？
#

十分に重いぼかしであれば、の話です。軽いぼかしや、弱いモザイクは、deblurring（ぼかしを復元する処理）の技術で部分的に戻され、文字や細部が復元されてしまいます。もし背景の何か——道路標識、特徴のある建物、反射——が居場所を明かしてしまうなら、堅い選択肢は、重いモザイク化か、いっそそれを画面から除くことであって、生ぬるいぼかしではありません。

たった一つ、最も値打ちのある習慣は何ですか？
#

繰り返し訪れる現実の場所——自宅、職場、子どもの学校、決まった曜日に通うジム——を、とりわけリアルタイムで投稿するのをやめることです。一度きりの旅行写真は、敵が動き出せる決まった場所よりも、小さなリスクです。それを、アップロード前にローカルで EXIF を削ることと組み合わせれば、metadata の層は閉じ、中身の層からは、最も動きにつながる手がかりを奪えます。

#	出典	URL	アーカイブ
1	Privacy International——“Nowhere to Hide? Privacy Risks and Policy Implications of AI Geolocation”（2026年）	https://privacyinternational.org/report/5736/nowhere-hide-privacy-risks-and-policy-implications-ai-geolocation	https://web.archive.org/web/*/https://privacyinternational.org/report/5736/nowhere-hide-privacy-risks-and-policy-implications-ai-geolocation
2	Haas ほか——“PIGEON: Predicting Image Geolocations”（Stanford、CVPR 2024）	https://arxiv.org/abs/2307.05845	https://web.archive.org/web/*/https://arxiv.org/abs/2307.05845
3	Huang ほか——“AI Sees Your Location, But With A Bias Toward The Wealthy World”（画像を読む AI〔VLM〕を GeoGuessr の名手に見立てた研究、arXiv、2025年）	https://arxiv.org/abs/2502.11163	https://web.archive.org/web/*/https://arxiv.org/abs/2502.11163
4	Sam Patterson——“Can o3 beat a GeoGuessr Master?"（2025年）	https://sampatt.com/blog/2025-04-28-can-o3-beat-a-geoguessr-master/	https://web.archive.org/web/*/https://sampatt.com/blog/2025-04-28-can-o3-beat-a-geoguessr-master/
5	Simon Willison——“o3 beats a GeoGuessr master”（2025年）	https://simonwillison.net/2025/Apr/28/o3-geoguessr/	https://web.archive.org/web/*/https://simonwillison.net/2025/Apr/28/o3-geoguessr/
6	Bellingcat——“Using the Sun and the Shadows for Geolocation”（2020年）	https://www.bellingcat.com/resources/2020/12/03/using-the-sun-and-the-shadows-for-geolocation/	https://web.archive.org/web/*/https://www.bellingcat.com/resources/2020/12/03/using-the-sun-and-the-shadows-for-geolocation/
7	TechNADU——“GeoSpy Sparks Privacy Concerns After Public Misuse”（2025年）	https://www.technadu.com/ai-powered-tool-geospy-sparks-privacy-concerns-after-public-misuse/570730/	https://web.archive.org/web/*/https://www.technadu.com/ai-powered-tool-geospy-sparks-privacy-concerns-after-public-misuse/570730/
8	Electronic Frontier Foundation——Surveillance Self-Defense	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/
9	Meta——プライバシーポリシー（画像 metadata の保持）	https://www.facebook.com/privacy/policy/	https://web.archive.org/web/*/https://www.facebook.com/privacy/policy/

この記事は、このサイトのより広い筋の、写真に特化した相棒だ。同じ機械の推論を、あなたの画像ではなくテキストに向けたものは、AI 非匿名化——推論が、あなたの匿名性を解いていく（2026年） に地図化してある。そして AI が脅威モデル全体にわたって壊す前提は、AI時代のOPSEC——脅威モデルを組み立て直す（2026年） に並べてある。位置を割り出された写真は、いったん投稿すれば取り消せないから、削除して実際に何が生き延びるのかの点検は、削除しても消えない——2026年、SNSの足跡はどこまで残るのか にある。背景ではなく、あなたの身体に狙いを定めた同じ脅威については、あなたの声と顔は、もう「鍵」だ——AI クローンに備える OPSEC（2026年） を見てほしい。そして、こうした手法が現実の標的へと収束していくさまは、配信者は、どこで暴かれるのか——5つの事例とドキシング防御（2026年）。

あなたの声と顔は、もう「鍵」だ——AI クローンに備える OPSEC（2026年）

Thu, 18 Jun 2026 00:00:00 +0000

私は仮名で書いている。そして私は女性だ。だから何かを録音する前に、いつもこの脅威を量っている。なじみのある声や顔には、長らくひとつの前提があった——それ自体が本人証明になる、と。電話口で母があなたの声を聞けば、それはあなただった。声を偽るには、あなた自身の関与が要ったからだ。その前提は、もう消えた。あなたが「自分」の証だと思っている特徴——声の音色、顔の造作、文章の癖でさえ——は、いまやモデルがあなたになりすますための材料になる。しかも、あなたが自分で公開した素材から。

これはAI 時代の脅威モデルで壊れた4つの前提のうち、4つ目にあたる。そして、独立した一本として扱うに値する。守り方が普通でないからだ——ほとんどが予防に尽きる。一度出した声の素材は取り戻せないし、これから見ていくとおり、モデルにそれを確実に忘れさせることもできない。だから仕事は前倒しになる——何を公開するか、そして、あなたを通して狙われうる人たちと、何をあらかじめ取り決めておくか。以下では、この問題の二面性、なぜ女性と、名乗りを上げて書く者に偏ってのしかかるのか、露出を下げる最小化、そして前の記事が約束だけ残した本人確認の手順を、まるごと示す。

あなたの生体情報は、いまや「ログイン」であり「標的」でもある
#

身元を証明するものが「鍵」、敵に突かれうるものが「攻撃の入口」だ。声・顔・文体は、いまや両方を兼ねる——あなたを保証する特徴が、そのままあなたを偽造させる。この崩壊は、最近のもので、しかも実測されている。Microsoft の研究者たちは2023年、自社の VALL-E というモデルが、わずか3秒の音声サンプルから話者の声を合成できることを示した。数枚の写真があれば、見分けのつかない合成の顔ができる。投稿の蓄積があれば、書き方を真似できる。どれも、もとを公開していたこと以上の協力は要らない。

これを単なる偽造ではなく*credential（資格証明）*の問題にしているのは、生体情報が安く偽れるようになった、まさにそのとき、各組織がそれを信頼しはじめたことだ。銀行は声紋による電話本人確認を入れた。家族は聞き慣れた声を頼りにする。アシスタントは顔でロックを解く。米連邦取引委員会（FTC）はこの帰結を正面から取り上げ、2023年11月に Voice Cloning Challenge を立ち上げ、2024年4月に『AI による音声クローンへの対処アプローチ』を公表した。あなたを認証するものが、いまやあなたを危険にさらすものになった。

あなたの生体情報	いま「鍵」として信頼されている場面	同時に「攻撃の入口」になる理由
声	銀行の電話本人確認、家族の信頼、音声アシスタント	約3秒の音声から、見分けのつかないクローンができる
顔	写真付き本人確認、社会的な信用、端末のロック解除	数枚の画像から、合成された似姿ができる
文体	「あの人らしい書き方だ」	投稿の蓄積から、文体を移植できる

守りの上での帰結はこうだ——これらを「それ自体が本人証明になるもの」と考えるのをやめること。電話口の声は、もう証明ではない。動画のなかの顔も、もう証明ではない。この記事の以降の話は、すべてそれを受け入れるところから始まる。

なぜ女性と仮名に、最も重くのしかかるのか
#

このリスクは、均等には降りかからない。なりすまし、捏造された性的な画像、声を使った詐欺は、女性に、そして動機ある嫌がらせ加害者を抱える人に、不釣り合いに重くのしかかる。だからこれは、単なるデータ衛生ではなく、身体と評判の主権の問題だ。証拠は、出典をまたいで一致している。2019年の Deeptrace の調査は、ディープフェイク（実在しない合成映像）動画の96%がポルノであり、標的にされた個人は事実上すべて女性だったことを見いだした。ディープフェイク追跡企業 Security Hero による2023年の業界調査は、ポルノの割合を98%、標的の99%を女性とした。これらは政府のデータではなく追跡調査だ——だが、その向きは、より硬い報道に裏づけられている。

2024年12月、American Sunlight Project は、米議会の女性議員の、およそ6人に1人——約16%——が、同意のないディープフェイク画像に描かれていたこと、そして女性が男性の70倍ほど多く標的にされていたことを見いだした（初報は The 19th）。UN Women は、より広い傾向を振り返りながら、米国でディープフェイクの被害者の半数超が自殺を考えたこと、そしてデジタルの暴力が日常的にオフラインの嫌がらせへとあふれ出すことを指摘する。この害は、漠とした評判リスクではない。標的を定め、性別に偏り、沈黙させるために設計されている。

仮名で活動する者にとって、この縛りは矛盾へと締まっていく。名乗りを上げたペルソナは、声と存在感の上に築かれる——ポッドキャスト、講演、その仕事を人間らしく感じさせる顔。けれど、きれいな録音の一つひとつ、顔を正面から写した写真の一枚いちまいが、そのペルソナになりすましたい誰か、あるいはそれを私の法的な身元に結びつけたい誰かにとっての、学習データでもある。最初の守りである最小化は、まっすぐ「届く範囲」と引き換えになる。私は、その緊張を「ないこと」にはしない。代わりに、それに振り回されるのではなく、こちらが御す方法を示す。

まず予防——公開する素材を最小化する
#

最初のてこは最小化だ。公衆の目に出す生の生体サンプルの、量と鮮明さを減らす。これは治療ではなく緩和だと受け入れたうえで。 これはAI 規模の非匿名化を律するのと同じ論理だ——最も安い攻撃は、あなたがすでに公開したものを読む。だから最もてこの効く制御は、どんな削除依頼よりも上流にある。クローンの出来は、その学習素材で頭打ちになる。長くて、きれいで、一人だけの録音は理想のサンプルだ。雑音まじりで、短くて、複数人が居合わせた音声は、できの悪いサンプルだ。どちらを供給するかは、あなたが選べる。

具体的には、こういうことだ。可能な限り、名乗りを上げたペルソナの発信を、高品質な生体取得から切り離す。そして、サンプルを時刻と場所に縛りつけるメタデータを削ぐ。公の発信者にとって、目標は沈黙ではない——届く範囲に対して、サンプルの品質を意図して落とすことだ。一人語りの独白ではなく、共同ホストの音声。法的な実名に紐づく顔ではなく、名乗りを上げた身元を担うイラストのアバター。そして、自分の声を認証要素として二重に使わせない、という固い拒否。

あなたが公開するもの	それが生むリスク	露出を抑える代わりの手
長く、きれいな、一人だけの音声録音	高品質な学習サンプル	もっと短い断片／共同ホストの音声／声の下に環境音や音楽を敷く
法的な実名に紐づく、顔を正面から写した写真	似姿と、身元へのリンクの両方	名乗りを上げたペルソナにはイラストのアバターを／実在の顔は実名から切り離す
銀行やログインの要素としての声紋	クローンが、機能する「鍵」になる	音声認証を無効にする／生体でない第2要素を使う

どれも治療ではない。そう言えば嘘になる。すでに公開されたサンプルは公開されたままだし、本気の敵は、できの悪い素材でも仕事をする。最小化は、クローン成功の確率と忠実度を下げる。ゼロにはしない。だからこそ、第2のてこと組み合わせる——そちらは、いずれクローンが存在するという前提に立つ。

本人確認の手順——その全体
#

第2のてこは、あらかじめ取り決めた信頼だ。あなたを通して狙われうる人たちと、前もって、別の経路で、本人確認の一手を取り決めておく——そうすれば、クローンされた声に「急かし」を作り出させない。たいていの助言は「家族の合言葉を決めよう」で止まる。それは正しい直感で、しかし不完全な手順だ。合言葉が効くのは、秘密だからではない。急かしが武器化された、その瞬間に、敵が握っていない経路での二度目の確認を強いるからだ。仕組みの全体を、たった一つの共有フレーズではなく、この原理の周りに組み立てる。

設計の規則は単純だ——本人確認は、依頼が来たのと同じ経路を、決して通ってはならない。 クローンされた声は、かかってきた電話を握っている。だが、あなたがすでに持っている番号への折り返しや、学習されたことのない私的な記憶までは握っていない。エピソード記憶——どこにでも投稿しうる事実ではなく、二人で分かち合った特定の瞬間——こそ、モデルが合成できない、あなたの一部だ。

手順の要素	どう仕込むか	なぜクローンには破れないか
別経路の規則	依頼が来たのとは別の経路で確認する（電話→既知の番号へのメッセージ）	クローンは一つの経路を握っても、独立した二つ目は握れない
共有した記憶の問い	二人で分かち合った経験からしか答えられない問い。どこにも投稿しない。定期的に変える	モデルは声は合成できても、私的なエピソード記憶は合成できない
折り返しの徹底	いったん切る。すでに保存してある番号へ、こちらからかけ直す	偽装された発信者番号と、時間の圧力を無効にする
強要のサイン	あらかじめ決めた言葉で「私は強要されている——従うふりをして、助けを呼んで」を伝える	本人なのに、強いられている場合をカバーする
仮名向けの拡張	仮名どうしの相手には、法的な身元に紐づかない使い捨てのトークンを、前もって別経路で共有しておく	仮名を解かずに、仮名のまま本人確認できる

その最後の行こそ、私のような者のために書いた部分であり、どんな「家族の合言葉」指南もカバーしない一手だ。信頼する相手が、あなたを仮名としてしか知らないなら、ペルソナと人物の壁を壊すことなく、共有した家族の歴史に頼ることはできない。使い捨ての本人確認トークン——暗号化された経路で一度だけ交換し、定期的に変わる問いの起点にする——があれば、仮名どうしの協力者のネットワークが、誰一人として法的な実名を知ることなく、互いを本人確認できる。この手順は、二人暮らしの家庭から、分散した活動家やクリエイターのネットワークまで、そのまま広がる。共有した法的な身元には決して依存せず、別経路で確立した共有の秘密だけに頼るからだ。

「消せばいい」は効かない——だから予防がすべてなのだ
#

ここで重荷を担うのは予防だ。削除は、荷重を支えられないからだ。学習済みモデルから声や似姿を取り除くことは、実運用の規模では、いまなお研究段階の能力でしかない——今日押せるボタンではない。だから実際に効く制御は、サンプルを出さないことだ。これは公開した足跡の永続性と同じ受け渡しだ——取り込みは絶え間なく、削除は部分的にしかできないから、後始末よりタイミングが勝る。

研究は、自らの限界について正直だ。MIT Technology Review は2025年7月に、研究者がテキスト音声合成モデルに特定の話者を「忘れさせる（unlearn）」ことができると報じた——ただし、その処理には数日かかり、モデルが許された声をわずかに劣化させ、研究者自身の言葉で「実用にはもっと速く、もっと拡張可能な解が要る」という。だから正確な言い方は「削除は不可能だ」ではない——機械的な忘却（machine unlearning）は、いまなお研究段階の能力であって、今日押せるボタンではない、だ。どんな「あなたの声を削除します」という触れ込みも、取り消しではなく、部分的で将来に向けたものとして扱うこと。

これが、すべての順序を入れ替える。サンプルが、いったん公開されれば事実上ずっと残るのなら、完全に効く制御は公開の前にしかない——そして次善の制御は、クローンの存在を前提とする、あの本人確認の手順だ。検知ツールや削除代行サービスにも役割はある。だがそれらは、外側の、最も弱い輪だ。内側の輪——最小化と、あらかじめ取り決めた信頼——こそ、あなたが完全に握れるものなのだ。

Key Takeaways
#

声・顔・文章は、いまや「鍵」であり「攻撃の入口」でもある。 聞き慣れた声や顔を、それ自体が本人証明になるものとして扱うのをやめる。
守りは予防であって、事後対応ではない。 約3秒の音声で声は複製される。サンプルは取り戻せず、忘却（unlearning）はまだ実運用に耐えない。
この脅威は、性別に偏っている。 合成された性的な画像となりすましは、圧倒的に女性と公の仮名にのしかかる——これは単なるデータ衛生ではなく、身体と評判の主権だ。
届く範囲に対して、サンプルの品質を落とす。 共同ホストの音声、名乗りを上げたペルソナにはアバター、声紋ログインをしない、メタデータを削ぐ。
別経路の本人確認を、あらかじめ取り決めておく。 折り返しの徹底、共有した記憶の問い、強要のサイン、そして仮名には——仮名を解かずに本人確認できる、使い捨てのトークン。

よくある質問
#

AI は本当に、短い音声から私の声を複製できますか？
#

できます。2023年の Microsoft の研究モデルは、3秒のサンプルからの音声合成を実証し、いまや商用ツールも同様の短サンプルでの複製を提供しています。2025年の UC バークレーの研究（Barrington & Farid、Scientific Reports）では、聞き手はこうしたクローンを、およそ80%の割合で本物の声と取り違えました。実践的な要点は、あなたの声の、きれいで公開された録音はどれも「使えるサンプル」だと考え、その数を減らすことです。

家族の「合言葉」は、実際に効きますか？
#

攻撃者が握っていない経路での確認を強いるとき、効きます。だからより強い版は、既知の番号への折り返しに、私的に分かち合った記憶からしか答えられない問いを足したもので、一つの固定フレーズではありません。パスワードは、当てられ、立ち聞きされ、あるいは口車で引き出されえます。定期的に変わる「共有した記憶の問い」に強要のサインを足したほうが、はるかに頑健です。フレーズは手順の種であって、その全体ではありません。

すでに学習されたモデルから、私の声や顔を取り除けますか？
#

確実には、規模では、今日はできません。研究者はモデルに話者を「忘れさせる（unlearn）」ことができますが、その処理は遅く、不完全で、実運用のシステムにはまだ載っていません（MIT Technology Review、2025年）。オプトアウトや「学習しないで」のシグナルは、プラットフォームがそれを尊重する場合に、おおむねこれからの取り込みに効くだけです。削除は、部分的で将来に向けたものとして扱うこと——だからこそ、何を公開するかを最小化することが、どんな削除依頼よりも効くのです。

なぜこれを、とりわけ女性の問題として枠づけるのですか？
#

データが、極端に偏っているからです。追跡調査は、ディープフェイク・ポルノの標的の圧倒的多数を女性とし、American Sunlight Project の研究は、議会の女性議員のおよそ6人に1人が同意のない画像に描かれていた——男性のおよそ70倍の割合だと見いだしました。実際に誰が標的にされているかを無視した守りは、最もリスクの高い人々を守りきれません。だからここでの手順は、詐欺だけでなく、嫌がらせとなりすましの脅威モデルに合わせて組んでいます。

最も効く一手は、たった一つなら何ですか？
#

あなたの声や顔を、認証要素として働かせるのをやめることです——生体でない第2要素が使える場面では、声紋による銀行認証や、生体の「あなた自身」ログインを無効にする。これは、機能する「鍵」を攻撃者の手の届く範囲から即座に取り除く、唯一の一手です。その間に、最小化と本人確認の手順が、より遅い構造的な仕事をこなします。

家庭用ルーターのセキュリティ監査：2026年版OPSECガイド

Fri, 28 Aug 2026 00:00:00 +0000

資金について：CypherpunkGuideは監視型広告を一切載せない——広告ネットワークも、トラッキングピクセルも、スポンサー記事もない。運営資金は透明な収益源から得ている。現在は読者からの寄付で賄い、将来は購読と編集方針に合うアフィリエイト収入も充てる。本稿は特定の事業者を推奨せず、ルーターやVPNのアフィリエイトリンクも含まない。

自宅のインターネットが普段どおり動いていても、ルーターが第三者の中継基盤として使われていることはある。米国の連邦捜査局（FBI）が2026年3月に出したAVreconに関する技術警告（FLASH）によると、このマルウェアは約163か国の機器で観測された。FBIはこれとは別に、SocksEscortというサービスが2020年以降、約369,000台を侵害し、その利用権を販売してきたとみている。AVreconは約1,200機種のルーターとIoT（インターネットへ接続する機器）を標的にし、観測された感染の大多数はSOHO（小規模オフィス／家庭用）ルーターだった。攻撃者の狙いは、所有者の通信を止めることとは限らない。自分たちの通信を、ごく普通の住宅用IPアドレスから出たように見せるためである。

だから「パスワードを変える」「WPA3を有効にする」「VPNを買う」だけでは足りない。OPSEC（運用上の安全対策）とは、相手に観測・悪用される情報や仕組みを見定めて守ることだ。正確な機種はまだサポートされているか。管理画面はインターネットから開けるか。第三者がDNS、管理者、ポート転送を変えていないか。異常があれば、設定を強化するのか、確認済みの設定から組み直すのか、それとも交換するのか。必要なのは、この判断である。ここでいう家庭用ルーターは、市販機やISP貸与機を含む、家庭とインターネットをつなぐ機器を指す。「ホームルーター」という名称の携帯回線製品だけに限らない。

私はFBI、米国司法省（DOJ）、米国連邦取引委員会（FTC）、米国国立標準技術研究所（NIST）の現行資料を照合し、18行の家庭用ルーター証拠監査表へ落とし込んだ。同じ監査質問を4つの現行AIシステムにも与えたところ、どれも見慣れたチェックリストを返したが、複数の回答が電源の入れ直し、工場出荷時リセット、マルウェア除去を混同していた。本稿では別の操作として扱い、証拠が得られない項目は「不明」のまま残す。

始める前に家庭用ルーター証拠監査表をダウンロードせよ。これは検査用のワークシートであり、スキャナーではない。設定ファイル、公開IPアドレス、Wi-Fiパスワード、ルーターのシリアル番号を入力する必要はない。

2026年の「家庭用ルーター侵害」とは何か
#

家庭用ルーターの侵害とは、自宅のネットワークとインターネットの間で通信を運ぶ機器が、第三者に不正制御されることだ。攻撃者は設定を変え、家庭のIPアドレスを中継に使い、家庭内ネットワーク（LAN）の端末を攻撃し、より大きな作戦の一部としてルーターを利用できる。接続が正常でも中継役にされうるため、遅さや発熱ではなく、サポート状況と設定の証拠で判断する。

ルーターが侵害されても、すべてのパスワードや暗号化されたページを読まれたとは限らない。現在の多くのウェブサイトが使うHTTPSや、正しく設定した端末側VPNは、通信内容を引き続き暗号化できる。回線が遅いだけでも侵害の証拠にはならない。役に立つのは、サポート、更新、意図した設定を証拠で確かめ、確認できない項目を「不明」と記録することだ。

現在の一次資料には、異なる侵害経路が示されている。

証拠	報告された規模	ルーターの役割	この証拠だけでは分からないこと
FBI AVrecon FLASH、2026年3月	SocksEscortが2020年以降、約369,000台を侵害し利用権を販売したとFBIはみている。AVreconは約163か国で観測され、約1,200機種を標的にした	住宅回線プロキシ（家庭のIPアドレスを中継に使うサービス）、遠隔操作用シェル、別プログラムの導入役、ボットネットを構成する端末	一覧にある全機種、または各家庭の全個体が感染したこと
DOJによるIoTボットネットの阻止、2026年3月	裁判所提出文書では、4つのボットネットが世界で300万台超を乗っ取ったと主張されている	Wi-Fiルーターは、大量の通信で相手を止めるDDoS攻撃に使われたIoT機器の一種	300万台すべてがルーターだったこと、各機器がルーターだったこと、主張された命令がすべて成功したこと
FBIのサポート終了ルーター警告、2025年5月	全機種に共通する台数は示されていない	遠隔管理が有効な一部のサポート終了（EOL）ルーターが、TheMoonのプロキシとして使われた	古いという理由だけで、特定の一台が感染していること
DOJによるGRU作戦阻止、2024年2月	数百台のSOHOルーターから成るネットワーク	公開済みの初期管理者パスワードが残ったUbiquiti EdgeOSルーターに犯罪者が入れたMoobotを、ロシア軍参謀本部情報総局（GRU）が転用した	各ルーターがMicrosoft Officeのトークンを直接抜き取ったこと

規模は一つのマルウェアに限らない。2026年3月のDOJによる作戦では、4つのボットネットが世界で300万台超を乗っ取ったとする裁判所提出文書上の主張が示された。ただし対象にはカメラや録画機なども含まれ、Wi-Fiルーターはその一種である。

GRU事案では、ルーターの役割を誇張してはいけない。GRU作戦の阻止を伝えたDOJ資料には、このルーターネットワークが標的型フィッシングと認証情報収集を隠し、その実行を支えたとある。家庭用ルーターがOfficeのトークンを直接抜き取ったとは書かれていない。ルーターは、より大きな作戦を支える基盤だった。

静かな中継役として使われたルーターには、「乗っ取り」から想像する目立つ症状がないかもしれない。劇的な兆候を探すのではなく、サポートと設定が意図どおりかを証拠で確かめる必要がある。

最初にサポート状況を確定する
#

サポート状況が最初の判定になる。メーカーまたはインターネット接続事業者（ISP）が脆弱性の修正を提供しなくなった製品は、設定を整えても既知の欠陥を直せない。年数だけで決めず、正確な機種とハードウェア版を確認せよ。名前が似た機種を代用してはいけない。公式記録を確認できなければ合格にせず、ISPまたはメーカーへ相談する。

自分が管理できる端末を使い、ルーターのローカルネットワークへ接続して作業せよ。設定ファイル全体、シリアル番号、公開IPアドレス、認証情報をウェブフォームやAIチャットへ貼り付けて検索してはいけない。

所有者を記録せよ。 ISP貸与機器なら、ファームウェアと遠隔管理を誰が制御するのか確認する。ISPに必要な管理経路を勝手に無効化したり、市販機向けファームウェアを入れたりしてはいけない。
正確な個体情報を記録せよ。 本体ラベルと管理画面から、メーカー、機種、ハードウェア版、導入済みファームウェアを控える。名前が似ている別機種を、ファームウェア判断の代用にしてはいけない。
公式の製品ライフサイクルを探せ。 メーカーまたはISPのサポートサイトで、正確なハードウェア版を調べる。URLと確認日を保存する。
公式ファームウェアを照合せよ。 導入済みの版と公開日を、公式の最新版と比べる。更新が自動、手動、ISP管理のどれかも確かめる。

FBIの2025年警告には、2010年以前のルーターは更新を受けていない可能性が高いとある。これは注意を促す目安であり、すべての製品に当てはまる期限ではない。より新しくてもサポートが終わった製品はある。古いISP貸与機器でも更新が続く場合はある。正確な機種の公式記録を優先せよ。

機種ごとの確認を、全製品共通の年数で置き換えられるとする一次資料は見つからなかった。

確認結果	判定	理由
正確な機種がEOL、または信頼できる更新経路がない	交換	既知の脆弱性が修正されないまま残りうる
サポート状況を確定できない	不明／相談	「安全だろう」という推測は、証拠不足を合格へ変えてしまう
サポート中だが公式ファームウェアより古い	強化	メーカーまたはISPの手順で更新し、導入済みの版を確認する
最新でサポート中、ISP管理も確認済み	監査を続ける	サポート中でも、設定や個体が正常だとは証明できない

交換とは、最も高価なゲーミングルーターを買うことではない。購入前に、サポート期間、更新方法、安全な初期設定、復旧手順を確認できる製品を選ぶことだ。NIST IR 8425Aはメーカー向けの製品プロファイルであり、消費者向け認証ではない。それでも、認証によって保護された設定操作、正規性を検証できる更新、管理経路の制限、安全に初期化できる仕組み、セキュリティ状態を確認できる情報は、購入時の確認表として使える。

18項目の証拠監査を行う
#

この監査は、所有者、サポート、外部への露出、設定、接続端末、復旧について、合格・不合格・不明の証拠を記録する。不明を合格へ丸めず、最も深刻な一項目で対応を決める。根拠のない「87点」のような総合点は作らない。秘密情報を含めず、各判定の根拠、確認日、次に取る対応を残せ。証拠のない安心感より、解決すべき不明点を見える形にする。

設定を変える前に、ダウンロードしたCSVをローカルの表計算ソフトまたはテキストエディターで開き、結果用の列を追加せよ。秘密情報は入れない。「遠隔管理は無効」と書き、管理者パスワードは書かない。「予定したDNSと一致」と書き、機密を含む設定ファイル全体は貼らない。

1. ファームウェアと管理者権限を確認する
#

更新ボタンを押した事実ではなく、更新後に表示されたファームウェア版を確認せよ。管理者アカウントをすべて見直し、初期設定または使い回しの管理者パスワードは、パスワードマネージャーで生成・保存した固有のものへ替える。管理者パスワードとWi-Fiパスワードは別の防御であり、片方を変えてももう片方は変わらない。

自分が作っていない管理者アカウントを見つけたら、通常の設定強化として扱うのをやめよ。削除やリセットの前に、アカウント名、時刻、ファームウェア版、関連ログを写真またはローカル記録で残す。不明なアカウントは調査のきっかけであり、国家が関与する攻撃を証明するものではない。

認証情報を整理する場合も、パスワードマネージャーの移行手順と同じく範囲を絞って確認する。信頼できる端末から重要な秘密を変更し、無関係な診断サービスへ貼らず、復旧経路を残せ。

2. 不要な管理経路を閉じる
#

Remote Management、Remote Administration、Web Access from WANを確認せよ。WAN（広域ネットワーク）はインターネット側、LAN（ローカルエリアネットワーク）は家庭内側を指す。Cloud Management、Telnet、SSHなどのコマンド操作経路も調べる。NISTのルータープロファイルは、WANからの遠隔アクセスを初期状態で無効にし、管理をLAN側へ限定するよう推奨している。インターネット側からの管理は、必要性と接続者を制限する方法を説明できない限り無効にせよ。

次も確認する。

WPS（ボタンやPINでWi-Fi機器を登録する仕組み）： FTCの基本方針に従って無効にする。
UPnP（アプリや機器が自動でポートを開く仕組み）： 自動ポート設定が不要なら無効にする。先に現在の設定を記録し、ゲーム機、通話アプリ、メディア機器への影響を見込む。
DMZホストとポート転送： DMZは一台の端末を広く外部へさらす設定、ポート転送はインターネットから特定の家庭内サービスへ通信を通す設定である。各項目に現在の所有者と目的が必要だ。再利用されたLAN内アドレスへ向く古い設定を、単なる書類上の問題として放置してはいけない。
ダイナミックDNS： 変わる公開IPアドレスへ固定のホスト名を付ける仕組みである。設定されたサービスとアカウントを確認する。
VPNなどのトンネル設定： すべてのサービスを確認する。不明な設定を見つけたら、証拠を残して相談する。

FTCの家庭用Wi-Fi基本対策は、遠隔管理、WPS、UPnPの無効化を勧めている。家庭用監査の出発点として妥当だが、機能の有無や業務上の必要性は環境で違う。例外を隠さず記録せよ。

3. Wi-Fi暗号化と分離を確認する
#

必要な機器がすべて対応するなら、Wi-Fiの暗号化方式にWPA3-Personalを使う。対応しない機器がある場合はWPA2-Personal/AESを使う。WEP、初代WPA、暗号化されていない主要ネットワークは、互換性のために許容する設定ではない。再設定または交換の対象である。

SSID（Wi-Fiのネットワーク名）を、ゲスト用、IoT用、非表示のものまで含めてすべて列挙する。名前を信用せず、分離が実際に効くか試す。ゲスト回線からノートPC、ネットワークストレージ、プリンター管理画面、ルーター管理画面へ届くなら、十分に分離されていない。

信頼度の低いスマート機器は、ルーターが通信分離を実施できる区画へ置く。古いカメラ自体が安全になるわけではないが、そのカメラから届く範囲を狭められる。この考え方はAI時代の脅威モデルにも通じる。予防に失敗したとき、侵害された一台から攻撃が届く端末を減らすのである。

4. 接続端末と設定状態を棚卸しする
#

接続端末の一覧、DHCP（端末へLAN内アドレスを自動で割り当てる仕組み）の割り当て一覧、予約済みアドレスを確認する。現在つながっている各端末を、所有者と種類で分類する。見慣れない識別子をすぐ侵入者と決めつけてはいけない。現在のスマートフォンは、機器固有のMACアドレス（ネットワーク機器の識別値）の代わりに、ランダム化した値を使うことがある。端末が部品メーカー名で表示される場合もある。

次の設定を、意図した状態と照合する。

WAN側とLAN側のDNS（ドメイン名をIPアドレスへ変換する仕組み）
IPv4とIPv6のファイアウォール
ポート転送、DMZホスト、外部公開サービス
管理者アカウントと最近のログイン試行
タイムゾーンと時刻同期
ファームウェア版と更新履歴
遠隔管理とクラウド管理の状態。

不明なDNS、未知の管理者、説明できないポート転送は、「本体が熱い」といった曖昧な症状より判断に使いやすい。正確な証拠を残し、信頼できる端末とメーカーまたはISPの公式窓口で、正当な変更だったかを確かめよ。

5. 製品が見せる証拠を調べる
#

NISTのプロファイルは、ログイン試行、管理操作、システムとファイアウォールの状態、機器を構成する要素の状態、時刻同期など、セキュリティ状態を把握できる情報を求めている。家庭向け管理画面で見られるのは、その一部だけかもしれない。

ログを見られなければ不明と書け。合格にしてはいけない。ログがあれば、予想外の接続元からの管理操作、身に覚えのない設定変更、繰り返す更新失敗、理由のない再起動、時刻が大きくずれて使えない記録を探す。ログを公開貼り付けサイトへ送ってはいけない。LAN内アドレス、端末名、ドメイン、アカウント名が含まれる場合がある。

同梱ワークシートは、観測できる証拠に絞って設計した。マルウェア検出をうたうものではない。サポートと設定に根拠がある項目、不明のまま残る項目を見分ける道具である。

経過観察・強化・再初期化・交換を選ぶ
#

合格した行の数ではなく、最も深刻な確認結果から対応を選べ。信頼できるファームウェア更新経路がないことは、整ったWi-Fi設定10件より重い。不正な管理者アカウント一つは、強いパスフレーズより重い。経過観察、強化、再初期化、交換の条件を混ぜてはいけない。証拠が足りなければ「不明」と記録し、ISPまたはメーカーへ相談する。

本稿の再初期化とは、先に証拠を残し、機種別の公式リセットまたは復旧手順に従い、確認済みの設定から組み直すことだ。反射的にResetボタンを押すことではない。

対応	きっかけの例	次に行うこと
経過観察	サポート中で最新版、説明できない外部公開や設定変更がなく、復旧手順も分かる	確認日を保存し、セキュリティ情報が出た後と無理なく続けられる間隔で見直す
強化	サポート中だがファームウェアが古い。初期設定が残る。WPS、不要なUPnP、WAN管理が有効	変更前を記録し、公式手順で一つずつ直し、通信と変更後の状態を確認する
再初期化	信頼できる侵害通知。不正な管理者、DNS、トンネル、ポート転送を確認。消したはずの設定が再び現れる。更新が繰り返し失敗	先に証拠を残してISPまたはメーカーへ連絡し、正確な公式リセット／再書き込み手順に従って、確認済みの設定から組み直す
交換	EOL／サポート終了。信頼できるファームウェア経路がない。必要な安全性を満たす暗号化方式を使えない。信頼できる状態へ戻せない	古い機器の使用をやめ、新しい管理者情報でサポート中の機器を設定する。信頼できない設定バックアップ全体を移さない

「経過観察」は、「侵害なし」を証明する認定ではない。家庭用ルーターのログだけで、隠れた侵害が一切ないとは証明できない。この監査で既知の失敗が見つからず、今後も更新と確認を続けられるという意味である。

「再初期化」には条件がある。ストーカー行為、標的型侵入、金銭被害、勤務先の調査に関わるルーターなら、リセットによって重要な設定やログを失うおそれがある。安全上必要な範囲でのみ切断または隔離し、状態を撮影してから、専門の事故対応担当者または警察などへ相談して消去を判断せよ。影響が限られる家庭内の異常なら、メーカーまたはISPから機種別の復旧手順を得られる。

電源の入れ直し、工場出荷時リセット、再書き込み、交換は別の操作
#

どのボタンも、すべてのルーターの信頼を取り戻せるわけではない。電源の入れ直しは機器を再起動する。工場出荷時リセットは製品資料に定められた初期状態へ戻す。公式ファームウェアの再書き込みは、対応機種でソフトウェアを入れ直す。交換は、新しい機器とサポート期間から始める。どの操作も普遍的な駆除保証ではないため、先に証拠と機種別の公式手順を確保する。

操作	できること	確認できないこと
電源の入れ直し	動作中の状態を再起動する。公式の更新／復旧手順が求める再起動を完了する	脆弱性が修正されたこと、不正な設定が消えたこと、マルウェアが戻らないこと
工場出荷時リセット	設定と保存済み利用者データを、製品が定める初期状態へ戻す。多くの不正な設定変更を消せる	ファームウェアや、その下位の構成要素まで正規であること、初期パスワードが安全であること、EOL製品の脆弱性が直ること
公式ファームウェアの再書き込み／復旧	一部機種で、メーカーが対応する検証済み経路からファームウェアを置き換える	起動時に最初に動くプログラム、ハードウェア、製造・流通過程、サポート終了機器の侵害まで直す万能策であること
交換	古い機器を外し、新しいサポートと更新の期間を始める	引き継いだ設定、使い回した秘密、外部公開サービス、侵害されたLAN内端末まで安全になったこと

FBIの2025年EOLルーター警告が勧めるのは、一連の対策である。可能ならEOL機器を交換し、更新を適用し、遠隔管理を無効にし、固有のパスワードを設定し、その後に再起動する。「ルーターを再起動する」だけを抜き出すと、同じ外部公開状態を残さないための対策が消えてしまう。

サポート中のルーターを再初期化するなら、メーカーまたはISPが示す機種別の手順を使え。作業前に公式ファームウェアと復旧資料を入手する。必要なISP接続設定は記録してよいが、秘密を公開ワークシートへ写してはいけない。リセットまたは再書き込み後は、新しい管理者情報と安全な管理設定を作ってから、当面必要のないLAN内機器をつなぐ。最後に導入済みファームウェアを確認する。

不審な変更が入った後の完全バックアップは、メーカーまたは事故対応担当者が安全だと確認しない限り戻してはいけない。バックアップは、消したかった問題までそのまま復元しかねない。

VPNで直せること、直せないこと
#

VPNは、VPNクライアントとVPNサーバーの間を暗号化するトンネルである。トンネル内の通信についてルーターやISPから読める内容を減らせるが、その通信を運ぶルーター自体は直さない。ファームウェアの更新、外部へ開いた管理画面の閉鎖、マルウェア除去は別の作業だ。ルーター上で動くVPNは、そのルーターをトンネルの端点として信頼する。VPNの有無とルーターの信頼は別に確認せよ。

NIST SP 800-77 Rev. 1は境界を明確にしている。VPNが守るのはトンネルの両端間の通信であり、経路上のルーターのファームウェアを更新したり、その設定が正しいと証明したりはしない。

確認事項	ノートPCやスマートフォンのVPN	ルーター上で動くVPN
ルーターのファームウェアを更新できるか	いいえ	いいえ
外部へ開いた遠隔管理を閉じられるか	いいえ	いいえ
ルーターのマルウェアや不明なアカウントを消せるか	いいえ	いいえ
対応端末の通信をVPNサーバーまで暗号化できるか	正しく設定すれば、はい	はい。ただしルーター自体がトンネルの端点になる
侵害されたルーターがプロキシになることやLANを攻撃することを止められるか	いいえ	いいえ
すべてのメタデータを隠せるか	いいえ。ルーターにはVPN接続先、時刻、通信量が見える	いいえ。侵害されたルーターは、暗号化する前または復号した後の通信を扱う

HTTPSは、ブラウザとウェブサイトの間で多くの通信内容をすでに暗号化している。端末側VPNは別のトンネルとしてプライバシーに役立ちうるが、どちらもルーターのサポート状況は変えない。ルーター自体がVPNクライアントなら、ルーターの侵害は、トンネルを作って経路を決める端末の侵害でもある。

そのため本稿はVPN事業者を順位付けせず、「常時接続」をルーター防御として勧めない。ルーターの更新経路と管理境界を信頼できる状態にした後で、ネットワーク上のプライバシー手段をより広いプライバシー設計の一部として選べ。

不正な変更を見つけた場合
#

何が変わったか説明できるだけの証拠を残し、信頼できる更新済み端末と公式復旧経路から信頼を取り戻せ。侵害の疑いがある端末で、すべてのアカウントを一斉に変更してはいけない。リセットで証拠を消す前に、所有者、機種、時刻、不正な設定をローカルへ記録する。設定を戻すのは、ISPまたはメーカーの正規窓口と機種別手順を確認してからだ。

ルーターの機種、ハードウェア版、ファームウェア、現在時刻、所有者と管理者を記録する。
不正なアカウント、DNS、ポート転送、トンネル、ログ記録、警告を具体的に保存する。ローカルに保管し、正規の窓口と共有するときも秘密を伏せる。
ISP管理なら、ISPのセキュリティまたはサポート窓口へ連絡する。市販機なら、メーカーの公式窓口を使う。
EOL機器は交換する。修正を受け取れない設定へ何時間も費やしてはいけない。
サポート中の機器では、公式のリセット／復旧／再書き込み手順に従う。信頼できないバックアップを自動で戻さず、設定を組み直す。
信頼できる更新済み端末から、ルーターの管理者パスワードと、証拠上、漏えいした可能性がある認証情報を変更する。利用できる重要アカウントでは多要素認証を有効にする。
復旧後に、ファームウェア、WAN管理、アカウント、DNS、ポート転送、ファイアウォール、接続端末、ログをもう一度確認する。

ルーター外のアカウント情報まで露出した証拠があれば、認証情報と身元記録について漏えい後の防御計画を使え。ルーター設定が一つ間違っていたという理由だけで、すべてのアカウントが侵害されたと決めつけてはいけない。

結論——検証できる信頼を取り戻せ
#

役に立つルーター監査は、サポートの記録、設定の記録、根拠のある対応を残す。魔法の点数を作らず、高度な侵害をすべて否定できるとも言わない。正確な機種を起点に、確認済みの更新と設定を積み上げ、証拠がなければ不明と書け。交換や再初期化は、条件に当てはまるときだけ選べ。最後に、復旧後のファームウェアと設定をもう一度確認する。

正確な機種とサポート期間から始めよ。次にファームウェア、管理者権限、WAN管理、Wi-Fi暗号化、ポート公開、DNS、接続端末、分離、利用できるログを確認せよ。証拠がなければ不明と書け。サポート終了機器は交換せよ。不正な変更は消す前に保存せよ。機種別の公式復旧手順に従え。

2026年の静かな危険は、通信を読まれることだけではない。家庭の機器が、所有者には正常に見えたまま第三者の基盤になることだ。対策も静かでよい。外部へ開く管理経路を減らし、確認済みの最新ソフトウェアを使い、意図した設定と確認できる証拠を残し、信頼できる復旧経路を持て。

よくある質問
#

通常の設定強化と事故対応を分け、確認できない項目を不明のまま残し、家庭用機器では証明できない駆除を約束しないための回答である。マルウェアを検出できると主張するものでもない。監査間隔、再起動、工場出荷時リセット、UPnPとWPS、AVrecon機種一覧について、何を確認できるのか、どこから先は断定できないのかを示す。

家庭用ルーターは、どのくらいの頻度で監査すればよいですか？
#

まず現在のサポート状況と設定全体を確認してください。その後は機種別のセキュリティ情報が出たとき、説明できない設定変更があったとき、無理なく続けられる一定の間隔で見直します。手動更新の機器なら、毎月ファームウェア版を確認するのも現実的です。ISP管理や自動更新でも、更新が実際に届いたかを定期的に確かめてください。間隔そのものより、確認した版と日付を残すことが重要です。

ルーターを再起動すれば、マルウェアは消えますか？
#

再起動は動作中の状態を変えますが、本稿で引用した政府資料は、AVrecon、TheMoon、Moobotなどのルーターマルウェアを再起動で除去できるとは示していません。脆弱性を修正せず、ファームウェアの正当性を証明せず、永続する変更をすべて消さず、再感染も防ぎません。公式の更新または復旧手順が求める一工程として扱い、機器が正常になった証拠にはしないでください。

ルーター侵害の後は、工場出荷時リセットだけで十分ですか？
#

すべての場合に十分とは言えません。工場出荷時リセットは、製品資料に定められた初期設定へ戻し、多くの設定変更を消せます。一方で初期パスワードへ戻り、重要な証拠も消えます。変更されたファームウェアや、その下位に残る不正な仕組みまで除去できる保証はありません。メーカー／ISPが示す機種別の復旧手順に従い、現行の公式ファームウェアを適用して安全な設定から組み直し、サポート終了機器は交換してください。

UPnPとWPSは無効にすべきですか？
#

FTCは両方を無効にするよう勧めています。WPSは無効にしてください。UPnPはゲーム、通話、メディア機器に必要な場合があるため、先に現在のポート設定を記録し、無効化後にアプリの動作を確認してください。例外を残すなら、どの端末とアプリが必要としているかを記録し、自動公開を説明できないままにしないでください。

自分の機種がAVreconボットネットに含まれていたか確認できますか？
#

FBIのFLASHには、観測されたメーカーと機種が載り、約1,200機種が標的になったとあります。ただし、一覧に自分の機種があるだけでは、その個体が感染した証拠になりません。一覧にないことも安全の証明にはなりません。機種を手掛かりに、公式ファームウェア、サポート期間、該当する脆弱性情報、FBIが示す痕跡を確認し、不明ならメーカーまたはISPへ相談してください。

出典
#

以下は政府機関と標準機関の一次資料である。各アーカイブは、独立した出典確認を行った2026年8月28日にHTTP 200で取得できた、元ページと日時が一致するWayback保存版である。変更されうる資料にはライブURLと保存版を併記した。後から数値、帰属、条件、断定できない範囲まで確かめるための二つの経路である。

#	出典	URL	アーカイブ
1	FBI FLASH 20260312-001——SocksEscortが住宅回線プロキシに悪用したAVrecon感染ルーター	https://www.fbi.gov/file-repository/cyber-alerts/avrecon-malware-infected-routers-exploited-as-residential-proxies-by-socksescort.pdf	https://web.archive.org/web/20260402044918/https://www.fbi.gov/file-repository/cyber-alerts/avrecon-malware-infected-routers-exploited-as-residential-proxies-by-socksescort.pdf
2	FBI——住宅回線プロキシ網から機器を守る	https://www.fbi.gov/investigate/cyber/alerts/2026/evading-residential-proxy-networks-protecting-your-devices-from-becoming-a-tool-for-criminals	https://web.archive.org/web/20260808054457/https://www.fbi.gov/investigate/cyber/alerts/2026/evading-residential-proxy-networks-protecting-your-devices-from-becoming-a-tool-for-criminals
3	FBI——サポート終了ルーターを悪用する犯罪者向けプロキシサービス	https://www.fbi.gov/investigate/cyber/alerts/2025/cybercriminal-proxy-services-exploiting-end-of-life-routers	https://web.archive.org/web/20260822065226/https://www.fbi.gov/investigate/cyber/alerts/2025/cybercriminal-proxy-services-exploiting-end-of-life-routers
4	DOJ——記録的攻撃を担った大規模IoT DDoSボットネットの阻止	https://www.justice.gov/usao-ak/pr/authorities-disrupt-worlds-largest-iot-ddos-botnets-responsible-record-breaking-attacks	https://web.archive.org/web/20260825205257/https://www.justice.gov/usao-ak/pr/authorities-disrupt-worlds-largest-iot-ddos-botnets-responsible-record-breaking-attacks
5	DOJ——ロシアGRUが制御したボットネットを裁判所の許可に基づき阻止	https://www.justice.gov/archives/opa/pr/justice-department-conducts-court-authorized-disruption-botnet-controlled-russian	https://web.archive.org/web/20260808070920/https://www.justice.gov/archives/opa/pr/justice-department-conducts-court-authorized-disruption-botnet-controlled-russian
6	NIST IR 8425A——家庭向けルーター製品に推奨されるサイバーセキュリティ要件	https://doi.org/10.6028/NIST.IR.8425A	https://web.archive.org/web/20260506061206/https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8425A.pdf
7	FTC——家庭のWi-Fiネットワークを安全にする方法	https://consumer.ftc.gov/articles/how-secure-your-home-wi-fi-network	https://web.archive.org/web/20260821194423/https://consumer.ftc.gov/articles/how-secure-your-home-wi-fi-network
8	NIST——スマートホームの安全とプライバシーを守る7つのヒント	https://www.nist.gov/blogs/taking-measure/7-tips-keep-your-smart-home-safer-and-more-private-nist-cybersecurity	https://web.archive.org/web/20260816082442/https://www.nist.gov/blogs/taking-measure/7-tips-keep-your-smart-home-safer-and-more-private-nist-cybersecurity
9	NIST SP 800-77 Rev. 1——IPsec VPNガイド	https://doi.org/10.6028/NIST.SP.800-77r1	https://web.archive.org/web/20260816065058/https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1.pdf

Cora Aegis

Cora Aegisは、CypherpunkGuideでプライバシーを最優先にしたOPSECの実践ガイドを書いている。本稿では、米国政府によるルーター事案4件をNISTの家庭向けルーター製品プロファイルと照合し、Google AI Modeと別のAIシステム4件で検索回答の境界を確認した。その結果を、読者のネットワークを走査・変更しない18項目の証拠監査へまとめた。

Cora Aegisについて詳しく読む →

その暗号化バックアップ、本当に復元できますか？【2026年】

Thu, 03 Sep 2026 00:00:00 +0000

資金について：CypherpunkGuideは監視型広告を載せない。広告ネットワーク、閲覧者を追跡するピクセル、スポンサー記事は使わない。運営資金は透明な収益源から得る。現在は読者からの寄付、将来は購読料と編集方針に沿った成果報酬型の紹介リンクを予定している。この記事に成果報酬型リンクはなく、特定の保存サービスを推奨するものでもない。

写真や手紙、大切な記録は、それを作ったパソコンを買い替えた後も残しておきたい。バックアップの暗号化は、他人に内容を読まれないために役立つ。ただし後から取り出すには、保存先へアクセスできること、暗号を解除できること、必要な版が残っていること、取り出したファイルを読めることも必要になる。

私は、プログラムのコードを公開している暗号化バックアップソフトresticを使い、12個の人工ファイルを6つの条件で復元する実験を設計した。ある条件では、保管領域の通常検査、全データの検査、復元操作がすべて成功したのに、戻ってきたのは予定した12個のうち11個だった。別の条件では12個すべてが戻り、形式の読み取りにも成功したが、1個だけが求めていた版より古かった。

確かめたいのは、残すつもりだった記録を、必要な版で取り出して使えるかどうかだ。その確認を、再現できる実験と、自分のバックアップで安全に試す手順につなげる。実験に使ったのは生成したテスト用ファイルだけで、個人の保存データではない。ドライブの寿命、別の場所に置いたコピーが災害後も使えるかどうか、パソコン全体の復旧は測っていない。

同期・バックアップ・長期保存の役割を分ける
#

同期は作業中のファイルを端末間でそろえ、バックアップは失ったり変更したりしたファイルを取り戻すためのコピーを残す。長期保存では、機器やソフトが変わった後も記録の意味が分かり、読める状態を維持する。一つのサービスが複数の役割を持っていても、それぞれの確認は必要だ。

同期サービスが、ある端末で削除したファイルを別の端末からも消すのは、仕様どおりの動作であり得る。取り戻せるかどうかは、過去の版をどれだけ残すか、削除をどう扱うか、アカウントへ入れるかで決まる。一方、接続を外したディスクには有用なコピーが残っていても、外した後の変更は入っていない。保存先を選ぶ前に、必要な役割を決めておきたい。

役割	目的	別に確かめること
同期	作業中のファイルを複数の端末で使う	削除や上書きの前の版を取り戻せるか。取り戻せる期間はどれくらいか
バックアップ	データの消失や望まない変更から復旧する	含まれるファイルと版、想定する事故の後もコピーが残るか、実際に復元できるか
長期保存	選んだ記録を何年も使い続ける	記録の説明、ファイル形式、読むための機器やソフト、保存媒体の更新、復元手段の維持

米国のサイバーセキュリティ・インフラセキュリティ庁（CISA）は、3-2-1方式を、原本を含む合計3つのコピーを2種類の媒体に置き、1つは離れた場所に保管する方法として説明している。ランサムウェア対策の指針では、オフラインで暗号化したバックアップと、データの検査・復元試験の定期実施も勧めている。オフサイトは保管する場所、オフラインは接続の状態を表す。 別の建物に置いても、侵害された同じアカウントから消せるコピーなら、それだけで独立した備えになるわけではない。CISAのバックアップ資料とランサムウェア対策ガイドを参照できる。

個人の記録なら、まず具体的な事故を書き出す。ノートパソコンの盗難、誤削除、自宅の火災、アカウントに入れなくなること、暗号の解除方法を失うこと。それぞれの後に、どのコピーを使えるか確かめる。個人のプライバシー対策と同じく、一つひとつの対策が何に備えるものなのかを明らかにする作業だ。

故障した環境に頼らず復元できるようにする
#

暗号化は、有効な解除手段を持たない相手からバックアップの内容を守る。解除手段そのものを残したり、アカウントへのアクセスを維持したり、コピーの消失を防いだりする機能ではない。復元の計画では、これらの条件も個別に満たしておく必要がある。

バックアップの場所、使ったソフトと保存形式、必要ならアカウントの復旧方法、権限のある人が解除情報を入手する方法を記録しておく。パスワードなどの秘密情報は保護し、公開する確認表やチャットボットへ書き込まない。「復旧手順は封をした書類にある」と所在を記すことと、秘密の中身を公開することは違う。

resticは、データを暗号化し、パスワードで保護した鍵を使ってアクセスする。データと管理情報を置く領域は、リポジトリと呼ばれる。一つのリポジトリに複数の鍵を持たせることもできる。別の有効な鍵と対応するパスワードが残っていれば、パスワードを一つ忘れただけで永久にデータを失うとは限らない。使える解除手段がすべて失われた場合とは、状況が異なる。この仕組みはresticのリポジトリ作成手順で説明されている。

復元に必要なものが、復元したいデータの中にしかない構成は避けたい。バックアップのパスワードをそのバックアップ内にだけ保存する場合や、パスワードマネージャーの復旧資料が故障したノートパソコンにしかない場合が当てはまる。パスキーの復旧とパスワードマネージャーの移行でも、同じ問題をアカウントへのアクセスから扱っている。

自分でサービスを運営するセルフホスティングでは、運営者が変わるとともに、復旧の責任も自分に移る。自前のサービスと唯一のバックアップを同じパソコンに置けば、その1台を失ったときに両方を失い得る。

検査で確かめられる範囲を知る
#

バックアップの検査は、その検査が対象にした範囲について答える。内部構造の整合性、保存データの読み取り、必要なファイルの復元、内容の一致、ファイルを開けることは、別々の確認だ。一つの成功から、残りも成功したとは判断できない。

2026年9月3日の確認時点で、resticの公式文書は通常のcheckとcheck --read-dataを区別している。通常の検査はリポジトリの構造や参照関係を調べるが、保存されたデータの中身をすべて読むわけではない。resticでは、バックアップのデータをまとめた保存用ファイルをpackと呼ぶ。--read-dataを付けるとすべてのpackを読むため、時間や通信量が大きくなる場合がある。詳細はリポジトリの検査に関する公式文書にある。

内容の変化を調べるために使うのが、ハッシュ値だ。ファイルを構成するバイト列から計算する値で、SHA-256などの方式がある。保存する予定のファイルをまとめた一覧をマニフェストと呼び、サイズやハッシュ値を加えることもできる。残したいファイルから事前に作り、保護しておけば、復元後の比較基準になる。ファイル名自体に個人情報が含まれることもあるため、この一覧もプライバシー対策の対象だ。

確認	成功から分かること	成功しても分からないこと
リポジトリの通常検査	検査した内部構造に整合性がある	保存データの中身をすべて読み、検証できたか
保存データ全体の検査	保存されたpackが、そのソフトのデータ検査を通った	必要なファイルをすべて含めたか。求める版を選んだか
予定一覧との照合	復元したファイルの場所と名前が、別に用意した一覧と一致する	内容も一致するか。利用するソフトで使えるか
ハッシュ値の照合	復元したバイト列が、選んだ比較基準と一致する	比較基準が正しく、求める版で、読める状態だったか
形式や利用ソフトでの確認	試した読み取り手段が、試した内容を扱える	すべての機能や別のファイルも使えるか。将来のソフトも対応するか

バックアップ内の一覧だけを正解にすると、最初から入れ忘れたファイルは見つからない。予定一覧は、バックアップに何が入ったかではなく、何を残すつもりだったかを記録するためにある。

米国議会図書館のデジタル資料管理の用語集も、ビット単位の保存と、将来も利用できるようにすることを区別している。今回の確認では現行ページが取得を拒否したため、2025年9月の保存版を使った。バイト列が一致することには価値がある。しかし、元から形式が壊れていたファイルも、そっくりそのままコピーできてしまう。この違いを実験に含めた。

人工ファイルを使った6条件の復元実験
#

Windows上のrestic 0.19.1で、操作の成功と、必要な記録が戻ることを分けて調べた。保存対象から1個を外した場合も、古い版を選んだ場合も、通常検査・全データ検査・復元はすべて成功した。違いが分かったのは、独立した比較基準と照合したときだった。

対象から何かを除外する前に、7種類の形式で12個のファイルを作った。UTF-8のテキスト、JSON、CSV、XML、ZIP、WAV、TOMLを使い、人工のメモや構造化した記録、ファイルをまとめたZIP、生成した音を用意した。形式に沿って内容を読み取るプログラムをparserという。今回はPythonに標準で付属するparserなどで確認しており、写真閲覧ソフト、オフィスソフト、音声プレーヤーの画面を操作した試験ではない。

各条件で、保存済みのある時点の状態を表すスナップショットを識別番号で指定し、新しい空のフォルダへ復元した。通常検査、全データ検査、復元、予定一覧との照合、ハッシュ値の照合、形式の読み取りは個別に記録している。操作の終了時に返る番号を終了コードといい、0はその操作の成功、0以外はその操作のエラーを示す。個人の保存データ全体に対する合格点ではない。

実測結果
#

条件	通常検査／全データ検査／復元の終了コード	予定したファイルの復元数	その条件で必要な版と一致したハッシュ値	形式の読取成功数／試したファイル数
S1：変更していない正常なファイル	0 / 0 / 0	12/12	12/12	12/12
S2：公開のテスト用パスワードを誤入力	12 / 12 / 12	0/12	0/12	復元ファイルがないため未実施
S3：実験用の保管領域の保存データを1バイト変更	0 / 1 / 1	11/12	11/12	11/11
S4：予定した1個を保存対象から除外	0 / 0 / 0	11/12	11/12	11/11
S5：古いスナップショットを指定	0 / 0 / 0	12/12	11/12	12/12
S6：保存前から不正な形式のJSONがある	0 / 0 / 0	12/12	12/12	11/12

復元数とハッシュ値の分母は、残す予定だった12個で統一している。形式の読み取りでは、復元されて実際に試したファイルだけを分母にした。欠けたファイルは、読み取る内容自体がないため成功に数えていない。S5のハッシュ値は、古いスナップショットから作った一覧ではなく、事前に記録した「必要な現在の版」と比較した。S6では、元から不正だった入力を比較基準にして、内容の保存と形式の読み取りを区別している。

それぞれの失敗が示すこと
#

S2は、間違ったパスワードを一つ試した結果だ。 そのパスワードが拒否されたことは分かるが、別の有効な鍵でも復元できないと示したわけではない。公開しているパスワードは、テスト用と明示したダミー文字列だ。実際のバックアップを守るためには使わないこと。

S3では、周囲の構造を保ったまま、保存データの中身を変更した。 通常検査は成功し、全データ検査と復元は異常を検出した。これは、今回加えた破損についての結果である。通常検査があらゆる破損を見逃すとも、現実の破損で失うファイルが必ず1個に収まるとも言えない。「バックアップの失敗」と一つにまとめると、どの操作が異常に気づいたのか見えなくなる。そのため、私は各操作の結果を分けて残した。

S4は、保存対象の選び方が目的と合っていなかった。 ソフトは指定されたファイルを正常に保存した。しかし、残す予定の一覧にあったdocuments/contacts.csvを、実験では意図的に除外している。有効な除外設定が利用者の希望と食い違っているかどうかを、ソフトが推測することはできない。resticのバックアップ手順を参照し、対象の指定と除外ルールも確認する必要がある。

S5は、選んだ版が目的と合っていなかった。 古いdocuments/status.jsonも正しいJSONであり、復元そのものに問題はなかった。ただし、ハッシュ値は必要な現在の版と異なっていた。数がそろい、読み取れるだけでは、新しさまで確かめたことにはならない。誤削除の前へ戻したいときには、古いスナップショットこそが正解になる。問題なのは古いこと自体ではなく、復元の目的に合う版かどうかだ。

S6では、不正な入力がそのまま保存された。 バックアップを取る前から、documents/records.jsonの形式を意図的に不正にした。resticの3つの操作はすべて成功し、復元した12個すべてのハッシュ値が元の比較基準と一致した。それでもJSONの読み取りは、保存前も復元後も同じファイルで失敗した。原因は元データの状態にあり、復元操作が壊したのではない。残る11個は形式の読み取りにも成功した。

同じ実験を再現する
#

配布する実験プログラムが受け付けるのは、restic 0.19.1の公式Windows amd64版ZIPだけだ。ZIPと実行ファイルのハッシュ値を確認した後、人工ファイルと実験専用のリポジトリを新しく作る。既存の原本フォルダや復元先を指定する機能はない。意図的にデータを壊すのも、その実験内で作ったコピーだけであり、実際に使っているバックアップのリポジトリは受け付けない。

実験方法と限界、結果表、ファイルごとの詳細結果、人工ファイルの予定一覧、公開用に端末情報を除いた実行記録を確認できる。記録したのは生成したファイルだけだ。実行記録では端末固有の識別情報や場所を置き換えているため、端末に表示された文字列を無加工で転載したものではない。

プログラムを読んでから、新しい空の作業フォルダでPython 3.11以降を使って実行する。restic 0.19.1の公式配布ページから対応するZIPを取得し、公式のチェックサム一覧と照合する。その後、次を実行する。

python restore-lab.py --restic-zip restic_0.19.1_windows_amd64.zip

実験用フォルダは、結果を調べられるよう実行後も残る。今回の実行環境はPython 3.12.10だった。小さな人工データと定めた失敗条件を使って仕組みを確かめたもので、故障率の推定やバックアップ製品の比較ではない。ファイルの権限、OS全体の復旧、通信障害、保管場所の独立性、機器の経年変化、利用ソフトの全機能は試験範囲に含めていない。

自分のバックアップを安全に復元確認する
#

新しい空のフォルダへ復元し、原本に変更を加える前に結果を確かめる。目的に合う版を選び、別に用意した予定一覧と内容を照合し、代表的なファイルを普段使うソフトで開く。一部だけを試した結果は、その範囲の確認であり、保存データ全体の合格にはならない。

resticの復元に関する公式文書は、既定の動作で復元先の既存ファイルを上書きすると説明している。他のソフトにも、それぞれの規則がある。使っている版の手順を読み、開始前に復元先を確認すること。試しの復元先に、普段の文書フォルダを指定してはいけない。

何を取り戻したいか決める。 「最後に完了したバックアップまでの手紙と写真」なのか、「昨日削除する前の版」なのかを記録する。必要なフォルダと日付も明らかにする。原本が残っているなら、保存対象の設定とは独立して予定一覧を作り、どの版の一覧かも対応づけておく。バックアップ後に作業中のファイルを更新したなら、保存済みの版と内容が違うのは当然であり、その差だけで復元時の破損とは判断できない。
アクセス手段と空き容量を確認する。 バックアップの所在と、有効な解除方法を確かめる。信頼できるパソコン上に、十分な空き容量を持つ別の空フォルダを用意する。復元したファイルは暗号化されていない状態になる場合がある。復元先を保護し、意図しない同期や共有の対象に入れない。
保存済みの版を具体的に指定する。 識別番号と該当する日付を残す。「最新」は並び順に関する指定であり、必要な変更が入っている証明ではない。
公式手順に沿って検査と復元を行う。 内部構造の検査と、全データを読む検査を区別する。復元時だけでなく、元のバックアップ作成時に出た警告やエラーも確認する。スナップショットが存在していても、元ファイルをすべて読めたとは限らない。
目的を満たしたか確かめる。 予定したファイル名と場所、代表的な内容と版、用意してあれば信頼できるハッシュ値を照合する。文書を開き、写真を見て、音声を再生する。その記録を使ううえで必要なソフトの機能も試す。何を確認し、何が未確認なのかを記録する。
検証が済むまで、使えるコピーを残す。 試しの復元が成功しても、ほかに使える唯一のコピーを消す理由にはならない。確認後の試用ファイルは、自分の保管方針に従って保護または削除する。食い違いを調べている途中で、元に戻せない整理をしない。

時間や容量の都合で全体を復元できないなら、まず範囲を限って試し、その制限も記録する。確認範囲は後から広げられる。すでに原本がなく、独立した予定一覧もない場合は、「全部そろっているかは不明」と残す。生き残ったバックアップの件数だけでは、その答えは出ない。

保存場所とともに、読める状態も維持する
#

長期保存では、媒体、接続方法、読み取り機器、ファイル形式、解除手段を定期的に確かめる必要がある。一つの保存素材について示された寿命は、その期間ずっと記録全体を復元できるという保証ではない。

米国議会図書館の個人のデジタル記録に関する案内は、保存したファイルを少なくとも年1回確認し、5年ごと、または必要に応じて新しい媒体へコピーするよう勧めている。媒体の耐久性に関する資料は、寿命の見積もりが不確かになる理由を説明している。この周期は保守の目安であり、次の確認日までドライブが壊れないという約束ではない。データの移行、解除方法の変更、故障の疑いがあったときにも確認する。

維持するもの	残すもの・見直すこと	記録する確認結果
媒体と接続手段	使える媒体と、対応するドライブ・ケーブル・接続口を利用できる状態	コピー全体を読んだ日、見つかったエラー、移行の結果
記録の意味とファイル形式	原本、記録の説明、必要に応じた書き出し版や閲覧用コピー	どのソフトでどのファイルを開けたか。変換で失った機能
暗号の解除とアカウントへのアクセス	保護した復旧情報と、権限のある人がそれを入手する方法	秘密情報自体は書かず、復旧を実際に試して成功した記録
保存対象と版	予定一覧と、その記録に合う保管期間の方針	欠けたファイル、必要な版、直近の確認で調べた範囲

「HDDは何年」「SSDは何年」という一律の数字だけで、ディスクを選ぶことはできない。同様に、VerbatimのM-DISCの長寿命に関する説明は光ディスク製品についての主張である。将来も対応ドライブを使え、解除情報が残り、ファイル形式を読み取れることまで保証するものではない。米国国立公文書館も、光ディスクを含む映像用媒体の寿命の不確かさと保管条件を説明している。こうした限界があるからといって、すべての光ディスクが故障するという結論にはならない。

形式やソフトが使いにくくなってきたら、原本を残したうえで、閲覧用のコピーを作って変換内容を記録する。複雑な文書では、変換によって配置や機能が失われることがある。変換すればバイト列も変わるので、新しいハッシュ値が原本と違うこと自体は異常ではない。その記録で重要な内容を保てたか確かめ、変換版と分かる名前を付け、変換版の比較基準を新しく作る。フォルダを整えるために原本を上書きしないこと。

今回の実験では、各操作の結果と並べて、残す予定のファイル、必要な版、読み取りの確認を記録した。欠けたファイルには対象設定の見直しが要る。古い版には、どの時点へ戻すかの判断が要る。元から読めない記録には、その内容を使える形で残す作業が要る。ディスクをもう一台買うだけでは、これらの問題は解決しない。

よくある質問
#

クラウド同期はバックアップになりますか？
#

過去の版や削除したファイルを必要な期間だけ残すサービスなら、一部の復旧機能を担えます。保存期間や削除の規則、アカウントの復旧に必要な条件を確認してください。同期しているだけでは、望まない変更、削除、アカウントを失った場合にも取り戻せるとは言えません。

resticの検査が成功すれば、全ファイルが安全ですか？
#

いいえ。通常の検査は、保存されたすべてのpackの中身を読むものではありません。全データ検査でも、残す予定のファイルをすべて含めたか、必要な版を選んだか、復元後に利用するソフトで読めるかまでは分かりません。

パスワードを忘れた暗号化バックアップは復元できますか？
#

使っているソフトと、ほかに残っている解除手段によります。resticでは、パスワードで保護した鍵を複数持てます。別の有効な鍵と対応するパスワードがあれば、使える可能性があります。保存サービスの事業者なら暗号を解除できると決めつけたり、パスワードが一つ通らなかっただけですべての復旧手段を失ったと判断したりしないでください。

個人の保存データは、どれくらいの頻度で確認すればよいですか？
#

米国議会図書館は、保存したファイルを少なくとも年1回確認するよう勧めています。重要な記録の更新頻度も踏まえて周期を決め、保存先、ソフト、復旧のためのアクセス手段に大きな変更があったときにも試してください。一部だけを確認したのか、全体なのかも記録します。決めた日付に点検したことや、少数のファイルで成功したことだけで、その後も復元できると保証されるわけではありません。

何十年もファイルを残せる記録媒体はどれですか？
#

どの媒体を選んでも、独立したコピー、点検、移行は必要です。媒体そのものに加え、保管条件と、対応する読み取り機器を使えるかを考えてください。長く利用できるかどうかには、形式、ソフト、解除情報も関わります。新しい閲覧用コピーを作るときも、検証済みの原本は残してください。

出典と実験の記録
#

一次資料の確認日は2026年9月3日。実験結果は、記載した実行環境と人工データについての観測である。保存版は資料の履歴を残すために併記しており、主張の確認に使った現行版より古い場合がある。

#	一次資料	原文	保存版
1	CISA：バックアップの選択肢	PDF	2026-08-05
2	CISA：ランサムウェア対策ガイド	ガイド	2026-08-30
3	restic：新しいリポジトリの準備	公式文書	2026-08-19
4	restic：リポジトリの管理と検査	公式文書	2026-08-22
5	restic：バックアップからの復元	公式文書	2026-08-22
6	米国議会図書館：デジタル資料管理の用語集	用語集・現行本文は取得拒否	2025-09-16
7	米国議会図書館：個人のデジタル記録	ガイド	2026-08-28
8	米国議会図書館：デジタル記録媒体はどれほど長く持つか	PDF	2025-11-07
9	Verbatim：M-DISC光ディスク	メーカーの説明	2026-05-02
10	米国国立公文書館：映像用媒体の状態評価	保存の指針	2026-05-15
11	restic：バックアップの作成	公式文書	2026-08-22
12	restic 0.19.1：リリース情報	公式配布ページ	2026-08-18・変更説明の保存版。実行ファイルの配布元ではない

Cora Aegis

Cora AegisはCypherpunkGuideで、プライバシーとデジタル環境を自分で管理するための方法を書いている。この記事では、人工データによる暗号化バックアップの復元実験を設計・確認し、結果をresticの公式文書と長期保存の指針に照らし合わせた。個人のバックアップデータは使っていない。

Cora Aegisについて →

セルフホスティングと主権 2026——五層で採点する自己監査

Wed, 01 Jul 2026 00:00:00 +0000

ここ数年のどこかで、「自前で立てろ」が、あらゆるプライバシー問題への反射的な答えになった。Google のクラウドを借りず、自分のクラウドを動かせ。企業のノードを信じず、自分の Bitcoin ノードを動かせ。自分のメールサーバー、自分の VPN、自分のなにもかもを動かせ——そうすれば Big Tech に何ひとつ借りずにすむ、と口上は続く。ここに添えられる言葉が主権だ。美しい言葉である。そして多くの場合、この言葉は、下で支えている構成が背負いきれる以上の重みを、背負わされている。

居心地が悪いのは、セルフホスティングが無駄だからではない。五層からなる問題のうち一層か二層を解いただけなのに、五層すべてを解けたかのような安心を、そっと先取りしてしまう——そこが落とし穴だ。ホスト——一台の物理マシン上で多数の仮想マシンを動かすソフトウェアの層、hypervisor——にそのメモリを読まれるレンタルサーバーは、自分で握った演算とは言えない。自宅で立てたサービスも、接続の metadata を ISP に渡し続けるし(ISP はそれを何か月も保持できる)、それがメールサーバーなら、地球上のあらゆる受信側プロバイダにも渡してしまう。そして、鍵からパケットまで完璧に組み上げたスタックも、そのドメインを本名で登録した瞬間、あるいはあなたに辿り着くカードで支払った瞬間、崩れ落ちる。

ノード運用の手引き、VPS プロバイダの文書、公開されているメールサーバーの runbook を読み込んで、私たちは三つの典型的な構成——自宅の Bitcoin ノード、レンタル VPS 上の Nextcloud、自前のメールサーバー——を、五層の主権モデルに照らして採点した。そしてそのどれでも、最も弱い層は、その構成が解こうとして組まれた当の層ではなかった。この記事が扱うのは、この繰り返しだ。主権とは、他人のプラットフォームから処理を自前に移しさえすれば手に入る称号ではない——いまなお現に露出している層でしか主張できない、一つの性質だ。これは売り込みのページではなく、自己監査である——自分の構成を正直に採点し、残り全部をそっと台無しにしている一層を、探し当てるための道具だ。

デジタル主権が、本当に求めるもの
#

デジタル主権とは、あるサービスが依存するすべての層——鍵、データ、ハードウェア、通信、そしてその背後にある身元——に対する、排他的で、強要の効かない支配のことだ。そしてセルフホスティングは、それ自体では、せいぜいそのうち一つか二つしか渡してくれない。よくある間違いは、主権を、処理を自前に移せば切り替わる二値の入切として扱うことだ。それは二値でもなければ、単一のものでもない。それはスタックであり、スタックが主権的でありうるのは、最も弱い層の分だけだ。

いま言ったこの一文が要になるので、はっきり述べておく——主権とは、各層にわたる最小値であって、和ではない。 保管で十点満点中の九点をとっても、身元が二点なら、その構成は総合では二点にしかならない。敵は強い層でなく、弱い層を突くからだ。これは、鎖にも、脅威モデルにも、セキュリティ境界にも通じる同じ理屈だ——守る側はどこも間違えてはならず、攻める側は一か所だけ当てればいい。各層を平均してその合計に安心するのは、この枠組みがまさに断ち切るために存在する、あの自己欺瞞そのものだ。

もう一つ、より気づきにくい罠がある——セルフホスティングは、依存を消すよりも、はるかに頻繁に、依存を別の場所へ移し替える。 クラウドから自宅サーバーへ移っても、依存から逃れたわけではない——Amazon への依存を、電力会社、インターネット回線業者、ハードウェアを作った半導体の供給網、パケットが横切る Tier-1 網、そして TLS を信頼させる認証局への依存と、取り替えただけだ。これらの依存はより静かで、忘れやすい——だからこそ、それが主権のように見えてしまう。独立した感覚は本物だ。だが独立そのものは、しばしば本物ではない。自分が実際に断ち切った依存はどれで、たんに見えにくい場所へ移しただけの依存はどれか——それを名指すこと、それがこの営みのすべてだ。

五層で採点する、主権の自己監査
#

役に立つ主権の監査は、独立した五つの層——保管・データ・演算・通信・身元——を採点する。ある構成が、ある層で強く、別の層で丸裸ということがありうるからだ。そして、そのどちらかを見せてくれるのは、層ごとに一つずつ見るやり方だけだ。下が、私たちが採点に使うモデルだ。いちばん右の列から読んでほしい——「自前で立てた」あとになお漏れ続けるものの一覧であり、正直な仕事のほとんどが、そこに宿っている。

層	ここでの主権の意味	セルフホスティングの通常の点	なお漏れるもの
1. 保管(custody)	鍵と root の秘密を、あなただけが握る	✅ たいてい、唯一うまくやれる層	手の届くサーバー上のホットキー、バックアップの保管先
2. データ(data)	第三者が読めず、強要もされえない	◐ まちまち	保存時の暗号化 ≠ 使用時、誰が召喚状の対象になるか
3. 演算(compute)	コードを実行するハードウェアを、あなたが握る	✗ どんなレンタルサーバーでも落ちる	ホストは guest の RAM を読める、実行中の平文
4. 通信(network)	到達性と metadata が、一人の監視者に依存しない	✗ たいてい、減るのでなく増える	ISP が宛先と時刻を見る、メール metadata が各中継へ
5. 身元(identity)	仮名性と、管轄の分離が保たれる	✗ 静かなとどめ役	本名のドメイン、KYC に紐づく決済、あなたに辿り着く一枚のカード

これらを分ける理由は、各層が、互いに独立して、それぞれ別の理由で落ちるからだ。保管は所持の問題——秘密を握っているか。演算はハードウェアの信頼の問題——誰のシリコンがあなたの平文を動かすか。通信はmetadata の問題——中の手紙とは関わりなく、封筒を誰が見るか。身元は名寄せの問題——現実の何か一つの事実が、その全体をあなたに結び戻さないか。一つを解いても、他の層には何も効かない。そして強い層が、弱い層を見過ごさせる油断を生む。この監査のただ一つの掟は、前節のそれだ——あなたの点は、平均でなく、いちばん低い行だ。 続く三つの節では、セルフホスターが最も確実に取りこぼす三つの行を、順に扱う。

演算と通信——セルフホスティングが、そっと漏らす層
#

セルフホスティングが最も苦手な二層は、最も得意だと感じられる二層でもある——レンタルサーバーは自分で握った演算とは言えないし、自宅サーバーは、クラウドのアカウントより通信 metadata を多く漏らすのがふつうで、けっして少なくはない。安心感が最も強く、実態が最も薄いのがこの二層だ。だからこそ、いちばん正確な言葉で語る必要がある。

まずレンタル VPS 上の演算から。仮想サーバーを借りると、自分の手にない hypervisor があなたの仮想マシンを動かし、設計上、その hypervisor は VM のメモリを読める——データが RAM のどこにあるかを示すページテーブル(CPU が持つ、データの在処の地図)そのものを、hypervisor が管理しているからだ。ここでディスク暗号化は助けにならない——保存時の暗号化が守るのは、マシンが止まっているときのディスクだけだ。だが動いているサーバーは、鍵と平文を RAM に抱えており、ホストはその RAM を読める。これは、プロバイダが実際に覗いているという告発ではない——覗くことができ、こちらの構成では何をどうしても止められない、という指摘だ。つまり演算は、会社がどれほど評判の良い相手であっても、あなたの信頼境界の外にある。ただ一つの本物の直し——CPU がホストに対して guest メモリを暗号化する confidential computing(AMD SEV-SNP、Intel TDX)——は存在し、大手クラウド(Azure、Google Cloud)はいまや上位オプションとしてそれを提供している。だが、多くのセルフホスターが2026年に実際に使う量販の VPS プランには、それはまだ無い。自前のベアメタルを持てば、問題は移るが、物理的な露出が戻ってくる——電源を切った数秒のうちに RAM から暗号鍵を復元するcold-boot 攻撃も、そこに含まれる。

演算の形	実行中、あなたのデータを読めるのは誰か	残る露出	主権的な演算か
レンタル VPS(標準)	ホスト——hypervisor が guest の RAM を読める	プロバイダのデータセンターと従業員	ノー——信頼境界の外
レンタル VPS + confidential computing	CPU がホストに対して RAM を暗号化する	2026年には稀、ファームウェア/attestation への信頼	実際に使える範囲では、部分的
自前のベアメタル	物理的に近づける者だけ	cold-boot と、物理的な差し押さえ	イエス、物理的な守りがあれば

通信の層こそ、セルフホスティングの神話が最も裏返るところだ。直感では、自宅サーバーなら通信は秘密に保たれる気がする。だが実際には、あなたの ISP があらゆる接続の metadata を見ている——宛先アドレス、時刻、量、そして、暗号化 DNS と暗号化 SNI(Server Name Indication——TLS の handshake のうち、放っておけばどのサイトへ向かうかを露わにしてしまう部分)を用意していない限り、たどり着くドメイン名そのものまで。通信内容の暗号化は、封筒を隠さない——EFF の Surveillance Self-Defense プロジェクトが説くとおり、metadata だけでも実に多くが分かる——中身が暗号化されていても、どのサイトへ接続するかを含めて。自宅サービスは、これを悪化させうる——常時稼働のサーバーは、目立つ、途切れない通信の型を生み、断続的な閲覧よりも輪郭を描かれやすい。そして自前のメールサーバーは、プロトコルの設計そのものによって漏らす——SMTP は、Received ヘッダの連なりと送信元の IP をあらゆるメッセージに刻み込み、各受信側プロバイダと、その間のあらゆる中継に、露わにする。metadata の外へ、セルフホスティングで抜け出すことはできない——できるのは、誰がそれを集めるかを選ぶことだけであり、そしてセルフホスティングは、しばしばあなた自身の名と住所を、記録上の集める側として選んでしまう。これは、『AI 非匿名化のプレイブック』で私たちが追ったのと同じ名寄せの領域だ——散らばった「無害な」metadata が、束ねられる。

身元と管轄——スタックを崩落させる、あの層
#

身元は、他のどこでも完璧でありうるのに、それでもすべてを引きずり倒す層だ——本名のドメイン登録が一つ、KYC に紐づく決済が一つ、あるいはあなたに辿り着くカードが一枚あれば、鍵からパケットまで完璧なスタックが、たった一度の照会で非匿名化される。そしてこれは、ほぼどのセルフホスティングの手引きも省く層でもある。技術の設定ではなく、誰が何に払ったかという、退屈な紙の跡だからだ——主権が最も頻繁に、そっと息絶えるのが、ここである。

その仕組みは、容赦がない。自分のノードを動かし、自分の鍵を握り、なにもかも暗号化して——そのうえで、それを賄ったコインが、政府発行の身分証を確認した取引所から来ていた、というわけだ。中央集権的な取引所の圧倒的多数が KYC を強制する——コンプライアンスベンダー Sumsub の集計では 90% を超える。そして、あらゆる法定通貨の入口が身元の検問所になっている。あるいは、VPS があなたの名義のカードで払われている。あるいは、ドメインの登録業者が、あなたの本当の詳細を握っている。あるいは、その三つすべてが一つの請求上の身元を共有し、「主権的な」インフラを一人の法的な人物へ束ねてしまう。決済経路の分離を欠いた保管の主権は、ガラスの壁にはめ込まれた施錠ドアだ——だからこそ私たちは、『KYC なしで Bitcoin を買う』ことと、『オンチェーンの決済プライバシー』を、スタックへの後付けでなく前提として扱う。そしてだからこそ、鍵を握ることは、現実の敵が相手に回った途端、『必要であっても、十分ではない』のだ。

管轄は、身元の層の法的な双子であり、広く誤解されている。 よくある思い込みは、データが物理的にどこに置かれるかが、誰がそれを強要できるかを決める、というものだ。米国の CLOUD Act(Clarifying Lawful Overseas Use of Data Act、海外データの合法的利用明確化法)のもとでは、それは端的に誤りだ——米国を拠点とするプロバイダは、そのデータが世界のどこに保存されていようと、その提出を強制されうる(18 U.S.C. § 2713)。管轄は、バイト列の物理的な所在ではなく、プロバイダの法的な住所に従うからだ。米国企業から EU 所在のサーバーを借りても、あなたのデータが米国の手の届かない場所へ出ていくわけではない。ここは、本物のセルフホスティング——自分が持つハードウェアで、自分の管轄で——が、実際に構図を変える場面だ。そもそも命令を突きつけられうる第三者プロバイダを、取り除くからである。だが、それが代わりに何を差し込むかに、目を向けてほしい——あなたの管轄における、直接の法的・物理的な露出だ。命令は、データセンターの扉ではなく、あなたの家の扉に来る。セルフホスティングは、管轄の問題を消しはしない。企業への強要点を、個人への強要点にすげ替えるだけであり、どちらの取引が安全かは、あなたが誰で、どこに住んでいるかに、まるごと懸かっている。

その「あなたが誰か」は、脚注ではない。家庭内暴力(DV)の生存者にとって、反体制の人にとって、あるいは安全が仮名に懸かっている人にとって、身元の層はチェックリストの最後の項目ではない——そこがまるごと肝心なところだ。明示的な脅威モデルなしに書かれたセルフホスティングの手引きが、価値ゼロと切り捨ててしまう、当の層である。あなたの名を WHOIS レコードや決済の台帳に載せてしまう主権は、そもそも本当には危険になどなかった人のための主権だ。

三つの構成を、五層で採点する
#

現実の構成を層ごとに採点すると、最弱層の掟はもはや抽象論ではなくなる——下の三つのどれも、組むために狙った当の層はきっちり決める一方、別の一層を、全体の点を左右するほど深く落としている。採点はわざと粗くしてある——狙いは露出の形をつかむことであって、見せかけの精密さではない。

構成	保管	データ	演算	通信	身元	本当の主権(=最弱)
自宅の Bitcoin ノード	強	強	強(自分のハードウェア)	弱(ISP がノードの通信を見る)	弱(KYC のコイン)	弱——通信 + 身元
レンタル VPS 上の Nextcloud	中	弱(ホストが読める)	極弱(hypervisor)	弱(プロバイダ + ISP)	中	極弱——演算
自前のメールサーバー	強	中	場合による(VPS か自前か)	極弱(SMTP metadata)	弱(IP ↔ 本名)	極弱——通信

自宅の Bitcoin ノードは、人々が引き合いに出す成功例であり、保管・データ・演算では、その称賛に値する——鍵は自分のもの、検証は自分のもの、ハードウェアも自分のものだ。だが監査を回すと、点は通信と身元の層まで落ちる——あなたの ISP はノードの通信を見るし(Blockstream 自身の指針が、まさにこのために Tor を勧めている)、コインが KYC の取引所から届いていたなら、身元の層は最初から主権的ですらなかった。レンタル VPS 上の Nextcloud は、自分のクラウドを持った気にさせるし、実際 Google Drive よりは保管を良くする——だが演算の層は設計上ホストに読まれるので、「あなたの」クラウドは、プロバイダに読み取れる。そして自前のメールサーバーは、三つのうち最も骨の折れる案件であり、強い保管を買っておきながら、通信層の metadata を、SMTP 越しにあらゆる相手のプロバイダへ流し続ける。三つとも、労力は目に見える層に注がれ、露出は静かな層に宿っている。それは偶然ではない——ここで「劇場」と呼ぶのは、まさにこれだ——観客(そして運営者)の目が向いている、ちょうどその場所に集めて演じられる、主権の上演である。

サイファーパンクの読み——仕組みそのものに、組み込め
#

サイファーパンクは、その底にある問いを三十年前に決着させていた。プロバイダを、管轄を、あるいは自分自身の律し方を信じることに頼るプライバシーは、恵みとして与えられたプライバシーにすぎない。長持ちするプライバシーは、仕組みそのものに組み込むほかない——彼らはそう結論した。セルフホスティングの論争に照らせば、これは懐古ではない——監査のどの層にも当てられる、一つの設計の試験だ。

「私たちは、政府や企業、その他の顔の見えない巨大な組織が、その善意からプライバシーを与えてくれるなどとは、期待できない。……プライバシーを持ちたいなら、自分自身で守らねばならない。」——Eric Hughes『A Cypherpunk’s Manifesto』、1993年

2026年へ携えたこの宣言の要点は、問いが決して「このホストを、この ISP を、この登録業者を、私は信じるか」ではない、ということだ——問いは「私が信じなかったとしても、私のプライバシーは生き延びるか」だ。レンタル VPS は、その試験に演算の層で落ちる。自前のメールサーバーは、通信の層で落ちる。KYC で賄ったノードは、身元で落ちる。セルフホスティングは、本物のサイファーパンクの本能だ——『宣言』の「自分自身のプライバシーを守れ」を、具体的な形にしたものである。だがその本能が報われるのは、信頼の依存を、移し替えるのでなく取り除くときだけだ。最も長持ちする一手は構造的なものであり、それは個人の技術が制度の権力とぶつかるときに通用するのと同じ教訓だ——どの一者も裏切らないことに賭ける設計よりも、どの一者も裏切ることができない設計を選べ。

結論——まず、いちばん弱い層を直せ
#

唯一実りのある一手は、いちばん弱い層を見つけ、それを最初に直すことだ。他のあらゆる改善は、最小値で頭打ちになるからである。 間違いは、すでに分かっている層を磨くことだ。この監査の見返りは、これまで避けてきた層を名指してくれる点にある——私たちが採点した三つの構成では、決まって通信か身元だった——そして、あなたの本当の点を決めているのは、たいていその層なのだ。

ハードウェアを買う前に、監査を回す。 いまの構成の五層すべてを正直に採点し、最小値を見つけること。いちばん弱い層が身元なら——KYC に紐づくコイン、本名のドメイン、あなたに辿り着くカード——どれだけ新しいハードウェアを足しても効かない。まず紙の跡を直すこと。それが、上のすべてに天井を課しているのだから。
見えない演算の税を、払うのをやめる。 主権が目的なら、レンタル VPS はあなたが握った演算ではない。その上にあるものは何でも、ホストに読み取れると扱うこと。レンタルのインフラでのセルフホスティングは、それを許容できる処理のためにとっておき、許容できない処理には、自前のハードウェア(その物理的・管轄的な露出は受け入れたうえで)を使うこと。
通信の層は漏れると想定し、それに備える。 あなたの ISP と、あらゆるメールの中継は、通信内容の暗号化に関わらず metadata を見る。暗号化 DNS と SNI、対応するサービスには Tor、そして——公開メールのように——プロトコルが身元を広く撒くたぐいの仕事は、そもそもセルフホストしないこと。それらは、サーバーをもう一台足すより価値がある。
どの層も、サイファーパンクの試験で判じる。 「この相手を信じるか」ではなく、「信じなくても、私のプライバシーは保たれるか」で。五層すべてでその試験を通る構成は、主権的だ。四層で通る構成は、五層目とちょうど同じだけ、主権的である。

主権とは、処理を自前に移せばたどり着ける場所ではない。それは、いまなおさらされている層でしか主張できない、一つの性質だ——そして正直な一手は、その層を見つけ、たんに移し替えただけの依存を名指し、その取引が値したかどうかを、目を見開いて決めることである。

要点

主権は和でなく、最小値だ： あなたの本当の点は、いちばん弱い層——保管・データ・演算・通信・身元——で決まる。敵は、強い層でなく、弱い層を突くからだ。
レンタル VPS は、あなたが握った演算ではない： hypervisor は設計上あなたの VM の RAM を読めるし、保存時の暗号化は、動いているサーバーを守らない。直しは confidential computing だけで、2026年にはなお稀だ。
セルフホスティングは、通常、通信 metadata を減らすのでなく増やす： あなたの ISP は、通信内容の暗号化に関わらず宛先と時刻を見るし、自前のメールサーバーは、SMTP 越しに、身元を明かす metadata をあらゆるメッセージへ刻む。
管轄は、バイト列でなくプロバイダに従う： 米国の CLOUD Act のもとでは、米国企業は、世界のどこに保存したデータでも引き渡しを強制されうる——だから米国プロバイダから借りた EU 所在のサーバーも、手の届かない場所にあるわけではない。
身元は、スタック全体を崩落させる： KYC に紐づく決済が一つ、あるいは本名のドメインが一つあれば、鍵からパケットまで完璧な構成が非匿名化される。そしてそれは、ほとんどの手引きがまるごと省く層だ。

よくある質問
#

セルフホスティングは、クラウドを使うよりプライバシーが守られますか？
#

自動的にそうなるわけではなく、層によっては、かえってプライバシーが弱くなります。セルフホスティングは、保管を——そして、自分が持つハードウェアの上でなら、演算を——良くできます。鍵を握り、マシンを支配するからです。ですが通信 metadata には何もしませんし(あなたの ISP は依然として通信を見ます)、しばしば悪化させます。常時稼働の自宅サーバーは、目立つ通信の型を持つからです。そして自前のメールサーバーは、主流のプロバイダより多くの、身元を明かす metadata を、積極的に漏らします。プライバシーは層ごとの問いです。「自前で立てた」は、五層のうち一つか二つに答えるだけです。

VPS のプロバイダは、私のデータを読めますか？
#

はい、演算の層で。そして、ふつうの暗号化ではそれを防げません。あなたの仮想マシンを動かす hypervisor は、設計上、そのマシンのメモリを読めます。ディスク暗号化は保存時のデータを守りますが、動いているサーバーは鍵と平文を RAM に抱えており、ホストはそこへ手が届きます。あるプロバイダが実際にそれをするかは信頼の問題ですが、その能力があるということは、レンタル VPS 上の演算があなたの支配の外にある、ということです。confidential computing(AMD SEV-SNP、Intel TDX)が唯一の本物の直しで、大手クラウドは上位オプションとして提供しますが、多くの人が使う量販の VPS プランには、まだ無いのです。

データをヨーロッパに置けば、米国の法律から守られますか？
#

プロバイダが米国企業なら、守られません。米国の CLOUD Act は、データが世界のどこに保存されていようと、米国を拠点とするプロバイダにその提出を強制します。管轄が、バイト列の物理的な所在ではなく、プロバイダの法的な住所に従うからです。米国企業が持つ EU のデータセンターも、なお手の届く先にあります。第三者プロバイダをまるごと取り除くこと——自分が持つハードウェアでの、本物のセルフホスティング——はこれを変えますが、あなた自身の管轄における直接の法的露出を、代わりに差し込みます。

典型的なセルフホスティングの構成で、いちばん弱い層はどこですか？
#

たいていは身元か通信です。それらは、人々が「ホスティング」の一部として思い浮かべない層だからです。自宅の Bitcoin ノードは、保管と演算では完璧でありながら、KYC に紐づくコイン(身元)や、ISP から見える通信(通信)によって、なおあなたに結びつけられえます。あなたの本当の主権は、いちばん弱い層に等しいので、紙の跡と metadata を直すことが、どんなハードウェアの増強よりも効く、ということがしばしば起こります。

セルフホスティングによる「デジタル主権」は、ただのマーケティングですか？
#

その言葉は売られすぎていますが、実践そのものは無価値ではありません。セルフホスティングは、支配を確かに移し替えます——正直な問いは、それが信頼の依存を取り除くのか、それとも、たんにより見えにくい場所(あなたの ISP、電力会社、ハードウェアの供給網、認証局)へ移すだけなのか、です。それが本物の主権になるのは、ほかのやり方でなら強要されえた、あるいは裏切りえた相手を、取り除いた層だけです。その試験に照らして層ごとに採点すれば、一部のセルフホスティングは本物の主権であり、その多くは劇場なのです。

#	出典	URL	アーカイブ
1	米国 CLOUD Act——Cross-Border Data Forum の FAQ	https://www.crossborderdataforum.org/frequently-asked-questions-about-the-u-s-cloud-act/	https://web.archive.org/web/*/https://www.crossborderdataforum.org/frequently-asked-questions-about-the-u-s-cloud-act/
2	EFF Surveillance Self-Defense——なぜ metadata が重要か	https://ssd.eff.org/module/why-metadata-matters	https://web.archive.org/web/*/https://ssd.eff.org/module/why-metadata-matters
3	Wikipedia——Cold boot 攻撃	https://en.wikipedia.org/wiki/Cold_boot_attack	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Cold_boot_attack
4	Blockstream——Bitcoin ノードを安全かつ私的に保つには	https://help.blockstream.com/education/nodes/set-up-and-optimization/how-do-i-keep-my-bitcoin-node-secure-and-private	https://web.archive.org/web/*/https://help.blockstream.com/education/nodes/set-up-and-optimization/how-do-i-keep-my-bitcoin-node-secure-and-private
5	IETF——RFC 5321、Simple Mail Transfer Protocol(trace / Received ヘッダ)	https://www.rfc-editor.org/rfc/rfc5321	https://web.archive.org/web/*/https://www.rfc-editor.org/rfc/rfc5321
6	VPSBG——Intel SGX 対 AMD SEV(confidential computing)	https://www.vpsbg.eu/blog/intel-sgx-vs-amd-sev-the-ultimate-comparison/	https://web.archive.org/web/*/https://www.vpsbg.eu/blog/intel-sgx-vs-amd-sev-the-ultimate-comparison/
7	Sumsub——カストディアル対ノンカストディアルのウォレットと KYC	https://sumsub.com/blog/custodial-vs-non-custodial-wallets/	https://web.archive.org/web/*/https://sumsub.com/blog/custodial-vs-non-custodial-wallets/
8	Eric Hughes——A Cypherpunk’s Manifesto(1993年)	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html
9	米国 CLOUD Act——18 U.S.C. § 2713(条文)	https://www.law.cornell.edu/uscode/text/18/2713	https://web.archive.org/web/*/https://www.law.cornell.edu/uscode/text/18/2713

Cora Aegis

Cora Aegis は CypherpunkGuide で、プライバシーを最優先する OPSEC の指針を書いている。プライバシー界隈の道具とうたい文句を、その下にある仕組みから読み解く——ここでは、「セルフホスティング」が、なぜある層では主権の名に値し、別の層ではそれをそっと借りているだけなのかを。

Cora についてもっと読む →

Bitcoin Silent Payments 実践ガイド 2026 — 自分で実装して確かめた仕組みと使いどころ

Thu, 09 Jul 2026 00:00:00 +0000

資金について: CypherpunkGuide には監視型の広告は載せていません。広告ネットワークも、追跡ピクセルも、記事広告もありません。資金は透明な流れで成り立っています——現在は読者の寄付、今後は subscription と編集方針に沿った affiliate です。私たちが向き合うのは広告主ではなく、読者です。

Bitcoin を受け取ろうとすると、小さく静かな矛盾に突き当たります。どのガイドも、アドレスを再利用してはいけないと説きます——再利用は、チェーン分析者にとって最もはっきりした手がかりの一つだからです。ところが、いざ支払いを受けたいとなると話は変わります。プロフィール欄の投げ銭アドレス、README に載せた寄付の一行、一度送って忘れてしまう請求書——こうした場面では、動かない、据え置きのアドレスが要ります。アドレスを回していくことと、変わらない受け取り先を持つことは、たがいに逆を向いているのです。

Silent Payments(BIP-352)は、この矛盾を解くプロトコルです。あなたが公開するアドレスは一つ。けれど、あなたに支払う人はそれぞれ、そこから別々のオンチェーンアドレスを導き出します。ですからチェーンを眺める第三者の目には、共通の宛先を持たない、互いに無関係な出力が並ぶだけです。これは、ここ数年で受信のプライバシーに起きた最も大きな変化の一つです。同時に、広く誤解され、ウォレットごとに中途半端にしか実装されておらず、そして——熱のこもった紹介記事がつい省いてしまう——現実の代償を抱えてもいます。

私は仮名で書き、手元のコインはどれも、すでに見られているものとして扱います。ですから、このプロトコルを鵜呑みにする気にはなれませんでした。このガイドを一文字も書き始める前に、私は BIP-352 を Python で一から実装しました——coincurve ライブラリ越しに libsecp256k1 を使っています——そして仕様書の公式テストベクターに通しました。結果は、送信 28サブケース中 28、受信 29サブケース中 29 が、1ビットの狂いもなく、200ミリ秒未満で一致しました(バンドルのログ)。以下は、その動く実装から見えたものです——何を守り、2026年にどのウォレットがそれを届け、そして頼りにする前に理解しておくべきスキャンの代償を、順に見ていきます。

謳い文句	実際のところ	落とし穴
「アドレス一つで、完全なプライバシー」	アドレスは一つ、ただし守られるのは受信だけ	金額も、あなたに送る相手も、手つかずのまま
「ミキシングの代わりになる」	CoinJoin とは別の問題を解いている	混ぜてはいない。再利用の結びつきを断つだけ
「公開したら、あとは忘れていい」	公開はタダ。けれど受信はタダではない	誰かが、あなたのコインを求めてチェーンをスキャンする必要がある
「いまはどのウォレットも対応済み」	送信は当たり前。受信のほうが新しい	ウォレットごと・バージョンごとに、送信と受信を別々に確かめる

Silent Payment とは実際に何なのか(そして何を守らないのか)
#

**Silent Payment とは、BIP-352 が定める再利用可能な Bitcoin アドレスです。あなたが一度だけ公開する一つの文字列から、支払う側は、あなた宛ての一意で結びつけようのないオンチェーンアドレスを導き出せます。これが守るのは受信の結びつき——同じ相手に宛てた別々の支払いが、互いにひもづいてしまうこと——だけであって、ほかは何も守りません。**金額を隠すわけではなく、あなたに送る相手を守るわけでもなく、コインをあなたの名前に結びつけるオフチェーンの記録にも、手を出しません。

このアドレスは、二つの公開鍵——scan key(スキャン鍵)と spend key(支出鍵)——を一つにまとめて符号化したものです。メインネットでは sp1 で、テストネットでは tsp1 で始まります(人間が読める接頭辞は sp / tsp で、1 は bech32m の区切り文字にすぎません)。誰かがあなたに支払うとき、その人のウォレットは、自分の入力鍵とあなたの scan key を組み合わせて共有秘密を計算し、そこから、あなただけが見つけて使える新しい Taproot 出力を導き出します。二人の支払人が同じ出力を生むことはなく、結びつきを告げる「通知トランザクション」も存在しません——ここが、古い BIP-47 の payment-code 方式に対する決定的な改良点です。

何が守られずに残るのかは、はっきり言葉にしておく価値があります。この分野では、「プライベート」という一語が、実力以上の働きをさせられがちだからです。Silent Payments は受信のための道具です。受け取る金額は、いまもオンチェーンに見えています。支払う側のプライバシーは、あなたではなく、その人自身の課題です。そして、名前を持つ仮名に対する最も強い攻撃は、たいていチェーンそのものではありません——それは文章であり、メタデータであり、コインがパスポートと出会う KYC 取引所です。この足し算のモデルは、オンチェーン追跡が実際どう動くかと、チェーンの外側については AI による匿名性剥がしで描いたとおりです。Silent Payments が塞ぐのは、特定の、しかし価値ある一つの穴です。必要ではあっても、それだけで十分ではありません。

2026年、どのウォレットが Silent Payments に対応しているか
#

**対応は本物ですが、ばらつきがあります。そして最も役に立つ習慣は、送信と受信を別々に確かめることです——両者は、別の時期に、別のウォレットで、ときに何年も離れて実装されてきたからです。**Silent Payment アドレスへ送ることは、いまや当たり前になりました。一方、そのアドレスで受け取れるようにするには、ウォレットがチェーンをスキャンしなければならず、こちらはより新しく、まだ数も少ないのが実情です。以下の表は 2026年7月9日時点の一次情報を反映しています。実際にお金を動かす前に、各プロジェクトのリリースノートで確かめてください。この一覧は、今後も更新されていきますから。

ウォレット	送信	受信	備考(2026年7月9日時点)
Sparrow	✅ v2.3.0(2025年10月)	✅ v2.5.0(2026年5月)	デスクトップで最も完成度が高い。ハードウェアウォレット署名は BIP-375 経由で v2.4.0(2026年2月)から。最新は v2.5.2
Cake Wallet	✅	✅	一通りの機能を備えた初のモバイルウォレット(v4.18.0、2024年5月下旬)。スキャンは端末上で行う——その分、電池と同期時間の負担は重い
Bitcoin Core	⏳ 未マージ	⏳ 未マージ	暗号処理の `libsecp256k1` モジュールはマージ済み(PR #1765)。ウォレット層の対応は今も未決着(PR #35301 / #35302)

表が圧縮してしまった注意点が二つあります。一つ目。本当に大事なのは「受信」の行で、しかもそこが最も遅れて追いついてくる部分です——ウォレットは、あなた自身のアドレスを保有できるようになるよりずっと前から、友人の sp1 アドレスへ支払うことはできてしまいます。二つ目。ウォレットがどうスキャンするかは、単なる性能の話ではなく、プライバシーの選択です——これは続く二つの節の主題です。そもそも、こうして受け取るためのコインを、取引所で身元の結びつきを蒔かずに手に入れる方法については、KYC なしで Bitcoin を買うを参照してください。

送信——二つのうち、簡単に片づく方
#

**Silent Payment アドレスへの送信は、このプロトコルで手のかからない方です。送る側は作業をすべて手元で済ませ、何一つスキャンする必要がないからです。**対応したウォレット——デスクトップの手本は Sparrow です——では、受取人の sp1… アドレスを、ほかのアドレスとまったく同じように送金欄に貼り付けるだけ。あとはウォレットが、導出を目に見えないところで済ませます。

内部では、ウォレットは、いま使おうとしている入力の秘密鍵を取り、それを受取人の scan key と組み合わせて共有秘密を計算し、その秘密を使って、この支払い専用の使い捨て Taproot 出力アドレスを導き出します。導出があなたの入力を織り込むため、同じ受取人アドレスでも、別の人が——あるいはあなたの別のコインの組み合わせが——支払うたびに、オンチェーンには違う出力が生まれます。送る側が受取人から必要とするものは、公開されたアドレスのほかには何もありません。往復のやり取りも、通知も、対話もいりません。だからこそ送信側の対応が先に整い、いまでは当たり前になっているのです。この非対称こそが、次の節のすべてを語ります——送信が避けられる代償は、まさに受信には避けられない代償なのです。

受信——誰も警告してくれないスキャンの代償
#

**Silent Payments を受け取るには、ウォレットはブロックチェーン全体の候補となる出力を一つずつ調べ、それぞれをあなたの鍵と突き合わせて、あなた宛ての支払いを探し出さなければなりません——チェーン上には、ただ「引くだけ」で見つかるアドレスなど存在しないのです。**このスキャンの代償こそ、BIP-352 の中心にありながら、あまり語られてこなかった引き換えです。そして、ウォレットがそれをどう解決するかが、あなたの利便性とプライバシーの両方を決めます。アドレスの公開はタダです。そこへ何が送られたかを見つけるのは、タダではありません。

自分でフルノードを動かしているなら、スキャンはブロックデータに対する手元での計算です——重い処理ですが、プライベートです。何一つ自分のマシンの外へ出ないからです。厄介になるのは、ノードを持たずに、スマートフォンやノートパソコンで受け取りたいときです。そこで登場するのがインデックスサーバーです。Sparrow の場合、そのサーバーが Frigate(Silent Payments 用の Electrum サーバー、最新は v1.5.3)で、frigate.2140.dev に公開インスタンスがあります。ブラウザで「訪れる」ものではありません——HTTP ではなく Electrum プロトコルを話すからです。Sparrow では Preferences → Server → Public Server から選び、接続をテストします。

ここからが、調子のいいチュートリアルが飛ばす部分です。しかもこれは脚注ではなく、プライバシーの核心です。サーバーにあなたの代わりにスキャンさせるには、ウォレットはそのサーバーに、あなたの scan private key(スキャン秘密鍵) と spend public key(支出公開鍵) を手渡します。Frigate がそう設計されているように、サーバーがそれらをメモリ上にしか保持しなかったとしても、悪意ある——あるいは侵害された——インデックスサーバーは、その鍵を使って、Silent Payments が第三者から隠すはずだったものを、そっくりそのまま復元できてしまいます。つまり、あなたが受け取った支払いの一覧すべてを、です。bennet.org の実践ガイドは、これをはっきりこう述べています——悪いサーバーは「Silent Payments が防ぐはずの、あなたの受信履歴の全体像を、そっくり組み上げられてしまう」。ですから、誠実に捉えるなら、これは白か黒かではなく、幅のある選択です。自分のノードは完全にプライベートで、その分だけ手間がかかる。公開インデックスサーバーは手軽で、その代わり、あなたの受信履歴について運営者を信用してくれと求めてくる。意識して選んでください。そして、見知らぬ他人のサーバーがあなたのスキャンを肩代わりしているときに、「自分は Silent Payments を使っているから」が、根拠のない安心に変わってしまわないように。

BIP-352 を、自分の手で再現してみた
#

**プライバシープロトコルを信頼する最も早い道は、それを実際に動かし、仕様書そのものが載せている数値と突き合わせることです。私は主張を鵜呑みにする代わりに、それをやりました。**私の一から書いた実装は、公式のテストベクター 57サブケースをすべて正確に再現します——送信 28/28、受信 29/29 です——完全なログとスクリプトはこの記事に同梱してあり(bip352-verification.txt)、あなた自身の手で再現できます。もっとも、通過した件数よりも役に立つのは、一件の支払いが一歩ずつ導き出されていくさまを、実際に眺めてみることです。

公開されたアドレスを一つ取り、送る側が何を計算するのかを追ってみましょう。以下の値は本物で、仕様書自身のテストベクターから取っています。

ステップ	何を表すか	値(短縮表記)
`a`	送る側の入力秘密鍵の総和	`7ed265a6…56345f86`
`A`	対応する公開鍵の総和	`032562c1…dedc4bee`
`input_hash`	使う特定のコインを束ねるハッシュ	`5bfe5321…b7ad0668`
`ecdh`	双方が独立に導く共有秘密(`input_hash · a · B_scan`)	`028158af…3e14d80d`
`t₀`	tweak、`hash(ecdh‖0)`	`f438b401…c2e7eef6`
output	`B_spend + t₀·G`(オンチェーンのアドレス)	`3e9fce73…de46e3c1`

さて、ここからが、この仕組み全体を報われたものにする性質です。私はもう一人、独立した送り手を自分で組み立てました——鍵の材料は別、想定するコインも別のものにして——そして同じ公開アドレスへ支払わせました(ここではトランザクションは何も送信しません。先ほどのトレースと同じく、これは純粋な導出です)。その出力は 3f1dd702…879b98ad でした。二つの支払い、一つのアドレス、けれどオンチェーンでは、二つの出力は何も共有しません。共通のアドレスもなく、目に見える結びつきもありません。逆向きの計算を回して、両方を自分のものだと見分けられるのは、scan key を持つ者だけです。これが受信プライバシーの保証であり、しかもあなたは、それを言明として信じるのではなく、トレースの上で実際に成り立つさまを見て取れます。これは、Bitcoin のオンチェーンプライバシーで解剖した再利用の問題の、オンチェーン側の裏返しです——再利用が分析者にタダで手渡してしまうのと同じクラスタリングを、この導出は、まさに渡さずに握っておくのです。

つまずきどころ——multisig、ラベル、そして K_max の上限
#

**スキャンの代償のほかにも、Silent Payments があなたの環境に合うかどうかを分ける実装上の細部が三つあります——multisig との相性、ラベルの扱い、そして受け取れる出力数の上限です。そのどれもが、頼りにしたあとではなく、頼りにする前に知っておきたい類いのものです。**これらは、仕組みを解説する記事がめったに踏み込まない一角です。

**multisig と協調型トランザクションは、相性が難しい。**送る側が、使う入力の秘密鍵から支払いを導き出す以上、multisig(複数署名)ウォレットや CoinJoin——署名鍵が複数の当事者に分かれて持たれ、それらを単純に一つへまとめてはならない場——からの送信は、BIP-352 とはきれいに噛み合いません。Silent Payments が解くのは再利用の結びつきであって、混ぜる問題ではありません。金額とグラフのプライバシーが欲しいなら、それはいまも協調型トランザクションの領分で、オンチェーンプライバシーで扱っています。両者は、入れ替えられるものではなく、補い合うものとして捉えてください。
**ラベルは、非対称を抱えた便利機能です。**BIP-352 では、受け取る側が、一つのアドレスからラベル付きの派生形を導けます——どの出力がどこから来たのかを見分けるのに役立ちます。ラベルの情報が意味を持つのは、保有者であるあなたにとってだけで、オンチェーンには出ません。ただ、それはあなたが手元で付ける帳簿であり、ということは、侵害されたウォレットやバックアップが漏らしうる帳簿でもあります。便利さを、正直に見積もっておきましょう。
**受取人には上限があり、K_max = 2323 です。**仕様書(v1.1.0、2026年3月。現行は v1.1.1、2026年4月)は、一つのグループが導ける出力の数に上限を設けています——受け手のスキャン作業を膨れ上がらせようと細工されたトランザクションへの、防御としてです。個人として使うぶんには、まず届かない数字です——けれどこれが、素朴に「一つのアドレスへ 3,000 出力を支払う」が設計上はねられる理由であり、プロトコルの作者たちがスキャンの代償という攻撃を真剣に受け止めていたことを物語っています。

ライトクライアントについても、関連する現実確認を一つ。スキャンの問題は、まさにここでこそもう解決済みだと期待されがちだからです。2026年半ばの時点で、ただインストールすれば済むような、実運用に耐える、信頼を最小化したライトクライアントのツールは一つも存在しません。ウォレットデーモンの blindbitd は 2025年8月にアーカイブされました。今も活発に保守されているのは、対になるインデクサーの blindbit-oracle だけで、ライトクライアントの仕様もまだ策定の途中です。bdk-sp のような実験的なライブラリはありますが、作者自身がメインネットでの利用を戒めています。もしどこかのガイドが、スマートフォンでの Silent Payments 受信を、もう解決済みで引き換えのない体験であるかのように匂わせているなら、それはソフトウェアの実態を先取りしすぎています。

結論——Silent Payments は、もう使うべきか
#

**Silent Payments は、特定の価値ある仕事——再利用の結びつきを漏らさない、再利用可能な公開受取アドレス——には、もう十分こなせます。けれど、あなたの唯一のプライバシー道具になるにも、手間のかからないモバイルの既定になるにも、まだ早い。道具を仕事に合わせてください。そして、受信履歴が身の安全に関わるなら、自分のノードを動かしてください。**ここでの誠実な目標は、匿名性ではなく、よりよい受信プライバシーです。

あなたの状況	判定	どうするか
公開の投げ銭・寄付アドレス(発信者、プロジェクト、仮名)	よく合う	`sp1…` アドレスを一つ公開する。できるなら自分のノードでスキャンする
日常の受け取り、ノードは動かしている	合う	Sparrow と自分のノード。完全にプライベートなスキャン
日常の受け取り、ノードなし、スマートフォン中心	部分的	公開インデックスサーバー経由なら使える——信頼の引き換えを受け入れるか、ライトクライアントを待つ
金額や送り手グラフのプライバシーが欲しい	道具が違う	Silent Payments はこれをしない。協調型トランザクションと Lightning を見てほしい
multisig / CoinJoin からの送信	よく確かめて	噛み合わせが難しい。まず自分のウォレットの対応を確かめる

どんな場合でも、順序はいつもと同じです。まず敵を名指しする。安上がりで、しかも取り返しのつかない結びつきから先に潰す——合法な範囲での KYC なしの入手、コインの扱いの基本、素のアドレスを二度と再利用しないこと。そのうえで、結びつけられたくない公開アドレスという特定の穴を、Silent Payments が塞ぐところに足していく。これは本物の前進です。同時に、スキャンの請求書がついて回る受信の道具でもあります。そしてその請求書を誰が払うのか——あなたか、それとも、あなたが信用するサーバーか——それこそが、プライバシーそのものと、プライバシーがある気がするだけの状態とを分ける差なのです。

要点

守るのは受信だけ: Silent Payments(BIP-352)は、再利用できる sp1… アドレスを一つ与え、そこへの支払いのあいだにオンチェーンの結びつきを残しません——ただし、金額を隠さず、送り手を守らず、オフチェーンの身元漏れには触れません。
送信は簡単、受信には代償がある: 送信は対話なしで手元で導出できます。受信はチェーンのスキャンが要り、それは自分のノードか、インデックスサーバー経由のどちらかです。
公開サーバーの引き換えは本物: Frigate のような公開インデックスサーバーは、あなたの scan private key と spend public key を受け取ります。ですから悪意あるサーバーは、あなたの受信履歴を再構成できます——大事な場面では、自分のノードを動かしてください。
2026年、対応にはばらつきがある: Sparrow は送信(v2.3.0、2025年10月)も受信(v2.5.0、2026年5月)もできます。Cake Wallet はどちらも端末上で行います。Bitcoin Core のウォレット対応は、いまだマージされていません。
自分で検証した: 一から書いた BIP-352 の実装は、公式のテストベクター 57件すべてに一致しました(送信 28/28、受信 29/29)。ログとスクリプトは、この記事に同梱しています。

よくある質問
#

Silent Payment のアドレスとは何ですか？
#

Silent Payment のアドレスとは、BIP-352 が定める再利用可能な Bitcoin アドレスで、一度だけ公開して使えます——メインネットでは sp1 で始まります。ふつうのアドレスと違い、支払う人はそれぞれ、そこから別々の使い捨てオンチェーンアドレスを導き出します。ですから、あなた宛ての支払いは、共有された結びつけ可能な宛先を持ちません。単一のスクリプトではなく、二つの公開鍵(scan key と spend key)を符号化したものです。

Silent Payments は、受け取る金額を隠しますか？
#

いいえ。Silent Payments が守るのは受信の結びつき——同じ相手への別々の支払いが、互いにひもづいてしまうこと——であって、それ以外は守りません。個々の支払いの金額は、いまも公開ブロックチェーンに記録されます。あなたに送る相手のプライバシーは変わりませんし、オフチェーンの記録(KYC 取引所など)も手つかずです。金額のプライバシーには、Lightning や協調型トランザクションが、その役目を担う道具になります。

2026年、どのウォレットが Silent Payments に対応していますか？
#

2026年7月9日時点で、Sparrow は送信(v2.3.0、2025年10月以降)と受信(v2.5.0、2026年5月以降)の両方に対応しています。Cake Wallet は、端末上でのスキャンにより両方に対応します(v4.18.0、2024年5月下旬以降)。Bitcoin Core のウォレット層の対応は、土台となる暗号モジュールこそ入ったものの、まだマージされていません。送信と受信の対応は、つねに別々に確認し、最新のリリースノートで裏を取ってください。

Silent Payment の受信は、なぜ遅いのですか？
#

チェーン上に、引くだけで見つかるアドレスがないからです。あなた宛ての支払いを見つけるため、ウォレットはブロックをまたいで候補の出力をスキャンし、それぞれをあなたの鍵と突き合わせなければなりません。自分のノードなら、これは手元での、プライベートな計算です。ノードがなければ、インデックスサーバーに頼ることになり、そのほうが速い代わりに、信頼の引き換えが生まれます。代償と信頼の両方を取り除くライトクライアントのツールは、まだ策定と開発の途中です。

公開サーバーを使っても、Silent Payments はプライベートなままですか？
#

部分的にしか、そうではありません。あなたの代わりにスキャンするため、公開インデックスサーバーは、あなたの scan private key と spend public key を受け取ります。メモリ上にしか保持しなかったとしても、その鍵があれば、悪意ある——あるいは侵害された——サーバーは、あなたが受け取った支払いの履歴すべてを再構成できます。それは、チェーンを見張る第三者に対して Silent Payments が防ごうとしている、まさにそのものです。自分のノードを動かせばこれを避けられますが、公開サーバーは、そのプライバシーを手軽さと引き換えにします。

#	出典	URL	アーカイブ
1	BIP-352 — Silent Payments(仕様書、v1.1.1)	https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki	https://web.archive.org/web/*/https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki
2	Bitcoin Optech — Silent Payments のトピック	https://bitcoinops.org/en/topics/silent-payments/	https://web.archive.org/web/*/https://bitcoinops.org/en/topics/silent-payments/
3	Sparrow Wallet — リリース一覧	https://github.com/sparrowwallet/sparrow/releases	https://web.archive.org/web/*/https://github.com/sparrowwallet/sparrow/releases
4	Frigate — Silent Payments 用 Electrum サーバー	https://github.com/sparrowwallet/frigate	https://web.archive.org/web/*/https://github.com/sparrowwallet/frigate
5	bennet.org — Silent Payments 実践ガイド(サーバーのプライバシー引き換え)	https://bennet.org/learn/silent-payments-bitcoin-privacy/	https://web.archive.org/web/*/https://bennet.org/learn/silent-payments-bitcoin-privacy/
6	libsecp256k1 — Silent Payments モジュール(PR #1765、マージ済み)	https://github.com/bitcoin-core/secp256k1/pull/1765	https://web.archive.org/web/*/https://github.com/bitcoin-core/secp256k1/pull/1765

このサイトの三つの筋が、ここで交わります。Silent Payments は、Bitcoin オンチェーンプライバシー——追跡はどう動くかで解剖した再利用問題の、受信側の半分に答えるものです——クラスタリングに何が見えて、何が見えないのかは、そちらを読んでください。そして、アドレスのプライバシーは、そこへ受け取るコインのプライバシー止まりでしかありません。ですからこの記事は、身元の起点を上流で正す KYC なしで Bitcoin を買うと対にしてください。さらに、脅威はチェーンの上だけにとどまりません——AI による匿名性剥がしが、それらすべてと並行して走るオフチェーンの推論を扱っています。

年齢確認 2026——匿名性が払う代償と、あなたの守り方

Wed, 24 Jun 2026 00:00:00 +0000

開かれたウェブが生きてきた時間のほとんど、私たちはまず自分が誰かを証明しなくても、読み、観て、語ることができた。その前提が、いま法律によって取り消されようとしている。2025年から2026年にかけて、英国、欧州連合(EU)、米国、オーストラリアで相次いだ立法の波が、年齢確認をふつうのオンライン利用の前提条件にした。そしてそのほぼすべてに、声高には語られない一点がある——確認を求められるのは、法律が名前に掲げる子どもだけではない。大人も含めた全員なのだ。見知らぬ相手が一定の年齢を超えていると証明するには、システムはまず、その相手が誰かを知らねばならない。

これが、見出しが飛ばす取引だ。英国の Online Safety Act による年齢チェックは2025年なかばから施行され、規制当局 Ofcom はすでに、違反に対して罰則を科しはじめている。2025年6月には、米国の連邦最高裁がテキサス州の年齢確認法を支持し、十あまりの州の同種の法律を阻んできた憲法上の反論を取り除いた。オーストラリアは2025年12月、16歳未満を対象にした全国的なソーシャルメディア禁止を発動した。そしてこれらの制度はどれも、同じ仕組みで動いている——政府発行の身分証に匹敵する身元を集める、あるいはそれと照合する関門と、その結果を抱え込むデータベースだ。

私たちは法律の条文と侵害の報告書を、並べて読む——本サイトが脅威をいつも読むやり方で、語られた意図の先にある、それが生み出す仕組みのほうへ目を向けて。そこから浮かび上がるのは、「とにかく VPN を使え」という指南書が描くパターンではない。長く残る害は、入口でチェックされる手間ではない。害は、もっと別のところにある。一つは、そのチェックがあとに残す、あらかじめ照合された消えない身元の記録。次に、そこで最もさらされるのが、法律が守ると称する当の脆弱な人々だという事実。そして、奪われた匿名性は、どんな道具をもってしても取り戻せないという現実だ。あなたを本当に守るものは、その法律が具体的にあなたの何を確かめるかによって変わる——そしてそれは、「年齢ゲートをどう突破するか」が解こうとする問題とは、別物だ。

2026年の年齢確認の波が、実際に求めているもの
#

2026年の年齢確認は、もはや提案ではなく、英国・オーストラリア・そして増え続ける米国の州で施行された法律だ——EU をはじめ、すぐ後ろに控える国も多い。これらの制度に共通するのは、大人がふつうのサービスにたどり着くために身元を証明しなければならないこと、そしてその手段がたいてい、政府発行の身分証、顔のスキャン、クレジットカードの提示だということだ。「年齢チェック」という言い方は、軽い手続きを思わせる。だが実際に主流となっている手法は、本物の身元を一回のアクセスに結びつける——軽い手続きとは、まるで正反対のものだ。

下の一覧表は、私たちが法律の条文と規制当局の指針からまとめた見取り図だ——どこが何を求めるか、そして2026年なかば時点で、それぞれがどの段階にあるか。いまどの段階にあるかが効いてくる。これらの法律には、すでに発効したものもあれば、まだ審議の途中のものもあり、少なくとも一つはすでに裁判で覆されている——流れは強いが、一様ではない、という戒めだ。

法域	何を求めるか	段階(2026年6月時点)
英国——Online Safety Act	ポルノその他「有害な」コンテンツへの年齢保証	2025年7月から施行。Ofcom が調査と制裁金で執行中
米国——テキサス州 HB 1181 と各州の同種法	アダルトコンテンツのサイトへの年齢確認	2025年6月に最高裁がテキサス法を支持。いまや米国のおよそ半数の州に法律あり、一部は裁判で差し止め
オーストラリア	16歳未満のソーシャルメディア利用の禁止	2025年12月から施行。罰則は1事業者あたり最大4,950万豪ドル
EU——DSA と eIDAS ウォレット	超大規模プラットフォーム向けの年齢確認手法、および EU 共通の年齢確認アプリ	2025年に設計図を公表、加盟国でパイロット運用中、2026年末の本格運用を目標
フランス	15歳未満のソーシャルメディア利用の禁止	国民議会が可決(2026年1月)。上院は異なる版を可決(2026年4月)し、まだ成立していない——両院の調整が保留中
米国連邦——KOSA、SAFE Kids Act	さまざまな義務と年齢チェック	提出され審議されているが、2026年なかば時点で未成立

この表のなかで、本当に効いてくる事実が二つある。第一に、米国連邦最高裁の2025年6月の判決、Free Speech Coalition 対 Paxtonは、中間審査(以前の版を阻んだ厳格審査より緩やかな、中位の憲法審査基準)のもとでテキサス州法を6対3で支持した。これが憲法修正第1条の壁を取り除き、他州への扉を開いた。第二に、これらの法律は仕組みの上、必然的に大人にまで及ぶ。未成年を弾くシステムは全員を試すしかないからだ——だから英国の年齢保証の義務も、オーストラリアの16歳未満ルールも、大人の人口すべてに自分を証明させる。「子どものことを思え」という訴えかけが、誰もが通る身元の関門を覆い隠している。

その関門がどう働くか——そこが、あなたの露出と守りを左右する部分だ。主流は三つの手法で、プライバシーの面でそれぞれまったく異なる。

確認の手法	仕組み	プライバシー上の性質
位置情報 / IP によるゲート	検知した地域で遮断または許可する	プライバシーへの影響は最も小さいが、VPN で簡単に突破される。より強い手法へ移行中
ID のアップロード / 顔による年齢推定	政府発行の身分証を提出するか、自撮りをスキャンして年齢を推定させる	身元の露出が最も大きい。データの扱いを確かめられない第三者ベンダーに依存する
デジタル ID / ゼロ知識トークン	ウォレットや証明書が、元のデータを明かさずに「N歳以上」と主張する	設計上は最も強い。だが、その証明書は、先にあなたの身元を確認した誰かが発行しなければならない

設計として最も強いのは、EU が掲げる方向だ——一定の年齢を超えていることを証明しつつ、ウェブサイトには一切の身元情報を渡さないウォレットである。これは ID のアップロードに比べて本物の前進で、標準になるべきものだ。だがそれは設計上の主張であって、まだ実装された保証ではない。そして、証明書が最初に発行されるとき上流で起きる身元確認の段階を、消し去るわけではない。この区別を覚えておいてほしい。のちほど守りを考えるとき、まさにここが要になるからだ。

リセットできないハニーポット——攻撃者を惹きつける、個人情報の集積
#

年齢確認システムは、あなたを確かめて忘れるのではない——あらかじめ照合された身元の記録(あなたの名前、顔、生年月日、そして自分を証明したサイトの一覧)を一か所に集める。そしてパスワードと違い、漏れた顔のデータはリセットできない。これが、利便という見せかけに隠された害だ。パスワードの漏洩は取り戻せる——秘密を入れ替えて、先へ進めばいい。だが生体情報と身分証の漏洩は永続する。顔も生年月日も、発行し直せないからだ。子どもを守るために「今回だけ」と組まれたデータベースは、それを求めた法律より長く生き延びる、居座り続ける攻撃対象になる。

ふつうのデータの保管庫より、これをたちの悪いものにする性質が二つある。一つ目は事前の名寄せだ。漏れたマーケティング用のリストは、攻撃者がまだ手間をかけて肉付けし、結びつけねばならないメールアドレスの山にすぎない。だが年齢確認の記録は、すでに結合された状態で届く——身元、生体情報、そしてどの大人向けサービスを利用したかという機微な事実が、一行にまとまっている。これは『AI 非匿名化のプレイブック』が描いた、まさにその名寄せの機構そのものだ。違うのは、法律のほうが攻撃者のために前もって組み立ててやる、という点だけである。二つ目は漏洩を最初から織り込んで設計されていることだ。誠実な脅威モデルは、この種のデータベースを初日からすでに漏れているものとして扱う——『政府があなたのデータを漏らすとき』で政府データに対して取ったのと同じ「漏洩を前提とする」構えだ。なぜなら、確認の記録が作られた瞬間から、それがいずれ露出するかどうかは「するか否か」ではなく「いつか」の問題になり、その中身は決して期限切れにならないからだ。

これは絵空事ではない。Discord が年齢チェックを導入したとき、2025年10月、その第三者の確認ベンダーで起きた侵害が、約7万人分の政府発行 ID 画像を流出させた(Cybernews)——批判者が警告していた、身元データ集積のリスクが現実になった瞬間だ。確認の記録は、攻撃者が狙う、価値が高く、取り返しのつかないほど機微な標的そのものであり、これらの法律はそれを一つひとつの関門で積み上げる。一件ごとの侵害は、取り消せない露出になる——さらされた人々は、確認を取り消すことも、漏れた身元を入れ替えることも、それを複製するブローカー市場やアーカイブから記録を消すこともできない。『あなたのソーシャルメディアの足跡は、どこまで永続するか』に記したとおり、発生源での削除は複製まで届かない——そして確認データベースは、あらゆる複製のなかで最も機微なものだ。

「今回だけ」という言い分は、とりわけ疑ってかかる価値がある。監視のための仕組みは、掲げられた目的より長く生き残るからだ。年齢ゲートのために作られたデータベースも、しょせんデータベースであり、データベースは転用され、召喚状で開かれ、破産処理で売られ、そして漏れる。どんな年齢確認の義務にも問うべきは、「この事業者を今日信用できるか」ではない——「この身元の記録が永遠に存在し、いずれ渡る先のあらゆる手のなかにあることに、自分は耐えられるか」だ。たいていの人にとって、正直に答えれば「いいえ」である。

誰の安全か——年齢確認が危険にさらす利用者たち
#

年齢確認の表向きの根拠は子どもの安全だ。だが、それがきまって危険にさらすのは、守ると称する当の脆弱な人々——支えのない家庭の LGBTQ の若者、家庭内暴力(DV)の被害者、そして反体制の人々——であり、彼らにとって匿名性は便利さではなく、安全の前提条件だ。これは、規制をめぐる議論が後回しにする次元であり、後回しにするからこそ、法律の名前そのものが掲げる人々を害する立法が書かれてしまう。

敵意ある家庭にいる若者にとって、匿名のアクセスは、支えてくれる仲間や、健康の情報や、あるいは同居する相手に監視されない場所へとつながる唯一の道であることが多い。市民的自由を擁護する団体は、年齢確認や保護者連携の要件がそのアクセスを断ち切るさまを、詳しく記録してきた——命綱を、家庭へ報告を返す関門に変えてしまう、と。安全な家庭の子を「守る」仕組みが、安全でない家庭の子を危険にさらす。そして法律は、その二つを見分けられない。

同じ反転が、DV 被害者にも当てはまる。ここでの害は、たまたま起きるものではなく、構造的だ。匿名性とは、被害者が加害者に行動を追われずに、読み、計画し、助けを求める手立てそのものだ——そして、身元をアクセスに結びつける、あるいは共有された家族のアカウントや端末を経由する年齢ゲートは、支配しようとする相手にとって、できあいの監視の道具になる。これは、ジェンダーに中立な指南書が見落としがちな親密な関係者からの脅威であり、『権威主義国家は、亡命した活動家をどう暴くのか』でたどったのと同じ盲点だ——善良な家庭を前提にした仕組みが、強圧的な家庭では武器になる。反体制の人々やジャーナリストにとっては、同じ論理が国家の規模で働く——入口での身元の義務づけが、一つの読書習慣を一つの記録に変えてしまう。

これらは、子どもの安全が本物の目標でないと言っているのではない。言いたいのは、選ばれた手段——全員への身元確認の義務づけ——が、最もさらされた利用者へリスクを押しつける一方で、本気の回避者にはほとんど効かない、ということだ。未成年は、同じシステムが開けたままにする抜け道を、いつもどおり見つけてしまうのだから。デジタル権利と市民的自由を掲げる団体の連合は、まさにこの取引について立法者へ警告してきた——こうした義務づけは標的にする当の若者たちのプライバシーと安全を損なう、と。EFF は、これらの義務づけが誰を害するかの一覧を、いまも更新し続けている。安全のための施策の最初の犠牲者が脆弱な人々であるとき、その施策はただ従う対象ではなく、身を守るべき対象なのだ。

本当にあなたを守るものと、ただの見せかけ
#

年齢チェックに奪われた匿名性を、ひとつの道具で取り戻すことはできない。それを約束する指南書は、見せかけを売っている——何が効くかは、その法律があなたの何を確かめるのかによって、すべて決まる。VPN は位置情報のゲートだけを突破し、それ以外には効かない。Tor は地理を突破するが ID のアップロードは突破できない。そしてゼロ知識による年齢証明でさえ、証明書が発行される瞬間の身元確認を、なお抱えている。誠実な守りは、まず手立てを確認の手法に合わせることから始まり、そのうえで、どの手立てでも消せない残余のリスクを受け入れる。

下の対応表は、よくある守りがそれぞれ実際に何を突破し、どこで通用しなくなるかを、私たちなりにまとめたものだ。メニューではなく、判断のための道具として読んでほしい——選ぶべき行は、上の最初の表にある手法しだいだ。

守り	本当に突破できるもの	通用しない場面	率直な評価
VPN	位置情報・IP に基づくゲート(現行の英国式の遮断の一部)	身元確認や顔認証。事業者によるログ記録。手法はこれを突破できないよう移行中	部分的でもろい。一時しのぎであって、盾ではない
Tor Browser	位置情報によるゲート、通信レベルの監視	ID のアップロードや顔のスキャン。出口ノードは暗号化されていない通信を見られる	部分的。地理には強いが、身元の証明には無力
プライバシー保護型のゼロ知識年齢証明	利用の時点での身元の露出	証明書の発行には、なお上流で身元確認が要る。まだ広くは実装されていない	有望で、求める価値があるが、不完全
アカウント不要 / 分散型のプラットフォーム	年齢ゲートそのもの。中央の門番を取り除くことで	届く範囲が小さい。大多数の読者がいる場所ではない	構造的で長持ちするが、適用範囲は限られる
データの最小化 / 不提出	そもそも存在しなければ漏れようのない記録	アクセスの喪失。いつでも選べる手とは限らない	状況しだい。ハニーポットを未然に防ぐ唯一の守り

いくつかの行は、はっきり言葉にしておく価値がある。VPN は反射的に出てくる答えで、最も弱い手だ。位置情報のゲートの向こうへ、見かけの所在を移すが、法律が ID のアップロードや顔のスキャンを求めた瞬間、VPN は無関係になる。そして各国の制度は、VPN では手の出せない手法へと、意図して移りつつある。Tor は地理と監視にはより強いが、身元確認には同じく無力だ。そして、その出口ノード(開かれたインターネットへ出る最後の中継点)は、暗号化されていない ID を送ってよい場所ではない——Tor プロジェクト自身の指針が、出口の中継点は暗号化されていない通信を読めると警告している。本当に興味深い選択肢は、ゼロ知識による年齢証明だ——「18歳以上」を証明しつつ、それ以外は何も明かさない証明書である。これは正しい方向で、EU の設計図やいくつかのパイロットがこれを追っている。だがその限界は、正確で、あまり報じられていない——証明書は提示の時点では何も明かさないが、それでも誰かが、証明書を発行するためにあなたの身元を確認しなければならなかった。つまり信頼の問題は消えるのではなく、発行者へと場所を移す。Brave の技術者は、発行者がボトルネックになるという論点を正面から述べている——ごく少数の証明書発行者が、ウェブに対する門番の力を握る、と。より深い問題は、論理そのものにある——発行者は、あなたが18歳以上だとまず確かめずに、それを保証することはできない。だから身元確認は消えるのではなく、上流へ移るだけだ。ゼロ知識は ID のアップロードに比べた本物の改善だ。ただ、匿名性が取り戻されたわけではない。

この表を貫くのは、サイファーパンクが、個人の技術と制度の権力がぶつかる場所でつねに引き出してきた教訓だ——最も長持ちする守りは、戦術的なものではなく構造的なものだ、と。VPN や回避策は、それを塞ぐべく設計されたシステムに対する、時間稼ぎの一手にすぎない。強要すべき中央の門番を持たないプラットフォームを選ぶこと、そして状況が許す限り最小の身元だけを渡すこと——これだけが、問題を先送りするのではなく、その形そのものを変える手だ。それは、弾圧のもとでの発信に通じるのと同じ「身元よりインフラ」の原理であり、年齢確認においても変わらず通用する。

サイファーパンクの読み——三十年続く一つのパターン
#

年齢確認は、十年ごとに繰り返される一つの要求の、2026年版だ——子どもを守るという名目で、全員のプライバシーを弱めよ、という要求である。1996年の通信品位法(CDA)から今日の年齢保証の義務づけまで、これを一つのパターンとして見抜くことが、最新版を目新しい緊急事態と取り違えずにすむ道だ。細部は変わる。構造は変わらない。未成年への本物の懸念が、身元の関門を築く口実として差し出される——そしていったん築かれれば、それは全員に適用され、当初をはるかに超える目的に使われるのだ。

サイファーパンクは、その底にある真実を、三十年前に名づけていた——これらの法律が統べるウェブが、まだ存在すらしない頃に。

「電子の時代において、プライバシーは開かれた社会に不可欠だ。……私たちは、政府や企業、その他の顔の見えない巨大な組織が、その善意からプライバシーを与えてくれるなどとは、期待できない。」——Eric Hughes『A Cypherpunk’s Manifesto』、1993年

年齢確認の波に照らせば、この一節は懐古ではない——設計の仕様書だ。確認ベンダーの行儀のよさや、規制当局の自制や、決して漏れないデータベースに依存するプライバシーは、善意から与えられたプライバシーだ——まさに Hughes が、それでは持ちこたえないと警告した種類のものである。サイファーパンクの答えは、「あらゆる安全策を拒め」では決してなかった。プライバシーは仕組みそのものに組み込まれねばならない、というものだった——制度が決まって裏切る信頼に、頼らずにすむように。年齢確認に当てはめれば、これは具体的で建設的な立場になる——身元を保存せずに事実だけを証明する、端末レベルとゼロ知識の手法を選ぶ。中央集権的な身元データベースを、最も危険な設計として拒む。そして、開かれたウェブを「身分証を見せること」の条件つきにするどんなシステムも、どれほど優しい名で呼ばれようと、それが何であるか——監視のための仕組み——として扱う。子どもを守るという目標は本物だ。だが、全員への身元確認を義務づけるという手段こそ、プライバシーに通じた市民が拒むべきものであり、それに代わる仕組みを自分たちで築いていく相手なのだ。

結論——あなたの脅威モデルに、どの守りが合うか
#

正しい応えは、あなたが誰で、目の前の法律が実際に何を確かめるかによって変わる——一度入れれば後は忘れていられる、そんな道具で決まるものではない。

施行された位置情報式のゲート(英国式の遮断)のもとで暮らすなら： VPN を使えば今日はアクセスできるが、それを守りではなく、もろい一時しのぎとして扱うこと——手法は VPN を突破するよう移りつつある。長持ちする一手は、提出する身元をそもそも最小化し、中央の年齢ゲートそのものが存在しないプラットフォームやプロトコルを選ぶことだ。
脆弱な利用者なら——LGBTQ の若者、DV 被害者、反体制の人やジャーナリスト： 匿名性は、便利さではなく、あなたの安全だ。どのサービスでも受け入れられる最小の身元だけを渡し、共有された家族のアカウントや端末に結びつく年齢ゲートを避け、保護者連携や身元結合の要件は、迂回すべき追跡の経路として扱うこと。あなたにとって、それはまさにそういうものだからだ。
作る側、訴える側なら： プライバシーを守る年齢保証を強く推すこと——ゼロ知識証明、端末レベルの信号、二重盲検の確認(プラットフォームも確認者も、互いの身元を知らない仕組み)を、ID のアップロードや顔のスキャンより上に、そして中央集権的な身元データベースに抗して、届く限りのあらゆる場で。人を保存せずに事実を証明する技術は、すでに存在する。それを義務づけるという政策の選択が、まだ存在しない——そこにこそ、実際に動かせる余地がある。

三つすべてを貫いて、それ以前のあらゆるプライバシーの戦いで成り立ってきたのと同じ真実が、ここでも成り立つ——いったん身元の記録が存在すれば、漏洩を「なかったこと」にして匿名性へ戻ることはできない。あなたにできるのは、関門の手前で決めることだけだ——自分の何を、どこまで渡すか。そして、個人の技術の限界の先では、必要なものだけを証明し、誰の記録も永遠に積み上げないシステムを後押しすることだ。

要点

波は本物で、世界的だ： 英国の年齢チェックは2025年7月から施行され、米国の連邦最高裁は2025年6月にテキサス法を支持し、オーストラリアの16歳未満禁止は2025年12月に発効した——そのどれもが、未成年だけでなく、すべての大人を試す。
長く残る害は、手間ではなく身元データの集積だ： 年齢確認の記録は、あらかじめ照合された身元(名前、顔、生年月日、利用したサイト)であり、パスワードと違って、いったん漏れたらリセットできない——そして侵害は、すでに起きている。
脆弱な人が、先に代償を払う： 敵意ある家庭の LGBTQ の若者、DV 被害者、反体制の人々は、自らの安全である匿名性を失い、その一方で本気の未成年は、結局どのみち抜け道を見つける。
匿名性を取り戻す道具はない： VPN は位置情報のゲートだけを、Tor は地理だけを突破し、ゼロ知識証明でさえ発行時の身元確認を抱えている——手立てを確認の手法に合わせ、残余のリスクを受け入れること。
構造的なものが、戦術的なものに勝る： 長持ちする守りは、門番のいないプラットフォームを選び、提出する身元をそもそも最小化することだ。それらは、問題を先送りするのではなく、その形そのものを変えるからである。

よくある質問
#

年齢確認は、私の年齢を確かめているのですか、それとも身元ですか？
#

いまのほとんどのシステムでは、一度に両方です。一定の年齢を超えていると確認するために、ID のアップロードや顔による年齢推定の手法は、まずあなたが誰かを突き止め、そこから年齢を導きます。身元を保存せずに年齢を証明しようとするのは、いま出てきたばかりのゼロ知識や端末レベルの手法だけです——そしてそれらでさえ、年齢の証明書が最初に発行されるとき、上流での身元確認に頼っています。ID のアップロードや顔のスキャンを使うシステムは、身元確認そのものだと思ってください。実際そうなのですから。

VPN で年齢確認を回避できますか？
#

位置情報に基づくゲートに対してだけ、しかも今のところは、です。VPN はサイトが検知する地域を変えるので、純粋に地理だけで働く遮断は迂回できます。ですが、ID のアップロードや顔のスキャンを求める法律には、何の効果もありません——それらは位置ではなく身元を確かめるからです。そしていくつもの制度が、まさに VPN の道を塞ぐために、身元に基づく手法へと意図して移っています。短期の一時しのぎとしては役立ちますが、頼れる盾ではありません。

なぜ年齢確認のデータベースは「ハニーポット」と呼ばれるのですか？
#

最も機微な個人データ——政府発行の身分証、生体情報、生年月日、そしてその人が利用したサービス——を、あらかじめ名寄せされた、攻撃者にとってこのうえなく魅力的な状態で、一か所に集めるからです。漏れたパスワードと違い、漏れた顔のデータや身分証はリセットできないので、どんな侵害も永続します。セキュリティ研究者の警告と、実在する年齢チェックシステムへの侵害が、すでにこの構造を実証しました。だからこそプライバシーの擁護者は、この種のデータベースを、そもそも作るべきでない負債として扱うのです。

年齢確認の法律で、最もリスクが高いのは誰ですか？
#

法律が守ると称する、脆弱な利用者たちです。支えのない家庭の LGBTQ の若者は、支えてくれる仲間への匿名のアクセスを失います。DV 被害者は、助けを求めるのに必要な、監視されないアクセスを失います。反体制の人々やジャーナリストは、一つの読書習慣を一つの記録に変えられてしまいます。彼ら全員にとって、匿名性は安全の仕組みであり、身元を結びつける年齢チェックはそれを奪います——その一方で、本気の未成年は同じシステムを回避するのです。

プライバシーを守りながら、年齢を証明する方法はありますか？
#

一部はあります。ゼロ知識の年齢証明や端末レベルの年齢信号は、あなたの名前も、身分証も、生年月日も、ウェブサイトに明かさずに「18歳以上」と主張でき、EU の設計図もこの方向を指しています。それらは ID のアップロードに比べた本物の改善で、求める価値のある標準です。限界は、証明書を発行するために、なお誰かがあなたの身元を確認することです——だから信頼の問題は、消えるのではなく、上流へ移ります。より良くはなりますが、解決はしていません——そして、ID と顔の中央集権的なデータベースよりは、はるかに良いのです。

#	出典	URL	アーカイブ
1	英国政府——Online Safety Act の資料集	https://www.gov.uk/government/collections/online-safety-act	https://web.archive.org/web/*/https://www.gov.uk/government/collections/online-safety-act
2	米国連邦最高裁——Free Speech Coalition 対 Paxton(23-1122)	https://www.supremecourt.gov/opinions/24pdf/23-1122_3e04.pdf	https://web.archive.org/web/*/https://www.supremecourt.gov/opinions/24pdf/23-1122_3e04.pdf
3	オーストラリア eSafety コミッショナー——ソーシャルメディアの年齢制限	https://www.esafety.gov.au/about-us/industry-regulation/social-media-age-restrictions	https://web.archive.org/web/*/https://www.esafety.gov.au/about-us/industry-regulation/social-media-age-restrictions
4	欧州委員会——EU の年齢確認	https://digital-strategy.ec.europa.eu/en/policies/eu-age-verification	https://web.archive.org/web/*/https://digital-strategy.ec.europa.eu/en/policies/eu-age-verification
5	EFF——年齢確認の(あまり)隠されていない10の危険	https://www.eff.org/deeplinks/2025/12/10-not-so-hidden-dangers-age-verification	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2025/12/10-not-so-hidden-dangers-age-verification
6	EFF——オンライン年齢確認の人的コスト	https://www.eff.org/deeplinks/2026/01/effecting-change-human-cost-online-age-verification	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2026/01/effecting-change-human-cost-online-age-verification
7	Cybernews——Discord の侵害が年齢確認から約7万件の政府発行 ID を流出	https://cybernews.com/news/discord-70000-gov-ids-exposed-zendesk-third-party-breach-scattered-spider/	https://web.archive.org/web/*/https://cybernews.com/news/discord-70000-gov-ids-exposed-zendesk-third-party-breach-scattered-spider/
8	Brave——年齢確認におけるゼロ知識証明の限界	https://brave.com/blog/zkp-age-verification-limits/	https://web.archive.org/web/*/https://brave.com/blog/zkp-age-verification-limits/
9	Eric Hughes——A Cypherpunk’s Manifesto(1993年)	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html
10	Tor プロジェクト——Tor 越しの平文は、やはり平文だ	https://blog.torproject.org/plaintext-over-tor-still-plaintext/	https://web.archive.org/web/*/https://blog.torproject.org/plaintext-over-tor-still-plaintext/
11	EFF——年齢確認の義務づけは誰を害するか	https://www.eff.org/pages/whos-harmed-age-verification-mandates	https://web.archive.org/web/*/https://www.eff.org/pages/whos-harmed-age-verification-mandates

Cora Aegis

Cora Aegis は CypherpunkGuide で、プライバシーを最優先する OPSEC の指針を書いている。新しい監視の法律を、報道が飛ばす「仕組み」から読み解く——ここでは、入口での一つの年齢チェックが、どうやって永続する身元の記録になるのか、そしてどの守りが本当に持ちこたえるのかを。

Cora についてもっと読む →

AI時代のOPSEC——脅威モデルを組み立て直す（2026年）

Sun, 14 Jun 2026 00:00:00 +0000

OPSEC——情報を狙う者の視点で考え、その情報を守る規律——が生まれて以来ずっと、敵の姿はひとつに定まっていた。人間だ。予算を持つ調査員。粘り強いストーカー。採用担当者、入国審査官、別れた相手。私たちは脅威モデルの描き方を学んできた——何を守るのか、誰がそれを欲しがるのか、その相手に現実的に何ができるのか、止めるのにどれだけの労力がかかるのか。その短く正直な地図だ。そして地図が「ここが大事だ」と告げる場所に、労力を注いできた。デジタル生活の20年間、その地図で足りていた。

だが、いまや4つの点でその地図は間違っている。敵がもはや人間ではなく、機械になりつつあるからだ。機械は疲れない。忘れない。すでに公開された情報を読むのに令状は要らない。そして人間の規模では働かない。これは仮定の話ではない。2026年3月の Pew Research のまとめでは、米国の成人の50%が、AI の広まりについて「期待よりも懸念」を感じると答えた——2021年の37%から上がっている。さらに早い時期のAI を知る人々を対象にした Pew の調査では、81%が、自分の個人情報を不快に思うような形で使われると予想していた。その懸念は理にかなっている。私たちはこのサイトのサーバーログを、自らを名乗る十数種の AI クローラー——GPTBot、ClaudeBot、PerplexityBot、Google-Extended とその仲間たち——について監視している。彼らはこちらの都合ではなく自分たちのスケジュールで、絶え間なくやって来る。

下に示す「4つの前提」の枠組みは、すでに世に出ているプライバシー指南をひととおり読み込んだうえで組み立てた。その大半は、企業の AI システムを守るものか、消費者向けツールの一覧で止まるものかのどちらかで、個人自身の脅威モデルは書かれないまま残されていた。

では、敵が機械であるとき、脅威モデルをどう組み立て直せばいいのか。削除ボタンを探し回ってもだめだ——モデルが学習した重みの中まで届くボタンはない。家の鍵がもうドアに合わなくなったと気づいたときと同じやり方でやる。前提をひとつずつ、だ。以下が AI の壊す4つの前提であり、それぞれが何を変えるのか、そして残る労力を、ただ気休めにするのではなく実際の露出を動かす場所へどう移すのか、である。

4 つの前提の差——古典的な OPSEC は人間の敵を前提にしていたが、機械の敵はその 4 つ（相関・推論・永続・合成された身元）を同時に破る。それぞれに、いま効く対策がある。

古典的な OPSEC の前提	機械の敵はこう振る舞う	あなたが打てる手
散らばったデータの紐づけは、遅く手間のかかる作業だ	何百万もの断片を、安く一瞬で相関させる	文脈をまたいで紐づけられるものを減らす
露出するのは、自分が投稿すると選んだものだけだ	投稿していない事実を、パターンから推論する	言葉そのものではなく、シグナルを管理する
元を削除すれば、データは消える	すでに複製をモデルの重みに取り込んでいる	公開時に防ぐ。削除は部分的でしかない
身元の偽造には、本人の関与が要る	声・顔・文章を合成する	信用を事前に登録し、生のサンプルを最小化する

前提1——相関には、もう時間がかからない
#

大規模な相関こそ、AI が最初に壊す前提だ。再利用したユーザー名、写真に埋め込まれた位置情報、投稿する時間帯の癖——どれも単体では無害な点を、機械はひとつのプロフィールへと束ねる。かつてのどんな人間の調査員より速く、はるかに安く。古い防御は摩擦だった。アカウントを紐づけるには人手で何時間もかかり、だからこそ大半の敵は手をつけなかった。その摩擦が消えた。

ここでいう相関とは、別々の情報のかけらをひとつの絵につなぎ合わせることだ。危険だったのは、いつだって単一の投稿ではない。つなぎ目だ。仕事用のアカウントと匿名のアカウントが、同じ言い回しの癖を共有している。風景写真には、メタデータ——ファイルに付随し、いつどこで撮られたかを記録する不可視の情報——として GPS 座標が埋め込まれている。配達のレビュー、レースの記録、公開のほしい物リスト。一つひとつは取るに足らないが、合わされば身上調書になる。機械は、まさにそうしたつなぎ目を、何百万もの記録の中から一度に見つけ出すために作られている。

これは古典的な鉄則を読み替えさせる。「機微なものは投稿するな」は、いつも不十分だった。機微なものはしばしば立ち現れる——断片が組み合わさったときに初めて姿を見せるからだ。それに代わる規律が**区画化（コンパートメント化）**だ。自分の複数の文脈が、紐づけられる特徴を共有しないよう、意図して断ち切る。身元ごとに別のユーザー名、別の文体、要所では別の端末とネットワークを使う。そして何かを手放す前に、メタデータは削ぎ落とす。後で相関させられるデータを、国家そのものが提出を強いてくる場合は、これと地続きの、独自の手順書を持つ脅威だ——国家があなたのデータを漏らす日。

前提2——あなたは投稿した以上をさらしている
#

推論が、壊れる2つめの前提だ。あなたが実際に投稿したもののパターンから、モデルは一度も明かしていない事実を導き出す——おそらくの居場所、勤め先、健康状態、人間関係、性的指向まで。古い心の地図は、帳簿だった。露出は、自分が打ち込んだものの総和に等しい、と。だが推論は、その帳簿を「面」に変える。書かれていない余白もまた、語りはじめる。

仕組みは、ありふれた機械学習だ。十分な数の例を与えられると、モデルは学ぶ——ある書き方をし、あるアカウントをフォローし、ある時間帯に投稿する人々には、共通する属性がある傾向だ、と。そしてそのパターンをあなたに当てはめる。あなたは街の名を口にしていない。けれど写真の背景、「おはよう」の投稿時刻、繰り返し使う土地の言い回しが、それを匂わせる。だから、躍起になって削除しても手応えだけで何も変わらないことがある。投稿を1件消したところで、推論を成り立たせているパターンまで消えることは、めったにないからだ。

打てる手は、言葉そのものではなくシグナルを管理することだ。敵が掘り起こすであろうパターン——投稿時刻、位置を語る背景、2つの身元を結びつける言語的な指紋——を、ばらつかせる、あるいは曖昧にする。そして人間関係と居場所を明かすデータは、最も価値の高い標的として扱う。推論が最も速く積み上がるのが、まさにそこだからだ。たいていの人にとって現実的な目標は、推論を打ち負かすことではない。その誤り率を、あなたがもう「最も安く組み立てられるプロフィール」ではなくなる程度まで、押し上げることだ。こうした推論の連鎖が端から端までどう走るのか、より詳しい解剖は、本シリーズの続編で扱う。

前提3——削除は、もうデータに届かない
#

永続性が、AI の壊す3つめの前提だ。あなたの公開テキストや画像が、いったんモデルの学習データに取り込まれてしまえば、元を削除しても、モデルがすでに学んだものは消えない——学習済みの重みの内側まで届く「削除」は存在しない。古い約束は、取り消せることだった。失敗は、公開を取り下げればよかった。だがモデルが相手では、公開は、一度くぐれば戻れない扉に近い。

公開された投稿、キャプション、画像は、Web 規模のデータセットに集められる——主要各社の多くが学習に使う公開インターネットの巨大なアーカイブ、Common Crawl が最もよく知られる——そして言語・画像モデルの学習に使われる。学習済みのモデルに特定のデータを忘れさせようとする研究分野、*機械的忘却（machine unlearning）*は、この問題を、本当に難しく、大規模ではいまだ未解決だとみなしている。確実な対処は、そのデータなしで再学習することだけだが、所有者がたった一人のためにそれを行うことは、まずない。そして取り込みは、無害なぼかしではない。セキュリティ研究者は、学習データの断片が大規模モデルから抽出して取り出せることを実証している。

ここは、AI 時代が、より古い「消えない Web」の問題と最も正面から出会う次元だ。だから繰り返さず、ここで手渡しをする。削除を生き延びるもの——バックアップ、データブローカー、アーカイブ、そして学習用のコーパス（言語資料の集まり）——を点検する全手順は、削除しても消えない——2026年、SNSの足跡はどこまで残るのかにある。脅威モデルとして持ち越すべき帰結は、身もふたもない。後始末より、タイミングが効く。 取り込みは継続的に起こるため、完全に有効な唯一の制御は、そもそも機微なものを公開しないことだ。後から施す防御はすべて部分的でしかない——そしてこの一点が、あなたの優先順位を、削除ツールから「そもそも何を世に出すか」へと組み替えるはずだ。

前提4——あなたの声と顔は、いまや認証情報だ
#

合成された身元が、壊れる4つめの前提だ。声、顔、文章のわずかなサンプルがあれば、モデルは説得力のある偽物を生み出せる——そして、あなたが「本人である証し」として扱う生体的な特徴そのものが、あなたへのなりすましの材料になる。古い前提は、身元の偽造にはあなたの関与か秘密が要る、というものだった。いまや要るのは、あなたが公開したメディアだけだ。

数秒の明瞭な音声があれば声の複製には足り、ひと握りの写真があれば合成の肖像には足り、投稿の蓄積があれば文章の模倣には足りる。これは、ほとんどの人が気づかぬまま頼っていた静かな防御を、崩してしまう——聞き慣れた声や見慣れた顔は、それ自体が本人証明になる、という防御だ。しかも、このリスクは均等には分布しない。なりすまし、捏造された性的な画像、声を使った詐欺は、女性に、そして動機ある嫌がらせ相手を抱える人に、不釣り合いに重くのしかかる。だからこの次元は、単なるデータ衛生の話ではなく、身体と評判の主権にかかわる問題なのだ。

打てる手は2つある。1つめは最小化だ。公開する生の生体サンプルの量と鮮明さを抑える——高音質の声のクリップを減らし、本名に結びついた顔正面の写真を減らす。ただしこれは緩和であって、治療ではないと心得ること。2つめは事前登録された信用だ。大切な相手とのあいだで、あらかじめ、本来の経路の外で——攻撃者には傍受できない別の回線を通じて——検証の一手を取り決めておく。合言葉、かけ直す番号、第二の連絡経路。そうしておけば、電話口の複製された声が、急かして思考を奪うことはできない。声・顔を認証情報として扱うこの問題と、家族の検証手順の全容は、本シリーズで改めて取り上げる。

モデルを組み立て直す——4つの次元のチェックリスト
#

AI 時代に向けて脅威モデルを組み立て直すとは、古典的な OPSEC の4つの問いを、機械の敵に対して問い直し、そのうえで、労力が実際の露出を変える場所を決め直すことだ。 4つの次元を等しく守る必要はない。どの次元が自分の弱点かを見つけ、そこから始めればいい。私たち自身がこの枠組みを通って考えたとき、最も過小評価されていると見たのは推論だった——人は口にしたことを守り、その周りのパターンが同じくらい雄弁に語ることを忘れる。

特定の敵がいない人にとっての、おおよその優先順位で、自分の状況を4つの次元に通してみよう。

次元	機械がすること	あなたが打てる手	どこから始めるか
永続	公開したものを、モデルの重みの中に保持する	公開を減らす。公開版は削除できないものとして扱う	最初——取り返しがつかない
合成された身元	わずかなサンプルから声と顔を偽造する	生のサンプルを最小化し、経路外の検証を事前登録する	最初——個人への害が大きい
相関	散らばった断片を、安くひとつのプロフィールに束ねる	区画化する。ユーザー名・端末を分け、メタデータを削ぐ	次に
推論	投稿していない事実を、パターンから導く	シグナルを管理する。居場所・行動・人間関係の手がかりを曖昧にする	継続的に

この表ではなく、自分自身の人生に照らして順位をつけること——要は、自分の弱点を見つけ、まずそこで動くことであって、4つを等しく守ることではない。

過剰投資すべきでないものについて、ひとこと。規制だ。EU AI Act は2026年8月2日に、その規定の大半の適用を始める。だが高リスクシステムに対する最も厳しい義務は、2026年5月の「Digital Omnibus」合意のもとで、2027年12月と2028年8月へと先送りされた。データ保護当局は真剣に取り組んでいる。欧州データ保護会議（EDPB）のOpinion 28/2024は、2024年12月18日に採択され、GDPR の原則が AI モデルにどう適用されるか——モデルがいつ匿名とみなしうるか、違法に学習されたモデルが何を負うのか、を含めて——を示した。これは注視する価値のある、動き続ける最前線だ——そして、頼りにするには心もとないものだ。あなたの脅威モデルは、法が追いつくまでの年月を持ちこたえなければならない。だからこそ、それはあなた自身のものでなければならないのだ。

「電子の時代において、プライバシーは開かれた社会に欠かせない。……政府にも、企業にも、その他の顔のない巨大な組織にも、その善意からプライバシーを与えてくれるなどと期待することはできない。」 — エリック・ヒューズ『暗号無政府主義者宣言（A Cypherpunk’s Manifesto）』1993

この一文は、暗号と電子メールについて書かれた。だがいまでは、機械の敵を言い当てた言葉として読める。道具は変わり、原理は変わらなかった。誰も代わりに組み立ててはくれないから、自分でモデルを組み立てる。そして、実際の露出を動かす場所に労力を注ぐ——残りのPrivacy 柱も手元に置いておくこと。ここで挙げた各次元には、それぞれより深い地図があるのだから。

結論——あなたの弱点は、どの次元か
#

AI 時代の OPSEC にふさわしい水準は、あなたの脅威モデルに合うものだ——どの次元があなたの弱点かは、自分が誰から身を守ろうとしているかで、まるごと決まる。

特定の敵がいない、ふつうの利用者なら： 最も効果の高い一手は永続と合成された身元だ——公開に間（ま）を置く習慣を取り入れ、最も身元の知れる生の声と顔のサンプルを削る。理由ができるまで、残りは後回しでいい。
複数の身元を保つなら——仮名のクリエイター、活動家、文脈どうしを決して結びつけてはならない人：相関が最前線だ。容赦なく区画化すること。たった1つの再利用したユーザー名が、ほかのすべてを台無しにしうる。
非対称なリスクを抱えるなら——ハラスメントに直面する女性、被害から逃れてきた人、公の場に立つ専門職：合成された身元と推論を優先し、経路外の検証手順は「任意」ではなく必須として扱うこと。

4つすべてに共通して、人間が敵だった時代と同じ真実が成り立つ——事後に削除して安全にたどり着くことは、確実にはできない。できるのは、自分が実際に抱える敵をモデル化し、意図して決め、機械に残してほしくないものを、より少なく公開することだけだ。

要点

AI 時代の OPSEC は、機械の敵に対する脅威モデル化だ——相関し、推論し、記憶し、合成する敵であって、人間だけが相手ではない。
相関： 機械は、単体では無害な断片（再利用したアカウント名、写真の GPS メタデータ、投稿の癖）をひとつのプロフィールに束ねる。打てる手は沈黙ではなく、区画化だ。
推論： モデルは、投稿していない事実——居場所、人間関係、勤め先——をパターンから導く。だから投稿を1件消しても、あなたをさらすパターンまで消えることはまれだ。
永続： いったん学習データに取り込まれれば、コンテンツはモデルの重みの中で生き残る。機械的忘却は大規模では未解決で、後始末よりタイミングが効く。
合成された身元： 数秒の声か数枚の写真で、説得力のある偽物が作れる——これは性差のあるリスクだ。だから生のサンプルを最小化し、経路外の検証を事前登録すること。
法を待たない： EU AI Act の高リスク義務は2027〜2028年へ先送りされた。その間、持ちこたえるのはあなたの脅威モデルだ。

よくある質問
#

AI 時代の OPSEC とは何ですか？ AI 時代の OPSEC とは、機械の敵に向けて組み立て直した OPSEC です。古典的な OPSEC は、有限の時間しか持たない人間の調査員をモデル化していました。AI 時代の OPSEC がモデル化するのは、データを大規模に相関させ、あなたが一度も投稿していないものを推論し、公開したものをモデルの重みの中に保持し、声と顔を合成しうるシステムです。実際には、標準的な脅威モデルの問い——何を守るのか、誰が欲しがるのか、その相手に何ができるのか——を、これら4つの能力に対して問い直すことを意味します。

AI は本当に、「匿名」のデータから私の身元を割り出せますか？ しばしば、割り出せます。名前を投稿に載せない、という「省略による匿名」は、推論と相関に対して脆弱です。モデルは、パターンから、そして別々のデータセットをまたぐつなぎ目から、あなたを再特定できるからです。強い「紐づけられなさ」は、ただ名前を伏せることからではなく、区画化（別々のユーザー名・端末・ネットワーク、そして削ぎ落としたメタデータ）から生まれます。

AI 学習からのオプトアウトは、実際に役立ちますか？ 部分的に、そしておもに将来に向けて役立ちます。オプトアウトや「学習させない」シグナルは、プラットフォームがそれを尊重する範囲で、将来の取り込みを減らせます。ただし、すでに学習済みのモデルに取り込まれたデータには届きませんし、機械的忘却は大規模では未解決のままです。オプトアウトは、削除ボタンではなく、いくつかある予防策のひとつとして扱うこと。

EU AI Act は、個人としての私を守ってくれますか？ すぐには守りませんし、あなた自身の脅威モデルの代わりにはなりません。同法の規定の大半は2026年8月から適用されますが、最も厳しい高リスク義務は、2026年5月の Digital Omnibus 合意のもとで2027年12月と2028年8月へ先送りされました。規制は、遅く、不均一な後ろ盾です。その間あなたが握るのは、この記事にある制御です。

#	出典	URL	アーカイブ
1	Pew Research Center——“What the data says about Americans’ views of AI”（2026年3月）	https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/	https://web.archive.org/web/*/https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/
2	Pew Research Center——“How Americans View Data Privacy”（2023年10月）	https://www.pewresearch.org/internet/2023/10/18/how-americans-view-data-privacy/	https://web.archive.org/web/*/https://www.pewresearch.org/internet/2023/10/18/how-americans-view-data-privacy/
3	EU Artificial Intelligence Act——Implementation Timeline	https://artificialintelligenceact.eu/implementation-timeline/	https://web.archive.org/web/*/https://artificialintelligenceact.eu/implementation-timeline/
4	EDPB——Opinion 28/2024 on AI models and GDPR（2024年12月18日）	https://www.edpb.europa.eu/news/news/2024/edpb-opinion-ai-models-gdpr-principles-support-responsible-ai_en	https://web.archive.org/web/*/https://www.edpb.europa.eu/news/news/2024/edpb-opinion-ai-models-gdpr-principles-support-responsible-ai_en
5	Carlini ほか——“Extracting Training Data from Large Language Models”（USENIX Security 2021）	https://arxiv.org/abs/2012.07805	https://web.archive.org/web/*/https://arxiv.org/abs/2012.07805

Claude（Anthropic）——身元要件とデータの扱いの記録

Tue, 14 Jul 2026 00:00:00 +0000

開示事項：本ページの性質 · アフィリエイト · 訂正窓口

本ページは事実の記録です。助言・推奨・勧誘・保証ではなく、掲載は承認を意味しません。ポリシーは変わるため、値に依拠する前に事業者の一次文書を確認してください。
現在、掲載サービスとのアフィリエイト関係は一切ありません。将来導入する場合は該当箇所に明記し、掲載や並び順には影響させず、変更はこのページに記録します。
掲載事業者または読者が値に誤りがあると考える場合は、次の窓口へ連絡できます。確認の結果、データセットの誤りと判断した場合は公開訂正します。連絡先： editor@cypherpunkguide.com
データの収集・確認方法（方法論）

現行記録の状態

名称: Claude · Claude.ai
事業者: Anthropic (直接提供型)
記録のある比較項目: 8/17項目に少なくとも1件の適用範囲付き記録
現行記録の情報源: 事業者の公表文書8件 · 画面上の実地観測0件

このパイロットに現行の範囲付き記録がない項目：

登録に要る識別子
決済・請求時の身元情報
入力内容の接続先事業者への転送
会話の人手による確認
保持期間
任意で使えるプライバシー設定
データ管理者が示す法域
第三者によるサイト分析
収集されるメタデータ（IPなど）

アカウント要否

条件付き

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
アカウント確認方式: メール確認
発動条件: 有料プランへのアップグレード
ひも付く先: アカウント
受領者: Anthropic（Claude）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/API
KYC Driftへの初回収録: 2026-07-13

To access our Services, we may ask you to create an Account.

— アーカイブ版 · 取得日 2026-07-13

you must sign up for a subscription with us (a “ Subscription ”), first by creating an Account

— アーカイブ版 · 取得日 2026-07-13

ログイン方式（SSO／ウォレット）

Google SSOまたはメールのワンタイムリンク

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント · 第三者
受領者: Anthropic（Claude） · Google
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/デスクトップ/モバイル
文書日付: 2026-05-19 (文書の最終更新日)
KYC Driftへの初回収録: 2026-07-13

you will see two different options for logging in to your Claude account. Continue with Google ... Continue with email

— アーカイブ版 · 取得日 2026-07-10

登録時の電話番号

必須

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
アカウント確認方式: SMS ワンタイムコード
制約: VoIP 番号は拒否 · Google Voice は拒否 · アプリ生成番号は拒否 · 固定電話は拒否 · 対応地域のみ · 1 番号 1 アカウント
ひも付く先: アカウント
受領者: Anthropic（Claude）
適用範囲: 地域: 対応地域 · プラン: 無料/有料 · 画面・経路: Web/デスクトップ/モバイル · 登録経路: Google SSO/メール
文書日付: 2026-05-19 (文書の最終更新日)
KYC Driftへの初回収録: 2026-07-13

We require phone verification for all new users, and there isn't a way to skip this step.

— アーカイブ版 · 取得日 2026-07-13

you'll be asked to enter your phone number from a supported location to receive a verification code via text message

— アーカイブ版 · 取得日 2026-07-13

you cannot use VoIP numbers, Google Voice, phone numbers created using apps, landlines, or other numbers that can't receive texts to verify your account.

— アーカイブ版 · 取得日 2026-07-13

登録時のメール

条件付き

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 収集する場合あり（事業者文書の表現）
発動条件: メール登録経路を選んだ場合（代替はGoogle SSO）
ひも付く先: アカウント
受領者: Anthropic（Claude）
適用範囲: 地域: 対応地域 · プラン: 無料/有料 · 画面・経路: Web/API
KYC Driftへの初回収録: 2026-07-13

Anthropic collects identifiers, including your name, email address, and phone number when you sign up for an Anthropic account

— アーカイブ版 · 取得日 2026-07-13

最低年齢

18歳以上

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント
受領者: Anthropic（Claude）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/API
KYC Driftへの初回収録: 2026-07-13

You must be at least 18 years old or the minimum age required to consent to use the Services in your location, whichever is higher.

— アーカイブ版 · 取得日 2026-07-13

継続利用

利用中・復旧時の身元／電話番号確認

条件付き

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 収集する場合あり（事業者文書の表現）
アカウント確認方式: 政府発行 ID または年齢証明
発動条件: 事業者の裁量（「特定の状況では」）
ひも付く先: アカウント
受領者: Anthropic（Claude）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/API
KYC Driftへの初回収録: 2026-07-13

Verification Data: In certain circumstances, we may ask you to verify your age or identity.

— アーカイブ版 · 取得日 2026-07-13

入力内容の学習利用

既定で有効（オプトアウト可）

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
ひも付く先: アカウント
受領者: Anthropic（Claude）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-13

We may use your Inputs and Outputs to train and improve Anthropic AI models, unless you opt out through your account settings.

— アーカイブ版 · 取得日 2026-07-13

削除

削除と識別子の再利用

利用可

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント
受領者: Anthropic（Claude）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-13

You also are able to delete individual conversations, which will be removed immediately from your conversation history and automatically deleted from our back-end within 30 days.

— アーカイブ版 · 取得日 2026-07-13

根拠資料

表では、主張を最初に支えた取得記録と、同じ変更不能な証拠系列の最新再確認を分けます。文書のSHA-256値は保存済み本文を、画面上の確認実行に付したダイジェストは確認済みの機微情報除去済み検証資料を識別します。いずれも変更検知には使えますが、それ自体で取得時刻を証明するものではありません。

証拠の役割	情報源	アーカイブ／結果	取得日／観測日	記録日／本文確認日	sha256
最初の裏付けとなる取得記録・最新再確認	https://www.anthropic.com/legal/consumer-terms	アーカイブ版	2026-07-13	2026-07-13	`731724432cfff0c19f2b8a2da4610f0107442a100d35c405a2d88ff4bcff1070`
最初の裏付けとなる取得記録・最新再確認	https://support.claude.com/en/articles/13189465-log-in-to-your-claude-account	アーカイブ版	2026-07-10	2026-07-13	`2493243a906bbc42a13cb20a5767449b03f2a9462cdeb5eecb8532269f8059cb`
最初の裏付けとなる取得記録・最新再確認	https://support.claude.com/en/articles/8287232-verify-your-phone-number	アーカイブ版	2026-07-13	2026-07-13	`c789de708f21e72e768e9eda79de4bd3374e6dca0690b6ccf91148f93f48177c`
最初の裏付けとなる取得記録・最新再確認	https://www.anthropic.com/legal/privacy	アーカイブ版	2026-07-13	2026-07-13	`a2fdc63d6bb693e172a803a2da85dbad2619d4022265cdb2cb0f2f2afb476168`

DeepSeek——身元要件とデータの扱いの記録

Tue, 14 Jul 2026 00:00:00 +0000

開示事項：本ページの性質 · アフィリエイト · 訂正窓口

本ページは事実の記録です。助言・推奨・勧誘・保証ではなく、掲載は承認を意味しません。ポリシーは変わるため、値に依拠する前に事業者の一次文書を確認してください。
現在、掲載サービスとのアフィリエイト関係は一切ありません。将来導入する場合は該当箇所に明記し、掲載や並び順には影響させず、変更はこのページに記録します。
掲載事業者または読者が値に誤りがあると考える場合は、次の窓口へ連絡できます。確認の結果、データセットの誤りと判断した場合は公開訂正します。連絡先： editor@cypherpunkguide.com
データの収集・確認方法（方法論）

現行記録の状態

名称: DeepSeek · DeepSeek Chat
事業者: DeepSeek (直接提供型)
記録のある比較項目: 6/17項目に少なくとも1件の適用範囲付き記録
現行記録の情報源: 事業者の公表文書4件 · 画面上の実地観測0件

このパイロットに現行の範囲付き記録がない項目：

アカウント要否
ログイン方式（SSO／ウォレット）
最低年齢
利用中・復旧時の身元／電話番号確認
決済・請求時の身元情報
入力内容の接続先事業者への転送
会話の人手による確認
保持期間
任意で使えるプライバシー設定
第三者によるサイト分析
収集されるメタデータ（IPなど）

登録に要る識別子

メールまたは電話

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
アカウント確認方式: 経路により異なる
ひも付く先: アカウント
受領者: DeepSeek（中国）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-14

We collect Personal Data that you provide when you set up an account, such as your date of birth (where applicable), username (where applicable), email address and/or telephone number, and password.

— アーカイブ版 · 取得日 2026-07-14

継続利用

データ管理者が示す法域

中国（CN）

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント · 親会社プロファイル
受領者: DeepSeek（中国）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-14

The Services are provided and controlled by Hangzhou DeepSeek Artificial Intelligence Co., Ltd., with its registered address in China (“we” or “us”).

— アーカイブ版 · 取得日 2026-07-14

入力内容の学習利用

既定で有効（オプトアウト記載なし）

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
ひも付く先: アカウント
受領者: DeepSeek（中国）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-14

To improve and develop the Services and to train and improve our technology, such as our machine learning models and algorithms.

— アーカイブ版 · 取得日 2026-07-14

削除

削除と識別子の再利用

利用可

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント
受領者: DeepSeek（中国）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-14

you may also copy or delete your chat history via your settings.

— アーカイブ版 · 取得日 2026-07-14

根拠資料

証拠の役割	情報源	アーカイブ／結果	取得日／観測日	記録日／本文確認日	sha256
最初の裏付けとなる取得記録・最新再確認	https://cdn.deepseek.com/policies/en-US/deepseek-privacy-policy.html	アーカイブ版	2026-07-14	2026-07-14	`339984e36a795843ee2b5b917797072ec249f3c0e9ff7cbbfe754c01caa4f069`

Gemini（Google）——身元要件とデータの扱いの記録

Tue, 14 Jul 2026 00:00:00 +0000

開示事項：本ページの性質 · アフィリエイト · 訂正窓口

本ページは事実の記録です。助言・推奨・勧誘・保証ではなく、掲載は承認を意味しません。ポリシーは変わるため、値に依拠する前に事業者の一次文書を確認してください。
現在、掲載サービスとのアフィリエイト関係は一切ありません。将来導入する場合は該当箇所に明記し、掲載や並び順には影響させず、変更はこのページに記録します。
掲載事業者または読者が値に誤りがあると考える場合は、次の窓口へ連絡できます。確認の結果、データセットの誤りと判断した場合は公開訂正します。連絡先： editor@cypherpunkguide.com
データの収集・確認方法（方法論）

現行記録の状態

名称: Gemini · Google Gemini
事業者: Google (直接提供型)
記録のある比較項目: 6/17項目に少なくとも1件の適用範囲付き記録
現行記録の情報源: 事業者の公表文書6件 · 画面上の実地観測0件

このパイロットに現行の範囲付き記録がない項目：

登録時の電話番号
登録時のメール
ログイン方式（SSO／ウォレット）
最低年齢
利用中・復旧時の身元／電話番号確認
決済・請求時の身元情報
入力内容の接続先事業者への転送
入力内容の学習利用
削除と識別子の再利用
データ管理者が示す法域
第三者によるサイト分析

アカウント要否

条件付き

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
アカウント確認方式: パスワード
発動条件: ログイン状態での利用
ひも付く先: アカウント · 親会社プロファイル
受領者: Google
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
文書日付: 2026-06-29 (文書の最終更新日)
KYC Driftへの初回収録: 2026-07-13

When you're signed in, we also collect information that we store with your Google Account, which we treat as personal information.

— アーカイブ版 · 取得日 2026-07-13

When you use Gemini Apps while signed out, Google processes your data (like your IP address and browser type) per the Google Privacy Policy .

— アーカイブ版 · 取得日 2026-07-13

登録に要る識別子

必須

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
ひも付く先: アカウント · 親会社プロファイル
受領者: Google
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
KYC Driftへの初回収録: 2026-07-13

When you create a Google Account, you provide us with personal information that includes your name and a password.

— アーカイブ版 · 取得日 2026-07-13

継続利用

会話の人手による確認

あり

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
ひも付く先: アカウント · 第三者
受領者: Google · 業務委託先
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
文書日付: 2026-06-29 (文書の最終更新日)
KYC Driftへの初回収録: 2026-07-13

Human reviewers (including trained reviewers from our service providers) review some of the data we collect for these purposes.

— アーカイブ版 · 取得日 2026-07-13

任意で使えるプライバシー設定

利用可

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント
受領者: Google
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
文書日付: 2026-06-29 (文書の最終更新日)
KYC Driftへの初回収録: 2026-07-13

You can also use temporary chats, which are not used to improve Google AI with help from human reviewers.

— アーカイブ版 · 取得日 2026-07-13

収集されるメタデータ（IPなど）

収集される

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 自動収集
ひも付く先: アカウント · 端末
受領者: Google
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
文書日付: 2026-06-29 (文書の最終更新日)
KYC Driftへの初回収録: 2026-07-13

Location information: the general area from your device, IP address, or Home or Work addresses in your Google Account.

— アーカイブ版 · 取得日 2026-07-13

削除

保持期間

最大3年

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
発動条件: 会話が人間レビューの対象になった場合
ひも付く先: アカウント
受領者: Google
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
文書日付: 2026-06-29 (文書の最終更新日)
KYC Driftへの初回収録: 2026-07-13

Instead, they are retained for up to three years.

— アーカイブ版 · 取得日 2026-07-13

根拠資料

証拠の役割	情報源	アーカイブ／結果	取得日／観測日	記録日／本文確認日	sha256
最初の裏付けとなる取得記録・最新再確認	https://policies.google.com/privacy	アーカイブ版	2026-07-13	2026-07-13	`35a5f8416bb2ab8ddfe15523696989dc57cb1763050e00d3df2cb4c822da262f`
最初の裏付けとなる取得記録・最新再確認	https://support.google.com/gemini/answer/13594961	アーカイブ版	2026-07-13	2026-07-13	`df5172a0969cda86258428f0bc7b82af2ba267ca1b895225185a03616e592b9a`

Le Chat（Mistral AI）——身元要件とデータの扱いの記録

Tue, 14 Jul 2026 00:00:00 +0000

開示事項：本ページの性質 · アフィリエイト · 訂正窓口

本ページは事実の記録です。助言・推奨・勧誘・保証ではなく、掲載は承認を意味しません。ポリシーは変わるため、値に依拠する前に事業者の一次文書を確認してください。
現在、掲載サービスとのアフィリエイト関係は一切ありません。将来導入する場合は該当箇所に明記し、掲載や並び順には影響させず、変更はこのページに記録します。
掲載事業者または読者が値に誤りがあると考える場合は、次の窓口へ連絡できます。確認の結果、データセットの誤りと判断した場合は公開訂正します。連絡先： editor@cypherpunkguide.com
データの収集・確認方法（方法論）

現行記録の状態

名称: Le Chat · Mistral
事業者: Mistral AI (直接提供型)
記録のある比較項目: 9/17項目に少なくとも1件の適用範囲付き記録
現行記録の情報源: 事業者の公表文書9件 · 画面上の実地観測0件

このパイロットに現行の範囲付き記録がない項目：

登録に要る識別子
ログイン方式（SSO／ウォレット）
利用中・復旧時の身元／電話番号確認
決済・請求時の身元情報
入力内容の接続先事業者への転送
会話の人手による確認
第三者によるサイト分析
収集されるメタデータ（IPなど）

アカウント要否

条件付き

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
発動条件: 製品による（一部の製品でアカウント必須）
ひも付く先: アカウント
受領者: Mistral AI（フランス）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
発効日: 2026-05-28 (文書に発効日と明記)
KYC Driftへの初回収録: 2026-07-14

Some Mistral AI Products require a Mistral AI account.

— アーカイブ版 · 取得日 2026-07-14

登録時のメール

収集される

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 収集される
ひも付く先: アカウント
受領者: Mistral AI（フランス）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
発効日: 2026-04-08 (文書に発効日と明記)
KYC Driftへの初回収録: 2026-07-14

Contact Data, such as your email address.

— アーカイブ版 · 取得日 2026-07-14

When you create your Mistral AI Account and subscribe to a Mistral AI Product.

— アーカイブ版 · 取得日 2026-07-14

登録時の電話番号

提供した場合に収集

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 収集する場合あり（事業者文書の表現）
ひも付く先: アカウント
受領者: Mistral AI（フランス）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
発効日: 2026-04-08 (文書に発効日と明記)
KYC Driftへの初回収録: 2026-07-14

Account Data (such as the phone number or email address you provided to verify or change your account password, etc.):

— アーカイブ版 · 取得日 2026-07-14

最低年齢

13歳以上

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント
受領者: Mistral AI（フランス）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
発効日: 2026-05-28 (文書に発効日と明記)
KYC Driftへの初回収録: 2026-07-14

You must be at least thirteen (13) years old to use the Mistral AI Products

— アーカイブ版 · 取得日 2026-07-14

継続利用

データ管理者が示す法域

フランス（FR）

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント · 親会社プロファイル
受領者: Mistral AI（フランス）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
発効日: 2026-04-08 (文書に発効日と明記)
KYC Driftへの初回収録: 2026-07-14

Mistral AI is a French company incorporated in Paris, under number 952 418 325, having its registered offices at 15 rue des Halles, 75001 Paris

— アーカイブ版 · 取得日 2026-07-14

Mistral AI is the data controller.

— アーカイブ版 · 取得日 2026-07-14

入力内容の学習利用

既定で有効（オプトアウト可）

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
ひも付く先: アカウント
受領者: Mistral AI（フランス）
適用範囲: 地域: 全地域（既定） · プラン: 無料 · 画面・経路: Web/アプリ
発効日: 2026-05-28 (文書に発効日と明記)
KYC Driftへの初回収録: 2026-07-14

We do not use Your Data to train our artificial intelligence models except (a) when you (i) use Mistral AI Products under a free subscription, or are subscribed to Vibe Pro or Vibe Student, and (ii) you have not opted-out of training,

— アーカイブ版 · 取得日 2026-07-14

We’ve introduced a user control which allows you to object to the use of your input and output data for model training directly from your account.

— アーカイブ版 · 取得日 2026-07-14

Please note that we do not use your Input and Output to train our artificial intelligence models when you use Le Chat Enterprise or the paid version of our APIs.

— アーカイブ版 · 取得日 2026-07-14

保持期間

利用者が消すまで

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント
受領者: Mistral AI（フランス）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
発効日: 2026-04-08 (文書に発効日と明記)
KYC Driftへの初回収録: 2026-07-14

we keep your Input and Output until you delete your account or until you delete the conversation from Le Chat.

— アーカイブ版 · 取得日 2026-07-14

任意で使えるプライバシー設定

利用可

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント
受領者: Mistral AI（フランス）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
発効日: 2026-04-08 (文書に発効日と明記)
KYC Driftへの初回収録: 2026-07-14

Turn off Memories at all times through your settings.

— アーカイブ版 · 取得日 2026-07-14

削除

削除と識別子の再利用

利用可

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント
受領者: Mistral AI（フランス）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/アプリ
発効日: 2026-04-08 (文書に発効日と明記)
KYC Driftへの初回収録: 2026-07-14

for 1 year after you delete your account.

— アーカイブ版 · 取得日 2026-07-14

Your Civil Identity Data (your first and last name, etc.): for 5 years after the termination of your Mistral AI account.

— アーカイブ版 · 取得日 2026-07-14

根拠資料

証拠の役割	情報源	アーカイブ／結果	取得日／観測日	記録日／本文確認日	sha256
最初の裏付けとなる取得記録・最新再確認	https://legal.mistral.ai/terms/privacy-policy	アーカイブ版	2026-07-14	2026-07-14	`a8406676deefa30f582c624c559d97645502eca7f1d9b4ac6d0db755510a55ab`
最初の裏付けとなる取得記録・最新再確認	https://legal.mistral.ai/terms/eu-consumers-terms-of-service	アーカイブ版	2026-07-14	2026-07-14	`b01bd5bb70e7199f54dc6f6f9365b3bef8c26b55f4e1d2355e1de1dc87d336a9`

ChatGPT（OpenAI）——身元要件とデータの扱いの記録

Tue, 14 Jul 2026 00:00:00 +0000

開示事項：本ページの性質 · アフィリエイト · 訂正窓口

本ページは事実の記録です。助言・推奨・勧誘・保証ではなく、掲載は承認を意味しません。ポリシーは変わるため、値に依拠する前に事業者の一次文書を確認してください。
現在、掲載サービスとのアフィリエイト関係は一切ありません。将来導入する場合は該当箇所に明記し、掲載や並び順には影響させず、変更はこのページに記録します。
掲載事業者または読者が値に誤りがあると考える場合は、次の窓口へ連絡できます。確認の結果、データセットの誤りと判断した場合は公開訂正します。連絡先： editor@cypherpunkguide.com
データの収集・確認方法（方法論）

現行記録の状態

名称: ChatGPT
事業者: OpenAI (直接提供型)
記録のある比較項目: 3/17項目に少なくとも1件の適用範囲付き記録
現行記録の情報源: 事業者の公表文書4件 · 画面上の実地観測0件

このパイロットに現行の範囲付き記録がない項目：

アカウント要否
登録に要る識別子
登録時の電話番号
登録時のメール
ログイン方式（SSO／ウォレット）
最低年齢
利用中・復旧時の身元／電話番号確認
入力内容の接続先事業者への転送
会話の人手による確認
保持期間
任意で使えるプライバシー設定
データ管理者が示す法域
第三者によるサイト分析
収集されるメタデータ（IPなど）

継続利用

入力内容の学習利用

既定で有効（オプトアウト可）

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
ひも付く先: アカウント
受領者: OpenAI（ChatGPT）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-13

we may use Content you provide us to improve our Services, for example to train the models that power ChatGPT.

— アーカイブ版 · 取得日 2026-07-11

Read our instructions on how you can opt out of our use of your Content to train our models.

— アーカイブ版 · 取得日 2026-07-11

決済

決済・請求時の身元情報

必須

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
アカウント確認方式: メール確認
発動条件: 有料プランへのアップグレード
ひも付く先: アカウント · 課金身元
受領者: OpenAI（ChatGPT）
適用範囲: 地域: 全地域（既定） · プラン: 有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-13

To upgrade to Plus/Pro/Teams, a user will still be required to verify an email.

— アーカイブ版 · 取得日 2026-07-13

削除

削除と識別子の再利用

削除後に再利用可

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント
受領者: OpenAI（ChatGPT）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-13

With some exceptions, we do allow consumers who have deleted their ChatGPT account to re-register using the same phone number.

— アーカイブ版 · 取得日 2026-07-13

削除と識別子の再利用

利用可

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント
受領者: OpenAI（ChatGPT）
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-13

Once you choose to delete Personal Data, we will remove it from our systems within 30 days

— アーカイブ版 · 取得日 2026-07-11

根拠資料

証拠の役割	情報源	アーカイブ／結果	取得日／観測日	記録日／本文確認日	sha256
最初の裏付けとなる取得記録・最新再確認	https://help.openai.com/en/articles/10388702-phone-only-signups	アーカイブ版	2026-07-13	2026-07-13	`cd6eac339eb7e485a952b5c50c5c63209b6f440c12ff0ed24e1cb48b24862ceb`
最初の裏付けとなる取得記録・最新再確認	https://openai.com/policies/row-privacy-policy/	アーカイブ版	2026-07-11	2026-07-13	`8f30b38251d856ce871031eb507aaa551f632c47ee1579c773a1ca50505721ca`

OpenRouter——身元要件とデータの扱いの記録

Tue, 14 Jul 2026 00:00:00 +0000

開示事項：本ページの性質 · アフィリエイト · 訂正窓口

本ページは事実の記録です。助言・推奨・勧誘・保証ではなく、掲載は承認を意味しません。ポリシーは変わるため、値に依拠する前に事業者の一次文書を確認してください。
現在、掲載サービスとのアフィリエイト関係は一切ありません。将来導入する場合は該当箇所に明記し、掲載や並び順には影響させず、変更はこのページに記録します。
掲載事業者または読者が値に誤りがあると考える場合は、次の窓口へ連絡できます。確認の結果、データセットの誤りと判断した場合は公開訂正します。連絡先： editor@cypherpunkguide.com
データの収集・確認方法（方法論）

現行記録の状態

名称: OpenRouter
事業者: OpenRouter (ルーター／集約サービス)
記録のある比較項目: 6/17項目に少なくとも1件の適用範囲付き記録
現行記録の情報源: 事業者の公表文書6件 · 画面上の実地観測0件

このパイロットに現行の範囲付き記録がない項目：

登録に要る識別子
登録時の電話番号
ログイン方式（SSO／ウォレット）
最低年齢
利用中・復旧時の身元／電話番号確認
会話の人手による確認
保持期間
削除と識別子の再利用
任意で使えるプライバシー設定
データ管理者が示す法域
収集されるメタデータ（IPなど）

アカウント要否

必須

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
アカウント確認方式: パスワード
ひも付く先: アカウント · 第三者認証基盤
受領者: OpenRouter · 認証基盤
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/API
KYC Driftへの初回収録: 2026-07-13

To access most features of the Service, you must register for an account.

— アーカイブ版 · 取得日 2026-07-13

登録時のメール

条件付き

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 収集する場合あり（事業者文書の表現）
ひも付く先: アカウント · 第三者認証基盤
受領者: OpenRouter · 認証基盤
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/API
KYC Driftへの初回収録: 2026-07-13

you may be required to provide us or our authentication platform with some information about yourself, such as your email address or other contact information.

— アーカイブ版 · 取得日 2026-07-13

継続利用

入力内容の接続先事業者への転送

下流事業者へ送信

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
ひも付く先: 下流のモデル事業者
受領者: 選択されたモデル提供事業者
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/API
KYC Driftへの初回収録: 2026-07-13

When you submit Inputs through the Service, those Inputs are transmitted to the Model Provider you select, or that is selected through automatic routing, as applicable.

— アーカイブ版 · 取得日 2026-07-13

第三者によるサイト分析

あり

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 自動収集
ひも付く先: 第三者
受領者: Google Analytics
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-13

Presently, we use Google Analytics.

— アーカイブ版 · 取得日 2026-07-13

入力内容の学習利用

下流事業者ごとに異なる（選択可）

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: 下流のモデル事業者
受領者: 選択されたモデル提供事業者
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web/API
KYC Driftへの初回収録: 2026-07-14

Different Model Providers have different data practices, including with respect to whether they retain or use your Inputs and Outputs to train, fine-tune, evaluate, or improve their Models.

— アーカイブ版 · 取得日 2026-07-13

If you do not want your Inputs used for model training, select a Model or Model Provider that commits to not using your data for that purpose.

— アーカイブ版 · 取得日 2026-07-13

決済

決済・請求時の身元情報

暗号資産決済に対応

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-13 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: 課金身元
受領者: OpenRouter
適用範囲: 地域: 全地域（既定） · プラン: 有料 · 画面・経路: Web/API
KYC Driftへの初回収録: 2026-07-13

Cryptocurrency payments are never refundable.

— アーカイブ版 · 取得日 2026-07-13

根拠資料

証拠の役割	情報源	アーカイブ／結果	取得日／観測日	記録日／本文確認日	sha256
最初の裏付けとなる取得記録・最新再確認	https://openrouter.ai/terms	アーカイブ版	2026-07-13	2026-07-13	`d264e051a102a9671dab6759d6235011403a199d9a33f494e5d4592698756dd8`
最初の裏付けとなる取得記録・最新再確認	https://openrouter.ai/privacy	アーカイブ版	2026-07-13	2026-07-13	`2b67c33c413db66aa2b4fc37b1cf13d021496acc0716cc3a89bd397163b17d67`

Perplexity——身元要件とデータの扱いの記録

Tue, 14 Jul 2026 00:00:00 +0000

開示事項：本ページの性質 · アフィリエイト · 訂正窓口

本ページは事実の記録です。助言・推奨・勧誘・保証ではなく、掲載は承認を意味しません。ポリシーは変わるため、値に依拠する前に事業者の一次文書を確認してください。
現在、掲載サービスとのアフィリエイト関係は一切ありません。将来導入する場合は該当箇所に明記し、掲載や並び順には影響させず、変更はこのページに記録します。
掲載事業者または読者が値に誤りがあると考える場合は、次の窓口へ連絡できます。確認の結果、データセットの誤りと判断した場合は公開訂正します。連絡先： editor@cypherpunkguide.com
データの収集・確認方法（方法論）

現行記録の状態

名称: Perplexity · Perplexity AI
事業者: Perplexity (検索 AI)
記録のある比較項目: 2/17項目に少なくとも1件の適用範囲付き記録
現行記録の情報源: 事業者の公表文書2件 · 画面上の実地観測0件

このパイロットに現行の範囲付き記録がない項目：

アカウント要否
登録時の電話番号
登録時のメール
ログイン方式（SSO／ウォレット）
最低年齢
利用中・復旧時の身元／電話番号確認
決済・請求時の身元情報
入力内容の接続先事業者への転送
会話の人手による確認
保持期間
削除と識別子の再利用
任意で使えるプライバシー設定
データ管理者が示す法域
第三者によるサイト分析
収集されるメタデータ（IPなど）

登録に要る識別子

必須

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
ひも付く先: アカウント · 端末
受領者: Perplexity
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-14

Account Registration When you make an account, we collect your name, contact information, username and password, and, in some instances, device and network identifiers

— アーカイブ版 · 取得日 2026-07-06

継続利用

入力内容の学習利用

メール内容は除外

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: アカウント
受領者: Perplexity
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-14

We do not use the content of emails to create, train, improve, or fine-tune AI models.

— アーカイブ版 · 取得日 2026-07-06

根拠資料

証拠の役割	情報源	アーカイブ／結果	取得日／観測日	記録日／本文確認日	sha256
最初の裏付けとなる取得記録・最新再確認	https://www.perplexity.ai/hub/legal/privacy-policy	アーカイブ版	2026-07-06	2026-07-14	`3a3038bcfab1f5536754352156df2ae1dadf135b276afa31995003c573b241ee`

Venice——身元要件とデータの扱いの記録

Tue, 14 Jul 2026 00:00:00 +0000

開示事項：本ページの性質 · アフィリエイト · 訂正窓口

本ページは事実の記録です。助言・推奨・勧誘・保証ではなく、掲載は承認を意味しません。ポリシーは変わるため、値に依拠する前に事業者の一次文書を確認してください。
現在、掲載サービスとのアフィリエイト関係は一切ありません。将来導入する場合は該当箇所に明記し、掲載や並び順には影響させず、変更はこのページに記録します。
掲載事業者または読者が値に誤りがあると考える場合は、次の窓口へ連絡できます。確認の結果、データセットの誤りと判断した場合は公開訂正します。連絡先： editor@cypherpunkguide.com
データの収集・確認方法（方法論）

現行記録の状態

名称: Venice · Venice.ai
事業者: Venice (ルーター／集約サービス)
記録のある比較項目: 5/17項目に少なくとも1件の適用範囲付き記録
現行記録の情報源: 事業者の公表文書5件 · 画面上の実地観測0件

このパイロットに現行の範囲付き記録がない項目：

登録に要る識別子
登録時の電話番号
登録時のメール
最低年齢
利用中・復旧時の身元／電話番号確認
決済・請求時の身元情報
入力内容の学習利用
会話の人手による確認
削除と識別子の再利用
任意で使えるプライバシー設定
データ管理者が示す法域
第三者によるサイト分析

アカウント要否

任意

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 収集しない
ひも付く先: セッションのみ
受領者: Venice
適用範囲: 地域: 全地域（既定） · プラン: デモ · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-14

The Venice.ai Website features a chat demonstration interface which is accessible to anyone without an account.

— アーカイブ版 · 取得日 2026-07-14

ログイン方式（SSO／ウォレット）

メール、ソーシャルログイン、Web3ウォレットのいずれか

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 必須収集
アカウント確認方式: 経路により異なる
発動条件: アカウントを作成する場合（デモは不要）
ひも付く先: アカウント
受領者: Venice
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料 · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-14

registering for an Account using a social login feature such as Google, Facebook, Apple, Discord, Coinbase, or a Web3 wallet

— アーカイブ版 · 取得日 2026-07-14

You must provide an email address to register for an account (“Account”) (either Free or Pro, as further described below) to use our Services.

— アーカイブ版 · 取得日 2026-07-14

継続利用

入力内容の接続先事業者への転送

保存しない条件を下流事業者に課す

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
ひも付く先: 下流のモデル事業者
受領者: モデル提供事業者
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料/デモ · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-14

We operate a zero data retention policy with our model providers in which our model providers are prohibited from storing, retaining, or using any of your Prompts or Outputs beyond the time strictly necessary to process and return a response.

— アーカイブ版 · 取得日 2026-07-14

収集されるメタデータ（IPなど）

収集される

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 自動収集
ひも付く先: セッションのみ · 端末
受領者: Venice
適用範囲: 地域: 全地域（既定） · プラン: デモ · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-14

Without an account, we collect basic metadata on you, such as time zone, browser type, and IP address.

— アーカイブ版 · 取得日 2026-07-14

保持期間

保持しない

主張の情報源: 事業者の記載
アーカイブの確認: アーカイブ済み・本文確認済み
実際の運用: 未検証：公表ポリシーだけではシステムの挙動を証明できません
主張の確認日: 2026-07-14 · 月次再確認は運用目標。本番相当の処理を連続2サイクル正常完了するまではSLAではありません
情報源の矛盾: 現行の証拠に記録済みの矛盾はありません
収集: 収集しない
ひも付く先: セッションのみ
受領者: Venice
適用範囲: 地域: 全地域（既定） · プラン: 無料/有料/デモ · 画面・経路: Web
KYC Driftへの初回収録: 2026-07-14

We do not collect or retain your Prompts or Outputs (other than as described in the Prompts and Outputs section above).

— アーカイブ版 · 取得日 2026-07-14

根拠資料

証拠の役割	情報源	アーカイブ／結果	取得日／観測日	記録日／本文確認日	sha256
最初の裏付けとなる取得記録・最新再確認	https://venice.ai/legal/tos	アーカイブ版	2026-07-14	2026-07-14	`a23fcfd349c1e26ce53bd2f017eb6f8fcbb6f65bbbd5d88ffcd5d54426df7e98`
最初の裏付けとなる取得記録・最新再確認	https://venice.ai/legal/privacy-policy	アーカイブ版	2026-07-14	2026-07-14	`b4ee97bcc08f31b872ef5ac40dec1eef70f83cc34ea12827728f3771f8a33b90`

ハル・フィニー：PGP、RPOW、初期Bitcoin（2026年）

Tue, 18 Aug 2026 00:00:00 +0000

資金について：CypherpunkGuideは監視型広告を載せない。広告ネットワーク、トラッキングピクセル、スポンサー記事は使わない。運営は透明な収益源による。現在は読者からの寄付、将来は購読と編集方針に合うアフィリエイトを想定している。私たちが向き合う相手は広告主ではなく、読者だ。

ハル・フィニーを語る文章は、たいてい二つの話へ縮む。「最初のBitcoin取引を受け取った人物」と、「Satoshi Nakamotoだったのではないか」。前者は取引の種類を言わなければ不正確で、後者は推測である。どちらも、資料でたどれる仕事そのものを見えにくくする。

PGP（Pretty Good Privacy）はメッセージを暗号化するソフトウェアである。匿名リメーラーは、送信者や宛先のつながりを見えにくくする転送サービスだ。RPOW（Reusable Proofs of Work）は、計算作業で裏づけたトークンをサーバー経由で移転できるようにしたフィニーの実験だった。

私は、1992年から2013年までの重要な一次記録12件を照合した。PGP 2.0の説明書、Cypherpunksメーリングリストへの投稿、RPOWの技術文書、公開前のBitcoin論評、「Running bitcoin」という投稿、ブロック170、そして本人の回想である。それぞれについて「何を立証するか」と「何までは立証しないか」を分けた。出典対応表は再現可能な検証スクリプトで形式を確認できる。末尾の参考文献には、表の外にある背景資料4件も加えた。

これは偉人伝でも、Satoshi探しでもない。抽象的なプライバシーの問題を動く仕組みへ変え、そのたびに残る信頼を確かめた一人のプログラマーを、資料の強さに合わせて読む試みである。

Bitcoin以前、ハル・フィニーは何を作ったのか
#

Bitcoin以前のフィニーは、PGP 2.0の実装に加わり、匿名リメーラーを運用し、署名付きのハードウェア証明を使う中央サーバー型のRPOWを作った。2008〜2009年には、Bitcoinの初期レビューとテストに参加した。ただし、この連続した経歴は、各技術が直接受け継がれたことや単独発明を立証しない。

Proof of Work（作業証明）とは、計算には費用がかかる一方、結果は安く検証できる仕組みである。Remote Attestation（遠隔証明）は、サーバーがどのソフトウェアを実行しているかを、署名付きの報告で示す仕組みだ。フィニーの経歴を貫くのは、暗号通信、匿名通信、私的な支払い、再利用できる作業証明、分散された取引履歴へと問題を実装し続けた事実である。

ただし表現の境界は守らなければならない。PGPを作ったのはPhilip Zimmermannであり、PGP 2.6.2 User’s Guideは、フィニーをPGP 2.0に貢献した複数のプログラマーの一人として記す。RPOWは専用サーバーとIBM製ハードウェアに依存し、Bitcoinのような分散合意には達していない。また、フィニー自身も「Satoshi以外で最初にBitcoinを動かした人物」だと断定しなかった。4年後の回想で使った言葉は「そうだったと思う（I think）」である。

資料が示すのは、信頼と検証の境界を何度も試した実装者だ。孤独な発明者という神話ではない。

証拠を4段階で読む——どの記録が、何を立証するのか
#

フィニーの足跡は、同時代の文書、運用設計、公開されたチェーンの記録、後年の本人証言を別々に扱うと鮮明になる。ある出来事が確認できても、後から結びつけられた人物名や因果まで同じ資料で確定するとは限らない。資料ごとの限界を残すことが、伝説と検証可能な歴史を分ける。強い結論ほど、どの記録を根拠にするかを明記しなければならない。

すべてのリンクを同じ強さと見なさず、証拠を4段階に分けた。

同時代の記録： 出来事の近くで作られた説明書、メーリングリスト投稿、リリース告知、公開発言。
運用文書： 仕組みの動き方と壊れ方を説明するソースコードやセキュリティ文書。
公開システムの記録： 誰でも読み直せるチェーンのデータ。ただし公開鍵は人名ではない。
本人による回想： 後からフィニー自身が記した説明。重要だが、当時の実行ログとは同一ではない。

記録	立証できること	立証できないこと
PGP 2.0の説明書	フィニーが貢献者として記載された	PGPを発明した、または一人で書いた
1992年のリメーラー投稿	早期の議論に参加し、実用的なプライバシー基盤を論じた	Cypherpunksを創設した、またはこの投稿時点で運用を始めた
RPOWの告知とコード	移転できる作業証明トークンの実験が稼働した	分散合意、またはBitcoinへの直接の影響
2008年のBitcoin返信	公開前の設計を検討していた	Bitcoinの共同著者だった
「Running bitcoin」	クライアントを動かしていると公に述べた	稼働ノードが正確に2台だったという全数記録
ブロック170	記録上最古の非コインベース取引で、出力が10 BTCと40 BTCだった	チェーンの情報だけで各出力の人間の所有者を特定すること
「Bitcoin and Me」	テスト送金と不具合報告についての本人証言	当時、ただ一人の最初の利用者だったという同時代の確証

通常の伝記は、この7行をひとつながりの伝説にしてしまう。一次記録は、むしろ証拠の種類と、その間に残る不確実さを見せている。

PGP 2.0——発明者ではなく、実装に加わった一人
#

フィニーはPGP 2.0に貢献したプログラマーの一人で、のちにPGP Corporationでも働いた。PGPの作者はPhilip Zimmermannであり、残る記録からフィニーを唯一の作者と呼ぶことはできない。手引きと本人の記録が示すのは共同実装であり、コード量の正確な分担でも発明者の交代でもない。

「PGPを作った人物」と短く書けば、Zimmermannだけでなく、共同実装の記録も消える。

フィニーは保存された自分のホームページで、Zimmermannと直接働いた初期PGP 2.0プログラマーの一人だと説明した。同時代の説明書は、さらに広いチームを挙げている。誰がコードの何パーセントを書いたかは資料にない。資料にない割合を作るべきではない。

ここには、その後の仕事にも通じる姿勢がすでにある。大胆な暗号技術の構想へ実装側から加わることだ。PGPは公開鍵暗号を、一般の利用者が動かせるソフトウェアへ変えた。後年のPGP Web of Trustへの誤解についての投稿は、暗号ソフトの公開後にも仕事が残ることを示す。利用者が信頼モデルを過大評価していないかを正す仕事である。

プライバシーツールを決めるのは暗号方式だけではない。鍵の配り方、画面設計、故障時の振る舞い、利用者が誤って期待する保証も含まれる。Cypherpunk Manifesto入門で扱った「約束と仕組みの差」であり、フィニーが取り組み続けたのは、まさにこの差だった。

リメーラーはメタデータもプライバシー問題にした
#

フィニーのリメーラー論は、隠す対象を本文から通信関係へ広げた。暗号化はメッセージの内容を守れる。リメーラーが見えにくくしようとしたのは、誰が誰と通信しているかというつながりである。1992年の投稿はこの考えを立証するが、その時点での運用開始日や「世界初」を単独で確定する資料ではない。後年の本人証言とは分けて読む必要がある。

1992年11月のWhy Remailers Iで、フィニーは匿名の私的通信を、のちの資格証明や取引を支える土台と位置づけた。1993年のProtecting Privacy with Electronic Cashでは、全体を公開鍵暗号、匿名メッセージ、私的な電子マネーという3層に整理している。

「プライバシーの先駆者」と呼ぶだけでは、この分解が消える。守る対象と、まだ残る問題を並べると意味が見える。

層	守ろうとした情報	残った問題
PGP	メッセージの内容	送信者と受信者の関係、利用端末や接続先の情報
リメーラー	通信経路と身元の結びつき	信頼性、悪用への耐性、通信量の分析、端末の侵害
電子マネー	支払い関係と取引履歴	二重使用、発行、受け入れ先、制度からの圧力

フィニーは後年、自分が暗号技術に基づく最初の匿名リメーラーを動かしたと書いた。これは本人による回想であり、初期サービスすべての全数調査ではない。「最初」かどうかに結論は左右されない。1992年に彼は運用できる基盤を論じ、その後、自分がリメーラーを運営したと記している。

RPOWは動いた。しかし中央にサーバーがあった
#

RPOWは、IBM 4758セキュリティプロセッサ上の専用サーバーを通じて、作業証明トークンを再利用できるようにした。公開コードと遠隔証明は運営者を信じる範囲を狭めたが、サーバーを消したわけでも、二重使用を防ぐ役割を分散したわけでもない。動いた実験であることと、Bitcoinの直接の前身であることは別の主張だ。

フィニーは1993年に二重使用の問題を説明していた。2004年8月のRPOW告知は、動作する実験を紹介する。利用者がHashcashという、迷惑行為を抑えるための計算スタンプをサーバーへ送り、サーバーが公開鍵暗号で署名したトークンを返す。受取人はそのトークンを新しいものと交換できた。同じトークンは一度しか受け入れないため、計算作業を移転できる。

二重使用を拒む境界はサーバーだった。署名付きで実行中ソフトウェアを確かめる遠隔証明は、改変サーバーの発見を狙った。IBMカードは、機械の所有者から署名鍵を守る設計だった。RPOW Security Modelは、所有者、運用者、開発者を攻撃者として想定し、遠隔証明されたソフトウェアだけを信頼する。信頼を減らす設計ではある。信頼がゼロになったわけではない。

問い	RPOW	Bitcoin v0.1
二重使用を拒む主体	状態を保持する専用サーバー	共有された作業証明の履歴を検証するノード
利用者が検証できるもの	公開コードとIBM 4758の遠隔証明	公開ルール、取引、積み上がったチェーンの作業量
中央の依存先	サーバーの稼働、ハードウェア、証明の連鎖	発行者や中央サーバーはないが、ネットワークとソフトウェアのリスクは残る
初期に明記された故障	ベータサーバーの再読み込みでトークンが無効になり得る	アルファ版は再起動が必要になる可能性があり、合意形成も実験段階
作業証明の役割	計算コストのある結果を作り、署名付きトークンと交換する	コインを発行しつつ、取引履歴を順序づけて守る

RPOWを「Bitcoin以前のBitcoin」と呼ぶ解説は多い。しかしBitcoin白書はフィニーもRPOWも引用しておらず、現存資料は直接の継承を立証しない。RPOWはBitcoin以前の作業証明の系譜に入る。BitcoinがRPOWから作られた、とまで言えば資料を越える。

フィニーは「コードを書けば政治は消える」と考えていなかった
#

フィニーは「コードを書き、政治は無視すればよい」という立場を退けた。1994年、技術によるプライバシー保護にも、政治的な勝利、人々への説得、コードが使われる法制度が必要だと論じている。暗号が信頼を減らせても、利用を規制する法律、侵害される端末、閉ざされる入口まで消せるわけではない。この制約も設計の一部である。

フィニーを実装者として描く伝記が最も落としやすいのが、この点である。Politics vs Technologyで、技術的な前進は後戻りせず抗議は二次的だという主張に、フィニーは正面から答えた。

「近道などない。技術の中へ引きこもるのは、頭から毛布をかぶるようなものだ」——ハル・フィニー、1994年

彼が挙げたのは暗号の輸出規制、PGPをめぐる捜査、暗号鍵の提出を強制されないための法的保護だった。コードが無力だという話ではない。技術は、制度、法律、社会の合意の中で実際に使われるという指摘である。

現代のプライバシーにも、そのまま当てはまる。プロトコルは信頼する相手を減らせる。しかし法律は利用を犯罪化でき、端末は情報を漏らし、プラットフォームは入口を閉ざせる。開かれたWebの囲い込みにも同じ緊張がある。構造と政治は互いを制約する。

公開前から、フィニーはBitcoinがどこで壊れるかを問うていた
#

2008年11月、フィニーはBitcoinを有望と評価しつつ、取引の伝播、競合チェーンへの対応、二重使用をどう検出するかについて質問した。2009年1月には、公開の論評から、リリースされたクライアントのテストへ移った。投稿は早期利用を裏づけるが、当時の全ノードを数えた記録ではない。後年の「そうだったと思う」という留保も消してはならない。

Bitcoin論文への2008年11月7日の返信は、発想を評価した直後に、起こり得る失敗の分析へ入る。仕組みを理解し、信頼の境界を探し、それから動かす。以前の仕事と同じ姿勢である。

Satoshiが2009年1月にBitcoin v0.1を告知したとき、ソフトウェアはアルファ版で実験的だと明記された。フィニーの公開返信は、試すのを楽しみにしていると述べる。1月11日には、わずか二語の投稿で実行を公にした——「Running bitcoin」である。

4年後、フィニーは「Satoshi以外で最初にBitcoinを動かしたのは自分だったと思う」、70番台のブロックを採掘し、Satoshiが直した不具合を報告した、と書いた。当時クライアントを短時間でも起動した全員の公開名簿は存在しないため、ここでは「思う」を残す。「Satoshi以外でBitcoinを動かしたことが確認できる最初期の一人」は言える。「確実に2番目のノード」は言えない。

この回想は、筋萎縮性側索硬化症（ALS）により身体の大半を動かせなくなったフィニーが、視線入力装置を使って書いた。本人はプログラミングを続けたとも記している。病気は記録がどう作られたかを理解する背景であって、技術的主張の信頼性を高める証拠ではない。障害を感動の道具へ変えるべきでもない。

ブロック170が示すのは取引であり、人名ではない
#

ブロック170には、記録上最古の非コインベース取引がある。50 BTCの入力は10 BTCと40 BTCの出力になった。チェーンから確認できるのは金額と時刻であり、10 BTCがSatoshiからフィニーへのテスト送金だったとする根拠は、フィニーの後年の証言である。チェーン上の事実と人間への帰属は、別々の証拠に基づく。

取引記録は誰でも読める。txidはf4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16、ブロック高は170、時刻は2009年1月12日03:30:25 UTC、出力は10 BTCと40 BTCである。それ以前のブロックにも、採掘報酬を生むコインベース取引はある。そのため、条件を付けず「Bitcoin史上最初の取引」と呼ぶのは技術的に誤りだ。

チェーンは、10 BTCの公開鍵に「Hal Finney」とは書かない。受取人をフィニーと特定する根拠は、2013年のBitcoin and Meにある「Satoshiがテストとして10コインを送った」という本人の説明である。歴史上の主張は、二つへ分ける必要がある。

チェーン上の事実： ブロック170には記録上最古の非コインベース取引と、10 BTCの出力がある。
チェーン外の帰属： フィニーは自分を受取人、送信者をSatoshiだと説明した。

この区別は、現代のチェーン分析にも必要である。取引グラフが示すのは取引とスクリプトだ。人名を付けるには外部の証拠が必要で、その判断は誤ることもある。Bitcoinのオンチェーン・プライバシーでは、複数のアドレスを同じ所有者のものと推定してまとめる分析を、確定事実ではなく推測として扱う理由を詳しく説明している。

フィニーという「橋」が意味すること、意味しないこと
#

フィニーの経歴は、PGP 2.0、リメーラー、電子マネーの分析、RPOW、Bitcoin初期の公開テストにまたがる。この意味で「橋」は経歴の説明として使える。ただし、単独の発明、技術の直接継承、Satoshiの身元を示す言葉ではない。資料でつながるのは、主張を動く仕組みに変え、残る信頼を明示する方法である。

共通する方法は四つある。

プライバシーの主張を仕組みにする。 PGPは内容を守り、リメーラーは通信関係の情報に取り組んだ。
残る信頼を名指しする。 RPOWはコードを公開し、遠隔証明でサーバー上のソフトウェアを検証できるようにしたが、サーバー自体は残った。
神話にする前に試す。 フィニーはBitcoinの壊れ方を尋ね、アルファ版を動かし、不具合を報告し、自分の記憶も断定しなかった。
政治を脅威モデルから外さない。 暗号を使えば法律や制度の権力が消える、とは考えなかった。

この文脈では、Satoshiの正体探しは話をそらす。今回照合した一次資料は、フィニーがBitcoinを発明したと立証しない。Bitcoin白書もフィニーやRPOWを引用していない。実在する仕事を、答えの出ない身元当てゲームに置き換える必要はない。

むしろ残るのは、実践の基準である。主張を試せる最小の仕組みを動かす。他者が信頼の境界を調べられるだけの情報を公開する。記録で決着しない点は、決着しないと書く。この方法なら、PGPからRPOW、Bitcoin最初期のテストまでを、英雄物語より正確につなげられる。

結論
#

ハル・フィニーはcypherpunkの実装とBitcoinをつなぐが、発明の直系を証明する人物ではない。PGP 2.0の実装に加わり、リメーラーを運用し、中央サーバーに依存するRPOWを作り、Bitcoinをテストし、記録で確認できる最初の個人間テスト送金を受け取った。その功績は、証拠が示す範囲を越えて大きく見せる必要がない。

証拠ごとの強さの違いは消してはならない。PGPには複数の貢献者がいた。RPOWにはサーバーがあった。ブロック170には公開された出力があるが、人名はない。Bitcoin and Meは4年後に書かれた本人証言である。何が分かるかは、その限界も示してこそ正確になる。

要点

PGPとリメーラー： フィニーはPGP 2.0に貢献したプログラマーであり、発明者ではない。暗号化された本文とは別に、通信関係の情報も守る対象と考えた。
RPOW： 遠隔証明で検証できるIBM 4758サーバーを通して作業証明を移転可能にした。動くソフトウェアだったが、分散型Bitcoinではない。
政治： プライバシー擁護者はコードだけ書いて法律や人々への説得を無視すればよい、という考えを明確に退けた。
Bitcoin： 初期の論評者、利用者だった。「2番目のノード」は、全数記録でなく本人の条件付き回想である。
ブロック170： チェーンは記録上最古の非コインベース取引を示す。誰が送受信したかは、後年の本人証言が補う。

よくある質問
#

ハル・フィニーをめぐる主張の強さは、資料の種類で変わる。同時代の投稿は公開活動を、チェーンは人名のない支出を立証し、後年の本人証言は不確実さを含む人間への帰属を補う。以下の回答でも「最初」「発明者」「前身」といった強い言葉を、各資料が支えられる範囲まで狭めている。断定の強さを資料より上げないためである。

ハル・フィニーはSatoshi以外で最初にBitcoinを動かした人物ですか？
#

可能性はありますが、ただ一人だったと証明する資料はありません。フィニーは2013年に「Satoshi以外で最初にBitcoinを動かしたのは自分だったと思う」と書きました。「Running bitcoin」という公開投稿は早期利用を裏づけますが、全利用者の記録ではありません。「Satoshi以外でBitcoinを動かしたことが確認できる最初期の一人」が、資料に合う表現です。

なぜブロック170が「最初のBitcoin取引」と呼ばれるのですか？
#

採掘済みの50 BTCを10 BTCと40 BTCの出力へ使った、記録上最古の非コインベース取引だからです。それ以前のブロックには、採掘報酬を作るコインベース取引があります。10 BTCがフィニーへのテスト送金だったという帰属は、チェーン上の人名ではなく、本人の後年の証言によります。

ハル・フィニーはBitcoinを発明した、またはSatoshi Nakamotoだったのですか？
#

今回確認した一次資料は、どちらも立証しません。フィニーが設計を論評し、公開ソフトウェアを動かし、不具合を報告し、Satoshiと呼ぶ人物からテスト送金を受けたことは示します。これは協力とテストの証拠であり、同一人物だったことや共同著者だったことの証明ではありません。

RPOWはBitcoinの初期版ですか？
#

Bitcoin以前に動いた作業証明トークンの実験ですが、構造は違います。RPOWは専用サーバーとIBM 4758の遠隔証明で、不正発行と二重使用を防ぎました。BitcoinはP2Pの作業証明チェーンを使い、発行者や中央サーバーを避けました。Bitcoin白書にRPOWからの直接の影響は記録されていません。

フィニーはPGP 2.0に何を貢献したのですか？
#

同時代の説明書と本人の記録は、Philip ZimmermannとPGP 2.0に取り組んだ複数のプログラマーの一人としてフィニーを挙げています。残る資料からコードの正確な割合は出せず、フィニーをPGPの発明者や唯一の作者とも呼べません。

参考文献
#

12件の出典対応表に、背景を補う4件の文書を加えた。各URLには、推測した時刻でなくInternet ArchiveのCDX記録から選んだ、時刻まで一致するWayback再生URLを併記している。本文の主張はこの16件へ戻って確認でき、出典対応表では各資料が立証しない点も読める。一次資料と限界を対で確かめられる構成だ。

Cora Aegis

Cora Aegisは、CypherpunkGuideでプライバシーを最優先にしたOPSECガイドを書いている。本稿では1992〜2013年の一次記録12件を照合し、直接の証拠と後年の帰属を分け、出典対応表と再現可能な検証スクリプトを作成した。

Cora Aegisについて ->

ナンバープレート読取カメラ 2026——本当に効く守りはどれか

Fri, 10 Jul 2026 00:00:00 +0000

ナンバープレートは、国家があなたに公然と掲げるよう義務づける、ただ一つの識別子だ。車にボルトで留め、あなたが通るあらゆる道の、あらゆるカメラの前を、それを掲げたまま走らされる。こうしたプレートを撮影する自動カメラは、長らく警察の特殊な道具にすぎなかった——自動ナンバープレート読取(ALPR)。道路脇やパトカーに取り付けられ、通り過ぎるすべてのプレートを撮影し、日時と場所を刻んで、検索できるデータベースに保存するカメラだ。それがいまや、無差別の網になった——疑いのある車だけでなく、通りかかった車を残らず捕らえる網だ。最も急成長している事業者 Flock Safety は、2026年にカメラ10万台を突破した。モトローラの旧来の Vigilant ネットワークや、数千に及ぶ地域のシステムが、その上に折り重なる。結果として生まれたのは、こういう国だ——読取機が置かれた場所ならどこでも、あなたの車の動きが既定で記録され、時刻を刻まれ、保持される。しかも、その大半について具体的に定めた法律を、いまなお持たない州がほとんどだ。

この悪用は、絵空事でもなければ、まれなことでもない。警官が、かつて交際していた相手を追い回すためにこれらのシステムを使い、逮捕され続けている。ペンシルベニア州のある警官は、別居中の妻を250回以上も追跡した。カンザス州のある警察署長は、彼を暴いた署の監査によれば、元交際相手とその新しいパートナーを、228回もカメラで照会していた。ミルウォーキーのある警官は、交際相手とその元恋人に対して、179回の検索を記録に残した。Flock 自身の最高法務責任者は、悪用について問われ、監視業界の専門メディア IPVM にこう答えている——このシステムを「元交際相手がどこにいるかを突き止める」ために使うのは「実のところ、最もよくあること」だ、と。無差別の網を売る当の会社が、自社製品の最もありふれた悪用の姿を、正確に知っているのだ。

では、自分の持ち物でもないカメラ、自分の管理下にもない道路に対して、一人の人間に何ができるだろうか。世に出回る答えのほとんどは、無意味を通り越して有害だ。プレートカバー、反射スプレー、プレートを傾ける金具(チルトブラケット)は、この国の多くの地域で違法であり、しかも独立した検証によれば、最新の読取機にはほぼ何の効果もない。私たちは、十数件を超えるこうした事件の裏にある宣誓供述書、起訴状、検察の発表を集め、その一つひとつを反証のための検索と突き合わせた。その結果、広く引用されていた「ALPR」の逸話を二つ、外している——一つは実は秘密の GPS 追跡装置による事件、もう一つはカメラが罪のない運転者のプレートを誤読した事件で、どちらもプレート読取機の悪用ではなかった。確かめられた記録が示すのは、こういうことだ。本当にあなたのリスクを下げる守りは、ハウツー記事が真っ先に並べるものと、ほぼ正反対なのだ。

下の表は、私たち自身がまとめたものだ——事業者の宣伝文句でもなければ、どこか一つの支援団体の集計の焼き直しでもない。一次の裁判記録に結びつけられた事件だけを、報道が飛ばすパターンに目を凝らして読み解いた。

警官／所在地	記録が示すこと	処分・法的な結果
McSherry——ペンシルベニア州フレイザー郡区	警察のプレート読取機材で、別居中の妻を250回以上追跡	有罪を認め、実刑判決(2021年)
Heiar——カンザス州キーチ	Flock で別居中の妻を追跡し、その居場所をショートメッセージで本人に送りつけた	コンピュータ犯罪とストーキングで有罪を認める(2023年)
Nygaard——カンザス州セジウィック	元交際相手とその新しいパートナーを、虚偽の口実で Flock 検索228回	辞職。警官資格を剥奪(2023年)
Josett——カリフォルニア州コスタメサ	妻、愛人、恋のライバルを、法執行機関のデータベースで照会	3件の罪で有罪を認める(2026年)
Ayala——ウィスコンシン州ミルウォーキー	交際相手とその元恋人を Flock 検索179回。被害者は恐怖を訴えた	有罪を認め、辞職(2026年)

これらを横に並べて読むと、取るべき対策の順位は、おのずと入れ替わる。この女性たちの誰一人として、巧妙な偽装が破られて居場所を突き止められたのではない。突き止められたのは、見張っていた側が、バッジと、データベースと、そして誰もログを見ていないという状況を持っていたからだ。これは、「どうやって自分のプレートを隠すか」が解こうとしている問題とは、別物なのだ。

ALPR ネットワークとは、本当は何なのか
#

ALPR ネットワークとは、カメラのことではない。あなたの車がどこにいたかを、検索できる履歴のことだ。 一台一台は、受け身のセンサーだ。誰かに疑いがあるかどうかとは関わりなく、視界に入るプレートをすべて読み取り、一行分のデータを書き込む——プレート番号、日時、GPS の座標、多くの場合は車とその周囲の写真まで。それが、数秒で照会できるデータベースに収まる。これを十分な数つなぎ合わせれば、たった一度の照会が移動の地図を返す。あなたが走った経路、家を出て戻った時刻、そして車を停めた教会、診療所、労働組合の会館、恋人の家までが、そこに描き出される。電子フロンティア財団(EFF)の技術解説は、その核心をはっきり言い切っている——ALPR は捜査対象の人だけでなく、あらゆる人のデータを集める、と。

これを、あなたの車に気づいた一人の巡回警官と分けるものが、二つある。一つ目は保持だ。読み取ったデータが残るので、監視はさかのぼって働く。今日かけた一度の検索が、あなたが先月どこにいたかを組み立て直せるのだ。保持期間の上限は——そもそも定めがある場合でも——ニューハンプシャー州の3分から、ワシントン州の21日、それ以外の州の60日かそれ以上まで幅があり、大半の州には上限そのものがない。二つ目はネットワーク化だ。ある町のカメラを、別の州の当局がふつうに検索できてしまう。2025年、EFF と ACLU(米自由人権協会)は、サンフランシスコ市警が州外と共有する形で160万件を超える検索を行っていた事実を記録した。その一部は入管法の執行に結びついており、市警自身の規定でも認められていない検索だった。米議会の調査機関は、そこから生じた法の空白を一覧にまとめている。かいつまんで言えば、技術が法を、およそ十年ぶんも追い越してしまった、ということだ。

その空白が最も広く口を開けているのが、保持だ。全米でこれに上限を設けている地域が、いかに少ないか——それを見ておく価値がある。

州	ALPR データの保持期間の上限
ニューハンプシャー州	フラグが付かなければ約3分——全米で最も厳しい
ワシントン州	21日(2026年 Driver Privacy Act)
カリフォルニア州	60日(SB 34)
大半の州	ALPR 固有の上限なし——無期限に保持

悪用は例外ではなく、パターンそのもの
#

ナンバープレート監視について最も大切な事実は、これだ。記録に残る最もありふれた悪用は、犯罪者の摘発ではない——警官が女性を追跡することなのだ。これは活動家の見立てではない。ほかならぬ事業者自身の言葉だ。裁判記録を並べてみると、州をまたいで同じ物語が繰り返される。現職または元職の警官が、公共の安全のために作られたシステムを使って、親密なパートナーや、元交際相手や、一方的に執着した女性を追いかけるのだ。

検察によれば、Ayala は、かつて交際していた女性とその元パートナーに対して、Flock 検索を179回行った。この悪用が明るみに出たのは、被害者が不審に思い、誰が自分のプレートを検索していたのかを調べるよう署に求めたからにほかならない。そして続いて行われた内部調査が、二人目のミルウォーキーの刑事を浮かび上がらせた——Ayala 自身の事件を担当していた捜査員の一人であり、別の女性に同じことをした容疑をかけられている。監査ログは、どちらの男も捕まえられなかった。捕まえたのは、おびえた一人の被害者だったのだ。

— 米ウィスコンシン州ミルウォーキー——警官 Josue Ayala、2026年に有罪答弁

この細部——ログが捕まえたのではない、被害者が捕まえたのだ——は、ほとんどどこでも繰り返される。ジョージア州では、いくつもの部局が Flock の監査ツールを導入し、実際に目を通して初めて、悪用が明るみに出た——2025年11月のブラセルトン、続いて2026年7月までにコフィー郡、チェロキー郡、オールバニー。誰かがようやく記録を見直したとたん、8か月で4つの機関だ。これらのすべてが元交際相手の追跡だったわけではない。共通しているのは、それらを捕まえたのがシステムそのものではなく、監査だったという点だ。ここから学ぶべきは、「監査ログがあれば安全だ」ではない。まるで逆だ——誰も読まないログは、犯罪の記録であって、犯罪への守りではないのだ。「きちんと監査されているから」このシステムは安全だ、と誰かが言うなら、それは電池を抜いた煙探知機のことを語っているのだ。

全体の規模は、本当のところ定かではない。数え上げるそばから、件数が増え続けているからだ。Institute for Justice の Plate Privacy Project は、こうした警官によるストーキング事件を何年も記録してきたが、より多くの部局が監査を行い、より多くの被害者が声を上げるにつれ、その数は増える一方だった。私たち自身が数えた下限——有罪答弁、有罪判決、または現に係属中の刑事訴追に結びつけられた警官——でも、7州にまたがる十数名にのぼる。しかもこれは、あくまで下限にすぎない。2026年を通じて、新しい事件がほぼ毎月のように明るみに出た。具体的な数字はどれも、読むころには古くなっているスナップショットにすぎない。変わらないのは、パターンのほうだ。

信頼性のために、逆向きの注意も一つ。世間を騒がせた「プレート読取機」の話が、どれも本当にそうだとは限らない。広く共有されたカリフォルニアのあるストーキング事件は、ALPR ではなく、ひそかに仕掛けられた GPS 追跡装置によるものだった。もう一つ、拡散した「Flock」の一件は、システムが罪のない女性のプレートを誤読し、彼女があやうく濡れ衣を着せられかけた、という話だ——これも本物の害だが、種類の違う害だ。ここで正確さにこだわるのは、細かいことにうるさいからではない。守る相手の仕組みを取り違えれば、見当違いのところに労力を注ぐことになる——プレートカバーが役に立つと約束するとき、監視があなたに売りつけるのと、同じ失敗だ。そもそもバラバラの記録が、どうやって一つの人物像へと束ねられるのか——その仕組みはAI 規模での非匿名化の解説で扱っている。

ジェンダーという層——見張る者が、彼女の眠る場所まで知っているとき
#

ナンバープレートの網は、誰もが同じように経験するものではない。見つけられることの危険は、人によって同じ大きさではないからだ。 加害者のもとを去ろうとしている女性、敵意ある州で中絶などの生殖医療を求める人、政府に疎まれる活動家——こうした人にとって、プレートを一つの居場所に変えるシステムは、抽象的なプライバシーの心配ごとではない。それは、その人の脅威モデルが打ち消そうとしている、まさにその能力そのものだ。そして記録が「追跡されている」と示すのは、ほかならぬこうした人々なのだ。

生殖医療をめぐる事例は、いまや詳しく記録されている。2025年、EFF が明らかにしたところによれば、テキサス州のある保安官が、自分で中絶を行った女性を捜し出すために、「行方不明者」という口実を使って、全米8万3000台を超えるカメラを検索した。ワシントン州の応えは、その害をそのまま法律に書き込むことだった——同州の2026年 Driver Privacy Act(SB 6002)は、ALPR のデータを入管法の執行に使うこと、そして生殖医療を求める人の追跡に使うことを禁じている。プレートカメラを中絶患者や移民の追跡に使うのを名指しで禁止しなければならないとき、立法府は、そのカメラがすでに何に使われていたかを、あなたに告げているのだ。

だからこそ、親密なパートナーをめぐる事件は、下世話な余談ではなく、この物語の中心にあるのだ。元交際相手を追跡した警官たちは、知る人ぞ知る欠陥を突いたのでも、特別なコードを書いたのでもない。使ったのはこのシステムのありふれた検索機能で、技術的な抜け穴などいらなかった——その事業者自身が最も多いと認める種類の濫用を、そのまま行っただけだ。生き延びようとする当事者にとって、意味を持つ事実は、残酷なほど単純だ。あなたの加害者がバッジを持っているか、バッジを持つ友人がいるなら、その網はもう、あなたの新しい通勤経路を知っている。 どんなプレートカバーも、それを変えない。それを変えるのは、車とあなたを結ぶ線を断ち切ること、そして誰が検索してきたのかを突き止められる法の仕組みを使うことだ——どちらもこのあとの守りの節で扱うが、どちらも地味だ。だからこそ、これらをあなたに売りつける者は、ほとんどいないのだ。

本当に効くもの——効き目で並べた守りの一覧
#

個人でできる守りを正直に並べ替えると、たいていの指南書が載せる順序と、ほぼ逆になる。 一番手として売り込まれる手——カメラを「遮る」物理的な小道具——は、最も効果が薄く、そして最も違法になりやすいものだ。本当にあなたのリスクを動かす手は、合法で、構造にかかわり、みなで取り組むものだ。しかも、アフィリエイト目当てのまとめ記事が飛ばすくらいに、地味だ。証拠が支える順序を、効かないものから効くものへと並べる。

守り	効くか？	合法か？	向いている人
プレートカバー／反射スプレー／赤外線(IR)フィルム	いいえ、ほぼ無効——独立した検証で、最新の読取機にはほぼ効果なし	違法(カリフォルニア・ニューヨーク・フロリダなど多くの州。カリフォルニアでは付加金を含め違反1件あたり約2,000ドル)	誰にも向かない——避けるべき
経路や時間を変える	いいえ、無効——24時間動く受け身の網は、どこへ行っても記録する	合法	気休めだけ。本当の対策ではない
コミュニティのカメラ地図(DeFlock)	限定的——設置の薄い地域で、存在を知り経路を考える助けになる程度	合法	自分の露出を把握する、地域で動く
法的なデータの権利(公文書開示請求とデータ削除請求)	部分的に有効——誰があなたを検索したかを知り、削除を求められる。ただし事業者はかわそうとする	合法	被害当事者、狙われている疑いのある人
構造を変える：車を自分の名義に結びつけない(カーシェア、レンタル)	効果は高い——自分のものでないプレートは、プレートに基づく追跡を無力にする	合法	リスクの高い移動、機微な行き先
政治で動かす：自治体の契約と州法	効果は最も高い——カメラそのものを外す、あるいは全員のために利用を制限する	合法	すべての人。長続きする唯一の解

一番下から見ていこう。効き目が最も大きいのは、そこだからだ。政治で動くことは、負けたときの慰めの賞品ではない。最も見返りの大きい守りだ。 現に、地域社会は本物の数で ALPR の契約を打ち切っている——2026年なかばまでに、連邦や州外への無許可のデータ共有を理由に、数十の都市が Flock を切った。その多くは、住民が監査の記録を手に議会へ足を運んだ後のことだ。ACLU の「Get the Flock Out(Flock を追い出せ)」のツールキットが存在するのは、まさにこれが規模を持てる介入だからだ。説得された一つの市議会は、どんな個人の小道具にもできないやり方で、その町のすべての運転者を守る——ただし、完全に永続するわけではない。あとから来た議会が、カメラのスイッチを入れ直すこともできる。実際、リッチモンドは2026年、一度止めたあとにそうした。だからこそ、契約の打ち切りは、勝ち取ったうえで守り続ける戦いなのだ。

次に、あなたの法的な権利だ。これは実在するが、過度な期待は禁物だ。カリフォルニア州をはじめ、増え続ける州では、警察の ALPR に関する規定や運用監査について、公文書開示請求を出せる。そして法律が認めていれば、あなた自身に関するデータの削除も求められる。落とし穴は——係争中の裁判で明らかになっているとおり——Flock が自らを単なる「サービス提供者」だと位置づけ、個人からの請求を市の側へ差し戻してしまうことだ。市が動くかどうかは、わからない。権利は使うべきだ。ただ、それがひとりでに執行されるとは思わないことだ。カリフォルニア州の司法長官は、違法なデータ共有をめぐって、少なくとも一つの市を提訴した。これは、執行がやって来るとすれば、それは個人が一人ずつ離脱を申し出ることからではなく、行政や裁判所からやって来がちだ、ということの表れだ。

個人が完全に握れる唯一の構造的な一手は、この一覧のなかで最も効果の高い個人の守りでもある——大事な移動については、車とあなたの身元とを結ぶ線を断ち切ることだ。カーシェアの車、レンタカー、自分の持ち物でない車で行けば、そのプレートは、あなた以外のどこかへとつながる。それで毎日の通勤を隠せるわけではない。けれど、機微な移動——診療所、シェルター、あの会合——にとっては、あなたを名指しするプレートと、そうでないプレートとの違いになる。これは、サイト全体の主権(Sovereignty)の柱を貫くのと同じ原理を、車に当てはめたものだ——行動だけでなく、インフラそのものを変える、という原理だ。

残るのは、誰もがそこから始め、そして最後に回すべき一行だ——物理的な難読化は効かないうえに、罰金を招きかねない。 RadarTest が反射式のプレート製品を独立に検証したところ、最新の読取機に対しては、測れるほどの効果は見つからなかった。この読取機は、赤外線と可視光の撮影を組み合わせ、露出を自動で調整するからだ。その一方で、プレートカバーやスプレーは、カリフォルニア、ニューヨーク、フロリダなどで、はっきりと違法だ。あなたは、何一つ得られないのと引き換えに、お金を払って法を犯すことになる。

個人の守りには、限界がある
#

この網は、受け身で、ネットワーク化され、さかのぼって働く。それに対して、個人の技術は、必要でありながら、それだけでは足りない。 これは、アフィリエイト目当ての指南書が、はっきりとは口にしない限界だ。そして、それを言葉にすることこそが、この記事の眼目だ。診療所へ行くのにレンタカーを借り、削除請求を出すことはできる。そうすべきだ。けれど一人では、10万台のカメラのつながりを解くことも、別の州があなたの市のデータへ持つアクセスを取り消すことも、先月の動きをすでに記録したシステムに、それを忘れさせることもできない。今朝あなたのプレートを撮影した読取機は、あなたが誰かなど気にもしなかった。そして、どれほど個人が知恵を絞っても、さかのぼってその記録をなかったことにはできないのだ。

これらの事件を、ひとまとまりとして読むと、まさにそう語りかけてくる。追跡された被害者は、OPSEC の間違いを犯したのではない。正規のアクセス権を持つ人間が、ただシステムをその人へ向けただけだ。こうした状況を実際に動かしたのは、小道具ではなかった——読まれた監査、報じた記者、契約を打ち切った議会、保持期間の上限を書いた立法府だ。これこそ、サイファーパンクがつねに名指ししてきた、本当に効く一手であり、個人の守りが制度の力とぶつかり、残りをみなの行動へと手渡す場所だ。最高裁も、長期にわたって集積される位置情報の追跡が、この網の運用者たちが避けたい憲法上の問いを突きつける、と示しはじめている。その圧力を築くのは、訴訟と立法であって、プレートを傾けることではない。これは、私たちが国家が義務づける身元の仕組みを論じたときに、反対の方向からたどり着いたのと同じ結論だ——長続きする解は、下流の、個人の道具箱のなかにではなく、上流の、ルールのなかにある。

「プライバシーとは、自分を世界に対してどこまで明かすかを、自分で選べる力である。」——Eric Hughes『A Cypherpunk’s Manifesto』、1993年

ナンバープレートは、その力の、ちょうど裏返しだ——同意しようがしまいが、すべてのカメラに向かって明かすことを強いられる識別子だ。できるところでは、一つひとつの移動を守れ。そのうえで、条件そのものを押し動かせ。ストーキングを自社製品の「最もありふれた」使い道と呼ぶ事業者が、善意から自ら保持期間に上限を設けることは、ないのだから。

結論——あなたのリスクに、どの守りが合うか
#

唯一の答えはない。正しい守りは、誰があなたにそのシステムを向けうるのか、そしてもし向けられたら、あなたがどれだけの代償を払うことになるのか——それによって、すべて決まるからだ。

追跡されるのが嫌な、ふつうの運転者なら： 小道具はまるごと飛ばし、その同じ労力を、規模を持てる唯一のことに注げ——地元警察の ALPR に関する規定を見せてもらう開示請求と、市議会への一通のメッセージだ。あなたが動かせる力は、技術ではなく政治にあり、しかもそれは、あなたの隣人まで守る。
虐待するパートナーのもとを去ろうとしているなら——とりわけ相手が法執行機関にアクセスできる場合は： その網はもう、あなたの日々の習慣を知っていると考えろ。そして機微な移動は、自分の名義で登録された車に乗らないことで守れ。並行して、あなたの州のデータアクセス権を使い、誰があなたのプレートを検索してきたのかを突き止めろ。記録に残る事件では、その請求こそが、警官を暴いたのだ。
活動家、ジャーナリスト、あるいは組織者なら： 自分の車を、居場所を知らせる発信機とみなし、それを前提に計画を立てろ——機微な会合にはカーシェアを使い、これを活動家へのドキシング(個人情報の暴露)対策の手引きにある、身元とインフラの規律と組み合わせろ。あなたの居場所を指し示す信号は、プレートだけではないからだ。
敵意ある州で、生殖医療や、移民に関わる機微なケアを求めているなら： 脅威は、記録されており、具体的だ。予約先へ自分の車で行くな。出かける前に、あなたの州の保持と共有のルールを知っておけ。そして、ワシントン州のような、こうした検索を真っ向から禁じる法律を、後押ししろ。

この四つすべてを貫いて、それ以前のあらゆる監視の失敗で成り立ってきたのと同じ真実が、ここでも成り立つ——網を、小道具で出し抜くことはできない。あなたにできるのは、大事な移動での露出を下げること、システムを明るみへ引き出す法的な権利を行使すること、そして——一人にできることの限界の先では——ほかの人たちと力を合わせて、カメラそのものを外させることだ。

要点

最もありふれた悪用はストーキングであり、それは事業者自身が認めている： Flock の最高法務責任者は、「元交際相手」の居場所を突き止めるためにシステムを使うことを、「最もよくある」悪用と呼んだ——7州にわたる十数名の警官によって裏づけられ、有罪答弁、有罪判決、または刑事訴追に結びついたパターンだ。
物理的な妨害具は、最悪の選択肢だ： プレートカバー、スプレー、赤外線(IR)フィルムは、独立した検証で最新の読取機にほぼ効果を示さず、しかもカリフォルニア、ニューヨーク、フロリダなどで違法だ。これらの州では、違反1件が約2,000ドルに達する。
監査ログはあなたを守らない——読まれたログが守るのだ： 記録に残る事件では、悪用を捕まえたのは、不審に思った被害者や同僚であって、システムではなかった。誰も読まないログは、証拠であって、守りではない。
個人にできる効く一手は、構造にある： 機微な移動では、自分の名義で登録されていない車が、どんなアクセサリーにもできないやり方で、プレートに基づく追跡を無力にする。
長続きする解は、政治にある： 2026年なかばまでに数十の都市が ALPR の契約を打ち切り、ワシントン州のような州は、保持期間を21日に制限し、生殖医療や移民に関わる検索を禁じた——どんな個人の小道具もかなわない効き目だ。

よくある質問
#

ナンバープレート読取カメラから、どう身を守ればいいですか？
#

小道具では守れません。プレートカバー、反射スプレー、プレートを傾ける金具は、多くの州で違法なうえ、最新の読取機にはほぼ何の効果もありません。効き目の大きい順に、本当に効く守りは三つです。政治で動くこと(市に ALPR 契約の打ち切りや制限を迫る)、法を使うこと(あなたの州の法律にもとづき、公文書開示請求とデータ削除請求を出す)、そして構造を変えること(機微な移動では、カーシェアやレンタカーのような、自分の名義で登録されていない車に乗る)です。受け身で、つねに動き続けている網に対しては、大事な移動での露出を下げ、みなの行動でルールそのものを変えるほうが、どんな個人向けの装置よりも効きます。

ナンバープレートのカバーや反射スプレーは合法ですか——そして、効くのですか？
#

どちらも、おおむね「いいえ」です。ALPR カメラを「遮る」とうたう製品——カバー、PhotoBlocker のような反射スプレー、赤外線フィルム——は、カリフォルニア、ニューヨーク、フロリダなどの州で、はっきりと違法です。これらの州では、州の付加金が加わると、違反1件が約2,000ドルに達することもあります。RadarTest のような独立した検証は、最新の読取機に対して、測れるほどの効果を見つけられませんでした。この読取機は、赤外線と可視光の撮影を組み合わせ、露出を自動で調整するからです。あなたは、本当の守りを何一つ得られないのと引き換えに、お金を払って法を犯すことになります。

自分のナンバープレートのデータを削除させたり、誰が検索したかを知ったりできますか？
#

州によっては、できることもあります。カリフォルニア州をはじめ、増え続ける州では、警察の ALPR に関する規定や運用監査について公文書開示請求を出せますし、法律が認めていれば、あなた自身に関するデータの削除も求められます。記録に残るいくつかのストーキング事件では、被害者が、誰が自分のプレートを検索したのかを見せてほしいと求めたことが、まさに警官を暴く決め手になりました。限界は、Flock のような事業者が、自らをしばしば「サービス提供者」と呼び、個人からの請求を市の側へ差し戻してしまうことです——そして市は、動かないかもしれません。だから、この権利は実在しますが、ひとりでに執行されるわけではない、と考えておくべきです。

警察は、ナンバープレート読取のデータをどのくらい保持しますか？
#

州によって大きく異なり、たいていは上限がありません。上限を定めている州でも、保持期間は、ニューハンプシャー州の3分から、ワシントン州の21日、それ以外の州の60日かそれ以上まで幅があります。ですが大半の州には、ALPR に固有の保持を定めた法律がそもそもなく、つまりデータは何か月も、何年も、さかのぼって保持・検索されうる、ということです。記録が保持され、しかも複数の管轄をまたいでネットワーク化されているために、今日かけた一度の検索が、その車が数週間前にどこにいたかを組み立て直せます——これこそ、この技術を、リアルタイムの警報ではなく、監視の道具にしている性質です。

Flock Safety は合法ですか？
#

ALPR カメラを運用すること自体は、米国の大半で合法です。ですが、その具体的な使い方や、データ共有の取り決めは、違法だとして次々に争われるようになっています。2026年なかばまでに、Flock は集団訴訟に直面し、違法な州外データ共有をめぐる州司法長官の提訴を受け、議会の追及にさらされ、監査によって連邦や州をまたぐ無許可の検索が明らかになったあと、数十件の市の契約を打ち切られました。「設置するのは合法」と「実際の使われ方として合法」は、まるで別の問いだと分かってきました。

Cora Aegis

Cora Aegis は CypherpunkGuide で、プライバシーを最優先する OPSEC の指針を書いている。報道の多くが飛ばす「仕組み」を、一次資料から読み解く——ここでは、掲げるよう義務づけられた一枚のプレートが、どうやってあなたの人生を検索できる地図に変わるのか、そしてそれに対するどの守りが本物なのかを。

Cora についてもっと読む →

Slack 監視はこうして社員を解雇に追い込む（2026年）

Tue, 16 Jun 2026 00:00:00 +0000

すでに決着のついた話から始めよう。取り繕っても仕方がないからだ。あなたの雇い主は、あなたの Slack を読める。プライベートの印がついたメッセージも含めて。そして、あなたが管理画面を一度も目にすることのない料金プランで、履歴をまるごとエクスポートできる。あなたをここへ連れてきた検索語——職場の Slack は上司に読まれるのか——から持ち帰るものがひとつだけあるとすれば、これだ。プライベートではないと前提し、そこで立ち止まる。 その答えはもうどこにでもある。あなたがこのページにたどり着く道すがら読んだであろう AI の要約にも、たぶん書いてあった。だから私たちは、それを再確認するためだけに記事を1本費やすつもりはない。

そのページが答えないのは、あなたが職を保てるかどうかを実際に左右する問いのほうだ。何がフラグされ、何が解雇を招くのか。これは読めるかどうかとは別物で、両者のあいだの隙間でこそ、キャリアは失われる。私たちがこの事例研究を書いたのは、既存の指南が、ありきたりな対策で止まっているからだ——私物の端末を使え、DM を避けろ。そして、その仕組みは書かれないまま残されている。チャットのログは、どうやって解雇通知へと変わるのか。誰がそれを決めるのか。そして2024年、読み手が人間の管理者ではなくなり、あなたのトーンをリアルタイムで採点するアルゴリズムになったとき、何が変わったのか。私たちは、このサイトを索引するために訪れる AI クローラーを観測している。彼らは自分たちのスケジュールでやって来て、人間はそのループの中にいない。同じ転換が、いまやあなたの職場の内側にまで届いている。

だからこれは、あなたが今まさに打ち込んでいるチャット欄のための脅威モデルだ。以下に、文書化された3つの事例を置く——すべて報道され、すべて過去のもの、名前は公になっている範囲でのみ挙げる。そしてそこから、ありきたりな対策リストが飛ばす部分を取り出す。何が人を解雇に追い込むのかの分類。キーワード回避を無意味にする、2024年の自動採点への移行。そして、個人の防御がどこまでで、そこから先はなぜ集団で動くしかないのか、という率直な見立てだ。

下の表は私たち自身の総合だ。報道された3事例を、ありきたりな対策リストが飛ばす1本の軸——監視手法、それが何をフラグし、何が実際に職を終わらせるのか——に沿って並べた。

監視手法	何をフラグするか	実際に解雇を招くもの	あなたが打てる、効く一手
管理者によるエクスポート・検索（人間が確認）	キーワード、名指しされた個人、請求に応じた履歴	公の場、あるいはログに残る経営陣批判。誰かが上層部へスクショして回したメッセージ	機微な会話を、雇い主のプラットフォームの外へ移す
口実づくり・狙い撃ちの監査	組織化の中心人物や情報漏洩調査の周辺の動き	組織化や賃金是正の活動を、規則違反として描き直したもの	経緯を時系列で記録する。自分の concerted activity（団結行動）保護を知っておく
自動の感情・有害性採点（AI、リアルタイム）	全メッセージにまたがるトーンとパターン——キーワードは要らない	あなたには見えない低い「感情」スコアやリスクスコアが、雇い主へ差し出される	トーンは採点されると前提する。確実にすり抜ける言い回しは存在しない

職場の Slack 監視は実際どう動くのか
#

職場の Slack 監視は、後付けの仕掛けではなく、製品の企業向けプランに最初から組み込まれている。有料プランの管理者は、メッセージ履歴をエクスポートし、検索し、保持できる——あなたがプライベートだと信じているダイレクトメッセージやチャンネルも含めて。そして製品があなたに見落とさせようとしている事実はこうだ。プライベートとは表示範囲の設定であって、法的にも技術的にも壁ではない。職場が管理するワークスペースでは、システムの運営者は、システムが抱えるものに手が届く。それが床（最低ライン）だ。

あなたの脅威モデルにとって大切なのは、読まれ方の種類だ。種類が違えば、捕まえるものも違うからである。最も古く、最もありふれているのが管理者によるエクスポートと検索だ。しかるべき権限を持つ人間が履歴を引き出し——多くは調査、紛争、退職のさなかに——読むか、キーワードで検索する。これは事後的で、出来事が引き金になる。たいてい、あなた個人を見るには理由が要る。2つめは狙い撃ちの監査だ。特定の人物が注意を引いたために——組織化の中心人物として、漏洩の疑いをかけられた者として、辞めそうな人材として——その活動が精査される。3つめは新しく、この記事が存在する理由そのものだ。サードパーティの AI ツールによる自動的で継続的な採点である。送信される端からすべてのメッセージを読み、トーン・感情・リスクのシグナルを割り当てる。何かがフラグされるまで、人間はループの中にいない。最初の2つが問うのはこの人物は何を言ったかだ。3つめが問うのは全員のすべての発言を貫くパターンは何か——それを、四六時中、である。

法的な枠組みは、米国でも、これに似た多くの法域でも、容赦がない。雇い主が所有するシステム上、会社のアカウント上の通信は、おおむね雇い主が監視できるものであり、「プライベートと印をつけた」は、システムの運営者の前ではほとんど重みを持たない。本当の限界はある——保護された種類の言論であり、これは後ほど触れる——が、既定は露出だ。これらは何ひとつ隠されていない。プランの説明書に書いてある。多くの人が犯す誤りは、読まれうるかどうかを知らないことではない。自分がどの種類の読まれ方に晒されているかを見誤り、間違った相手に防御を張ってしまうことだ。

3つの事例——何が見られたか、から、誰が解雇されたか、へ
#

読まれうると解雇を招くの隙間を最も速く見るには、報道された3つの事例を並べ、それぞれに同じ道筋をたどればいい。何が監視され、何が解雇の引き金になり、そして——もしあれば——何が結末を変えたのか。これらは閉じた、文書化された出来事であり、すべて同時代の報道に依拠している。メッセージの中身はその報道に帰せられるもので、ここで再構成したものではない。

仕組み：経営陣への公の訂正。 イーロン・マスクによる Twitter 買収の数日後、同社は、新たな所有体制を社内 Slack チャンネルや公の場で批判していた社員たちを、波のように解雇した。解雇されたと報じられた中に、エンジニアの Eric Frohnhoefer がいた。NBC News によれば、彼はプラットフォームの性能に関するマスクの技術的な主張に公然と反論しており、その直後に解雇された。

教訓は、特定の1通のメッセージの中身ではない。ログに残る、雇い主が管理するチャンネルで——あるいは仕事の身元のまま公の場で——経営陣を批判することは、監視された状態から解雇された状態への、最も確実な一本道だということだ。しかもそれは、手の込んだツールを一切必要としない。

— Twitter、買収後のレイオフ、2022年11月

仕組み：組織化と、端末ポリシーという口実。 Apple は、プログラムマネージャーで #AppleToo 運動の共同発起人だった Janneke Parrish を解雇した。この運動は、賃金の不平等や職場での扱いに関する社員の証言を集めたものだ。表向きの理由は、漏洩調査のさなかに業務用端末からファイルを削除したこと、とされた。Parrish と支持者たちは、この解雇を彼女の組織化への報復だと評した。

2023年1月、TechCrunch が報じたところによれば、NLRB（全米労働関係委員会）の地方事務所は、Apple が労働者の権利を侵害したとの申し立てに予備的な認定（found merit）を下した。これは予備的な一歩であって最終判断ではなく、しかもこの規制上の筋は持ちこたえなかった。2025年9月、Reuters が報じたとおり、同委員会の検察官は、Board の指導部交代のさなかに、Parrish の解雇に関するものを含むこの一連の申し立てを取り下げ、Apple が法を破ったという最終的な裁定は下されなかった。持ち越すべきパターンは、結末に左右されない。組織化の活動が理由として挙げられることはまれだ。挙げられるのは、別の、もっともらしく聞こえる規則違反のほうである。そして規制による救済は、たとえ始まったとしても、何年もかかったうえに、霧消しうる。

— Apple、#AppleToo の組織化、2021年10月

仕組み：名指しの解雇はない——そして、それこそが要点だ。 Aware は、Slack、Microsoft Teams、その他のツールにまたがる職場チャットの AI 監視を売る企業で、メッセージを感情や「有害性」について大規模に採点する。2024年に CNBC が報じたところによれば、そのシステムは300万人を超える従業員にまたがる、およそ200億件のやり取りを解析しており、名の挙がった顧客には Walmart、Delta、T-Mobile、Chevron、Starbucks が含まれていた。

Aware の単一のスコアに結びついた公の解雇はない。そして、その必要もない。Aware はフラグを立てる。そのフラグをどうするかは、顧客企業が決める。脅威は構造的なのであって、逸話的ではない——だからこそ、最初の2つの事例のような見出し級の解雇を生まないのであり、だからこそ、防ぐのがより難しいのだ。

— Aware による AI 職場監視、2024年に報道

3つを横に読むと、総合は、どの単一の事例よりも鋭くなる。Twitter の一件は、最も古い監視手法——人間がログに残る批判を読む——が、いまなお最も速い解雇を生むことを示す。Apple の一件は、監視がしばしば口実のための証拠であって、表向きの理由ではないことを示す。解雇は規則違反で装われ、本当の引き金は保護された活動なのだ。そして Aware は、その軌道を示す——人間がメッセージの意味を判断する側から、機械がパターンの含意を採点する側へ。最初の2つは、あなたが選べる中身についての話だ。3つめは、あなたが完全には制御できないトーンについての話であり——その区別こそ、この脅威モデルにとっての2024年の更新まるごとである。

脅威モデル——実際に何が解雇を招くのか
#

職場チャット監視から流れ出る解雇は、ごく少数の引き金に集まる。そして、それらのリスクは一様ではない。経営陣への批判と組織化の活動が、報じられた事例の大半を占め、感情フラグが台頭する3つめだ。そして中間のカテゴリを覆うはずの法的保護は、本物ではあるが、執行は遅く、不均一である。この分類を知れば、あらゆるものに警戒を薄く広げるのではなく、自分が現に抱える特定のリスクに防御を張れる。

4つの引き金が仕事の大半をこなす。そして、そのリスクは一様ではない。

解雇の引き金	軸となる事例	たいていどう現れるか	相対的なリスク
ログや公の場での経営陣批判	Twitter、2022年	直接引かれるか、スクショが上層部へ転送される——特別なツールは要らない	最も基底のリスクが高い
組織化と賃金是正の活動	Apple、2021年	組織化に帰せられることはほぼない。同時期の規則問題（削除されたファイル、端末規則）として装われる	高い、たいてい偽装される
感情・リスクのフラグ	Aware、2024年	単一のメッセージを原因としない不透明なスコア——指し示すものも、異議を申し立てる先も、きれいには存在しない	台頭中、争うのが難しい
漏洩・守秘の調査	他の引き金の運び役	別の理由で都合の悪い人物を狙い撃ちで監査することを許す、表向きの理由	他の3つを増幅する

上から下へ読むと、この表はあなたの露出の順位づけにもなっている。最初の2つの引き金が文書化された解雇の大半を占め、3つめは台頭中、4つめは他のものが実行に移される際の運び役だ。

ここで、ありきたりな対策リストが平たく潰してしまう法的な機微を、正確に述べておく。重要だからだ。米国では、全米労働関係法（NLRA）が*concerted activity（団結行動）*を保護する——賃金、労働時間、労働条件をめぐって従業員が共同で行動することで、多くの組織化や賃金是正の議論を含み、組合の有無にかかわらず大半の民間部門の労働者に適用される。この保護は本物だ。だが、それはその場で働く盾ではない。事後に、NLRB（全米労働関係委員会）への申し立てや訴訟を通じて執行されるもので、しかも、その保護された活動が不利益処分の本当の理由だったことを立証する負担は、従業員の側にある。結果はまちまちで、所要期間は数か月から数年に及び、適用範囲は法域や労働者の区分によって異なる。Apple の件は、両側を一度に映し出す。組織化した者たちには保護された活動という主張があった。そして、NLRB の予備的な認定は解雇から1年以上たって出され、挙げ句、最終判断のないまま2025年に取り下げられた。NLRA は、入念に記録し、集団で行動する理由として扱うこと——その場の免責としてではなく。これは公の報道と条文に依拠した一般情報であって、法的助言ではない。あなた自身の状況については、労働問題の弁護士に相談を。

2024年の転換——読み手がアルゴリズムになったとき
#

この脅威モデルにとって最も重要な更新は、あなたの職場チャットの読み手が、もはや「あなたを見るのに理由を要する人間の管理者」とは限らないことだ。それは次第に、すべてのメッセージを感情とリスクについて採点する、常時稼働の AI システムになりつつある。そしてこのたった一つの変化が、特定の言葉を避けよという従来の助言を、ほぼ無意味にしてしまう。 Aware の報道は、その変曲点を示す。数十億件規模のやり取りに、継続的に、全員に、調査を前提条件とすることなく適用される監視である。

なぜこれが古い手口を打ち負かすのかを理解しよう。キーワードに基づく監視——人間によるエクスポート、特定の語の検索——は、その語を使わなければ回避できる。経営幹部の名前を出さない、組合という語を避ける、引き金を迂回する。感情採点には、避けるべきキーワードがない。 それはトーンを、苛立ちを、何週間にもわたる気分の軌道を読む。あなたが何を書くかだけでなく、どう書くかからパターンを組み立てる。あなたが中を覗けないモデル、一度も示されない閾値に調整されたモデル、採点ロジックが企業秘密のベンダーに対して、確実に「中立」と読まれる言い回しなど存在しない。会話が問題としてフラグされるのに、禁じられた語を含んでいる必要はないのだ。

3つの帰結が、防御の順序を組み替える。第一に、人間の判断という緩衝が薄くなっている。 人間の確認者は文脈を持ち込む——皮肉、ついていない一週間、内輪のジョーク——が、自動スコアは設計上それを切り捨てる。フラグは、そのメッセージを許したかもしれない当の機微を剥ぎ取られて届く。第二に、きれいに異議を申し立てられるものがない。 キーワードにたどれる解雇なら、争うべき特定のメッセージが手元にある。集計された「リスクスコア」の下流にある解雇は、一文も付随しない数字を手渡すだけだ。第三に、そして最も有用なことに、チャンネルの区別が崩れる。 トーンが、どこでも、四六時中、採点されるのなら、チャンネルの規律こそ唯一の本当の制御になる——雇い主のプラットフォームの内側での言葉選びではなく、本当のリスクを帯びる会話を、そのプラットフォームの外へまるごと移すこと、だ。これこそが、手口である。

防御の手口
#

職場チャット監視への防御とは、自分が抱える特定の引き金に制御を合わせることだ。そして制御は3つの層に分かれる。アカウントと端末を分けて、職場の監視が私生活に届かないようにすること。職場の内側でチャンネルの規律を保つこと。そして——もしあなたが組織化に近いことを少しでもしているなら——高リスクの会話が始まる前に、それを雇い主のプラットフォームの外へ移すこと、だ。すべてが要るわけではない。自分の脅威に合う層が要るのだ。

環境を分ける。 仕事と私生活を、別々の端末、別々のアカウントで、重なりなく保つ——業務用ノートに私物のログインを入れない、私物のスマホに、どうしても必要な分を超えた仕事のチャットを入れない。これは AI の要約がすでに教えてくれる基本線であり、正しい。一方の文脈の監視が他方へ届くのを防ぐし、最も安く採れる制御だ。だが、これは必要ではあっても十分ではない。仕事用の環境の内側で何を言うかには、何もしないからだ。

チャンネルの規律を保つ。 雇い主が管理するワークスペースでは、すべてのメッセージを——ダイレクトメッセージも、プライベートの印がついたチャンネルも含めて——「いずれエクスポートされ、好意的でない誰かに読まれる」ものとして書くこと。システムの運営者には、まさにそれができるからだ。これは、自分の有能さを沈黙へと自己検閲せよ、という話ではない。自分のキャリアを終わらせる一文を、その標的が握るシステムの中に決して置かない、という話だ。

高リスクの会話を、プラットフォームの外へ——早めに移す。 組織化している、賃金是正を訴えている、あるいは雇い主が監視したくなるような何かを計画しているなら、最も効く一手は、その会話を、雇い主が運営しない場所で持つことだ——それも、十分に進んでから、あるいは発覚してからではなく、本格化する前に。私物の端末で、自分の時間に、Signal や SimpleX のようなエンドツーエンド暗号化された経路を使えば、肝心の中身はエクスポートからまるごと外れる——これらのツールの、メタデータを最小化する設計こそが効く性質であって、何か単一の機能ではない。これが Apple の事例が指し示す構造的な手当てだ。雇い主のプラットフォーム上にある組織化の会話は証拠になる。一度もそこに触れなかった会話は、ならない。これを、公開したものは取り消しにくいというより大きな原則と組み合わせること——削除しても消えない、SNSの足跡の永続性は、SNS と同じく職場のログの内側にも当てはまる。

concerted activity（団結行動）の保護を知り、記録する。 あなたの活動が団結行動なら——賃金、労働時間、労働条件についての共同行動なら——NLRA の保護下にある可能性が高い。これを正確に知る価値があるのは、それが「何を記録すべきか」を形づくるからだ。保護された活動と、その後に続くあらゆる不利益な扱いについて、日付入りの時系列を同時並行で残し、私物の端末に保管する。あなたが築いているのは免責ではない。事後の申し立てや労働弁護士が必要とする証拠の記録だ——本当の理由を示す負担が、あなたに課されることを思えば。

なぜ個人の防御だけでは足りないのか
#

ここに率直な限界がある。これを隠す OPSEC 失敗事例研究は、ありきたりな対策リストと同じことをしていることになる。チャンネルの規律と端末の分離は、個人を守る。だが、その監視を生んだ条件は変えない。そして、全員に一斉に適用される不透明な自動採点に対しては、個人の技術は尽きる。あなたは、職を終わらせる一文を雇い主のプラットフォームから外しておける。だが一人では、ワークスペース全体を走る感情スコアからオプトアウトすることも、自動監視が取り除く人間の判断という緩衝を取り戻すことも、法があなたに課す立証責任を動かすこともできない。

事例を、ひとつの組として読むと、そう告げている。Twitter の解雇は、言い回しの問題ではなく、力の非対称だった。Apple の組織化した者たちは、その主張を記録に載せるだけのために、集団の重みと規制当局の注意を必要とした——より良い OPSEC ではなく、NLRB を。それでもなお、認定は予備的で、職が失われてからずっと後に出て、挙げ句、最終判断のないまま取り下げられた。Aware のモデルは、作りからして構造的だ。それは全員を監視するものとして売られている。これこそ、いかなる個人も迂回できないものだ。これらの条件を実際に動かせるのは、個人の暗号が制度の力とぶつかるとき、cypherpunk がいつも名指してきたものだ——集団の行動と、変えられた規則である。concerted activity の保護のより強い執行。自動の職場採点に対する透明性の要求。報復に高くつかせるだけの頭数を持った組織化。個人の防御は、安全と時間を買ってくれる。だが、それ自体が非対称を正すことはない。

それが、このサイトの Privacy の仕事を貫く一本の線だ。あなたが雇い主から受ける監視は、国家があなたのデータを漏らす日に受ける監視と、同じ形をしている——参加を強いられるシステムから自分を消すことはできないのだから、防御は、自分が握る層に、そしてその先では集団の圧力に宿る。そして、そのすべての底にあるより深い駆動装置は、AI時代のOPSECで私たちが地図に描いたものだ——読み手が、トーンを継続的に採点する機械になったとき、間違った語を避けるという古い規則は効かなくなり、脅威モデルは、発言ではなくパターンを軸に組み立て直さねばならない。残りの Privacy 柱も手元に置いておくこと——職場の監視は、ひとつの問題のひとつの顔にすぎない。

「電子の時代において、プライバシーは開かれた社会に欠かせない。……政府にも、企業にも、その他の顔のない巨大な組織にも、その善意からプライバシーを与えてくれるなどと期待することはできない。」 — エリック・ヒューズ『暗号無政府主義者宣言（A Cypherpunk’s Manifesto）』1993

ここでいう顔のない組織が企業であり、チャットのログが電子の時代だ。個々のケースを防御せよ。そのうえで、条件そのものに圧力をかけよ——監視を売るベンダーも、それを買う雇い主も、その善意からあなたにプライバシーを与えてはくれないのだから。

結論——あなたの状況に合うのはどの防御か
#

ふさわしい警戒の水準は、あなたがそのチャット欄で何をしているか、そして誰があなたを見張る理由を持つかで、まるごと決まる。

特定の露出がない、ふつうの社員なら： ワークスペースを「既定でエクスポートされるもの」として扱い、仕事と私生活の端末・アカウントを分け、キャリアを終わらせる一文を、雇い主が管理するあらゆるシステムの外に置く。リスクの大半は、低コストでこれで片づく。
組織化、賃金是正、あるいは雇い主が監視したくなる何かをしているなら： あなたの最前線はプラットフォームの外だ。本格化する前に、肝心の会話を私物の端末の暗号化された経路へ移し、保護された活動とあらゆる報復について日付入りの時系列を記録し、concerted activity の保護を「その場の免責」ではなく「証拠を形づくるもの」として学ぶ。
プライバシー／セキュリティのチームを率いるなら： 2024年の転換が、あなたの計画の入力だ。従業員が、ロジックの見えない自動の感情採点の対象になっていると前提せよ。トーンがいまや監視され、安全なキーワードの集合など存在しないという理解の上で、ポリシーを設計せよ。そして、チャット監視をサードパーティのベンダーの下に集中させる構造的なコストを、売り文句の効率と天秤にかけよ。

3つすべてに共通して、それ以前のあらゆる OPSEC の失敗で成り立ってきたのと同じ真実が成り立つ。メッセージがログに残ったあとで、送信を取り消して安全にたどり着くことは、確実にはできない。できるのは、打ち込む前に、どのシステムにその一文を抱えさせるかを決めることだけだ——そして、一人にできることの限界の先では、そもそもそのシステムにあなたを見張らせた条件を変えるために、他者とともに行動することだ。

要点

雇い主があなたの Slack を読めるかは、もう決着がついている——読める、「プライベート」な DM も含めて。 決定的な問いは何が解雇を招くかであり、それはありきたりな対策リストが飛ばす別の脅威モデルだ。
監視と解雇——Twitter、2022年： ログや公の場で経営陣を批判することは、監視から解雇への最も速い文書化された一本道であり、特別なツールを必要としない。
監視と解雇——Apple、2021年： 組織化が表向きの理由になることはまれで、同時期の規則違反（削除されたファイル、端末規則）が口実になる。NLRB の地方事務所は1年以上たって労働者の権利侵害の申し立てに予備的な認定を下した——同委員会が2025年に最終判断のないまま取り下げた、予備的な一歩である。
2024年の転換——Aware の AI： 数十億件のメッセージへの継続的な自動感情採点は、避けるべきキーワードがないことを意味する。トーンそのものが採点されるので、語の回避はもう効かず、チャンネルの規律だけが本当の制御になる。
法的な現実——NLRA： 賃金や労働条件をめぐる団結行動を保護するが、立証責任をあなたに負わせて事後に執行する。その場の免責としてではなく、記録し組織化する理由として扱うこと。
限界： 個人の防御は安全と時間を買うが、ワークスペース全体の採点からあなたをオプトアウトさせることも、力の非対称を正すこともできない——それをするのは、集団の行動と変えられた規則だ。

よくある質問
#

雇い主は私の Slack のダイレクトメッセージを読めますか？
#

職場が管理する Slack ワークスペースでは、おおむね読めます。有料プランの管理者は、ダイレクトメッセージやプライベートの印がついたチャンネルを含めて、メッセージ履歴をエクスポートし、検索できます。プライベートとは利用者どうしのあいだの表示範囲の設定であって、システムの運営者に対する壁ではありません。雇い主が管理するワークスペース上のメッセージは——DM も含めて——雇い主に読まれ、エクスポートされうるものとして扱ってください。

職場のチャット監視は合法ですか？
#

米国やこれに似た多くの法域では、雇い主が所有するシステムや会社のアカウント上の通信の監視は、おおむね認められており、職場のワークスペースの既定は、あなたのメッセージを雇い主が監視できる、というものです。具体的な規則は、法域によって、また何を監視するかによって異なり、保護された種類の活動もあります（下記の NLRA を参照）。これは一般情報であって法的助言ではありません——あなた自身の状況については労働問題の弁護士に相談を。

Slack で雇い主を批判したら、NLRA は私を守ってくれますか？
#

部分的に、そして条件つきで、守ります。全米労働関係法（NLRA）は*concerted activity（団結行動）*を保護します——賃金、労働時間、労働条件をめぐって従業員が共同で行動することで、大半の民間部門の労働者について、多くの組織化や賃金是正の議論を覆います。ただし、それは事後に、NLRB への申し立てや訴訟を通じて執行され、保護された活動が不利益処分の本当の理由だったことを示す負担はあなたにあります。結果も所要期間もまちまちです。共同でもなく、労働条件についてでもない、個人の不満の吐露は、おおむね保護されません。

AI の感情監視にフラグされるのを避けられますか？
#

言葉を変えることでは、確実には避けられません。2024年に報じられたようなツールは、特定のキーワードを探すのではなく、あなたの全メッセージにまたがるトーンとパターンを採点します。だから、あなたが中を覗けないモデルに対して、当てになるほど中立に読まれる言い回しなど存在しません。現実的な制御は、雇い主のプラットフォームの内側での言い回しではなく——高リスクの会話を、そのプラットフォームの外へまるごと置くことです。

職場の監視に対して、実際に役立つツールは何ですか？
#

本当のリスクを帯びる会話——組織化、賃金是正、雇い主が監視したくなる何か——については、それらを雇い主のプラットフォームの外、私物の端末へ、Signal や SimpleX のようなエンドツーエンド暗号化された、メタデータを最小化する経路を使って移すことで、肝心の中身はあらゆるエクスポートから外れます。職場の内側での制御は、仕事と私生活の端末・アカウントを分けることと、規律あるチャンネルの使い方です。雇い主が管理するワークスペースの内側に、あなたのメッセージを管理者から読めなくするツールはありません。

#	出典	URL	アーカイブ
1	NBC News——Twitter の買収後レイオフと Eric Frohnhoefer（2022年11月）	https://www.nbcnews.com/news/amp/rcna57250	https://web.archive.org/web/*/https://www.nbcnews.com/news/amp/rcna57250
2	CNN Business——Apple が #AppleToo の発起人 Janneke Parrish を解雇（2021年10月）	https://www.cnn.com/2021/10/15/tech/apple-appletoo-organizer-janneke-parish/index.html	https://web.archive.org/web/*/https://www.cnn.com/2021/10/15/tech/apple-appletoo-organizer-janneke-parish/index.html
3	TechCrunch——NLRB が Apple 幹部の労働者の権利侵害を認定（2023年1月）	https://techcrunch.com/2023/01/30/labor-officials-found-that-apple-execs-infringed-on-workers-rights/	https://web.archive.org/web/*/https://techcrunch.com/2023/01/30/labor-officials-found-that-apple-execs-infringed-on-workers-rights/
4	CNBC——AI があなたの Slack・Teams を読んでいるかもしれない、Aware の技術で（2024年2月）	https://www.cnbc.com/2024/02/09/ai-might-be-reading-your-slack-teams-messages-using-tech-from-aware.html	https://web.archive.org/web/*/https://www.cnbc.com/2024/02/09/ai-might-be-reading-your-slack-teams-messages-using-tech-from-aware.html
5	全米労働関係委員会（NLRB）——団結行動（第7条の権利）	https://www.nlrb.gov/about-nlrb/rights-we-protect/the-law/employees/concerted-activity	https://web.archive.org/web/*/https://www.nlrb.gov/about-nlrb/rights-we-protect/the-law/employees/concerted-activity
6	Reuters——米労働委員会、Apple の CEO が従業員の権利を侵害したとの申し立てを取り下げ（2025年9月）	https://www.reuters.com/sustainability/sustainable-finance-reporting/us-labor-board-withdraws-claims-apple-ceo-violated-employee-rights-bloomberg-2025-09-26/	https://web.archive.org/web/*/https://www.reuters.com/sustainability/sustainable-finance-reporting/us-labor-board-withdraws-claims-apple-ceo-violated-employee-rights-bloomberg-2025-09-26/

Cora Aegis

Cora Aegis は CypherpunkGuide で、プライバシーを第一に置いた OPSEC 指南を書いている。閉じた監視事例を、多くの報道が飛ばす仕組みのために読み解く——ここでは、職場のチャットログが、どうやって解雇通知へと変わるのかを。

Cora についてもっと読む →

電話番号のプライバシー——2026年でも効く「4つの番号」戦略

Tue, 14 Jul 2026 00:00:00 +0000

登録フォームは、どれも電話番号を求めてくる。銀行も、歯科医院も、スーパーのポイントカードも——そして今月、hosted AI（事業者のサーバー側で動く AI）の大手6サービスの登録要件を洗い出して分かったのだが——チャットボットまでもだ。r/privacy のあるユーザーは、大半のセキュリティベンダーよりうまく言い当てた。電話番号は新しい SSN だ（原文 “the phone number is the new SSN”）——SSN とは米国の社会保障番号のことで、生涯ほぼ変わらず、あらゆる場面に付いて回る身元番号だ。ほとんどの人が一度も変えず、あらゆるサービスで使い回し、年に何十回も他人へ渡す識別子は、電話番号のほかにない。だからこそ、攻撃者にとってもデータブローカー（個人情報を集めて売買する業者）にとっても、これほど安上がりな「名寄せ」（ばらばらの記録を同一人物へ束ねる作業）の鍵はないのだ。

厄介なのは、2026年がその逃げ道を、二つの方向から同時に塞ぎにかかっていることだ。上からは、米連邦通信委員会（FCC）が提案中の規則で、すべての電話事業者に対し、新規・更新契約のたびに「氏名、居住住所、政府発行の身分証明書番号、および予備の電話番号」（原文 “the name, physical address, government issued identification number, and an alternate telephone number”）を集めさせようとしている。Privacy International の2021年の世界集計の時点で、157か国がすでに何らかの形で敷いていたモデルである。下からは、どのガイドも最初に勧める回避策——VoIP 番号、つまり Google Voice や Hushed のようなアプリが発行する、SIM カードにひも付かないネット経由の電話番号——を、サービス側が静かに拒み始めた。Anthropic のヘルプセンターはいま、Claude のアカウント開設に「VoIP 番号、Google Voice、アプリで作成した電話番号、固定電話」は使えないと明記しているし、その Google Voice 自体も、2026年1月から新規ユーザーに政府発行の身分証を求めるようになった。そのあいだも、手元の番号は漏れ続けている。FBI は2024年に SIM swap（携帯会社をだまして他人の番号を自分の SIM カードへ移させる乗っ取り手口）の被害届982件、損失2,600万ドルを記録し、ある監視ベンダーは、通信会社どうしをつなぐ1970年代生まれの交換網 SS7 を悪用して、2024年から2025年にかけて電話番号から人の居場所を突き止めていたことが発覚した。

だから、正直に立てるべき問いは「電話番号をどう隠すか」ではない。完全に隠すことはできないし、できるふりをした助言は人を傷つける。問うべきは、どの番号に、どの仕事をさせるかだ。この記事では、番号一つが何を明かすのかを整理し、挟み撃ちの実態を一次資料と国別の表で確かめ、各社の登録要件を自分で洗い出した結果から、どのサービスが実際に代替番号を拒むのかを示す。そのうえで、いまも効く「4つの番号」戦略を、4つの具体的な脅威モデルに突き合わせて組み立てる。

電話番号は、もう身分証になっている
#

電話番号の身元ひも付け（identity binding）とは、電話番号を「連絡を取る手段」ではなく「本人であることの証明」として使う運用を指す。変わったのは、まさにここだ。連絡先なら取り替えが利く。だが身元の要になった番号を、アカウントも、データブローカーも、政府も、残るすべての情報をつなぎ合わせる軸として使う。その役割の中で電話番号をとりわけ危険にしている仕組みが、3つある。

番号ひとつで、あなたのアカウントの鍵が開く。 SIM swap とは、攻撃者が携帯会社を言いくるめて、あなたの番号を自分の SIM カードへ移させる攻撃だ。以後、ログインコードを含むすべての SMS は攻撃者へ届く。珍しい話ではない。Princeton の研究チームが2020年に米国の大手プリペイド携帯5社を試したとき、SIM swap の試行は 50回中39回（78%） 成功した。同じ調査の対象になった人気ウェブサイト140超のうち、17件は電話番号だけで乗っ取れた——パスワードは要らなかった。FBI のインターネット犯罪苦情センター（IC3）は、2024年に SIM swap の被害届982件、損失2,598万ドルを記録している。2022年の7,270万ドルからは減ったが、損失の一部はいまでは近縁の詐欺区分に計上されている可能性がある。

その網に入り込む手段を買える相手には、誰であれ現在地を教えてしまう。 SS7 は、通信会社どうしが通話を橋渡しするために使う信号網で、そこへ入り込んだ者は「この番号はいまどこにいるか」を問い合わせられる。2025年、通信セキュリティ企業 Enea の研究者は、ある監視ベンダーを記録した。細工したコマンドで通信会社側の防御をすり抜け、電話の位置情報を注文どおりに引き出す手口で、Enea が2024年末から実際の使用を追跡してきた攻撃類型だ。あなたは何もクリックしなくていい。番号を知られている——それだけで足りる。

番号をたどれば、名前に行き着く。 米国では、通信会社が管理する発信者名データベース CNAM が、番号を登録名に対応づけている。さらに商用の人物検索サイトは、番号を漏えいデータ・有権者名簿・不動産記録と突き合わせ、数ドルで氏名と自宅住所を返してくる。一度でも本人の身元にひも付いた「プライベートな」番号は、索引の項目として永久に残る。この永続性は、SNS の履歴で記録したのと同じ力学だ——目に見える複製を消しても、名寄せの鍵は消えない。

挟み撃ち——上からは本人確認、下からは拒否
#

ここに、大半のガイドがまだ追いついていない構造の変化がある。人々が頼ってきた二つの逃げ道——現金でプリペイド SIM を買うことと、ネット経由の番号を使うこと——が、正反対の両端から同時に閉じられつつあるのだ。挟み撃ちの両側を押さえてはじめて、この後の戦略は懐古趣味ではなく、現実に立脚した設計になる。

上から：登録の義務化。 Privacy International の2021年の世界調査の時点で、157か国が SIM カードの身元登録を義務づけ、義務のない国は34か国のみ。14か国は顔スキャンなどの生体情報まで求めていた。義務のない国の顔ぶれは、縮み続けている。メキシコでは2022年に最高裁が生体情報つきの SIM 登録制度を違憲としたが——2026年1月、CURP（メキシコの国民 ID 番号）にもとづく登録義務が結局やってきて、未登録回線は2026年7月から停止されていく。目立った例外が米国で、連邦レベルの登録義務はこれまで存在しなかった。FCC が2026年4月に出した提案（整理番号 CG 17-59、5月26日に連邦官報へ掲載）は、まさにその例外を終わらせるものだ。KYC（know-your-customer、本人確認義務）として氏名・居住住所・政府発行の身分証番号・予備の電話番号を集め、契約が終わったあとも4年間保存する。まだ提案であって法律ではない——意見募集は2026年7月27日まで続く——が、進む方向は見誤りようがない。そして日本は、この提案より一足早く、同じ方向へ踏み出していた。2026年5月の携帯電話不正利用防止法の改正は、本人確認の対象をデータ通信専用 SIM——この市場に最後まで残っていた、身分証なしで持てる領域——へ広げる。施行の期限は2027年5月だ。

この挟み撃ちを最初に食らうのは、犯罪者ではない。全米 DV 撲滅ネットワーク（NNEDV）は FCC に対して意見書を出し、提案が「疑わしい」と名指す振る舞い——現金で払う、私書箱や転送住所を使う——は、「生存者にとって、確立された、しばしば命を守る安全の実践だ」（原文 “are, for survivors, well-established and often life-preserving safety practices”）と述べた。加害者から逃げる被害者には、安全に書ける住所も、取りに戻れる書類もないことがある。ジャーナリストとその情報源も、賭けているものこそ違え、同じ問題を抱える。これは、私がこのサイトで繰り返し立ち返るパターンだ。詐欺対策として築かれた本人確認の関門は、失うものが最も大きい人々に、最も重くのしかかる。

あなたの国は、どこに立っているか。 次の表は、一次法令資料と Privacy International の調査から私が組んだものだ。各行に、その行自身の出典と確認日が付いている。代表的な制度を切り取ったものであって、網羅的な一覧ではない。

国	プリペイド SIM に身分証は必要か	確認されるもの	データ通信専用 SIM	出典
米国	法律上の義務なし — FCC の提案（2026年）が通れば身分証の収集が加わる	—	—	出典 · 2026-07-14
英国	法律上の義務なし	—	—	出典 · 2026-07-14
ポルトガル	法律上の義務なし	—	—	出典 · 2026-07-14
ドイツ	法律で義務 (2017)	政府発行の身分証	同じ規則	出典 · 2026-07-14
スペイン	法律で義務 (2007)	政府発行の身分証	同じ規則	出典 · 2026-07-14
メキシコ	法律で義務 (2026) — 生体情報つき登録制度は2022年に違憲判断。CURP にもとづく身分証登録は2026年1月から施行	政府発行の身分証	同じ規則	出典 · 2026-07-14
ブラジル	法律で義務	政府発行の身分証	同じ規則	出典 · 2026-07-14
日本	法律で義務 (2006) — 2026年改正により、2027年5月までにデータ通信専用 SIM も本人確認の対象に	政府発行の身分証	現時点では対象外	出典 · 2026-07-14
中国	法律で義務 (2019)	政府発行の身分証+顔スキャン	同じ規則	出典 · 2026-07-14

代表的な制度を切り取った表であり、網羅的な一覧ではない——規則は変わる。各行に出典と最終確認日を付した。「法律上の義務なし」は、通信会社が何も集めないという意味ではない：支払い記録も、店舗のカメラも、各社の社内規程も存在し続ける。

この先を読み進める前に、まず上の表で、自分が住んでいる国の行を確かめてほしい。日本にいる読者なら「日本」の行だ——音声通話つき SIM の購入には本人確認が法律で義務づけられている一方、データ通信専用 SIM は現行法の対象外だ。ただし、この例外には期限が付いた。2026年5月の改正により、2027年5月までに本人確認の対象へ組み込まれることが決まっている。つまり日本では、後述の第4層（プリペイド）は、音声 SIM である限り購入時点で身元とひも付き、切り分けの本体は残る3層が担うことになる。義務のない国にいる読者なら、プリペイドの層は今日もそのまま使える。それ以外の国の読者は、自国の行と、その行の出典を確かめてから先へ進んでほしい。

下から：サービスそのもの。 法律が沈黙している場所でも、プラットフォームは、携帯会社の契約にひも付かない番号を拒むようになっている——そして、その区別は機械的に付けられる。Twilio の Line Type Intelligence API は商用の番号照会サービスの一つで、任意の番号を mobile、landline、fixedVoip、nonFixedVoip といった12種類に分類する。Twilio は、認証フローから「nonFixedVoip」の番号をはじく使い方を、不正対策チーム向けに公然と売り込んでいる。かつてプライバシー対策の定番だった Google Voice は、いまや新規番号の取得に政府発行の身分証を要求する（2026年1月30日から）。安価な回避手段の世界は、値札と許可制で締め出されつつある。

どの AI サービスが代替番号を拒むのか、実際に確かめた
#

抽象的な警告より、検証済みの一覧のほうが役に立つ。2026年7月、私は hosted AI 大手6サービスの登録要件を、各社自身のヘルプセンター・利用規約・プライバシーポリシーから引き出し、構築中の要件データセットの一部として各ソースをアーカイブした。この表は日付つきのスナップショットとして扱い、頼る前に各社の現行ページと突き合わせてほしい。AI アシスタントは試験台としてふさわしい。いま最も新規アカウントが増えている領域であり、AI アシスタント監査で示したとおり、そこへ話したことは記録として残るからだ。

サービス	登録時の電話番号（2026年7月時点）	番号なしの経路	効いてくる細部
Claude（Anthropic）	必須——新規アカウント全員、SMS のみ	なし	VoIP・Google Voice・アプリの番号・固定電話は拒否。1番号につき1アカウント
ChatGPT（OpenAI）	メール/SSO 経由なら不要	メール、または Google/Microsoft/Apple でのログイン（SSO）	電話番号のみの登録も存在するが、列挙された13地域に限られる
Gemini（Google）	Google アカウントの規則に従う	Google アカウント	ひも付く先は番号ではなく、Google の身元全体
DeepSeek	メールまたは電話	メール経路	登録時はどちらの識別子でも通る
OpenRouter	不要	メール/SSO	中継役：身元の露出は、モデルを実際に提供する各社の側へ移る
Venice	不要	メール、ソーシャル、または暗号資産ウォレット	デモはアカウントなしで動く——今回確かめた中で、最もひも付きの薄い経路

Claude の行には、原文をそのまま引く価値がある。大手サービスの中で、新しい標準をこれほど明瞭に言い切った文はないからだ。「新規の利用者全員に電話番号の確認を求めており、この手順を飛ばす方法はありません……VoIP 番号、Google Voice、アプリで作成した電話番号、固定電話、その他テキストを受信できない番号は、アカウントの確認には使えません」（原文 “We require phone verification for all new users, and there isn’t a way to skip this step… you cannot use VoIP numbers, Google Voice, phone numbers created using apps, landlines, or other numbers that can’t receive texts to verify your account."）。実在の携帯番号一つに、アカウント一つ。そして、この表の幅こそが実務上の要点だ。同じ製品カテゴリの中に、「携帯会社で確認済みの番号、例外なし」から「アカウント不要」までが並んでいる。 そのサービスに、どの番号を——そもそも番号を——差し出す価値があるのか。それは、いまもあなたが選べる。ただし、実番号を打ち込む前に確かめた場合に限る。

いまも効く「4つの番号」戦略
#

一つの電話番号にすべての仕事をさせること——それ自体が脆弱性だ。長持ちする直し方は、役割の分離である。AI 時代の脅威モデルを貫くのと同じ区画化の理屈を、人々が区画し忘れる唯一の識別子に適用する。電話番号は安い。一つの名寄せの鍵で見つかる状態こそ、高くつく。守りの厚い順に、4層を並べる。

層	その番号	渡す相手	決して使わない用途
1——金庫	携帯会社契約の実番号	携帯会社、SMS を強制する銀行、行政	あらゆるウェブサイト登録、メッセージアプリ、電話帳の類
2——対人	ユーザー名の背後に置いたセキュアメッセンジャー	実際にやり取りする人	公開の場への掲示。番号検索を開けたままの運用
3——アカウント	VoIP 番号を1〜2本	通販、ニュースレター、VoIP を通すアプリ	金銭を引き出せるもの一切
4——端（使い捨て）	プリペイド SIM（適法な国で）または番号なし	一回きりの認証、個人売買、旅行	第1層・第2層アカウントへのログイン

組み立ては、この順で進める。

何よりも先に、金庫を固める。 携帯会社に連絡して port-out PIN（番号を他社へ移す手続きに必要な暗証番号）か番号ロックを設定する——Princeton の結果が示したとおり、携帯会社の本人確認こそ最も破られやすい壁だ。次に、認証アプリやパスキーへ切り替えられるすべてのアカウントから、実番号を外す。SMS を第二要素にするのは、他に何も用意されていない場合だけにする。
メッセンジャーの番号を、ユーザー名に変える。 Signal は2024年2月から、ユーザー名の背後に番号を隠せる。登録にはいまも電話番号が要るが、「電話番号であなたを見つけられる人」を「なし」に設定すれば、相手に見えるのは cora.01 であって、数字ではない。第2層が存在する理由はこうだ——連絡がつくことと身元は、もともと同じものではなかった。
アカウント層を買う。 VoIP サービス——SIM にひも付かないネット電話の番号——は、MySudo や Hushed なら月に数ドルで区画用の番号をくれる。XMPP の上で動く JMP.chat は、プライバシー系のコミュニティで人気だ。先の表が示したとおりのことは見込んでおく。この種の番号を拒むサービスはあるし、その拒否自体が、そのサービスがどれだけの身元を要求しているかという情報になる。
自国の行が許すなら、端の層を持っておく。 義務のない国では、現金で買ったプリペイド SIM はいまも合法で、一回きりの認証をこなす手段としては、いまも最も身元の絡まない選択肢だ——FCC の提案は、まだ可決されていない。義務のある国での正直な第4層は、番号なしである。メールの経路、ウォレットの経路、あるいは立ち去ることを選ぶ。携帯会社に嘘をつくこと、法律上の本人確認をすり抜けること——この二つを私は勧めない。登録義務のある国では、それ自体が犯罪になりうるし、このサイトは法的リスクの博打を勧めない。

支払いについて、短く二点。VoIP 層の支払いには、できる限りマスクカードかプリペイドカードを使うこと。実名のカードで請求されるプライバシー番号は、調べる側に書類を一枚余分にめくらせるだけで、遮断にはならないからだ。そして、主義として KYC なしの Bitcoin をすでに持っているなら、JMP.chat はそれを受け付ける数少ない番号サービスの一つだ。

脅威モデルに、番号を合わせる
#

戦略は、名指しできる敵があってはじめて意味を持つ。大半の読者は、次の4つのどれかに当てはまる——自分のものを選べば、先の表は具体的な二、三手まで絞り込める。

脅威	突いてくるもの	あなたの手
データブローカー／マーケター	サービス横断の名寄せの鍵としての番号	第3層をどこでも使う。金庫の番号はフォームに書かない
漏えいデータ+認証情報の攻撃者	SMS コード、使い回された識別子	金庫のアカウントに認証アプリ／パスキー。携帯会社に PIN
特定の人物——ストーカー、元交際相手、嫌がらせの加害者	人物検索サイト、CNAM、共有してきた過去	番号を隠した新しい第2層。データブローカーへの削除請求。第1層はほぼ誰にも教えない
資金の潤沢な相手／国家級	SS7 での位置特定、通信会社の記録、登録データ	持ち歩く番号はどれも位置的に安全ではない。端末ごと分ける——活動家の安全公開プロトコルを参照

私はこの記事を、ストーカーの行にいる読者のために書いている。FCC への意見書の記録は、この規制の核心を言い当てた。生存者のネットワークは、現金で買った電話と秘匿された住所を「命を守る安全の実践」と呼び、まさにその振る舞いこそ、KYC の体制が「疑わしい」と旗を立てるものだ。あなたの脅威が、あなたの名前を知っている特定の人物なら、危険なのは、相手がすでに知っている金庫の番号のほうである。相手が一度も見たことのない番号を、番号の照会に答えないメッセンジャーの上に置くこと——それは、どれだけブロックを積み上げるよりも価値がある。

効かない手
#

思い込みを崩すことは、それ自体が防御の一層だ。次の4つの誤解は、現実の金と現実の安全を、実際に損なってきた。

「burner アプリ（使い捨て番号アプリ）を使えば匿名だ」。 VoIP 番号が隠すのは、通話相手から見たあなたの携帯番号だ。アプリ本体からは隠れられない。アプリはあなたの支払い方法も、IP アドレスも、多くの場合は連絡先一覧も知っている。しかもサービス側が回線種別を照会した瞬間、その番号は通らない。有用な区画ではあるが、隠れ蓑ではない。
「番号を変えればいい」。 古い番号は、あなたが触れてきたすべてのブローカーのデータベース、漏えいデータ、CNAM の記録に残り続ける。そして新しい番号は、同じ配り方をした瞬間から、同じ蓄積を始める。役割を分けないままの番号変更は、何もリセットしない。
「プリペイドは匿名だ」。 157か国では、購入のその場で身分証にひも付けて登録される。義務のない国でも、購入は支払い記録と店の防犯カメラ映像を残すし、FCC はその隙間ごと閉じる提案をしている。現金のプリペイドは購入時点でひも付いていないだけであって、使っている間まで追跡できないわけではない——先に見た SS7 の調査結果は、どの SIM にも等しく当てはまる。
「SMS の二要素認証でも、ないよりましだ」。 正しい。そして同時に、調査対象になった140超のサイトのうち17件を、番号だけで乗っ取り可能にした当の仕組みでもある。認証アプリかパスキーが使える場所では、SMS は予備の鍵ではない——攻撃の入り口だ。

結論——あなたに合う構成はどれか
#

今日ひとつだけやるなら：携帯会社で port-out PIN を設定し、認証アプリで置き換えられるすべてのアカウントから実番号を外すこと。その1時間で、昨年の米国に2,600万ドルの報告損失を生んだ SIM swap の通り道が閉じる。

フルの構成でやるなら：銀行と行政には金庫の番号を。人間には Signal のユーザー名を。アカウントには VoIP 番号を1本。そして——自国の行が許すなら——端には現金で買ったプリペイドを。番号を使う前に、サービスの側を確かめること。Claude（携帯会社で確認済みの番号、例外なし）と、ウォレット認証で通る Venice のようなサービスの差は、同じ製品カテゴリの中に並ぶ、恒久的な身元のひも付けと、ひも付けゼロの差だ。

そして、暦から目を離さないこと。FCC の意見募集は2026年7月27日に閉じる。日本のデータ通信専用 SIM への拡大は、2027年5月までに効いてくる。上の国別表の各行には、それぞれの確認日が付いている。2026年の番号プライバシーは、一度買えば済む品物ではない。維持し続ける構造だ。

要点

電話番号は身元を束ねる識別子になった： SIM swap の被害届982件・損失2,598万ドル（FBI IC3、2024年）。Princeton の実験では SIM swap の成功率78%（50回中39回）、対象になった140超のサイトのうち17件が番号だけで乗っ取り可能だった（2020年）。
挟み撃ちは現実で、両側から来る： 157か国が SIM 登録を義務化、うち14か国は生体情報つき（Privacy International、2021年）。2026年の FCC 提案（CG 17-59）は米国に KYC と4年保存を加えようとし、Claude は VoIP 番号をはっきり拒み、Google Voice は政府発行の身分証を要求するようになった（2026年1月）。
4つの番号に、4つの仕事： 金庫（携帯会社+port-out PIN）、対人（Signal のユーザー名、2024年2月から番号を隠せる）、アカウント（VoIP：MySudo／Hushed／JMP.chat）、端（適法な国では現金プリペイド——または番号なし）。
まず自分の行、次にサービス： SIM の法律は国ごとに違う（表参照、行ごとに出典つき）。同じカテゴリの中でも、電話必須（Claude）からウォレット認証（Venice）まで幅がある——番号を渡す前に確かめる。
効かないもの： burner アプリの「匿名性」、役割分離なしの番号変更、「プリペイド=追跡不能」の思い込み（SS7 はどの SIM も追う）、そしてパスキーが使える場所での SMS 二要素認証。

よくある質問
#

VoIP 番号があれば、身元は隠せますか？
#

区画は作れますが、匿名にはなりません。VoIP 番号は、店やアプリにあなたの携帯番号を知られないようにしてくれます。しかし VoIP 事業者は、あなたの支払い方法と IP アドレスを知っていますし、サービス側は Twilio のような照会 API で回線種別を検出して拒否できます。Claude が実際にそうしています。VoIP はアカウント層に使い、それだけを唯一の防壁にしないでください。

使い捨て携帯（burner phone）は2026年、違法ですか？
#

米国では違法ではありません——プリペイド SIM への連邦レベルの身分証要件は現時点で存在せず、ただし FCC の2026年提案（意見募集は2026年7月27日まで）が通れば、それが変わります。登録義務のある157か国では、プリペイド SIM は合法ですが、購入時に身元とひも付きます。偽の身元で買うことは、それ自体が犯罪になりえます。上の表で、自国の行とその出典を確かめてください。

Signal はいまも電話番号を要求しますか？
#

はい——登録には電話番号が必要で、これは2024年2月のユーザー名導入後も変わっていません。変わったのは露出のほうです。ユーザー名を作り、「電話番号であなたを見つけられる人」を「なし」に設定すれば、他の利用者に番号は見えません。金庫か VoIP の番号で一度だけ登録し、あとはユーザー名だけを渡してください。

FCC の提案が法律になったら、何が起きますか？
#

プリペイドを含む米国のすべての事業者が、氏名・居住住所・政府発行の身分証番号・予備の電話番号を収集し、解約後も4年間保存することになります。DV 被害者の支援団体は FCC に対し、この制度は生存者の安全策を危険信号に変えてしまうと述べました。可決されれば、米国は縮み続ける「義務なし」の側——2021年時点で34か国、2026年1月にメキシコが離脱——から外れ、戦略の第4層はプリペイドから「番号なし」の経路へ移ります。

いっそ番号を新しくして、やり直すべきですか？
#

役割分離とセットで行う場合だけ、そして脅威が「古い番号を知っている特定の人物」である場合だけです。古い番号はブローカーのデータベースと漏えいデータに永久に残りますし、新しい番号を古いやり方——一つの番号をすべてに——で使えば、数か月で同じプロフィールが組み上がります。変えるべきは番号ではなく、構造です。

出典
#

#	出典	URL	アーカイブ
1	FCC——「Enhancing Know-Your-Customer Requirements」FNPRM CG 17-59（Federal Register、2026年5月26日）	https://www.federalregister.gov/documents/2026/05/26/2026-10407/enhancing-know-your-customer-requirements	https://web.archive.org/web/*/https://www.federalregister.gov/documents/2026/05/26/2026-10407/enhancing-know-your-customer-requirements
2	Ars Technica——FCC の身分証義務化案は匿名プリペイド携帯を締め出しうる（NNEDV 意見書の引用、2026年6月24日）	https://arstechnica.com/tech-policy/2026/06/fcc-plans-id-mandate-that-could-block-anonymous-use-of-prepaid-burner-phones/	https://web.archive.org/web/*/https://arstechnica.com/tech-policy/2026/06/fcc-plans-id-mandate-that-could-block-anonymous-use-of-prepaid-burner-phones/
3	Privacy International——SIM カード登録法のタイムライン（2021年調査）	https://privacyinternational.org/long-read/3018/timeline-sim-card-registration-laws	https://web.archive.org/web/*/https://privacyinternational.org/long-read/3018/timeline-sim-card-registration-laws
4	FBI IC3——2024年インターネット犯罪報告書（SIM swap：982件、$25,983,946）	https://www.ic3.gov/AnnualReport/Reports/2024_IC3Report.pdf	https://web.archive.org/web/*/https://www.ic3.gov/AnnualReport/Reports/2024_IC3Report.pdf
5	Lee ほか、Princeton——「An Empirical Study of Wireless Carrier Authentication for SIM Swaps」（2020年）	https://collaborate.princeton.edu/en/publications/an-empirical-study-of-wireless-carrier-authentication-for-sim-swa	https://web.archive.org/web/*/https://collaborate.princeton.edu/en/publications/an-empirical-study-of-wireless-carrier-authentication-for-sim-swa
6	Signal——「Keep your phone number private with Signal usernames」（2024年2月20日）	https://signal.org/blog/phone-number-privacy-usernames/	https://web.archive.org/web/*/https://signal.org/blog/phone-number-privacy-usernames/
7	Anthropic——電話番号を確認する方法（ヘルプセンター、2026年7月確認）	https://support.claude.com/en/articles/8287232-verify-your-phone-number	https://web.archive.org/web/*/https://support.claude.com/en/articles/8287232-verify-your-phone-number
8	Google Voice——番号の取得前に本人確認が必須に（2026年1月30日発効）	https://support.google.com/voice/community-guide/405972015/identity-verification-now-required-before-you-can-claim-a-google-voice-number	https://web.archive.org/web/*/https://support.google.com/voice/community-guide/405972015/identity-verification-now-required-before-you-can-claim-a-google-voice-number
9	Twilio——Lookup v2：Line Type Intelligence（12種類の回線種別）	https://www.twilio.com/docs/lookup/v2-api/line-type-intelligence	https://web.archive.org/web/*/https://www.twilio.com/docs/lookup/v2-api/line-type-intelligence
10	TechCrunch——監視ベンダーが新型 SS7 攻撃で携帯電話の位置を追跡していた（2025年7月18日）	https://techcrunch.com/2025/07/18/a-surveillance-vendor-was-caught-exploiting-a-new-ss7-attack-to-track-peoples-phone-locations/	https://web.archive.org/web/*/https://techcrunch.com/2025/07/18/a-surveillance-vendor-was-caught-exploiting-a-new-ss7-attack-to-track-peoples-phone-locations/
11	Bundesnetzagentur——プリペイド SIM の本人確認要件（TKG=ドイツ電気通信法、2017年から）	https://www.bundesnetzagentur.de/DE/Fachthemen/Telekommunikation/OeffentlicheSicherheit/IdentverfahrenPrepaid/start.html	https://web.archive.org/web/*/https://www.bundesnetzagentur.de/DE/Fachthemen/Telekommunikation/OeffentlicheSicherheit/IdentverfahrenPrepaid/start.html
12	BOE——Ley 25/2007 データ保全法（スペイン、SIM 登録）	https://www.boe.es/buscar/act.php?id=BOE-A-2007-18243	https://web.archive.org/web/*/https://www.boe.es/buscar/act.php?id=BOE-A-2007-18243
13	e-Gov 法令検索——携帯電話不正利用防止法（2026年改正の文脈）	https://elaws.e-gov.go.jp/document?lawid=417AC0000000031	https://web.archive.org/web/*/https://elaws.e-gov.go.jp/document?lawid=417AC0000000031
14	Infobae——CURP による携帯電話登録：期限と回線停止（メキシコ、2026年6月）	https://www.infobae.com/mexico/2026/06/15/registro-de-celular-con-curp-gobierno-aclara-que-no-existe-padron-nacional-de-telefonia-movil/	https://web.archive.org/web/*/https://www.infobae.com/mexico/2026/06/15/registro-de-celular-con-curp-gobierno-aclara-que-no-existe-padron-nacional-de-telefonia-movil/

Cora Aegis は、Bitcoin プライバシー・自己管理・デジタル主権について仮名で書いている——その選択の理由は、この記事自体が語っているはずだ。統計はすべて上の出典に対応づけてある。国別表には、行ごとの出典と確認日が付く。訂正はこちらへ：cora@cypherpunkguide.com。

パスキーの復旧——Google・Apple・Microsoft・GitHubを比較（2026年）

Sat, 01 Aug 2026 00:00:00 +0000

資金について：CypherpunkGuideは監視型広告を一切載せない——広告ネットワークも、トラッキングピクセルも、スポンサー記事もない。運営は透明な収益源による。現在は読者からの寄付、将来は購読と編集方針に合致したアフィリエイト。私たちは広告主ではなく、読者に向き合う。

普段のログインだけを見れば、パスキーはすでに成果を出している。FIDO Allianceの2025年版Passkey Indexによると、ログイン成功率はパスキーが93%、その他の方式が63%。平均所要時間も8.5秒で、その他の方式の31.2秒を大きく下回った。フィッシングにも強い。利用者が入力する使い回し可能な秘密情報そのものがないため、偽サイトに盗み取られないからだ。

難しさが表れるのは、普段のログインではなく復旧時だ。通常のログインでは優れた認証情報でも、その背後にある電話番号、メールアカウント、クラウド事業者、信頼済み端末、紙のコードに依存しているかもしれない。私は2026年8月1日、Google、Apple、Microsoft、GitHub、FIDO、NISTの公式資料または一次資料25件を確認し、各社に同じ故障条件を当てはめた。毎日使うスマートフォン、パソコン、持ち歩くハードウェアキーを失い、別の場所に保管した復旧手段だけが残っているという条件だ。見えてきたのは、一つの「パスキー復旧」ではない。永久に締め出される条件がそれぞれ異なる、二段階または三段階の復旧だった。

したがって、問うべきは「パスキーはSMSによる二要素認証（2FA、パスワードに加えて別の証明を求める仕組み）より安全か」だけではない。フィッシングへの強さでは、パスキーが勝る。だが本当に確かめるべきなのは、同じ失った端末へ戻ることなく、パスキーを保管する側とそのパスキーを受け入れるアカウントの両方を復旧できるかだ。この記事では依存関係を整理し、検索結果に混じり始めたMicrosoft個人アカウントと企業向けEntraの混同を正したうえで、復旧を先に準備する移行手順を示す。読みながら最後のログイン手段を削除してはいけない。

パスキーの復旧には、別々の二つの復旧がある
#

パスキーの復旧には、認証情報プロバイダーからパスキーを戻す方法と、利用先のアカウントを取り戻して新しいパスキーを登録する方法がある。担当する会社が異なるため、一方に成功しても、もう一方まで復旧できるとは限らない。

パスキーとは、特定のウェブサイトやアプリで使う暗号学的な認証情報である。ウェブサイトは公開鍵を持ち、端末または認証情報の管理ソフトは秘密鍵を持つ。パスキーが使うウェブ標準のWebAuthnは、その鍵を正規サイトのドメインに結びつける。NIST SP 800-63B-4が、適切に設定されたWebAuthnをフィッシング耐性ありとし、人が入力するワンタイムコードを耐性なしとするのはこのためだ。

一度のログインの背後には、二つの役割がある。

認証情報プロバイダーは、パスキーを保存または同期する側だ。iCloudキーチェーンを使うAppleの「パスワード」、Google パスワードマネージャー、Microsoft Password Manager、第三者のパスワードマネージャー、Windows Hello、物理セキュリティキーがこの役割を担う。
利用先サービスは、そのパスキーを受け入れるウェブサイトやアプリである。GitHubは利用先サービスだ。GoogleやMicrosoftは、自社アカウント用のパスキーを自社に保存する場合、保管元と利用先の両方になりうる。

今回の資料監査で最初に分かったのは、この役割の違いだ。Apple、Google、Microsoft、GitHubを同じ性質の4列として並べる比較は多い。実際には、ここでのAppleは主に認証情報プロバイダーであり、GitHubは主に利用先サービスである。端末を失ったあと、この違いが効いてくる。

認証情報または経路	秘密情報の保管場所	端末を1台失っても残るか	毎日使う端末をすべて失った場合	主なリスク
同期型パスキー	エンドツーエンド暗号化された認証情報の管理ソフト	別の端末ですでにログイン済みなら、通常は残る	プロバイダーのアカウントを復旧し、暗号鍵を戻すための確認を通す	同期型パスキーの復旧がプロバイダーのアカウントに依存する
端末固定型パスキー	1台のスマートフォン、パソコン、または物理キー	そのパスキーは戻らない。別の認証手段があればアカウントは残りうる	別の経路で利用先アカウントを復旧し、新しいパスキーを登録する	認証情報そのものを永久に失う
復旧コード	紙またはオフラインの安全な保管場所	残る	1回限りのコード、または長い復旧コードを入力する	盗難、紛失、日常端末と同じ場所への保管
メールまたは電話による復旧	別のアカウントまたは携帯電話会社	場合による	先にその連絡経路を復旧する	フィッシング、SIM swap、共通原因による同時喪失

FIDOの同期型パスキー導入資料も、この条件を曖昧にしていない。同期すれば端末喪失に耐えやすくなるが、プロバイダーへのアクセスを失ったり、復元時の確認を通せなかったりすることはある。「同期済み」とは、保護された複製が存在するという意味だ。プロバイダーが必ず返してくれるという保証ではない。

毎日使う端末をすべて失ったら、何が起きるか
#

毎日使う端末をすべて失った場合、同期型パスキーを戻せるかは認証情報プロバイダー次第である。端末固定型パスキーは戻らない。利用先のアカウントを守るのは、別の場所に残した復旧手段だけだ。

この条件を4つの環境へ適用した結果は、ダウンロードできるパスキー復旧監査に残した。これは文書の監査であり、実際のアカウントを締め出す実験ではない。私は稼働中のアカウントから認証手段を削除していないし、読者も再現のためだけに削除すべきではない。

比較対象は、自分で管理する個人アカウントに限った。Google Workspace、Managed Apple Account、GitHub Enterprise Managed Users、Microsoft Entra IDのように、管理者または組織のIDプロバイダーが管理するアカウントには組織固有の規則があるため、この表の対象外だ。後でEntraの日付に触れるのは、検索結果にある個人向けと企業向けの混同を正すためだけである。

環境	この監査での役割	同期型パスキーの復元	文書にあるプロバイダー／アカウント復旧の仕組み	日常端末を失っても復旧できる条件	失敗／永久締め出しの境界
Google個人アカウント	プロバイダーと利用先の両方	Googleアカウントに加え、Google パスワードマネージャーのPINまたは条件を満たす使用済み端末	プロバイダー／Googleアカウント：復旧情報。条件を満たす個人アカウントでは復旧用の連絡先も追加できる	失った端末とは独立した復旧経路または連絡先に、少なくとも一つアクセスできる	パスワードマネージャーのPINを復旧できず、そのコレクションの全パスキーをリセットする。利用先ごとに別の復旧が必要になる
Apple個人アカウント	主にプロバイダー	Apple Accountの確認を使うiCloudキーチェーンの安全な復旧	プロバイダー／Apple Account：標準のアカウント復旧、登録済みの復旧用連絡先、または任意で設定した復旧キー	信頼済み電話番号を取り戻せる、または事前登録した連絡先か28文字のキーが失った端末の外にある	復旧キーを有効にしたのに、信頼済み端末も28文字のキーもなく、Advanced Data Protectionで別途設定され、復旧キーと併用できる復旧用連絡先も使えない
Microsoft個人アカウント	プロバイダーと利用先の両方	同期先のプロバイダーへログインして復元。Windows Helloや物理セキュリティキーなら端末固定型の場合がある	プロバイダー／Microsoftアカウント：代替のセキュリティ情報、または25桁の復旧コード	代替経路へアクセスできる、または25桁のコードをオフラインに保管してある	2段階認証が有効で代替手段がない。Microsoftはサポートでも回避できないとしている
GitHub個人アカウント	主に利用先サービス	同期型ならパスキーのプロバイダーが復元する。GitHubは秘密鍵を保有しない	利用先の個人アカウント： 16個の1回限りのコード、別のパスキー／セキュリティキー、SSHキー、personal access token（PAT）、確認済み端末	オフラインのコードか別に保管した認証手段が残る。SSH、PAT、確認済み端末は、残っており、かつGitHubが復旧用と認めた場合だけ使える	パスキーも、GitHubが受け付ける復旧手段もない。GitHub Supportはアクセスを復元できない

表からは、もう一つの問題も見える。「パスキーを使っている」だけでは、どこに保存されたか分からない。Windowsの案内で作った認証情報が、あるときは1台のWindows Helloに、別のときは同期型のパスワードマネージャーに保存されることがある。QRコードを使う操作も、その場だけスマートフォンを借りる場合と、スマートフォンに認証情報を保存する場合がある。復旧を考える前に、利用先サイトのパスキー一覧と、プロバイダー側の認証情報一覧を開こう。サイト名だけでなく、プロバイダーと端末を記録する必要がある。

4つの環境の復旧経路を個別に見る
#

4つの環境はいずれも、安全にパスキーを使える仕組みは持っている。締め出しを避けられるかは、保存場所、プロバイダーアカウントの復旧、日常端末の外にある予備手段で決まる。

Google個人アカウント——パスワードマネージャーのPINを確認する
#

Google パスワードマネージャーは、Android、Chrome、iPhone、iPadの間でパスキーを同期できる。パソコン、iPhone、iPadで初めてパスキーを作ると、Google パスワードマネージャー専用のPINが作成される場合がある。GoogleのPINに関する資料によると、このPINは新しい端末でパスキーのロックを解除するために使われ、暗号化されたデータをGoogle自身が読めない状態に保つ。

個人のGoogleアカウントへパスキーを追加しても、既存のパスワード、復旧情報、ほかの認証手段が自動で消えるわけではない。Googleアカウントのパスキー案内では、パスキーがログイン時の第2段階も満たせると説明している。つまり、日常のログインは一つのパスキーで済む一方、明示的に削除しない限り、以前の手段は復旧用に残る。

厳しい境界は、PINを忘れた場合だ。Googleは、Google パスワードマネージャーのパスキーを以前使ったAndroid以外の端末からPINをリセットできるとしている。条件を満たす端末をすべて試しても復旧できない場合、資料に示された代替手段は**「パスキーをリセット」**である。これはGoogle パスワードマネージャー内のパスキーをすべて削除する操作であり、各ウェブサイトが新しいパスキーを自動発行する操作ではない。利用先のアカウントを一つずつ復旧し、登録し直すことになる。

多くの解説が一つにまとめる二つの経路を、私は分けて記録した。Googleのアカウント復旧手続きはGmailとGoogleアカウントへのアクセスを戻す。パスワードマネージャーの復旧は、暗号化されたパスキーの集合を開けるようにする。アカウントを取り戻しても、それだけで暗号化された集合を開けるとは限らない。2段階認証で締め出された場合、Googleの問題解決ガイドは、一部の審査に3〜5営業日かかるとしている。Googleは2025年、条件を満たす個人アカウント向けにRecovery Contactsを導入した。ただし利用資格と展開状況に左右されるため、全員が使える保証ではなく追加の選択肢として扱うべきだ。

Apple個人アカウント——iCloudキーチェーンの復旧には条件がある
#

AppleはiCloudキーチェーンを、パスワードとパスキーをエンドツーエンド暗号化して同期する仕組みとして設計した。Appleのサーバーは、読める形の記録を保持せずに暗号化済みデータを転送する。Apple Platform Securityは、利用者の端末すべてへアクセスできない場合にも、キーチェーンを復旧できるよう設計されていると明記している。「iCloudにある」という説明だけでは分からない復旧範囲を、より正確に示している。

ただし無条件ではない。Appleのパスキーのセキュリティに関するページによると、全端末を失った場合の復旧では、Apple Accountのパスワード、登録した電話番号へのSMS、端末のパスコードが必要になることがある。復旧用の暗号データを預かるエスクローサービスで試せる認証は10回までで、10回目に失敗するとエスクロー記録が破棄される。「全端末を失っても復旧できる」は、用意された経路の説明であって、回数制限のない保証ではない。

キーチェーンの復旧もApple Accountに依存する。標準の手続きでは、アカウント情報、信頼済み電話番号、端末のパスコード、時間をかけたアカウント復旧が使われる。復旧用連絡先は6桁のコードを発行でき、最大5人まで登録できる。連絡先はアカウントの中身を読めず、本人確認の復旧を手伝うだけだ。

Appleは、アカウント復旧に数日以上かかることがあり、サポートでも待ち時間を短縮できないとしている。当日中の緊急アクセスではなく、最後の経路として扱う必要がある。

任意の復旧キーには、特に強い警告が要る。Appleの復旧キーに関する資料では、28文字のキーを有効にすると標準のアカウント復旧が無効になる。Advanced Data Protection（高度なデータ保護）では復旧キーと復旧用連絡先を併用でき、どちらかでアクセスを取り戻せる場合がある。それでも、アカウントのパスワードが分からず、信頼済み端末がなく、キーを提示できず、設定済みの連絡先も使えなければ、永久に締め出される可能性がある。復旧キーで自分の管理権を強められるのは、守る対象の外に保管した場合だけだ。Apple Notes、iCloud Drive、「パスワード」アプリへ置けば、復旧に必要なものが復旧対象の中に閉じ込められる。Appleも、そうした場所へ保存しないよう警告している。

Apple Accountの物理セキュリティキーは、iCloudで同期するパスキーとは別の機能である。Appleは物理キーを最低2本、最大6本まで登録できるとしている。セキュリティキーの案内には、信頼済み端末と登録したキーをすべて失えば、アカウントから永久に締め出される可能性があるという警告もある。予備キーは、事前に登録し、動作を確かめ、日常端末とは別の場所に置いて初めて役に立つ。

Microsoft——個人アカウントとEntraの廃止日程を混同しない
#

Microsoftは同期型と端末固定型の両方のパスキーに対応する。個人向けパスキー案内では、同期型は認証情報の管理ソフトを通じて復元でき、端末固定型は別の認証手段がなければ端末とともに失われると説明している。Microsoft Password Managerは個人用Edgeプロファイル向けに展開中だが、Windows Helloと物理セキュリティキーは端末内だけに残る場合がある。

「Microsoftは2026年9月にSMSを廃止する」という見出しは、助言を誤らせかねないため、Microsoftの資料まで戻って確かめた。2026年9月1日からの展開は、組織が管理するディレクトリであるEntra IDテナント向けの方針だ。SMSまたは音声認証がすでに有効な利用者は、パスキー登録の対象として自動的に有効化され、登録を促される。テナント管理者は一時的にオプトアウトできるが、Microsoftが提供するEntraのSMS・音声配信は2027年2月1日に終了する。Microsoftは別に、個人アカウント向けSMSコードを段階的に廃止するとも説明している。ただし個人向けページに、2026年9月を全員共通の期限とする記載はない。二つを同じ日程として扱うと、個人利用者に存在しない期限で認証手段を外させることになる。

個人アカウントの復旧には別の厳しい境界がある。2段階認証を有効にした状態で代替の確認手段へ一つもアクセスできない場合、通常のアカウント復旧フォームもサポートも助けにならないとMicrosoftは復旧フォームの案内で説明している。一方、Microsoftは事前に生成する25桁の復旧コードを用意している。復旧コードの案内によると、2段階認証を有効にした状態でセキュリティ情報を変更すると、反映に30日かかることがある。コードを作って保管するのは、パスキーの端末を失ったあとではなく、危機の前である。

GitHub個人アカウント——手段は多いが、サポートによる例外はない
#

ここで扱うのは、認証情報を自分で管理する個人アカウントだ。GitHubのパスキー資料は、この復旧方法を企業が管理するアカウントへ広げていない。個人アカウントでは、ブラウザでのログイン時に一つのパスキーがパスワードと2FAの両方を満たす。同期型パスキーを戻すのは、その秘密鍵を保存したApple、Google、Microsoft、その他のプロバイダーである。GitHubのパスキー管理ページも、同期済みの認証情報はプロバイダーを通じて復旧するよう案内している。端末固定型のセキュリティキーは、GitHubの一覧に残っていても復元可能にはならない。

GitHubは、その先の復旧手段も明確にしている。復旧方法の資料では、16個の1回限りの復旧コードを発行する。SSHキー（Git操作やサーバー接続で使う暗号鍵）、personal access token（PAT、パスワードの代わりにAPIなどで使う個人用トークン）、確認済み端末も候補になりうる。ただし、以前使えた手段でも復旧に使えない場合がある。たとえば、長く使われていないSSHキーは対象外になることがあるため、使えると決めつけず、状態を確かめる必要がある。GitHubが認める確認済み端末またはSSHキーを使った復旧申請には、最大3営業日かかることがある。

最後の境界は明快だ。個人アカウントで認証情報と復旧手段をすべて失った場合、GitHub Supportは2FAアカウントを復元できない。認証情報を失った場合の案内は、その喪失を永久的なものとしている。パスキーを日常のログインにする前に、コードをオフラインへ保存し、複数の手段を登録すべきだ。

復旧の逆説——強いログインを、弱い予備経路が支える
#

復旧の逆説とは、フィッシングに強いログインを、より弱い復旧経路が支える状態である。攻撃者はパスキーではなく、それを置き換えられるメール、電話、サポート手続き、クラウドアカウントを狙える。

だからといって、パスキーが誤りなのではない。復旧の仕組みも認証の一部であり、後ろに付く事務手続きではないということだ。NISTの復旧ガイダンスは、アカウント復旧を認証手段の管理イベントとして扱い、アカウントの保証水準に合う復旧方法を求めている。1回限りの復旧コードは、日常端末から独立させられる点で役立つ。それでも偽サイトに入力すれば、フィッシングには耐えない。

復旧経路	失った端末から独立しているか	フィッシングに強いか	向く用途	強化する方法
オフラインの復旧コード	端末外に保管すれば、はい	いいえ	緊急時のアクセス	紙または暗号化したオフラインの複製。クラウドだけに置かない
2本目の物理セキュリティキー	別の場所に置けば、はい	はい	重要アカウント	2本を登録して両方を確認し、1本は別の場所へ保管する
同じプロバイダー内の同期型パスキー	一部のみ	ログイン時は、はい	日常利用と端末1台の喪失	プロバイダーの復旧を強化し、外部の手段も残す
復旧用メール	別アカウントなら、はい	それ自体は、いいえ	広く使えるアカウント復旧	別のプロバイダー、パスキー、独立した復旧手段を使う
電話／SMSによる復旧	電話サービスが残れば、はい	いいえ	互換性のための最後の経路	携帯電話会社に暗証番号を設定し、電話番号の脅威モデルで露出を減らす
復旧用連絡先	本人とその端末が使えれば、はい	それ自体は、いいえ	Appleまたは条件を満たすGoogleアカウントの復旧	慎重に選び、連絡方法と本人確認の手順を確認する

パスキーの持ち出しと移行は改善しているが、将来の約束を前提に設計してはいけない。FIDOは2026年3月、安全に認証情報を出し入れするためのCredential Exchange Format Proposed Standardを公開した。提案標準が公開されたことは、利用中のプロバイダーが現在すべてのパスキー転送に対応している証拠ではない。別のプロバイダーへ移せると見込む前に、移行元と移行先の両方で、実際のエクスポートとインポート機能を確かめる必要がある。

プライバシー上のトレードオフも明快だ。同期は端末1台の喪失に強い代わりに、復旧をクラウドアカウントへ集中させる。端末固定型のキーはプロバイダーへの依存を減らす代わりに、物理的な紛失の代償を大きくする。自分で運用することと、管理画面の向こうへ信頼を移しただけの状態を分ける点は、主権を5層で点検する方法と同じだ。標語ではなく、想定する相手と起こりうる故障を具体的に決めて選ぶべきである。

復旧を先にする移行手順
#

安全な移行は復旧の準備から始まる。保存場所を棚卸しし、プロバイダーの外に予備手段を作り、壊さずに確認してからSMSやパスワードの優先度を下げる。

アカウントとプロバイダーを分けて書く。 単に「GitHub——パスキー」ではなく、「GitHub——Google パスワードマネージャー」と記録する。同期型、端末固定型、不明のどれかも付ける。不明なら、まだ何も削除しない。
最初にプロバイダーのアカウントを守る。 同期型パスキーを戻すには、利用する認証情報プロバイダーのアカウントを復旧し、暗号鍵を開けるための確認を通せなければならない。復旧用メール、信頼済み電話番号、復旧用連絡先、独立した認証手段を更新する。AI時代の脅威モデルと同じく、先に敵を決めて備える。
そのプロバイダーの外に、復旧経路を一つ作る。 サービスに応じて、印刷した復旧コード、別の場所に置く2本目の物理キー、または別端末に秘密鍵か動作確認済みのバックアップがあり、利用先が復旧用として現在も受け付けるSSHキーを使う。唯一の複製を、守る対象と同じクラウドアカウントへ置かない。
何も壊さずに試す。 ブラウザのプライベートウィンドウか別プロファイルでログインを始め、予備手段が選択肢に出ることを確認する。可能なら、状態を見るだけの非破壊的な確認を使う。1回限りのコードを使った場合は使用済みと記録し、直ちに補充するか、保管中の一式を再生成する。訓練のためだけに完全なアカウント復旧を始めたり、主パスキーを削除したり、端末を消去したり、信頼済みセッションすべてからログアウトしたりしない。
復元手順をオフラインへ記録する。 プロバイダー名、利用先アカウント、予備手段の保管場所、公式の復旧URLを含める。Bitcoinを初めて保有した後の復旧訓練と同じで、試していないバックアップは、効くという思い込みにすぎない。
古い手段の優先度は、アカウントごとに一つずつ下げる。 日常のログインではパスキーを優先する。独立した経路に成功し、サービスが復旧に電話番号を要求しないことを確かめてから、SMSを外す。スマートフォン、パスワードマネージャー、Apple／Google／Microsoftアカウント、セキュリティキーを変更したら、もう一度確認する。

順序を逆にしてはいけない。SMSを先に外し、「予備は後で追加する」と考えると、その間のスマートフォンの紛失、画面の破損、キーの紛失、保存先の選択ミスが永久の締め出しに変わりうる。セキュリティ対策は、同時に失う経路を減らすために行うもので、自分で増やすためではない。

結論——SMSをいま置き換えるべきか
#

日常のログインにはパスキーを使え。ただし、別の復旧経路を新しいブラウザで安全に確認できるまで、SMSの優先度を下げるな。フィッシングに強いログインと、一つの端末やクラウドアカウントに依存しない復旧を組み合わせよ。

通常のログインについては、根拠がそろっている。先に挙げたFIDOのデータと、Googleが2024年に報告した4億アカウント、10億回超の認証、ログイン時間50%短縮は、通常利用の結果である。端末を失ったあとの復旧を測った数字ではないことも忘れてはいけない。

端末喪失時の復旧は、一つの製品機能にまとまっていない。Google パスワードマネージャーではPINが要る場合がある。Appleではアカウント復旧、復旧用連絡先、復旧キーのいずれかが関わる。Microsoft個人アカウントには代替のセキュリティ情報と25桁のコードがある。GitHubは復旧コードか、事前登録された別の証明に依存する。「クラウドにバックアップ済み」の一言では、これらの条件は分からない。

失えば最も困るアカウントから始めよ。プロバイダーと利用先を対応づけ、その両方の外に復旧手段を一つ置き、確かめてから次のアカウントへ進め。午後のうちにすべてのサービスで「パスキーを使う」を押すより時間はかかる。それでも、鞄を一つ失っただけで重要アカウントへまとめて戻れなくなる事態を避けながら、フィッシングへの強さを得られる。

要点

パスキーの復旧は二つに分かれる： 認証情報プロバイダーから戻す方法と、利用先アカウントを復旧して新しいパスキーを登録する方法は、同じ手続きではない。
通常のログインは改善している： FIDO Allianceの2025年版調査では、成功率はパスキーが93%、その他の方式が63%。平均時間は8.5秒対31.2秒だった。
同期で残るかどうかにも条件がある： プロバイダーのアカウントと暗号鍵の復旧確認を通せる場合だけ、端末喪失後に戻る。端末固定型には別の予備が要る。
各社の厳しい境界は異なる： Googleではリセットによりパスワードマネージャー内の全パスキーが削除される。Appleの28文字の復旧キーは標準復旧を無効にするが、Advanced Data Protectionでは設定済みの連絡先を併用できる場合がある。Microsoftの2段階認証にはサポートによる例外がなく、GitHubは16個の1回限りのコードを発行する。
安全性を決めるのは移行の順序だ： 棚卸し、プロバイダーの強化、外部の復旧経路、動作確認、手順の記録を済ませてから、アカウントごとにSMSの優先度を下げる。

よくある質問
#

パスキーはSMSによる二要素認証より安全ですか？
#

フィッシングへの強さでは、はい。WebAuthnのパスキーは正規サイトのドメインに結びつくため、偽サイトが再利用できるログイン秘密情報を集めることはできません。SMSコードは偽サイトへ入力してしまうことがあり、SIM swapのあとに傍受されることもあります。ただし復旧は別です。失ったパスキーを置き換えるためにSMSを受け付けるサービスなら、その復旧経路にはSMSのリスクが残ります。

スマートフォンを失うと、パスキーはどうなりますか？
#

同期型パスキーは、別の端末で認証情報の管理ソフトを復旧し、暗号化されたデータのロックを解除できれば戻る可能性があります。そのスマートフォンだけに保存した端末固定型パスキーは失われます。どちらの場合も、2つ目の認証手段か利用先サイトのアカウント復旧方法がなければ、スマートフォンなしでアクセスを取り戻せません。

Apple、Google、Microsoftは、同期したパスキーを読めますか？
#

各社の資料では、パスキーの集合はエンドツーエンド暗号化されるか、プロバイダーが読める形の秘密鍵を受け取らないよう保護されると説明されています。それでもプロバイダーへの依存がなくなるわけではありません。アカウント、同期サービス、復旧規則、暗号化された集合へのアクセスを制御するソフトウェアは、各社が運用しています。

パスキーを追加したら、パスワードとSMS用の番号を削除すべきですか？
#

すぐには削除しないでください。先に独立した復旧手段を追加し、何も消さずに新しいブラウザから確かめてください。その後、サービスが許す場合に限り、復旧経路が同じ端末やプロバイダーへ依存していないことを確認しながら、弱い手段をアカウントごとに外すか、優先度を下げます。

すべてのパスキーと復旧コードを失っても、サポートがアカウントを戻してくれますか？
#

戻せると決めつけてはいけません。GitHubは、受け付けられる復旧手段がなければ2FAアカウントを復元できないとしています。Microsoftも個人アカウントについて、2段階認証が有効で代替手段へアクセスできない場合、復旧フォームでは対応できないと説明しています。失う前に、独立した認証手段を用意してください。

出典
#

Cora Aegis

Cora Aegisは、CypherpunkGuideでプライバシーを最優先にしたOPSECの実践ガイドを書いている。この記事では、毎日使う端末を失っても別の場所の復旧手段は残るという同じ条件を4つの環境へ適用し、公式資料と一次資料25件を確認した。その結果を、復旧の依存関係が分かる表とダウンロード可能な監査データとして公開した。

Cora Aegisについて詳しく読む →

パスワードマネージャー移行——BitwardenとKeePassXCを比較（2026年）

Mon, 03 Aug 2026 00:00:00 +0000

資金について：CypherpunkGuideは監視型広告を一切載せない——広告ネットワークも、トラッキングピクセルも、スポンサー記事もない。現在は読者からの寄付で運営し、将来は購読と編集方針に沿うアフィリエイト収入も充てる。私たちは広告主ではなく、読者に向き合う。

ブラウザ内蔵のパスワードマネージャー（アカウントの秘密情報を保存し、ログイン画面へ入力するソフトウェア）自体が、ただちに危険というわけではない。NIST SP 800-63B-4は、利用者が強力でサービスごとに異なるパスワードを使いやすくなるよう、NISTに準拠する認証サービスにパスワードマネージャーと自動入力を認めることを求めている。移行する理由はもっと具体的である。何を誰から守るか、どの障害で締め出されるおそれがあるかを整理した脅威モデルによっては、一つのブラウザアカウントから独立した保管庫（vault、認証情報をまとめて守るデータ置き場）、複数ブラウザへの対応、別系統の復旧方法、または暗号化データベースを自分で管理できる仕組みが必要になる。

注意すべきなのは、製品名よりも移行作業そのものだ。私は2026年8月3日、Google検索の上位5件、本文を読めた競合記事4本（平均2,512語）、そしてChrome、Edge、Firefox、Bitwarden、KeePassXC、NIST、FIDOの移行・認証・認証情報交換に関する公式資料を確認した。Google AI Modeは、CSV（項目をカンマで区切る表形式のファイル）へ書き出し、読み込み、行数を比べてファイルを消すという、一見十分な3段階の回答をすでに返していた。しかし、その手順は肝心な失敗を見逃している。

そこで、架空の認証情報だけを入れた12件の保管庫を二つ作り、パスワードを表示しない監査ツールで比較した。両方とも12行だったが、一致したのは11件だけである。移行先では、移行元の認証情報が1件欠け、その代わりに別の認証情報が1件重複していた。照合率は91.7%、判定はHOLD。URL、ユーザー名、パスワード、秘密情報から作ったフィンガープリント（照合用の要約値）は一つも出力していない。この結果をもとに、移行手順を7段階に組み直した。ツールの使い方を覚えるときは架空データを使い、切り替え中は移行元の保管庫を残し、実際のパスワード書き出しファイルをオンライン変換サイトやAIアシスタントへ渡してはいけない。

問題は「ブラウザだから危険」ではない
#

パスワードマネージャーは、アカウントの秘密情報を保存して入力するソフトウェアである。「ブラウザなら危険、専用アプリなら安全」という分け方では足りない。信頼先、同期、復旧、締め出しの条件が、自分の脅威モデルに合う製品を選ぶ必要がある。

ブラウザに保存したパスワードも、各社が公開している端末とアカウントの保護機能で守られる。ただし、復旧方法や端末内で読める条件はブラウザごとに異なる。専用マネージャーへ移せば、同期の運用者、復旧方法、保管庫を共有できるブラウザと端末の範囲、自分で暗号化ファイルを管理するかどうかが変わる。一方で、侵害を受けたロック解除済み端末まで安全になるわけではない。どのマネージャーも、ログイン時には認証情報を使える状態にする必要があるからだ。

移行するなら、理由を具体的に決める。

ブラウザからの独立： 複数のブラウザを使っている。または、ブラウザを替えるたびに認証情報を移したくない。
復旧経路の分離： Google、Microsoft、Mozillaの同じアカウントに、閲覧データとパスワード復旧の両方を握らせたくない。
ローカルでの管理： 暗号化データベース、バックアップ、同期方法を自分で管理したい。
家族・チームでの共有： チャットやメールでパスワードを送らず、権限を管理できる共有機能を使いたい。
監査しやすさ： 認証情報の一覧や状態レポート、移行用の書き出しデータを使って、復旧計画を検証したい。

「ブラウザのパスワードはメモリ上で平文になる」という見出しだけで移行してはいけない。ロック解除済みのパソコンやスマートフォンでパスワードを使う以上、どこかでは復号される。保管庫の製品を替えても、マルウェア、画面キャプチャ、悪意ある拡張機能、端末への物理アクセスは残る。移行の目的は、特定の依存関係を減らすことだ。あらゆる攻撃を無効にすることではない。

パスキーも、パスワードとは別に棚卸しする必要がある。パスキーはウェブサイトごとに結びついた暗号学的な認証情報であり、CSVのパスワード行ではない。マネージャーを替える前に、パスキーの復旧手順を使い、どのパスキーが同期型か、端末固定型か、利用先サイトから復旧できるかを記録しておく。

BitwardenとKeePassXCは、どの失敗に備えるかで選ぶ
#

Bitwardenは、複数端末の自動同期と公式モバイルアプリを重視する人に向く。KeePassXCは、KDBX形式の暗号化データベースをローカルで管理したい人に向くが、同期、バックアップ、競合処理、復旧も自分の責任になる。

Bitwardenは、ウェブ版、ブラウザ拡張機能、デスクトップ版、モバイル版、コマンドライン版からブラウザデータを読み込める。ChromeとEdgeからのインポート手順によると、読み込んだデータはサーバーへ送信される前に端末内で暗号化される。サーバー側から見える情報を減らす設計だが、Bitwardenアカウント、利用端末、マスターパスワードの扱い、二つ目の認証要素、サービスの稼働状況は復旧経路に残る。

対応するデスクトップ版には、手動でCSVを書き出さず、互換性のあるChromium系ブラウザから直接読み込む機能もある。対象は公式サイトから入手したWindows版とmacOS版、Linux向けの単体実行形式AppImageであり、アプリストア版は対象外だ。Windowsでは、資料に記載されたbitwarden_chromium_import_helper.exeに対し、ユーザーアカウント制御（UAC、OSが管理者権限を確認する画面）やEDR（端末上の不審な動作を監視するセキュリティ製品）が警告を出すことがある。先にインストーラーと署名を確認し、自分で操作を開始せよ。予期しない確認画面が出たら、プロセス名だけを信じず中止せよ。

KeePassXCは、認証情報を暗号化されたKDBX形式のデータベースファイルへ保存し、独自のクラウド同期サービスを持たない。公式マニュアルでは、ファイルをローカルに置く方法と、自分で選んだ同期先へ置く方法を説明している。事業者の同期アカウントを必須にしない代わりに、ファイルの競合、バックアップ、端末外の複製、データベースを開く鍵の復旧を自分で運用しなければならない。

判断項目	Bitwarden	KeePassXC	備えるべき故障
同期方式	事業者が暗号化同期を運用	利用者がKDBXファイルと任意の外部同期を運用	サービス／アカウントの復旧、またはファイル喪失／同期競合
向く使い方	複数端末、モバイル利用、共有、手間の少ない運用	デスクトップ中心、ローカル管理、独自のバックアップ設計	利便性か自己管理の利点だけを見て、必要な運用負担を見落とすこと
移行時の読み込み	ブラウザ別CSV。対応環境では直接読み込み	CSVの列をプレビューし、項目を明示的に対応づけるウィザード	重複作成、または列の対応ミス
復旧で最後に頼るもの	アカウント情報、二つ目の認証要素、復旧計画	KDBXファイル、マスターキー、任意のキーファイル／ハードウェア認証、バックアップ	復旧に必要なものをすべて同じ端末へ置くこと
パスキーと時間ベースのワンタイムパスワード（TOTP、一定時間ごとに変わる認証コード）	機能の対応状況とプラン制限を別々に確認。ブラウザCSVだけではどちらも確認できない	機能の対応状況と利用先サイトとの互換性を別々に確認。ブラウザCSVだけではどちらも確認できない	パスワード行だけで、パスワード以外も移ったと判断すること
日常の運用負担	同期基盤は事業者が運用	保存、同期、バックアップ、競合処理を自分で運用	「ローカル保存」を「自動バックアップ済み」と取り違えること

監査を設計する前に、私は2026年3月10日公開の公式KeePassXC 2.7.12ポータブル版もダウンロードした。ファイル照合に使うZIPのSHA-256値は、配布元が公開した86718f7f47d7ca7f287de0260c567644c846e2a3e51ad2f93a76605178be9850と一致した。展開したKeePassXC.exeをWindowsのコード署名検証（Authenticode）にかけると、DroidMonkey Apps, LLCによる有効な署名と判定された。確認できるのは、私が調べたこのファイルだけである。すべてのミラー、将来の版、設定まで保証するものではない。同じ2.7.12のリリースノートには、パスキーのフラグを修正した影響で、既存の一部パスキーを利用先サイトが拒む可能性があるとの警告もある。パスキーも移行対象なら、移行元のログイン経路を残したまま、一つずつ動作を確かめる必要がある。

本番の切り替え前なら、選択はやり直せる。公式配布元から移行先のアプリをインストールし、架空の項目を一つだけ作って、ロック、解除、復旧を練習しておく。ほかの端末でも想定どおり動くか確認する。試験のためだけに、ブラウザの認証情報を消してはいけない。

ブラウザのCSVで移せるもの、証明できないもの
#

ブラウザが書き出すCSVは、暗号化されていない受け渡し用ファイルである。ログイン項目は運べるが、パスキー、TOTPの秘密値、添付ファイル、カード、本人情報、独自項目、変更履歴、復旧情報、製品固有のメタデータまで移ったとは証明できない。

Googleは、ChromeのCSVに最低限入る列をurl、username、passwordと説明し、削除せずに残したファイルを手にした人は誰でもパスワードを読めると警告している。これらはパスワード行の項目であり、パスキーや移行先の読み込み結果を保証しない。MicrosoftもEdgeの書き出しに同じ平文の警告を出している。MozillaはFirefoxの書き出しファイルをアップロード、メール送信、共有しないよう求めている。

受け渡しファイルの限界と、移行先製品の限界は同じではない。Bitwarden独自のCSVにはlogin_totp列を入れられるが、カスタムファイルの読み込み資料によると、CSVが扱うのはログイン情報とセキュアノート（保管庫内で守るメモ）である。本人情報とカードにはJSON形式のファイルが必要で、添付ファイルは別に扱う。KeePassXCも、自身が書き出すCSVでは添付ファイル、高度な属性、自動入力（Auto-Type）の設定、独自アイコンを表現できないと警告している。そもそもブラウザがファイルへ入れていない情報を、移行先が読み込むことはできない。

棚卸しする種類	パスワードCSVから確認できること	別に確認すること	秘密を漏らさない確認方法
パスワードによるログイン	URL、ユーザー名、パスワード。場合により名前／メモ	重複、空欄、URLの変化、移行元独自の項目	秘密情報を表示しない内容照合
パスキー	確認できない。パスワード行から網羅率を推測してはいけない	保管元の事業者、利用先サイト、同期型／端末固定型、持ち出し可否	保管元と利用先サイトの認証情報一覧
TOTPの秘密値	移行元が書き出し、移行先が対応づけた場合だけ	読み込み後のコード生成、端末の時刻、復旧コード	重要度の低いアカウントで、設定を壊さない形で確認
添付ファイル／独自項目	入らないか、情報が限られることが多い	件数、種類、手動移行	移行先の項目を直接確認
カード／本人情報／セキュアノート	ブラウザの書き出しには入らない場合がある	製品独自のJSONまたは直接転送への対応	種類ごとに件数を分けて確認
復旧情報	保管庫に含まれると決めつけてはいけない	二つ目の認証要素、復旧コード、緊急アクセス、データベースのバックアップ	移行元を残したまま、新しいブラウザで復旧経路を確認

**Credential Exchange Protocol（CXP）**は、製品間で認証情報を直接交換するFIDOの仕様である。移行元と移行先の両方が対応していれば、平文ファイルを作る段階をなくせる。Bitwardenの現行資料には、対応するモバイル環境で、互換性のあるアプリからパスワードとパスキーを移すFIDO CXPの経路が記載されている。歓迎すべき改善だが、デスクトップ上のChrome、Edge、FirefoxとBitwarden、KeePassXCのどの組み合わせでも使える共通手順ではない。実際に使う移行元アプリ、移行先アプリ、OSがそろって対応しているか確かめる必要がある。

CXPが使えるなら利用し、それでも認証情報の種類ごとに棚卸しせよ。「CSVを使わない」ことで平文ファイルそのものを作らずに済むが、すべての種類と復旧経路が移った証明にはならない。

12件対12件でも、移行は完了していなかった
#

行数が同じでも、保管庫の中身は一致しないことがある。移行先で1件が欠け、別の1件が重複すれば、合計は移行元と同じままだ。移行の確認では、総数だけでなく内容と認証情報の種類を比べなければならない。

同梱した実験データには、例示用に予約されたドメインと明らかな架空パスワードだけを使っている。ブラウザ形式の移行元には、重複のないログイン情報が12件ある。Bitwarden形式の移行先にも12行あるが、管理者用ログインを意図的に1件省き、別の項目を重複させた。

二つのファイルは、migration-audit.pyで比較した。このスクリプトは、対応するブラウザ、Bitwarden、KeePassXCのCSV見出しを共通形式へ整え、URL・ユーザー名・パスワードの組をメモリ内のSHA-256フィンガープリントとして比較する。フィンガープリントをファイルへ書かず、画面にも出さない。ただし、メモリを安全にゼロで上書きする機能はなく、使用したメモリはプロセス終了時にOSへ戻される。公開した監査結果には集計値しか含めていない。

このツールのPASSは、URL・ユーザー名・パスワードの組が一致したことだけを意味する。メモ、フォルダー、独自項目、パスキー、TOTP、添付ファイル、本人情報、カード、復旧情報まで移ったことは証明しない。

監査項目	結果	行数だけならどう見えるか
移行元の行数	12	完了に見える
移行先の行数	12	完了に見える
完全に一致した認証情報	11/12（91.7%）	見えない
移行先にない認証情報	1	見えない
移行先にだけある認証情報	1	見えない
移行先で完全に重複した項目	1	見えない
監査判定	HOLD	誤ってPASSになる

この実験は、各社の読み込み機能をすべて再現したものではない。示しているのは検証方法の論理的な欠陥である。総数が同じでも、欠落は起こりうる。Bitwardenでは、重複が起きる可能性も無視できない。公式のインポートFAQによると、一致する項目がすでに存在しても、読み込みのたびに新しい項目が作られるからだ。

スクリプトはローカルだけで使う。実際のCSVには、アカウントへログインするための秘密情報が入っている。サポートへの添付、AIチャットへの貼り付け、このリポジトリへの保存、ウェブ上の「移行チェッカー」への送信はしてはいけない。実データを比較スクリプトへ読ませたくないなら、オフライン端末で少数を手作業で照合し、移行元を長めに残す。

パスワードマネージャーを移す7段階
#

安全な移行は、順序を管理した切り替え作業である。認証情報を種類別に棚卸しし、復旧手段を準備し、移行先を検証し、一度だけ転送する。その後で内容を比較し、通常ログインと復旧を試し、最後に平文ファイルを消して古いマネージャーを退役させる。

総数ではなく種類ごとに棚卸しする。 パスワードによるログイン、パスキー、TOTP、セキュアノート、添付ファイル、本人情報、カード、復旧コードを分けて記録する。最初に見るのは、主要メール、パスワードマネージャー自体、携帯電話会社、金融、ドメイン登録事業者、クラウドストレージなど、失ったときの影響が大きいアカウントだ。SNSのセルフ監査と同じく、用途の異なる身元は分けて扱う。
製品を選ぶ前に、復旧が最後に何へ依存するかを特定する。 Bitwardenでは、アカウントのメールアドレス、マスターパスワード、利用できる二つ目の認証要素、2段階ログイン（2FA）の復旧コードを記録する。このコードで無効にできるのは2段階ログインだけであり、その後もマスターパスワードが必要だ。マスターパスワードを忘れた場合の資料によると、事前設定した代替手段が残っていなければ、Bitwardenの担当者が個人の保管庫を取り戻すことはできない。代替アクセスを当てにする前に、その手段が機能することを確認する。KeePassXCでは、KDBXの保存場所、マスターキー、任意で設定したキーファイルまたはハードウェア認証、端末外に置くバックアップ1つ以上、ファイル競合時の手順を記録する。すべてを持ち歩くノートパソコン1台に置いてはいけない。
移行先のインストーラーを検証し、架空データで練習する。 公式ドメインまたは署名付きリリースから入手し、配布元が示すチェックサムまたは署名を確認する。架空の保管庫を作り、実データを書き出す前に、ロック、解除、ブラウザ連携、バックアップからの復元を確かめる。
平文データに触れる範囲が最も小さい公式手順を選ぶ。 移行元、移行先、インストール経路、認証情報の種類、実際に使うOSのすべての条件がそろうときは、確認済みの直接読み込みまたはCXPを優先する。Bitwardenの対応デスクトップ版による直接読み込みなら、ブラウザCSVを手動で作らずに済む。ただし、パスキーや他のすべての種類まで移ったとは証明できない。ファイルが必要なら、信頼できる端末上の、自動同期されない暗号化ローカルストレージへ一度だけ作る。コピーを生みそうなチャット、クラウドドライブ、バックアップ、索引作成、エディターを閉じ、正確な保存先を記録する。Coraの調査に使うブラウザ、AIの入力欄、オンライン変換サイトへ実際の秘密情報を渡してはいけない。
転送は一度だけ行い、結果を確認する。 正しい移行元または直接読み込み経路を選ぶ。KeePassXCでは、確定前にCSV列のプレビューと項目の対応を確認する。CSV自体は暗号化されていない。Bitwardenは、直接読み込みでもファイル読み込みでも重複を検出しない。エラーが出たら止める。「今度は入るかもしれない」と何度も実行してはいけない。
内容と種類を確かめる。 認証情報を画面やログへ出さずに内容を比較し、影響の大きいアカウントはすべて手作業でも確認する。パスキー、TOTP、添付ファイルは別々に数える。行数の一致は一つの参考値にすぎない。移行元の認証情報が一つでも欠ける、予期しない重複がある、パスワード以外の種類について確認済みの移行経路がない——どれかに当てはまれば判定はHOLDだ。
ログインと復旧を試し、観察してから旧環境を退役させる。 新しいブラウザプロファイルを使い、重要度の低いアカウントをいくつか試し、影響の大きいアカウントをすべて確認する。移行元を消さず、既存のログイン済みセッションからもログアウトせず、繰り返せる復旧手順を実行する。1回限りのコードは、保管した複製を取り出せることと、公式手順を参照できることを確認する。意図的に使用し、再発行または交換後のコードを保存した場合に限り、機能まで確認済みと呼べる。短い観察期間には、古い保管庫を読み取り専用で残す。成功を確認してから、ブラウザの保存機能を無効にし、移行元の項目を消す。ファイルで移した場合は、見つけられる平文の複製をすべて削除する。

この順序は、ログインできる状態を守る。読み込みが誤っていれば、移行元へ戻れる。復旧に問題があれば、既存のログイン済みセッションから修復できる。CSVが同期フォルダーへ複製されていても、ローカルの1ファイルを消しただけで完了と考える前に発見できる。

同じ移行中に、復旧用の電話番号まで軽い気持ちで変更してはいけない。日常ログインに使わなくなった番号でも、アカウント復旧には残っている場合がある。電話番号のプライバシーモデルで、その依存関係を先に整理しておく。

CSVを消しても、完全消去とは限らない
#

平文CSVの削除は露出を減らすが、削除操作だけでは、物理媒体、同期先、検索用索引、バックアップ、プレビューに複製が残っていないと証明できない。最も有効なのは、書き出す前に余計な複製を防ぎ、ファイルが存在する時間を短くすることだ。

Google、Microsoft、Mozilla、Bitwarden、KeePassXCはいずれも、パスワードの書き出しファイルは平文で読めると警告している。MicrosoftはEdgeからの移行後にSHIFT+DELETEを使うよう具体的に勧めている。Windowsのごみ箱を経由しない削除方法だが、SSD、クラウド同期の履歴、バックアップ、自分で管理できないストレージから、デジタル鑑識でも復元できないほど完全に消えたことを保証するものではない。

削除時は、次の場所を確認する。

場所	確認すること	対応
指定した書き出し先	正確なファイル名と更新日時	監査と復旧試験の成功後に削除
ダウンロード／デスクトップ／ドキュメント	誤って2回目を書き出していないか	確認できた複製だけを削除
クラウド同期フォルダーと版の履歴	保存先が同期されたか	事業者の公式手順でリモート側の版を削除
ごみ箱	通常の削除を使ったか	対象を確認してごみ箱から削除する。ただし媒体の完全消去とは考えない
エディター、表計算ソフト、プレビュー	最近使ったファイル、自動保存、一時コピー	書き出し前に閉じ、確認できた一時ファイルを消す
バックアップと時点保存の複製（スナップショット）	バックアップ対象だった時間帯にファイルが存在したか	保存期間の規則に従う。削除を確認できなければ、そのファイルに入っていたパスワードを変更

実際のCSVがメール、チャット、AIサービス、公開リポジトリ、信頼できない変換サイトへ渡った可能性があるなら、パスワードは漏れたものとして扱う。証拠を残し、影響の大きい認証情報から変更し、必要に応じてセッションを無効にして、棚卸しの順に対処する。すでに複製された秘密情報は、移行先の保管庫へ入れても非公開には戻らない。AIアシスタントのプライバシー監査で説明したとおり、チャット入力欄は記録を残す場所であり、安全な受け渡し経路ではない。

結論——どの移行経路を選ぶべきか
#

サービス事業者のアカウントへの依存を受け入れても、管理型同期と日々の手間の少なさを重く見るならBitwardenを選べ。バックアップと同期を自分で運用しても、ローカル管理を優先するならKeePassXCを選べ。どちらでも、内容と復旧経路を確認せよ。

優先したいこと	最初の候補	必須の備え
複数端末で自動同期	Bitwarden	マスターパスワードの保管・復旧計画、別に保管した2FA復旧コード、確認済みのアクセス経路
ローカルの暗号化データベース	KeePassXC	端末外のKDBXバックアップと確認済みの復元手順
移行中の露出を最小化	資料に明記された直接読み込みまたはCXP	移行元、移行先、インストール経路、OS、認証情報の種類ごとに対応範囲を確認
ブラウザだけで簡単に使う	ブラウザのマネージャーを使い続ける	端末とアカウントを強く守り、復旧を確認。移行は必須ではない
高リスクまたは複雑な保管庫	段階的な移行	少量ずつ移し、重要項目を手作業で確認し、読み取り専用の移行元を長めに残す

「書き出して、うまくいくよう願う」で終わらせるな。認証情報を種類ごとに把握し、ファイルで表現できないものを知り、一度だけ読み込み、秘密を漏らさず内容を比較し、復旧を試してから古い経路を止めよ。製品選びも重要だが、切り替え方はそれ以上に重要である。

要点

選択は条件で変わる： Bitwardenは暗号化同期を運用する。KeePassXCでは、利用者がKDBXファイルとバックアップの責任を負う。
対応が明記されていればファイルを避け、必要なら厳重に扱う： 公式の直接読み込みまたはCXPなら、手動でCSVを作る段階をなくせる。ただし、すべての認証情報が移った証明にはならない。CSVが必要なら、見つけた複製をすべて消すまで、暗号化されていない平文ファイルとして扱う。
件数は誤解を招く： 12件対12件の架空データでは、一致は11件だけだった。照合率91.7%、欠落1件、重複1件で、判定はHOLDになった。
認証情報は種類ごとに違う： パスワード行の件数では、パスキー、TOTP、添付ファイル、カード、本人情報、復旧情報の移行を証明できない。
順序がアクセスを守る： 棚卸し、復旧準備、ソフトウェアの検証、1回の転送、内容比較、動作確認を済ませてから、古いマネージャーを無効にし、平文の複製を削除する。

よくある質問
#

移行で誤りやすいのは、製品選び、件数による確認、パスキーの扱い、平文ファイルの片づけ、SSDや同期ストレージからCSVを削除する限界の5点である。

BitwardenはChromeのパスワードマネージャーより安全ですか？
#

一概には言えません。Bitwardenへ移すと、保管庫をブラウザの仕組みから分けられ、複数のクライアントや共有機能を使えるため、信頼先と復旧方法が変わります。Google中心の使い方なら、Chromeのほうが単純な場合もあります。製品名だけで安全性を決めず、ロック解除済み端末での危険、アカウント復旧、同期への依存、移行失敗の影響を比べてください。

KeePassXCはオフラインだからBitwardenより安全ですか？
#

必ずしもそうではありません。KeePassXCには必須のクラウド同期アカウントがありませんが、KDBXファイル、バックアップ、同期、競合、復旧を自分で管理する必要があります。ローカルに1つしかないファイルは、自主管理ではなく単一障害点です。Bitwardenの管理型同期には異なるリスクがあるだけで、必ずしも大きいわけではありません。

読み込み件数が一致したら、CSVを削除してよいですか？
#

いいえ。同じ件数でも、1件の欠落と1件の重複が隠れていることがあります。認証情報の中身を比較し、影響の大きいアカウントを確認し、パスキーとTOTPを別に数え、通常ログインと復旧を試してから、受け渡しファイルと移行元の保管庫を削除してください。

ChromeのパスワードCSVにパスキーも入りますか？
#

パスワード行の件数を、パスキーが移った証拠にしないでください。Googleが示すCSVの最低限の列はURL、ユーザー名、パスワードです。パスキーは、保管元の事業者ごとに持ち出しの条件が異なります。パスキーを別に棚卸しし、移行元と移行先が実際に使うOS上で明示的に対応している場合だけ、CXPを使ってください。

SSD上のパスワードCSVは、安全に上書き消去すべきですか？
#

1回の上書きや削除で、SSD、同期先、バックアップ、プレビューにあるすべての複製が消えるとは約束できません。自動同期されない暗号化ローカルストレージを使って複製を防ぎ、ファイルが存在する時間を短くしてください。確認できた複製を削除し、同期履歴を調べ、漏れを否定できない場合は認証情報を変更してください。

出典
#

次の公式資料と一次資料12件は、2026年8月3日時点の移行に関する主張を支える。11件には、対象ページと日時が一致するアーカイブがある。Edgeの現行資料だけは同日時点で完全に一致する保存版がなく、その欠落をワイルドカードのURLで隠していない。

#	出典	URL	アーカイブ
1	NIST——SP 800-63B-4	https://pages.nist.gov/800-63-4/sp800-63b.html	https://web.archive.org/web/20260802091116/https://pages.nist.gov/800-63-4/sp800-63b.html
2	Google Chrome ヘルプ——パスワードとパスキーの読み込み／書き出し	https://support.google.com/chrome/answer/13068232?hl=en-GB	https://web.archive.org/web/20250409111740/https://support.google.com/chrome/answer/13068232?hl=en-GB
3	Microsoft サポート——Edgeからパスワードを書き出す	https://support.microsoft.com/en-us/edge/export-passwords-in-microsoft-edge	完全に一致する保存版なし（2026年8月3日確認）
4	Mozilla サポート——Firefoxからログイン情報を書き出す	https://support.mozilla.org/en-US/kb/export-login-data-firefox	https://web.archive.org/web/20260621011944/https://support.mozilla.org/en-US/kb/export-login-data-firefox
5	Bitwarden——Chrome、Edge、Chromium系ブラウザから読み込む	https://bitwarden.com/help/import-from-chrome/	https://web.archive.org/web/20260713195219/https://bitwarden.com/help/import-from-chrome/
6	Bitwarden——読み込みと書き出しに関するFAQ	https://bitwarden.com/help/import-faqs/	https://web.archive.org/web/20260622160725/https://bitwarden.com/help/import-faqs/
7	Bitwarden——カスタムファイルから読み込む	https://bitwarden.com/help/condition-bitwarden-import/	https://web.archive.org/web/20260708232651/https://bitwarden.com/help/condition-bitwarden-import/
8	KeePassXC——User Guide	https://keepassxc.org/docs/KeePassXC_UserGuide	https://web.archive.org/web/20260728213815/https://keepassxc.org/docs/KeePassXC_UserGuide
9	KeePassXC——2.7.12リリース	https://github.com/keepassxreboot/keepassxc/releases/tag/2.7.12	https://web.archive.org/web/20260728142825/https://github.com/keepassxreboot/keepassxc/releases/tag/2.7.12
10	FIDO Alliance——Credential Exchange Specifications	https://fidoalliance.org/specifications-credential-exchange-specifications/	https://web.archive.org/web/20260711082529/https://fidoalliance.org/specifications-credential-exchange-specifications/
11	Bitwarden——2段階ログインの復旧コード	https://bitwarden.com/help/two-step-recovery-code/	https://web.archive.org/web/20260515192732/https://bitwarden.com/help/two-step-recovery-code/
12	Bitwarden——マスターパスワードを忘れた場合	https://bitwarden.com/help/forgot-master-password/	https://web.archive.org/web/20260729154628/https://bitwarden.com/help/forgot-master-password/

Cora Aegis

Cora Aegisは、CypherpunkGuideでプライバシーを最優先にしたOPSECの実践ガイドを書いている。この記事では、Google検索の競合5件と一次資料7系統を確認し、KeePassXCの署名付きリリースを検証したうえで、パスワードを表示しない12件の移行監査を作成した。

Cora Aegisについて詳しく読む →

ChromeのAIモデルを監査・削除・維持する方法（2026年）

Thu, 06 Aug 2026 00:00:00 +0000

資金について：CypherpunkGuideは監視型広告を一切載せない——広告ネットワークも、トラッキングピクセルも、スポンサー記事もない。運営資金は透明な収益源から得ている。現在は読者からの寄付で賄い、将来は購読と編集方針に合うアフィリエイト収入も充てる。私たちは広告主ではなく、読者に向き合う。

「Chromeが知らないうちに4GBのAIモデルを入れた」という話には、本当に確認すべき設定の問題と、あてにならない固定値が混ざっている。Chromeはオンデバイスモデルをダウンロードできる。これはAIが学習した数値パターンを収めたファイルで、遠隔のサーバーではなく利用者の端末上で処理するために使われる。Googleの資料には、たとえば20億（2B）と40億（4B）のパラメータを持つモデルが示されている。しかしパラメータ数はファイル容量ではない。実際の容量は更新によっても変わる。

私は2026年8月6日、remove Chrome on-device AI model 2026でGoogle検索の上位5件を調べ、Google AI OverviewとAI Modeの回答も確認した。生成された回答は、公式設定、手動削除、実験機能を切り替えるflags、組織管理用ポリシー、起動時に指定する引数を並べていたが、それぞれ何を制御するのかを分けていなかった。

そこで、7つの制御手段を、ローカルでの保存と計算、クラウドAIや端末とクラウドを組み合わせるAI、ブラウザ事業者への信頼という3層に分けた。さらに、モデルが取りうる4つの状態を架空データで再現し、同梱の読み取り専用監査ツールを試した。結果は4件中4件が想定どおりだった。このツールはモデルの中身を読まず、利用者のChromeプロファイルを探索せず、指定されたフォルダーの場所を表示せず、ファイルの削除もポリシーの変更も行わなかった。制御手段の一覧とテスト結果も公開する。

これはChromeを勧めるためでも、退けるためでもない。自分が守りたい範囲に合う、必要最小限の手段を選ぶための整理である。

Chromeの「4GB AIモデル」とは何か
#

Chromeのローカル基盤モデル——幅広い用途の土台になるAIモデル——は、ブラウザ本体とは別に管理される部品（コンポーネント）である。「4GB」は報告例の一つにすぎず、容量が固定されているわけでも、すべての端末に必ず入るわけでもない。モデルの有無を判断する確実な基準にもならない。

Googleの内蔵モデル管理に関する資料は、ブラウザ本体とモデルのコンポーネントを分けて説明している。Chromeは端末に合うモデルを選び、バックグラウンドで、または対応機能から求められたときにダウンロードできる。モデルだけを個別に更新することもあり、容量不足やポリシーに応じて削除もする。20億（2B）と40億（4B）のパラメータを持つモデルは種類の例であり、「2GB」「4GB」という意味ではない。

端末が利用条件を満たすかどうかも重要だ。Googleの開発者向け要件には現在、Chromeプロファイルが置かれたドライブに22GB以上の空き容量があることと、従量制ではないネットワークを使うことが挙げられている。さらに、4GBを超えるビデオメモリを備えたGPUが必要だ。GPUを使わずCPUで処理する場合は、16GB以上のRAMと4コア以上のCPUが必要になる。これは現在の内蔵AI API（ウェブページからブラウザ内のAI機能を呼び出す仕組み）を使うための動作要件であり、該当するすべてのChromeが同じファイルを即座にダウンロードする証拠ではない。

ダウンロードが始まるきっかけも一つではない。利用者向け機能がバックグラウンドでの管理を始める場合がある。ウェブページが内蔵APIを通じてモデルを要求する場合もある。詐欺検出の資料に示された条件では、モデルを利用できるか確かめるだけでダウンロードが始まることもある。「Chromeを入れれば全端末へ入る」も、「自分が明示的に頼むまで何も入らない」も、どちらも正確ではない。

よくある主張	2026年8月6日時点で確認できる挙動	実務上の意味
すべてのChromeに4GBのモデルが入る	対象端末、開始条件、モデルの種類、正確な容量は一定でない	一つの数字を探すのではなく、自分の環境を確認する
4Bモデルは4GBを占める	「4B」はパラメータ数でありバイト数ではない	名前から容量を換算せず、ファイルを測る
明示的にAIへ指示した後だけダウンロードされる	利用者向け機能やAPIの動作によって管理が始まることがある	継続的に効く制御は、有効な機能とポリシーで考える
モデルのファイルを消せば二度と戻らない	許可された管理コンポーネントは再ダウンロードされうる	公式設定または対象を絞ったポリシーを使い、その後で確認する
ローカルモデルならGoogleへ何も送らない	AI処理自体が端末内で完結しても、機能全体ではクラウド処理や端末とクラウドにまたがる処理を使う場合がある	モデルだけでなく機能全体のデータの流れを調べる

この違いは、プライバシーにもセキュリティにも関わる。Chrome 137では、一部のテクニカルサポート詐欺（偽のサポート窓口へ誘導する詐欺）が疑われるページを見分けるため、Gemini Nanoが端末内で作る判定材料が追加された。Googleのセキュリティ解説によると、Enhanced Protection（保護強化機能）を選んだ利用者では、大規模言語モデル（LLM）が作った判定材料をSafe Browsing（危険サイト判定サービス）へ送り、最終判定を行う。Standard Protection（標準保護）の利用者も、確認済みの脅威が遮断リストへ加わった後は保護を受けられる。モデルの計算場所はローカルだが、Enhanced Protectionの処理全体はローカルとクラウドを組み合わせたハイブリッドである。

変更する前にモデルを監査する
#

監査では、ローカルコンポーネントが存在するか、どのChromeバージョンと機能が懸念の発端か、クラウドAIや端末とクラウドにまたがるAI機能が有効かを別々に確かめる。一つのフォルダーから分かるのは、ローカルコンポーネントの有無だけだ。

まずChrome自身の内部一覧を見る。アドレスバーへchrome://on-device-internalsと入力し、ブラウザのバージョン、モデルの状態、そのChromeで表示される容量またはコンポーネント情報を記録する。診断内容を公開フォーラムやAIチャットへ貼ってはいけない。内部ページには、助言を求めるのに不要な環境情報が含まれる場合がある。

デスクトップでもう一つ読み取り専用の測定を行うなら、同梱スクリプトへ、自分で明示的に選んだ利用者データの最上位フォルダー（Chromeの各プロファイルを収めるローカルフォルダー）を渡す。

python chrome-ai-model-audit.py "C:\Path\To\Chrome User Data"

ツールが調べるのは、その直下にあるOptGuideOnDeviceModelだけだ。別の場所を参照するディレクトリは除外し、通常ファイルの数とバイト数を数え、weights.binというモデルファイルの有無を記録する。出力するのは固定ラベルで、指定したフォルダーの場所ではない。この監査では、どの機能がモデルを使ったかも、クラウドAIの状態も分からない。

Chromeを調べずに、架空データによるテストだけを再現することもできる。

python chrome-ai-model-audit.py --self-test

架空の状態	期待する分類	実測結果
コンポーネントのディレクトリがない	`absent`	PASS
ディレクトリはあるが空	`present-empty`	PASS
モデルの管理情報はあるが`weights.bin`はない	`present-without-weights`	PASS
管理情報と架空の`weights.bin`がある	`present-with-weights`	PASS

このスクリプトはプロファイルを列挙せず、Windowsのユーザー名を表示せず、モデルファイルの内容から照合値（ハッシュ）を計算せず、プロファイルのデータベースを開かない。今回の監査に必要のない情報まで集めないためである。

設定を変える前に、懸念の対象を明確にする。ディスク使用量やローカルの計算負荷なら、対象はOn-device AI設定だ。ページ内容の外部送信が心配なら、クラウド機能を一つずつ調べる。アカウント連携なら、AI、検索、同期を別々に確認する。ブラウザのコードと更新をGoogleが管理すること自体が問題なら、事業者との関係を変えられるのはブラウザ移行だけである。フォルダーを消すだけでは、どの問題にも継続的な答えにならない。

公式の制御手段で削除する
#

個人用ChromeではOn-device AI設定を使え。組織管理下のChromeではローカルモデル専用のポリシーを使え。フォルダーの手動削除、コンポーネント全体の停止、flagsは同じ働きをしない。

Googleの現在の利用者向け案内では、設定はSettings > System > On-device AIにある。2026年7月のChromium変更では、今後の版でSettings > AIへ移す作業が進んでいる。メニューに見当たらなければ、Settings内で「On-device AI」を検索する。スイッチをオフにするとローカルモデルの利用を防ぎ、導入済みモデルを削除する。再びオンにすれば、後でダウンロードできるようになる。Googleは、操作後すぐに全データが消えるとも、削除にかかる時間が全環境で同じだとも明記していない。変更が反映される時間を置き、その後で確かめる。

次の順序で行え。

先にChromeを更新せよ。 AIについて判断している間もブラウザのセキュリティ更新は有効に保ち、確認したバージョンを記録する。
削除前の状態を確認せよ。 chrome://on-device-internalsを開き、必要なら自分で選んだChromeのデータフォルダーへ読み取り専用監査を実行する。
個人用のスイッチを使え。 Chrome SettingsでOn-device AIを検索する。現在のHelpではSystemの下にあるが、今後の版ではAIの下へ移る場合がある。オフにする。
管理対象ブラウザだけに専用ポリシーを使え。 管理者はブラウザ単位のGenAILocalFoundationalModelSettingsを1にすると、ダウンロードを防ぎ、既存モデルを削除できる。未設定または0なら、条件を満たした環境で自動管理が許可される。これは利用者のGoogleアカウント単位ではなく、管理対象ブラウザに適用するポリシーである。
再起動して確認せよ。 内部ページとローカルの一覧をもう一度見る。表示の更新が遅れても、無関係なプロファイルデータを削除してはいけない。まず状態が変わるかを観察する。
クラウドAIを別に監査せよ。 AI Mode、Gemini in Chrome、文章作成支援、拡張機能、検索、同期、組織ポリシーを個別に確認する。

制御手段	実際の対象	ローカルモデルを削除	クラウドAIを停止	他への影響	用途
On-device AI設定	ローカル基盤モデル	はい	いいえ	モデル依存機能が使えなくなる	個人用の公式設定
`GenAILocalFoundationalModelSettings=1`	ローカル基盤モデル	はい	いいえ	モデル依存機能が使えなくなる	管理対象ブラウザ用
フォルダーの手動削除	現在あるローカルファイル	確実ではない	いいえ	対象を誤るとプロファイルを壊す	避ける。文書化された制御ではない
`ComponentUpdatesEnabled=false`	ポリシー対象となる多数のコンポーネント	保証されない	いいえ	大きい	モデル一つの判断には使わない
AI関連のflags	一時的な実験	保証されない	保証されない	予測できない	テスト専用
`AIModeSettings=1`	Chrome内のAI Mode入口	いいえ	いいえ。指定された入口を隠すだけ	小さい	管理プロファイルでの連携制御
ブラウザを替える	事業者とサービスの境界	該当しない	製品による	大きい	Googleへの信頼が問題のとき

一つのモデルを止めるために、コンポーネント更新をまとめて無効にしてはいけない。GoogleのComponentUpdatesEnabledポリシーは、除外対象を除く多数のコンポーネントに効く。一方、実行コードを含まない一部の重要なセキュリティコンポーネントはこのポリシーから除外され、更新を続ける。Chrome本体の更新機能でもない。モデル一つを対象にするには範囲が広すぎる。

chrome://flagsの長い一覧にも頼ってはいけない。Chromiumはflagsを実験として説明し、Chrome自身も、データを失ったりセキュリティやプライバシーを損ねたりするおそれがあると警告する。flagsは消えることがある。公式設定には対象範囲が定められている。

削除しても止まらないもの
#

On-device AIをオフにして制御できるのはローカル基盤モデルである。クラウドの文章作成ツール、Gemini連携、拡張機能、Safe Browsingのデータの流れ、ブラウザ同期、検索リクエスト、Googleアカウントとの連携は止まらない。

「ローカルで動く」という説明が示すのは、一つのAI処理が行われる場所であり、そのAIを組み込んだ機能全体の挙動ではない。モデルを端末内で動かしながら、そこから得た危険度のシグナルをクラウドサービスへ送る機能もある。選択した文章、ページの前後関係、URLを遠隔のモデルへ送る機能もある。独自の提供元とプライバシーポリシーを持つ拡張機能もある。

層	例	データと制御について確認すること	適切な制御
ローカル	基盤モデルのファイル、端末内での要約や分類	この端末で保存容量または計算資源を使ってよいか	On-device AI設定または専用ポリシー
ハイブリッド	端末内の詐欺分類とSafe Browsingの最終判定	どのシグナルが、どの保護モードで外へ出るか	機能とSafe Browsingを確認する。モデルの場所だけから推測しない
クラウド	Help me write、Gemini in Chrome、AI Mode	入力内容、ページの前後関係、URL、アカウントデータが提供元へ送られるか	機能別または管理プロファイル向けの制御
拡張機能	第三者のアシスタントやサイドバー	どの拡張機能がページを読めて、どこへ送るか	拡張機能の削除、権限、提供元のポリシー
事業者	更新、初期設定、同期、サービスの接続先	ブラウザ運営者を信頼先として受け入れるか	ブラウザ選択とアカウント／サービス設定

GoogleのHelp me write資料は、入力した文章、周囲のページ内容、ページのURLがGoogleへ送られるとしている。別のAI Modeポリシーが対象にするのは、アドレスバーとNew Tabにある特定の入口であり、AI ModeのウェブサイトやGoogleのAI連携すべてではない。ローカルモデルのファイルを削除しても、どちらも変わらない。

この分け方はChrome以外にも使える。AIアシスタントのプライバシー監査では、データの保持、アカウント、データの流れに関する主張を繰り返し確認する方法を示した。AI時代の脅威モデルでは、AIモデルと、その出力を使って行動できるアプリケーション、エージェント、人を分けている。

維持するか、削除するか、ブラウザを替えるか
#

守りたいものと想定する脅威にローカル機能が合うなら、モデルを維持する。保存容量または端末内の計算負荷が問題なら削除する。Googleがブラウザを運営すること自体を受け入れないならブラウザを替える。

ここには実際の得失がある。ローカルモデルは、対応する端末内処理に限ればクラウドへ送るデータを減らせる可能性があり、詐欺検出のような保護にも使われる。一方でディスクを占め、端末の計算資源を使い、ブラウザを複雑にする。しかも、その事業者が決める初期設定を受け入れられないかもしれない。削除を選ぶのは合理的だが、「ディスク上のコードが減る」ことは「あらゆる状況でセキュリティが高まる」ことと同じではない。

自分が守りたい境界	最初に取るとよい行動	それだけでは証明できないこと
対応するローカル機能を使いたく、資源の消費も受け入れる	On-device AIをオンのままにし、機能ごとに確認する	機能全体のデータの流れがローカルで完結すること
ローカルモデルの保存または計算を拒む	On-device AIをオフにして確認する	ChromeのクラウドAIまで無効になったこと
Chromeは使うが、特定のクラウドAIは拒む	該当する連携を個別にオフにし、必要なら管理者用ポリシーを使う	拡張機能やアカウントサービスまで対象になったこと
Googleをブラウザ運営者として受け入れない	ブラウザ移行を計画する	移行先にAI、利用状況の送信、クラウドサービス、セキュリティ上の得失がないこと

Firefoxは自動的な勝者ではなく、制御方法を比べる材料になる。Mozillaの現在のAI Controls資料によると、Firefox 148以降では、一つの設定画面から現在と将来の内蔵生成AI機能をまとめて無効にし、ダウンロード済みのオンデバイスモデルを削除できる。一方、独立した拡張機能はその制御の対象外だ。内蔵AIをまとめて拒否できる点は分かりやすいが、AIサービスがページへ一切触れない保証ではない。

ほかのChromium系ブラウザも個別に調べる必要がある。アシスタントを省いていてもChromiumコンポーネントは残るかもしれず、別のクラウドサービスを使う製品もある。「プライバシー重視」「AI非搭載」という表示だけでは、更新、初期設定、拡張機能、ポリシーの確認に代わらない。

ブラウザを替えるなら、古いプロファイルを消す前に認証情報を移す。パスワードマネージャーの移行手順で示したように、件数が同じでもパスワード、パスキー、一定時間ごとに変わる認証コード、復旧経路が無事に移った証明にはならない。

ブラウザのセキュリティを弱めずにGoogle依存を減らす
#

Googleの何に依存したくないのかを先に決める。検索、同期、AIサービス、Googleアカウントとの結びつき、ブラウザ事業者への信頼を一つずつ置き換え、更新と確認済みの復旧経路を残す。

次の順序で行え。

境界を書き出せ。 検索、アカウント連携、クラウドAI、同期、ローカルAI、ブラウザ本体のどれを外すのか選ぶ。一つの切替設定では、6つすべてが消えたと証明できない。
データを棚卸しして移せ。 ブックマーク、拡張機能、パスキー、パスワード、二つ目の認証要素、復旧コードを記録する。文書化した方法で移し、古いプロファイルは戻れる状態で残す。
移行先を試せ。 公式ダウンロードを使い、更新を確認し、初期設定の検索サービスと利用状況の送信を調べる。AI設定を確認し、ログイン、通話、銀行サービス、アクセシビリティ、物理セキュリティキーをテストする。
依存先を一つずつ外せ。 移行先が動いてからサインアウトまたはデータ削除を行う。ブラウザ更新は維持する。広すぎるコンポーネントポリシーはクラウドAIを消さないまま、多数の更新を止めるおそれがある。

結論——守りたい境界に合う手段を選べ
#

ローカルモデルへの答えは単純だ。状態を確認し、On-device AIをオフにし、再起動して確かめよ。プライバシーの判断では、ローカル、ハイブリッド、クラウド、拡張機能、アカウント、ブラウザ事業者を分けて考えよ。

「4GB」という数字を判断の軸にするな。削除をポリシーの代わりにするな。ディスクや計算負荷が問題ならモデルをオフにせよ。クラウドへの送信が問題なら機能ごとに監査せよ。Googleとの関係が問題なら、更新を弱めず認証情報も失わない手順で、ブラウザとGoogleアカウントへの依存を段階的に外せ。

要点

「4GB」は共通値ではない： Chromeが選ぶモデルは一つではなく、導入済み容量は更新でも変わる。
公式の制御手段を使う： 個人用ブラウザではOn-device AIをオフにし、管理対象ブラウザではGenAILocalFoundationalModelSettings=1を使う。
ファイル削除はポリシーにならない： コンポーネントのディレクトリを一度消しても、許可されたコンポーネントが戻ることは防げない。
ローカル処理は全体の一部にすぎない： ローカルモデルを削除しても、ハイブリッドやクラウド機能が入力内容、前後の文脈、URL、そこから得たシグナルを送る場合がある。
懸念に合う手段を選ぶ： ローカル資源が問題ならモデルを削除し、ブラウザ事業者への信頼が問題のときだけブラウザを替える。

よくある質問
#

モデルの容量は一定ではなく、メニューの場所は変わり、クラウドAIは別に残る。手動削除は継続的な設定にならず、別のブラウザも製品ごとの確認が必要である。

すべてのChromeが4GBのAIモデルをダウンロードするのですか？
#

いいえ。対象端末、ダウンロードが始まるきっかけ、ハードウェア、空き容量、モデルの種類、リリースによって変わります。Googleが例示する2Bと4Bはパラメータ数であり、ファイル容量ではありません。自分のブラウザを確認してください。

Systemの下にOn-device AI設定が見つからない場合、どこを見ればよいですか？
#

Chrome SettingsでOn-device AIを検索してください。2026年8月6日時点のGoogle HelpではSettings > Systemにありましたが、ChromiumではSettings > AIへ移す作業が進んでいました。StableやBetaなどの配信系列とバージョンによって、メニューの位置は変わります。

On-device AIをオフにすれば、ChromeのAIはすべて無効になりますか？
#

いいえ。制御するのはローカルモデルです。AI Mode、Gemini連携、クラウドの文章作成、拡張機能、Safe Browsing、検索、同期、アカウントサービスは別です。

`weights.bin`やモデルのフォルダーを手動で削除してもよいですか？
#

いいえ。手動削除は文書化された制御ではなく、削除した状態を保つ設定にもなりません。許可されたファイルは戻る場合があります。公式設定または対象を絞ったポリシーを使い、その後で状態を確認してください。

Firefoxや別のプライバシー重視ブラウザへ替えれば、自動的に安全になりますか？
#

いいえ。Firefox 148以降には内蔵生成AIをまとめて制御する設定がありますが、拡張機能とウェブサービスは別です。ほかのブラウザもアシスタント、利用状況の送信、更新方式、依存するサービス、互換性に伴う手間が異なります。実際に使う現行版を確認してください。

出典
#

次の変更されうる公式資料10件には、対象ページと日時が一致するWayback保存版を併記した。Chromiumの設定移動は変更不能なコミットURLであり、存在しないアーカイブ日時は付けていない。

#	出典	URL	アーカイブ／変更不能な証拠
1	Google Chrome Help——Chromeのオンデバイス生成AIモデルを管理する	https://support.google.com/chrome/answer/16961953?hl=en	https://web.archive.org/web/20260801170205/https://support.google.com/chrome/answer/16961953?hl=en
2	Chrome for Developers——内蔵モデルの管理を理解する	https://developer.chrome.com/docs/ai/understand-built-in-model-management	https://web.archive.org/web/20260709211120/https://developer.chrome.com/docs/ai/understand-built-in-model-management
3	Chrome for Developers——内蔵AIを使い始める	https://developer.chrome.com/docs/ai/get-started	https://web.archive.org/web/20260629120921/https://developer.chrome.com/docs/ai/get-started
4	Chrome Enterprise——GenAI local foundational model settings	https://chromeenterprise.google/policies/gen-ai-local-foundational-model-settings/	https://web.archive.org/web/20260308023006/https://chromeenterprise.google/policies/gen-ai-local-foundational-model-settings/
5	Chrome Enterprise——Component updates enabled	https://chromeenterprise.google/policies/component-updates-enabled/	https://web.archive.org/web/20260208072812/https://chromeenterprise.google/policies/component-updates-enabled/
6	Chrome Enterprise——AI Mode settings	https://chromeenterprise.google/policies/ai-mode-settings/	https://web.archive.org/web/20260526191101/https://chromeenterprise.google/policies/ai-mode-settings/
7	Chromium——実験と`chrome://flags`	https://www.chromium.org/developers/design-documents/experiments/	https://web.archive.org/web/20260804174840/https://www.chromium.org/developers/design-documents/experiments/
8	Google Security Blog——テクニカルサポート詐欺検出のためのオンデバイスAI	https://security.googleblog.com/2025/05/using-ai-to-stop-tech-support-scams-in.html	https://web.archive.org/web/20260430082954/https://security.googleblog.com/2025/05/using-ai-to-stop-tech-support-scams-in.html
9	Google Chrome Help——ChromeでAIを使って文章を書く	https://support.google.com/chrome/answer/14582048	https://web.archive.org/web/20260725211037/https://support.google.com/chrome/answer/14582048
10	Mozilla Support——Firefox AI Controls	https://support.mozilla.org/en-US/kb/firefox-ai-controls	https://web.archive.org/web/20260613231843/https://support.mozilla.org/en-US/kb/firefox-ai-controls
11	Chromium——On-device AI設定をAIページへ移す	https://chromium.googlesource.com/chromium/src/+/a4d2410c1ca703aa6c2ed0ec83ff95d0f4205a72	変更不能なコミットURL

Cora Aegis

Cora Aegisは、CypherpunkGuideでプライバシーを最優先にしたOPSECの実践ガイドを書いている。この記事では、Google検索の上位5件と生成回答2種類を監査し、アーカイブ済みの公式ページ10件と変更不能なChromiumコミット1件を確認した。さらにChromeの制御手段7つを整理し、ローカルモデルの4状態を読み取り専用で調べる監査を作成した。

Cora Aegisについて詳しく読む →

Monero・SimpleX・Cryptomatorで組むプライバシー設計（2026年）

Thu, 13 Aug 2026 00:00:00 +0000

支払いはMonero、会話はSimpleX、クラウド上のファイルはCryptomatorで守る。別々に見れば、3つの問題は片づいたように思える。確かに、それぞれの道具には明確な保護範囲がある。しかし、3つを使っただけで、決済からファイル受け渡しまでが匿名性を備えた一つの仕組みになるわけではない。

私は2026年8月13日時点の公式資料を使い、3つの道具について、観測者が知りうる情報を合計18項目、各6項目に分けて監査した。出典と判定を結び付けたCSVは4つの状態を記録し、同じ入力には必ず同じ結果を返す検証スクリプトは、保護範囲、出典、確認日が欠けた行を受け付けない。性質の違う項目を足してプライバシーの総合点を作れば、根拠のない順位になってしまうため、点数化はしていない。

難しいのは、3つを組み合わせたときだ。監査から、別々の記録を結び付ける手掛かりが6つ見えてきた。共通の別名、端末、通信経路、取引相手、時刻とデータ量の並び、復旧情報である。複数の記録へアクセスできる観測者は、こうした共通点を使って、支払い、会話、ファイル操作を同じ人の行動として推定できる。まず各道具の資料に書かれた保護範囲を確定し、その外側に残る記録を減らす手順を組み立てる。

3つの道具は、それぞれ別の記録を守る
#

プライバシー対策を重ねても、匿名性がまとめて保証されるわけではない。Moneroが守るのは決済記録、SimpleXが守るのはメッセージの配送、Cryptomatorが守るのはクラウドへ置くファイルである。保護できる観測者と、保護できない観測者を分けて考えなければならない。

製品名から考えるのではなく、残る記録から考える。公開ブロックチェーンを分析する人、インターネット接続事業者、中継サーバー、クラウド事業者、取引相手、自分の端末へ入り込んだマルウェアでは、見える情報が違う。同じ項目でも、ある相手からは隠れ、別の相手には見えることがある。

用途	主に守るもの	保護範囲の外に残るもの
決済——Monero	送金元の入力を特定しにくくし、受取人のアドレスと送金額を隠す仕組み	ウォレットの通信元IP、販売者の記録、自分から伝えた身元、端末上の鍵と復号後の情報
メッセージ——SimpleX	通信中の本文、接続をまたいで同じ利用者を示すグローバルなIDを持たない配送、宛先側中継サーバーからの送信元分離	相手ごとのキュー識別子、通信時刻、一部の中継・ネットワーク情報、連絡相手が知る身元、端末内の履歴
保存——Cryptomator	クラウド同期前のファイル内容と名前、分かりにくくしたフォルダー構成	更新時刻、オブジェクト数、保存後のサイズ、Cryptomator保管庫と分かる形式、同期アカウントの身元、開いた後の平文

監査台帳では、誰から情報を隠すのかを各行で一つ指定し、結果を次の4段階で記録した。

保護（protected）：その相手から情報を隠せることが、公式資料で確認できる。
一部保護（partial）：その相手に見える情報は減るが、情報そのものや、別の記録と結び付ける手掛かりは残る。
見える（exposed）：その相手から見えるか、その道具では守られないことが公式資料で確認できる。
不明（unknown）：公式資料だけでは、その相手に情報が見えるのか、隠れるのかを判断できない。不明だから安全とも、危険とも言えない。

ここでいう「保護」は、公式資料で確認できた範囲で、その相手から情報を隠すことだけを意味する。受取人にも見えない、端末を侵害されても安全、ほかの記録と結び付けられない、という意味ではない。

これは実用的な脅威モデルと同じ考え方である。対策を選ぶ前に、誰が、何を、どの出来事から知ろうとするのかを決める。想定する相手が変われば、必要な対策も変わりうる。

Moneroが隠すのは公開台帳上の関係であり、決済全体ではない
#

Moneroは、送金元を一つに断定しにくくし、受取人には一回限りの宛先を使い、送金額を隠す。これらは決済プロトコルの性質である。外部ノード、通信事業者、取引相手の記録、取引所アカウント、侵害された端末は別に考えなければならない。

Moneroの技術仕様に記載された現在のリングサイズは16である。本物の入力1つを**15個のおとり（decoy）と並べる。これにより、観測者が送金元を一つに断定しようとしても、ほかのおとり入力が候補として残る。この性質を否認可能性（plausible deniability）**と呼ぶ。ここでの「否認」は、送金元ではないと証明することではなく、公開台帳だけでは候補を一つに絞れないことを指す。ただし、「観測者が当てる確率は16分の1」という保証ではない。MoneroのOSPEAD研究は、おとりの選ばれ方の偏りや時刻に関係する危険をモデル化している。プロトコル上の個数を、そのまま個人の匿名確率へ換算してはいけない。

受取人と送金額は、送金元とは別の仕組みで守られる。**ステルスアドレス（stealth address）**は、受取人が繰り返し使うアドレスを公開台帳へそのまま出さず、決済ごとに一回限りの宛先を作る。RingCTは、公開台帳上の送金額を隠す仕組みだ。したがって「Moneroのプライバシー」は、送金元、受取人、金額という3つの異なる性質を指す。一つの万能な保護ではない。

観測者	Moneroによって変わるもの	なお持ちうる情報
公開ブロックチェーンの分析者	送金元の入力を特定しにくくし、受取人との対応と送金額を隠す	プロトコル上の取引が存在したことと時刻、確率的な推定
外部ノードの運用者	公開台帳から受取人の再利用アドレスや送金額を平文では読めない	通信経路を別に守らない限り、ウォレットからの接続と送信元IP
ISP（インターネット接続事業者）またはVPN事業者	公開台帳上の取引関係は引き続き隠れる	接続経路、通信時刻、接続先の並び
取引相手または取引所	外部の観測者は、決済の非公開項目を公開台帳から得られない	自分が渡した身元、注文内容、配送先、アカウント、金額、会話
侵害された端末	公開観測者に対するプロトコル上の保護は残る	ウォレットの鍵、送金先、金額、画面、クリップボード、入力したパスワード

公式FAQは100%の匿名性を否定し、端末の侵害、鍵の露出、弱いパスワード、取引相手へ渡した個人情報が結果を左右すると警告している。支払者や用途ごとに異なるサブアドレスを使えば、取引相手がアドレスの再利用から支払いを結び付ける機会を減らせる。しかし、同じ販売者へ配送先を渡した事実までは消せない。

通信元の保護も別である。Moneroの資料は、**remote node（手元のウォレットに代わってブロックチェーンへ接続する外部ノード）**を使うウォレットが、初期設定のままではIPアドレスを隠さないと警告し、TorまたはI2Pを追加の通信手段として説明している。Dandelion++は取引の伝わり方を変えるが、ISP、VPN事業者、最初の接続相手からノードの通信そのものを隠すものではない。通信元を守る必要があるなら、経路を明示的に設定し、実際のウォレットが意図した経路を使っているか確かめよ。

決済全体の脅威モデルは、Bitcoinのオンチェーン・プライバシーガイドでも扱っている。プロトコルは異なるが、公開台帳上の保護だけでは、購入記録や端末上の証拠は消えないという運用上の注意は共通する。

SimpleXは全接続に共通する利用者IDを使わない。それでも記録は残る
#

SimpleXは、全接続で同じ利用者を示すグローバルなプロフィールIDをメッセージ配送に使わない。代わりに、メッセージの受け渡し先を示す相手ごとのキュー識別子と、エンドツーエンド暗号化を使う。中継サーバー、通信経路、連絡相手、通知サービス、端末には、それぞれ別の情報が見える。

SimpleXのプライバシーポリシーによれば、プロフィールと配信済みの履歴は、中継用アカウントではなく利用者の端末に保存される。未配信の暗号化メッセージは、あらかじめ設定された中継サーバー（relay、送信側から受信側へ暗号化データを渡すサーバー）に、配信まで、または最長21日間残りうる。同じく初期設定のファイル中継サーバーでは、暗号化ファイルの保持期間は48時間である。本文を読めないサーバーであっても、何も保存しないわけではない。

メッセージは16KiB単位になるよう詰め物が加えられ、ファイルは固定サイズの断片に分けられる。この処理は正確なデータ量を分かりにくくするが、通信が起きた事実までは隠さない。iOSで即時通知を使えば、通知サーバーには、通知を有効にしたキューのおおよその数やメッセージ量が見える場合もある。

確認対象	初期設定の挙動	より厳しい設定	それでも残るもの
プロフィールの身元	接続をまたぐグローバルなプロフィールIDはなく、接続ごとの情報を使う	`incognito`（接続ごとに、通常のプロフィールとは別の名前や画像を使う設定）を使う	連絡相手は、やり取りするプロフィールを知る。繰り返す特徴から用途を結び付けられることもある
中継経路	private routing（転送用と宛先用の中継サーバーを分ける方式）では、設定済みの転送用サーバーを宛先側サーバーの前に置く。初期候補に複数の運用者がいれば、別運用者を優先する	選んだ中継サーバーへ送信元IPを見せたくない場合は、Torなど目的に合う追加経路を使う	転送側と宛先側が別運用者であるとは限らず、手元の通信を観測する相手には通信自体が見える
通信の照合	同じプロフィールは、初期設定では1本のTCP接続を共有する	`BETA`であることを確認したうえで、通信接続の分離（`transport isolation`、連絡相手ごとにTCP接続を分ける設定）を有効にする	通信の時刻と量から関係を推定される余地は残る
連絡相手の確認	招待リンクから接続する	アプリ内の本人確認用コード（security code）を別の経路で照合する	照合に使う別経路も、目的の相手が管理していなければならない
端末内の履歴	配信済みの履歴は端末へ保存される	アプリのデータベースにパスフレーズを設定し、必要な保持期間を決める	ロック解除済み端末、受取人、スクリーンショット、マルウェアは平文を保持できる

プライバシーとセキュリティの公式ガイドは、通信途中で招待リンクを別のものへ差し替えられる可能性を警告している。機密性の高い相手なら、信頼済みの電話や対面など、SimpleXの招待リンクとは独立した経路でアプリ内の本人確認用コードを照合せよ。同じ未確認アカウントから届いた2通目のメッセージは、独立した確認にならない。

プロトコルの脅威モデルを読むと、「識別子がない」という表現の限界も分かる。相手は、incognitoを使っていない別の接続で、プロフィール情報が同一かどうかを照合できる場合がある。受信確認や自動応答から、利用者が活動しているか、いつ活動したかを推測できる場合もある。全接続に共通する配送用プロフィールIDがないことと、相手ごとの識別子や観測可能な記録が一切ないことは同じではない。

通話はメッセージと別の保護範囲を持つ。SimpleXの音声・ビデオ通話ガイドによれば、**TURN中継サーバー（直接つながらない通話を中継するサーバー）**を使う通話では、そのサーバーから継続時間が見える。直接接続するP2P通話では、連絡相手にIPアドレスが見える。作業手順に通話を含めるなら、メッセージとは分けて監査せよ。

SimpleXが守るのはメッセージの配送と内容であり、送る内容まで安全に変えるわけではない。電話番号のプライバシーガイドでは、電話番号という識別子を外す効果を説明した。識別子を減らした後も、連絡相手の行動と端末の侵害には別の対策が必要である。

Cryptomatorはファイルを暗号化するが、動いた時刻や量は隠さない
#

Cryptomatorはクラウド同期の前にファイルの内容と名前を暗号化し、フォルダー構成を読み取りにくい形へ変える。一方、更新時刻、ファイルやフォルダーの数、クラウド上での保存サイズ、Cryptomator保管庫と分かる形式は、設計上クラウド側に残る。

Cryptomatorが守るものと守らないものを定めた公式文書（security target）は、保護対象外の情報まで明確に書いている。クラウド事業者は、読めるファイル名や内容を受け取らない。しかし、暗号化済みのファイルやフォルダーがいつ変わったか、いくつあるか、クラウド上でどれだけの大きさかは観測できる。.c9rや.c9sの拡張子と保管庫の設定ファイルから、Cryptomatorの利用も分かりうる。暗号化は、保管庫の存在を別のデータに見せかけるステガノグラフィーではない。

保管庫を開いた後の漏えいを考えると、**端末（endpoint、鍵と復号後のデータを実際に扱う機器）**が重要になる。マルウェア、悪意ある端末管理者、スクリーンショット、アプリの一時ファイル、クリップボード履歴、Cryptomatorの外へ作られたコピーは、クラウド向けの暗号化を迂回できる。別のアプリが開いたファイルを複製しても、Cryptomatorはその複製を守らない。

Cryptomatorは同期機能でも、バックアップ方針でもない。公式のbest practicesは暗号化された保管庫の定期バックアップを求め、同期競合のガイドは、競合を起こしうる別の仕組みとして同期を扱っている。保管庫の認証情報と復旧情報は、同じクラウドアカウントや、それを開く端末だけに置いてはいけない。保管庫の復旧を使っても、削除済みの暗号化ファイルは戻らない。複数のアプリが開いた保管庫を読めるなら、そのすべてを端末上で信頼する対象に含める必要がある。

18項目で確認した、道具をまたぐ情報の残り方
#

この監査は、3つの道具について各6項目、合計18項目を記録した。各行には、観測者、公式資料、確認日、判定の限界がある。目的は、道具を組み合わせたときの弱点を見つけることであり、製品の点数、レビュー評価、プライバシー順位を作ることではない。

私は、本稿で参照した公式資料から18行の監査台帳を作った。続いて検証スクリプトを実行し、行数が18であること、各道具が6行ずつであること、項目が重複していないこと、出典のホストが許可リストに入っていること、日付がISO形式であること、判定の限界が空欄でないことを確認した。生成した概要には4状態の件数を残しているが、件数を道具同士の優劣に使わないよう警告も入れてある。

監査方法には、5つの制約を置いた。

1項目につき観測者を1つ決める。 「通信元」は、中継サーバーやネットワーク上の観測者に対して判定する。正体の分からない「攻撃者」を置かない。
初期設定と追加対策を分ける。 hardened（追加対策後）欄には、公式資料に書かれた追加設定、または本文で名指しした別の対策を適用した場合だけを書く。Coraがその通信経路を実地で検証した評価ではない。Torを利用できる作業手順であっても、資料に明記されない限り初期設定とは書かない。
すべての行で、保護が及ばない条件を明記する。 通信中のメッセージが守られても、両端末には平文が残りうる。
根拠がなければ「不明（unknown）」のままにする。 Cryptomatorの公式文書は、クラウド同期時の通信元を匿名にすると約束していない。この項目は、推測で埋めず「不明」とした。不明だから情報が見えるとも、守られるとも言えない。
件数を点数へ変えない。 観測者も結果の重さも違う6項目を足しても、製品のプライバシーを正しく測る数字にはならない。

4番目の制約は、監査で特に重視した点である。評判から答えを補わず、Cryptomatorの1項目を意図的に「不明」のまま残した。また、判定前にすべての行へ観測者を明記した。表を埋めることより、出典が言える範囲を守ることのほうが重要だ。そうしなければ、見た目だけ整った比較表を根拠に、実際に情報が漏れる部分とは別の設定を変えてしまう。

別々の記録を同じ人へ結び付ける6つの手掛かり
#

以下は、各道具の資料を組み合わせてCoraが導いた推論である。1社が3つの道具を組み合わせた作業全体を実測した結果でも、特定の利用者を再識別できるという事業者の主張でもない。NISTの用語集は、**非関連化（disassociability）**を、運用上必要な範囲を超えて個人や端末へデータや出来事を結び付けずに処理できる性質と定義している。3つの用途に長く残る共通点があれば、この性質は失われる。

結び付ける手掛かり	例	記録を照合できる相手	分離する方法
別名またはアカウント	SimpleXのプロフィール、取引所の記録、クラウドアカウントで同じ名前を使う	取引相手、アカウント事業者、データブローカー	用途ごとに異なる身元を使い、復旧メールを共有しない
端末	侵害された1台のノートPCから、ウォレット、チャット、開いた保管庫の平文が見える	マルウェア、端末管理者、デジタル鑑識の担当者	必要なら端末を分けるか、強く隔離された環境を使う。通常のOSアカウントは整理には役立つが、管理者権限やroot権限を持つマルウェアは止めない
通信経路	ウォレット、中継サーバー、クラウド同期が、同じ家庭の固定IPから接続する	ISP、VPN事業者、中継サーバー、補助データを持つクラウド事業者	機密性が必要な通信ごとに経路を明示的に決める。ファイルやプロトコルの暗号化でIPまで隠れると思い込まない
取引相手	同じ人がメッセージ、決済、ファイルのリンクを受け取る	受取人または販売者	取引に必要な項目だけを明かし、用途別のサブアドレスとリンクを使う
時刻とデータ量	メッセージ、決済、クラウドへのアップロードが数秒以内に続く	複数のログを参照できる観測者	まとめて処理し、必要なら時間をずらす。正確な金額やファイル名を実況しない
復旧情報	1つのメール、パスワードマネージャー、写真のバックアップから3つすべてを復旧できる	アカウントを奪った攻撃者、クラウド事業者、開示を強いられた保管者	復旧経路を分け、オフラインの情報も使う。各経路を別々に試す

時刻の扱いには慎重さが要る。出来事の時刻が近いことは手掛かりであって、2つの記録が同じ人のものだという証明ではない。それでも、メッセージ、決済、アップロードという同じ順序を繰り返せば、一度だけの一致より強いパターンになりうる。待ち時間を無作為に入れるだけで匿名になるとは考えるな。まず共通の身元や端末など、より強い手掛かりを減らし、その後で不要に正確な時刻情報を減らせ。

この問題は、AIによる再識別のガイドで扱った構図にも通じる。複数の弱い手掛かりが同じ識別情報を共有すると、機械で記録を結び付ける処理が容易になる。ここで扱う手掛かりは文体ではなく、機械で観測できる決済、通信、ファイル操作である。

共通の識別子を作らずに3つを使う8ステップ
#

先に脅威モデルを決め、用途を分け、ソフトウェアと連絡相手を検証し、必要な通信経路だけを守り、同期前に暗号化し、復旧を練習せよ。1つのアカウントまたは端末を失っても、3つすべてが露出しない状態を完成条件にする。

本物の資金や機密情報を移す前に、秘密情報を含まないテストデータを使って次の順序を試せ。

誰に何を見せたくないか、3つの文で書け。 例は「公開台帳から受取人と金額を読めないこと」「メッセージ中継サーバーが本文を持たないこと」「クラウド事業者がファイル名と内容を読めないこと」である。通信経路と端末を加えるのは、その危険に対処する負担が自分の状況に見合う場合だけにする。
用途ごとに身元を分けよ。 取引相手が決済、会話、ファイルを結び付けてもよいか決める。結び付けられたくないなら、別名、復旧メール、プロフィール画像、クラウドアカウントを共有せず、会話の内容から関係を明かさない。
公式配布元からソフトウェアを入手し、検証せよ。 プロジェクトがリリース署名や再現可能ビルドの手順を公開している場合は、それを確認する。Moneroは試験用ネットワークのstagenetで試し、SimpleXとCryptomatorには機密でないデータを使う。出所を確かめていない実行ファイルを、ほかの対策の土台にしてはいけない。
決済の保護範囲を設定せよ。 支払者または用途ごとに異なるサブアドレスを使う。外部ノードへウォレットの送信元IPを見せてはいけないなら、通信経路を別に設定して試す。取引相手側に残る情報も記録する。
メッセージの相手を確認せよ。 SimpleXで相手と接続し、独立した経路で本人確認用コードを照合する。incognito（接続ごとに、通常のプロフィールとは別の名前や画像を使う設定）と、通信接続の分離（transport isolation、連絡相手ごとにTCP接続を分ける設定）を確認し、通知と通話が脅威モデルに合うか決める。
ファイル保存を設定せよ。 ローカルで保管庫を作り、十分に長く、ほかでは使わないパスワードを設定する。復旧情報を別に保管してから暗号化済みのファイルを同期せよ。一時的な書き出しやアプリのバックアップによって、平文が別の場所へ残っていないか確かめる。
秘密情報を含まないテストデータで障害と復旧を練習せよ。 テスト用の保管庫を復元し、現行資料に従って秘密情報を含まないテスト用チャットプロフィールを復旧または移行する。ウォレットの復旧には、残高のないテスト用ウォレットか、意図的に隔離したテスト環境を使う。実際の資金を守る**seed（ウォレットを復元できる秘密情報）**を、ウェブサイト、クラウドサービス、未検証の端末、使い慣れていない復旧ツールへ入力してはいけない。練習中に既存ウォレットを上書きしてもいけない。緊急時になって、3つの復旧が同じ電話1台に依存していたと気付く事態を避けよ。
用途をまたぐ手掛かりを見直せ。 別名、端末、通信経路、取引相手、時刻、データ量、復旧経路を並べて比べる。運用上の利点がない共通点は外し、残すものは理由とともに記録する。

分離には費用がかかる。復旧情報が増え、操作が遅くなり、通知を逃し、通信経路の設定に失敗し、利用者自身の誤りも増えうる。目標は最大限に分けることではない。想定した観測者が記録を結び付けられないようにするための、最小限の分離である。セルフホスティングと主権のガイドでも、同じ原則をインフラに当てはめている。サービスを自宅へ移せば信頼する相手は変わるが、管理や復旧の危険は消えない。

結論——守るべき記録を先に選べ
#

公開台帳上の取引関係を守るならMonero、グローバルなプロフィールIDを使わずに連絡するならSimpleX、クラウド上のファイルを暗号化するならCryptomatorを使え。その後で、共通の身元、端末、通信経路、時刻、復旧情報を監査せよ。

クラウド事業者にファイル名を読ませないことだけが目的なら、Cryptomatorだけで答えになる場合がある。販売者がすでに法的な身元と配送先を知っているなら、Moneroでその販売記録は消せない。連絡相手を確認していなければ、SimpleXは暗号化したまま別人へ接続できてしまう。脅威モデルと対象がずれたままでは、道具を増やしても直らない。

保護を主張するなら、どの観測者から守るのかを必ず指定せよ。復旧経路は、必ず秘密情報を含まないテストデータで試せ。出典で確定できない項目は「不明（unknown）」のまま残せ。出典が約束していない性質まで埋めた、見た目だけ整った表より安全である。

要点

対象は3つに分かれる： Monero、SimpleX、Cryptomatorは、それぞれ別の記録を守る。決済、メッセージ、ファイルをまたぐ共通の匿名性は作らない。
公開台帳： Moneroのリングサイズは16で、うち15個がおとりである。この個数は、個人の匿名確率が「16分の1」であることを意味しない。
メッセージ： SimpleXは、接続をまたいで同じ利用者を示すグローバルなプロフィール識別子を使わない。一方、相手ごとのキュー識別子、通信時刻、端末内の履歴、一部の通知情報は残る。
ファイル保存： Cryptomatorは内容と名前を暗号化するが、更新時刻、数、保存後のサイズ、Cryptomatorと分かる保管庫形式は意図的に隠さない。
監査： Coraの検証済み台帳は、3つの道具×6項目の18行である。総合点も製品順位も作っていない。

よくある質問
#

3つの道具が守るのは、プロトコルと保存形式のうち、資料に明記された項目である。その周囲にある身元、通信経路、端末、復旧記録をまとめて隠すわけではない。まず観測者を決め、見える情報を変える対策だけを選ぶ必要がある。

Monero、SimpleX、Cryptomatorを一緒に使えば匿名になりますか？
#

いいえ。それぞれが守る記録は別です。取引相手、侵害された端末、同じIPを使い続ける通信経路、続けて起きる操作の時刻、共通の復旧アカウントから、作業全体を結び付けられる場合があります。匿名性は3つの製品名から得られる機能ではありません。想定した観測者が記録を結び付けられるかどうかで判断してください。

Moneroは外部ノードからIPアドレスを隠しますか？
#

初期設定では隠しません。Moneroの技術資料は通信元の保護を別の対策として扱い、TorまたはI2Pによる経路を説明しています。ウォレットが実際に使う経路を確認してください。公開台帳上で送金元、受取人、金額を守る仕組みから、IPアドレスまで隠れるとは推定できません。

SimpleXには識別子もメタデータもないのですか？
#

いいえ。全接続で同じ利用者を示すグローバルなプロフィール識別子は、メッセージ配送に使いません。しかし、相手ごとのキュー識別子と、運用に必要な記録が存在することは資料で確認できます。中継サーバー、連絡相手、通知サービス、ネットワーク上の観測者、端末では、それぞれ見える項目が違います。

クラウド事業者はCryptomatorを使っていることに気付きますか？
#

はい。Cryptomatorはファイルの内容と名前を暗号化しますが、保管庫の形式そのものを隠そうとはしません。暗号化オブジェクトの拡張子、設定ファイル、更新時刻、数、保存後のサイズは、クラウド側から見える場合があります。

復旧情報をすべて1つのパスワードマネージャーへ入れてもよいですか？
#

そのマネージャーと復旧経路が、3つすべてを結び付ける一点になることを脅威モデルで受け入れるなら選択肢になります。危険が大きい使い方では、まとめて失ったり奪われたりすると全体が露出する復旧情報を分けてください。そのうえで、分離が自分を締め出す原因にならないよう復旧を試してください。

出典
#

変更されうる公式資料13件について、原ページと日時が一致するWayback保存版を併記した。本文の主張は現在の公式ページに基づき、保存版は後から同じ資料を確かめるための第二経路として使う。

#	出典	URL	アーカイブ
1	Monero Docs——Technical Specs	https://docs.getmonero.org/technical-specs/	https://web.archive.org/web/20260808191457/https://docs.getmonero.org/technical-specs/
2	Monero——Frequently Asked Questions	https://www.getmonero.org/get-started/faq/	https://web.archive.org/web/20260730231338/https://www.getmonero.org/get-started/faq/
3	Monero Docs——Subaddress	https://docs.getmonero.org/public-address/subaddress/	https://web.archive.org/web/20260804004416/https://docs.getmonero.org/public-address/subaddress/
4	Monero Research Lab——OSPEAD	https://www.getmonero.org/2025/04/05/ospead-optimal-ring-signature-research.html	https://web.archive.org/web/20260423131819/https://www.getmonero.org/2025/04/05/ospead-optimal-ring-signature-research.html
5	SimpleX Chat——Privacy Policy and Technical Details	https://simplex.chat/privacy/	https://web.archive.org/web/20260725150448/https://simplex.chat/privacy/
6	SimpleX Chat——Privacy and Security	https://simplex.chat/docs/guide/privacy-security.html	https://web.archive.org/web/20260804190527/https://simplex.chat/docs/guide/privacy-security.html
7	SimpleX Chat Protocol——Threat Model	https://simplex.chat/docs/protocol/simplex-chat.html	https://web.archive.org/web/20260731210120/https://simplex.chat/docs/protocol/simplex-chat.html
8	SimpleX Chat——Audio and Video Calls	https://simplex.chat/docs/guide/audio-video-calls.html	https://web.archive.org/web/20260729214320/https://simplex.chat/docs/guide/audio-video-calls.html
9	Cryptomator Docs——Security Target	https://docs.cryptomator.org/security/security-target/	https://web.archive.org/web/20260512122357/https://docs.cryptomator.org/security/security-target/
10	Cryptomator Docs——Best Practices	https://docs.cryptomator.org/security/best-practices/	https://web.archive.org/web/20260722112824/https://docs.cryptomator.org/security/best-practices/
11	Cryptomator Docs——Vault Recovery	https://docs.cryptomator.org/desktop/vault-recovery/	https://web.archive.org/web/20260310220344/https://docs.cryptomator.org/desktop/vault-recovery/
12	Cryptomator Docs——Synchronization Conflicts	https://docs.cryptomator.org/desktop/sync-conflicts/	https://web.archive.org/web/20260706002907/https://docs.cryptomator.org/desktop/sync-conflicts/
13	NIST CSRC——Disassociability	https://csrc.nist.gov/glossary/term/disassociability	https://web.archive.org/web/20260622190616/https://csrc.nist.gov/glossary/term/disassociability

Cora Aegis

Cora Aegisは、CypherpunkGuideでプライバシーを最優先にしたOPSECの実践ガイドを書いている。この記事では、Monero、SimpleX、Cryptomatorについて観測可能な18項目を整理し、各行を公式資料へ結び付けたうえで、順位を付けないデータセットと検証スクリプトを作成した。

Cora Aegisについて詳しく読む →

配信者は、どこで暴かれるのか——5つの事例とドキシング防御（2026年）

Sun, 21 Jun 2026 00:00:00 +0000

配信者のプライバシーを説く記事は、どれも飛行前の点検リストのように読める。VPN を使え。メールは別にしろ。二段階認証を入れろ。写真からメタデータを消せ。背景に気をつけろ。助言そのものは間違っていない。すべてを守る配信者は、守らない配信者より確かに安全だ。（この記事を通じて——ドキシングとは、嫌がらせを目的に、本人の同意なくその私的な情報（実名・住所・身元）を晒すこと。スワッティングとは、虚偽の緊急通報で武装した警察を標的の自宅へ差し向けることを指す。）けれど実際の事例を読むと——本当に見つかり、スワッティングされ、つきまとわれ、引っ越しを強いられた配信者たちを読むと——違う絵が見えてくる。そのほとんどは、点検リストをまるごと飛ばしたから捕まったのではない。たった一つの急所で捕まった。しかも繰り返し現れる急所は、ほんの数えるほどしかない。

これが大事なのは、点検リストがすべての項目を同じだけ重要なものとして扱うからだ。いや、項目の重みは等しくない。2021年のユネスコによる女性ジャーナリストの調査では、回答者の73%がネット上の暴力を経験したとわかった。しかもその嫌がらせは、言葉から個人情報の暴露へと、決まったように激化していった（UNESCO、2021年）。とりわけ女性や LGBTQ+ の発信者にとって、ドキシングが終着点であることはまれだ——それはつきまといの一歩手前であり、スワッティングの通報、そして性的な脅迫の、その前段なのだ。性別に中立な指南書は、この代償をまるで勘定に入れない。

私たちはこの5つの記録された事例を、本シリーズがいつもそうするように読む——見せ物のためではなく、仕組みを見るために。下の表は、私たちが独自にまとめたものだ。それぞれの事例を、被害者が何を隠すべきだったかではなく、公開された身元を「所在の割れる標的」へと変えてしまった、たった一つの急所に対応づけた。

事例	急所	それがどう運用化されたか	そこから取り出せる教訓
Keffals（Clara Sorrenti）、2022年	投稿した写真に写り込んだ細部	スワッティング、写真から割れた所在、そして引っ越しの強制	メタデータだけでなく、背景を点検する
Valkyrae、Cinna、Emiru、2025年	リアルタイムの所在を、生で放送	つきまとう人物が、屋外生配信を追跡の標識に使った	屋外生配信は、それ自体が所在の信号だ
Dream、2022年	ブランドが頼る、伏せられた顔	流出写真と名前を結ぼうとする、何年もの集団的な試み	唯一の伏せた属性は、認証情報として守る
Nadia Amine、2022年	すでに出回っていた自宅住所	本人の新たなミスを必要としない、スワッティングの通報	住所のプライバシーは、すべての上流にある
Jacksfilms と SSSniperWolf、2023年	敵対する同業者が辿れる自宅の所在	公開の対立のさなか、ライバルが所在を晒した	脅威モデルには、あなた自身の業界も含まれる

5つを見渡すと、講じるべき守りの順序が組み替わる。やるべきは、隠すものを増やすことではない。あなたの配信形式、あなたの顔、あなたの視聴者に、どの急所が当てはまるのかを知り、まずそこを塞ぐことだ。

配信者にとって、「ドキシングされる」とは実際に何を意味するか
#

ドキシングとは、公の人格を、物理的に辿り着ける一人の人間へと変えることだ——そして配信者の場合、その材料は流出したデータベースではなく、放送そのものになる。「本人の意に反して私的な情報を晒す」という古典的な定義は、発信者に対してそれがどう効くのかを過小に語っている。配信者は、設計からして膨大な信号を自ら差し出す——何時間もの声、晒した顔、あるいは意図して伏せた顔、部屋、生活のリズム、リアルタイムでそこにいるという事実。攻撃者の仕事は、サーバーを破ることではない場合がほとんどだ。すでに映ってしまったものを突き合わせていく——窓からの眺め、宅配便のノック、反射、うっかり口にした通りの名前。それらを、一つの所在と一つの本名へと束ねるのだ。

だからこそ、配信者の脅威モデルは、一般のそれから枝分かれする。散らばった「無害な」信号を一つの身元へと融かし合わせるAI 規模の推論エンジンは、標的が生配信するとき、類を見ないほど豊かな素材へと向けられる。そして仮名の発信者が持つ、最も価値のある資産——Dream の事例のような、伏せられた顔——こそ、『あなたの声と顔は、もう「鍵」だ』で私たちが追った、まさに生体認証情報の一種だ。露出は、一度ふさげば終わる漏れではない。発し続けてしまうものを、管理し続けるしかないのだ。

主流の指南書が省く、二つ目の枝分かれがある。そして、この記事はそれを正面から言うために書かれた——脅威は、性別に対して中立ではない。 女性や LGBTQ+ の配信者にとって、ドキシングはほぼ確実につきまといと性的な脅迫へと拡大する。男性の標的が、これほどの頻度でも強さでも受けることはまれだ。この非対称は構造的なもので、どの「無害な」データが実は高リスクなのかを変えてしまう。だから下に独立した一節を立てた——競合するどの指南書も、そこに節を割かないからだ。

5つの事例、5つの急所
#

放送がどうやって所在になるのか。それを最も速く見る方法は、記録の残る5つの事例を並べ、それぞれに同じ問いを通すことだ——何が映ったか、それがどう運用化されたか、そしてどの一手があれば、その連鎖を断ち切れたか。これらは同時代の報道から引いた、報じられた出来事だ。具体的な事実はその出典に帰し、ここで再構成したものではない。

急所：データベースの穴ではなく、写真のなかの細部。 Keffals として知られるカナダの配信者・活動家 Clara Sorrenti は、2022年8月にスワッティングされた——彼女の名を騙った偽のメールをきっかけに、武装した警察がオンタリオ州ロンドンの自宅へ踏み込んだ。嫌がらせを組織する海外掲示板 Kiwi Farms が、彼女の情報をまとめて拡散したあとのことだ。彼女は逃げたが、嫌がらせは追ってきた。報道によれば、掲示板の利用者たちは彼女が共有した写真や投稿を子細に調べ、写り込んだ細部を突き合わせて、逃げた先を割り出していった——彼女は繰り返しの転居を、ある時には国外への移動さえ強いられた（NBC News、Vice）。最終的に Cloudflare は、人命への脅威を理由に、この掲示板へのサービスを打ち切った（Fortune）。教訓——あなたを暴くデータは、たいてい、あなたが自ら選んで投稿した何かの背景に潜んでいる。窓、ベッドカバー、街並みのシルエット。鍵をかけ忘れた記録のなかではなく。

— Keffals（Clara Sorrenti）——Kiwi Farms、2022年8月

急所：設計からして生で放送される、リアルタイムの所在。 2025年3月、配信者の Valkyrae、Cinna、Emiru は、IRL 配信（IRL stream＝屋外など現実の場から行う生配信）のマラソンを、予定より早く切り上げた。3人の居場所を突き止めた男が、配信中、カメラの前でグループを脅したからだ（Rolling Stone）。これはスワッティングでもデータベースの流出でもない。生放送そのものを追跡の標識に使った、現実のつきまとい犯だった——配信は、彼に必要なただ一つの問いに、絶え間なく、公の場で答え続けた。いま、彼女たちはどこにいるのか、と。教訓——屋外生配信は、絶え間なく続く所在の信号だ。急所は、配信者が隠し忘れた何かではなく、この形式が伝えるために作られている、まさにそのリアルタイムの存在そのものなのだ。

— Valkyrae、Cinna、Emiru——屋外生配信、2025年3月

急所：ブランド全体が頼る、たった一つの伏せた属性。 Dream は、世界で最も多くのフォロワーを持つマインクラフト系の発信者の一人で、顔を伏せたまま巨大な視聴者を築いた——だからこそ、その顔自体が、執拗な非匿名化キャンペーンの賞品になった。流出した、あるいは本人とされる写真を実名と結びつけようとする集団の試みは、何年も続いた。彼が自ら、管理された形で顔出しを選んだ2022年10月まで（Wikipedia）。要点は顔出しそのものではない。その前にあった圧力だ。教訓——仮名の価値のすべてが、たった一つの伏せた属性に乗っているとき——顔、本名、住んでいる都市——その属性は高価値の認証情報になる。そして動機を持った群衆は、辛抱強い。パスワードと同じように守ること。機能としては、まさにそうなのだから。

— Dream——伏せられた顔の価値、2022年

急所：すでに出回っていた住所。 配信者の Nadia Amine は2022年にスワッティングされた。その年、発信者を狙って相次いだスワッティングの一つだ（Sportskeeda）。ここでの決定的な急所は、個々の配信よりずっと前にある——いったん自宅の住所が、個人情報を売買する業者（data broker＝データブローカー）や掲示板の生態系へ漏れてしまえば、武装警察を差し向ける虚偽の緊急通報に、被害者のさらなるミスはもう要らない。教訓——住所のプライバシーは、すべての上流にある。データブローカーからの削除と、自宅の住所を公の人格と結びつけないこと。それが効く一手だ。放送のさなかに、漏れた住所を「なかったこと」にはできないのだから。

— Nadia Amine——スワッティング、2022年

急所：あなたの所在を、すでに握っている敵対的な同業者。 2023年10月の公開の対立のさなか、YouTuber の Jacksfilms は、同じ発信者である SSSniperWolf が自宅を晒したと非難した——彼女は、彼の家とされる建物の外から Instagram Live で配信したのだ。YouTube は、誰かの安全を危険にさらすプラットフォーム外の行為だとして、彼女の動画の一本を一時的に収益化停止にした（Tubefilter）。教訓は、発信者が最も聞きたくないものだ——あなたの脅威モデルには、あなた自身の業界も含まれる。 効く一手は、つきまとい犯やスワッターに対するものと同じだ——自宅を見つからないようにし、公の身元と結びつけないこと——ライバルの自制を当てにして、守りを築くことはできないのだから。

— Jacksfilms と SSSniperWolf——2023年10月

ひとまとまりに読むと、5つは無関係な5つの不運ではない。同じ結末——名前と場所——に至る、5つの異なる入口であり、それぞれが他の事例にはない一手を取り出している。Keffals は写真の背景を、Valkyrae はリアルタイムの信号を、Dream はたった一つの命綱となる秘密を、Nadia はずっと前に漏れた住所を、Jacksfilms は同僚でもある敵を示す。のっぺりした点検リストではなく、このパターンから守りを組めば、入口が実際にどこにあるかを見定めて、そこに力を注げる。

急所のパターン分類
#

上の記録にあるどの配信者ドキシングも、5つの急所のいずれかに行き着く——そして急所を名指せば、すべてを等しくやれと求める代わりに、あなたにとってどの一手が命綱なのかがわかる。この分類は、私たちが事例からまとめたものだ。のっぺりした点検リストが決して組み立てないフレームでもある——リストは守りを並べるが、露出が起きる具体的な道筋に対応づけないからだ。

急所のかたち	実際に漏れたもの	それを断つ一手
視覚／メタデータの露出	写真の背景、反射、あるいは EXIF データ（写真に埋まる撮影メタ情報。カメラが画像ファイルに記録する、隠れた技術的なメタデータ）に埋まった所在	メタデータを消し、さらに投稿前に全フレームの背景と反射を点検する
リアルタイムの所在（屋外生配信）	いまどこにいるか、生で伝わってしまう	屋外の所在は遅らせるか曖昧にする。固定された、戻ってこられる「ここ」を決して放送しない
仮名と属性の結びつき	ブランドが頼る、たった一つの伏せたもの（顔、本名、都市）	その属性を認証情報として扱い、公に晒す環境を徹底して狭める
出回っている住所	すでにブローカーや掲示板のデータにある自宅住所	データブローカーからの削除。自宅住所を、公の人格と結びつけない
敵対者による露出	ライバル、荒らし、元交際相手に武器化された、あなたの所在	自宅を見つからないようにする。すでに知っている敵には、一切の自制を期待しない

この分類は、飾りではなく診断のためのものだ。固定された自宅スタジオで顔を出す配信者は、たいてい一行目と四行目に生きる。屋外を旅する配信者は二行目に。身元のすべてが伏せた顔である発信者は、三行目で生きるか死ぬかが決まる。まず自分の行を見つけること。そこに対応する点検項目こそ、完璧にすべきものだ。残りは基本の心得ではあっても、あなたの最前線ではない。

性別という層——ドキシングがつきまといと性的な脅迫になるとき
#

女性や LGBTQ+ の配信者にとって、露出が露出のまま止まることはまれだ——それはつきまとい、性的な脅迫、そして身に迫る恐怖へと、不運な激化ではなく、予測できるパターンとして転じる。これこそ、プライバシーの点検リストがほぼ一様に省く次元だ。そして省けば、女性が実際には同じ形で受けない脅威に合わせて、守りが調整されてしまう。漏れた住所は同じでも、そこへ届くものは違う。

事例の記録は、この非対称をはっきりと示す。トランス女性である Keffals は、ただドキシングされただけでなく、スワッティングされ、幾度もの転居を越えて追い回された。Valkyrae の事案は、放送のさなかの、3人の女性に対する現実の脅迫だった。どちらも、一般の指南書が暗に想定する「気まずいツイートが蒸し返される」というモデルには当てはまらない。データも、個々の事例を越えてこのパターンを裏づける。UN Women は、女性に対するテクノロジーを用いた暴力——ドキシング、ストーカーウェア、画像を使った虐待などを含む——を、ジェンダーに基づく暴力の、独立した、しかも拡大しつつあるカテゴリーとして記録している（UN Women）。Equality Now は、ドキシングに対する個別の法的保護がほぼ存在しないために、女性がつきまといと嫌がらせの高まったリスクに晒されている、と論じている（Equality Now）。

脅威モデルにとって、これは具体的に二つを変える。第一に、「無害な」データは、誰にとっても等しく無害なわけではない。 カメラに映る顔、配信で触れた交際関係、日常を映す動画にちらりと写る近所——どれもが、抽象的な標的を想定して書かれた性別に中立な指南書が決して織り込まない形で、女性にとっては性的な、あるいはつきまといの攻撃の材料になる。第二に、人間関係（ソーシャルグラフ）は、二次的ではなく一次的な経路だ——交際相手、家族、そして視聴者が期待するリアルでの集まりが、標的へと至る道になる。だからこそ下の守りは、自宅と人間関係の区画化を、女性や LGBTQ+ の発信者にとって上級者向けの追加ではなく、中核の一手として扱う。

主権ある仮名による守り
#

仮名とは、誰かに名前を当てられるまで身につけている変装ではない——それは、稼ぐ人格と、どこかに住む法的な一人の人間とのあいだに立つ、構造的な防火壁だ。その仕事は、たった一つの漏れを致命傷にしないことにある。配信者向けの指南書は、「芸名を使え」を点検リストの一行として扱う。いや、それは他のすべてが掛かる土台だ。衣装としてではなく防火壁として作るなら、それは運用上の身元と法的な人格が、メールも、電話番号も、決済手段も、宅配の届け先も、使い回しのハンドルも、決して共有しないことを意味する——だから一つの信号が漏れても、それが連鎖の残りを引きずり出さない。その二つを今すでに結びつけているものを洗い出す手引きが、消えないデジタルの足跡だ——ドキシングを仕掛ける側の材料は、まさにその手引きが「刈り取れ」と教える痕跡そのものなのだ。

敵対的な国家のもとで発信する活動家を守るのと同じ区画化が、配信者を守る。根っこにある問題が同じだからだ——本気の敵は、漏れた身元を最初の一手として扱う。そして持ちこたえる守りとは、決して特定されないことにすべてを賭けるのではなく、手の届きやすさを握ること——どの住所が、どの管轄が、どの名前が、実際に行動の標的になりうるかを握ることだ。具体的に、発信者にとってそれは、いくつかの譲れない一線を意味する。

層	露出	仮名による一手
身元	一つの漏れた項目（メール、電話、決済）が残りをほどく	完全な分離：人格は、法的な人間とアカウントも番号も住所も共有しない
自宅	公の名前に結びついた、戻ってこられる物理的な場所	自宅住所を人格に決して結びつけない。公に晒すものには、登記上の代理人、私書箱、事業所の住所を
伏せた属性	ブランドが伏せることに頼る、顔、本名、都市	パスワードのように、晒す環境を最小化する。群衆は際限なく試してくると前提する
リアルタイムの存在	屋外、あるいは「いまここから生配信」という信号	遅らせ、曖昧にし、地域を絞る。どこにいるかと、そこにいると言う時刻を切り離す

ただし、限界には正直であること。約束しすぎる守りは、それ自体が一つの失敗だからだ。仮名は、絶え間ない突き合わせのもとで劣化する——発信するほど、推論エンジンに与える材料が増えていく——だからそれが買うのは安全と時間であって、永続ではない。そして法的な層は薄い。多くの管轄では、いまだにドキシングを名指しで禁じる法律がなく、スワッティングに関する法も大きくばらつき、存在する保護も、遅い、事後の救済であって、リアルタイムの盾ではない。法は、隠れる壁ではなく、記録しておくべき手立てとして扱うこと。

一人でできることの、限界
#

ここに、正直な限界がある。これを覆い隠す記事は、本シリーズが正そうとしてきた当の省略を、自ら繰り返すことになる。個人の OPSEC は、個人を守る。だが、配信者へのドキシングを安く成り立たせている嫌がらせのインフラを、解体はしない。そして、あなたを見つけるために組織された掲示板や、すでに発せられたスワッティングの通報に対しては、個人の技術は、必要であると同時に、それだけでは足りない。あなたは身元を区画化し、背景を点検し、何百ものブローカーサイトから住所を削除できる。だがあなた一人では、嫌がらせを取りまとめる掲示板を閉じることも、被害が降りかかる前にプラットフォームを動かすことも、あなたの管轄に欠けているドキシング禁止の法律を書くことも、できない。

事例をひとまとまりに読めば、そう告げている。Keffals に技術が足りなかったのではない——彼女は組織された掲示板に追い回され、ついに大手のインフラ事業者がサービスを打ち切るまで続いた。発信者へのスワッティングの通報が成功するのは、緊急対応の仕組みが、どんな個人が固めるより速く武器化されうるからだ。こうした条件を実際に動かすのは、個人の暗号術が制度の権力とぶつかる場所でサイファーパンクが指し示してきた、効く一手だ——集団の応答と、規則そのものの変革。束になった嫌がらせを締め出すプラットフォーム、それを運ぶことを拒むインフラ事業者、スワッティング対策の登録制度と法律、そして孤立して立ち向かう代わりに脅威の情報を分かち合う発信者コミュニティ。個人の守りは、安全と時間を買う。だがそれ自体では、そもそも嫌がらせを仕掛ける側の代償を、引き上げはしない。

「プライバシーとは、自分自身を世界に対して選択的に明かす力である。」——Eric Hughes『A Cypherpunk’s Manifesto』、1993年

配信者の技そのものが、選択的に明かすことだ——人格は伏せたまま、その演技を見せる。攻撃者の企ては、そこから選択的にを剥ぎ取ることにある。個別の事案を守れ——そのうえで、それを生む条件を押し返せ。嫌がらせの掲示板が、善意から発信者にプライバシーを与えてくれることなど、ないのだから。Privacy（プライバシー）の柱の残りは、同じ戦いを別の戦線で描く。

結論——どの守りが、あなたのリスクに合うか
#

正しい最前線は、あなたの配信形式、あなたの伏せた属性、そして誰にあなたを探す動機があるか——すべてはそこで決まる。

屋外で配信する、あるいはカメラを連れて移動するなら： あなたの急所はリアルタイムの所在だ。どこにいるかと、そこにいると言う時刻を切り離せ——放送を遅らせ、正確な場所を曖昧にし、固定された、戻ってこられる「ここ」を決して作らない。どれだけメタデータの心得を守っても、この形式が生で伝えるために作られた信号は塞げない。
ブランドが、伏せた顔や名前に頼っているなら： その一つの属性を、気軽に扱える秘密ではなく、認証情報として扱え。公に晒す環境を徹底して狭め、辛抱強い群衆があらゆる漏れを突き合わせていると前提し、次の顔出しの圧力に押される前に、『あなたの声と顔は、もう「鍵」だ』を読んでおくこと。
あなたが女性、あるいは LGBTQ+ の発信者なら： 性別に偏る激化を、最初から織り込め。露出はつきまといと性的な脅迫になりやすく、あなたの自宅と人間関係を経由しやすい。だから自宅住所の区画化とソーシャルグラフの分離は、あなたにとって上級者向けではなく、中核の一手だ。

三つのどれにも、それ以前のあらゆる OPSEC の失敗が証明してきた真実が、そのまま当てはまる——いったんあなたの身元が最初の一手として扱われれば、漏洩を「なかったこと」にして安全へ戻ることはできない。あなたにできるのは、配信を始める前に決めることだけだ——あなたの形式が、どの急所を晒すのか。そしてまずそこを塞ぎ、それから他の発信者とともに動いて、嫌がらせそのものの代償を、引き上げることだ。

要点

人は点検リスト全体ではなく、一点で捕まる： 記録の残るどの事例でも、ドキシングはたった一つの急所から成功した——写真の背景、リアルタイムの所在、伏せた顔、漏れた住所、敵対的な同業者——だから自分の急所を見つけ、まずその一手を完璧にすること。
Keffals、2022年——背景こそが漏れだ： スワッティングされたあと、Clara Sorrenti は、掲示板の利用者が投稿画像の細部を突き合わせるたびに、繰り返し転居を強いられた。Cloudflare は最終的に、人命への脅威を理由に、嫌がらせ掲示板へのサービスを打ち切った。
Valkyrae、Cinna、Emiru、2025年——屋外生配信は生の所在信号だ： 3人は、追跡してきた現実のつきまとい犯がカメラの前でグループを脅したのち、マラソンを早めに切り上げた——データベースの侵入は要らなかった。
仮名は防火壁であって、衣装ではない： その価値は、一つの漏れた項目が残りをほどくのを防ぐことにある。だから人格は、法的な人間とメールも電話も決済も住所も共有してはならない。
指南書が飛ばす、性別の層： 女性や LGBTQ+ の発信者にとって、露出は確実につきまといと性的な脅迫になる——ユネスコの調査では、回答した女性ジャーナリストの73%がネット上の暴力を経験していた——自宅とソーシャルグラフの分離を、おまけではなく中核の一手にする。
限界： 個人の OPSEC は安全と時間を買うが、嫌がらせの掲示板を閉じることも、プラットフォームを間に合うよう動かすことも、ドキシング禁止の法律を書くこともできない——それには、プラットフォームの行動、インフラの拒否、そして発信者の集団的な守りが要る。

よくある質問
#

配信者は、どうやってドキシングされるのですか？
#

ほとんどの場合、データベースの侵入ではなく、すでに放送されたものを突き合わせることによってです。繰り返し現れる急所は、写真の背景やメタデータに隠れた所在、屋外生配信中に伝わるリアルタイムの所在、ブランドが頼るたった一つの伏せた属性（顔や本名）、すでにデータブローカーや掲示板のデータへ漏れた自宅住所、そして対立のさなかに所在を晒す敵対的な同業者です。攻撃者の仕事は、散らばった「無害な」信号を、一つの名前と一つの場所へと融かし合わせることにあります。

VPN は、配信者をドキシングから守りますか？
#

狭い一つの経路に対してだけです。VPN は IP アドレスを隠します。それ自体は大切ですが、実際に配信者を捕まえる急所に対しては何もしません——窓の外に見えるランドマーク、カメラに映る宅配、顔出し、あるいはすでにブローカーサイトで出回っている住所。VPN は、守りそのものではなく、必要な一項目として扱うこと。命綱となる一手は、背景の点検、住所の削除、そして身元の区画化です。

なぜドキシングは、女性配信者を違う形で狙うのですか？
#

女性や LGBTQ+ の発信者にとって、露出が気まずさで終わらず、確実につきまといと性的な脅迫へと拡大するからです。UN Women は、テクノロジーを用いたジェンダーに基づく暴力——ドキシング、ストーカーウェア、画像虐待などを含む——を独立したカテゴリーとして扱い、Equality Now は、ドキシングを名指しで禁じる法律の欠如を、女性のつきまといリスクの高まりに結びつけています。上の性別の層の節で述べたとおり、これは顔、交際関係、近所のデータをより高リスクなものにし、自宅とソーシャルグラフの分離を、中核の一手にします。

仮名は、本当に配信者を守りますか？
#

はい、衣装ではなく防火壁として作るなら。仮名の守りは、完全な分離から生まれます——人格と法的な人間が、メールも、電話も、決済手段も、住所も共有しないこと——だから一つの漏れた項目が、残りをほどきません。それは、絶え間ない突き合わせのもとで劣化する、時間稼ぎの守りであって、永続の盾ではありませんが、他のあらゆる一手が頼る土台です。あなたの本当の決済情報を共有する芸名は、何も守りません。

ドキシングされたら、まず何をすべきですか？
#

すべてを記録すること——日付の入ったスクリーンショットを、個人の端末に保存して。そのうえでプラットフォームに通報し、物理的な脅威が少しでもあれば、地元の警察にも連絡すること——そして、あなたの地域でスワッティング対策のプログラムが運用されているなら、事前に登録しておくこと——警察によっては、リスクのある住民が自分の住所に印をつけ、通報が虚偽かもしれないと指令係に知らせられる仕組みがあります。並行して、自宅の住所はもう漏れていると前提すること。データブローカーからの削除を始め、その住所に結びついたアカウントや人物も、同じく露出していると扱うこと。事後の後始末は予防より難しいものですが、記録された時系列こそ、のちのあらゆるプラットフォームや法的な対応が必要とするものです。

#	出典	URL	アーカイブ
1	NBC News——Cloudflare、Kiwi Farms、Keffals（2022年9月）	https://www.nbcnews.com/tech/internet/cloudflare-kiwi-farms-keffals-anti-trans-rcna44834	https://web.archive.org/web/*/https://www.nbcnews.com/tech/internet/cloudflare-kiwi-farms-keffals-anti-trans-rcna44834
2	Vice——Keffals と Kiwi Farms	https://www.vice.com/en/article/xgyagd/keffals-kiwi-farms	https://web.archive.org/web/*/https://www.vice.com/en/article/xgyagd/keffals-kiwi-farms
3	Fortune——Cloudflare が人命への脅威を理由に Kiwi Farms を遮断（2022年9月）	https://fortune.com/2022/09/05/kiwi-farms-so-bad-cloudflare-feared-immediate-threat-to-human-life-for-clara-sorrenti-keffals/	https://web.archive.org/web/*/https://fortune.com/2022/09/05/kiwi-farms-so-bad-cloudflare-feared-immediate-threat-to-human-life-for-clara-sorrenti-keffals/
4	Rolling Stone——女性 Twitch 配信者と嫌がらせ（2025年）	https://www.rollingstone.com/culture/culture-features/valkyrae-cinna-emiru-women-twitch-streamers-harassment-1235289509/	https://web.archive.org/web/*/https://www.rollingstone.com/culture/culture-features/valkyrae-cinna-emiru-women-twitch-streamers-harassment-1235289509/
5	Wikipedia——Dream（YouTuber）、2022年10月の顔出し	https://en.wikipedia.org/wiki/Dream_(YouTuber)	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Dream_(YouTuber)
6	Sportskeeda——配信者へのスワッティング、Nadia Amine（2022年）	https://www.sportskeeda.com/esports/news-swatting-turns-wholesome-cop-asks-chat-start-hype-train-swatted-warzone-streamer	https://web.archive.org/web/*/https://www.sportskeeda.com/esports/news-swatting-turns-wholesome-cop-asks-chat-start-hype-train-swatted-warzone-streamer
7	Tubefilter——Jacksfilms、SSSniperWolf、YouTube の収益化停止（2023年10月）	https://tubefilter.com/2023/10/23/youtube-demonetizes-sssniperwolf-jacksfilms-house/	https://web.archive.org/web/*/https://tubefilter.com/2023/10/23/youtube-demonetizes-sssniperwolf-jacksfilms-house/
8	UNESCO——The Chilling：女性ジャーナリストへのネット上の暴力（2021年）	https://www.unesco.org/en/articles/global-survey-reveals-rising-violence-against-women-journalists	https://web.archive.org/web/*/https://www.unesco.org/en/articles/global-survey-reveals-rising-violence-against-women-journalists
9	UN Women——テクノロジーを用いたジェンダーに基づく暴力に関する FAQ	https://www.unwomen.org/en/articles/faqs/digital-abuse-trolling-stalking-and-other-forms-of-technology-facilitated-violence-against-women	https://web.archive.org/web/*/https://www.unwomen.org/en/articles/faqs/digital-abuse-trolling-stalking-and-other-forms-of-technology-facilitated-violence-against-women
10	Equality Now——ドキシングに対する法的保護の欠如と女性のリスク	https://equalitynow.org/news/press-releases/lack-of-legal-protections-against-doxing-is-putting-women-at-greater-risk-of-online-stalking-and-harassment/	https://web.archive.org/web/*/https://equalitynow.org/news/press-releases/lack-of-legal-protections-against-doxing-is-putting-women-at-greater-risk-of-online-stalking-and-harassment/
11	PEN America——オンライン嫌がらせ実務マニュアル：ドキシングから情報を守る	https://onlineharassmentfieldmanual.pen.org/protecting-information-from-doxing/	https://web.archive.org/web/*/https://onlineharassmentfieldmanual.pen.org/protecting-information-from-doxing/
12	Activist Checklist——ドキシング防御	https://activistchecklist.org/doxxing/	https://web.archive.org/web/*/https://activistchecklist.org/doxxing/

Cora Aegis

Cora Aegis は CypherpunkGuide で、プライバシーを最優先する OPSEC の指針を書いている。決着のついた嫌がらせの事例を、ほとんどの報道が飛ばす「仕組み」から読み解く——ここでは、配信者の放送を所在へと変えてしまう、たった一つの急所と、なぜそれが女性にいちばん重くのしかかるのかを。

Cora についてもっと読む →

権威主義国家は、亡命した活動家をどう暴くのか——ドキシング防御の OPSEC（2026年）

Fri, 19 Jun 2026 00:00:00 +0000

国を出れば、危険は終わる——はずだった。国境を越え、亡命を申請し、また自分の名前で書きはじめる。故郷で背負っていた脅威モデルは、その境界線で失効する。それが亡命の約束だ。そして、活動家向けのセキュリティ助言の多くが、口には出さずに受け継いでいる前提でもある——とにかく外へ出ろ、しばらく身を潜めろ、そうすれば逃げてきた国の手はもう届かない、と。

いや、手は届く。2023年、香港の国家安全維持部隊は、ボストン、ロンドン、メルボルンに暮らす活動家へ、逮捕令状と 100万香港ドル(HK$1M)の懸賞金をかけた。地球の反対側で口にした言葉にまで管轄が及ぶ、と称する法律を根拠にしてだ。ベラルーシはかつて、国際空域を飛ぶ旅客機を無理やり着陸させ、機内にいた一人の反体制ジャーナリストを捕らえた。フリーダム・ハウスの2025年報告は、2014年以降、物理的な国境を越えた弾圧(transnational repression)の事案を1,375件記録している。54の政府が、107の受け入れ国にまたがって行ったものだ。しかもこの数字は、たいてい先に到着するデジタルな攻撃を、意図して除いている——数えにくく、止めるのはもっと難しいからだ。

私たちはこの三つの事例を、本シリーズがいつもそうするように読む——憤りのためではなく、仕組みを見るために。懸賞金の告知と裁判記録を並べて読むと、安全チェックリストが描くのとは違うパターンが浮かび上がる。ドキシング(個人情報の暴露)が、恨みを抱えた一匹狼の仕業であることはまれだ。それは国家による作戦の最初の一手であり、しかも女性には、ジェンダーに中立な指南書が想定しない形で重くのしかかる。そして、あなたを本当に守るのは、巧妙な仮名ではない。どこから、いつ発信するか——守りはその一点にある。

下の表は、私たちが独自にまとめたものだ。三つの報道事例を、ドキシング指南書が飛ばす軸に沿って並べた——何が漏れたかではなく、その漏洩が、どうやって国境を越える「到達」へと運用化されたか、という軸に。

事例	ドキシングの手口	国家はそれをどう運用化したか	そこから取り出せる OPSEC の教訓
ベラルーシ——Protasevich、2021年	旅程と時刻を、事前に把握	物理的に逮捕するため、旅客機を強制着陸	露出は身元ではなく、移動の時刻と動線のメタデータだ
香港——HKLeaks と懸賞金、2019〜2023年	個人情報の「ドキシング・カード」約2,800件。のちに、名指しの亡命者へ懸賞金	群衆による嫌がらせが、域外令状と親族への圧力へと拡大	あなたの人間関係(ソーシャルグラフ)と家族が、攻撃面だ
中国——越境ネットワーク	身元と所在を集約し、国家間で共有	インターポールの悪用、代理人による嫌がらせ、受け入れ国の協力者の取り込み	管轄(jurisdiction)そのものが、あなたに動かせる変数だ

三つを並べて見ると、講じるべき守りの順序が組み替わる。この人たちは誰一人、仮名が弱かったから捕まったのではない。漏れた身元を、国境を越える作戦の第一歩として国家が扱ったから、手が届いたのだ。それは「匿名でブログを書く方法」が解こうとする問題とは、別物だ。

権威主義国家のもとで、ドキシングは何を意味するか
#

権威主義国家の文脈で、ドキシングは屈辱で終わるネット上の残酷さではない——それは国家弾圧の偵察(reconnaissance)段階であり、批判者を「所在が割れ、逮捕でき、圧力をかけられる標的」へと変える一手だ。実名、住所、勤務先、家族関係を公開する。同じ行為でも、その漏洩を使うのが匿名の暴徒ではなく、令状を持つ政府や、情報機関や、外交機構であれば、意味はまるで変わる。学術文献はドキシングを、「非匿名化」から「標的化」へと幅のある、意図の段階として論じる。敵対国家のもとでは、それが一つに潰れる。漏洩こそが、標的化なのだ。

この捉え直しが大事なのは、あなたが守るべきものが変わるからだ。嫌がらせに対しては、見知らぬ他人に情報を渡さないことが目標になる。国家に対しては、情報はすでに握られていることが多い。あなたが拒むべきは、その運用だ——リストに載った名前が、親族の戸口を叩く一手に変わる、その瞬間を止めることだ。国際テロ対策センター(ICCT)のドキシングに関する文献レビューは、この手口が個人的な復讐から、組織化された政治的道具へと移っていった経緯をたどっている。以下の事例は、その移行が完成した姿だ。

標準的な指南書がまるごと省く、二つ目の捉え直しがある。そして、この記事はそれを正面から言うために書かれた——脅威は、性別に対して中立ではない。 女性活動家にとって、ドキシングは確実に性的な脅迫へと拡大する——レイプの脅迫、加工された性的画像、そして家族や人間関係の武器化が、男性の標的が同じ強さで受けることはまれな形で襲ってくる。この非対称は、脚注ではない。弾圧が性別に偏って設計されている、その構造的な特徴であり、守りの計算を変える。競合するどの指南書もやらないから、私たちは下に独立した一節を立てた。

三つの事例——ミンスク、香港、そして国境なきネットワーク
#

漏洩がどうやって「到達」になるのか。それを最も速く見る方法は、記録の残る三つの事例を並べ、それぞれに同じ筋道をたどることだ——標的について何が知られていたか、国家はそれをどう使ったか、そして手元の OPSEC に何かを変えられた余地があったとすれば、それは何か。これらは同時代の報道と一次資料から引いた、決着のついた事例だ。ここで示す具体的な事実は、すべて原出典による。

仕組み：旅行のメタデータが、リアルタイムで武器になる。 亡命中のベラルーシ反体制ジャーナリスト、Roman Protasevich は、アテネ発ヴィリニュス行きの Ryanair 4978便に搭乗した。機体がベラルーシ空域を飛んでいるあいだに、当局は虚偽の爆破予告を無線で送り、MiG-29 戦闘機を緊急発進させて、機をミンスクへ着陸させた。Protasevich と同行者の Sofia Sapega は、ゲートで逮捕された。国家は彼を探す必要すらなかった——旅程を知っていて、それに沿って動いた。日常の一便を、制御された傍受作戦に変えてみせたのだ。(GPIL、ボン大学)

その後の経緯が、よくある誤読を正す。Protasevich は2023年5月に8年の判決を受け——その19日後にルカシェンコによって恩赦された。協力を引き出され、それを見せ物にされたうえで。実際の拘束は8年ではなく、2年に近い(Al Jazeera)。Sapega も別に6年の判決を受けたが、同じく2023年に恩赦され、ロシアへ引き渡された。教訓は判決ではない。露出は、仮名の強さではなく、移動の時刻と動線のメタデータだったこと——そして国家は、それに沿って動くためなら、国際的な事件一つを費やす、ということだ。

— ベラルーシ——Ryanair 4978便、2021年5月23日

仕組み：群衆によるドキシングが、域外令状へと拡大する。 2019年8月から、HKLeaks のネットワークは、抗議者・ジャーナリスト・当局者の個人情報を暴く「ドキシング・カード」を公開した——シチズン・ラボのフォレンジック調査によれば、約2,800人ぶん。同調査は、これを草の根の行為に帰すのではなく、政府系組織がこのキャンペーンを実施したか、積極的に支援した可能性を示す状況証拠を見いだした。データは原材料であり、到達距離を与えたのは国家安全維持法だった。

2023年までに、その到達は完全に域外へ及んだ。どこで、誰によって行われた行為にも管轄が及ぶ、と称する第38条を根拠に、香港警察は逮捕令状と 100万香港ドル(HK$1M)の懸賞金をかけた——まず7月に、海外の活動家8名の第1陣に(ヒューマン・ライツ・ウォッチ)、続いて12月にさらに5名へ。そのなかには、ボストンを拠点とする活動家 Frances Hui がいた(Hong Kong Free Press)。名指しの標的に手が届かないと、圧力は届く相手へ移った。香港にいる Hui の両親は国家安全維持部隊に呼び出された。亡命活動家の家族に対する、記録された拡大の一環だ(HRW、2025年)。教訓——あなた本人に手が届かなくなったその瞬間、あなたの人間関係(ソーシャルグラフ)と親族が、攻撃面になる。

— 香港——HKLeaks と域外の懸賞金、2019〜2023年

仕組み：管轄を渡り歩き、代理人に執行させる。 ベラルーシが直接動き、香港が懸賞金を通じて動いたのに対し、中国のより広い機構は他国の制度を通じて動く——インターポールの赤手配を悪用し、受け入れ国のビジネスやディアスポラ(離散した同胞)の協力者に圧力をかけ、地域社会の一員を装う工作員を起訴させる。米国では、申告のない海外「警察署」を運営した工作員や、民主活動家を長年装いながら、反体制派を北京の国家安全部に通報していた長期エージェントに、連邦裁判で有罪判決が下っている(NBC News)。

最も強力な変数を取り出すのが、この事例だ。こうした作戦が機能するのは、法体系のあいだの継ぎ目を突くからだ——引き渡し請求や、ビザの記録や、レジストラ(ドメイン登録業者)のコンプライアンス窓口が開ける、その隙間を。だとすれば、個人が実際に選べる変数は、管轄そのものだけだ——ドメインをどこで登録するか、サーバーをどこに置くか、どのプラットフォームがアカウントを保持するか。この点は、最後の各節で改めてたどる。

— 中国——国境を越えた弾圧のネットワーク

三つを重ねて読むと、これらは無関係な出来事ではなく、ひとつの拡大の階段を描く。ベラルーシは、すでに握っていたメタデータに国家が動く姿を示す。香港は、漏洩(HKLeaks)と執行(懸賞金、家族への圧力)が、標的が国境を越えたとき一緒に越えてきた、ひとつの作戦の両半分であることを示す。中国は、その成熟形を示す——本来は避難所を差し出すはずだった、まさにその国々の制度を経由して回される弾圧だ。どの段でも、活動家を危うくしたのは身元ではなかった——手が届くこと、それが本当の弱点だったのだ。

性別という層——ドキシングが性的な脅迫になるとき
#

女性活動家にとって、ドキシングのキャンペーンが暴露で止まることはまれだ——それは確実に性的な脅迫へと転じる。そしてその転換は、不運な副作用ではなく、意図された弾圧の手口だ。これこそ、ドキシング指南書も OPSEC チェックリストも、ほぼ一様に省く次元だ。そして省けば、女性が実際には同じ形で受けない脅威に合わせて、守りが調整されてしまう。暴露は同じでも、次に来るものが違う。

香港の抗議運動は、このパターンを大規模に可視化した。HKLeaks のデータと並んで、女性の抗議者やジャーナリストは、性別に偏った嫌がらせの並行キャンペーンに直面した——レイプと殺害の脅迫、そして性的に露骨に見えるよう加工され、辱めのために再拡散された写真だ。当時の報道は、女性抗議者の画像が裸に見えるよう改変されたこと、名指しのジャーナリストが運動を取材しながらレイプの脅迫を受けたことを記録している(France 24、2019年)。加工画像の狙いは、だますことではない——偽物だと、誰もが知っている。狙いは、これから先のあらゆる検索結果で、あなたの名前に性的な辱めを貼りつけること。そして、あなたの主張だけでなく、あなたの身体が、正当な標的なのだと告げることだ。

この手口は、それ以来ただ産業化してきた。2025年、亡命した香港の活動家たちは新たな波を報告した——懸賞金リストに載った、名指しの女性の偽の性的画像が、印刷され、英国やオーストラリアの近隣住民へ郵送されたのだ。著名な活動家一人の事案はテムズ・バレー警察が捜査中で、ある男性活動家の妻も同様に、性的なポスターを自宅住所に送りつけられた(Reuters、U.S. News 経由)。拡大の仕方は、正確だ——ネット上の画像から物理的な郵便へ、標的本人からその周りの人々へ。三つの圧力を一つの行為に束ねている——性的な辱め、家族と地域社会の露出、そしてあなたの住む場所を知っているという暗黙のメッセージを。

脅威モデルにとって、これは具体的に二つを変える。第一に、「無害な」データは、誰にとっても等しく無害なわけではない——顔写真、交際関係の有無、自宅の地域は、性別に中立な標的を想定した一般の指南書が決して織り込まない形で、女性にとっては性的攻撃の原材料になる。第二に、家族と親密な関係は、二次的ではなく一次的な経路だ——だからこそ下の守りの各節は、ソーシャルグラフの分離と家族の連絡計画を、上級者向けの追加機能ではなく、中核の守りとして扱う。偽物をいまや安価に量産できる、この合成メディアの問題は、『あなたの声と顔は、もう「鍵」だ』でたどったのと同じ仕掛けであり、そしてそれは、まさにこの場面で最も重くのしかかる。

弾圧下で発信するための脅威モデル
#

国境を越えた弾圧を生き延びる守りは、道具リストがひっくり返している一つの原理に立つ——インフラを移すほうが、身元を隠すより長く効く。管轄は変えられる。だが、本気の国家が時間をかけて身元を割る能力は、変えられない。身元の秘匿は、時間稼ぎの戦術だ——価値はあるが、国家がより多くのデータを突き合わせるにつれて、時とともに劣化する。インフラの主権(sovereignty)は構造的だ——それはどの主体があなたに不利な行動を強いられうるかを決める。そして、上の事例がすべて転んだのは、その変数の上でだった。守りは層に分けて組む。防ごうとする「到達」の種類に、それぞれ合わせて。

発信する身元を、法的な人格から、早い段階で切り離す。 最初の投稿の前に、自分が仮名の個人として発信するのか、集団としてか、名のある媒体としてかを決める——その選択が、責任のかかり方の全体を定め、あとで変えるのは苦痛だからだ。仮名の集団は、帰属を拡散させる。名のあるジャーナリスト媒体は、発行者としての責任を負うが、一人のブロガーには使えない報道の自由の保護を発動できる。万人に通じる答えはない。あなたの管轄と、あなたが受け入れられる露出の水準に合った答えがあるだけだ。万国共通なのはこれだ——運用上の身元と法的な人格に、メールアドレス、電話番号、決済手段、使い回しのハンドルを共有させてはならない。AI 規模の推論エンジンが使う非匿名化の手口は、まさにそうした「無害な」重なりの突き合わせだ。

インフラは、利便ではなく「誰が強要されうるか」で選ぶ。 これは、主流の指南書が「VPN を使え」に縮めてしまう層であり、それよりはるかに大きい。ドメインのレジストラ、ホスティング事業者、配信チャネル——どれもが、国家が圧力をかけられるコンプライアンス窓口を表す。だからどれも、単なる技術的選択ではなく、管轄の選択だ。個人データを収集も引き渡しもしないプライバシー尊重のレジストラ、当該国家の手の届かない場所にあるホスト、押収すべき利用者データベースを持たない静的サイト、そして単一の企業に削除を命じることのできない分散配信(Nostr プロトコル、IPFS、Tor のオニオンサービス)——これらは偏執ではない。一通の法的書簡で消せる媒体と、消せない媒体の差だ。原理はこうだ——発信のすべてを、一つの管轄から強要できる一つの主体に握らせない。

発信の層	敵対国家が強要しうるもの	主権的な代わりの手
ドメインのレジストラ	登録者の身元、ドメインの停止	個人データを収集も引き渡しもしない、プライバシー尊重のレジストラ
ホスティング	サーバーの押収、アクセスログ、削除命令	敵の管轄外にあるホスト、押収すべき利用者データベースを持たない静的サイト
配信	アカウント削除、プラットフォーム追放、コンテンツの削除	単一の企業に消去を命じられない分散プロトコル(Nostr、IPFS、Tor のオニオンサービス)
発信の時刻	タイムゾーンと活動パターンの突き合わせ	実際の生活と切り離した予約投稿、タイムスタンプが所在を漏らさないプロトコル

時刻を、指紋として扱う。 Protasevich の傍受は、移動の時刻に依った。同じ論理が、発信にも当てはまる。投稿のパターン——活動する時間帯、そこから推せるタイムゾーン、一人の日常生活と相関するリズム——は、良質な仮名性さえ生き延びるメタデータだ。意図して散らすこと。書く瞬間と公開する瞬間を、予約投稿で切り離す。そして、公開されるタイムスタンプが物理的なタイムゾーンを漏らさないプロトコルを選ぶ。いつ公開するかもまた、何を公開するかと同じくらい確実に、あなたの身元を割りうる——しかもそれは、ほとんど誰も守らない漏洩だ。

家族という経路に、明示的に備える。 香港では、活動家本人に手が届かなくなったその瞬間に、親族が圧力点になった。だから真剣な脅威モデルは、あなたの周りの人々を含む——何を話してよく、何が危ないかの共通理解、活動家としての身元と家族との公的なつながりの最小化、そして彼らの端末やアカウントが見られているかもしれない、と前提する連絡計画だ。身元を分離し、すでに何があなたを結びつけているかを点検する実務については、消えないデジタルの足跡を点検するプレイブックが、この節の相棒になる——ドキシングを仕掛ける側が使う原材料は、まさにそのプレイブックが「見つけて刈り取れ」と教える痕跡そのものだ。公的な被害者向けの案内、たとえば英国政府の国境を越えた弾圧に関する資料や、Activist Checklist の実践的なチェックリストは、必要になってからではなく、なる前に読んでおく価値がある。

個人の守りの、限界
#

ここに、正直な限界がある。これを覆い隠す事例研究は、本シリーズが正そうとしてきた当の省略を、自ら繰り返すことになる。OPSEC は個人を守る。だが、弾圧を生んだ条件そのものは変えない。そして、戦闘機一機、百万ドルの懸賞金、あるいは他国の法体系を費やす気のある国家に対しては、個人の技術は、必要であると同時に、それだけでは足りない。あなたはインフラを移し、時刻を散らし、ソーシャルグラフを切り離せる。だがあなた一人では、外国政府の域外管轄の主張を取り消すことも、その国境の内側にいる親族への圧力を止めることも、インターポールの手配の悪用を防ぐこともできない。

三つの事例を並べれば、そう告げている。Protasevich の技術(トレードクラフト)が破れたのではない——国家がただ、彼の飛行機を強制着陸させたのだ。懸賞金と家族の呼び出しが始まれば、香港の活動家の匿名性は、もう論点ではなくなった。中国のネットワークが機能するのは、まさに個人が抜け出せない制度を通じて動くからだ。こうした条件を実際に動かすのは、個人の暗号術が制度の権力とぶつかる場所でサイファーパンクが指し示してきた答え——集団の応答と、規則そのものの変革だ。政治的な容疑では引き渡しを拒み、代理工作員を訴追する受け入れ国。域外からの要求への服従に抵抗するプラットフォームとレジストラ。懸賞金を、ひそかな脅しではなく外交上の代償に変える、報道の自由の団体とディアスポラのネットワーク。個人の守りは、安全と時間を買う。だがそれ自体では、弾圧が突くために作られた、管轄のあいだの継ぎ目を閉じはしない。

「電子の時代において、プライバシーは開かれた社会に不可欠だ。……私たちは、政府や企業、その他の顔の見えない巨大な組織が、その善意からプライバシーを与えてくれるなどとは、期待できない。」——Eric Hughes『A Cypherpunk’s Manifesto』、1993年

ここでいう顔の見えない組織とは、批判者を追って国境を越えた国家であり、電子の時代とは、漏らされたカード、加工された写真、ネットに掲げられた懸賞金のことだ。個別の事案を守れ——そのうえで、それを生む条件そのものを変えよ。国境を越える懸賞金をかける政府が、善意からプライバシーを与えてくれることなど、ないのだから。Sovereignty(主権)の柱の残りは、同じ戦いを別の戦線で描く——圧力にしか応えない権力に、一人の個人が立ち向かう姿を。

結論——あなたのリスクに、どのプロトコルが合うか
#

正しい守りの水準は、誰があなたを国境の向こうまで追う理由を持つか、そしてその相手がどこまでやる気を、すでに見せたか——すべてはそこで決まる。

名指しの敵対国家を持つ、ディアスポラの活動家や亡命者なら： 身元は知られていると前提し、代わりに手が届くことを守れ。最前線はインフラの管轄だ——レジストラ、ホスト、配信を、誰に強要できないかで選ぶ——加えて、明示的な家族の連絡計画を。あなたに手が届かなくなった瞬間、親族が記録された圧力点になるからだ。
敵対的な管轄から、調査報道や運動のジャーナリズムを発信するなら： 最初の投稿の前に、責任を負う身元(仮名・集団・名のある媒体)を決めよ。運用上の身元を法的な人格から完全に切り離せ。そして報道の自由の保護は、本物だが遅い、事後の資源として扱え——発動する価値はあるが、リアルタイムの盾ではない。
女性の活動家やジャーナリストなら： 性別に偏った拡大を、最初から織り込め。ドキシングは性的な脅迫として届き、家族や近隣住民を経由する公算が高い。だからソーシャルグラフの分離と、公的な顔と交際関係のデータの最小化は、あなたにとって上級者向けではなく、中核の守りだ。

三つすべてに、それ以前のあらゆる OPSEC の失敗で成り立った真実が、同じく成り立つ——いったん国家が、漏れたあなたの身元を最初の一手として扱えば、漏洩を「なかったこと」にして安全へ戻ることはできない。あなたにできるのは、公開する前に決めることだけだ——どの管轄があなたの仕事を保持し、どのリズムがあなたの一日を明かすのか。そして、一人にできることの限界の先では、他者とともに動き、そもそも国境を越えて手を伸ばす代償を、引き上げることだ。

要点

脅威は、身元ではなく「手が届くこと」だ： どの事例でも、活動家が捕まったのは仮名が破れたからではなく、知られた身元を、国境を越える作戦の第一歩として国家が扱ったからだ。
ベラルーシ、2021年——露出は時刻だ： Protasevich は、事前に把握された旅行のメタデータを根拠に、Ryanair 4978便を強制着陸させて捕らえられた。8年の判決を受け、19日後に恩赦され、実際の拘束は2年に近かった。
香港、2019〜2023年——家族が攻撃面だ： 約2,800件の HKLeaks ドキシング・カードが、100万香港ドル(HK$1M)の域外懸賞金へと拡大し、Frances Hui のような名指しの亡命者に手が届かないと、圧力は香港内の親族へ移った。
指南書が飛ばす、性別の層： 女性にとって、ドキシングは確実に性的な脅迫になる——2019年の加工された露骨な画像から、2025年に亡命者の近隣住民へ郵送された偽の性的画像まで——ソーシャルグラフと家族の分離を、追加機能ではなく中核の守りにする。
身元だけでなく、インフラを移せ： 管轄——レジストラ、ホスト、配信チャネル——は変えられる変数だ。本気の国家がいずれ行う非匿名化は変えられない。だから各層を、誰に強要できないかで選べ。
限界： 個人の OPSEC は安全と時間を買うが、域外管轄を取り消すことも、家族への圧力を止めることもできない——それには、受け入れ国の引き渡し拒否、プラットフォームの抵抗、そして報道の自由を守る集団の力が要る。

よくある質問
#

権威主義国家で、活動家はどうやってドキシングされるのですか？
#

群衆によって、あるいは国家が支援したデータ漏洩と、公的記録の組み合わせによってです。実名・住所・勤務先・家族・SNS の履歴といった個人情報が、公開の「ドキシング」プロフィールにまとめられます。HKLeaks に関するシチズン・ラボの調査のようなフォレンジック研究が、国家の支援を受けた可能性が高いと見いだしたネットワークの手によることもあります。漏洩はそのあと運用化されます——令状の発行、懸賞金の掲示、雇用主や親族への圧力に使われ、ベラルーシの事例のように、把握された旅程に沿って動くために使われます。ドキシングはたいてい、それ自体が目的ではなく、より大きな国家作戦の偵察段階です。

海外で公開した内容で、外国政府が本当に私を逮捕できますか？
#

その権限があると主張できますし、物理的に手が届かない場所でも、別の手段でその主張に沿って動けます。香港の国家安全維持法は、どこで誰が行った行為にも管轄が及ぶと主張し、2023年には警察が、米国・英国・オーストラリアに暮らす活動家に逮捕令状と100万香港ドル(HK$1M)の懸賞金をかけました。海外での直接逮捕はまれですが、引き渡し請求、インターポールの手配、まだ国内にいる家族への圧力、受け入れ国での代理人による嫌がらせは、いずれも記録されています。物理的に引き渡せない相手であっても、令状はその効果において現実のものと扱うことです。

身元を隠すのと、インフラを動かすのと、どちらが大切ですか？
#

インフラを動かすほうが、長く効く守りです。身元の秘匿は、国家がデータを積み上げるほど効力を失う、時間稼ぎの戦術です。インフラの選択——どのレジストラ、ホスト、配信チャネルがあなたの仕事を保持するか——は、誰が法的にあなたへ不利な行動を強いられるかを決めます。そして主要な事例がすべて転んだのは、その変数の上でした。両方やるべきですが、優先せざるを得ないなら、発信スタックの各層を、どの管轄に置かれ、誰に削除を命じられないかで選ぶことです。

なぜドキシングは、女性活動家を違う形で狙うのですか？
#

女性にとって、暴露が意図された手口として、確実に性的な脅迫へと拡大するからです——2019年の香港のキャンペーンにおける加工された露骨な画像から、2025年に亡命した女性の近隣住民へ郵送された偽の性的画像まで。上の性別の層の節で詳しく述べたとおり、これは顔写真、交際関係のデータ、自宅の地域の情報を、女性にとってより高リスクなものにし、ソーシャルグラフと家族の分離を、上級者向けではなく中核の守りにします。

自分が標的にされていると思ったら、まず何をすべきですか？
#

日付の入った記録を個人の端末に保存して、すべてを記録すること。そして一人で抱え込まず、報道の自由や人権の団体と、地元の警察に連絡することです——まさにこのために、英国政府の国境を越えた弾圧に関する資料のような、公的な案内が存在します。並行して、あなたの活動家としての身元を、法的な人格や家族に公的に結びつけているものを点検し、そのつながりを減らすこと。親族の端末やアカウントは見られているかもしれないと前提し、何を話して安全かを彼らと取り決めておくこと。事後の後始末は予防より難しいものですが、記録された時系列こそ、のちのあらゆる法的・擁護的な対応が必要とするものです。

#	出典	URL	アーカイブ
1	Human Rights Watch——香港の令状は海外の活動家を狙う(2023年7月)	https://www.hrw.org/news/2023/07/04/hong-kong-warrants-aim-activists-abroad	https://web.archive.org/web/*/https://www.hrw.org/news/2023/07/04/hong-kong-warrants-aim-activists-abroad
2	Hong Kong Free Press——海外活動家5名に逮捕令状と100万香港ドルの懸賞金(2023年12月)	https://hongkongfp.com/2023/12/14/breaking-hong-kong-national-security-police-issue-arrest-warrants-hk1-million-bounties-for-5-overseas-activists/	https://web.archive.org/web/*/https://hongkongfp.com/2023/12/14/breaking-hong-kong-national-security-police-issue-arrest-warrants-hk1-million-bounties-for-5-overseas-activists/
3	Citizen Lab——HKLeaks：秘密と公然のオンライン嫌がらせの手口(2023年7月)	https://citizenlab.ca/research/hkleaks-covert-and-overt-online-harassment-tactics-to-repress-the-2019-hong-kong-protests/	https://web.archive.org/web/*/https://citizenlab.ca/research/hkleaks-covert-and-overt-online-harassment-tactics-to-repress-the-2019-hong-kong-protests/
4	Human Rights Watch——香港：亡命活動家の家族への標的化が拡大(2025年5月)	https://www.hrw.org/news/2025/05/04/hong-kong-targeting-exiled-activists-families-escalates/	https://web.archive.org/web/*/https://www.hrw.org/news/2025/05/04/hong-kong-targeting-exiled-activists-families-escalates/
5	Al Jazeera——ベラルーシの活動家 Protasevich が恩赦される(2023年5月)	https://www.aljazeera.com/news/2023/5/22/belarusian-activist-pardoned-by-minsk	https://web.archive.org/web/*/https://www.aljazeera.com/news/2023/5/22/belarusian-activist-pardoned-by-minsk
6	GPIL、ボン大学——FR4978便の進路変更を受けたベラルーシ航空会社の禁止	https://gpil.jura.uni-bonn.de/2023/10/banning-belarusian-airlines-in-response-to-belarus-diversion-of-ryanair-flight-fr4978-as-a-third-party-countermeasure/	https://web.archive.org/web/*/https://gpil.jura.uni-bonn.de/2023/10/banning-belarusian-airlines-in-response-to-belarus-diversion-of-ryanair-flight-fr4978-as-a-third-party-countermeasure/
7	Freedom House——国境を越えた弾圧(1,375件、起点54か国 / 受け入れ107か国)	https://freedomhouse.org/report/transnational-repression	https://web.archive.org/web/*/https://freedomhouse.org/report/transnational-repression
8	France 24——香港の女性抗議者がレイプの脅迫と加工画像に直面(2019年9月)	https://www.france24.com/en/20190902-attacked-for-gender-not-views-hk-women-protesters-facing-troll-army	https://web.archive.org/web/*/https://www.france24.com/en/20190902-attacked-for-gender-not-views-hk-women-protesters-facing-troll-army
9	Reuters(U.S. News 経由)——亡命した香港活動家が偽の性的画像で標的に(2025年12月)	https://www.usnews.com/news/world/articles/2025-12-12/exiled-hong-kong-democracy-activists-say-theyre-targeted-by-fake-sexualised-images	https://web.archive.org/web/*/https://www.usnews.com/news/world/articles/2025-12-12/exiled-hong-kong-democracy-activists-say-theyre-targeted-by-fake-sexualised-images
10	英国政府——国境を越えた弾圧の被害者になったと思ったら	https://www.gov.uk/government/publications/transnational-repression/what-to-do-if-you-think-you-are-the-victim-of-transnational-repression	https://web.archive.org/web/*/https://www.gov.uk/government/publications/transnational-repression/what-to-do-if-you-think-you-are-the-victim-of-transnational-repression
11	ICCT——ドキシング：文献レビュー(2024年12月)	https://icct.nl/publication/doxing-literature-review	https://web.archive.org/web/*/https://icct.nl/publication/doxing-literature-review
12	NBC News——ニューヨークの中国エージェント事案、典型的な北京のスパイ活動	https://www.nbcnews.com/investigations/chinese-agent-case-new-york-classic-beijing-spy-effort-experts-say-rcna169506	https://web.archive.org/web/*/https://www.nbcnews.com/investigations/chinese-agent-case-new-york-classic-beijing-spy-effort-experts-say-rcna169506

Cora Aegis

Cora Aegis は CypherpunkGuide で、プライバシーを最優先する OPSEC の指針を書いている。決着のついた弾圧の事例を、ほとんどの報道が飛ばす「仕組み」から読み解く——ここでは、漏れた一つの身元が、どうやって国境を越えて活動家を追う国家作戦になるのかを。

Cora についてもっと読む →

編集方針と方法論

Fri, 19 Jun 2026 00:00:00 +0000

私たちはペンネームで書いている。これは意図的な選択であり、その理由は著者ページに記したとおりだ。だが仮名であることは、私たちに一つの責務を課す——職歴で仕事を裏づけられない以上、仕事そのものが検証可能でなければならない。本ページは、私たちが出典をどう扱い、どう調べ、誤りをどう正し、そして公開内容を読者がどう検証できるかを記した常設の記録だ。資格証の代わりであり、資格証より高い基準であることを目指している。

出典
#

一次資料を最優先する。 二次的な要約ではなく、マニフェスト・仕様書・訴訟記録・データセットそのものを引く。他者の報道に依拠する場合は、その旨を明記してリンクする。
リンクは必ずアーカイブする。 外部参照はすべて、原 URL と並べて archive.org のスナップショットを残す。記録は風化し、リンク切れは証拠にならない。
名指しの主張には、名のある出典を。 専門家を引用するときは出典を明示する。出典も、肩書きも、経歴も——自分のものであれ他者のものであれ——捏造しない。
統計には必ず出所を添える。 数値は出典と年を併記し、私たちの言葉を鵜呑みにせずたどれるようにする。

一次研究と方法論
#

私たちの仕事で最も重みを持つのは一次研究——他者の主張の受け売りではなく、自分たちで実際に計測したものだ。その旗艦は、自動化システムがウェブをどう読むかを継続的に計測すること——どの AI・検索クローラが、どの user-agent の組で、どの周期で、どのページを取得するか——に加え、機械可読の llms.txt と、私たちの記事が AI にいつ・どこで引用されるかの定期的な確認だ。

この研究を、私たちは他者に求めるのと同じ基準で律する:

再現できるように設計する。 方法は再現できるだけの詳しさで公開し、結論がデータに基づく場合はそのデータも公開する——同じ道具を持つ読者が私たちを検証——あるいは反証——できるように。再現できない結果は、意見にすぎない。
主張ではなく、計測する。 実際に走らせた計測だけを公開する。推計や予測である場合は、そう明記する。
日付つきの来歴。 各研究には、データをいつ・どの期間にわたって取得したかを記し、どれだけ新しいかを読者が判断できるようにする。

訂正
#

誤りの報告方法。 メールは cora@cypherpunkguide.com へ。機微な報告は私たちの公開鍵（フィンガープリント FFE1 ECFE 2C75 7E98 6077 AAE2 56FB 82BD 4541 5835）で暗号化してほしい。
訂正の扱い。 内容に関わる訂正は、該当記事に日付と変更点を明記する。実質的な主張を黙って書き換え、最初からそうだったかのように装うことはしない。
日付の残る記録。 重要な更新は記事自体に日付を残す。研究については、変更をデータにも記録する。

検証と完全性
#

責任を負う一つの声。 Cora Aegis は単一で一貫したペンネームであり、著者ページ・検証済みの Nostr ID（cora@cypherpunkguide.com）・ORCID 記録を通じて公開している。一貫していることに意味がある——すべての主張を、責任を負える一つの声へとたどれるからだ。
暗号による署名。 私たちの OpenPGP 鍵は公開済みだ（上記フィンガープリント）。gpg --locate-keys cora@cypherpunkguide.com で取得でき（Web Key Directory）、ダウンロードもできる。この鍵で署名された訂正や研究リリースは照合して検証でき、声明が確かに私たちから出たもので、途中で改ざんされていないことを確かめられる。
独立性。 私たちは読者に支えられ、透明な複数の収入源で運営している——現在は Bitcoin と Monero による直接寄付、のちに Premium 購読と編集方針に合致したアフィリエイト——そしてどれがどれかを常に明示する。監視型広告は載せない。広告ネットワークも、トラッキングピクセルも、スポンサー記事もない。私たちは広告主にではなく、読者に向き合う。

開示
#

仮名は意図的なもの。 監視への抵抗を教えながら、私たちが回避を手助けしているまさにそのデータブローカーに本名を収集させるのは、筋が通らない。理由は著者ページに詳しい。
ポートレートはイラスト。 Cora Aegis の画像はすべて AI 生成イラストであり、写真ではない。掲載されるどこでもそのように明示する。
関係は明示する。 アフィリエイト関係がある場合は、その文脈で平明に開示する——決して埋もれさせない。

プライバシーポリシー

Tue, 02 Jun 2026 00:00:00 +0000

最終更新: 2026年6月10日

プライバシーはこの媒体の核です。だからこのポリシーは、私たちがしないことから始めます。

私たちが拒むこと
#

監視型広告なし。 広告ネットワークなし、トラッキングピクセルなし、スポンサードコンテンツなし。私たちは広告主にではなく、読者に向き合います。
サードパーティ・トラッカーなし。 Google Analytics なし、Meta ピクセルなし、クロスサイト・トラッキングなし。
データの販売・貸与なし。 一切、誰に対しても。
行動プロファイリングなし、そしてあなたのデータを AI 学習に使うこともしません。

運営に必要な最小限だけを収集し、それが何であるかを正確にお伝えします。

収集する情報
#

訪問者。 現在、クライアントサイドのアナリティクスは一切実行していません。解析スクリプトもフィンガープリンティングもなく、ページが cookie をセットすることもありません。ページの配信は CDN(BunnyCDN、私たちの処理者として動く EU の事業者)が担い、IP 匿名化を有効にした配信ログと、集計統計(リクエスト数、帯域、キャッシュ率、国単位の合計)を保持します。この統計から把握するのは負荷であって、人ではありません。将来、詳細なアナリティクスを加える場合は、自前ホストかつ cookie レスのもの(計画中の候補は自前ホストの Plausible)とし、先に本ポリシーを更新します。

ニュースレター購読者(計画中——ニュースレターはまだ稼働していません)。 開始後に購読された場合:メールアドレス(配信のため)と任意の言語設定。保持するのは集計的な開封/クリック数のみで、長期の個別追跡は行いません。

インタラクティブな道具(提供時)。 計算はすべてあなたのブラウザ内(クライアントサイド)で実行されます。メールでのレポート受領を明示的に選択しない限り、入力や結果は収集しません(その場合もメールアドレスのみ)。私たちのリゾルバへの送信が必要な接続/リーク試験は、送信元 IP を一時的に(24時間以内)記録した後に削除し、国単位の集計のみを残します。

利用目的
#

サイトの安定した配信(CDN による配信と濫用対策)、何が読まれているかを知るための集計統計(広告や販売には決して用いません)、ニュースレター開始後はその配信と言語ローカライズ、あなたが求めたときだけの道具レポートの送付、そして真に該当する場合の法的義務の履行。

保持期間
#

全体を通じてデータ最小化を徹底します:ニュースレターのデータは退会まで(加えて短いバックアップ期間)、集計アナリティクスは最長 24か月、リゾルバのログは 24時間以内(その後は国単位の集計)、メール送付した道具レポートは私たちのサーバーに保存しません。バックアップは暗号化されています。

共有
#

私たちはあなたのデータを共有・販売・貸与しません。狭い例外として:厳密に私たちの代理として動く処理者(例:メール配信)で、守秘義務を負う者。そして、しかるべき法域からの有効な法的手続き——これは精査し、過度に広範な場合は争います。広告ネットワーク、データブローカー、ソーシャルプラットフォーム、AI 学習提供者とデータを共有することは決してありません。

あなたの権利
#

お住まいの地域(GDPR / UK GDPR、CCPA / CPRA、日本の APPI、LGPD など)に応じて、あなたには自分のデータへのアクセス・削除・訂正・ポータビリティ・処理への異議を申し立てる権利、およびそれらの行使による不利益を受けない権利がある場合があります。私たちはデータを販売しないため「販売のオプトアウト」は該当しませんが、その旨を明示的に確認します。

権利を行使するには privacy@cypherpunkguide.com までご連絡ください。あなたの法が求める期限内(例:GDPR 30日 / CCPA 45日)に対応し、まず本人確認を行う場合があります。合理的な請求は無料です。

Cookie
#

本サイトは現在、cookie を一切セットしません。ログインもセッションもなく、同意の対象が何もないため、同意バナーもありません。テーマ設定(ライト/ダーク)はあなたのブラウザの localStorage に保存され、端末の外に出ることはありません。言語は URL の一部であり、cookie ではありません。広告 cookie も追跡 cookie もありません。サードパーティのメディアを埋め込む場合は、プライバシーを尊重する埋め込みを優先し、できないときはその旨をお伝えします。

運営資金とアフィリエイトリンク
#

私たちは広告主にではなく、読者に向き合います。複数の透明な収入源に支えられています:最初に立ち上げるのは Bitcoin と Monero による寄付、後のフェーズで有料サブスクリプションと、ごく少数の編集方針に合致したアフィリエイトリンク。アフィリエイトリンクを用いる場合は率直に開示し、自分たちが使う道具だけを薦めます。

お子様について
#

本サイトは 13歳未満(EU では 16歳未満)のお子様を対象としていません。私たちは、それと知ってお子様のデータを収集することはありません。

変更
#

本ポリシーを更新することがあります。重要な変更は告知し(ニュースレターでの通知とサイト上のバナー)、上部の「最終更新」日付を改めます。

お問い合わせ
#

プライバシーに関するご質問・データ請求:privacy@cypherpunkguide.com。私たちは分散した媒体であり、公開の物理オフィスは持ちません。発行者情報もご覧ください。

発行者情報と著者アイデンティティ

Tue, 02 Jun 2026 00:00:00 +0000

最終更新: 2026年6月2日

発行しているのは誰か
#

CypherpunkGuide は、ペンネーム Cora Aegis の名のもとに書かれた、独立した編集媒体です。

なぜペンネームなのか
#

私たちはオペレーショナル・セキュリティ(OPSEC)、監視への抵抗、自己主権について書いています。それを——まさに私たちが「逃れ方」を説いているデータブローカーに収集される——本名で行うのは、筋が通りません。ペンネームは小細工ではありません。それは最初の一講であり、私たちは説くことを自ら実践しています。同じ理由で著者の身元を守る、同種の媒体の先例に倣います。

これが意味すること
#

Cora Aegis は実在の人物であり、その法的身元は意図的に開示されていません。私たちは次のような求めに応じて身元を明かすことはしません:

読者からの要請、
身元開示を条件とするジャーナリストの照会、
適法な KYC 要件に基づかない商業的要請、
あるいは敵対的な暴露の試み。

私たちは、有効な法的手続き(管轄権をもつ法域からの裁判所命令や召喚状)には、適切な審査を経て、法の限界の範囲内でペンネームの一貫性を保つ合理的な努力とともに、応じることがあります。

私たちの運営
#

私たちは分散した媒体であり、公開の物理オフィスは持ちません。サイトはスイスでホストされ、ドメイン登録は設計として WHOIS プライバシーを用いています。

お問い合わせ
#

editor@cypherpunkguide.com — 編集
privacy@cypherpunkguide.com — プライバシーとデータ請求
legal@cypherpunkguide.com — DMCA、法務、規制

連絡先、プライバシーポリシー、利用規約もあわせてご覧ください。

免責事項

Tue, 02 Jun 2026 00:00:00 +0000

最終更新: 2026年6月2日

専門的助言ではありません
#

CypherpunkGuide は教育です。ここにあるものは、法務・財務・税務・セキュリティのいずれの助言でもありません。ここで読んだことに基づいて行動する前に——とりわけお金や安全に関わる決定については——資格をもつ専門家にご相談ください。

暗号資産と自己保管のリスク
#

自己保管と暗号資産には、取り返しのつかない損失という現実のリスクがあります。あなたの鍵、運用上のセキュリティ、そして決定について、責任を負うのはあなた自身です。まずは少額で試してください。

「現状のまま」
#

コンテンツと道具は、いかなる種類の保証もなく「現状のまま」提供されます。私たちは、私たちのコンテンツに基づいてあなたが下す決定、リンクや言及する第三者サービス、サービスの中断やデータ損失について、責任を負いません。完全に安全なシステムは存在しません。私たちは手持ちの資源で最善を尽くし、万一インシデントが起きた場合は透明な開示を約束します。

絶対ではなく、意見
#

私たちの編集上の立場は、誠実に提示された、確かな根拠をもつ意見です。理性ある人々の見解は分かれます——私たちはそれを歓迎します。

アフィリエイトリンク
#

アフィリエイトリンクを含める場合、私たちは率直に開示し、自分たちが使う道具だけを薦め、手数料が判断を左右することを決して許しません。監視型の広告ネットワークは用いず、あなたのデータを販売することもありません——私たちは複数の透明な収入源に支えられています(最初に立ち上げるのは寄付、後に有料サブスクリプションと編集方針に合致したアフィリエイトリンク)。プライバシーポリシーをご覧ください。

第三者リンク
#

私たちは利便性のために外部リソースへリンクします。それらを管理しておらず、その内容や慣行について責任を負いません。リンク切れに備え、引用したものは保存します(例:Wayback Machine を通じて)。

利用規約

Tue, 02 Jun 2026 00:00:00 +0000

最終更新: 2026年6月2日

1. 同意
#

cypherpunkguide.com を利用する、またはニュースレターを購読することで、本規約に同意したものとします。同意されない場合は、本サイトをご利用にならないでください。

2. 提供するもの
#

CypherpunkGuide は編集媒体です:プライバシーと OPSEC、自己保管、主権、サイファーパンク思想に関する記事。媒体の成長に伴い、無料のインタラクティブな道具やニュースレター(将来の有料 Premium 層を含む可能性)を追加することがあります。コンテンツは情報提供のみを目的とし、専門的な法務・財務・セキュリティ助言の代替ではありません。

3. あなたの責任
#

サイトを適法に利用すること。セキュリティの侵害や濫用的なスクレイピングを試みないこと。Cora Aegis や私たちのスタッフを詐称しないこと。アカウントが存在する場合、その認証情報を共有しないこと。

4. 編集上の立場
#

私たちは明確な立場をとります:基本的権利としてのプライバシー(Hughes『サイファーパンク宣言』に倣って)、自己保管と金融上の主権、そして監視技術と政策への批判的分析。これらは確かな根拠をもつ意見であり、絶対的真理ではありません——敬意ある異論を歓迎します。嫌がらせやヘイトスピーチに関与する者には、サービスの提供を拒むことがあります。

5. アフィリエイトリンクと独立性
#

すべてのコンテンツは編集上独立しています。スポンサードコンテンツや有料の掲載は受け付けません。私たちは複数の透明な収入源に支えられています(最初に立ち上げるのは寄付、後に有料サブスクリプションと編集方針に合致したアフィリエイトリンク)。アフィリエイトリンクが現れる場合は率直に開示し、私たちの推奨を左右することは決してありません。プライバシーポリシーと免責事項もご覧ください。

6. 著者性とペンネーム
#

CypherpunkGuide は編集上のペンネーム Cora Aegis の名のもとに書かれています。著者アイデンティティの完全な方針は発行者情報をご覧ください。

7. 訂正
#

私たちは重大な誤りを公然と訂正します:該当記事への訂正注記、ニュースレターでの通知、そして Wayback Machine での原文の保存。ケーススタディで名指しされた当事者で事実に異議がある場合は、editor@cypherpunkguide.com まで——誠実な再検討を行います。

8. 著作権と DMCA
#

私たちは知的財産権を尊重します。テイクダウン通知を提出するには、legal@cypherpunkguide.com 宛に次を添えてください:主張する著作物、侵害とされる URL、あなたの連絡先、誠実な申立ての表明、正確性と権限の表明、そして署名。私たちは 14日以内に対応し、フェアユース・報道・その他適法と考える場合は反対通知を行うことがあります。過度に広範な、または悪意ある請求には応じません。

9. 免責と責任
#

コンテンツと道具は、保証なしに「現状のまま」提供されます。完全な内容は免責事項をご覧ください。

10. 準拠法
#

本規約の文言にかかわらず、あなたの地域の消費者保護法・データ保護法が適用されます(例:EU/UK は GDPR、カリフォルニアは CCPA、日本は APPI、ブラジルは LGPD)。紛争はまず誠実な交渉、次に調停、そして管轄権をもつ裁判所によって解決します。

11. お問い合わせ
#

編集:editor@cypherpunkguide.com · プライバシー:privacy@cypherpunkguide.com · 法務:legal@cypherpunkguide.com

連絡先

Tue, 02 Jun 2026 00:00:00 +0000

私たちは公開の物理オフィスを持たない、分散した媒体です。メールでご連絡ください:

editor@cypherpunkguide.com — 編集、情報提供、訂正、名指しされた当事者からの異議 (Cora Aegis)
privacy@cypherpunkguide.com — プライバシーに関する質問とデータ主体請求
legal@cypherpunkguide.com — DMCA 通知、法務・規制に関する連絡

暗号化。 機微な内容は、どうか暗号化してください。Cora Aegis の OpenPGP 鍵（フィンガープリント FFE1 ECFE 2C75 7E98 6077 AAE2 56FB 82BD 4541 5835）はダウンロードできます。gpg --locate-keys cora@cypherpunkguide.com でも取得できます。

活動の支援。 CypherpunkGuide は読者に支えられています。Bitcoin と Monero による寄付の詳細は本ページで公開します。私たちは広告主にではなく、読者に向き合います。

著者アイデンティティの方針については発行者情報をご覧ください。出典の扱い・検証・訂正の方針は編集方針と方法論に記しています。

CypherpunkGuide について

Mon, 01 Jun 2026 00:00:00 +0000

なぜ、この場所をつくったのか
#

「プライバシーとは、自分自身を世界に対して選択的に開示する力である。」 — Eric Hughes『サイファーパンク宣言』(A Cypherpunk’s Manifesto、1993)

それから三十余年。その「力」を手元に保つことは、かつてないほど難しくなりました。あらゆる取引、あらゆるやり取り、あらゆる行動が記録され、結びつけられ、売られています。CypherpunkGuide は、それを「仕方のないこと」とは認めないと決めた人のための場所です。そして、その力を取り戻すための、実践的で検証済みの方法を求める人のための場所です。

私たちは特定の技術からではなく、プライバシーから始めます。プライバシーは権利であり、目的そのもの。道具はそれを行使する手段にすぎません。

Cora Aegis とは
#

Cora Aegis は、この媒体の編集を担う「声」です。そしてこの名前は、意図して選んだペンネームです。私たちはオペレーショナル・セキュリティ(OPSEC)、監視への抵抗、自己主権について書いています。その私たちが、「その逃れ方」を説いている当のデータブローカーに収集される本名で書くのは、筋が通りません。ペンネームは小細工ではありません。それは、最初のレッスンです。

私たちの立ち位置は、ためらいなく擁護者(advocate)のものです。プライバシーと自己主権は、抽象的な好みではありません。それは、一人の人間の尊厳が立つ土台です——自分の身体を、自分のお金を、自分の物語を、誰かの許可を先に請うことなく持ちつづける権利です。

Cora Aegis について詳しく →

扱うテーマ — 4つの柱
#

私たちの仕事は、学ぶ順序として最良と考える順に、4つの柱で構成されています。

プライバシーと OPSEC — すべての土台です。脅威モデリング(threat model)、メタデータ、監視、そして攻撃される面(attack surface)を小さくする日々の実践。Bitcoin に触れたことがあってもなくても、ほとんどの読者はここから始めます。
自己保管(Self-Custody) — お金の領域に踏み込んだプライバシーです。Bitcoin は看板ではありません。それは、金融のプライバシーと検閲耐性を現実に変えるための手段です。最初のハードウェアウォレットからマルチシグまで、私たちはそれを第一の柱に仕える道具として扱います。
主権(Sovereignty) — 人生のすべてに広がるプライバシー。通信、住まい、健康、そして独立を静かに支える土台。
サイファーパンク(Cypherpunk) — すべてを束ねる思想を、スローガンではなく一次資料から読み解きます。

道筋は一方向です。プライバシーが入口、Bitcoin は手段の一つ、主権はその延長、そしてサイファーパンクの倫理が地平線です。

私たちの仕事の流儀
#

教育が先。 私たちが公開するものの大半は、製品の売り込みではなく、解説です——脅威モデル、比較、一次資料の分析。
自分たちが実際に使う道具だけ。 何かを薦めるとき、私たちは自分でそれを使い、トレードオフも具体的に挙げ、アフィリエイト関係があれば率直に開示します。
一次資料。 宣言を、仕様を、訴訟記録を引用します。そしてリンク先を保存します——記録は朽ちるからです。
自分たちの OPSEC を実践する。 ペンネームによる執筆、プライバシーを尊重するホスティング、監視型アナリティクスなし、広告トラッカーなし。

運営資金について
#

私たちの仕事は、複数の透明な収入源に支えられています。どの記事がどの収入源によるものかは、必ず明示します。

直接の寄付 — Bitcoin と Monero による寄付は、私たちが最初に立ち上げる収入源です。自前でホストする決済サーバーが稼働し次第、連絡先ページにアドレスを掲載します。
有料サブスクリプション — より深く読みたい読者のために(後のフェーズで計画)。
厳選したアフィリエイトリンク — すでに私たちの編集方針に合致する、ごく少数の道具に対してのみ。誇大広告なし、自分たちが使うものだけ、常に開示します。

私たちは広告主にではなく、読者に向き合います。この一文が、私たちのあらゆる編集判断を決めています。

まずはここから
#

はじめての方は、プライバシーと OPSEC から始めてください。Bitcoin を含む他のすべては、自分が本当は何から身を守ろうとしているのか——その脅威が見えたとき、はじめて腑に落ちます。

ExposureCheck

Mon, 01 Jan 0001 00:00:00 +0000

一分でわかる、できること
#

ExposureCheck が読むのは、あなた自身がプラットフォームから書き出したデータです。動いているアカウントに触れることも、他人のデータを扱うことも、決してありません。そのうえで、攻撃者が投げかけるであろう問いを立てます。これだけの投稿を全部合わせると、その背後にいる人物について何が分かってしまうのか、と。

Reddit の GDPR 書き出しと、X / Twitter のアーカイブ（フォルダでも .zip でも）を読み込みます。
取りこぼしを防ぐ段階処理（カスケード）で進めます。まず安価な処理が全投稿に優先順位をつけ、次に高価な処理が重要なものを精読します。このとき弱いシグナルもあえて残します。モザイクは弱いシグナルから組み上がるので、捨ててしまえば「安全だ」という見せかけの安心にしかなりません。
メタデータの層は、推論ではなく決め打ちで抽出します。自分で設定した居場所の欄、外部リンク、画像の EXIF / GPS（写真に埋め込まれた撮影日時や位置などの情報）、端末の機種、そして投稿時刻の偏りから漏れるタイムゾーン——X では、これらが本文よりも多くを明かします。
結果はカテゴリ別のリスクカードで報告します。居場所、勤め先、家族、生活リズム、お金、アカウントのつながり——それぞれをリスクへの寄与度で並べ、マスクした実例と、まず一般化するという具体的な対処を添えます。

ExposureCheck はローカル完結で、集めた情報を一切保存せず、あなたのプロファイルをディスクに書き出すこともありません。

「モザイクによる身元特定」が初耳でしたら、まずツールより脅威そのものから始めてください。対になる解説記事、AI の目で、自分の投稿履歴を棚卸しするを読んでから、また戻ってきていただければと思います。

あえてやらないこと
#

集めた情報を保存しません。 「あなたは X 市に住み、Y 社で働き、名前は Z」といった出力は決してしません。カードに出るのはマスクした断片だけです。復元した値が見えるのは、あなたがあなた自身の元の投稿へその場で辿ったときに限られ、保存もされません。
発見を書き出す機能はありません。スクレイピング（自動収集）もしません（入力は書き出しデータのみ）。あなたの代わりに投稿したり削除したりもしません。他人の履歴を分析することもありません。
あなたを匿名にする道具ではありません。 あくまでリスクを減らすものです。「Low」は「安全」ではありませんし、メタデータ・投稿時刻・文体まで完全に見きれるわけでもありません。

外に出るデータと、出ないデータ
#

プライバシーツールが最初に伝えるべきはこの点ですので、冒頭ではっきりさせておきます。推論はあなたが選んだバックエンドの上で動き、何が外へ出ていくかを決めるのは、ツールではなく、その選択です。

バックエンド	中身	データは端末から出ていきますか？
`local`	手元の Ollama / llama.cpp / LM Studio のモデル	✅ いいえ（出ません） — あなたのパソコンの中にとどまります
`heuristic`	オフラインの正規表現スタブ。ほぼ何も拾いません	✅ いいえ（出ません） — ただし開発・CI 用であって、本来の点検ではありません
`cloud`	OpenAI 互換のエンドポイント（鍵はあなたのもの）	⚠️ はい（送られます） — あなたの投稿が、その事業者へ届きます

ツール本体には、サーバーも、外部への通信も、アカウントもありません。作者があなたのデータを預かることも、鍵を持つこともありません。cloud を選んだときは、あなたの書き出しデータが、あなたの指定した API 事業者へ届きます。ログの保存期間、学習方針、鍵に紐づく IP や支払い情報まで——すべてその事業者の規約が適用されます。ExposureCheck が中継を増やすことはありません。ただし、あなた自身が選んで通した経路を、ツールが消してくれるわけでもありません。

クラウドで本当に問題になる、ただ一つの注意点
#

点検しようとしているアカウントが、本名と切り離して保っている仮名のもので、かつあなたの AI / クラウドのアカウントが本名で登録されている、または本名で支払われているとします。すると、その履歴をクラウドへ送った時点で、事業者は自社の側で本名 ↔ 匿名アカウントを結びつけられてしまいます（令状・情報流出・内部者の手を通じて）。それこそが、このツールが防ぐために存在している、まさにその身元特定です。

ですから——厳密に匿名のアカウントを点検するなら、--backend local を使ってください（匿名で開設・支払いしたクラウドアカウントでも構いません）。本名・公開アカウントの点検なら、クラウドでも問題ありません。CLI はこの点を画面に表示し、該当する場面ではあなたに確認を求めます。ローカルを強制はしません。それでは使える人が誰もいなくなるからです。代わりに、この選択の意味をはっきり見えるようにします。

仕組み
#

export ─▶ parse ─▶ prefilter (drop only TRUE-empty) ─┬─▶ deterministic: profile + EXIF + timing ─┐
 └─▶ cascade: cheap route ─▶ expensive read ─┤
 ▼
 risk-contribution scoring ─▶ category cards ─▶ no-dossier report

段階処理を挟むのは、1〜3千件の履歴でも費用を抑えて回せるようにするためです。すべてを精読に送るのではなく、安価な処理がどれを精読する価値があるかを見極めます。続くリスク寄与度のスコアリングは、各カテゴリを「モデルの確信度」ではなく「実際にどれだけあなたを絞り込むか」で並べます。モデルの確信度は、必ずしも正確に較正されているわけではないからです。

インストール
#

中核——解析、EXIF、段階処理、そしてクラウド／ローカルの HTTP バックエンド——は、Python の標準ライブラリだけで書かれています。あなたの書き出しに触れるサードパーティ製パッケージは一つもありません。そのぶん、あなたが信頼すべきコードの範囲は小さく保たれます。

# from source (a PyPI release ships with the first public version):
git clone https://github.com/coraaegis/exposurecheck && cd exposurecheck
pip install -e .

# or run without installing:
python -m exposurecheck --help

# Local model — nothing leaves your machine (recommended for anonymous accounts)
exposurecheck audit \
 --reddit ./reddit_export.zip \
 --twitter ./twitter_export \
 --backend local --expensive-model llama3.1 \
 --i-own-this-data

# Cloud — bring your own key; set it in the ENV, never on the command line
export OPENAI_API_KEY=sk-...
exposurecheck audit --twitter ./twitter_export --backend cloud --i-own-this-data

API の鍵を環境変数から読むのは、意図してのことです。コマンドラインの引数は、シェルの履歴やプロセス一覧に漏れてしまうからです。

ExposureCheck は、いまのところコマンドラインのツールで、ターミナルに慣れた方を想定しています。最初にこのツールを検証してくれるのも、そうした人たちだからです。Python を入れる必要のない、ローカルかつブラウザ内で動く UI を備えたワンクリックのアプリ（技術に明るくない方向け）が、次の目標です。CLI は、使い込む方のために残します。

プライバシーツールは、信じるのではなく確かめるもの——このツールも同じです
#

作者は仮名ですから、名前を鵜呑みにしないでください。代わりに、あなた自身が確かめられるものを受け取ってください。

コードを読む。 オープンソース（MIT）で、標準ライブラリだけで書かれています。ですから、あなたが点検すべき依存関係は、実質的に標準ライブラリそのものです。
リリースを検証する。 各リリースには Cora Aegis の PGP 署名が付いています。鍵を WKD 経由で取得し、署名を確かめてください。
```
gpg --locate-keys cora@cypherpunkguide.com
gpg --verify exposurecheck-0.1.0.tar.gz.asc
```
SHA-256 のチェックサムも毎リリースに同梱され、ビルドは再現可能です。タグ付けされたソースから自分でビルドし直し、できあがったものが一致するかを確かめられます。
身元に紐づくコード署名証明書は、あえて用意していません。 その種の証明書は、プロジェクトを法的な身元に結びつけてしまうもので、目的の正反対だからです。署名のない Windows のバイナリは、SmartScreen の「不明な発行元」という警告を出すかもしれませんが、それは想定どおりです。パッケージマネージャ（pip / Scoop / Homebrew）を使うか、ソースから動かし、PGP 署名を検証することをお勧めします。
出力の設計そのものが、歯止めになっています。 「情報を保存しない」という約束は、コードで強制されています。マスクされたラベルはプログラムが生成するので、モデル自身の出力でさえ、復元した値をレポートに表示することができません。悪用を防ぐ仕組み——所有者前提の入力、カテゴリのみの出力、マスク処理、そして公開前の悪用評価——は、ABUSE-EVAL.md にまとめてあります。

データフロー図と公開された脅威モデルは、このツールが何をするものかを示します。ソースコード、署名、そして再現可能なビルドは、それが本当にそのとおりに動き——それ以外のことはしないと——あなた自身が確かめるための手段です。

知っておきたい限界
#

「Low」は「安全」ではありません。 このツールはリスクを減らしますが、匿名性を保証するものではありません。
見落としはあります。 「何も引っかからなかった」は、あなたを特定できないことの証明にはなりません。とりわけ heuristic バックエンドは、本来の点検ではなく動作確認用です。
対象外のもの。 文体による筆者の特定、書き出しに含まれる範囲を超えたサービス横断の照合、ネットワーク層のメタデータ、そして画像の写っている中身（v1 が読むのは EXIF / メタデータだけです。ロードマップを参照してください）。
このツール自身が、あなたの最も機微なデータを読みます。 だからこそ、ローカル完結で、標準ライブラリのみで、オープンソースで、署名付きです。露出を確かめるために動かすツール自身が、できるだけ小さく、できるだけ検証しやすい存在でなければなりません。

よくある質問
#

ExposureCheck は、私の投稿をどこかへアップロードしますか？
#

cloud バックエンドを選んだときだけで、しかも送り先は、あなたが鍵を渡した API 事業者に限られます。local または heuristic なら、何一つあなたの端末から出ていきません。ツール自身には、サーバーも外部への通信もありません。

自分の住所や本名を、教えてくれるのですか？
#

いいえ、教えません。それが「情報を保存しない」という意図的な設計です。表示するのはマスクしたカテゴリで、あなた自身の元の投稿へ案内し、何を変えるかはあなたが決めます。あなたのプロファイルを組み立てることも、保存することも、決してありません。

匿名のアカウントを点検します。クラウドのバックエンドでも安全ですか？
#

厳密に匿名のアカウントには --backend local を使ってください。あなたのクラウドアカウント自体が匿名である場合は別です。匿名アカウントの履歴を本名の AI アカウントへ送ると、事業者の側で両者が結びついてしまいます。このツールは、まさにそのリスクを見つけ出すためにあります。

自分の全履歴に対して走らせて、本当に安全ですか？
#

コードはオープンソースで標準ライブラリのみなので、何をしているか自分で読めます。リリースは PGP 署名付きで再現可能なので、インストールしたものを確かめられます。プロファイルをディスクに書き出しません。これらを信用ではなく、あなた自身の目で検証してください。それがこのツールの基本姿勢です。

なぜアプリではなく、コマンドラインなのですか？
#

最初の読み手は技術寄りの方々で、CLI が最も点検しやすい形だからです。ローカルかつブラウザ内で動く UI を備えた、ワンクリックのアプリ（技術に明るくない方向け）が次の目標です。

制作: Cora Aegis。 プライバシーや安全上の不備を見つけられましたか？責任ある開示を歓迎します——cora@cypherpunkguide.com（PGP は WKD 経由）。正式なソースと ExposureCheck という名前は、github.com/coraaegis/exposurecheck にあります。

#	出典	URL	アーカイブ
1	FBI——“Galveston Man Sentenced to Federal Prison for Computer Hacking”（2012年）	https://www.fbi.gov/sanantonio/press-releases/2012/galveston-man-sentenced-to-federal-prison-for-computer-hacking	https://web.archive.org/web/*/https://www.fbi.gov/sanantonio/press-releases/2012/galveston-man-sentenced-to-federal-prison-for-computer-hacking
2	CSO Online——“Embedded data, not breasts, brought down hacker”（2012年）	https://www.csoonline.com/article/535700/embedded-data-not-breasts-brought-down-hacker.html	https://web.archive.org/web/*/https://www.csoonline.com/article/535700/embedded-data-not-breasts-brought-down-hacker.html
2b	Gizmodo——Ochoa の写真 GPS 追跡の報道（iPhone、ウォンティルナ・サウス、2012年）	https://gizmodo.com/these-breasts-nailed-a-hacker-for-the-fbi-5901430	https://web.archive.org/web/*/https://gizmodo.com/these-breasts-nailed-a-hacker-for-the-fbi-5901430
3	NPR——“Betrayed By Metadata: John McAfee Admits He’s Really In Guatemala”（2012年）	https://www.npr.org/sections/thetwo-way/2012/12/04/166487197/betrayed-by-metadata-john-mcafee-admits-hes-really-in-guatemala	https://web.archive.org/web/*/https://www.npr.org/sections/thetwo-way/2012/12/04/166487197/betrayed-by-metadata-john-mcafee-admits-hes-really-in-guatemala
4	The Next Web——“Vice leaves metadata in photo of John McAfee”（2012年）	https://thenextweb.com/news/vice-leaves-metadata-in-photo-of-john-mcafee-pinpointing-him-to-a-location-in-guatemala	https://web.archive.org/web/*/https://thenextweb.com/news/vice-leaves-metadata-in-photo-of-john-mcafee-pinpointing-him-to-a-location-in-guatemala
5	The New York Times——“Web Photos That Reveal Secrets, Like Where You Live”（2010年）	https://www.nytimes.com/2010/08/11/business/media/11photos.html	https://web.archive.org/web/*/https://www.nytimes.com/2010/08/11/business/media/11photos.html
6	Friedland & Sommer——“Cybercasing the Joint: On the Privacy Implications of Geo-Tagging”（USENIX HotSec 2010）	https://www.usenix.org/conference/hotsec10/cybercasing-joint-privacy-implications-geo-tagging	https://web.archive.org/web/*/https://www.usenix.org/conference/hotsec10/cybercasing-joint-privacy-implications-geo-tagging
7	ICSI——“Cybercasing” プロジェクトのメモ（2010年）	https://www.icsi.berkeley.edu/icsi/news/2010/08/cybercasing	https://web.archive.org/web/*/https://www.icsi.berkeley.edu/icsi/news/2010/08/cybercasing
8	CIPA——DC-008 Exchangeable image file format 規格	https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf	https://web.archive.org/web/*/https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
9	MetaFilter——2003年の埋め込み縮小画像（embedded thumbnail）事件を記録したスレッド	https://www.metafilter.com/27225/Photoshop-Thumbnails-Boobs	https://web.archive.org/web/*/https://www.metafilter.com/27225/Photoshop-Thumbnails-Boobs
10	Stolen Camera Finder——製造番号による写真検索	https://www.stolencamerafinder.com/	https://web.archive.org/web/*/https://www.stolencamerafinder.com/
11	Apple——写真の位置情報 metadata を管理する（Personal Safety ユーザガイド）	https://support.apple.com/guide/personal-safety/manage-location-metadata-in-photos-ips0d7a5df82/web	https://web.archive.org/web/*/https://support.apple.com/guide/personal-safety/manage-location-metadata-in-photos-ips0d7a5df82/web
12	Google フォトヘルプ——写真の位置情報を編集する	https://support.google.com/photos/answer/6153599?hl=en	https://web.archive.org/web/*/https://support.google.com/photos/answer/6153599?hl=en
13	ExifTool（作者 Phil Harvey）——公式サイト	https://exiftool.org/	https://web.archive.org/web/*/https://exiftool.org/
14	ExifCleaner——オープンソースの metadata 除去ツール（GitHub）	https://github.com/szTheory/exifcleaner	https://web.archive.org/web/*/https://github.com/szTheory/exifcleaner
15	Signal Community——ファイル種別ごとの metadata の挙動（写真か、ドキュメント／添付ファイルとしての送信か）	https://community.signalusers.org/t/list-of-meta-data-which-should-be-displayed-when-sending-certain-file-formats/31798	https://web.archive.org/web/*/https://community.signalusers.org/t/list-of-meta-data-which-should-be-displayed-when-sending-certain-file-formats/31798

#	出典	URL	Archive
1	FTC——Background Checks: What Employers Need to Know	https://www.ftc.gov/business-guidance/resources/background-checks-what-employers-need-know	https://web.archive.org/web/20260717052817/https://www.ftc.gov/business-guidance/resources/background-checks-what-employers-need-know
2	FTC——Employer Background Checks and Your Rights	https://consumer.ftc.gov/articles/employer-background-checks-and-your-rights	https://web.archive.org/web/20260423200314/https://consumer.ftc.gov/articles/employer-background-checks-and-your-rights
3	FTC——TruthFinder LLC, FTC v.（署名済み命令へのリンクを含む事件ページ）	https://www.ftc.gov/legal-library/browse/cases-proceedings/truthfinder-llc-ftc-v	https://web.archive.org/web/20260521224619/https://www.ftc.gov/legal-library/browse/cases-proceedings/truthfinder-llc-ftc-v
4	FTC——Fair Credit Reporting Act、2026年3月改訂	https://www.ftc.gov/legal-library/browse/statutes/fair-credit-reporting-act	https://web.archive.org/web/20260719204956/https://www.ftc.gov/legal-library/browse/statutes/fair-credit-reporting-act
5	EEOC・FTC——Background Checks: What Job Applicants and Employees Should Know	https://www.eeoc.gov/laws/guidance/background-checks-what-job-applicants-and-employees-should-know	https://web.archive.org/web/20260723022448/https://www.eeoc.gov/laws/guidance/background-checks-what-job-applicants-and-employees-should-know
6	The Harvard Crimson——Doxxing Attacks, Employment Losses（2023年12月）	https://www.thecrimson.com/article/2023/12/8/doxxing-students-palestine-feature/	https://web.archive.org/web/20260720063907/https://www.thecrimson.com/article/2023/12/8/doxxing-students-palestine-feature/
7	Network World——Ciscoの公開投稿上のやり取り（2009年3月）	https://www.networkworld.com/article/763101/cisco-subnet-tweeted-out-of-a-job-the-cisco-fatty-story.html	https://web.archive.org/web/20250820182213/https://www.networkworld.com/article/763101/cisco-subnet-tweeted-out-of-a-job-the-cisco-fatty-story.html
8	SHRM——HR Weeds Out Applicants Through Public Social Media Searches（2015年調査）	https://www.shrm.org/topics-tools/news/talent-acquisition/hr-weeds-applicants-public-social-searches	https://web.archive.org/web/20260410095524/https://www.shrm.org/topics-tools/news/talent-acquisition/hr-weeds-applicants-public-social-searches
9	Express Employment Professionals / Harris Poll——Social Media Integral to Recruiting（2022年調査）	https://www.expresspros.com/newsroom/news-releases/news-releases/2023/05/social-media-integral-to-recruiting-as-most-businesses-use-it-to-source-research-and-screen-candidates	https://web.archive.org/web/20251216153245/https://www.expresspros.com/newsroom/news-releases/news-releases/2023/05/social-media-integral-to-recruiting-as-most-businesses-use-it-to-source-research-and-screen-candidates
10	厚生労働省——募集情報等提供事業者等が講ずべき措置	https://www.mhlw.go.jp/web/t_doc?dataId=00005680&dataType=0	https://web.archive.org/web/20260730162215/https://www.mhlw.go.jp/web/t_doc?dataId=00005680&dataType=0
11	厚生労働省——公正な採用選考	https://kouseisaiyou.mhlw.go.jp/consider.html	https://web.archive.org/web/20260202150024/https://kouseisaiyou.mhlw.go.jp/consider.html
12	個人情報保護委員会——個人情報保護法ガイドライン（通則編）	https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/	https://web.archive.org/web/20260730125407/https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
13	個人情報保護委員会——相談ダイヤル	https://www.ppc.go.jp/personalinfo/pipldial/	https://web.archive.org/web/20260730130017/https://www.ppc.go.jp/personalinfo/pipldial/
14	個人情報保護委員会——公開情報と個人情報保護法の適用	https://www.ppc.go.jp/all_faq_index/faq1-q1-5/	https://web.archive.org/web/20251205110629/https://www.ppc.go.jp/all_faq_index/faq1-q1-5/
15	個人情報保護委員会——公開情報の取得・保管	https://www.ppc.go.jp/all_faq_index/faq1-q4-4/	https://web.archive.org/web/20241010164945/https://www.ppc.go.jp/all_faq_index/faq1-q4-4/
16	個人情報保護委員会——個人情報保護法改正、2026年7月17日公表	https://www.ppc.go.jp/news/press/2026/260717/	https://web.archive.org/web/20260730162058/https://www.ppc.go.jp/news/press/2026/260717/
17	厚生労働省——求職者向け「公正な採用選考」相談窓口	https://kouseisaiyou.mhlw.go.jp/jobseekers.html	https://web.archive.org/web/20260128025334/https://kouseisaiyou.mhlw.go.jp/jobseekers.html

#	出典	URL	アーカイブ
1	PGP 2.6.2 User’s Guide——PGP 2.0謝辞（1994年）	https://web.pa.msu.edu/reference/pgpdoc1.html	https://web.archive.org/web/20201112040702/https://web.pa.msu.edu/reference/pgpdoc1.html
2	ハル・フィニー——保存されたホームページ	https://fennetic.net/irc/finney.org/~hal/home.html	https://web.archive.org/web/20250314135429/https://fennetic.net/irc/finney.org/~hal/home.html
3	ハル・フィニー——Why Remailers I（1992年）	https://nakamotoinstitute.org/library/why-remailers-i/	https://web.archive.org/web/20241005233552/https://nakamotoinstitute.org/library/why-remailers-i/
4	ハル・フィニー——Protecting Privacy with Electronic Cash（1993年）	https://nakamotoinstitute.org/library/protecting-privacy-with-electronic-cash/	https://web.archive.org/web/20240813051548/https://nakamotoinstitute.org/library/protecting-privacy-with-electronic-cash/
5	ハル・フィニー——Detecting Double Spending（1993年）	https://nakamotoinstitute.org/library/detecting-double-spending/	https://web.archive.org/web/20240521015620/https://nakamotoinstitute.org/library/detecting-double-spending/
6	ハル・フィニー——Politics vs Technology（1994年）	https://nakamotoinstitute.org/library/politics-vs-technology/	https://web.archive.org/web/20240521015548/https://nakamotoinstitute.org/library/politics-vs-technology/
7	ハル・フィニー——PGP Web of Trust Misconceptions（1994年）	https://nakamotoinstitute.org/library/pgp-web-of-trust-misconceptions/	https://web.archive.org/web/20240521015609/https://nakamotoinstitute.org/library/pgp-web-of-trust-misconceptions/
8	ハル・フィニー——RPOW告知（2004年）	https://cryptome.org/rpow.htm	https://web.archive.org/web/20200702094208/https://cryptome.org/rpow.htm
9	ハル・フィニー——RPOW IBM 4758 Security Model	https://nakamotoinstitute.org/finney/rpow/secmodel.html	https://web.archive.org/web/20240715202954/https://nakamotoinstitute.org/finney/rpow/secmodel.html
10	Satoshi Nakamoto——Bitcoin: A Peer-to-Peer Electronic Cash System	https://bitcoin.org/bitcoin.pdf	https://web.archive.org/web/20210812170542/https://bitcoin.org/bitcoin.pdf
11	ハル・フィニー——Bitcoin P2P e-cash paperへの返信（2008年）	https://www.metzdowd.com/pipermail/cryptography/2008-November/014827.html	https://web.archive.org/web/20220407064228/https://www.metzdowd.com/pipermail/cryptography/2008-November/014827.html
12	Satoshi Nakamoto——Bitcoin v0.1リリース（2009年）	https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html	https://web.archive.org/web/20200207210227/https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html
13	ハル・フィニー——Bitcoin v0.1への公開返信（2009年）	https://www.metzdowd.com/pipermail/cryptography/2009-January/015004.html	https://web.archive.org/web/20260802040419/https://www.metzdowd.com/pipermail/cryptography/2009-January/015004.html
14	ハル・フィニー——「Running bitcoin」（2009年）	https://x.com/halfin/status/1110302988	https://web.archive.org/web/20240719190909/https://x.com/halfin/status/1110302988
15	Bitcoin取引`f4184fc5…e16`、ブロック170	https://blockstream.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16	https://web.archive.org/web/20201112014519/https://blockstream.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
16	ハル・フィニー——Bitcoin and Me（2013年）	https://bitcointalk.org/index.php?topic=155054.msg1644175	https://web.archive.org/web/20220309092611/https://bitcointalk.org/index.php?topic=155054.msg1644175

#	出典	URL	アーカイブ
1	EFF——路上の監視：自動ナンバープレート読取(ALPR)	https://sls.eff.org/technologies/automated-license-plate-readers-alprs	https://web.archive.org/web/*/https://sls.eff.org/technologies/automated-license-plate-readers-alprs
2	EFF——テキサス州の警官が8万3000台のカメラで中絶患者を追跡(2025年5月)	https://www.eff.org/deeplinks/2025/05/she-got-abortion-so-texas-cop-used-83000-cameras-track-her-down	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2025/05/she-got-abortion-so-texas-cop-used-83000-cameras-track-her-down
3	IPVM——監査を始めたとたん、Flock を使った警察の LPR 悪用が3倍に	https://ipvm.com/reports/flock-police-triple-audit	https://web.archive.org/web/*/https://ipvm.com/reports/flock-police-triple-audit
4	ACLU——「Get the Flock Out」キャンペーンとモデル条例案	https://www.aclu.org/campaigns-initiatives/get-the-flock-out	https://web.archive.org/web/*/https://www.aclu.org/campaigns-initiatives/get-the-flock-out
5	ACLU-WA——ファーガソン知事、Driver Privacy Act(SB 6002)に署名	https://www.aclu-wa.org/press-releases/gov-ferguson-signs-sb-6002-the-driver-privacy-act-into-law/	https://web.archive.org/web/*/https://www.aclu-wa.org/press-releases/gov-ferguson-signs-sb-6002-the-driver-privacy-act-into-law/
6	Institute for Justice——Plate Privacy Project(警察の LPR ストーキング事件)	https://ij.org/issues/ijs-project-on-the-4th-amendment/license-plate-readers/	https://web.archive.org/web/*/https://ij.org/issues/ijs-project-on-the-4th-amendment/license-plate-readers/
7	米議会調査局——自動ナンバープレート読取(IF13068)	https://www.congress.gov/crs-product/IF13068	https://web.archive.org/web/*/https://www.congress.gov/crs-product/IF13068
8	カリフォルニア州司法長官——ボンタ、違法な ALPR データ共有でエルカホンを提訴	https://oag.ca.gov/news/press-releases/attorney-general-bonta-sues-el-cajon-illegally-sharing-license-plate-data-out	https://web.archive.org/web/*/https://oag.ca.gov/news/press-releases/attorney-general-bonta-sues-el-cajon-illegally-sharing-license-plate-data-out
9	RadarTest——PhotoBlocker／反射式プレート製品のレビュー	https://radartest.com/photoblocker-review.asp	https://web.archive.org/web/*/https://radartest.com/photoblocker-review.asp
10	NCSL——自動ナンバープレート読取：各州の法令	https://www.ncsl.org/technology-and-communication/automated-license-plate-readers-state-statutes	https://web.archive.org/web/*/https://www.ncsl.org/technology-and-communication/automated-license-plate-readers-state-statutes
11	TribLive——警察機材で女性をストーキングした元警官に判決(McSherry、PA)	https://triblive.com/local/valley-news-dispatch/ex-cop-who-used-police-gear-to-stalk-woman-pleads-guilty-sentenced-to-jail-probation/	https://web.archive.org/web/*/https://triblive.com/local/valley-news-dispatch/ex-cop-who-used-police-gear-to-stalk-woman-pleads-guilty-sentenced-to-jail-probation/
12	KAKE——セジウィックの警察署長、プレートカメラで元交際相手を164回追跡(Nygaard、KS)	https://www.kake.com/home/sedgwick-police-chief-tracked-ex-girlfriend-164-times-using-license-plate-cams/article_21fdfdba-5dc5-11ef-95c4-8be8baa3f10c.html	https://web.archive.org/web/*/https://www.kake.com/home/sedgwick-police-chief-tracked-ex-girlfriend-164-times-using-license-plate-cams/article_21fdfdba-5dc5-11ef-95c4-8be8baa3f10c.html
13	TMJ4——元ミルウォーキー警官、警察技術で元交際相手をストーキングし有罪答弁(Ayala、WI)	https://www.tmj4.com/news/local-news/in-your-community/milwaukee-county/former-milwaukee-officer-pleads-guilty-to-misdemeanor-for-stalking-ex-girlfriend-with-police-technology	https://web.archive.org/web/*/https://www.tmj4.com/news/local-news/in-your-community/milwaukee-county/former-milwaukee-officer-pleads-guilty-to-misdemeanor-for-stalking-ex-girlfriend-with-police-technology
14	EFF——Get the Flock Out of Here(2026年)	https://www.eff.org/deeplinks/2026/06/get-flock-out-here	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2026/06/get-flock-out-here
15	TechTimes——Flock Safety がカメラ10万台を突破、53都市が契約解除(2026年6月)	https://www.techtimes.com/articles/319317/20260629/flock-safety-crosses-100000-cameras-as-53-cities-cancel-over-unauthorized-federal-data-access.htm	https://web.archive.org/web/*/https://www.techtimes.com/articles/319317/20260629/flock-safety-crosses-100000-cameras-as-53-cities-cancel-over-unauthorized-federal-data-access.htm
16	EFF と ACLU——SFPD が ALPR データを ICE と反中絶州に違法共有(2025年9月)	https://www.eff.org/deeplinks/2025/09/eff-aclu-sfpd-stop-illegally-sharing-data-ice-and-anti-abortion-states	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2025/09/eff-aclu-sfpd-stop-illegally-sharing-data-ice-and-anti-abortion-states

#	出典	URL	アーカイブ
1	NIST——SP 800-63B-4：認証手段とフィッシング耐性	https://pages.nist.gov/800-63-4/sp800-63b/authenticators/	https://web.archive.org/web/20260701051113/https://pages.nist.gov/800-63-4/sp800-63b/authenticators/
2	NIST——SP 800-63B-4：認証手段のイベント管理とアカウント復旧	https://pages.nist.gov/800-63-4/sp800-63b/events/	https://web.archive.org/web/20260323072006/https://pages.nist.gov/800-63-4/sp800-63b/events/
3	FIDO Alliance——Passkey Indexの公開と2025年の結果	https://fidoalliance.org/fido-alliance-launches-passkey-index-revealing-significant-passkey-uptake-and-business-benefits/	https://web.archive.org/web/20260420062740/https://fidoalliance.org/fido-alliance-launches-passkey-index-revealing-significant-passkey-uptake-and-business-benefits/
4	FIDO Alliance——同期型パスキーの導入：消費者向け事例で新たに見えてきた実務	https://fidoalliance.org/wp-content/uploads/2024/05/Synced-Passkey-Deployment_-Emerging-Practices-for-Consumer-Use-Cases_2024-Final.pdf	https://web.archive.org/web/20260420102322/https://fidoalliance.org/wp-content/uploads/2024/05/Synced-Passkey-Deployment_-Emerging-Practices-for-Consumer-Use-Cases_2024-Final.pdf
5	FIDO Alliance——Credential Exchange Format、提案標準（2026年3月9日）	https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-20260309.pdf	https://web.archive.org/web/20260515224326/https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-20260309.pdf
6	Google——Google パスワードマネージャーのPINを管理する	https://support.google.com/chrome/answer/16608973	https://web.archive.org/web/20260729220641/https://support.google.com/chrome/answer/16608973
7	Google——GoogleアカウントまたはGmailを復元する	https://support.google.com/accounts/answer/7682439?hl=en	https://web.archive.org/web/20260713163540/https://support.google.com/accounts/answer/7682439?hl=en
8	Google——Recovery Contactsの発表（2025年10月15日）	https://blog.google/innovation-and-ai/technology/safety-security/how-google-protects-against-scams-2025/	https://web.archive.org/web/20260524055556/https://blog.google/innovation-and-ai/technology/safety-security/how-google-protects-against-scams-2025/
9	Google——パスキー導入状況と利用データの更新（2024年5月2日）	https://blog.google/innovation-and-ai/technology/safety-security/google-passkeys-update-april-2024/	https://web.archive.org/web/20260711072347/https://blog.google/innovation-and-ai/technology/safety-security/google-passkeys-update-april-2024/
10	Apple——iCloudキーチェーンのセキュリティ概要	https://support.apple.com/en-gb/guide/security/sec1c89c6f3b/web	https://web.archive.org/web/20260312052028/https://support.apple.com/en-gb/guide/security/sec1c89c6f3b/web
11	Apple——Apple Accountの復旧用連絡先を設定する	https://support.apple.com/en-us/102641	https://web.archive.org/web/20260628000018/https://support.apple.com/en-us/102641
12	Apple——Apple Accountの復旧キーを設定する	https://support.apple.com/en-ie/109345	https://web.archive.org/web/20260516085000/https://support.apple.com/en-ie/109345
13	Microsoft——パスキーとは何か、なぜ重要なのか	https://support.microsoft.com/en-us/windows/security/identity-signin/what-are-passkeys-and-why-they-matter	https://web.archive.org/web/20260722085522/https://support.microsoft.com/en-us/windows/security/identity-signin/what-are-passkeys-and-why-they-matter
14	Microsoft——Microsoftアカウント復旧フォームに関するヘルプ	https://support.microsoft.com/en-us/accounts-billing/manage/help-with-the-microsoft-account-recovery-form	https://web.archive.org/web/20260727062121/https://support.microsoft.com/en-us/accounts-billing/manage/help-with-the-microsoft-account-recovery-form
15	Microsoft——Microsoftアカウントの復旧コードを取得する方法	https://support.microsoft.com/en-us/accounts-billing/manage/how-to-get-a-microsoft-account-recovery-code	https://web.archive.org/web/20260713003505/https://support.microsoft.com/en-us/accounts-billing/manage/how-to-get-a-microsoft-account-recovery-code
16	Microsoft Entra——パスキーの既定有効化とSMS／音声認証の廃止	https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement	https://web.archive.org/web/20260724230317/https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement
17	GitHub——パスキーを管理する	https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys	https://web.archive.org/web/20260708055407/https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys
18	GitHub——2FAの復旧方法を設定し、失った認証情報から復旧する	https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication-recovery-methods	https://web.archive.org/web/20260716133240/https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication-recovery-methods
19	GitHub——2FAの認証情報を失った場合にアカウントを復旧する	https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/recovering-your-account-if-you-lose-your-2fa-credentials	https://web.archive.org/web/20260728005320/https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/recovering-your-account-if-you-lose-your-2fa-credentials
20	Google——パスワードの代わりにパスキーでログインする	https://support.google.com/accounts/answer/13548313?hl=en	https://web.archive.org/web/20260721063041/https://support.google.com/accounts/answer/13548313?hl=en
21	Google——2段階認証でよくある問題を解決する	https://support.google.com/accounts/answer/185834?hl=en	https://web.archive.org/web/20260627232455/https://support.google.com/accounts/answer/185834?hl=en
22	Apple——パスキーのセキュリティについて	https://support.apple.com/en-us/102195	https://web.archive.org/web/20260728162533/https://support.apple.com/en-us/102195
23	Apple——Apple Accountのセキュリティキーについて	https://support.apple.com/en-gb/102637	https://web.archive.org/web/20260217211459/https://support.apple.com/en-gb/102637
24	Microsoft——個人アカウント向けSMSコードの段階的廃止	https://support.microsoft.com/en-us/accounts-billing/manage/microsoft-to-stop-sending-sms-codes-for-personal-accounts	https://web.archive.org/web/20260714002357/https://support.microsoft.com/en-us/accounts-billing/manage/microsoft-to-stop-sending-sms-codes-for-personal-accounts
25	Apple——Apple Accountのパスワードをリセットできない場合のアカウント復旧	https://support.apple.com/en-gb/118574	https://web.archive.org/web/20260309005225/https://support.apple.com/en-gb/118574

CypherpunkGuide

Bitcoinを買った後の10ステップ：セルフカストディ検証手順（2026年版）

最初の原則：自己管理はリスクの移転である #

受領・署名・復旧は、それぞれ別の証明である #

10ステップのセルフカストディ検証 #

ステップ1：購入記録を保存し、取引所アカウントを守る #

ステップ2：今日引き受けられる責任の大きさを決める #

ステップ3：検証できる公式経路からウォレットを入手する #

ステップ4：ウォレットを作り、復旧に必要な情報をすべて記録する #

ステップ5：全額を入れる前にバックアップを確認する #

ステップ6：新しいアドレスを作り、全文字を照合する #

ステップ7：損失を限定するテスト出金を行う #

ステップ8：受領を証明する #

ステップ9：少額送金で署名を証明する #

ステップ10：復旧を証明し、運用計画を完成させる #

隔離環境のBitcoin Core 31.1検証で分かったこと #

結論：残りを移す前に、管理権の引き渡しを終わらせる #

よくある質問 #

Bitcoinは取引所からすぐに引き出すべきですか？ #

ハードウェアウォレットは必要ですか？ #

テスト出金に成功すれば、自己管理できた証明になりますか？ #

どのウォレットでも、シードフレーズからBitcoinを復旧できますか？ #

Bitcoinを買った後、どの税務記録を残すべきですか？ #

Cora Aegis

一次資料とアーカイブ #

Bitcoinパスワード復旧：AIにできること、できないこと（2026年）

Bitcoinのパスワードは本当に復旧できるのか #

2026年に報じられたAI復旧で、実際に起きたこと #

AIは候補を整理し、ソフトウェアが正誤を判定する #

BTCRecoverで架空データを11回検証して分かったこと #

BTCRecover、Hashcat、ローカルAI、復旧業者を比べる #

オフライン優先で進める7段階の復旧手順 #

復旧業者へウォレットを丸ごと渡さずに評価する #

結論：何を失ったか、秘密をどこまで見せるかで選べ #

よくある質問 #

AIで忘れたBitcoinウォレットのパスワードを復旧できますか？ #

BTCRecoverなら、どんなBitcoinパスワードでも総当たりできますか？ #

BIP39パスフレーズとウォレットのパスワードは同じですか？ #

復旧業者へwallet.datを渡しても安全ですか？ #

復旧に成功した直後、何をすべきですか？ #

Cora Aegis

出典とアーカイブ #

Methodology — KYC Driftがhosted AI事業者の主張を記録する方法

現行パイロットの状態 #

記録する単位 #

意図的に測らないもの #

値の情報源 #

統制語彙と空欄を作らない規則 #

証拠、日付、完全性 #

主張の情報源、完全性、実運用、鮮度、矛盾 #

経時変化、訂正、異議 #

更新目標と現在の限界 #

スコアを付けない理由 #

選定とライセンス #

強要のもとでの Bitcoin 自己管理 2026 — サバイバーのための脅威モデル

定番の管理術は、脅威が家の中にいると崩れる #

相手の能力で考える対応表 #

Bitcoin の前に、まず端末と計画を守る #

強要のもとでの管理の選択肢——その正直な限界 #

Bitcoin の公開台帳そのものが、もう一つの露出になる #

段階で応じる——その場面に、その一手を合わせる #

Bitcoin が答えではないとき #

結論——あなたのリスクに合う計画を立てる #

よくある質問 #

ハードウェアウォレットは、パートナーに使うところを見られていても私を守ってくれますか? #

おとりや「強要対応」のウォレットは、強要のもとで安全に使えますか? #

multisig に、友人や家族を入れるべきですか? #

端末が監視されていると思ったら、まず何をすべきですか? #

安全に離れるには、Bitcoin は銀行口座より良いですか? #

参考文献 #

Cora Aegis

Cypherpunk Manifesto とは何か——2026年に読み直す入門

Cypherpunk Manifesto が実際に語っていること #

3つの文章、ひとつの思想——May、Hughes、Chaum #

名付けた女性——ジュード・ミルホン #

1993年の予言を、2026年に採点する #

「Cypherpunk はコードを書く」——2026年における倫理 #

結論——1993年の文章が、いまも基準を定めている理由 #

よくある質問 #

Cypherpunk Manifesto とは何ですか？ #

最初の原則：自己管理はリスクの移転である
#

受領・署名・復旧は、それぞれ別の証明である
#

10ステップのセルフカストディ検証
#

ステップ1：購入記録を保存し、取引所アカウントを守る
#

ステップ2：今日引き受けられる責任の大きさを決める
#

ステップ3：検証できる公式経路からウォレットを入手する
#

ステップ4：ウォレットを作り、復旧に必要な情報をすべて記録する
#

ステップ5：全額を入れる前にバックアップを確認する
#

ステップ6：新しいアドレスを作り、全文字を照合する
#

ステップ7：損失を限定するテスト出金を行う
#

ステップ8：受領を証明する
#

ステップ9：少額送金で署名を証明する
#

ステップ10：復旧を証明し、運用計画を完成させる
#

隔離環境のBitcoin Core 31.1検証で分かったこと
#

結論：残りを移す前に、管理権の引き渡しを終わらせる
#

よくある質問
#

Bitcoinは取引所からすぐに引き出すべきですか？
#

ハードウェアウォレットは必要ですか？
#

テスト出金に成功すれば、自己管理できた証明になりますか？
#

どのウォレットでも、シードフレーズからBitcoinを復旧できますか？
#

Bitcoinを買った後、どの税務記録を残すべきですか？
#

一次資料とアーカイブ
#

Bitcoinのパスワードは本当に復旧できるのか
#

2026年に報じられたAI復旧で、実際に起きたこと
#

AIは候補を整理し、ソフトウェアが正誤を判定する
#

BTCRecoverで架空データを11回検証して分かったこと
#

BTCRecover、Hashcat、ローカルAI、復旧業者を比べる
#

オフライン優先で進める7段階の復旧手順
#

復旧業者へウォレットを丸ごと渡さずに評価する
#

結論：何を失ったか、秘密をどこまで見せるかで選べ
#

よくある質問
#

AIで忘れたBitcoinウォレットのパスワードを復旧できますか？
#

BTCRecoverなら、どんなBitcoinパスワードでも総当たりできますか？
#

BIP39パスフレーズとウォレットのパスワードは同じですか？
#

復旧業者へ`wallet.dat`を渡しても安全ですか？
#

復旧に成功した直後、何をすべきですか？
#

出典とアーカイブ
#

現行パイロットの状態
#

記録する単位
#

意図的に測らないもの
#

値の情報源
#

統制語彙と空欄を作らない規則
#

証拠、日付、完全性
#

主張の情報源、完全性、実運用、鮮度、矛盾
#

経時変化、訂正、異議
#

更新目標と現在の限界
#

スコアを付けない理由
#

選定とライセンス
#

定番の管理術は、脅威が家の中にいると崩れる
#

相手の能力で考える対応表
#

Bitcoin の前に、まず端末と計画を守る
#

強要のもとでの管理の選択肢——その正直な限界
#

Bitcoin の公開台帳そのものが、もう一つの露出になる
#

段階で応じる——その場面に、その一手を合わせる
#

Bitcoin が答えではないとき
#

結論——あなたのリスクに合う計画を立てる
#

よくある質問
#

ハードウェアウォレットは、パートナーに使うところを見られていても私を守ってくれますか?
#

おとりや「強要対応」のウォレットは、強要のもとで安全に使えますか?
#

multisig に、友人や家族を入れるべきですか?
#

端末が監視されていると思ったら、まず何をすべきですか?
#

安全に離れるには、Bitcoin は銀行口座より良いですか?
#

参考文献
#

Cypherpunk Manifesto が実際に語っていること
#

3つの文章、ひとつの思想——May、Hughes、Chaum
#

名付けた女性——ジュード・ミルホン
#

1993年の予言を、2026年に採点する
#

「Cypherpunk はコードを書く」——2026年における倫理
#

結論——1993年の文章が、いまも基準を定めている理由
#

よくある質問
#

Cypherpunk Manifesto とは何ですか？
#

Cypherpunk Manifesto を書いたのは誰ですか。「cypherpunk」という語を作ったのは誰ですか？
#

Cypherpunk Manifesto と Crypto Anarchist Manifesto は、どう違いますか？
#

Cypherpunk Manifesto は、2026年のいまも意味がありますか？
#

cypherpunk になるには、プログラマーでなければなりませんか？
#

「削除」というユーザーインターフェースの幻想
#

2026年の新しい経路——あなたの投稿は、いまや AI の学習データ
#

ジャスティン・サッコの12時間のフライトが、2026年もなお教えること
#

古いアカウント棚卸しの手順書——6ステップの自己点検
#

リスクが非対称なとき——女性と標的にされる個人の足跡リスク
#