ワークフローSaaSの選定や見直しには、確認しておきたい前提が2つあります。kickflowは50IDから契約可能と案内されており、rakumo ワークフロー（Google Workspace版）はGoogle Workspace（有料版）が必要です。申請フォーム・承認ルート・承認履歴の保存はワークフローSaaSに残すのが基本です。作り替えの検討は、案件・予算・購買データと連動した判定や自社固有の分岐ルール、承認後の後工程といった標準機能の外側に限られます。
残す／作り替えの判断表【早見表】
稟議・申請フローの業務を、感覚ではなく次の9項目で仕分けます。契約中のワークフローSaaSを1つずつ表に当てはめてみてください。
判定は4種類です。「残す」はそのままSaaSに置くもの、「残す（標準機能）」は追加契約なしで標準に含まれるもの、「残す（プラン・オプション要確認）」は上位プランや追加オプションの契約が必要になるもの、「作り替え候補」はSaaS単体では完結せず専用の仕組みや外部連携を検討する対象を指します。表で用いる用語の定義は次のとおりです。REST APIはシステム同士が規約に沿って自動でデータをやり取りするための接続口です。CSVは表形式のデータを別システムに受け渡すためのファイル形式です。承認履歴は誰がいつ承認・却下したかの記録です。監査ログはシステム上で誰がいつログインや設定変更、チケット操作を行ったかを残す追跡記録です。Webhookは申請の状態変化などのイベントを起点に、外部システムへリアルタイムで自動通知する仕組みです。
| 業務 | 判定 | kickflowの仕様条件 | rakumo ワークフローの仕様条件 |
|---|---|---|---|
| 申請フォームの作成 | 残す（標準機能） | ノーコードで作成可能（スタンダード：20セクション・100フィールド、エンタープライズ：50セクション・200フィールド） | マウス操作で直感的にひな型を作成可能（フォルダ別の利用制御に対応） |
| 承認ルートの基本設定（固定順・上長自動表示） | 残す（標準機能） | 組織図・役職に基づく経路作成、並列ステップ、申請者情報による内分岐に対応 | 上長の自動表示、専用経路・共有経路の設定、ステップ設定に対応 |
| 承認ルートの条件分岐（高度な条件式・動的指定） | 残す（プラン・オプション要確認） | 外分岐の高度な条件式（AかつB、またはC）は標準。チーム/ユーザーの動的指定や変数による内分岐はエンタープライズ限定 | 分岐設定や入力項目間の連動設定に対応。組織外マスタと高度に連動させる動的分岐は事前の設計確認が必要 |
| 申請データ・承認履歴の保存 | 残す（標準機能） | チケット件数無制限。承認・差戻し・却下の操作履歴、代理記録を保持 | 契約期間中は保管期間に制限なし。代理承認・確認操作に対応 |
| システム操作・監査ログの保存 | 残す（プラン要確認） | 操作ログは標準。IPアドレス付き監査ログ（CSV/API取得）はスタンダードで60日、エンタープライズで1年 | 運用管理画面でのログ管理に対応（保存日数や監査出力の要件は事前確認が必要） |
| 申請データのCSV出力・帳票出力 | 残す（プラン・オプション要確認） | CSVエクスポートは標準。Excel/PDFの帳票出力やBox/ドライブへの自動アップロードはエンタープライズ限定 | CSVダウンロード・印刷レイアウトは標準。添付を含む一括ZIPダウンロードは超過時（150回超で年15,000円税抜）に追加購入が必要 |
| API連携・Webhook | 残す（プラン・オプション要確認） | REST APIはスタンダード・エンタープライズの両方で提供（ファイルUP APIはエンタープライズ限定）。Webhook上限はスタンダード10件、エンタープライズ50件 | Google Workspace版はAPIオプション（初期180,000円＋各API年15,000円税抜）が別契約（Microsoft 365版は無償提供・要申込） |
| 案件・予算・購買データと連動した事前判定 | 作り替え候補 | 稟議の承認可否を別システムのリアルタイムな予算残高や案件進捗と突き合わせて事前判定するロジックは、両製品とも標準機能の外側になりやすい領域 | |
| 承認後の後工程（発注・支払・他システム台帳更新） | 作り替え候補 | 決裁完了をトリガーとして基幹・会計システムへ自動登録したり発注処理を行ったりする後工程は、API連携や専用の自動化処理を組み合わせる対象 | |
この仕分けは、該当項目の数だけで機械的に判断するものではありません。まずは手作業での突き合わせにかかる業務時間、転記ミスによる損失リスク、監査で求められる証跡の厳密さ、そしてSaaSの上位プランやAPIオプションにかかる契約・保守費用を天秤にかけます。SaaSの上位プラン変更だけで解決できるなら、自社開発を行わずにSaaS内で完結させるのが最も堅実です。
申請・承認・証跡を残す根拠は「承認記録の一元管理」にある
ワークフローSaaSに申請・承認・証跡を残す判断の根拠は、誰がいつ何を承認したかという記録が、システム上で一元管理され続けるという点にあります。紙やメールでの申請・承認に戻すと、この記録が分散し、後から追跡することが難しくなります。
証跡を評価する際は、日常の「申請・承認履歴」と、内部統制に関わる「システム監査ログ」を区別して確認する必要があります。kickflowの公式サイトによれば、申請（チケット）は件数無制限で、承認・差し戻し・却下の操作は標準機能として記録されます。代理申請・代理承認についても「代理の記録つき」と案内されており、本人以外が処理した場合もその事実が履歴に残る設計です。一方、テナント内の設定変更やチケット操作を追跡するシステム監査ログは、作成・更新・削除をIPアドレスとともに記録し、CSV・REST APIで取得可能です（保存期間はスタンダードプランで60日、エンタープライズプランで1年。これは申請そのもののデータではなく、システム操作ログの保存期間です）。rakumo ワークフローの公式サイトによれば、申請データは「契約期間中であれば保管期間に制限はない」と案内されており、管理者が代理で承認・確認を行う場合も運用管理画面から処理できます（いずれも2026年9月10日確認）。ただし、解約後のデータ保持期間や外部ストレージへの永続保管については、各社の利用規約に応じたエクスポート設計が前提となります。
承認記録を一元管理し、後から追跡できることが、残す判断の根拠です。どちらのSaaSが優れているかを比較する記事ではありません。
kickflow・rakumo ワークフローの契約前提と費用構造【2026年9月10日確認】
kickflowの公式サイトによれば、プランは「スタンダード」「エンタープライズ」の2種類で、初期費用0円、月額は利用構成に応じた個別見積り、50IDから契約可能と案内されています。機能一覧ページでは、ノーコードでの申請フォーム作成、承認経路の分岐（外分岐・内分岐）、CSVエクスポート、100種類以上のREST API、Webhook、外部チャット連携などが掲載されています。注意すべきは、動的な承認者指定（チーム/ユーザー）、変数による内分岐、帳票出力、添付ファイルアップロードAPI、kintone連携、SSO（シングルサインオン＝1組のID・パスワードで複数システムにログインできる仕組み）など25項目が「エンタープライズ限定」となっている点です。Webhookの登録可能数（スタンダード10件、エンタープライズ50件）やオートメーション実行回数（月100回対10,000回）にも差が設けられています。
rakumo ワークフロー（Google Workspace版）は、利用にGoogle Workspace（有料版）の契約が前提となります。本体ライセンスは月額換算1ユーザー500円（年額6,000円、税別）、契約は12ヶ月単位で初期費用は不要です。ライセンス料金のみの試算例としては、50ユーザーで月額換算25,000円、100ユーザーで月額換算50,000円、300ユーザーで月額換算150,000円（いずれも税別）となります（Google Workspace本体の費用や追加オプションは含まれません）。外部システムとの接続には追加費用が発生し、人事マスタ等を連携する「Active Directory 連携ツール」が600,000円、「ユーザー詳細CSVアップローダー」が120,000円（いずれも税抜・買い切り型）です。さらにWEB APIを利用する場合は「APIオプション」が別契約となり、初期導入費180,000円に加え、APIごとに年間15,000円（税抜）の年額利用料が必要です。
両社に共通するのは、標準機能とは別に「上位プラン」「オプション」の区分が用意されている点です。この区分の外側にあるものが、作り替えを検討する対象になります。最新のプラン内容・金額は各公式サイトでご確認ください。
詰まりやすいポイントは「標準機能の外側」にある
ワークフローSaaSを運用する中で、現場の業務と乖離しやすい代表的な論点は次の4つです。
- 案件・予算・購買データと連動した判定: 稟議の承認可否を、基幹や会計にある予算残高・発注実績とリアルタイムに突き合わせて判定する処理は、SaaS単体のフォームや分岐条件では完結しにくい領域です。
- 動的な承認者解決を伴う分岐ルール: 金額や部門だけでなく、プロジェクト体制や案件ごとの外部マスタを参照して承認者を動的に切り替える運用は、上位プランの条件式を駆使しても設定が煩雑化しやすいポイントです。
- 他システムとの二重入力: 稟議が通った後に、購買管理システムや会計ソフトへ同じ内容を手作業で転記している場合、入力ミスや二重管理のリスクが生じます。
- 承認後の後工程（発注・支払・台帳更新）: 承認が完了した事実をトリガーとして、発注書の送付や台帳の自動更新といった後続処理を回す仕組みは、ワークフローSaaSの基本スコープ外になります。
これらはワークフローSaaS自体の欠陥ではなく、自社固有のデータ構造や周辺システムとの境界で生じる課題です。申請フォーム・承認操作・証跡管理といった「統制の中心」はSaaSに残し、外部データの参照判定や後続連携に絞って見直すのが合理的です。
基幹データベースの正本性を保ったまま、周辺の判定やデータ加工の役割を切り分けたアーキテクチャの考え方は、事例集の〈CASE 06｜業務DBと生成AIを、あえて分ける〉（※本記事で扱う特定SaaSの導入実績ではなく、データ分離設計の参考事例）で紹介しています。
併用設計 — 申請・承認・証跡はSaaSに、固有の判定と連動は自社システムで持つ
現実的な進め方は、全面移行ではなく併用です。申請フォーム・承認ルート・承認履歴はワークフローSaaSを確定元とし、案件・予算データは基幹システム等を正本として参照します。そのうえで、事前判定結果をSaaSへ反映させる入力連携と、決裁完了イベントを受け取って発注・台帳更新を進める外部システム側の後工程連携とに方向を分けて設計します（CSV出力はデータ抽出用であり、SaaSへの書込手段としては扱いません）。
モデルケースとして、従業員120名の建設関連企業で、稟議の承認可否を案件ごとの予算残高と突き合わせる必要があり、承認者が別システムの画面を見比べながら手作業で判定している状況を想定します（架空の設計モデルであり、特定企業での実証結果ではありません）。この場合、承認権限や証跡の記録はSaaS側に残し、判定の補助と後工程を外部化する設計をとります。
具体的には、申請者が起案した内容をもとに、外部システムが基幹DBの予算残高を参照して「予算適合」「予算超過（要役員承認）」といった判定結果を算出します。この判定結果と参照時点のタイムスタンプに加え、判定に用いた参照予算残高（金額）も申請内容と対応づけてSaaS側の申請フィールドへ戻す設計は、採用製品において対象項目の更新APIや一括取込が提供されているか、また申請ステータスや更新権限の制約を満たせるかを事前に確認したうえで適用します。最終的な「承認・却下の判断」は権限を持つ人間がSaaS上で行い、その操作証跡はSaaSに一元保存されます。申請内容の修正や差し戻しが発生した場合は、必ず外部システム側で再判定を行い、判定結果と申請内容の乖離を防ぐ排他設計が必要です。さらに決裁完了後は、製品が備えるWebhook通知やAPIポーリングなどの取得経路を確認したうえで、外部システムが発注処理や台帳更新をキックします。再通知やリトライによる二重発注を防ぐ冪等性（べきとうせい＝同じ処理が複数回実行されても結果が変わらない性質）の担保が必須要件となります。削減額や工数は契約構成や既存DBの仕様によって異なるため断定しません。
- 1. 申請起案（SaaS） 申請者がワークフローSaaSのフォームから起案内容を入力する。
- 2. 予算照合・事前判定（外部システム） 外部システムが基幹DB等の最新予算データを照合し、判定結果・参照予算残高・時点情報を算出する。
- 3. 判定結果の反映（SaaS） 判定結果・参照予算額・時点情報をSaaSへ戻す（API更新・取込の可否や権限仕様の確認が前提）。
- 4. 承認判断と証跡記録（SaaS） 権限者が判定結果を確認して承認・却下。操作履歴と監査ログをSaaSに一元保存する。
- 5. 発注・台帳更新（外部システム） 決裁完了を外部システムが受信（WebhookやAPIポーリング等の利用可能経路を確認）。
※架空の未検証設計例です。SaaS側での申請フィールド更新可否や通知取得手段は製品・プランごとの仕様確認が必要です。申請内容の修正・差し戻し時は「2. 予算照合」に戻り再判定を行います。後続処理には二重実行を防ぐ冪等性の担保が必要です。
自社のどの業務が標準機能の外側にあるかを整理したい場合は、無料のAI自動化診断が出発点になります。
AI駆動開発で作り替えると、何がどう変わるか
自社固有の予算照合や後工程を専用システムに切り出す場合でも、SaaSの利用を全面解約するわけではありません。費用構造は「ワークフローSaaS（および接続に必要な上位プランやAPIオプション利用料）」を継続しつつ、そこに「専用システムの初期構築費用と運用保守費用」を組み合わせる併用型となります（開発費用の相場感はAI駆動開発費用の相場まとめを参照）。
支援体制の一例として、担当エンジニアが業務の分解から実装、運用定着まで伴走するFDE（Forward Deployed Engineer：顧客の業務現場に入り込んで個別実装を行うエンジニア）型の進め方があります（FDE型AI導入支援とは）。進め方としては、すべてのフローを一気に作り替えるのではなく、予算照合などのボトルネック1箇所に絞って最小限の実装（MVP：実用最小限のプロダクト）を作成し、動作を確認しながら段階的に拡張します。一方、標準機能の分岐設定で過不足なく回っており、手作業の転記負荷も軽微であるなら、追加開発を行わずSaaSを標準のまま使い続けるのが最も経済的です。この見極めにあたっては、業務システムは共有型か専用型かを事前に参照してください。
定型的なデータ転記や周辺作業を自動化で引き取ったアプローチの参考として、事例集の〈CASE 02｜毎日の巡回・転記を、AIが引き取る〉（※特定製品の導入実績ではなく、周辺作業の自動化事例）を紹介しています。
よくある質問
kickflowやrakumo ワークフローを使っているのに、なぜ稟議のたびに他のデータを見比べる必要があるのですか？
標準的な承認ルートを前提に設計されているためです。案件・予算・購買データとの突き合わせ判定は、標準機能の外側になりやすい領域です。
kickflowやrakumo ワークフローを、AI駆動開発システムに完全に置き換えるべきですか？
いいえ。申請フォーム・承認ルート・承認履歴の保存は、承認記録の一元管理を満たし続けるためワークフローSaaSに残すのが基本です。作り替えの対象は標準機能の外側に限ります。
承認ルートの条件分岐は、どこまでが「標準機能の外側」なのですか？
フォーム入力値や組織階層に基づく分岐であれば、SaaSの標準または上位プランの範囲内で設定できるケースが一般的です。たとえばkickflowでは外分岐の高度な条件式（AND/OR条件）は標準機能に含まれ、変数による内分岐や承認者の動的指定はエンタープライズ限定と案内されています。rakumo ワークフローでも分岐設定や入力項目間の連動設定に対応しています。一方、「標準機能の外側」となるのは、基幹DB上の予算残高や案件進捗といったSaaS外のデータをリアルタイムに参照して判定する場合や、外部マスタと高度に連動させて承認者を動的に解決するような処理が必要な場合です。
残す／作り替えを判断するとき、最初に何を確認すればよいですか？
契約中のワークフローSaaSの機能を、本記事の判断表の9項目に当てはめ、標準機能の外側にある業務がどれだけあるかを洗い出すのが最初の一歩です。
kickflowとrakumo ワークフロー（Google Workspace版）の契約には、それぞれどのような前提条件がありますか？
kickflowは初期費用0円で、50IDから契約可能と案内されています。rakumo ワークフロー（Google Workspace版）は利用にGoogle Workspace（有料版）が必要で、初期費用は不要、契約は12ヶ月単位です。
業務別の判断基準は、請求・見積・勤怠管理・CRM・SFA・経費精算の各記事でも扱っています。SaaS費用の考え方を横断的に整理する場合は「SaaS is dead」とは何か、残す／置き換えの基本は残すSaaSと置き換えるSaaSの見極め基準、契約中の全SaaSの棚卸し手順はSaaS費用の棚卸し実務、解約・データ移行等の個別論点は脱SaaSのよくある質問20をご覧ください。
自社のどの業務からAI化すべきかを知りたい方は、無料のAI自動化診断をご利用ください。自社の業務に合わせたシステムをAI駆動開発で作る場合の相談・見積りは、株式会社Walkersのシステム開発事業で受け付けています。本記事は、FDE型のAI導入支援を行う株式会社Walkersが運営しています。
参考
執筆時点（2026年9月10日確認）の各公式サイトの公開情報に基づきます。プラン・仕様・料金は予告なく変更される場合があるため、最新情報は各公式サイトでご確認ください。
- 機能一覧｜kickflow（取得日 2026-09-10）
- 料金｜kickflow（取得日 2026-09-10）
- 会社概要｜kickflow（取得日 2026-09-10）
- セキュリティ（ISO/IEC 27001）｜kickflow（取得日 2026-09-10）
- rakumo ワークフロー｜rakumo（取得日 2026-09-10）
- rakumo ワークフローのご利用料金・プラン｜rakumo（取得日 2026-09-10）
- 株式会社Walkers「AI駆動開発費用の相場まとめ」（取得日 2026-09-10）
- 株式会社Walkers「FDE型AI導入支援とは」（取得日 2026-09-10）
