2026年4月、チャットツールのグループメンションと人事データベースを自動連携する仕組みの設計に取り組んだ記録です。人事DBをマスターにする設計方針の選択から、GASによる処理フローの設計、運用ルールの確定までを残します。
この記事を読んだほうが良い人
- チャットツールのグループメンションを手動で管理していて、更新漏れが気になっている情シス担当者
- 人事データベースとチャットツールの連携設計を検討しているが、方針が定まっていない方
- GASを使った社内ツール開発の設計事例を参考にしたい方
- 退職者・異動者のグループメンバー管理を自動化したい方
背景：手動管理の何が問題だったか
部門ごとのグループメンションは便利です。情報システム部門向け、営業部門向け、管理部門向けといった単位で通知を一括送信できます。しかしチャットツール上で直接メンバーを管理していると、人事情報との乖離が起きやすい状態が続きます。
発生しやすいのは以下の3つのパターンです。
- 退職済みのメンバーがグループに残り、退職後も通知を受け取り続ける
- 異動済みのメンバーが旧部署のグループに残ったまま、関係のない情報が届く
- 新しく配属されたメンバーがグループに追加されず、重要な通知を受け取れない
この更新作業は、1回あたり10〜30分程度の確認と修正を要します。対象グループが数個から十数個にわたると、毎月数時間単位の作業になります。そして手動作業には必ずヒューマンエラーが伴います。
特に退職者の削除漏れは、通知ミスにとどまらず、情報共有範囲やアクセス管理上の問題にもつながります。数十名から数百名規模の組織でこれを手動管理し続けるには限界があります。
設計の核心：どちらをマスターにするか
この問題を解決するうえで、最初に決めるべき設計判断は「どちらのデータをマスターにするか」です。連携処理を実装するよりも先に、この方針を固めないと、自動化しても運用がすぐに崩れます。
選択肢は2つあります。
チャットツール側をマスターにする場合
チャットツール上でメンバーを管理し、人事DBは参照元にとどめる形です。一見シンプルに見えますが、人事異動や退職が発生するたびに「人事DB上では処理済み・チャットツールでは更新されていない」という状態が生まれます。2つのシステムが分離した状態で動き続けることになります。
人事DBをマスターにする場合
人事DB側で社員番号・メールアドレス・所属部署・雇用ステータス（いずれも人事DBの管理項目）を管理し、チャットツール側はその反映先として扱います。部署変更や退職処理が人事DBに反映された時点で、次回同期のタイミングにグループメンションも更新されます。チャットツール上でのメンバー管理は廃止し、人事DBだけで判断します。
今回は人事DBをマスターにする設計を選択しました。組織の正式な状態を保持している場所がすでに人事DBとして存在しており、そちらに権威を持たせる方が整合性を維持しやすいためです。
処理フロー：実装の流れを8ステップで整理する
実行基盤はGASを想定しています。更新頻度は1日1回の定期実行を基本とし、入社日・退職日・異動日などのタイミングでは手動実行にも対応できる設計にします。
処理の流れは次のとおりです。
- 人事DBから全社員レコードを取得する
雇用ステータスが有効（在籍中）のユーザーに絞り込む所属部署・役職・雇用区分などの属性から、対象グループを判定するメールアドレスをキーにチャットツール側のアカウントと照合する- 対象グループごとのメンバー一覧（あるべき姿）を生成する
- 現在のチャットツール側のメンバーと差分を確認する
- 差分に応じた追加・削除を実行する
- 実行ログとエラー内容を記録して終了する
ステップ6の差分確認がこの処理フローの肝です。チャットツール側の現在のメンバーと、人事DBから計算した「あるべきメンバー」を突き合わせることで、追加すべきアカウントと削除すべきアカウントが明確になります。
落とし穴：チャットツール側の直接編集を禁止しなければならない
この設計で見落としやすいのが、チャットツール側でのグループメンション直接編集への対処です。
人事DBをマスターにする設計では、定期実行のたびにチャットツール側のメンバーが「人事DBの状態」に上書きされます。チャットツール上で手動変更を加えても、次回同期時に元の状態へ戻ります。
担当者が善意でチャットツール側を更新した場合でも、同期処理で変更が上書きされます。この仕様を事前に共有しないと、「更新したはずなのに戻っている」というトラブルが情シスに届きます。
そのため、グループメンションのメンバー管理は人事DB側で完結させ、チャットツール側の直接編集は原則禁止とする運用ルールを、実装前にチームで合意しておくことが欠かせません。この合意が取れていない状態で自動同期を動かすと、運用混乱の原因になります。
なお、チャットツール側のグループを誰でも編集できる状態にしておくと、この問題が必ず起きます。グループのメンバー変更権限を管理者のみに制限する設定と組み合わせて運用するのが現実的です。
この設計から得た学び
2026年4月のこの設計作業から得た学びをまとめます。
グループメンションの自動更新において、連携処理の実装よりも「どちらをマスターにするか」の設計判断が先です。
チャットツール側をマスターにしたまま自動化しようとすると、人事DBとの整合が取れなくなるタイミングが発生します。人事DBをマスターに固定し、チャットツールを反映先として扱う前提を先に決める。この方針なしに実装を始めると、後から運用ルールを変更するコストが大きくなります。
自動化の価値は「1回あたり10〜30分の作業削減」だけではありません。退職者や異動者の取り残しをゼロにする点に、より大きな意義があります。退職後も社内通知が届き続ける状態は、情報共有範囲の管理上の問題として扱うべきです。自動化によってその発生を構造的に防げます。
設計段階でマスターデータの置き場所と手動編集禁止ポリシーを決めておく。この2点を先に固めれば、GASによる定期同期フローの実装はシンプルに進められます。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
御社の IT 部門、ここにあります。
「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。