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

OpenHarmonyを装置OSの候補に入れるかは、機能の多さより先に、保守・SDK・開発要員で判断します。10年動かす装置に、2年でコミュニティ保守が終わる版をそのまま載せることはできません。必要なカメラのSDKがWindowsにしかなければ、そのカメラを使う構成も成立しません。

本記事は、装置メーカーに向けたWindows IoT Enterprise LTSC・組込みLinux(Debian / Yoctoベース)・OpenHarmonyの比較です。まず比較する対象を揃え、製品寿命を支えられるか、既存資産を移せるか、量産・出荷まで進められるかの順に確認します。そのうえで、採用してよい条件と見送るべき条件を判断表にまとめます。

当社が普段扱うのはWindowsの装置ソフトですが、OpenHarmonyを一律に勧めたり否定したりする記事ではありません。「新しい技術だから」「中国発だから」ではなく、装置の時間軸・調達・要員に合うかを判断します。OpenHarmony・HarmonyOS・HarmonyOS NEXTの違い自体は、前回の「OpenHarmonyとは何か」を参照してください。

比較する技術情報と保守スケジュールの基準は、2026年7月です。サポート期間、対応ボード、認証要件は変わるため、採用する版と製品については、判断の直前に一次情報とベンダーへ確認してください。

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

1. まず結論：採用条件と、選ぶ理由を分けて考える

OpenHarmonyの強みは、小さな機器まで対応できることと、複数機器の連携を標準の仕組みで扱えることです。一方、既存Windows資産、産業用のベンダーSDK、日本語の一次情報には明確な制約があります。¹²³

採用に必要なのは、次の3条件です。どれかを満たせないなら、Windows IoT Enterprise LTSCか商用サポート付き組込みLinuxを優先します。反対に、3条件が揃っても、それだけでOpenHarmonyの採用が決まるわけではありません。製品の要件にOpenHarmonyの強みが合うことと、その製品を開発・保守できることの両方を確認します。

flowchart TB
    accTitle: 採用条件と製品にとっての利点を分ける
    accDescr: 製品要件に合う利点と、保守、SDK、要員という実現の条件を分け、両方を照合して採否を判断する。
    requirements["装置の市場・製品要件"] --> value["OpenHarmonyを選ぶ理由"]
    requirements --> conditions["保守・SDK・要員の条件"]
    value --> check["両方を照合して採否判断"]
    conditions --> check

図1: 動かせる条件と、選ぶ理由を分けて考える。

目的に合わせて読む

総合比較は2.3節、状況別の推奨は7.2節です。判断表で推奨される用途でも、上の3条件を省略できるわけではありません。

2. 比較対象を揃える：OSの名前だけでは比べられない

2.1. Windows IoT・Debian・Yocto・OpenHarmonyの位置づけ

最初に揃えるのは、完成したOS製品を使うのか、自社製品用のOSを作る土台を使うのかという違いです。ここを混ぜると、製品化のために自社が引き受ける作業を見落とします。

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

OpenHarmonyも、Windows IoTのような「買ってきて載せる完成品」ではありません。位置づけはYoctoに近く、土台を使って自社製品用の構成を作る側の選択肢です。ただし、Yoctoと違ってUIフレームワークとアプリモデルまで一体で用意されているため、上位の層まで含む体系になっています。

flowchart TB
    accTitle: 完成したOS製品と製品用の構成を作る土台
    accDescr: 商用OS製品を調達する経路と、プロジェクトの土台から自社製品用の構成を作る経路では引き受ける作業が異なる。
    os["装置へ載せる実行基盤"] --> product["商用OS製品を調達"]
    os --> project["開発の土台を選ぶ"]
    project --> config["製品用の構成を作る"]
    config --> scope["自社・ベンダーの担当を決める"]

図2: 同じOS選定でも、完成品の調達と構成作りでは担当範囲が違う。

2.2. メモリの下限は、システムタイプを揃えて読む

OpenHarmonyには、軽量・小型・標準の3つのシステムタイプがあります。¹

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

軽量システムの最小128 KiBに対し、Windows 11 IoT Enterprise LTSCの特定用途デバイス向け最小要件はメモリ2GB・ストレージ16GBです。一般的な組込みLinuxも、MMU付きプロセッサと数十MB以上のRAMが前提になります。OpenHarmonyがMCU領域まで同じ体系で扱える点は、大きな違いです。¹⁴

ただし、128 KiBで標準システムのアプリが動く、という意味ではありません。軽量システムはLiteOS-M、小型システムはLiteOS-A、標準システムはLinuxと、カーネルも実行環境も異なります。「同じOpenHarmonyだから同じアプリを載せ替えられる」と考えず、製品に必要なシステムタイプから選びます。

flowchart TB
    accTitle: システムタイプから実行環境を決める
    accDescr: 製品に必要なシステムタイプを決めてからカーネルとアプリの実行環境を確認し、メモリ下限だけでアプリ互換性を判断しない。
    need["製品に必要な機能"] --> type["システムタイプを決める"]
    type --> kernel["カーネル・実行環境を確認"]
    kernel --> app["その環境に合うアプリを作る"]
    minimum["最小メモリの数値"] -.-> caution["アプリ互換性の保証ではない"]

図3: 128 KiBという下限は、標準システムのアプリがそのまま動くという意味ではない。

2.3. 総合比較：強みと制約を同じ軸で見る

比較対象を揃えたうえで、6つの評価軸を並べます。記号は ◎=そのまま適合 / ○=条件付きで適合 / △=注意が必要 / ×=適合しない の4段階です。各章の説明を要約した表であり、すべての装置に共通する優劣ではありません。

OpenHarmonyが◎になるのは、リソース下限と機器連携の2軸です。既存資産・SDK・日本語情報の3軸は×になります。これは「悪いOS」という意味ではなく、採用条件が合う製品を選ぶ必要があるということです。

中国市場向けの製品、機器発見・データ同期・アプリ移行が価値の中心となる製品、ArkUIを使う画面付きIoT機器、MCUからリッチデバイスまでを1つの体系で揃えたい製品ラインには、検討する価値があります。具体的な採否は7章の判断表で確認できます。²

flowchart TB
    accTitle: 総合比較表を製品の要件に当てはめる
    accDescr: 比較表の評価だけでOSを決めず、製品の中心となる価値と制約に当てはめて採否判断へ進む。
    table["総合比較で強みと制約を把握"] --> req["自社製品の要件に当てはめる"]
    req --> fit["SDK・保守・要員を照合"]
    fit --> decision["7章の状況別判断へ"]

図4: 評価記号を数えるのではなく、自社製品の条件に当てはめる。

3. 保守を決める：担当・終了日・修正範囲を確認する

3.1. 最初に、製品の保守を誰が引き受けるか決める

保守を比べる目的は、OpenHarmony自体の品質の高低を決めることではありません。コミュニティ版をそのまま10年稼働の製品に載せ、放置する運用は成立しないという話です。

採用するなら、商用ディストリビューションのベンダー保守を購入するか、自社でブランチを保守してCVE対応まで引き受けます。産業採用では、ベンダーが独自に分岐を保守して有償提供する商用層が実際の調達先になります。Huaweiも2026年6月の説明で、OpenHarmonyは100を超える商用バージョンをリリースしたとしています。⁹

したがって、問い合わせるべきことは「OpenHarmonyは何年サポートされますか」ではなく、「そのディストリビューションの、どのブランチを、いつまで、どのSLAで保守しますか」です。保守を固められないなら、技術的に動かせても採用判断は保留します。

flowchart TB
    accTitle: コミュニティ保守と製品寿命をつなぐ担当
    accDescr: コミュニティ版をそのまま長期稼働の製品へ載せて放置せず、ベンダーか自社が製品寿命に必要な保守を引き受ける。
    life["製品寿命に必要な保守"] --> vendor["ベンダー保守を契約"]
    life --> own["自社でブランチ・CVE対応"]
    vendor --> terms["分岐・終了日・SLAを確定"]
    own --> terms
    terms --> adopt["採用判断の前提を固める"]

図5: 問い合わせはOS全体の年数ではなく、調達する分岐と保守条件について行う。

3.2. 総年数ではなく、終了日が装置の運用期間に足りるかを見る

装置に組み込むPCやボードは、装置本体と同じ10年前後のライフサイクルで動き続けることを求められます。各OSの保守を、その時間軸で比べます。

この表は2026年7月時点の各公式情報にもとづきます。年数だけでなく、表にある終了日までの期間が装置の運用期間に足りるかを確認します。サポート期間と終了日は改定されるため、採用判断の直前に確認する一次情報は次のとおりです。

• OpenHarmony: Version Lifecycle Management(生命周期管理ポリシー)とVersion Definitions(ブランチ種別・保守スケジュール表)。⁸¹¹
• Windows: 製品ごとのMicrosoft Lifecycle。⁵
• Debian: Debian Wiki LTS。⁶
• Yocto Project: Releases。⁷

flowchart TB
    accTitle: 装置の運用期間とOSの保守終了日を照合する
    accDescr: OSのサポート年数だけでなく、採用する版の終了日が装置の運用期間に足りるかを確認する。
    device["装置の運用終了予定"] --> compare["終了日を照合"]
    osend["採用する版の保守終了日"] --> compare
    compare --> enough{"運用期間を支えられるか"}
    enough -->|"不足"| contract["保守契約・別の選択肢を検討"]
    enough -->|"足りる"| scope["修正範囲も確認"]

図6: 10年サポートという名称だけでなく、その版の終了日を装置の運用計画と比べる。

3.3. 主動保守と受動保守を分けて読む

OpenHarmonyのReleaseブランチは主動保守1年＋受動保守1年、LTSブランチは主動保守2年＋受動保守1.5年です。合計だけを見て判断しないでください。⁸

この違いから、本記事では実質的に「安心して使える期間」を、Releaseで1年、LTSで2年と考えるべきだと評価しています。コミュニティ保守の総年数と、手厚い保守を期待できる期間は別です。⁸

flowchart TB
    accTitle: OpenHarmonyの保守段階の変化
    accDescr: 主動保守では計画的なタグ版の提供を行い、受動保守では修正範囲と提供方法が限定され、最後に保守終了を迎える。
    active["主動保守"] --> passive["受動保守"]
    passive --> eol["保守終了"]
    active -.-> regular["計画的なタグ版と修正"]
    passive -.-> limited["重大以上の脆弱性・不具合の修正"]

図7: 同じ保守期間でも、後半まで同じ範囲の修正が続くわけではない。

3.4. 採用するブランチの記載を確認する

本記事が参照する2026年7月時点では、近年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です。3.0-LTSの系列も掲載され、3.1以降はRelease種別になっています。¹²

さらに、同時点の保守スケジュール表には5.x系・6.x系の記載がありません。表にない版の保守期間を、他の版から決めつけないでください。期間が未確定という前提で、その版の確認を進める必要があります。

Windows 11 IoT Enterprise LTSC 2024は固定ライフサイクルで終了日が2034年10月10日と確定し、Debianは通常サポートとLTS期間、Yocto Projectは4年のLTSサポートを公表しています。それに対し、OpenHarmonyでは「採用する分岐をどこまで保守するか」を個別に確認する必要があります。⁵⁶⁷

flowchart TB
    accTitle: 一覧にない版の保守を推定しない
    accDescr: 保守スケジュールに採用する版が載っているかを調べ、記載がないときは別の版の期間を当てはめず個別に確認する。
    branch["採用する版・ブランチを特定"] --> listed{"保守表に記載があるか"}
    listed -->|"ある"| dates["その版の期間・終了日を確認"]
    listed -->|"ない"| ask["期間未確定として個別確認"]
    ask --> hold["保守が固まるまで判断保留"]

図8: LTSという呼び名や別の版の年数から、未掲載の版の保守を決めつけない。

4. 移行できるか調べる：SDK・アプリ・ドライバ・要員

4.1. OS比較より先に、依存するSDKを棚卸しする

産業用カメラ、モーションコントローラ、PLC通信、画像処理などのSDK・ミドルウェアは、Windows向けが第一で、次にLinux向けがあればよい、というものが多くあります。OpenHarmony向けの提供は、最初から期待できる状況ではありません。

そのため、最初の作業は次の棚卸しです。

装置に必要な周辺デバイスとミドルウェアを列挙し、それぞれのOpenHarmony対応状況を確認する。

必要なSDKが無く、不足分を自社で作ることもできないなら、その構成でのOpenHarmony採用は見送ります。比較表の機能だけで選んでからSDKを調べると、後工程で構成が成立しなくなります。当社が装置ソフトの相談を受けるときも、このリスト作りから始めています。

flowchart TB
    accTitle: 必要なSDKからOSの候補を絞る
    accDescr: 装置に必要な周辺デバイスとミドルウェアを列挙し、OpenHarmony向けSDKがない場合は不足分を自社で作れるかを確認する。
    devices["周辺機器・ミドルウェアを列挙"] --> sdk{"必要なSDKが揃うか"}
    sdk -->|"揃う"| next["移植範囲の確認へ"]
    sdk -->|"揃わない"| make{"不足分を自社で作れるか"}
    make -->|"はい"| next
    make -->|"いいえ"| stop["その装置構成では見送る"]

図9: SDKが無く補うこともできないなら、機能比較を続けても装置構成は成立しない。

4.2. Windows装置ソフトは、そのまま持ち込めない

開発体系の違いを並べると、既存資産への影響が分かります。

C#/.NET、Win32、COM、WPF/WinFormsで書かれたWindows装置ソフトは、OpenHarmonyでは実質的に作り直しになります。対応する実行環境がなく、UIはArkTS＋ArkUI、下回りはC/C++という別体系で書き直すためです。

既存資産を活かすことが前提なら、Windows IoT Enterprise LTSCへの載せ替えが現実的です。組込みLinuxを選ぶ場合もWindowsのUIなどは作り直しですが、C/C++の計測・制御ロジックは移植しやすく、必要なLinux向けSDKが提供されている機器に絞れば検討できます。

なお、表のOpenHarmonyのドライバ欄がHDFだからといって、既存のLinuxドライバをすべて書き直すわけではありません。通常のLinuxインターフェースから使う場合と、OpenHarmonyのフレームワークから使う場合の違いは次の4.3節で説明します。

flowchart TB
    accTitle: 既存Windows資産の移行範囲を切り分ける
    accDescr: 既存Windowsソフトをそのまま使う経路と、別OS向けにUIや実行環境を作り直す経路を分け、LinuxではSDKの提供とC/C++ロジックの移植可能性を確認する。
    assets["既存Windows装置ソフト"] --> reuse["既存資産をそのまま活かす"]
    assets --> port["別OS向けに作り直す"]
    reuse --> windows["Windows IoT LTSCを検討"]
    port --> scope["UI・実行環境・SDKを切り分ける"]
    scope -.-> logic["LinuxではC/C++ロジックを検討"]

図10: OSを替えるときは、UIと実行環境、計測・制御ロジック、SDKを一括りにしない。

4.3. Linuxドライバを使う経路と、HDFへの適合を分ける

OpenHarmonyのHDF(Hardware Driver Foundation)は、プラットフォーム非依存・カーネル非依存の統一ドライバ基盤で、全システムタイプに適用されます。²

一方、標準システムのカーネルはLinuxです。そのため、既存のLinuxカーネルドライバを組み込み、V4L2や入力デバイスといった通常のLinuxインターフェースから使うこと自体は可能です。

Linux BSPがあるなら、「全ドライバをHDFで書き直す」という見積もりは不要です。まず、どのデバイスをOpenHarmonyのフレームワークへ公開する必要があるかを決め、その範囲を工数に積みます。

また、ボード調達前でも、QEMUで構造と起動の流れを確認する作業は始められます。その入口と、採用時の着手順は8章にまとめます。

flowchart TB
    accTitle: Linuxドライバの再利用とフレームワークへの適合
    accDescr: 標準システムで既存Linuxドライバを使う場合、通常のLinuxインターフェースから使うか、HDIを介してOpenHarmonyのフレームワークへ公開するかで追加作業を分ける。
    driver["標準システムのLinuxドライバ"] --> normal["通常のLinuxインターフェース"]
    driver --> hdi["HDIを介した利用"]
    normal --> direct["既存ドライバを組み込む構成"]
    hdi --> adapt["OpenHarmony側へ適合"]
    adapt --> framework["システムサービス・フレームワーク"]

図11: 全ドライバを書き直すのではなく、OpenHarmony側へ公開する範囲を見積もる。

4.4. 開発環境と、技術文書を読める要員を用意する

デバイス開発の入口は、GUIのDevEco Device ToolとCLIです。DevEco Device Toolの構成は、Windowsでコード編集・デバッグ・書き込み、Ubuntuでコンパイルする併用方式です。ソース取得にはrepoツールを使い、gitcode.com・gitee.com・GitHubのミラーが案内されています。¹³¹⁴

公式ドキュメントは中国語と英語の2種類で、日本語版はありません。コミュニティの議論や商用ディストリビューションのベンダーも中国側が中心で、日本語で一次サポートを受けられる窓口は限られます。中国語または英語の技術文書を読み切れる人員がいることは、開発開始後の補助条件ではなく、実質的な採用条件です。³

flowchart TB
    accTitle: ソース取得とデバイス開発の実行環境
    accDescr: repoで取得したソースを使うデバイス開発にはCLIとDevEco Device Toolの入口があり、後者ではWindowsの編集・デバッグ・書き込みとUbuntuのコンパイルを組み合わせる。
    source["repoでソース取得"] --> cli["CLIで開発"]
    source --> ide["DevEco Device Tool"]
    ide --> win["Windowsで編集・デバッグ・書き込み"]
    ide --> ubuntu["Ubuntuでコンパイル"]

図12: ツールの準備に加えて、中国語または英語の技術文書を読み続けられる体制が必要になる。

5. 調達できるか確かめる：対応ボードと量産条件

5.1. 対応ボードには、NXPやSTのSoCも含まれる

本記事が参照するコミュニティの対応開発ボード一覧は22機種です。そのうち、装置に関係しそうなものを抜き出します。¹⁵

SoCベンダーは中国系だけではありません。NXP i.MX8M MiniやSTのSTM32シリーズもあり、日本の装置メーカーが既に採用しているSoCファミリで検討できる可能性があります。

ただし、この表はドキュメント上の想定用途を示すものです。10年の供給保証、日本国内での流通、量産向けボードへのOpenHarmonyの公式対応を保証するものではありません。

flowchart TB
    accTitle: 対応一覧と量産の調達条件を分ける
    accDescr: 対応開発ボード一覧は技術検討の入口であり、国内流通や供給年数、量産ボードへの公式対応を保証するものではない。
    list["対応開発ボード一覧"] --> candidate["技術検討の候補"]
    candidate --> sale["実際の販売・国内流通を確認"]
    sale --> supply["量産ロット・供給年数を確認"]
    list -.-> note["長期供給の保証ではない"]

図13: 一覧に名前があることと、製品寿命のあいだ調達できることは別の確認になる。

5.2. 評価機を手配する前に、調達条件を確認する

一覧の中心は評価ボードで、中国市場向けのものも多くあります。国内代理店で普通に買えるとは限りません。評価機を手配する前に、次の3点を問い合わせます。

1. ボードベンダーの販売ページや越境ECで取り扱いがあるか。
2. 国内の販売代理店があるか。
3. 量産時の最低ロットと供給年数はどうなるか。

対応一覧に載っていても、必要なボードを調達できなければ、実機での技術検証は進められません。OSの保守期間と合わせて、ボードの供給条件も確認してください。

自社基板へ載せる場合、ポーティングは自社またはディストリビュータの作業です。Windows IoTでOEM代理店からライセンスを調達し、ベンダー供給のドライバを使う場合とは、担当する範囲が変わります。SoCが既に決まっているなら、評価ボードを探すより、そのSoCへのポーティング工数を見積もるほうが実際的なこともあります。

flowchart TB
    accTitle: 評価ボードと自社基板で準備を分ける
    accDescr: 評価ボードを使う場合は入手性と量産条件を調べ、自社基板や決定済みSoCの場合はポーティングの担当と工数を見積もる。
    hardware["製品に使うハードウェア"] --> board["評価ボードを検討"]
    hardware --> own["自社基板・決定済みSoC"]
    board --> procure["入手性と量産条件を確認"]
    own --> port["ポーティング担当・工数を確認"]
    procure --> plan["OS保守と合わせて計画"]
    port --> plan

図14: 評価機の購入だけでなく、製品用ハードウェアに載せる作業も調達計画へ含める。

6. 出荷の条件を確認する：ライセンス・認証・エコシステム

6.1. 組み込む範囲のLICENSEを1つずつ確認する

OpenHarmonyは単一ライセンスではありません。製品へ組み込むリポジトリを列挙し、範囲ごとに確認します。

「OpenHarmonyはApache 2.0だから安心」と一括りにすると、標準システムのLinuxカーネル部分のGPL義務を見落とします。OSを商用ライセンスで調達するWindows IoTとの実務的な差は、この構成要素ごとのライセンス確認にもあります。

flowchart TB
    accTitle: 製品に含む範囲からライセンスを確認する
    accDescr: OpenHarmony全体を一つのライセンスと見なさず、製品に組み込むリポジトリを列挙して各LICENSEと頒布時の対応を確認する。
    product["製品へ組み込む構成"] --> repos["対象リポジトリを列挙"]
    repos --> licenses["各LICENSEを確認"]
    licenses --> delivery["頒布時の対応を整理"]
    delivery --> legal["法務・知財部門と確認"]

図15: Apache 2.0だけで判断せず、実際に組み込む構成要素ごとに確認する。

6.2. カーネルを改変することと、装置を顧客へ頒布することを分ける

GPLv2で義務が発生するのは、改変した時点ではなく頒布(distribution)の時点です。社内の検証機でカーネルを改変して動かすだけなら、ソース提供義務は生じません。

装置を顧客に納入するときは、頒布したバイナリに対応するソースコード(改変分を含む)を頒布先へ提供する義務が発生します。装置メーカーにとって「納品＝頒布」なので、量産・納入では対応が必要です。社内試作の段階から公開義務があるわけではないことと、顧客への納入時には対応が必要なことを分けてください。具体的な適合方法は、自社の法務・知財部門と確認します。

flowchart TB
    accTitle: 社内でのカーネル改変と顧客への頒布を区別する
    accDescr: GPLv2のソース提供義務を検討する際は社内利用にとどまる場合と、カーネルのバイナリを含む装置を顧客へ頒布する場合を分ける。
    kernel["Linuxカーネルを含む構成"] --> internal["社内検証・社内利用にとどまる"]
    kernel --> distribute["装置を顧客へ頒布"]
    internal --> no["社内改変だけでは提供義務なし"]
    distribute --> corresponding["対応するソースの提供に対応"]

図16: 改変した時点と、顧客へ装置を納入する時点を分けて義務を確認する。

6.3. 動くことと、OpenHarmony互換を名乗ることを分ける

ライセンスへの対応とは別に、対外的な互換性の表明に必要な手続きを確認します。

6.3.1. 社内検証と製品の互換性表明

社内検証や単発の装置で使うだけなら、互換性認証は不要です。一方、製品として「OpenHarmony互換」を対外的にうたう場合や、エコシステムの一員として扱われたい場合は、OpenAtom財団の互換性測評を通す前提で工数を見積もります。

技術的な土台は、互換性テストスイート群であるXTS(X Test Suite)です。申請者が適合開発とセルフテストを行い、テストレポートを添えて申請する、という流れになります。²¹⁹

flowchart TB
    accTitle: 互換性を表明する製品の認証準備
    accDescr: OpenHarmony互換を対外的にうたう製品では、要求されるテストを確認し、適合開発とセルフテスト、レポートを準備して互換性測評へ申請する。
    claim["OpenHarmony互換を表明"] --> required["申請時点のテスト要件を確認"]
    required --> test["適合開発・セルフテスト"]
    test --> report["テストレポートを準備"]
    report --> apply["互換性測評へ申請"]

図17: 社内で動作を確認したことと、製品の互換性を表明できることは同じではない。

6.3.2. ACTS・HATS・DCTSは、資料差を踏まえて確認する

本記事が参照する2026年7月時点では、資料によってXTSの内訳に差があります。

公式資料ではDCTSは将来提供の扱いですが、コミュニティ資料では構成要素として説明されています。DCTSを必須と決め打ちせず、申請時点で実際に要求されるスイートを認証窓口へ確認してください。この記述の差と、日本語の一次情報がないことは、採用時のコミュニケーションコストにもなります。²¹⁹

6.4. 顧客の求めるエコシステムと、調達方針を確認する

顧客が求めているのがAppGallery配信やHarmonyOSアプリ連携なら、OpenHarmonyでは要件を満たせません。AppGallery、HMS、HarmonyOS SDKはOpenHarmonyに含まれず、HarmonyOSアプリの互換性も保証されません。必要なのはHarmonyOS対応製品・HarmonyOS SDKであり、「OpenHarmony互換」の認証とは別の話です。

flowchart TB
    accTitle: OpenHarmony互換とHarmonyOSの要件を分ける
    accDescr: 顧客が求めるものがOpenHarmony互換か、AppGallery配信やHarmonyOSアプリ連携かを切り分け、後者はHarmonyOS対応製品とSDKの要件として扱う。
    customer["顧客が求める要件"] --> oh["OpenHarmony互換"]
    customer --> harmony["AppGallery・HarmonyOS連携"]
    oh --> cert["OpenHarmonyの互換性測評"]
    harmony --> commercial["HarmonyOS対応製品・SDK"]

図18: OpenHarmonyの互換性認証では、HarmonyOS側の配信・連携要件を代替できない。

調達方針についても、運営主体への制約とコード由来への制約を分けます。前者なら欧州財団のガバナンス下にあるEclipse Oniro系が検討候補になりますが、本記事の基準時点である2026年7月ではIncubatingで、コミュニティ規模もOpenHarmony本体とは比較になりません。後者が「中国由来のコードを含まないこと」なら、OniroもOpenHarmonyの基盤層の上に構築されるため、制約は解消しません。

flowchart TB
    accTitle: 運営主体への制約とコード由来への制約
    accDescr: 調達方針が運営主体を対象にする場合とコードの由来を対象にする場合を分け、欧州ガバナンスのOniroでもOpenHarmony由来のコードという条件は変わらないことを確認する。
    policy["調達方針の制約"] --> governance["運営主体・ガバナンス"]
    policy --> origin["コードの由来"]
    governance --> oniro["Oniro系を条件付きで検討"]
    origin --> remain["Oniroでも制約は解消しない"]
    oniro -.-> maturity["2026年7月時点の成熟度も確認"]

図19: 運営主体を替えることと、コードの由来を替えることを混同しない。

7. 採否を決める：製品の要件と引き受けられる条件を照合する

7.1. 市場・製品要件から順に判断する

前提を確認する順番は、市場・製品要件が先、技術検討が後です。そのうえで、SDK、保守、技術文書を読める要員を確認します。技術的に作れても保守が固まらなければ、装置への採用は決められません。

flowchart TB
    accTitle: OpenHarmonyを装置OSとして採用する主要な判定
    accDescr: 市場要件または機器連携の価値を確認した後に、SDK、保守、技術文書を読める要員を確認し、条件を満たせなければWindows IoTまたは組込みLinuxを検討する。
    S["装置に載せるOSを選ぶ"] --> Q1["中国市場向けか互換指定か"]
    Q1 -->|"はい"| Q3["SDKが揃う・自社で作れるか"]
    Q1 -->|"いいえ"| Q2["機器連携が製品価値の中核か"]
    Q2 -->|"はい"| Q3
    Q2 -->|"いいえ"| OTH["Windows IoT LTSC / Linux"]
    Q3 -->|"揃う / 自社で作れる"| Q4["保守を固められるか"]
    Q3 -->|"揃わない"| NG["OpenHarmonyは見送り"]
    Q4 -->|"固められる"| Q5["中国語または英語を読めるか"]
    Q4 -->|"固められない"| NG
    Q5 -->|"いる"| OH["OpenHarmonyを正面から検討"]
    Q5 -->|"いない"| NG
    NG --> OTH
    OH -.-> vendor["商用ディストリビューションで調達"]
    OTH -.-> assets["既存資産とSDK対応で選ぶ"]

図20: 市場・製品要件を入口に、SDKと保守、要員の条件を順に確かめる。

実際には、Q3(ベンダーSDK)とQ4(保守契約)で条件を満たせなくなる案件が多い、というのが本記事の主旨です。この図は主要な判定の流れです。MCU用途や製品ラインの統一、調達方針などの個別条件は、次の表と合わせて判断します。

7.2. 状況別の判断表

表のサポート年数は各版のライフサイクルです。装置の稼働期間と合うかは、3章の終了日まで含めて確認してください。また、表でOpenHarmonyを推奨する用途でも、SDK・保守・要員の条件が不要になるわけではありません。

8. 候補に残ったら、7つの作業で具体化する

判断表で候補に残ったら、次の7つの作業へ進みます。QEMUや実機で動いたことと、製品として採用できることは別です。保守条件が決まらないまま、技術検証の成功だけで採用を確定しないでください。

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. 互換性測評の要否を判断する。対外的にOpenHarmony互換をうたうなら、XTSによる適合開発・セルフテストと申請の工数を最初から積みます。

flowchart TB
    accTitle: 技術検証を製品の採用条件までつなぐ
    accDescr: 周辺機器とシステムタイプを確定してQEMUで構造を確認し、ビルド再現性とライセンス、保守契約、認証要否を固めてから採用判断へ進む。
    inventory["機器・SDKを棚卸し"] --> type["システムタイプを確定"]
    type --> qemu["QEMUで構造・起動を確認"]
    qemu --> reproduce["分岐固定・ビルド再現性"]
    reproduce --> conditions["ライセンス・保守・認証を確認"]
    conditions --> decision["製品としての採用判断"]

図21: 動作検証で止めず、将来の再ビルドと出荷後の保守まで具体化する。

8.1. まとめ：装置の時間軸・調達・要員に合うOSを選ぶ

OpenHarmonyは、128 KiBのMCUから128 MiB以上のリッチデバイスまでを1つの体系でカバーし、DSoftBusによる機器連携を標準で持つ、技術的には筋の通った設計です。産業用途を想定した対応ボードには、NXPやSTのSoCも含まれています。¹²¹⁵

一方で、10年稼働する装置に対し、コミュニティ保守のRelease 2年・LTS 3.5年は明確に足りません。本記事の基準時点では3.0-LTS以降にLTSが切られていない点も含め、商用ディストリビューションの保守、または自社でCVE対応まで行う体制なしに採用する選択肢ではありません。⁸¹¹¹²

日本の装置メーカーが確認すべきなのは、使う機器のSDK、技術文書を読める要員、製品寿命を支える保守です。これらが揃わなければ、Windows IoT Enterprise LTSCか商用サポート付き組込みLinuxが現実的です。逆に、中国市場の要件、機器連携、MCUからリッチ機器までの体系統一が製品価値に直結するなら、OpenHarmonyを正面から検討する価値があります。

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