編集部 → 総務(高橋)の業務委託発注 〜 支払依頼フローを kintone に集約し、4種フォーマット統合・PDF自動出力・取引先表記揺れ撲滅を実現する。
編集部担当者が kintone 1画面で発注書を作成 → PDFが自動生成され取引先へ送付 → 同じレコードから支払依頼が派生 → 総務(高橋)が月次まとめて承認、という一気通貫の運用を実現する。
①書籍デザイン等/②撮影・校正・拡材等/③だいわlog連載/④リーディング/⑤その他(例外) を1つの kintone フォームに集約。業務種別 × 支払起算日 のドロップダウン選択で 5 種を完全に吸収(⑤は例外運用用、原則使用禁止・経理 高橋さん事前相談必須)。
「PDF生成」ボタン1つで規定レイアウトの発注書PDFを自動生成。kintoneレコードに添付ファイルとして保管され、紛失リスクゼロ・どこからでも参照可能。
「鷗来堂」「株式会社鷗来堂」「Ouraidou」が全部同じ取引先と認識される、表記揺れ吸収マスタ。高橋さんの THINKs 登録コード照合作業を大幅短縮。
発注書から「支払依頼を作成」ボタンで支払依頼レコードを自動生成。金額変更がある場合は理由を必須入力させ「発注書を作り直さない」運用ミスを構造的に防止。
編集部担当者 → 総務(高橋:支払日入力・最終確認)の 2ステップ を kintone プロセス管理で実装。河合さんは出版契約フロー(Phase 3)の担当で、本PJ(発注・支払)には関与しない。
支払予定月別の集計ビューで高橋さんの月次処理を効率化。CSV エクスポートで THINKs 印税入力・freee 会計取引登録へ連携(Phase 3で自動化)。
5/19 高橋MTG での新発見。自分が過去に申請した発注書を複製して新規作成可能。だいわlog連載(同額複数回)・定期発注(例:チコルズ山田さんへのカバー/本文デザイン)で「内容ほぼ同じ+一部だけ変更」の運用に対応し、入力負荷・金額ミスを大幅削減。権限は自分の過去発注のみ複製可(他人不可)。
5/19 高橋さま・西川MTGでの最大成果。新規取引先が発注の半数を占める課題に対し、編集者が最小項目入力 → 取引先本人にメール+Microsoft Forms自動送信(CC: 編集者・高橋)→ 回答が Power Automate で kintone マスタに自動連携 → 高橋がTHINKsに転記、という抜本フローを導入。Microsoft 365 既存基盤 + Power Automate Premium 月¥2,248 + 西川用 M365 アカウント月¥1,874 ≒ 月¥4,122で運用。詳細は §13 参照。
関係者・データの流れを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標準UIと比較しながらレビュー・改善する。以下は発注書アプリの実際の画面イメージです(確定したデザイン言語=墨+朱+紙のブランドで作成)。支払依頼・取引先マスタの全画面は §3 末尾リンクの詳細設計書を参照してください。
業務種別の選択で、支払起算日タイプ(①=校了日基準/②③④=納品日基準)と日付ラベル(①=「受領(校了)予定日」/それ以外=「納品予定日」)が setFieldShown/ラベル切替で自動連動します。⑤その他(例外)は薄い面+チップで「🚫 原則使用禁止」を伝え、赤2px枠やグラデでの過剰な警告はしません(状態色=状態専用の規律)。
setFieldShown)。②③④では「納品日基準」になります。⚠️ 上部(バナー+ステッパー+タブ)と本文は同じ中央幅(--uk-form-w 880px)に揃える。ただし地色は揃えない — 上部は kintone グレー地のまま=上下の境界を明示。発注書は承認フローが無いため、詳細タブは「内容/関連支払依頼」で構成します。
▼ 確定前(下書き)の詳細では、主役アクションが「発注書を確定」に切り替わります(ステータス依存・支払依頼ボタンは PDF生成済以降に表示):
docs/design/app-design-detail.html の §13(支払依頼)/§14(発注書)/§15(取引先マスタ)に対応します。本ブループリント §3 の発注書モックは、この詳細設計書 §14 と同一のデザイン言語・同一の型です。
関係者ごとに、いつ・何を・どう操作するかを整理。各ペルソナのストーリーが完結することを確認する。
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 取引登録(手動転記)
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
| テーブル | 種別 | 初期件数 | 増分 | キー | 主な用途 |
|---|---|---|---|---|---|
| 著作権者マスタ | マスタ | 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 | ペンネーム・別名でも検索可 |
| 書籍/企画 | lookup | ISBN or 企画名で検索 | |
| 業務内容 | 業務種別 | ドロップダウン | ①書籍デザイン等 / ②撮影・校正・拡材等 / ③だいわlog連載 / ④リーディング / ⑤その他(例外🚫) |
| 業務内容詳細 | テキストエリア | 例: 表1デザイン、本文DTP | |
| 報酬明細 | サブテーブル | 内容/単価/数量/金額(複数行) | |
| 合計金額(税抜/税込) | 計算フィールド | 自動計算 | |
| 納品・支払 | 受領/納品予定日 | 日付 | 業務種別によりラベル切替(JS) |
| 支払起算日タイプ | ドロップダウン | 校了日 / 納品日(業務種別から自動) | |
| 支払日(計算) | 計算フィールド | 翌月20日 | |
| 出力 | PDF添付 | 添付ファイル | 「PDF生成」ボタンで自動格納 |
| カテゴリ | フィールド名 | 型 | 備考 |
|---|---|---|---|
| 基本情報 | 支払依頼番号 | 文字列(自動採番) | PR-2026-0042 |
| 申請日 | 日付 | デフォルト: 今日 | |
| ステータス | プロセス管理 | 申請中 / 高橋確認中 / 完了 / 差戻 | |
| 発注書参照 | 発注書 | lookup | 派生時に自動入力 |
| 書籍/企画 | lookup | 発注書からコピー | |
| 支払内容 | 支払先表記 | 文字列 | 取引先名 or ペンネーム(編集可) |
| 金額確定値(税抜) | 数値 | 発注書からコピー、変更可 | |
| 金額修正理由 | テキストエリア | 発注書と異なる場合のみ必須(JSで強制) | |
| 金額(税込) | 計算フィールド | 源泉徴収反映可 | |
| 支払情報 | 支払予定日 | 計算フィールド | 支払起算日 + 締日 + 支払日から自動算出 |
| 支払日(振込) | 日付 | 高橋が入力、最終承認時 | |
| 振込先確認 | チェックボックス | 高橋が確認後ON | |
| その他 | 高橋メモ | テキストエリア | 編集部からは非表示 |
発注書を 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) | 予備案(品質要件次第で切替) |
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
| 発生タイミング | 内容 | 工数 |
|---|---|---|
| 年1回 | GCP Node.js ランタイム deprecation 対応 | 半日 |
| 年2-3回 | Puppeteer/Chrome のセキュリティパッチ反映 | 1-2時間 |
| 必要時 | PDFレイアウト変更要望(社印位置等) | 半日〜1日 |
| 初期設計に含めればOK | エラー時 Slack 通知 | 設計込み |
| 原則不要 | kintone API トークン期限切れ(無期限) | ― |
高橋さんの月次集計作業(現状2-3時間)を 30分以下 に短縮するための仕組み。kintone標準機能でほぼ実現可能。
高橋さんが日次・月次にどう操作するかを実画面イメージで。
| 支払依頼番号 | 申請者 | 著作権者 | 金額 | 支払予定日 |
|---|---|---|---|---|
| PR-2026-0042 | 荻田 | 株式会社鷗来堂 | ¥96,750 | 2026-06-20 |
| PR-2026-0043 | 荻田 | 合同会社チコルズ | ¥190,000 | 2026-06-20 |
| PR-2026-0044 | 田中 | キャメレオン竹田 | ¥120,000 | 2026-06-20 |
| ... 残り9件 | ||||
事前にビューを設定しておけば、毎回検索せずに目的の画面に1クリックで飛べる。
| 対象者 | ビュー名 | 抽出条件 | 用途 |
|---|---|---|---|
| 編集部 | 「自分の発注書」 | 担当編集者 = ログインユーザー | 自分の進行中案件チェック |
| 「自分の支払依頼」 | 申請者 = 自分 | 支払処理状況確認 | |
| 高橋 | 「支払日未入力」 | ステータス=高橋確認中 AND 支払日=空 | 日次の todo リスト |
| 「当月支払予定」 | 支払予定日 ∈ 今月 | 月次の支払総額把握 | |
| 「月次CSV出力用」 | ステータス=完了 AND 支払日 ∈ 指定月 | エクスポート対象抽出 | |
| 全員 | 「書籍別集計」 | 書籍でグルーピング、金額合計 | 1冊あたり総原価把握 |
高橋さん(毎月月末) │ │【1】「月次CSV出力用」ビューを開く ▼ [kintone] 完了レコードを抽出表示 │ │【2】右上「エクスポート」→ CSV ダウンロード ▼ [ダウンロードフォルダ] payment_2026-05.csv │ │【3-A】 THINKs 印税入力に手動投入(Phase 3で半自動化) │【3-B】 freee 取引登録に手動投入(Phase 3で API化検討) ▼ [完了] 月次経理処理完了
| 処理 | 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% |
高橋さんから 2026-05-15 にご共有いただいた「著作権者マスタ一覧.csv」を確認させていただきました。データの構造に合わせて kintone を設計することで、高橋さんの日々の業務がどう楽になるか を整理しました。
銀行コード、支店、口座番号、口座名義まで揃っているので、編集部が支払依頼を起票するときに 著作権者を選ぶだけで振込先情報が自動表示。転記ミスのご確認作業が不要になります。
「著作権者名」と「ペンネーム」が別の項目で記録されているおかげで、表記揺れの照合作業(THINKs登録コード全件確認)が解消。編集部が誰の名前で書いても、高橋さんの目に届く時には正規名で揃います。
個人著者(10.21%)1,576件、法人(0%)871件、非居住者(20.42%)22件 のパターンが整っているので、支払依頼起票時に 源泉税額を自動計算。電卓いらず。
登録済1,089件、未登録623件、登録予定なし226件、未確認548件 が整理可能。支払処理時に登録状況がひと目で分かる ようになります(インボイス番号自体は別管理かどうか5/19で確認させてください)。
「備考」欄に「著者」「イラストレーター」等の記載が散見されますが、明確なカテゴリ項目が見当たりませんでした。高橋さんは普段どうやって判別されていますか? 5/19で教えてください。
「編集担当者」項目が2つあるのは「コード」と「氏名」の組合せでしょうか?/「個人法人」に「ユウチヨ」が1件あるのは入力誤り?/「論理削除」項目が全件空のため、停止された取引先のエクスポート方法も合わせて伺いたいです。
どの連携が 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 検討 |
著作権者マスタは「初期投入で終わり」ではなく、新規契約・情報変更が継続的に発生する生きたマスタ。発生源と更新パスを整理。
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 自動化の安定運用が前提、長期構想) |
業務種別・金額変更・取引先タイプによって、kintoneアプリが分岐する処理を整理。
Phase 1 を5つのStepに分解。現在はStep 0(設計準備)の中盤。
実装を進めながらのテスト・パイロット展開で、事前に高橋さん・窪田部長に依頼しておきたいこと。
| タイミング | 確認・依頼事項 | 依頼先 | なぜ事前準備が必要か |
|---|---|---|---|
| 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一本化を社内通知 |
5/19 高橋さま・西川MTGで発覚した「新規取引先が発注の半数を占める」という重大課題に対し、 取引先本人に Microsoft Forms 入力してもらう抜本フローを設計。属人運用・表記揺れ・支払直前の駆け込み登録を構造的に解消する。 ✅ 採用方針:B案 Microsoft Forms + Power Automate — 楽楽明細運用と統一・公式 kintone コネクタで実装簡素化
シリーズ本でも別デザイナー/別イラストレーターになると完全新規。発注先の約半数が新規取引先。
「先に欲しい」と頼んでも情報が出てこず、支払直前まで著作権者マスタが作れない。高橋さんが夜に対応する状況が常態化。
取引先 → 編集者 → 高橋への伝言ゲームで誤記・抜け漏れ・表記揺れ発生。THINKsコード照合の追加作業が膨大。
銀行情報・インボイス・マイナンバー有無等は編集者が把握する情報ではない。代理入力させると間違いも増える。
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
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分程度でご入力いただけます。
ご入力内容:
ご入力後、自動的に弊社システムに反映されます。
ご不明な点は、CCの担当者または弊社経理担当(高橋)までご連絡ください。
引き続きどうぞよろしくお願いいたします。
株式会社大和書房
総務部 経理担当
本メールは大和書房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 コネクタで実装簡素化 | △ コスト高、新規ベンダ追加 |
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 に以下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日経過 → アーカイブ |
個別アクション失敗を「実行履歴」に記録、翌日のフロー実行で自動リトライ |
@{...} 記法)の記述が必要。
Microsoft 365 サブスクライバ向けの 「Office Script」でJavaScript相当の処理も差し込める。HMAC実装は Office Script を利用するのが堅牢。
| セキュリティ要素 | 対策 | 効果 |
|---|---|---|
| URL推測攻撃 | HMAC-SHA256 + 32文字署名(2^256 通り) | 総当り実質不可能 |
| URL漏洩リスク | 有効期限 7日 を URL に埋め込み | 古いURLが漏洩しても無効化済 |
| シークレット管理 | Azure Key Vault または Office Script 環境変数で保管 (Power Automate 接続参照経由) |
フロー設定画面からは見えない、IT管理者のみアクセス可 |
| 第三者の不正回答 | token + 取引先メアド + フォーム冒頭の本人確認チェックボックスの三重検証 | URL知らない限り回答不可、誤送信時も本人確認で気づける |
| Step | 作業内容 | 担当 | 工数 | アウトプット |
|---|---|---|---|---|
| 0 | 前提条件:Power Automate Premium 契約 + 西川用 M365 アカウント発行 | 窪田部長 + 情シス | 2-3営業日 | ライセンス契約 + 西川アカウント発行(実装着手のクリティカルパス) |
| 1 | 取引先マスタ kintone アプリ作成(§13.3 仕様準拠、webhook設定含む) | 西川 | 1日 | kintone アプリ + APIトークン |
| 2 | Microsoft Forms 設計・作成(§13.3 取引先入力項目を Forms に展開、事前入力URLパラメータ確認) | 西川 | 0.5日 | Microsoft Forms URL + 事前入力URL構造 |
| 3 | Power Automate Flow_SupplierInvite + Flow_FormResponse 構築(kintone コネクタ + Outlook コネクタ) | 西川 | 2日 | 2フロー実装完了 |
| 4 | Office Script で HMAC token 生成ロジック + Azure Key Vault シークレット保管 | 西川 | 0.5日 | HMAC生成/検証ロジック + シークレット保管 |
| 5 | Flow_ScheduledReminder(スケジュールトリガー:督促・期限切れ・アーカイブ) | 西川 | 0.5日 | 毎朝9時実行の督促フロー |
| 6 | テスト:内部メンバーで E2E 動作確認(編集者入力 → メール送信 → フォーム入力 → kintone反映 → 督促 → アーカイブ) | 西川 + 高橋さん | 1.5日 | 動作確認レポート + Power Automate 実行履歴確認 |
| 7 | 運用ガイド作成(編集者向け1枚 + 高橋さん向け1枚 + Power Automate 保守ガイド) | 西川 | 0.5日 | 運用マニュアル3種 + フロー所有権移譲手順書 |
| 合計工数 | 7日 | 純工数(前提条件Step 0除く)。リードタイム12営業日(直列実装、ライセンス発行含む) | ||
| ライセンス / アカウント | 月額 | 対象者 | 必要な理由 |
|---|---|---|---|
| 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(消費税別) | |
| パターン | フロー所有者 | 月額追加 | 特徴・適用フェーズ |
|---|---|---|---|
| パターン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名が引き継ぎ可能、二段構えで安全 |
→ 西川アカウント有効中は無償サポート、移管後は別途保守契約 or 大和書房側で運用継続。
GAS で個人情報・口座情報を扱うため、QA観点でレビューした問題点に対する設計対策を多角的に整理。
URLに ?token={hmac}&exp={timestamp} 付与、GAS側で再計算して検証。32文字署名(2^256通り)で総当り実質不可、有効期限7日で漏洩リスクを時限化。
フォーム冒頭に「あなたのお名前・屋号」確認チェックボックス必須化。編集者の誤メアド入力 / 会社共通メアド経由の誤回答を防ぐ。回答完了時に取引先メアドに完了通知も自動送信。
Power Automate 実行履歴 + SharePoint ログから口座番号・マイナンバー等を自動マスキング(例: 「1234-5678」→「****-****」)。アクション設定の「セキュリティで保護された入出力」機能で機密フィールドの履歴記録を抑制。半年に1回ログ監査を運用ルール化。
口座情報・マイナンバー有無は kintone で 閲覧権限を高橋さん・経理のみに限定。編集者・他部署には非表示設定。
kintone コネクタ通信失敗時は Power Automate 標準リトライ機能で3回再試行(指数バックオフ自動)。それでも失敗なら「実行に失敗した場合」アクションで高橋さんに通知 + 実行履歴に記録。
kintone コネクタでレコード更新する際、フロー冒頭で「現在のステータス取得」アクションを実行し、既にステータス=入力済 ならスキップ。取引先が複数回フォーム送信しても重複更新が発生しない設計。
Premium プランの30日アクション数 250,000回上限内で動作可能(想定月数百件規模なら十分余裕)。督促バッチは「分割実行」で 100件単位処理、Forms 回答も非同期処理で並列実行可能。
同じ kintone_id に対して複数フォーム回答が来た場合は後勝ち + 高橋さんに警告。取引先が分担入力するケースに対応。
| 経過日数 | アクション | 通知先 | kintoneステータス |
|---|---|---|---|
| 7日経過 | 督促メール自動送信 | 取引先 + 編集者 + 高橋さん | 「📨 取引先入力依頼中」のまま |
| 14日経過 | 期限切れ警告 + 高橋さん通知 | 高橋さん(個別フォロー対応依頼) | 「⚠️ 期限切れ」に自動変更 |
| 30日経過 | レコードアーカイブ | 高橋さん(最終通知) | 「🗄️ アーカイブ」(論理削除相当) |
編集者が新規登録時にメアド欄を空にする → 自動で高橋さんに通知 → 高橋さんが楽楽明細の登録シートを取引先に郵送 → 返送後に kintone マスタを手動入力。ステータス「📮 紙運用」で別軌道管理。
口座変更・住所変更等の更新時、高橋さんが kintone マスタを開いて「🔄 情報更新を依頼」ボタンクリック → 同じユニークURL生成ロジックで再送。変更履歴サブテーブルに過去情報を保持。
更新時、kintone JS で「変更前 / 変更後」を並列表示。高橋さんが目視確認のうえ承認 → 確定で本番反映。誤入力リスクを構造的に防ぐ。
Power Automate Premium ライセンス継続困難になった場合、A案 Google Apps Script に切替可能。kintone マスタ仕様・メール本文・運用フローは同一のため、移行コスト中程度(GAS実装で純6日)。
| テスト種別 | シナリオ | 担当 | 合格基準 |
|---|---|---|---|
| 正常系 E2E | 編集者新規登録 → メール送信 → 取引先フォーム入力 → kintone自動反映 → 高橋さん通知 | 西川(実装側)+ 高橋さん(受領側) | 全Step 5分以内完了、データ100%反映 |
| 異常系:HMAC不一致 | URLパラメータ改竄、トークン欠落、期限切れ | 西川 | すべて拒否、エラー画面表示 |
| 異常系:通信失敗 | kintone コネクタ一時失敗、Power Automate標準リトライ動作確認 | 西川(kintone側 一時停止シミュレーション) | 3回リトライ後成功 or 高橋さん通知 |
| 異常系:重複送信 | 取引先が同じフォームを2回送信 | 西川 | 後勝ち更新 + 高橋さんに警告通知 |
| 督促・期限切れ | 7日/14日/30日経過をシミュレート(日時を手動変更) | 西川 | 督促メール送信 → ステータス自動変更 → アーカイブ |
| 例外運用 | メアド無し → 紙運用フロー | 高橋さん | kintone ステータス「📮 紙運用」で手動完結 |
| セキュリティ | Power Automate 実行履歴 + SharePointログに口座番号等が漏れていないか確認 | 西川 | 「セキュリティで保護された入出力」適用、平文機密情報なし |
| フェーズ | タイミング | 作業内容 | アウトプット |
|---|---|---|---|
| Phase α | Step 6 完了直後 | パターン1(西川アカウント所有)で本番稼働開始 1-2ヶ月モニタリング期間 |
稼働実績データ + バグ発生履歴 |
| Phase β | Phase 1 完了時点(7月末想定) | パターン3(共同所有)に切替:大和書房側1名を共同所有者として追加 Microsoft Forms・トリガーは設定変更なし(テナント内移譲のため簡単) |
共同所有完了、稼働継続 |
| Phase γ | 移譲後 1ヶ月 | 大和書房側で稼働確認、引き継ぎ完了確認 西川アカウント停止 or 保守継続契約判断 |
運用保守ガイドの最終版 |
2026-06-05 新刊フローキックオフ確定スコープを受けて、v3.3 までの §14「書籍マスタ拡張案」を大幅縮減。 新刊フロー側で4アプリ(①新刊搬入日登録/②初版申請/③カレンダー/④ポータル)が確定し、 ①新刊レコードが書籍lookup の真のハブとして設計済み。purchase-order PJ から見ると「書籍マスタ App85 は触らない」が最終結論。
詳細:book-master-extension.md(縮減版) / integration-with-shinkan-flow.md / ADR-001
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 "取引先参照"
}
| 観点 | 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 触らないため) |
新刊フロー① 未稼働期間の暫定運用。発注書アプリで App85 を直接 lookup。書籍/企画が見つからない場合はフリーテキスト入力で代用。
新刊フロー① 完成後、発注書アプリの lookup 先を新刊レコード①に切替。kintone JS の lookup イベントをリファクタ + 過去発注書はそのまま維持。
新刊フロー① が編集部に浸透。発注書を出す前に新刊レコード① が存在する状態が常態化。Phase 2 で業務委託契約との連携を追加。
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
| 影響箇所 | どう壊れるか | 補足 |
|---|---|---|
| 発注書アプリの書籍 lookup | 機能しない(マスタにレコードなし) | 編集者が「書籍を選択」できない |
| 書籍別の発注一覧表示 | 紐付け不可 | 関連レコード一覧が機能しない |
| 経理:書籍別原価集計(決算) | 引き続き属人化(高橋さんの記憶頼み) | 「私の記憶力と分用でカバーしている状態」(5/19高橋さん談) |
| Phase 2/3:書籍↔著作権者紐付け | 紐付け先がない | 業務委託契約・出版契約のマスタ参照不可 |
| 支払依頼アプリ | 書籍名フリーテキスト化 | 発注書から派生でも書籍紐付けが弱い |
| 案 | アプローチ | 概要 | 編集者負荷 | 高橋負荷 | 原価集計 | THINKs整合 | 実装工数 |
|---|---|---|---|---|---|---|---|
| A | フリーテキスト + 後付けマージ | 書籍名は単純な文字列入力。ISBN取得後に「書籍マスタ」を選択しなおして紐付け(手動) | ◎ 最小 | △ 後でマージ作業 | × 低(手動マージ漏れ) | △ 不整合発生 | ◎ 小(0.5日) |
| B | 企画マスタ アプリ新設 | 書籍マスタとは別に「企画マスタ」アプリを新規作成。仮タイトル時点で先行登録、ISBN取得時に書籍マスタに昇格 | △ 中(企画登録の手間) | △ 中(マスタ管理2箇所) | ◎ 高 | △ 別途同期設計必要 | × 大(3-5日) |
| C 🎯 | 既存書籍マスタを企画段階から使用 | 書籍マスタにステータスフィールド追加。企画中・ISBN取得済・刊行済・絶版 を許容、ISBN空欄も許容 | △ 中 | ◎ 小 | △ 中(ステータス管理必要) | ◎ 高(半自動同期可) | △ 中(1-2日) |
| D 🎯 | 軽量プロビジョナル登録 | 編集者が発注時に書籍マスタへ最小項目(仮タイトル・著者名想定・担当編集者)でレコード作成。ISBN取得時にTHINKsデータで上書き | △ 中 | △ 中 | ◎ 中(仮IDで集計可) | ◎ 自動同期 | △ 中(1.5日) |
既存書籍マスタ ID 85(1,245件)を 企画段階から使えるよう拡張し、発注書アプリから直接「企画段階レコード」を作成できる動線を追加。 ISBN取得後にTHINKsから自動同期で上書きされ、本登録扱いに自動昇格。
| # | フィールド名 | 入力者 | 必須 | 備考 |
|---|---|---|---|---|
| 1 | 書籍ステータス 🆕 | 編集者 → THINKs | ✅ | 企画中 / ISBN取得済 / 刊行済 / 重版中 / 絶版(企画段階レコードを許容) |
| 2 | 仮タイトル 🆕 | 編集者 | — | 正式タイトル決定前の作業タイトル |
| 3 | ISBN | THINKs同期 | — | 企画段階では空欄許容、取得時に自動入力 |
| 4 | 企画名 / 正式タイトル | 編集者 → THINKs | ✅ | 初期は仮タイトル、正式タイトル決定後に上書き |
| 5 | 著者名(想定) | 編集者 | — | 企画段階の想定著者 |
| 6 | 担当編集者 🆕 | 自動(kintone CREATOR) | ✅ | kintone JS で CREATOR を自動コピー(編集者は手動入力ナシ)。THINKs側に該当カラム無いため突合キーには使わず、候補表示時の補助情報として利用 |
| 7 | 公刊期日 | THINKs同期 | — | — |
| 8 | 体裁 | THINKs同期 | — | 例:四六判 並製 192頁 |
| 9 | 初版発行部数 | THINKs同期 | — | — |
| 10 | 本体価格 | THINKs同期 | — | — |
| 11 | 責了日 | THINKs同期 | — | 発注書「校了日基準」支払日計算の基準 |
| 12 | レーベル | THINKs同期 | — | 単行本 / 文庫 / だいわ文庫 / 雑誌 / だいわlog |
| 13 | kintone作成日 🆕 | 自動 | — | 企画段階レコード作成時刻 |
| 14 | THINKs同期日時 | 自動 | — | 企画段階 → 本登録 への昇格日時の管理 |
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
核心課題:仮タイトル時点で発注書を出した後、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側にデータ無し → 突合キーに使えない。 ただし候補表示画面で「あ、これ中山さんの企画」と高橋さんが目視判定する補助に有効 |
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仮レコード | 担当編集者 (補助情報) |
想定著者 | 想定発売月 | アクション |
|---|---|---|---|---|---|
| 92点 | 「test 健康レシピ本(仮)」 | 中山 淳也 | ロン毛メガネ | 2025-12 | ✅ このレコードと紐付け |
| 65点 | 「タイトル未定_新企画」 | 中山 淳也 | 不明 | 2026-01 | 候補から外す |
| 52点 | 「料理本 仮タイトル」 | 林 陽一 | ロン毛メガネ | 2026-02 | 候補から外す |
書籍マスタ「企画中」レコードの仮タイトル → 正式タイトルへの更新運用について、 誰が・いつ・何を行うかを明示。編集者が主・高橋さんが月次レビューの2層責任構造を推奨。
| 段階 | タイミング | 主責任者 | アクション | 承認・確認 |
|---|---|---|---|---|
| ① 企画起動 | 企画立ち上げ直後(発注書作成時) | 担当編集者 | 発注書アプリから「🆕 企画段階で新規登録」ボタンクリック → 仮タイトル・想定著者のみ入力(担当編集者はkintone CREATOR から自動コピー、手動入力ナシ) → ステータス「📝 企画中」でレコード作成 |
— |
| ② タイトル更新 | 正式タイトル決定時(随時) | 担当編集者 | kintone書籍マスタを開いて仮タイトル → 正式タイトルに上書き 必要に応じて著者名も正式名へ更新 |
—(編集者自身の判断) |
| ③ 月次レビュー | 毎月末〜月初(高橋さん月次処理時) | 高橋さん | 「ステータス=企画中」ビューで 3ヶ月以上更新がないレコード を抽出 担当編集者に「最新タイトル教えてください」と確認依頼 |
編集者からの返信を待ってマスタ更新 |
| ④ ISBN取得 | 刊行 2-3ヶ月前 | 高橋さん | THINKsにISBN・書誌情報を登録 (既存運用、変化なし) |
— |
| ⑤ 検索マッチング | ISBN登録直後(高橋さん操作) | 高橋さん | kintone書籍マスタを開いて「🔍 企画中レコードから候補を探す」をクリック §14.6 の検索マッチング画面でスコア順候補表示 担当編集者列を見て目視で1件選択 |
— |
| ⑥ 候補承認 | マッチング画面から(即時) | 高橋さん | kintone「マッチ候補承認待ち」ビューを確認 各候補に対して「承認 / 新規扱い」を判定 → 1件あたり1分以内で完了 |
編集者には通知のみ(編集者は意識せずに本登録完了) |
| ⑦ 例外対応 | 新規扱いになったレコード発生時 | 高橋さん + 担当編集者 | マッチしなかったレコードについて、過去発注書を手動で本書籍に紐付け 原因(想定著者未入力等)を分析して改善 |
— |
Phase 1(発注書・支払依頼)が安定運用したあとの拡張スコープを正直ベースで整理。「完全自動」と書きたいところを「半自動」に補正し、実現性のグラデーションを明示する。
| コンポーネント | 残論点(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ヶ月 | |
| コンポーネント | 残論点 | 期待値(実現確度) | 工数感 |
|---|---|---|---|
| 出版契約アプリ(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実績あり、優先度次第で実装可能 |
編集部 8割が kintone 発注書を日常使用、月次支払処理が30%以上時短、ビズロボ廃止判断のデータ揃いの3つが揃ってから Phase 2 に進む。
河合さん経由でDocuSignアカウントの API 利用権限を取得、既存契約との整合方針を合意。Phase 2 着手前に1on1必須。
5-7日のPoCで「THINKs UIをPywinautoで安定操作できるか」を実証。失敗時はマスタ更新を手動継続 + ビズロボ廃止見送り判断。
実装に必要な情報のうち、現状不足しているもの・大和書房さま側にしかない情報を構造的に整理。
この資料を元に、次の1on1で合意・確認していきたい項目。
Step 0 完了。5パターン命名・複製機能・新規取引先登録フロー・書籍マスタ問題対応など、設計確定に必要な合意を一気に取得。
→ Step 0 → Step 1 着手の Go 判定
窪田部長 + 情シスに ①Power Automate Premium ¥2,248/月 ②西川用 M365 Business Standard ¥1,874/月 ③§13.6.5 権限スコープ設定 を依頼。実装着手のクリティカルパス。
→ 2-3営業日のリードタイム。Step 1 開始時に間に合わせる必要あり
①発注書の書籍lookup設計(新刊レコード①連携、v1暫定はApp85直接)の詳細化/ ②Power Automate フロー設計詳細化(§13.6.2 の3フロー)/ ③Office Script HMAC 検証ロジック実装。
→ Step 1 着手と並行で実施。アカウント発行待ちの間に設計詳細化
マスタ38項目に対して「必須/任意」「入力者(編集者/取引先本人/高橋)」の区分を高橋さん側で記入。新規取引先登録フロー実装の前提。
→ 西川から区分テンプレ送付 → 返送待ち
受領済CSV 2,487件の初期投入(38列→kintone REST API)+ rapidfuzz 名寄せ。書籍マスタ App85 は不変(ADR-001)。
→ 純工数 4日 / LT 9日
5種統合フォーム + JSカスタマイズ(タブ切替・lookup・複製機能・PDF生成ボタン)+ Cloud Run PDF生成基盤。
→ 純工数 4.5日 / LT 13日
取引先マスタアプリ + Microsoft Forms + Power Automate 3フロー構築(SupplierInvite / FormResponse / ScheduledReminder)。E2Eテスト含めて純工数7日。
→ Step 2 と並行・最大の差別化機能。Power Automate ライセンス発行後即着手
支払依頼アプリ + 派生ボタン + ワークフロー(編集→高橋)+ 月次CSVエクスポート。
→ 純工数 3日 / LT 10日
Stage 1: 高橋さんによる UAT → Stage 2: 編集部パイロット 2-3名 → 編集部全展開 + 旧Excel運用廃止アナウンス。
→ 6月中旬リリース目処(前倒し検討中)