この記事の対象者 コーディングエージェントをローカルで構築したい方 GPU環境(筆者はRTX 3060(VRAM 12GB))をお持ちの方 Windows環境で実装したい方 ※本記事で紹介するツール・モデルの評価は執筆時点の検証結果に基づくものであり、利用にあたっては各組織のセキュリティポリシーおよび利用規約をご確認ください。 はじめに 近年Codex、Claude Codeなど多様なコーディングエージェントアプリが出ており、コーディングエージェントを誰でも試すことができる時代になりました。 一方で、投入してたコードや指示は学習用途で使われるケースもあり、セキュアな内容の取扱

こんにちは。ファインディ株式会社でモバイルエンジニアをしている加藤です。技術カンファレンス向けのモバイルアプリ「Findy Events」を、React Nativeで開発しています。iOSは App Store 、Androidは Google Play で公開しています。 2026年9月11日から13日にかけて開催された iOSDC Japan 2026 に参加し、ファインディのブースにも立ちました。ブースでは、日ごとに設問を変えたアンケートを実施しました。 Findy Eventsの開発ではAIを積極的に使っていますが、UIやテストをどこまで任せるかは、今も考え続けているテーマです。クロスプラットフォームで開発している立場としては、iOSとAndroidでどこまでを共通のコードにするかも気になっています。今回のiOSDCでは、この2つを頭に置きながらセッションを聴きました。 この記事では、アンケートの結果と聴いたセッションの内容を紹介し、カンファレンスアプリを作る立場から、AIに任せる範囲とOS間で共有する範囲について考えたことを書きます。同じようにどこに線を引くかを考えているモバイルエンジニアの方の参考になれば嬉しいです。 iOSDC Japan 2026とは ファインディのブース アンケートで聞いた「人間が学ぶべきこと」 2つのセッションから考える、AIに任せる範囲 AI時代におけるiOS設計の守り方と人間の役割 スマホアプリ開発におけるハーネスエンジニアリングの取り組み Findy Eventsの開発に照らして感じたこと KMPの事例から考える、OS間で共有する範囲 Kotlin Multiplatformを軸にした求人アプリ全面リニューアルの技術戦略 Findy Eventsの技術選定に照らして感じたこと まとめ iOSDC Japan 2026とは iOSDC Japan 2026は、iOS関連技術をコアのテーマにした、ソフトウェア技術者のためのカンファレンスです。有明セントラルタワーホール＆カンファレンスでの現地開催と、ニコニコ生放送での配信を組み合わせたハイブリッド形式で、3日間にわたって開催されました。会場には、ロゴとアイコンのモザイクをあしらった大きなバナーが掲げられていました。 iosdc.jp ファインディのブース ファインディはゴールドスポンサーとして協賛し、ブースを出展しました。ブースの企画は、DevRelチームが事前に公開した次のnote記事で紹介しています。 note.com ファインディのDevRelチームは、エンジニアのスキルアップやキャリアを応援する方針で活動しています。生成AIの普及で学び方が変わってきている中で、これからのコンテンツ企画の参考にするために、エンジニアの学び方や情報収集をテーマにしたアンケートを企画しました。 ブースでは、日ごとに異なる設問をボードに掲示し、シールや付箋で回答していただきました。 この記事では、このうち私が担当した9月12日の結果を紹介します。 アンケートで聞いた「人間が学ぶべきこと」 「AIがコードを書く時代に『人間が学ぶべきこと』」という設問で、9の選択肢に513枚のシールが集まりました。当てはまる選択肢にシールを貼っていただく形式で、1人で複数の選択肢に貼っていただいた場合もあるため、次の表の数は回答者数ではなくシールの枚数です。 順位 選択肢 シールの枚数 シール全体に占める割合 1位 企画、要件定義、プロダクト設計 125枚 24.4% 2位 ビジネス理解、ステークホルダーコミュニケーション 113枚 22.0% 3位 アーキテクチャ、ドメインモデリング 74枚 14.4% 4位 UI/UX、アクセシビリティ 62枚 12.1% 5位 品質保証、テスト設計 47枚 9.2% 6位 セキュリティ設計、脅威モデリング 37枚 7.2% 7位 開発プロセス、チーム開発（CI/CD、レビューなど） 26枚 5.1% 8位 パフォーマンス、スケーラビリティ設計 14枚 2.7% - その他 15枚 2.9% 特にシールの集まった選択肢は「企画、要件定義、プロダクト設計」と「ビジネス理解、ステークホルダーコミュニケーション」の2つで、この上位2つを合わせると238枚、全体の半分近く（46.4%）になりました。AIがコードを書く時代に学ぶべきこととして、何を作るかを決めることや、関係者と話して合意をつくることを選んだ方が多かった、という結果です。 ボードの前では、選んだ理由も聞かせていただきました。上位の2つに共通していたのは、「AIだけで済むイメージがわかない」という声です。企画や要件定義については、「何を狙っていくのか、どんなプロダクトを作るのかという判断は人がやるのではないか」という意見でした。ビジネス理解については、他社のプロダクト開発に依頼を受けて共同で取り組んでいる立場の方から、「相手の事業を理解するほど、より良いものを一緒に作れる」という話を聞きました。一方で、「これはAI時代に始まった話ではなく、昔から大事だった」という意見もありました。 AI時代のエンジニアの越境、つまりコードを書くことにとどまらず、企画やビジネスの領域まで関わっていくことは、最近よく話題になります。ブースで話していても、そこを意識している方が多い印象を受けました。 2つのセッションから考える、AIに任せる範囲 ブースで話した方からも、「UI/UXやテストはAIに任せにくい」という声を聞きました。モバイルアプリでは実機やシミュレータで確認するハードルが高く、そのすべてをAIに任せるのは難しい、という話です。冒頭に書いたとおり、これはFindy Eventsの開発でも気になっているところです。AIを使った開発を扱ったセッションの中から、この点に通じるところがあった2つを紹介します。 AI時代におけるiOS設計の守り方と人間の役割 9月12日にTrack Bで行われた、株式会社TVerの遠藤拓弥さんのセッションです。 fortee.jp TVerのiOSアプリでの試行錯誤をもとにした内容で、AIは速いものの、今の時点ではまだ任せきれず、人の判断が必要だという話でした。 任せきれない理由として挙がっていたのは、AIにはできない判断があることです。1つは、バグと仕様の識別です。AIは全体ではなく近くのコードを手本にするため、既存のコードにバグがあると、それを仕様として扱ってしまうことがあります。もう1つは、SwiftUIとUIKitのどちらを採用するかという判断です。特定のOSバージョンではSwiftUIが期待どおりに動かないといった事情を踏まえて、どちらを使うかを決めることは、AIには難しいとのことでした。 こうした課題に気づいたタイミングでAIのガードレールを整備し、効率化を進める取り組みを続けているそうです。たとえば、アーキテクチャのガイドラインを定めたり、人が決めた内容をCLAUDE.mdやFigmaに残したりしています。 スマホアプリ開発におけるハーネスエンジニアリングの取り組み 9月12日にTrack Bで行われた、株式会社カカクコム（食べログ）の原隆幸さんのセッションです。 fortee.jp 食べログのアプリ開発チームは、「アプリ開発を誰でもできるようにする」というミッションのもとで、AIが正しく動ける土台づくりを進めています。タイトルにあるハーネスエンジニアリングは、この土台にあたる開発環境や情報の整え方を指します。セッションでは、プロダクトごとのワークスペースの構築や、CLAUDE.mdを継続的に改善する運用、ドメイン知識やテスト項目の整備などが紹介されました。 AIに渡すコンテキストは量より質を重視し、単一の信頼できる情報源（SSOT）を保つという話があり、改善を回し続ける仕組みも含めて、フィードバックループを強く回している印象を受けました。テストでは、MaestroによるUIテストの自動実行で手動QAを減らしていて、テスト項目の作成にもAIを使う取り組みを進めているそうです。 Findy Eventsの開発に照らして感じたこと Findy Eventsの開発でも、テスト項目の作成にAIを使っています。Issueの要件やFigmaのデザインをもとにAIへ作らせ、各項目には関係するGitHubのコミットも載せています。ほかの現場でも同じようにテスト項目の整備にAIを使っていると聞けたのは、心強く感じました。 一方で、AIが近くのコードを手本にしてバグを仕様として扱ってしまうという話は、歴史のあるアプリだからこそ直面する課題のように感じました。Findy Eventsは初回リリースからまだ日が浅く、実装と食い違う説明や古い記述もそれほど溜まっていません。AIが指摘や書き方の統一を提案してくれる場面が多いのも、そのおかげかもしれません。歴史が積み重なった先で向き合うことになる課題を先に知れたのは、参考になりました。 KMPの事例から考える、OS間で共有する範囲 AIの話とは別に、クロスプラットフォームで開発している立場から聴いたセッションです。 Kotlin Multiplatformを軸にした求人アプリ全面リニューアルの技術戦略 9月13日にTrack Cで行われた、ディップ株式会社の宮川昌高さんのセッションです。 fortee.jp スライドも公開されています。 speakerdeck.com 事業戦略とアーキテクチャのズレを解消するために、24年続くアルバイト求人サービスのiOSアプリを全面リニューアルしている事例です。 Kotlin Multiplatform（KMP）を採用した背景には、アプリ間で差異が生まれるという課題がありました。iOSとAndroidのチームがそれぞれ業務ルールやトラッキング要件を理解し、実装とテストをしていたためです。そこで、共有する領域を柔軟に選べること、UIは各OSのネイティブ実装を維持できること、社内のKotlin経験者の知見も活かせることから、KMPを選んでいます。 KMPを採用すると、iOSエンジニアもKotlinのコードに触れることになります。それでも、KMPを変更するPull Requestの約4割をiOS開発者が起票しているそうです。iOSとAndroidの開発者が一緒に保守できていると感じる数字でした。 一方で、iOSにKMPを組み込む中では、KMPからexportされた型をSwiftコンパイラがSendableとして検証できないという、Swift Concurrencyとの境界の課題も見つかったそうです。それでも、アプリ間の差異やメンテナンスの負担を解消するためのトレードオフとして、この課題を受け入れる判断をしていました。 Findy Eventsの技術選定に照らして感じたこと Findy Eventsは新規アプリとして立ち上げ、「最小リソースで最速リリース」を前提にReact Nativeを選びました。決め手は、ReactとTypeScriptの素養を持つメンバーが多い組織のアセットと、iOSとAndroidのプラットフォーム特性を理解しているモバイルエンジニアとしてのナレッジです。 KMPの事例でも、社内のKotlin経験者の知見を活かせることが選定理由に挙がっていました。選んだ技術は違っても、組織が持っている知識を活かすという観点は共通していると感じました。 まとめ 今回のiOSDCで肌で感じたのは、コードを書くことのAI化は確実に進んでいて、人がメインで担う領域が、コードを書く前の工程へ移ってきているということです。ブースのアンケートで上位に挙がったのは、企画や要件定義、ビジネス理解でした。 ただ、そこで大事だと言われていることの多くは、AI時代に始まった話ではありません。何を作るかを決めることも、関係者と話して合意をつくることも、昔から大事でした。AIがコードを書くようになったことで、コードを書くことに使っていた時間が空き、その分が手前の工程に使われるようになった結果、その工程に改めて意識が向くようになったのだと思います。 Findy Eventsの開発でも同じ課題感を持っていたので、ほかの現場の方から話を聞けたのは収穫でした。KMPの事例のように、技術選定もまた、組織やプロダクトの前提を踏まえて人が決める判断です。アンケートの9つの選択肢を自分のチームに当てはめて、いまAIに任せている範囲と人が担っている範囲を並べてみると、次に手を入れる場所が見えてくるかもしれません。 最後に、iOSDC Japan 2026を運営してくださった実行委員会とスタッフの皆さま、登壇者の皆さま、そしてブースでアンケートに答えてくださった皆さまに感謝申し上げます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに こんにちは、EC基盤開発本部SRE部でテックリードを務めている杉山です。 ZOZOでは、長年運用してきた基幹システムを新しいアーキテクチャへリプレイスする取り組みを進めています。新システムではAPIにJava、フロントエンド＋BFFにReact（TypeScript / Node.js）を採用し、インフラはKubernetes上に構築しています。 2025年11月に開催されたファインディ株式会社主催の「アーキテクチャConference 2025」では、「巨大モノリスのリプレイス──機能整理とハイブリッドアーキテクチャで挑んだ再構築戦略」と題して発表しました。基幹システムの課題と、アーキテクチャの方向性を紹介した内容です。 findy-tools.io その中で、基幹フロントエンドリプレイスについても触れています。既存システムと新システムを共存させながら、Kubernetes上で機能ごとにパスルーティングし、段階的に置き換えていく構想です。 しかし、当時このアーキテクチャはまだ「予定」でした。実現するためには、既存システムが長年抱えてきたある制約を取り除く必要があったためです。 それが、Webサーバーがユーザーセッションを保持する「ステートフル」な構成です。 本記事では、既存システムのIISが保持していたセッションをRedisへオフロードし、Webサーバーをステートレス化するまでの取り組みを紹介します。それによって基幹システムの段階的なフロントエンドリプレイスを進められるようになった背景にも触れます。 目次 はじめに 目次 基幹フロントエンドリプレイスの構想 新アーキテクチャを用意するだけでは移行できない 段階的リプレイスを阻んだIISセッション 認証だけではないIISセッションへの依存 認証をOIDC化するだけでは解決できない リプレイスの前に「状態」を切り離す IISセッションをRedisへオフロードする Before / After 独自フレームワークを変更した理由 セッションIDの引き回し シリアライズ方式と互換性 更新タイミングとエラー時のロールバック セッション期限管理の設計 Redis障害時の考え方 Redis Clusterの障害対策とキー設計 段階的な切り替えとフォールバック ステートレス化によって何が変わったのか いよいよ基幹フロントエンドのリプレイスへ まとめ 基幹フロントエンドリプレイスの構想 まず、ZOZOの基幹システムとリプレイスの背景について簡単に紹介します。 既存の基幹システムはClassic ASP（VBScript）/ IISを中心に構築され、長年にわたって機能追加を続けてきました。ZOZOは自社で倉庫を持っており、基幹システムには事業部が利用する業務機能だけでなく、ECサイトで取り扱う商品の物流機能も含まれています。非常に巨大なシステムで、長期間の運用によってモノリス化が進み、保守性・拡張性の低下や技術的負債の蓄積が課題となっています。 そこで現在、既存システムを新しいアーキテクチャへリプレイスする取り組みを進めています。 ただし、巨大な基幹システムを一度にすべて置き換えることは現実的ではありません。 ドメイン分離が容易な部分のマイクロサービス化やデータベースアクセス部分のマイクロサービスAPI化は進んでいますが、基幹システムのメインのフロントエンドのリプレイスはまだこれからです。 既存システムと新システムを一定の期間共存させ、機能単位で徐々に切り替えていく方針を考えました。 具体的には、次のような構成を目指しています。 Kubernetes基盤上にIngress + Istioによるルーティングの仕組みを構築し、URLのパスなどに応じてリクエストを振り分けます。これにより、既存システムを稼働させたまま一部の機能から置き換えていく、いわゆるストラングラーパターンによる段階的なリプレイスを目指しました。 「アーキテクチャConference 2025」でこの構想を紹介した2025年11月時点では、まだ「ステートレス化後のフロントアーキテクチャ（予定）」という位置づけでした。 では、なぜすぐにこの構成へ移行できなかったのでしょうか。 新アーキテクチャを用意するだけでは移行できない 構成図だけを見ると、新システムをKubernetes上に構築し、Ingressなどでパスルーティングすれば、既存システムから少しずつ移行できるように思えるかもしれません。 しかし、実際の既存システムには大きな制約がありました。 Webサーバー自身が状態を持っていた ことです。 既存システムでは、IISのセッション管理やサーバー上の作業用データファイルなど、動作に必要な状態をWebサーバー内部に保持していました。このような構成では、リクエストを処理するサーバーを自由に切り替えられません。 例えば、あるユーザーからの最初のリクエストをWebサーバーAが処理し、そのサーバーのメモリ上にセッションを作成したとします。次のリクエストがWebサーバーBへ送られると、WebサーバーBにはそのセッションが存在しません。 これは単純なスケールアウトだけでなく、Kubernetesへの移行でも問題になります。KubernetesではPodが作成・削除されることを前提としており、特定のWebサーバーやPodのローカルな状態に依存しない、ステートレスなアプリケーションが扱いやすい構成となります。 そして今回、もう1つ大きな問題となったのが 段階的リプレイス でした。 段階的リプレイスを阻んだIISセッション 今回目指しているのは、既存システムをあるタイミングですべて停止し、新システムへ一斉に切り替えるリプレイスではありません。既存システムと新システムを共存させながら、ページや機能単位で少しずつ移行していく、ストラングラーパターンによる段階的なリプレイスです。 この構成を実現するうえで、大きな壁となったのが、既存システムのIISセッションへの依存でした。 認証だけではないIISセッションへの依存 既存の基幹システムでは、IISのインメモリセッションをさまざまな用途で利用しています。代表的なものがユーザーの認証情報ですが、セッションの用途は認証だけではありません。 基幹システムには、複数の画面を遷移しながら1つの業務を完了する機能が数多く存在します。その過程で入力・選択した情報など、画面をまたいで引き継ぐ必要がある一時的なデータの保持にもセッションを利用しています。 そのため、既存システムの画面遷移は、同じIISセッションを継続して参照できることを前提としていました。 ここで、ページ単位の段階的なリプレイスを考えてみます。 既存画面（Classic ASP / IIS） ↓ 新画面（新システム） ↓ 既存画面（Classic ASP / IIS） IngressやIstioを利用すれば、URLのパスに応じてリクエストを振り分けること自体は可能です。しかし、ルーティングだけを切り替えても、画面間で利用しているセッション情報まで引き継げるわけではありません。 例えば、既存画面で保持した認証情報や一時データを後続の画面で必要とする場合を考えます。遷移先がKubernetes上の新システムになると、IISのメモリ上に保持していたセッションをそのまま参照できません。 つまり、ログイン状態の維持だけが問題ではありません。既存システムにおける 画面間の状態の引き継ぎそのものが、IISのインメモリセッションに依存している ことが、段階的リプレイスの障壁でした。 認証をOIDC化するだけでは解決できない この問題に対して、認証方式そのものを変更するアプローチも考えられます。例えば認証をOIDC（OpenID Connect）化し、ID Tokenを利用する構成に変更したとします。認証情報を特定のIISサーバーのインメモリセッションに依存させず、新旧システムの双方でユーザーを識別できるようになります。 認証だけが課題であれば、この方法で解決できる可能性があります。しかし今回の基幹システムでは、OIDC化だけでは要件を満たせません。既存システムがIISセッションに保持しているのは認証情報だけではないこと、そして拠点専用のサーバー構成を脱却しALBによるロードバランシングを実現することも目的としていたためです。 仮にOIDC化によって「誰がログインしているのか」を新旧双方で識別できるようになったとします。それでも、画面で入力・選択した情報など、画面間で引き継いでいる業務上の一時データまでID Tokenで引き継げるわけではありません。 例えば、既存画面でセッションに保存した情報を、次の新システムの画面で必要とするケースを考えます。 既存画面 │ │ 認証情報 │ ＋ │ 画面間で引き継ぐ業務データ ↓ IIS Session │ × │ 新画面（新システム） 認証方式だけを切り替えても、この「×」は残ります。 つまり、今回解決する必要があったのは、認証をステートレスにすることだけではありませんでした。必要だったのは、認証情報や画面間で引き継ぐ一時データを含め、 既存WebアプリケーションがIISに保持している状態そのものを、特定のWebサーバーから切り離すこと でした。 リプレイスの前に「状態」を切り離す このままでは、Kubernetes上に新しいアプリケーションを構築しても、ページ単位の段階的な置き換えは実現できません。 言い換えると、セッションの保存場所という既存システムの実装上の制約が、リプレイスできる単位まで制約していました。 そこで、新システムへの移行を本格化する前に、まず特定のIISサーバーに閉じていたセッションを外部へ切り離すことにしました。認証情報だけでなく、画面をまたいで利用される状態もWebサーバーの外部で管理します。これにより、既存システムと新システムが共存しながら、ページ・機能単位で段階的に移行できる状態を作ります。 そのために採用したのが、IISのインメモリセッションをRedisへオフロードする 「セッションオフロード」 という手法です。 次章では、このセッションオフロードをどのような構成で実現したのかを紹介します。 IISセッションをRedisへオフロードする 目指したのは、Webサーバー自身がユーザーセッションを保持しない構成です。そこで、これまでIISのインメモリに保持していたセッションを、外部のRedisへオフロードすることにしました。 Before / After ポイントは、単純にRedisを追加することではありません。既存アプリケーションから見たセッションの扱いを大きく変えずに、セッションの保存先だけをWebサーバーのメモリから外部へ移す必要があります。 ZOZOの既存基幹システムでは独自フレームワークを利用しています。今回、この独自フレームワークをバージョンアップして、セッションの読み書きをRedisへオフロードできる仕組みを導入しました。これによって、Webサーバー自身はユーザー固有のセッションを保持せず、必要なセッション情報を外部から取得する構成へ変更します。 サーバー内部に保持していたデータファイルも、読み書き先をファイルサーバーへ移行しました。 Webサーバーとセッションのライフサイクルを分離することが、この取り組みの重要なポイントです。 独自フレームワークを変更した理由 既存の基幹システムでは、Classic ASPの各ページから直接IISのSessionオブジェクトを操作するのではなく、独自フレームワークを通じてセッションを読み書きしています。このフレームワークが、セッションへのアクセスを一元的に管理する役割を担っています。 この構成であったことが、今回のセッションオフロードを実現するうえで大きな助けとなりました。 アプリケーションを1つずつ改修して保存先を変更するアプローチでは、膨大な画面数を持つ基幹システムにおいて現実的な工数で対応しきれません。しかし、セッションへのアクセスがフレームワーク層に集約されていたため、そのレイヤーでRedisへの読み書きを吸収すれば、個々のアプリケーションコードを変更せずにセッションの保存先を切り替えられます。 つまり、フレームワーク側を変更することで、 既存アプリケーションへの変更を最小限に抑えながら、セッション管理だけを差し替える ことが可能になりました。 セッションIDの引き回し 新旧システム間でセッションを共有するためには、同一ユーザーのリクエストに対して同じセッションIDでRedisにアクセスする必要があります。 セッションIDはCookieを通じてクライアントに保持させます。リクエストごとにCookieから取得したセッションIDをキーとしてRedisからセッション情報を取得します。この仕組みにより、振り分け先がIIS上の既存システムでもKubernetes上の新システムでも、同じセッションを参照できます。 シリアライズ方式と互換性 IISのインメモリセッションでは、VBScript固有のオブジェクト形式でデータが保持されています。Redisへオフロードするにあたっては、このデータをシリアライズ可能な形式に変換する必要があります。 フレームワーク層でシリアライズ・デシリアライズ処理を実装し、既存のセッションデータとの互換性を維持しながらRedisへの永続化を実現しました。シリアライズフォーマットにはJSONを採用し、VBScript固有の型情報も保持するスキーマ設計としています。これにより、新システム側でも同じフォーマットで正しくデータを読み書きできます。 更新タイミングとエラー時のロールバック セッションデータのRedisへの更新タイミングも、重要な設計ポイントです。 今回は、スクリプトの実行開始時にセッションデータをまとめて取得し、処理中はインメモリで扱い、実行完了時にまとめてRedisへ書き戻す方式を採用しました。この方式には、スクリプト処理中のセッションアクセスを高速化できること、そしてエラー発生時のロールバックを兼ねられることという2つの利点があります。 処理の途中でエラーが発生した場合、Redisへの更新は実行されません。つまり、セッションが中途半端に更新された状態を防ぐことで、セッションデータの自動ロールバックを実現しています。 仮に、スクリプト実行中に都度Redisを更新する方式にすると、エラー発生時点で一部だけ更新が反映された状態となり、ロールバックが難しくなります。更新タイミングをまとめることで、この問題を回避しています。 セッション期限管理の設計 IISのインメモリセッションには、一定時間アクセスがなければ自動的に破棄されるタイムアウトの仕組みがあります。既存システムでは、セッション破棄時にSession_OnEndイベントで業務処理を実行していました。Redisへオフロードするにあたり、このセッション終了時の処理をどう再現するかが課題となりました。 RedisにはKeyspace Notificationsという仕組みがあり、キーの期限切れを検知した際にexpiredイベントを通知できます。ただし、このイベントはTTL満了時刻ちょうどではなく、Redisがキーの期限切れを検知・削除した時点で発行されるため、通知タイミングや時刻の厳密さは保証されません。また、Keyspace Notificationsは永続キューではなく、購読者が停止している間のイベントを後から取得する仕組みもありません。したがって、取りこぼしが許容されない業務処理のトリガーには適さないと判断しました。 そこで、別途、期限管理のサブシステムを稼働させる方式を採用しています。このサブシステムがセッションの期限切れを能動的に検知し、従来Session_OnEndで実行していた業務処理を代替したうえでセッションを削除します。定期スキャンによって確実に処理を実行でき、イベントの取りこぼしがないため安定性に優れます。 この仕組みは、ZOZOTOWNでのセッションオフロード時の仕様を踏襲したものです。 Redis障害時の考え方 セッションの保存先をRedisに一本化することで、Redis障害がシステム全体に影響するリスクが生まれます。 この点については、Amazon ElastiCache for Redisのクラスタモードを採用し、3AZにまたがるレプリケーショングループによる自動フェールオーバー構成としています。さらに、1シャードの障害影響を局所化するために複数シャード構成を採用しました。特定のシャードに障害が発生しても、影響を受けるのはそのシャードに割り当てられたセッションのみです。たとえば、1シャード構成では1ノード障害の影響が100%に及びますが、5シャード構成であればハッシュスロットが均等に分散していると仮定して1ノード障害の影響は20%にとどまります。実際にはハッシュスロット分散の偏りによって上下し、ここはランニングコストと可用性のバランスになります。そのうえで、SLOで定義した可用性や試験で計測したMTTRなども考慮して、最終的なシャード数を決定しました。 Redis Clusterの障害対策とキー設計 Redis Clusterでは、キーのハッシュ値に基づいてデータが各シャードに分散されます。しかし、1つのセッションに関連する複数のキーが異なるシャードに散ると、以下の問題が生じます。 複数シャードをまたいだ読み書きによるレイテンシー悪化。 multi-key commandは同一hash slot内のキーに制限されるため、別slotのキーにはCROSSSLOTエラーが発生する。 single-slot operationの方がパフォーマンスに優れる。 シャード障害時に、同一セッションのキーの一部だけが取得できず、データ不整合を引き起こす。 Redis Clusterには「ハッシュタグ」という仕組みがあります。キーに {...} パターンを含めると、波括弧内の文字列のみをもとにハッシュスロットが計算されます。これにより、同じハッシュタグを持つキーは必ず同一シャードに配置されます。 今回のセッション管理では、1ユーザーの複数のキーにセッションIDをハッシュタグとして埋め込む設計を採用しました。 機能によってHash・String・List・Setなど適したRedisのデータ型が異なるため、セッションを1つのキーにまとめず、ユーザーの認証情報とは別に機能や画面の単位でキーを分けています。これらのキーが別シャードに散らないよう、セッションIDをハッシュタグとして共通で埋め込んでいます。 例： data:{session-id}:<FEATURE_KEY_1> # Hash data:{session-id}:<FEATURE_KEY_2> # String data:{session-id}:<FEATURE_KEY_3> # List data:{session-id}:<FEATURE_KEY_4> # Set このキー設計により、同一ユーザーのセッションに属するすべてのデータが同じシャードに格納されます。これにより、前述の問題を回避しつつ、Redis Clusterによるシャーディングの恩恵を受けられる構成としました。 参考： Redis Cluster Specification - Hash tags 段階的な切り替えとフォールバック セッションオフロードの適用は、全拠点を一斉に切り替えるのではなく、段階的に進めています。 まず、セッションオフロードに対応した環境を構築し、全倉庫拠点での動作確認を事前に実施しました。その後、影響度が小さい拠点から順にアクセス先をセッションオフロード環境へ切り替え、ロングランで安定稼働を確認しながら対象拠点を広げていく方式を採用しています。 問題が発生した場合は、影響のあるユーザー単位で旧ドメインへ切り戻すフォールバックを用意しています。拠点全体を巻き戻す必要がなく、影響範囲を限定した復旧が可能です。 2026年9月現在、この段階的な切り替えを進行中です。 ステートレス化によって何が変わったのか セッションオフロードで得られた一番大きな変化は、「Redisを使えるようになったこと」ではありません。 Webサーバーとユーザーセッションの紐付きを切り離せたこと です。 これまでWebサーバーの中にあった状態を外部へ移しました。その結果、リクエストをどのWebサーバーが処理するかと、ユーザーがどのセッションを利用するかを分離して考えられるようになりました。 これによって、アーキテクチャ上の選択肢が大きく広がります。 特定のWebサーバーにユーザーを固定する前提がなくなる。 ALBによるリクエストの均等な負荷分散が可能になる。 Webサーバーの増減や入れ替えと、ユーザーセッションのライフサイクルを分離できる。 Podが入れ替わることを前提とするKubernetesへの移行にも対応しやすくなる。 従来のステートフルな構成では、拠点ごとに接続先のWebサーバーが固定されていました。「アーキテクチャConference 2025」でもこの点を課題として紹介しています。セッションがサーバーに紐付いているため、リクエストを別のサーバーへ振り分けられず負荷が偏りやすい構造でした。ステートレス化によってこの制約がなくなり、ALBで均等にリクエストを分散できるようになりました。 しかし、今回の基幹リプレイスにおいて最も重要なのは、その先です。既存システムと新システムをまたいだ、段階的なフロントエンドリプレイスを進めるための前提条件が整いました。 これまで、 Webサーバー ＝ アプリケーション ＋ ユーザーの状態 だったものを、 Webサーバー ＝ アプリケーション Redis ＝ ユーザーの状態 へ分離したことで、フロントエンドのルーティングとセッション管理を独立して考えられるようになります。 これは単なるインフラ変更ではなく、基幹システムをどの単位で、どの順番でリプレイスできるかを変えるための アーキテクチャ変更 です。 いよいよ基幹フロントエンドのリプレイスへ ここで、2025年11月の「アーキテクチャConference 2025」で紹介した構成に戻ります。 当時紹介したのは、Kubernetes基盤上にIngress + Istioを配置し、ストラングラーパターンによって既存システムと新システムを共存させる構成でした。そして、機能ごとのパスルーティングによって、既存のClassic ASPから新しいアプリケーションへ段階的に切り替えていくことを予定していました。 当時はまだ「予定」だったこのアーキテクチャに対して、今回のセッションオフロードによって、その前提となるステートレス化を進めることができました。 巨大な基幹システムのリプレイスでは、新しいシステムを作ることだけが課題になるわけではありません。既存システムが長年の運用の中で持つようになった前提や制約を1つずつ解きほぐし、新旧システムが共存できる状態を作ることも、段階的なリプレイスには必要です。 今回取り組んだセッションオフロードは、そのための1つのステップでした。Webサーバーから状態を切り離したことで、既存システムを稼働させたまま、新アーキテクチャへページ・機能単位で移行していくための土台が整いました。 まとめ 本記事では、ZOZOの基幹システムにおけるWebサーバーのステートレス化について紹介しました。 2025年11月の「アーキテクチャConference 2025」では、基幹システムのリプレイスを進めるうえで「ステートフル」であることを課題として挙げました。あわせて、IISセッションをRedisへオフロードする方針と、Kubernetes上での段階的なフロントエンドリプレイス構想を紹介しました。 その構想を実現するため、既存システムで利用している独自フレームワークをバージョンアップし、IISのインメモリに保持していたユーザーセッションをRedisへオフロードしました。 今回の取り組みで重要だったのは、Redis導入そのものではありません。既存システムから「状態」という制約を切り離し、リプレイスの自由度を上げることでした。 長年稼働してきた基幹システムを、一度にすべて刷新できません。だからこそ、新しいアーキテクチャを作るだけではなく、既存システムを少しずつ「置き換えられる状態」に変えていくことが重要だと考えています。 2025年に「予定」として紹介していた基幹フロントエンドの新しいアーキテクチャは、今回のステートレス化によって実現に向けた準備が整いました。ここから、基幹フロントエンドの段階的なリプレイスを進めていきます。 ZOZOでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com