【実録】RTOS経験半年の若手がAIを活用し、2週間弱でデュアルコア制御システムを作った話 ―組込み×生成AIの可能性と課題―

1ヶ月かかるはずのプロジェクトが、9日で終わった

― デュアルコア・マイコン上でリアルタイムOS（RTOS）を両コアに載せ、コア間連携を行いながらネットワーク経由でロボットアームを制御する。―

組込みソフトウェア開発の経験がある方なら、これが一筋縄ではいかないプログラムであることは容易に想像がつくはずです。とりあえず動くだけのデモ・プログラムであっても、RTOSやプロトコルスタックの移植、コア間通信プロトコルの策定・デバッグを含め、経験者でなければ1ヶ月以上はかかる開発規模です。

今回、私たちは実験としてあえて「RTOS経験わずか半年」の若手エンジニアにこの開発を担当してもらいました。 ただし、ひとつの実験的なルールを設けています。それは「コーディングにおけるAIの使用は完全自由」ということです。

結果はどうだったか。なんと、わずか9日後に展示会デモが可能なレベルでプログラムが完成しました。

本稿では、RTOS「μT-Kernel 3.0」を用いたマルチコア開発の実録を通して、組込み開発における生成AIの凄まじいスピード感と、逆に浮き彫りとなった「組込み特有のリアルな課題」について現場の視点から共有します。

本記事の開発は2026年5月に行いました。生成AIの進歩は非常に速く状況はどんどん変わっていますのでご注意ください。

開発ターゲット：デュアルコア× μT-Kernel 3.0によるロボットアーム制御

今回構築したのは、STM32H747I-EVAL基板と6軸ロボットアームを組み合わせたデモシステムです。
PCのWebブラウザからの操作でロボットアームを制御します。

各CPUコアの作業分担と連携は以下の通りです。

  • Cortex-M7（コア0 / 頭脳担当）
    • RTOS μT-Kernel 3.0 ＋ lwIP（TCP/IPプロトコルスタック）
    • PCのブラウザからのWeb（REST API）制御を受け付けるWebサーバとして機能
  • Cortex-M4（コア1 / 手足担当）
    • RTOS μT-Kernel 3.0
    • I2C通信経由でPWMドライバ（PCA9685）を叩き、6軸サーボを精密に駆動
  • コア間連携
    • 共有メモリ＋ハードウェアセマフォと割り込み通知

PCからネットワーク経由で指示を送ると、コア0がそれを受け取り、コア間通信を経てコア1がロボットアームを意図通りに動かします。

なぜ9日で完成したのか？ ── AIフル活用による開発タイムライン

今回の開発は、基本的にすべて生成AIをフル活用して進められました。設計段階では、当社の有するµT-Kernel 3.0とlwIPの移植のノウハウが投入されています。コーディングはすべてAIが行いました。
作業工数の内訳は以下の通りです。

日数内容
4日μT-Kernel 3.0とlwIPの移植
3日共有メモリ制御と割込みによるコア間通信の構築
2日ロボットアーム制御ロジック、Web API連携などのアプリケーション実装

当初の想定を大幅に前倒しして完成したため、余った時間でLCDへのスライドショー表示機能や、あらかじめ登録したモーションを再生する自動デモモードまで追加実装することができました。

RTOSのAPIリファレンスを引きながら手作業でドライバコードを組んでいた時代と比べると、AIによる初動スピードは圧倒的と言えます。

コードレビューで見えた「組込み×AI開発」の落とし穴

「AIがあれば、経験の浅いエンジニアでも完璧な組込みソフトが組めるのか？」 答えは半分YESで、半分NOです。

動くデモは完成したものの、完成したソースコードをレビューしたところ、組込みシステムとして見過ごせない問題が散見されました。

1.  RTOSの基本を無視したタスク間の制御

タスク間の排他制御や同期処理を行う際、本来であればRTOSが提供するイベントフラグ、セマフォ、メールボックスといった同期・通信機能を使うべき場面で、単純な「グローバル変数」でフラグ管理をしてしまうような初歩的なアンチパターンが見受けられました。 偶然タイミング良く動いていても、高負荷時や予期せぬ割り込み発生時に競合状態を引き起こす典型例です。

2. コード内に埋め込まれた大量のデバッグルーチン

コード内には、不要なログ出力や状態確認用のデバッグコードが至る所に残されていました。 AI自身がRTOS上でコードを走らせた際の振る舞い（タスクのプリエンプションやディスパッチの挙動）を推し量るために、試行錯誤しながら過剰な確認コードを埋め込んでいった形跡でした。

なぜこの問題が起きたのか？ ── 組込み開発特有の3つの課題

これらの問題は、AIツールの欠陥というよりは、組込み領域特有の事情とプロンプト（指示出し）の難しさに起因しています。

  1. AIへ正しいコンテキスト（前提知識）を与えられていない
    「このタスクとこのタスクでデータをやり取りしたい」とだけ指示すると、AIはWebや汎用アプリで一般的な最短経路（グローバル変数等）を提示しがちです。「μT-Kernel 3.0のイベントフラグを用いてタスク同期を行い、排他制御にはミューテックスを用いる」といったRTOSの設計思想を踏まえた適切なプロンプトを指示するスキルが開発者側に求められます。

  2. 組込み特有の学習データ不足
    一般的なWebフレームワークやPython等に比べ、RTOSやマイコン固有のペリフェラル制御に関する良質なコード資産は、ネット上に公開されている絶対量が限られています。そのため、AIが組込み特有のベストプラクティスを自律的に選びきれないケースがあります。

  3. 「AIが直接デバッグできない」という物理の壁
    Web開発であれば、AI自身にテストを実行させ、エラーログを読ませて自己修復（デバッグ）ループを回すことが容易です。しかし、組込み開発では「実機のピンから波形が出ない」「I2CがACKを返さない」「相手コアが共有メモリを掴んだまま止まった」といった物理ハードウェアが絡むデバッグが発生します。ここはどうしても人間の介在と実機デバッガが必要になります。

AI時代だからこそ「基礎力」と「デバッグ環境」が価値を持つ

今回の検証から得られた最大の教訓は、「AIは超高速なコーダーになり得るが、設計の舵取りと品質の担保は、エンジニアのRTOS理解とデバッグ技術にかかっている」ということです。

AIに適切な指示を出し、生成されたコードの危うさを見抜き、マルチコア特有のタイミング不具合を実機上で可視化して追い詰める──これらができるエンジニアがいれば、開発期間はこれまでの何分の一にも短縮されます。

ユーシーテクノロジのアプローチについて

当社では「組込みシステムにおけるAI活用」に真正面から取り組んでいます。

  • RTOSを使用した組込みシステムの正しいアーキテクチャ設計
  • プロンプトエンジニアリングと組込みドメイン知識を融合した開発プロセスの標準化
  • マルチコア・JTAGデバッガを活用した高度な実機デバッグ・検証ソリューション

「自社でもマルチコア・マイコンやRTOSを導入したいが設計・デバッグの見通しが立たない」「最新のAI開発を取り入れて組込みの開発スピードを加速させたい」とお考えの企業様は、ぜひお気軽にお問い合わせください。