Adobe Flashは2020年12月にサポート終了。セキュリティリスクと保守コストが年々増加しています。
| Frontend | Adobe Flash (Flex/MXML) — EOL |
| Backend | Java (Seasar2) — 安定 |
| Database | Oracle (528 tables) — 安定 |
| 通信 | AMF / BlazeDS — 要置換 |
従来手法では 200〜300人月 規模（18〜20ヶ月）。その間、Flash保守とReact開発の二重コストが発生し続けます。
「562画面」はview/フォルダ配下の全.mxmlファイル数。実際の画面構成はメイン画面＋サブ画面＋共通コンポーネントに分解されます。Fabbiはソースコードから精密に分析しました。
※ 562→412: ソースコードとExcel program_IDの照合。150ファイルはExcel未登録（サブ画面・共通部品等）。
※ 412→308: 非Flash = HTML5(76) + React(4) + 未分類(24)。React実装は実際15+画面（機能一覧未更新）。
※ 308→287: 対象外21 = 未使用(23) + 設計書未整備(4) − POC(6)。
※ 見積対象: Ph1 99 + Ph2a 33 + Ph2b 149 + POC 6 = 287画面。 各Phaseの全PC画面数（Flash+HTML5+React含む）は137/57/174。 308(Flash全体) − 287(見積対象) = 21(対象外)。
「562画面」はソースコードスキャン結果（.mxmlファイル数）。TMS機能一覧（Excel）の機能分類に基づく移行対象は287画面（Ph1 99 + Ph2a 33 + Ph2b 149）。対象外除外済み。STEP数ベース＋ランク別工数で精密に見積もりました。
バックエンド業務ロジック (Java/Oracle) はそのまま維持。通信層をAMF→REST APIに置換し、フロントエンドをFlashからReactへ移行します。
S-CASH Platform Architecture — 603 APIs: 183 Existing (30.3%) + 420 Must Build (69.7%) — Backend Work is MANDATORY
S-CASH Business Domain Flow — TMS (8 domains, 3,759 functions) & WMS (6 domains, 382 functions)
現行システムではFlash ClientとJava Backend間の通信にAMF (Action Message Format)というバイナリプロトコルを使用しています。 このプロトコルはサーバー側のBlazeDSライブラリで処理されていますが、ReactではAMFを使用できません。
BlazeDS/AMFはサーバー側のServletレイヤーとして動作しています（MessageBrokerServlet → S2AMFEndpoint → S2Adapter → Seasar2 Service）。
移行では、このServletレイヤーをREST Controllerに置換します。302のサービスペアそれぞれにREST endpoint（JSONレスポンス）を作成し、既存のSeasar2 Service Layerをそのまま呼び出します。業務ロジックとDBは一切変更不要です。
ファイル単位の移行対応表。左の各要素が右のどこに対応するかを番号で示します。
POC（無償・6画面）→ Phase 1（標準）→ Phase 2（標準外 + Housing）の3段階で実行します。
独自AIツールチェーン FARE→NEXA で、従来手法の10倍以上高速に移行します。
AIは100%自動ではありません。全ての品質ゲートでシニアエンジニアがレビューします。
Fabbi独自の2段階AIツールチェーンが、分析から設計・コード生成まで一貫して自動化します。
Flash Analysis & React Engine
リバースエンジニアリング — Flash構造を高速解析
Next-gen Expert Analysis & Generation
深層分析＋設計書＋Reactコード＋テストを日本品質基準で自動生成
3層セキュリティ (インフラ + AIツール + 法的) でソースコードとデータを保護します。
AI Pipeline（FARE＋NEXA）＋ Manual QA による見積もり。POCで精度をキャリブレーションします。
FARE（自動Flash解析）+ NEXA（業務理解支援）パイプラインにより、工数の60%をAI自動化。人的工数（HITL）は40%。
| Rank | STEP閾値 | 手動工数 (MD) | AI適用後 (×0.4) | Phase 2a (×0.70) | Phase 2b (×0.60) |
|---|---|---|---|---|---|
| S | ≥5,000 | 70 MD | 28 MD | 19.6 MD | 16.8 MD |
| A | ≥2,000 | 35 MD | 14 MD | 9.8 MD | 8.4 MD |
| B | ≥1,000 | 16.25 MD | 6.5 MD | 4.55 MD | 3.9 MD |
| C | ≥400 | 10 MD | 4 MD | 2.8 MD | 2.4 MD |
| D | <400 | 5 MD | 2 MD | 1.4 MD | 1.2 MD |
※ Phase 2a: 30%学習曲線削減（×0.70）、Phase 2b: 40%学習曲線削減（×0.60）。AI活用率適用後の値に乗算。
| フェーズ | 画面数 | 作業小計(MD) | 管理工数(MD) | 合計(MD) | 工数(MM) | 金額(¥) |
|---|---|---|---|---|---|---|
| POC（6画面 — 無償） | 6 | 44.9 | 9.2 | 54.1 | 2.71 | ¥0 |
| Phase 1 — 標準画面（99画面） 含 ST/UAT Support 1.5ヶ月 |
99 | 582.9 | 58.3 | 641.2 | 32.06 | ¥17,005,114 |
| Phase 2a — 標準外画面（33画面） 含 ST/UAT Support 1ヶ月 |
33 | 110.6 | 11.1 | 121.7 | 6.09 | ¥3,368,613 |
| Phase 2b — Housing画面（149画面） 含 ST/UAT Support 2ヶ月 |
149 | 535.5 | 53.6 | 589.1 | 29.46 | ¥16,196,060 |
| 合計 | 287 | 1,274.0 | 132.2 | 1,406.2 | 70.31 | ¥36,569,788 |
※ 1人月 = 20人日（MD）。POC 54.1 MD（無償・6画面）は別途。管理工数 10%（POCのみ 20.55%）込み。対象外42画面除外。
FAREサーバー + NEXAライセンス + LLM API + 運用・保守の4項目。全Phase共通費用。
| 費用項目 | 単価 | 数量 | 金額 |
|---|---|---|---|
| FAREサーバー | ¥55,000 / 月 | 11ヶ月 | ¥605,000 |
| NEXAライセンス | ¥4,200 / 画面 | 287画面 | ¥1,205,400 |
| LLM API | ¥2,800 / 画面 | 287画面 | ¥803,600 |
| 運用・保守 | ¥19,409 / 月 | 11ヶ月 | ¥213,500 |
| 合計 AI費用 | — | — | ¥2,827,500 |
※ AI費用は NONE-BACKEND / WITH-BACKEND 共通。各Phaseの人件費とは別途。
Phase 1で基盤構築 → Phase 2a+2b並行実行（IT/ST 10月末完了）→ UAT 10月〜（IT/ST gối）12月完了 → Go-Live 1/2027
562画面・302モジュールを対象に、AI活用×Human-in-the-Loopで品質を担保しながら効率的にテストを展開します。
※ 比率はテストケース数ベースの目安
| テストレベル | ツール | テストケース作成 | レビュー |
|---|---|---|---|
| UT（単体） | Manual + Postman + Playwright | Fabbi | Fabbi内部 |
| IT（統合） | Manual + Playwright | Fabbi | TDC |
| ST（システム） | — | TDC | センコー |
| UAT（受入） | — | TDC | センコー |
AIが「速度」を、人間が「判断」を担当。両者の掛け算で品質と効率を両立します。
| テストフェーズ | Fabbi | TDC | センコー |
|---|---|---|---|
| UT（単体テスト） | 実施+TC作成 | — | — |
| IT（統合テスト） | 実施+TC作成 | TCレビュー | — |
| ST（システムテスト） | Support | 実施+TC作成 | TCレビュー |
| UAT（受入テスト） | Support | 実施+TC作成 | 承認 |
| 回帰テスト | Playwright自動 | 結果確認 | — |
※ ダミーOracle環境で実行。本番データへの影響ゼロ。テスト後に自動クリーンアップ。
品質ゲートフローにTDC様・センコー様のレビューを組み込み、手戻りを最小化します。
※ Lane 2はノンブロッキング: Fabbiは次バッチに継続しつつ、TDCフィードバックを納品前に反映。
※ 品質確保のためTDC様にレビューいただく中間ドキュメント。納品物は下記「納品物一覧」を参照。
| # | 中間ドキュメント | 種別 | 数量 | 判定基準 | レビュー担当 |
|---|---|---|---|---|---|
| 1 | 業務フロー図 | 既存→確認 | 1ファイル | 維持 / 新規 / 修正 / 削除 | TDC + センコー |
| 2 | 機能要件一覧 | 既存→確認 | 1ファイル | 維持 / 新規 / 修正 / 削除 | TDC |
| 3 | 画面一覧 | 既存→更新 | 1ファイル | 維持 / 新規 / 修正 / 削除 | TDC + センコー |
| 4 | 画面遷移図 | 既存→更新 | 1ファイル | 維持 / 新規 / 修正 / 削除 | TDC |
| 5 | 画面基本設計 （8シートExcel） |
再作成/修正 | 画面毎1ファイル (~287件) |
Flash→React設計変換。修正/新規作成対象画面分。 | TDC バッチ毎~20画面 / 5営業日 |
| 6 | UIスタイルガイド | 新規作成 | 5画面サンプル | カラー・タイポグラフィ・スペーシング・コンポーネント規約 | TDC + センコー 初期1回 |
| 7 | UI Figmaデザイン | 新規作成 | 画面毎1ファイル (全画面UIリニューアル) |
React新UIの画面デザイン。全対象画面分。 | TDC バッチ毎 |
| 8 | フロントエンドアーキテクチャ | 新規作成 | 1ドキュメント | React技術スタック・ルーティング・状態管理・ビルド設定 | TDC承認 初期1回 |
| 9 | API Layerアーキテクチャ | 新規作成 | 1ドキュメント | RESTブリッジ設計・認証方式・エラーハンドリング | TDC承認 初期1回 |
※ 上記はレビュー用の中間ドキュメントであり、納品物ではありません。納品物は下記「納品物一覧」を参照。
※ 業務フロー図・機能要件一覧は1:1マイグレーションのため原則変更なし。変更がある場合は変更管理として別途協議。
※ Figmaデザインは現行レイアウト踏襲＋モダンUI適用。全画面分を作成。
※ プロジェクト完了時にTDC様へ正式に納品する成果物。
| # | 納品物 | 種別 | 数量 | 内容 | 納品タイミング |
|---|---|---|---|---|---|
| A. 中間ドキュメント最終版（上記レビュー対象9点の確定版） | |||||
| 1 | 中間ドキュメント最終版 | ドキュメント | 9点 | 上記レビュー対象ドキュメント（業務フロー図、機能要件一覧、画面一覧、画面遷移図、UIスタイルガイド、FEアーキテクチャ、APIアーキテクチャ等）のレビュー反映済み最終版。 | Phase毎 |
| B. 基本設計書（BD） | |||||
| 2 | 画面基本設計書 （8シートExcel形式） |
ドキュメント | 画面毎1ファイル (~287件) |
Flash→React設計変換後の最終版。8シートExcel。 | バッチ毎 ~20画面/バッチ |
|
既存維持
~50件
既存修正
~170件
不足分新規
~67件
追加画面
TBD
|
|||||
| 3 | API基本設計書 | 新規作成 | API毎1ファイル (~600件) |
RESTエンドポイント設計。Request/Response定義・シーケンス図。603サービスベース。 | バッチ毎 |
| 4 | バッチ処理設計書 | 既存→更新 | ~4件 (Housing系) |
送り状受信・配達状況送信・送り状送信・配達状況受信。 | Phase 2b |
| 5 | 帳票・ファイル出力設計書 | 既存→更新 | ~55件 (帳票50 + CSV5) |
送り状・荷札・配送指示書等の帳票50件＋CSV入出力仕様5件。 | バッチ毎 |
| 6 | 共通設計書 | 新規作成 | 1式 | 共通コンポーネント・ユーティリティ・Props/Interface定義。 | 初期1回 |
| 7 | Figma UIデザイン | 新規作成 | 画面毎1ファイル (~287画面分) |
React新UIの画面デザイン。現行レイアウト踏襲＋モダンUI適用。 | バッチ毎 |
| C. 詳細設計書（DD） | |||||
| 8 | 画面詳細設計書 | 新規作成 | 画面毎1ファイル (~287件) |
画面レイアウト詳細・項目定義・LOGICブロック・バリデーション。AI生成。 | バッチ毎 |
| 9 | API詳細設計書 | 新規作成 | API毎1ファイル (~600件) |
Request/Response詳細・LOGICブロック＋SQL・シーケンス図。AI生成。 | バッチ毎 |
| D. ソースコード・テスト | |||||
| 10 | Reactソースコード | ソースコード | 全画面分 | React実装コード。コンポーネント・ルーティング・状態管理含む。 | バッチ毎 |
| 11 | ユニットテストコード | ソースコード | 全画面分 | React画面のユニットテスト。テストカバレッジレポート含む。 | バッチ毎 |
| 12 | テスト結果報告書 | ドキュメント | バッチ毎1ファイル | テスト実施結果・不具合一覧・カバレッジ。 | バッチ毎 |
※ 数量は現行分析に基づく概算値。詳細マッピング後に確定予定。
※ BD画面設計の「既存維持」「既存修正」「不足分新規」の内訳は289件の既存設計書と287画面のマッピング結果による。
※ API件数は603サービスベース。REST化時にエンドポイント集約により変動の可能性あり。
※ 納品形式・媒体はTDC様と別途協議。
Flash→React移行の実動プロトタイプ。9モジュール・全画面を実装済み。
1. ログイン画面 — 412 PC画面（287 移行対象）、6ロール対応
2. ダッシュボード — KPI、チャート、リアルタイムデータ
3. マスタ管理 — 81画面、30+マスタ種別、9,800+レコード
4. 配車管理 — 車両×ルート割り当て、ステータス追跡
5. 送り状管理 — 24バリアント、本番品質データグリッド
6. 配送管理 — リアルタイム追跡、GPS、写真確認
7. 帳票管理 — 96帳票種別、6カテゴリ
8. 請求管理 — 請求書ライフサイクル、クレーム管理、EDI
無償POC（6画面：送り状4 + マスタ2）から開始します。
技術検証の結果に基づき、本格移行の精度の高い見積もりを提出します。
Fabbi — AI-Powered Software Development
ハノイ、ベトナム | P-mark (JIS Q 15001) 取得済み
詳細データ・根拠資料。見積もりおよび提案の補足情報です。
Fabbiによるソースコード詳細解析（2026/03/16）で確認。Fabbi提案の妥当性を裏付けるエビデンスです。
/ajax サーブレット経由（AjaxServletCommonDto）
TDCの独自React移行は/ajaxサーブレットを経由しており、本格的なREST APIレイヤーなしには拡張限界に達しています。FabbiのREST APIブリッジ提案の技術的必要性を裏付けるエビデンスです。
| 項目 | TDC独自移行（現状） | Fabbi提案 |
|---|---|---|
| 通信方式 | /ajax サーブレット（独自） | REST API (OpenAPI準拠) |
| セキュリティ | パスワード平文送信（未解決） | HTTPS + Token認証（設計済） |
| カバー率 | ~15画面 / 287対象 ≈ 30.3%で停滞 | 287画面 100%（Phase 1〜2b） |
| スケーラビリティ | 拡張限界（設計制約） | 302 endpoints、FARE/NEXA自動化 |
※ 2026/03/16 Fabbiによるソースコード解析結果。TDCの試行は評価されるべき取り組みであり、Fabbiはこれを引き継ぎ完走させます。
※ TMS機能一覧ではReact=4画面。ソースコード分析(2024/05以降)では15+画面のReact実装を確認。機能一覧未更新の可能性あり。
見積対象画面数と TMS機能一覧の画面数が異なる理由を説明します。
Phase分割された配信スコープ (POC 6 + Ph1 99 + Ph2a 33 + Ph2b 149)
Flash画面全体（スキップ・N/A 含む）
| 項目 | 画面数 | 備考 |
|---|---|---|
| TMS機能一覧（全体） | 308 | スキップ・N/A 含む Flash全画面 |
| 差分 — 見積対象外 | 21 | design docs 未整備のため対象外 |
| 見積対象合計 | 287 | POC 6 + Ph1 99 + Ph2a 33 + Ph2b 149 |
| └ Phase 1 内訳 | 137 | PC画面 137枚中 Flash 100画面が移行対象 (見積 99画面) |
※ Oracle DBテーブル数: ソースコードEntity解析=528テーブル。初期ヒアリング情報では529テーブル。差分1テーブルは未使用Entity or ビュー定義の可能性あり。本提案では実測値528を採用。
| Phase | 画面数 | 設計書 | ソースコード | テスト |
|---|---|---|---|---|
| POC（無償） | 6 | 設計書 6 (8シート形式) | React TSX 6画面 + REST 6 endpoints | Vitest UT + Playwright E2E |
| Phase 1（標準） | 99 | 設計書 99 + OpenAPI Spec | React TSX 99画面 + REST ~100 endpoints + 共通コンポーネントライブラリ | Vitest UT + Playwright E2E |
| Phase 2a（標準外） | 33 | 設計書 33 + OpenAPI Spec差分 | React TSX 33画面 + REST ~33 endpoints | Vitest UT + Playwright E2E |
| Phase 2b（Housing） | 149 | 設計書 149 + OpenAPI Spec差分 | React TSX 149画面 + REST ~163 endpoints | Vitest UT + Playwright E2E |
| 合計 | 287 | 設計書 287件 + API仕様書 | React 287画面 + REST ~302 endpoints | 全画面 UT + E2E |
Fabbiによるソースコード詳細解析で特定。Flash環境では事実上隠蔽されていたリスクが、React SPA化により顕在化します。
AjaxServlet.java:
Line 259: Class<?> cls = Class.forName(SERVICE_PACKAGE + requestService);
Line 262: Method method = cls.getMethod(requestMethod, dto.getClass());
Line 267: method.setAccessible(true);
SERVICE_PACKAGE = "jp.co.senko.jigs.service." (line 47)AjaxServletCommonDto.java: 1,033行、178個のpublicフィールドAjaxServlet.java:
Line 23: import flex.messaging.FlexContext;
Line 88: FlexContext.createThreadLocalObjects(); // 全リクエストで実行
Line 89: FlexContext.setThreadLocalHttpRequest(request);
BaseDto.java:
Line 54: public String flexClientid;
Line 64: public String flexSessionId;AjaxServlet.java:
Line 175: requestTantoPassword = (String) json.getString(REQ_TANTO_PASSWORD_CD);
Line 196: model.tantoPassword = requestTantoPassword; // 平文のまま保存
Line 531: // CORSエラー対応：制限なし
Line 532: response.setHeader("Access-Control-Allow-Origin", "*");| カテゴリ | BlazeDS専用 | /ajax対応 | カバー率 |
|---|---|---|---|
| Master Data | 52 | 46 | 47% |
| Invoice & Billing | 120 | 4 | 3% |
| 合計 | 420 | 183 | 30.3% |
※ 全発見事項は 2026/03/16 Fabbiによるソースコード解析で確認。行番号はAjaxServlet.java / AjaxServletCommonDto.java / BaseDto.java の実コードに対応します。