既存のEC・決済基盤を、組み替えられるシステムへ再設計する
機能追加を重ねるうちに、API・コード・DB・仕様の関係が追いにくくなっていた自社EC。SophiaRealは全面刷新ではなく、AIで既存システムを読み解き、機能を再利用できるブロックとして整理する AI BLOCK ARCHITECTURE を設計しました。独自の決済基盤へ発展させられる構造をつくりながら、アジャイルで小さく実装と検証を繰り返し、稼働中のシステムを止めずに段階的な更新を続けています。
全部を作り直さない。全部を、組み替えられる状態にする。
デザイン家電やライフスタイルプロダクトを企画し、製造を外部パートナーへ委託しながら、自社ECを中心に販売している企業です。事業の成長に合わせて、会員、キャンペーン、在庫連携、配送、保証、決済といった機能の追加を長年続けてきました。 一つひとつの改修は、そのときに必要なものでした。ただ、追加のたびに仕様書や要件定義書も継ぎ足されていき、やがて「どのAPIがどの処理につながっているのか」「このDB項目を変えるとどこへ影響するのか」を一枚の設計図で説明できない状態になっていたといいます。 そこへ、自社ECを販売サイトから発展させ、複数の決済手段や新しいサービスを束ねる独自の決済基盤へ拡張する構想が生まれます。実現には、機能を足す前に、既存システムを安全に変更できる構造そのものをつくり直す必要がありました。
改修するのは機能ではなく、「変更できる構造」そのもの。
この案件で全面刷新を選ばなかったのには理由があります。 既存システムには、長年の運用を通じて積み上がった業務ルールがあります。複雑だからといってすべてを捨てれば、コードだけでなく、会社固有の判断や例外処理まで失いかねません。一方で、既存コードへそのまま機能を足し続ければ、次の変更はさらに難しくなります。 そこでSophiaRealは、システムを新旧の二択で考えるのをやめ、機能ごとに切り分けて再構成する AI BLOCK ARCHITECTURE を設計しました。
仕様書を整え直しても、開発が続けば実装との差はまた開く。
API一覧や設計書を一度きれいに書き直すことはできます。しかしそれは、その時点の写しでしかありません。開発が続けば実装との差は再び広がり、数年後に同じ調査をやり直すことになります。 必要だったのは、現状を一度整理することではなく、コード、API、DB、業務仕様の関係を継続的に追える仕組みでした。
AIで読み解く。ブロックで分ける。RAGでつなぐ。アジャイルで変え続ける。
AIに任せたのは、コードを書き換えることではなく、システムの関係を読み解くことです。 API、ソースコード、DB、既存資料、テスト、ログを横断して依存関係を整理し、「この機能は何を担い、何に依存し、どこから利用されているか」を把握できる状態をつくります。そのうえで機能を独立性の高いブロックへ整理し、変更の影響範囲を確認しながら一つずつ実装していきます。 一括で完成させてから切り替えるのではなく、小さく作り、小さく出し、実際の利用から次の仕様を決める。アジャイルを採用したのは、この進め方を成立させるためでした。
読み解く、分ける、つなぐ、試す。改修そのものを開発基盤に変える。
既存システムを止めずに改修するため、構造の理解、ブロック化、AIとRAGによる知識化、段階的な実装を並行して進めました。実利用から得た情報を次のスプリントへ戻しながら、改修のたびにシステム全体が整理されていく構造をつくっています。
AIで、継ぎ足されたシステムの全貌を読み直す。
最初に着手したのは、新機能の開発ではなく、現行システムの把握でした。 API、ソースコード、DBスキーマ、外部サービス連携、バッチ処理、画面、既存仕様書、過去の要件資料を集め、AIを使って関係性を整理していきます。 どのAPIがどのコードから呼ばれているか。どのDBを読み書きしているか。どの画面や外部サービスが依存しているか。変更した場合にどこへ影響する可能性があるか。 人が一つずつ資料を読み直して設計書を復元するのではなく、AIをシステム解析の補助として使い、エンジニアが確認できる形へ構造化しました。 人が判断するために必要なシステムの地図を、AIでつくる。 そこから始めています。
API・コード・DB・仕様を、一つの「ブロック」として整理する。
次に、システムを技術ファイル単位ではなく、業務機能単位へ分け直しました。 商品、会員、カート、注文、決済、キャンペーン、配送、返品、保証。それぞれを一つのブロックとして扱います。 各ブロックには、API仕様だけでなく、関連するコード、利用DB、依存先、業務上の役割、表示される画面、テスト、既知の制約までを紐づけました。これを BLOCK LIBRARY として蓄積していきます。 動いているコードの集合を、どこを変えればよいか理解でき、次の開発でも再利用できるシステム部品へ変えていく作業です。
独自RAGで、変更する前に影響範囲を探せる状態にする。
BLOCK LIBRARYに、既存仕様、API、DB情報、テスト、障害履歴、過去の改修内容を接続し、開発者向けのRAGを構築しました。 たとえば「新しい後払い決済を追加したい」という要求が出たとき、関連する決済APIだけを見て済ませることはできません。ORDERとの関係、返品処理への影響、関連DB、既存テスト、過去に決済を追加したときに変更した箇所まで、横断して確認できるようにしています。 このRAGが担うのは、APIの自動的なつなぎ替えではなく、判断材料の提示です。どのブロックを使い、どこへ影響しうるかを、人が決められる形で差し出す知識レイヤーとして設計しました。 新しい決済サービスや機能を追加するたびに、システム全体をゼロから調査し直す必要を減らしていく仕組みです。
アジャイルで、ブロック単位に小さく置き換える。
アジャイルを選んだのは、開発の順序を事業の側から決めるためです。 全貌が複雑な既存システムでは、最初にすべての仕様を確定して一括改修すること自体がリスクになります。そこで、事業インパクトと依存関係を見ながら、改修対象を小さく切り出しました。 最初にPAYMENT、次にORDERというように順序を決め、一つのブロックを実装したら限定した利用範囲で動かします。そこで既存処理との整合、購入画面や管理画面の操作性、障害、想定していなかった例外を確認し、結果を次のバックログへ戻して優先順位と仕様を更新していきました。 切り出す → つくる → 限定して出す → 使われる → 次の仕様へ戻す この短いサイクルを繰り返し、問題があれば戻せる状態を保ったまま、旧機能を一つずつ置き換えています。完成形を予測して一度に作るのではなく、実際に使われた事実から次の開発を決めるための進め方です。
この事例で組んだ専門性とフェーズ
既存システムの解析だけでも、新機能の実装だけでもありません。現行業務と技術構造の把握、AIによる依存関係の整理、アーキテクチャ設計、API・DBの再構成、RAGによる開発知識基盤、アジャイル開発、段階リリースと検証までを、一つの改修プロジェクトとして扱いました。
既存EC・決済システムの現状分析、API・コード・DB・外部連携の依存関係整理、AI BLOCK ARCHITECTUREの設計、BLOCK LIBRARYの構築、開発者向けRAG、API・データ構造の再構成、新しい決済・EC機能の実装、購入画面と管理画面のUI改善、アジャイルによるバックログ管理、段階リリース、検証、旧機能からの切り替えまで。既存資産を活かしながら、継続的に変更できるシステムへ移行した範囲です。
システムを改修するたびに、次の改修がしやすくなる。
このプロジェクトが目指したのは、新しいECや決済機能を一度完成させることではありませんでした。長年の追加改修で見えにくくなっていたシステムを、AIで理解でき、ブロック単位で変更でき、実際の利用から次の開発を決められる構造へ変えています。
動いているシステムほど、全部を作り直す必要はありません。
既存のコードやデータを活かしながら、API・機能・DBの関係を整理し、変更しやすい構造へ段階的に移行します。AIを使った既存システムの解析、アジャイルによる機能追加、API連携、UI改善まで、現行業務を止めない改修を設計・実装します。