■ 背景

GASのトリガーが増え、処理は連鎖して動くようになった。

一つの失敗が、全体に波及する。

既にGit帯域エラーも経験している。

⸻

意識は変わった。

「動く」から「安全に回る」へ。

■ 課題

• トリガーの分散
• 重複実行リスク
• 例外時の停止・未検知
• チェック層の不在

■ 方針

• 人間の確認を減らす
• 自動処理内に監査を組み込む
• 既存処理は壊さない

四之丞を「門番」として配置する。

■ 実装

トリガー整理

• runKirehashiInboxOnce → 廃止
• updateFukaLatestFromSheet に統合

親トリガー └ 子処理（切れ端）

暦処理の統合

• exportKoyomiLatestJson → 月次へ統合
• monthlyKita8Main の後段で実行

監査レイヤー

処理 → try → 本体 → catch → 四之丞（ログ）

try {
  runKirehashiInboxOnce();
} catch (e) {
  Logger.log("runKirehashiInboxOnce failed: " + e);
}

⸻

■ 構造の変化

Before

トリガー → 個別処理

After

トリガー → 親処理 → 子処理 → 四之丞

⸻

■ 効果 • トリガー削減 • 二重実行排除 • 例外耐性向上 • ログ追跡可能

⸻

■ 副作用 • 構造が一段深くなる • 把握コスト増 • デバッグ難度微増

⸻

■ 今後 • 通知連携（LINE / Slack） • 異常検知 • 九太郎連携

⸻

■ 結び

四之丞は機能ではない。 流れの中に差し込まれた“位置”である。