Tether MDKとは？15社参加の意味と本番導入前の確認点

メーカーの異なる採掘機を別々の管理画面で扱う現場では、通信断の直前に命令が実行されたか分からず、再送によって同じ操作を重ねる危険があります。機器をまとめて見たいという要求に対し、接続確認だけで本番へ進めば、権限漏れや復旧不能を招きかねません。

Tether MDK（Mining Development Kit）は、この機器差を共通の方法で監視・制御するアプリを作るためのオープンソース基盤です。完成済みの一元管理製品ではありません。2026年10月24日に発表された15社参加も、各社が自社向けの「Worker」を構築・保守する合意であり、全社の接続完成や現場配備を示す数字ではありません。

先に見るべき優先点は、①自社機種に合うWorkerが実在するか、②現行0.xの変更へ追随できるか、③認可と障害復旧を自社側で実装・検証できるか、の三つです。本稿は公式文書、公開リポジトリ、参加企業の発表、第三者報道を2026年10月28日に机上確認して整理しました。実機での耐久試験は行っていないため、性能や安全性を独自に保証するものではありません。

最初に押さえる用語：ASICはBitcoin計算に特化した採掘機、APIはソフト同士の接続口、SDKはアプリ開発用の部品一式、テレメトリーは温度や稼働状態などの遠隔測定値です。HRPCはMDK内部の通信方式、冪等性は同じ命令を再実行しても結果が重ならない性質を指します。本文ではこれらを導入判断に必要な範囲だけ扱います。

Tether MDKの定義と15社参加の意味

Bitcoinのマイニング施設では、複数メーカーのASIC、冷却設備、電力管理装置、マイニングプールなどを組み合わせることがあります。それぞれの機器やサービスが異なるAPIや管理画面を使うと、監視項目、操作手順、障害対応がばらばらになりやすくなります。MDKは、その違いを吸収する共通層を設け、運用アプリから同じ考え方で扱えるようにする開発基盤です。

機器監視と制御を共通化するオープンソース基盤

MDKは完成済みの単一管理画面というより、マイニング運用アプリを組み立てるための部品群です。機器の状態を取得する「テレメトリー」と、設定変更や再起動などの「命令」を共通形式で扱い、機器固有の違いは後述するWorkerが変換します。既存設備をすべて同じメーカーへ交換するのではなく、接続部品を追加して共通の上位システムへつなぐ発想です。

この設計が狙うのは、特定ベンダーの管理ソフトだけに運用全体を依存する状態の緩和です。ただし、MDKを採用すればベンダー依存が完全になくなるわけではありません。機器固有APIが変更されればWorker側の更新が必要であり、対応モデル、機能、品質もWorkerごとに異なり得ます。

JS SDKとUI部品で運用アプリを構築できる

公式発表では、JavaScript SDKとReactのUI部品が提供されます。開発者は、共通APIを呼び出すダッシュボードや社内ツールを構築できます。MDKの「フルスタック」という説明は、導入するだけであらゆる設備が自動統合されるという意味ではなく、バックエンドの通信層から画面部品まで、開発に使える範囲が広いという意味で読むのが適切です。

MDKアプリは、構成を記述するmdk.yaml、機器やプールにつなぐWorker、外部アプリとの窓口となるGatewayプラグイン、必要に応じたUIなどで構成されます。運用者はKernel本体へ機器別コードを次々に埋め込むのではなく、交換可能な拡張部分を組み合わせます。この分離により追加しやすくなる一方、組み合わせ試験とバージョン管理は利用者側の仕事として残ります。

Apache-2.0のコードから実装と試験を確認できる

MDKのモノレポはApache-2.0ライセンスで公開され、コード、テスト、デモ、変更履歴、セキュリティ方針を確認できます。発表資料だけでなく、実際のパッケージや未解決の変更を技術評価に含められる点は重要です。一方、公開されていること自体は、特定の設備構成での安全性や長期安定性を保証しません。採用判断では、ライセンス、依存パッケージ、更新頻度、試験範囲も個別に確認します。

15社参加が示す範囲と示さない範囲

参加企業はASICメーカーとプールなど供給側が中心

Tetherは2026年10月24日、BITMAIN、Canaan、MicroBT、Bitdeer、ProtoのようなASIC関連企業と、複数のマイニングプールを含む15社がMDKを支持すると発表しました。異なる機器やプールへ接続するには、それぞれの仕様をよく知る提供者の協力が重要です。その意味で、供給側の企業が接続部品を担当する枠組みには実務的な意義があります。

ただし、参加社の構成と、採掘事業者による採用は別の指標です。報道では主要な米上場マイナーが参加社一覧に含まれない点も指摘されています。これはMDKが採用されないと断定する材料ではありませんが、少なくとも「15社」という数だけでは、運用現場にどこまで広がったかは測れません。

合意の範囲はWorkerの構築と継続保守

公式発表が示す中心的な約束は、参加各社が自社のハードウェアやプール向け統合を構築し、継続的に保守することです。完成品の納入、全モデル対応、特定日からの本番稼働までが一括して確約されたわけではありません。導入側は、対象Workerが公開済みか、どのモデルとファームウェアに対応するか、誰が障害対応するかを別途確認する必要があります。

稼働台数やハッシュレート採用比率とは区別する

参加社数は、MDKで管理されているASICの稼働台数でも、Bitcoinネットワーク全体のハッシュレートに占める比率でもありません。全15社のWorker完成、各社顧客への配布、実サイトへの配備が済んだという発表も確認されていません。普及度を見るなら、公開済みWorkerの数、対応モデル、導入サイト、継続稼働期間、処理対象の規模など、異なる証拠が必要です。

CanaanとTetherには今回以前から採掘ハードウェア・ソフトウェア面の協業関係があります。既存の協業は統合作業を進める土台になり得ますが、それと独立した第三者による広範な本番採用は区別して評価します。発表の意義を過小評価する必要はないものの、数の印象を稼働実績へ置き換えないことが大切です。

三層構造と利用者側に残る実装責任

共通命令とテレメトリーをつなぐアダプター

Workerは、上位のMDK共通プロトコルと、下位のメーカー固有APIをつなぐ翻訳層です。例えば、運用アプリが共通形式で「状態を取得する」「設定を変更する」と要求すると、Workerが対象機器のAPIに合う形へ変換します。反対に、温度、稼働状態、性能など機器側から得た情報を共通のテレメトリー形式へ整え、Kernelへ返します。

この仕組みにより、上位アプリは機器ごとに通信処理をすべて書き分けずに済みます。ただし、共通化できるのは契約で定義された範囲です。ある機器だけが持つ特殊機能や、ファームウェアごとの応答差まで自動的に消えるわけではありません。

Kernelを改変せず新しい機器対応を追加できる

第三者は、MDK本体を直接改変せず、別のnpmスコープでWorkerを作成・公開できます。接続先、扱う命令、テレメトリーなどを契約ファイルで示し、拡張部品として組み込みます。新しいメーカーや機種を追加しやすく、Kernelの中核コードと機器別の変更周期を分けられるのが利点です。

一方で「追加できる」と「公式がすべて保守する」は同義ではありません。実装者は機器APIを追跡し、認証情報を安全に扱い、互換性を試験し、障害を修正する必要があります。自社製Workerや第三者製Workerを使う場合は、公開主体、更新窓口、脆弱性対応、サポート終了条件を確認します。

対応モデルとWorkerごとの品質差は残る

公式のパッケージ一覧にはAntminerやAvalon向けWorkerなどが掲載されていますが、名称だけで自社の全モデル・全ファームウェアが対応すると判断できません。同じメーカーでも世代、制御API、認証方法が違う可能性があります。命令の種類も、読み取りだけか、再起動や設定変更までできるかで運用上の意味が変わります。

導入前には、対象機種とファームウェアの対応表、読み取り・書き込み機能、タイムアウト時の挙動、エラーの表現、試験結果をWorker単位で確認します。共通基盤はインターフェースをそろえますが、下位機器の差や実装品質まで均一にするものではありません。公式パッケージ一覧と各提供元のリポジトリを照合し、名称だけで対応済みと判断しないことが要点です。

Gateway・Kernel・Workerの責任分界

Gatewayが外部アプリとの接点を担う

Gatewayは、ダッシュボード、CLI、社内システム、AIエージェントなど、外部の利用者やアプリとMDK内部をつなぐ入口です。外から来た要求を受け、Kernelが扱える命令へ渡し、戻ってきた結果や状態を外部へ提供します。HTTPやMCPなど、利用形態に合った接続面を用意する場所でもあります。

セキュリティ上とくに重要なのは、利用者認証と書き込み認可がGateway側の責務になる点です。「誰が接続できるか」だけでなく、「誰がどの機器に、どの命令を、どの条件で実行できるか」まで制限する必要があります。

Kernelは命令配送と機器状態管理に集中する

Kernelは、登録された機器とWorkerの関係を把握し、命令を担当Workerへ配送し、定期的なテレメトリー取得や機器状態の管理を行う中核です。しかし、公式アーキテクチャでは、複数サイトのデータ集約、長期テレメトリー保存、利用者の認証を何でも担う中央管理製品ではありません。

したがって、履歴データベース、分析基盤、監査ログ、全社向けのユーザー管理が必要なら、Gatewayや外部アプリを含めた別の設計が要ります。Kernelが担わない機能を把握せずに本番要件を当てはめると、後工程で大きな追加実装が生じます。

切断時の命令保持と再送を前提にしない

Kernelは受動的な中核であり、接続が切れた間の未達命令を無制限に蓄積し、復旧後に必ず再送する中央ジョブキューとは位置付けられていません。この違いは、停止・再接続時の安全設計に直結します。命令が届かなかったのか、実行後に応答だけ失われたのかを区別できなければ、再実行で意図しない操作が重なる恐れがあります。

利用側では、各命令のタイムアウト、再試行の可否、冪等性、実行結果の確認方法を定めます。とくに電源や稼働設定を変える操作では、「応答なし」を単純に「未実行」と扱わず、実機状態を再取得してから次の判断を行う手順が必要です。

複数サイト運用で利用者側に残る統合

サイトごとに制御境界を分離する

公式のスケーラビリティ設計は、基本的に1サイトにつき1つのKernelと1つのGatewayを置く考え方です。拠点ごとに制御境界を分ければ、あるサイトのネットワーク障害や設定ミスを他サイトから切り離しやすくなります。地域ごとの回線、電力、機器構成に合わせて運用できる利点もあります。

ここでの「サイト」が自社のラック、建屋、地域のどこに相当するかは、設備と障害分離の要件に合わせて定義します。すべてを一つのKernelへ集めればよいとは限らず、分割を増やせば監視対象と更新作業も増えるため、境界設計が必要です。

全拠点の一元監視は独自アプリで補う

MDK本体は複数サイトの情報を自動で一つに集約しません。全拠点を一つの画面で監視したい場合、利用者側のアプリが各サイトのGatewayへ接続し、データを収集・正規化して表示します。長期履歴、横断検索、アラートの統合、権限の一元管理も、その外部層で設計することになります。

拠点追加時に設計すべきデータ集約と障害分離

拠点追加では、接続先を増やすだけでなく、サイトIDと機器IDの重複防止、時刻同期、通信断時の表示、データ保持期間、アラートの重複排除を考えます。中央アプリが止まっても各拠点を安全に運転・停止できるか、反対に拠点側が切断しても中央画面が古い状態を最新情報のように示さないかも確認します。

権限もサイト単位で分けると安全性を高めやすくなります。閲覧担当、現場担当、全社管理者が同じ書き込み権限を持つ必要はありません。中央からの一括操作は便利ですが、誤命令の影響範囲も広がるため、対象確認、段階適用、緊急停止を組み込みます。

AIエージェント連携の範囲と安全条件

AIエージェントはMCPエンドポイントから接続する

MDKはAIエージェントとの接続手段としてMCPを想定しています。MCPは、AIが利用可能なツールや入力形式を理解し、外部システムを呼び出すための接続方式です。MDKでは、独立したMCPエンドポイント、またはGatewayへ組み込まれたMCP面を通して、状態の読み取りや許可された操作へつなげます。

AIは、複数機器の状態をまとめる、異常候補を絞る、手順を提案するといった補助に使えます。しかし、判断の正しさは入力データ、ツール定義、権限、モデルの挙動に左右されます。AI連携という名称だけで、誤診断や誤操作が防がれるわけではありません。

契約情報からMCPツールを自動生成する配線は未完成

公式文書では、契約にAI向けの安全情報を記述できる一方、その契約からMCPツールを自動生成して接続する一連の配線は現時点で未完成とされています。将来像と現在利用できる実装を分けて読む必要があります。デモで一部操作ができても、任意のWorkerの全命令が安全なAIツールとして自動公開されるとは限りません。

評価時は、どのMCPサーバーを使うか、公開されるツール、入力値の検証、失敗時の表示、監査ログを実装単位で確認します。AIエージェントがGatewayの通常HTTP面を直接自由に使う設計ではなく、明示したMCP面と許可ツールへ絞ることが基本です。

書込み操作は許可範囲と人手承認で制御する

読み取りと書き込みは危険度が異なります。温度や状態の参照から始め、設定変更、再起動、停止など影響の大きい操作は、対象機器、値の範囲、時間帯、実行回数を制限します。提案はAIが作っても実行は人が承認する、あるいは小さな機器群で試して結果を確認してから広げる方法が考えられます。

公式のセキュリティ設計では、直接命令に対するKernel側の利用者権限確認を前提にできないため、Gatewayでの認証・認可が欠かせません。プロンプトや会話上の指示だけを安全境界にせず、許可リスト、強制的な入力検証、鍵管理、監査記録、停止手段をシステム側で実装します。

現行0.xは本番対応前：ロードマップと破壊的変更

10月末の実サイト試験は安定性保証ではない

公式ロードマップでは、2026年10月末に実サイト試験、同年12月末に1.0の本番対応を目指す段階が示されています。実サイト試験はモックだけでは見つけにくい通信、機器差、負荷、復旧の課題を確認する重要な工程です。しかし、試験を始めることと、あらゆる現場条件で安定性が保証されることは別です。

公開チュートリアルにはモック機器を使ったデモがあります。学習や接続確認には有用ですが、実ASIC、混在ファーム、長期負荷、回線障害、電源障害での耐久性を証明するものではありません。デモ成功を本番受け入れ試験の代わりにしないことが重要です。

0.5.0でも通信方式やWorker構造が変更された

0.xは、公開APIがまだ安定しない可能性を含む開発段階です。変更履歴には、0.5.0で通信方式をHRPCへ一本化する変更やWorker構造の再編など、既存実装の修正を要する破壊的変更が記録されています。これは開発が止まっているという意味ではなく、1.0へ向けて設計を固めている途中であることを示します。

0.xを先行評価する場合は、バージョンを固定し、依存関係の更新を自動で本番反映せず、変更履歴と移行手順を確認します。自社のGateway、Worker、UI、監視が新バージョンでどう影響を受けるかを検証環境で確かめ、戻せる手順を用意します。

2026年12月末の1.0は確定日ではなく目標

1.0の時期は2026年12月末の目標として示されています。予定どおり公開される可能性はありますが、試験結果による延期や仕様変更もあり得るため、確定した提供日として契約や移行日程へ組み込むのは早計です。公開後も、対象Workerや自社機器との組み合わせが同時に本番対応するとは限りません。

判断の節目は、単にバージョン番号が1.0になったかではなく、リリースノート、互換性方針、セキュリティ修正手順、対象Workerの状態、実サイト試験の結果がそろったかです。先行検証と本番採用を分け、ロードマップが更新されたら条件を再評価します。

本番導入前の確認対象と三段階判定

MDKの採用可否は参加社数ではなく、自社環境で再現できる証拠から決めます。次の表は必須条件を「確認対象／合格条件／見送り条件」に分けたものです。いずれかの見送り条件に当たる場合、直ちに全面導入せず、対象を狭めるか不足を解消します。

確認対象	合格条件	見送り条件
Workerと実機	対象モデル・ファームウェア・命令範囲が明示され、実機値と照合でき、保守窓口がある	Workerが未公開、対応版が不明、または主要な値・命令を実機で照合できない
版と変更追随	MDK、Worker、依存関係を固定し、検証環境、移行手順、ロールバックを用意できる	0.xを自動更新し、破壊的変更時の担当者・工数・復帰方法が決まっていない
認証・認可	役割・サイト・機器・命令・値の範囲をGatewayで強制し、権限外操作を拒否できる	共通資格情報を全員やAIで共有し、書き込み範囲を技術的に制限できない
障害と復旧	通信断前後の命令結果を確認し、古い値を識別し、安全停止と再開を演習できる	応答なしを未実行とみなして自動再送する、または現場の代替確認手段がない
複数サイト・AI	サイト間の障害を分離し、AIは許可ツールと人手承認の範囲内だけで動く	中央障害が全サイトへ波及する、またはAIが制限なく重要操作を実行できる

推奨条件は、長期負荷試験、段階配備、監査ログの定期レビュー、鍵ローテーション、担当交代時の訓練です。これらは一度の接続には不要でも、継続運用の事故確率を下げます。以下では、表の合否を決めるための試験方法を具体化します。

実機と混在ファームで長期負荷・障害試験を行う

• 対象を固定する：メーカー、モデル、ファームウェア、Worker、MDKの各バージョンを記録する。
• 読み取りを照合する：温度、状態、性能などを既存管理画面や実機値と比較する。
• 書き込みを限定する：検証用の少数機器から始め、値の上限・下限と反映結果を確認する。
• 負荷を継続する：短いデモだけでなく、想定台数と取得頻度で長期に動かし、遅延やメモリ使用を観察する。
• 障害を注入する：回線断、機器停止、遅い応答、不正な応答、GatewayやKernelの再起動を試す。

異なるメーカーを同時に扱うことがMDKの主要な価値なので、単一機種だけでなく実際の混在比率に近い環境で試します。モックは開発初期の確認に残しつつ、本番判定は実機結果と運用担当者の受け入れ確認に基づけます。

Gatewayの認証・認可とHRPC鍵を点検する

Gatewayでは、利用者とサービスの認証、役割別の認可、書き込み対象の許可リストを確認します。閲覧者が設定変更できないこと、あるサイトの担当者が別サイトを操作できないこと、AI用の資格情報が人間の管理者権限を持たないことを試験します。外部公開を最小化し、ネットワーク境界でも接続元を絞ります。

HRPCの鍵やAPI資格情報は、ソースコードや一般ログへ書かず、専用の秘密情報管理で保護します。発行、配布、ローテーション、失効、漏えい時の交換手順を決めます。誰がいつどの命令を要求し、承認し、実行結果がどうなったかを追える監査ログも必要です。

停止・再接続・未達命令の復旧手順を検証する

正常終了の手順と緊急停止の手順を分けて用意します。Gateway、Kernel、Worker、対象機器をどの順で止め、再開後にどの状態を確認するかを文書化します。通信が途切れた直前の命令について、未達、実行済み、結果不明を識別し、むやみに再送しないルールを置きます。

復旧試験では、古いテレメトリーを最新値として扱わないか、再接続した機器が正しいWorkerへ登録されるか、保留中の操作が意図せず実行されないかを確認します。中央監視が停止している間も、現場が安全状態を判断できる代替手段を残します。

Workerの更新責任と対応機種を確認する

最後に、Workerごとの責任者と保守条件を一覧化します。確認するのは、提供元、対応機種、ファームウェア、利用できる命令、更新頻度、脆弱性窓口、サポート終了、代替手段です。参加企業が保守を表明していても、自社が使う具体的なモデルと版が範囲に入るかは別途確認します。

概念実証では、まず読み取り専用で可視化し、次に限定した機器へ人手承認付きの書き込みを追加し、最後に障害訓練を行う段階的な進め方が安全です。現行0.xでは変更追随の工数も見積もり、1.0公開後に互換性と運用条件を再評価します。

PoCから本番へ進む三段階の最終判定

概念実証を「画面に値が出た」「一度だけ命令が通った」で終えると、本番運用に必要な条件を見落とします。開始前に合格条件を決め、技術面と運用面の両方で記録を残します。少なくとも、対象機器を誤認しないこと、状態値を許容時間内に取得できること、権限外の操作が拒否されること、障害後に安全な状態へ復旧できることを確認します。

性能の目標値は調査資料から一律に決められないため、自社の台数、監視頻度、回線、許容停止時間から定義します。例えば「速いはず」と評価するのではなく、必要なテレメトリーが自社の許容時間までに届くか、中央画面の遅延を現場担当者が識別できるか、監査記録を事故調査に使えるかという形で判定します。根拠のない台数上限や処理性能をMDK全体の保証値として扱わないことも大切です。

PoCへ進める：対象Workerと検証機があり、読み取り専用、隔離ネットワーク、版固定で試せる段階です。ここでは機能を広げるより、既存管理画面との値の一致、エラーの見え方、停止方法を記録します。

追加検証：値は取得できるものの、書き込み認可、混在ファーム、通信断後の結果確認、長期負荷、保守窓口のいずれかが未確認の段階です。未確認項目を責任者と期限付きで管理し、対象機器を増やしません。

限定本番へ進める：表の必須条件をすべて満たし、ロールバック、緊急停止、鍵失効、担当交代を含む演習に合格した段階です。最初から全拠点へ広げず、少数機器で監視期間を置いてから段階的に拡大します。

見送る：対象Workerが存在しない、権限外操作を拒否できない、結果不明の命令を安全に処理できない、復旧責任者がいない場合です。1.0という番号だけではこれらは解消しないため、条件が変わるまで本番書き込みを許可しません。

本番移行後も監視すべき変更点

採用後はMDK本体だけでなく、各Worker、機器ファームウェア、Gatewayプラグイン、MCP接続、依存パッケージの変更を追跡します。更新前に変更履歴とセキュリティ情報を確認し、検証環境で互換性を試し、承認後に段階反映します。参加企業が継続保守を掲げていても、更新の公開時期や対象版が自社の保守計画と一致するとは限りません。

運用レビューでは、拒否された操作、タイムアウト、再接続、古いテレメトリー、AIによる提案と人の承認結果を振り返ります。問題が起きなかったことだけでなく、安全機構が想定どおり働いたかを確認します。担当者の交代後も同じ手順を再現できるよう、判断理由と例外対応も記録します。これにより、MDKの共通化という利点を生かしながら、便利さのために制御境界を広げ過ぎることを防げます。

まとめ：Tether MDKは共通化の土台であり、完成済み統合製品ではない

Tether MDKは、Gatewayを外部との窓口、Kernelを配送と状態管理の中核、Workerを機器・プールごとの翻訳層として分離し、異種設備を共通の運用アプリへつなぐ基盤です。15社の参加は、接続エコシステムを広げるうえで重要ですが、全Workerの完成、現場配備、ネットワーク全体での採用比率を示すものではありません。

導入を検討するなら、現行0.xの破壊的変更、複数サイト集約の独自実装、Gatewayでの認証・認可、AI書き込みへの人手承認、切断時の復旧、Workerごとの対応範囲を確認します。まず限定環境で実機検証し、ロードマップ上の1.0公開と各Workerの成熟度を見て本番条件を再判定するのが現実的です。Bitcoinマイニング自体の基本から確認したい人は、マイニングの仕組みとプルーフ・オブ・ワークの解説も参考にしてください。