n8n・freee・Slackを連携した経費申請通知の自動化は、freee側の通知・API仕様とn8nのトリガー方式を確認したうえで設計すれば、実務に組み込める現実的な選択肢です。ただし「申請された瞬間に必ず通知する」構成は、freeeのWebhook仕様やAPIの制約に依存します。本記事では、通知の起点をどこに置くか、重複通知をどう防ぐか、失敗時に誰がどう気づくかという実務判断を中心に整理します。料金・API仕様・画面は変更されるため、設計前に必ずfreeeおよびn8nの公式ドキュメントで最新情報を確認してください。
なぜ経費申請の通知自動化が検討されるのか
中小企業の経理では、経費申請の承認待ちが滞留し、月末に集中するという課題が起きやすい構造があります。申請者・承認者・経理担当が別々のツールを見ていると、「申請したのに承認されていない」「承認したつもりで経理に届いていない」という認識のずれが発生します。
Slack通知を挟む狙いは、承認アクションそのものを置き換えることではなく、見落としを減らすことにあります。freeeが申請・承認の正となるデータを持ち、Slackは気づきのきっかけ、n8nはその橋渡しという役割分担です。この分担を崩すと、二重管理や通知の取りこぼしが起きます。
通知の起点を決める：3つの方式の比較
最初に決めるべきは「何をきっかけにn8nを動かすか」です。方式によって、リアルタイム性・実装難易度・障害時の挙動が変わります。
| 方式 | 仕組み | 向くケース | 注意点 |
|---|---|---|---|
| Webhook方式 | freee側のイベント発生時にn8nへ通知 | 即時性を重視したい場合 | freeeのWebhook対応範囲・再送仕様を公式で確認する必要がある |
| 定期実行（ポーリング）方式 | n8nのScheduleトリガーで定期的にfreee APIを照会 | 即時性より確実性を優先する場合 | 実行間隔の分だけ遅延する。API利用制限に配慮 |
| 手動・半自動方式 | 担当者がn8nを実行、またはSlackから起動 | 件数が少なく検証段階の場合 | 運用負荷は残るが、まず挙動を確認しやすい |
編集部の検討メモとしても、最初からWebhook方式に固定せず、まずポーリング方式で通知内容と重複防止の設計を固め、その後Webhookへ移行する順序が安全です。Webhookはfreeeの対応イベントやペイロードの仕様確認が前提になります。
n8nワークフローの基本構成
構成は大きく4段階です。以下は一般的な設計パターンであり、実際のノード名・パラメータはn8nの公式ドキュメントで確認してください。
1. トリガー
WebhookトリガーまたはScheduleトリガーを配置します。Webhookの場合は受信データに検証用の情報が含まれるか、署名検証が必要かをfreee側の仕様で確認します。
2. データ取得・整形
freee APIから経費申請の情報を取得し、Slack通知に必要な項目（申請者、金額、申請日、承認状況、該当URLなど）だけを抽出します。APIのレスポンス構造は変更されうるため、項目名を決め打ちしすぎず、欠損時の分岐を用意します。
3. 重複防止
同じ申請に対して何度も通知が飛ぶのを防ぐため、申請IDなどの一意なキーを記録し、既通知かどうかを判定するステップを入れます。n8n内のデータストアや外部の簡易DBを利用する構成が考えられますが、保存先の選定はセキュリティと運用負荷の両面で判断してください。
4. Slack通知
SlackのIncoming WebhookまたはSlackノードで投稿します。通知先チャンネルは承認者用・経理用で分けると、情報過多を防げます。メンションの付けすぎは通知疲れを招くため、本当に必要な相手に限定します。
重複防止と失敗時の確認をどう設計するか
自動化で最も多い失敗は「動かないこと」より「動いたことに気づかないこと」です。次のチェックリストで設計を見直してください。
- 一意キー（申請ID等）で既通知を判定しているか
- 通知に失敗した場合、n8nの実行履歴で確認できるか
- エラー時にSlackの別チャンネルや担当者へアラートを送る設計か
- APIの一時的な失敗に対する再試行回数・間隔を決めているか
- 通知内容にfreeeの該当画面へ遷移できる情報を含めているか
- 休日・締め日など通知を止めたい時間帯を定義しているか
特に再試行は、無限に繰り返すと重複通知の原因になります。再試行回数の上限と、上限到達時の通知先を必ず決めてください。また、n8nの実行ログの保存期間はプランや設定に依存するため、障害調査に必要な期間を公式情報で確認しておきます。
導入前に確認しておきたい公式情報
本記事では具体的な料金・APIエンドポイント・画面操作を断定していません。設計を進める前に、次の情報を公式ページで確認し、確認日を社内に記録してください。
- freeeのAPIが経費申請のどの情報を提供しているか、Webhookの対応イベントと再送仕様
- freeeのAPI利用に関する制限や認証方式
- n8nのトリガー種別ごとの挙動、実行ログの保存、エラーハンドリング機能
- Slack連携の認証方式と投稿先の管理方法
- 各サービスの利用規約・データの取り扱いに関する記載
これらは改定される可能性があります。導入判断の根拠として、担当者が公式情報を確認した日付と参照URLを残す運用を推奨します。
よくあるつまずきと回避の考え方
通知が多すぎる：申請1件ごとに全承認者へ通知すると疲弊します。金額閾値や部署で通知先を分ける、ダイジェスト化するなどの調整を検討します。
承認済みなのに通知が来る：状態の取得タイミングと判定条件のずれが原因になりえます。ステータス判定の条件を明確にし、テスト用の申請で確認します。
誰も監視していない：自動化は放置すると静かに壊れます。週次で実行履歴を確認する担当と頻度を決め、チェックリスト化しておくと安心です。
まずは少額・少件数の範囲で試験運用し、通知内容と重複防止が意図通りか確認してから対象を広げてください。無理に全社展開せず、段階的に拡大する方が結果的に定着します。
設計の詳細は各社の公式ドキュメントを確認し、必要に応じてベンダーや専門家に相談してください。本記事は個別の税務・法務判断や導入成果を保証するものではありません。
