AIとハーネスで育てるトランスコンパイラ / 20260722 Yasushi Katayama

2026/7/22 AI DevEx Conference 2026

https://dev-productivity-con.findy-code.io/aidevex2026

AIコンパイラインフラストラクチャアーキテクト
片山 靖

1. AI DevEx Conference 2026 2026 7 / 22 14:15-14:55 AIとハーネスで育てる トランスコンパイラ 分散したコードから、検証可能な業務ルールを取り出す 株式会社SHIFT AIコンパイラインフラストラクチャアーキテクト 片山 靖 Copyright SHIFT Inc., All Rights Reserved. Yasushi Katayama 1
2. 自己紹介 Copyright SHIFT Inc., All Rights Reserved. 2
3. Copyright SHIFT Inc., All Rights Reserved. 3
4. Copyright SHIFT Inc., All Rights Reserved. 4
5. なぜソースコードから業務ルールを取り出すのか？ 古いシステムを新しいアーキテクチャーに移行しないといけない”マイグレーショ ン”、”モダナイゼーション” を必要に迫られている企業が多くあります。 マイグレ・モダナイで最も重要なこと 現行システムの仕様の把握 なぜなら、現行システムの仕様と同じ、または、新システムとの仕様の違いが分 かっていないと… ・会社全体の業務が止まる ・仕様の違いによりトラブルが発生する 業務ルールに着目 ・会社の業務の強みが発揮できなくなる などがあります。 Copyright SHIFT Inc., All Rights Reserved. 5
6. ソースコードから“業務ルール”を取り出すとは？ 重要 ポイント 実装は分散していても、利用者が知りたいのは一貫した業務ルール。 ソースコードからそのルールを取り出せれば、理解・検証・再構築がしやすくなる。 Copyright SHIFT Inc., All Rights Reserved. 6
7. 業務ルールは“フィールド同士の関係”として現れる 重要 ポイント 業務ルールは単独のフィールドではなく、複数フィールドと条件（monad）の関係として現れる。 結果変数ごとにその連鎖をたどって絞り込めば、ソースコードの分散実装から業務ルールを読み取れる。 Copyright SHIFT Inc., All Rights Reserved. 7
8. まとめ：業務ルールとは 業務ルールとは… 入力変数 条件 条件の組み合わせのルール →後述します アクション(結果変数の代入) →後述します Copyright SHIFT Inc., All Rights Reserved. 8
9. 業務ルールを「入力変数・条件・条件の組み合わせ・アクション」で仕様化する 重要 ポイント 入力（変数）を明確に する Copyright SHIFT Inc., All Rights Reserved. 条件を最小Fact（C1～ C3）に分解して定義 ルールは条件の組み合わ せで表現（AND/OR/NOT） アクションで 結果を定義する 9
10. 業務ルールは「デシジョンテーブル」にまとめると、すぐにプログラム化できる Copyright SHIFT Inc., All Rights Reserved. 10
11. 完全に“業務ルール”が取り出せると ・アーキテクチャに依存しない →理想のアーキテクチャを選定できる ・現行踏襲が容易にできる ・安全に業務（仕様）を変更できる Copyright SHIFT Inc., All Rights Reserved. 11
12. 理想的なDDDプログラム構成 重要 ポイント 書き直す対象は“振る舞い”ではなく“構造”。 仕様はレガシーから抽出し、Value Objectを核にしたDDD構成へ移す。 Copyright SHIFT Inc., All Rights Reserved. 12
13. Copyright SHIFT Inc., All Rights Reserved. 13
14. 今回解析した事例 サブスクリプション管理システム • サブスクリプションメニューが数十種類を管理 • 総行数72万step • 約100画面 • 約1,000イベント • クライアントサーバーで一気通貫に解析 • その中でも１イベントで、5万ステップの関係するコードがあり、82関数の関係するコード がある • １つの“業務ルール”にあたる一つのDBフィールドの書き込みに関係する関数が32関数 • 新規注文の作成で、83のDBフィールドを計算 • 全部で10000のDBフィールド書き込み、画面の表示がある Copyright SHIFT Inc., All Rights Reserved. 14
15. なぜ“業務ルール”をソースコードから取り出すのが難しいのか？ ・現行仕様調査、何度も何度もソースを読み直さないと取り出すことが できない ・調査対象が多岐にわたる（画面の表示フィールド、DBのフィールド等） （ちなみに…調査したプログラムで10,000ぐらいフィールドがあった。） “長年メンテナンスされてきたプログラムはより複雑になりがち” ：サブスクリプション管理システム 注文のレコード１つ新規作成しても、82の関数が関係し、１つの結果変数を作るのに32個の関数が関係 その結果、10^45の組み合わせが発生し、256GBのメモリがあるサーバでも解析が不能 ・AIでも全パターンを確認するわけではありません。 ・現行仕様調査が、非常に困難であることがわかります。 Copyright SHIFT Inc., All Rights Reserved. 15
16. レガシーコード問題 重要 ポイント レガシーコードの難しさは、単に古いことではない。 構造の分断・接ぎ木・巨大オブジェクト化によって、仕様抽出の探索空間が急激に大きくなることにある。 Copyright SHIFT Inc., All Rights Reserved. 16
17. 1. 計算コードとDBコードが別の島 重要 ポイント 問題は「DBがあること」ではなく、『仕様のまとまり』が計算コード側とDB側に分断されること。 そのため、同じ業務ルールを理解・変更・検証するたびに、複数の島を往復する必要がある。 Copyright SHIFT Inc., All Rights Reserved. 17
18. 2. 後から継ぎ足された接ぎ木構造 重要 ポイント 問題は「機能が増えたこと」ではなく、『仕様変更の経緯』がそのままコードに『分岐として継ぎ足される』こと。 そのため、現在の仕様を理解するには、幹だけでなく過去の枝と例外の意図まで読み解く必要がある。 Copyright SHIFT Inc., All Rights Reserved. 18
19. 3. なんでも1つのオブジェクトに詰めて引き回す 重要 ポイント 問題は「オブジェクトがあること」ではなく、『異なる意味の値を1つの入れ物に集約し、 複数処理で共有すること』。そのため、1つの項目変更でも影響ないことを確認するために 多くの参照先・確認箇所を見なければならず、構造の見通しが悪くなる。 Copyright SHIFT Inc., All Rights Reserved. 19
20. まとめ：なぜ“業務ルール”の取り出しが難しい？！ ・計算の島とDBの島が別の島 ・後から継ぎ足された接ぎ木構造 ・なんでもオブジェクトに入れて引き回し 長年運用していくと、 技術負債が溜まっていくだけでなく、 規模が拡大するにつれアーキテクチャやFWが複雑に ソースコードを何度も何度も読み直さないと、 “業務ルール”を取り出すことができない Copyright SHIFT Inc., All Rights Reserved. 20
21. その結果、状態空間が爆発する ここでいう状態空間は、条件の数のことです。 解析対象のプログラムは、以下のような複雑さでした。 ：サブスクリプション管理システム ・一つの注文レコードを作るのに82関数、その中で一つのDBのフィールドを作るのに 32の関数が関係しているプログラムでした。 ・if f(x) == “OK” thenのf(x)の戻り値のような変数名がない変数も含めると2000もの変数、151の条件がありました。 ・すべての条件に、True/Falseがあるので、2^151（10^45超）通りの組み合わせがあります。 地球から見える恒星の数は10^23だそうなので、身近にある無限の組み合わ せのものです。 ご存じの通りAIはすべての通りを調べるわけではありません。 しかし、AIを用いない通常のコンパイラでは、256GBメモリを持っているマ シンでも解析できませんでした。 Copyright SHIFT Inc., All Rights Reserved. 21
22. 4.状態空間の爆発 重要 ポイント 問題は151という数そのものだけでなく、各条件に true / false が付くことで 組合せ数が指数的に増えること。n条件なら 2ⁿ、151条件では約 2.85 × 10⁴⁵ 通りとなり、 総当たりの解析・テスト・シミュレーションは成立しない。 Copyright SHIFT Inc., All Rights Reserved. 22
23. Copyright SHIFT Inc., All Rights Reserved. 23
24. なぜコンパイラにAIとハーネスを組み込んだのか 組み合わせ無限問題を解くために、通常のコンパイラに、 AIとハーネスを組み込みました。 これを実装するのに参考にしたのが、 タンパク質の構造を予測する Google DeepMindのプロジェクトAlphaFoldです。 Copyright SHIFT Inc., All Rights Reserved. 24
25. コンパイラアーキテクチャ：AI前処理から実行シミュレーション確認まで 重要 ポイント AIが最終判断を下すのではなく、AIで仕様候補を絞り込み、alias解析・Lean/Alloy・ 実行シミュレーションで検証する。 このパイプラインは『仕様仮説』を抽出し、検証可能な形へ変換する。 Copyright SHIFT Inc., All Rights Reserved. 25
26. ノーベル賞を受賞した AlphaFold Copyright SHIFT Inc., All Rights Reserved. 26
27. AlphaFoldを参考に。2^n問題に対応 重要 ポイント AlphaFoldから得た示唆は、巨大な探索空間は AI 単体ではなく、前処理・後処理・シミュレーションを 含むハーネス全体で解く、ということ。コンパイラでも同様に、2^n問題を AI による縮約と検証の 組み合わせで突破する。 Copyright SHIFT Inc., All Rights Reserved. 27
28. AlphaFoldで参考にしたところ AIで予測する前に、前処理、AIで予測後に後処理 最後に実コードシミュレーションして、決める！！ 最後をAIの予測にしない！！ Copyright SHIFT Inc., All Rights Reserved. 28
29. AlphaFoldとコンパイラアーキテクチャの比較 重要 ポイント どちらもAIが最終判断を下すのではなく、AIで候補仮説を作り、信頼性評価・整合性チェック・ シミュレーションで検証する。 AlphaFold は「構造仮説」、コンパイラは「仕様仮説」を扱う。 Copyright SHIFT Inc., All Rights Reserved. 29
30. コンパイラの前処理 １つ目のハーネスとして 前処理では、従来からコンパイラの仕組みを使います。 ：サブスクリプション管理システム 対象のプログラムは、funnel（漏斗）構造を作った時点で、 2,000変数、151条件ありました。 十分に絞り込まれていません！！ Copyright SHIFT Inc., All Rights Reserved. 30
31. コンパイラ個別説明：AI前処理・正規化と依存構造化・funnel化 重要 ポイント ここで重要なのは、条件を単なる if 文として捨てず、monad 仮想変数として参加させること。 これにより、funnel化で result1個に効く依存集合へ縮約し、 その後、AIでできるだけ絞り込むことができる。 Copyright SHIFT Inc., All Rights Reserved. 31
32. AIによる絞り込みとalias分析 ２つ目のハーネスとして AIの予想もプログラムを作りながら検証する ①経路のトレース ②実際につながったかのチェック ：サブスクリプション管理システム この結果、確実性が増し、 2,000変数=>5変数 151条件=>3条件 まで圧縮されました。Lean/alloyというロジック言語を使用し、最終的に 入力変数 3, 条件3, ルール(条件の組み合わせ1), アクション1にまとめられました。 Copyright SHIFT Inc., All Rights Reserved. 32
33. AIによる絞り込みとalias分析・形式証明 重要 ポイント AI は「プログラムを分析するプログラム」を生成してハーネスとして使い、候補を絞り込む。 最終段階は Lean / Alloy で実際に形式証明し、不要な要素を除いた最小factを得る。 Copyright SHIFT Inc., All Rights Reserved. 33
34. まだこれで完了ではありません Copyright SHIFT Inc., All Rights Reserved. 34
35. 実コード・シミュレーション確認 最後の３つ目のハーネスとして AIが提案した候補を実際のシミュレーションにかけます。 インテグレーションテストを自動作成し、テストを通過 できれば、“業務ルール”の取り出し成功です！ Copyright SHIFT Inc., All Rights Reserved. 35
36. 実コード・シミュレーション確認：最小factを元に統合テストで仕様を検証 重要 ポイント 最小factを“事実（入力・条件・ルー ル・アクション）”として、実コード上 での振る舞いを統合的に検証する Copyright SHIFT Inc., All Rights Reserved. 副作用はStubで隔離し、再現性と 制御性を確保する 実機で確認できない場合は、シ ミュレーション環境で補完する 周辺フィールドの影響がないことま で確認し、仕様の正確性を担保する 36
37. Copyright SHIFT Inc., All Rights Reserved. 37
38. 今後の展望 複雑なプログラムから”業務ルール“を取り出すことができました。 すべての業務ルールを取り出せば、お客様のプログラムをお預かり して１か月ほどで、現行仕様そのままのPoCが作れます。 AIをこのように活用すれば、現行仕様調査も現実 的なコストで正確にモダナイゼーション・マイグ レーションはもう怖くありません！！ 現行仕様調査とPOCをもとに、綿密な計画を立て、真のモダナイ ズと業務改革を実現しましょう！！ Copyright SHIFT Inc., All Rights Reserved. 38
39. ご清聴ありがとうございました！！ ご清聴ありがとうございました Copyright SHIFT Inc., All Rights Reserved.