OM1 を採用する前に読む: Go ランタイム、Zenoh 前提、OMCU 課金という三つの制約
Modular AI HAL (Hardware Abstraction Layer) for Robots
ひと目でわかる
- これは何？
- OpenMind の OM1 はロボット向けのモジュラー AI ランタイムで、Go 実装と Python 実装が併存する。入力から LLM、行動までのパイプラインは読めるが、公開情報だけでは判断できない部分も多い。何が確認できて、何が確認できないかを分けて整理する。
- 誰に向いている？
- 音声とカメラで動く会話エージェントを最短で試したい個人開発者、あるいは ROS2 や Zenoh 経由で実機を繋ぐ実験を素早く回したいチームには向く。逆に、Python 資産を前提にした既存コードの移行先としては勧められない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
OM1 が埋めようとしている溝は「ロボットごとの作り直し」
ロボットのソフトウェアを書くとき、厄介なのは知能の部分そのものより、入力と出力の配線である。カメラ、マイク、LIDAR といった入力の形式は機体ごとに違い、モーションや音声出力の叩き方も違う。OM1 はこの配線を抽象化し、同じエージェントのロジックをヒューマノイド、四足歩行、TurtleBot 4 のような教育用ロボット、あるいは Gazebo や Isaac Sim のシミュレータ上で動かすことを狙っている。README の表現を借りれば、目的は「異なる物理形状に対応できるよう簡単にアップグレードと再設定ができる、人間中心のロボット」を作りやすくすることだ。対象読者は、LLM を使ったロボット制御を試したい開発者と、複数の機体で同じエージェント資産を使い回したいチームである。Web データやソーシャルメディアの入力も扱えるとされており、物理ロボット専用というより、マルチモーダルなエージェントランタイムとして設計されている。
Go 版と Python 版が併存し、片方は終わることが決まっている
このプロジェクトで最初に把握すべき事実は、ランタイムが二つあることだ。OM1 は元々 Python で書かれ、Go 版は後発の実装である。Go に移った理由として README は低レイテンシ、性能、並行処理の効率、エッジデバイス向けの小さなメモリフットプリント、そして単一バイナリとしての配布のしやすさを挙げている。Zenoh の C ライブラリを同梱する形になっている点も、単一バイナリ配布という設計と整合する。
重要なのは移行の非対称性だ。README は「Go ランタイムはコアのエージェントパイプラインをカバーするが、Python ランタイムにある機能のいくつかはまだ活発に開発中である」と述べ、同時に Python 版について「非推奨であり、保守されない」と明記している。つまり新規開発は Go を選ぶしかないが、Go 側が Python 側の機能をまだ全部持っていないという過渡期にある。ここは採用判断で最も注意が必要な点で、README はどの機能が未実装なのかを列挙していない。自分の用途が該当しないかは、ドキュメントかソースを直接確認するしかない。
入力から行動までの流れと、プラグインで吸収する境界
アーキテクチャの骨格は README の記述から読み取れる。エージェントは Web データ、ソーシャルメディア、カメラ映像、LIDAR といった多様な入力を処理し、モーション、自律ナビゲーション、自然な会話といった物理的な行動を出力する。クイックスタートで使われる conversation エージェントは、Web カメラとマイクから視覚と音声を取り込み、モデルが応答を生成し、音声で返す。README はこれを「入力、LLM、行動のフロー」と表現し、状態の更新をターミナルに可視化すると説明している。
ハードウェアとの接続はプラグインで抽象化される。ROS2、Zenoh、CycloneDDS 向けのプラグインがあり、README は新規開発では Zenoh を推奨すると明言している。推奨が一つに絞られている点は評価できる。ミドルウェアの選択肢を三つ並べたうえで「どれでもよい」と逃げていないからだ。ただし、ROS2 資産が既にある読者にとって Zenoh 推奨は移行コストを意味する。この推奨が技術的な理由によるものか、OpenMind 側の実装の重心によるものかは、README からは分からない。
LLM と VLM については、OpenAI、xAI、DeepSeek、Anthropic、Meta、Gemini、NearAI、Ollama（ローカル）など複数のエンドポイントが事前設定済みとされている。TTS も同様に設定済みのエンドポイントがある。Ollama が含まれているため、完全ローカルで動かす構成も想定されていることが読み取れる。
動かすまでの手順: 依存パッケージ、API キー、Zenoh のライブラリパス
README のクイックスタートは 5 分と銘打たれ、システム依存の導入から起動までを四段階で示す。macOS では brew install portaudio ffmpeg、Linux では sudo apt-get update の後に portaudio19-dev、ffmpeg、pkg-config を入れる。portaudio が入るのは音声入出力を使うためだ。
バイナリ配布が用意されており、linux-amd64、linux-arm64、darwin-arm64、darwin-amd64 の四つが対象とされている。Go をインストールせずに使える点が利点で、アーカイブには config/、knowledge_base/、libzenohc が同梱されるため、リポジトリを clone する必要はないと README は説明する。macOS で Gatekeeper に止められた場合は xattr -d com.apple.quarantine om1 を実行する。
ソースからビルドする場合は Go 1.25.0 以上と make が必要で、git clone の後に make deps、make build の順に走らせる。起動はバイナリなら ./om1 -config ./config/conversation.json5、ソースからなら CONFIG=conversation make run、デバッグログ付きなら CONFIG=conversation make dev である。
注意したいのは、バイナリ実行時に Zenoh の共有ライブラリを自分で探索パスに通す必要があることだ。macOS では export DYLD_LIBRARY_PATH="$PWD:$DYLD_LIBRARY_PATH"、Linux では export LD_LIBRARY_PATH="$PWD:$LD_LIBRARY_PATH" を設定してから起動する。「Zenoh C ライブラリを同梱している」という説明と、この環境変数設定の手間はやや噛み合っていない。同梱されているのは確かだが、動的リンカにその場所を教える作業は利用者側に残っている。
認証は OpenMind Portal で取得した API キーを OM_API_KEY として環境変数に置く。シェルプロファイルへの設定が推奨されるが、ソースからビルドした場合は .env.example を .env にコピーして OM_API_KEY を書く方法も使える。会話エージェントを使うなら、ASR と TTS を config/conversation.json5 に設定しておく必要があると README は注記している。
観測性は Docker 構成に依存し、メトリクスポートは 9090 を占有する
Prometheus と Grafana のスタックが同梱されており、LLM や ASR のレイテンシのようなパイプライン指標をリアルタイムで見られる。起動は docker-compose up -d grafana prometheus の一行で、ブラウザで localhost:3000 を開くと admin/admin の初期ログインで OM1 Latency Monitoring ダッシュボードが自動プロビジョニングされる。ダッシュボードを自分で組む必要がないのは、計測を後回しにしがちな開発では効く。
ただしこれは Docker が前提である。README は「Docker がインストールされていれば」と条件を付けており、エッジデバイスに直接デプロイする構成ではこの監視スタックをそのまま使えない可能性がある。また、トラブルシューティングにメトリクスポート 9090 の「Address already in use」が挙げられている。別の Prometheus が動いている環境では衝突するので、ポートの割り当てを確認しておく必要がある。
OMCU という課金単位と、無料枠 50 の意味
OM1 の利用には OpenMind の API キーが必要で、課金は OMCU という計算単位で行われる。README によれば無料プランで毎月 50 OMCU が付与され、追加クレジットはポータルで購入する。
ここで注意したいのは、OMCU が何を 1 単位として消費するのかが README に書かれていないことだ。LLM 呼び出し回数なのか、トークン量なのか、実行時間なのかによって、50 という数字の重みはまったく変わる。会話エージェントを常用するなら消費速度を把握しておかないと、無料枠が想定より早く尽きる可能性がある。この点は公開情報だけでは判断できない。
もう一つの含みは、Ollama のようなローカル LLM を選んだ場合に OMCU がどう扱われるかである。ローカル推論なら外部 API を叩かないのだから課金対象外と考えるのが自然だが、README はそこに触れていない。コストを抑えるためにローカル構成を選ぼうと考えている読者にとって、これは確認すべき項目になる。
ROS 2 をすでに使っているチームにとっての現実的な差分
ロボットのミドルウェアとして最も広く使われているのは ROS 2 である。OM1 は ROS 2 を置き換えるものではなく、その上に載る層として設計されている。README のプラグイン一覧に ROS2 が含まれていることがそれを示す。
アプローチの違いは抽象化の位置にある。ROS 2 ではノード、トピック、サービスといった通信プリミティブを自分で組み、その上に知能のロジックを書く。OM1 は入力、LLM、行動というエージェントのパイプラインを先に固定し、ハードウェア固有の部分をプラグインに押し出す。複数機体で同じエージェントを使い回したいなら OM1 の抽象化が効く。逆に、既存の ROS 2 ノード群がすでに密に連携していて、その上に薄く LLM を差し込みたいだけなら、OM1 のパイプラインに合わせて構成を組み直すコストのほうが大きくなる可能性がある。
ミドルウェアの推奨が Zenoh に寄っている点も、ROS 2 中心のチームには影響する。ROS 2 の通信層は DDS 系であり、CycloneDDS 向けプラグインはあるものの、README は新規開発で Zenoh を勧める。ROS 2 資産との接続をどこまで Zenoh 経由で賄うのかは、実装を見ないと判断できない。
ライセンスと保守コスト、そして最初に確かめるべきこと
ライセンスは MIT で、商用利用を含めて制約が少ない。ただし MIT が及ぶのはリポジトリ内のコードに対してであり、OpenMind の API 利用は別途ポータルの契約と OMCU の消費に従う。ライセンスの条文解釈についてはここでは扱わない。
保守の面で読むべきシグナルはリリースの刻み方だ。nightly の開発ビルドが継続的に出ており、v1.0.2-beta.1 と beta.2 が 2026 年 4 月に立て続けに公開されている。バージョン番号に beta が付いたままである点は、API や設定ファイルの形式がまだ動きうることを示唆する。config/conversation.json5 のような設定ファイルを運用に組み込むなら、更新のたびに差分を追う前提でいたほうがよい。
アップグレードのコストは、Go 版が Python 版の機能を追いかけている途中であることとも関係する。Python 版から Go 版へ移す場合、README が「コアのエージェントパイプライン」と表現する範囲の外にある機能は、まだ移植されていない可能性がある。移行を計画するなら、使っている機能が Go 版に存在するかを先に確認する。
最初に確かめるべきことは三つに絞られる。一つ、自分の用途が Go 版で未実装の機能に依存していないか。二つ、OMCU の消費単位と、Ollama 利用時の扱い。三つ、config/conversation.json5 に ASR と TTS を自分で設定できるか。ここが曖昧なまま実機に載せると、後から構成をやり直すことになる。
編集部の結論
音声とカメラで動く会話エージェントを最短で試したい個人開発者、あるいは ROS2 や Zenoh 経由で実機を繋ぐ実験を素早く回したいチームには向く。逆に、Python 資産を前提にした既存コードの移行先としては勧められない。Python 版は非推奨で保守されないと README が明記しており、Go 版は「コアのエージェントパイプライン」のみをカバーして一部機能が開発中とされている。採用前に確認すべきは三点。自分の用途が Go 版で未実装の機能に依存していないか、OMCU の無料枠 50 が毎月の運用で足りるか、そして config/conversation.json5 に ASR と TTS の設定を自分で書き込めるか、である。
コミュニティノート