Minrally 開発提案 - Fabbi × NEXA

01 / 課題Vấn đề

自前 + Copilot と、NEXA で取り組むのと、何が違うのか"Tự làm + Copilot" khác gì với làm bằng NEXA

Minrally = 完全新規・145画面・補助金あり（検収と監査が必須）・想定チーム 17〜19名。一部に本番稼働中の Web みんラリが存在。顧客はこう問います。Minrally = hoàn toàn mới, 145 màn, có trợ cấp (bắt buộc nghiệm thu + kiểm toán), đội dự kiến 17-19 người. Một phần Web みんラリ đang chạy prod. Khách hỏi thẳng.

核心: 145画面の補助金案件で最も高コスト・高リスクな工程は、Copilot が触れない範囲（BD/DD/test/PM）に集中する。Cốt lõi: trong case 145 màn có trợ cấp, phần đắt và rủi ro nhất nằm ngoài vùng Copilot phủ (BD/DD/test/PM).

手戻り最大のリスクrủi ro lớn nhất

自前 + CopilotTự làm + Copilot

BD 基本設計 → 生成しないkhông sinh
DD 詳細設計 → 生成しないkhông sinh
Test design / IT → しないkhông
PM → しないkhông
Code FE/BE → する（唯一の工程）có (lát duy nhất)

最大のリスクは手戻り。コード前のゲートがなく、設計の不具合が Test / UAT で初めて露見し、最も高コストな段階で修正することになります。17〜19名が各々の流儀で進めば、成果物の一貫性も保てません。Rủi ro lớn nhất là 手戻り (rework). Không có gate trước code, lỗi thiết kế lọt tới Test/UAT mới lộ, phải sửa ở giai đoạn đắt nhất. 17-19 người mỗi người một kiểu thì artifact không nhất quán.

NEXA 🟢🔵

各画面 = BD-画面 + DD-画面（同一ID）mỗi màn = BD-màn + DD-màn (cùng ID)
コードは spec の下で生成code sinh dưới spec → 同じIDcùng ID
test case もtest case cũng 同じID に紐づくgắn cùng ID
品質ゲートが各工程に立つgate chất lượng đứng ở mỗi pha
納品 = 設計書 + code + testbàn giao = 設計書 + code + test

「この画面はどの要件に基づくのか、testはどこか」をIDで30秒以内に回答。手戻りを盲目的に積まない仕組みです。"Màn này dựa requirement nào, test ở đâu" - trả lời trong 30 giây bằng ID. Cơ chế không chất 手戻り một cách mù quáng.

Takeaway:Takeaway: 論点は「Copilotが弱い」ではなく、補助金案件で評価される工程の広さ。NEXA はコード前ゲートと ID 連携で手戻りを構造的に抑える。Vấn đề không phải "Copilot yếu" mà là độ rộng các pha được tính trong case trợ cấp. NEXA chặn 手戻り bằng gate trước code + ID-linked.

詳細を開く: なぜ Copilot だけでは足りないかMở chi tiết: vì sao chỉ Copilot không đủ

145画面の工数構造を見ると、Copilotが確実に効くのはcodeのみ。BD/DD/test design/PM はカバー外。補助金プロジェクトでは設計書と test が監査資産として必須のため、未カバー工程こそが総コストの大半を占めます。科学的にも、コード高速化だけなら全体削減の約20%相当（METR-mix 下限）にとどまります。Nhìn cấu trúc công 145 màn, Copilot chỉ chắc chắn hiệu quả ở code. BD/DD/test design/PM nằm ngoài. Với dự án trợ cấp, 設計書 và test là tài sản kiểm toán bắt buộc, nên các pha chưa cover lại chiếm phần lớn tổng chi phí. Theo science anchor, riêng tăng tốc code chỉ đáng ~20% giảm tổng (sàn METR-mix).

出典:Nguồn: data-appendix §A,§F · writer-vi §1.1, §3.4 · proposal phan2-minrally-cu-the · Fantrec 工数見積もり.xlsx (2A サマリ).

02 / アプローチCách tiếp cận

NEXA は Minrally のどこに入るのかNEXA vào Minrally ở đâu

Minrally はグリーンフィールドです。NEXA は「大規模な既存システムスキャン」を売りません。spec-driven の骨格で入ります。Minrally là greenfield. NEXA không bán "quét hệ cũ quy mô lớn". Vào bằng bộ xương spec-driven.

既存との接点: M0で Web みんラリをスキャンしてKBを構築し、データモデルとロジックを再利用。145画面の開発本体はグリーンフィールド。Điểm chạm legacy: M0 quét Web みんラリ dựng KB, tái dùng data model + logic. 145 màn phát triển mới hoàn toàn là greenfield.

1点FARE-lite M01 điểm chạm M0

詳細を開く: M0 で既存 Web を1点接触で再利用する仕組みMở chi tiết: M0 tái dùng Web cũ qua 1 điểm chạm

M0フェーズで既存 Web みんラリのソースをスキャンし、KB（Knowledge Base）を構築します。このKBから、本番稼働済みの data model・業務ロジック・命名規約を抽出し、新規アプリ145画面の spec 生成に注入します（FARE-lite の1点接触 🟢🔵）。既存 Web を全部作り直すのではなく、「何が動いているか」の知識だけを再利用します。これにより M0 の完了後、greenfield 向けの spec-driven パイプラインがプロジェクト固有の文脈を持ってスタートできます。Ở M0, quét source Web みんラリ cũ để dựng KB (Knowledge Base). Từ KB, trích xuất data model / logic nghiệp vụ / quy ước đặt tên đang chạy prod, bơm vào sinh spec cho 145 màn app mới (1 điểm chạm FARE-lite 🟢🔵). Không làm lại toàn bộ Web cũ, chỉ tái dùng "tri thức" về những gì đang hoạt động. Nhờ đó, sau M0, pipeline spec-driven greenfield khởi động với ngữ cảnh riêng của dự án.

出典:Nguồn: writer-vi §2.1 · CLAUDE.md §2 (1 điểm chạm FARE-lite) · data-appendix §A.

145画面 màn ↓ 各画面に 1つのBD-画面 + 1つのDD-画面（IDを保持）mỗi màn: 1 BD-màn + 1 DD-màn (giữ ID) ↓ コードが spec の下で生成され、同じIDに紐づくcode sinh dưới spec, gắn cùng ID ↓ test case も同じIDに紐づくtest case cũng gắn cùng ID → 納品パッケージgói bàn giao

既存システムとの接点はただ1点。M0で既存 Web みんラリのソースをスキャンして KB を構築し、本番稼働済みの data model と logic を再利用します（FARE-lite の1点接触 🟢🔵）。既存部分をゼロから作り直しません。Điểm chạm với hệ cũ chỉ 1. Ở M0 quét source Web みんラリ cũ để dựng KB, tái dùng data model + logic đã chạy prod (1 điểm chạm FARE-lite 🟢🔵). Không làm lại phần cũ từ đầu.

Takeaway: NEXA は legacy 移行ツールではなく、greenfield 向け spec-driven パイプライン。既存 Web は M0 の1点接触のみで再利用。NEXA không phải tool migrate legacy mà là pipeline spec-driven cho greenfield. Web cũ chỉ tái dùng qua 1 điểm chạm ở M0.

出典:Nguồn: data-appendix §A,§I · writer-vi §1, §4.4 · CLAUDE.md §2 (Minrally = GREENFIELD).

03 / 手法Phương pháp

Minrally における5つの具体的な仕組み5 cơ chế cụ thể trong Minrally

5つの仕組み全て 🟢 出荷済み。 JPフォーマットゲート・display-only ゲート・KB注入・governance vibecode・12式 JP ドキュメント納品。Cả 5 cơ chế 🟢 đã ship. Gate format JP, gate display-only, bơm KB, governance vibecode, bàn giao 12 bộ tài liệu JP.

5/5🟢 shipped

詳細を開く: 5つの仕組みとゲート G1-G10 + ライフサイクルのマッピングMở chi tiết: map 5 cơ chế vào gate G1-G10 + lifecycle

5つの仕組みはそれぞれ、NEXA の品質ゲート（G1-G10）とライフサイクル10フェーズに連結されています。G1 RD・G2 BD・G3 DD でJP定型フォーマットの sign-off（仕組み01）。G4 JP-format・G5 Cross-ref・G6 Provenance で artifact の一貫性を確保。display-only ゲート（仕組み02）は BD/DD フェーズで画面の複雑さに応じた spec 量を調整し、余剰な設計コストを防ぎます。KB注入（仕組み03）は KB Bootstrapフェーズで構築されたMinrally 固有の知識を、BUILD フェーズの coding agent に配信します。G7 Build・G8 Code・G9 Test・G10 Delivery は governance vibecode（仕組み04）と JP 12式ドキュメント（仕組み05）によって保護されます。5 cơ chế gắn với gate G1-G10 và 10 pha lifecycle. G1 RD / G2 BD / G3 DD: sign-off format JP chuẩn (cơ chế 01). G4 JP-format / G5 Cross-ref / G6 Provenance: đảm bảo nhất quán artifact. Gate display-only (cơ chế 02) điều chỉnh lượng spec theo độ phức tạp màn trong pha BD/DD, tránh chi phí thiết kế thừa. Bơm KB (cơ chế 03) phân phối tri thức Minrally đặc thù (dựng ở KB Bootstrap) cho coding agent ở pha BUILD. G7 Build / G8 Code / G9 Test / G10 Delivery được bảo vệ bởi governance vibecode (cơ chế 04) và 12 bộ tài liệu JP (cơ chế 05).

出典:Nguồn: data-appendix §I (gates + lifecycle) · writer-vi §4.4 · CLAUDE.md §6 (nexa mcp 5 agents).

🟢 JP定型フォーマットのゲート + コード前 sign-offGate format JP định dạng + sign-off trước code

設計書（基本設計/詳細設計）をJP標準で自動生成。BD/DD が sign-off 未済ならコード不可。チームが自前だと省略しがちで、最も高コストな手戻りの源です。Tự sinh 設計書 (基本設計/詳細設計) chuẩn JP. BD/DD chưa sign-off thì không cho code. Team tự làm hay bỏ qua bước này - đây là nguồn 手戻り đắt nhất.

🟢 表示画面向けの「display-only」ゲートGate "display-only" cho màn chỉ hiển thị

HexMap・MyLog・スポット詳細など表示のみの画面が多数。ゲートは余分なロジック spec を要求せず、ドキュメントが実態に即し、見積りが膨らみません。Nhiều màn chỉ hiển thị (HexMap, MyLog, chi tiết spot). Gate không bắt viết spec logic thừa, doc sát thực tế, est không phồng.

🟢 Minrally KB をコーディングエージェントに注入Bơm KB Minrally vào coding agent

screen-map・API list・DB model・命名規約を nexa mcp 経由で投入。エージェントはどのAPIを呼ぶか把握します。「素のCopilot」とは決定的に異なります。Bơm screen-map / API list / DB model / quy ước đặt tên qua nexa mcp. Agent biết gọi API nào. Khác hẳn "Copilot trần".

🟢 規律ある vibecodeVibecode có kỷ luật

コーディングエージェントは spec + gate の下で高速稼働。各不具合を正しい層（spec不足 / code誤り / 設計不良）に分類し、正しい箇所で修正します。場当たり修正をしません。Coding agent chạy nhanh dưới spec + gate. Phân loại từng lỗi đúng tầng (thiếu spec / sai code / thiết kế lỗi) và sửa đúng chỗ. Không sửa chắp vá.

🟢 JPドキュメント12式の納品Bàn giao 12 bộ tài liệu JP

要件定義書・基本設計書・詳細設計書・API spec・test design・manual を Document Control で管理。補助金ありのプロジェクトでは、これは実際の監査資産です。要件定義書 / 基本設計書 / 詳細設計書 / API spec / test design / manual quản lý bằng Document Control. Với dự án trợ cấp, đây là tài sản kiểm toán thật.

Takeaway: 5つの仕組みは全て🟢 出荷済み。Minrally固有の display-only ゲートと KB 注入が「素のCopilot」との決定的差。Cả 5 cơ chế đều 🟢 đã ship. Gate display-only đặc thù Minrally + bơm KB là khác biệt quyết định với "Copilot trần".

出典:Nguồn: data-appendix §H (🟢 SHIPPED) · writer-vi §4.4 · CLAUDE.md §6 (nexa mcp 5 agents).

D / DATA · 145画面145 màn

145画面の全データ - 難易度が cut-off を決めるToàn bộ dữ liệu 145 màn - 難易度 quyết định cut-off

下表は per-task model の生データ（145行）。フィルタ・列ヘッダのソートで全画面を検証できます。est_人日 / aidf_人日 / cut% は work-item レベルの値です。Bảng dưới là dữ liệu gốc per-task model (145 dòng). Lọc + sort header để kiểm tra mọi màn. est_人日 / aidf_人日 / cut% là giá trị mức work-item.

per-screen 人日合計: 1611.7 → 870.7 人日 = −46.0%（raw work-item cut）。これは headline −41.8% MM とは別物 - weighting と NEXA setup の前段階の値です。混同しません。Tổng 人日 per-screen: 1611,7 → 870,7 人日 = −46,0% (raw work-item cut). Khác headline −41,8% MM - là giá trị TRƯỚC weighting + NEXA setup. Không conflate.

−46.0%work-item ≠ −41.8% MMwork-item ≠ −41,8% MM

大項目Nhóm 難易度 AI-rank

ID	画面名	大項目Nhóm	難易度	est_人日	aidf_人日	cut%	AI-rank	DEV-tier

Takeaway: 易しい画面ほど cut-off が深く、難しい画面（XL 8画面）ほど浅い。この勾配が −41.8% を「均一割引でない」根拠にします。Màn càng dễ cut-off càng sâu, màn khó (8 màn XL) càng nông. Gradient này là căn cứ −41,8% "không phải chiết khấu đều".

詳細を開く: 8画面の XL（AIが最も苦手な領域、隠さず明示）Mở chi tiết: 8 màn XL (vùng AI kém nhất, không giấu)

XL = realtime / animation / 複雑な統合。SCR-001 ホーム(SpotMap)・SCR-010 ホーム(HexMap)・SCR-013 HEXガチャ・SCR-020 チェックイン_QRリーダー・SCR-079 DiceTrip_サイコロ演出・SCR-049 SHOP_POコイン購入・SCR-101 MAB_トーク・ADM-B-007 カード決済管理。難領域（rank C+D）は総工数の約8%のみだが、cut-off の天井を決めます（Amdahl）。だから全体は60%でなく41.8%に留まります。XL = realtime / animation / tích hợp phức tạp. SCR-001 SpotMap, SCR-010 HexMap, SCR-013 HEXガチャ, SCR-020 QR reader, SCR-079 DiceTrip xúc xắc, SCR-049 mua coin, SCR-101 MAB chat, ADM-B-007 quản lý thẻ. Nhóm khó (rank C+D) chỉ ~8% tổng công nhưng chặn trần cut-off (Amdahl). Vì vậy tổng dừng 41,8% chứ không 60%.

出典:Nguồn: per-screen-summary.csv (n=145, VERIFIED) · data-appendix §D,§E · writer-vi §2.2.

04 / 根拠Căn cứ

−41.8% は均一な割引ではない−41,8% không phải chiết khấu đều

13の大項目それぞれの削減率を、工数で重みづけした加重平均です。設計書を量産できる工程ほど深く、判断・調整の工程ほど浅く効きます。Là trung bình có trọng số (theo công) của mức giảm từng 大項目. Pha sinh được 設計書 hàng loạt thì sâu, pha phán đoán / điều phối thì nông.

加重平均の正味削減（NEXA 立ち上げ投資 +2.51 MM を差し引き済み）。Case B 96.67 → 56.30 MM。Giảm ròng theo trọng số (đã trừ đầu tư setup NEXA +2,51 MM). Case B 96,67 → 56,30 MM.

−41.8%96.67 → 56.30 MM

−44.4%

13項目の作業だけの削減（粗）giảm chỉ 13 hạng mục (gộp thô)

+2.51 MM

NEXA 立ち上げの一度きり投資（≈2.6%）đầu tư 1 lần dựng NEXA (≈2,6%)

−41.8%

投資を差し引いた正味（保守的）ròng sau khi trừ đầu tư (bảo thủ)

−41.8% = 1 − 56.30 / 96.67 = 41.76% · 出典: 工数見積 2A サマリnguồn: 工数見積 2A サマリ

難易度が上がるほど cut-off は浅くなる難易度 càng cao, cut-off càng nông

AIの削減は不均一です。易しい画面はAIが非常に速く、難しい画面は手作業より遅くなりうる。145画面を画面難易度別に平均すると、明確な勾配が出ます。Giảm của AI không đều. Màn dễ AI rất nhanh, màn khó có thể chậm hơn tay. Trung bình 145 màn theo 難易度 cho gradient rõ.

S · 易dễ

60.0%

doc-gen / form 中心doc-gen / form

M · 中TB

49.6%

標準的なCRUD画面CRUD chuẩn

L · 難khó vừa

38.8%

ロジック密な画面màn dày logic

XL · 最難khó nhất

28.2%

HexMap / ガチャ等 8画面HexMap / gacha, 8 màn

XL画面8つ（HexMap・SpotMap・QRチェックイン・ガチャ・DiceTrip演出）は realtime/animation の複雑なUIで、AIが最も苦手な領域です（METR の知見と一致）。ただし難領域（rank C+D）は総工数の約8%のみ。工数の大半（rank A+B ≈ 85%）はAIが中〜強で支援する領域にあり、全体を押し下げきれません。8 màn XL (HexMap, SpotMap, QR check-in, gacha, DiceTrip演出) là UI realtime/animation phức tạp, vùng AI kém nhất (khớp METR). Nhưng nhóm khó (rank C+D) chỉ ~8% tổng công. Phần lớn công (rank A+B ≈ 85%) ở vùng AI hỗ trợ trung-mạnh, không kéo nổi toàn bộ xuống sâu hơn.

誠実な framing。Framing trung thực. 各画面の cut-off を工数加重で roll-up すると、各フェーズの削減率（BD 55% / DD 42% / FE 45% / BE 50% / UT 45% / IT 40%）に完全一致し、Case B 合計 96.7 → 56.3 MM = −41.8%。これは数値の透明な説明であり、再計算ではありません。難領域が総量を押し下げるため、60%ではなく41.8%に留まります（Amdahlの法則）。Roll-up cut-off mỗi màn theo trọng số công thì khớp tuyệt đối mức giảm từng pha (BD 55% / DD 42% / FE 45% / BE 50% / UT 45% / IT 40%), tổng Case B 96,7 → 56,3 MM = −41,8%. Đây là giải thích minh bạch, không phải tính lại. Nhóm khó kéo tổng xuống nên dừng 41,8% chứ không 60% (luật Amdahl).

なぜこの数値が信頼できるのかVì sao con số này tin được

🔵 実際の PoC、フルライフサイクルPoC thật, full lifecycle

社内PoC（インフラ業界、匿名）が RD→BD→DD→code→test→delivery を完走。約20のID連携 artifact と実際の納品パッケージを生成。手法はスライドではなく、一周を走りきっています。PoC nội bộ (ngành hạ tầng, ẩn danh) chạy trọn RD→BD→DD→code→test→delivery. Sinh ~20 artifact ID-linked + gói bàn giao thật. Phương pháp đã chạy đủ một vòng, không phải slide.

🔵 納品済みエンタープライズ案件（匿名）の実測Đo thật trên dự án enterprise đã bàn giao (ẩn danh)

AIが9画面のDDを生成 → 平均 accuracy 80.0%、9/9画面で達成、画面間のばらつき僅か2.4%。均一だから145画面で再現できると考えます。72バグ中8つ（11.1%）はAI由来で、プロセスが100%捕捉・処理しました。AI sinh DD cho 9 màn → accuracy TB 80,0%, 9/9 màn đạt, độ lệch giữa màn chỉ 2,4%. Đều nên tin lặp lại trên 145 màn. 8/72 bug (11,1%) do AI, quy trình bắt + xử 100%.

独立した科学的 anchorScience anchor độc lập

コード高速化 +55.8% = GitHub Copilot RCT（arXiv 2302.06590、95名）。難タスクの遅延 −19% = METR 2025（arXiv 2507.09089、16名/246タスク）。混合 1.26× = Management Science 2025（4,000名以上/3 RCT）。別々の研究で、混同しません。コード高速化だけなら全体削減の約20%相当 - Fabbiの−41%は NEXA が自動化するドキュメント/テスト工程から来ます。Tăng tốc code +55,8% = GitHub Copilot RCT (arXiv 2302.06590, 95 dev). Task khó chậm −19% = METR 2025 (arXiv 2507.09089, 16 dev / 246 task). Trộn 1,26× = Management Science 2025 (4.000+ dev / 3 RCT). Các nghiên cứu khác nhau, không gộp. Riêng tăng tốc code chỉ đáng ~20% giảm tổng - −41% của Fabbi đến từ pha doc/test NEXA tự động hóa.

Takeaway: −41.8% は 4つの根拠（est v2 + PoC 80%/9画面 + science anchor + M0 再計測）で支え、per-task は透明化であって循環論証ではありません。−41,8% được đỡ bởi 4 chân neo (est v2 + PoC 80%/9 màn + science anchor + M0 đo lại); per-task là minh bạch hóa chứ không phải vòng tròn.

詳細を開く: sanity bound と per-task の robustnessMở chi tiết: sanity bound + robustness per-task

Sanity: 20.6% (METR-mix 下限 = 1−1/1.26) ≤ 41.8% ≤ 59.0% (Amdahl 上限) → PASS。41.8% は下限の約2倍（過度に保守的でない）かつ上限から距離（over-promise でない）。Robustness: 独立再計算（別 gradient）でも各フェーズ roll-up Δ=0、勾配 S>M>L>XL は同形。rank の絶対値（S20/A63...）は提示 lens で gradient により変動しますが、難領域 C は8画面で不変。Sanity: 20,6% (sàn METR-mix = 1−1/1,26) ≤ 41,8% ≤ 59,0% (trần Amdahl) → PASS. 41,8% gấp đôi sàn (không quá rụt rè) và cách trần (không over-promise). Robustness: re-derive độc lập (gradient khác) vẫn roll-up từng pha Δ=0, gradient S>M>L>XL cùng hình. Giá trị tuyệt đối rank (S20/A63...) là lens trình bày, đổi theo gradient; nhưng nhóm khó C = 8 màn bất biến.

出典:Nguồn: data-appendix §B,§D,§F,§G · writer-vi §3.1-§3.4 · 工数見積もり.xlsx (2A) · arXiv 2302.06590 · arXiv 2507.09089 · Management Science 2025 (doi 10.1287/mnsc.2025.00535).

04b / 見積Ước lượng

NEXA 5フェーズ別の見積（greenfield 展開モデル）Ước lượng theo 5 pha NEXA (mô hình triển khai greenfield)

10フェーズのライフサイクルを greenfield 向けに5フェーズへ圧縮。各フェーズの通常/NEXA/削減を示します。合計は加重平均と一致（96.67→56.30 MM）。Nén lifecycle 10 pha xuống 5 pha cho greenfield. Hiển thị 通常/NEXA/削減 từng pha. Tổng khớp trung bình có trọng số (96,67→56,30 MM).

正味削減 −41.8%: NEXA setup 投資（+2.51 MM、≈2.6%）を差し引いた後の数値。96.67 → 56.30 MM。Giảm ròng −41,8%: sau khi trừ đầu tư NEXA setup (+2,51 MM, ≈2,6%). 96,67 → 56,30 MM.

−41.8%96.67 → 56.30 MM

詳細を開く: 10フェーズ → 5フェーズへの圧縮マッピングMở chi tiết: map 10 pha lifecycle xuống 5 pha greenfield

NEXA のライフサイクルは10フェーズ（INIT / KB Bootstrap / RD / BD / DD / BUILD / VERIFY / UAT / DELIVERY / Knowledge-Update）。Minrally は greenfield のため、これを5フェーズへ圧縮して展開します。

INTAKE（≈INIT+KB Bootstrap）: 既存 Web スキャン・KB構築・M0 試行。唯一の「投資フェーズ」で削減−1.7%（投資）。
FOUNDATION（≈RD）: 要件定義・画面マップ・API設計。削減 16.5%。
ARCH-VAL + TESTSPEC（≈BD+DD前半）: 基本設計・詳細設計・test spec。削減 43.0%（doc-gen が最も効く領域）。
BASIC-DOCS + CODING（≈DD後半+BUILD）: spec 下で code 生成・ゲート通過。削減 46.7%（最大効果）。
TEST / AUDIT（≈VERIFY+UAT+DELIVERY+KU）: UT/IT・UAT・G10 納品確認・ドキュメント一式。削減 41.7%。 Lifecycle NEXA gồm 10 pha (INIT / KB Bootstrap / RD / BD / DD / BUILD / VERIFY / UAT / DELIVERY / Knowledge-Update). Minrally là greenfield nên nén xuống 5 pha triển khai.

INTAKE (≈INIT+KB Bootstrap): quét Web cũ, dựng KB, thử nghiệm M0. Pha đầu tư duy nhất, giảm -1,7% (đầu tư).
FOUNDATION (≈RD): định nghĩa requirement, screen map, thiết kế API. Giảm 16,5%.
ARCH-VAL + TESTSPEC (≈BD+DD truoc): 基本設計, 詳細設計, test spec. Giảm 43,0% (vùng doc-gen hiệu quả nhất).
BASIC-DOCS + CODING (≈DD sau+BUILD): sinh code dưới spec, vượt gate. Giảm 46,7% (hiệu quả cao nhất).
TEST / AUDIT (≈VERIFY+UAT+DELIVERY+KU): UT/IT, UAT, G10 nghiệm thu, bộ tài liệu. Giảm 41,7%.

出典:Nguồn: data-appendix §I (lifecycle 10 pha) · layout-estimate.csv (VERIFIED) · writer-vi §3.5.

NEXA phase	通常 MM	NEXA MM	削減 MM	削減%
INTAKE	3.068	3.120	−0.052	−1.7 (投資)−1,7 (đầu tư)
FOUNDATION	6.443	5.383	1.060	16.5
ARCH-VAL + TESTSPEC	11.463	6.537	4.926	43.0
BASIC-DOCS + CODING	57.325	30.547	26.778	46.7
TEST / AUDIT	18.373	10.715	7.658	41.7
計	96.672	56.302	40.370	41.8

通常thông thườngNEXA

Takeaway: 削減は BASIC-DOCS+CODING（46.7%）と ARCH-VAL+TESTSPEC（43.0%）に集中。INTAKE は唯一の投資フェーズ（M0 含む、約3.0 MM は総額内）。Giảm tập trung ở BASIC-DOCS+CODING (46,7%) và ARCH-VAL+TESTSPEC (43,0%). INTAKE là pha đầu tư duy nhất (gồm M0 ~3,0 MM, đã nằm trong tổng).

出典:Nguồn: layout-estimate.csv (VERIFIED sum 96.67→56.30) · data-appendix §C,§I · writer-vi §3.5.

04c / 分布Phân bố

145画面の分布 - rank / DEV-tier / 難易度Phân bố 145 màn - rank / DEV-tier / 難易度

3つの軸で145画面を分類。AI-rank はAI支援の強さ、DEV-tier は人手の難度、難易度は実装の複雑さ。Phân loại 145 màn theo 3 trục. AI-rank = độ mạnh AI hỗ trợ, DEV-tier = độ khó tay người, 難易度 = độ phức tạp triển khai.

AI-rank · S=20 · A=63 · B=54 · C=8 (S=AI 非常に強いrất mạnh ... C=AI 弱いyếu)

S 20A 63B 54C 8

DEV-tier · S=38 · A=22 · B=31 · C=32 · D=22

S 38A 22B 31C 32D 22

難易度 · S=19 · M=64 · L=54 · XL=8

S 19M 64L 54XL 8

Takeaway: 難易度 XL と AI-rank C は共に8画面 - これが cut-off の天井を決める難領域。rank A+B ≈ 85%（工数ベース）で、ここがAI支援の主戦場。難易度 XL và AI-rank C đều 8 màn - chính là nhóm khó chặn trần cut-off. rank A+B ≈ 85% (theo công), là chiến trường chính AI hỗ trợ.

詳細を開く: 大項目別の cut% (est人日→aidf人日)Mở chi tiết: cut% theo 大項目 (est人日→aidf人日)

アプリ102画面 1123.1→610.0 (45.7%, n=102) · Admin事業者B2B 210.7→116.6 (44.6%, n=17) · Admin運営 159.1→83.4 (47.6%, n=14) · Web統合 118.8→60.7 (48.9%, n=12)。per-screen 合計 1611.7→870.7 = 46.0%（raw work-item、headline −41.8% MM とは別物）。アプリ102画面 1123,1→610,0 (45,7%, n=102) · Admin事業者B2B 210,7→116,6 (44,6%, n=17) · Admin運営 159,1→83,4 (47,6%, n=14) · Web統合 118,8→60,7 (48,9%, n=12). Tổng per-screen 1611,7→870,7 = 46,0% (raw work-item, khác headline −41,8% MM).

出典:Nguồn: per-screen-summary.csv (n=145, VERIFIED) · data-appendix §E.

05 / 柔軟性Linh hoạt

Minrally は product - 顧客が途中で変えたらどうなるかMinrally là product - khách đổi giữa chừng thì sao

顧客は product owner。Figma を自ら提供し、sprint に参画し、v1を見てから変更します。spec-driven の仕組みは変更時に手戻りの重荷にならないか、−41% は維持されるか。Khách là product owner. Tự cung cấp Figma, join sprint, xem v1 rồi đổi. Cơ chế spec-driven có thành gánh nặng 手戻り khi đổi không, −41% có giữ được không.

変更のコストを小さく・範囲を限定に： impact-analysis で何が変わるか約30秒で判明。baseline −41.8% は崩れず、変更は追加 MM として別途定量化。Đổi rẻ, có phạm vi: impact-analysis ~30 giây biết đúng cái gì lệch. Baseline −41,8% không sụp; đổi định lượng riêng thành MM bổ sung.

~30simpact analysisimpact analysis

詳細を開く: change-request の具体例と Sprint A/B/C WBSMở chi tiết: ví dụ change-request + WBS Sprint A/B/C

具体例（churn = change-request）: 顧客が Sprint B 完了後に「HexMap 画面に新しいフィルタ UI を追加したい」と要求。NEXA は impact-analysis（約30秒）を実行し、影響範囲（SCR-010 の BD-SCR-010 / DD-SCR-010 / code / test）を正確に特定。変更は baseline の外に置き、追加 MM として定量化（N画面 × per-screen effort delta）。残り144画面には触れません。

Sprint WBS の構成: パイプラインは Sprint A / B / C（各 10-15画面）でスライスして進行。各 sprint では1画面あたり RD→BD→DD→code→test を一貫して完了させます。顧客は各 sprint の v1 を確認してから v2/v3 の変更を判断。これにより変更を early に発見し、後工程の修正コストを最小化します。 Ví dụ cụ thể (churn = change-request): Khách sau Sprint B hoàn thành yêu cầu "thêm filter UI mới vào màn HexMap". NEXA chạy impact-analysis (~30 giây), xác định đúng phạm vi ảnh hưởng (BD-SCR-010 / DD-SCR-010 / code / test của SCR-010). Đổi đặt ngoài baseline, định lượng thành MM bổ sung (N màn x delta effort per-screen). Không đụng 144 màn còn lại.

WBS Sprint A/B/C: Pipeline chạy theo lát Sprint A / B / C (mỗi sprint ~10-15 màn). Mỗi sprint hoàn thành trọn RD→BD→DD→code→test từng màn. Khách xem v1 từng sprint rồi mới quyết v2/v3. Nhờ đó phát hiện đổi sớm, giảm tối đa chi phí sửa hậu kỳ.

出典:Nguồn: writer-vi §4.3 · proposal §7.1 WBS · Lương quyết 14/6 (churn = change-request).

回答の柱は、traceability が変更を安くすることです 🟢。 各画面が BD → DD → code → test を同一IDで連結するため、1画面を変えると NEXA は正確に何を触るべきか把握します。Trụ cột: traceability làm cho việc đổi rẻ 🟢. Mỗi màn nối BD → DD → code → test cùng một ID, nên đổi 1 màn thì NEXA biết chính xác phải đụng cái gì.

HexMap画面の Figma 変更Đổi Figma màn HexMap ↓ IDによる impact analysis（約30秒）impact analysis bằng ID (~30 giây) 正確に判明: どの BD / DD / code / test がずれるかbiết đúng: BD / DD / code / test nào lệch ↓ re-spec + re-test は当該画面のみ（delta）re-spec + re-test chỉ màn đó (delta) 残り145画面に触れないkhông đụng 145 màn còn lại

「−41.8% は途中変更で崩れないか」への直答。Đáp thẳng "−41,8% có sụp khi đổi giữa chừng". −41.8% は M0 で確定する scope 上の baseline です。途中変更は baseline の外に置き、別途 change-request として impact-analysis で定量化します（N画面変更 → 追加 MM）。つまり baseline は崩れません。NEXA が変えるのは1回ごとの変更コスト（impact 30秒 + 当該画面のみの re-spec）であり、「無料で変更」でも「変更で価格が崩壊」でもありません。−41,8% là baseline trên scope chốt ở M0. Đổi giữa chừng đặt ngoài baseline, định lượng riêng thành change-request qua impact-analysis (đổi N màn → MM bổ sung). Vậy baseline không sụp. Cái NEXA đổi là chi phí mỗi lần đổi (impact 30 giây + re-spec chỉ màn đó), không "đổi free" cũng không "đổi vỡ giá".

sprint で進行、waterfall ではありません。 パイプラインはスライス（Sprint A/B/C）で進み、各 sprint 約10-15画面を RD→BD→DD→code→test 一貫で。顧客は v1 を見てから v2/v3 を判断します。デザインは顧客の自主領域で、アプリ102画面は顧客 Figma を使用（Fabbi にデザイン工数は発生しません）。Chạy theo sprint, không phải waterfall. Pipeline chạy theo lát (Sprint A/B/C), mỗi sprint ~10-15 màn trọn RD→BD→DD→code→test. Khách xem v1 rồi quyết v2/v3. Design là quyền tự chủ khách, 102 màn app dùng Figma khách (Fabbi không phát sinh công design phần này).

誠実な境界。Ranh giới trung thực. NEXA が最も強いのは spec-driven の doc-gen / test-gen。速く変わる product での価値は traceability + 手戻り防止 + 監査ドキュメントであり、「あらゆる変更への自動追従」ではありません。その自動追従は現状ロードマップ ⚪（v3.2 alpha）で、約束しません。NEXA mạnh nhất ở doc-gen / test-gen spec-driven. Với product đổi nhanh, giá trị = traceability + chống 手戻り + tài liệu kiểm toán, KHÔNG phải "tự động bám theo mọi thay đổi". Việc tự bám đó hiện là lộ trình ⚪ (v3.2 alpha), không hứa.

Takeaway: flexibility の本質は「変更を安く・範囲限定にする」traceability 🟢。「自動追従」は ⚪ ロードマップで約束に含めません。Bản chất flexibility là traceability "đổi rẻ, có phạm vi" 🟢. "Tự bám thay đổi" là ⚪ lộ trình, không đưa vào cam kết.

出典:Nguồn: data-appendix §H · writer-vi §4.2-§4.6 · proposal §7.1 WBS · Lương quyết 14/6 (churn = change-request).

06 / 位置づけVị thế

NEXA は Copilot を内包する（対立ではない）NEXA bao trùm Copilot (không đối lập)

Copilot は優れたコード補助です。2026年版は agent mode・code review・データレジデンシーも備えます。論点は「Copilot が弱い」ではなく、145画面の JP B2B 案件が評価される工程の広さです。Copilot là trợ thủ code tốt. Bản 2026 có agent mode, code review, cả data residency. Vấn đề không phải "Copilot yếu" mà là độ rộng các pha được tính trong case JP B2B 145 màn.

工程カバーの広さが差： Copilot が確実にカバーするのは code 生成（1工程）。NEXAは BD/DD/traceability/ゲート/JP納品を含む全6工程をカバー。Khác biệt ở độ rộng pha: Copilot chắc chắn phủ code (1 pha). NEXA phủ toàn bộ 6 pha gồm BD/DD/traceability/gate/tài liệu JP.

6:1工程カバーpha được phủ

詳細を開く: Copilot 2026 の正確な能力と NEXA との違いMở chi tiết: năng lực thực Copilot 2026 và khác biệt với NEXA

Copilot 2026 の VERIFIED 事実（github.blog + docs.github.com 確認済み）:
- agent mode: PR の自動生成・test の自動実行・自動修正（auto PR / run test / fix）
- code review: 自動コードレビュー
- Spark: 自然言語でのアプリ生成（新機能）
- データレジデンシー: JP リージョンも対応（「日本は対応外」という主張は誤り。VERIFIED）

なぜ NEXA が superset か（Copilot を下げずに）:
Copilot はコード補助として優れています。ただし145画面・補助金・JP標準監査ドキュメントが必要なケースでは、BD/DD の自動生成・要件→test の traceability・コード前品質ゲート・17-19名の一貫性 governance が不可欠であり、これらは Copilot のスコープ外です。NEXA は Copilot を置き換えるのではなく、その上に JP プロジェクト向けの process layer を積んだ superset です。Copilot 系ツールは NEXA の中で引き続き利用可能です。 Copilot 2026 - sự thật VERIFIED (github.blog + docs.github.com):
- agent mode: tự động tạo PR / chạy test / fix bug
- code review: review code tự động
- Spark: sinh app từ ngôn ngữ tự nhiên (tính năng mới)
- Data residency: có hỗ trợ JP region (claim "Copilot không có JP data residency" là SAI, đã VERIFIED)

Vì sao NEXA là superset (không hạ thấp Copilot):
Copilot là trợ thủ code tốt. Tuy nhiên với 145 màn - trợ cấp - tài liệu kiểm toán chuẩn JP, việc tự động sinh BD/DD, traceability requirement->test, gate trước code, governance nhất quán 17-19 người là bắt buộc - và đây là ngoài scope Copilot. NEXA đặt process layer cho dự án JP lên trên Copilot, không thay thế. Tool Copilot vẫn dùng được bên trong NEXA.

出典:Nguồn: CLAUDE.md §2 (Copilot 2026 VERIFIED github.blog + docs.github.com) · nexa-vs-copilot-vi.md · data-appendix §H.

プロジェクト工程Pha dự án	自前 + CopilotTự làm + Copilot	NEXA
コード生成 (FE/BE)Sinh code (FE/BE)	対応có	対応có
基本設計 / 詳細設計の生成Sinh 基本設計 / 詳細設計	なしkhông	対応có
要件→test の traceabilityTraceability requirement→test	なしkhông	対応có
コード前の品質ゲートGate chất lượng trước code	なしkhông	対応có
JP標準の納品ドキュメントTài liệu bàn giao chuẩn JP	なしkhông	対応có
17〜19名の一貫性ガバナンスGovernance nhất quán 17-19 người	なしkhông	対応có

NEXA は Copilot を置き換えるのではなく、その上に process gate・JP artifact・traceability を載せた superset です。コード補助としての Copilot 系は、NEXA の中で引き続き使えます。NEXA không thay thế Copilot mà là superset đặt process gate / JP artifact / traceability lên trên. Copilot với vai trò trợ thủ code vẫn dùng tiếp được bên trong NEXA.

Takeaway: Copilot を下げず正しく評価（2026 は data residency も有）。差は工程の広さ - NEXA = Copilot ⊂ NEXA。Không hạ thấp Copilot, đánh giá đúng (2026 có cả data residency). Khác biệt là độ rộng pha - NEXA = Copilot ⊂ NEXA.

出典:Nguồn: CLAUDE.md §2 (Copilot 2026 VERIFIED github.blog + docs.github.com) · nexa-vs-copilot-vi.md.

07 / 検証と成熟度Kiểm chứng + độ trưởng thành

顧客は事前に信じる必要はない - M0 が検証するKhách không cần tin trước - M0 kiểm chứng

本資料の全%は、顧客が大部分を投資する前に、本プロジェクト上で再計測されます。Mọi % trong tài liệu được đo lại trên chính dự án trước khi khách xuống tiền phần lớn.

M0で確率が上がる： 達成確度 80%→95%、見積り誤差 ±15%→±5%。5ヶ月 + M0 vs 手作業 8-9ヶ月。ピーク 17-19名。M0 nang xac suat thanh cong: dat thanh 80%→95%, sai so est ±15%→±5%. 5 thang + M0 vs thu cong 8-9 thang. Peak 17-19 nguoi.

80→95%達成確度dat thanh

詳細を開く: M0 の具体的ステップとロックインなしの根拠Mở chi tiết: các bước cụ thể M0 + căn cứ không lock-in

M0 の具体的ステップ:
1. 既存 Web みんラリのソースをスキャン → KB 構築（data model / logic / 命名規約を抽出）
2. 実際の Minrally 画面（代表的な数画面）で NEXA パイプラインを試行
3. effort-log で全ての数値を再計測（est vs actual を画面単位で記録）
4. 達成確度 80%→95%、見積り誤差 ±15%→±5% を確認してから全体コミット

ロックインなしの根拠: 納品物は JP 標準の設計書 / code / test 一式。NEXA エンジンは Fabbi の社内ツールであり、納品物自体は NEXA に依存しません。仮に将来 NEXA を使わなくなっても、顧客は完全な JP 標準ドキュメントと動作するコードを保持します。M0 完了後に全体をコミットするため、顧客は低コストで検証した上で判断できます。 Các bước cụ thể của M0:
1. Quét source Web みんラリ cũ → dựng KB (trích xuất data model / logic / quy ước đặt tên)
2. Chạy thử NEXA pipeline trên một số màn Minrally đại diện thực tế
3. Đo lại mọi số bằng effort-log (ghi est vs actual từng màn)
4. Xác nhận đạt 達成確度 80%→95%, sai số ±15%→±5% rồi mới cam kết toàn bộ

Căn cứ không lock-in: Bàn giao là bộ 設計書 / code / test chuẩn JP. Engine NEXA là tool nội bộ Fabbi, bản bàn giao không phụ thuộc NEXA. Nếu tương lai không dùng NEXA nữa, khách vẫn giữ đủ tài liệu JP chuẩn + code chạy được. Sau M0 mới cam kết toàn bộ, nên khách có thể quyết định sau khi kiểm chứng chi phí thấp.

出典:Nguồn: data-appendix §A (M0/POC locked numbers) · writer-vi §3.5, §4.5 · proposal §7.2.

M0（初期段階、低コスト）M0 (giai đoạn đầu, chi phí thấp) 既存 Web スキャン → KB 構築quét Web cũ → dựng KB 実画面で試行chạy thử trên màn thật 全ての数値を effort-log で再計測đo lại mọi số bằng effort-log ↓ 達成確度 80% → 95% · 見積り誤差 ±15% → ±5%達成確度 80% → 95% · sai số est ±15% → ±5% 5ヶ月 + M0 vs 手作業 8-9ヶ月、ピーク 17-19名Timeline 5 tháng + M0 vs thủ công 8-9 tháng. Peak 17-19 người. その後に全体をコミットsau đó mới cam kết toàn bộ

🟢 出荷済み（コミット対象）Đã ship (đối tượng cam kết)

JP定型の設計書 doc-gen + コード前ゲートdoc-gen 設計書 chuẩn JP + gate trước code
ID連携の traceability + impact-analysistraceability ID-linked + impact-analysis
governance エンジン（規律ある vibecode）engine governance (vibecode kỷ luật)
納品パッケージ（設計書 / code / test、ロックインなし）gói bàn giao (設計書 / code / test, không lock-in)

⚪ ロードマップ（約束に含めない）Lộ trình (không đưa vào cam kết)

orchestration E2E の完全自動化tự động hóa E2E orchestration toàn phần
DD→CODE traceability の完全性tính đầy đủ traceability DD→CODE
変更への自動追従（product-agility 自動化）tự bám theo thay đổi (product-agility automation)
NEXA v3.2 は現状 alphaNEXA v3.2 hiện là alpha

ロックインなし。Không lock-in. 納品物は JP標準の設計書 / code / test。NEXA エンジンは Fabbi の社内ツールで、全 artifact は独立して使用できます。仮に明日 NEXA がなくなっても、顧客は継続に十分なドキュメントと JP標準コードを保持します。Bàn giao là 設計書 / code / test chuẩn JP. Engine NEXA là tool nội bộ Fabbi, mọi artifact dùng độc lập được. Giả sử mai NEXA biến mất, khách vẫn giữ đủ tài liệu + code chuẩn JP để tiếp tục.

Takeaway: 本資料の数値は信仰ではなく検証対象。M0 が低コストで再計測し、🟢 のみコミット、⚪ は約束しない。NEXA v3.2 = alpha と明言。Số trong tài liệu không phải đức tin mà là đối tượng kiểm chứng. M0 đo lại với chi phí thấp, chỉ cam kết 🟢, không hứa ⚪. Nói rõ NEXA v3.2 = alpha.

出典:Nguồn: data-appendix §A,§H,§I · writer-vi §3.5, §4.5 · 工数見積もり.xlsx (5C.M0-POC) · proposal §7.2.