旧システムのAI移行はなぜ失敗する？1,141行の憲法とSQLite・Rust検問の12段階実証録

旧システムのAI移行が失敗する真因と初期の泥沼

企業の基幹システム移行（レガシー・モダナイゼーション）は、従来から 70〜 80% 近くが予算超過や中断に陥ると言われる難工事です。そこに生成 AI が登場したことで「古いコードを AI に読ませて Java や Python へ自動翻訳させれば一気に片付く」という期待が広がりましたが、現場からは「コンパイルは通るのに本番データを入れると計算が合わない」「修正指示を出すほどスパゲティ化する」という失敗報告が噴出しています。

なぜ最先端の AI を使っても失敗するのでしょうか。それは、世間の失敗プロジェクトの大半が、かつて当サイトの運用初期に私自身が踏み抜いた 「情報不足のまま一括変換させる罠」 とまったく同じ穴に落ちているからです。

人間には通じる短い指示がAIを暴走させる理由

人間同士で仕事をお願いするとき、私たちは無意識のうちに膨大な「現場の常識（暗黙知）」で行間を補っています。たとえばベテランの担当者同士なら、「この帳票の消費税計算を新様式に合わせて直しておいて（既存の端数処理や過去データの互換性は当然守ってね）」と括弧の中を言わなくても通じます。

しかし、長年稼働してきた COBOL、PowerBuilder、Delphi、Visual Basic、C++、あるいは共有 Access や古い PHP で組まれた業務システムには、「紙の仕様書には一行も書かれていないが、現場のコードの隅々にだけ刻まれている例外ルール」 が何百個も眠っています。COBOL で同じメモリ番地をフラグひとつで別のデータ型として読み替える REDEFINES 句や、1 円未満の端数を丸める 10 進パック演算、あるいは特定の取引先コードのときだけ発動する分岐などはその典型です。

この「暗黙の前提」を言語化しないまま、AI に「この旧コードを最新の言語へ綺麗に書き換えて」と短い指示だけを投げるとどうなるでしょうか。AI は表面上の構文（Syntax）は驚くほど綺麗に翻訳しますが、書かれていない業務上の制約（Semantics）は「不要な古い記述」とみなして勝手に削ぎ落としてしまいます。

人間なら「そこは触っちゃいけん場所じゃろ！」って空気で分かるんじゃけど、AI は言われとらんことは 1 ミリも忖度してくれんけん、平気で大黒柱を抜いてリフォームしてしまうんよね。

まさにそこが最大の落とし穴なんです。AI が無能なのではなく、「人間の頭の中にだけあった境界条件が AI に渡っていない（情報不足）」 のが失敗の出発点なんですね。

Python一括置換で1箇所直すごとに壊れた失敗談

偉そうなことを書いていますが、当サイトでも最初からうまくいっていたわけではありません。運用を始めた初期のころは、まさにこの「情報不足」で大失敗を繰り返していました。

当時も AI に守らせるルールファイル（憲法）自体は作っていましたが、まだ数十行〜百数十行程度の短いものでした。「見出しは短く」「太字の前後には半角スペースを入れる」「既存の文章は勝手に消さない」といった、人間が読めば十分に意図が通じるレベルの箇条書き だったのです。

その状態で複数記事の修正を AI に依頼すると、AI は決まって「効率よく直そう」と判断し、その場で即席の Python スクリプトを書いて正規表現による一括置換を走らせていました。ところが、これが底なしの泥沼でした。

世間で「旧システムを AI にやらせたら失敗した」と嘆いている現場で起きているのも、規模こそ違えどこれとまったく同じ現象です。設計図（憲法）の解像度が圧倒的に足りないまま、AI に一括変換スクリプトや大量のコード生成を走らせれば、破綻するのは当たり前だったのです。

失敗を資産に変えた12段階のAI開発進化プロセス

では、その Python 一括置換の泥沼からどうやって抜け出し、550 本を超える記事とシステム群を無事故・数ミリ秒検問で回せるようになったのか。振り返ってみると、そこには 1 つずつボトルネックを潰していった「12 段階の明確な進化プロセス」 がありました。

この ①〜⑫ の各工程で「何に気づき、どう変えたのか」を順番に辿ってみましょう。

反復修正から1,141行の憲法が生まれるまで

最初の転換点は、不具合が出たときに「その場しのぎの手直し」で終わらせるのをやめたことでした（工程 ①〜④）。

最初から 1,000 行を超える仕様書を書ける人間などいません。しかし、実戦で起きた失敗を 1 件残らず条文化していった結果、当サイトの運用憲法（GEMINI.md）は最終的に 1,141 行 に到達しました。ここまで例外なく言語化して初めて、AI は人間の意図通りに一発で動くようになったのです。

AIの思考を覗いて見つけた全文検索の無駄とDB化

憲法が固まって品質が安定した次に立ちはだかったのが、「とにかく AI の処理が遅い」 という第 2 の壁でした。そこで実行したのが 工程 ⑤〜⑧ です。

AI の頭の中を覗いてみたら、難しいことを考えて悩んでるんじゃなくて、書類棚を端から 1 枚ずつひっくり返して探し物をしてただけだったのね！それは遅くなるはずだわ。

そうなんです。旧システムの移行でもまったく同じで、何百本もあるプログラムやテーブル定義を毎回 grep で手探りさせていたら日が暮れてしまいます。先に 「どこに何があるかの索引 DB」 を作って渡すだけで、AI の足取りは見違えるほど軽くなります。

憲法丸読みのクォータ浪費を断つRust検問所

ところが、SQLite 導入でスピードが上がったにもかかわらず、まだ解決しない深刻な問題が 1 つ残っていました。それが 工程 ⑨〜⑫ で挑んだ 「クォータ（利用枠）の激しい消費」 です。

実際に運用を切り替えた効果は絶大でした。以下の比較表の通り、「品質を上げるほどルールが増えて AI が重くなる」というジレンマを、ルールそのものを Rust の機械語バイナリへ変換して PC 側へ下ろすこと で完全に打ち破ることができたのです。

RAMディスク常駐と0.5秒自己再ビルドの裏側

ここで、同じように Mac やローカル PC の RAM ディスクを活用している方なら、きっと 1 つの疑問が浮かぶはずです。

「その gemini-gate の実行バイナリは RAM ディスク上のどこに展開されているのか？ そして Mac を再起動して RAM ディスクが作り直されたら、自動で複製（コピー）しているのか？」 という点です。ここにも、保守の手間と内蔵 SSD（記憶装置）の寿命を徹底的に守るための工夫を仕込んでいます。

展開先はRAM上の専用領域で単体4ミリ秒の爆速検問

まず展開場所ですが、当サイトの母艦（iMac 27 インチ 2020 年モデル / メモリ 64GB）では、64GB メモリのうち 16GB を切り出した高速 RAM ディスク上の専用ディレクトリに配置しています。

• RAM ディスク上の実体パス : /Volumes/RAMDisk/$USER/tmp/gemini-gate-bin/gemini-gate
• 未マウント・隔離環境時の自動退避先 : /tmp/gemini-gate-$USER/gemini-gate
• コンパイル済みバイナリ容量 : 約 979KB（1MB 未満）

外部パッケージ（サードパーティ製クレート）を一切使わず、Rust の標準ライブラリ（std）だけで 7,756 行を組んでいるため、出来上がるネイティブ機械語バイナリはわずか 979KB しかありません。AI がファイルを保存した直後のフックやデプロイ前検問では、メモリ上に置かれたこの軽量バイナリを exec でオーバーヘッド 0 ミリ秒で直接起動するため、単体記事の検査なら 約 4 ミリ秒、全 550 記事超のリンク網・画像サイズ・システム設定ロックの一括監査でも 12 スレッド並列で 約 150 ミリ秒 で駆け抜けます。

再起動時は複製せずソースから0.5秒で自動錬成

では、Mac を再起動して揮発性の RAM ディスクが真っ白に作り直されたときはどうしているのか。

実は、ログイン時に RAM ディスクを作成するスクリプト（create_ramdisk.sh）の側では、/Volumes/RAMDisk/$USER/tmp という空の作業フォルダを作るだけで、内蔵 SSD からのバイナリ複製（バックアップ復元）はあえて一切行っていません。

その代わり、起動ラッパーである scripts/run_gemini_gate.sh（約 70 行）が呼ばれた瞬間に、「RAM ディスク上にバイナリが無ければ（または .rs ソースコードが 1 秒でも新しければ）、その場で Git 管理下のソースから直接 RAM ディスクへ約 0.5 秒で自動再コンパイルする」 というオンデマンド自己錬成方式を採っています。

# scripts/run_gemini_gate.sh の自動検知＆アトミック再ビルド中核部（抜粋）
RAM_USER_DIR="/Volumes/RAMDisk/${USER:-$(id -un)}"
GATE_DIR="$RAM_USER_DIR/tmp/gemini-gate-bin"
mkdir -p "$GATE_DIR"
export TMPDIR="$RAM_USER_DIR/tmp"

BIN="$GATE_DIR/gemini-gate"
NEED_BUILD=0

# ① RAMDisk作り直し直後（バイナリ不在） または ② .rsソース更新時のみ再ビルド
if [ ! -x "$BIN" ]; then
    NEED_BUILD=1
else
    for rs_file in "$PROJECT_ROOT/tools/gemini-gate/src"/*.rs; do
        if [ "$rs_file" -nt "$BIN" ]; then
            NEED_BUILD=1
            break
        fi
    done
fi

if [ "$NEED_BUILD" -eq 1 ]; then
    TMP_BIN="$BIN.tmp.$$"
    rustc --edition 2021 -O -C strip=symbols -A linker_messages \
        "$PROJECT_ROOT/tools/gemini-gate/src/main.rs" -o "$TMP_BIN"
    chmod +x "$TMP_BIN"
    mv -f "$TMP_BIN" "$BIN"
fi

exec "$BIN" --project-root "$PROJECT_ROOT" "$@"

なるほどなぁ！わざわざ SSD にバイナリの控えを置いて毎回コピーする仕組みを作らんでも、外部パッケージなしの素の Rust じゃけん、最初の一発目に 0.5 秒でコンパイルし直せば済むんか！これならソースを直したのに古いバイナリが動くミスも絶対に起きんね。

起動スクリプトを増やしすぎないのが、長生きするシステムの秘訣でちぃ。

旧システム移行でゴミを生まない泥臭い憲法鍛造法

この 12 段階のプロセスは、ブログ運営に限らず、今まさに企業や現場で難航している 旧システムの AI モダナイゼーションや業務アプリ開発 にそのまま応用できます。ここで絶対に勘違いしてはいけない大前提があります。

適当な仕様書以上のものはAIにも絶対に作れない

旧システムの AI 移行で失敗した現場の多くは、「AI が勝手に仕様を変えてしまった」「AI に作らせたら使い物にならないゴミしか出てこなかった」と AI 側を責めます。

しかし、はっきり言ってしまえば 「いま手元にある仕様書以上のことは、どれほど優秀な AI にも絶対にできない」 のです。AI の立場から見れば、「長年メンテもされていない穴だらけの適当な仕様書しか渡されていないのに、それより良いシステムができるわけないじゃん！」というのが偽らざる事実です。人間は泥臭い仕様整理をサボって「AI が勝手に好き勝手なコードを書いた」と怒りますが、実際には仕様書の空白（書かれていない隙）を AI が確率で埋めた結果にすぎません。ゴミしか生まれないのは AI のせいではなく、人間の努力が間違った方向へ向かっているから です。

たしかに、材料がスカスカのレシピを渡しておいて「なんで一流レストランの味にならんのじゃ！」って怒っとるようなもんじゃけぇね……。AI からしたらいい迷惑よなぁ。

本当にその通りなんです！だからこそ、人間が汗をかくべき場所は「自分でコードを手書きすること」ではなく、「AI が迷いようのない網羅された憲法（仕様書）を泥臭く鍛え上げること」 にあります。

壁打ちの違和感で憲法の隙を炙り出す対話テスト

では、古い COBOL や PowerBuilder、Visual Basic、業務 Web アプリなどの移行で、どうやってその「隙のない憲法」を作ればよいのか。いきなり移行プログラムを書かせるのではなく、まずは 「対話（壁打ち）をリトマス試験紙にする手順」 を踏みます。

画面と帳票の試作反復から発展形が生まれる理由

どんな壁打ちをしても隙のない会話ができるようになってきたら、そこで初めて次の段階へ進みます。ただし、ここでもいきなり本番の基幹コードを丸ごと書かせるのではありません。

まず作らせるのは 「画面や帳票のプロトタイプ（試作品）」 です。実際に動く画面や出力された帳票の姿を人間の目で確認すると、言葉の壁打ちだけでは気づけなかった「この項目が並ぶと現場が誤入力する」「集計行の丸めタイミングが違う」といった細部の抜けが必ず見つかります。それを見つけてはまた憲法を更新し、もう一度プロトタイプを作らせる――この泥臭い反復をひたすら繰り返して「網羅された憲法」を完成させたとき初めて、AI は単なる現状維持を超えて 「元のシステムをさらに発展させた素晴らしい仕組み」 を生み出せるようになります。

そして憲法が何千行にも育ってきたら、当サイトが工程 ⑤〜⑫ で行った通り、テーブルや部品の依存関係は SQLite 索引 へ入れ、入出力の 1 円誤差や規約違反のチェックは AI 自身に書かせた Rust 製の高速検問ゲート へ逃がせばよいのです。

手元の64GB母艦と最上位AIプランの時間単価

この「壁打ちとプロトタイプ反復で憲法を鍛え上げ、ローカル環境で SQLite と Rust 検問所を常駐させ、クラウドの最上位 AI には純粋な思考だけをさせる」スタイルをストレスなく回す上で、もうひとつ大切なのが 手元の PC メモリ容量と AI プランの考え方 です。

16GB の RAM ディスクを切り出しつつ、OS のファイルキャッシュ、SQLite のメモリマップ、ブラウザ、開発エディタ、そして並列で走る Rust コンパイラを SSD スワップ（メモリ不足による記憶装置への退避）ゼロで動かすには、やはり 64GB クラスのメモリを積んだ母艦 が圧倒的な威力を発揮します。

一見すると 64GB メモリ環境や上位 AI プラン（Google AI Ultra 等）は贅沢に見えるかもしれません。しかし、ここからは耐用年数にもとづく 推論（試算） ですが、たとえば中古・整備済みの 27 インチ 5K iMac（2020 年モデル）に DDR4 メモリを増設して 64GB 化した環境や、64GB ユニファイドメモリ構成の Mac mini を 5 年間（1,825 日） 毎日使うとすれば、1 日あたりの機材コストは 数十円〜百数十円（缶コーヒー 1 本以下） に収まります。

見栄のための消費にお金をかけるのではなく、「人間は壁打ちとプロトタイプ確認による『憲法づくり』という正しい方向にだけ努力を注ぎ、探索や機械検問・実装は 24 時間 AI と Rust に働かせる（タイム・イズ・マネー）」 ための投資と考えれば、これほど回収の早い自己投資はなかなかありません。

【Intel Mac増設用】Crucial iMac 27インチ(2019/2020)・ノートPC用 メモリ DDR4-2666 SO-DIMM (16GB×2 / 32GB×2)

Amazon 楽天市場 Yahoo!

【中古・整備済品】Apple iMac 27インチ Retina 5K (2020年モデル / Intel最終世代・メモリ自己増設対応)

Amazon 楽天市場 Yahoo!

Apple Mac mini（Appleシリコン Pro系チップ・64GBユニファイドメモリ構成）

Amazon 楽天市場 Yahoo!

SanDisk Professional PRO-G40 SSD 4TB / 2TB (Thunderbolt 3 & USB 3.2 Gen 2 両対応)

Amazon 楽天市場 Yahoo!

まとめ：AIは純粋な思考へ、憲法執行はRustへ

最後に、初期の Python 一括置換の失敗から辿り着いた「AI 駆動開発・旧システム移行で破綻しないための鉄則」をまとめます。

もし今、手元のシステム移行や開発プロジェクトで「AI が見当違いなコードを出す」「ルールファイルが長くなりすぎてクォータが苦しい」と感じている方は、以下のプロンプトを使って、まずは 「憲法の隙を見つける壁打ち」と「SQLite 索引＋ローカル高速チェッカーへの分離」 から AI と一緒に始めてみてください。

なお、仕様の行間や安全境界線を誤って読み飛ばさないよう、軽量モデル（Flash 系など）ではなく 必ず『Gemini 4 Argon』（または同等以上の最上位推論モデル）を選択した上で 実行することを強くおすすめします。

以下の記事で解説されている「泥臭い憲法鍛造（壁打ちによる隙チェック → 画面・帳票プロトタイプ反復）と12段階の分離設計（憲法 × SQLite索引 × ローカル高速検問ゲート）」を参考に、私のプロジェクトを最適化したいです。
https://lab.chihouzakki.com/blog/review/ai-legacy-migration-failure-1141-constitution-rust-gate/

いきなり本番コードを書き換えたり一括置換したりせず、まず以下の順番で私と壁打ち・調査を行ってください：
1. 現在の仕様書・ルール定義・ディレクトリ構造を読み取り、移行方針・画面・帳票・入出力（I/O）の観点で「定義が曖昧でAIの解釈に隙が生まれる箇所」をすべて指摘し、私に質問して憲法を煮詰める。
2. 壁打ちで隙がなくなったら、まず画面・帳票（または出力形式）の小さなプロトタイプ案を提示し、私の確認を受けてさらに憲法を更新する。
3. あわせてクォータ消費と探索時間を減らすため、①毎回grep検索が発生する依存関係のSQLite索引化案と、②憲法遵守をローカル側（Rustまたは高速CLI）で機械検問する設計案を提示する。

AI に「空気を読め」と怒るのでもなく、AI に六法全書の丸暗記と書類探しを毎回やらせるのでもなく、AI が一番得意な「思考」と、Rust や DB が一番得意な「0.004 秒の厳密な検問・検索」を適材適所で組み合わせること。これこそが、今の時代に個人でも大企業以上の開発速度と品質を両立できる一番気持ちのいいやり方だと実感しています。