Bitcoinのオープンソース・エコシステムでは、AIを使ったセキュリティレビューが新しい規模に達している。2026年8月の短期集中監査で、ボランティア団体のBitcoin Red Teamは、人間が指揮する複数モデルのワークフローにより、約390のBitcoin関連リポジトリを約27.5時間で調査したと報告した。報告件数は4,962件で、このうち85件を「重大」、635件を「高」深刻度に分類している。もっとも、これは4,962件の悪用可能な脆弱性が確定したという意味ではない。あくまで検証待ちの有力な候補であり、この違いこそが今回の核心だ。
11
24
AIが増やしたのは「候補」の処理量
監査は開発者のCalleと、AnchorWatchのCEOであるRob Hamiltonが主導した16人のチームによるもの。報道によれば、OpenSatsが拠出した4万ドル超のAI計算資源を使い、モデルがコード中の不審な経路や弱点となり得る箇所を探し、人間が調査の方向付けとメンテナー向け報告を担った。使用モデルとしてKimi K3、GPT Sol、Fable、Opus、GLM 5.2が挙げられている。
2
5
12
対象の広さも異例だった。約390リポジトリに加え、チームのレビュー用ハーネスは17万1,599行のコードをカバーしたとされる。高・重大に分類された報告は合計720件だった。
23
27
AIは大量のコードから危険なパターンを探し、データの流れをたどり、テストケースや悪用仮説を提示できる。つまり「調べるべき箇所」を量産するコストは大きく下がった。しかし、怪しい挙動を見つけたことだけでは、メンテナーが修正に着手できる品質のセキュリティ報告にはならない。
4,962件を「脆弱性の確定数」と読めない理由
この数字は、検証待ちの候補リストとして読むべきだ。初期報道では、独立して再現できたのは全件の21.4%にとどまった。実際のビルドや設定で問題が起きるのか、悪用可能か、既報との重複ではないか、深刻度は妥当か――そのすべてを人が確かめる必要がある。
11
15
通常、セキュリティ対応には次の工程が伴う。
- 実際のソフトウェア環境で挙動を再現する
- 誤検知や重複を除く
- 悪用可能性と利用者への影響を評価する
- メンテナーと非公開で開示・調整する
- 影響範囲を絞った修正とテストを書く
- 回帰がないかレビューする
- 運用者と利用者に更新を導入してもらう
AIによって最初の段階、つまり候補の発見は格段に安く速くなった。一方で、その後の専門的な検証と責任ある対応まで不要になったわけではない。実際、メンテナーに届いた報告は一部にとどまったとされ、開示対応そのものの処理能力も制約になっている。
14
Coldcardの事故が突きつけたもの
この監査の背景には、ハードウェアウォレット「Coldcard」を巡る事故がある。報道によると、2021年3月のファームウェアにあった不具合により、シード生成が本来意図されたハードウェア乱数生成器ではなく、予測可能なソフトウェア乱数生成器を経由した。必要な入力条件を十分に絞り込める攻撃者なら、影響を受けた鍵を再現できる可能性があった。
42
45
被害推定は調査の進展に伴って変動した。CoinDeskは4回の攻撃波を通じた累計が約1億1,400万ドルに近づく可能性を報じ、別の報道では7月30日から8月3日にかけて約1,816 BTCが盗まれたとされる。
41
42
ここで壊れたのはBitcoinの暗号技術そのものではない。自己保管を支える周辺ソフトウェアの欠陥が、大規模な被害につながり得ることを示した事例だ。悪用後に見つけるだけでなく、悪用前に危険な欠陥を特定して対処できるかが問われている。
マージされた修正は、報告件数とは別の重みを持つ
具体的な成果として、HamiltonによるAI支援のBitcoin Coreへの貢献が8月20日にマージされ、ウォレット関連のクラッシュ不具合に対応したと報じられた。
13
これは、AIが見つけた、またはAIを使って見つけた候補が、従来のレビューとマージの手順を通過した例として重要だ。同時に、4,962件という見出しの数字を「修正済み件数」と混同すべきでない理由でもある。マージ済みの修正には、明確に定義された不具合、レビューされたパッチ、保守されているコードベースでの受け入れという、はるかに高い基準がある。
OpenAIのアクセス制限が浮かび上がらせた防御側の課題
Hamiltonは、監査にOpenAIのサイバーセキュリティ機能を組み込み始めた後、同社のTrust Cyberプログラムによってアクセスを制限されたと述べた。報道によれば、チームはその後、オープンウェイトを含む別のモデルへ切り替えて作業を続けた。
18
21
32
強力なサイバー能力を持つモデルは、防御側による欠陥発見を助ける一方で、悪用されるおそれもある。Hamiltonは、身元が分かる防御側に摩擦が生じる一方、ローカルで動かせるモデルなどは攻撃側にも利用可能なままであれば、実務上の非対称性が生まれると批判した。ただしこれはアクセスと対応速度を巡る主張であり、特定の提供者がツールを制限すれば、セキュリティ研究や悪用を完全に止められることを示すものではない。
21
Boltzが示した、小規模チームへの運用負荷
BitcoinのスワップサービスBoltzは8月、AI支援の自動的な探索・試行が増え、小規模チームでは安全な修正と展開が追いつかないとして、スワップを無期限停止した。スワップを止める一方で、返金機能は利用可能な状態に保ったという。
28
29
30
これは、AIを使う攻撃がすべて高度で成功することの証明ではない。しかし、自動化された探索や試行は止まらずに続けられる一方、メンテナーは各アラートを調査し、安全な対策を一つずつ出荷しなければならない――Bitcoin Red Teamの監査が示した速度差を、実務面から示す例ではある。
高性能モデルが変えるリスクの計算
Bitcoin本体とその周辺サービスの多くはオープンソースだ。公開コードは透明性と第三者レビューを可能にするが、攻撃者と防御者が同じコードにアクセスできることも意味する。HamiltonやBitcoin評論家のCobraBitcoinが懸念するのは、オープンソース自体が危険だということではない。より高性能なモデルが、多数のリポジトリにまたがる珍しい欠陥を探すための時間と専門性を下げる可能性だ。
17
21
OpenAIは、GPT-6 Astraが同社のPreparedness Frameworkにおけるサイバーセキュリティ能力の「Critical」基準に達したとしている。同社によれば、適切なツールとアクセスがあれば、Astraは人が一手ごとに指示しなくても、多くの防御が施されたシステムで未知の欠陥を発見し、悪用方法を開発できるという。
19
22
この能力に関する説明は、AstraがBitcoin Red Teamの監査に使われたことも、最先端モデルがBitcoinの侵害を引き起こしたことも示していない。ただし、モデルがリポジトリ規模での推論や脆弱性開発に強くなるほど、重要な候補を迅速に証明し、修正し、更新を届ける能力が決定的になることを明確にしている。
必要なのは、検証を回すための投資
Bitcoin Red Teamの短期集中監査は、セキュリティ処理能力への警告として捉えるのが適切だ。現在のエコシステムは、もっともらしい候補を数千件、短時間で生み出せる。その安全性を左右するのは、独立した再現確認、セキュアな報告窓口、メンテナーの時間、コードレビュー、テスト、迅速な更新配布を同程度の速度で支えられるかどうかである。
Bitcoin関連プロジェクトの次の評価指標は、AIが抽出した件数の多さではない。報告のうち、攻撃者に先んじて、検証済みの脆弱性、責任ある形で調整された修正、そして実際に導入された保護策へと変わる割合だ。
15
14