OpenRGBは、マザーボード・メモリ・GPU・ファン・周辺機器のRGBライティングを、メーカーをまたいで1本のソフトで制御するGPLv2のオープンソースソフトウェアです。無料のARGB制御ソフトとしてWindows・Linux・macOSで動き、GUIとコマンドラインの両方から色やエフェクトを指定できます。2026年9月12日に約3年ぶりの正式版1.0が公開され、udevルールの扱い、SDKサーバーの待受、プロファイルの形式、プラグインの互換性が変わりました。この記事は1.0を前提に、OS別の導入、日本語化、CLI操作、DDR5環境で報告されているSPD破損リスク、デバイスが出ないときの切り分けまでを、公式のソースコードと実際の実行結果で確かめて整理します。
まとめ:OpenRGB 1.0で押さえる要点
- 現行版は1.0(2026年9月12日公開)です。リリース候補の1.0rc3(6月28日)と、セキュリティ修正の1.0rc3.1(8月23日)を経た正式版で、GUIはQt6に移りました。
- Windowsでマザーボードやメモリを制御するには、PawnIOの導入に加えて、管理者での実行かインストーラのシステムサービス登録が必要です。1.0のインストーラはサービス登録が既定の選択肢です。
- DDR5環境のSPD破損・起動不能は、2026年10月時点でも未解決のイシューとして残っています。RGBのないメモリなら、メモリ系の検出を切って使うのが安全側です。
- Linuxのudevルールは、1.0から本体が生成します(
--generate-udev-rules)。Ubuntuのaptは1.0より前の開発版なので、AppImageかFlatpakを使います。 - rc3から上げると、SDKサーバーが127.0.0.1でしか待ち受けなくなり、プロファイルはJSONへ移り、rc2向けプラグインは読み込まれません。
- 日本語UIは設定の「言語」から切り替えます。1.0の日本語訳は425件中424件が訳済みです。
OpenRGBの位置づけ:純正ソフトを置き換える無料のRGB/ARGB統合制御
ASUSのAura Sync、MSIのMystic Light、CorsairのiCUE、Razer Synapseは主な対応製品や連携範囲が異なり、他社パーツを混ぜた構成では複数の常駐ソフトが必要になる場合があります。iCUEには対応するASUS製マザーボードやGPUを制御する機能もあります。OpenRGBはUSBとSMBusの通信手順を自前で実装し、これを1つのアプリにまとめます。公式サイトは「OpenRGB is free and open source software under the GNU General Public License version 2.」と明記しており、アカウント登録や課金の仕組みはありません。ライセンス種別ごとの採用判断はオープンソースソフトウェア(OSS)とは|ライセンス種別と実装現場での採用判断・リスク管理で整理しています。
純正ソフト・SignalRGBとの比較と選び分け
| 比較軸 | OpenRGB 1.0 | SignalRGB | メーカー純正 |
|---|---|---|---|
| 料金 | 無料(GPLv2) | 無料版+Pro(サブスク) | 無料 |
| 対応OS | Windows・Linux・macOS | Windowsのみ | 多くはWindowsのみ |
| 他社製デバイスの混在 | 対応機器で可 | 対応機器で可 | 対応製品・連携機能による |
| CLI・SDKからの操作 | 可(ポート6742) | 限定的 | 製品による |
SignalRGBは公式ダウンロードページが「SignalRGB is a Windows desktop app.」と書くとおりWindows専用で、ファンカーブの細かな編集や色の詳細設定はサブスクリプションのProで開放されます。判断の分かれ目はOSと操作方法です。LinuxやmacOSでメーカーをまたいで照明を管理したい場合や、CLI・SDKから操作したい場合は、対応機器を確認したうえでOpenRGBを候補にできます。逆に、Windows専用機で画面連動や音楽連動の凝った演出を最小の手間で使いたいなら、OpenRGBを選ぶ理由は薄くなります。
ARGB(5V・3ピン)とRGB(12V・4ピン)の違いと制御経路
ARGBはLEDを1個ずつ別の色にできるアドレサブル方式で、従来のRGBは帯全体が1色になります。NZXTの公式解説によると、5V ARGBヘッダーは4ピン幅に3ピンを並べて1か所を塞いだ形、12V RGBヘッダーは4ピンが並んだ形で、電圧もヘッダーも別物です。同じ解説は「Never plug one into the other, because it can permanently damage the device, the motherboard or both.」と警告しています。OpenRGBが色を送る先は、ファンやLEDストリップそのものではなく、それをつないだマザーボードのヘッダーや外付けコントローラです。ARGBファンを個別に光らせたいなら、まずマザーボードのARGBヘッダーかARGB対応コントローラにつながっているかを確認してください。
1.0正式版で変わった点:rc3から移行するときに引っかかる箇所
1.0のリリースノートは、0.9からほぼ3年分、1.0rc2から1年分の作業を含むと説明しています。使い方に直接響く変更を、タグ release_1.0 のソースと実行結果から拾うと次のとおりです。
| 項目 | 1.0rc3まで | 1.0 |
|---|---|---|
| Linuxのudevルール | リリースに同梱のファイルを配置 | 本体が生成 |
| SDKサーバーの既定の待受 | 0.0.0.0(全インターフェース) | 127.0.0.1 |
| プロファイル | 設定フォルダ直下の .orp | profiles フォルダの .json |
| プラグインAPI | バージョン4 | バージョン5 |
| SDKプロトコル | バージョン5 | バージョン6 |
| GUIの土台 | Qt5 | Qt6 |
最も影響が大きいのはSDKサーバーの待受です。rc3のヘルプは「Default: 0.0.0.0 (all network interfaces)」でしたが、1.0のソースでは既定値が127.0.0.1に変わりました。2026年10月12日にmacOS(Intel)版1.0で--serverを起動すると、待受は127.0.0.1:6742だけで、--server-host 0.0.0.0を付けたときに初めて全インターフェースで待ち受けました。別PCから照明をそろえていた構成は、1.0に上げただけでつながらなくなります。前段の1.0rc3.1は、悪意あるクライアントがプロファイルの保存・削除で設定フォルダの外へ書き込める問題を直し、バックグラウンドサービスの待受をlocalhostに限定した修正版です。外へ開けるのは信頼できるLANの中だけにしてください。
プロファイルは、1.0の起動時に旧形式の .orp をJSONへ変換し、元のファイルを .orp.bak へ改名します。ゾーンの長さなどを持つ sizes.ors も Configuration.json に置き換わりました。プラグインは、APIバージョンが本体と一致しないと「incompatible API version」として読み込みを飛ばす実装のため、1.0rc2向けのビルドは1.0では動きません。1.0向けのプラグインを入れ直してください。
OpenRGBをインストールする:OS別の前提条件とドライバ
Windows:msiインストーラとPawnIO・システムサービス
1.0の配布物は、64bit版のmsiインストーラと、インストール不要のzip(64bit・32bit)です。32bit向けのmsiはありません。キーボードやマウスなどUSB接続の機器はこれだけで動きますが、RGBメモリと一部のマザーボードのオンボードLEDはSMBus経由のため、PawnIOの導入が要ります。リリースノートは、PawnIOを入れたうえで「run as Administrator or install with the background service option」が必要だと書いています。
1.0のmsiは、PawnIOの画面の次にシステムサービスの選択画面を出し、「Install System Service (Default)」が既定のボタンです。サービス登録を選ぶと、裏側が管理者権限で常駐し、GUIは通常ユーザーのまま機器にアクセスできます。登録しない場合は、起動のたびに管理者として実行します。公式FAQによると、バックグラウンドサービスからはプラグインを使えないため、プラグインの設定を含むプロファイルは、GUIを開いている間しかその部分が適用されません。
Linux:AppImage・Flatpakの導入とudevルールの生成
Ubuntuのuniverseにもopenrgbはありますが、26.04 LTSと開発中の26.10はどちらも0.9+git20251009+ds-1で、1.0より前の2025年10月9日時点の開発版です。24.04 LTSには収録がありません。一方、Arch Linuxの公式リポジトリ(extra)は2026年9月12日に1.0へ更新され、Flathubも1.0を配信しています。Ubuntuで1.0を使うなら、公式配布のAppImageかFlatpakが近道です。.debと.rpmは、1.0からhidapiのフォーク hidapi-hotplug に依存するので、Codebergで配布されているパッケージを先に入れます。
1.0ではudevルールの配布ファイルとインストールスクリプトがリリースから消え、本体がルールを書き出す方式に変わりました。公式のUdevRules.mdは、手動で入れる場合の置き場所を/etc/udev/rules.d/60-openrgb.rulesとしています。
# AppImage の場合
chmod +x OpenRGB_1.0_x86_64_81bbe18.AppImage
sudo mkdir -p /etc/udev/rules.d
sudo ./OpenRGB_1.0_x86_64_81bbe18.AppImage --generate-udev-rules /etc/udev/rules.d/60-openrgb.rules
sudo udevadm control --reload-rules
sudo udevadm trigger
# Flatpak の場合(FlatpakとFlathubを設定済みの環境)
flatpak install --system flathub org.openrgb.OpenRGB
sudo mkdir -p /etc/udev/rules.d
sudo sh -c 'flatpak run org.openrgb.OpenRGB --print-udev-rules > /etc/udev/rules.d/60-openrgb.rules'
sudo udevadm control --reload-rules
sudo udevadm trigger
# マザーボードとメモリを扱う場合
sudo modprobe i2c-dev
sudo modprobe i2c-i801 # Intelチップセット
sudo modprobe i2c-piix4 # AMDチップセット
Ubuntu 24.04のコンテナでAppImage 1.0を動かしたところ、最小構成では「libusb-1.0.so.0: cannot open shared object file」で起動せず、libusb-1.0-0を入れると通りました。生成されたルールは5,684行で、USB機器の行が1,205、先頭にI2CデバイスへのTAG+="uaccess"が入っていました。--print-udev-rulesと--generate-udev-rulesの出力は同一です。.debや.rpmで入れた場合は/usr/lib/udev/rules.d/60-openrgb.rulesが同時に入ります。i2cのモジュールを再起動後も読み込むには、公式のSMBusAccess.mdのとおり/etc/modules-load.d/i2c.confにモジュール名を1行ずつ書きます。なお同文書によると、SMBusが要るのはRGB付きのDDR4・DDR5メモリと、X370/Z270・X470/Z370世代を中心とするマザーボードのオンボードLEDです。どちらも無ければi2cの設定は省けます。個々のコマンドの意味はLinuxコマンド一覧|用途別早見表48選とUbuntu 26.04での変更点で引けます。
SDKサーバーを常駐させるなら、リポジトリ同梱のsystemdユニット qt/openrgb.service が使えます。ExecStart=/usr/bin/openrgb --server --config /etc/openrgbでサーバーを起動し、1.0ではProtectSystem=strictとProtectHome=trueの制限も加わりました。パッケージで入れた環境ならsudo systemctl enable --now openrgb.serviceで有効にできます。ユニットファイルの書き方はsystemdとは?読み方・SysVinitとの違いとsystemctl・ユニットファイルの基本【v262】で確認できます。
macOS:未署名のzip配布と制御できる範囲
macOS版はApple Silicon(ARM64)とIntelそれぞれのzipで、dmgではありません。Intel版1.0のアプリをcodesign -dvで調べると「code object is not signed at all」と返り、Gatekeeperも拒否しました。macOS Sequoia以降では右クリックから開くだけでは許可できません。配布元と警告内容を確認し、システム設定の「プライバシーとセキュリティ」から実行を許可します。設定ファイルの置き場所はLinuxと同じ~/.config/OpenRGB/です。SMBusは、公式のSMBusAccess.mdによるとIntelのi801系コントローラに限り、別途macUSPCIOドライバを入れれば使えます。それ以外の環境で制御できるのはUSB接続の外付け機器です。
OpenRGBの使い方:デバイス確認から色の指定・プロファイル保存まで
GUIでの基本操作
起動すると機器の自動検出が走り、終わるとメインウィンドウにデバイスのタブが並びます。公式Wikiの使い方ページは、ウィンドウが空なら検出に失敗しているので、Windowsは管理者実行、Linuxはudevルールを見直すよう案内しています。デバイスを選んだら、モード欄で効果を選び、色の指定方法を「LEDごと」「モード固有」「ランダム」から選びます。速度と方向は、モードが対応している場合だけ操作できます。仕上がったら「プロファイルを保存」で名前を付けて保存します。
コマンドラインの主要オプションと実行例
| オプション | 内容 |
|---|---|
-l, --list-devices |
デバイスと番号の一覧 |
-ld, --list-detailed |
モード・ゾーン・LEDまで表示 |
-d, --device |
対象デバイス(番号か名前) |
-z, --zone |
対象ゾーン(デバイスの後に指定) |
-m, --mode |
モード(static、breathing など) |
-c, --color |
色(16進数・カンマ区切り・random) |
-b, --brightness |
明るさ 0〜100 |
-p, --profile |
プロファイルの読み込み |
-sp, --save-profile |
プロファイルの保存 |
--server, --server-host |
SDKサーバー(既定 127.0.0.1:6742) |
--nodetect |
起動時の機器検出を省く |
--i2c-tools |
I2C/SMBusツール画面を開く |
基本は--list-detailedで番号と対応モードを確かめ、その番号を--deviceに渡す流れです。1.0のヘルプによると、名前は3文字以上の部分一致で引け、色の数がLEDより少なければ最後の色が残りのLEDに当たります。
openrgb --list-detailed
openrgb --device 0 --mode static --color FF0000
openrgb --device "Aura" --zone 0 --mode static --color 0000FF --brightness 40
openrgb --device 1 --mode static --color 000000
プロファイル保存とログイン時の自動起動
openrgb --save-profile gaming
openrgb --list-profiles
openrgb --profile gaming
openrgb --autostart-enable "--profile gaming --startminimized"
openrgb --autostart-check
1.0ではプロファイル名に拡張子を付けません。macOS版1.0で--save-profile gamingを実行すると profiles/gaming.json ができ、中身は"profile_version": 6でした。旧手順のように--save-profile night.orpと書くと、night.orp.json という名前の別プロファイルになります。ログイン時の起動は--autostart-enableに起動時の引数を渡して登録し、--autostart-checkで確認、--autostart-disableで解除します。GUIでは「設定」の「ログイン時に起動」から同じ登録ができ、公式FAQによると、起動時に読むプロファイルはプロファイル管理の設定で選べます。
SDKサーバーとネットワーク同期
# 照明をまとめるPC(LAN内に公開)
openrgb --server --server-host 0.0.0.0 --server-port 6742
# 操作する側のPC
openrgb --client 192.168.1.10:6742
OpenRGBは自分をサーバーにして、外部プログラムや別のPCから操作を受け付けます。前述のとおり1.0の既定の待受は127.0.0.1なので、同じPCのスクリプトから使うだけなら--serverだけで足ります。複数台で照明をそろえる場合は、サーバー側で--server-hostにLAN側のアドレスか0.0.0.0を指定し、OSのファイアウォールで6742番を許可します。
日本語化の手順と翻訳が反映されないときの確認箇所
OpenRGBは日本語UIに対応しています。1.0では「設定」の「ユーザーインターフェース」にある「言語」で日本語を選びます。翻訳は本体に組み込まれており、別ファイルを入れる必要はありません。ソースでは、指定した言語が読み込めないときにOSのロケールの訳を読み込む実装になっています。1.0の翻訳ファイル OpenRGB_ja_JP.ts は、425件の文言のうち424件が訳済みで、収録21言語の1つです。最後の更新は2026年8月24日でした。
日本語にならない場合は言語設定を確認し、一部だけ英語になる場合は該当画面の翻訳状況と使用中のビルドを確認します。Ubuntuのaptで入る0.9+git20251009は、2025年10月9日時点の開発版を固めたものです。日本語訳ファイルはその後も更新が続き(直近は2026年8月24日)、apt版にはそれらの訳が入っていません。日本語表示を優先するなら、AppImageかFlatpakの1.0を使ってください。Ubuntu側の日本語入力や文字化けのつまずきはUbuntuとは|インストール手順・推奨スペック・日本語化と文字化け対策を初心者向けに解説にまとめています。
OpenRGBの安全性:DDR5のSPD破損リスクとPawnIO移行の目的
結論から言えば、USB接続の周辺機器だけを扱う用途はリスクが小さく、SMBus経由でRGBメモリやマザーボードを触る用途には現実の破損報告があります。この差を理解せずに全機能を有効にするのが、最も危ない使い方です。
SMBusアクセスによる障害報告と発生構成
OpenRGBはメモリのRGBコントローラにSMBus(I2C)で直接アクセスします。同じバスには、メモリの仕様情報を持つSPDも載っています。1.0のソース(SPDAccessor/DDR5DirectAccessor.cpp)を読むと、DDR5のSPDを読むときも、SPDハブのページ切替レジスタ(0x0B)へ書き込む実装です。つまり「読むだけ」の検出でも、バスへの書き込みが起きます。
イシュートラッカーの「[Meta-Thread] DDR5 Detection / SPD Corruption / Boot Issues」(#4934)は2025年7月19日に起票され、2026年8月15日の更新時点でもオープンのままです。修正候補に挙がっていたマージリクエスト!2548は、マージされずに閉じられました。報告されている進行は次の順です。
- 起動直後はDDR5モジュールを検出しますが、OpenRGBの再起動・再検索・スリープ復帰の後に検出できなくなります。
- CPU-ZやHWiNFOで、SPDの情報が欠けたり壊れたりして見えます。
- Windowsからの再起動で、メモリエラーによりPOSTに失敗します。
- 最悪の場合、SPDの破損により起動できなくなることがあります。
同じイシューでは、同一のDDR5モジュールがASUS PRIME B760M-Kでは症状を起こし、MSI B850 GAMING PLUS WIFIでは起こさなかったと報告されています。マザーボード側の実装に左右されるため、自分の構成が当たるかどうかは事前に判別できません。もう1つの引き金は同時アクセスです。公式FAQは、SMBusは一度に1つのアプリしか正しく扱えず、2つのアプリが同時に触ると機器を不正な状態に落としうると書いています。「RAMを壊すのか」という疑問に対しては、DDR5環境でSPD破損と起動不能の報告があるため、構成を問わず安全とは断言できません。
WinRing0からPawnIOへの置き換えとアンチチート・Defenderの検知
Windowsでの低レベルアクセスに使われていたWinRing0は、WinRing0.sysとWinRing0x64.sysの脆弱性がCVE-2020-14979としてNVDに登録され(CVSS 3.1で7.8 HIGH)、Microsoft Defenderが「VulnerableDriver:WinNT/Winring0」として検知するようになりました。OpenRGBは1.0rc2でPawnIOへ置き換え、互換用にWinRing0版を別タグ(release_candidate_1.0rc2wr0)で残しています。
公式FAQの説明も1.0に合わせて変わりました。以前はVALORANTのアンチチートVanguardとの衝突が導入条件のように書かれていましたが、現行のFAQでは、Vanguardが止めたのは0.7までのinpout32、Defenderが止めたのはWinRing0で、PawnIOへの移行はこの問題を避けるためだったと整理しています。そのうえで、管理者で実行しても検出しないなら、カーネルレベルのアンチチートやウイルス対策がPawnIOを止めている可能性を挙げています。ゲーム用PCでは、この点を最初に疑ってください。
導入を見送るべき構成と安全側に倒す運用
次に当てはまるなら、SMBus制御は使わない判断を勧めます。メモリにRGBがないDDR5環境、カーネルレベルのアンチチートを常用するゲーム機、止められない業務端末です。復旧にBIOSの操作やモジュールの交換が要る時点で、照明をそろえる目的に対して代償が釣り合いません。
使う場合は、要らない検出を切ります。設定ファイル OpenRGB.json の Detectors には検出器ごとの真偽値が並び(macOS版1.0が生成したファイルで1,885項目)、公式の設定解説は、無効にしたい項目をfalseに書き換えるよう案内しています。メモリ系はENE SMBus DRAM、Corsair DRAM、Kingston Fury DDR5 DRAMなどの8項目です。G.Skill・Geil・T-Force・A-DATAのメモリはENE製のチップを使うため「ENE DRAM」として出ます。CPU-ZやHWiNFO64を同時に起動しない、純正RGBソフトとそのサービスを止める、更新前に設定フォルダごとバックアップする。これだけでも事故の確率は下がります。--i2c-toolsのI2C/SMBusツールは、ヘルプ自体が「There is a risk of bricking your motherboard, RGB controller, and RAM」と警告しているので、目的がない限り開かないでください。
デバイスが認識されないときの切り分け手順
検出されない原因は、権限・競合・非対応の3つに分かれます。上から順に潰すのが早道です。
- 他のRGBソフトを終了し、バックグラウンドサービスまで止めます。ASUS Aura、iCUE、Gigabyte RGB Fusionなどが同じバスとUSBを奪い合います。
- 権限を確かめます。WindowsはPawnIOと、管理者実行またはサービス登録。Linuxは60-openrgb.rulesとi2c-devの読み込みが前提です。
- 機器自体がOSから見えているかを
lsusbやlspciで確かめます。 - 電源を完全に落として、他のRGBアプリを開かずにOpenRGBだけを起動します。
- メモリの一部だけが出ないなら、公式FAQのとおりモジュールを別のスロットへ挿し直します。OpenRGBが探さないアドレスに割り当たっていることがあります。
- LinuxでKingston FuryのDDR5が出ないなら、
sudo i2cdetect -lで見つけたバスをi2cdetectで調べます。該当アドレスがUUと表示されたら、カーネルのspd5118ドライバが先に確保しているので、公式文書のとおりrmmod spd5118で外します。
ここまでで出ないなら、実装上の制約を疑います。AMD GPUのLinuxでの制御は、公式FAQが「Linux kernel versions prior to 6.15 did not have a driver for the OEM I2C interface on AMD GPUs」と書くとおり、カーネル6.15以降が条件です。MSI製マザーボードがrootでしか動かない場合は、Super I/Oへの書き込み権限が足りていないため、FAQは実行ファイルにsudo setcap cap_sys_rawio=ep ./openrgbを付ける方法を示しています(AppImageには効きません)。GPUが出ないときは、対応デバイス一覧にそのカードのPCI IDが載っているかを製品名で引き直してください。
プラグインとSDK:1.0対応の公式プラグインとPythonからの自動化
公式プラグインと1.0対応状況
| プラグイン | 役割 | 1.0向け |
|---|---|---|
| Effects | 機器を横断するエフェクト・音楽連動 | あり |
| Visual Map | 複数機器を1つのグリッドに配置 | あり |
| Hardware Sync | CPU・GPU温度を色で表示 | あり |
| E1.31 Receiver | E1.31で外部ソフトから制御 | あり |
| HTTP Hook | HTTPでプロファイル切替など | あり |
| Scheduler | 時刻でプロファイルを切替 | あり |
| Fan Sync | 温度をファン回転数に割当 | なし(rc2向けまで) |
公式サイトのプラグイン一覧に載る6本は、いずれも2026年9月12日に1.0向けのビルドがCodebergで公開されました。問題はファンの回転数を扱うFan Syncで、2026年10月12日時点の最新はrc2向け(2025年9月14日)にとどまり、公式の一覧からも外れています。APIバージョンが合わないため1.0では読み込まれません。ファン制御まで1本にまとめたい場合、1.0では別のファン制御ソフトと組み合わせる前提になります。
openrgb-pythonでの制御例
pip3 install openrgb-python
from openrgb import OpenRGBClient
from openrgb.utils import RGBColor, DeviceType
client = OpenRGBClient('127.0.0.1', 6742, 'build-status')
print(client.protocol_version)
for dev in client.get_devices_by_type(DeviceType.KEYBOARD):
dev.set_color(RGBColor(255, 0, 0))
client.disconnect()
PyPIの最新版openrgb-python 0.3.8(2026年10月8日公開)で1.0のサーバーへ接続すると、protocol_versionは4でした。サーバー側はプロトコル6に対応していますが、ライブラリが対応する4で通信が成立し、種別で機器を取り出すところまで例外なく動きました。デバイス番号ではなく種別で取るため、機器の構成が変わってもスクリプトを書き換えずに済みます。この例は対応キーボードを赤色に設定する部分です。ビルド結果や監視値を通知するには、成否の取得やしきい値との比較に応じて色を選ぶ処理を追加します。LED制御を業務システムや監視画面に組み込む規模になったら、フルスクラッチ開発として設計から相談できます。
よくある質問
OpenRGBは安全ですか?
用途によって差があります。USB接続のキーボード・マウス・LEDコントローラを扱うだけならリスクは小さいです。一方、SMBus経由でRGBメモリやマザーボードを制御する使い方では、DDR5環境でSPDが壊れて起動しなくなる報告がイシュー#4934として2026年8月時点でもオープンのまま残っています。CPU-ZやHWiNFO64との同時実行は避け、RGBのないメモリなら設定でメモリ系の検出を無効にしてください。
OpenRGBは日本語で使えますか?
使えます。1.0では「設定」の「ユーザーインターフェース」にある「言語」で日本語を選びます。翻訳は本体に組み込まれており、1.0の日本語訳は425件中424件が訳済みです。Ubuntuのaptで入る版は2025年10月9日時点の開発版で、その後に更新された日本語訳は入っていません。
Ubuntuではaptで入れられますか?
Ubuntu 26.04 LTSのuniverseにはopenrgbがあり、sudo apt install openrgbで入ります。ただし版は0.9+git20251009+ds-1で、1.0ではありません。24.04 LTSには収録がありません。1.0を使うならAppImageかFlatpakを入れ、--generate-udev-rulesでudevルールを書き出してください。ディストリビューション側の収録状況はUbuntu 26.04 LTS 開発者向け詳細|言語バージョン・x86-64-v3・フレーバー・サポート期間も参考になります。
OpenRGBでファンの回転数も制御できますか?
本体だけではできません。回転数を扱うFan Sync Pluginは、2026年10月12日時点で1.0向けのビルドが公開されておらず、rc2向けのビルドは1.0では読み込まれません。ファンの光り方の制御は本体で、温度に合わせた色の変化はHardware Sync Pluginで行えます。
SignalRGBとOpenRGBはどちらを選ぶべきですか?
LinuxやmacOSを使うか、CLIやSDKから照明を自動で変えたいならOpenRGBです。Windows専用機で凝った演出を手間なく使いたいならSignalRGBが向いています。SignalRGBはWindows専用で、細かな設定はサブスクリプションのProで開放されます。OpenRGBは全機能が無料ですが、Windowsで内部パーツを触るにはPawnIOと、管理者実行またはサービス登録が必要です。