「設計DXに3,000万円投資したい」と稟議書を回したとき、決裁者から最初に返ってくる質問は何でしょうか。多くの場合、それは「効果はいくらで、何年で回収できるのか」ではなく、「これを入れたら、現場の誰の業務が、どう変わるのか」です。この質問に1枚の図で答えられない稟議書は、ほぼ通りません。製造業のAI投資・業務基盤投資の稟議が通るかどうかは、技術選定の妥当性ではなく、組織の意思決定構造の側で決まっています。本稿では、業務OS導入の稟議が通る組織が共通して押さえている3つの軸——業務分解の解像度／責任配置／撤退条件——を、稟議書の構造に落とし込んで整理します。

稟議が止まる構造的理由——「投資対効果」の言語化が業務側で終わっている

稟議が通らないとき、決裁者は技術を否定しているわけではありません。3D CAD更新やPLM導入の稟議は通った企業でも、AI関連の投資稟議は途中で止まることが少なくありません。なぜ同じ企業の同じ決裁ラインで、技術投資の通りやすさが変わるのでしょうか。

差は、稟議書に書かれた「投資対効果」の言語化が、業務側でどこまで進んでいるかにあります。PLMや3D CADは、業務の置き換え対象が明確です——既存の図面サーバを置き換える、既存の2D設計を3Dに置き換える。投資の主語が「ツール」で、効果の主語も「ツール」です。一方、業務OSや個社別AIエージェントは、置き換え対象が業務プロセスそのものです。図面検索という業務、設計変更通知という業務、見積依頼という業務——これらが「人が手を動かす業務」から「AIが第一次処理する業務」に変わります。投資の主語が「業務」になる瞬間に、稟議書の様式が追いつかなくなります。

具体的には、3つの問いに答えられないと稟議は止まります。第一に「どの業務が、どれだけ削れるのか」(業務分解の解像度)。第二に「効果が出なかった場合、誰がどう責任を取るのか」(責任配置)。第三に「いつ撤退判断するのか」(撤退条件)。この3つは、いずれも業務側の整理が前提で、技術ベンダーが代わりに答えられる問いではありません。代わりに答えようとすると「効果はXX社の事例で30%削減」のような他社事例の引用になり、決裁者は「うちは違う」で打ち返します。

稟議の問題を「決裁者の理解不足」「経営層がAIに弱い」と整理する見方もありますが、現場の感触としては逆です。決裁者は十分にAIの可能性を理解した上で、組織として投資判断するための言語が現場側で生成されていないことに困っています。AI投資が通る組織と通らない組織の差は、現場が業務をどこまで言語化して経営層に渡せているかの差です。

稟議が通る組織の3つの軸——業務分解／責任配置／撤退条件

ERPは記録台帳・PLMは保管庫。両者があっても業務を継続的に走らせる仕組みは抜け落ちている——この空白を埋めるのが業務OSである。

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

軸1: 業務分解の解像度——「設計者の業務」を90分単位で割る

業務OS導入の稟議が通る組織では、設計者・調達担当・品質担当の業務を「日単位」ではなく「90分単位」で分解した一覧が、稟議書の添付資料に必ず付いています。設計者の1日が「8:30 メール確認(20分)／9:00 図面検索(45分)／9:45 BOM修正(60分)／10:45 設計変更通知の影響範囲調査(90分)…」のレベルで書かれていて、各タスクに想定工数と発生頻度(週X回)が記載されている状態です。

このレベルで分解されていると、AI支援が効く業務(図面検索、BOM差分抽出、設計変更通知の影響範囲調査)と、AIが補助しかできない業務(設計判断そのもの、サプライヤー交渉、品質トラブルの原因究明)を稟議書上で切り分けられます。「年間総工数のうちAI支援対象は約X%、月間Y時間、年間Z時間」と数値が積み上がります。決裁者が「うちの設計者は何にどれだけ時間を使っているのか」を1枚で見られる状態が、稟議の通る組織の標準装備です。

分解されていない組織では、稟議書に「設計工数を30%削減」とだけ書かれます。決裁者は「30%の根拠は」と問い、現場は「他社の導入事例平均」と答え、稟議は止まります。

設計者の業務時間の約4割は、図面を探す・改訂を追う・関係者に確認する——この3つで溶ける。稟議書の「業務分解の解像度」はここから始まる。

設計部長が知らないと損する、図面検索の本当のコスト——年間1,200時間が消える理由

軸2: 責任配置——投資主体は経営、業務再設計は現場、運用責任は両者

稟議が通る組織は、業務OS導入の責任配置が稟議書段階で明示されています。投資判断の責任は経営(投資金額の決裁ライン)、業務再設計の責任は現場部門長(設計部長、調達部長)、運用後のKPI管理責任は両者の合議——という三層構造を、稟議書の組織体制ページに書きます。

三層構造が曖昧な組織では、導入後に「AIが期待通り動かない」となったとき、責任の押し付け合いが起きます。情シスは「現場が使いこなしていない」、現場は「情シスが選んだツールが業務に合っていない」、経営は「両方の責任」と曖昧にし、2年目以降の追加投資が止まります。稟議の通る組織は、ここを事前に決めています。「業務再設計の責任は設計部長」「経営は3年間の投資コミットを保証」「半年ごとに業務再設計の進捗を経営に報告」——という運用責任の取り決めが、稟議書段階で組織図化されています。

軸3: 撤退条件——「いつ撤退するか」を稟議段階で書く

稟議が通る組織は、稟議書に「撤退条件」を明記しています。「導入から12ヶ月後の時点で、設計者の業務分解一覧の対象業務において、月間工数削減が想定値の50%を下回っていた場合、追加投資を凍結し、対象業務を絞り込んだ上で再評価する」のような文言です。

撤退条件を書ける組織は、AI投資が「賭け」ではなく「検証」であることを経営層と共有できています。検証である以上、想定通りいかない可能性があり、その場合の意思決定基準を事前に決めておくことが、健全な投資判断です。撤退条件のない稟議は「絶対に成功する前提」で書かれているため、想定通りいかなかった瞬間に、誰も次の意思決定ができなくなります。

撤退条件を書く副次効果として、稟議の通りやすさが上がります。決裁者は「失敗したらどうする」を最も気にしており、撤退条件が事前に書かれていれば、「失敗時のリスクは想定範囲内」と判断できます。撤退条件のない稟議は、決裁者にとって「無限責任」と映ります。

稟議書のビフォー・アフター——3軸を入れると何が変わるか

3つの軸を稟議書に入れる前と後で、決裁者との対話がどう変わるかを比較します。

項目	3軸を入れる前の稟議	3軸を入れた後の稟議
投資効果の根拠	「他社事例で30%削減」	「自社設計者の業務分解一覧から、対象業務X時間/月→Y時間/月の根拠あり」
決裁者の質問	「うちでも同じ効果が出るのか」	「対象業務の優先順位は妥当か」
失敗時のシナリオ	言及なし	「12ヶ月時点で50%未満なら凍結→対象絞り込み」
運用責任	情シスと現場で曖昧	業務再設計=設計部長、運用KPI=合議、投資=経営
2年目の追加投資判断	都度ゼロから議論	稟議書の撤退条件を満たしたか/超えたかで自動判定

3軸を入れる作業は、稟議書の見栄えを整える作業ではなく、組織として意思決定するための言語を業務側で生成する作業です。この作業ができる組織は、業務OSの導入を「単発の投資」ではなく「3〜5年の業務基盤投資」として扱える状態にあります。

OSと呼ぶ理由——個別ツール導入と何が違うのか

2026年は産業AIが「実証フェーズを終えた」年と位置づけられる。投資判断の基準も「PoCの成否」から「業務全体での累積効果」に変わる。

Hannover Messe 2026が示した「産業AIは実証フェーズを終えた」

図面管理ツール、見積支援ツール、BOM管理ツールを個別に導入してきた製造業から見ると、「業務OS」という言葉は新たなバズワードに見えるかもしれません。実際には逆で、個別ツールを20本入れても業務が変わらなかった反省から出てきた概念です。

OSと呼ぶ理由は、個別アプリケーション(図面検索、BOM差分抽出、設計変更通知の影響範囲調査)が、共通の業務データ(図面、部品表、設計変更履歴)と共通のAI判断層の上で動く構造を指すからです。Windows上で複数のExcelとWordが同じファイルを開けるのと同じく、業務OS上で複数の業務エージェントが同じ業務データを読み書きします。「業務基盤」「実装プラットフォーム」と呼んでも構造は同じです。

稟議の文脈で重要なのは、OSという捉え方をすると投資の単位が「個別ツール×N本」から「業務基盤×1本」に変わる点です。個別ツール積み上げは効果も個別計測が必要で稟議が複雑になります。業務基盤は単一投資単位で、効果計測も業務全体で1つです。決裁者にとって判断しやすい構造になります。

自己診断ミニチェックリスト——稟議が通る組織への距離

貴社の現状が、業務OS稟議が通る組織にどれだけ近いか、5項目で自己診断してください。3つ以上「いいえ」がある場合、稟議書を書き始める前に、業務側の整理から着手することをお勧めします。

• 設計部・調達部・品質部の主要業務を、90分単位で分解した業務一覧が現存する(過去1年以内に更新されたもの)
• 各業務の発生頻度(週X回)・想定工数(分)・現状の担当者数が、稟議書に添付できるレベルで整理されている
• 過去のIT投資稟議で、撤退条件を明記したものがある
• 業務再設計の責任者が、システム部門ではなく現場部門長として明示できる
• 3〜5年の業務基盤投資として、複数年予算をコミットした実績(または可能性)がある

反論への先回り——「うちは内製で十分」と言われたら

「業務OSは外部に頼まなくても、社内のDX推進部とエンジニアで内製できる」という反論があります。この反論に対する誠実な答えは、内製で十分な組織と、外部支援が効率的な組織が分かれる、というものです。

内製で十分なのは、(1)社内に業務分解ができる人材(現場業務を90分単位で言語化できる人)が複数おり、(2)エンジニアリング部門にAIエージェント開発経験者が3名以上おり、(3)業務再設計の責任者を現場部門長から明示的に置ける、という3条件が揃っている組織です。この組織は、外部支援なしでも稟議書の3軸を埋められます。

3条件のいずれかが欠ける組織では、内製を始めても稟議書の3軸が埋まらず、「とりあえず使ってみる」段階で止まります。2年目に「効果が見えない」と評価され、3年目の追加投資が落ちる流れです。最初の業務分解と稟議書設計を外部支援に依頼する方が、結果的に内製化までの時間が短くなる場合があります。外部支援の役割を「ツールを売ること」ではなく「業務分解と稟議書設計のテンプレート提供」と整理すれば、内製と外部支援は対立しません。

「ChatGPTで足りる」という反論については、汎用AIは個別業務の便利ツールとして有効ですが、業務基盤の継続運用と組織横断のデータ連携には別の設計が必要、というのが現場の実感です。

次のアクション——稟議書の設計から始める

業務OS導入を検討している経営層・DX推進担当者の方には、技術選定よりも先に、稟議書の3軸(業務分解・責任配置・撤退条件)を貴社の言葉で書ける状態にすることをお勧めします。書ける状態になれば、技術選定はその後で十分間に合います。書けない状態で技術選定から始めると、ベンダーの言葉で稟議書が書かれてしまい、決裁者の質問に答えられなくなります。

稟議書の3軸を貴社の言葉で書く作業を、経営層と現場部門長の合議で進める90分の戦略相談を無料で承っています。貴社の業務分解の現状、責任配置の検討状況、撤退条件の設計案を、業務OS導入の文脈で整理します。

関連して読みたい記事

• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体
• 設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤
• 設計DRが形骸化する5つの理由と、AIエージェントで補える部分・補えない部分