前回は、AIを使ってOBDの取得プログラムを作り、車両から返った応答を残すところまでを紹介しました。今回は、2009年式Mercedes-Benz W204 C63 AMGで得た初回ログを読みます。標準OBDの保存・保留故障コードは0件でした。それでも、始動不良の原因は確定していません。

故障コードの件数を見るときは、「どの範囲に問い合わせた結果か」を一緒に確認する必要があります。この一回の取得で分かったことと、次の測定に残ったことを整理します。

DTCはDiagnostic Trouble Codeの略で、診断で読み取る故障コードを指します。

キーONで取得したデータ #

測定日は2026年10月13日。OBDLink EXを車両のOBD端子とWindows PCに接続し、キーON・エンジン停止の状態で取得しました。ISO 15765、11-bit、500 kbit/sを指定した通信で、約4.4秒の取得中に2つの応答アドレスから返答がありました。自動検出の結果ではなく、この設定で通信を確認した記録です。

7E8と7E9は返答のアドレスです。Mercedesの具体的な制御ユニット名との照合はまだ行っていません。VIN（車台番号）も取得できましたが、この記事では個体を識別する情報を掲載していません。

エンジン停止中なので、回転数0 rpmはその測定条件と整合します。一方、絶対スロットル位置16.08 %は、ペダルをその割合だけ踏んだことを示す値ではありません。項目名を正しく残すことで、数字だけを見た解釈の取り違えを減らせます。

0件と未取得を分ける #

標準OBDには、保存DTCを読むMode 03、保留DTCを読むMode 07、恒久DTCを読むMode 0Aなど、用途ごとにサービスがあります。取得対象の区分を分けることから、結果の読み方が始まります。（OBD Solutionsのサービス一覧）

今回の保存DTC要求では、次の応答を記録しました。

要求 03
応答 7E9 02 43 00
応答 7E8 02 43 00

この2アドレスの返答から、保存された標準OBD DTCが0件だったと解釈しています。保留DTCも0件でした。しかし、SAM・EIS・ESPなどのメーカー固有の故障メモリーには、今回のプログラムで問い合わせていません。標準OBDの0件を「車両の全システムにエラーなし」に広げることはできません。

恒久DTCでは NO DATA が返りました。解析結果では、件数を0にせず「未取得」として残しています。応答がないことだけでは、コードがないのか、対応や通信条件の問題なのかを区別できないからです。集計表を作る際に空欄をすべて0へ変換すると、ここで意味が変わってしまいます。

AIには結果を要約させますが、その入力にはサービス番号、応答アドレス、生の返答、解析の状態を付けます。結論が気になったときに元の応答へ戻れる形にすることが、文章だけの説明より役立ちました。

症状と測定条件を並べる #

過去には、冷間始動直後に冷却ファンが高速回転したという報告がありました。今回のキーON・エンジン停止では高速回転しませんでした。水温21 ℃も得られましたが、始動後とエンジン停止中では条件が違います。この結果だけでファンの症状が解消したとは判断していません。

始動操作については、スターターが「キュルッ」と一瞬エンジンを回して止まった、という報告がありました。過去の完全無反応という状態とは分けて記録します。今回のログはその瞬間を測っていないため、0 rpmや11.6 Vを始動操作中のデータとして使うことはできません。

キーOFFで取得したOBD端子電圧は11.9 V、キーONの初回取得では11.6 Vでした。これはアダプタ側で読んだ値であり、バッテリー端子の休止電圧や、始動時の電圧降下を直接測った結果ではありません。次は充電と測定ができる条件を整え、バッテリーや主電源供給を確認する予定です。現在の値だけでバッテリー交換を決める段階にはありません。

AIに渡す情報を整える #

今回の取得で確認できたのは、指定した条件で標準OBDが応答し、いくつかの値を保存できたことです。始動許可や車両全体のCAN通信、各モジュールの正常性までは分かっていません。

AIと診断を進める際も、取得できた項目、未取得の項目、人が観察した症状を分けて渡すと、次に何を確かめるべきかを検討しやすくなります。

今回は電源状態の確認を優先し、その後にメーカー固有の診断へ進む方針にしました。次回は、既存のOBDLink EXでその診断を試すために、何を調べ、どこまでプログラムを準備したかを紹介します。