社会保険労務士事務所が顧問先へ毎月送る法改正・助成金のニュースレターを、所員が書いた公表資料のメモから下書きし、顧問先の業種ごとの注意点を添える
所員が公表資料を読んで書いたメモから、顧問先へ送るニュースレターの共通の本文と、業種ごとの注意点の下書きを作ります。顧問先ごとの版は、台帳の業種と雇用形態から欄を選んで組み立てます。
- 生成AI
- Claude/Gemini
- 連携・自動化
- Make/n8n/Power Automate/Zapier
- 対象業界
- 介護/士業/小売/建設/飲食
- 対象部門
- 人事/総務
- 対象業務
- 書類作成
- 主な課題
- 人手が足りない/属人化している/書類作成に時間がかかる
- AIで行う処理
- 生成
- 主な効果
- 品質標準化/工数削減/機会損失防止
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 半自動化
- 費用感
- ノーコード連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 所員が月中に公表資料を見て、気になったものを共有メモに書く
- 毎月20日ごろ、担当者がメモを読み返し、その月に載せる話題を4〜6本選ぶ
- 話題ごとに、原文を開き直して顧問先向けの本文を書く
- 業種ごとに、その話題がどう効くかの注意点を書き分ける
- 顧問先台帳を見ながら、顧問先ごとに載せる話題と注意点を選び、文書ファイルを複製して組み立てる
- 「御社の場合」の一言を書き、宛名と担当者名を差し替える
- PDFにして、顧問先ごとにメールで送る
- 人所員が公表資料を読み、決めた書式でメモを書く(出典URL、所管、種別、施行日・期限、対象、要点)
- 人担当の社労士が、その月に載せるメモに印を付け、対象の印(業種、有期雇用、外国人雇用など)を確かめる
- 自動毎月20日にシナリオが動き、印の付いたメモを読む
- 自動生成AIが、メモごとに共通の本文の下書きを作る
- 自動生成AIが、メモと業種の組み合わせごとに注意点の下書きを作る
- 人担当の社労士が、共通の本文と業種ごとの注意点を確かめ、直す(ここが唯一の本格的な確認です)
- 自動顧問先台帳とメモの対象の印を突き合わせ、顧問先ごとに載せる話題と注意点を規則で選ぶ
- 自動テンプレートから顧問先ごとの文書を作り、送付用の下書きを用意する
- 人担当の所員が、顧問先ごとの版を一覧で流し見て、「御社の場合」の一言を足して送る
各工程の詳しい説明を読む
- 所員が月中に公表資料を見て、気になったものを共有メモに書く
- 毎月20日ごろ、担当者がメモを読み返し、その月に載せる話題を4〜6本選ぶ
- 話題ごとに、原文を開き直して顧問先向けの本文を書く
- 業種ごとに、その話題がどう効くかの注意点を書き分ける
- 顧問先台帳を見ながら、顧問先ごとに載せる話題と注意点を選び、文書ファイルを複製して組み立てる
- 「御社の場合」の一言を書き、宛名と担当者名を差し替える
- PDFにして、顧問先ごとにメールで送る
(a)3番と4番が特定の所員に寄る。 本文は誰でも書けますが、業種ごとの注意点は経験のある所員でないと書けません。その所員が繁忙期に入ると、ニュースレター全体が遅れます。 月末の算定基礎や年度更新の時期と重なると、翌月にずれ込むこともあります。
(b)5番の組み立てで取り違えが起きる。 120社分の文書を複製して欄を差し替えるので、飲食の顧問先に建設の注意点が残る、前月の一言が消えずに残る、といった取り違えが毎月数件起きます。
(c)メモに無い事実が本文に入る。 書く人が原文を開き直さず、記憶で施行日や対象を書くことがあります。メモと本文のどちらが正しいのか、後から誰も確かめられません。
(d)助成金の書き方が人によって違う。 「使えます」と書く人と「要件を確認しましょう」と書く人がいます。受給を約束するような書き方は、顧問先との行き違いのもとです。
- 【人】 所員が公表資料を読み、決めた書式でメモを書く(出典URL、所管、種別、施行日・期限、対象、要点)
- 【人】 担当の社労士が、その月に載せるメモに印を付け、対象の印(業種、有期雇用、外国人雇用など)を確かめる
- 【自動】 毎月20日にシナリオが動き、印の付いたメモを読む
- 【自動】 生成AIが、メモごとに共通の本文の下書きを作る
- 【自動】 生成AIが、メモと業種の組み合わせごとに注意点の下書きを作る
- 【人】 担当の社労士が、共通の本文と業種ごとの注意点を確かめ、直す(ここが唯一の本格的な確認です)
- 【自動】 顧問先台帳とメモの対象の印を突き合わせ、顧問先ごとに載せる話題と注意点を規則で選ぶ
- 【自動】 テンプレートから顧問先ごとの文書を作り、送付用の下書きを用意する
- 【人】 担当の所員が、顧問先ごとの版を一覧で流し見て、「御社の場合」の一言を足して送る
6番目が、この設計の分かれ目です。人が丁寧に見るのは、顧問先ごとの120件ではありません。 話題が5本、業種が8区分なら、確かめるのは共通の本文5本と注意点40本です。ここを確かめ終えれば、顧問先ごとの版は同じ部品の組み合わせなので、9番目は流し見で足ります。
7番目を規則で決めるのも、意図してのことです。 どの顧問先にどの話題を載せるかをAIに選ばせると、載せなかった理由が残りません。 「なぜうちには助成金の案内が無かったのか」と聞かれたときに、台帳の列とメモの印で答えられるようにします。
02今回想定するシステム構成
所員が公表資料を読む(厚生労働省・日本年金機構・労働局など) │ 決めた書式でメモを書く ▼ 公表資料メモ(スプレッドシート)── 社労士が掲載の印と対象の印を付ける ▼【トリガー】毎月20日の定時実行 Make ├──▶ 印の付いたメモを読む ├──▶ Claude ── メモごとの共通の本文(JSON) ├──▶ Claude ── メモ×業種ごとの注意点(JSON) ▼ 確認用の一覧(スプレッドシート)── 社労士が確かめて「確定」にする ▼【トリガー】確定の印 Make ├──▶ 顧問先台帳と対象の印を突き合わせる(規則) ├──▶ Google ドキュメントのテンプレートから顧問先ごとの版を作る ▼ 送付用の下書き ── 所員が一言を足して送る
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| ワークフロー | Make | n8n、Zapier、Power Automate |
| 生成AI | Claude(Make の Anthropic Claude アプリ) | OpenAI、Gemini |
| メモと台帳 | Google スプレッドシート | Microsoft 365 の表計算 |
| 文書の作成 | Google ドキュメント | Microsoft 365 の文書 |
| 送付 | メール(下書きまで) | 顧問先との共有フォルダ |
顧問先台帳とメモは、新しく足すものではありません。 台帳には、業種の区分と、有期雇用・外国人雇用・派遣の受入れ・36協定の有無といった対象の判定に使う列を足すのが最初の準備作業です。 従業員の個人名は要りません。
生成AIは、Make の Anthropic Claude アプリから呼びます。 接続は Anthropic のコンソールで作った API キーを Make の接続画面に入れる形で、Create a Prompt のモジュールでモデルとプロンプトを指定して応答を受け取ります。無料プランでは使えるモデルが限られるとされているため、試すときと本番とでモデルが変わらないよう、有料プランを前提にします。アプリにはほかに、API を直接呼ぶ Make an API Call のモジュールがあります。
JSONで受け取りたいときは、Make an API Call で Messages API を呼びます。 Claude の API では、output_config.format に type: "json_schema" とスキーマを渡すと、スキーマに沿ったJSONで応答が返る構造化出力が使えます。共通の本文と注意点は、施行日や出典の欄を別々に受け取りたいので、こちらを使います。
文書の作成は、Google ドキュメントの Create a Document from a Template のモジュールで行います。 テンプレートの文書を複製し、文中のタグを指定した値で置き換えるモジュールで、作った文書を指定のドライブとフォルダへ置けます。顧問先ごとの版は、宛名、話題ごとの本文、業種の注意点のタグを差し替えて作ります。
03どうやって実装するのか
処理の起点を決める
シナリオは2本に分けます。 1本目は毎月20日の定時実行で、印の付いたメモを読み、共通の本文と注意点の下書きを確認用の一覧へ書き出します。2本目は、確認用の一覧で社労士が「確定」にしたことを起点に、顧問先ごとの版を作ります。
1本にまとめないのは、間に人の確認を挟むためです。 下書きから顧問先ごとの版まで一息に作ると、確かめる前の文章が120社分に複製されます。直すべき1か所が、120か所に増えます。
20日にしているのは、月末の手続の締切から逆算した日付です。 確認に2〜3営業日、送付に1営業日を見ると、月末の繁忙期の前に送り終えられます。メモの締切は前日の19日とし、20日以降に書かれたメモは翌月に回します。 急ぎの改正があれば、1本目を手で動かします。
公表資料の取り込みを自動にしないことも、トリガーの設計の一部です。 厚生労働省は新着情報を RSS で提供していますが、RSS のページには、配信された情報に基づくメールマガジンの作成や情報の再配布を断る旨が書かれています。 RSS の内容をそのままニュースレターの材料に流し込む設計にはしません。所員が原文を読み、自分の言葉でメモを書くところを起点にします。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 公表資料メモ | メモID、出典URL、所管、種別(法改正/助成金/手続/統計)、公表日、施行日・期限、対象、要点、掲載の印、対象の印 | 公表資料メモのスプレッドシート |
| 業種の区分 | 介護、建設、飲食、小売、運送、IT、製造、その他の8区分と、区分ごとの働き方の特徴(シフト制、日給月給、深夜業の有無など) | 事務所で用意する一覧 |
| 顧問先台帳 | 顧問先コード、業種の区分、従業員数の帯、有期雇用・外国人雇用・派遣の受入れの有無、担当所員 | 顧問先台帳 |
| 文体の決まり | 事務所の言い回し、使わない表現の一覧(「必ずもらえる」「確実に」など) | 事務所で用意する一覧 |
質を決めるのは、いちばん上のメモです。 メモの要点が3行で書かれていれば、AIはそれを読める文章に直せます。メモが「育休関係で何か改正あり」だけなら、AIは何も足せません。 足させないように作っているので、下書きは空欄だらけになります。それで正しい動きです。
業種の区分には、働き方の特徴を書いておきます。 「介護:シフト制、夜勤あり、有期雇用が多い」と書いてあれば、AIは改正がどこに効くかを書き分けられます。特徴の書いていない区分は、注意点が一般論になります。
顧問先台帳から生成AIへは何も渡しません。 台帳は、7番目の規則で欄を選ぶためだけに Make の中で使います。顧問先の名前も従業員数も、AIの入力には入りません。
データの取得方法を決める
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 掲載の印が付いたメモ | Google スプレッドシートの行の検索 | 共通の本文と注意点の材料 |
| 業種の区分と特徴 | 同じく行の検索 | 注意点を書き分ける材料 |
| 文体の決まり | 同じく行の読み取り | プロンプトに差し込む |
| 顧問先台帳 | 同じく行の検索(2本目のシナリオ) | 顧問先ごとに載せる欄の選択 |
| テンプレートの文書 | Google ドキュメント | 顧問先ごとの版の型 |
メモは、掲載の印と公表日で絞って読みます。 印の付いていないメモは、所員の勉強用として残しておいてかまいません。印を付けるのは社労士の仕事で、ここだけはAIに選ばせません。 どの話題を顧問先に伝えるかは、事務所の判断そのものだからです。
メモの出典URLは、AIへ渡す前に Make の側で形を確かめます。 https:// で始まらないもの、空欄のものは、そのメモを下書きの対象から外して確認用の一覧に「出典なし」と書きます。出典の無い事実を、顧問先へ送る文章にしないためです。
AIへ渡す前に整形する
- 出典の確認 … 出典URLが無いメモは対象から外し、書いた所員に戻します
- 施行日・期限の形の確認 … 日付の列が日付として読めるかを確かめます。「10月から」のような書き方は、メモの段階で日付に直してもらいます
- 掲載本数の確認 … 掲載の印が付いたメモが3本未満、または8本を超えるときは、社労士に通知して止めます
- 対象の印の確認 … 対象の印が空のメモは「全顧問先」として扱わず、確認用の一覧に「対象未設定」と書きます
- 助成金のメモの確認 … 種別が助成金のメモに、制度の名称、問い合わせ先、要領の改定日のどれかが欠けていれば、そのまま止めます
- 前月との重複の確認 … 同じ出典URLのメモが前月に掲載済みなら、「続報」の印を付けて下書きの書き方を変えます
4番目を「全顧問先」にしないのは、取り違えの多くがここから出るためです。 対象が空のメモを全社に載せると、外国人を雇っていない顧問先に在留資格の手続の話が届きます。 印が無いことは、確かめていないことだと扱います。
5番目は、助成金の案内の質を守るためです。 厚生労働省の雇用関係助成金のページには、共通要領の Q&A を更新したお知らせが日付付きで載っています。要領はこうして改定されていくので、いつ時点の要領を見て書いたメモかを残しておかないと、翌月には古い案内になります。
AIに処理させる
させるのは2つだけです。メモを顧問先向けの本文に直すことと、業種ごとの注意点を書き分けることです。
| させること | 入力 | 出力 |
|---|---|---|
| 共通の本文の下書き | メモ1本、文体の決まり | 見出し、本文(400字程度)、施行日・期限、出典URL、確認が要る点 |
| 業種ごとの注意点 | メモ1本、業種の区分1つとその特徴 | 注意点(150字程度)、見直しの候補になる書類の種類、関係が薄い場合はその旨 |
注意点は、関係が薄い業種には書かせません。 すべての組み合わせで何か書かせると、建設の会社に「深夜業の改正にご注意ください」のような当てはまらない注意が並びます。 関係が薄いと判断したら relevance を low にして、注意点を空にさせます。載せるかどうかは、後段の規則と社労士の確認で決めます。
| させないこと | 理由 |
|---|---|
| メモに無い事実(施行日、金額、対象の範囲)の追加 | 原文を読んでいないAIが書くと、確かめる手段が無い |
| 助成金を受けられるかの判断 | 要件を満たすかは個々の顧問先の事情で、社労士が判断する |
| 法令の解釈を断定すること | 解釈は社労士の仕事。文章は「〜とされています」でメモに沿わせる |
| 掲載する話題の選択 | 何を伝えるかは事務所の判断 |
| 顧問先ごとの欄の選択 | 規則で決め、理由を残す |
| 出典URLの書き換え | メモのURLをそのまま写す |
1行目が、いちばん起きやすい失敗です。 生成AIは、メモに「来年4月施行」とあれば、知っている範囲で経過措置や対象の規模を書き足そうとします。それが正しくても、所員が原文で確かめていない事実は送れません。
前処理で「続報」の印が付いたメモは、書き方を変えさせます。 前月に送った本文をあわせて渡し、「前月にお知らせした件の続き」として、変わった点だけを書かせます。 同じ改正を毎月一から説明すると、顧問先の担当者は読み飛ばすようになります。変わった点がメモから読み取れなければ、続報として載せずに needs_check に書かせます。
指示内容を固定する
あなたは社会保険労務士事務所の所員として、顧問先の人事・総務の担当者に
送るニュースレターの下書きを書きます。
【入力】
- メモ:所員が公表資料を読んで書いたもの。これが唯一の事実の根拠です
- 業種の区分とその特徴(注意点を書くときだけ渡します)
- 文体の決まり
【書くもの】
1. 見出し(30字以内)
2. 本文(400字程度)。何が変わるのか、いつからか、顧問先が何をすればよいか
3. 業種の注意点(150字程度)。この業種の働き方の特徴に照らして、
どの書類・どの運用に関係しそうかを書く
【厳守事項】
- メモに書かれていない事実を書かないでください。施行日、期限、金額、
対象となる企業の規模、経過措置は、メモに無ければ書かないでください。
- メモに書かれていても読み取れない点は、本文に書かず、
needs_check に「メモで確認が要る点」として書いてください。
- 日付と数字は、メモの表記のまま写してください。言い換えないでください。
- 出典URLはメモのものをそのまま source_url に入れてください。
- 助成金について「受けられます」「もらえます」と書かないでください。
「要件に当てはまるかは個別に確認が必要です」と書いてください。
- 法令の解釈を断定しないでください。「〜とされています」と書いてください。
- 業種の注意点で、この業種への関係が薄いと判断した場合は、
relevance を low にし、caution を空にしてください。
無理に注意点を作らないでください。
- 見直しの候補になる書類は、就業規則、賃金規程、労働条件通知書、
36協定、育児・介護休業規程、雇用契約書 の中から選んでください。
- 使わない表現:{banned_phrases}
【メモ】{memo}
【業種の区分と特徴】{industry_profile}
【文体の決まり】{style_rules}
「メモに無ければ書かない」を、項目を並べて書いています。 「推測しないでください」だけでは、施行日や対象の規模のようにAIが知っていそうな事実ほど書き足されます。 書いてはいけない項目を名前で挙げると、守られやすくなります。
見直しの候補の書類を6種類に限っているのは、後段で集計するためです。 自由に書かせると「就業規則等」「社内規程」と表記が揺れ、顧問先ごとに「見直す書類」の欄を作るときにまとめられません。
出力形式を固定する
共通の本文は、次の形のJSONで受け取ります。
{
"memo_id": "M-2026-10-03",
"headline": "",
"body": "",
"effective_date": "",
"source_url": "",
"needs_check": [""],
"used_banned_phrase": false
}
業種ごとの注意点は、組み合わせごとに次の形で受け取ります。
{
"memo_id": "M-2026-10-03",
"industry": "介護",
"relevance": "high | medium | low",
"caution": "",
"documents_to_review": ["就業規則", "労働条件通知書"],
"needs_check": [""]
}
1つ目の理由は、施行日と出典を本文と別の欄に持てることです。 確認用の一覧で、effective_date とメモの施行日を並べて表示し、一致しないものに色を付けます。 社労士は本文を読む前に、日付と出典が写されているかを一目で確かめられます。
2つ目は、relevance で載せる組み合わせを絞れることです。 確認用の一覧では、low の組み合わせを最初から折りたたんでおきます。社労士が開くのは high と medium だけです。 low を載せたい場合は、社労士が手で上げます。
3つ目は、needs_check が空でないものを先に見られることです。 メモが足りない点をAIが書き出しているので、確認の順番が決まります。 ここに何か書かれている下書きは、メモを書いた所員に戻すのが早道です。
顧問先ごとの欄を選ぶ規則は、Make の側に置きます。
| 規則 | 内容 |
|---|---|
| 話題を載せる | メモの対象の印と、顧問先台帳の列が1つでも重なる |
| 業種の注意点を載せる | 顧問先の業種の区分で relevance が high か medium、かつ社労士が確定にしたもの |
| 助成金の欄を載せる | 上記に加え、担当所員が台帳で「案内可」にしている |
| 載せない | 対象未設定のメモ、出典なしのメモ |
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 公表資料メモ | Make の Google スプレッドシートのモジュール | 印の付いたメモを読む |
| Claude | Make の Anthropic Claude アプリ(Make an API Call) | 共通の本文と注意点をJSONで受け取る |
| 確認用の一覧 | Google スプレッドシートへの書き込み | 下書きと、メモとの日付の一致を並べる |
| 顧問先台帳 | Google スプレッドシートの読み取り | 欄を選ぶ規則に使う |
| テンプレート | Google ドキュメントの Create a Document from a Template | 顧問先ごとの版を作る |
| メール | 下書きの作成まで | 送信は所員が行う |
顧問先台帳には書き込みません。 載せた話題の履歴は、別の送付記録の表に書きます。台帳は顧問先との契約の内容を持つ表で、ここに自動で書き込む経路を作らないためです。
メールは下書きまでです。 顧問先ごとの版を作った後、担当の所員が一言を足して送ります。自動で送ると、確定前の版や、取り違えた版がそのまま届きます。
人が確認する
確認は2段階です。丁寧に見るのは1段目だけです。
- 社労士が共通の本文を確かめる …
effective_dateとメモの施行日が一致しているか、source_urlがメモのものか、needs_checkに何が書かれているかを先に見ます。そのうえで本文を読み、言い回しを直します - 社労士が業種ごとの注意点を確かめる …
highとmediumの組み合わせだけを開きます。その業種の働き方に照らして当たっているかを見ます。 直したら「確定」にします - 所員が顧問先ごとの版を流し見る … 宛名、業種の注意点が顧問先の業種と合っているか、助成金の欄の有無を見ます
- 所員が「御社の場合」の一言を足す … 前月の面談の内容など、所員しか知らないことを書きます。ここはAIに書かせません
2番目で直した内容は、業種の区分の特徴に戻します。 「介護の注意点で毎回夜勤の話を落とす」と分かれば、介護の区分の特徴に夜勤の書き方を足します。直した結果を入力の側に戻すと、翌月の下書きが良くなります。
4番目をAIに書かせないのは、ニュースレターが顧問先との関係の道具だからです。 一言は短くても、担当者が自分で書いたものだと伝わることに意味があります。
1番目と2番目は、同じ社労士が続けて見るのが効率的です。 共通の本文を読んだ直後なら、メモの中身が頭に入っているので、業種ごとの注意点の当たり外れを短い時間で判断できます。本文と注意点を別の人に分けると、それぞれがメモを読み直すことになります。 社労士が不在の月は、確認を後ろにずらしても送付を急がない、と事務所で決めておきます。
例外に対処する
| 起きること | 対応 |
|---|---|
| 出典URLが無いメモ | 下書きの対象から外し、書いた所員に戻す |
| 施行日の形が読めない | メモの段階で日付に直してもらう。下書きは作らない |
effective_date がメモと一致しない | 確認用の一覧で色を付け、その本文は確定にできないようにする |
| 本文に使わない表現が入った | used_banned_phrase に加え、Make の側でも一覧の語を検索して印を付ける |
| 対象の印が空のメモ | どの顧問先にも載せない。「対象未設定」として社労士へ |
| 掲載本数が少なすぎる・多すぎる | シナリオを止めて社労士に通知する |
| 急ぎの改正が20日以降に出た | 1本目のシナリオを手で動かすか、翌月に回す。判断は社労士 |
| 生成AIが応答しない・JSONが壊れている | そのメモだけ再実行し、2回失敗したら一覧に「生成失敗」と書く |
| 顧問先の業種の区分が台帳で空 | 業種の注意点を載せずに版を作り、所員に台帳の更新を頼む |
3行目を「確定にできない」としているのは、日付の誤りがもっとも重いためです。 施行日が1か月ずれた案内は、顧問先の就業規則の改定の時期を狂わせます。
記録を残す
- 掲載したメモの内容と、そのときの出典URL・施行日
- 生成AIへ渡したプロンプトと、返ってきたJSONの全文
- 社労士が直す前と直した後の本文・注意点
- 顧問先ごとに、載せた話題・注意点・助成金の欄と、それを選んだ規則
- 送付した日時と、送付した版のファイル
4つ目の「選んだ規則」は、問い合わせへの答えになります。 「なぜうちには載っていないのか」と聞かれたとき、台帳のどの列とメモのどの印で外れたのかを示せます。 台帳が古かったのなら、台帳を直せば翌月から載ります。
3つ目の「直す前と後」は、業種の区分の特徴を見直す材料です。 同じ区分で同じ直しが続くなら、特徴の書き方が足りていません。
04実装レベルの3段階
本記事の想定は半自動化です。 1件15分が5分になるのは、共通の本文と注意点の下書きが1回で済み、顧問先ごとの組み立てと宛名の差し替えが手作業から外れるためです。残る5分は、確認の按分と、所員が一言を足して送る時間です。 最小構成から半自動化へ進む前に、メモの書式をそろえてください。 書式がばらばらのまま Make で読むと、出典なしと対象未設定で多くのメモが止まります。止まること自体は正しい動きですが、最初の月に半分が止まると使われなくなります。 本格構成は、半自動化を数か月回してからで足ります。 顧問先からの反応を集める仕組みは、事務所ごとに送り方が違うため、ここでは扱いを限ります。
05工数削減シミュレーション
導入後 120件 × 5分 ÷ 60 = 10 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 顧問先が100社前後あり、毎月の法改正・助成金の案内を顧問先ごとに送っている社会保険労務士事務所。業種がばらばらで、同じ改正でも介護・建設・飲食で伝えるべき点が違い、書き分けが特定の所員に寄っている場合。公表資料を読んだ所員がメモを残す習慣があり、メモの書式をそろえる合意が取れる場合。顧問先の業種・規模・雇用形態の有無を台帳で持っている場合。
- 顧問先が数社で、案内を電話や面談で済ませている場合。ニュースレターを市販の定型記事の購入で賄っており、自所で書く部分がほとんど無い場合。公表資料を読んでメモを残す人がおらず、元になる事実を所内で用意できない場合。なお、個々の顧問先に助成金の要件を満たすかを判断すること、法令の解釈を示すことは、この構成では代替しません。
07最小構成で試す方法
- 先月のメモから、載せた話題を3本選ぶ
- 業種の区分を3つ選び(たとえば介護、建設、飲食)、それぞれの働き方の特徴を3行ずつ書く
- 手元の生成AIのサービスに、メモ1本と業種の特徴1つを貼り、第7章のプロンプトで本文と注意点を書かせる
- 3本×3業種=9本の注意点を、先月実際に送った文章と並べる
- メモに無い事実が書き足されていないかを、1本ずつ確かめる
5番目を最優先で見てください。 文章のうまさより先に、施行日や対象の規模が勝手に足されていないかを確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 先月の注意点と同じ論点が出た | Make とのつなぎに進む |
| メモに無い事実が書き足された | 指示の書き方で直る。書いてはいけない項目を名前で足す |
| 注意点が一般論ばかり | 業種の特徴の書き方が足りない。AIより入力の問題 |
needs_check が多い | メモの書き方を見直す。所員のメモの書式を先にそろえる |
4行目が出たら、それは収穫です。 これまで記憶で補っていた部分が、メモに書かれていなかったということです。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| メモに無い施行日や対象を書き足す | 書いてはいけない項目を名前で挙げる。 effective_date をメモと突き合わせる |
| すべての業種に注意点を書く | relevance を low にさせ、無理に書かせない |
| 助成金を「受けられる」と書く | 使わない表現の一覧をプロンプトと Make の両方で見る |
| 対象の印が空のメモが全社に載る | 対象未設定はどこにも載せない |
| RSS をそのまま材料にする | RSS のページは、メールマガジンの作成や再配布を断っている。 所員のメモを起点にする |
| 下書きの段階で120社分を作る | シナリオを2本に分け、確定の後に組み立てる |
| 業種の注意点が一般論になる | 業種の区分に働き方の特徴を書く |
| テンプレートのタグの差し替え漏れ | 作った版のタグの残りを Make で検索する |
| 前月の一言が残る | 一言の欄は毎月空のテンプレートから作る |
| 助成金の要領が改定されている | メモに要領の改定日を書かせる。 欠けていれば止める |
| 送付を自動にしてしまう | 下書きまでにする。 送信は所員が行う |
上の3行が、この構成の失敗のほとんどです。 どれも「AIがもっともらしく補う」ことから出ています。メモを唯一の根拠に置く設計を、指示と後段の照合の両方で守ります。
5行目は、技術ではなく決まりの話です。 公表資料を自動で集めて文章にする仕組みは作りやすいのですが、元の情報の提供のされ方によっては、その使い方自体が断られています。 取り込む前に、提供元の利用条件を読んでください。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 所員が書いた公表資料のメモ、業種の区分の特徴、顧問先台帳(業種、従業員数の帯、雇用形態の有無)です。従業員の個人情報は扱いません。
- 生成AIに顧問先の情報を渡さない … AIに渡すのはメモと業種の特徴だけです。顧問先の名前、規模、雇用形態の有無は、Make の中の規則でだけ使います
- 法令の解釈と助成金の要件の判断を、文章に持ち込まない … ニュースレターは一般的な案内です。個々の顧問先が助成金の要件を満たすか、改正がどう適用されるかは、社労士が個別に判断します
- 助成金の勧誘と紛らわしい書き方をしない … 厚生労働省の雇用関係助成金のページには、委託事業者を名乗って助成金の申請や受給額の無料査定を勧誘する者への注意喚起が載っています。受給を約束するような書き方は、顧問先にとってこうした勧誘と見分けにくくなります
- 公表資料の利用条件を守る … RSS の配信情報に基づくメールマガジンの作成や再配布は断られています。一次情報は原文のページを読んで書き、出典URLを付けます
- 送付の前に人が見る … 確定前の版や取り違えた版が届くことを防ぐため、送信は所員が行います
- ログに残す範囲を決める … プロンプトとJSONの全文を残しますが、顧問先台帳の内容は送付記録の側にだけ残します
誤りが起きた場合のリスクは、誤った施行日や対象を顧問先へ届けることと、当てはまらない顧問先に助成金の案内を届けることの2つです。 前者はメモに無い事実の書き足しから、後者は対象の印の欠けから起きます。どちらも、メモと台帳を根拠に置く設計で防ぎます。
10まず何から始めるか
1週目:メモの書式を決める
公表資料メモの列を決めます。出典URL、所管、種別、公表日、施行日・期限、対象、要点、掲載の印、対象の印です。助成金のメモには要領の改定日の列を足します。 3名で1週間、この書式でメモを書いてみます。
2週目:業種の区分と特徴を書く
顧問先台帳から業種を8区分にまとめ、区分ごとの働き方の特徴を3〜5行で書きます。経験のある所員が書くのが、属人化を解く最初の一歩です。
3週目:最小構成で試す
先月のメモ3本と業種3区分で、本文と注意点を書かせます。メモに無い事実が足されていないかを最優先で確かめます。
4週目:1本目のシナリオを組む
Make で、印の付いたメモを読み、共通の本文と注意点を確認用の一覧へ書き出すところまで作ります。この時点では顧問先ごとの版を作りません。
2か月目: 顧問先台帳に対象の判定の列を足し、2本目のシナリオでテンプレートから顧問先ごとの版を作ります。3か月目以降: 社労士が直した内容を業種の区分の特徴に戻し、1件15分が何分になったかを実測します。業種の注意点の下書きを経験の浅い所員が確かめられるようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| Make の Anthropic Claude アプリで、コンソールで作った API キーで接続すること。Create a Prompt でモデルとプロンプトを指定して応答を得られること。無料プランでは使えるモデルが限られること。Make an API Call のモジュールがあること | Make: Anthropic Claude | 2026-10-07 |
| Google ドキュメントのモジュールに Create a Document from a Template があり、テンプレートの文書を複製してタグを置き換えること。作った文書を指定のドライブとフォルダに置けること | Make: Google Docs modules | 2026-10-07 |
Claude の API で output_config.format に type: "json_schema" を渡すと、スキーマに沿ったJSONで応答を受け取れること | Claude API Docs: Structured outputs | 2026-10-07 |
| 厚生労働省が新着情報を RSS で提供していること。配信された情報に基づくホームページ・メールマガジンの作成や情報の再配布を断る旨が書かれていること | 厚生労働省: RSSによる情報配信について | 2026-10-07 |
| 雇用関係助成金のページで、共通要領の Q&A の更新がお知らせとして日付付きで載っていること。委託事業者を名乗る助成金の勧誘への注意喚起が載っていること | 厚生労働省: 事業主の方のための雇用関係助成金 | 2026-10-07 |
個々の法改正の内容と助成金の要件は、必ず原文で確かめてください。 本記事は、ニュースレターを作る手順の構成例を扱っており、特定の改正や助成金の内容を解説するものではありません。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0838)についてのご相談はこちらから。
