AI で古いシステムから業務ルールを抽出するには？

古いシステムの業務ルールは 3 つのステップで抽出します。AI がコードを読み、各ルールを元のコード行と結び付けた明確な文章にする。プロセスの責任者がそれを見直し、承認または修正する。そして実際の請求書で、システムが実際に行っている処理と照らし合わせる。メインフレーム向け AWS Transform のようなツールはルールをレビュー可能な要件として書き出し、Thought Machine と Amazon が 2026 年 9 月 29 日に発表した内容 では、抽出は人による承認で終わる 4 つの段階を経ます。ルールが確認されるまで、新しいコードは書かないでください。

第 3 回 では、各システムの棚卸しと暫定的な判断をまとめました。再構築や変換を決めたシステムこそ、最初にこのステップが必要です。

業務ルールが古いシステムで最も価値のある部分である理由

業務ルールとは、会社が何かを計算したり判断したりする方法です。卸売顧客の割引をどう計算するか、いつ延滞金を加算するか、一定額を超える発注を誰が承認するか、分割払いの金額をどう端数処理するか。こうしたルールは長年の変更の中で積み重なり、その多くはどの文書にも書かれていません。

• コードの中：すでに退職した管理職の依頼で、何年も前にプログラマーが書いた条件や計算。
• データベースの中：何がそれに依存しているかを知らないまま誰かが手で書き換える価格表、料率、限度額。
• 社員の頭の中：システムが処理しないため、経理担当者が手作業で処理している例外。
• 表計算ファイルの中：システムの不足を補う数式。これについては どのシートが本当のシステムか で説明しました。

これらのルールなしでシステムを再構築すると、計算方法の違う新しいシステムができあがり、顧客が請求書に異議を唱えたときに初めて気づくことになります。移すべきなのはルールであり、古いプログラミング言語は入れ物にすぎません。

AI はどのようにコードを読み、ルールを書き出すのか

ルールの抽出はかつて長い手作業でした。プログラマーがコードを 1 行ずつ読み、理解したことを書き留めていたのです。今のツールはコード全体を読み、すべての数値がどこから来てどこへ行くのかを追跡し、見つけたことをわかりやすい言葉で書き出します。一例として、Amazon は メインフレーム向け AWS Transform のページ で、このサービスがソースコードからすべての業務ルールを抽出して出どころまで追跡し、チームがレビューできる開発用の要件を生成し、各要件は元のコードまでたどれると説明しています。これは Amazon による自社サービスの説明であり、保証された結果ではありません。

ルールをどの形式で書くかは重要です。よく知られた形式の一つが EARS（Easy Approach to Requirements Syntax）で、Alistair Mavin 氏とロールス・ロイスの同僚が開発し、2009 年に初めて公開されました。考え方は、すべてのルールを決まった順序で書くことです。まず状態、次にきっかけ、最後にシステムが行うべきこと。5 つの基本パターンがあり、以下は業務での例です。

この形式の価値は、プロセスの責任者がプログラミングを知らなくても読んで判断できることです。ルール 1 つにつき 1 文で、答えは「はい」「いいえ」「不完全」のいずれかです。

銀行の事例：1 行ずつの翻訳ではなく、業務の意図を抽出する

最近の最もわかりやすい例は銀行業界です。利息、手数料、返済のルールが、何十年もメインフレーム上の COBOL コードの中にあります。COBOL は古いプログラミング言語で、今も銀行や保険の多くのシステムを動かしています。銀行向けテクノロジー企業の Thought Machine は 2026 年 9 月 29 日の発表 で、コードを 1 行ずつ翻訳するのではなく、純粋な業務の意図を抽出する仕組みを Amazon と共に進めていると述べました。発表によると、この仕組みは 4 つの段階で構成されます。

1. 抽出：AWS Transform がレガシーアプリケーションを読み、業務ロジックを EARS 形式で書かれた仕様として抽出する。
2. 統合：同じ商品の何百もの重複したバリエーションを、簡潔で現代的な仕様にまとめる。
3. 生成：AI エージェントが金融商品とそのテストを Python で生成する。
4. 検証：人によるレビューで、銀行のエンジニアリングチームとリスクチームが明確な承認権限を持つ。

ここには 2 つの教訓があります。統合の段階は、古いシステムが同じルールの複製を数多く抱えていることを示しており、最後の段階は完全に人が担います。これは 2 社が自社の仕組みについて述べている内容で、事例も銀行のものですが、方法そのものはどの会社にも当てはまります。抽出し、重複をまとめ、それから構築する。そして意思決定者が承認するまで何も確定させないことです。

プロセスの責任者がすべてのルールを確認しなければならない理由

AI が読むのはコードが何をしているかであって、会社が何を望んでいるかではありません。この 2 つのずれこそ、モダナイゼーションの失敗が起こる場所です。

• 使われていないコード：何年も使われていない部分からルールを抽出し、現役のルールのように見せてしまうことがあります。
• 習慣になった古いバグ：システムが金額を誤った方法で端数処理し、社員が手で直している。誰かがバグだと指摘しない限り、抽出されたルールはそのバグも引き継ぎます。
• コードの外にあるルール：経理担当者が手作業で処理している例外は、抽出結果には決して現れません。
• 矛盾するルール：2 か所に割引計算の 2 つのバージョンがある。どちらが正しいかは技術ではなく業務の判断です。

そのため、各ルールに承認者となる業務側の責任者を決めてください。割引ルールは営業部長、延滞金や承認は財務部長です。確認済みのルールは新システムの要件定義書の土台になります。その書き方は ソフトウェア要件の書き方ガイド で説明しました。また、コードやデータベースには顧客や社員のデータが含まれている可能性があるため、王国外でそれらを読み取るツールには、第 3 回で取り上げた確認と サウジデータ・人工知能庁（SDAIA）の指針 の確認が必要です。

Origami の視点

古いシステムをモダナイズするとき、私たちが最も大切に移すものはコードではなく業務ルールです。AI ツールを使ってコードを読み、以前は不可能だった速さでルールを明確な文章にしますが、プロセスの責任者が読んで承認するまで、どのルールも確定とはみなしません。

そのうえで、確認済みの各ルールを古いシステムの実データでテストしてから、その周りに新しいシステムを構築します。新しいシステムがツールの推測ではなく、会社の期待どおりに計算するようにするためです。私たちの進め方を知りたい方は、サービス紹介 をご覧ください。

今週の練習：1 つのルールと 3 枚の請求書

始めるのにツールを待つ必要はありません。割引や延滞金など、よく議論になるルールを 1 つ選び、次の手順で進めます。

1. プロセスの責任者に、そのルールを「…のとき、システムは…しなければならない」という形で 1 文に書いてもらう。
2. そのルールが適用された実際の請求書 3 枚をシステムから取り出す。通常のもの、境界値のもの、例外を含むもの。
3. 書かれた文を使って各請求書を手計算し、システムの出力結果と比べる。

3 枚とも一致すれば、そのルールは文書化できたことになります。1 枚でも違えば、隠れたルールか古いバグを見つけたということで、それこそがモダナイゼーションの前に知っておくべきことです。

次回

これでシステムの確認済みルールがそろいました。次は大きな判断です。システムをそのまま移すのか、コードを最新のプラットフォームに変換するのか、抽出したルールを軸に再構築するのか、それとも既製品に置き換えてデータだけを残すのか。第 5 回では、これらの道を表で比較します。それぞれがどんな場合に合うのか、何を残し、何がリスクになり、誰が関わるべきかを見ていきます。

出典

• メインフレーム向け AWS Transform：公式ページ — 元のコードまで追跡できる業務ルールの抽出、レビュー可能な要件、同等性テスト。
• Thought Machine と AWS：2026 年 9 月 29 日の発表 — 4 つの段階：EARS による抽出、統合、生成、人による検証。
• EARS：Alistair Mavin 氏による公式ガイド — 形式、5 つのパターン、2009 年の初公開。
• SDAIA：個人データ保護。