Engineer Blog

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

<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をアップデートする技術

Tailwind CSSのバージョンをアップグレードしてTailwind CSS 4に対応する際に作成した、Figmaのstylesをもとにして各種設定ファイルを自動生成する仕組みについての紹介。

Figmaのstylesをもとにして「Tailwind CSSのテーマ」「tailwind-mergeの設定」「Storybookのドキュメント」などの各種ファイルを自動生成する

<h2>はじめに</h2>
<p>こんにちは！</p>
<p>プレイドで６月から７月末までEngineerインターンとして働いていたアボンデットルイです。現在はアメリカのマサチューセッツ工科大学（MIT）でコンピューターサイエンスを専攻している大学生です。</p>
<p>高校でエンジニアリングに興味を持ち、知識を活かして価値のあるものを作り出せることに魅力を感じました。そこからプログラミングを始め、今ではコンピューターサイエンスのさまざまな分野を幅広く探求しています。</p>
<p>同じくCSを学んだ<a href="https://tech.plaid.co.jp/intern-at-plaid-avondet">兄が以前プレイドでインターンをした</a>ことがあり、とてもいい経験だったと聞いたので、僕も挑戦したいと思い今回応募しました。</p>
<p>今回が初めての日本の企業での実務経験で、エンジニアとして働くことの楽しさや難しさを実感しながら、たくさんのことを学ぶことができました。このブログでは、インターンでの経験を振り返りながら、自分が学んだことについて共有したいと思います。</p>
<h2>① UI基礎の習得</h2>
<p>インターンに参加する前から、個人でWebアプリをいくつか作っていたこともあり、特にフロントエンド開発にはある程度慣れていました。その経験を活かして、最初は<a href="https://karte.io/">KARTE</a>のフロントエンドに関わる開発に取り組みました。</p>
<p>インターン開始直後は、Vue.jsやKARTEのコードベースに慣れるため、比較的シンプルなUI改善のIssueをいくつか対応しました。たとえば、検索機能の追加、ツールチップによって長いタイトルを全文表示する対応、ユーザーの入力形式に応じて表示を変えるフォーマット処理など、ユーザー体験を少しずつ向上させるような細かい変更です。</p>
<p>このようなタスクは、一見すると単純で地味に思えるかもしれませんが、実際には多くの工夫が必要でした。どのように既存のコードと整合性を保ちながら変更を加えるか、パフォーマンスに影響がないように注意すること、そしてUIコンポーネントの再利用性を損なわないように設計することなど、意外と奥が深い作業でした。</p>
<p>また、Vue.jsを本格的に使うのは今回が初めてだったため、最初はコンポーネントの設計思想やReactとの違いに戸惑うことが多くありました。特にKARTEのコードベースは大規模で、どこに何が定義されているかを見つけるだけでも最初は時間がかかりました。</p>
<p>とはいえ、こういった小さなIssueを積み重ねる中で、だんだんとVue.jsの書き方にも慣れ、大規模なコードベースのスタイルや構造にも自然に馴染めるようになっていきました。レビューで指摘された内容を意識して、自分なりにルールやベストプラクティスを積み重ねていったことで、次第に自信を持ってコードを書けるようになりました。</p>
<p>この時期は、「まずは手を動かして学ぶ」ことの重要さを実感した期間でもありました。コードを書くこと自体は目的ではなく、ユーザー体験をより良くするための手段であるということを、タスクを通して実感できたと思います。</p>
<h2>② UI刷新の経験</h2>
<p>Vue.jsに慣れてきたころ、管理画面のあるページを新しいデザインに全面的に改修する、大きなUIの仕事を任されました。この仕事は、Figmaで用意されたデザインをもとに、今あるUIを最新の仕様に合わせて見た目を新しくするものでした。</p>
<p>この作業は、画面をゼロから作るのではなく、既存の構造をできるだけ活かしながら新しい条件を満たすという、バランスの難しいものでした。全てを作り直すか、一部だけ変えるか、既存のスタイルや使いやすさを考えて、自分で最適な方法を考えながら進めました。</p>
<p>特に苦労したのは、コードの中でどこにどんな処理やデザインが書かれているのかを見つけることでした。画面は複数のパーツに分かれていて、データのやりとりも複雑だったため、「どこをどう変えれば見た目も動きも正しくなるか」を理解するのに時間がかかりました。</p>
<p>最初は難しさを感じましたが、コードの中にある意図を理解する力が少しずつつき、「なぜこう書かれているのか」「どのパーツが何を担当すべきか」といった視点で実装の方針を決められるようになりました。自分なりに工夫した実装方法を考えながら進める中で、コードの理解が深まり、自信にもつながりました。</p>
<p>最終的にFigmaのデザインとぴったり合う画面が完成したときは、とても達成感がありました。そして何より、自分が作ったものが実際にユーザーに使われるという実感が、エンジニアとしてのやる気をさらに高めてくれました。</p>
<p>具体的なタスクとしては、<a href="https://support.karte.io/post/2lRnr05R5uTA0K8D5fDzBc">行動チェーン(β)</a>のフォルダ機能における改善と、<a href="https://support.karte.io/post/4MxyAWLgEopohX27lnCFjZ">ユーザー構成比</a>の画面改善でした。<br>
<img src="https://ik.imagekit.io/plaid/c59fea1b-53dc-4889-b32c-be2f20d3bdd1/2025-08-0616.49%E3%81%AE%E7%94%BB%E5%83%8F.jpeg" alt="2025-08-0616.49の画像.jpeg"></p>
<p><img src="https://ik.imagekit.io/plaid/075047ba-3bf1-410a-8726-09fa987a7e9a/2025-08-0617.05%E3%81%AE%E7%94%BB%E5%83%8F.jpeg" alt="2025-08-0617.05の画像.jpeg"></p>
<h2>③ バックエンドへの挑戦</h2>
<p>インターン後半では、「バックエンドにも挑戦してみたい」と相談し、データ周りのIssueを対応させていただきました。タスクの内容は、ある管理画面の既存のフィルター機能に新しい条件を追加するため、SQLクエリの生成ロジックを修正し、BigQueryを用いた集計処理に新しいフィルター条件を組み込むというものでした。</p>
<p>このタスクは、技術的にも認知的にも非常に難易度が高かったです。まず、BigQueryもSQLも初めて触る技術であり、構文や最適なクエリの書き方に慣れるまでにかなりの時間がかかりました。また、複数のイベントテーブルをJOINしたり、ユーザー単位で集約したりといった処理が必要で、そもそも「このデータがどうやって構成されているのか」を理解するところからのスタートでした。</p>
<p>特に苦労したのは、巨大なコードベースの中で「どこがボトルネックなのか」「この値はどこからきて、どこで使われているのか」といった、データの流れを追いかける作業です。関数が分散していたり、抽象化されているレイヤーが多かったりと、全体像を把握するには時間と根気が必要でした。</p>
<p>ただ、その分だけ得られる学びも大きく、「なぜデータ処理をこのように設計しているのか」「フィルター条件が一つ増えるだけでも、どのような設計的配慮が必要か」といった、普段の個人開発では触れない視点を身につけることができました。</p>
<p>最初は不安でしたが、バックエンド開発に興味を持てるようになったのは、自分にとって大きな成長の一歩でした。</p>
<h2>プレイドの文化</h2>
<p>今回のインターンで一番印象に残ったのは、プレイドの働きやすさとカルチャーでした。初めての実務経験だったので、最初はもっと簡単な作業ばかり担当するのかと思っていたのですが、実際には自分が関わったタスクはどれもプロダクトにしっかりと関係していて、やりがいのある内容でした。常にメンターの方がサポートしてくださり、困った時には丁寧に説明してくれたので、安心して新しいことに挑戦できました。最初はうまくいかないことも多く、戸惑うこともありましたが、その経験が逆に自分の成長につながったと感じています。</p>
<p>2ヶ月という短い期間だったので、自分が関われた範囲は限られていましたが、それでも多くの方が自分に声をかけてくれて、新しいツールや機能の開発に参加するチャンスを与えてくれました。タスクを進める中でも、自分の興味や学びたいことを考慮してくれる雰囲気があり、インターンとしてとても充実した経験ができたと感じています。</p>
<p>インターンに参加してから、一緒に機能開発を行うチームの定例ミーティングに参加し、他のメンバーがどのような仕事をしているのかを聞くことで、プロダクト全体の流れやチーム間の連携の重要性を学ぶことができました。日々のやりとりを通じて、インターンであっても一人のメンバーとして扱ってもらえる環境にとても感謝しています。</p>
<h2>最後に</h2>
<p>今回のインターンを通して、エンジニアとして働くことの楽しさや難しさをたくさん学びました。最初は不安もありましたが、周りの方がいつも助けてくれて、新しいことにも安心して挑戦できました。</p>
<p>実際にプロダクト開発に関わる中で、自分の書いたコードがプロダクトの一部になる経験はとてもやりがいがありました。うまくいかないこともありましたが、そのたびにサポートしてもらい、少しずつ自信を持てるようになりました。</p>
<p>2ヶ月という短い期間でしたが、いろいろな技術に触れ、チームの一員として働くことができたのはとても貴重な経験でした。今回の経験を通して、エンジニアとしてもっと成長したいという気持ちが強くなりました。これからもプレイドの成長を楽しみにしつつ、自分もこの経験を活かして努力を続けていきたいと思います！</p>
<hr>
<p>プレイドはエンジニアインターンを募集しています！　興味を持った方は是非応募してみてください！</p>
<p><strong>サマーインターン</strong></p>
<div class="iframely-embed" data-embedded-url="https://open.talentio.com/r/1/c/plaid/pages/106581"><div class="iframely-responsive" style="padding-bottom: 56.25%; padding-top: 120px;"><a href="https://open.talentio.com/r/1/c/plaid/pages/106581" data-iframely-url="https://cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fopen.talentio.com%2Fr%2F1%2Fc%2Fplaid%2Fpages%2F106581&key=878c5bef402f0b2911bf6d4ce6261abd">【26卒/27卒】エンジニアサマーインターン / 株式会社プレイド</a></div></div><script async src="https://cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p><strong>通期インターン</strong></p>
<div class="iframely-embed" data-embedded-url="https://open.talentio.com/r/1/c/plaid/pages/90783"><div class="iframely-responsive" style="padding-bottom: 30.2778%; padding-top: 120px;"><a href="https://open.talentio.com/r/1/c/plaid/pages/90783" data-iframely-url="https://cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fopen.talentio.com%2Fr%2F1%2Fc%2Fplaid%2Fpages%2F90783&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Engineer) / 株式会社プレイド</a></div></div><script async src="https://cdn.iframe.ly/embed.js" charset="utf-8"></script>


プレイドで2ヶ月間エンジニアインターンに挑戦した学生の体験記。Vue.jsでのUI改善・刷新からBigQueryを活用したバックエンド開発まで、幅広い技術領域で学んだ実務経験と成長の記録を詳しく紹介します。

プレイドインターン体験記：フロントエンドからバックエンドまで挑戦した2ヶ月

<h2>はじめに</h2>
<p>こんにちは、今年4月に新卒でプレイドに入社しエンジニアをしている佐藤と申します！普段は、社内で利用する<a href="https://open.talentio.com/r/1/c/plaid/pages/106299">内製のOLAPデータベースを開発するチーム</a>でお仕事をしています。</p>
<p>この度、プレイドは「<a href="https://sre-next.dev/2025/">SRE NEXT 2025</a>」にゴールドスポンサーとして協賛いたしました。当日はブース出展に加え、エンジニアの土谷が<a href="https://sre-next.dev/2025/schedule/#slot084">「大量配信システムにおけるSLOの実践 ：「見えない」信頼性をSLOで可視化」</a>というテーマでスポンサーセッションに登壇しました。</p>
<p>私自身もイベントに参加し、ブースの運営と多くのセッションを聴講しました。本記事では、当日のプレイドブースの様子や、個人的に特に印象に残ったセッションについてレポートします！</p>
<h2>ブースの紹介</h2>
<p>まずは、プレイドブースの様子からご紹介します。ブースでは、来場者の皆様と多岐にわたる技術的な議論ができるよう、以下の5つのトピックを用意しました。</p>
<ol>
<li>Production Readiness Reviewとは</li>
<li>リアルタイムユーザー解析エンジンのリアーキテクチャ</li>
<li>監査ログとは - なぜ重要なのか</li>
<li>KARTE BlocksのSLO</li>
<li>AIエージェントを用いたセキュリティレビュー</li>
</ol>
<p><img src="https://ik.imagekit.io/plaid/472905ef-0548-4eab-8787-fdf6eaf1ce62/IMG_4624.jpg" alt="IMG_4624.jpg"></p>
<p>ブースでは、来場者の方に興味のあるトピックへシールを貼っていただく企画を実施し、特にAI関連のテーマに多くの関心が集まっているようでした。</p>
<p>私はリアルタイムユーザー解析エンジンについて会話することが多かったので、そちらについて紹介します。プレイドでは、「KARTE」を通じて取得した膨大なデータを処理するために内製のリアルタイムの解析エンジン(「Blitz」と呼んでいます)を置いています。(<a href="https://tech.plaid.co.jp/deim_2025">このエンジンはデータ工学系のフォーラムであるDEIMに論文を投稿して</a>いたりします)。主にその内部の仕組みとリアーキテクチャについて議論させてもらいました。例えば、リアーキテクチャによってレイテンシが1500ms（結果整合性）からp95で200ms（強整合性）へと改善したことをお話しすると、プレイドの技術への投資姿勢とエンジニアの技術力について良い反応をもらうことができて嬉しかったです。</p>
<p>Blitzの詳細に関しては、論文以外にも以下のブログで紹介していますので、よろしければご覧ください。</p>
<ul>
<li><a href="https://tech.plaid.co.jp/blits_pre_aggregation"><strong>Blitz（前編）: 自由度と即時更新性を担保したAggregation</strong></a></li>
<li><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture"><strong>Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</strong></a></li>
<li><a href="https://tech.plaid.co.jp/blitz_performance_user_cache"><strong>Blitz: リアルタイムユーザー解析エンジンのボトルネックを解消したキャッシュ設計</strong></a></li>
</ul>
<p>また、現在私が開発に携わっているユーザー行動分析に特化した内製のOLAPデータベースについても、Kubernetesやコンテナランタイムといった技術を交えながらお話しでき、そちらに対する議論も大変盛り上がりました。</p>
<p>これらの技術的なコンテンツに加え、様々なノベルティ(カフェオレ、ラムネ、うちわ、歯ブラシなど)やSRE NEXT 2025のために作成したパンフレットも大変好評でした！</p>
<p><img src="https://ik.imagekit.io/plaid/47ac9bd5-c960-48a2-b847-6d4c5ec76de1/IMG_4578.jpg" alt="IMG_4578.jpg"></p>
<h2>参加セッションの感想</h2>
<h3><a href="https://sre-next.dev/2025/schedule/#slot044"><strong>Fast by Friday: Making performance analysis fast and easy(Brendan Gregg)</strong></a></h3>
<p>Brendan Gregg氏はフレームグラフを始めとした多くの可視化ツールの発案者であり、<a href="https://www.usenix.org/">USENIX</a>などの著名カンファレンスで基調講演をされており、私自身本セッションをとても楽しみしておりました。</p>
<p>このセッションでは、「Fast by Friday」——つまり、月曜日に発生したパフォーマンス問題をその週の金曜日までに解決するというコンセプトに基づき、システムパフォーマンスを迅速に分析・改善するための方法論が紹介されました。</p>
<p>例えば、「月曜日にはまず問題を定量的に分析する」「水曜日にはフレームグラフやeBPFを用いてプロファイリングを行う」といったように、1週間の各曜日で何をすべきかが具体的に語られました。第一線で活躍するエンジニアのパフォーマンスチューニングの過程を体系的に知ることができ今後の業務に大変活かせると感じました。</p>
<p>(SRE NEXT 2025での発表資料は見つけることができませんでしたが、<a href="https://www.brendangregg.com/Slides/eBPFSummit2023_FastByFriday/">こちらの資料</a>に内容は近いと感じましたので、ご興味ありましたら是非ご覧ください。)</p>
<p>セッション後のAsk the Speakerでは、私たちが開発しているOLAPデータベースのパフォーマンスについて少し相談してきました。特に印象的だったこととして、メモリ使用量の改善についてのアドバイスです。「プロダクション環境でメモリダンプを取得するとJVMのレイテンシが悪化してしまう」という課題に対し、「CPUのフレームグラフを分析してメモリ割り当てが多いコードパスを特定すれば、より低コストで問題の原因を突き止められるかもしれない」という助言をいただきました。また、データベースのような巨大で複雑なシステムのパフォーマンスを改善するためには、まずマイクロベンチマークを整備することが重要であると勧められました。実装には工数がかかりそうですが、コードを大量に生産することにはAIの活用も期待できるため、チームで検討し、整備を進めていこうと思います。</p>
<h3><a href="https://sre-next.dev/2025/schedule/#slot087">Intel SGXをAzureで本番運用するための構成事例と実践知見(株式会社Datachain SRE/テックリード 大久保 俊彦)</a></h3>
<p>TEE（Trusted Execution Environment）は、ハードウェア上の保護された領域でコードやデータを処理し、安全性を確保する技術です。例えば、メモリ上にデータを暗号化して保持し、CPU内部で復号化と処理を行うなどがあり、これにより、メモリを抜かれたとしても暗号が解読されない限りは、データを覗き見ることができなくなります。多くのCPU(ARM, AMD, etc.)がTEEをサポートしていますが、中でも強力なTEEの一つとして、Intel SGXがあります。</p>
<p>その仕組みの複雑さや具体的なユースケースのイメージが湧きづらい点から、私自身これまで深く学習できていませんでしたが、本講演では動作原理とユースケースに対する興味深い話を伺うことができました。(講演の後、大久保さんと2時間ほどお話しする機会をいただき、Intel SGXについてさらに深く学ぶことができ大変良い経験になりました。ありがとうございました。)</p>
<p>Datachain社では、異なるブロックチェーン間で資産やデータを安全に移動させるための「ブリッジ」という仕組みにIntel SGXを活用されています。このブリッジですが、暗号化が施されていない場合、内部の人間が直接メモリを盗み見ると仮想通貨の情報が見れてしまい、ユーザーの暗号資産を不正に操作できてしまうリスクがあります。(実際にブリッジの運用者の内部犯行によってユーザーの仮想通貨が<a href="https://www.chainalysis.com/blog/multichain-exploit-july-2023/">$120M抜き取られたという事件</a>が起きていたりします)。</p>
<p>Datachain社は、Intel SGXを用いることで運用者ですらアクセスできないセキュアな環境を構築し、ユーザーが安心して資産を移動できるサービスを提供しているとのことでした。</p>
<p>秘密計算という先進的な技術が、実社会の課題解決に貢献している様子を知ることができて、大変刺激を受けました。</p>
<h2>プレイドのセッションの紹介</h2>
<h3><a href="https://sre-next.dev/2025/schedule/#slot084">大量配信システムにおけるSLOの実践 ：「見えない」信頼性をSLOで可視化（プレイド 土谷）</a></h3>
<p>弊社エンジニアの土谷からは、「KARTE Message」をテーマに、月間10億通を超える大規模配信の信頼性をどのようにSLOに落とし込み、運用・改善してきたかについてお話ししました。</p>
<p>セッション後、弊社ブースにお立ち寄りいただいた方の中には、これからSLI/SLOを設定するという方も多くいらっしゃいました。技術的な側面に加え、「ビジネスメンバーへの理解をどのように促進したか」といった具体的な実践方法まで踏み込んで質問される方も多く、皆様との対話を通じて、私たち自身も多くの学びを得ることができました。</p>
<p>よろしければ登壇資料もご覧ください。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="大量配信システムにおけるSLOの実践:「見えない」信頼性をSLOで可視化" src="https://speakerdeck.com/player/6e64b50718624605960a8f215fce51e7" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h2>おわりに</h2>
<p>SRE NEXT 2025には、SREやインフラ分野に深い知見をお持ちの方が数多く参加されており、弊社の取り組みに興味を持っていただき、活発な議論ができたことを大変嬉しく思います。私たちが知見を提供するだけでなく、皆様からも多くのことを学ばせていただき、非常に貴重な交流をすることができました！</p>
<p>今回、初めてカンファレンスのブース担当を経験しましたが、多様なバックグラウンドを持つ方々と直接技術的なお話しができ、とても楽しかったです。普段チームの中で開発している時には中々得られない刺激と知見を得ることができました。今後もこのような場に参加させていただきたいと思います！</p>
<p>最後に、このような素晴らしいカンファレンスを主催・運営してくださった皆様、本当にありがとうございました！ブース出展では、スタンプラリーなど来場者と話すきっかけを運営の皆様にご用意いただけたおかげで、非常に多くの方々とお話できました。そして、盛り上げていただいた参加者のみなさま、様々な知見をご共有いただいたスピーカー、スポンサー企業の皆様、ありがとうございました！</p>
<p>SRE NEXT 2026も楽しみにしております！</p>


新卒のエンジニアがSRE NEXTに参加しました。プレイドのブースの紹介や聴講したセッションレポートをお伝えします。

新卒エンジニアによるSRE NEXT 2025 イベントレポート　

<p>この記事は、社内の生成AI LT会（<a href="https://tech.plaid.co.jp/plaid-generative-ai-lt-report">LT会に関するブログ</a>）で「誰でもできるvibe-coding」と題した発表内容を基に、AIに執筆させています。</p>
<h2>はじめに</h2>
<p>こんにちは、プレイドのKARTE Messageチームでエンジニアをしている大内です。</p>
<p><a href="https://karte.io/package/message/">KARTE Message</a>は、メール・アプリプッシュ・LINEなどのチャネルからエンドユーザーにパーソナライズした配信を効率化したMAツールです。</p>
<p><a href="https://tech.plaid.co.jp/karte_message_mass_delivery_architecture">メール配信の運用について紹介した記事</a>や、<a href="https://tech.plaid.co.jp/complex_logic_to_dynamically_generate_sql">機能改善により開発スピードが向上したことを紹介した記事</a>がありますので、そちらも併せてご覧ください。</p>
<p>私たちMessageチームでは、開発の生産性をさらに高めるために、エンジニア以外のメンバーもAIを活用して開発を行う取り組みを進めています。この試みは多くの可能性を秘めている一方で、「レビュワーの負担が増えすぎる」という課題も明らかになりました。</p>
<p>この記事では、その課題にどのように取り組み、改善を進めているかご紹介します。</p>
<h2><strong>AI開発の幕開けと、見えてきた課題</strong></h2>
<p>チームのプロダクトマネージャー（以下、PMとします）が生成AIを使い、次々と実装を始めたのがことの始まりでした。AIによってコードが効率的に生み出され、ローカル環境で動作確認ができれば、機能が形になるという事実は、開発のスピード感に大きなインパクトを与えました。</p>
<p>その結果、PMは多くのPRを作成。この1ヶ月だけでも、<strong>レポート機能の改善、AI連携機能の強化、リスト表示のUI刷新、多岐にわたる機能改善</strong>に関するPRがマージされました。</p>
<p>一方で、この新しい開発スタイルは、いくつかの運用上の課題も浮き彫りにしました。</p>
<ul>
<li><strong>エンジニアのレビュー負荷増大</strong>：エンジニアから見ると、「開発の意図や目的が必ずしも明確でない大量のコード」をレビューする必要が生じた。</li>
<li><strong>AI生成コードの品質</strong>：AIは既存のコードベースを完全に理解しているわけではないため、「動作はするものの、品質面では改善の余地がある」コードを生成してしまうことがあった。例えば、既存コードの再利用が不十分であったり、実装方針の変更時に古いコードが残ってしまったりするケースがある。</li>
</ul>
<p>レビュワーからは、特に以下の点が負担増の原因として挙げられました。</p>
<ul>
<li>PRにおける差分量の増加があった。</li>
<li>「まず実装してみる」という進め方だったため、設計やセキュリティリスクに関する検討がコードレビュー段階に集中し、レビューの負担が増した。</li>
<li>AIが生成したコードの意図を読み解くのに時間がかかることがあった。</li>
</ul>
<h2><strong>課題解決への道のり：プロセスの見直しと改善</strong></h2>
<p>これらの課題に対応するため、私たちは以下の改善策に取り組んでいます。</p>
<ol>
<li><strong>「仕様ドキュメント」の事前作成とレビュー</strong>：開発着手前に「仕様ドキュメント」を作成し、エンジニアがレビューするフローを導入。これにより、設計段階で問題点を洗い出し、セキュリティ懸念を事前に検討できるため、コードレビュー時には実装そのものに集中できるようになった。</li>
<li><strong>AIによる実装意図のコメント記載</strong>：AIが生成したコードには、可能な限り実装意図をコメントとして記述。これにより、レビュワーがコードの意図を理解しやすくなることが狙い。</li>
<li><strong>PRの適切な分割</strong>：AIによる大量のコード生成に対応するため、PRを機能単位や意味のある変更単位で細かく分割するルールを設けた。仕様ドキュメントで事前に粒度を決めておくことで、レビューの負荷軽減を図っている。</li>
</ol>
<h2><strong>レビュワーから見たAI開発：評価と今後の期待</strong></h2>
<p>AIが生成したコードをレビューする中で、その可能性と課題の両方が見えてきました。</p>
<p><strong>評価できる点</strong></p>
<ul>
<li>既存の複雑な実装がある中でも、動作するコードを生成できる点は注目に値する。特にテストコードの生成精度は高く、品質向上に貢献する可能性がある。</li>
<li>既存の制約がない新規開発の場合、AIが生成するコードは比較的標準的で読みやすい傾向にある。</li>
<li>コードを記述する速度は非常に速く、人間によるレビューがボトルネックになる場合もあるほどである。</li>
</ul>
<p><strong>今後の改善に期待する点</strong></p>
<ul>
<li>既存実装が複雑な場合や、多くの背景情報を理解する必要がある場合、生成されるコードの質がまだ高くないことがある。これは事前の設計ドキュメント作成である程度カバーできると考える。</li>
<li>PRの粒度調整や補足コメントの追加など、実装以外の部分では、まだ人間によるコントロールが必要である。</li>
<li>既存のコードアーキテクチャが一般的でない場合、AIの知識外となり精度が低下する可能性がある。AIを有効活用するには、既存コードも一般的なアーキテクチャに準拠している方が望ましいかもしれない。</li>
</ul>
<p>総じて、AIに開発を完全に任せるのはまだ難しい点が多いものの、工夫次第で品質を向上させることは十分に可能だと感じています。チームとしてこの新しい取り組みに前向きに関わり、改善を続けていくことが重要だと考えています。</p>
<h2><strong>現在の取り組みと、そこから得られた学び</strong></h2>
<p>現在、私たちは以下の対策を中心に進めています。</p>
<p>それは、<strong>「仕様ドキュメント」を事前に作成し、エンジニアのレビューを経たうえで開発に進むフローを確立すること</strong>です。</p>
<p><strong>具体的なフローのイメージ</strong></p>
<ol>
<li>PMが仕様ドキュメントに「背景」「期待する機能」「懸念点」を記述し、「実装方針」についてはAIの支援も受けつつ草案を作成。
<ul>
<li>この時点で、PM自身も実装の概要を把握。</li>
</ul>
</li>
<li>エンジニアが「仕様ドキュメント」をレビュー。
<ul>
<li>これにより、コードレビュー時に仕様の全体像が共有され、手戻りを削減。既存コードの活用など、エンジニアの知見を早期に反映する。</li>
</ul>
</li>
<li>レビュー結果を元に「仕様ドキュメント」を修正し、関係者間で合意。</li>
<li>修正された「仕様ドキュメント」を設計書としてAIに入力し実装。
<ul>
<li>より正確な仕様に基づいてAIがコードを書くことで、誤りを減らす。</li>
</ul>
</li>
</ol>
<p><strong>AI運用の工夫</strong></p>
<ul>
<li>作成した仕様ドキュメントをCursorやCopilotに一時的にルールとして登録し、開発中の参照を容易にしている。</li>
<li>PR作成前に必須のチェックリストを作成し、レビューの負担軽減に努めている。</li>
</ul>
<p>これらの取り組みにより、エンジニアからは「レビューの負担が軽減された」という声も聞かれるようになってきました。（もちろん、まだ改善の余地はあります。）</p>
<p><strong>得られた学び</strong></p>
<p>この経験から、ビジネスサイドとエンジニアが共同で仕様を定義し、開発を進めていくプロセスが、AIの登場によって大きく変わる可能性を感じています。</p>
<p>現在のAIの進化を見ると、いずれ「仕様書＝実装」という未来も現実のものとなるかもしれません。私たちMessageチームは、今後もこの新しい開発スタイルに積極的に取り組み、知見を深めていきたいと考えています。</p>


生成AIで書いたコードをどうレビューしていくか。AIと共存しながら開発しているMessageチームの取り組みを紹介します。

「生成AIで書いたコード、どうレビューする？」Vibe codingと共存する開発プロセス

<p>プレイドが提供するKARTEでは、エンドユーザの行動データを活用するためにさまざまな分析機能を提供しています。データベースの裏側を支えるデータ構造も多種多様で、それらを正しく理解し活用していくことは分析サービスを提供する上で非常に重要です。</p>
<p>この記事ではBitmap Indexにフォーカスし、ナイーブなBitmap IndexとRoaring BitmapやBit-Sliced Indexについて解説します。</p>
<p>弊社の記事で手前味噌ですが、分析向けデータベースの技術全般については以下の記事も非常に参考になるのでオススメです。<br>
<a href="https://tech.plaid.co.jp/fundamentals_of_olap_db_technology">OLAP DBの技術要素の基礎</a></p>
<h2>ナイーブなBitmap Index</h2>
<p>最も基本的なBitmap Indexは、カラム内の特定の値ごとに一つのビットマップを持つ構造です。このビットマップでは、各ビットがテーブル内の一つの行（行番号）に対応します。その値を持つ行であればビットを1、持たなければ0とします。</p>
<p>例えば商品テーブルに「商品カテゴリ」というカラムがあり、以下のデータが入っているとします。</p>
<table>
<thead>
<tr>
<th>行番号</th>
<th>商品カテゴリ</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>トップス</td>
</tr>
<tr>
<td>1</td>
<td>トップス</td>
</tr>
<tr>
<td>2</td>
<td>トップス</td>
</tr>
<tr>
<td>3</td>
<td>ボトムス</td>
</tr>
<tr>
<td>4</td>
<td>ボトムス</td>
</tr>
</tbody>
</table>
<p>この商品カテゴリカラムに対してBitmap Indexを作成すると、以下のようになります。</p>
<ul>
<li>トップス: <code>11100</code> (0, 1, 2番目の行がトップス)</li>
<li>ボトムス: <code>00011</code> (3, 4番目の行がボトムス)</li>
</ul>
<p>最大の利点はANDやORをBit演算で高速に計算できることです。<br>
例えば、「トップスまたはボトムスの商品を抽出する」場合、<code>11100</code> OR <code>00011</code> = <code>11111</code><br>
となり、全ての行が該当することが分かります。</p>
<p>また、該当するエントリ数の算出はpopcntでできてしまいます。</p>
<p>主な弱点は以下です。</p>
<ul>
<li>サイズが大きくなりやすい
<ul>
<li>カーディナリティ(カラム内のユニークな値の数)の分ビットマップを持たなければならず、特にカーディナリティが高い時に大きくなります。</li>
<li>値がスパースな時に非効率です。例えば100万行の商品テーブルで「虹色」の商品が1つだけある場合、「虹色」のビットマップは「00...010...00」のようにほとんどが0で占められます。これなら、単に対応する行番号のリスト（例：<code>[2500]</code>）で持つ方がはるかにコンパクトです。</li>
<li>(基本的にはカーディナリティが高いカラムはスパースな値が多いです。多値型の場合はその限りではありませんが)</li>
</ul>
</li>
<li>範囲検索が非効率
<ul>
<li>例えば商品価格のような値に対してBitmap Indexをそのまま使って「1000円以上の商品」を検索する場合、1000円、1001円、1002円… といった個別の価格に対応する全てのビットマップを取得し、ORを取らなければなりません。</li>
</ul>
</li>
</ul>
<h2>Roaring Bitmap</h2>
<p>Bitmapの良さを活かしつつ弱点を克服するためのフォーマットがいくつかあります。有名なものがWAH (Word Aligned Hybrid), Concise Bitmap, そしてRoaring Bitmapです。<br>
雑にまとめるとどの手法も、決まった方針でBitmapを分割して、1と0が満遍なく混在するパーツは純粋なBitmapとして扱いつつ、スパースなパーツは行IDのリストやRun-Length Encodingで保持する、という仕組みです。</p>
<p>OLAP分野だとRoaring Bitmapが特に人気なようで、IndexにはRoaring Bitmapが優先されることが多いと思います。以下はRoaring Bitmapについて説明します。</p>
<h3><strong>Roaring Bitmapの仕組み</strong></h3>
<p>Roaring Bitmapでは、Bitmapを最大65,536(2^16)個の要素で構成されるコンテナに分けます。コンテナはBitmap / Arrayのどちらかで表現します。</p>
<ul>
<li>Bitmap: スパースではない場合、65,536ビット（8KB）のビットマップとして格納します。</li>
<li>Array: スパースな場合(デフォルトでは1が4096個以下)、要素の値を整数のソート済み配列としてそのまま格納します。</li>
</ul>
<p>(進化版ではRun-Length Encodingという3種類目のコンテナもありますが、今回は割愛します。)</p>
<p>AND/ORなどの論理演算はコンテナ単位で行われ、コンテナの組み合わせごとにアルゴリズムがあります。例えばAND演算は以下です。</p>
<ul>
<li>Bitmap vs Bitmap: 通常のビットワイズAND演算。</li>
<li>Bitmap vs Array: Array内の各要素について、Bitmapの対応するビットを確認。</li>
<li>Array vs Array: ソート済み配列同士のマージ処理に似た方法で共通要素を探索。</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/ddb8044b-db50-493c-9d73-918bafb04060/%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-05-2322.50.10.png" alt="Roaring Bitmap"><br>
(int32を扱うとして、実際にはcontainerの要素には下位16bitを入れ、上位16bitはコンテナ毎に持ちます。足し合わせることで元のint32に復元できます。)</p>
<p>Arrayコンテナが関わる演算はBitmapコンテナ同士の演算と比べると非効率ですが、そもそも要素数が少ないため大して問題にならない、というのが良くできているところだと思います。また、WAHやConcise Bitmapではワード単位でBitmapかRun-lengthかを区別しますが、Roaring Bitmapでは大きい固定サイズで分けたことで、オーバヘッドが少なくなったことがポイントだと思います。</p>
<p>余談ですが、OSSのOLAP DBであるApache Druidでは、デフォルトで文字列型の全カラムに対してRoaring Bitmap Indexが作られます。大胆ですね。実際KARTEで扱うような行動データをDruidにロードして試したことがありますが、Bitmap Indexのサイズはカラムナ部分と同程度に収まり、フィルタリングもかなり早くなりました。</p>
<p>また、数値型に対して作らない理由は以下だと思います。</p>
<ul>
<li>カーディナリティが高いことが多い(年齢や会員ランクなど、反例も多そうですが)</li>
<li>固定長で値が小さいためカラムナフォーマットだけでも十分早い(SIMD / CPUキャッシュ / CPUレベルでの並列化が効きやすい)</li>
</ul>
<h2>Bit-Sliced Index</h2>
<p>Bitmap Indexの弱点に対応するフォーマットとして、Bit-Sliced Indexもあります。ざっくり言えば数値型に向いてるIndexです。(Roaring BitmapはBitmap単体のフォーマットですが、Bit-Sliced Indexはindex全体のフォーマットです。組み合わせることもできます。)</p>
<p>Bit-Sliced Indexは、カラムの値を特定の基数で分解（スライス）し、各ビット位置ごとにビットマップを作成します。</p>
<p>以下は商品価格を基数2で表現(=2進数)する例です。B[i]は2進数表現の、i bit目を意味します。</p>
<table>
<thead>
<tr>
<th>行番号</th>
<th>価格</th>
<th>B[7]</th>
<th>B[6]</th>
<th>B[5]</th>
<th>B[4]</th>
<th>B[3]</th>
<th>B[2]</th>
<th>B[1]</th>
<th>B[0]</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>5</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
<td>1</td>
</tr>
<tr>
<td>1</td>
<td>230</td>
<td>1</td>
<td>1</td>
<td>1</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>1</td>
<td>0</td>
</tr>
<tr>
<td>2</td>
<td>130</td>
<td>1</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
</tr>
<tr>
<td>3</td>
<td>5</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
<td>1</td>
</tr>
</tbody>
</table>
<p>Bit-Sliced Indexでは、物理的には縦方向のBitmapを持ちます。この例では行数が4で桁数が8(bit)なので、長さ4のBitmapが8個作られます。</p>
<p>ナイーブなBitmap Indexでは行番号を指し示すBitmapが値ごとに作られますが、今回は値自体もBitmapでエンコーディングするのでこんがらがりがちです。上記の表を行列と捉えて、横方向のBitmapは値自体の表現であり、縦方向のBitmapは値の特定の桁が一致する行番号を指し示すBitmapと言えます。</p>
<p>価格が最大で255円だとすると、基数2のBlit-Sliced Indexで必要なビットマップは8個です。ナイーブなBitmap Indexなら最大256個のビットマップが必要になることと比べると、大幅にサイズを抑えられることが分かります。</p>
<h3>Bit-Sliced Indexによる合計計算（基数2の場合）</h3>
<p>応用のアルゴリズムとして、Bit-Sliced Indexでカラムに含まれる値の合計値が計算できます。元々の目的である索引以外にも使えるのが面白いです。</p>
<pre><code class="language-cpp">/**
 * B: 特定カラムCのBit-Sliced Index (B[i]はi番目のビットに対応するビットマップ)
 * Bf: 条件を満たす行を示すビットマップ (Foundset)
 * num_bits: 値を表現するのに必要なビット数(横方向のBitmapのビット数)
**/
int sum = 0;
for (int i = 0; i &lt; num_bits; ++i) {
    // i番目のビットが立っている行だけを対象に、2^i を加算
    sum += 2^i * POPCOUNT(B[i] AND Bf);
}
return sum;

</code></pre>
<h3>基数</h3>
<p>ここまで基数2を例にしてきましたが、他の基数を取ることもできます。例えば基数10とすると、1000未満の整数であれば100,10,1の位の3つの10bitのスライスで表現し、位の値がNならスライスの右からN番目に1を立てます。</p>
<p>例えば230は100の位が2、10の位が3、1の位が0なので、以下のようになります。<br>
<code>0000000100</code>(100の位) <code>0000001000</code>(10の位) <code>0000000001</code>(1の位)</p>
<p>基数は単一である必要はなく、位ごとに変えることもできます。</p>
<p>基数の増減に伴うトレードオフはサイズとクエリ効率にあるようです。基数を増やすサイズは増えますが、例えば等価検索の効率が良くなることは明らかです。</p>
<h3>Encodingと検索</h3>
<p>値のBitmap(横方向)のEncodingのバリエーションとして、Equality EncodingとRange Encodingがあります。</p>
<p>Equality Encodingは値がNならN番目のbitに1を立てるもので、ここまでで説明してきた方法です。<br>
Range Encodingでは、値がNならN番目のbitとその左のbit全てに1を立てます。</p>
<p>例えば基数10で230を表現すると、100の桁が2、10の桁が3、1の桁が0ですから、以下のようになります。<br>
<code>0000000100 0000001000 0000000001</code>(Equality Encoding)<br>
<code>1111111100 1111111000 1111111111</code>(Range Encoding)</p>
<p>Range Encodingはその名の通り範囲検索に強いエンコーディングです。</p>
<p>それぞれのエンコーディングで等価検索と範囲検索のアルゴリズムがあります。複雑なので、範囲検索の大雑把な方針のみ説明します。</p>
<p><strong>Equality Encodingの範囲検索</strong><br>
例えば特定の値より大きいデータを取る場合、位だけを見て対象の値より大きいと分かる行を取るステップと、同じ位の中で対象の値より大きい行を取るステップがあります。</p>
<p>例えば基数2で <code>価格 &gt;= 5 (バイナリ: 00000101)</code> を検索する場合、以下の2つの結果の和集合が結果です。</p>
<ul>
<li>8以上255以下の行
<ul>
<li>B[7]からB[3]までのうちどれか一つでも1が立っている(ORで取得)</li>
</ul>
</li>
<li>5以上7以下の行
<ul>
<li>B[2]が立っていて、B[1]かB[0]のうちどちらか一つでも1が立ってる(ANDとORで取得)</li>
</ul>
</li>
</ul>
<p><strong>Range Encodingの範囲検索</strong><br>
特定の値より大きいデータを取る場合、その値のbitだけをチェックします。例えば基数10で値が200以上のデータを取る場合、100の位のスライスの右から1番目のbitが0である行を取得します。</p>
<h2>まとめ・感想</h2>
<p>Bitmap Indexと言えばデカいイメージがありますが、対策としていろいろなアイデアが提案されています。こんなにアイデアを凝らすほどAND/ORが効率的に処理できるBitmapが魅力的ということですね。</p>
<p>Roaring Bitmapに比べるとBit-Sliced Indexはそこまで流行っていないような気もします。カラムナDBであれば数値型はカラムナだけで十分早いからでしょうか。行指向のDBでは有用な気もしますが、更新が重いからかもしれません。</p>
<p>また、Bit-Sliced Indexの基数とエンコーディングについては、クエリやデータパターンに応じて選ぶのが重要な気がします。それぞれの特性・トレードオフを整理するところまでは今回は辿り着けませんでしたが、興味があれば各種論文を見てみると良いかもしれません。</p>
<h2>参考資料</h2>
<p><a href="https://dl.acm.org/doi/10.1145/253262.253268">Improved query performance with variant indexes | ACM SIGMOD Record</a><br>
<a href="https://dl.acm.org/doi/10.1145/276305.276336">Bitmap index design and evaluation | ACM SIGMOD Record</a><br>
<a href="https://arxiv.org/abs/1004.0403">[1004.0403] CONCISE: Compressed 'n' Composable Integer Set</a><br>
<a href="https://roaringbitmap.org/">Roaring Bitmaps</a></p>


いろいろなBitmap Indexの紹介

Engineer Blog

Recent Article