登録→消込パターンカタログ (入力業務イベント × 業務段階マトリクス)

📌 本ドキュメントの位置付け: 本システムを流れる 全入力業務イベント（支出 + 売上） を「業務イベント × 業務段階 × 実装状況」のマトリクスで一望し、さらに「3 軸 × 36 パターン × 10 フロー × 6 段階構造」で網羅した横断的なパターンカタログ。各個別 spec (spec_rpa_*.md / spec_engine.md / spec_stl_auto.md 等) を統合的に俯瞰するためのリファレンスであり、自動化進捗の SSoT として機能する（運用ルールは §8）。

視点の差: 本表 = 業務イベント × 業務段階（経営者・運用者向け俯瞰）／ _internal/TODO_future.md §3 = Phase × Layer（開発バックログ）。両者で同じ案件を別軸から見るため、相互参照しながら使う。

2026-04-30 移動: 本ドキュメントは元々 docs/_internal/TODO_future.md §6 に記載されていたが、内容が静的・運用ログではなくシステム仕様の付録として位置付けが妥当なため、docs/spec/ 配下に独立移動 (PR #418)。

目的

個別案件 (MAS-XX 等) の位置付けや未着手領域を「業務イベント単位でどの段階まで自動化されているか」で可視化
自動化の進捗 (✅ 完了 / 📝 仕様書完了 / 🟡 未着手 / 🔴 手入力のみ) を一覧で把握
段階別ボトルネック (① 登録 → ② INV 生成 → ③ 証憑保管 → ④ Action A → ⑤ マッチ → ⑥ Action B) の解消案件をマッピング
INV / STL / ORD のステータス遷移とユーザ語彙（未登録 / 登録済 / 承認 / 消込）の対応を明示

1. 3 軸の定義

軸	値	意味
計画性	計画 / 予算 / 事後発生	事前にマスタ登録があるか、予算枠のみか、証憑到着と同時に発生するか
消込方法	銀行STL / カードSTL / 立替精算STL / 小口現金 / 仕訳振替 / 売掛入金STL	残高を減らす対象（売上側は売掛入金 STL）
取込方式	Drive→OCR / CSV / 写真 / スキャナ / API / メール / 手入力	証憑・データのシステム取込経路

理論最大 3 × 6 × 7 = 126 通りだが、実際に成立するのは 36 パターン（支出側、§4 集約表参照）。売上側は別系統で§2 行 #17-19 として記載。

2. 業務イベント × 業務段階マトリクス

読み方: 縦軸 = 入力業務イベント（請求書/領収書/銀行明細/給与/CAPEX/売上 …）、横軸 = 業務段階（C1 入力 → C5 消込）。各セルに自動化の現状を ✅📝🟡🔴 で示し、C6 列で行全体の総合判定。

列定義

列	ラベル	内訳（既存 6 段階）	セル記載
C1	入力	① 登録 + ③ 証憑保管	取込方式 + 対象シート
C2	起票（未承認）	② INV/STL 生成	INV_NEW 到達手段
C3	承認	④ Action A	INV_NEW → INV_APR トリガ
C4	マッチ	⑤ STL ↔ 銀行/カード明細	STL_NEW → STL_CLR ロジック
C5	消込	⑥ Action B	INV_PAR / INV_CMP 確定
C6	状況	—	✅/📝/🟡/🔴 + 担当 MAS-XX + 主spec

凡例: ✅ 完了（稼働中） / 📝 仕様書完了（実装待ち） / 🟡 未着手（計画あり） / 🔴 手入力のみ / — 対象外

業務イベント縦軸（19 行）

#	業務イベント	APL	主シート	C1 入力	C2 起票	C3 承認	C4 マッチ	C5 消込	C6 状況
1	取引先請求書 PDF（メール / Drive）	AP	32_wrk_invoice	📝 OCR	📝 自動起票	✅ Action A	✅ Action B 連動	✅ Action B	📝 MAS-147 / spec_rpa_adhoc
2	取引先請求書（紙→スキャナ）	AP	32	🟡 複合機→Drive	🟡 OCR後自動起票	✅ Action A	✅ Action B 連動	✅ Action B	🟡 MAS-173 / spec_rpa_adhoc
3	取引先領収書 PDF（支払後・Drive/メール）	AP	32_wrk_invoice	📝 PDF→OCR	📝 OCR後自動起票	✅ Action A	✅ 銀行STL（支払済照合）	✅ Action B	📝 MAS-147 / spec_rpa_adhoc
4	給与（SaaS API）	HC	22→32	✅ API取込	✅ 407_rpa_hc 複数INV生成	✅ Action A	✅ 銀行振込STL	✅ Action B	✅ MAS-074 / spec_rpa_hc
5	源泉・社保（給与控除）	HC	32 派生	✅ 給与から派生	✅ 控除INV自動生成	✅ Action A	✅ 仮想消込	✅ 仮想消込	✅ spec_rpa_hc + ADR-0015
6	立替経費レシート（写真）	EX	35_wrk_receipt	📝 写真→OCR	📝 35→26枠紐付け	📝 Action A	📝 立替精算STL	✅ Action B	📝 MAS-157 / spec_receipt_import
7	立替経費レシート（PDF）	EX	35_wrk_receipt	📝 PDF→OCR	📝 35→26枠紐付け	📝 Action A	📝 立替精算STL	✅ Action B	📝 MAS-157 / spec_receipt_import
8	小口現金レシート	EX	35	🔴 手入力	🔴 手入力	✅ Action A	🔴 手動目視	✅ Action B	🔴 spec_receipt_import
9	サブスク（SaaS 予算枠あり）	TR	23→32→34_wrk_card	✅ クレカCSV	✅ 501_cc 自動マッチ	✅ Action A	✅ 辞書ヒット自動	✅ Action B	✅ spec_cc_import
10	サブスク（予算枠外・予期外課金）	TR	34 直接	✅ クレカCSV	📝 マスタ自動生成	📝 Action A	📝 辞書外フォールバック	✅ Action B	📝 MAS-146 / MAS-171
11	法人カード明細（予算消化）	TR	26→34	✅ クレカCSV	✅ 501_cc 自動マッチ	✅ Action A	✅ 3パス自動	✅ Action B	✅ spec_cc_import
12	法人カード明細（立替類似フロー）	EX/TR	34 → 35	✅ クレカCSV	📝 立替紐付け	📝 Action A	📝 35との突合	✅ Action B	📝 spec_cc_import
13	銀行入出金（CSV 取込）	TR	33→36_wrk_bank_import	✅ CSV取込	✅ 407_rpa 月次	✅ Action A	✅ 3パス自動	✅ Action B	✅ MAS-145 / spec_pipeline_ingest
14	銀行入出金（API 直接）	TR	33→36	🟡 銀行API	✅ 407_rpa 月次	✅ Action A	✅ 自動	✅ Action B	🟡 MAS-181
15	CAPEX 検収・支払	AP/JE	24→32	📝 PDF取込	📝 OCR後自動起票	✅ Action A	✅ 銀行STL	✅ Action B	📝 spec_rpa_capex + ADR-0016
16	ファイナンス（借入・利息）	JE	25→32	🔴 手入力	✅ 407_rpa_finance	✅ Action A	✅ 銀行STL	✅ Action B	✅ spec_rpa_finance
17	アドホック計画支出	AP	26→32	🔴 手入力	✅ 407_rpa_adhoc	✅ Action A	✅ 銀行STL	✅ Action B	✅ spec_rpa_adhoc
18	振替伝票（手入力）	JE	32 直接	🔴 手入力	🔴 手入力	🔴 手入力	—	—	🔴 spec_engine（仕訳振替＝完全一致）
19	売上請求書発行（自社→取引先）	TBD	21_bud_pipeline→32	🟡 パイプライン管理	🟡 INV発行RPA	🟡 Action A	—	—	🟡 spec_pipeline_plan
20	売上入金（銀行入金照合）	TBD	33	✅ CSV取込	✅ 407_rpa 月次	✅ Action A	🟡 売掛突合	🟡 売掛消込	🟡 spec_pipeline_ingest
21	売掛金消込（部分/全額）	TBD	32 売掛	—	—	—	🟡 入金STL紐付け	🟡 Action B 売掛版	🟡 spec_engine + ADR-0014

集計 (C6 列ベース): ✅ 7 行 / 📝 8 行 / 🟡 5 行 / 🔴 1 行 = 21 行（売上行 19-21 はすべて 🟡 または 📝。支出行 1-18 は ✅ 過半数）。§7 のパターン別カバレッジとは集計軸が異なる（こちらはイベント単位）。

📎 C6 のリンク補足: MAS-XX のアンカーリンクは _internal/TODO_future.md §3 全案件マスタテーブル を前提にしている。仕様書完了案件は docs/spec/spec_*.md への相対リンクも併置。

3. ステータス遷移図 (INV / STL / ORD)

ステータスコード定義の出典: mas/100_config/101_sys_config.js L1483-1485

3.1 INV（請求ID）ステータス遷移

stateDiagram-v2
  [*] --> INV_NEW : ②起票
  INV_NEW --> INV_APR : ④Action A 承認
  INV_APR --> INV_PAR : ⑥Action B 部分消込
  INV_PAR --> INV_CMP : ⑥全額消込
  INV_APR --> INV_CMP : ⑥一括消込
  INV_NEW --> INV_CAN : 取消
  INV_APR --> INV_CAN : 取消

ステータス	コード	ユーザ語彙	§2 列との対応
INV_NEW	未処理	「登録済・承認待ち」	C2 到達
INV_APR	承認済	「承認済・未消込」	C3 到達
INV_PAR	部分決済	「部分消込済」	C5 到達（部分）
INV_CMP	決済完了	「消込済」	C5 到達（完了）
INV_CAN	取消	「無効化」	—

詳細ロジック: ADR-0014 INV ステータス遷移

3.2 STL（決済ID）ステータス遷移

stateDiagram-v2
  [*] --> STL_NEW : ④Action A で自動生成
  STL_NEW --> STL_CLR : ⑤マッチ確定
  STL_NEW --> STL_REJ : 差戻
  STL_CLR --> STL_REJ : 差戻（消込解除）

ステータス	コード	ユーザ語彙	§2 列との対応
STL_NEW	未処理	「消込待ち」	C2 到達
STL_CLR	消込済	「マッチ済（Action B 入力可）」	C4 到達
STL_REJ	差戻	「マッチ無効化」	—

詳細ロジック: ADR-0015 STL 消込 vs 天引き / ADR-0017 33_wrk_bank 集計条件 / spec_stl_auto.md

3.3 ORD（発注ID）ステータス遷移

stateDiagram-v2
  [*] --> ORD_EST : 見積取得
  ORD_EST --> ORD_ORD : 発注確定
  ORD_ORD --> ORD_PAR : 部分納品
  ORD_PAR --> ORD_CMP : 全数納品
  ORD_ORD --> ORD_CMP : 一括納品
  ORD_EST --> ORD_CAN : 取消
  ORD_ORD --> ORD_CAN : 取消

ステータス	コード	ユーザ語彙	§2 行との対応
ORD_EST	見積中	「見積取得済」	行 #13 (CAPEX) の前段
ORD_ORD	発注済	「発注確定」	行 #13 (CAPEX) / #15 (アドホック) の前段
ORD_PAR	部分納品	「一部検収済」	C2 到達前
ORD_CMP	完了	「全数検収済」	C2 トリガ
ORD_CAN	取消	「発注無効化」	—

ORD は §2 のすべてのイベントには関与しない（主に CAPEX / アドホックの大型発注で使う前段ライフサイクル）。詳細: spec_ord.md

4. 36 パターン × 10 フロー (集約表)

§2 の 業務イベント単位 をさらに「処理フロー単位」に集約したビュー。36 パターンを 共通する処理フロー で 10 種類にグルーピング。§2 の各行末「関連 Flow#」と対応する。

#	フロー名	パターン数	主要案件	登録（マスタ）	INV 生成	証憑	STL 生成	マッチ	消込
1	銀行CSV 自動マッチ	2	✅ MAS-145	23/25tab 事前	407_rpa 月次	任意	MAS-145 CSV取込	3パス自動	Action B
2	請求書 PDF OCR	5	📝 MAS-147	23/25/26tab 事前	OCR → 32tab 自動起票	Drive PDF	銀行/カード CSV	既存マスタと照合	Action B
3	クレカ CSV 自動承認	3	✅ 501_cc / 📝 MAS-146 / MAS-171	事前 (計画/予算) or 事後	RPA or CC明細マッチ	クレカ CSV	501_cc → 34tab	辞書ヒット自動	Action B
4	写真レシート（予算枠消化）	5	📝 MAS-157	26tab 事前	OCR → 35tab → 26枠紐付け	写真	カード／立替／小口	金額・取引先	Action B
5	写真レシート（事後マスタ自動起票）	3	📝 MAS-157 + MAS-150/MAS-169	取込時に自動生成	OCR → マスタ生成 → INV	写真	同上	同上	Action B
6	給与SaaS（API + 仮想消込）	2	📝 MAS-158 / ✅ MAS-074	22tab 事前	API → 407_rpa_hc で複数INV	給与明細	仮想消込 + 銀行振込STL	自動	源泉＝仮想 / 差引＝Action B
7	Outlook メール自動取込	4	🟡 MAS-155	事前	メール→Drive自動投入→OCR	メール添付 PDF	銀行/カード CSV	自動	Action B
8	スキャナ経由（紙→電子化）	2	🆕 MAS-173	26tab 事前	複合機→Drive自動→OCR	スキャンPDF	立替／小口	金額・取引先	Action B
9	銀行 API 直接取得	1	🟡 MAS-181	23/25tab 事前	407_rpa 月次	銀行 API JSON	MAS-181 連携	自動	Action B
10	手入力（自動化なし）	9	🆕 MAS-174（UI化）	事前 or 事後手動	手動で 32tab / 35tab 記入 → MAS-174 サイドバー UI	手元保存（Drive手動）	手動 or CSV	手動目視	手動 or Action B

合計 36 パターン（2+5+3+5+3+2+4+2+1+9。支出側のみ。売上側は §2 行 17-19 として別管理）

5. 共通する 6 段階構造

①登録      → ②INV生成      → ③証憑保管 → ④Action A              → ⑤マッチ              → ⑥Action B
(23〜26tab)   (32/35tab)       (Drive)     (INV承認→仕訳+STL自動作成)   (STL ↔ 銀行/CC 明細)   (消込→決済仕訳+残高更新)
                                            → 42_trn_journal + 33/34tab                        → 42_trn_journal + 32tab 残高

§2 の列との対応: C1=①+③ / C2=② / C3=④ / C4=⑤ / C5=⑥（C6 は総合判定列）

Action A（④）: 承認済 INV から仕訳を起票すると同時に、現金が動く INV の STL を自動作成（33/34tab）。詳細は仕訳エンジン (spec_engine.md) / STL 自動作成 (spec_stl_auto.md)。
Action B（⑥）: マッチ確定済 STL から決済仕訳を起票し、INV の未決済残高を再計算。
Flow 5（事後マスタ自動起票）のみ ①と②の順序が逆転し、「証憑到着 → マスタ自動生成 → INV」という後追い構造になる。

6. 段階別ボトルネックと解消案件

段階	既存の痛み	主な解消案件
② INV 生成	手入力 or RPA 任せ	MAS-147 / MAS-157 / MAS-158
③ 証憑保管	Drive 手動投入	MAS-155 / MAS-173（複合機スキャン連携🆕）
④ Action A (起票 + STL 自動作成)	STL 自動作成漏れ / 二重起票リスク	MAS-159✅ / MAS-122
⑤ マッチ (STL ↔ 明細)	銀行明細の突合せ手間・目視確認の負担	MAS-145✅ / MAS-146 / MAS-171 / MAS-181
⑥ Action B (消込確定)	月次締めの順序ミス・未処理検知不足	MAS-148 / MAS-160 / MAS-167

7. ステータス別カバレッジ

§4 の 36 パターン（支出側）を自動化ステータスで集計したビュー。§2 の C6 列（イベント単位 19 行）とは集計軸が異なるため数値が一致しない点に注意。

ステータス	パターン数	比率
✅ 完了（稼働中）	6	17%
📝 仕様書完了（実装待ち）	14	39%
🟡 未着手（計画あり）	7	19%
🔴 手入力のみ（自動化計画なし）	9	25%

📝 実装完了時点で 56% 自動化（6 + 14）
🟡 未着手を含めた全実装で 75% 自動化
残り 25% は事後発生系・小口現金系で、人間の認識行為が業務上必然 な領域

8. 更新運用ルール

本ドキュメントは自動化進捗の SSoT（Single Source of Truth） として運用する。案件ステータスが変わったときの更新順序:

本§2 の C6 セルを更新（経営者・運用者が最初に見る俯瞰ビュー）
docs/_internal/changelog.md に変更を 1 行追記（PR / コミットハッシュ付き）
docs/_internal/TODO_future.md §3 のフラグを追従更新（開発バックログ）

理由: 本表は「経営視点の俯瞰」、TODO_future は「開発バックログ」で粒度が異なる。上流（俯瞰）から動かすことで齟齬を最小化し、「経営報告では完了扱いだが TODO では着手中」のような乖離を防ぐ。

四半期ごとに§7 のステータス別カバレッジ集計（パターン単位）と§2 の C6 集計（イベント単位）を突合し、数値乖離があれば §2 が正として扱う。§4 の 36 パターン表は集計の根拠資料であり、§2 とは独立に保守する（粒度が違うため）。

ステータス遷移定義（§3）は mas/100_config/101_sys_config.js L1483-1485 が SSoT。コード変更時は本§3 の表記も追従させる（変更時テスト表に該当: mas/100_config/101_sys_config.js 変更 → 全テスト）。

9. 関連ドキュメント

追加開発案件 (TODO_future.md) — 各 MAS-XX 案件の詳細・進捗（Phase × Layer 軸）
仕訳エンジン (spec_engine.md) — Action A / Action B の詳細
STL 自動作成 (spec_stl_auto.md) — STL 自動生成ロジック
発注ライフサイクル (spec_ord.md) — ORD ステータスの詳細
各 RPA spec: spec_rpa_hc / spec_rpa_capex / spec_rpa_adhoc / spec_rpa_finance
取込系 spec: spec_receipt_import / spec_cc_import / spec_pipeline_ingest / spec_pipeline_plan
ADR: 014 INV ステータス遷移 / 015 STL 消込 vs 天引き / 016 資産計上の決済手段 / 017 33_wrk_bank 集計条件

目的