---
title: "グループウェアのワークフローはどこまで足りるか｜専用システムへ移す4つの条件"
url: "https://www.issoh.co.jp/column/details/19254/"
published: 2026-11-03
updated: 2026-11-03
categories: ["DX"]
publisher: "株式会社一創"
---

# グループウェアのワークフローはどこまで足りるか｜専用システムへ移す4つの条件

稟議も経費申請も休暇届も、グループウェアのワークフロー機能で回している。その状態を続けてよいのか、専用のワークフローシステムへ移すべきなのかを、製品の公式仕様から判定していきます。この記事では、サイボウズのGaroonとMicrosoft 365の承認アプリを例に、経路・入力・連携・証跡・保管の5つの軸でグループウェアのワークフローが届く範囲を確かめる構成です。そのうえで専用システムへ移す4つの条件と、両方を併用するときに二重投資を避ける境界の引き方を示します。数値と仕様は2026年11月時点の公式ドキュメントに基づきます。

## まとめ：グループウェアのワークフローで足りる範囲と、専用システムへ移す4つの条件

グループウェアのワークフローは、申請を人から人へ回して承認を記録するところまでは十分に作り込まれています。直列・並列の承認、回覧、代理承認、金額による経路分岐まで、標準機能で設定できます。足りなくなるのは、申請の中身を他のデータと突き合わせる場面と、承認の結果を別のシステムへ流す場面です。

移行の判断は4つの条件で決めてください。取引先や予算といったマスタを申請画面から参照したい、承認済みのデータを会計や販売管理へ自動で登録したい、監査で申請単位の証跡を求められる、承認待ちが30日を超える申請がある。どれか1つでも当てはまれば専用システムへ移す前提で設計を始めます。4つとも当てはまらないなら、書式の数が多くてもグループウェアのまま運用を整えるほうが安く済みます。

## グループウェアのワークフロー機能が公式仕様として持つ範囲と設計の前提

比較記事の多くは「グループウェアのワークフローは簡易版」と一言で片付けます。公式ドキュメントに当たると、経路の設定は想像より細かく作れる一方、入力と連携には明確な制約があるという構造です。グループウェア全体の機能と選び方は[グループウェアとは？機能・料金とクラウド型オンプレ型の違い、選び方を解説](https://www.issoh.co.jp/column/details/13295/)で整理しているため、ここではワークフロー機能だけを取り出して見ます。

### 承認・回覧・代理承認まで揃う経路設定と、条件分岐に使える項目の制約

[クラウド版Garoonのワークフローの特徴](https://jp.cybozu.help/g/ja/admin/application/workflow/first/feature.html)によると、経路種別は「承認（全員）」「承認（誰か1人）」「回覧」の3種類です。経路ステップは複数並べられ、最後のステップの処理者が最終承認者になります。代理申請者と代理承認者を置く代理人の仕組み、申請者が処理前に申請を引っ込める「取り戻し」、最終承認前に撤回する「取り消し」も標準で用意されています。

経路の分岐も、標準機能で対応できる範囲です。[経路分岐条件の設定](https://jp.cybozu.help/g/ja/admin/application/workflow/branch/condition.html)では、分岐の判定に使える項目はメニュー・数値または自動計算・ラジオボタン・チェックボックスの4タイプで、条件は一覧の上から順に適用されます。「金額が100万円以上なら役員決裁を足す」といった分岐は、この範囲で組めます。

組めないのは、申請者の所属や取引先の属性を外部から引いて分岐させる形です。判定の材料は申請フォームに入力された値に限られるため、分岐の軸がフォームの外にある業務は、入力欄を足して申請者に選ばせる運用で補うことになります。

### 申請フォームの項目は10種類で、マスタを参照する入力欄が無いという限界

経路より先に限界が来るのは入力側です。[Garoonの申請フォームの項目のタイプ](https://jp.cybozu.help/g/ja/admin/application/workflow/item/type.html)は、文字列（1行）・文字列（複数行）・メニュー・ラジオボタン・チェックボックス・数値・自動計算・日付・ファイル添付・路線ナビ連携の10種類です。ファイル添付は1申請あたり最大5個と書かれています。

この一覧に、別のデータベースから値を引いてくる項目はありません。メニューの選択肢は管理者が直接入力するか、申請者の所属組織を読み込むかの2通りです。取引先コードを入れたら社名と与信枠が表示される、予算科目を選んだら残額が出る、といった入力補助は標準機能では作れません。

この差は申請の差し戻し率に出ます。購買稟議で取引先名を手入力させると、表記ゆれと誤記が生じ、経理側の確認作業が増える原因になるためです。申請件数が月に数十件のうちは目視で吸収できますが、件数が増えるほど差し戻しの往復が承認の待ち時間を押し上げます。

### Microsoft 365の承認アプリが抱える30日の待機上限とテンプレート数の天井

Microsoft 365を使う会社では、Teamsの承認アプリとPower Automateが実質的なワークフロー機能になります。[Teamsで承認アプリを管理する](https://learn.microsoft.com/ja-jp/microsoftteams/approval-admin)には、承認アプリから作成された承認は既定のMicrosoft Dataverse環境に格納され、現時点でバックアップはサポートされないと書かれています。各チームが持てる承認テンプレートは最大400個、1テンプレートで集められる要求は最大50,000件です。

多段の承認をPower Automateのフローで組む場合は、実行時間の上限が効きます。[Power Automateの制限事項](https://learn.microsoft.com/ja-jp/power-automate/limits-and-config)では、実行の継続時間は30日で、承認などの保留中のステップを含むフローも対象になり、30日後にはすべての保留ステップがタイムアウトすると明記されています。実行の保持期間も30日です。

月次の稟議なら30日で困ることはまずありません。問題になるのは、決裁者の出張が続く会社の大型投資稟議や、年度をまたいで承認を待つ契約更新のような申請です。90日以内に一度もトリガーされないフローは停止される場合がある点も、年に一度しか使わない申請書を組むときに見落とされがちです。

## グループウェアと専用ワークフローシステムの差を5項目で並べた実務比較

5つの軸で並べると、設定や運用で埋められる差と、製品の設計思想から来る差が分かれます。表のあとで、最も差が開く連携の軸を掘り下げます。

### 経路・入力・連携・証跡・保管の5軸で比べた到達点と差が出る業務場面

下表は、前章で確認した公式仕様と、専用ワークフローシステムが一般に備える機能を突き合わせたものです。グループウェア側の記述はGaroonとMicrosoft 365の承認アプリを基準にしており、製品やプランで変わります。

| 軸  | グループウェア付属    | 専用ワークフロー      | 差が出る場面       |
| -- | ------------ | ------------- | ------------ |
| 経路 | 承認・回覧と分岐に対応  | 組織改編を経路に自動反映  | 年1回の大規模な組織改編 |
| 入力 | フォーム内の値だけ    | マスタ参照と入力チェック  | 取引先や予算科目の選択  |
| 連携 | 取得系APIとCSV出力 | 登録APIと仕訳データ出力 | 会計や販売管理への転記  |
| 証跡 | 運用ログとして記録    | 申請単位で履歴を出力    | 監査での決裁経緯の提出  |
| 保管 | グループウェアの容量内  | 年限と検索条件を設定    | 決裁文書の長期保存    |

経路の軸は差が小さく、組織改編のたびに管理者が経路を直す手間で吸収できます。入力と連携の2軸は、標準機能に無いものを運用で補うことが難しく、ここで移行を決める会社が大半を占めるのが実情です。専用ワークフローシステム側の機能の全体像は[ワークフローシステムとは？機能・クラウドとオンプレの違い・選び方と自社開発の判断基準](https://www.issoh.co.jp/column/details/15254/)にまとめています。

### 基幹システム連携で差が開く理由｜取得系のAPIだけで登録はできない構造

Garoonの開発者向け資料である[Garoon REST APIの一覧](https://cybozu.dev/ja/garoon/docs/rest-api/)を見ると、ワークフロー関連は「1件の申請データを取得する」「複数の申請データを取得する」「申請データに添付されたファイルを取得する」「申請フォームを構成している項目を取得する」の4本で、いずれもGETです。承認済みの申請を外から読み出すことはできても、外部システムから申請を起票する口はREST APIにはありません（申請を処理するAPIはSOAP API側の一覧に置かれています）。

実務では、承認済みの申請を定期的に取得し、会計システムへ仕訳として登録するバッチを別に作る形になります。読み出し側だけで組めるため実装は難しくありません。ただし、申請項目のどれを勘定科目に対応させるかの対応表と、取得漏れを検知する仕組みは自社で持つことになります。

逆方向、つまり販売管理で受注が立ったら値引き申請を自動で起票する、といった流れはグループウェア側では作りにくい部類です。連携方式ごとの設計は[ワークフローシステム連携の方式と設計：API・CSV・DB直結・iPaaSの選び分け](https://www.issoh.co.jp/column/details/18046/)で扱っています。

## グループウェアのワークフローで足りる会社の条件と破綻が始まる兆候

書式の数で線を引く説明をよく見かけますが、書式が30種類あっても回る会社はあります。見るべきは書式の数ではなく、申請が承認されたあとにデータがどこへ流れるかです。

### 専用システムへ移す4つの条件｜マスタ参照・基幹連携・監査証跡・長期保留

次の4つのどれかに当てはまれば、専用システムへ移す前提で設計を始めます。

- マスタ参照：取引先・予算科目・品目などを、申請画面で既存のマスタから選ばせたい
- 基幹連携：承認済みの申請を、会計・販売管理・人事の各システムへ人手を介さず登録したい
- 監査証跡：J-SOXや会計監査で、申請ごとの決裁経緯と経路変更の履歴を提出する立場にある
- 長期保留：決裁者の不在や年度またぎで、承認待ちが30日を超える申請が毎年発生する

実務での比重は上の順です。マスタ参照と基幹連携は、要件として最初に出てきやすく、グループウェアの標準機能で代替できる手段がほとんどありません。監査証跡は、上場準備や親会社の監査対応で後から追加されることが多い条件です。上場企業や上場準備企業での経路設計と統制の要件は[大企業のワークフローシステム選定｜多階層の承認経路・J-SOX統制・人事連携の要件](https://www.issoh.co.jp/column/details/18037/)で詳しく扱っています。

### 併用で二重投資を避ける境界｜入口はグループウェア、決裁は専用側へ

専用システムへ移すと決めても、全部の申請を移す必要はありません。休暇届、備品購入、社内イベントの参加申請のように、承認で完結してデータが次へ流れない申請はグループウェアに残します。専用側へ移すのは、承認結果を会計や販売管理が使う申請と、監査で提出を求められる決裁です。

境界を引くときの判断軸は1つで十分です。「この申請の承認結果を、別のシステムが読みに来るか」。読みに来るなら専用側、来ないならグループウェア側に置きます。この線を先に決めておくと、同じ申請書が2か所に存在して現場が迷う状態を避けられます。

ポータルの入口をグループウェアに残し、専用システムの申請画面へリンクで飛ばす構成にすれば、利用者の操作はほとんど変わりません。認証をグループウェアと揃え、マスタ参照や会計連携を備えた申請画面だけを個別に作る進め方は、[ワークフローシステム開発](https://www.issoh.co.jp/service/business%5Fsystem/workflow/)で相談を受けています。

## グループウェアのワークフローを据え置く判断と、移行で詰まる工程の先回り

ここは条件付きで言い切ります。4つの条件のどれにも当てはまらないなら、専用システムの導入は過剰です。一方で移行を決めたなら、詰まる工程は事前に分かっています。

### 据え置きを決めてよい条件｜申請が人で終わりデータが次へ流れない業務

据え置いてよいのは、承認された申請を人が読んで次の作業をする会社です。経費申請の承認後に経理担当が会計ソフトへ手で入力しており、その件数が月100件程度に収まっているなら、連携を作る費用のほうが手入力の人件費を上回ります。

この規模で投資すべきは、システムではなく書式と経路の整理です。似た申請書を統合し、分岐条件をメニュー項目に寄せ、代理承認者を全経路に設定する。これだけで承認の滞留は大きく減ります。専用システムは利用者数に応じた月額費用がかかり、グループウェアとの二重契約になります。

据え置きの前提が崩れるのは、会計システムの入れ替えや上場準備が始まったときです。この2つは連携と監査証跡の要件を同時に連れてくるため、計画が見えた時点で移行の検討を始めてください。

### 移行で詰まる3つの工程｜処理中の申請・過去データ・経路定義の移し替え

移行で止まるのは、新しい画面を作る工程ではなく、古い側からデータを出す工程です。

1. 処理中の申請：切り替え日に承認途中の申請は移せないため、旧側で最後まで処理させる期間を1〜2か月設ける
2. 過去の申請データ：Garoonは[ワークフローの管理機能](https://jp.cybozu.help/g/ja/admin/application/workflow.html)に申請データのCSV書き出しがあり、Teamsの承認アプリはDataverseに格納されるため、出力形式を先に確かめる
3. 経路の定義：Garoonの共有経路はXMLファイルで管理できるが、移行先の形式へは対応表を作って手で写す

3つのうち最も工数が読みにくいのは経路の定義です。経路は組織図と役職の組み合わせで書かれているため、移行先の組織マスタと突き合わせる作業が発生します。過去データは、監査で参照される期間だけを移し、残りはCSVのまま保管する判断が費用面では有利です。

## よくある質問

グループウェアのワークフローについて、導入や移行の検討でよく挙がる質問をまとめました。

### グループウェアのワークフローとワークフローシステムの違いは何ですか？

申請を回して承認を記録する機能は、どちらも持っています。差が出るのは、申請画面でマスタを参照できるかと、承認結果を他のシステムへ登録できるかの2点です。Garoonを例に取ると、申請フォームの項目は10種類で外部のデータを引く項目が無く、ワークフローのREST APIは取得系だけです。承認で業務が完結するならグループウェアで足り、承認結果が会計や販売管理へ流れるなら専用システムが向きます。

### Microsoft 365の承認機能だけで稟議を回せますか？

稟議の種類が少なく、承認が数日で終わる会社なら回せます。Teamsの承認アプリは標準で使え、テンプレートの作成上限はチームあたり400個です。注意が必要なのは、次に挙げる2つの制約です。Power Automateで多段の承認フローを組むと、承認待ちを含めて実行は30日でタイムアウトします。承認データは既定のDataverse環境に入り、承認アプリとしてのバックアップには対応していません。決裁の記録を長期保存する必要があるなら、保管先を別に設計してください。

### 代理承認や差し戻しはグループウェアでも設定できますか？

主要なグループウェアは標準で対応しています。Garoonでは代理申請者と代理承認者を代理人として設定でき、差し戻しや経路変更の許可も管理者の一般設定で切り替えられる仕組みです。申請者側には、誰も処理していない段階で申請を引っ込める「取り戻し」と、最終承認前に撤回する「取り消し」があります。代理承認者を設定していない経路では、決裁者の不在がそのまま滞留になるため、導入時に全経路へ設定しておくと詰まりを防げます。

### グループウェアを乗り換えると過去の申請データはどうなりますか？

新しい製品へそのまま引き継がれることはありません。Garoonは申請データをCSVで書き出せるため、申請内容と処理結果を表形式で保存できます。ただし、移行先の製品が過去の申請を取り込める形式かどうかは製品ごとに異なります。監査や税務調査で参照される期間の申請だけを移行先へ取り込み、それ以前はCSVとして保管する方法が、作業量を抑えやすい進め方です。切り替え日の時点で承認途中の申請は、旧製品で最後まで処理させてください。

### 専用ワークフローシステムへ移すと費用はどのくらい増えますか？

増える費用は、専用システムの利用料と連携の開発費の2つに分かれます。利用料は利用者数に応じた月額が中心で、グループウェアの契約も残るため、両方の利用料を支払う形です。連携の開発費は、会計や販売管理へ登録する項目の数と、マスタを同期する範囲で決まります。全申請を移すのではなく、承認結果を他システムが使う申請だけに移行対象を限れば、利用者数も連携範囲も絞ることが可能です。月額と初期費用の内訳は、関連記事の費用相場の記事で確認できます。

## 関連記事

- [ワークフローシステム比較の判断軸4つ｜タイプ別の選び分けと費用の見方](https://www.issoh.co.jp/column/details/17504/)：専用システムへ移すと決めたあと、製品のタイプをどう選び分けるかを扱っています。
- [ワークフローシステムの費用相場と内訳｜月額・初期費用・自社開発との5年総額](https://www.issoh.co.jp/column/details/18033/)：移行で増える費用を、月額と初期費用の内訳から見積もれます。
- [グループウェア比較｜料金と最低ユーザー数、Microsoft 365との棲み分けで決める選定基準](https://www.issoh.co.jp/column/details/17482/)：グループウェア側を選び直す場合の料金と契約条件の見方が分かります。
- [グループウェアの文書管理はどこまで足りるか｜専用システムへ移す判断基準](https://www.issoh.co.jp/column/details/17756/)：決裁済み文書の保管先をどこに置くかを、文書管理の側から扱っています。
- [稟議システムとは？機能・仕組みと紙・メール稟議の課題から見る導入判断の基準](https://www.issoh.co.jp/column/details/15916/)：稟議に絞った電子化の進め方と導入判断を扱っています。

---

出典: [グループウェアのワークフローはどこまで足りるか｜専用システムへ移す4つの条件](<https://www.issoh.co.jp/column/details/19254/>)（株式会社一創）