Lark Base × Workflow で承認フローを自動化する実装ガイド — 紙とハンコをやめて月100時間を取り戻す

なぜ今「Lark 承認ワークフロー」なのか — 紙とハンコ運用の構造的限界

結論から書きます。紙の稟議書とハンコ運用は「人が在席している前提」「物理的に書類が移動する前提」の 2 つに支えられた仕組みで、ハイブリッドワーク・モバイル業務・複数拠点化が進む 2026 年の中小企業では、この前提が崩れた瞬間に承認フローが止まる──これが当社が業務システム構築の現場で繰り返し目にする現実です。中小企業庁の 2024 年版中小企業白書では『紙書類の電子化・ペーパレス化』が中小企業 DX 取り組みの上位に挙げられており、これは『紙のままでは業務が回らない』という実感が中小企業全体に広がっている裏返しです。

紙とハンコの稟議が崩れる 5 つの典型サイン

当社が中小企業の承認フロー改善に入るとき、ヒアリングで毎回出てくるのが以下の 5 つです。3 つ以上当てはまるなら、紙運用は限界に近いと判断して問題ありません。

• サイン1: 承認 1 件のリードタイムが「平均 3 日以上」かかる──申請者が記入 → 印刷 → 上司の机に置く → 不在で寝かす → 押印 → 次の承認者へ、の物理的移動と『在席待ち』が積み重なって日単位の遅延が発生。
• サイン2: 「あの稟議どこいった?」を月 1 回以上聞く──書類が複数の机を経由するうちに紛失・滞留が発生。誰の机で止まっているか追跡できない。
• サイン3: 月末に経理が深夜残業──経費精算の領収書貼付・金額再計算・上司印章の確認に、月末の数日が完全に潰される。
• サイン4: 営業がハンコをもらうために本社往復している──契約書・見積書の決裁印を取りに 1 回 1〜2 時間の往復が発生。月に何度も繰り返される。
• サイン5: 過去の承認履歴を探すのに半日かかる──稟議書原本がキャビネットの奥に綴じられており、「去年の同様案件の決裁内容を見たい」が即座にできない。

これらの根本原因は『書類が物理的に存在し、人が物理的に在席している』前提に縛られていることです。サイオステクノロジー (Gluegent) の解説でも『紙の稟議書は印刷代・保管スペース・郵送費といった間接コストに加え、紛失リスクと検索性の悪さが構造的な問題』と整理されているとおり、紙運用は紙であり続ける限り構造的に解決できません。電子化が必要、ではなく『電子化しないと業務が止まる』という段階に多くの中小企業が到達しています。

なぜ「ワークフローシステムだけ」では足りないのか

専用のワークフローシステム (rakumo・kickflow・ジョブカンワークフロー・X-point Cloud など) を導入する選択肢もありますが、当社が中小企業に推す第一手として Lark を選ぶ理由は明確です。専用ワークフローシステムは「承認業務だけ」を電子化しますが、承認のあとに発生する『申請データの集計・分析・通知・次工程連動』までは扱わないのが構造的限界です。例えば購買稟議が通った後、その金額を月次の購買予算実績に積み上げ、上限を超えそうなら警告を出し、契約書ドラフトをチャットに通知する──こうした『承認の前後』を含めた業務を一気通貫で扱うには、承認単体ツールでは追加で BI ツールや RPA を組み合わせる必要があります。

Lark は『承認 (Lark Approval) + 業務データベース (Lark Base) + 自動化 (オートメーション) + チャット通知 (Lark Messenger) + ドキュメント (Lark Docs) + カレンダー (Lark Calendar)』が 1 つのアカウントの中で標準連携している、いわば『業務 OS』として機能します。承認が通った瞬間にデータが Base に積み上がり、関係者にチャット通知が飛び、期日が Calendar に登録される、というところまでノーコードで作れるのが他のワークフロー単体ツールと最も違う点です。中小企業のスタッフは 1 人何役もこなすため、ツールが分散すれば分散するほど『どこに何を入力するか分からない』問題が発生します。1 アプリで完結することの重みは、規模が小さい企業ほど大きく効きます。

Lark 承認 (Lark Approval) の基本仕様 — 機能・無料プラン・連携範囲

結論を先に書きます。Lark 承認は Lark Starter プラン (20 名まで無料・2025 年 3 月改定後) に標準搭載されており、追加料金なしで稟議書・経費精算・休暇申請・出張申請・契約稟議などの社内承認を完全電子化できます (21 名以上は Pro プラン ¥1,420/ユーザー/月)。Lark 承認 公式製品ページに記載されているとおり、申請フォーム作成 → 承認ルート設計 → モバイル承認 → 連携機能までをノーコードで一気通貫に扱える設計です。

Lark 承認の主要機能 6 つ

• 機能1: 申請フォーム設計──単一行テキスト・複数行テキスト・数字・金額・日付・期間・単一選択・複数選択・添付ファイル・連絡先・部署・明細テーブルなど 10 種類以上のウィジェットを画面操作で配置。標準テンプレート (休暇・出張・経費精算・残業・打刻修正など) を読み込んで微修正するだけでも実用に足ります。
• 機能2: 承認ルート設計──提出 → 承認 → 終了の 3 ステップを基本に、承認者ステップ・処理者ステップ・CC ステップ・条件分岐・並列分岐を画面で組み立てる。承認者は『指定ユーザー』『申請者の上長』『部署の責任者』『カスタムロール』から選択できる。
• 機能3: モバイル承認──Lark スマホアプリから承認待ち一覧を見て、その場でワンタップ承認 / 差し戻し / コメントが可能。出張中・移動中の上司が承認のために会社に戻る必要がない。
• 機能4: 自動アクション──承認後にチャットメッセージを自動送信、別の承認フローを自動開始、Base にレコード自動追加、といった後続処理をオートメーションで設計できる。
• 機能5: 過去履歴と検索──過去の全承認履歴がアプリ内に蓄積される。申請者・承認者・期間・キーワードで瞬時に検索可能。監査対応・税務対応で過去の決裁書を探すコストが大幅に下がる。
• 機能6: 外部連携──Lark Base への自動データ書き込み、Lark Docs での申請書テンプレ自動生成、AnyCross 経由での Salesforce / SAP / 既存基幹システム連携など、Lark プラットフォーム全体との統合が容易。

無料 (Starter) プランで使える範囲

Lark Starter プランは 20 名まで完全無料 (2025 年 3 月のプラン改定後) で、Lark 承認の以下の機能がすべて使えます (2026 年 5 月時点・最新情報は Lark 公式料金ページ でご確認ください)。21 名以上は Pro プラン (¥1,420/ユーザー/月) が必要です。

項目	Starter (無料)	Pro / Enterprise (有料)
申請フォーム作成	無制限	無制限
標準テンプレート	すべて利用可	すべて利用可
条件分岐・並列分岐	利用可	利用可
モバイル承認	利用可	利用可
承認履歴保管	1 年	無制限
監査ログ・SSO	×	○
外部システム連携 (AnyCross)	限定	フル

中小企業の社内承認 (稟議・経費・休暇・出張・契約稟議など) の電子化目的であれば、まずは Starter で全機能を試して定着させ、社員数が 20 名を超えるか、内部統制で監査ログ・SSO が必要になった段階で Pro / Enterprise を検討するのが現実的な順序です (2025 年 3 月のプラン改定でメンバー上限が 50 名 → 20 名に変更されたため、21 名以上は Pro プラン ¥1,420/ユーザー/月)。Lark Base や Lark Workflow を本格運用する場合も同じく Starter で 30〜90 日試行できます。Lark Base が中小企業の業務効率を変える 3 つの理由もあわせて、Lark の導入判断材料としてご確認ください。

申請フォーム設計の正解 — 6 必須フィールド + 標準テンプレ

結論から書きます。稟議書・経費精算・休暇・出張など、どの申請種別であっても『最低 6 フィールド + 種別固有の 2〜4 フィールド』に揃えると、運用も集計もスムーズに回る──これが当社の現場で 30 案件以上を回した結論です。最初から細かく作り込みすぎると、入力負担が増えて申請者が紙運用に逆戻りします。

全申請に共通する 6 必須フィールド

#	フィールド名	ウィジェット種類	役割
1	申請者	連絡先 (自動取得)	誰が出したかを記録。後から検索する起点になる。
2	申請日時	日付 (自動取得)	提出タイムスタンプ。リードタイム計算の基準。
3	申請件名	単一行テキスト	承認者の一覧表示で何の申請か瞬時に分かるための要約。
4	申請内容詳細	複数行テキスト	承認判断に必要な背景・経緯・根拠を記述。
5	金額 or 数量	金額 / 数値	承認ルートの条件分岐に使う。閾値判定のキー。
6	添付ファイル	添付ファイル	見積書 PDF・領収書写真・契約書ドラフトなど。

この 6 フィールドを揃えるだけで、承認 → 通知 → 集計 → 検索の基本動作が成立します。さらに種別ごとに必要なフィールドを 2〜4 つ追加します。

代表 5 種別の追加フィールド設計

申請種別	追加フィールド	条件分岐の例
購買稟議	取引先名・支払期日・予算科目	金額 10 万円未満→課長 / 10〜50 万円→課長+部長 / 50 万円超→課長+部長+役員
経費精算	経費科目・領収書枚数・利用日	金額 3 万円超→上長+経理 / 3 万円以下→経理のみ
休暇申請	休暇種別・開始日・終了日・日数	3 日以下→直属上長 / 4〜7 日→上長+部長 / 8 日超→部長+人事
出張申請	出張先・出張期間・想定費用	国内→上長のみ / 海外→上長+部長+経営層
契約稟議	取引先名・契約金額・契約期間・契約種別	新規取引→法務+部長+役員 / 既存更新→部長のみ

当社の実装パターンとして、最初の 30 日は『購買稟議』『経費精算』『休暇申請』の 3 種別だけで運用を開始することを推奨しています。残りの種別は試行期間中の運用知見を踏まえてから足すことで、フォーム設計の手戻りを最小化できます。

承認ルート設計の 4 パターン — シーケンシャル / 並列 / 条件分岐 / 統合

結論を先に書きます。実務で必要な承認ルートは『単純な順序型』『並列承認型』『金額/種別の条件分岐型』『複合統合型』の 4 パターンに集約され、これらをノーコードで組み合わせれば中小企業の社内稟議の 95% 以上をカバーできます。Stella DeepTech Lab の Lark 承認解説でも、Lark 承認の設計の柔軟性は『条件分岐』と『並列分岐』を組み合わせて表現する点にあると整理されています。

パターン 1: シーケンシャル承認 (順序型)

申請者 → 直属上長 → 部長 → 経営層、のように上から順に 1 人ずつ承認していくシンプルなパターン。休暇申請・出張申請・経費精算 (中額まで) の大半はこれで対応できます。Lark 承認では『承認者ステップ』を縦に並べるだけで設定完了。各承認者がスマホで承認した瞬間に次の承認者に通知が飛ぶため、書類が物理的に移動する時間がゼロになります。

パターン 2: 並列承認 (同時承認型)

同じ階層の承認者 (例: 部長 + 法務責任者) が同時に承認するパターン。契約稟議で『法務観点』と『事業部観点』を並列でかける場合、または購買稟議で『現場部門』と『経理』が同時にチェックする場合に使います。Lark 承認では『並列分岐ステップ』を挿入し、ステップ内に複数の承認者を配置すれば、全員の承認が揃った時点で次へ進む設定が可能。1 人ずつ順序立てて回すより 50〜70% リードタイムを短縮できる場合があります。

パターン 3: 条件分岐 (金額・種別・部署型)

申請内容に応じて承認者を切り替えるパターン。最も需要が高く、紙運用では『金額別に申請書テンプレを 3 種類用意して使い分ける』という非効率が発生していました。Lark 承認では『条件分岐ステップ』を挿入し、フォーム上の金額フィールドや種別フィールドの値に応じてルートを自動振り分け。例えば購買稟議なら『金額 10 万円未満→課長承認のみ / 10〜50 万円→課長+部長 / 50 万円超→課長+部長+役員』を 1 つの申請フォームで自動判定。申請者は金額を入れるだけで、適切なルートが裏で組み上がります。

パターン 4: 複合統合型 (条件分岐 + 並列 + 後続自動アクション)

条件分岐の中に並列承認を入れ子にし、承認完了後に Base への自動データ追加・チャット通知・後続承認の自動起動まで組み込むパターン。当社の自社 EC 事業では、仕入稟議が金額閾値を超えた場合に『部長+経理+在庫担当』の並列承認を発火させ、承認完了後に Base の『仕入実績テーブル』へ自動レコード追加 → 関係者チャットへ自動通知 → 取引先への発注書 PDF を自動生成、までを 1 つの申請フローに統合しています。これにより仕入関連の月間稟議処理工数が大幅に短縮し、月 240 時間 → 24 時間 (-90%) の集約効果の一部を担っています。

4 パターンの組み合わせ判断は、当社の Lark Base 脱 Excel 30 日チャレンジ でも触れている『最小設計から運用しながら拡張する』思想と同じです。最初から複合統合型を作り込まず、まずシーケンシャル → 必要に応じて条件分岐 → 安定したら並列・統合、と段階的に育てる順序が中小企業の現場では機能します。

6 ステップ完全実装手順 — フォーム作成からテスト公開まで

結論を先に書きます。Lark 承認の最初の 1 フォームは『管理コンソールへログイン → 申請フォーム新規作成 → テンプレ選択 → フィールド配置 → 承認ルート設定 → テスト承認 → 公開』の 6 ステップで、所要時間 30〜60 分。手順自体は単純で、最大の壁はステップ 1 の『どの申請から電子化するか』を決めることです。

Step 1: Lark 管理コンソールにログイン → 承認管理画面を開く

Lark のアカウントで admin.larksuite.com にアクセスし、左メニューから『ワークプレース』→『承認』を選択します。最初のアクセス時は『承認管理者として有効化』のボタンを押す必要があります (管理者権限が必要)。Lark 承認 はじめてのガイド (公式) も合わせて参照してください。

Step 2: 標準テンプレートを選択 (休暇 / 経費 / 出張 / 購買 etc.)

『申請フォームを新規作成』を押すと、Lark が提供する数百種類の標準テンプレートが一覧表示されます。最初の 1 フォームは『経費精算』『休暇申請』『購買稟議』のいずれかから選ぶことを推奨。社内で利用頻度が最も高い申請を選び、既存の紙テンプレと項目を見比べながら不要なものを削り、足りないものを追加する流れが最短ルートです。テンプレを使わず白紙から作ることもできますが、初回はテンプレ起点のほうがフィールド設計の経験値が早く溜まります。

Step 3: フィールドを 6 + 種別固有 2〜4 個に整える

前章で示した『6 必須フィールド + 種別固有 2〜4 フィールド』に揃えます。テンプレ初期状態では 15〜20 フィールドが配置されていることが多いですが、迷ったら『この項目を入れないと承認判断ができないか?』を基準に削減。1 申請あたり入力時間 3〜5 分以内を目安にすると、申請者の負担が紙より明確に減ります。各フィールドには『必須/任意』『表示条件 (他フィールドの値で表示切替)』も設定可能。

Step 4: 承認ルートを設定 (4 パターンから選ぶ)

『フォーム設計』タブの隣にある『ワークフロー』タブを開き、承認ルートを設計します。初回はシーケンシャル承認 (順序型) でシンプルに『申請者→直属上長→部長』の 3 段で組むのが安全。承認者ステップで『申請者の上長』を選ぶと、組織図上の上司が自動でアサインされます (部署の組織図登録が前提)。複雑な条件分岐は運用が安定してから足すこと。最初から作り込みすぎると、ルート設計のバグで申請が止まる事故が発生しやすくなります。

Step 5: テスト承認を 5 件実施 (本番公開前)

『テスト送信』機能で、自分宛てに 5 件の申請を流して動作確認します。チェック項目は『フィールドが正しく表示・必須判定されるか』『承認者に通知が正しく届くか』『金額閾値の条件分岐が想定どおり振り分けられるか』『差し戻しと再提出が正常動作するか』『モバイルアプリで承認できるか』の 5 つ。テストで発見される代表的なバグは『金額閾値の境界値の挙動』『連絡先フィールドで部署が反映されない』『添付ファイルサイズ上限の見落とし』など。テストで全部潰してから本番公開へ。

Step 6: 対象メンバーに公開 + 利用ガイドを共有

『公開』ボタンを押し、対象メンバー (全社員 / 特定部署 / 特定ロール) を指定。同時に Lark Docs で『申請者向け利用ガイド (3 ページ程度・スクショ付き)』を作成し、Lark Chat の関連グループにピン留めします。初週は『Lark で出した稟議のほうが紙より早く通る』体験を全員にしてもらうことが最重要。利用ガイドを配って終わりではなく、初日に管理者が傍につく『定着伴走』の半日を予算化しておくと立ち上がりが格段に速くなります。Lark 導入失敗パターン 3 つでも触れていますが、ツール導入の失敗は技術ではなく『導入後 7 日間の運用設計』に起因することが圧倒的多数です。

Lark Base × Workflow との 4 つの統合パターン — 承認データを業務 DB に流す

結論を先に書きます。Lark 承認単体で電子化を済ませるだけでも紙運用より圧倒的に速くなりますが、Lark Base のオートメーションと組み合わせて『承認データを業務 DB に自動格納 → 集計 → 通知 → 次工程連動』までを設計すると、月間の手作業工数が一桁減るのが当社案件の標準的な観測値です。Lark Base オートメーション 公式ガイドに整理されているとおり、Base のオートメーションはトリガー条件と実行操作の組み合わせで構成され、ノーコードで設計できます。

統合パターン A: 承認完了 → Base に実績レコード自動追加

購買稟議や経費精算が承認された瞬間、Lark Base の『購買実績テーブル』『経費実績テーブル』に新規レコードが自動追加されるパターン。これにより、経理が月末に Excel で集計する作業が不要になります。Lark 承認の自動アクションで『承認完了時に Base にレコード追加』を設定するだけで実装可能。当社の自社 EC 事業ではこのパターンで仕入実績・販管費・人件費の 3 テーブルが日々リアルタイム更新されており、月次決算前の集計時間が大幅に短縮しています。

統合パターン B: Base の予算上限到達 → 承認ルートを自動エスカレーション

Base 上の『月次予算テーブル』で当月の購買実績が予算 80% に到達したら、それ以降の購買稟議は自動的に役員承認まで含むルートにエスカレーションされるパターン。Base のオートメーションで『予算実績が閾値超過したらフラグフィールドを更新』→ 承認フォームの条件分岐がそのフラグを参照、という二段構えで実装します。予算オーバーを後から気付いて『役員に怒られる』事故を構造的に防げます。

統合パターン C: 承認完了 → チャット自動通知 + Calendar 自動登録

休暇申請や出張申請が承認された瞬間、関係する部署のチャットグループに自動通知が飛び、当該休暇期間が Lark Calendar に自動登録されるパターン。これにより『誰がいつ休むか / いつ出張で不在か』が組織全体に共有され、抜け穴のスケジュール調整が消えます。当社では『3 営業日前までの休暇申請なら自動承認 + 全体通知 + Calendar 登録』をルールに組み込み、上司の判断負担そのものを削減しています。

統合パターン D: 契約稟議 → Docs で契約書 PDF 自動生成

契約稟議が承認された瞬間、Lark Docs の契約書テンプレートに承認内容 (取引先名・金額・期間など) が自動流し込みされ、契約書 PDF が自動生成されて法務担当のチャットに通知されるパターン。法務担当は内容確認・電子署名へ進むだけ。手作業の差し込み・誤記・確認往復がほぼゼロになります。Lark Docs のテンプレ機能と Base の参照リンクを組み合わせて実装します。当社案件では新規取引先との初期契約処理時間が大幅に短縮しました。

4 パターンとも、最初から全部を作り込む必要はありません。当社では『パターン A (実績データ自動追加) を 30 日 → パターン C (チャット+カレンダー連動) を次の 30 日 → パターン B/D を 90 日目までに』という順序を推奨しています。一気にやらない理由は、各パターンが定着するまで運用観察期間が必要だからです。Lark Base ガントチャートで案件・工程管理を一元化する完全手順でも触れていますが、Lark Base の真価は『単体で使う』のではなく『承認・チャット・ドキュメント・カレンダー・自動化と組み合わせる』ところで発揮されます。

中小企業がつまづくポイント TOP 5 — 失敗を回避する

結論から書きます。Lark 承認の導入で躓くのは技術問題ではなく、設計と運用の問題が 9 割──以下の TOP 5 を事前に潰せば、初月の試行で挫折する確率が大幅に下がります。当社が中小企業向け Lark 業務システム構築で繰り返し発生する典型失敗を整理したものです。

つまづき 1: 一気に全種別を電子化しようとして頓挫

『稟議・経費・休暇・出張・契約・備品購入・残業・打刻修正…全部 Lark に移行しよう!』と初月で 10 種類のフォームを作り込もうとして、設計が終わらず公開がずれ込み、推進担当が疲弊して紙運用に戻る、という失敗パターン。回避策は明快で、最初の 30 日は『最も頻度の高い 3 種別』に絞ること。当社の経験則では『経費精算 + 休暇申請 + 購買稟議』の 3 種別で社内承認の 70% 以上をカバーできます。残りは 60 日目以降に段階的に拡張します。

つまづき 2: 承認ルートを紙のままコピーしてしまう

紙運用時代の『5 人ハンコリレー』をそのまま電子化して、結局リードタイムが短縮しないパターン。電子化を機に、本当に必要な承認者を 2〜3 人に絞ることがセットで重要です。例えば『金額 1 万円未満の経費は上司承認のみ (経理通過)』『3 万円超のみ経理確認』のように閾値で承認者数を変えると、低額案件のリードタイムが劇的に短縮します。電子化は単なるツール置き換えではなく『承認設計の見直し機会』として扱うのが定石です。

つまづき 3: 申請フォームに項目を詰め込みすぎる

『せっかく電子化するから将来必要かもしれない項目も入れておこう』と入力フィールドが 30 個になり、申請者が嫌気を覚えて紙運用に戻るパターン。1 申請あたり入力時間 3〜5 分を上限に設計するのが鉄則です。本記事の『6 必須フィールド + 種別固有 2〜4 フィールド』に従えば、入力時間は十分この範囲に収まります。欲しい情報は後から追加できるので、初版は必要最小限にとどめます。

つまづき 4: モバイル承認の運用ルールを決めていない

『スマホで承認できます』とアナウンスしただけで、上司側に『どのくらいの時間内に対応するか』のルールがなく、結局 PC を開くまで承認が止まるパターン。『業務時間内の申請は当日中、業務時間外の申請は翌営業日午前中まで』のような時間基準を承認者全員で握ることが、リードタイム短縮の決め手です。Lark のチャット通知をスマホのプッシュ通知 ON にし、承認待ち一覧を 1 日 2〜3 回見る習慣をつけてもらうだけで、平均リードタイムが 1/3 〜 1/5 になります。

つまづき 5: 過去履歴の運用ルールが曖昧で監査時に困る

承認履歴は Lark 内に蓄積されますが、Starter プランは 1 年保管が上限のため、税務・会計監査で 3〜7 年遡る必要がある書類は Lark Base の専用テーブルに別途エクスポート保存しておく運用が必要です。当社では『承認完了時に自動で Base の長期保管テーブルに転記する』オートメーションを組み込むことを標準対応にしており、これで Starter プランのままでも長期保管要件を満たせます。Pro / Enterprise に上げる前に、まずこの自動エクスポート運用を試すことを推奨します。

自社 EC 事業で月 240h→24h(-90%) を実証した運用パターン

結論を先に書きます。アウフヘーベンジャパンが運営する自社 EC 事業では、Lark 承認 + Lark Base + Lark Workflow + Lark Chat + Lark Docs を組み合わせた業務集約により、月 240 時間相当の手作業を約 24 時間に圧縮 (-90%) しました。これは Lark 承認単体ではなく『承認の前後をすべて Lark で完結する設計』の総合効果です。承認系の主要 3 業務での実装パターンを公開します。

運用例 A: 仕入承認 — 取引先別予算管理と連動

自社 EC は月数百件の仕入が発生します。紙運用時代は『仕入伝票を印刷 → 上司決裁 → 経理転記 → 月末集計』に多くの工数を費やしていました。Lark 承認で『仕入稟議フォーム』を作り、申請内容を Lark Base の『仕入実績テーブル』に自動格納 → Base 側で取引先別 / 月次の予算実績を自動集計 → 上限到達でチャット警告、という統合運用に切り替えました。月末の集計作業はゼロになり、上司の決裁も 1 件あたり数十秒で完了します。

運用例 B: 経費精算 — 月末経理残業ゼロのフロー

経費精算は申請者がスマホで領収書を撮影 → Lark 承認フォームに添付 → 金額・科目・利用日を入力 → 上司承認 → 経理確認 → Base の経費実績テーブルに自動格納、というフローに統一。月末に経理が領収書を物理的に集めて Excel に転記する作業がゼロになり、月次決算前の経理残業時間が大幅に短縮しました。3 万円以下は経理確認をスキップする条件分岐を組み、低額案件のリードタイムをさらに短縮しています。

運用例 C: 業務委託・取引先稟議 — 契約締結まで一気通貫

業務委託・新規取引先との契約は『稟議申請 → 部長+役員並列承認 → 承認完了で契約書ドラフトを Docs から自動生成 → 法務確認 → 取引先へ送付 → 締結完了で Base 契約管理テーブルに自動登録』のフローに統合。紙運用時代は契約 1 件あたり 7〜10 日かかっていたものが、Lark 統合後は 2〜3 日に短縮。契約管理テーブルには更新期日が自動登録され、満了 60 日前に担当者へ自動通知が飛ぶため、契約満了の見落としリスクも構造的に消えました。

これら 3 業務だけで承認系の月間工数が大幅に削減され、残りの集約効果は Lark Chat・Lark Docs・Lark Calendar・Lark Wiki への業務統合で実現しています。詳細な集約パターンは AI 業務自動化で中小企業の収益増 88% を再現する 90 日プラン にも整理しています。なお、当社は群馬・前橋に拠点を構えるアウフヘーベンジャパン株式会社が運営する Lark 導入支援事業であり、自社の業務集約実証を踏まえて中小企業向けのコンサルティングを提供しています。代表の小池は Lark Partner CSM Certificate を 2026 年 6 月に取得予定です。

Lark 承認 vs 主要ワークフローシステム比較 — 中小企業視点の選定基準

結論から書きます。『社内承認だけを電子化したい』なら専用ワークフローシステムも選択肢ですが、『承認の前後の業務 DB・チャット・カレンダー・自動化まで一気通貫で電子化したい』なら Lark が中小企業の現実解──というのが当社の比較分析の結論です。料金体系・機能範囲・拡張性で主要選択肢を整理します (各料金は 2026 年 5 月時点の公式公開情報、最新は各社公式ページで要確認)。

製品	料金 (30 名)	承認機能	業務 DB	チャット	カレンダー	自動化
Lark (Starter)	無料	○ 標準搭載	○ Base	○ Messenger	○ Calendar	○ オートメーション
rakumo ワークフロー	月 9,000 円〜 (300 円/名)	○ 専用	×	×	連携	限定
kickflow	月 15,000 円〜 (要見積)	○ 専用	×	×	×	○
ジョブカン ワークフロー	月 9,000 円〜 (300 円/名)	○ 専用	×	×	×	限定
X-point Cloud	月 15,000 円〜 (500 円/名)	○ 専用	限定	×	×	○
Excel + 紙 + 印鑑	0 円 (ただし時間コスト大)	△ 手作業	△	×	×	×

専用ワークフローシステムは『承認業務に最適化された UI と過去資産』に強みがあります。一方 Lark は『承認だけでなく業務全体の OS として機能する』ことが構造的優位で、中小企業のように専任の情シスがいない組織では『1 ツールで完結する』ことの実運用効果が大きい傾向です。詳細な比較軸は Lark vs kintone どっちを選ぶべきか や Notion vs Lark Base 中小企業の業務 DB 選定基準 にも整理していますので、kintone / Notion / Teams との比較で迷われている方はあわせてご確認ください。

30 日定着ロードマップ — Day 1〜10 設計 / 11〜20 試行 / 21〜30 横展開

結論を先に書きます。Lark 承認の定着には『最初の 30 日を 3 つのフェーズに分けて、それぞれゴールを明確化する』設計が必要──ツールを入れて『あとは現場任せ』にすると、初月のうちに紙運用に戻る確率が高くなります。以下、3 フェーズの標準ロードマップです。

Day 1〜10: 設計フェーズ — フォーム 3 種類を完成

• Day 1〜2: 既存の紙申請書を全種類洗い出し、頻度・件数・関与人数で優先順位付け。最も頻度が高い 3 種別を選定。
• Day 3〜5: 選定した 3 種別の Lark 承認フォームを作成。6 必須フィールド + 種別固有 2〜4 フィールドで設計。
• Day 6〜8: 承認ルートを設計。初版はシーケンシャル承認 (順序型) で 3 段までに抑える。条件分岐は後回し。
• Day 9〜10: 各フォームを管理者が 5 件ずつテスト承認。全 15 件のテストで動作確認と微修正。

Day 11〜20: 試行フェーズ — 限定部署で実運用

• Day 11: 試行部署 (1 部署または推進チームのみ) で公開。利用ガイドを Lark Docs で配布。
• Day 12〜14: 推進担当が試行部署に張り付き、初日の申請を全件フォロー。つまづいたら即修正。
• Day 15〜17: 紙運用と並行運用。週次で『リードタイム / 申請件数 / 差し戻し回数 / 推進担当への問い合わせ件数』を計測。
• Day 18〜20: 試行で出た改善点をフォームと承認ルートに反映。リードタイムが紙の 1/3 以下になっていることを確認。

Day 21〜30: 横展開フェーズ — 全社展開と紙運用停止

• Day 21: 全社員に公開。3 種別を一斉に Lark 承認へ移行。
• Day 22〜25: 各部署で『初日承認会』を開催。実際に申請を 1 件ずつ提出して使い方を体験。
• Day 26〜28: 紙運用の段階的停止。新規申請は Lark のみ受付。過去の紙申請はそのまま完了させる。
• Day 29〜30: 30 日振り返り。リードタイム短縮率、月間時間削減、定性的な改善ポイントを社内発信。次の 30 日で追加する申請種別 (出張・契約稟議など) を決定。

30 日でここまで進めれば、社内の『紙はもう戻れない』気運が定着し、次の 60〜90 日で残りの申請種別と Base 統合パターンを段階的に追加していけます。当社の 中小企業 DX を 90 日で軌道に乗せる実践ロードマップ にも整理しているとおり、90 日プランの中で『最初の 30 日』を承認電子化に充てるのは、効果が見えやすく社内合意を取りやすい現実的な選択肢です。

よくある質問 (FAQ) — Lark 承認ワークフローの導入相談

Q1. Lark の承認機能は無料プランで使えますか?

はい。Lark Starter プラン (20 名まで無料・2025 年 3 月のプラン改定後) には Lark 承認 (Lark Approval) が標準で含まれており、申請フォーム作成・承認ルート設計・モバイル承認のすべてが無料で利用できます。承認テンプレート (出張・休暇・経費精算など) も標準搭載されています。20 名以下の中小企業の社内稟議・経費・休暇申請であれば Starter プランから始めても問題ありません。21 名以上は Pro プラン (¥1,420/ユーザー/月) が必要です。詳細は Lark 公式料金ページで最新の機能比較をご確認ください。

Q2. 紙の稟議書をやめると本当に時間は減りますか?

減る確率は非常に高いですが、減り幅はもとの紙運用の手数に比例します。承認 1 件あたり、紙では『申請書記入→印刷→上司の机に置く→不在で 1〜2 日寝かす→押印→次の上司に回す→経理に提出』と平均 3〜7 日かかります。Lark 承認に置き換えると、申請者の入力 (3〜5 分) と承認者のスマホ確認 (1 件あたり 30 秒〜1 分) で完結し、リードタイムが平均 1/5 〜 1/10 に短縮するのが当社案件の体感です。当社の自社 EC 事業では稟議系を含む業務全体で月 240 時間 → 24 時間 (-90%) を達成しましたが、これは承認単体ではなく Lark Chat・Lark Docs・Lark Base・Lark Workflow との統合運用の総合効果です。

Q3. Lark 承認と Lark Base のオートメーションは何が違いますか?

役割が異なります。Lark 承認 (Lark Approval) は『申請書 → 上司の承認 → 完了通知』という人が判断する稟議フローを扱う専用アプリです。Lark Base のオートメーションは、テーブル上のレコード変化 (新規追加・ステータス更新・期日到来など) をトリガーに、別フィールドを更新したりチャット通知を送ったりする自動化機能です。承認結果を Base のレコードに同期して集計したい、申請通過後に Base に新規行を自動追加したい場合は、両者を組み合わせて使います。本記事では統合実装パターンを 4 パターン解説しています。

Q4. 既存のワークフローシステム (rakumo / kickflow など) からの移行は可能ですか?

可能です。多くの場合、紙の申請書 → 既存ワークフロー → Lark 承認の順で電子化されてきた企業は『移行のたびにテンプレを作り直す』という負担を抱えています。Lark 承認は標準テンプレート (出張・休暇・経費・購買稟議・契約稟議 など) が組み込まれており、既存ワークフローのフォーム項目を Lark のウィジェット (単一行テキスト・数字・金額・日付・添付ファイル・連絡先 など) に置き換えるだけで再現できることが多いです。並行運用期間を 30 日設けて、過去の申請履歴は旧システムに残し、新規申請のみ Lark で受け付けるのが安全な移行パターンです。

Q5. 承認ルートが部署ごとに違う場合でも対応できますか?

対応できます。Lark 承認は『条件分岐ステップ』と『並列分岐ステップ』を組み合わせることで、申請者の所属部署・金額・申請内容に応じて承認者を切り替えられます。例えば『金額 10 万円未満は課長承認のみ / 10〜50 万円は課長+部長 / 50 万円超は課長+部長+役員』のような閾値分岐や、『総務マターは総務部長 / 経理マターは経理部長』のような種別分岐をノーコード画面操作だけで設計できます。複雑なルートを 1 つの承認に詰め込みすぎると保守が大変になるため、原則として 1 申請種別 = 1 フォーム、複雑な閾値は『条件分岐』に集約するのが運用しやすい設計です。

まとめ — Lark 承認ワークフローで「ハンコ待ち」を構造的に消す

本記事では、Lark 承認 (Lark Approval) と Lark Base のオートメーションを組み合わせて、中小企業の社内承認を一気通貫で電子化・自動化する実装ガイドを解説しました。要点を 5 つに整理します。

• 申請フォームは 6 必須フィールド + 種別固有 2〜4 フィールドに揃えて、入力時間 3〜5 分以内に収める。
• 承認ルートは 4 パターン (シーケンシャル / 並列 / 条件分岐 / 統合) を組み合わせ、まずシーケンシャルから運用開始する。
• Lark Base のオートメーションと連動させ、承認完了 → 実績データ自動格納 → 集計 → チャット通知 → 次工程連動までを設計する。
• 30 日定着ロードマップで『Day 1〜10 設計 / 11〜20 試行 / 21〜30 横展開』のフェーズ管理を徹底する。
• つまづき TOP 5 (一気に全種別 / 紙ルートコピー / 項目詰め込み / モバイル運用ルール欠落 / 過去履歴運用) を事前に潰す。

当社の自社 EC 事業では Lark 統合運用で月 240 時間 → 24 時間 (-90%) の業務集約を実証しました。これは承認単体ではなく『業務全体を Lark に集約する』設計の総合効果です。承認電子化はその第一歩として最も効果が見えやすく、社内合意を取りやすい入口になります。