定例ミーティングを自動化する方法：GASとSlackで社内定例会議の準備・通知漏れを防ぐ実践事例

導入

社内の定例ミーティングは、会議そのものよりも「準備」と「通知」で疲弊しがちです。

一言で言うと、本記事は GASで議事録テンプレートを毎週自動生成し、Slackで当日の議事録URLとファシリテーター名を自動通知する運用 を、社内IT担当者・チームマネージャー向けに整理した実践プレイブックです。

読み終えると、次のことができます。

• 定例会議前の議事録コピー、日付更新、担当者入力をGASで自動化する
• Slackへ「今日の議事録URL」「担当者」「開始前リマインド」を自動送信する
• エラー時の逃げ道まで含めて、社内 定例会議 自動化の運用設計を始める

手作業の運用では、担当者が朝に前回議事録を探し、コピーし、日付を直し、Slackに投稿します。忙しい日は忘れます。通知が遅れます。議事録URLが前週のまま貼られます。

現場は悲鳴を上げているはずです。

一方で、自動化された運用では、開催日の朝に新しい議事録が生成され、SlackにURLと担当者が流れます。参加者はリンクを開くだけ。ファシリテーターは「準備されていないかも」という不安から解放されます。

これは単なる効率化ではありません。
会議前の小さな不安を減らし、チームの心理的安全性を守る仕組みだと考えます。

会議運用全体の考え方は、meeting や productivity のテーマとも相性がよいですね。

ボトルネック整理

定例ミーティング 自動化 CS、つまりCSチームや社内横断チームの定例会議を自動化したい場合、最初に見るべきは「会議時間」ではありません。

実務的には、会議の前後にある細かい作業がボトルネックになります。

よくある手作業は次の通りです。

作業	手作業で起きる問題	自動化で狙う状態
前回議事録を探す	保存場所が人によって違う	テンプレートまたは前回分から自動コピー
日付を更新する	古い日付のまま残る	開催日を自動挿入
ファシリテーターを確認する	担当者表を見に行く必要がある	担当者リストから自動取得
Slackに投稿する	朝の投稿忘れ、URL貼り間違い	指定時刻に自動投稿
エラー確認	動かなかったことに気づかない	管理者チャンネルへ失敗通知
Teams招待	時間設定ミス、重複招集	Outlook予定表確認から招待作成まで自動化

特に負荷が大きいのは、「小さいが毎週発生する作業」です。

1回3分でも、毎週・複数チーム・複数会議で積み上がります。しかも、こうした作業は集中力を削ります。CS担当者やマネージャーが本来向き合うべき顧客対応、メンバー育成、案件レビューといったコア業務から注意を奪うわけですね。

現場感としては、次のような会話が出てきたら自動化のサインです。

「今日の議事録ってどれですか？」
「ファシリ、誰でしたっけ？」
「先週のテンプレをコピーしておきます」
「Slack通知、誰か出しました？」
「Teamsの招待、入っていない人がいます」

この状態が続くと、会議の質以前に、チームの空気が少しずつ重くなります。
「また準備が抜けた」という疲労感が、定例会議そのものへの不信につながるためです。

改善方針

改善方針は、いきなり大規模なワークフロー基盤を作ることではありません。

まずは「毎週同じこと」を機械に渡します。
そのうえで、人が判断すべき部分だけを残します。

短期と中期に分けると、次のようになります。

短期：1週間で始める自動化

まずはGASとSlackで、次の3点を自動化します。

1. Googleドキュメントの議事録テンプレートをコピーする
2. コピーした議事録に開催日・担当者名を挿入する
3. Slackへ議事録URLとファシリテーター名を通知する

この段階では、完璧な会議運営システムを目指さなくてよいです。

狙いは、「朝に誰かが慌てて議事録を作る状態」をなくすことです。

中期：予定表・Web会議URL・担当者割当まで広げる

次に広げる対象は、予定表と会議URLです。

Microsoft 365環境であれば、Power Automateを使い、Outlook予定表の確認からTeams招待の作成まで自動化できます。たとえば、参加者の予定を確認し、定例会議のTeams招待を作成するフローです。

ただし、ここは慎重に設計したいところです。

• 誤った時間で招待を作る
• 既存予定と重複する
• 退職者や異動者に招待が残る
• タイムゾーン設定がずれる
• 同じ会議が複数回作成される

こうしたミスは、全社員参加の会議では影響が大きくなります。

日程調整やWeb会議URL発行を安定運用したい場合は、カレンダー連携やZoom/Google Meet/Microsoft Teams連携に対応した日程調整ツールを組み合わせる選択肢もあります。Jicooは、Googleカレンダー、Outlook、Appleカレンダーとの連携、Zoom/Google Meet/Microsoft Teamsの会議URL自動発行、Slack通知連携が紹介されているため、定例会議の周辺業務を標準化する候補になります。詳細機能やプランは公開時点で要確認です。

自社でGASを書くか、日程調整ツールや連携ツールを使うかは、api を使える体制があるか、誰が保守するかで判断するとよいですね。

実装ステップ

ここでは、Google WorkspaceとSlackを使う前提で、1週間で始める手順を示します。

1日目：対象会議を1つに絞る

最初から全社の会議をすべて自動化しない方が安全です。

まずは、次の条件を満たす会議を1つ選びます。

• 毎週または隔週で開催される
• 議事録フォーマットがほぼ固定
• Slackで参加者に通知している
• ファシリテーターが持ち回り
• 参加者が10人以上いる、または準備漏れの影響が大きい

おすすめは、CSチームの週次定例や社内横断の進捗共有会です。

CSチームは顧客対応、更新確認、問い合わせ分析、エスカレーション対応など、会議以外のコア業務が多い部署です。だからこそ、社内会議 効率化の効果を体感しやすいですね。

2日目：議事録テンプレートを整える

Googleドキュメントで、定例会議用のテンプレートを作ります。

最低限、以下の項目を入れます。

• 会議名
• 開催日
• ファシリテーター
• 参加者
• 共有事項
• 決定事項
• ToDo
• 前回ToDoの確認
• 次回確認事項

自動差し込みしやすいように、テンプレート内には置換用の文字を入れます。

例：

• {{DATE}}
• {{FACILITATOR}}
• {{MEETING_TITLE}}
• {{PREVIOUS_DOC_URL}}

このとき、チームごとに自由記入できる余白も残しておきます。

テンプレートを固めすぎると、現場が「使わされている」と感じます。
逆に、見出しだけ揃えると、各チームが自分たちの言葉で更新できます。

この体験こそが価値です。

3日目：担当者リストを作る

Googleスプレッドシートで、ファシリテーターのローテーション表を作ります。

列はシンプルで十分です。

開催日	ファシリテーター名	SlackメンバーID	予備担当者	ステータス
2026-07-06	山田	UXXXXXXX	佐藤	未作成
2026-07-13	佐藤	UYYYYYYY	鈴木	未作成

ポイントは、Slack表示名ではなくSlackメンバーIDを持つことです。

表示名は変わることがあります。メンション通知を安定させたい場合は、SlackメンバーIDを使う方が安全です。Slack リマインド 自動送信では、この小さな設計が効きます。

4日目：GASで議事録を生成する

GASでやることは、ざっくり言うと次の5つです。

1. 今日の日付を取得する
2. スプレッドシートから今日の担当者を探す
3. 議事録テンプレートをコピーする
4. コピー後のドキュメント内で日付・担当者名を置換する
5. 生成した議事録URLをスプレッドシートへ記録する

定例MTG GAS スクリプトを作るときは、いきなり複雑にしないことが重要です。

最初の版では、次のような処理順にします。

• 設定値を読み込む
• 今日の会議があるか判定する
• 対象がなければ終了する
• 対象があればテンプレートをコピーする
• ドキュメント名を「会議名_YYYY-MM-DD」にする
• 置換文字を更新する
• URLを記録する
• Slack通知用の本文を作る

ここで大事なのは、処理結果を必ずどこかに残すことです。

「生成されたかどうか」がスプレッドシート上で見えるだけでも、運用担当者の安心感はかなり変わります。

5日目：Slack通知を設定する

Slack通知は、Incoming WebhookやSlack APIを使って送信します。どちらを使うかは、社内のセキュリティ方針に合わせて要確認です。

通知文は、短くします。

例：

本日の定例ミーティング議事録を作成しました。
議事録URL：{URL}
ファシリテーター：<@{SlackメンバーID}>
開始前にアジェンダの確認をお願いします。

通知に入れる情報は、最大でも次の4つです。

• 会議名
• 議事録URL
• ファシリテーター
• 開始時刻または事前確認依頼

Slack通知が長すぎると、読まれません。
通知が多すぎると、重要情報を見落とすリスクもあります。

6日目：時間主導トリガーを設定する

GASの時間主導トリガーを使い、会議当日の朝に処理を動かします。

たとえば、毎週月曜9:30に定例会議がある場合は、次のような設計です。

• 9:00：議事録を自動生成
• 9:05：SlackへURLと担当者を通知
• 9:10：管理者用チャンネルへ実行結果を通知
• 9:25：必要に応じて開始前リマインド

全社員参加の会議であれば、会議直前ではなく、少し余裕を持って通知するのがよいです。

朝9:30開催なのに9:29に通知が来ると、参加者は準備できません。
これは自動化していても、体験としては親切ではないですね。

7日目：テスト運用する

本番投入前に、必ずテストチャンネルで動かします。

確認項目は以下です。

• 議事録ファイル名が正しい
• 日付が正しい
• ファシリテーター名が正しい
• Slackメンションが正しく飛ぶ
• URL権限が参加者に開放されている
• 生成済みステータスが記録される
• エラー時に管理者へ通知される
• 同じ日に二重生成されない

特に、Googleドキュメントの共有権限は要注意です。

URLはSlackに流れているのに、参加者が開けない。
この状態は、現場のストレスを増やします。

運用ルール

自動化は、作って終わりではありません。

むしろ、社内全員が依存する仕組みほど、運用ルールが重要です。

ルール1：オーナーを1人にしない

GASを書いた人だけが直せる状態は危険です。

最低でも、以下を決めます。

• 主担当
• 副担当
• エラー時の一次対応者
• Slack通知文の変更承認者
• 担当者リストの更新者

退職・異動・休暇で止まらないように、属人化を避けます。

ルール2：エラー時の手動手順を残す

自動化が失敗したときに備えて、手動復旧手順を1ページにまとめます。

内容は、次の粒度がよいです。

1. テンプレートの保存場所を開く
2. 前回議事録またはテンプレートをコピーする
3. ファイル名を変更する
4. 日付と担当者を修正する
5. Slackへ定型文で投稿する
6. 管理者チャンネルに「手動対応済み」と報告する

自動化は便利ですが、停止時に誰も動けない状態は避けたいですね。

ルール3：通知チャンネルを分ける

Slack通知は、次の2種類に分けるのがおすすめです。

通知種別	投稿先	内容
参加者向け通知	定例会議チャンネル	議事録URL、担当者、開始前確認
管理者向け通知	運用管理チャンネル	実行成功、失敗、二重生成検知、権限エラー

参加者向けにエラー詳細を流す必要はありません。
逆に、管理者向けには原因特定に必要な情報を残します。

ルール4：変更履歴を残す

テンプレート、担当者リスト、GAS、Slack通知文を変更したら、変更日と理由を残します。

例：

変更日	対象	変更内容	変更者	理由
2026-07-02	通知文	開始前確認の一文を追加	情シス	アジェンダ未確認が多かったため
2026-07-09	担当者表	異動に伴い担当者を更新	CS Ops	メンバー変更

このような地味な運用が、半年後の保守負担を下げます。

ルール5：Teams招待の自動化は段階導入にする

Power AutomateでOutlook予定表確認からTeams招待まで自動化する場合は、最初から全社予定に反映しない方が安全です。

推奨は次の順番です。

1. テスト用アカウントで予定作成
2. 小規模チームでTeams 招待 自動化を試す
3. 重複予定やタイムゾーンの検知を入れる
4. 管理者承認後に本番予定へ反映する
5. 招待送信後のログを残す

OutlookやTeamsの自動招集では、誤った時間設定や重複招集に注意が必要です。
ここは「便利だから自動化する」より、「事故が起きても検知できるから自動化する」という順番で考えるべきですね。

KPI設計

自動化の効果は、感想だけで終わらせない方がよいです。

ただし、最初から厳密なROIを出す必要もありません。
現場の疲労感を減らす取り組みなので、定量と定性の両方で見ます。

KPI1：会議準備にかかる手作業時間

測定方法：

• 導入前：担当者が議事録準備とSlack通知に使った時間を3回分メモする
• 導入後：手動対応が必要だった時間だけを記録する

見るポイント：

• 議事録コピーにかかる時間
• 日付・担当者更新にかかる時間
• Slack投稿にかかる時間
• URL確認にかかる時間

「1回あたり数分」でも、毎週積み上がると無視できません。

KPI2：準備漏れ・通知漏れの件数

記録するイベントは次の通りです。

• 議事録が作られていなかった
• URLが間違っていた
• Slack通知がなかった
• ファシリテーターが誤っていた
• 参加者が議事録を開けなかった
• Teams招待が届いていなかった

月次で件数を見ます。

ここで重要なのは、犯人探しにしないことです。
ミスを責めるのではなく、仕組みで減らす。これが心理的安全性につながります。

KPI3：会議開始前の準備完了率

定例会議の開始時点で、次が揃っているかを見ます。

• 議事録URL
• アジェンダ
• ファシリテーター
• 前回ToDo
• 参加URL
• 関係者への通知

チェックは、会議開始5分前で十分です。

「開始時に全員が同じページを見られる」状態は、会議の質をかなり左右します。

KPI4：参加者の体感

月1回、簡単なアンケートを取ります。

質問は3つでよいです。

1. 議事録URLを探す手間は減りましたか
2. ファシリテーター確認の不安は減りましたか
3. 定例会議の開始がスムーズになりましたか

5段階評価と自由記述を組み合わせます。

数字だけでは見えない変化があります。
たとえば「朝のバタつきが減った」「担当者が明確で助かる」「会議前に少し余裕ができた」といった声です。

この余裕が、チームの雰囲気を変えます。

KPI5：エラー検知から復旧までの時間

自動化で見落としがちなのが、エラー対応です。

測定すべきは以下です。

• エラー発生時刻
• 検知時刻
• 一次対応開始時刻
• 手動復旧完了時刻
• 原因
• 再発防止策

全社員参加の定例オンライン会議では、エラーに気づかないこと自体がリスクです。

GASスクリプトのメンテナンス負担や権限設定も含め、運用品質として見る必要があります。

自動化の実装例

ここでは、全社員参加の週次オンライン定例を想定した実装例を紹介します。

比較基準日：2026-07-02

想定する会議

• 会議名：全社週次定例
• 開催頻度：毎週月曜
• 開催形式：オンライン
• 議事録：Googleドキュメント
• 担当者表：Googleスプレッドシート
• 通知：Slack
• 進行：ファシリテーター持ち回り

国内の実践事例でも、週次の全社オンライン定例会議において、GASでGoogleドキュメントのレポートを自動生成し、開催日の朝にSlackで議事録URLとファシリテーターを通知する運用が紹介されています。前週内容を引き継ぎ、当日の日付や担当者名を挿入する設計です。

ここで学べるのは、技術の珍しさではありません。

「毎週の面倒な準備を、人間の記憶に頼らない形に変えた」ことです。

実装の全体像

処理は、次の流れにします。

1. GASの時間主導トリガーが起動する
2. 今日が定例会議の開催日か確認する
3. スプレッドシートから担当者情報を取得する
4. 議事録テンプレートをコピーする
5. ファイル名に日付を入れる
6. ドキュメント本文の置換文字を更新する
7. 生成したURLをスプレッドシートに保存する
8. Slackへ参加者向け通知を送る
9. 管理者向けチャンネルへ実行ログを送る

スプレッドシート設計

シートは3つに分けると管理しやすいです。

シート名	役割	主な列
Settings	固定設定	テンプレートID、保存先フォルダID、Slack Webhook URL
Facilitators	担当者管理	開催日、担当者名、Slack ID、予備担当者
Logs	実行履歴	実行時刻、結果、議事録URL、エラー内容

Settingsシートに認証情報やWebhook URLを置く場合は、閲覧権限に注意してください。
社内ポリシーによっては、GASのプロパティサービスなど別管理が必要です。ここは要確認です。

議事録テンプレート設計

テンプレートには、以下のような構造を入れます。

セクション	目的
基本情報	会議名、日付、ファシリテーター
今週の共有	各部署・各チームの共有事項
CS共有	顧客要望、問い合わせ傾向、解約リスク、アップセル機会
決定事項	会議で決まった内容
ToDo	担当者、期限、次回確認
前回からの継続	未完了タスクや保留事項

CSチームが関わる場合、「顧客の声」が埋もれない構造にすることが大切です。

定例ミーティング 自動化 CSの文脈では、単に議事録作成を楽にするだけでなく、顧客接点から得た情報を社内に流通させる意味があります。

Slack通知文の例

通知文は、次のようにします。

おはようございます。
本日の全社週次定例の議事録を作成しました。

議事録URL：{生成URL}
本日のファシリテーター：<@{Slack ID}>
開始前に、各チームの共有事項を追記してください。

エラーや権限不備があれば、このスレッドでお知らせください。

ここで「このスレッドでお知らせください」と書いておくと、問い合わせが分散しにくくなります。

管理者向けログ通知の例

参加者向け通知とは別に、管理者には次の情報を送ります。

全社週次定例の自動生成が完了しました。
実行時刻：2026-07-02 09:00
担当者：山田
議事録URL：{URL}
ステータス：成功

失敗時は、最低限以下を入れます。

• どの処理で失敗したか
• 対象日
• 担当者
• エラーメッセージ
• 手動復旧手順への案内

高度な運用にするなら、同じ日に二重生成されそうな場合に処理を止めるチェックを入れます。これはツールなし・ログなしでは管理が難しいポイントです。

たとえば、Logsシートに同日の成功履歴がある場合は、次の挙動にします。

1. 新規生成を止める
2. 管理者チャンネルに「同日生成済み」と通知する
3. 既存の議事録URLを再掲する
4. 必要なら管理者が手動で再生成する

この「二重生成防止」は、地味ですが非常に効きます。
議事録が2つできると、参加者がどちらに書けばよいか迷うためです。

Power Automateで広げる場合

Microsoft 365環境では、Power Automateで次のようなフローも考えられます。

1. Outlook予定表から定例会議の予定を取得する
2. 参加者と時間を確認する
3. Teams会議を作成する
4. 招待メールを送る
5. Teamsチャネルへ通知する
6. 実行結果を管理者へ通知する

ただし、Teams 招待 自動化では、重複招集と時間設定ミスに注意が必要です。

特に、既存の繰り返し予定がある場合、新しい招待を追加で作ってしまうと混乱します。
まずは小規模チームでテストし、手動確認を挟む設計から始めるのが現実的です。

日程調整ツールと組み合わせる場合

GASとSlackは、社内定例の「議事録生成」と「通知」に向いています。

一方で、次のような領域は専用ツールの方が運用しやすい場合があります。

• 外部参加者を含む日程調整
• 複数カレンダーの空き時間確認
• Web会議URLの自動発行
• 担当者の自動割当
• フォーム回答による振り分け
• Slackへの予約通知
• SalesforceなどCRMとの連携

Jicooは、日程調整の自動化を主目的としたツールとして紹介されており、Googleカレンダー/Outlook/Appleカレンダー連携、Zoom/Google Meet/Microsoft Teams連携、予約時の会議URL自動発行、担当者自動割当、Slack通知連携、Salesforce連携、REST API提供の記述があります。

社内定例はGASで軽く始め、外部商談・CS面談・採用面談のように関係者が増える会議は日程調整ツールで標準化する。
この分担は、現実的な落としどころではないでしょうか。

会議と周辺業務の改善アイデアは、blog や meeting の観点でも整理できます。

まとめ

社内 定例会議 自動化で最初に狙うべきなのは、大きなDXではありません。

毎週発生する、次のような小さな負担です。

• 議事録テンプレートを探す
• 前回分をコピーする
• 日付を直す
• ファシリテーターを確認する
• SlackへURLを投稿する
• 通知漏れに気づいて慌てる

GASとSlackを使えば、これらの多くを自動化できます。
Power Automateを使えば、Outlook予定表やTeams招待まで広げることも可能です。

ただし、社内全員が依存する仕組みには、エラー時の対応策が必要です。

• 管理者向けログ通知を入れる
• 手動復旧手順を残す
• オーナーを複数人にする
• 通知を増やしすぎない
• 権限設定を定期的に確認する
• 二重生成や重複招集を防ぐ

定例ミーティング 自動化 CSの本質は、会議を「楽にする」ことだけではありません。

CS担当者やマネージャーが、顧客理解、チーム支援、意思決定といったコア業務に戻れる時間を作ることです。
そして、会議前の小さな不安を減らし、チームの雰囲気を少し軽くすることです。

次のアクションとしては、まず1つの定例会議を選び、議事録テンプレートと担当者表を作るところから始めてみてください。

最初の自動化は、完璧でなくて大丈夫です。
「朝、誰かが慌てなくて済む」状態を1つ作る。そこから、会議運用は変わり始めます。