iAEONアプリがサービスを止めずに挑む、Capacitor経由の段階的リアーキテクト

イオンスマートテクノロジー（AST）が開発・運用するイオンのトータルアプリ「iAEON」。会員コードの提示、決済、店舗検索、クーポン利用など、イオンの多岐にわたるサービスを1つのアプリで完結させるこのプロダクトは、リリース以降、急速にユーザー数と機能を拡大させてきた。

しかし、その急成長の裏側で、開発現場は既存アーキテクチャの構造的な限界に直面していた。古くなる技術スタック、数万行超のファイル、複雑に絡み合ったスパゲッティコード、そしてブラックボックス化した仕様──。

この課題に正面から向き合い、サービスを止めることなくアプリの基盤を作り替えるリアーキテクトプロジェクトが、いま進行している。Cordovaベースのハイブリッドアプリから、ネイティブとミニプログラムを組み合わせたモダンな構成へ。なぜ彼らは、止めないリアーキテクトを選んだのか。そして、その過程でどのような技術的判断を下したのか。プロジェクトを主導するAST iAEON開発ディビジョンの渡邉大樹に、プロジェクトの全貌を聞いた。

【目次】

「今後の成長に耐えうる土台作りを」──UXの限界と触れないネイティブコードへの焦り

きっかけはシンプルで、開発者としてもユーザー体験としても限界を感じていたからです。（渡邉）

iAEONアプリは、Cordovaを用いたWebView中心のアーキテクチャで構成されている。UI構築にはAngularとIonicが使われており、リリース当時は効率的なクロスプラットフォーム開発を実現していたものの、サービスの拡大とともに歪みが生じ始めていた。

まず、ユーザー体験の面で、WebView特有のもたつきが解消できなかった。画面遷移のレスポンスやスクロールの挙動など、ネイティブアプリの滑らかさと比べると、どうしても違和感が残ってしまう。しかし、それを改善しようにも、エンジニアの手が届かない領域が多くあったのだ。

Cordova構成における最大のボトルネックは、ネイティブ層がブラックボックス化しやすい点にある。ネイティブコードはフレームワークによって生成・管理されるため、開発者がSwiftやKotlinのコードを直接修正してパフォーマンスをチューニングすることが難しい。

課題はユーザー体験だけではなかった。外部ベンダーが構築したコードがそのまま残り、見通しの悪いコードベースの上で機能追加を重ねていく限界を、渡邉は開発者として実感していたという。

ネイティブではなくフレームワークを採用しているため、ビルド時間も長大化していました。これからも機能を追加し続けていくなら、この基盤では限界がある。将来の成長に耐えうる土台を作らなければならないという思いが強くなっていました。（渡邉）

ビッグバンではなく段階移行を選んだ理由

リアーキテクトの方針を検討する際、最初に議論の俎上に載ったのは、全体を一気に作り替えるビッグバン型のアプローチだった。しかし、iAEONの現実はそれを許さなかった。

iAEONはすでに多くのユーザーに使われており、ビジネス側からの機能追加要望も絶えません。「作り直すので1年間リリースを止めます」というのは、現実的ではなかった。何より、機能数が膨大になっている今、一気に作り替えるのはリスクが高いと判断しました（渡邉）

そこで採用されたのが、サービスを止めずに、段階的にネイティブ化していくという戦略だ。そのための重要な"架け橋"となる技術として、理想とするアーキテクチャを実現できる適切なフレームワークを選定した。既存のWebViewリソースを動かしながら、iOS/Androidのネイティブコードも同一プロジェクト内で扱えるメリットがある。

iAEONの実態は、Angularで構築されたWebViewアプリです。画面もロジックもすべてWebリソースの上に載っている構成なので、それを活かして移行できるフレームワークは今回選定したものだけでした。（渡邉）

こうして採用されたのが、3フェーズに分けた段階移行の戦略だ。

Phase 1：過渡期アーキテクチャへの移行──ネイティブへの"入口"を開く

WebViewの中身はそのままに、外側の基盤をCordovaから過渡期フレームワークへ載せ替える。これにより、ネイティブコード（Swift/Kotlin）を直接扱える開発環境を手に入れることができる。

Cordovaで構築された資産が過渡期フレームワーク上で本当に動くのか、事前にフィジビリティ調査を実施。Capacitor上でビルドを通し、MagicPodでテストを実行して問題がないことを確認したうえで、本格的な移行に踏み切った。

Phase 2：段階的置換──主要画面から順にネイティブ化

過渡期フレームワーク上でWebViewとネイティブの画面を混在させながら、ユーザーへのインパクトが大きい画面から順次ネイティブへ作り替えていく。並行して、変更頻度の高い画面はミニプログラム（WebView＋React）へ移行する。

Phase 3：完全移行──旧基盤を削除

すべての移行が完了した後、役目を終えたCordova、過渡期フレームワーク、Angularを完全に削除し、純粋なネイティブ＋ミニプログラムの構成へ移行する。

つまり、今回適用したフレームワークはあくまで通過点だ。最終的にはこちらも削除し、旧WebView依存を脱却したモダンなハイブリッド基盤へ移行する。段階移行を安全に進めるための、戦略的な中間地点として位置づけられている。

「ネイティブ × ミニプログラム」で、適材適所の技術選定

現在Phase 1の対応中で、準備が整い次第、Phase 2へと移行していく計画が進んでいる。ここで重要なのが、どの画面をネイティブにし、どの画面をWebのままにするか、という線引きだ。渡邉は「すべてをネイティブにするわけでも、すべてをWebにするわけでもない」と語る。

ネイティブで実装するのは、ホーム画面、支払いバーコード、起動処理、店舗検索など、ユーザーが日常的に触れ、体感速度や操作性がUXに直結する領域だ。一方、会員登録やログイン、マイページなどは、ミニプログラムとしてReactで実装する。ストア審査を経ずにサーバー側の更新だけで反映できるため、ABテストを含めた高速な改善サイクルが回せる。

頻繁に更新が必要な画面までネイティブで作ってしまうと、修正のたびにストア審査を通す必要があり、リードタイムが発生します。そこで、こうした画面は「ミニプログラム」として、WebView上で動くReactアプリケーションに置き換える方針を検討しています。（渡邉）

最終的な構成イメージは、ベースとなる基盤と主要導線がネイティブ（Swift/Kotlin）で実装され、その上で各機能モジュールがReact製のミニプログラムとして動く、いわゆる「スーパーアプリ」に近い形となる。

※各画面の実装方式は現時点の方針であり、今後ビジネス要件に応じて変更の可能性あり

仕様書なし、テストなし。数万行超のスパゲッティコードと向き合う

戦略はロジカルだが、現場での実行は困難を極める。最大の壁は、長年の運用で複雑化した既存コードの解析だ。

正直に言うと、ドキュメントや仕様書がほとんど残っていない機能も多くあります。長いところだと数万行を超えるファイルもあり、コードを見ても継ぎ足しで作られたスパゲッティ状態で、「これいらなくない？ でも必要かもしれない」と、判断がつかない。仕様がわからないことが、やはり一番の苦労です。（渡邉）

渡邉率いるリアーキテクトチームは、このブラックボックスに対し、AIと人の力を組み合わせて挑んでいる。GitHub CopilotやClaudeといった生成AIツールをフル活用し、難解なコードの挙動を解析。それでもわからない部分は、有識者を探し出してヒアリングを重ねる。渡邉は「最後は自分たちでコードを読み解き、現在の挙動を事実ベースで洗い出すしかない。地味で泥臭い作業ですが、ここを避けては通れません」と話す。

MVPアーキテクチャ、テストコードの導入──品質と効率を「仕組み」で支える

既存コードの解析に苦労しているからこそ、新しく作る基盤では、品質と可読性の担保にこだわった。

まずは、MVPアーキテクチャを採用した。View（画面表示）、Presenter（仲介）、Model（ロジック・データ処理）の3層に責務を分離する設計だ。この選択には、iAEONアプリのようにネイティブとWebが混在する環境下でも、ロジック（Model）と表示（View）をきれいに分離し、共通のロジックを再利用しやすくする狙いがある。

テストコードの導入も重要な柱だ。現行アプリにはテストコードがほぼ存在せず、わずかな修正でも画面からの手動テストで品質を担保するしかなかった。そこで現在は、「テストコードを書くこと」を文化として根付かせようとしている。

これまでは、わずかな修正であっても手動テストに多くの時間を取られていました。新しい基盤ではロジック層へのテストコード実装を標準とし、安心して変更できる状態を目指します。AIによるテストコード生成も活用することで、品質と開発効率の両立を図っていく方針です。（渡邉）

技術スタックはiOS側がSwift/SwiftUI、Android側がKotlin/Jetpack Composeで、いずれもモダンな標準技術を採用。Linter/FormatterやCIによる自動テスト実行の仕組みも整備し、品質担保を人の注意力ではなく、仕組みに移行させている。

正解は自分たちで決める。カオスを楽しみ、理想を実装する現場

2026年初頭、それまで通常案件と兼務で進められていたリアーキテクトプロジェクトは、より実行力を高めるために体制を強化した。渡邉、そして業務委託メンバーを含む6名のエンジニアがこの難題に集中して取り組んでいる。

これまではどうしても目の前のリリース案件にリソースを取られ、リアーキテクトが後回しになりがちでした。今はビジネス側の理解も得て、専任に近い体制で動けています。チームのメンバーは、元々Webが得意な人もいれば、ネイティブが得意な人もいますが、領域を区切らずフラットに開発しています。（渡邉）

実際に、iOSとAndroidで担当を分けず、Swift、Kotlin、Reactと幅広い技術に横断的に触れられる環境がある。AI活用にも積極的で、CopilotやClaudeといったツールを制限なく利用でき、プルリクエストをトリガーにしたドキュメント自動生成など、開発プロセスそのものにAIを組み込む取り組みも進めている。

エンジニアとしては、一番おもしろいフェーズだと思います。ただコードを書き換えるだけでなく、「なぜこの設計にするのか」を自分たちで決められる裁量がある。苦労も多いですが、CI/CDの整備など、コードを書く以外の領域にも幅広く携われており、新しい技術で理想的な環境を作っていくワクワク感のほうが強いですね。（渡邉）

スパゲッティコードを読み解く地道さと、新しい基盤を自分たちの手で設計できる自由度。その両面が、このプロジェクトにはある。完璧な設計を待つのではなく、サービスを止めずに、作りながら安全に変えていく。そのプロセスを楽しめるエンジニアにとって、iAEONのリアーキテクトは、技術力とプロダクト思考の両方が試されるまたとない挑戦の場だ。渡邉は、このリアーキテクトプロジェクトに向いている人物像についてこう語る。

自律的に動ける人が向いていると思います。リソースが潤沢にあるわけではないので、つきっきりで教えてもらえるような体制ではありません。でも逆に言えば、「ここは変えたほうがいい」「こっちのほうがいい」と自分で意見を出して動ける人にとっては、とても良い環境です。やりたいことはやらせてもらえるし、チームはフラットで上下関係もない。指示されて動くというよりは、フラットに一緒に取り組んでいこうという空気が合う人は、やりやすいと思います」（渡邉）

リアーキテクトの先に見据えるもの

現在進行形で進むiAEONアプリのリアーキテクト。2026年内に、主要画面のネイティブ化+ミニプログラムの初回リリースを実現することを目指し、現場は熱気を帯びている。この長い旅路の先に、渡邉はどのような未来を描いているのか。

まずは何より、ユーザー体験の劇的な向上です。アプリを開いた瞬間の起動速度、バーコードが出るまでの速さ。これらが当たり前に速くなるだけで、ユーザーのストレスは消え、利用頻度は上がるはずです。そしてエンジニアにとっては、「変わり続けられる基盤」が手に入ることが最大の成果です。テストがあり、設計が整理され、モダンな言語で書かれている。AIも活用して、欲しい機能をすぐに実装できる。そんな健全な開発環境があれば、iAEONはビジネスの変化に合わせて、もっと速く、どこまでも進化していけるはずです。（渡邉）

「止めずに作り替える」という難題への挑戦は、単なるシステムの刷新ではない。国内最大級の小売アプリが、テクノロジーの力で次のステージへと生まれ変わるための、必然の進化なのだ。

イオングループでは一緒に変革に挑んでくれる方を募集中です。

どんなことをしているのか気になる方は、お気軽にご連絡ください。カジュアル面談も実施しておりますので、まずはざっくばらんにお話しましょう！