資金について：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を替えても現実的に復旧できない場合がある。
よくある質問#
AIが役に立つのは、記憶や既存の証拠によって候補数を有限に絞れる場合だけである。BTCRecoverはパスワードを再設定せず、BIP39パスフレーズの照合には既知の対象が要る。クラウドAIへ渡せるのは抽象的なパターンと架空の置き換え文字だけだ。解除に成功した後も、同じウォレットを使い続けず、新しい環境へ移す必要がある。
AIで忘れたBitcoinウォレットのパスワードを復旧できますか？#
場合によっては、実行可能な検索へ絞るための文脈を探せます。古いファイルの場所、パスワードの構造、誤入力の癖、公式ツールの選択肢などです。ただし、ウォレットからランダムで予測しにくいパスワードを導き出したり、暗号化を迂回したりはできません。固定したソフトウェアが、実際に正しい候補を試す必要があります。
BTCRecoverなら、どんなBitcoinパスワードでも総当たりできますか？#
できません。BTCRecoverは多くのウォレット形式に対応し、候補を効率よく生成できます。それでも、正しいウォレット情報、対応形式、有効な照合先、現実的な時間で終わる候補数が必要です。ツールが形式へ対応していることは、復旧の保証ではありません。
BIP39パスフレーズとウォレットのパスワードは同じですか？#
同じではありません。ウォレットのパスワードは、通常、保存された鍵情報を復号します。BIP39パスフレーズはニーモニックと組み合わせてシードを導き出します。どの文字列でも有効なシードになりますが、通常は意図したものとは別のウォレットを導き出します。復旧には正確なニーモニックと既知の照合先が必要で、すべてオフラインで扱います。
復旧業者へwallet.datを渡しても安全ですか？#
暗号化されたウォレットファイルも機微情報です。Bitcoin Coreの資料では、暗号化が守るのは秘密鍵であり、データベース内のすべてではなく、取引情報は見えると説明されています。公式資料が単体で資金を動かせないと明記する縮小データを優先し、それでもプライバシー上の機微情報として扱ってください。業者が解除に必要な一式を求めるなら、鍵の管理権をすべて預けるのと同じです。
復旧に成功した直後、何をすべきですか？#
信頼できる機器で新しいウォレットと復旧方法を作り、検証してください。宛先と手数料を確認してから資金を移します。古いパソコン、候補ファイル、ログ、関与した第三者によって、秘密情報に触れた範囲が広がったと考えてください。一度開けたという理由だけで、古い環境を使い続けないでください。
出典とアーカイブ#
本記事の主張は、公式ソフトウェア資料、仕様、政府機関の詐欺警告、および対象を一つの事例に限定した報道1件にもとづく。12件の原文URLが表示できることは2026年8月21日と2026年8月23日に確認した。下記の日時固定Wayback保存版は、2026年8月23日に12件すべてHTTP 200で再生できることを確認した。
