AIネイティブな仕事の作法
第7章 / Essay
第7章 № 07 · 2026

既存システムは並行稼働で
書き換える。動いたら殺す。

「壊すな・触るな」はもう古い

2026.05.02 🌐 EN

業務システムと「うまく付き合う」道は、もう要らない。

並行稼働で、書き換える。新しいシステムを AI で作って、旧と並行で動かす。出力を毎日突き合わせる。差分が消えたら、旧を殺す。

これが、AI ネイティブな仕事の作法における業務システムへの態度だ。中途半端な共存はしない。

「壊すな」「触るな」は古い助言だ

過去 20 年、業務システムを担当する人間に与えられてきた助言は、こうだ。

「壊すな」「触るな」「動いているものに手を入れるな」「既存資産を活かせ」。

これは、書き換えのコストが高すぎた時代の助言だった。書き換えに数年・数億円かかる時代には、「動いているものは触らない」が確かに正解だった。

時代が変わった。

AI が業務ロジックを Python に翻訳できる。AI が SQL の意図を Markdown で書き出せる。AI がテストデータを生成できる。AI がドキュメント無しのコードからルールを抽出できる。書き換えのコストが、10 分の 1 になった。

10 分の 1 になったコストで、まだ「触るな」と言うのは、新しい現実を無視している。残す理由は、もう無い。

並行稼働の論理

書き換えのコストが下がったとはいえ、リスクはゼロではない。新システムが旧システムと完全に同じ動きをする保証は、どんな手法でも与えられない。

そこで、並行稼働だ。

新システムを AI で作る。旧システムはそのまま動かす。同じ入力を両方に流す。出力を比較する。

flowchart LR Input["本番の入力データ"] Old["旧システム
Java/C#
Oracle/SQL Server"] New["新システム
Python + AI
PostgreSQL"] Diff{"毎日
突き合わせ"} Fix["新システムを修正
(旧は触らない)"] Kill["差分ゼロが続く
→ 旧を殺す"] Input --> Old --> Diff Input --> New --> Diff Diff -->|差分あり| Fix Fix --> New Diff -->|差分ゼロ| Kill classDef old fill:#fef3e7,stroke:#c89559,color:#5a3f1a classDef new fill:#e8f5e9,stroke:#7a9a6d,color:#3a4d34 classDef decision fill:#f0f0f0,stroke:#666 class Old old class New,Kill new class Diff,Fix decision

A と B が一致するなら、新システムは正しい。一致しないなら、どちらかが間違っている。だいたい、旧システムに 20 年前から残っていたバグが先に見つかる。ドキュメントに書かれていなかったバグ。

これを 1 ヶ月、3 ヶ月続ける。差分がゼロになり、想定外のケースもカバーされたと確認できたら、旧システムを止める。

並行稼働は、書き換えのリスクを 実測 で潰す手段だ。机上の検証ではない。仕様書のレビューではない。本番環境で、実データで、動かして確かめる。

旧システムをいつまで残すか

並行稼働の期間は、長くて 6 ヶ月、ふつう 3 ヶ月もあれば充分だ。

それ以上長く並行稼働させる必要があるなら、そもそも新システムが正しくない。新システムを直す。並行稼働を「ずっと」やってはいけない。

組織の中には「旧システムを念のため残しておく」という心理が働く。これは罠だ。残し続けると:

並行稼働は手段であって、目的ではない。新が正しいと分かったら、旧を殺す。

殺せないなら、最初から書き換えるべきではなかった。やる時はやる。

なぜ「補う」では足りないか

「既存資産を活かしつつ AI で補う」── これは、結局、旧システムが残り続けることを許容する考え方だ。

新しい機能は外側に積み上がる。中身は古いまま。担当者は二つの世界を行き来する。3 年経っても 5 年経っても、組織は AI ネイティブにならない。

並行稼働には期限がある。期限内に置き換える。中途半端な共存は、組織を硬直させる。

「補う」が許されるのは、書き換えコストが本当に高すぎた過去の話だ。今は違う。

ベンダー製品をどう殺すか

Oracle、SAP、Salesforce、Microsoft の業務製品 ── これらは「製品」を売っているのではない。「製品を使い続けないといけない状況」を売っている。

並行稼働で殺すパターン:

  1. 製品からデータを毎日エクスポートする(製品はそのまま動かす)
  2. AI で書いた新システムが、エクスポートを処理して同じ業務を回す
  3. 同じ業務指標(売上、在庫、顧客状態)を、両方で計算する
  4. 数字が一致したら、製品契約を更新しない
  5. 製品から「全データエクスポート」を最後にもらって、新システムに完全移行

契約更新時期に間に合わせる。これは戦略的なスケジュールだ。10 月に契約更新があるなら、6 月までに並行稼働を始める。3 ヶ月走らせて、9 月に意思決定。

ベンダーは「移行リスク」「データ整合性」「ベテラン担当者の引き止め」── あらゆるカードで引き止めにかかる。並行稼働で同じ出力が出ていれば、それらは全部反論できる。証拠が手元にある。

ライセンス料は年に数千万円単位だ。それを止められれば、新システムの開発コストは数ヶ月で回収できる。

業務知識を一気に Markdown に出す

並行稼働の準備として、業務知識を Markdown に出す。一気にやる。

これまでの常識では、業務知識のドキュメント化は数ヶ月から数年がかりのプロジェクトだった。担当者が空き時間に少しずつ書く。半分も書き終わらないうちに、書いた人が異動する。途中で頓挫する。結局、書かれない。

時代が変わった。

旧システムのコード、コメント、SQL、運用手順書、過去の障害報告 ── これらを 全部 Claude に渡す。「業務ロジックを抽出して Markdown で整理しろ」と頼む。数千行のコードベースなら、数時間で初版が出る。数万行でも、数日で完了する。

「このコードは何をしているか」「埋め込まれているルールは何か」── 人間が読める Markdown が、一気に手に入る。

完璧でなくていい。80% で十分。残り 20% は、並行稼働中に出力差分として現れる。差分を一つずつ潰していけば、業務知識は完成する。

数ヶ月の作業を、数日に圧縮する。これが AI の本領だ。

これが、並行稼働の隠れた効用でもある。書かれていなかった業務ルールが、並行稼働で全部炙り出される。机上で書かれた仕様書には現れない、実運用で初めて分かるルール ── これが、Claude による初版 Markdown と、並行稼働の出力差分の両方から、引き出される。

書き換えは、ドキュメント整備でもある。今週中に終える。「いつかドキュメント化する」というプロジェクトを抱えている時間は、もう無い。

業務ルールは現場にある

書き換えを誰がやるか。

これまでの常識: IT 部門、SI ベンダー、コンサルタントが、現場から仕様を聞き取って、コードを書く。書き終わったら現場が受け入れテストをする。

これは、書き換えに必要な知識が分散していた時代のかたちだ。コードを書く能力は IT 部門に、業務ルールの知識は現場に、それぞれ偏在していた。だから両者を協働させる仕組みが必要だった。

今は違う。

コードを書く能力は、Claude が持っている。残るのは業務ルールの知識だけだ。そして、業務ルールを最も深く知っているのは、毎日その業務を回している現場の人間である。

現場の人間が、Claude にコードを書かせる。これで完結する。途中の伝言ゲームが要らない。

現場がテストを書く

並行稼働で重要なのは、出力差分を見つけることだ。「新システムが旧と同じ出力を出すか」── これを判定するためのテストデータが要る。

このテストデータを作るのに、最も向いているのが現場の人間だ。

「7 月の請求は 10 日締めだが、お盆休みを考慮して翌月 5 日まで延長する」── このルールを知っている現場の人間が、Claude にこう頼む: 「7 月のお盆延長を考慮した請求テストデータを 50 件作って」。Claude が作る。実際に旧システムを通して、期待出力を生成する。これがテストデータになる。

机上の仕様書には書かれていなかったルールが、テストの形で実体化する。業務知識が、現場からテストへ、そしてコードへと流れる。

これは、IT 部門には絶対に書けないテストだ。彼らはルールを知らない。ルールを知らない者がテストを書くから、書き換えは失敗してきた。

委託は止める

ここまで来ると、結論は明白だ。

業務システムの書き換えを、IT ベンダーやコンサルタントに委託する必要は無い。

委託の伝統的な根拠は二つだった:

  1. コードを書く能力が外側にしかない
  2. 業務ルールの知識を外側に伝える必要がある

(1) は、Claude が解決した。(2) は、そもそも外に伝える必要が無くなった。現場 + Claude で完結する。

ベンダーへの委託費は、業務システム書き換えで最大のコスト項目だ。年間数千万円から数億円。これが要らなくなる。

業務ルールを知っている現場の人間が、Claude にコードを書かせ、Claude にテストを書かせ、並行稼働で実測する。書き換えは、外注するものではなく、内製で行うものに変わる。

これは IT 部門の役割の縮小ではない。IT 部門は、現場 + Claude のチームを支える基盤(インフラ、データベース、デプロイ環境、セキュリティ)を整える役割に集中できる。重複した「業務ロジックの仲介」役を抜ける。長年、業務を理解しないまま仕様書を書いては修正されていた仕事が、無くなる。

業務を知る者が、Claude を使って、自分の業務を書き換える。これが新しい現場の作法だ。

委託をやめるとは、責任を取り戻すことでもある。

SQL は残す。PL/SQL と T-SQL は捨てる

データベースは残す。しかし、ベンダー方言は捨てる。

SQL という標準言語は残す。SELECT、JOIN、GROUP BY、ウィンドウ関数 ── これらは 50 年前から動いていて、これからも 50 年動く。Claude も完全に書ける。

しかし、Oracle の PL/SQL、Microsoft SQL Server の T-SQL ── これらは捨てる。ベンダー固有の方言だ。データベースに業務ロジックを埋め込むことで、ベンダーロックインの最後の砦を作ってきた。

PostgreSQL に移行する。コストメリットが非常に大きい。

PostgreSQL はオープンソース、無料、商用利用可。機能は Oracle や SQL Server と同等以上だ。

PL/SQL のストアドプロシージャに埋め込まれた業務ロジックは、Python に書き直す。Claude に PL/SQL を渡せば、業務ルールを抽出した上で Python に翻訳して出す。業務ロジックが、不可視のストアドからコードに戻る。可読性が上がる、バージョン管理できる、テストできる。

DB と論理層を並行稼働で置き換える

論理層を Python に書き換えるのと同じ要領で、DB も並行稼働で置き換える。

  1. PostgreSQL に同じスキーマを作る(Claude が DDL の方言変換を書く)
  2. 旧 DB から PostgreSQL へデータを毎日同期する
  3. 新システム(Python)は PostgreSQL を読み書きする
  4. 旧システム(Java/C#、PL/SQL)は引き続き Oracle / SQL Server を読み書きする
  5. 出力突き合わせで両系の整合性を確認する
  6. 切り替え日を決める。PostgreSQL を本番、旧 DB を読み取り専用に
  7. 数週間の安定稼働を確認したら、旧 DB を停止する

論理層を Python にするだけでは、ベンダーロックインは半分しか抜けない。DB が Oracle のままなら、Oracle のライセンス費は払い続ける。PostgreSQL への移行は、ロックインから抜ける最後のステップだ。

そして、ライセンス費の年間コストが、新システムの開発費を数ヶ月で回収する。財務的にも、書き換えない理由が無い。

Oracle / SQL Server を捨てる。これがベンダーロックインからの卒業証書だ。

ベンダーロックインから抜ける方法は、いつも同じ

ここまで見てきた話は、すべて同じ構造だ。

これらは別々の問題ではない。同じ手で全部抜ける。

並行稼働で書き換える。

旧を止めない。新を並行で作る。同じ入力を両方に流し、出力を突き合わせる。差分が消えたら、旧を殺す。契約更新の時期に間に合わせる。

ロックインは、「触れない・抜けられない」と思わせる心理的な装置だ。並行稼働は、その心理を物理的に解除する。触らずに、横に新しい本流を作る。新が動けば、旧が要らないことが誰の目にも明らかになる。

ベンダーロックインから抜ける方法は、すべて同じ。並行稼働で書き換える。

これは業務システムだけの話ではない。Office、Microsoft 365、Google Workspace、CRM ── ベンダーが「これ無しではあなたの業務は止まる」と主張するすべての領域で、同じ手が使える。

例: 月次決算処理

例えば、月末に動く決算処理バッチ。

旧: COBOL や Java で書かれた、5 年前から動いているバッチ。中身は誰も完全には理解していない。月末に動く。失敗すると経理が止まる。

並行稼働の手順:

第一週: 旧バッチの入力(前月の取引データ)と出力(決算サマリ)を 12 ヶ月分エクスポートする。これを正解データとする。

第二週: Claude に旧コードと運用ドキュメントを渡し、Python で同等処理を書かせる。12 ヶ月分のデータを流し、出力が正解と一致するか確認する。一致しないところを潰す。

第三週〜第六週: 旧システムが動く本番タイミングで、同じ入力を新システムにも流す。毎月、出力を突き合わせる。差分があれば原因を特定して修正。

第三月: 差分がゼロの月が連続したら、責任者が決断する。「来月から新システムで運用」。旧バッチは止める。

3 ヶ月で書き換え完了。担当者の負担は、並行稼働中だけ二重になるが、それが終わると半減する。そして、業務ロジックがコードと Markdown の両方で読める状態になる。これは大きい。

例: SAP の出荷管理を抜ける

別の例。中規模製造業の出荷管理を SAP で動かしている会社。ライセンス 年額 数千万円。

並行稼働の組み立て:

  1. データ層:SAP から夜間バッチで出荷データを Parquet に エクスポート(第4章)── SAP は触らない、読み取りのみ
  2. 新ロジック層:Polars + DuckDB で在庫照合・出荷判定・運送業者 の振分けを Python で書く(Claude が現場ヒアリングと既存 SAP の 設定画面のスクショから初版を生成)
  3. 画面層:現場用の出荷指示画面は FastAPI + HTML(第7章、社内 LAN だけで動かすので Forgejo の miniPC でホスト可)
  4. 突き合わせ:毎日、SAP の出荷結果と新システムの出荷結果を 比較。差分があれば原因を Claude と一緒に追う。ほぼ毎週、SAP 側に「実は文書化されていなかったルール」が見つかる
  5. 3 ヶ月後:差分ゼロが 2 週間続いたら、新システムを本番に 昇格、SAP は 来年度の契約更新前に止める

結果:

これは第5章の「Office から離れる」の 基幹システム版 だ。 「Office を捨てない、CSV だけ捨てる」と同じ構造で、「SAP を一度に 捨てない、並行稼働で殺す」。

「動いているものに触るな」と言う人へ

組織には、書き換えに反対する人がいる。彼らの言い分は、ほぼ一つに集約される: 「動いているものに触ったら、止まるかもしれない」。

並行稼働は、この言い分への回答だ。触っていない。旧システムは並行稼働中も動き続ける。新システムが旧と同じ出力を出すことを、毎日実測で確認する。

差分が出る日があったら、その日のうちに原因を特定する。新システムを直す。旧システムは触らない。旧システムは、新システムが正しいことの基準として、動かし続ける。

並行稼働期間が終わったら、新システムが旧と完全に同じ振る舞いをしていることが、3 ヶ月分の実測データで証明されている。この時点で旧を止めるリスクは、最初に書き換えに反対していた人が想定するリスクより、はるかに小さい。

「動いているものに触るな」と言い続ける人は、データを示せない。並行稼働を提案する側は、毎日データを示す。議論が事実に着地する。

実例: 数字で見る

PL/SQL 5,000 行の業務ロジックを Python に翻訳、SI ベンダーの外注見積もり: 約 3,000 万円。現場担当者が Claude で書き換え、開発期間 1 ヶ月、人件費約 100 万円。30 分の 1。

Oracle Enterprise Edition のライセンス: 20 CPU で年間約 4,000 万円 + 保守料 22%。PostgreSQL に移行で年間ゼロ円。新システム開発費を 1 ヶ月で回収。

並行稼働 3 ヶ月で発見した未文書化の業務ルール: 1 つの業務システムで平均 20〜50 件。机上の仕様書では一つも見えなかったルールが、出力差分として全部炙り出される。

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

まとめ

業務システムと「うまく付き合う」のは、もう古い。

並行稼働で、書き換える。新システムを AI で作って、旧と並行で動かす。出力を実測で突き合わせる。差分が消えたら、旧を殺す。

やる時はやる。中途半端な共存は、組織を硬直させる。AI で書き換えのコストが 10 分の 1 になった時代に、残す理由は無い。

次の章では、Web を作る話に進む。「React は要らない。HTML と CSS と JavaScript で十分だ」── 原点回帰のはなし。

関連記事

実例

再現可能なソース・コマンド・実測結果を、別ページにまとめてある。