# レガシー集計資産 仕様書逆生成＋Python移行支援 — 営業・デモガイド

## これは何か（1分説明）

厚生労働省統計処理システムで動いている**レガシー集計プログラム**（SAMAS・DICS64 相当のパラメタ形式作表定義、COBOL・FORTRAN・C の集計処理）と**固定長ファイル定義**を貼り付けるだけで、

1. **処理仕様書を逆生成**する（入力レイアウト／選択条件／前処理／集計軸／出力表定義／特殊処理・暗黙ルール／未確定事項）
2. その仕様書から **Python(pandas)実装・既存出力との突合検証コード・検証観点チェックリスト**を生成する

という2段構成のワークフローです。

- 判断にはすべて `[根拠: 文書名]` タグ
- **仕様書の「未確定事項」は実装でも未確定のまま扱う**（コードに `# TODO(要確認):` を残し、暫定値を使ったことを明示）
- 両方の出力の末尾に「最終判断は職員」固定文言

**このUCの肝は「移行は新しいリスクではない」という建付け**です。統計データの正確性の確保対策 3(7) は「主要な値については…**別の手法等（他言語のプログラムを含む。）により数値を算出するなどして確認**を行うこと」と**既に求めています**。Python実装はその「別の手法」そのものであり、いま人が Excel でやっている検算を機械に置き換えるものだ、と説明できます。

## 実務調査の結果（2026-08-03、この設計の根拠）

| 論点 | 実態 | 出典 |
|---|---|---|
| **SAMAS/DICS は統計解析ソフトではない** | 「厚生労働省統計処理システムにおいて、データチェック、審査、統計表の作成等の処理をするための**厚生労働省独自のプログラミング言語**」。SAMAS＝審査、DICS＝**パラメタ形式の簡易なコマンドを組み合わせて統計表を作成**。現行世代は SAMAS・**DICS64** | [書面調査項目の概要 別紙1 p.16](https://www.soumu.go.jp/main_content/000617512.pdf) |
| **Python 移行は既に省の公式方針** | 対応方針3「SAMAS・DICS64 の技術者の減少等に伴い…**汎用プログラミング言語（Python など）への移行**や『汎用集計ツール』の活用可能性も含めて…検討する」 | [第8回統計改革検討会 参考3 p.7](https://www.mhlw.go.jp/content/10700000/001585871.pdf) |
| **いまが移行計画の策定フェーズ** | 令和6年度下期〜7年度上期に業務フロー全量調査・Python検証環境整備（統計端末／NAS）・職員研修。**令和7年度下期の予定＝「統計調査ごとの移行計画（移行方式及び移行時期）の策定」** | [第8回統計改革検討会 資料2](https://www.mhlw.go.jp/content/10700000/001585868.pdf) |
| **実質デッドライン** | 令和8年1月 次期システム稼働（オンプレ→クラウド、**言語移行は積み残し**）／令和8年3月末 現行運用保守終了／**令和11年度以降 GSS 移行** | 同上 |
| **ドキュメント不整備は省が自己申告している** | 対応方針1「利用者が自由にデータやプログラムを作成・修正して、**設計書等も一元管理されておらず**、プログラムやドキュメントの**修正履歴等の確認が困難な状態**」 | [第8回統計改革検討会 参考3 p.7](https://www.mhlw.go.jp/content/10700000/001585871.pdf) |
| **仕様書整備は2019年の自己コミット** | 統計改革ビジョン2019 工程表「『**ブラックボックス化**』したシステムを有する統計においては、**仕様書等を早急に整備し**、汎用性が高く、容易に改修等ができるシステムへの計画的な移行を早急に検討する」 | [工程表](https://www.mhlw.go.jp/content/10700000/000851284.pdf) |
| **省内に移行完遂の実績がある** | 令和5年度に**毎月勤労統計の集計を COBOL → C++ へ完全移行** | [第8回統計改革検討会 資料2](https://www.mhlw.go.jp/content/10700000/001585868.pdf) |
| **移行時の考慮事項を省が名指ししている** | クラウド化の方針に「（**OSや文字コード、固定長ファイル等**の考慮すべき事項は存在するため、詳細については継続検討が必要）」 | [第8回統計改革検討会 参考3 p.7](https://www.mhlw.go.jp/content/10700000/001585871.pdf) |

→ **対応方針1（ドキュメント不整備）と対応方針3（Python移行）を1本のワークフローで同時に潰す**、が設計の結論。

## ワークフロー構成

```
start（レガシー集計プログラム + 固定長ファイル定義 + 移行方針 + 補足）
  → kr1: 集計検証観点・移行実務論点のナレッジ検索（query=legacy_program, 4docs, top_k=10）
  → llm1: 処理仕様書の逆生成（gpt-5-mini, temp=0.2）
  → llm2: Python実装＋突合検証（gpt-5-mini, temp=0.2, 仕様書と原本の両方を入力）
  → end: spec（処理仕様書） / migration（Python移行案）の2出力
```

### 逆生成と実装をノードで分けた理由

1. **職員が仕様書を先にレビュー・修正できる。** 仕様書が誤っていれば実装も誤る。人が介入する切れ目を工程として作っている
2. **仕様書は移行しなくてもドキュメント資産として残る。** 対応方針1（ドキュメントの適正管理）と、正確性の確保対策 4（登録データ保管時のドキュメント提出）を単独で満たす
3. **工程ごとにモデル・温度を選べる。** 児童手当UC・患者調査UCの「転記と審査を分ける」と同じ設計思想
4. **出力を end の2変数に分けているので、仕様書だけを配布・回覧できる**

## デモの流れ（見どころ）

1. **サンプル1（DICS風・患者調査 推計入院患者数 TBL-0301）** を投入。移行方針＝`Python（pandas）へ移行`
2. **見どころ①: レイアウトの検算** — 「開始位置＋バイト数の合計 = 256 バイト、LRECL=256 と一致」を自分で足し算して示す
3. **見どころ②: コメントと実処理の食い違いを、実処理を正として立てる** — ヘッダコメントは「対象: 病院の入院患者（**一般病床のみ**）」だが、プログラムには病床の種類 `REC(042:042)` に対する選択条件が**無い**。「実処理を仕様として扱い、乖離そのものを未確定事項に挙げる」と処理する。改修時にコメントだけ取り残されるのは実務で最も多いパターン
4. **見どころ③: 暗黙ルールを名指しする** — ①`WGT REC(230:236)` は**拡大乗数（復元倍率）**であり、単純件数集計にすると推計値が実数になる ②その拡大乗数は**暗黙小数点2桁**（`0012345` → `123.45`）で、忘れると100倍ずれる ③`AGEC` は**レイアウトに存在しない項目**で、前段ジョブ `JOB-0290` が付与している（担当者は異動済み）④`M.PREF47` / `M.ICD10A` は**版管理されていない外部マスタ** ⑤`ROUND` → `SUP` の**処理順序**で結果が変わる
5. **見どころ④: Python 実装が実務的に正しい** — 固定長を `pd.read_fwf` ではなく**バイナリで読んでバイト位置でスライスしてから decode** する（全角混在で桁がずれるため）。文字コードは `cp932`。丸めは `Decimal.quantize(ROUND_HALF_UP)`（`round()` は偶数丸め）。未確定事項には `# TODO(要確認):` が入る
6. **サンプル2（COBOL風・医療施設静態調査 病床規模別 IRYOU-T05）** を投入。移行方針＝`Python（pandas）へ移行＋データベース化を前提`
7. **見どころ⑤（最大の山場）: 現行プログラムに潜んでいたバグを見つける** — `IF IR-KAISETSUSHA = "99" MOVE "98"` で開設者コードを 98 に読み替えているが、集計表は `T-KAI OCCURS 30 TIMES` = **添字30まで**しかない。**98 は配列範囲外**。「配列オーバーランや誤集計、ランタイム例外の恐れ」と未確定事項に挙がる。あわせて `COMPUTE T-RITSU(I) = T-ZAIIN(I) * 100 / T-BED-K(I)` の**ゼロ除算未チェック**、`PIC S9(5)`（符号付きゾーン10進）に負値がある意味、`PIC 9(3)V99` の暗黙小数点も拾う
8. **見どころ⑥: 移行方針で出力が変わる** — DB化前提を選ぶと `CREATE TABLE` 相当のテーブル定義と固定長→テーブル投入手順が §2 に入る
9. **クロージング**: 「**集計業務の留意事項(7)で、主要な値は別の手法でも算出して突き合わせるよう、既に求められています。Python実装はその『別の手法』そのものです。** 移行は新しいリスクではなく、いま手作業でやっている検算を機械にやらせることです。しかも 2019年の統計改革ビジョンで『仕様書等を早急に整備し』と自ら書かれている。その"仕様書"がこれです」

## 厚生労働省資料との対応

| 資料の記載 | 本ワークフローでの実装 |
|---|---|
| 対応方針1「設計書等も一元管理されておらず、プログラムや**ドキュメントの修正履歴等の確認が困難**」 | llm1 の処理仕様書＝欠けているドキュメントそのもの |
| 対応方針3「**汎用プログラミング言語（Python など）への移行**」 | llm2 の Python(pandas)実装 |
| 対応方針3「**ノンプログラミングツール**の活用」 | 移行方針 select の第4選択肢（ツールで表現できる処理／できない処理の切り分け表を出す） |
| 対応方針4「**データベース化**を検討」 | 移行方針 select の第2選択肢（テーブル定義＋投入手順を出す） |
| クラウド化の但し書き「**OSや文字コード、固定長ファイル等**の考慮すべき事項」 | KB `固定長ファイルと文字コード_Python移行の実務論点` が丸ごとこの論点 |
| 統計改革ビジョン2019「**仕様書等を早急に整備し**、汎用性が高く、容易に改修等ができるシステムへの計画的な移行」 | ワークフロー全体＝2019年の宿題2件の同時実装 |
| 正確性の確保対策 **3(7)**「主要な値については…**別の手法等（他言語のプログラムを含む。）**により数値を算出するなどして確認」 | llm2 §3 の突合検証コード＝3(7) の自動化。**移行の建付けの根拠** |
| 同 **3(8)**「有効桁数や精度」 | 暗黙小数点・整数除算・丸め方式・`Decimal` の扱い |
| 同 **3(9)**「集計項目が変更になった場合…**指定都市・中核市の追加**等」 | サンプル2の改修履歴「H26.04(指定都市の追加)」がそのまま該当 |
| 同 **2(2)②**「**エラーケースを含んだデータセット**を準備すること」 | llm2 §4 のテストケース表（欠測／不詳／範囲外／未定義分類／全角混在／符号付き／改元年／レコード長不正） |
| 同 **4**「登録データファイル保管時に…ガイドラインに基づき作成した**ドキュメントについても合わせて提出**」 | 逆生成した仕様書がこの提出要件を満たす |

## 既知の制約（**隠さないことが提案の信用を作る**）

- **SAMAS・DICS64 の言語仕様は非公開である。** 公開されているのは「パラメタ形式の簡易なコマンドを組み合わせることで、統計表を作成することが可能」という性質の記述のみ。したがってデモ入力の作表定義は**その公開された性質だけを模した当社作成の等価サンプル**であり、DICS の実コマンド名ではない。KB の対応表も同様（ファイル名に `_当社作成の等価サンプル` と明記）。**実案件では先方の言語仕様書と実プログラムをKBに投入して精度を出す**
- そのためプロンプトには「対応表に無い記法は推測で断定せず**未確定事項に列挙する**」を鉄則として入れている。デモでも実際に未確定事項が9件出る
- **COBOL の添字が0起点で書かれている点は指摘しなかった**（サンプル2の `MOVE 0 TO W-KIBO` と `OCCURS 7 TIMES`＝COBOLは1起点）。配列範囲外（98 > OCCURS 30）は検出したが、0起点/1起点の規約差は検出していない。**言語規約レベルの細部は実コンパイラの仕様書をKBに入れる必要がある**
- 逆生成した仕様書は**下書き**である。原プログラムとコードリストを見た職員の確定作業が前提（出力末尾に固定文言）
- **実行時間は1件あたり3.5〜6分**（実測 208〜356秒。2段LLM＋長文出力で、仕様書 約11,000〜13,000字＋移行案 約22,000〜25,000字）。営業デモでは事前実行した結果を見せるか、投入して別の話をしながら待つ運用を推奨
- **見どころ③（コメントと実処理の食い違い）の検出は、当初 run 間で揺れた**（3回中2回）。暗黙ルールの番号付きリストに「コメントの記述を1件ずつ実処理と照合する」を項目9として追加し、§0 にも「ヘッダコメントを書き写す前に裏付けを確認する」を義務づけて補強した。E2E も、ヘッダコメントを引き写しただけでは通らないよう**食い違いを指摘する語**で判定している。それでも生成物である以上、デモ前に一度流して出方を確認すること
- **守秘区分は「要判断／閉域推奨」**。プログラムとファイルレイアウト自体は調査票情報ではないが、**突合検証のテストケースに実データが混じる**ため、閉域前提で設計するのが安全 → `docs/mhlw-toukei/05_confidentiality-llm.md`。Dify はノード単位でモデルを差し替えられるので、構成を変えずにローカルLLMへ向けられる

## 運用メモ

- サンプルは**すべてデモ用・当社作成の等価サンプル**（プログラム冒頭とレイアウト冒頭に明記）。実在の厚労省プログラムではない
- KBの正本は `knowledge/*.txt`（4文書）。うち2文書は**当社作成**でありファイル名にそう書いてある。公開資料からの引用箇所は各ファイル冒頭に出典URL・取得日を記載
- E2E: `DIFY_LOCAL_CONSOLE_URL=http://localhost/console/api DIFY_LOCAL_WORKFLOW_URL=http://localhost/v1 DIFY_LOCAL_BASE_URL=http://localhost python scripts/test_legacy_spec_python.py`（KB作成→import→2ケース実行→app+KB削除まで自己完結。`--keep` で残す）
- E2E は検証観点チェックリストが**正確性の確保対策 3(1)〜(9) を条文どおりの観点名で並べているか**も検査する（初版は条番号に独自の観点名を当てていたため、プロンプトで条文を固定した）
- 対になるUC: `verified/自治体・公共/患者調査票の内容検査と疑義照会文案/`（審査工程／SAMAS が原理的に届かない調査間整合性）。**同じ2統計（患者調査・医療施設静態調査）を題材にしており、審査＝SAMAS・集計＝DICS の両方を1セットで見せられる**
- 検討ドキュメント一式は `docs/mhlw-toukei/`。提案時の地雷リストは同 `README.md` 末尾