組み込み開発(実機動作)でAI駆動開発を用いた時の失敗談

この記事は、AI駆動開発で生成したコードを組み込み製品の実機で動かしたとき、シミュレータでは見えなかった問題がどこで出てくるか、そしてバグ修正にどれだけ時間がかかるかをまとめたものです。
(ちょっと内容としては古いかも・・もしかしたらモデルによっては解決できる問題かもしれません)

---

シミュレータでデバッグ完了、実機でNG

AI駆動開発でコードを生成→シミュレータ上でテスト→OKを確認→実機に書き込む、という流れで進めると、実機検証でNGになるケースが想定より多かった。

一例を挙げる。I2Cセンサーの読み取り処理をAIに生成させた。

uint8_t read_sensor(uint8_t reg_addr, uint8_t *data, uint8_t len) {
    uint8_t result;
    
    result = i2c_write(SENSOR_ADDR, &reg_addr, 1);
    if (result != I2C_OK) return result;
    
    result = i2c_read(SENSOR_ADDR, data, len);
    return result;
}

シミュレータ上では問題なく動いた。実機でテストすると、データが化けることが断続的に発生した。

原因はI2Cのストップコンディションとスタートコンディションの間のウェイトだった。対象センサーのデータシートには「Stop→Startの最小待ち時間：1.3μs」という記載があった。シミュレータはこの時間制約を無視する。実機のバスはごまかしてくれない。

修正はこうなった。

uint8_t read_sensor(uint8_t reg_addr, uint8_t *data, uint8_t len) {
    uint8_t result;
    
    result = i2c_write(SENSOR_ADDR, &reg_addr, 1);
    if (result != I2C_OK) return result;
    
    delay_us(2);  /* Stop-Start minimum: 1.3us (datasheet p.18) */
    
    result = i2c_read(SENSOR_ADDR, data, len);
    return result;
}

delay_us(2) 1行だけの修正だが、これに気づくまでに数時間かかった。AIはデータシートを読んでいない。

---

AIが知らない「製品固有のクセ」

問題はタイミングだけでなく、製品固有の動作特性にも出てくる。

AD変換処理をAIに実装させると、こんなコードが出てくる。

uint16_t read_adc(uint8_t channel) {
    adc_select_channel(channel);
    adc_start_conversion();
    while (!adc_conversion_complete());
    return adc_get_result();
}

これはADCとしては正しいコードだ。ただし実機で使うと、特定の環境条件下でサンプル値がバラつく。

理由は実装した回路の入力インピーダンスと、ADCのサンプリングホールド時間の関係だった。基板の回路設計から入力インピーダンスを計算し、それに合わせてサンプリングクロック設定を変える必要があった。この情報は回路設計書にある。AIはそれを知らない。

uint16_t read_adc(uint8_t channel) {
    adc_select_channel(channel);
    adc_set_sample_time(ADC_SAMPLETIME_480CYCLES);  /* 入力インピーダンス10kΩに合わせた設定 */
    adc_start_conversion();
    while (!adc_conversion_complete());
    return adc_get_result();
}

こういう修正は、実機を動かして数値を見て、回路図と照らし合わせて、初めてたどり着く。AIへの問い合わせで解決するものではない。

---

バグ修正に時間がかかる本当の理由

シミュレータでOKでも実機でNGになるパターンを整理すると、以下のものがある。

• タイミング制約（セットアップ時間、ホールド時間、バス間ウェイト）
• ハードウェア固有のキャリブレーション手順
• 電源投入シーケンスへの依存
• 回路定数に依存するレジスタ設定
• 実負荷による電圧変動の影響

これらは全て、ハードウェアの情報がなければわからない。AIはソフトウェアの文脈でコードを生成するが、このような問題はソフトとハードの境界面に潜んでいる。

しかもこの類のバグは再現条件が限定的なことが多く、「環境によって出たり出なかったりする」。デバッグに費やす時間は長くなる。

---

組み込みAI駆動開発との正しい付き合い方

実機検証でのNGを経験して、使い方を変えた。

AI生成コードは「参考」として扱う

アルゴリズムの骨格、関数の構造、エラー処理の流れを参考にする。そのまま製品コードに採用しない。

ハードウェア依存部分は自分で書く

タイミング設定、レジスタ初期化、キャリブレーション処理は自分で書く。AIに渡せる情報がない。

チューニングは自分で行う

生成されたコードを起点に、実機での計測値を見ながら自分でパラメータを調整する。この工程はAIに代替させない。

組み込み開発におけるAI駆動開発の限界は、「ハードウェアを知らないこと」に尽きる。コードの品質問題ではなく、情報の非対称性の問題だ。

ハードウェアの情報を全てAIに渡せる環境が整えば話は変わるかもしれないが、現時点では「コードを出してもらって、ハードとの接合部は自分で仕上げる」という使い方が、一番効率がいい。

---