AIネイティブな仕事の作法
第7章 · 実例 2
実例 2 · 第7章: 業務システムと付き合う ── 並行稼働で書き換える

既存 Java / C# コードから業務ルールを Markdown に抽出

第 06 章「業務システムと付き合う ── 並行稼働で書き換える」の 2 番目の角度: 既存システムには業務知識が埋まっている。それを少しずつ Markdown に出していく。

章のどの主張に対応するか

業務知識を Markdown 化する作業: 担当者の空き時間でやると 6 ヶ月〜1 年。 Claude に全コードベースを渡して一気にやれば、1 週間で 80%。

(章本文「実例: 数字で見る」より)

example-1 が「PL/SQL → Python 並行稼働」、これは その前段: コードに散らばっている業務ルールを機械的に抽出して Markdown にする。

やること

  1. 入力: legacy/(Java + C# のサンプル業務コード)
  2. 抽出: extract_rules.py が:
    • final / const / static readonly の 定数定義(閾値・税率)
    • 直前の 行コメント(業務上の意味)
    • JavaDoc / DocString ブロック(仕様の概要) を集めて Markdown のテーブルに整理
  3. 出力: out/RULES.md(後で Claude に補完してもらう叩き台)

構成

example-2/
├── README.md
├── legacy/
│   ├── OrderService.java     ── 注文処理ロジック(送料・割引・税)
│   └── PaymentService.cs     ── 決済処理ロジック(上限・手数料・再試行)
├── extract_rules.py          ── 機械抽出(正規表現で定数 + コメント)
├── Makefile
├── results.md
└── out/
    └── RULES.md              ── 抽出結果

実行

make clean && make all

抽出は 数 ms で完了(正規表現だけ、外部依存ゼロ)。

なぜこれが「実例」になるのか

業務システムを書き換えるとき、最大の壁は 「ルールがどこにも書いていない」 こと。

そこで、コードを Markdown に翻訳する 工程が要る。これは Claude に 丸投げできるが、まず機械で取れる部分(定数・JavaDoc)だけ集めて 叩き台を作る のが速い。

このスクリプトの役割:

  1. 定数を全部抜き出す(SHIPPING_REMOTE = 1500 のような)
  2. 直前の行コメント(業務上の意味)を紐付ける
  3. JavaDoc を取り出して仕様の概要を確保

これが叩き台。次は Claude に「legacy/ 一式と out/RULES.md を見て、 コメントに無い暗黙ルールも書き起こして」と頼む。これで章本文が言う 「1 週間で 80%」に近づく。

人間は 判断と確認 だけに集中できる。

出力サンプル(out/RULES.md 抜粋)

## OrderService.java から抽出

| 名前 | 値 | 業務上の意味 |
|------|-----|------------|
| SHIPPING_REMOTE | 1500 | 送料は離島が高い ── 北海道・沖縄は 1500 円 |
| SHIPPING_FREE_THRESHOLD | 10000 | 小計が 10,000 円以上で送料無料 |
| MEMBER_DISCOUNT_RATE | 0.05 | 会員割引: 5% |
| BULK_DISCOUNT_THRESHOLD | 30000 | 大口割引(会員割引後 30,000 円以上) |
| TAX_RATE | 0.10 | 消費税率(2026 年現在 10%) |

### JavaDoc からの仕様

> 注文の請求書を計算する。
> 業務ルール:
>   1. 小計 = 数量 × 単価
>   2. 送料 (北海道・沖縄/その他、10000 円以上で無料)
>   3. 会員割引 (5%, 切り捨て)
>   ...

これは 誰でも読める仕様書 になる。新メンバーが Java を読めなくても 業務ルールが追える。これが章で言う「業務知識を Markdown に出していく」の 最小実演。

計測結果 — 第 06 章 example-2

実行環境: Linux 6.18 / Python 3.x(標準ライブラリのみ)

抽出結果(主目的)

=== 業務ルール抽出 ===
  処理ファイル : 2 個 (.java + .cs)
  抽出した定数 : 13 個
  抽出時間     : <1 ms

抽出された定数の例

OrderService.java から:

定数名 値 業務上の意味
SHIPPING_REMOTE 1500 北海道・沖縄の送料
SHIPPING_NORMAL 800 それ以外の送料
SHIPPING_FREE_THRESHOLD 10000 送料無料の境界
MEMBER_DISCOUNT_RATE 0.05 会員割引 5%
BULK_DISCOUNT_THRESHOLD 30000 大口割引の境界
BULK_DISCOUNT_RATE 0.03 大口割引 3%
TAX_RATE 0.10 消費税率

PaymentService.cs から:

定数名 値 業務上の意味
FAILURE_THRESHOLD 3 24 時間以内 3 回失敗で要確認
FAILURE_WINDOW_HOURS 24 失敗判定の窓
SINGLE_PAYMENT_LIMIT 500,000 単発決済上限
MONTHLY_LIMIT_B2B 5,000,000 月次上限(B2B)
MONTHLY_LIMIT_RETAIL 1,000,000 月次上限(個人)
RETRY_INTERVAL_MINUTES 15 再試行間隔
MAX_RETRIES 3 最大再試行回数
FEE_RATE 0.036 決済手数料率
FEE_FIXED 30 決済手数料固定額

機械抽出の限界

このスクリプトが取れるのは コードに書かれているもの だけ:

取れる 取れない
定数の名前と値 なぜその値なのか
直前の行コメント コメントに書かれていない暗黙の前提
JavaDoc / DocString 「実は障害対応で別ルートがある」みたいな運用知
関数のシグネチャ 過去のリリースで変わった仕様の経緯

なので、機械抽出 → Claude に補完依頼 → 担当者ヒアリングで確定 という 3 段階になる。

章本文との対応

担当者の空き時間でやると 6 ヶ月〜1 年。Claude に全コードベースを 渡して一気にやれば、1 週間で 80%。

このフォルダは 6 ヶ月→数 ms の機械抽出層を実演する。実プロジェクトでは:

  1. このスクリプトで定数と JavaDoc を抽出(数秒)
  2. Claude に legacy/ 全体を渡して暗黙ルールも書き起こし(数時間)
  3. 担当者と読み合わせ(数日)

合計 1 週間で 80% に到達する道筋。

来月の運用

新しいコードが入ったら:

make all  # → out/RULES.md を再生成
git diff out/RULES.md  # 何が増えたかレビュー

新規ルールが入ると Markdown に表として現れるので、レビューで気づく。 「いつの間にか追加された定数」を見逃さない。

再現手順

# 標準ライブラリだけで動く
make clean && make all

ファイル一覧

out/

← 第7章「業務システムと付き合う ── 並行稼働で書き換える」に戻る