自動車のECU（電子制御ユニット）開発において、AIは「開発を少し速くするツール」ではなく、開発プロセスそのものを組み替えるインフラになり得ます。ホンダのE&Eアーキテクチャー開発現場の課題から出発し、「ソース納品を起点とした3つのAIループ」を考えました。
現状の課題
- 一致性検証があまりやられていない（文化として馴染んでいない）
- 指摘書のやり取りだけで膨大な時間が消費される
- 設計編でOKを出しても、実装段階で漏れが大量に発覚
- 品質担保が個人の経験値に依存しており、スケールしない
- 若手や経験の浅いメンバーが増え、「失敗してから学ぶ」サイクルに依存
3つのAIループ
🔄 ループ1：要求仕様の高速精緻化
日本語の要求仕様からAIがオートコードを生成 → エミュレーター（Renode等）で即座に動作確認 → フィードバックして要求仕様を修正。このループを高速で回します。
本質は「経験値に依存しない品質担保」です。
- 今：経験ある人の検証に依存 → スケールしない
- これから：AIに「勘所」をルーブリック化 → 誰でも最初から高品質な要求仕様を書ける
- 経験ある人の役割変化：自分で検証する → AIに「どこを見るべきか」を教える
「失敗してから精度を上げる」から「最初から失敗しない構造」へ。これがループ1の核心です。
🔒 ループ2：ソース管理AI（3層システム）
ソース納品が全ての起点です。ソースが揃えば、AIが以下を自動実行します。
- 一致性検証を自動実行 → 設計編の指摘書やり取りが不要に
- 不具合発生時はJiraとソースを横断比較 → 原因特定が一瞬で完了
- 複数サプライヤーのソースが揃えば、「どっちが悪い」問題が解消
- 3層AIでサプライヤーのソースを保護しつつ、解析結果だけを提供
🌐 ループ3：AI通信レイヤー（HIL統合）
各社の単体HILベンチをAI通信レイヤーで論理的に接続し、システムベンチ相当を構成します。
- モードA：サプライヤー未納品時 → ループ1のオートコードを対抗機モデルとして利用
- モードB：サプライヤー納品済み → ソース管理AI経由でCAN信号処理をAPI化
各社は単体開発に集中でき、AIがシステム全体の繋ぎを担保します。
Before / After
Before（現状）
- 指摘書の往復で週単位のロス
- 品質 = 個人の経験値に依存
- システムベンチのために大規模な設備と調整が必要
After（3ループ導入後）
- 一致性検証はAIが自動実行 → 指摘書の往復なし
- 品質 = ルーブリック化されたシステムが担保
- 単体ベンチの組み合わせでシステムベンチ相当を実現
コア思想
「みんなが単体の開発を標準ワークの中でやれば、全員が助かる。集中するべきところに集中すれば、周りはAIが繋いでいく」
これは夢物語ではありません。各ループは既存技術の組み合わせで実現可能です。重要なのは技術そのものよりも、ソース納品を起点にした開発プロセスへの転換です。
まとめ
- 🔑 ソース納品が全ての起点 — これが揃えばAIループが回り始める
- 🔄 ループ1は「経験依存」から「システム担保」への転換点
- 🔒 ループ2は指摘書文化を自動検証に置き換える
- 🌐 ループ3は大規模設備を論理接続で代替する
- 💡 経験ある人の役割は「検証する人」から「AIに勘所を教える人」へ
現場の課題から逆算して設計した3つのループです。まずはループ1の「経験値をルーブリック化する」取り組みから始められるはずです。
