調達の道具を、9つの工程に並べ直した ― SaaS と BPO を同じ表に置くと見えるもの

調達の SaaS と購買 BPO を、同じ工程の表に並べてみた。外資 SaaS 17製品、国内 SaaS 15本前後、購買 BPO 各社。やってみて分かったのは、空いている場所は「誰も作っていない機能」ではなく、「人がやっている仕事」だったということだ。

以下は、その地図をどう作って、どこからこの結論が出てきたかの説明になる。使ったのは2026年8月時点で各社が公表している資料だけで、問い合わせは一切していない。

なぜ並べ直したのか

調達の道具を比べようとすると、いつのまにか製品カテゴリの話になる。Source-to-Pay、P2P、Intake & Orchestration、支出管理、電子帳票。どれもベンダーが自分の位置を説明するために作った言葉で、「うちのどの工程が空いているか」には答えてくれない。

もう一つ困るのは、SaaS の比較記事は SaaS だけを、BPO の紹介は BPO だけを扱うことだ。買う側から見れば「その工程を誰がやるか」は同じ問いなのに、両者が同じ物差しに乗った地図が見当たらない。だから、足りないのが道具なのか人手なのかを判断できない。

そこで製品カテゴリを一度捨てて、工程のほうを先に固定した。使った軸は次の9つ。

このあとの表の記号は、すべて**「各社が自社サイト等でそう公表している」という意味しか持たない。■ は主機能・モジュールとして公表しているもの、△ は上位モジュール内の一機能としての言及または部分的なもの、空欄は公表資料から確認できなかったもの。推測では埋めていない。実装の深さ・使い勝手・優劣は判定していないし、この記事では判定しない**。挙げた数値はすべて各社の発表値で、第三者による検証はしていない。

世界のスイートは、3つの形しかなかった

最初に外資の Source-to-Pay スイート8本を1本ずつ並べたのだが、行がほとんど同じ形になった。製品名で比べる意味があまり無い。形で畳むと3つになる。

A＝SAP Ariba / Coupa / JAGGAER One / GEP SMART / Ivalua / Zycus。B＝Oracle Fusion Procurement（「別」は請求・支払が別モジュール）。C＝Basware。

A の6本は、③探索から⑨分析までをほぼ同じ形で埋めている。 どれを選んでも工程の被覆という意味では似た絵になるので、違いは機能一覧ではなく別のところにある。

B の Oracle だけが、⑦検収を独立したモジュール名で出している。 他の7本では検収は「購買から支払までの流れの中」に埋まっていて、名指しされない。この1点だけで、Oracle は行の形が変わる。

C の Basware は、そもそも別の生き物だった。 請求書処理と e-Invoicing が中核で、上流のソーシングや支出分析を独立モジュールとしては打ち出していない。8本を横一列に「S2P スイート」と呼ぶと、この違いが消える。

そして3つの形すべてで、②仕様策定の列が空いた。 スイートの手前に立つ Intake & Orchestration 層（Zip、Levelpath、Oro Labs、Omnea、Tonkean）と、ソーシング特化（Keelvar、Arkestro、Globality、Fairmarkit）を足した17製品まで広げても、②を主機能として公表しているものを見つけられなかった。たとえば Fairmarkit が公表しているエージェントの並びは、Intake、Supplier Discovery、RFx Execution、Evaluation、Performance & Compliance の5つ。需要を受け取る工程と、見積を出す工程の間が、名前を持たないまま繋がっている。

日本の SaaS は、3つの群に割れている

日本勢の特徴は、3つの群に割れていて、群をまたぐ製品がほとんど無いことだった。

上流に寄る群（調達・購買の専業）

Leaner は購買依頼から一括の見積依頼、自動比較表、支出分析までを公表している。A1A の「RFQクラウド」は見積フォーマットの統一と見積査定を掲げる。ディーコープは1万3千社超の登録サプライヤーを持ち、相見積とリバースオークションを運営する。

ここで、さっきの②の話に戻る。②仕様策定に手を伸ばしていると公表している数少ない製品が、この群にいる。 Leaner は図面情報の読み取りから見積作成を支援すると書き、A1A は見積フォーマットの統一そのものを商品にしている。世界のスイートが空けている列に、日本の専業が部分的に触れている。

下流に寄る群（支出・請求まわり）

⑥発注書の発行と⑦検収書の発行を両方とも明示しているのは、この群ではインフォマートだけだった。 バクラクは発注段階で適格請求書発行事業者かどうかを判定する機能を公表しているが、発注書そのものの発行機能は公表資料から確認できなかった。

通販側から取りに来る群（カタログ購買・間接材EC）

アスクルのソロエル、MonotaRO の ONE SOURCE、Amazon ビジネス、トラスコ中山。この群は①申請・承認と⑥発注を、購買システムではなく買う場所の側から押さえにくる。Amazon ビジネスは推奨サプライヤーや購入禁止カテゴリの設定という形で、③の選定にガバナンスとして触れている。トラスコ中山の MRO ストッカーに至っては、消費地に在庫を置くことで⑥発注そのものを消しにいっている。

同じ表に、購買 BPO を置く

ここからが本題だった。いま挙げた工程を「人手で請け負う」と公式に書いている事業者を、同じ列に並べる。拾ったのは、各社が請け負う業務として工程名を明示しているものだけだ。

「—」＝そのビジネスモデル上、該当しないもの。

表を作りながら、ある種類の言葉が BPO 側にだけ現れることに気づいた。トランスコスモスの**「検収督促」。パーソルの「納品書発行・検収処理」。パーチェスワンの「マスター登録・メンテナンス」。ディーコープの「見積仕様書の作成代行」**。

どれも、SaaS の機能一覧には出てこない言葉だ。

並べ終わって見えた、5つの空白

1. ②仕様策定は、ソフトではなく人に外注されている

17製品を見て、②を主機能として公表しているものを見つけられなかった。一方でディーコープは「見積仕様書の作成代行」を明示して人手で受けている。つまりこの空欄は「誰もやっていない」ではなく**「人がやっている」**。

2. ⑦検収は、ソフトの上で名前を失っている

検収を独立したモジュール名で公表しているのは、世界のスイート8本のうち Oracle だけだった。日本の SaaS で明示しているのはインフォマートと富士通 Japan の ProcureMART。

ところが BPO 側では、検収が名前を持っている。しかも**「督促」**という語がついてくる。検収の実務は、画面のボタンを押すことではなく、相手に押させることなのだと思う。自社の中だけで完結しないから、機能として切り出しても売り物になりにくい。ここは私の推測だ。

下流から埋めにくる動きはある。Sansan の Bill One は、請求書と仕入データを総額だけでなく明細単位で突き合わせる機能を公表している。谷の向こう側から手を伸ばしている形に見える。

3. 日本勢は、⑥発注を挟んで谷になっている

上流に Leaner・A1A・ディーコープ、下流にバクラク・TOKIUM・Bill One・マネーフォワード・ラクス。⑥⑦を跨いで繋いでいるのは、インフォマート、富士通 Japan の ProcureMART、そして外資スイートだけだった。

なぜそうなるのか。ここも推測だが、電子帳簿保存法・インボイス制度・Peppol という強制力が下流に集中して降りてきたことと形が一致している。上流の見積や仕様には、同じ強制力が無い。バクラクが発注の段階で適格請求書発行事業者を判定するのは象徴的で、上流に触ってはいるが、動機は下流にある。

4. 「オーケストレーション層」を名乗る日本製品を、確認できなかった

世界では Zip、Oro Labs、Omnea、Tonkean が揃って「既存の ERP や S2P を置き換えず、その手前・上に立つ」と自己定義している。日本でも①購買申請はバクラク、マネーフォワード、ソロエルのワークフローが担っているが、「複数の既存システムをオーケストレーションする層」という自己定義は、今回の調査では確認できなかった。

無いと断定はできない。ただ、もし本当に少ないのだとしたら、置き換える対象になるほどのスイートが普及していないので「手前に立つ」という価値提案が成立しにくい、という説明はありうる。そして日本では、その位置に人が立っているのかもしれない。

5. BPO が請け負う工程は、SaaS の公表機能とかなり重なる

パーソルが公表している業務の一覧 ―― 見積書作成、注文書処理、納期調整、納品書発行、検収処理、請求書発行、支払処理、売掛買掛管理 ―― は、機能名としては複数の SaaS が公表しているものと重なる。それでも人手で請け負う事業が成立している。

自作を同じ表に置くと、②にいた

私は自分でも調達のシステムを書いている。せっかくなので同じ表に並べてみた。

並べてから気づいたのだが、17製品が誰も埋めていない②に、自分は先に手を出していた。 狙って空白を選んだわけではない。「集めた見積が比べられない」という目の前の問題を潰していたら、比較できない原因が明細の形にあると分かり、形を作るには仕様が要る、という順序でここに着いた。

同時に、自分が⑥⑦⑧を持っていないことも表にそのまま出た。私も、日本の上流勢と同じ側にいる。

もう一度、結論のところ

冒頭に書いたことに戻る。BPO が人手で請け負っている工程と、SaaS が「機能がある」と公表している工程は、かなり重なっている。 それなのに、人手で請け負う事業が成立している。

調べている途中で、それを一社で体現している例に行き当たった。アスクルのソロエルは、SaaS 型の購買システムと購買業務の代行を、同じ会社が両方提供していると公表している。しかも代行のほうは「システム導入後の購買業務を支援する」と位置づけられている。システムを入れたあとに、人手の支援が要るという前提が、そのまま商品になっている。

だとすると、差は機能の有無ではない。候補は3つある。

• マスタ。 パーチェスワンが「マスター登録・メンテナンス」を、トランスコスモスが「各種マスタ情報のメンテナンス」を、請け負う業務として名指ししている。機能があっても、中身を正しく保つ人がいなければ動かない。
• 例外処理。 納期調整、検収督促、問い合わせ対応、返品クレーム。いずれも BPO 側にだけ工程名がある。定型から外れたものを引き受ける仕事が、機能一覧には載らない。
• 相手が使ってくれるか。 サプライヤー側の運用は、こちらのシステムでは強制できない。検収に「督促」がつくのは、たぶんこれが理由だ。

地図を描く前は、空白は「まだ誰も作っていない機能」に見えていた。描いたあとで見えたのは、その逆だった。道具が足りないのではない。道具が前提にしている状態を作る仕事が、人のところに残っている。

自分のシステムに戻って考えると、②の仕様を機械に吐かせたところで、その仕様がカテゴリの実態と合っているかを保つのは結局マスタの手入れだし、ブランクを送ったところで相手が埋めてくれる保証はない。次に作るべきものは、たぶん機能ではない。

この調査でできなかったこと

最後に、この地図の限界を書いておく。

• 一次ページの本文を取得できなかった先がある。 SAP と富士通 Japan の公式ページは、今回アクセスできなかった。該当箇所は検索結果に現れた公式の抜粋や解説サイト経由で埋めており、一次資料での裏取りができていない。
• 各社ページの更新日はほとんど特定できていない。 だから「2026年8月時点で公表されている範囲では」という以上のことは言えない。個別の製品について「最新はこうだ」とは書いていない。
• BPO 大手のうち数社は、調達購買で請け負う工程を明示した公式ページを見つけられなかった。 名前だけ載せて工程を空欄にすると読者が誤読するので、表から外した。
• 日本の購買 BPO の市場規模や事業者数は、この記事では扱わない。 信頼できる形で確認できていない。
• 記号はすべて「そう公表している」の意味しか持たない。実装の深さも、使い勝手も、優劣も判定していない。

見えた5つの空白のうち、②仕様策定と⑦検収については、それぞれもう少し掘りたいと思っている。この地図で間違っているところ、あるいは「うちはその工程をこう埋めている」という話があれば、ぜひ教えてほしい。

Connect — ご感想、似た課題に取り組む方との情報交換、記事への意見を歓迎します。
[email protected] までお気軽にどうぞ。

※ 現在、業務の受託やサービスの申込・相談は受け付けていません。