最終更新: 2026/06/22 18:56
commonid: todo-futuretype: trackingstatus: active
pageauthor: [email protected]audience: human

29. 追加開発案件 (TODO)

本ドキュメントは、システムへの追加エンハンスメント計画をまとめたものです。

🧭 目次

📌 0. 本ファイルの管理規約 (ADR-0145 で整備)

⬆ トップへ戻る

項目規約
所有者[email protected] (代表取締役)。日常の追記・整合更新は sub セッションが PR 経由で行う
役割①追加開発案件 (MAS-XXX 系) の台帳 ②known-unknowns (意図的な未記録) の SSOT (ADR-0048 決定②の 2026-06-12 改訂・移送先は §7.2 等の該当節) ③ドキュメント運用バックログ (DOC-OPS-NN・§7.2)
更新頻度起票は随時 (PR 経由)。§7.2 は四半期レビュー対象 (§7.3)。ID 採番前に既存番号の grep 確認必須
セッション残タスクとの境界セッション間の短命な残タスクは handover のマーカー節 → COVERAGE_GAPS.md (自動生成) が担う。案件として固定化するものだけを本ファイルへ起票する (ADR-0145 案 B 不採用の理由 = 粒度が異なるため一本化しない)
廃止条件案件管理を GitHub Issues 等へ移行した時 (チーム拡大時に判断)。移行時は新 SSOT を ADR で宣言し、known-unknowns の行き先も同 ADR で再指定する

📊 1. 実装状況サマリー（2026-04-27 時点）

⬆ トップへ戻る

ステータス件数前回比 (2026-04-25 → 2026-04-27)
✅ 完了35変動なし (MAS-057 Phase 3 は MVP 完了行へ移行)
🟡 MVP 完了 / Phase 完了（継続拡張）4+1 (MAS-057 Phase 3 完了 PR #379 で Phase 1.5 → Phase 3 全完了に昇格)
📝 仕様書完了47+2 (MAS-066 v1.1 GO PR #387/#389 / MAS-067 v1.2 PR #386/#388/#390)
未着手143+3 (MAS-068 補助金 P3 / MAS-069 HD/M&A P3 / MAS-144 規程ジェネレーター P1 — 全て MAS-334 派生・PR #390 で起票)
バグ修正（別管理）11変動なし

バグ修正・障害対応は C.3 バグ修正トラッキング で管理

📦 完了アーカイブ（26件） / 📝 仕様書完了・次に着手可能（41件）

詳細一覧は §3. 全案件マスタテーブル (統合版 / SSoT) を参照

本ドキュメントでは「案件ごとのステータス」は §3 を唯一の真実として管理。重複更新・上書き事故防止のため、個別案件の一覧は §1 には置かない (2026-04-21 Phase 1 整理で削除)。

未着手の Phase 別内訳

Phaseテーマ件数主な案件
P1バグ修正・基盤構築 + 手入力削減・監査強化 + パフォーマンス改善10MAS-178(エラーハンドリング), MAS-147(請求書OCR↑), MAS-158(給与SaaS↑), MAS-170(法人番号API↑), MAS-139(セルバリデーション↑), MAS-213(監査ログ保護★★★↑), MAS-214(メニューカタログ📝), MAS-231(GAS 最適化パス 1 🆕★★★), MAS-233(パフォーマンス診断ツール🆕) (2026-04-30 Ops 系 12 件を P3 に降格 — 詳細は P3 行参照)
P1.5自動入力パイプライン（即効） + D.8-D.10 抽出最優先13MAS-145(✅), MAS-154(✅), MAS-162(✅), MAS-166(✅), MAS-159(✅ 重複防止), MAS-048(✅ 2026-04-24), MAS-146(CC自動消込), MAS-148(月次締め), MAS-157(写真OCR), MAS-160(未処理アラート), MAS-161(OCR補正), MAS-141(節税・共済効果シミュレーター🆕D), MAS-176(AI ツール投資 ROI 管理🆕D)
P2計画強化・実務要件 + サイドバー SPA 化 + 意思決定対話 UI73+MAS-002(スナップショット), MAS-028(SaaS KPI), MAS-091(T/B), MAS-121-MAS-124, MAS-215(✅ 2026-04-21), MAS-216(✅ 2026-04-24), MAS-217(サイドバー統合📝🆕), MAS-219(ADR-0009 テナント抽象化), MAS-221(TODO自動生成🆕), MAS-040(法人税会計年度ベース化🆕), MAS-173(複合機スキャン連携🆕), MAS-174(小口現金サイドバーUI🆕), MAS-232(サイドバー SPA 化・Vite+React 🆕), MAS-251〜MAS-253(データ主権: 監査/HP公開/契約書🆕), MAS-043(ハイブリッド2トラック採算 RICE/VALUE/SEED🆕), MAS-049(✅ 2026-04-24), MAS-142(workType DDL🆕D), MAS-143(フリーランス新法🆕D), MAS-235(補助金管理台帳🆕D), MAS-056(一人社長の意思決定対話 UI・Web App + Chat🆕D), MAS-057(🟡 Phase 3 + Step 6 + シート保存 + Step 7 多年 P/L · B/S · CF + 4 アプローチ比較 + Y0 着地見込み 完了 2026-05-01 PR #379/#394/#454/#459), MAS-058(必要年商シミュレーター仕様書完了 2026-04-25 / Step 5 UI 待ち), MAS-059(一人法人 成長計画ワークスペース🆕 2026-04-25), MAS-060(組織構成シミュレーター🆕 2026-04-25), MAS-061(キャッシュ実効税率トラッキング🆕 2026-04-25), MAS-062(PSF プロフィタビリティ指標拡張🆕 2026-04-26), MAS-063(P/L 営業外損益指標拡張🆕 2026-04-26), MAS-067(マルチイヤー計画 Phase A〜E 完了・シナリオ保存 + 即時反映 + UX 統一 v1.8 2026-04-30 PR #418/#423/#425/#426/#440/#442/#445/#448/#451/#454), MAS-144(役員社宅・出張日当・退職金 規程ジェネレーター🆕 2026-04-27 MAS-334 派生・MAS-067 並列起票), MAS-071(✅ 完了 v1.1 2026-05-01 PR #457/#459・4 軸 + 労働強度 + シナリオ保存 + UX 改善 + Step 7 連携), MAS-072(企業価値スコアボード・MAS-057 cockpit 拡張・3 評価手法統合🆕 2026-04-30), MAS-355(✅ 完了 2026-05-03 PR #489 · 資本効率&キャピタル・アロケーション最適化ダッシュボード · 3 バケツ + ROE + Rule of 40 + CapitalAllocationPanel.tsx), MAS-358(Cockpit 左サイドバーナビ + GAS メニュー廃止🆕 2026-05-03)
P2.5自動入力パイプライン（拡張）+ SaaS連携 + D.8-D.10 補助機能15MAS-147(請求書OCR), MAS-151(予算自動生成), MAS-180(OCR強化), MAS-046(投資カタログマスタ🆕D), MAS-047(RICE スコアリング🆕D), MAS-050(ベンチマーク比較🆕D), MAS-051(PSF KPI ダッシュボード🆕D)
P3予測高度化・GCP移行基盤 + Web App 中間段階 + Ops/組織・採用・セキュリティ整備 (2026-04-30 Ops 系を P1 から降格)42MAS-017(WACC), MAS-038(バリュエーション), MAS-236-MAS-240(GCP移行), MAS-245(GAS Web App 独立化・MAS-238 先行切出🆕), MAS-041(繰越欠損金・税制優遇反映🆕), MAS-220(フリート管理デプロイ調査🆕), MAS-246〜MAS-250(データ主権: TEE/DP/接続/Attestation/匿名化🆕), MAS-042(🟡 MVP 完了 2026-04-23), MAS-044(✅ 2026-04-23), MAS-012(✅ 2026-04-23), MAS-045(What-if 結果の予算転記🆕), MAS-052(軽量版 Stage-Gate🆕D), MAS-054(Monte Carlo🆕D), MAS-055(SaaS カタログマスタ🆕), MAS-066(配当ミックス最適化・仕様書完了 v1.1 GO 2026-04-27 PR #389), MAS-068(補助金マッチング・MAS-334 派生・P1→P3 降格 2026-04-27), MAS-069(HD化・M&A エグジットシミュレーター・MAS-334 派生・P2→P3 2026-04-27), MAS-205(MFA義務化 ✅ 2026-04-21・P1→P3 2026-04-30), MAS-206(外部共有制限 ✅・P1→P3 2026-04-30), MAS-218(タイムトラッキング導入・R&D 税制・P1→P3 2026-04-30), MAS-222(開発端末セキュリティ・P1→P3 2026-04-30), MAS-223〜MAS-230(Jr オンボーディング + CI + branch protection + レビュー運用 + 業務委託契約 + Jr 特権分離 + 採用要件・P1→P3 2026-04-30), MAS-254(プライバシーマーク取得・P1→P3 2026-04-30)
P4運用改善・SaaS運用基盤12MAS-182(異常値検知), MAS-207-MAS-211(GCPセキュリティ), MAS-241-MAS-242(管理者/課金)

🗂️ 未着手のレイヤー別内訳

GAS Modular Monolith のレイヤー別グルーピング。Phase 別内訳（優先度軸）と直交する第 3 の軸として、担当エンジニアの領域分担・レイヤー間の実装負荷バランス可視化 に利用する（MAS-230 Jr 採用時の担当領域明確化の布石）。

レイヤー別サマリー

レイヤー対応ディレクトリ件数主な案件
🎨 UImas/300_ui/ mas/templates/15MAS-232, MAS-245, MAS-174, MAS-014/MAS-015/MAS-021/MAS-023, MAS-184/MAS-185, MAS-130/MAS-132, MAS-358(🆕 2026-05-03 / Cockpit 左サイドバーナビ + GAS メニュー廃止)
🧠 Domainmas/400_domain/51MAS-002/MAS-004/MAS-005/MAS-007/MAS-009/MAS-017, MAS-043/MAS-054, MAS-058(🆕 2026-04-25), MAS-060(🆕 2026-04-25 / 組織ミックス最適化), MAS-061(🆕 2026-04-25 / Cash ETR + 合法節税サジェスト), MAS-062(🆕 2026-04-26 / PSF Rule of Three), MAS-063(🆕 2026-04-26 / 営業外損益 + ICR), MAS-066(🆕 2026-04-27 / 配当ミックス・449), MAS-067(🆕 2026-04-27 / 5 軸マルチイヤー・451・MAS-334 反映 v1.2), MAS-068(🆕 2026-04-27 / 補助金マッチング P3), MAS-069(🆕 2026-04-27 / HD/M&A レーマン方式 P3), MAS-091/MAS-100/MAS-101/MAS-126〜MAS-129, MAS-141, MAS-144(🆕 2026-04-27 / 規程ジェネレーター・452), MAS-071(✅ v1.1 2026-05-01 / 稼働率連動型役員報酬シミュレーター・454・4 軸 + 労働強度 + シナリオ保存 + Step 7 連携), MAS-072(🆕 2026-04-30 / 企業価値スコアボード・455・MAS-057 cockpit 拡張), MAS-182/MAS-189/MAS-190/MAS-191
（MAS-012/MAS-042/MAS-048/MAS-049 は実装完了で除外・2026-04-27 更新）
💾 Datamas/200_data/ 101_sys_config.js DDL23MAS-045/MAS-046/MAS-055, MAS-119/MAS-121/MAS-124/MAS-135/MAS-140/MAS-142 (workType DDL), MAS-193/MAS-197/MAS-202/MAS-212/MAS-219/MAS-231/MAS-233/MAS-235, MAS-240
（MAS-044 は実装完了で除外）
🔧 Inframas/000_infra/ mas/100_config/ mas/appsscript.json webapp_client/vite.config.ts12MAS-177, MAS-236〜MAS-239/MAS-241/MAS-242/MAS-244, MAS-246, MAS-220, MAS-257, MAS-359(🆕 2026-05-03 / フロントエンドバンドル分割・MAS-356/357/358 前提)
📥 Importmas/500_import/2MAS-173, MAS-174
📊 Reportmas/600_report/5MAS-113, MAS-115, MAS-123, MAS-133, MAS-040
🛠️ Opsmas/800_ops/ / 運用・セキュリティ・組織27MAS-187/MAS-194/MAS-200/MAS-207〜MAS-211/MAS-218/MAS-221〜MAS-230, MAS-248/MAS-251〜MAS-254, MAS-243, MAS-255/MAS-256/MAS-258/MAS-260
🧪 Testmas/900_test/1MAS-224
🌐 層横断複数層に跨る5MAS-143, MAS-047, MAS-225, MAS-176, MAS-059(🆕 2026-04-25 / Domain orchestrator + UI ワークスペース)
🗑️ 廃止候補—4MAS-180/MAS-181/MAS-183/MAS-186（取消線表記・別案件に統合済）

合計: 145 件（§1 未着手 145 件のうち重複行除外・MAS-059〜MAS-063 + MAS-066/MAS-067/MAS-068/MAS-069 + MAS-144 + MAS-358 + MAS-359 新規起票を反映・2026-05-08 更新）

主な気づき

  • Domain 層が圧倒的に多い（47 件、34%）: 会計ロジック・シミュレーション・ワークフロー等、ビジネスロジックの拡張要求が集中。mas/400_domain/ に新規ファイルが増え続ける構造
  • Ops 層（27 件、19%）が予想より大きい: セキュリティ・組織整備・DevOps 系の非機能案件が蓄積。Jr 採用 D-180 関連（MAS-223/MAS-226/MAS-227/MAS-229/MAS-230）が集中
  • Data 層（24 件）は DDL / マスタ整備が中心: スキーマ定義の拡張と外部データ取込前処理
  • UI / Report / Import が薄い（各 2-14 件）: 既存サイドバー / 財務諸表 / OCR パイプラインが成熟し、漸進的改善フェーズ
  • 層横断 4 件は仕様書分割候補: MAS-047 / MAS-176 / MAS-225 / MAS-143 はレイヤーを跨ぐため、Phase 実装時に Sub-ID 分割を検討

🎨 UI 層（14 件）

  • MAS-125 発注ステータス遷移ワークフローの標準化
  • MAS-130 フィルタービュープリセット配布（行積み上がり対策 A）
  • MAS-132 月次行グルーピングの自動生成（行積み上がり対策 D）
  • MAS-014 プロジェクト別予実ダッシュボード
  • MAS-015 リソース稼働率のヒートマップ可視化
  • MAS-021 財務諸表の PDF/Excel エクスポート
  • MAS-023 月次経営コメント入力機能
  • MAS-184 コラボレーション・通知（軽量版）
  • MAS-185 コンテキスト付きチャット連携
  • MAS-232 サイドバー UI の SPA 化（Vite + React）
  • MAS-245 GAS Web App 独立化（MAS-238 先行切出）
  • MAS-228 業務委託契約書テンプレ + 社労士連携窓口整備
  • MAS-249 Attestation 検証の顧客向け提供機構
  • MAS-172 クレカ MATCHED 自動承認化の検討（HITL 緩和案）

🧠 Domain 層（47 件）

会計ロジック: MAS-091 月次 T/B 自動生成 / MAS-100 請求書発行 / MAS-101 債権エイジング / MAS-104 支払依頼ワークフロー / MAS-105 工数入力 PJ 原価連携 / MAS-114 インボイス要件チェック / MAS-126 発注→INV 自動展開 / MAS-127 発注書 PDF / MAS-128 発注承認ワークフロー / MAS-129 複数見積比較 / MAS-022 予実差異ドリルダウン / MAS-026 TDABC / MAS-039 ABC 分析 / MAS-041 繰越欠損金・税制優遇計算

FP&A・シミュレーション: MAS-256 予算スナップショット / MAS-258 ローリングフォーキャスト / MAS-259 動的シナリオプランニング UI（MAS-056 に吸収予定）/ MAS-007 ドライバーベース計画 / MAS-009 資金ショート警告 / MAS-012 目標逆算型人員計画 / MAS-017 資金調達シミュレーション / MAS-019 予測分析 + 外部シグナル / MAS-043 ハイブリッド 2 トラック採算 / MAS-048 採用 TCO & BEP / MAS-049 賃上げ促進税制 / MAS-051 PSF KPI / MAS-054 Monte Carlo / MAS-027 M365 監査ログ→作業時間推定 / MAS-141 節税・共済効果シミュレーター

プロダクト・成長: MAS-028 ARR/MRR / MAS-029 LTV/CAC / MAS-030 コホート分析 / MAS-031 Compound Growth / MAS-032 プロダクト別 P/L / MAS-033 Rule of 40

R&D: MAS-034 R&D 費用分類 / MAS-035 IP ポートフォリオ / MAS-036 R&D ROI / MAS-037 ソフトウェア資産減価償却 / MAS-038 研究開発税制

AI 活用: MAS-182 異常値検知 / MAS-189 HRIS/ATS 連携 / MAS-190 CRM 連携 / MAS-191 NLP ナラティブ生成 / MAS-203 AI プロンプトライブラリ版管理

データ主権: MAS-247 差分プライバシー / MAS-250 匿名化データパイプライン

💾 Data 層（24 件）

マスタ・DDL 拡張: MAS-119 人件費予算の保険料率マスタ化 / MAS-121 CAPEX 償却・借入条件マスタ化 / MAS-124 発注残高エイジング / MAS-135 決済手段マスタ新設 / MAS-140 MAS-120 後追い対応 / MAS-142 workType 列 DDL 追加

FP&A マスタ: MAS-042 投資ハードルレートマスタ / MAS-044 HC テンプレートマスタ / MAS-045 What-if → 予算転記 / MAS-046 投資カタログマスタ / MAS-055 SaaS カタログマスタ / MAS-050 投資回収ベンチマーク / MAS-052 軽量版 Stage-Gate

基盤改善: MAS-193 DTO バリデーション層 / MAS-197 dev/prod スキーマ差分検出 / MAS-202 DDL 自動マイグレーション / MAS-212 論理削除理由記録 / MAS-219 bizlp 固有ハードコード洗い出し / MAS-231 GAS 最適化パス 1 / MAS-233 パフォーマンス診断ツール / MAS-235 補助金管理台帳 / MAS-131 完了行グレーアウト

セキュリティ: MAS-188 エンタープライズセキュリティ要件 / MAS-240 データ移行（→ BigQuery）

🔧 Infra 層（11 件）

  • MAS-177 多年度データ基盤
  • MAS-220 フリート管理型デプロイ基盤調査
  • MAS-236 認証・ユーザー管理基盤
  • MAS-237 マルチテナントデータ分離
  • MAS-238 Web UI / フロントエンド
  • MAS-239 API 層（REST / GraphQL）
  • MAS-241 管理者用ダッシュボード
  • MAS-242 課金・サブスクリプション管理
  • MAS-244 Clean Architecture + フィーチャー分割
  • MAS-246 TEE 基盤構築
  • MAS-257 顧客環境への一斉パッチ展開機構

📥 Import 層（2 件）

  • MAS-173 複合機スキャン→Drive 自動投入→OCR 連携
  • MAS-174 小口現金・事後発生経費のサイドバー即時登録 UI

📊 Report 層（5 件）

  • MAS-113 株主資本等変動計算書の科目マスタ動的参照化
  • MAS-115 財務諸表タブ統合（プルダウン切替方式）
  • MAS-123 発注残高・予算執行ダッシュボード
  • MAS-133 年度跨ぎアーカイブ機構
  • MAS-040 法人税計算の会計年度ベース化

🛠️ Ops 層（27 件）

セキュリティ・GCP 移行: MAS-187 RBAC / MAS-200 個人情報保護 / MAS-207〜MAS-211 GCP セキュリティ系（IAM / VPC-SC / CMEK / SCC / SOC2 & ISO27001）/ MAS-222 開発端末セキュリティ / MAS-248 TEE 接続基盤 / MAS-251 第三者監査連携 / MAS-252 HP 公開戦略 / MAS-253 契約書テンプレ / MAS-254 P マーク取得

Jr 採用・組織: MAS-223 Jr オンボーディング / MAS-226 Good-first-issue + Labels / MAS-227 コードレビュー運用 / MAS-229 Jr 特権分離 / MAS-230 採用要件定義

DevOps・運用: MAS-194 GAS 実行時間最適化 / MAS-204 仕様書整合性チェック / MAS-218 タイムトラッキング + R&D 税制 / MAS-221 TODO 自動生成 / MAS-243 CI/CD パイプライン

事業・商用化: MAS-255 GAS テンプレート販売モデル / MAS-256 顧客別 GAS インスタンス管理 / MAS-258 ライセンス認証 / MAS-260 初期セットアップウィザード

🧪 Test 層（1 件）

  • MAS-224 GitHub Actions CI パイプライン構築（lint / テスト / clasp 構文チェック）

🌐 層横断（4 件）

いずれも Domain + Data + Report / Ops を跨ぐため、実装時に Sub-ID 分割（例: F-47a / F-47b）を検討:

  • MAS-143 フリーランス新法対応管理機能（Domain + Data + Ops）
  • MAS-047 RICE スコアリング機能（Domain + Data + Report）
  • MAS-225 Branch protection + CODEOWNERS（Domain + Data + Infra + Config）
  • MAS-176 開発者向け AI ツール投資 ROI 管理（Domain + Data + Report）

🗑️ 廃止候補（4 件）

取消線表記の案件。別案件に機能統合済のため整理タイミングで物理削除する:

  • MAS-180 AI-OCR 連携による証憑自動起票（MAS-147 系列に統合）
  • MAS-181 銀行 API 連携（MAS-158 系列に統合）
  • MAS-183 月次決算チェックリスト自動化（MAS-148 系列に統合）
  • MAS-186 経費精算の Slack/Chatwork 連携（MAS-174 系列に統合）

🔥 優先着手バックログ（未完了案件・推奨順 Top 14）

戦略テーマ（2026-04-20 更新）: Phase 1 基盤構築完了に伴い、戦略軸を以下に再編。

  1. 「月次決算の完全自動化（手入力ゼロ）」
  2. 「手入力削減 + 監査強化」 🆕 — Gemini Pro 戦略レビューに基づき追加
  3. 「事業成長の可視化（攻めの FP&A）」

以下の Top 15 は 未完了案件 のみで構成（MAS-145 / MAS-154 / MAS-162 / MAS-166 / MAS-201 等の完了案件は完了アーカイブ参照）。「自動化によるミス排除」と「物理的な入力制限」を前段に配置し、監査コストを最小化する構成。

順案件ID案件名所要時間変更①選定理由 ②依存監査時の主張ポイント状況
1MAS-139セル単位データバリデーション4-6hBump①ゴミデータ混入を入口で防ぎ後段集計エラー根絶 ②独立実装可「入力時点でビジネスルールに反するデータを物理的に遮断」📝
2MAS-146カード明細の高信頼度自動消込2h維持①目視確認 95% 削減 ②MAS-145 の実装流用「辞書ベース自動消込により人為的判断ミスと操作介入を排除」📝
3MAS-157写真(JPEG/PNG)対応の証憑OCR2-3h維持①現場入力負荷を下げつつ証憑回収率を 100% へ ②既存 OCR 基盤「全経費がオリジナル証憑画像から直接生成され改竄余地なし」📝
4MAS-147請求書PDF→INV自動起票4-6hBump①AP（買掛）入力の最大ボトルネック解消 ②MAS-157 OCR 基盤を拡張「請求書PDFから直接データ抽出・転記ミスなし」📝
5MAS-158給与計算SaaSデータ取込3-4hBump①人件費という最大支出の転記ミス根絶 ②独立実装可「給与データはSaaSから直接同期・手入力リスクなし」📝
6MAS-148ワンクリック月次締め1-2h維持①締め作業の属人化排除・手順漏れ防止 ②Action A/B/マート更新「標準化された締めプロセスにより処理の抜け漏れ・順序ミスを防止」📝
7MAS-160月次締め前未処理アラート・サマリーUI1-2h昇格①「締め忘れ」をシステムが能動検知 ②MAS-148 の実行前フック「未処理事項ゼロをシステムが検証してから締めを実行」📝
8MAS-213監査ログシート(98_audit_log)の編集禁止保護1-2hBump①MAS-179 監査証跡の信頼性を物理的に担保 ②MAS-179 実装済「監査ログは WORM（書込後消去不能）な保護状態で管理」未着手
9MAS-152証憑ファイル名の電帳法リネーム1-2h維持①税務調査時の検索性を自動担保 ②MAS-154 略称（実装済）「全証憑が電帳法要件に基づき自動整理・即座に検索照合可能」📝
10MAS-153証憑リンク再構築1h維持①共有時のリンク切れ防止・監査人の閲覧性確保 ②MAS-152 とセット「会計士・監査人への共有後も全仕訳から証憑へのリンク維持」📝
11MAS-170法人番号自動取得（国税庁 Web-API）2-3hBump①T番号誤入力防止 → 仕入税額控除の否認リスク低減 ②独立実装可「取引先データは国税庁公表情報と API 連携・正確性担保」📝
12MAS-164銀行摘要名の自動学習2h昇格①自動化率を継続的に向上・手作業を逓減 ②MAS-145 実装済「過去の確定実績に基づき消込ロジックが自己学習的に強化」未着手
13MAS-16733タブSTL重複行の検出・削除ツール1-2h昇格①Action A 多重実行等の事故を事後検知・修復 ②独立実装可「データ不整合を定期スキャン・異常検知時に即修復可能」未着手
14MAS-008資金繰り予測 (Cash Runway)3-4h維持①「攻めの FP&A」象徴機能 ②既存マート基盤「実績と予測が直結・将来の資金ショートリスクを早期主張可能」📝

Top 15 から外した案件: MAS-028（ARR/MRR）/ MAS-151（実績ベース予算）/ MAS-091（月次T/B）/ MAS-156（運用ナビ）— いずれも「機能拡張」色が強く監査強化に直接寄与しない。次点バックログとして個別タイミングで実施。

🛡️ 横断テーマ：手入力削減 + 監査強化（Reduction of Manual Entry & Audit Integrity）

本テーマは 既存 Phase 構造を補完する横軸。Phase 1.5 の中で本テーマ案件を優先実装することで、3〜5 名規模でも「1 人経理」で回せる強固な基盤を完成させる。

分類狙い該当案件
① 自動取込 (Auto-Import)転記ミスを物理的に排除し、証憑との直結性を確保MAS-145✅ / MAS-146 / MAS-147 / MAS-157 / MAS-158 / MAS-164
② 事前防御 (Pre-emptive)誤ったデータがシステムに入るのを入口でブロックMAS-139 / MAS-159 / MAS-170 / MAS-114
③ 事後監査 (Post-audit)処理の正しさを証明し、異常を早期に発見MAS-179✅ / MAS-213 / MAS-160 / MAS-167 / MAS-122

📅 実装ロードマップ案（3 パターン）

パターン想定期間含む案件想定リスク
保守的4 週間Top 1〜6（基盤ガード + 主要自動化）自動化の恩恵は受けるが、MAS-213 等が後回しで統制面に不安が残る
標準（推奨）6 週間Top 1〜12（自動化 + 監査基盤）手入力の大部分が消え、監査人に「システム統制」を自信を持って説明可能
積極的10 週間全候補 + MAS-164 / MAS-167 等の運用ツール開発リソースを使い切り、Phase 3 着手が遅延。運用キャパ圧迫

PM 推奨: 標準パターン（Top 1〜12 / 6 週間） で確実に完遂。MAS-139 / MAS-170 は実装着手前に仕様書作成が必要なため、スケジュール上は最初の 1 週間を仕様書スプリントに充てる前提。

今後追加予定の改善案件

IDTypeLayer案件名所要時間目安理由前提
MAS-163Story—銀行摘要名の名寄せマスタ独立化1時間現在 12_mst_partner の「銀行摘要名」列で管理しているカナ→取引先の対応表を、独立した名寄せマスタシート（例: 17_mst_bank_alias）に分離。1取引先に複数のカナ表記がある場合（振込名義変更、個人名/法人名の使い分け等）に対応MAS-154
MAS-164Story📥 Import銀行摘要名の自動学習2時間銀行CSV消込で MATCHED/消込済 になった行の「銀行摘要カナ ↔ 取引先名」の対応を名寄せマスタに自動記録。次回以降のマッチングで自動参照。初回は手動入力が必要だが、2回目以降は自動MAS-145, MAS-163
MAS-165Story—未消込明細の能動的確認通知1-2時間銀行CSVマッチング後にUNMATCHED/SUGGEST行が残っている場合、対象明細を抽出してユーザーにダイアログ or メール/Slack通知で確認を促す。月次締め前の「未消込チェックリスト」として機能。放置されている未消込明細の見落とし防止MAS-145
MAS-168Story—立替精算の複数立替者対応2-3時間現在MAS-166はCFG_REIMBURSEMENT_PAYEEパラメータ（単一値）で振込先名を付加しているが、従業員増加時に複数人の立替精算に対応できない。対策: ①22_bud_headcountの従業員マスタから立替者を自動判定（INVの組織名・摘要から従業員を特定）。②決済口座を 立替精算_従業員名 で従業員別に生成。③銀行CSVマッチングのpayeeグルーピングは既にpayee単位で動作するため、STL生成側の対応のみで複数人に拡張可能。④CFG_REIMBURSEMENT_PAYEEは廃止しINV起票者→従業員マスタ照合に移行MAS-166
MAS-161Story🎨 UIOCR結果の手動補正アシスト（UxAssist拡張）1-2時間MAS-157（写真OCR）で読み取った金額・取引先名を手動修正した際に、消費税額等を自動再計算する handleUxAssist の拡張。→ 開発仕様書MAS-157
MAS-340Story🎨 UIF-57 / F-67 シナリオ間 diff 表示（差分ハイライト）2-3時間PR #454 で F-57 / F-67 のシナリオ・プリセットがシート保存化された後の 比較 UX 拡張。2 つのシナリオ (or プリセット) を選択 → フィールド単位で差分ハイライト (色付け or sub-table 表示) して「何が変わったか」を即座に把握可能に。前提: 同一 SPA 内に複数シナリオがロード済 (Phase E v2 で values prefetch 済)。MAS-067 マルチイヤーでも同パターン適用可。実装未定。MAS-057 v2.3 / MAS-067 v1.8
MAS-341Story🎨 UIF-57 / F-67 シナリオエクスポート/インポート（JSON ダウンロード/アップロード）1-2時間シート保存化されたシナリオ・プリセットを JSON ファイルとしてダウンロード/アップロード可能に。用途: (a) 他法人インスタンスへの移植、(b) 業種別テンプレ配布 (将来の SaaS 化で「コンサル業向け前提条件パック」等)、(c) バックアップ/レストア用途。payloadJSON 列をそのまま activate するシンプル実装で対応可能。実装未定。MAS-057 v2.3 / MAS-067 v1.8
MAS-342Story💾 DataF-57 / F-67 シナリオのバージョニング（親 ID + 改版番号）2-3時間シナリオ・プリセットの「ある時点でのスナップショット」を保存し、後で復元可能に。実装方針: F57_AS / F57_SC / F67_SCN スキーマに parentId (親シナリオ ID・null = ルート) + version (改版番号・1 始まり) を追加 → 保存時に親 ID を記録し履歴ツリー化。復元 UX は親子表示 (タイムライン or ツリービュー)。論理削除との違い: 論理削除は「削除 vs 復元」の 2 状態のみ・バージョニングは「過去の任意時点」を選んで復元可能。MAS-002 期末スナップショット とラップ可能性あり (本 MAS-342 はシナリオ単位・MAS-002 は財務諸表全体)。実装未定。MAS-057 v2.3 / MAS-067 v1.8
MAS-343Story🎨 UIF-57 プリセット読込時の variables 系のみ復元オプション1時間現状の F-57 AssumptionsBar 読込ロジックは「前提条件 16 項目のみ上書き (Variables 維持)」固定だが、「Variables のみ復元」or「両方上書き」を選択可能にするオプション追加。シナリオ間で「同じ Variables・異なる前提条件」を試したいケースで有用 (現状は ScenarioBar 読込で対応可能だが UX が二段階)。チェックボックス or ラジオボタン 1 個追加で実装可能。実装未定。MAS-057 v2.3

2026-04-20 更新: MAS-159 / MAS-164 / MAS-167 / MAS-160 は戦略レビューに伴い 🔥 優先着手バックログ Top 15 へ昇格済（横断テーマ「手入力削減 + 監査強化」枠）。

2026-04-30 追加: F-57 / F-67 のシナリオ・プリセットがシート保存化された (PR #454) 後の拡張候補 4 件 (シナリオ間 diff / エクスポート・インポート / バージョニング / variables のみ復元) を追記。優先度高まり次第 MAS-XXX 採番予定。

2026-05-01 追加 (MAS-071 v1.0 実装完了 PR #457 後の発展候補・全件実装未定):

  • MAS-344 アプローチ E (退職金考慮): 月額抑制で退職金枠縮小トレードオフを統合評価 (現状 4 アプローチに 5 つ目を追加)
  • MAS-345 配偶者役員化対応 (v2): 夫婦法人化時の並列表示・MAS-066 配当連携と整合 (MAS-066 とラップ可能性あり)
  • MAS-346 5 軸モデル拡張: 経営戦略 (Strategy) を独立軸として分離 (現状 4 軸: デリバリー / 営業 / 投資 / 管理 → 5 軸)
  • MAS-347 役員社宅併用での実質可処分計算: effectiveCompensation = candidate + housingDeductibleEquivalent (MAS-057 Step 6.5 の社宅控除と連動・MAS-057 Step 6.5 とラップ可能性あり)
  • MAS-348 多通貨対応: V (市場年収) を JPY 以外で設定可能に (MAS-064 連動・out of scope)
  • MAS-349 税務調査防衛資料の自動生成: ロールバリュー積算根拠の議事録テンプレ (MAS-144 規程ジェネレーターとラップ可能性あり)

2026-05-01 追加 (MAS-057 Step 7 + MAS-071 v1.1 実装完了 PR #459 後の発展候補・全件実装未定):

  • MAS-350 B/S 73 タブから共済積立金・配当決議の取得: 現状 getSoloCEOY0Forecast() で '—' 表示 → 73_bs_plan の他列を解析して取り込み (MAS-177 多年度データ基盤とラップ可能性あり)
  • MAS-351 64 タブからの役員報酬 / 法人社保 / 共済 / 減価償却の個別取得: 現状 Y0 で '—' 表示 → 64_pl_ytd_plan の費目別分解列を取り込み (MAS-177 とラップ可能性あり)
  • MAS-352 CF 内訳 (営業/投資/財務) の Y0 取得: 現状 '—' 表示 → 64 タブまたは別 CF 計画タブから取得 (MAS-177 とラップ可能性あり)
  • MAS-344 アプローチ E 退職金考慮型の追加 ⚠️ MAS-071 v1.0 後発展と重複: 月額抑制で退職金枠縮小トレードオフ反映 (MAS-071 v1.1 後続候補と統合判断・上記 MAS-344 と同一案件)
  • MAS-353 アプローチ別 5 年累積純資産推移グラフ: ApproachComparisonPanel の縦軸を 5 年累積に拡張・パネル形式 or 別タブ
  • MAS-354 マルチイヤー版 cockpit (?view=multiyear_spa) との統合シナリオ ID 共有: F-67 ScenarioPanel と F-57 cockpit のシナリオ ID 名前空間統合 (現状は別系統・MAS-067 既存実装とラップ可能性あり)

2026-05-15 追加 (パイプライン Observability):

  • MAS-365 Gate1↔Gate4 カバレッジ突き合わせスクリプト: Langfuse API から直近の Gate1 questions と Gate4 採点（10項目×スコア）のペアを取得し、「Gate1 が聞かなかったのに Gate4 で減点（≤3点）された項目」を集計して GitHub Issue を自動起票する仕組み。Gate1 の判定基準漏れを人間が気づく前に検知できる。前提条件: golden.jsonl 整備完了（D+60: 2026-07-14）以降に有効化。発展として Gate2 の見逃し検知・Gate3 モデル間乖離検知にも横展開予定。実装規模: 4〜6 時間。TODO_future.md とパイプライン系タスクの混在は別途ファイル分割で対応予定。

2026-05-15 追加 (税効果会計対応):

  • MAS-364 11_mst_account に is_tax_effect 列追加（税効果科目フラグ）: 税効果会計の開示対応として、繰延税金資産・負債の算定対象科目を管理する仕組みがない。現状は目視確認で、過去3期で帳票誤記2件・監査指摘1件が発生。11_mst_account に boolean 型の is_tax_effect 列を追加し DDL（setupAllSchemas）に組み込む。既存行デフォルト FALSE。科目名キーワードによる自動初期値設定は行わない（ADR-0011 分類禁止原則・監査リスク回避）。改修対象: mas/100_config/101_sys_config.js（DDL 追加）・mas/400_domain/40x_rpa_*.js（参照追加）・mas/600_report/6x_datamart_*.js（参照追加）。実装規模: 4〜6 時間。次期決算 2026-06 までに対応推奨。ADR 起案済み（PR #555 クローズ・旧命名形式のため）、実装時に正式 ADR 番号で再起案すること。

2026-05-08 追加 (健全性診断・MAS-008 延長):

  • MAS-363 財務健全性信号機判定（5 段階 U字型非対称リスクモデル）: 仕様 spec_bs.md §9 で確定済み。一人法人 IT/コンサル業向けに 5 指標 (現預金比率は対月商倍率・自己資本比率・流動比率・固定比率・ランウェイ) を 5 段階信号機 (🔴 危険 / 🟠 警告 / 🟡 注意 / 🟢 健全 / 🔵 過剰) で判定。独自要素: (a) 固定比率 <5% を「過少投資（PC・作業環境への投資忌避）」として🔵 過剰判定、(b) Tax-Adjusted Cash（実質現預金）で納税サイクル誤検知防止、(c) MVS（Minimum Viable Salary）監査で役員報酬下げによるランウェイ偽装検出、(d) 過剰検知時のメッセージは「称賛 → 機会損失指摘 → 具体提案」3 段構成。MAS-008 (Cash Runway) の単一指標判定からの拡張で、93_kpi_dashboard または専用タブに月次の総合健全性を表示。実装規模: 6-8 時間（実装 + テスト + UI 統合）・対象: mas/600_report/613_health_diagnostic.js (新規)、mas/600_report/609_datamart_kpi.js (信号機列追加)、mas/100_config/101_sys_config.js (03_sys_params 17 パラメータ追加)。実装未定。

2026-05-07 追加 (cockpit_spa ナビ拡張・実装未定):

  • MAS-360 cockpit_spa sticky ナビの復活（GAS iframe 対応後）: PR #499 で追加した左サイドバーナビは現状 position: fixed 非適用（GAS の ?embedded=1 iframe 内では position: sticky/fixed が正しく動作しない制約のため）。GAS HtmlService iframe 制約が解消された場合（MAS-357 Firebase Hosting 移行後等）に sticky 化して UX 向上。実装規模: 小 (CSS 数行)・MAS-357 完了後の後続タスク

2026-05-03 追加 (コックピット UX 統一):

  • MAS-358 Cockpit 折りたたみ式左サイドバーナビゲーション（GAS スプレッドシートメニュー廃止）: コックピット Web App 左端に折りたたみ可能なナビゲーションパネルを追加し、Google Sheets ネイティブメニュー（🚀 BizLP / 💾 バックアップ / 📋 サイドバー: ... 全 11 カテゴリ）を廃止する UX 統一案件。menuDefinition: Constants.MENU_DEFINITION は 302_spa_bridge.js:196 で既に getInitialStateForSpa の戻り値に含まれており GAS 側変更不要。フロントエンドのみで Phase 1 完結。Phase 1: CockpitNavSidebar.tsx 新規作成 + CockpitApp.tsx / MultiyearApp.tsx レイアウト変更（2 カラム flex） + cockpit.css 追記。Phase 2: 101_sys_config.js の createMenu 呼び出し削除でスプレッドシートメニュー廃止。MAS-357 Firebase Hosting 移行の前提条件 (スプレッドシートメニューは Firebase 環境で機能しない)。実装規模: 半日〜1 日 (Phase 1)・実装未定

2026-05-01 追加 (フロントエンド近代化・実装未定):

  • MAS-356 Vercel v0 + Tremor 採用 (UI コンポーネント生成効率化): cockpit パネル開発の高速化目的。Vercel v0 (v0.app) でプロンプト → React + Tailwind + shadcn/ui 産物生成・Tremor (@tremor/react) でダッシュボード専用コンポーネント (KPI カード / スピードメーター / ゲージ) を統一。MAS-355 Rule of 40 スピードメーター実装での試験採用候補。bizlp 既存 React + Vite スタックと完全互換でロックインなし。Tremor は v3 で Tailwind v4 対応・shadcn 統合化進行中でフロントエンド技術スタックの近代化の起点。実装規模: ~1 週間 (依存追加 + 既存パネル 1-2 件で試験)・実装未定
  • MAS-357 フロントエンド GCP 移行 (GAS HtmlService → Firebase Hosting): ADR-0009 (活動領域分離戦略) Phase 4-5 SaaS 化への基盤。現状: GAS Web App URL (script.google.com/exec) で HtmlService 経由 SPA 配信 → カスタムドメイン不可・Service Worker / PWA 不可・?embedded=1 制約・CDN 制御弱。移行後: Firebase Hosting + カスタムドメイン (例: cockpit.bizlp.co.jp) + CDN + HTTPS 自動 + PWA 対応 + WebSocket 可。段階移行 Phase 1-4: (Phase 1) GAS 並列稼働で A/B 検証 / (Phase 2) フロント完全 Firebase 移行 + バック GAS 維持 + CORS / (Phase 3) バックも Cloud Run / Cloud Functions / (Phase 4) Sheets API 直叩き化 or Firestore 検討。認証フロー再設計必要 (Session.getActiveUser() → Firebase Auth or IAP)。ADR-0008 (Vertex AI 集約) と整合で既に GCP 寄り方針。MAS-356 と独立採用可能 (フロントツール採用と移行は別問題)。実装規模: 2-4 週間 (Phase 1-2)・実装未定 ⚠️ Epic 級規模・サブ案件への分解検討余地

2026-06-02 追加 (ADR-0107 実装ハンドオフ・ADR 情報資産化 / [cross-workspace] main 専属): ADR-0107 (Proposed) で決定した「単一抽出器 → adr-index.json (SSoT) → 4 出力」の実装タスク。scripts/**・.github/workflows/** は workspace_rules マトリクス上 main 専属のため sub では実装不可。前例は prompt-catalog.mjs (ADR-0106) で、自動生成・--check 型をそのまま転用する。総工数 ~9h (AI 支援) / ~14h (手作業換算)。

  • MAS-366 メタデータバックフィル (前提作業): B_complete_adr_metadata.mjs で Scope 欠落 48 本・Status/Mode 欠落 18 本を補完 (ADR-0031 メタデータ後付け範疇)。索引・絞り込みの信頼性の前提。実装規模: ~2h。他タスクの先行条件。前提: ADR-0107 Accepted 化。
  • MAS-367 抽出器 + adr-index.json (SSoT): scripts/adr-index.mjs 新規。docs/adr/*.md を 1 パス走査し frontmatter (Status/Mode/Kruchten/Scope/Impl/起案日) + 相互参照 (ADR-NNNN) + Supersede 関係を構造化。--check で CI 整合。実装規模: ~3h。前提: MAS-366。
  • MAS-368 出力①② 自動カタログ + メタデータ横断ビュー: adr-index.json から docs/adr/INDEX.md を自動生成し README §15 手書き表を置換 (§15 はポインタ化)。docs-build に Kruchten/Mode/Scope/Status のソート・絞り込み (クライアントサイド) を付与。実装規模: ~2h。前提: MAS-367。
  • MAS-369 出力③ 依存グラフ: Supersede 鎖・被参照を mermaid で可視化。孤立 ADR・メタデータ欠落 ADR を警告リスト化 (現状: 孤立 0 本・最多被参照 ADR-0036:46)。実装規模: ~1h。前提: MAS-367。
  • MAS-370 出力④ RAG 導線: adr-index.json を機械可読エクスポートとし、決定パイプライン (ADR-0019 triage) が新規起票時に関連既存 ADR を自動提示する文脈ソースにする。実装規模: ~2h。前提: MAS-367 / ADR-0019 パイプライン稼働。
  • CI: 完了後 node scripts/adr-index.mjs --check を PR チェックに追加 (ADR-0107 Confirmation)。

📅 2. 推奨開発ロードマップ（全体像 / Phase 別ビュー）

⬆ トップへ戻る

優先度の定義

優先度定義
★★★改善効果が大きく、改修規模が小さい。すぐに着手すべき
★★改善効果が大きいが改修規模も中程度、または改修規模は小さいが効果も中程度
★改善効果・改修規模ともに大きい、または効果が限定的

推奨開発順序（Phase 1 エンハンスメント）

バグ修正・障害対応は C.3 バグ修正トラッキング で管理。

順番案件ID案件名所要時間目安理由状況
1MAS-001予実差異分析2-3時間FP&Aの最重要機能✅
2MAS-024損益分岐点(BEP)の月次自動算出1時間既存データのみで算出可能✅
3MAS-074給与INV未決済残高の仕訳振替反映1-2時間残高表示の適正化✅
4MAS-199prod→devデータ同期ツール1時間フィルター罠によるデータ欠落防止✅
5MAS-094実績集計の基準年月プルダウン2時間月次締め前の仮集計ニーズ✅
6MAS-020前年同月比較(YoY)2時間経営トレンドの可視化✅
7MAS-192Repository パターンの完全移行4-6時間コードベース全体の保守性向上✅

Phase 別サマリー

Phaseテーマ計画期間実績期間ステータス主な開発案件
Phase 1バグ修正・基盤構築・即効性2-3週間 1週間2026-04-14〜進行中✅冪等性修正(MAS-076)、✅クリーンアップ(MAS-097)、✅デプロイ保護(MAS-096/MAS-195)、✅テスト追加(MAS-098/MAS-196)、✅CF実績専用化(MAS-093)、✅予実差異分析(MAS-001)、✅KPIダッシュボード(MAS-003)、✅監査証跡(MAS-179)、✅setupAllSchemas高速化(MAS-134)、✅バックアップ(MAS-201) (2026-04-30: ✅MFA義務化(MAS-205) / ✅外部共有制限(MAS-206) / プライバシーマーク取得(MAS-254) を Ops 系として P3 に降格)
Phase 1.5自動入力パイプライン（即効）3-4週間 1-2週間2026-04-16〜進行中✅銀行CSV取込(MAS-145)、CC自動消込(MAS-146)、ワンクリック月次締め(MAS-148)、写真OCR(MAS-157)、税区分自動判定(MAS-086)、✅取引先略称(MAS-154)、電帳法リネーム(MAS-152)、証憑リンク再構築(MAS-153)、証憑→マスタ自動起票(MAS-150)、✅取引先マスタ拡張(MAS-120)、✅重複防止(MAS-159)
Phase 2計画強化・実務要件1-2ヶ月 2-3週間2026-04-15〜進行中5カ年財務モデリング(MAS-010)、月次残高試算表(MAS-091)、バージョン管理(MAS-002)、資金繰り予測(MAS-008)、消費税対応(MAS-089)、✅基準年月プルダウン(MAS-094)、✅前年比較(MAS-020)、エクスポート(MAS-021)、✅Repository完全移行(MAS-192)、✅給与INV残高(MAS-074)、✅決済日列追加(MAS-077)、✅管理ID早期採番(MAS-080)、✅マイグレーション基盤(MAS-116)、✅起票ターゲット月(MAS-118)、✅BEP算出(MAS-024)、第三者監査・学術連携(MAS-251)、HP公開戦略(MAS-252)、契約書テンプレ(MAS-253)
Phase 2.5自動入力パイプライン（拡張）1-2ヶ月 2-3週間—未着手請求書OCR→INV起票(MAS-147)、証憑OCR強化(MAS-180)、実績ベース予算生成(MAS-151)、運用ナビゲーター(MAS-156)、Outlookメール自動取得(MAS-155)、取込ダッシュボード(MAS-149)、月次チェックリスト(MAS-183)
Phase 3予測高度化・シミュレーション2-3ヶ月 3-4週間—未着手動的シナリオUI(MAS-005)、目標逆算型人員計画(MAS-012)、ボトムアップWhat-if(MAS-011)、ローリング予測(MAS-004)、投資回収シミュレーション(MAS-013)
Phase 4運用改善・自動化3-6ヶ月 3-4週間—未着手銀行API連携(MAS-181)、異常値検知(MAS-182)、通知連携(MAS-184)、NLP自動ナラティブ(MAS-191)、Slack経費精算(MAS-186)
Phase 5GCP移行・SaaS化 + データ主権基盤3-6ヶ月—未着手認証基盤(MAS-236)、マルチテナント(MAS-237)、Web UI(MAS-238)、API層(MAS-239)、データ移行(MAS-240)、CI/CD(MAS-243)、GCP IAM設計(MAS-207)、VPC-SC(MAS-208)、CMEK暗号化(MAS-209)、監査自動化(MAS-210)、SOC 2/ISO 27001(MAS-211)、管理者ダッシュボード(MAS-241)、課金基盤(MAS-242)、TEE基盤(MAS-246)、DP統合(MAS-247)、接続基盤(MAS-248)、Attestation検証(MAS-249)、匿名化パイプライン技術実装(MAS-250)

必要な体制と役割

役割担当範囲Phase 1-2Phase 3-4備考
プロダクトオーナー (PO)要件定義・優先順位決定・受入テスト必須（兼務可）必須「人間が検討すべき事項」の意思決定者
GASデベロッパーGASコード実装・テスト・デプロイ1名（AI支援）1-2名Claude Code / Roo Code によるAI支援で1名体制が可能
経理・業務担当業務要件の提供・動作確認・運用テスト必須（兼務可）必須会計処理の正確性を検証する最終判断者
税理士・会計士会計指針準拠の確認・税務要件のレビュー随時相談随時相談MAS-073, MAS-089, MAS-090, MAS-109 等の会計・税務案件
Workspace管理者MFA設定・共有制限・アクセス権管理MAS-205/MAS-206時—GASフェーズのセキュリティ設定
GCPアーキテクトIAM設計・VPC-SC・KMS・IaC構築—Phase 4GCP移行時に必要。外部委託も選択肢
セキュリティ監査人SOC 2 / ISO 27001 監査対応—Phase 4認証取得時に外部監査法人が必要

Phase 1-2 の最小体制: PO兼経理 1名 + GASデベロッパー 1名（AI支援）= 2名で推進可能。 税理士への相談は月1-2回程度のスポット対応。

🚀 3. 全案件マスタテーブル

⚠️ 2026-04-30 移動: 本セクションの内容 (§3.1 カテゴリ別 + §3.2 自動入力パイプライン + §3.3 SaaS化展開・計 565 行) は TODO_future.md の構造改革 Phase 2 として docs/_internal/todo_master_tables.md に独立移動しました (PR #420)。

👉 全案件マスタテーブル (todo_master_tables.md)

内容: 215+ 案件のカテゴリ別マスタ (15 バケット) / 自動入力パイプライン narrative / SaaS 化展開・テナントセットアップ。

📐 4. FP&A ギャップ分析サマリー

⬆ トップへ戻る

現在の実装度と、100%（エンタープライズ水準）に向けた具体策のサマリーです。2026-04-30 更新: MAS-057 Phase 3 + Step 6 完了 (PR #379/#394) / MAS-058 Step 1-5 完了 (PR #376/#400・シナリオ健全性診断モードへ主機能変更) / MAS-066 配当ミックス実装完了 (PR #402) / MAS-067 マルチイヤー計画 Phase A〜D 全完成 (Phase A PR #418 / B-1 #423 / B-2 #425 / B-3 #426 / C-1 #440 / C-2 #442 / C-3 #445 / D #448) を反映し、特に シナリオ分析 / バージョン管理 / ドライバーベース計画 / ローリング予測 / 個人法人統合最適化 が大幅前進。

FP&A機能領域現在の実装度100%に向けた具体策
予実比較 (Budget vs Actuals)65%✅ 差異分析自動化 (MAS-001 完了)・MAS-057 cockpit「現状との累積純資産比較」セクション (MAS-058 Step 5 PR #400) / 残: YTD ビュー強化、要因ドリルダウン
シナリオ分析 (What-if)75% (0% → 75% 大幅前進)✅ MAS-011 What-if 5 カ年 ✅ ・MAS-057 cockpit ドロップダウン UI + サンキー + 5 カ年チャート (Phase 3 ✅ PR #379) ・MAS-058 シナリオ健全性診断 6 制約 × Y1-Y5 matrix + 投資余力テーブル (Step 5 ✅ PR #400) ・MAS-066 配当ミックス最適化 (✅ PR #402) ・前提条件 × シナリオのマトリクス試算 (Step 6.9 localStorage 二系統 + 前回選択自動復元) / 残: マクロ経済指標等の外部指標取込、Monte Carlo (MAS-054 仕様書未着手)
ローリング予測75% (15% → 75% 大幅前進)✅ MAS-067 マルチイヤー計画ワークスペース Phase A〜D 全完成 (5 軸モデル + 10 アクション信号機 + ガードレール 10 件 + Burnout/Section G + サジェストエンジン + AI 提案統合 Vertex Gemini・PR #418/#423/#425/#426/#440/#442/#445/#448) / 残: B-4 配当連携 (〜0.5 週・F67_DIVIDEND_INTEGRATION_ENABLED フラグ)・動的期間シフト・実績確定月の自動ロック機構
バージョン管理35% (20% → 35% 前進)✅ MAS-057 cockpit Step 6.9 シナリオ・前提条件 localStorage 二系統保存 (f57_cockpit_scenarios_v1 / f57_cockpit_assumptions_v1)・前回選択自動復元 (PR #400) / 残: 期末スナップショット保存 (MAS-002 仕様書未着手)、バージョン間比較ビュー
ドライバーベース計画80% (70% → 80% 前進)✅ MAS-011 What-if ドライバーベース 5 カ年 ✅ ・MAS-058 健全性診断ドライバー連携 (役員報酬・原価率・固定費・配当の 4 軸入力) / 残: SaaS / ビジネス KPI 統合 (MAS-028)、マクロ経済指標連携
多次元分析55% (50% → 55% 前進)✅ MAS-058 6 制約 × Y1-Y5 期末 matrix (フロー/ストック × 5 年・Step 5 PR #400) / 残: 部門・地域・製品ライン等の分析ディメンション追加、BI ツール連携 (Looker Studio・GCP 移行後)
ワークフロー/ガバナンス60%多段階承認チェーン (申請→一次承認→最終承認)、承認済データのロック機構 (MAS-104 で簡易版検討)
データバリデーション75%複雑なビジネスルールエンジンの導入、リアルタイム修正サジェスト (MAS-139 セルバリデーション 📝)
監査証跡60% (55% → 60% 前進)✅ MAS-179 監査証跡 (✅) ・MAS-201 バックアップ (✅) ・MAS-205 MFA (✅) ・MAS-213 監査ログ保護 (📝) / 残: 完全な操作ログ (誰が・いつ・何を・どう変更したか) の網羅、論理削除の徹底
コラボレーション10%コンテキスト付きチャット連携 (コメント通知)、タスク管理と自動リマインド (MAS-056 意思決定対話 UI 実装後)
プロダクト事業メトリクス0%ARR/MRR トラッキング (MAS-028)、ユニットエコノミクス LTV/CAC (MAS-029)、コホート分析 (MAS-030)、Compound Growth シミュレーション
R&D 管理5% (0% → 5% 仕様書レベル前進)📝 MAS-218 タイムトラッキング (R&D 税制エビデンス用) ・MAS-049 賃上げ促進税制 ✅ ・MAS-061 Cash ETR (R&D 税制控除サジェスト連携) / 残: R&D 費用の自動分類、知財ポートフォリオ、ソフトウェア資産の減価償却、研究開発税制シミュレーション本実装
データ主権・プライバシー保護0%TEE (秘密計算) 基盤 + 差分プライバシー統合 + Attestation 検証 + 匿名化パイプライン + プライバシーマーク取得 + 契約書テンプレ整備 + HP 公開戦略 (MAS-246〜MAS-254 — §3.1 カテゴリ別マスタの 🛡️ セキュリティ / 🏗️ プラットフォーム参照)
個人/法人統合最適化 (2026-04-30 新設)85% (70% → 85% 前進)✅ MAS-057 Solo-CEO Visual Cockpit (Phase 1-3 + Step 6・PR #379/#394) ・MAS-058 シナリオ健全性診断 (PR #400) ・MAS-066 配当ミックス最適化 (PR #402) ・MAS-067 マルチイヤー計画 Phase A〜D 全完成 (PR #418/#423/#425/#426/#440/#442/#445/#448) — 海外 FP&A SaaS の空白領域・bizlp 特有の差別化機能 / 残: MAS-056 意思決定対話 UI、MAS-141 共済シミュレーター、MAS-067 B-4 配当連携

💡 5. 現時点では対象外（Out of Scope）

⬆ トップへ戻る

IDTypeLayer案件名理由
MAS-261Story—AI/MLによる予測分析GAS実行環境制約+データ量不足（※Gemini API等を用いた軽量な推計はスコープ内）
MAS-262Story—多通貨対応現在は国内取引(JPY)のみ。詳細実装単位として MAS-064（為替差損益処理・MAS-063 v2 連動）を §5 末尾に派生起票（2026-04-26）
MAS-263Story—連結会計単体法人のみ。詳細実装単位として MAS-065（関連会社設立時の指標再設計・MAS-063 v2 連動）を §5 末尾に派生起票（2026-04-26）
MAS-264Story—複雑な承認チェーン代表1名体制のため不要（※将来的な多段階承認はMAS-104で簡易版を検討）
MAS-265Story—ERPシステム連携GAS+スプレッドシートで完結
MAS-266Story—リアルタイムデータストリーミングバッチ処理で十分
MAS-267Story—マイナンバー管理機密性が極めて高く GAS+スプレッドシートでは不適切。専用サービス（freee人事労務等）に委ねる
MAS-268Story—入社・退職の行政手続き（届出書類作成）社会保険・雇用保険の届出書類生成は社労士 or 専用SaaS領域。GASで管理するのは22tab(HC)の入退社日・給与情報のみ
MAS-269Story—勤怠打刻・シフト管理リアルタイム打刻はGASの実行モデルに不適合。外部勤怠システム(KING OF TIME等)→CSV取込(MAS-099)で連携
MAS-270Story—通信経路の暗号化・ディスク暗号化Google Cloud基盤がTLS+AES256でデフォルト対応。GAS側での追加実装不要
MAS-271Story—DLP（情報漏洩防止）の自動検知Google Workspace Business Plus以上の機能（DLPルール）で対応。GASでのコンテンツスキャンは実行時間・権限の制約で非現実的
MAS-272Story—SOC 2 Type II 認証の取得認証取得自体は組織プロセスの問題。GASで対応できるのはMAS-188記載の技術的統制のみ。認証監査は外部監査法人に委託
MAS-273Story—PCI DSS完全準拠（カード番号の保持・処理）GAS環境でカード番号を扱わない方針。34_wrk_cardには金額・日付・加盟店名のみ保持。カード番号はクレジットカード会社のポータルに委ねる
MAS-274Story—ScriptPropertiesの暗号化GASのScriptPropertiesは平文保存（Google側の保管時暗号化はあり）。APIキー等のアプリ層暗号化はGAS標準機能では不可。キーローテーション運用（MAS-188）で代替
MAS-275Story—在庫管理・サプライチェーン（BOM/生産管理）コンサルティング業のため製造業向け機能は不要。物品管理が必要になった場合は専用SaaS（Infor SyteLine等）に委ねる
MAS-276Story—Eコマース連携（EC売上の自動取込）現時点でEC事業なし。将来必要になった場合はShopify/Stripe APIからの売上CSV取込（MAS-145パターンの拡張）で対応可能
MAS-277Story—マルチテナント/多拠点管理GASフェーズでは対象外。GCP移行時に MAS-237（マルチテナントデータ分離）として実装予定
MAS-282Story—税務申告用データ抽出エクスポート（旧MAS-092）税務申告は顧問税理士の責務。freee会計/MFクラウド確定申告 → 税理士で完結。本システムは管理会計データの提供まで
MAS-283Story—振込データ自動作成・全銀フォーマット（旧MAS-102）ネットバンキングの振込機能 or 給与計算SaaSの振込連携で対応。振込口座情報のセキュリティ管理リスクも高い
MAS-284Story—給与明細PDF生成・配布（旧MAS-103）給与計算SaaS（freee人事労務等）の標準機能。法定記載事項の準拠も SaaS 側で保証される
MAS-285Story—年末調整データ生成（旧MAS-106）年末調整は給与計算SaaS + 顧問税理士の責務。保険料控除等の入力UIも SaaS 側で提供済み
MAS-278Story—社保料率の自動計算・算定基礎届（旧MAS-107）給与計算SaaS（freee人事労務等）の責務。標準報酬月額・等級判定・年齢判定は法改正追従コストが高く、専門SaaSに委ねる。本システムは確定額を22タブに取込む
MAS-279Story—残業代の計算（旧MAS-099）給与計算SaaS（freee人事労務等）の責務。労基法の割増率計算・みなし残業の超過判定は給与計算の中核機能であり、自前実装のリスクが高い
MAS-280Story—源泉所得税の月額表自動計算（旧MAS-108）給与計算SaaS（freee人事労務等）の責務。税額表の年次改定追従・甲欄/乙欄判定を自前で持つと計算誤りによる過不足徴収リスクがある
MAS-281Story—賞与計算・役員賞与・決算賞与（旧MAS-109）給与計算SaaS（freee人事労務等）の責務。賞与社保の上限判定・源泉税率の特別計算は複雑。役員賞与の届出額チェックのみ本システムで管理可能
MAS-064Story—多通貨対応・為替差損益処理（MAS-262 の派生・MAS-063 v2 連動）国内取引中心の現状はスコープ外（PRD §OUT 多通貨対応の継承）。海外顧客やクロスボーダー案件が出始めたタイミングで起票候補。①対応範囲（将来の仕様化時の想定）: 外貨建 INV / STL / TRN の多通貨記録 / 為替レートマスタ（日次・月末）/ 営業外損益への為替差損益分離計上（MAS-063 営業外損益サブ分類「為替差損益」と連動）/ IFRS 軸の EBIT Margin 切替（MAS-063 戦略メモ §7「海外指標との対応関係」参照）。②起票トリガー: (a) 海外顧客 1 件目との契約締結時 / (b) MAS-063 営業外損益率に為替差損益が出始めた時 / (c) GCP 商用化フェーズ（PH-4）で英語版 SaaS 提供検討時。③依存関係: MAS-063（為替差損益サブ分類で 1 次対応）→ MAS-064（多通貨完全対応で 2 次対応）の段階移行。④起票経緯: 2026-04-26 ユーザー要望「MAS-064/MAS-065 を起票して対象外案件に」を受け、MAS-063 営業外損益指標拡張の戦略メモ §9（深掘り論点）で言及した「為替差損益が出始めた時の処理」を将来 TODO として独立明示。⑤関連戦略メモ: docs/_internal/biz/pl_metrics_non_operating_strategy.md §9（深掘り論点）。⑥MAS-262 多通貨対応との関係: 旧 MAS-262 はマクロな対象外宣言（JPY のみ）。MAS-064 はその下位の具体実装単位（為替差損益処理・IFRS 切替等）として将来詳細化する位置付け。
MAS-065Story—連結会計・関連会社設立時の指標再設計（MAS-263 の派生・MAS-063 v2 連動）単体法人前提の現状はスコープ外（PRD §OUT 連結会計の継承）。SZ-3〜SZ-4（10 名超・持株会社化検討）フェーズで起票候補。①対応範囲（将来の仕様化時の想定）: 親会社 + 子会社 + 関連会社の連結 P/L/B/S/CF / 持分法投資利益の自動計算 / 連結消去仕訳 / 内部取引相殺 / MAS-063 v2 への事業利益率昇格（営業利益 + 受取利息 + 受取配当金 + 持分法投資利益）。②起票トリガー: (a) 関連会社設立検討時 / (b) MAS-063 営業外損益率に持分法投資が出始めた時 / (c) SZ-3 → SZ-4 遷移時の本格 ERP（SAP/NetSuite）移行検討前の中間段階。③依存関係: MAS-063 v2（事業利益率昇格で 1 次対応）→ MAS-065（完全連結で 2 次対応）の段階移行。④起票経緯: 2026-04-26 ユーザー要望「MAS-064/MAS-065 を起票して対象外案件に」を受け、MAS-063 営業外損益指標拡張の戦略メモ §9（深掘り論点）で言及した「関連会社設立時の指標再設計」を将来 TODO として独立明示。⑤関連戦略メモ: docs/_internal/biz/pl_metrics_non_operating_strategy.md §9（深掘り論点）。⑥MAS-263 連結会計との関係: 旧 MAS-263 はマクロな対象外宣言（単体法人のみ）。MAS-065 はその下位の具体実装単位（持分法投資利益・連結消去仕訳・MAS-063 v2 事業利益率昇格との連動）として将来詳細化する位置付け。⑦use_cases.md SZ-3/SZ-4 連動: 規模軸 SZ-4 SMB 拡大期の「30 名超で本格 ERP 移行検討」記述と整合。MAS-065 は SAP/NetSuite 移行前の中間ソリューション位置付け。
MAS-335Story—代表取締役の持ち家事務所化による不動産所得・必要経費按分計算機能節税効果が限定的 (年 3-8 万円規模) のためシステム機能化はスコープ外。実務は税理士アドバイザリー + 個人確定申告 (青色) で対応。①対応範囲（将来仕様化する場合の想定）: (a) 代表者の持ち家のうち事業使用部分 (10% 等) を法人に賃貸する契約を前提に、(b) 個人側の不動産所得計算 (家賃収入 - 必要経費按分) と (c) 法人側の地代家賃損金算入を統合シミュレーション、(d) 必要経費は減価償却 (建物 ÷ 法定耐用年数 × 事業使用割合) + 固定資産税 + 住宅ローン金利 + 火災保険 + 修繕積立金 + 水道光熱費の按分、(e) 構造別耐用年数自動判定 (木造 22 年 / 軽量鉄骨 19 年 / 重量鉄骨 34 年 / RC 47 年)、(f) 中古資産の簡便法耐用年数 = (法定耐用年数 - 経過年数) + 経過年数 × 20%、(g) 将来売却時の取得価額調整 (減価償却累計分縮小) と居住用財産特例 3,000 万円控除の事業用部分対象外を譲渡所得シミュレーションに連動。②節税効果スケール: 建物 5,000 万・木造・10% 事業使用・家賃月 3 万で年 7-8 万円程度 (赤字戦略 = 損益通算で 8.4 万・黒字戦略 = 7.4 万)。RC マンションだと減価償却が薄く 3-4 万。MAS-057 役員社宅 (借家・年 30-60 万) や MAS-141 経営セーフティ共済 (年 50-100 万) と比べ節税スケールが 1 桁小さいため主役にならず、cockpit に統合する優先度は低い。③スコープ外判断理由: (a) 節税スケールが小さい (主役級でない)、(b) 個人確定申告書 (B 様式 + 青色) で完結する内容で法人会計システム機能化の必要性が薄い、(c) 譲渡時の取得価額調整は売却時 1 回のみのイベントで継続的なシミュレーション需要なし、(d) 過大家賃 / 過小家賃の税務否認リスクは「近隣相場ベース」という属人的判断に依存し自動化困難、(e) 住宅ローン減税の事業使用 50% 超ライン判定だけが要警戒だが個人確定申告ソフト (freee 確定申告 / マネーフォワード確定申告) でカバー済。④起票トリガー (将来再評価条件): (a) MAS-057 cockpit / MAS-067 マルチイヤー計画の Phase B-4 / Phase C 完了で「節税スケール小さくても精緻化価値あり」と判断された場合、(b) 顧客向け SaaS 商用化フェーズで「税理士向けアドバイザリーツール」を商品化する戦略を取る場合 (= 節税スケールではなく「税理士の事務効率化」に価値が転換)、(c) 持ち家率の高い地方コンサル法人への商用展開時。⑤関連 RQ: MAS-333 (少額減価償却特例 40 万円未満化検証 2026/4 改正) と関連。⑥起票経緯: 2026-04-30 セッションでユーザー質問「代表取締役の持ち家を法人事務所として家賃支払いする節税効果」を受け、限定的だが効果はある (年 3-8 万円・必要経費按分の減価償却で個人課税所得圧縮) ことを確認したが、cockpit 統合スケールには至らないため Out of Scope として記録。⑦実務での運用方法: 税理士に依頼して個人確定申告 (青色 65 万円控除付き) で不動産所得を申告 + 賃貸借契約書 (法人 ↔ 個人・利益相反取引・取締役会議事録) を整備すれば、システム機能なしでも節税は実行可能。

📎 6. 登録→消込パターンカタログ

⚠️ 2026-04-30 移動: 本セクションの内容は静的・運用ログではなくシステム仕様の付録として位置付けが妥当なため、docs/spec/spec_payment_flow_patterns.md に独立移動しました (PR #418)。以下のリンクから参照してください。

👉 登録→消込パターンカタログ (spec_payment_flow_patterns.md)

内容: 3 軸の定義 / 36 パターン × 10 フロー集約表 / 共通する 6 段階構造 / 段階別ボトルネックと解消案件 / ステータス別カバレッジ。

🔄 7. ドキュメント運用 Review トリガー (handover 2026-05-20 派生)

⬆ トップへ戻る

handover 2026-05-19〜20 セッション (tasks/prompts/handover_2026-05-20_adr_0054_0055_sidebar_session.md) で完了した大規模改訂 (ADR-0054 全 Phase / ADR-0055 / nav 構造クリーンアップ / サイドバーリファクタ / Glossary SSoT) の事後検証・改善案を集約。MAS-XXX 系の実装案件とは別軸の「運用 review トリガー」として管理。

7.1 ADR Review After トリガー一覧

トリガー日対象 ADR検証内容起票 PR
本番 20 run 到達後の月初 (初回想定 2026-07 月初)ADR-0142受付プリゲートの precision 月次監視。drp/queries/adr-0142-pregate-observation.sql(drp 側で整備依頼中・handover_2026-06-18_adr0142-precision-monitoring-sql_to_drp.md)で本番 D1 から月次集計。precision <70% or INVALID ≥3 件 で撤退条件発動(graph 分岐 OFF + docs 「本番稼働」記述を「OFF / 撤退」へ更新)。TC-G04 golden eval(tools/pregate-eval/eval-prod.ts・main 領分)も相乗り可。本番稼働 2026-06-15 = PR #2043PR #2043 (Phase B 本番稼働)
2026-08-19 (3 ヶ月後)ADR-0054新規 rule 追加が 1 件以上発生し doc 構造が機能したか確認。10 節構造で表現困難なら案 X2 (Progressive Disclosure 中心) へ寄せる検討。§3 評価軸スコアの confirmation bias を第三者 re-scoring で再検証PR #856〜#870
2026-08-19 (3 ヶ月後)ADR-0055新規 group 追加で番号衝突が発生していないか確認。NS 接頭辞 4 つ (I/A/O/M) で disambiguate 不能なケース有無PR #858〜#862
2026-11-19 (6 ヶ月後)ADR-0054adr-lint_rules.md 行数が 500 行に逼迫していれば Progressive Disclosure 分割を実施 (現在 134 行、warn 閾値 400 行)—
2026-11-19 (6 ヶ月後)ADR-0055既存メンバーから letter prefix 復活要望が出れば部分復元検討—
2027-05-19 (1 年後)ADR-0054Gemini の superseded_by 等の未採用 metadata フィールド追加検討、業界 FW (markdownlint v2 等) の規約改訂反映—
2027-05-19 (1 年後)ADR-0055nav title 長が平均 15 文字超えていれば prefix 短縮再設計—

7.2 改善案バックログ (低優先・四半期レビュー対象)

ID内容優先度想定起票
DOC-OPS-01docs/architecture/glossary.md の四半期レビュー: 用語追加候補抽出 + MAS-NNN との紐付け強化 (現状 61 用語、MAS-XXX 関連は 12 用語)low2026-08-19 (ADR-0054 review と同期)。2026-05-30 中間パス: Pipeline 中核語 5 件追加 (Decision Pipeline / Gate 0–4 / mode / MCDA / telemetry、56→61)。MAS-NNN 紐付け強化は MAS master 突合が必要なため次パス (2026-08) へ繰越
DOC-OPS-02docs/SUMMARY.md (swap 後 landing) / docs/index.md (swap 後 TOC) の prefix 同期 lint を docs-nav-lint.mjs に追加 (将来 R5)。_config.json group prefix と TOC section prefix の機械整合を CI で検証low必要時
DOC-OPS-03sidebar styling 微調整 (font size / 配色 / アイコン等)。handover で「sub から発見した改善案」例として明示されたが今セッションでは具体案なしlowsub session 着想時
DOC-OPS-04docs/implementation/legacy-dev/dev_mas-090_*.md 等 legacy-dev 配下の swap 影響 anchor ([5.5 預り金・源泉税](../index.md) 等) を read-only ポリシー継続するか修正するか判断lowlegacy-dev 解凍時
DOC-OPS-05 ✅docs/_internal/05_how-to/git_workflow.md rebase 章に「pre_bash_guard が force-with-lease push を block するため ! git push --force-with-lease をユーザに依頼」のオペレーション手順を明文化 ([[failure-patterns]] #42 対策)mid✅ 完了 PR #880 (2026-05-20)
DOC-OPS-06ADR-0070 R6 lint 実装 (main 担当): scripts/docs-nav-lint.mjs に R6 title-h1-consistency 追加。ADR file H1 の ^ADR-NNNN:\s+ strip 例外ロジック + docs-nav-lint-r6-allowlist.json 新規 (機械生成 file 用)midADR-0070 Accept 後すぐ (2026-Q3)
DOC-OPS-07ADR-0070 Phase 2b: 残 238 件 (other bucket、H1 と title が完全に違う言い回し) を R6 lint 実装後の CI WARN リストベースで個別判断・batch 修正 (sub 担当)lowDOC-OPS-06 完了後 (2026-Q4 〜 2027-Q1)
DOC-OPS-08 ✅ADR-0041 実装: docs/research/ 4 RQ research doc (current-spec / itgc / research / spec テンプレ用 Gemini/Claude/GPT 3 vendor 並列調査) + AGENTS.md 改訂 (型ファースト運用追記) (sub 担当)mid✅ 完了 PR #985 (2026-05-26) — rq-054〜057 + AGENTS.md §型ファーストプロセス。ADR-0041 Implementation Status: Done
DOC-OPS-09 ✅ADR-0041 --check-template-exists 実装 (main 担当): scripts/adr-lint.mjs に新規 subcommand 追加、_meta/templates/<type>.md 存在検証mid✅ 完了 PR #997 (2026-05-26)
DOC-OPS-10ADR-0070 Phase 3: R6 lint WARN → ERROR 昇格 (main 担当)。Phase 2b 完了 6 ヶ月後の絶対時期 (2027-04 〜 2027-08) で実施low2027-Q2
DOC-OPS-11ADR-0043 JTBD スコープ拡張: 開発プロセス・ドキュメント管理系 RQ (RQ-034, RQ-040〜053) 用の JTBD を 3 軸テストで起案し _jtbd_list.md に追加。現状は業務ドメイン RQ のみタグ付与済、メタ/ツール系は --check-jtbd-ref で warning のままmid内部プロセス JTBD 方針確定後
DOC-OPS-12 ❌Pipeline Opus 4.7 ノードへ Anthropic prompt caching 適用 — 元 ADR 起案は技術的に無効と確定 (2026-05-29 RQ-084 P1-Q3 計測)。Opus 4.5+ の最小キャッシュ可能サイズ 4,096 tokens に対し全 4 ノード system が下回る (body-generation 3,599 / gate2-consistency 690 / gate3-parallel-review 323 / gate4-scoring 775)。cache_control 付与しても prefix が threshold 未満で cache 不成立。[[rq-084]] §5.4 で案 δ (body-generation prompt slim down) に転換。main 側で prompts/production/body-generation/prompt.md を 3,599 → ~2,500 tokens に slim 化 (詳細は RQ-084 §5.6 = 12 ブロック特定 + 4 ブロックの具体的置換案 + promptfoo eval + KV push 手順)。月 -$1-1.5 + TTFT ~30% 短縮見込み。本 caching 路線は完全廃止midmain 側 prompt slim 化着手待ち
DOC-OPS-13Gate 4 Scoring samplingN を 5→3 に削減検討 (scoring Opus 呼び出し −40% のコスト減)。前提条件あり: σ (scoringStdDev) 上昇で mode 閾値 (Light 35 / Standard 40 / Critical 45) 判定ブレのリスク。ADR-0056 §6.1 のトリガーは「σ>5 → N=10 拡張」で 増やす 方向のため N=3 は逆行。判断には σ 実績が必要だが [[adr-0074]] (Gate 4 σ 月次モニタリング) が Proposed/Not Started で σ トレンド未可視化。→ まず ADR-0074 実装 or telemetry D1 から N=5 時点の σ 分布を確認し、σ≪5 を確認できてから 5→3。設定箇所 prompts/production/gate4-scoring/prompt.meta.yaml (sampling_n: 5)lowσ 実績確認後 (ADR-0074 実装と同期)
DOC-OPS-14 ✅adr-lint scope-meta / confirmation-section の新規 ADR 再発防止 (body-generation prompt 根治)。CI の node scripts/adr-lint.mjs docs/adr/ が 0072-0087 の 16 本で fail していたのを 2026-05-30 PR #1180 で遡及修正済 (Scope 付与: 0080=product / 他=platform、Confirmation を H3→H2 昇格)。systemic fix (① Scope メタ出力、② Confirmation を ## H2 出力) は deploy 完了 = 解決 (2026-06-02 sub 検証): prompts/production/body-generation/prompt.md に Scope 出力指示 + ## Confirmation H2 強制 (adr-lint ルール名明記) が両方反映済。新規 ADR-0105/0106 が後修正なしで pass し、adr-lint 107/107 pass (100%) を sub ローカルで確認。以後 sub の手動遡及不要mid✅ 完了 (2026-06-02 検証) — body-gen prompt deploy 済・adr-lint 全 pass
DOC-OPS-15ADR-0098 errata (撤退条件の時系列不整合): 撤退判断日「マージ+grace14日+60日 = 74日(≒2.5ヶ月)」と撤退表の観測窓「3ヶ月連続 overdue」が構造的に矛盾 (2.5ヶ月時点で3ヶ月連続観測は不可能)。対応案: 判断日を「+90日(≒3.5ヶ月)」に後ろ倒し or 観測窓を「2ヶ月連続」に短縮。実装着手時に確定し ADR本文+撤退自動Issue発火日を一致させる。この errata 含む全レビュー指摘 (採点コメント4点・13盲点・3モデルレビュー) は PR #1251 本文 (15KB) に既存。本行は埋もれ防止のサマリ。ADR-0098 は Accepted (PR #1251 merged) ゆえ訂正は実装フェーズ=main で軽量PRmidADR-0098 実装着手時 (main)
DOC-OPS-16 ✅提案資料生成パイプライン (.md + 会社紹介PPTXテンプレ → ブランド一致.pptx) の ADR/spec 起案: main が Track1(レンダリング/ブランド忠実度)+Track2(オーサリング上流・3モデル一致)を調査確定 (2026-06-01, ~$7.1)。結論=Slide-IR(JSON)採用(DOM-to-PPTX はテンプレ再利用非互換で不可)。sub が正式 ADR/spec 起案 (配置: docs/_internal/04_specs or 新規プロジェクト docs)。起案時は Track1+2 FINAL を引用しつつ「実装で確定する2点(①CJK粒度 ②テンプレ参照方式)」を Open Question 化 (main 側で renderer/CJK 最小決定が先)。raw: main gitignored tmp + handover proposal-pipeline-track1/track2_to_sub.md。起案者生テキスト作成済 (tmp/adr_proposal-slide-gen-pipeline.md, 2026-06-02 sub) — operator_guide §4.1 形式・Track1+2 FINAL 引用・2 Open Question (①CJK 粒度 ②テンプレ参照方式) 含む。memory: project_proposal_slide_gen_pipeline_track2mid✅ 完了 — ADR-0122 として受理 (PR #1483 merged 2026-06-05・CV 一発通過 46/50・nav A.09.5.83)。KV draft 自動削除済。次 = 実装 (main 領分・renderer 確定 PoC が最初)
DOC-OPS-17ADR-0099 実装時の縮退検討 (過剰設計指摘): ADR-0099 (実装スコープ第一級化 + 0088同期, PR #1258 merged 48/50) は Policy Alignment が項目#3「1人法人の運用コスト」で ❌ (KPI 8件・撤退条件 8件・4週レビューは単独運用で認知負荷飽和)。3モデル・盲点#3 も同旨。実装時に縮退検討: Confirmation を最小3KPI(保有率・空節率・§5スコア)に絞り残りは観測のみに降格 / 撤退トリガ削減 / 三者整合(ADR-0024・body-gen・adr-lint)の manifest 化 / warn→error 昇格判断。詳細レビュー(Policy・3モデル・7盲点)は PR #1258 本文に既存。本行は埋もれ防止のサマリ。実装フェーズ=mainmidADR-0099 実装着手時 (main)
DOC-OPS-18 (②起案済・③未)認証・秘密情報衛生 RQ-085 の残テーマ②③ ADR 起案: 元単一 ADR (KV draft auth-secret-consolidation-strategy・Critical 38/50 差戻し) を 3 分割し、テーマ① (失効しない GAS/clasp デプロイ認証) は ADR-0104 で起案済 + 実機完了 (2026-06-01)、元 KV draft は DELETE 済。②起案済 (2026-06-03 審査通過 42/50 → ADR-0110 Proposed・PR #1364 merged 2026-06-04 = doc は Proposed のまま main 着地): pipeline Basic 認証→Cloudflare Access service token (sub audit API 疎通の正規化)。OQ 追補済 (2026-06-04: OQ-1 workers.dev 直下適用可否=カスタムドメイン前提 / OQ-2 緊急スイッチ→IP allowlist 再設計推奨 / OQ-3 製品化後は顧客向けマルチテナント Entra OIDC が固定制約=CF Access は社内フェーズ限定の解・過剰投資回避を Accept 前判断)。Accept は OQ-1〜3 の実機検証 main 担当・検証後判断 (PR は merged 済だが Status=Proposed / Implementation=Not Started)。raw: tmp/adr_pipeline-basic-auth-to-cf-access-service-token.md。残③が未起案: 静的 secret 単一ソース化 (Doppler 等) + GitHub OIDC/WIF キーレス化 + 失効の日次カナリア pre-flight 検知。いずれも job-blocking でない衛生課題 (docs/_internal/03_decisions/decision_pipeline/mvp_exit_criteria.md で 🟡 と評価)。起案時は RQ-085 synthesis (docs/research/rq-085-auth-secret-consolidation.md) を定量根拠に。memory: project_rq085_auth_consolidationlow②=実機検証 main 待ち (ADR-0110) / ③=パイプライン安定後
DOC-OPS-19審査パイプラインへ「コード実査グラウンディング」導入 (verify_in_code actionability + evidence pack 規約): pipeline はコードを読む step を持たない (drp/src/graph.ts の全ノードが LLM テキスト処理・consistency は ADR コーパスのみ参照) ため、盲点検出が生成する「コードで白黒つく仮説」を検証できないまま CV が Must 毀損として差し戻す構造的非対称がある。実例 (2026-06-04): docs 差分ビルド draft が CV 4 連続差し戻し (score 44→46→47→48 と上昇しつつ critical は毎回新種 = goalpost パターン)。うち round3 critical (glossary 注入粒度) はコード実査 5 分で反証できた (scripts/docs-build.mjs L409-414 = buildPage 内側注入 / L460 = 起動時 fresh ロード) のに、検証手段がないため 1 周 ~16 分 + LLM 課金を消費。改修案: ① CV finding の actionability に verify_in_code を追加し「revise_adr (却下)」から「コード根拠を添えて反証 or 追補」の検証要求へ分離 (プロンプト+分岐の小改修・main) ② 起案テキストの「検証済みの前提」節 (コード実査結果・行番号つき) を operator_guide に規約化 (運用のみ・v4 で実証済) ③ 審査ノードへ repo read ツール付与 (将来・token 管理と agentic 制御が必要)。設計要件 = 起案テキストの肥大化防止: 盲点対応の追記が本文に永続蓄積するラチェット構造 (実例: 同 draft の生 context が v1→v4 で 3.5KB→13KB に膨張) を避け、evidence は KV draft の別フィールド等で本文と分離して CV が参照できる形にする — 決定の変更のみ本文へ・検証事実は evidence pack へ。関連: reference_crossval_selfscore_premise_loop / project_pipeline_early_crossval_pregate_idea (早期プリゲート案と統合検討余地)midパイプライン安定後・DRP-371 修正後に起案者生テキストから ADR 起案
DOC-OPS-20ADR-0109 の 8 週後 amendment に反映する改善 5 点 (重複 draft 再審査の副産物): KV 残骸 draft adr-0107-crossval-part4 (= ADR-0109 を生んだ元 draft の消し忘れ) を 2026-06-04 に再審査した run (47/50・Gate2 が SUPERSEDE メタ要求 + ADR-0109 重複を INFO 指摘) が、ADR-0109 本文への実質的な改善指摘 5 点を産出した。draft は重複のため DELETE 済 (204・姉妹 draft crossval-systemic-fix と同処理)。ADR-0109 の escalate 承認率 KPI 確定 (起案 8 週後 ≒ 2026-07 末) の amendment 時に以下を反映: ① 撤退条件の真の撤退化 — 「月 5 件超で見直し」→「即時 flag OFF」+ 誤 escalate 比率 10% 基準 (分母下限 20 件) + 8 週 baseline 期間の暫定基準 (初週 3 件超で即停止) + sunk cost と採択判断の分離を明記 ② solo 運用 HITL の独立性限界の Limitations 化 — escalate PR の self-merge は LLM-Modulo の「独立した外部検証器」要件を満たさない (ADR-0112 の HITL 受理で実例発生済)。「merge は起案者以外 or 非同期第三者レビュー」の運用規約 or 限界明示 ③ Part3 (socratic 決定化) のデフォルト OFF 再評価 — 無改変再投入の月間件数を実測し観点固着コストと比較 ④ FNV-1a 入力正規化 (UTF-8 / CRLF→LF / BOM 除去) の CI (Node.js)・本番 (Workers V8) 間ハッシュ一致 unit test ⑤ 実装後追認 ADR である旨のリスク明記 + KPI 確定 amendment 手順の明文化。指摘全文は audit run telemetry (2026-06-04 18:16 JST 起案分) の盲点レポート参照midADR-0109 起案 8 週後 (2026-07 末) の amendment 時
DOC-OPS-21 ✅Corp（全社）L1 入口ページの新設（ADR-0128 / Tier P）: 再ポジショニング後も Corp 軸に概要/入口ページが無く（空白）、新規読者が全社像を把握できない。writing-guide §7.3 の Tier P 軽量ヘッダー（運営/対象/更新ポリシー/索引リンク）+ エレベーターピッチ形式で Corp L1 入口を新設する。本タスクは「起票」のみ（本文執筆は別タスク）。必須フィールド — 担当者: sub（ドキュメント担当）/ 完了期限: 2026-08-03（ADR-0128 採択 2026-06-08 + 8 週・KPI 期限）/ レビュー責任者: [email protected]（単独 Decider）/ 優先度: mid。完了条件 (KPI): Corp L1 landing が URL として HTTP 200 で閲覧可能（ADR-0128 §Confirmation・採択+8 週以内）。未達時は ADR-0128 撤退条件 (a) を発動し Tier P「推奨」降格 or 案 A へ revert を検討。配置候補は _config.json nav の Corp グループ直下。memory: project_corporate_site_repositioningmid✅ 完了 (2026-06-14) — docs/corp/README.md が Tier P L1 入口として稼働（基本情報 + エレベーターピッチ + 主要導線、nav A.03.3.1）。KPI（HTTP 200・採択 2026-06-08 + 8 週以内）達成。導線に最新更新（What's New）を追補。本文の深掘りは Tier P 軽量方針のため将来タスク
DOC-OPS-22ADR-0130 (索引・目次・カタログ自動生成規律) の 3 モデルレビュー未反映指摘の Review After 反映: 受理 run (47/50・2026-06-10・PR #1677 merged) の 3 モデルレビューに、本文未反映の concern/suggestion が残る。盲点 7 件は本文 Confirmation 1〜7・撤退条件 (c) に織り込み済み = 実装フェーズで消化、これとは別枠。判定タイミング (受理 6 ヶ月後 ≒ 2026-12・撤退条件判定と同時) or Accepted 化前の追補で反映を検討: ① 例外リストの上限数と例外常態化時の規律全体再評価条件 (Claude — 現行は例外追記のみで形骸化経路が残る) ② 判定タイミングを待たない critical 中間対応の定義 (Claude — 6 ヶ月内の閾値超過時の扱いが未定義) ③ CI 実行時間バジェット — 全生成器合計の --check 実行時間閾値 (Gemini+o3 の 2 モデル一致・DX/ランナーコスト) ④ 難易度別工数テーブルの骨格 (Claude+o3 一致 — 簡易 ~3h / 標準 ~8h / 複雑 ~20h + 分類軸: ソース数・外部依存・結合ロジック) ⑤ rollback 減点分: 規律全体の撤回シナリオ・データ復旧視点 (scoring 7_rollback 4/5)。運用実績待ちで見送り: 境界事例 (ハイブリッドページ) の判定揺れ / 並行 PR での生成器競合 (系統数増加後) / 本文ページ四半期レビューのスコープ越境懸念 (Confirmation 7 を削る方向のため Review After で)。指摘全文は審査 run telemetry (sessionId 90e9fefc / 2026-06-10) 参照。memory: project_adr0107_exec_summary_6rlow判定タイミング (2026-12・撤退条件判定と同時) or Accepted 化前
DOC-OPS-23 ✅docs/index.md (全ドキュメント目次・グループ俯瞰マップ) の生成器化 (ADR-0130 棚卸しの起票): 本文に「_config.json の nav と同じ階層・順序」「概要は代表ページ冒頭から自動抽出」と明記されているが生成器がコミットされておらず、手作業更新前提の対象ページになっている (ADR-0130 棚卸しリスト index_catalog_inventory.md で唯一の生成器化候補)。実装: scripts/generate-docs-index.mjs (仮) — _config.json nav 走査 + 代表ページ (README / 先頭ページ) 冒頭の自動抽出 + namespace prefix 変換 (M/I/A/O)。3 点セット (生成器 + adr-lint.yml --check + 走査範囲明文化 + scan_baseline 縮小ガード) で整備し、完了後に doc-inventory.mjs の TICKETS → GENERATORS へ移す。難易度: 標準 (ソース 2 種結合・外部依存なし)。関連: DOC-OPS-02 (prefix 同期 lint R5 — 生成器化されれば同期は構造的に保証され R5 は不要化する可能性)mid✅ 完了 PR #1690 (2026-06-10) — scripts/generate-docs-index.mjs + CI --check + 縮小ガードの 3 点セットで整備、レジストリ TICKETS → GENERATORS 移動済。起票は PR #1687
DOC-OPS-24 ✅#1693 群A: docs メタデータ由来の手書き一覧 2 件の解消 (ADR-0130 セクション単位適用): ① docs/domains/README.md §機能一覧 (ドメイン×主要仕様書 10-15 行) を docs/domains/*/ ディレクトリ構造から生成器化 (scan_baseline 縮小ガード + adr-lint.yml --check の 3 点セットで整備。generate-docs-index.mjs の代表ページ解決ロジックが流用候補) ② docs/adr/README.md §用語定義 (略号×定義 15 語) は glossary.md (docs/architecture/glossary.md) との手書き重複なので SSoT 参照へ置換 — 置換前に 15 語の glossary 収録突合が必要 (欠落語は glossary へ追加してから参照化)。完了後 scripts/doc-inventory.mjs の TICKETS → GENERATORS / 登録解除を反映。出典: tasks/prompts/main_2026-06-10_doc-inventory-section-list-candidates.md 群Amid✅ 完了 PR #1698 (2026-06-10) — ① scripts/generate-domains-list.mjs (セクション単位生成器) + CI --check + 縮小ガードの 3 点セットで整備 ② 突合の結果 glossary 収録済みは SSoT のみ・欠落 13 語を glossary へ追加して参照化 (案件 prefix は tooltip 誤マッチ回避で I-XX 等の番号表記)。レジストリ TICKETS → GENERATORS 移動済
DOC-OPS-25#1693 群B: GAS コード由来 doc 一覧の codegen 整備の是非判断 (ADR-0130 スコープ外の別軸): タブ一覧 (arch_data_model.md ~100 行)・UI 分類 (spec_dashboard.md)・列マッピング (spec_engine.md)・仕訳マトリクス (frd_financial_logic.md)・テスト ID 対応表 (testing/00_overview.md) 等 9 件は、生成元が GAS ソース (101_sys_config.js タブ定義 / DDL / 901_test_runner.js 等) のため code→docs codegen が必要で、ADR-0130 (doc メタデータ由来の生成) のスコープ外。codegen 整備の是非・優先順を別 ADR or 案件として判断する (高リスク = タブ一覧・列マッピングは実装乖離が監査リスク、低リスク = npm scripts 一覧)。判断まで棚卸しリストの対象外として走査範囲注記に明文化済み。9 件の詳細表: tasks/prompts/main_2026-06-10_doc-inventory-section-list-candidates.md 群BlowADR-0130 判定タイミング (2026-12) の振り分け確認まで or GAS スキーマ大規模変更時
DOC-OPS-26 ✅ADR-0141 スコープ外「concern タグ設計+必須レビュアー発火条件」の別 ADR 起案: security/legal 等の横断的関心 (concern) タグを consulted 欄に付与する設計と、タグに応じた必須レビュアーの発火条件 (RQ-101 設問 3)。ADR-0141 (承認者体系・Accepted 2026-06-12) が Non-Goals と §1.4 で「ドライバー・検証 KPI が分かれる別決定」として分離し、受理後 30 日以内 (= 2026-07-12) の DOC-OPS backlog 起票を Confirmation 要件とした行き先 (未起票は Confirmation 違反・ADR-0130 パターン)。本行の起票で履行済み — 0141 初回月次集計で本行の存在を確認する。起案時は RQ-101 (DACI/RACI 3 フレームワーク調査) と役割割当レジストリ (docs/_internal/06_ops/adr_approver_role_registry.md) を素材に、consulted 運用実績から発火条件の要否を判断するlow✅ 完了 — ADR-0151 として受理 (2026-06-14・審査 44/50・rejected:false・PR #1963 起票 → #1964 受理 flip)。 実装 (concerns スキーマ + lint ルール a〜f + concern→reviewer registry) は ADR-0151 Implementation Status: Not Started でチーム化準備時の別タスク (main 領分)
DOC-OPS-27ADR-0039 残作業 (Phase 4 後フォロー・旧 COVERAGE_GAPS から移送 / ADR-0145): ① AI ツール呼び出し計測 — ADR-0039 §Confirmation の count-doc-tool-calls.sh Phase 3 後再計測 (目標: 平均 2 回以内・2026-08-15 Review After 前) ② operations/itgc/ 4 領域の本格化 — 現状スケルトン (各 39 行)。J-SOX 監査要件確定時に B2/B3/B5 パイプライン経由で本文充填 ③ domains/{rpa-automation, order-management, project-accounting, data-ingest, corporate-tax} の統合 current-spec.md — 5 ドメイン全て未作成 (FP&A スイート整備のタイミングで)low①2026-08-15 前 ②監査要件確定後 ③必要時
DOC-OPS-28ADR-0048 Phase 3-4 fitness function 未実装分 (旧 COVERAGE_GAPS から移送 / ADR-0145): ① scripts/count-doc-tool-calls.sh の CI 組込み ② status: planned の 30 日経過警告 scripts/check_stale_stubs.py 新設 (ADR-0048 Phase 3 計画・検出時は CI warning)。いずれも main 領分lowADR-0048 Phase 3 着手時
DOC-OPS-29CV コメント (D1 telemetry) からのタスク候補抽出の仕組み化: 審査 run の cross_validation_verdicts / residual_risk_titles を定期照会し、未追跡の高優先タスク候補を抽出する仕組み (スクリプト+運用) を、必要に応じて ADR 起案のうえ整備する (達希 2026-06-13 決定)。抽出 3 信号 = ① escalate 受理の residual_risk_titles (残余リスク付き merge = 明示的に未解決のまま受理されたリスク) ② 通過 run の undermines=true (本文に緩和を書き足して通過 = 実装で果たすべき約束) ③ verifyInCode=true かつ evidenceResolved=false (コード実査で安価に閉じられる)。既存トラッカー (DOC-OPS / main 申し送り / パイロット計画) と突合して未追跡分のみ起票する。初回サンプル分析 (直近 60 run・1,910 verdict → 未追跡候補 7 件) と D1 照会手順は起票 PR #1922 本文に既存。関連: DOC-OPS-19 (verify_in_code グラウンディング — 統合検討余地)・DOC-OPS-20 (run 再審査が改善指摘を産出した先例)midADR 起案 or 実装着手時 (main との分担確定後)
DOC-OPS-30JTBD-012（証憑保存 SaaS）spec へ BCP/DR 必須節を起票: 証憑-仕訳紐付けインデックスの再構築可能性・TSA（タイムスタンプ局）停止時の猶予手順・ストレージインシデント時の代替提出手順を spec の必須節とする。出典 = DOC-OPS-29 初回分析 候補3（PR #1922 本文）。根拠 CV = ADR-0126 の残余リスク付き受理 3 件（「電帳法施行規則第 4 条違反が全顧客同時に成立」等）。行き先: JTBD-012 の spec 着手時に当該 spec へ移送（現状 PoC 先行で spec 未コミットのため本表で暫定追跡）。関連: ADR-0118 / ADR-0126高（製品・法令）JTBD-012 spec 着手時
DOC-OPS-31PoC 顧客データの返却・削除手順書を PoC 開始の前提条件として起票: 撤退時に電帳法対象書類の返却・削除手順が存在しないと顧客の保存義務違反を招く。PoC 開始前に手順書が存在することを前提条件とする。出典 = DOC-OPS-29 候補4（PR #1922 本文）。根拠 CV = ADR-0118 残余リスク。行き先: JTBD-012 の PoC 計画。関連: ADR-0118中（PoC 前）JTBD-012 PoC 開始前
DOC-OPS-32COVERAGE_GAPS 幽霊エントリーの初月確認: 消化済みタスクの出典 handover 側削除（マーカー節からの除去 or archive 退避）が運用に乗り、幽霊エントリー（消化済みなのに残る行）が撤退閾値 20% を超えないかを初回月次で確認する。ADR-0149 Phase 2 の件数ガード・鮮度チェック・ソース別乖離検知（PR #1936/#1939/#1940 で実装済）が幽霊を実際に検知できるかの検収を兼ねる。出典 = DOC-OPS-29 候補7（PR #1922 本文）。根拠 CV = ADR-0145「削除の責任者・手順未定義で幽霊エントリーが撤退閾値を運用開始直後に超える」。相乗り: 週次レビュー（DOC-OPS-33・観測項目 5。観測は今週から・正式検収は月次節目）低（監視相乗り）週次レビュー稼働後・初回の月次節目
DOC-OPS-33 ✅週次レビューの記録先・テンプレート・観測カレンダーの枠組み整備: 複数 ADR（0136/0138/0140/0107/0149）が個別に Confirmation で「月次集計」を要求するが、記録先が分散・統一フォーマット無し・一度も実行されていなかった。加えて月次では今の高頻度フェーズ（数日で ADR 受理）に追いつかないため運用を週次へ前倒し。週次レビューの SSoT を新設し「今週から観測 → ADR 規定の判定節目（2026-07-11〜）で正式判定」に整理。出典 = handover 2026-06-14 残タスク「月次集計の初回」が受理直後では時期尚早と判明 → 週次なら今週から積み上げ可能と達希が判断。相乗り: DOC-OPS-32（幽霊エントリーは本枠組みの項目 5）。ADR の月次規定は実態に合わなくなったため将来 amendment 候補（当面は運用=週次・ADR 本体は据え置き）mid✅ 完了（2026-06-14） — docs/_internal/06_ops/weekly_review/（index.md = 運用ガイド + 観測カレンダー、template.md = 週次記入枠）を整備、nav O.03.8/O.03.9 登録。観測は今週（2026-W24）から、正式判定は ADR 節目で
DOC-OPS-34docs-build.mjs のビルド軽量化 (per-page git blame + fetch --deepen の最適化): 1 ビルドが重い — 各 .md に git blame --line-porcelain を実行（scripts/docs-build.mjs L567 blameCommitterTimes・直近更新ブロックのハイライト用）し、shallow clone では起動時に git fetch --deepen=250（L553・timeout 60s）で履歴を掘る。2026-06-18 の Cloudflare Pages デプロイ渋滞調査で原因④として特定。渋滞の核心（preview 全ブランチ無条件ビルド + build キャッシュ無効 + 自動 PR の高頻度再ビルド）は対処済み（Cloudflare preview を chore/auto-sync-* 除外 + build caching 有効化）。本件はビルド時間そのものの最適化で、build caching で一部緩和され得るが blame/fetch の per-build コストは残る。改修案: 最終更新ハイライトのキャッシュ化 or blame 範囲の限定（全ページ→更新候補ページのみ）。出典 = handover main_2026-06-18_cloudflare-pages-deploy-congestion.md 対策④。関連: doc-news-sync.yml / coverage-gaps-sync.yml（同じく derived doc 鮮度のため fetch-depth:0 を要する群）low渋滞再発時 or ビルド時間が問題化した時（Cloudflare 本丸で当面解消）
DOC-OPS-35 ✅auto-sync bot PR の merge 摩擦の恒久解消（GITHUB_TOKEN で必須 check 未発火→BLOCKED）: peter-evans の自動 PR は GITHUB_TOKEN で作成されるため pull_request イベントが発火せず必須 check が未報告 → BLOCKED に固定されていた。改修案①（PAT 化）を 2026-06-19 採用・完了: fine-grained PAT AUTOSYNC_PAT（Contents/Pull requests/Workflows Read & write・本リポ限定・1 年 expiration）を発行し、3 workflow（doc-news-sync.yml / coverage-gaps-sync.yml / sync_slice_id.yml）の peter-evans/create-pull-request step に token: ${{ secrets.AUTOSYNC_PAT }} を追加。以後の bot PR は人間相当の event を発火し、必須 check が自動で走って通常 merge できる。rotation: PAT 失効が近づいたら新 PAT 発行 → secrets.AUTOSYNC_PAT 更新 → 旧 PAT revoke の順（現 PAT は 2027-06 失効想定）。手動 merge の対症療法は不要化（memory autosync-bot-pr-merge-path は「過去対症策」として保全）。出典 = 2026-06-18 doc-news 自動化（#2151/#2153）で顕在化、本セッション #2175/#2176 で 4 度目の再発を契機に根本対応low✅ 完了 (2026-06-19) — PR で 3 workflow 修正 + 秘密設定 + memory 反映

7.3 改善案の起票運用

  • MAS 番号化しない理由: 7.1 は ADR 内で定義済の Review After、7.2 は運用 doc 系で実装案件 (MAS-XXX) とは性質が異なる
  • 7.2 が複数蓄積したら DOC-OPS-NN を MAS 採番 (DC-XXX 等の独立 prefix) に格上げするか検討 (1 年後の運用 review トリガーで判断)
  • ADR Review After は ADR 本文 §6 が SSoT。本セクションは 横断インデックスとして機能 (起票漏れ防止)