製造業

サプライチェーンリスク予測をClaude Codeで実装|製造業向け5手順

製造業のサプライチェーンリスクをClaude Codeで予測・可視化。調達遅延の自動検知から代替サプライヤー提案まで、実装パターンを5ステップで解説。

サプライチェーンリスク予測をClaude Codeで実装|製造業向け5手順

結論:Claude Codeのサブエージェント・hooks・MCP連携を組み合わせることで、製造業のサプライチェーンリスク予測パイプラインを5ステップで構築できる。

  • 要点1:Gartnerは2030年までにサプライチェーン管理ソフトウェアのエージェントAI市場が530億ドル規模に成長すると予測(2025年の20億ドル未満から急拡大、Gartner 2026年4月発表)
  • 要点2:Claude Codeのhooksとサブエージェントで、調達リードタイム異常の検知からSlack通知まで自動化するパイプラインを構築可能
  • 要点3:外部データ(為替・天候・地政学リスク)をMCP経由で統合し、サプライヤーリスクスコアを自動更新する実装パターンを解説

対象読者:製造業の調達・生産管理に関わるエンジニア・PM、サプライチェーンDXを推進する技術リーダー

今日やること:Step 1のCSVデータ正規化スクリプトをClaude Codeで生成し、自社の調達データで動かしてみる

事例区分: 実装パターン解説
本記事は、製造業のサプライチェーンリスク予測をClaude Codeで実装する汎用パターンを解説しています。数値は試算・想定モデルであり、特定企業の実績ではありません。

「またサプライヤーからの納期遅延が入った。先週で3件目だ」

ある製造業(従業員3,000名規模)の調達担当エンジニアから、こんな相談を受けたのは2026年3月のことでした。ERPに蓄積された調達データは膨大なのに、リスクの兆候を「人間の勘と経験」で拾っている。Excel上でリードタイムの推移をグラフ化しても、異常に気づくのは問題が顕在化してからです。

正直に言うと、サプライチェーンリスク予測は「AIを入れれば即解決」というテーマではありません。Gartnerの2026年5月調査でも、サプライチェーンへのAI導入で即座に変革的なプロセス再設計を進めている組織はわずか17%で、83%は段階的なアプローチを取っています(Gartner 2026年5月発表、参照日: 2026-05-19)。

だからこそ、小さく始められる実装パターンが重要です。この記事では、Claude Codeのサブエージェント・hooks・MCP連携を使って、サプライチェーンリスク予測パイプラインを5ステップで構築する方法を、コピペ可能なコード付きで解説します。

サプライチェーンリスク予測にClaude Codeを使う理由

従来のERPベース予測の限界

多くの製造業では、SAP・Oracle等のERPに蓄積された調達データを手動でエクスポートし、Excelやスプレッドシートでリードタイム分析を行っています。この方法には3つの構造的な問題があります。

  1. 検知の遅さ — リードタイムの異常傾向に気づくのは、月次レポート作成時。その時点で納期遅延は既に確定している
  2. 外部要因の未統合 — ERPは社内データのみ。為替変動、天候リスク、地政学イベントといった外部リスク因子が反映されない
  3. 代替案の欠如 — リスクを検知しても「では代わりにどのサプライヤーに切り替えるか」の意思決定支援がない

Claude Codeが提供する3つの強み

サプライチェーン分析パイプラインの構築には、Claude Codeの以下の特性が有効です。

  • サブエージェントによる並列処理 — 為替データ取得・天候API呼び出し・ニュース分析を並列実行し、リスクスコアを統合(Claude Code Docs: Subagents
  • hooksによる自動トリガー — データ更新をトリガーにスコア再計算→閾値超過でSlack通知を自動実行(Claude Code Docs: Hooks
  • MCP連携でデータソース統合 — Google Sheets、Slack、社内DB等を直接参照し、ダッシュボードを自動更新(Claude Code Docs: Overview、参照日: 2026-05-19)

製造業のサプライチェーンでClaude Codeが扱うのは、あくまでデータの収集・整形・分析・通知の自動化です。最終的な調達判断は人間が行う前提で設計します。

製造業でのClaude Code活用事例は他にもあります。生産管理データの自動化については製造業の生産管理データを自動化した実装事例で詳しく解説しています。

動作環境と前提条件

検証環境

# 検証環境(2026年5月時点)
# OS: Ubuntu 22.04 LTS / macOS 14+
# Claude Code: 最新安定版
# Python: 3.11+(データ前処理用)

# プロジェクト初期化
mkdir supply-chain-risk && cd supply-chain-risk
git init && claude

必要なAPIキーとデータソース

本パイプラインで使用する外部データソースは以下の通りです(いずれも無料枠またはフリーミアムプランで検証可能)。

データソース 用途 取得方法
ERPエクスポート(CSV) 調達実績・リードタイム 手動 or API
Open Exchange Rates API 為替レート 無料プラン(月1,000リクエスト)
Open-Meteo API 天候データ 完全無料(商用利用可)
GDELT Project API 地政学リスクイベント 完全無料

Step 1 — 調達データの収集と正規化

ERPからのCSVエクスポート形式

最初に必要なのは、ERPから調達データをCSV形式でエクスポートすることです。以下が最低限必要なカラムです。

# ERPエクスポートCSVの期待フォーマット(procurement_data.csv)
# supplier_id, supplier_name, part_number, order_date, expected_delivery,
# actual_delivery, unit_price, currency, country, category

# サンプルデータ確認
head -5 data/procurement_data.csv

Claude Codeでデータ前処理スクリプトを生成

Claude Codeに以下のプロンプトを投げると、データの前処理スクリプトが生成されます。ポイントは、仕様を具体的に指定すること。

# Claude Code プロンプト(ターミナルで実行)
# 動作環境: Claude Code 最新安定版、Python 3.11+
claude -p "
procurement_data.csv を読み込んで以下の前処理を行うPythonスクリプトを書いてください。

1. 日付カラム (order_date, expected_delivery, actual_delivery) を datetime に変換
2. lead_time_days = actual_delivery - order_date を算出
3. delay_days = actual_delivery - expected_delivery を算出(負値は0に)
4. supplier_id ごとに過去90日の平均リードタイムと標準偏差を算出
5. 移動平均(7日窓)でトレンドを検出
6. 結果を data/supplier_risk_metrics.csv に出力

不足している情報があれば、最初に質問してから作業を開始してください。
数字と固有名詞は、根拠(出典/計算式)を添えてください。
"

Claude Codeはファイルを直接読み書きできるため、生成→実行→結果確認→修正のサイクルが1セッションで完結します。

正規化結果の検証

生成されたスクリプトの出力は必ず検証します。日付フォーマットの解釈やタイムゾーン処理でエッジケースが発生することがあるため、lead_time_daysの負値やNaN率をClaude Codeに確認させてください。

Step 2 — リスクスコアリングモデルの構築

リスク因子の定義

サプライヤーリスクスコアは、以下の4因子を重み付き合算で算出します。これは専門的なMLモデルではなく、ルールベースの重み付けスコアです。

因子 重み(試算) データソース 更新頻度
納期遵守率 0.35 ERPエクスポート 日次
リードタイム変動(σ) 0.25 ERPエクスポート 日次
為替変動リスク 0.20 Open Exchange Rates 日次
地政学・天候リスク 0.20 GDELT + Open-Meteo 日次

※ 重みは製造業6社(従業員1,000〜10,000名規模)へのヒアリングをもとにした試算値です。実運用では、自社の調達特性に合わせて調整してください。

Claude Codeでスコアリングロジックを生成

# Claude Code プロンプト
# 動作環境: Claude Code 最新安定版、Python 3.11+
claude -p "
以下の仕様でサプライヤーリスクスコアリングモジュールを作成してください。

## 入力
- data/supplier_risk_metrics.csv(Step 1の出力)

## スコアリングロジック
- on_time_score: 納期遵守率(直近90日)。100%なら0、80%未満なら100
- volatility_score: リードタイム標準偏差の偏差値(高いほどリスク大)
- fx_score: 当該サプライヤーの通貨の30日ボラティリティ。1%未満なら0、5%超なら100
- geo_score: GDELT GKG APIで当該国のリスクイベント件数(直近30日)を0-100に正規化

## 合算
risk_score = 0.35 * on_time_score + 0.25 * volatility_score + 0.20 * fx_score + 0.20 * geo_score

## 出力
- data/supplier_risk_scores.json(supplier_id, risk_score, 各因子スコア, 更新日時)
- risk_score が 70 以上のサプライヤーを HIGH_RISK としてフラグ

仮定した点は必ず '仮定' と明記してください。
"

Step 3 — 外部データソースとの統合

為替・天候・地政学リスクの取り込み

Claude Codeのサブエージェント機能で、複数API呼び出しを並列実行します。

# Claude Code プロンプト — 外部データ取得(3スクリプト並列生成)
# 動作環境: Claude Code 最新安定版、Python 3.11+
claude -p "
3つの外部データ取得スクリプトを作成(出力は data/external/):
1. fetch_fx_rates.py — Open Exchange Rates で30日分の為替ボラティリティ算出
2. fetch_weather_risk.py — Open-Meteo で港湾都市の暴風雨リスク指標算出
3. fetch_geo_risk.py — GDELT GKG で国別リスクイベント件数を0-100正規化
各スクリプトにリトライ(3回、exponential backoff)とエラーハンドリング。
APIキーは環境変数。
"

MCP連携でリアルタイムデータ接続

Claude CodeはMCPを通じて外部データソースと接続できます。Google Sheetsで調達データを管理しているなら、MCPサーバー設定でリアルタイム参照が可能です。

# .claude/settings.json に MCP サーバーを追加
# (Google Sheets MCPサーバーの設定例)
{
  "mcpServers": {
    "google-sheets": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-google-sheets"],
      "env": {
        "GOOGLE_SHEETS_CREDENTIALS": "/path/to/credentials.json"
      }
    }
  }
}

MCP連携はオプションです。既存のスプレッドシート運用を維持したまま、Claude Codeからデータを参照できます。

Step 4 — 異常検知アラートの実装

hooksを使った閾値監視

Claude Codeのhooks機能を使うと、特定のファイル更新をトリガーにスコア再計算→アラート送信を自動化できます。

# .claude/settings.json — hooks設定
# Claude Code hooks: ファイル編集後に自動でリスクスコア再計算
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "python3 scripts/recalc_risk_scores.py && python3 scripts/check_alerts.py"
      }
    ]
  }
}

Slack / Teamsへの自動通知パイプライン

リスクスコアが閾値(試算: 70点以上)を超えたサプライヤーの自動通知を生成します。

# Claude Code プロンプト — Slack通知スクリプト生成
# 動作環境: Claude Code 最新安定版、Python 3.11+
claude -p "
supplier_risk_scores.json から risk_score>=70 を抽出し、
上位2因子を特定、Slack Webhook(環境変数 SLACK_WEBHOOK_URL)に
テーブル形式で送信するスクリプトを作成。
1日1回に制限(alert_history.json で重複防止)。
"

IoTセンサーデータの異常検知パイプラインについては、製造IoT異常検知をClaude Codeで実装した事例も参考になります。

Step 5 — 代替サプライヤー提案の自動化

サプライヤーDBの構築

リスクを検知するだけでは不十分で、「ではどこに切り替えるか」の提案まで自動化します。サプライヤーマスターをJSON形式で構造化し、カテゴリ・認証・キャパシティ情報を含めます。

Claude Codeで代替候補をランキング

HIGH_RISKサプライヤーと同カテゴリ・同認証の代替候補をランキングします。

# Claude Code プロンプト — 代替サプライヤー提案
# 動作環境: Claude Code 最新安定版、Python 3.11+
claude -p "
supplier_risk_scores.json のHIGH_RISKサプライヤーに対し、
supplier_db.json から同カテゴリ・risk_score<50 の候補を抽出。
ソート優先度: 認証有無 > リスクスコア昇順 > キャパシティ余力 > リードタイム短順。
上位3候補をMarkdownレポート出力。各推奨に '自動生成・要確認' 注記を付与。
"

想定効果と段階的導入ロードマップ

想定効果(試算)

以下は製造業(従業員1,000〜5,000名規模)を想定したモデルケースの試算値です。実際の効果は企業規模・調達構造・データ品質により変動します。

指標 導入前(想定) 導入後(試算) 改善(試算)
リスク検知リードタイム 月次レポート時(平均15日遅れ) 日次自動検知(当日) 検知速度15倍向上
サプライヤー評価工数 週8時間(手動集計) 週1時間(自動レポート確認) 工数87%削減
代替サプライヤー選定 平均5営業日 即時候補提示+1日で最終判断 選定期間80%短縮
外部リスク因子の反映 未実施 日次自動更新(4因子統合)

※ 上記は試算値です。Gartnerは2030年までに大規模組織の70%がAIベースのサプライチェーン予測を導入すると予測しています(Gartner 2025年9月)。

Phase 1(1〜2ヶ月): PoC — 単一カテゴリで検証

最もリスクの高い調達カテゴリ1つ(例: 電子部品)に絞り、Step 1〜2を実装。ERPデータのCSVエクスポート→リスクスコア算出→閾値超過のSlack通知まで。この段階ではAPIの外部データ統合は不要です。

Phase 2(3〜4ヶ月): 横展開 — 外部データ統合と全カテゴリ適用

Step 3の外部データ統合を追加し、全調達カテゴリに展開。為替・天候・地政学リスクを含むスコアリングに拡張。代替サプライヤー提案(Step 5)の試験運用を開始します。

Phase 3(5〜8ヶ月): 自動化レベル向上

Claude CodeのRoutines機能(InfoQ 2026年5月)で定期実行をクラウドに移行。24時間監視体制を構築します。

【要注意】よくある失敗パターンと回避策

失敗1:データ品質を無視してスコアリングを始める

❌ ERPからエクスポートしたCSVをそのままスコアリングに投入。日付フォーマットの不統一(yyyy/MM/dd と MM-dd-yyyy の混在)やNULL値でスコアが異常値に。

⭕ Step 1のデータ正規化を必ず先に実行。特に actual_delivery が空(未納品)のレコードは除外するか、expected_delivery + バッファで仮置きするロジックが必要。

なぜこれが重要か:スコアリングの精度は入力データの品質に直接依存します。「Garbage In, Garbage Out」はAI時代でも変わりません。

失敗2:外部APIの障害を想定していない

❌ Open Exchange Rates APIがメンテナンス中にスクリプトがクラッシュ。リスクスコアが更新されず、高リスクサプライヤーの検知が1週間遅延。

⭕ 各外部APIの呼び出しにリトライ(3回、exponential backoff)とフォールバック(前日のキャッシュデータを使用)を実装。APIステータスの監視もhooksに追加。

なぜこれが重要か:外部APIの障害は「起きるもの」として設計する必要があります。

失敗3:アラート疲れ — 閾値設定が甘すぎる

❌ リスクスコア50以上でアラート設定。毎日20件以上の通知が飛び、調達チームが通知を無視するようになる。本当にクリティカルなアラートも埋もれる。

⭕ 初期は閾値を高め(70以上)に設定し、週次で閾値を見直す運用に。HIGH_RISK(70+)とWATCH(50-69)の2段階に分け、HIGH_RISKのみ即時通知、WATCHは日次ダイジェストにまとめる。

なぜこれが重要か:通知数を最小限に絞ることが、対応率の最大化につながります。

失敗4:代替サプライヤー提案をそのまま発注してしまう

❌ Claude Codeが提案した代替サプライヤーに、品質検証・価格交渉なしで発注。ロット不良が発生し、ライン停止に。

⭕ 代替提案レポートには必ず「自動生成・要確認」ラベルを付与。提案は「候補リスト」であり、最終判断は調達担当者が品質・価格・納期を個別確認した上で行う。AIは補助ツールであり、最終判断者ではありません。

なぜこれが重要か:自動車部品等ではサプライヤー変更に顧客承認が必要です。AIの提案を無条件に信頼するのは危険です。

品質検査レポートの自動化パターンについては、製造品質検査レポートをClaude Codeで自動化した事例も参考にしてください。

よくある質問(FAQ)

Q1: サプライチェーンリスク予測とは何ですか?

調達先の納期遅延・品質問題・外部環境リスク(為替・天候・地政学)を定量的に評価し、問題が顕在化する前に検知・対策を講じるための分析手法です。従来はExcelベースの手動分析が主流でしたが、Claude Code等のAIツールを活用することでリアルタイムの自動監視が実現可能になっています。

Q2: Claude Codeの利用料金はいくらですか?

Claude CodeはClaude Max(月額$100〜$200)またはAnthropic API(従量課金)で利用できます。最新の料金体系はAnthropicのClaude Code公式ページで確認してください(2026年5月時点)。

Q3: 無料で試せますか?

Claude Codeのインストール自体は無料ですが、実行にはClaudeのサブスクリプションまたはAPIキーが必要です。Anthropic APIには新規登録時の無料クレジットがある場合があります。最新の無料枠はAnthropic Consoleで確認してください。

Q4: 既存のSCMソフトウェア(SAP IBP等)と何が違いますか?

SAP IBP等の商用SCMツールは統合的なプラットフォームを提供しますが、導入コストが高く(年間数千万円〜)カスタマイズに時間がかかります。Claude Codeはコーディングアシスタントとして、既存のERPデータを活用した軽量なリスク分析パイプラインを短期間で構築する用途に適しています。大規模なS&OP(販売・生産計画)を含む統合管理にはSCM専用ツールが適切です。

Q5: 小規模な製造業(従業員100名未満)でも使えますか?

使えます。むしろ、SCM専用ソフトウェアの導入が予算的に難しい中小製造業にとって、Claude Codeでの軽量パイプライン構築は費用対効果の高い選択肢です。ただし、Step 1のデータ整備(CSVエクスポートの自動化)は自社のERPや生産管理システムに依存するため、技術者のサポートが必要になる場合があります。

まとめ:今日から始める3つのアクション

  1. 今日やること:ERPから調達データを1カテゴリ分CSVエクスポートし、Claude Codeで前処理スクリプト(Step 1)を生成・実行する
  2. 今週中:リスクスコアリング(Step 2)を実装し、上位5サプライヤーのスコアを手動で検証する
  3. 今月中:外部データ統合(Step 3)とSlackアラート(Step 4)を追加し、日次監視の試験運用を開始する

エージェントAI搭載SCMソフトウェア市場は2030年に530億ドル規模と予測されています(Gartner 2026年4月)。小さなPoCから始めることで、この波に乗る準備ができます。


次回予告:次の記事では、物流業界のWMS(倉庫管理システム)連携をClaude Codeで構築するパターンを解説予定です。


著者: 佐藤傑(さとう・すぐる)
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X(旧Twitter)で活用法を発信(@SuguruKun_ai、フォロワー約10万人)。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載7回執筆(NewsPicksで最大1,125ピックス)。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。

参考・出典

この事例を実装するための技術ガイド

Next Step

この事例を、自社の業務に置き換える。

対象業務、利用データ、評価基準、社内展開の順番まで整理すると、Claude Code導入の失敗を減らせます。

導入を相談する