製造業の基礎知識自己保持回路・インターロック・タイマ駆動——PLCシーケンス制御の3つの基本回路パターンを図解で読み解く【2026年版】
「この仕様で大丈夫か」に即答できる人が限られる——技術問い合わせ対応が属人化する構造と、業務OSでそろえられる範囲
「この材質でこの使い方をして大丈夫でしょうか」——営業や顧客からのこうした技術的な問い合わせに、即答できる人が部署に一人か二人しかいない。その人が会議中や出張中だと回答が数日止まり、退職・異動の話が出るたびに「あの人がいなくなったら誰が答えるのか」と不安になる。多くの製造業で、技術問い合わせへの回答は特定のベテランの記憶に支えられています。本記事では、技術問い合わせ対応が属人化する構造を業務の流れに分解し、業務OS（設計OS・品質OS）でどこまでそろえられるのか、人が握り続ける判断はどこかを、図解と比較表で整理します。
もくじ
この記事の要点
- 技術問い合わせ対応の属人化とは、顧客・営業からの仕様に関する質問に答えられる人が特定の担当者に偏り、その人の記憶と個人ファイルに回答品質が依存している状態を指します。
- 属人化の主因は担当者の怠慢ではなく、過去の類似案件・設計根拠・不具合履歴が横断検索できず、「知っている人に聞く」以外の手段がない業務構造にあります。
- 技術問い合わせ1件の対応時間の多くは、回答そのものより「過去案件を探す・設計意図を確認する・不具合履歴を照合する」という情報をそろえる工程に費やされます。
- 業務OS（AIエージェント基盤）がそろえられるのは、類似案件の検索・候補回答と出典の提示・履歴の全社共有までです。妥当性の最終判断と顧客への約束は人が担います。
- まず着手すべきは、直近の技術問い合わせ数件を「担当者以外でも答えられたか」で仕分けし、答えが個人の頭にしかない領域を特定することです。
技術問い合わせ対応の属人化とは？
技術問い合わせ対応の属人化とは、顧客や営業から寄せられる製品仕様・使用条件・過去実績に関する質問に対して、答えられる人が特定の担当者に偏っている状態を指します。回答の根拠が図面や記録として組織に残っておらず、ベテランの記憶と個人フォルダに蓄えられているため、その人が対応できなければ回答が止まります。
ここでいう技術問い合わせとは、「この寸法公差で組み付くか」「別の材質に変えても強度は足りるか」「過去に似た仕様で不具合はなかったか」といった、設計根拠や実績にさかのぼって初めて答えられる質問です。カタログを見れば分かる質問とは違い、なぜその設計にしたのかという意図や、過去のトラブルの経緯を参照する必要があります。だからこそ、その情報を握る人に問い合わせが集中します。
この状態が続くと、回答スピードが担当者の稼働に左右されるだけでなく、回答品質そのものが特定の個人に紐づきます。担当者が異動・退職すれば、積み上げた判断の勘所が組織から失われ、後任は同じ質問に一から向き合うことになります。
なぜ「この仕様で大丈夫か」に答えられる人が限られるのか？
答えられる人が限られる直接の原因は、回答に必要な情報が一か所にそろっておらず、それらを頭の中で結びつけられる人が少数だからです。設計図面はPLMに、不具合報告は品質部門の台帳に、過去の見積や仕様のやり取りは営業の個人メールに、というように、一つの質問に答えるための材料が複数のシステムと個人環境に分散しています。
問い合わせ対応の何に時間がかかっているのか？
技術問い合わせ1件にかかる時間の多くは、回答文を書く作業ではなく、回答の根拠を集める工程に費やされます。過去の類似案件を探し、当時なぜその仕様にしたのかという設計意図を確認し、同じ系列の製品で不具合やクレームがなかったかを照合する。この「情報をそろえる」段階が対応時間の大半を占め、担当者が本来発揮すべき判断は最後のわずかな時間に押し込まれます。次の図は、その時間配分のイメージです。
既存のシステムでは、なぜ答えがそろわないのか？
ERPやPLMを導入していても技術問い合わせの属人化が解消しないのは、これらが情報の保管と参照を担う仕組みであって、「問い合わせに答える」という業務そのものを進める仕組みではないからです。図面やBOMはPLMに格納されていても、「この質問に関係する図面はどれか」を横断的に見つけ出し、設計根拠や不具合履歴と結びつけて回答候補を組み立てる工程は、依然として人の頭に依存しています。
過去記事でも、このシステムの性格の違いを次のように整理しました。
ERPは「お金とモノの記録台帳」、PLMは「図面とBOMの保管庫」であり、いずれも「業務そのもの」を実行する仕組みではない。
品質OSとは——FMEA・是正処置・市場品質を一気通貫させる構造
加えて、回答の勘所が特定の人に集中している状態そのものが、退職・異動のたびに顕在化するリスクとして残ります。この点は、装置メーカーの新人教育を扱った記事でも指摘しました。
ベテラン設計者が「どこに何があるか」の暗黙知を握り、退職リスクが顕在化しています
装置メーカーの新人設計者教育——設計OSが「暗黙知の継承装置」になる構造
業務OSは技術問い合わせ対応をどこまでそろえられるのか？
業務OSがそろえられるのは、回答の材料を集めて候補を提示するところまでです。業務OSとは、ERPやPLMの上に乗り、日々の業務そのものをAIエージェントで進める業務基盤を指します。技術問い合わせに当てはめると、過去の類似案件・設計根拠・不具合履歴を横断的に探し、出典つきの回答候補を組み立てる工程を担います。一方で、その候補が今回の条件に本当に適合するかの最終判断と、顧客への約束は人が握り続けます。
この「そろえる」対象がどれほど広いかは、設計者の日常業務を見ると分かります。過去記事では、設計者の時間の使われ方を次のように示しました。
設計者が一日のうち4割を、図面を探したり、部品表をメンテしたり、設計変更を関係部署に伝えたりすることに使っている
業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体
AIエージェントに任せられる範囲はどこか？
AIエージェントに任せられるのは、定型的で検索・集約・下書きに落とし込める工程です。具体的には、問い合わせ文から関係しそうな製品・図面・案件を絞り込む一次検索、過去の類似仕様や不具合履歴の照合、回答候補と参照元の提示、誰が類似案件を担当したかの手がかり提示までが該当します。いずれも所要時間の大半を占めながら、判断そのものではない工程です。
人が握り続ける判断はどこか？
人が握り続けるのは、そろえられた材料をもとに「今回の条件で本当に問題ないか」を見極める妥当性判断と、それを顧客に約束する意思決定です。過去に似た事例があっても、使用環境や要求品質が少しでも異なれば結論は変わり、この最終判断を業務OSに委ねることはできません。業務OSの役割は、判断に必要な材料を欠けなくそろえ、判断者が短時間で確度の高い結論を出せる状態をつくることにあります。次の比較表は、技術問い合わせを構成する業務ごとに、業務基盤に載せられる範囲と人が担う判断を整理したものです。
| 技術問い合わせの構成業務 | 属人運用（現状） | 業務基盤に載せられる範囲 | 人が担い続ける判断 |
|---|---|---|---|
| 類似案件・過去仕様の探索 | 担当者の記憶と個人フォルダ頼み | 製品・図面・案件を横断した一次検索 | どの案件を今回の参照とみなすか |
| 設計根拠・仕様意図の確認 | 設計者に都度口頭で確認 | 設計変更履歴・根拠メモの提示 | 意図が今回の条件にも当てはまるか |
| 不具合・クレーム履歴の照合 | 品質台帳を手作業で検索 | 関連する不具合・是正記録の抽出 | 再発リスクをどこまで見込むか |
| 回答候補の作成 | ベテランが一から文面を作成 | 出典つき回答ドラフトの生成 | 顧客への表現・約束の範囲 |
| 回答の記録と共有 | 個人メールに残り全社に届かない | 案件に紐づく回答・根拠の全社蓄積 | どこまでを標準回答として残すか |
この「材料をそろえる層」と「業務を実行する層」を分ける発想は、調達部門の課題を扱った記事でも共通していました。定型の集計は仕組みに寄せ、最終査定は人が握るという切り分けです。
自己診断：あなたの現場はどのくらい属人化しているか
次の5項目のうち、3つ以上に「はい」がつく場合、技術問い合わせ対応は仕組みではなく個人に支えられている可能性が高い状態です。
- 顧客・営業からの技術的な問い合わせに、即答できる人が部署に一人か二人に偏っている
- その担当者が不在だと、回答が翌日以降に持ち越されることがある
- 回答の根拠となった過去案件や設計意図は、担当者に聞かないとたどれない
- 同じような問い合わせに、担当者ごとに違う回答が返ることがある
- 過去に回答した内容が、次の担当者に引き継がれる形で残っていない
「ベテランに聞けば済む」「ChatGPTで足りる」のではないか？
「答えられるベテランがいるのだから、聞けば済む」という反論はよく聞きます。確かに回答の質は高いかもしれませんが、それは回答スピードと再現性を一人の稼働と在籍に賭けている状態です。その人が休んだ日、退職した後に同じ質問が来たとき、組織は同じ水準で答えられません。属人化は平時には問題に見えず、人が抜けた瞬間にコストが表面化します。
「汎用の生成AIで足りるのではないか」という見方もあります。しかし汎用のチャットツールは、自社の図面・不具合履歴・過去の仕様のやり取りといった社内固有の情報を参照できません。技術問い合わせの答えは、その社内固有の実績にさかのぼって初めて出ます。必要なのは汎用の言語能力ではなく、自社のデータを横断して根拠つきの候補をそろえる仕組みです。
よくある質問（FAQ）
技術問い合わせ対応の属人化は、何から手をつければよいですか？
直近の技術問い合わせを数件取り上げ、「担当者以外でも同じ回答にたどり着けたか」で仕分けることから始めます。答えが個人の記憶にしかない領域が特定できれば、そこが業務基盤に載せるべき情報の候補になります。全社一斉ではなく、一つの製品群や一種類の問い合わせから小さく始めるのが現実的です。
回答をAIに任せると、誤った内容を顧客に伝えるリスクはありませんか？
業務OSの役割は回答候補と出典をそろえるところまでで、顧客への最終回答は担当者が妥当性を確認して行う前提です。候補には必ず参照元を添え、担当者が根拠を追える状態にします。判断と約束を人が握る限り、汎用ツールに丸投げするより誤りの検証はしやすくなります。
既存のPLMや文書管理システムがあれば十分ではないですか？
PLMや文書管理は情報の保管と参照に強みがありますが、「一つの問い合わせに関係する情報を横断して集め、回答候補を組み立てる」工程は担いません。そこが人手に残るために属人化が続きます。業務OSは既存システムの置き換えではなく、その上で回答を組み立てる業務そのものを支える層として機能します。
次のアクション
技術問い合わせ対応が「人の問題」なのか「情報設計の問題」なのかは、直近の数件を分解すれば見えてきます。私たちは、実際の問い合わせを題材に、答えがどこにあり、何をそろえれば担当者以外でも回答できるかを棚卸しする無料の業務診断を提供しています。設計・品質・営業技術の関係者が同席し、30分で自社の属人化ポイントを言語化するところから始められます。
出典
- 経済産業省・厚生労働省・文部科学省「2024年版ものづくり白書」（製造業の技能継承・人材課題に関する記述）
- ISO 9001:2015 箇条8.2.1「顧客とのコミュニケーション」（製品・サービスに関する問合せ対応の要求事項）
- 本メディアによる製造業の業務観察（技術問い合わせ対応の業務分解）。図表は業務構造を説明する参考図であり、実測値ではありません。
次に読みたい関連記事
