生成AI
BYOAIとは?BYODには慎重だった日本企業が考えるべきシャドーAIのリスクと対策
生成AIの業務利用が急速に広がる中、企業の情報システム部門や経営層に新たな課題が生まれています。
それが、BYOAI(Bring Your Own AI)とシャドーAI(Shadow AI)です。
従業員が個人で契約した生成AIを仕事でも利用する。会社が承認していないAIサービスに業務上の相談をする。自分用にカスタマイズしたAIを、そのまま職場でも使う。
こうした使い方は、すでに特別なものではありません。
MicrosoftとLinkedInが公表した2024 Work Trend Indexでは、仕事でAIを利用する人の78%が、自分で用意したAIツールを職場に持ち込んでいるとされています。日本でもBYOAIを行っているとの回答は78%で、世界平均と同じでした。Microsoftの発表を見る
しかし、ここには一つ大きな疑問があります。
個人所有のPCやスマートフォンを仕事に持ち込むBYODには慎重だった日本企業が、個人のAIを仕事へ持ち込むBYOAIを、そのまま認めてよいのでしょうか。
BYODには慎重だった日本企業
BYOAIを考える前に、BYOD(Bring Your Own Device)を振り返ってみましょう。
BYODとは、社員が個人で所有するPC、スマートフォン、タブレットなどを業務に利用することです。
日本企業では、BYODは必ずしも広く普及しませんでした。
IPAの「DX白書2023」によると、「個人保有のモバイルデバイスの業務活用」について、日本企業では「すでに導入」が11.3%、「導入予定」が13.9%であるのに対し、「導入予定なし」が50.1%でした。
一方、米国企業では「すでに導入」が29.8%、「導入予定」が30.1%で、日本企業よりBYODに積極的な傾向が確認できます。IPA「DX白書2023」を見る
日本企業がBYODに慎重だった理由は理解しやすいでしょう。
個人端末に会社の情報を保存すれば、紛失、盗難、マルウェア感染、退職後のデータ残存など、さまざまな情報管理上の問題が発生します。
そのため企業は、会社支給端末、端末管理、アクセス制御などを利用し、企業データを企業側で管理することを重視してきました。
ところが生成AIの時代には、BYOD以上に難しい問題が発生しています。
BYOAIとは?
BYOAIは「Bring Your Own AI」の略で、従業員が個人的に契約・利用しているAIサービスを業務にも持ち込んで利用することを指します。
たとえば、会社が契約している生成AIとは別に、個人契約の生成AIで資料を作成したり、業務上の相談をしたり、個人的に作成したカスタムAIやAIエージェントを仕事でも利用したりするケースです。
これに対してシャドーAIは、企業の情報システム部門や管理者が把握・承認していないAI利用を広く指します。
Google Cloudも、Shadow AIをBYODやShadow ITに続く企業IT上の問題として取り上げ、未承認の生成AI利用によるデータセキュリティ、プライバシー、コンプライアンス上のリスクを指摘しています。Google Cloudの記事を見る
つまり、BYOAIは「個人のAIを業務へ持ち込むこと」、シャドーAIは「企業から見えないAI利用が発生している状態」と考えると分かりやすいでしょう。
BYOAIが企業の管理外で行われれば、そのままシャドーAIになる可能性があります。
BYOAIはBYODより管理が難しい
BYODの場合、主な管理対象は「端末」と、その端末に保存されるデータでした。
端末を特定し、アクセス権を制御し、退職時には会社データへのアクセスを停止する、といった対応が可能です。
しかしBYOAIでは、個人が利用するAI環境の中に、業務に関するさまざまな情報が蓄積されていく可能性があります。
- 会話履歴
- アップロードしたファイル
- カスタム指示
- プロンプト
- AIエージェントの設定
しかも、問題は「ファイルが保存される」ことだけではありません。
AIに蓄積されるのは「仕事の文脈」
BYOAIのリスクとして最初に思い浮かぶのは情報漏えいでしょう。
顧客情報、設計情報、価格情報、契約書、ソースコード、経営資料などを、企業が管理していない生成AIへ入力することには慎重であるべきです。
ただし、「生成AIへ入力した情報は必ず学習され、他の利用者へ漏れる」と一括りにするのも正確ではありません。
データの保存期間、学習利用の有無、管理機能などは、AIサービス、契約プラン、設定によって異なります。
BYOAIでより本質的な問題になるのは、企業側が契約条件、データ保持、アクセス状況などを十分に管理・監査できないことです。
さらに、生成AIを継続的に使うと、単なるファイル以上のものがAIとの関係の中に形成されていきます。
たとえば営業担当者が個人AIへ、顧客への提案方法、過去の失注理由、価格についての考え方、競合企業への対応、上司が重視する判断基準、提案資料の作り方などを繰り返し相談していたとします。
そのAIは単なるファイル置き場ではありません。
その企業で仕事をするための文脈を持った、個人専用の仕事環境に近づいていきます。
BYOAIでは、企業秘密が「データ」として外部へ出るだけでなく、仕事の進め方や判断の背景、業務ノウハウまで企業の管理外に形成される可能性を考える必要があります。
個人が育てたAIは誰のものなのか
一方、ここでBYOAI特有の難しい問題が生じます。
生成AIを長期間利用している人の中には、自分の仕事のスタイルに合わせてAIをかなりカスタマイズしている人もいるでしょう。
たとえば、自分の文章表現、資料の構成方法、アイデア整理の方法、問題分析のフレームワーク、プログラミングのスタイル、よく使う指示方法などです。
こうしたものは、本人が時間をかけて培ったAI活用能力の一部とも考えられます。
実際、Microsoftの調査では、AI利用者は「時間を節約できる」「重要な仕事へ集中できる」「より創造的になれる」などの効果を挙げています。Microsoftの発表を見る
では、企業は社員に対して、「個人で育てたAIは業務では一切使用してはいけません。会社が用意した初期状態のAIだけを使ってください」と言えばよいのでしょうか。
これは簡単な問題ではありません。
個人が培ったAI活用方法と、会社の業務を通じて得たノウハウや情報の境界は、徐々に曖昧になっていく可能性があるからです。
個別の権利関係については契約や法制度、情報の内容によって異なるため、一律に「会社のもの」「個人のもの」と断定することはできません。
だからこそ、企業側であらかじめ方針を定めておく必要があります。
退職時にBYOAIの問題はさらに大きくなる
BYOAIで特に重要なのが、退職・転職時の問題です。
会社支給PCなら返却できます。
会社が発行したMicrosoft 365やGoogle Workspaceなどのアカウントであれば、退職時に停止できます。
しかし、社員本人が契約しているAIアカウントは企業側で管理できません。
もし個人AIの中に、業務上の会話履歴、会社資料、顧客情報、カスタム指示、業務で作成したAIエージェントなどが残っていれば、そのAI環境を退職後も本人が使い続ける可能性があります。
さらに、その社員が競合企業へ転職する可能性もあります。
従来の情報持ち出しでは、USBメモリへファイルをコピーするといった行為が問題になりました。
BYOAIでは、それとは異なり、会社で仕事をする中で形成された文脈やノウハウを持つAI環境そのものが、個人側に残る可能性があるという新しい問題が生じます。
退職時に削除を求めれば解決する、とも限りません。
企業に管理権限のない個人アカウントについて、企業側が完全な削除を確認・保証できるとは限らないからです。
そのため、退職時の対応だけでなく、在職中から企業情報を個人AIへ蓄積させない設計が重要になります。
シャドーAIはすでに企業リスクとして顕在化している
AIガバナンスの問題は、理論上の話だけではありません。
IBMの2025年「データ侵害のコストに関する調査」では、調査対象600組織の63%が、AIを管理したりシャドーAIの利用を防止したりするためのAIガバナンスポリシーを整備していませんでした。
また、シャドーAIの利用レベルが高い組織では、そうでない組織と比べ、世界平均のデータ侵害コストが67万米ドル高かったと報告されています。IBMの記事を見る
もちろん、この金額をそのまま日本企業へ当てはめることはできません。
しかし、生成AIの利用速度にガバナンス整備が追いついていないこと自体が、企業の新たなリスクになっていることは無視できません。
グローバル企業では、日本だけのAI利用ルールでは足りない
海外拠点を持つ企業では、問題はさらに複雑になります。
日本本社では法人契約AIのみを利用している一方、海外子会社では個人AIが自由に利用されている、といった状態になれば、企業グループとして統一した情報管理ができません。
個人情報、データの国外移転、プライバシー、AI関連規制などは国・地域によって異なります。
そのため、グローバル企業では、企業グループ共通のAI利用原則を設け、その上で各国・地域の法制度や事業環境に応じた追加ルールを設計するという考え方が必要になります。
「日本本社の生成AI利用ガイドライン」を作るだけでは十分ではない可能性があります。
情報システムガイドラインは「生成AIの項目を足す」だけでよいのか
これまで企業の情報セキュリティや情報システムに関する規程では、PC、スマートフォン、USBメモリ、メール、クラウドストレージ、パスワード、BYODなどが管理対象でした。
生成AI時代には、新たに多くの論点が加わります。
- プロンプト
- AIとの会話履歴
- アップロードファイル
- 個人AIアカウント
- AIの長期記憶
- カスタムAI
- AIエージェント
- AIから社内システムへのアクセス
- AIによる外部操作
さらに、社員の異動・退職や、海外拠点でのAI利用まで考えなければなりません。
したがって企業によっては、既存規程へ「生成AI利用上の注意事項」を数ページ追加するだけではなく、情報セキュリティ、アカウント管理、データ管理、外部サービス利用、開発、退職者管理などの関連規程全体を、AI利用を前提に再検討する必要が生じる可能性があります。
GBSでは、BYOAIの業務利用は原則慎重に考えるべきだと考えます
ここまでの論点を踏まえ、GBSでは、企業情報を扱う業務で個人管理のAIをそのまま利用するBYOAIについては、原則として慎重な立場を取るべきだと考えます。
特に、会社が管理できない個人AIへ企業情報や業務上の文脈が蓄積され、退職後もその環境が残る可能性を考えれば、企業情報を扱うAIは会社が管理することが基本になるでしょう。
これは生成AIそのものを禁止するという意味ではありません。
むしろ企業としてAIを積極活用するからこそ、会社の情報を扱うAIは、会社が管理できる環境で利用するという原則が重要になります。
一方で、それだけでは新たな問題が残ります。
では、個人が育ててきたAIの価値はどうするのか
BYOAIを原則禁止した場合、それまで社員が個人AIを使い込むことで培ってきたものはどうすればよいのでしょうか。
- 自分に合った文章表現
- 思考を整理する方法
- よく使うプロンプト
- 資料作成の進め方
- AIへの指示方法
こうしたものまで一律に捨てさせれば、AIを使いこなしてきた社員ほど、会社のAI環境に移ったときに生産性が低下する可能性があります。
BYOAIを制限することと、個人が培ったAI活用能力まで失わせることは、同じではありません。
では、個人が培ったAI活用能力を活かしながら、会社の情報や業務ノウハウは企業側で管理するには、どのような仕組みが必要なのでしょうか。
ここから先は、単なる「生成AI利用禁止事項」の作成では解決できません。
個人AIと会社管理AIの境界、パーソナライズ情報の扱い、企業データとの接続方法、アクセス権限、利用履歴、AIエージェントの実行権限、異動・退職時の管理、海外拠点を含む運用ルールなどを、企業ごとの業務実態に合わせて設計する必要があります。
BYOAI/シャドーAI対策を、AI環境全体から考える
GBSでは、個人アカウントと法人管理環境の利用範囲、企業データとの接続、アクセス権限、ログ、人による承認、AIエージェントの実行範囲などを整理し、企業固有のAI活用環境として設計する支援を行っています。
まとめ―BYOAIは「使うか、使わないか」だけの問題ではない
BYOAIは、単純に「BYODのAI版」と考えるべきではありません。
BYODで企業が管理しようとしていたのは、主として端末と保存データでした。
BYOAIでは、それに加えて、AIとの対話、仕事の進め方、判断の背景、業務ノウハウ、個人向けに形成されたAI環境そのものが問題になります。
日本企業は、かつてBYODに慎重でした。
BYOD以上に企業と個人の境界が曖昧になる可能性があるBYOAIについても、利便性だけを理由に安易に解禁すべきではありません。
一方、個人AIを禁止するだけで、社員が培ってきたAI活用能力まで失わせる必要もありません。
これから企業が考えるべきなのは、「個人AIを会社へ持ち込む方法」ではなく、「個人が培ったAI活用能力を、企業情報を守りながら会社のAI環境で活かす方法」ではないでしょうか。
そのためには、AI利用規程だけではなく、企業の情報管理、AI環境、権限、データ、組織、人材を含めた新しいAIガバナンス設計が必要になります。
BYOAI・シャドーAIに関するよくある質問
BYOAIとは何ですか?
BYOAI(Bring Your Own AI)とは、従業員が個人で契約・設定した生成AI、カスタムAI、AIエージェントなどを業務でも利用することです。個人向けに蓄積したプロンプトや文章表現、仕事の進め方を活かせる一方、企業情報や業務上の文脈が会社の管理外にあるAIアカウントへ蓄積される可能性があります。そのため、個人AIと会社管理AIの利用範囲や、業務データを扱う際のルールを整理する必要があります。
BYOAIとシャドーAIは何が違いますか?
BYOAIは、従業員が個人で利用しているAIを業務へ持ち込むことを指します。一方、シャドーAIは、企業の情報システム部門や管理者が把握・承認していないAI利用全般を指します。BYOAIが企業の承認と管理のもとで行われる場合も考えられますが、会社が把握できない状態で利用されれば、シャドーAIになる可能性があります。
シャドーAIにはどのようなリスクがありますか?
主なリスクは、顧客情報、設計情報、契約書、ソースコード、経営情報などが、企業の管理していないAIサービスへ入力されることです。サービスごとにデータの保存場所や利用条件が異なるほか、企業側で利用履歴や削除状況を確認できない場合があります。
さらに、個人のAIアカウントへ仕事の進め方、判断基準、過去の相談内容などが蓄積されると、異動・退職時に業務ノウハウを企業側で回収・管理できない可能性があります。情報漏えいだけでなく、アカウント管理、アクセス権限、法令・社内規程への適合、利用履歴、退職者対応を含めて考える必要があります。
シャドーAIは生成AIの利用を禁止すれば防げますか?
利用禁止のルールを設けるだけで、すべてのシャドーAIを防げるとは限りません。業務に役立つAI環境が会社から提供されていなければ、従業員が個人AIを利用する動機が残る可能性があります。
禁止事項を示すだけでなく、会社が管理するAI環境を用意し、扱える情報の区分、個人アカウントとの境界、アクセス権限、利用ログ、人による承認、異動・退職時の取り扱いなどを具体的に設計することが重要です。また、従業員が個人AIの利用を通じて培ったプロンプト作成や業務改善の能力を、企業情報を持ち込まずに会社管理AIで活かせる方法も検討する必要があります。
BYOAI/シャドーAIへの対応を、自社ではどこまで進めるべきでしょうか?
GBSでは、企業ごとの業務内容、情報区分、既存システム、海外拠点などを踏まえ、BYOAI/シャドーAI対策、AI利用ポリシー、会社管理AI環境、AIハーネスを含むAIガバナンスの設計をご支援します。
「全面禁止すべきか」「どこまで利用を認めるべきか」「社員が培ったAI活用能力をどう活かすか」など、企業によって適切な設計は異なります。
自社に適したAI利用環境について、まずはGBSへご相談ください。
参考情報
AIエージェント時代のPLMとは
製造業でAIエージェントへの期待が高まっています。検索、要約、問い合わせ対応といった補助業務だけでなく、BOM確認、設計変更の影響把握、図面や技術文書の横断検索、過去案件の再利用、プロジェクト進捗の把握まで、設計・開発の現場でAIを使いたいという声は確実に増えています。
ただし、ここで重要なのは「AIを導入すれば業務が変わる」という単純な話ではないことです。製造業の実務では、AIエージェントが何を参照し、どの情報を根拠に答え、どこまで業務文脈を理解できるかが成果を左右します。
GBSは、AIエージェント時代のPLMを設計情報管理のための仕組みとしてではなく、AIエージェントが業務で活躍するための製品情報基盤として捉えるべきだと考えています。こうした考え方は、近年「Agentic PLM(エージェンティックPLM)」と呼ばれることもあります。
BOM、図面、文書、要求仕様、設計変更、プロジェクト情報などが整理され、信頼できるデータとして管理されていなければ、AIは現場で使える答えを返せません。逆に言えば、製品情報管理が整っていれば、AIエージェントは単なる会話ツールではなく、設計・開発・製造の実務を前に進める存在になれます。

AIエージェントが製造業で注目される理由
AIエージェントが製造業で注目される背景には、設計・開発業務の複雑化があります。開発スピードの要求は高まる一方で、製品は多品種化し、部門横断の調整は増え、技術情報は散在し、ベテランの知識継承も課題になっています。
これまでのように、人が必要な情報を探し、読み比べ、関係部門に確認しながら判断するだけでは、スピードにも再現性にも限界があります。そこで期待されているのが、必要な情報を横断的に探し、文脈に応じて整理し、次のアクションにつながる形で支援するAIエージェントです。
特に製造業では、単なるチャット機能ではなく、設計・製造・品質・保守にまたがる情報をつなぎながら、現場の判断を支援することが求められます。つまり、製造業におけるAIエージェントの本質は、「AIが自然な文章を返すこと」ではなく、「業務に必要な製品情報へ適切にアクセスし、活用できること」にあります。
AIだけでは業務改善できない理由
GBSは、AI単体では業務改善できないと考えています。なぜなら、AIの性能が高くても、参照する情報が整理されていなければ、現場で使える答えにはならないからです。
たとえば、次のような問いは製造業では日常的に発生します。
- この設計変更はどのBOMに影響するのか
- 類似部品は過去に存在したか
- この要求仕様はどの図面・試験項目・文書と関係しているか
- 過去案件ではどのような判断がされていたか
- 現在参照すべき正しい版はどれか
これらに答えるためには、AIそのものよりも先に、製品情報の構造と関係性が整っていなければなりません。BOM、図面、仕様書、変更履歴、要求仕様、プロジェクト情報が分断されたままでは、AIは断片的な補助しかできません。
ChatGPTのような生成AIも同様です。生成AIは非常に有力な技術ですが、単体で導入しただけでは製造業DXは前進しません。実務で使うには、PLMデータ、ERP、文書管理、BOM、設計変更情報などとAPI連携し、必要な文脈と根拠を持たせる必要があります。OpenAI APIも、エージェント構築においてはコンテキスト、ツール、業務システム連携が重要であることを示しています。
つまり、AIエージェントを導入する前に問うべきなのは、「どのAIを使うか」だけではありません。まず問うべきなのは、AIが使うべき製品情報が整理されているかです。
Agentic PLMとは?
近年、AIエージェントとPLMを組み合わせた考え方として、「Agentic PLM(エージェンティックPLM)」という言葉が使われ始めています。
Agentic PLMとは、PLMに蓄積されたBOM、図面、仕様書、要求仕様、設計変更、プロジェクト情報などをAIエージェントが参照し、単に情報を検索・要約するだけでなく、業務の文脈を踏まえた分析や判断支援、次のアクションにつなげていく考え方です。
従来のPLMが「製品情報を正しく管理する仕組み」だとすれば、Agentic PLMでは、その製品情報をAIエージェントが業務で活用できる状態にすることまでが重要になります。
Agentic PLMのポイント
AIそのものをPLMに追加することが目的ではありません。AIエージェントが正しいBOMや最新版の図面、変更履歴、要求仕様などを根拠として、安全かつ適切に業務を支援できる製品情報基盤を整えることが重要です。
そのため、Agentic PLMを実現するうえでは、AIモデルの性能だけでなく、製品情報の正本管理、版管理、データ間の関係性、アクセス権限、承認プロセス、APIによる業務システムとの連携などが重要になります。
GBSでは、この考え方を「AIエージェント時代のPLM」として捉えています。PLMを単なる設計情報の保管場所ではなく、AIエージェントが設計・開発・製造・品質・保守の業務で活躍するための信頼できる製品情報基盤へ進化させることが重要だと考えています。
AIエージェントを支えるPLMという考え方
ここでPLMの役割が変わります。これまでPLMは、設計情報管理、図面管理、部品表管理、変更管理の仕組みとして語られることが一般的でした。もちろんそれらは今後も重要です。
しかしAIエージェント時代には、PLMを単なる管理システムとしてではなく、AIエージェントが安全かつ実務的に使える情報基盤として捉える必要があります。
PLMが重要なのは、情報を集めるからではありません。どの情報が正本なのか、どの版が有効なのか、誰が参照できるのか、どの変更が何に影響するのか、といった業務文脈を持って管理できるからです。AIエージェントに必要なのは大量データではなく、文脈付きで信頼できるデータです。
この意味で、PLMは「設計情報管理」から「AIエージェントの情報基盤」へと、その価値の見え方を変えつつあります。
- 正しいBOMにAIがアクセスできること
- 図面・仕様書・要求仕様が関連付けられていること
- 設計変更の前後関係と影響範囲が追えること
- 案件・製品・部品・文書・人の関係がたどれること
- 権限や承認ルールを守ったままAIが利用できること
こうした状態が整って初めて、AIエージェントは「答えるAI」ではなく、「業務を前に進めるAI」になります。
世界のPLM市場も同じ方向へ進んでいる
これはGBSだけの考え方ではありません。世界のPLMベンダー各社も、表現は異なっていても、AIを単体機能としてではなく、PLMやデジタルスレッド上の情報を活用する方向へ進めています。
PTCはWindchill AIを、PLMワークフローに埋め込まれたAIとして位置づけ、製品データの理解、定型作業の自動化、意思決定支援、さらに「agentic digital thread」という考え方まで打ち出しています。AIが価値を出す前提として、信頼できる製品データとデジタルスレッドがあることを明確にしています。
SiemensのTeamcenter Copilotは、PLM内の知識ベース、セマンティック検索、RAG、権限制御を通じて、企業内の文書や製品情報に根ざした回答を返す考え方を示しています。これは、AIが外部の一般知識ではなく、自社のPLMデータを根拠に動くべきだという典型例です。加えて、Siemens Industrial Copilotも、設計・計画から運用・保守まで産業バリューチェーン全体を支援する方向性を示しています。
Arasは、構造化データと非構造化データをまたぐAI支援検索や、自然言語での知識活用を打ち出しています。PLMとデジタルスレッドを基盤に、製品データへのアクセスや解釈をより実務的にする方向です。
Dassault Systèmesは、AIをVirtual TwinやOntology、Generative Knowledge & Know-Howと結びつけ、データを検証可能な知識へ変える方向を示しています。ここでも重要なのは、AI単体ではなく、モデル、データ、文脈を結びつける基盤的な考え方です。
CONTACT SoftwareのFourier AIも、製品ライフサイクル全体にAIを埋め込むための基盤として位置づけられています。BOM処理や要件管理など、Digital Thread上の各ポイントでAIを活用する考え方は、まさにAIエージェント時代のPLMの一つの方向性といえます。
つまり市場全体は、「AI搭載PLM」という表現を超えて、AIが活躍できる製品情報基盤をどう作るかという方向へ進みつつあります。GBSが打ち出したいメッセージは、この流れと本質的に重なっています。
AIエージェント活用例
BOM活用
AIエージェントは、部品表を読むだけでなく、構成差分の把握、類似部品の再利用候補抽出、調達影響の確認、変更候補の洗い出しまで支援できます。ただし前提になるのは、BOMが統一された粒度・属性・版管理で整備されていることです。BOMが部門ごとに分断され、名称ゆれや属性欠落が多い状態では、AIは正しい再利用提案も影響分析もできません。
多品種・多仕様のBOM管理について
製品の仕様やオプションが増える場合は、BOMの粒度や版管理だけでなく、製品バリエーションをどのように表現・管理するかも重要になります。
製品ファミリー全体の構成候補を管理する150% BOMと、特定仕様の100% BOMの違い、構成ルールの考え方については、別のコラムで詳しく解説しています。
設計変更
設計変更は、AIエージェントが価値を出しやすい領域です。変更要求の要約、関連文書の収集、影響対象部品・図面・試験項目の抽出、過去類似案件の提示などは、実務での有効性が高いテーマです。しかし実際には、変更理由、承認履歴、変更前後の差分、関連成果物がPLM上で一貫して管理されていなければ、AIは部分的な補助しかできません。
図面検索
図面検索では、「品番を知っている人だけが探せる」状態から脱却できるかが重要です。AIエージェントが自然言語で「この機能を持つ部品」「過去に似た構造の図面」「この規格に関わる設計例」を見つけられるようになると、設計初期の検討スピードは大きく変わります。ただし、図面そのものだけでなく、メタデータ、版、関連仕様、変更履歴までひも付いていなければ、検索結果の信頼性は上がりません。
技術文書
仕様書、試験規格、作業標準、品質文書、過去トラブル報告書など、製造業には「あるが見つからない」「読めるが使い切れない」文書が大量にあります。知識ベース化されたPLM文書に対してAIが対話的に回答できれば、ベテラン依存の軽減や立ち上がり期間短縮に効果があります。逆に、文書が散在し、どれが正なのか分からない状態では、AIは誤誘導のリスクを高めます。
過去案件の再利用
AIエージェントは、過去案件を「検索対象」から「再利用資産」へ変える可能性を持っています。類似製品、類似部品、類似要求、過去の不具合対応、顧客別カスタマイズ履歴を横断して参照できれば、設計の初手が変わります。ですが、案件情報、成果物、変更履歴、技術判断の根拠がPLMや関連システムでつながっていないと、再利用は結局人の記憶頼みのままです。
プロジェクト管理
プロジェクト管理でも、AIエージェントは進捗報告の要約、遅延要因の抽出、未完了タスクと設計変更の関連把握、会議前の論点整理などで役立ちます。ただし、タスク、成果物、承認、課題、設計変更が別々のツールで管理されていて関係性が見えない場合、AIは状況説明の補助にはなっても、意思決定支援までは届きません。
AIエージェント時代にPLM導入を考えるポイント
AIエージェント前提でPLM導入を考えるなら、機能一覧やパッケージ比較だけでは不十分です。重要なのは、「将来、AIが使える情報基盤になっているか」という視点です。
1. 製品情報の正本をどこに置くか
BOM、図面、仕様書、要求仕様、変更情報の正本管理を曖昧にしたままAIを載せても、答えの信頼性は上がりません。まずは製品情報管理の中心を定義することが必要です。
2. 構造化データと非構造化データを分断しないか
AIエージェントは、BOMのような構造化データだけでなく、PDF、Word、図面、スキャン文書、議事録などの非構造化データも横断して価値を出します。両者を関連付けて扱えるPLM設計が重要です。
3. 設計変更を履歴ではなく知識として扱えるか
変更票を残すだけでなく、「なぜ変えたか」「どこに影響したか」「再発防止にどう生かすか」まで追える設計が、AIエージェント時代の変更管理には求められます。
4. 権限・承認・トレーサビリティを保ったままAIが使えるか
製造業でAIを使ううえでは、便利さ以上に統制が重要です。誰が何を見られるか、どの版を根拠にしたか、どの回答がどの情報源に基づくかを担保できることが必須です。
5. ERP、文書管理、品質、プロジェクト情報とつながるか
AIエージェントは単独システム内より、複数システムをまたいだ時に真価を発揮します。PLMを核に、ERP、QMS、文書管理、プロジェクト管理との連携を見据えたアーキテクチャが必要です。
6. API連携や将来のAI拡張が可能か
ChatGPTをはじめとする生成AIや各種AIエージェントを活用するには、将来的なAPI連携、検索基盤、RAGなどの接続性も重要になります。今の運用課題だけでなく、将来のAI活用余地を見越してPLMを設計すべきです。
7. Fit to Standardだけで終わらないか
標準機能に業務を合わせることは依然として重要です。しかし、AIエージェント時代には、その標準化が「AIが読める・つながる・再利用できる」状態につながっているかまで問われます。これからのPLM導入では、Fit to Standardに加えて、Fit to AIの視点が必要です。
GBSがご支援できること
GBSは、PLMを単なるシステム導入テーマではなく、製造業DXを支える製品情報基盤づくりとしてご支援します。AIエージェントを入れること自体が目的ではなく、AIエージェントが実務で機能するための情報設計、業務設計、運用設計まで含めて考えることが重要です。
- PLM導入支援:現状業務の整理、製品情報の棚卸し、BOM・設計変更・文書管理の要件定義、導入構想策定
- CONTACT Software活用支援:PLM基盤構築、デジタルスレッド整備、将来のAI活用を見据えた情報設計
- CIM Database活用支援:設計情報・技術情報の蓄積と再利用性向上、検索性改善、業務知識の資産化
CONTACT Fourier AIのように、PLM上の情報を前提にAIを活用する選択肢は今後さらに増えていきます。ただし重要なのは、特定のAI製品を先に決めることではありません。まず、自社のBOM、図面、文書、要求仕様、設計変更、案件情報が、AIエージェントにとって使える状態にあるかを見極めることです。
GBSが考えるこれからのPLMは、設計情報を管理するためだけのものではありません。AIエージェントが、設計、開発、製造、品質、保守にまたがって活躍するための基盤です。
Fit to Standardから、Fit to AIへ。
この視点でPLMを見直すことが、これからの製造業DXにおける競争力の差につながります。
FAQ
Q1. AIエージェントがあれば、PLMは不要になるのでしょうか。
A. いいえ。むしろ逆です。AIエージェントが実務で価値を出すには、信頼できる製品情報基盤が必要です。PLMは、AIが参照する情報の正本・版・関係性・権限を管理する役割を担います。
Q2. ChatGPTを導入すれば、設計業務はすぐ効率化できますか。
A. 単体導入だけでは限定的です。ChatGPTや生成AIは有力ですが、PLM、ERP、文書管理、BOM、変更管理とAPI連携し、業務文脈を持たせて初めてAIエージェントとして機能します。
Q3. なぜBOMがAI活用の鍵になるのですか。
A. BOMは製品構成の中心情報だからです。部品間の関係、影響範囲、再利用候補、原価や調達への波及など、多くの判断がBOMを起点に発生します。BOM品質が低いとAIの提案精度も下がります。
Q4. 図面やPDFが大量にあります。これでもAI活用は可能ですか。
A. 可能ですが、整理が前提です。版管理、属性付与、関連情報とのひも付け、OCRや検索性改善が必要です。文書が散在したままでは、AIは「見つけたように見えて、使えない」状態になりがちです。
Q5. AIエージェントと生成AIは同じ意味ですか。
A. 厳密には異なります。生成AIは文章生成や要約などのモデル機能を指すことが多く、AIエージェントはそこに検索、ツール実行、システム連携、業務フロー遂行まで含めた実行主体を指します。
Q6. Agentic PLMとは何ですか?
A. Agentic PLMとは、PLMに蓄積されたBOM、図面、仕様書、設計変更、要求仕様などの製品情報をAIエージェントが活用し、検索や要約だけでなく、分析、判断支援、業務アクションにつなげていく考え方です。
重要なのは、AIをPLMに追加すること自体ではありません。AIエージェントが信頼できる製品情報を、適切な権限や承認ルールのもとで利用できるようにすることです。そのため、Agentic PLMでは、製品情報の正本管理、版管理、データ間の関係性、権限管理、API連携などが重要になります。
Q7. まずAIツールを入れてから、後でPLMを整えてもよいですか。
A. 一時的なPoCなら可能ですが、本番活用では限界が出やすいです。情報基盤が未整備だと、回答の根拠、更新追従、権限、トレーサビリティの問題が残ります。
Q8. AIエージェント時代のPLM導入では、どの部門が関与すべきですか。
A. 設計部門だけでなく、情報システム、DX推進、品質、製造技術、場合によっては経営層も含めた横断体制が望まれます。AI活用はシステム導入ではなく業務基盤再設計に近いテーマだからです。
Q9. デジタルスレッドとPLMはどう違うのですか。
A. PLMは製品情報を管理する基盤であり、デジタルスレッドはその情報を設計から製造、品質、保守までつなぐ考え方です。AIエージェントは、このつながりがあるほど高い価値を出しやすくなります。
Q10. CONTACT Fourier AIのようなAI基盤は、どのような企業に向いていますか。
A. 製品情報をPLM上で整備しながら、将来的にBOM、要件管理、文書活用、デジタルスレッド全体でAIを使いたい企業に向いています。ただし、先に情報基盤の整備方針を固めることが重要です。
Q11. PLM導入は、AI活用を前提にすると難しくなりませんか。
A. 難しくなるというより、目的が明確になります。単なる管理効率化ではなく、「AIが業務で機能するための情報基盤をつくる」という視点が加わるため、導入意義を社内で共有しやすくなります。
AIエージェント時代のPLM導入をご検討中の方へ
AIエージェントを業務で活用するには、AIそのものだけでなく、BOM・図面・文書・設計変更情報などを整理した製品情報基盤が重要です。
GBSでは、PLM導入支援、CONTACT Software / CIM Databaseの活用、AIエージェントを見据えたデータ整備・業務設計までご相談いただけます。
関連ページもご覧ください
PLMに関する基本的な考え方についてはPLMとは?をご覧ください。
AIエージェント時代のPLMを具体的に検討する際は、PLM導入支援、CONTACT Software、CIM Databaseの各ページもあわせてご覧ください。
参考情報
- PTC / Windchill AI
- Siemens / Teamcenter Copilot
- Siemens / Industrial Copilot
- Aras / AI-Assisted Search and Intelligent Assistant
- CONTACT Software / Fourier AI
- Dassault Systèmes / AI Software
- Autodesk / Autodesk Assistant
- Arena / AI Assistant
- OpenAI / API Platform for Agents
- NIST / Digital Thread for Smart Manufacturing
