結論：自動車整備業（認証工場・自動車特定整備事業者）の「特定整備記録簿」は、道路運送車両法第91条で記載事項が条文レベルで固定された定型記録業務であり、2020年4月の「分解整備→特定整備」移行と2024年4月の電子制御装置整備の本格運用開始でチェック項目が増えたいまこそ、Claude Codeで記録簿の構造化と欠落チェックをスクリプト化する投資対効果が高いタイミングです（本記事は想定モデルケースの試算です）。
- 要点1：特定整備記録簿は記載日から2年間の保存義務があり（道路運送車両法第91条第3項）、点検整備記録簿とは根拠法令・保存期間が別物。混同すると監査で誤った運用を指摘されるリスクがある
- 要点2：2020年4月の制度改正で「分解整備」が「特定整備」へ拡大され、自動ブレーキ用カメラ・レーダーなどの電子制御装置整備（エーミング）も対象に追加。2024年4月から本格運用が始まり、記録すべき装置・作業の種類が増えている
- 要点3：車両識別情報・総走行距離・整備主任者名など記載事項は条文で列挙されているため、予約・入庫データが構造化されていればドラフト生成と欠落チェックは機械集計＋整備主任者確認の型に載る
対象読者：認証工場・指定整備工場の工場長・整備主任者・経営層、複数拠点の記録業務を束ねる管理部門、自動車整備業のDXを支援するエンジニア・PM
今日やること：直近1か月分の特定整備記録簿（紙・システム出力どちらでも）を1つのフォルダに集め、後述の「構造化プロンプト」を1本試す
事例出典：想定シナリオ（モデルケース）
本記事は、複数業界での導入支援経験をもとに構成した想定モデルケースです。登場する工場・数値はすべて仮想のモデルであり、実在企業の実測値ではありません。効果の数値はすべて「試算」です。
自動車整備業の記録ルールは、この数年で静かに、しかし確実に書き換わっています。令和2年（2020年）4月に施行された改正道路運送車両法により、従来の「分解整備」制度は「特定整備」制度へと名称を変え、対象範囲が拡大されました。エンジン・ブレーキ・ステアリングなど装置を取り外して行う従来の分解整備に加え、自動ブレーキに使われる前方監視カメラやミリ波レーダーの調整（いわゆる「エーミング」）のように、取り外しを伴わなくても装置の作動に影響を及ぼす整備が「電子制御装置整備」として新たに規制対象に含まれています。電子制御装置整備の認証取得には4年間の経過措置期間が設けられ、令和6年（2024年）4月1日にその経過措置が終了し、制度の本格運用が始まりました。
根拠法令は道路運送車両法です。自動車特定整備事業者（認証工場）は特定整備を行った際、車両識別情報・整備概要・完了年月日・依頼者の氏名及び住所・総走行距離・整備主任者名・事業者の認証番号などを特定整備記録簿に記載し、使用者へ写しを交付する義務があります（同法第91条）。そして特定整備記録簿は記載の日から2年間の保存が義務付けられています（同条第3項）。ここで注意が必要なのは、同じ「整備の記録簿」でも、ユーザー車検を含む定期点検の記録である点検整備記録簿とは根拠条文も保存期間も別物だという点です。点検整備記録簿は点検の種類によって保存期間が1年〜2年と異なり、特定整備記録簿の一律2年とは制度が独立しています。整備工場では日常的に両方の帳票を扱うため、この違いを曖昧なままシステム化すると、監査で「別の帳票の保存ルールを流用していた」という指摘を受けかねません。
ASV（先進安全自動車）技術の普及により、電子制御装置整備の対象になる入庫車両は今後も増えていく見込みです。整備士12名・フロント3名・管理3名の従業員18名、年間車検・整備台数の想定約4,800台の認証工場F社（想定モデル）を題材に、Claude Codeでこの記録業務をどう圧縮するかを実装レベルで解説します。車両系の法定記録という切り口では、以前に取り上げた貸切バスの点呼・運行指示書の効率化事例と共通する設計思想がありますが、根拠法令・記載事項はまったく別物です。
導入前の状況：紙の特定整備記録簿と「台帳への手書き転記」
想定モデルのF社の業務フローはこうです。
- 入庫・特定整備の実施：車検・分解整備・電子制御装置整備（エーミング含む）を実施した際、整備主任者が紙の特定整備記録簿に車両登録番号・整備概要・走行距離・完了日・依頼者情報を手書きで記入
- 使用者への交付：記録簿の写しをコピー機で複写し、車検証入れとともに使用者へ手渡し。控えは工場内のバインダーに整備完了日順で綴じる
- 電子制御装置整備の記録：エーミング作業を行った場合、対象装置（前方カメラ・ミリ波レーダー等）と作業内容を別紙のチェックシートに記入し、特定整備記録簿とは別に保管
- 監査・立入検査対応：運輸支局や地方の適正化事業実施機関による立入検査の前に、バインダーから該当車両の記録簿を数日がかりで探し出す
ボトルネックは3つありました。第一に記載事項の欠落。繁忙期は1日15台前後の入庫があり、走行距離の記入漏れや整備主任者名の記入漏れが、月末にまとめてチェックした時点で初めて見つかることが常態化していました。第二に電子制御装置整備の記録が特定整備記録簿と紐づいていないこと。エーミング用の別紙チェックシートと本体の記録簿がファイル上でも物理的にも分かれており、「この車両でどの装置のエーミングをやったか」を後から追うのに手間がかかっていました。第三に2年保存の期限管理が属人化していたこと。バインダーは年度ごとに新調していましたが、いつ処分してよい記録なのかを紙の日付を目視で確認する運用で、廃棄タイミングの判断が担当者任せになっていました。
Claude Codeに任せた4つの役割
- 特定整備記録簿の構造化とスキャン読み取り — 紙の記録簿のスキャンPDF・整備システムの出力CSVを統一スキーマのJSONに変換し、第91条の記載事項（車両識別情報・整備概要・完了年月日・依頼者氏名及び住所・総走行距離・整備主任者名・事業者の認証番号）を満たす月次台帳を生成する
- 記載事項の欠落チェックと2年保存期限の管理 — 空欄・記入不備を運行前に一覧化し、記載日を基準に2年保存の期限が近い記録を四半期ごとにフラグする
- 電子制御装置整備（エーミング）記録の突合 — エーミング用チェックシートと特定整備記録簿を車両IDで紐づけ、対象装置マスタと照らして記録漏れ・認証区分の食い違いがないかを検知する
- 監査・立入検査への横断検索レポート — 車両登録番号・依頼者・整備完了日をキーに記録簿を横断検索し、提示用の一覧ドラフトを数分で作る
共通する設計思想は「AIは記録の構造化・突合・下書きまで。整備内容の適否と最終確認は整備主任者」です。特定整備の要否や整備方法の適否といった安全に関わる判断は、資格を持つ整備主任者と、必要に応じて所管の運輸支局・地方運輸局への確認で固める運用を崩しません。
実装スタックとリポジトリ構成
- Claude Code（Anthropicのエージェント型コーディングCLI）＋ Python 3.12
- 入力：特定整備記録簿スキャン（PDF/JPEG）、整備システム出力CSV、エーミング用チェックシートのスキャン、入庫予約データ
- 出力：特定整備記録簿の月次台帳CSV、記載事項欠落チェックレポート、2年保存期限アラート、エーミング記録突合結果、監査提示用索引
- 保存：工場内NAS＋クラウドストレージの二重化。記録簿・エーミングチェックシートは車両登録番号＋整備完了日で相互参照
seibi-kiroku/
├── CLAUDE.md # 記載事項の定義・原文ママ原則・保存期限ルール
├── tokutei/
│ ├── 2026-07/scans/ # 特定整備記録簿スキャン・整備システムCSV
│ └── ledger/2026-07.csv # 特定整備記録簿の月次台帳(記載日から2年保存)
├── eiming/
│ ├── scans/ # エーミング用チェックシートのスキャン
│ └── masters/target-devices.csv # 電子制御装置整備の対象装置マスタ
├── daicho/
│ └── seibi-shunin.csv # 整備主任者・認証番号の管理台帳
└── scripts/ # 構造化・突合・索引生成スクリプト
CLAUDE.mdには「車両登録番号・車台番号・総走行距離・アルコール等の測定値に相当する数値は1文字も補正しない」「日時は年月日単位、判読不能はUNKNOWN」「記録簿の列順は条文の記載事項の順に固定」という3原則を明記します。ここが崩れると、後段の欠落チェックも監査提示もすべて信用できなくなります。
実装の核心：記録簿の構造化から監査対応まで
Step 1：特定整備記録簿のスキャンをJSONへ構造化する
最初の関門は手書きの記録簿です。F社では複合機でスキャンしたPDFを月別フォルダに置き、Claude Codeに次のプロンプトを流します。
tokutei/2026-07/scans/ の特定整備記録簿スキャンを読み取り、
1台=1オブジェクトのJSONに構造化してください。
フィールド: 車両識別情報(登録番号/車台番号), 整備概要, 整備完了年月日,
依頼者氏名, 依頼者住所, 総走行距離, 整備主任者名, 認証番号,
使用者への写し交付日。
ルール:
- 車両登録番号・車台番号・総走行距離は原文ママ。読めない文字は "?" のまま
残し confidence: low を付ける。推測補完は禁止。
- 走行距離は記載の桁のまま。単位(km)を勝手に補完しない。
出力: tokutei/2026-07/scans/structured.json
最後に low confidence の件数と対象を一覧で報告してください。ポイントは車両識別情報と走行距離を「いい感じに」直させないことです。車台番号や走行距離をAIが善意で補正すると、原本の記録簿と台帳が食い違い、監査時に記録の信頼性そのものを疑われる火種になります。低信頼フラグが付いた箇所だけ人間が原本を見て確定します。
Step 2：記載事項の欠落チェックと2年保存期限のアラート
構造化できれば、台帳生成と期限管理は機械集計です。
tokutei/2026-07/scans/structured.json を読み込み、
tokutei/ledger/2026-07.csv に記録簿エントリを追記してください。
列は道路運送車両法第91条の記載事項の順:
車両識別情報 / 整備概要 / 整備完了年月日 / 依頼者氏名及び住所 /
総走行距離 / 整備主任者名 / 認証番号 / 写し交付日。
併せて欠落チェック:
1) 記載事項のいずれかが空・UNKNOWNの記録
2) 整備完了年月日はあるが写し交付日の記載がない記録
3) 総走行距離が前回整備時点の記録より小さい(逆行)記録
4) 記載日から2年保存期限までの残日数が90日以内の記録
を「要修正・要確認リスト」としてMarkdownで出力してください。3)の突合が実務の肝です。1台の記録簿を単体で眺めても走行距離の入力ミスは見えません。過去の整備履歴と突き合わせて初めて、「前回より走行距離が減っている」という機械的にしか気づけない矛盾が検知できます。紙運用時代は監査で指摘されて初めて気づいていたような入力ミスが、月次の締めで見つかるようになります。
Step 3：電子制御装置整備（エーミング）記録の突合
ASV搭載車の入庫が増えるほど重くなるのが、この突合作業です。
eiming/scans/ のエーミング用チェックシートを読み取り、
tokutei/ledger/2026-07.csv の記録簿エントリと車両識別情報で突合してください。
eiming/masters/target-devices.csv (前方カメラ・ミリ波レーダー等の対象装置マスタ)
と照らして、次を検知してください:
1) エーミングを実施したのに特定整備記録簿の整備概要欄に記載がない車両
2) 対象装置マスタにない装置名でエーミングが記録されている車両
(表記ゆれの可能性があるため一覧化するのみで自動修正しない)
3) 電子制御装置整備の認証区分を持たない作業者名での記録
結果を「エーミング記録突合レポート」としてMarkdownで出力してください。
認証区分の要否判定はせず、記載の食い違いだけを列挙してください。最後の一文が重要です。ある作業者がその装置の整備を担当してよいかどうかの判断は、認証区分・資格要件に関わる制度的な判断であり、AIに確定させません。あくまで「記録上の食い違い」を洗い出すところまでを担当させ、確定は工場長・整備主任者が行います。
Step 4：使用者への写し交付ログと監査提示用索引の生成
最後に、交付漏れの検知と監査準備を1本のプロンプトにまとめます。
対象期間: {開始日}〜{終了日}
tokutei/ledger/ を対象に、期間内の全整備について
車両識別情報 / 整備完了年月日 / 写し交付日の有無 / エーミング記録の有無 /
2年保存期限までの残日数 を一覧表にしてください。
写し交付日が空欄の記録は先頭にまとめ、経過日数も併記してください。
これは社内確認用ドラフトであり、監査への提示資料は工場長が確定します。このプロンプトで提示用リストを生成し、写し交付漏れや保存期限切れ間近の記録を事前に把握してから立入検査の当日を迎えられます。数日がかりだった監査前の探し物作業が、日常運用の延長になります。
段階的導入のロードマップ
Phase 1（1〜2ヶ月）：特定整備記録簿の構造化（Step 1）だけを回す。低信頼フラグの発生率を測り、記録簿の記入ルール（数値は枠内に楷書で等）とスキャンファイルの命名規則を現場と調整。既存の紙保存運用はそのまま並走させる。
Phase 2（3〜4ヶ月）：台帳生成と欠落チェック（Step 2）を全整備に展開し、走行距離の逆行チェックを月次の締めに組み込む。エーミング記録の突合（Step 3）は代表的な対象装置から開始し、対象装置マスタを実績に合わせて拡充する。
Phase 3（5〜8ヶ月）：写し交付ログと監査提示用索引（Step 4）を標準化。2年保存期限の管理を自動化し、年1回「過去の任意の車両の記録一式を10分で揃えられるか」訓練を定例化する。
想定効果（試算）
| 指標 | 導入前 | 導入後（試算） | 改善 |
|---|---|---|---|
| 特定整備記録簿の台帳化・整理（月間約400件） | 週 約10時間 | 週 約3時間 | 約70%削減 |
| 記載事項の欠落検知 | 月末の目視チェックで発覚 | 日次〜週次で自動フラグ | 検知が事後→日次 |
| エーミング記録と記録簿の突合 | 属人管理（記載漏れリスク） | 週次の自動突合 | 仕組み化 |
| 写し交付ログの管理 | 紙ベースで未追跡 | 交付日の一覧管理 | 交付漏れの可視化 |
| 立入検査・監査の資料準備 | 約2人日 | 約半日 | 約75%短縮 |
繰り返しになりますが、上記は従業員18名・年間整備台数約4,800台の想定モデルにおける試算です。記録簿の状態（手書き比率・スキャン品質）と整備システムの整備状況によって、構造化の精度と削減幅は大きく変わります。
【要注意】よくある失敗パターンと回避策
失敗1：特定整備記録簿と点検整備記録簿を同じテンプレートで扱う
❌ 「整備の記録簿だから」と特定整備記録簿と点検整備記録簿を1つのチェックリスト・保存期限ルールで一括管理 → 特定整備記録簿は記載日から2年保存（道路運送車両法第91条第3項）、点検整備記録簿は点検の種類により保存期間が異なる別制度。同じ扱いにすると、どちらかの保存期間を誤って運用するリスクがある。
⭕ 記録スキーマ・保存期限マスタを条文単位で分離する。特定整備記録簿は第91条の記載事項でチェックリスト化し、点検整備記録簿とはマスタ・保存期限管理を分ける。
失敗2：走行距離・車両識別情報をAIに「いい感じに」補正させる
❌ 手書きの走行距離の判読しづらい桁をAIが前後の文脈から推測して補完、かすれた車台番号を車両マスタから推測補完 → 原本と台帳が食い違い、記録の信頼性が崩れる。走行距離の逆行チェックなど、後段の欠落検知そのものが機能しなくなる。
⭕ 識別子・測定値は原文ママ＋低信頼フラグ運用。補正するのは原本を確認した人間だけ。CLAUDE.mdに「補正禁止」を明記し、プロンプトにも毎回書く。
失敗3：電子制御装置整備の認証区分をAIの判断で確定させる
❌ エーミング記録の食い違いをAIが「おそらく問題なし」と判定して記録簿を自動修正 → 電子制御装置整備の認証区分は制度上の要件であり、記載の食い違いをAIが安易に「問題なし」と結論づけると、実際には認証要件を満たしていない記録がそのまま残るリスクがある。
⭕ AIの担当は食い違いの一覧化までにとどめ、確定は整備主任者・工場長が行う。判断に迷う場合は所管の運輸支局・地方運輸局に確認する運用を明文化する。
失敗4：使用者への写し交付を後回しにし、記録が追いつかなくなる
❌ 繁忙期に写しの交付を後回しにし、交付ログを付けないまま数週間分が溜まる → 道路運送車両法上、事業者は特定整備記録簿の写しを使用者に交付する義務がある。交付漏れが積み重なると、後から個別に追跡するコストが跳ね上がる。
⭕ 整備完了と同時に交付日を記録するワークフローにし、Step 4のレポートで交付日が空欄の記録を毎週フラグする。
適用余地のある業界・規模
「条文で記載事項が固定された記録簿×車両単位の管理×保存期限」という骨格は、自動車整備業に限らず車両を扱う業種に広く通用します。建設機械のレンタル・整備、農業機械の整備・点検、二輪車の特定整備を扱う認証工場でも、記載事項と保存期限を条文単位で読み替えれば同型の実装が使えます。品質記録を条文・規格ベースで構造化するという切り口では、製造業の品質検査報告書の効率化事例とも共通の型です。整備士数名の小規模な認証工場でも、記録簿の構造化と保存期限アラートだけに絞れば投資対効果は出やすいはずです。
まとめ：今日から始める3つのアクション
- 今日やること：直近1か月分の特定整備記録簿をスキャンして1フォルダに集め、Step 1の構造化プロンプトを1本流してみる（車両識別情報・走行距離の補正はさせない設定で）
- 今週中：特定整備記録簿と点検整備記録簿の保存ルールを棚卸しし、それぞれの保存期限（2年・種類別1〜2年）を満たせているかを確認する。ファイル名に車両登録番号・整備完了日を入れる命名規則を決める
- 今月中：先月分の記録について走行距離の逆行チェックを1回実行し、「要修正・要確認リスト」を整備主任者とレビューする。エーミング記録の突合を代表的な対象装置1つで試し、確認フローを決める
FAQ
Q1. 自動車整備工場でClaude Codeは具体的に何に使えますか？
特定整備記録簿の記載事項を満たす構造化データへの変換と欠落チェック、記載日から2年間の保存期限管理、電子制御装置整備（エーミング）記録の突合、使用者への写し交付ログの管理、監査・立入検査に備えた横断検索レポート作成が代表例です。いずれも最終確認は整備主任者・工場管理者が行う補助ツールとしての活用です。
Q2. 特定整備記録簿と点検整備記録簿はどう違いますか？保存期間は同じですか？
特定整備記録簿は認証工場が特定整備を行った際に作成し、記載日から2年間保存する義務があります（道路運送車両法第91条第3項）。点検整備記録簿は定期点検の記録で、点検の種類により保存期間が異なり、根拠法令・保存主体も別です。混同してテンプレートを一本化しないよう注意が必要です。
Q3. 「分解整備」と「特定整備」はどう違いますか？いつ変わりましたか？
令和2年4月（2020年4月）の道路運送車両法改正で「分解整備」制度が「特定整備」制度に名称変更・範囲拡大されました。従来の分解整備に加え、自動ブレーキ用カメラ・レーダーなどの電子制御装置整備（エーミング）も対象に含まれています。電子制御装置整備の認証には4年間の経過措置が設けられ、令和6年4月1日から本格運用が始まっています。
Q4. 特定整備記録簿には何を記載する必要がありますか？
車両識別情報（登録番号・車両番号・車台番号）、特定整備の概要、整備完了年月日、依頼者の氏名及び住所、総走行距離、整備主任者の氏名、事業者の氏名又は名称・事業場の所在地・認証番号などです。事業者は記載した記録簿の写しを使用者に交付する義務があります。
Q5. 導入コストはどのくらいかかりますか？
本記事のモデルケースでは月数万円程度のプラン・API費用＋初期の記録簿様式整理・命名規則づくりの工数という試算です。既存の紙の記録簿＋スキャン運用のまま始められるため、特定整備管理システムの入れ替えを待つ必要はありません。料金は改定されるため、必ずAnthropic公式サイトで最新情報を確認してください。
参考・出典
- 国土交通省「自動車特定整備事業について」 — 令和2年4月の「分解整備」から「特定整備」への名称変更・電子制御装置整備の追加、特定整備記録簿の記載義務（参照日: 2026-07-18）
- 国土交通省「特定整備制度概要」 — 電子制御装置整備の認証・4年間の経過措置期間（参照日: 2026-07-18）
- e-Gov法令検索「道路運送車両法」（昭和26年法律第185号） — 第91条（特定整備記録簿の記載・交付・保存義務）（参照日: 2026-07-18）
- 国土交通省 北陸信越運輸局「特定整備記録簿の記載要領について」 — 記載事項の実務上の記入方法（参照日: 2026-07-18）
- Anthropic「Claude Code 公式ドキュメント」 — CLI・CLAUDE.md・運用設定の一次情報（参照日: 2026-07-18）
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
自動車整備業に限らず「法定記録簿×車両管理×監査対応」まわりの自動化のご相談は、お問い合わせフォームからお気軽にどうぞ。
