QBT（Quantum Blockchain Technologies）は2026年10月29日、Bitcoin採掘向けのMethod A・B・Cが、それぞれライブ採掘環境で動いていると発表しました。結論から言えば、これは研究段階から実機・プールを使う比較試験へ進んだことを示す一方、採掘効率の向上、利益の増加、製品化を証明する発表ではありません。
今回確認できるのは、Method AがAntminer S9、Method BがBitaxe Gamma、Method Cが非公表メーカーのMDK（メーカー向け開発キット）で稼働しているという「試験の現在地」です。accepted shares、reject率、壁面消費電力、J/TH、稼働時間、採算の比較結果は公表されていません。この記事では、QBTの発表を追う投資家・マイニング関係者に向け、3方式の違いと試験条件を整理し、次の発表で何を見れば性能や商用化を慎重に判断できるかを初心者向けに解説します。
- 分かったこと：3方式は異なる機材・構成でライブ環境へ進んだ
- まだ分からないこと：同一条件での性能差、電力効率、収益差、第三者再現性
- 読み方の要点：「接続できた」「shareを出した」「ブロックを見つけた」「採算が改善した」を分ける
| 方式 | 試験機材・仕組み | 対照 | 現在地 | 未公表 |
|---|---|---|---|---|
| Method A | Antminer S9＋QBTサーバー | 無改変Braiins OSのS9 | 公開プールで比較中 | 実効速度・電力・採算 |
| Method B | Bitaxe Gamma、非機械学習方式 | 標準ESP-Miner機 | ライブ測定中 | 具体的処理・性能差 |
| Method C | 非公表メーカーのMDK＋AI Oracle | 公表なし | ライブジョブを処理 | ASIC仕様・比較結果 |
表のとおり、3方式は機材も対照条件も異なるため、現時点では方式間の順位を付けられません。
QBTが発表した「3方式のライブ稼働」とは
QBTの発表でいうライブ稼働は、保存済みの過去データだけを使う模擬試験ではなく、採掘機や開発キットを動かし、現行の採掘ジョブを扱う段階へ進んだことを指します。ただし、3方式は同じ機械、同じソフトウェア、同じ接続経路で横並びに試されているわけではありません。AはS9とQBTサーバー、Bはオープンソースの小型機Bitaxe Gamma、CはNDA先メーカーのMDKという別々の環境です。
Method A・B・Cがそれぞれライブ環境へ移行
Method Aは、ASIC（Bitcoin採掘に特化した集積回路）を搭載するS9を使い、学習済みモジュールをQBT側サーバーで動かし、API（ソフト同士の接続口）を介してAntminer S9へ処理を返す構成です。公開プールへ接続し、無改変のBraiins OSで動くS9を対照機として比較中です。Method Bは機械学習を用いないカオス数学型で、BM1370を搭載するBitaxe Gammaに実装され、標準ESP-Miner機と測定されています。Method CはAI Oracleを非公表メーカーのMDKに接続し、ライブジョブを処理しています。
2025年のライブ採掘主張との違い
QBTは2025年1月にもMethod Cについて、過去ブロックを用いる模擬試験から現行ブロックのプール採掘へ移行したと発表しています。したがって「ライブ」という言葉自体が2026年10月に初めて登場したわけではありません。今回の新規性は、Method CだけでなくA・Bを含む3方式へ範囲が広がり、S9、Bitaxe Gamma、メーカーMDKという具体的な実行環境と対照機が示された点にあります。
今回の発表でまだ示されていない成果
発表には、比較試験が完了したという記載も、優位性を判断できる測定表もありません。受理されたshareの数、拒否されたshareの割合、試験時間、実測ハッシュレート、コンセント側で測った消費電力、J/TH、プール手数料や通信費を含む収益差は不明です。顧客への販売開始、採掘事業者への導入、ライセンス契約も示されていません。
この段階を低く評価する必要はありませんが、到達点を正確に呼ぶことが重要です。「実機を使う比較試験の開始・進行」は確認できても、「性能向上の実証」「商用製品の完成」「顧客採用」は次の証拠を待つ段階です。
Method AはAntminer S9で比較試験中
まなぶ「クリプ先生、古いS9で動いたなら、新しいS21でも同じように使えるんですか？」
クリプ「まだ同じとは言えないよ。ASICの世代や制御基板、ファームが違うので、S9の結果と新しい機種への移植は分けて確かめる必要があるんだ。」
Method Aの試験は、同型のS9を使ってQBT版と無改変Braiins OS版を比べる設計です。対照機を置くことには意味があります。採掘成果は機器の個体差、温度、電源、クロック、プール側の条件にも左右されるため、基準となる通常運転機がなければ変化がMethod Aによるものか判断しにくいからです。
学習済みモジュールをサーバー側で動かす構成
発表によると、学習済みモジュールは採掘機の中ではなくQBTのサーバーで動き、採掘機とAPIで通信します。この構成なら採掘機の限られた計算資源へモデル全体を載せずに済み、サーバー側で更新しやすい可能性があります。一方で、採掘機単体で完結するファームウェアとは異なり、通信経路とサーバーの可用性が運転条件へ加わります。
評価時には、API往復にかかる時間、接続断からの復旧、サーバー停止時のフォールバック、外部へ送るデータの範囲、認証方法も確認対象です。計算上の改善があっても、ジョブ切り替えへの応答が遅れたり、停止時間が増えたりすれば、実際にプールへ受理される仕事量へ反映されない場合があります。
無改変Braiins OS機との比較で見るべき条件
「無改変Braiins OS」との比較は出発点ですが、公平な試験には詳細が必要です。両機のS9が同じASIC数と健康状態か、同じ電源・冷却・室温か、クロックと電圧が同じか、同一のBraiins OS版か、同じプール・ワーカー難度へ同時に接続したかをそろえます。片方だけを高い電圧で動かせばハッシュレートは増えても、電力効率や故障リスクが変わります。
比較結果を見るときは、瞬間的な管理画面の数値より、同じ時間窓で集計したaccepted sharesとreject率を重視します。採掘機が表示する理論的・短期的ハッシュレートと、プールが実際に観測する仕事量は一致しないことがあるためです。壁面電力も同時に測れば、速度だけでなくエネルギー効率を比較できます。
S19・S21対応表明と導入実績の差
QBTはアフターマーケットの制御基板とファームウェアを介し、Method AをS19・S21向けにも構成済みと説明しています。しかし「構成済み」は、すべての派生モデルと制御基板で長期運転が完了したことや、顧客設備へ導入されたことを意味しません。S19・S21には複数のモデル、ASIC構成、制御基板があり、導入手順も一様ではありません。
今後は、対応した正確な型番と基板、ファーム版、試験台数、連続稼働時間、障害時の挙動、実際の導入先が示されるかを確認します。S9で得た結果を世代の異なるS19・S21へそのまま一般化せず、機種別の測定を待つのが安全です。
Method BはBitaxe Gammaで標準機と測定中
Method Bは、QBTがカオス数学型と呼ぶ方式で、Bitaxe Gamma上の実装を標準ESP-Miner機と比較しています。Bitaxe Gammaは設計情報が公開された小型のBitcoin採掘機で、S21 Pro由来のBM1370 ASICを1個使います。公開された機材は構成を追いやすく、試験の説明や第三者による追試に向く一方、小型機での結果が大型の市販採掘機群へそのまま当てはまるとは限りません。
機械学習を使わないカオス数学型の位置づけ
Method Bは機械学習を使わない方式と説明されていますが、カオス数学をどの処理へどう使うかは、公表資料だけでは判断できません。確認できるのは方式の分類と試験環境までで、名称から性能を推測せず測定結果を待つ必要があります。
2026年7月の発表では、オフライン試験からBitaxe Gammaでのライブ試験へ進む段階でした。10月発表はライブ環境で標準機と測定中という進展を示しますが、優位性の確定ではありません。アルゴリズムの説明と、実運用で得られる成果を分けて読む必要があります。
Bitaxe GammaとBM1370を選んだ試験環境
Bitaxe Gammaはオープンソースで、ハードウェアと標準ファームの情報を確認しやすい点が比較試験に役立ちます。単一ASICなので大規模機より構成要素を絞りやすく、変更前後を観測しやすい試験台とも考えられます。ただし、冷却、電源品質、周波数、電圧によって動作は変わり、単一個体の差も無視できません。
結果を商用機へ広げるには、同じBM1370を多数搭載する機器での挙動や、別世代ASICでの再現性、制御基板との統合を確かめる工程が必要です。Bitaxeでの成功は重要な技術検証になり得ますが、それだけで大規模マイニング施設への導入準備が整ったとは判断できません。
ESP-Minerの版と設定を固定する必要性
ESP-Minerは更新が続くソフトウェアで、版ごとに修正、対応ASIC、チューニングが変わり得ます。QBT版と標準機を比較するなら、標準側の版番号を記録し、比較期間中に自動更新などで条件が変わらないようにします。プールURL、ワーカー設定、share難度、周波数、電圧、ファン制御も記録対象です。
理想的には複数台を無作為に割り当て、一定期間後に設定を入れ替えるクロスオーバー試験も考えられます。これは調査資料がQBTの実施を示したものではなく、個体差を減らす一般的な比較方法の例です。少なくとも、結果と一緒に版・設定・試験時間が開示されなければ、第三者が差の原因を検討しにくくなります。
Method Cは非公表メーカーのMDKで稼働
Method CはAI Oracleと呼ばれ、NDA先のASICメーカーが提供したMDK（開発キット）へ接続してライブ稼働しています。メーカー名、ASICの詳細仕様、測定結果は非公表です。MDKでの稼働はメーカー固有の環境へ近づいた進展ですが、一般に販売されている完成品の制御基板へソフトウェアが組み込まれ、顧客が使える状態になったこととは異なります。
有望と評価した採掘ジョブを実行するAI Oracle
まなぶ「クリプ先生、AI Oracleは答えのnonceを先に当ててくれるんですか？」
クリプ「有効なブロックを保証する仕組みではないよ。候補を評価して実行対象を絞る構想でも、最後はBitcoinの同じPoW条件を満たす必要があるんだ。」
QBTの説明では、AI Oracleは採掘ジョブを評価し、有望とみなしたハッシュ計算を実行する構想です。ただし、Bitcoin採掘の結果は確率的であり、「有望」という評価が必ず有効なshareやブロックにつながるわけではありません。どの入力をどう評価し、除外による見逃しと追加処理コストをどう管理するかが実効性を左右します。
性能評価では、モデルの予測指標だけでなく、最終的にプールが受理したshare、同じ電力で得た仕事量、長期の再現性を見る必要があります。学習データ上の精度が高くても、ライブジョブで入力分布が変わったり、評価処理が遅れたりすれば、採掘現場で同じ効果が出るとは限りません。
メーカー固有ASIC向けに必要だったモデル再構成
2026年8月の更新では、Bitaxe向けのモデルをメーカーASICへ単純に再学習するだけでは足りず、メーカー固有OSとローリング方式へ合わせて学習モデルを再構成したと説明されています。これはASICや制御方式が変われば、同じモデルをそのまま移せない可能性を示します。
機種別の再構成が必要なら、対応機種を増やすたびにデータ収集、学習、検証、統合の費用と時間がかかります。一方、固有環境へ合わせ込めることが確認できれば、技術の適応範囲を示す材料になります。現時点では一つの非公表環境での進捗であり、他メーカーや他世代への汎用性は未確認です。
MDK直結は試験短縮策であり製品統合ではない
QBTは2026年4月、制御基板への完全移植を先に行うのではなく、MDKへ直接接続する試験方式へ変更したと説明しました。これはモデルを実際のASICへ近い環境で早く試すための工程短縮策です。開発上は合理的でも、完成品に必要な配布、更新、安全な認証、障害復旧、監視、ユーザー設定などは別の課題として残ります。
したがって、MDKのライブ稼働は「ASICメーカーとの技術検証が前進した」と読めますが、「市販採掘機への完全統合が完了した」とは読めません。製品化の判断には、量産機上のファーム、長期安定性、メーカーまたは顧客の採用、保守体制まで見る必要があります。
A・Bのメーカー実機移植は今後の工程
10月29日の発表では、Method A・Bを同じ非公表メーカーの実機へ移植する作業は今後の工程です。現在のAはS9、BはBitaxe Gammaであり、CのMDKと同一条件で3方式を比べた結果ではありません。方式間の優劣を語るには、同じASIC、同じ電力・冷却、同じプール条件での横並び試験が望まれます。
将来、A・B・Cが同一メーカー機で動けば比較しやすくなりますが、稼働したという情報だけでは足りません。各方式の追加ハードウェア、サーバー依存、導入難度、保守費用も含め、現場にとっての総コストと効果を測る必要があります。
プール接続だけでは性能向上を証明できない
まなぶ「プールにつながって採掘中と表示されたら、Bitcoinのブロックを見つけたということですか？」
クリプ「そうとは限らないよ。プールは低い難度のshareで仕事量を測るけれど、Bitcoinネットワークのブロック条件はずっと厳しいんだ。」
Proof of Work（PoW）の「ライブ採掘」という表現を理解するには、プール接続、share提出、ブロック発見を分ける必要があります。採掘プールは多数の参加者から計算能力を集め、各参加者の貢献を測って報酬を分配します。その測定に使われるのが、通常はBitcoinネットワークのブロック条件より低い難度のshareです。
プールが低難度shareで仕事量を測る仕組み
採掘機はプールからジョブを受け取り、nonce（試行ごとに変える数値）などを変えながらブロックヘッダー候補を二重SHA-256で計算します。プールが設定したshare target（プールが定める目標値）を満たす結果が出ればshareとして送信します。プールは受理されたshareの量から、各ワーカーがどれだけ仕事をしたかを推定できます。
shareにはacceptedとrejectedがあります。acceptedはプールが条件を満たす有効な提出として受理したものです。rejectedはstale（期限切れの古いジョブ）、重複、不正な結果、通信遅延などの理由で受理されなかった提出を含み得ます。採掘機側の表示速度が高くてもreject率が増えれば、報酬計算に寄与する有効仕事量は期待ほど増えません。
接続成功とネットワーク難度のブロック発見は別
プールへログインし、ジョブを受け取り、shareを返せれば、採掘の通信経路が機能していることは確認できます。しかし、そのshareがBitcoinネットワーク全体のtargetも満たすとは限りません。まれにネットワークtargetを満たす結果が出たとき、プールはブロック候補をネットワークへ送れます。
したがって、接続成功はブロック獲得の証明ではありません。またブロックを一度見つけても、方式の優位性が確定するわけではありません。確率的なばらつきがあるため、十分な期間と仕事量を使い、対照群との統計的な比較が必要です。「ライブ」「share受理」「ブロック発見」「収益改善」は段階の違う主張です。
最適化後も変わらないBitcoinのPoW検証条件
Bitcoinで有効なPoWとなるには、80バイトのブロックヘッダーを二重SHA-256した値が、ネットワークのtarget（合格上限値）以下でなければなりません。採掘側が探索順序やジョブ評価を工夫しても、ネットワークのノードが検証するこの条件を変更することはできません。
これはQBTの方式が無意味だという話ではありません。既存の合意規則を変えずに、同じ時間や電力で有効な候補へ到達する確率または処理効率を改善できるかが検証テーマです。だからこそ、会社側の内部指標だけでなく、プールが観測するaccepted sharesと壁面電力が重要になります。
性能を判断するために不足しているデータ
現時点の資料で最も大きな空白は、方式ごとの比較結果です。発表は試験構成を説明していますが、結果表を示していません。将来の発表を評価する際は、一つの派手な改善率だけを見るのではなく、その分母、測定場所、試験期間、対照条件を確かめてください。
ハッシュレート以外に必要な測定指標
| 指標 | 分かること | 注意点 |
|---|---|---|
| accepted shares | プールが受理した実仕事量 | share難度と期間をそろえる |
| reject率 | 無効・遅延提出の割合 | 理由別の内訳も見る |
| 実効ハッシュレート | プール側推定の処理能力 | 短期値はばらつく |
| 壁面電力 | 設備が実際に消費する電力 | 電源損失も含める |
| J/TH | 計算能力当たりのエネルギー効率 | 同じ測定窓で比べる |
| 稼働率 | 停止や通信障害を含む可用性 | 長期試験が必要 |
ハッシュレートが増えても、消費電力がそれ以上に増えれば効率は悪化します。逆に電力を抑えて速度が少し下がっても、J/THや採算が改善する場合があります。サーバー型なら採掘機だけでなく、追加サーバーとネットワークの費用も評価対象です。
結果が出たら見る5項目：①accepted sharesとreject率、②壁面電力とJ/TH（1TH/s当たりの消費エネルギー）、③試験期間と台数、④同じ温度・電圧・クロック・ファームでの対照、⑤第三者再現性です。
比較条件と再現性
ASICは温度が上がるとエラーや冷却負荷が変わり、電圧とクロックの設定で速度・消費電力・安定性が変わります。比較する2台は、同じ室温と風量、同等の電源、同じクロック・電圧、同じファーム基準、同じプールへ接続する必要があります。個体差を考えるなら複数台を使います。
測定開始直後だけでなく、ウォームアップ後の定常状態を含めます。再起動回数、ASICエラー、温度、ファン速度、通信断も記録すれば、数値の改善が無理なオーバークロックや不安定化によるものではないかを検討できます。公開資料には、こうした条件と生データへの説明が必要です。
試験期間と第三者再現性
採掘は確率的なので、短い時間窓ではshareの数が期待値から上下します。プール全体がブロックを見つける頻度にも運の影響があります。これを一般にpool luckと呼びます。短期間にブロックが多かったことを、特定ワーカーの方式だけの効果と結び付けることはできません。
十分なshare数が集まる期間を設定し、複数回の反復と信頼区間を示すと結果を評価しやすくなります。さらに、QBTや提携メーカーとは独立した第三者が、公開された手順または監査可能な環境で再現できるかが重要です。現状の主要情報源は開発会社自身で、第三者再現試験は調査資料にありません。
採算比較
利益はハッシュレートだけで決まりません。受取報酬から、電力費、プール手数料、設備費、保守費、サーバー利用料、通信費などを差し引きます。半減期によるブロック報酬の変化に加え、Bitcoin価格とネットワーク難易度も変動するため、ある期間の収益を恒久的な結果として扱えません。
方式比較では、同じ価格・難易度の前提を置き、技術によって変わる部分と外部市場で変わる部分を分けます。Method Aに利用料やサーバー費が生じるならそれも含め、導入前後の純利益を示す必要があります。本稿はQBT株、Bitcoin、採掘機の売買を推奨するものではなく、技術発表を評価する材料を整理するものです。
商用化までに残る実装・事業上のハードル
技術が比較試験で改善を示しても、商用化には別の条件があります。多数機への展開、遠隔更新、セキュリティ、障害対応、料金体系、顧客サポート、メーカー保証との関係を整える必要があります。今回の発表はこれらの完了を示していません。
通信遅延・API障害・データ送信を伴うMethod A
Method AはQBTサーバーとのAPI接続を含むため、通信遅延と可用性が製品品質の一部になります。採掘ジョブは更新されるので、古い仕事への計算が増えるとstaleやrejectにつながり得ます。サーバーの地域、冗長化、停止時の通常採掘への切り替え、更新時の互換性が確認点です。
また、外部へ送る情報がジョブデータだけなのか、機器識別子、性能ログ、温度や設定も含むのかは運用者にとって重要です。データの暗号化、保存期間、アクセス権、顧客が接続を解除した際の扱いも契約と技術仕様で明らかにする必要があります。
ASIC世代と制御基板ごとに異なる互換性
同じAntminerブランドでも、モデルと派生型、制御基板、ファームウェア、ASIC世代は異なります。ある組み合わせで起動したことは、全機種で安全に使えることを保証しません。導入時には対応表、必要な基板交換、元へ戻す手順、保証への影響、更新失敗時の復旧方法が必要です。
大規模施設では数百・数千台を一度に変えるリスクを避け、小規模なカナリア導入から稼働率と電力を確認する方法があります。これはQBTの導入実績を示す記述ではなく、一般的な展開上の考え方です。QBTについては、実顧客の台数や運用期間が今後公表されるかを見ます。
NDA（秘密保持契約）が制限するMethod Cの外部検証
Method Cのメーカー名とASIC仕様はNDAにより非公表です。企業間の共同開発で秘密保持は珍しくありませんが、外部の読者は機材、条件、モデルの適合範囲を照合できません。機材提供と共同試験があることは、販売契約、独占契約、採用決定を意味しません。
秘密情報を保ったまま信頼性を高める方法として、独立監査者による測定、条件を匿名化した詳細な結果表、試験手順の事前登録などが考えられます。ただし、調査資料はそれらが実施済みとは示していません。開示できない事情と、性能が検証済みかどうかは分けて判断します。
次回発表で確認したい数値・導入実績・契約
- 方式ごとのaccepted shares、reject率、試験期間、share難度
- 壁面電力、実効ハッシュレート、J/TH、温度と設定
- 対照機の型番、ファーム版、台数、同時試験の条件
- 第三者による測定または再現試験の有無
- S19・S21の正確な対応型番と長期稼働実績
- Method Cの量産機統合と、A・Bのメーカー機移植の完了
- 顧客導入、ライセンス、販売契約と、単なるNDA・試験協力の区別
- サーバー費、手数料、電力費を含む純採算
資金面の補足：QBTは2026年9月に35万ポンドを調達し、試験・最適化などに充てると説明しました。開発継続の資金であり、商用収益の証拠ではありません。
まとめ：ライブ稼働は検証の入口、次は比較結果を確認
QBTの2026年10月29日発表は、Method A・B・Cがライブ環境へ進み、AとBでは標準構成の対照機を置いた測定が始まっていることを示します。AはS9と外部サーバー、BはBitaxe Gamma、Cは非公表メーカーのMDKで動くため、三方式の同条件比較が完了したわけではありません。
最も大切なのは、「プールへ接続できた」ことを「ブロックを獲得した」「効率が上がった」「利益が増えた」「製品が売れる」と読み替えないことです。次の発表ではaccepted shares、reject率、試験期間、壁面電力、J/TH、対照条件、第三者再現性を確認してください。数値が出た場合も、その数値がMethod A・B・Cの実測か、別のASIC UltraBoost特許の分析値かを区別する必要があります。
現段階の妥当な評価は「実機・開発キットを用いる検証が前進したが、性能と商用性は未確定」です。今後、同一ASICでの横並び試験、長期稼働、顧客導入、料金を含む採算がそろえば、研究成果から製品への距離をより具体的に判断できるでしょう。
