概要と適用範囲
本書は、組込みソフトウェア開発においてAIやDX技術を活用してシステム開発と内製化を進めるための実務ガイドです。目的は「実行可能な手順」と「品質・安全を担保するガバナンス」の両立です。想定読者は、製品開発責任者、プロジェクトマネージャー、組込みソフト開発チーム、QA担当者です。
適用範囲：要件定義、アーキテクチャ設計、コード生成補助、レビュー支援、CI/CD・自動テスト、エッジ推論モデルの実装・検証、運用データのフィードバックループ。法的・安全性の最終判断は必ず社内の責任者が行ってください。
業界特有の実務上の課題（簡潔整理）
- ハード依存性（ドライバ、ボード設計、電源・タイミング要件）
- 技術資産の属人化（暗黙知が多い、ドキュメント不足）
- 高い検証負荷（リアルタイム性・安全性の証跡が必要）
- データ・機密性（製品ログや顧客データの取り扱い制限）
- 人材と教育（組込みとAIの両方の知見が求められる）
これらに対し、本ガイドは「誰が何を確認するか」を明示した手順を提供します。
実務手順（PoCから本番まで）
以下は推奨される段階的手順。各ステップでの成果物、責任者、合否判定基準を併記します。
-
現状分析（インプット：既存ソース、ビルド手順、テスト仕様）
- 成果物：資産台帳（コード、ボード、ツール）、依存マップ、主要要求リスト
- 責任者：プロジェクトマネージャー（PM）
- 合否基準：重要機能のトレース可能性（トレーサビリティマトリクス作成）
-
優先機能の選定とモジュール化計画
- 成果物：モジュール図、インタフェース定義、モジュールごとの品質要件
- 責任者：ソフトウェアアーキテクト
- 合否基準：モジュール単位で独立してテスト可能であること
-
PoC設計（技術・運用の検証）
- 成果物：PoC仕様書（目的、データ、テストケース、計測KPI、合否判定表）
- 責任者：PoCリード（技術責任者）＋QA
- 合否基準：事前に定義した受け入れ基準に合致すること（以下のKPI例を参照）
-
PoC実行と評価
- 成果物：実験ログ、テスト結果、リスク評価レポート
- 責任者：PoCチーム
- 合否判定：PMと品質責任者が判定。合格ならスケール計画へ。未達成なら原因分析と改善案提示。
-
本開発・内製化フェーズ
- 成果物：CI/CDパイプライン、ビルド・リリース手順、運用ドキュメント、教育計画
- 責任者：開発リード、サイト信頼性エンジニア（SRE）/運用担当
- 合否基準：自動ビルド・自動テストの安定稼働と、レビュー・承認フローの実装
-
運用・継続改善
- 成果物：運用ログ、教訓（レトロスペクティブ）、モデル更新計画
- 責任者：運用チーム、製品オーナー
- 合否基準：品質指標が定常的に満たされること、エスカレーションが機能すること
PoC設計：必須要素と受け入れ基準の例
PoC仕様書に含める項目（必須）
- 目的と検証項目（何を「できる」と評価するか）
- 入出力データの定義（サンプル数、フォーマット、匿名化の方法）
- 測定KPI（定義式を必ず記載）
- 試験環境（ハードウェア条件、RTOS設定、電源・温度条件）
- セキュリティ要件（アクセス制御、ログ保管、データ消去手順）
- 人的確認ポイント（どのレビューを誰が行うか）
- 受け入れ判定フロー（合格基準・不合格時の次ステップ）
KPIの例と計算式（必ず社内前提で調整）
- ビルド成功率 = 成功ビルド数 / 全ビルド数
- 単体テストカバレッジ = カバレッジ取得ツールでのライン/分岐カバレッジ
- リソース消費（推論） = 平均CPU% / メモリ使用量（MB） / 電力（W）
- 回帰検出時間 = 問題発見時刻 − 最終安定ビルド時刻
※ 上記は計測式の例です。閾値は製品要件に合わせて設定してください。
責任分界（RACI表の雛形）
| 活動 | R | A | C | I |
|---|---|---|---|---|
| 現状分析 | PM | PM | アーキテクト, QA | 経営 |
| PoC設計 | 技術責任者 | PM | QA, 運用 | ステークホルダ |
| モデル検証 | AIエンジニア | 技術責任者 | QA | PM |
| CI/CD導入 | SRE | 開発リード | 開発チーム | QA |
| リリース承認 | QA | 製品オーナー | 法務（契約） | 利害関係者 |
R=Responsible, A=Accountable, C=Consulted, I=Informed。社内で明確に承認者を決め、ドキュメントに署名痕跡を残してください。
テスト戦略（組込み特有の注意点）
- ハードウェアイン・ザ・ループ（HIL）やシミュレータを早期に整備し、ハード依存のテストを自動化する。
- リアルタイム要件はベンチマークで検証し、スケジューラのジッタや割込みレイテンシを測定して記録する。
- セーフティクリティカル機能は「フォールトモデル」と「フォールト注入試験」を設計に組み込む。
- 生成AIやコード支援ツールが生成したコードは、スタイル・規約チェックと人によるセキュリティレビューを必須にする。
例外処理とエスカレーション手順（運用面）
- 問題検出（自動アラート／現場報告）
- 一時対応（回避策の適用、影響の隔離）
- 影響範囲評価（ソフト/ハード/顧客影響）
- 永久対策の設計と優先度付け（根本原因分析）
- 修正のテスト（回帰テスト含む）
- リリースと顧客通知（必要時）
- レトロスペクティブとドキュメント更新
エスカレーションはレベル定義（例：L1＝現場、L2＝開発リード、L3＝製品オーナー）と対応時間目標を定義してください。
契約・データ利用チェック（選定時の必須項目）
ベンダーやクラウドサービスを使う場合は、以下を確認・文書化すること。
- データ利用範囲と第三者提供の可否（経済産業省のチェックリストを参照）
- SLA（可用性、サポート窓口、障害時対応）
- 知的財産の帰属（生成物の取り扱い）
- 脆弱性対応ポリシーと通知義務
- 退去時のデータ消去・移行手順
契約テンプレートにこれらを反映し、法務と必ず協議してください。
KPI運用・定量評価のワークフロー（実務）
- KPI定義（測定式・データソース明示）
- 定期計測（週次・月次）
- 閾値超過時のアクションプラン（担当者、期限）
- 改善施策の効果測定（施策前後で同一条件で比較）
- ドキュメントとナレッジ共有（社内Wiki等）
測定に使うログやメトリクスは長期保存ポリシーと併せて設計してください。
導入時のチェックリスト（短縮版）
- 資産台帳とトレーサビリティマトリクスの作成
- PoC仕様に受け入れ基準を明記
- セキュリティ・契約要件の事前確認
- CI/CD + 自動テストの最低ラインを定義
- 責任分界（RACI）の社内合意
- 教育計画（オンボーディング教材とレビュー頻度）
- 運用エスカレーション手順の整備
FAQ（本文内補足）
Q. PoCが失敗した場合はどうする？ A. まず失敗原因を分類（要件定義の不足、データ不足、ハード制約、実装ミス）し、短期（代替策）・中期（改善計画）・長期（方針見直し）の対応を決定。費用やスケジュールを再試算してステークホルダに報告します。
Q. 生成AIが出力したコードをそのまま使えますか？ A. 生成物は参考として扱い、必ず静的解析・規約チェック・セキュリティレビュー・動作検証を実施してください。最終判断は担当のエンジニアとQAが行います。
問い合わせ（控えめな導線）
本ガイドの適用に関する社内相談やPoC設計支援が必要な場合は、所属組織内のプロジェクト支援窓口、技術相談窓口、または法務・セキュリティ担当にお問い合わせください。外部協業を検討する場合は、契約条件とデータ利用範囲を事前に確認してください。
AI出力についての注意
本ドキュメントはAIを用いて整理・提案した内容を含みます。提示した手順やチェックリストは実務的な補助を目的としていますが、品質・安全・法令順守の最終判断は担当者（プロジェクト責任者、QA、法務等）が行ってください。
ArcHackでは、対象業務の整理、PoCの評価設計、品質・運用プロセスへの接続を支援しています。
よくある質問（FAQ）
Q1. 内製化を検討する際、まず何を検証すべきですか？
まず現状の技術資産の棚卸し（ソース、ドライバ、ボード構成、ビルド手順、テスト資産）、クリティカルな品質要求（安全性・リアルタイム性）、および外部依存（外注、サプライヤー）を確認してください。それを基にPoCで技術的実現性、テストカバレッジ、運用負荷を検証します。
Q2. PoCの合否判定はどのように行えばよいですか？
合否判定は事前に定義した受け入れ基準（性能、リソース消費、テスト自動化の達成度、セキュリティ要件の適合）に基づき行います。判定は開発責任者・QA・運用担当が合意して行い、失敗時のエスカレーション経路と再試行条件も定義してください。
Q3. AI（生成系含む）を開発プロセスで使う際の注意点は？
生成AIを含むAI利用は、入力データの機密性・著作権、生成物の検証体制、ログ・トレーサビリティ、ベンダー契約での利用範囲を必ず確認してください。生成物は必ず人がレビューし、品質・安全の最終判断は担当者が行ってください。