Claude Code × 製造業｜組込C/C++リファクタリングからMES統合、技術者退職対策まで

製造業のソフトウェア開発には、SaaSやWeb開発とは根本的に異なる時間軸が存在します。組込ソフトウェアは10年、20年と稼働し続け、開発当時のエンジニアはすでに退職しています。ドキュメントは紙のバインダーに綴じられたまま倉庫に眠り、コードの「なぜこう書かれているか」を知る人間がいない。それでも法改正やセキュリティパッチへの対応は待ってくれません。

本記事では、製造業の開発チームがClaude Codeを実務に組み込むための具体的な手法を解説します。組込C/C++のリファクタリング、MES（製造実行システム）の統合開発、工場閉域ネットワークでの運用構成、そしてベテラン技術者の退職に伴う知識継承——それぞれについて、CLAUDE.mdの設計例と Before/After を交えて踏み込んでいきます。

製造業ソフトウェア開発の構造的課題 — なぜ「普通の開発改善」が通用しないのか

製造業の開発課題は「技術負債」と「人的負債」が同時進行で悪化している点にあります。

Web開発やSaaSの世界であれば、古い技術スタックは数年単位でリプレースできます。しかし製造業の組込ソフトウェアは、ハードウェアとの密結合、安全規格の認証取得、生産ラインの停止リスクなどにより、「書き直し」の選択肢がほぼ存在しません。

レガシーコードの堆積

C言語で書かれた制御ソフトウェアは、初期の開発者が「動くように書いた」コードに、後任が「壊さないように追記した」コードが積み重なっています。1つの関数が500行を超え、グローバル変数が数百個あり、コメントは10年前の日本語が混在している——こうした状況は珍しくありません。

ベテラン技術者の退職

2025年以降、団塊ジュニア世代の大量退職が本格化しています。組込開発を30年担ってきた技術者の知識は、コードのコメントにも仕様書にも残っておらず、「あの人に聞けばわかる」という状態で維持されてきました。退職後、その知識は完全に失われます。

ドキュメントの断絶

設計書は紙で作成されたものがスキャンPDFで保存されているか、そもそもデジタル化されていないケースがあります。仕様変更が反映されておらず、「設計書とコードのどちらが正しいか」を判断できる人間がいない状況です。

組込C/C++リファクタリング — CLAUDE.mdでハードウェア制約を教える

組込ソフトウェアのリファクタリングでは、「一般的なクリーンコード」をそのまま適用すると安全性やパフォーマンスが破壊される可能性があります。CLAUDE.mdでハードウェア制約を明示することが不可欠です。

CLAUDE.mdの設計例：組込C/C++プロジェクト

# CLAUDE.md（組込制御ソフトウェア）

## ハードウェア制約
- ターゲット: ARM Cortex-M4（RAM 256KB, Flash 1MB）
- RTOS: FreeRTOS v10.5
- ヒープ使用禁止（malloc/free/new/delete 使用不可）
- スタックサイズ: タスクあたり最大4KB
- 割り込みハンドラ内ではブロッキング操作禁止

## コーディング規約
- MISRA C:2012 準拠
- 動的メモリ確保禁止
- 再帰呼び出し禁止
- 関数の最大行数: 75行（MISRA推奨）
- 変数名は物理量を含める（例: voltage_mV, pressure_kPa）

## リファクタリング制約
- 割り込み優先度の変更は禁止
- volatile修飾子を外さない
- ビットフィールド操作のエンディアンに注意する
- タイミングクリティカルなループの構造変更は要相談

このCLAUDE.mdが定義されていれば、Claude Codeが「std::vectorを使いましょう」「スマートポインタで管理しましょう」といった、組込環境では適用できない提案をすることを防げます。

Before/After: 肥大化した制御関数のリファクタリング

Before: 1つの関数にセンサー読取り、異常判定、アクチュエータ制御、ログ出力が全て含まれた450行の関数。

After: Claude Codeに「MISRA C準拠で、責務ごとに関数を分割して」と指示。センサー読取り（read_sensor_values）、異常判定（evaluate_anomaly）、アクチュエータ制御（control_actuator）、ログ出力（write_diagnostic_log）の4関数に分割。各関数は75行以内に収まり、単体テストが書ける単位になりました。

重要なのは、分割後もタイミング特性が変わっていないことを計測で確認することです。Claude Codeはコードの構造改善はできますが、実行時間やメモリ使用量への影響は計測しないと判断できません。

MES統合開発 — ベンダー固有APIをCLAUDE.mdで橋渡しする

MES（製造実行システム）のカスタマイズ開発では、ベンダー固有のAPIドキュメントをClaude Codeに教えることが品質の決め手です。

MESパッケージ（SAP MII、Siemens Opcenter、横河FAST/TOOLSなど）のカスタマイズ開発では、パッケージ固有のAPI・データモデル・設定規則を開発者が理解している必要があります。しかし、これらの情報はベンダーのマニュアルに散在しており、開発者がAPIを正しく使いこなすまでに時間がかかります。

CLAUDE.mdにベンダーAPIの要約を含める

# CLAUDE.md（MESカスタマイズプロジェクト）

## MESプラットフォーム
- パッケージ: [ベンダー名] v[バージョン]
- カスタマイズ言語: C# / .NET 6
- DB: SQL Server 2022

## ベンダーAPI規約
- ワークオーダーの取得: WorkOrderService.GetByIdAsync(string workOrderId)
- ロット情報の更新: LotService.UpdateStatusAsync(string lotId, LotStatus status)
- 装置状態の取得: EquipmentService.GetCurrentStateAsync(string equipmentId)
- すべてのAPI呼び出しはtry-catchで囲み、MesApiExceptionをハンドリングする
- トランザクション管理はUnitOfWorkパターンを使用する

## データモデル制約
- WorkOrderテーブルのStatus列はVARCHAR(20)、許容値: Created/Released/Active/Completed
- LotとWorkOrderは1:N関係
- 装置IDは工場コード(3桁) + ライン番号(2桁) + 装置番号(3桁)の8桁固定

このようにベンダーAPIの使い方をCLAUDE.mdに要約しておけば、Claude Codeはカスタマイズモジュールのコード生成時に正しいAPI呼び出しパターンを使います。ベンダーマニュアルの全文を読み込ませるのではなく、開発チームが「よく使うAPI」と「間違えやすいポイント」を抽出してCLAUDE.mdに記述するのが効率的です。

生産実績データのインターフェース開発

MESと基幹系（ERP）間のデータ連携インターフェースの開発は、製造業で最も頻度の高い開発タスクの一つです。Claude Codeに以下を指示することで、インターフェースモジュールのひな型を生成できます。

• MES側のデータ取得API呼び出し
• データ変換・バリデーションロジック
• ERP側への送信フォーマット整形
• エラーハンドリングとリトライロジック
• 処理ログの出力

工場閉域ネットワークでの運用構成

工場のOTネットワークはインターネットから物理的に隔離されているケースが多く、Claude Codeの利用方法は開発環境の配置によって大きく異なります。

パターン1: オフィス開発 → ビルド成果物を工場に持ち込み

開発作業はインターネット接続のあるオフィス環境で行い、ビルド済みバイナリのみを工場ネットワークに持ち込むパターンです。この場合、Claude Codeは通常のAPI接続またはBedrock経由で利用できます。

メリット: 導入のハードルが最も低い。既存の開発フローを大きく変えずにClaude Codeを追加できます。 注意点: 工場環境固有のデバッグ（実機接続、I/Oテスト）にはClaude Codeを使えません。

パターン2: オフィス環境からBedrock閉域接続

開発環境がAWS VPC内に配置されている場合、VPCエンドポイント経由でBedrock APIにアクセスする構成です。インターネットを経由しないため、ソースコードの外部送信に関するセキュリティ懸念を軽減できます。

# .envrc（direnv設定）
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=ap-northeast-1
export AWS_PROFILE=manufacturing-dev

パターン3: 完全オフライン環境

インターネット接続もAWS接続もない完全閉域環境では、現時点でClaude Codeの直接利用はできません。この場合の代替手段として、以下が考えられます。

• オフィス環境でClaude Codeを使ってコード・ドキュメントを生成し、成果物のみを閉域環境に持ち込む
• 閉域環境内にローカルLLMを構築する（ただしClaude Codeの品質には届かない可能性がある）

いずれのパターンでも、知的財産としてのソースコードの取扱いについて、法務・知財部門との事前合意が必要です。

ベテラン技術者の退職対策 — 知識を「コードの隣」に残す

ベテラン技術者の知識を引き出してドキュメント化する作業は、退職前に計画的に進めないと取り返しがつきません。Claude Codeはこの作業を加速するツールとして機能します。

知識継承のワークフロー

ステップ1: コードベースの自動ドキュメント化 Claude Codeに対象モジュールを読ませ、処理フロー・データ構造・依存関係の「たたき台ドキュメント」を自動生成します。

ステップ2: ベテラン技術者によるレビュー・加筆 生成されたドキュメントをベテラン技術者にレビューしてもらいます。ゼロから書くのは嫌がるベテランでも、「これ合ってますか？」「ここ、なんでこう書いたんですか？」という質問には答えてくれることが多いです。その回答をドキュメントに反映します。

ステップ3: 暗黙知のCLAUDE.md化 ベテラン技術者が口頭で共有する「コードに書いてない理由」——「この処理は○○工場の△△装置が特殊な信号を出すから入れてある」「この待ち時間は短くするとモーターが焼ける」——こうした情報をCLAUDE.mdに追記します。

# CLAUDE.md（退職者知識の記録セクション）

## 装置固有の制約（口頭伝承からの記録）
- モーター制御モジュール: PWM周波数を20kHz未満にすると可聴ノイズが発生する
- 温度センサー読取り: 起動後30秒間は値が安定しないため、最初の30回のサンプルは捨てる
- 通信プロトコル: 装置Aは応答に最大500msかかるため、タイムアウトを1000msに設定している
  （200msにすると高負荷時にタイムアウトエラーが頻発した実績あり：2019年3月）

このCLAUDE.mdは、コードと同じリポジトリで管理し、バージョン管理の対象に含めます。 紙のバインダーに綴じるのではなく、コードの隣に置くことで、将来の開発者がClaude Codeを使う際にも自動的に参照されます。

導入ステップ — 安全な順序で進める

製造業での導入順序には明確な理由があります。

ステップ1: ドキュメント生成（リスク最小） 既存コードを読み取るだけで、コードの変更は発生しません。ベテラン技術者の退職前に着手すべき最優先項目です。

ステップ2: テスト生成（リスク低） テストコードの追加は本番コードを変更しないため、安全に始められます。テストフレームワーク（Google Test、CppUTest、Unity）に合わせた形式で生成可能です。

ステップ3: リファクタリング支援（リスク中） 十分なテストカバレッジが確保された後で、はじめてリファクタリングに着手します。テストが薄い状態でのリファクタリングは回帰バグのリスクが高く、製造業ではその影響が生産ラインの停止に直結する可能性があります。

ステップ4: 新規開発での標準利用（リスク管理済み） 既存コードでの実績を積んだ後、新規プロジェクトでClaude Codeを標準ツールとして採用します。

まとめ — 「人の退職」が始まる前に、知識をコードの隣に残す

製造業におけるClaude Code活用の最大の価値は、ベテラン技術者の暗黙知をドキュメントとしてコードの隣に残し、将来の開発者が参照できる状態にすることです。組込C/C++のリファクタリングやMES統合の効率化は重要ですが、それらはベテランの知識が残っていてはじめて正しく実行できます。

退職の日程が決まってからでは遅い。今日からドキュメント生成を始めることが、最もROIの高い投資です。

Claude Codeの基本操作については Claude Code完全ガイド を、CLAUDE.mdの書き方は CLAUDE.md作成ガイド を参照してください。