法改正と通達の更新を毎週巡回して影響のある顧問先と規程を洗い出す

処理の起点を決める

週1回の定時実行を基本にします。モデルでは毎週月曜の午前6時としました。担当者が出社したときに結果が揃っている状態を作ります。

これに加えて、2つの補助的なきっかけを持ちます。

• 官報の日次取得 … 官報は毎日午前8時30分に発行されます。公布された法令の一覧だけは日次で取ります
• 手動実行 … 大きな改正が話題になったときに、担当者がその場で回せるようにします

リアルタイム監視にはしません。 官公庁のページは日中に何度も更新されることがあり、常時監視すると同じ内容を何度も処理します。週次で十分です。

入力データを集める

「巡回先の一覧」を人が作ることが、この構成の出発点です。 AIに「関係のありそうなサイトを探して」と任せてはいけません。追う範囲を人が決め、その範囲を確実に見ることが目的だからです。範囲を決めていないと、「見落としがない」と言えなくなります。

一覧は30〜50件程度になります。この一覧を作る作業自体が、現状の棚卸しになります。

データの取得方法を決める

法令： e-Gov の法令APIを使います。法令の一覧、法令の本文、条文単位の取得、更新された法令の一覧を取得する機能が提供されています。バージョン2が2025年3月に公開され、バージョン1も引き続き提供されています。どちらを使うかは実装時に確認してください。

官報： 官報発行サイトから、当日発行分の目次を取得します。発行から90日を過ぎると一部の記事が非公開になるため、取得したものは自社側に保存します。

通達・Q&A・様式： ここでエージェントを使います。Claude API のウェブ検索ツールには、検索対象のドメインを限定する設定（allowed_domains）と、1回のリクエストでの検索回数の上限（max_uses）があります。巡回先を go.jp の該当ドメインに限定し、回数の上限を決めます。 上限がないと、関連情報を辿り続けて費用が膨らみます。

検索結果には出典が必ず付き、引用元の情報は入力・出力のトークンとして課金されない旨が公開資料に記載されています。根拠のURLが必ず付くことは、この用途では機能要件です。

顧問先台帳・社内規程： 検索基盤に取り込みます。規程やひな形はPDFやWordで散在しているため、取り込みの前に「どれが現行版か」を整理する必要があります。この整理が実装で最も時間のかかる部分です。

AIへ渡す前に整形する

1. 巡回先一覧の整備 … URLだけでなく、「そのページの何を見るのか」（一覧の日付欄／PDFの版数／ページ末尾の更新日）を書き添えます。これがないとエージェントが毎回違う見方をします
2. 前回記録との突合キーを決める … URL単位で持つか、記事ID単位で持つかを決めます。官公庁サイトはURLが変わることがあるため、題名と日付も併せて持ちます
3. PDFの扱いを分ける … 文字が埋め込まれたPDFはそのまま読めます。画像だけのPDFはOCRが必要です。古い通達は画像PDFのことがあります
4. 現行版の特定 … 社内規程は「2023年版」「最新版」「最新版（修正）」のようなファイルが並びます。取り込む前に現行版を1つに決めます
5. 顧問先台帳の項目整理 … 影響判定に使う項目（業種、規模、都道府県、適用特例）が空欄だらけだと照合できません。先に台帳を埋める作業が要ります
6. パブリックコメント段階のものを分ける … 意見募集中の案と、確定した通達を混ぜないようにします。混ざると「まだ決まっていないこと」を顧問先に伝えることになります

AIに処理させる

3つの段階に分け、それぞれ別の呼び出しにします。1回の呼び出しで全部やらせません。

第1段階：巡回と差分の特定（エージェント）

第2段階：内容の整理（通常の呼び出し）

第3段階：影響の照合（検索基盤との組み合わせ）

やらせないこと：

• 法的な結論を出すこと。 「この改正により御社は違法状態です」といった断定はさせません。示すのは「確認が必要な箇所」までです
• 顧問先への自動送信。 下書きまでです
• 「影響なし」の確定。 影響なしという判定も出させますが、それを最終結果にしません。 抜き取りで人が確認します
• 巡回先の自由な拡張。 一覧にないサイトを勝手に見に行かせません。範囲が変わると「見落としがない」と言えなくなります
• 知識からの回答。 「一般に、労働基準法では…」という説明をさせません。取得したページの記載だけを根拠にさせます

指示内容を固定する

第3段階（影響の照合）の例を示します。

あなたは社会保険労務士事務所の調査担当を支援する担当者です。
下の【更新情報】について、影響を受ける可能性のある顧問先を
【顧問先台帳】から挙げ、確認すべき点を示してください。

【厳守事項】
- 【更新情報】に書かれていることだけを根拠にしてください。
  あなたの知識で法令の内容を補わないでください。
  記載がない事項は「記載なし」としてください。
- 適法か違法かの結論を出さないでください。
  「確認が必要な点」までにとどめてください。
- 顧問先を挙げるときは、台帳のどの項目が条件に当たるのかを
  matched_condition に必ず書いてください。根拠のない列挙をしないでください。
- 影響がないと判断した場合も、なぜないのかを書いてください。
  「該当なし」だけで終わらせないでください。
- 施行日が未定、または意見募集の段階である場合は、
  status にそのことを明記し、顧問先への連絡文は作らないでください。
- 都道府県によって取扱いが異なる可能性がある場合は、
  needs_local_check に該当する都道府県を挙げてください。

【更新情報】
出典URL: {source_url}
取得日時: {fetched_at}
本文: {content}

【顧問先台帳（業種・規模・所在地・適用特例）】
{client_master}

【関連する社内規程・ひな形の抜粋】
{internal_docs}

「あなたの知識で補わない」の1行が、この用途では最も重要です。 法令の内容は改正で変わります。学習した時点の内容で補われると、古い内容が混ざり、しかもそれが自然な文章で出てきます。根拠を取得したページに限定し、出典URLを必ず付けさせてください。

「影響がない理由も書かせる」も必ず入れます。理由が書かれていれば、人が抜き取りで確認したときに、判断の筋道が正しいかを見られます。「該当なし」だけでは検証できません。

出力形式を固定する

{
  "source_url": "",
  "fetched_at": "",
  "doc_type": "法令改正 | 通達 | Q&A | 様式変更 | お知らせ | 意見募集",
  "status": "施行済み | 公布済み施行前 | 案の段階 | 施行日未定",
  "effective_date": "",
  "summary": {
    "what_changed": "",
    "who_is_affected": "",
    "transitional_measure": ""
  },
  "impact": "high | medium | low | none",
  "impact_reason": "",
  "affected_clients": [
    {
      "client_id": "",
      "matched_condition": "",
      "action_needed": "",
      "confidence": "high | medium | low"
    }
  ],
  "affected_internal_docs": [
    { "doc_name": "", "section": "", "reason": "" }
  ],
  "needs_local_check": [],
  "draft_notice": "",
  "unresolved": []
}

構造化した形にする理由は、後段の処理が3つあるためです。第一に impact で担当者に見せる順番を決めます。第二に affected_clients を顧問先管理システムへ書き戻します。第三に、impact: none の件を別の一覧にして、抜き取り確認の対象にします。

unresolved は、判断できなかった点を入れる欄です。ここが空で返ってくる場合は、逆に疑ってください。週50件の更新で、判断に迷う点が1件もないということはありません。

Claude API には、返すJSONの形をスキーマで指定して守らせる構造化出力の機能があります。status や impact に想定外の値が入ると後段が止まるため、ここは形を固定します。

システムへ連携する

顧問先管理システムへのタスク起票は、人が承認してから行います。 自動で200社にタスクが立つと、確認されないタスクが溜まります。

確認画面の作りが、この構成の使い勝手を決めます。次の3つを必ず入れてください。

• 出典URLを1クリックで開ける（原文をすぐ見られないと、確認に時間がかかります）
• AIが取得した本文と、現在のページを並べて見られる（ページが後から更新されることがあります）
• 「影響なし」の一覧を、いつでも開ける

人が確認する

全件、有資格者が確認します。この工程は運用が安定しても外しません。

理由は、誤りの結果が顧問先に及ぶためです。対応漏れは是正勧告や追徴につながり、誤った案内は責任問題になります。この構成が減らしているのは「探して読んで照合する時間」であって、「判断の責任」ではありません。

確認の手順を3段階に分けます。

3段階目が肝です。ここを省くと、この仕組みは「見落としを防ぐ」目的を果たしません。抜き取りで誤りが見つかった場合、その週の none は全件を見直します。

月に1回、巡回先一覧そのものを見直します。サイトの改編でページが移動していないか、追うべき情報源が増えていないかを確認します。

例外に対処する

「巡回が失敗して0件」の扱いを最初に決めてください。 通知が来ないことを「更新なし」と受け取る運用は、静かに機能停止します。毎週、更新が0件であっても「0件でした」と通知する設計にします。

記録を残す

この業務では、記録の保存が構成の存在理由の半分を占めます。

• 巡回した全URLと、取得日時、HTTPの応答（成功／失敗）
• 取得したページの本文スナップショット（官報は90日で一部が非公開になるため、自社側に残す）
• AIが返した判定の全項目（impact: none を含む）
• 確認者、確認日時、人が判定を変えた場合の変更前後
• 抜き取り確認の対象と結果

後から「なぜ見落としたのか」を追えることが重要です。追えれば、原因が巡回先一覧の不足なのか、判定の誤りなのか、確認の抜けなのかを切り分けられます。追えなければ、同じ見落としが繰り返されます。

人が判定を変えた記録は、精度の実測値になります。「様式変更は毎回 low と判定されるが、人は medium に上げている」と分かれば、判定基準の書き方を直せます。