⚠️ この記事は、BPO業界出身の非エンジニアが書いています。用語の誤用があれば、やさしく教えてください。また以前同じ記事を出して、誤りが酷かったので、再投稿しました。
はじめに：市場の重心は「人」から「プロダクト」へ
まず、BPaaSとは何かを先に押さえます。
BPaaS（Business Process as a Service） とは、給与計算や経費精算といった業務プロセスそのものを、クラウド経由のサービスとして提供する形態です。利用企業は自社で人とシステムを抱える代わりに、提供者が用意した「標準化された仕組み（ソフトウェア＋運用）」をサブスクリプション的に利用します。SaaSが「ソフトウェアをサービス化」したものだとすれば、BPaaSは「業務オペレーションごとサービス化」したものだと考えると分かりやすいです。
つまりBPaaSの核心は、「標準化された業務を、複数の顧客に同じ形で提供する（横展開する）」 という点にあります。この「横展開できるか」が、本記事を通じての論点です。
次に市場です。調査会社ごとに定義・対象範囲が異なるため額面の厳密な比較はできませんが、傾向だけ示します。
| 区分 | 規模 | 成長率 | 出所 |
|---|---|---|---|
| 国内BPO市場（事業者売上高ベース） | 2024年度 約5兆786億円（前年比+4.0%） | CAGR 約4%前後 | 矢野経済研究所 |
| グローバルBPaaS市場 | 2024年 約661億USD → 2032年 約1,721億USD | CAGR 約12.7% | Data Bridge Market Research |
| グローバルBPaaS市場 | 2025年 約959億USD → 2033年 約1,931億USD | CAGR 8.8% | Grand View Research |
📌 数字の読み方について
BPO市場（兆円・国内）とBPaaS市場（USD・グローバル）は、地域も定義も異なるため、絶対額を直接比べることはできません。
また成長率も調査会社によって幅があります（Data Bridge系で約12〜14%、Grand View系で約8.8%）。
ここで読み取っていただきたいのは、どの調査でもBPaaSがBPO本体（CAGR約4%）を上回る速度で伸びている、という傾向の一致だけです。
1. ずっと不思議に思っていたこと
BPO業界にいて、ずっと不思議に思っていたことがあります。
客先ごとに業務を分析し、手順書を作り、人を育て、品質を安定させる。そしてまた次の客先で、ほぼ一から同じことをやる。なぜ「すでにあるもの」を再利用できないのか。なぜ毎回スクラッチになるのか。
この「作った業務設計を再利用・標準化して提供したい」という発想を、サービスの形にしたものが、まさに前述のBPaaSです。標準化した業務をサービスとして横展開すれば、毎回のスクラッチから抜け出せる——理屈の上ではそうなります。
ここで、私はひとつ誤解をしていました。
「BPOはパッケージとして売れない」わけではありません。パッケージは作れます。実際、各社が作っています。
問題は、その先にあります。
2. 「BPaaS」と「AI-BPO」は別物です
ここで事例を整理しますが、まず重要な区別をします。最近よく目にする事例には、性質の異なる2種類が混ざっています。
┌────────────────────────────────────────────┐
│ ① BPaaS型（提供形態の話） │
│ 標準化された業務を、複数顧客に │
│ クラウドサービスとして横展開する │
│ 例：クラウド給与計算、経費精算サービス │
│ → 「同じ仕組みを多数の顧客が使う」 │
├────────────────────────────────────────────┤
│ ② AI-BPO型（中の作り方の話） │
│ AIと人を組み合わせて代行業務を効率化する │
│ 例：AI-OCR＋人で請求書処理を代行 │
│ → 「1顧客の業務をAIで省力化する」 │
└────────────────────────────────────────────┘
2025〜2026年に話題になった事例の多くは、実は ②のAI-BPO型 です。
| 事例 | 内容 | 分類 |
|---|---|---|
| LayerX「バクラク」 | 請求書受領業務を、人とAIで代行するAI-BPO | ②寄り |
| TOKIUM | AIとプロスタッフが連携する「経理AIエージェント」 | ②寄り |
| NTTデータ | 資料作成の上流にAIを適用し、既存BPOから追加で約40%の工数削減を実証 | ②寄り |
これらは「AIでどう効率化したか」という中の作り方の話であって、「標準サービスを多数の顧客にどう横展開したか」というBPaaSの提供形態の話ではありません。
一方、給与計算や勤怠・経費精算のクラウドサービスのように、同一の標準フローを多数の企業がそのまま使う形態は、典型的な①のBPaaS型です。ここに両者の差が出ます。
- 標準フローに乗る業務（給与計算など）→ 横展開しやすい＝BPaaSが成立する
- 客先ごとにバラつく業務（個別ルールの多い申請業務など）→ 横展開しにくい＝戻される
つまり「BPaaSが伸びている」と言うとき、伸びの実態が①なのか②なのかを分けないと、議論が噛み合いません。本記事が扱うのは①、「標準化したパッケージは本当に横展開できるのか」 という問いです。
3. 本当の問題：パッケージは作れる。鍵は「戻り」をどう扱うか
パッケージを構築するとき、事前にオブジェクト（業務の構造・データの型・処理の単位）を想定します。給与計算ならこういう項目、申請業務ならこういうフロー、というように。
ところが、現場に入れた瞬間にズレが出ます。
- 事前に想定したオブジェクトの設計が甘く、実際の業務が収まらない
- 客先固有のローカルルールに縛られ、標準フローに乗らない
- 例外処理が想定の何倍もあり、設定変更では吸収しきれない
その結果、パッケージの見直しが多発します。設定変更のはずが改修になり、改修が積み重なって、実質フルスクラッチと変わらない工数になります。
これが、私が現場で見てきた「BPaaSが横展開しきれない」理由です。名前が10年以上前からあるのに現場が手順書と人で回っているのは、パッケージが作れないからではありません。作ったパッケージが現場で戻されるからです。
【理想】
パッケージ ──設定変更だけ──→ 客先A
──設定変更だけ──→ 客先B ＝ 高速横展開
【現実】
パッケージ ──オブジェクト想定が甘い──→ 改修
──ローカルルールに非対応──→ 改修
──例外処理が想定外に多い──→ 改修
↓
実質フルスクラッチ
📚 補足：この「ミスフィット」は研究で指摘されている
パッケージ標準機能と組織の実態とのギャップは、情報システム研究で 「misfit（ミスフィット）」 と呼ばれます。
Soh ら（2000）は、これを data／process／output の3種 に分類し、欧米発のパッケージが前提とする業務構造と、現地のローカルな業務慣行とのあいだで misfit が大きくなることを示しました。
「想定したオブジェクトが甘い」「ローカルルールに乗らない」は、まさにこの misfit にあたります（出典は記事末）。
4. なぜオブジェクト設計は「甘く」なるのか
事前のオブジェクト設計は、明示化できた形式知の範囲でしか作れません。ところが現場には、手順書に書ききれない判断、ローカルルール、例外の嗅ぎ分けが大量にあります。設計時には見えていなかった暗黙知が、実装後に「想定外」として噴き出します。 だからオブジェクトは甘くなり、見直しが発生します。
さらに、「うちは特殊だから」「昔からこうだから」といったローカルルールの正当化が、外部標準との比較を回避させます。標準パッケージを入れようとしても、内向きの参照軸がそれを押し戻します。
📚 補足：現場が標準を「押し戻す」動きも研究されている
標準システムが現場の実態に合わないとき、現場は独自の回避策（workaround）を編み出します。
Davison & Wong（2021）は、グローバル標準システムとローカルな現実との misfit に対して、現場がどのように回避策を生み出し調整するかを分析しています。
「現場がパッケージを戻す」「内向きの理由で標準を押し返す」は、この workaround の現象と重なります（出典は記事末）。
5. 実体験：仕込もうとして、頓挫した話
私はかつて、BPaaS的なものを仕込もうとしたことがあります。SIerとアライアンスを組み、電子申請システム＋RPA＋AI-OCR、そしてBPOの運用枠組みを一体で構築する試みでした。申請を電子で受け、AI-OCRで読み取り、RPAで処理し、判断が要る部分だけ人が見る。標準化された業務基盤の上で複数の対象に横展開する——そういう絵を描いていました。
ところが、大きな制度方針の転換が報じられ、前提が崩れ、計画は頓挫しました。
この経験から学んだことが、この記事の核です。パッケージ化の難しさは、技術ではなく「前提の固定」にあります。 国の制度、客先のローカルルール、業務の暗黙知——これらは外部要因であり、こちらの設計で固定できません。固定できない前提の上にオブジェクトを設計するため、前提が動いた瞬間に見直しが走ります。技術（RPA・AI-OCR・電子申請）はむしろ動いていました。動かなかったのは、前提を固定できるという思い込みのほうでした。
6. では、どう作ればよいのか
ここで、二種類の「戻り」を分けて考える必要があります。
戻りの種類
├─ A. コントロールできない戻り
│ 国の制度変更、大きな方針転換など
│ → 前提が外から崩れる。設計では防げない（受け入れる）
│
└─ B. 備えられる戻り
要件定義段階で出てくる想定外（ローカルルール・例外・認識のズレ）
→ 最初から「出てくるもの」として設計に織り込める
備えられる戻り（B）に対しては、次の設計が効きます。
| アプローチ | 内容 |
|---|---|
| 想定の薄いコア＋厚い設定層 | コアを最小限にし、ローカルルールは設定で吸収する前提で設計する |
| 8割共通・2割個別の明示 | 最初から「2割は個別改修が発生する」と見積もりに織り込む |
| 要件定義段階での戻りループ | 想定外が出た時点でオブジェクト設計に立ち返れる手順を工程に組み込む |
| 暗黙知の事前棚卸し | 設計前に「手順書に書かれていない判断」を現場から吸い上げる |
完全な解はまだありません。ただし、外部要因による戻り（A）は受け入れたうえで、要件定義段階で生じる戻り（B）を設計にあらかじめ組み込むことが、現実的な勝ち筋になります。
7. まだ合流していない二つの品質思想
BPaaSは、SE型の「ゼロ欠陥」思想（コード部分）と、BPO型の「許容誤差設計」思想（HITL＝人が介在する部分）を、一つのサービスの中で同居させています。
SE型品質： ゼロ欠陥を目指す ────┐
├→ BPaaSで合流？
BPO型品質： SLA許容誤差で設計 ──┘
実態：コード部分はSE型（ゼロ志向）、
HITL部分はBPO型（許容誤差）に分裂したまま共存
コードはバグゼロを目指し、人は許容誤差の中で例外を回収します。この二つの品質思想は、まだ合流していません。 ここを設計でどうつなぐかが、BPaaSの完成度を左右します。
8. 平準化されるもの、残るもの
BPaaSが平準化できるのは、コストと定型業務です。一方、ローカルルールへの適応、例外の嗅ぎ分け、前提が動いたときの立て直し——こうした暗黙知の領域は、プロダクトに移そうとしても現場へ戻ってきます。
つまり、移せずに人へ残る暗黙知こそが、その会社の競争力として残り続けます。
📚 補足：「移せない暗黙知」は古典的な指摘
暗黙知のすべてを形式知に変換できるわけではない、という点を、Polanyi は「我々は語れる以上のことを知っている（We can know more than we can tell）」という言葉で指摘しました。
Nonaka の SECI モデルは知識変換を理論化した一方で、その後の議論では「コード化できない暗黙知の残余」が繰り返し論じられています。
プロダクトに移しきれず人へ残る部分があるのは、理論的にも自然な帰結です（出典は記事末）。
おわりに
「BPOはスクラッチしかない」という私の見立ては、間違っていました。パッケージは作れます。問題は、作ったパッケージが、甘いオブジェクト設計とローカルルールによって現場で戻され、実質スクラッチに回帰することでした。その根っこには、固定できない前提の上に設計してしまうという構造があります。
逆にいえば、「戻る」ことを最初から織り込んで設計できれば、BPaaSはまだ十分に可能性のある形態です。
出典・参考文献
- 市場規模（BPO）：矢野経済研究所「BPO（ビジネスプロセスアウトソーシング）市場に関する調査（2025年）」
- 市場規模（BPaaS）：Data Bridge Market Research / Grand View Research 各社レポート（数値は公表時期により更新されるため原典を要確認）
- ミスフィット：Soh, C., Sia, S. K., & Tay-Yap, J. (2000). "Enterprise Resource Planning: Cultural Fits and Misfits: Is ERP a Universal Solution?" Communications of the ACM, 43(4), 47–51.
- ワークアラウンド：Davison, R. M., & Wong, L. H. M. (2021). "The Coordination of Workarounds." Information & Management, 58.
- 暗黙知：Polanyi, M. (1966). The Tacit Dimension. University of Chicago Press.
- 知識変換モデル（SECI）：Nonaka, I. (1994). "A Dynamic Theory of Organizational Knowledge Creation." Organization Science, 5(1), 14–37.