Odoo AI Implementation Platform 開発基本資料

1. 目的

本システムは、既存ERP設計書・帳票・画面仕様・DataSource・業務資料をAIで解析し、Odoo標準フローとの差分を抽出し、必要な質問だけを生成し、回答・判断・業務ルールをGraph / DomainGuideへ焼き込み、最終的にOdooのモデル・フィールド・View・メニュー・権限・コード生成までつなげる開発支援基盤である。

目的は、コンサルタントや業務担当者のヒアリング量を減らし、要件定義からOdoo実装までの後戻りを最小化すること。

2. 基本思想

2.1 LLMに記憶させない

API化すると、チャットのようにLLMが過去文脈を自然に覚えている前提は使えない。

そのため、記憶の正本はLLMではなく、以下に分ける。

PostgreSQL：状態管理、一覧、CRUD、レビュー、ジョブ、監査ログ
Neo4j：業務要素、関係性、質問、回答、Decision、DomainGuide、Odoo仕様Graph
ChromaDB：設計書本文、DomainGuide本文、Odoo標準知識、過去案件ナレッジの検索
Git：生成コード、差分、レビュー履歴

LLMは、毎回Context Packを受け取り、必要な情報だけを読んで処理する。

2.2 Graphを正本にする

本システムでは、チャット回答ではなくGraphを業務理解の正本とする。

追跡すべきこと：

なぜこの業務要素があるのか
どの資料に基づくのか
どの質問回答で確定したのか
どのDomainGuideに基づくのか
どのOdooモデル・フィールド・Viewに変換されたのか
どのコードファイルを生成するのか

2.3 いきなりコード生成しない

必ず以下の順序を踏む。

資料解析
業務要素抽出
モジュール分類
DomainGuide生成
新規機能オーダー / AIおすすめ機能
横断論点解決
Odoo実装仕様Graph
人間レビュー
コード生成
Dev環境反映・検証

3. 全体レイヤー構成

最終構成は以下の通り。

Document Layer
Business Element Extraction Layer
Module Mapping Layer
Module DomainGuide Layer
Feature Order / Recommendation Layer
Cross-Module Resolution Layer
Integrated Odoo Implementation Spec Layer
Code Generation Layer
Deployment & Validation Layer
Operation Feedback Layer
Test & Validation Design Layer
Estimate / Proposal Layer
Audit / Explanation Layer
Impact Analysis Layer
Odoo Standard Knowledge Base Layer

4. Layer 1：Document Layer

役割

既存資料を取り込む。

対象：

Excel設計書
PDF設計書
帳票レイアウト
画面仕様
イベント仕様
DataSource
既存SQL
既存業務フロー
既存Excel運用資料

機能

ファイルアップロード
シート / ページ / セクション分解
表・帳票・画面項目抽出
元資料とのリンク保持
原文チャンク化
ChromaDBへの登録

主な保存先

PostgreSQL：documents, document_sections, parse_jobs
ChromaDB：document chunks
Neo4j：SourceDocument

5. Layer 2：Business Element Extraction Layer

役割

資料から業務要素を抽出する。

抽出対象：

画面
処理
帳票
ラベル
イベント
DataSource
チェック処理
マスタ
一覧
バッチ

出力例

発注書
原料・資材発注一覧
原材料発注量予実チェック
HT入荷
購入検査記録
MTX_MX原料・資材管理状況

主ノード

BusinessElement
SourceDocument

6. Layer 3：Module Mapping Layer

役割

BusinessElementをOdoo/ERPモジュールに分類する。

対象モジュール：

Purchase / 購買
Inventory / 在庫
Receipt / 入荷
Quality / 検査
Manufacturing / 製造
Sales / 販売
Accounting / 会計
Organization / 組織・権限
Barcode / HT・作業ログ
Reporting / 帳票・分析

重要方針

複数モジュールにまたがるものは、無理に1つへ確定しない。

例：

発注量予実チェック → Purchaseに属するが、MRP / Inventoryに依存
検収基準請求 → Purchase / Quality / Accountingに依存
HT作業者取得 → Inventory / Receipt / Delivery / Organizationに依存

横断するものはCrossModuleIssue候補にする。

7. Layer 4：Module DomainGuide Layer

役割

モジュール別の業務ルール・禁止ルール・判断条件を作る。

購買例：

RFQは基本使わず直接発注中心
価格協定を正式単価マスタとして扱う
重要品目は発注量予実チェック必須
差異が大きい場合は責任者承認

主ノード

DomainGuideTopic
BusinessRule
Question
Answer
Decision

8. Layer 5：Feature Order / Recommendation Layer

役割

既存資料にはない新規追加機能を受け付け、AIが追加機能を提案し、質問化し、Graphへ焼き込む。

必要性

既存資料解析だけでは「今ある業務をどう移すか」に留まる。

実際には以下が必要になる。

Odoo化するなら追加したい機能
業務効率化のために提案したい機能
Graph / DomainGuideがあるから実現できる機能
旧画面を持ち込まない代替機能

主ノード

FeatureOrder
FeatureRecommendation
FeatureCandidate
FeatureQuestion
FeatureDecision
FeaturePriority
FeatureImpact
FeatureScope
FeatureStatus

購買におけるおすすめ機能例

価格協定期限切れアラート
発注量差異ダッシュボード
重要品目の承認強化
単価手動変更レポート
仕入先別納期遅延分析
MTX_MX代替ダッシュボード

状態遷移

requested
recommended
candidate
question_generated
answered
approved
rejected
pending_cross_module
resolved
ready_for_odoo_spec
mapped_to_odoo_spec
generated

9. Layer 6：Cross-Module Resolution Layer

役割

モジュール別に解決できない論点を集約し、全体最適で解決する。

主ノード

CrossModuleIssue
DataOwnership
ProcessBoundary
IntegrationPoint
ResolutionDecision
PendingDependency
Conflict
CodeGenerationBlocker

代表論点

論点	関係モジュール	解決すべきこと
発注量予実チェック	Purchase / MRP / Inventory	予定・実績の正本
入荷数量差異	Purchase / Inventory	差異確定の責務
検収基準請求	Purchase / Quality / Accounting	検査結果と請求可否
価格協定と補充	Purchase / Inventory	価格・補充・発注判断の関係
重要品目	Product / Purchase / Quality / MRP	重要品目定義の正本
毒劇物証跡	Purchase / Quality / Inventory / Accounting	証跡未完了時に止める処理
HT作業ログ	Inventory / Receipt / Delivery / Organization	作業者・端末・操作ログの正本

コード生成条件

CrossModuleIssue.status = resolved
DataOwnership.status = confirmed
ProcessBoundary.status = confirmed
CodeGenerationBlocker = 0

10. Layer 7：Integrated Odoo Implementation Spec Layer

役割

横断論点解決後に、Odoo実装仕様を統合する。

対象：

OdooModelSpec
OdooFieldSpec
OdooViewSpec
OdooTabSpec
OdooButtonSpec
OdooSmartButtonSpec
OdooMenuSpec
OdooActionSpec
OdooSecurityRuleSpec
OdooComputeSpec
OdooOnchangeSpec
OdooConstraintSpec
OdooReportSpec
DomainGuideMappingRule

重要方針

モジュール別仕様を足し合わせるだけではなく、Cross-Module Resolution Layerを通す。

例：

予定数量の正本はMRP
Purchaseにはチェック結果だけ表示
Inventoryが入荷実績の正本
Qualityが検査結果の正本

11. Layer 8：Code Generation Layer

役割

Integrated Odoo Spec GraphからOdoo addonコードを生成する。

生成対象：

manifest.py
models/*.py
views/*.xml
security/ir.model.access.csv
security/*.xml
reports/*.xml
data/*.xml
wizard/*.py
tests/*.py

Code Generation Gate

以下を満たす必要がある。

未解決CrossModuleIssueがない
DataOwnershipが確定
DomainGuideがconfirmed
OdooSpecがreviewed / approved_for_codegen
SecuritySpecが存在
TestScenarioが存在
生成差分がレビュー済み

12. Layer 9：Deployment & Validation Layer

役割

生成コードをDev環境に反映し、実機検証する。

機能：

Gitブランチ作成
Odoo addon生成
Docker / Odoo dev環境へ反映
モジュールインストール
View表示確認
メニュー確認
ボタン実行確認
権限確認
ログ確認

13. Layer 10：Operation Feedback & Learning Loop Layer

役割

運用後の改善要望・不具合・レビュー差戻し・実機検証結果を収集し、次回以降の設計・質問生成・DomainGuide生成・OdooSpec生成・コード生成へ再利用する。

このLayerは、本システムを「作れば作るほど賢くなるERP実装知能基盤」にするための中核である。

基本方針

LLMに直接記憶させるのではなく、案件ごとの実装結果・バグ・修正・レビュー結果・運用フィードバックを、Graph / DomainGuide / Chroma / PostgreSQLへ蓄積する。

次案件では、それらをContext Packとして再構成し、AIの判断材料として使う。

入力

生成コード
Git diff
Odoo install result
Validation result
Test result
Bug report
User feedback
Consultant correction
Customer answer
Operation issue
Review rejection / approval
Manual code fix
Deployment log

出力

ExceptionPattern
QuestionEffectiveness
DomainGuideImprovement
OdooSpecCorrection
CodePattern
BugPattern
FixPattern
ValidationResult
RecommendationPattern
ReusablePattern

蓄積する知識

1. 例外パターン

業界・国・商習慣・業務慣行に由来する例外を蓄積する。

例：

日本の化学メーカー特有の毒劇物証跡
日本型締め請求
商社経由の仕入先・メーカー分離
オーストラリア税制対応
検収基準請求
分納・過入荷・入荷差異
製造消費と在庫計上のズレ

2. 質問の最適化

質問自体を資産化する。

各質問について以下を記録する。

その質問で不整合が解消したか
CrossModuleIssueが解決したか
DomainGuideが確定したか
OdooSpecが確定したか
不要だったか
順番が適切だったか

質問は単なるヒアリング項目ではなく、要件確定のための最短経路として改善される。

3. コード変換パターン

DomainGuideからOdooSpec、OdooSpecからコードへの変換結果を蓄積する。

記録するもの：

どのDomainGuideから
どのOdooSpecが生成され
どのCodeUnitが生成され
どのテストに通り
どのバグが出て
どう修正されたか

これにより、次回コード生成時に過去の失敗を回避できる。

Reusable Pattern Graph

顧客固有のProject Graphとは別に、匿名化・抽象化された再利用可能な知識Graphを作る。

Project Graph

顧客固有情報を含む。

顧客固有の品目名
顧客固有の帳票名
顧客固有の組織名
顧客固有の業務名
案件内の質問回答

Reusable Pattern Graph

次案件に再利用可能な抽象パターンを保持する。

業界パターン
国別ローカライズパターン
業務例外パターン
質問最適化パターン
DomainGuide改善パターン
OdooSpec設計パターン
CodePattern
BugPattern
FixPattern

例：

顧客Aの毒劇物譲渡証管理
  ↓ 匿名化・抽象化
化学メーカー向け毒劇物証跡管理パターン

主ノード

LearningEvent
OperationFeedback
ExceptionPattern
IndustryPattern
CountryRule
LocalizationRule
BusinessCustomPattern
QuestionEffectiveness
DomainGuideImprovement
SpecCorrection
CodePattern
BugPattern
FixPattern
ValidationResult
RegressionTest
RecommendationPattern
ReusablePattern

主な関係

OBSERVED_IN_PROJECT
DERIVED_FROM_BUG
FIXED_BY
IMPROVES_DOMAIN_GUIDE
IMPROVES_QUESTION
IMPROVES_CODE_PATTERN
AVOIDS_BUG
REUSED_IN_PROJECT
SIMILAR_TO_PATTERN
PROMOTED_TO_REUSABLE_PATTERN
ANONYMIZED_FROM

API案

Feedback API

POST /feedback/operation
POST /feedback/bug
POST /feedback/spec-correction
POST /feedback/domain-guide-correction
POST /feedback/question-effectiveness
POST /feedback/code-fix
POST /feedback/review-result

Learning API

POST /learning/extract-patterns
GET /learning/patterns
GET /learning/patterns/{id}
GET /learning/patterns/similar
POST /learning/promote-pattern
POST /learning/anonymize

Reuse API

POST /reuse/suggest-patterns
POST /reuse/apply-pattern
GET /reuse/project/{project_id}/matched-patterns

KPI

質問系KPI

平均質問数
未回答質問率
質問1件あたりのDecision確定率
質問1件あたりのCrossModuleIssue解決率
再質問率
不要質問率

設計系KPI

DomainGuide初回採用率
DomainGuide修正率
OdooSpec修正率
CrossModuleIssue解決時間
Specレビュー差戻し率

コード系KPI

初回インストール成功率
生成コードの手修正率
テスト通過率
再生成回数
同種バグ再発率
Validation失敗率

提案系KPI

AIおすすめ機能採用率
FeatureRecommendation採用率
提案からOdooSpec化までの時間
提案却下率
提案による追加売上・工数削減効果

重要な注意点

1. 顧客データをそのまま再利用しない

Project Graphには顧客固有情報が含まれるため、Reusable Pattern Graphへ昇格する際は必ず匿名化・抽象化する。

2. 成功パターンと失敗パターンを分ける

以下を区別する。

採用された設計
却下された設計
バグを出した設計
修正後に成功した設計
再利用してよい設計

3. AI提案には根拠を必須にする

FeatureRecommendation、Question、OdooSpec、CodePatternは、必ず根拠ノードを持つ。

例：

過去5案件で採用された
過去3案件で不整合を解消した質問である
Odoo 18で検証済みのコードパターンである
同種バグを過去に回避したFixPatternである

完了条件

実機検証結果を保存できる
バグと修正内容をGraphに登録できる
Review結果を蓄積できる
QuestionEffectivenessを記録できる
ReusablePatternへ昇格できる
次案件のContext Packに過去Patternを注入できる

14. Layer 11：Test & Validation Design Layer

役割

OdooSpecからテストケースを自動生成する。

対象：

Python unit test
UI smoke test
権限テスト
データ投入テスト
ボタン実行テスト
帳票出力テスト

例：購買

重要品目で差異がある場合、承認が必要になるか
価格協定と異なる単価の場合、理由入力が必要か
発注量チェック未実行時に発注確定できるか

15. Layer 12：Estimate / Proposal Layer

役割

OdooSpecから見積・提案資料を生成する。

算出材料：

新規モデル数
標準拡張モデル数
フィールド数
View数
帳票数
ボタン数
権限数
DomainGuide連携数
CrossModuleIssue数
未確定質問数

出力：

概算工数
実装スコープ
カスタム範囲
標準対応範囲
リスク
保留事項

16. Layer 13：Audit / Explanation Layer

役割

顧客説明・監査・社内レビュー向けに、判断根拠を出力する。

回答できる問い：

なぜこのカスタムが必要なのか
なぜOdoo標準で足りないのか
なぜ旧画面を持ち込まないのか
誰の回答で確定したのか
どの資料に根拠があるのか
どのDomainGuideに基づくのか

17. Layer 14：Impact Analysis Layer

役割

変更差分の影響範囲を分析する。

例：価格協定ルールを変更した場合

影響対象：

product.supplierinfo
purchase.order.line
単価変更constraint
発注書帳票
価格協定期限切れアラート
価格関連FeatureRecommendation

主機能

変更影響ノード抽出
再レビュー対象抽出
再生成が必要なコードファイル抽出
再質問が必要な論点抽出

18. Layer 15：Odoo Standard Knowledge Base Layer

役割

Odoo標準のモデル・フィールド・View・フローを知識ベース化する。

対象：

purchase.order
purchase.order.line
stock.picking
stock.move
account.move
mrp.production
quality.check
res.partner
product.template
product.supplierinfo

用途：

Odoo標準で対応できるか判定
カスタム要否判定
標準との差分抽出
View継承先の候補提示
モデル選定支援

19. Context Pack / Memory Snapshot

課題

API化すると、LLMは会話履歴を覚えていない。

解決策

Layer4までの結果を永続化し、毎回必要な文脈だけContext PackとしてLLMに渡す。

主要コンポーネント

ProjectMemorySnapshot
ContextPackBuilder
FeatureRecommendationEngine

Context Packに含めるもの

project_id
module
confirmed_rules
business_elements
pending_cross_module_issues
do_not_migrate_as_is
odoo_fit_summary
source_nodes

20. Agent構成

本システムには、レイヤー完了判定と次工程起動を行うエージェント群が必要。

主要Agent

Project Orchestrator Agent
Layer Gate Agent
Quality Review Agent
Question Agent
Feature Recommendation Agent
Cross-Module Resolver Agent
Spec Generation Agent
Codegen Gate Agent
Impact Analysis Agent
Validation / Test Agent

21. Project Orchestrator Agent

役割

現在のLayer確認
Gate条件判定
次Layer起動
ReviewTask作成
Blocker作成
NextAction提示

自動進行してよいもの

Document parsing
BusinessElement extraction draft
Module mapping draft
Question draft generation
Graph draft write
ContextPack generation

人間承認が必要なもの

DomainGuide confirmed
CrossModule Resolution confirmed
OdooSpec approved_for_codegen
Code generation approve
Deployment approve

22. 状態管理

Layer状態

not_started
running
generated
review_required
blocked
approved
completed

BusinessElement状態

extracted
classified
mapped_to_module
question_generated
answered
graph_inferred
graph_confirmed

CrossModuleIssue状態

detected
pending
in_review
resolved
blocked
rejected

DomainGuide状態

draft
assumed
confirmed
superseded

OdooSpec状態

draft
review_required
reviewed
blocked_by_cross_module
approved_for_codegen
generated
deployed
tested

23. API構成

Document API

POST /documents/upload
POST /documents/{id}/parse
GET /documents/{id}/sections
GET /documents/{id}/elements

Business Element API

GET /elements
PATCH /elements/{id}
POST /elements/{id}/classify
POST /elements/{id}/map-module

Question API

POST /questions/generate
GET /questions
PATCH /questions/{id}/answer
POST /questions/{id}/confirm

DomainGuide API

POST /domainguide/generate
GET /domainguide/topics
PATCH /domainguide/topics/{id}
POST /domainguide/topics/{id}/confirm

Feature API

POST /features/order
POST /features/recommend
GET /features/recommendations
POST /features/{id}/promote
PATCH /features/{id}

Cross-Module API

GET /cross-module/issues
POST /cross-module/issues/detect
PATCH /cross-module/issues/{id}
POST /cross-module/issues/{id}/resolve
GET /cross-module/data-ownership
PATCH /cross-module/data-ownership/{id}
GET /cross-module/process-boundaries
POST /cross-module/gate-check

Odoo Spec API

POST /odoo/spec/generate
GET /odoo/spec/models
GET /odoo/spec/fields
GET /odoo/spec/views
PATCH /odoo/spec/{id}
POST /odoo/spec/review

Code Generation API

POST /codegen/odoo
GET /codegen/jobs/{id}
GET /codegen/jobs/{id}/diff
POST /codegen/jobs/{id}/approve
POST /codegen/jobs/{id}/commit

Deployment API

POST /deploy/dev
POST /deploy/test
GET /deploy/jobs/{id}
GET /deploy/jobs/{id}/logs

Agent API

POST /agents/orchestrator/run
POST /agents/layer-gate/check
POST /agents/question/generate
POST /agents/feature/recommend
POST /agents/cross-module/detect
POST /agents/spec/generate
POST /agents/codegen-gate/check
POST /agents/impact/analyze
POST /agents/validation/run

24. UI構成

1. Project Dashboard

現在Layer
モジュール別進捗
未解決Issue
Review待ち
NextAction
Codegen可否

2. Document Review UI

資料一覧
抽出状態
抽出要素
原文プレビュー

3. Module Mapping UI

業務要素
推定モジュール
confidence
別モジュール候補
保留理由

4. Question UI

質問
回答
回答者
確定度
Graph反映状態

5. DomainGuide UI

ルール本文
禁止ルール
参照データ
対象モジュール
confidence
confirmed / draft

6. Feature Order UI

新規機能オーダー
AIおすすめ機能
採用 / 保留 / 却下
質問生成
Graph反映

7. Cross-Module Resolution UI

横断論点一覧
関係モジュール
未解決理由
推奨解決案
データ正本
プロセス境界
コード生成ブロック有無

8. Odoo Spec Review UI

モデル
フィールド
View
タブ
ボタン
スマートボタン
メニュー
権限
compute
constraint
帳票

9. Codegen Review UI

生成ファイル一覧
差分
影響範囲
未解決ブロッカー
生成可否

10. Impact Analysis UI

変更対象
影響ノード
再レビュー対象
再生成対象ファイル
再質問対象

25. データストア設計

PostgreSQL

主に一覧・状態管理・CRUD。

候補テーブル：

projects
project_layers
documents
document_sections
business_elements
questions
answers
domain_guides
feature_orders
feature_recommendations
cross_module_issues
odoo_model_specs
odoo_field_specs
odoo_view_specs
codegen_jobs
review_tasks
blockers
audit_logs
project_memory_snapshots
context_packs

Neo4j

主に関係性・影響範囲・設計根拠。

主要ノード：

BusinessElement
OdooModule
DomainGuideTopic
BusinessRule
Question
Answer
Decision
FeatureOrder
FeatureRecommendation
CrossModuleIssue
DataOwnership
ProcessBoundary
OdooModelSpec
OdooFieldSpec
OdooViewSpec
CodeGenerationUnit
LayerRun
GateCheck
Blocker
NextAction

ChromaDB

検索・類似比較。

対象：

設計書本文
帳票説明
画面仕様
DomainGuide本文
Odoo標準知識
過去案件ナレッジ
ProjectMemorySnapshot

Git

コード・差分・レビュー履歴。

対象：

generated addons
diff
review comments
approved versions
deployment tags

26. MVP開発順序

MVP 1：Document → BusinessElement → Question

資料アップロード
要素抽出
モジュール分類
質問生成
回答登録

MVP 2：Graph / DomainGuide

Neo4j仮焼き
DomainGuide生成
質問回答反映
ContextPack生成

MVP 3：Feature Order / Recommendation

新規機能オーダー
AIおすすめ機能提案
FeatureCandidate化
質問生成

MVP 4：Cross-Module Resolution

横断論点検出
データ正本管理
プロセス境界管理
コード生成ブロッカー表示

MVP 5：Odoo Spec Graph

モデル仕様生成
フィールド仕様生成
View仕様生成
レビューUI

MVP 6：Code Generation

Odoo addon生成
Git差分
Dev環境反映

MVP 7：Validation / Impact / Estimate

実機検証
影響範囲分析
テストケース生成
見積・提案資料生成

27. 今回の購買モジュールで得た設計パターン

購買モジュールでは、以下まで確認済みの想定。

初期カスタマイズ候補

purchase.order 拡張
purchase.order.line 拡張
product.template 拡張
product.supplierinfo 拡張
purchase.quantity.check
purchase.quantity.check.line

主目的

発注量予実チェック
価格協定補足管理
重要品目・差異閾値管理
発注書上の警告・承認状態表示
チェック履歴保存

保留したもの

輸入レポート
原料・資材発注一覧帳票
MTX_MX代替画面
発注判断ルール管理画面
質問回答履歴画面
本格DomainGuide API連携

CrossModuleIssueへ上げるもの

発注量予実チェック：Purchase / MRP / Inventory
入荷数量差異：Purchase / Inventory
検収基準請求：Purchase / Quality / Accounting
価格協定と補充：Purchase / Inventory
重要品目：Product / Purchase / Quality / MRP

28. 最終的な開発方針

本システムは、単なるOdooコード生成ツールではない。

目指すものは以下。

AIが既存資料を読む
AIが業務要素を抽出する
AIがOdoo標準との差分を分類する
AIが不明点だけ質問にする
回答をGraphに焼く
DomainGuideとして判断ルールを残す
横断論点を上位層で解決する
新規機能オーダーやAIおすすめ機能もGraphに焼く
Odoo実装仕様Graphへ変換する
人間がレビューする
コード生成する
実機反映・テストする
運用後の改善をまたFeatureOrderへ戻す

この循環により、コンサルタントや業務担当者のヒアリング量を減らし、設計根拠を残し、後戻りの少ないOdoo開発を実現する。

29. 最重要コンポーネント一覧

ContextPackBuilder
ProjectMemorySnapshot
FeatureRecommendationEngine
Project Orchestrator Agent
Layer Gate Agent
Question Agent
Cross-Module Resolver Agent
Spec Generation Agent
Codegen Gate Agent
Impact Analysis Agent
Odoo Standard Knowledge Base
Validation / Test Agent

30. 開発時の優先順位

最初に作るべきもの：

Project / Layer / Status管理
Document upload / parse
BusinessElement抽出
Module Mapping
Question生成・回答登録
Neo4j Graph焼き込み
DomainGuide生成
ContextPackBuilder
Feature Recommendation
CrossModuleIssue検出
OdooSpec生成
Codegen Gate
Odoo addon生成

31. 結論

このシステムは、以下の5つを一体化する開発基盤である。

要件定義支援
業務Graph構築
DomainGuide管理
Odoo実装仕様生成
Odooコード生成・反映

中核は、GraphとDomainGuideを正本にすること。

LLMは記憶装置ではなく、DB/Graph/Chromaから構成されたContext Packをもとに、抽出・提案・質問・仕様生成・コード生成を行う処理エンジンとして使う。

この構成を前提に開発を進める。

32. MVPフェーズ別開発指示書

以下の順番で開発する。

MVP 1：Document → BusinessElement → Question
MVP 2：Graph / DomainGuide
MVP 3：Feature Order / Recommendation
MVP 4：Cross-Module Resolution
MVP 5：Odoo Spec Graph
MVP 6：Code Generation
MVP 7：Validation / Impact / Estimate

33. MVP 1：Document → BusinessElement → Question 指示書

33.1 目的

既存ERP資料をアップロードし、資料単位・セクション単位に分解し、業務要素を抽出し、Odooモジュール候補へ分類し、不明点を質問化し、回答を登録できる状態を作る。

このフェーズでは、Graphやコード生成には入らない。まず、資料から業務要素と質問を作ることを目的とする。

33.2 実装対象

資料アップロード
資料台帳作成
ファイル / シート / セクション分解
BusinessElement抽出
Odooモジュール分類
質問生成
回答登録
一覧・レビューUI

33.3 対象データ

Excel
PDF
Word
CSV
画像付き資料は一旦メタ情報のみ、OCRは後続でも可

33.4 主要テーブル案

projects
documents
document_sections
business_elements
module_mappings
questions
answers
review_tasks
audit_logs

33.5 API案

Document API

POST /documents/upload
GET /documents
GET /documents/{document_id}
POST /documents/{document_id}/parse
GET /documents/{document_id}/sections

BusinessElement API

GET /business-elements
GET /business-elements/{id}
PATCH /business-elements/{id}
POST /business-elements/extract
POST /business-elements/{id}/classify

Question API

POST /questions/generate
GET /questions
GET /questions/{id}
PATCH /questions/{id}/answer
POST /questions/{id}/confirm

33.6 BusinessElementの最低項目

id
project_id
document_id
section_id
name
element_type
summary
source_text
source_path
module_candidate
confidence
status
created_at
updated_at

33.7 Questionの最低項目

id
project_id
business_element_id
question_text
question_type
ask_to_role
priority
status
answer_text
answer_confidence
created_at
updated_at

33.8 UI要件

資料一覧画面

ファイル名
種別
アップロード日時
解析状態
抽出要素数
質問数

業務要素一覧画面

要素名
種別
概要
推定モジュール
confidence
元資料
質問有無
レビュー状態

質問一覧画面

質問ID
対象要素
質問
質問先
優先度
回答
確定度
状態

33.9 完了条件

資料をアップロードできる
資料台帳に登録される
document_sections が作成される
business_elements が抽出される
各BusinessElementにmodule_candidateが入る
confidenceが保存される
questions が生成される
回答を登録できる
回答状態が更新される

33.10 確認方法

1. 資料アップロード確認

任意のExcel/PDFをアップロード
documents に1件以上登録されること
ファイルパスまたはストレージキーが保存されること

2. セクション分解確認

POST /documents/{id}/parse を実行
document_sections にシート名・ページ名・セクション名が登録されること

3. 業務要素抽出確認

POST /business-elements/extract を実行
business_elements に画面、帳票、処理、イベントなどが登録されること
source_document / source_section を辿れること

4. モジュール分類確認

各BusinessElementに Purchase / Inventory / Manufacturing / Accounting 等の候補が入ること
Unknownが一定割合以下であること

5. 質問生成確認

POST /questions/generate を実行
confidenceが低い要素、分類不能要素、カスタム候補要素に質問が作成されること

6. 回答登録確認

PATCH /questions/{id}/answer を実行
answer_text、answer_confidence、status が更新されること

33.11 MVP 1でやらないこと

Neo4j焼き込み
DomainGuide生成
CrossModuleIssue解決
OdooSpec生成
コード生成

34. MVP 2：Graph / DomainGuide 指示書

34.1 目的

MVP 1で抽出したBusinessElement、Question、Answer、DecisionをNeo4jに仮焼きし、モジュール別DomainGuideを生成し、ContextPackを作れる状態にする。

34.2 実装対象

Neo4j仮焼き
BusinessElement Graph化
Question / Answer / Decision Graph化
DomainGuideTopic生成
BusinessRule生成
DomainGuide本文生成
質問回答反映
ContextPack生成

34.3 Neo4j主要ノード

Project
SourceDocument
BusinessElement
OdooModule
OdooFlowStep
Question
Answer
Decision
DomainGuideTopic
BusinessRule
ActorRole

34.4 主要リレーション

DERIVED_FROM
BELONGS_TO_MODULE
BELONGS_TO_FLOW
HAS_UNKNOWN
ASK_TO
ANSWERED_BY
CONFIRMED_AS
CONFIRMS_TOPIC
HAS_RULE
DERIVED_FROM_DECISION

34.5 API案

Graph API

POST /graph/sync
GET /graph/business-elements/{id}
GET /graph/questions/{id}
GET /graph/impact/{node_id}

DomainGuide API

POST /domainguide/generate
GET /domainguide/topics
GET /domainguide/topics/{id}
PATCH /domainguide/topics/{id}
POST /domainguide/topics/{id}/confirm

Context API

POST /context-pack/build
GET /context-pack/{id}

34.6 ContextPackに含めるもの

project_id
target_module
business_elements
confirmed_decisions
assumed_decisions
questions_open
domain_guides
business_rules
pending_items
source_nodes

34.7 完了条件

BusinessElementがNeo4jに同期される
Question / Answer / DecisionがNeo4jに同期される
DomainGuideTopicが生成される
BusinessRuleが生成される
DomainGuide本文が生成される
ContextPackが生成できる
ContextPackから根拠ノードを辿れる

34.8 確認方法

1. Graph同期確認

POST /graph/sync を実行
Neo4j上で BusinessElement 件数がPostgreSQLと一致すること

2. 質問回答反映確認

回答済みQuestionが Answer / Decision に接続されていること

3. DomainGuide生成確認

POST /domainguide/generate を実行
DomainGuideTopicとBusinessRuleが作成されること

4. ContextPack確認

POST /context-pack/build を実行
対象モジュールのBusinessElement、Decision、DomainGuideが含まれること
source_nodes が含まれること

34.9 MVP 2でやらないこと

新規機能提案
CrossModuleIssue解決
OdooSpec生成
コード生成

35. MVP 3：Feature Order / Recommendation 指示書

35.1 目的

既存資料にはない新規機能オーダーを登録し、AIがGraph / DomainGuideをもとにおすすめ機能を提案し、FeatureCandidate化し、必要な質問を生成する。

35.2 実装対象

新規機能オーダー登録
AIおすすめ機能生成
FeatureRecommendation保存
FeatureCandidate化
追加機能用質問生成
採用 / 保留 / 却下
Graph焼き込み

35.3 主要ノード / テーブル

FeatureOrder
FeatureRecommendation
FeatureCandidate
FeatureQuestion
FeatureDecision
FeatureImpact
FeaturePriority

35.4 API案

POST /features/order
GET /features/orders
POST /features/recommend
GET /features/recommendations
POST /features/{id}/promote
PATCH /features/{id}/status
POST /features/{id}/questions/generate

35.5 FeatureRecommendationに必要な項目

name
description
reason
priority
scope
target_module
cross_module_flag
based_on_domain_guides
based_on_business_rules
based_on_decisions
required_questions
status

35.6 完了条件

新規FeatureOrderを登録できる
ContextPackをもとにFeatureRecommendationを生成できる
根拠DomainGuide / BusinessRule / Decisionにリンクされる
採用したRecommendationをFeatureCandidate化できる
Candidateに対して質問を生成できる
横断が必要なCandidateはCrossModuleIssue候補に送れる

35.7 確認方法

1. 新規機能オーダー確認

POST /features/order を実行
FeatureOrderが保存されること

2. おすすめ機能確認

POST /features/recommend を実行
FeatureRecommendationが複数件生成されること
各Recommendationにreasonとbased_onがあること

3. Candidate化確認

POST /features/{id}/promote を実行
FeatureCandidateが作成されること

4. 質問生成確認

POST /features/{id}/questions/generate を実行
FeatureCandidateに紐づく質問が作成されること

35.8 MVP 3でやらないこと

OdooSpec化
コード生成
実装見積

36. MVP 4：Cross-Module Resolution 指示書

36.1 目的

複数モジュールにまたがる論点を検出し、データの正本、プロセス境界、統合判断、コード生成ブロッカーを管理する。

36.2 実装対象

横断論点検出
CrossModuleIssue登録
関係モジュール設定
DataOwnership管理
ProcessBoundary管理
ResolutionDecision登録
CodeGenerationBlocker表示

36.3 主要ノード / テーブル

CrossModuleIssue
OdooModule
DataOwnership
ProcessBoundary
IntegrationPoint
ResolutionDecision
CodeGenerationBlocker

36.4 API案

POST /cross-module/issues/detect
GET /cross-module/issues
GET /cross-module/issues/{id}
PATCH /cross-module/issues/{id}
POST /cross-module/issues/{id}/resolve
GET /cross-module/data-ownership
PATCH /cross-module/data-ownership/{id}
GET /cross-module/process-boundaries
PATCH /cross-module/process-boundaries/{id}
GET /cross-module/blockers
POST /cross-module/gate-check

36.5 代表的な検出条件

1つのBusinessElementが複数モジュールに依存
DomainGuideが他モジュールのデータを参照
FeatureCandidateが複数モジュールにまたがる
OdooSpec候補が他モジュールの正本を侵害
同じデータ項目が複数モジュールで定義されている

36.6 完了条件

CrossModuleIssueを検出できる
Issueに関係モジュールを設定できる
DataOwnershipを登録できる
ProcessBoundaryを登録できる
ResolutionDecisionを登録できる
unresolved blockerを一覧化できる
gate-checkでコード生成可否を判定できる

36.7 確認方法

1. 横断論点検出確認

POST /cross-module/issues/detect を実行
Purchase / MRP / Inventoryなど複数モジュールを含むIssueが作成されること

2. DataOwnership確認

在庫数量、検査結果、請求状態などに正本モジュールを設定できること

3. 解決確認

POST /cross-module/issues/{id}/resolve を実行
status が resolved になること
ResolutionDecisionが紐づくこと

4. Gate確認

POST /cross-module/gate-check を実行
unresolved issueがある場合はコード生成不可になること

36.8 MVP 4でやらないこと

Odooコード生成
実機デプロイ

37. MVP 5：Odoo Spec Graph 指示書

37.1 目的

DomainGuide、Decision、CrossModuleResolutionをもとに、Odooコード生成前の実装仕様Graphを作る。

37.2 実装対象

モデル仕様生成
フィールド仕様生成
View仕様生成
Button仕様生成
SmartButton仕様生成
Menu仕様生成
Security仕様生成
Compute / Onchange / Constraint仕様生成
レビューUI

37.3 主要ノード / テーブル

OdooModelSpec
OdooFieldSpec
OdooViewSpec
OdooTabSpec
OdooButtonSpec
OdooSmartButtonSpec
OdooMenuSpec
OdooActionSpec
OdooSecurityRuleSpec
OdooComputeSpec
OdooOnchangeSpec
OdooConstraintSpec
OdooReportSpec
DomainGuideMappingRule

37.4 API案

POST /odoo/spec/generate
GET /odoo/spec/models
GET /odoo/spec/fields
GET /odoo/spec/views
GET /odoo/spec/security
PATCH /odoo/spec/{id}
POST /odoo/spec/review
POST /odoo/spec/gate-check

37.5 完了条件

OdooModelSpecが生成される
OdooFieldSpecが生成される
OdooViewSpecが生成される
SecuritySpecが生成される
各SpecがDomainGuide / Decision / BusinessElementにトレースできる
review状態を更新できる
gate-checkで未確定Specを検出できる

37.6 確認方法

1. Spec生成確認

POST /odoo/spec/generate を実行
対象モジュールのModelSpec / FieldSpec / ViewSpecが作成されること

2. トレーサビリティ確認

任意のFieldSpecから、元のBusinessElementまたはDomainGuideTopicを辿れること

3. レビュー確認

OdooSpecをreviewed / blocked / approved_for_codegenに変更できること

4. Gate確認

SecuritySpecがないモデルはコード生成不可になること
CrossModuleIssue未解決のSpecはblockedになること

37.7 MVP 5でやらないこと

実コード生成
Odoo反映

38. MVP 6：Code Generation 指示書

38.1 目的

approved_for_codegen のOdooSpecからOdoo addonを生成し、Git差分を作り、Dev環境へ反映できる状態にする。

38.2 実装対象

CodeGenerationUnit生成
manifest.py生成
models/*.py生成
views/*.xml生成
security/ir.model.access.csv生成
reports/*.xml生成
Git差分作成
Dev環境反映

38.3 API案

POST /codegen/odoo
GET /codegen/jobs/{id}
GET /codegen/jobs/{id}/files
GET /codegen/jobs/{id}/diff
POST /codegen/jobs/{id}/approve
POST /codegen/jobs/{id}/commit
POST /deploy/dev

38.4 生成対象

manifest.py
models/init.py
models/*.py
views/*.xml
security/ir.model.access.csv
reports/*.xml
data/*.xml
tests/*.py

38.5 完了条件

approved_for_codegen のSpecだけを対象にできる
addonディレクトリを生成できる
Python/XML/CSVが生成される
Git diffを表示できる
人間承認後にcommitできる
Dev環境へ反映ジョブを起動できる

38.6 確認方法

1. Codegen Gate確認

unresolved CrossModuleIssueがある状態では生成不可になること

2. ファイル生成確認

POST /codegen/odoo を実行
addon構成が生成されること

3. 差分確認

GET /codegen/jobs/{id}/diff を実行
生成差分が表示されること

4. Commit確認

POST /codegen/jobs/{id}/commit を実行
Gitにcommitが作成されること

5. Dev反映確認

POST /deploy/dev を実行
Odoo dev環境にaddonが配置されること

38.7 MVP 6でやらないこと

本番反映
完全自動承認
複雑な帳票完全実装

39. MVP 7：Validation / Impact / Estimate 指示書

39.1 目的

生成コードの実機検証、変更影響範囲分析、テストケース生成、見積・提案資料生成を行う。

39.2 実装対象

実機検証
モジュールインストール確認
View表示確認
メニュー確認
権限確認
ボタン実行確認
影響範囲分析
テストケース生成
見積・提案資料生成
顧客向け説明資料生成

39.3 API案

Validation API

POST /validation/run
GET /validation/jobs/{id}
GET /validation/jobs/{id}/logs
GET /validation/jobs/{id}/results

Impact API

POST /impact/analyze
GET /impact/{id}

Test API

POST /tests/generate
GET /tests
GET /tests/{id}

Estimate API

POST /estimate/generate
GET /estimate/{id}

Proposal API

POST /proposal/generate
GET /proposal/{id}

39.4 Validation確認項目

addon install成功
server logにERRORがない
View inheritanceエラーがない
メニューが表示される
権限エラーがない
ボタンが実行できる
テストデータで画面が開く

39.5 Impact Analysis確認項目

変更対象ノード
影響BusinessElement
影響DomainGuide
影響OdooSpec
影響CodeGenerationUnit
再レビュー対象
再生成対象
再質問対象

39.6 Test生成対象

Unit test
UI smoke test
Security test
Data creation test
Button action test
Report generation test

39.7 Estimate算出材料

新規モデル数
標準拡張モデル数
フィールド数
View数
帳票数
ボタン数
SecurityRule数
DomainGuide連携数
CrossModuleIssue数
未確定質問数

39.8 完了条件

実機検証ジョブが動く
検証結果が保存される
変更影響範囲が出る
テストケースが生成される
概算見積が生成される
顧客向け説明資料が生成される

39.9 確認方法

1. Validation確認

POST /validation/run を実行
Odoo dev環境でaddon installが成功すること
結果ログが取得できること

2. Impact確認

任意のDomainGuideまたはFieldSpecを変更
POST /impact/analyze を実行
影響Spec / CodeUnit / Questionが表示されること

3. Test確認

POST /tests/generate を実行
OdooSpecに対応するテストケースが作成されること

4. Estimate確認

POST /estimate/generate を実行
モデル数、フィールド数、View数などを元に概算が作成されること

5. Proposal確認

POST /proposal/generate を実行
標準対応範囲、カスタム範囲、保留事項、見積根拠が出力されること

40. MVP全体の進行条件

各MVPは前段の成果物を前提とする。

MVP	前提
MVP 1	project と document が登録可能
MVP 2	BusinessElement / Question / Answer が存在
MVP 3	DomainGuide / ContextPack が存在
MVP 4	複数ModuleMapping / DomainGuide が存在
MVP 5	CrossModuleIssueが検出・解決可能
MVP 6	OdooSpecがapproved_for_codegen
MVP 7	生成済みaddonとDev環境が存在

41. フェーズ別開発時の注意

MVP 1の注意

抽出精度を最初から完璧にしない。レビュー・修正できるUIを優先する。

MVP 2の注意

Neo4jを正本にしすぎず、PostgreSQL側にも一覧・状態を持つ。

MVP 3の注意

AIおすすめ機能は、必ず根拠DomainGuide / BusinessRule / Decisionにリンクする。

MVP 4の注意

横断論点を無理に自動解決しない。AIは解決案を提示し、人間が承認する。

MVP 5の注意

OdooSpecはコードではなく中間仕様。人間レビューを必ず挟む。

MVP 6の注意

コード生成はapproved_for_codegenだけに限定する。未解決Issueがある場合は止める。

MVP 7の注意

実機検証・影響範囲分析・テストケース生成をセットで扱う。コード生成だけで完了扱いにしない。1. 目的

目的は、コンサルタントや業務担当者のヒアリング量を減らし、要件定義からOdoo実装までの後戻りを最小化すること。

2. 基本思想

2.1 LLMに記憶させない

API化すると、チャットのようにLLMが過去文脈を自然に覚えている前提は使えない。

そのため、記憶の正本はLLMではなく、以下に分ける。

PostgreSQL：状態管理、一覧、CRUD、レビュー、ジョブ、監査ログ
Neo4j：業務要素、関係性、質問、回答、Decision、DomainGuide、Odoo仕様Graph
ChromaDB：設計書本文、DomainGuide本文、Odoo標準知識、過去案件ナレッジの検索
Git：生成コード、差分、レビュー履歴

LLMは、毎回Context Packを受け取り、必要な情報だけを読んで処理する。

2.2 Graphを正本にする

本システムでは、チャット回答ではなくGraphを業務理解の正本とする。

追跡すべきこと：

なぜこの業務要素があるのか
どの資料に基づくのか
どの質問回答で確定したのか
どのDomainGuideに基づくのか
どのOdooモデル・フィールド・Viewに変換されたのか
どのコードファイルを生成するのか

2.3 いきなりコード生成しない

必ず以下の順序を踏む。

資料解析
業務要素抽出
モジュール分類
DomainGuide生成
新規機能オーダー / AIおすすめ機能
横断論点解決
Odoo実装仕様Graph
人間レビュー
コード生成
Dev環境反映・検証

3. 全体レイヤー構成

最終構成は以下の通り。

Document Layer
Business Element Extraction Layer
Module Mapping Layer
Module DomainGuide Layer
Feature Order / Recommendation Layer
Cross-Module Resolution Layer
Integrated Odoo Implementation Spec Layer
Code Generation Layer
Deployment & Validation Layer
Operation Feedback Layer
Test & Validation Design Layer
Estimate / Proposal Layer
Audit / Explanation Layer
Impact Analysis Layer
Odoo Standard Knowledge Base Layer

4. Layer 1：Document Layer

役割

既存資料を取り込む。

対象：

Excel設計書
PDF設計書
帳票レイアウト
画面仕様
イベント仕様
DataSource
既存SQL
既存業務フロー
既存Excel運用資料

機能

ファイルアップロード
シート / ページ / セクション分解
表・帳票・画面項目抽出
元資料とのリンク保持
原文チャンク化
ChromaDBへの登録

主な保存先

PostgreSQL：documents, document_sections, parse_jobs
ChromaDB：document chunks
Neo4j：SourceDocument

5. Layer 2：Business Element Extraction Layer

役割

資料から業務要素を抽出する。

抽出対象：

画面
処理
帳票
ラベル
イベント
DataSource
チェック処理
マスタ
一覧
バッチ

出力例

発注書
原料・資材発注一覧
原材料発注量予実チェック
HT入荷
購入検査記録
MTX_MX原料・資材管理状況

主ノード

BusinessElement
SourceDocument

6. Layer 3：Module Mapping Layer

役割

BusinessElementをOdoo/ERPモジュールに分類する。

対象モジュール：

Purchase / 購買
Inventory / 在庫
Receipt / 入荷
Quality / 検査
Manufacturing / 製造
Sales / 販売
Accounting / 会計
Organization / 組織・権限
Barcode / HT・作業ログ
Reporting / 帳票・分析

重要方針

複数モジュールにまたがるものは、無理に1つへ確定しない。

例：

発注量予実チェック → Purchaseに属するが、MRP / Inventoryに依存
検収基準請求 → Purchase / Quality / Accountingに依存
HT作業者取得 → Inventory / Receipt / Delivery / Organizationに依存

横断するものはCrossModuleIssue候補にする。

7. Layer 4：Module DomainGuide Layer

役割

モジュール別の業務ルール・禁止ルール・判断条件を作る。

購買例：

RFQは基本使わず直接発注中心
価格協定を正式単価マスタとして扱う
重要品目は発注量予実チェック必須
差異が大きい場合は責任者承認

主ノード

DomainGuideTopic
BusinessRule
Question
Answer
Decision

8. Layer 5：Feature Order / Recommendation Layer

役割

既存資料にはない新規追加機能を受け付け、AIが追加機能を提案し、質問化し、Graphへ焼き込む。

必要性

既存資料解析だけでは「今ある業務をどう移すか」に留まる。

実際には以下が必要になる。

Odoo化するなら追加したい機能
業務効率化のために提案したい機能
Graph / DomainGuideがあるから実現できる機能
旧画面を持ち込まない代替機能

主ノード

FeatureOrder
FeatureRecommendation
FeatureCandidate
FeatureQuestion
FeatureDecision
FeaturePriority
FeatureImpact
FeatureScope
FeatureStatus

購買におけるおすすめ機能例

価格協定期限切れアラート
発注量差異ダッシュボード
重要品目の承認強化
単価手動変更レポート
仕入先別納期遅延分析
MTX_MX代替ダッシュボード

状態遷移

requested
recommended
candidate
question_generated
answered
approved
rejected
pending_cross_module
resolved
ready_for_odoo_spec
mapped_to_odoo_spec
generated

9. Layer 6：Cross-Module Resolution Layer

役割

モジュール別に解決できない論点を集約し、全体最適で解決する。

主ノード

CrossModuleIssue
DataOwnership
ProcessBoundary
IntegrationPoint
ResolutionDecision
PendingDependency
Conflict
CodeGenerationBlocker

代表論点

論点	関係モジュール	解決すべきこと
発注量予実チェック	Purchase / MRP / Inventory	予定・実績の正本
入荷数量差異	Purchase / Inventory	差異確定の責務
検収基準請求	Purchase / Quality / Accounting	検査結果と請求可否
価格協定と補充	Purchase / Inventory	価格・補充・発注判断の関係
重要品目	Product / Purchase / Quality / MRP	重要品目定義の正本
毒劇物証跡	Purchase / Quality / Inventory / Accounting	証跡未完了時に止める処理
HT作業ログ	Inventory / Receipt / Delivery / Organization	作業者・端末・操作ログの正本

コード生成条件

CrossModuleIssue.status = resolved
DataOwnership.status = confirmed
ProcessBoundary.status = confirmed
CodeGenerationBlocker = 0

10. Layer 7：Integrated Odoo Implementation Spec Layer

役割

横断論点解決後に、Odoo実装仕様を統合する。

対象：

OdooModelSpec
OdooFieldSpec
OdooViewSpec
OdooTabSpec
OdooButtonSpec
OdooSmartButtonSpec
OdooMenuSpec
OdooActionSpec
OdooSecurityRuleSpec
OdooComputeSpec
OdooOnchangeSpec
OdooConstraintSpec
OdooReportSpec
DomainGuideMappingRule

重要方針

モジュール別仕様を足し合わせるだけではなく、Cross-Module Resolution Layerを通す。

例：

予定数量の正本はMRP
Purchaseにはチェック結果だけ表示
Inventoryが入荷実績の正本
Qualityが検査結果の正本

11. Layer 8：Code Generation Layer

役割

Integrated Odoo Spec GraphからOdoo addonコードを生成する。

生成対象：

manifest.py
models/*.py
views/*.xml
security/ir.model.access.csv
security/*.xml
reports/*.xml
data/*.xml
wizard/*.py
tests/*.py

Code Generation Gate

以下を満たす必要がある。

未解決CrossModuleIssueがない
DataOwnershipが確定
DomainGuideがconfirmed
OdooSpecがreviewed / approved_for_codegen
SecuritySpecが存在
TestScenarioが存在
生成差分がレビュー済み

12. Layer 9：Deployment & Validation Layer

役割

生成コードをDev環境に反映し、実機検証する。

機能：

Gitブランチ作成
Odoo addon生成
Docker / Odoo dev環境へ反映
モジュールインストール
View表示確認
メニュー確認
ボタン実行確認
権限確認
ログ確認

13. Layer 10：Operation Feedback & Learning Loop Layer

役割

このLayerは、本システムを「作れば作るほど賢くなるERP実装知能基盤」にするための中核である。

基本方針

次案件では、それらをContext Packとして再構成し、AIの判断材料として使う。

入力

生成コード
Git diff
Odoo install result
Validation result
Test result
Bug report
User feedback
Consultant correction
Customer answer
Operation issue
Review rejection / approval
Manual code fix
Deployment log

出力

ExceptionPattern
QuestionEffectiveness
DomainGuideImprovement
OdooSpecCorrection
CodePattern
BugPattern
FixPattern
ValidationResult
RecommendationPattern
ReusablePattern

蓄積する知識

1. 例外パターン

業界・国・商習慣・業務慣行に由来する例外を蓄積する。

例：

日本の化学メーカー特有の毒劇物証跡
日本型締め請求
商社経由の仕入先・メーカー分離
オーストラリア税制対応
検収基準請求
分納・過入荷・入荷差異
製造消費と在庫計上のズレ

2. 質問の最適化

質問自体を資産化する。

各質問について以下を記録する。

その質問で不整合が解消したか
CrossModuleIssueが解決したか
DomainGuideが確定したか
OdooSpecが確定したか
不要だったか
順番が適切だったか

質問は単なるヒアリング項目ではなく、要件確定のための最短経路として改善される。

3. コード変換パターン

DomainGuideからOdooSpec、OdooSpecからコードへの変換結果を蓄積する。

記録するもの：

どのDomainGuideから
どのOdooSpecが生成され
どのCodeUnitが生成され
どのテストに通り
どのバグが出て
どう修正されたか

これにより、次回コード生成時に過去の失敗を回避できる。

Reusable Pattern Graph

顧客固有のProject Graphとは別に、匿名化・抽象化された再利用可能な知識Graphを作る。

Project Graph

顧客固有情報を含む。

顧客固有の品目名
顧客固有の帳票名
顧客固有の組織名
顧客固有の業務名
案件内の質問回答

Reusable Pattern Graph

次案件に再利用可能な抽象パターンを保持する。

業界パターン
国別ローカライズパターン
業務例外パターン
質問最適化パターン
DomainGuide改善パターン
OdooSpec設計パターン
CodePattern
BugPattern
FixPattern

例：

顧客Aの毒劇物譲渡証管理
  ↓ 匿名化・抽象化
化学メーカー向け毒劇物証跡管理パターン

主ノード

LearningEvent
OperationFeedback
ExceptionPattern
IndustryPattern
CountryRule
LocalizationRule
BusinessCustomPattern
QuestionEffectiveness
DomainGuideImprovement
SpecCorrection
CodePattern
BugPattern
FixPattern
ValidationResult
RegressionTest
RecommendationPattern
ReusablePattern

主な関係

OBSERVED_IN_PROJECT
DERIVED_FROM_BUG
FIXED_BY
IMPROVES_DOMAIN_GUIDE
IMPROVES_QUESTION
IMPROVES_CODE_PATTERN
AVOIDS_BUG
REUSED_IN_PROJECT
SIMILAR_TO_PATTERN
PROMOTED_TO_REUSABLE_PATTERN
ANONYMIZED_FROM

API案

Feedback API

POST /feedback/operation
POST /feedback/bug
POST /feedback/spec-correction
POST /feedback/domain-guide-correction
POST /feedback/question-effectiveness
POST /feedback/code-fix
POST /feedback/review-result

Learning API

POST /learning/extract-patterns
GET /learning/patterns
GET /learning/patterns/{id}
GET /learning/patterns/similar
POST /learning/promote-pattern
POST /learning/anonymize

Reuse API

POST /reuse/suggest-patterns
POST /reuse/apply-pattern
GET /reuse/project/{project_id}/matched-patterns

KPI

質問系KPI

平均質問数
未回答質問率
質問1件あたりのDecision確定率
質問1件あたりのCrossModuleIssue解決率
再質問率
不要質問率

設計系KPI

DomainGuide初回採用率
DomainGuide修正率
OdooSpec修正率
CrossModuleIssue解決時間
Specレビュー差戻し率

コード系KPI

初回インストール成功率
生成コードの手修正率
テスト通過率
再生成回数
同種バグ再発率
Validation失敗率

提案系KPI

AIおすすめ機能採用率
FeatureRecommendation採用率
提案からOdooSpec化までの時間
提案却下率
提案による追加売上・工数削減効果

重要な注意点

1. 顧客データをそのまま再利用しない

Project Graphには顧客固有情報が含まれるため、Reusable Pattern Graphへ昇格する際は必ず匿名化・抽象化する。

2. 成功パターンと失敗パターンを分ける

以下を区別する。

採用された設計
却下された設計
バグを出した設計
修正後に成功した設計
再利用してよい設計

3. AI提案には根拠を必須にする

FeatureRecommendation、Question、OdooSpec、CodePatternは、必ず根拠ノードを持つ。

例：

過去5案件で採用された
過去3案件で不整合を解消した質問である
Odoo 18で検証済みのコードパターンである
同種バグを過去に回避したFixPatternである

完了条件

実機検証結果を保存できる
バグと修正内容をGraphに登録できる
Review結果を蓄積できる
QuestionEffectivenessを記録できる
ReusablePatternへ昇格できる
次案件のContext Packに過去Patternを注入できる

14. Layer 11：Test & Validation Design Layer

役割

OdooSpecからテストケースを自動生成する。

対象：

Python unit test
UI smoke test
権限テスト
データ投入テスト
ボタン実行テスト
帳票出力テスト

例：購買

重要品目で差異がある場合、承認が必要になるか
価格協定と異なる単価の場合、理由入力が必要か
発注量チェック未実行時に発注確定できるか

15. Layer 12：Estimate / Proposal Layer

役割

OdooSpecから見積・提案資料を生成する。

算出材料：

新規モデル数
標準拡張モデル数
フィールド数
View数
帳票数
ボタン数
権限数
DomainGuide連携数
CrossModuleIssue数
未確定質問数

出力：

概算工数
実装スコープ
カスタム範囲
標準対応範囲
リスク
保留事項

16. Layer 13：Audit / Explanation Layer

役割

顧客説明・監査・社内レビュー向けに、判断根拠を出力する。

回答できる問い：

なぜこのカスタムが必要なのか
なぜOdoo標準で足りないのか
なぜ旧画面を持ち込まないのか
誰の回答で確定したのか
どの資料に根拠があるのか
どのDomainGuideに基づくのか

17. Layer 14：Impact Analysis Layer

役割

変更差分の影響範囲を分析する。

例：価格協定ルールを変更した場合

影響対象：

product.supplierinfo
purchase.order.line
単価変更constraint
発注書帳票
価格協定期限切れアラート
価格関連FeatureRecommendation

主機能

変更影響ノード抽出
再レビュー対象抽出
再生成が必要なコードファイル抽出
再質問が必要な論点抽出

18. Layer 15：Odoo Standard Knowledge Base Layer

役割

Odoo標準のモデル・フィールド・View・フローを知識ベース化する。

対象：

purchase.order
purchase.order.line
stock.picking
stock.move
account.move
mrp.production
quality.check
res.partner
product.template
product.supplierinfo

用途：

Odoo標準で対応できるか判定
カスタム要否判定
標準との差分抽出
View継承先の候補提示
モデル選定支援

19. Context Pack / Memory Snapshot

課題

API化すると、LLMは会話履歴を覚えていない。

解決策

Layer4までの結果を永続化し、毎回必要な文脈だけContext PackとしてLLMに渡す。

主要コンポーネント

ProjectMemorySnapshot
ContextPackBuilder
FeatureRecommendationEngine

Context Packに含めるもの

project_id
module
confirmed_rules
business_elements
pending_cross_module_issues
do_not_migrate_as_is
odoo_fit_summary
source_nodes

20. Agent構成

本システムには、レイヤー完了判定と次工程起動を行うエージェント群が必要。

主要Agent

Project Orchestrator Agent
Layer Gate Agent
Quality Review Agent
Question Agent
Feature Recommendation Agent
Cross-Module Resolver Agent
Spec Generation Agent
Codegen Gate Agent
Impact Analysis Agent
Validation / Test Agent

21. Project Orchestrator Agent

役割

現在のLayer確認
Gate条件判定
次Layer起動
ReviewTask作成
Blocker作成
NextAction提示

自動進行してよいもの

Document parsing
BusinessElement extraction draft
Module mapping draft
Question draft generation
Graph draft write
ContextPack generation

人間承認が必要なもの

DomainGuide confirmed
CrossModule Resolution confirmed
OdooSpec approved_for_codegen
Code generation approve
Deployment approve

22. 状態管理

Layer状態

not_started
running
generated
review_required
blocked
approved
completed

BusinessElement状態

extracted
classified
mapped_to_module
question_generated
answered
graph_inferred
graph_confirmed

CrossModuleIssue状態

detected
pending
in_review
resolved
blocked
rejected

DomainGuide状態

draft
assumed
confirmed
superseded

OdooSpec状態

draft
review_required
reviewed
blocked_by_cross_module
approved_for_codegen
generated
deployed
tested

23. API構成

Document API

POST /documents/upload
POST /documents/{id}/parse
GET /documents/{id}/sections
GET /documents/{id}/elements

Business Element API

GET /elements
PATCH /elements/{id}
POST /elements/{id}/classify
POST /elements/{id}/map-module

Question API

POST /questions/generate
GET /questions
PATCH /questions/{id}/answer
POST /questions/{id}/confirm

DomainGuide API

POST /domainguide/generate
GET /domainguide/topics
PATCH /domainguide/topics/{id}
POST /domainguide/topics/{id}/confirm

Feature API

POST /features/order
POST /features/recommend
GET /features/recommendations
POST /features/{id}/promote
PATCH /features/{id}

Cross-Module API

GET /cross-module/issues
POST /cross-module/issues/detect
PATCH /cross-module/issues/{id}
POST /cross-module/issues/{id}/resolve
GET /cross-module/data-ownership
PATCH /cross-module/data-ownership/{id}
GET /cross-module/process-boundaries
POST /cross-module/gate-check

Odoo Spec API

POST /odoo/spec/generate
GET /odoo/spec/models
GET /odoo/spec/fields
GET /odoo/spec/views
PATCH /odoo/spec/{id}
POST /odoo/spec/review

Code Generation API

POST /codegen/odoo
GET /codegen/jobs/{id}
GET /codegen/jobs/{id}/diff
POST /codegen/jobs/{id}/approve
POST /codegen/jobs/{id}/commit

Deployment API

POST /deploy/dev
POST /deploy/test
GET /deploy/jobs/{id}
GET /deploy/jobs/{id}/logs

Agent API

POST /agents/orchestrator/run
POST /agents/layer-gate/check
POST /agents/question/generate
POST /agents/feature/recommend
POST /agents/cross-module/detect
POST /agents/spec/generate
POST /agents/codegen-gate/check
POST /agents/impact/analyze
POST /agents/validation/run

24. UI構成

1. Project Dashboard

現在Layer
モジュール別進捗
未解決Issue
Review待ち
NextAction
Codegen可否

2. Document Review UI

資料一覧
抽出状態
抽出要素
原文プレビュー

3. Module Mapping UI

業務要素
推定モジュール
confidence
別モジュール候補
保留理由

4. Question UI

質問
回答
回答者
確定度
Graph反映状態

5. DomainGuide UI

ルール本文
禁止ルール
参照データ
対象モジュール
confidence
confirmed / draft

6. Feature Order UI

新規機能オーダー
AIおすすめ機能
採用 / 保留 / 却下
質問生成
Graph反映

7. Cross-Module Resolution UI

横断論点一覧
関係モジュール
未解決理由
推奨解決案
データ正本
プロセス境界
コード生成ブロック有無

8. Odoo Spec Review UI

モデル
フィールド
View
タブ
ボタン
スマートボタン
メニュー
権限
compute
constraint
帳票

9. Codegen Review UI

生成ファイル一覧
差分
影響範囲
未解決ブロッカー
生成可否

10. Impact Analysis UI

変更対象
影響ノード
再レビュー対象
再生成対象ファイル
再質問対象

25. データストア設計

PostgreSQL

主に一覧・状態管理・CRUD。

候補テーブル：

projects
project_layers
documents
document_sections
business_elements
questions
answers
domain_guides
feature_orders
feature_recommendations
cross_module_issues
odoo_model_specs
odoo_field_specs
odoo_view_specs
codegen_jobs
review_tasks
blockers
audit_logs
project_memory_snapshots
context_packs

Neo4j

主に関係性・影響範囲・設計根拠。

主要ノード：

BusinessElement
OdooModule
DomainGuideTopic
BusinessRule
Question
Answer
Decision
FeatureOrder
FeatureRecommendation
CrossModuleIssue
DataOwnership
ProcessBoundary
OdooModelSpec
OdooFieldSpec
OdooViewSpec
CodeGenerationUnit
LayerRun
GateCheck
Blocker
NextAction

ChromaDB

検索・類似比較。

対象：

設計書本文
帳票説明
画面仕様
DomainGuide本文
Odoo標準知識
過去案件ナレッジ
ProjectMemorySnapshot

Git

コード・差分・レビュー履歴。

対象：

generated addons
diff
review comments
approved versions
deployment tags

26. MVP開発順序

MVP 1：Document → BusinessElement → Question

資料アップロード
要素抽出
モジュール分類
質問生成
回答登録

MVP 2：Graph / DomainGuide

Neo4j仮焼き
DomainGuide生成
質問回答反映
ContextPack生成

MVP 3：Feature Order / Recommendation

新規機能オーダー
AIおすすめ機能提案
FeatureCandidate化
質問生成

MVP 4：Cross-Module Resolution

横断論点検出
データ正本管理
プロセス境界管理
コード生成ブロッカー表示

MVP 5：Odoo Spec Graph

モデル仕様生成
フィールド仕様生成
View仕様生成
レビューUI

MVP 6：Code Generation

Odoo addon生成
Git差分
Dev環境反映

MVP 7：Validation / Impact / Estimate

実機検証
影響範囲分析
テストケース生成
見積・提案資料生成

27. 今回の購買モジュールで得た設計パターン

購買モジュールでは、以下まで確認済みの想定。

初期カスタマイズ候補

purchase.order 拡張
purchase.order.line 拡張
product.template 拡張
product.supplierinfo 拡張
purchase.quantity.check
purchase.quantity.check.line

主目的

発注量予実チェック
価格協定補足管理
重要品目・差異閾値管理
発注書上の警告・承認状態表示
チェック履歴保存

保留したもの

輸入レポート
原料・資材発注一覧帳票
MTX_MX代替画面
発注判断ルール管理画面
質問回答履歴画面
本格DomainGuide API連携

CrossModuleIssueへ上げるもの

発注量予実チェック：Purchase / MRP / Inventory
入荷数量差異：Purchase / Inventory
検収基準請求：Purchase / Quality / Accounting
価格協定と補充：Purchase / Inventory
重要品目：Product / Purchase / Quality / MRP

28. 最終的な開発方針

本システムは、単なるOdooコード生成ツールではない。

目指すものは以下。

AIが既存資料を読む
AIが業務要素を抽出する
AIがOdoo標準との差分を分類する
AIが不明点だけ質問にする
回答をGraphに焼く
DomainGuideとして判断ルールを残す
横断論点を上位層で解決する
新規機能オーダーやAIおすすめ機能もGraphに焼く
Odoo実装仕様Graphへ変換する
人間がレビューする
コード生成する
実機反映・テストする
運用後の改善をまたFeatureOrderへ戻す

この循環により、コンサルタントや業務担当者のヒアリング量を減らし、設計根拠を残し、後戻りの少ないOdoo開発を実現する。

29. 最重要コンポーネント一覧

ContextPackBuilder
ProjectMemorySnapshot
FeatureRecommendationEngine
Project Orchestrator Agent
Layer Gate Agent
Question Agent
Cross-Module Resolver Agent
Spec Generation Agent
Codegen Gate Agent
Impact Analysis Agent
Odoo Standard Knowledge Base
Validation / Test Agent

30. 開発時の優先順位

最初に作るべきもの：

Project / Layer / Status管理
Document upload / parse
BusinessElement抽出
Module Mapping
Question生成・回答登録
Neo4j Graph焼き込み
DomainGuide生成
ContextPackBuilder
Feature Recommendation
CrossModuleIssue検出
OdooSpec生成
Codegen Gate
Odoo addon生成

31. 結論

このシステムは、以下の5つを一体化する開発基盤である。

要件定義支援
業務Graph構築
DomainGuide管理
Odoo実装仕様生成
Odooコード生成・反映

中核は、GraphとDomainGuideを正本にすること。

LLMは記憶装置ではなく、DB/Graph/Chromaから構成されたContext Packをもとに、抽出・提案・質問・仕様生成・コード生成を行う処理エンジンとして使う。

この構成を前提に開発を進める。

32. MVPフェーズ別開発指示書

以下の順番で開発する。

MVP 1：Document → BusinessElement → Question
MVP 2：Graph / DomainGuide
MVP 3：Feature Order / Recommendation
MVP 4：Cross-Module Resolution
MVP 5：Odoo Spec Graph
MVP 6：Code Generation
MVP 7：Validation / Impact / Estimate

33. MVP 1：Document → BusinessElement → Question 指示書

33.1 目的

このフェーズでは、Graphやコード生成には入らない。まず、資料から業務要素と質問を作ることを目的とする。

33.2 実装対象

資料アップロード
資料台帳作成
ファイル / シート / セクション分解
BusinessElement抽出
Odooモジュール分類
質問生成
回答登録
一覧・レビューUI

33.3 対象データ

Excel
PDF
Word
CSV
画像付き資料は一旦メタ情報のみ、OCRは後続でも可

33.4 主要テーブル案

projects
documents
document_sections
business_elements
module_mappings
questions
answers
review_tasks
audit_logs

33.5 API案

Document API

POST /documents/upload
GET /documents
GET /documents/{document_id}
POST /documents/{document_id}/parse
GET /documents/{document_id}/sections

BusinessElement API

GET /business-elements
GET /business-elements/{id}
PATCH /business-elements/{id}
POST /business-elements/extract
POST /business-elements/{id}/classify

Question API

POST /questions/generate
GET /questions
GET /questions/{id}
PATCH /questions/{id}/answer
POST /questions/{id}/confirm

33.6 BusinessElementの最低項目

id
project_id
document_id
section_id
name
element_type
summary
source_text
source_path
module_candidate
confidence
status
created_at
updated_at

33.7 Questionの最低項目

id
project_id
business_element_id
question_text
question_type
ask_to_role
priority
status
answer_text
answer_confidence
created_at
updated_at

33.8 UI要件

資料一覧画面

ファイル名
種別
アップロード日時
解析状態
抽出要素数
質問数

業務要素一覧画面

要素名
種別
概要
推定モジュール
confidence
元資料
質問有無
レビュー状態

質問一覧画面

質問ID
対象要素
質問
質問先
優先度
回答
確定度
状態

33.9 完了条件

資料をアップロードできる
資料台帳に登録される
document_sections が作成される
business_elements が抽出される
各BusinessElementにmodule_candidateが入る
confidenceが保存される
questions が生成される
回答を登録できる
回答状態が更新される

33.10 確認方法

1. 資料アップロード確認

任意のExcel/PDFをアップロード
documents に1件以上登録されること
ファイルパスまたはストレージキーが保存されること

2. セクション分解確認

POST /documents/{id}/parse を実行
document_sections にシート名・ページ名・セクション名が登録されること

3. 業務要素抽出確認

POST /business-elements/extract を実行
business_elements に画面、帳票、処理、イベントなどが登録されること
source_document / source_section を辿れること

4. モジュール分類確認

各BusinessElementに Purchase / Inventory / Manufacturing / Accounting 等の候補が入ること
Unknownが一定割合以下であること

5. 質問生成確認

POST /questions/generate を実行
confidenceが低い要素、分類不能要素、カスタム候補要素に質問が作成されること

6. 回答登録確認

PATCH /questions/{id}/answer を実行
answer_text、answer_confidence、status が更新されること

33.11 MVP 1でやらないこと

Neo4j焼き込み
DomainGuide生成
CrossModuleIssue解決
OdooSpec生成
コード生成

34. MVP 2：Graph / DomainGuide 指示書

34.1 目的

MVP 1で抽出したBusinessElement、Question、Answer、DecisionをNeo4jに仮焼きし、モジュール別DomainGuideを生成し、ContextPackを作れる状態にする。

34.2 実装対象

Neo4j仮焼き
BusinessElement Graph化
Question / Answer / Decision Graph化
DomainGuideTopic生成
BusinessRule生成
DomainGuide本文生成
質問回答反映
ContextPack生成

34.3 Neo4j主要ノード

Project
SourceDocument
BusinessElement
OdooModule
OdooFlowStep
Question
Answer
Decision
DomainGuideTopic
BusinessRule
ActorRole

34.4 主要リレーション

DERIVED_FROM
BELONGS_TO_MODULE
BELONGS_TO_FLOW
HAS_UNKNOWN
ASK_TO
ANSWERED_BY
CONFIRMED_AS
CONFIRMS_TOPIC
HAS_RULE
DERIVED_FROM_DECISION

34.5 API案

Graph API

POST /graph/sync
GET /graph/business-elements/{id}
GET /graph/questions/{id}
GET /graph/impact/{node_id}

DomainGuide API

POST /domainguide/generate
GET /domainguide/topics
GET /domainguide/topics/{id}
PATCH /domainguide/topics/{id}
POST /domainguide/topics/{id}/confirm

Context API

POST /context-pack/build
GET /context-pack/{id}

34.6 ContextPackに含めるもの

project_id
target_module
business_elements
confirmed_decisions
assumed_decisions
questions_open
domain_guides
business_rules
pending_items
source_nodes

34.7 完了条件

BusinessElementがNeo4jに同期される
Question / Answer / DecisionがNeo4jに同期される
DomainGuideTopicが生成される
BusinessRuleが生成される
DomainGuide本文が生成される
ContextPackが生成できる
ContextPackから根拠ノードを辿れる

34.8 確認方法

1. Graph同期確認

POST /graph/sync を実行
Neo4j上で BusinessElement 件数がPostgreSQLと一致すること

2. 質問回答反映確認

回答済みQuestionが Answer / Decision に接続されていること

3. DomainGuide生成確認

POST /domainguide/generate を実行
DomainGuideTopicとBusinessRuleが作成されること

4. ContextPack確認

POST /context-pack/build を実行
対象モジュールのBusinessElement、Decision、DomainGuideが含まれること
source_nodes が含まれること

34.9 MVP 2でやらないこと

新規機能提案
CrossModuleIssue解決
OdooSpec生成
コード生成

35. MVP 3：Feature Order / Recommendation 指示書

35.1 目的

既存資料にはない新規機能オーダーを登録し、AIがGraph / DomainGuideをもとにおすすめ機能を提案し、FeatureCandidate化し、必要な質問を生成する。

35.2 実装対象

新規機能オーダー登録
AIおすすめ機能生成
FeatureRecommendation保存
FeatureCandidate化
追加機能用質問生成
採用 / 保留 / 却下
Graph焼き込み

35.3 主要ノード / テーブル

FeatureOrder
FeatureRecommendation
FeatureCandidate
FeatureQuestion
FeatureDecision
FeatureImpact
FeaturePriority

35.4 API案

POST /features/order
GET /features/orders
POST /features/recommend
GET /features/recommendations
POST /features/{id}/promote
PATCH /features/{id}/status
POST /features/{id}/questions/generate

35.5 FeatureRecommendationに必要な項目

name
description
reason
priority
scope
target_module
cross_module_flag
based_on_domain_guides
based_on_business_rules
based_on_decisions
required_questions
status

35.6 完了条件

新規FeatureOrderを登録できる
ContextPackをもとにFeatureRecommendationを生成できる
根拠DomainGuide / BusinessRule / Decisionにリンクされる
採用したRecommendationをFeatureCandidate化できる
Candidateに対して質問を生成できる
横断が必要なCandidateはCrossModuleIssue候補に送れる

35.7 確認方法

1. 新規機能オーダー確認

POST /features/order を実行
FeatureOrderが保存されること

2. おすすめ機能確認

POST /features/recommend を実行
FeatureRecommendationが複数件生成されること
各Recommendationにreasonとbased_onがあること

3. Candidate化確認

POST /features/{id}/promote を実行
FeatureCandidateが作成されること

4. 質問生成確認

POST /features/{id}/questions/generate を実行
FeatureCandidateに紐づく質問が作成されること

35.8 MVP 3でやらないこと

OdooSpec化
コード生成
実装見積

36. MVP 4：Cross-Module Resolution 指示書

36.1 目的

複数モジュールにまたがる論点を検出し、データの正本、プロセス境界、統合判断、コード生成ブロッカーを管理する。

36.2 実装対象

横断論点検出
CrossModuleIssue登録
関係モジュール設定
DataOwnership管理
ProcessBoundary管理
ResolutionDecision登録
CodeGenerationBlocker表示

36.3 主要ノード / テーブル

CrossModuleIssue
OdooModule
DataOwnership
ProcessBoundary
IntegrationPoint
ResolutionDecision
CodeGenerationBlocker

36.4 API案

POST /cross-module/issues/detect
GET /cross-module/issues
GET /cross-module/issues/{id}
PATCH /cross-module/issues/{id}
POST /cross-module/issues/{id}/resolve
GET /cross-module/data-ownership
PATCH /cross-module/data-ownership/{id}
GET /cross-module/process-boundaries
PATCH /cross-module/process-boundaries/{id}
GET /cross-module/blockers
POST /cross-module/gate-check

36.5 代表的な検出条件

1つのBusinessElementが複数モジュールに依存
DomainGuideが他モジュールのデータを参照
FeatureCandidateが複数モジュールにまたがる
OdooSpec候補が他モジュールの正本を侵害
同じデータ項目が複数モジュールで定義されている

36.6 完了条件

CrossModuleIssueを検出できる
Issueに関係モジュールを設定できる
DataOwnershipを登録できる
ProcessBoundaryを登録できる
ResolutionDecisionを登録できる
unresolved blockerを一覧化できる
gate-checkでコード生成可否を判定できる

36.7 確認方法

1. 横断論点検出確認

POST /cross-module/issues/detect を実行
Purchase / MRP / Inventoryなど複数モジュールを含むIssueが作成されること

2. DataOwnership確認

在庫数量、検査結果、請求状態などに正本モジュールを設定できること

3. 解決確認

POST /cross-module/issues/{id}/resolve を実行
status が resolved になること
ResolutionDecisionが紐づくこと

4. Gate確認

POST /cross-module/gate-check を実行
unresolved issueがある場合はコード生成不可になること

36.8 MVP 4でやらないこと

Odooコード生成
実機デプロイ

37. MVP 5：Odoo Spec Graph 指示書

37.1 目的

DomainGuide、Decision、CrossModuleResolutionをもとに、Odooコード生成前の実装仕様Graphを作る。

37.2 実装対象

モデル仕様生成
フィールド仕様生成
View仕様生成
Button仕様生成
SmartButton仕様生成
Menu仕様生成
Security仕様生成
Compute / Onchange / Constraint仕様生成
レビューUI

37.3 主要ノード / テーブル

OdooModelSpec
OdooFieldSpec
OdooViewSpec
OdooTabSpec
OdooButtonSpec
OdooSmartButtonSpec
OdooMenuSpec
OdooActionSpec
OdooSecurityRuleSpec
OdooComputeSpec
OdooOnchangeSpec
OdooConstraintSpec
OdooReportSpec
DomainGuideMappingRule

37.4 API案

POST /odoo/spec/generate
GET /odoo/spec/models
GET /odoo/spec/fields
GET /odoo/spec/views
GET /odoo/spec/security
PATCH /odoo/spec/{id}
POST /odoo/spec/review
POST /odoo/spec/gate-check

37.5 完了条件

OdooModelSpecが生成される
OdooFieldSpecが生成される
OdooViewSpecが生成される
SecuritySpecが生成される
各SpecがDomainGuide / Decision / BusinessElementにトレースできる
review状態を更新できる
gate-checkで未確定Specを検出できる

37.6 確認方法

1. Spec生成確認

POST /odoo/spec/generate を実行
対象モジュールのModelSpec / FieldSpec / ViewSpecが作成されること

2. トレーサビリティ確認

任意のFieldSpecから、元のBusinessElementまたはDomainGuideTopicを辿れること

3. レビュー確認

OdooSpecをreviewed / blocked / approved_for_codegenに変更できること

4. Gate確認

SecuritySpecがないモデルはコード生成不可になること
CrossModuleIssue未解決のSpecはblockedになること

37.7 MVP 5でやらないこと

実コード生成
Odoo反映

38. MVP 6：Code Generation 指示書

38.1 目的

approved_for_codegen のOdooSpecからOdoo addonを生成し、Git差分を作り、Dev環境へ反映できる状態にする。

38.2 実装対象

CodeGenerationUnit生成
manifest.py生成
models/*.py生成
views/*.xml生成
security/ir.model.access.csv生成
reports/*.xml生成
Git差分作成
Dev環境反映

38.3 API案

POST /codegen/odoo
GET /codegen/jobs/{id}
GET /codegen/jobs/{id}/files
GET /codegen/jobs/{id}/diff
POST /codegen/jobs/{id}/approve
POST /codegen/jobs/{id}/commit
POST /deploy/dev

38.4 生成対象

manifest.py
models/init.py
models/*.py
views/*.xml
security/ir.model.access.csv
reports/*.xml
data/*.xml
tests/*.py

38.5 完了条件

approved_for_codegen のSpecだけを対象にできる
addonディレクトリを生成できる
Python/XML/CSVが生成される
Git diffを表示できる
人間承認後にcommitできる
Dev環境へ反映ジョブを起動できる

38.6 確認方法

1. Codegen Gate確認

unresolved CrossModuleIssueがある状態では生成不可になること

2. ファイル生成確認

POST /codegen/odoo を実行
addon構成が生成されること

3. 差分確認

GET /codegen/jobs/{id}/diff を実行
生成差分が表示されること

4. Commit確認

POST /codegen/jobs/{id}/commit を実行
Gitにcommitが作成されること

5. Dev反映確認

POST /deploy/dev を実行
Odoo dev環境にaddonが配置されること

38.7 MVP 6でやらないこと

本番反映
完全自動承認
複雑な帳票完全実装

39. MVP 7：Validation / Impact / Estimate 指示書

39.1 目的

生成コードの実機検証、変更影響範囲分析、テストケース生成、見積・提案資料生成を行う。

39.2 実装対象

実機検証
モジュールインストール確認
View表示確認
メニュー確認
権限確認
ボタン実行確認
影響範囲分析
テストケース生成
見積・提案資料生成
顧客向け説明資料生成

39.3 API案

Validation API

POST /validation/run
GET /validation/jobs/{id}
GET /validation/jobs/{id}/logs
GET /validation/jobs/{id}/results

Impact API

POST /impact/analyze
GET /impact/{id}

Test API

POST /tests/generate
GET /tests
GET /tests/{id}

Estimate API

POST /estimate/generate
GET /estimate/{id}

Proposal API

POST /proposal/generate
GET /proposal/{id}

39.4 Validation確認項目

addon install成功
server logにERRORがない
View inheritanceエラーがない
メニューが表示される
権限エラーがない
ボタンが実行できる
テストデータで画面が開く

39.5 Impact Analysis確認項目

変更対象ノード
影響BusinessElement
影響DomainGuide
影響OdooSpec
影響CodeGenerationUnit
再レビュー対象
再生成対象
再質問対象

39.6 Test生成対象

Unit test
UI smoke test
Security test
Data creation test
Button action test
Report generation test

39.7 Estimate算出材料

新規モデル数
標準拡張モデル数
フィールド数
View数
帳票数
ボタン数
SecurityRule数
DomainGuide連携数
CrossModuleIssue数
未確定質問数

39.8 完了条件

実機検証ジョブが動く
検証結果が保存される
変更影響範囲が出る
テストケースが生成される
概算見積が生成される
顧客向け説明資料が生成される

39.9 確認方法

1. Validation確認

POST /validation/run を実行
Odoo dev環境でaddon installが成功すること
結果ログが取得できること

2. Impact確認

任意のDomainGuideまたはFieldSpecを変更
POST /impact/analyze を実行
影響Spec / CodeUnit / Questionが表示されること

3. Test確認

POST /tests/generate を実行
OdooSpecに対応するテストケースが作成されること

4. Estimate確認

POST /estimate/generate を実行
モデル数、フィールド数、View数などを元に概算が作成されること

5. Proposal確認

POST /proposal/generate を実行
標準対応範囲、カスタム範囲、保留事項、見積根拠が出力されること

40. MVP全体の進行条件

各MVPは前段の成果物を前提とする。

MVP	前提
MVP 1	project と document が登録可能
MVP 2	BusinessElement / Question / Answer が存在
MVP 3	DomainGuide / ContextPack が存在
MVP 4	複数ModuleMapping / DomainGuide が存在
MVP 5	CrossModuleIssueが検出・解決可能
MVP 6	OdooSpecがapproved_for_codegen
MVP 7	生成済みaddonとDev環境が存在

41. フェーズ別開発時の注意

MVP 1の注意

抽出精度を最初から完璧にしない。レビュー・修正できるUIを優先する。

MVP 2の注意

Neo4jを正本にしすぎず、PostgreSQL側にも一覧・状態を持つ。

MVP 3の注意

AIおすすめ機能は、必ず根拠DomainGuide / BusinessRule / Decisionにリンクする。

MVP 4の注意

横断論点を無理に自動解決しない。AIは解決案を提示し、人間が承認する。

MVP 5の注意

OdooSpecはコードではなく中間仕様。人間レビューを必ず挟む。

MVP 6の注意

コード生成はapproved_for_codegenだけに限定する。未解決Issueがある場合は止める。

MVP 7の注意

実機検証・影響範囲分析・テストケース生成をセットで扱う。コード生成だけで完了扱いにしない。