みなさん、こんにちは。
Haiku R1/beta5 から約2年。2026年8月26日にHaiku R1/beta6が無事にリリースされました！
さっそくインストールして触ってみたのですが、やっぱり Haiku は「軽い・速い・構造がシンプル・リアルタイム性が高い」の四拍子が揃っていて最高です。
そして今回、特に注目したいのがNVMM（NetBSD Virtual Machine Monitor）仮想化のサポートです。これが入ったことで、「複数の小型OSを並列で動かすホストOS」としての可能性が一気に広がった気がしています。
Haikuって、IoTオーケストレーションOSとして最適なのでは？
そう考えたのが、今回の記事の出発点です。
実は以前から、「HaikuをIoT端末として使えないか？」という可能性を探っていました。
しかし、NVMMによるハードウェア仮想化が使えるようになったことで、単なる端末としてではなく「IoT端末（子機）を取りまとめる親機（オーケストレーションOS）」として使ったら面白いのではないか、という構想がひらめきました。
HaikuをIoTオーケストレーションOSとして見たときの強みは、主に次の4点です。
- OS構造が圧倒的にシンプルで軽量
Linuxのようなsystemd・udev・dbusといった巨大なサブシステムがありません。かといってFreeBSDのようなサーバー向けの重厚さもなく、基本は単ユーザー向けで構造がすっきりしています。リアルタイム性も高く、仕組みを把握しやすいのは親機として理想的です。 - NVMM仮想化で複数のRTOSを高速起動できる
R1/beta6でQEMUがハードウェア仮想化に対応したため、複数のRTOS（リアルタイムOS）を同時に立ち上げて制御・連携させる構成が、現実味を帯びてきました。 - BFS（メタデータFS）がログや状態管理に強い
IoT運用では大量のログデータやセンサー値を取り扱いますが、Haikuのファイルシステム「BFS」はファイルそのものをデータベースのようにメタデータ管理・検索できます。高速に分類・検索ができるため、運用が非常にラクになります。 - GUIがOSに統合されている
app_serverがOSのコアと一体化して動作するため、IoT全体の動態を管理・可視化するダッシュボードなどのUIを、非常に軽量かつスピーディーに作成できます。
じゃあRTOSを2つ立ち上げて通信させてみよう
この強みを活かして、さっそく次のような実験をしてみることにしました。
- Haiku をホストOSとして動かす
- Haiku上の QEMU（NVMM） で FreeRTOS を2台起動する
- 2台のFreeRTOS間で UDP/TCP通信 を行わせる
- Haiku側でそのログを集約してオーケストレーションする
「これが動いたらめちゃくちゃ面白いぞ！」とワクワクしながら作業を開始。
検証に使うボードのターゲットには、FreeRTOS公式デモでも広く使われている lm3s6965evb を選定しました。選んだ理由は、「FreeRTOS公式のQEMUデモがこれを使っているから」です。
しかし、ここで大きな落とし穴にハマる
arm用QEMUをインストールし、lm3s6965evbターゲットを指定して2台分を実行すると、FreeRTOS自体は何の問題もなくスムーズに起動しました。
画面には以下のようなログが出力されます。
Timer with period zero, disabling
これはエラーではなく、FreeRTOSが正常にアイドル状態に入ったことを示す正しい動作です。よしよし、ここまでは順調だな！
しかし、通信がまったくできない……！
問題はここからです。ネットワーク設定を見直したり、QEMUのネットワークオプションをいろいろ変更してみたりしても、FreeRTOS側がNIC（ネットワークカード）をまったく認識してくれません。
「設定が間違っているのかな？」とあれこれ調査を進めた結果、衝撃の事実が判明しました。
lm3s6965evb の QEMU Ethernet は「未実装」だった
なんと、FreeRTOS+TCPがアクセスしようとしている Ethernet レジスタ類が、QEMU側の lm3s6965evb エミュレーションではそもそも実装されていなかったのです。
さらに追い打ちをかけるように……
- FreeRTOS公式の
lm3sデモは「ネットワーク非対応」の設計だった
つまり、lm3s6965evbの環境では FreeRTOS+TCP は絶対に動きません。
どれだけ設定を頑張ろうが、どれだけ試行錯誤しようが通信は起きない仕様だったわけです。努力でどうこうできる問題ではありませんでした……（泣）。
正しい解決策は「RISC-V + QEMU virt」に乗り換えること
じゃあどうすればいいのか？ 調べていくと、正解が見つかりました。
FreeRTOSでは、RISC-V + QEMU virt 環境向けに、FreeRTOS+TCP がしっかり動く公式デモを提供してくれています。
QEMU virtは Ethernet エミュレーションが完全実装されている- FreeRTOS+TCP がそのまま動作する
- UDP/TCP 通信が普通に使える
- 2台の FreeRTOS をソケットで接続すれば、相互通信が可能
- もちろん Haiku上（NVMM環境） でも問題なく動作する
というわけで、「ネットワーク通信をさせたいなら lm3s6965evb は諦めて RISC-V + virt に移行する」 のが唯一かつ最高の解決策でした。
今回の学び
今回の検証を通して得られた知見をまとめます。
- Haikuは「IoTオーケストレーションOS」として本当に優秀
軽量・シンプル・リアルタイム性・仮想化サポート・強力なメタデータFSという組み合わせは、他のOSにはない唯一無二の魅力です。 - FreeRTOSのlm3s6965evb QEMUデモはネットワーク非対応
「とりあえず起動させてみる」ためのデモ環境であり、通信機能は備わっていません。ハマりやすいポイントなので要注意です。 - 仮想環境でFreeRTOS通信を行うなら RISC-V + virt 一択
FreeRTOS+TCP を素直に動かしたい場合は、最初からvirtプラットフォームを選択しましょう。
挑戦は次回に続く…
Haiku R1/beta6 を触ってみて、「IoTの親機（オーケストレーションOS）としての可能性」がいよいよ現実的なものとして見えてきました。
lm3s6965evbのネットワーク未実装という罠には見事にハマってしまいましたが、そのおかげで FreeRTOS の正しいベスト構成（RISC-V + virt）に辿り着くことができました。
次回は、Haiku上で複数の FreeRTOS（virt）を実際に起動し、それらをHaiku側で一元管理・オーケストレーションする環境を構築してみようと思います。
この構成がしっかり完成すれば、Haikuは「IoT親機OS」の有力な選択肢になるはず。乞うご期待です！
「自分も何か作ってみたい」と思われた方、そのアイデア、頭の中で寝かせておくのはもったいないかもしれません。
ビューローみかみでは、構想段階の壁打ちからPoC・実装・現場導入まで、現場で「使い続けられる」ものづくりを支援しています。
アイデアを短期間で「動くもの」にし、PoCで終わらせず、実運用まで伴走します。まずは「これ、作る価値ありますか？」という壁打ちからでも大歓迎です。
▶ PoC・MVP開発サービスの詳細はこちら
気になることがあればお気軽にご相談ください。
本日も最後までお読みいただきありがとうございました。
それでは、よいHaikuライフを！
