法律是规范文档，庭审是生产测试？用“输入→实现→反馈”来理解法律制度

关于本文
本文采用基于生成式 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 流水线，这一点我们首先需要明确。

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 —— 法律制度同时也是“权限模型”

接下来是另一个重要的轴心。

如果仅用“因为在上所以效力强”“因为在下所以效力弱”这一条标准去单向看待法律、政令、省令、指引、通知等，往往容易产生误解。

我们需要审视的是：

• 由谁制定
• 由谁修改
• 经过了什么程序
• 能决定到什么程度
• 被上位法赋予了什么权限
• 对象是谁
• 违反时会产生什么法律效果

等等。

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

这样的对应关系。

然而，这种归类方式是危险的。

有些指引同样是为了具体化法律义务而根据法律规定制定的。此外，在同一个指引中，也可能既有法律上必要措施的具体化内容，又共存着“期望的举措”。

因此，不能仅看资料名称，还需要审视：

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 年，最高法院对当时《民法》中关于非婚生子女法定继承份额为婚生子女二分之一的规定做出了违宪判决。随后，《民法》进行了修改，继承份额变得平等。

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. 公众评议（Public Comment）也是 FEEDBACK / INPUT 之一

在制定政令或省令等时，有时会依据《行政程序法》实施意见征集程序，即所谓的公众评议（Public Comment）。

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. 将目前的内容总结为“五层模型”

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 之后将其数据库化，数据模型将会是这样的。

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

不如从 IT 的视角来思考，这样它们之间的关系就会串联成一条直线。

社会问题、庭审和统计是 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 示例仅以辅助法令管理为目的，并非用于自动化法律判断。

免责声明
本文是旨在一般性制度理解、学习及业务设计的信息，并非针对个别案件的法律咨询或法律建议。