家庭用マイナーがハッシュしない？ 完全トラブルシューティング聖書（2026）

どの日でもいいので家庭用マイニングのコミュニティを覗いてみれば、必ず同じ投稿が見つかります。起動はするのに 0 GH/s から動かない Bitaxe、二分ごとに再起動する NerdQaxe、ファームウェア更新後にハッシュレートが半減した Gamma、そしてプール側が何も見ていないのに「ハッシュ中」と主張し続けるマシン。これらの機器はオープンソースのファームウェアを載せたオープンソースのハードウェアで、再生された産業用シリコンの上で動いています。この組み合わせは強力で安価であり、そして家電製品では決してあり得ないやり方で本当に繊細です。

本ガイドは、誰かのデバッグを手伝うたびに「こういう参考書があればいいのに」と思っていたものです。ほぼすべての「死んだ」あるいは挙動のおかしい個体を説明できる六つの故障領域を扱い、修理工房がやるようにログを読む方法を教え、症状のマスターテーブルと実際に遭遇するエラー行の辞書で締めくくります。対象は AxeOS 系統のすべて。あらゆる Bitaxe（Max、Ultra、Supra、Gamma、Gamma 601/602、GT、Hex）、++ と Hydro を含む NerdAxe および NerdQaxe 系列、NerdOctaxe、そして派生として ESP-Miner ベースのあらゆる機種、BM1373 時代のリファレンスで扱った新しい BM1373 機も含みます。

他のすべてに先立つ原則が一つあります。触る前に診断すること。本ガイドの手順の順序には理由があり、各ステップが原因の一クラスまるごとを除外していきます。本当の問題が電源の電圧降下であるときにいきなりファームウェアの再書き込みへ飛ぶと、一晩を無駄にしたうえ、問題が一つから二つに増えかねません。

時間がない？ 大半のケースを解決する五つの対処

他の何かを読む前に、この五つを順番に試してください。工具もログも筐体を開ける必要もなく、「マイナーが死んだ」という報告の大多数がこれで片付きます。

1. コールド電源サイクルを、正しく。
   電源コネクタそのものを抜く（壁のスイッチではなく）。
   きっちり 60 秒数える。挿し直す。
   理由：レギュレータの故障は「ラッチ」され、あらゆる
   ソフトウェア再起動を生き延びる。本当の切断だけが
   それを消せる。

2. 実際に何が給電しているのか確かめる。
   USB-C はダッシュボードを動かすが、ASIC には給電できない。
   USB-C だけのマイナーは永遠に 0 GH/s と約 2 W を表示する。
   本物の電源（DC ジャック / XT30）が挿さっていて奥まで
   入っていること、そして電圧が正しいこと（5 V と 12 V：
   間違えると基板が壊れる）を確認すること。

3. http:// を明示的に入力する。
   ブラウザは黙って https:// に切り替えて失敗する。
   http://マイナーのIP —— プレフィックス付きで、毎回。

4. 2.4 GHz を与える。
   これらの無線モジュールは 5 GHz を決して話さない。
   メッシュルーターでは 2.4 GHz 専用 SSID か IoT ネットワークを
   作り、WPA2-AES を使い、AP 分離をオフにすること。

5. マイナーではなく、プールに訊く。
   プール側ダッシュボードの「最後に受理されたシェアからの
   経過時間」が、オンラインかどうかの唯一誠実なテスト。
   10 分超 = 今この瞬間は死んでいる。マイナーの画面が
   何と言おうと関係ない。

解決した？ よし、タブを閉じてよい。解決しない？ 下の
トリアージが 60 秒であなたの章を見つける。

自分の問題を素早く見つける

二十の章は確かに多い。自分の章へ飛ぶ方法が三つあります。

検索で：本ガイドのエラー文字列はすべて、ファームウェアが出力するとおりに一字一句そのまま書かれています。Ctrl+F（Mac なら Cmd+F）を押してエラーメッセージを貼り付ければ、その上に着地します。これは運ではなく設計上の判断です。

症状で：

読み方のスタイルで：次の章で、本ガイドを初心者向けの道筋とプロ向けの道筋に分けます。

自分の道筋を選ぶ

本ガイドは非常に異なる二種類の読者に向けて書かれており、同じ読み方をすべきではありません。

初めてのマイナー、初めてのトラブル？番号付きの道筋を、何も飛ばさずにたどってください。二つの安全ルール、内蔵セルフテスト、60 秒トリアージ、そしてトリアージが送り出した先の章だけ。コードブロックはすべてそのままコピーして使えますし、知らないかもしれない用語はすぐ下のミニ用語集にあります。初心者向けの道筋には、筐体を開けたりテスターを持っていたりする必要のある内容は一つもありません。

ターミナルとテスターに慣れている？あなたの追い越し車線はこちら。ログをリモートで取得し複数台をまとめて点検する API の章、エラー文字列から原因へ直接飛ぶための赤いエラー行の辞書、機種別の癖の表、そして最後にある専門的な作業台の章。回路図、測定ポイントの手法、基板レベルのリソースはそこにあります。PRO と記された章は、回路図が読めて通電状態の基板を安全にプローブできることを前提としています。

始めたばかりの人向けミニ用語集

十個の用語、それぞれ十秒。これで本ガイドの残りが二倍の速さで読めるようになります。

ASIC        マイニングチップそのもの ——
            実際にハッシュを計算する唯一の部品
ESP32       それ以外のすべてを担当する小さなコントローラ：
            WiFi、ダッシュボード、ASIC との通信
AxeOS       ESP32 上のファームウェア + ウェブ画面
VCORE       ASIC コアへの約 1.0-1.3 V の給電 ——
            入力の 5 V または 12 V から基板上で作られる
VRM / TPS546  VCORE を作り出し、故障時に自らシャットダウン
            することでチップを守るレギュレータ回路
stratum     マイナーがプールと会話するためのプロトコル
シェア      提出する作業の証明。プールはこれを数えて
            あなたが生きていることを知る
HW エラー率 チップが「間違って」計算した結果の割合 ——
            最も誠実な健康指標（2% 未満を保つこと）
OTA         ダッシュボード経由の「無線」更新。
            USB 経由の書き込みと対になる概念
NVS         再書き込みを生き延びる設定領域 ——
            工場出荷時リセットが存在する理由

何よりも先に：二つの安全ルールと内蔵ツール

基板を死なせないための二つのルール

ルール一：電圧を絶対に推測しない。標準的なシングルチップの Bitaxe は 5 V、GT・Hex・NerdQaxe++・NerdOctaxe は 12 V です。両系統の DC ジャックは物理的に差し替えできてしまい、12 V の電源を 5 V の基板に繋ぐと一秒足らずで永久に破壊されます。接続のたびにコネクタの形状ではなく電源のラベルを読んでください。これはこの趣味における最も高くつく単一のミスです。

ルール二：コネクタが熱い＝中止。ぬるい程度なら警告ですが、熱い・変色している・プラスチックの匂いがする場合は、ただちに電源を切り、次に通電する前にケーブルを交換してください。本ガイドの他のすべては明日まで待てます。これだけは待てません。

内蔵セルフテストを実行する

AxeOS には、大半の所有者がその存在すら知らない電源投入時セルフテストが搭載されています。五つのサブシステムを順に検査し、最初に失敗した項目を画面に表示します。つまり、故障している領域の名前を教えてくれる無料の三十秒ハードウェア診断です。

検査対象（順番）              失敗時に画面が表示するもの
  入力レール                    POWER FAIL
  コア電圧レギュレータ          VCORE FAIL
  I2C センサーバス              （テスト中に固まる）
  ファン回転数のフィードバック  FAN FAIL
  ASIC の検出                   ASIC FAIL
  短時間のハッシュバースト      HASHRATE FAIL

結果の読み方
  POWER / VCORE FAIL   -> 電源の問題の章へ。このテストは
                          定格から 10% 以上ずれた入力を
                          拒否する —— 電源を測ること。
  ASIC FAIL            -> ASIC の問題の章へ。
  FAN FAIL             -> ファン未接続、固着、または
                          回転数信号線の断線。
  HASHRATE FAIL        -> チップは検出されたが計算していない：
                          たいてい電源がぎりぎりか設定の問題。
                          工場出荷値に戻すこと。

セルフテスト自体が固まる場合
  画面が SELF TEST で 30 秒以上止まる、あるいは SELF TEST ->
  再起動の無限ループになる場合：AxeOS v2.12 以降では
  SELF TEST 画面の間に BOOT ボタンを 2 秒長押しすると
  スキップしてダッシュボードに入れる。そこから診断すること。
  書き込み後のセルフテストループは、たいてい基板に対して
  誤ったイメージを書いたことを意味する。

セルフテストは初回起動時に自動で走り、設定画面から手動でも起動できます。ハードウェアに何かあったあとは必ず実行してください。輸送のあと、ヒートシンクの取り付け直しのあと、電源の交換のあと。ログを一つも開かないうちに、「何かがおかしい」を名前のあるサブシステムへと変えてくれます。

画面が伝えていること

ディスプレイ搭載機では、OLED は装飾ではなく状態表示計器です。数秒ごとに情報画面を切り替えており、BOOT ボタンで手動送りができ、タイマーで消えた画面を復帰させることもできます。覚えておくべき状態は、起動画面（ファームウェアは生きている）、設定用ホットスポット画面（未設定または WiFi 認証情報の消失）、IP アドレス画面（ダッシュボードへの入口）、上記のセルフテストと FAIL コード、過熱警告、そしていつか出会えることを願うブロック発見のアニメーションです。画面が暗いことは基板が死んだ証拠にはなりません。単に画面消灯タイマーが働いただけではないか、プールにシェアが届き続けていないかを確認してください。

60 秒トリアージ

ログを一つも開かないうちに、五つの質問に答えてください。これで問題空間全体が分割されます。

Q1  何かに通電しているか？（LED、画面、ファン）
      いいえ -> 電源領域。移動先：電源の問題。
      はい   -> Q2

Q2  AxeOS のダッシュボードに到達するか、IP を表示するか？
      いいえ -> Q2a：設定用ホットスポットを出しているか？
                はい   -> WiFi 領域。移動先：ネットワーク。
                いいえ -> 起動領域。移動先：ファームウェア。
      はい   -> Q3

Q3  ダッシュボードのハッシュレートはゼロより上か？
      いいえ -> Q3a：電源故障、過熱バナー、または ASIC
                チップ 0 のいずれかが出ているか？
                電源故障 -> 電源の問題
                過熱     -> 熱の問題
                0 チップ -> ASIC の問題
      はい   -> Q4

Q4  プールは直近 10 分以内に受理シェアを示しているか？
      いいえ -> STRATUM 領域。移動先：プールの問題。
      はい   -> Q5

Q5  ハッシュレート、エラー率、温度はあるべき値か？
      いいえ -> 熱の問題、またはオーバークロックの失敗。
      はい   -> 何も壊れていない。タブを閉じてよい。

Q4 が訊いているのは機器ではなくプールであることに注目してください。家庭用マイニングで最もよくある徒労は、画面上は完璧に見えるのにプールが一時間その声を聞いていないマイナーをデバッグすることです。機器とプールはそれぞれ絵の半分ずつしか見ておらず、本ガイドは何度もこの非対称性に立ち返ります。

ログの読み方

ログが読めれば本ガイドの他のすべてが速くなるので、この章を先頭に置いています。ログの窓口は二つあり、それぞれ別の問いに答えます。

AxeOS のウェブログ

マイナーの IP アドレスでダッシュボードを開き、ログ表示を探してください。実行時のログをリアルタイムで表示します。stratum のやり取り、シェアの提出、難易度の変更、温度イベントなど。機器が正常に起動していて「今それが何をしているのか」が問いであるときに正しい道具です。限界は二つ。ネットワークが立ち上がったあとに始まるので起動時の失敗を見せられないこと、そしてウェブサーバーと一緒に死ぬのでクラッシュを見せられないことです。

シリアルコンソール：真実

起動、クラッシュ、ASIC の検出、WiFi 接続に関わることなら、必要なのはシリアルコンソールです。これは開発者が読んでいるものと同じ出力で、いちばん最初の命令から始まります。

1. USB-C データケーブル（充電専用ではないもの）でマイナーと
   パソコンを繋ぐ。一部の Bitaxe 基板ではネイティブの
   USB-C 対 USB-C 接続がネゴシエーションに失敗する。
   その場合は USB-A から USB-C のケーブルまたは変換を使う。
   これは従来の 5V を強制する。

2. 115200 ボー、8N1 のシリアルターミナルを開く：

   Windows:  PuTTY -> Serial -> COMx -> 115200
   Linux:    sudo minicom -D /dev/ttyACM0 -b 115200
             （または：screen /dev/ttyACM0 115200）
   macOS:    screen /dev/tty.usbmodem* 115200

3. 基板上の RST ボタンを押す（または電源を挿し直す）。
   起動ログ全体が最初から流れる。

ESP-IDF のログ行には重要度を表す文字が付きます。I は情報、W は警告、E はエラーです。ほとんどのターミナルは E 行を赤で表示します。健全な起動では E 行はゼロです。ログ読解の技術はこの一文に凝縮されます。起動をスクロールして最初の E を見つけ、本ガイド末尾の辞書で引くこと。重要なのは最初のエラーです。後続のエラーはたいてい最初のエラーによる連鎖的な被害だからです。

健全な起動はこう見える

注釈付き・短縮版です。あなたのものは細部で異なりますが、同じ順序で同じ節目を通過しなければなりません。

rst:0x1 (POWERON_RESET), boot:0x8 (SPI_FAST_FLASH_BOOT)
        <- リセット理由。POWERON は正常。ここで RTC_WDT や
           BROWNOUT のリセットが繰り返されていたら、それが
           最初の警報。

I (xx) main: Found device config: <あなたの基板の型番>
        <- ファームウェアが基板を識別した。ここで型番が
           違っていたら、書き込んだイメージが違う。

I (xx) TPS546: Found TPS546D24A          （TPS 搭載基板）
I (xx) Power: VCORE set to 1150 mV
        <- コアレギュレータが I2C で応答し、ASIC のレールが
           立ち上がった。このブロックが無い、またはエラーを
           出す場合、それ以降は何も機能し得ない。

I (xx) bm13xx: Found 1 chip(s)
        <- 決定的な一行。この数はあなたの基板のチップ数と
           一致しなければならない：シングルチップなら 1、
           GT は 2、NerdQaxe は 4、Hex は 6、NerdOctaxe は 8。

I (xx) wifi: connected, IP: 192.168.x.x
        <- ネットワーク確立。接続の失敗はここに理由コードを
           出力する（辞書は後述）。

I (xx) stratum_task: Connected to pool ...
I (xx) stratum_task: mining.subscribe / authorize OK
I (xx) stratum_task: Set difficulty to ...
I (xx) create_jobs_task: New Work: ...
        <- プールがログインを受理し、仕事を送ってきた。

I (xx) asic_result: Nonce found, diff xxx of yyy
        <- ASIC が結果を返している。一、二分以内にプールの
           難易度を超えるシェアが提出され受理されるのが
           見えるはず。

節目の順序を覚えてください。リセット理由 → 基板設定 → レギュレータ → チップ数 → WiFi → stratum → nonce。最初に失敗した節目が、あなたに必要な章の名前です。

電源の問題：あらゆる不具合の第一原因

家庭用マイナーの故障にランキングがあったなら、電源が上位三つを独占するでしょう。これらの基板は民生用の電源から民生用のコネクタを通して、3 nm や 5 nm のシリコンを高電流で駆動しており、余裕はごくわずかです。

自分の給電アーキテクチャを知る

シングルチップ Bitaxe（Max/Ultra/Supra/Gamma）
  入力：      5 V、DC ジャック（5.5x2.1mm）または USB-C
  電流：      Gamma の初期状態で最大約 5 A、OC 時はさらに
  レギュレータ：TPS546D24A デジタル降圧（旧基板は DS4432U
              DAC + INA260 モニタ）。5V を非常に大きな電流で
              約 1.1-1.3V の ASIC コア電圧まで下げる
  動作窓：    レギュレータは約 4.8 V で起動し、約 4.5 V を
              下回ると停止する

12 V 系（GT、Hex、NerdQaxe++、NerdOctaxe）
  入力：      12 V、XT30 コネクタまたは DC ジャック
  電流：      NerdQaxe++ は全負荷で約 8+ A、Octaxe はさらに上
  リスク：    コネクタの発熱、負荷時の電圧降下

重要な事実：現行の Bitaxe 基板の USB-C は ESP32 と書き込み
専用である。ASIC には給電できない。USB-C だけで動く基板は
起動し、ダッシュボードを表示し、消費電力約 2 W でちょうど
0 GH/s のハッシュレートになる。これは壊れたレギュレータを
正確に模倣するため、コミュニティ全体で毎週何時間もの時間を
浪費させている。

Power Fault Detected：実際に起きたこと

TPS546 レギュレータは四つの保護を監視しています。過電流、過電圧、低電圧、過温度です。いずれかが作動すると、レギュレータはシャットダウン状態をラッチし、AxeOS が電源故障のバナーを表示します。ASIC はレールを失いますが、別系統で給電されている ESP32 が画面を生かし続けます。解決策を左右する事実が二つあります。

• ラッチはソフトウェア再起動を生き延びます。故障状態はレギュレータ自身のステータスレジスタに、入力電圧が物理的に取り除かれるまで保持されます。ウェブ画面からの再起動、restart API の呼び出し、ESP32 のリセットボタンのいずれもこれを消しません。これはバグではなく文書化された挙動であり、GitHub に一つのクラスをなす issue 群が存在する理由でもあります。5 W を消費しながら 0 GH/s で固まった BM1370 基板で、restart エンドポイントは何も直さないのに、電源の抜き差し一回ですべてが直るというものです。
• 作動は症状であって、原因は上流にあります。レギュレータが守っているのは、その周りの基板全体より高価なチップです。繰り返し作動するケースの圧倒的多数は、レギュレータではなく入力電源に遡ります。

解決の手順を順番に：

1. コールドサイクル。電源コネクタそのものを抜く（壁の
   スイッチではなく）。きっちり 10 秒数える。一部の基板は
   バルクコンデンサが放電し、ESP32 のブラウンアウト保持
   状態が消えるまで 60 秒必要。挿し直す。これだけで
   単発の故障の大半は解決する。

2. USB-C を外す。USB-C ポートに何か挿さっているなら外し、
   本物の電源（DC ジャック / XT30）が挿さっていることを
   確認する。上で説明した USB-C の罠を排除すること。

3. 負荷をかけて測定する。テスターを直流に合わせ、
   マイナーがハッシュしている最中に入力コネクタで測る：
     5 V 基板：  4.9-5.3 V が維持されているはず。
                 4.8 V を下回る = 電源が原因。
     12 V 基板： 11.8-12.2 V が維持されているはず。
                 11.4 V を下回る = 電源が原因。
   無負荷での測定は何も証明しない。粗悪な電源は無負荷では
   完璧な 5.0 V を表示し、負荷がかかると 4.4 V まで落ちる。

4. 経路を除外する。電源を壁のコンセントに直接挿す。
   電源タップも延長コードも数珠つなぎもなし。品質の低い
   タップは測定可能な電圧降下を生む。DC ジャックを揺すって
   みる：画面がちらつくなら、ジャックかケーブルが摩耗している。

5. 電源を格上げする。誠実な最低仕様：
     5 V シングルチップ基板： 良質な 5 V / 5 A 専用電源
     NerdQaxe++ 級の 12 V：   12 V / 10 A（120 W）以上
   スマートフォンの充電器と汎用アダプタは、本ガイド全体で
   最も多い根本原因である。

XT30 についての警告

12 V 系は 8 アンペア以上を一つの XT30 に流します。コネクタ自体はその定格で作られていますが、その裏で手作業ではんだ付けされたリード線はそうでないことが多々あります。ピンの変色、触ってぬるいコネクタ、はんだ不良、緩んだ圧着を点検してください。8 A における高抵抗の接合部は発熱し、酸化し、抵抗がさらに上がり、さらに発熱します。家庭用マイニングにおいて、プラスチックが溶けて終わる唯一の故障モードがこれです。コネクタが一度でも変色するほど熱くなったことがあるなら、ケーブルを交換してください。使い回さないでください。電源エラーと Guru Meditation コードを出してクラッシュする NerdQaxe は、まさにこの負荷時に落ちるレールに遡ります。

ブラウンアウト：クラッシュではないクラッシュ

ESP32 にはハードウェアのブラウンアウト検出器があります。3.3 V レールが落ちると Brownout detector was triggered を出力して再起動します。数分おきに再起動するマイナー、とくに ASIC が全負荷まで立ち上がるときに再起動するものは、ほぼ間違いなくファームウェアの問題ではありません。ピーク消費の瞬間に給電が落ちているのです。解決策は上の手順 3 から 5 です。ブラウンアウトのループでファームウェアを追いかけないでください。

ASIC の問題：チップが応答しない

起動ログで見るべき行はチップ数です。ファームウェアは UART 経由で ASIC チェーンを列挙し、何個のチップが応答したかを出力します。あなたの基板の完全な数以外はすべてこの章の話です。

チップがゼロ個検出された

ダッシュボードの ASIC 数が 0 になる、またはログに初期化失敗が出ます。観測される頻度の順に原因を挙げます。

1. ラッチしたレギュレータ、または保持されたブラウンアウト状態。コア電圧のないチップは列挙されません。他の何よりも先に、60 秒のフルコールド放電を行ってください。メイン電源、USB-C、あらゆる付属品を外し、まるまる一分待ち、再通電します。これだけで無視できない割合のケースが解決します。
2. 誤ったファームウェアイメージ。他の基板のイメージを一度でも書き込むと、不揮発性メモリに誤ったデバイス設定が残り、その後の再書き込みを生き延びることがあります。起動ログの型番行が実際の基板と一致しない場合は、完全な工場出荷時リセットを行ってから正しいイメージを書き込んでください。BM1370 基板に BM1366 のイメージを入れても、チップは永遠に見つかりません。
3. 物理的な事象。典型的な時系列はこうです。移動した、落とした、発送した、あるいはヒートシンクを締め直した。そして二度とハッシュしなくなった。ASIC の下には BGA のはんだボール配列があり、たわみがそれを割ります。ヒートシンクの取り付け圧が不均一でも同じことが起きます。時系列が合うなら、これは設定の問題ではなく作業台での修理（リフロー）です。
4. 初期不良。一度もハッシュしたことのない新品は、製造時のはんだ不良である確率が不釣り合いに高いです。週末をソフトウェアに費やさないでください。コールド放電とファームウェアの確認だけ済ませたら、保証を使ってください。

チップ数が足りない：マルチチップ特有の兆候

Hex が 6 個中 3 個、NerdQaxe が 4 個中 2 個、GT が 2 個中 1 個と報告する場合です。マルチチップ基板は ASIC をチェーンとして列挙するため、死んだあるいは切れたチップが一つあると、チェーンのその地点で検出が途切れます。つまりその数字が、断線のおおよその位置を教えてくれます。4 チップ基板が 2 と表示するなら、問題は 3 個目のチップにあります。原因は上と同じ（電源の余裕、割れたはんだ）に加えて、マルチチップ特有のものが一つ。チェーン内の弱いチップが、高い周波数でだけ脱落するというものです。工場出荷時の周波数では完全な数に戻るのにオーバークロックするとチップが消える場合、あなたはシリコンくじで引いた最も弱いダイを見つけたのであり、その上限が基板全体の上限になります。

I2C エラー：マイナーではなくセンサーバス

紛らわしい部類の症状があります。マイナーは正常にハッシュしているのに、Power、ASIC Temp、Input Voltage がダッシュやヌルやゼロで表示され、ログには I2C の送受信エラーやタイムアウトが出るというものです。ハッシュ経路（ASIC への UART）とテレメトリ経路（レギュレータの PMBus、温度センサー、電流モニタへの I2C）は別のバスです。片方が落ちてももう片方は動き続けます。既知の引き金は、AxeOS v2.13/v2.14 付近のファームウェア退行帯で、一部の個体でセンサー読み取り経路が静かに失敗するというもの。I2C コネクタを共有するあらゆる付属品も原因になります。後付けの OLED や接触の悪い外部センサーが、基板上のセンサーごとバスを塞いでしまうことがあるのです。機器を出荷時の構成に戻し、コールドサイクルを行い、ファームウェア退行帯が原因なら前進するか一バージョン戻ってください。

危険な副作用があります。温度のフィードバックがないとファンカーブが機能せず、ファンは一つの回転数で固定されます。テレメトリが死んでいるなら熱保護も死んでいるものとして扱い、修理が済むまで無人で運転しないでください。

熱の問題：熱はイベントではなく予算である

意味のある数値

ASIC コア温度   目標：      55-62 C を維持
                懸念：      65 C 超が常態化
                停止：      約 75 C -> Overheat モード

VREG 温度       負荷時はコアより 10-15 C 高く動作する。
                BM1370/BM1373 基板では、コアではなく
                こちらが制限側のセンサーであることが多い

Overheat モード ハッシュが停止し、ファンは 100%、画面は
                生きたまま。温度が約 65 C まで下がると
                ヒステリシス付きで解除される

パターンによる診断

冷えた状態から即座に過熱する —— 取り付けの問題です。ヒートシンクが接触していません。サーマルパッドの欠落や破れ、乾いたあるいは塗られていないグリス、締め付けトルクの不均一、輸送中に緩んだヒートシンクなど。接触のないチップは室温から停止温度まで数秒で到達します。取り付け直し、良質なグリスを米粒一つ分塗り、ネジを対角に均等に締めてください。

10 分から 30 分後に過熱する —— 放熱能力の問題です。接触は良好ですが、発生する熱を捨てる速度が追いついていません。原因は積み重なります。室温が約 27 C を超えている、キャビネットや引き出しや密閉ケースに入っている、吸気か排気が塞がっている、フィンにほこりのフェルトが乗っている、あるいは冷却系が想定していないオーバークロックをしている。両側に 10 cm の空間を確保し、フィンを清掃してください。周波数を変えた直後に始まったなら、その変更が行きすぎだったということです。

数週間かけてゆっくり上昇する —— 保守の問題です。設定は同じなのに温度が一度ずつ這い上がるなら、ほこりの堆積かサーマルグリスの乾燥です。これらの基板ではグリスは消耗品であり、6 か月から 12 か月ごとに塗り直すのが普通です。

ファームウェア更新後の過熱 —— カーブの問題です。ファンと熱のカーブはバージョン間で変わります。v2.11 付近の文書化された例では、既定の挙動が動いた結果、工場出荷時設定のまま数度高温かつわずかに低速で動作するようになりました。リリースノートを読み、ファン回転数を手動で一段上げるか、ファームウェアが PID 制御を公開しているなら目標温度を調整してください。

ファンそのもの

どんな温度でも 0 RPM を報告するファンは、繋がっていないか、ケーブルで固着しているか、壊れています。常時 100% で唸り続けるファンは、本当にチップが熱いか（上記参照）、温度テレメトリが死んでいてカーブが手探りで制御しているか（I2C の章参照）のどちらかです。40 mm と 60 mm の交換ファンは安価で、高品質な静音モデル（コミュニティの定番は Noctua）は騒音を 40 dB 未満まで下げます。これらの機器において最もコストパフォーマンスの高いハードウェア改善です。

ネットワークの問題：ESP32 から見た WiFi の世界

これらのマシンに載っている無線モジュールは2.4 GHz しか話しません。5 GHz でも 6 GHz でもなく、例外もなく、ファームウェアで直す手段もありません。導入失敗の非常に大きな割合が、この一文と現代のルーターの挙動との衝突に帰着します。

メッシュルーターの問題

現代のメッシュ機器は単一の統合 SSID を出し、クライアントをバンド間で誘導します。ESP32 は 5 GHz 側に参加できず、バンドステアリングは 2.4 GHz に落ち着くことを妨げ得ます。確実な対処法は次のとおりで、ほとんどのルーターは少なくとも一つに対応しています。

方法 A  2.4 GHz 専用の SSID を作る（最良）
方法 B  ルーターの「IoT ネットワーク」機能を使う ——
        複数のメーカーがまさにこういう機器のために
        搭載している
方法 C  バンドステアリング /「smart connect」を無効化し、
        バンドを別々の SSID として見せる

そのうえで 2.4 GHz の SSID 側を確認：
  暗号化       WPA2-Personal、AES のみ（TKIP は不可。
               WPA3 のみのネットワークは失敗する）
  チャンネル   混雑した環境では 1、6、11 に固定。Auto は不可
  チャンネル幅 20 MHz
  AP 分離      無効 <- 有効だと WiFi は繋がるのに
               ダッシュボードが LAN から到達できず、
               機器が死んでいるのと全く同じに見える
  MAC フィルタ 無効、またはマイナーの MAC を登録する

シリアルログで WiFi の失敗を読む

シリアルコンソールは接続に失敗するたびに切断理由を出力し、その理由が解決策の名前になっています。

AUTH_EXPIRE / auth failed      パスワード（PSK）が違う。
                               打ち直すこと。スマートフォンから
                               コピーした場合は組版用の引用符に
                               注意。
NO_AP_FOUND                    SSID が 2.4 GHz で見えていない：
                               バンドステアリング、SSID ステルス、
                               電波範囲外、または 5 GHz のみ。
beacon timeout                 信号が弱すぎるかチャンネルが混雑。
                               機器を移動するかチャンネルを固定。
ASSOC_TOOMANY                  ルーターのクライアント数上限に到達。
Brownout detector triggered    これは WiFi の問題ではまったくない：
                               接続時の無線モジュールの消費電流
                               ピークが弱い電源を落としている。
                               直すべきは電源であって、ネットワーク
                               ではない。

最後の項目は強調しておく価値があります。WiFi の送信は ESP32 が生み出す最大の瞬時負荷ピークです。アイドル状態なら耐えられるぎりぎりの電源が、接続の瞬間に死ぬ。つまり「WiFi 接続時にクラッシュする」個体は、たいていネットワークの装いをした電源の問題なのです。

WiFi のエラーがないのに到達できない

ルーターの二つのセキュリティ機能は特筆に値します。設計上マイナーを遮断するからです。ASUS の AiProtection と一部 TP-Link 機種の同等機能は、stratum のトラフィックを疑わしいと判定して黙って破棄します。マイナーは完璧に WiFi に参加し、そのあとどのプールにも到達できません。WiFi には繋がるのにプール接続がすべて失敗し、同じプールがスマートフォンのテザリングでは動く場合は、他の何かを触る前にルーターの当該保護機能を無効にするか、マイナーをホワイトリストに入れてください。

そして無限に誤報を生むブラウザの癖が一つ。AxeOS はポート 80 でプレーンな HTTP を提供します。現代のブラウザは裸のアドレスを黙って HTTPS に変換し、それが失敗し、マイナーが死んでいるように見えます。プレフィックスを明示的に入力してください。IP の前に http:// を、毎回。それでも失敗するなら別のブラウザを試し、ローカルアドレスに対して広告ブロッカーを無効にしてください。

マイナーに IP はあるのにダッシュボードが開けない場合は、AP 分離（上記）、ルーターのクライアント一覧の癖、あるいは mDNS です。機器は .local のホスト名で自身を告知します。複数の個体が同じホスト名を使うと、現代のファームウェアは MAC 由来のサフィックスを自動で付けますが、パソコン側の古い mDNS キャッシュが誤った個体を指し続けることがあります。迷ったらルーターの DHCP テーブルから生の IP を使い、各個体に別々のホスト名を与えてください。

Stratum とプールの問題：ラストワンマイル

機器は起動し、ハッシュしており、そして真実が決まる場所はプールです。この章では、マイナー側の視点とプール側の視点を合わせて読む必要があります。

接続拒否または到達不能

この順で確認する：
1. URL の正確さ： stratum+tcp://ホスト:ポート ——
                 https:// は不可、末尾のスラッシュも不可、
                 ポートは必須かつ正確に
2. DNS：         同じ LAN の別の機器はそのホストを解決できるか？
                 一部の ISP ルーターや DNS フィルタ（Pi-hole の
                 ようなブロッカーを含む）はマイニング関連の
                 ドメインを黙って飲み込む。
3. ポート：      一部のネットワークは珍しい送信ポートを塞ぐ。
                 スマートフォンのテザリングで試す：そちらで
                 繋がるなら自宅ネットワークが遮断している。
4. リージョン：  プールの別のリージョンのエンドポイントを試す。
                 単一リージョンの障害を見ているだけかもしれない。

authorize が失敗する

プールがログインを拒否しました。ソロプールではユーザー名はウォレットアドレスとワーカー名の組み合わせであり、アドレスがアイデンティティのすべてです。打ち間違える「アカウント」というものが存在しません。原因としては、アドレスの打ち間違い（一文字で十分です）、誤ったチェーンのアドレス（後述）、空白や特殊文字を含むワーカー名、あるいはプールが空でないことを期待しているパスワード欄（x を入れてください）などがあります。

誤ったチェーンのアドレス：静かな殺し屋

マルチチェーンの SHA-256 マイニングにおいて最も害の大きい設定ミスであり、二通りの失敗の仕方があります。

• 騒がしい失敗：プールがチェーンごとにアドレス形式を検証し、authorize またはすべてのシェアを拒否します。腹立たしいですが安全です。数分で気づけます。
• 静かな失敗：複数のチェーンで形式上有効なアドレス、あるいは深く検証しないプールが、一日中あなたのシェアを受理し続け、そして支払いがあなたに届きません。ノンカストディアルのソロプールでは、ブロック報酬はあなたが設定したアドレス文字列へコインベースで直接支払われます。使えないアドレスに支払われたコインベースを取り消せるサポート窓口は存在しません。

ルールはこうです。アドレスは、あなたが向けているチェーンのネイティブなものでなければなりません。そのチェーンのウォレットで生成し、検証したものを使ってください。同じ物理マイナーをチェーン間で使い回すなら、「チェーン → アドレス」の対応表を書き残し、stratum の URL を変えるたびに毎回ユーザー名欄を確認してください。これは本章の他のすべての助言を足したものより価値があります。

拒否されたシェア：拒否理由を読む

拒否は一つの問題ではありません。ログの理由文字列が、四つのうちどの問題なのかを教えてくれます。

"job not found" / stale       プールがすでに差し替えたジョブに
  新しいブロックの直後に      対して作業を提出した：ブロックの
  小さなかたまりで出る        切り替わり時には正常。全体の
                              ~1-2% 未満なら無視してよい。
                              継続的にそれ以上なら、ネットワーク
                              遅延か WiFi のパケットロス。RSSI を
                              確認し、より近いプールリージョンを
                              試すこと。

"above target" /              シェアがプールの割り当てた難易度に
"low difficulty share"        届いていない。継続する場合：難易度
                              変更後のずれ、または結果を壊している
                              ハードウェアエラー。HW エラー率を
                              確認すること。

"duplicate"                   同じ nonce が二度提出された。
                              たまに出るなら無害な再送の産物。
                              連続して出るなら既知の故障状態で、
                              ASIC が一つの nonce でループしている。
                              チップが引っかかっている。電源を
                              入れ直し、現在の周波数で再発するなら
                              オーバークロックを下げること。

すべて拒否される              運の悪さではなく設定：誤ったチェーンの
                              アドレス、不正な形式のワーカー名、
                              または誤ったポート（例：大型 ASIC 向けの
                              高難易度ポート）。

ハードウェアエラー率：誠実な数字

ダッシュボードのハッシュレートは主張であり、ハードウェアエラー率は自白です。これは ASIC が返してきたが検証を通らなかった結果を数えたものです。2 パーセント未満なら健全です。温度の上昇とともにエラー率が上がるなら熱の問題、温度が一定なのに設定変更後にエラー率が上がるなら、周波数と電圧の組み合わせがそのチップのシリコンの限界を超えています。エラー率 5 パーセントのチップは立派なハッシュレートを表示しながら、実効ハッシュレートは静かに、周波数を下げた場合を下回る水準まで落ちていることがあります。チューニングの際は一時間あたりの受理シェア数を最適化目標にしてください。ダッシュボードの数字は決して目標にしないこと。手法の全体は BM1373 リファレンスのチューニングの章にあり、シェア難易度が何を意味するかの背景は best share の解説にあります。

「マイナーはハッシュ中と言うのにプールに何も出ない」

あらゆるコミュニティで最も多く投稿される症状なので、解決までの道筋を丸ごと示します。

1. プール側、最後に受理されたシェアからの経過時間：
   10 分超 = 接続は「今」死んでいる。マイナーの画面が何と
   言おうと関係ない。ダッシュボードの平均値は約一時間かけて
   減衰し、直近の切断を隠す。「ハッシュレートがゼロより上」
   はオンラインのテストではない。「最後のシェアが最近」が
   テストである。

2. マイナー側、ライブログ：
   シェアは「提出」されているか？ ASIC が nonce を見つけて
   いるのに何も提出されていないなら、stratum のソケットが
   固まっている —— マイナーを再起動すること。
   提出が「エラー」を返しているか？ 拒否理由の表を読むこと。

3. 同一性の確認：今見ているプールのダッシュボードは、
   マイナーに設定されているのと同じウォレットアドレス、
   かつ同じコインで絞り込まれているか？ 驚くほど多くの
   ケースが、マイナーは BCH を向いているのに BTC の
   ダッシュボードを開いていた、あるいは昨日のテスト用
   アドレスの統計ページを見ていた、というものである。

4. フォールバック：予備プールが設定されていて、マイナーが
   静かにそちらへ切り替わっていないか？ あなたのハッシュ
   レートは「もう一方の」プールに届いているかもしれない。
   そちらの統計を確認すること。

フォールバックは必ず設定する

AxeOS 系統のすべての機器は予備プールに対応しています。フォールバックのないマイナーが午前 2 時に stratum のソケットを失うと、あなたが気づくまで何もしません。そしてダッシュボードの減衰していく平均値が、気づくのが遅くなることを確実にしてくれます。フォールバックには同じプールの別リージョンを設定してください。そうすればリージョン単位の障害でマシンが止まることは決してありません。各チェーンのリージョン別ホストとポートは接続ページにあります。

ファームウェアの問題：書き込み、文鎮化、復旧

二ファイル構成の OTA と「半文鎮」

AxeOS の更新は二つの成果物で構成されます。ファームウェアのバイナリと、ウェブ画面のイメージ（www.bin）です。文書化されている故障モードの一つが、OTA が www.bin の段階で固まり、ファームウェアと画面が同期しなくなるというもの。機器は起動して採掘もしますが、ダッシュボードは真っ白か壊れています。これは文鎮化ではありません。復旧用の URL に直接アクセスしてください。

http://<マイナーのip>/recovery

そしてウェブイメージを再アップロードします。更新失敗後にまったく起動しなくなった場合は、USB のウェブ書き込みツール（Chrome か Edge、USB-C データケーブル）が工場出荷イメージ全体を書き直し、事実上あらゆるソフト文鎮を救います。三つのルールが、書き込みを恐ろしいものから退屈なものに変えます。

• イメージは基板に正確に、リビジョン単位まで一致させること。リビジョン番号は基板そのものに印字されており、AxeOS のシステム欄にも表示されます。Supra 401 には 401 のイメージが必要で、402 ではありません。リリースページにある二種類のファイルを理解してください。完全版の esp-miner-factory-REV-vX.X.X.bin（ブートローダ + パーティション + 画面 + ファームウェア。USB 書き込みと完全復旧用）と、小さい方の esp-miner.bin（ファームウェアのみ。ダッシュボード経由の OTA 用）です。一方を他方の場所で使うのが、典型的な半文鎮のレシピです。Gamma のイメージは Gamma へ、Ultra は Ultra へ。誤ったイメージは NVS に誤ったデバイス設定を残し、通常の再書き込みを生き延びることがあります。治療法は工場出荷時リセットと正しいイメージの組み合わせです。
• 電波がぎりぎり、あるいは電源がぎりぎりの状態で WiFi 経由の書き込みを絶対に行わないこと。www.bin の段階で固まる現象は、まさにこの二つと相関しています。
• 戻り先のバージョンを把握しておくこと。退行は起こります。v2.13/v2.14 付近のテレメトリ喪失帯、機器がより高温で動作するようになった v2.11 付近のファンカーブ変更、一部のハードウェアリビジョンでユーザーがダウングレードするまで固まっていた v2.4.3 付近の更新経路など。更新前に現在のバージョンを控えてください。新しい方の挙動が悪ければ、前のバージョンはプロジェクトのリリースページでウェブ書き込み一回の距離にあります。

クラッシュループ：Guru Meditation を読む

Guru Meditation Error は ESP32 のカーネルパニックです。括弧内の語が手がかりになります。

Guru Meditation Error: Core X panic'ed (理由)

LoadProhibited /       ファームウェアのバグが不正なメモリに
StoreProhibited        触れている：バージョンを控え、issue
                       トラッカーを確認し、一つ前に戻す
IllegalInstruction     フラッシュの破損またはスタックの上書き：
                       USB 経由で完全に再書き込みする
Cache error /          たいてい PSRAM の問題に続いて出る
DoubleException        （後述）
Interrupt wdt timeout  タスクが固まっている —— ネットワーク
                       関連であることが多い。自分のバージョンの
                       既知 issue を探すこと

単発のパニックは無視してかまいません。ループの場合は、毎回同じ理由なのか（ファームウェアまたはハードウェアの不具合。表に従って対処）、それともブラウンアウトのメッセージが混ざっているのか（それなら電源の問題です。パニックを読むのをやめて電源を直しに行ってください）を見極めてください。

PSRAM の不具合：Nerd 系統に特有の話

NerdQaxe、NerdOctaxe、その他 ESP32-S3-WROOM-1 モジュールを使う基板は外部 PSRAM を搭載しています。起動バナーに PSRAM の ID 読み取りエラーや初期化失敗が出て、ファームウェアが外部 RAM に触れた瞬間に StoreProhibited のパニックが続く場合、既知の原因は五つあります。PSRAM のダイが入っていない偽造モジュール、誤った PSRAM モード（quad ではなく octal）でコンパイルされたファームウェア、モジュール下のはんだ不良、初期化ウィンドウ中のブラウンアウト、そして劣化したダイです。実践的なトリアージはこうです。まず電源を除外し（いつもどおり）、自分の基板向けのメーカー純正イメージを正確に書き込み（これが正しい PSRAM モードを内包しています）、それでもクリーンな電源と正しいファームウェアの下でエラーが続くなら、モジュール自体が原因です。これは保証か作業台の案件になります。

オーバークロックの失敗：復旧と予防

不具合の特徴はこうです。周波数か電圧を上げたところ、クラッシュするようになった、数分から数時間でハッシュレートが平坦になる、スロットリングする、あるいはマルチチップ基板からチップが一つ消える。物理法則は一点において容赦がありません。クロックが高すぎることによる不安定さは、現れるまでに時間がかかることが多いのです。10 分のテストを生き延びた設定が、基板が完全に熱飽和した 40 分目に失敗することがあります。24 時間未満の安定性の主張がすべて暫定的である理由がこれです。

復旧（機器がまだ起動する場合）：
  ウェブ画面 -> 周波数と電圧を工場出荷値に戻す -> 保存 ->
  コールド電源サイクル（ラッチした故障があれば消える）。

復旧（画面に到達する前にループに入る場合）：
  USB 経由で工場出荷イメージを書き込む —— これで出荷時の
  動作点が復元される。そのあと NVS を空にするため工場出荷時
  リセットを行う。

予防（手法の全体が五行）：
  - 一度に 25 MHz 一段だけ。電圧は触らない
  - 一段につき最低 30 分。HW エラー率を見張る
  - エラーが 2% を超えたら一段戻す。そこが壁である
  - 追加の発熱を受け入れる覚悟があるときにのみ、そこから
    25 mV 刻みで電圧を上げる。1100-1300 mV の範囲に留まること
  - 最終設定で 24 時間回してから、安定と呼ぶこと

そして正直な補足を一つ。効率のためのアンダーボルトは、速度のためのオーバークロックとまったく同じ形で失敗します。方向が逆なだけです。クロックに対して電圧が足りなければ、同じエラーと同じ固まり方を生みます。シリコンくじは両端で成立します。

API で診断する：上級者の近道

AxeOS 系統のすべてのマイナーはポート 80 で REST API を公開しており、これがトラブルシューティングの姿を変えます。画面は不要、ダッシュボードをクリックして回る必要もなく、一台から複数台の運用までそのまま拡張できます。完全な仕様は ESP-Miner リポジトリの openapi.yaml にあります。診断に効く呼び出しは以下のとおりです。

五つの診断用呼び出し

# 一度に全部：ハッシュレートの平均、各種温度、電圧、消費電力、
# ファン回転数、シェア、ベスト難易度、WiFi RSSI、稼働時間、
# ファームウェアのバージョン、空きヒープ
curl http://マイナーのIP/api/system/info

# ASIC の状態：モデル、個数、周波数、電圧
curl http://マイナーのIP/api/system/asic

# ダッシュボードのグラフの元になっている時系列データ
curl "http://マイナーのIP/api/system/statistics?columns=hashrate,asicTemp,vrTemp,power"

# 過小評価されているもの：機器のログをリモートで取得する。
# シリアルケーブルも PuTTY も不要 —— ログをネットワーク越しに
# 取ってきて、下の辞書にある赤いエラー行で絞り込むだけ。
curl http://マイナーのIP/api/system/logs

# どれがどれか？ 機器に自分を名乗らせる（画面 / LED）——
# 同じ箱が並んだ棚では値段がつけられないほど便利
curl -X POST http://マイナーのIP/api/system/identify

このログのエンドポイントには独立した一文を割く価値があります。機器が HTTP を返せる程度まで起動しているかぎり、本ガイドのシリアルコンソールの章の大半は、この呼び出し一つでソファに座ったまま実行できます。シリアルケーブルが依然として必要なのは、起動時点での不具合とクラッシュループだけです。

/api/system/info を整備士のように読む

この JSON の六つのフィールドが、質問が発せられる前に大半の問い合わせに答えてくれます。

フィールド（一般的な名称） それが伝えていること
hashRate / hashrate_10m   例の「主張」—— プールと突き合わせる
temp / asicTemp           熱の章にある 55-62 C の予算
vrTemp                    レギュレータ側 —— BM1370/BM1373 では
                          しばしばこちらが真の制限要因
voltage                   基板から見た入力レール：ソフトウェアの
                          テスター。負荷時に 4.9 V を下回るなら
                          電源が原因。筐体を開けずに証明できる
power                     実際の消費ワット数：「ハッシュ中」の
                          機器が 2 W なら USB-C の罠
sharesAccepted /          真実の二人組。拒否が増えているなら
sharesRejected            拒否理由の表へ
wifiRSSI                  -70 dBm より強ければ健全。それより
                          弱いなら期限切れシェアの説明になる
freeHeap                  数日かけてじわじわ減るなら、メモリ
                          リークの類のファームウェアバグ。
                          バージョンを控えてトラッカーを確認

ループで複数台の健全性を確認する

一台を超えたら、ダッシュボードを一つずつ見るのはやめましょう。このループはマイナーごとに一行の健全性サマリを出力し、死んでいるものに印を付けます。

#!/bin/bash
# fleet-check.sh - IP は自分の機器群に合わせて書き換える
for IP in 192.168.1.101 192.168.1.102 192.168.1.103; do
  J=$(curl -s -m 5 "http://$IP/api/system/info")
  if [ -z "$J" ]; then
    echo "$IP  到達不能"
    continue
  fi
  echo "$J" | python3 -c "
import sys, json
d = json.load(sys.stdin)
print('$IP  %-10s %6.1f GH/s  %4.1fC  %4.1fW  acc:%s rej:%s' % (
  d.get('hostname','?'),
  d.get('hashRate',0),
  d.get('temp',0),
  d.get('power',0),
  d.get('sharesAccepted','?'),
  d.get('sharesRejected','?')))"
done

これを cron で五分ごとに走らせ、好みの通知先へ流せば、午前 2 時の障害は朝の驚きではなく午前 2 時 5 分のアラートになります。フィールド名はファームウェアのバージョンによって少し異なるので、一度生の JSON を出力してから合わせてください。

API は直すこともできる

# ハードウェアに触らずに再起動する
curl -X POST http://マイナーのIP/api/system/restart
#   （注意：これはラッチした TPS546 の電源故障は消さない ——
#    そちらは依然として物理的な抜き差しが必要）

# オーバークロックの実験を正気な値に戻す
curl -X PATCH http://マイナーのIP/api/system \
  -H "Content-Type: application/json" \
  -d '{"frequency": 525, "coreVoltage": 1150}'

# 打ち間違えたプール設定を画面なしで直す
curl -X PATCH http://マイナーのIP/api/system \
  -H "Content-Type: application/json" \
  -d '{"stratumUser": "あなたのウォレットアドレス.worker1"}'

正直な但し書きを一つ。この API には認証がありません。同じ LAN にいる誰もが、あなたのマイナーを読み取り、設定を書き換えられます。家庭内ネットワークならたいてい許容範囲ですが、共有ネットワークやゲストが入れるネットワークでは、マイナーを専用の VLAN か IoT セグメントに入れてください。都合のよいことに、これは WiFi の章ですでに推奨したのと同じ対処です。

機種ごとの癖：自分の基板の性格を知る

共通の故障モードとは別に、基板の系統ごとに、デバッグを始める前に知っておく価値のある特徴的な振る舞いがあります。

症状のマスターテーブル

赤いエラー行の辞書

実際に遭遇するエラー文字列を一か所にまとめ、Ctrl+F で見つかるよう一字一句そのまま書いてあります。自分の行を見つけて、進む方向を手に入れてください。

ログ中の行                         意味 -> どこへ行くか
---------------------------------------------------------------
Brownout detector was triggered    電圧降下 -> 電源
rst:0x.. (BROWNOUT_RESET)          同じもの。リセットのバナー内
Power Fault Detected               TPS546 のラッチ -> 電源
TPS546 status / regulator fault    同じ系統 -> 電源
VCORE init failed /                ファームウェアがレギュレータを
  device ID mismatch               設定できない：イメージ違いか
                                   I2C -> ASIC + ファームウェア
i2c_master_transmit_receive err /  センサーバスの停止 -> ASIC の
  ESP_ERR_TIMEOUT near boot          章、I2C の小節
Found 0 chip(s) / ASIC init fail   チップが応答しない -> ASIC
Chip count N of M                  N+1 の位置でチェーン断線 -> ASIC
Device has overheated /            75 C での停止 -> 熱
  Overheat Mode
VREG temp over limit               レギュレータ側の高温 -> 熱
wifi: NO_AP_FOUND                  2.4 GHz での可視性 -> ネットワーク
wifi: AUTH_EXPIRE / auth fail      パスワード違い -> ネットワーク
wifi: beacon timeout               信号かチャンネルが弱い -> ネットワーク
wifi_disconnect reason: N          N を調べる。理由ごとに対処
Stratum connection failed /        プールに到達できない -> Stratum
  connect errno
authorize failed                   ログイン拒否 -> Stratum、
                                   アドレスとワーカーを確認
job not found（提出時）            期限切れシェア -> Stratum
above target / low diff share      難易度のずれ、または HW エラー
duplicate share                    nonce の引っかかり -> 電源を
                                   入れ直し、その後クロックを下げる
Guru Meditation Error: (理由)      パニック -> ファームウェア。
                                   括弧内の理由の語を読む
esp_psram: PSRAM ID read error /   PSRAM 初期化 -> ファームウェア、
  Failed to init external RAM        Nerd 系統の小節
E (xx) esp_image: checksum failed  フラッシュ破損 -> USB 再書き込み
[www.bin / 更新後に画面が真っ白]   復旧 URL -> ファームウェア

予防保守：月 15 分の儀式

上に挙げたことのほとんどは、デバッグするより予防する方が安上がりです。

毎月
  [ ] ほこり：フィンとファンの羽根（エアダスター。ファンは
      押さえて回さないこと）
  [ ] プール側からの確認：受理と拒否の推移、HW エラー率が
      まだ 2 未満か
  [ ] 温度をざっと見る：先月と比べてずれていないか？
  [ ] 電源コネクタを実際に触る：ぬるいなら警告、熱いなら中止

6-12 か月ごと
  [ ] サーマルグリスを塗り直す（消耗品である）
  [ ] XT30 や DC ジャックのピンの変色を点検する
  [ ] テスターで電源を負荷時に再確認する

ファームウェア更新のたびに
  [ ] 書き込む「前に」リリースノートを読む
  [ ] 現在のバージョンを控える（戻り先になる）
  [ ] 電源が安定した状態で、できればルーターの近くで書き込む
  [ ] 事後にプール設定を再確認する：更新で項目がリセットされる
      ことがある

常に
  [ ] 予備プールを設定してある（別リージョン）
  [ ] 全機で重複しないワーカー名を使っている
  [ ] 書き残した対応表：チェーン -> ウォレットアドレス
  [ ] チューニング前に工場出荷時設定を控えてある

本当にハードウェアだったとき：何が修理可能か

コールドサイクルも、工場出荷時リセットも、検証済みの電源での正しいイメージの再書き込みもやった。それでも不具合が残る。それがハードウェアの問題の定義です。現実的な修理の地図は次のとおりです。

• 作業台で修理可能（ホットエア、顕微鏡、安定した手、あるいは専門家）：故障した TPS546 や降圧段の部品、割れたセラミックコンデンサ、ASIC や ESP32 モジュール下のはんだ不良（リフロー）、摩耗した電源コネクタ、死んだファン。ASIC の修理を扱う工房ならどこでも日常的な作業です。
• ときには救える：5 V レールが完全に短絡している基板（電源を切った状態でグランドに対しほぼ 0 オーム）—— これ以上通電しないでください。まず短絡箇所を見つけて取り除く必要があります。
• たいてい手遅れ：ヒートシンクが接触しない状態で数秒を超えて動作した ASIC、熱暴走のあとの残骸、あるいは間に合わせの VRM 修理中に誤ったコア電圧を与えられたチップ。シングルチップ基板ではチップが価値のほとんどを占めるため、ある地点を越えると交換の方が修理に勝ります。

コミュニティの支援は OSMU の Discord と ESP-Miner の GitHub issue トラッカーにあります。投稿する前にまずトラッカーを検索してください。「うちの機器が壊れた」という報告のうち驚くほどの割合が、次のバージョンに修正がすでにマージされている既知の issue だからです。実際に報告するときは、完全な報告なら数時間で返信が付き、曖昧な報告は静かに埋もれます。このテンプレートをコピーしてください。

基板：       （正確な型番 + リビジョン。例：Gamma 602）
ファームウェア：（AxeOS のバージョン。画面または
              /api/system/info から）
電源：       （電圧、アンペア、メーカー —— そして：負荷時に
              測定したか？）
プール：     （URL + ポート + コイン）
症状：       （一文で：何が起きるか、いつからか）
きっかけ：   （直前に何を変えたか：更新？ 輸送？ OC？
              ヒートシンクの再取り付け？ 何もしていない？）
試したこと： （60 秒コールドサイクル？ 工場出荷時リセット？
              再書き込み？ 工場出荷時の周波数？ セルフテストの
              結果は？）
ログ：       （シリアル 115200 の起動ログ、または
              curl http://IP/api/system/logs の出力を貼る ——
              最低でも最初の E 行とその前後 10 行）

このテンプレートはお役所仕事ではありません。修理工房が最初に集める情報そのものであり、集める順序まで同じです。

PRO：作業台の章 —— 回路図、測定ポイント、テスター

この章は、回路図が読めて、隣接するピンを短絡させずに通電した基板をプローブできることを前提としています。この一文でためらったなら、ここで止めてください。この行より上のすべては筐体を開けずに解決できますし、通電した 3 nm の基板の上で滑ったプローブは、一つの問題を二つに変えます。それ以外の方には、ここがオープンハードウェアが本当に報いてくれる場所です。

これらの基板が他のどのマイナーとも違う理由

Bitaxe のハードウェアは CERN-OHL-S ライセンスで KiCad により設計されており、すべての回路図、すべての基板レイアウト、すべての部品表が公開されています。つまり、ある部品が何なのか、あるレールがどこを通っているのかを推測する必要が一切ありません。自分の基板の正確なリビジョンの正確な回路図を開き、そのネットを見つけ、測ればよいのです。Antminer の所有者がこの特権を持ったことは一度もありません。さらに、各ハードウェアリポジトリには、ほとんど誰も開かないセクションがあります。リビジョンごとの既知の不具合、改修、正誤情報をまとめた HW issues のページです。基板レベルの不具合を診断する前に、自分のリビジョンに文書化された正誤情報がないか確認してください。「原因不明」のハードウェア不具合の驚くほどの割合が、それを直す改修方法と一緒にすでにそこへ書かれています。

テスターの手法：三本のレールが物語のすべてを語る

給電経路の不具合は、順番に行う三回の直流測定で切り分けられます。まずグランドを基準に取り、順序を守り、指定された箇所では負荷をかけた状態で測ってください。

レール 1 —— 入力（系統により 5 V または 12 V）
  測る場所： 入力コネクタ / 入力パッド（回路図を参照）
  期待値：   5 V 系： ハッシュ中に 4.9 - 5.3 V
             12 V 系：ハッシュ中に 11.8 - 12.2 V
  負荷時だけ低い -> 電源かケーブル（大半のケース）
  良い電源なのに 0 -> 入力保護の焼損か、下流の短絡：
                      電源を切った状態でグランドとの抵抗を
                      測る。ほぼ 0 オーム = 短絡。通電を
                      やめて、それを探すこと

レール 2 —— 3.3 V（ESP32 の給電）
  測る場所： 回路図上の 3.3 V ネット（ESP32 モジュール）
  期待値：   3.2 - 3.4 V で安定
  入力が正常なのに存在しない -> 小さい方の 3.3 V
  レギュレータかその周辺の受動部品。電源が良品と証明済み
  なのに「完全に無反応、USB の列挙もない」という状況を
  説明する

レール 3 —— VCORE（ASIC の給電）
  測る場所： TPS546 降圧段の出力 / ASIC コアのネット
  期待値：   おおよそ 1.0 - 1.3 V。AxeOS で設定した値と
             一致すること
  入力も 3.3 V も正常なのに存在しない -> 降圧段：ラッチした
  故障（必ず先にコールドサイクル）、あるいは TPS546 /
  インダクタ / 周辺の受動部品の故障
  存在するが値が違う -> レギュレータの設定か PMBus の通信。
  AxeOS が設定したと思っている値と突き合わせること

確認のための測定
  入力コネクタ -> レギュレータ入力の導通：断線したパターンや
  割れたジャックのはんだを見つけられる
  ダッシュボードの TPS546 ダイ温度と、手を近づけた感覚の比較：
  無負荷で近づけないほど熱いレギュレータは壊れかけている

この三本のレールが、あらゆる電源不具合を切り分けます。入力が不良 = 基板より手前。入力は良好で 3.3 V が不良 = 小さい方のレギュレータ。両方良好で VCORE が不良 = 降圧段。三本とも良好 = 不具合は電源ではないので ASIC の章に戻る。二十ドルのテスターと十分間が、何時間もの推測に取って代わります。

修理工房にできること、できないこと

日常的な作業（ホットエア + 顕微鏡 + 安定した手）
  - TPS546 や降圧段の部品の交換
  - 割れたセラミックコンデンサ（目視：本体を横切る細い
    ひび。電気的：短絡または開放）
  - ASIC や ESP32 モジュール下の BGA リフロー（落下後と
    取り付け直し後の故障の類）
  - コネクタの交換（摩耗したジャック、焼けた XT30）

根気があれば可能
  - 5 V レールの短絡箇所の追跡（サーモグラフィ、または
    怪しい領域にイソプロピルアルコールを垂らして蒸発を
    見る手法）
  - ESP32-S3 モジュールの交換（あとで再書き込みが必要）

割に合わない / 手遅れ
  - シングルチップ基板での ASIC 交換：チップが基板の価値の
    ほとんどを占め、供与元のチップもどのみち再生品である。
    新しい基板の方がコストでも確実性でも勝る
  - 熱暴走のあと、またはレール全体に逆極性の入力が加わった
    あとのあらゆる状況

修理技術者のように回路図を読む

公開された回路図を本当に役立つものにする習慣が三つあります。第一に、電源ツリーのページを見つけ、何かを測る前に一度、紙の上で入力から VCORE までの経路をたどってください。その時点であなたは、そのレールを殺し得るすべての部品を把握しています。第二に、降圧段の部品番号（R12、C34、U3）を控えてください。フォーラムの投稿も正誤情報も部品番号で部品を指しますし、レイアウトファイルを開いていれば自分の基板上でそれらを見つけるのは数秒です。第三に、不具合がリビジョン固有であるときはリビジョン同士を比較してください。たとえば Gamma 600 と 601 の間の変更履歴は、設計者が何を直したのかを正確に教えてくれます。そしてそれは、古い方で壊れるものとまさに一致していることが多いのです。

オープンソースのリソース集

一次情報源をすべて一つの表にまとめました。この章をブックマークしてください。オープンハードウェアの価値の半分は、原典がどこにあるかを知っていることにあります。以下のリンクはすべて公式の情報源であり、ミラーではありません。

要点

• 六つの領域がほぼすべての不具合を覆う：電源、ASIC、熱、ネットワーク、stratum、ファームウェア。60 秒トリアージが、何かを触る前にあなたがどの領域にいるかを教えてくれる。
• 電源は第一の原因であり、第一の詐称者でもある。WiFi のクラッシュ、ファームウェアのパニック、引っかかったチップ、死んだ基板に化ける。他のどんな仮説を信じる前にも、まず負荷をかけて入力を測ること。
• ラッチしたレギュレータの故障は、あらゆるソフトウェア再起動を生き延びる。10 秒から 60 秒の物理的な抜き差しは迷信ではなく、本物の診断手順である。
• USB-C が給電するのは ESP32 であって、ASIC ではない。USB-C だけの基板は 0 GH/s の死んだマイナーを完璧に模倣する。
• 115200 ボーのシリアルコンソールを覚えること。起動ログの最初の E 行は、どんなフォーラムのスレッドよりも速くあなたの問題に名前を付ける。
• 内蔵セルフテストは 30 秒で故障したサブシステムの名前を出し、REST API はログもテレメトリも、ときには修正手段までネットワーク越しに届けてくれる。シリアルケーブルを探しに行く前に、この二つを使うこと。
• 12 V の電源を 5 V の基板に絶対に繋がないこと。コネクタは差し替えられるが、基板はそうではない。
• ESP32 は 2.4 GHz しか話さない。バンドステアリングと AP 分離が、最も多くの導入を壊している二つのルーター機能である。
• プール側の真実は、マイナー側の楽観に勝る。最後に受理されたシェアからの経過時間が唯一誠実な稼働テストであり、10 分がその境界線である。
• ウォレットアドレスは採掘中のチェーンのネイティブでなければならない。ノンカストディアルのプールにおいて、これは唯一、後戻りのできない間違いである。
• ハードウェアエラー率が誠実な性能の数字であり、ダッシュボードのハッシュレートは主張にすぎない。受理シェアに向けてチューニングし、どんな設定であれ安定と呼ぶ前に 24 時間を要求すること。
• 熱い電源コネクタは、「あとでデバッグ」ではなく「今すぐ中止」を意味する唯一の症状である。

本稿は ESP-Miner の issue トラッカーとリリースノート、ESP-IDF の致命的エラーに関する文書、コミュニティの修理工房の資料、そして Bitaxe、NerdAxe、NerdQaxe の各コミュニティで繰り返し報告されている故障パターンをもとに、2026 年 7 月 20 日時点でまとめたものです。ここで述べたファームウェアの挙動（故障のラッチ、過熱のしきい値、復旧 URL、既知の退行バージョン帯）は公開時点の AxeOS および ESP-Miner のバージョンを反映しています。ご自身のバージョンのリリースノートを確認してください。本ガイドは生きた参考資料として維持されています。ここで扱われていない故障モードに遭遇した場合は、お問い合わせページからご連絡ください。追記します。