「入社日が決まると、毎回同じ作業を思い出しながら進めている」「退職者のアカウントを止め忘れていた」。従業員数十名規模の会社では、入退社の段取りが担当者の頭の中にしか無い状態になりがちです。これを申請1件をきっかけに自動で流す仕組みへ置き換えられるのが、ノーコード自動化ツールの Make です。本記事では手順・料金・他ツールとの違い・現場でのつまずきどころを整理します。
入社・退職手続きの自動化とは、何を自動化する取り組みなのか
入社時の「十数個の作業」を申請1件から連鎖させます
入社が1件決まると、アカウント発行、チャットへの招待、PC・作業着などの備品手配、書類の回収、配属先と経理への通知、初日の予定登録、教育担当者の割り当てが同時に発生します。自動化の考え方は、これを人が思い出すのではなく、「入社予定者の情報が1件登録されたこと」を起点に、台帳追記・通知・カレンダー登録・タスク発行を一本の流れでつなぐことです。
退職側は「抜け漏れ防止」が主目的になります
退職時に発生するのは、権限剥奪、データとメールの引き継ぎ、貸与品(PC・鍵・制服・カード類)の回収、外部サービスの解約です。どれも「やらなくても業務が止まらない」ため後回しになり、セキュリティリスクと無駄なライセンス費用が残ります。そのため退職側は全自動で処理するより、「誰が・何を・いつまでに解除するか」のチェックリストを自動発行し、未完了を可視化する設計が現実的です。
Make とは、モジュールをつないで作るノーコード自動化ツールです
Make は複数のクラウドサービスを連携させる iPaaS で、アイコン(モジュール)を並べ線でつなぐだけで処理の流れを作れます。用語は3つで足ります。流れ全体が「シナリオ」、部品1つが「モジュール」、1件のデータを処理する単位が「オペレーション」で、3つ目が料金に直結します。Zapier が「きっかけ→処理」を一直線に並べる設計に対し、Make は分岐・繰り返し・データ加工を自由に組めるため例外処理に強いという違いがあります。自動化できるのは社内の段取りまでで、法定手続きの詳細は社会保険労務士へご確認ください。
Make で入社・退職手続きを自動化する手順を解説します
Step 1:「誰が・何を・いつまでに」を棚卸しして一覧化します
最初にやるのは Make の操作ではなく棚卸しです。入社1件で発生する作業を全部書き出し、各行に担当者・期限(入社何日前/何日後)・使うサービス・必要な情報を埋めます。埋まらない行は、自動化しても通知先が決まらず止まります。
当協会がDX支援の現場で実感しているのは、入社手続きの自動化は「効果がすぐ見える割に難易度が低い」ため最初の1本に向く一方、フローを紙で書き出さずに画面から作り始めるとほぼ必ず手戻りになる、ということです。詰まり方は2つあります。1つは「備品手配の担当が部署によって違う」ことが作り始めてから判明し、分岐を後付けするケース。もう1つはフォームの項目が足りず、半分組んだ後に作り直して既存回答と項目名が合わなくなるケースです。
Step 2:トリガーになる申請フォームを用意します
起点は「入社が決まったとき必ず1件だけ作られるデータ」にします。Google フォームで氏名・入社日・雇用形態・配属部署・必要備品を項目化するのが手軽です。分岐に使う雇用形態・部署は自由記述にせず選択式にします。表記のゆれがあると条件が一致せず、意図しない経路に流れます。項目名は後から変えると連携が外れます。
Step 3:Make でシナリオを作成します
新規シナリオを作り、トリガーにフォーム回答シートの「新しい行」を指定します。そこから、①管理台帳への追記、②Google Workspace のアカウント発行依頼を管理者へ通知、③配属先と経理へのチャット通知、④初日の予定をカレンダーへ登録、⑤担当者ごとのタスク発行、の順につなぎます。各欄には前のモジュールの値を差し込めます。
Step 4:分岐を入れて雇用形態・部署ごとに処理を変えます
ルーター(分岐)で、「正社員は書類回収タスクまで発行」「アルバイト・パートは案内と初日の集合時間のみ」「製造部門は安全教育と作業着手配を追加」といった枝を作ります。条件には Step 2 の選択式項目を使い、枝はまず2本で動かしてから追加します。
Step 5:テスト実行とエラーハンドリングを設定します
1件流して各モジュールの実行結果を開き、入るべき値が入っているかを確認します。同時に、失敗時の通知をチャットへ飛ばす設定と、失敗しても後続を止めない経路を必ず入れます。テストはダミーの氏名で行います。
Step 6:退職シナリオで権限剥奪チェックリストを自動発行します
退職連絡フォームを起点に解除対象サービスの一覧を展開し、サービスごとに担当者付きのタスクを発行します。貸与品の回収項目と返却期限もカレンダーへ登録し、全項目完了で台帳のステータスが変わるようにすると未完了が一目で分かります。関連する進め方は中小企業のDX・AI活用情報(当協会オウンドメディア)でも扱っています。
Make の料金プランと課金の考え方を整理します
課金単位は「シナリオの本数」ではなく「処理した件数」です
Make の月額は、シナリオの本数ではなく、モジュールが何件のデータを処理したかで決まります。原則1モジュールが1件処理するごとに1カウント消費されるため、モジュール20個のシナリオを月20回動かせば約400カウントです。入退社は件数が少なく、低コストに収まりやすい業務です。なお Make は2025年8月27日以降、課金単位の名称を「オペレーション」から「クレジット」へ変更しています(非AI機能では1対1で考え方は同じ)。
プラン別の月額目安(2026年9月時点)
| プラン | 月額の目安 | 主な特徴 |
|---|---|---|
| Free | 無料 | 月1,000クレジット程度。同時稼働シナリオ数に上限。試作向け |
| Core | 10ドル台〜 | 月10,000クレジットから。実務で使う最小構成 |
| Pro | 20ドル台〜 | 優先実行やカスタム変数など運用向け機能 |
| Teams | 40ドル台〜 | 複数人でのシナリオ共有・権限管理 |
| Enterprise | 個別見積 | 高度なセキュリティ要件・SLA・専任サポート |
ドル建ての概算です。クレジット枠・年払いか月払いか・為替で負担額は変わります。料金・プラン構成は改定される場合があるため、最新は公式サイトでご確認ください。
中小企業はどのプランから始めるとよいか
入退社が年20件前後なら、まず Free で1本動かし、消費量を見てから Core に上げます。判断基準は「同時に動かしたいシナリオが3本以上になったか」「月末に枠が足りず止まったか」の2点です。
Make・Zapier・Power Automate を比較するとどう違うのか
3ツールの比較表
| 比較軸 | Make | Zapier | Power Automate |
|---|---|---|---|
| 得意なこと | 分岐・繰り返しを含む複雑な業務フロー | 2〜3ステップの連携を最速で作る | Microsoft 365 内の申請・承認フロー |
| 課金の考え方 | 処理件数(クレジット) | 実行回数(タスク) | ユーザー単位のライセンス |
| 分岐の柔軟性 | 高い | 中程度 | 高い(設計難易度も高い) |
| 学習コスト | 中 | 低い | やや高い |
| 向く環境 | Google Workspace 中心+外部SaaSが多い | 小さく早く始めたい | Microsoft 365 中心 |
Google Workspace 中心の会社なら Make が扱いやすいです
フォーム・スプレッドシート・カレンダー・Gmail を土台にしている会社では、分岐や複数通知を含むフローを1本に収めやすく、既存の管理台帳をそのまま使えるため移行コストがかかりません。
Microsoft 365 中心なら Power Automate を先に検討します
Power Automate は Microsoft 365 の多くのプランに含まれ、追加費用なく始められる場合があります。逆に Microsoft 以外のSaaSが多いなら Make の連携先の広さが効きます。
中小企業での活用事例を3件紹介します
事例1:製造業(従業員60名規模)— 初日までの準備漏れがゼロに
年間の入退社が20名前後あり、総務担当者1名がメモを見ながら進めていました。工場と本社で備品手配の担当が分かれていたため「作業着が初日に間に合わない」「入場証の発行依頼が漏れる」が毎回発生。入社連絡フォームから部署で分岐して備品手配タスクを発行し、入社3日前に未完了を再通知する形にしたところ、準備漏れはなくなりました。
事例2:サービス業(従業員25名規模)— 権限剥奪漏れを解消
アルバイトの入退社が多く、退職後もシフト管理システムやチャットのアカウントが残る状態が常態化していました。退職連絡フォームから対象サービス6種類の解除タスクと貸与品回収タスクを自動発行し、最終出社日の翌営業日に未完了があれば店長へ通知する形に変更。解約漏れのライセンスも複数見つかりました。
事例3:士業事務所(従業員15名規模)— 担当者の工数が月8時間程度減
入社案内メールの作成と提出書類の回収リマインドを手作業で行っていました。入社日から逆算して案内メールの下書き作成・未提出者への督促・初日の予定登録を自動化し、担当者は確認して送るだけの状態に。支援現場の実感として月8時間程度の削減になりました。
導入前に押さえておきたいデメリットと注意点
設計が雑だとコストが想定外に増えます
処理件数課金のため、全行を毎回読み込む作り方では1回で数百カウント消費します。取得条件を絞る、トリガーを「新規行のみ」にする丁寧さが月額に跳ね返ります。
人事・労務データを外部サービスに流すことになります
氏名・住所・雇用形態などが Make を経由します。管理者権限を誰が持つか、実行ログをどこまで残すか、社内規程上の整理を構築前に確認します。
シナリオ作成者が属人化しやすいです
作った本人しか中身が分からないと、異動時に誰も触れなくなります。命名規則を決め、各モジュールに用途のメモを残し、フロー図を保存しておきます。
連携先のAPI仕様変更で止まることがあります
接続先の仕様変更や認証の期限切れで突然動かなくなります。エラー通知を設定し、月1回は実行履歴を確認します。
法定手続きそのものは自動化の対象外です
自動化できるのは通知・発行依頼・督促・タスク管理までです。社会保険・雇用保険の届出内容の判断や提出は対象外で、法定手続きの詳細は社会保険労務士へご確認ください。
よくある失敗パターンと対策
フローを整理せずにいきなりシナリオを作り始める
最も多い失敗です。画面から作ると分岐条件や通知先が途中で判明し、作り直しになります。対策は Step 1 の棚卸しを先に終えること。
エラー通知を設定せず、止まっていることに気づかない
止まっても誰も困らないまま数週間経つことがあります。通知先を個人ではなく複数人が見る場所にし、履歴を確認する担当を決めます。
最初から全部を自動化しようとして完成しない
入社・退職・異動・契約更新を一気に作ると検証が終わりません。まず「入社時の通知とタスク発行」に絞り、2週間運用してから広げます。
個人情報をシナリオのログに残しすぎる
実行履歴には扱ったデータがそのまま残ります。テストはダミーデータで行い、不要な項目はシナリオに通さず、ログの保存期間設定も確認します。
まとめ:入社手続きの自動化は最初の1本に向いています
小さく1本作り、動かしながら広げるのが最短です
Make による入社・退職手続きの自動化は、効果が「準備漏れゼロ」という形で見えるため、ノーコード自動化の入口に適しています。棚卸し→フォーム→シナリオ1本→分岐追加→退職シナリオの順で進め、いきなり全社を対象にしないことです。
判断に迷う段階でご相談いただけます
「どの手続きから自動化すべきか」「Make と Power Automate のどちらが合うか」は、既存のツール構成と入退社の件数で結論が変わります。作りかけで止まっている段階でも構いません。


