組み込みソフトウェア開発は、デスクトップ、モバイル、Web 向けの一般的なソフトウェア開発とは、これまでも常に異なる規律を求められてきました。問題が起きたときにスケールアウトできるクラウドインスタンスはなく、メモリが足りなくなっても簡単に増設する方法もありません。さらに、システムクラッシュの影響は、最後の保存状態から復旧できるオフィスアプリケーションの利用とは異なります。組み込みソフトウェアの不具合は、車両や医療機器、産業機器そのものを停止させかねず、リスクの大きさが根本的に違います。この違いこそが、予算やエンジニアリング時間を投じる前に、組み込みシステム向け AI の活用をどう評価すべきかを左右します。
何があれば、エージェント型開発は組み込みハードウェアで本番導入レベルになるのか ？
本番導入レベルのエージェント型開発には、次の3つの要素が揃っている必要があります。
-
対象プラットフォーム向けに構築された、UI とハードウェアを理解したエージェントスキル
-
エージェントの判断だけに頼らないための、専用のヒューマン・イン・ザ・ループ（Human-in-the-loop） レビュー
-
何を出荷するかについての、明確な組織的説明責任
組み込み向け AI ツールを評価する組織は、これら3つすべてを、あれば望ましい改善点としてではなく、前提条件として扱うべきです。
Qt Group は先日、組み込みシステム向け AI の現状に関するパネルディスカッションを開催しました。登壇したのは、Beningo Embedded Group の Jacob Beningo 氏、Spyrosoft の Przemyslaw Nogaj 氏、そして Qt Group の Peter Schneider です。このパネルでは、組み込みチームがエージェントによるコードを確実に本番環境へ届ける上で、現在直面している共通の課題が浮き彫りになりました。
なぜ今、組み込みシステム向け AI が重要なのか
AI コーディングの波が始まってから最初の数年間、生産性の向上はほぼ Web、デスクトップ、モバイルソフトウェアに集中していました。組み込み開発はその後れを取っていましたが、これはおそらく開発規模の問題もありつつ、構造的な理由もありました。対象デバイスにはメモリ制約があることが多く、処理を肩代わりする GPU がないことも多く、汎用のエージェント型コーディングモデルが学習していない、特有のハードウェア要件を抱えているためです。
しかし今、このギャップは急速に縮まりつつあります。過去半年から9ヶ月の間には、従来慎重で規制の厳しい業界でも、目に見える変化が現れています。1年前には AI 支援開発を完全に排除していた医療機器メーカーが、今では、コミット・承認されるコードのうち AI が生成する割合について、社内目標を設定するようになっています。防衛関連企業は、パブリッククラウドの API 経由ではなく、自社のデータセンター内にデプロイできる大規模言語モデル(LLM)を評価しています。
組み込み製品のサイクルは消費者向けソフトウェアに比べて依然として遅く、規制業界での現実的な導入には2〜5年かかると見られていますが、その方向性はもはや疑う余地がありません。導入を先送りする組織は、先に動いた競合他社に生産性の優位性を奪われるリスクを負います。
組み込み向け AI ツールを本番導入する際によくある課題
AI を試すことと、実際に本番環境へ導入することの間には大きなギャップがあり、多くの組織はそこに必要な作業量を過小評価しています。実機上で組み込み向け AI ツールを運用するチームには、次の4つの課題が繰り返し現れます。
-
ハードウェアへの理解：汎用 LLM は、デスクトップ、Web、モバイルアプリケーションに適したパターンで学習されているため、リソースが制約された HMI デバイスには十分対応できません。
-
メモリとサイクルの制約： あらゆる最適化の判断は、対象ハードウェアのバイナリサイズと CPU サイクルという固定の制約を守らなければなりません。
-
機密性：特に安全性が重視される組み込みシステムでは、クラウドでホストされた共有モデルにデータを送ること自体が選択肢にならないことがあり、そのためプライベートにホストされたインスタンスや、オンプレミス、あるいはより小規模なローカルモデルへとワークロードがシフトします。
-
シミュレーションの死角：デスクトップビルドやシミュレーション上では見えないパフォーマンスの問題が、実際のターゲットデバイス上では深刻な問題として現れることがあり、実機での適切な検証が不可欠になります。
これらの制約自体は、組み込みソフトウェア開発にとって目新しいものではありません。変わったのは、適切なコンテキストさえあれば、AI エージェントをこれらの課題に対して具体的に振り向けられるようになったという点です。
組み込みシステムや安全性が重視されるデバイスで、AI が生成したコードは信頼できるのか
率直に言えば、答えはノーです。少なくとも、デフォルトでは信頼できません。デスクトップやモバイルアプリケーションであっても生成されたコードをそのまま信頼することはできませんが、対象がハードウェア、それも本番稼働中のハードウェアである場合、リスクの重みは根本的に大きくなります。
組み込み AI に関するパネルディスカッションで挙げられた、分かりやすい例えがあります。今日のコーディングエージェントは、資格上は非常に優秀な新卒者に似ています。理論上は申し分ないものの、特定のコードベースに対する実践的な理解には欠けている、というものです。監督なしに任せてしまえば、新機能を追加しながら既存の機能を壊してしまうことも同じくらい簡単に起こり得ます。これこそが、組み込みデバイスにおける核心的な問題です。自信ありげに生成されたコードは、正しいと検証されたコードとは違うのです。
組織は、AI エージェントを近道としてではなく、あくまでツールとして捉えるべきです。コード生成を行う前に、要件を丁寧に定義することに労力を割き、検証チェックリストによって受け入れる出力にゲートを設けることには十分な価値があります。エージェントは、監督なしの意思決定者としてではなく、監督下で動作しなければなりません。
コードは誰がレビューし、テストするのか。エージェント型 AI システムに、なぜ今も人間のレビュアーが必要なのか
エージェントがますます速くコードを生成するようになるにつれ、コードレビューが新たなボトルネックになりつつあります。これは部分的には、エージェントによるコードレビューと、決定論的な静的コード解析を組み合わせることで解決できます。しかし、エージェントによるレビューや品質保証は、最終承認としてではなく、一次フィルターとして捉えるべきです。
最も基本的なレベルでは、ドメイン特化型のエージェントスキルが、生成されるコードの品質向上に役立ちます。たとえば QML プロファイラースキルは、手作業での確認ではなく体系的に UI のボトルネックを特定でき、メモリプロファイリングはパフォーマンスを適切な範囲に保つ助けになります。Qt は、まさにこうしたハードウェアを理解したレビューのために構築されたエージェントスキルと MCP ツールを公開しています。
しかし、それだけでは十分ではありません。たとえば、従来のコードレビューの慣行から学べる有効なモデルとして、承認には、人間が見落としがちな点を拾い上げるエージェントによるレビューと、人間による最終承認の両方が必要だという考え方があります。エージェントの判断に加えて静的解析もパイプラインに残しておくべきです。規制業界では、常に明確に定義され、監査可能なレビュー工程が必要とされるからです。
規制対応：エージェント型 AI によるソフトウェア開発は、CRA などの規制にどう対応するのか
ますます多くの業界に適用が広がっている規制対応は、コード品質とセキュリティの重みをさらに引き上げています。
ソフトウェア要素を含む機器に適用されるEUのサイバーレジリエンス法（CRA）は、製品のライフサイクル全体にわたるサイバーセキュリティの責任を、機器メーカーに直接課しています。同様の規制は、アメリカから APAC まで、世界各地で整備が進んでいます。ソフトウェアがあらゆる製品のリスク領域における比重を増すにつれ、規制当局は、AI エージェントが生成に関わったコードも含め、スタック全体についてベンダーに責任を求めるようになっています。
正しく実装されれば、組み込みシステム向け AI は規制対応と衝突する必要はありません。むしろその逆です。エージェント型ワークフローは、既知の脆弱性を監視し、コードのトレーサビリティを維持できます。規制上の義務を満たすフレームワークの上に製品を構築し、組み込みシステム向けのエージェント型 AI を、安定したライブラリや、定義された規格に照らしてコードを自動検証するツールと組み合わせる組織は、手作業のみに頼るよりも、実際にはより確実にコンプライアンスを担保できます。
パフォーマンス：AI エージェントは、対象の組み込みハードウェア向けに UI コードを最適化できるのか
特に組み込み開発においては、機能的な正しさはゴールではありません。コードは、実際のターゲットデバイス上で、厳格なパフォーマンス制約の中で動作しなければなりません。デスクトップやシミュレーション環境では見えないコストが、実機では深刻な問題として現れることがあるため、hardware-in-the-loop の環境での最適化作業が必要になります。
自律的なエージェントループは、すでに今日の時点で、この作業をより簡単かつ効率的にできます。たとえば、バイナリサイズと CPU サイクルを削減するために、エージェントはコードを修正し、ボードにデプロイし、テレメトリデータを収集し、次のイテレーションを決定できます。しかもエージェントは、これを人間が手作業で行うよりも10倍速く行えます。ただし、シミュレーションやデスクトップでの代替環境が、この種のチューニングの代わりにはならないという点は重要です。組み込みデバイスにおけるパフォーマンス作業は、実際のハードウェア上でループを閉じる必要があります。
Human in the Loop：エージェント型 AI システムは、組み込みソフトウェア開発をどう変えているのか
ここまでの内容は、開発者が受け身の傍観者になるという意味ではありません。AI がもたらすのは責任の所在の変化です。開発者は、すべてのコード行を書く立場から、エージェントが貢献するシステム全体を統括する立場へと移行します。技術仕様を定義し、制約を設定し、アーキテクチャを検証し、レビューの方向づけを行う役割です。これは、コンパイラが成熟したことで手書きのアセンブリから離れていった過去のシフトになぞらえることができます。エージェント型 AI システムは、それと同様のシフトを一段上のレイヤーで引き起こしており、繰り返しの実装作業から、システムレベルの思考へと時間を解放しています。
役割はどう変化するか：シニアエンジニアには、スキルの転換が求められます。すべての行を順番に読むのではなく、生成されたコードを効率的に評価し、アーキテクチャ上の欠陥を素早く見抜く能力が必要になります。これは、繰り返し作業に費やしていた時間を、より影響力の大きい創造的な仕事へと振り向けられる、前向きな挑戦にもなり得ます。
採用の判断にどう影響するか：採用基準は、ツールへの習熟度から、実証された好奇心と適応力へとすでにシフトしつつあります。ただし、今後のジュニアエンジニアが実際にコードを書く経験を積む機会が少なくなるのであれば、何がうまくいかなくなるかを察知する勘を養うために、育成サポートが必要になる可能性があることも認識しておく必要があります。
なぜこれが定着率と成果の質を高めるのか：繰り返しの実装作業こそ、エージェントが最も効果的に吸収できる領域です。取り戻された時間は、優秀な人材を組織にとどめる仕事、つまり新しい問題を解決し、システムを全体的に理解し、過去の成果を再生産するのではなく新たに作り上げる仕事に充てられます。
組み込みデバイス向けソフトウェア開発における、AI の今後
エージェント型開発は、組み込みエンジニアリングに求められる厳密さを引き下げるものではありません。むしろ、「レビュー済み」「テスト済み」「規制準拠」が意味する水準そのものを引き上げながら、組織がその水準を満たすための余力を増やします。組み込みシステム向け AI へのこの転換を、組み込みソフトウェア開発における構造的な変化として捉える組織は、持続的な優位性を手にする立場にあります。導入を先送りする組織は、リスクを回避しているのではなく、後になるほど埋めるのに高くつく能力のギャップを先送りしているに過ぎません。
組み込みソフトウェア開発のエージェンティックAI活用
