2026年5月頃、Claude.ai（チャット）を使って趣味で作ったツールの開発記録です（全4回の第4回）。
はじめに
最終回は、開発全体を振り返ります。
AIが間違えた例
| 内容 | 正しいもの | 気づいたきっかけ |
|---|---|---|
パッケージ名 python-udsoncan
|
udsoncan |
pip install のエラー |
API名 Response.Code.positiveResponse
|
PositiveResponse |
テスト実行時のエラー |
テスト用の設定 QT_QPA_PLATFORM=offscreen をメインウィンドウのコードに書いた |
テストコード側だけで設定する | 起動してもGUIが正しく表示されなかった |
どれも、コードを読んだ時点では気づかず、実行して初めてわかりました。
TDDは守れていなかった
本来のTDD
エンジニアがテストを書く
↓
Red（失敗）を確認
↓
AIに実装を依頼
↓
Green（成功）を確認
↓
リファクタリング
実際にやっていたこと
AIにテストと実装の両方を依頼
↓
生成されたコードに目を通す
↓
実行して確認する
テストの設計も実装も、ほぼAIに任せていました。pytestの仕組みも、理解しきれていない部分があります。
それでもテストは役に立ちました。AIが書いたテストでも、実行すればAIのコードの間違いを見つけられます。機能を足すときに、既存の動作が壊れていないかも確認できます。
本来は、テストを人が書き、実装をAIに任せるべきだと考えています。テストを書くことは「何を確認するか」を決める作業で、そこは人が判断する部分だからです。次に何か作るときは、この進め方を試します。
組込み開発の経験が役立った点
| 経験 | 役立った場面 |
|---|---|
| HAL・レイヤー設計 | AIが各層の処理を混ぜたコードを出したとき、すぐに問題に気づけた |
| 異常系の確認 | 「NRC応答は？」「接続が切れたら？」をAIに確認できた |
| プロトコルの知識 | AIのコードがプロトコル仕様と合っていないことに気づけた |
予想どおりだったこと・予想外だったこと
| 内容 | |
|---|---|
| 予想どおり | 開発は速くなった。設計方針をプロンプトに書くと、出力の質が上がった |
| 予想外（良かった点） | テストが役に立った。ECUシミュレータで確認の手間が減った |
| 予想外（課題） | 理解が追いつかない部分が出た。TDDを守れなかった |
AIと人の役割分担
| AIに任せたこと | 人がやったこと |
|---|---|
| コードの生成 | 設計の判断・レビュー |
| 定型的な実装 | ドメイン知識（UDS・DoIP）の提供 |
| ライブラリの候補出し | テストを実行して動作を確認 |
コードをすべて読んでレビューするのは大変です。テストがあれば、「仕様どおりのテストがあるか」「異常系をカバーしているか」という観点でレビューできます。AIが書くコードが増えるほど、この方法が使えると考えています。
やり残したこと
今回はここまでで開発を終えました。拡張するなら、次の項目です。
| 項目 | 内容 |
|---|---|
| DoIP通信の強化 | 再接続・タイムアウト処理 |
| SecurityAccess（0x27） | 未対応 |
| UDS on CAN | ISO-TP + python-can で実装。Protocol層を差し替えれば対応できる設計にしてある |
おわりに
| 目的 | 結果 |
|---|---|
| Python・pytestの学習 | 基本は身についた。テストはまだ理解しきれていない |
| 設計の練習 | レイヤー設計とStrategyパターンを実践できた |
| AIとの役割分担 | コードの生成はAI、判断は人、という分担が明確になった |
| 手軽に使えるツール | DoIPの主要なSIDは、ECUシミュレータで動作を確認した |
AIを使うと、コードを書く量は減ります。一方で、設計・レビュー・ドメイン知識は人の側に残りました。