Engineer Blog

Kakemu Fujii

Kento Kaseda

Reo Hakuta

Erika Sakurai

erikasakurai

Takaharu Nakamura

Daichi Hachisuka

Louis Avondet

Sota Sato

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

<p>こんにちは、藤井駆陸です。普段は化石について研究している大学院生です。9月の間、プレイドのJourneyチームにてインターンに参加しておりました。</p>
<p>振り返れば一瞬に感じられた1ヶ月でした。頭を抱えながら巨大なアーキテクチャの概要を掴み、タイムゾーンとSQLに苦戦しながら多くの実装をし、検証用環境を追い込んで問題点を洗い出す。そんな目まぐるしい日々でした。</p>
<p>この記事では、実際に関わったタスクや、インターンの率直な感想についてお伝えできればと思います。</p>
<h2>導入</h2>
<h3>インターン参加の経緯</h3>
<p>最初のきっかけは、プレイドで働く友人から、仕事がとても充実していると聞いたことでした。<br>
面談や面接でお話を伺う中で、カルチャーなどに加えて、技術的に難易度の高い大規模データを扱う挑戦に魅力を感じました。<br>
「自分もこの環境に飛び込み、挑戦したい」と強く感じ、このインターンシップに参加しました。</p>
<h3>Journeyとは？</h3>
<p>プレイドが提供するプロダクト「KARTE」において、ユーザーの辿る行動に応じて、異なる施策を実行することができる機能です。例えば、ECサイトで「カートに商品を入れたまま迷っているユーザーに、2時間後にクーポンの通知を送る」といった、ユーザーの状況に応じたシナリオを自動で実行してくれます。</p>
<p>参考：<a href="https://karte.io/product/journey/">KARTE Journey</a></p>
<p>現在、Journeyチームでは配信基盤周りの改善を行なっています。その中核としてユーザーのイベントが発火した瞬間に処理を行う「イベント処理基盤」と、指定時間の経過や条件の評価などをバッチ処理で行う「定期実行基盤」を開発しています。<br>
今回は「定期実行基盤」にまつわるタスクを行いました。</p>
<h2>業務内容紹介</h2>
<h3>時間経過の判定の処理のリアーキテクチャ</h3>
<p>Journeyにおいてシナリオは、ユーザーの行動や通知の配信などといった1つ1つのステップに分けられます。その中には、「指定時間までユーザーを待つ」といったものもあります。そこでは、「2時間後」「毎週金曜の18:00」「月末の12:00」など、様々な条件でユーザーが留まる時間を指定することができます。</p>
<p><img src="https://ik.imagekit.io/plaid/7bd172a8-fccb-4f88-b8c7-932f98ea5b8c/blog_image_1.png" alt="blog_image_1.png"></p>
<p>定期実行基盤の主要な部分として、各ステップの遷移対象となるユーザーを抽出するコンポーネントと、遷移対象のユーザーを実際にデータベースに書き込んで次のステップへ移すコンポーネントがあります。</p>
<p>従来の実装では、データ更新を担うコンポーネント（下図右側）が、ユーザーを待つ処理がある時には「ユーザーの待ち時間の終了時刻を計算する」という処理も行なっていました。本来書き込みに専念すべき場所に、時刻計算のビジネスロジックが混在して責務が曖昧になり、全体の見通しの悪さが課題となっていました。</p>
<p><img src="https://ik.imagekit.io/plaid/d14465ef-2fd8-43d2-9d4b-02e3d39884e8/blog_image_2.png" alt="blog_image_2.png"></p>
<p>そこで、遷移を実行するコンポーネントで書き込み処理に専念できるよう、遷移対象を抽出する段階で動的にSQLを生成するように実装を変更しました。*1<br>
具体的には、TypeScript側で「現時点でいつの時刻まで流入してきた人が遷移対象となるべきか」を計算し、それを用いてクエリを書くといった実装でした。</p>
<p>*1: BigQueryのUDF(User defined function)も検討しましたが、行数を少なく実装できる一方で可読性やメンテナンス性が低かったため見送りました。</p>
<p><img src="https://ik.imagekit.io/plaid/72d50f67-2cbf-4a7a-9682-c6fb7d3d5a83/blog_image_3.png" alt="blog_image_3.png"></p>
<p>大変だったことは、網羅すべきパターンが多く、単純な計算なのにも関わらずコード量が膨大になったことです。初めはパターンごとにクエリを実装していましたが、SQLの構造が2つのパターンに集約できるのを見抜いて、計算部分を切り出しました。まだまだSQLの動的生成の可読性は課題ではあるものの、コードの見通しはある程度良い状態で実装ができました。</p>
<p>実装の細部にまで目を配ってレビューしていただき、非常に勉強になりました。例えば、待ち時間のパターンに対して Discriminated Union の導入を提案いただいたことで、より型安全に整理できました。このように、今まで知らなかった技術を活かして実践的なコード改善に繋げるという貴重な体験は、自身の成長に大きくつながりました。</p>
<h3>定期実行基盤の負荷検証</h3>
<p>次に、クラウドインフラのリソースを増やすことによって定期実行基盤が本番トラフィックを処理可能か、そのスケーラビリティを検証するための負荷テストを行いました。</p>
<p>目標実行時間を2分半以内と設定し、大量の検証用データを投入してテストを開始したのですが、現実は甘くありませんでした。実行時間は常に目標を大幅に上回り、ボトルネック探しの調査が始まったのです。</p>
<p>以下の流れで負荷検証を行いました。</p>
<ol>
<li>データ大量投入スクリプトの準備</li>
<li>検証</li>
<li>デプロイ設定の変更(複数回)</li>
<li>Datadogメトリクスの導入</li>
</ol>
<p><strong>仮説1：ユーザー抽出時のリソース不足</strong></p>
<p>まず疑ったのは、コンピューティングリソースの不足です。</p>
<p>実際に、テストの初期段階ではcpu使用率が頭打ちしていて、メモリにも余裕がない状況でした。GKEのpod数を10程度まで増やしてリソースを潤沢に確保しました。しかし、CPU使用率は安定したものの、実行時間は依然として5分を超過したままでした。</p>
<p><img src="https://ik.imagekit.io/plaid/fd0a8e70-2268-408f-b9f2-a133f8398704/blog_image_4.png" alt="blog_image_4.png"></p>
<p><strong>仮説2：データベース処理の遅延</strong></p>
<p>次に目を向けたのは、データベース、特にBigQuery(BQ)の処理です。Temporalのワークフローの実行記録(上の画像)から、BQでの一時テーブル作成やSpannerへのエクスポートの処理に時間がかかっている可能性が浮かび上がりました。</p>
<p>これを検証するため、Datadogで各BQクエリの実行時間を計測可能にしました。その結果、クエリの実行時間は最長で10秒程度であることがわかりました。5分以上の実行時間を説明するには不十分でした。</p>
<p><img src="https://ik.imagekit.io/plaid/39f98e76-7cac-4acf-bb7a-1911ff967d40/blog_image_5.png" alt="blog_image_5.png"></p>
<p><strong>真相：直列実行の罠</strong></p>
<p>八方塞がりかと思われた中で、GKEのログを見てみたところ、驚くべき事実が判明しました。<br>
調査の結果、検証環境では本来並列で実行されるべき多数のタスクが、なぜか直列に一つずつ処理されていたのです。すなわち、BQやSpannerのIO待ちが積み重なっていたということです。<br>
今回のボトルネックの正体は、「デプロイされた環境における並列処理の不具合」だったのです。<br>
最終的に問題を完全に修正するところまで至りませんでしたが、この調査プロセスは非常に大きな学びとなりました。<br>
「仮説を立て、データを用いてそれを検証し、次の打ち手を考える」というサイクルを高速で回すことの重要性を肌で感じました。巨大なシステムにおける問題解決のリアルな一端に触れられた、非常に価値のある経験でした。</p>
<h2>インターン生活について</h2>
<h3>プレイドでの働く環境</h3>
<p>全体的にオープンな雰囲気で、誰にでも気軽に質問や相談ができました。特に印象的だったのは、タスクに関する何気ない相談が、次第にプロダクトの設計といった、より深い議論に発展していく光景でした。1人の思考がチームとしての思考に拡張されてゆくような、新鮮な体験でした。<br>
また、ランチの時間には他のチームの方とも交流することができ、毎日楽しく過ごすことができました。インターン生同士や新卒の方などとの繋がりもできてよかったです。</p>
<h3>インターンを通しての学び</h3>
<p>この1ヶ月で、エンジニアとして多方面にわたり大きく成長できたと感じています。<br>
実装における細かい技術的な側面から、プロダクトの提供する価値といったビジネス的な側面まで、幅広い視点でインプットできました。<br>
その中でも特に、データを大量に投入してパフォーマンスを観察するといったことは、自分一人ではできない新たな経験でした。大規模なデータを処理するアプリケーションのインフラの一端を覗くことができ、非常に勉強になりました。</p>
<h2>最後に</h2>
<p>この1ヶ月は、手厚いサポートを受けながらも手応えのあるタスクに没頭することができ、非常に充実した時間でした。改めて、Journeyチームの皆様には心から感謝しています。<br>
このインターンは、刺さる人には深く刺さるものだと感じています。「手応えのあることに挑戦したい」「新しい技術に触れてみたい」といった方には最高の環境です。<br>
そのワクワクするような経験を、ぜひ次はご自身で体験してみてください。</p>


こんにちは、藤井駆陸です。普段は化石について研究している大学院生です。9月の間、プレイドのJourneyチームにてインターンに参加しておりました。  振り返れば一瞬に感じられた1ヶ月でした。頭を抱えながら巨大なアーキテクチャの概要を掴み、タイムゾーンとSQLに苦戦しながら多くの実装をし、検証用環境を追い込んで問題点を洗い出す。そんな目まぐるしい日々でした。  この記事では、実際に関わったタスクや、インターンの率直な感想についてお伝えできればと思います。

プレイドインターン体験記：大規模システムのリアーキテクチャと負荷検証

<p>KARTE for Appチームのエンジニアの悴田です。</p>
<p>プレイドは、2025年9月19日〜21日に開催された <a href="https://iosdc.jp/2025/">iOSDC Japan 2025</a> にゴールドスポンサーとして協賛し、ブース出展も行いました。<br>
本記事では、当日のブースの様子と、聴講した中で特に印象的だった4つのセッションについてご紹介します。</p>
<h2>ブースのご紹介</h2>
<p>プレイドでは、モバイルアプリ向けのSDKを開発・提供しています。</p>
<p>現在は、モバイルアプリのエンゲージメント向上を目的とする「<a href="https://karte.io/package/app/">KARTE for App</a>」と、Native UIの開発生産性向上を目的とした新規プロダクト (本記事公開時点ではクローズドベータ)、の2つを提供しています。<br>
今回のブース企画・運営は、これら2チームの開発メンバーを中心に行いました。</p>
<p>ブースでは、「<strong>アプリグロースの課題に関するパネルアンケート</strong>」と「<strong>マーケティングSDKの利用状況に関するWebアンケート</strong>」の2つを実施しました。</p>
<p><img src="https://ik.imagekit.io/plaid/b4be8f0a-852a-4130-8084-919d5678507c/IMG_0075.jpg" alt="IMG_0075.jpg"></p>
<p>アンケートにご協力いただいた方々には、弊社のノベルティグッズをプレゼントしました。<br>
ノベルティグッズとして「ラムネ」「歯磨きセット」「携帯式のコップ」「米 (2合)」を用意し、特に「米」は物珍しさもあって好評でした。</p>
<p>また、Webアンケートは弊社の「KARTE」を用いて作成し、アンケートの回答後にはくじを引けるようにしました。<br>
見事当たりを引いた方には、弊社のエンジニアが厳選した技術書の中から、お好きな一冊をプレゼントさせていただきました。</p>
<p><img src="https://ik.imagekit.io/plaid/740576ff-fc73-4bc2-ab3b-544df4b54c73/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-09-2915.02.17.png" alt="スクリーンショット2025-09-2915.02.17.png"><br>
当選者の方々 (ブログ掲載許諾取得済み)</p>
<h2>印象に残ったセッション</h2>
<p>テストやビルドといったMobile SDK開発にも関係するセッションや、個人的に興味のある低レイヤー寄りのセッションを聴講しました。</p>
<h3>1. 半自動E2Eで手っ取り早くリグレッションテストを効率化しよう</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="半自動E2Eで手っ取り早くリグレッションテストを効率化しよう" src="https://speakerdeck.com/player/b2991526951744758463d4663866c514" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>タイミー社での、E2Eテストの効率化に向けた現実的なアプローチが紹介されました。</p>
<p>当初、同社ではCI/CDとSaaSを活用した全自動のE2Eテストを目指していましたが、SaaSを使いこなす難しさや、SMS認証・QRコード読み取りといった実機特有のテスト項目が障壁となり、1年以上かけても安定運用には至らなかったそうです。</p>
<p>そこで、全自動化を諦め、以下のような「<strong>簡単にできる部分だけ自動化する</strong>」という半自動の方針に切り替えました。</p>
<ul>
<li>ローカルPCでアプリをビルドし、実機にインストールしてテストを実行する。</li>
<li>テスト自動化ツールとして、Railsで使い慣れている「Ruby」で記述できるAppiumを使用する。</li>
<li>自動化できない処理は、手動で操作する。スクリプト内にsleepメソッドを入れ、一時停止中に手動で操作する。手動操作のタイミングは、音を鳴らす仕組みで伝える。</li>
<li>うまく検出できないUI要素は、OCRを利用した画面タップで対応する。</li>
</ul>
<p>このアプローチにより、<strong>わずか1ヶ月で運用を軌道に乗せることに成功</strong>したそうです。</p>
<hr>
<p>私たちのチームにおいても、Mobile SDKのテスト自動化は重要な課題の一つです。<br>
本セッションで語られている、完璧を求めず、最小の労力で最大の成果を得ることを目指すアプローチを取り入れたいと思いました。</p>
<hr>
<h3>2. Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム" src="https://speakerdeck.com/player/89fc533243314e52a7bca2e17d6a4c23" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>XcodeならびにSwift Package Manager (SPM) において、Swiftコードがビルドされる流れと、その際に利用される各種ツール (`xcodebuild`, `swiftc`, `llbuild`など) の役割が紹介されています。</p>
<p>Xcodeでのビルドの場合、まずはXcodeが*.xcodeprojから「<strong>llbuildマニフェスト</strong>」を作成します。llbuildマニフェストとは、<strong>ビルドに必要なタスク一覧とそれらの依存関係を記述したファイル</strong>です。<br>
続いて、llbuildマニフェストは「llbuild」に渡され、実際のビルド処理をコンパイラ (swiftc/clang) やリンカ (ld) を用いて実行します。</p>
<p>一方、SPMでのビルドの場合には、SPMがPackage.swiftからllbuildマニフェストを生成し、llbuildに渡します。<br>
このような、<strong>llbuildマニフェストを生成するツールの違いが、XcodeとSPMの機能差の一因</strong>となっています。</p>
<p>その前提知識を踏まえた上で、最近新たに登場した「Swift Build」の立ち位置と可能性について解説されています。<br>
<strong>Swift Buildは、XcodeおよびSPMの両方において「llbuildマニフェストの生成」を行えるツール</strong>です。これにより、機能差の軽減や新たな機能追加が見込まれています。</p>
<hr>
<p>Swiftのビルドシステムの仕組みを、馴染みのない人でも難なく理解できるよう、丁寧に解説されています。<br>
このテーマがここまで分かりやすく解説されるのは希少だと思いますので、ぜひアーカイブが公開されたら視聴をお勧めしたいです。</p>
<hr>
<h3>3. Embedded Swiftで解き明かすコンピューターの仕組み</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.2903%;"><iframe title="Embedded Swiftで解き明かすコンピューターの仕組み | ドクセル" src="https://www.docswell.com/slide/5QX77N/embed" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen></iframe></div>
<p>このセッションは、<strong>Embedded Swift</strong>と<strong>MMIO (メモリマップドI/O)</strong> を使い、OSのないベアメタル環境でコンピューターをゼロから動かす仕組みを紹介しています。</p>
<p>コンピューターの中心には<strong>CPU</strong>があり、機械語で書かれた命令を実行して動作します。<br>
このCPUが実行できる命令セット (ISA) は、画面表示やネットワーク通信といった複雑な機能を直接含んでいる訳ではありません。</p>
<p>画面表示やネットワーク通信といった、周辺機器 (GPUやストレージなど) の制御に使われるのが、<strong>MMIO (メモリマップドI/O)</strong> です。<br>
MMIOは、GPUなどの周辺機器をメモリ上の一領域とみなし、特定アドレスへデータの読み書きを介して、周辺機器をコントロールする技術です。</p>
<p><strong>Embedded Swift</strong>を使用することで、特定のメモリアドレスを直接操作できる、すなわちMMIOが可能となります。Embedded SwiftによるMMIOの実演として、Raspberry Piの画面を操作して、Swiftのロゴを画面に表示するデモが行われました。</p>
<hr>
<p>コンピュータの動作原理の核心に迫る内容で、個人的に非常に面白かったセッションです。<br>
説明が丁寧、かつ実演もあり、低レイヤに詳しくない人でも知的好奇心を満たされる内容かと思います。</p>
<hr>
<h3>4. アセンブリで学ぶCPUアーキテクチャ</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="Learn CPU architecture with Assembly" src="https://speakerdeck.com/player/6220b9f1e63846039dad83abc0dfcba8" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>Intel Macのサポート終了が発表され、Apple Siliconへの完全移行という転換点を迎えた今、<strong>アセンブリ言語を通じて、CPUアーキテクチャの仕組みを学ぼう</strong>というセッションです。</p>
<p>まず、これまでのMacにおけるCPUの歴史を振り返っています。<br>
Macはこれまで、<strong>Motorola 68k (CISC)</strong> → <strong>PowerPC (RISC)</strong> → <strong>Intel x86 (CISC)</strong> → <strong>Apple Silicon (RISC)</strong> のように、命令セット (ISA) が複雑な<strong>CISCアーキテクチャ</strong>と、命令が単純な<strong>RISCアーキテクチャ</strong>の間を行き来してきました。このアーキテクチャ移行を裏で支えてきたのが、Rosettaのようなエミュレーション技術です。</p>
<p>続いて、アセンブリ言語の基礎が解説されています。アセンブリとは、機械語と1対1で対応する低レベルなプログラミング言語です。<br>
このセッションでは、<strong>「Hello, World!」の出力をアセンブリで行うことで、CPUの動作原理を解説</strong>しています。同じ処理でも、 CISC と RISC でアセンブリの記述が変わることも示されました。</p>
<p>最後に、実務的な応用例として、アプリがクラッシュした際のスタックトレースを読む際に、アセンブリの知識がどのように役立つかが紹介されました。</p>
<hr>
<p>3.のセッション (Embedded Swiftで解き明かすコンピューターの仕組み) と同様、コンピュータの動作原理を解説した内容ですが、異なるレイヤーにフォーカスした解説となっています。<br>
両方のセッションを聴講したことで、コンピュータの動作原理をより立体的に理解できました。</p>
<p>アプリ開発をしていると、時たま「あるライブラリがApple Siliconでは動かない」など、CPUアーキテクチャを意識せざるを得ない場面に遭遇するかと思います。そういった場面に備えて、低レイヤーの理解を深める上で良いセッションかと思います。</p>
<hr>
<h2>おわりに</h2>
<p>iOSDC Japan 2025の3日間、弊社ブースへ多くの方々にお立ち寄りいただきました。<br>
アプリのグロースに関する課題感から、KARTEのご紹介まで、皆さんと直接お話しできたことは、私たち開発チームにとって大変有意義でした。</p>
<p>本記事でご紹介したセッションは、私の個人的な興味から低レイヤー寄りの内容が多くなりました。<br>
私と同じくコンピュータサイエンスの探求が好きなモバイルエンジニアの方がいらっしゃいましたら、ぜひカジュアル面談でお話ししましょう！</p>
<p>プレイドでは、以下のポジションで<strong>モバイルエンジニアを積極的に採用</strong>しています。<br>
ご興味のある方は、ぜひリンク先の募集要項をご覧ください。</p>
<ul>
<li><a href="https://open.talentio.com/r/1/c/plaid/pages/102069">Mobile App SDK Engineer</a></li>
<li><a href="https://open.talentio.com/r/1/c/plaid/pages/106290">アプリエンジニア（新規プロダクト開発）</a></li>
</ul>
<p>最後に、この素晴らしいカンファレンスを企画・運営してくださったスタッフの皆様、そして私たちのブースに足を運んでくださった全ての参加者の皆様に、心より感謝申し上げます。</p>


プレイドは、2025年9月19日〜21日に開催された iOSDC Japan 2025 にゴールドスポンサーとして協賛し、ブース出展も行いました。 本記事では、当日のブースの様子と、聴講した中で特に印象的だった4つのセッションについてご紹介します。

iOSDC Japan 2025参加レポート｜ブース出展の裏側と印象に残ったセッション4選

巨大モノレポ環境でのDeveloper Experience改善に挑戦したプレイドのサマーインターン体験記。CI効率化や社内ESLintプラグイン開発、pnpm catalog移行など技術的成果と、柔軟な労働・開発環境のリアルな様子を詳しく紹介します。

プレイドインターン体験記：巨大モノレポとDeveloper Experienceの改善

<p>KARTE for Appチームのエンジニアの悴田です。</p>
<p>プレイドは、この度<a href="https://2025.droidkaigi.jp/">DroidKaigi 2025</a>にゴールドスポンサーとして協賛し、ブースの出展も行いました。<br>
この記事では、弊社のブースの内容を紹介するとともに、Mobile SDKエンジニアとしての視点から特に役立つと感じたセッションを5つ紹介します。</p>
<h2>ブースの紹介</h2>
<p>プレイドでは、モバイルアプリ向けのプロダクトとして「<a href="https://karte.io/package/app/">KARTE for App</a>」と、Native UIの開発生産性向上を目的とした新規プロダクト (本記事公開時点ではクローズドベータ)、の2つを提供しています。</p>
<p>今回のブース企画・運営は、これら2チームのメンバーを中心に行いました。</p>
<img src="https://ik.imagekit.io/plaid/93e1f423-a525-4a9e-bb76-406b77361c58/IMG_5834.jpeg" width=400 />
<h3>ブースのコンテンツ</h3>
<p>ブースでは、以下の2つのコンテンツを用意しました。</p>
<h4>アプリグロースの課題に関するアンケート</h4>
<p>アプリグロースにまつわる課題について、該当するものにシールを貼っていただく形式でアンケートを実施しました。マーケティング寄りの質問でしたが、ほとんどの参加者がアプリグロースに関して何らかの課題を実感していることが分かりました。<br>
アンケートや来場者との会話を通じて得られた知見は、今後の新機能開発に活かしていきたいと考えています。</p>
<img src="https://ik.imagekit.io/plaid/ccb69b8b-6a0b-4db1-b0fd-b3421fd20c3a/IMG_7536.JPG" width=400 />
<h4>マーケティングツールの利用に関するWebアンケート</h4>
<p>マーケティングツールの利用状況に関するWebアンケートにご回答いただいた方に、抽選で技術書をプレゼントしました。外れてしまった方々にも、ノベルティグッズをお渡ししました。<br>
また、このアンケート自体がKARTEで作成されたものであり、来場者の方々にKARTEの機能を実際に体験していただくきっかけにもなりました。</p>
<img src="https://ik.imagekit.io/plaid/aacf9cea-6000-4fc9-b75d-3fb4b55172d8/IMG_7534.jpeg" width=400 />
<h3>ブース運営の雑感</h3>
<p>結果として、多くの方々にブースへ立ち寄っていただけました。<br>
既にKARTEを利用されている方・過去に利用経験のある方も少なくなかった一方で、「プレイド/KARTEを知らなかった」という方も依然として多く存在しました。<br>
モバイルアプリ領域におけるプレイドの認知度・プレゼンス向上に、引き続き取り組んでいきたいと感じました。</p>
<h2>SDK開発に役立つセッション</h2>
<p>Mobile SDKエンジニアの視点から、特に役立つと感じたセッションを5つ紹介します。</p>
<h3>1. Androidライブラリアンの手引き：堅牢なライブラリとSDKの構築</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.25%;"><iframe title="DroidKaigi 2025 - [EN] Android Librarian&#39;s Guide: Building Robust Libraries a… | Jaewoong (skydoves)" src="https://www.youtube.com/embed/0K_X4uNbU8U?rel=0" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no" allow="accelerometer *; clipboard-write *; encrypted-media *; gyroscope *; picture-in-picture *; web-share *;"></iframe></div>
<p>このセッションでは、Androidアプリ向けに堅牢なライブラリやSDKを提供するために必要なテクニックが体系的に紹介されています。</p>
<p>具体的に触れられていた内容は以下の通りです。</p>
<ul>
<li><strong>APIの可視性コントロール</strong>：@JvmSynthetic アノテーションや Explicit API Mode の活用。</li>
<li><strong>APIライフサイクル管理と互換性維持</strong>：@Deprecated アノテーションやマニュアルへの明示。</li>
<li><strong>バイナリ互換性</strong>：概念の解説に加え、検証ツール (Binary Compatibility Validator、 Metalava) の使い方と比較。</li>
<li><strong>リソース管理</strong>：SDKのリソースを非公開にする方法。&lt;public /&gt; タグによる検出、resourcePrefix を使った名前衝突の回避。</li>
<li><strong>推移的依存関係</strong>：推移的依存関係による課題。implementation/api の適切な使い分け、Non-transitive R class の活用。</li>
</ul>
<p>全体を通して、SDK開発に携わる上で押さえておきたい注意点が整理されており、実務に直結する内容でした。<br>
またセッション後には、ブースで発表者の方に直接「SDKのKotlinバージョンをどのように決定・更新しているか」といった技術的な質問をする機会があり、丁寧に答えていただけたのも印象に残りました。</p>
<h3>2. そのAPI、誰のため？ Androidライブラリ設計における利用者目線の実践テクニック</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.25%;"><iframe title="DroidKaigi 2025 - [JA] そのAPI、誰のため？ Androidライブラリ設計における利用者目線の実践テクニック | mkeeda" src="https://www.youtube.com/embed/uNDOE0JSRls?rel=0" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no" allow="accelerometer *; clipboard-write *; encrypted-media *; gyroscope *; picture-in-picture *; web-share *;"></iframe></div>
<p>発表者が社内ライブラリの開発を通じて得られた学びを紹介するセッションです。<br>
1.のセッションと同様にライブラリ設計を扱っていますが、1.は「堅牢な設計にすること」をテーマとしていたのに対し、本セッションは「<strong>ユーザーフレンドリーな設計にすること</strong>」にフォーカスしています。</p>
<p>具体的には、以下を意識することが推奨されています。</p>
<ul>
<li>カプセル化を徹底し、利用者が内部実装を意識せずに使えるようにする。</li>
<li>利用者側の技術スタックに、できるだけ非依存にする。例えば、特定のUIフレームワークやDIライブラリの利用を前提としないようにする。</li>
<li>一般にライブラリの機能を増やすと、自由度 (カスタマイズ性) は低下する傾向にある。機能性と自由度を両立する手段として、コアの低レベルなモジュールと、アプリケーション寄りの高レベルなモジュールを、別々のモジュールとして提供する方法がある (e.g. Jetpack Composeの設計)。</li>
<li>コードコメントやドキュメントを充実させる。ユーザーフレンドリーなライブラリになるだけでなく、設計の良し悪しに気づくきっかけにもなる。</li>
<li>ライブラリの使い勝手を知るには、自分でそのライブラリの利用者になってみるのが良い。サンプルアプリを作ることも有効である。</li>
</ul>
<p>なお、KARTE for AppのMobile SDKにおいても、ここで挙げられているような「SDKの依存ライブラリを減らす」や「マルチモジュール方式でcoreライブラリと機能ごとのモジュールに分けて提供する」といった工夫がなされています。</p>
<h3>3. 厄介な依存関係：サードパーティライブラリのバグを乗り切り修正する方法</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.25%;"><iframe title="DroidKaigi 2025 - [EN] Nasty Dependencies: Surviving and fixing bugs in 3rd-party libra… | Yury Vlad" src="https://www.youtube.com/embed/hYH21Ttlbjs?rel=0" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no" allow="accelerometer *; clipboard-write *; encrypted-media *; gyroscope *; picture-in-picture *; web-share *;"></iframe></div>
<p>このセッションでは、Androidアプリ開発において避けて通れない「サードパーティライブラリ起因のバグ」への対処法が体系的に紹介されています。</p>
<p>具体的には、以下のようなテクニックが解説されています。</p>
<ul>
<li><strong>ローカル環境での修正・動作確認</strong>
<ul>
<li>Gradle Assemble、Composite Build、Git Submodule、Local Maven Repository、Remote Maven Repositoryなどの各種方法を比較する。</li>
</ul>
</li>
<li><strong>修正版ライブラリの利用方法</strong>
<ul>
<li>オープンソースライブラリの場合：upstreamにバグ修正を反映する方法。</li>
<li>クローズドソースライブラリの場合：リフレクションやバイナリ操作ツール (Recaf) を用いてパッチを当てる方法。</li>
</ul>
</li>
</ul>
<p>アプリ開発者にとって有用なのはもちろんですが、SDK開発者の立場から見ても「依存ライブラリに起因する問題をどう扱うか」は避けて通れないテーマです。ライブラリの仕組みを理解し、場合によっては自ら修正・回避できる能力の重要性を改めて感じました。</p>
<h3>4. 例外のその先へ：セーフティクリティカル原則に基づき堅牢なAndroidアプリを構築する</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.25%;"><iframe title="DroidKaigi 2025 - [EN] Beyond Exceptions: Building Resilient Android Apps with S… | Bogusz Pawłowski" src="https://www.youtube.com/embed/c-OO-8diTpk?rel=0" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no" allow="accelerometer *; clipboard-write *; encrypted-media *; gyroscope *; picture-in-picture *; web-share *;"></iframe></div>
<p>Kotlinにおけるエラーハンドリングのベストプラクティスを紹介したセッションです。</p>
<p>メインとなる主張は「ドメインロジックのエラーを例外 (Exception) で表現しない」という点です。例外を網羅的にハンドリングするには、内部実装を知ることが必要となります。また、スタックトレース取得のオーバーヘッドも大きいです。</p>
<p>一方で、Kotlin組み込みの Result 型を使う方針には、以下のような課題があるとされています。</p>
<ul>
<li>不要な例外クラス生成を伴う。</li>
<li>網羅的ハンドリングができない。</li>
<li>Result.runCatching が Kotlin CoroutinesのCancellationException を補足してしまう。</li>
</ul>
<p>また、Kotlin公式側でも、Result型はDomain Specificなエラーのハンドリングには使うべきでないとされています。<br>
<a href="https://github.com/Kotlin/KEEP/blob/main/proposals/stdlib/KEEP-0127-result.md#error-handling-style-and-exceptions">https://github.com/Kotlin/KEEP/blob/main/proposals/stdlib/KEEP-0127-result.md#error-handling-style-and-exceptions</a></p>
<p>適切なエラーの表現手段としては、軽量に済ませたい場合は null、丁寧に扱う場合は sealed interface などを用いたカスタムクラスの定義が推奨されています。<br>
さらに、将来的な選択肢として、Kotlin 2.4で導入予定の「Rich Errors」というUnion型のような言語機能も紹介されています。<br>
参考：<a href="https://youtu.be/IUrA3mDSWZQ?feature=shared">Rich Errors in Kotlin | Michail Zarečenskij</a></p>
<p>タイトルには「Androidアプリ」とありますが、ライブラリやサーバーサイドにおけるKotlinの利用も含めた、幅広い領域で役立つ内容でした。</p>
<h3>5. プロパティベーステストによるUIテスト: LLMによるプロパティ定義生成でエッジケースを捉える</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.25%;"><iframe title="DroidKaigi 2025 - [JA] プロパティベーステストによるUIテスト: LLMによるプロパティ定義生成でエッジケースを捉える | Tetta Noguchi" src="https://www.youtube.com/embed/ur-w06-L6SU?rel=0" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no" allow="accelerometer *; clipboard-write *; encrypted-media *; gyroscope *; picture-in-picture *; web-share *;"></iframe></div>
<p>このセッションでは、Property Based Testing (PBT) の概要と、Jetpack ComposeベースのAndroidアプリにおけるUIテストへの応用が紹介されています。</p>
<p>一般に使われるExample Based Testing (EBT) では、事前に用意したテストケースに沿ってテストを行いますが、PBTは入力や状態をランダムに生成してより網羅的にテストできる点が特徴です。もっとも、EBTと対立するわけではなく、相互に補完し合うアプローチとして位置づけられます。</p>
<p>発展的な内容として、ステートフルなシステムに対するPBTの適用方法や、LLMを活用してプロパティ定義を自動抽出する試みも紹介されています。</p>
<p>PBTは学習・導入コストが高く、私自身もまだ実際のプロダクトで活用した経験はありません。<br>
一方で、テスト自動化はSDK開発においても重要なトピックの一つであり、網羅的な検証が要求される場面で使えるよう、PBTの実装方法と特性を把握しておかねばと思いました。</p>
<h2>最後に</h2>
<p>今回、私は初めてDroidKaigiに参加しましたが、ブースでの会話やセッションを通じて多くの学びを得られ、とても有意義で、何より楽しい時間を過ごすことができました。来場者の方々からいただいたユーザー目線でのフィードバックや、各セッションで得られた技術的な知見は、今後のプロダクト開発に活かしていきたいと考えています。</p>
<p>プレイドの<strong>KARTE for Appチーム</strong>および<strong>新規プロダクト開発チーム</strong>では、現在モバイルエンジニアを募集しています。あらゆるモバイルアプリにおける顧客体験やデータ分析、開発生産性向上の基盤となるSDK開発にご興味のある方は、ぜひカジュアルにお話ししましょう！</p>
<ul>
<li><a href="https://open.talentio.com/r/1/c/plaid/pages/102069">Mobile App SDK Engineer</a></li>
<li><a href="https://open.talentio.com/r/1/c/plaid/pages/106290">アプリエンジニア（新規プロダクト開発）</a></li>
</ul>
<p>最後に、カンファレンスの運営に携わってくださった皆様、そしてブースに立ち寄ってくださった皆様に、心より感謝申し上げます。</p>


プレイドは、この度DroidKaigi 2025にゴールドスポンサーとして協賛し、ブースの出展も行いました。この記事では、弊社のブースの内容を紹介するとともに、Mobile SDKエンジニアとしての視点から特に役立つと感じたセッションを5つ紹介します。

DroidKaigi 2025参加レポート｜SDK開発に役立つ5つのセッション

<p>こんにちは。プレイドでエンジニアをしている、とさです。</p>
<p>今回は、2025年6月13日(金)に開催した、社内のAI Agent開発ハッカソンのレポートをお届けします。</p>
<h3>1. はじめに</h3>
<h3>開催の背景と目的</h3>
<p>現在プレイドでは、提供するプロダクト上にAI機能を組み込むためのプロジェクト進めていて、mastraを用いた開発環境の整備やPOC（概念実証）を通して、組み込みの方向性を模索しています。</p>
<p>このプロジェクトの一環として、私たちは「動くAI Agentを作る実践の場」として、社内ハッカソンを企画しました。</p>
<p>このイベントは、単なる開発コンテストではありません。</p>
<ul>
<li><strong>技術の筋トレ:</strong> 最新のAI技術に触れ、実践的な開発スキルを磨く。</li>
<li><strong>チーム横断開発の種まき:</strong> 部署の垣根を越えたコラボレーションを生み出し、組織全体の開発力を底上げする。</li>
</ul>
<p>これらを同時に達成し、プロダクトへのAI組み込みの速度と質を向上させることが、私たちの大きな狙いです。</p>
<p>今回のAI Agent開発は、実際にAI機能開発でも利用されているプラットフォーム「mastra」上で行われました。参加者は普段の業務に近い本格的な環境で、実践的な開発に挑戦しました。</p>
<p><a href="https://mastra.ai/blog/plaid-jpn-gcp-agents">Why PLAID Japan builds agents on their Google Cloud infrastructure with Mastra</a></p>
<p>Mastra社の技術ブログでもプレイドのことを取り上げてくださいました。</p>
<h3>イベントの概要</h3>
<ul>
<li><strong>日時:</strong> 2025年6月13日(金) 13:00 - 19:00</li>
<li><strong>場所:</strong> オフィス（芝生エリア）。</li>
<li><strong>参加者:</strong> エンジニアを中心に約20名。</li>
<li><strong>開発テーマ:</strong> プロダクトのAPIを活用した、便利なAI Agentを開発する。</li>
</ul>
<p>半日という短い時間で、ローカル環境に「ミニマム」で「動く」AI Agentを開発することを目指しました。</p>
<h3>2. 当日の様子</h3>
<p>当日は、オフィス内の開放的な芝生エリアにメンバーが集結。午後1時のキックオフから開始しました。</p>
<p><img src="https://ik.imagekit.io/plaid/216860f9-1624-475d-9802-ca4769139972/image1.png" alt="image1.png"></p>
<p>最初のアイデア出しでは、「どのような課題を解決しようか」「どのようなAgentが便利か」と、多くのチームが議論に苦戦している様子も見られました。しかし、そこからがエンジニアの腕の見せ所です。徐々にアイデアが固まると、各々が猛烈な勢いでコーディングに集中し始めました。</p>
<p><img src="https://ik.imagekit.io/plaid/1fa28090-0a1d-4d79-856b-69e67bce2b34/image2.png" alt="image2.png"></p>
<p>真剣な表情でモニターに向かう姿、チームメンバーと活発に意見を交わす姿、そして時折見せる笑顔。限られた時間の中で、ものづくりを楽しむ参加者のエネルギーが会場全体に満ちていました。</p>
<p>さらに驚くべきは、今回のハッカソンには開発経験が必ずしも多くない新卒メンバーやカスタマーエンジニアも参加し、開発環境のセットアップから始めたにもかかわらず、発表までの短い時間で全員がAI Agentを完成させたことでした。これも、開発をサポートするAI Coding Agent自体の進化が後押しした結果と言えるでしょう。</p>
<p><img src="https://ik.imagekit.io/plaid/d3dcf93a-55e0-4a01-a316-9f74d5d2e32d/image3.png" alt="image3.png"><br>
<img src="https://ik.imagekit.io/plaid/d3dcf93a-55e0-4a01-a316-9f74d5d2e32d/image3.png" alt="image1.pngimage2.pngimage3.png"></p>
<h3>3. チームと成果物の紹介</h3>
<p>夕方からは、いよいよ成果発表会です。短時間でAI Agentが次々と生み出されました。ここで参加者が作成したAI Agentたちをいくつかご紹介します。</p>
<h3>実際に開発されたAI Agentの一例</h3>
<ul>
<li>クエリGUIの「ノード説明Agent」</li>
<li>面倒な入力を一瞬で終わらせる「フォーム自動入力ツール」</li>
<li>クエリGUIの「エラー解説＆ノード名提案Agent」</li>
<li>ローカルクラスタ用の「自然言語データ検索Agent」</li>
<li>30分で実装した「記事要約＆関連記事提示Agent」</li>
<li>営業の強い味方となる「業界別・事例検索Agent」</li>
<li>企業情報への「自動タグ付けAgent」（への道）</li>
</ul>
<p>実際のプロダクトのローカル環境に組み込んでデモしてくれたチームもありました。</p>
<h3>4. 参加者の声</h3>
<p>イベント後、参加者から多くのフィードバックが寄せられました。その一部をご紹介します。</p>
<h3>良かったこと・新たな発見</h3>
<p>最も多くの参加者が口にしたのは、**「AI Coding Agentの発達の凄さ」と「チームで開発する楽しさ」**でした。「数時間でみんなが成果物を作れていた」「普段関わりのないメンバーと機能開発の面で交流できたのが貴重だった」といった声が上がりました。</p>
<p>また、「mastraやKARTEの中身も軽く知ることができ、KARTEそのものの理解も深まった」という副次的な効果を実感した参加者もいました。</p>
<h3>改善点・今後の期待</h3>
<p>一方で、**「アイデア出しの難しさ」**も浮き彫りになりました。「アイデアソンの前にmastraへの理解を深めていれば、もっと良いアイデアが出せたかも」といった声や、「まずmastraを触ってからアイデアを出す方がやりやすかった」という意見が多く聞かれました。中には、「事前にアイデア出しのフェーズを設け、アイデアを出す人と作る人が分かれて参加できる形式も良いのでは」といった具体的な提案もありました。</p>
<p>また、「KARTE上での実装を楽にしてくれるツールが欲しい」という声が多数寄せられました。特に、以下のような実践的な開発をサポートする機能への期待が高まっています。</p>
<ul>
<li>複雑な接客作成をサポートする、社内ナレッジを学習したエージェント</li>
<li>PdMやデザイナーが開発セットアップなしで簡単に動作確認できる環境</li>
<li>本格導入に向けたエージェントの評価の仕組み</li>
</ul>
<h3>5. ハッカソンを終えて</h3>
<p>最後に、参加者から寄せられた「今回感じたこと」が、今回のハッカソンのリアルな学びを象徴していたのでご紹介します。</p>
<ul>
<li><strong>Vibe codingの限界:</strong> 本当に知識がないと、投げるプロンプトが曖昧になり、痒い所に手が届かない。</li>
<li><strong>Agent化の必要性:</strong> 今やっている作業は、本当にAgentにする必要があるのか、と作りながら考えさせられた。</li>
<li><strong>AIとの対話の難しさ:</strong> なぜAIがWebサイトをしっかり調べにいかないのか、プロンプトが細かすぎるのかなど、AIの挙動をコントロールする難しさを感じた。</li>
</ul>
<p>ツールを使えば誰でも簡単に作れるように見えて、実は深いドメイン知識やプロンプトエンジニアリングの技術が求められます。AI開発のリアルな手触り感を得られたことも、大きな収穫でした。</p>
<h3>6. 謝辞</h3>
<p>このハッカソンの成功は、参加者の皆さんの情熱と創造性、そして企画・運営に奔走してくださった運営・サポートメンバーの尽力のおかげです。</p>
<p>この場を借りて、イベントに関わったすべての方々に心から感謝申し上げます。ありがとうございました。</p>
<h3>7. おわりに</h3>
<p>今回のハッカソンは、社内に眠る技術力と創造性を再発見する、素晴らしい機会でした。半日という短い時間で、これだけ多様なAI Agentが生まれたことに驚きました。</p>
<p>そして、早くも第2回の開催が決定しました。次回は、より多くの職種のメンバーが参加できるよう「アイデアソン」形式での開催を予定しています。</p>
<p>このハッカソンをきっかけに生まれた熱量を、今後のプロダクト開発、そして組織全体の力へと繋げていきます。</p>
<p>今後のプレイドのプロダクトとAIの進化にご期待ください。</p>


社内AI Agent開発ハッカソンレポート｜半日で20名が挑んだ“動くAI”づくり

<h2>はじめに</h2>
<p>はじめまして、プレイドにて8月の1ヶ月間エンジニアインターンに参加しておりました、中村天晴と申します。プレイドではJourneyチームで、定期実行基盤に関するタスクに取り組んでいました。</p>
<p>本ブログでは自分がプレイドにて行った仕事を紹介しつつ、プレイドでの働き方やインターンの魅力をお伝えできればと思います。</p>
<h2>Journeyとは</h2>
<p>具体的な仕事内容をご紹介する前に、KARTEが持つ「Journey」という機能を紹介させていただきます。</p>
<p>JourneyとはKARTEで得られたユーザ行動を元に、シーンやシナリオに合わせてより1人ひとりの行動にあわせたアクションを実行する機能です *1</p>
<p>*1: <a href="https://karte.io/product/journey/">KARTE Journey</a></p>
<p>例えば、「商品をカートに入れたままサイトを離れたユーザに、翌日プッシュ通知でクーポンを送る」といった複雑なシナリオを、管理画面で簡単に作成・配信することができます。</p>
<p>内部の仕組みとしては「定期実行基盤」と呼ばれるバッチジョブが存在し、このジョブが定期的に実行されることでユーザがシナリオ上のステップからステップに移動しています。</p>
<p>Journeyは現在ベータ版の機能として提供しており、今後より多くのニーズに応えられるよう定期実行基盤の改善を進めています。</p>
<h2>分岐ノードのデバッグ</h2>
<p>ここからは、実際に自分が担当した仕事を紹介していきます。</p>
<p>Journeyではユーザの各ステップを「ノード」という形で表現しており、管理画面上でノードを繋ぎ合わせることで複雑なシナリオを設定します。</p>
<p>今回自分は「分岐ノード」と呼ばれる、ユーザを属性によって異なるノードへと進めるためのノードを作り直す作業に取り組みました。</p>
<p><img src="https://ik.imagekit.io/plaid/7a976b2d-f83a-4e51-b5a8-15225c04d78b/mermaid-diagram-2025-08-28-123417.png" alt="mermaid-diagram-2025-08-28-123417.png"></p>
<p>定期実行基盤には、大きく2つの要件があります。1つは数百万規模のユーザを遅延なく処理できること、もう1つは「カートに入れたが購入しなかった」といったユーザごとの複雑な条件を計算できることです。</p>
<p>この要件を満たすため、アーキテクチャは工夫されており、「次にシナリオを進めるべきユーザを計算・抽出するコンポーネント」と、「実際にそのユーザの状態を次のステップに移動させるコンポーネント」というように、役割が明確に分割されています。</p>
<p>自分が開発に関わり始めた時点で新しい分岐ノードに対応する実装は完了していたのですが、一連の処理が正しく実行できる状態になっていませんでした。自分は、一連の処理が正しく実行されない原因を究明し、処理が完了できるようにするため様々な修正を行いました。</p>
<ul>
<li>コンポーネント間で参照しているデータベースが異なっていたため修正</li>
<li>コンポーネント間でハッシュの生成方法に差異があったため修正</li>
<li>分岐判定の誤り原因を調査するためデバッガーを導入</li>
<li>分岐ノードで分岐条件を正しく判定できても、実際に分岐先にユーザが移動しない問題の修正</li>
<li>評価環境と開発環境の差分をなくすためのマイグレーションの実施</li>
</ul>
<p>動かない間はひたすらクラウドサービスのコンソールを眺める時間が続き大変でしたが、分岐ノードのテストが正しく動作した時は本当に嬉しく感じました。</p>
<h2>BigQueryのオプションジョブ作成モードの適用</h2>
<p>Journeyでは一部でBigQueryを利用しています。インターンではパフォーマンス向上とコスト効率化を目指し、BigQueryの改善にも取り組みました。</p>
<p>BigQueryには8月からクエリが短い場合にジョブを作成せずにジョブを実行することができる昨日「オプションジョブ作成モード」が追加されました。*2</p>
<p>*2: <a href="https://cloud.google.com/bigquery/docs/running-queries?hl=ja#optional-job-creation">オプションジョブ作成モード</a></p>
<p>この機能がベータとしてリリースされた当初からJourneyではこのモードを利用するために、当時ドキュメントに記載されていた <code>QUERY_PREVIEW_ENABLED</code> という環境変数を適用していました。しかし、調査してみるとこの環境変数が設定されていてもジョブが常に作成されていることがわかりました。</p>
<p>さらにクライアントライブラリの実装 *3 を調べると、有効化の方法が環境変数での設定からクライアントのオプションとして設定するように変更されていることがわかりました。</p>
<p>*3: <a href="https://github.com/googleapis/nodejs-bigquery/pull/1480">クライアントの実装PullRequest</a></p>
<p>そのため、調査結果を元にオプションジョブ作成モードをクライアント側で明示的に指定するよう変更し、短いクエリの場合にジョブが作成されなくなったことを確認しました。</p>
<h2>プレイドでのインターン生活</h2>
<p>最後にプレイドでのインターン生活で特に印象に残った部分をご紹介します。</p>
<p>Journeyチームでは週次で全体のミーティングがあり、プロダクトの方向性などについての議論が交わされています。自分もそのような会議に基本的に出席するなかで、顧客から求められていることと技術的な制約の間を垣間見ることができました。</p>
<p>そのなかで毎度なぜ技術的な制約があるのかに立ち返りながら、ステークホルダー全員が理解できる形での説明が繰り返されている点から、単なる開発ではなく「仕事」として開発するということを学ぶことができました。</p>
<p>また技術的にも、今ある技術的課題がどこにあるのか、何が原因なのか、短期・長期でどのように解決していくのかといった議論にインターンという身でありながら参加することができたのも非常に面白かったです。</p>
<p>このように単なる開発ではなく、仕事としての開発を感じることができることがプレイドのインターンの一つの魅力だと感じました。</p>
<h2>終わりに</h2>
<p>Journeyは大量の入力があった場合にも問題なく処理できるようにするため、非常に複雑なアーキテクチャとなっています。</p>
<p>今回のインターンでは初回の1on1の際にメンターの方に分からないことを全て質問する機会をいただいたおかげで、期間を通して複雑なアーキテクチャであってもすんなりと理解することができました。 *4</p>
<p>*4: 利用されているマネージドサービスはほとんど触れたことのないものでしたが、期間を通じてそれぞれの強みと利用されている理由を理解することができました。</p>
<p>プレイドでは与えられた仕事だけでなく、自分が「ここはこうした方が良いのではないか」といった提案がインターン生であっても積極的に採用されるフラットな文化があり楽しく過ごすことができました。</p>
<p>実際にはこの記事の中ではなかなかご紹介できない様々な課題に取り組んだため、ぜひプレイドに入社して確かめてみてください！1ヶ月間お世話になりました！</p>


はじめまして、プレイドにて8月の1ヶ月間エンジニアインターンに参加しておりました、中村天晴と申します。プレイドではJourneyチームで、定期実行基盤に関するタスクに取り組んでいました。  本ブログでは自分がプレイドにて行った仕事を紹介しつつ、プレイドでの働き方やインターンの魅力をお伝えできればと思います。

プレイドインターン体験記：大規模ユーザデータを処理する裏側を覗く

<h1>自己紹介</h1>
<p>こんにちは！8月1日からプレイドでインターンをしている<a href="https://my-portfolio-kh49.vercel.app/">櫻井絵理香</a>です。<br>
普段は京都の大学に通っています。</p>
<p>これまでiOS開発をメイン（正直、iOS開発しかほとんどしたことがありませんでした...）でやってきましたが、今回のプレイドでのインターンでは初めてフルスタックで開発をしました。私は今回のプレイドのインターンでは、「モバイルアプリのNative UI構築に関する課題を解決する」新規事業・プロダクト開発のチームに配属されました。</p>
<p>Webのフロントエンド、バックエンド、インフラアーキテクチャ、そしてiOS SDKまで、超フルスタックな体験をさせていただき、自分にとって大きな挑戦となりました。普段慣れ親しんだiOS開発の領域を飛び出して、新しい技術スタックに触れることで多くの学びを得ることができました。<br>
この記事では、そんな貴重な体験について詳しくお話ししたいと思います。</p>
<h1>インターンでの内容</h1>
<h2>デモアプリの実装</h2>
<p>SDKの機能や使用感を実際に体験してプロダクトの理解を深めるために、Figmaのデザインに沿ったデモアプリの実装を行いました。インターン開始時に「やりたいことはあるか？」と聞かれた際、CI構築とテスト実装への挑戦を希望していたため、デモアプリでこれらの技術要素を組み込むことになりました。アプリ開発では実際にSDKをコードベースに統合し、その動作を確認しました。SDKの内部実装を詳細に調査するのは初めての経験でした。<br>
<img src="https://ik.imagekit.io/plaid/01cb494a-cd74-4d5f-9919-7b345945c420/Group1759.png" alt="Group1759.png"><br>
画像はデモアプリのもの</p>
<h2>CIとテスト実装の実践的学習</h2>
<h3>GitHub Actionsによる継続的インテグレーション</h3>
<p>初めてGitHub Actionsを使用し、プルリクエスト時の自動テスト実行環境を構築しました。ワークフローファイルの設定からテスト結果の可視化まで、継続的インテグレーションの仕組みを実践的に学習できました。</p>
<h3><strong>段階的なテスト戦略の確立</strong></h3>
<p>プロジェクトIDの変更をテキストで手動入力することの煩わしさを解決するため、管理画面側でプロジェクトIDをQRコード化し、SDK側で読み取って即座にプロジェクトIDを反映する機能を実装しました。この新機能の品質を保証するため、QRコード読み込み機能を中心としたユニットテストを実装し、Swift Testingフレームワークを使用してViewModelの状態管理をテストしました。</p>
<p>具体的には、QRコード検出時の状態変化、スキャン開始/停止の制御、カメラ権限拒否時のエラーハンドリングなど、ユーザーの実際の使用パターンを想定したテストケースを作成しました。</p>
<p>テスト実装を通じて「何を保証すべきか」という設計思想の重要性を学びました。単純な動作確認だけでなく、スキャン中でない場合のQRコード無視処理や、複数回の検出処理など、境界条件や異常系も含めた包括的な品質保証の考え方を身につけることができました。</p>
<p>一方でUIテストでは従来手法の限界を実感しました。要素特定の困難さ、UI変更への脆弱性、環境依存による不安定性、そして工数の大きさが課題となりました。この解決策として<strong>MagicPod</strong>を導入し、ノーコードでの効率的なUIテスト自動化を実現しました。</p>
<h2>グラデーションカラーの実装</h2>
<p>デモアプリ実装を通じて実際のプロダクトの機能や使用感を掴むことができたため、次のステップとして実際のプロダクトへ新機能を追加しました。プロダクトの管理画面でグラデーションカラーを指定し、それがSDKに反映される機能を実装しました。この実装を通じて、フルスタック開発における問題解決力やスキーマ設計の重要性について多くの学びを得ることができました。特に印象的だったのは、スキーマを定義してmake generateコマンドでコードと型が自動生成される体験と、GraphQLを初めて触ることでプロダクトの根幹部分に関わることの責任感でした。</p>
<h3>実装の全体像</h3>
<p>アーキテクチャは以下のような流れになっています</p>
<ol>
<li>管理画面でグラデーションカラーを指定</li>
<li>データベースとGCSに保存</li>
<li>iOS SDK側でGCSからJSONを読み取り</li>
<li>JSONをパースしてレンダリング</li>
</ol>
<p>以下に動作の流れのイメージ図を記載します。</p>
<p><img src="https://ik.imagekit.io/plaid/e66702ba-fdf2-4f80-932d-e5c1184adc86/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-08-2911.20.06.png" alt="スクリーンショット2025-08-2911.20.06.png"></p>
<h2>フルスタック開発における問題解決力</h2>
<h3><strong>長い連携チェーンでのデバッグの難しさ</strong></h3>
<p>管理画面（フロント）→ バックエンド → GCS → SDK → アプリという長い連携チェーンで開発を進める中で、最も困ったのは「どこで問題が起きているか分からない」状況でした。</p>
<ul>
<li>フロントからバックエンドにJSONが正しく読み込めているか</li>
<li>GCSに正しく送信できているか</li>
<li>SDK側でJSONが正しくパースできているか</li>
</ul>
<p>これらを一つずつ確認していく作業は想像以上に大変でした。</p>
<h3><strong>問題を小さく分割する習慣</strong></h3>
<p>この経験を通じて、問題を小さく絞って解決していく方法が身につきました。各段階でのデータ整合性を確認し、どの部分で失敗しているかを特定する習慣は、今後のフルスタック開発でも必須のスキルだと感じています。</p>
<h2>GraphQLスキーマ設計の責任と互換性管理</h2>
<h3><strong>プロダクトの核となるデータ構造への責任</strong></h3>
<p>GraphQLを触ること自体が初めてで、特にJSONがプロダクトの大事な部分であることを理解した時、その定義から関わることの重大さを実感しました。スキーマの変更がプロダクト全体に与える影響の大きさは、新規プロダクトならではの貴重な体験でした。</p>
<h3><strong>互換性を考慮した設計の重要性</strong></h3>
<p>最も頭を悩ませたのは互換性の問題でした</p>
<ul>
<li><strong>後方互換性</strong>: 古いJSONで新しいSDKが正常に動作するか</li>
<li><strong>前方互換性</strong>: 古いSDKで新しいJSONが処理できるか</li>
</ul>
<p>これらの両方を考慮しながらスキーマを設計することで、将来的な変更に柔軟に対応できる基盤を作ることの重要性を学びました。</p>
<h3>インターンシップで学んだコーディングの基本</h3>
<p>インターン期間中に最も重要だと実感したのは、レイヤー構造を意識したコード設計です。各層の役割を明確に分離し、適切な抽象化レベルを維持することの重要性を学びました。<br>
単一のモジュールで複数の概念を同時に定義してしまうと、コードの保守性が著しく低下することを実際の開発で経験しました。プレゼンテーション層、ビジネスロジック層、データアクセス層といった責務の分離により、システム全体の理解しやすさと拡張性が大幅に向上することを実感できました。</p>
<h3>Claude Codeでの限界</h3>
<p>Claude Codeは非常に有効なツールですが、その限界についても理解を深めました。新規のiOSアプリ開発のような、ゼロから構築する慣れ親しんだ技術領域では優秀な開発パートナーとして機能しました。<br>
しかし、既存のWebアプリケーションなど、触ったことのない技術スタックでは期待通りの結果を得ることが困難でした。コードが動作するだけでは不十分で、なぜそのような実装を選択したのかという設計思想の理解が不可欠であることを学びました。ツールに依存するのではなく、各コードの抽象化レベルを正確に把握し、システム全体の中での位置づけを理解することの重要性を実感しました。あと、めっちゃ重複でコード書いてくる。差分だけ見ててもダメ、既存のアプリだとすでに実装済みのものがあるかもしれないので、そこを注意しなければならないと感じました。</p>
<h3>まとめ</h3>
<p>今回のグラデーションカラー機能の実装は、単なる機能追加を超えて、フルスタック開発における多くの重要な概念を学ぶ機会となりました。特に以下の点は今後の開発でも大切にしていきたいと思います</p>
<ul>
<li><strong>問題を小さく分割し、段階的にデバッグする習慣</strong></li>
<li><strong>スキーマ設計における互換性への配慮</strong></li>
<li><strong>自動生成ツールを活用した開発効率の向上</strong></li>
<li><strong>プロダクト全体のアーキテクチャを意識した設計</strong></li>
</ul>
<p>フルスタック開発は確かに複雑で困難な面もありますが、プロダクト全体を俯瞰し、エンドユーザーまでの一連の流れを自分の手で作り上げることができる魅力的な野だと改めて感じました。今回の経験を活かして、より良いプロダクト開発に貢献していきたいと思います。</p>
<h1>プレイドで働いてみての感想</h1>
<p>これまでの私の開発経験は主にiOSアプリ開発に限定されており、SwiftとFirebaseを中心とした比較的狭い技術スタックでの開発が中心でした。しかし、今回のインターンでは初めてフルスタック開発に挑戦し、フロントエンドからバックエンドまでの一連の開発フローを体験することができました。この経験は、技術者としての視野を大きく広げる貴重な機会となりました。</p>
<p>他のインターン先で既存アプリケーションの保守・運用は経験したことはあるのですが、今回は新規プロダクトの機能開発に携わることができました。ゼロから機能を設計・実装していく過程は新鮮で、プロダクトが成長していく様子を間近で見ることができたのは非常に貴重な体験でした。スタートアップフェーズのプロダクト開発に関わることで、技術的な判断だけでなく、ビジネス観点も含めた総合的な開発プロセスを学ぶことができました。</p>
<p>プレイドでは、オンライン・オフライン問わず、チームメンバーとのコミュニケーションが非常に取りやすく、疑問点があれば気軽に相談できる雰囲気がありました。そのため、インターン期間を通じて楽しみながら多くのことを学ぶことができ、充実した時間を過ごすことができました！<br>
<img src="https://ik.imagekit.io/plaid/6c2d4724-8115-4a53-8de3-b095626aa231/IMG_0619.jpg" alt="IMG_0619.jpg"></p>


こんにちは！8月1日からプレイドでインターンをしている櫻井絵理香です。今回のプレイドのインターンでは、Webのフロントエンド、バックエンド、インフラアーキテクチャ、そしてiOS SDKまで、超フルスタックな体験をさせていただき、自分にとって大きな挑戦となりました。普段慣れ親しんだiOS開発の領域を飛び出して、新しい技術スタックに触れることで多くの学びを得ることができました。 この記事では、そんな貴重な体験について詳しくお話ししたいと思います。

プレイドインターン体験記：初めてフルスタックでの開発

<h2>はじめに</h2>
<p>こんにちは！8月からの1ヶ月間サマーインターンとしてプレイドで働いていた蜂須賀大智です。個人でWebアプリケーションを開発したり、他社で少し開発経験を積んだりする中で、自身のフロントエンドの技術力をさらに高めたいという思いがありました。そんな中、サポーターズの1on1イベントでプレイドという会社を知り、面談を重ねるうちに事業の面白さに惹かれ、インターンとして働くことになりました。このブログでは、私がプレイドでインターンとしてどのような課題に取り組んだか、そこから何を学んだかについてお話しさせていただきたいと思います。</p>
<h2>KARTE messageについて</h2>
<p><a href="https://karte.io/package/message/">KARTE Message</a>は、クライアント企業が保有するデータをもとに、メールやプッシュ通知、LINEのメッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<h2>取り組んだタスク</h2>
<p>今回のサマーインターンで取り組んだタスクは、キャンペーン編集画面における未保存の変更に対する警告機能の実装です。<br>
KARTE Messageにおけるキャンペーンとは、特定のターゲットユーザーに対してメール、アプリプッシュ、LINEなどのマーケティング施策を一括で設定し、実行するための機能です。キャンペーンの設定は「配信タイプ」「対象ユーザー」「アクション」「スケジュール」　の4つの要素で構成されています。すべての設定が完了し、キャンペーンを「実行」すると、指定したチャネルを通じてクリエイティブをターゲットユーザーに届けることができます。<br>
今回、解決したかった課題は、「キャンペーンの新規作成・編集中に、入力・変更した内容を保存せずに他のページへ移動すると、その内容がすべて失われてしまうこと」　でした。</p>
<p>※以下の画像は、実装した警告機能です。</p>
<p><img src="https://ik.imagekit.io/plaid/08d05abc-a607-4fbf-b180-ce7ba2578fbe/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-08-2615.37.32.png" alt="変更検知"></p>
<p><img src="https://ik.imagekit.io/plaid/4a6a1e4b-265f-4252-8906-58fadf93c9dd/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-08-2615.38.46.png" alt="変更検知"></p>
<h2>実装について</h2>
<p>実装は、以下の図のようになっています。</p>
<p><img src="https://ik.imagekit.io/plaid/a4cde3d8-441d-4fc6-bdaf-08b8a272f1fb/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-08-2715.06.47.png" alt="変更検知"></p>
<h3>変更検知の基本ロジック</h3>
<p>機能の核となるのは、状態の差分検知です。初期状態と現在の状態と比較し、両者に差分が生じた場合に「未保存の変更あり」と判定する仕組みです。</p>
<h3>編集後の離脱防止アラート機能</h3>
<p>未保存の変更があるかどうかを最終的に判定する関数がtrueの場合、beforeunloadイベントでe.preventDefault()を実行します。アプリケーション内の画面遷移はVue Routerのナビゲーションガードで画面遷移時の確認ダイアログを表示されるよう制御しています。</p>
<h3>異なる画面間のデータの自動同期と偽陽性防止</h3>
<p>5秒毎に実行されるタブ間データの自動更新処理については、スナップショットも同時更新するようにしました。そして、デフォルト値の初期反映で新規作成時の偽陽性を回避しています。</p>
<h3>保存成功時の状態リセット</h3>
<p>データの保存処理において、API 呼び出しが成功したタイミングで、状態を保存後の最新の状態にリセットします。</p>
<h2>苦労したこと、工夫した点</h2>
<p>今回のタスクに対して、苦労したこと、工夫した点が多く分けて３つあります。</p>
<p>一つ目は、システム的な値の変更と、ユーザーの入力値による値の変更を切り分けるのが課題でした。サーバーに最新のデータをポーリングしにいって値が変わる実装があり、その更新をユーザーによる変更と区別する仕組みが必要だったからです。また、新規作成時にデフォルト値がセットされ、これをユーザーの入力値と誤って判定する箇所もありました。デフォルト値であれば警告が出ないように、そしてユーザーによる変更があった場合も検知できるよう実装しました。</p>
<p>二つ目は、実行時の画面遷移(配信実行中など)でも未保存の警告が出ないように工夫しました。</p>
<p>三つ目は、KARTE Messageの契約プランによって初期で入ってる値が違うところがあり、初期スナップショット(initialSnapshot)を作る時に調整することで、新規作成時の偽陽性を回避できるようにしています。</p>
<h2>インターンで得られたこと</h2>
<h3>反省点</h3>
<p>これまで、コードベースが大きく、かつ多くのユーザーに利用されているプロダクトの開発経験がなかったため、自分の変更が予期せぬデグレを引き起こさないよう、常に意識して開発に取り組んでいました。具体的には、変更検知の箇所を事前に調査してチェックリストを作成し、動作確認時にチェックしていました。プロダクトが非常に巨大であるため、どこに何が書かれているのかを特定するだけでも一苦労でした。当初想定していたよりも広範囲に影響が及ぶことに気づかず、手戻りが発生してしまったこともあります。特に今回のタスクを通して反省しているのは、分からない部分を一旦後回しにしてしまった結果、それが設計時の考慮漏れに繋がってしまった点です。</p>
<h3>学び</h3>
<p>この経験から、変更に着手する前に、関連する機能を広く深く理解し、影響範囲を正確に見極めることの重要性を痛感しました。この広大なコードベースをキャッチアップするために、AIを活用したり、ディレクトリ構造から関連コードを推測して読み進めたりと、様々な工夫をしました。自分の変更が関わる全ての機能を把握するまでには時間がかかりましたが、このインターンを通して、複雑で大規模なシステムについて慎重に開発を進める力が身についたと感じています。</p>
<h2>最後に</h2>
<p>プレイドでのインターンを終えて、一つのタスクをやったこと以外にも、チーム内の輪読会の参加<br>
や、インターンの最後にあるdemodayでの発表などたくさんの刺激があり、とても成長できたと感じていますし、楽しかったです。チームメンバーの皆さんや、一緒に開発してくれた方々をはじめ、プレイドの社員の方々、インターン生のみんな、ありがとうございました。とても充実した時間を過ごすことができました。</p>


こんにちは！8月からの1ヶ月間サマーインターンとしてプレイドで働いていた蜂須賀大智です。個人でWebアプリケーションを開発したり、他社で少し開発経験を積んだりする中で、自身のフロントエンドの技術力をさらに高めたいという思いがありました。そんな中、サポーターズの1on1イベントでプレイドという会社を知り、面談を重ねるうちに事業の面白さに惹かれ、インターンとして働くことになりました。このブログでは、私がプレイドでインターンとしてどのような課題に取り組んだか、そこから何を学んだかについてお話しさせていただきたいと思います。

プレイドインターン体験記：一ヶ月のインターンで体験した技術と学び

<h2>Introduction</h2>
<p>I'm @kazupon from the Developer Experience team.</p>
<p>PLAID offers a product called KARTE that enables continuous improvement by providing popup dialogs to users visiting their website through campaigns, analyzing visualized user behavior, and implementing measures. We provide an editor called &quot;Flex Editor&quot; for editing these campaigns.</p>
<p>We've achieved a massive performance improvement in KARTE's no-code editor Flex Editor by accelerating action build times up to 87x, dramatically enhancing the user experience. In this post, I'll walk you through our journey of migrating from Rollup to Rolldown for server-side build optimization.</p>
<p>This article is a follow-up to our previous post:</p>
<p><a href="https://tech.plaid.co.jp/rollup-perf">How We Made Rollup Build Times 10x Faster to Improve Preview Display</a></p>
<p>Actions are applications that allow editing action templates (internally called &quot;campaign templates&quot;) through KARTE's admin panel. They're edited using &quot;Flex Editor&quot;, a no-code editor that builds JavaScript code server-side for execution as marketing campaigns on websites.</p>
<h2>The Challenge: Build Times Hurting UX</h2>
<p>When users save edited actions in Flex Editor, they're built server-side for web delivery. However, lengthy build times were causing slow server responses, forcing users to wait and degrading the overall experience.</p>
<p>According to our DataDog metrics, action-compiler build times ranged from <strong>5-10 seconds</strong>, sometimes exceeding 20 seconds.</p>
<p><img src="https://ik.imagekit.io/plaid/c1113f81-799b-4227-bb09-16658d3ffd0e/asset-builder-bad-perf.png" alt="DataDog metrics showing server-side build times ranging from 5-10 seconds"></p>
<p>The primary culprit? JavaScript-based bundlers running server-side.</p>
<p>As mentioned in our previous article, action-compiler internally uses Rollup, a JavaScript-based module bundler. Module bundling is inherently CPU-intensive. While modern JavaScript engines like V8 and SpiderMonkey can achieve near-native performance through internal optimizations, they're not ideal for CPU-heavy tasks.</p>
<p>Bundlers like Rollup, which parse massive amounts of JavaScript code and perform tree-shaking on module graphs, suffer from JavaScript's event-loop-based single-threaded architecture when it comes to CPU-intensive operations.</p>
<p>While Web Workers or Node.js worker threads (<code>node:worker_thread</code>) can provide parallelization, Rollup's architecture wasn't designed with parallel bundling optimization in mind.</p>
<p>Additionally, to maximize action performance on websites, we use Terser (a code minifier) for minification. Since minification involves static code analysis followed by compression, it adds even more CPU overhead on top of Rollup's bundling process.</p>
<h2>The Solution: Migrating to Rolldown</h2>
<p>To tackle server-side action build times, we decided to migrate from Rollup to Rolldown.</p>
<p><a href="https://rolldown.rs/">Rolldown</a> is a high-performance JavaScript bundler written in Rust with Rollup API compatibility, promising significant bundling performance improvements.</p>
<p>Rolldown addresses Rollup's performance challenges through several innovations. Bundler operations like JavaScript module parsing and module graph tree-shaking are accelerated using crates from the Oxc project and Rust-side multi-threaded parallelization.</p>
<p>While maintaining API compatibility for existing Rollup plugins, Rolldown's architecture enables plugins to run in parallel on the JavaScript side through Workers, coordinating with the Rust side.</p>
<p>At the time of writing, Rolldown is at v1.0.0 beta.32. When we evaluated migration (January 2025), we found:</p>
<ul>
<li>Core bundler implementation was nearly complete, with only edge cases and bug fixes remaining, indicating <strong>stability</strong></li>
<li>Major <a href="https://github.com/rolldown/rolldown/issues/819">Rollup plugins were compatible with Rolldown</a>, maintaining <strong>compatibility</strong></li>
<li>I <a href="https://github.com/intlify/vue-i18n/pull/2067">verified bundling behavior</a> in my OSS projects, confirming <strong>proper operation and faster bundling than Rollup</strong></li>
<li><a href="https://github.com/intlify/vue-i18n/actions/runs/12644519450">E2E tests</a> confirmed <strong>bundled JavaScript modules worked correctly</strong></li>
</ul>
<p>These factors and verification results led us to adopt Rolldown for the Flex Editor project.</p>
<h3>Migration Approach</h3>
<p>Thanks to Rolldown's Rollup API compatibility, migrating my OSS projects and packages within Flex Editor was straightforward. However, action-compiler presented unique challenges.</p>
<p>As explained in our previous article, we have two types of action-compiler:</p>
<ul>
<li>For Browser: Used for action preview functionality in Flex Editor's GUI application</li>
<li>For Server (Node.js): Used server-side to build actions for deployment as campaign applications on websites</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/a217bf9c-89f5-4ad8-84ae-1d71e26f51dd/asset-builder-action-compiler.png" alt="Architecture diagram showing action-compiler for both browser and server environments"></p>
<p>Both environments use Rollup to build actions into JavaScript code. It's a single-source package optimized for performance in each environment.</p>
<p>The browser-oriented action-compiler pre-bundles JavaScript modules that actions depend on to improve editor preview UX, as mentioned in our previous article. It even bundles Rollup itself into action-compiler for optimized build speed.</p>
<p>The server-oriented action-compiler bundles with Rollup and minifies with Terser (via Rollup plugin) to maximize action performance. Like the browser version, action-compiler itself is bundled, but unlike the browser version, it simply imports Rollup from node_modules rather than bundling Rollup into action-compiler.</p>
<p>While each environment uses Rollup appropriately with environment-specific configurations, maintaining a single source while using Rolldown only server-side required careful planning. We wanted to avoid code complexity and increased maintenance cognitive load from implementing Rolldown-specific code.</p>
<h3>Leveraging API Compatibility for Rolldown Migration</h3>
<p>We achieved server-side action-compiler Rolldown migration by leveraging API compatibility and using a bundler to rewrite Rollup imports in server-side implementation code.</p>
<p>Specifically, we implemented a Rollup plugin that replaces <code>import { rollup } from 'rollup'</code> with <code>import { rolldown as rollup } from 'rolldown'</code>.</p>
<p>This gets a bit complex, but action-compiler is a JavaScript package that compiles (bundles) actions into JavaScript code using Rollup. As mentioned, we bundle action-compiler itself for browser and server optimization. (In other words, we're bundling a bundler with a bundler!)</p>
<p>Here's the relevant excerpt from action-compiler's bundler configuration file (rolldown.config.js) - note that action-compiler's bundler is now Rolldown:</p>
<pre><code class="language-js">// ...

/**
 * Replace import syntax with rolldown when using in Node.js environment
 */
if (isNode &amp;&amp; useRolldown) {
  plugins.push({
    name: 'replace-import-syntax',
    transform(code, id) {
      if (id.endsWith('src/prod.ts') || id.endsWith('src/dev.ts')) {
        return code.replace(/import\s+{\s+rollup\s+}\s+from\s+['&quot;]rollup['&quot;]\s*;?/gm, () =&gt; {
          return `import { rolldown as rollup } from 'rolldown';`
        })
      }
    }
  })
}

// ...
</code></pre>
<p>That's it!<br>
(The implementation uses simple regex string replacement rather than AST-based static analysis since we're only transforming two files.)</p>
<p><code>isNode</code> determines if the bundle target is Node.js - <code>true</code> for Node.js (server-side), <code>false</code> for browser. <code>useRolldown</code> determines whether to use Rolldown server-side - <code>true</code> uses Rolldown, <code>false</code> continues using Rollup.</p>
<p>When both <code>isNode</code> and <code>useRolldown</code> are <code>true</code>, the bundler registers a plugin that rewrites <code>import { rollup } from 'rollup'</code> to <code>import { rolldown as rollup } from 'rolldown'</code> in action-compiler's code.</p>
<p>By setting these flags appropriately (both <code>true</code>) when bundling action-compiler for server use, the code is transformed to use Rolldown. Using the bundler eliminated the need for Rolldown-specific code in action-compiler itself.</p>
<h2>Rolldown Server-Side Build Performance</h2>
<p>With Rollup successfully replaced by Rolldown in server-side action-compiler, we measured build performance using the following configurations and environment.</p>
<h3>Metrics</h3>
<ol>
<li>Rollup<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup> (no minification)</li>
<li>Rolldown<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup> (no minification)</li>
<li>Rollup + Terser (<code>@rollup/plugin-terser</code><sup class="footnote-ref"><a href="#fn3" id="fnref3">[3]</a></sup>)</li>
<li>Rolldown + SWC (<code>rollup-plugin-swc3</code><sup class="footnote-ref"><a href="#fn4" id="fnref4">[4]</a></sup>)</li>
<li>Rolldown + built-in minifier (<code>oxc-minify</code><sup class="footnote-ref"><a href="#fn5" id="fnref5">[5]</a></sup>)</li>
</ol>
<p>For comparison, we included cases without minification and the Rollup + Terser combination. Since <code>oxc-minify</code> was in WIP status during our implementation and might not function correctly for actions in the Flex Editor beta production environment, we also measured performance with Terser and SWC available as Rollup plugins.</p>
<h3>Environment</h3>
<p>Performance measurements were conducted on:</p>
<ul>
<li>Machine specs:
<ul>
<li>Model: MacBook Pro 14-inch, 2021</li>
<li>Chipset: Apple M1 Max</li>
<li>Memory: 64GB</li>
</ul>
</li>
</ul>
<p>The action structure for build performance testing:</p>
<ul>
<li>Build target action structure:
<ul>
<li>index.tsx</li>
<li>App.svelte</li>
<li>gen.ts</li>
<li>customScript.ts</li>
<li>karte-template.json</li>
<li>props.json</li>
<li>variablesQuery.json</li>
<li>localVariablesQuery.json</li>
</ul>
</li>
</ul>
<p>The action UI represents a campaign like this:</p>
<p><img src="https://ik.imagekit.io/plaid/a7f21d69-6f5b-45d6-a980-3b1a0e31ae0e/asset-builder-target-action.png" alt="Example campaign UI created with the action in Flex Editor"></p>
<p>While we'll skip the detailed file contents, when editing and saving in the editor, action file code is serialized into JSON with this structure and sent server-side for building:</p>
<p><img src="https://ik.imagekit.io/plaid/1c02f655-95ec-4206-8822-4cff3a4821b2/asset-builder-action-codes.webp" alt="JSON structure showing serialized action file codes sent to server for building"></p>
<p>For these performance measurements, we used server-oriented action-compiler to build this action code.</p>
<h2>Build Performance Results</h2>
<p>Here are our performance measurement results:</p>
<h3>Build Times</h3>
<table>
<thead>
<tr>
<th>Configuration</th>
<th>Max Build Time</th>
<th>Min Build Time</th>
<th>Average Build Time</th>
</tr>
</thead>
<tbody>
<tr>
<td>Rollup (no minification)</td>
<td><strong>560.596119 ms</strong></td>
<td>205.13774 ms</td>
<td>236.0695421 ms</td>
</tr>
<tr>
<td>Rolldown (no minification)</td>
<td>112.801283 ms</td>
<td><strong>23.01124 ms</strong></td>
<td>33.42461761 ms</td>
</tr>
<tr>
<td>Rollup + Terser (<code>@rollup/plugin-terser</code>)</td>
<td><strong>2424.394387 ms</strong></td>
<td>959.403731 ms</td>
<td>1149.732976 ms</td>
</tr>
<tr>
<td>Rolldown + SWC (<code>rollup-plugin-swc3</code>)</td>
<td>235.093658 ms</td>
<td>106.845099 ms</td>
<td>125.2551525 ms</td>
</tr>
<tr>
<td>Rolldown + built-in (<code>oxc-minify</code>)</td>
<td>143.829239 ms</td>
<td><strong>28.230994 ms</strong></td>
<td>40.44968284 ms</td>
</tr>
</tbody>
</table>
<p>Without minification, Rolldown clearly outperforms Rollup. Comparing Rolldown's minimum build time to Rollup's maximum shows approximately 24x improvement, with an average 9x performance boost. These results confirm Rolldown's acceleration benefits for action builds.</p>
<p>With minification, Rolldown builds still outperform Rollup + Terser. Comparing Rolldown + SWC's minimum build time to Rollup + Terser's maximum shows about 23x improvement, averaging 9x faster. With Rolldown's built-in minifier, we achieved an incredible <strong>87x</strong> improvement at minimum and <strong>29x</strong> on average.</p>
<p>These results demonstrate that while the SWC minifier via <code>rollup-plugin-swc3</code> provides acceleration, using Rolldown's built-in <code>oxc-minifier</code> delivers overwhelming build performance gains.<sup class="footnote-ref"><a href="#fn6" id="fnref6">[6]</a></sup></p>
<h3>File Sizes</h3>
<table>
<thead>
<tr>
<th>Configuration</th>
<th>Minified Size</th>
<th>Gzipped Size</th>
</tr>
</thead>
<tbody>
<tr>
<td>Rollup + Terser</td>
<td>92.15 kb</td>
<td>31.38 kb</td>
</tr>
<tr>
<td>Rolldown + SWC</td>
<td>114.73 kb</td>
<td>39.11 kb</td>
</tr>
<tr>
<td>Rolldown + built-in minifier</td>
<td>122.09 kb</td>
<td>40.35 kb</td>
</tr>
</tbody>
</table>
<p>File size results revealed interesting insights for action builds.</p>
<p>Various Rolldown minification configurations resulted in approximately 20-25% larger bundle sizes compared to Rollup + Terser. This is because Svelte runtime code used by actions is pre-bundled with Rolldown during action-compiler bundling.</p>
<p>Rolldown's built-in minifier <code>oxc-minify</code> has <a href="https://github.com/vitejs/rolldown-vite/issues/155#issuecomment-2856998564">several open issues</a> regarding minification optimization. Our analysis of the built code confirmed issues matching these reported problems.</p>
<p>The reason for pre-bundling Svelte runtime code is to accelerate Flex Editor preview display, as explained in our previous article.</p>
<p>Comparing minification performance between SWC (<code>rollup-plugin-swc3</code>) and <code>oxc-minify</code>, SWC showed higher compression rates.</p>
<h2>Trade-offs with Rolldown Adoption</h2>
<p>Performance measurements of Rolldown-powered server-side action-compiler showed build times exceeded expectations, while bundled action JavaScript file sizes increased 20-27% compared to Rollup + Terser.</p>
<p>Our goal was to accelerate server-side action build times and improve the save experience in Flex Editor. After team discussion, we decided to adopt Rolldown with its built-in minifier (<code>oxc-minifier</code>) for server-side build acceleration.</p>
<p>The trade-off: JavaScript action files delivered will be larger than Rollup-bundled versions. However, new actions from Flex Editor have been reduced to 1/10th the size of current production actions through architecture renewal. Server-side build acceleration with Rolldown not only improves DX through reduced server infrastructure costs but also enhances end-user UX when saving in Flex Editor. The dual benefits of DX and UX improvements drove our decision to adopt Rolldown with built-in <code>oxc-minifier</code>.</p>
<h2>Production Build Performance</h2>
<p>At the time of writing, we've deployed Rolldown-powered server-side action-compiler to production as a beta for select customers using Flex Editor. We continuously monitor server-side action-compiler performance with DataDog. Here's the graph after introducing Rolldown-powered action-compiler to production:</p>
<p><img src="https://ik.imagekit.io/plaid/8d78539a-e84b-475b-8447-90b789e8c97f/asset-builder-rolldown.png" alt="DataDog graph showing dramatic reduction in build times after Rolldown deployment"></p>
<p>In production, the system runs in a Kubernetes (k8s) container environment. Pre-migration action-compiler build times of 5-10 seconds have dramatically reduced to hundreds of milliseconds. The accelerated server-side build times when editing and saving actions in Flex Editor result in faster server responses and noticeably improved editor UX.</p>
<h2>Future Outlook</h2>
<h3>Towards Rolldown's Official Release</h3>
<p>While Flex Editor currently uses Rolldown beta, we'll continue updating toward the official release. We hope the file size issues mentioned earlier will be resolved by Rolldown's official release. Vite is also progressing with Rolldown integration through <a href="https://github.com/vitejs/rolldown-vite">rolldown-vite</a>, and we've verified <a href="https://voidzero.dev/posts/announcing-rolldown-vite#real-world-impact">up to 16x acceleration</a> in the Flex Editor project.</p>
<h3>Technical Future Prospects</h3>
<p>With Rolldown adoption, we've dramatically improved build time challenges. Our next step involves exploring AST-based editor generalization. While currently using Svelte-based AST, we're considering migration to Vapor's AST/IR base using <a href="https://github.com/kazupon/inclusion-vapor">inclusion-vapor</a> and expansion to other products.</p>
<h2>Conclusion</h2>
<p>This article detailed our journey migrating from Rollup to Rolldown, dramatically improving server-side build times and enhancing product UX.</p>
<p>Despite being in beta, Rolldown's core functionality is nearly complete and ready for production use. JavaScript/TypeScript projects can especially benefit from significant build time reductions, improving DX and accelerating CI/CD deployment cycles.</p>
<p>I hope this article inspires you to consider Rolldown for your own projects.</p>
<p>If you're interested in working on projects while contributing to OSS, please check out our <a href="https://recruit.plaid.co.jp/product">careers page</a>.</p>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p>v4.35.0 <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn2" class="footnote-item"><p>v1.0.0-beta.32 <a href="#fnref2" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn3" class="footnote-item"><p>v0.4.4 <a href="#fnref3" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn4" class="footnote-item"><p>v0.12.1, using minify feature <a href="#fnref4" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn5" class="footnote-item"><p>Minifier provided by the oxc project <a href="#fnref5" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn6" class="footnote-item"><p>This performance measurement compares only SWC and Rolldown's minifier under Rolldown. As shown in various <a href="https://github.com/privatenumber/minification-benchmarks">minification benchmarks</a>, performance varies depending on the code being minified. <a href="#fnref6" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


We've achieved a massive performance improvement in KARTE's no-code editor "Flex Editor" by accelerating action build times up to 87x, dramatically enhancing the user experience. In this post, I'll walk you through our journey of migrating from Rollup to Rolldown for server-side build optimization.

Achieving 87x Faster Server-Side Action Builds: Migrating from Rollup to Rolldown

<p>デザインエンジニアの安田（<a href="https://x.com/_yuheiy">@_yuheiy</a>）です。</p>
<p>プレイドの多くのシステムでは、サーバーサイドの実行環境としてNode.jsを採用しています。そのため、サーバーサイドもクライアントサイドもまとめてnpmを使って依存パッケージ（dependencies）を管理している場合がほとんどです。</p>
<p>システムのメンテナンスにおいては、このような依存パッケージのバージョンを継続的にアップデートし続けることが重要です。そこで今回は、社内向けに実施した、依存パッケージのバージョンアップをテーマにした発表を一部再編集してご紹介します。</p>
<h2>なぜ依存パッケージのアップデートが必要か</h2>
<p>筆者が所属するDeveloper Experience &amp; Performanceチーム（通称: DXチーム）では、その活動の一つとして、さまざまなシステムの依存パッケージのバージョンをアップデートして回るような作業をする機会がよくあります。DXチームでは、現在アクティブに開発が行われていない一部システムのメンテナンスを担当したり、既存のチームの開発をヘルプしたりする場面があり、その一環として併せてこのような作業を行っています。</p>
<p>依存パッケージをアップデートすることには、おもに次のような理由があります。</p>
<p>まず最初は、Node.jsのバージョンアップに対応するためです。Node.jsのバージョンアップにともなって古いバージョンの依存パッケージが動作しなくなることがあるので、Node.jsに追従するために必要な作業です。</p>
<p>次は、一般的なソフトウェア品質や開発効率の向上のためです。多くのパッケージはバージョンアップにともなって、動作上のバグの修正やパフォーマンスの改善、セキュリティ上の問題の解決が行われているほか、便利な新機能が追加されたりしています。これによってソフトウェアの外部品質が改善したり、余計な実装が不要になって設計がシンプルになったりする可能性があります。また、古いバージョンのパッケージを使い続けていることで、それに携わる開発者が古いバージョンの使い方を調べたり覚えたりといった無駄な学習コストを払わなければならないという問題もあります。</p>
<h2>デザインシステムの最新化のために</h2>
<p>もう一つの理由は、利用されているデザインシステムを最新化するためです。社内向けのデザインシステムであるSourが多くのシステムに導入されていますが、Sour自体の内容は日々アップデートされ続けている一方、各システムで利用されているSourのバージョンはアップデートされずに古いものが使い続けられていることが少なくありません。</p>
<p>参考までに、<a href="https://karte.io/">KARTE</a>のリポジトリにおいて使用されているSourのバージョンは次の通りです（件数は発表時のもの）。</p>
<ul>
<li>4.x: 5件（うち3件はDXチームが管理するシステム）</li>
<li>3.x: 5件</li>
<li>2.x: 11件</li>
<li>1.x: 2件</li>
<li>0.x: 1件</li>
</ul>
<p>筆者の本務はSourの開発ですが、ユーザー側でのバージョンアップが行われなければ開発している意味がありません。そのため私自身がそのアップデート作業を担当することもありますが、それに併せてその周辺環境を整備しなければならない場面もあります。というのも、Sour自身が依存しているパッケージのアップデートにともなって、ユーザー側の関連するライブラリのアップデートをしなければならなくなったり、もしくは、そのようなアップデートにともなう問題が発生しないかをテストするための環境が必要になったりすることもあるからです。</p>
<h2>タイミングが遅れるほどアップデート作業が難しくなる</h2>
<p>一般的に、依存パッケージが古くなればなるほど対処が必要な問題が増えて複雑化し、作業が難しくなる傾向にあります。特に古いシステムをメンテナンスしていると、複数の古い依存パッケージ同士が絡み合う問題が発生してデバッグが難しくなったり、古いバージョンで想定されていなかった環境依存の問題が発生して解決のために余計な手間を取られたりすることがよくあります。</p>
<p>また、関連する機能を担当した当時の開発者がチームや会社を離れたりしていることもあります。アップデートにともなう動作確認が必要になることがありますが、そのような場合、期待される正しい仕様や動作確認の方法がわからなくなる可能性もあります。あるいは、当時の担当者にしか意図を理解できないトリッキーな実装が行われているような場合もあります。</p>
<h2>「システムのメンテナンスは天下の回りもの」</h2>
<p>これは昔から個人的に唱えている理論です。システム開発の仕事をしていると、知らない誰かが作ったシステムを回り回って自分が引き継ぐというような場面は珍しくありません。そして、自分が作ったシステムもいずれまた別の誰かに引き継がれていくことになります。</p>
<p>システムの出来の良し悪しにかかわらず、引き継いだ人にはそのすべてを引き受ける責任が生じます。だからこそ、後任の誰かのために、自分が今担当しているシステムはできるだけ良い状態にしておくという心づもりでいることが大事だと思います。</p>
<h2>作業の進め方</h2>
<p>具体的な話に移ります。</p>
<p>まず、これから説明するような作業にあたっては、さまざまな観点でのソースコードの変更をしなければならない場合があります。そのため、必ずしも1つのpull requestで一気に対応しようとするのではなく、適切な粒度に分解しながら作業を進めてください。これについては普段の機能開発と同じです。</p>
<p>次に、CIが不十分だと感じる場合はあらかじめ整備しておくのがよいです。作業を細かく分割するほど、人力ではチェックの抜け漏れが発生しがちです。変更にともなうテストを効率的に行うために、できるかぎり自動化してしまいましょう。</p>
<h3>不要な依存パッケージを削除する</h3>
<p>アップデートの前に、不要な依存パッケージがあればあらかじめ削除しておきます。使わないものをアップデートしても仕方がないからです。</p>
<p><a href="https://knip.dev/">Knip</a>を導入することで、未使用の依存パッケージやデッドコードの検出ができます。これらを削除することで余計な要素を削れます。さらに、KnipをCIに組み込むことで、今後余計なものが追加されないように予防することもできます。</p>
<p>また、そのほかにも不要な機能などが残っていれば削除しておきます。</p>
<h3>言語の標準機能に置き換える</h3>
<p>Node.jsのアップデートにともなって、これまでサードパーティのパッケージが必要だったことが、Node.jsのコアの機能として実現できるようになっていることがあります。「<a href="https://zenn.dev/morinokami/articles/npm-uninstall">Node.js の進化に伴い不要となったかもしれないパッケージたち</a>」などを参考にして置き換えてください。</p>
<p>また、ECMAScriptやDOM仕様のアップデートにともなって、同じくサードパーティのパッケージが不要になることもあります。「<a href="https://github.com/you-dont-need/You-Dont-Need">You-Dont-Need</a>」などが参考になります。</p>
<p>依存パッケージを減らしてコアの機能に置き換えていくことで、将来的なメンテナンスコストを削減できることになります。</p>
<h3>package.jsonのアップデート</h3>
<p><code>package.json</code>に記述されている<code>dependencies</code>や<code>devDependencies</code>のバージョンをアップデートする際には、次のようなコマンドを使用すると一気に書き換えができて便利です。<code>--interactive</code>オプションを指定することで、アップデートする対象をチェックボックス方式で選択できます。</p>
<p>npmの場合:</p>
<pre><code class="language-bash">cd path/to/monorepo-root
npx npm-check-updates --workspaces --root --interactive
</code></pre>
<p><img src="https://ik.imagekit.io/plaid/9266d5fd-ceff-47f0-a94e-7d78bcfe707e/ncu.png" alt="新しいバージョンが存在するdependenciesのうち、必要なものを選択式でアップデートできる。パッケージごとに現在のバージョンとアップデート後のバーションが表示される。"></p>
<p>出典: <a href="https://github.com/raineorshine/npm-check-updates">raineorshine/npm-check-updates: Find newer versions of package dependencies than what your package.json allows</a></p>
<p>pnpmの場合:</p>
<pre><code class="language-bash">cd path/to/monorepo-root
pnpm update --latest --recursive --interactive
</code></pre>
<p>pnpm 10.12以降であれば、catalogsで管理しているバージョンもいっしょにアップデートできます。</p>
<p>またロックファイルは壊れやすいので、インストールに際して問題が発生した場合は再生成してみるとよいです。</p>
<pre><code class="language-bash">rm -rf package-lock.json **/node_modules &amp;&amp; npm install
</code></pre>
<h3>破壊的変更への対応</h3>
<p>セマンティックバージョニングにおいては、メジャーバージョンが上がるか、もしくは1.0.0に満たない場合のバージョンアップでは、常に破壊的変更の可能性があります。そのためアップデートをする前には、ざっとでもいいのでパッケージのCHANGELOGに目を通しておくことをおすすめします。</p>
<p>また、最新版よりもいくつも古いバージョンを使っている場合は、破壊的変更が積み重なって簡単にアップデートできないことがあります。そのような場合、バージョンは一気に上げるのではなく、ある程度の区切りに分けて段階的にアップデートしたほうが作業が簡単になります。</p>
<h3>後継のライブラリに置き換える</h3>
<p>場合によっては、あるパッケージの代わりとなる後継のパッケージ（ライブラリ）が登場しているがあります。既存のパッケージがメンテナンスされなくなったり、アーキテクチャが古くなって根本的な刷新が必要になったりしたときに、それを置き換えるために別のものが開発されて、コミュニティでもそちらが主流になっていくというパターンです。</p>
<p>KARTEでよく使われているところで言えば、次のような後継のパッケージがあります。</p>
<ul>
<li>Jade → <a href="https://pugjs.org/api/getting-started.html">Pug</a>（参考: <a href="https://github.com/pugjs/pug/issues/2184">Renaming jade -&gt; pug · Issue #2184 · pugjs/pug</a>）</li>
<li><a href="https://github.com/TypeStrong/ts-node">ts-node</a> → <a href="https://tsx.is/">tsx</a>（もしくは、<a href="https://nodejs.org/api/typescript.html#type-stripping">Node.jsのtype stripping</a>を使う）</li>
<li><a href="https://jestjs.io/">Jest</a> → <a href="https://vitest.dev/">Vitest</a></li>
<li><a href="https://recoiljs.org/">Recoil</a> → <a href="https://jotai.org/">Jotai</a></li>
<li><a href="https://lodash.com/">Lodash</a> → <a href="https://es-toolkit.dev/">es-toolkit</a></li>
<li><a href="https://github.com/raineorshine/npm-check-updates">npm-check-update</a> + <a href="https://github.com/ds300/patch-package">patch-package</a> + <a href="https://github.com/open-cli-tools/concurrently">concurrently</a> → <a href="https://pnpm.io/">pnpm</a> CLI（同等の機能がpnpmに組み込まれている）</li>
</ul>
<p>既存パッケージのアップデートと併せて、後継のパッケージへの移行も行いましょう。</p>
<h3>気になる部分はついでに改善しながら進める</h3>
<p>パッケージのアップデート作業をしていると、それに関係するほかの部分が気になることもあります。気になった部分についても、そのままにしておかず、せっかくなのでついでに改善してしまうのがよいです。たとえば次のようなものです。</p>
<ul>
<li>CIの構成をきれいにする</li>
<li>いらないnpm scriptsを消す</li>
<li>冗長な設定ファイルをクリーンアップする</li>
<li>deprecatedなメソッドの使用箇所を直す</li>
<li>破壊的変更がある箇所の周辺のコードをリファクタリングする</li>
</ul>
<p>このようなメンテナンス作業は普段は軽視されがちで、ともすれば老朽化した仕組みがそのまま何年も動き続けていることになりがちです。だからこそ、みなさんにはぜひ<a href="https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html">ボーイスカウト・ルール</a>を意識してもらいたいです。</p>
<blockquote>
<p>ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。そうやって、次にキャンプに来る人達が気持ちよく過ごせるようにするのです（このルールは元々、ボーイスカウトの父と呼ばれるロバート・スティーブンソン・スミス・ベーデン=パウエルの「自分が最初に見た時よりも、世界をいい場所にすべく努力しよう」という言葉から来ています）。</p>
<p>これに倣ってコーディングに関しても同じルールを定めるとしたら「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」となります。最初にそのモジュールを書いたのが誰であるかに関係なく、皆がそうやって、たとえ少しずつでもモジュールを改善する努力を続けたとしたら、その結果どういうことが起きると思いますか?</p>
</blockquote>
<p>出典: Kevlin Henney編、和田卓人監修『プログラマが知るべき97のこと』、オライリージャパン、2010年</p>
<h2>こまめなアップデートを習慣化する</h2>
<p>アップデート作業は後回しにするほど面倒な問題を引き起こしがちです。善は急げと思って、まずは今日からやってみましょう。</p>
<p>いったんひと通りのアップデートができたら、それ以降も定期的にアップデートを続けられるように、次に作業する日を決めてしまいましょう。月に1回程度が目安です。もしくは、<a href="https://docs.github.com/ja/code-security/dependabot/working-with-dependabot">Dependabot</a>などの自動化ツールを使って作業を自動化するのもよいと思います。</p>


Node.jsやフロントエンドのプロジェクトにおけるdependenciesをアップデートするうえでのよくある問題やうまく進めるためのコツなど。

package.jsonのdependenciesをアップデートする技術

Engineer Blog

Recent Article