現役組み込みエンジニアがAIを業務利用して分かったこと――期待と限界と現実解：AI基礎解説（1/3 ページ）
組み込み開発の業務でもAI活用に対する期待は大きく高まっている。本稿では、現役の組み込みエンジニアが本業である筆者が、日々の業務にAIを組み込み続けてきて見えてきたAI活用の限界と現実解について解説する。
1．はじめに――製造業のAI活用報道と現場体感の乖離
製造業のAI（人工知能）導入を取材した記事を読むと、たいてい「業務効率○％向上」の成功談か、「生成AIの仕組み解説」のような技術解説に行き着く。しかし、現場で実際にAIを業務に使っている筆者の体感は、そのどちらでもない。
派手な事例の裏側でもなく、技術そのものの解説でもない“使う側の視点”に、AI導入のリアルは眠っている――。現役の組み込みエンジニアとして本業でAIを日常活用してきた立場から、そう感じている。派手さのない業務工程で地味に効いている場面と、期待とは違う形で止まっている場面。両方の輪郭がはっきり見えてきたのは、日々の業務にAIを組み込み続けてきた今になってのことだ。
本稿では、AIアシスタントとして広く利用されている「Microsoft Copilot」（以下、MS Copilot）と、AIコーディングアシスタントである「GitHub Copilot」を日常業務で扱う中で見えてきた、AIが業務のどこで“効き”、どこで“止まっている”のかを、業務単位で分解して解説する。
2．業務にAIが入って効率化できた3つの工程
まずは「AIが効いた3つの工程」を取り上げる。
MS CopilotとGitHub Copilotを日常的に業務で扱う中で、「AIが効いた」と実感した業務は、意外にも派手さのないところに集中していた。代表例を3つ紹介する。
（1）レガシー仕様書の読解と現代化
レガシー仕様書のよくある困りごとは、仕様内容が書き切れていないことだ。要件の重要な部分が省略され、判断根拠が口頭のまま文書に残っていないケースが多い。加えて古い作法で書かれているため、主語の省略や章立ての古さが読みづらさを生む。
MS Copilotに渡して対話しながら整理すれば、書かれている内容は現代的な読みやすさに書き直せる。さらにGitHub Copilotで既存コードから逆に「実装がしていること」を仕様書に反映するリバース作業を組み合わせれば、書き切れていなかった仕様の断片を実装側から補完できる。新人教育コストとして地味に効いていた工数の負荷が、確実に下がる。
（2）ソースコード解説と実装ミス検出
単体ソースファイルなら、MS Copilotだけで関数の解説や実装ミス検出に十分な力を発揮する。しかしプロジェクト全体の依存関係を追う場面では、GitHub Copilotのようにコードベース全体を文脈として扱えるツールが不可欠だ。「1ファイルの読解」と「複数ファイル跨ぎの文脈追跡」は別の作業であり、適したツールを使い分けることでコード読解のスピードは大きく上がる。
（3）設計書ベースの自動補完――定数と関数の宣言はAIに任せられる
規約や制約まみれの中で、動くコードを一から書き上げるのは、まだAI単独では難しい。しかし、設計書で定義されている定数や関数の宣言のように「設計書がそのまま正解になる」部分は、設計書をインプットにコードを自動補完できる。
例えば、設計書にペリフェラルのレジスタ定義やモジュール間のインタフェース関数の宣言が明文化されていれば、それをMS Copilotに渡すことで、C言語コードでマクロ指定を行う#defineや、ヘッダ定義、関数プロトタイプを自動生成できる。
こうした宣言部分は、実装量が多い割に単純作業になりがちだ。1つでも間違えればプログラムが動かなくなるため集中力は要るが、判断すべきことは少ない。この「量は多いが単純な作業」こそが、AIによる工数削減効果が最も大きい領域だ。
3．AIの効果が期待外れだった3つの場面
3つの「AIが効いた3つの工程」に共通するのは、「人間が判断するための情報を、AIが先に下ごしらえしてくれる」構造である。しかし、AIに任せきりにすると足をすくわれる場面もあった。ここからは、期待外れだった3つの場面を取り上げる。
AIが“止まる”領域は3つあり、それぞれ「網羅性」「正確性」「統合性」の限界として整理できる。
（1）仕様変更の影響範囲――網羅性の限界
「この機能を変えると、どこに影響が出るか」とAIに問うと、意外なほど正直な返答が返ってくる。「この部分は判断しきれない」と、AI自身が影響範囲を保証しきれないことを明示する。これは誠実な挙動だが、逆に言えば実装者が組織横断の依存関係を把握していないとAIの回答だけで安心はできない。網羅性の担保は依然として人間の仕事だ。
（2）責任分界の判断――正確性の限界
「このバグは設計部／製造部／品証部のどの責任か」とAIに問うと、それらしい回答は返ってくる。しかし組織図の力関係、部門ごとの暗黙のルール、過去の判断先例といった“現場の空気”を知らないAIの回答は、しばしば実務の落としどころとズレる。判定を任せると危険な領域であり、AIの正確性はここで壁にぶつかる。
（3）複数制約を統合した動くコードを一から書き上げる――統合性の限界
前ページの第2章の（3）で紹介した通り、設計書ベースの定数や関数の宣言のような単純だが量が多い部分はMS Copilotの得意領域である。しかし、そこから一歩進んで「規約／タイミング制約／メモリ制約／割り込み優先度／排他制御などを全て統合した動くコードを一から書き上げる」となると、話は変わる。
組み込み開発の実装では、これらの制約を同時に頭に入れて設計判断を積み重ねる必要がある。AIは部分的な補完はできるが、複数制約の統合を伴う実装はまだ人間の仕事だ。第2章の“部分自動化ができる領域”とこの“統合実装が届かない領域”は、AIコーディング自動化の対の輪郭になる。
これら3つの限界は、AIの欠陥というより、“AIに何を任せてよいか”の輪郭を教えてくれる。
Copyright © ITmedia, Inc. All Rights Reserved.