将来構想

位置づけ: 将来構想

概要

本ページは、先行リリース（催事・アイテム・商社）の範囲外に位置づく将来フェーズの構想を扱う。起点は 2026-07-29 の定例会であり、7/22 是正（催事・卸の統合／権限／報告拡張）の実装レビューが完了した場で、「バックオフィス自動化（中間やりとりのAIエージェント化・商社明細スキャン取込）」「太陽光設計AI」「Jクレジット」「CRMのSaaS化（代理店提供）」「商社機能の分社化」がまとめて提示された。実装着手は 12月のCRM完成後と定例会で明示されている。正本は redesign/meeting-log.md を参照する。

構想は3層の積み上げ構造を持つ。

第1層：社内業務の自動化 — バックオフィス自動化・太陽光設計AI・商社明細スキャン取込。自社の業務効率を上げる層。
第2層：代理店へのCRM提供（SaaS化） — 自社向けCRMをパートナー代理店にサービスとして提供する層。
第3層：商社機能の分社化 — 卸業務を独立採算の事業として切り出す層。

価格モデルの channel 軸や商社（卸）モジュールなど、構想を支える土台の一部はすでに先行実装に組み込まれている。構想は着手前の白紙状態ではなく、具体的な布石の上に立っている。

スコープ

本ページで扱う6テーマを一覧化する。

テーマ	概要	起点	依存する先行機能・前提
商社機能の分社化	卸業務の別事業化	7/29定例	商社モジュール（実装済み）＋卸金額・発注管理・決済フロー
CRMのSaaS化（代理店提供）	自社CRMを代理店にサービス提供	7/29定例	`SalesPrice` の channel（商流/代理店）軸（実装済み）とテナント分離設計
バックオフィス自動化	中間やりとりのAIエージェント化・商社明細スキャン取込	7/15・7/29定例	チャット一元化（実装済み、features/chat-collab.md）・商品マスタ（Product.model）・卸金額/発注管理
太陽光設計AI	図面読取→寸法把握→入力の自動化	7/29定例	太陽光工程タスク（実装済み）
Jクレジット	環境価値の創出・売却を収益源化	7/29定例	Household・申込・アイテム（商品マスタ）の蓄積
ValueOSとの棲み分け	Ouver側プロダクトとの責務分界	7/29定例・2026-08-05確認	ValueOS（正本 `github.com/stanaka-blip/valueos`）との差分整理（redesign/valueos-gap.md）

「実装済み」は現行試作（React+TS, lib/crm.ts 等）への反映を指し、本番リリース済みを意味しない。

商社機能の分社化

商社（卸）モジュールは第1弾の先行リリース範囲としてすでに実装済みである。分社化構想は、この卸業務を独立採算で運営できる水準まで育てた延長線上に位置づく。

7/29の新要件（卸金額の管理・発注管理・決済フロー・商社別の管理軸）は、本業CRMの機能拡張であると同時に、分社化後に「別会社としての商社業務」を運営するための必須機能でもある。

分社化にあたってシステムとして検討する論点は次のとおりである。

論点	検討内容
データ所有権の分割	商品マスタ・仕入価格（`netPrice`）の正本をどちらの法人が持つか
法人間取引の表現	受発注・請求を法人間取引としてどう扱うか
権限とテナントの分離	分社後にアクセス境界をどう引くか

分社化は次の3段階で進める。

社内モジュールとして機能を完成させる
会計・責任分界を社内で仮想的に分離する
法人分離する

システムとしては、段階2の時点でテナント分離可能な構造にしておく。分社化の時期・法人形態・既存商社取引の移管方法は経営判断事項であり、本ページの管掌外とする（確認事項参照）。

CRMのSaaS化（代理店への提供）

自社（バリューエコロジー住宅設備事業部）向けに作ったCRMを、パートナー代理店にもサービスとして提供する構想である（7/29定例発）。代理店には無料提供し、アライアンス条件で実質利用を促す一方、自社導入は課金対象とする方向で整理されている。

すでに実装済みの布石は次の2点である。

布石	内容
価格モデルの channel 軸	`SalesPrice` が `productNo × channel（商流/代理店）× price × 反映日` で設計され、`currentSalesPrice` により代理店ごとの現在価格を導出できる。代理店軸は価格の一級概念として最初から存在する
`Deal.channel` のパートナー区分	代理店経由の商談を既存データモデルのまま表現できる

SaaS化にあたって新たに整備する要素は次のとおりである。

マルチテナント分離（データ・権限・監査）
代理店向け課金モデル
代理店側ユーザーのオンボーディング
提供機能のサブセット定義

商社分社とCRM-SaaSは独立に進行できる。両方が成立した場合、分社した商社が代理店網にSaaSと卸を併せて提供する形が最終像となる。

ValueOS との棲み分け

SaaS化・分社化の前提として、Ouver側プロダクト（ValueOS）と本CRMの責務分界を整理する。詳細な差分分析は redesign/valueos-gap.md を正本とし、本節はSaaS化観点（マルチテナント時にどちらを拡張するか）に絞る。

「ValueAuth」という別リポジトリは存在しない。5本柱（案件・受注・請求・入金・タスク）を持つ ValueOS（正本 github.com/stanaka-blip/valueos）が実体である（2026-08-05確認）。

領域	正本を持つ側	ValueOSの役割	本CRMの役割	状態
見積・価格表UI	CRM	実装済みUI設計の参照元	価格データ（PriceBook / Part / SalesPrice / PackageSet / Manufacturer）の正本を保持	方針確定（7/17）
認証・アカウント	ValueOS側	認証・アカウント基盤	SaaS化時のテナント・代理店ユーザー管理の受け持ち範囲	検討中
商品マスタ	CRM	—	Product.model（型番）を主キーとする商品/部材/パッケージマスタを保持	実装済み
商談・活動データ	CRM	—	Deal / Household / 活動ログ / タスクを保持	後続フェーズ
KPI予実	CRM（新設予定）	—	予算・実績・ダッシュボードを新設する	未実装（現行本番DBに予算/評価テーブルなし）

現行CRMは「案件獲得〜見積〜催事（前段）」に強く、ValueOSは「受発注〜請求〜入金（ERP後段）」に強い相補関係にある。SaaS化・分社化を進める場合、この前段/後段の境界がテナント境界の候補となる。

バックオフィス自動化（AIエージェント）

柱1：中間やりとりのAIエージェント化（7/29発）営業・事務・商社間の確認・取次コミュニケーションをAIエージェントに肩代わりさせる構想である。チャット一元化（features/chat-collab.md、Slack通知連携）の実現後、その上に載せる段階構成として進める。詳細機能は features/ai-agent.md に展開する。

柱2：商社明細スキャン→自動取込 商社からの明細書類をスキャンし、発注・仕入データとして自動登録する構想である。第1弾の商品マスタ（Product.model）と卸金額・発注管理が突合先の土台となる。

柱3：業務プロセス自動化の横展開 既存業務プロセスの自動化パターンを参照モデルとして、他業務へ横展開する構想である。

段階導入方針は、いずれも「AIが下書き→人が承認」から開始し、精度実績を見て自動確定範囲を広げる二段構えとする。当面は人の承認を必須とする。SaaS化した際は、これらの自動化が代理店向けの差別化機能となる。

太陽光設計AIによる設計自動化

太陽光の設計作業は「図面読取→寸法把握→システムへの入力」という流れを持ち、対応できる担当者が限られる属人業務になっている。

構想（7/29発）は、図面画像の読取（屋根形状・寸法の抽出）→パネル配置・容量の算出→CRMの太陽光工程タスクへの自動入力、というパイプラインをAIで自動化することである。試作にはタスク（太陽光の工程管理）がすでに存在し、設計AIの出力先となるデータ構造は実装済みである。

導入は次の3段階で進める。

図面から寸法候補を提示する補助ツール
半自動（人が確認して確定）
定型パターンの全自動

図面フォーマットの多様性・読取精度・設計責任の所在（自動設計結果の最終承認者）は、着手前に解決する論点である。

Jクレジット（環境価値の事業化）

太陽光・高効率給湯器など環境貢献度の高い住宅設備の販売実績をもとに、Jクレジット制度による環境価値の創出・売却を新たな収益源とする構想である（7/29発、6テーマの中で最も遠い将来枠）。

制度申請には「どの世帯にいつどの設備を設置したか」の実績データが必要になる。Household・申込・商品マスタ（アイテム）の蓄積がそのまま原資データとなる。設備の型式・容量・設置日・稼働状況など、制度要件から逆算した追加項目が必要になる可能性がある（制度詳細の調査は未着手）。

これは機能開発ではなく、データ蓄積の副産物として狙う事業機会である。後続フェーズのデータモデル設計では、後から取得できなくなる項目がないかを意識する。

前提条件と依存関係

ビジョン全体に共通する前提と依存関係を一覧化する。

前提・依存関係	影響する構想	内容	対応方針
順序依存	全構想	後続フェーズ（顧客・商談CRM、見積・価格、KPI、チャット、データ移行）の完成が全構想の前提	後続フェーズ完成前に将来構想へ着手しない
テナント分離の後付けコスト	SaaS化・分社化	後続フェーズのDB設計を経てから分離すると手戻りが大きい	後続フェーズのDB設計時点でテナント境界を意識する
AI精度と業務責任	設計AI・明細取込	誤りが受注金額や施工に直結する	人の承認を外す判断基準を精度実績を踏まえて先に定義する
既存業務との並行負荷	年末一括移行と構想着手時期	移行作業と構想着手が時期的に競合し得る	移行完了後に構想着手時期を再設定する

確認事項

分社化の時期・法人形態・既存商社取引の移管方法（経営判断待ち）
SaaS課金モデルの詳細（代理店無料提供・自社課金の具体条件）
ValueOS側の認証・アカウント基盤がSaaS化時のテナント管理をどこまで受けるか
Jクレジット制度参入の是非・必要データ項目（制度調査が未着手）
AIエージェント・設計AIにおいて人の承認を外す判断基準の確定時期