組み込みソフトウェア開発のAI活用｜品質を保つテスト・レビュー・ログ解析の進め方
目次
組み込みソフトウェアでAIを使う前に決めること
組み込みソフトウェアの開発では、ハードウェア仕様、ファームウェア、通信、試験設備、量産後の保守が相互に影響します。そのため、AIを導入する目的を「コードを速く書くこと」だけに置くと、品質確認、変更管理、実機試験の負荷を見落としやすくなります。
IPAは、AIを用いたソフトウェア開発の活用場面として、要件定義、会議記録、コード生成、レビュー、テスト・テストデータ作成を挙げています。[1] 組み込み開発では、これらを既存の設計審査、テスト、リリース承認にどう接続するかが重要です。AIは、判断に必要な情報を整理する補助として用い、製品の安全性、品質、出荷可否を最終決定する役割は担当者に残します。
優先しやすい4つの適用領域
| 開発上の課題 | AIで補助しやすい作業 | 人が確認する事項 | 評価指標の例 |
|---|---|---|---|
| 変更影響の見落とし | 要件、設計、コミット、テストケース、障害票の関連候補を整理する | 対象範囲と試験要否の決定 | 追跡可能な要件の割合、手戻り件数 |
| レビューの滞留 | コーディング規約、差分、過去の不具合を基に確認観点を提示する | 指摘の妥当性、修正方針、承認 | レビュー待ち時間、再レビュー回数 |
| 回帰試験の肥大化 | 変更箇所と過去の不具合から、確認すべき試験観点を整理する | 必須試験と安全関連試験の選定 | 実行時間、未実施ケース、障害流出 |
| 実機ログ解析の属人化 | ログの整形、時系列の要約、類似障害の候補提示を行う | 原因の特定、対策、障害クローズ | 一次切り分け時間、再現率、復旧時間 |
組み込みソフトウェア向けのIPA資料では、コーディング、設計、テスト、バグ管理、開発プロセス、品質指標、計画立案を個別に扱っています。[2] AI活用もこの分け方に沿って設計すると、対象業務と責任者を明確にしやすくなります。
AIを既存の品質プロセスに組み込む手順
1. 対象製品と品質上の境界を固定する
最初は全社展開ではなく、一つの製品群、一つの開発工程、一つのリリース周期に範囲を限定します。対象製品で求められる安全、セキュリティ、顧客承認、変更管理の手順を確認し、AIに任せない判断を明文化します。たとえば、リリース可否、品質記録の承認、障害の最終原因判定は、権限を持つ担当者が行います。
2. 識別子と証跡をつなぐ
AIの出力精度を高める前に、要件ID、設計書、コミット、テストケース、障害票、基板・ファームウェアの版数を対応付けます。これは、変更影響の確認と回帰試験の説明可能性のために必要です。追跡関係が不明なままAIの提案を採用すると、確認漏れが起きても根拠をたどれません。
3. PoCは「人が正誤を判定できる工程」から始める
最初の検証では、レビュー観点の整理、ログの一次分類、テスト仕様の候補抽出など、既存の担当者が結果を比較できる業務を選びます。PoCの開始前に、評価期間、対象件数、正解として扱う基準、利用しない情報、失敗時の戻し方を定めます。
| PoCで決める項目 | 確認内容 |
|---|---|
| 目的 | 例：障害ログの初動整理を補助し、担当者が確認すべき情報を早くそろえる。 |
| 対象 | 製品群、データ期間、工程、利用者、除外する安全・機密情報。 |
| 指標 | 作業時間だけでなく、見落とし、再調査、品質記録、利用者の確認負荷。 |
| 判定 | 従来手順との比較方法、継続・停止・再設計の判断者。 |
| 記録 | 入力データ、出力、レビュー結果、例外、モデル・ツールの変更履歴。 |
4. 提案・レビュー・限定自動化の順で広げる
PoCで妥当性を確認した後も、いきなり実機書き込みや自動マージに進むのではなく、まずは提案のみ、次にレビュー補助、最後に限定的な自動化へ進めます。AIが生成したコード、テスト観点、障害要約は、既存の承認ゲートを通過して初めて正式な成果物として扱います。
5. データと契約の扱いを確認する
ソースコード、仕様、障害票、ログには、機密情報や取引先情報が含まれる場合があります。AIサービスを利用する前に、入力するデータの範囲、保存・学習への利用、アクセス権、生成物の利用条件、第三者提供、終了時の扱いを確認します。経済産業省はAIの利用・開発に関する契約上の確認事項を整理しており、導入担当者と法務・セキュリティ担当者が確認する材料になります。[3]
効果を過大評価しない評価方法
AI導入の成否を、特定の削減率や費用と便益の比較期間で一律に示すことはできません。対象工程、既存のCI・試験設備、ソースコードの機密性、製品の安全要求、教育・保守の負荷で条件が大きく変わるためです。
評価では、次のように「従来の方法と同じ定義で比較できる指標」を用います。
| 観点 | 指標の例 | 注意点 |
|---|---|---|
| 効率 | レビュー待ち時間、ログ一次切り分け時間、回帰試験の実行時間 | AIの確認・修正に必要な時間も含める。 |
| 品質 | 不具合の再オープン、障害流出、テストの再実行 | 短期的な工数減だけで品質低下を見落とさない。 |
| 追跡性 | 要件・設計・テストの関連付け、変更根拠の記録 | 出力を採用した理由とレビュー担当者を残す。 |
| 運用 | 利用率、例外処理、問い合わせ、ツール変更の影響 | モデル更新やデータ変更時も比較できるようにする。 |
よくある失敗と避け方
品質責任まで自動化しようとする
AIによる候補提示と、製品品質の承認は別の作業です。コーディング規約、設計レビュー、実機試験、リリース判定の責任者を明確にし、AIの出力が誤っていた場合の再確認手順を定めます。
外部サービスに機密情報をそのまま入力する
利用規約と契約条件を確認しないまま、ソースコード、未公開仕様、障害ログを入力してはいけません。生成AIの導入・運用では、利用ルール、リスク管理、セキュリティ対策を文書化して運用することが重要です。[4]
すべての試験をAIの優先度付けに任せる
変更影響の整理は有用でも、安全機能、規制対応、リリース前に必須と定めた試験は、AIの優先度にかかわらず実施する必要があります。AIの提案は、試験計画を見直す材料として扱います。
まとめ
組み込みソフトウェア開発でAIを活かすには、要件追跡、レビュー、回帰試験、ログ解析など、既存の品質プロセスを補助する領域から始めます。対象を一つに絞り、評価基準と人による承認を先に定め、記録を残しながら段階的に広げることが重要です。
ArcHackでは、対象業務の整理、PoCの評価項目設計、データ・契約上の確認事項、既存プロセスへの接続を支援しています。導入の可否を判断する段階から、状況に合わせてご相談ください。
よくある質問（FAQ）
Q1. 組み込みソフトウェア開発では、最初にどの工程へAIを適用すべきですか？
安全性や品質に関わる最終判断を自動化する前に、要件・設計・テストの対応付け、レビューの観点整理、ログの一次分類など、結果を既存の担当者が確認できる工程から始めます。対象製品群と評価指標を一つに絞り、従来手順との比較で有効性を確認します。
Q2. 生成AIが出力したコードやテスト観点を、そのまま採用してもよいですか？
そのまま正式成果物として扱うのではなく、既存のコーディング規約、設計レビュー、テスト、変更管理の手順に載せて確認します。AIの出力を誰がレビューし、どの記録を残し、誤りがあった場合にどう戻すかを事前に定めます。
Q3. AIの導入効果はどのように評価すればよいですか？
工数だけでなく、レビュー待ち時間、要件からテストまでの追跡性、回帰試験の実行時間、障害の一次切り分け時間、障害流出、修正後の再試験負荷などを、導入前後で同じ定義により測ります。費用や回収期間は、対象工程、既存ツール、セキュリティ要件、教育・運用を含めた自社の前提で試算します。
参考資料
[2] IPA「高品質な組込みソフトウェア開発（ESxR Series）」
