AI DevEx Conference 2026 登壇レポート
企業のレガシーシステム移行において最大の壁となるのが、現行仕様のブラックボックス化です。
長年にわたって改修が繰り返されたソースコードは複雑を極め、仕様書の陳腐化や担当者の退職も重なり、誰も正確な仕様を把握できない状態に陥るケースが少なくありません。
長年追加開発された複雑なプログラムから、いかに現行仕様を解明するか。
AIにコードをそのまま読み込ませても文脈の完全な解読はむずかしく、すべての組み合わせを手作業や力業で検証することは現実的ではありません。
本記事では、2026年7月22日から23日にかけて開催され、SHIFTがダイヤモンドスポンサーを務めた「AI DevEx Conference 2026 – Future of Development Productivity –」より、SHIFTにてAIコンパイラインフラストラクチャアーキテクトを務める片山の講演をレポート。
複雑なソースコードから、AIとシミュレーションを駆使して正確な業務ルールを抽出する手法を紐解きます。
AIの予測力と徹底した検証を掛けあわせたこのアプローチが、モダナイゼーションの未来をどう変えるのか、その全貌をご紹介します。
-
AIコンパイラインフラストラクチャアーキテクト 片山
大手電機メーカーにて組み込み開発やブラウザ、言語処理系・JavaScriptインタプリタの開発に従事。その後、楽天にて新旧サーバーを並行運用・比較する「ダークローンチ」手法を用い、店舗向け大規模APIのマイグレーションを成功に導く。SHIFTへ参画後はシステム仕様可視化ソリューション「SHIFT DQS for リバースエンジニアリング」を開発し、現在はインフラストラクチャアーキテクトとして、その進化形となるAIトランスコンパイラの開発を牽引している。
目次
レガシー移行が暗礁に乗り上げる最大の要因、仕様のブラックボックス化
現在、多くの企業が古いシステムのEOL（サポート終了）への対応や、既存システムをクラウド環境へ移行する「クラウドリフト」など、マイグレーションの推進を迫られています。
そのなかで、私がもっとも重要だと考えているのが、現行システムの仕様把握です。新旧システムの間に意図しない仕様の差異が生じれば、業務停止や深刻な障害を引き起こすリスクがあります。
実際に解析したお客様のプログラムから抽出した業務ルールは、機器設置の綿密なスケジュール、サービス組み合わせの最適化、サービスの利用者への請求に対するきめ細かな配慮が読み取れました。
サービス利用者を支えるサポート体制の特徴もうかがえました。システムの強みは業務ルールであり、企業の強みを支える要素の一つといえます。
しかし、現場で立ちふさがるのが深刻なレガシーコード問題です。
長年の運用のなかで、暫定対応パッチや特定顧客向けの例外処理、あとから追加されたif文が幾重にも継ぎ接ぎされ、巨大なオブジェクトにあらゆるデータが詰め込まれて引きまわされています。
規模拡大に伴いフレームワークが複雑化するなかでは、仕様の把握は容易ではありません。これは必ずしも実装品質の問題ではなく、現代的なレイヤー構造のアーキテクチャがもつ特性の一つでもあります。
オブジェクトやテーブルを明確に分離した設計は保守性や拡張性に優れる一方、業務仕様の全体像がコード上で見えにくくなる側面があります。
そのため、仕様書の更新が追いつかない場合には、コードを読み解かなければ全貌を把握できないという状況が生じます。
私が着目したのは、オブジェクトやテーブルの構造そのものではなく、仕様の核心である“業務ルール”を取り出すことでした。
例えば、「1株買うと持ち株が1株増え、在庫が1株減る」といった、ユーザーの入力情報DBの値を条件に照らしあわせ、特定の結果へと結びつけるルールのことを指します。
私はこれを説明するとき、よく漏斗（ファネル）に例えています。画面の入力フィールドやDBの値という入力変数が、条件や条件の組み合わせという漏斗を通って、最終的なアクション（変数の代入など）にたどり着く構造です。
抽出された業務ルールは、「デシジョンテーブル（条件と結果の組み合わせを整理した表）」の形式に整理されます。
デシジョンテーブルはソフトウェアのテスト仕様書にも通じる形式であり、条件が成立した際のアクションが明確になります。
これにより、特定のアーキテクチャに依存することなく、新システムにおける理想的な技術選定が可能になります。現行仕様の踏襲はもちろん、新たな業務仕様へと変更（モダナイゼーション）することも容易になるのです。
従来手法の限界。手作業・全探索・単なるAI検索（RAG）の壁
しかし、ソースコードから業務ルールを取り出す作業は困難を極めます。長年の運用と改修によって、コードは技術的負債の塊となりがちだからです。
実際に解析対象となったシステム（約72万行、100画面・1000イベント規模）では、新規注文作成に関わるたった1つの処理イベントに約5万行のコード、82の関連ファイル、83のデータフィールド計算が絡みあっていました。
計算コードとDBコードが別々の場所に分散し、巨大なオブジェクトに多種多様なデータが詰め込まれて引き回される構造が、解読の難度を跳ね上げていました。
「AIにソースコードを読ませれば解決するのではないか」と考える方もいるでしょう。
しかし、特定の文字列を検索する「grep」はもちろん、外部情報を参照して回答を生成するAI技術（RAG）を用いても、仕様の完全な解読は容易ではありません。
なぜなら、複雑化したコードのなかでは、同じフィールド名が別のテーブルに存在したり、同じ役割をもつ変数が微妙に異なる名前で使われたりしているからです。
文脈を完全に理解し、ソースコードの隅々まで何度も読み直さなければ、真の業務ルールは見えてきません。
さらに大きな壁となったのが、状態空間の爆発です。変数のコピー関係を追跡したところ、単一の処理に151もの条件が絡みあっていることが判明しました。
これらすべての条件の組み合わせは「2の151乗」という、天文学的な数字に膨れあがります。
あらゆるパターンをしらみつぶしに検証する全探索（ブルートフォース）を試みたものの、256GBもの巨大なメモリを搭載したハイスペックマシンでさえ、計算量が追いつかず解析不能に陥りました。
ノーベル賞AIに学ぶブレイクスルー。AIと3つのハーネスによるアプローチ
こうした問題のなかで私がヒントを得たのは、Google DeepMindが開発したタンパク質構造予測AI「AlphaFold」でした。
タンパク質の構造にも、アミノ酸の組み合わせによりほぼ無限のパターンが存在します。AlphaFoldは全パターンを力業で探索するのではなく、「AIの予測によって探索範囲を絞り込み、最後に検証する」ことでこの難題をクリアしました。
この「前処理 → AI予測 → 後評価 → シミュレーション」のパイプラインをコンパイラアーキテクチャに応用したのが、以下で説明する“3つのハーネス構造”です。
第1のハーネス：コンパイラ技法による構造化（SSA・ANF・モナド化）
まず、言語処理系の高度なコンパイラ最適化技術を適用しました。
- SSA（静的単一代入）およびANF（A正規形）の技法を用いてコード内の代入関係を整理
- 条件式を変数として扱い、monad化することで、条件と変数の依存関係を明確な有向グラフ構造へと変換
この前処理により構造化は進んだものの、名前のない中間変数などを含めて依然として2000変数・151条件が残り、組みあわせ爆発を抑え込むには至りませんでした。
第2のハーネス：AIの推論と形式検証ツール（Alloy）による探索空間の絞り込み
そこで導入したのが、AIの勘と経験を活用して探索空間を絞り込むアプローチ（第2のハーネス）です。
生成された依存グラフをもとに、AIに「どの経路が真の業務ルールにつながるか」を、変数トレースプログラムを生成させながら予測させました。
さらに、形式手法の論理検証ツール（AlloyやLean）を用いた論理検証・形式証明（形式手法）を組み合わせました。
モデル検査や論理検証によって矛盾や不要な経路を排除し、同じ実体を指す変数を代表変数に統合することで、151あった条件をまず変数5個3条件まで圧縮し、最終的には「入力変数3、条件3、ルール1、アクション1」という、人間が理解しやすいシンプルな業務ルールに整理することができました。
第3のハーネス：実機シミュレーションと「変数揺らし（摂動テスト）」
AIの予測で探索範囲を絞り込めたとはいえ、AIの答えを盲信してシステムを移行することはできません。最後にAIの推論を一切排し、決定論的なプログラム実行によるシミュレーション検証を実施します。
- 自動インテグレーションテスト：抽出された「入力・条件・ルール・アクション」をテスト仕様書へ変換し、画面表示やDB更新といった副作用を伴う部分にスタブ（仮プログラム）を注入して結合テストを実行。
- 変数揺らし（摂動テスト）：抽出されたルールに無関係と判定された周辺変数やフィールドの値を意図的に上下に変動（摂動）させ、実行結果に一切影響を与えないことを確認。
- AIとの協調によるエッジケース発見：シミュレーションを通じて、AIの初期予測だけでは拾いきれなかったエッジケースが浮き彫りに。
仕様の可視化からはじまる、真の業務プロセス改革
このアプローチにより、私のチームは巨大で複雑なプログラムから、数十個の具体的な業務ルールを正確に取り出すことができました。
この技術がさらに進化し、システム内のすべての業務ルールを確実に取り出せるようになれば、システム開発のあり方に大きな変化をもたらす可能性があります。
将来的には、システム全体のルールを網羅的に抽出し、「短期間で現行仕様を反映した PoC（概念実証システム）を自動生成できる世界」を目指しています。
これまで、現行仕様と新仕様のギャップに悩み、深夜まで手作業でコードを追いつづけていた大手SIerやエンタープライズのエンジニアにとって、この手法は大きなブレイクスルーとなります。
力業の全探索でも、テキストに頼るgrep/RAGだけでもなく、「AIの予測」と「シミュレーション検証」を組みあわせることで、現実的なコストとスケジュールで、現行仕様調査の効率化や精度向上が期待でき、モダナイゼーションやマイグレーションに伴う課題の軽減にもつながります。
しかし、レガシーコード問題を解消し、正確な仕様を把握することは、あくまで真のDXに向けたスタート地点に過ぎません。
現行の業務ルールがデシジョンテーブルとして可視化されてはじめて、長年企業を支え、収益を生み出しつづけてきた大切な業務を正確に再現・継承しつつ、「どのルールを統廃合し、どこを刷新すべきか」という本質的な議論が可能になります。
仕様把握の壁を越えることで、企業ははじめて“真の業務改革”へと踏み出すことができるのです。
まとめ
レガシーシステム移行を阻む最大の壁である、現行仕様のブラックボックス化。長年の運用で複雑に絡みあったソースコードは、人間の目視はおろか、最新のAI技術や高性能な計算環境を用いても容易には解読できないケースがあります。
しかし、AlphaFoldに着想を得たAIによる予測と、SHIFTが誇るテスト技術に裏打ちされたシミュレーション検証の掛けあわせにより、その壁を乗り越えるための現実的なアプローチが見えはじめています。
徹底したアプローチによって実現した正確な仕様把握。それは、これまでのシステムが培ってきた貴重な業務資産を確実に引き継ぐとともに、単なるシステム移行の成功にとどまらず、次世代に向けたシステムのモダナイゼーションと、企業が本来成し遂げるべき“真の業務改革”の未来を明るく照らしています。
（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）
