Bitcoin Core、AIで容易に見つかる脆弱性は非公開期間なしで修正・公表へ 開示方針を改定

Last Updated on 2026年10月30日 by Co-Founder/ Researcher

Bitcoin Coreは、修正した脆弱性をしばらく公表しない方針を続けてきました。更新を急がない利用者に、時間を確保するためです。けれども、AIへの簡単な指示で見つかる脆弱性なら、長く隠しておく効果は乏しくなります。隠しておく時間は、いったい誰を守っているのでしょうか。

Bitcoin Coreは2026年10月22日（UTC）、脆弱性の開示方針を改定した。最小限の労力で見つかる脆弱性、たとえば大規模言語モデル（LLM）への簡単な指示で見つかるものを「容易に発見できる（easily discoverable）」と分類する。この分類に当たる脆弱性には重大度に応じた非公開期間を適用せず、保守中の各メジャーバージョン向けに修正を含むポイントリリースをできるだけ早く出し、セキュリティアドバイザリを同時に公表する。それ以外は、Lowは修正を含むメジャーリリースの2週間後、MediumとHighは影響を受ける最後の版がサポート終了を迎えた2週間後に開示する。

提案者は、LLMによって特定の種類の問題や、ひそかに行った修正を見つけるハードルが大きく下がったと説明している。

From: Update security policy for easy-to-find vulnerabilities (bitcoin-core/bitcoincore.org #1281)

Bitcoin Coreの脆弱性の開示方針は、2024年に導入されて以来、修正したあとも一定の非公開期間を置くことを基本にしてきました。今回の改定は、その扱いに新しい例外を加えるものです。LLMへの簡単な指示など、最小限の労力で見つかる脆弱性については、長い非公開期間の効果が乏しい、という判断です。

改定は、bitcoincore.orgのリポジトリに出されたプルリクエスト（#1281）として10月16日に提案され、複数の開発者の賛同を経て、10月22日（UTC、日本時間23日）にマージされました。

なぜ「黙っておく時間」が必要だったのか

提案の説明文は、セキュリティの方針には、互いに引っ張り合う二つの目標があると書いています。一つは透明性で、攻撃する側と守る側の情報の差を縮めます。もう一つは、利用者が更新するための時間です。脆弱性を早く公表しすぎると、多くの利用者がまだ古い版を使っているうちに、攻撃の手がかりを渡してしまいます。

Bitcoin Coreは、後者を重く見てきました。提案者は、プロジェクトの性質に加え、更新を急がない文化が背景にあると説明しています。通常の非公開期間を適用するMediumとHighの脆弱性は、影響を受ける最後の版がサポートを終えた2週間後に公表されます。方針の本文では、修正を含むメジャーリリースが出てからおよそ1年後とされています。提案者によれば、こうした長い非公開期間を保つため、修正を過去の版にさかのぼって適用せず、次のメジャーリリースで届けるのが一般的でした。

AIが変えたのは、隠すことの効き目

提案者は、容易に再発見できる脆弱性の報告が最近増えたと書いています。大規模言語モデル（LLM）によって、特定の種類の問題を見つけるハードルも、コードにひそかに入れた修正を見抜くハードルも、大きく下がったからです。

提案者は、容易に再発見できる脆弱性については、長い非公開期間がもたらす保護は乏しく、修正版を届ける時期を遅らせてしまうと説明しています。過去の版にさかのぼって修正を急いで適用すれば、その修正自体から脆弱性が読み取られてしまう、とも指摘しています。

AIを使った脆弱性探しは、すでに現実のものです。Decryptによると、有志の「Bitcoin Red Team」は8月、ビットコイン関連の390のプロジェクトをAIで調べ、4,962件の指摘を記録しました。8月に取り上げたColdcardの事件でも、メーカーのCoinkiteは、AIが過去のファームウェアを調べて問題を発見した可能性に言及していました。ただし、攻撃者がAIを使ったと確認されたわけではありません。

議論で見えた、線の引き方

マージまでの議論は、短いながらも中身の濃いものでした。

ある開発者は、さらに踏み込むべきだと指摘しました。いまはリポジトリを安く自動で監視できるため、修正のプルリクエストを開いた時点で多くの攻撃者に気づかれ、大半の利用者への通知だけが数日から数週間遅れる状況になりかねない、と懸念したのです。そのうえで、修正のプルリクエストを開く時点までに公表することも選択肢だと提案しました。

これに対し提案者は、致命的（Critical）な脆弱性はもともと個別に対応する決まりになっており、その範囲で対処できると答えました。それより軽い脆弱性については、修正版が出る前に利用者へ警告すると、利益より害が大きくなるのではないかと懸念を示しています。

別の開発者からは、修正版を出すときにアドバイザリを出すかどうかを、その都度判断できるようにする案も出ました。提案者は、詳細のない警告は、本来は影響を受けない利用者まで慌てて移行させ、かえってリスクを生むと反対しています。例として挙げたのは、ブロックのテンプレート作成に関わる問題です。マイナーはすぐに更新すべきでも、決済を受け付ける事業者は落ち着いて更新すればよい。誰が、どれだけ急ぐべきかを伝えるために、アドバイザリは修正版と同時に出す、という考え方です。

ノードを動かす人の負担は、少し重くなる

この改定で、容易に発見できると分類された脆弱性の修正は、保守中の各メジャーバージョンへ適用され、ポイントリリースとしてできるだけ早く届くことになります。議論では、その結果としてリリースの頻度が増える可能性も指摘されました。提案者自身も、修正を開発中のブランチで試す時間が短くなると認めています。そのため、不必要に注目を集めないことを基本としつつも、ほかの箇所を壊さない確信を持てる素直な修正なら、問題を隠しにくくなることを受け入れる場面が増えるだろうとしています。

自分でノードを動かすことは、ビットコインの検証を他人に任せないための選択です。今回の改定は、その選択に伴う責任を少し重くします。アドバイザリを読み、自分が影響を受けるかを判断し、必要なら早く更新する。取引所やカストディ事業者、マイナーだけでなく、個人でノードを運用する人にも、その姿勢が求められるようになります。

「隠して直す」から「直してすぐ話す」へ

脆弱性をいつ、どこまで明かすかは、プロジェクトごとに判断が分かれています。8月に取り上げたPolygonは、修正をまず非公開のビルドとして配り、メインネットで有効になってから公表しました。10月に取り上げたXRP Ledgerは、通常のアメンドメント投票を経ずに、各サーバーの更新ですぐに効く修正を出しました。どちらも、修正の中身が攻撃の手引きにならないよう、公開の順番を工夫した例です。

Bitcoin Coreの今回の改定は、それとは逆向きの判断に見えます。ただ、目指しているものは同じです。攻撃者より先に、守る側に修正を届けること。AIが脆弱性探しの速さを変えたいま、守る側の手順も速さに合わせて組み直されていく。ビットコインの開発文化が、その変化に正面から向き合った一歩と言えます。

Bitcoin Core
ビットコインのネットワークで最も広く使われている、ノードのソフトウェア。オープンソースで開発され、ビットコインの元のソフトウェアの流れをくむ。

脆弱性の開示方針
ソフトウェアの脆弱性が報告されたとき、修正をどう配り、いつ、どこまで公表するかを定めた方針。

非公開期間（エンバーゴ）
修正を済ませてから、脆弱性の詳細を公表するまでに置く期間。利用者が更新する時間を確保する目的がある。

大規模言語モデル（LLM）
大量の文章で学習し、文章の生成や要約、コードの読解などを行うAIのモデル。

重大度
Bitcoin Coreは脆弱性をLow、Medium、High、Criticalの4つに分け、区分ごとに公表の時期を定めている。Criticalは個別に対応する。

メジャーバージョン
大きな機能の追加などを含む、番号の最初の数字が変わる版。Bitcoin Coreは直近のいくつかのメジャーバージョンを保守対象としている。

ポイントリリース
メジャーバージョンの中で、不具合や脆弱性の修正のために出す小さな更新版。

セキュリティアドバイザリ
脆弱性の内容、影響を受ける版、対応方法などを利用者に知らせる公式の告知。

プルリクエスト
GitHubなどで、コードや文書の変更を提案し、ほかの開発者のレビューを受ける仕組み。承認されると本体に取り込まれる（マージ）。

サポート終了
ある版が保守の対象から外れ、原則として修正が提供されなくなること。英語ではEnd of Life（EOL）。

ノード
ブロックチェーンの取引やブロックを自ら検証し、ネットワークに中継するコンピューター。

アメンドメント
XRP Ledgerで、取引処理のルールを変えるための仕組み。バリデーターの一定以上の支持が続くと有効になる。

Bitcoin Core Security Advisories（外部）
Bitcoin Coreの脆弱性の開示方針の現行の本文と、過去のセキュリティアドバイザリの一覧を掲載している公式ページ。

Bitcoin Core Lifecycle（外部）
Bitcoin Coreのメジャーバージョンごとの保守期間とサポート終了の考え方を説明している公式ページ。更新の目安になる。

Bitcoin Core SECURITY.md（外部）
Bitcoin Coreの脆弱性の報告先と報告の手順、連絡に使う鍵などをまとめた、GitHubのリポジトリ上の公式の文書。

Bitcoin Core Rewrites Its Security Policy for a World Where AI Finds Bugs in One Prompt（Decrypt）（外部）
Bitcoin Coreの方針改定を、AIで脆弱性が見つけやすくなった背景とともに報じた記事。PR #1281へのリンクを含む。

Bitcoin will now stop hiding bugs an AI can find in one prompt（CoinDesk）（外部）
Bitcoin Coreが、AIが1回の指示で見つけられるバグを長く隠さない方針に変えたことを報じた、CoinDeskの10月23日の記事。

Bitcoin AI security audit files 4,962 findings across 390 projects（Decrypt）（外部）
有志のBitcoin Red Teamが、AIでビットコイン関連の390のプロジェクトを調べた途中経過を報じた2026年8月の記事。

Bitcoin Coreの脆弱性開示方針改定「AI容易発見分類」と「隠しておく時間は誰を守るか」の問いを、より広い文脈で理解するための関連記事をご案内します。脆弱性開示手順とプロトコル改革・AI×セキュリティとAIレッドチーミング・BTC/Ethereum/Solanaプロトコル改革・取引所セキュリティを横断的に読むことで、「AIが脆弱性探しの速さを変えたいま、守る側の手順も速さに合わせて組み直されていく」という共通の課題が立体的に見えてきます。

脆弱性開示手順・プロトコル改革

• XRP Ledger、アメンドメント投票を経ずに脆弱性を修正 10年以上で初 → 本記事内で明示的に言及される、10月のXRPL脆弱性修正動向。「XRPL：アメンドメント手続きを飛ばして即時配布」「Bitcoin Core：従来の長い非公開期間を一部放棄」いずれも開示順序の工夫を両記事併読で立体的に理解できます。
• Polygonが直してから話した理由—非公開で先に配る手順が残した記録 → 本記事内で明示的に言及される、8月のPolygon非公開先行配布動向。「Polygon：非公開ビルドで先に配り、有効化後に公表」「Bitcoin Core：直してすぐ話す」の逆方向の判断を対比して理解できます。
• BlackRock・Strategy・Coinbaseら9社が Bitcoin Security Consortium 設立、量子対策を含むセキュリティ開発へ3年1500万ドル → 本記事のBTCセキュリティ動向と並ぶ、BTC 9社連合による長期セキュリティ開発動向。
• Ethereum研究者ドレイク氏が「bunker mode」提唱、AIによるECDSA解読に備え → 本記事のAI脅威動向と直接連動する、AIによる暗号解読脅威への備え動向。「AIが脆弱性を見つける」「AIが暗号を解く」両軸でのAI脅威論点を理解できます。

AI×セキュリティ・AIレッドチーミング

• Coldcardのシード生成に欠陥、第4波疑いを含め約1,816 BTC流出の暫定推計—競合取引は被害者と攻撃者の双方の手段に → 本記事内で明示的に言及される8月のColdcard事件動向。「メーカーCoinkiteがAIが過去のファームウェアを調べた可能性に言及」の背景を両記事併読で立体的に理解できます。
• アライドアーキテクツ × Nyx Foundation、AIがDeFiの安全を”検算”する時代へ → 本記事のAI×セキュリティ動向と並ぶ、AI×形式検証によるオンチェーン安全性検証動向。「AI攻撃側」「AI防御側」両軸でのAIレッドチーミング論点を理解できます。
• Ledger・Trezorを狙う新型マルウェア「OkoBot」—正規アプリ内から偽の復元画面でシードフレーズを盗む → 本記事のハードウェアウォレット脆弱性動向と並ぶ、新型マルウェア事例。
• Anthropic報告が示すKYCの死角｜本人確認は偽造されず中継された → 本記事のAI×セキュリティ動向と並ぶ、AI×業界セキュリティ脅威事例動向。

プロトコル改革・BTC/Ethereum/Solana

• サトシ・ナカモト四人説、Ripple名誉CTOが語ったのは鍵の行方 → 本記事のBTC長期プロトコル論点と並ぶ、BTC初期P2PK出力とBIP-361量子救済動向。
• Ethereum「Lean Ethereum」始動—ブテリンが量子耐性・プライバシー・拡張性を最優先に → 本記事のプロトコル改革動向と並ぶ、Ethereum本体側のプロトコル改革ロードマップ動向。
• Solana「Alpenglow」、確定は誰でも検証できる証明書に → 本記事のプロトコル改革動向と並ぶ、Solana本体側のプロトコル改革動向。

取引所セキュリティ・被害事例

• Bitgetで約3億8800万ドルが不正流出、CEOは回収に慎重な見方 → 本記事のセキュリティ動向と並ぶ、取引所セキュリティ事例動向。
• Hinkal約82万ドル流出—プライバシー保護protocolが「証明なし入金」で破られた皮肉 → 本記事の脆弱性修正動向と並ぶ、実際に悪用された脆弱性事案動向。

直近姉妹記事

• OCC、GENIUS法の最終規則を公表 ステーブルコインの利回り禁止で第三者経由の「推定」を削除 → 本記事の直前姉妹記事。「BTC本体のセキュリティ方針改定」「米国ステーブルコイン規制最終化」いずれも2026年10月下旬の重要動向を対比して理解できます。

議論の中で、ある開発者は、修正版を出したあとに公表するというこれまでの約束そのものが、今後は守りにくくなるだろうと書いていました。見つけやすい脆弱性と、隠しきれない修正の境目は、これからも速く動き続けるからです。

いまは簡単な指示では見つからない脆弱性も、次のモデルでは見つかるかもしれません。今回の「例外」が、いつか例外でなくなる日が来るのか。その線がどこまで動くのかは、ノードを動かす側も見ておく必要がありそうです。

——————–
※本記事は情報提供を目的としており、投資助言ではありません。
　詳細は当サイトの免責事項をご確認ください。
——————–