NILIM2.0 を WSL2 + Docker + gfortranで動かして、節点 / 河道区間型の河道網へ機能拡張する

はじめに

国土技術政策総合研究所の NILIM2.0 は、都市域の内水氾濫だけでなく、河道・氾濫原・下水道を組み合わせて内外水複合氾濫まで扱うことができる解析モデルです。

公式マニュアルでは、大きく次の3つのモデルから構成されています。

NILIM2.0の機能

河道モデル：一次元不定流
氾濫原モデル：平面二次元不定流
下水道モデル：開水路流れと圧力流れを扱う Diffusion Wave 法

さらに、破堤・溢水、盛土、水路、樋門・カルバート、排水機場、調節池なども扱える構成になっています。

一方、NILIM2.0の公式配布ページでは、2024年9月6日からソフトウェアの公開・個別配布が停止されています。理由として、推奨環境だったWindows 7のサポート終了により、国総研側で動作確認環境を維持することが難しくなったことが挙げられています。

技術そのものが使えなくなったわけではありません。公式ページにはマニュアルや関連資料が残されており、過去の配布条件では、著作権表示を維持することなどを条件として使用・複製・改変が認められていました。

そこで現在、手元にあるNILIM2.0のソースと公式サンプルを使いながら、

元の計算方法をできるだけ残し、Linux / gfortranで再現可能な状態にしたうえで、河道網やデータ構造を段階的に整理・再構成する
また、python環境への移植、GUI環境を備えたシステムへの機能拡張も考えています。

という作業を進めています。

現在の実行環境は、Windows 11上のWSL2 Ubuntuを入口にして、gfortranのビルド・回帰試験をDockerコンテナ内で行える形へ整理します。Windows側へDocker Desktopを入れず、WSL2 Ubuntu内のDocker Engineを使う構成です。

この記事では、これまでに行った旧Windows版との比較、gfortran版の基準作成、明確な不具合の修正、(節点 / 河道区間) Node / Reach型河道網への拡張、回帰テストの整備までをまとめます。

1. NILIM2.0はどのようなモデルか

NILIM2.0は、河川だけ、下水道だけを単独で計算するプログラムではありません。

河道、地表面、下水道の水の移動を組み合わせることで、都市域で発生する複雑な浸水現象を扱います。

公式マニュアルでは、解析種別として次の4種類が整理されています。

解析種別	使用する主なモデル
内外水複合氾濫	河道 + 氾濫原 + 下水道
外水氾濫	河道 + 氾濫原
内水氾濫	氾濫原 + 下水道
河道水位解析	河道

河道モデルでは、上流端の時系列流量、下流端の時系列水位、初期水位・流量、横断面特性などを使います。

氾濫原は一般に50～250m程度のメッシュで表現し、NILIM2.0では密集市街地を対象とすることから50mメッシュを標準としています。

下水道は、人孔と管路からなる管路網として扱います。管路内の状態に応じて開水路流れと圧力流れを切り替え、人孔から地表面への溢水と、地表面から下水道への再流入も計算します。

2. 今回は「別の計算モデル」に作り替えない

古いFortranプログラムを見直すと、最初から全部を書き直したくなります。

ただし、水理計算プログラムでは、それを最初にやると危険です。

たとえば、

実数精度を変える
収束条件を変える
時間刻みを変える
しきい値を変える
河道の接続方法を変える
支配方程式を書き換える

といった変更を同時に行うと、結果が変わった原因を追えなくなります。

そのため、今回の作業では次の順番を守ることにしました。

旧Windows版
    ↓
公式サンプルで基準結果を取得
    ↓
gfortran版を同じ条件で計算
    ↓
Windows版との差を調べる
    ↓
gfortran REAL*4版を修正前基準として固定
    ↓
明確なコード上の不具合だけ修正
    ↓
同一gfortran環境で回帰比較
    ↓
既存計算を残したままNode / Reach層を追加
    ↓
小規模回帰 + 全期間回帰

ここで重要なのは、旧Windows版と完全に同じ数値を無理に作ることを最初の目標にしていないことです。

まず、元の計算方法を理解し、どこで差が発生するのかを把握し、その差を再現できる状態にすることを優先しました。

3. Windows 11 + WSL2 + Dockerで実行環境を固定する

ここからの計算は、Windows上で直接gfortranを動かすのではなく、WSL2 Ubuntuの中にDocker Engineを入れ、そのDocker上でNILIM2.0を実行する構成にします。

今回の構成では、Windows側へDocker Desktopをインストールする必要はありません。

Windows 11
    ↓
WSL2
    ↓
Ubuntu 24.04
    ↓
Docker Engine
    ↓
Docker Compose
    ↓
NILIM2.0 gfortran実行環境
    ├─ build
    ├─ fast regression
    └─ full validation

構成図にすると次のようになります。

3.1 WSL2を確認する

Windows 11のPowerShellから確認します。

wsl --status
wsl --list --verbose

まだWSLを導入していない場合は、管理者権限のPowerShellから次のように導入できます。

wsl --install

Microsoftの現在の手順では、wsl --install によりWSLに必要な機能と既定のUbuntu環境をまとめて導入できます。

今回の計算環境では、WSL1ではなく WSL2 を使用します。

確認例です。

NAME            STATE           VERSION
Ubuntu-24.04    Running         2

3.2 プロジェクトはWSL側へ置く

NILIM2.0は計算中に多数の結果ファイルを書き出します。

そのため、プロジェクトは、

/mnt/c/Users/...

のようなWindowsファイルシステム上ではなく、できるだけWSL側のLinuxファイルシステムへ置きます。

たとえば、

mkdir -p ~/vol
cd ~/vol
unzip NILIM2.0_step4_r002_fix001.zip
cd NILIM2.0_step4_r002_fix001

のような配置です。

今回の説明では、以降このディレクトリをプロジェクトルートとします。

~/vol/NILIM2.0_step4_r002_fix001/

3.3 WSL2 UbuntuへDocker Engineを入れる

Docker Desktopではなく、WSL2 Ubuntuの中へDocker Engineを直接インストールします。

Docker公式のUbuntu向けapt repositoryを登録して、EngineとCompose pluginを入れます。

sudo apt update
sudo apt install -y ca-certificates curl

sudo install -m 0755 -d /etc/apt/keyrings

sudo curl -fsSL \
  https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

sudo apt install -y \
  docker-ce \
  docker-ce-cli \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin

インストール後に確認します。

sudo systemctl status docker
docker --version
docker compose version

必要に応じて、一般ユーザーからDockerを実行できるようにします。

sudo usermod -aG docker "$USER"

設定後はいったんWSLのシェルを終了して入り直します。

確認は、

docker run --rm hello-world

です。

3.4 NILIM2.0用Dockerfile

プロジェクトルートに docker/ を作り、次の Dockerfile を置きます。

FROM ubuntu:24.04

ENV DEBIAN_FRONTEND=noninteractive
ENV LANG=C.UTF-8
ENV LC_ALL=C.UTF-8

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
       ca-certificates \
       gfortran \
       make \
       python3 \
       python3-pip \
       time \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /workspace

CMD ["bash"]

ここでは、水理計算そのものをDockerfileへ埋め込みません。

Docker imageには、

Ubuntu
gfortran
Python
/usr/bin/time

など、実行と検証に必要な環境だけを入れます。

計算ソース、公式サンプル、テストスクリプトはプロジェクトディレクトリをbind mountして使用します。

3.5 compose.yaml

プロジェクトルートへ次の compose.yaml を置きます。

services:
  nilim20:
    build:
      context: .
      dockerfile: docker/Dockerfile

    working_dir: /workspace

    volumes:
      - .:/workspace

    user: "${NILIM_UID:-1000}:${NILIM_GID:-1000}"

    environment:
      HOME: /tmp
      TMPDIR: /tmp
      LANG: C.UTF-8
      LC_ALL: C.UTF-8

    stdin_open: true
    tty: true

WSLの最初の一般ユーザーであれば、多くの場合UID/GIDは1000:1000です。

確認できます。

id

もし1000以外なら .env を作ります。

NILIM_UID=1001
NILIM_GID=1001

これにより、コンテナで作成した結果ファイルがすべてroot所有になることを避けられます。

3.6 Docker imageをbuildする

プロジェクトルートで実行します。

docker compose config
docker compose build --no-cache

まず、コンテナ内のgfortranを確認します。

docker compose run --rm nilim20 \
  gfortran --version

NILIM2.0ではコンパイラによるごく小さな浮動小数点差が、SPLITSVのしきい値判定へ影響することを確認しています。

そのため、検証ログには必ず、

gfortran version
Docker image
対象revision

を残すようにします。

3.7 まず高速回帰を実行する

スクリプトに実行権限がない場合は、WSL側で付けます。

chmod +x scripts/*.sh

高速回帰は次の1コマンドで実行します。

docker compose run --rm nilim20 \
  ./scripts/run_fast_regression.sh

現在のStep 4 r002では、

STATIC CHECK
TARGETED TESTS
NODE/REACH TOPOLOGY TEST
NODE/REACH RVQCAL ENDPOINT TEST
VALIDATOR PARSER REGRESSION
case01_steady
case02_pulse

を順番に確認します。

最後が、

STEP 4 R002 FAST REGRESSION: PASS

であれば、Node / Reachまわりの短時間回帰は完了です。

3.8 公式サンプルの全期間検証

大きな変更を行った場合や配布前には、公式サンプルを使った全期間検証もDocker内から実行します。

docker compose run --rm nilim20 \
  ./scripts/run_full_validation.sh

ここでも重要なのは、別PCで作った固定結果との単純比較ではないことです。

同じDocker imageの中で、

Step 4 r001 local baseline
        ↓
29400秒まで計算

Step 4 r002 legacy mode
        ↓
29400秒まで計算

Step 4 r002 graph mode
        ↓
29400秒まで計算

を実行し、結果を比較します。

つまりDockerを使う目的は、

Dockerに入れれば数値結果が必ず全環境で完全一致する

ことではありません。

目的は、

コンパイラ、ライブラリ、実行コマンドをまとめて固定し、同一条件で基準版と修正版を比較できるようにする

ことです。

3.9 普段の開発ではコンテナへ入って作業してもよい

調査中は、毎回docker compose runへ長いコマンドを書くより、シェルへ入る方が扱いやすい場合があります。

docker compose run --rm nilim20 bash

コンテナ内では、

gfortran --version

./scripts/run_fast_regression.sh

./scripts/build_linux.sh

./scripts/run_linux.sh

のように、これまでWSL上で直接実行していたスクリプトをそのまま使えます。

プロジェクト全体をbind mountしているため、結果ファイルはWSL側にも残ります。

3.10 Docker化後の実行フロー

最終的には、普段の確認を次のようにします。

この構成にしておくと、Windows 11側は編集・ファイル管理の入口として使い、水理計算環境はWSL2上のDockerへまとめられます。

また、将来CIへ移行するときも、

Docker build
Fast Regression
Full Validation

という現在の流れをそのまま持っていきやすくなります。

4. Step 3：旧Windows版とgfortran版を29400秒まで比較した

最初に必要だったのは、修正前の基準です。

NILIM2.0に付属している公式サンプルを使い、旧Windows版とgfortran版で同じ計算を実行しました。

今回の比較条件は次のとおりです。

項目	条件
解析種別	内外水複合氾濫
計算開始	9000秒
計算終了	29400秒
計算刻み	1秒
出力間隔	1分
管路数	73
人孔数	75
実数精度	REAL*4
gfortran最適化	なし

gfortran版は29400秒まで完走しました。

主要な結果ファイルについて、数値として読み取れる範囲では NaN と Inf は確認されませんでした。

ただし、旧Windows版とgfortran版の数値は途中から完全一致しません。

調査した結果、差が大きくなる最初の場所は、下水道の分流計算を行う SPLITSV 付近でした。

これは、gfortranへ移したことで支配方程式そのものが別物になった、という話ではありません。

元プログラムは多くの計算を単精度の REAL*4 で行っています。

その途中に 0.001 付近で処理を切り替える判定があるため、コンパイラや浮動小数点演算による非常に小さな差が判定の反対側に入ると、その後の反復計算経路が変わります。

この結果から、Step 4へ進むときの基準を次のように決めました。

gfortran REAL*4版を「修正前基準」として固定し、以降の修正は同じPC・同じgfortranで再計算して比較する。

異なるgfortranバージョンで作った結果ファイルを固定期待値にする方法は採用していません。

5. REAL*4はそのまま残した

途中でREAL*8による倍精度化も検討しました。

ただし、互換性を確認している段階でプログラム全体を倍精度へ変更すると、

コード修正による差

と、

REAL*4 → REAL*8による差

を分けられなくなります。

そこで、現在の互換基準版では REAL*4 を維持しています。

同様に、次の条件も勝手に変更していません。

EPS = 0.001
ABS(QQWEIR_s) < 0.001
下水道の収束条件
dwsizeによる時間刻み再分割
河道・氾濫原・下水道の支配方程式

性能改善や倍精度化は、この基準版が安定してから別の検討として行う方が追跡しやすいと考えています。

6. Step 4 r001：明確な不具合だけを修正した

基準ができたところで、ソースを静的に確認し、明確に誤っている箇所を修正しました。

r001で修正した主な内容は次の5点です。

nlimflg / nilmflg の綴り違い
土研式破堤で使用する BRD の配列添字と断面・左右岸参照
SUIファイル処理の CLOSE(93) を CLOSE(92) へ修正
2月28日固定だった時刻処理を、うるう年と年越しへ対応
開水路入力 FORMAT 末尾の余分な閉じ括弧を修正

一方、次の部分は変更していません。

REAL*4
SPLITSV のしきい値
河道・氾濫原・下水道の支配方程式
下水道の収束条件
dwsize
既存の河道計算方法

公式マニュアルのモジュール一覧を見ると、河道計算では次のサブルーチンが中心になっています。

RVHCAL   連続式による河道水位の計算
RVHINS   河道水位の内挿
RVQCAL   河道流量計算
RVQINS   河道流量の内挿

今回の再構成では、この部分を安易に置き換えないことを基本方針にしています。

7. 回帰テストは「同じ環境で再計算して比較」する

NILIM2.0のように単精度計算としきい値判定を多く含むプログラムでは、別環境で作った1個の結果ファイルを正解として固定すると、コンパイラ差をプログラム不具合と誤判定する可能性があります。

そのため、r001以降では次の方法を採用しています。

同じPC
同じgfortran
同じコンパイル条件
        ↓
修正前版を計算
        ↓
修正版を計算
        ↓
主要出力を比較

Step 4 r001の全期間検証では、

Step 3 r002 修正前版
    ↓
9000～29400秒

Step 4 r001
    ↓
9000～29400秒

両結果
    ↓
完走確認
NaN / Inf確認
行数確認
主要数値結果比較

という流れにしています。

水理計算の変更と、コンパイラ固有の浮動小数点差を分けて見るための仕組みです。

8. Step 4 r002：河道をNode / Reachとして扱えるようにした

次に着手したのが河道網です。

元のNILIM2.0にも、支川、放水路、合流、分流を扱う仕組みがあります。

公式マニュアルの河道関連変数にも、

CHT
CFCS
SPCS

などがあり、本川・支川・捷水路・分水路、合流断面、分流断面を管理しています。

ただし、今後さらに複雑な河道網を扱いやすくするには、水理計算そのものと接続関係を分けた方が扱いやすいと考えました。

そこでr002では、

Node  = 水理的な接続点
Reach = Nodeまたは外部境界の間にある河道区間

という接続層を追加しました。

ここで大事なのは、河道計算を全面的に書き直したわけではないことです。

9. 既存のRVHCAL / RVQCALを残してwrapperを追加した

r002では、既存の次のサブルーチン本体を残しています。

RVHCAL
RVHINS
RVQCAL
RVQINS

河道運動方程式に関係する CSMVEQ も置き換えていません。

代わりに、1段wrapperを挟みました。

river_network_graph.dat が無ければ従来計算へ戻る legacy mode、ファイルがあればNode / Reach接続を使う graph mode です。

river_network_graph.dat なし
    ↓
legacy mode
    ↓
従来CHT / CFCS / SPCS
    ↓
既存河道計算

river_network_graph.dat あり
    ↓
graph mode
    ↓
Node / Reach接続検査
    ↓
Node端点の接続条件を構築
    ↓
Reach内部は従来の河道計算式

これによって、

互換性を確認する経路

と、

新しい河道網を扱う経路

を同じコードの中で比較できます。

10. 公式サンプルでlegacy modeとgraph modeを比較した

Node / Reachを追加しただけで従来結果が変わってしまっては意味がありません。

そこで公式サンプルを使い、

Step 4 r001 local baseline
        ↓
Step 4 r002 legacy mode
        ↓
Step 4 r002 graph mode（単一Reach）

を同じgfortran環境で比較しました。

利用者側のGNU Fortran 13.3.0環境では、3ケースとも29400秒まで完走し、

r001 → r002 legacy
r002 legacy → graph single reach

について、主要9出力がbyte-identicalとなることを確認しています。

一方、パッケージ作成に使った別のGNU Fortran 14.2.0環境では、実行時間上限の関係で公式サンプルの長時間計算を途中まで確認した記録もあります。

そのため、配布物では短時間回帰と全期間回帰を分けています。

11. Node / Reach専用の短時間回帰ケースを作った

公式サンプルの全期間計算は重要ですが、Node / Reachを1か所直すたびに数分の計算を待つのは効率が良くありません。

そこで、公式サンプルの河道断面を再利用して、2 Node / 5 Reach の短時間検証ケースを作りました。

このケースでは、一度に次を確認できます。

複数河道の合流
複数河道への分岐
再合流
複数Node
Node端点の水位・流量処理
対称なReachの応答

case01_steady

定常ケースです。

Main上流流量       1.0 m3/s
Tributary A        0.2 m3/s
Tributary B        0.2 m3/s
下流水位           29.600 m
計算時間           1時間
出力間隔           1分

case02_pulse

同じ河道網に対して、2本の支川へ同じ流量パルスを与えます。

時間変化がある状態でも、対称なReachが同じ応答になるかを確認します。

12. 高速回帰テストを正式に組み込んだ

現在の run_fast_regression.sh では、次を順番に実行します。

1. STATIC CHECK
2. r001修正項目のtargeted test
3. Node / Reach topology test
4. Node / Reach endpoint test
5. CRSS validator parser regression
6. case01_steady
7. case02_pulse

最終的に、

STEP 4 R002 FAST REGRESSION: PASS

となることを確認します。

作成環境のGNU Fortran 14.2.0では、定常・パルスケースの計算時間はそれぞれ約0.03秒でした。

検証では次を確認しています。

graph modeで2 Node / 5 Reachとして認識される
60個の1分出力が存在する
数値が有限値である
対称なReach同士の結果が一致する
上流流量境界が正しい
下流水位境界が正しい
パルス流量が反映される
Node診断出力が存在する
fatal errorが出ていない

この高速回帰は全期間29400秒検証の代わりではありません。

役割を分けています。

普段は高速回帰で壊れていないことを確認し、大きな変更や配布前には全期間検証を行います。

13. 現在の構成

Step 4 r002では、概ね次のように整理しています。

NILIM2.0_step4_r002/
├── source/
│   ├── NILIM20_step4_r002_real4_linux.for
│   ├── NILIM20_step4_r002_real4_windows.for
│   ├── common20.inc
│   ├── river_network_topology_linux.for
│   ├── river_network_topology_windows.for
│   ├── river_network_solver.for
│   └── r001_local_baseline/
├── examples/
│   ├── river_network_graph_single_reach.dat
│   └── river_network_graph_multi_junction_example.dat
├── tests/
│   ├── regression/
│   ├── test_targeted_fixes.py
│   └── test_river_network_graph.py
├── tools/
│   ├── static_checks.py
│   ├── compare_result_dirs.py
│   └── legacy_summary_to_graph.py
├── scripts/
│   ├── run_fast_regression.sh
│   └── run_full_validation.sh
└── docs/

考え方としては、

元の数値計算
      +
接続関係を扱う層
      +
自動検証

を分け始めた段階です。

14. 最終的には計算ロジックとデータ構造を分離したい

今後の再構成では、Fortranのサブルーチンを単純に別ファイルへ分けるだけではなく、扱っている対象を明確にしたいと考えています。

目標としている構成は次のようなものです。

特に河道では、

河道の接続関係

と、

各Reach内部の水理計算

を分離することが重要だと考えています。

これができると、

合流
分岐
並列河道
再合流
支川
放水路
複数下流端
水理構造物との接続

を、サブルーチン内部の特別扱いだけで増やさずに済みます。

15. 質量保存の保証

Node / Reach化で次に重要になるのが質量収支です。

現在も river_node_balance.dat でNode診断を出力していますが、今後はさらに、

ΣQin
ΣQout
Nodeへの横流入
Nodeの有効貯留量
dV/dt

を整理し、

ΣQin - ΣQout + Qlateral - dV/dt

をNodeごとに評価できるようにする予定です。

単純に「流入量と流出量が瞬間的に一致すること」だけを要求すると、水位変化に伴うReach端部やNode周辺の貯留を無視する可能性があります。

そのため、Nodeの有効貯留を含めた形で診断できるようにしてから、より厳密な質量収支試験へ進む方針です。

16. 今後の進め方

現在の流れを続けるなら、次は以下の順番が良さそうです。

Step 5：Node質量収支の強化

Node有効貯留量
dV/dt
流入・流出・横流入の明示
許容誤差の定義
定常・非定常ケースでの自動検査

Step 6：より一般的な河道網

Node数を固定しない
Reach数を固定しない
複数合流
複数分岐
並列河道
再合流
複数境界条件

Step 7：水理構造物との接続整理

元NILIM2.0にある、

堰
調節池
樋門・樋管
カルバート
排水機場
横流入

を、河道網との接続関係が分かるデータ構造へ整理します。

Step 8：氾濫原モデルの整理

河道側と同じように、

データ
計算
境界
構造物
結果

を分けて追えるようにします。

Step 9：下水道モデルの整理

特に、

SPLITSV
MAINSV
STVEN
DWSIZE

など、Step 3で差が確認された箇所を診断しやすくします。

Step 10：河道・氾濫原・下水道の連成を再整理

最後に、

河道 ↔ 氾濫原
氾濫原 ↔ 下水道
下水道 ↔ 河道

の交換流量を明確にし、全体の質量収支を確認できる構成へ進めます。

17. 今回の作業で一番重要だったこと

ここまで進めて感じたのは、古い数値計算プログラムでは、コードを書き換えることよりも先に、

「変更前の計算を再現できる状態を作る」

ことが重要だということです。

今回も、もし最初からREAL*8化、河道網の全面書き換え、データ形式変更を同時に行っていたら、旧Windows版との差、コンパイラ差、修正による差を分離できなかったと思います。

現在は、

旧Windows版
    ↓
修正前gfortran REAL*4版
    ↓
Step 4 r001
    ↓
Step 4 r002 legacy mode
    ↓
Step 4 r002 graph mode

という比較経路を残しています。

さらに、

数秒で終わるNode / Reach回帰

と、

公式サンプル29400秒の全期間回帰

を分けたことで、普段の修正と配布前確認の両方を行いやすくなりました。

18. まとめ

今回行っているのは、NILIM2.0を別の水理モデルへ置き換える作業ではありません。

まず、元のプログラムを読み解き、旧Windows版とgfortran版の差を確認し、計算方法を残したまま実行・検証しやすい形へ整理しています。

現在までに行った内容をまとめると、次のようになります。

NILIM2.0の更新作業

NILIM2.0公式サンプル
↓
旧Windows版の基準結果取得
↓
gfortran REAL*4で29400秒完走
↓
SPLITSV付近の差を特定
↓
修正前gfortran基準を固定
↓
明確なコード不具合を修正
↓
同一環境で回帰確認
↓
Node / Reach接続層を追加
↓
legacy / graph modeを分離
↓
2 Node / 5 Reach短時間回帰(サンプル河道データ)
↓
Fast Regressionを正式統合

ここから先は、Nodeの質量収支をさらに厳密にし、河道網を一般化したうえで、氾濫原・下水道・水理構造物も同じ考え方で整理していく予定です。

元のNILIM2.0が持っている水理計算の蓄積を捨てずに、変更内容を追跡でき、回帰確認できる解析システムとして組み直すことが今回の目的です。

ソースファイルは現在整理中ですので、公開可能になれば、改めてアナウンスします。

参考資料