装置に載せるOSとしてOpenHarmonyは選択肢になるか ── Windows IoT・組込みLinuxとの比較

前回の記事「OpenHarmonyとは何か」では、OpenHarmony・HarmonyOS・HarmonyOS NEXTという3つの実体を切り分けました。ここからは実務の話です。装置に載せるOSとして、OpenHarmonyは本当に選択肢に入るのか。

装置メーカーのOS選定は、機能比較よりも先に決まる要素があります。10年動く装置に、2年しか保守されないOSは載せられない。ベンダーSDKがWindowsにしかないカメラを使うなら、そのOSは最初から候補外になる。この記事では、Windows IoT Enterprise LTSC・組込みLinux(Debian / Yoctoベース)・OpenHarmonyを、装置の時間軸と調達の観点から並べて比較し、採用してよい条件と見送るべき条件を判断表にまとめます。

なお本記事は「OpenHarmonyを勧める記事」でも「やめておけという記事」でもありません。当社が普段扱っているのはWindowsの装置ソフトですが、選択肢を正しく比較できないまま「新しい技術だから」あるいは「中国発だから」で判断が決まってしまう場面を何度も見ています。判断材料を揃えることが目的です。

1. まず結論

• 保守期間が最大の分かれ目です。OpenHarmonyコミュニティのReleaseブランチは2年(主動保守1年＋受動保守1年)、LTSブランチでも3.5年(2年＋1.5年)。Windows 11 IoT Enterprise LTSC 2024の10年とは前提が違います。¹²
• しかも近年、LTSブランチは切られていません。LTSは初期には出ており(1.1.0 LTS、3.0-LTS)、公式の保守スケジュール表に残るLTSは2021年9月の3.0-LTSが最後です。3.1以降に公開されたブランチはすべてReleaseです。³⁴
• したがってコミュニティ版を製品にそのまま載せる運用は成立しません。採用するなら商用ディストリビューションのベンダー保守を買うか、自社でブランチを保守してCVE対応まで行う体制が要ります。Huaweiは「OpenHarmonyは100を超える商用バージョンをリリースした」と説明しており、この商用層が実際の採用先です。⁵
• リソースの下限はOpenHarmonyが圧倒的に低いです。軽量システムは最小128 KiBのMCUから動作します。Windows 11 IoT Enterprise LTSCの特定用途デバイス向け最小要件はメモリ2GB・ストレージ16GBなので、そもそも土俵が違います。⁶⁷
• 既存のWindows装置ソフト資産は持ち込めません。C#/.NET、Win32、COM、WPF/WinFormsに相当する実行環境がなく、UIはArkTS＋ArkUI、ドライバはHDFという別体系になります。移植ではなく作り直しです。
• 実際のボトルネックはベンダーSDKです。産業用カメラ、モーションコントローラ、PLC通信ライブラリの多くはWindows向け、次いでLinux向けしか提供されません。OpenHarmony向けドライバの有無は、OS比較より先に確認すべき項目です。
• 日本語の一次情報とサポートはほぼありません。公式ドキュメントは中国語と英語の2種類で、日本語版はありません。⁸ 中国語または英語の技術文書を読み切れる人員がいることが実質的な前提条件です。
• 向いている用途は確実にあります。中国市場向けの製品、複数機器の連携(DSoftBus)が製品価値の中心にある機器、画面付きIoT機器でArkUIのUIを使いたいケース、MCUからリッチデバイスまでを1つの体系で揃えたいケースです。⁹

評価軸×選択肢の総合判定を、先に1枚にまとめます。以降の各章で扱う内容の要約です。記号は ◎=そのまま適合 / ○=条件付きで適合 / △=注意が必要 / ×=適合しない の4段階です。

見てのとおり、OpenHarmonyが◎になるのはリソース下限と機器連携の2軸で、既存資産・SDK・日本語情報の3軸は×です。この形は「優劣」ではなく「噛み合う条件が限られる」ことを示しています。どの条件なら噛み合うのかを、8章の判断表で個別に示します。

この記事の知識マップ

装置に載せるOSの選定では、機能比較より先に保守期間とベンダーSDKの対応が結果を決めます。OpenHarmonyのコミュニティ保守はReleaseブランチで2年、LTSブランチでも3.5年しかなく、10年稼働する装置にはWindows 11 IoT Enterprise LTSC 2024の固定10年サポートや商用ディストリビューションのベンダー保守が必要です。一方でOpenHarmonyはリソース下限が圧倒的に低く、128 KiBのMCUから動く軽量システムを持つため、機器連携や超小型機器が製品価値の中心にある場合は正面から検討する価値があります。

flowchart LR
    accTitle: 装置OS選定(OpenHarmony・Windows IoT・組込みLinux)の知識マップ
    accDescr: OpenHarmonyと、比較対象のWindows IoT Enterprise LTSC・組込みLinux(Debian/Yocto)を、10年ライフサイクルの装置という要求、Releaseブランチ・LTSブランチの保守期間、商用ディストリビューションのベンダー保守、システムタイプ別のリソース下限、ベンダーSDK依存、既存Windows資産、HDF・ライセンス構成、互換性測評(XTS/ACTS/DCTS/HATS)、Eclipse Oniroの関係で示す図
    openharmony["OpenHarmony"]
    windows_iot_enterprise_ltsc["Windows IoT Enterprise LTSC"]
    embedded_linux["組込みLinux"]
    long_lifecycle_equipment["10年ライフサイクルの装置"]
    openharmony_release_branch["Releaseブランチ"]
    openharmony_lts_branch["LTSブランチ"]
    commercial_distro_support["商用ディストリビューションのベンダー保守"]
    yocto_project["Yocto Project"]
    debian["Debian"]
    lightweight_system["軽量システム(Mini)"]
    standard_system["標準システム(Standard)"]
    linux_kernel["Linuxカーネル"]
    hdf["HDF(Hardware Driver Foundation)"]
    gplv2_license["GPLv2"]
    apache_license_2["Apache License 2.0"]
    bsd_3_license["BSD 3条項ライセンス"]
    cc_by_4_license["CC BY 4.0"]
    vendor_sdk_dependency["産業用ベンダーSDKへの依存"]
    windows_app_assets["既存Windows装置ソフト資産"]
    deveco_device_tool["DevEco Device Tool"]
    gn_ninja["GN + Ninja"]
    repo_tool["repoツール"]
    device_qemu["device_qemu(QEMUエミュレーション環境)"]
    openharmony_compatibility_certification["OpenHarmony互換性測評(認証)"]
    xts["XTS(X Test Suite)"]
    acts["ACTS(アプリケーション互換性テストスイート)"]
    dcts["DCTS(デバイス互換性テストスイート)"]
    hats["HATS(ハードウェア抽象層互換性テストスイート)"]
    appgallery["AppGallery"]
    hms["HMS(Huawei Mobile Services)"]
    oniro["Eclipse Oniro for OpenHarmony"]
    eclipse_foundation["Eclipse Foundation"]
    windows_iot_enterprise_ltsc -->|"推奨される対応"| long_lifecycle_equipment
    openharmony_release_branch -->|"用いるのは非推奨"| long_lifecycle_equipment
    openharmony_lts_branch -.->|"用いるのは非推奨"| long_lifecycle_equipment
    openharmony -.->|"前提とする"| commercial_distro_support
    commercial_distro_support -->|"推奨される対応"| long_lifecycle_equipment
    embedded_linux -.->|"利用する"| yocto_project
    embedded_linux -.->|"利用する"| debian
    debian -.->|"推奨される対応"| long_lifecycle_equipment
    yocto_project -.->|"推奨される対応"| long_lifecycle_equipment
    lightweight_system -->|"両立しない"| windows_iot_enterprise_ltsc
    openharmony -->|"実装を担う"| lightweight_system
    openharmony -->|"実装を担う"| standard_system
    standard_system -->|"利用する"| linux_kernel
    openharmony -->|"利用する"| hdf
    standard_system -.->|"利用する"| gplv2_license
    openharmony -.->|"利用する"| apache_license_2
    openharmony -.->|"利用する"| bsd_3_license
    openharmony -.->|"利用する"| cc_by_4_license
    openharmony -.->|"用いるのは非推奨"| vendor_sdk_dependency
    windows_iot_enterprise_ltsc -->|"推奨される対応"| vendor_sdk_dependency
    openharmony -->|"両立しない"| windows_app_assets
    openharmony -->|"利用する"| deveco_device_tool
    openharmony -->|"利用する"| gn_ninja
    openharmony -->|"利用する"| repo_tool
    openharmony -->|"で確認できる"| device_qemu
    openharmony -.->|"前提とする"| openharmony_compatibility_certification
    openharmony_compatibility_certification -->|"利用する"| xts
    xts -->|"利用する"| acts
    xts -.->|"利用する"| dcts
    xts -.->|"利用する"| hats
    openharmony -->|"両立しない"| appgallery
    openharmony -->|"両立しない"| hms
    oniro -->|"利用する"| openharmony
    oniro -->|"前提とする"| eclipse_foundation

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全34件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 比較の前提を揃える ── 何と何を比べているのか

比較を始める前に、対象を明確にします。「OS」と一口に言っても層が違うものを並べると議論が噛み合いません。

表の中の用語を2つだけ補足します。Yoctoは完成したOSではなく、レシピ(ビルド手順の定義)を組み合わせて自社製品用のLinuxディストリビューションをビルドする枠組みです。LTSC(Long-Term Servicing Channel)は、機能更新を入れずセキュリティ更新だけを長期間提供するWindowsの提供モデルで、装置のように構成を固定したい用途向けの選択肢です。

ここで押さえるべきなのは、OpenHarmonyはWindows IoTのような「買ってきて載せる完成品」ではないということです。位置づけとしてはYoctoに近く、「これを土台に自社製品用の構成を作る」枠組みです。ただしYoctoと違い、UIフレームワークとアプリモデルまでが一体で決まっているぶん、上まで積み上がっています。

OpenHarmonyのシステムタイプの定義は次のとおりです。⁶

装置組み込みの文脈で比較対象になるのは主に標準システム(HMI付きの装置)と軽量システム(センサーノード、通信モジュール)です。小型システムはカメラ製品寄りの位置づけになります。

3. サポート期間の比較 ── 装置の時間軸に合うのはどれか

装置に組み込むPCやボードは、装置本体と同じ10年前後のライフサイクルで動き続けることを求められます。この観点で各選択肢を並べると、差は明白です。

この表は2026年7月時点の各公式情報にもとづきます。サポート期間と終了日は改定されるため、採用判断の直前には必ず一次情報で確認してください。確認先は次のとおりです。

• OpenHarmony: Version Lifecycle Management(生命周期管理ポリシー)とVersion Definitions(ブランチ種別と保守スケジュール表)¹³
• Windows: Microsoft Lifecycle(製品ごとのライフサイクル)²
• Debian: Debian Wiki LTS¹⁰
• Yocto Project: Releases¹¹

とくにOpenHarmonyは、後述のとおり5.x系・6.x系が保守スケジュール表にまだ載っていません。この表の行にないバージョンを検討する場合は、期間が未確定だという前提で見てください。

さらに読み込むべき点が2つあります。

1つ目。OpenHarmonyの「受動保守期間」は品質が落ちます。公式の生命周期管理ポリシーでは、主動保守期間はコミュニティがタグ版を計画的に出して不具合とセキュリティ脆弱性を修正しますが、受動保守期間に入るとタグ版の計画・リリースは行われず、重大以上のセキュリティ脆弱性と不具合のみが修正対象になります。¹ つまり実質的な「安心して使える期間」はReleaseブランチで1年、LTSで2年と考えるべきです。

2つ目。近年LTSブランチが切られていません。公式の保守スケジュール表に載るLTSは3.0-LTS(2021年9月)が最後で、3.1・3.2・4.0・4.1はすべてRelease種別です。³ LTS自体はそれ以前にも出ており、リリースノート索引には1.1.0 LTS(2021年4月)とその系列が残っていますが、いずれもEnd of Lifeです。⁴ さらに、5.x系と6.x系はこの保守スケジュール表にまだ記載がありません。10年の装置ライフサイクルを前提にすると、「どの分岐にどれだけの保守が付くのか」がリリースごとに読めない状態が続いていることになります。

一方、Windows 11 IoT Enterprise LTSC 2024は固定ライフサイクルポリシーで、2034年10月10日という終了日が最初から確定しています。² Debianも各リリースの通常サポートとLTS期間が公表され、Yocto ProjectもLTSリリースを4年間サポートすると明示しています。¹⁰¹¹

これはOpenHarmonyの品質が低いという話ではありません。この保守モデルは「コミュニティ版をそのまま製品に載せて放置する」使い方を想定していない、というだけです。実際の産業採用では商用ディストリビューションのベンダーが自社で分岐を保守し、保守を有償で提供します。採用検討時に確認すべきは「OpenHarmonyのサポートは何年ですか」ではなく、「そのディストリビューションのベンダーは、どのブランチを、いつまで、どういうSLAで保守しますか」です。

4. ハードウェアの選択肢

コミュニティが対応を公表している開発ボードは22機種です。¹³ 装置に関係しそうなものを抜き出すと次のようになります。

重要なのは、SoCベンダーが中国系だけではないという点です。NXP i.MX8M MiniやSTのSTM32シリーズが対応リストに入っているのは、日本の装置メーカーにとって現実的な意味があります。既に採用実績のあるSoCファミリで検討できる可能性があるからです。

ただし注意点も同じくらい大きいです。

• 対応ボードのリストと、実際に手に入る産業用ボードは別物です。ここに載っているのは評価ボード中心で、10年供給保証付きの産業用ボードにOpenHarmonyが公式に載っているかは別途確認が必要です。表の「想定用途」はドキュメント上の位置づけであって、供給保証でも日本国内での流通の裏付けでもありません。
• 入手性は日本から個別に確認する必要があります。この一覧のボードは中国市場向けが中心で、国内代理店で普通に買えるとは限りません。評価機を手配する前に、(1)ボードベンダーの販売ページと越境ECでの取り扱い、(2)国内の販売代理店の有無、(3)量産時の最低ロットと供給年数、の3点を問い合わせで確認してください。ここが詰まると、以降の技術検証はすべて止まります。
• 自社のハードウェアに載せるならポーティングが自社作業になります。Windows IoTなら「OEM代理店経由でライセンスを買い、ドライバはベンダーが供給する」で済むところが、OpenHarmonyでは自社かディストリビュータの作業になります。
• ドライバの扱いは「どこから使うか」で変わります。OpenHarmonyはHDF(Hardware Driver Foundation)という統一ドライバ基盤を持ち、これはプラットフォーム非依存・カーネル非依存の設計で全システムタイプに適用されます。⁹ ただし標準システムのカーネルはLinuxなので、既存のLinuxカーネルドライバをそのまま組み込み、V4L2や入力デバイスといった通常のLinuxインターフェース経由で使うこと自体は可能です。適合作業が必要になるのは、そのデバイスをOpenHarmonyのシステムサービスやフレームワークからHDI経由で扱わせたい場合です。既存のLinux BSPがあるなら、「全ドライバをHDFで書き直す」と見積もる必要はありません。どのデバイスをOpenHarmonyのフレームワークに露出させるかを先に決めて、その範囲だけを工数に積んでください。

なお、ボードの調達で止まっている段階でも検証は始められます。実機を買う前にQEMUで構造と起動の流れを確認する手順を9章に挙げてあります。また、自社基板のSoCがすでに決まっているなら、評価ボードを探すよりそのSoCへのポーティング工数を見積もるほうが実際的な場合もあります。

5. 開発環境と言語 ── 既存資産は持ち込めるか

装置ソフトの資産という観点で見ると、話は単純です。Windowsで書かれた装置ソフトは、OpenHarmonyには持ち込めません。C#/.NETもWin32もCOMもWPFも、対応する実行環境がありません。UIはArkTSとArkUI、下回りはC/C++で書き直しになります。

さらに現実的な障害は、ベンダーSDKの対応状況です。産業用カメラのSDK、モーションコントローラのライブラリ、PLC通信のミドルウェア、画像処理ライブラリ ── これらの多くはWindows向けが第一で、Linux向けが提供されていれば良いほう、というのが実情です。OpenHarmony向けの提供は期待できません。したがって、

OS比較より先に、装置に必要な周辺デバイスとミドルウェアのリストを作り、それぞれのOpenHarmony対応状況を確認する。

これをやらずにOS比較表だけで議論すると、後工程で確実に破綻します。当社が装置ソフトの相談を受けるときも、最初にこのリストを作るところから入ります。

開発環境の入口は2つ用意されています。GUIのDevEco Device Tool(Windowsでコード編集・デバッグ・書き込み、Ubuntuでコンパイルという併用構成)と、CLIによる手順です。¹⁴ ソース取得はrepoツールで、gitcode.com・gitee.com・GitHubのミラーが案内されています。¹⁵

6. ライセンスと知財

OpenHarmonyは単一ライセンスではありません。組み込む範囲ごとに確認が必要です。

「OpenHarmonyはApache 2.0だから安心」とまとめてしまうと、標準システムのカーネル部分のGPL義務を見落とします。装置に載せる範囲のリポジトリを列挙し、LICENSEを1つずつ確認するのが原則です。この点はWindows IoT(商用ライセンス1本で完結)との実務的な差になります。

GPLv2について1点補足します。義務が発生するのは頒布(distribution)の時点であって、改変した時点ではありません。社内の検証機でカーネルを改変して動かしているだけなら提供義務は生じず、その装置を顧客に納入した段階で、頒布したバイナリに対応するソースコードを頒布先に提供する義務が発生します。装置メーカーにとっては「納品＝頒布」なので結局対応が必要になりますが、社内試作の段階から公開義務があるわけではない、という区別は押さえておいてください(具体的な適合方法は自社の法務・知財部門と確認してください)。

7. 認証とエコシステム参加

製品として「OpenHarmony互換」を対外的にうたうには、OpenAtom財団の互換性測評を通す必要があります。技術的な土台はOpenHarmonyのXTS(X Test Suite) で、公式ドキュメントでは「OpenHarmony互換性テストスイート群を提供し、現在サポートされているアプリケーション互換性テストスイート(ACTS)と、将来サポートされるデバイス互換性テストスイート(DCTS)を含む」と説明されています。⁹ つまり公式ドキュメントの記述(2026年7月時点)では、現時点で提供されているのはACTSで、DCTSは将来提供という扱いです。

一方、コミュニティの認証手順資料では、XTSをACTS・HATS(ハードウェア抽象層互換性)・DCTSの3本立てとして説明しており、公式ドキュメントの記述と食い違っています。¹⁹ 申請者が自社で適合開発とセルフテストを行い、テストレポートを添えて申請する、という流れ自体は共通です。

工数を見積もるときは、DCTSを必須要件と決め打ちしないでください。どのスイートが申請時点で実際に要求されるかは、認証窓口に直接確認するのが確実です。この種の「公式ドキュメントとコミュニティ資料が一致しない」状況は、日本語の一次情報がないことと合わせて、採用時のコミュニケーションコストとして見込んでおくべきものです。

社内検証や単発の装置に使うだけなら認証は不要ですが、対外的に互換性をうたう製品、あるいはエコシステムの一員として扱われたい製品では通す前提になります。工数として最初から見積もっておくべき項目です。

8. 判断表 ── 採用してよい条件、見送るべき条件

判断表に入る前に、そこへ至る判定の流れを1枚にしておきます。前提を確認する順番が大事で、市場・製品要件が先、技術検討は後です。技術的に作れても、保守を契約で固められないなら装置には載せられません。

flowchart TD
    S["装置に載せるOSを選ぶ"]
    Q1["中国市場向けの製品か、または<br/>要件がOpenHarmony互換の指定か"]
    Q2["複数機器の連携(DSoftBus)が<br/>製品価値の中核か"]
    Q3["周辺デバイスとミドルウェアの<br/>ベンダーSDKがOpenHarmonyで揃うか<br/>(揃わない分を自社で作れるか)"]
    Q4["保守を契約で固められるか<br/>(商用ディストリビューションのベンダー、<br/>または自社でCVE対応まで持つ体制)"]
    Q5["中国語または英語の技術文書を<br/>読み切れる要員がいるか"]
    OH["OpenHarmonyを正面から検討<br/>商用ディストリビューション経由で調達"]
    OTH["Windows IoT LTSC または組込みLinux<br/>既存資産とベンダーSDKの対応で決める"]
    NG["OpenHarmonyは見送り"]

    S --> Q1
    Q1 -->|"はい"| Q3
    Q1 -->|"いいえ"| Q2
    Q2 -->|"はい"| Q3
    Q2 -->|"いいえ"| OTH
    Q3 -->|"揃う / 自社で作れる"| Q4
    Q3 -->|"揃わない"| NG
    Q4 -->|"固められる"| Q5
    Q4 -->|"固められない"| NG
    Q5 -->|"いる"| OH
    Q5 -->|"いない"| NG
    NG --> OTH

図1: OpenHarmonyを採用するかの判定フロー。各分岐の根拠は下の判断表の行に対応します

分岐のうちQ3(ベンダーSDK)とQ4(保守契約)で落ちる案件が実際には多い、というのがこの記事の主旨です。以下の判断表は、この図の各分岐を具体的な状況に展開したものです。

9. 採用するなら最初にやること

判断表で「採用」に振れた場合、着手順はこうなります。

1. 周辺デバイスとミドルウェアの棚卸し。カメラ、I/O、通信、モーション、画像処理 ── 各ベンダーのOpenHarmony対応可否を確認します。ここで詰まるなら、他の工程を進める意味がありません。
2. システムタイプの確定。軽量/小型/標準のどれで作るかを決めます。これでカーネル(LiteOS-M / LiteOS-A / Linux)もアプリの書き方も変わります。
3. QEMUでの構造確認。実機ボードを買う前に、device_qemuが用意しているArm Virt(LiteOS-A / Linux)、Cortex-M4、Cortex-M55、RISC-Vなどのエミュレーション環境で、ビルドと起動の流れを確認できます。²⁰
4. 保守分岐の固定とビルド再現性の確保。repoのマニフェストを固定し(タグ指定が確実です)、社内ミラーを持ち、5年後に同じバイナリを再生成できる状態を作ります。¹⁵ 上流のホスティングがgitcode.com中心である点も、事業継続の観点では自社ミラーを持つ理由になります。
5. ライセンス棚卸し。組み込む範囲のリポジトリを列挙し、Apache 2.0 / BSD / GPLの義務を整理します。
6. 保守契約の交渉。商用ディストリビューションのベンダーと、「どのブランチを、いつまで、どのSLAで」保守するかを契約で固めます。ここが決まらないなら採用判断を保留すべきです。
7. 互換性測評(XTS)の要否判断。対外的に互換性をうたうなら、工数を最初から積みます。

10. まとめ

• OpenHarmonyは技術的には筋の通った設計で、128 KiBのMCUから128 MiB以上のリッチデバイスまでを1つの体系でカバーし、機器連携(DSoftBus)を標準で持ちます。産業用途を想定した対応ボードもあり、NXPやSTのSoCも含まれます。
• 一方、装置の10年ライフサイクルという観点では、コミュニティの保守期間(Release 2年、LTS 3.5年)は明確に足りません。しかもLTSブランチは2021年の3.0-LTS以降切られていません。採用するなら商用ディストリビューションのベンダー保守が前提です。
• 日本の装置メーカーにとっての実質的な採用条件は3つです。(1)ベンダーSDKがOpenHarmonyに対応しているか、(2)中国語または英語の技術文書を読み切れる要員がいるか、(3)保守を契約で固められるベンダーがいるか。どれか1つでも欠けるなら、Windows IoT Enterprise LTSCか商用サポート付き組込みLinuxのほうが装置の時間軸に合います。
• 逆に、中国市場向けの製品、機器連携が製品価値の中核にある製品、MCUからリッチまでを1体系で揃えたい製品ラインでは、正面から検討する価値があります。

OS選定は「どれが優れているか」ではなく「装置の時間軸・調達・要員とどれが噛み合うか」の問題です。Windows側の選定基準については「産業用PCにはどのWindowsを入れるべきか」に整理しています。

関連記事

• OpenHarmonyとは何か ── HarmonyOS・HarmonyOS NEXTとの違いを整理する
• 産業用PCにはどのWindowsを入れるべきか ── Windows IoT Enterprise / LTSC 実践ガイド
• Windows 10サポート終了後の現実解
• Windowsキオスクモード(Assigned Access)の実務ガイド

関連する相談領域

合同会社小村ソフトでは、装置に載せる実行基盤の選定支援、既存Windows装置ソフトの移行可否の切り分け、長期稼働を前提とした構成のレビューを扱っています。「新しいOSが候補に挙がったが、社内に比較できる材料がない」という段階からご相談いただけます。

• 技術相談・設計レビュー
• ソフトリアルタイムWindowsアプリ開発
• Windowsアプリ開発
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

産業機器のOSとしてOpenHarmonyを採用しても大丈夫ですか？

条件次第です。決め手になるのは保守期間の扱いで、OpenHarmonyコミュニティのReleaseブランチは生命周期が2年(主動保守1年＋受動保守1年)、LTSブランチでも3.5年です。10年稼働する装置にコミュニティ版をそのまま載せると、製品寿命の途中でセキュリティ修正が止まります。採用するなら、商用ディストリビューションのベンダー保守を購入するか、自社でブランチを保守しCVE対応まで行う体制を持つことが前提になります。この体制が用意できないなら、Windows IoT Enterprise LTSC(10年)や商用組込みLinuxの長期サポート契約のほうが装置の時間軸に合います。

OpenHarmonyと組込みLinuxはどちらが軽いですか？

OpenHarmonyのほうが下限は低いです。OpenHarmonyの軽量システムはArm Cortex-Mや32ビットRISC-VのMCUで最小128 KiBのメモリから動作し、小型システムは1 MiB以上、標準システムは128 MiB以上です。一般的な組込みLinuxはMMU付きプロセッサと数十MB以上のRAMが前提なので、MCU領域まで同じOS体系でカバーできるのはOpenHarmonyの特徴です。ただし軽量システムのカーネルはLiteOS-Mで、標準システムのLinuxとは実行環境がまったく異なるため、「同じOSだから同じアプリが動く」わけではない点に注意してください。

既存のWindows装置ソフトをOpenHarmonyへ移植できますか？

実質的に作り直しになります。C#/.NETやWin32、COM、WPF/WinFormsで書かれた装置ソフトは、OpenHarmony上には対応する実行環境がありません。UIはArkTS＋ArkUI、下回りはC/C++、ドライバはHDF(Hardware Driver Foundation)という別体系で書き直すことになります。さらに産業用カメラやモーションコントローラのベンダーSDKはWindows(次いでLinux)向けしか提供されないことが多く、そこが移植の実際のボトルネックになります。既存資産を活かす前提なら、Windows IoT Enterprise LTSCへの載せ替えか、Linux向けSDKが提供されているデバイスに限定した組込みLinuxのほうが現実的です。

OpenHarmony対応をうたうには何か認証が必要ですか？

製品として「OpenHarmony互換」を名乗るには、OpenAtom財団の互換性測評(認証)を通す必要があります。技術的な土台はOpenHarmonyのXTS(X Test Suite)というテストスイート群です。ただし内訳は出典によって記述が異なり、2026年7月時点の公式ドキュメントは「現在サポートされているACTS(アプリケーション互換性テストスイート)と、将来サポートされるDCTS(デバイス互換性テストスイート)」と書いています。一方、コミュニティの認証手順資料はこれにHATS(ハードウェア抽象層互換性)を加えた構成で説明しています。工数を見積もるときは、DCTSを必須要件と決め打ちせず、申請時点で実際に要求されるスイートを認証窓口に確認してください。社内検証だけで使う分には認証は不要ですが、対外的に互換性をうたう製品では必要になります。

日本語のサポートや情報はどれくらいありますか？

公式ドキュメントは中国語と英語の2種類で、日本語版はありません。コミュニティの議論も中国語が中心です。商用ディストリビューションのベンダーも中国企業が中心で、日本語で一次サポートを受けられる窓口は限られます。したがって、社内に中国語または英語の技術文書を読み切れる人員がいることが実質的な採用条件になります。この点はWindowsや主要Linuxディストリビューションと比べたときのはっきりした差です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。