TATEKAN Industry OS Vision — ビルメン業界OS構想

Date: 2026-03-10 JST Status: PM Approved — 正式採用 Origin: PM + ChatGPT 会話 → ClaudeCode 調査・考察 → Codex / GeminiCLI レビュー反映済み

1. Executive Summary

TATEKAN は「ビルメンテナンス業界（清掃・設備管理・警備）の業界OS」になりうる。

既存の 3 アプリ（Core / Toriteki / Mitsumori）+ TATEKAN Control の設計が、ビルメン業界の多層下請け構造・人手不足・低利益率という構造的課題を解くためにそのまま活用できる。

TATEKANOS の理念は NOS = AI-native operating system とする。

• AI との chat を主入口にする
• 音声入力を強く活用する
• 最終確認、監査、承認、例外処理のために最小限の structured console を残す
• 従来 ERP の大量入力画面を再現すること自体は目的にしない

さらに NFT ドメインと Dmail（Web3 分散型メール）は、MVP 前提ではなく将来の optional trust layer として段階的に統合することで、従来の Vertical SaaS では到達しにくい「信頼のプラットフォーム」へ発展しうる。

2. ビルメン業界の構造と痛点

2.1 業界の数字

2.2 多層下請け構造

ビルオーナー / PM会社
    │
    ├── 元請けビルメン会社（大手）
    │       │
    │       ├── 清掃（協力会社 A, B, C...）
    │       ├── 設備管理（協力会社 D, E...）
    │       ├── 警備（協力会社 F, G...）
    │       └── 衛生管理（協力会社 H...）
    │
    └── 各層で中間マージンが発生
        → 末端の作業員は最低賃金近辺
        → 元請けも利益率 0.5%

2.3 主要業務

• 清掃管理: 日常清掃、定期清掃、特別清掃（面積×単価×頻度で積算）
• 設備管理: 電気・空調・給排水・エレベーター等の点検・監視・保全
• 警備防災: 常駐警備、巡回警備、防火管理、入退館管理
• 衛生管理: 空気環境測定、水質検査、害虫防除

2.4 核心的な痛点

1. 元請け〜協力会社の情報断絶: FAX/Excel/電話。同一プラットフォームに乗っていない
2. 利益率 0.5%: 物件別の収支が見えず、赤字物件を放置
3. 人手不足 92%: 事務作業に人手を取られ、現場に人が足りない
4. 取適法対応: 発注条件の記録・保管が人手頼り
5. 見積の属人化: 積算ロジックが担当者の頭の中

3. TATEKAN 3アプリのビルメンへの当てはめ

3.1 アプリ×ビルメン業務マッピング

3.2 典型フロー

1. ビルオーナーから年間契約 or スポット依頼
   → Core: 物件（案件）登録 + 契約管理

2. 見積作成（清掃: 面積×単価×頻度、設備: 点検項目×人工）
   → Mitsumori: 積算 + 帳票出力 + 提出

3. 協力会社への発注（清掃A社、警備B社...）
   → Toriteki: 見積依頼 → 回収 → 発注 → 作業完了報告

4. 検収・月次請求
   → Toriteki: 検収 → Core: 請求 + 入金

5. 原価管理（利益率 0.5% の世界で致命的に重要）
   → Core: 物件別損益 = 売上 - Σ(協力会社発注額)

4. NFTドメイン × Dmail の将来統合

4.1 NFTドメインとは

• ブロックチェーン上に記録される所有権証明付きドメイン
• 一度購入すれば永久所有、売却可能
• Web3 ログイン認証として機能（Login with Unstoppable）
• 主要プロバイダー: Unstoppable Domains, ENS

4.2 Dmail とは

• Web3 分散型暗号化メール + 従来メールとの相互運用
• AI 搭載アシスタント、Drive/Meeting/Chat 統合の Web3 ワークスペース
• エンタープライズ向けマーケティングハブ
• 2025年1億ユーザー目標、独自チェーン構築中

4.3 ビルメンでの活用

現時点の方針:

• MVP の本線は 通常メール + 監査ログ + 添付証跡
• NFT ドメインは Phase A ではブランド保護を主目的とする
• Dmail は即時全面導入ではなく、PM pilot と限定的な実運用検証から入る
• Web3 は optional trust layer であり、Core / Toriteki / Mitsumori の必須前提にはしない

5. 5層アーキテクチャ

┌──────────────────────────────────────────────────┐
│  Layer 5: AI Agent Hub（AI 主導層）               │
│  - 積算 AI: 面積×単価×頻度から自動見積           │
│  - 原価 AI: 物件別損益リアルタイム監視            │
│  - シフト AI: 人員配置最適化                      │
│  - 点検 AI: IoT異常検知 → 作業指示自動生成       │
│  - 取適法 AI: 発注条件の自動コンプライアンス      │
├──────────────────────────────────────────────────┤
│  Layer 4: Web3 Trust（信頼・証跡層）              │
│  - NFTドメイン: 将来の協力会社認証・テナントID    │
│  - Dmail: 将来の暗号化送信 pilot                  │
│  - オンチェーン証跡: 将来の作業/検収証跡          │
├──────────────────────────────────────────────────┤
│  Layer 3: TATEKAN Control（制御層）               │
│  - 元請け: Core+Toriteki+Mitsumori (linked)      │
│  - 協力会社: Toriteki only / Toriteki+Mitsumori   │
│  - designated_parent_app で shared reference 制御 │
├──────────────────────────────────────────────────┤
│  Layer 2: Business Apps（業務アプリ層）            │
│  ┌──────────┬───────────┬────────────┐          │
│  │ Core     │ Toriteki  │ Mitsumori  │          │
│  │ 物件管理 │ 協力会社  │ 清掃積算   │          │
│  │ 契約管理 │ 発注管理  │ 設備積算   │          │
│  │ 請求入金 │ 作業報告  │ 警備積算   │          │
│  │ 物件損益 │ 検収管理  │ 帳票出力   │          │
│  └──────────┴───────────┴────────────┘          │
├──────────────────────────────────────────────────┤
│  Layer 1: Infrastructure                         │
│  Cloud Run / Cloud SQL / GCS / tatekan.app       │
└──────────────────────────────────────────────────┘

6. 競合との差別化

7. ロードマップ案

Phase A: 基盤固め（現在 → 6ヶ月）

• TATEKANOS の AI-native operating system 原則を固定
• TATEKAN Control Phase 1 実装完了
• ビルメン固有エンティティ（物件、区画、作業メニュー、単価テーブル）の設計
• Mitsumori の AI-first 積算テンプレート設計
• Toriteki の売り引き / pricing / workflow 境界の整理
• tatekan.app NFTドメイン取得（ブランド保護）

Phase B: 業界OS MVP（6〜12ヶ月）

• 元請けテナント（full_linked）+ 協力会社テナント（standalone）の実運用
• 物件別損益の自動集計
• AI 積算支援
• Mitsumori の AI-first MVP 実装
• Con の tenant composition 運用開始
• Dmail pilot（限定的な暗号化送信検証）

Phase C: 信頼プラットフォーム（12〜24ヶ月）

• TATEKAN Core の集中再開と AI-first UI 置換
• NFTドメインベースの協力会社認証
• オンチェーン作業証跡
• AI Agent Hub（シフト最適化、点検AI、取適法AI）
• テナント間連携（A社の発注 → B社の受注が直接流れる）

8. 設計論点と採用方針

1. ビルメン固有エンティティ: - property/building は Core 所有 - zone は共通大マスターにせず、Mitsumori は見積用、Toriteki は実行用で使い分ける - service menu / unit price table は Mitsumori 所有、Core と Toriteki には snapshot を渡す
2. 協力会社 standalone tenant: - 第一候補は Toriteki only - 第二候補は Toriteki + Mitsumori - Core は元請けの販売本体であり、協力会社の必須前提にしない
3. NFTドメイン / Dmail: - MVP の前提にしない - Phase A はブランド保護、Phase B は PM pilot、Phase C で trust layer 拡張を狙う
4. SaaS pricing: - 高額 seat 課金ではなく、低い基本料 + 成果連動 add-on を基本線にする - 協力会社向けは free receive/respond か極小課金を優先する
5. AI Agent 優先順位: - 第1優先: 積算 AI - 次点: 原価 AI、取適法 AI - シフト AI / 点検 AI は後段
6. 既存文書との整合: - domain_entity_service_mapping.md は汎用の上位参照として維持 - ビルメン固有拡張は別紙 industry_os_building_maintenance_mapping.md で整理する

9. 結論（暫定）

TATEKAN は「ビルメン業界OS」になりうる構造を既に持っている。

• TATEKAN Control = 業界OS の Control Plane
• 3アプリの composable 設計 = 元請け/協力会社が必要な機能だけ使える
• standalone/linked = 多層下請け構造にそのまま対応
• AI 3体制 = 開発自体が AI 協働で進んでいる

核心は「元請けと協力会社が同じプラットフォームに乗ること」であり、これが利益率改善・人手不足解消・取適法対応のすべてを同時に解く。

NFTドメイン + Dmail は optional trust layer として段階的に統合し、「信頼のプラットフォーム」へ進化させる。

10. Codex レビュー結果（2026-03-10 16:35 JST）

Codex が vision 本文 + 既存責務境界 docs + 外部一次情報を突き合わせてレビュー。

Finding 1: 物件系エンティティの所有権を厳密に分けるべき

• property/building → Core 所有（安定した物件参照 + 契約・損益）
• zone（作業範囲ゾーン） → 共通大マスターにしない
• Mitsumori: 見積用の作業範囲ゾーン
• Toriteki: 発注・納品・検収用の実行ゾーン
• service menu / unit price table → Mitsumori 所有が基本
• Core: 契約成立時のスナップショットのみ
• Toriteki: 発注時の service package / agreed vendor rate snapshot のみ
• 問題: vision の「Layer 2」表現だけだと Toriteki 側まで pricing master を持つように読める → 危険
• 参照: tatekan_industry_os_vision.md:147, tatekan_responsibility_boundary_memo_20260310.md:22, tatekan_control_basic_design.md:95

Finding 2: 協力会社の standalone tenant 設計

• 第一候補: Toriteki only
• 第二候補: Toriteki + Mitsumori
• Core は元請けの販売本体 → 下請けに最初から要求すると参加障壁が高すぎる
• vision の「designated_parent_app で正本管理」は言い過ぎ → 正しくは「standalone dual-app 時の shared reference host」
• ビジネスモデル: 協力会社向けは free receive/respond + low-cost operate、元請け側に network fee を持たせる
• 参照: tatekan_industry_os_vision.md:142, tatekan_control_basic_design.md:255, tatekan_control_requirements_draft.md:152

Finding 3: NFT domain / Dmail は将来の optional trust layer に下げるべき

• ブランド保護として tatekan.app 系取得 → OK
• 企業 KYC や発注先実在証明の代替としては未成熟
• Dmail: wallet/DID ベースの Web3 通信が本体。Google/Telegram 対応は進んでいるが、日本のビルメン業界の FAX/メール慣行をそのまま置き換える段階ではない
• 結論: 近未来は 通常メール + 監査ログ + 添付証跡 を本線、Web3 は pilot に留める
• 参照: tatekan_industry_os_vision.md:99

Finding 4: SaaS pricing — network-subsidized low-friction pricing が最適

• 高額 seat 課金は不適（利益率 0.5% の業界）
• 推奨モデル:
• 元請け: Core + Toriteki + Mitsumori + Con の platform fee
• 協力会社: Toriteki inbox/respond を 無料 or 極小課金、重い機能だけ有料化
• 課金軸は field worker seat ではなく:
• managed property / active vendor link / issued order / processed inspection / AI usage
• 低い基本料 + 成果連動 add-on が推奨
• 参照: tatekan_industry_os_vision.md:203

Finding 5: 最初の AI Agent は「積算 AI」

推奨順序: 1. 積算 AI（最優先 — 既存 pain に最も直結、Mitsumori 単独で価値を出せる） 2. 原価 AI（Core + Toriteki の原価実績がつながってから） 3. 取適法 AI 4. シフト AI / 点検 AI（workforce/attendance data、IoT/モバイル証跡が必要なため後段） - 参照: tatekan_industry_os_vision.md:130

Finding 6: domain_entity_service_mapping.md は拡張しすぎない

• あれは横断の上位参照 → ビルメン固有エンティティを入れると汎用文書が vertical 専用化する
• 推奨: domain_entity_service_mapping.md に短いリンク節だけ追加、別紙として industry_os_building_maintenance_mapping.md を起こす
• 参照: domain_entity_service_mapping.md:27

Codex 総評

方向性自体は良い。修正すべき本質は 2 点: 1. ビルメン固有 master の所有権をもっと厳密に分けること 2. Web3 を MVP の前提ではなく将来レイヤーへ下げること

そこを直せば、Industry OS の主張はかなり筋が通る。

外部確認ソース（Codex）

• Unstoppable Login overview
• ENS primary names
• Dmail mainnet / Google login
• Dmail embedded wallets
• 全国ビルメンテナンス協会 年鑑案内
• 全国ビルメンテナンス協会 労務単価上昇

11. ClaudeCode × Codex 合意事項（暫定）

12. 残る PM 判断待ち事項

1. ビルメン業界OS を TATEKAN の正式なプロダクト方針として採用するか
2. Phase A（基盤固め）の着手タイミング
3. 合同産業以外の最初のターゲット顧客像
4. NFT/Dmail の pilot 時期と対象
5. 本構想を tatekan-ops PM ポータルに掲載するか

13. GeminiCLI レビュー結果（2026-03-10 17:00 JST）

GeminiCLI が NFT ドメインのオンボーディング設計と Dmail Chrome 拡張機能の実態を調査。

Finding A: NFTドメインの「2つの入口」設計

テナントに対して Web3 メール（NFTドメイン）の入口を 2 系統用意する。

A系統: BYOD（Bring Your Own Domain）— 上級者向けオプション

• テナントが独自に NFT ドメインを用意（例: tenant-company.eth, tenant.crypto）
• メリット: テナント完全コントロール、ブランド一貫性、TATEKAN 側のコスト負担なし
• デメリット: ウォレット管理リテラシーが必要 → 導入ハードルが高い

B系統: SaaS Managed — 標準オプション（推奨）

• TATEKAN が親ドメイン（例: tatekan.eth）を取得
• テナント登録時に tenant-a.tatekan.eth のようなサブドメインを自動発行
• メリット: テナント側は Web3 知識不要、「エンタープライズ機能」申込だけで利用開始 → UX が劇的に向上
• デメリット: ガス代を TATEKAN が負担、親ドメインの管理権限セキュリティが重要

GeminiCLI 推奨

• まず B（TATEKAN サブドメイン自動発行）を標準の「監査・セキュア通信オプション」として提供
• A（独自ドメイン持ち込み）は上級者向けオプション設定として開放

Finding B: Dmail Chrome 拡張機能による Web2/Web3 統合

Dmail は「既存の Web2（Gmail 等）と Web3 のシームレスな統合」を戦略の核としている。

Chrome 拡張機能でできること

1. Gmail 画面での Web3 機能統合 - Gmail の画面上に Dmail 機能（暗号化送信、送信取り消し等）を統合
2. Web2 ↔ Web3 双方向リレー通信 - Web2→Web3: Gmail 等から Dmail アドレス（xxx@dmail.ai）宛に送信可能 - Web3→Web2: Dmail から通常の Gmail / 企業メール宛に送信可能
3. Wallet 接続ログイン - MetaMask 等のウォレット接続でパスワード不要の Web3 メール利用

TATEKAN テナントの利用イメージ

• 通常業務: 今まで通り Gmail / Outlook でメールを見る
• セキュア通信（Dmail 経由）: Chrome 拡張機能 or TATEKAN 画面から送信ボタン → ブロックチェーン + 分散型ストレージ経由で改ざん防止・完全暗号化メッセージとして送達

GeminiCLI 総評

「2つの入口でテナントの導入ハードルを下げる」アプローチと、「Dmail の Web2/Web3 ゲートウェイ・Chrome 拡張機能で既存 Gmail の延長線上でセキュア通信を実現する」アプローチは、TATEKAN のプロダクト価値（言った・言わないをなくす、改ざん不可能な証跡を残す）を最大化する非常に現実的で強力な組み合わせ。

14. 3 AI Agent 統合見解

15. PM 決定事項（2026-03-10 17:10 JST）

15.2 TATEKANOS 命名決定（2026-03-10 17:15 JST）

• 「TATEKAN Platform」という表現は今後 TATEKANOS（タテカノス）に統一する
• TATEKANOS = TATEKAN + OS（業界OS としてのポジショニングを名称に反映）
• 読み: タテカノス（一語として読む。「タテカン・オーエス」ではない）
• 略称: NOS（ノス）
• 個別アプリ名（TATEKAN Core / Toriteki / Mitsumori / TATEKAN Control）は変更なし

15.3 TATEKANOS UI 原則（2026-03-10 17:20 JST）

• NOS = AI-native operating system を採用する
• Core、Toriteki、Mitsumori の UI は最終的に AI-first を目指す
• 主入口は chat + voice
• ただし、監査、承認、差分確認、例外処理のための最小限の structured UI は残す
• GLOVIA 型の大量入力画面をそのまま再現することは目的にしない

15.4 TATEKAN Core 再開方針（2026-03-10 17:25 JST）

• TATEKAN Core は現行 GLOVIA 運用中の本体であるため、薄く並行実装しない
• NOS、Con、Mitsumori、Toriteki の前提整理を先に進める
• Core の本実装再開は、最後に 集中フェーズ として扱う
• 再開時は AI-first UI への置換を前提にする
• それまでは再開準備、責務境界、参照キー、番号体系、監査要件の整理を優先する

未決定（継続検討）

• Phase A 着手タイミング
• 合同産業以外の最初のターゲット顧客像

16. Next Actions

1. [ ] industry_os_building_maintenance_mapping.md を別紙として起草
2. [ ] domain_entity_service_mapping.md にリンク節を追加
3. [ ] Con Phase 1 の実装 scope を freeze する
4. [ ] Mitsumori の AI-first MVP issue を分解する
5. [ ] Toriteki の売り引き / pricing / workflow 境界を詰める
6. [ ] TATEKAN Core 集中再開の前提条件を checklist 化する
7. [ ] tatekan.eth / tatekan.crypto 等の NFT ドメイン取得調査 + 取得実行
8. [ ] PM が Dmail Chrome 拡張機能を個人で試用

本文書は PM + ChatGPT → ClaudeCode → Codex → GeminiCLI の 4者討議プロセスを経た working document です。 ClaudeCode 調査・起草: 2026-03-10 14:00 JST Codex レビュー完了: 2026-03-10 16:35 JST GeminiCLI レビュー追記: 2026-03-10 17:00 JST PM 決定: 2026-03-10 17:10 JST — 正式採用 TATEKANOS 命名決定: 2026-03-10 17:15 JST

TATEKAN Responsibility Boundary Memo

Date: 2026-03-10 JST
Status: Working memo
Purpose: TATEKAN Core / Mitsumori / Toriteki / 一般購買 の責務境界を固定するための整理メモ

Related: - docs/Tatekan/tatekanos_canonical_commercial_architecture.md（2026-03-15 時点の canonical schema / master / 連携主線の整理）

1. 結論

TATEKAN 全体の責務分担は、次の前提で整理する。

• TATEKAN Core は販売本体であり、案件の正本を持つ
• Mitsumori は見積作成の正本を持つ
• Toriteki は受発注、納品、検収、受託側請求などの進行管理を担う
• 社内消耗品や事務用品などの一般購買は、顧客案件とは分けて扱う

2. 3システムの責務

2.1 TATEKAN Core

GLOVIA販売 が現状担っている販売本体機能の置換先として扱う。

主な責務:

• 案件管理
• 契約管理
• 売上管理
• 請求管理
• 入金 / 消込
• 会計連携
• 販売本体系の顧客 / 物件 / 契約系マスタ

補足:

• 案件の正本 は TATEKAN Core に置く
• 顧客に紐づく業務案件の受注後商流正本は TATEKAN Core に置く
• 見積起点案件では、受注前の起点は Mitsumori になり得る

2.2 Mitsumori

見積作成システムとして位置づける。

主な責務:

• 見積作成
• 見積明細編集
• 見積一覧 / 検索
• 見積複写
• paste ベース入力
• テンプレート帳票出力
• 出力履歴
• 見積提出補助

補足:

• 見積書の正本 は Mitsumori に置く
• Mitsumori は案件管理の正本を持たない
• Mitsumori は本格的な受発注進行管理を持たない
• ただし canonical architecture では、受注前の commercial_context 作成と Core への受注昇格起点を担う

2.3 Toriteki

受発注と履行進行のワークフローシステムとして位置づける。

主な責務:

• 受託先への見積依頼
• 見積回収
• 発注
• 納品
• 検収
• 受託側請求
• 通知 / 督促 / メール起点ワークフロー
• 取適法対応の進行管理

補足:

• 受発注進行の正本 は Toriteki に置く
• Toriteki は案件の親台帳そのものを持ちすぎない
• Toriteki は契約 / 売上 / 入金 / 会計連携の正本を持たない
• canonical architecture では、受注前の仮案件、execution_unit 単位の履行、請求候補化も担う

3. 入口の分岐

3.1 顧客案件

顧客に紐づく案件は、受注前後で起点を分けて扱う。

例:

• 商マネ社案件
• 商マネ社以外の顧客案件
• 役務提供案件
• 工事案件
• 顧客請求対象となる物品購入

基本フロー:

1. 見積起点案件では Mitsumori で見積と商流前段情報を作成
2. 顧客受注/契約確定で TATEKAN Core に受注昇格する
3. 必要なら Toriteki で受託先へ見積依頼・発注・納品・検収を行う
4. 契約 / 売上 / 請求 / 入金 / 会計連携の正本は TATEKAN Core

補足:

• 2026-03-15 時点の canonical は Mitsumori-first -> Core を標準とする
• 本文書の Core-first 読みは、旧整理ではなく上記フローで読む

3.2 一般購買

社内消耗品や事務用品など、顧客案件に紐づかない購買は TATEKAN Core の案件起点とは分けて扱う。

例:

• Amazon Business での事務用品購入
• 社内使用の消耗品購入
• 顧客請求対象ではない備品購入

補足:

• これは 販売案件 ではない
• 必要に応じて Toriteki を購買ワークフローに流用する余地はある
• ただし 案件の正本 として TATEKAN Core に載せる前提ではない

4. 商マネ社案件とその他案件

4.1 商マネ社案件

商マネ社案件は、顧客案件として受注後商流正本を TATEKAN Core に置く。

特徴:

• Mitsumori で商マネ社向け見積書を作成する
• 承認や受発注進行は Toriteki で扱う
• MARCURY への copy / 提出補助は Mitsumori UI が担う
• MARCURY は外部 legacy であり、正本ではない

4.2 商マネ社以外の案件

商マネ社以外でも、顧客案件である限り基本構造は同じとする。

特徴:

• Mitsumori で見積作成
• 顧客受注確定で TATEKAN Core に受注昇格
• Toriteki で受発注進行
• MARCURY は関与しない

整理:

• 商マネ社案件だけ MARCURY 分岐が追加される
• システムの中心構造自体は商マネ社案件と共通である

5. 物品と役務の違い

5.1 役務 / 工事

役務や工事は、原則 顧客案件 として扱う。

したがって:

• 見積起点なら Mitsumori
• 受注後商流正本は TATEKAN Core
• 外注や履行進行が必要なら Toriteki

5.2 物品

物品は、顧客案件に乗るかどうか で分岐する。

顧客案件に乗る物品

例:

• 商マネ社案件の 建物管理費 として扱う物品

扱い:

• 必要なら Mitsumori で見積 / 帳票作成
• 受注後商流正本は TATEKAN Core
• 必要なら Toriteki で受発注進行
• 商マネ社案件なら MARCURY 入力が後続で発生しうる

顧客案件に乗らない物品

例:

• 合同産業の社内消耗品
• 事務用品

扱い:

• 一般購買
• TATEKAN Core の案件起点とは分ける

6. AIへの最初の指示

6.1 顧客案件

AIへの最初の指示は、案件段階に応じて起点を分けて考える。

例:

• 見積を作成する
• この案件は商マネ社案件である
• この案件は物品案件である
• この案件は役務案件である
• 顧客受注が確定したので Core に昇格する

6.2 一般購買

一般購買は、TATEKAN Core ではなく購買フロー起点で指示する。

例:

• 社内消耗品の購入を進める
• Amazon Business での購買処理を進める

7. 重複させない原則

• TATEKAN Core は案件・契約・売上・請求・入金・会計の正本を持つ
• Mitsumori は見積作成に集中する
• Toriteki は受発注と履行進行に集中する
• MARCURY は商マネ社案件で必要な外部 legacy として扱う
• 一般購買は顧客案件と混ぜない

8. 現時点の結論

GLOVIA販売 の置換本体は TATEKAN Core である。
Mitsumori は見積作成サブシステム、Toriteki は受発注・納品・検収の進行システムとして位置づける。 ただし、社内消耗品や事務用品などの一般購買は、顧客案件とは別フローとして扱う。

9. ClaudeCode レビュー（2026-03-15 19:30 JST）

9.1 本文書の位置付け

本文書は 2026-03-10 時点の責務境界の初期整理であり、その後 tatekanos_canonical_commercial_architecture.md（2026-03-15）で canonical schema・pure master・商流コンテキスト等を伴う再設計に発展している。本文書の基本方針（Core=案件正本、Mitsumori=見積正本、Toriteki=受発注進行正本）は canonical architecture でも維持されている。

9.2 本文へ反映済みの更新点

• 見積起点案件の標準フローを Mitsumori-first -> Core に更新
• Mitsumori の commercial_context 前段責務と Core 昇格起点を追記
• Toriteki の仮案件 / 履行 / 請求候補責務を追記
• MARCURY の copy / 提出補助を Mitsumori UI responsibility と明記

9.3 本文書で引き続き有効な整理

以下は canonical architecture でも変更されておらず、引き続き有効:

• 一般購買と顧客案件の分離（§3.2）— canonical architecture ではスコープ外として扱われているが、本文書の整理が唯一の記述
• 商マネ社案件と一般案件の MARCURY 分岐（§4）— canonical architecture では MARCURY を「商流属性」として抽象化しているが、本文書の具体的な分岐記述は実務参照として有用
• 物品と役務の分岐ルール（§5）— canonical architecture では直接扱われていないため、本文書が唯一の参照
• 重複させない原則（§7）— canonical architecture の pure master / 運用拡張分離と整合

9.4 Fredy 調査からの補足

2026-03-15 の Fredy マスター調査で以下を確認:

• Fredy は department（部門）+ building（建物） ベースの組織構造を採用
• 本文書で言及されていない business_code（業務コード）マスター が Fredy に存在し、GLOVIA 販売連携用のコード変換・会計属性付き master として機能
• Toriteki の branch/facility は Fredy の department/building に移行予定（canonical architecture §11 Phase 1）

詳細: docs/architecture/tatekanos_family_integration.md

TATEKANOS Canonical Commercial Architecture

Date: 2026-03-15 JST
Status: Working draft
Purpose: Mitsumori / Toriteki / TATEKAN Core の責務、canonical schema、共通 master、標準連携フローを固定し、個別最適を避けた再設計の正本たたき台とする

1. Architecture Decision (PM-approved 2026-03-16)

master management strategy は次の 3-phase で確定した。

• Phase 1 (NOW): tatekanos_shared に canonical master model を library として追加する
• Phase 2 (post-Toriteki + Mitsumori beta): Core を master-only scope で先行起動し、department / building / business_code / customer / supplier の単一正本とする
• Phase 3 (long-term): 必要なら tatekanos_shared の service 化を検討する

補足:

• Con (TATEKAN Control) は master authority にしない
• Core は beta 後までは pure master authority ではなく、Phase 1 中は各サービスが shared schema + local Datastore で運用する
• 本文書でいう Core = pure master authority は Phase 2 以降の責務 として読む

2. 結論

TATEKANOS の標準形は、次の 3 層構造とする。

• Mitsumori
• 見積正本
• 商流コンテキスト正本（受注前）
• 顧客受注確定まで
• Toriteki
• 仮案件
• 発注
• 履行
• 検収
• 発注/履行進行の正本
• TATEKAN Core
• 共通 pure master 正本
• 受注後商流正本
• 請求 / 入金 / 会計IF 正本
• change set 正式確定

MARCURY は起票元ではなく、商流属性 / 外部連携属性 として扱う。
標準連携フローは次の通り。

Mitsumori
  -> Core
    -> Toriteki
      -> Core
        -> Accounting Adapter

ただしこれは単純な直列ではなく、役割分担は次のように固定する。

• Mitsumori: 顧客向け見積と商流前段
• Toriteki: 協力会社発注と履行実績
• Core: 受注後商流と共通 master と請求/入金/会計

3. 設計原則

3.1 canonical schema 先行

• Core の現行物理DBや GLOVIA販売 テーブルに全体設計を従属させない
• 先に TATEKANOS canonical schema を定義し、その後に Core/GLOVIA へマッピングする
• 物理実装は現行 Core を活かしてよいが、論理設計はそこに縛られない

3.2 pure master と運用拡張の分離

pure master は Core に寄せる。

• department
• building
• business_code
• customer
• supplier

運用拡張は App 側または tenant adapter 側に分ける。

• customer 運用拡張
• 見積段階では Mitsumori
• 受注後は Core
• supplier 運用拡張
• Toriteki

3.3 pure building / pure customer / pure supplier

• building は pure master に保つ
• customer は pure master に保つ
• supplier は pure master に保つ
• 請求先 / 契約先 / 管理会社 / 元請商流先 のような役割情報は master に持たせず、commercial_context に寄せる

3.4 標準形と例外形

• 標準形は Core 併用
• Mitsumori単独 は正式にあり得る
• Toriteki単独 は標準外オプションとして保留する

4. canonical schema の主要 entity

4.1 共通 master

• department
• 組織所属
• 承認系既定値
• 見積既定値
• building
• 基本属性
• 所属 department
• 建物種別
• business_code
• 業務分類
• 会計/売上区分
• 工事分類
• 集計区分
• customer
• pure customer master
• supplier
• pure supplier master

4.2 前段商流

• quotation
• quotation_line
• commercial_context
• quotation_line_execution_map

補足:

• commercial_context は Mitsumori でも正式 entity として持つ
• Mitsumori 見積ヘッダ は複数の commercial_context を持てる
• 見積明細 は commercial_context に明示リンクする
• quotation_line と execution_unit は多対多とし、quotation_line_execution_map に
• 按分数量
• 按分金額
• 補足メモ を持つ

4.3 受注後商流

• sales_order
• execution_unit
• procurement_order
• inspection_event
• invoice
• invoice_line
• receipt
• payment
• accounting_export_batch
• accounting_export_line
• change_set
• approval_event

4.4 粒度ルール

• Core受注1件 は sales_order 1 件
• sales_order 配下に複数の execution_unit を持てる
• execution_unit の標準粒度は 建物 × 業務コード
• execution_unit に対して複数の procurement_order を持てる
• 請求は固定粒度ではなく invoice header + invoice lines

5. アプリ責務

5.1 Mitsumori

責務:

• 見積作成
• 見積承認
• 顧客提示
• commercial_context 前段編集
• 顧客受注確定
• Core への受注昇格起点

補足:

• Mitsumori単独 テナントでは
• 見積作成
• 承認
• 出力/提出
• 受注確度/失注管理
• 簡易受注管理 を標準機能として持つ
• Core 導入テナントでは、簡易受注管理は read-only / 補助表示に留める
• 既存の orders / delegations 相当機能は、Core 併用テナントでは正本機能として維持しない
• orders: Core の sales_order 参照または補助表示へ縮退
• delegations: 見積承認 / 依頼補助へ再定義するか、不要なら整理対象とする

5.2 Toriteki

責務:

• 受注前の仮案件
• 原価見積/RFQ
• 協力会社発注
• 履行
• 検収
• 請求候補化

補足:

• commercial_context は参照のみ
• supplier 運用拡張は Toriteki 主編集
• Toriteki は最終請求正本や最終会計IF正本を持たない

5.3 Core

責務:

• pure master 正本
• sales_order 正本
• 請求対象確定
• 請求確定
• 入金確認
• 会計 export
• change_set 正式確定

UI 方針:

• Core は基幹/管理ハブ寄り
• 主に扱うのは
• master 管理
• 請求確定
• 入金確認
• change set 確定

6. 商流コンテキスト

6.1 定義

commercial_context は、案件上の相手先関係を保持する entity とする。

最低限含むもの:

• 契約先
• 請求先
• 管理会社 / 元請商流先

6.2 配置原則

• building は pure master のまま保つ
• 相手先役割は building や customer に持たせず、commercial_context に寄せ切る
• execution_unit はどの commercial_context に属するかを明示リンクする

6.3 Mitsumori / Core / Toriteki での扱い

• Mitsumori
• 見積段階の正式 entity
• 作成・編集を行う
• Core
• 受注後の正本
• 継続編集を行う
• Toriteki
• 参照のみ

6.4 MARCURY との関係

• MARCURY は commercial_context の一属性または外部連携条件として扱う
• MARCURY への copy-paste / 提出補助の UI 責務は Mitsumori に置く
• 手動運用が残る場合でも、どの画面がそれを補助するかは Mitsumori 側で明確に持つ

7. 標準ライフサイクル

7.1 顧客受注前

1. Mitsumori で quotation と commercial_context を作成
2. 必要なら quotation_line をもとに execution_unit 候補を判定
3. 次の OR 条件を満たす場合、Toriteki に仮案件を起票 - 外注あり - 工事案件 - MARCURY 連動必要
4. Toriteki では 建物 × 業務コード 粒度で仮案件を持つ

7.2 顧客受注確定

1. 顧客受注/契約が確定した時点で Mitsumori -> Core
2. Core に - quotation - quotation_line - commercial_context - sales_order を作成
3. 条件に応じて execution_unit を正式生成

7.3 履行・検収

1. Toriteki で procurement_order を作成
2. 発注・履行・納品・検収を行う
3. inspection_event は Toriteki -> Core へ即時反映

7.4 請求対象化

1. Toriteki が請求候補を作成
2. Core が請求対象化を最終確定
3. invoice / invoice_line を確定
4. receipt / payment と accounting_export へ接続

8. 変更管理

8.1 change_set

• Mitsumori と Toriteki の両方から起票可
• 正式確定は Core
• Core 確定後は Mitsumori / Toriteki へ即時反映

8.2 change_set の対象

• 見積明細
• execution_unit
• 受注増減額
• 追加工事
• 差替
• 減額

9. 承認モデル

承認正本は単一システムに寄せず、業務段階ごとに分散する。

• Mitsumori
• 見積承認
• Toriteki
• 発注承認
• Core
• 請求承認
• change set 承認

department が持つ 承認系既定値 は、承認ルートや承認候補者のデフォルト設定を指す。
承認実績そのものの正本は department に持たせず、各業務段階のシステムと approval_event に記録する。

横断監査用に approval_event を共通記録として持つ。

最低限持つ項目:

• 対象ID
• 承認者
• 結果
• 時刻
• コメント
• 承認段階 / ルート情報

10. 3システム横断連携表

11. Mitsumori / Toriteki の不足・過剰

11.1 Mitsumori に足りないもの

• commercial_context の正式 entity 化
• quotation_line -> execution_unit 多対多マッピング
• business_code 前提の見積構造
• customer pure / 運用拡張分離
• 顧客受注確定から sales_order へ昇格する設計/実装
• change_set 起票モデル
• Core ありテナントでの簡易受注 read-only 化

11.2 Toriteki に足りないもの

• branch / facility から department / building への完全移行
• execution_unit = 建物 × 業務コード 粒度への統一
• commercial_context 参照前提の設計
• procurement_order -> inspection_event -> invoice candidate の canonical 接続
• supplier pure / 運用拡張分離
• change_set 起票モデル

11.3 Mitsumori に余計なもの

• 受注後商流の本格正本化
• 請求/会計まで持つ方向
• agreements / orders を Mitsumori 内部正本として持つ発想

11.4 Toriteki に余計なもの

• 最終請求正本
• 最終会計 export 正本
• branch / facility を family 共通 master として維持すること
• commercial_context 自前正本化

12. 本書のスコープ外

本書は顧客案件に紐づく商流と履行の canonical architecture を対象とする。
次は本書の直接スコープ外とする。

• 一般購買
• 社内消耗品や事務用品の購買フロー
• Toriteki単独 を正式標準形として扱う配備モデル

一般購買は tatekan_responsibility_boundary_memo_20260310.md の整理を参照し、必要に応じて別アーキテクチャで定義する。

13. 実装フェーズ

Phase 1: 共通 master 再編

先行:

• department
• building
• business_code

実装方針:

• tatekanos_shared に canonical master model を library として追加する
• Mitsumori / Toriteki は shared schema を採用するが、この phase では各サービスの local Datastore を使う
• Core はまだ master authority としては起動しない

後段:

• customer
• supplier

Phase 2: Mitsumori -> Core 主線

最小実装で次を一気に通す。

• quotation
• quotation_line
• commercial_context
• 顧客受注確定で sales_order 作成
• 条件付き execution_unit 生成
• これと並行して Core master-only scope を先行起動し、5 master の単一正本を持たせる

Phase 3: Toriteki -> Core 主線

最小実装で次を一気に通す。

• procurement_order
• inspection_event 即時反映
• 請求候補化

Phase 4: 後段統制 / optional shared service 検討

• customer / supplier 再編
• change_set
• receipt / payment
• accounting_export adapter
• 必要なら tatekanos_shared service 化の再評価

14. 保留事項

• Toriteki単独テナント を正式な標準配備モデルにするか
• tenant ごとの adapter 範囲の詳細
• 現行 Core/GLOVIA 物理DBへの具体的マッピング方式
• customer / supplier 後段移行の優先順

15. ClaudeCode レビュー（2026-03-15 19:30 JST）

15.1 全体評価

本文書は responsibility_boundary_memo（2026-03-10）を大幅に発展させた次段の設計文書として十分成立している。canonical schema の定義、pure master vs 運用拡張の分離、commercial_context の first-class entity 化は、Fredy 調査結果とも整合しており設計品質は高い。

15.2 同意する設計判断

• pure master を Core に寄せる判断（department, building, business_code, customer, supplier）
• commercial_context を building/customer に埋め込まず独立 entity とした判断
• execution_unit の標準粒度 = building × business_code
• change_set の分散起票 + Core 確定モデル
• approval_event による横断監査記録
• Mitsumori 単独テナントを正式な標準配備モデルとして認めた判断

15.3 要確認・要明確化の論点

論点1: Mitsumori-first vs Core-first の矛盾解消

responsibility_boundary_memo §3.1 では「Core で案件作成 → Mitsumori で見積作成」としているが、本文書 §6.1 では「Mitsumori で quotation/commercial_context を作成 → 顧客受注確定で Core に sales_order 化」としている。これは逆方向のフローである。

本文書の Mitsumori-first が canonical であるなら、responsibility_boundary_memo の該当箇所を明示的に「旧前提・更新済み」とマークすべき。曖昧なまま残すと実装者が Core-first と Mitsumori-first を混同する。

論点2: department と承認経路のデフォルト設定

Fredy 調査で department に approval_group1-4 が埋め込まれていることを確認した。本文書 §8 では承認を業務段階ごとに分散（Mitsumori=見積承認, Toriteki=発注承認, Core=請求/変更承認）としている。この設計は Fredy パターンより優れている。

ただし明文化が必要: department は「承認のデフォルト設定元」であって「承認実績の正本」ではない。Fredy の承認埋め込みをそのまま継承しないことを明示すべき。

論点3: Mitsumori 既存の /orders, /delegations の扱い

§10.3 で「agreements/orders を Mitsumori 内部正本として持つ発想」を excess と指摘しているが、現在の Mitsumori には既に /orders, /delegations ルートが存在する。移行方針の明確化が必要:

• Core ありテナント: read-only 参照 or Core 昇格前後の補助 UI に縮退
• Mitsumori 単独テナント: 簡易受注管理として限定維持
• delegations: 見積承認/依頼補助へ再定義 or 整理対象

論点4: MARCURY 連携の実務責任

§1 で MARCURY を「商流属性/外部連携属性」として位置付けているのは正しい。ただし、実務的に誰が copy-paste ワークフローを維持するかが未定義。推奨: Mitsumori UI が MARCURY 連携対象案件の提出補助を担う（手動ではあるが UI 責任は Mitsumori 側）。

論点5: 一般購買のスコープ

本文書は顧客案件商流に集中しており、一般購買（社内消耗品・事務用品等）が扱われていない。推奨: §12 保留事項に「一般購買は本 canonical architecture のスコープ外。別アーキテクチャとして扱い、Toriteki を購買ワークフローに流用する余地あり」と明記する。

15.4 追加の設計観察

1. schema と deployment model の分離: Mitsumori 単独可/Toriteki 単独は標準外/Core 標準は「配備モデル」であり、canonical schema とは別の関心事。将来的には別節に分離した方が読みやすい。

2. commercial_context と customer 運用拡張の境界: commercial_context を first-class にした結果、customer 運用拡張との境界を厳密にしないと責務が逆流する。特に請求先/契約先/管理会社は customer 側へ戻さず commercial_context に留めるべき。

3. execution_unit の例外: building × business_code は強い標準粒度だが、time-based recurring services や building をまたがる一括業務が将来出る可能性がある。標準粒度の注記として「例外時は execution_unit を建物横断で束ねる上位 entity を導入する余地あり」程度の escape hatch を記載しておくと安全。

4. Fredy 業務マスターとの関係: 本文書の business_code は Fredy の businesses master に対応する。Fredy 調査で business_code が GLOVIA 連携用コード変換・集計・会計属性付き master であることを確認済み。本文書 §3.1 の business_code 定義（業務分類/会計・売上区分/工事分類/集計区分）は Fredy 実態と整合しており、そのまま採用可能。

Google Workspace CLI (gws) — TATEKANOSファミリー横断活用方針

作成日: 2026-03-12 作成者: ClaudeCode（GeminiCLI調査結果を統合・文書化） ステータス: Draft v0.1 参照記事: https://dev.classmethod.jp/articles/google-workspace-cli-release/

1. gws 概要

Google Workspace CLI（gws）は、GoogleのDiscovery Serviceを利用してGoogleの各種Workspace API（Gmail / Drive / Sheets / Chat等）をCLIコマンドから直接操作できるツール。

2. TATEKANOSファミリーにおける位置づけ

[TATEKANOS AI Agent Hub]
    ↓ MCP / CLIコマンド
[gws（Google Workspace CLI）]
    ↓
[Gmail]  [Google Drive]  [Google Sheets]  [Google Chat]
    ↑          ↑               ↑                ↑
  Mitsumori  Toriteki    TATEKAN Core       全システム
 (発注メール) (証跡保存)  (経営ダッシュ)     (通知・アラート)

設計原則: gws は「GCPインフラ（Cloud Run / Pub/Sub等）とGoogle Workspace（社内ツール）をつなぐ糊（のり）」として活用する。イベント駆動のコアアーキテクチャ（Push通知 / Pub/Sub）は各システムの設計を維持し、gws はその内部処理・補助ツールとして組み込む。

3. Mitsumori（見積管理）への応用

詳細: docs/Tatekan/mitsumori/mitsumori_infra_design.md §12

アーキテクチャ上の注意: Gmail API Push + Pub/Sub（常時待ち受け）は引き続き必要。gws はイベント発火後の処理ロジック（Cloud Run worker内）で使用する。

4. Toriteki（受発注・納品・検収進行）への応用

4.1 下請け業者からの成果物（納品書・報告書）自動回収

シナリオ: 下請け業者がToriteki画面を使わずメールに納品書PDFを添付して送信してきた場合。

# Cloud Run内でのイメージ
gws gmail users messages get --userId=me --id={messageId} \
  --format=full | jq '.payload.parts[] | select(.mimeType=="application/pdf")'
# → 添付抽出 → GCS保存 → Toriteki納品ステータス自動更新

優先度: 高

4.2 やり直し依頼・エスカレーション自動化

シナリオ: 検収で不備があった場合、下請け業者へ修正依頼を送信。一定期間返信がない場合、社内マネージャーへエスカレーション。

# やり直し依頼メール送信
gws gmail users messages send --userId=me \
  --subject="【要対応】検収不備について" --to={vendor_email}

# 返信チェック（定期バッチ）
gws gmail users messages list --userId=me \
  --q="from:{vendor_email} after:{sent_date}" | jq '.resultSizeEstimate'
# → 0件なら Google Chat / メールでマネージャーへアラート

優先度: 中

4.3 発注書・検収書のセキュアな証跡保存（取適法・フリーランス新法対応）

シナリオ: 取引適正化法・フリーランス保護新法に対応するため、交付した書面をGoogle Driveに改ざん防止状態で長期保管。

# 指定フォルダへ保存（編集不可権限）
gws drive files create --name="発注書_{order_no}.pdf" \
  --parents={ORDER_ARCHIVE_FOLDER_ID} --uploadType=multipart

# 閲覧のみ権限付与（改ざん防止）
gws drive permissions create --fileId={file_id} \
  --role=reader --type=domain

優先度: 高（法令対応）

5. TATEKAN Core（案件・契約・売上・請求・会計連携）への応用

5.1 売上・請求データの経営ダッシュボード連携

シナリオ: 経営層・営業部門がBigQueryを直接叩かずにリアルタイムな売上実績をスプレッドシートで確認。

# BigQuery集計結果をスプレッドシートに日次出力
gws sheets spreadsheets values update \
  --spreadsheetId={DASHBOARD_SHEET_ID} \
  --range="売上実績!A1" --valueInputOption=RAW \
  --values="$(bq query --format=json '...' | jq '[...]')"

優先度: 中（BIツール導入前の軽量ダッシュボードとして有効）

5.2 契約・請求アラートの自動化

シナリオ: 未入金の請求が一定日数経過 / 高額契約が発生した際、担当者・経理に自動通知。

gws gmail users messages send --userId=me \
  --to={accountant_email} \
  --subject="【未入金アラート】{client_name} {amount}円 {due_date}超過"

優先度: 低（TATEKAN Core実装後に検討）

5.3 請求書PDFのDrive自動分類・権限管理

シナリオ: 顧客に発行した請求書の控えを顧客別・年月別フォルダに自動整理し、経理担当者のみアクセス可能にする。

# 年月・顧客フォルダを動的作成
gws drive folders create --name="{YYYY-MM}_{client_code}" \
  --parents={INVOICE_ROOT_FOLDER_ID}

# 請求書PDF保存
gws drive files create --name="請求書_{invoice_no}.pdf" \
  --parents={folder_id}

# 経理グループにのみ閲覧権限
gws drive permissions create --fileId={file_id} \
  --role=reader --type=group --emailAddress=keiri@godosangyo.com

優先度: 中

6. 実装優先度ロードマップ

7. 技術的共通事項

7.1 認証設計

Service Account: gws-automation-sa@gobms-465809.iam.gserviceaccount.com
→ Domain-Wide Delegation 設定（Google Workspace 管理コンソール）
→ Impersonation: gems-admin@godosangyo.com

7.2 Cloud Run 内での使用方法

# Dockerfile への追加
RUN curl -sSL https://github.com/nicholasgasior/gws-cli/releases/latest/download/gws-linux-amd64 \
    -o /usr/local/bin/gws && chmod +x /usr/local/bin/gws
# ※ 正式インストール方法は公式ドキュメントを参照

7.3 AIエージェント（ClaudeCode）との連携

MCP Server 経由で gws を直接操作可能: - 開発・テスト時: ClaudeCodeがメール取得テスト・ラベル付与テストを自律実行 - QA自動化: Playwright MCP + gws を組み合わせたE2Eテスト

8. 未解決事項

• [ ] gws の正式インストール方法・Cloud Run対応バイナリの確認
• [ ] Domain-Wide Delegation の設定（Google Workspace 管理者権限が必要）
• [ ] 取適法対応 Drive フォルダ構造の詳細設計（保存期間・アクセス権限の法令要件確認）
• [ ] TATEKAN Core の実装スコープ確定後に優先度を見直し

本文書はGeminiCLI調査（2026-03-12）結果をClaudeCodeが統合・構造化して作成。