生成AIをめぐる議論は、しばしば「これまでと断絶した革命」として語られる。しかし業務の情報化という視点で眺めると、生成AIは突然現れたわけではない。ISO9001・TQM・BPRの流れをIT化した BPM（Business Process Management）、その実行基盤としての BPMS（Business Process Management Suite）、そこから分岐した RPA・Process Mining・Low-Code という一連の系譜の、延長線上にある。
本稿の主張は単純だ。BPMSがたどった「壮大な理想 → 頓挫 → 定型業務への着地」という歴史は、生成AIの現在地を読む最良の補助線になる。そして歴史を重ねて見たとき、生成AIには「同じ道をたどる部分」と「決定的に異なる部分」の両方が見えてくる。その境界を見極めることこそ、AI時代の業務設計の本質的な課題だと考える。
BPMは「考え方」として定着し、BPMSは頓挫した
BPMは、営業から見積・承認・受注・製造・請求・入金へと続く業務の流れを、属人的な運用ではなく「プロセス」として管理する経営手法である。個々の担当者の頑張りではなく、プロセスそのものを管理・改善の対象に置く。この発想自体は大企業ではほぼ完全に定着した。BPMN（Business Process Model and Notation）という記述標準も、IT部門や業務設計者の共通言語として普及している。
問題は「考え方」ではなく「実装」の方だった。2005年から2015年ごろ、SAP・IBM・Oracle・富士通・NEC・日立といった大手が一斉に BPMS製品を売り込み、「業務はすべてフロー化され、BPMSの上で実行される」という構想が語られた。代表的な製品には Appian、Pega、IBM BPM、Bizagi、Bonita、Camunda、Oracle BPM、SAP Signavio、ServiceNow、Nintex などがある。「業務＝フロー」という世界観が支配的で、稟議・申請・承認をシステムが一元管理し、Excelとメールを業務から追い出すことが理想とされた。
ところが現実は甘くなかった。最大の障害は、人間はフロー通りに仕事をしないという単純な事実である。同じ営業案件でも、A社は通常対応、B社は特別対応、C社は役員決裁、D社は海外対応と、条件ごとにフローが分岐する。さらに例外・特例・担当者判断・電話・メール・チャット・会議といった「フロー図に描かれない実務」が大量に挟まる。BPMSは一本道の処理は得意だが、実際の業務は網の目である。ここに埋めがたいギャップがあった。
結果として企業は「全社をBPMSで統一管理する」という理想を諦め、経費精算・休暇申請・購買申請・契約管理・稟議・品質管理といった定型業務の一部分だけを BPMS化する方向に落ち着いた。BPMSに関する系統的文献レビュー（arXiv:2312.00442, 2023）でも、BPMSは「利用者とタスクを結び業務を自動化する技術」として学術的関心を集めつつ、その適用は特定領域にとどまってきた実態がうかがえる。
主役の座を奪った RPA・Process Mining・Low-Code
理想が縮小する一方で、周辺技術が主役の座を奪っていった。
2016年ごろから RPA（UiPath、Automation Anywhere、Blue Prism）が爆発的に普及する。BPMSでプロセスそのものを作り直すより、既存の画面を自動操作した方が速い。つまり関心が「プロセス改善」から「現場改善」へ移った。
次に登場したのが Process Mining である。ERP・SAP・Salesforce などのログから、机上のフロー図ではなく「実際に業務がどう流れているか」を自動で復元・可視化する。これはBPMにとって大きな転換点だった。人間が書いた理想のフローではなく、システムに残った事実から現実を再構成するという、発想の逆転である。
そして Low-Code の時代が来る。Appian、Pega、OutSystems、Mendix、ServiceNow、Power Platform といった製品は、もはや「BPMS」というより「Low-Code Platform」であり、フロー・画面・DB・API・AIまで一通り作れる。BPMSはその一機能に格下げされた。
2025年から2026年には、生成AI・エージェントAIの波が新しい局面をもたらしつつある。固定フローの中の「判断」までAIが担い、請求書を読む、AIが分類する、必要なら承認する、AIがメールを作成する、担当者が確認する、送信する、といった半自律的なプロセスが構想され始めた。
この方向は学術的にも定式化されつつある。Dumas・Milani・Chapela-Campa らの position paper「Agentic Business Process Management Systems」（arXiv:2601.18833, 2026、BPM’2025 AI4BPMワークショップ発表）は、BPMの進化を「自動化の波」の連続として捉えたうえで、生成AI・エージェントAIの波は従来と質的に異なると論じる。焦点が automation（自動化）から autonomy（自律）へ、design-driven（設計主導）から data-driven（データ主導）へと移り、Process Mining が築いた基盤の上でエージェントがプロセスの状態を感知し、改善機会を推論し、実行する。彼らが提唱する A-BPMS は、完全に人間主導のプロセスから完全自律のプロセスまでを「連続体」として扱える基盤だとされる。
注目すべきは、この最先端の学術ビジョンでさえ「すべてを自律化する」とは言っていない点である。人間主導から自律までの連続体を支えること、その境界のガバナンスを再定義することが課題だとしている。BPMSの歴史が教えた「全部は無理」という教訓が、そのまま組み込まれているのだ。
生成AIは同じ道をたどるのか
BPMSは登場時に「会社全体が変わる」と言われ、最終的には稟議・申請・経費といった定型業務に落ち着いた。生成AIも「AIが経営を変える」と言われているが、実際にはまず定型業務 ── メール作成、議事録作成、資料要約、FAQ回答、コード生成、文書分類 ── から普及している。歴史は反復する可能性が高い。
そして両者の失速には共通の根本原因がある。現実世界の情報が完全ではないことだ。BPMSが全社適用に失敗したのも、生成AIが判断領域で苦戦するのも、技術そのものの能力不足というより、入力となる情報が欠落し、背景が記録されず、判断理由が当人にも説明できず、正解データが存在しない、という現実側の不完全さに起因する。多くの議論はAIの「賢さ」に注目するが、ボトルネックはしばしばAIではなく世界の側にある。
ただし、生成AIを BPMSの単なる焼き直しと見なすのは誤りである。決定的な違いが一つある。扱える対象の幅だ。BPMSが扱えたのは構造化された「フロー」だけだった。これに対し生成AIは、文章・図面・会議記録・メール・法律・論文といった非構造の情報を扱える。これは質的な拡張である。フローに落とせなかったからこそ BPMSが取りこぼした領域 ── 例外処理、文脈依存の判断、多部門の調整 ── に、生成AIは少なくとも「触れる」ことができる。
とはいえ、触れられることと担えることは違う。営業判断・投資判断・経営判断・暗黙知といった領域では、生成AIは急に苦しくなる。理由は前述の通り、情報の欠落、背景の未記録、理由の説明不能、正解データの不在である。生成AIは判断の「材料」を扱えるが、材料が欠けている領域では、扱えること自体が助けにならない。
二つの生産性を分ける
ここから実務的な含意を引き出すために、「生産性向上」という言葉を二つに分けたい。
第一は処理速度の生産性である。文書を書く、検索する、集計する、翻訳する、プログラムを書く。ここは生成AIが極めて得意で、時間は確実に短縮される。いま世の中が「生産性向上」と呼んで評価しているのは、ほぼこの第一である。「議事録が30分短縮」「メールが5分で書ける」といった効果は本物だ。
第二は意思決定品質の生産性である。この案件を受けるべきか、この研究を続けるべきか、この設計でよいか、どこへ投資するか。経営者が本当に困っているのはこちらだが、ここは生成AIだけでは依然として難しい。
重要なのは、この二つを混同したまま「生成AIで生産性が上がった」と語ると、議論が雑になることだ。正確には、構造化できる仕事と情報整理では生成AIは大きな生産性をもたらすが、情報が欠落し判断が本質となる領域では、生産性向上よりも「判断材料を整理する支援」に価値がある、と分けて語るべきである。
この整理は、「生成AIの生産性向上など、BPMやRPAで効率化できた部分を少し速くしているだけではないか」という懐疑論への応答にもなる。第一の生産性についてはその懐疑は半ば正しい。しかし第二の生産性 ── 判断材料の整理という支援 ── は、BPMSにもRPAにもできなかった新しい価値であり、ここを見落とすべきではない。
Explainable AI ではなく Auditable AI
第二の生産性、すなわち判断の領域に踏み込むと、避けて通れない問題が出てくる。判断の説明可能性である。ここで一つの論点を提示したい。求めるべきは「説明可能性（Explainable AI）」ではなく「監査可能性（Auditable AI）」ではないか、という視点だ。
認知科学が古くから指摘してきたように、人間は「なぜそう判断したか」と問われると、本当の理由を思い出すのではなく、もっともらしい理由を構成してしまうことがある。嘘ではない。本人もそれが理由だと思っている。しかし実際の判断過程は意識にのぼらず、後から物語が作られる。心理学でいう記憶の再構成、確証バイアス、後知恵バイアスである。
これは BPMSプロジェクトでも起きた。現場に「業務フローを書いてください」と頼むと、現場は理想的なフローを書く。だが実際には「ここは部長に電話」「ここは経験で判断」「ここは様子を見る」が大量にある。出来上がる BPMNは実態ではなく説明用のモデルになる。多くの BPMS失敗の一因はここにあった。
そして生成AIに「なぜその判断をしたか説明せよ」と命じても、AIは見えている情報からもっともらしい説明を生成する。その説明が本当にその出力を生んだ要因かは分からない。人間もAIも、後付けの説明を作る危険を共有しているのだ。「AIはハルシネーションするが人間は信頼できる」という二元論は成り立たない。どちらも不完全な判断主体である、という前提に立つべきである。
ならば、説明を問うのをやめ、証拠を残せばよい。判断の理由（後付けになり得る）ではなく、「何を参照し、何を参照しなかったか」という観測事実を記録する。参照したものは提案書・過去案件・顧客情報・技術資料、参照しなかったものは最新の競合情報・担当営業との面談・現場視察、というように。これは理由ではなく観測事実であり、後付けができない。人間に対しても「どの情報を見たか、見ていない情報は何か、他の可能性は検討したか」を確認し、AIにも同じ質問をする。そうすれば、人間にもAIにも同一のレビュー基準が適用できる。
ここで二点、批判的な補足を加えておきたい。この二点を欠くと、議論は甘く見える。
第一に、「Auditable AI」は新しい発見ではない。既存の概念群 ── 監査証跡（audit trail）、来歴管理（provenance）、データリネージ（data lineage）、意思決定来歴（decision provenance）、モデルカード、human-in-the-loop ガバナンス ── とかなり重なる。したがって独自性は、技術としての監査ログではなく、人間の判断もAIの判断も同じ土俵に乗せてレビューするという運用思想の側にある、と位置づけるのが正確だろう。
第二に、参照リストは透明性の半分しか埋めない。「何を参照したか」は分かっても、「それをどう重み付けして結論に至ったか」は参照リストからは出てこない。同じ資料を見ても、そこから何を重視するかで結論は変わる。したがって Auditable AI は入力の透明性を保証するが、判断の重み付けの透明性は依然として残された課題である。この限界を認めたうえで、なお参照リストが有用なのは、それが最も安価で最も改竄しにくい第一の防衛線だからだ、という論立てにするのが誠実である。
第三者レビューを再定義する
以上を踏まえると、AI時代のレビューは次のように再定義できる。レビューとは「推論の前に証拠を確認する行為」である。「この設計はダメだ」と結論から入るのではなく、「この資料を見た、この資料はない、この観点は確認できない」から入る。
この観点は、判断主体が人間かAIかを問わない。これまでは「人間がAIをチェックする」という一方向の構図で語られがちだった。しかし正しくは、AIの判断も人間の判断も、ともにレビュー対象である。判断主体が誰かではなく、判断品質そのものをレビューする。「人間だから正しい、AIだから危険」ではなく、「どちらも不完全な判断主体である」という前提で、レビューと意思決定の仕組みを設計し直す。これがAI時代の組織設計の出発点になる。
生成AIの本当の価値も、この文脈で捉え直せる。AIの価値は「判断する」ことではなく「判断材料を整理する」ことにある。営業会議でAIが「この案件はAです」と結論を出すのではなく、「この案件について技術資料・過去案件・契約条件・顧客履歴を整理しました」と材料を並べる。理由は人間が考える。これだけでも第二の生産性は確実に上がる。
結論 ── 境界をどう設計するか
BPMの歴史を補助線として引くと、生成AIの現在地は次のように整理できる。生成AIは、BPMやRPAを置き換える技術ではない。「構造化できるところまではAIが担当し、構造化できない判断を人間が担当する」という境界を、これまで以上にはっきりと可視化する技術である。BPMSは業務プロセスを管理し、RPAは作業を自動化し、Process Mining は実態を可視化した。生成AIはさらにその一段上にある問い ── 判断の品質をどう担保するか ── を、人間とAIの双方に対して突きつける。
この境界をどう設計するか。判断そのものを代行するのではなく、その判断がどの証拠に支えられ、どこに空白があるのかを可視化する。人間もAIも後付けの説明を作る存在だと認めたうえで、両者を同じ基準でレビューする仕組みを用意する。これは「AIを信用するため」ではなく、「AIを、そして人間を、適切に疑うため」の仕組みである。その境界をどう設計するかこそが、AI時代の本当の設計課題なのだと考える。