Toriteki Canonical Integration Spec

Date: 2026-03-16 JST Status: DRAFT — ClaudeCode review pending Related Issue: #335

1. Purpose

Toriteki の branch / facility 中心モデルから、canonical department / building へ移行するための Phase 1-2 接続仕様を整理する。

2. Phase 1 Integration Policy

• tatekanos_shared の canonical master model を library として導入する
• Datastore は当面 Toriteki 自身が保持する
• 現行 toriteki_master_org_branches / toriteki_master_org_facilities / operational kinds は即時廃止しない
• まず schema alignment と naming alignment を優先する

3. Mapping Policy

注意:

• これは単なる rename ではない
• branch は営業拠点寄り概念、department は業務統制単位
• facility は現場寄り概念、building は管理対象物件

4. Phase 1 Practical Design

4.1 Department-side

• UI ラベルは当面 branch を残してよい
• 内部 model は canonical department field を持てるようにする
• approval_route_default や default_quotation_expiry は未実装でも field 予約する

4.2 Building-side

• facility は内部的に canonical building field を持つ
• department_code 紐付けを明示する
• key name に名称を入れる legacy パターンから、code ベースへ段階移行する

4.3 Two-layer Structure

• master + operational の二層は Phase 1 では維持してよい
• ただし canonical authority ではないことを明記する
• Phase 2 で Core authority 導入後、Toriteki の local master は replica / operational support として見直す

5. Canonical Reference Usage

Toriteki が将来参照する canonical master:

• department: 発注主体 / 履行主体 / テナント内組織
• building: execution unit の対象物件
• business_code: RFQ / 発注 / 履行分類
• supplier: pure supplier master

原則:

• commercial_context は Toriteki で正本化しない
• Toriteki は building × business_code 粒度の実行を前提に設計する

6. Future Core Integration Points (Phase 2)

6.1 Read Path

• Core master の検索・参照
• inactive / archived 判定の統一
• tenant scoped lookup

6.2 Write Path

• Toriteki から branch/facility を authority write しない
• 必要な master 更新は Core API 経由とする
• local master 更新は migration 期間中の互換運用に限定する

6.3 Migration Path

1. current branch/facility に canonical field を追加
2. UI / route / export の参照先を canonical alias 対応
3. Core authority 導入後に write stop
4. legacy route を縮退

7. Known Gaps

• operational 側 key name = entity name パターンの廃止時期
• vice_owner_name のような master-only field の同期方法
• /admin/branches 等の legacy route 廃止順
• supplier master と現行 vendor/supplier 運用拡張の境界

Toriteki マスター管理 再実装仕様書

• 文書バージョン: 1.0
• 作成日: 2026-02-23
• 作成者: ClaudeCode (PLD)
• 承認者: PM SATORU
• ステータス: DRAFT — PM承認待ち

0. 設計方針と背景

0.1 再実装に至る経緯

既存のマスター管理実装（app.py内埋め込み）は以下の問題を抱えていた: - 仕様が曖昧なまま実装が先行し、手戻りが多発 - UX/UIガイドラインを参照せず、カテゴリ間でデザインが不統一 - PM承認なしの独断実装によるデグレード頻発 - ブラウザによるユーザー目線の動作確認が行われていない

0.2 PLDの実施ルール（本仕様書に基づく）

1. 本仕様書に書かれていないことは実装しない
2. 各カテゴリの実装前にPMへ計画提示 → y/n承認を得る
3. 実装後は必ずPlaywrightでブラウザ確認し、スクリーンショットをPMへ報告
4. 仕様変更が必要な場合は本仕様書を更新し、PMへ再承認を求める

0.3 参照ガイドライン（正本）

1. アーキテクチャ

1.1 ファイル構成（Blueprint分割）

scripts/toriteki_placeholder_service/
├── app.py                          # メインアプリ（マスター管理コードは削除）
├── admin_master_blueprint.py       # 新設: マスター管理Blueprint
├── templates/
│   └── (テンプレートはapp.py内文字列から移行しない — app.py方式を継続)
└── tests/
    └── test_master_management_routes.py  # 既存テスト更新

注意: テンプレートはFlaskの慣例に従いapp.py内の文字列定数として保持する（既存アーキテクチャとの整合）。Blueprint登録のみ分離する。

# app.py に追加
from admin_master_blueprint import admin_master_bp
app.register_blueprint(admin_master_bp)

# admin_master_blueprint.py
from flask import Blueprint
admin_master_bp = Blueprint('admin_master', __name__)

1.2 データ層

• ストレージ: Google Cloud Datastore（変更なし）
• テナント隔離: tenant_domain:code の複合キーを維持
• 削除方針: 論理削除のみ（active=False）。UIラベルは「無効化」に統一
• 自動同期: 組織マスター保存時に運用テーブルへ自動反映（失敗時はエラー詳細をUIに表示）

2. 共通UX/UIルール

2.1 レイアウト構造（全カテゴリ共通）

┌─────────────────────────────────────────────────┐
│ パンくずリスト: 管理 > マスター管理 > [カテゴリ名] │
├─────────────────────────────────────────────────┤
│ ページヘッダー                                    │
│  タイトル（左）           ガバナンス指標バッジ（右）│
├─────────────────────────────────────────────────┤
│ ① 登録フォーム（カード）                          │
│   - 入力フィールド群                              │
│   - [キャンセル] [登録する]                       │
├─────────────────────────────────────────────────┤
│ ② 一覧テーブル（カード）                          │
│   - 検索フィールド（統一デザイン）                 │
│   - データ行（操作ボタン含む）                    │
└─────────────────────────────────────────────────┘

2.2 フォームデザイン原則

2.3 ボタン設計

破壊的アクション（無効化）の安全設計: - ボタンは赤系アウトライン（btn-outline-danger） - 近隣の他ボタンと22px以上の余白を確保 - クリック時に確認モーダルを表示（UX audit FIND-007対応）

2.4 フィードバック（トースト通知）

位置: 右上固定（top: 1rem; right: 1rem）
表示時間: 成功=3秒, エラー=6秒（自動消去）
色:
  成功 → bg-success（緑）
  エラー → bg-danger（赤）
  警告 → bg-warning（黄）

フラッシュメッセージからトースト表示に統一（ページ最上部への埋め込みは廃止）。

2.5 空状態（Empty State）

一覧テーブルにデータがない場合:

<tr>
  <td colspan="N" class="text-center text-muted py-5">
    <i class="bi bi-inbox fs-1 d-block mb-2"></i>
    まだ登録されていません。上のフォームから登録してください。
  </td>
</tr>

2.6 入力バリデーション

禁止文字（全フィールド共通）: - 半角カナ（U+FF61-FF9F） - 機種依存文字（U+2460-2473, U+2160-216B, U+3200-32FF, U+3300-33FF） - 絵文字（U+1F000+, U+2600-26FF, U+2700-27BF）

正規化: NFKC + トリム（サーバーサイド。クライアントはIME確定後に表示チェックのみ）

エラー表示: フィールド直下に赤色テキストで表示（invalid-feedback）

2.7 フォーカスアクセシビリティ（UX audit FIND-003対応）

:focus-visible {
  outline: 2px solid #1976D2;
  outline-offset: 2px;
  border-radius: 3px;
}

全テンプレートに共通スタイルとして適用。

3. カテゴリ別仕様

3.1 ① 組織マスター（/admin/master/organization）

概要

拠点（Branch）と現場（Facility）を管理する。他のマスター（権限・承認・取引先）が参照する基盤データ。

画面構成

タブ A: 拠点管理
タブ B: 現場管理（拠点登録後に有効）

タブ A: 拠点管理

登録フォーム:

一覧テーブル:

自動同期: 登録・編集時に toriteki_branches へ自動反映。失敗時はエラー詳細をトーストで表示。

ガバナンス指標（ヘッダー右）: - 登録拠点数: N件（有効: N / 無効: N）

タブ B: 現場管理

前提条件: 有効な拠点が1件以上存在すること。未存在時はフォームエリアに「先に拠点を登録してください」を表示。

登録フォーム:

一覧テーブル:

自動同期: 登録・編集時に toriteki_facilities へ自動反映。失敗時はエラー詳細をトーストで表示。

ガバナンス指標: - 登録現場数: N件（有効: N / 無効: N）

3.2 ② 権限マスター（/admin/master/permissions）

概要

ロール（Role）・権限（Permission）・割当（Mapping）を管理する。アクセス制御の根幹。

画面構成

タブ 1: 権限マトリクス（概観）
タブ 2: ロール管理
タブ 3: 権限管理
タブ 4: 割当設定

タブ 1: 権限マトリクス

• 行: 権限（カテゴリ・ソート順で並び替え）
• 列: ロール
• セル: ✓（割当済）/ —（未割当）
• 読み取り専用（編集はタブ4から）
• ロール未登録時: 「ロールを登録してください（タブ2）」ガイドを表示

タブ 2: ロール管理

登録フォーム:

一覧テーブル（有効・無効フィルタ付き）:

タブ 3: 権限管理

登録フォーム:

一覧テーブル（有効・無効フィルタ付き）:

タブ 4: 割当設定

登録フォーム:

ポリシー検証: ロールBand < 権限ポリシー要件の場合、チェックボックスをdisabledにし、理由をツールチップで表示（例: 「この権限はbranch_manager以上が対象です」）。

一覧テーブル:

ガバナンス指標（ヘッダー右）: - ロール数: N件 / 権限数: N件 - 割当済ロール率: N%（プログレスバー）

3.3 ③ 承認マスター（/admin/master/approval）

概要

申請種別（Request Type）と承認ルート（Approval Route）を管理する。

画面構成

タブ A: 申請種別
タブ B: 承認ルート（申請種別登録後に有効）

タブ A: 申請種別

登録フォーム:

一覧テーブル:

タブ B: 承認ルート

前提条件: 有効な申請種別が1件以上存在すること。

登録フォーム:

一覧テーブル:

ガバナンス指標: - 自己承認許可率: N% - 有効ルート数: N件

3.4 ④ 取引先マスター（/admin/master/suppliers）

概要

取引先（Supplier）と拠点マッピング（Supplier-Branch Map）を管理する。

画面構成

タブ A: 取引先
タブ B: 拠点紐付け（取引先・拠点が登録済みの場合に有効）

タブ A: 取引先

登録フォーム:

一覧テーブル:

自動同期: 登録・編集時に toriteki_suppliers へ自動反映。

タブ B: 拠点紐付け

登録フォーム:

重複チェック: 同一組み合わせの登録を拒否。

一覧テーブル:

3.5 ⑤ 会計マスター（/admin/master/accounting）

概要

税区分（Tax Code）・支払条件（Payment Term）・会計コード（Account Code）を管理する。

画面構成

タブ A: 税区分
タブ B: 支払条件
タブ C: 会計コード（税区分・支払条件が登録済みの場合に有効）

タブ A: 税区分

タブ B: 支払条件

タブ C: 会計コード

ガバナンス指標: - 税区分: N件 / 支払条件: N件 / 会計コード: N件

3.6 ⑥ 通知/SLAマスター（/admin/master/notifications）

概要

通知テンプレート（Notification Template）とSLAポリシー（SLA Policy）を管理する。

画面構成

タブ A: 通知テンプレート
タブ B: SLAポリシー（テンプレート登録済みの場合に有効）

タブ A: 通知テンプレート

タブ B: SLAポリシー

4. データ整合性設計（最重要）

4.1 問題の構造

マスター管理は「既存の運用テーブル」と「新設のマスターテーブル」の2層構造を持つ。 この2層の間に以下の構造的な不整合リスクが存在する。

キー体系の不一致（既存 vs マスター経由）

二重存在の影響

• 発注時の facility_key は fac-{SHA1} を参照 → マスター経由の master-{FC} を選択肢に出せない
• 取引先の supplier_id も同様 → マスター経由の取引先が発注で使えない
• 同一の現場・取引先が2つのキーで存在 → データが分裂

4.2 設計方針（PLD決定、PM承認事項）

方針: マスターテーブルが真実の源（Single Source of Truth）

[マスターテーブル] → 一方向同期 → [運用テーブル]
                                     ↑ここを参照
                              発注・承認・ユーザー管理

運用テーブルのキーは既存キーを維持し、マスターからの同期で上書き・更新する。 新規作成時も既存キー生成ロジックと同じ方式を使用することでキーの一致を保証する。

4.3 キー統一設計（実装指針）

4.3.1 拠点（Branch）

マスターキー（toriteki_master_org_branches）: tenant_domain:BR0001
運用キー（toriteki_branches）: 拠点名文字列（例: "首都圏支店"）
同期: branch_name フィールドで一意特定 → 既存エンティティを上書き更新

安全設計: - 拠点名変更時は旧名の運用エンティティに is_archived=True をセットし、新名で新規作成 - 拠点名は変更不可（変更する場合は無効化→新規登録フローを案内）

4.3.2 現場（Facility）

マスターキー（toriteki_master_org_facilities）: tenant_domain:FC0001
運用キー（toriteki_facilities）: fac-{SHA1[:16]}（ブランチ名+住所+施設名のハッシュ）
同期: マスター登録時に同じSHA1ハッシュ式でキーを計算 → 既存エンティティを上書き更新

実装要件:

# マスター→運用同期時のキー生成（既存ロジックと完全一致）
import hashlib
digest = hashlib.sha1(
    f"{branch_name}|{address}|{facility_name}".encode()
).hexdigest()
op_key = f"fac-{digest[:16]}"

安全設計: - 施設名・住所・拠点名の変更は SHA1 が変わるため、旧キーのエンティティを残しつつ新キーで作成し is_archived=True に設定 - 現場の住所フィールドはマスターテーブルの toriteki_master_org_facilities に追加（現仕様書に追記） - マスターの facility_code（FC0001）と運用の fac-{SHA1} キーを master_code フィールドで紐付け

4.3.3 取引先（Supplier）

マスターキー（toriteki_master_suppliers）: tenant_domain:SP0001
運用キー（toriteki_suppliers）: 既存データは tok-1234 等、新規は master-{sp0001}

既存データの問題: 既存取引先（tok-1234 等）はマスター管理画面に表示されない。 「取り込み機能」（後述 §4.5）でマスターテーブルに吸い上げ、master_code を付与する。

新規登録分: マスター経由の新規取引先は master-{sp0001} キーで作成。発注・現場選択UIはこのキーを正しく参照できるため問題なし。

4.4 テナント別の導線設計

4.4.1 既存テナント（合同産業株式会社）の初期化フロー

Step 1: マスター管理画面を初回開いたとき
  → 既存データの検出: master_source フィールドがない運用テーブルレコードを検索
  → 「未取込データあり」バナーを表示

Step 2: 管理者が「既存データを取り込む」ボタンをクリック
  → toriteki_branches の全レコードをマスターテーブルに自動インポート
     （branch_code=BR0001, BR0002... を自動採番し、master_codeを設定）
  → toriteki_facilities の全レコードをマスターテーブルに自動インポート
     （facility_code=FC0001... を自動採番）
  → 運用テーブルの各レコードに master_source="organization_master", master_code=XXX を書き込み

Step 3: 取込完了後、マスター管理画面でデータを確認・編集可能

取り込み時の重複防止: - master_source == "organization_master" がすでに設定済みのレコードはスキップ - 同一拠点名・施設名がマスターに既存であれば上書きインポートしない（警告表示）

4.4.2 新規テナントの初期化フロー

オンボーディングウィザード Step 2（拠点登録）
  → 拠点を登録すると toriteki_branches に書き込み（既存フロー維持）
  → 同時に toriteki_master_org_branches にも BR0001 として登録（新規追加）
  → master_source="organization_master", master_code="BR0001" を運用テーブルに書き込み

→ マスター管理画面を初回開いたとき、既に拠点が1件登録済みで表示される
→ 「未取込データあり」バナーは表示されない

4.5 既存データ取込機能（Import）の仕様

エンドポイント:

POST /admin/master/organization/import-existing   → 既存データの一括取込
GET  /admin/master/organization                   → 取込状況バナー表示

取込対象: - toriteki_branches（master_source 未設定のもの）→ マスター拠点として登録 - toriteki_facilities（master_source 未設定のもの）→ マスター現場として登録 - toriteki_suppliers（master_source 未設定のもの）→ マスター取引先として登録

取込画面のUI:

┌─────────────────────────────────────────────────────┐
│ ⚠️ 未取込の既存データが検出されました                  │
│                                                     │
│  拠点: N件 / 現場: N件 / 取引先: N件                  │
│                                                     │
│  マスター管理の対象とするには取込が必要です。           │
│  取込後もデータは変更されません（読取→登録のみ）        │
│                                                     │
│  [詳細を確認] [一括取込を実行]                        │
└─────────────────────────────────────────────────────┘

取込後の保証: - 既存データは削除・変更しない（読み取って、マスターテーブルに登録するのみ） - 運用テーブルの master_source, master_code フィールドを追記 - 取込ログを toriteki_master_audit_history に記録

4.6 他機能との連動一覧

マスターデータを変更した際に影響を受ける機能と、その安全設計:

4.7 マスターテーブルへの追加フィールド

調査の結果、現場マスターに住所フィールドが欠如していることが判明。以下を追加:

toriteki_master_org_facilities への追加フィールド:

これにより fac-{SHA1[:16]} キーの再現が可能になる。

6. マスター管理トップページ（/admin/master）

6カテゴリをカードグリッドで表示。各カードには: - カテゴリ名・説明 - 登録件数バッジ（有効件数） - 「開く」ボタン

7. データモデル（Datastoreエンティティ）

既存のエンティティ種別・キー形式・コード体系を継承（変更なし）:

共通フィールド（全エンティティ）:

{
  "tenant_domain": str,      # テナント識別子
  "code": str,               # エンティティ固有コード
  "active": bool,            # 論理削除フラグ（True=有効）
  "version": int,            # 楽観的ロック用バージョン
  "created_at": datetime,    # 作成日時（UTC）
  "created_by": str,         # 作成者メール
  "updated_at": datetime,    # 更新日時（UTC）
  "updated_by": str,         # 更新者メール
}

8. ルート設計（Blueprint）

6.1 一覧・表示系

GET  /admin/master                              → マスター管理トップ
GET  /admin/master/organization                 → 組織マスター
GET  /admin/master/permissions                  → 権限マスター
GET  /admin/master/approval                     → 承認マスター
GET  /admin/master/suppliers                    → 取引先マスター
GET  /admin/master/accounting                   → 会計マスター
GET  /admin/master/notifications                → 通知/SLAマスター

6.2 CRUD系（カテゴリごとに定義）

全POST系エンドポイントは admin_required() デコレータを付与。

# 組織マスター（既存データ取込）
POST /admin/master/organization/import-existing             → 既存データ一括取込

# 組織マスター
POST /admin/master/organization/branches/save                    → 拠点新規登録
POST /admin/master/organization/branches/<code>/update           → 拠点編集
POST /admin/master/organization/branches/<code>/toggle-active    → 拠点 有効/無効切替
POST /admin/master/organization/facilities/save                  → 現場新規登録
POST /admin/master/organization/facilities/<code>/update         → 現場編集
POST /admin/master/organization/facilities/<code>/toggle-active  → 現場 有効/無効切替

# 権限マスター
POST /admin/master/permissions/roles/save
POST /admin/master/permissions/roles/<code>/toggle-active
POST /admin/master/permissions/permissions/save
POST /admin/master/permissions/permissions/<code>/toggle-active
POST /admin/master/permissions/maps/save
POST /admin/master/permissions/maps/<code>/toggle-active

# 承認マスター
POST /admin/master/approval/request-types/save
POST /admin/master/approval/request-types/<code>/update
POST /admin/master/approval/request-types/<code>/toggle-active
POST /admin/master/approval/routes/save
POST /admin/master/approval/routes/<code>/update
POST /admin/master/approval/routes/<code>/toggle-active

# 取引先マスター
POST /admin/master/suppliers/items/save
POST /admin/master/suppliers/items/<code>/update
POST /admin/master/suppliers/items/<code>/toggle-active
POST /admin/master/suppliers/maps/save
POST /admin/master/suppliers/maps/<code>/toggle-active

# 会計マスター
POST /admin/master/accounting/tax-codes/save
POST /admin/master/accounting/tax-codes/<code>/toggle-active
POST /admin/master/accounting/payment-terms/save
POST /admin/master/accounting/payment-terms/<code>/toggle-active
POST /admin/master/accounting/account-codes/save
POST /admin/master/accounting/account-codes/<code>/toggle-active

# 通知/SLAマスター
POST /admin/master/notifications/templates/save
POST /admin/master/notifications/templates/<code>/toggle-active
POST /admin/master/notifications/sla/save
POST /admin/master/notifications/sla/<code>/toggle-active

9. テスト要件

9.1 各カテゴリ実装後のテストチェックリスト

• [ ] 正常登録（必須項目全入力）→ 成功トースト表示・一覧に反映
• [ ] 必須項目欠落 → エラーメッセージ表示・登録されない
• [ ] 禁止文字入力 → エラーメッセージ表示
• [ ] 無効化 → 確認モーダル表示 → 実行後バッジが「無効」に変化
• [ ] 有効化 → 実行後バッジが「有効」に変化
• [ ] admin以外のアクセス → 403
• [ ] 空状態 → Empty Stateメッセージ表示
• [ ] フォーカス → :focus-visible のアウトライン表示

9.2 データ整合性テスト（組織・取引先マスター実装後に必ず実施）

• [ ] 既存データ取込 → toriteki_branches の全レコードがマスターに反映されること
• [ ] 取込後の運用テーブルに master_source, master_code が設定されること
• [ ] マスターから現場を新規登録 → 発注フォームの現場選択に表示されること（キー一致確認）
• [ ] マスターから取引先を新規登録 → 発注フォームの取引先選択に表示されること
• [ ] 拠点を無効化 → 発注フォームの拠点選択から消えること
• [ ] 同一現場名・拠点・住所でのマスター登録 → 既存運用エンティティを上書き（新規作成しない）こと
• [ ] 取込済みデータに対して再度取込 → スキップされること（重複取込なし）

9.3 Playwright確認項目（実装後に必ず実施）

• スクリーンショット取得してPMへ報告
• デスクトップ（1366×768）とモバイル（390×844）の両方
• フォーム送信フロー（成功・失敗）の動作確認
• 既存テナント（合同産業株式会社）データでの取込フロー確認

10. 実装スケジュール（目安）

各カテゴリの実装前に本仕様書の該当セクションをPMへ提示し、y/n承認を得る。

本仕様書はPM承認後、実装の正本となる。変更が必要な場合はPMへ差分提示して再承認を得ること。

Toriteki 納品・検収・請求フロー 仕様書

作成日: 2026-02-03 (JST) 更新日: 2026-02-10 16:10 JST 作成者: ClaudeCode (PL Deputy) ステータス: 本番検証済み（テスト拠点）- 反映済み

更新メモ: 2026-02-04 の本番テスト（テスト拠点）で自動検収・リマインダー系の動作確認が完了。

関連仕様: - docs/Tatekan/toriteki/toriteki_estimate_phase_spec.md（見積依頼〜採択〜発注自動起票）

1. 概要

発注が受諾された後の「納品→検収→請求」プロセスを管理する機能を設計する。

1.1 前提条件

• 発注ステータス: SENT かつ vendor_status: ACCEPTED
• 受託先がメール経由で納品報告を行う（ログイン不要）
• 発注者が受領・検収を行う（ログイン必須）
• 取適法（中小受託取引適正化法）に準拠

1.2 フロー概要（案B採用: 検収統合フロー）

[受諾済み] → [納品報告待ち] → [納品済み] → [検収完了] → [請求発行] → [支払完了]
  ACCEPTED   AWAITING_REPORT  DELIVERED    INSPECTED    INVOICED      PAID

PM決定（2026-02-03）: - 基本は案B（受領と検収を統合、検収のみ） - 物品の場合のみ、検収時に「納品請書も同時に発行」オプションあり

2. 取適法準拠：支払期日ルール（PM決定: 2026-02-03）

2.1 法的要件

2.2 発注タイプと起算日

2.3 デフォルト支払条件

月末締め・翌月末現金払い

→ 全ケースで60日以内

2.4 見積書の支払条件対応（案1採用）

2.5 検収不合格・やり直し時の起算日

やり直しの条件: - 受託先の責任による不備・不具合が明確な場合のみ - 発注者都合の一方的な変更は禁止 - 不良品の返品は「受領後速やかに」行う必要あり

3. ステータス定義

3.1 delivery_status（納品ステータス）- 案B統合フロー

注: 案B採用により RECEIVED は廃止。検収時に受領も兼ねる。

3.2 billing_status（請求ステータス）

4. メール送信タイミング（PM決定: 2026-02-03）

4.1 納品報告リンク送信

4.2 手動催促機能

UI（発注一覧/詳細画面）: - 「納品催促メールを送信」ボタン - 表示条件: vendor_status = ACCEPTED かつ delivery_status = AWAITING_REPORT

催促メール: - 件名: 【Toriteki】納品報告のお願い: 発注書 {order_no} - 内容: 納品予定日リマインド + 納品報告リンク

制限: - 連続送信防止: 24時間に1回まで - 最終催促日時を記録: delivery_reminder_sent_at

4.3 トークン有効期限

• 納品予定日 + 7日間
• 催促時は新しいトークンを発行（旧トークンは無効化）

4.4 検収自動化ルール（PM決定: 2026-02-04）

基本方針: 受託先の納品報告により delivery_status = DELIVERED となった後、 猶予期間内に発注元が手動検収を行わない場合は自動検収を実行する

猶予期間

自動検収フロー

起点: delivery_status = DELIVERED になった日時

納品報告 → [猶予期間内に手動検収なし] → 自動検収実行
         → 検収書自動発行 → 請求書自動生成 → 受託先へ送付
         → 受託先がメール内ボタンで確認 → 発注元に通知
         → 会計連携データ生成

自動検収時の処理

1. delivery_status を INSPECTED に更新
2. inspected_at に現在日時を設定
3. inspection_result を PASS に設定
4. auto_inspected フラグを true に設定
5. 検収書PDFを自動生成
6. 請求書を自動生成（受託先へ送付）
7. 発注元へ「自動検収完了」通知メール送信
8. 監査ログに「自動検収」として記録

自動検収の除外条件

• delivery_status が DELIVERED 以外の場合
• 既に手動検収済みの場合
• やり直し依頼中（REWORK_REQUESTED）の場合

4.5 営業日の取り扱い（PM決定: 2026-02-04）

方式: ハイブリッド（猶予期間=暦日、支払期日=営業日）

祝日マスタ

支払期日の計算例

検収日: 2026-01-15（木）
締め日: 2026-01-31（土）→ 暦日通り
支払期日: 2026-02-28（土）→ 前営業日の 2026-02-27（金）

5. データモデル（Firestore追加フィールド）

5.1 toriteki_orders 追加フィールド

# 発注タイプ・支払条件
order_type: string               # "service"（デフォルト） or "goods"
payment_terms: string            # "default" or "custom"
payment_terms_source: string     # "default" or "quote"（見積書から）
payment_terms_text: string       # 支払条件の文言（カスタム時）
payment_cutoff_day: int          # 締め日（デフォルト: 0=末日）
payment_due_months: int          # 翌月=1（デフォルト）
payment_due_day: int             # 支払日（デフォルト: 0=末日）
payment_due_date: datetime       # 計算された支払期日

# 納品関連
delivery_status: string              # AWAITING_REPORT | DELIVERED | INSPECTED | INSPECTION_FAILED | REWORK_REQUESTED
delivered_at: datetime               # 納品報告日時
delivered_comment: string            # 納品コメント
delivery_attachment_blob: string     # 納品書GCSパス
delivery_attachment_filename: string
delivery_reminder_sent_at: datetime  # 最終催促送信日時

# 検収関連（案B: 受領と統合）
inspected_at: datetime               # 検収日時（= 受領日時、支払期日起算日）
inspected_by: string                 # 検収者メール（自動検収時は "system"）
inspection_result: string            # PASS | FAIL
inspection_comment: string           # 検収コメント
inspection_attachment_blob: string   # 検収書GCSパス
issue_delivery_receipt: boolean      # 物品時: 納品請書も同時発行する（チェックボックス）
delivery_receipt_blob: string        # 納品請書GCSパス（物品の場合のみ）
auto_inspected: boolean              # 自動検収フラグ（true=自動、false=手動）

# やり直し関連
rework_requested_at: datetime        # やり直し依頼日
rework_reason: string                # やり直し理由（必須）
rework_count: int                    # やり直し回数

# 請求関連
billing_status: string               # PENDING | INVOICED | PAID
invoice_no: string                   # 請求書番号
invoice_blob: string                 # 請求書GCSパス
invoice_filename: string             # 請求書ファイル名（アップロード時）
invoice_content_type: string         # 請求書MIMEタイプ
invoice_source: string               # "upload" | "auto" （アップロード or 自動生成）
invoiced_at: datetime                # 請求日時
paid_at: datetime                    # 支払日時
paid_by: string                      # 支払処理者（手動時）or "csv_import"（CSV取込時）
paid_comment: string                 # 支払メモ

# 納品報告リンク（内部）
# 有効期限・検証方式などの実装詳細は非公開別紙 `docs/Tatekan/toriteki/security_controls_private.md` を参照。

6. 画面・API設計

6.1 受託先：納品報告

URL: GET/POST /vendor/delivery/<token>

表示内容: - 発注番号 / 件名 / 金額 / 納品予定日 - 納品日（デフォルト: 今日） - コメント欄（任意） - 納品書アップロード（任意、PDF/画像 10MB以下） - 「納品報告する」ボタン

処理: 1. 専用URLの有効性検証（詳細は非公開別紙参照） 2. delivery_status を DELIVERED に更新 3. 納品書をGCSに保存（アップロード時） 4. 発注者へメール通知 5. 監査ログ記録

帳票: 「納品書」（アップロード or システム生成）

6.2 発注者：納品催促

URL: POST /order/<order_no>/remind-delivery

権限: 発注者本人、同一拠点のManager/Admin

処理: 1. 権限チェック 2. 24時間以内の催促履歴チェック 3. 新しい納品報告リンクを発行 4. 受託先へ催促メール送信 5. delivery_reminder_sent_at を更新 6. 監査ログ記録

6.3 発注者：検収（案B: 受領と統合）

URL: GET/POST /delivery/inspect/<order_no>

権限: 発注者本人、同一拠点のManager/Admin

表示条件: delivery_status = DELIVERED

表示内容: - 発注情報 - 納品報告情報（日時、コメント、納品書） - 検収日（デフォルト: 今日）= 受領日として扱う - 検収結果（合格/不合格） - コメント欄（不合格時は必須） - 【物品の場合のみ表示】 ☑ 納品請書も同時に発行する - 「検収完了」ボタン

処理: 1. 権限チェック 2. delivery_status を INSPECTED または INSPECTION_FAILED に更新 3. 支払期日を計算・記録（検収日 = 受領日として起算） 4. 検収書PDFを生成 5. 物品 かつ チェックON の場合: 納品請書PDFも同時生成 6. 受託先へメール通知（検収書PDF + 納品請書PDF添付） 7. 合格の場合、請求フローを開始可能に 8. 監査ログ記録

帳票: - 「検収書（合格通知書）」または「検収不合格通知書」（必須） - 「納品請書（受領書）」（物品 かつ チェックON時のみ）

UIイメージ:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
検収確認
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

発注番号: ORD-2026-001
件名: サーバー機器購入
発注タイプ: 物品

【納品報告】
納品日: 2026-02-01
コメント: 機器を納品しました

【検収情報】
検収日: [2026-02-03  ▼]

検収結果:
○ 合格
○ 不合格

コメント:
[________________]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
☑ 納品請書も同時に発行する
  ※物品の受領確認書として発行されます
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

        [検収完了]  [キャンセル]

6.4 発注者：やり直し依頼

URL: GET/POST /delivery/rework/<order_no>

権限: 発注者本人、同一拠点のManager/Admin

表示条件: delivery_status = INSPECTION_FAILED

表示内容: - 検収不合格の理由 - やり直し依頼理由（必須） - 新しい納品予定日 - 「やり直しを依頼する」ボタン

処理: 1. 権限チェック 2. delivery_status を REWORK_REQUESTED に更新 3. rework_reason を記録（必須） 4. rework_count をインクリメント 5. 新しい納品報告リンクを発行 6. 受託先へやり直し依頼メール送信 7. 監査ログ記録

注意: やり直し後の再受領時に新しい支払期日起算日となる

6.5 受託先：検収確認（オプション）

URL: GET/POST /vendor/inspection_confirm/<token>

表示内容: - 検収結果 - コメント欄（任意） - 「確認しました」ボタン

処理: 1. 専用URLの有効性検証（詳細は非公開別紙参照） 2. 確認記録を保存 3. 発注者へ通知 4. 監査ログ記録

帳票: 「検収請書」（システム自動生成）

6.6 請求書発行（PM決定: 2026-02-04）

URL: GET/POST /vendor/invoice/<token>

発行フロー（自動検収時）

検収完了（自動/手動）
    ↓
請求書自動生成（発注情報を元に作成）
    ↓
受託先へメール送信（請求書PDF添付 + 確認リンク）
    ↓
受託先が内容確認
    ├── 問題なし → 「確認」ボタン押下 → billing_status = INVOICED
    └── 修正要 → 自社請求書をアップロード → billing_status = INVOICED

受託先の選択肢

画面表示

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
請求内容の確認
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

発注番号: ORD-2026-001
件名: サーバー保守
検収日: 2026-02-03
支払期日: 2026-03-31

【請求金額】
税抜金額: ¥100,000
消費税(10%): ¥10,000
税込合計: ¥110,000

[自動生成された請求書を見る] (PDF)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
○ この内容で請求を確定する
○ 自社の請求書をアップロードする
  └ [ファイル選択] (PDF, 10MB以下)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

        [確定]  [キャンセル]

billing_status 遷移条件

サーバー側バリデーション

• 検収完了（INSPECTED）でない場合は請求不可
• INSPECTION_FAILED 状態では請求フロー進入禁止
• アップロードファイル: PDF/画像、10MB以下、MIME検証必須

6.7 発注履歴・詳細（閲覧）

URL: - GET /orders（発注履歴一覧） - GET /order/<order_no>（発注詳細・閲覧専用）

権限スコープ: - admin/privileged: 全社 - manager: 拠点 - staff/viewer: 自分のみ

UI/UX共通方針（WebUI UX定義準拠）: - 一覧読み込みはスケルトンUIを表示 - 主要操作の完了時はトーストで即時フィードバック - 誤操作リスクがある導線は確認モーダルを挟む - 画面遷移後は直前のフィルタ条件を保持 - 全画面で「戻る」導線を常設（ログイン後のみ）

発注履歴（一覧）UI: - 表示項目は発注番号、日付、取引先、件名、金額、ステータス、アクション - DRAFT / RETURNED は「編集」ボタンを表示 - PENDING_APPROVAL かつ manager/admin は「承認詳細」ボタンを表示 - それ以外は「閲覧」ボタンを表示 - 権限外の発注は表示しない

発注詳細（閲覧）UI: - 編集不可の読み取り専用画面とする - 表示内容は発注基本情報、明細、支払条件、見積書、納品/検収/請求ステータス、主要監査ログ - 見積書PDF、発注書PDFのリンクを表示する（存在時） - 画面上部にサマリーカードを配置し、取引先/件名/金額/納期/ステータスを集約表示 - 二重発注警告はサマリー直下に配置し見落としを防止 - PDFリンクは右上に集約し視線移動を最小化 - 主要監査ログは直近5件を表示し、全件はリンクで遷移

UIラベル/文言（確定）: - 画面タイトル: 「発注詳細（閲覧）」 - 右上ボタン: - 「承認画面へ」（権限がある場合のみ） - 「戻る」 - 「発注書PDF」「見積書PDF」「受託請書PDF」「請求書PDF」（存在時のみ表示） - サマリーカード見出し: 「サマリー」 - サマリー項目ラベル: - 「発注番号」「拠点」「取引先」「件名」「金額（税抜/税込）」 - 「発注ステータス」「納品ステータス」「検収ステータス」「請求ステータス」 - 「納品予定日」「検収予定日」「支払期日」 - 複製/警告カード見出し: 「複製・二重発注チェック」 - 警告バナー文言: - WARN: 「同一受託先の進行中発注があります。内容と納期をご確認ください。」 - HIGH: 「同一受託先の未完了発注（承認待ち/受託請書待ち）があります。二重発注の可能性があるため必ず確認してください。」 - 複製情報ラベル: - 「複製元」「複製理由」「二重発注チェック」「関連する未完了発注」 - セクション見出し: - 「発注内容」「進行状況」「書類」「監査ログ」 - 発注内容ラベル: - 「件名」「仕様」「数量」「単位」「単価」「金額」「支払条件」「条件内容」「発注日」「作成者」 - 進行状況ラベル: - 「受託先ステータス」「納品報告日」「納品コメント」「検収結果」「検収日」「請求確定日」「支払状況」 - 監査ログ: - 「直近5件を表示」「全件を見る」

アーカイブポリシー（PM決定: 2026-02-08）: - 発注データの物理削除・論理削除は不可。削除操作はすべて「アーカイブ」に置換 - アーカイブ済み発注は一覧に表示しないが、origin_order_no 等からの参照は可能 - アーカイブ済み発注を参照した場合:「この発注はアーカイブされています」と表示し、基本情報（発注番号・件名・取引先）のみ閲覧可能

監査ログ: - order_viewed を記録（閲覧のみ、更新なし） - 記録頻度制限: 同一ユーザー × 同一発注の組み合わせは1日1回のみ記録（Firestore書き込みコスト最適化） - 判定キー: {user_email}_{order_no}_{YYYY-MM-DD}（JST日付基準）

6.8 発注履歴・複製（入力支援）

定義: - 複製は入力支援であり「再発注」とは別概念 - 再発注は「同一目的での追加発注」を指す

URL: - POST /order/<order_no>/duplicate

権限: - admin/privileged/manager/staff: 可 - viewer: 不可

複製フロー: - 複製確認モーダルを表示 - 複製理由コメントを必須入力 - 新規 order_no を発行し DRAFT で作成 - origin_order_no を保存 - 発注入力画面に遷移（事前入力済み） - レート制限: サーバー側制限なし。UI側でボタンdebounce（二重クリック防止）のみ実装（PM決定: 2026-02-08）

複製対象フィールド: - 引き継ぐ項目は取引先、件名、仕様、数量、単価、支払条件、承認者候補 - 引き継がない項目はステータス、承認/納品/検収/請求の履歴、トークン類、請求番号

発注履歴一覧のボタン配置（多言語）: - アクション列の表示順: 「閲覧」→「複製」 - DRAFT / RETURNED: 「編集」ボタンのみ表示 - PENDING_APPROVAL かつ manager/admin: 「承認詳細」+「複製」 - それ以外: - admin/manager/staff: 「閲覧」+「複製」 - viewer: 「閲覧」のみ - 複製ボタンの注意バッジ: - 同一受託先で未完了発注が存在する場合、「注意」バッジを表示 - 表示色はWARN相当の淡い黄（bg-warning-subtle） - クリック時に複製モーダル内でHIGH/WARNの詳細を表示

「注意」バッジ文言（多言語）:

複製モーダル（多言語）: - モーダルタイトル: 「発注を複製」 - 説明文: 「この発注を複製して新規の下書きを作成します。必要に応じて内容を編集してください。」 - 理由入力ラベル: 「複製理由（必須）」 - 理由プレースホルダ: 「例: 追加発注 / 分割発注 / 仕様変更対応」 - 注意文: 「同一受託先で未完了の発注がある場合、承認者へ警告が表示されます。」 - ボタン: 「複製する」/「キャンセル」 - 理由は選択式 + 任意の自由記述（「その他」選択時のみ表示） - 自由記述欄は全角英数字禁止・半角カタカナ禁止（既存バリデーションと同等）

複製理由（選択式）: 1. 固定契約（定期・定形業務） 2. 追加発注（同一案件の追加分） 3. 分割発注（予算・工程・納期都合） 4. 仕様変更対応（条件変更による再作成） 5. 単価改定対応（価格変更による再作成） 6. 緊急対応（至急・突発） 7. その他（自由記述必須） - 自由記述は最小10文字・最大400文字 - 入力欄は3〜4行の固定高さ、最大8行まで自動拡張 - 文字数カウンタを表示（例: 45/400） - 情報アイコンで事前に入力ルールを表示 - 例: 「ⓘ 全角英数字・半角カタカナは使用できません」 - エラー文言（例） - 「複製理由は10文字以上で入力してください。」 - 「複製理由は400文字以内で入力してください。」 - 「全角英数字は使用できません。」 - 「半角カタカナは使用できません。」

複製理由コード（監査ログ用）: - fixed_contract - additional_order - split_order - spec_change - price_change - urgent - other

複製理由コードの多言語ラベル:

差分表示（複製後の編集画面）（PM決定: 2026-02-08）: - 複製元との差分を強調表示する - 差分の表示対象は件名、仕様、数量、単価、納期、支払条件 - 変更前/変更後を並列表記（差分がある場合のみ表示） - 実装方式: origin_order_no から都度読み取り（スナップショット保存はしない） - 複製元がアーカイブ済みの場合は差分表示を省略し「複製元はアーカイブ済みです」と表示

二重発注チェック（警告）: - 条件: 同一取引先 + 同一件名 + 同一金額 + 納期近接（直近60日）（PM決定: 2026-02-08） - 警告は画面にバナー表示し、承認通知メールにも記載 - 警告が出ても複製は可能（最終判断は承認者） - 直前の同一受託先発注が未完了の場合は警告強度を引き上げる - PENDING_APPROVAL / 受託請書待ち: HIGH警告 - 納品待ち / 検収待ち / 請求待ち: WARN

承認通知メール追加情報: - 複製元 origin_order_no - 複製理由コメント - 二重発注チェック警告（該当時のみ）

監査ログ: - order_duplicated を記録（origin_order_no を含む） - order_duplicate_warning を記録（警告発生時） - order_duplicated には複製理由コードと自由記述を含める

画面警告バナー文言（例）: - WARN: 「同一受託先の進行中発注があります。内容と納期をご確認ください。」 - HIGH: 「同一受託先の未完了発注（承認待ち/受託請書待ち）があります。二重発注の可能性があるため必ず確認してください。」

承認通知メール文面（例）:

本発注は「複製」操作で作成されました。
複製元: {origin_order_no}
複製理由: {duplicate_reason}

二重発注チェック: {warning_level}
理由: {warning_reason}
関連する未完了発注: {related_order_url}

承認通知メール内リンク文言（多言語）:

承認画面のリンク文言（多言語）:

承認画面での表示位置（UI/UX定義準拠）: - 位置: 承認詳細のサマリー直下、承認アクションボタンの直上 - 見出し: 「関連する未完了発注」 - 表示条件: High警告が発生した場合のみ表示 - 表示項目: 発注番号、件名、金額、納品予定日、ステータス、リンク - 複数件の表示ルール: - 最大3件まで表示 - 優先度順: PENDING_APPROVAL → 受託請書待ち → その他の未完了 - 同優先度内は更新日時の新しい順

High警告時のダイレクトリンク: - High警告に該当する未完了発注がある場合、承認通知メールと承認画面にリンクを表示する - リンク先は閲覧専用の発注詳細（/order/<order_no>）とする - 承認権限がある場合のみ、閲覧画面から承認画面へ遷移リンクを表示する

警告バナーの表示デザイン（UI/UX準拠）: - HIGH: 淡い赤背景 + 濃い赤文字 + 左ボーダー（例: bg-danger-subtle / text-danger / border-danger） - WARN: 淡い黄背景 + 濃い黄文字 + 左ボーダー（例: bg-warning-subtle / text-warning / border-warning） - 画面上の警告バナーはクローズ不可（見落とし防止）

7. 発注書PDF：支払条件の記載

7.1 PDF最下段に追加する記載

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【お支払条件】

■ 本発注の種別: [役務提供 / 物品]
■ 適用される支払条件: [月末締め・翌月末現金払い / 見積書記載の条件]

〈役務提供の場合〉
  役務提供完了日の属する月の翌月末日までに現金でお支払いいたします。
  （例：1月15日完了 → 2月末日支払）

〈物品納品の場合〉
  物品受領日の属する月の翌月末日までに現金でお支払いいたします。
  （例：1月15日受領 → 2月末日支払）

※本発注は取適法（中小受託取引適正化法）に準拠しています。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

7.2 支払条件のUI（発注画面）

【発注タイプ】
○ 役務提供（コンサル、工事、保守など）← デフォルト
○ 物品（機器購入、資材調達など）

【支払条件】
○ 標準条件（月末締め・翌月末現金払い）← デフォルト
○ 見積書記載の条件を使用
   └ 条件内容: [________________]

⚠️ 60日を超える条件は取適法違反となるため設定できません

8. 帳票一覧（案B統合版）

9. メール通知

9.1 納品報告リンク（受託先宛）- 自動送信

送信タイミング: 受諾完了時（即時）

件名: 【Toriteki】納品報告のご案内: 発注書 {order_no}

内容: - 発注番号 / 件名 / 金額 - 納品予定日 - 納品報告リンク（トークン付きURL） - 注意事項

9.2 納品催促（受託先宛）- 手動送信

送信タイミング: 発注者が「納品催促」ボタンをクリック

件名: 【Toriteki】納品報告のお願い: 発注書 {order_no}

内容: - 発注番号 / 件名 - 納品予定日（強調表示） - 納品報告リンク（新規トークン付きURL） - 催促文言

9.3 納品報告通知（発注者宛）

件名: 【Toriteki】納品報告: 発注書 {order_no}

内容: - 受託先名 - 納品日 - 納品コメント - 納品書リンク（GCS署名付きURL） - 受領確認ボタンURL

9.4 検収完了通知（受託先宛）- 案B統合版

件名: 【Toriteki】検収完了: 発注書 {order_no}

内容: - 検収日（= 受領日） - 検収結果（合格/不合格） - 検収者名 - コメント - 支払期日 - 検収書PDFリンク - 【物品 かつ 納品請書発行時】 納品請書PDFリンク - （合格時）請求発行手続きの案内

9.5 検収不合格・やり直し依頼通知（受託先宛）

件名: 【Toriteki】やり直しのお願い: 発注書 {order_no}

内容: - 検収日 - 不合格理由 - やり直し依頼理由 - 新しい納品予定日 - 納品報告リンク（新規トークン付きURL）

10. サーバー側バリデーション・ガード条件（PM決定: 2026-02-04）

10.1 取適法60日超過防止（API必須バリデーション）

原則: UIの警告に加え、サーバー側で強制拒否

検証タイミング

エラーレスポンス例

{
  "error": "PAYMENT_TERMS_VIOLATION",
  "message": "支払期日が検収日から60日を超えています（取適法違反）",
  "details": {
    "inspection_date": "2026-02-03",
    "payment_due_date": "2026-04-15",
    "days_difference": 71,
    "max_allowed_days": 60
  }
}

10.2 物品限定「納品請書同時発行」サーバー側ガード

原則: issue_delivery_receipt = true は order_type = "goods" の場合のみ許可

検証

# API: POST /delivery/inspect
if request.issue_delivery_receipt and order.order_type != "goods":
    raise ValidationError(
        "納品請書の同時発行は物品発注の場合のみ可能です"
    )

エラーレスポンス

{
  "error": "DELIVERY_RECEIPT_NOT_ALLOWED",
  "message": "納品請書の同時発行は物品発注の場合のみ可能です",
  "order_type": "service"
}

10.3 INSPECTION_FAILED 時の請求フロー禁止

原則: 検収不合格状態では請求フローに進入不可

状態遷移制約

INSPECTION_FAILED → 請求フロー進入禁止
                  → REWORK_REQUESTED のみ遷移可能
                  → やり直し後 DELIVERED に戻る

API ガード

10.4 再納品（やり直し）時の履歴方針

決定: 監査ログのみで履歴保持、データは上書き

上書きされるフィールド

delivered_at          → 再納品日で上書き
delivered_comment     → 新しいコメントで上書き
delivery_attachment_* → 新しい納品書で上書き
delivery_status       → DELIVERED に戻る

監査ログに記録する項目

{
  "event": "REWORK_DELIVERY",
  "order_no": "ORD-2026-001",
  "rework_count": 2,
  "previous_delivered_at": "2026-01-15T10:00:00Z",
  "new_delivered_at": "2026-02-01T14:30:00Z",
  "rework_reason": "仕様不一致のため再作業",
  "actor": "vendor@example.com",
  "timestamp": "2026-02-01T14:30:00Z"
}

10.5 税額算出ルール

適用税率: 消費税10%（軽減税率対象外）

計算ルール

税抜金額 = order_amount（発注金額）
消費税額 = floor(税抜金額 × 0.10)  # 端数切り捨て
税込金額 = 税抜金額 + 消費税額

注意事項

• 発注金額（order_amount）は税抜で登録
• 請求書・会計連携CSVには税抜/税額/税込を全て出力
• 軽減税率（8%）が必要な場合は次期実装で対応
• 複数税率の混在は現時点で非対応

会計連携CSV出力例

order_no,vendor_name,amount_excl_tax,tax_amount,amount_incl_tax,tax_rate
ORD-2026-001,テスト株式会社,100000,10000,110000,10

11. 入力制約一覧（実装必須）

原則: UIとAPIは同一制約。UIのみに依存しない。

メッセージ標準:
{項目名}: {上限}文字以内で入力してください

12. エラーコード一覧（API共通）

13. 監査ログ（必須イベント）

必須項目: event_type, actor, order_no, timestamp, before, after, ip_address

14. 例外フロー（最小必須）

15. ロール・権限マトリクス（最小）

16. 通知テンプレート（標準）

原則: 件名・本文の差し込み変数は {var} 形式で統一。HTML/テキスト共通の要旨を定義する。

16.1 納品報告リンク（受託先）

• 件名: 【Toriteki】納品報告のご案内: 発注書 {order_no}
• 本文（要旨）:
• 受託先名 {vendor_name}
• 発注番号 {order_no}
• 件名 {item_name}
• 納品予定日 {delivery_deadline}
• 納品報告リンク {delivery_link}
• 注意事項: 「リンク有効期限: 期限切れの表示が出た場合は再送依頼をご利用ください」

16.2 納品催促（受託先）

• 件名: 【Toriteki】納品報告のお願い: 発注書 {order_no}
• 本文（要旨）:
• 発注番号 {order_no}
• 件名 {item_name}
• 納品予定日 {delivery_deadline}
• 納品報告リンク {delivery_link}

16.3 納品報告通知（発注者）

• 件名: 【Toriteki】納品報告: 発注書 {order_no}
• 本文（要旨）:
• 受託先名 {vendor_name}
• 発注番号 {order_no}
• 件名 {item_name}
• 納品日 {delivered_at}
• 納品コメント {delivered_comment}
• 納品書リンク {delivery_doc_link}
• 受領確認リンク {inspection_link}

16.4 検収完了（受託先）

• 件名: 【Toriteki】検収完了: 発注書 {order_no}
• 本文（要旨）:
• 検収日 {inspected_at}
• 検収結果 {inspection_result}
• 支払期日 {payment_due_date}
• 検収書リンク {inspection_doc_link}
• 納品請書リンク {delivery_receipt_link}（物品/発行時のみ）
• 請求確定リンク {invoice_confirm_link}

16.5 検収不合格・やり直し依頼（受託先）

• 件名: 【Toriteki】やり直しのお願い: 発注書 {order_no}
• 本文（要旨）:
• 検収日 {inspected_at}
• 不合格理由 {inspection_comment}
• やり直し依頼理由 {rework_reason}
• 新しい納品予定日 {delivery_deadline}
• 納品報告リンク {delivery_link}

16.6 請求確定（発注者）

• 件名: 【Toriteki】請求確定: 発注書 {order_no}
• 本文（要旨）:
• 請求番号 {invoice_no}
• 請求金額 {invoice_amount}
• 請求書リンク {invoice_doc_link}
• 支払期日 {payment_due_date}

16.7 自動検収完了（発注者）

• 件名: 【Toriteki】自動検収完了: 発注書 {order_no}
• 本文（要旨）:
• 検収日 {inspected_at}
• 自動検収フラグ {auto_inspected}
• 検収書リンク {inspection_doc_link}
• 請求確定リンク {invoice_confirm_link}

16.8 支払完了（受託先）

• 件名: 【Toriteki】支払完了: 発注書 {order_no}
• 本文（要旨）:
• 支払日 {paid_at}
• 支払金額 {paid_amount}
• 支払方法 {payment_method}

17. 関連別紙

• 会計連携CSV仕様: docs/Tatekan/toriteki/toriteki_accounting_csv_spec.md
• 監査ログ仕様: docs/Tatekan/toriteki/toriteki_audit_log_spec.md
• 通知テンプレート（多言語）: docs/Tatekan/toriteki/toriteki_notification_templates_multilang.md

18. 実装フェーズ

Phase 1: 納品報告（受託先）

• 受諾時の納品報告リンク自動送信
• 納品報告画面
• 納品書アップロード
• 発注者への通知

Phase 2: 検収（発注者）- 案B統合版

• 納品催促機能（手動）
• 検収画面（受領と統合）
• 支払期日の自動計算（検収日 = 受領日として起算）
• 検収書自動生成
• 物品の場合: 納品請書同時発行オプション（チェックボックス）
• やり直し依頼機能
• 受託先への通知

Phase 3: 請求（受託先/自動）

• 請求書アップロード or 自動生成
• 請求一覧画面

Phase 4: リマインダー

• Cloud Scheduler 設定
• バッチ通知処理（納品予定日、検収予定日、支払期日）

Phase 4 運用手順（バッチ/スケジューラ）

対象: 自動検収バッチ・リマインダー
実行時間: JST 08:00 / 16:00（2026-02-09変更: 始業前・午後更新に最適化） エンドポイント: POST /tasks/toriteki-daily

1. Cloud Run 環境変数

• BATCH_JOB_TOKEN: バッチ認証用トークン

2. Cloud Scheduler ジョブ

Staging - toriteki-daily-staging-0900 (JST 08:00) - toriteki-daily-staging-1300 (JST 16:00)

Production - toriteki-daily-prod-0900 (JST 08:00) - toriteki-daily-prod-1300 (JST 16:00)

共通設定 - HTTP Target: POST <service_url>/tasks/toriteki-daily - Headers: - X-Job-Token: <BATCH_JOB_TOKEN> - Content-Type: application/json - Body: {}
- Timezone: Asia/Tokyo

3. 手動実行（疎通確認）

# Scheduler から手動実行（例: Staging 09:00）
# gcloud scheduler jobs run toriteki-daily-staging-0900 --location=asia-northeast1 --project=gobms-465809

# 直接呼び出し（確認用）
# curl -X POST -H "X-Job-Token: <BATCH_JOB_TOKEN>" -H "Content-Type: application/json" -d '{}' <service_url>/tasks/toriteki-daily

期待値 - HTTP 200 - JSON: auto_inspection / reminders の結果が返る

4. BATCH_JOB_TOKEN ローテーション手順

目的: トークン漏洩や定期運用に備えた更新

準備 1. 新トークンを生成（例: openssl rand -hex 32） 2. 現在のトークンは切替完了まで保持

Staging 更新 1. Cloud Run の BATCH_JOB_TOKEN を新トークンに更新（Staging） 2. Staging Scheduler の X-Job-Token を新トークンに更新 3. Staging で手動実行し HTTP 200 を確認

Production 更新 1. Cloud Run の BATCH_JOB_TOKEN を新トークンに更新（Production） 2. Production Scheduler の X-Job-Token を新トークンに更新 3. Production で手動実行し HTTP 200 を確認

切替後 - 旧トークンは破棄 - 証跡（ログ/結果）を handoff に記録

5. 障害時の基本対応

• Scheduler 実行結果を確認
• Cloud Run ログで /tasks/toriteki-daily のステータス確認
• 401/403 の場合はトークン設定を再確認
• 500 の場合はアプリ側ログを確認し、PL にエスカレーション

Phase 5: ロール別BI/ダッシュボード

• 担当者向けTop画面（自分の発注、要対応件数）
• 承認者/拠点長向けTop画面（拠点状況、承認待ち、遅延アラート）
• 管理者/役員向けTop画面（全社KPI、拠点別集計、月次推移）

Phase 5 方針（運用コスト最小化）

• ダッシュボードは 日次集計キャッシュ前提 で表示する
• 直接集計は行わず、バッチが作成したキャッシュを参照する

Phase 5 集計キャッシュ（Datastore）

Kind: toriteki_dashboard_cache
主キー: cache_id（例: global_YYYYMMDD, branch_<branch>_YYYYMMDD, user_<email>_YYYYMMDD）

共通フィールド - cache_date (date) : JST日付 - scope_type (string) : global / branch / user - scope_key (string) : all / <branch_name> / <user_email> - updated_at (datetime) : 生成時刻（UTC） - ttl_days (int) : 保持日数（例: 30）

指標フィールド（例） - total_orders_count (int) - total_orders_amount (int) - approval_rate (float) - pending_approval_count (int) - pending_delivery_count (int) - pending_inspection_count (int) - overdue_delivery_count (int) - overdue_inspection_count (int) - payment_due_soon_count (int) # 期日が近い（閾値は運用定義） - payment_overdue_count (int) - compliance_risk_count (int) # 60日超過リスク

月次推移（Admin） - monthly_trends (array) : 直近Nヶ月の {month, amount, count} 配列

Phase 5 バッチ集計（JST基準）

集計タイミング - 日次バッチに統合（JST 09:00 / 13:00）

集計対象 - toriteki_orders を対象に、cache_date（JST日付）で集計 - scope 別に global / branch / user を作成

遅延・期日定義（暫定） - 納品遅延: delivery_deadline < today かつ delivery_status が完了前 - 検収遅延: inspection_deadline < today かつ delivery_status != INSPECTED - 支払期日アラート: payment_due_date が閾値以内 かつ billing_status != PAID - 60日超過リスク: payment_due_date - inspected_at > 60

キャッシュ利用 - UIは最新の cache_date を読み込む - 無い場合は「集計未完了」表示（再実行を促す）

Phase 5 表示仕様（数値の信頼性担保）

原則 - ダッシュボードは「最後に成功した集計キャッシュ」のみを表示する - 画面上に 集計時刻（JST） を必ず表示する - データが無い・失敗時は 事実を明示 し、誤った数値は出さない

表示ルール - latest_success_cache が存在する場合: そのキャッシュを表示 - latest_success_cache が存在しない場合: 画面をブロックし「集計未完了」メッセージを表示 - latest_success_cache が前回バッチ時刻より古い場合: 画面上部に 警告バナー を表示

警告バナー文言（固定） 最新の集計に失敗しました。表示中の数値は {last_success_at} 時点のものです。

時刻の表記 - 画面に表示する集計時刻は JST で統一 - 例: 集計時刻: 2026-02-06 13:00 JST

SLAルール（明文化） - 09:00 バッチ成功後、13:00 までは 09:00 時点の数値を表示 - 13:00 バッチ成功後、翌日 09:00 までは 13:00 時点の数値を表示 - どちらも失敗した場合は、最後に成功した集計時刻 を明示して表示 - 成功キャッシュが存在しない場合は「集計未完了」のみを表示し、数値は一切表示しない

運用対応（失敗時） - Scheduler 実行失敗 or Cloud Run 500/401/403 の場合は 即時再実行 - 再実行でも失敗する場合は、当日中に原因調査ログを残し、PMへエスカレーション

監視（必須） - Scheduler 実行結果の失敗をアラート化 - /tasks/toriteki-daily の HTTP ステータスと実行件数をログで監視

Phase 6: 発注タイプ・支払条件

• 発注画面に発注タイプ選択を追加
• 見積書の支払条件読み取り
• 発注書PDFへの支払条件記載

Phase 7: 監査・可観測性強化（低コスト / 高効果）

• 監査ログの検索/エクスポートUI
• バッチ実行結果の可視化（成功/失敗/件数）

Phase 8: 取適法コンプライアンス可視化（低コスト / 高効果）

• 60日超過リスクの警告・一覧
• リスク理由の明示

Phase 9: 通知履歴・再送（中コスト）

• 通知履歴の閲覧
• 再送・手動送信

Phase 10: 発注履歴・閲覧・複製（中コスト）

• 発注履歴の閲覧可否を明確化（編集不可でも閲覧可）
• 閲覧: ステータス非依存で許可（権限に応じてスコープ制御）
• 編集: DRAFT / RETURNED のみ許可
• スコープ: admin/privileged=全社, manager=拠点, staff/viewer=自分のみ
• 発注履歴からの複製（入力支援）
• 定義: 「再発注」ではなく入力支援の複製操作
• 新規 order_no を必ず発行（重複禁止）
• 複製元 origin_order_no を保存し監査可能にする
• 複製時は常に DRAFT として作成
• 二重発注チェックの警告（同一取引先/件名/金額/納期が直近60日）
• 承認通知メールに「複製元」「二重チェック警告」「複製理由」を明記
• 複製理由コメントの入力を必須化（承認者・監査向け）
• アーカイブポリシー（物理/論理削除禁止、削除はアーカイブに置換）
• 詳細仕様: 6.7節（閲覧）、6.8節（複製）参照

Phase 11: 代理承認/代理操作フロー（中コスト）

• 事前委任方式（案A）: 承認者が事前に代理者と委任期間を設定
• 委任期間中は代理者が承認画面で承認可能
• 元の承認者も引き続き承認可能（並行権限）
• 期間終了で自動的に委任解除
• 監査ログに「代理承認（委任元: {original_approver}）」と記録
• 都度指名方式（案B）: Adminが個別発注の承認者を変更
• 発注単位での承認者変更（全発注委任ではない）
• 新承認者に承認依頼通知、旧承認者に変更通知
• 監査ログに「承認者変更（旧: {old} → 新: {new}、変更者: {admin}）」と記録
• 代理操作の対象:
• 発注承認: 必須（不在時のブロッカー防止）
• 検収: 対応（7日猶予があるが長期不在時に必要）
• 納品催促/支払記録: 対象外（既存権限で代替可能）
• データモデル（Firestore）:
• toriteki_delegations コレクション
  • delegation_id: string（自動生成）
  • delegator_email: string（委任元）
  • delegate_email: string（代理者）
  • delegation_type: string（pre_approved / ad_hoc）
  • scope: string（all_orders / single_order）
  • target_order_no: string（都度指名時のみ）
  • start_date: datetime（委任開始日）
  • end_date: datetime（委任終了日）
  • is_active: boolean
  • created_by: string（設定者）
  • created_at: datetime
• toriteki_orders 追加フィールド
  • approved_by_delegate: boolean（代理承認フラグ）
  • original_approver_email: string（委任元、代理承認時のみ）
• 監査ログイベント:
• delegation_created: 委任設定
• delegation_revoked: 委任取消
• delegation_expired: 委任期間満了（自動）
• order_approved_by_delegate: 代理承認実行
• approver_reassigned: 承認者変更（都度指名）

Phase 12: 役割詳細化（中コスト）

• 方式: ロール追加方式（既存4ロール維持＋新ロール追加）
• 新規ロール:
• inspector: 検収専任（拠点スコープ、検収操作のみ可能）
• branch_viewer: 拠点閲覧（拠点スコープ、閲覧のみ、経理・監査向け）
• 次期拡張候補（本Phaseでは未実装）:
• approver_limited: 金額制限付き承認（運用で代替可能なため後回し）
• 権限マトリクス（更新版）:

• データモデル: toriteki_users.role に inspector / branch_viewer を追加
• Firestoreセキュリティルール: ロールベースのアクセス制御を更新
• UI影響: ユーザー管理画面のロール選択肢を追加

Phase 12.5: パンくずナビゲーション（低コスト・UI改善）

• 目的: 全画面共通の「戻る」ボタンをBootstrapパンくずリスト（breadcrumb）に置換し、UI/UXを改善
• 背景: 各画面左上に孤立した「戻る」ボタンがあり、ダッシュボード等の美観を損ねていた（PM指摘）
• 実装内容:
• BASE_TEMPLATEの「戻る」ボタンをBootstrap breadcrumbコンポーネントに置換
• _breadcrumbs() ヘルパー関数を追加
• 全render_base()呼び出しにページ階層情報を追加
• ダッシュボード: パンくず非表示
• L2ページ（発注一覧等）: ダッシュボード > 発注一覧
• L3ページ（発注詳細等）: ダッシュボード > 発注一覧 > 発注詳細
• 個別テンプレート内の重複「戻る」ボタンを整理
• 翻訳キー追加（4言語対応）
• PM決定: 2026-02-08（案A採用）

Phase 13: 検索（中コスト）

• 標準検索窓の提供（発注番号/件名/取引先/金額/期間/ステータス）
• 検索条件の可視化（チップ表示）
• 権限スコープ内のみ検索可能
• 次期拡張: AI連動検索（自然文 → 条件化）
• 同時対応: ユーザー管理CSVエクスポート/インポート（Admin専用、即時対応）
• 検索API（PM決定: 2026-02-08）:
• GET /orders/search
• クエリパラメータ:
  • q: テキスト検索（発注番号/件名/取引先を横断）
  • status: ステータスフィルタ（カンマ区切りで複数指定可）
  • delivery_status: 納品ステータスフィルタ
  • billing_status: 請求ステータスフィルタ
  • amount_min: 金額下限（税抜）
  • amount_max: 金額上限（税抜）
  • date_from: 発注日From（YYYY-MM-DD）
  • date_to: 発注日To（YYYY-MM-DD）
  • vendor_name: 取引先名（部分一致）
  • cursor: ページネーションカーソル
  • limit: 1ページ表示件数（デフォルト: 20、最大: 50）
• レスポンス:
  • orders: 検索結果配列
  • next_cursor: 次ページカーソル（null=最終ページ）
  • has_more: boolean
  • total_hint: 概算件数（Firestoreの制約上、正確な総件数は返さない）
• ページネーション: カーソル方式（Firestore startAfter 利用）
• 「前へ」「次へ」ボタン方式（無限スクロールではない）
• 1ページ20件（将来的にユーザー設定で20/50切替を検討）
• Firestoreインデックス: 複合インデックスを以下の組み合わせで作成
• (branch, status, created_at)
• (branch, vendor_name, created_at)
• (branch, order_amount, created_at)
• 検索UIイメージ:
• 検索窓は発注一覧画面の上部に配置
• フィルタはドロップダウン/日付ピッカーで展開
• 適用中のフィルタ条件はチップ（バッジ）で表示、×で個別解除可能
• 検索結果0件時:「条件に一致する発注が見つかりません」と表示

Phase 13 追加（ユーザー管理CSV）

• 対象画面: /admin/users
• 機能: CSVエクスポート / CSVインポート（Upsertのみ、削除なし）
• 実行権限: Adminのみ
• 検証: email ドメイン、role 許可値、branches 既存一致、CSV内重複
• 監査: user_csv_import を監査ログに記録

Phase 14: メール通知＋取引先許諾フロー（中コスト）

14-A: Welcome Mail（ユーザー登録通知）

• トリガー: ユーザー新規登録時（/admin/users/save）
• 送信先: 登録されたユーザーのメールアドレス
• 内容: HTMLクールデザイン（TATEKANロゴ付き）、ロール・拠点案内、ログインURL
• 多言語: ja / en / zh_CN / zh_TW

14-B: 取引先登録通知メール

• トリガー: 取引先新規登録時（/supplier/save）
• 送信先: 取引先メール（許諾リクエスト付き）＋登録者（社内確認）
• 内容: 登録完了通知＋許諾ページURL

14-C: 取引先許諾（Consent）フロー

• ワンタイムトークン: UUID v4、7日間有効
• 公開許諾ページ: ログイン不要、トークン認証のみ
• 使用許諾契約（チェックボックス必須）
• 個人情報取扱い（チェックボックス必須）
• 電子取引同意（チェックボックス必須）
• 同意処理: 許諾日時・IP・UA記録 → toriteki_supplier_consents に保存
• 通知: 発注側（登録者＋Admin）へ許諾完了メール
• ステータス表示: 取引先一覧に許諾状態（未送信 / 送信済み・未許諾 / 許諾済み / 期限切れ）

14-D: ユーザー許諾（User Consent）フロー

• トリガー: ユーザー新規登録時（/admin/users/save）
• 送信先: 登録されたユーザーのメールアドレス
• 送信順序: Welcomeメール送信後、ユーザー許諾メールを約1分遅延して送信（先着逆転を抑制）
• ワンタイムトークン: UUID v4、7日間有効
• 公開許諾ページ: ログイン不要、トークン認証のみ（/user/consent/<token>）
• 使用許諾契約（チェックボックス必須）
• 個人情報取扱い（チェックボックス必須）
• サービス利用同意（チェックボックス必須）
• 同意処理: 許諾日時・IP・UA記録 → toriteki_user_consents に保存
• ステータス表示: ユーザー一覧に許諾状態（未送信 / 送信済み・未許諾 / 許諾済み / 期限切れ）
• 再送: 管理者がユーザー一覧から許諾メールを再送可能（許諾済以外）

14-UI: 既存ページ改善

• ナビバーにTATEKANロゴアイコン追加
• 全ページフッターに「Powered by TATEKAN/Toriteki.」追加

Phase 15: マルチテナント対応（GWS前提版 ✅ 完了）

• 目的: 複数企業（テナント）を同一基盤で安全に運用する（GWS導入済み企業向け）。
• ログイン表示: Topページの案内は「関係者専用」のみ表示（特定ドメイン名は表示しない）。
• データ分離: 全エンティティに tenant_id を必須付与（orders, suppliers, users, branches, audit_log）。
• 認証/認可: ログイン時に tenant_id を解決し、全APIで tenant_id を強制フィルタ。
• 管理者: テナント管理者ロールを追加（自社ユーザー/拠点/取引先の管理）。
• 監査: 監査ログに tenant_id を記録。
• インデックス: tenant_id を含む複合インデックスを追加（例: (tenant_id, branch, created_at)）。
• 移行: 既存データは tenant_id = "godosangyo" を一括付与。
• 新規テナント招待: 特権ロールのみ実行可（会社名、登録担当者メールで招待送信）。
• 登録ステータス: INVITED → CONSENT_PENDING → CONSENTED → PROVISIONING → ACTIVE（例外: FAILED, EXPIRED）。
• 入力項目: 会社名、郵便番号、住所、電話番号、主担当者メール、申請ドメイン。
• 入力規則:
• 主担当者メールのドメインと申請ドメインが不一致の場合は NG（作成不可）。
• フリーメールドメインは 拒否。
• 許諾未同意では作成不可。
• 言語表示: ステータス名・エラー・警告は選択言語に応じて表示（日本語選択時は日本語表記）。
• 作成完了通知: ACTIVE 遷移後に登録担当者へ「テナント作成完了」通知を送信。
• 初回オンボーディング: 初期ユーザー（登録担当者）は初回ログイン時にウィザードを必須完了（氏名入力必須→拠点を最低1件作成必須、途中中断は再開可）。詳細: docs/Tatekan/toriteki/toriteki_tenant_onboarding_spec.md
• 監査対象イベント: 招待送信、再送、同意完了、作成開始、作成成功/失敗、不一致拒否、フリーメール拒否。
• 監査表示境界: 特権ロールは全テナントを閲覧可能。ただしテナント管理者向け監査ログには特権ロール操作を表示しない。
• 監査保存方針: 特権ロール操作は特権ロール専用の運用ログへ記録し、テナント側の監査ログとは分離する（詳細は非公開別紙参照）。

Phase 17: 独自ドメイン対応（中〜高コスト）

• 目的: テナントごとに独自ドメインで利用できるようにする。
• 緊急課題（外部ログイン）: 現状はGoogle OAuthクライアントの制約（Internal/組織内限定）およびアプリ側の固定ドメイン制約により、外部ドメインのテナント利用者がログインできない可能性がある。Phase 17 で「外部ドメインでもログイン可能な認証/認可」へ移行する。
• ドメイン管理: tenant_domains に tenant_id, domain, status を管理。
• 検証: DNS TXT による所有証明 → 有効化。
• TLS: マネージド証明書で自動更新。
• ログイン: ドメインに紐づく tenant_id を決定し、認証後も一致チェック。
• 制約: 認証方式との整合が必要（組織アカウント前提の制約は将来見直しの可能性あり）。

Phase 18: 運用アラート（中コスト）

• 監視対象:
• PDF改ざん検知（GCSオブジェクト更新/削除）
• 納品期限超過・無応答
• 請求期限超過・無応答
• 通知先チャネル:
• メール（Monitoring Notification Channel）
• Slack / Google Chat（Webhook連携）
• 最小構成:
• 監視ログメトリクス
• Alert Policy
• 通知チャネル1系統（運用開始後に追加拡張）

Phase 19: 会計連携自動化（高コスト）

• 会計CSV自動生成・配信
• 送信履歴・再送・例外対応

Phase 20: GWS非依存マルチテナント（Phase 15残タスク移行）

• 背景: Phase 15はGWS前提の実装。サービス展開にはGWS無し（独自ドメインあり、フリーメールNG）への対応が必要。
• 移行タスク: 1. Provisioning失敗の原因調査と修正 2. platform_audit_log の閲覧/出力要件詳細化 3. Phase 15クローズ判定（残タスク最終確認） 4. 本番反映対象の差分棚卸し（コード・Docs）
• 新規要件:
• GWS無し環境でのログイン・認証フロー
• 独自ドメイン（フリーメールNG）によるテナント登録
• GWS依存部分（OAuth Internal制約等）の汎用化

Phase 21: 発注種別の導入（低コスト）

• 発注作成時に「固定契約 / 臨時契約 / その他」を選択
• toriteki_orders に order_contract_type を保存
• 初期リリースでは ダッシュボード集計には反映しない（後続で必要に応じ対応）

12. ロール別ダッシュボード設計（Phase 6）

12.1 担当者（Staff）

12.2 承認者/拠点長（Manager）

12.3 管理者/役員（Admin/Executive）

13. PM決定事項

13.1 請求書発行方式: 自動生成 + 受託先確認（PM決定: 2026-02-04）

決定: 検収完了時に請求書を自動生成し、受託先が確認または差替え

フロー: 1. 検収完了（自動/手動）時に請求書を自動生成 2. 受託先へメール送信（請求書PDF添付） 3. 受託先が確認画面で内容チェック 4. 問題なければ「確認」、修正要なら自社請求書をアップロード 5. 確定後、発注元へ通知 + 会計連携データ生成

検収完了後の画面（受託先宛メール内リンク）:

【自動生成された請求書】
[PDFを見る]

○ この内容で請求を確定する（推奨）
○ 自社の請求書をアップロードする
  └ [ファイル選択] (PDF, 10MB以下)

13.2 検収確認（受託先）: オプション（デフォルトOFF）

決定: 実装はするが、デフォルトは無効。必要な場合のみ有効化。

• 大型案件で双方の認識齟齬を防ぎたい場合に有効化
• 受託先が明示的に「受け取りました」を残したい場合に有効化

13.3 PAID（支払完了）更新方法（PM決定: 2026-02-04）

決定: C（両方対応）- 会計連携CSV取込 + Toriteki手動入力

方式A: 会計連携CSVの支払完了取込

会計ソフトで支払実行
    ↓
支払完了CSV出力
    ↓
Toritekiにインポート（管理画面 or API）
    ↓
発注番号で照合 → billing_status = PAID

URL: POST /admin/payments/import

CSVフォーマット:

order_no,paid_date,paid_amount,payment_method,reference_no
ORD-2026-001,2026-03-31,110000,bank_transfer,TRF-20260331-001

方式B: Toriteki管理画面での手動更新

URL: POST /admin/order/<order_no>/mark-paid

権限: Admin のみ

画面:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
支払完了の記録
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

発注番号: ORD-2026-001
請求金額: ¥110,000
支払期日: 2026-03-31

支払日: [2026-03-31  ▼]
支払方法: [銀行振込 ▼]
メモ: [________________]

        [支払完了を記録]

処理共通

1. billing_status を PAID に更新
2. paid_at に支払日を記録
3. paid_by に処理者（CSV取込時は csv_import）を記録
4. 監査ログに記録
5. 受託先へ支払完了通知メール送信（オプション）

13.4 支払管理・会計ソフト連携

決定: 会計ソフト連携（TATEKAN経由 or 直接）

Toriteki（発注・納品・検収・請求）
        │
        ├── TATEKAN経由 ──→ GLOVIA会計 / Freee会計
        │
        └── 直接連携 ────→ GLOVIA会計 / Freee会計 / その他

連携方式: CSV（Phase 3）/ API（次期実装）
設定: 初回に連携先選択（途中変更は次期実装）

重要: 口座情報はToritekiに持たない - 受託先の振込口座情報は会計ソフト側のマスタで管理 - Toritekiは受託先名（支払先識別子）のみを連携

14. 会計ソフト連携仕様

14.1 連携パターン

14.2 連携方式

14.3 連携データ項目

支払予定データ（Toriteki → 会計ソフト）

注: 口座情報（銀行名、支店、口座番号）はToritekiに持たない

14.4 連携タイミング

14.5 設定画面（初回設定）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
会計ソフト連携設定
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【連携方式】
○ 連携しない（Toritekiのみで管理）
○ TATEKAN経由で連携
○ 会計ソフトに直接連携

【連携先】（上記で連携を選択した場合）
○ GLOVIA会計
○ Freee会計
○ その他（CSV汎用フォーマット）

【連携方法】
○ CSV出力（手動ダウンロード）
○ API連携（自動同期）← 次期実装予定

        [保存]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
※連携先の変更は次期実装予定です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

14.6 CSVフォーマット（会計ソフト別）

GLOVIA会計向け / Freee会計向け / 汎用フォーマット - 各会計ソフトの仕様に合わせたCSVテンプレートを用意 - 詳細フォーマットは実装Phase時に定義

15. 参考: ステータス遷移図（案B統合版 + 自動検収）

[DRAFT] ─作成→ [PENDING_APPROVAL] ─承認→ [APPROVED] ─送信→ [SENT]
                      │                        │
                      ↓                        ↓
                [REJECTED]                vendor_status:
                [RETURNED]                 PENDING → ACCEPTED/HOLD
                                                │
                                                ↓ (受諾時に自動)
                                          delivery_status:
                                           AWAITING_REPORT
                                                │
                                    ┌───────────┴───────────┐
                                    │                       │
                              (納品報告)              (納品催促)
                                    │                       │
                                    ↓                       │
                                DELIVERED ←─────────────────┘
                                    │
                    ┌───────────────┼───────────────┐
                    │               │               │
              (手動検収)      (猶予期間経過)    (検収不合格)
                    │               │               │
                    ↓               ↓               ↓
              INSPECTED      INSPECTED        INSPECTION_FAILED
             (手動検収)     (自動検収)              │
                    │               │               ↓
                    │               │        REWORK_REQUESTED
                    │               │               │
                    │               │               ↓ (再納品)
                    │               │         DELIVERED (再)
                    │               │               │
                    └───────┬───────┘               │
                            │                       │
                            ↓                       │
                    支払期日計算                    │
                   （検収日 = 受領日）              │
                            │                       │
                            ↓                       │
                   billing_status:                  │
                        PENDING                     │
                            │                       │
                            ↓ (請求書確認/アップロード)
                        INVOICED ←──────────────────┘
                            │                  (再検収後)
                            ↓ (CSV取込 or 手動)
                          PAID

※猶予期間: 通常7暦日、月末7日以内は締め日優先
※自動検収時: auto_inspected = true
※物品の場合: 検収時に「納品請書同時発行」オプションあり
※INSPECTION_FAILED 状態では請求フロー進入禁止

16. 変更履歴

End of Document

TATEKAN Toriteki 要件定義書（Draft）

Version: 0.5 Date: 2026-01-20 Author: GeminiCLI (PL Deputy), ClaudeCode (PL Deputy / QA Practitioner) Target Deadline: 2025-12-31 (historical) Last Updated: 2026-02-10 (セキュリティ仕様を非公開別紙へ分離)

1. 概要と目的

1.1 背景

2026年1月1日施行の「中小受託取引適正化法」（通称：取適法、旧・下請法の全面改正）および2024年11月施行の「フリーランス・事業者間取引適正化等法」（フリーランス新法）に対応するため、発注から支払いに至る一連の取引プロセスをデジタル化し、法的遵守（コンプライアンス）と業務効率化を同時に実現するシステムを構築する。 従来のGoogle Formベースの運用を刷新し、TATEKAN の連携オプション機能として実装する。

1.2 目的

• 法定必須事項（3条/4条書面相当）を含む発注書の電子交付。
• 取引先（受注者）による意思表示（受諾/辞退）のログ記録と、契約成立時の「発注請書」自動発行。
• 納品・検収・請求プロセスの進捗管理と、期限管理（リマインダー）による遅延防止。
• 多言語対応（日/英/中）によるグローバルなサプライチェーン対応。

1.3 現状ステータス（2026-02-09 時点）

• Phase 6 UI（発注タイプ/支払条件/60日ガード）は Staging 実装・検証完了。
• ログイン後はダッシュボードへ遷移。拠点が1つの場合は自動選択で拠点ダッシュボードを表示。
• Admin は拠点未選択でもメニュー表示（current_branch=ALL）に対応。
• Phase 9 として、拠点切替時のダッシュボード数値と発注履歴件数の不一致を本番で解消。
• admin/privileged の /orders が selected_branch を尊重し、拠点別集計と一致。
• 取適法リスク一覧の拠点反映が一致。
• ユーザー管理CSV（エクスポート/インポート）を Phase 13 に統合（即時対応）。
• Phase 15（マルチテナント: GWS前提版）✅ 完了・Phase 16（証跡保全: ストレージ計画）・Phase 17（独自ドメイン）・Phase 18（運用アラート）・Phase 19（会計連携自動化）・Phase 20（GWS非依存マルチテナント）・Phase 21（発注種別）をロードマップに追加。
• 緊急課題: 外部ドメインのテナント利用者がログインできない可能性があるため、Phase 17（独自ドメイン/外部ログイン解放）を前倒しして対応する。
• セキュリティ実装詳細は非公開別紙へ分離（公開仕様では概要のみ保持）。

2. 業務フローと帳票

システムは以下のライフサイクルを管理する。

2.0 見積依頼フェーズ（新規仕様）

• 見積依頼〜提出〜比較〜採択〜発注自動起票を新規フェーズとして定義。
• 詳細仕様（正本）: docs/Tatekan/toriteki/toriteki_estimate_phase_spec.md
• 要点:
• 候補受託先（最大3社）へ見積依頼を同報し、受託先は手入力またはPDF添付で提出する。
• PDF添付時はAI（LLM）で明細を構造化抽出し、担当者が確認・修正する。
• 比較画面でスコアリング（価格70/納期20/評価10）を参考に、担当者が手動で採択する。
• 採択と同時に発注書を自動起票し、既存の発注→納品→検収→請求フローに接続する。
• 税区分不一致・金額不一致は担当者承認まで保留とし、全操作を監査ログに記録する。
• 見積原本・抽出結果・承認ログは7年保存（電帳法準拠）。
• 受託先向け通知は日本語のみ、担当者向け通知はユーザーの選択言語に従う。
• エンティティ設計・ロール権限・状態遷移の詳細は上記正本を参照。
• オプション化と統制（運用者・特権ロール）:
• 本機能はテナントごとの オプション機能 とし、運用者（特権ロール）が動的に有効/無効を切り替える。
• 新規テナント開設時はデフォルト 無効（OFF）。運用開始後でも運用者専用画面から有効化が可能。
• オプション無効時はUI（メニュー等）から非表示となり、バックエンドでもアクセスを厳格に遮断（403 Forbidden）する。
• 切り替え操作は運用者専用の運用ログに記録し、ガバナンスを確保する（詳細は非公開別紙を正本とする）。

2.1 発注（Order）

• アクター: 発注者（TATEKANユーザー）
• アクション:
  • 取引先を選択し、「発注書」を作成。
  • 下書き保存機能: 作成途中のデータを一時保存（バリデーション緩和、拠点内共有）。
  • 確認画面: 送信前に内容をプレビュー確認。
  • 送信: 確定後、取引先へメール通知。
  • 見積書の有無チェック: 発注画面にチェックボックスとアップロードエリアを表示。
• 必須項目（確定時）:
  • 給付の内容（品目、仕様、数量）
  • 下請代金の額（単価、総額） ※通貨は言語設定により JPY/USD 表示切替
  • 納品予定日（給付期日）
  • 検収完了予定日（検査完了期日）
  • 支払期日・方法
  • 納入場所・受領場所
  • 見積書の支払条件（見積書を根拠に設定）
• 帳票: 「発注書」（PDF/HTML）

2.2 受注（Acceptance）

• アクター: 受注者（取引先）
• アクション: メールで届いたリンク（認証付き）からポータルへアクセスし、「受注（承諾）」または「辞退」をクリック。
• 制約: 見積書の「確認」ボタンを押下しない限り、「受注（承諾）」および「保留（拒否）」は操作不可とする。
• システム動作: 受注ボタン押下時、「発注請書」 を自動生成し、双方へ交付。
• 帳票: 「発注請書」

2.3 納品（Delivery）

• アクター: 受注者
• アクション: 業務完了/出荷時にポータルで「納品報告」を行う。
• 帳票: 「納品書」（システムにて作成、またはアップロード）

2.4 受領（Receipt）

• アクター: 発注者
• アクション: 物品/役務の受領を確認し、「受領」ボタンを押下。
• システム動作: 受領日時を記録し、「納品請書（受領書）」 を自動発行。
• 帳票: 「納品請書（受領書）」

2.5 検収（Inspection）

• アクター: 発注者
• アクション: 内容を検査し、合否判定を行う（合格＝検収完了）。
• 帳票: 「検収書（合格通知書）」

2.6 検収確認（Inspection Acceptance）

• アクター: 受注者
• アクション: 検収結果を確認し、「確認（異議なし）」ボタンを押下。
• システム動作: 合意記録として 「検収請書」 を自動発行。
• 帳票: 「検収請書」

2.7 請求（Billing）

• アクター: 受注者（またはシステム自動）
• アクション: 検収完了に基づき請求データを確定させる。
• 帳票: 「請求書」

3. 機能要件

3.1 リマインダー通知機能

以下の期日に対し、発注担当者および取引先担当者へメール通知を行う。 - 対象日付: 納品予定日、検収完了予定日 - タイミング: - 3日前（予兆） - 1日前（直前） - 当日以降（遅延督促）

3.2 ユーザーインターフェース (UI)

• 発注者用（TATEKAN内）:
  • 既存の「Toriteki Placeholder」を拡張。
  • 多言語対応: 日本語（デフォルト）、英語、中国語（簡体字/繁体字）。
  • 通貨表示: 日本語選択時は「円」、それ以外は「USD」。
  • 発注履歴一覧・ステータス管理ダッシュボード。
• 受注者用（専用ポータル）:
  • ログイン不要（Token付URL）または軽量認証。
  • スマホ対応（レスポンシブ）。
  • アクションボタン（受注する、納品する、等）を大きく配置。

3.3 データ・セキュリティ（公開概要）

• データ:
  • 発注/取引先/同意等の業務データを保持する。
  • 監査・運用ログを保持し、追跡可能性を確保する。
• 安全対策（Staging）:
  • Staging環境では、誤送信防止や濫用防止などの安全策を講じる（詳細は非公開別紙で管理）。
• 非公開別紙:
  • セキュリティ実装の具体（認証・制御値・内部API・内部ログ条件等）は docs/Tatekan/toriteki/security_controls_private.md を参照。

3.4 マスターと権限

• マスターの正: 取引先、拠点（部門）、税率の正は TATEKAN 側とする。
• 入力権限: Toriteki の権限者全員が入力可能。
• 承認権限: 拠点管理者が承認。特権管理者も承認可能。
• 支払条件: 見積書（個別契約書）を第一エビデンスとし、発注画面の支払条件は見積書を根拠に設定する。

3.5 TATEKAN 連携（方針）

• イベント連携: 発注確定・承認結果は TATEKAN へ通知する方針。
• 実装: Webhook は TATEKAN 側の受け口（Cloud Run/Functions）で受信し、検証後に Firestore へ反映する想定。
• 状態: 方針は確定、実装は未着手。

4. 開発ロードマップ（12/31まで）

1. 要件定義 & DB設計: 12/25（完了）
2. Phase 1: 発注入力・保存機能: 12/25（完了）
   • 多言語化、下書き機能、Staging環境構築含む。
3. Phase 2: PDF生成・メール送信機能: 12/26
   • 発注書PDF生成、SendGrid/Gmail連携、送信ロジック。
4. Phase 3: 受注ポータル & 納品〜検収フロー: 12/27 - 12/29
   • 受注者画面、ステータス遷移ロジック、各帳票生成。
5. Phase 4: リマインダー & 仕上げ: 12/30
   • Cloud Scheduler/Jobs による通知バッチ実装。
6. 最終確認 & リリース: 12/31

5. 実装済み機能（2026-01-19 Step 1-5）

5.1 入力バリデーション（Step 1-2）

フロントエンド（JavaScript）: - 半角カタカナ（ｦ-ﾟ）の検出・エラー表示 - 全角英数字（Ａ-Ｚ、ａ-ｚ、０-９）の検出・エラー表示 - リアルタイムバリデーション（blur時にチェック） - エラー時のフォーカス遷移・スクロール

バックエンド（Python）: - 正規表現による二重チェック - validate_input() / validate_form_data() 関数 - エラー時は400レスポンス

UIコンポーネント: - ⓘ infoアイコン（ツールチップ付き） - .validation-error クラスによるエラーハイライト

5.2 ユーザー管理拡張（Step 3）

新規フィールド: - family_name（姓） - given_name（名）

多言語対応（4言語）: | 言語 | family_name | given_name | |------|-------------|------------| | 日本語 | 姓 | 名 | | 英語 | Family Name | Given Name | | 簡体字 | 姓 | 名 | | 繁体字 | 姓 | 名 |

用途: - 発注書PDFの「担当者名」として表示 - {family_name} {given_name} 形式で出力

5.3 拠点名変更（Step 4）

対象: - ALL_BRANCHES 定数（コード） - Datastore エンティティ（87件更新） - toriteki_users: 3件（branches配列） - toriteki_suppliers: 82件（branch_name） - toriteki_orders: 2件（branch_name）

5.4 発注書PDFフォーマット更新（Step 5）

レイアウト: - A4縦サイズ - 2カラム構成（発注元/受注先） - 区切り線による視認性向上

発注元情報: - 会社名: 合同産業株式会社 - 拠点名: branch_name - 担当者名: {family_name} {given_name} - 発行日時: YYYY年MM月DD日 HH:MM

受注先情報: - 取引先名 - 担当者（取引先の連絡先）

金額計算: - 小計: 商品金額合計 - 消費税（10%）: 自動計算 - 合計: 小計 + 消費税

フォント: - CIDフォント（HeiseiKakuGo-W5）試行 - 日本語対応

5.5 文言変更

5.6 見積書・承認フロー機能（2026-01-20 Phase 2）

5.6.1 見積書「あり」の場合（ファイルアップロード）

フロー: 1. 発注フォームで「見積書: あり」を選択 2. ファイルアップロードセクションが表示 3. PDF/画像ファイル（10MB以下）をアップロード 4. 発注確定時、GCSに保存 5. 取引先へのメールに見積書を添付

GCS設定: - バケット: gobms-toriteki-quotes - パス: quotes/{order_no}/{uuid}.{ext}

5.6.2 見積書「なし」の場合（自動生成＋承認フロー）

フロー: 1. 発注フォームで「見積書: なし（自動生成）」を選択 2. 承認者ドロップダウンが表示（同一拠点のManager一覧） 3. 承認者を選択して発注確定 4. システムが見積書PDFを自動生成 5. ステータスは「承認待ち」（PENDING_APPROVAL） 6. 承認者へ通知メール送信 7. 承認者が承認/却下/差戻しを実行 8. 承認後、取引先へ発注書+見積書をメール送信

承認者の選択ロジック: - 発注者の所属拠点と同じ拠点のManagerを一覧表示 - adminロールは全拠点で承認可能

5.6.3 承認画面・アクション

承認待ち一覧（/approvals）: - Manager/Admin権限のみアクセス可 - ナビゲーションに「承認待ち一覧」リンク表示 - 自分が承認者として指定された発注のみ表示

承認詳細画面（/approval/{order_no}）: - 発注内容の詳細表示 - 見積書PDFへのリンク - コメント欄（任意） - 3つのアクションボタン

アクション:

コメント欄バリデーション: - 半角カタカナ（ｦ-ﾟ）使用不可 - 全角英数字（Ａ-Ｚ、ａ-ｚ、０-９）使用不可

5.6.4 新規ステータス

5.6.5 見積書PDF自動生成フォーマット

レイアウト: - A4縦サイズ - タイトル: 「見 積 書」/ "Quotation" - 見積番号: QT-{order_no の数字部分} - 注記: order_no の内部形式は変更しない（保存キー/外部参照のため）。 - UI上は一覧などで order_no が短縮表示される場合があるが、URL/検索/CSV/監査はフル値を使用する。

構成:

┌─────────────────────────────────────┐
│            見 積 書                  │
│        Quotation                    │
├─────────────────────────────────────┤
│ 見積番号: QT-XXXXXXXX              │
│ 見積日: YYYY年MM月DD日              │
├─────────────────────────────────────┤
│ 見積先: 合同産業株式会社            │
│ 見積元: {取引先名}                  │
├─────────────────────────────────────┤
│ 品名: {件名}                        │
│ 数量: {数量} {単位}                 │
│ 単価: ¥{単価:,}                     │
├─────────────────────────────────────┤
│ 小計: ¥{小計:,}                     │
│ 消費税(10%): ¥{税額:,}              │
│ 合計: ¥{合計:,}                     │
├─────────────────────────────────────┤
│ 有効期限: {見積日+30日}             │
│ 備考: 本見積書は発注内容より自動生成│
└─────────────────────────────────────┘

5.6.6 通知メール

承認依頼メール（承認者宛）: - 件名: 【承認依頼】発注書 {order_no} の承認をお願いします - 内容: 発注番号、申請者、取引先、件名、金額、納品予定日

結果通知メール（申請者宛）: - 件名: 【通知】発注書 {order_no} が{承認/却下/差戻し}されました - 内容: 処理結果、承認者コメント（あれば）

5.6.7 Datastoreスキーマ追加

toriteki_orders 追加フィールド:

コンポジットインデックス追加:

- kind: toriteki_orders
  properties:
  - name: approver_email
  - name: status
  - name: updated_at
    direction: desc

5.6.8 多言語対応

承認フロー関連の翻訳（4言語対応）:

5.6.9 Staging テスト結果（開発用）

• レポート: docs/reports/20260120_staging_quote_approval_test_report.md
• 実施範囲: TC1/TC3/TC4/TC5
• TC2 (Admin 承認一覧) は自動化環境の権限制約によりスキップ
• 主要フロー（作成→承認依頼→承認→送信）は Staging で確認済み

5.6.10 ストレージ・セキュリティ方針（マルチテナント）

• 本節の実装詳細は非公開別紙 docs/Tatekan/toriteki/security_controls_private.md を正本とする。
• 公開要件では、テナント分離・データ保持・アクセス制御を実施する方針のみを定義する。

5.6.10-A マルチテナント登録フロー（Phase 15: GWS前提版 ✅ 完了）

• ログインTopの表示は「関係者専用」のみ（固定ドメイン名の画面表示は行わない）。
• 新規テナント招待は運用者（特権ロール）のみ実行可能。
• 招待後のステータスは以下を採用:
• INVITED, CONSENT_PENDING, CONSENTED, PROVISIONING, ACTIVE, FAILED, EXPIRED
• 登録フォーム入力項目:
• 会社名、郵便番号、住所、電話番号、主担当者メール、申請ドメイン
• 同意チェック（必須3項目）:
  • 利用規約同意（ToS）
  • プライバシーポリシー同意
  • 電子取引同意
• バリデーション:
• 主担当者メールドメインと申請ドメインが不一致の場合は 登録不可（NG）
• フリーメールドメインは 拒否
• 必須3同意のいずれか未チェックは 登録不可
• 同意取得時は監査証跡として「同意日時・IP・User-Agent・同意文書バージョン（ToS/Privacy/Electronic）」を保存する
• 登録処理:
• 同意後に PROVISIONING でテナント作成処理
• 作成成功で ACTIVE、失敗で FAILED
• ACTIVE 遷移時に登録担当者へ完了通知
• テナント開設直後の初期状態:
• 履歴0件、取引先0件、発注0件、拠点0件（空）を基本とする
• ACTIVE 遷移時に初期ユーザー（owner_email）を admin ロールで自動作成する
• 初回オンボーディング（必須）:
• 初期ユーザーの初回ログイン時はウィザードを強制し、完了まで業務画面へ遷移不可
• Step1: 氏名（姓・名）入力を必須
• Step2: 拠点を最低1件作成を必須
• Step3: 権限説明（admin/manager/hub_manager/staff/viewer/inspector/branch_viewer）を表示
• 途中中断（ブラウザクローズ/タイムアウト）を許容し、次回ログイン時に未完了Stepから再開
• Step1完了・Step2未完了状態（IN_PROGRESS）を許容
• 詳細仕様: docs/Tatekan/toriteki/toriteki_tenant_onboarding_spec.md
• 多言語要件:
• ステータス文言、警告、エラーは選択言語に応じて表示（日本語選択時は日本語）。
• 初回オンボーディングの文言も選択言語に応じて表示する。
• 監査ログ要件:
• 招待送信/再送、同意、作成開始、成功/失敗、ドメイン不一致拒否、フリーメール拒否を記録する。
• 初回オンボーディング開始/完了、氏名登録完了、初回拠点作成完了を記録する。
• 運用者（特権ロール）は全テナント閲覧を許可する。
• テナント管理者向け監査ログには運用者操作を表示しない。
• 運用者操作は運用者専用の運用ログに記録し、テナント側の監査ログとは分離する（詳細は非公開別紙を正本とする）。

5.6.11 セキュリティ対策（実装）

• 非公開別紙 docs/Tatekan/toriteki/security_controls_private.md を参照。
• 公開文書では個別防御ロジック・制御値・内部API仕様は記載しない。

5.6.12 セキュリティ Phase B 再テスト（Staging）

• セキュリティ検証の詳細結果は非公開別紙で管理する。

5.6.13 セキュリティ Phase B 再再テスト（Staging）

• セキュリティ検証の詳細結果は非公開別紙で管理する。

6. 今後の開発予定

~~Phase A-2: 見積書PDF設計~~ ✅ 完了（2026-01-20）

• ~~発注書と同様のフォーマット~~
• ~~見積書有無のラジオボタン~~
• ~~見積書自動生成機能~~
• 実装内容: セクション5.6参照

~~Phase A-3: 発注メール文面設計~~ ✅ 完了（2026-01-20）

• ~~取引先向けメール本文~~
• ~~SendGrid連携~~
• 実装内容: 承認後メール送信、通知メール実装済み

~~Phase B: 受託/保留ボタン~~ ✅ 実装済み

• 取引先（受託先）がログイン不要の専用URLから「受諾」「保留（拒否）」を返すフローを実装済み。
• 運用・セキュリティ実装詳細は非公開別紙参照。

Phase 16: 証跡保全（ストレージ計画）

• 実装済み: 見積書/検収証明/請求書/添付など、業務上必要なファイルのGCS保管は実装済み（例: gobms-toriteki-quotes）。
• 残作業（Phase 16）: 証跡保全を「設計 + 運用 + 監査観点 + 災害復旧」を含めて確定し、運用可能な状態にする。
• 具体のセキュリティ実装値（保持期間、ロック手順、内部運用値、アクセス制御等）は非公開別紙参照。

Phase 16 計画（提案）

目的 - 電子帳票・添付ファイル・イベント証跡を、監査/不正対策/復旧の観点で「保存ポリシーが明確で、運用できる状態」にする。

対象データ（例） - 見積書（アップロード/自動生成） - 発注書/検収証明/納品請書/請求書（自動生成） - 取引先添付（受諾時/納品時/請求時） - 同意関連の記録（本文は別管理、同意の事実/時刻/版）

成果物 - 公開Docs（本書）: どのデータを、どの分類で、どの責務で保存するか（高レベル方針） - 非公開別紙: 保持期間/アクセス制御/改ざん検知/ロック運用/監査の具体、運用チェックリスト - 運用Runbook（非公開）: 復旧手順（誤削除/漏洩疑い/リージョン障害を想定）

実装・運用タスク（最小セット） 1. データ分類と命名規約の確定（prefix/ファイル名/メタ情報） 2. アクセス制御（作成者/閲覧者/運用者の責務分離） 3. 保持・削除ポリシー（ライフサイクル）を決め、運用手順化 4. 証跡保全の運用（改ざん検知や監査観点の担保。具体は非公開別紙） 5. 復旧訓練（リストア手順の机上/最小テスト）

完了条件（Done） - 保存対象の全カテゴリについて「保存先・命名・アクセス・保持・復旧」の方針が確定している - 非公開別紙に運用チェックリストがあり、担当者が実行可能 - 最小の復旧テスト（1件）で手順が成立する

Phase 16 追加タスク（テナント初期化/初回オンボーディング）

1. 初期ユーザー自動作成 - テナント ACTIVE 化時に owner_email の toriteki_users レコードを admin ロールで自動作成。 - 既存ユーザー重複時は上書きせず、所属/状態のみ整合チェックを行う。
2. オンボーディング状態管理 - onboarding_status（NOT_STARTED / IN_PROGRESS / COMPLETED）を管理。 - onboarding_started_at / onboarding_completed_at を保持。
3. 初回ウィザード実装 - Step1（氏名必須）を保存し、途中中断を許容。 - Step2（拠点1件以上必須）完了後に Step3（権限説明）へ進行。 - 完了前はダッシュボード・発注等の業務画面をブロック。
4. 再開制御 - 次回ログイン時、onboarding_status != COMPLETED のユーザーは未完了Stepへ自動リダイレクト。
5. 監査ログ - first_login_wizard_started, user_profile_completed, first_branch_created, first_login_wizard_completed を記録。

Phase 20: GWS非依存マルチテナント（Phase 15残タスク移行）

• 背景: Phase 15はGWS（Google Workspace）前提の実装。サービス展開にはGWS無し（独自ドメインあり、フリーメールNG）への対応が必要。
• 前提: GWS導入済み企業向けのPhase 15実装は完了済み。
• 移行タスク: 1. Provisioning失敗の原因調査と修正 2. platform_audit_log の閲覧/出力要件詳細化 3. Phase 15クローズ判定（残タスク最終確認） 4. 本番反映対象の差分棚卸し（コード・Docs）
• 新規要件:
• GWS無し環境でのログイン・認証フロー
• 独自ドメイン（フリーメールNG）によるテナント登録
• GWS依存部分（OAuth Internal制約等）の汎用化

~~Phase D: リマインダー機能~~ ✅ 実装済み（※Phase番号の再採番は別途管理）

• 納品予定日/検収予定日/支払期日の自動通知（バッチ）を実装済み。
• Cloud Scheduler から日次で実行する構成を実装済み。