Engineer Blog

Kakemu Fujii

Kento Kaseda

Reo Hakuta

Erika Sakurai

erikasakurai

Takaharu Nakamura

Daichi Hachisuka

Louis Avondet

Sota Sato

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

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


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

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

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


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

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

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

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

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


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

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

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


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

BigQueryを題材にし、大規模なデータベースでの分散処理の仕組みについて紹介します。

BigQueryの分散処理の仕組みを深掘りする_プレイドエンジニアブログ

BigQueryの分散処理の仕組みを深掘りする

<p>こんにちは。プレイドで技術領域の広報などを担当しているmomoki (<a href="https://twitter.com/mmk__106">@mmk__106</a>)です。</p>
<p>プレイドは、2024年5月8日に開催された「<a href="https://gen-ai-conf.org/">生成AIカンファレンス2024</a>」にシルバースポンサーとして参加しました。今回は、当日のイベントの様子やプレイドとして行ったことを紹介します。</p>
<h1>イベントへの参加の経緯</h1>
<blockquote>
<p>生成AIカンファレンスは、この革新的な分野の専門家が集まる、国内最大規模の生成AIイベントの一つです。スタートアップのCEO/CTO、大手企業のリーダー、トップレベルの研究者たちが登壇し、最新の知見と経験を共有します。（<a href="https://gen-ai-conf.org/#:~:text=keyboard_arrow_right-,Concept,-%E7%94%9F%E6%88%90AI%E3%81%AF">生成AIカンファレンス2024 Webサイト</a>より）</p>
</blockquote>
<p>生成AIカンファレンス2024は、その名の通り生成AIの専門家や注力して取り組む企業・団体が参加するイベントです。プレイドにおいても、<a href="https://pdf.irpocket.com/C4165/RzLT/uAgQ/HejY.pdf#page=47">IR資料</a>で中長期成長に向けた主要な取り組みの一つとして「データ分析/活⽤に⼤規模⾔語モデル(LLM)などの新しいAI技術を本格活⽤」を掲げ、さまざまな取り組みを進めています。<br>
<img src="https://ik.imagekit.io/plaid/0b0eaedf-e21e-4d2f-b982-e3cf0b1ca3f4/plaid_ir_24-2_P47(1).png" alt="plaid_ir_24-2_P47(1).png"></p>
<p>ユーザーの行動データの分析と生成AIをかけ合わせて、セグメンテーションの⾼度化・⾃然⾔語によるラベルなどへの活用を進め、またプレイドグループで提供する各プロダクトにおける生成AIの機能的な活用も強化しています。そして、今後のさまざまな活動の加速・拡大に繋げるために、生成AIカンファレンス2024に参加することになりました。</p>
<h2>プレイドの生成AI活用の活動例</h2>
<h3>『生成AIによる次世代のユーザー行動解析』 : Google Cloud主催「Google Cloud Next Tokyo ’23」にて</h3>
<div class="iframely-embed" data-embedded-url="https://cloudonair.withgoogle.com/events/next-tokyo/watch?talk=d2-aiml-03"><div class="iframely-responsive" style="padding-bottom: 52.4126%; padding-top: 120px;"><a href="https://cloudonair.withgoogle.com/events/next-tokyo" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fcloudonair.withgoogle.com%2Fevents%2Fnext-tokyo%2Fwatch%3Ftalk%3Dd2-aiml-03&key=878c5bef402f0b2911bf6d4ce6261abd">Google Cloud Next Tokyo ’23</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h3>PaaSプロダクト「<a href="https://ecosystem.plaid.co.jp/product/karte-craft">KARTE Craft</a>」で作成する汎用プログラムの活用を支援してくれるAIアシスタント「Craft Functions Copilot」</h3>
<div class="iframely-embed" data-embedded-url="https://tech.plaid.co.jp/ms-ai-craft-functions-copilot"><div class="iframely-responsive" style="padding-bottom: 52.5%; padding-top: 120px;"><a href="https://tech.plaid.co.jp/ms-ai-craft-functions-copilot" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Ftech.plaid.co.jp%2Fms-ai-craft-functions-copilot&key=878c5bef402f0b2911bf6d4ce6261abd">Microsoft の AI 技術 をベースに構成される Craft Functions Copilot</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h3>『RightTouchのLLM活用のこれまでとこれから』</h3>
<div class="iframely-embed" data-embedded-url="https://blog.righttouch.co.jp/llm"><div class="iframely-responsive" style="padding-bottom: 52.3%; padding-top: 120px;"><a href="https://blog.righttouch.co.jp/llm" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fblog.righttouch.co.jp%2Fllm&key=878c5bef402f0b2911bf6d4ce6261abd">RightTouchのLLM活用のこれまでとこれから</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h1>当日のイベントの様子</h1>
<p>当日は、パネルディスカッションへの登壇とブース出展を行いました。</p>
<h2>パネルディスカッション「日本の生成AIをリードする企業に学ぶ、革新的アプリケーションの創造」</h2>
<p>プレイドからはCTOの牧野 <a href="https://twitter.com/makinoy">@makinoy</a> が参加し、<a href="https://algomatic.jp/">Algomatic</a>の南里 <a href="https://twitter.com/neonankiti">@neonankiti</a> さん・<a href="https://www.ai-shift.co.jp/">AI Shift</a> の青野 <a href="https://twitter.com/brn227">@brn227</a> さんとともに、生成AIカンファレンス運営代表の南野 <a href="https://twitter.com/tentenmitsunori">@tentenmitsunori</a> さんにファシリテートいただきました。LLMを使って世の中にどのように価値を届けていくかについて、「競合との差別化ポイントの作り方」「基盤モデルとの向き合い方」「開発するアプリケーションの決め方」という3つのお題に沿って、プレイドや牧野が考えていることをお話ししました。</p>
<p>参加チケットを購入されている方は、期間限定でアーカイブ動画が視聴できるので、ご参加頂いた方も見逃した方も、改めてぜひご覧ください。</p>
<p><img src="https://ik.imagekit.io/plaid/fdf832ec-69e1-45d7-8e42-ad0b24d17e75/%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%882024-05-1116.01.57.png" alt="スクリーンショット2024-05-1116.01.57.png"></p>
<h2>ブース : 開発中の生成AIを活用したプロダクトデモ紹介</h2>
<p>ブースでは、現在開発中の生成AIを活用したプロダクトデモを複数紹介していました。</p>
<h3>1. Craft Functions Copilot (β版)</h3>
<p>Craft Functions Copilot (β版) は、AIによるプロダクト活用支援機能です。KARTE Craftの使い方や機能開発に関する質問を行うと、その回答やコードの改善提案がリアルタイムで行われます。<br>
<img src="https://ik.imagekit.io/plaid/6de7966d-cb87-4f47-ab5d-a05aacbc6802/s-1280x720_c546f5ab-3a81-47b7-b3bf-3fc04f6defd3.gif" alt="s-1280x720_c546f5ab-3a81-47b7-b3bf-3fc04f6defd3.gif"></p>
<h3>2. RightSupport by KARTEにおける<strong>サポートシナリオの自動生成</strong></h3>
<p>ユーザーのWeb行動から蓄積された統計情報をもとに、特定のページでユーザーに提示すべきFAQ選択肢や、そこに誘導するためのヒアリング項目をLLMを用いて自動生成します。<br>
<img src="https://ik.imagekit.io/plaid/7704dbb6-5f36-4abe-855b-b8a72054ebf5/%E3%82%B7%E3%83%8A%E3%83%AA%E3%82%AA%E8%87%AA%E5%8B%95%E7%94%9F%E6%88%90%E7%B0%A1%E6%98%93%E7%89%88002.gif" alt="シナリオ自動生成簡易版002.gif"></p>
<h3>3. 商品閲覧履歴からセッション要約</h3>
<p>ユーザーの商品閲覧履歴からユーザーのそのセッションでの行動を要約したり、そのユーザーに対しての施策アイデアを提供します。<br>
<img src="https://ik.imagekit.io/plaid/6b5b3403-e882-4c04-8a15-6dd90539779c/%E7%94%BB%E9%9D%A2%E5%8F%8E%E9%8C%B2-2024-05-07-21.54.54(1).gif" alt="画面収録-2024-05-07-21.54.54(1).gif"></p>
<h2>ブース運営の工夫</h2>
<p>また、ブース出展においては、イベントに参加されている方に興味持っていただき立ち寄っていただけるような工夫を行いました。<br>
<img src="https://ik.imagekit.io/plaid/0b434906-1342-4729-be95-eaf9d971c6ba/Untitled.jpeg" alt="Untitled.jpeg"><br>
まずは端的に「デモを展示していること」がわかりやすく伝えるために、わかりやすく「生成AIデモ展示中！」と書いたパネルを社内のデザイナーに作成してもらいました。</p>
<p>立ち寄っていただく人が同時に複数いることも想定し、ディスプレイを2台持ち込むことは決めていたので、残りのスペースを最大限活用できる、かつ目立たせられるように、サイズ調整の提案をもらって変形A1サイズで作成しました。<br>
<img src="https://ik.imagekit.io/plaid/65b51dd7-6eda-46a5-8cb8-ed16ad07e20e/Layout.png" alt="Layout.png"><br>
ブースに立ち寄ってくれた方には、今回のために作成したオリジナルキャンディーと、プレイドグループの生成AI関連の除法を集めた<a href="https://recruit.plaid.co.jp/gen-ai-conf-2024">特設ページ</a>のQRコードが入ったカード、ステッカーなどを配布しました。いろいろとアイテムがあることで、イベント参加者の方々と話すきっかけがつくりやすく、とても重宝しました。</p>
<p>カードに記載した「Context Is All We Need.」というメッセージは、『<a href="https://arxiv.org/abs/1706.03762">Attention Is All You Need</a>』をオマージュしてCTOの牧野が考案したものです。立ち寄っていただいた方をはじめ、社内外の評判がとても良かったので、今後プレイドのAI関連のあれこれに使用していくかもしれません。</p>
<p>オリジナルキャンディーはマーケティングチームのノベルティ制作に知見があるメンバーとデザイナーにアイデアを出してもらい、<a href="https://candy-showtime.com/order/">CANDY SHOW TIME</a>さんに制作を依頼しました。見た目の区別はつきませんが、実は1つの袋に2つの味（フレーバー）の飴が入っています。制作段階で2種類選べたので、Apple味とIchigo味を指定したのですが、そのことを完全に忘れたまま、ブースに立つメンバーにも来場された方にも伝えることなくイベントが終わってしまいました。今後どこかの機会で見かけた際には、プレイドのAIキャンディーとして受け取ってください。<br>
<img src="https://ik.imagekit.io/plaid/5fa09b3b-4a4b-4ca7-bb94-95763bd8fcb5/Untitled(1).jpeg" alt="Untitled(1).jpeg"></p>
<p>今回のイベントでは、セッションが行われるメインホール（1箇所）に隣接する形でブースエリアが設けられており、セッション間の5~10分の休憩時間を中心に立ち寄る方が多くいました。ブースを10箇所まわるとプチギフトがもらえる企画が行われていたり、ブースエリアでフリードリンク配布が行われていたり、来場者がブースに立ち寄りやすくなる仕掛けがされていて、とてもありがたかったです。</p>
<p>そのような企画と、ご来場された方々のモチベーション・興味が高かったこと、プレイドメンバーの熱烈な呼び込み、デモを用意・訴求した甲斐もあり、本当にたくさんの方々にブースにお立ち寄りいただけました。「デモ見てみたいです」とお声掛けいただくことも多く、対応したメンバーの話を聞いて「今まで見たデモで一番おもしろかったです」「（学生なんですが）自分の研究がどう社会に活きるのか、少しイメージが湧きました」など言ってくれる方もいて、参加したメンバーやプレイドにとって良い機会にすることができました。</p>
<blockquote class="twitter-tweet"><p lang="ja" dir="ltr"><a href="https://twitter.com/hashtag/gen_ai_conf?src=hash&amp;ref_src=twsrc%5Etfw">#gen_ai_conf</a> 企業ブースではスタンプラリーを実施し、10このブースを回った方にはオリジナルチロルチョコを景品として配布しておりました🍫✨<br><br>いち早くGetされた方々、おめでとうございます🙌 <a href="https://t.co/IfNxPRYnTu">pic.twitter.com/IfNxPRYnTu</a></p>&mdash; 生成AI Conf実行委員会 (@gen_ai_conf) <a href="https://twitter.com/gen_ai_conf/status/1788110926694281322?ref_src=twsrc%5Etfw">May 8, 2024</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<h1>おわりに</h1>
<p>生成AIカンファレンスにご来場いただいた皆さん、セッションを視聴いただいた皆さん、本当にありがとうございました。</p>
<p>そして、イベントの企画・運営をしていただいた皆さん、素晴らしいイベントに関与させていただきありがとうございました。準備段階の相談・質問にも丁寧に対応していただいたおかげもあり、スムーズに準備・参加することができました。何よりも会場全体が熱気溢れていて、スポンサーという立場に限らず楽しく刺激あるイベントで最高でした。</p>
<p>今後もプレイドでは生成AI技術をはじめ、さまざまな領域・シーンで存在感を強めていけるように、面白い開発や企画に取り組んでいきます。Xアカウント (<a href="https://twitter.com/PLAID_Tech">@PLAID_Tech</a>)などで情報発信していきますので、ぜひフォローをお願いします。<br>
<img src="https://ik.imagekit.io/plaid/cc787854-1af3-44a8-8c8c-06727820ea92/Untitled(2).jpeg" alt="Untitled(2).jpeg"></p>
<h2>関連リンク（活動例の続き）</h2>
<h3>『AI時代に人は制約から解き放たれる。その先にある社会像と企業像』</h3>
<div class="iframely-embed" data-embedded-url="https://dhbr.diamond.jp/articles/-/10441"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://dhbr.diamond.jp/articles/-/10441" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fdhbr.diamond.jp%2Farticles%2F-%2F10441&key=878c5bef402f0b2911bf6d4ce6261abd">AI時代に人は制約から解き放たれる。その先にある社会像と企業像 | テクノロジー｜DIAMOND ハーバード・ビジネス・レビュー</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h3>『効率競争から価値競争の時代へ、人のポテンシャルを解放するAI実装のあり方』</h3>
<div class="iframely-embed" data-embedded-url="https://dhbr.diamond.jp/articles/-/10443"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://dhbr.diamond.jp/articles/-/10443" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fdhbr.diamond.jp%2Farticles%2F-%2F10443&key=878c5bef402f0b2911bf6d4ce6261abd">効率競争から価値競争の時代へ、人のポテンシャルを解放するAI実装のあり方 | A New Era of CX｜DIAMOND ハーバード・ビジネス・レビュー</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h3>『KARTE CraftにおけるLLM活用~Craft Functions Copilot~』 : 「Microsoftと語る LLM実装の最前線」にて</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="KARTE CraftにおけるLLM活用~Craft Functions Copilot~" src="https://speakerdeck.com/player/d9f4d037b34044e4b688034987891ad2" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h3>『生成AIによるカスタマーサポート変革：ウェブチャットの業務生産性 &amp; CX向上』 : Google Cloud主催 「Generative AI Summit Tokyo '24」にて</h3>
<div class="iframely-embed" data-embedded-url="https://cloudonair.withgoogle.com/events/generative-ai-summit-24q1?talk=24-t1-session4"><div class="iframely-responsive" style="padding-bottom: 52.5%; padding-top: 120px;"><a href="https://cloudonair.withgoogle.com/events/generative-ai-summit-24q1" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fcloudonair.withgoogle.com%2Fevents%2Fgenerative-ai-summit-24q1%3Ftalk%3D24-t1-session4&key=878c5bef402f0b2911bf6d4ce6261abd">Generative AI Summit Tokyo &#39;24：生成 AI の「体験」から「活用」へ！</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h3>エモーションテックのテキストAI分析サービス「TopicScan︎®︎」</h3>
<div class="iframely-embed" data-embedded-url="https://emotion-tech.co.jp/topicscan/"><div class="iframely-responsive" style="padding-bottom: 52.5%; padding-top: 120px;"><a href="https://emotion-tech.co.jp/topicscan/" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Femotion-tech.co.jp%2Ftopicscan%2F&key=878c5bef402f0b2911bf6d4ce6261abd">TopicScan – テキストAI分析サービス ｜ 株式会社エモーションテック</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

プレイドは、2024年5月8日に開催された「[生成AIカンファレンス2024](https://gen-ai-conf.org/)」にシルバースポンサーとして参加しました。今回は、当日のイベントの様子やプレイドとして行ったことを紹介します。

生成AIカンファレンス2024 参加レポート_プレイドエンジニアブログ

生成AIカンファレンス2024 参加レポート

<h1>はじめに</h1>
<p>こんにちは。<a href="https://twitter.com/calloc134">calloc134</a> といいます。<br>
情報工学系の学生で、普段は Web アプリケーション開発について学習しています。</p>
<p>今回、2024年2月から3月の5週間、プレイドでソフトウェアエンジニアとしてインターンシップを行いました。<br>
この記事では、インターンシップの振り返りとともに、学んだことや感じたことをまとめていきたいと思います。</p>
<h1>インターンシップ開始まで</h1>
<p>当インターンシップは、知り合いから紹介をいただいたことがきっかけで始まりました。<br>
自分は今までインターンシップを経験したことがなく、実務経験もありませんでした。<br>
プレイドのインターンでは、任される開発業務に必要な範囲で、社員さんと同じ環境・同じシステムに対して開発・コーディングを行うことができるという特徴がありました。<br>
この特徴は、実際の開発現場でどのように開発が進められているかを知りたい自分にとって、非常に魅力的でした。<br>
そのほか、技術領域が自分の普段の学習と近いことや、エンジニアインターンではフルリモートでも勤務でき、都心住みでない自分でも働きやすいことなどが決め手となりました。</p>
<p>インターン開始前にカジュアル面談を行い、簡単な技術スタックと業務内容について説明を受けました。<br>
プレイドでは、担当するプロダクトによって開発チームが分割されています。<br>
自分はMessageチームに入ることになったので、そのチームでの業務内容について説明を受けました。</p>
<p>Message チームは <a href="https://karte.io/package/message/">KARTE Message</a> というプロダクトを開発しています。<br>
当プロダクトは、データを元にメールやプッシュ配信、LINE メッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<h1>技術スタック</h1>
<p>Message チームの技術スタックについては、同じ Message チームの方が書かれた<a href="https://tech.plaid.co.jp/intern-at-plaid-yurihttps://tech.plaid.co.jp/intern-at-plaid-kenshin">こちら</a>のブログ記事が参考になると思います。</p>
<p>簡単に解説すると、下記のような技術スタックになっています。</p>
<ul>
<li>フロントエンド
<ul>
<li>Vue(メイン)</li>
<li>React (一部メニュー)</li>
</ul>
</li>
<li>バックエンド
<ul>
<li>サーバサイド Node.js / Express.js</li>
<li>Golang</li>
<li>Java</li>
</ul>
</li>
<li>インフラ
<ul>
<li>MongoDB (データベース)</li>
<li>Redis</li>
<li>Cloud Pub/Sub</li>
<li>GKE (Google Kubernetes Engine)
<ul>
<li>ArgoCD (デプロイ)</li>
</ul>
</li>
</ul>
</li>
<li>DevOps
<ul>
<li>GitHub Actions</li>
<li>CircleCI</li>
</ul>
</li>
<li>監視
<ul>
<li>Sentry</li>
<li>Datadog</li>
</ul>
</li>
</ul>
<p>また、開発については、下記の技術を使用していました。</p>
<ul>
<li>Git/ GitHub (コード管理)</li>
<li>Docker Compose (開発環境)</li>
<li>Kind (Kubernetes in Docker)</li>
</ul>
<p>自分にとって、このインターンが初めてのエンジニアとしての実務経験となります。<br>
そのため、技術レベルも含めて最初はインターンで活躍できるかすごく不安でした。</p>
<h1>インターンの内容</h1>
<h2>最初の二日間</h2>
<p>インターン開始してすぐの二日間は、自分の開発環境を整えることから始まりました。</p>
<p>まず開発環境セットアップの資料を確認してインストールを行ったのですが、リポジトリの更新や仕様の変更により、資料と異なる部分がありました。また、資料に存在しないような issue に遭遇することがしばしば起こりました。</p>
<p>そこでSlack に開発環境構築専用のチャンネルが存在したため、そこにスレッドを立てて技術チームに質問を行いながら、一つずつ課題を解決していきました。<br>
フルリモートで意思疎通が難しくなるかもと心配していましたが、チームメンバーの皆さんが迅速に対応してくれたため、スムーズに進めることができました。<br>
また、解決した課題は、times と呼ばれる自分専用のメモ書きチャンネルにまとめていくことで、後から振り返りが容易になるようにしました。</p>
<p>一通り開発環境の構築が完了した後、開発環境構築の手引きとして社内ドキュメントを執筆しました。新しく入ったインターン生が同じような問題に遭遇した際に、自分の経験が役立つことを願っています。</p>
<h2>タスク</h2>
<p>開発環境の構築が完了した後、実際に開発に取り組むことになりました。</p>
<p>5週間という比較短い期間の中でもさまざまなタスクに着手してきましたが、ここでは一番印象に残ったタスクをピックアップし、振り返りたいと思います。</p>
<h3>LINEコンテンツのサムネイル生成機能</h3>
<p>KARTE Messageでは、メール、プッシュ配信、またはLINEを用いてユーザにコンテンツを送信することができます。</p>
<p>コンテンツの保存時に自動的にコンテンツのサムネイル画像を生成し、プレビューすることができる機能が存在するのですが、この機能が実装されているのはメール配信とプッシュ配信のみであり、LINE には実装されていませんでした。</p>
<p>そこで、LINEコンテンツのサムネイル画像を生成する機能を実装することになりました。</p>
<p><img src="https://ik.imagekit.io/plaid/f65747e2-4ff0-4320-ac33-48a8f6cd8c5e/Untitled(1).png" alt="Untitled(1).png"></p>
<p>タスクに取り組むにあたり、はじめに現状のサムネイル生成機能を理解するところから始めました。</p>
<p>まず管理画面上でコンテンツが保存されたタイミングでpubsubのキューにHTML と CSS の情報がメッセージとして登録されます。<br>
サムネイル生成用サービスがそのメッセージをsubscribeしており、メッセージの内容からサムネイル画像を生成する、というシンプルな構成でした。<br>
具体的には、メッセージから取り出した HTML と CSS の情報をpuppeteerでレンダリングし、レンダリング結果のスクリーンショットを生成、S3のsignedURLを用いてS3に保存します。</p>
<p><img src="https://ik.imagekit.io/plaid/b7ded338-bbcd-49b9-a48e-b50fa26298fd/Untitled(2).png" alt="Untitled(2).png"></p>
<p>ではLINEコンテンツのサムネイル生成機能を実装するためにはどのような実装が必要なのでしょうか。</p>
<p>現状の構成では、サムネイル生成用サービスのインターフェースはHTMLとCSSとなっています。</p>
<p>一方で、管理画面で表示しているコンテンツのプレビューはReactやTailwind CSSといったフレームワークを用いて描画しているため、ここからなんとかして等価のHTMLやCSSを生成する必要があります。<br>
あるいは、サムネイル生成用サービスを改修し、Reactコンポーネントを描画する方法もとりえます。<br>
<img src="https://ik.imagekit.io/plaid/3e8f31ec-5a52-4e93-9deb-30b69085fbf7/Untitled(3).png" alt="Untitled(3).png"></p>
<p>上記に加え、さらにいくつか設計の選択肢をリストアップし、メリットとデメリットを比較してみました。<br>
<img src="https://ik.imagekit.io/plaid/4edc16e3-5bc3-45fc-85d7-a02d22801e60/Untitled(4).png" alt="Untitled(4).png"></p>
<p>まず、一番目と二番目の選択肢は実装が難しいと感じたため、採用を見送りました。</p>
<p>そこで三番目の選択肢で実装を進めていましたが、画像がロード中の表示のままサムネイル生成されてしまう可能性があるという問題が発生しました。</p>
<p>これはサーバサイドでのReactコンポーネントのレンダリングの場合、画像の描画に時間がかかってしまうことが原因でした。<br>
従って、最終的に四番目の解決策である、クライアント側の React コンポーネントの HTML を取得してレンダリングする方法を採用しました。</p>
<p>クライアントサイドにおいて、React Componentの描画結果のHTMLはuseRefを利用することで簡単に取得できました。</p>
<pre><code class="language-tsx"> 	const previewHTMLRef = useRef&lt;HTMLDivElement&gt;(null);
 	const previewHTML = previewHTMLRef.current?.innerHTML

  return (
    &lt;&gt;
      &lt;LineEditorPreview controller={controller} previewHTMLRef={previewHTMLRef} /&gt;
    &lt;&gt;
  )
</code></pre>
<p>またスタイリングにはTailwindCSSを用いていたため、プレビューのコンポーネントで適用されているTailWindCSSのクラスをあらかじめビルドしておけば、プレビューに使われているCSS を生成することができます。</p>
<p>TailwindCSS は CLI での呼び出しに対応しており、構成ファイルを指定して手動コンパイルを行いました。</p>
<p>今回は、LINE プレビューに関連するコンポーネントを全て指定した構成ファイルを作成し、TailwindCSS CLI でビルドを行うことで、CSS を生成しました。</p>
<pre><code class="language-tsx">// 構成ファイル

/** @type {import('tailwindcss').Config} */
module.exports = {
  presets: [require('@plaidev/sour-react/tailwind')],
  content: [
    './src/page/template-edit/line-editor/preview.util.tsx',
    './src/page/template-edit/line-editor/preview.tsx',
  ],
  variants: {
    extend: {},
    animation: [],
  },
};
</code></pre>
<pre><code class="language-bash"># TailwindCSS CLI
tailwind -o path/of/output -c path/to/config -m
</code></pre>
<p>最終的にあらかじめ生成しておいたCSSをサーバー側で保持しておき、クライアントサイドから送られてくるHTML情報と合わせてpubsubに登録することで、LINE コンテンツのサムネイル画像を生成することができました。</p>
<p><img src="https://ik.imagekit.io/plaid/ec4733fa-d507-427b-bf8d-1bdd8cbdb5be/Untitled(5).png" alt="Untitled(5).png"></p>
<h1>インターンを振り返って</h1>
<p>社員さんと同じ環境で開発を行っていくことで、自分の中における仕事に対する解像度が上がったと感じています。<br>
これまでは個人的な開発しかしてこなかったため、自身のスキルが社会に出てから実際に活かすことができるのか不安でした。<br>
しかしプレイドのインターンシップを通じて、今まで学習してきたスキルが仕事に活かせることを実感し、また必要なスキルをどのように向上させていけばよいのかを学ぶことができました。</p>
<h2>インターンから得た学び</h2>
<h3>コーディングについての学び</h3>
<p>一例としては、コードの可読性やコメントの重要性を学びました。<br>
これまでの開発では自分がわかりやすいようなコメントや変数名を付けることが多かったのですが、プレイドではロジックの背景を意識したコメントや変数名を付けることが求められ、普段の開発でもこれらの意識を持って開発を行うようになりました。</p>
<h3>ロジックの理解</h3>
<p>また、ロジックを理解する大切さについても学習しました。<br>
挙げられた issue に関して場当たり的な修正は簡単に見えても、その根本的な原因は別のところにあることが多く、ロジックを含めて全体を理解することが重要であると感じました。</p>
<h3>issueの理解</h3>
<p>タスクの内容を深く理解することも重要です。</p>
<p>タスクは基本的に ~ ができない　のような課題形式で書かれているのですが、その解決には様々な方法が考えられます。その中でもどういった仕様が良いのかを正しく導くためには、既存ロジックの理解に加え、ドメインや顧客の理解も非常に重要となってきます。<br>
プレイドでは仕様に関するディスカッションも頻繁に行われるため、こういった能力も養うことができました。<br>
コーディングならAIでもできるようになってきている時代において、仕様設計はますます重要になると考えており、今後も磨いていきたいと思っています。</p>
<h1>インターンの特徴</h1>
<p>プレイドのインターンの特徴を以下にまとめました。</p>
<ul>
<li>実際のエンジニアと同じチームでプロダクト開発を行う</li>
<li>社員と同じ一連の開発フロー(issue アサインと方針の整理、修正とデプロイ、動作確認まで)</li>
<li>技術力に応じてコア開発に近いタスクへのアサインも可能</li>
</ul>
<h2>こんな人におすすめ</h2>
<ul>
<li>実際の開発現場で、開発のサイクルを学びたい</li>
<li>技術力を向上させたい・フルスタックで活躍したい</li>
<li>課題解決力の向上・設計・実装・運用までの幅広い業務経験を積みたい</li>
</ul>
<h1>まとめ</h1>
<p>自分にとって初めてのインターンでしたが、実際の開発を通して色々なことを指導していただき、無事やり遂げることができました。<br>
お世話になった社員さん、インターン生の皆さん、本当にありがとうございました。<br>
今後もこの経験を活かして、さらに活躍できるようなエンジニアを目指していきたいと思います。</p>
<p>プレイドの開発インターンに興味のある方はぜひ下記から応募してみてください。</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

プレイドインターン体験記: はじめての開発インターンを通じて得た学び

Microsoft の AI 技術 をベースに構成される Craft Functions Copilot の仕組みとその中で利用されている Azure サービスの役割について説明します。

Microsoft の AI 技術 をベースに構成される Craft Functions Copilot

<p>こんにちは、エンジニアの白木です。</p>
<p>2023年4月 - 2024年2月までインターンとして開発に携わりました。</p>
<h2>自己紹介</h2>
<p>分散システム、データベースについて勉強しています。<br>
最近は、NewSQL、MPPデータベース、io_uring に最適化したデータベースの勉強をしています。</p>
<h2>プレイドのインターンに参加した理由</h2>
<p>プレイドの存在を知ったきっかけは<a href="https://bootjp.me/2023/independence_for_next/">ブログ記事</a>で、そこで大規模な分散システムを開発・運用していることを知りました。<br>
今まで分散システムを プロダクトに応用している例を身近で見たことがなかったため、 CX （Customer Experience）プラットフォームである KARTE を提供しているプレイドに興味を持ちました。そのような中、プレイドがインターン募集をしているを知り、是非参加したいと思い応募しました。</p>
<h2>インターンに入る前の前提知識の話</h2>
<p>インターンに入る以前は データ処理に関する知識は深く持っていませんでした。<br>
大規模データにおける分散処理フレームワークの Apache Hadoop、Apache Spark を用いたデータ処理について少しだけ知っていました。そのため、バッチ処理、ストリーム処理に関する 何となくのイメージがついていました。ただ、データ解析基盤を手を動かして作った経験はなく、どういったアーキテクチャで実装しているかのイメージが全くついていませんでした。<br>
データベースに関しては、MySQL、PostgreSQL などのOLTP(Online Transaction Processing) の処理向けのデータベースについては知識はありましたが、BigQueryのようなDWH (Data Warehouse) や OLAP（Online Analytical Processing) 向けのデータベースの知識は持っていませんでした。<br>
そのため、大規模データを処理するためにどのようなアーキテクチャで構築しているのか、大規模な解析用途で使われている データベースを扱えることが非常に楽しみにして参加しました。</p>
<h2>インターンで開発した内容の話</h2>
<p>インターン開発タスクの一つとして、KARTEのリアルタイム解析基盤に関わるAPIの改善を行いました。具体的にいうと、ユーザーの行動解析結果を取得するAPIが常に最新情報を返すようにするというものです。リアルタイム解析基盤の詳細については以下記事を参考にしてください。</p>
<ul>
<li><a href="https://tech.plaid.co.jp/blits_pre_aggregation">Blitz（前編）: 自由度と即時更新性を担保したAggregation</a></li>
<li><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析</a></li>
</ul>
<p>タスクの説明を受けた際に、該当のAPIについて「強整合性モード」を実現したいという話を聞き、「結果整合性」、「強整合性」という概念を正しく理解するところから始めました。<br>
結果整合性では、データ読み込み時に最終的に全ての更新が反映されることを保証するものの、即時ではないため古いデータを返す可能性があります。強整合性においては、データ読み込み時に全ての更新が反映されたデータが返ってくることを保証します。<br>
今までビッグデータの処理の文脈で見る BASE特性、また、Apache Cassandra が採用している整合性モデルであることから概念自体は理解できました。しかし、どう実装するかについてイメージができていませんでした。<br>
最初はリアルタイム解析基盤の実装部分やインフラの構成図を元にどう実装するかを考えようとしましたが、どう実装するかのイメージはつかないばかりでした。そこでリアルタイム解析基盤の概略について書かれた<a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">こちらの記事</a>を読み直し、大枠のロジックの理解に努めました。</p>
<p><img src="https://ik.imagekit.io/plaid/e52a44f2-f17c-467e-86c4-71e04bdbaeb4/Untitled.png" alt="Untitled.png"><br>
<em>Blitz の強整合を実現している図</em></p>
<p>結果、この図に強整合を実現するロジックが詰め込まれていることが理解できました。Realtime Queue にイベントを書き込んでおき、 Backend Servers で まだユーザーデータに反映されていないイベントを動的に遡求していくことで常に最新のデータを読み込めるという強整合性を実現していました。このアーキテクチャは今まで自分では想像ができなかった部分だったので、すごい仕組みだなと興奮しました。<br>
一度コンセプトを理解してしまえば、APIの実装部分も未反映のイベントを Realtime Queue から取得をして動的にユーザーデータを最新化すればいいという実装イメージが湧き、強整合性モードの実現も無事行うことができました。</p>
<h2>インターンで開発してみて得られた知見・経験</h2>
<h3>分散システムを用いた設計についての知見を得られた</h3>
<p>KARTE では秒間最大 13万4千イベント、月間 180PB を超える解析を行なっています。それを支えるプレイド独自のリアルタイム解析基盤は大規模な分散システムであり、アーキテクチャ上の工夫が随所に見られます。<br>
例を挙げると、リアルタイム解析で結果を同期的に配信するレイテンシー重視な処理と裏側でデータを溜めて一気に更新するスループット重視な処理を完全に分けて考えている点です。ここまで大規模かつシビアなパフォーマンスが求めれる環境だと、目的別にコンポーネントを分離することで、コスト最適化や柔軟なスケーラビリティが可能になっているなと感じました。<br>
分散システムを本で学習していても設計意図を肌で理解できず、中々身につかないなと思っていました。今回、インターンで実務を通じて分散システムに携わることでプロダクトと分散システムが結び付き、理解が深まりました。また、分散システムを通じて価値提供できる面白さを感じることができました。</p>
<h3>プロダクト・ビジネスへの貢献を意識した開発ができる</h3>
<p>プレイドのエンジニアは、技術的にかなり尖っています。しかし、技術だけを見ているだけでなく、プロダクト・ビジネスにも強くフォーカスしています。そのため、日々のタスクに関してもどのようにすれば最もプロダクト・ビジネスに貢献できるかを強く意識しています。例えば、単にプログラムを修正してタスクを完了するのではなく、将来的にどういった構想になっていれば良いかを意識してタスクに取り組んでいます。これによって、アーキテクチャの複雑度を下げています。ただ単にタスクを素早く終わらせる簡単な方法を取るだけでなく、将来までを意識して必要なコストは割いているのは、今後エンジニアとして働く上で学ぶべきことがありました。</p>
<h3>現場のエンジニア・ビジネスの方とディスカッションできる</h3>
<p>プレイドのインターンでは社員と同様の裁量を与えられてタスクに取り組めます。そのため、タスクに関しても現場の社員と同様にディスカッションできます。ディスカッションをすることでプレイドの社員の方の考えが分かり、タスクを進めるにあたりどういったことを意識すればいいのかを知れます。例えば、将来的に見ると価値は高いが直近だと賛否両論が生まれる機能をリリースする攻めの手を打つか、そういった手は打たず保守的な実装をするべきかについて、トレードオフを意識してタスクに取り組むことの重要性、締め切りが迫っている場合にどういったマインドでタスクに取り組むべきかなど、今後のエンジニア人生で大事なことをディスカッションを通じて学べました。</p>
<h3>仕事にやりがいを持っている社員と働ける</h3>
<p>プレイドの社員の方は仕事にやりがいを持っています。社員の方とお昼を一緒にしていると、どの方も楽しそうに仕事に関する話をします。楽しそうにやっている方、事業を本気で成長させようとしている方々と働ける経験は大事です。自分もこのように仕事に対してやりがいを持って働けるようになりたいと思えるようになりました。</p>
<h3>目的達成のためならばどのような技術でも扱う</h3>
<p>手を動かす Web エンジニアは大きく「フロントエンド」、「バックエンド」、「インフラ」などに分かれているところが多いと思います。プレイドでは、プロダクト・ビジネスにインパクトを与えるためならば、エンジニアはこれらの役割に囚われません。どのような領域の技術であっても役割に依らずタスクに取り組みます。役割に囚われずに 貢献していく姿勢は、人にタスクを依頼するコストを減らすことができ、高い生産性を出す上で大事だと感じました。このマインドは私も今後も続けていきたいです。また、どのような技術でも扱うため技術的な刺激を受ける機会がたくさんあります。自身も成長できる素晴らしい環境でインターンできました。</p>
<h2>最後に</h2>
<p>インターンを通じて、分散システムなどの技術的な成長を得られただけでなく、タスクを進めるにあたって考えるべきこと、エンジニアとしてのマインド、モチベーション高く働ける環境への解像度が高くなりました。</p>
<p>プレイドのインターンではエンジニアとして大きく成長できると思います。<br>
興味のある方は下記から応募してみてください！</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び

<p>株式会社プレイドのCore Platformチームに所属しているBrownです。今回のブログでは2022年頃より使用可能になった、BigQueryのAnalytics Hubを用いた、安全なデータ共有の導入について紹介します。</p>
<h1>前提となるプレイド社内でのデータの管理方法</h1>
<p>プレイドでは、CXプラットフォーム「<a href="https://karte.io/">KARTE</a>」の計測タグ経由で収集したイベントデータを元にWeb上のユーザーの行動を分析するサービスに加え、クライアント企業が社内外に保有する多種かつ大量なデータをKARTEに統合・連携して利活用できる<a href="https://karte.io/feature/integration/">KARTE Datahub</a>（以下、Datahub）を提供しています。<br>
KARTEの内外に散らばったサイロ化されたデータをDatahubに集約して、KARTEのプロダクトの中でユーザーのセグメントに活用したり、WidgetやKARTE内のアクション機能から参照したりすることができます。<br>
<img src="https://ik.imagekit.io/plaid/46c800d9-dd3d-4ff1-a605-a2cd7272ace9/datahub_case01_image-1.webp" alt="datahub_case01_image-1.webp"><br>
<em><a href="https://cxclip.karte.io/casestudy/tips/datahub_case01/">「KARTE Datahubに蓄積した様々なデータを活用する｜KARTE Datahub事例集 vol.1</a>」より引用</em></p>
<p>Datahubでは、KARTEに関わらず様々なデータの統合・利活用するプラットフォームであるため、他のKARTEのProductとデータの取り扱いを区別する必要があります。</p>
<h1>プレイドでのデータ共有</h1>
<p>データへのアクセスの安全性を高めるために、Datahub以外のKARTEのプロダクトから、クライアント企業の許諾なく直接Datahubに連携されたデータを参照することはできません。<br>
そのため、クライアント企業から許諾を受けたデータのみを、Datahub以外のプロダクト側に共有することで、イベントデータと組み合わせて使用したり、加工済みデータを生成しています。</p>
<p>また、データ連携の際に使用するBigQueryのDataset（以下、Dataset）やGCPのサービスアカウント（以下、SA）はクライアント企業ごとに分離されており、例えば、企業AのSAではその企業AのDatasetのみが操作でき、それ以外のクライアント企業のDatasetへの権限は一切持ちません。</p>
<h1>従来のDatasetの共有方法の問題点</h1>
<p><img src="https://ik.imagekit.io/plaid/26051d0a-c445-4260-90ff-0c084d3f9bfc/image1.png" alt="image1.png"></p>
<p>従来の仕組みでは、クライアント企業がDatahubを通じてKARTEにインポートしたデータを、Datahub以外のプロダクトから利用する場合には、KARTE Data LayerのSAがDatahub Data Layerに直接アクセスできないため、そのDatasetのデータを含めてKARTE Data Layerにコピーする必要がありました。<br>
この方法では、明示的に必要なDatasetだけをKARTE Data Layerに共有できる反面、以下の二点の問題があります。</p>
<ul>
<li>KARTE Data Layerにコピーされた後のDatasetへのアクセス権限を持つSAの管理・監視が煩雑</li>
<li>Origin DatasetからShared Datasetへ定期的にデータをコピーする必要がある</li>
<li>Origin Dataset・Shared Dataset双方でストレージコストがかかる</li>
</ul>
<h1>Analytics Hubを用いて問題点を改善</h1>
<p>まず前提として、Analytics Hubでは以下の構成によりDatasetを共有することができます。各権限の詳細は<a href="https://cloud.google.com/bigquery/docs/analytics-hub-grant-roles?hl=ja">公式ドキュメント</a>をご覧ください。<br>
<img src="https://ik.imagekit.io/plaid/c0d7cca4-fe2a-4291-90c9-24d0d260a7e4/image3.png" alt="image3.png"><br>
<em><a href="https://cloud.google.com/bigquery/docs/analytics-hub-introduction#subscriber_workflow">Introduction to Analytics Hub</a>より引用</em></p>
<ul>
<li>Publisher : 共有元となるDatasetを持つGCP Project</li>
<li>Data Exchange : Publisherが共有対象となるListingを作る場所</li>
<li>Listing : PublisherがData Exchange内に作成した、共有対象となるDatasetのリストで、SubscriberはこのListingへの <code>roles/analyticshub.subscriber</code> 権限を持つ</li>
<li>Subscriber : Analytics Hub経由で共有されたLinked Datasetを使う側を指し、このSubscriberはListingをSubscribeすることでLinked Datasetを自分のGCP Project内に作成する</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/ea657c14-c835-4176-8c15-616c4be357dc/image2.png" alt="image2.png"></p>
<p>Analytics Hubを通じてDatasetを共有することで、Datasetのデータ実体はKARTE Data Layerに共有することなく、Origin Datasetの内部にあるデータと同じものをShared Datasetに対してクエリを実行することで取得できます。この時、Origin Datasetに対して権限を持っているGCPのService Accountのみが共有対象のAnalytics HubのListingを作ることができるように権限管理をしているため、Data ExchangeはDatahub Data Layerに置いています。<br>
Analytics HubでDatasetを共有することで、従来のSAで直接共有する形式では見えずらかった、共有先での使用状況や、共有先が明確になりました。<br>
また、データコピーの必要がなく、かつストレージはOrigin Datasetにのみ課金されるため、上記の2点の問題点が両方とも解決できます。</p>
<h1>セキュアなデータガバナンスの取り組み</h1>
<p>KARTE Data Layerに一度共有されたDatasetは、そのクライアント企業がKARTEの他のプロダクトから利用することができます。しかし、一度共有したDatasetであっても、何かの事情がありそのDatasetをKARTEの他のサービスへ共有停止したいというケースもあります。<br>
そのような際には、Analytics HubのPublisher側でそのDatasetのSubscriptionを削除する、Subscriber側で共有されているDatasetを削除するなど、いずれの方法でも瞬時に共有を停止できます。<br>
また、現在共有されているDatasetをListingから取得できるため、共有中のDatasetのListingへ監視を入れておくことで、意図せずDatasetが共有されてしまっているという状態をすぐに検知することも可能です。</p>
<h1>実際にAnalytics Hubを使ってみて</h1>
<p>Analytics Hubでは、一般公開されているDatasetをSubscribeして使うことや、異なる組織間でDatasetをセキュアに共有しつつ、クエリに対する課金も分離するという用途のみならず、同一組織内でもデータガバナンスの観点で、データへのアクセス権限を管理したり、特定のDatasetのみを特定の目的で他のGCPのプロジェクトへ共有して使うという用途でも使いやすい機能だと思いました。<br>
しかし、まだAnalytics Hubも出たばかりの機能ということで、以下の機能に関して改善が行われると、より使いやすい機能になると感じました。</p>
<ul>
<li>Listingを消した時に自動でLinked Datasetも削除されること</li>
<li>共有用URL経由でLinked Datasetを作成できるGCPプロジェクトを限定したい
<ul>
<li>Service Accountの権限で制限をかけることもできるが、Service Accountの権限設定ミスで想定外のGCPプロジェクトのSAが権限を持ってしまった場合に備えて、Listingごとに共有先として許可するGCPプロジェクトを指定したい</li>
</ul>
</li>
<li>Node.js API Clientの拡充</li>
</ul>
<p>上記のように改善点はいくつかあるものの、KARTEのデータガバナンスを強化する機能としては非常に有効な機能なので、今後も使用箇所を増やしていこうと思っています。</p>


2022年頃より使用可能になった、BigQueryのAnalytics Hubを用いた、安全なデータ共有の導入について紹介します。 

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有 - PLAID engineer blog

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有

OLAPデータベースにおける高速化の技術 - PLAID engineer blog

OLAPデータベースにおける高速化の技術

<p>こんにちは、プレイドでCore Platform開発の責任者をしているエンジニアのkusappeです。</p>
<p>プレイドの社内向けに行ったModern Data Stack勉強会の内容が好評だったので、データ基盤に携わる方に向けてブログ化しました。<br>
この記事では、Modern Data Stackとは何か、そのメリットや特徴について解説します。また、具体的な技術要素・主要サービスや重要だと思うトレンドについても紹介します。</p>
<h2>Modern Data Stackとは？</h2>
<p>Modern Data Stackとは、データの収集、処理、分析、可視化などデータ活用に関わる機能を、それぞれに特化したクラウドサービスやSaaSツールを組み合わせて構築するという考え方やその基盤のことを指します。<br>
クラウドサービスやその周辺の技術要素の進化によって、従来のデータ基盤と比べると以下のメリットがあると言われています。</p>
<ul>
<li>高いスケーラビリティや可用性を実現できる</li>
<li>SaaSを組み合わせてスピーディーにデータ基盤の環境を構築できる</li>
<li>簡単にツールを使えるようになり、誰でもデータの利活用ができる状態になる（データの民主化）</li>
</ul>
<p>そして、dbtのCEOは2020年に書いた<a href="https://www.getdbt.com/blog/future-of-the-modern-data-stack">Modern Data Stackの過去・現在・未来のブログ</a>で、「2021〜2025年にかけてさらなるイノベーションが起きるのでは？」と予測しています。<br>
データの活用をより加速させるためにも、具体的な技術要素や主要なSaaSサービスを押さえておくのはとても重要だと思います。それでは見ていきましょう。</p>
<h2>具体的な技術要素・主要なサービス</h2>
<p>個々の技術要素を説明する前に、まずはModern Data Stackの全体像（図1）を見てみましょう。今回紹介する図以外にも全体像の図はいくつかあるため、本記事末の参考資料のところに載せておきます。</p>
<p><img src="https://ik.imagekit.io/plaid/d538514d-1860-4e0c-abc1-5cb49e44b234/ModernDataStack_Overview.png" alt="ModernDataStack_Overview.png"><br>
図1. Modern Data Stack 全体像 ( https://www.moderndatastack.xyz/journal/the-modern-data-stack-ecosystem-spring-2022-edition-5qe )</p>
<p>それでは各カテゴリーと主要サービスを見ていきましょう。データの流れの観点から大きく、データ収集、データ処理、データ活用、その他（横断系）の4つに分類して解説します。</p>
<h3>データ収集</h3>
<ul>
<li>
<p>Data Warehouse<br>
Data Warehouseとは企業内の多種多様な大量データを貯め、様々な分析を行うために特化されたサービスのことです。Warehouse（倉庫）という言葉からも連想されるように、構造化されたデータを扱うイメージが強いです。画像やテキストなどの非構造化データを扱う場合は、Data Lakeという言葉が使われます。<br>
その中で一つ注目したいトレンドとして、ETLからELTへのシフト（図2）があります。<br>
Data Warehouse側の技術進化によって、まずはロードしてその後変換が簡単に実現できるようになりました。ETLと比べた場合のELTは、高速・低メンテナンス・ロードが1回で済むといった利点があります。<br>
ELTが標準になることによって、Data Warehouse内でのData Transformationの管理ニーズが高まってきました。</p>
<p><img src="https://ik.imagekit.io/plaid/10231ec1-5aa6-496b-9c56-9babf6c01ea6/ETL_ELT.png" alt="ETL_ELT.png"><br>
図2. ETLとELT ( https://aws.amazon.com/jp/compare/the-difference-between-etl-and-elt/ )</p>
</li>
<li>
<p>Data Integration<br>
様々なデータソースからデータウェアハウスにデータを集めるための連携ツール（図3）です。<br>
主要なSaaSとして、<a href="https://www.fivetran.com/">Fivetran</a> や <a href="https://airbyte.com/">Airbyte</a> があります。<br>
双方の立場から比較記事が出ているので興味ある方は見てみてください。</p>
<ul>
<li><a href="https://airbyte.com/etl-tools/fivetran-alternative-airbyte">Airbyte側の主張 (Fivetran vs Airbyte)</a></li>
<li><a href="https://www.fivetran.com/blog/fivetran-vs-airbyte-features-pricing-services-and-more">Fivetran側の主張 (Fivetran vs Airbyte)</a></li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/7b0729d6-51e1-437a-b7e4-4c71823c364e/Data_Integration_Overview.png" alt="Data_Integration_Overview.png"><br>
図3. Data Integration ( https://www.fivetran.com/data-movement )</p>
</li>
<li>
<p>Event Tracking<br>
Websiteでのクリック情報など、ユーザーの行動情報を取得するツールのことを指します。<br>
<a href="https://segment.com/">Segment</a>や<a href="https://www.rudderstack.com/">Rudderstack</a>あたりがグローバルでも有名ですね。<a href="https://karte.io/">KARTE</a>もこのリストの仲間に入れるように頑張らなくではと思います。<br>
SegmentとRudderstackに共通する点としては、Customer Dataを軸としてそれをマーケティングに使うだけではなく、データのTransformation機能や他の業務ツールとの連携など多岐にわたって活用していることが挙げられます。</p>
</li>
</ul>
<h3>データ処理</h3>
<ul>
<li>
<p>Data Transformation<br>
Data Warehouseにロードしたデータを使いやすい形に変換するレイヤーです。<br>
Warehouse側の技術進化によってSQLでできることが増え、基本的な処理はSQLで行うのが主流になってきています。<br>
そのデータ変換用のSQLを管理するフレームワークとして、<a href="https://www.getdbt.com/">dbt</a> や <a href="https://cloud.google.com/dataform?hl=ja">Dataform</a>があります。<br>
プレイドでのdbtの活用方法は先日<a href="https://tech.plaid.co.jp/signals_connector_dbt">ブログに記載</a>したのでよかったらみてください。</p>
</li>
<li>
<p>Metric Store<br>
一言でいうと、分析の際に使う指標や数値（メトリクス）の定義を一元管理するツールです。<br>
今までは各BIツールでメトリクス定義を管理していましたが、それによって以下問題が起きていました。<br>
- レポーティングで使う数値の定義が、各チーム・各BIツールによって違っていて何が正解なのかわからない<br>
- 運用管理しようとしても、定義がBIツールごとに散らばり重複しているので管理が大変<br>
メトリクスの定義管理をBIツールとは分離し、再利用可能にするというのがコンセプトです（図4）。Headless BIとも呼ばれます。<br>
SaaSとしては、<a href="https://www.getdbt.com/product/semantic-layer">dbt（semantic layer）</a>、<a href="https://metriql.com/">Metriql</a> 、<a href="https://cube.dev/">cube</a> があります。<br>
<img src="https://ik.imagekit.io/plaid/ee409271-1c44-416c-9b5b-d8c1df2aeab6/Metric_Store.png" alt="Metric_Store.png"><br>
図4. Metric Storeのコンセプト( https://benn.substack.com/p/metrics-layer )</p>
</li>
</ul>
<h3>データ活用</h3>
<ul>
<li>
<p>Data Analytics<br>
この領域はBIツールなど、みなさんご存知だと思うので割愛します</p>
</li>
<li>
<p>Reverse ETL<br>
Reverse ETLとは、Data Warehouseのデータを他のシステム（CRM、Marketing Tool、Operation用のSaaSなど）に連携する手法（図5）を指します。<br>
Data warehouseに入ったデータやその分析を最後アクションに結びつけることから、Data Activationとも呼ばれます。<br>
収集した生データや変換されたデータをビジネス上の価値に繋げるための重要な架け橋の一つだと考えられています。<br>
Reverse ETL / Data ActivationのSaaSは、<a href="https://www.rudderstack.com/">rudderstack</a>, <a href="https://www.getcensus.com/">Census</a> , <a href="https://hightouch.com/">hightouch</a> があります。<br>
<img src="https://ik.imagekit.io/plaid/939a59d5-f580-462b-955f-dd10eadad6c2/Data_Activation.png" alt="Data_Activation.png"><br>
図5. Data Activation ( https://www.getcensus.com/solutions/data-teams )</p>
</li>
</ul>
<h3>その他（横断系）</h3>
<ul>
<li>
<p>Data Governance<br>
ここまで説明したツールの進化によってデータの活用が進むと、今度はデータの運用管理が大変になり、管理ツールへのニーズが高まってきました。<br>
データ運用管理に求められる機能としては以下があります。</p>
<ul>
<li>データカタログ
<ul>
<li>組織内にあるデータを検索・発見する</li>
</ul>
</li>
<li>データリネージ
<ul>
<li>どこからどこへデータが流れたのかを可視化・監視する</li>
</ul>
</li>
<li>データオブザーバビリティ
<ul>
<li>今流れているデータのEnd-to-Endのモニタリングする（可視化、品質チェックetc）</li>
</ul>
</li>
</ul>
<p>各機能についてData Warehouse側でも提供しています。たとえば、<a href="https://www.databricks.com/jp/product/unity-catalog">DatabricksのUnity Catalog</a>、<a href="https://cloud.google.com/data-catalog?hl=ja">GCP Data Catalog</a>などなど。各種サービス跨いだ管理ツールとしては<a href="https://atlan.com/">Atlan</a>や<a href="https://www.montecarlodata.com/">MONTE CARLO</a> があります。</p>
<p>いずれの機能も内部的には各種サービスからメタデータを収集し、それを目的に応じて使用しているという構造になっています（図6）。なので、どれぐらい解像度高くリアルタイムでメタデータを収集できるかがポイントと言えます。<br>
　 <img src="https://ik.imagekit.io/plaid/a6f2dba8-5e18-44f4-aa16-1d066047fb28/Metadata_Lake.png" alt="Metadata_Lake.png"><br>
図6. Metadata管理 ( https://atlan.com/what-is-data-governance/?ref=/modern-data-stack-101/ )</p>
</li>
<li>
<p>Data Orchestration<br>
上で話したようなデータの収集・処理・活用を実行するために、タスクのワークフロー管理を行うツールを指します。<br>
主に<a href="https://airflow.apache.org/">Airflow</a>、<a href="https://www.prefect.io/">Prefect</a>、<a href="https://dagster.io/">dagster</a>あたりが有名です。</p>
</li>
</ul>
<h2>まとめ</h2>
<p>さて、Modern Data Stackとは何かから始めて、カテゴリーごとの技術要素・代表的なサービス・重要だと思うトレンドを解説しました。<br>
あくまで概要を説明しただけなので、実際にデータ基盤を構築しようとした際はいろいろなトピックを深掘りする必要が出てきます。参考資料にも今回調べたリンクを載せたので、みなさんが各トピックの詳細を知る上での手助けになれば幸いです。</p>
<h2>参考資料</h2>
<ul>
<li>Modern Data Stack全体像の図
<ul>
<li><a href="https://twitter.com/ValentinUmbach/status/1418242294952644611">https://twitter.com/ValentinUmbach/status/1418242294952644611</a></li>
<li><a href="https://www.indicative.com/resource/modern-data-infrastructure/">https://www.indicative.com/resource/modern-data-infrastructure/</a></li>
</ul>
</li>
<li>Modern Data Stack概論
<ul>
<li><a href="https://speakerdeck.com/satoshihirose/modandetasutatukugai-lun">https://speakerdeck.com/satoshihirose/modandetasutatukugai-lun</a></li>
</ul>
</li>
<li>Modern Data Stack Repository
<ul>
<li><a href="https://www.moderndatastack.xyz/">https://www.moderndatastack.xyz/</a></li>
</ul>
</li>
</ul>


プレイドの社内向けに行ったModern Data Stack勉強会の内容が好評だったので、データ基盤に携わる方に向けてModern Data Stackの概要、主要サービス、重要だと思うトレンドをまとめました。

社内勉強会「Modern Data Stack入門」の内容をブログ化しました - PLAID engineer blog

社内勉強会「Modern Data Stack入門」の内容をブログ化しました

<p>あけましておめでとうございます。エンジニアの Yui です。</p>
<h2>はじめに</h2>
<p>KARTE では毎年、年越し(1/1 0:00)のタイミングで KARTE を導入している一部のウェブサイトにおける新年のキャンペーンやセール開始によるリクエスト急増が見込まれます。このリクエスト急増に対応する事前のスケールアップやリアルタイムでの対応を一部のエンジニアで行なっています。</p>
<p>通常時はクラウド上のほぼ全てのリソースのスケーリングを自動化しているのですが、コストやコールドスタートに対する対策の観点からこのタイミングのみ一部を手動で対応しています。</p>
<p>この記事では今年どんな対応を行なったのかを記録として残しておきたいと思います。</p>
<h2>今回スケールさせた部分について</h2>
<p>KARTE ではインフラの大部分に Google Cloud を利用しています。今回スケールさせるのは主に Google Cloud のサービス群（Cloud Bigtable（以下 BigTable）, Google Kubernetes Engine（以下 GKE）, Compute Engine（以下 GCE） など）になります。</p>
<p>今回の対応部分である、KARTEのリアルタイム解析基盤についてざっくり説明します。<br>
<img src="https://ik.imagekit.io/plaid/57731d06-9649-41ae-9b82-bece8247f89c/%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%882024-01-1513.13.57.png" alt="スクリーンショット2024-01-1513.13.57.png"><br>
<a href="https://karte.io/feature/core-realtime/">リアルタイムユーザー解析</a></p>
<p>KARTE の JavaScript タグが入っているウェブサイトにユーザーが訪れると、そのユーザーの閲覧やクリックなどのウェブサイト上での行動（ = <strong>イベントデータ</strong>）が KARTE のサーバーに送られます。KARTE のサーバーは受け取ったイベントデータをリアルタイムに解析します。また、事前に設定している施策配信を行うかどうか（このページを閲覧した人にはこのポップアップを出す、など）の判定を行い、結果をウェブサイト側に返します。</p>
<p>この解析や配信判定処理を担当しているのがリアルタイム解析基盤と呼んでいる部分で、レイテンシやサーバー負荷状況がサイト上のユーザー体験にクリティカルに影響します。<br>
（リアルタイム解析基盤のアーキテクチャについて詳しく知りたい方はこちらの記事をご参照ください。 <a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</a> ）</p>
<h2>事前準備</h2>
<p>リアルタイム解析基盤はざっくり分けてユーザーの解析や配信判定などリアルタイムに処理する必要がある部分と、イベントデータの永続化など非リアルタイムの処理でよい部分があります。<br>
アーキテクチャや過去の対応実績をもとに特に前者に重点を置き、何をどの程度スケールさせるのかを事前に検討しました。</p>
<p>準備として実際に当日までに行った内容は以下です。</p>
<ul>
<li>
<p>当日の対応内容の読み合わせ（今回は4名で対応しました）</p>
</li>
<li>
<p>誰がどの部分を担当するのかを決める</p>
</li>
<li>
<p>各自担当部分についてスケールさせる値を決める</p>
<ul>
<li>昨年の年明けタイミングや直近1ヶ月の定常時のリクエスト数・インスタンス数の平均・最大値などを確認して判断しました</li>
</ul>
</li>
<li>
<p>Terraform や GKE の manifest など IaC で対応する部分は当日までに PR を作成し、レビューを済ませておく</p>
<ul>
<li>当日はこの PR をマージすることで CI/CD パイプラインが走り、変更が適用されます</li>
</ul>
</li>
<li>
<p>BigTable のスケールアウト検証</p>
<ul>
<li>BigTable は最小ノード数を増やしたからといって必要なリソースが確保できるかを確約していません。そこで、実際の環境で少なくとも数日前の時点で想定量までスケールできるかという点や、当日の作業手順確認の目的で事前検証を行いました。（数日前時点でスケールできたからといって当日に同じリソース量までスケールできることが確約されていない点は注意が必要です）</li>
</ul>
<blockquote>
<p>ノード割り当てとは、各プロジェクトで 1 つのゾーンにプロビジョニングできるノードの最大数です。この割り当て数にまだ達していなくても、クラスタにノードを追加できるとは限りません。ゾーンでこれ以上ノードを利用できない場合、プロジェクトで割り当てが残っていても、そのゾーンのクラスタにノードを追加できないことがあります</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/quotas?hl=ja#availability">割り当てと上限  |  Cloud Bigtable ドキュメント  |  Google Cloud</a></p>
<blockquote>
<p>ゾーンでノードがなくなると、構成した最小ノード数を満たすように追加ノードがプロビジョニングされません。</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/docs/autoscaling?hl=ja#determine-min">自動スケーリング  |  Cloud Bigtable ドキュメント  |  Google Cloud</a></p>
</li>
</ul>
<p>作業内容や担当、進捗についてはこんな感じで Notion で管理しました。<br>
<img src="https://ik.imagekit.io/plaid/53d77f2c-8d01-4bb4-9dab-65a83469c146/tasks.jpg" alt="tasks.jpg"></p>
<h2>当日やったこと</h2>
<p>作業当日（2023/12/31）は事前に決定した通りに以下の手順で作業を行いました。</p>
<ul>
<li>
<p>20:30 に Slack に集合</p>
</li>
<li>
<p>通常時に利用している自動スケール設定のモニタリングを OFF にする</p>
</li>
<li>
<p>Datadog のログ量を調整する</p>
<ul>
<li>普段から Datadog への書き込みが多いかつ重要度の低いログを一時的に停止させることで、不要なコストがかかることを防止する目的で行いました。</li>
</ul>
</li>
<li>
<p>BigTable クラスタのノードサイズの最小値を手動で徐々に上げていく</p>
<ul>
<li>
<p>BigTable はノードを増やすと一時的にレイテンシが増加し負荷がかかった状態が続く可能性があり、ユーザー体験に影響を与える可能性があります。一気に上げてレイテンシが高い状態が続くのを避けるため、都度レイテンシを確認しながら手動で徐々に上げるようにしました。</p>
<blockquote>
<p>クラスタ内のノード数が増加した後、クラスタのパフォーマンスが大幅に向上するまでに、負荷のかかった状態が最大 20 分間続く可能性があります。Bigtable は、その負荷に基づいてクラスタ内のノードをスケーリングします。</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/docs/performance?hl=ja#slower-perf">パフォーマンスについて  |  Cloud Bigtable ドキュメント  |  Google Cloud</a></p>
</li>
</ul>
</li>
<li>
<p>IaC 対応部分のPRをマージし、変更後の値までスケールすることを確認</p>
</li>
<li>
<p>Datadog のダッシュボードでスケール台数やエラーレート、レイテンシを監視し異常がないかを確認<br>
<img src="https://ik.imagekit.io/plaid/1f2e893a-0a49-4e39-9cce-efb048e06469/datadog.jpg" alt="datadog.jpg"><br>
▲こんな感じで作業と並行してダッシュボードを継続して確認していました</p>
</li>
</ul>
<p>以下は 2023/12/31 23:00 〜 2024/1/1 1:00 までのイベント数や接客数・スループットを Datadog のダッシュボードに描画したグラフです。0:00 のタイミングでリクエストが急増しているのがわかります。<br>
<img src="https://ik.imagekit.io/plaid/eea55fa4-e87e-4582-bea4-9baa1530368c/%E3%82%A4%E3%83%98%E3%82%99%E3%83%B3%E3%83%88%E6%95%B0.jpg" alt="イベント数.jpg"></p>
<p>当日は事前準備した内容の実施に加え、想定よりもリクエスト数が増えそうな兆候があったため追加でインスタンス数を増やすなどの対応を行いました。</p>
<h2>後片付け</h2>
<p>0:00〜0:30ごろをピークにリクエスト数が徐々に落ち着いていくのを確認しました。その後1:00頃からPRのリバートや手動でスケールさせた部分のスケールインを行いました。</p>
<p>スケールイン時も急激に台数を減らすとサーバーの負荷増加や BigTable のレイテンシ増加などでパフォーマンスが低下するおそれがあるため、対応方法に注意する必要があります。</p>
<p>今回対応した部分（BigTable, GKE,  GCE）に関してはスケールインを自動で徐々に行う設定が入ってることを確認し、スケールインを実行しました。</p>
<blockquote>
<p>クラスタ内のノード数を減らしてスケールダウンする場合、10 分間に 10% を超えるクラスタサイズの縮小は行わないようにしてください。スケールダウンが速すぎると、クラスタ内の残りのノードが一時的に過負荷になる場合にレイテンシが増加するなど、パフォーマンス上の問題が発生する可能性があります。</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/docs/scaling?hl=ja#scale-down">スケーリング | Cloud Bigtable ドキュメント | Google Cloud</a></p>
<blockquote>
<p>Kubernetes offers features to help you run highly available applications even when you introduce frequent voluntary disruptions.<br>
As an application owner, you can create a PodDisruptionBudget (PDB) for each application. A PDB limits the number of Pods of a replicated application that are down simultaneously from voluntary disruptions.</p>
</blockquote>
<p><a href="https://kubernetes.io/docs/concepts/workloads/pods/disruptions/">Disruptions | Kubernetes</a></p>
<blockquote>
<p>スケールインの速度を制御するには、追跡時間枠内でのオートスケーラーの最大許容削減数を構成します。</p>
<ul>
<li><strong>最大許容削減数</strong>（<code>maxScaledInReplicas</code>: VM インスタンスの数または割合）。指定された追跡時間枠内においてワークロードで（グループのピークサイズから）削除できるインスタンスの数。このパラメータを使用して、グループをどれだけスケールインできるかを制限します。これにより、より多くのインスタンスがサービスを開始するまで、発生しうる負荷スパイクに引き続き対応できます。最大許容削減数が小さいほど、スケールインの速度は遅くなります。</li>
<li><strong>追跡時間枠</strong>（<code>timeWindowSec</code>: 秒）一時的な負荷減少の後に負荷スパイクが発生する可能性が高く、最大許容削減数を超えてグループサイズをスケールインしたくない時間。このパラメータで、オートスケーラーが過去の負荷を処理するのに十分なピークサイズを決定する際の時間枠を定義します。オートスケーラーは、追跡時間枠で観測されたピークサイズから最大許容削減数を差し引いた値よりも小さいサイズには変更されません。追跡時間枠が長いほど、オートスケーラーは過去のピーク負荷を重視します。これにより、より慎重な安定したスケールインが可能になります。</li>
</ul>
</blockquote>
<p><a href="https://cloud.google.com/compute/docs/autoscaler/understanding-autoscaler-decisions?hl=ja">オートスケーラーによる判断の理解 | Compute Engine ドキュメント | Google Cloud</a></p>
<h2>おわりに</h2>
<p>年越しの瞬間はこんな感じで緊張感がありながらもわいわい対応していました。<br>
<img src="https://ik.imagekit.io/plaid/a87d020b-d545-410e-958a-6794e64efeaf/Group1.jpg" alt="Group1.jpg"><br>
普段はなかなかやらないような大幅なスケールアップやリアルタイムでの対応を行い、個人的にもとてもいい経験になりました。</p>
<p>CX（顧客体験）プラットフォーム「KARTE」を運営するPLAIDでは、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


普段からトラフィック量の多いプロダクトであるKARTEにおいて、特にトラフィックが増えることが想定できる年末年始のタイミングにおいて、事前スケールやリアルタイム対応をどのように行ったのかの記録です。

年越しのその瞬間、KARTEのリクエスト急増とスケールアップの裏側

<h2>概要</h2>
<p>本記事では <a href="https://www.getdbt.com/">dbt (data build tool)</a> を本番環境のサービスで使った事例を主に Web サービス開発者向けに紹介します。プレイドでは <a href="https://karte.io/package/signals/">KARTE Signals</a> Connector (以下、Signals コネクタ) の SQL を生成するエンジンとして dbt を使っています。dbt を使う前には機能を実現するための SQL が大きく複雑なために機能の追加や変更が困難な状態に陥っていました。dbt を使うことで SQL をシンプルな複数のファイルに分割して、自動テストも導入できるようになりました。機能の変更や保守がしやすくなり、開発速度と品質が向上しました。</p>
<h2>背景</h2>
<h3>dbt を使うに至った背景</h3>
<p>今回の記事の背景として Signals コネクタを紹介します。KARTE Signals にはダッシュボードとコネクタという2つの機能があります。Signals ダッシュボードは広告効果を表示・分析するためのツールですが、今回はスコープ外なので詳しく紹介しません。Signals コネクタは 1st Party Data を使って広告効果を根本的に改善するサービスです。Signals コネクタには主に3つの機能があります。1つ目は失われたコンバージョンの補完です。これまでコンバージョン情報の計測のために使っていた 3rd Party Cookie の利用が Intelligent Tracking Prevention (ITP) により阻害され、広告媒体のコンバージョン情報の欠損が発生します。この欠損したコンバージョンを広告媒体の Conversion API を利用して補完します。2つ目はターゲティングです。KARTE で取得する行動データや自社の CRM データを活用することでより高精度にターゲティングを実現します。3つ目は入札最適化の精度改善です。Value Based Bidding (VBB) という入札最適化によって目的広告費用対効果やコンバージョン値の最大化を目指します。</p>
<h3>広告API用データ作成の問題</h3>
<p>広告配信媒体は、その広告媒体の API ごとに必要なデータの内容やフォーマットが異なります。つまり、広告媒体 API の違いを吸収するように似たような機能の複雑な SQL を複数用意する必要があります。この複雑な SQL の開発と管理を楽にするために dbt を使っています。具体的には「複数の SQL テンプレートファイルと変数から1つの SQL を dbt が合成(compile)」します。Signals コネクタには dbt を使った SQL 合成の機能が組み込んであります。Signals コネクタではクライアントがデータフォーマットの違いを意識することはほとんどありません。管理画面上からいくつかのパラメータ設定をするだけで広告媒体 API に対してデータを送ることが出来ます。</p>
<h2>dbt</h2>
<h3>dbt とは何か？</h3>
<p>dbt はデータレイクもしくはデータウェアハウスと呼ばれるデータプラットフォームに格納されたデータの分析をサポートするツールです。 具体的には、オンラインエディタで SQL を書いてデータプラットフォームで実行したり、Git で SQL ファイルを管理したり、CI/CD でビルドやテスト、デプロイなどができます。</p>
<h3>なぜ dbt を選んだのか？</h3>
<p>dbt も含めて複数の SQL テンプレートファイルから1つの SQL を合成する方法はいくつかあります。たとえば、プログラミング言語と SQL フレームワークを使って SQL を生成したり、単純な SQL テンプレートに書く、ビジュアルエディタや統合開発環境を使うなどの方法があります。Signals チームでは初期に SQL 書くメンバーがプログラマではなかったのでプログラミング言語による SQL 生成は選択しませんでした。また、検証時に作成した SQL 文を活用したいという要望もありました。dbt はこれらの要求を満たしているツールの1つでした。OSS(dbt Core)としてソースコードが提供されているのとSaaSオンラインエディタ(dbt Cloud)を利用できるのが dbt の良いところです。</p>
<h2>開発と運用</h2>
<h3>dbt をどのように使っているか？</h3>
<p>dbt を使う前には KARTE 内のクエリエディタ機能で巨大な BigQuery SQL を書いていました。現在は dbt を使って動的に SQL を生成しています。テンプレートとなる SQL を書くときには dbt Cloud というオンライン開発環境で作業します。エディタ上で SQL のビルドや実行、テストデータを使ったテストもできます。dbt では Git を使ってテンプレートファイルを管理します。Git ブランチ切り替えや GitHub Pull Request 作成も dbt Cloud から操作できます。</p>
<p>dbt を使う前後でどのように SQL 開発環境が変わったのかを説明します。</p>
<table>
<thead>
<tr>
<th></th>
<th>dbt 使用前</th>
<th>dbt 使用後</th>
</tr>
</thead>
<tbody>
<tr>
<td>SQL ファイル数(1機能あたり)</td>
<td>1</td>
<td>5 (平均)</td>
</tr>
<tr>
<td>SQL 行数(1ファイルあたり)</td>
<td>300 - 500</td>
<td>20 - 60</td>
</tr>
<tr>
<td>テストデータ作成</td>
<td>困難</td>
<td>容易</td>
</tr>
<tr>
<td>自動テスト</td>
<td>なし</td>
<td>あり</td>
</tr>
<tr>
<td>SQL クエリ管理</td>
<td>データベース</td>
<td>Git</td>
</tr>
<tr>
<td>クエリエディタ</td>
<td>独自 (機能少)</td>
<td>dbt Cloud (機能多)</td>
</tr>
</tbody>
</table>
<p>SQL ファイルの分割によってコードの見通しが良くなったことで、クエリを改善できて SQL の合計行数も少なくなっています。SQL を実行してエラーが出たときにテストデータに問題があるのかクエリ内容の問題なのか切り分けるのが難しかった問題も、小さな SQL に分割することによって判断しやすくなりました。SQL の自動テストについては後述します。</p>
<h3>dbt 関連サーバ構成</h3>
<p>dbt の SQL 合成は GraphQL API を通じて行うようにしました。dbt Cloud の API (REST API) を使うことも検討したのですが、BigQuery の権限管理の要件を満たすことができずに自前で dbt API を作成して運用しています。</p>
<p>Signals の構成サーバのうち dbt に関係している部分だけを抜き出した構成図<br>
<img src="https://ik.imagekit.io/plaid/24ff250b-49f5-4131-a545-883909e01fe1/dbt_structure.png" alt="dbt_structure.png"></p>
<p>Signals サーバと dbt API サーバが GraphQL で通信します。dbt API サーバ自体はステートレスなのでデータベースを持たず dbt Core を通じて Git Repository (ワーキングディレクトリ)内の SQL ファイルを参照します。</p>
<h3>dbt を使った SQL 合成機能の開発フロー</h3>
<p>Signals チームにおける SQL 合成機能の開発フローを紹介します。ここでは新しい機能(モデル)を追加する場合のフローを例とします。SQL 開発自体は dbt Cloud のみでほとんど作業が完結します。</p>
<ol>
<li>Git の main ブランチから開発ブランチを作成する</li>
<li>seeds ディレクトリにテストデータ(csvファイル)を入れる(dbt seed で BigQuery にアップロードされる)</li>
<li>models 以下に新しいモデルのディレクトリを作成する</li>
<li>SQL ファイルを書いてビルドする(dbt build で BigQuery を使って SQL を実行する)</li>
<li>SQL が完成したら git commit して Pull Request を作る</li>
<li>CI による自動テストと担当者によるコードレビューを行う</li>
<li>PR をマージ後に GraphQL サーバとクライアントを自動生成して git commit して PR を作成する</li>
<li>CI によるテストとコードレビュー</li>
<li>PR をマージするとクライアントが自動リリースされる</li>
</ol>
<h3>自動ビルドと自動テスト</h3>
<p>CI でビルドを実行して SQL が正しいかどうかを確認します。BigQuery と接続することで合成した SQL が文法として正しいかどうかだけではなく、テストデータ自体のフォーマットや合成した SQL を実行して結果が取得できるかも確認します。テストとして特定の SQL 文を実行して結果の整合性を確認することもできます。</p>
<p>自動でビルドとテストを行えるようになったお陰で CI の時点で SQL の文法ミスや変数設定時の誤植などを減らすことができるようになりました。SQL ファイルを小さいファイルに分割したことによって個々の機能が明確になり、レビューも容易になりました。</p>
<p>自動テストではテストデータや個別の SQL 実行後のスキーマが正しいかどうかを検証します。自動テストによって SQL 修正時に特定の項目を出力してなかったりカラム名を間違っていたりするような単純なミスを見つけやすくなりました。</p>
<h3>GraphQL サーバとクライアントのコード生成スクリプト</h3>
<p>GraphQL サーバ (Python) と GraphQL クライアント (node.js) のコードをそれぞれスクリプトで生成しています。dbt Cloud を使って作成した SQL ファイルが models ディレクトリ以下に置いてあるものとします。コード生成スクリプトを実行すると GraphQL サーバと GraphQL クライアントのコードを生成します。</p>
<p>サーバ側のコード生成のポイントは SQL ファイルを読んで変数名を抽出しているところです。変数を GraphQL の引数として渡せるようにしています。変数を自動抽出することで変数名の間違いや抜け漏れを減らすことができます。</p>
<p>クライアント側のコード生成には <a href="https://the-guild.dev/graphql/codegen">GraphQL Code Generator</a> を使っています。GraphQL Code Generator は GraphQL スキーマと GraphQL ドキュメントから TypeScript などの言語による GraphQL クライアントを生成します。GraphQL スキーマはサーバ側のコードから自動生成します。スクリプトで自動生成した GraphQL ドキュメントと組み合わせると GraphQL クライアントを生成できます。</p>
<p><img src="https://ik.imagekit.io/plaid/5543098d-8f04-4876-91c5-b0a7edb88d4d/dbt_flow.png" alt="dbt_flow.png"></p>
<h2>現状の課題と展望</h2>
<h3>dbt の問題点</h3>
<p>dbt も万能ではなく、いくつか扱いづらいことがありました。使ってみて気づいた課題を共有します。</p>
<ul>
<li>dbt compile が遅い<br>
SQL の生成に使っている dbt compile に数秒程度かかります。複数ファイルをマージして変数展開している部分よりも BigQuery に接続しているところで時間がかかっているようです。頻繁に dbt compile を実行しないようにアプリケーションの実装を工夫することで問題を回避しています。</li>
<li>ファイル名や参照名のユニークネス<br>
dbt ではモデルという概念で生成される SQL を表し、複数のモデルを1つの dbt プロジェクトで扱えます。しかし、ファイル名や参照(ref)名をプロジェクト内でユニークにしなければならないという制限があります。複数のモデルでそれぞれ異なるファイル名をつける必要があります。似たような機能を提供してほぼ同じ内容の SQL ファイルに固有の名前を要求されるので、モデルが増えるたびにファイル名の重複を気にする必要があります。必要に応じて命名規則を定めた方が良いかもしれません。</li>
</ul>
<h3>今後の展望</h3>
<ul>
<li>SQL 合成機能以外も活用する<br>
dbt の本来の使い方である継続的なデータ分析のサポートの機能も使ってみたいと思います。たとえば <a href="https://docs.getdbt.com/reference/resource-properties/freshness">source freshness</a> を設定すると入力データが正しく更新されているか監視することができます。この機能を使えばサービス品質を向上するのに使えるはずです。</li>
<li>他の機能にも dbt を展開する<br>
KARTE やその他のプロダクトでも dbt を使える場所に展開することを検討しています。普及活動の一環として社内の勉強会で dbt の使い方や活用事例を何度か紹介しました。</li>
</ul>
<h2>まとめ</h2>
<p>KARTE Signals コネクタでは dbt Cloud で開発した SQL を独自の dbt GraphQL API を通じて本番環境で利用しています。dbt を導入することで SQL の開発や保守がやりやすくなりました。最大500行以上あった複雑な SQL を数十行のファイル群に分割することで見通しが良くなり、レビューや動作確認、テストデータの作成が容易になりました。また自動ビルドや自動テストを導入することで SQL の記述の問題に早く気付けるので、開発とデバッグの速度も向上しました。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営する<a href="https://plaid.co.jp/">PLAID</a>では、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


KARTE Signals コネクタの SQL 生成機能として dbt を活用して SQL 開発の課題を解決して開発効率を上げた具体的な手法を紹介します

KARTE Signals の複雑 SQL を支える dbt の活用

Engineer Blog

Recent Article

BigQueryの分散処理の仕組みを深掘りする

生成AIカンファレンス2024 参加レポート

プレイドインターン体験記: はじめての開発インターンを通じて得た学び

Microsoft の AI 技術をベースに構成される Craft Functions Copilot

プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有

OLAPデータベースにおける高速化の技術

社内勉強会「Modern Data Stack入門」の内容をブログ化しました

年越しのその瞬間、KARTEのリクエスト急増とスケールアップの裏側

KARTE Signals の複雑 SQL を支える dbt の活用

Popular Articles

Popular Tags

Archives

Writers

Recent Article

BigQueryの分散処理の仕組みを深掘りする

生成AIカンファレンス2024 参加レポート

プレイドインターン体験記: はじめての開発インターンを通じて得た学び

Microsoft の AI 技術 をベースに構成される Craft Functions Copilot

プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有

OLAPデータベースにおける高速化の技術

社内勉強会「Modern Data Stack入門」の内容をブログ化しました

年越しのその瞬間、KARTEのリクエスト急増とスケールアップの裏側

KARTE Signals の複雑 SQL を支える dbt の活用

Popular Articles

Popular Tags

Archives

Writers

Microsoft の AI 技術をベースに構成される Craft Functions Copilot