■ 1. 価格.com事業概要
- 「買ってよかった」をすべてのひとに、をコンセプトとした購入支援メディア
- パソコン、家電、自動車、携帯電話、ファッション、ゲーム、保険、プロバイダ等42商材を網羅
- 月間総PV: 約2億4,753万PV、月間利用者数: 約3,108万人（PCサイト: 約999万人、スマートフォンサイト: 約2,109万人）
■ 2. システム改革プロジェクトの背景と経緯
- 「AIによるレバレッジ」を加速させるため、システム改革とオペレーション改革の2つのプロジェクトを推進中
- 現行システムの概要:
- C#/Classic ASPが混在するWindowsシステムで、創業から約30年間、抜本的な刷新なしに運用
- レポジトリ数: 752
- 画面数: 1,353
- バッチ数: 498
- C#コード行数: 800.9万行
- ASPコード行数: 161.0万行
- テーブル数: 13,210
- 単独テーブル最大カラム数: 327
- 最長レコード数: 5.89億行
- PoCの経緯:
- 2025年10月〜2026年1月（PoC第一段階）:
- ウォーターサーバーカテゴリを対象に再構築。AIによる実装18h + 人間による修正22h = 40hで8割程度の完成度を実現
- 2026年1月〜2026年3月（PoC第二段階）:
- 金融領域を対象に再構築。AIによるE2Eテストの検証が開始され、動作検証の重心が人間からAIへシフト
- 2026年4月〜（本格対応の開始）:
- PoCの結果を評価し正式決定。AIワークフローのブレイクスルーと自律性・生成精度の向上が意思決定に繋がった
- リプレイスのスコープ:
- アプリケーション・インフラをフルスクラッチで書き直す（DBのテーブル構造は現行維持）
- 既存の機能やビジネスロジックは原則変更しない
- 2026年5月に「DODAIプロジェクト（Debt Of Decades + AI）」としてキックオフ
- 目標: 2027年5月の30周年に間に合わせること
■ 3. 独自AIワークフローの全体像と設計思想
- 5つのフェーズ × 3層のAIエージェント実行レイヤで構成:
- Phase 1: 現行システム分析（既存コード・ドキュメントから画面・遷移・業務ルール・URL/APIを抽出しドキュメント化）
- Phase 2: アーキテクチャ設計（ADRとして出力、人間レビューと対話による調整が必須）
- Phase 3: 詳細仕様設計（API・UI・業務ルールをOpenAPI等の実装可能な粒度まで具体化）
- Phase 4: 実装（Phase 3の仕様書に基づき、Phase 2で定義したアーキテクチャでコード+ユニットテストを実装）
- Phase 5: 受入テスト（新システムが現行システムと機能的に同等であることをE2Eテストで検証）
- 各フェーズでオーケストレータが全体を統括し、Step GroupがサブエージェントをKickする構造（サブエージェントは合計71体）
- AIワークフローの設計思想（5点）:
- 長時間の自律実行: 人手の監視なしにAIが動き続ける
- 高いコンテキストスケーラビリティ: サブエージェントは単独役割で必要な文脈のみを保持し性能を維持する
- 現行システムを正解とする: 既存コードとドキュメントを唯一の信頼できる情報源として仕様を正確に再現する
- 自律的な改良機構: 失敗や誤りを検知し自力で修正するサイクルを実行する
- 工程ごとの品質評価: 各工程にQAプロセスを設け通過・非通過を判定する
■ 4. AIワークフローの成果と品質保証
- 2026年5月時点の成果（保険カテゴリ）:
- 実行時間: 134時間
- 実行コスト: $6,921
- 総生成コード: 約3.6万行
- サブエージェント呼び出し回数: 1,959回
- 対象ページ数: 88
- 生成E2Eテストケース: 5,629個
- 新旧コードの規模比較:
- ウォーターサーバー: C#/ASP実装コード 7,058行 → Python実装コード 7,796行（110.5%）
- クレジットカード: C#/ASP実装コード 29,215行 → Python実装コード 19,313行（66.1%）
- 保険: C#/ASP実装コード 67,931行 → Python実装コード 29,505行（43.4%）
- 新しいカテゴリほど削減幅が小さい傾向があり、古い実装や歴史的経緯から生じた偶有的複雑性にまつわるコードが削減されている
- Anthropicが示した5つの長時間稼働の失敗パターンへの対応:
- Context Rot（コンテキスト枯渇）→ 3層エージェント構造（作業単位ごとに文脈を分けフレッシュな状態で実行）
- Premature Completion（早期終了）→ 構造化された仕様書（AI向けに責務と粒度を揃え後続工程を安定化）
- Lossy Compaction（要約による情報損失）→ 工程単位の独立レビュー（実行とは別のAIが別の文脈で点検）
- Shallow Plans（粗い計画）→ 完了判定ゲート（自己申告に頼らず成果物とテストの通過を機械判定）
- Generous Self-evaluation（甘い自己評価）→ E2E自律改善ループ（現行と同等になるまで失敗を戻して自力修正）
- 品質保証の手段:
- 各Phase内:
- 仕様のトラッキング（現行仕様の各項目にIDを付与しPhase1〜4まで対応を追う）
- 決定論的チェッカー（プログラムで抜け漏れや逸脱を検査しAIの嘘を弾く）
- Phase 5（最終QA）:
- Docker実起動（プレースホルダ実装・汎用フォールバックなどによる抜け道実装を検出）
- E2Eテスト（Playwrightで現行と新システムを操作しDOM・表示・値が一致するかを検証）
- ディファレンシャルテスト（新旧のDOM・スクリーンショット・値の差分を抽出）
- 差分の対応分類（「修正対象 / 許容 / 環境起因」に分類）
- ワークフロー自体の観測と改善:
- Tracerによる実行時間・コスト・API呼び出し・サブエージェント数の計測・可視化
- AIワークフロー自己改善Skill（Issue化→調査・計画→実装→検証のサイクル）
- 移植性を確保し特定ツール（Claude Code、Codex等）に縛られない形へ
- 今後の課題:
- コスト: 設計者の月額AI利用料は440万円、さらなる拡大を見据えたコスト最適化が急務
- 品質: 内部品質（コード品質、テストカバレッジ）の向上と安定化
- 評価: ワークフロー自体の性能を測るベンチマークの整備
- 実行基盤: ローカル実行からクラウド実行（GCPオフロード）への移行
- 組織: AIの生産速度に人が追いついていない状況であり組織基盤の整備が必要
■ 5. 新システムの技術選定とアーキテクチャ
- 技術選定の要諦（事業特性から技術要件を導出）:
- サービス特性「広く、浅く」: カテゴリ数は膨大だがUI/UXはシンプル（検索・一覧・詳細・比較が中心）
- UI要件「シンプル」: 複雑なインタラクション（SPA）は不要、情報量や比較などで価値を出す
- 経営課題「売上拡大 & 費用圧縮」: 新規カテゴリ構築による成長が最優先、既存カテゴリの運用効率化で成長投資の原資を確保
- 採用技術スタック: Python + FastAPI + htmx
- Python選定理由:
- 人材採用の優位性: 利用人口が多く採用母集団が大きい
- エコシステムの充実: ネット上のソースコード・ドキュメントが豊富でAIコード生成精度も高い、OSSも充実
- AIとの親和性: 機械学習・生成AIの標準言語、Pydanticにより動的言語だが型安全な開発が可能
- FastAPI選定理由:
- 低い運用コストと学習曲線: マイクロフレームワークで機能が最小限、学習・アップグレードのコストが低い
- 必要十分な性能: 非同期処理（Async）に標準対応し高トラフィックに強い
- API設計の自動化: OpenAPI（Swagger）定義書が自動生成され、ドキュメント作成コストがゼロになり仕様の乖離も防ぐ
- htmx選定理由:
- 必要十分な機能: 「検索・一覧・フォーム」の動的更新にSPAは過剰、HTML属性だけで実現する適正技術
- 低コストな運用: JavaScriptの巨大なエコシステム（ビルド・依存）が不要、ライブラリ自体が軽量で保守コストが低い
- バックエンド主導の開発: APIと画面が分離せず一気通貫で開発でき、BE/FEといった分業の必要性が薄い
- アーキテクチャ: Vertical Slices Architecture（VSA）を採用
- カテゴリごとの独立性が高いため機能的な関心軸で分割するVSAと相性が良い
- スライスの中に関心事が集中する構造のため、コンテキストにも優しくAIとも相性が良い（検証中）
■ 6. システム改革を進めるための組織づくり
- 大規模なシステム改革が難しい理由: リーダーシップ（変化への対処）とマネジメント（複雑さへの対処）の両方を高い次元で同時に求められるため
- 推進者のマインドセット: 「楽観的に構想し、悲観的に計画し、楽観的に実行する」
- 構想: AIでまるごとリプレイスできるのでは？（楽観的に）
- 計画: コードの規模・複雑さ、AIと人の境界、再現の担保、AIの限界など起こりうるすべての問題を考え尽くす（悲観的に）
- 実行: 問題は必ず起きる、それでも必ず越えられると信じてやり切る（楽観的に）
- 推進において意図して取り組んだ5つの施策:
- ビジョンを掲げる: 「価格.comの次の30年を支える、新しい土台をつくる」というビジョンを設定。負債の返済を「次の30年」「新しい土台づくり」として前向きに捉え直し、「土台」をDODAIというプロジェクトコードに昇華
- 協業体制をつくる: PoC期はコンセンサスが固まる前のため各組織が独立して動ける疎な連携とした。キックオフ後はコンセンサスが固まったため組織を一つに束ね密に連携する体制へ移行。価格.com組織とCTO直下の双方の長をプロジェクト責任者として対等に配置
- 行動原則を据える: 4つの指針（オーナーシップを持つ、AIを中心に考える、部分最適をしない、過去を否定しない）を共有し、守りたい人・変えたい人がお互い歩み寄れる環境を整備
- 抵抗に向き合う: 現状維持を望む人は敵ではなく、向き合う先は事実と仕組みであるとする。原因を人ではなく仕組みに置く、結果で示す、事実で議論する、強いコミットメントを示すという4つのアプローチで対処
- キックオフで動き出す: 組織全体が本気で動き始めるための最もレバレッジの効く起点として位置づけ、キックオフ資料を約10回のレビューを重ねて磨き込み、トップのコミットメントを冒頭で宣言