製造業 アフターサービス AIを導入しても、CRMの会話だけを学習させたチャットボットでは、正しい技術回答や部品見積にはつながりません。必要なのは、顧客と製造番号を起点に、納入時の構成、現在のサービスBOM、設計変更、保証・契約、在庫・納期、価格承認までをたどれる仕組みです。本稿では、タイ・ASEANの製造業が90日で小さく検証する方法を解説します。
製造業 アフターサービス AIで変わったこと――SiemensとSalesforceの発表をどう読むか
SiemensとSalesforceは2026年9月15日、TeamcenterとAgentforceの連携を深め、産業向け営業・サービスにAIを組み込む方針を発表しました。発表で示されたのは、単なる会話の自動化ではありません。従来はエンジニアリング部門へ戻していた質問への回答、初回訪問前の製造番号に適合する交換部品の特定、技術的に有効で製造可能なアップグレードだけを対象にした見積、顧客自身による正しい部品の検索・注文など、製品構成の正しさが結果を左右する業務です。
Siemensの発表は、複雑な産業プロセスを数週間から数時間へ短縮できる可能性を述べています。また、同社が引用する業界分析として、アフターマーケット売上は新規設備販売より約6倍速く成長し、利益率は約4倍と紹介しています。ただし、これはSiemensの発表内で引用された分析であり、あらゆる企業に当てはまる監査済みの普遍的ベンチマークではありません。自社の投資判断では、問い合わせ件数、再訪問、誤出荷、見積手戻りなど自社データを使う必要があります。
Salesforceの同日発表は、AgentforceとTeamcenter Service Lifecycle Management（SLM）を組み合わせ、営業・サービス・顧客接点にエンジニアリング水準の回答を届ける構想を確認しています。同じ発表には、Siemensが問い合わせ対応と見込み客判定に2つのAIエージェントを使い、月2,500件超の未評価リード、18,000人の営業担当者、132か国からのインバウンドリード100%への対応を扱う例もあります。これは営業開発の規模を示す例であり、製造番号別の部品適合性やサービス回答の正確性を証明するものではありません。営業の自動応答と、構成に依存する技術判断は分けて評価すべきです。
McKinseyも2026年5月の分析で、個別企業の例として、AIを使ったスケジューリングにより技術者の対応能力が40%増え残業が6%減った水処理会社、1作業当たりの労働時間を15%、使用部品を18%削減したエンジンOEM、自動請求で手作業の請求時間を80%削減した例、サービス・コパイロットと初回修理完了率10%向上の関連を報告しています。いずれも特定組織や分析に基づく事例であり、TOMAS TECHの導入効果や自社の保証値ではありません。
重要なのは「AIが賢くなった」ことではなく、CRMの案件・会話と、PLM/SLMが持つ製品構成・設計根拠を、権限と証跡を保ったまま結び付ける実装が現実的になってきたことです。
なぜ汎用チャットボットやCRM単独では技術問い合わせAIにならないのか
CRMには、顧客名、販売店、案件、問い合わせ文、担当者、契約、過去の会話が蓄積されます。しかし「その製造番号の装置に、どの部品が現在適合するか」をCRMの会話だけから確定するのは危険です。同じ型式でも、製造時期、工場オプション、現地改造、設計変更、過去の修理によって構成が異なるからです。古いメールの回答が、別の改訂や別の顧客構成に対するものかもしれません。
一方、PLM/SLMや同等の構成管理基盤だけでは、問い合わせをした顧客、販売チャネル、保証契約、サービス水準、地域、価格条件、未決ケースの文脈が不足します。製品の技術的な正しさと、顧客に対する商取引上の正しさは、別の情報領域です。どちらか一方を「すべての正本」にしようとすると、現場で必要な判断材料が欠けます。
汎用チャットボットが失敗しやすい典型例は次の通りです。
- 型式だけで検索し、製造番号ごとのオプションや改造履歴を無視する。
- 最新の設計図を引用しても、既設機にその改訂が適用済みかを確認しない。
- 代替部品を候補として示すが、互換条件、必要な同時交換、認証、保証への影響を確認しない。
- 在庫画面に数量があっても、引当、地域倉庫、輸送、リードタイムを確認せず納期を約束する。
- 類似する過去回答を再利用し、出典、版、承認者、適用対象を残さない。
- タイ語の現場用語、日本語の設計用語、英語の部品名称が一致せず、別部品を同一視する。
したがって、AIモデル自体に「工学的正確性を保証させる」という考え方は採りません。正確性を支えるのは、根拠データへのグラウンディング、アクセス制御、決定論的な適合ルール、出典表示、バージョン管理、承認ゲート、監査ログです。生成AIは、必要な根拠を集め、説明し、下書きを作る層として位置付けます。
この考え方は、汎用的なAIエージェント導入の設計原則とも共通します。ただしアフターサービスでは、会話履歴より先に製造番号と実機構成を固定する点が特に重要です。また、工場や設備の状態表現については製造業のデジタルツイン解説も参考になります。
信頼できる回答と見積を作るデータ構成――8段階の根拠チェーン
アフターサービスAIの画面を考える前に、回答がどの根拠を通って作られるかを定義します。最低限のチェーンは次の8段階です。
- 顧客・製造番号：問い合わせ元、納入先、設備ID、製造番号、販売店・代理店を特定する。
- 納入構成・as-maintained BOM：納入時のas-builtだけでなく、保全後の現在構成を取得する。
- 適用可能な設計改訂：製造時点、変更通知、改造キット、適用開始・終了条件を照合する。
- 互換部品・アップグレード：正規スペア、代替、後継、同時交換品、適用条件を規則で絞る。
- 保証・契約：保証期間、保守契約、無償・有償、販売店責任、例外承認を確認する。
- 在庫・供給・リードタイム：利用可能在庫、引当、調達、製造可能性、輸送前提を照会する。
- 価格・承認：価格表、通貨、割引権限、税・運賃の扱い、有効期限、承認者を適用する。
- 監査ログ：参照したデータ、版、ルール、AI出力、人の修正、承認、外部送信を記録する。
この順番には意味があります。価格が登録されていても、その部品が対象機に適合しなければ見積対象にできません。技術的に適合しても、供給終了や製造不可なら納期を確約できません。供給可能でも、保証判定や割引承認が未了なら、顧客への確定条件にはできません。検索結果を一つ表示するだけではなく、各段階で「確認済み」「条件付き」「不明」「承認待ち」を区別します。
Teamcenter SLMの製品情報では、Service BOMとエンジニアリングの接続、物理構成、as-built/as-maintained、サービス履歴、資産状態、サービス計画を一つのサービス知識源として扱う考え方が示されています。Spring 2026の製品リリースでは、Service BOM部品への故障コード割当、代替品から対応するスペア定義を作る機能、システム生成フラグとトレーサビリティ、EBOMからのService BOM作成、部品移動追跡、Salesforce連携などが説明されています。その特定機能では再帰ロジックによる「100% spare coverage」と表現されていますが、製品機能の説明であり、企業データ全体や業務回答の正確性が100%になるという意味ではありません。
AIが参照する「回答パッケージ」を固定する
各回答・見積下書きに、本文だけでなく次の構造化情報を付けます。
| 項目 | 必須内容 | 不明な場合の動作 |
|---|---|---|
| 対象 | 顧客、拠点、製造番号、ケース番号 | 対象を確認するまで一般情報のみ |
| 構成根拠 | as-maintained BOMの版と取得時刻 | 技術回答を保留し構成確認へ |
| 設計根拠 | 図面、変更通知、サービス指示の版 | エンジニアリングへ引き継ぐ |
| 適合判定 | 部品・アップグレード、ルール、条件 | 候補としても外部提示しない |
| 商務根拠 | 契約、保証、価格表、承認状態 | 価格・保証は未確定と明示 |
| 供給根拠 | 在庫、引当、リードタイム、時点 | 納期を約束しない |
| 出力状態 | 回答、下書き、承認済み、実行済み | 状態を外部表示とログに反映 |
| 出典 | URLまたはレコードID、版、取得時刻 | 出典のない主張を抑止 |
文書検索だけでなく、BOM照合、契約判定、価格計算、承認権限は決定論的な処理に寄せます。生成AIには、複数システムの結果を人が読める説明へまとめる仕事を任せます。これにより「流暢だが根拠のない回答」と「規則上は正しいが説明できない結果」の両方を減らせます。
製造業営業AI・技術問い合わせAIのユースケース優先順位
すべてを一度に自動化せず、入力の明確さ、誤りの影響、必要なデータの成熟度で優先順位を付けます。
| ユースケース | AIが支援する内容 | 必要な根拠 | PoCでの推奨権限 | 主な停止条件 |
|---|---|---|---|---|
| 技術問い合わせ | 質問分類、構成検索、回答案、出典提示 | 製造番号、as-maintained、設計版、サービス履歴 | 回答案まで | 構成不明、安全影響、根拠競合 |
| スペア選定 | 適合候補、代替、同時交換品の提示 | Service BOM、代替規則、変更通知、在庫 | 推奨まで | 製番不明、代替未承認、適用条件不足 |
| アップグレード見積 | 技術的に成立する構成と見積下書き | 現在構成、オプション規則、製造可能性、価格 | 下書きまで | 技術審査・割引・納期承認待ち |
| サービス派遣 | 必要技能、想定部品、作業指示、候補日時 | 故障コード、履歴、技能、在庫、地域 | 作業指示案まで | 安全、現場条件不明、契約範囲外 |
| 顧客セルフサービス | 製番に応じた文書・部品候補・ケース受付 | 顧客権限、対象資産、公開可否、適合規則 | 検索・注文依頼まで | 他社データ、輸出・地域制限、要承認条件 |
最初のPoCには、問い合わせ件数が十分にあり、製造番号が取得でき、正解を後から判定できる一つの製品群を選びます。たとえば「特定シリーズの消耗部品選定と見積下書き」のように範囲を区切ります。安全に影響する診断、保証例外、複雑な改造、供給終了品は初期対象から外すか、必ず専門家へ送ります。
提案書や回答文面の生成そのものを改善したい場合は、AIによる提案書・文書生成の考え方も使えます。ただし、文章を速く作れることと、部品が対象機に適合することは別問題です。適合判定の根拠を先に完成させます。
「回答・下書き・実行」を分ける人間とAIの権限設計
PoCで最も危険なのは、AIエージェントに見積、納期回答、発注、技術者派遣まで一括で任せることです。権限は次の3段階に分離します。
レベル1：回答・推奨
AIは根拠を検索し、候補を順位付けし、回答案と出典を示します。人は製造番号、構成、適用条件を確認してから顧客に回答します。低リスクの一般情報でも、出典と版を表示し、確定情報と一般的説明を分けます。
レベル2：見積・作業指示の下書き
AIは部品行、数量、前提、除外事項、保証候補、作業内容を構造化して下書きします。ただし、価格、割引、通貨、納期、保証、代替、作業安全条件は担当権限者が承認します。承認前の文書には「DRAFT」を明示し、外部送信を制限します。
レベル3：発注・派遣・外部確約の実行
注文登録、在庫引当、技術者派遣、顧客への納期確約、保証認定はシステム上の実行です。PoCでは自動実行させず、承認済みデータを人が確認して実行するか、既存ワークフローの承認ゲートを通します。将来一部を自動化する場合も、対象、金額、リスク、例外、取消方法を限定します。
商務条件、安全に影響する技術指示、保証判断、代替品、外部への確約には、PoC期間中必ず人の承認を置きます。承認は単なる「OK」ボタンではなく、誰が、どの版の根拠を見て、何を承認したかを残します。AI出力を人が修正した場合は、修正前後と理由も記録し、将来のルール改善に使います。
アクセス制御も回答単位で考えます。代理店が見られる価格と社内原価は異なり、顧客が見られる設計文書とサービス技術者向け文書も異なります。検索結果を生成AIへ渡す前に権限で絞り、プロンプトで「表示しない」と頼むだけの設計にはしません。
タイ・ASEANで製造業 アフターサービス AIを実装する際の論点
タイ・ASEANでは、モデル性能よりもデータの所在と運用責任が難所になりやすいです。日本本社のPLM、タイ法人のERP、地域CRM、代理店の表計算、現場サービス担当者のメールに情報が分散しているケースがあります。一つの新システムへ全移行してから始める必要はありませんが、PoC対象製品についてどの項目をどこから取得し、誰が誤りを直すかは決める必要があります。
日本語・タイ語・英語の用語差をマスタ化する
同じ部品が、日本語の設計名称、英語の品目説明、タイ語の現場俗称、旧部品番号で呼ばれることがあります。翻訳モデルに任せるだけではなく、正規部品番号を中心に、承認済み別名、禁止語、旧番号、単位、略語を辞書として管理します。曖昧な語はAIが一つに決めず、「候補AとBのどちらか」と確認質問を返します。回答言語が変わっても製番・部品番号・改訂は同一レコードを参照させます。
代理店・販売店データを含めた責任分界を決める
直接販売だけでなく、代理店やサービスパートナーが問い合わせを受ける場合、最終顧客、設置場所、製造番号、契約主体がCRM上で分かれていることがあります。誰が構成を更新できるか、誰が価格を見られるか、どのチャネルが保証申請を出せるかを定義します。共有データは最小限にし、他の代理店や顧客の情報が検索に混ざらないようテナント・行・属性レベルの制御を設けます。
古い設備の製造番号・BOM欠損を正常な例外として扱う
旧設備では、紙図面、現場改造、銘板の読取不能、移行漏れにより、完全なas-maintained BOMがないことがあります。欠損をAIに推測させるのではなく、写真、銘板、既知の部品、過去報告から「構成確認ケース」を作り、確定した結果を構成管理へ戻します。不明状態を明示できることが、安全なAIの要件です。構成信頼度が閾値未満なら見積下書きへ進めない制御を置きますが、閾値そのものは製品リスクに応じてPoCで決めます。
複数ERP・CRM・PLMを無理に一つに見せない
国・事業部・買収会社ごとにシステムが異なる場合、まず共通IDと最小データ契約を定義します。顧客ID、資産ID、製造番号、部品番号、改訂、ケース番号、契約番号を対応付け、取得元と更新時刻を保持します。リアルタイム連携が不要な項目まで同期せず、見積時に最新性が必要な在庫・価格は都度照会し、構成履歴は版を固定するなど、用途ごとに方式を選びます。
90日PoC――一つの意思決定フローを根拠付きで通す
PoCの目的は、派手なデモを作ることではありません。「特定製品の技術問い合わせを受け、構成に適合する部品を選び、根拠付き見積下書きを人に渡す」という一つの意思決定フローを、再現可能な品質で通すことです。90日を4段階に分けます。
1〜15日目：対象と正解を定義する
- 対象製品、国、問い合わせ種別、利用者、除外条件を一枚で合意する。
- 過去ケースから評価用データを抽出し、構成・正解部品・回答・エスカレーション理由を専門家が確認する。
- データ源、所有者、更新頻度、アクセス権、保持する版を登録する。
- 現状の初回応答時間、見積手戻り、技術部門へのエスカレーション率を測れる状態にする。
16〜35日目：根拠チェーンを接続する
- CRMの顧客・ケースと、PLM/SLM等の製造番号・as-maintained構成を対応付ける。
- 適合規則、設計変更、保証・契約、在庫・価格への読取専用接続を作る。
- 出典、版、取得時刻、未確認項目を回答パッケージに保存する。
- 日本語・タイ語・英語の用語辞書と、曖昧時の確認質問を実装する。
36〜60日目：回答と見積下書きをシャドー運用する
- AIの回答を顧客へ送らず、担当者の実回答と並べて評価する。
- 誤った構成、根拠のない主張、古い版、権限外情報、過剰な納期表現を分類する。
- 不確実時の停止、専門家への引継ぎ、承認ログをテストする。
- 対象ケースだけ、AIの見積下書きを人が修正して利用する。
61〜90日目：限定本番と受入判定を行う
- 承認済み利用者と対象製品に限定し、レベル1とレベル2だけを本番運用する。
- 毎週、失敗ケース、修正理由、データ欠損、アクセス違反をレビューする。
- 受入基準を満たしたか、継続改善が必要か、対象拡大を止めるかを判定する。
- 発注・派遣の自動実行はPoCの合格条件に含めない。
PoCの受入指標
ベンダー事例の改善率を目標値としてコピーせず、次のプロセス指標に自社の合格値を設定します。
| 指標 | 定義 | 確認方法 |
|---|---|---|
| 根拠引用率 | 外部へ使う主張のうち版付き出典を持つ割合 | 回答ログをサンプル監査 |
| 正しい構成取得率 | 正解データと一致する製造番号別構成を取得した割合 | 専門家承認済み評価セットと比較 |
| 根拠なし回答率 | 出典や規則で支えられない回答の割合 | 全件またはリスク別サンプル確認 |
| 見積手戻り率 | 構成・部品・条件の誤りで再作成となった割合 | 見積版履歴と理由コードを集計 |
| 初回応答時間 | 受付から根拠付き一次回答までの時間 | ケース時刻を比較 |
| 引継ぎ完全性 | 対象、根拠、未決事項、推奨先が揃う割合 | エスカレーション様式を監査 |
| 技術部門エスカレーション率 | 対象ケースのうち技術確認が必要だった割合 | 理由別に推移を確認 |
「根拠なし回答率が低い」だけでは不十分です。AIがほぼすべてを人に転送すれば、誤答は減っても価値は出ません。正しい構成取得率、初回応答時間、エスカレーション率を一緒に見ます。逆に自動回答率だけを追うと、危険な断定を促します。
費用とROI――製品ライセンスと実装総額を混同しない
Salesforce Manufacturing Cloudの公開ページには、2026年9月16日時点で、Manufacturing Cloud Sales EnterpriseおよびService EnterpriseがUSD 275／ユーザー／月、Sales and Service UnlimitedがUSD 475／ユーザー／月、Agentforce 1 for SalesおよびServiceがUSD 700／ユーザー／月と掲載され、年次請求とされています。価格は参考情報であり変更される可能性があります。THBへ換算せず、また総導入費として扱わないでください。
実装総額には、ライセンス以外に、製品構成データの整備、ID対応、連携、アクセス制御、用語辞書、評価セット、テスト、変更管理、利用教育、監視、運用保守が含まれます。既存PLM/SLMの成熟度、古い設備の欠損、複数拠点、代理店範囲により工数は変わります。製品価格を人数倍しただけでは、投資額も効果も判断できません。
200時間／年の説明用計算
以下はベンチマークではなく、計算方法を示す仮定です。
- サービス問い合わせ：年間1,000件
- 現在の一次切り分け：1件35分
- 対象ケースの目標：1件15分
- AI支援の対象にできる割合：60%
計算は、(35分 − 15分) × 1,000件 × 60% = 12,000分 = 200時間／年です。ここに金額を掛けるには、自社の福利厚生・間接費を含む負荷後人件費が必要です。ユーザーからその単価が提示されていないため、本稿では金額換算しません。また、200時間がそのまま人員削減になるとは限らず、回答速度、案件処理能力、技術者の集中時間へ振り替わる可能性があります。
ROIには時間削減だけでなく、誤部品出荷の回避、再訪問の削減、見積手戻りの削減、設備停止時間の短縮、エンジニアリング部門への割込み削減も含めます。ただし、金額は自社の発生件数と単価で計算し、外部事例をそのまま基準ケースにしません。
McKinseyの2025年3月の分析では、50超の産業組織を15年間分析し、サービス重視企業のTSRが製品重視企業の1.7倍だったと報告していますが、因果関係を意味するものではありません。同じ記事は、水技術OEMが45,000顧客からUSD 350 million超のアフターマーケット見込み案件を創出し、そのうち8,000件がホワイトスペースだった例や、Ascendumが13,000超の文書を使い、初回接触解決率が50%増加し、通常30分のトラブルシューティングが1分未満になった例も紹介しています。これらも特定事例であり、自社の期待値にはせず、どのデータと業務変更が効果を生んだかを検討する材料に留めます。
ベンダー・製品選定チェックリスト
デモの流暢さではなく、自社の製造番号と例外ケースで評価します。
| 評価領域 | ベンダーに確認する質問 | 提出を求める証拠 |
|---|---|---|
| 構成管理 | as-builtとas-maintained、現地改造をどう区別するか | 製番別の取得結果と版履歴 |
| 適合判定 | 代替・後継・同時交換・設計変更を何で制御するか | ルール、出典、失敗時の停止画面 |
| CRM連携 | 顧客、代理店、契約、ケースを構成へどう結ぶか | ID対応とデータフロー |
| ERP連携 | 在庫、引当、価格、納期をいつ照会するか | 時点情報、再照会、エラー処理 |
| AI制御 | 根拠なし回答、古い版、競合する出典をどう扱うか | 評価結果、拒否例、監査ログ |
| 権限 | 社内、代理店、顧客の閲覧範囲をどこで絞るか | ロール別の検索・回答テスト |
| 承認 | 商務、安全、保証、代替、外部確約を誰が承認するか | ワークフローと職務分離 |
| 多言語 | 日本語・タイ語・英語の部品語彙をどう固定するか | 用語辞書、曖昧語の確認動作 |
| 運用 | データ欠損、モデル更新、ルール変更を誰が監視するか | 責任分担、変更・ロールバック手順 |
| 費用 | ライセンス以外に何が必要か | 前提付き内訳、除外、継続費用 |
短いデモ課題として、あえてBOMが欠けた旧設備、設計変更前後で部品が異なる設備、保証境界のケース、在庫はあるが代替承認がないケースを渡します。正答を返すことだけでなく、「答えられないため止まる」「必要な確認を人へ渡す」挙動を評価してください。
FAQ：製造業 アフターサービス AIの導入判断
製造業 営業 AIとアフターサービスAIは同じ基盤で作れますか？
顧客・案件・会話というCRM基盤は共有できますが、判断根拠は異なります。リード対応は顧客意図や案件確度が中心で、サービスは製造番号別構成、設計改訂、互換性、保証、履歴が中心です。同じAI画面を使う場合でも、サービス回答にはPLM/SLMまたは同等の維持された構成源を接続し、別の評価セットと承認規則を設けます。Salesforce発表の月2,500件超、18,000人、132か国、インバウンド100%の例を、サービス精度の根拠として流用してはいけません。
技術問い合わせ AIはエンジニアへの確認をなくせますか？
なくすことをPoC目標にしません。構成と根拠が明確な定型ケースを速く処理し、構成不明、安全影響、設計競合、新規故障は情報をそろえて専門家へ引き継ぎます。エスカレーション率が下がることだけでなく、引継ぎ完全性と誤った非エスカレーションがないかを確認します。
部品見積 自動化ではどこまでAIに任せるべきですか？
初期段階では、適合部品の候補、数量、前提、価格表候補を含む見積下書きまでです。価格、割引、通貨、税・運賃、納期、保証、代替品、顧客への送信は人が承認します。技術適合性と商務条件の両方が承認されて初めて確定見積になります。
デジタルツイン AIがあればPLM/SLMは不要ですか？
不要にはなりません。デジタルツインは設備の状態や構成を利用しやすく表現できますが、部品番号、設計改訂、変更通知、Service BOM、適用規則の管理元が必要です。重要なのは製品名ではなく、実機構成が版付きで維持され、CRM・ERPの文脈と結べることです。
古い設備でBOMが不完全でも始められますか？
始められますが、対象を限定します。製造番号と構成が確認できるシリーズからPoCを始め、欠損設備は構成確認フローへ送ります。写真や現物確認で確定した結果をas-maintainedへ戻し、次回から根拠として使えるようにします。AIに欠損を推測させて見積を確定してはいけません。
製造業 アフターサービス AIの費用はどう見積もりますか？
ユーザー数に基づく公開ライセンス価格だけでなく、データ整備、連携、アクセス制御、評価、承認、教育、運用を分けて見積もります。PoCでは一つの製品群と意思決定フローに範囲を限定し、受入指標を先に合意します。公開価格は変更され得る参考値であり、総導入費ではありません。
まとめ：AIに権限を渡す前に、根拠を渡す
製造業 アフターサービス AIの価値は、回答文を数秒で作ることではありません。顧客と製造番号から、現在構成、設計改訂、適合部品、保証・契約、供給、価格承認までをたどり、「なぜこの回答・見積なのか」を再現できることです。CRMだけでもPLM/SLMだけでも足りず、両者を明確なID、ルール、版、権限、承認ゲートで接続する必要があります。
最初の90日は、一つの製品群、一つの問い合わせ種別、一つの見積下書きフローに絞ります。AIには回答・推奨と下書きを任せ、商務、安全、保証、代替、外部確約は人が承認します。根拠引用率、正しい構成取得率、根拠なし回答率、見積手戻り率、初回応答時間、引継ぎ完全性、技術部門エスカレーション率で受入を判断すれば、自動化率だけに引っ張られず、安全と事業価値を同時に検証できます。
タイ・ASEAN拠点で、製造番号・サービスBOM・CRM・ERPがどこまでつながるかを棚卸しする段階からでもご相談いただけます。対象を一つに絞った90日PoCの設計をご検討の場合は、TOMAS TECHお問い合わせページをご利用ください。
参考資料
- Siemens and Salesforce deepen AI partnership to redefine industrial sales and service（Siemens、2026年9月15日）
- Siemens and Salesforce Expand Strategic Partnership to Redefine Industrial Sales and Service with AI（Salesforce、2026年9月15日）
- Teamcenter Service Lifecycle Management（Siemens）
- What’s new in Teamcenter Service Lifecycle Management Spring 2026（Siemens、2026年6月15日）
- Manufacturing Cloud（Salesforce、2026年9月16日閲覧）
- AI is already rewiring the aftermarket sales and services（McKinsey、2026年5月29日）
- From pilot to profit: Scaling gen AI in aftermarket and field services（McKinsey、2025年3月13日）
