AI駆動開発とメモリ制約の話 #C - Qiita

AI駆動開発とメモリ制約の話 #C - Qiita 2 いいねしたユーザー一覧へ移動 0 X（Twitter）でシェアする Facebookでシェアする はてなブックマークに追加する more_horiz 記事を削除する close 一度削除した記事は復旧できません。 この記事の編集中の下書きも削除されます。 削除してよろしいですか？ キャンセル 削除する delete @ tai0921 ( tai 0921 ) AI駆動開発とメモリ制約の話 C AI メモリ管理 組み込み AI駆動開発 2 投稿日 2026年03月25日 この記事は、組み込みC開発にAI駆動開発を取り入れてみて、メモリ管理の面でぶつかった問題と、その対処についてまとめたものです。 AIが生成するコードはメモリを気にしない AI駆動開発でコードを生成させると、たいてい「動く」コードが出てくる。しかし組み込み開発では「動く」と「製品として使える」の間には大きな溝がある。その溝の代表格がメモリ制約だ。 試しに「センサーデータをバッファリングしてUART送信する処理」を生成させると、こんなコードが平気で出てくる。 #include <stdlib.h> #include <string.h> typedef struct { float * data ; int size ; int capacity ; } SensorBuffer ; SensorBuffer * create_buffer ( int initial_capacity ) { SensorBuffer * buf = ( SensorBuffer * ) malloc ( sizeof ( SensorBuffer )); buf -> data = ( float * ) malloc ( sizeof ( float ) * initial_capacity ); buf -> capacity = initial_capacity ; buf -> size = 0 ; return buf ; } void push_data ( SensorBuffer * buf , float value ) { if ( buf -> size >= buf -> capacity ) { buf -> capacity *= 2 ; buf -> data = ( float * ) realloc ( buf -> data , sizeof ( float ) * buf -> capacity ); } buf -> data [ buf -> size ++ ] = value ; } malloc 、 realloc 、動的サイズ拡張。PC向けのコードとしては普通だが、RAMが数十KBのマイコンで動かすコードではない。 AIはヒープ断片化を知らない 問題はmalloc禁止かどうかだけではない。仮にヒープ使用が許可された環境でも、AIが生成するコードはヒープ断片化のリスクを考慮しない。 長時間稼働する組み込み製品でmalloc/freeを繰り返すと、物理メモリは余っているのに連続した空きが取れなくてアロケーションに失敗する。これは実機を長時間動かして初めて気づく類の問題で、AIには当然わからない。 AIは「今この瞬間に動くコード」を書く。「3ヶ月連続稼働しても壊れないコード」を書く責任感は持っていない。 静的メモリでの再設計をAIに任せると何が起きるか 「mallocを使わず静的メモリで書き直して」と指示すると、それなりのコードは出てくる。 #define SENSOR_BUFFER_SIZE 64 static float sensor_buffer [ SENSOR_BUFFER_SIZE ]; static int buffer_index = 0 ; void push_data ( float value ) { if ( buffer_index < SENSOR_BUFFER_SIZE ) { sensor_buffer [ buffer_index ++ ] = value ; } } 形にはなった。ただしここに問題が残っている。 SENSOR_BUFFER_SIZE の根拠がない（64は適当な数字） バッファフルのときサイレントに捨てている（エラー処理なし） buffer_index が static 変数として隠れており、複数インスタンスに非対応 スタック消費の見積もりが出力されない サイズ定数の根拠は、製品のサンプリングレートと通信周期から計算するしかない。その計算式はシステム仕様書にある。AIはそのドキュメントを読んでいない。 結局どこで使えて、どこで使えないか AIにメモリ設計を任せるのは無理だと割り切って、役割を分けた。 AIに任せること バッファ処理、ステートマシン、パーサーなど、アルゴリズムのロジック部分 関数の骨格とインターフェース定義 Doxygenコメントの生成 自分でやること バッファサイズの計算と根拠の記録 スタック・ヒープの使用量見積もり メモリマップへの影響確認 長時間稼働を想定したリソースリーク確認 AIが書いたコードを採用する前に、必ずメモリ関連の部分だけ自分でチェックする工程を挟む。自動化できない部分はここだ。 まとめ AI駆動開発はC言語のメモリ制約に対して無頓着だ。動的メモリの乱用、バッファサイズの根拠なし、ヒープ断片化リスクの無視。これらは組み込み製品では致命的になりうる。 AIをコード生成に使うなら、メモリ設計だけは自分の手を離してはいけない。ここを外注できる日は、少なくとも今はまだ来ていない。 2 いいねしたユーザー一覧へ移動 0 comment 0 コメント一覧へ移動 新規登録して、もっと便利にQiitaを使ってみよう あなたにマッチした記事をお届けします 便利な情報をあとで効率的に読み返せます ダークテーマを利用できます ログインすると使える機能について 新規登録 ログイン 2 いいねしたユーザー一覧へ移動 0 more_horiz 記事を削除する close 一度削除した記事は復旧できません。 この記事の編集中の下書きも削除されます。 削除してよろしいですか？ キャンセル 削除する delete