生成AIは純粋置換モダナイの費用をどこまで下げられるのか#
生成AIを開発にどう活用するか、という話はよく聞く。
ただ、その入口にはいつも少し引っかかりがある。 「生成AIがすごい」という言葉は多いのに、 何が一次情報で、何が期待で、何が実務上の制約なのかが見えにくい。
今回のセッションでは、最初は生成AIを活用した開発方法論を整理しようとしていた。 Eval 駆動、Spec-first、Context Engineering など、 有力そうな言葉はいくつも出てくる。
しかし、話しているうちに関心は少しずつ別の問いへ移っていった。
生成AIは、レガシーシステムのモダナイに対して、 これまで費用対効果が合わなかった「純粋置換」を現実的にするのだろうか。
ここでいう純粋置換#
モダナイという言葉は広い。
実際の現場では、言語の置き換えだけでなく、 システム統廃合、運用ルール変更、業務プロセス見直し、UI 改善などを含むことが多い。 その場合、投資価値は説明しやすくなる。 古いものを新しくするだけでなく、業務価値も変えるからである。
一方で、今回考えたのはもっと狭い前提だった。
システムのスコープは変えない
外部環境も変えない
画面、ロジック、タイミングを可能な限り同じにする
潜在バグや暗黙ルールも含めて移植する
COBOL などで動いていたものを、別言語へ置き換える
つまり、業務改善を主目的にしない。 「同じものを、別の技術基盤で動かす」ことに徹する。
この前提を置くと、よくあるモダナイの説明は少し弱くなる。
たとえば、外部連携先が変わるから難しい、運用ルールが変わるから難しい、 という話は、今回の前提ではいったん脇に置く。 外部環境は変えないことにするし、運用もできるだけ同じにする。
すると問いは、かなり素朴になる。
これまで「お金をかける価値が見いだしにくい」とされてきた純粋置換は、 生成AIによって安くできるのではないか。
生成AIが効きそうなところ#
この問いに対して、まず期待できる部分はある。
生成AIは、コード変換そのものにはかなり効きそうである。 古いコードを読み、別言語の実装案を出し、 周辺のテスト雛形やドキュメントを作る。 差分が出たときに、原因候補を整理することもできる。
人間が一つずつ読み替えていた作業を、 AI が下書きし、人間が確認する形に変えられるなら、 変換工程の費用は大きく下がる可能性がある。
ここまでは、かなり前向きに見てよいと思う。
ただし、そこで「では純粋置換は簡単になった」とは言えない。 セッションで繰り返し出てきたのは、 作ることと、同じであると説明することは別だという点だった。
最後に残るのは同値性検証#
純粋置換で難しいのは、正しい新システムを作ることではない。 旧システムと同じように正しく、同じように間違うことを確認することである。
たとえば、桁あふれ、丸め、文字コード、初期値、ソート順、NULL の扱い、 日付境界、バッチの実行順、例外時の戻り値などは、 言語や実行基盤を変えると微妙にずれることがある。
通常の新規開発なら、そのずれを「新しい仕様」として整理できるかもしれない。 しかし純粋置換では、ずれ自体が問題になる。 古い挙動が業務上の前提になっているなら、 たとえそれが美しくない挙動でも互換対象になる。
ここで効いてくるのが、同値性検証である。
旧システムと新システムに同じ入力を与え、 出力、ログ、副作用、状態遷移を比較する。 過去データやゴールデンデータを使い、 差分が出たら原因を調べる。 必要なら差分を許容するのか、旧挙動に寄せるのかを決める。
生成AIは、この差分分析を助けられる。 テストケースを増やしたり、差分の分類をしたり、 怪しい変換箇所を指摘したりできる。
それでも、最終的に「この範囲で同じとみなす」と決めるのは人間側である。 ここは AI が代わりに責任を取れる場所ではない。
「再現できない」より「再現できたと言い切れない」#
今回の対話で、自分の理解が少し変わったのはここだった。
最初は、モダナイを阻むものとして、 タイミング依存、人間依存、外部依存、暗黙ルールのような例が挙がった。 しかし、純粋置換という前提を強く置くなら、 それらは「移植対象に含めればよい」と考えることもできる。
直列実行が必要なら、その仕組みも移す。 潜在バグがあるなら、それも前提に含める。 画面外の運用があるなら、外部環境は変えない。 連携先も変わらないものとして考える。
そうすると、「再現できないから無理」という説明は弱くなる。
むしろ問題は、 再現できたことをどこまで証明できるのか、 その証明にどれだけ費用がかかるのか、 そして誰がその説明責任を引き受けるのか、である。
生成AIが登場したことで、 純粋置換の変換費用は下がるかもしれない。 だが、検証責任まで自動的に消えるわけではない。
この整理のほうが、いまの自分にはしっくりくる。
開発方法論として見ると何が残るか#
この話は、生成AI活用の一般的な方法論にもつながる。
Eval 駆動や Spec-first が重要と言われるのは、 AI による生成が強力になったからこそ、 何を合格とみなすかを先に決める必要があるからである。
純粋置換モダナイでいえば、Spec-first は新仕様を書くことだけではない。 むしろ、互換性の判定条件を書くことになる。
どの入出力を比較するのか
どの副作用を比較するのか
どの差分を許容しないのか
どの差分は仕様更新として扱うのか
どの時点で受け入れ可能と判断するのか
この条件がないまま AI に変換させると、 コードは早く出てくる。 しかし、成功したかどうかを判断できない。
速度を上げるほど、判定基準の弱さが後で効いてくる。 ここに生成AI活用の怖さがある。
現時点での整理#
今回のセッションを通して、現時点では次のように考えている。
生成AIは、純粋置換モダナイの可能性を広げる。 特に、コード変換、テスト雛形、差分分析、ドキュメント化の費用は下げられる。
一方で、生成AIは「同じであることの説明責任」を消してくれない。 純粋置換で最後に重く残るのは、 変換作業そのものではなく、 同値性検証、受入ゲート、責任分界である。
だから、生成AIは銀の弾というより、強力な圧縮機に近い。 作業を圧縮し、検証の材料を増やし、 人間が判断する場所を見えやすくする。
ただし、何を同じとみなすかを決めないままでは、 その力はかえって危うい。
次に考えるなら、純粋置換専用のチェックリストを作りたい。
互換性の判定項目
ゴールデンデータの作り方
差分の分類ルール
受入ゲート
経営向けの費用対効果説明
生成AI時代のモダナイは、 「AI が変換できるか」だけでは判断できない。
本当に問うべきなのは、 AI を使って、どこまで検証可能性を高められるかである。
記事情報
- 著者:
mtakagishi
- 公開日:
2026-06-21