価格.comの30年コードをAIが建て替える。選ばれなかった技術の話

C#で約800万行、Classic ASPで約160万行。合わせて約960万行のコード。リポジトリ（コードの保管庫）は752個、データを格納するテーブルは13,210個、画面は1,353枚。創業から約30年、抜本的な作り直しをせずに動かし続けてきた。

これは価格.comの裏側にあるシステムの規模です。先日公開されたカカクコムのCTO・京和崇行さんの登壇資料で、その数字が公開されました。そして同社は今、この巨大な30年ものを、AIに書き換えさせています。プロジェクトの名前は「DODAI」。Debt Of Decades + AI、つまり「数十年分の負債」と「AI」をかけた名前だそうです。ネーミングからして覚悟がある。

正直に言うと、最初に技術スタックがC#とWindowsだったことに驚きました。価格.comのような巨大サービスを、SaaSの寄せ集めではなく自前のWindowsシステムで30年支えてきた。そしてその規模の数字を見て、もう一度驚いた。これはもう、決断するに足る負債です。リプレイス（作り直し）に踏み出すのは正しい。

ただ、資料を読み込むほど「うまいな」と思う判断と、「ここ、私だったらどうしただろう」と引っかかる箇所が両方出てきました。否定したいわけじゃありません。むしろ手伝いたいくらいに面白い。だからこそ、現場のいち開発者として気になったことを書いておきたいと思います。

サービスを止めずに、30年ものを建て替えるということ

まず押さえておきたいのは、これは更地に新築を建てる話ではない、ということです。価格.comは今この瞬間も動いていて、利用者がいて、売上が立っている。止められない。家にたとえるなら、住みながら建て替えるようなものです。新しく一から建てるより制約が増えるし、その制約を飲み込むために、わざわざ複雑さを足さざるを得ない場面が出てくる。

その点で、データベース（データの土台）は現行構造を維持したまま進める、という判断は正しいと思いました。基礎まで一気に作り替えると、家全体が傾く。基礎は残して、上物から直す。手堅い順番です。

一方で、現行のDBを残すというのは「ゼロから理想形を作る」のとは重さが跳ね上がる選択でもあります。13,210個のテーブルには、30年分の事情が詰まっている。それを正解として扱いながら、コードだけきれいにしていく。理想的なクリーンな状態に持っていくのは、想像するだけでなかなか骨が折れます。だからこそ、後続のフェーズで土台側も含めて設計をきれいに閉じていく方針——資料でいう Vertical Slices Architecture（機能ごとにコードを縦に切り分けてまとめる設計。VSAと略されます）で閉じる——のは、筋のいい着地だと感じました。

この「日本のIT移行はなぜ難しいのか」という話は、過去に特許庁やグリコの移行失敗を5パターンに分けて書いた記事でも触れました。止められない巨大システムの作り替えは、技術以前に判断の連続です。価格.comはそこに、AIという新しい変数を持ち込んだ。

なぜPythonだったのか。そして、同点だった候補はなぜ負けたのか

新しい技術スタックは、Python・FastAPI（Python製の軽量なWebフレームワーク）・htmx（JavaScriptをほとんど書かずにHTMLだけで画面を動かす仕組み）。採用理由として挙がっているのは、Pydantic（データの型を自動で検証するPythonのライブラリ）による型の安全性と、AIによるコード生成との相性のよさ、そして「必要十分」を狙ったシンプルさ。

この選定自体には、私も同意します。FastAPIのメリットは実務で感じていますし、htmxも悪くない。画面側を軽く保てるのは、AIに生成させるうえでも効いてくるはずです。採用した武器は、ちゃんと刺さる武器だと思う。

ただ、ひとつだけ純粋に気になったことがあります。資料には「これを採用した理由」はあっても、「これを採用しなかった理由」がほとんど書かれていない。技術選定をしたことがある人なら分かると思いますが、比較表の本当に面白い列は、勝った技術の隣にある「負けた技術と、その負け方」です。

たとえばバックエンドの言語。「Pythonで解決できます」という主張は、裏を返せば他の選択肢も土俵に上がっていたはずです。型の安全性、大量の同時リクエストをさばく非同期処理、そしてVSAのような層を意識した設計との相性。この観点だけで素朴に並べると、Goあたりはかなり強い。並行処理が言語に組み込まれていて、型もかっちりしている。私自身、次の主力言語にGoを選んだ理由を「最強武器ランキングで言語を選ぶな」という記事に書いたくらいで、この領域でのGoの相性のよさは身体感覚としてあります。

もちろん、これはGoの方が正解だった、という話ではありません。分析処理やデータ周りがサービスに密に組み込まれるなら、Pythonのライブラリ群は圧倒的に強い。だったらいっそ、責務ごとにサービスを物理的に分けるマイクロサービス（小さな部品に分けて連携させる作り）にして、データ処理はPython、高負荷なAPIは別言語、と棲み分ける手もある。AIに書かせる時代だからこそ、部品が物理的に分かれていて、つなぎ目の約束ごとさえ人間がきっちり決めておけば、品質を保ったまま並行して開発できるかもしれない。比較の土台に上げてよさそうなものは、ぱっと考えるだけでもいくつか浮かびます。

71体のAIに任せて、いちばん怖いこと

DODAIの中身も面白い。5つのフェーズ（現行分析→設計→詳細仕様→実装→受入テスト）に、合計71体のサブAIエージェントを配置して、長時間自律で走らせる仕組みです。保険カテゴリの再構築では、134時間・$6,921で約3.6万行を生成し、E2Eテスト（利用者の操作を最初から最後まで再現する自動テスト）を5,629件も作ったといいます。AIで32人規模のチームを動かす検証は私も個人でやってみたのですが、71体を本番の刷新に投入する胆力はすごい。

そのうえで、技術的負債を返すためのプロジェクトで、新しい負債を作ってしまう——この事故だけは起きてほしくないな、と強く思いました。負債を取り除くために負債を生む。笑い話のようですが、AIに任せすぎると普通に起こります。

怖いのは、派手な失敗じゃない。AIの提案がそれらしくなればなるほど、「それで」とEnterを押してしまう、その瞬間です。提案が筋よく見えるから、つい確認を省く。そして後になって、エッジケース（例外的な入力や状況）でバグり、しかもそれが元に戻しにくい作りになっていることに気づく。可逆性（あとから元の状態に戻せること）が弱いことに、その時が来るまで気にも留めていなかった。これ、本当にしょっちゅうあります。

もっと厄介なのは、知識の在り処です。どんな現場にも「この機能は◯◯さんしか知らない」というブラックボックスがありますよね。AI主導の開発で雑にEnterを押し続けると、その◯◯さんすら存在しない状態が生まれる。仕様を本当に分かっているのが、もう存在しないAIのセッション（その時の対話の文脈。閉じたら消える）だけ、という代物が量産される。誰にも引き継がれないまま、コードだけが残る。これは新種の負債です。

AIの性能向上は本当に半端ない。それっぽさが上がる速度も恐ろしいほどです。でも、「網羅的でベストな選択をした」ように見えるだけ、というケースはまだ全然ある。見えるだけ、です。だから「もう時代は変わった、AIに書かせたものをそのまま動作確認して出せばいい」という言説を、私は丸ごとは信じていません。あれは、たぶんそのレベルの仕事しかしていない人の感想です。真に受けると事故る。AIが書いたコードが壊れたとき誰の責任になるのかという問題とも、地続きの話です。

転換点は、もうすぐそこまで来ているのかもしれない。それでも今はまだ、意思決定を放棄せず、人間のレビューを挟む必要がある。下に置いたのは、私が自分のために使っている自己点検リストです。価格.comほどの規模じゃなくても、AIに任せる開発をしている人には効くと思います。

ちなみにこの感覚は、AIで一度ウォーターフォール的な工程に戻ってみて分かったことでもあります。詳しくはAI開発でウォーターフォールに帰った話に書きました。DODAIが5フェーズの工程と品質評価ゲートを置いているのは、まさにこの「任せすぎ事故」への備えだと読めて、そこは唸りました。

「楽観的に構想し、悲観的に計画し、楽観的に実行する」

資料の中で、いちばん刺さったのは技術の話ではありませんでした。プロジェクトを貫くマインドセットとして掲げられていた、この一文です。

「楽観的に構想し、悲観的に計画し、楽観的に実行する」

これは、私もまったく同じ思想で動いているので、強く共感しました。夢は大きく描く。計画は最悪を想定して悲観的に詰める。でも、いざ走り出したら腹をくくって楽観的に進む。この3つの切り替えができるかどうかで、長期プロジェクトの体力はまるで変わります。

資料には他にも、「人ではなく仕組みに原因を置く」「過去を否定しない」「キックオフ前に資料を10回近くレビューした」といった、組織とメンタルの設計が並んでいました。技術選定の話より地味ですが、こういう部分こそ、30年を作り替えるような長い開発サイクルでじわじわ効いてくる。月額440万円のAI利用料や、ローカルからGCP（クラウド)への移行といった生々しい課題を抱えながら、それでも前に進める組織を作っている。

正直、これを設計してやり切ろうとしている方は、エンジニアリング組織を率いるのに素晴らしい人材だなと思いました。技術スタックの議論はいくらでもできるけれど、この手のメンタル面の土台は、一朝一夕では作れない。

負けた技術の話が聞きたい、という応援

ここまで、気になったことを正直に並べました。同点に見えた候補はなぜ負けたのか。AIに任せすぎて新しい負債を作らないか。でもこれは全部、否定じゃなくて興味です。むしろ手伝いたいくらい、面白いプロジェクトだと思っている。

30年もののコードを、サービスを止めずに、AIと一緒に建て替える。これが成功したら、日本の多くの「作り替えたいけど止められない」システムにとって、ひとつの道しるべになります。価格.com以外への横展開も視野に入れているそうなので、なおさらです。

参照元: 価格.comをAI駆動で全面刷新する（京和崇行 / Speaker Deck） ／ カカクコム、AIエディタ「Cursor」を全エンジニアに導入（PR TIMES）