2026年4月のハノーバーメッセでは、生成AIが「答えを提示する道具」から「業務を引き受けて自律的に動く存在（エージェント）」へと位置づけを変えた展示が主役になりました。国内でも7月には「製造業の生成AI展」が東京ビッグサイトで開催され、現場での実装が一段と現実味を帯びています。一方で、設計部や調達部の担当者に話を聞くと、返ってくる言葉はむしろ逆です。「ツールは年々増えているのに、忙しさは変わらない」。CADもPLMも、社内チャットボットも導入した。それでも図面を探す時間は減らず、設計変更の連絡漏れも消えない——。本記事では、この「ツールは増えたのに業務は軽くならない」という体感のズレがどこから来るのかを業務フローで分解し、生成AIを“使うツール”としてではなく“任せるエージェント”として現場に組み込むときに問われる「業務分解力」という視点を整理します。

なぜツールを入れても設計者の時間は戻らないのか

多くの設計部門は、過去20年でCAD（2D/3D）、PDM/PLM、構成管理ツール、DRレビューシステムと、複数のITツールを順に導入してきました。にもかかわらず、設計者の一日を細かく追うと、時間の使い方は驚くほど変わっていません。類似品の参考図面が見つからずベテランに聞いて回る、設計変更のたびに設計BOM・製造BOM・購買BOMの整合を手で確認する、ECN（Engineering Change Notice：設計変更通知）を関係部署に回したものの誰が受領したか追えない——こうした「探す・転記・通知・整合確認」に、設計者の業務時間の3〜4割が吸い取られています。

CADもPLMも入っているのに、業務時間そのものは10年前と変わっていない。

設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤

ここで効いてくるのが、ツールと業務の「接続」の問題です。図1は、設計者の業務時間の配分を「ツールを入れただけの状態」と「定型業務をエージェントに委譲した状態」で並べた概念試算です。ツールを増やしても、それを“使うかどうか”が個人任せである限り、非付加価値の時間はあまり減りません。逆に、定型・探索系の作業をエージェントが引き受ければ、設計者は構想設計や検図といった付加価値業務に時間を戻せます。

汎用の生成AIチャットを全社に配っても、同じことが起こります。便利なのは間違いないのですが、業務フローに接続されていないため、「使いこなせる一部の人が、一部の作業で部分的に使う」状態にとどまります。ツールは増え、ライセンス費も増え、それでも組織全体の業務時間は動かない。これは現場の怠慢ではなく、構造の問題です。なぜ既存のシステムでこの空白が埋まらなかったのかは、業務基盤という考え方から整理すると見通しが良くなります。

ERPは「お金とモノの記録台帳」、PLMは「図面とBOMの保管庫」であり、いずれも「業務そのもの」を実行する仕組みではない

業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体

「ツール型AI」と「エージェント型AI」は何が違うのか

生成AIの組み込み方を2つに分けて考えると、見通しが良くなります。ひとつは、人が必要なときに開いて指示を出す「ツール型」。もうひとつは、業務フローの中に常駐し、定型の判断と作業を引き受ける「エージェント型」です。両者は同じ大規模言語モデル（LLM）を使っていても、業務に対する関係がまったく異なります。下表に、その違いを整理しました。

観点	ツール型AI	エージェント型AI
使い方	人が開いて、その都度指示する	業務フローに常駐し、定型処理を引き受ける
対象	個人の作業（下書き・要約・調べ物）	部署をまたぐ業務（探索・整合・通知・追跡）
社内データとの接続	原則つながらない（その場で完結）	図面・部品表・品質データに権限付きで接続
記録・責任	履歴は個人に閉じる	誰が・いつ・何をしたかの監査証跡が残る
効果の出方	使える人が部分的に速くなる	組織の業務時間そのものが動く

“OS”という言葉を使うのは、この違いを指してのことです。アプリ（個別ツール）は人が起動して使うものですが、OSは裏側で常に動き、アプリと業務をつなぎ続けます。設計・調達・品質・生産技術の業務を、人が一つひとつツールを起動して回すのではなく、業務基盤（業務OS）の上でエージェントが定型処理を引き受け、人は判断に集中する——これが“任せる”という発想の中身です。業務エージェント、あるいは業務実装プラットフォームと呼んでも構いません。重要なのは名前ではなく、「業務フローに接続されているか」です。

現場業務を「任せる／握る」で分解する——業務分解力という設計スキル

“任せるエージェント”を入れるときに最初に問われるのが、自社の業務を「任せられる仕事」と「人が握るべき仕事」に切り分ける力、すなわち業務分解力です。図2は、設計業務を委譲適性の観点で並べたものです。図面・仕様情報の探索、帳票や部品表の転記と整合、変更通知の伝達と受領追跡、類似案件の参照といった定型・探索系は委譲適性が高い。一方、構想設計やトレードオフ判断、最終検図・出図承認、責任を伴う意思決定は、人が握るべき領域です。

この切り分けを、設計変更というひとつの業務で具体化してみます。現状のフローは、設計者が変更を起票し、影響範囲（BOM・組立順序・検査仕様）を手で追跡し、関係部署にメールや回覧で通知し、受領確認は電話とリマインドで行い、漏れが発覚するのは不適合品が出た後、という流れです。これをエージェント委譲後のフローに置き換えると、変更が起票された時点で、影響範囲の洗い出しと通知先の特定、受領状況の追跡をエージェントが実行し、未読・未対応は自動で督促され、人は「この変更を承認してよいか」という判断だけに集中できます。作業は引き受けさせ、判断は人が握る。これが業務分解の基本形です。

業務そのものではなく業務の周辺事務に大量の工数が吸われている

調達OSとは——見積・サプライヤー管理・購買業務を統合する業務基盤

自己診断：あなたの現場は“任せる”準備ができているか

• 主要な業務フロー（設計変更・図面検索など）を「探す・転記・通知・整合確認」と「構想・判断・承認」に分けて説明できる
• 設計者が定型・探索系に使っている時間を、おおよそでも把握している
• 社内の図面・部品表・品質データに、権限を管理しながら接続できる状態にある
• 「誰がいつ何を承認したか」を記録として残す必要がある業務を特定できている
• AIに任せてよい業務と、人が責任を持って握るべき業務の線引きが、部署内で共有されている

投資判断は、金額の多寡だけで測ると見誤ります。見るべきは、対象業務に張り付いている時間のうちどれだけが探す・転記・通知・整合確認といった定型・探索系か、その業務が組織で何人ぶん発生しているか、そして人が握るべき判断業務に時間を戻したとき設計品質やリードタイムにどう跳ね返るか——この3点です。削減した時間そのものより、戻した時間が生む価値で評価する。この考え方に立てると、エージェント委譲の効果は単なるコスト削減ではなく、設計力そのものへの再投資として説明できます。

「ChatGPTでよいのでは」という問いに、正面から答える

「結局、ChatGPTのような汎用ツールで十分なのでは」という問いはもっともです。答えは、合うケースと合わないケースがあります、です。合うのは、個人の作業——文章の下書き、要約、調べ物、コード片の生成など、その人が開いてその場で完結する仕事です。ここは汎用ツールが圧倒的に強い。一方で合わないのは、複数部署をまたぐ業務フロー、社内の図面・部品表・品質データといった機微な情報の参照、そして「誰がいつ何を承認したか」の記録と責任が問われる業務です。汎用チャットは業務フローに常駐せず、社内データに権限付きで接続されず、監査証跡も残らないため、そのままでは“任せる”対象にはなりません。個人を強くするのが汎用ツール、組織の業務を回すのがエージェント型——この棲み分けで考えると、二者択一ではないことが見えてきます。

よくある質問（FAQ）

エージェント型AIは、RPAと何が違うのですか。

RPAは「あらかじめ決められた手順を正確に繰り返す」自動化です。エージェント型は、状況に応じて手順そのものを組み立て、例外を判断し、必要な情報を自分で集めにいく点が異なります。定型作業の置き換えにとどまらず、「探す・照合する・督促する」といった判断を含む業務まで引き受けられるのが特徴です。

何から始めればよいですか。

まず自社の一業務（たとえば設計変更通知や図面検索）を、「探す・転記・通知・整合確認」といった定型・探索系と、「構想・判断・承認」といった人が握るべき業務に分解することです。最初に動かすのは、漏れると痛いのに判断は単純な業務——変更通知の受領追跡などが向いています。小さく接続して効果を確かめ、対象業務を広げていくのが定石です。

社内データやセキュリティはどう扱われますか。

業務に接続するエージェントは、参照範囲・権限・監査証跡を業務基盤側で管理する設計が前提です。誰が・どのデータに・どの権限でアクセスしたかを記録できる構成にすることで、機微情報を扱う製造業の現場でも運用に乗せられます。逆に言えば、この管理層を持たない仕組みは、現場の重要業務を任せる対象にはなりません。

まとめ——“任せる”前に、業務を分解する

2026年、生成AIは「使うツール」から「任せるエージェント」へと役割を広げています。ただし、任せるためには、その前段として自社の業務を「任せられる仕事」と「人が握るべき仕事」に分解する作業が欠かせません。ツールを増やすことではなく、業務を分解して接続すること——これが、現場の時間を取り戻す出発点になります。展示会で見た“動くAI”を自社に持ち帰るとき、最初に取り組むべきは導入製品の比較ではなく、自社業務の分解だ、と言い換えてもよいでしょう。

自社の設計業務のどこに定型・探索系の時間が張り付いているか、どこからエージェントに任せられるか——それを業務フロー単位で切り分ける「業務診断」を、30分・無料で提供しています。

関連して読みたい記事

• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体
• 設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤
• 業務OS導入の稟議が通る組織の条件——意思決定構造を3つの軸で分解する