OrderFlow

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

OrderFlow

受注・在庫・入荷・出荷をつなぐ業務システム

在庫不足時の受注、入荷をきっかけにした自動再引当、Role別のアクセス制御、監査ログまでを実装しました。

開発には AI Development System(ADS)を使いました。ADSは、AIを設計・実装・Reviewなどの役割に分け、自動チェックと再検収を組み合わせて、完成までの工程を管理する開発プロセスです。ADSの進め方を見る

  • 23Features
  • 23/23Review承認
  • 10/10E2E 連続PASS
  • 正式受理Project Complete

1:59で、在庫不足の受注 → 入荷による自動再引当 → Role別の権限制御 → 品質実績を紹介します。字幕のみ(音声なし)。

2分版を直接開く(7.7MB) · 完全版を直接開く(13.9MB)

  1. 何を

    受注・在庫・入荷・出荷を連携する業務システムを、要件定義から画面まで一通り開発。

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

    在庫不足でも受注を確定し、入荷時に自動で再引当。Roleごとの表示・操作・APIの権限もサーバー側で制御。

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

    23 Featuresすべてで、実装と分離したReview工程と再検収を経て、Project Completeとして正式受理。E2E(6テスト)を初期状態から10回連続実行し、全回PASS。

    品質実績を見る

何を作ったのか

受注から出荷までの業務が、在庫の状態を介して連動するシステムです。一つの操作が、在庫・他の受注・監査ログへ自動的に反映されます。

  1. 1受注登録営業担当が下書き(DRAFT)を作成
  2. 2受注確定金額を確定し、在庫を自動で引き当てる
  3. 3在庫が足りない場合確保できた分だけ引き当て、不足分は「未引当」として保持(確定はエラーにしない)
  4. 4入荷・在庫の増加倉庫担当が入荷を登録
  5. 5自動再引当未引当の受注へ、確定日時の古い順に自動で引き当てる。全明細がそろうと ALLOCATED
  6. 6出荷引当が完了した受注だけを出荷(SHIPPED)
  7. 7監査ログ状態変更・引当・在庫変動などを1事象1件で記録

出荷前の受注をキャンセルすると、引き当てていた在庫が解放され、ほかの未引当の受注へ自動で再引当されます(引当のきっかけは「受注確定」「入荷・在庫調整による増加」「キャンセルによる解放」の3つ)。

主要機能

受注管理

下書き作成・確定・キャンセル、一覧検索(ページング・並び替え)。確定後に変更できるのは希望納期・備考のみ。

在庫・引当

「現在庫」と「引当済在庫」の2軸で管理し、利用可能在庫はその差として算出。受注明細単位の部分引当。

入荷・在庫調整

入荷登録と、理由付きの在庫調整(増加・減少)。増加時は自動再引当が起動し、結果を画面に表示。

出荷

引当が完了した受注のみを対象に、出荷先情報を記録して出荷。在庫の2軸を同時に減らす。

顧客・商品マスタ

顧客・商品の登録・更新・無効化。商品は CSV 一括取込(1行でも誤りがあれば全体を取り消す方式)。

ユーザー・監査

ユーザーとRoleの管理(初回ログイン時のパスワード変更、最後の有効な管理者の保護)。監査ログの検索・閲覧。

開発した 23 Features の一覧
  1. F-001開発基盤構築
  2. F-002認証・監査ログ基盤
  3. F-003認可共通機構・ユーザー管理API
  4. F-004顧客マスタ
  5. F-005横断的エラーハンドリング・Pagination基盤
  6. F-006商品マスタ
  7. F-007商品CSV一括取込
  8. F-008在庫基盤
  9. F-009受注登録・更新
  10. F-010受注確定+自動引当コア
  11. F-011入荷登録
  12. F-012在庫調整
  13. F-013出荷登録
  14. F-014受注キャンセル
  15. F-015監査ログ閲覧UI・API
  16. F-017Frontend基盤・認証・ユーザー管理画面
  17. F-018マスタ・在庫画面
  18. F-019受注・出荷・キャンセル・監査ログ画面
  19. F-016通し検証・NFR実測・E2E全経路確認
  20. F-020受注確定・キャンセル・出荷における在庫ロック順序是正
  21. F-021残Feedback是正
  22. F-022楽観ロックのversion往復
  23. F-023引当契機の受注状態同期の直列化・最後の有効ADMINの降格禁止・sort方向の検証

UIについて 本デモは業務ロジック・権限制御・データ整合性・検証を中心に実装しており、画面は最小構成です。UIは導入先のデザインシステムや既存コンポーネントに合わせて調整する想定です。

特徴的な業務ロジック

画面の入力をそのまま保存するだけでなく、在庫・受注・監査の整合をサーバー側で保証しています。

在庫が足りなくても受注は確定できる

在庫3個に対して10個の注文でも、確定はエラーにしません。確保できた3個だけを引き当て、残り7個は「未引当」として受注に残します。「入荷待ち」のような別状態を増やさず、明細の未引当数量で表します。

技術補足: 引当は受注明細単位。0 ≤ 引当済数量 ≤ 数量 を常に満たす(DB制約と不変条件で保証)。

在庫3に対して10を受注確定。引当済3・未引当7
在庫3に対して10を受注確定。引当済3・未引当7

入荷をきっかけに自動で再引当

入荷を登録すると、未引当の受注へ自動で在庫が割り当てられ、全明細がそろった受注は ALLOCATED(出荷可能)に変わります。優先順位は受注の確定日時が古い順です。

技術補足: 引当処理は1か所(AllocationService)に集約し、「確定」「入荷・在庫増加」「キャンセル解放」の3つの契機から同じ処理を呼ぶ。在庫の減少調整や出荷では起動しない。

入荷後に自動再引当され、受注がALLOCATEDへ
入荷後に自動再引当され、受注がALLOCATEDへ

業務状態による操作制御

受注の状態は DRAFT → CONFIRMED → ALLOCATED → SHIPPED(出荷前ならキャンセル可)の固定の遷移だけを許可します。APIを直接呼んでも、表にない遷移は拒否します。

出荷は「在庫減少・引当解除・出荷記録・状態更新」を1トランザクションで行い、途中の失敗を残さない。

金額は確定時に固定

受注確定の時点で単価・金額・消費税(10%・1円未満切り捨て)を確定値として保存し、後から商品の価格を変えても確定済みの受注は変わりません。

並行処理での整合性

同じ商品への同時操作でも、在庫がマイナスになったり、同じ在庫が二重に引き当てられたりしないようにしています。

在庫行は商品ID昇順で悲観ロック(デッドロック回避)、状態の同期は受注行ロックの後に再判定、マスタ更新は version による楽観ロック。20並行の混在操作で不変条件の維持を検証。

Role と Security

見せない情報は画面で隠すのではなく、APIのレスポンス自体に含めません。権限のない操作は、画面だけでなくAPIでも拒否します。

Roleごとの主な利用範囲(画面メニューとAPIの認可が一致)
Role主な業務制限
営業担当
SALES		顧客・商品・在庫の参照、受注の登録・確定・キャンセル仕入原価はAPIレスポンスから除外。ユーザー管理・監査ログ・入出荷は不可
倉庫担当
WAREHOUSE		入荷・在庫調整・出荷、在庫と受注の参照受注の金額項目はAPIレスポンスから除外(配送先は表示)。仕入原価も不可
管理部門
MANAGEMENT		顧客・商品・在庫・受注の参照、監査ログの閲覧ユーザー管理・入出荷は不可
管理者
ADMIN		全機能(ユーザー・Role管理、商品CSV取込、監査ログを含む)最後の有効な管理者は無効化・降格できない
営業担当の商品一覧。APIレスポンスに仕入原価が含まれない
営業担当の商品一覧。APIレスポンスに仕入原価が含まれない
営業担当が /users へアクセス。画面で拒否、APIは403
営業担当が /users へアクセス。画面で拒否、APIは403
  • 認可はサーバー側(application層)で実施。全Role × 全エンドポイントの 403 を統合テストで確認
  • セッション認証 + CSRF対策。初回ログイン時はパスワード変更を強制
  • 監査ログは更新・削除の経路を持たない(API・アプリ・DBロール権限のいずれにもない)。自動処理も、起動したユーザーを実行者として記録
監査ログ。種別・契機(手動/自動)・実行者・対象を記録
監査ログ。種別・契機(手動/自動)・実行者・対象を記録

開発・品質実績

数値は、動画の実績カードと同じ検証済みデータ(OrderFlow の記録と ADS Runner の状態)から生成しています。

Project Complete は、全Featureの完了・承認の有効性・必須チェックなど、ADSで定めた完了条件を満たし、Runnerが正式に受理したことを指します。欠陥がないことや本番環境での稼働を意味するものではありません。

23Features要件から分解した機能単位。すべて完了
23 / 23Review承認全Featureで実装と分離したReview工程を実施し、完成時点で全件承認
正式受理Project CompleteADS上の完了条件を満たし、Runnerが正式受理
0承認再評価の残件最終成果物に対する承認の再確認が必要な項目の残り
10 / 10E2E 連続実行6テストのE2Eスイートを初期状態のDBから10回連続実行し、全回PASS
37ms受注一覧 p95基準 500ms 以内
53ms受注確定 p95明細10行・基準 1秒 以内
10,000性能試験時の受注件数ローカル環境で計測

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

フォーマット・静的解析(SpotBugs)・コンパイル・単体テストとアーキテクチャテスト(ArchUnit)・統合テスト(実PostgreSQLをTestcontainersで起動)・パッケージ・秘密情報スキャン(gitleaks)・Frontendのformat / lint / 型チェック / テスト / ビルド。全PASSしない限りReviewへ進めない運用。

追跡した記録

  • 要件機能 27 / 非機能 8
  • 設計判断(ADR)15
  • 実装報告(IR)99
  • Review99
  • Feedback(問題の起票と是正)77
  • 開発・検証期間2026-09-02 〜 2026-09-30(約1か月)OrderFlow の開発・再検収と並行して、実案件相当の適用で判明した ADS の改善・更新を含む(ADS 自体をこの期間に新規開発したものではありません)

ADS でどう開発したか

ADS(AI Development System)は、AIを設計・計画・実装・Reviewなどの役割に分け、自動チェックと再検収を組み合わせて、完成までの工程を管理する開発プロセスです。AI にコード生成を任せきりにするのではなく、役割と関門を決めた工程で進めました。OrderFlow(成果物)と ADS(開発プロセス)は別物です。

  1. Requirements業務判断 34 件を明文化し、要件へ
  2. Designアーキテクチャ・データモデル・API・ADR
  3. ImplementationFeature単位の指示書に沿って実装
  4. Automated Checks必須チェックが全PASSでなければ次へ進めない
  5. Review実装とは別のセッションでレビューし、指摘は修正して再Review
  6. Re-acceptance正本の変更後、完了済みFeatureを再検収
  7. Project Complete全Featureの承認が有効な状態で最終受理

使用した AI / Agent

複数の AI / Agent を工程ごとに使い分け、実装と Review は工程・セッションを分離しました。どれか1つのツールが OrderFlow を自動で作ったのではなく、各工程の成果物(設計文書・指示書・実装報告・Review)を次の工程と開発者本人が確認しながら進めています。

Claude Code

設計・計画・実装・Reviewの各工程を担当。工程ごとにセッションを分け、Reviewは実装とは別のセッションで実施。

Codex

計画(Planning)工程の一部を担当。実装報告の受領、修正指示書の作成、Feedbackの分析。

ChatGPT

要件・方針整理、開発報告の要約、実装担当への作業指示整理に使用。最終的な判断・意思決定は開発者本人が担当。

開発時点の利用モデル(実装報告・Review記録のModel欄より)
  • Claude CodeClaude Opus 5 / Claude Opus 5.5 / Claude Sonnet 5
  • Codex記録なし
  • ChatGPT記録なし

モデル名は開発時点のものです。

AI と開発者の分担

AI に任せた工程

  • 設計文書(要件・アーキテクチャ・データモデル・API・ADR)の作成
  • Feature への分解と、実装指示書の作成
  • 実装と、自動チェックの結果をまとめた実装報告
  • 実装とは別のセッションでの Review

開発者本人が行ったこと

  • 業務要件の判断(34 件の業務判断として明文化)
  • 人間の判断が必要な設計・是正方針の決定と承認
  • 再検収の開始や完了に向けた最終的な方針決定
  • AI の成果物と自動チェック・Review の結果の確認

品質の確認

Review の位置付け

設計・計画・実装・レビューを別の役割として扱い、実装とレビューは必ず別のセッションで行いました。Reviewを担うAIは実装と同じベンダーのモデルのため、第三者による独立レビューではなく、工程とセッションを分離したReviewです。

問題が見つかったとき

Reviewは 98 回行い、うち 15 回は差し戻し(Request changes)でした。差し戻しはいずれも修正・再Reviewを経て承認されています。実装中やレビューで見つかった問題は Feedback として起票し、コードで回避せず、仕様・設計の判断を経て是正しました。終盤には並行処理時の状態同期などを是正し、正本を更新したうえで、完了済みの 23 Features すべてを最新の入力で再検収しています。

OrderFlow の開発中に実際に発生した停止・権限・再検収・検証時間などの課題は ADS 側へフィードバックし、開発期間中も ADS を更新しました。

About the developer

担当領域

S.S業務システムエンジニア｜Java / Spring Boot・AI活用

Java / Spring Bootを中心に、約5年にわたり業務システム開発に携わっています。要件整理・設計から実装・テスト・運用までを担当し、現在はAIを開発プロセスに組み込み、自動チェックとReviewを組み合わせた開発に取り組んでいます。

OrderFlowでは、受注・在庫・入出荷・権限制御などの業務ロジックを実装し、検証・Review・再検収を経てProject Completeまで進めました。

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

  • 業務要件をシステム仕様・状態遷移・不変条件へ落とし込む
  • バックエンドとフロントエンドをまたぐ業務システムの開発
  • AIを使った開発プロセスの設計と運用(役割分担・関門・記録)
  • 自動テストとReview工程による品質管理
  • 認証・認可、並行処理、状態整合性に関する不具合の分析と是正
  • 検証結果に基づく改善と再検収
  • 完了条件を定め、そこまで開発を進めること

AIを使って速く作るだけでなく、実案件として検証できる状態で完成まで持っていくことを重視しています。

技術構成

Backend

  • Java 21
  • Spring Boot 3.5.3(Web / Data JPA / Security / Actuator)
  • Flyway(DBマイグレーション)
  • Apache Commons CSV

Frontend

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

Database / Infra

  • PostgreSQL 16
  • Docker Compose(postgres:16 / eclipse-temurin:21-jdk / node:22-alpine)
  • ローカル環境で完結

Test / Quality

  • JUnit 5 · Testcontainers · ArchUnit 1.4.1
  • Vitest 4 · Testing Library · MSW
  • Playwright 1.62.1(E2E)
  • Spotless · SpotBugs · ESLint · Prettier · gitleaks

テスト: Backend 単体・アーキテクチャ 14 クラス / 統合 21 クラス、Frontend 20 ファイル、E2E 5 シナリオ

前提と既知の制限

  • ローカル環境が前提本番・ステージング環境、デプロイ・監視・バックアップの設計はスコープ外です。
  • 倉庫は1つ複数倉庫は扱いません。
  • 出荷の選択肢出荷登録で選べる受注は、引当完了済みの先頭20件までです。
  • 性能値の位置付けローカル環境・受注10,000件での計測値です。基準値(500ms / 1秒 / 20並行)はプロジェクト内で仮置きした値です。
  • UI最小構成です。一部の画面ではAPIエラーの理由表示など、UXの改善余地をReviewで記録しています。

ご相談について

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

ご相談いただける内容

  • Java / Spring Bootでの業務システム開発
  • 要件整理・設計から実装・テストまでの開発
  • 準委任での開発支援
  • 小〜中規模の業務システム受託開発
  • AIを活用した開発環境・開発プロセスの導入／改善

稼働稼働開始時期・稼働日数は、案件条件に応じてご相談ください。

メールで相談する

OrderFlowのソースコードは公開していません。コードは面談時に画面共有でご説明できます。