条件付き承認ルート
申請種別・提出時の所属部署・金額と優先度から、1〜複数段の直列ルートを決定。同じ優先度で同時に一致し得るルールは設定時に拒否します。申請者本人は承認者になれません。
業務システム開発ポートフォリオ
ApprovalFlow
申請・承認・差戻し・再提出・履歴を
メールやExcel、チャットに分散しがちな社内の申請・承認業務を、1つのWebシステムで扱えるようにしました。単純な申請CRUDではなく、承認経路の決定、差戻しと再提出、承認者の再割当、権限、履歴と監査ログまでを業務ルールとして実装しています。
- 6Features 完了
- 12別AIのReview
- 約12時間記録済み開発工程
- P1 完了Project Complete
1:39で、申請 → 差戻し → 再提出 → 承認者の再割当 → 最終承認 → 履歴・監査ログまでを、1件の申請で通して紹介します。字幕のみ(音声なし)。
ApprovalFlow とは
中小〜中堅企業の購買申請・経費精算を想定した、社内申請・承認のWebシステムです。申請者・承認者・経理・管理者が、それぞれの権限で同じ申請を扱います。動画では、次の流れを1件の申請で通しています。
- 1申請申請者が購買申請を作成し、見積書を添付して提出
- 2承認経路の決定申請種別・所属部署・金額から、提出時に承認経路と承認者を確定
- 3差戻し承認者が理由を付けて差し戻す(理由は履歴に残る)
- 4修正・再提出同じ申請を修正し、第2回として先頭の段階から承認をやり直す
- 5承認者の再割当担当者不在時、管理者が未処理の段階だけ担当を変更(理由必須)
- 6承認再割当先の承認者が承認し、次の段階へ
- 7最終承認直列の全段階が承認され、申請が完了
- 8履歴・監査誰が・いつ・何をしたかを提出回ごとの履歴と監査ログで確認
却下・取下げで終わる経路もあります。差戻し後の再提出は「上書き」ではなく新しい提出回です。第1回の内容・添付・承認経路・差戻し理由はそのまま残ります。
主要機能
提出時 snapshot
提出した時点の申請内容・添付・申請者・部署・承認経路・承認者を、提出回ごとに保存。後から組織やルールを変えても、過去の提出回の意味は変わりません。
差戻し・再提出
差戻し後は同じ申請を修正して再提出。再提出時点のルールで承認経路を決め直し、先頭の段階から承認します。旧提出回と旧承認履歴は保持します。
承認者の再割当
退職・長期不在などに備え、管理者が進行中の提出回の未処理の段階だけ担当を変更できます。変更前後の担当・実行者・理由を記録し、処理済みの段階は変えません。
Role と権限
申請者・承認者・経理・管理者のRole(兼務可)と、提出回ごとの関係(本人・現在の担当・処理した人)で閲覧と操作を判定。画面だけでなくAPIで拒否します。
履歴・監査ログ・証憑
提出・差戻し・再割当・承認などを提出回の履歴と監査ログに記録。PDF / JPEG / PNG の証憑はDBに保存し、保存済みの申請・証憑・履歴を削除する機能は設けていません。
開発した 6 Features の一覧
- F-001認証と本人下書きの縦断導線
- F-002条件ルートと提出回・直列処理
- F-003マスタ管理と未処理step再割当
- F-004保存証憑と経費精算提出
- F-005提出回検索・履歴・Audit投影
- F-006ローカル再現・性能・復旧と主要デモ
特徴的な業務ロジック
申請を保存するだけでなく、「いつ・誰の判断で・どの条件だったか」を後から説明できることを重視しました。
組織変更後も、提出当時の記録を保持
承認者が異動しても、過去の提出回には「提出時: 佐藤 一郎 · 営業部」のように当時の部署・担当がそのまま表示されます。現在のマスタを都度参照して表示を作り直すのではなく、提出時点の内容を提出回として保存しているためです。
技術補足: 申請(現在の下書き)と、不変の提出回・初期の承認段階・現在の担当・確定した操作を別のデータとして持つ。提出回の snapshot と証憑の関連は、DBの権限とトリガーで更新・削除できないようにしている。
未処理の段階だけを、理由付きで再割当
担当者が長期不在でも、申請を止めずに済むよう、管理者が担当を変更できます。対象は進行中の提出回の未処理の段階だけで、処理済みの承認や過去の提出回は変わりません。再割当の画面には、申請本文や金額を出していません。
技術補足: 再割当は割当の版番号で競合を検出し、同じ版への同時変更は1件だけ成立する。変更前後の担当・実行者・理由を割当履歴と監査ログへ同一トランザクションで記録する。
再提出は別の提出回
差戻し後の再提出は第2回として保存し、その時点のルール・組織で承認経路を決め直します。第1回の内容と差戻し理由は残ります。
同時操作でも二重処理しない
同じ承認段階に2人が同時に操作しても、成立するのは最初の1件だけです。後の操作は競合として拒否し、状態・履歴・監査ログが中途半端に残らないようにしています。
設定の共有/排他ロック→申請ロックの順に取得し、状態・操作履歴・監査ログは同一トランザクションで保存。成立順は実DBの並行試験で確認。
負荷試験で見つけた問題を設計から是正
20同時セッションの読取り負荷中に、管理変更・パスワード変更が待ち続ける問題を見つけました。原因(ロックの待ち順)を設計文書へ反映してから修正し、再測定で 14/14 件成立・503は0件になりました。
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を設計・実装・レビューなどの役割に分けて開発しました。実装とレビューの役割を分離し、指摘は修正・再レビューまで確認しています。業務判断は開発者本人が行っています。
- 要件整理業務判断 29 件を明文化し、要件へ
- 設計アーキテクチャ・データモデル・API・設計判断(ADR)
- 実装機能(Feature)単位で実装し、自動テストを実行
- 独立AIレビュー実装とは別のAIがレビューし、指摘は修正・再レビュー
- 検証実DBの統合テスト・E2E・負荷試験・Backup/Restore
- 最終監査機能横断の整合と残置事項を確認し、完成を判断
使用した 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を更新してから実装を直しました。修正前の実装で失敗し、修正後に成功する試験を追加しています。
このプロジェクトで担当した範囲
ApprovalFlowの成果物と記録から確認できる範囲です。AIとの分担は「開発プロセス(ADS)」に記載しています。
- 業務要件の整理と、業務判断 29 件の明文化
- アーキテクチャ・データモデル・APIの設計(ADR 3 件)
- 条件付き承認ルートと、提出時 snapshot・提出回の設計
- Backend(Spring Boot)・Frontend(React)・DB(PostgreSQL)の実装
- Role と認可(画面とAPIの両方での判定)
- 履歴・監査ログと、差戻し・再提出・再割当の記録
- 同時操作・トランザクションの整合性の設計と是正
- 負荷試験・Backup / Restore による検証
- Review・最終監査を経た完成判断
技術構成
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で受けた指摘のうち、業務上の影響が小さい一部の改善提案は、理由を記録したうえで見送っています。
- データ動画・画面に登場する人物・部署・申請・見積書はすべて架空です。
- 公開範囲本ページでは成果物・動作・検証結果を公開しています。ソースコードは公開していません。