稟議・承認フローをNext.jsで内製する｜ワークフローSaaSとの比較と設計【2026年版】

「稟議が誰の承認待ちで止まっているか分からない」「拠点によって承認ルートが違い、SaaSの標準テンプレートでは表現しきれない」——中小企業の社内システム担当者から、こうした相談をよく受けます。

紙の稟議書やExcel台帳、メール回覧で運用してきた承認フローは、組織が育つほど「誰が今のボトルネックか」が見えなくなります。かといって、ワークフローSaaSを導入すればすべて解決するわけでもありません。この記事では、稟議・承認フローをSaaSではなくNext.jsフルスクラッチで内製する場合の判断基準・設計・費用感・導入手順を整理します。

先に、要点をまとめます。

• ワークフローSaaSが向くのは「承認ルートが定型的」「早く安く導入したい」企業。内製が向くのは「承認ルートが複雑で条件分岐が多い」「受発注・会計等の基幹システムとリアルタイム連携したい」企業
• Next.js実装では、申請データ・承認ルート定義・承認履歴を分離したテーブル設計にし、承認ルートは「条件×承認者」のルールテーブルとして持たせるのが壊れにくい
• 最小構成であれば、対象の稟議種別を絞った上で1〜2ヶ月程度・実装だけで80万円台〜250万円台が目安（承認ルートの複雑さ・既存システムとの連携有無で変動）

ただし、内製の承認フローには後述する「承認ルート変更にどう追従するか」という運用上の注意点があります。この点は後半で詳しく説明します。

ワークフローSaaSと内製、どちらを選ぶべき？

承認ルートが定型的で早く導入したいならSaaS、条件分岐が複雑または他システムとの連携が必要なら内製が向きます。

市場には kickflow・楽々WorkflowII・承認TIME をはじめ、多くのクラウド型ワークフローシステムがあります。これらは「稟議書の申請・承認・決裁」という業務を電子化する点では優れており、導入の速さとコストの低さが最大の強みです。

一方で、SaaSのワークフロー機能は「汎用的な承認ルートのテンプレート」を前提に作られています。以下のようなケースでは、SaaSの標準機能では対応しきれず、内製を検討する価値があります。

• 承認ルートの条件分岐が複雑：金額帯・拠点・案件種別によって承認者の組み合わせが変わり、SaaSの設定画面では表現しきれない
• 他の基幹システムとリアルタイムに連携したい：承認完了と同時に受発注システムの在庫を引き当てる、会計システムに仕訳を自動連携する、といった処理をワンストップで行いたい
• 申請フォームの項目が業務ごとに大きく異なる：稟議・経費精算・購買申請・契約審査など、申請ごとに必要な項目・添付書類・チェック項目がまったく異なり、SaaSの汎用フォームでは入力の手間が減らない
• 社内の別システム（勤怠・顧客管理・案件管理）のデータを承認画面に自動反映したい：申請者が手入力する情報を減らし、入力ミスを防ぎたい

御社の状況がこれらの複数に当てはまるなら、SaaSの設定を工夫して延命するより、フルスクラッチでの内製を前提に検討を始める時期です。特に「他の基幹システムとの連携」は見落とされがちですが、承認フローだけを電子化しても、その前後の業務（受発注・会計処理）が手作業のままでは、全体の業務時間はさほど短縮されません。

実際に私たちが相談を受けるケースでは、「稟議書自体はSaaSで電子化できているが、承認完了後の受発注登録や会計仕訳は結局手作業で二重入力している」という声が目立ちます。承認フローの電子化と、前後の基幹業務の連携をセットで設計できるかどうかが、内製を選ぶ判断の分かれ目になります。逆に言えば、承認フロー単体の電子化が目的であれば、無理に内製せずSaaSを使うほうが合理的です。内製の判断は「この承認フローの先に、どの基幹業務が連携するか」を先に洗い出してから行うのが安全です。

承認フローをNext.jsで内製する場合の設計はどうなる？

申請データ・承認ルート定義・承認履歴を分離したテーブル設計にし、承認ルートは「条件×承認者」のルールテーブルとして持たせるのが壊れにくい設計です。

承認フローの内製で最も事故が起きやすいのは、承認ルートをコードに直接書いてしまうことです。「金額が50万円以上なら部長承認」「拠点が本社以外なら追加でエリア統括の承認」といった条件分岐をif文で書くと、組織変更や承認ルート変更のたびにコード修正とデプロイが必要になり、運用が回らなくなります。

推奨する設計は以下の3層構造です。

1. 申請データ（Request）：申請種別・金額・拠点・申請者・添付ファイル等、申請1件ごとの内容を保持
2. 承認ルート定義（ApprovalRule）：申請種別×条件（金額帯・拠点等）に対して、承認者の役職・順序を定義するルールテーブル。管理画面から非エンジニアが編集できるようにする
3. 承認履歴（ApprovalStep）：申請1件に対して、どの承認者がいつ承認・却下・差し戻したかを1ステップずつ記録するテーブル

この構成にすると、承認ルートの変更は「ApprovalRuleテーブルの行を管理画面から編集する」だけで完結し、コード修正・再デプロイが不要になります。Next.jsのServer Actionsで承認アクション（承認・却下・差し戻し）を実装し、承認完了時に次のステップの承認者へ通知を送る設計が一般的です。権限周りはRBACによる権限設計の考え方をそのまま流用でき、「誰が承認者ロールを持つか」と「その申請の承認ルートに含まれるか」を分けて判定する必要があります。

承認完了後に他システムへ連携する場合（受発注の在庫引き当て、会計システムへの仕訳連携等）は、承認ステップの最終ステータス変更をトリガーに、非同期のジョブとして連携処理を実行する設計にすると、連携先システムの応答が遅い場合でも承認画面の操作性を落とさずに済みます。

画面設計では、承認者向けの「承認待ち一覧」画面が最も使用頻度の高い画面になります。申請日順・金額順・滞留日数順に並び替えられるようにし、金額や添付見積書などの主要な判断材料を一覧上で確認できるようにしておくと、承認者が申請の詳細画面まで開かなくても大半の判断ができるようになります。承認者の多くは決裁者としての本業務が別にあるため、「一覧の一行を見るだけで承認できるか却下すべきかの見当がつく」設計にできるかどうかが、現場での定着度を大きく左右します。

また、申請者向けの画面では「今、自分の申請がどの承認者の手元で止まっているか」をひと目で分かるようにするステータス表示が重要です。紙やメール回覧の時代に最も不満が多かったのが「今誰が確認しているのか分からない」という状態であり、これを解消できるかどうかが内製システムへの満足度に直結します。承認ステップごとのタイムスタンプと承認者名を時系列で表示するだけでも、問い合わせの多くは解消できます。

AIを承認フローに組み込む場合の設計はどうなる？

AIは「申請内容の不備チェック」「差し戻し理由の下書き」に留め、承認・却下の最終判断は必ず人が行う設計が安全です。

承認フローにAIを組み込みたいという相談も増えていますが、AIに「承認するかどうか」を判断させるのは避けるべきです。承認・却下は責任の所在が明確でなければならない業務であり、AIの判断ミスが起きた場合に「誰が承認したのか」が曖昧になると、内部統制上のリスクになります。

現実的にAIが役立つ範囲は以下です。

• 申請内容の不備チェック：必須項目の未入力、金額と添付見積書の不一致、過去の類似申請との重複などを申請時点で検知し、申請者に修正を促す
• 差し戻し理由・確認事項の下書き：承認者が却下・差し戻しをする際、理由の文章を一から書く手間を減らすため、AIが申請内容を踏まえた下書きを提示し、承認者が確認・修正してから送信する
• 承認待ち滞留の検知と通知：一定期間承認されずに滞留している申請を検知し、承認者本人だけでなくその上長にもリマインドを送る（属人化した「誰かが忘れている」状態を減らす）

いずれも「候補を出す・気づかせる」役割に留め、最終的な承認・却下の意思決定は人が行うという線引きを、設計段階で明確にしておくことが重要です。

導入までの流れとスケジュールは？

最小構成であれば要件整理からリリースまで1〜2ヶ月程度が目安です。

対象の稟議種別を1〜2種類に絞った最小構成であれば、以下のようなスケジュールが一般的です。

対象の稟議種別を絞らず、経費精算・購買申請・契約審査まで一気に内製しようとすると、要件整理だけで数ヶ月かかることが珍しくありません。まずは承認ルートが最も複雑、または他システム連携の必要性が最も高い1種別から着手し、運用が定着してから対象を広げる進め方をおすすめします。

費用感はどれくらいを見ておくべき？

最小構成（対象1〜2種別・承認ステップ2〜3段階）であれば、実装だけで80万円台〜250万円台が目安です。

費用は主に以下の要素で変動します。

• 対象の稟議種別数：1種別のみか、経費精算・購買申請等を含めた複数種別か
• 承認ルートの条件分岐の複雑さ：金額帯のみの単純な分岐か、拠点・案件種別を掛け合わせた多段の分岐か
• 他システムとの連携の有無：会計システム・受発注システムとの自動連携がある場合、連携先のAPI仕様確認や認証周りの実装が追加で発生する
• 通知の実装範囲：メール通知のみか、社内チャットツール（Slack等）への通知連携も含むか

既製のワークフローSaaSは月額数万円〜十数万円程度（ID数による）で導入できるため、単純な費用比較ではSaaSに軍配が上がります。内製の投資対効果は、「SaaSでは実現できない条件分岐や連携がある」「その業務の非効率が放置コストとして積み上がっている」という前提があって初めて成立します。見積もりの内訳の読み方はNext.js受託開発の相場と見積書の内訳で詳しく解説しています。

費用感を判断する際は、初期の実装費用だけでなく、保守運用の費用も含めて比較することをおすすめします。SaaSは月額費用の中に保守・アップデート対応が含まれますが、内製の場合は別途保守契約を結ぶか、社内の情シスが運用を巻き取るかを決めておく必要があります。承認ルートの追加・変更程度であれば管理画面から現場で対応できる設計にしておけば、保守費用を抑えながら運用の柔軟性を保てます。一方、他システムとの連携部分に不具合が起きた場合の切り分けは専門知識が必要になるため、その部分だけは保守契約でカバーしておくといった、部分ごとの使い分けを検討するとよいでしょう。

内製の承認フローで失敗しやすいパターンは？

失敗しやすいパターンには以下のようなものがあります。

• 承認ルートをコードに直接書いてしまう：前述の通り、条件分岐をif文で実装すると、組織変更のたびにコード修正・デプロイが必要になり、運用担当者が変更できない状態に陥る
• 代理承認・休暇時の権限委譲を後回しにする：承認者が長期休暇中に申請が滞留する事故は非常に多く、設計の初期段階で「代理承認者を誰が設定できるか」を決めておく必要がある
• 既存の紙・Excel台帳との並行運用期間を設けない：切り替え当日に全社員がシステムに慣れるわけではないため、一定期間は旧運用と並行し、問い合わせ窓口を用意しておく
• 通知が多すぎて形骸化する：すべての承認ステップで通知を送ると、承認者が通知を見なくなる。滞留時のリマインドなど「本当に必要な場面」に絞って通知を設計する
• 承認履歴を1つのステータスカラムだけで持つ：申請テーブルにstatusカラム1つだけを持たせる設計だと、「誰が・いつ・どの段階で」承認したかの履歴が追えなくなる。前述の3層構造（承認履歴を別テーブルで持つ）にしておくことが重要
• 例外処理を後付けで対応しようとする：「承認者が退職して次の承認先が決まっていない」「金額が想定レンジを超えた特別案件」など、通常ルートに乗らない例外は必ず発生する。設計段階で「例外時に誰が管理者権限で承認ルートを差し替えられるか」を決めておかないと、運用開始後に現場から突き上げを受けてから慌てて対応することになる

これらは、稟議・承認フローに限らず受発注管理の内製や在庫管理の内製でも共通して起きる失敗パターンです。業務フローを電子化するプロジェクト全般に共通する教訓として押さえておくとよいでしょう。私たちが要件定義の場でヒアリングする際も、「通常ルート」だけでなく「今までに困った例外的な申請」を必ず具体的に聞くようにしています。例外パターンを後回しにした設計は、リリース後の運用フェーズで最も手戻りが大きくなる部分だからです。

まずは、現在お使いの稟議書やExcel台帳を1つ手元に置いて、「承認ルートが何パターンあるか」「今月何件の申請がどこで止まっているか」を数えてみてください。承認ルートのパターン数と滞留件数が、SaaSで足りるか内製が必要かを判断する最初の材料になります。

まとめ：この記事で持ち帰れること

この記事では、以下を持ち帰れる内容として整理しました。

• ワークフローSaaSと内製、どちらが自社に向くかの判断基準（承認ルートの複雑さ、他システム連携の有無）
• 承認ルートをコードに書かず、管理画面から編集できるテーブル設計にする重要性
• 最小構成での費用感とスケジュールの目安

承認フローの内製は、対象を絞って小さく始めれば、思ったより大掛かりなプロジェクトにはなりません。まずは自社の稟議種別のうち、最も承認ルートが複雑、または他システムとの連携が必要な1つから検討してみるのがおすすめです。御社の承認ルートの複雑さや連携要件を踏まえた設計・見積もりについては、お気軽にご相談ください。

よくある質問

Q. 既存のワークフローSaaSから内製システムへの移行は簡単ですか？

A. 過去の承認履歴データの移行方法を事前に決めておく必要があります。全履歴を移行するか、切り替え日以降の新規申請のみ新システムで扱い、過去分はSaaS側を参照専用で残すかは、社内の監査要件によって選択が変わります。

Q. 承認ルートの変更は誰でもできるようにすべきですか？

A. 承認ルート自体の変更権限は、情シス担当者や特定の管理者ロールに限定するのが一般的です。現場の承認者が自由に承認ルートを変更できてしまうと、内部統制上のリスクになります。

Q. スマートフォンからの承認には対応できますか？

A. Next.jsはレスポンシブ対応が前提のフレームワークのため、スマートフォンのブラウザから承認操作を行う画面は標準的に実装できます。外出の多い承認者がいる場合は、初期の要件に含めておくとよいでしょう。

Q. 小規模な会社でも内製する価値はありますか？

A. 承認ルートが単純で申請件数も少ない場合は、既製のワークフローSaaSのほうが総コストで有利なケースが多いです。内製の価値が出るのは、条件分岐が複雑、または他システムとの連携が必要な場合に限られます。

Q. 承認フローと在庫管理や受発注管理を同じ基盤で作る意味はありますか？

A. あります。承認完了をトリガーに在庫の引き当てや受発注データの生成まで自動化したい場合、別々のSaaSを組み合わせるより、同一の基盤で一気通貫に設計したほうが連携部分の実装・保守コストを抑えやすくなります。