CASE STUDY ・ 社内DX・ワークフロー ・ FlowGate（仮称）
- React
- TypeScript
- Ant Design
- Laravel
- AWS
※ 機密保持のため、企業名・プロジェクト名・システム画面は仮名およびモックに置き換えています。
電子化の前に、通常ルートと例外ルートを分ける
対象となった事業者では、経費、手当、補助金、休暇など、申請種別によって入力項目と承認経路が異なっていました。紙やExcelを一つのフォームにまとめるだけでは、誰が承認すべきか、承認者が不在なら誰に委任するか、期限を過ぎた申請をどう扱うかが曖昧なままです。
そこで、申請テンプレート、承認ルート、通知・期限管理、会計連携を別々の機能としてではなく、一つの運用として設計しました。通常処理と例外処理を先に分けることで、システムが判断する範囲と人が確認する範囲を明確にしました。
先に解いた4つの設計課題
一括承認は操作を短くできますが、金額や申請種別によって個別確認が必要な場合もあります。対象をまとめて選べることと、まとめて承認してよい条件を分けて設計する必要があります。
- 申請項目の標準化
申請種別ごとに必須項目と明細を定義し、入力漏れを画面で確認できるようにする。
- 承認ルートの分岐
部署、申請種別、条件に応じて承認段階を切り替えられる前提を置く。
- 代理・期限の例外処理
承認者不在、期限超過、差戻しを通常の承認とは別の状態として扱う。
- 承認後の会計連携
承認済みデータだけをCSVで出力し、会計側の取込条件と照合できるようにする。
AMELAが担当した範囲と設計判断
AMELAは、申請・承認ワークフロー基盤の新規構築に参画しました。公開用ケース資料で確認できる構成は、フロントエンドがReact、TypeScript、Ant Design、バックエンドがLaravelとPHP、インフラがAWSとRedis、認証連携がSAML2 SSO、会計連携がCSV出力です。
設計では、申請種別ごとのテンプレートと明細入力、多段階の承認ルート、承認・差戻し、一括承認と代理承認、承認状況の表示と期限アラート、承認済みデータのCSV出力、SAML2 SSOによる認証連携を一つの申請業務フローとして接続しました。
- 領域 01申請テンプレート課題
申請種別ごとに入力項目が異なる
解決策種別ごとの必須項目と明細を定義
- 領域 02承認ルート課題
部署や条件によって確認者が変わる
解決策多段階ルートと承認・差戻しを管理
- 領域 03例外管理課題
承認者不在や期限超過で処理が止まる
解決策代理承認と期限アラートを用意
- 領域 04会計・認証連携課題
承認後の転記と認証を別管理する
解決策CSV出力とSAML2 SSO連携を実装
この事例の根拠と読み方
- 根拠：移行元のAMELA開発ストーリー、公開用デモ、画面資料、CMSに保存された案件情報を照合しました。
- 対象期間：2026年8月17日時点で確認できる公開用ケース資料を対象としています。
- 確認できること：AMELAが新規構築に参画したこと、実装対象の機能、技術構成、申請・承認・期限管理・CSV出力・SSO連携を接続した設計方針を確認できます。
- 確認できないこと：処理時間や工数の削減率、導入期間、開発工数、申請件数、会計処理の正確性、内部統制の有効性、可用性、SLA、個別企業の承認ルートは公開資料だけでは確認できません。
- 公開上の扱い：守秘義務に基づき、企業名、プロジェクト名、システム画面は仮名またはモックに置き換えています。画面内の氏名、金額、日付、件数は説明用であり、実績値として使用していません。
読者が使える実践ツール
画面設計の前に、申請種別ごとの承認ルートを一枚にまとめます。次は経費精算を想定した一般的な記入例であり、FlowGateの実際の運用設定ではありません。
- 受付条件：申請者が費目、利用日、明細、添付資料を入力／不足項目があれば申請前に表示する
- 通常ルート：申請者 → 直属上長 → 経理／各段階で承認者と確認対象を定義する
- 分岐条件：特定の費目や社内規程に該当する場合は部門責任者を追加／条件の管理責任者を決める
- 代理承認：承認者が不在の場合は、事前登録された代理者へ委任／委任期間と操作履歴を残す
- 期限超過：期限前に通知し、超過後は上位承認者または運用担当へ通知／自動承認にはしない
- 差戻し：理由を必須にして申請者へ戻す／再申請時は変更箇所と過去の履歴を確認できるようにする
- 会計連携：最終承認済みのデータだけをCSV出力／出力項目、文字コード、取込エラー時の再処理担当を定義する
自社向けに書き換えるときは、各申請種別に『入力責任者』『承認段階』『分岐条件』『代理者』『期限』『差戻し』『証跡』『連携先』を設定してください。承認権限と代理権限は、同じ項目として扱わないことが重要です。
公開用デモで確認できることと、適用時の注意点
公開用デモでは、申請一覧、申請入力、承認ルート付きの詳細、承認・差戻し、一括承認を一連の画面で確認できます。これは、申請者、承認者、運用担当が同じ状態を参照する構成を示します。
一方で、デモ画面だけでは、実際の社内規程、職務分掌、監査ログの保管期間、本人確認の強度、IDプロバイダーの設定、会計システム側の取込仕様は確認できません。導入時には、少数の申請種別で通常ルートと例外ルートを検証し、承認履歴とCSVの照合まで受入条件に含める必要があります。
導入判断で先に決めること
申請・承認ワークフローの開発では、申請画面より先に、ルートを変更できる責任者、代理承認を認める条件、承認後に渡すデータの正本を決めることが重要です。この三点が曖昧なままでは、電子化後も画面外の確認が残ります。
業務ルールの整理から検討する場合は、AMELAのDXコンサルティング支援もご覧ください。
