製造業の生産管理データを自動化｜大手工場が工数85%削減した実装事例

従業員約5,000名規模の大手製造業A社では、生産管理と品質検査の日次レポート集計に週40時間もの工数を費やしていた。MES（製造実行システム）・SCADA・品質検査機器から出力される表記揺れだらけのデータを、人手でExcelに転記・整形し、報告書としてまとめる作業だ。Claude Codeを使った日次レポート自動化パイプラインを構築した結果、週40時間の作業は週6時間にまで圧縮され、工数は85%削減された。本記事では、想定シナリオに基づくサンプル実装として、製造現場でClaude Codeを用いた業務改革を実装する流れを、コード例とともに紹介する。

導入前の課題：1週間40時間が「数字の集計」に消えていた

A社では、複数工場で稼働する生産ラインから日々大量のデータが出力されていた。MESからは生産実績（計画数・実績数・段取り時間・サイクルタイム）、SCADAからは設備稼働ログ（稼働率・停止理由・アラーム履歴）、品質検査機器からは寸法測定値や外観検査の判定結果が出力される。これらを工程ごとに集計し、翌朝の朝礼で配布する「日次生産レポート」と「品質週報」にまとめるのが生産管理課の主要業務だった。

担当者2名が毎日3〜4時間、月次集計時には1日中Excelと格闘していた。週合計で約40時間。さらにMESとSCADAでは設備IDの表記が異なり（例: MES側「L01-PRESS-A」、SCADA側「Line1_Press_A」）、品質検査機器のCSVには列名揺れや日付フォーマット差異もあるため、転記ミスやマッピング漏れで「数字が合わない」事故が月に数回発生していた。

Claude Codeで構築した「日次レポート自動化パイプライン」の全体像

A社はClaude Codeを社内ネットワーク内に閉じて運用し、生産管理データの収集・正規化・レポート生成までを一気通貫で処理するパイプラインを構築した。中核となるモジュールは以下の4つだ。

• データ収集モジュール：MES（DBエクスポート）、SCADAヒストリアン、品質検査機器CSVの3ソースを夜間バッチで取り込み
• 正規化モジュール：設備ID・工程コード・製品コードの表記揺れを辞書ベースで吸収
• 異常検知モジュール：稼働率・不良率のしきい値超過と統計的外れ値（3σ）を自動抽出
• レポート生成モジュール：Jinja2テンプレートでHTML/PDF日報・週報を生成し、配布リストへ自動送信

開発期間は約8週間。生産技術部のエンジニア1名と情報システム部1名が、Claude Codeに仕様を伝えながらPython 3.11ベースで実装した。依存パッケージは pandas 2.2、SQLAlchemy 2.0、Jinja2 3.1、jsonschema 4.21、scikit-learn 1.4 程度に絞り、ベンダーロックを避けた。実行環境はオンプレ Linux（RHEL 8）上の cron + systemd タイマー。Claude Code は社内プロキシ経由で API キーを使い分け、生産データそのものは外部API送信しない設計とした。

生産管理データの正規化：複数システムの表記揺れを吸収する仕組み

製造現場のデータ統合で最も詰まるのが「同じ設備なのに別のID」「同じ製品なのに別の品番」という表記揺れだ。A社では、Claude Code に過去半年分の MES / SCADA エクスポートと品質検査CSVを読み込ませ、自動的にマッピング辞書を生成させた。人間のレビューで確定したものを equipment_aliases.yaml として保存し、夜間バッチが毎晩参照する。

以下は正規化モジュールのサンプル実装（抜粋）。pandas のベクトル化処理で、表記揺れを吸収しつつ、辞書にない値はログに残して人間レビューに回す。

import pandas as pd
import yaml
from pathlib import Path
import logging

logger = logging.getLogger(__name__)

def load_alias_map(path: Path) -> dict[str, str]:
    """設備ID辞書を読み込み、正規ID -> {表記揺れ集合} を逆引きdictに変換"""
    raw = yaml.safe_load(path.read_text(encoding="utf-8"))
    alias_to_canonical: dict[str, str] = {}
    for canonical, aliases in raw.items():
        alias_to_canonical[canonical] = canonical
        for alias in aliases:
            alias_to_canonical[alias.strip().lower()] = canonical
    return alias_to_canonical

def normalize_equipment_id(df: pd.DataFrame, alias_map: dict[str, str],
                            col: str = "equipment_id") -> pd.DataFrame:
    """設備ID列を正規化。未知の値は unknown_equipment.log に出力"""
    key = df[col].astype(str).str.strip().str.lower()
    df["equipment_id_canonical"] = key.map(alias_map)
    unknown = df.loc[df["equipment_id_canonical"].isna(), col].unique()
    if len(unknown) > 0:
        logger.warning("Unknown equipment IDs detected: %s", unknown.tolist())
    return df

# 使用例: MESエクスポートとSCADAヒストリアンを統一IDで結合
alias_map = load_alias_map(Path("config/equipment_aliases.yaml"))
mes_df = normalize_equipment_id(pd.read_csv("data/mes_20260514.csv"), alias_map)
scada_df = normalize_equipment_id(pd.read_csv("data/scada_20260514.csv"), alias_map)
merged = mes_df.merge(scada_df, on=["equipment_id_canonical", "shift"], how="outer")

導入後、設備ID・製品コードの吸収精度は97%超に達し、月次集計時の「数字が合わない」差異調査の作業は月12時間からほぼゼロになった。残り3%は新規ラインや治具入れ替え時に発生する未知ID で、ログから自動でSlackに通知され、生産技術担当者が辞書に追記する運用に落とし込んだ。

品質検査レポートの自動生成と異常検知

品質週報では、寸法測定値の工程能力指数（Cpk）や外観検査の不良率を、製品×ライン×ロット単位で集計する必要がある。A社では、Claude Codeに「Cpkを計算してしきい値1.33を割っていれば赤色フラグ、1.67を超えていれば緑色フラグを立てる」「不良率は前週比で20%以上増えたら異常扱い」というルールを自然言語で伝え、Pythonコードと Jinja2 テンプレートを生成させた。

以下は異常検知ロジックのサンプル実装。scipy.stats を使わず標準的な統計量だけで実装し、現場のExcel管理者でも読める粒度に抑えた。

import pandas as pd

def compute_cpk(values: pd.Series, usl: float, lsl: float) -> float:
    """工程能力指数 Cpk を計算（標準偏差は不偏分散ベース）"""
    mu = values.mean()
    sigma = values.std(ddof=1)
    if sigma == 0 or pd.isna(sigma):
        return float("nan")
    return min((usl - mu) / (3 * sigma), (mu - lsl) / (3 * sigma))

def classify_cpk(cpk: float) -> str:
    if pd.isna(cpk):
        return "insufficient_data"
    if cpk < 1.33:
        return "red"     # 改善要
    if cpk < 1.67:
        return "yellow"  # 注意
    return "green"        # 良好

def detect_defect_spike(current: float, previous: float, ratio: float = 1.20) -> bool:
    """前週比 20% 以上の不良率上昇を異常扱い"""
    if previous <= 0:
        return current > 0
    return current / previous >= ratio

異常検知の結果は、レポートPDFの巻頭サマリーに自動でハイライトされる。これにより、製造課長は「どこを真っ先に見るべきか」を朝礼前に30秒で把握できるようになった。導入前は「全データを眺めて違和感を見つける」属人作業だったため、ベテラン課長の不在時には異常を見逃すリスクが大きかった。

工数85%削減を実現した実数値と効果

運用開始から3か月後の実績では、改革の効果が明確に出ている。週40時間の集計工数が週6時間に圧縮され、85%の工数削減を達成した。さらに副次的な効果も大きい。

• 日次レポート集計工数（2名分合算）：週40時間 → 週6時間（85%削減）
• レポート配布タイミング：翌朝9時 → 当日23時（朝礼前に確認可能に）
• 数字差異の調査作業：月12時間 → ほぼゼロ
• 品質異常の発見リードタイム：平均3.2日 → 平均0.8日（76%短縮）
• 生産管理課の月間残業時間：1人あたり平均38時間 → 12時間

注目すべきは、削減された工数が「単なるコストカット」ではなく、生産技術部の改善活動や予防保全分析に再投資された点だ。空いた時間で過去ログを掘り直し、ある搬送ライン特有の停止パターンを発見、段取り時間を平均1.4分短縮する改善につなげた。レポート自動化は、現場の知的活動を取り戻すための起点になっている。

導入時に直面した3つの壁と乗り越え方

順調に見える本事例にも、現場での抵抗や規程・運用面の障壁は存在した。A社が乗り越えた代表的な3つの壁を紹介する。

壁1：現場オペレーターの抵抗（紙運用との並行期間）

「紙の日報のほうが書き慣れている」「PCで集計するなんて信用できない」というベテランオペレーターの声があった。A社では、最初の8週間は紙運用と自動レポートを並行させ、両者の数字を毎日突き合わせる体制を敷いた。差異が出るたびに辞書・ロジックを修正し、3週目には99%以上の数字一致を達成。これを根拠に、9週目から紙運用を段階的に廃止していった。「いきなり置き換える」ではなく「並走して信頼を積む」のが、現場巻き込みの定石である。

壁2：製造データ管理規程・ISO 9001 監査対応

製造業ではISO 9001 や顧客監査でデータの真正性・追跡可能性が問われる。A社では、Claude Codeで生成したパイプラインに以下の監査対応機能を組み込んだ。

• 入力CSVのSHA-256ハッシュをDBに保存（改ざん検知）
• 変換ロジック・辞書ファイルを Git で版管理（変更履歴の追跡）
• レポートPDFに「集計ロジックバージョン」「使用辞書バージョン」をフッターに自動印字
• 異常検知時の判定理由（しきい値・実測値・前週値）をJSONで併存保存

この設計により、外部監査でも「どのデータからどのロジックで何が出力されたか」を一意に再現可能になり、品質保証部門の承認を得られた。

壁3：パイプラインの保守運用（夜間バッチの失敗対応）

夜間バッチが落ちて翌朝レポートが出ない、という事態は最悪のシナリオだ。A社では、systemd の OnFailure フックと簡易ヘルスチェックスクリプトで、失敗を即座にSlackへ通知する仕組みを作った。以下は通知用シェルの抜粋。

#!/usr/bin/env bash
set -euo pipefail

REPORT_LOG="/var/log/daily_report/$(date +%Y%m%d).log"
WEBHOOK_URL="${SLACK_WEBHOOK_URL:-}"

if grep -qE "^(ERROR|CRITICAL)" "$REPORT_LOG"; then
  msg="🚨 日次レポート生成エラー検知: $(date +%F) - $(tail -n 3 "$REPORT_LOG")"
  curl -sS -X POST -H 'Content-Type: application/json' 
    -d "{"text": "${msg}"}" "$WEBHOOK_URL" > /dev/null
  exit 1
fi
echo "OK: $(date +%FT%T) report generated"

運用開始から3か月のうち、夜間バッチが落ちたのは3回。いずれもSlack通知から30分以内に検知し、当日朝までに復旧できている。落ちた原因（品質検査機器のCSVに新列追加、SCADA再起動による接続切れ、ディスク容量逼迫）はすべてランブック化され、属人化を防いだ。

まとめ：製造業におけるClaude Code活用の本質

A社の事例が示すのは、Claude Codeが単なる「省力化ツール」ではなく、製造業の管理業務を再設計する力を持つということだ。生産管理データの集計という「誰がやっても結果が同じになるべき作業」をパイプラインに委ね、人間は異常分析や改善活動という「判断と発想が必要な作業」に集中する——この役割分担が、最終的に工数85%削減と現場改善力の回復をもたらした。

製造業は、データ量の多さ、システム間の表記揺れの激しさ、規程対応の重さという点で、AI活用の難易度が比較的高い業界とされてきた。しかしClaude Codeのように、現場のエンジニアが自然言語で仕様を伝えながら段階的にロジックを育てられるツールが登場したことで、内製での改革が現実的な選択肢になった。重要なのは、最初から全工程の自動化を狙わず、最も工数を食っている1〜2業務に絞ること。A社も最初の8週間は「日次レポートの自動集計」だけに集中し、その成功体験を足がかりに品質週報・予防保全分析へと範囲を広げていった。生産現場の管理業務は、ここから数年で確実に変わる。

あわせて読みたい：製造業の作業手順書・技能伝承をClaude Codeで効率化