10年前に納めた装置の予備品を聞かれて、図面と部品表を探し回る——保守部品の問い合わせ対応が属人化する構造と、業務OSでそろえられる範囲【2026年】

10年前に納めた装置の予備品を聞かれて、図面と部品表を探し回る——保守部品の問い合わせ対応が属人化する構造と、業務OSでそろえられる範囲【2026年】
banner_01

この記事の要点

  • 保守部品の問い合わせに即答できないのは、情報・人・プロセスの3層が同時に欠けているためであり、担当者個人の能力の問題ではありません。
  • 予備品情報は「引渡」の時点で更新が止まります。据付時の現地調整や調達段階の代替品採用が部品表に戻らないことが最大の断点です。
  • 業務OS(AIエージェント基盤)がそろえられるのは、過去図面・部品表・改訂履歴の横断検索と、出典つきの候補提示、そして回答履歴の全社共有までです。
  • 在庫を持つか、いつまで供給を保証するかという事業判断は人が担います。ここを混同すると導入検討が止まります。
  • 着手の順番は「直近の問い合わせ数件を回答経路で棚卸し→情報の所在を一元化→検索と履歴を仕組みにする」。ツール選定はその後です。

「5年前に納めたラインの、あの搬送ユニットのベアリング、型番わかりますか」。装置メーカーのサービス窓口には、この種の問い合わせが日常的に届きます。厄介なのは、答えられる人が社内に数名しかいないことです。当時の設計者が退職していれば、案件フォルダを開き、出図データを追い、据付時の変更が反映されているかを確かめ、半日が消えます。顧客のラインは止まったままです。この記事では、なぜ保守部品の問い合わせ対応が個人に閉じるのかを構造として分解し、業務OS(個社別のAIエージェント基盤)でそろえられる範囲と、そろえられない範囲を切り分けます。

予備品の問い合わせに即答できないのは、なぜ担当者個人の問題ではないのか?

結論から述べます。即答できない原因は、部品情報が「案件を進めるための情報」としてだけ作られ、「10年後に引き当てるための情報」として設計されていないことにあります。担当者は与えられた道具の範囲で最善を尽くしています。

装置メーカーの保守部品(スペアパーツ)とは、納入済み装置の消耗・故障に備えて顧客が調達する交換部品を指します。ベアリング、シール、センサ、ベルト、電磁弁など、装置の稼働時間に応じて摩耗する部位が中心です。この情報がどこで失われるのかを、情報・人・プロセスの3層に分けて見ます。

予備品の問い合わせが特定個人に集中する3層構造情報層出荷時の部品表・図面・改訂履歴・メーカー型番が、案件フォルダ/紙/個人PCに分散している人 層当時の設計者・据付担当だけが「どの部品が消耗するか」を知っており、退職・異動で失われるプロセス層問い合わせが営業→設計→調達と口頭で転送され、回答の根拠も履歴も残らない
予備品の即答できなさは、情報・人・プロセスの3層が同時に欠けることで生じます

情報層:部品情報が「案件フォルダ」に閉じている

出図時の部品表は案件番号ごとのフォルダに保存されます。ところが問い合わせは装置単位・部位単位で来ます。「A社2021年3月納入の第2ラインの、上流側の吸着パッド」という粒度の質問に対し、案件フォルダという索引は答えを返せません。さらに、メーカー型番の廃番・後継品への切り替えは、部品表の側には書き戻されないのが通例です。

人層:消耗部位を知っているのが少数の経験者だけ

どの部品が先に傷むかという知識は、図面には書かれていません。試運転の立ち会いや、過去のクレーム対応を通じて個人の中に蓄積されます。この知識を持つのは設計者と据付担当のごく一部で、装置の設計寿命(10年以上のことも珍しくありません)より、担当者が同じ職場にいる期間のほうが短いという構造的なずれがあります。

プロセス層:回答の根拠と履歴が残らない

問い合わせは営業が受け、設計に口頭で回り、調達が型番を確認して営業に戻る、という経路をたどります。この過程で「なぜその型番と判断したか」は誰の手元にも残りません。半年後に同じ装置で同じ質問が来ても、同じ半日を繰り返すことになります。

装置ライフサイクルのどこで予備品情報が切れるのか?

切れる位置は明確です。引渡の直後、案件がクローズされた瞬間に部品情報の更新が止まります。

装置ライフサイクルと予備品情報が切れる位置設計部品表作成製造・調達型番確定・代替品採用据付・引渡現地調整で仕様変更保守(〜10年超)予備品の問い合わせここで情報が切れる案件クローズで更新が止まり、以後は個人の記憶が唯一の索引になる
予備品情報は「引渡」で更新が止まり、保守フェーズでは人の記憶だけが頼りになります

設計段階の部品表は、あくまで「これから作るもの」の一覧です。ところが実機は、調達段階の代替品採用と、据付段階の現地調整という2回の変形を受けます。納期都合で同等品に振り替えたセンサ、現地で追加した中間ストッパ——これらが部品表に書き戻される仕組みがなければ、保守フェーズで参照される図面は実機と一致しません。実機と合わない部品表は、間違った部品を届けるリスクを生みます。

この「工程をまたぐと情報が変形する」という問題は、部品表そのものの構造にも現れます。過去記事では次のように整理しました。

問題は二つあることではなく、二つの間の「変換」が構造化されず、人手の転記に依存していることです。

同じ製品なのに部品表が二つある——E-BOMとM-BOMの変換が人手に頼る構造と、業務OSでそろえられる範囲

予備品の問い合わせは、この変換の最終地点で起きます。設計から製造への変換が人手に依存していれば、その先の保守フェーズにも同じ歪みが引き継がれます。

業務OSでそろえられる範囲はどこまでか?

結論を先に述べます。業務OSがそろえられるのは、探す・引き当てる・根拠を示す・履歴を残すまでです。在庫の持ち方と供給保証の期限は、事業判断として人が決めます。

作業業務OSでそろう人が判断する
過去図面・部品表の検索装置名・納入年・部位の自然文から候補を提示候補が実機と一致するかの最終確認
型番の特定改訂履歴・代替品採用の記録を出典つきで提示廃番時の後継品選定と互換性の判断
消耗部位の推定過去の交換実績・クレーム記録からの類似提示顧客の稼働条件を踏まえた妥当性判断
回答履歴の共有誰が何を根拠に答えたかを全社で参照可能に顧客への約束(納期・価格・保証)
在庫・供給方針問い合わせ頻度の可視化何をいくつ持つか、いつまで供給するか
保守部品対応における、仕組みで担える範囲と人が担う範囲の切り分け

この切り分けは、技術問い合わせ全般に共通します。過去記事でも同じ線引きを置きました。

業務OS(AIエージェント基盤)がそろえられるのは、類似案件の検索・候補回答と出典の提示・履歴の全社共有までです。妥当性の最終判断と顧客への約束は人が担います。

「この仕様で大丈夫か」に即答できる人が限られる——技術問い合わせ対応が属人化する構造と、業務OSでそろえられる範囲

入口として現実的なのは、過去図面の横断検索です。図面バンク(株式会社New Innovationsが提供するクラウド図面管理サービス。ファースト・オートメーションのグループ会社にあたります)は、AIによる類似図面検索を備えており、公開されている導入事例では、この検索機能を案件管理に転用した使い方が報告されています(湖国精工の事例/2025年9月13日プレスリリース)。また、三重精機の事例では見積の属人化と紙保管の解消が導入目的として挙げられています(2025年8月プレスリリース)。いずれも保守部品そのものの事例ではありませんが、「過去の図面を引き当てる」という同じ動作が業務のどこに効くかを示す一次情報です。

「ウチは台数が少ないから覚えている」は成り立つのか?

成り立つ場合があります。年間の納入台数が数台で、設計者が定年まで在籍するなら、記憶は十分に機能します。この記事はその状態を否定しません。

ただし、その状態が崩れる条件は3つあり、いずれも予告なく訪れます。第一に、覚えている本人の退職・異動。第二に、装置の設計変更が重なり「同じ型式でも中身が違う」個体が増えること。第三に、顧客側の担当者が代わり、口頭で通じていた前提が通じなくなることです。

もう一つ、よくある反論に「引き継ぎ資料を作れば済む」があります。これが機能しにくい理由は、別の業務でも同じ形で観察されています。

「引き継ぎ資料を作る」対応が機能しにくいのは、そこに書かれるのが操作手順であって、セルに埋まった業務ルールの意図ではないからです。

作った人しか直せないExcel帳票——数式とマクロが属人ブラックボックス化する構造と、様式を残したまま引き継ぐ順番

予備品も同じです。資料に残せるのは型番の一覧であって、「なぜこの部品が先に傷むのか」という判断の根拠ではありません。根拠を残す形にしない限り、資料は作った直後から古くなります。

負荷の目安を一つ置きます。問い合わせ1件あたりの調査時間を平均2時間、月あたりの件数を10件と仮定すると、年間で約240時間が調査だけに費やされる計算になります(編集部による前提付きの概算試算であり、実測値ではありません)。前提が半分でも年間120時間です。この時間が設計者の稼働から差し引かれている点が、見えにくいコストです。

自己診断:5つのチェック

次の5項目のうち、「いいえ」が2つ以上あれば、保守部品対応は個人に依存した状態にあります。

  1. 納入から5年以上経った装置について、担当者以外が部品表と改訂履歴にたどり着けますか。
  2. 据付時の現地変更は、出荷時の部品表に書き戻されていますか。
  3. 調達段階で採用した代替品の型番は、装置単位で追えますか。
  4. 過去1年の予備品問い合わせについて、誰が何を根拠に回答したかが残っていますか。
  5. 問い合わせの多い部位を、装置横断で集計できますか。

FAQ

保守部品の情報を整理するのに、どこから手をつけるべきですか?

直近3か月の問い合わせを5件だけ選び、回答までの経路(誰に聞き、どこを見たか)を書き出すところからです。全案件の遡及整理は工数が読めず、途中で止まります。5件の経路が重なる場所が、最初に一元化すべき情報です。

古い装置の図面が紙しかない場合はどうなりますか?

紙図面はスキャンした時点では検索対象になりません。図面内の文字・記号を読み取って索引化する工程が必要です。全量を一度に電子化するより、問い合わせが実際に来た装置から順に索引化するほうが、費用と効果の対応を確認しながら進められます。

AIに部品の型番を答えさせて、間違っていたら誰の責任になりますか?

顧客への回答責任は人に残ります。だからこそ、業務OS側に求められるのは「答えを出すこと」ではなく「根拠となる図面・改訂記録を出典として一緒に提示すること」です。出典が示されない回答は、確認工数を減らしません。

次のアクション

まずは直近の問い合わせ5件を、上の自己診断5項目で仕分けしてください。そのうえで、情報がどこに散っているかを外部の目で棚卸ししたい場合は、業務診断をご利用ください。現状の情報の置き場所と回答経路を整理し、どこから着手すると効果が見えやすいかを一緒に確認します。

保守部品対応の業務診断を申し込む

次に読むべき記事

出典

※本文中の時間換算は、記載した前提に基づく編集部の概算試算であり、特定企業の実測値ではありません。

banner_01
記事一覧
広告 広告

関連記事

の最新情報をお届け

厳選した記事を定期配信
キャンペーン情報などをいち早く確認