Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AI時代のリアーキテクチャ戦略 / Re-architecture Strategy in t...
Search
dachi023
May 16, 2025
Programming
0
200
AI時代のリアーキテクチャ戦略 / Re-architecture Strategy in the AI Era
dachi023
May 16, 2025
Tweet
Share
More Decks by dachi023
See All by dachi023
チーム開発を円滑に進めるためのOSS / Lightning TechTalks 20231102
dachi023
0
410
なぜその技術を使うのか? / Connehito marche online 20201112
dachi023
0
800
リモートワークの導入から3ヶ月 / Connehito marche online 20200311
dachi023
2
3k
急に大量のHTMLが必要になったこと、ありませんか? / BIT VALLEY INSIDE vol8
dachi023
0
8k
ママリのweb技術の今と未来 / mamari's front-end present and future
dachi023
2
1.4k
2年運用したサービスのフロントをReactで書き換えたい話
dachi023
5
2.1k
beginner_react_flux
dachi023
1
430
エンジニアがUIデザインをしてみた話
dachi023
1
1.3k
Other Decks in Programming
See All in Programming
UPDATEがシステムを複雑にする? イミュータブルデータモデルのすすめ
shimomura
0
400
型安全なDrag and Dropの設計を考える
yudppp
5
690
プロダクト開発でも使おう 関数のオーバーロード
yoiwamoto
0
100
プロダクト改善のために新しいことを始める -useContextからの卒業、Zustandへ-
rebase_engineering
1
100
tsconfigのオプションで変わる型世界
keisukeikeda
1
130
複雑なフォームを継続的に開発していくための技術選定・設計・実装 #tskaigi / #tskaigi2025
izumin5210
12
6.7k
External SecretsのさくらProvider初期実装を担当しています
logica0419
0
250
型付け力を強化するための Hoogle のすゝめ / Boosting Your Type Mastery with Hoogle
guvalif
1
250
イベントストーミングから始めるドメイン駆動設計
jgeem
3
700
TSConfigからTypeScriptの世界を覗く
planck16
2
1.3k
#QiitaBash TDDでAIに設計イメージを伝える
ryosukedtomita
2
1.6k
The Evolution of Enterprise Java with Jakarta EE 11 and Beyond
ivargrimstad
0
240
Featured
See All Featured
Music & Morning Musume
bryan
47
6.6k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
34k
Designing for Performance
lara
608
69k
Statistics for Hackers
jakevdp
799
220k
How to train your dragon (web standard)
notwaldorf
92
6.1k
The Language of Interfaces
destraynor
158
25k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.7k
Practical Orchestrator
shlominoach
188
11k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
760
Facilitating Awesome Meetings
lara
54
6.4k
Art, The Web, and Tiny UX
lynnandtonic
298
21k
Transcript
AI時代のリアーキテクチャ戦略 2025-05-15 “AI x フロントエンド開発のリアル ” PRESENTATION SLIDES [ ver.01
2025.05 ] © MOSH Inc. MOSH develops and operates a platform that supports independent creators in selling their services online.
Ryo Adachi Webフロントエンドエンジニア at MOSH株式会社 PRESENTATION SLIDES © MOSH Inc.
Productivity Team 基盤の改善、開発生産性の向上、などが主業務。 プロダクト開発を円滑に進めるための開発。 技術広報 企業ポッドキャスト、技術ブログ、勉強会の企画・運営。 趣味:料理、公園 最近は魚が好き。
PRESENTATION SLIDES © MOSH Inc. INDEX 01 会社概要 02 背景・前提
03 AIとの開発の進め方 04 まとめ
MOSHのミッション 一人の情熱が育まれ、だれかに伝播し、また新しい情熱が生まれる。 そんなふうに「情熱がめぐる」世界をつくることが私たちのミッションです。 PRESENTATION SLIDES © MOSH Inc.
MOSHのプロダクト MOSHは専門性を持った個人・クリエイター向けのサービス販売&経営拡大プラットフォームです。 オールインワンプロダクトとしてクリエイターの事業拡大を支援します。 PRESENTATION SLIDES © MOSH Inc.
背景・前提 PRESENTATION SLIDES © MOSH Inc.
[email protected]
→ React
[email protected]
MOSH創業時から続いてきたAngularアプリケーションをReactへ書き換えることに。 PRESENTATION SLIDES © MOSH Inc.
開発者への負荷 開発体験の悪化、コードの複雑化など。 変更容易性の低さ 機能変更による不具合の発生率が上昇。 プロダクト開発が思うように進まない状態になる。 Reactへの乗り換え AngularよりもReactの方が経験があるというメンバーが増えてきた。 コミュニティが活発で他ライブラリとの親和性も高い。
PRESENTATION SLIDES © MOSH Inc. 開発者への負荷 • 8年分のコードの中にある使ってないけど消してないコー ド、テストコードがない、etc… •
機能同士が複雑に絡まっていて入社後最初にぶち当たる 壁になっている • ビルド時間が長い、開発サーバーのメモリ消費量など開 発体験が著しく低下している
PRESENTATION SLIDES © MOSH Inc. 変更容易性が低い • 歴史の中で処理は複雑化してしまっていて、何かを変更 すると何かしら不具合が起きる •
これを改善するためには相当なリソースを割く必要がある が、その改善すらも不具合を起こす
PRESENTATION SLIDES © MOSH Inc. Reactにすることの利点 • MOSHに来る前までReactを書いていたというメンバーが 複数名おり、移行すること自体に抵抗はない •
情報量やコミュニティの活発さ、ライブラリの充実度などが 魅力的である
一度にまとめて移行するのは非現実的かつ疲弊するので少しずつ移行・リリースできる仕組みを整える。 また、自動化できる部分は積極的に自動化していく。 段階的な移行を進めるために PRESENTATION SLIDES © MOSH Inc. リバースプロキシで画面ごとに振り分ける mosh.jpへのリクエストをAngular
/ Reactのどちらに処理させるか判定。 認証処理の共通化 AWS Cognito, Amplifyを使って認証基盤を共通化。 API Clientの再利用 Orvalを採用し、クライアント以外にもzodやMSWのスキーマ生成も対応。
PRESENTATION SLIDES © MOSH Inc. リバースプロキシで 画面ごとに振り分ける • アプリケーションの前にnginxを置き、パス単位でどちらの アプリケーションにリクエストを通すか決定する
(デフォル トはAngular) • Reactへの書き換えが完了したら向き先を変更、Angular の使わなくなったコードを削除という運用 AWS ECS S3 Cloudflare Pages /page/a /page/b
PRESENTATION SLIDES © MOSH Inc. 認証処理の共通化 • もともと利用していたAWS Cognitoを引き続き利用、ユー ザープールや認証を共通で利用可能
• パス単位でアプリケーションの振り分けをしているのでドメ インは一緒、認証も引き継がれユーザーは意識せずアプ リ間を行き来可能 • 今回のようなケースを想定して使っていたわけではないも のの、移行のハードルを大きく下げることが出来た AWS Cloudflare Cognito S3 Pages
PRESENTATION SLIDES © MOSH Inc. API Clientの再利用 • API Clientはすべてopenapi.ymlから生成する
• 生成ツールはOrvalを利用、API Clientだけでなくzod schemaやMSWのモック生成などにも対応
AIとの開発の進め方 PRESENTATION SLIDES © MOSH Inc.
AI agentを活用するためのセットアップ ストレスなくAIに任せられる環境づくりをしていく。 AIだから特別これをしなければならない、というものは特に無い。 PRESENTATION SLIDES © MOSH Inc. オンボーディング
KnowledgeやMemory Bankといった仕組みを活用して精度を上げる。 Issueの作成 Issueは細かく、目的はなるべく単純に。
PRESENTATION SLIDES © MOSH Inc. オンボーディング • 全てのタスクで守るべきルールや専門用語の説明などを まとめておく •
指示の仕方で成果物の品質が大きく変わってしまうことを 防ぎたい • もしドキュメントがなければここから更にドキュメントを作る ことも可能
PRESENTATION SLIDES © MOSH Inc. Issueの作成 • やること、制約や守ってほしいことを記載 • 複数のタスクをまとめてやろうとすると脱線しがちなので
Issueを分割できるならする
Devin 複数リポジトリの参照、異なるライブラリへの書き換えを実現する。 PRESENTATION SLIDES © MOSH Inc. AngularからReactへ 正しさはテストで保証 PRで上がってきたものをチェックし、問題なければマージしていく。
元のコードにはテストがほぼないのでこのタイミングで整える。 テストが仕様である状態になることで実装者は迷わず開発ができる。
PRESENTATION SLIDES © MOSH Inc. AngularからReactへ • Reactの書き方については何も指示していないが、Hooks 使ったりReactぽいコードに書き換わっている •
UI周りはだいぶ厳しい、修正指示を何回もすることになっ たため諦めた
PRESENTATION SLIDES © MOSH Inc. 正しさはテストで保証 • 仕様をIssueに書き実装前にテストを書いておく、それを満 たすように移行するなどの工夫が必要 •
TDDライクに「通らないテスト」を書いて、それが通るよう にDevinにコードを書いてもらう • リファクタリングはPRのレビューコメントでやるか、PRごと 引き取って手元で修正する
MCP AIエディタにMCPサーバーを接続し、できることを増やす。 PRESENTATION SLIDES © MOSH Inc. Figma MCP 初回のデザインの反映コストを削減。
Playwright MCP E2Eシナリオの作成やスクリーンショットの自動化。
PRESENTATION SLIDES © MOSH Inc. Figma MCP • UIのスタイリングが可能になる •
新規UIの実装、shadcn/uiで生成したコンポーネントに Figma上のデザインを当てて利用するなど
PRESENTATION SLIDES © MOSH Inc. Playwright MCP • 自然言語で書かれている仕様や受け入れ条件などから E2Eテストのシナリオを生成
• Before / Afterの比較を視覚的に伝えるためのスクリーン ショット撮影
まとめ PRESENTATION SLIDES © MOSH Inc.
AI使えば開発速くなるは本当、だが 仕込みが重要なのでとりあえず使えば速くなるわけじゃない。 PRESENTATION SLIDES © MOSH Inc. 使いながら得意・不得意を理解していく 迷わないためのドキュメンテーション コードの移植やデザインを当てる作業ではなく、何が仕様で何が正しいをしっかりと定義すること
に時間を割く。これからの開発で過去の失敗を繰り返さないようにする。 人間には出せないようなパフォーマンスも出せる一方で自分でやった方が良いなと感じる部分も ある。そういった癖みたいなものがあるという前提で向き合う。