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

OpenHarmonyは、装置に載せるOSの選択肢になります。ただし、機能より先に「製品寿命を支える保守」と「必要なベンダーSDK」を確認する必要があります。10年動かす装置に、2年でコミュニティ保守が終わる版をそのまま載せることはできません。必要なカメラのSDKがWindowsにしかなければ、OSの機能比較を続けても、そのカメラを使う構成は成立しません。

この記事では、装置メーカーを対象に、Windows IoT Enterprise LTSC・組込みLinux(Debian / Yoctoベース)・OpenHarmonyを比較します。「何を比べるか」を揃えたうえで、保守、既存資産、調達、ライセンスと認証を順に確認し、採用してよい条件と見送るべき条件へ進みます。

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

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

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

1. まず結論：保守・SDK・要員を確認してから機能を比べる

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

最初に確認するのは、次の3点です。どれかが欠けるなら、Windows IoT Enterprise LTSCか商用サポート付き組込みLinuxを優先する、というのが本記事の判断です。

1.1. 3つの選択肢の総合比較

記号は ◎=そのまま適合 / ○=条件付きで適合 / △=注意が必要 / ×=適合しない の4段階です。表は以降の各章の要約であり、すべての装置に共通する優劣ではありません。

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

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

2. 比較の前提：完成したOS製品と、製品を作る土台を分ける

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

同じ「OS」でも、購入して利用する商用製品と、自社製品向けに構成を作るプロジェクトでは、引き受ける作業が違います。まず比較する対象を揃えます。

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

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

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だから同じアプリを載せ替えられる」と考えず、製品に必要なシステムタイプから選びます。

3. 保守：装置の寿命を、誰がどこまで支えるか

3.1. 保守年数と終了日を並べる

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

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

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

3.2. OpenHarmonyの「2年」「3.5年」は、同じ手厚さで続く期間ではない

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

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

3.3. LTSという名前だけで、採用する版の保守を推定しない

本記事が参照する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では「採用する分岐をどこまで保守するか」を個別に確認する必要があります。⁴⁵⁶

3.4. コミュニティの保守と、製品の保守契約を分ける

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

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

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

4. SDKと既存資産：使いたい機器から移行の可否を決める

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

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

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

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

必要なSDKが無く、不足分を自社で作ることもできないなら、その構成でのOpenHarmony採用は見送ります。比較表の機能だけで選んでから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のフレームワークから使う場合の違いは5.3節で説明します。

4.3. 開発ツールだけでなく、文書を読める要員も必要

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

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

5. ハードウェア：対応一覧と、量産時に調達できることは別

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

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

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

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

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

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

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

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

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

5.3. Linux BSPを使える範囲と、HDFへの適合が必要な範囲

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

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

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

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

6. ライセンス：OpenHarmony全体をApache 2.0と考えない

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

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

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

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

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

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

7. 認証とエコシステム：技術的に動くことと、互換を名乗ることは別

7.1. 社内検証と、対外的な互換性の表明を分ける

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

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

7.2. XTSの内訳は、申請時点の要件を確認する

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

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

7.3. HarmonyOSへの参加要件や、コード由来の制約は別に確認する

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

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

8. 採否判断：製品の要件と、引き受けられる条件を照合する

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

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

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(保守契約)で条件を満たせなくなる案件が多い、というのが本記事の主旨です。この図は主要な判定の流れです。MCU用途や製品ラインの統一、調達方針などの個別条件は、次の表と合わせて判断します。

8.2. 状況別の判断表

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

9. 検討を進める場合：最初の7つの作業

採用候補に残ったら、次の順番で具体化します。保守条件が決まらないまま、技術検証の成功だけをもって採用を確定しないことが重要です。

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による適合開発・セルフテストと申請の工数を最初から積みます。

10. まとめ

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