「経費精算も、備品の購入も、休暇の申請も、紙を回して、承認は口頭で『OK』」。中小企業ほど、この申請の回覧と口頭承認が当たり前になっています。けれど紙は誰の机で止まっているか分からず、催促の連絡が増え、いざ後で「これ承認したっけ？」と聞かれても記録がどこにもない。承認した・していないで気まずくなることも起きます。
世の中では「申請フォームを作りましょう（Google フォームなど）」で話が終わりがちですが、現場で本当にラクになるのは、申請が来た先、つまりその瞬間に承認者へ自動で通知が飛び、1クリックで承認でき、結果が自動で記録に残る状態です。本記事では、Google フォーム（無料の入力フォーム） で申請を受け、GAS（Google Apps Script・Google製の無料の自動化スクリプト） でスプレッドシートに記録し、Slack（スラック・チャットツール） へ自動通知するところまで、どの工程でどのツールを使うか具体名で紹介します。
1分の無料セルフ診断：5つの質問に答えるだけで、時間と人件費の変化の目安が出ます。
結論：申請は「出した瞬間に通知、1クリックで承認、自動で記録」にできる
社内申請の処理は、頭を使う仕事のようでいて、その大半は決まった作業です。申請を受け取る、承認者に知らせる、承認の結果を記録に残す。ここはルール化でき、機械に任せられます。人がやるべきなのは、承認するかどうかの判断だけ。「全部を自動に丸投げ」ではなく、作業は自動化、判断は人にと分けるのが現実的です。
きっかけになるのは、申請者がフォームを送信した瞬間です。ここを起点にすれば、誰かが紙を運ばなくても後工程が動き出します。
紙の回覧を続けるほど、「催促の手間」と「記録がない不安」が静かに積み上がります。先に仕組みにしておくほうが、結局は安全で速いです。
社内申請の回覧・承認まわり：仕組み化の前と後（月・中小企業のよくある規模での試算）
向いている会社・向きにくい会社
向いているのは、申請の種類が決まっていて、それが毎月一定数発生する会社です。経費精算・備品購入・休暇・稟議など、形が繰り返されるものほど、フォームと自動通知の効果が出ます。すでに Slack や Google Workspace を使っている会社は、通知や記録の口がそろっているので、とくに相性が良いです。
逆に、申請がごくたまにしか発生しない会社では、自動化の効果は限定的です。それでも「申請をフォームで受けて、結果だけ記録に残す」という軽い運用なら、後から探せるようになるだけでも十分に価値があります。
1分の無料セルフ診断：5つの質問に答えるだけで、時間と人件費の変化の目安が出ます。
具体的に、どう仕組みにするか
社内申請を仕組みにする3ステップ
- 1フォームで申請を受ける申請者はフォームに入力して送信。内容はスプレッドシートへ自動でたまります。
- 2承認者へ自動通知申請が届いた瞬間、Slack に「誰が・何を・いくら」が通知されます。
- 31クリックで承認・自動記録承認者はボタンを押すだけ。結果と承認者・日時が台帳に自動で残ります。
- 申請をフォームで受け取る：Google フォームに「申請種別・金額・理由・希望日」を入力して送信してもらいます。回答はスプレッドシートに1行ずつ自動でたまります。
- 承認者へ知らせる：申請が届いた瞬間、GAS が Slack に「誰が・何の申請を・いくら」と通知します。承認者が見落とさず、催促が要らなくなります。
- 1クリックで承認する：通知の「承認」「却下」ボタンを押すだけ。承認者がアプリを開いて探す必要はありません。
- 結果を自動で記録する：承認の結果・承認者・日時を、スプレッドシートの同じ行に自動で書き戻します。この記録が、後で聞かれたときの証跡になる肝です。
- 申請者へ結果を返す：承認・却下を申請者へ自動で通知します。ここまで人が触れるのは、承認のボタンを押す一瞬だけです。
実際に、どの道具を使うのか
ここは具体名で踏み込みます。工程は「申請の受付 → 記録 → 通知 → 承認の書き戻し」に分かれ、それぞれに向く道具があります。
申請を受ける（Google フォーム）
入口は Google フォーム（無料の入力フォーム） が手軽です。申請の種類ごとに必要な項目を決めておけば、書き漏れが減ります。回答はそのまま Google スプレッドシート にたまるので、別途データベースを用意しなくても記録の土台ができます。社内の申請が多種類あるなら、種別を選ばせて1つのフォームにまとめるのが運用しやすいです。
通知と記録を動かす（GAS ＋ Slack）
通知を受けて実際に動かす中心が GAS（Google Apps Script・Googleの無料の自動化スクリプト） です。フォーム送信をきっかけに GAS が起動し、申請内容を Slack の Webhook（ウェブフック・出来事を自動で通知する仕組み） へ流します。Slack が無い会社なら、同じ要領で Google Chat やメール通知に差し替えられます。承認ボタンの「押された」という合図も GAS が受け取り、スプレッドシートの該当行に結果を書き戻します。入口・通知・記録をひとつのスクリプトでつなげるのが、この仕組みの背骨です。
記録を台帳として残す（スプレッドシート ／ Notion）
記録先は Google スプレッドシート か Notion（ノーション・情報をデータベース化できるツール） が定番です。申請日・申請者・種別・金額に加えて、承認者・承認日時・ステータスの列を持たせるのが要。Notion なら「承認待ちだけ」「今月の経費だけ」といったビューを作れるので、未処理の取りこぼしを見つけやすくなります。
ここが肝
「通知して終わり」にせず、承認者・日時まで台帳に書き戻すこと。通知の自動化が「催促の手間」を消し、記録の自動化が「言った・言わない」を防ぎます。価値が大きいのは後者です。
つまずきやすい点
社内申請の自動化でつまずくのは、たいてい技術そのものより記録の作り方です。とくに、申請が同時に複数届いたときに「どの行に書き戻すか」を間違えると、別の人の承認が混ざってしまいます。実際に私たちが製造業の取引先向けに申請フローを組んだときも、この行のズレが最初の関門でした。
- 申請の行番号で書き戻す設計にする：「何行目」で記録先を決めると、申請が増減したときにズレて、別の申請に承認が混ざります。各申請に重複しないIDを振り、そのIDで該当行を探して書き戻す設計にすれば、事故が起きません。
- 同じ通知が二重に飛ぶ：処理が途中で再実行されると、通知や記録が二重になることがあります。一度処理した申請にはフラグを立て、二度目はスキップする（冪等性〔べきとうせい〕＝何度実行しても結果が同じ、という作り）を入れておくと安全です。
- 承認ルートを最初から複雑にする：「金額で承認者が変わる」などを最初から作り込むと、運用前に止まります。まずは「全部この人が承認」で動かし、実物を数件見てからルートを足すほうが速いです。
よくある質問
Q. 申請内容には金額や個人の情報が含まれます。どう扱えば安全ですか？ A. 申請データは社内の人事・経費情報を含むので、スプレッドシートやフォームの閲覧・編集権限を絞るのが基本です。承認者と経理だけが台帳を見られるようにし、申請者は自分の申請だけ確認できる、といった切り分けにします。誰がどこまで見られるかを先に決めておけば、申請が増えても散らかりません。
Q. 承認の記録は、どれくらい残しておくべきですか？ A. 経費や稟議の承認記録は、社内の取り決めや税務の観点から一定期間の保管が求められることがあります。台帳に承認者・日時・結果がそろっていれば、後から「いつ・誰が承認したか」をたどれます。保管期間の最終的な確認は、顧問の税理士に相談するのが安全です。
なお、この記事の数値は、特定の実在企業の事例ではなく、現場でよく見る状況を組み立てた代表的なケースです。御社に当てはめた目安は、診断で出すのがいちばん近くなります。
社内申請の回覧と口頭承認は、地味に時間を奪い、しかも記録が残らず後で困る業務です。申請をきっかけに「通知が飛ぶ・1クリックで承認できる・記録に残る」まで仕組みにすれば、社員は催促や紙の管理から解放され、本来やるべき仕事に向かえます。御社のどの申請から手をつけると時間が浮きそうか、まずは目安を出してみませんか。
1分の無料セルフ診断：5つの質問に答えるだけで、時間と人件費の変化の目安が出ます。
