法律事務所・司法書士事務所で、裁判所・法務局の申立書と申請書の様式・記載例の改定をエージェントが毎月見回り、事務所のひな形の一覧と照らして差し替えが要るものを知らせる

処理の起点を決める

毎月1日の朝7時に、Schedule Trigger で動かします。 Before では割り当ての順に回していましたが、この構成では300のひな形の元のページをすべて毎月見ます。 ページを取って比べるだけなら、人の手はかかりません。工数の試算は、人が確かめる件数として月40件のまま置いています。

Schedule Trigger は、ワークフローのタイムゾーンが無ければインスタンスのタイムゾーンを使い、セルフホストの既定は America/New York とされています。ワークフローのタイムゾーンを Asia/Tokyo にし、保存して公開します。 公開しないと動かないとされています。

手続の改正の施行に合わせた月には、手で動かします。 法令の改正で様式が一斉に変わる時期は、事務所でも把握していることが多いので、施行日の翌営業日に一度動かせば、翌月を待たずに拾えます。

入力データを集める

質を決めるのは、いちばん下の欄の対応です。 公式の様式で欄が1つ増えても、事務所のひな形がその欄を使っていなければ、差し替えは急ぎません。 逆に、事務所が定型の文で埋めている欄の文言が変われば、定型の文のほうを直す必要があります。 欄の対応があれば、エージェントはこの2つを分けて候補にできます。

公式の様式の版は、取るたびにファイルと文字の両方を残します。 導入した月は比べる相手がないので、最初の1回は「基準の版を取る」だけで、違いは出しません。 第4章の②の旧版が無い問題は、ここで解きます。

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

ファイルの変化は、リンク・更新日時・大きさの3つで見ます。 2026年10月8日に裁判所の様式のPDFを取ったとき、応答のヘッダーには更新日時（Last-Modified）と大きさ、ETag が付いていました。リンクが同じでもヘッダーが変われば中身が差し替わった可能性があり、リンクが変わってもヘッダーと大きさが同じなら置き場所が変わっただけかもしれません。 どれか1つが変われば文字を取り出して比べ、3つとも同じなら比べません。

新旧の比べ方は、Compare Datasets に行を渡すだけにします。 前回の文字を1行1項目にして入力A、今回の文字を入力Bにし、行の文字で突き合わせます。「Aにだけある行」が消えた行、「Bにだけある行」が足された行です。Compare Datasets は、2つの入力をAにだけあるもの、同じもの、違うもの、Bにだけあるものに分けて出すとされています。

Word のファイルは比べる対象にしません。 同じ様式に PDF と Word がある場合、PDF のほうで比べます。 Word は事務所のひな形を作り直すときに使うので、ファイルとして残すだけにします。

AIへ渡す前に整形する

1. ページの共通部分を外す … メニューやフッターは比べません。様式の一覧の部分だけに絞ります
2. 文字を行にそろえる … 全角と半角の空白、行頭の記号、ページ番号を規則でそろえます。そろえ方は前回と今回で同じにします
3. 年号の行を印にする … 「令和○年」「2026年」だけが違う行は、体裁の違いの候補として印を付けます
4. PDFの文字が取れたかを確かめる … 取れた文字数が少ない記入例は画像のPDFと見て、「文字で比べられない」として人に回します
5. 違いの行が多すぎるものを分ける … 違いが全体の半分を超える様式は、作り直された可能性が高いので、エージェントに細かく分けさせず「全面的な改定の可能性」として人に回します

2番目と5番目を軽く見ないでください。 PDFからの文字の取り出しは、レイアウトが少し変わるだけで改行の位置が変わります。行のそろえ方が甘いと、中身が同じでも全部の行が違いに出ます。 5番目は、そうなったときに誤った候補を大量に出さないための止め方です。

AIに処理させる

させるのは、様式1件ごとに、新旧の違いの行を分け、事務所のひな形の欄と照らして差し替えの候補を挙げることです。

区分の分け方は、指示の中で具体的に決めます。 欄の名前が増えた・消えた、欄の説明の文が変わったものは「記載事項」、収入印紙の額・郵便切手・添付書類の一覧は「手数料・添付書類の案内」、記入の注意は「注意書き」、年号・ページ番号・ファイルの名前・空白の位置だけのものは「体裁」です。体裁だけの様式は、一覧の最後に件数だけを出します。 第3章の（d）は、ここで解きます。

1行目がいちばん起きやすい失敗です。 様式の文言が変わっていると、生成AIは「○○法の改正に伴うものと考えられます」と書き添えます。当たっていることもありますが、外れていても読み手には区別がつきません。 改定の理由は、案内のページや裁判所・法務局のお知らせに書かれているものだけを写させます。

指示内容を固定する

AI Agent ノードの System Message に、次のように書きます。

あなたは法律事務所・司法書士事務所の事務局で、裁判所・法務局の様式の
改定を、事務所のひな形と照らす担当です。入力は、様式1件の
新旧の違いの行（消えた行・足された行）、様式の名前、元のページのURL、
事務所のひな形の欄の対応です。

【やること】
1. 違いの行を、次の区分に分ける。
   記載事項：欄の名前・欄の説明の文が足された・消えた・変わった
   手数料・添付書類：収入印紙・郵便切手・添付書類の一覧が変わった
   注意書き：記入の注意・提出の注意が変わった
   体裁：年号・ページ番号・空白・記号の位置だけが変わった
2. 記載事項・手数料・添付書類の違いがあるときは、道具で元のページと
   手続の案内のページを開き、改定の説明が書かれていれば写す。
3. 事務所のひな形の欄の対応と照らし、違いがひな形のどの欄に関わるか、
   事務所の定型の文に関わるかを挙げる。
4. 差し替えの候補として、直す箇所と公式の新しい文字を示す。

【厳守事項】
- 新旧の文字は、入力の行のとおりに写してください。言い換えないでください。
- 改定の理由は、ページに書かれているときだけ写してください。書かれて
  いなければ reason_in_source を false にし、推測で書かないでください。
- 手数料・郵便切手・添付書類の額や通数は、様式の文字にあるものだけを
  書いてください。
- 手続や実務への影響、差し替えるべきかの結論を書かないでください。
- 体裁の違いしかないときは、change_type を cosmetic にして、
  候補を挙げないでください。
- 区分に迷う行は、体裁に入れず、記載事項に入れて uncertain を true にしてください。

【出力】指定のJSONの形で返してください。

「区分に迷う行は記載事項に入れる」が、この指示の要です。 体裁に入れた行は、一覧の最後に件数だけで出て、誰も中身を読みません。 迷ったときに読まれる側へ倒すことで、見落としの向きを片方に寄せます。

「改定の理由は書かれているときだけ」と reason_in_source を組にしているのも、同じ考えです。 理由が案内のページから来たのか、AIが補ったのかを、出力の項目で区別できるようにします。

出力形式を固定する

Structured Output Parser で、次の形のJSONを返させます。

{
  "form_name": "",
  "source_page": "",
  "file_url_old": "", "file_url_new": "",
  "change_type": "content | fee_attachment | notes | cosmetic | mixed",
  "changes": [
    { "category": "content | fee_attachment | notes | cosmetic",
      "old_text": "", "new_text": "", "uncertain": false }
  ],
  "reason_quote": "", "reason_in_source": false,
  "office_templates": [
    { "template": "", "field": "", "office_text_affected": false, "fix_candidate": "" }
  ],
  "unresolved": [""]
}

1つ目の理由は、change_type で知らせ方を変えられることです。 content と fee_attachment は担当の弁護士・司法書士へ、notes は事務局の確認だけ、cosmetic は件数だけにします。

2つ目は、office_text_affected で急ぐものが分かることです。 事務所の定型の文が公式の新しい文言と食い違うものは、そのひな形で作った書面がそのまま古い文言で出ていくので、最初に並べます。

3つ目は、old_text と new_text で、ファイルを開かずに違いが読めることです。

5行目は、エージェントを通さずに人が見るものです。 件数は少なくても、いちばん読む価値があります。

システムへ連携する

エージェントの道具は、公式のページを開く HTTP Request だけです。 ひな形の一覧への書き込みは、ワークフローの側で Append or Update Row を使って行います。エージェントが一覧やひな形を書き換える経路を作りません。 HTTP Request の道具の向き先も、裁判所と法務局のドメインに限ります。

人が確認する

1. 並べ順の1を、担当の弁護士・司法書士が読む … 事務所の定型の文と公式の新しい文言の食い違いを確かめ、直すかを決めます
2. 並べ順の2を読む … old_text と new_text を読み、必要なら新しい様式のファイルを開きます。ここが確認の中心です
3. 差し替えを決めたものを事務局が直す … 公式の新しいファイルからひな形を作り直し、事務所の定型の文を入れ直します
4. 並べ順の5を事務局が見る … 文字で比べられなかった記入例は、画面で新旧を見比べます
5. 判断を記録する … 差し替えた・差し替えない・理由を、ひな形の一覧に残します

目標は、1件をならして12分です。 違いの区分と引用の確認に6分、差し替えの要否の判断材料の確認に4分、一覧の更新の確認に2分という見込みです。ひな形を作り直す時間は、Before にも After にも入れていません。

例外に対処する

上の2行は、サイトの模様替えのときに起きます。 ページのURLが変わると、リンクの比較が全部外れます。3回続けて取れないものを人に知らせる決まりにしておけば、元のページが黙って消えることはありません。

記録を残す

• 実行ごとの、ページの取得の成否と、ファイルのリンク・ヘッダー
• 公式の様式の版ごとのファイルと、取り出した文字
• 新旧の違いの行と、エージェントのJSON出力
• 弁護士・司法書士の判断 … 様式ごとの差し替えの要否と理由、判断した日
• 公式の様式が変わったことを知った日と、ひな形を差し替えた日

2つ目で版ごとの文字を残すのは、後から「いつの様式で作った書面か」を確かめるためです。 補正の連絡を受けたとき、提出した書面の元のひな形が、どの版の公式の様式から作られていたかを、保存した版と日付でたどれます。

最後の行が、この構成の物差しです。 公式の変化から事務所のひな形の差し替えまでの日数を並べると、見回りが遅れているのか、判断や作り直しが遅れているのかが分かれて見えます。