ops 統合設計書

Issue #161 — 全パイプラインの要件・フロー・データモデルの統合整理 | 2026-04-06

1. 全体概要

opsとは

合同会社MNMLの月次業務を自動化するパイプライン群。経費処理、請求書管理、メール振り分け、作業報告書作成、TFHD案件の月次フロー、ニュース巡回など、毎月繰り返す定型業務をプログラムで処理する。

すべてのパイプラインはMac mini上で動作し、Slackを通じてCEOに通知・確認を行う。

目的

範囲

現在 9つのパイプライン（＋1つ設計中）で構成される。

パイプライン ひとことで言うと 状態 頻度
accounting 経費を自動仕訳してMFクラウドに登録 稼働中 月次
invoice MFクラウドの請求書を確定しPDFを取得 稼働中 月次
tfhd TFHD案件の月次報告・請求の一連フロー 稼働中 月次
mnml MNML委託先の請求書受領・支払い管理 稼働中 月次
mail_filing メール添付ファイルを自動で振り分け・保管 稼働中 日次
work_report カレンダーから月次作業報告書(Excel)を生成 稼働中 月次
scheduler カレンダーの空き時間を検索・会議を設定 稼働中 随時
news_reminder AI・金融ニュースの巡回と通知 稼働中 日次
contract 契約情報の一元管理（顧客・委託先） 設計中 随時

2. パイプライン一覧と要件

2.1 accounting — 経費自動仕訳・登録

やること：MFクラウド経費から連携明細を取得し、ルールに基づいて勘定科目を自動判定。LLMによる推定も併用し、最終的にMFクラウドに登録する。

項目内容
処理の流れスクレイピング → ルール適用 → LLM推定 → 手動調整 → 登録 → レポート生成
外部サービスMFクラウド経費（OAuth2 + Playwright）、Amazon API
入力MFクラウド連携明細、Amazon注文履歴
出力仕訳結果CSV、登録済みID、HTML月次レポート
データops/accounting/data/rules.csv（仕訳ルール）、expenses/YYYYMM/（月別作業データ）
トリガー月次（第2金曜）、手動CLI
CEOの関与手動調整の確認、登録前の最終承認

要件

2.2 invoice — 請求書確定・PDF取得

やること：MFクラウド請求書APIで当月の下書きを確定し、PDFをダウンロードして保管する。

項目内容
処理の流れ状態確認 → 一覧取得 → 下書き確定 → PDF取得・保存
外部サービスMFクラウド請求書API（OAuth2 + PKCE）
入力MFクラウドの下書き状態請求書
出力確定済みPDF（data/invoices/YYYYMM/）
トリガー月次（第3金曜頃）、手動CLI
CEOの関与なし（自動処理）

要件

2.3 tfhd — TFHD月次報告・請求フロー

やること：TFHD向けコンサル案件の月次業務を一貫して自動化する。メール受領確認からお礼返信、作業報告書生成、請求書PDF取得、納品メール下書きまで6ステップで処理する。

項目内容
処理の流れ対象者特定 → 受領確認 → お礼返信 → 報告書作成 → 請求書取得 → メール下書き → CEO送信
外部サービスOutlook（メール/カレンダー）、SharePoint、MFクラウド請求書API、Slack
入力委託先からのメール（報告書・請求書）、カレンダーイベント
出力お礼メール送信、作業報告書Excel、請求書PDF、TFHD宛メール下書き
トリガー月初（手動CLI / ステップ連鎖）
CEOの関与報告書内容の確認（約3分）、納品メールの送信（約2分） = 合計約5分/月

※ 詳細は 第6章「TFHD月次フローの詳細」を参照。

2.4 mnml — MNML委託先の請求書管理

やること：MNML自社案件の委託先（森屋、小川さとこ、Josh等）から届く請求書を受領・保管し、支払い通知をSlackに送る。

項目内容
処理の流れメール受領チェック → SharePoint保管 → お礼返信 → 支払い通知
外部サービスOutlook（メール）、SharePoint、Slack
入力委託先からのメール（請求書添付）
出力SharePointへの保管、Slack支払い通知
データtfhd/app/data/targets.jsonのclient="MNML"エントリ、mail_filing/data/received_YYYYMM.json
トリガー月次、手動CLI
CEOの関与なし（通知を確認するのみ）

要件

2.5 mail_filing — メール自動振り分け

やること：Outlookの受信メールから添付ファイルを自動取得し、ルールに従ってSharePointの各フォルダに振り分ける。処理結果をSlackのダイジェストで通知する。

項目内容
処理の流れメール取得 → 添付ファイル保存 → 振り分け → 既読化 → ダイジェスト通知
外部サービスOutlook（MS Graph）、SharePoint、Slack、Playwright（ブラウザ取得型）
入力Outlook受信メール
出力SharePointの各フォルダへのファイル配置、Slackダイジェスト
データdata/rules.json（振り分けルール）、data/processed.json（処理済みID）
トリガー日次（毎朝8時）、手動CLI
CEOの関与なし（ダイジェストを確認するのみ）

要件

2.6 work_report — 月次作業報告書

やること：OutlookカレンダーからCEO（内山）の月間イベントを取得し、作業報告書（Excel）を自動生成する。

項目内容
処理の流れカレンダーイベント取得 → キーワード分類 → Excel生成
外部サービスOutlook カレンダー（MS Graph）、SharePoint（保存先）
入力Outlookカレンダーイベント
出力Excel（作業報告書_YYYYMM_TFHD_合同会社MNML_内山.xlsx）
データdata/keywords.json（カテゴリ分類ルール）、data/events_YYYYMM.json（キャッシュ）
トリガー月次（第3金曜頃）、手動CLI
CEOの関与報告書内容の確認（カレンダーが正しく反映されているか）

要件

2.7 scheduler — 予定調整

やること：Outlookカレンダーの空き時間を検索し、相手との共通空き時間を見つけ、会議を設定する。

項目内容
機能空き時間抽出、相手との共通空き時間検索、カレンダー直接登録
外部サービスOutlook カレンダー（MS Graph）
トリガー随時（手動CLI）
CEOの関与調整依頼時のみ

要件

2.8 news_reminder — ニュース巡回

やること：AI・金融分野のニュースを11のソースから自動巡回し、関連度をLLMで評価してSlackに通知する。重要な技術トピックはGitHub Issueに自動起票する。

項目内容
処理の流れRSS/API巡回 → LLM評価（Haiku） → Slack通知 / Issue起票
外部サービスRSS/arXiv/Hacker News、Anthropic Haiku、GitHub API、Slack
入力11ニュースソース（primary 7 + secondary 4）
出力Slack #news-reminder への通知、GitHub Issue
データdata/sources.json、data/scanned.json（処理済み追跡）、data/holdings.json（保有銘柄）
トリガー日次（毎朝7時 + 8時/12時/18時）、手動CLI
CEOの関与なし（通知を確認するのみ）

要件

2.9 contract — 契約管理 設計中

やること：顧客（売上側）と委託先（仕入側）の契約情報を一元管理する。契約期間の管理、更新通知、金額照合の基盤となるマスターデータを提供する。

項目内容
機能契約一覧・詳細表示、契約追加、期限チェック・通知
外部サービスSlack（通知）、SharePoint（将来：契約書PDF保管）
入力CEO手入力（初期データ）、将来的にSharePoint自動連携
出力JSON（ops/contract/app/data/contracts.json）、Slack通知
トリガー随時（CLI）、定期チェック（将来）
CEOの関与初期データ投入、契約追加時

※ 詳細は 第7章「契約管理パイプラインの位置づけ」を参照。

3. システムフロー図

全パイプラインの関係性、外部サービス連携、データの流れを俯瞰する図。

外部サービス MFクラウド 経費 / 請求書 Outlook メール / カレンダー SharePoint ファイル保管 Slack 通知・確認 GitHub Issue管理 RSS / arXiv ニュースソース Amazon 注文履歴 Anthropic LLM Haiku / Claude ops/shared — 共通基盤（OAuth認証・Slack通知・MS Graph API） パイプライン 月次業務 accounting 経費自動仕訳・登録 第2金曜 invoice 請求書確定・PDF取得 第3金曜頃 work_report 作業報告書(Excel) 第3金曜頃 tfhd — TFHD月次フロー 受領確認 → お礼 → 報告書 → 請求書 → 下書き → CEO送信 invoice / work_report / mail_filing を統合的に呼び出す 月初（ステップ連鎖実行） mnml MNML委託先の請求書受領・支払い管理 月次 contract（設計中） 契約マスターデータ管理 将来: 全パイプラインのマスター参照先 日次 / 随時 mail_filing メール自動振り分け 毎朝8時 news_reminder ニュース巡回 毎朝7時 + 3回/日 scheduler 予定調整 随時（手動） Step4 Step3 Step1 受領状態 受領状態共有 将来: 契約情報参照 Slack → CEO（確認・承認） 凡例 パイプライン = 稼働中 設計中 = 未実装 統合 = 他パイプラインを呼び出す パイプライン間の呼び出し 将来の連携（設計中） 外部サービスへの接続 データの流れ: 外部サービスから取得したデータは、ops/shared の共通基盤を経由して各パイプラインに届く。 tfhd は invoice / work_report / mail_filing を統合的に呼び出し、TFHD案件の月次フローを一貫して実行する。

4. パイプライン間の依存関係

どのパイプラインが何を参照しているか、データがどう流れるかを整理する。

4.1 依存関係マトリクス

呼び出す側 ↓ / 呼ばれる側 → shared invoice work_report mail_filing contract
accounting OAuth, Slack————
invoice OAuth————
tfhd OAuth, Slack, GraphStep4: PDF取得Step3: Excel生成Step1: 受領状態将来: 契約参照
mnml Graph, Slack——受領状態共有将来: 契約参照
mail_filing Graph, Slack————
work_report Graph, OAuth————
scheduler Graph, OAuth————
news_reminder Slack————
contract Slack————

4.2 共有データファイル

データファイル 場所 書き込む側 読み込む側
受領状態 mail_filing/data/received_YYYYMM.json mail_filing, tfhd tfhd, mnml
対象者リスト tfhd/app/data/targets.json CEO（手動） tfhd, mnml
振り分けルール mail_filing/data/rules.json CEO（手動） mail_filing
契約マスター contract/app/data/contracts.json CEO（手動）→ contract CLI 将来: tfhd, invoice, mnml
DocID台帳 tfhd/app/data/docid_ledger.json tfhd tfhd
ステップ実行状態 tfhd/app/data/step_state_YYYYMM.json tfhd tfhd

4.3 データフローの概要

入口（外部 → ops）

出口（ops → 外部）

5. 月次業務タイムライン

いつ何が動くかの全体スケジュール。

毎日
7:00 — news_reminder: AIニュース巡回（1回目）
8:00 — mail_filing: メール添付ファイル振り分け / news_reminder（2回目）
12:00 — news_reminder: 巡回（3回目）
18:00 — news_reminder: 巡回（4回目）
月初
(1日〜)
tfhd Step 0 — 対象者の特定（契約フォルダから稼働中の委託先を抽出）
tfhd Step 1 — 委託先からのメール受領を確認（mail_filing経由）
tfhd Step 2 — お礼メールの自動返信
mnml — MNML委託先の請求書受領チェック・お礼・支払い通知
月初〜中旬
tfhd Step 3 — CEO作業報告書(Excel)生成 → CEO確認（約3分）
※ デュアルトリガー: Step 2完了 or 月の最終月曜（どちらか早い方）
第2金曜
accounting — MFクラウド経費の自動仕訳・登録
第3金曜頃
invoice — MFクラウド請求書の確定・PDF取得
work_report — 月次作業報告書(Excel)の単独実行（tfhd以外の案件用）
tfhd Step 4 — MFクラウド請求書のワークフロー状態確認・PDF取得
※ WF未完了の場合は1時間間隔でリトライ（最大24時間）
月末頃
tfhd Step 5 — TFHD宛の納品メール下書き作成（全添付ファイル集約）
tfhd Step 6 — CEO確認 → 送信（約2分）
contract check（将来）— 契約期限チェック・更新通知
随時
scheduler — 空き時間検索・会議設定（CEOの依頼時）
contract（将来）— 契約の追加・照会
CEOが実際に手を動かすのは月間で約5〜10分。 tfhd Step 3の報告書確認（約3分）、Step 6のメール送信（約2分）、accounting登録前の確認が主な作業。

6. TFHD月次フローの詳細

TFHD案件の月次業務フロー。6ステップ（＋Step 0）で構成され、他パイプラインを統合的に呼び出す。

6.1 ステップ一覧

ステップ 内容 自動化 利用するパイプライン 開発状況
Step 0 対象者特定 — SharePoint契約フォルダから稼働中の委託先を動的に抽出 全自動 —（SP直接走査） 未実装
Step 1 受領・振り分け — 委託先からの作業報告書・請求書メールを検知し、SharePointへ配置 全自動 mail_filing 稼働中
Step 2 お礼返信 — 受領確認後、定型文でお礼メールを自動送信 全自動 —（Graph Mail直接） 一部実装
Step 3 作業報告書 — CEO（内山）の作業報告書をExcel生成。CEOが内容を確認 半自動 work_report 稼働中
Step 4 請求書取得 — MFクラウドのWF状態を確認し、完了後にPDFを取得 全自動 invoice 一部実装
Step 5 メール下書き — TFHD宛の納品メールを下書き。全成果物を添付 全自動 —（Graph Mail直接） 一部実装
Step 6 CEO送信 — CEOがメール内容を確認し、手動で送信ボタンを押す 手動 — 稼働中

6.2 フロー図

Step 0: 対象者特定 SP契約フォルダ走査 Step 1: 受領・振り分け mail_filing が自動処理 Step 2: お礼返信 全自動送信（定型文） デュアルトリガー: Step 2完了 or 最終月曜 Step 3: 作業報告書 work_report → CEO確認 CEO Step 4: 請求書PDF取得 invoice パイプライン WF? 完了 未完了 1h間隔リトライ 最大24h Step 1 + Step 3 + Step 4 全完了で次へ Step 5: メール下書き 全成果物を添付 Step 6: CEO送信 手動（Outlookで送信ボタン） CEO Step 5 で集約する添付ファイル: 1. MNML作業報告書Excel（Step 3） 2. MNML請求書PDF（Step 4） 3. 委託先A 作業報告書（Step 1） 4. 委託先A 請求書（Step 1） 5. 委託先B 作業報告書（Step 1） ... × N人分（Step 0で動的に決定） 全自動 半自動/手動 未実装 判断分岐 CEO確認

6.3 Step 0: 動的な対象者特定

現在はtargets.jsonにハードコードされた委託先リストを参照している。将来はcontractパイプラインのcontracts.jsonを参照し、契約期間内の委託先を自動的に抽出する。

6.4 自動送信の判断基準

ステップメールの性質判断理由
Step 2（お礼） 社内的な定型挨拶 全自動送信 テンプレート固定、リスクなし
Step 5→6（納品） 外部顧客（TFHD）宛 CEO確認後に手動送信 顧客向けは内容が月ごとに変わりうる

6.5 MNML業務委託フローの詳細

MNML自社案件の委託先（森屋、小川さとこ、Josh等）からの請求書受領・保管・支払い通知フロー。 委託先ごとに処理差異があり、全員の請求書が揃った時点で支払い一括通知を行う。

6.5.1 ステップ一覧

ステップ 内容 自動化 利用するパイプライン
Step A 対象者特定 — targets.jsonのclient="MNML"エントリから稼働中の委託先を抽出 全自動 —（targets.json直接参照）
Step B メール受領チェック — 各委託先から請求書メールが届いているか確認 全自動 mail_filing（受領状態ファイル参照）
Step C SharePoint保管 — 請求書添付ファイルを委託先別フォルダに配置 全自動 mail_filing（振り分けルール適用）
Step D お礼返信 — 受領確認後、委託先へ定型お礼メールを自動送信 全自動 —（Graph Mail直接）
Step E 全員揃いチェック — 全委託先の請求書が受領済みか判定 全自動 —（received_YYYYMM.json照合）
Step F 金額照合 — 各請求書の金額が契約金額（contracts.json / targets.json）と一致するか検証 半自動 contract（将来）
Step G 支払い一括通知 — Slack #bo-notification に全委託先分の支払い一覧を投稿 全自動 —（Slack通知）

6.5.2 フロー図

MNML業務委託 — 請求書受領・支払い通知フロー Step A: 対象者特定 targets.json (client=MNML) Step B: メール受領チェック mail_filing 受領状態参照 委託先ごとの並行処理（各委託先に対して Step C → D を実行） 森屋 — 請求書メール Step C: SharePoint保管 /10_Corporate/accounting/40_仕入れ請求/森屋/ Step D: お礼返信 定型メール自動送信 小川さとこ — 請求書 Step C: SharePoint保管 /10_Corporate/accounting/40_仕入れ請求/小川/ Step D: お礼返信 定型メール自動送信 委託先N — 請求書 Step C: SharePoint保管 委託先名ごとのフォルダ Step D: お礼返信 定型メール自動送信 Step E 全員揃い? 未受領あり → 翌日再チェック 翌日 mail_filing 再確認 全員OK Step F: 金額照合 請求額 vs 契約金額 不一致の場合: Slack警告 → CEO確認 Step G: 支払い一括通知 Slack #bo-notification 通知内容: • 委託先名 / 請求金額 / 受領日 の一覧 • 合計支払い金額 • 金額不一致があった場合はその旨を注記

6.5.3 委託先ごとの処理差異

委託先 請求書の届き方 SharePoint保管先 金額照合の基準
森屋 メール添付（PDF） /10_Corporate/accounting/40_仕入れ請求/森屋/ targets.json の月額（将来: contracts.json）
小川さとこ メール添付（PDF） /10_Corporate/accounting/40_仕入れ請求/小川/ targets.json の月額（将来: contracts.json）
Josh メール添付（PDF / Invoice） /10_Corporate/accounting/40_仕入れ請求/Josh/ targets.json の月額（将来: contracts.json）
（新規委託先） targets.jsonに追加時点で自動認識 委託先名でフォルダ自動生成 同上

6.5.4 「全員揃ったら一括通知」のロジック

判定基準: targets.jsonのclient="MNML"全エントリに対し、 received_YYYYMM.jsonで受領済みフラグが立っていること。

冪等性: 一括通知は月に1回のみ発行。step_state_YYYYMM.jsonに mnml_payment_notified: trueを記録し、二重通知を防ぐ。

6.5.5 TFHDフローとの違い

項目TFHDフローMNMLフロー
作業報告書 CEOの報告書をExcel自動生成（Step 3） なし（委託先から受領するのみ）
請求書 MFクラウドからPDF取得（Step 4） 委託先からメールで受領
納品メール TFHD宛に下書き → CEO送信（Step 5-6） なし（支払い通知のみ）
金額照合 MFクラウドWF確認 受領請求額 vs 契約金額の突合
支払い通知 なし（MNMLが請求する側） 全員分を一括でSlack通知
CEO関与 報告書確認 + メール送信（約5分） 通知確認のみ（金額不一致時のみ対応）

7. 契約管理パイプラインの位置づけ

7.1 なぜ必要か

現在、契約に関する情報は複数箇所に分散している:

これを1つのJSONファイルに集約し、全パイプラインが参照できるマスターデータにする。

7.2 データモデル

フィールド型説明
idstr一意のID（C=顧客, S=委託先。例: C001, S001）
type"sales" | "purchase"顧客契約（売上）か委託先契約（仕入）か
counterpartystr相手先の名前（会社名または個人名）
vdulist[str]関連するVDU（事業単位）のリスト
amountint月額金額（税抜、円、整数）
period_startdate契約開始日
period_enddate契約終了日
status"active" | "expired" | "terminated"契約状態
payment_cyclestr支払いサイクル（例: "monthly"）
report_due_dayint | null報告書の提出期限日（1〜31）
sharepoint_pathstr | nullSharePoint上の契約書保管パス
invoice_folderstr | null請求書の保管フォルダパス
notesstr | null備考

7.3 他パイプラインとの統合計画

フェーズ内容影響範囲
Phase 1（今） contracts.jsonを新規作成。targets.jsonは残して共存する。
targets.jsonにcontract_idフィールドを追加し、相互参照可能にする。 		contract（新規）、tfhd（targets.jsonに項目追加のみ）
Phase 2（将来） 名前・メール・SharePointパスなどの重複情報をcontracts.jsonに一本化。
targets.jsonからは重複項目を削除し、contract_idで参照する。 		tfhd, mnml（contracts.jsonを参照するよう変更）
Phase 3（将来） targets.jsonをrecipients.jsonに改名し、メール送信先の情報のみに限定。
契約情報は完全にcontractsから参照する。 		tfhd, mnml, invoice

7.4 提供する関数（他パイプライン向けAPI）

関数用途利用パイプライン
get_active_contracts(type, vdu)稼働中の契約を条件付きで取得tfhd（Step 0）、mnml
get_monthly_amount(counterparty)相手先の月額金額を取得tfhd、invoice（金額照合）
get_contract_by_id(id)ID指定で契約詳細を取得全パイプライン
get_contracts_by_vdu(vdu)VDU単位で契約を一覧invoice（VDU別集計）

7.5 SharePointの保管ルール

保管先: SharePoint → 10_Corporate/contracts/

既存の30_VDU/consulting/20_suppliers/はレガシーとして残す。新規契約書は上記パスに配置する。

8. データモデル

各パイプラインの主要なデータ構造を一覧する。

8.1 targets.json（tfhd/mnml共有）

委託先・TFHD側メンバーの情報を管理する。場所: ops/tfhd/app/data/targets.json

フィールド型説明
namestr名前
emailstrメールアドレス
clientstr"TFHD" or "MNML"
rolestr"to"（TFHD送信先）/ ""（委託先）
contract_idstr | nullcontracts.jsonへの参照（Phase 1で追加予定）

例: 根崎（委託先）、西出（TFHD側 to）、森屋（MNML委託先）

8.2 rules.json（mail_filing）

メール振り分けルール。場所: ops/mail_filing/data/rules.json

フィールド型説明
namestrルール名
senderstr送信者フィルタ（メールアドレス or ドメイン）
filename_patternstrファイル名の正規表現フィルタ
destinationstr一時保存先パス
distributearray正式保存先のマッピング（pattern → dest）
enabledboolルールの有効/無効
typestr"standard" or "catch"（ブラウザ取得型）

8.3 rules.csv（accounting）

経費の自動仕訳ルール。場所: ops/accounting/data/rules.csv

フィールド説明
支払先パターン正規表現で支払先名をマッチ
勘定科目マッチ時に適用する科目
優先度複数ルールがマッチした場合の優先順
確認要否自動登録可 or 手動確認必要

8.4 sources.json（news_reminder）

ニュース巡回ソース。場所: ops/news_reminder/data/sources.json

フィールド型説明
namestrソース名
urlstrRSS/APIのURL
typestr"rss" / "arxiv_api" / "hn_api"
tierstr"primary"（高信頼）/ "secondary"（要裏取り）
categorystr"ai" / "geopolitical"

合計11ソース（primary 7、secondary 4）。

8.5 step_state_YYYYMM.json（tfhd）

月次フローの各ステップ実行状態。場所: ops/tfhd/app/data/step_state_YYYYMM.json

フィールド型説明
step1〜step6"pending" | "completed"各ステップの実行状態
year_monthstr対象年月（YYYYMM）

冪等性の保証: 完了済みステップはスキップされる。

8.6 docid_ledger.json（tfhd）

成果物のDocID採番履歴。場所: ops/tfhd/app/data/docid_ledger.json

報告書や納品物に一意のDocIDを付与し、SharePoint上のファイルと紐づける。

9. 外部サービス連携

サービス 認証方式 利用パイプライン 用途
MFクラウド経費 OAuth2 + Playwright accounting 連携明細スクレイピング、仕訳登録
MFクラウド請求書 OAuth2 + PKCE invoice, tfhd 請求書確定、PDF取得
Outlook メール MS Graph OAuth2 mail_filing, tfhd, mnml メール受信・送信・下書き作成
Outlook カレンダー MS Graph OAuth2 work_report, scheduler, tfhd イベント取得・作成
SharePoint MS Graph OAuth2 tfhd, work_report, mail_filing, mnml, contract（将来） ファイル保存・配置
Slack Bot Token 全パイプライン 通知・ダイジェスト・確認
GitHub Token news_reminder Issue自動起票
RSS / arXiv / Hacker News なし（公開API） news_reminder ニュース取得
Amazon API Keys accounting 注文履歴取得（経費突合）
Anthropic LLM API Key / CLI accounting, news_reminder, mail_filing, tfhd 分類推定・評価・解釈

OAuth認証のポート割り当て

ポートパイプライン対象サービス
8585accountingMFクラウド経費
8586invoiceMFクラウド請求書
8787work_report / mail_filing / schedulerMS Graph（共有ポート、同時実行不可）

10. 共通基盤（shared）

ops/shared/ は全パイプラインが利用する共通ユーティリティを提供する。

モジュール機能利用者
notify.py Slack通知（Bot Token方式）。デフォルト投稿先は #bo-notification 全パイプライン
oauth.py OAuth2トークン管理の基底クラス。トークン永続化（JSON）、自動リフレッシュ、リトライ accounting, invoice, work_report, mail_filing, scheduler
ms_graph/client.py MS Graph APIクライアント。カレンダーイベント取得・作成、Rate limit対応 work_report, scheduler, tfhd, mail_filing, mnml
ms_graph/models.py CalendarEvent等のデータモデル work_report, scheduler
graph_retry.py Graph API用リトライ管理（exponential backoff） ms_graph利用の全パイプライン

11. 安全性・冪等性の設計

11.1 破壊的操作（不可逆なもの）

パイプライン操作安全装置
accounting register（MFクラウドに仕訳登録） --dry-runで事前確認、registered_ids.csvで二重登録防止
accounting cleanup（連携明細削除） --dry-runで事前確認
invoice confirm（下書き→確定） --dry-runで事前確認、確定済みスキップ
tfhd Step 2 お礼メール自動送信 受領確認済みの場合のみ送信、テンプレート固定

11.2 冪等性の仕組み

仕組みパイプライン内容
処理済みID追跡 mail_filing, news_reminder, accounting 処理済みメッセージ/記事/明細のIDをJSONファイルで追跡。同じ対象は2回処理しない
受領状態ファイル tfhd, mnml received_YYYYMM.jsonで月ごとの受領状態を管理。確認済みはスキップ
ステップ実行状態 tfhd step_state_YYYYMM.jsonで各ステップの完了を記録。完了済みはスキップ
イベントキャッシュ work_report events_YYYYMM.jsonでAPI取得結果をキャッシュ。2回目以降はAPI不要
dry-runオプション 全パイプライン --dry-runで実際の変更を加えずに結果をプレビュー可能

11.3 エラー時の挙動

ops統合設計書 — Issue #161 | 2026-04-06 作成 | 合同会社MNML