Media > AI活用ユースケース > 法務 > 社内規程を改定したときに、他の規程や様式との食い違いを洗い出す

社内規程を改定したときに、他の規程や様式との食い違いを洗い出す

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

規程の改定案を入力に、他の規程からの参照、用語の定義、数値や期間の食い違いを洗い出します。法務担当の作業は、影響しそうな規程を記憶で探して読み比べることから、指摘された箇所を確かめることに変わります。

サマリー
利用ツール
ChatGPT/Claude/Gemini/Make/n8n/Power Automate/Python
対象業界
IT・SaaS/士業/製造/金融
対象部門
法務/総務
対象業務
内容確認・チェック/情報検索
主な課題
属人化している/情報が見つからない/確認ミスが多い
AIで行う処理
校正
主な効果
品質標準化/属人化解消/工数削減
導入難易度
★★★☆☆
実装レベル
半自動化
費用感
API連携(中)
人間の確認
条件付き
現在工数
24h/月
AI導入後
8h/月
想定削減
67%
年間削減
192h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 所管部門から改定案を受け取る(Wordの変更履歴付き)
  2. 法務担当が改定内容を読み、影響しそうな規程を思い浮かべる
  3. SharePointで規程を検索し、該当しそうなものを開く
  4. 目次から関係のありそうな章を探し、読み比べる
  5. 条番号が変わる改定の場合、他の規程が引用していないかを探す
  6. 改定内容に対応する様式・帳票がないかを確認する
  7. 食い違いが見つかれば、所管部門と協議して修正する
  8. 施行日を確認し、他の規程の改定と整合させる
  9. 改定案を確定し、稟議に回す
導入後(After)
  1. 所管部門から改定案を受け取り、SharePointの改定フォルダに置く
  2. 自動改定前後を比較し、変更箇所(追加・削除・修正・条番号の移動)を特定する
  3. 自動規程の参照地図から、改定した規程を引用している他の規程を洗い出す
  4. 自動条番号が移動した条文について、他の規程からの引用が壊れていないかを確認する
  5. 自動改定で定義や数値が変わった語について、他の規程での記述と突き合わせる
  6. 自動改定内容に対応する様式・帳票を、様式台帳から洗い出す
  7. 自動食い違いを一覧にする(該当箇所の原文つき)
  8. 法務担当が指摘を確かめ、所管部門と協議する内容を決める
  9. 改定案を修正し、稟議に回す
  10. 自動施行後、規程の参照地図を更新する
各工程の詳しい説明を読む
  1. 所管部門から改定案を受け取る(Wordの変更履歴付き)
  2. 法務担当が改定内容を読み、影響しそうな規程を思い浮かべる
  3. SharePointで規程を検索し、該当しそうなものを開く
  4. 目次から関係のありそうな章を探し、読み比べる
  5. 条番号が変わる改定の場合、他の規程が引用していないかを探す
  6. 改定内容に対応する様式・帳票がないかを確認する
  7. 食い違いが見つかれば、所管部門と協議して修正する
  8. 施行日を確認し、他の規程の改定と整合させる
  9. 改定案を確定し、稟議に回す

問題は5つあります。

(a)62本を横断して探せない。 「この改定に関係する規程はどれか」を機械的に出す手段がありません。担当者の記憶が唯一の索引です。

(b)参照の書き方が揺れている。 「別に定める」「◯◯規程による」「就業規則第32条」「前項の定めるところにより」と、書き方がばらばらです。文字列検索では拾えません。

(c)条番号のずれで引用が壊れる。 条文を1つ追加すると、以降の条番号が1つずつずれます。他の規程が「第32条」を引いていれば、その引用は別の条文を指すようになります。 これがもっとも多い事故です。

(d)様式・帳票への影響が漏れる。 規程で記載事項を追加したのに、申請書の様式がそのまま、ということが起きます。180種の様式を毎回確認する時間はありません。

(e)2名に依存している。 規程の全体像を把握しているのがこの2名だけで、異動すると再現できません。

  1. 所管部門から改定案を受け取り、SharePointの改定フォルダに置く
  2. 【自動】 改定前後を比較し、変更箇所(追加・削除・修正・条番号の移動)を特定する
  3. 【自動】 規程の参照地図から、改定した規程を引用している他の規程を洗い出す
  4. 【自動】 条番号が移動した条文について、他の規程からの引用が壊れていないかを確認する
  5. 【自動】 改定で定義や数値が変わった語について、他の規程での記述と突き合わせる
  6. 【自動】 改定内容に対応する様式・帳票を、様式台帳から洗い出す
  7. 【自動】 食い違いを一覧にする(該当箇所の原文つき)
  8. 【人】 法務担当が指摘を確かめ、所管部門と協議する内容を決める
  9. 【人】 改定案を修正し、稟議に回す
  10. 【自動】 施行後、規程の参照地図を更新する

自動化されるのは「差分を取る」「引用元を探す」「定義を突き合わせる」「様式を洗い出す」の4つです。残るのは「どちらに合わせるかを決める」で、これは法務担当と所管部門の仕事です。

02今回想定するシステム構成

構成図
所管部門(改定案・Wordの変更履歴付き)
   │
   ▼ SharePoint の改定フォルダ
   │
   ▼【トリガー】ファイルが作成されたとき
Power Automate
   │
   ├──▶ 改定前後の差分の抽出(追加 / 削除 / 修正 / 条番号の移動)
   │
   ├──▶ 規程の参照地図を引く(どの規程が、どの条文を引いているか)
   │
   ├──▶ LLM API ── 引用の破損の確認
   │                 + 用語の定義の突合
   │                 + 数値・期間・金額の突合
   │                 + 様式・帳票への影響の洗い出し
   │
   ▼
整合チェックの一覧(該当箇所の原文つき)──【法務担当が確認】
   │
   ├──▶ 所管部門と協議
   │
   ▼
改定案の確定 ── 稟議 ── 施行
   │
   ▼【施行後】
規程の参照地図を更新
役割想定する製品代替候補
生成AIClaude APIOpenAI API、Gemini API
連携Power AutomateMake、n8n、Python
保管SharePointBox、Google Drive
規程の参照地図SharePoint リストGoogle スプレッドシート

規程管理システム(規程の版管理、参照関係の管理、改定ワークフローを一体で扱うもの)が存在します。 まずそれを検討してください。自前で組む価値があるのは、すでにWordとSharePointで管理していて、システムを入れ替えずに整合チェックだけを足したい場合です。

検索基盤を置かず、生成AIに直接読ませる構成にしています。 規程62本・約1,200ページは、文字数にして100万字程度です。改定のたびに全文を渡すのは効率が悪いため、参照地図で関係する規程を絞ってから渡します。 絞り込んだ結果は、多くの場合3〜8本の規程に収まり、これは1回の呼び出しで扱える範囲です。

Claude を選んだのは、長い文書をまとめて読ませる用途に向くためです。 プロジェクトに規程を置いて参照させる使い方もできます。他の生成AIでも、同じ考え方で成立します。

03どうやって実装するのか

Step1

処理の起点を決める

SharePointの改定フォルダにファイルが作成されたことを起点にします。Power Automate の SharePoint コネクタには「ファイルが作成されたとき」トリガーが標準で用意されています。

改定案をWordの変更履歴付きで提出してもらうことを、運用の前提にしてください。 変更履歴がないと、差分の抽出を機械的に行えません。「改定前」「改定後」の2ファイルを出してもらう形でも構いませんが、どちらかに統一します。

Step2

入力データを集める

データ中身取得元
改定案変更履歴付きのWord、または改定前後の2ファイル所管部門
全規程62本の規程本文(条番号、見出し、本文)SharePoint
規程の参照地図どの規程の第何条が、どの規程の第何条を引いているか法務(新しく作る
用語の定義集規程ごとに定義されている用語と、その定義法務(新しく作る
様式台帳様式の名称、様式番号、根拠となる規程と条文総務(整備が必要
改定の履歴過去の改定と施行日SharePoint
法令の対応関係規程が対応している法令(労働基準法、個人情報保護法など)法務

「規程の参照地図」が、この構成の中核です。

1行に1つの参照を持ちます。

参照元の規程旅費規程
参照元の条第8条第2項
参照の文言就業規則第32条に定める
参照先の規程就業規則
参照先の条第32条
参照の種類明示(条番号あり)/包括(「別に定める」)/用語の準用

この地図は、最初に1度作れば、改定のたびに更新するだけで維持できます。 62本から参照を拾う作業は、生成AIに手伝わせられます(後述)。

「用語の定義集」も同様です。 「従業員」「就業日」「所定労働時間」「機密情報」といった語が、どの規程の第何条で、どう定義されているかを並べます。同じ語が複数の規程で違う定義になっていることが、作った時点で見つかります。

Step3

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

改定案の差分: Wordの変更履歴から、追加・削除・修正を抽出します。変更履歴がない場合は、改定前後のテキストを比較します。条番号の移動を検出することが重要です。 「第12条を追加した」ことと「旧第12条以降が1つずつ繰り下がった」ことは、別の情報として扱います。

規程本文の構造化: 各規程を「条 → 項 → 号」の構造に分解します。規程の書式が統一されていれば、見出しの正規表現で分解できます。 統一されていない場合は、この整備が先です。

参照地図の初期作成: 全規程の本文から、他の規程・条文への参照を抽出します。

生成AIに1規程ずつ読ませ、「この規程が他の規程や条文を参照している箇所」を挙げさせます。62本で62回の呼び出しです。 抽出結果を法務担当が確認して、地図を作ります。この作業に1〜2週間かかりますが、1度だけです。

Step4

AIへ渡す前に整形する

  1. 改定箇所の分類 … 変更を「文言の修正」「条文の追加」「条文の削除」「条番号の移動」「別表・様式の変更」に分けます
  2. 条番号の移動の追跡 … 追加・削除によって何条から何条に移ったかの対応表を作ります。これが引用の破損を見つける材料です
  3. 参照地図の引き当て … 改定した条文を参照している他の規程を洗い出します
  4. 定義が変わった語の抽出 … 改定で定義や数値が変わった語を特定します
  5. 関係規程の絞り込み … 参照地図と用語の定義集から、今回読む必要のある規程を3〜8本に絞ります
  6. 様式の引き当て … 改定した条文を根拠とする様式を、様式台帳から洗い出します

2番目を必ず実装してください。 条番号の移動による引用の破損は、この業務でもっとも多く、かつ機械的に確実に検出できる種類の問題です。

Step5

AIに処理させる

条番号の移動の追跡と、参照地図の引き当ては、プログラムで行います。 機械的に決まることにLLMを使う必要はありません。

LLMにさせること:

処理内容
引用の破損の確認移動した条番号を引いている記述が、意味として通るかを確認する
包括的な参照の解釈「別に定める」「関係規程による」が、今回の改定に関係するかを判断する材料を出す
用語の定義の突合改定で定義が変わった語が、他の規程でどう使われているかを並べる
数値・期間・金額の突合「60日」「2か月」のように表記が違う同じ値を見つける
様式への影響の指摘記載事項の追加・変更が、様式の項目に影響するかを指摘する
施行日の整合の確認関連する規程の施行日が揃っているかを確認する

「どちらが正しいか」を決めさせないでください。

「就業規則では60日、育児介護休業規程では2か月」と並べるところまでです。どちらに合わせるかは、法令の要請、実務の運用、所管部門の意向を踏まえて決めることであり、文書を読むだけでは決まりません。

同じ理由で、改定案の修正文を作らせないでください。 「第8条を『就業規則第33条』に修正してください」という指摘までは出しますが、修正後の条文そのものをAIに書かせると、確認が形骸化します。

Step6

指示内容を固定する

あなたは、社内規程の改定における整合の確認を支援する担当者です。
改定案と関係する規程を読み、食い違いを指摘してください。

【厳守事項】
- どちらが正しいかを判断しないでください。
  「就業規則に合わせるべきです」「こちらが誤りです」と書かないでください。
  食い違っている事実と、双方の記述を並べるだけにしてください。
- 修正後の条文を書かないでください。
  「どの条文の、どの記述が、何と食い違っているか」を示すところまでです。
- 指摘には必ず、双方の原文を quote として引用してください。
  要約した文言で指摘しないでください。
- 規程に書かれていないことを補わないでください。
  「おそらく意図としては〜」と推測しないでください。
- 法令の解釈をしないでください。
  「労働基準法に違反する可能性があります」と書かないでください。
  法令との関係が疑われる場合は、needs_legal_review に該当箇所を挙げるだけにしてください。
- 包括的な参照(「別に定める」「関係規程による」)については、
  今回の改定に関係するかどうかを断定せず、
  「確認が必要」として関係しうる規程を挙げてください。
- 数値・期間・金額については、表記が違っても同じ値なら食い違いとしないでください
  (60日と2か月が同じ意味かどうかは文脈によるため、
   判断できない場合は uncertain に入れてください)。

【改定する規程】
{target_policy_name}

【改定の内容(差分)】
{diff}

【条番号の移動の対応表】
{article_renumbering}

【この改定を参照している他の規程(参照地図より)】
{referencing_policies}

【関係する規程の本文】
{related_policy_texts}

【用語の定義集の該当行】
{term_definitions}

【改定した条文を根拠とする様式(様式台帳より)】
{related_forms}

「どちらが正しいかを判断しないでください」の1行が、この構成の安全装置です。 これを書かないと、LLMは「就業規則の記載が正しく、旅費規程を修正すべきです」と書きます。その判断が誤っていても、読んだ担当者が気づかないまま所管部門に伝えてしまいます。

「法令の解釈をしないでください」も必ず入れてください。 規程が法令に適合しているかの判断は、法務部門と顧問弁護士・社会保険労務士の業務です。

Step7

出力形式を固定する

{
  "revision_id": "",
  "target_policy": "",
  "diff_summary": {
    "articles_added": [],
    "articles_deleted": [],
    "articles_renumbered": [],
    "text_changes": 0
  },
  "findings": [
    {
      "type": "broken_reference | term_definition | numeric_mismatch | form_impact | effective_date | uncertain",
      "severity": "high | medium | low",
      "source": {
        "policy": "",
        "article": "",
        "quote": ""
      },
      "counterpart": {
        "policy": "",
        "article": "",
        "quote": ""
      },
      "description": "",
      "action_required_by": "法務 | 所管部門 | 総務(様式) | 未定"
    }
  ],
  "forms_to_review": [],
  "needs_legal_review": [],
  "uncertain": [],
  "reference_map_updates": []
}

双方の quote(原文)を必ず残します。 「食い違いがあります」だけでは、法務担当が該当箇所を探すことになり、削減効果が消えます。

severity の目安は次のとおりです。

区分内容
high条番号の引用が壊れている/用語の定義が矛盾している/法令に関わる数値の食い違い
medium様式への影響/施行日のずれ
low表記の揺れ(「従業員」と「社員」の混在など)

reference_map_updates には、この改定によって参照地図をどう更新すべきかを入れます。施行後にこれを反映すれば、地図が維持されます。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります(2026-09-16時点ではベータ機能として提供)。項目が多い出力なので、利用できると形の崩れを防げます。

Step8

システムへ連携する

つなぐ先内容
SharePoint改定案の受け取り、規程本文の取得、結果の保管
SharePoint リスト(参照地図)参照関係を引く。施行後に更新する
SharePoint リスト(用語の定義集)定義を引く
SharePoint リスト(様式台帳)様式への影響を洗い出す
Teams / Outlook所管部門・総務に協議の依頼を出す

改定案そのものを自動で修正しないでください。 規程の条文は、承認の経路(稟議・取締役会)を経て確定するものです。機械が書き換えた条文が混ざると、どの版が正か分からなくなります。

参照地図の更新は、施行後に行います。 改定案の段階で更新すると、稟議で差し戻されたときに地図が現実と合わなくなります。

Step9

人が確認する

すべての指摘を法務担当が確認します。

見る優先順位は次のとおりです。

優先対象対応
1broken_reference(条番号の引用の破損)確実に直す。 機械的に検出できるので見落としてはいけない
2term_definition(用語の定義の矛盾)所管部門と協議して、どちらに合わせるかを決める
3needs_legal_review顧問弁護士・社会保険労務士に確認する
4numeric_mismatch数値の意味を確認する
5form_impact(様式への影響)総務と協議する
6uncertain内容を読んで、食い違いかどうかを人が判断する

uncertain を軽く見ないでください。 「60日」と「2か月」が同じ意味かどうかは、起算日の定め方によって変わります。AIが判断できないと言っているものは、実際に判断が難しいものです。

Step10

例外に対処する

起きること対応
改定案に変更履歴がない改定前後の2ファイルの比較に切り替える。どちらもなければ処理を止める
規程の書式が統一されておらず条文に分解できない分解できた範囲で処理し、できなかった規程を明示する。黙って飛ばさない
「別に定める」が今回の改定に関係するか判断できないuncertain として、関係しうる規程を挙げる。断定しない
参照地図に載っていない参照がある検出したら reference_map_updates に追加候補として挙げる
用語の定義集に載っていない語の定義が変わった定義集への追加候補として挙げる
様式台帳が整備されていない様式への影響の洗い出しができない。「確認できていない」と明示する
複数の規程を同時に改定する改定案どうしの整合も確認対象にする。1本ずつ独立に処理しない
法令改正への対応で、複数の規程が一斉に変わる施行日の整合を必ず確認する。先に施行された規程が、まだ改定されていない規程を引く状態を検出する
改定が差し戻された参照地図を更新しない。施行を条件にする
過去の版を参照している記述がある版数まで含めて突き合わせる
Step11

記録を残す

  • 改定案(改定前後、変更履歴つき)
  • 差分の抽出結果と、条番号の移動の対応表
  • 整合チェックの一覧と、双方の原文
  • 法務担当が「食い違いではない」と判断した指摘と、その理由
  • 所管部門との協議の記録
  • 確定した改定案と施行日
  • 参照地図・用語の定義集の更新履歴

「食い違いではないと判断した指摘と理由」が資産になります。 「この2つの規程で『従業員』の範囲が違うのは意図的(一方は出向者を含む)」といった判断が蓄積すれば、次回から同じ指摘を抑えられます。 誤検知が減ることで、一覧が読まれ続けます。

参照地図と用語の定義集の更新履歴を必ず残してください。 過去のある時点で規程がどう繋がっていたかを、後から確認する必要が生じることがあります。

04実装レベルの3段階

最小構成:改定案と関係しそうな規程を生成AIに貼り、食い違いを挙げさせる / 読み比べ
半自動化:参照地図から関係規程を自動で絞り込み、差分の抽出・引用の破損の確認・用語の突合までを自動化する / 絞り込み・差分・突合
本格構成:上記+様式台帳との突合+施行日の整合確認+参照地図・定義集の自動更新 / 判断以外のすべて

半自動化で効果の大半が出ます。 240分が100分程度になります。影響しそうな規程を探す90分がほぼ消えるためです。本格構成にすると80分程度ですが、本格構成の価値は時間より「参照地図が維持されること」にあります。 地図が古くなると、この構成は機能しなくなります。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
2 名
月間件数
6 件
1件あたり現在時間
240 分
1件あたり導入後時間
80 分
現在  6件 × 240分 ÷ 60 = 24 時間/月
導入後 6件 × 80分 ÷ 60 = 8 時間/月
月間削減時間
16h
削減率
67%
年間削減時間
192h
年間金額換算(時間単価4,000円)
77万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 社内規程が30本以上あり、改定が月2件以上ある企業。規程が電子データ(WordまたはPDF)で管理されていること。規程どうしの参照や、規程と様式の対応があること。
向いていない
  1. 規程が10本以下で、担当者が全文を把握できている場合。改定が年に数回しかない場合。規程が紙でしか存在せず、電子化の計画もない場合。規程管理システムに整合チェックの機能があり、それで足りている場合。

07最小構成で試す方法

  1. 過去に行った改定を1件選ぶ(条文の追加を含むもの)
  2. その改定に関係する規程を3本選ぶ(当時、法務担当が読み比べたもの)
  3. 改定案と3本の規程を生成AIに貼り、食い違いを挙げさせる
  4. 当時、法務担当が見つけた食い違いと比べる

見るのは次の4点です。

見る点判断
当時見つけた食い違いを、AIも挙げたか挙げていれば下敷きとして使える
当時見落としていた食い違いがあるか1つでもあれば、この構成には価値があります
どちらが正しいかを断定していないか断定していたら、プロンプトを強める。ここが最重要
双方の原文が引用されているかされていなければ、確認に時間がかかる

そのうえで、参照地図の作成を試してください。

  1. 規程を3本選び、生成AIに「この規程が他の規程や条文を参照している箇所をすべて挙げて」と指示する
  2. 法務担当が目で確認し、漏れと誤りを数える

この作業が現実的な時間で終わるかが、この構成を作れるかどうかの分かれ目です。 3本で試して、漏れが多いようなら、規程の書式の統一が先になります。

08実装時につまずきやすいポイント

問題対策
AIがどちらが正しいかを断定するプロンプトで明確に禁止する。「すべき」「誤り」「正しい」といった語が出力に含まれていないか機械的に検査する。最重要
修正後の条文をAIが書く禁止する。指摘までにとどめる
条番号の移動を追跡していない対応表を必ず作る。引用の破損はここでしか見つからない
規程の書式が統一されておらず分解できない書式の統一を先に行う。できない規程は明示して人が見る
参照地図が古くなる施行後に必ず更新する。更新を運用フローに組み込む
「別に定める」を関係なしと自動判定するuncertain にする。断定しない
誤検知が多くて一覧が読まれない「食い違いではない」と判断した指摘を記録し、次回の前提に加える
様式台帳がなく、様式への影響が確認できない「確認できていない」と明示する。黙って省かない
複数規程の同時改定で、改定案どうしの整合を見ていない同時改定は1セットとして処理する
法令の解釈がAIの出力に混ざる禁止する。needs_legal_review に挙げるだけにする

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 社内規程の全文、改定の検討内容、施行前の改定案。施行前の改定案には、組織変更や制度変更の意思決定が含まれることがあります。

  1. 施行前の改定案の取り扱い … 人事制度の変更、組織再編、報酬制度の改定は、社内でも限られた範囲でのみ扱う情報です。外部サービスに送ることの可否を、自社の情報管理規程で確認してください
  2. 外部AIへの入力可否 … 規程には、自社の内部統制の仕組み、権限の分掌、セキュリティ対策が書かれています。これらは組織の構造を示す情報です。 テナント内で処理が完結する構成を選ぶ判断も合理的です
  3. 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます
  4. アクセス権限 … 改定案と整合チェックの結果の閲覧を、法務部門と所管部門に限定します。人事制度に関わる改定は、さらに範囲を絞ってください
  5. 法令解釈をAIに委ねない … 規程が法令に適合しているかの判断は、法務部門と顧問の専門家の業務です。AIの出力に法令の解釈が混ざっていないか、検査する仕組みを入れてください
  6. 版の管理 … どの版が施行中かが分からなくなることが、規程管理の最大の事故です。AIが扱うのは改定案の検討であり、正本は従来どおり承認された版であることを、明確にしてください
  7. 自動実行してよい範囲 … 差分の抽出と食い違いの指摘までです。改定案の修正、所管部門への依頼、参照地図の更新の確定は、必ず人が行います

誤りが起きた場合のリスクは、不整合な規程の施行です。条番号の引用が壊れた規程は、その条文を根拠とする処分や手続きの正当性に影響します。 労務トラブルや監査の指摘として、後から問題になります。

10まず何から始めるか

1週目:規程の書式を点検する

62本の規程を開き、次を確認します。

  • 条・項・号の書き方が統一されているか
  • 目次と本文の条番号が一致しているか
  • 改定履歴が各規程に記載されているか

統一されていないなら、そこを直すのが先です。 機械的に分解できない規程は、この構成の対象外になります。

2〜3週目:参照地図を作る

全規程から、他の規程・条文への参照を抽出します。生成AIに1本ずつ読ませ、法務担当が確認します。300〜600行の地図になります。

この作業の途中で、すでに壊れている引用が見つかります。 過去の改定で条番号がずれたまま放置されているものです。それ自体が、この構成を導入する理由になります。

4週目:用語の定義集を作る

規程で定義されている語を抽出し、規程ごとの定義を並べます。同じ語が違う定義になっている箇所が見つかります。

2か月目:過去の改定1件で試す

参照地図と定義集ができたら、過去の改定1件で整合チェックを試します。当時見落としていた食い違いが出るかを確かめてください。

3か月目以降: SharePointへの提出をきっかけとした自動チェックを作り、実際の改定で使います。240分が何分になるかを実測します。 並行して様式台帳を整備し、様式への影響の洗い出しを追加します。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-09-16/最終更新:2026-09-16
確認した内容情報源確認日
Claude のプロジェクトに参照用の文書(PDF、テキスト、Markdown など)をアップロードでき、そのプロジェクト内の会話で読ませられることClaude Help Center: What are projects?2026-09-16
Claude API に、出力をJSONスキーマに沿わせる構造化出力の機能があること(2026-09-16時点ではベータ機能)Claude Platform Docs: Structured outputs2026-09-16
Power Automate の SharePoint コネクタに「ファイルが作成されたとき」トリガーがあることMicrosoft Learn: SharePoint コネクタ2026-09-16

規程が法令に適合しているかの判断は、法務部門および顧問弁護士・社会保険労務士の業務です。この構成はその判断を行うものではありません。 施行前の改定案を外部サービスに送ることの可否は、自社の情報管理規程によります。規程の版管理と承認の経路は、自社の規程管理規程に従ってください。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-0099)についてのご相談はこちらから。

AI活用について相談する
目次