Engineer Blog

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

巨大モノレポ環境での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開発の領域を飛び出して、新しい技術スタックに触れることで多くの学びを得ることができました。 この記事では、そんな貴重な体験について詳しくお話ししたいと思います。

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

こんにちは！10月初旬から4月末までの7ヶ月間、ソフトウェア開発のインターンとしてプレイドで働いていた[上野海吏](https://x.com/kairi_noel)(@kairi_noel)です。

プレイドで7ヶ月間の開発インターンで体験したことと得られた学び

AIエージェントによるセキュリティレビューの試みを紹介します。

AIエージェントによるセキュリティレビューことはじめ

この記事では、MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーションシステムについて解説します。

MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーション

<p>プレイドが提供する<a href="https://karte.io/">KARTE</a>では、オンライン上のエンドユーザの行動データを活用するためにさまざまな分析機能を提供しています。<br>
その中で非常によくある集計がユニークユーザのカウントです。SQLで言うところのCOUNT(DISTINCT user_id)です。KARTEはMAU約8億の膨大な量のユーザを扱っていて、ユニークユーザ数を効率的に集計することは重要なテーマです。<br>
最適化のためにこのアルゴリズムについて深掘りする機会があったので、調べたことを説明していきます。</p>
<h1>HashTable</h1>
<p>最も一般的なのは、HashTable にキーを追加してカウントしていく方法でしょう。<br>
擬似コードは以下です(Linear Probing)</p>
<pre><code class="language-bash">initialize table
count = 0

insert(key):
  h = hash(key)
  bucket = h mod capacity;
  while table[bucket] is occupied:
    if table[bucket] == key:
      break
    bucket = (bucket + 1) mod capacity
  
  table[bucket] = key
  count = count + 1
  if load_factor() &gt; threshold:
    resize()
</code></pre>
<p>挿入の計算量はO(1)ですが、擬似コードからもわかる通り実際には以下のようなオーバヘッドが乗ります。</p>
<ul>
<li>ハッシュ計算</li>
<li>キーの一致判定</li>
<li>リサイズ(テーブルが埋まってきたら、大きくして作り直す)</li>
</ul>
<p>全体的にキーが長いほど、またテーブルが埋まっていくほど遅くなります。固定長で短いキーと比べて、可変長で長いキーの方が一致判定は遅くなりがちです。</p>
<p>使う側でできる最適化の余地としては以下のようなものがあります。</p>
<ul>
<li>リサイズの発生を抑えるために初期サイズを賢く設定する</li>
<li>データの特性に合わせて適切なアルゴリズムを選択する
<ul>
<li>主に別々のキーでバケットが衝突した時に代わりのバケットを選ぶ方法について、Robin hoodやQuadratic probingなどさまざまな手法があります。</li>
<li><a href="https://thenumb.at/Hashtables/">Optimizing Open Addressing</a></li>
</ul>
</li>
</ul>
<h1>Sketch</h1>
<p>結果が近似値で良ければ Sketch が使えます。<br>
HyperLogLog が有名ですが、すでに多くの記事で紹介されてるので代わりに KMV（K-Minimum Values）Sketchを紹介します。HyperLogLogも面白いので知らない方はぜひ調べてみてください。</p>
<p>KMV ではハッシュ関数をキーに適用して、得られた値のうち小さい順に k 個だけを保持します。<br>
ユニークなキーが多ければ多いほど小さい数字(と大きい数字)もたくさん現れるわけですから、保持するk個の値はより小さい値で埋まっていくことになります。<br>
言い換えると、k に含まれる値が小さいほどユニーク数が多そうだと言えます。</p>
<p>KMV ではこの k 個の中の最大の値 R を使って、ユニーク数を推定します。</p>
<pre><code class="language-bash">推定値 = k / R
</code></pre>
<p>たとえば、 ハッシュ関数の出力が[0, 1)、 k=3 、R=0.5であれば、6個のユニークなキーがあると推定されます。</p>
<p><img src="https://ik.imagekit.io/plaid/9d6a250e-5997-42ce-93fd-a3102b6cb6e6/%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-04-0415.36.59.png" alt="スクリーンショット2025-04-0514.30.38.pngスクリーンショット2025-04-0415.36.59.png"><br>
挿入の計算量はO(log k)で他の手法に劣りますが、メモリはかなり小さく保てます。</p>
<p>分散システムで顕著ですが、集計処理ではノード間での中間集計結果の受け渡しにコストがかかりがちです。そのコストが減らせるのも大きいメリットでしょう。</p>
<p>HyperLogLogより良いところとして、KMVはintersectionができます。実際の要素を保持していて、複数のSketchの共通要素を割り出せるためです。<br>
HyperLogLogでもunionはできるため包除原理で共通要素数の推定ができますが(|A ∩ B| = |A| + |B| - |A ∪ B|)、以下のように、対象のSketchが増えるほど非効率になっていきます。<br>
∣A∩B∩C∣=∣A∪B∪C∣−(∣A∣+∣B∣+∣C∣)+(∣A∩B∣+∣A∩C∣+∣B∩C∣)<br>
https://agkn.wordpress.com/2012/07/09/sketch-of-the-day-k-minimum-values/</p>
<h1>Bitmap</h1>
<p>入力が小さな整数であれば、Bitmap が使えます。キーに対応する位置のビットを立てていきます。たとえば入力のキーが42であればビット列の42番目を1にします。</p>
<p>挿入処理が軽いことと、最大値が小さければ小さい容量で表現できるのがメリットです。</p>
<p>以下は挿入処理の擬似コードです。</p>
<pre><code>bitmap = int64[(N + 63) / 64]

insert(key):
  # word(int64)の位置の計算。key &gt;&gt; 6 は key / 64 の意味
  word_index = key &gt;&gt; 6
  # word内でのbit位置の計算。key &amp; 63 は key % 64 の意味
  bit_offset = key &amp; 63
  bitmap[word_index] |= (1 &lt;&lt; bit_offset)
</code></pre>
<p>1キーに1byteを割り当てるシンプルなByteArrayにすれば、メモリを使う代わりにワードとビットの位置の計算も省略できそうです。CPUキャッシュミスが増える分遅くなることもあるので、データの特性によって検討するといいでしょう。</p>
<p>全てのキーを挿入したあと、立ってるビットを数えるにはCPU命令のpopcntを使うのが最も速いです。</p>
<p>古い言語や環境で動いていてpopcntが使えない場合はビットカウントアルゴリズムの出番です。もはや出番は少なさそうですが、面白いので紹介します。</p>
<p>ビットカウントアルゴリズムでは、ビット演算を駆使してビット列を2bit-&gt;4bit-&gt;8bitずつと小分けにして加算していきます。</p>
<p>以下分かりやすさのため8bitの入力を例にしますが、実際には64bitで処理することがほとんどです。</p>
<pre><code>bit_count(bits):
    bits = (bits &amp; 0b01010101) + (bits &gt;&gt; 1 &amp; 0b01010101);
    bits = (bits &amp; 0b00110011) + (bits &gt;&gt; 2 &amp; 0b00110011);
    bits = (bits &amp; 0b00001111) + (bits &gt;&gt; 4 &amp; 0b00001111);
  return bits
</code></pre>
<p><img src="https://ik.imagekit.io/plaid/f72cdfe2-c328-4d7d-81b5-c53d8806fe53/%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-04-0514.30.38.png" alt="スクリーンショット2025-04-0514.30.38.png"></p>
<p>基本的な演算をいくつか組み合わせるだけで何重にも並列で計算できてしまうのがすごいところです。</p>
<p>また、まとめてカウントするのではなく挿入時にビットのチェックをして都度カウントを増やす方法も取れます。空間に対して入力のキー数が少ないとわかっている場合は、その方が効率が良さそうです。ただしまとめてカウントする方も、分岐がない分CPU内での並列化も効いて速いので、多くの場合はそちらを採用していいと思います。(都度カウントしたいくらい入力が少ないとわかってるなら、そもそもBitmapよりHashTableの方が適してる気もします。最初のメモリ確保が小さく済ませられるため)</p>
<h1>ベンチマーク</h1>
<p>以下の3パターンでベンチマークを取りました。(kmvは良い実装が見つからず、AIもうまく書いてくれなかったので断念)</p>
<ol>
<li>HashTable(key=32byte, <a href="https://github.com/attractivechaos/klib/blob/5c1451caa1ee476624d00eed71810532c89b82d1/khash.h">klibのkhash</a>)
<ol>
<li>ハッシュ関数はdjb2に類似した反復ハッシュ。Open AddressingでQuadratic Probing。初期サイズはデフォルトの16</li>
</ol>
</li>
<li>HashTable(key=4byte, kilibのkhash)
<ol>
<li>ハッシュ関数はThomas Wangハッシュ。他は同上</li>
</ol>
</li>
<li>Bitmap(key=4byte)</li>
</ol>
<p>パターン1だけ入力のキー長が違います。意図としては、HashTableによるナイーブなユニークユーザカウント(UUIDを想定して32bytesのstring)と、最適化を意図してキーをint32にした手法を比較することです。</p>
<p>入力のデータセットは下記で、全てのキーを追加してユニークカウントを取るまでの時間を測りました。</p>
<ul>
<li>トータルのキー数: 10,000,000</li>
<li>ユニークなキー数: 100,000</li>
<li>int32の場合の最大のキー:  10,000,000</li>
</ul>
<p>それぞれ5回実行し、かかった時間の平均をとります。</p>
<p>コード: <a href="https://gist.github.com/takaaki7/5cdcee9cacd5133fde10c7f9edf114a2">uniqueue_count_algorithm_benchmark</a></p>
<h3>ベンチマークの結果</h3>
<p>入力が32bytes stringのHashTableとint32(4bytes)のHashTableで、30倍の差が出ました。</p>
<p><img src="https://ik.imagekit.io/plaid/aea5e11a-689f-4549-a63a-26c775cf601e/hashtablebench.png" alt="hashtablebench.png"><br>
stringの方をperfで見ると、strcmpが特に重いです。キーの一致判定をしてる部分ですね。</p>
<p><img src="https://ik.imagekit.io/plaid/c7bded59-2b26-4903-8479-63cbdbcc865c/hashtableperf.png" alt="hashtableperf.png"><br>
今回はCPU観点だけでの比較ですが、データベース上での扱いを考えると、安くて遅いストレージとの通信を減らして如何にキャッシュに載せるかも肝になります。その観点でもデータを小さくすると圧倒的に速いです。</p>
<p>また、同じint32でもHashTableよりもBitmapの方が6倍速い結果でした。</p>
<p><img src="https://ik.imagekit.io/plaid/fd06c926-424d-4ef8-9d1a-1d2f24316fc6/hashvsbitmap.png" alt="hashvsbitmap.png"></p>
<h1>終わりに</h1>
<p>行動分析に関して言えば、匿名ユーザも含めたデータ活用であればIDを4bytesまで短くすることは簡単ではないです。実際にはユニークユーザのカウントでここまで最適化した手法を使えることは多くないでしょう。</p>
<p>ただ本来は日本の全人口(1.2億)であってもわずか15mbのBitmapで表現できる量であり、空間分割や並列化を駆使しながら前処理をすればIDの短縮やBitmapカウントの適用も現実的なはずです。</p>
<p>この記事の内容はほんの一つに過ぎませんが、人の行動分析に対して、こういったアイデアを適用しながら新しいエンジンを開発中です。採用強化中です。応募待ってます！！</p>
<div class="iframely-embed" data-embedded-url="https://open.talentio.com/r/1/c/plaid/pages/106299"><div class="iframely-responsive" style="padding-bottom: 30.2778%; padding-top: 120px;"><a href="https://open.talentio.com/r/1/c/plaid/pages/106299" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fopen.talentio.com%2Fr%2F1%2Fc%2Fplaid%2Fpages%2F106299&key=878c5bef402f0b2911bf6d4ce6261abd">Software Engineer, Database Internals / 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>


異なり数を数えるアルゴリズムの概要と、それらのパフォーマンスについて比較しています

異なり数を数えるアルゴリズムとパフォーマンス比較

<h1>Introduction</h1>
<p>KARTEを支えるリアルタイムユーザー解析エンジン（Blitz）のパフォーマンスに関する記事です。解析基盤が抱えていたボトルネックを解消した方法について、新旧のアーキテクチャの違いにフォーカスしながら説明していきます。</p>
<p>以下記事の続編にあたるので、事前に読むのがオススメです。<br>
<a href="https://tech.plaid.co.jp/blits_pre_aggregation">Blitz（前編）：自由度と即時更新性を担保したAggregation</a><br>
<a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術（強整合な解析）</a></p>
<h1>課題</h1>
<p>KARTEのエンドユーザー(以下ユーザー)の統計情報は平均でも100kb以上と大きく、取得コストはやや大きいです。統計情報が大きくなる要因として、以下が挙げられます。</p>
<ul>
<li>統計値をフィールドやタイムウインドウごとに複数種類保持</li>
<li>一部の統計値では送信された文字列をそのまま保持</li>
</ul>
<p>下記は統計情報のイメージです。</p>
<pre><code class="language-json">{
  $week: {
    $buy: {
      sku: {
        last: &quot;xxxxxxxxxxxxxxx&quot;,
        first: &quot;yyyyyyyyyyyyyyyyyy&quot;,
        sets: [&quot;xxxxxxxxxxxxxxx&quot;,&quot;yyyyyyyyyyyyyyyyyy&quot;],
        ....
      },
      price: {
        last: 100,
        sum: 2000,
        max: 200,
        ...
      }
    }
  }
}
</code></pre>
<p>統計情報はBigtableに保存しています。</p>
<p>旧アーキテクチャでは、ユーザーのイベントが発生するたびにBigtableからこのユーザー統計情報を取得しており、全体の中で最もコストとレイテンシがかかる処理でした。</p>
<p><img src="https://ik.imagekit.io/plaid/9a8c4407-7e37-4509-8cef-252587a266af/%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-03-0523.31.10.png" alt="スクリーンショット2025-03-0523.31.10.png"></p>
<p>キャッシュの導入は整合性の問題で困難でした。Bigtableから取得した統計情報をそのままキャッシュすると、一部のイベント(まだRealttime Queue上にあってConsumeされてないイベント)が畳み込まれていない統計情報を使い続けることになってしまうからです。</p>
<p>このような要因からアクション配信のレイテンシはp95で1.5秒程度でした。ユーザー体験を損ねているというフィードバックをお客様からいただくこともよくありました。</p>
<p>このボトルネックをBlitzで解消した方法について説明します。</p>
<h1>1. 取得するデータの絞りこみ</h1>
<p>Blitzのバックエンドは、アクションを配信するサーバ(以下アクションサーバ)と、統計情報を永続化するサーバに大きく分かれます。<br>
アクションサーバでは、ユーザーの統計情報を使ってパーソナライズされたアクション(メールやポップアップ)を配信します。</p>
<p>ここで、保存されてる統計情報のうち実際に配信に使われる統計値はごくわずかです。<br>
旧アーキテクチャではほとんど全ての統計情報を取得していましたが、Blitzでは、お客様が設定したアクションの配信設定から必要最小限の統計情報のフィールドと<a href="https://cloud.google.com/bigtable/docs/filters?hl=ja">Bigtableのフィルタ</a>を算出し、データベースから取り出しています。</p>
<p><img src="https://ik.imagekit.io/plaid/8b05e23c-02bb-430c-9c98-6351ca4d0585/%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-03-0415.36.06.png" alt="スクリーンショット2025-03-0415.36.06.png"><br>
一見シンプルに見えますが、以下の点が課題でした。</p>
<ul>
<li>配信設定に関する機能は多岐に渡り、必要な統計値を算出するための対応箇所が多い</li>
<li>統計値間の依存関係がある
<ul>
<li>例：「平均」は「合計と回数」に依存(後述の通り統計情報をキャッシュ上で更新し続けるため、依存する統計値も必要)</li>
</ul>
</li>
<li>統計値のタイムウインドウ間の依存がある
<ul>
<li>例：「前回のセッション」は「最新のセッション」に依存(こちらもキャッシュ上で更新し続けるために必要)</li>
</ul>
</li>
<li>Bigtableのフィルタは細かく設定しすぎるとCPU消費が大きくなり逆効果
<ul>
<li>Bigtableのフィルタだけだと絞り込みきれないから、デシリアライズ時にも余分なフィールドの実体化を省略したい</li>
</ul>
</li>
</ul>
<p>対応として、フィルタの中間表現を定義し、統計値間の依存を考慮して中間表現を算出するモジュールを作ることで、安全かつ簡単に統計値への依存を追加できるようにしました。また、中間表現を挟むことで、Bigtableとデシリアライザのフィルタリングもシンプルに実装できました。この中間表現はMongoDBの機能になぞらえてProjectionと呼んでいます。</p>
<p><img src="https://ik.imagekit.io/plaid/690e6e21-ba66-4be9-a7d6-799464462f66/%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-03-0516.12.02.png" alt="スクリーンショット2025-03-0516.12.02.png"><br>
こちらは全体のフローのイメージです。</p>
<p><img src="https://ik.imagekit.io/plaid/d619202c-7ca2-4106-b63f-6c520087dd6a/%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-03-0416.53.34.png" alt="スクリーンショット2025-03-0416.53.34.png"></p>
<p>またデータフォーマット自体もJSONからMessagePackに変更して、少量化とSerialize/Deserializeの改善をしました。</p>
<p>(厳密にはこれらの最適化自体はリアーキテクチャせずとも実装可能でしたが、改修の難易度が高かったので、リアーキテクチャに伴うコードベースとデータの刷新に混ぜ込む形で実装しました)</p>
<h1>2. キャッシュ</h1>
<p>絞り込みによって一定の改善ができたものの、依然として取得処理は重いです。<br>
更なる改善として、Blitzではユーザーの統計情報をアクションサーバのメモリにキャッシュしています。</p>
<p>キャッシュの整合性と効率に焦点を当てつつ、その仕組みについて説明します。</p>
<p>前記事でも述べた通り、Blitzではアクションサーバの前段にBigtableベースのイベントキューがあります。また、キューにイベントが追加されるとLoadBalancer経由でアクションサーバに通知されます。<br>
<img src="https://ik.imagekit.io/plaid/f58e2d9b-6c30-4e0d-aeef-afe6bbc6cbc9/%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-03-1211.55.47.png" alt="スクリーンショット2025-03-1211.55.47.png"></p>
<p>どのアクションサーバに通知が届いても、そのサーバは、今までに送られた全てのイベントが畳み込まれた最新のユーザー統計情報を扱わないといけません。一見難しく見えますが、強整合性が担保されたキューが前段にあることで、シンプルに実現できました。</p>
<p>キューのチェックポイントも統計情報と一緒に保持し、通知を受けたらそのチェックポイント以降のデータをキューからスキャンすればいいのです。</p>
<p>以下は、アクションサーバの処理フローを示した疑似コードです。</p>
<pre><code class="language-java">handle_notification(user_id):
    user = cache.get(user_id)
    if user is None:
        user = db.get_user(user_id)
    
    # チェックポイント以降のイベントをBigtableからスキャン
    events = scan_events(user_id, user.checkpoint)
    
    for event in events:
        new_user = reduce(user, event)
        deliver_personalized_action(event, new_user)
    
    new_user.checkpoint = events[-1].timestamp
    
    cache.put(user_id, new_user)
</code></pre>
<p>基本的なロジックはこれだけです。</p>
<p>また、LoadBalancerにはGCPのL7 Internal LoadBalancerを採用しました。<a href="https://cloud.google.com/load-balancing/docs/backend-service#session_affinity">Session Affinity</a>のキーにuser_idを指定して同じユーザーのイベントをできるだけ同じサーバに振り分けることで、キャッシュ効率を上げています。<a href="https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy">Consistent Hash</a>を使うことで、バックエンドの台数が増減してもキャッシュミスは少なく収まります。</p>
<p>データをしっかり絞り込んだおかげか、メモリやGC関連で苦戦を強いられることもこれといってありませんでした。machine typeも特別メモリが大きいものではないです。</p>
<p>ここまでの説明だと簡単そうに見えますが、実際には以下のような点について、さらに複雑なロジックを実装しています。</p>
<ul>
<li>アノニマスユーザーがサービスにログインしたときに、サービスのユーザーIDでマージ</li>
<li>イベントの順序性の担保
<ul>
<li>ナイーブにBigtableのキューのキーにタイムスタンプを付与するだけだと、クロックのズレなどの要因で順序担保ができません</li>
</ul>
</li>
<li>Statsを都度作り直すと重いので、スレッド間の競合制御をしながらキャッシュをmutableなobjectとして更新</li>
</ul>
<h1>結果</h1>
<p>他にも様々な改善が加えられた新アーキテクチャに移行して、以下が達成できました。</p>
<ul>
<li>Compute Engineのコストが7割減</li>
<li>アクション配信のレイテンシ(p95)が1500msec -&gt; 200msec
<ul>
<li>配信が遅いという声も聞かなくなりました</li>
</ul>
</li>
<li>Bigtableのコストが数割減(正確なデータが探せませんでした…)</li>
</ul>
<p>裏側としてはなかなかいい成果だったと思います。ただ、2022年の円安が加速している時期に移行してコスト削減の効果が相殺されたことなどもあり、最終的には少し派手さに欠ける結果になったのを覚えています笑</p>
<h1>まとめ</h1>
<p>以前のアーキテクチャでは解析が非同期であるがゆえに、結果整合性しか担保できず、統計情報のキャッシュもできていませんでした。</p>
<p>BlitzではBigtableのキューを前段に置くことで、整合性とパフォーマンスの2つの問題が解決できました。さらに言えば、受信したリクエストをすぐにキューに積むため、データが欠損するリスクへの耐性も上がったと言えます。</p>
<p>1つのアイデアで複数の課題が解けたところは面白い点だと思います。</p>
<p>他にも様々な最適化や運用上の工夫が凝らされているので、今後紹介できればと思います。</p>


KARTEのリアルタイムユーザー解析エンジンのアーキテクチャを刷新し、キャッシュ設計等を工夫してボトルネックを解消した方法を説明します

Blitz: リアルタイムユーザー解析エンジンのボトルネックを解消したキャッシュ設計 - PLAID engineer blog

Blitz: リアルタイムユーザー解析エンジンのボトルネックを解消したキャッシュ設計

<p>こんにちは、株式会社プレイドで内定者アルバイトとしてCore Platform Team でプラットフォームエンジニアをしている小林と申します。プレイドには今春新卒として入社予定です。</p>
<p>今回は福岡で実施された第17回データ工学と情報マネジメントに関するフォーラム <a href="https://pub.confit.atlas.jp/ja/event/deim2025">DEIM2025</a> に参加しましたので、その内容をレポートします！</p>
<h2>プレイドは日本データベース学会(DBSJ)に入会しました</h2>
<p>今年から株式会社プレイドは、データベースやデータ工学分野における最新の研究動向の把握やコミュニティへの貢献を目的に、日本データベース学会(<a href="https://dbsj.org/">DBSJ</a>)に維持会員として入会しました。</p>
<p>その活動の一環として、DBSJが主催する「第17回データ工学と情報マネジメントに関するフォーラム(DEIM2025)」に本年ゴールドスポンサーとして参加し、ブースの出展・技術報告に加え、論文の発表を行いました。</p>
<h1>DEIMについて</h1>
<p>DEIM は日本データベース学会・電子情報通信学会 データ工学研究専門委員会・情報処理学会 データベースシステム研究会が主催している、データ工学と情報マネジメントに関する研究発表や意見交換を目的とした学術集会です。今回は2月27日~3月1日がオンライン、3月3日と4日がオンサイトで福岡国際会議場での開催となりました。</p>
<h1>技術広報活動</h1>
<p>会社として学会に参加し、以下2つを実施しました。</p>
<ol>
<li>ブース出展</li>
<li>技術報告論文の執筆、発表と技術登壇</li>
</ol>
<h2>ブース出展</h2>
<p>株式会社プレイドはDEIM2025に初めてゴールドスポンサーとして参加し、スポンサーブースを出展しました。ブースでは社員が弊社の主要プロジェクトである<a href="https://karte.io/">KARTE</a>や、用いられている技術の説明を行いました。データベースやビッグデータの分析に関連する研究を実施している研究者の方が多く参加されていたので、技術スタックや現状の課題、技術的に難易度の高い部分についてなど様々な質問をいただき、多くの学生や企業の方とお話することができました。また、弊社はロゴ入りのタンブラーやサウナハットなどのグッズと、事業内容とそこで利用している技術についてのパンフレットの配布も行いました。ブースを訪れてくださった皆さん、ありがとうございます！</p>
<p><img src="https://ik.imagekit.io/plaid/30bbfdc3-5b18-4b06-a667-4d50b7145557/756d8989-cdc2-4ffa-9a52-d3e15786a5c9.webp" alt="756d8989-cdc2-4ffa-9a52-d3e15786a5c9.webp"></p>
<h2>技術報告論文の執筆、発表と技術登壇</h2>
<p>「<a href="https://pub.confit.atlas.jp/ja/event/deim2025/presentation/4D-04">Blitz: データ強整合性を持つリアルタイムエンドユーザー解析エンジンBlitz: データ強整合性を持つリアルタイムエンドユーザー解析エンジン</a>」と題し、メインのプロダクトであるKARTEで開発しているデータ解析基盤についての論文を投稿し発表を行いました。多くのお客様にご利用いただいているKARTEのサーバーは日中平均で秒間7万リクエスト、多いときには秒間13万のリクエストがあり、それぞれに対して強整合性を保ちつつリアルタイムで解析を行い、500ms 以下で結果を返却しています。このような高スループットと強整合性を実現し実際の環境で運用する難易度は高く、興味深い論文になっているのではないかと思います。また、「<a href="https://pub.confit.atlas.jp/ja/event/deim2025/presentation/2F-05">月間180PBのストリーム処理されたイベントデータを使用した, KARTEのリアルタイムインタラクションマネジメント</a>」という題名で技術登壇も実施しました。こちらでもリアルタイム解析基盤についての紹介や、大規模データを扱うにあたっての工夫などを紹介しています。スライドも公開されているので、ご興味のある方はこちらもぜひご覧ください！</p>
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/a7f1e9a3adba4de2b87e4b5cac50529b" title="月間180PBのストリーム処理されたイベントデータを使用した, KARTEのリアルタイムインタラクションマネジメント" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>
<p>DEIMでは他にも技術報告を実施している企業が多くあり、企業ごとの独自の課題に対する様々なアプローチを見ることができとても魅力的でした。</p>
<h1>参加した感想</h1>
<p>私は学会に参加するのが初めてだったので、どんな雰囲気なのかと少し緊張しながら会場へ向かったのですが、会場では参加者同士の交流が盛んに行なわれており非常に楽しい時間を過ごすことができました。</p>
<p>ポスターセッションの時間は1時間半ごとに区切られているのですが、魅力的なポスターや元々興味を持っていた分野に関連するものなど心を惹かれる発表が多くあったため見て回ることに苦労しました。</p>
<p>LLMを活用した商品レビュー分析や分散データベースのトランザクションに関わる研究、さらにはデータサイエンスを活用し周期性を持った天体の周期分析に関わる研究など多様な研究分野の発表があり、初見では理解できないことが多かったのですが、専門外の私に対してどなたもわかりやすく説明してくださいました。学校や会社、年齢の垣根を超えて学術的な交流ができる学会という環境の素晴らしさを実感しました。</p>
<p>また、私は東京在住であり、大学も会社のオフィスも東京にあることから首都圏の学生との交流がどうしても大きな割合を占めてしまうのですが、今回の学会は福岡で開催されており関西や九州の学生の方々とお話することができたのも良かったです。今回はスポンサー企業所属としての参加でしたが、まだ大学にも在籍している学生なので学生目線で参加していた学生の方々とお話することができたかなと思います。</p>
<p>聞き切れていない発表も多くあるのですが、お話を伺ったなかで個人的に興味深かった研究をいくつかご紹介します。</p>
<h2>部分ステートマシンレプリケーションにおける投機的分散トランザクション処理</h2>
<p><a href="https://pub.confit.atlas.jp/ja/event/deim2025/presentation/7C-03">https://pub.confit.atlas.jp/ja/event/deim2025/presentation/7C-03</a></p>
<p>白石 裕輝1、杉浦 健人2、石川 佳治2 (1. NTT、2. 名古屋大学)</p>
<p>NTTコンピュータ&amp;データサイエンス研究所さんで行われている研究で、分散データベースのトランザクション処理を高速化する新たな手法を提案されています。分散データベースにおいてトランザクションを実施する際、既存のアプローチではトランザクション処理の順序や可否を分散して判定することで高速化を図っていますが、ロジックの実行がトランザクションのコミット後に行われるため複数のトランザクションが存在する場合ロジックの実行が遅延してしまいます。そこで、投機的に読み書きを行うことによってコミット前にロジックを実行し、実行遅延を軽減する手法を提案しています。</p>
<p>具体的な例を考えてみましょう。トランザクションAとBが存在する際に、既存手法ではAでの書き込みを待ってBでの読み取りを行いますが、Bで読み取る行にAによる更新が無い場合はこの待機時間は必要ありません。本手法では、コミット前に投機的な読み取りをし、読み取った後に更新が無い場合はこの待機を行わないという処理を行うことにより処理の高速化を行っているものと解釈しました。</p>
<p>プレイドでは MongoDB や Google Spanner といった分散データベースを積極的に活用しており、社内にはデータベースの内部構造に興味を持つ人も多くいます。こういった手法がデータベースに実装されていくことにより処理の高速化に繋がるので、基盤チームとしては見逃せない研究と言えます。</p>
<h2>局所探索法を用いた実体化ビュー選択によるクエリワークロード処理の高速化</h2>
<p><a href="https://pub.confit.atlas.jp/ja/event/deim2025/presentation/3C-03">https://pub.confit.atlas.jp/ja/event/deim2025/presentation/3C-03</a></p>
<p>アンダーソン 圭那1、鬼塚 真1、佐々木 勇和1、Yohanes Yohanie Fridelin Panduman1 (1. 大阪大学)</p>
<p>大阪大学に在籍している方の研究で、クエリワークロードの高速化を行う際の実体化ビューの選択手法を提案されています。複雑なクエリワークロードを実行する際は実体化ビューを用いることによりクエリの高速化が可能となりますが、どの部分クエリを実体化するかという選択は実体化ビューの容量や更新処理のコストなど考慮するべき変数が多数あります。既存の手法では確率を用い実体化ビューを選択していますが、本手法では局所探索法を用いて解の探索を行うことで既存手法より効率の良い実体化クエリの選択を可能としています。</p>
<p>プレイドでは多くの行動データを日々解析しており、その活用の際にはクエリの実行時間が問題となってきます。データが多ければ活用の幅も広がりますが、実体化ビューなどを利用しないと実行時間もデータ量に比例して長くなっていってしまいます。このような手法を用いることによりクエリの高速化が実現できれば、データの利活用をより進めることができそうです。</p>
<h2>偏向型テンソルストリームのための多方向特徴自動抽出とリアルタイムサイバー攻撃検出への応用</h2>
<p><a href="https://pub.confit.atlas.jp/ja/event/deim2025/presentation/4D-02">https://pub.confit.atlas.jp/ja/event/deim2025/presentation/4D-02</a></p>
<p>中村 航大1,3、川畑 光希1、田中 駿吾1,2、松原 靖子1、櫻井 保志1 (1. 大阪大学産業科学研究所、2. 大阪大学工学部電子情報工学科 、3. 大阪大学大学院情報科学研究科)</p>
<p>こちらも大阪大学に所属されている方の研究で、サーバーの通信ログなどから潜在的なパターンを抽出しサイバー攻撃を検知することを可能とする手法を提案しています。ログに含まれるポート番号などのカテゴリ属性と、時刻など連続的に変化する量的属性の両方をテンソルストリームとして扱い、一定時間ごとに傾向を分析することにより異常な活動を検知することができます。カテゴリ属性と量的属性を上手く扱い、さらに時系列パターン分析を用いることで既存の手法では検出が難しかった攻撃も異常として捉えることができるそうです。</p>
<p>KARTEでは様々なウェブサイトからの膨大な数のリクエストを処理しており、サイバー攻撃への対策は必須です。このような手法を取り入れることによって、今まで検知が難しかった攻撃を検知できるようになり、よりサイバー攻撃に強いサービスを作りあげることができるのではないかと考えています。</p>
<h1>最後に</h1>
<p>株式会社プレイドはDEIM2025に初めてゴールドスポンサーとして参加し、スポンサーブースを出展しました。</p>
<p>プレイドではデータベースやデータ解析といった分野と関わりが深いプロダクトの開発を行なっており、難易度の高い課題に取り組む機会が多くあります。DEIMにご興味のある方には、面白いと感じるポイントが多くあるのではないかと思います。プレイドの技術や、プレイドで働くことに興味を持たれた方は、是非以下のリンクを覗いてみてください。</p>
<p><a href="https://recruit.plaid.co.jp/product">採用ページ</a></p>
<p><a href="https://tech.plaid.co.jp/blits_pre_aggregation">Blitz（前編）: 自由度と即時更新性を担保したAggregation</a></p>
<p><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</a></p>


DEIM2025参加レポート：内定者のエンジニアが初めての学会で得た学びと刺激

<h2>はじめに</h2>
<p>プレイドのApp Teamでエンジニアをしている市川です。</p>
<p>App Teamとは『KARTE for App』は分析から施策実行までをワンストップで提供し、モバイルアプリのエンゲージメントをより高めるためのプロダクトを提供するチームです。</p>
<p>今回はApp Teamのエンジニアだけで1日ハッカソンを開催し、KARTE for Appが提供するSDKから送信されるイベントデータをリアルタイムに近い速度で閲覧可能にする新機能を作りました！ 🥳</p>
<h2>なぜハッカソン？</h2>
<p>App Teamの開発は、「大きなIssue＝エピックでチーム対応、小さなIssue＝月1回のスプリントで個人ごとにIssueをアサイン」というスタイルで進めています。ただ、ちょうど中間レベルのIssueで「これがあったら便利だよね」と言われつつ、誰も手をつけられずにいたものが、なかなか実行に移されない課題がありました。そこで、チームビルディング観点も含めて「1日ハッカソンで一気に作ってしまおう！」というでハッカソンを決行しました 😎</p>
<h2>当日の流れ</h2>
<p>1日ハッカソンにはApp Teamのエンジニア4名、デザインエンジニア1名、そしてインターン生1名が参加しました。朝から集まって開発するというのは、なかなかない機会なので学園祭感で面白かったです！</p>
<p><strong>9:00〜</strong></p>
<ul>
<li>ブリーフィングと質問対応</li>
<li>タスク分担やざっくり設計の打ち合わせ</li>
</ul>
<p><strong>12:00〜</strong></p>
<ul>
<li>ランチ（お弁当を食べながら雑談＆進捗共有）</li>
</ul>
<p><strong>16:30〜</strong></p>
<ul>
<li>Pull Request作成・レビュー・動作確認</li>
</ul>
<p><strong>18:00〜</strong></p>
<ul>
<li>チーム内でデモ共有</li>
<li>「早く使いたい」というフィードバックに盛り上がるw</li>
</ul>
<p><strong>18:30</strong></p>
<ul>
<li>解散</li>
</ul>
<h2>作成したかった機能</h2>
<p><strong>概要</strong></p>
<ul>
<li>KARTE for Appが提供するSDKから送信されるイベントデータを、<strong>ほぼリアルタイム</strong>でKARTE管理画面から閲覧できるようにする</li>
</ul>
<p><strong>制約</strong></p>
<ul>
<li>従来の仕組みではイベントデータが送信されてから、KARTE管理画面で閲覧するまでに数秒遅延があるため別の仕組みを考える（詳しくは後述）</li>
<li>社内検証から始めて、将来的にはクライアントにも提供する想定</li>
<li>保守性・拡張性・セキュリティを担保した設計にすること</li>
</ul>
<h2>背景/課題</h2>
<p>KARTE for Appの提供するSDKは、モバイル向けのネイティブアプリ上でのユーザー行動を計測したり、アプリ内メッセージやプッシュ通知でのアクションを行うことが可能にするものです。</p>
<p>実際にアプリを操作すると、そのイベントデータをKARTE管理画面で閲覧できますが、閲覧タイミングには数秒のラグが発生します。プレイドの強みでもあるリアルタイム解析基盤「Blitz」を通し、BigQueryに保存されたデータをKARTE管理画面で参照し表示しているためです。Blitzについて、詳しく知りたい方はこちらをご覧ください！<br>
<a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</a></p>
<p>実際の運用上、「イベントデータが正しく送信されているかをテストしたいだけ」の場面があり、その数秒が意外と煩わしいという声があがっていました。</p>
<h2>成果物</h2>
<ul>
<li>送信されたイベントデータを閲覧するための画面（React）</li>
<li>SDKから送信されるイベントデータを受け取るエンドポイントとロジック（express）</li>
<li>イベントデータを新しく作成したエンドポイントに送付するモジュールの作成（iOS/Android）</li>
</ul>
<h3>実装の仕組み</h3>
<p><strong>従来のフロー</strong></p>
<p><img src="https://ik.imagekit.io/plaid/85f19485-7f93-4445-bddd-e89169efc517/%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-02-269.56.02.png" alt="スクリーンショット2025-02-269.56.02.png"></p>
<p>従来は、SDKからのイベントデータが「Blitz」で解析され「BigQuery」に保存されてから、KARTE管理画面から参照しています。数秒の遅延が発生する原因でした。</p>
<p><strong>新しく作成したフロー</strong></p>
<p><img src="https://ik.imagekit.io/plaid/7d1276bf-05b1-4afa-959b-28648c07f69a/%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-02-269.56.20.png" alt="スクリーンショット2025-02-269.56.20.png"></p>
<h3>工夫した点</h3>
<ul>
<li>「SSE（Server-Sent Events）」を使い、サーバーがイベントを受け取ったタイミングでフロントエンドに即通知する設計を採用した</li>
<li>「KARTE」はマイクロサービスアーキテクチャを採用しており、イベントデータ受信用サービスとKARTE管理画面は別サービスになっている
<ul>
<li>ここを「Redis」の<a href="https://redis.io/docs/manual/pubsub/">Pub/Sub機能</a>で接続して、リアルタイム通知を実現した</li>
</ul>
</li>
<li>クライアントの本番環境には要らない機能なので、コアのSDKのモジュール群とは別のモジュールとして開発し、コア側はイベントビューワーのモジュールを「知らない」状態を実現した</li>
<li>フロントエンド側は、<a href="https://tech.plaid.co.jp/analyze-internal-ui-library-usage">弊社デザインシステムSourのReactJS用ライブラリである「sour-react」</a>を使うことで、フロントエンジニアだけで綺麗なUIを実現した</li>
</ul>
<h3>デモ</h3>
<p>今回開発したUIでは、アプリ操作（ボタンクリックなど）からリアルタイムにイベントデータがKARTE管理画面で表示され、イベントデータをその場で確認できます。<br>
<img src="https://ik.imagekit.io/plaid/b4b580dc-5ecd-417a-b576-a0d364d0d7bc/ScreenRecording.gif" alt="ScreenRecording.gif"></p>
<p>従来の画面（数秒の遅延があるため、テスト時には待ち時間が発生していました）</p>
<p><img src="https://ik.imagekit.io/plaid/be922b0a-d55f-417d-ba98-da8ba318b9a9/%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-02-0619.30.46.png" alt="スクリーンショット2025-02-0619.30.46.png"></p>
<p>この機能によって「誤ったフィールドを送っている」「イベント自体が飛んでいない」といったミスを即座に発見できるようになりました！この改善によってデバッグやテスト作業が劇的に楽になり、チーム内外のメンバーから「便利になった」と好評です！</p>
<h2>まとめ</h2>
<p>1日ハッカソンという短い時間でしたが、集中力とモチベーションを高められたのも大きな成果です。実際にメンバーからは「丸一日コードに没頭できて最高」「少し重いなと思っていたIssueも意外と完成できた」といった声があがりました。</p>
<p>App Teamでは、クライアントSDKの開発と運用からKARTE管理画面の開発をしています。スタートアップからメガバンクまで、幅広いクライアントが利用できるマーケティング機能を提供するSDKを開発し、日々数千万人を超えるエンドユーザーへの価値提供ができる環境です。<br>
興味がある方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。お待ちしております！</p>


この記事ではMobile SDK発火のKARTEイベントをリアルタイムに閲覧する機能をハッカソンで１日で作った話を掲載します

Mobile SDK発火のKARTEイベントをリアルタイムに閲覧する機能をハッカソンで１日で作った話

<p>こんにちわ、プレイドでエンジニアをしている塩澤（<a href="https://github.com/hshiozawa">@hshiozawa</a>）です。</p>
<p>プレイドはミッションとして「データによって人の価値を最大化する」を掲げています。私たちにとって「データ」は会社のミッションに掲げるほどの重要な存在です。プレイドは多種多様なデータを扱っていますが、データから価値を生み出すためにはその品質（Data Quality）が非常に重要となります。</p>
<p>この記事では Google Cloud Dataplex の<strong>自動データ品質（Auto Data Quality）機能</strong>を使ったデータ品質向上の取り組みについてご紹介します。</p>
<h1>データ品質</h1>
<p>プレイドでは Google Cloud の BigQuery を利用して多種多様な大量のデータを扱っています。データパイプラインやテーブルも数多くあり、マイグレーションも頻繁に行っています。このような大量のデータから価値を生み出すために、データ品質の向上は必要不可欠なものです。</p>
<p>たとえば、ユーザーの Web サイト上での行動データを考えてみます。サイトの運営者はサイトでのユーザー体験をよりよくするためにデータを使ってユーザーを理解しようとします。その時、行動データが次のような状況だとどうなるでしょうか？</p>
<ul>
<li>ユーザー ID が含まれていないレコードが存在する</li>
<li>行動イベントのレコードが一部抜け落ちている</li>
<li>購入イベントのレコードが重複して存在する</li>
</ul>
<p>このような状況ではデータからユーザーを正確に理解することはできませんし、ユーザー体験を向上することもできません。これはあくまで一例ですが、ユーザーのイベントに限らずデータの品質が低い場合には、そこから価値を生み出すことが難しくなります。</p>
<h2>定義</h2>
<p>ここまでは曖昧に「データの品質」という言葉を用いてきましたが、『データマネジメント知識体系ガイド 第二版』（通称 DMBOK）ではデータ品質を次のように定義しています。</p>
<blockquote>
<p>データ品質は、データ品質の各評価軸が要件を満たす度合いとして定義できる。これは要件を、（関連する）それぞれの評価軸ごとに策定する必要があることを意味する。データ品質の定義を簡潔にすると、「目的に適合している」となる。</p>
</blockquote>
<p>このようにデータ品質を考えるためにはデータを評価するための一定の軸を定める必要があります。DMBOK では一般的な合意が得られているデータの評価軸として次のようなものを挙げています（抜粋しています）。</p>
<ul>
<li>有効性（Validity）：定義された領域と一致しているかどうか</li>
<li>完全性（Completeness）：必要なデータが存在するかどうか</li>
<li>一貫性（Consistency）：同じルールで表されているかどうか</li>
<li>適時性（Timeliness）：ユーザーがデータにアクセスできるまでの時間</li>
<li>一意性（Uniqueness）：一意であるべきデータが重複してないかどうか</li>
</ul>
<p>データ品質を向上させるためには、データの特性に応じてこれらがどの程度満たされるべきかの要件を定める必要があります。その後、この評価軸がどれだけ満たされているかを実際に測定し、必要な修正を行います。そして最も重要な点は、この一連の活動を継続して続けていくことです。</p>
<h1>課題</h1>
<p>ここからはプレイドにおけるデータ品質に対しての課題について述べます。話を簡単にするため以下のようなシンプルなパイプラインを想定してみます。</p>
<p><img src="https://ik.imagekit.io/plaid/062cadf1-e172-4bfb-8608-2eea59633cfb/pipelines.png" alt="pipelines.png"></p>
<p>データソースで発生したデータは BigQuery に書き込まれます。その後、解析などのアプリケーションによってデータが変換され、他のテーブルに書き込まれます。このような構成のパイプラインはプレイドに多く存在します。</p>
<p>このようなパイプラインに対していくつかの方法でデータの正しさをチェックしていました。</p>
<p><img src="https://ik.imagekit.io/plaid/de391f90-7578-4620-b522-675d0b19ac9a/checks.png" alt="checks.png"></p>
<ol>
<li>データソースがデータを書き込む際に、書き込む側がデータを確認</li>
<li>データを変換した後に Transformer がデータの正しさを確認</li>
<li>テーブルのチェックジョブが定期的にデータのぬけもれを確認</li>
<li>他のパイプラインがデータを使う前にデータの整合性を確認</li>
</ol>
<p>このようにして様々な箇所で独自のデータのチェックが行われていました。また、これらはすべてのパイプラインで実現されていたわけではなく、それぞれのパイプラインの特性や重要度に応じて実装されていました。</p>
<p>これらの手法は必要に応じて要求に特化したチェックができるのでメリットもありますが、本質的には次のような問題を抱えていました。</p>
<h2>評価軸が不明瞭</h2>
<p>データ品質の定義で述べたように、データ品質には評価軸という考え方があります。しかし、この確認方法では、それぞれがどの評価軸に対応したチェックなのかが不明瞭です。この曖昧さによって問題を正確に捉えることが困難になり、効果的な施策が実行されない要因となっていました。</p>
<p>また、評価軸が不明瞭であることでデータ品質という概念自体をチームに浸透させることが難しいという面もありました。</p>
<h2>要求が分かりづらい</h2>
<p>評価軸の問題に加えて、それぞれのデータに求められている要求が明らかになっていないことは大きな問題でした。これらの方法によって「データに問題がない」ことは確認できています。しかし、データが満たすべき要求が明確になっていません。</p>
<p>これは要求をコード上に手続き的に記述したり、確認用の SQL クエリの実行で実現していることも要因です。手続き的なコードや確認用の長いクエリを見ただけでは、何が満たすべき基準なのかを判断することは難しくなってしまいます。</p>
<h2>観測可能性が低い</h2>
<p>既存の確認方法では「データがテストケースを満たしたかどうか」の単純な事柄しか分かりません。「テストケースは満たしているが品質が徐々に劣化している」ようなケースが把握できません。そのため、問題が起きる前に早めに手を打つことができません。また、過去の履歴を統一的に記録する仕組みがないため昔の品質や、品質の推移を確認できていません。</p>
<h2>仕組みの乱立</h2>
<p>それぞれの部分で独自の仕組みを作ったことで、プロダクトを横断する統一的な基準を作ることが難しくなってます。また、それぞれでデータの確認の実現方法が異なるため、あるチームは SQL クエリとして実現し、あるチームは API を利用して確認する、といったように確認方法が乱立しました。</p>
<p>実現方法が異なることでメンテナンスコストが高くなり、最悪の場合はメンテナンスされなくなり放置される可能性もあります。こうなるとデータ品質を保つことは難しくなります。</p>
<h1>Dataplex 自動データ品質の採用</h1>
<p><a href="https://cloud.google.com/dataplex?hl=ja">Google Cloud Dataplex</a> はデータを管理・統合するためのデータファブリックです。BigQuery に限らず分散したデータを統合・統制するためのデータカタログやデータメッシュなど、様々な機能を提供しています。</p>
<p>自動データ品質はこの Dataplex 内の機能の一つです。BigQuery のテーブルに対してルールを定義し、ルールを満たしているかどうかを確認することができます。</p>
<p>ここからは Google Cloud Dataplex の自動データ品質機能（以下、自動データ品質）を採用した理由について述べます。ここでは自動データ品質の利用の仕方については詳しく書きません。利用方法はドキュメント等を参考にしてください。</p>
<p><a href="https://cloud.google.com/dataplex/docs/auto-data-quality-overview?hl=ja">自動データ品質の概要  |  Dataplex  |  Google Cloud</a></p>
<h2>理由1：ルールを YAML で記述できる</h2>
<p>自動データ品質ではルールを下記のような YAML で記述することができます。</p>
<pre><code class="language-yaml">rules:
- uniquenessExpectation: {}
  column: transaction_id
  dimension: UNIQUENESS
- nonNullExpectation: {}
  column: amount
  dimension: COMPLETENESS
  threshold: 1
- setExpectation :
    values :
    - 'USD'
    - 'JPY'
    - 'INR'
    - 'GBP'
    - 'CAN'
  column : currency_id
  ignoreNull : true
  dimension : VALIDITY
  threshold : 1
</code></pre>
<p>データが満たすべきルールを宣言的な形で記録できるのは大きな利点です。これによってそれぞれのカラムが満たすべき要求を把握することが簡単になります。また、Single Source of Truth となっているので、満たすべき要求を変えたい場合はこの YAML を変えるのみです。</p>
<h2>理由2：スコアリング</h2>
<p>自動データ品質のチェック結果には <code>0~100</code> のスコアが含まれています。これまではテストの成功か失敗しか把握できませんでしたが、ある程度の尺度で品質を評価できるようになりました。また、全体のスコアに加えて YAML で設定した dimension（評価軸）ごとのスコアも取得することができるため、評価軸ごとの品質評価も可能となります。</p>
<h2>理由3：シンプルな仕組み</h2>
<p>BigQuery のデータ品質を確認するツールは自動データ品質以外にもいくつかあります。dbt や dataform などがありますが、これらはデータ管理ツールの一種でテーブル自体をそれらのフレームワーク上で管理するのが一般的です。</p>
<p>その点、自動データ品質は BigQuery のデータ品質を確認する部分だけで利用できることができます。すでにある BigQuery のデータに対して変更を加える必要はありません。また、自分でインスタンス等のリソースを準備する必要もありません。これらは自動でデータ品質を採用した大きな理由です。</p>
<h2>理由4: BigQuery との親和性</h2>
<p>自動データ品質は BigQuery を前提に作成されているので BigQuery との親和性が非常に高いです。弊社は多くのデータを BigQuery で扱っているのでこの点はとても重要です。</p>
<p>具体的にはパーティションごとのインクリメンタルスキャンや、ネイティブテーブル以外にも多く対応しています。また、BigQuery の既存のテーブルをスキャンし、自動でそれを満たすようなルールを作成してくれるような便利な機能もあります。</p>
<h2>理由5：実行履歴の記録</h2>
<p>チェックの結果は Google Cloud コンソールから GUI で確認できます。それ以外にも結果を BigQuery のテーブルに保存することもでき、ほぼ永続的にデータ品質の推移を保持することが可能です。</p>
<p>また、前述したスコアリングに加え、カラムごとの細かいチェック記録も保存されているで、あとからカラムごとの品質推移を追うこともできます。</p>
<h1>アーキテクチャ</h1>
<p>ここからは構築したシステムのアーキテクチャについて説明します。</p>
<p>Dataplex の自動データ品質が持っているマネージドな機能をベースにして、プレイドの状況に合わせて補助的なアプリケーションを作成してシステムを構築しました。構築したアーキテクチャの全体像は次のとおりです。</p>
<p><img src="https://ik.imagekit.io/plaid/433c59d4-7c53-4e52-9607-299d0081a796/architecture.png" alt="architecture.png"></p>
<h2>スキャン実行アプリケーション</h2>
<p>自動データ品質を実行するためのアプリケーションは独自に実装しました。このアプリケーションは API を利用して自動データ品質を実行します。自動データ品質はマネージド機能なので実行アプリケーションを作らずとも利用することもできます。ただ、プレイドの状況に合わせるため、下記のような機能を実装して自動データ品質を補完していますました。</p>
<ul>
<li>複数のルールを指定可能にし、同時並行で実行できるようにした</li>
<li>日付を指定可能にして、日付シャーディングテーブルに対応した</li>
<li>リージョンを指定可能にして、同じルールを異なるリージョンでチェックできるようにした</li>
</ul>
<p>このように独自のアプリケーションを作ることで、自動データ品質の機能を補ってより柔軟なチェックが可能になりました。</p>
<h2>ルールの管理</h2>
<p>上述したようにテーブルの満たすべきの仕様は YAML ファイルとして定義しています。この YAML はスキャン実行アプリケーションのソースコードと同一の Git リポジトリでバージョン管理しています。こうすることであるべき仕様とルールの管理が一元的に管理できるようになっています。また、Git を利用するため変更履歴の確認が容易になっています。</p>
<h2>Google Kubernetes Engine で実行</h2>
<p>作成したスキャンアプリケーションは Docker Image としてビルドしたあと Google Kubernetes Engine で実行しています。Docker Image にはルールの YAML も含めて実行に必要な一式がすべて含まれているので再利用が容易になっています。通常、このアプリケーションを CronJob として実行することで定常的な品質チェックに利用しています。</p>
<p>現時点ではチェックアプリケーションは GKE で動作させていますが、Cloud Run などのよりマネージドな環境で動作させることも可能です。また、ルールの更新（コミット＆プッシュ）と、そのデプロイは分離されているため検証環境での検証も容易になっています。</p>
<p>プレイドでは GKE 上で使えるワークフローツールを利用してパイプラインを構築しています。作成したスキャンアプリケーションはこのパイプラインとも連携可能です。こうすることで特定のジョブワークフローの最後にスキャンを実行し、パイプライン実行の結果に対する品質をすぐにチェックすることもできます。</p>
<h2>モニタリングツール</h2>
<p>実行アプリケーションを独自に実行したことで、外部のモニタリングツールと連携することが可能です。プレイドでは横断的なモニタリングツールとして Datadog を用いています。Datadog にすべての結果を送ることは現実的ではないため、結果の一部をカスタムメトリクスとして送信してモニタリングに利用しています。</p>
<h1>成果</h1>
<h2>データ品質の導入</h2>
<p>既存のデータパイプラインを変更せずにデータ品質を観測するための仕組みを導入することができました。これに伴ってデータに対する要求を明確にし YAML 形式で表すことができました。評価軸がきちんと明確になったことでデータ品質に対する精度が高まりました。また、スコアリング値によって以前よりもより品質をより詳細に把握できるようになったことも大きな利点です。</p>
<h2>観測可能性の向上</h2>
<p>品質チェックを定常的で統一的に実行できるようになりました。スキャン結果は Google コンソールや Datadog 上で確認できるようになっています。このような定常的で統一した仕組みがあることでチームでの品質のコミュニケーションが円滑になっています。</p>
<p>また、データ品質の劣化を検知できるようになりました。その結果、問題が発生する前にアクションをとれるようになっています。実際にいくつかのテーブルで品質の劣化は検知することができアクションをとることができました。このように、間違いなく観測可能性が高まりました。</p>
<h2>スケーラブルな仕組み</h2>
<p>これまでばらばらだったデータのチェックの仕組みを統一的な仕組みに変更し、プロダクトの種類が増えた場合にも対応できるようなスケーラブルな仕組みになりました。統一された仕組みを活用することで、チェックの導入コストを大幅に削減し、チェックに一貫性が生まれています。新しい品質チェックの導入と運用の負荷を大幅に削減することができましたし、ルールを作るときは YAML ファイルを作るだけですむため開発者体験も向上しています。</p>
<h1>まとめ</h1>
<p>今回は Google Cloud Dataplex の自動データ品質を用いて、データ品質管理の仕組みを構築しました。Dataplex を活用することで既存のデータパイプラインに影響を与えることなく、アドインの形でデータ品質を測定し、品質改善の仕組みを整えることができました。この仕組みによって、データに対する一貫した品質チェックが可能となり、異常検知・品質の劣化への迅速な対応によって信頼性を向上させることができました。</p>
<p>今後もこうした取り組みをさらに加速させ、プレイドが提供するデータへの信頼を着実に高めるとともに、データによる価値を最大化するように取り組んでいきます。</p>


この記事では Google Cloud Dataplex の自動データ品質（Auto Data Quality）機能を使ったデータ品質向上の取り組みについてご紹介します。

Google Cloud Dataplex を使ったデータ品質の向上

Rollupのビルド時間を10倍高速化することでプレビュー表示を改善した話

プレイドインターン体験記：インターンを通じて得た技術力と開発力の学び

Engineer Blog

Recent Article