大和書房 × オモシク / kintone DXプロジェクト Phase 1

kintone 発注書アプリ
Phase 1 最終形ビジョン

編集部 → 総務(高橋)の業務委託発注 〜 支払依頼フローを kintone に集約し、4種フォーマット統合・PDF自動出力・取引先表記揺れ撲滅を実現する。

📅 2026-06-13 更新 v3.4(書籍マスタ ADR-001:新刊フロー連携前提に方針転換) 🎯 Phase 1: 6月 v1リリース → 7-8月 v2(新刊フロー①連携) → 安定運用 👥 推進: 西川(オモシク)/ 窪田(総務)/ 高橋(経理)
-70%
発注書1件作成時間
(10分 → 3分)
0件
表記揺れ差戻し件数
(月5-10件 → 0件)
-50%
高橋 月次支払処理時間
(案件あたり)
100%
PDF生成自動化
(手動 → ボタン1つ)
FINAL VISION

1. 最終形:何が実現されるか

編集部担当者が kintone 1画面で発注書を作成 → PDFが自動生成され取引先へ送付 → 同じレコードから支払依頼が派生 → 総務(高橋)が月次まとめて承認、という一気通貫の運用を実現する。

CORE 1

発注書 5種統合フォーム

①書籍デザイン等/②撮影・校正・拡材等/③だいわlog連載/④リーディング/⑤その他(例外) を1つの kintone フォームに集約。業務種別 × 支払起算日 のドロップダウン選択で 5 種を完全に吸収(⑤は例外運用用、原則使用禁止・経理 高橋さん事前相談必須)。

CORE 2

PDF 自動生成

「PDF生成」ボタン1つで規定レイアウトの発注書PDFを自動生成。kintoneレコードに添付ファイルとして保管され、紛失リスクゼロ・どこからでも参照可能。

CORE 3

取引先マスタ統一

「鷗来堂」「株式会社鷗来堂」「Ouraidou」が全部同じ取引先と認識される、表記揺れ吸収マスタ。高橋さんの THINKs 登録コード照合作業を大幅短縮。

CORE 4

支払依頼へワンクリック派生

発注書から「支払依頼を作成」ボタンで支払依頼レコードを自動生成。金額変更がある場合は理由を必須入力させ「発注書を作り直さない」運用ミスを構造的に防止。

CORE 5

シンプル承認ワークフロー

編集部担当者 → 総務(高橋:支払日入力・最終確認)の 2ステップ を kintone プロセス管理で実装。河合さんは出版契約フロー(Phase 3)の担当で、本PJ(発注・支払)には関与しない。

CORE 6

月次集計・経理連携

支払予定月別の集計ビューで高橋さんの月次処理を効率化。CSV エクスポートで THINKs 印税入力・freee 会計取引登録へ連携(Phase 3で自動化)。

CORE 7 🆕

過去発注の複製機能

5/19 高橋MTG での新発見。自分が過去に申請した発注書を複製して新規作成可能。だいわlog連載(同額複数回)・定期発注(例:チコルズ山田さんへのカバー/本文デザイン)で「内容ほぼ同じ+一部だけ変更」の運用に対応し、入力負荷・金額ミスを大幅削減。権限は自分の過去発注のみ複製可(他人不可)。

CORE 8 🆕

新規取引先 セルフ登録フロー(B案 Microsoft Forms + Power Automate 採用)

5/19 高橋さま・西川MTGでの最大成果。新規取引先が発注の半数を占める課題に対し、編集者が最小項目入力 → 取引先本人にメール+Microsoft Forms自動送信(CC: 編集者・高橋)→ 回答が Power Automate で kintone マスタに自動連携 → 高橋がTHINKsに転記、という抜本フローを導入。Microsoft 365 既存基盤 + Power Automate Premium 月¥2,248 + 西川用 M365 アカウント月¥1,874 ≒ 月¥4,122で運用。詳細は §13 参照。

SYSTEM ARCHITECTURE

2. システム全体像

関係者・データの流れを1枚に集約。kintoneを中心に、THINKs・freee と疎結合で連携する。SharePoint は発注書PDF保管としては廃止(kintone添付ファイルで一元化)。

flowchart TB
    subgraph 編集部["👥 編集部担当者"]
        E1[発注書作成]
        E2[支払依頼へ派生]
    end

    subgraph kintone["☁️ kintone(中核)"]
        APP1[発注書アプリ
5種統合フォーム] APP2[支払依頼アプリ
ワークフロー付] M1[(取引先マスタ
表記揺れ吸収)] M2[(書誌マスタ
既存 1,245件)] end subgraph 総務["🏢 総務"] T2[高橋:支払日入力・最終確認] end subgraph 取引先["✉️ 取引先"] TS[著作権者:
デザイナー/著者/
イラストレーター等] end subgraph 外部["🔗 外部システム"] TH[(THINKs
著作権者マスタ 2,487件)] FR[freee会計] end E1 ==> APP1 APP1 --lookup自動--> M1 APP1 --lookup自動--> M2 APP1 ==PDF自動生成==> TS E2 ==> APP2 APP1 ==派生ボタン==> APP2 APP2 ==> T2 T2 -.月次CSV手動DL.-> FR T2 -.月次CSV手動DL.-> TH TH -.初期CSV手動取込
2026-05-15 受領済.-> M1 style APP1 fill:#dbeafe,stroke:#1a56db style APP2 fill:#cffafe,stroke:#0891b2 style M1 fill:#d1fae5,stroke:#16a34a style M2 fill:#d1fae5,stroke:#16a34a
━━▶太線(実線):自動処理(kintone 内蔵・JS・lookup・添付保管)
━▶細線:自動だが補助的(lookup 表示等)
┄┄▶点線:人が介在する手動操作(CSVダウンロード・取込)
INSIGHT
kintone は「業務の中核」、THINKs/freee/SharePoint は「外部の補助」という位置付け。すべての発注・支払データが kintone に集約されるため、過去履歴の検索・分析が一画面で完結する。
UI / UX MOCKUP

3. UI / UX イメージ

編集部担当者が日常使うフォームの叩き台。実際のkintone標準UIと比較しながらレビュー・改善する。以下は発注書アプリの実際の画面イメージです(確定したデザイン言語=墨+朱+紙のブランドで作成)。支払依頼・取引先マスタの全画面は §3 末尾リンクの詳細設計書を参照してください。

3-1. ポータル(ホーム=カスタムビュー)

① 役割
発注書アプリのランディング。世界観・全体の流れ・一覧へのハブ。標準一覧でなくカスタマイズビュー(type=CUSTOM)。
② 主役1アクション
一覧ヘッダー右の朱ピル「発注書を作成」(uk-btn--accent uk-btn--pill)。Hero の CTA は控えめ。
③ 4状態
一覧0件は uk-empty。読込/error/成功は 3-5 にまとめて掲載。
④ 使う部品
uk-hero / uk-hero-kpi / uk-flow / uk-listhead / uk-select / uk-statustabs / uk-pgriduk-pcard / uk-guide
発注書アプリ / ホーム(ポータル)
発注書アプリ
発注書を、作成から PDF・支払依頼までひと続きに。
編集部が業務種別を選んで発注書を作成・確定すると、その場で PDF を生成。取引先にメール送付し、そのまま支払依頼へつなげられます。
18
今月の発注件数
¥2,146,500
金額合計
3
PDF未生成
全体の流れ
01
作成編集部
編集部が業務種別を選び、発注書を作成します。
02
確定編集部
内容を確認し、発注書を確定します。
03
PDF生成・送付編集部
PDFを自動生成し、取引先へメール送付します。
04
支払依頼経理部
送付済みの発注書をもとに、支払依頼を行います。
発注書一覧
2026-0061PDF生成済
きみに届くまでの距離
スタジオ・ハル / ①書籍デザイン等
¥187,000
2026-06-11詳細 →
2026-0060確定
夜明けのコーヒー
フォトオフィス三上 / ②撮影・校正・拡材等
¥143,000
2026-06-10詳細 →
2026-0059確定
だいわlog 6月連載
だいわlog編集協力 / ③だいわlog連載
¥55,000
2026-06-09詳細 →
2026-0058下書き
星をつなぐ手紙
リーディング工房みお / ④リーディング
¥33,000
2026-06-08詳細 →
📖 ここから下は 使い方ガイド
使い方ガイド
このアプリの基本的な使い方と、業務種別の選び方・ステータスの見方をまとめました。はじめての方も、ここを読めば迷わず発注書を作成できます。
役割ごとの使い方
編集部(作成)
1「発注書を作成」を押す
2業務種別を選び、取引先・書籍・報酬を入力
3確定すると PDF が生成される
ポイント
業務種別を選ぶと、支払起算日タイプと日付の呼び方(受領(校了)予定日/納品予定日)が自動で切り替わります。
編集部(送付・支払)
1PDF を取引先にメール送付
2詳細から「支払依頼を作成」
3金額確定値だけ追記して申請
ポイント
同じ取引先・書籍で別の発注をするときは「複製して新規作成」が便利です(自分の過去発注のみ複製可)。
ステータスの見方
下書き
作成中の状態です。まだ PDF は生成されません。
確定
内容を確定した状態。PDF生成・支払依頼が可能です。
PDF生成済
PDF が生成された状態。取引先へ送付できます。
よくある質問
取引先がマスタに見つからない時は?
「新刊フローで新規登録する」リンク、または取引先マスタの「取引先を登録」から手続きしてください。確定(正式登録)後に発注書から選べるようになります。
業務種別の「⑤その他(例外)」はいつ使う?
①〜④に当てはまらない例外時のみ。原則使用禁止です。使う場合は事前に高橋さんへ相談してください。
PDF を作り直したい時は?
確定状態に戻して内容を直し、再度「PDF生成」を実行してください。

3-2. 一覧(ステータスタブ+複製動線)

① 役割
状態で絞り込み、自分の過去発注から「複製して新規作成」で定期発注(だいわlog月次等)を素早く回す導線。
② 主役1アクション
各カードの「複製 →」(自分の過去発注のみ)。新規は一覧ヘッダー右の朱ピル。
③ 4状態
タブ絞り込み結果0件は uk-empty
④ 使う部品
uk-statustabs / uk-pgriduk-pcard / uk-link(複製動線)
発注書アプリ / 一覧(PDF生成済で絞り込み・複製動線)
発注書一覧(自分の発注書)
2026-0059PDF生成済
だいわlog 6月連載
だいわlog編集協力 / ③だいわlog連載
¥55,000
2026-06-09複製 →
2026-0052PDF生成済
だいわlog 5月連載
だいわlog編集協力 / ③だいわlog連載
¥55,000
2026-05-09複製 →
2026-0048PDF生成済
きみに届くまでの距離
スタジオ・ハル / ①書籍デザイン等
¥187,000
2026-04-28複製 →
複製の権限
「複製して新規作成」は自分の過去発注のみ対象です(他人の発注書は複製不可・5/19高橋MTG合意)。報酬明細以外をコピーして、月次連載・定期取引先への類似発注を素早く起こせます。

3-3. 新規作成 / 編集フォーム(中央カード・業務種別5パターン)

① 役割
編集部が業務種別・取引先・書籍・報酬明細を入力して発注書を作成。標準フォームを中央寄せ白カード+セクションコンテナに磨く(--uk-form-w 880px)。
② 主役1アクション
「発注内容を確認」→ 確認モーダル →(画面下の標準)「保存」で確定。
③ 4状態
保存失敗は event.error+該当 input ハイライト、成功は uk-toast--success(3-5)。
④ 使う部品
UIKit.formGroupsuk-formgroupuk-section)/ UIKit.fieldDescuk-fielddesc・複数カラムは uk-fieldhint ⓘ)/ 報酬明細サブテーブル / UIKit.confirmModal / setFieldShown 条件表示

業務種別の選択で、支払起算日タイプ(①=校了日基準/②③④=納品日基準)と日付ラベル(①=「受領(校了)予定日」/それ以外=「納品予定日」)が setFieldShown/ラベル切替で自動連動します。⑤その他(例外)は薄い面+チップで「🚫 原則使用禁止」を伝え、赤2px枠やグラデでの過剰な警告はしません(状態色=状態専用の規律)。

発注書アプリ / 新規作成(業務種別=①書籍デザイン等)
1基本情報
発注番号
発注日
発注元部署
2取引先・書籍情報
取引先i
取引先様付け
書籍/企画
新刊番号・書名・ISBN で検索(v1 は App85 直接 lookup、v2 で新刊レコード①へ切替)。見つからない時は「📚 新刊フローで新規登録する」へ。
著者名(コピー)
担当編集者(コピー)i
3業務内容
業務種別
①書籍デザイン等 / ②撮影・校正・拡材等 / ③だいわlog連載 / ④リーディング / ⑤その他(例外)
業務内容詳細
報酬明細
内容/単価/数量/金額を行で追加(複数行可)。合計は自動計算されます。
内容
単価
数量
金額
装丁一式(カバー・本文・DTP)
160,000
1
160,000
カバーイラスト
27,000
1
27,000
合計金額(税抜)
消費税率
合計金額(税込)
4納品・支払条件
受領(校了)予定日i
検収予定日
支払起算日タイプ
業務種別=①書籍デザイン等のため「校了日基準」を自動選択(setFieldShown)。②③④では「納品日基準」になります。
締日 / 支払日
納入場所
業務種別=⑤その他(例外)を選んだ場合
🚫 原則使用禁止 ①〜④に当てはまらない例外時のみ使用します。支払起算日タイプは手動選択になり、高橋さんへの事前相談が必須です。

3-4. 詳細(横サマリ+ステータス依存アクション+タブ)

① 役割
1件の発注書の全容。いまどの段階か(下書き→確定→PDF生成済→完了)を横サマリで示す。
② 主役1アクション
ステータス依存:確定前=「発注書を確定」/確定後=「支払依頼を作成」。PDF生成は ghost(脇役)。
③ 4状態
PDF未生成(確定だが未生成)はステッパーで現在地を示す。空/読込/error/成功は 3-5。
④ 使う部品
UIKit.banner / UIKit.stepper(横型)/ UIKit.tabs(内容/関連支払依頼)

⚠️ 上部(バナー+ステッパー+タブ)と本文は同じ中央幅(--uk-form-w 880px)に揃える。ただし地色は揃えない — 上部は kintone グレー地のまま=上下の境界を明示。発注書は承認フローが無いため、詳細タブは「内容/関連支払依頼」で構成します。

発注書アプリ / 詳細(確定・PDF未生成 → 主役アクション=支払依頼を作成)
発注番号2026-0060
取引先フォトオフィス三上
書籍/企画夜明けのコーヒー
金額(税込)¥157,300
下書き
編集部
2
確定
編集部
3
PDF生成済
4
完了
業務種別②撮影・校正・拡材等(納品日基準)
業務内容詳細撮影(書影・著者近影)
合計金額(税抜 / 税込)¥143,000 / ¥157,300
納品予定日 / 検収予定日2026-06-25 / 2026-07-02
支払期日納品日基準 / 毎月25日締め・翌月20日支払い

▼ 確定前(下書き)の詳細では、主役アクションが「発注書を確定」に切り替わります(ステータス依存・支払依頼ボタンは PDF生成済以降に表示):

発注書アプリ / 詳細(下書き → 主役アクション=発注書を確定)
発注番号2026-0058
取引先リーディング工房みお
状態下書き
1
下書き
編集部
2
確定
3
PDF生成済
4
完了

3-5. 4状態(空 / 読込 / エラー / 成功)

① 役割
happy path だけでなく unhappy path を設計する。一覧0件・読込・失敗・成功の4状態。
② 主役1アクション
空状態は「発注書を作成」、エラーは「再試行」=必ず次の1アクションを置く。
③ 4状態
このセクション自体が4状態の見本。空とエラーは視覚・トーンを分離。
④ 使う部品
uk-empty / uk-skeleton / uk-error-state / uk-toast--success
発注書アプリ / 4状態(unhappy path)
空状態(uk-empty)
該当する発注書はありません
最初の発注書を作成して、作成から PDF・支払依頼までをひと続きに進めましょう。
読込(uk-skeleton)
エラー(uk-error-state)
PDF の生成に失敗しました
テンプレートの読み込みに失敗した可能性があります。時間をおいて再試行してください。
成功(uk-toast--success)
PDFを生成しました
全アプリ・全画面の設計
上記は 発注書アプリの実際の画面イメージです。支払依頼・取引先マスタ を含む全アプリ・全画面(4状態・条件分岐・部品一覧まで)は、詳細設計書にまとめています。
🔗 詳細設計書(UIモック全画面)を見る
リポ内では docs/design/app-design-detail.html の §13(支払依頼)/§14(発注書)/§15(取引先マスタ)に対応します。本ブループリント §3 の発注書モックは、この詳細設計書 §14 と同一のデザイン言語・同一の型です。
USER FLOW BY PERSONA

4. ユーザー別 E2E フロー

関係者ごとに、いつ・何を・どう操作するかを整理。各ペルソナのストーリーが完結することを確認する。

編集部担当者
発注書作成 → PDF送付 → 支払依頼起票
1取引先と業務・報酬を決定(口頭・メール)
2kintone「発注書」アプリで新規作成
3書籍・著作権者を選択(lookupで自動入力)
4業務種別・報酬明細・予定日を入力
5保存 → 発注番号 2026-NNNN 採番
6「PDF生成」ボタンでPDFを自動添付
7PDFをメールで取引先へ送付
━ 納品確認後 ━
8発注書詳細画面で「支払依頼を作成」
9金額変更があれば修正値+理由を入力
10「申請」ボタン → 高橋へ通知
高橋さん(総務・経理)
支払日入力・最終承認・月次CSV連携
1「支払日未入力」ビューを開く(日次)
2各レコードの振込先・金額を最終確認
3支払日(振込予定日)を入力
4「最終承認」 → ステータス=完了
━ 月次処理 ━
5「月次CSV出力用」ビューを開く
6CSV エクスポート(ボタン1つ)
7THINKs 印税入力に投入(手動転記)
8freee に取引登録(手動転記、Phase 3でAPI化検討)
※ 河合さんはPhase 1では本フローに関与せず(出版契約フローのみ Phase 3 で担当)
END-TO-END DATA FLOW

5. E2E データフロー(ユーザー × システム × データ)

1件の発注 〜 支払完了までの全イベントを、3レイヤーで可視化。

sequenceDiagram
    autonumber
    participant U as 編集部担当者
    participant K as kintone
(発注書/支払依頼) participant DB as マスタ
(著作権者/書籍) participant PDF as PDF生成
(Cloud Run/Puppeteer) participant T as 高橋 participant X as freee/THINKs Note over U,X: ── 1. 発注フェーズ ── U->>K: 新規発注書を作成 K->>DB: lookup(著作権者・書籍) DB-->>K: 取引先情報・書籍情報を返却
(源泉徴収税率・インボイス状況含む) U->>K: 業務種別・明細を入力 K->>K: 合計金額・税額・源泉自動計算 U->>K: 保存(ステータス=確定) K->>PDF: 「PDF生成」ボタン押下 PDF-->>K: PDF を添付ファイルに保管 U->>U: PDFをメールで取引先送付 Note over U,X: ── 2. 納品〜支払依頼フェーズ ── Note over U: 取引先から成果物受領 U->>K: 発注書から「支払依頼を作成」ボタン K->>K: 発注書情報を引き継いで新規
支払依頼レコード作成 U->>K: 金額確定値・修正理由を入力 U->>K: 「申請」ボタン → ステータス=高橋確認中 Note over U,X: ── 3. 支払処理フェーズ ── T->>K: 「支払日未入力」ビューを確認 T->>K: 振込先口座・金額の最終確認 T->>K: 支払日(振込予定日)を入力 T->>K: 「最終承認」 → ステータス=完了 Note over T,X: ── 月次バッチ ── T->>K: 「月次CSV出力用」ビューを開く K-->>T: CSV エクスポート T->>X: THINKs 印税入力 / freee 取引登録(手動転記)
DATA SCHEMA

6. データテーブル蓄積イメージ(スキーマ)

kintone は 1アプリ = 1テーブル。フォームに入力された内容がレコードとして蓄積され、検索・集計・CSV出力できる。Phase 1 で動く4テーブルの中身を可視化。

flowchart LR
    subgraph master["📁 マスタテーブル"]
        M1[("著作権者マスタ
2,487件
38列")] M2[("書籍マスタ
1,245件
既存ID 85・不変")] end subgraph trx["📁 トランザクションテーブル"] T1["発注書
月50-150件
編集部が起票"] T2["支払依頼
月50-150件
発注書から派生"] end M1 -->|lookup
著作権者コード| T1 M2 -->|lookup
ISBN| T1 T1 -->|派生ボタン| T2 M1 -->|lookup
支払先| T2 M2 -->|lookup
関連書籍| T2 style M1 fill:#d1fae5,stroke:#16a34a style M2 fill:#d1fae5,stroke:#16a34a style T1 fill:#dbeafe,stroke:#1a56db style T2 fill:#cffafe,stroke:#0891b2

📊 4テーブルの想定蓄積件数

テーブル 種別 初期件数 増分 キー 主な用途
著作権者マスタ マスタ 2,487件(受領済) 年+50-100件 著作権者コード 発注書・支払依頼から lookup 参照
書籍マスタ マスタ(既存ID 85・不変) 1,245件 年+200件 ISBN 同上、書籍別の集計軸
発注書 トランザクション 0件(運用開始時) 月50-150件 = 年600-1,800件 発注番号(自動採番) 編集部が日常的に作成、PDF出力、支払依頼の起点
支払依頼 トランザクション 0件(運用開始時) 月50-150件 = 年600-1,800件 支払依頼番号(自動採番) 発注書から派生、高橋承認、月次CSV出力

📁 発注書テーブル 主要フィールド詳細

カテゴリ フィールド名 備考
基本情報発注番号文字列(自動採番)2026-0042 など
発注日日付デフォルト: 今日
担当編集者ユーザー選択デフォルト: ログインユーザー
ステータスドロップダウン下書き / 確定 / PDF生成済 / 取消
取引先・書籍著作権者lookupペンネーム・別名でも検索可
書籍/企画lookupISBN or 企画名で検索
業務内容業務種別ドロップダウン①書籍デザイン等 / ②撮影・校正・拡材等 / ③だいわlog連載 / ④リーディング / ⑤その他(例外🚫)
業務内容詳細テキストエリア例: 表1デザイン、本文DTP
報酬明細サブテーブル内容/単価/数量/金額(複数行)
合計金額(税抜/税込)計算フィールド自動計算
納品・支払受領/納品予定日日付業務種別によりラベル切替(JS)
支払起算日タイプドロップダウン校了日 / 納品日(業務種別から自動)
支払日(計算)計算フィールド翌月20日
出力PDF添付添付ファイル「PDF生成」ボタンで自動格納

📁 支払依頼テーブル 主要フィールド詳細

カテゴリ フィールド名 備考
基本情報支払依頼番号文字列(自動採番)PR-2026-0042
申請日日付デフォルト: 今日
ステータスプロセス管理申請中 / 高橋確認中 / 完了 / 差戻
発注書参照発注書lookup派生時に自動入力
書籍/企画lookup発注書からコピー
支払内容支払先表記文字列取引先名 or ペンネーム(編集可)
金額確定値(税抜)数値発注書からコピー、変更可
金額修正理由テキストエリア発注書と異なる場合のみ必須(JSで強制)
金額(税込)計算フィールド源泉徴収反映可
支払情報支払予定日計算フィールド支払起算日 + 締日 + 支払日から自動算出
支払日(振込)日付高橋が入力、最終承認時
振込先確認チェックボックス高橋が確認後ON
その他高橋メモテキストエリア編集部からは非表示
SHCEMA POINT
「データは消えずに永続保管される」のがkintone の最大の強み。月50-150件の発注書が積み上がれば、半年後には「あの著作権者には今年いくら払った?」「この書籍の原価はいくら?」がボタン1つで集計できる。Excel 個別管理では絶対にできない検索性が手に入る。
PDF GENERATION

7. PDF生成方式(C案採用、内製で月¥0〜数百円)

発注書を kintone から PDF として出力する仕組み。複数方式を検討した結果、Cloud Run + Puppeteer による内製(C案) を採用方針とする。

方式 月額 実装工数 保守 品質 採否
A. kViewer プラグイン ¥9,800 1日 低(GUI) ★★★ 候補(コスト発生)
B. プリントクリエイター ¥9,000 1日 低(GUI) ★★★ 候補(コスト発生)
C. Cloud Run + Puppeteer ← 採用 ¥0〜数百 4-5日 中(年0.5-1日) ★★★ ✅ 採用
D'. kintone JS + jsPDF + html2canvas
(注文書ジェネレーターと同方式)
¥0 3-4日 ★★(画像PDF) 予備案(品質要件次第で切替)

🏗️ C案 構成イメージ

flowchart LR
    A[編集部担当者] -->|PDF生成ボタン押下| B[kintone JS]
    B -->|HTTPS POST
レコードJSON| C[Cloud Run
Puppeteer] C -->|HTML雛形にデータ流し込み| D[HTML+CSS
レンダリング] D -->|PDF変換| E[PDFバイナリ] E -->|レスポンス| B B -->|kintone REST API| F[レコードの
添付ファイル欄に格納] F --> G[編集部担当者が
ダウンロード→メール送付] style C fill:#dbeafe,stroke:#1a56db style D fill:#cffafe,stroke:#0891b2

🛠️ 内製の保守ケース(年合計0.5〜1日程度)

発生タイミング 内容 工数
年1回GCP Node.js ランタイム deprecation 対応半日
年2-3回Puppeteer/Chrome のセキュリティパッチ反映1-2時間
必要時PDFレイアウト変更要望(社印位置等)半日〜1日
初期設計に含めればOKエラー時 Slack 通知設計込み
原則不要kintone API トークン期限切れ(無期限)
5/19 MTG で確認
PDF 品質要件次第で D'案(無料・ブラウザ内)にも切り替え可能。 確認したいこと:① 発注書PDFは印刷物として配るか?(画像PDFでは荒れる)② 社印は電子印影を貼るか? ③ レイアウト改修頻度はどの程度想定?
MONTHLY CSV EXPORT

8. 月次CSVエクスポート & ビュー設計

高橋さんの月次集計作業(現状2-3時間)を 30分以下 に短縮するための仕組み。kintone標準機能でほぼ実現可能。

🖥️ kintone ホーム画面からビューに到達する流れ

高橋さんが日次・月次にどう操作するかを実画面イメージで。

cy6vg2ycifc8.cybozu.com / ポータル(ホーム画面)
📌 ステップ① 高橋さんがkintoneにログイン → ホーム画面で「支払依頼」アプリのアイコンをクリック
📋
取引先マスタ
📚
書籍マスタ
📝
発注書
💰
支払依頼
← クリック
cy6vg2ycifc8.cybozu.com / 支払依頼 / レコード一覧
📌 ステップ② アプリ画面でビュー切替プルダウンを開く → 目的のビューを選択
▼ ビュー
デフォルト一覧
⚠️ 支払日未入力 (12件)
当月支払予定
月次CSV出力用
書籍別集計
→ 「支払日未入力」を選ぶと、
高橋さんが今日処理すべきレコードだけが一覧表示される
cy6vg2ycifc8.cybozu.com / 支払依頼 / 支払日未入力ビュー
📌 ステップ③ ビュー表示 → 各レコードをクリックして支払日入力・最終承認
支払依頼番号 申請者 著作権者 金額 支払予定日
PR-2026-0042荻田株式会社鷗来堂¥96,7502026-06-20
PR-2026-0043荻田合同会社チコルズ¥190,0002026-06-20
PR-2026-0044田中キャメレオン竹田¥120,0002026-06-20
... 残り9件
右上「エクスポート」ボタンで全件CSV出力可能(月次CSV出力用ビューと同じ動線)

📊 ビュー一覧(標準機能で事前設定)

事前にビューを設定しておけば、毎回検索せずに目的の画面に1クリックで飛べる。

対象者 ビュー名 抽出条件 用途
編集部「自分の発注書」担当編集者 = ログインユーザー自分の進行中案件チェック
「自分の支払依頼」申請者 = 自分支払処理状況確認
高橋「支払日未入力」ステータス=高橋確認中 AND 支払日=空日次の todo リスト
「当月支払予定」支払予定日 ∈ 今月月次の支払総額把握
「月次CSV出力用」ステータス=完了 AND 支払日 ∈ 指定月エクスポート対象抽出
全員「書籍別集計」書籍でグルーピング、金額合計1冊あたり総原価把握

📤 CSV エクスポートのフロー

高橋さん(毎月月末)
   │
   │【1】「月次CSV出力用」ビューを開く
   ▼
[kintone] 完了レコードを抽出表示
   │
   │【2】右上「エクスポート」→ CSV ダウンロード
   ▼
[ダウンロードフォルダ] payment_2026-05.csv
   │
   │【3-A】 THINKs 印税入力に手動投入(Phase 3で半自動化)
   │【3-B】 freee 取引登録に手動投入(Phase 3で API化検討)
   ▼
[完了] 月次経理処理完了

⏱️ Before / After

処理 Before(現状) After(Phase 1) 短縮
個別 .xlsx の収集・統合1-1.5時間0分(kintone集約済)-100%
取引先表記揺れ照合30分0分(マスタ統一済)-100%
月次集計表作成30分5分(ビュー切替)-83%
THINKs/freee 転記30分30分(手動継続、Phase 3でAPI化検討)
合計2.5-3時間35分-80%
5/19 MTG で確認(画面共有依頼)
高橋さんに 実際の THINKs/freee への転記作業を画面共有してもらう。kintone CSVのフォーマットを「後工程が一番楽になる形」に設計するため。
特に:① THINKs印税入力画面の入力項目・順序、② freee取引登録時の必須列、③ 区分・摘要等の自動入力に使える情報。
RECEIVED CSV ANALYSIS

9. いただいた CSV データから見えた、kintone 活用ポイント

高橋さんから 2026-05-15 にご共有いただいた「著作権者マスタ一覧.csv」を確認させていただきました。データの構造に合わせて kintone を設計することで、高橋さんの日々の業務がどう楽になるか を整理しました。

2,487
著作権者レコード
kintone に取り込み
38
項目数
振込先・税率まで完備
cp932
文字コード
(Shift_JIS、取り込み可)
3種
源泉徴収税率パターン
自動計算に活用

💡 kintone でこう活かせます(高橋さんの業務観点)

POINT 1

振込先の手入力がゼロになります

銀行コード、支店、口座番号、口座名義まで揃っているので、編集部が支払依頼を起票するときに 著作権者を選ぶだけで振込先情報が自動表示。転記ミスのご確認作業が不要になります。

POINT 2

「鷗来堂」「株式会社鷗来堂」が同じと認識できます

「著作権者名」と「ペンネーム」が別の項目で記録されているおかげで、表記揺れの照合作業(THINKs登録コード全件確認)が解消。編集部が誰の名前で書いても、高橋さんの目に届く時には正規名で揃います。

POINT 3

源泉徴収税率を自動判定できます

個人著者(10.21%)1,576件、法人(0%)871件、非居住者(20.42%)22件 のパターンが整っているので、支払依頼起票時に 源泉税額を自動計算。電卓いらず。

POINT 4

インボイス登録状況がフォームから見えます

登録済1,089件、未登録623件、登録予定なし226件、未確認548件 が整理可能。支払処理時に登録状況がひと目で分かる ようになります(インボイス番号自体は別管理かどうか5/19で確認させてください)。

QUESTION

👉 業務委託先と著者の判別方法を教えてください

「備考」欄に「著者」「イラストレーター」等の記載が散見されますが、明確なカテゴリ項目が見当たりませんでした。高橋さんは普段どうやって判別されていますか? 5/19で教えてください。

QUESTION

👉 軽微な気になり点もご確認させてください

「編集担当者」項目が2つあるのは「コード」と「氏名」の組合せでしょうか?/「個人法人」に「ユウチヨ」が1件あるのは入力誤り?/「論理削除」項目が全件空のため、停止された取引先のエクスポート方法も合わせて伺いたいです。

5/19 MTG ですり合わせさせてください
いただいたデータの構造に合わせて kintone マスタを設計します。上記の「👉 QUESTION」2点をクリアにできれば、Phase 1 のマスタ整備(Step 1)に即着手できる状態です。
EXTERNAL INTEGRATION FEASIBILITY

10. 外部システム連携マトリクス(フィジビリ・自動度)

どの連携が Phase 1 スコープ内か、どこまで自動化されるか、何が手動で残るかを明示。技術的な実現性(フィジビリ)と現状の不確実性も整理。

連携先 方式 データ/用途 頻度 Phase 自動化レベル フィジビリ
THINKs(著作権者マスタ) CSV 手動 DL → Python取込 著作権者マスタ初期投入
2,487件・38列(口座/源泉/インボイス完備)
初期 1 回 Phase 1 半自動 ✅ CSV受領済(2026-05-15)、想定以上にリッチ
THINKs(書誌) 既存 kintone アプリ ID 85 を活用 1,245 件の書誌マスタ
ADR-001で拡張せず不変(担当編集者等は新刊レコード①が保持)
必要時 Phase 1 完全自動
(既存活用)
✅ 既存運用あり、技術的問題なし
THINKs(取引先 RPA) 大和PC上 RPA
(Pywinauto)
取引先マスタ継続同期
(Phase 1 後)
週次/月次 Phase 2 後 半自動 🟡 PoC 必要、ビズロボ廃止判断と連動
THINKs(印税入力) kintone CSV 出力 → THINKs CSV 取込 月次印税支払対象データ 月次 Phase 3 手動 🟡 THINKs 側 CSV 取込機能の有無を窪田経由で要確認
freee 会計 kintone CSV 出力 → freee CSV 取込 月次取引登録(業務委託料・印税以外) 月次 Phase 3 手動 ✅ freee は CSV 取込標準対応、API もあり拡張可
SharePoint 非連携(kintone 内完結) 発注 PDF 保管
※既存 SharePoint 個人保管は廃止
Phase 1 完全自動
(kintone 添付)
✅ kintone 添付ファイルで代替、SharePoint 連携不要
DocuSign API 連携 業務委託契約・出版契約の電子署名発行 イベント駆動 Phase 2 完全自動 🟡 Phase 2 で技術検証、API 既存実績あり
Cloud Run + Puppeteer
(内製、C案採用)
kintone JS → HTTPS → Cloud Run 発注書 PDF 自動生成
HTML/CSS雛形でレイアウト管理
イベント駆動
(PDF生成ボタン押下時)
Phase 1 完全自動 ✅ GCP無料枠で運用可、月¥0〜数百
取引先送付
(メール)
編集部担当者が手動送付 kintone から PDF DL → メール添付 都度 Phase 1 手動 ✅ 既存運用継続、メール文面の自動化は Phase 2 検討
完全自動人間操作不要、システムが完結
半自動人間が起動、処理は自動
手動人間が操作・確認しながら実行
PHASE 1 のスコープ整理
Phase 1 で実装する連携:著作権者マスタ初期投入(CSV手動)/書誌マスタ活用(既存)/PDF生成(Cloud Run+Puppeteer 内製)/SharePoint代替(kintone内)/取引先送付(メール手動)

Phase 1 で「手動継続」する部分:取引先送付メール/月次CSV出力 → THINKs/freee 取込(月次バッチ)/著作権者マスタの追加更新

Phase 2/3 で自動化する部分:THINKs RPA 同期(Pywinauto)/DocuSign API/印税入力/freee 取引登録(API化検討)
⚠️ 5/19 高橋MTG で確認する論点
① 業務委託先と著者の判別方法:CSV「備考」列に「著者」「イラストレーター」等が散見されるが、明確なカテゴリ列なし。判別方法を確認。
② THINKs CSV エクスポート手順:誰がいつどう実施するか、自動化可否(Phase 1後 RPA 検討材料)。
③ THINKs/freee への CSV 転記実態:画面共有で実際の運用フローを確認、kintone CSV のフォーマット最適化に反映。
④ 論理削除の扱い:CSV内「論理削除」列が全件空のため、削除済みレコードの所在を確認。

🆕 新規著作権者が発生したらどう更新する?

著作権者マスタは「初期投入で終わり」ではなく、新規契約・情報変更が継続的に発生する生きたマスタ。発生源と更新パスを整理。

flowchart TB
    subgraph trigger["🎯 新規発生・更新が起きるシーン"]
        S1["新規契約締結
(業務委託 or 出版契約)"] S2["既存著作権者の
情報変更
(口座/住所/インボイス)"] S3["編集部が
マスタ未登録の
取引先と契約"] end subgraph thinks["📚 THINKs(基幹)"] TH[("著作権者マスタ
(正本)")] end subgraph kintone["☁️ kintone(運用)"] KM[("著作権者マスタ
(運用)")] KP["発注書/支払依頼
からlookup"] end S1 -->|高橋/河合が登録| TH S2 -->|高橋が更新| TH S3 -->|"⚠️ 高橋に追加依頼
(暫定運用)"| TH TH -.->|"Phase 1:
月次 手動CSV
取り込み"| KM TH ==>|"Phase 2:
RPA 週次/月次
半自動同期"| KM KM --> KP style TH fill:#fed7aa,stroke:#d97706 style KM fill:#d1fae5,stroke:#16a34a style S3 fill:#fee2e2,stroke:#dc2626
フェーズ 更新トリガー 更新パス 更新頻度・実現性
Phase 1(5-7月) 月次の経理締めタイミング 高橋さんが THINKs から CSV エクスポート → 西川提供スクリプトで差分抽出 → kintone API でアップサート ✅ 月次・半自動
(CSV出力は手動、取り込みは自動)
Phase 1(緊急対応) 編集部がマスタ未登録の取引先と契約 編集部 → 高橋さんへ追加依頼 → 高橋さんが THINKs に登録 → kintone マスタにも手動追加(or 次回CSV取込待ち) 🟡 都度・暫定手動運用
(運用負荷あり、Phase 2 で解消)
Phase 2 以降 同上+日次の情報変更 大和PC (NucBox4) 上で RPA(Pywinauto)が THINKs UI を自動操作してCSV出力 → 差分検出 → kintone 同期 🟡 週次/月次・半自動
(PoC必要、ビズロボ廃止連動)
Phase 3 以降(理想形) 新規契約締結のkintoneイベント kintone 契約アプリで新規登録 → Webhook で THINKs RPA 起動 → kintone マスタも同時更新 🔴 イベント駆動・半自動
(THINKs UI 自動化の安定運用が前提、長期構想)
⚠️ 期待値調整
「完全自動」は THINKs に API が無い限り技術的にハードルが高い。RPA(UI 自動操作)は実現可能だが、THINKs 画面構造の変更時にメンテが必要・実行中の例外ハンドリングが必要・大和PCの常時稼働前提など、「半自動」が現実的な落としどころ

Phase 1 では「月次手動 + 緊急時の都度手動追加」で運用開始し、運用負荷を実測してから Phase 2 の自動化スコープを決めるのが安全。
USE CASE BRANCHING

11. ユースケース別の判断分岐

業務種別・金額変更・取引先タイプによって、kintoneアプリが分岐する処理を整理。

🎨 ケース A:デザイン発注(責了日基準)
業務種別=「デザイン等」を選択
→ 支払起算日=「校了日基準」を自動選択
→ 受領(校了)予定日 を入力
→ 検収予定日 = 受領予定日 + 7日 で自動計算
→ PDF 出力時「受領(校了)予定日」表記を使用
📷 ケース B:撮影・校正発注(納品日基準)
業務種別=「撮影・校正等」を選択
→ 支払起算日=「納品日基準」を自動選択
→ 納品予定日 を入力
→ PDF 出力時「納品予定日」表記を使用
💻 ケース C:だいわlog 連載原稿
業務種別=「だいわlog連載」を選択
→ 書籍マスタ参照を「連載企画」フィルタに切替
→ PDF テンプレートが連載専用に変わる
→ 「掲載1回分」表記でPDF生成
📖 ケース D:翻訳前下読み(リーディング)
業務種別=「リーディング」を選択
→ 後注釈「翻訳業務委託契約時に印税に含む」を自動付記
→ 翻訳契約発生時に Phase 2 業務委託契約と紐付け可能
💰 ケース E:金額変更(発注後の追加作業)— 3案あり、5/19で運用合意
推奨 B案(支払依頼で吸収)
発注書はそのまま → 支払依頼の「金額確定値」を変更 → 「金額修正理由」を必須入力(JSで強制)
長所: 取引先への再送付不要、社内完結 / 短所: 発注書↔支払依頼で金額差が残る(修正理由で追跡)

A案(発注書改定): ステータス「改定中」→ バージョン2 → PDF再送付
C案(追加発注書): 差分のみ別発注書として起票、関連付けで紐付け
→ どのケースをどう運用するか、5/19高橋さんに確認
🚫 ケース F:取引先がマスタにない
取引先lookup で検索ヒットなし
→ 警告メッセージ「マスタにない場合は高橋さんへ依頼」
→ 高橋承認 + マスタ追加後に発注書作成再開
→ Phase 1 後半は編集部から直接マスタ追加申請可
IMPLEMENTATION ROADMAP

12. 実装ステップと現在地

Phase 1 を5つのStepに分解。現在はStep 0(設計準備)の中盤。

5/13-19
Step 0: 設計準備 進行中(90%)
マスタ設計・PDFサンプル試作・ヒアリング・THINKs連携PoC。
✅ 設計ドキュメント一式 / ✅ 著作権者マスタCSV受領(2,487件) / ✅ 河合さん除外を高橋確認済 / 🟡 5/19高橋MTGで詳細確定
5/20-28
Step 1: マスタ整備 未着手
著作権者マスタ kintone アプリ作成、CSV初期投入(38列 → kintone REST API、rapidfuzz名寄せ)。書籍マスタ App85 は不変(ADR-001)、lookup先は新刊レコード①連携で準備
5/29-6/10
Step 2: 発注書アプリ実装 未着手
5種統合フォーム(業務種別5パターン)、JS カスタマイズ(賢い動き)、Cloud Run + Puppeteer による PDF生成基盤
6/11-20
Step 3: 支払依頼アプリ実装 未着手
発注書からの派生、ワークフロー、月次集計ビュー、CSV エクスポート
6/21〜7月
Step 4: UAT・段階展開 未着手
Stage 1(前半):総務メンバーUAT、機能検証
Stage 2(後半):編集部パイロット 2-3名、実利用検証 → 全員ロンチ

📊 Step別 着手可能率(情報・条件が揃っている割合)

Step 0: 設計準備90%
Step 1: マスタ整備90%
Step 2: 発注書アプリ実装95%
Step 3: 支払依頼アプリ実装95%
Step 4: UAT・段階展開70%
BLOCKER UPDATE(2026-05-17)
🎉 Step 1 のブロッカーがほぼ解消:THINKs「著作権者マスタ」CSV(2,487件・38列)を 2026-05-15 に高橋さんから受領済。想定以上にリッチなデータ(口座/源泉徴収税率/インボイス状況フル装備)で、Step 1 着手可能。
→ 残るは 5/19 高橋MTG で運用詳細を確認 すれば即着手可能。

🔍 Step 4(UAT・パイロット)の事前確認・依頼事項

実装を進めながらのテスト・パイロット展開で、事前に高橋さん・窪田部長に依頼しておきたいこと。

タイミング 確認・依頼事項 依頼先 なぜ事前準備が必要か
5/20-28(Step 1中) kintone 管理者権限の最終確認、APIトークン発行 窪田部長 マスタアプリ作成にcybozu.com共通管理者権限が必須(付与済だが念のため)
5/29-6/10(Step 2中) 発注書PDFサンプル1枚のレビュー 高橋・松本 既存Excel発注書とのレイアウト差分を実物で確認、社印・宛名ルールの最終合意
6/11-20(Step 3中) Stage 1(総務UAT)参加者の確保 高橋・窪田部長 高橋さん本人+総務メンバー1-2名で実データ投入テスト、最低5営業日確保
6月中 編集部 kintoneライセンス追加判断 窪田部長・井坂部長 Stage 2 編集部パイロット(2-3名)に必要、月¥1,800/人の予算稟議
6月中 編集部パイロット候補者の推薦 井坂部長・松本 「触ってみてくれる前向きな2-3名」を事前リストアップ
6/21-28(Stage 1中) 過去1ヶ月分の発注実データで動作確認 高橋 仮想データではなく実データで「業務種別の境界」「金額変更ケース」をテスト
7月(Stage 2中) 編集部全員への展開タイミングの合意 窪田・井坂部長 2-3名パイロットで問題出尽くしを確認した後、全展開判断
7月以降(運用安定後) 旧Excel運用の正式廃止アナウンス 窪田部長 経由 全社 新旧併用は混乱の元、kintone一本化を社内通知
★ SUPPLIER ONBOARDING — B案 Microsoft Forms + Power Automate 採用版

13. 🚀 新規取引先登録フロー(B案 Microsoft Forms + Power Automate 採用)

5/19 高橋さま・西川MTGで発覚した「新規取引先が発注の半数を占める」という重大課題に対し、 取引先本人に Microsoft Forms 入力してもらう抜本フローを設計。属人運用・表記揺れ・支払直前の駆け込み登録を構造的に解消する。 ✅ 採用方針:B案 Microsoft Forms + Power Automate — 楽楽明細運用と統一・公式 kintone コネクタで実装簡素化

13.1 課題:発注の半数が新規取引先

PAIN 1

新規発生頻度が高い

シリーズ本でも別デザイナー/別イラストレーターになると完全新規。発注先の約半数が新規取引先

PAIN 2

支払直前の駆け込み登録

「先に欲しい」と頼んでも情報が出てこず、支払直前まで著作権者マスタが作れない。高橋さんが夜に対応する状況が常態化

PAIN 3

編集者経由のロス

取引先 → 編集者 → 高橋への伝言ゲームで誤記・抜け漏れ・表記揺れ発生。THINKsコード照合の追加作業が膨大。

PAIN 4

編集者の入力負荷

銀行情報・インボイス・マイナンバー有無等は編集者が把握する情報ではない。代理入力させると間違いも増える。

13.2 全体フロー(5/19 合意版)

sequenceDiagram
    autonumber
    actor E as 👤 編集者
    participant K as ☁️ kintone
発注書 / 取引先マスタ participant N as ⚡ Power Automate
(大和書房 M365テナント) participant F as 📝 Microsoft Forms actor S as 🏢 取引先本人 actor T as 👤 高橋さん participant TH as 💾 THINKs rect rgb(245, 240, 255) Note over E,K: Phase A — 編集者:発注時に取引先が未登録と発覚 E->>K: 発注書アプリで取引先を検索 K-->>E: 該当なし E->>K: 「🆕 新規取引先を登録」ボタンクリック end rect rgb(245, 255, 245) Note over E,K: Phase B — 編集者:最小項目を入力(30秒で完結) E->>K: 取引先登録アプリ起動
必須: ペンネーム/会社名 + メアド
任意: 業務種別、書類送付先 K->>K: レコード作成 (仮ID採番)
ステータス: 「📨 取引先入力依頼中」 end rect rgb(255, 250, 235) Note over K,S: Phase C — 自動送信:取引先本人にフォーム送付 K->>N: kintone webhook 発火(公式コネクタ「kintone レコード作成時」) N->>N: ユニークURL生成
Power Automate 式言語で HMAC-SHA256(kintone_id + secret)
?kintone_id={id}&token={hmac}&exp={timestamp} N->>S: 📧 メール送信(Outlook コネクタ)
To: 取引先本人
CC: 編集者 + 高橋さん
本文: 業務委託につき以下フォームに情報入力ください end rect rgb(235, 245, 255) Note over S,F: Phase D — 取引先:本人が情報入力 S->>F: フォーム入力
カナ・住所・口座・インボイス・源泉
マイナンバー有無 等 F-->>S: 送信完了画面 end rect rgb(255, 245, 250) Note over F,K: Phase E — 自動連携:kintoneマスタに反映 F->>N: 「フォーム回答送信時」トリガー発火 N->>N: HMAC token 検証 + 有効期限チェック
(Power Automate 条件分岐アクション) N->>K: kintone コネクタ「レコード更新」アクション
取引先IDで該当レコード特定
ステータス: 「✅ 取引先入力済」
機密フィールド(口座等)も自動セット K->>T: 通知(kintone内 + Outlook コネクタ経由メール) end rect rgb(255, 240, 240) Note over T,TH: Phase F — 高橋:内容確認 + THINKs転記 T->>K: レコード確認・必要に応じ補正 T->>TH: THINKsに手動転記 (コード採番) T->>K: 採番済THINKsコードをkintoneに反映
ステータス: 「🎉 正式登録完了」 K-->>E: 編集者に通知(発注書アプリで選択可能に) end
SO WHAT
取引先 → 編集者 → 高橋 の伝言ゲームを排除。取引先本人が直接フォーム入力するため表記揺れ・誤記が原理的に発生しない。 編集者の入力負荷も最小(30秒 = メアド+ペンネームのみ)。高橋さんの夜間駆け込み対応も不要に。

13.3 取引先マスタ アプリ仕様

📋 ステータス遷移

stateDiagram-v2
    direction LR
    [*] --> 入力依頼中: 編集者が新規登録
    入力依頼中 --> 入力済: 取引先がフォーム送信
    入力依頼中 --> 期限切れ: 7日経過で督促
    期限切れ --> 入力済: 取引先がフォーム送信
    入力済 --> 正式登録完了: 高橋がTHINKs転記+コード反映
    正式登録完了 --> 取引停止: 取引停止時
    正式登録完了 --> [*]: 発注書で選択可能
    取引停止 --> [*]
    

📊 フィールド設計(入力者別の必須/任意区分)

凡例:🟦 編集者入力(最小限)/ 🟧 取引先本人入力(詳細)/ 🟩 高橋入力(最終確定)/ 🔒 機密フィールド

# フィールド名 入力者 必須 フィールド型 備考
Phase A-B:編集者入力(最小限・30秒)
1ペンネーム / 会社名🟦 編集者文字列1行編集者が把握している呼び方。後で取引先本人が正式名で上書き可
2取引先メールアドレス🟦 編集者リンク(Email)フォーム送付先。無い場合のみ高橋さんに別途連絡(楽楽明細運用に準拠)
3業務種別(想定)🟦 編集者複数選択デザイン/イラスト/撮影/校正/ライティング/翻訳/監修/著者
4書類送付先(あれば)🟦 編集者文字列複数行取引先が改めて記入するため、把握範囲で OK
Phase D:取引先本人入力(フォーム経由)
5著作権者名(正式)🟧 取引先文字列1行法人格付き正式名
6著作権者名カナ🟧 取引先文字列1行半角カナ統一推奨
7ペンネーム(正式)🟧 取引先文字列1行編集者入力分から本人が修正
8ペンネームカナ🟧 取引先文字列1行
9郵送宛名🟧 取引先文字列1行「○○様」「○○御中」完全形
10郵便番号🟧 取引先文字列1行
11-13住所1-3🟧 取引先文字列1行都道府県/市区町村+番地/建物名
14電話番号🟧 取引先文字列1行
15個人 / 法人🟧 取引先ドロップダウン源泉徴収税率の自動判定に使用
16マイナンバー有無🟧 取引先チェックボックス個人の場合のみ。番号は本人別途送付(kintoneでは保持しない)
17居住 / 非居住🟧 取引先ドロップダウン
18インボイス登録状況🟧 取引先ドロップダウン登録済 / 未登録 / 登録予定なし
番号(T+13桁)はkintoneマスタで保持しない(5/19合意)
19銀行コード+銀行名🟧 取引先 🔒文字列1行機密フィールド
20支店コード+支店名🟧 取引先 🔒文字列1行機密フィールド
21口座区分🟧 取引先 🔒ドロップダウン普通預金/当座預金
22口座番号🟧 取引先 🔒文字列1行機密フィールド・閲覧権限は高橋・経理のみ
23口座名義(漢字+カナ)🟧 取引先 🔒文字列1行機密フィールド
Phase F:高橋入力(最終確定)
24著作権者コード(THINKs)🟩 高橋文字列1行PK。THINKs採番後にkintoneへ反映。RPA化のキー
25源泉徴収税率🟩 高橋数値0.00 / 10.21 / 20.42(個人/法人/非居住者)
26源泉徴収税計算区分🟩 高橋ドロップダウン税込 / 税抜
27支払方法🟩 高橋ドロップダウンFB振込 / 振込 / 現金
28ステータス🟩 高橋ドロップダウン入力依頼中/入力済/正式登録完了/取引停止
29取引先タイプ🟩 高橋複数選択業務委託先/著者/その他
30表記揺れ別名(サブテーブル)🟩 高橋サブテーブル別名/登録日/追加者の3列で複数行管理
31備考_kintone🟩 高橋文字列複数行kintoneで追記する補足
📝 高橋さんへの依頼事項(5/19合意)
上記フィールドの「必須/任意」「入力者区分」を高橋さん側でレビュー → 区分シートを西川さんに返送。 届き次第、本仕様を確定する。

13.4 取引先への送付メール本文(自動生成)

📧 自動送信メール(プレビュー)
To: {取引先メールアドレス}
CC: {編集部入力者メアド} / takahashi@daiwashobo.co.jp(高橋さん)
From: {フロー所有者の大和書房 M365 アカウント}(Power Automate の Outlook コネクタで送信、返信不要設定可)
件名: 【大和書房】業務委託のお取引に関する情報入力のお願い

{取引先様} 御中

このたびは弊社(株式会社大和書房)との業務委託のお取引、誠にありがとうございます。
ご担当の {編集者名} よりお取引情報の登録を承りました。

つきましては、お支払いに必要な情報のご入力にご協力をお願いいたします。
下記フォームより、5分程度でご入力いただけます。

▼ ご入力フォーム(個別URL・有効期限7日)
https://forms.office.com/r/{form_id}?kintone_id=12345&token=Hk8Bc3aF2pQv9ZdYxNmL4Rk6Wj7T0sUe&exp=1748908800
※ 上記URLはお客様専用です。他の方への転送はお控えください。
※ 有効期限を過ぎた場合は、CCの担当者または弊社経理担当(高橋)までご連絡ください。

ご入力内容:

  • お名前・ペンネーム・カナ表記
  • ご住所・ご連絡先
  • 個人 or 法人区分
  • インボイス登録状況
  • お振込先口座情報

ご入力後、自動的に弊社システムに反映されます。
ご不明な点は、CCの担当者または弊社経理担当(高橋)までご連絡ください。

引き続きどうぞよろしくお願いいたします。

株式会社大和書房
総務部 経理担当
本メールは大和書房kintoneシステムから自動送信されています。

📨 CC設計の意図
  • CC: 編集者 → 取引先とのやり取りが見える、入力遅延時にフォロー可能
  • CC: 高橋さん → 進捗が経理側で把握できる、内容に疑問あれば即座に介入可能
  • From: 自動送信アドレス → 個人アドレス露出を避け、運用引き継ぎ容易

13.5 フォーム回答 → kintone 自動連携の技術アプローチ比較

取引先がフォーム送信した後、kintone マスタに自動で反映する技術手段の3案を多角的に評価。

観点 A案 代替案: Google Forms + GAS 🎯 B案 採用:
Microsoft Forms + Power Automate
C案: kintone専用プラグイン
(フォームブリッジ等)
技術スタック Google Forms + Google Apps Script (GAS) Microsoft Forms + Power Automate Premium トヨクモ「フォームブリッジ」など kintone 連携プラグイン
初期構築工数 ◎ 低(GAS で 1-2日) △ 中(Power Automate 学習要、1-2日) ◎ 低(GUI設定で半日)
月額コスト ¥0(GAS無料枠で十分。Google Workspace契約は別途必要) ¥2,248/月のみ(Power Automate Premium 実装者1名分のみ契約で動作。現状未契約 × フォームブリッジ ¥9,000-/月
ライセンス対象範囲 実装者のGoogle Workspaceアカウントのみ(編集者・取引先・高橋さんは追加不要) 実装者1名のPremiumライセンスのみで動作(バックグラウンド実行のため編集者・取引先・高橋さんは追加不要) kintone契約(既存)+ プラグイン契約
ユニーク URL(取引先ID紐付け) ◎ 事前入力 URL ?entry.{question_id}={id} ◎ 事前入力 URL(同様の機能あり) ◎ kintone レコードIDを自動付与
楽楽明細運用との整合性 △ Google Forms(既存運用は Microsoft Forms)
取引先側UXはほぼ同等で大きな問題なし。デメリットは「IT部門が2系統のフォームツールを管理」「メアド回収データが2基盤に分散」
Microsoft Forms 365 を既に利用中(楽楽明細運用とフォーム基盤が統一) △ 新規ツール導入
取引先のUX ◎ アカウント不要、即入力可 ○ アカウント不要設定可 ◎ kintone非ユーザーでも入力可
kintone連携 △ GAS から REST API 呼び出し(自前実装) ◎ 公式 kintone コネクタあり ◎ kintone内完結(プラグイン提供)
セキュリティ(トークン検証) ◎ GAS でカスタム検証ロジック実装可 ◎ Power Automate でフロー検証可 △ プラグイン仕様に依存
運用保守負荷 △ GAS スクリプトの保守必要 ◎ ノーコード GUI で改修容易 ◎ プラグインベンダ保守
大和書房のIT資産との親和性 △ Google Workspace 個別契約必要 Microsoft 365 既導入(楽楽明細運用基盤) △ 新ベンダ追加
総合評価 ○ 代替案:Power Automate契約しない場合のフォールバック 🎯 採用:大和書房既存 Microsoft 365 基盤と統一・楽楽明細運用と整合・公式 kintone コネクタで実装簡素化 △ コスト高、新規ベンダ追加

13.6 採用案:B案 Microsoft Forms + Power Automate の詳細設計

🎯 採用判断の根拠(A案・C案との比較)
  • 🏢 大和書房既存 Microsoft 365 基盤と統一(楽楽明細経由のメアド回収運用も Microsoft Forms 365 ベース、フォーム基盤・データガバナンスを統合)
  • 🔌 Power Automate の公式 kintone コネクタを利用、ノーコード GUI で実装簡素化
  • 👤 西川用 大和書房 M365 アカウント発行で大和書房テナント内でフル実装可能(西川単独で純7日)
  • 💰 月¥4,122(Power Automate Premium ¥2,248 + M365 Business Standard ¥1,874)で長期運用
  • 🔄 運用引き継ぎ容易:フロー所有者を大和書房側1名に設定すれば、西川契約解除後もそのまま稼働継続
⚠️ 前提条件(Step 0 完了前に必須)
  • ① 大和書房側で Power Automate Premium ライセンス(¥2,248/月)契約(フロー所有者用、1ライセンスで動作可能)
  • ② 西川用に大和書房 Microsoft 365 アカウント発行(推奨:Business Standard ¥1,874/月、ゲスト招待では Power Automate Premium が適用困難なため正規ライセンス必須
  • ③ 西川アカウントへの権限スコープ設定(取引先マスタアプリ操作のみ、社内システム全体アクセスは不要)
→ 月額合計 ¥4,122/月。契約承認 + アカウント発行は 窪田部長 + 情シス対応で実装着手前のクリティカルパス。

13.6.1 アーキテクチャ全体構成

flowchart LR
    subgraph DAIWA_M365["☁️ 大和書房 Microsoft 365 テナント"]
        PA[("⚡ Power Automate
フロー所有: 大和書房側1名
実装: nishikawa@daiwashobo.co.jp")] FORM[("📝 Microsoft Forms
取引先入力用")] OUTLOOK[("📧 Outlook コネクタ
自動メール送信")] SP[("💾 SharePoint
ログ + フロー設定")] end subgraph DAIWA_KIN["☁️ 大和書房 kintone"] APP["取引先マスタアプリ
cy6vg2ycifc8.cybozu.com"] WEBHOOK["公式 kintone コネクタ
「レコード作成時」トリガー"] end subgraph EXT["👥 外部"] EDITOR["編集者"] SUPPLIER["取引先"] TAKAHASHI["高橋さん"] end EDITOR -- 新規取引先登録 --> APP APP --> WEBHOOK WEBHOOK -- イベント発火 --> PA PA -- ユニークURL生成 --> FORM PA -- メール送信 --> OUTLOOK OUTLOOK -- To: 取引先 / CC: 編集者・高橋 --> SUPPLIER SUPPLIER -- フォーム入力 --> FORM FORM -- 「回答送信時」トリガー --> PA PA -- HMAC検証 + kintone コネクタ「レコード更新」 --> APP PA -- 実行履歴記録 --> SP APP -- ステータス更新通知 --> TAKAHASHI TAKAHASHI -- THINKs手動転記 --> APP style PA fill:#dbeafe,stroke:#1e40af,stroke-width:2px style APP fill:#dcfce7,stroke:#16a34a,stroke-width:2px style FORM fill:#fce7f3,stroke:#db2777,stroke-width:2px
💡 全体構成のポイント
  • すべて大和書房テナント内で完結:データガバナンス・監査証跡が大和書房側で一元管理。オモシク経由のデータ流通なし
  • Power Automate 実行履歴は SharePoint に自動保存:個人情報マスキングを徹底したログ管理が可能
  • kintone 公式コネクタを利用するため、REST API ペイロード手書きの工数最小化

13.6.2 Power Automate フロー構成(フロー別の責務)

Power Automate に以下3フローを実装。すべて公式コネクタ + 式言語のノーコード設計、冪等性確保・エラーハンドリング込み

# フロー名 トリガー アクション構成 エラー時の挙動
1 Flow_SupplierInvite
取引先招待メール送信
kintone コネクタ
「レコード作成時」
(取引先マスタ)
① レコード詳細取得(kintone_id・取引先メアド・編集者)
② 変数初期化(exp = utcNow() + 7days)
HMAC-SHA256 トークン生成(式言語 + ScriptDirective)
④ Outlook「メールの送信(V2)」アクション
To: 取引先 / CC: 編集者 + 高橋さん
各アクションに 「実行条件」設定で失敗キャッチ → kintoneレコードに「⚠️ 送信失敗」フラグセット + 高橋さんに通知
2 Flow_FormResponse
フォーム回答→kintone反映
Microsoft Forms コネクタ
「フォーム回答送信時」
① フォーム回答詳細取得(kintone_id・token・exp 含む)
条件分岐:HMAC検証 + exp 有効期限チェック
③ kintoneコネクタ「レコード更新」アクション
ステータス: 「✅ 取引先入力済」
④ Outlook で高橋さんに完了通知
トークン無効時:取引先に「URL無効、再発行依頼」メール返信 / kintone通信失敗時:Power Automate 標準リトライ機能で3回再試行
3 Flow_ScheduledReminder
督促・期限切れ・アーカイブ
スケジュールトリガー
毎日 9:00 AM
① kintoneコネクタ「レコード取得(複数)」でステータス=入力依頼中のレコード走査
② 経過日数を式言語で算出
③ 条件分岐:
・7日経過 → 督促メール送信
・14日経過 → ステータス「⚠️ 期限切れ」変更
・30日経過 → アーカイブ
個別アクション失敗を「実行履歴」に記録、翌日のフロー実行で自動リトライ
💡 Power Automate のノーコード設計と式言語
Power Automate は基本的に GUI 操作で構築できるが、HMAC トークン生成や複雑な条件分岐は 式言語@{...} 記法)の記述が必要。 Microsoft 365 サブスクライバ向けの 「Office Script」でJavaScript相当の処理も差し込める。HMAC実装は Office Script を利用するのが堅牢。

13.6.3 ユニークURL設計(HMAC-SHA256 + Power Automate / Office Script)

// Microsoft Forms URL 構造
https://forms.office.com/r/{form_id}
  ?kintone_id=12345
  &token=Hk8Bc3aF2pQv9ZdYxNmL4Rk6Wj7T0sUe
  &exp=1748908800
※ Microsoft Forms は事前入力 URL パラメータを「隠し質問」として受領可能

// Office Script で HMAC-SHA256 生成(Power Automate から呼出)
function main(workbook: ExcelScript.Workbook, kintone_id: string, exp: string): string {
  const secret = workbook.getNamedItem("HMAC_SECRET").getValue() as string;
  const message = `${kintone_id}|${exp}`;
  const enc = new TextEncoder();
  const key = await crypto.subtle.importKey(
    "raw", enc.encode(secret), { name: "HMAC", hash: "SHA-256" }, false, ["sign"]
  );
  const sig = await crypto.subtle.sign("HMAC", key, enc.encode(message));
  return btoa(String.fromCharCode(...new Uint8Array(sig))).slice(0, 32);
}

// Power Automate 式言語による検証(Flow_FormResponse 内)
@if(
  and(
    greater(int(triggerOutputs()?['exp']), div(ticks(utcNow()), 10000000)),
    equals(triggerOutputs()?['token'], outputs('Office_Script_HMAC')?['result'])
  ),
  'valid', 'invalid'
)
セキュリティ要素 対策 効果
URL推測攻撃 HMAC-SHA256 + 32文字署名(2^256 通り) 総当り実質不可能
URL漏洩リスク 有効期限 7日 を URL に埋め込み 古いURLが漏洩しても無効化済
シークレット管理 Azure Key Vault または Office Script 環境変数で保管
(Power Automate 接続参照経由)
フロー設定画面からは見えない、IT管理者のみアクセス可
第三者の不正回答 token + 取引先メアド + フォーム冒頭の本人確認チェックボックスの三重検証 URL知らない限り回答不可、誤送信時も本人確認で気づける

13.6.4 実装プラン(純6日 / リードタイム10営業日)

Step 作業内容 担当 工数 アウトプット
0前提条件:Power Automate Premium 契約 + 西川用 M365 アカウント発行窪田部長 + 情シス2-3営業日ライセンス契約 + 西川アカウント発行(実装着手のクリティカルパス)
1取引先マスタ kintone アプリ作成(§13.3 仕様準拠、webhook設定含む)西川1日kintone アプリ + APIトークン
2Microsoft Forms 設計・作成(§13.3 取引先入力項目を Forms に展開、事前入力URLパラメータ確認)西川0.5日Microsoft Forms URL + 事前入力URL構造
3Power Automate Flow_SupplierInvite + Flow_FormResponse 構築(kintone コネクタ + Outlook コネクタ)西川2日2フロー実装完了
4Office Script で HMAC token 生成ロジック + Azure Key Vault シークレット保管西川0.5日HMAC生成/検証ロジック + シークレット保管
5Flow_ScheduledReminder(スケジュールトリガー:督促・期限切れ・アーカイブ)西川0.5日毎朝9時実行の督促フロー
6テスト:内部メンバーで E2E 動作確認(編集者入力 → メール送信 → フォーム入力 → kintone反映 → 督促 → アーカイブ)西川 + 高橋さん1.5日動作確認レポート + Power Automate 実行履歴確認
7運用ガイド作成(編集者向け1枚 + 高橋さん向け1枚 + Power Automate 保守ガイド)西川0.5日運用マニュアル3種 + フロー所有権移譲手順書
合計工数7日純工数(前提条件Step 0除く)。リードタイム12営業日(直列実装、ライセンス発行含む)

13.6.5 ライセンス・アカウント構成(月¥4,122)

ライセンス / アカウント 月額 対象者 必要な理由
Power Automate Premium
(プレミアムプラン)
¥2,248/月 フロー所有者1名
(大和書房側1名)
kintone コネクタ等のプレミアムコネクタ利用に必須。フロー所有者1名のライセンスのみで全動作(編集者・取引先・高橋さん追加不要)
Microsoft 365 Business Standard
(西川用 大和書房ドメイン)
¥1,874/月 西川(nishikawa@daiwashobo.co.jp 等) Power Automate フロー編集 + Office Script + Microsoft Forms 作成に必要。ゲストアカウントでは Power Automate Premium 適用困難なため正規ライセンス必須
合計 ¥4,122/月 年額 約¥49,500(消費税別)
💡 西川アカウントの権限スコープ(情シス側で要設定)
  • 付与:Power Automate Premium / Microsoft Forms / Outlook(フロー所有者として送信権限)/ SharePoint(ログ保存先のみ)/ kintone(取引先マスタアプリ操作)
  • 不要:Teams(任意)/ SharePoint他サイト / OneDrive(社内ファイル共有)/ 経理・人事システム / 社内メーリングリスト
  • 退職時・契約解除時はアカウントを無効化するだけでフロー所有権を大和書房側1名に移譲可能

13.6.6 フロー所有権管理パターン(PoC期 → 本番運用)

パターン フロー所有者 月額追加 特徴・適用フェーズ
パターン1 PoC・初期実装 西川(nishikawa@daiwashobo.co.jp)
大和書房 M365 テナント
¥4,122/月 初期推奨。西川単独で開発・デバッグ・テスト完結。実装スピード最速。フロー所有権・データはすべて大和書房テナント内
パターン2 本番運用移管 大和書房側1名
(窪田部長 or 高橋さん)
¥2,248/月(西川アカウント削減後)
or ¥4,122/月(保守継続)
長期推奨。本番安定後(Phase 1 完了時点)にフロー所有権を大和書房側1名に移譲。西川契約解除時もフロー継続可能
パターン3 共同所有 西川 + 大和書房側1名
(共同所有者として2名登録)
¥4,122/月 過渡期推奨。西川アカウント返却後も大和書房側1名が引き継ぎ可能、二段構えで安全
💡 Power Automate 保守作業の具体(年1-2回想定・クリックで展開)
  • コネクタ変更追従:kintone コネクタ・Microsoft Forms コネクタの仕様変更に合わせてフローを修正(年1-2回程度)
  • エラーハンドリング:通信エラー・トークン期限切れ・スロットリングの監視・対応
  • OAuth 接続更新:kintone APIトークン・Microsoft 365 接続認証の期限管理
  • 個人情報マスキング検証:Power Automate 実行履歴に口座番号等が漏れていないか半年に1回監査
  • 属人化対策:フロー仕様書を SharePoint に保管、定期的に「フロー定義のエクスポート」(.zip)を取得して GitHub 等で版管理
  • ライセンス更新:Power Automate Premium・M365 Business Standard の年次更新(情シス対応)

→ 西川アカウント有効中は無償サポート、移管後は別途保守契約 or 大和書房側で運用継続。

13.7 セキュリティ・エラーハンドリング戦略

GAS で個人情報・口座情報を扱うため、QA観点でレビューした問題点に対する設計対策を多角的に整理。

SECURITY 1 (CRITICAL)

HMAC-SHA256 トークン検証

URLに ?token={hmac}&exp={timestamp} 付与、GAS側で再計算して検証。32文字署名(2^256通り)で総当り実質不可、有効期限7日で漏洩リスクを時限化。

SECURITY 2 (CRITICAL)

本人確認の二要素化

フォーム冒頭に「あなたのお名前・屋号」確認チェックボックス必須化。編集者の誤メアド入力 / 会社共通メアド経由の誤回答を防ぐ。回答完了時に取引先メアドに完了通知も自動送信。

SECURITY 3 (CRITICAL)

個人情報マスキング

Power Automate 実行履歴 + SharePoint ログから口座番号・マイナンバー等を自動マスキング(例: 「1234-5678」→「****-****」)。アクション設定の「セキュリティで保護された入出力」機能で機密フィールドの履歴記録を抑制。半年に1回ログ監査を運用ルール化。

SECURITY 4

機密フィールドの権限分離

口座情報・マイナンバー有無は kintone で 閲覧権限を高橋さん・経理のみに限定。編集者・他部署には非表示設定。

ERROR HANDLING 1

HTTP通信失敗時のリトライ

kintone コネクタ通信失敗時は Power Automate 標準リトライ機能で3回再試行(指数バックオフ自動)。それでも失敗なら「実行に失敗した場合」アクションで高橋さんに通知 + 実行履歴に記録。

ERROR HANDLING 2

冪等性確保

kintone コネクタでレコード更新する際、フロー冒頭で「現在のステータス取得」アクションを実行し、既にステータス=入力済 ならスキップ。取引先が複数回フォーム送信しても重複更新が発生しない設計。

ERROR HANDLING 3

Power Automate 実行制限対策

Premium プランの30日アクション数 250,000回上限内で動作可能(想定月数百件規模なら十分余裕)。督促バッチは「分割実行」で 100件単位処理、Forms 回答も非同期処理で並列実行可能。

ERROR HANDLING 4

競合検出

同じ kintone_id に対して複数フォーム回答が来た場合は後勝ち + 高橋さんに警告。取引先が分担入力するケースに対応。

13.8 運用パターン(督促・例外・更新)

📅 督促・期限切れ・アーカイブ自動化(Flow_ScheduledReminder)

経過日数 アクション 通知先 kintoneステータス
7日経過督促メール自動送信取引先 + 編集者 + 高橋さん「📨 取引先入力依頼中」のまま
14日経過期限切れ警告 + 高橋さん通知高橋さん(個別フォロー対応依頼)「⚠️ 期限切れ」に自動変更
30日経過レコードアーカイブ高橋さん(最終通知)「🗄️ アーカイブ」(論理削除相当)

📋 例外パターンの運用

EXCEPTION 1

メアド無し取引先(紙運用)

編集者が新規登録時にメアド欄を空にする → 自動で高橋さんに通知 → 高橋さんが楽楽明細の登録シートを取引先に郵送 → 返送後に kintone マスタを手動入力。ステータス「📮 紙運用」で別軌道管理。

UPDATE 1

既存取引先の情報更新

口座変更・住所変更等の更新時、高橋さんが kintone マスタを開いて「🔄 情報更新を依頼」ボタンクリック → 同じユニークURL生成ロジックで再送。変更履歴サブテーブルに過去情報を保持。

UPDATE 2

差分の見える比較画面

更新時、kintone JS で「変更前 / 変更後」を並列表示。高橋さんが目視確認のうえ承認 → 確定で本番反映。誤入力リスクを構造的に防ぐ。

FALLBACK

A案 GAS 切替時(緊急時)

Power Automate Premium ライセンス継続困難になった場合、A案 Google Apps Script に切替可能。kintone マスタ仕様・メール本文・運用フローは同一のため、移行コスト中程度(GAS実装で純6日)。

13.9 テスト戦略 + 本番運用引き継ぎ

🧪 テストカバレッジ(Step 6 で実施)

テスト種別 シナリオ 担当 合格基準
正常系 E2E 編集者新規登録 → メール送信 → 取引先フォーム入力 → kintone自動反映 → 高橋さん通知 西川(実装側)+ 高橋さん(受領側) 全Step 5分以内完了、データ100%反映
異常系:HMAC不一致 URLパラメータ改竄、トークン欠落、期限切れ 西川 すべて拒否、エラー画面表示
異常系:通信失敗 kintone コネクタ一時失敗、Power Automate標準リトライ動作確認 西川(kintone側 一時停止シミュレーション) 3回リトライ後成功 or 高橋さん通知
異常系:重複送信 取引先が同じフォームを2回送信 西川 後勝ち更新 + 高橋さんに警告通知
督促・期限切れ 7日/14日/30日経過をシミュレート(日時を手動変更) 西川 督促メール送信 → ステータス自動変更 → アーカイブ
例外運用 メアド無し → 紙運用フロー 高橋さん kintone ステータス「📮 紙運用」で手動完結
セキュリティ Power Automate 実行履歴 + SharePointログに口座番号等が漏れていないか確認 西川 「セキュリティで保護された入出力」適用、平文機密情報なし

🔄 本番運用引き継ぎ計画(パターン1 → パターン2 移譲)

フェーズ タイミング 作業内容 アウトプット
Phase α Step 6 完了直後 パターン1(西川アカウント所有)で本番稼働開始
1-2ヶ月モニタリング期間
稼働実績データ + バグ発生履歴
Phase β Phase 1 完了時点(7月末想定) パターン3(共同所有)に切替:大和書房側1名を共同所有者として追加
Microsoft Forms・トリガーは設定変更なし(テナント内移譲のため簡単)
共同所有完了、稼働継続
Phase γ 移譲後 1ヶ月 大和書房側で稼働確認、引き継ぎ完了確認
西川アカウント停止 or 保守継続契約判断
運用保守ガイドの最終版
💡 楽楽明細運用との接続
大和書房は既に 楽楽明細(クラウド書類送付サービス)を 2024年4月から運用中で、紙郵送時の QRコード経由で Microsoft Forms にメアド回収を実施中。 本フロー(Google Forms)も取引先側のUXは同等(アカウント不要・即入力可)であり、学習コストはゼロに近い。 IT部門のフォームツール管理は2系統に分散するが、運用業務へのブロッカーはなし。
★ BOOK MASTER — 新刊フロー連携前提に大幅縮減(ADR-001)

14. 📚 書籍マスタ × 新刊フロー連携設計

2026-06-05 新刊フローキックオフ確定スコープを受けて、v3.3 までの §14「書籍マスタ拡張案」を大幅縮減。 新刊フロー側で4アプリ(①新刊搬入日登録/②初版申請/③カレンダー/④ポータル)が確定し、 ①新刊レコードが書籍lookup の真のハブとして設計済み。purchase-order PJ から見ると「書籍マスタ App85 は触らない」が最終結論。

🎯 v3.4 方針確定(ADR-001)
  • 📌 書籍マスタ App85 への変更ゼロ(既存THINK's日次同期そのまま維持)
  • 📚 発注書の「書籍/企画」lookup 先 = 新刊レコード①(v3.3 の App85 直接 lookup から変更)
  • 👤 担当編集者は新刊レコード①から自動コピー(v3.3 の CREATOR 自動セット廃止)
  • 🔄 段階移行:v1(6月リリース、App85 直接 lookup 暫定)→ v2(7-8月、新刊レコード① 連携切替)
  • 廃止:v3.3 §14 の「企画中ステータス追加」「検索マッチング画面」「想定マッチ率議論」「仮タイトル運用責任者」は全て新刊フロー側に責務委譲

詳細:book-master-extension.md(縮減版) / integration-with-shinkan-flow.md / ADR-001

14.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 "取引先参照"
    }
    

14.2 v3.3 → v3.4 の変更サマリ

観点 v3.3 設計(旧) v3.4 設計(新・確定)
書籍マスタ App85 ステータス・担当編集者・仮タイトル追加 何も変更しない(既存運用そのまま)
発注書の書籍lookup先 App85 直接 新刊レコード①(v1暫定はApp85、v2切替)
担当編集者 App85フィールド追加、kintone CREATOR 自動セット 新刊レコード①の `editor`、lookup自動コピー
企画段階レコード作成動線 発注書アプリから「🆕 企画段階で新規登録」ボタン 新刊フロー①の登録UIへリンク誘導
仮タイトル → 正式タイトル追従 編集者主・高橋月次レビュー 新刊フロー側 T1通知で自動追従
検索マッチング画面 kintone JS スコアリング(想定著者名+発売月+レーベル) 不要(App85 ↔ 新刊レコード① は 1:1直結)
Phase 1 工数 純3-5日(書籍マスタ拡張) 純0日(App85 触らないため)

14.3 段階移行スケジュール

v1 暫定(6月)

App85 直接 lookup

新刊フロー① 未稼働期間の暫定運用。発注書アプリで App85 を直接 lookup。書籍/企画が見つからない場合はフリーテキスト入力で代用。

v2 切替(7-8月)

新刊レコード① 連携

新刊フロー① 完成後、発注書アプリの lookup 先を新刊レコード①に切替。kintone JS の lookup イベントをリファクタ + 過去発注書はそのまま維持。

中長期(9月〜)

編集部への浸透

新刊フロー① が編集部に浸透。発注書を出す前に新刊レコード① が存在する状態が常態化。Phase 2 で業務委託契約との連携を追加。

📜 v3.3 § 14.1〜14.7 廃止セクション(参考・歴史的記録)— クリックで展開
⚠️ 以下は v3.3 までの設計(廃止済)
ADR-001 により、書籍マスタ拡張は新刊フロー連携前提に大幅縮減されました。以下のセクションは 参考・歴史的記録としてのみ残置しており、最新の設計方針は §14.1〜14.3(このセクション直上)を参照してください。

14.1 問題の構造(v3.3、廃止)

flowchart TB
    A[企画立ち上げ
仮タイトル] --> B[編集者:発注書作成
★この時点では書籍マスタなし★] B --> C[著作権者と業務開始] C --> D[執筆・編集進行
仮タイトル変動] D --> E[ISBN取得
刊行2-3ヶ月前] E --> F[THINKs 書籍マスタ登録] F --> G[kintone 書籍マスタ ID 85 に同期] G --> H[刊行] style B fill:#fee2e2,stroke:#dc2626,color:#7f1d1d,stroke-width:3px style E fill:#dbeafe,stroke:#1e40af,color:#1e3a8a style F fill:#dcfce7,stroke:#15803d,color:#14532d
⚠️ 5/19 高橋さん談
「(書籍マスタは)この時点で存在しないのが現時点の状況なんです。既存の書籍マスタはあるが、ここでやり取りしてる時って新しい本だから、THINKsになにもないってことですね。全て仮みたいなタイトルでやってて、っていう状態ですね。 (THINKs に)持ってるのは結構刊行 2-3ヶ月前とか ISBN を取った時になります。」

14.2 影響範囲

影響箇所 どう壊れるか 補足
発注書アプリの書籍 lookup機能しない(マスタにレコードなし)編集者が「書籍を選択」できない
書籍別の発注一覧表示紐付け不可関連レコード一覧が機能しない
経理:書籍別原価集計(決算)引き続き属人化(高橋さんの記憶頼み)「私の記憶力と分用でカバーしている状態」(5/19高橋さん談)
Phase 2/3:書籍↔著作権者紐付け紐付け先がない業務委託契約・出版契約のマスタ参照不可
支払依頼アプリ書籍名フリーテキスト化発注書から派生でも書籍紐付けが弱い

14.3 4案の多角的評価

アプローチ 概要 編集者負荷 高橋負荷 原価集計 THINKs整合 実装工数
A フリーテキスト + 後付けマージ 書籍名は単純な文字列入力。ISBN取得後に「書籍マスタ」を選択しなおして紐付け(手動) ◎ 最小 △ 後でマージ作業 × 低(手動マージ漏れ) △ 不整合発生 ◎ 小(0.5日)
B 企画マスタ アプリ新設 書籍マスタとは別に「企画マスタ」アプリを新規作成。仮タイトル時点で先行登録、ISBN取得時に書籍マスタに昇格 △ 中(企画登録の手間) △ 中(マスタ管理2箇所) ◎ 高 △ 別途同期設計必要 × 大(3-5日)
C 🎯 既存書籍マスタを企画段階から使用 書籍マスタにステータスフィールド追加。企画中・ISBN取得済・刊行済・絶版 を許容、ISBN空欄も許容 △ 中 ◎ 小 △ 中(ステータス管理必要) ◎ 高(半自動同期可) △ 中(1-2日)
D 🎯 軽量プロビジョナル登録 編集者が発注時に書籍マスタへ最小項目(仮タイトル・著者名想定・担当編集者)でレコード作成。ISBN取得時にTHINKsデータで上書き △ 中 △ 中 ◎ 中(仮IDで集計可) ◎ 自動同期 △ 中(1.5日)

14.4 推奨案:C + D ハイブリッド

🎯 推奨:C+D ハイブリッド — 既存書籍マスタを拡張 + プロビジョナル登録動線

既存書籍マスタ ID 85(1,245件)を 企画段階から使えるよう拡張し、発注書アプリから直接「企画段階レコード」を作成できる動線を追加。 ISBN取得後にTHINKsから自動同期で上書きされ、本登録扱いに自動昇格。

📋 書籍マスタ 拡張フィールド

# フィールド名 入力者 必須 備考
1書籍ステータス 🆕編集者 → THINKs企画中 / ISBN取得済 / 刊行済 / 重版中 / 絶版(企画段階レコードを許容)
2仮タイトル 🆕編集者正式タイトル決定前の作業タイトル
3ISBNTHINKs同期企画段階では空欄許容、取得時に自動入力
4企画名 / 正式タイトル編集者 → THINKs初期は仮タイトル、正式タイトル決定後に上書き
5著者名(想定)編集者企画段階の想定著者
6担当編集者 🆕自動(kintone CREATOR)kintone JS で CREATOR を自動コピー(編集者は手動入力ナシ)。THINKs側に該当カラム無いため突合キーには使わず、候補表示時の補助情報として利用
7公刊期日THINKs同期
8体裁THINKs同期例:四六判 並製 192頁
9初版発行部数THINKs同期
10本体価格THINKs同期
11責了日THINKs同期発注書「校了日基準」支払日計算の基準
12レーベルTHINKs同期単行本 / 文庫 / だいわ文庫 / 雑誌 / だいわlog
13kintone作成日 🆕自動企画段階レコード作成時刻
14THINKs同期日時自動企画段階 → 本登録 への昇格日時の管理

14.5 書籍登録の状態遷移フロー

sequenceDiagram
    autonumber
    actor E as 👤 編集者
    participant K as ☁️ kintone
書籍マスタ(ID 85, 拡張) participant TH as 💾 THINKs actor T as 👤 高橋さん rect rgb(245, 240, 255) Note over E,K: Phase A — 企画段階:発注書作成時に書籍を新規登録 E->>K: 発注書アプリで「書籍/企画を選択」 K-->>E: 該当書籍なし E->>K: 「🆕 企画段階で新規登録」ボタン
仮タイトル・想定著者 入力
※担当編集者は kintone CREATOR から自動コピー K->>K: 書籍マスタにレコード作成
ステータス: 「📝 企画中」
ISBN: 空欄 K-->>E: 発注書から lookup 可能に end rect rgb(255, 250, 235) Note over K,TH: Phase B — 開発期間:執筆・編集・正式タイトル決定 E->>K: 仮タイトル → 正式タイトル更新 Note over K: ステータス: 「📝 企画中」(変化なし) end rect rgb(235, 245, 255) Note over TH,T: Phase C — ISBN取得:刊行 2-3ヶ月前 T->>TH: ISBN・書誌情報をTHINKs に登録 end rect rgb(245, 255, 245) Note over TH,K: Phase D — 自動同期:THINKs → kintone TH->>K: 月次(or 週次)RPA で同期
ISBN・公刊期日・体裁・部数・本体価格・責了日を上書き K->>K: 既存「企画中」レコードと突合
想定著者名+発売月+レーベル スコアで候補抽出
※担当編集者は補助情報として表示
レコード更新 + ステータス: 「✅ ISBN取得済」 end rect rgb(255, 245, 250) Note over K,E: Phase E — 刊行:完成 T->>K: ステータス: 「📚 刊行済」に更新 Note over K: 過去発注書・支払依頼も自動で本書籍に紐付く end
📌 C+D ハイブリッド の利点
  • 既存書籍マスタ ID 85 を活用(新規マスタ作成不要、設計シンプル)
  • 編集者は企画段階で1度だけ登録(その後のISBN等はTHINKs同期で自動補完)
  • 過去発注書も自動で本書籍に紐付く(仮タイトル → 正式タイトル変化を吸収)
  • 経理の書籍別原価集計が企画段階から可能に → 高橋さんの属人記憶からの脱却
  • Phase 2/3 のマスタ参照もそのまま利用可能

14.6 高橋さん用 検索マッチング画面(kintoneを正・手動転記方針)

📌 5/20 事実確認:「担当編集者」フィールド非存在
kintone API でアプリID 85 のフィールド39件を確認したところ、「担当編集者」フィールドは存在しない(同期データが全件 Administrator のため、THINKs側にも該当カラムは無いと推定)。
→ 当初の「自動同期スクリプト + スコアリング」設計は前提崩壊。kintoneを正・高橋さん手動転記方針に切替、「kintone JS によるスマート検索 + 高橋さん目視選択」の半自動運用で対応する。

核心課題:仮タイトル時点で発注書を出した後、ISBN取得時にTHINKsで登録される正式タイトルと kintone企画段階レコードを どうユニークに紐付けて上書きするか。 仮タイトル「test(仮)」と正式タイトル「ずぼら薬膳」のようにタイトル自体が一致しないため、完全自動マッチは不可能。 「自動候補抽出 → 高橋さんによる承認」の半自動運用で対応する。

🔑 スコアリング・キー設計(担当編集者は突合キーから除外)

# キー / 情報 スコア配点 種別 突合相手(THINKs由来フィールド)
1 想定著者名(rapidfuzz類似度) 70点 主キー THINKs author1 フィールドと照合(部分一致率に応じてスコア配分)
2 想定発売月 ±60日 ウィンドウ 20点 補助キー THINKs publish_date または sales_date と照合
3 レーベル / 商品分類一致 10点 補助キー THINKs product_category / series_name
4 担当編集者(kintone CREATOR自動コピー) 0点 候補表示時の補助情報 THINKs側にデータ無し → 突合キーに使えない。
ただし候補表示画面で「あ、これ中山さんの企画」と高橋さんが目視判定する補助に有効
⚠️ なぜ「担当編集者」を突合キーから外したか
THINKs由来の同期レコード側(書籍マスタ ID 85)に 担当編集者カラムが存在しないため、片側にしかデータがない以上、スコアリングに使えない。
ただし kintone 企画段階レコードには kintone CREATOR を自動コピーして保持しておくことで、候補マッチング画面で「これは誰の企画か」が一目で分かり、高橋さんの目視判定スピードが大幅に向上する。

⚙️ 検索マッチング画面のワークフロー(kintone JS実装)

flowchart TB
    A[高橋さんがTHINKsにISBN登録] --> B[kintone書籍マスタを開く]
    B --> C["🔍 企画中レコードから候補を探す
ボタンをクリック"] C --> D[kintone JS が企画中レコード一覧を取得] D --> D1["スコア計算式:
想定著者名 rapidfuzz 0〜70点 +
想定発売月 ±60日 20点 +
レーベル一致 10点
※担当編集者は候補表示の補助情報"] D1 --> E{スコア閾値判定} E -->|80点以上| F[🟢 自動昇格候補
承認クリックのみで完了] E -->|50-79点| G[🟡 候補リスト表示
担当編集者付きで一覧化] E -->|50点未満| H[🔴 新規扱い
マッチなし] F --> J[高橋さんが承認
1分以内] G --> J J --> K[ステータス: ✅ ISBN取得済
THINKsデータで kintone レコード上書き] H --> L[新規レコード作成
過去発注書は手動紐付け] style F fill:#dcfce7,stroke:#16a34a,color:#14532d style G fill:#fef3c7,stroke:#d97706,color:#7c2d12 style H fill:#fee2e2,stroke:#dc2626,color:#7f1d1d

🖥️ 高橋さん向け検索マッチング画面(kintone JS カスタマイズ)

cy6vg2ycifc8.cybozu.com / 書籍マスタ / 🔍 企画中レコードから候補を探す THINKs登録時に起動
📚 THINKs新規登録:ISBN 978-4-479-XXXX-X 「ずぼら薬膳」
著者: ロン毛メガネ / 公刊期日: 2025-12-01 / レーベル: 単行本
🔍 kintone JS によるスマート検索結果(スコア順表示・担当編集者は補助情報)
スコア kintone仮レコード 担当編集者
(補助情報)
想定著者 想定発売月 アクション
92点 「test 健康レシピ本(仮)」 中山 淳也 ロン毛メガネ 2025-12 ✅ このレコードと紐付け
65点 「タイトル未定_新企画」 中山 淳也 不明 2026-01 候補から外す
52点 「料理本 仮タイトル」 林 陽一 ロン毛メガネ 2026-02 候補から外す
💡 担当編集者列の使い方:「ずぼら薬膳は中山さんの企画」と高橋さんが思い出して92点候補(中山)を即座に判定。担当編集者は突合計算には使わないが、目視判定の決定打になる。
✅ 上位候補を承認・紐付け 🆕 マッチなし → 新規レコード作成
💡 想定マッチ率(5/20 訂正・担当編集者除外後)
担当編集者を突合キーから外したことで、自動昇格率は当初予想(50-60%)から下方修正:
  • 自動昇格候補(80点以上):全体の 30-40%(想定著者名がほぼ一致するケース。高橋さんは承認クリックのみで完了)
  • 候補リスト表示(50-79点):全体の 40-50%(複数候補を担当編集者で目視判定、1-3秒で選択)
  • 新規扱い(50点未満):全体の 15-25%(想定著者未入力等、過去発注書は手動紐付け)
PoC運用後に閾値(80点→75点等)を調整してチューニング。担当編集者列の表示で目視判定スピードを補強することで、トータルの運用負荷は低水準を維持。

14.7 仮タイトル運用責任者と段階別アクション

書籍マスタ「企画中」レコードの仮タイトル → 正式タイトルへの更新運用について、 誰が・いつ・何を行うかを明示。編集者が主・高橋さんが月次レビューの2層責任構造を推奨。

段階 タイミング 主責任者 アクション 承認・確認
① 企画起動 企画立ち上げ直後(発注書作成時) 担当編集者 発注書アプリから「🆕 企画段階で新規登録」ボタンクリック
仮タイトル・想定著者のみ入力(担当編集者はkintone CREATOR から自動コピー、手動入力ナシ)
→ ステータス「📝 企画中」でレコード作成
② タイトル更新 正式タイトル決定時(随時) 担当編集者 kintone書籍マスタを開いて仮タイトル → 正式タイトルに上書き
必要に応じて著者名も正式名へ更新
—(編集者自身の判断)
③ 月次レビュー 毎月末〜月初(高橋さん月次処理時) 高橋さん 「ステータス=企画中」ビューで 3ヶ月以上更新がないレコード を抽出
担当編集者に「最新タイトル教えてください」と確認依頼
編集者からの返信を待ってマスタ更新
④ ISBN取得 刊行 2-3ヶ月前 高橋さん THINKsにISBN・書誌情報を登録
(既存運用、変化なし)
⑤ 検索マッチング ISBN登録直後(高橋さん操作) 高橋さん kintone書籍マスタを開いて「🔍 企画中レコードから候補を探す」をクリック
§14.6 の検索マッチング画面でスコア順候補表示
担当編集者列を見て目視で1件選択
⑥ 候補承認 マッチング画面から(即時) 高橋さん kintone「マッチ候補承認待ち」ビューを確認
各候補に対して「承認 / 新規扱い」を判定
1件あたり1分以内で完了
編集者には通知のみ(編集者は意識せずに本登録完了)
⑦ 例外対応 新規扱いになったレコード発生時 高橋さん + 担当編集者 マッチしなかったレコードについて、過去発注書を手動で本書籍に紐付け
原因(想定著者未入力等)を分析して改善
💡 運用負荷の見積もり
  • 担当編集者:①企画起動時の登録(1分)+ ②タイトル更新時の上書き(1分)= 1書籍あたり2分程度
  • 高橋さん:③月次レビュー(月1回・10分)+ ⑥候補承認(月1-2回・10分/回)= 月20-30分
  • システム自動化部分:⑤同期スクリプトはバッチ実行のため運用負荷ゼロ
編集者の入力負荷は最小、高橋さんも月30分以下で運用可能
PHASE 2 / 3 OUTLOOK

15. Phase 2 / 3 の残論点・期待値・工数感

Phase 1(発注書・支払依頼)が安定運用したあとの拡張スコープを正直ベースで整理。「完全自動」と書きたいところを「半自動」に補正し、実現性のグラデーションを明示する。

📋 Phase 2: 業務委託契約書(想定 8-10月)

コンポーネント 残論点(5/19以降に確認) 期待値(実現確度) 工数感
業務委託契約アプリ(2フォーマット統合) 「ライティング等」「翻訳業務」の業務種別分岐、印税率/金額の入力UI 高(kintone標準で実現可) 純1日 / LT2日
JS カスタマイズ(マスタ参照・印税率計算) Phase 1 のJS資産が流用可能か 純2日 / LT3日
Word .docx 出力機能 既存Word雛形のCSS化、または pandoc / docx生成ライブラリで対応? 中(PoC必要) 純3日 / LT5日
DocuSign API 連携 大和書房のDocuSignアカウント権限、既存契約との整合(河合さんとすり合わせ) 中(API実績あり、社内権限次第) 純4日 / LT2週間
編集部→高橋ワークフロー(プロセス管理) Phase 1 と同じパターンで吸収可 純1日 / LT1日
Phase 2 合計 中〜高(DocuSign権限が鍵) 純11日 / LT 約1ヶ月

📋 Phase 3: 出版契約書類(想定 11月-)

コンポーネント 残論点 期待値(実現確度) 工数感
出版契約アプリ(5フォーマット統合) 「契約書/覚書」「紙電子一体型/紙のみ/文庫同意書」の組合せ判定 純2日 / LT3日
JS カスタマイズ(媒体別印税計算) 再版印税率・電子印税率・ページ割(按分)の自動計算 純3日 / LT4日
編集部→河合→高橋→河合 ワークフロー 河合さんとの詳細設計、現状の「往復」をどう解消 中(運用合意が前提) 純1日 / LT 河合さんMTG含めLT2週間
DocuSign 連携(Phase 2流用) Phase 2 が動いていれば流用 高(Phase 2成功条件付き) 純1日
THINKs 印税自動入力(RPA) THINKs UI の自動操作(Pywinauto)— UI変更時にメンテ必要・大和PC常時稼働前提 低〜中(PoC 5-7日必要、長期保守リスクあり) 純7日 + 運用保守 年5-10日
著者マスタ(書籍マスタから派生) 著作権者マスタとの統合 or 別アプリ化の判断 高(既設計の延長) 純1日
Phase 3 合計 低〜中(THINKs RPA が鍵) 純15日 / LT 約1.5ヶ月

🚦 期待値の補正(前回からの差分)

項目 前回表記 今回補正 理由
THINKs RPA 同期 完全自動 半自動(週次/月次) UI自動化は構造変更時にメンテ必要、例外処理が必要
DocuSign API 完全自動 半自動(イベント駆動) 社内DocuSign権限取得・既存契約との整合確認が前提
THINKs 印税入力(Phase 3) 手動 → API化検討 RPA(UI自動化)、長期保守要 THINKs に API が無いことが確定、RPA以外の選択肢なし
freee 取引登録 手動継続 手動継続(Phase 3+でAPI化検討) freee API実績あり、優先度次第で実装可能

⚠️ Phase 2/3 に進む前の前提条件

前提 A

Phase 1 の運用安定

編集部 8割が kintone 発注書を日常使用、月次支払処理が30%以上時短、ビズロボ廃止判断のデータ揃いの3つが揃ってから Phase 2 に進む。

前提 B

DocuSign 権限と運用合意

河合さん経由でDocuSignアカウントの API 利用権限を取得、既存契約との整合方針を合意。Phase 2 着手前に1on1必須。

前提 C

THINKs RPA PoC 成功

5-7日のPoCで「THINKs UIをPywinautoで安定操作できるか」を実証。失敗時はマスタ更新を手動継続 + ビズロボ廃止見送り判断。

SO WHAT
Phase 2/3 は「やれば動く」が「自動度の期待値は高くしすぎない」のが正直なところ。 特に THINKs RPA は「動かしたら安定運用は別問題」なので、Phase 1 の手動運用を覚悟しながら徐々に自動度を上げる姿勢が安全。 Phase 1 完了時点で改めて「Phase 2/3 のROI vs 工数」を再評価することを推奨。
GAPS & REQUESTS

16. 不足情報 と 大和書房さまへの確認・依頼(5/19 MTG 反映済)

実装に必要な情報のうち、現状不足しているもの・大和書房さま側にしかない情報を構造的に整理。

✅ 5/19 高橋MTG で解決済み(11項目)

✅ RESOLVED
業務委託先マスタの所在
THINKs「著作権者マスタ」がそれに該当することが判明(5/15)。著者・業務委託を包括した2,487件CSV受領済。
受領済み:2,487件・38列・cp932 / クレンジングPoC完了
✅ RESOLVED
河合さんの担当領域(再訂正)
河合さんは総務人事労務担当であり経理ではない(5/19 高橋さん明示)。Phase 3 の出版契約フローで関与。本PJ(発注・支払)は編集部 → 高橋さん の 2ステップで完結。
反映済み:全フロー図を編集部→高橋の2ステップに修正
✅ RESOLVED
発注書5パターンの命名と運用
①書籍デザイン等/②撮影・校正・拡材等(営業の販促物デザインも吸収)/③だいわlog連載/④リーディング/⑤その他(例外) の5パターンに確定。④はほぼ未使用、⑤は西川さん相談ベースの例外運用。
反映済み:本資料 §3 UI/UX セクションに5タブとして反映
✅ RESOLVED
複製機能の必要性
だいわlog連載(同額複数回)対応の検討から、定期発注(チコルズ山田さん等)全般に有効と判明。自分の過去発注のみ複製可、親子構造は履歴検索で十分。
合意済み:§3 で詳細仕様化、入力負荷-70〜80%削減
✅ RESOLVED
取引先重複の正体と運用
角川・日本ユニ等の大手重複は著作権料のみで発注書出ない。発注書が出るのは吉本興業のみ(銀行口座違いで複数コード)。「同一取引先で複数許容+例外は西川相談」で合意。
合意済み:マスタ設計で「複数許容」運用に確定
✅ RESOLVED
論理削除フラグの扱い
論理削除は使っていない。代わりにペンネームに「※使用停止」を付与して並列保持(284件運用中)。理由:個人 → 法人 → 数年後個人に戻るケースがあるため。
合意済み:「状態」フィールドで正規化、ペンネーム本体は分離
✅ RESOLVED
検索UIの方針
編集部はペンネーム検索が中心、「相手が会社か個人かわかっていない人が多い」。ペンネーム+会社名の2系統入口必須で合意。
合意済み:JSカスタマイズで lookup ピッカーを2入口拡張
✅ RESOLVED
業務委託先 vs 著者の判別
CSV備考欄で記載されるが運用は統一されていない(書く人による)。著者でも自分のオフィス名で受け取るケースあり。完全自動判別は不可、Phase 1 では取引先タイプフィールドを設けて手動分類運用。
合意済み:運用ルール策定は中長期論点として整理
✅ RESOLVED
インボイス番号の管理
「番号(T+13桁)は不要、登録済/未登録 だけわかれば十分」(高橋さん)。Phase 1 設計から番号フィールドは削除。
合意済み:マスタフィールドから削除
✅ RESOLVED
🚀 新規取引先登録フローの設計
発注の半数を占める「新規取引先」課題に対し、取引先本人がフォーム入力 → kintone自動連携 → 高橋がTHINKs転記の抜本フローで合意。楽楽明細運用と整合。
合意済み:§13 で詳細仕様化、Microsoft Forms + Power Automate 推奨
✅ RESOLVED
⚠️ 書籍マスタが仮タイトル時点で存在しない問題
5/19 で初めて発覚。ISBN取得は刊行2-3ヶ月前のため、発注時点では書籍マスタにレコードなし。当初 C+Dハイブリッド案で検討したが、2026-06-05 新刊フローキックオフを受け ADR-001 で方針転換(新刊レコード①が書籍lookup の真のハブ)。
方針確定:ADR-001 により書籍マスタ拡張は廃止。発注書の書籍lookup先 = 新刊レコード①(v1暫定はApp85直接)。§14 参照

🔴 5/19 以降の新規論点(P0)

🔴 CRITICAL
🆕 Power Automate Premium 契約 + 西川用 M365 アカウント発行
B案採用の前提条件。月¥4,122の追加コスト(Power Automate Premium ¥2,248 + M365 Business Standard ¥1,874)。情シス対応で2-3営業日のリードタイム。実装着手のクリティカルパス。
判断依頼:窪田部長 + 情シスに ①Power Automate Premium 1ライセンス契約 ②西川用 nishikawa@daiwashobo.co.jp(または別ドメイン)アカウント発行 ③§13.6.5 の権限スコープ設定 を依頼。経営判断必要なら社内稟議も。
🔴 CRITICAL
著作権者マスタ項目の「必須/任意・入力者」区分シート
5/19 で高橋さんに作成依頼。新規取引先登録フローの設計確定に必須。編集者最小入力 / 取引先本人入力 / 高橋入力 の3区分。
依頼済み:高橋さんが区分シート作成中、返送待ち(西川から区分用テンプレ送付要)
🔴 CRITICAL
編集部 kintone ライセンス追加状況の確認
6月中旬リリース目処に対し、編集部アカウントが入っていないとテスト・パイロットができない。
確認依頼:窪田部長にライセンス追加状況・タイムラインを確認(西川から or 高橋さん経由)
✅ RESOLVED
フォーム連携方式の採用判断
大和書房既存 Microsoft 365 基盤との統一性・楽楽明細運用との整合性を優先し、B案 Microsoft Forms + Power Automate を採用。Power Automate Premium 月¥2,248 + 西川用 M365 Business Standard 月¥1,874 = 月¥4,122で長期運用。
方針確定:§13.6 詳細アーキテクチャ(フロー3つ・HMAC設計・実装プラン7日)/ §13.7 セキュリティ / §13.8 運用パターン / §13.9 テスト戦略・所有権移譲 を整理済。A案 GAS は緊急時フォールバックとして保留。
✅ RESOLVED v3.4
書籍マスタ拡張 → 新刊フロー連携前提に方針転換(ADR-001)
2026-06-05 新刊フローキックオフで4アプリ確定スコープ判明 → 新刊レコード①が書籍lookup の真のハブとして設計済。v3.3 §14 の C+D ハイブリッド案・検索マッチング画面・想定マッチ率は全て新刊フロー側に責務委譲
方針確定:ADR-001 で書籍マスタ拡張廃止。発注書の書籍lookup先 = 新刊レコード①(v1暫定はApp85直接、v2切替)。詳細は book-master-extension.md(縮減版) / integration-with-shinkan-flow.md 参照。
✅ RESOLVED
THINKs書籍マスタの担当編集者フィールド有無
5/20 kintone API でアプリID 85(39フィールド)を確認した結果、「担当編集者」フィールドは存在しない。THINKs側にも無いと推定(同期データが全件 Administrator)。
反映済み(v3.4 改訂):担当編集者は新刊レコード①のフィールドで管理(新刊フロー側で確定済)。発注書からは新刊レコード①を lookup して担当編集者を自動コピー。CREATOR 自動セット方式は廃止。

🟡 実装中に必要(P1)

🟡 HIGH
PDF 品質要件・社印・宛名ルール
PDF生成方式(C案 Cloud Run+Puppeteer vs D'案 ブラウザ内 jsPDF)の最終選定に影響。対外正式文書としての印刷要件・社印の扱いを確認。
確認したい:社印の電子化はあるか?「様/御中」判定ルール?印刷物 vs PDFのみの比率?取引先別の特殊レイアウト要望はあるか?
✅ RESOLVED
THINKs ↔ kintone のマスタ同期方針
5/19 MTG・本セッションで方針確定。THINKs → kintone の自動同期は行わず、kintone を「マスタの正」として扱う
方針確定:
  • 新規取引先:kintoneで新規登録 → §13 のフォーム連携で本人入力 → kintoneマスタに反映
  • 更新:kintoneマスタ上で編集(旧THINKs同期スクリプトは廃止)
  • THINKs側:高橋さんが kintone マスタを見ながら手動で転記(コード採番・印税入力・支払通知書発行)
  • THINKs CSV エクスポート手順の確認は不要(Phase 1 では自動連携の前提を持たないため)
✅ RESOLVED
編集担当者列が2つある理由
受領CSV内に「編集担当者」というカラム名が2列ある件。「コード」と「氏名」の組合せで確定(5/19 ヒアリングで合意)。
反映済み:kintoneマスタ取込時に「編集担当者コード」「編集担当者名」の2フィールドとしてリネーム。詳細はmaster-design.md フィールド14-15。
🟡 HIGH
編集部 kintone ライセンス追加判断
Stage 1(総務UAT)完了後、編集部パイロット 2-3名へのアクセス権発行が必要。月額 ¥1,800/人 × 人数の予算判断。
判断依頼:編集部パイロット時期(7月想定)に向けて、ライセンス追加可否・タイミングを窪田部長とご相談いただきたい。

🟢 後でいい(P2、Phase 1 後半 or Phase 2 移行時)

🟢 MINOR
インボイス番号(T+13桁)の管理
受領CSVには「インボイス登録状況」(登録済/未登録等)はあるが番号(T+13桁)は無い。適格請求書発行時の表示に必要だが、Phase 1 では未表示でも実用可。
確認したい:インボイス番号は別管理か? 必要時は別CSV取得可能か?
🟢 MINOR
月間発注件数・4種比率の実数
ROI 試算・KPI設定の精度向上に使う。受領済み支払依頼.xlsxから算出可能。
確認したい:月間発注書件数(部署別)、4種フォーマットの利用比率の感覚値
🟢 MINOR
パイロット利用者の候補
Stage 2 編集部パイロットに参加してもらう 2-3名を選定する。早期適応者を優先。
相談したい:編集部内で kintone を試してくれそうな前向きな方を推薦してほしい(Phase 1 後半までに)。

✅ 5/19(火)14:00 高橋さん 60分MTG 実施結果サマリ

  1. 1
    ビジョン資料レビュー:編集側/高橋側フローともに合意。一方、書籍マスタが仮タイトル時点で存在しない問題が判明(重大発見 → §14 で対応設計)。→ 完了
  2. 2
    発注書5パターンの命名確定:①書籍デザイン等 / ②撮影・校正・拡材等 / ③だいわlog連載 / ④リーディング / ⑤その他(例外)。複製機能の有用性が新発見→ §3 反映済
  3. 3
    取引先マスタ CSV 突合せ:重複は「同一許容+例外は西川相談」、検索はペンネーム+会社名2系統、論理削除は使わず「※使用停止」運用で合意。→ §13 反映済
  4. 4 🚀
    新規取引先登録フローのブレイクスルー:発注の半数が新規という重大課題に対し、取引先本人がフォーム入力 → kintone自動連携 → 高橋がTHINKs転記 という抜本フローで合意。→ §13 で詳細設計
  5. 5
    クロージング:インボイス番号はマスタ管理不要、リリース目処6月中旬、UAT は高橋さん先行で合意。→ 完了
⚠️ 残P0項目:①🆕 Power Automate Premium 契約 + 西川用 M365アカウント発行(月¥4,122、窪田部長 + 情シス対応)/②著作権者マスタ項目「必須/任意・入力者」区分シート(高橋さん作成中)/③編集部 kintone ライセンス追加状況(窪田部長に確認)
解決した残論点:フォーム連携方式 B案 Microsoft Forms + Power Automate 採用(§13.6で詳細化)/書籍マスタ仮タイトル運用責任者と運用フロー(§14.6/14.7)/THINKs書籍マスタの担当編集者フィールド非存在を確認(§14.6で kintone CREATOR 自動コピー設計に変更)/編集担当者列の意味(コード+氏名で確定)/過去1年分支払依頼.xlsx 入手は 不要として前進
NEXT ACTIONS

17. 次のアクション

この資料を元に、次の1on1で合意・確認していきたい項目。

✅ 5/19 完了

高橋さん 60分MTG クロージング

Step 0 完了。5パターン命名・複製機能・新規取引先登録フロー・書籍マスタ問題対応など、設計確定に必要な合意を一気に取得。

→ Step 0 → Step 1 着手の Go 判定

🔴 5/20〜 最優先

Power Automate 契約 + 西川 M365 アカウント発行依頼

窪田部長 + 情シスに ①Power Automate Premium ¥2,248/月 ②西川用 M365 Business Standard ¥1,874/月 ③§13.6.5 権限スコープ設定 を依頼。実装着手のクリティカルパス

→ 2-3営業日のリードタイム。Step 1 開始時に間に合わせる必要あり

🔄 5/20〜(並行)

西川 持ち帰り検討事項

①発注書の書籍lookup設計(新刊レコード①連携、v1暫定はApp85直接)の詳細化/ ②Power Automate フロー設計詳細化(§13.6.2 の3フロー)/ ③Office Script HMAC 検証ロジック実装。

→ Step 1 着手と並行で実施。アカウント発行待ちの間に設計詳細化

📋 5/20〜(高橋さん)

著作権者マスタ 区分シート

マスタ38項目に対して「必須/任意」「入力者(編集者/取引先本人/高橋)」の区分を高橋さん側で記入。新規取引先登録フロー実装の前提。

→ 西川から区分テンプレ送付 → 返送待ち

📦 5/20-28

Step 1 マスタ整備

受領済CSV 2,487件の初期投入(38列→kintone REST API)+ rapidfuzz 名寄せ。書籍マスタ App85 は不変(ADR-001)。

→ 純工数 4日 / LT 9日

⚙️ 5/29-6/10

Step 2 発注書アプリ実装

5種統合フォーム + JSカスタマイズ(タブ切替・lookup・複製機能・PDF生成ボタン)+ Cloud Run PDF生成基盤。

→ 純工数 4.5日 / LT 13日

🚀 6/2-14(並行)

新規取引先登録フロー実装

取引先マスタアプリ + Microsoft Forms + Power Automate 3フロー構築(SupplierInvite / FormResponse / ScheduledReminder)。E2Eテスト含めて純工数7日。

→ Step 2 と並行・最大の差別化機能。Power Automate ライセンス発行後即着手

📋 6/11-20

Step 3 支払依頼アプリ実装

支払依頼アプリ + 派生ボタン + ワークフロー(編集→高橋)+ 月次CSVエクスポート。

→ 純工数 3日 / LT 10日

🚀 6/中旬〜7月

Step 4 UAT・段階展開

Stage 1: 高橋さんによる UAT → Stage 2: 編集部パイロット 2-3名 → 編集部全展開 + 旧Excel運用廃止アナウンス。

→ 6月中旬リリース目処(前倒し検討中)

🎉 SO WHAT — 5/19 MTG 後の Phase 1 確信度
Step 0(設計準備)は実質クロージング。前回の最大ブロッカー(業務委託先マスタの所在)+ 今回判明したブロッカー(書籍マスタ仮タイトル問題・新規取引先半数問題)すべてに対応方針を設定済。

Phase 1 の技術ブロッカーはほぼゼロ。残る論点は ①Power Automate ライセンス保有確認、②編集部 kintone ライセンス追加、③高橋さん区分シート返送、の3点のみ。

現実的スケジュール:5/20 Step 1 着手 / 6月末 Stage 1 UAT / 7月上旬 編集部展開。リリース目処 6月中旬・前倒し検討中