これはAIとの対話をもとにした公開メモです。
近年、日常的にAIツールで相談する回数が増えていますが、その内容の中には非常に有益に感じるものも多くなってきました。
そのやりとりをAIツール内のみに残したままだと、後から振り返りにくいし、もったいない。
そこで気になった話題への質問と回答をブログ上に記録することにしました。必要に応じて、関連リンクや画像、Xの投稿なども補足として添えています。
使用AI：ChatGPT
使用バージョン：GPT-5.5 Thinking
なお、AIの回答には未確認の情報や解釈が含まれる場合があります。必要に応じて、公式情報や一次情報もあわせて確認してください。
Contents
今回の質問
Xで見かけた話題の投稿で、かかくこむのAIを使った既存システムの刷新について元ネタの内容を読んでみました。なるほど、AIを使えばこれまで手付かずになってしまいどうすることもできなかった800万行のコードも型をつけることができるわけか、、、詳しい内容はまだあまり読み込めていない、、、読んだ方がよいのだろうか、、、 的な状態です。
いったん知識として押さえておきたいです。興味を持ったので。 というのも、自分も最近AI使って小さい部分からブログ記事システム刷新を進めているので、そんな意味で興味を持った。 Claudeの最新民生版がつい先日発表されたばかりだし。
ただ、個人でAI開発するにしても、依然としてコストの問題は残り続けるのではないかと。そこがハードルだな。
AIの回答
これは読んだ方がよいです。ただし、全部を精読するというより、読むべきポイントはかなり絞れます。
結論から言うと、この資料の本質は「800万行のコードにAIで型を付けた」話ではなく、レガシーシステムをAIに“丸投げ”するのではなく、AIが失敗しにくい工程・検証・組織を設計した話です。ここが非常に重要です。
まず押さえるべき核心
価格.comの現行システムは、C#とClassic ASPが混在するWindows系システムで、C#コード約800.9万行、ASPコード約161万行、テーブル13,210、画面1,353、バッチ498という規模です。つまり合計では約960万行級です。資料では、この30年分の技術的負債を返す「DODAI」プロジェクトとして、アプリケーションとインフラをフルスクラッチで書き直す一方、DB構造や既存機能・ビジネスロジックは原則維持する方針が示されています。(Speaker Deck)
ここで大事なのは、仕様を変えて新サービスを作るのではなく、現行システムを“正”として再実装するという点です。要するに、古い家を眺めながら「間取りは変えずに、柱・配線・水回りを全部やり直す」ような話です。建築士が聞いたら軽く膝を抱えるやつです。
何がすごいのか
一番すごいのは、AIを単なる「コードを書く道具」として使っていないことです。
資料では、AIワークフローを「現行システム分析 → アーキテクチャ設計 → 詳細設計 → 実装 → 受入テスト」の5フェーズに分け、さらにオーケストレータ、Step Group、サブエージェントという3層構造にしています。サブエージェントは合計71体。既存コードとドキュメントをもとに、AIが仕様を抽出し、新しい言語・アーキテクチャで再実装していく構造です。(Speaker Deck)
つまり、AIに「このシステムを刷新して」と頼んだのではありません。
AIが作業できるように、作業の分解・責務・検証・完了条件まで人間側が設計したわけです。
ここが、個人開発にもそのまま効きます。AI活用で成果が出る人と出ない人の差は、モデルの賢さよりも、だいたいここです。
さらに重要なのは「AIを信じていない」こと
この資料で非常に健全だと思うのは、AIの出力を信用しすぎていない点です。
同じ挙動を保証するために、仕様項目にIDを付けてPhase 1〜4まで追跡し、最終的には新システムを実際に動かして検証しています。さらに、決定論的チェッカー、Dockerでの実起動、旧新DOM・スクリーンショット・値の差分比較、PlaywrightによるE2Eテストなどで、AIの嘘や手抜き実装を弾く仕組みにしています。(Speaker Deck)
これはかなり本質的です。
AI開発で怖いのは、
「できました！」
「動きます！」
「完全に対応しました！」
と言いながら、実はプレースホルダーだったり、例外ケースを握りつぶしていたり、既存仕様と違っていたりすることです。
なので、この資料の教訓はこうです。
AIに作らせるなら、AIに検証までさせる。ただし、検証基準は人間が設計する。
この考え方は、ダニエルさんのWordPress・ブログ記事システム刷新にもそのまま使えます。
コストの話は、やはり重いです
ここは冷静に見た方がよいです。
資料では、保険カテゴリの構築で、AIワークフローの実行時間134時間、実行コスト$6,921、サブエージェント呼び出し1,959回、対象ページ88、生成E2Eテストケース5,629個という結果が示されています。さらに今後の課題として、設計者の月額AI利用料が440万円で、コスト最適化が急務だと書かれています。(Speaker Deck)
つまり、夢のように見える一方で、AIでコストが消えるわけではありません。
人件費・時間・属人性の一部が、AI利用料・検証設計・ワークフロー運用・FinOpsに置き換わっている、という見方が正確です。
個人開発では特にここが現実的な壁になります。Claudeの個人向けプランは月額サブスクリプション型ですが、APIはトークン単位の従量課金です。重いエージェント処理や長時間自律実行をAPIで回すと、サブスク感覚とは別物になります。公式のClaude料金ページでも、個人向けProは月額$20、APIはモデルごとに入出力トークン単価が設定されています。(Claude)
なので、個人でやる場合の現実解はこれです。
AIに長時間走らせる前に、作業範囲を小さく切る。
テスト・確認ポイントを先に決める。
高性能モデルを常用せず、設計・実装・レビューで使い分ける。
API課金を使う場合は上限を決める。
ここをやらないと、AI開発は「便利なはずなのに、財布だけが先にリファクタリングされる」状態になります。
ダニエルさんのブログ刷新に置き換えるなら
今回の価格.comの話を、個人のWordPress・ブログシステム刷新に縮小すると、こうです。
まず、現行仕様をAIに読ませる前に、自分で仕様の棚卸しを作るべきです。
たとえば、
「路線図記事にはどんなショートコードがあるか」
「駅カードにはどんな項目があるか」
「一覧表と駅カードはどう連動するか」
「クリック時にどこへスクロールするか」
「PC/SPで見た目がどう違うか」
「どこまでを既存維持し、どこからを刷新するか」
このように、先に“現行システムの地図”を作る。
そのうえでAIに「この仕様を壊さずに、CSS構造を整理して」「このショートコードを責務ごとに分けて」「このJSの挙動を安定化して」と頼む。
カカクコムの巨大版DODAIに対して、ダニエルさんの場合はミニDODAIで十分です。名前は少し大げさですが、個人事業主は大げさな名前をつけた方が動けることがあります。地味な作業に旗を立てるのは、案外ばかにできません。
読むなら、ここだけでよいです
全部を読むより、まずは以下を押さえるのが効率的です。
スライド10〜12：現行システムの規模と刷新スコープ
スライド15〜23：AIワークフロー、品質保証、コスト、課題
スライド25〜30：Python / FastAPI / htmx / VSA の技術選定
スライド33〜39：大規模改革を進めるためのマインドセットと組織論
特に個人開発目線では、スライド15〜23が一番おいしいです。
ここは「AI時代の開発作法」として読めます。
私の見立て
これは、AI開発の未来というより、かなり現実的な資料です。
派手に見える部分は「960万行級のレガシー刷新」ですが、本質はもっと地味です。
仕様を明文化する。
作業を分割する。
AIの出力を疑う。
差分で検証する。
コストを測る。
人間は判断と設計に集中する。
つまり、AI時代になっても、雑に作ったものは雑に壊れます。
ただし、きちんと土台を作れば、これまで個人では重すぎた刷新作業にも手が届くようになってきた。そこが希望です。
ダニエルさんの場合も、AIに「ブログ全体を刷新して」と投げるのではなく、まずは路線図記事システム、駅カード、関連記事カード、一覧表、JS挙動のように、小さな単位で“仕様化 → 実装 → 差分確認”を回すのがよいです。
この資料は、読む価値があります。
ただし、読むべきなのは「すげえ、AIで全部できる」ではなく、**「AIに任せるために、人間は何を整えるべきか」**です。
