大和書房 kintone 発注書PJ 詳細設計書 v1.0

0.1 本ドキュメントの位置付け

大和書房 × オモシクの kintone 発注書PJ Phase 1 における実装レベルの詳細設計を全領域統合した設計書。

0.2 読み方のガイド

0.3 v3.4 設計の核心

1.1 システム全体構成

flowchart TB
    subgraph EXT["👥 外部"]
        EDITOR["編集者"]
        SUPPLIER["取引先"]
        TAKAHASHI["高橋さん"]
    end

    subgraph KIN["☁️ 大和書房 kintone"]
        APP_PO["📋 発注書アプリ
5パターン統合・PDF生成"]
        APP_SM["👤 取引先マスタアプリ
新規登録フロー受け皿"]
        APP_PR["💰 支払依頼アプリ
発注書から派生"]
        APP85["📚 書籍マスタ App85
THINK's同期 既存"]
        APP_SH["🆕 新刊レコード①
新刊フロー連携先 v2"]
    end

    subgraph M365["☁️ 大和書房 Microsoft 365"]
        PA["⚡ Power Automate
3フロー"]
        MSF["📝 Microsoft Forms
取引先入力"]
        OUTLOOK["📧 Outlook
自動メール"]
        SP["💾 SharePoint
ログ"]
    end

    subgraph EXT_SYS["🔌 外部基幹"]
        THINKS["THINK's
印税・支払処理"]
        FREEE["freee会計"]
    end

    EDITOR -- 発注書作成 --> APP_PO
    APP_PO -- lookup --> APP_SM
    APP_PO -- lookup --> APP_SH
    APP_SH -- lookup --> APP85

    APP_SM -- webhook --> PA
    PA -- メール --> OUTLOOK
    OUTLOOK -- To+CC --> SUPPLIER
    SUPPLIER -- 入力 --> MSF
    MSF -- onSubmit --> PA
    PA -- レコード更新 --> APP_SM
    PA -- ログ --> SP

    APP_PO -- 派生 --> APP_PR
    APP_PR -- CSV月次 --> TAKAHASHI
    TAKAHASHI -- 手動転記 --> THINKS
    TAKAHASHI -- 手動転記 --> FREEE

    style APP_PO fill:#dbeafe,stroke:#1e40af,stroke-width:2px
    style APP_SM fill:#fef3c7,stroke:#d97706,stroke-width:2px
    style APP_SH fill:#fce7f3,stroke:#db2777,stroke-width:2px
    style PA fill:#ede9fe,stroke:#7c3aed,stroke-width:2px

1.2 主要アプリ構成（新規3アプリ + 書籍lookup連携）

1.3 連携の特徴

• すべて大和書房テナント内で完結：Microsoft 365 + kintone のデータが大和書房側で一元管理
• 新刊フロー PJ との連携：書籍 lookup を新刊レコード①経由に統一（v2）
• 外部基幹システム連携：THINK's / freee は手動転記（自動化は Phase 3 で検討）
• Power Automate Premium 月¥2,248 + 西川用 M365 月¥1,874 = 月¥4,122

2.1 コンテクスト

v3.3 までは「書籍マスタ App85 を拡張（ステータス・担当編集者・仮タイトル追加 + 検索マッチング画面）」する設計だったが、2026-06-05 新刊フローキックオフで 4アプリ確定スコープ + 新刊レコード①が書籍lookup の真のハブ 設計が確定したため、設計コンフリクトが発生。

2.2 決定（D1〜D6）

2.3 v3.3 → v3.4 変更サマリ

2.4 段階移行スケジュール

3.1 フィールド設計（全32項目・3区分）

編集者最小入力（4項目）→ 取引先本人入力（19項目）→ 高橋さん確定（9項目）の3段階で完成。

3.1.1 Phase A-B：編集者入力（最小限・30秒）

3.1.2 Phase D：取引先本人入力（Microsoft Forms 経由）

19フィールド：基本情報（5-11）/ 連絡先（12-17）/ インボイス・税務（18）/ 銀行口座 🔒（19-24）。詳細は app-supplier-master.md §2.2 参照。

3.1.3 Phase F：高橋さん入力（最終確定）

9フィールド：著作権者コード（PK・THINK's 採番）/ 源泉徴収税率 / 支払方法 / ステータス / 取引先タイプ / 表記揺れ別名サブテーブル / 備考。

3.2 ステータス遷移

stateDiagram-v2
    [*] --> input_requesting: 編集者が新規登録
    [*] --> paper_operation: メアド空で登録
    input_requesting --> input_done: 取引先がフォーム送信
    input_requesting --> expired: 14日経過
    expired --> input_done: フォーム送信
    expired --> archived: 30日経過
    paper_operation --> confirmed: 高橋さん紙回収+手動入力
    input_done --> confirmed: 高橋さんTHINK's転記+コード反映
    confirmed --> suspended: 取引停止
    suspended --> archived
    archived --> [*]
    confirmed --> [*]: 発注書 lookup 可能

3.3 権限設計（二層防御）

3.4 ビュー設計（9ビュー）

「自分の登録」「取引先入力依頼中」「取引先入力済（高橋確認待ち）」「期限切れ警告」「正式登録完了」「紙運用」「アーカイブ」「取引先タイプ別」「機密情報ビュー」の9ビューを用意。詳細は app-supplier-master.md §6。

4.1 業務種別5パターン（5/19高橋MTG確定）

4.2 新刊レコード①連携（ADR-001 反映）

v1（6月リリース）は App85 直接 lookup、v2（7-8月）で新刊レコード①連携に切替。

sequenceDiagram
    autonumber
    actor E as 編集者
    participant PO as 発注書アプリ
    participant SH as 新刊レコード①
    participant SF as 新刊フロー① UI

    E->>PO: 「書籍／企画」検索
    PO->>SH: lookup（新刊番号）
    alt 該当書籍あり
        SH-->>PO: 書名/著者/ISBN/担当編集者を返す
        PO->>PO: 発注書に自動コピー
    else 該当書籍なし
        SH-->>PO: ヒットなし
        PO->>E: 「📚 新刊フローで新規登録する」リンク表示
        E->>SF: 新刊フロー① で最小入力
        SF-->>E: 新刊番号取得
        E->>PO: 戻って lookup 選択
    end

4.3 複製機能（CORE 7）

自分の過去発注書を複製して新規作成。だいわlog連載月次発注 / 定期取引先（チコルズ等）/ 同一書籍の追加発注で入力負荷-70〜80%削減。

4.4 PDF生成・「支払依頼を作成」ボタン

確定ステータスで PDF 自動生成（C案 Cloud Run + Puppeteer or jsPDF）。「支払依頼を作成」ボタンで支払依頼アプリへ自動派生、取引先・書籍・金額を引き継ぎ。

5.1 主要フィールド

5.2 ワークフロー（2ステップ）

編集者申請 → 高橋さん最終確認・支払日入力。河合さんは Phase 1 では関与なし（5/19 高橋MTG訂正）。

5.3 月次CSVエクスポート

毎月末に「支払予定月」フィルタでCSV出力。THINK's印税入力・freee会計取引登録への手動連携。Phase 3で自動化検討。

6.1 データモデル

erDiagram
    BISHO_MASTER ||--o| SHINKAN : "lookup 書誌コード/ISBN"
    SHINKAN ||--o{ PURCHASE_ORDER : "lookup 新刊番号"
    BISHO_MASTER {
        string shosi_code PK "書誌コード App85 既存"
        string isbn_code "ISBN"
        string title "書名"
    }
    SHINKAN {
        string shinkan_no PK "新刊番号"
        lookup bisho "書誌マスタ参照"
        user editor "担当編集者 lookup元"
        date deliver_fix "搬入確定日"
    }
    PURCHASE_ORDER {
        string order_no PK "発注番号"
        lookup shinkan "新刊レコード参照 lookup先変更"
        lookup supplier "取引先参照"
    }

6.2 lookup 自動コピー項目

6.3 T1書名追従

新刊レコード①の書名が変更されると、関連発注書の書名（コピー）を一括更新。kintone JS の app.record.edit.submit.success イベントで実装。詳細は §8 §7 title-sync.js。

6.4 段階移行（再掲）

v1（6月、App85直接） → v2（7-8月、新刊レコード①切替）→ v3（9月〜、編集部浸透）。詳細は §2.4 + integration-with-shinkan-flow.md §7。

7.1 Power Automate 3フロー構成

Flow_SupplierInvite（取引先招待メール送信）

Flow_FormResponse（フォーム回答→kintone反映）

Flow_ScheduledReminder（督促・期限切れ・アーカイブ）

7.2 Microsoft Forms 設計（7セクション・24質問）

7.3 HMAC セキュリティ設計

8.1 ファイル構成

scripts/kintone-js/
├── common/         # 共通 config + utils + API ラッパー
├── purchase-order/ # 発注書アプリ JS
├── supplier-master/# 取引先マスタ JS
├── payment-request/# 支払依頼 JS
└── book-master-link/ # 書籍マスタ × 新刊レコード連携 JS

8.2 主要 JS 機能（9種）

8.3 実装スケジュール

9.1 全体スケジュール

gantt
    title Phase 1 リリーススケジュール
    dateFormat YYYY-MM-DD
    section Step 1-3
    マスタ整備           :a1, 2026-05-20, 9d
    発注書アプリ実装 v1  :a2, after a1, 13d
    支払依頼アプリ実装   :a3, after a2, 10d
    section パイロット
    Stage 1 総務UAT     :b1, 2026-07-01, 7d
    Stage 2 編集部      :b2, 2026-08-01, 14d
    section v2 切替
    新刊フロー①完成待ち  :c1, 2026-07-01, 30d
    発注書アプリ v2 切替 :c2, after c1, 7d
    section 全展開
    編集部全展開        :d1, 2026-09-01, 14d

9.2 取引先マスタ初期投入

9.3 段階パイロット

9.4 Phase 1 完了判定KPI

10.1 テスト階層・カバレッジ

10.2 重要 E2E シナリオ

1. E2E-001：編集者新規取引先登録 → メール送信 → 取引先フォーム入力 → kintone反映 → 高橋さんTHINK's転記 → 発注書 lookup（成功パス）
2. E2E-002：メアド無し → 紙運用 → 高橋さん郵送回収 → kintone手動入力（例外パス）
3. E2E-003：既存取引先の情報更新（口座変更等）（更新パス）
4. E2E-004：HMAC改竄検知 → 再送メール（セキュリティ）
5. E2E-005：7日経過督促 → 14日 expired → 30日 archived（タイマー）
6. E2E-006：発注書作成 → 派生 → 支払依頼 → 月次CSV エクスポート（業務フロー）

10.3 セキュリティ検証

• kintone 権限制御：編集者が機密フィールドにアクセスできないこと（JSなしでも）
• HMAC 検証：改竄URL、期限切れURL の拒否
• 個人情報マスキング：Power Automate 実行履歴・SharePoint ログに口座情報が平文で記録されていないこと

11.1 西川判断で決められること

11.2 先方（大和書房）に確認が必要

11.3 新刊フロー側と連携が必要

12.1 purchase-order PJ ドキュメント

12.2 新刊フロー PJ ドキュメント

12.3 議事録

• 5/19 高橋さん60分MTG — 業務種別5パターン確定 + 新規取引先登録フロー合意
• 4/28 窪田部長MTG — kintone第1弾選定・並行モデル合意

この §13 は ui-design-system v2 のアーキタイプ（型） を、ゴールド参照アプリ「支払依頼」の全画面で示す自己完結 HTML/CSS モックです。型は ポータル → ステータスタブ一覧 → 中央カードフォーム → 詳細（横サマリ＋承認フロー縦タイムライン）→ 4状態 の5層構成。発注書 / 取引先マスタは、この型の文言・データ項目を差し替えて横展開します。

墨（#1c1b19）＋朱（#d8553a）＋紙（#f7f4ee）のブランド。デザイン規律 — ①カードは淡色 tint 面＋右上チップ（端の色帯バー禁止）②朱は「主作成ピル1つ＋現在地」のみ（≦10%）③状態色は状態専用・中立補足は薄グレー（uk-point）④主役1要素を最大・脇役は小さく。文言・データ項目はゴールド参照 payment-request.app.js に忠実。

この §14 は §13 のアーキタイプ（型）を 発注書アプリ に展開した全画面モックです。CSS は §13 で定義した .uk-mock をそのまま再利用します（新規スタイルなし）。発注書は承認なし（提出後すぐ PDF 生成 → 担当者がメール送付）で、主役アクションがステータスで切り替わるのが支払依頼との差分です（確定前＝「発注書を確定」／確定後＝「支払依頼を作成」）。文言・データ項目は app-purchase-order.md に忠実。

墨＋朱＋紙のブランドと規律（淡色 tint 面＋右上チップ／朱は主作成ピル1つ＋現在地のみ／状態色は状態専用・中立補足は薄グレー）は §13 と完全に同一。発注書固有のキモは 業務種別5パターン（①書籍デザイン等＝校了日基準／②撮影・校正・拡材等＝納品日基準／③だいわlog連載＝納品日基準／④リーディング＝納品日基準／⑤その他例外🚫原則使用禁止）と、選択に応じた支払起算日タイプ・日付ラベルの条件表示（setFieldShown）。

この §15 は §13 のアーキタイプ（型）を 取引先マスタアプリ に展開した全画面モックです。CSS は §13 の .uk-mock をそのまま再利用します（新規スタイルなし）。取引先マスタの本質は「編集者が招待 → 取引先本人が Microsoft Forms で入力 → 高橋さんが THINK's 転記して正式登録」の3段オンボーディング。承認フロー縦タイムラインは「オンボーディング進捗」として、編集者登録→取引先フォーム入力→高橋確定 の3ステップで表します。文言・データ項目は app-supplier-master.md に忠実。

墨＋朱＋紙のブランドと規律（淡色 tint 面＋右上チップ／朱は主作成ピル1つ＋現在地のみ／状態色は状態専用・中立補足は薄グレー）は §13 と完全に同一。固有のキモは 口座情報など機密フィールドの段階開示＋権限（kintone フィールドアクセス権でサーバー側を締め、JS の setFieldShown は見せ方の最適化のみ＝二層防御）。