承認ワークフローシステム — シャチハタ卒業、電帳法対応の自社基盤へ
アネブル／ENA の「ハンコ・紙・別紙」でまわしている承認業務を、止めずに・なくさず・改ざんされずに 進めるために、Fab Forward では 自社の承認ワークフローシステム をつくっています。先行する各システムと同じ考え方——「1 つの基盤で、会社ごとの様式にあわせて使える」——を、決裁・稟議・各種申請の分野に広げるものです。
ひと言でいうと、こうです。
紙とハンコでやっていた申請・承認を、画面の中で。決裁が下りたら振込依頼まで自動で起こし、原本は 7 年、改ざんできない形で残す。
本資料はプロジェクト報告です。経営会議でのご確認を目的に、技術用語をできるだけ避けてまとめています。柱は 4 つ——①聞いたこと ②調べたこと ③つくる中身 ④どこまで来たか——の順にご説明します。開発できる範囲はすでに完成し、本番サーバーで動いています → 実際に触ってみる（デモ環境・ログイン）。
なぜ、いま必要なのか
きっかけは、現在つかっている承認サービス（シャチハタクラウド／旧親会社の X-Point）が使えなくなることです。
X-Point は 10 月 1 日で使用禁止。 それまでに、自社で持てる承認の仕組みへ移らなければなりません。
しかも単に置き換えるだけでなく、電子帳簿保存法（電帳法） への対応——「電子で受け取った書類は、決められたルールで電子のまま保存する」——も同時に満たす必要があります。期限のある、待ったなしの課題 です。
① 聞いたこと — 現場ヒアリング（6/19）
アネブル／ENA の実務担当の方々に、いまの承認業務の困りごとを直接うかがいました（2026 年 6 月 19 日）。出てきた「困りごと」はとても具体的でした。
| いまの困りごと | なぜ困るか |
|---|---|
| 差し戻されると、最初からやり直し | 直してもらおうと突き返すと「別の申請」として作り直しになり、元の番号とつながらない。ここが一番の痛み。 |
| 保存期間が短く、過去が探せない | 1 年ほどで消え、決裁番号も振られないため、後から追えない。電帳法にも足りない。 |
| 必須項目の抜け漏れ | 自由に書ける様式なので、項目が埋まっていないまま回ってきて差し戻しが増える。 |
| 「別紙」運用の手間 | 決裁書とは別に振込依頼書を毎回つくり直している（小田木さんご要望）。 |
| Excel の書式崩れ・画像が貼れない | 添付すると関数や体裁が崩れる。画像の添付ができない。 |
この声から決めた「外せない条件」（★）
- 様式を固定 して、必須項目の抜け漏れを防ぐ
- 差し戻しても、同じ書類・同じ番号のまま 直して出し直せる（＋コメントを残す）
- ファイルも画像も添付 でき、改ざんできない形で原本を保存
- 決裁が下りたら、振込依頼を自動で起票（「別紙」を手で作る運用をやめる）
② 調べたこと — 既製品と社内アンケート
「買えば済むのでは？」をきちんと確かめました。既製の承認サービスを調べ、社内アンケート（49 名・3〜4 月）で「本当に欲しい機能」を順位づけしました。
社内アンケートで欲しいとされた機能（上位順）
| 順位 | 欲しい機能 | 希望の強さ |
|---|---|---|
| 1 | 検索・履歴管理（キーワード／期間／種別で過去を探す） | ほぼ全員 |
| 2 | 進捗の見える化・通知（いまどこで止まっているか） | 9 割超 |
| 3 | 修正・差し戻しのしやすさ | 8 割超 |
| 4 | 分かりやすい画面（説明なしで使える） | 8 割 |
| 5 | ルート・様式の自動化（毎回手で設定しない） | 7 割 |
| 6 | 印影（押印枠） ——「あった方がいい」 | 約 48% |
「買う」ではなく「自社でつくる」と決めた理由
| 既製品では難しかった点 | 自社化で解けること |
|---|---|
| 差し戻しが「別申請」になり番号がつながらない | 同じ書類・同じ番号のまま 直せる仕組みにできる |
| 決裁と振込依頼が別管理 | 決裁 → 振込依頼を 自動でつなげる（ENA 固有の流れ） |
| 親会社システムの 10/1 廃止に間に合わない | 9 月運用開始 にあわせて、必要な分から段階的に出せる |
| 電帳法対応・保存ルールが製品任せ | 保存期間・改ざん防止を 自分たちの基準 で持てる |
③ つくる中身 — 実装する仕様
承認の「心臓部」（エンジン）
どんな様式・どんなルートでも、この 1 つの基盤で扱えるようにしています。
| できること | 中身 |
|---|---|
| 直列・合議・条件分岐 | 順番に回す／複数人の同意（AND・OR）／金額で分岐（例：20 万以上は社長、未満は部長） |
| 回覧（通知だけ） | 承認は不要だが見ておいてほしい人へ |
| 差し戻し（最重要） | 同じ書類・同じ番号のまま 差し戻し → 直して再申請。コメントも残る |
| 取消 | 申請者が途中で取り下げられる |
| 自動採番 | ルートごとに決裁番号を自動で発番（後から探せる） |
決裁 → 振込依頼の「自動起票」と、長期保存
- 決裁が下りたら、振込依頼書が自動でできあがる。 決裁番号・部署・金額が引き継がれ、振込金額（①予定額 −②手数料）は自動計算。口座名義はカタカナのみ、金融機関コード／名はどちらか必須——といった現場のルールも様式に組み込みます。
- 電帳法対応の保存 = 原本をそのまま保存し、指紋（ハッシュ）で改ざんを検知、削除できないようにし、7 年間保管。だれが・いつ・何をしたかの操作記録（監査ログ）も残します。
- 印影 = 承認のステップに、氏名・役職・日時の入った押印枠を表示（画像のハンコは不要）。
24 様式を、3 つの波で展開
実際の決裁書・稟議書・各種申請書（全 24 様式）を、業務インパクトの大きい順に段階展開します。
段取り — まず「アプリの中」で動かし、つなぎ込みは後追い
9 月の日程を 社外の調整待ちでブロックしない よう、二段構えにします。
| 項目 | 9 月トライアル時点 | 後追い（運用後） |
|---|---|---|
| ログイン | アプリ内ログイン（M365 の名簿を取り込み） | Microsoft 365 のシングルサインオン |
| ファイル保存 | アプリ内の電帳法対応ストレージ | SharePoint へ切替（差込口の差し替えだけ） |
④ どこまで来たか — 進捗
開発できる範囲は「ほぼ完成」、すでに本番サーバーで動いています
承認の心臓部だけでなく、実際の様式・電帳法・振込連携・印影・通知・検索まで、開発できる範囲はひと通り完成し、テストも通っています。すでに本番サーバー（ff-02）にデプロイ済みで、下記のデモ URL から実際に触れます。
- 承認エンジン（直列／合議／金額分岐／回覧／差し戻し＝同一番号／取消）= 完成・検証済み
- 決裁 → 振込依頼の 自動起票（特別決裁も対象）= 完成・検証済み
- 24 様式すべてを、お預かりした原本どおりの 実レイアウト で実装（#24 稟議書も新規作成）= 完成・検証済み
- 電帳法保存（原本＋指紋＋削除不可＋7 年）・添付／画像・印影・メール通知・検索／履歴 = 完成・検証済み
- 入力時のライブ検証（合計の自動計算・フリガナのカナ強制・「いずれか必須」）= 完成・検証済み
- 自動テスト 169 件＋通しテスト（標準・実組織）すべて green（2026/6/21 再確認）
- 本番サーバー（ff-02）にデプロイ済み・稼働中
工程の状況（6 月 → 9 月）
| 工程 | 中身 | 状態 |
|---|---|---|
| R0 | 実組織マスター（小田木・平川・山内・清水・大嶋・長谷川＋各役職）・ログイン基盤 | ✅ 完成・検証済み |
| R1 | ファイル／画像添付・電帳法ストレージ（原本＋指紋＋削除不可＋7 年） | ✅ 完成・検証済み |
| R2 | 振込依頼の様式・決裁→振込の自動起票・印影 | ✅ 完成・検証済み |
| R3 | 24 様式すべてを実レイアウトで展開（#24 稟議書を新規作成） | ✅ 完成・検証済み |
| R4 | メール通知（承認・差し戻し・滞留）・検索／履歴 | ✅ 完成・検証済み |
| R5 | 本番デプロイ・バックアップ・受入テスト（UAT）・利用者教育 | 🔄 最終工程（実名簿・UAT 待ち） |
段取りの鍵 — まず強力なモデルで「土台＋検証ゲート」を手組みし、様式やルートの量産は自動化ループで回しました。「バンドエイドな直しはしない・検証してから出す」 を徹底しています。
実際に触ってみる — デモ環境
完成した範囲は、いまこのアドレスから実際に操作できます。役割（受付・承認・決裁・閲覧）によって見える画面・押せるボタンが変わるので、複数アカウントで見比べてください。
- URL: https://approval.fab-forward.co.jp
- ログイン: 下表の「ログイン ID（メール）」と「パスワード」で入れます（パスワードは全アカウント共通の仮設定）。
| ログイン ID（メール） | パスワード | 役割 | デモで見えること |
|---|---|---|---|
applicant@ena.example.jp | password | 申請者（テスト） | 新規申請の起案 → 承認の進み具合、差し戻し後の 同じ番号での再申請 |
odagi@ena.example.jp | password | 受付・総務人事部長（小田木） | 多くの申請の 受付・差し戻し、総務系の最終決裁 |
president@ena.example.jp | password | 社長 | 20 万以上の決裁書・稟議の 最終決裁 → 振込依頼の自動起票 |
honbu-kanri@ena.example.jp | password | 管理本部長 | 承認 2（本部長承認） |
director@ena.example.jp | password | 取締役 | リース・固定資産・取引登録の決裁 |
hirakawa@ena.example.jp | password | システム G 長（平川） | システム関連申請の承認 |
yamauchi@ena.example.jp | password | 経理・閲覧（山内） | 決裁書の閲覧、検索・履歴 |
⚠️ 上記はデモ期間中の仮パスワードです。実社員名簿の取り込み・本番運用の前に、全アカウントのパスワードを変更します。メールのドメイン（
@ena.example.jp）も仮のもので、Microsoft 365 の名簿を取り込んだ時点で実際のものに置き換わります。
おすすめデモコース（5 分）
applicantでログイン → 新規申請（ENA 決裁書 20 万以上）を 起案 → 承認の流れが図で見えるodagiに切り替え → 受付で 差し戻し（コメント付き）→ もう一度applicantで 同じ番号のまま 直して再申請（※最重要の差別化）- 承認を進め、
presidentで 最終決裁 → 振込依頼書が自動でできあがる のを確認 yamauchiで 検索・履歴 から過去の申請を種別・期間で探す
6/26（金）クライアント確認会 — 「最終確認」の位置づけ
当初 6/26 は「開発を止めている項目（実様式のレイアウト等）を確定する場」でしたが、原本を先行受領して実装を済ませたため、いまや 運用に向けた最終確認の場 になりました。残る確認事項は、人手・社外調整に依存するものだけです。
| # | ねらい | いまの状況 |
|---|---|---|
| A | X-Point 廃止（10/1）までに移行 | 開発できる範囲は完成・本番稼働中。9 月トライアルへ最終工程 |
| B | 差し戻し＝同一番号・別紙廃止 という現場の要望 | 完成・検証済み（上のデモで体験できます） |
| C | 電帳法（7 年・改ざん不可） | 完成・検証済み（保存期間 7 年で本番固定） |
| D | 実様式・特別決裁の振込連携 | 完成・検証済み（24 様式＋#24 稟議＋#22 特別決裁の自動起票） |
| E | 6/26 でお願いしたいこと | 全社員名簿（M365 エクスポート）・実ドメイン・SSO／SharePoint の穴開け時期 |
本資料はプロジェクト報告です（更新 2026/6/22）。技術的な詳細（仕様書・テスト・組織マスター・様式定義・6/26 Q&A 台帳）は社内資料（approval-sys リポジトリ docs/）に整理済みです。画像はイメージ（AI 生成）。