【2026年最新】部品メーカーRFQ対応をClaude Codeで自動化

はじめに:RFQ対応が「営業技術部の沼」になっていた話

正直に言うと、私自身は部品メーカーの社員ではない。けれどここ1〜2年、製造業のAI研修・伴走支援でいちばん多く相談を受けるのが「RFQ対応をなんとかしたい」という話だった。

ある電装部品メーカーの営業技術課長さんに、最初の打ち合わせで聞いた話がいまも頭に残っている。「うちの見積、図面を最初に見て、過去の似た案件を頭の中で探して、原価をざっくり叩いて、納期を見て、ようやく営業に回答案を出す。これが一件あたり半日〜1日。月に40件くるんですよ」。

40件で半日〜1日。単純計算で、見積前さばきだけでフルタイム1人分以上のリソースを食っていた。しかも、ベテラン1人に依存していて、その人が休むと全部止まる。

これは「AIで楽になるかも」というよりも、「AIを入れないと数年後に詰む」テーマだ、と私はずっと感じていた。なぜなら、図面の山を見て一瞬で類似案件を思い浮かべる「勘」と、原価マスタを暗算する「経験」は、年単位の現場経験でしか身につかない。新人を採用しても、即戦力にはならない。

そこで本記事では、Claude Code（ターミナル上で動くAnthropicの開発支援エージェント）を、コーディング用途ではなく「営業技術部の前さばきアシスタント」として使う具体的なやり方を、実際に研修現場でお勧めしているプロンプトと一緒に公開する。

Claude Code自体は、ローカルのファイル(PDF・Excel・CSV・テキスト)を読み書きしたり、bashコマンドを実行したりできる。これがRFQ対応とすごく相性がいい。なぜなら、RFQに付随する図面・仕様書・BOM・過去の見積データは、ほぼすべて「ローカルか社内NASに転がっているファイル」だからだ。クラウドに上げにくい機微情報も、Claude Codeのワークフロー(設定によってはAPI送信のみで端末ログ保持を最小化)なら社内のガバナンス基準に合わせやすい。

もちろん、最終的な見積金額の決定・納期の確約・顧客への回答送付は、引き続き人間(営業担当・原価担当・営業技術課長)が責任を持つ。Claude Codeはあくまで「ドラフトを30分で出してくれる優秀な新人」のポジション。ここを誤解しないでほしい。

RFQ対応業務の現状整理:どこに時間が消えているか

まず、RFQ対応のどこにボトルネックがあるかを整理する。私が複数社の現場で観察した結果、典型的にはこの5工程に分解できる。

工程	主な作業	所要時間(1件あたり)	AI余地
①図面・仕様書の読み込み	形状・公差・材質・特記事項の把握	30分〜2時間	★★★★☆
②類似案件の探索	過去の見積・受注実績から似た形状・スペックを検索	20分〜1時間	★★★★★
③原価試算	材料費・加工費・段取・歩留・外注費の見積	1〜3時間	★★★☆☆
④納期計画	自社工場の負荷・部材調達LTを踏まえた回答納期	20分〜1時間	★★★☆☆
⑤回答案作成	顧客フォーマット(PDF・Excel・メール本文)に転記	20分〜1時間	★★★★☆

このうち、Claude Codeが最も貢献するのは②類似案件の探索と⑤回答案作成だ。①と④も、社内資料の整備状況次第で大きく効く。③だけは「自社の暗黙知が一番濃い領域」で、AIに丸投げするのではなく、AIが叩き台を出して人間が修正するというワークフローが現実的になる。

ここから先は、各工程ごとに「実際に使えるプロンプト」を提示していく。すべて私が研修や個別支援の現場で実際に紹介・調整してきたものだ。コピペしてそのまま使ってもいいし、自社業務に合わせて改造してもいい。

事前準備:Claude Codeに読ませる社内データの最低構成

プロンプトを紹介する前に、Claude Codeに「読ませる」社内データの最低構成を決めておく必要がある。私が現場で推奨しているのは、以下のディレクトリ構造だ。

rfq-workspace/
├── inbox/                  # 受領したRFQの図面・仕様書・依頼書をここに置く
│   └── 20260527_顧客A_品番XYZ/
│       ├── drawing.pdf
│       ├── spec.pdf
│       └── rfq_request.pdf
├── past_quotes/            # 過去の見積データ(CSV/Excel)
│   ├── past_quotes_2024.csv
│   ├── past_quotes_2025.csv
│   └── past_quotes_2026.csv
├── bom_master/             # 部品マスタ・BOMテンプレート
│   ├── parts_master.csv
│   └── bom_templates/
├── cost_master/            # 原価マスタ(材料単価・加工レート・歩留率)
│   ├── material_unit_price.csv
│   ├── machining_rate.csv
│   └── yield_rate.csv
├── prompts/                # 本記事のプロンプトを保存しておく場所
│   ├── 01_drawing_summary.md
│   ├── 02_similar_search.md
│   ├── 03_cost_draft.md
│   ├── 04_leadtime_check.md
│   └── 05_response_draft.md
└── output/                 # Claude Codeの出力(ドラフト)を保存
    └── 20260527_顧客A_品番XYZ/

この構成にしておくと、Claude Codeに「inboxの新規RFQを読んで、past_quotesから類似案件を探して、cost_masterで原価ドラフトを出して、outputに保存して」と指示するだけで、自動でファイルを開き、検索し、書き出すところまで一気に走る。

1点だけ重要な注意がある。クラウドAIにアップロードしてはいけない情報(顧客固有図面・特殊原価率など)は、社内のガイドラインに従って取扱いを決めること。Claude Codeはローカルファイルを直接読み書きできるが、内部的にはAPIにテキストを送って推論する。送信前にマスキングする運用(顧客名・型番をXXXに置換するスクリプトを挟む等)を併用すると、情報統制と業務効率を両立しやすい。

プロンプト①:図面・仕様書の自動サマリー

最初のプロンプトは、図面PDFと仕様書PDFから「見積に必要な要素だけを抽出」するもの。Claude Code自体は画像を直接読み解くより、テキスト化された情報の整理が得意なので、PDFを事前にOCR/テキスト抽出しておくか、Claude側のファイル読み込み機能を使う形になる。

あなたは部品メーカーの営業技術アシスタントです。
以下のRFQ関連ファイルを読み込み、見積に必要な要素を構造化して抽出してください。

【読み込み対象】
- inbox/20260527_顧客A_品番XYZ/drawing.pdf
- inbox/20260527_顧客A_品番XYZ/spec.pdf
- inbox/20260527_顧客A_品番XYZ/rfq_request.pdf

【出力フォーマット(YAML)】
client_name: ""
part_number: ""
part_name: ""
material:
  primary: ""           # 例: SPCC, A5052, PA66-GF30
  surface_treatment: "" # 例: 三価クロメート, 黒色アルマイト
dimensions:
  outline: ""           # 外形寸法(主寸法のみ)
  thickness: ""
tolerance:
  general: ""           # 一般公差(JIS B 0405 m級など)
  critical:             # 重要公差のリスト
    - location: ""
      value: ""
quantity:
  one_time: 0
  annual_estimate: 0
delivery:
  initial: ""           # 初回納期希望
  recurring: ""         # 量産後の納期
special_requirements:   # 顧客特記事項
  - ""
attached_documents:     # 添付された規格・指示書
  - ""
risk_flags:             # 営業技術として気になった点(自由記述)
  - ""

【ルール】
- 図面から読み取れない項目は "" (空)のままにし、推測しないこと
- 「risk_flags」には、加工難度が高そうな箇所・追加工程が必要そうな箇所・公差が厳しい箇所を箇条書きで列挙
- 推測した値には必ず「(推定)」と付記すること
- 出力はYAMLのみ。コメントや前置きは不要

このプロンプトのポイントは「推測した値には必ず(推定)と付記」させていること。営業技術の現場では、図面に書いていないことを勝手に埋めてしまうと後で大事故になる。Claude Codeも当然間違えるので、「これは推定です」「これは確定です」を出力時に明示させるルールが効く。

研修で実際にやってもらうと、「材質欄が空欄なのに何かを書いてくる」みたいな出力もたまに発生する。そのたびに「推測した値には(推定)」というルールを強化していくと、だんだん安定してくる。

プロンプト②:過去類似案件の自動探索

次が、いちばん体感効果の大きい類似案件探索。past_quotes.csvに過去案件が蓄積されている前提で、Claude Codeに「特徴ベース」で似た案件を引いてくる。

あなたは部品メーカーの営業技術アシスタントです。
本日受領したRFQと類似する過去案件を、past_quotes フォルダの CSV から検索してください。

【現RFQの特徴(プロンプト①の出力をここに貼る)】
client_name: ○○自動車部品株式会社
part_number: XYZ-001
material:
  primary: A5052
  surface_treatment: 黒色アルマイト
dimensions:
  outline: 120 x 80 x 4.5
quantity:
  one_time: 500
  annual_estimate: 12000

【検索ルール】
1. past_quotes/ 配下の全CSVを読み込み、以下の優先度で類似案件を探すこと:
   - 優先度A: 同一顧客 × 同系列品番(品番接頭辞一致 or 部品カテゴリ一致)
   - 優先度B: 同材質 × ±20%サイズ × 同年度量±50%
   - 優先度C: 同加工種別(板金/切削/プレス等)で類似形状
2. 各候補について以下を出力:
   - 案件ID, 受注日, 顧客名, 品番, 材質, 数量, 単価, 加工種別, 主要工程
3. 単価は「材料費 / 加工費 / その他 / 合計」に分解できる場合は分解
4. 最後に「今回案件との差分」を箇条書きで述べる(数量倍率・材質違い・公差違い等)

【出力フォーマット】
## 類似案件 トップ5
| 案件ID | 受注日 | 顧客 | 品番 | 材質 | 数量 | 単価 | 一致度 |
|...|

## 各案件の差分メモ
### 案件ID: XXX
- 数量: 今回500 vs 過去2000 → 単価上昇要因
- 公差: 今回±0.05 vs 過去±0.1 → 工程追加検討
- ...

## 営業技術コメント(今回見積の留意点)
- ...

【ルール】
- past_quotes に同等の案件がない場合は「該当なし」と明記し、推測で書かないこと
- 「一致度」は A/B/C で表記し、根拠を「材質一致・サイズ近似・量±30%以内」等で説明

これが効くのは、ベテラン営業技術の「あの時のあの案件に似てるな」を、CSVの全件検索で再現できるところ。人間の記憶は古い案件・自分が担当していない案件には弱いが、Claude Codeは年単位の全件をフラットに検索できる。

注意点として、past_quotes.csvに「加工種別」「主要工程」「材質」のような構造化カラムがないと、探索の精度が一気に落ちる。研修現場でこのプロンプトを試す前に、まず「過去案件CSVのカラム整備」をやることを強く勧めている。データ整備2割・プロンプト8割ではなく、データ整備5割・プロンプト5割が現実だ。

プロンプト③:原価試算ドラフトの生成

原価試算は、AIに丸投げするべきではない領域だ。理由は単純で、自社の原価ロジック(歩留率の刻み・段取費の根拠・外注先選定基準)は、外に出していない暗黙知の塊だから。AIが「それっぽい数字」を出してしまうと、新人が信じて顧客に出してしまう事故が起きる。

だからこのプロンプトは「ドラフト=たたき台」を作るところまで。最終チェックは必ず原価担当が行う前提で組む。

あなたは部品メーカーの見積アシスタントです。
以下の情報を元に、原価試算のドラフトを作成してください。最終チェックは人間の原価担当が行います。

【現RFQ(プロンプト①出力)】
(YAMLを貼る)

【類似案件参考(プロンプト②出力)】
(類似案件表を貼る)

【参照マスタ】
- cost_master/material_unit_price.csv
- cost_master/machining_rate.csv
- cost_master/yield_rate.csv

【試算ルール】
1. 材料費 = (部品重量) × (材料単価) ÷ (歩留率)
   - 部品重量は図面から計算できない場合は「(要確認)」と明記し、類似案件比から推定範囲を提示
2. 加工費 = (主要工程ごとのサイクルタイム見積) × (加工レート)
   - 工程はプロンプト①の risk_flags と類似案件から推定
   - 推定根拠を「類似案件XXXのサイクルタイムYY秒を参照」と必ず明記
3. 段取費 = 加工費の 10〜20% で仮置き(レンジで提示)
4. 外注費 = 表面処理・熱処理・特殊加工が含まれる場合のみ計上、未確定なら「(外注見積待ち)」
5. 諸経費 = 直接費の 15% を仮置き
6. 利益率 = 自社標準値(別途指定された場合はそれを使う、なければ 12% で仮置き)

【出力フォーマット】
## 原価試算ドラフト(自動生成・要原価担当確認)

| 項目 | 単価(円) | 数量 | 小計(円) | 根拠 |
|-----|---------|-----|---------|------|
| 材料費 | xx | 500 | xxx | 類似案件XXX参照、歩留85%仮定 |
| 加工費 | xx | 500 | xxx | サイクルタイム45秒(類似XXX) |
| 段取費 | xx | 1式 | xxx | 加工費の15% |
| 外注費 | xx | 500 | xxx | アルマイト処理(外注見積待ち) |
| 諸経費 | xx | - | xxx | 直接費15% |
| 利益 | xx | - | xxx | 標準利益率12% |
| **見積単価** | **xxx** | - | - | - |

## 要確認事項(原価担当へ)
- 部品重量の確定値
- アルマイト処理の外注先と単価
- 量産展開時の単価逓減ロジック

## 営業技術リスク
- xxxx

このプロンプトで毎回ちゃんとやるのは「要確認事項を最後に列挙させる」こと。原価担当に渡したときに「で、ここどうするの?」を逆質問してもらう。AIが出した数字をそのまま客に出さないための、いちばん大事な防御線だ。

プロンプト④:納期計画の整合性チェック

4つ目は納期計画。自社工場の生産負荷データ(週次の空き工数)と、部材調達リードタイム(発注から納品まで)を踏まえて、顧客の希望納期に応えられるかを判定する。

あなたは部品メーカーの生産管理アシスタントです。
以下の情報を元に、今回RFQの納期回答ドラフトを作成してください。

【現RFQ(プロンプト①出力)】
delivery:
  initial: 2026-07-31
  recurring: 月次500個 / 24ヶ月予定
quantity:
  one_time: 500
  annual_estimate: 12000

【参照データ】
- production/factory_capacity_weekly.csv (週次・工程別の空き工数)
- procurement/material_leadtime.csv (材料・サブパーツの調達LT)
- production/outsource_leadtime.csv (外注表面処理等のLT)

【判定ルール】
1. 部材調達LTを cost_master / procurement から取得し、最長LTを「部材LT」とする
2. 自社加工のサイクルタイム × 500個を、工程別の空き工数に当てはめ、必要週数を算出
3. 外注工程(アルマイト等)がある場合は外注LTを加算
4. 全体LT = 部材LT + 自社加工週数 + 外注LT + バッファ(7日)
5. 「希望納期 - 全体LT」がマイナスなら「希望納期未達のリスクあり」と明記し、代替提案を出す

【出力フォーマット】
## 納期回答ドラフト

### 全体LT試算
| 段階 | 期間 | 開始 | 終了 |
|-----|-----|-----|-----|
| 受注確定 | 0日 | 2026-06-15 | 2026-06-15 |
| 部材手配 | 21日 | 2026-06-15 | 2026-07-06 |
| 自社加工 | 14日 | 2026-07-06 | 2026-07-20 |
| 外注処理 | 7日 | 2026-07-20 | 2026-07-27 |
| 検査・出荷 | 4日 | 2026-07-27 | 2026-07-31 |
| **回答納期** | **46日** | - | **2026-07-31** |

### 判定
- 希望納期: 2026-07-31
- 自社見立て: 2026-07-31(ぎりぎり可能 / 一部工程のリスクあり)
- 量産時の月次500個ペースは、現状の工場負荷で xx 月以降であれば対応可

### 代替提案(希望納期に間に合わない場合のみ)
- 数量分割: 初回ロット300個を2026-07-15、残り200個を2026-08-15
- 材料先行手配: 受注前に材料を先行手配する条件で-5日短縮可能

【ルール】
- factory_capacity に該当工程の空き工数が無い場合は「要生産管理確認」と明記
- 数字を勝手に作らないこと。元データに無い数字は出さない

納期は数字の積み上げと判断が混じる領域だ。完全自動化ではなく、「材料LT/加工LT/外注LT」のそれぞれの数字をAIに引っ張ってもらった上で、生産管理担当が「これは無理がある」「ここは詰められる」を判断する形が、現場では一番受け入れられる。

プロンプト⑤:営業部門向け回答案の自動生成

最後は、営業部門に渡す回答案ドラフトの生成。ここまでに作った材料(プロンプト①〜④の出力)を全部突っ込んで、「顧客に送れる文章」のひな型を作る。

あなたは部品メーカーの営業技術アシスタントです。
以下の情報を元に、営業担当が顧客に送るための回答案ドラフトを作成してください。

【入力】
- プロンプト①のRFQ要約YAML
- プロンプト②の類似案件メモ
- プロンプト③の原価ドラフト
- プロンプト④の納期ドラフト

【出力フォーマット】
## 営業部門向け回答案ドラフト

### 1. 顧客向けメール本文(下書き)
---
件名: 【お見積回答】品番XYZ-001のお見積につきまして

○○自動車部品株式会社
○○ご担当者様

平素より格別のお引き立てを賜り、誠にありがとうございます。
○月○日にご依頼いただきました品番XYZ-001のお見積につきまして、下記の通りご回答申し上げます。

■品名:○○○
■数量:初回500個、量産時 月次500個(年間12,000個想定)
■お見積単価:○○○円(税別)
■初回納期:2026年7月31日
■量産納期:受注確定後、月次出荷
■見積有効期限:2026年6月30日

■備考
- 材料費は受注時の市況により変動する可能性がございます
- 表面処理は外注先確定後の単価変動可能性がございます
- 公差○○○については追加工程が必要となる可能性があり、量産検討時に再度ご相談させてください

ご不明点がございましたらお気軽にお申し付けください。
何卒よろしくお願い申し上げます。
---

### 2. 営業部門向け補足メモ(社内共有用)
- 類似案件: 案件ID XXX(2025年4月受注、同顧客・同系列品番)を参照
- 原価担当チェック必須項目: 部品重量・外注単価
- 生産管理確認事項: 量産時の工場負荷見込み
- 営業技術リスク: 公差○○○、特記事項○○○

### 3. 質問リスト(顧客に追加確認したい事項)
- ○○○について、図面に明記がないため確認させてください
- 量産展開時の年間数量は12,000個の想定で問題ないでしょうか
- 表面処理の規格指定は弊社既定で進めて問題ないでしょうか

【ルール】
- 顧客向け文章は丁寧語・敬語で。社内向け文章は簡潔に
- 価格・納期は必ず「(原価担当確認後)」「(生産管理確認後)」と注釈を付けてドラフトであることを明示
- 自社にとって不利な含みを持つ表現(「絶対」「保証」「確約」)は避ける
- 質問リストは少なすぎず多すぎず3〜5項目

このプロンプトの肝は、最後の「質問リスト」だ。RFQ対応で意外と詰まるのが「客に追加確認しないと進まない」事項を見落とすこと。Claude Codeに先回りで質問リストを作らせると、「ああ、これ確認しないと出せないやつだった」という気づきが早くなる。

プロンプト①〜⑤の連携ワークフロー:1件のRFQをどう流すか

ここまで5本のプロンプトを個別に紹介してきたが、実運用では「1件のRFQに対して順番に流す」連携ワークフローが必須になる。Claude Code上では、これを1つの会話セッションの中で連続実行できる。私が現場で勧めているのが、以下のセッション運用だ。

Claude Codeを起動したら、ターミナルでまずワーキングディレクトリを移動する。「cd rfq-workspace」してから「claude」と打って起動するイメージだ。そこから1つの会話セッションの中で、プロンプト①→②→③→④→⑤を順番に貼り付けていく。前のプロンプトの出力が、次のプロンプトの「入力」になる構造なので、セッション内で状態を保持できるClaude Codeのこの特性は非常に便利だ。

1件あたりの目安時間は、慣れてくると30〜45分。内訳としては、プロンプト①が5〜10分(PDF読み込みと出力)、②が10〜15分(過去案件CSVのスキャン)、③が10分(原価マスタ参照と計算)、④が5分、⑤が5〜10分という配分。最初のうちは1件1時間半くらいかかるが、5件回す頃には半分以下に短縮される。

もう1つ重要なポイントとして、各プロンプトの出力を必ず「output/案件番号/01_drawing.md」のようにファイル保存することを徹底する。理由は3つある。1つ目は、原価担当・営業担当への共有がファイル単位で楽になること。2つ目は、後でナレッジ蓄積するときに「過去どんな出力を出していたか」を参照できること。3つ目は、AIの出力品質を定期レビューするための監査証跡が残せること。

Claude Codeに「output/20260527_顧客A_品番XYZ/01_drawing.md として保存して」と指示すれば、自動でディレクトリを作って書き出してくれる。手動でコピペするより遥かに楽だ。

BOM(部品表)整合性確認の追加プロンプト

もう1つ、補助的なプロンプトとして「BOM整合性確認」を紹介しておく。これは、量産展開を見越したRFQで特に効く。

あなたは部品メーカーのBOM整合性チェッカーです。
今回RFQの構成部品リスト(BOMドラフト)と、bom_master 配下のテンプレートを照合してください。

【今回RFQのBOMドラフト】
(顧客から提供されたBOM or 自社で起こした構成リスト)

【参照】
- bom_master/parts_master.csv (自社部品マスタ)
- bom_master/bom_templates/ (類似製品の標準BOM)

【チェック項目】
1. 部品マスタに登録がない部品 → 新規登録要のフラグ
2. 標準BOMとの差分 → 構成違いを箇条書き
3. 共用部品の使用 → 量産時のコストダウン余地を提示
4. 在庫品 vs 受注購買品 の区分
5. 単一供給先(シングルソース)部品 → BCPリスクとしてフラグ

【出力フォーマット】
## BOM整合性チェックレポート

### 新規部品(マスタ未登録)
| 部品コード | 部品名 | サプライヤ | 単価 |
|...|

### 標準BOMとの差分
- 部品A: 標準ではA-100だが今回はA-200指定(理由不明 → 顧客確認推奨)

### コストダウン余地(共用部品提案)
- 部品Bを既存共用部品Cに置換可能(月間使用量+15%により単価低減見込み)

### BCPリスク
- 部品D: シングルソース、代替供給先の事前確保推奨

### 営業技術コメント
- ...

これは量産展開フェーズに入ったRFQで、新人営業技術が見落としがちな「BOMの細かい差分」「単独購買リスク」を、AIに先回りで指摘させるためのプロンプト。原価試算の前にこれを通しておくと、後工程の手戻りが減る。

【要注意】失敗パターン:こうやって運用すると事故る

ここまでプロンプトを5本+1本紹介してきたが、実際に現場に入れる前に必ず押さえてほしい失敗パターンがある。私の研修先や個別支援先で実際に起きた事故ベースで書いている。

❌ 失敗パターン1:AI出力を営業担当がそのまま客に送る

これは絶対NGなのに、必ず起きる。AIが出した見積単価をそのままメール本文にコピペして顧客に送ってしまい、後で「単価が10倍違う」「公差が違う」というクレームに繋がるケース。

⭕ 正しい運用:Claude Codeの出力は必ず「ドラフト」と明記し、原価担当のチェックが入る前のメールは送信ボタンを押せないフローにする。具体的には、SalesforceやkintoneのようなCRMで「原価担当チェック完了フラグ」が立たないと顧客送信できないステータス遷移にする、というのが現場で見た解決策だった。

❌ 失敗パターン2:過去案件CSVの整備が中途半端なまま走る

「データはCSVで持ってるから大丈夫です」と言われて見せてもらうと、カラムが「品番・金額・備考」の3つしかない、みたいな案件が結構ある。これだと類似案件探索のプロンプト②が、ほぼ役に立たない。

⭕ 正しい運用:プロンプト②を回す前に、過去案件CSVに最低限「材質・加工種別・主要工程・数量・単価分解・公差レベル」のカラムを追加する。半年分でいいので、過去のExcel見積から手作業で構造化データを起こしておく。この投資が一番リターンを生む。

❌ 失敗パターン3:機微情報をクラウドに上げてしまう

顧客から「他社に出さないでください」と明記されている図面・特殊原価率を、なんとなくChatGPT Webにペーストしてしまう。これは情報漏洩事故になる可能性が高い。

⭕ 正しい運用:Claude Codeを使う場合も、APIには本文が送られる。ローカル完結ではない。だから、機微情報は必ず社内のガイドラインに従って取扱う。顧客名・型番をXXXに置換するマスキングスクリプトを前段に挟む、特殊原価率は別ファイルに切り出してプロンプトに含めない、といった運用が現実解。Anthropic公式のドキュメントも、データ取扱いポリシーを必ず一読してから始めること。

❌ 失敗パターン4:プロンプトを各人が好き勝手にいじって標準化しない

最初は「すごい便利!」と1人が使い始めて、その人なりにプロンプトを改造しまくる。半年後、別の人がやろうとしても「俺は俺のプロンプトを使う」になって、ナレッジが個人化する。

⭕ 正しい運用:rfq-workspace/prompts/ のように、組織共通のプロンプト集を1箇所に置いて、Git管理する(ローカルGitでOK)。改造したら必ずコミットメッセージで「なぜ変えたか」を残す。AIプロンプトもコードと同じで、属人化させた瞬間にメンテ不能になる。

業種別の応用例:自動車部品と電子部品では何が変わるか

本記事は自動車部品と電子部品の両方を対象にしているが、業種ごとに微妙にプロンプトのチューニングが変わってくる。私が実際に現場で見てきた違いを書いておく。

自動車部品メーカーの場合

自動車部品の特徴は、量産展開時の年間数量が大きい(数千〜数十万個/年)こと、ティア1・ティア2の階層構造でサプライヤが組まれること、PPAP(部品認定プロセス)などの品質保証プロセスが厳格なこと。これらを踏まえて、プロンプトに以下の調整を入れるといい。

• プロンプト②(類似案件探索)では、検索キーに「ティア1顧客の名称」「車種・プラットフォーム」を加える。同じプラットフォーム向け部品は構造的に似ている確率が高い
• プロンプト③(原価試算)では、「型費の按分」「量産時の単価逓減率(年5〜10%程度のコストダウン要求が一般的)」を試算ロジックに組み込む
• プロンプト⑤(回答案生成)では、PPAP対応・初期流動管理体制の説明欄を追加する

特に「型費按分」は自動車部品見積の独特の論点で、AIに正確な按分を任せるのは難しい。営業技術と原価担当のすり合わせ材料として、AIには「過去の類似品番では○○円/個で按分されていました」という参考情報の提示までやらせるのが、現実的なライン。

電子部品メーカーの場合

電子部品の特徴は、品種が膨大(同じ型番でも電圧・容量・温度範囲で数十SKUに分岐)、ライフサイクルが短く廃番が多い、EOL(製造終了)情報のキャッチアップが重要、というところ。

• プロンプト①(図面サマリー)では、データシートの読み込みを追加する。仕様書PDFというよりデータシートPDFが主体になる
• プロンプト②(類似案件探索)では、「電気的特性(電圧・容量・温度範囲)」を必須カラムにする。形状ベースではなくスペックベースの探索が中心
• プロンプト③に「ロット指定LT」「最小ロット数(MOQ)」「テープ&リール梱包仕様」のチェックを追加
• BOM整合性チェック(補助プロンプト)で「EOL予定品の使用検知」を入れる

電子部品はBOMに含まれる部品点数が多く、BOM整合性チェックの重要度が自動車部品よりさらに高い。プロンプト⑥(BOM整合性確認)を必ず通すワークフローを推奨している。

導入ステップ:小さく始めて広げる

ここまで読んで「うちでもやりたい」と思った方向けに、現実的な導入ステップを書いておく。研修現場でいちばんよく勧めているのが、この6ステップだ。

1. パイロット担当を1名決める(営業技術の中で、ITに少し強い人がベスト。完璧でなくていい)
2. サンプルRFQを5件選ぶ(過去に受注済みで、結果がわかっているものがいい。AIの出力と実際の見積を比較できる)
3. 過去案件CSVのカラムを最低6項目に増やす(材質・加工種別・数量・単価分解・公差レベル・受注/失注)
4. 本記事のプロンプト5本を組織共通のリポジトリに保存(社内の共有ドライブでもGitでもOK)
5. パイロット担当が5件回して所要時間と精度を測定(1件あたりの工数・出力の修正率を記録)
6. 営業技術部全体に展開、月次でプロンプト改善会を開く(うまくいかなかったケースを共有し、プロンプトに反映)

大事なのは、最初から完璧を目指さないこと。プロンプトは生き物で、現場の実データに当てて初めて欠陥が見える。私が支援している企業でも、3ヶ月でようやく「自社用のプロンプト」が安定し、6ヶ月でやっと営業部全体に展開できる、というペースが多い。

既存システムとの連携:CRM・販売管理・原価管理との接続

RFQ対応のAI化を本格運用に乗せようとすると、必ず「既存システムとどう繋ぐか」の話になる。多くの部品メーカーでは、Salesforce・kintone・楽々販売・OBIC7・自社製のオフコン系業務システムなど、すでに業務システムが動いている。Claude Codeはそれらの「代替」ではなく「前段の補助」として位置づけるのが現実的だ。

具体的な接続パターンを3つ紹介する。

パターンA:ファイルベース連携(最も簡単)

業務システムから過去案件CSVをエクスポートして、rfq-workspace/past_quotes/ に置く運用。手動でも自動(夜間バッチ)でもできる。最初の3ヶ月はこのパターンで十分。Claude Codeは社内データに「読み専用」でアクセスするだけなので、業務システム側に変更を加える必要がない。情シスの承認も取りやすい。

パターンB:API連携(中級)

SalesforceやkintoneのREST API経由で、Claude Codeから過去案件を直接検索する。スクリプトを書いてClaude Codeにbashコマンドとして実行させる形になる。リアルタイム性が必要な場合(例えば、引き合い受付した瞬間に過去類似案件を自動でアサイン)はこちらが有利。

ただし、APIキーをClaude CodeのCLIに渡すことになるので、情報セキュリティ部門との調整が必要。APIキーはrfq-workspace/.envに置き、Gitには絶対コミットしないルールを徹底する。

パターンC:RPAとの組み合わせ(上級)

オフコン系の閉じた業務システムからは直接データを取れないので、UiPath・WinActor・Microsoft Power AutomateなどのRPAでCSVを吐かせ、それをClaude Codeに食わせる構成。製造業のレガシーシステムが多い現場では、これが現実解になることが多い。

どのパターンを選ぶかは、自社の業務システム・情シス体制・予算で決める。私が研修先で勧めているのは「まずパターンAで3ヶ月、効果が見えたらパターンB/Cを検討」という段階的アプローチ。最初からシステム連携にこだわると、AIに辿り着く前にプロジェクトが頓挫する。

失敗事例の深掘り:なぜプロジェクトが頓挫するか

AI導入プロジェクトの失敗事例は、技術的な問題よりも組織的な問題の方が多い。私が観察してきた頓挫パターンを3つ挙げておく。

1つ目は「決裁者がAIに過度な期待をするパターン」。経営層が「AIを入れれば見積工数が90%減るんですよね?」と最初に言ってしまい、3ヶ月後に「40%しか減ってないじゃないか」と失望される。これを避けるには、最初に「3〜6ヶ月で20〜30%削減」「1年で40〜50%削減」のような現実的な数字を共有しておくこと。

2つ目は「現場担当者が学習コストを嫌がるパターン」。「いまのやり方で間に合ってるから別にいい」となって、パイロット担当が孤立する。これを避けるには、パイロット担当の評価をAI効果連動にする、または上司が「君の主業務として時間を確保する」と明示すること。片手間でやらせると100%失敗する。

3つ目は「ガバナンスが先行しすぎるパターン」。情報セキュリティ部門が「全データを社内オンプレに置かないとAI使用禁止」と言い出し、そもそも始められない。これは、最初に小規模のサンプルデータ(顧客名をマスキングした過去案件20件など)で「触る用」のデータセットを作り、本番データへの拡大は段階的にやる、という運用設計で回避できる。

これら3つの組織的な落とし穴を、技術検証より先に潰しておくことが、製造業AI導入の本当の勝負所だと私は思っている。

ROIの目安:どれくらい時間が浮くか

具体的な金額は企業ごとに差が大きいので断言できないが、複数社の現場観察を踏まえた目安としては、こんなところだ。

項目	導入前	導入後	削減幅
RFQ1件あたりの初動工数	3〜6時間	1.5〜3時間	約40〜50%
類似案件探索の所要	20〜60分	5〜10分	約75%
原価試算ドラフトの所要	1〜3時間	30分〜1時間	約50%
顧客回答メール作成	20〜40分	10〜15分	約60%

これらは想定例であり、自社のデータ整備度・担当者のITリテラシー・既存業務フローの整理度で大きく変わる。私が見てきた中では、データ整備が0からのスタートだと半年は所要工数が大きく動かない。逆に、ある程度CSV化が進んでいた企業は、3ヶ月で2割削減を実感できていた。

ROIを経営層に説明する際は、時間削減だけでなく「機会損失の回避」を必ずセットで語るといい。RFQ対応が遅れて失注に繋がるケース、ベテランが休んで案件が滞留するケース、新人が出した見積で原価割れを起こすケース、これらは「目に見える時間短縮」より遥かに金額インパクトが大きい。製造業の経営層に響くのは、絶対こちらの話題だ。

もう1つ強調しておきたいのが「営業フロントの感覚速度」が上がること。お客様にRFQをいただいてから「3日以内に概算回答」できるようになると、競合との初動勝負で優位に立てる。1週間後に正式回答を出す競合と、3日で概算+1週間で正式の二段構えで出す自社、では商談の主導権が違ってくる。これも金額化はしにくいが、現場の営業はすぐ実感できる効果だ。

そして、もう1つ重要なROIがある。それは「ベテラン依存の解消」だ。営業技術歴20年の方が1人で回している部署では、その人が休んだ瞬間に全部止まる。Claude Code+プロンプト集を整備しておくと、新人や派遣の方でも「ベテランの思考プロセスをAIが代行してくれる」ので、属人化リスクが大きく下がる。これは金額で測りにくいが、経営的にはもっとも重要なROIだと私は思っている。

運用が回り始めた後の継続改善:プロンプトの育て方

プロンプトは1回作って終わりではない。実運用で当てると必ず「思ったように動かない」「特定のパターンで間違える」が出てくる。育て方の現場ノウハウを共有しておく。

私が研修先で勧めているのは「失敗ログを残す」運用だ。AIの出力をそのまま採用できなかったケース、原価担当が修正したケース、営業担当が顧客とのやり取りで気づいて差し戻したケース、これらを月次で集めて「なぜAIは間違えたか」「プロンプトに何を追加すれば防げたか」をチームで議論する。これを3〜6ヶ月続けると、自社特化型の強いプロンプト集に育っていく。

具体的に、プロンプト改善でよく追加されるのが、以下のような「禁則ルール」だ。

• 「材料費を計算する際、板厚が不明な場合は重量推定をせず必ず空欄にする」
• 「歩留率の仮置きは80%を超えない(自社の経験則として超える歩留は危険)」
• 「公差±0.05以下は『要相談』フラグを立て、AIが見積に組み込まない」
• 「アルマイト処理を含む案件では、必ず外注先の選定を要確認とマークする」

これらは自社の暗黙知をプロンプトに少しずつ埋め込んでいく作業で、最初は誰も書けない。3ヶ月運用して初めて、現場担当が「あ、これプロンプトに書いたほうがいいですね」と気づき始める。だからこの「3ヶ月の我慢」をいかに乗り切るかが、AI導入プロジェクトの本当の難所だ。

もう1つ大事なのが、プロンプトのバージョン管理。Gitでなくても、ファイル名に日付を入れて「01_drawing_summary_v2_20260601.md」のように管理するだけでも、過去のプロンプトに戻れる。改造して失敗したらすぐ戻せる仕組みを最初から用意しておくと、改善のスピードが上がる。

セキュリティとガバナンスの基本

製造業のRFQ対応は、顧客の機微情報・自社の競争力の源泉(原価率・サプライヤ情報)が交差する領域だ。AIを入れる際のセキュリティ・ガバナンスの基本だけ、簡潔に整理しておく。

• データ取扱いポリシーを社内で明文化する:Claude Code(Anthropic API)に送ってよい情報・送ってはいけない情報の線引きを、情報セキュリティ部門と握る
• マスキングを前段に挟む:顧客名・型番を置換するスクリプトを必ず通す
• ログを社内で保持する:Claude CodeのCLIログ・出力ファイルを、社内サーバに月次で集約してレビュー可能にする
• NDA上の制約を確認する:顧客との秘密保持契約に「AIへの入力は別途承認」のような条項があるか確認
• 定期的なプロンプト監査:プロンプトの中に固有名詞・原価率・特殊条件が漏れていないか、3ヶ月に1回はチームでレビュー

これらは「やらないと事故る」というよりも、やっておくと「社内で堂々と展開できる」「経営層に説明できる」というガバナンス上の意義が大きい。社内のAI活用がここで止まる企業もよく見るので、初期段階で押さえておくと後が楽だ。

現場担当者の声:導入支援先での実際の反応

研修・伴走支援の現場で、RFQ対応にClaude Codeを入れた後の現場担当者から実際に聞いた反応を、編集してまとめておく(個別社名は伏せ、内容を一般化している)。

ある電装部品メーカーの営業技術課長:「最初は『AIにうちの図面なんか読めるの?』と疑っていました。でも、図面に書いてある材質・公差・特記事項を抽出するくらいなら、想像以上に正確でした。むしろ、新人が見落としていた『特記事項に小さく書かれた条件』をAIが拾ってくれて、ヒヤリハットを防げたケースもありました」。

別の自動車部品メーカーの原価管理担当:「正直、最初の1ヶ月は『この原価ドラフトは使い物にならない』と思っていました。でも、それはAIが悪いんじゃなくて、うちの原価マスタが古かったり、歩留率の入力が間違っていたりが原因でした。AIを入れたおかげで、自社のデータ品質の悪さに気づけたのが一番の収穫かもしれない」。

別のメーカーの営業部長:「営業の立場としては、技術部から回ってくる回答案の質が安定したのがありがたい。前はベテランが書いたものと新人が書いたもので品質差がありすぎて、新人案件は私が全部目を通していた。今はAI+技術部のレビューで、ある程度のレベルが担保されている」。

これらの声からわかるのは、AI導入の効果は「時間短縮」だけじゃないということ。データ品質の見える化、品質のばらつき低減、暗黙知の言語化、これらの副次効果が、長期的にはむしろ大きい。

関連事例:製造業の他工程でのClaude Code活用

RFQ対応以外にも、製造業ではClaude Codeが効く工程が複数ある。Uravationでも、以下のような事例を取り扱っている。

• 製造業のサプライチェーンリスク予測をClaude Codeで5ステップ自動化 — 部材調達LTの監視・代替サプライヤ提案など、購買側の運用と組み合わせると効果が大きい
• 製造業の品質検査レポート自動生成をClaude Codeで実装 — RFQで受注した後の量産フェーズで効く。検査記録の自動集計とNG分析
• 製造業の生産管理業務をClaude Codeで効率化する実践例 — RFQの納期回答(プロンプト④)と直接連携できる。工場負荷情報の自動収集

RFQ対応のプロンプトは、これらの他工程プロンプトと連携させると更に効く。例えば、RFQ④の納期チェックを生産管理側のリアルタイム工場負荷データと繋ぐと、回答精度が一段上がる。

よくある質問(FAQ)

Q1. Claude Codeと普通のChatGPTで何が違うのか?

普通のChatGPT(Webブラウザ版)は、ファイルを都度アップロードする必要があり、社内NASやローカルディレクトリを直接読めない。Claude Codeはターミナルで動き、ローカルファイルを直接読み書きし、bashコマンドも実行できる。RFQ対応のように「社内に大量のファイルがある業務」では、Claude Codeの方が圧倒的に運用しやすい。

Q2. 図面PDFの内容をどこまで読めるのか?

PDFの中にテキストが埋め込まれていれば、かなり正確に読める。スキャンしただけのPDF(画像化されている)は、OCR処理を先にかける必要がある。図面の幾何情報(寸法線・公差マーク・断面記号)を正確に読み解くのは、現状のAIだとまだ苦手な領域。「主寸法と材質と特記事項」レベルなら読める、と思っておくのが現実的。

Q3. CAD(STEP/IGES)を直接読めるか?

そのままでは難しい。CADデータを「重量・体積・主寸法」のような数値情報に変換するCAD CAMツールの出力を、Claude Codeに渡す形が現実的。CADから自動で寸法情報を抽出する社内マクロを書いて、その出力をプロンプトに食わせる構成にすると、精度が上がる。

Q4. プロンプトの整備に何ヶ月かかるか?

パイロット担当1名が片手間でやって、5件で1ヶ月、20件で3ヶ月、組織展開できる安定版で半年、というのが私の見立て。最初の2週間が最も「使い物にならない」と感じる期間で、ここで諦めないことが大事。

Q5. 営業担当が嫌がる/使いこなせないと想定されるが?

これはほぼ全社で起きる。営業はAIの操作を覚えるより、客と話す方が好き。だから運用設計としては「営業はAIを操作しない、営業技術がAIに前さばきさせて、営業には完成したドラフトを渡す」分担にする。プロンプトを叩くのは営業技術の役目、と割り切るのが現実的だ。

Q6. 経営層への説明はどう組み立てればいい?

「業務効率化」より「ベテラン依存の解消」「人材育成期間の短縮」を強調する方が刺さる。RFQ対応はベテランに依存しがちな業務で、5年・10年の経験がないと回せない。AIを入れることで、その経験を半分の期間で身につけられるという文脈にすると、経営層は理解しやすい。

Q7. 失敗したらどれくらいの損害になるか?

本記事のように「ドラフト生成までをAIに任せ、最終判断は人間」の運用設計にしておけば、致命的な損害は出にくい。最悪のケースでも「ドラフトに間違いがあり、原価担当の修正で余分に30分かかった」レベル。逆に、AIの出力を無検証で顧客に送ってしまうと、原価割れの受注、納期未達のクレーム、機微情報の漏洩、といった大事故になる。だから「人間チェックゲートを必ず通す」運用設計が、何よりの保険だ。

Q8. 助成金は使えるか?

厚生労働省の「人材開発支援助成金 事業展開等リスキリング支援コース」は、生成AI・Claude Codeの研修費用を対象にできる可能性がある。営業技術部にAI研修を入れる文脈なら、社労士と相談の上で申請を検討してもいい。ただし制度は毎年度改正されるため、最新情報は厚生労働省の公式パンフレットで必ず確認すること。

導入後3ヶ月・6ヶ月・1年で見るべき指標

導入を始めたら、定期的に進捗をレビューする必要がある。漠然と「うまくいってる気がする」では、経営層への説明にも、現場の改善にも繋がらない。私が伴走支援先で勧めている、フェーズ別の見るべき指標を整理しておく。

導入3ヶ月時点では、「パイロット担当の月間処理件数」「1件あたりの初動所要時間」「AI出力の人間修正率(=どれくらいの割合で原価担当が大きな修正を入れたか)」の3つを必ず測る。この時点ではROIを出すには早いので、量的な感触をつかむ。

導入6ヶ月時点では、パイロット担当以外への展開状況、プロンプトの改善履歴(月何件のプロンプト改修が入ったか)、AI出力起因の事故・ヒヤリハット件数、を追加する。ここでようやくROIの試算ができる段階になる。

導入1年時点では、営業フロントの感覚速度(顧客への初回回答までの平均日数)、失注率の変化、ベテラン1人欠勤時の業務継続性、までを評価対象にする。本当の意味でAIが組織に定着したかは、1年後の継続性で判断するしかない。

まとめ:RFQ対応はAI導入の「最初の山」として最適

製造業でAIを入れたいけど、どこから始めればいいかわからない、という相談を本当に多く受ける。私はいつも「RFQ対応から始めるのがいいですよ」と答える。理由はシンプルだ。

• 毎月一定件数発生する(=効果測定がしやすい)
• 過去データがそれなりに溜まっている(=AIが学習しやすい)
• 属人化していて経営層も問題視している(=予算が出やすい)
• 営業技術部だけで完結できる(=全社展開を待たずに始められる)

本記事のプロンプト5本+BOM補助1本は、すぐに試せるレベルまで具体化して書いた。手元のRFQ1件で、30〜60分試してみてほしい。それで「これは使える」と感じたら、ぜひ本格運用に進めてほしい。

もし社内展開で詰まったり、自社用にプロンプトをチューニングしたい場合は、Uravationの個別指導・伴走支援で一緒に組み立てることもできる(後述のCTA参照)。

著者プロフィール

佐藤傑(さとう・すぐる)。株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。100社以上の企業向けにAI研修・導入支援を提供。製造業の現場(自動車部品・電子部品・金属加工・化学)でのAI導入伴走経験多数。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載7回執筆。

次のアクション

本記事を読み終えたら、ぜひこの3つのどれかを試してみてほしい。

1. 今日試す:プロンプト①(図面サマリー)だけ、手元のサンプルRFQ1件にClaude Codeで当ててみる。所要30分。これだけで「使えそう/使えなさそう」の感覚がつかめる
2. 今週試す:過去案件CSVに「材質・加工種別・数量・単価分解」のカラムを追加し、プロンプト②(類似案件探索)を5件で回してみる。1〜2日
3. 今月試す:本記事のプロンプト5本を全て自社用に少し改造し、パイロット担当1名で月20件のRFQに対して並行運用してみる。所要工数の比較データを取る

Uravationでは、製造業向けにClaude Code導入の個別指導・伴走支援を提供しています。「うちの現場でやろうとすると詰まるところがあって…」というご相談、お気軽にどうぞ。

参考出典

• Anthropic公式ドキュメント — Claude Code概要 (anthropic.com/claude-code)
• Anthropic公式ドキュメント — Claude Codeのデータ取扱いポリシー (anthropic.com)
• 経済産業省「DXレポート2.2」(meti.go.jp) — 製造業のDX現状整理
• 経済産業省「2024年版ものづくり白書」(meti.go.jp) — 人材不足と業務効率化の必要性
• 厚生労働省「人材開発支援助成金 事業展開等リスキリング支援コース」(mhlw.go.jp) — AI研修の助成制度

関連記事（自動）

• ▸ サプライチェーンリスク予測をClaude Codeで実装｜製造業向け5手順
• ▸ 製造品質検査レポートをClaude Codeで自動化｜不良分類と是正メモ
• ▸ 製造IoT異常検知をClaude Codeで実装｜保全ログ分析パイプラインの作り方
• ▸ 製造業の生産管理データを自動化｜大手工場が工数85%削減した実装事例