Lark × 経理 SaaS(freee / マネーフォワード) 連携で実現する経理自動化 — API・Webhook の実装と運用

経理 SaaS と Lark の「分断」が起こす 4 つの症状

結論：経理 SaaS を入れただけでは経理は楽にならない。チャット・ファイル・承認のレイヤーが分断されていれば、月末ごとに「探す・聞く・転記する」作業が必ず復活する。

中小企業の経理が「クラウド化したのに楽にならない」と訴える時、原因の 8 割は経理 SaaS そのものの機能不足ではなく、経理 SaaS と社内コミュニケーション基盤の分断にあります。当社が中小 EC 事業者として自社業務を Lark に集約する過程で観察した分断症状は、おおむね次の 4 つに収束します。

症状 1: 給与明細・請求書ステータスがチャットで「口頭再現」される

freee 人事労務やマネーフォワード クラウド給与で給与計算は完了している。にもかかわらず、従業員から「給与明細はいつですか？」と毎月チャットで聞かれる。経理担当が口頭・テキストで「先ほど freee から配信したのでメールを確認してください」と返信する。月 30 名でこの会話が 1 人 5 分発生すれば、それだけで 150 分。1 年で 30 時間が「ステータスの口頭再現」に溶けています。

症状 2: 経理 SaaS にログインする人が経理 1 名に集中する

freee 会計のスタンダードプランは 3 ユーザーまでが基本料金に含まれ、追加ユーザーは経理／経営者相当が 1 人月額 300 円となります（freee 公式料金ページ参照、2026 年 6 月確認）。マネーフォワード クラウドのビジネスプランは 3〜5 名がサービスごとの基本枠で、追加は 300〜900 円／名となります（マネーフォワード公式価格ページ参照、2026 年 6 月確認）。1 人あたりは安いが、現場が見たいデータほど「経理しか開けない」状態になりがちで、結果として「経理に聞く」が常態化します。

症状 3: 承認・差し戻しがメールと紙のハイブリッドに退化する

freee やマネーフォワードにも申請・承認のワークフロー機能はありますが、経営者が日中チェックする画面が Outlook と Lark で、経理 SaaS は週 1 回しか開かない、というケースが多発します。すると「Lark で頼んでください」「メールで送り直してください」と通知先の二重化が起き、最終的に「やっぱり紙で持ってきて」に退化します。導入前より承認リードタイムが伸びる典型パターンです。

症状 4: マスタが SaaS ごとに二重・三重に持たれる

部署、プロジェクト、取引先、従業員 — これらのマスタが Lark の組織情報、freee の部門・取引先、マネーフォワードのプロジェクトコード、それぞれで別管理になっている。新規入社のたびに 3 か所更新が必要で、しかも誰かが必ず忘れる。マスタ不整合は仕訳ミス・経費精算遅延の温床であり、内部統制上のリスクでもあります。

当社が自社の EC 事業（前橋拠点）で行っている月次経理クローズの工数比較は、Lark に各種フックを集約する前は月 240 時間、Lark を中枢にした後は月 24 時間。90% 削減の大半は「経理 SaaS と Lark を分断させない」設計から生まれました。次章でその 4 つの実装パターンを順に解きほぐします。

連携の全体像 — 4 つの実装パターン

結論：Lark と経理 SaaS の連携は「公式ワンクリックコネクタ」ではなく、Open API・Webhook・Custom Bot・SSO を組み合わせた自前統合で組む。だからこそ「どのパターンを、どの順番で」入れるかが投資効率を決める。

Lark 公式ブログの「Lark と freee 会計の API 連携：効率的な組織管理と便利な給与明細の一元化と分析へ」（2023 年 7 月 7 日公開、藤本ジェイソン氏執筆）でも、freee API キーを取得して Lark 側でデータを取り込む手順が紹介されています（Lark 公式ブログ参照、2026 年 6 月確認）。裏を返せば、ワンクリックで完成する公式コネクタが用意されているわけではなく、各社の要件に合わせて API を組み立てる前提のサービスです。

この前提を踏まえ、当社では中小企業向けに次の 4 パターンを「下流から上流へ」順に導入することを推奨しています。下にいくほど実装難度と効果の双方が上がります。

パターン	主な構成要素	実装難度	直接効果
1. Webhook 通知	freee / MF イベント → Lark Custom Bot Webhook → 該当チャットへ自動投稿	低	問い合わせ削減・ステータス透明化
2. Base 同期	freee / MF API → ETL バッチ → Lark Base レコード upsert	中	全社的な可視化・ダッシュボード化
3. SSO	Lark を IdP 化（または Google/Microsoft の SAML を経由）→ 経理 SaaS にシングルサインオン	中	パスワード管理コスト削減・離職時の権限失効自動化
4. 承認連動	Lark 承認で起票 → Webhook → freee / MF API で本登録	高	承認リードタイム短縮・二重入力撲滅

この 4 パターンは「1 から 4 へ順番に積む」ことで投資回収が安定します。いきなり 4（承認連動）から作ろうとすると、組織マスタや会計コード設計が整わないまま自動化することになり、「自動化したエラー処理」を毎日デバッグする悪夢に陥ります。次章以降で各パターンの具体実装を順に解説します。

パターン 1: Custom Bot Webhook で給与明細・請求書通知を自動配信

結論：Lark の Custom Bot Webhook は最も導入コストが低く、最も投資回収が早い。給与明細・請求書発行・入金確認を即時通知するだけで、月初 1 週間の問い合わせが半減する。

Custom Bot Webhook の正体

Lark のグループチャットには、URL を 1 本叩くだけで投稿できる「Custom Bot」を設置できます。Webhook URL の形式は https://open.larksuite.com/open-apis/bot/v2/hook/[token] で、HTTPS POST で JSON ボディを送るだけです。Custom Bot にはキーワード一致・IP ホワイトリスト・署名検証の 3 種のセキュリティ設定を組み合わせられます（Lark Open Platform Custom bot usage guide 参照、2026 年 6 月確認）。

最小実装（curl 1 行）

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "msg_type": "text",
    "content": { "text": "【給与明細配信】2026/6 分の給与明細を freee 人事労務から配信しました。各自 freee アプリでご確認ください。質問は #経理-給与 チャンネルへ。" }
  }' \
  https://open.larksuite.com/open-apis/bot/v2/hook/xxxxxxxx

この 1 行を、freee や MF 側の「配信完了」イベントから呼び出すだけで、給与明細配信通知が自動化されます。経理担当が「配信完了をチャットで報告する」作業がそのままゼロになります。

freee / MF からのトリガリング戦略

freee と マネーフォワード クラウドは、いずれも「自動的に外部 Webhook を呼ぶ」ネイティブ機能を限定的にしか持ちません。そのため実務上は次の 3 経路のいずれかでトリガします。

1. 定時バッチ（推奨）: 毎日 9:00 と 17:00 に GitHub Actions / AWS EventBridge / Lark の自社サーバ常駐ジョブから freee / MF API を叩き、当日発生したイベント（給与明細配信完了、請求書発行、入金確認）を取得して Custom Bot に POST する。実装難度は最も低い。
2. 外部 iPaaS 経由: Zapier / Make / n8n のような iPaaS で「freee の新規請求書発行」イベントを契機に Webhook を発火させる。コードを書かずに済む反面、ランニング費用が発生する。30 名規模で月 3,000〜10,000 円程度を見込む必要がある。
3. RPA で freee / MF の画面遷移を監視: 緊急対応用。Lark Automate（Pro 以上）か社内 RPA から freee の「配信完了」画面を検知してフックする。仕様変更に弱く、長期運用にはおすすめしない。

当社の自社 EC 事業では (1) の定時バッチを Lark のサーバレス Workflow と GitHub Actions のハイブリッドで運用し、配信通知・入金通知・督促通知の 3 系統で月 38 時間の経理問い合わせ対応工数を消し去りました。月給ベースで概算 7 万円相当の人件費削減です。

サンプル: Python で freee 売上請求書を Lark に転送する 30 行

import os, requests, datetime

FREEE_TOKEN = os.environ["FREEE_TOKEN"]
COMPANY_ID  = os.environ["FREEE_COMPANY_ID"]
LARK_HOOK   = os.environ["LARK_WEBHOOK_URL"]
TODAY = datetime.date.today().isoformat()

# 1) freee API で本日発行の請求書を取得
res = requests.get(
    "https://api.freee.co.jp/api/1/invoices",
    headers={"Authorization": f"Bearer {FREEE_TOKEN}"},
    params={"company_id": COMPANY_ID, "issue_date_start": TODAY, "issue_date_end": TODAY},
    timeout=20,
)
invoices = res.json().get("invoices", [])

# 2) Lark Custom Bot に整形して送信
if not invoices:
    quit()
lines = [f"【本日発行の請求書 {len(invoices)} 件】"]
for inv in invoices:
    lines.append(f"・{inv['partner_name']} 様 ¥{inv['total_amount']:,} (#{inv['invoice_number']})")
payload = {"msg_type": "text", "content": {"text": "\n".join(lines)}}
requests.post(LARK_HOOK, json=payload, timeout=10)

このスクリプトを GitHub Actions の cron で 17:00 に走らせれば、毎日の請求書発行サマリが経理チャンネルに自動投稿されます。「今日いくら売れたか」を経営者がチャットの 1 タップで確認できる状態になり、業績可視化のサイクルが日次に短縮します。

パターン 2: 経理 SaaS データを Lark Base に定期同期する

結論：Lark Base は「経理 SaaS のサブセット」ではなく「経営者と現場の共通ダッシュボード」として使う。仕訳の原本は freee / MF に置き、Base には「全社員に見せていい粒度の集計」だけを同期するのが正解。

なぜ Lark Base に「再表示」するのか

経理 SaaS のダッシュボードは強力ですが、ライセンスの壁・専門用語の壁・モバイル UX の壁の 3 重バリアがあり、経営者と現場が日常的に開く場所にはなりにくいのが実態です。一方で Lark Base は次の特性を持ちます。

• 全社員に「閲覧」レベルのアクセスを安価に配れる（Lark Pro / Enterprise の同一ライセンス内）
• カンバン・ガント・カレンダー・グリッド・フォームをワンクリックで切り替えられる
• Lark チャット・Docs・カレンダーと相互リンク可能（経理データを承認チャットに引用できる）
• モバイルアプリ単独で閲覧・コメント・承認まで完結する

仕訳の原本（一次データ）は freee / MF に置いたまま、「全社員に見せていい集計（売上日次・経費月次・債権残高）」だけを Base に持ち込むのが堅実な設計です。Lark Base の各プランで扱える行数は、Starter プランが 2,000 行、Pro プランが 20,000 行、Enterprise プランが 50,000 行となります（Lark 公式プランページ参照、2026 年 6 月確認）。日次サマリであれば年間でも 365 行で済み、Starter プランでも十分機能します。

同期テーブル設計（5 表構成）

中小企業 50 名規模で当社が実装している標準セットは以下の 5 表です。

テーブル名	同期頻度	主な列	想定行数
日次売上サマリ	日次 17:00	日付・部門・売上額・件数・前年同日比	年 365 行
月次経費サマリ	日次 17:00	月・勘定科目・部門・金額・予算比	年 1,200 行
取引先マスタ	日次 9:00	取引先 ID・名称・与信枠・担当営業	通常 200〜800 行
未回収請求書	日次 17:00	請求書 No・取引先・期限・金額・経過日数	月 50〜300 行
給与配信ステータス	月次（配信日）	対象月・従業員ID・配信日時・閲覧フラグ	年 360〜1,200 行

upsert を成立させる主キー設計

Lark Base の同期で最も事故が多いのが、「同じレコードが日々重複追加されてしまう」問題です。回避するには Base 側のテーブルに「自然キー」になる列を 1 つ用意し、ETL バッチがその列で既存行を検索 → なければ create / あれば update（upsert）する設計を取ります。

具体的には、freee の請求書同期では freee_invoice_id を Base の単一行識別列にし、Lark Base API の検索エンドポイントで filter=CurrentValue.[freee_invoice_id]="{id}" でヒットさせます。1 件目はバッチ中 create、2 回目以降は update に分岐します。

Lark Base への upsert は CLI でも実装できます。たとえば lark-cli base +record-upsert --base-token xxx --table-id tbl... --record-id rec... --json '{"金額":1000000}' のように 1 行で書けるので、シェル中心の運用にも乗せやすいのが利点です。

パターン 3: SSO で経理 SaaS にもシングルサインオン

結論：SSO は「楽になる」よりも「離職時の権限失効が確実になる」効果のほうが大きい。中小企業の内部統制で最も穴が開きがちな「退職者の SaaS アカウント残置」を構造的に防ぐ。

Lark を IdP 化するか、Google / Microsoft を経由するか

Lark は IdP（ID プロバイダ）としての SAML / OAuth 連携にも対応しますが、中小企業の現実解としては「Lark で人事マスタを管理し、Google Workspace か Microsoft Entra ID を IdP として経理 SaaS に連携する」ハイブリッド構成のほうが安価で安定します。

freee は SAML 2.0 ベースの SSO に Enterprise プランで対応し、マネーフォワード クラウドも上位プランで SAML SSO を提供しています。Lark 側で「人事マスタの変更」を起点に Google Workspace / Microsoft Entra ID のユーザーを同期しておけば、退職処理を Lark だけで完結させても、freee / MF のアクセス権が 同日中に失効します。これは内部統制上の大きな差です。

中小企業の現実：パスワード共有を構造的に絶つ

SSO を入れる前の中小企業では、経理 SaaS のパスワードがチャットや付箋で共有され、退職後もそのパスワードが生き続けるのが常態です。SSO を経由しないログイン手段を全て無効化することで、「退職者の私的端末から残置アカウントが叩かれる」最悪シナリオを構造的に排除できます。SOC2 や ISMS の準備をする企業では避けて通れない論点です。

パターン 4: Lark 承認 → freee / MF 起票の連動

結論：4 つの中で最も難しいが、最も効く。経費精算・購買稟議・取引先登録の 3 ワークフローを Lark 起点で完結させると、経理工数の体感値が 4〜5 割減る。

3 つの典型ワークフロー

1. 経費精算: Lark 承認フォームに領収書写真と金額・科目を入力 → 上長承認 → 承認完了イベントで freee / MF の経費登録 API を呼ぶ。
2. 購買稟議: Lark 承認で見積書 PDF と支払予定日を申請 → 部長＋経営者の二段承認 → 承認完了で freee の取引（買掛）を自動起票。
3. 取引先登録: Lark フォームで新規取引先情報を申請 → 経理承認 → freee / MF の取引先マスタに自動登録。

実装の勘所：冪等性と「失敗時の手動再投入」

承認連動の Webhook は「ネットワーク瞬断で 1 件落ちる」を必ず想定します。freee / MF API への起票時に「同じ承認 ID で既に起票済か」を check してから create する冪等処理を入れ、失敗した場合は Lark Base の「再投入待ち」テーブルに自動退避させます。経理担当はその Base ビューを毎朝 3 分確認し、ボタンを押せば再投入が走る、という運用にします。

この「自動の 8 割＋手動の 2 割」設計が、中小企業の経理自動化を長期運用できる秘訣です。100% 自動を目指して例外を増やすと、半年でメンテ不能になります。境界をあえて残し、人間が最終判断する場所を明示するのが、Hegelian 止揚（Aufheben＝対立を保ちつつ次の段階へ）の哲学を屋号に持つ当社の一貫した設計思想です。

10 名 / 30 名 / 50 名 — 料金シミュレーション

結論：30 名規模で Lark Pro + freee スタンダード + マネーフォワード ビジネスの組み合わせを年払いで組むと、月額のソフトウェア費用は約 6.4 万円〜8.5 万円のレンジに収まる。これに対して削減できる経理工数は月 30〜80 時間が現実値。

代表的な 3 規模での料金を、各社の 2026 年 6 月時点の公式情報から組み立てます。為替・為替変動の影響を受けない円建てで、税抜表示に統一します。

10 名規模（社員 8〜10 名・経理 1 名）

ツール	プラン	月額（税抜）
Lark	Starter（10 名）	¥0
freee 会計	スターター 年払い	¥4,110〜（25% 割引適用）
またはマネーフォワード	ビジネス 年払い	¥6,480
合計目安	Lark Starter + 経理 SaaS	¥4,110〜¥6,480 / 月

Lark の 20 名以下無料枠を最大活用できるレンジ。10 名規模では SaaS 費用そのものが安く、削減できる人件費は月 10 時間程度が現実的なライン。投資回収というより、属人化解消と監査対応力の向上に意味がある。

30 名規模（社員 25〜30 名・経理 2 名）

ツール	プラン	月額（税抜）
Lark	Pro × 30 名 年払い	¥42,600
freee 会計	スタンダード 年払い	¥6,735〜（25% 割引適用）
freee 追加ユーザー	経理 / 経営者相当 × 2 名	¥600（@¥300×2）
またはマネーフォワード	ビジネス 年払い	¥6,480 + 追加 ¥300〜¥900／名
合計目安	Lark Pro + 経理 SaaS	¥49,935〜¥58,500 / 月

30 名は「分断を解いた効果が体感できる最初の規模」。当社の自社 EC 事業もこの規模で、Lark を中枢に経理 SaaS と HR をつないだ結果、月 240 時間→24 時間（90% 削減）を 4 か月で達成しています。SaaS 月 6 万円弱で人件費換算 30〜40 万円相当の経理工数を回収できる計算です。

50 名規模（社員 45〜50 名・経理 3 名）

ツール	プラン	月額（税抜）
Lark	Pro × 50 名 年払い	¥71,000
freee 会計	アドバンス 年払い	¥29,835〜（25% 割引適用）
freee 追加ユーザー	経理 / 経営者相当 × 3 名	¥3,000（@¥1,000×3）
合計目安	Lark Pro + freee Advance	¥103,835 / 月

50 名規模ではSSO（パターン 3）と承認連動（パターン 4）の効果が指数的に効いてくる。経費精算と請求書承認を Lark で完結させると、経理 3 名のうち 1 名は他業務に再配置できる、というのが当社の中小企業向け伴走支援の標準的な見立てです。

※価格は 2026 年 6 月時点の各社公式情報に基づきます。最新の正確な料金は各社の公式サイトでご確認ください：Lark、freee 会計、マネーフォワード クラウド。

実装の落とし穴 6 つと回避策

結論：技術的に動くことと、運用に乗ることは別の問題。中小企業の連携 PoC が頓挫する典型 6 パターンを先回りで潰す。

落とし穴 1: アクセストークンの期限切れを誰も検知できない

freee / MF / Lark のいずれも、API のアクセストークンは数十時間〜数日で期限切れになります。リフレッシュトークンの自動更新を組まずに本番運用すると、ある日突然「請求書通知が止まっている」状態が 1 週間続きます。回避策: トークン残日数を Lark Base に毎日記録し、残 3 日以下で経理チャンネルにアラートを Custom Bot で投げる「セルフ監視ジョブ」を最初に組みます。

落とし穴 2: API レート制限を読まないままバッチを書く

freee API には事業所単位での秒間・分間レート制限があります。マネーフォワード クラウド API も「事業者単位で利用回数無制限だが、システム負荷が高い場合は強制停止される可能性」が明記されています（マネーフォワード公式参照）。回避策: バックオフ（429 受信時に指数的に待つ）と並列度の上限を最初から組み込み、深夜の大量同期は禁じる運用ルールを文書化します。

落とし穴 3: 部署マスタの命名が SaaS ごとに違う

Lark では「営業 1 課」、freee では「営業1課」、マネーフォワードでは「Sales-1」と命名がバラバラ、というのが導入 2 年目の典型風景です。回避策: マスタ管理シートを Lark Base 内に 1 つ用意し、freee / MF への投入は必ずそのマスタからプログラム経由で行う。手動入力を禁止します。

落とし穴 4: Webhook のリトライが指数爆発する

Lark Custom Bot 側で何らかのエラーが返ったときに、freee / MF 側の自前バッチが「無限リトライ」してしまうケース。回避策: リトライは「最大 3 回・指数バックオフ」を厳守し、4 回目以降は Base の「failure queue」テーブルに自動退避させて経理担当のレビューに回します。

落とし穴 5: 通知過多で経理チャンネルが「ノイズ」と化す

最初は喜ばれた自動通知が、半年で「全部読まれないチャンネル」になる現象。回避策: 通知の粒度を「日次サマリ × 例外即時通知」の二段構成にし、サマリは午前 9 時と午後 5 時の 2 回だけに集約します。週次でクリック率を Base に記録し、20% を切ったら再設計します。

落とし穴 6: 「経理が抜けたらメンテ不能」の属人化

情シスがいない中小企業では、経理担当者が自力で API トークンを管理し、コードを書き、運用しているケースが少なくありません。回避策: コードは社内 Git（Lark Wiki + GitHub Private）に保管し、トークンは Lark Approval を経由した発行・更新フローに乗せます。当社のような外部パートナーを「副運用者」として位置付け、月 1 回のレビュー会で監査します。

30 日で立ち上げる導入ロードマップ

結論：4 パターン全部を一気にやらない。Week 1〜2 で Webhook 通知を稼働させて成功体験を作り、Week 3 で Base 同期、Week 4 で SSO 設計を始めるのが安全な投資回収カーブ。承認連動（パターン 4）は 60〜90 日目の課題に置く。

1. Day 1〜3: ヒアリングと優先順位確定。経理担当の月次タスクを 15 件以上洗い出し、上位 3 件に絞る。Lark Base に「経理タスク一覧」テーブルを作り、自動化対象に「目的」「想定削減時間」「データソース」を必ず明記。
2. Day 4〜7: freee / MF API キー取得・テスト。Lark Custom Bot を経理チャンネルに設置し、テストメッセージが届くことを確認。API トークンは Lark Wiki の「シークレット管理」ページに権限制御をかけて保存。
3. Day 8〜14: パターン 1（Webhook 通知）本番化。給与明細配信通知・日次売上サマリ・未回収請求書アラートの 3 系統を稼働。問い合わせ削減の数字を 2 週目の経営定例で報告する。
4. Day 15〜21: パターン 2（Base 同期）の最小セット。日次売上・月次経費・未回収請求書の 3 表を Base に同期。経営者と経理がモバイルアプリから常時参照する状態にする。
5. Day 22〜28: パターン 3（SSO）の設計と段階導入。退職者発生時の「Lark 1 アクション操作で全 SaaS が失効する」フローを確立。本番切替は週末メンテで実施。
6. Day 29〜30: 振り返りと次フェーズ計画。30 日間で削減できた工数を実測。承認連動（パターン 4）の対象ワークフローを 2〜3 個に絞り、60〜90 日目の課題として KPI 付きで再計画する。

よくある質問

関連記事

• Lark Base が中小企業の業務効率を変える 3 つの理由 — 業務 DB として Lark Base を選ぶ視点
• 中小 EC 事業者の Lark 活用 — 240h→24h と 90% 削減の現実 — 当社の自社実証データ
• Lark vs kintone どっちを選ぶべきか — 業務 DB 比較
• SaaS ポカリプス 2026 — 統合型へ移行すべき 5 つの理由 — SaaS 分断の経済学
• 中小企業 DX 失敗率 64% から学ぶ 5 ステップ — 自動化前の業務整理
• Lark 導入支援サービス詳細 — 当社の伴走プラン
• 無料ヒアリングのご予約 — 60 分で診断シートを提供

---

本サイトは アウフヘーベンジャパン株式会社 が運営しています。
Lark は ByteDance Ltd. の登録商標です。freee は freee 株式会社、マネーフォワード クラウドは株式会社マネーフォワードの各社が提供するサービスです。当社は Lark の導入を支援する独立した第三者コンサルティング事業者であり、ByteDance 社・freee 株式会社・株式会社マネーフォワードのいずれの公式機関でもありません。本記事の料金・仕様は 2026 年 6 月時点の各社公式情報に基づきます。最新情報は必ず各社公式サイトでご確認ください。