Zimaからのメッセージ
Bob、ZimaCubeとの時間を、従来のレビューよりはるかに有益なものへと変えてくださり、ありがとうございます。あなたの継続的な記録は、第一印象やハードウェアの分解から、ZimaOS、Windows Server、Proxmox、バックアップ、監視、AIエージェント、さらには仮想化ルーターに至るまで、マシンが役割を変えていく様子を追いながら、気に入った点も、ストレスを感じた点も同じ記録に残しています。このような長期的で率直な実験は、ZimaCubeで何ができるのかだけでなく、実際のホームラボの一部になった後に何が起こるのかを理解するうえで役立ちます。
— Zima
Bob Loves Techに会う
Bob Loves Techは、Windows、Linux、仮想化、ネットワーク、自宅運用、そしてそれらを支えるハードウェアまで、幅広い分野で活動するホームラボユーザー兼テクノロジークリエイターです。
彼とZimaハードウェアとの関わりは、このプロジェクト以前から続いていました。BobはZima Pioneer Programmeに参加する前から、ZimaBoardやZimaBladeをはじめとする以前のZima製品を使っていました。ZimaCubeが届いたとき、彼は洗練されたレビューを1本作って終わりにするのではなく、ZimaCube Experience Blogを作成しました。これは、彼のホームラボとともにマシンが変化するにつれて成長し続ける公開リポジトリです。
Bobはこれを、正式なレビューではなく継続的な記録だと説明しています。この違いが、プロジェクトの内容をよく表しています。ハードウェアへの最初の反応、開封後に発見したこと、試したオペレーティングシステム、周辺に構築したインフラ、そして数週間使った後に変化した結論が含まれています。
第一印象を超えてZimaCubeを記録する
Bobのプロジェクトの初期の記事は、ほとんどのハードウェア記事と同じところから始まります。マシンを開封し、ビルド品質を確認し、ポートやドライブ用キャディーをチェックし、ハードウェアを実際に机の上に置いたときに何が違って感じられるのかを見極めるのです。
しかし、この記録はそこで終わりません。Bobは実際に使い込んだ後もハードウェアを見直しています。彼のリポジトリには、専用のハードウェア概要、完全な分解記事、6週間後のフォローアップ、CPUコア数ではなくメモリが実用上のボトルネックになった理由を詳しく検証する記事、そして最終的にすべてのレビュアーが問うことになる疑問、つまり実際に自分のお金を出して買うのか？を扱った別の記事が含まれています。
この積み重ねが、プロジェクトを価値あるものにしています。第一印象からは、製品がどのような状態で届くのかがわかります。一方、継続的な記録からは、新鮮さが薄れた後に何が残るのかがわかります。
ハードウェアを開封し、細部を追う
ハードウェアに関する章の一つは、単純に分解すると題されています。これはBobのアプローチをよく表しています。
ZimaCubeを密閉されたNASアプライアンスとして扱うのではなく、彼は筐体を開けて内部を記録しました。そこには冷却システムや、マシンを保守・改造可能にすべきだと誰かが判断して初めて見える、小さなハードウェアの細部も含まれていました。
その分解作業は後に、記録の別のテーマへとつながります。6週間後に何が変わり、何が変わらなかったのかというテーマです。時間が経つにつれて重要性が薄れる観察結果もあります。一方で、冷却、ファンの動作、メモリ容量、アップグレードへのアクセス性、そして常時稼働環境におけるハードウェアの適合性などは、より重要になっていきます。
同じハードウェアについてさらに詳しく知りたい方は、ZimaCube分解ガイドで内部レイアウトとアップグレード方法をご覧いただけます。また、ZimaCubeの7つの巧妙な設計の特徴では、仕様表だけでなくシステムを開けて見ることで明らかになる詳細をより深く紹介しています。
CPUコアを増やすよりRAMが重要だと気づく
後半のハードウェアに関する記事の一つは、別のベンチマークグラフよりもはるかに有用な結論に達しています。Bobのワークロードでは、ZimaCubeに必要だったのはCPUコアの追加ではなく、メモリの増設でした。
彼の記録によると、10台のゲストが稼働している間もCPU使用率は約4％にとどまっていましたが、メモリ使用量は約27GBまで増加していました。これにより、ハードウェアの評価方法は変わります。実用上の最初の制限になったのはプロセッサーではなく、製品に搭載されていたメモリ構成でした。
マシンが徐々に仮想化ホスト、バックアップサーバー、監視ノード、ルーターVMホスト、AIの実験環境へと変わっていくと、メモリ容量は単なる仕様ではなく、インフラそのものになります。
これは、長期にわたるユーザーストーリーだからこそ明らかになる、まさにそのような結論です。CPUが理論上どこまでできるかを尋ねて導き出したものではありません。現実のワークロードが次々と積み重なった後のシステムを観察して得られた結論です。
ZimaOSを消去してWindows Server 2025をインストール
Bobのリポジトリで特に注目を集めた実験は、ZimaOSを削除し、ZimaCubeにWindows Server 2025を直接インストールしたことから始まりました。
Bobはこの組み合わせを奇妙な適合だと表現しています。だからこそ試してみたのです。このプロジェクトは、製品に付属するソフトウェア環境に依存せず、ハードウェアを検証する方法になりました。インストール時の挙動、ドライバー探し、ネットワーク、ストレージ、そしてコンパクトなNASプラットフォームを汎用Windowsサーバーのように扱った場合でも意味があるのかを確かめたのです。
この実験は、Zimaのハードウェアに対する重要な思想も示しています。ZimaOSを削除しても、そのマシンの有用性が失われるわけではありません。x86ハードウェアは、別のOSを中心に再構築できるプラットフォームとして残り続けます。
この実験を、より体系的なZimaCubeへのWindows Server 2025セットアップガイドにまとめました。同じ方向性を試したいユーザー向けに、インストール手順、Intelネットワークドライバーの対応、ストレージ構成を解説しています。
次へ進む前にZimaOSを公平に試す
Windows Serverは、OSに関するストーリーの一部にすぎません。BobはHomelab Journalで、専用のZimaOSレビューも執筆しています。
彼の結論は、意図的に「良い」か「悪い」かの二択よりも、ニュアンスに富んだものになっています。リポジトリでは、ZimaOSは小型デバイスに適した選択肢だとしながらも、仮想化やホームラボのインフラストラクチャへとZimaCubeをより深く活用していく場合、そのシンプルな体験が自分の求めるものと合っているのか疑問を呈しています。
この批判が有用なのは、Bobがセルフホスティングを初めて試す人としてZimaOSを評価しているのではないからです。すでに複数のシステムで構成されたホームラボを運用し、より低レイヤーの管理にも慣れているユーザーの視点から評価しています。
別のユーザーにとっては、シンプルさが使い続ける理由になるかもしれません。Bobにとっては、インフラストラクチャの複雑化が、最終的に離れる理由になりました。
同じトレードオフについては、私たちのZimaOS vs Proxmox vs Windows Server比較記事でも取り上げています。この記事は、同じ一連のより広範な実験から生まれました。
ホームラボの中心にProxmoxを据える
ほかの方向性を試した後、Bobは最終的に、ZimaCubeに導入したいOSについて、より明確な結論にたどり着きました。彼のホームラボには、Proxmoxが最も理にかなった環境でした。
このジャーナルでは、ZimaCubeがSynologyのNFSストレージと連携し、3ホスト構成の一部になっていく過程が記されています。この時点で、このマシンはもはや主にNASとして評価されているのではありません。インフラストラクチャになったのです。
この変化により、後の複数の記録への道が開かれます。Proxmoxが、バックアップインフラ、監視、AIサービス、ネットワーク仮想化に関する次の実験の基盤となるためです。
同じ基盤を構築したいユーザー向けに、ZimaCube + Proxmoxセットアップガイドでは、BIOSの準備からVM、LXCコンテナ、ストレージ、ネットワーク、パススルーまでの手順を解説しています。
インフラを中心にバックアップを構築する
マシンがインフラになると、次の問いは、さらに多くのサービスを実行できるかどうかではなく、そのサービスの1つが消えたときに何が起こるかです。
BobのBackupsという記録では、その移行を追っています。Proxmox Backup Serverが登場し、保護対象のシステム自体の一部でもあるインフラを、そのインフラを使ってバックアップするという、扱いの難しい循環的な問題も取り上げています。
その結果、単一の完璧なバックアップ先を見つけることよりも、復旧を予測可能なものにするレイヤーを構築し、Bobがバックアップについて常に考え続けなくても済むようにすることが重要になります。
その経験を基に作成したProxmox Backup Serverガイドでは、増分VM・コンテナバックアップ、保持、検証、追加の保護レイヤーという考え方をさらに詳しく説明しています。
常に確認するのではなく、フリートを監視する
ホームラボが数個のサービスを超えて成長した人なら誰もが抱く、Bobの次の疑問はこれです。1人に本当に必要な監視の量はどれくらいなのか？
彼のWatching the Fleetという記録では、PulseやProxmox Data Center Managerなどのツールを取り上げていますが、より興味深い目標は、インフラに必要な手動対応の量を減らすことです。
役立つ監視システムは、一日中見続ける必要のある別のダッシュボードを増やすべきではありません。通常時は静かに稼働し、本当に対応が必要なときに障害を明確に知らせるべきです。
そのBobの体験をさらに掘り下げたホームサーバー監視ガイドでは、Pulse、Uptime Kuma、Proxmox Data Center Managerに加え、監視がメンテナンスを増やすのではなく減らすべきタイミングについて解説しています。
AIエージェントに恒久的な居場所を与える
このジャーナルはやがて、セルフホスティングの別の層へと進みます。それは、ZimaCube上で常駐AIエージェントを実行することです。
Hermes AgentをZimaCubeで動かす理由では、Bobがこのマシンを単なるストレージや仮想化基盤としてではなく、セルフホスト型エージェントが常時稼働する場所として捉えています。
この組み合わせは、これまでの流れを踏まえると自然です。ZimaCubeがすでに常時オンラインでホームラボに接続され、バックアップと監視も行われていれば、エージェントはノートパソコンのセッションに縛られない、常駐サービスの一つになれます。
このワークフローをZimaOS上で直接試したい場合は、ZimaOS向けHermes Agentセットアップガイドで、インストール、モデル設定、メッセージング連携、Hermesダッシュボードへのアクセス方法を説明しています。
ZimaCubeをOPNsenseルーターに変える
後半で行われる最も興味深い実験の一つでは、マシンが再びまったく異なる役割、つまりネットワークインフラへと変わります。
BobのOPNsenseジャーナルでは、ZimaCubeのデュアル2.5GbEインターフェースをProxmoxと組み合わせ、ルーターVMがこのハードウェアの最も有力な用途の一つになり得るかを検証しています。
ここで、先に行ったオペレーティングシステムの選択が活きてきます。Proxmoxを使えば、従来なら別々の筐体が必要だったワークロードを同じ物理マシン上でホストできます。また、2つのEthernetインターフェースにより、仮想化ファイアウォール環境でWANとLANを分離する自然な構成が可能になります。
Proxmoxガイドでは、ZimaCube上でOPNsenseをソフトウェアルータVMとして実行する方法も取り上げています。これには、別々の2.5GbEインターフェースをネットワークアプライアンスに割り当てる方法も含まれます。
価値は最終的な結論ではなく、記録にある
全体として見ると、Bobのプロジェクトは、結論が固定されたレビューよりもはるかに興味深いものです。
同じZimaCubeが、リポジトリの存続期間を通じてさまざまな形で登場します。
新しいハードウェアとして始まります。 Bobは箱から取り出し、構造を確認し、シャーシを開け、冷却について疑問を持ちながら、アップグレードについて考え始めます。
Windows Serverの実験になります。 ZimaOSを削除し、付属ソフトウェアなしでも基盤となるハードウェアが役立つかを検証します。
オペレーティングシステムの問題に戻ります。 Bobは、環境がますます複雑になり別のものが必要だと判断する前に、ZimaOSについて独自に評価します。
Proxmoxホストになります。そこからマシンはより大きなフリートに加わり、インフラの責任を次々と担うようになります。
バックアップと監視のシステムの一部になります。Proxmox Backup Server、Pulse、フリート管理によって、目標は「サービスを追加し続ける」ことから、「サービスを十分に安定させ、存在を意識しなくて済むようにする」ことへと変わります。
そして、AIホストとネットワークアプライアンスになります。Hermes AgentとOPNsenseは孤立した実験ではありません。以前のインフラ層がすでに整っているからこそ可能になっています。
その結果は、Bobが当初約束していたものそのものです。正式なレビューではなく、メモや実験、経験に応じて変化する意見、そしてますます意欲的になる一つのホームラボプロジェクトです。
一人のユーザーストーリーがZimaCubeガイド集に
Bobのプロジェクトは、長期的なコミュニティテストが、個人のホームラボを超えた価値を持つ理由も示しています。
ZimaCube Experience Blogで記録された複数の実験は、その後、より詳しいZimaリソースへと発展しました。Windows Serverのインストール、Proxmoxの導入、オペレーティングシステムの選択、バックアップアーキテクチャ、ホームラボの監視などです。
これにより、コミュニティの体験とドキュメントの間に有用な循環が生まれます。Bobは好奇心から何かを試します。記録には何が起きたのかが残ります。役立つ部分は、次の人が再現しやすい形になります。
物語は今も書き綴られている
Bob Loves TechとZimaの物語は、今も書き綴られています。彼のZimaCube Experience Blogは、開封とハードウェア分解から始まり、ZimaOS、Windows Server、Proxmox、バックアップ、フリート監視、Hermes Agent、OPNsenseへと発展してきました。そして、継続的な記録の本質は、最終構成を決める必要がないことにあります。
ホームラボが変化すれば、ZimaCubeの役割もそれに合わせて変わります。Bobが次に何を試すのか見てみたい方は、GitHubで継続中のZimaCube Experience Blogをフォローしてください。
