1 価格.comをAI駆動で全面刷新する ー 30年分の技術的負債を返し、次の30年の土台をつくる ー 2026.6.8 AI Engineering Summit Tokyo 2026 株式会社カカクコム CTO 京和 崇行 

2 京和 崇行 Kyowa Takayuki SIer 2003-2007 Full Stack Engineer (食べログ) 2007-2012 PdM/ TechLead 2012-2014 CEO/ BizDev 2015-2019 食べログ 技術責任者 2019-2023 CTO 2024- Mission 自己紹介 レシピサービスの会社（CEOは子会社） 独立系SIer Hobby ボルダリング、マンガ、仕事 株式会社カカクコム 上級執行役員CTO AI・テクノロジー管掌 「AIネイティブカンパニー化」をミッションに、全社の プロダクト開発やオペレーション業務のAI活用を推進。 

3 3 ..and more Sponsored by ユーザーファーストで、新しい常識を作る 

4 本日のアジェンダ 1. 価格.com事業紹介 2. システム改革プロジェクトについて 3. 現行システムを刷新する独自のAIワークフロー 4. 新システムの技術選定とアーキテクチャ 5. システム改革を淀みなく進めるための組織づくり 

5 5 価格.com事業紹介 1 

6 6 

7 7 

8 8 システム改革プロジェクトについて 2 

9 プロジェクトの背景 価格.comカンパニーでは「AIによるレバレッジ」を加速させるため、2つの改革PJを推進中。 システム改革 プロジェクト オペレーション改革 プロジェクト 

10 価格.comのシステム C# / Classic ASPが混在するWindowsのシステム。 メイン言語はC#だが、創業から約30年、システム全体の抜本的な刷新をすることなくここまで運用。 レポジトリ数 752 C#コード行数 800.9万行 画面数 1,353 バッチ数 ASPコード行数 161.0万行 498 単独ファイルの 最大コード行数 11,350行 テーブル数 13,210 単独テーブル 最大カラム数 327 単独テーブル 最長レコード数 5.89億行 

11 AI駆動によるシステムリプレイスの検証 長年の負債が積み重なっており、小さな変更でも大きな工数がかかる状態。 生成AIが進化した今、「今あるものを直す」よりも「ゼロから作り直す」方が早いのでは？ という仮説の元、2025年10月からPoCのプロジェクトがスタート。 2025年10月〜2026年1月 PoC 第一段階 2026年1月〜2026年3月 PoC 第二段階 2026年4月〜 リプレイスの意思決定 ＜ウォーターサーバー再構築＞ 独立性が高く、かつシステムが最も シンプルな領域を選定。独自のAI ワークフローの作成が始まる。 AIによる実装18h + 人間による修正 22h = 40h で、8割程度の完成度で再 現。 ＜金融領域の再構築＞ より複雑で、別の言語によるリプレ イスの試験。 AIによるE2Eテストの検証が開始さ れ、動作検証の重心が人間からAIに シフトした。 ＜本格対応の開始＞ PoCの結果を評価し、正式に決定。 AIワークフローにブレイクスルーが 起き、自律性と生成精度が一気に上 がったこと、価格.comチーム内での 検証が始まり、手応えがあったこと が意思決定に繋がった。 

12 システムリプレイスのスコープ • アプリケーション・インフラをフルスクラッチで書き直す • DBのテーブル構造は現行を維持（次フェーズ） • 原則、既存の機能やビジネスロジックは変えない • 30周年（2027年）に向けた中長期プロジェクトとして推進 • 理想は2027年5月の30周年に間に合わせること！ 

13 2026年5月キックオフ – “DODAI” プロジェクトの始まり 「価格.comの次の30年を支える “新しい土台” をつくる」 キックオフMTGからの引用 

14 14 現行システムを刷新する独自のAIワークフロー 3 

15 AIワークフローの全体像 ― 5つのフェーズ × 3層のAIエージェント実行レイヤ Phase 1 現行システム分析 › Phase 2 アーキテクチャ設計 › Phase 3 詳細設計 › Phase 4 実装 › Phase 5 受入テスト Orchestrator Step Group Sub Agent Sub Agent Step Group Sub Agent Sub Agent Step Group Sub Agent Sub Agent … … … 既存のコードとドキュメントを基に、AIが現行システムを新たな言語・アーキテクチャで作り直す。 各フェーズごとでオーケストレータが全体を統括し、その下のStep Groupが工程ごとにサブエージェン トを起動する。サブエージェントは一つの役割に特化し、合計で71体実装されている。 

16 設計思想と特徴 大規模なシステムの再現をAIに任せるためにAIワークフローの要点を5つに整理した。 1 長時間の自律実行 人手の監視なしに、AIが動き続ける。 2 高いコンテキストスケーラビリティ 対象が大規模でもサブエージェントは単独役割で必要な文脈 だけを持ち、性能を保つ。 3 現行システムを正解とする 既存のコードとドキュメントを信頼できる唯一の情報源として、 現行システムの仕様を正確に再現をする。 4 自律的な改良機構 失敗や誤りを検知し、自力で修正するサイクルを回す。 5 工程ごとの品質評価 各工程にQAプロセスを設け、通過・非通過を判定する。 

17 AIワークフローの成果（2026/5時点） 価格.comの保険カテゴリを、AIが一定の完成度まで自力での構築をやりきった。 実行時間 134時間 実行コスト $6,921 総生成コード 約3.6万行 サブエージェントの 呼び出し回数 1,959回 対象ページ数 88 生成E2Eテストケース 5,629個 Phase 5(のみ)の実行結果 

18 新旧コードの規模比較と考察 AIワークフローを実行した3カテゴリで比較。 保険が最大で43.4%の削減。ウォーターサーバーはやや微増という結果となった。 サービス C# / ASP 総行数 C# / ASP 実装コード行数 Python 総行数 Python 実装コード行数 実装コード比 (Python / C#) ウォーター サーバー 16,178 7,058 11,923 7,796 110.5% クレジット カード 47,735 29,215 27,971 19,313 66.1% 保険 172,812 67,931 36,194 29,505 43.4% 現状の仮説として、新しい（メンテされている）カテゴリほど、削減幅が小さいという傾向。 AIワークフローは仕様を変えずに再実装する。つまり、業務そのものが抱える本質的複雑性は保たれ、 その領域のコード量が減らないのは意図通りの結果。 古い実装や歴史的経緯から生じた、偶有的複雑性にまつわるコードが削減されている。 

19 各フェーズごとの解説 人間の開発工程と同じ流れを、責務ごとに特化したAIエージェント群が協調しながら進める。 P1 現行システム分析 既存コード・ドキュメントから、画面・遷移・業務ルール・URL/APIを抽出し、現行仕様 の分析結果としてドキュメント化する。 ▼ P2 アーキテクチャ設計 新システムのアーキテクチャ・技術選定内容をADR（Architecture Decision Record） として出力。このPhaseは人間レビューと対話による調整が必須。 ▼ P3 詳細仕様設計 API・UI・業務ルールを、実装可能な粒度（OpenAPI等）まで具体化する。 ▼ P4 実装 Phase 3の仕様書に基づき、Phase 2で定義したアーキテクチャでコード＋ユニットテス トを実装。 ▼ P5 受入テスト Phase 4で生成された新システムが現行システムと機能的に同等であることを、E2Eテス トなどで検証。 

20 長時間止まらず、動き続ける仕組み 複雑で長時間かかるタスクを与えた時、AIは途中で諦めたりズルをして目的を達成しようとする。 動き続けるためのAIワークフローの設計を、Anthropicによる長時間稼働の5つの失敗パターンに対応づけた。 Anthropic が示した5つの失敗パターン AIワークフローの設計 Context Rot コンテキストが埋まると、矛盾した判断をする Premature Completion 上限を察知し、作業を早く切り上げる Lossy Compaction 要約によって必要な詳細が失われる Shallow Plans 扱いやすい単位に分解せず、一回でやろうとする Generous Self-evaluation 生成物を甘く評価し、バグがあるのに完了としてしまう 3層エージェント構造 作業単位ごとに文脈を分け、フレッシュな状態で実行 構造化された仕様書 AI向けに責務と粒度を揃え、後続工程が安定 工程単位の独立レビュー 実行とは別のAIが、別の文脈で点検 完了判定ゲート 自己申告に頼らず、成果物とテストの通過を機械判定 E2E自律改善ループ 現行と同等になるまで、失敗を戻して自力修正 

21 同じ挙動をどう保証するか 仕様のトラッキング 現行仕様の各項目にIDを付与し、 Phase1〜4まで対応を追う。 Phase 5（最終QA）でのチェック 各Phase内でのチェック AIの結果レポートを信じるのでなく、新システムを実際に動かして、その結果をもとに評価し、 問題を一つずつ潰していく。また、このすべての一連の流れをAIが自律的に行う。 決定論的チェッカー プログラムで抜け漏れや逸脱を 検査し、AIの嘘を弾く。 Docker 実起動 主要URLを実際に叩き、プレースホル ダ実装・汎用フォールバックなどによ る抜け道実装がないかを検出。 ディファレンシャルテスト 新旧のDOM・スクリーンショット・ 値の差分を抽出する。 E2Eテスト Playwrightで現行と新システムを操作 し、DOM・表示・値が一致するかを 検証する。 差分の対応分類 差分を「修正対象／許容／環境起因」 に分類し、修正対象に対する適切なア プローチを行う。 

22 AIワークフロー自体の観測と改善 実行時間・コスト・呼び出し回数などを計測し、ワークフロー改善作業をスキル化。 ワークフロー自体もAIが自律的に改善する仕組みを構築している。 観測（Tracer) 実行時間・コスト・API呼び出し・サブエージェント 数を計測・可視化 Issue化 調査・計画 実装 検証 移植性 Claude Code Codex 特定のツールに縛られず、実行環境を移せる形へ AIワークフロー自己改善Skill 

23 今後の課題と展望 すべてをAIに任せきるにはまだ遠い。人間による動作確認も必須で、不安定な部分も多い。 コスト 設計者の月額AI利用料は440万円。さらなる拡大を見据えてコスト最適化が急務。 品質 内部品質（コード品質、テストカバレッジ）の向上と安定化。 評価 ワークフロー自体の性能を測るベンチマークの整備。 実行基盤 ローカル実行 → クラウド実行（GCPオフロード）への移行。 組織 今はAIの生産速度に、人が追いついていない。組織基盤の整備も必要。 今後の展望 価格.comだけでなく、会社の様々なサービスへ横展開する。 今後の課題 

24 24 新システムの技術選定とアーキテクチャ 4 

25 技術選定の要諦 技術選定は、事業特性から技術要件を導出することから始まる。 1 サービス特性「広く、浅く」 カテゴリ数は膨大だが、UI/UX はシンプル。 （検索・一覧・詳細・比較が中心） 2 UI要件「シンプル」 複雑なインタラクション（SPA）は不要。体験はシンプルで、 情報量や比較などで価値を出す。 3 経営課題「売上拡大 & 費用圧縮」 新規カテゴリ構築による成長が最優先。既存カテゴリの運用を 効率化して、成長投資の原資を確保する。 価格.comは「広く、浅く」。多数のカテゴリをシンプルなUIで、高効率で開発できること を要件とした。 

26 価格.com 新システムの技術選定 1 AI時代のエンジニア像 フルスタック・フルサイクルのエンジニアが当たり前になる。 領域を横断して多種多数のシステムをエンジニアリングする。 2 AI時代に求められる言語体系 AIフレンドリーな言語であること。 自律的な開発を支援するための型推論や低コンパイル時間など。 事業特性に加えて、AI時代に求められるエンジニアの役割や言語体系を整理し、 「Python 」 + 「FastAPI 」 + 「htmx 」 という構成を選定した。 

27 Pythonの選定理由 利用人口が大きく採用しやすい。AIによるコード生成とも相性がよく、型安全な 開発も可能。 人材採用の優位性 利用人口が多く、採用母集団が大 きい（人材確保リスクの低減）。 エコシステムの充実 ネット上のソースコード・ドキュ メントが豊富なため、AIのコード 生成精度も高い。OSSも充実。 AIとの親和性 機械学習・生成AIの標準言語。 Pydantic により、動的言語だが 型安全な開発ができる。 

28 FastAPIの選定理由 マイクロフレームワークのためアップグレードにかかるコストが低く、パフォー マンスも必要十分。2026年現在、PythonのWAFとしては最もシェアが高く、長期 的な運用耐性が高い。 低い運用コストと学習曲線 マイクロフレームワークで機能が 最小限。学習・アップグレードの コストが低い。 必要十分な性能 非同期処理（Async）に標準対応 し高トラフィックに強い。 API 設計の自動化 OpenAPI（Swagger）定義書が 自動生成され、ドキュメント作成 コストがゼロに。仕様の乖離も防 ぐ。 

29 htmxの選定理由 jQueryのシンプルさを、モダンなWeb技術で安全に再現。 jQueryが現役の価格.comにとっては最も移行が容易。 必要十分な機能 「検索・一覧・フォーム」の動的 更新に SPA は過剰。htmx は HTML 属性だけで実現する適正技 術。 低コストな運用 JavaScript の巨大なエコシステム （ビルド・依存）が不要。ライブ ラリ自体が軽量で保守コストが低 い。 バックエンド主導の開発 API と画面が分離せず一気通貫で 開発できるため、一気通貫で対応 黄が可能。BE/FEと言った分業の 必要性が薄い。 Click Me HTML 属性だけで AJAXとHTML更新を表現できる。 

30 Vertical Slices Architecture(VSA)の採用 価格.comではカテゴリごとの独立性が高いため、機能的な関心軸で分割するVSAと の相性が良いと判断。スライスの中に関心事が集中する構造のため、コンテキスト にも優しく、AIとも相性が良い。 → ※ 検証中のため、追試は必要。 Vertical Slices Architecture Clean Architecture 

31 31 システム改革を淀みなく進めるための組織づくり 5 

32 なぜ大規模なシステム改革は難しいのか？ A.リーダーシップとマネジメントの両方を、高い次元で同時に求められるから。 マネジメント・リーダーシップマトリクス リーダーシップとマネジメントの役割 リーダーシップ マネジメント 役割 変化への対処 複雑さへの対処 課題設定 方向性を示す 計画・予算を立てる 実行 人を束ね、鼓舞する 組織化し、統制する リーダーシップだけでは、無秩序なカオスに陥る。 マネジメントだけでは、変 革のスピードと振れ幅を出しきれない。 カオス 動くが、まとまらない 変革 ★ 動いて、変わる 硬直 動かず、変わらない 漸進 動くが、跳べない リーダーシップ 強 弱 弱 強 マネジメント 

33 推進者が持つべきマインドセット 楽観的に構想し、悲観的に計画し、楽観的に実行する AIでまるごとリプレイスできるのでは？ 本当にAIで書き直せるのか？ 起こりうるすべての問題を考え尽くす。 コードの規模・複雑さ ／ AIと人の境界 ／ 再現の担保 ／ AIの限界 / etc... 構想 計画 実行 問題は必ず起きる。それでも必ず越えられると、信じてやり切る。 

34 34 推進するうえで意図して取り組んだことを、五つご紹介します。 1 ビジョンを掲げる 2 協業体制をつくる 3 行動原則を据える 4 抵抗に向き合う 5 キックオフで動き出す 

35 ① ビジョンを掲げる - ビジョンに意味を込める 良いビジョンは 「有意義な目的」「未来のイメージ」「明確な価値観」の3つで構成される。 価格.comの次の30年を支える、新しい土台をつくる。 シンプルで伝わりやすい表現の中に、どれだけの意味と意図を圧縮して込められるか。 前向きに捉え直す 負債の返済を、「次の30年」「新 しい土台づくり」として語る。 スコープを定める 仕様は変えず、土台（裏側）だけ をつくり変える。 自然と浸透する単語を選ぶ 「土台」を、DODAIというプロ ジェクトコードに昇華させる。 

36 ② 協業体制をつくる ― PoC期 コンセンサスが固まる前は、各組織が独立して動ける、疎な連携にする。 価格.com エンジニア組織 CTO 直下 価格.com 開発組織長 Chief of Staff（CTO補佐） 各領域の開発 既存システムの運用 AIスペシャリストチーム 初期段階では、各組織が向き合うべきテーマが異なる。価格.com組織、CTO直下組織がそれぞ れ独立して各々のテーマに集中して取り組める体制とした。 

37 ② 協業体制をつくる ― キックオフ後 コンセンサスが固まった後は、分かれていた組織を一つに束ね、密に連携する。 開発チーム 移行にオーナーシップを持つチーム 推進チーム AIワークフローの開発やイネイブリングを行うチーム 移行チーム QAやインフラ移行などを担当 領域A 領域B 領域C 領域D 移行QA インフラ移行 価格.com横断推進 AI＆アーキテクト プロジェクト責任者 価格.com 開発組織長 Chief of Staff（CTO補佐） 統合は、片方に寄せれば進まない。価格.com組織とCTO直下、双方の長を推進責任者として 対等に立て、どちらも当事者となる体制とした。 

38 ③ 立場を越えて共有する行動原則 変革の振れ幅とスピードを一人ひとりが生み出すためのマインドセットを共有する。 守りたい人・変えたい人がお互い歩み寄り、同じ目線でプロジェクトに取り組めるように。 01 オーナーシップを持つ 1人1人がリプレイスを完遂させるマインドを持ち続け、 あらゆる状況に柔軟に自ら行動していく。 02 AIを中心に考える これまでの延長線ではなく、AI前提であるべきから考 える。人間は人間がやるべき仕事に集中する。 03 部分最適をしない 小さく直して終わり、にはしない。チームだけでなく、 価格.comという事業や組織全体を最適にしていく。 04 過去を否定しない これまでの選択は、その時点での最善。否定ではなく 進化のための整理として、過去と向き合う。 ＜キックオフで共有した4つの指針＞ 

39 ④ 変化への抵抗と向き合う 現状維持を望む人は敵ではない。向き合う先は、事実と仕組み。 慎重さは現場を支えてきたがゆえの懸念であり、一定の合理性がある。そのことを認める。 原因を、人ではなく仕組みに置く チームの目線が自領域に閉じる場面もあった。その多くは、縦割りの組織と旧いシステムが生む構造の問題である。 説得ではなく、結果で示す 言葉を重ねるより、動くものを見せる。PoCでは、ウォーターサーバーのシステムを短期間で再現した。 主観ではなく、事実で議論する 「難しい」「時間がない」という定性的な話ではなく、誰が何にどれだけ時間を割いているか、具体の事実で話す。 強いコミットメントを示す 最終的には強い意志、そして考え抜くことが重要。そのうえで真正面から対話する。 

40 ⑤ キックオフで動き出す – キックオフの重要性 準備を入念に尽くして、一気に動き出す。大規模になるほど準備が重要。 キックオフは、組織全体が本気で動き始めるための、最もレバレッジの効く起点。 ＜トップのコミットメント＞ ＜入念な準備＞ キックオフ冒頭、価格.com組織長からの宣言 キックオフ資料で繰り返したレビュー 約 10 回 レビューを重ね、 迷いが出ないところまで磨き込んだ。 キックオフ資料からの引用 

41 41 おわりに 6 

42 本日のアジェンダの振り返り 1. 価格.com事業紹介 2. システム改革プロジェクトについて 3. 現行システムを刷新する独自のAIワークフロー 4. 新システムの技術選定とアーキテクチャ 5. システム改革を淀みなく進めるための組織づくり 

43 43 絶賛採用募集中！ ・ AI Expert ・ Fin Ops for AI ・ AI Platform / Harness Engineering ・ Company AX Engineering 

44 44 ..and more Sponsored by ユーザーファーストで、新しい常識を作る 

45 ご清聴ありがとうございました