テクノロジー

Salesforce 承認ワークフロー相当の仕組みを、ライセンス不要で実装する3パターン

Salesforce 承認ワークフロー相当の仕組みを、ライセンス不要で実装する3パターン

「稟議や申請の承認を、Excelやハンコ回しから卒業したい」——中小企業の管理者層からよくいただく相談です。

エンタープライズの世界では、Salesforce Approval Process のように 「申請 → 上長承認 → 通知 → 履歴保存」を一本のフローで回す仕組み が定着しています。複数承認者・並列承認・差戻し・期限管理まで、設定画面で組み立てられるのが強みです。

ただ、この仕組みをそのまま中小企業に持ち込もうとすると ライセンス費用が重く なりがちです。承認者だけにライセンスを割り当てれば済む話でもなく、申請者側にも一定の権限が必要になるため、人数が増えるほど月額が膨らみます。

本記事では、Optiensがエンタープライズ向け大規模CRMで設計してきた承認ワークフローの考え方を踏まえ、ライセンス不要で実装できる3パターン を整理します。管理者層が「うちの規模だとどれが現実的か」を判断するための材料としてお使いください。

前提：Salesforce Approval Process の何を再現したいのか

3パターンを比較する前に、一般的な承認ワークフローで再現したい機能を整理しておきます。

機能内容
申請受付フォームまたは添付ファイルから申請内容を受け取る
ルール判定金額・部署・種別などで承認ルートを自動分岐
通知該当承認者に「承認依頼が来ています」を即時通知
承認・却下承認者がワンタップで判断できる
差戻し・コメント修正依頼と理由を記録
履歴保存「いつ・誰が・何を承認したか」をログとして残す
期限管理一定時間で次の承認者へエスカレーション

この7機能を どこまで実装するか がパターン選択の分かれ目になります。「全部を完璧に」ではなく、業務上どこが本当に必要か を見極めることが、ライセンス不要構成の成否を分けます。

パターン1：メールベース型——最小コストで稟議化

最もシンプルなのが、メール本文に「承認」「却下」のリンクを埋め込み、承認者がクリックするだけで結果がDBに記録されるパターンです。

仕組み

[申請フォーム] → [サーバ] → [承認URL付きメール] → [承認者クリック]
                       ↓                                  ↓
                  [DBに申請保存]                    [DBに結果保存・通知]

承認URLには 使い捨てトークン を付与し、本人確認とURL再利用防止を担保します。承認/却下ボタンは、Webページを開かずメール本文のリンク1クリックで完結する設計が現場で好まれます。

Salesforce Approval Process との対応

Salesforce 機能メールベース型での実装
申請受付Web フォーム（Astro / Google Forms など）
ルール判定サーバ側スクリプトで条件分岐
通知通常のメール送信（SendGrid / Resend など）
承認・却下承認URLクリック
差戻し「コメント付き却下」リンクから入力フォームへ誘導
履歴保存DBに承認ログを蓄積
期限管理一定時間後にリマインドメールを再送

メリット・デメリット

メリット

  • 承認者は 新しいツールを覚えなくてよい（普段使っているメールで完結）
  • 構築・運用コストが最も低い
  • スマホからでもワンタップ承認可能

デメリット

  • 複雑な並列承認・条件分岐ルートには向かない
  • 承認者がメールを見落とすと止まる
  • 履歴の可視化（一覧画面）は別途必要

想定費用

  • 初期構築：30万円〜80万円（申請フォーム1〜3種類・承認ルート2〜3パターン程度）
  • 運用：メール送信サービス実費（月額1,000〜3,000円程度）+ 保守プラン

Optiensでの構築事例

公開デモ /document-editor は、まさにこのメールベース型に近い思想で作られています。提出者が文書を提出すると、上長は スマホでQRコード経由のURL から承認画面を開き、その場で「承認」「差戻し」を判断できます。承認モード／提出モードで画面が切り替わる設計は、メール+承認URL型の典型パターンです。

「まずは1つの稟議だけシステム化したい」「ハンコ回しを止めたいだけ」という規模感であれば、このパターンで十分です。

パターン2：チャット型——Approver の業務動線に密着

申請内容を Slack / Microsoft Teams にカード形式で投稿し、承認者がチャット上の 「承認」「却下」ボタン を押すパターンです。

仕組み

[申請フォーム] → [サーバ] → [Slack/Teams にカード投稿] → [ボタンクリック]
                       ↓                                       ↓
                  [DBに申請保存]                         [DBに結果保存・スレッド返信]

Slack の Block Kit、Teams の Adaptive Cards を使えば、申請内容と承認ボタンを構造化された形で表示できます。承認後は同じスレッドに自動返信されるため、チーム全員が承認の流れを把握 できます。

Salesforce Approval Process との対応

Salesforce 機能チャット型での実装
申請受付Web フォーム or チャットコマンド（/申請 など）
ルール判定サーバ側で条件分岐し、投稿先チャネル・承認者をメンション
通知チャット通知（既存のチャネルでメンション）
承認・却下カード上のボタンをクリック
差戻しモーダルでコメント入力 → 申請者にメンション
履歴保存DBに記録 + チャットスレッドにも残る
期限管理未対応のカードを定期的にリマインド再投稿

メリット・デメリット

メリット

  • 承認者が普段見ているチャット画面で完結 するので開封率が圧倒的に高い
  • スレッドにコメントが残り、承認の文脈が分かりやすい
  • 複数承認者へ一斉メンションすれば、早い者勝ち承認も簡単

デメリット

  • Slack / Teams を会社で導入していることが前提
  • 機微な情報（給与・人事評価など）はチャット表示に向かない
  • 承認履歴を整理した一覧画面は別途必要

想定費用

  • 初期構築：50万円〜120万円（申請種別・承認ルート数による）
  • 運用：Slack / Teams は既存契約をそのまま利用（追加ライセンス不要）+ 保守プラン

Optiensでの構築事例

Optiens社内の経営オペレーションでは、AIエージェントからの「人間の判断が必要な事項」を Slack 風UI に投稿し、代表がスマホで承認/却下する仕組みを運用しています。承認者の動線にAIエージェントを組み込む という発想は、人間が中心にいながらAIに業務を任せる体制を作るうえで効果が高いパターンです。

「社内チャットがすでに業務の中心になっている」企業には、最も自然なフィット感が得られます。

パターン3：専用UI型——複数承認ルート・履歴可視化対応

申請者・承認者・管理者がそれぞれの専用画面を持ち、案件一覧・ステータス・履歴を可視化するパターンです。BaaS（Supabase など）+ Astro / Next.js で構築します。

仕組み

[申請者画面] ──┐
[承認者画面] ──┼─→ [Supabase（DB + 認証）] ←─→ [管理者画面（履歴・分析）]
[管理者画面] ──┘                ↓
                           [通知（メール/チャット）]

ロール別の画面を持つことで、「申請の進捗を一覧で見たい」「過去の承認履歴を集計したい」 といった業務管理者の要望に応えられます。

Salesforce Approval Process との対応

Salesforce 機能専用UI型での実装
申請受付専用入力画面（業務に最適化）
ルール判定DB側関数 or サーバスクリプトで条件分岐
通知メール / チャット / アプリ内通知の組み合わせ
承認・却下承認者ダッシュボードでまとめて処理
差戻しコメント・添付ファイル付きで返却
履歴保存DB に完全記録 + 管理画面で検索・集計
期限管理自動エスカレーション・サマリ通知

ここまで作り込めば、Salesforce Approval Process が提供する機能のほぼ全てを、業務に合わせた形で実装 できます。

メリット・デメリット

メリット

  • 御社の業務フローに 完全に合わせた画面 が組める
  • 履歴・集計・分析が自由（CSV エクスポートやBI連携も可）
  • 承認ルートの追加・変更が、ライセンス制約なく行える
  • データは御社名義のクラウドプロジェクトに格納され、いつでもエクスポート可能

デメリット

  • 初期構築コストが3パターン中で最も高い
  • 業務分析・画面設計の工程が必要（最低でも1〜2ヶ月）
  • 利用者向けの簡易マニュアル整備が必要

想定費用

  • 初期構築：120万円〜300万円（申請種別・ロール数・承認ルート複雑度による）
  • 運用：Supabase 等のクラウド実費（月額数千円〜2万円程度）+ 保守プラン

Optiensでの構築事例

Optiens では、業務専用UI を Astro + Supabase で構築するパターンを複数運用しています。たとえば社内向けの 小説推敲メモ管理ツール は、PC/スマホ双方から操作でき、メモ保存と同時に Google Tasks にタスクが自動生成されるよう設計されています。「業務専用UI を持つことの強さ」 は、現場で使ってみるとすぐに実感していただけるはずです。

「承認ルートが複数あり、履歴の管理も重要」「監査対応で履歴の証跡が必要」という規模感であれば、このパターンが最も投資対効果に見合います。

3パターン比較表

観点メールベース型チャット型専用UI型
初期構築費30〜80万円50〜120万円120〜300万円
月額運用費数千円 + 保守既存チャット + 保守数千〜2万円 + 保守
承認者の学習コストほぼゼロほぼゼロ軽微（数十分の説明）
複雑な承認ルート不向き向く完全対応
履歴の可視化最低限スレッド単位完全対応
監査対応弱い中強い
ライセンス料ゼロゼロ（既存チャット利用）ゼロ

どのパターンを選ぶか——3つの判断軸

実務でパターンを選ぶ際、Optiens では次の3軸で判断しています。

軸1：承認件数 × 種別数

  • 月10件以下・1〜2種別 → メールベース型で十分
  • 月10〜100件・3〜5種別 → チャット型がフィット
  • 月100件超・5種別超 → 専用UI型の投資対効果が出る

軸2：承認者の業務動線

  • 承認者が メールを開く頻度が高い → メールベース型
  • 承認者が 常時 Slack / Teams を使っている → チャット型
  • 承認者が 管理者・経営者で、一覧で俯瞰したい → 専用UI型

軸3：監査・履歴要件

  • 「承認したことが分かれば良い」 → メールベース型
  • 「承認の文脈・経緯も残したい」 → チャット型
  • 「監査・コンプラ対応で履歴の完全性が必要」 → 専用UI型

段階的に育てる進め方

「いきなり専用UI型を作る」必要はありません。Optiens がよく提案するのは、次のような段階導入です。

Step 1: メールベース型で1つの稟議を試す（1〜2ヶ月）
   ↓
Step 2: 効果を確認したらチャット型に拡張（既存Slack活用）
   ↓
Step 3: 承認件数・種別が増えたら専用UI型に統合

最初から完璧を目指さず、業務での効果を確認しながら拡張していく ほうが、トータルの投資効率が高くなります。これは Optiens が一貫して提案している進め方で、汎用SaaS の「最初から全部入り」とは対照的なアプローチです。

まとめ：ライセンス料を払わずに「承認の仕組み」を持つ

Salesforce Approval Process は強力な仕組みですが、中小企業の規模感では「全部入り」がオーバースペック になりがちです。

本記事で紹介した3パターンは、いずれも 月額ライセンス料ゼロ で承認ワークフローを持てる構成です。

  • メールベース型：最小コストで稟議化したい
  • チャット型：Slack / Teams を業務動線にしたい
  • 専用UI型：複数承認ルート・履歴可視化・監査対応まで欲しい

御社の承認業務にどのパターンが効きそうか、AI活用診断 で AI 活用の方向性 をレポートでお届けします。具体的な構成案・導入見積は 詳細レポート（¥5,500税込） でお届けします。

AI活用診断を申し込む（/free-diagnosis） / サービスメニューを見る（/service）

関連リンク

← ブログ一覧へ