資金について：CypherpunkGuideは監視型広告を一切載せない——広告ネットワークも、トラッキングピクセルも、スポンサー記事もない。運営資金は透明な収益源から得ている。現在は読者からの寄付で賄い、将来は購読と編集方針に合うアフィリエイト収入も充てる。私たちは広告主ではなく、読者に向き合う。
支払いは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を一緒に使えば匿名になりますか？#
いいえ。それぞれが守る記録は別です。取引相手、侵害された端末、同じIPを使い続ける通信経路、続けて起きる操作の時刻、共通の復旧アカウントから、作業全体を結び付けられる場合があります。匿名性は3つの製品名から得られる機能ではありません。想定した観測者が記録を結び付けられるかどうかで判断してください。
Moneroは外部ノードからIPアドレスを隠しますか？#
初期設定では隠しません。Moneroの技術資料は通信元の保護を別の対策として扱い、TorまたはI2Pによる経路を説明しています。ウォレットが実際に使う経路を確認してください。公開台帳上で送金元、受取人、金額を守る仕組みから、IPアドレスまで隠れるとは推定できません。
SimpleXには識別子もメタデータもないのですか？#
いいえ。全接続で同じ利用者を示すグローバルなプロフィール識別子は、メッセージ配送に使いません。しかし、相手ごとのキュー識別子と、運用に必要な記録が存在することは資料で確認できます。中継サーバー、連絡相手、通知サービス、ネットワーク上の観測者、端末では、それぞれ見える項目が違います。
クラウド事業者はCryptomatorを使っていることに気付きますか？#
はい。Cryptomatorはファイルの内容と名前を暗号化しますが、保管庫の形式そのものを隠そうとはしません。暗号化オブジェクトの拡張子、設定ファイル、更新時刻、数、保存後のサイズは、クラウド側から見える場合があります。
復旧情報をすべて1つのパスワードマネージャーへ入れてもよいですか？#
そのマネージャーと復旧経路が、3つすべてを結び付ける一点になることを脅威モデルで受け入れるなら選択肢になります。危険が大きい使い方では、まとめて失ったり奪われたりすると全体が露出する復旧情報を分けてください。そのうえで、分離が自分を締め出す原因にならないよう復旧を試してください。
出典#
変更されうる公式資料13件について、原ページと日時が一致するWayback保存版を併記した。本文の主張は現在の公式ページに基づき、保存版は後から同じ資料を確かめるための第二経路として使う。
