ユースケース別ワークフローUse Cases
ここまでの各ページで説明した仕組みは、実際の業務では互いに連携して動きます。松葉のサービス間の連携は、突き詰めると 3 つのパターンに整理できます。①「ファイルの到着」を合図に動く連携、②「発信箱に書き留めて後追いで届ける」連携、③「決まった時刻に動く」連携です。この 3 つで、主要な業務シナリオがすべて説明できます。
3 つの連携パターンと業務シナリオThree patterns
まず、システムの登場人物（サービス・部品）と、3 つの連携パターンの関係を 1 枚にまとめます。下の図は、利用者の操作（上段）から始まり、3 つのパターン ①②③ がそれぞれ別の「引き金」で動き出し、いずれも中央の共通の流通路（Pub/Sub）に集まることを示しています。これが 3 パターンの関係です。
関係の読み方: ①（到着が引き金）②（業務処理が引き金）③（時刻が引き金）は、動き出すきっかけが違うだけで、最終的にはどれも中央の Pub/Sub（共通の流通路）に集まり、受け取り側の冪等性（二重処理を防ぐ仕組み）の上で処理されます。たとえばファイルのアップロードでは、利用者 → 画面（web）→ API → 未検査バケットと進み、そこから ① が起動して検査・振り分けを行い、その結果が ② の流通に乗って Drive 同期や通知へ繋がります。次のページ以降で、各パターンを「利用シーン（こんなとき）」と「仕組み」の 2 段で詳しく見ていきます。
パターンと、それぞれが受け持つ業務シナリオの対応は次のとおりです。「状態」の欄に、土台のどこまでが実装済みかを正直に記しています。
| 業務シナリオ | 使う連携パターン | 状態 |
|---|---|---|
| ファイルのアップロード → ウイルス検査 | ① イベント連携駆動 | 連携・振り分けは実装済み。検査エンジンの接続は今後の実装 |
| Google Drive への同期 | ② 発信箱（Outbox）駆動の受信側 | 受け取りの骨格は実装済み。同期処理そのものは今後の実装 |
| 各種スケジュール処理（定期バッチ） | ③ スケジュール駆動 | 送り出し役は実装済み。個別の処理 17 種は今後の実装 |
| イベント連携経由のサービス実行 | ① イベント連携駆動（検査と同じ経路） | 連携の仕組みは実装済み |
パターン① 「到着」を合図に動くEvent-triggered
ファイルがストレージに到着したことを合図に、その後の処理を自動で起こすパターンです。代表例はウイルス検査。「ウイルス検査の連携」で扱った経路を、業務の流れとして見たものです。
こんなとき: 取引先（社外の担当者）が見積書や提案資料などをアップロードした瞬間に、このパターンが動きます。利用者は特別な操作をしません。検査が終わるまでファイルは一覧で「検査中」と表示されて開けず、安全と分かると利用可能になります。もし感染していれば自動で隔離され、管理者へ通知されます。下図はその裏側の仕組みです。
特徴: 「誰かが指示する」のではなく「状態の変化（到着）が引き金」になります。指示の取りこぼしが起きにくく、ストレージ側の仕組みが「届くまで再試行」してくれるのが利点です。
パターン② 発信箱に書き留めて、後追いで届けるOutbox-driven
業務処理の中で「あとで通知・同期したい」ことを、その場で送らず発信箱（Outbox）に書き留め、別の送り出し役が後追いで確実に届けるパターンです。仕組みの詳細は「イベント駆動の整合性」をご覧ください。
こんなとき: 社内の担当者が、取引先に資料フォルダの共有リンクを発行するときに、このパターンが動きます。「共有」を押すと画面はすぐ「発行しました」と返り、担当者は次の作業へ進めます。裏側では「受取人へ案内メールを送る」という指示が発信箱に書き留められ、送り出し役が後追いで（数十秒〜1 分ほどで）確実にメールを届けます。もしこの瞬間にメール基盤が一時的に不調でも、指示は発信箱に残るため取りこぼしません。ほかに「ウイルス検査が済んだファイルを Google Drive へ自動同期する」のも、このパターンの受け取り側です。
受け持つシナリオ: 「共有リンクを発行したら受取人へ案内メール」「ウイルス検査が済んだファイルを Google Drive へ同期」など、本処理の後に確実に届けたい連絡・同期がこのパターンです。Drive 同期は、この受け手側にあたります。
パターン③ 決まった時刻に動くSchedule-driven
毎日・毎週など、決まった時刻に自動で動く処理のパターンです。保持期間を過ぎたファイルの削除、ゴミ箱の整理、まとめ通知の配信などが該当します。これらは定期バッチ（matsuba-batch）に統合し、 1 つのジョブとして動かします。
こんなとき: このパターンは、ユーザが操作しなくても毎日決まった時刻に自動で動きます。たとえば、保持期間（既定 180 日）を過ぎたファイルを自動で削除してゴミ箱を整理したり、その日に溜まった更新を翌日 1 通のまとめ通知（ダイジェスト）として届けたりします。ユーザにとっては「気にしなくても裏側で片付いている」状態が保たれます。下図はその裏側の仕組みです。
到達点: 定期バッチの仕組みと、その中で動く送り出し役（前ページの dispatcher）を実装しました。保持期間切れの削除など他の 17 種は、処理を差し込む「枠」だけを用意した段階です。時刻起動の設定（Scheduler）自体は本資料の対象範囲外で、別途設定します。
3 つのパターンで業務を組み立てる: 松葉のこれからの業務機能は、ほぼすべてこの 3 パターンの組み合わせで実現できます。新しい機能を作るときも、「これはどのパターンか」を選ぶところから設計を始められるため、毎回ゼロから連携を考える必要がありません。3 パターンすべての土台を、本番で動く形まで用意しました。