ApprovalFlow

業務システム開発ポートフォリオ

ApprovalFlow

申請・承認・差戻し・再提出・履歴を一元管理する社内承認システム

メールやExcel、チャットに分散しがちな社内の申請・承認業務を、1つのWebシステムで扱えるようにしました。単純な申請CRUDではなく、承認経路の決定、差戻しと再提出、承認者の再割当、権限、履歴と監査ログまでを業務ルールとして実装しています。

  • Java 21
  • Spring Boot
  • React
  • TypeScript
  • PostgreSQL
  • Docker Compose
  • 6Features 完了
  • 12別AIのReview
  • 約12時間記録済み開発工程
  • P1 完了Project Complete

1:39で、申請 → 差戻し → 再提出 → 承認者の再割当 → 最終承認 → 履歴・監査ログまでを、1件の申請で通して紹介します。字幕のみ(音声なし)。

Hero版を直接開く(10.9MB) · 完全版を直接開く(12.9MB)

  1. 何を

    申請から最終承認・履歴確認までを扱う社内承認システムを、要件整理から画面・検証まで一通り開発。

    業務フローを見る
  2. 特徴

    提出時点の内容・承認経路・担当者を保持。差戻し後は別の提出回として再提出し、組織が変わっても当時の記録は変わらない。

    業務ロジックを見る
  3. 検証

    6 Featuresすべてで、実装とは別のAIによるReviewを経て完了。実PostgreSQLでの統合テスト・E2E・20同時セッション負荷・Backup/Restoreまで確認。

    品質実績を見る

ApprovalFlow とは

中小〜中堅企業の購買申請・経費精算を想定した、社内申請・承認のWebシステムです。申請者・承認者・経理・管理者が、それぞれの権限で同じ申請を扱います。動画では、次の流れを1件の申請で通しています。

  1. 1申請申請者が購買申請を作成し、見積書を添付して提出
  2. 2承認経路の決定申請種別・所属部署・金額から、提出時に承認経路と承認者を確定
  3. 3差戻し承認者が理由を付けて差し戻す(理由は履歴に残る)
  4. 4修正・再提出同じ申請を修正し、第2回として先頭の段階から承認をやり直す
  5. 5承認者の再割当担当者不在時、管理者が未処理の段階だけ担当を変更(理由必須)
  6. 6承認再割当先の承認者が承認し、次の段階へ
  7. 7最終承認直列の全段階が承認され、申請が完了
  8. 8履歴・監査誰が・いつ・何をしたかを提出回ごとの履歴と監査ログで確認

却下・取下げで終わる経路もあります。差戻し後の再提出は「上書き」ではなく新しい提出回です。第1回の内容・添付・承認経路・差戻し理由はそのまま残ります。

主要機能

条件付き承認ルート

申請種別・提出時の所属部署・金額と優先度から、1〜複数段の直列ルートを決定。同じ優先度で同時に一致し得るルールは設定時に拒否します。申請者本人は承認者になれません。

提出時 snapshot

提出した時点の申請内容・添付・申請者・部署・承認経路・承認者を、提出回ごとに保存。後から組織やルールを変えても、過去の提出回の意味は変わりません。

差戻し・再提出

差戻し後は同じ申請を修正して再提出。再提出時点のルールで承認経路を決め直し、先頭の段階から承認します。旧提出回と旧承認履歴は保持します。

承認者の再割当

退職・長期不在などに備え、管理者が進行中の提出回の未処理の段階だけ担当を変更できます。変更前後の担当・実行者・理由を記録し、処理済みの段階は変えません。

Role と権限

申請者・承認者・経理・管理者のRole(兼務可)と、提出回ごとの関係(本人・現在の担当・処理した人)で閲覧と操作を判定。画面だけでなくAPIで拒否します。

履歴・監査ログ・証憑

提出・差戻し・再割当・承認などを提出回の履歴と監査ログに記録。PDF / JPEG / PNG の証憑はDBに保存し、保存済みの申請・証憑・履歴を削除する機能は設けていません。

開発した 6 Features の一覧
  1. F-001認証と本人下書きの縦断導線
  2. F-002条件ルートと提出回・直列処理
  3. F-003マスタ管理と未処理step再割当
  4. F-004保存証憑と経費精算提出
  5. F-005提出回検索・履歴・Audit投影
  6. F-006ローカル再現・性能・復旧と主要デモ

特徴的な業務ロジック

申請を保存するだけでなく、「いつ・誰の判断で・どの条件だったか」を後から説明できることを重視しました。

組織変更後も、提出当時の記録を保持

承認者が異動しても、過去の提出回には「提出時: 佐藤 一郎 · 営業部」のように当時の部署・担当がそのまま表示されます。現在のマスタを都度参照して表示を作り直すのではなく、提出時点の内容を提出回として保存しているためです。

技術補足: 申請(現在の下書き)と、不変の提出回・初期の承認段階・現在の担当・確定した操作を別のデータとして持つ。提出回の snapshot と証憑の関連は、DBの権限とトリガーで更新・削除できないようにしている。

承認者が異動した後も、第1回の経路は提出当時の部署「営業部」のまま表示
承認者が異動した後も、第1回の経路は提出当時の部署「営業部」のまま表示

未処理の段階だけを、理由付きで再割当

担当者が長期不在でも、申請を止めずに済むよう、管理者が担当を変更できます。対象は進行中の提出回の未処理の段階だけで、処理済みの承認や過去の提出回は変わりません。再割当の画面には、申請本文や金額を出していません。

技術補足: 再割当は割当の版番号で競合を検出し、同じ版への同時変更は1件だけ成立する。変更前後の担当・実行者・理由を割当履歴と監査ログへ同一トランザクションで記録する。

Adminが未処理の課長承認を再割当。変更前後・実行者・理由を記録
Adminが未処理の課長承認を再割当。変更前後・実行者・理由を記録

再提出は別の提出回

差戻し後の再提出は第2回として保存し、その時点のルール・組織で承認経路を決め直します。第1回の内容と差戻し理由は残ります。

同時操作でも二重処理しない

同じ承認段階に2人が同時に操作しても、成立するのは最初の1件だけです。後の操作は競合として拒否し、状態・履歴・監査ログが中途半端に残らないようにしています。

設定の共有/排他ロック→申請ロックの順に取得し、状態・操作履歴・監査ログは同一トランザクションで保存。成立順は実DBの並行試験で確認。

負荷試験で見つけた問題を設計から是正

20同時セッションの読取り負荷中に、管理変更・パスワード変更が待ち続ける問題を見つけました。原因(ロックの待ち順)を設計文書へ反映してから修正し、再測定で 14/14 件成立・503は0件になりました。

Role と権限

画面に出さないだけでなく、現在の権限をAPIで毎回判定します。検索・履歴・添付・監査ログのどの経路からも、権限外の申請内容は取得できません。

Roleごとの主な利用範囲(Roleは兼務可。画面メニューとAPIの認可が一致)
Role主な業務制限
申請者
EMPLOYEE		購買・経費の申請作成・提出・取下げ、自分の申請と提出回の閲覧他人の下書きや、関係のない提出回は閲覧できない
承認者
APPROVER		現在担当している段階の承認・差戻し・却下閲覧できるのは、現在の担当か自分が処理した提出回のみ。担当を外れると操作できない
経理
BACKOFFICE		全社の提出回の検索・閲覧承認操作はできない
管理者
ADMIN		ユーザー・部署・承認担当・承認ルールの管理、承認者の再割当、監査ログ管理者であることだけでは申請本文を閲覧できない(管理に必要な情報のみ)
承認者の差戻し理由を、提出回の履歴として保存
承認者の差戻し理由を、提出回の履歴として保存
監査ログ。提出・差戻し・再割当・承認を実行者・日時とともに記録
監査ログ。提出・差戻し・再割当・承認を実行者・日時とともに記録
  • Sessionごとに、現在有効なアカウント・Role・提出回との関係をサーバー側で判定(過去の提出内容を権限の根拠にしない)
  • Session認証 + CSRF対策。初回ログイン時のパスワード変更を強制し、管理者による再発行で旧Sessionを無効化
  • 状態の変更・操作履歴・監査ログは一体で保存し、片方だけが残らないようにしている

開発・品質実績

数値は、動画の実績カードと同じ記録(ApprovalFlow の実装報告・Review・検証証跡)から自動で取得しています。

Project Complete は、現在承認されている初期Scopeに対して、ローカル環境で動く作品として完了と判断したことを指します。一般公開・納品・本番運用の完了を意味するものではありません。

6 / 6Features 完了要件から分解した機能単位。すべて完了
12別AIによるReviewうち差戻し(Request changes)2回。指摘を修正し再Reviewを経て承認
60PostgreSQL 統合テスト実DB(Testcontainers)で認可・競合・トランザクションを確認
7E2E テストほか Java単体 26・Frontend 9。最終版で全件PASS
20同時セッション負荷申請1万件・提出回3万件で、一覧・詳細 p95 最大 約146ms(基準1秒)
14 / 14負荷中の管理・パスワード変更成立。503 は 0 件
Backup / Restore復旧検証復元後に履歴・証憑のハッシュ・権限制御が一致
0最終監査のブロッカー判定は「条件付き可」。残置事項を確認のうえ P1 完了と判断

各Featureで必須の自動チェック

フォーマット(Spotless / Prettier)・静的解析(SpotBugs / ESLint)・型チェック・単体テスト・実PostgreSQLでの統合テスト・ビルド・秘密情報スキャン(gitleaks)・依存関係の脆弱性検査(OWASP Dependency-Check / npm audit)・E2E を、各Featureの完了前に実行。

追跡した記録

  • 要件機能 14 / 非機能 7
  • 業務判断(明文化)29
  • 設計判断(ADR)3
  • 実装報告(IR)12
  • Review(実装 / 設計)12 / 3
  • Feedback(設計へ戻した問題)1(是正済み)
  • 記録済み開発工程の実行時間約12時間全体設計の開始(2026/09/26)からローカル完成判定(2026/10/02)までは6日間です。途中に約5日の一時停止を含み、記録から確認できた開発工程の実行時間は約12時間(下限)です。要件整理以前の時間と、人間の実働工数・AIの総稼働時間は含みません(未計測)。
  • 設計開始〜完成判定6日間(約5日の一時停止を含む)内訳: 全体設計(Design) 43分47秒 / 9/27 計画開始〜一時停止 7時間25分03秒 / 10/2 再開〜完成判定 3時間56分14秒(下限)

開発プロセス(ADS)

AI Development System(ADS)を使い、AIを設計・実装・レビューなどの役割に分けて開発しました。実装とレビューの役割を分離し、指摘は修正・再レビューまで確認しています。業務判断は開発者本人が行っています。

  1. 要件整理業務判断 29 件を明文化し、要件へ
  2. 設計アーキテクチャ・データモデル・API・設計判断(ADR)
  3. 実装機能(Feature)単位で実装し、自動テストを実行
  4. 独立AIレビュー実装とは別のAIがレビューし、指摘は修正・再レビュー
  5. 検証実DBの統合テスト・E2E・負荷試験・Backup/Restore
  6. 最終監査機能横断の整合と残置事項を確認し、完成を判断

使用した AI / Agent

Codex と Claude Code を工程ごとに使い分け、実装したAIとレビューするAIは常に別の製品・別セッションにしました。

Codex

設計・計画・実装・Review・最終監査などの工程で使用。

Claude Code

設計・計画・実装・Review などの工程で使用。

ChatGPT

開発者本人が AI へ渡す作業指示文の作成補助に使用。設計・実装・Review は担当していない。

AI と開発者の分担

AI に任せた工程

  • 設計文書(要件・アーキテクチャ・データモデル・API・ADR)の作成
  • Feature への分解と、実装指示書の作成
  • 実装と、自動チェックの結果をまとめた実装報告
  • 実装とは別のAIによるレビューと最終監査

開発者本人が行ったこと

  • 業務要件の判断(29 件の業務判断として明文化)
  • Scope・公開・費用など、人が決めるべき事項の判断
  • 工程の開始・中断・再開と、完了の最終判断
  • AI の成果物と自動チェック・Review 結果の確認

問題が見つかったとき

Review の結果

実装Reviewは 12 回行い、うち 2 回は差戻し(Request changes)でした。認証応答に内部用の値が含まれていた問題や、管理者が発行した一時パスワードを本人へ渡せない画面の問題など、自動チェックを通過した後の欠陥をReviewで見つけ、修正・再Reviewを経て承認しています。

設計まで戻した問題

負荷試験で見つかったロックの待ちの問題は、コードだけで回避せず、Feedback として起票し、設計文書とADRを更新してから実装を直しました。修正前の実装で失敗し、修正後に成功する試験を追加しています。

技術構成

Backend

  • Java 21
  • Spring Boot 4.1.1(Web MVC / Security / Data JPA)
  • Flyway(DBマイグレーション)

Frontend

  • React 19
  • React Router 7
  • TypeScript 6(strict)
  • Vite 8

Database / Infra

  • PostgreSQL 18.3
  • Docker Compose(DB・アプリ・Webをコンテナで起動)
  • ローカル環境で完結

Test / Quality

  • JUnit · Testcontainers(実PostgreSQL)
  • Vitest 5
  • Playwright 1.63.0(E2E)
  • Spotless · SpotBugs · ESLint · Prettier · gitleaks · OWASP Dependency-Check

前提と現在の状態

  • Project Complete の範囲現在承認されている初期Scopeに対する、ローカルで動作する作品としての完了です。一般公開・公開デモ・納品・本番運用は行っていません。
  • 実行環境Docker Compose によるローカル環境が前提です。小規模・単一アプリ構成を想定しています。
  • 業務設定値承認金額のしきい値・費目・承認段階は、デモ用の例です。正式な業務設定値は未決定です。
  • 性能値の位置付けローカル環境・架空データ・20同時セッションでの計測値です。公開時の規模やSLAを保証するものではありません。
  • 未実施の検証依存関係の脆弱性検査のうち OSS Index は資格情報がないため未実施です。CI(GitHub Actions)での実行も未実施で、検証はすべてローカル実行です。
  • 見送った指摘Reviewで受けた指摘のうち、業務上の影響が小さい一部の改善提案は、理由を記録したうえで見送っています。
  • データ動画・画面に登場する人物・部署・申請・見積書はすべて架空です。

About the developer

担当領域

ApprovalFlowの成果物と記録から確認できる、担当した範囲です。

  • 業務要件を、承認経路・状態遷移・不変条件・権限の仕様へ落とし込む
  • 提出時 snapshot・履歴・監査ログを含むデータモデルと設計判断(ADR)
  • Spring Boot の Backend と React の Frontend、PostgreSQL の実装
  • 認証・認可、同時操作・トランザクションの整合性の設計と検証
  • 実DBの統合テスト・E2E・負荷試験・Backup/Restore による検証
  • AIを使った開発プロセスの運用(役割分担・レビュー・検証・記録)
  • 見つかった問題を設計まで戻して是正し、完了条件まで進めること

業務ルールの「なぜそうなっているか」を後から説明できるシステムとして、完成まで持っていくことを重視しています。

ご相談について

業務システム開発や、AIを活用した開発プロセスについてご相談いただけます。

ApprovalFlowのソースコードの公開範囲は未定です。コードは面談時に画面共有でご説明できます。