ASUS ROG Flow Z13:携帯性を保とうとしなかった私のポータブルホームラボ
- カテゴリ
- AIとローカルLLM
- 公開日
- 2026年7月30日
- 更新日
- 2026年9月16日
- 著者
- Jacob Lloyd — プロジェクト完了後、AIの支援を受けて執筆
- 読了時間
- 約16分で読めます
かんたんに言うと: 私はメインのコンピュータおよびホームサーバーとして、ASUS ROG Flow Z13というゲーミングタブレットを使用していました。この機器でAIモデルを実行したり、ウェブサイトをホストしたり、開発環境全体を維持したりしていました。ところが、電源に不具合が生じるようになったのです。毎回、電源を入れるとロゴ画面でフリーズし、30秒ほどで自動的にスリープ状態になってしまうのです。以下が、正常時に行っていた作業内容、具体的な故障の様子、そしてこの不具合が私が修正できるソフトウェア上の問題ではなく、ハードウェア側の問題であると判断した経緯です。
ASUS ROG Flow Z13は、もともとサーバーとして使うための製品ではありませんでした。取り外し可能なキーボードやRGBライトバーを備えたゲーミングタブレットであり、AAA級のゲームを十分な設定でプレイできるほどのGPU性能も持っています。私は2026年2月に開封済み品を購入し、ポータブルワークステーションとして利用しようと考えました。つまり、バッグに入れて持ち運び、自宅でドックに接続してあらゆる作業に使えるマシンとしてです。5ヶ月間、まさにその通りに機能してくれ、サイズが2倍もあるハードウェアよりも優れた働きを見せてくれました。
その後、電源に不具合が生じ、それ以降は起動できなくなってしまいました。
更新情報:2026年9月16日 私が利用しているOpenClawのエージェント群は、その後6つにまで統合されました。以下に記載されている「8つのエージェント」という数値は、当時このマシンで実際に稼働していた状況を表しています。
要約
- 使用していた機器: ASUS ROG Flow Z13(2025年モデル、GZ302EA)。13インチのゲーミングタブレットで、128GBの統合メモリを備えていました。私にとってはAIサーバー、開発用マシン、そして家庭内ネットワークのハブとしても活用していました。
- 実行していた内容: 1200億パラメータ規模のモデルをローカルで実行したり、8つのエージェントから成るOpenClawスタックを動かしたり、自宅用のチャットアプリや自分で作成した各種ウェブサイトも運用していました。
- 故障の原因: 電源系の不具合です。電源を入れるとROGのロゴ画面で止まり、約30秒後に内蔵コントローラーがスリープ状態に移行してしまいます。冷たい状態からの起動時でも、再起動時でも同様です。BIOS画面にすら到達できません。
- なぜ修復不可能なのか: ブートローダーが起動する前に不具合が発生するため、ディスク上のデータには影響がありません。したがってOSの再インストールも効果がありません。これはマザーボードレベルの故障です。
- 現在の状態: SSDを取り外した状態で棚の上に置いてあります。保証請求などは行わず、ドライブを抜き取って別の機器へ移行しました。
- 後継機器: CHUWI AuBox Ai365ミニPCを使用しています。メモリ容量は前機器の4分の1程度ですが、全く同様の不具合は発生していません。
詳細仕様
| 構成要素 | 仕様 |
|---|---|
| モデル | ASUS ROG Flow Z13(2025年モデル)— GZ302EA |
| CPU | AMD Ryzen AI Max+ 395 “Strix Halo” — 16コア/32スレッド、最大5.1 GHz、キャッシュ容量80 MB |
| GPU | AMD Radeon 8060S — RDNA 3.5、統合型、計算ユニット数40個 |
| NPU | AMD XDNA — 最大50 TOPSの処理能力 |
| メモリ | 128 GB LPDDR5X-8000、はんだ付け済み(CPUとGPUで共有) |
| ストレージ | 1 TB PCIe 4.0 NVMe、M.2 2230規格 |
| ディスプレイ | 13.4インチ、2560×1600解像度、リフレッシュレート180 Hz、タッチスクリーン |
| バッテリー | 70 Wh |
| ポート | USB4 Type-C×2、USB 3.2 Type-A×1、HDMI 2.1、microSDカードスロット、3.5 mmコンボジャック |
| 無線機能 | Wi-Fi 7、Bluetooth 5.4 |
| 重量 | 約1.2 kg(タブレット単体時)/約1.5 kg(フォリオキーボード装着時) |
| OS | 出荷時はWindows 11がインストールされていましたが、使用期間中はBazzite(Fedora Atomicベース)が利用されていました |
| 特記事項 | 各キーにRGBバックライト付きの着脱式フォリオキーボード、エッジライトバー、スタイラス対応 |
最も注目すべき数値は128 GBというメモリ容量です。CPUとGPUで共有されるLPDDR5Xメモリであるため、そのうち64 GBをVRAMとして割り当てても、残りの64 GBはオペレーティングシステム用に利用可能となります。2026年初頭時点では、片手で持ち運べるサイズでありながらこのようなことができる機器は他に存在しませんでした。
日々実行されていた処理について
ローカルで動作する120Bパラメータのモデル
メモリこそがこのタブレットの最大の強みです。64GBものVRAMが搭載され、ROCmによってRDNA 3.5ベースのiGPUが駆動しているおかげで、私はこのタブレット上で1200億パラメータを持つモデルを実行することができました。速度はゆっくりではありますが、バックグラウンド作業用として十分に使えるレベルです。より小規模なモデルであればさらに快適に動作します。例えば300億パラメータのMoEモデルなら、1秒間に約70トークンの速度で処理できるので、対話型利用にも問題ありません。
その機能が、私が構築したシステム全体の基盤となりました。私のエージェント群の中には、一切クラウドAPIにアクセスしない階層も存在しました。大量処理や夜間処理、そして社内から外部に出してはいけない処理などはすべてローカルモデルで実行され、かかるコストは電気代のみでした。 8つのエージェントからなるOpenClawの構成や AIエージェントの実際のコスト内訳も、この階層が存在することを前提としています。なぜなら、私のマシン上では確かにその階層が存在したからです。
開発とホスティング
私が管理しているすべてのサイトは、本番公開前にここで作成・構築・プレビューされていました。このサイトも同様です。USB4ポートにより4Kモニターやドックを接続できたため、同じタブレットが約4秒でデスクトップワークステーションへと変身したのです。
常時稼働型インフラストラクチャ
このマシンでは、Tailscaleを自宅ネットワークの基盤として利用し、さらに複数のsystemdサービスを組み合わせることで、あらゆる機器同士が通信できるようにしていました。常に電源が入っており、常に接続状態で、常にある程度の負荷がかかっている状態でした。この最後の点が、この話の結末に関わってくるのです。
非常に優れていた点
- 128 GBの統合メモリ。 この仕様だけでも、Z13を他機種とは一線を画す存在にしていました。タブレット上で1200億パラメータ規模のモデルを実行するというのは今でも少し現実離れしているように感じますが、当時はこれに匹敵する携帯性を持つ機器は他に存在しませんでした。
- Linuxとの互換性。 Windows 11から Bazzite へ移行してから、すべてがスムーズに動作するようになりました。ASUS Aura HIDプロトコルもhidraw経由で問題なく機能し、ROCm によってiGPUも適切に制御されました。また、systemdのユニットがWindowsのバックグラウンドプロセスすべてをより洗練されたものに置き換えてくれました。
- フォームファクター。 ソファでタブレットとして使い、ドックに接続すればデスクトップにもなり、モニターの後ろではヘッドレスサーバーとしても利用可能。すべてが同一のマシンでありながら、数秒で切り替えられるのです。フリップ式キーボードも実に優秀で、キーストロークも十分で歪みもありませんでした。
- GPUの性能。 RDNA 3.5アーキテクチャを採用した40基のコンピュートユニットにより、CAD作業やローカルでの推論処理、軽めのゲームも問題なくこなせました。まさに統合グラフィックスとは思えない性能でした。
不満な点
- 長時間の負荷時の発熱対策。 薄型の筐体には熱を逃がすための手段が一つしかありませんでした。それはファンを高速回転させることです。長時間にわたって処理を続けると、筐体が非常に熱くなり、手で持つのも不快なほどになりました。
- 複合負荷時の電力供給。 充電はType-Cポート経由のUSB-PD方式です。CPUとGPUを同時にフル稼働させると、充電器が供給できる以上の電力が必要になるため、充電中でもバッテリー容量が減少してしまうのです。つまり、バッテリーから電力を補給することでようやくバランスが取れる仕組みでした。
- Linux環境でのバッテリー持続時間。 WindowsではASUSのファームウェア調整により6〜8時間ほど使用できました。一方Linuxでは良い日でも3〜4時間程度しか持ちませんでした。また、取り外し可能なキーボードを使った際のサスペンド/復帰処理もudev関連の問題を頻発させる原因となりました。
- 修理が難しい構造。 RAMは半田付けされており、筐体も密閉されています。キックスタンド部分の蓋を開けることでアクセスできるM.2 SSDだけがユーザーが交換可能な部品です。実際、このSSDのおかげで何とか事なきを得ました。
RGBキーボードプロジェクト
ASUS製のArmoury Crateは、キーボードやライトバーのRGB設定を制御するための公式ツールですが、Linux上では利用できません。そこで私自身でツールを作成しました。PythonベースのCLIプログラムがAura HIDインターフェースと直接通信し、GTK4を用いたカラーピッカーやlocalhost上で動作するブラウザパネルも備えています。全体のサイズは約40KB程度で、スリープ状態からの復帰や再起動、キーボードの取り外しにも対応しています。これらは他のLinux用RGB制御ツールでは実現できていない機能です。
この記事は当サイトで最も読まれている記事のひとつとなりました。RGBキーボードに関する記事全文を読む →
経緯:電源関連の不具合
2026年7月19日から20日にかけて、Z13が起動しなくなりました。2日間かけて調査しましたが、私の手では修復不可能だと判断しました。この不具合は非常に特徴的であるため、きちんと記録しておく価値があります。というのも、「電源が入らない」という表現はコンピュータ関連では最も役立たずな表現であり、今回のケースではそれすら正確ではなかったからです。実際には電源は入るのですが、起動状態を維持できないだけでした。
症状の順序
- 起動中にROGロゴで停止する。アニメーションではなく、静止画の状態です。「F2を押せ」というプロンプトにも到達せず、BIOSやブートローダーにも進めません。試行ごとに状態が異なりました:時にはバックライトが消えた画面、時にはファンだけが回っている黒い画面、またある時は前述の静止したロゴが表示されるだけでした。
- 起動時にフォリオキーボードが反応しない。再起動時にバックライトが白く点滅しますが、その後は何も反応しません。F2、Esc、Delキーも一切受け付けません。これはこのモデル特有の不具合で、キーボードコントローラーがブートローダーモードに固定されてしまう現象です。
- POST中にUSBバス電源が供給されない。ロゴ表示中に外付けのRGBキーボードを接続しましたが、ライトも電力も一切ありませんでした。POSTのその段階ではポートは正常に動作すべきなのですが、実際にはそうではなく、これはOS側の問題ではなく組み込みコントローラーの電源管理機能が不調であることを示しています。
- 熱異常が発生している。画面もファンも停止した状態で、AC電源に接続されたまま筐体が非常に熱くなっているのを確認しました。この組み合わせは異常を示唆するものです:SoCがクラッシュ状態のまま電力を消費しており、ファン制御が機能していなかったのです。強制的に冷却した後、外部ファンを使っても筐体温度は約96°Fまでしか下がらず、これが通常状態ではなく異常な熱だと確認できました。
- 決定的な証拠:静止画の下でスリープLEDが点滅している。ECリセット後、電源LEDが約1秒点灯して5秒消灯するパターンになりました。ASUSの仕様によれば、このパターンはノートパソコンがスリープ状態にあることを意味します。しかし実際にはPOSTロゴが画面に表示されているため、機械が同時にスリープ状態であるはずがありません。この矛盾こそが診断の鍵となります。
- 再現性がある。起動後、30秒ほどLEDが白く点灯し続けた後、再びスリープ時の点滅パターンに戻りました。コールドブートを繰り返しても常に同じ結果でした。
つまり、POST初期段階でファームウェアがハングし、組み込みコントローラーがその下でModern Standby状態へ移行させ、ディスプレイコントローラーが最後に表示された画像を保持したままになっているのです。静止したロゴは機械が何かを考えているわけではなく、単にスリープ中のコンピュータに残された静止画像に過ぎません。
私が試したこと
- 強制再起動や標準的なリセットを繰り返し実施。
- EC/RTCのハードリセット:AC電源接続状態で電源ボタンを40秒間押し続ける方法、およびAC電源を一度切断してから再接続する方法。このプラットフォームではこれらはCMOSバッテリーを外すことと電気的には同等の処置です。
- 周辺機器をすべて取り外し:キーボードを外し、microSDカードも抜き取り、すべてのUSB-CおよびHDMIケーブルを外してタブレット単体として起動させる。
- リセット後、128GBものメモリ再構成や未処理のファームウェア更新が必要な可能性を考慮し、45〜60分間何もせず待機。
- フォリオキーボード(反応なし)、外付けUSBキーボード(ポートに電力なし)、ボリュームダウン+電源ボタンのいずれでもBIOSへのアクセスを試みる。
- 完全に冷却した後、コールドブートから再テストを行う。
私は物理的にCMOSバッテリーを外す処置は行いませんでした。40秒間の電源ボタン長押しで既に同等のリセットが行われており、またそれだけではECの不調や電源供給系の問題は修復できないからです。またOSレベルの対処も行いませんでした。その理由は以下の通りです。
除外できた原因とその根拠
| 疑われる原因 | 判定 | 理由 |
|---|---|---|
| ソフトウェア/OS/カーネル引数 | 問題なし | ハングはブートローダーが読み込まれる前に発生しているため、ディスク上の設定が原因である可能性は皆無です。 |
| 起動デバイス/SSD | 問題なし | USB電源の不調や「クラッシュ→スリープ」という現象はストレージ層よりも上位で発生しています。後日SSDを取り外して確認したところ正常で、現在は代替機で使用中です。 |
| 熱によるシャットダウン | 問題なし | コールド状態かつ約96°Fの環境でも同様の不具合が再現されます。 |
| バッテリー切れ | 問題なし | 点滅しているのは白いスリープパルスであり、オレンジ色の低電力インジケータではありません。 |
私の機体だけの問題ではない
これは単なる個体不良ではなく、このモデルにおける公知の不具合クラスです。ROGフォーラムにもGZ302EAで同様の現象が報告されており、「Modern Standbyに関連した黒い画面のままハングする現象」が記載されています。また、Linux環境下でフォリオキーボードのコントローラーがブートローダーモードに固定される事例も広く知られており、これらはすべて私が経験した状況と一致します。
もしあなたのZ13でも同じように静止したロゴが表示されているなら、電源LEDがゆっくり点滅し始めるまでの時間を計ってみてください。30秒前後であれば、これと同じ不具合である可能性が高く、どれだけ再インストールを繰り返しても解決しないでしょう。
2日間のトラブルシューティングで得られたもの
問題の解決ではありませんでした。得られたのは確信です――「壊れてしまった、自分が何かやってしまったのかも」という曖昧な状態から、「どの部品が故障したのか正確に分かり、どれだけ時間を費やしても直らない」という確実な認識へと変わったのです。その根拠となる事実は以下の5つです。
- 冷蔵状態からの起動時でも、再起動後でも、約30秒でスリープ状態に突入する現象が再現可能である。
- フリーズしたPOSTロゴと同時にスリープ状態を示すLEDが点灯している。正常なマシンではあり得ない状態だ。
- 熱異常が発生していた:筐体が高温で、ファンは停止しており、AC電源接続中にもかかわらずクラッシュ状態だった。
- POST中にUSBバスからの電力供給が行われていなかった。
- このモデル特有の不具合として、他のユーザーのマシンでも全く同じ現象が起きているという報告がある。
最後の点が私の気持ちに最も影響を与えました。機械が壊れるとつい自分自身を振り返ってしまいます――設定したカーネル引数や実行したアップデート、一晩中コンパイルさせていた処理などです。しかしメーカーのフォーラムで他の人々も同じ30秒間の現象について書き込んでいるのを確認し、その疑念は晴れました。その結果、使用をやめるという決断が容易なものとなりました。
私は保証請求は行いませんでした。その機器は開封済み品だったため、手続きを進めれば実際に必要なマシンが数週間使えなくなってしまう可能性があり、すでに代替品も注文済みだったからです。そうしてZ13はSSDを取り外した状態で棚の上に置かれています。そのSSDはキックスタンド用の開口部から取り出され、新しいマシンの箱の中へ直ちに収められました。この開口部こそが、最終的に役立った唯一の設計点だと言えます。
タブレットをサーバーとして使う方へ伝えたいこと
私はZ13に怒ってはいません。これまでのどのタブレットよりも多くのことをやってくれ、5ヶ月間も文句ひとつ出さずに動き続けてくれました。しかしこの失敗から得られる教訓が実際には存在します。それは「消費者向けハードウェアは悪い」ということではありません。
要点は、バッテリーを中心に作られた機器には、充電・放電・スリープ・復帰を行うための電力管理用状態遷移機構が備わっているということです。これをサーバーとして使う場合、数ヶ月間ずっと電源に接続されたままで、温かい状態で、決してスリープしない状態に保つことになります。これはファームウェアが想定していた負荷条件ではなく、最終的に起きた不具合もCPUの故障やディスクの容量不足ではなく、電力管理機能の不具合でした。
実用的なアドバイスとしては、常時稼働型のインフラとして使うなら、バレル型コネクタとファンを備えた機器を選ぶべきです。また、万が一その機器が故障してもデータが失われないよう、別の場所にデータを保存しておくことも大切です。今回の話が良い結末を迎えられたのは、SSDがはんだ付けされた回路の奥ではなく、取り外し可能なドアの後ろにあったからに他なりません。
代わりとなった機器
後継機として選んだのはCHUWI AuBox Ai365です。これはRyzen AI 9 365を搭載した小型のAMD製ミニPCで、2つの2.5 GbEポートやバレル型電源コネクタも備えています。Z13の128GBに対し、こちらは利用可能なメモリが30GBしかなく、そのせいで大規模なローカルモデルの運用が不可能になりました。そこでローカル処理用の部分は別のGPUボックスに移行し、主要なエージェントの運用も定額制のクラウドプランへ切り替えました(詳細はコスト内訳をご覧ください)。その代わりに、バッテリーがなく、USB-PDのネゴシエーションも不可、Modern Standby機能も搭載していないため、予期せぬクラッシュの心配もありません。
CHUWI AuBox Ai365のセットアップについて読む →
関連記事:CHUWI AuBox Ai365:箱の中に収まった私のAIホームラボ · Linux上でASUS ROG Flow Z13のRGBキーボードを制御する方法 · 1台のミニPCで運用する小規模なAIエージェント群:私のOpenClawスタック · AMD環境でのローカルAI画像生成:ComfyUIとZ-Image Turboの組み合わせ · 私のAIエージェント運用にかかる実際のコスト:DeepSeekと大手APIの比較