法律は仕様書、裁判は本番テスト？ 法制度をInput→実装→Feedbackで理解する

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。e-Gov、内閣法制局、厚生労働省、法務省、裁判所などの一次情報を確認し、法制度を「INPUT / DEVELOPMENT / PERMISSION / RUNTIME / FEEDBACK」というIT開発・運用モデルで整理しています。後半ではExcel・VBA・PowerShellによる管理サンプルまで実装します。

検証ステータス：📘 一次情報確認済み・法的判断の自動化は行わない設計

とある資格試験の勉強をしていると、法律、政令、省令、指針、通達、提言、大綱、認定基準……と、似ているようで役割の違う言葉が次々に出てきました。

名称と年号だけを覚えようとすると、なかなか頭に入りません。

そこで、普段なじみのあるIT開発やシステム運用に置き換えて考えてみました。

すると、法律は単に「国が決めたルール」ではなく、

社会という本番環境からINPUTを受け取り、制度として設計・実装され、RUNTIMEで運用され、その結果をFEEDBACKとして次の改修へ戻す巨大な社会システム

として見えてきます。

この記事では、法制度を次の5つの要素で整理します。

INPUT
   ↓
DEVELOPMENT
   ↓
PERMISSION
   ↓
RUNTIME
   ↓
FEEDBACK
   └────────→ 次のINPUTへ

さらに後半では、この考え方をそのままExcel・VBA・PowerShellで管理する方法まで考えます。

法律をプログラムに判定させるのではありません。

法律・指針・通知を「何を根拠に、何を実施し、いつ点検し、どの証跡を残すか」という管理対象に変換するのが目的です。

1. まず全体像 ― 法制度は巨大なフィードバックループ

flowchart LR
    subgraph INPUT["INPUT：社会から入ってくる情報"]
        I1[社会問題]
        I2[事故・重大事件]
        I3[裁判・判例]
        I4[統計・調査]
        I5[行政実務]
        I6[専門家・研究]
        I7[当事者・業界]
        I8[世論・報道]
        I9[国際動向]
        I10[新技術・災害]
    end

    subgraph DEV["DEVELOPMENT：制度を設計する"]
        D1[問題認識]
        D2[調査・検討]
        D3[報告書・提言]
        D4[大綱・基本方針等]
        D5[制度設計]
        D6[法案]
        D7[法制面の審査・調整]
        D8[国会審議]
    end

    subgraph CORE["CORE"]
        L[法律]
    end

    subgraph DETAIL["DETAIL：詳細化"]
        R1[政令]
        R2[省令]
        R3[告示・法定指針]
        R4[通達・通知]
        R5[認定基準・審査基準等]
    end

    subgraph RUN["RUNTIME：社会で動かす"]
        O1[行政実務]
        O2[企業実装]
        O3[現場運用]
    end

    subgraph FEEDBACK["FEEDBACK：運用結果"]
        F1[裁判]
        F2[統計]
        F3[行政上の課題]
        F4[新しい社会問題]
        F5[技術・環境変化]
    end

    INPUT --> D1
    D1 --> D2 --> D3
    D3 --> D5
    D3 --> D4
    D4 --> D5
    D5 --> D6 --> D7 --> D8 --> L

    L --> R1
    L --> R2
    L --> R3

    R1 --> R4
    R2 --> R4
    R3 --> R4
    R4 --> R5

    R1 --> RUN
    R2 --> RUN
    R3 --> RUN
    R4 --> RUN
    R5 --> RUN

    RUN --> FEEDBACK
    FEEDBACK --> D1

この図で一番重要なのは、右端で終わらず、また左へ戻ることです。

法律は、

作る
↓
公布する
↓
終わり

ではありません。

むしろ、

リリース
↓
本番運用
↓
ログを見る
↓
不具合・新要求を発見
↓
次バージョンを設計

というライフサイクルを持っています。

ただし、この図は理解用のモデルです。すべての法律が必ず「検討会→提言→大綱→法案」という同じ順番を通るわけではありません。内閣提出法案もあれば、国会議員や国会の委員会等から提出される法案もあります。

法律のCI/CDパイプラインが1本だけ存在するわけではない、という点は最初に押さえておきます。

2. INPUT ― 法律は何を材料にして作られるのか

「法律を作る」と聞くと、白紙から条文を書き始めるイメージを持ちやすいかもしれません。

しかし、新規立法に見える制度でも、その手前には多くの場合、社会の中に要求が蓄積しています。

「ゼロから法律を作る」と言っても、実態は、

未整理の要求や障害報告が十分に蓄積し、正式な開発プロジェクトとして立ち上がる

ことに近い場合が多いと考えると理解しやすくなります。

3. 提言・報告書・大綱は何をしているのか

ここも、単純な上下関係にしない方が理解しやすい部分です。

特に「大綱」は、名前だけで法律より一段下と考えるべきものではありません。政策・制度の大きな方向を示す文書として用いられますが、法的位置付けや作成主体は個々の大綱によって異なります。

したがって、

大綱 = 必ず法律の直前に存在する成果物

ではありません。

ITで言えば、すべての新システムに必ず MasterPlan.md というファイルが存在するわけではないのと同じです。

重要なのはファイル名ではなく役割です。

4. DEVELOPMENT ― 内閣提出法案はどう作られるのか

内閣法制局は、内閣提出法律案について「法律ができるまで」を公開しています。

大まかには、各省庁で政策を検討し、原案を作成し、関係省庁との調整や必要に応じた審議会・公聴会等を経て法文化し、内閣法制局の審査、閣議決定、国会提出へ進みます。

flowchart TD
    A[政策上の課題]
    --> B[所管省庁<br>Requirements]

    B --> C[制度設計<br>Basic Design]
    C --> D[関係省庁調整<br>Integration Review]
    D --> E[審議会・意見聴取等<br>Stakeholder Review]
    E --> F[法文化<br>Specification Draft]
    F --> G[内閣法制局審査<br>Architecture / Legal Review]
    G --> H[閣議決定<br>Release Approval]
    H --> I[国会提出]
    I --> J[委員会審査]
    J --> K[本会議]
    K --> L[成立]
    L --> M[公布・施行]

内閣法制局は「法務版Architecture Review」

内閣法制局の説明では、内閣提出法律案について、

• 憲法や既存法制との関係
• 立法内容の法的妥当性
• 立法意図が条文へ正確に反映されているか
• 条文構成
• 用字・用語

などを審査しています。

ITに置き換えるなら、

Architecture Review
+
Compatibility Check
+
Static Analysis
+
Code Review
+
Lint

を一度に行っているようなイメージです。

一次情報

• 内閣法制局「法律ができるまで」

5. PERMISSION ― 法制度は「権限モデル」でもある

ここからがもう1つ重要な軸です。

法律、政令、省令、指針、通知などは、単純に「上だから強い」「下だから弱い」と一本のゲージだけで見ると誤解しやすくなります。

見るべきなのは、

• 誰が作るのか
• 誰が変更できるのか
• どの手続を通るのか
• どこまで決められるのか
• 上位法からどの権限を与えられているのか
• 誰を対象とするのか
• 違反した場合にどんな効果があるのか

です。

flowchart TB
    C[憲法<br>Architecture Constraints]

    L[法律<br>Core Specification<br>権限境界]

    O[政令<br>Detailed Design]
    M[省令<br>Detailed Configuration]
    G[法定指針<br>Implementation Guide]
    N[通達・通知・認定基準<br>Administrative Runbook / Rule Engine]

    P[行政・企業・社会で実装]

    C --> L
    L -->|法律の実施・委任| O
    L -->|法律等の実施・委任| M
    L -->|根拠法に基づく具体化| G

    O --> M
    M --> N
    G --> N

    O --> P
    M --> P
    G --> P
    N --> P

親APIが許していない権限を子モジュールは勝手に追加できない

日本国憲法41条は、国会を「国の唯一の立法機関」としています。

また憲法73条6号では、内閣が憲法・法律を実施するため政令を制定できる一方、法律の特別な委任がなければ政令で罰則を設けられないとされています。

国家行政組織法12条は、省令について、法律・政令の施行または特別の委任に基づいて発することができるとし、法律の委任がなければ、省令だけで罰則を設けたり、義務を課したり、国民の権利を制限したりする規定を設けられないとしています。

したがって、ガイドラインを書き換えて、突然「違反したら懲役10年」というような新しい刑罰を作ることはできません。

重い法的効果を持たせるには、それに応じた法的根拠と手続が必要です。

一次情報

• 日本国憲法（e-Gov）
• 国家行政組織法（e-Gov）

6. 「変更しやすさ」と「決められる範囲」

この表の「変更コスト」は理解用の一般化です。

必ずしも、

変更しやすい = 法的に弱い

とはなりません。

7. RFCの MUST / SHOULD / MAY だけでは整理できない

エンジニアであれば、

法律 = MUST
指針 = SHOULD
通知 = MAY

と割り当てたくなるかもしれません。

しかし、この整理は危険です。

指針でも、法律上の義務を具体化するために法律の規定に基づいて定められているものがあります。また、1つの指針の中に、法律上必要な措置を具体化した部分と「望ましい取組」が共存することもあります。

したがって、資料名だけではなく、

DocumentType
Issuer
LegalBasis
Target
RequirementType
EffectiveDate
Consequence

を見る必要があります。

これは法制度のメタデータと考えると分かりやすいです。

8. 裁判は法律を作るのか

ここは特に混乱しやすいところです。

裁判そのものは法律ではありません。

日本国憲法76条は司法権を裁判所に属させ、裁判官は憲法と法律に拘束されると定めています。

ITで例えるなら、

法律
= Specification

具体的事件
= Production Input

裁判
= Specificationを実案件へ適用する判定処理

判決
= Result

判例
= 過去の重要な判断ログ / Regression Test Case

くらいのイメージです。

「裁判＝バグ発見装置」という表現は分かりやすいのですが、裁判所の目的は法律のバグ探しではありません。

より正確には、

本番事例へ仕様を適用した結果として、仕様の曖昧さや制度上の問題が可視化されることがある

と考えるとよいでしょう。

9. 判例が立法のINPUTになる実例 ― 安全配慮義務

今回のモデルを理解するうえで分かりやすいのが、労働契約法5条です。

厚生労働省の労働契約法施行通達では、安全配慮義務について、もともと判例上認められてきた一方で民法等の規定からは明確でなかったため、労働契約法5条で使用者が安全配慮義務を負うことを規定した、という趣旨が説明されています。

flowchart LR
    A[具体的な事故・紛争]
    --> B[裁判]
    B --> C[判例上<br>安全配慮義務を形成]
    C --> D[実務で判断が蓄積]
    D --> E[条文上分かりにくい<br>予測可能性の課題]
    E --> F[労働契約法]
    F --> G[第5条で明文化]

これは、

Production Cases
↓
Rule discovered in operation
↓
Specificationへ正式採用

という流れに近い例です。

一次情報

• 厚生労働省「労働契約法について」
• 労働契約法の施行について
• 労働契約法条文

10. 解雇権濫用法理も「判例 → 成文化」の例

労働契約法16条も興味深い例です。

厚労省の通達では、この条文について、最高裁判決で確立している解雇権濫用法理を規定したものと説明しています。

flowchart LR
    A[解雇をめぐる紛争]
    --> B[裁判]
    B --> C[解雇権濫用法理]
    C --> D[判例法理として確立]
    D --> E[労働契約法16条]
    E --> F[成文法として確認しやすくなる]

これは「裁判所が法律を作った」のではなく、

裁判を通じて形成・確立した判断ルールを、立法側が後から成文法へ取り込んだ

と理解するのが適切です。

11. 裁判が既存仕様の問題を表面化させ、法改正につながる例

別のパターンもあります。

2013年、最高裁は、当時の民法で嫡出でない子の法定相続分を嫡出子の2分の1としていた規定について違憲と判断しました。その後、民法が改正され、相続分が同等になりました。

flowchart LR
    V1[民法 v1]
    --> P[具体的事件]
    P --> J[最高裁]
    J --> X[既存仕様の一部を<br>憲法違反と判断]
    X --> C[法改正]
    C --> V2[民法 v2]

一次情報

• 法務省「民法の一部が改正されました」

12. 判例を調べる場所

裁判所は公式の裁判例検索を提供しています。

• 裁判例を調べる
• 裁判例検索

ただし、裁判所のサイトにも明記されている通り、すべての判決等が掲載されているわけではありません。

13. なぜ細かなルールを全部「法律」に書かないのか

ここで疑問が出ます。

どうせ守らなければならないなら、全部法律本文に書けばよいのでは？

しかし、すべての判定基準や社会変化への対応を法律本文へ固定すると、細かな変更のたびに大きな法改正手続が必要になります。

ITでいえば、

設定値を1つ変更するために
OSカーネルを毎回ビルドし直す

ようなものです。

そこで、

安定させたいCore
+
状況に応じて変更するConfiguration / Rule

を分離します。

14. 2023年「心理的負荷による精神障害の認定基準」は好例

厚生労働省は2023年、心理的負荷による精神障害の労災認定基準を改正しました。

背景として、近年の社会情勢の変化、労災請求件数の増加、最新の医学的知見、専門検討会での検討などが示されています。

改正では、

• カスタマーハラスメントを具体的出来事に追加
• 感染症等の病気や事故の危険性が高い業務を追加
• パワーハラスメント6類型の具体例を明記・拡充

などが行われました。

flowchart LR
    A[社会情勢の変化]
    B[労災請求データ]
    C[医学的知見]
    D[既存運用]

    A --> E[専門検討会]
    B --> E
    C --> E
    D --> E

    E --> F[検討会報告書]
    F --> G[認定基準改正]
    G --> H[労働局の認定実務]
    H --> I[新しい申請・統計・課題]
    I --> E

2023年の認定基準は、厚生労働省労働基準局長から都道府県労働局長に対する通知として定められています。

ITにすると、

労災補償制度というCoreの上で動く行政判断のRule Engine

と見るとイメージしやすくなります。

一次情報

• 精神障害の労災認定の基準に関する専門検討会
• 2023年7月の検討会報告書
• 心理的負荷による精神障害の認定基準
• 運用上の留意点

15. パブリックコメントもFEEDBACK / INPUTの1つ

政令や省令等の制定時には、行政手続法に基づく意見公募手続、いわゆるパブリックコメントが行われる場合があります。

Release Candidate
↓
Public Preview
↓
External Review
↓
Feedback
↓
Final Release

e-Govは、政令や省令等を定める際に案を公表し、広く意見・情報を募集して、その内容を考慮する仕組みとして説明しています。

提出された意見は単純な多数決ではなく、意見の内容が考慮されます。

公式リンク

• e-Govパブリックコメント
• パブリックコメント制度について

16. 法制度をPDCAとして見る

flowchart LR
    P["PLAN<br>社会問題・統計・裁判を分析<br>制度設計"]
    D["DO<br>法律・政省令・指針を整備<br>行政・企業で実装"]
    C["CHECK<br>裁判・統計・行政運用<br>制度の効果を評価"]
    A["ACT<br>法改正・基準改正<br>運用改善"]

    P --> D
    D --> C
    C --> A
    A --> P

つまり、法律はウォーターフォールで作って終わるものではなく、社会全体で長期間回り続けるPDCAとも言えます。

17. ここまでを「5レイヤーモデル」にする

flowchart TB
    I["1. INPUT<br>社会問題・事故・裁判・統計・研究"]
    D["2. DEVELOPMENT<br>検討・提言・大綱・制度設計・立法"]
    P["3. PERMISSION<br>誰が何をどこまで決められるか"]
    R["4. RUNTIME<br>行政・企業・現場で運用"]
    F["5. FEEDBACK<br>裁判・統計・運用上の問題"]

    I --> D
    D --> P
    P --> R
    R --> F
    F --> I

法律名や年号より先に、この5問を考えるだけでも理解しやすくなります。

18. Papanda実装編 ― このモデルをExcelで管理する

ここまで理屈の話でした。

では、この考え方を実際に管理するツールにしたらどうなるでしょうか。

まず一番簡単なのはExcelです。

目的は法律そのものを保存することではありません。

管理したいのは、

どの資料を読んだのか
↓
何が要求されているのか
↓
自分の組織では何を実装するのか
↓
誰が担当するのか
↓
いつ点検するのか
↓
証跡はどこにあるのか
↓
法改正があったら何を見直すのか

です。

19. Excelブックの構成イメージ

flowchart TB
    WB[Law-System-Control.xlsx]

    WB --> S1[01_Sources<br>法令・指針・提言等]
    WB --> S2[02_Requirements<br>要求事項]
    WB --> S3[03_Controls<br>自社実装・統制]
    WB --> S4[04_Evidence<br>証跡]
    WB --> S5[05_Reviews<br>点検]
    WB --> S6[06_Actions<br>改善]
    WB --> S7[07_ChangeLog<br>改正・変更履歴]
    WB --> S8[08_Dashboard<br>可視化]

20. Excel管理表イメージ① ― Sources

01_Sources は一次情報の台帳です。

ここで重要なのは、提言や報告書を法律と同じ「強さ」の列へ入れないことです。

代わりに Layer を、

INPUT
CORE
DETAIL
GUIDE
RUNBOOK
RULE

のように持たせます。

21. Excel管理表イメージ② ― Requirements / Controls

次に、資料から読み取った要求と、自分の組織の実装を分離します。

ここでは、

Source
↓
Requirement
↓
Control
↓
Evidence

というトレーサビリティを作ります。

22. Excel管理表イメージ③ ― 法改正をVersionとして管理する

ITでいう、

Current
Future
Superseded

の管理です。

flowchart LR
    C[Current]
    -->|改正公布・発出| F[Future]

    F -->|施行・適用日| N[New Current]

    C -->|置換| S[Superseded]

    N --> C2[次のCurrent]

23. Excelでは「人が判断する列」と「機械が判定できる列」を分ける

機械が判定しやすいもの

• 次回レビュー日を過ぎている
• URLが空
• EvidencePathが空
• ファイルが存在しない
• 最終確認日が古い
• StatusがFutureなのに施行日を過ぎている

人間が判断すべきもの

• この指針が自社へどう適用されるか
• 法改正の影響が重大か
• 個別事件が法的に何に該当するか
• 裁判例を自社事案へどう当てはめるか
• この統制で十分か

flowchart LR
    A[Excel / Script]
    --> B[期限・欠落・差分を検出]

    B --> C[人間へAlert]
    C --> D[法令・一次情報を確認]
    D --> E[影響・対応を判断]
    E --> F[管理表を更新]

自動化するのは判断そのものではなく、判断が必要な場所を見つけることです。

24. VBAサンプル ― Excelを開いた担当者が期限をチェックする

Excel中心の小規模運用ならVBAが便利です。

次の例は 03_Controls シートを見て、NextReview が過去なら OVERDUE、30日以内なら ATTENTION、それ以外なら OK に更新します。

Option Explicit

Public Sub CheckControlReviewDates()

    Const SHEET_NAME As String = "03_Controls"
    Const HEADER_ROW As Long = 1

    Dim ws As Worksheet
    Dim lastRow As Long
    Dim colNextReview As Long
    Dim colStatus As Long
    Dim i As Long
    Dim nextReview As Variant

    Set ws = ThisWorkbook.Worksheets(SHEET_NAME)

    colNextReview = FindHeaderColumn(ws, HEADER_ROW, "NextReview")
    colStatus = FindHeaderColumn(ws, HEADER_ROW, "Status")

    If colNextReview = 0 Or colStatus = 0 Then
        MsgBox "NextReview または Status 列が見つかりません。", vbExclamation
        Exit Sub
    End If

    lastRow = ws.Cells(ws.Rows.Count, 1).End(xlUp).Row

    For i = HEADER_ROW + 1 To lastRow

        nextReview = ws.Cells(i, colNextReview).Value

        If IsDate(nextReview) Then

            If CDate(nextReview) < Date Then
                ws.Cells(i, colStatus).Value = "OVERDUE"

            ElseIf CDate(nextReview) <= Date + 30 Then
                ws.Cells(i, colStatus).Value = "ATTENTION"

            Else
                ws.Cells(i, colStatus).Value = "OK"
            End If

        Else
            ws.Cells(i, colStatus).Value = "NO DATE"
        End If

    Next i

    MsgBox "レビュー期限の確認が完了しました。", vbInformation

End Sub

Private Function FindHeaderColumn( _
    ByVal ws As Worksheet, _
    ByVal headerRow As Long, _
    ByVal headerName As String _
) As Long

    Dim hit As Range

    Set hit = ws.Rows(headerRow).Find( _
        What:=headerName, _
        LookIn:=xlValues, _
        LookAt:=xlWhole, _
        MatchCase:=False _
    )

    If hit Is Nothing Then
        FindHeaderColumn = 0
    Else
        FindHeaderColumn = hit.Column
    End If

End Function

VBAに任せやすい処理

• ボタンを押して期限チェック
• 入力必須項目のチェック
• 点検票を新規作成
• PDF帳票を作成
• ダッシュボード更新
• 選択したControlのEvidenceフォルダを開く
• 「今回の点検日」を一括入力

つまり、

Excelの中で人間が操作する仕事を支援する

役割です。

25. PowerShellサンプル ― 定期監視する

PowerShellは、人がExcelを開いていない時間にも動かせます。

たとえばExcel管理表からCSVを出力しておき、Windowsタスクスケジューラ等で毎週実行します。

想定するCSV列は、

ControlID
Title
Owner
NextReview
EvidencePath
SourceURL

です。

param(
    [string]$InputCsv = ".\control-register.csv",
    [string]$OutputDirectory = ".\out",
    [int]$WarningDays = 30
)

Set-StrictMode -Version Latest
$ErrorActionPreference = "Stop"

if (-not (Test-Path -LiteralPath $InputCsv)) {
    throw "Input CSV not found: $InputCsv"
}

New-Item -ItemType Directory `
    -Path $OutputDirectory `
    -Force | Out-Null

$today = (Get-Date).Date
$controls = Import-Csv -LiteralPath $InputCsv

$result = foreach ($control in $controls) {

    $reviewStatus = "NO_DATE"
    $nextReview = $null

    if (-not [string]::IsNullOrWhiteSpace($control.NextReview)) {
        $parsed = [datetime]::MinValue

        if ([datetime]::TryParse($control.NextReview, [ref]$parsed)) {
            $nextReview = $parsed.Date

            if ($nextReview -lt $today) {
                $reviewStatus = "OVERDUE"
            }
            elseif ($nextReview -le $today.AddDays($WarningDays)) {
                $reviewStatus = "ATTENTION"
            }
            else {
                $reviewStatus = "OK"
            }
        }
        else {
            $reviewStatus = "INVALID_DATE"
        }
    }

    $evidenceStatus = "NO_PATH"

    if (-not [string]::IsNullOrWhiteSpace($control.EvidencePath)) {
        if (Test-Path -LiteralPath $control.EvidencePath) {
            $evidenceStatus = "EXISTS"
        }
        else {
            $evidenceStatus = "MISSING"
        }
    }

    [pscustomobject]@{
        ControlID      = $control.ControlID
        Title          = $control.Title
        Owner          = $control.Owner
        NextReview     = $control.NextReview
        ReviewStatus   = $reviewStatus
        EvidencePath   = $control.EvidencePath
        EvidenceStatus = $evidenceStatus
        SourceURL      = $control.SourceURL
        CheckedAt      = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    }
}

$reportPath = Join-Path $OutputDirectory "control-check.csv"

$result |
    Export-Csv `
        -LiteralPath $reportPath `
        -NoTypeInformation `
        -Encoding UTF8

$alerts = $result | Where-Object {
    $_.ReviewStatus -in @(
        "OVERDUE",
        "ATTENTION",
        "INVALID_DATE"
    ) -or $_.EvidenceStatus -eq "MISSING"
}

$alertPath = Join-Path $OutputDirectory "control-alerts.csv"

$alerts |
    Export-Csv `
        -LiteralPath $alertPath `
        -NoTypeInformation `
        -Encoding UTF8

Write-Host "Checked : $($result.Count)"
Write-Host "Alerts  : $($alerts.Count)"
Write-Host "Report  : $reportPath"
Write-Host "Alert   : $alertPath"

実行すると、

control-register.csv
        ↓
PowerShell
        ↓
control-check.csv
control-alerts.csv

ができます。

26. PowerShellでHTMLレポートまで作る

CSVだけでは少し味気ないので、ブラウザで確認できるHTMLにしてもよいでしょう。

$alerts |
    Select-Object `
        ControlID,
        Title,
        Owner,
        NextReview,
        ReviewStatus,
        EvidenceStatus |
    ConvertTo-Html `
        -Title "Law / Control Review Alerts" `
        -PreContent "<h1>Law / Control Review Alerts</h1>" `
        -PostContent "<p>Generated: $(Get-Date)</p>" |
    Set-Content `
        -LiteralPath ".\out\control-alerts.html" `
        -Encoding UTF8

これなら、

毎週月曜
↓
タスクスケジューラ
↓
PowerShell
↓
期限・証跡を自動確認
↓
HTMLレポート
↓
担当者が一次情報を見て判断

という運用にできます。

27. VBAとPowerShellの役割分担

flowchart LR
    U[担当者]

    subgraph EXCEL["Excel"]
        A[Sources]
        B[Requirements]
        C[Controls]
        D[Evidence]
        E[Reviews]
        F[ChangeLog]
    end

    subgraph VBA["VBA：対話処理"]
        V1[入力チェック]
        V2[期限チェック]
        V3[帳票作成]
        V4[ダッシュボード更新]
    end

    subgraph PS["PowerShell：バッチ処理"]
        P1[定期実行]
        P2[Evidence存在確認]
        P3[期限監視]
        P4[HTML/CSV生成]
    end

    subgraph HUMAN["Human Review"]
        H[法令確認<br>影響評価<br>意思決定]
    end

    U --> EXCEL
    EXCEL --> VBA
    EXCEL --> PS
    VBA --> H
    PS --> H
    H --> EXCEL

28. この仕組み自体にもPDCAを回す

制度管理ツールを作って満足してはいけません。

flowchart LR
    P["PLAN<br>一次情報・要求を登録"]
    D["DO<br>Controlを実装<br>証跡を保存"]
    C["CHECK<br>Excel/VBA/PowerShell<br>期限・証跡を点検"]
    A["ACT<br>手順・Control・管理項目を改善"]

    P --> D --> C --> A --> P

この構造は、この記事で説明した法制度そのもののFeedback Loopと同じです。

つまり、

制度を管理するシステムも、制度と同じように更新し続ける

必要があります。

29. 法制度をDBとして考えるとさらに面白い

Excelの次にDB化することを考えるなら、データモデルはこのようになります。

erDiagram
    SOURCE ||--o{ REQUIREMENT : contains
    REQUIREMENT ||--o{ CONTROL : implemented_by
    CONTROL ||--o{ EVIDENCE : evidenced_by
    CONTROL ||--o{ REVIEW : reviewed_by
    REVIEW ||--o{ ACTION : creates
    SOURCE ||--o{ CHANGE : revised_by

    SOURCE {
        string SourceID
        string DocumentType
        string Title
        string Issuer
        string URL
        date EffectiveDate
        string Status
    }

    REQUIREMENT {
        string RequirementID
        string SourceID
        string Requirement
    }

    CONTROL {
        string ControlID
        string RequirementID
        string Owner
        date NextReview
        string Status
    }

    EVIDENCE {
        string EvidenceID
        string ControlID
        string Path
        date EvidenceDate
    }

    REVIEW {
        string ReviewID
        string ControlID
        date ReviewDate
        string Result
    }

    ACTION {
        string ActionID
        string ReviewID
        string Action
        date DueDate
    }

    CHANGE {
        string ChangeID
        string SourceID
        date EffectiveDate
        string Impact
    }

この形まで整理できれば、将来的には、

• SQLite
• Microsoft Lists
• SharePoint Lists
• Dataverse
• Power Apps
• Webアプリ

などへ移行することもできます。

30. 重要：相談内容や個人情報をこの台帳へ詰め込みすぎない

法制度管理と、実際の個別案件管理は分けて考えた方が安全です。

たとえばハラスメント相談なら、氏名、健康情報、詳細な発言内容、調査記録、関係者情報など、非常にセンシティブな情報を含む可能性があります。

したがって、このExcelは、

制度・Control・点検・Evidenceの管理

に集中させ、個別案件の詳細データは、

アクセス制御された別システム

へ分離する設計が適切です。

31. 法律を読むときの実用チェックリスト

知らない資料が出てきたら、次の順番で見ます。

法律の文章を読む前に、このメタデータを埋めるだけでもかなり整理できます。

32. 一次情報を調べる順番

flowchart TD
    Q[疑問が発生]
    --> E[e-Gov法令検索<br>現行条文]

    E --> R{改正履歴・<br>未施行改正は?}
    R --> N[日本法令索引<br>制定・改廃・法案履歴]
    N --> M[所管省庁<br>制度ページ]
    M --> G[政省令・告示・指針]
    G --> T[通達・通知・認定基準]
    T --> C[検討会・報告書・提言]
    C --> J[裁判所<br>必要なら判例]
    J --> U[理解・管理表を更新]

33. 保存しておきたい一次情報リンク集

法律そのものを確認する

• e-Gov法令検索
• 日本国憲法
• 国家行政組織法

法律が作られる過程を確認する

• 内閣法制局「法律ができるまで」
• 国立国会図書館「日本法令索引」
• 国立国会図書館 Webサービス一覧

行政の制度設計・意見募集を見る

• e-Gov パブリックコメント
• パブリックコメント制度の説明

裁判例を見る

• 裁判例を調べる
• 裁判例検索

判例法理と労働契約法を見る

• 厚生労働省「労働契約法について」
• 労働契約法の施行について
• 労働契約法条文

裁判→法改正の具体例を見る

• 法務省「民法の一部が改正されました」

精神障害の労災認定基準を見る

• 専門検討会
• 2023年検討会報告書
• 心理的負荷による精神障害の認定基準
• 運用上の留意点

34. まとめ ― 法律は「完成品」ではなく「運用中のシステム」

法律、政令、省令、指針、通達、提言、大綱、認定基準をバラバラに暗記する代わりに、

INPUT
↓
DEVELOPMENT
↓
PERMISSION
↓
RUNTIME
↓
FEEDBACK

で考えると、関係が一本につながります。

社会問題や裁判、統計はINPUT。

検討会、報告書、提言、大綱はAnalysis / Planning。

法律は社会システムの重要なCore Specification。

政令・省令・指針はCoreを具体化するDetailed Design / Implementation Guide。

通知や認定基準は行政実務で動くRunbook / Rule Engine。

企業や行政での実際の運用がRuntime。

そして裁判、統計、行政上の問題が再びFeedbackとして戻ってきます。

flowchart LR
    I[INPUT]
    --> D[DEVELOPMENT]
    --> P[PERMISSION]
    --> R[RUNTIME]
    --> F[FEEDBACK]
    --> I

法律は、上から一方的に流れてくる静的な文章ではありません。

社会という巨大な本番環境で動き、そのログを受けながら更新され続けるシステム

と考えると、今まで点で覚えていた制度が一本につながります。

そして実務では、その制度を、

Source
↓
Requirement
↓
Control
↓
Evidence
↓
Review
↓
Action

として管理できます。

Excelで構造化する。

VBAで人の作業を支援する。

PowerShellで機械的な期限・欠落を監視する。

そして最後の判断は、人間が一次情報を確認して行う。

この分担も、法制度そのものの設計とよく似ています。

記事作成時点：2026年9月15日
法令や行政基準は改正されます。実務・試験・個別案件で利用する場合は、e-Govや所管省庁で最新の施行日・改正履歴・原文を確認してください。

注意
本記事のIT用語への置き換えは、法制度を理解しやすくするための比喩です。法律、政令、省令、指針、通達、判例等の正式な法的性質をIT用語と同一視するものではありません。また、掲載したExcel・VBA・PowerShell例は法令管理の補助を目的としており、法的判断を自動化するものではありません。

免責
本記事は一般的な制度理解・学習・業務設計を目的とした情報であり、個別案件に対する法律相談・法的助言ではありません。