製造業のAI受託案件で、PoC（概念検証）まではうまく走ったのに、本導入の稟議に至らず1年後に立ち消えになる──このパターンが多すぎる、と感じている経営企画・情シス部門の方は少なくないはずです。1,500万円規模の個社別AIエージェント受託案件は、技術選定の巧拙よりも、もっと前段にある「業務分解能力」で勝負がついているのが実態です。本記事では、当社が中堅製造業のAI受託支援で繰り返し観察してきた「実装まで到達する企業に共通する3つのパターン」を抽出し、自社が今どの位置にいるかを判定するためのフレームを提示します。読者の所属部門が経営企画でも情シスでも設計部でも、稟議書を書き始める前に確かめてほしい3点です。

なぜAI受託案件はPoC止まりで消えるのか

製造業の現場でAIエージェントの受託開発が走り始めると、最初の3か月はおおむね順調に進みます。生成AIのデモは派手で、経営層への報告では「設計者の図面検索が10分の1になりました」「FMEAの初稿が30分で出ます」といった成果が並びます。ところが半年後、本導入の稟議に向けた折衝に入ると、急に話が前に進まなくなる。「結局あれは何の業務に効くんだっけ」「現場が使い続けてくれるか分からない」「3年後にこのコードを誰が触るのか」といった、技術選定とは別の論点が次々に立ち上がります。

当社が2024年から2026年にかけて関わった製造業のAI受託案件を振り返ると、PoC終了後12か月時点で「業務に組み込まれ、稟議で本予算が降りている」割合は約4割でした。残りの6割は、PoC成果物が業務ファイルサーバの片隅に残ったまま、誰も触らない状態で1年が過ぎていました。失敗した側の共通項を分解すると、技術スタックの選定ミスでも、ベンダー側の実装力不足でもなく、ほぼ全てが発注側の業務分解の解像度に起因していました。

業務分解の解像度とは、自社の業務を「設計部の業務」のような部門単位ではなく、「サプライヤーから返ってきた見積メールから単価と納期を抜き出してExcelの相見積比較表に転記する作業」のような動作単位まで言語化できているかを指します。この粒度まで分解できている企業は、AI受託の要件定義書を「業務工程ベース」で書けます。書けない企業は、「ChatGPTでFMEAを書いてください」「画像認識で外観検査をやってください」といった、業務というより機能発注になってしまいます。機能発注はPoCは作れますが、本導入の稟議では「で、それは結局どの業務をいつ・誰がやらなくてよくなるのか」に答えられず、決裁が止まります。

本論：実装まで到達する企業に共通する3つのパターン

当社の支援案件のうち、PoC終了後に本予算の稟議が通り、業務に組み込まれて12か月以上運用が続いた案件には、技術選定や業種を超えて、組織側に3つの共通パターンがありました。順に解説します。

パターン1：業務分解が「動作単位」まで降りている

1つ目は、要件定義の入口時点で業務が動作単位（図1の第3〜4階層）まで分解されているパターンです。例えば調達部のAIエージェント案件であれば、「相見積業務」という業務群レベルではなく、「サプライヤー10社から返ってきた見積メールの本文と添付PDFから、品目コード／単価／納期／支払条件を抽出してExcelテンプレートのB〜E列に転記する」という工程レベルまで分解できている状態です。この粒度で書き下ろせる組織は、AI受託ベンダーに対して「この工程の代行をエージェントが担い、人は単価査定の判断のみ残す」という形で発注ができます。要件のブレが少ないため、PoC成果物がそのまま本番運用の要件になり、稟議書の「業務効果」欄も具体的に書けます。

逆に、業務群レベルでしか書けない企業は、PoCで何ができたかは見せられても、「それで来期から月に何時間が浮きますか」「浮いた時間で誰が何をしますか」という問いに答えられず、本予算化が止まります。経営層から見ると「PoCのデモは凄かったが、要するに何が変わるのか」が言語化されていない状態に映ります。

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

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

引用記事が指摘するように、既存の業務システムは「業務の実行」までは踏み込んでいません。AIエージェントは初めて業務の実行に踏み込む層であり、だからこそ実行する業務の粒度が要件定義の精度を決めます。業務分解の解像度が低い組織は、AIエージェントを「便利ツール」として位置づけてしまい、業務OSとしての受け皿を持てません。

パターン2：経営×情シス×現場の三者で稟議書を共同編集している

2つ目は、稟議の決裁プロセスに経営企画／情シス／業務現場の三者が、設計段階から参加しているパターンです。多くの企業では、AI受託の稟議は「現場が起案→情シスが技術精査→経営が決裁」という直列の流れになりがちです。この直列モデルは、現場が起案した時点で「何の業務をどう変えるか」が決まってしまい、情シスが見るのは技術スタックの妥当性、経営が見るのは投資対効果の最終数字、という分業になります。結果として、3者の誰も「3年後に社内に残る業務資産」の観点で稟議書を書きません。

一方、実装到達率が高い企業では、PoC着手前の業務分解の段階から経営企画と情シスが現場に張り付いています。経営は「この業務に組み込まれた知識が、3年後にも会社の資産として残るか」を問い、情シスは「このエージェントが落ちたときの暫定運用は誰が持つか」を問い、現場は「動作単位で何が代行されるか」を書きます。三者の問いが揃った稟議書は、評価軸が単年度の工数削減金額にとどまらず、累積資産化／業務継続性／撤退コストにまで広がります。

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

経営企画から見たAI投資——業務OSを稟議で評価する5つの観点

三者合議型の稟議は時間こそかかりますが、決裁後の本導入推進力が段違いです。経営が業務分解の現場感を共有しているため、追加投資判断も早く、撤退判断も恣意的にならない。情シスは技術運用の覚悟ができているため、PoCベンダーから運用ベンダーへの引き継ぎで業務が崩れません。

パターン3：撤退設計と人間側のオーナーシップを最初から組み込んでいる

3つ目は、AIエージェントが止まった／陳腐化した／ベンダーが事業継続できなくなった、といった事態を最初から想定した撤退設計を要件定義書に含めているパターンです。具体的には、(a) エージェント停止時の暫定運用フローを人間側でも実行できる手順書として並走で整備する、(b) エージェントが扱うデータと業務KPIのオーナーシップを社外ベンダーではなく自社の業務部門に置く、(c) 業務知識の暗黙知をエージェントに集約しすぎず、現場OJTで継承する経路も維持する、の3点が要件に含まれています。

撤退設計を最初から組み込んだ案件は、結果として「撤退しなくて済む」案件になります。なぜなら、撤退時のリスクを定量化できる組織は、現場でも経営でも「このエージェントは何のリスクを引き受けるための投資か」が明確で、運用継続のメンタルモデルがブレないからです。逆に撤退設計のない案件は、エージェントが業務クリティカルになった瞬間に「誰も止められないし、誰も改修できない」状態に陥り、3年目に大規模リプレース費用が突発的に必要になります。

「現場発のAI内製依頼」を全部やる／全部止めるの二択で捌くと、シャドーAI繁殖か業務停滞のどちらかが起きる

内製と外注の境界線——設計OS構築で「自社で握るべき層」「任せていい層」を分ける3つの軸

撤退設計を組み込めるかどうかは、受託案件の中で「自社が握るべき層」を最初から線引きできているかと同じ問いです。エージェントの実行ロジックは外注してよいが、業務KPIと業務知識のオーナーシップは絶対に外注しない──この線引きが要件定義書の段階で書かれていることが、3年後の業務継続性を決めます。

3パターンの組織能力チェック

3パターンを連動させる判断フロー

3つのパターンは独立ではなく、順に積み上がる構造になっています。業務分解が動作単位まで降りていなければ、三者合議の論点が定まらず、稟議書の評価軸も曖昧なまま。撤退設計を組み込もうとしても、業務分解と稟議が揃っていなければ、撤退時の暫定運用すら書けません。下図は、AI受託案件が実装に到達するまでの判断フローを、3パターンの分岐点として整理したものです。

flowchart TD
    A[受託案件着手] --> B{パターン1
業務分解は
動作単位まで降りているか}
    B -- いいえ --> C[PoCで雲散霧消
本予算化に届かない]
    B -- はい --> D{パターン2
経営・情シス・現場の
三者合議は成立しているか}
    D -- いいえ --> E[部分導入で停滞
社内政治化のリスク]
    D -- はい --> F{パターン3
撤退設計と人間側の
オーナーシップはあるか}
    F -- いいえ --> G[単発ツール化
3年目にリプレース問題]
    F -- はい --> H[業務OSとして定着
1,500万円規模が業務改善ROIに転化]
    classDef start fill:#1D4ED8,stroke:#1E3A8A,color:#FFFFFF,font-weight:bold
    classDef decision fill:#DBEAFE,stroke:#1D4ED8,color:#1E3A8A
    classDef fail fill:#FEF2F2,stroke:#B91C1C,color:#7F1D1D
    classDef success fill:#D1FAE5,stroke:#065F46,color:#064E3B,font-weight:bold
    class A start
    class B,D,F decision
    class C,E,G fail
    class H success

自社のいまを判定する5項目セルフチェック

受託発注を検討する前に、自社が3パターンのどの段階にいるかを判定するための5項目です。3つ以上「いいえ」なら、いきなり受託発注に進むのではなく、業務分解ワークショップから始めるほうが結果的に短期で本導入に到達します。

• 業務改善対象の業務について、「サプライヤー名と単価をExcel A列に転記する」レベルの動作単位の記述が文書化されているか
• AI受託の稟議書に、経営企画／情シス／業務現場の3者がそれぞれ評価軸を書く欄が用意されているか
• PoC完了時点で、本導入時のKPIオーナー（人）が業務部門の誰になるかが決まっているか
• エージェントが3か月間停止したときの暫定運用手順が、人間側でも実行可能な形で並走整備される計画があるか
• 3年後にAIエージェントを別ベンダーに切り替える場合の、データ・業務知識・運用権限の引き渡し条件が要件定義書に明示されているか

反論：「分解できない企業は受託発注すべきでない」のか

ここまでの議論を読むと、「業務分解の解像度が低い企業はAI受託に手を出すな」と受け取られかねません。しかし、当社の立場は逆です。業務分解の解像度を上げる作業こそ、AI受託支援の最初のフェーズに含めるべきだと考えています。実装到達率が高い企業も、最初から動作単位で業務を書けたわけではなく、PoC着手前の2〜4か月で業務分解ワークショップを通じて解像度を上げてきた組織が多い。むしろ受託支援を業務分解と切り離して「実装だけ請け負ってください」と発注する形が、最も失敗確率が高い。

同じく「ChatGPTやCopilotで十分では」という反論もよく聞きます。汎用AIツールは個人の生産性ツールとしては優秀ですが、業務として継続運用する層には届きません。継続運用の層では、業務KPIが計測されること／業務オーナーが固定されていること／引き継ぎ可能な業務手順として残ること、の3条件が必須になります。汎用ツールはこの3条件を満たさないため、結局は個人技術として消費されて終わります。業務分解と撤退設計を組み込んだ受託案件は、この3条件を要件定義書のレベルで担保するという点で、汎用ツール導入とは別物です。

もう1つの反論として、「ベンダーロックインが怖い」という声があります。これは正当な懸念で、パターン3（撤退設計）が要件定義書に組み込まれているかが、まさにロックイン回避策そのものです。撤退設計のない受託案件はロックインに帰着しますが、撤退設計を最初から要件にすれば、ベンダー側もそれを前提に技術選定するため、ロックインリスクは実装の問題ではなく要件定義書の問題に還元できます。

次のアクション：受託発注前の業務分解診断

本記事のセルフチェック5項目で3つ以上「いいえ」だった場合、いきなり受託発注に動くのではなく、対象業務の分解解像度を上げるワークショップから始めることをお勧めします。当社では、製造業AI受託の事前ステップとして、業務分解の現状解像度を診断し、3パターンのどこから着手すべきかを30分でご一緒に整理する無料セッションを設けています。受託案件を「実装の発注」ではなく「業務OSの構築プロセス」として組み立て直すための入口としてご利用ください。

関連記事

• 経営企画から見たAI投資——業務OSを稟議で評価する5つの観点（パターン2の稟議観点をさらに深掘り）
• 内製と外注の境界線——設計OS構築で「自社で握るべき層」「任せていい層」を分ける3つの軸（パターン3の撤退設計と地続きの論点）
• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体（受託案件を業務OSとして定着させる前提の概念）

FAQ

Q1. 業務分解は具体的にどこまで降ろせばよいですか

A1. 「人が30秒〜5分で繰り返している作業」が単位として書けると、AIエージェントの代行範囲を定義しやすくなります。「サプライヤー名と単価をExcel A列へ転記する」はこの粒度の典型例です。さらに細かく「文字列を選択する」「Ctrl+Vで貼り付ける」まで降ろす必要はありません。動作の起点と終点が明確で、人の判断が入る分岐点を識別できる粒度を目安にしてください。

Q2. 三者合議は時間がかかりすぎませんか

A2. 確かに合議プロセスの組成には3〜6か月かかります。ただし、直列の決裁プロセスでも本予算稟議が止まれば結果として同じだけ時間を消費し、しかも本導入に到達できないリスクが残ります。合議プロセスは「決裁時間」ではなく「稟議書の評価軸を揃える時間」と位置づけると、本導入後の運用速度が早まる投資として理解できます。

Q3. 撤退設計を要件に入れるとベンダーが嫌がりませんか

A3. 撤退設計を嫌がるベンダーは、長期運用前提の支援を引き受ける能力がない可能性が高いと判定できます。むしろ、撤退設計を要件として受け入れるベンダーは、自社の技術選定とデータ設計に対する責任の取り方が明確で、結果として長期運用に強い構造のエージェントを構築します。要件として明示することで、ベンダー選定の試金石になります。

Q4. 3パターンすべてを満たさないと受託発注は無理ですか

A4. すべてが満たされている必要はありません。パターン1（業務分解）が第3階層まで降りていれば、パターン2と3は受託支援の中で並走で組成することが可能です。一方、パターン1が第1〜2階層止まりの状態で発注に踏み切ると、パターン2・3を後から差し込んでも軌道修正のコストが大きくなります。順序としては、業務分解の解像度確認→三者合議の組成→撤退設計の要件化、の順で着手するのが現実的です。