TATEKAN Time Concept Brief

Date: 2026-03-13 JST Status: 市場調査完了 / コンセプト整合中 — PM y/n 確認待ち 前版: TATEKAN Kintai（仮称）→ PM決定により TATEKAN Time に正式改訂

1. Decision Summary

• サービス名: TATEKAN Time（PM 決定）
• 短縮名: Time（内部略称）
• ビルメン業（設備・清掃・警備・事務職）向けのマルチテナント対応勤怠管理システムとして TATEKANOS プラットフォームに追加する。
• 設計の基本線は マルチテナント前提・Google Workspace 非依存 としつつ、First Tenant は合同産業 として要件を具体化する。
• 対象業務は 打刻管理 / シフト管理 / 申請承認 / 給与計算連携 の 4 カテゴリ。
• テナント構成は TATEKAN Control と連携し、既存 NOS スタック（Core / Toriteki / Mitsumori）と並立する新サービス区画として位置づける。
• 市場調査の結果、ShiftMAX（ビルメン特化・月3万円〜） が唯一の近似競合だが、TATEKAN Time は「TATEKANOS 統合 + クラウドネイティブ + 低価格帯」で明確な差別化ポジションを確保できる。
• シフト表を正本 とし、Google Calendar は必要な場合のみ補助的な import / sync 先として扱う。

2. Why It Is Needed

2.1 業界の構造的課題

ビルメン業界は 人件費率 57.7%・警備員の 52.7% が 60 歳以上 という労働集約型業種であり、勤怠管理は「利益率 0.5% の世界で最も原価に直結する業務」の一つである。

現状の課題:

2.2 NOS に勤怠が欠けている理由

tatekan_industry_os_vision.md の 5 層アーキテクチャでは、シフト AI は Phase C（12〜24 ヶ月先）に位置づけられているが、これは「AI による最適化」が後段であるという意味であり、基盤となる打刻・シフト・申請承認データの収集は Phase A から始める必要がある。

AI Agent Hub（Layer 5）の「シフト AI: 人員配置最適化」は、勤怠管理の生データなしには実現しない。TATEKAN Time はそのデータ基盤を担う。

2.3 Toriteki との補完関係

Toriteki は「元請け→協力会社への発注・検収・作業報告」を扱うが、作業員の勤怠（出勤・退勤・現場滞在時間）は管理しない。TATEKAN Time はこのギャップを埋め、作業報告と勤怠記録を紐づけることで現場別原価管理精度を高める。

3. Product Position

TATEKAN Time は:

• ビルメン業界の多現場・多職種（清掃・設備・警備・事務）に対応した勤怠管理サービス
• TATEKANOS の一サービス区画として TATEKAN Control で有効化されるオプション
• 打刻→シフト→申請承認→給与連携の エンドツーエンドの勤怠フロー を担う
• dMemo と近接連携し、日次業務メモと終業打刻の接続を可能にする

TATEKAN Time は以下ではない:

• 給与計算エンジン本体（外部給与システムとの連携 I/F までが責務）
• 人事システム・採用管理・評価管理
• Toriteki の発注・検収・作業報告フローの置き換え

4. 対象業界の勤務パターン

4.1 合同産業（最初のテナント）の 4 職種

4.2 商マネ社（三井不動産商業マネジメント社）管理建物の勤務スタッフ

• 合同産業は商マネ社管理の大規模施設に管理受託業者として社員を配置している
• 全国統一の決まった勤務パターンがあり、全国からシフト表を収集中（2026-03-13 現在）
• TATEKAN Time では商マネ社向けシフトテンプレートを全国統一パターンとして登録できる設計が必要

4.3 全職種の出勤場所モデル（PM 確認済み 2026-03-13）

primary_site_id をスタッフマスタに登録し、BLE 検知は登録済み現場のビーコンに限定して処理する。

4.4 複数現場掛け持ちの管理要件

清掃スタッフが同日に A 現場（06:00-09:00）と B 現場（10:00-14:00）を掛け持ちするケース（primary_site_id 外への出勤）では: - 同日の複数打刻を合算して1日の実労働時間を計算 - 現場ごとの滞在時間を個別記録（原価配賦のため） - 合計が8h超の場合に時間外として自動認識

5. 法的要件対応方針

5.0 シフト表正本と実績分離

• shift table = plan、clock/application/approval = actual、payroll ledger = approved result の 3 層で扱う
• 発注元へ提出する月次シフト表を plan の正本とし、怪我・病欠・交代・欠員などの臨時変更は actual 側で履歴管理する
• Google Calendar は正本ではなく、必要時に plan を配信する補助チャネルとして扱う
• 給与計算に直結する出勤簿・休暇情報はセンシティブ情報として扱い、厳格な権限分離・監査ログ・変更履歴を必須とする

5.1 変形労働時間制

5.2 36協定アラート

• 月次時間外が 45h（原則上限）の 80% を超えたらアラート
• 月次時間外が 80h を超えたらエスカレーションアラート
• 年次累計を常時表示（現在値 / 残り時間）

5.3 宿直の労働時間判定（大星ビル管理事件準拠）

宿直勤務タイプでは以下を選択:

5.4 割増賃金の自動計算

打刻時刻から以下のマトリクスを自動適用:

6. Core Features（Phase 1）

6.1 打刻管理

6.2 シフト管理

6.3 申請承認ワークフロー

承認フローは 1 段または 2 段（マネージャー → 管理本部）を設定可能。

6.4 給与計算連携

7. Technical Direction

7.1 推奨スタック

7.2 代替案との比較

7.3 マルチテナント方針

• データ分離: Cloud SQL で tenant_id による行レベル分離（PostgreSQL RLS）
• 大規模テナント: 必要に応じて DB 分離ハイブリッドへ移行
• テナント有効化: TATEKAN Control が time = enabled/disabled を管理
• サービス URL 規則: tatekan.app/time/[tenant_slug]/ または Cloud Run サービス分離（→ Open Questions Q8）
• 外部依存の原則: Google Workspace / Google Calendar / Google Form を前提要件にしない。First Tenant が合同産業でも、他テナントで成立する独立認証・独立勤怠モデルを維持する

8. Competitive Positioning

8.1 競合マップ

8.2 TATEKAN Time の固有価値

1. Toriteki 作業報告 × 打刻記録の連携 → 現場別原価のリアルタイム把握
2. 宿直管理の法的自動判定（大星ビル管理事件準拠）— 汎用 SaaS にはない
3. ビルメン4職種プリセット — 初期設定コストを最小化
4. AI Agent Hub への接続性 — Phase C シフト AI のデータ基盤

9. First Tenant And Future Tenants

9.1 合同産業（最初のテナント）

• 現場: 清掃・設備・警備 の複数現場を管理
• 想定利用者:
• 現場スタッフ（打刻）
• 現場マネージャー（シフト・承認）
• 管理本部（給与連携・レポート）
• 初期フェーズで最も価値を出せる機能: 打刻 + シフト管理（4職種プリセット）+ 月次集計 CSV 出力

9.2 将来テナントのパターン

10. Open Questions（PM 判断待ち）

11. TATEKANOS 5 層アーキテクチャ内の位置づけ

┌──────────────────────────────────────────────────────────┐
│  Layer 5: AI Agent Hub                                    │
│  - シフト AI: 人員配置最適化（Time データが前提）          │
│  - 原価 AI: 労務費リアルタイム監視（Time × Core 連携）    │
├──────────────────────────────────────────────────────────┤
│  Layer 4: Web3 Trust（将来 optional）                     │
├──────────────────────────────────────────────────────────┤
│  Layer 3: TATEKAN Control                                 │
│  - Time = enabled / disabled をテナントごとに制御         │
├──────────────────────────────────────────────────────────┤
│  Layer 2: Business Apps                                   │
│  ┌──────────┬───────────┬────────────┬─────────────┐    │
│  │ Core     │ Toriteki  │ Mitsumori  │    Time     │    │
│  │ 物件管理 │ 協力会社  │ 清掃積算   │  打刻管理   │    │
│  │ 契約管理 │ 発注管理  │ 設備積算   │  シフト管理  │    │
│  │ 請求入金 │ 作業報告  │ 警備積算   │  申請承認   │    │
│  │ 物件損益 │ 検収管理  │ 帳票出力   │  給与連携   │    │
│  └──────────┴───────────┴────────────┴─────────────┘    │
│           ↑ 作業報告 × 打刻の原価連携 ↑                   │
├──────────────────────────────────────────────────────────┤
│  Layer 1: Cloud Run / Cloud SQL / GCS / tatekan.app      │
└──────────────────────────────────────────────────────────┘

12. フェーズ並行化計画（PM 決定 2026-03-13）

BLE ビーコン調達に時間を要するため、開発と調達を並行して進める。

→ Track B 完了を待たずに Track A を進める。ビーコン未到着でも打刻 UI は稼働可能な設計とする。

13. Next Actions

1. [ ] Open Questions Q2〜Q8 の PM 決定を受ける
2. [ ] GitHub Issue 作成 + carryover ラベル付与
3. [ ] docs/orders/ACTIVE.json に tatekan-time 追加
4. [ ] Phase 1 要件定義（kintai_requirements.md）の着手（Mitsumori 形式に倣う）
5. [ ] domain_entity_service_mapping.md に TATEKAN Time エンティティのリンク節を追加
6. [ ] BLE ビーコン調達先リスト作成（Track B キックオフ）

14. PM 口頭決定メモ（2026-03-13 追記）

• First Tenant は合同産業だが、設計思想は最初からマルチテナント前提で固定する
• Google Workspace ありきで考えない。Google Calendar / Google Form は移行補助や補助同期の対象に留める
• 勤怠の正本は シフト表 とし、提出用の月次シフト表を基軸に運用する
• 臨時変更（怪我・病欠・交代・欠員など）に耐えるよう、予定と実績を明確に分離する
• 休憩打刻は合同産業では不要だが、Time 全体では tenant option として保持する
• AI が先に月次シフトの下書きを出し、本人は OK なら何も触らない導線を基本にする
• AI native を志向しつつも、人間が安心できる最小限の確認 UI（シフト表、マスター確認、差分修正）を残す
• Time の近接連携先はまず dMemo とする
• 出勤簿は給与直結データ、休暇はセンシティブ情報であるため、情報管理の徹底と曖昧な実装の排除を必須とする

作成: ClaudeCode 2026-03-13 JST 形式参照: docs/Tatekan/control/tatekan_control_concept_brief.md 市場調査参照: docs/Tatekan/kintai/kintai_market_research.md 旧仮称 Kintai → TATEKAN Time（PM決定 2026-03-13）

ShiftMAX 分析 + TATEKAN Time API 連携設計

Date: 2026-03-13 JST Status: 参考資料 — 設計指針として使用 目的: ShiftMAX の「いいとこどり」転用方針と外部 API 連携設計を統合した設計参照文書

1. ShiftMAX とは

株式会社グッドサイクルシステム（大阪）が開発・販売するビルメンテナンス/警備/清掃業界向けシフト管理 SaaS。

• 対象: ビルメン・警備・清掃・設備管理（50〜500名規模）
• 位置づけ: 汎用勤怠 SaaS では対応困難な「業界特有の複雑シフト」に特化
• URL: https://shiftmax.jp（株式会社グッドサイクルシステム）

2. ShiftMAX の機能詳細分析

2.1 自動シフト生成エンジン（最大の差別化）

ShiftMAX の核心は業界特化型の自動シフト生成ロジックにある。

2.2 宿直/夜勤のネイティブ対応（汎用 SaaS との最大差異）

汎用 SaaS では「ワークアラウンド」が必要な宿直を、ShiftMAX はファーストクラスのシフトコードとして扱う。

宿直シフトの流れ（ShiftMAX での表現）:
  Day 1 08:30  → 出勤（日勤帯入）
  Day 1 17:30  → 日勤終了
  Day 1 17:30  → 宿直入（シフトコード切替）
  Day 2 08:30  → 宿直明け（退勤）
  Day 3        → 休み（明け休）

• 宿直・日直・宿直明けが独立したシフトコードとして定義済み
• 拘束時間・実働時間・仮眠時間を別フィールドで管理
• 法定休日/所定休日の区別を自動判定

2.3 変形労働時間制対応

2.4 打刻方式

2.5 有給・申請ワークフロー

• 有給申請 → スタッフ: アプリ送信 → 管理者: Web 承認
• 代替シフト自動提案: 有給承認時に同現場・同スキルの代替スタッフを自動リストアップ
• 有給残日数のリアルタイム表示（スタッフ・管理者双方）

2.6 現場別原価集計

ShiftMAX の隠れた強み。ビルメン特有の「顧客請求管理」との連動:

• 現場別・スタッフ別の実働時間を集計
• 工数 × 単価 = 請求可能コストの計算
• 弥生給与・PCA給与・給与奉行 への CSV 出力

3. ShiftMAX の UI/UX 設計パターン

3.1 画面構成

左サイドバー（ナビ）
├── シフト管理
│   ├── 月次シフト表（メイン画面）
│   └── 現場ビュー
├── 勤怠管理
├── 有給管理
├── マスタ管理
└── レポート

パンくず: 会社 > エリア > 現場

3.2 月次シフト表ビュー（メイン画面）

         1  2  3  4  5  6  7 ... 31
山田太郎 [日][日][宿][明][休][日][日]
鈴木花子 [早][─][日][日][夜][─][早]
田中一郎 [─][警][警][警][明][休][警]

• 行 = スタッフ、列 = 日付、セル = シフト種別（色分け）
• 欠員セルは赤背景でハイライト
• セルクリックでシフト種別の変更ダイアログ

3.3 管理者ダッシュボード

3.4 モバイル対応

3.5 Time へ転用すべき画面原則

ShiftMAX から Time に直接学ぶべきなのは、色や表現ではなく 画面構造そのもの である。

• 月次シフト表を主画面にする
• 行 = スタッフ、列 = 日付、セル = 勤務種別の構造を崩さない
• 責任者は「不足・競合・欠員・未確認」だけを見られる別面を持つ
• 個人は毎回入力するのではなく、AI下書きの確認者 として扱う
• AI native を志向しても、最終的には人が見慣れた 表 と 一覧 に着地させる
• Time は AIが考える / 人が確認して選ぶ / 手入力は最後 を dMemo と共通原則にする

4. ShiftMAX の価格・弱点

4.1 価格体系（2024-2025 推定）

30日無料トライアルあり。電話・メールサポート込み。

4.2 弱点・制約

5. TATEKAN Time への「いいとこどり」転用方針

5.1 転用マトリクス

5.2 Phase 1 UX 設計方針（ShiftMAX ベースト）

ShiftMAX のメイン画面レイアウトを TATEKAN Time に採用:

月次シフト表（カレンダーグリッド）を主入口として採用
├── 行 = スタッフ（現場でフィルタ）
├── 列 = 日付
├── セル = シフトテンプレート（色分け）
│   - 日勤:  青
│   - 宿直:  紺
│   - 明け:  水色
│   - 休み:  グレー
│   - 欠員:  赤（アラート）
└── サイドパネル: 当日の現場別配置状況

モバイル管理者対応（ShiftMAX の弱点を克服）:
- スワイプでスタッフ切替
- タップでシフト変更ダイアログ
- プッシュ通知: 申請・欠員アラート

6. 外部 API 連携設計

6.1 連携システム比較

6.2 弥生給与 CSV（最優先・中小企業の現実解）

フォーマット仕様:
  - 文字コード: Shift-JIS（UTF-8 不可）
  - 改行: CR+LF
  - ヘッダ行: あり（固定項目名）

主要フィールド:
  社員コード, 支給区分, 支給/控除コード,
  出勤日数, 実労働時間, 時間外時間, 深夜時間, 休日出勤時間,
  金額（割増計算済み）

6.3 freee work_record_segments（清掃掛け持ちに最適）

{
  "employee_id": 123,
  "date": "2026-03-01",
  "segments": [
    {
      "clock_in_at": "2026-03-01T06:00:00+09:00",
      "clock_out_at": "2026-03-01T09:00:00+09:00",
      "work_place": "A現場"
    },
    {
      "clock_in_at": "2026-03-01T10:00:00+09:00",
      "clock_out_at": "2026-03-01T14:00:00+09:00",
      "work_place": "B現場"
    }
  ]
}

TATEKAN Time の内部データモデルはこの構造を採用する。

6.4 TATEKAN Time 自身の API 設計

# 認証
OAuth2 PKCE（企業向け）/ API キー（Server-to-Server）

# 打刻セグメント（freee 準拠・拡張）
POST /api/v1/tenants/{tenant_id}/clock_events
GET  /api/v1/tenants/{tenant_id}/work_record_segments/{date}

# 日次集計（給与連携出力用）
GET  /api/v1/tenants/{tenant_id}/daily_summaries/{year_month}
→ 実働/残業/深夜/休日出勤/割増区分 を JSON で返す

# 給与連携エクスポート（フォーマット自動変換）
GET  /api/v1/tenants/{tenant_id}/payroll_export/{year_month}
     ?format=freee|mf|yayoi_csv

# 宿直勤務
POST /api/v1/tenants/{tenant_id}/overnight_shifts
{
  "employee_id": "...",
  "date": "2026-03-01",
  "standby_type": "standby_obligated|standby_released|incident_only",
  "start_at": "2026-03-01T08:30:00+09:00",
  "end_at": "2026-03-02T08:30:00+09:00",
  "sleep_periods": [
    {"from": "2026-03-01T23:00:00+09:00", "to": "2026-03-02T05:00:00+09:00"}
  ]
}

# Webhook（締め処理・承認イベント）
POST {callback_url}
{
  "event": "monthly_close_completed|leave_approved|overtime_limit_warning",
  "tenant_id": "...",
  "payload": {...}
}

6.5 実装優先順位

7. 競合ポジショニング（最終版）

                    高価格
                      │
    ShiftMAX ●        │
  （業界特化・高機能）  │
                      │
  ──────────────────────┼────────────────────────
  汎用機能              │              業界特化機能
                      │
  KING OF TIME ●      │       TATEKAN Time ◎
  ジョブカン ●         │     （ここを狙う）
  freee ●             │     ・TATEKANOS統合
                      │     ・API-first
                    低価格    ・クラウドネイティブ

ShiftMAX との差別化サマリ: 1. TATEKANOS 統合（Toriteki 原価連携）— ShiftMAX にはない 2. API-first 公開設計 — ShiftMAX は非公開 3. モバイル管理フル対応 — ShiftMAX はデスクトップ依存 4. 法的判定自動化（宿直） — ShiftMAX は設定ベース 5. 中価格帯 — ShiftMAX より低コストで業界特化機能を提供

8. 合同産業ヒアリング

ヒアリング項目・回答内容は分割ファイルを参照: godo_sangyo_hearing.md（全8項目・PM回答済み 2026-03-13）

作成: ClaudeCode 2026-03-13 JST 参照調査: Background Agent（ShiftMAX深堀り + API連携調査）2026-03-13 関連: godo_sangyo_hearing.md / kintai_market_research.md / kintai_concept_brief.md

TATEKAN Time Concept Brief

Date: 2026-03-13 JST Status: 市場調査完了 / コンセプト整合中 — PM y/n 確認待ち 前版: TATEKAN Kintai（仮称）→ PM決定により TATEKAN Time に正式改訂

1. Decision Summary

• サービス名: TATEKAN Time（PM 決定）
• 短縮名: Time（内部略称）
• ビルメン業（設備・清掃・警備・事務職）向けのマルチテナント対応勤怠管理システムとして TATEKANOS プラットフォームに追加する。
• 設計の基本線は マルチテナント前提・Google Workspace 非依存 としつつ、First Tenant は合同産業 として要件を具体化する。
• 対象業務は 打刻管理 / シフト管理 / 申請承認 / 給与計算連携 の 4 カテゴリ。
• テナント構成は TATEKAN Control と連携し、既存 NOS スタック（Core / Toriteki / Mitsumori）と並立する新サービス区画として位置づける。
• 市場調査の結果、ShiftMAX（ビルメン特化・月3万円〜） が唯一の近似競合だが、TATEKAN Time は「TATEKANOS 統合 + クラウドネイティブ + 低価格帯」で明確な差別化ポジションを確保できる。
• シフト表を正本 とし、Google Calendar は必要な場合のみ補助的な import / sync 先として扱う。

2. Why It Is Needed

2.1 業界の構造的課題

ビルメン業界は 人件費率 57.7%・警備員の 52.7% が 60 歳以上 という労働集約型業種であり、勤怠管理は「利益率 0.5% の世界で最も原価に直結する業務」の一つである。

現状の課題:

2.2 NOS に勤怠が欠けている理由

tatekan_industry_os_vision.md の 5 層アーキテクチャでは、シフト AI は Phase C（12〜24 ヶ月先）に位置づけられているが、これは「AI による最適化」が後段であるという意味であり、基盤となる打刻・シフト・申請承認データの収集は Phase A から始める必要がある。

AI Agent Hub（Layer 5）の「シフト AI: 人員配置最適化」は、勤怠管理の生データなしには実現しない。TATEKAN Time はそのデータ基盤を担う。

2.3 Toriteki との補完関係

Toriteki は「元請け→協力会社への発注・検収・作業報告」を扱うが、作業員の勤怠（出勤・退勤・現場滞在時間）は管理しない。TATEKAN Time はこのギャップを埋め、作業報告と勤怠記録を紐づけることで現場別原価管理精度を高める。

3. Product Position

TATEKAN Time は:

• ビルメン業界の多現場・多職種（清掃・設備・警備・事務）に対応した勤怠管理サービス
• TATEKANOS の一サービス区画として TATEKAN Control で有効化されるオプション
• 打刻→シフト→申請承認→給与連携の エンドツーエンドの勤怠フロー を担う
• dMemo と近接連携し、日次業務メモと終業打刻の接続を可能にする

TATEKAN Time は以下ではない:

• 給与計算エンジン本体（外部給与システムとの連携 I/F までが責務）
• 人事システム・採用管理・評価管理
• Toriteki の発注・検収・作業報告フローの置き換え

4. 対象業界の勤務パターン

4.1 合同産業（最初のテナント）の 4 職種

4.2 商マネ社（三井不動産商業マネジメント社）管理建物の勤務スタッフ

• 合同産業は商マネ社管理の大規模施設に管理受託業者として社員を配置している
• 全国統一の決まった勤務パターンがあり、全国からシフト表を収集中（2026-03-13 現在）
• TATEKAN Time では商マネ社向けシフトテンプレートを全国統一パターンとして登録できる設計が必要

4.3 全職種の出勤場所モデル（PM 確認済み 2026-03-13）

primary_site_id をスタッフマスタに登録し、BLE 検知は登録済み現場のビーコンに限定して処理する。

4.4 複数現場掛け持ちの管理要件

清掃スタッフが同日に A 現場（06:00-09:00）と B 現場（10:00-14:00）を掛け持ちするケース（primary_site_id 外への出勤）では: - 同日の複数打刻を合算して1日の実労働時間を計算 - 現場ごとの滞在時間を個別記録（原価配賦のため） - 合計が8h超の場合に時間外として自動認識

5. 法的要件対応方針

5.0 シフト表正本と実績分離

• shift table = plan、clock/application/approval = actual、payroll ledger = approved result の 3 層で扱う
• 発注元へ提出する月次シフト表を plan の正本とし、怪我・病欠・交代・欠員などの臨時変更は actual 側で履歴管理する
• Google Calendar は正本ではなく、必要時に plan を配信する補助チャネルとして扱う
• 給与計算に直結する出勤簿・休暇情報はセンシティブ情報として扱い、厳格な権限分離・監査ログ・変更履歴を必須とする

5.1 変形労働時間制

5.2 36協定アラート

• 月次時間外が 45h（原則上限）の 80% を超えたらアラート
• 月次時間外が 80h を超えたらエスカレーションアラート
• 年次累計を常時表示（現在値 / 残り時間）

5.3 宿直の労働時間判定（大星ビル管理事件準拠）

宿直勤務タイプでは以下を選択:

5.4 割増賃金の自動計算

打刻時刻から以下のマトリクスを自動適用:

6. Core Features（Phase 1）

6.1 打刻管理

6.2 シフト管理

6.3 申請承認ワークフロー

承認フローは 1 段または 2 段（マネージャー → 管理本部）を設定可能。

6.4 給与計算連携

7. Technical Direction

7.1 推奨スタック

7.2 代替案との比較

7.3 マルチテナント方針

• データ分離: Cloud SQL で tenant_id による行レベル分離（PostgreSQL RLS）
• 大規模テナント: 必要に応じて DB 分離ハイブリッドへ移行
• テナント有効化: TATEKAN Control が time = enabled/disabled を管理
• サービス URL 規則: tatekan.app/time/[tenant_slug]/ または Cloud Run サービス分離（→ Open Questions Q8）
• 外部依存の原則: Google Workspace / Google Calendar / Google Form を前提要件にしない。First Tenant が合同産業でも、他テナントで成立する独立認証・独立勤怠モデルを維持する

8. Competitive Positioning

8.1 競合マップ

8.2 TATEKAN Time の固有価値

1. Toriteki 作業報告 × 打刻記録の連携 → 現場別原価のリアルタイム把握
2. 宿直管理の法的自動判定（大星ビル管理事件準拠）— 汎用 SaaS にはない
3. ビルメン4職種プリセット — 初期設定コストを最小化
4. AI Agent Hub への接続性 — Phase C シフト AI のデータ基盤

9. First Tenant And Future Tenants

9.1 合同産業（最初のテナント）

• 現場: 清掃・設備・警備 の複数現場を管理
• 想定利用者:
• 現場スタッフ（打刻）
• 現場マネージャー（シフト・承認）
• 管理本部（給与連携・レポート）
• 初期フェーズで最も価値を出せる機能: 打刻 + シフト管理（4職種プリセット）+ 月次集計 CSV 出力

9.2 将来テナントのパターン

10. Open Questions（PM 判断待ち）

11. TATEKANOS 5 層アーキテクチャ内の位置づけ

┌──────────────────────────────────────────────────────────┐
│  Layer 5: AI Agent Hub                                    │
│  - シフト AI: 人員配置最適化（Time データが前提）          │
│  - 原価 AI: 労務費リアルタイム監視（Time × Core 連携）    │
├──────────────────────────────────────────────────────────┤
│  Layer 4: Web3 Trust（将来 optional）                     │
├──────────────────────────────────────────────────────────┤
│  Layer 3: TATEKAN Control                                 │
│  - Time = enabled / disabled をテナントごとに制御         │
├──────────────────────────────────────────────────────────┤
│  Layer 2: Business Apps                                   │
│  ┌──────────┬───────────┬────────────┬─────────────┐    │
│  │ Core     │ Toriteki  │ Mitsumori  │    Time     │    │
│  │ 物件管理 │ 協力会社  │ 清掃積算   │  打刻管理   │    │
│  │ 契約管理 │ 発注管理  │ 設備積算   │  シフト管理  │    │
│  │ 請求入金 │ 作業報告  │ 警備積算   │  申請承認   │    │
│  │ 物件損益 │ 検収管理  │ 帳票出力   │  給与連携   │    │
│  └──────────┴───────────┴────────────┴─────────────┘    │
│           ↑ 作業報告 × 打刻の原価連携 ↑                   │
├──────────────────────────────────────────────────────────┤
│  Layer 1: Cloud Run / Cloud SQL / GCS / tatekan.app      │
└──────────────────────────────────────────────────────────┘

12. フェーズ並行化計画（PM 決定 2026-03-13）

BLE ビーコン調達に時間を要するため、開発と調達を並行して進める。

→ Track B 完了を待たずに Track A を進める。ビーコン未到着でも打刻 UI は稼働可能な設計とする。

13. Next Actions

1. [ ] Open Questions Q2〜Q8 の PM 決定を受ける
2. [ ] GitHub Issue 作成 + carryover ラベル付与
3. [ ] docs/orders/ACTIVE.json に tatekan-time 追加
4. [ ] Phase 1 要件定義（kintai_requirements.md）の着手（Mitsumori 形式に倣う）
5. [ ] domain_entity_service_mapping.md に TATEKAN Time エンティティのリンク節を追加
6. [ ] BLE ビーコン調達先リスト作成（Track B キックオフ）

14. PM 口頭決定メモ（2026-03-13 追記）

• First Tenant は合同産業だが、設計思想は最初からマルチテナント前提で固定する
• Google Workspace ありきで考えない。Google Calendar / Google Form は移行補助や補助同期の対象に留める
• 勤怠の正本は シフト表 とし、提出用の月次シフト表を基軸に運用する
• 臨時変更（怪我・病欠・交代・欠員など）に耐えるよう、予定と実績を明確に分離する
• 休憩打刻は合同産業では不要だが、Time 全体では tenant option として保持する
• AI が先に月次シフトの下書きを出し、本人は OK なら何も触らない導線を基本にする
• AI native を志向しつつも、人間が安心できる最小限の確認 UI（シフト表、マスター確認、差分修正）を残す
• Time の近接連携先はまず dMemo とする
• 出勤簿は給与直結データ、休暇はセンシティブ情報であるため、情報管理の徹底と曖昧な実装の排除を必須とする

作成: ClaudeCode 2026-03-13 JST 形式参照: docs/Tatekan/control/tatekan_control_concept_brief.md 市場調査参照: docs/Tatekan/kintai/kintai_market_research.md 旧仮称 Kintai → TATEKAN Time（PM決定 2026-03-13）