🕸️
Muddy Web #10 ~Special Edition~ 【ゲスト: pixiv】 レポート
公開
2025-04-13
更新
2025-04-13
文章量
約4516字
「Muddy Web」は、“Muddy = 泥くさい” をキーワードに、Webフロントエンド開発の現場で遭遇する具体的かつ生々しいケーススタディを通して学びを得るためのイベントです。第10回目となる今回は、pixiv のエンジニアの方々をゲストに迎え、オフライン・オンライン同時開催で行われました。
フロントエンドの技術選定や実装上の悩み、巨大サービス特有のレガシー負債、そして最新のブラウザ技術との向き合い方まで、多彩なテーマが飛び交い、大いに盛り上がった夜の様子をレポートします。
https://cyberagent.connpass.com/event/335669/
1. イベント概要と進行
10回目の Muddy Web は、サイバーエージェント社のオフィスとオンラインで同時開催されました。オフラインでは会場に集った参加者同士の懇親会も行われ、登壇では語りきれないエピソードを直接質問できる場として大きな盛り上がりを見せました。
オフライン会場の注意事項として、遅い時間でも気軽に食事や飲み物を楽しみながらセッションを視聴できるラフなスタイル。オンライン参加者はYouTube Liveでコメント・質問を投稿可能。さらには別途、スライド上で質問が投げられる仕組みも用意され、現場とオンラインの垣根を感じさせない運営が印象的でした。
登壇は以下の4つのセッションが連続で行われました。
野口さん（AbemaTV） 「スマートテレビアプリケーションのパフォーマンス改善: 業界トップクラスを目指して」
yueさん（pixiv） 「ブラウザ単体でmp4書き出すまで」
浅原さん（CyberAgent, ジャンプTOON） 「ジャンプTOONにおけるサイトマップの自動生成手法について」
さいとさん（pixiv） 「17年周年のWebアプリケーションにTanStack Queryを導入する」
2. セッション1：ABEMA「スマートテレビアプリケーションのパフォーマンス改善」
最初に登壇したのは、ABEMA のWebエンジニア・野口さん。テレビ向けデバイス、特に WebベースTV アプリケーションにおけるパフォーマンス課題と、そこからどう改善しトップクラスを目指したかを紹介されました。
ポイントまとめ
背景 ABEMAのTVデバイス対応は多数のメーカーが対象だが、パフォーマンスが他社アプリに比べ遅いのが課題だった。
計測方法 最初は手動で動画撮影 → コマ送り確認 → 平均値を出すという地道なアプローチ。 後にNew Relicを活用して継続的計測や可視化の仕組みを構築。
具体的な施策
CDN導入・圧縮配信で 0.7秒短縮
プリコネクト設定で 0.4秒短縮
JSバンドルサイズ削減で 1.5秒短縮
海遊ページの遅延レンダリング対応で大幅改善
Q&Aピックアップ
Q. 機能追加よりパフォーマンス改善の優先度はどうすり合わせたか？ → ビジネスサイドも「スマートテレビの利用増加に伴い品質向上が重要」という認識が強く、機能追加と同等のプライオリティでチーム体制が組まれた。
Q. ネットワークや環境差は対策したのか？ → スマートテレビは基本的に家庭の固定回線でWi-Fi接続が多いので、圧縮やJS削減が効果的と判断。モバイル回線のような多様性は少ない印象。
結果として、起動～操作など全般の反応速度でトップクラスを実現し、ビジネス指標（PVなど）の向上にも明確に貢献。泥臭い検証と改善を半年前から粘り強く行った成果が強調されました。
3. セッション2：pixiv「ブラウザ単体でmp4書き出すまで」
続いて、pixivでVRoid Hubチームのyueさん。3DモデルをWebブラウザ上で撮影し、MP4形式の動画をブラウザ単体で出力する機能開発について、緻密な検討プロセスと技術選択の奮闘を紹介しました。
ポイントまとめ
経緯 VRMアニメーションを試せる場として、ユーザーが3Dアバターを撮影 → 動画ファイルを出力・共有したいという要望が生まれた。
フォーマット/実装選定
サーバサイドFFmpeg → 負荷や開発コストが大きい
GIF → 撮影時間が長いとファイルサイズが激増
MediaRecorder/Canvas + WebCodecs → ブラウザ標準APIを活用
マルチブラウザ対応でMP4書き出しがネックに。ChromeとFirefoxはWebM中心、SafariはMP4可…など仕上げが複雑。
デバイス制限 携帯端末では描画解像度やフレーム落ち対策が必要。DPRやキャンバスサイズに工夫しメモリ不足を回避。
Q&Aピックアップ
Q. 出力に時間がかかりすぎる問題は？ → 工夫次第で、撮影終了後すぐダウンロード可能なレベルに。フレームレートやDPRを調整しつつクラッシュを避ける。
Q. Windows特定環境でクラッシュが起きたのは？ → ライブラリやコード変換の不具合。プラットフォーム固有問題に苦労した。
Q. なぜWebCodecs？ → MP4やWebMに対応するAPIが選択肢。MediaRecorder＋WebCodecsが比較的柔軟と判断。
実装はマディに課題が噴出。モバイルでのクラッシュ、デバイスのDPR問題などを一つずつ解決し、最終的にブラウザでスムーズに動画を書き出せる機能を完成。社内外で「ブラウザでそこまでできるのか」と驚きがあったとのことでした。
4. セッション3：ジャンプTOON「サイトマップ自動生成手法について」
3つ目のセッションは浅原さん。タテ読みマンガサービス「ジャンプTOON」のサイトマップ自動生成をめぐる実装方法や設計・運用上の注意点を披露しました。
ポイントまとめ
ジャンプTOON 2024年5月リリース。オリジナル連載や人気作品のタテカラー版を毎日更新。作品数増加に合わせ、検索エンジン対策として定期的にサイトマップを生成。
実装アプローチ
next-sitemapや内蔵機能を使わず、自前スクリプトでXML生成分割ファイルをまとめるインデックスを自動化し、作品や話数の増加に対応
ファイル上限（5万URL）や運用の都合を考慮しつつ、複数ファイルをまとめるためのロジックを整備
Q&Aピックアップ
Q. なぜ自作？ →
Next.js提供の機能はファイル分割はできるが、インデックスファイルの自動生成が未実装だった。運用が大規模化する中で自作の方が都合良かった。Q. スクレイピング対策は？ → 可能な限りサイトマップの特定を難しくしたい。ロボッツ用だけに配置し、安易にURLが知られないようにする配慮。
巨大サービスほどサイトマップのファイル数や自動生成バッチ運用が複雑になるが、ジャンプTOONでは「ローカル生成→配信バケットへのアップ→CDNキャッシュパージ」という流れを定期実行して安定を図っているそうです。
5. セッション4：pixiv「17年周年のWebアプリケーションにTanStack Queryを導入する」
最後はpixivのさいとさん。17年の長期運用により積み重なった実装負債をいかに解消し、最新のライブラリを組み込むのか。その背景や合意形成の手法を示されました。
ポイントまとめ
pixivの歴史 2007年の誕生から長期にわたりPHP＋Smarty、あるいはVue/Reactが混在する状態。チームも多数に分かれ、移行にはリスクが大きい。
変えるための合意形成
ADR（Architecture Decision Record）導入
フロントエンド開発者の定例会で提案や議論
各時代の負債を一気に消すのは無理だが、段階的に移行やリファクタリングを図る
TanStack Query導入
Reduxを脱却し、非同期データ管理をシンプルにしたい
SWRやRTK Queryなど複数候補があったが、ADRで検討を進め、最終的にTanStackを採用
同期的に場所を設け、チーム間で納得感を得たのが大きな成功要因
6. Q&Aダイジェスト
いくつかのセッションで印象深いQ&Aが飛び交いました。
「ABEMAのパフォーマンス改善は、機能開発との優先度をどう決めた？」 → スマートテレビ領域の品質向上がビジネス的にも重要と認識され、機能開発と同列に扱われた。専任チーム体制が大きい。
「pixivでのライブラリ選定はどう承認？ 誰が決済する？」 → テックリードが参加する定例会などで議論、ADRで客観的に要件比較し合意。最終判断は関心あるメンバー＋テックリードが行う。
「サイトマップに全部載せるとスクレイピング増えるのでは？」 → ロボッツファイルやURLの露出制限を検討。自作スクリプトで細かな制御をしている。
いずれも大規模・複雑化サービスに共通する「誰がどこまで決められるか」「旧コードをどこまで残すか」「適切な技術が導入しづらい環境をどう打開するか」がテーマとなっていました。
7. 全体を踏まえた感想
長期にわたるサービスほど、技術負債や混在する実装、チーム体制の壁など、フロントエンド開発には厄介な課題が山積みです。しかし登壇者の経験談を見ると、それを一気に刷新するのではなく、粘り強く現状分析し、改善目標を設定し、地道な検証を繰り返す姿勢が成功に繋がっていました。
特に印象的だったのは、pixivでの**「合意形成の仕組み」**としてのADRとフロントエンド定例会。あえて週1〜隔週の定期ミーティングを設けることで、提案が埋もれず、スムーズにチーム合意を得られる流れが生まれていました。これは技術的なノウハウ以上に「チームや組織にとって本当に必要なアーキテクチャを実装する上で不可欠」だと感じます。
また、ABEMAが示したテレビアプリのパフォーマンス改善や、pixivのWebGL＋動画出力、ジャンプTOONの巨大サイト運営など、どれも泥臭く試行錯誤してこそ可能になる領域ばかりでした。まさにMuddy Webの名にふさわしいディープな現場知見が詰まった回だったと言えるでしょう。
今後もフロントエンドは進化が止まりません。泥まみれになりながらも技術の価値を信じ、ひとつひとつ課題を超えていく現場の姿勢が、多くの参加者のモチベーションをかきたてた印象的なイベントでした。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
