Engineer Blog

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


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

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

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

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


いろいろなBitmap Indexの紹介

<h2>はじめに</h2>
<hr>
<p>こんにちは。プレイドのKARTE Datahubチームでエンジニアをしている安海です。</p>
<p>この記事は「<a href="https://tech.plaid.co.jp/multi-product-audit-log-collection">マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装　- 収集編</a>」の続編です。<br>
前回は監査ログの収集基盤について解説しましたが、今回は収集した監査ログをどのように抽出し、ユーザーに提供しているのか、そのアーキテクチャと技術的な工夫について詳しく解説します。<br>
監査ログの抽出基盤を設計・運用する際に直面した課題と、それに対する解決策を共有することで、同様の課題に取り組むエンジニアの一助となれば幸いです。</p>
<h2>抽出基盤のアーキテクチャ</h2>
<hr>
<p>監査ログの抽出基盤は、「他プロジェクトのデータが混在しない安全性」と「開発者の実装のしやすさ」を両立することを目指して設計されています。具体的には、以下のようなアーキテクチャを採用しています。</p>
<p><img src="https://ik.imagekit.io/plaid/ffa4aa6f-b680-42f2-ace3-661e65c9dfa1/auditlog_table_function_architecture.png" alt="auditlog_table_function_architecture.png"></p>
<h3>なぜテーブル関数を採用したのか</h3>
<p>まず、監査ログの抽出基盤でなぜ <a href="https://cloud.google.com/bigquery/docs/table-functions?hl=ja">BigQueryのテーブル関数</a> を採用したのかについて説明したいと思います。テーブル関数は、SQLクエリをカプセル化し、関数として再利用できるBigQueryの機能です。通常のテーブルと同様にクエリ内で参照でき、さらに引数を受け取れる点が大きな特徴です。<a href="https://cloud.google.com/bigquery/docs/views-intro?hl=ja">ビュー</a>と異なり、実行時にパラメータを渡せるため、同一のロジックを様々な条件で使い回すことができます。</p>
<p>例えば、以下のようにシンプルなテーブル関数を定義できます。</p>
<pre><code class="language-sql">CREATE OR REPLACE TABLE FUNCTION project_dataset.get_project_logs(project_id STRING, start_date DATE, end_date DATE)
AS (
  SELECT *
  FROM `logs.audit_logs`
  WHERE project_id = project_id
    AND DATE(timestamp) BETWEEN start_date AND end_date
);

</code></pre>
<p>このテーブル関数は、クエリから次のように参照できます。</p>
<pre><code class="language-sql">SELECT *
FROM project_dataset.get_project_logs('project-123', DATE('2023-01-01'), DATE('2023-01-31'))
WHERE severity = 'ERROR'
ORDER BY timestamp DESC
LIMIT 100;

</code></pre>
<p>テーブル関数を採用した主な理由は、クエリ実行時にパラメータを受け取れる柔軟性にあります。特に監査ログでは、ユーザーが任意の期間のログを抽出できることが重要な要件でした。テーブル関数を使用することで、日付範囲などのパラメータを実行時に指定でき、ユーザーは必要なデータだけを効率的に取得できます。</p>
<p>さらに、生ログは日時でパーティショニングされているため、日付範囲を指定することでパーティションプルーニングが働きます。この仕組みにより、不要なデータスキャンを最小限に抑え、クエリのパフォーマンスを向上させることが可能です。</p>
<p>また、SQLのロジックをテーブル関数内にカプセル化できるため、クエリの再利用性が高まることもメリットです。これにより、複雑なロジックを一箇所に集約し、メンテナンス性を向上させることができます。</p>
<h3>テーブル関数の役割と設計</h3>
<p>抽出基盤の中核となるのは3種類のテーブル関数です。これらの役割と設計思想について解説します。</p>
<h4>1. プロジェクトログ抽出テーブル関数</h4>
<p>この基盤層のテーブル関数は、引数で指定されたプロジェクトIDに対応するログだけを抽出する役割を担っています。他プロジェクトのログが露出するリスクを最小化するため、この関数は変更頻度が低くなるような設計としています。</p>
<p>単一の責務に特化することで、SQLの複雑性を抑制し、堅牢性を高めています。この層がセキュリティの要となるため、変更する際にはGithubで指定された <code>CODE_OWNER</code> のコードレビュープロセスを経る必要があります。</p>
<h4>2. プロダクト別変換テーブル関数</h4>
<p>プレイドでは複数のプロダクトを展開しており、各プロダクトでクライアント向け監査ログへの変換方法が異なります。そこで、プロダクトごとに専用の変換テーブル関数を用意し、それぞれのデータ構造に合わせた変換ロジックを定義できるようにしています。</p>
<p>実際のデータ変換の例はこのような感じです。例えば、以下のような生ログのJSON構造があるとします：</p>
<pre><code class="language-json">{
  &quot;jsonPayload&quot;: {
    &quot;user&quot;: {
      &quot;id&quot;: &quot;user_12345&quot;,
      &quot;name&quot;: &quot;山田太郎&quot;,
      &quot;email&quot;: &quot;yamada@example.com&quot;
    },
    &quot;http_request_meta&quot;: {
      &quot;ip&quot;: &quot;192.168.1.1&quot;,
      &quot;user_agent&quot;: &quot;Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)...&quot;
    },
    &quot;resource&quot;: {
      &quot;type&quot;: &quot;dataset&quot;,
      &quot;id&quot;: &quot;dataset_789&quot;,
      &quot;action_type&quot;: &quot;update&quot;
    },
    &quot;detail&quot;: [
      {
        &quot;detailType&quot;: &quot;diff&quot;,
        &quot;new&quot;: {&quot;dataset_name&quot;: &quot;分析用データセット2023&quot;},
        &quot;old&quot;: {&quot;dataset_name&quot;: &quot;分析用データセット&quot;}
      },
      {
        &quot;detailType&quot;: &quot;fields&quot;,
        &quot;value&quot;: {&quot;created_at&quot;: &quot;2023-05-01T09:00:00Z&quot;}
      }
    ],
    &quot;timestamp&quot;: &quot;2023-05-01T10:15:30Z&quot;
  }
}

</code></pre>
<p>このような生ログから、ユーザーに見せる監査ログとして以下のような形式に変換したいとします：</p>
<table>
<thead>
<tr>
<th>user_id</th>
<th>ip_address</th>
<th>action</th>
<th>resource_type</th>
<th>resource_id</th>
<th>timestamp</th>
<th>before_edit</th>
<th>after_edit</th>
</tr>
</thead>
<tbody>
<tr>
<td>user_12345</td>
<td>192.168.1.1</td>
<td>update</td>
<td>dataset</td>
<td>dataset_789</td>
<td>2023-05-01T10:15:30Z</td>
<td>{ &quot;dataset_name&quot;: &quot;分析用データセット&quot; }</td>
<td>{ &quot;dataset_name&quot;: &quot;分析用データセット2023&quot; }</td>
</tr>
</tbody>
</table>
<p>このような変換を行うために、各プロダクトチームはどのフィールドをどのように抽出・変換するかをマッピング定義として記述します。これにより、生ログの複雑なネスト構造から必要な情報だけを取り出し、ユーザーにとって理解しやすい形式に整形できます。</p>
<p>この層では宣言的なアプローチを採用しており、各プロダクトチームは変換マッピングを定義するだけで、自動的にSQL文(テーブル関数)が生成される仕組みを整えています。これにより、SQLを意識しなくても監査ログの変換ロジックを実装できます。</p>
<p><strong>マッピングの仕様：</strong></p>
<ul>
<li><strong>基本構造</strong>
<ul>
<li><code>map</code> 内の key は整形後の監査ログのカラム名を指定します</li>
<li><code>columnName</code> には生ログのデータパスを指定します</li>
<li><code>type</code> にはデータ型（STRING, JSON など）を指定します</li>
</ul>
</li>
<li><strong>detail フィールドの処理</strong>
<ul>
<li><code>detail</code> フィールドには比較的自由な形式のデータが格納されるため、特殊なマッピングを指定できます：
<ul>
<li><code>detailType</code> - 処理対象のデータタイプ（<code>diff</code>/<code>fields</code>/<code>error</code> など）</li>
<li><code>detailFieldsKey</code> - オブジェクト内の抽出したいキー名</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>実際に <code>detail</code> に格納されるデータの例<br>
※ 同一 detailType のオブジェクトが複数入らないようにしています</p>
<pre><code class="language-jsx">[
  {detailType: &quot;diff&quot;, new: {dataset_name: &quot;hoge&quot;} old: { dataset_name: &quot;fuga&quot; }},
  {detailType: &quot;fields&quot;, value: { hoge: 1, fuga: &quot;piyo&quot; }},
  {detailType: &quot;error&quot;, message: &quot;this is error&quot; }
]

</code></pre>
<p>以下は変換マッピングの例です。このマッピングでは、ユーザーID、IPアドレス、編集前の値などを抽出する方法を定義しています。</p>
<p>また、より柔軟なデータ抽出が必要な場合には、<code>custom</code>セクションを利用してカスタムの<code>SELECT</code>文を記述できます。これにより、既存のパターンでは対応できない特殊な要件にも対応可能です。例えば、特定の条件に基づいてデータを加工したり、集約した結果を取得することができます。</p>
<pre><code class="language-jsx">{
  map: {
    user_id: { columnName: 'user.id', type: 'STRING' },
    ip_address: { columnName: 'http_request_meta.ip', type: 'STRING' },
    before_edit: {
      columnName: detail,
      type: 'JSON',
      detailType: 'diff',
      detailFieldsKey: 'old',
    },
  },
  custom: {
    selectQueries: [
      `TO_JSON(ANY_VALUE(IF(STRING(detail.detailType) = 'fields' AND CAST(jsonPayload.resource.action_type AS STRING) = 'create', detail.value, NULL))) AS created_value`,
    ],
  },
  version: '1'
};

</code></pre>
<p>このマッピング定義から、以下のようなSQLが自動生成されます。</p>
<pre><code>SELECT
  CAST(jsonPayload.user.id AS STRING) AS user_id,
  CAST(jsonPayload.http_request_meta.ip AS STRING) AS ip_address,
  TO_JSON(ANY_VALUE(IF(detail.detailType = 'diff', detail.old, NULL))) AS before_edit,
  TO_JSON(ANY_VALUE(IF(STRING(detail.detailType) = 'fields' AND CAST(jsonPayload.resource.action_type AS STRING) = 'create', detail.value, NULL))) AS created_value
FROM
  sampleTableFunction(api_key, start_date, end_date)
  ...

</code></pre>
<h4>3. プロジェクト別テーブル関数</h4>
<p>最終的なデータ提供層として、プロジェクトごとにデータセットを分け、その中にプロダクトごとのテーブル関数を配置しています。この設計には二つの利点があります。</p>
<ol>
<li>将来的に<a href="https://cloud.google.com/bigquery/docs/analytics-hub-introduction?hl=en">BigQuery sharing</a>経由などでデータセットごとユーザーに提供する可能性への対応</li>
<li>マッピング変更時の影響範囲の局所化</li>
</ol>
<p>このテーブル関数は基本的に中間層（プロダクト別変換テーブル関数）を参照するだけの構造になっています。そのため、中間層の変換ロジックが変更された場合でも、すべてのプロジェクトデータセット内のテーブル関数を更新する必要がなく、運用負荷を大幅に削減できます。</p>
<h3>テーブル関数の自動生成と管理</h3>
<p>続いて、テーブル関数の作成・更新プロセスについて説明していきます。構成としては、以下のようになっており、基本的に自動化されています。</p>
<p><img src="https://ik.imagekit.io/plaid/47096b33-1545-48e9-aa3d-2269ef407723/auditlog_table_function_automation.png" alt="auditlog_table_function_automation.png"></p>
<h4>プロジェクトログ抽出テーブル関数の管理</h4>
<p>基盤層のテーブル関数は、リポジトリ内のコード変更をトリガーにGitHub Actionsを通じて更新されます。(構成図の左側参照) この重要なコンポーネントはCODE_OWNERで厳格に管理されており、特定のレビュアーの承認がなければ変更できない仕組みになっています。</p>
<h4>プロダクト別テーブル関数の自動生成</h4>
<p>各プロダクトチームは、マッピング定義を更新するだけで、GitHub Actions経由でSQLが自動生成され、対応するテーブル関数が更新されます。(構成図の左側参照)</p>
<h4>プロジェクト別データセット・テーブル関数の自動生成</h4>
<p>新しいプロジェクトのデータが生ログに追加された場合、自動的に対応するデータセットとテーブル関数が作成される仕組みを実装しています。(構成図の右側参照) 具体的には、Cloud Schedulerで定期的にCloud Run関数を起動し、直近の生ログをスキャンして新規プロジェクトを検出します。</p>
<p>検出された新しいプロジェクトに対しては、データセットの作成とテーブル関数の生成が自動的に行われます。データセット・テーブル関数が作成済みのプロジェクトに関する情報は、BigQueryの簡易的なテーブルを使い以下のように管理しています。</p>
<table>
<thead>
<tr>
<th>project_id</th>
<th>product</th>
<th>version</th>
<th>created_at</th>
</tr>
</thead>
<tbody>
<tr>
<td>xxx</td>
<td>talk</td>
<td>0</td>
<td>2025-04-30 02:50:19.420000 UTC</td>
</tr>
<tr>
<td>xxx</td>
<td>datahub</td>
<td>0</td>
<td>2025-04-30 02:50:19.420000 UTC</td>
</tr>
<tr>
<td>xxx</td>
<td>datahub</td>
<td>1</td>
<td>2025-04-30 02:51:19.420000 UTC</td>
</tr>
</tbody>
</table>
<h2>保守運用の工夫</h2>
<hr>
<p>監査ログ基盤の運用には、データの安全性確保と長期的な保守性の両立が求められます。ここでは、その課題に対応するための技術的な工夫を紹介します。</p>
<h3>効率的なデータダウンロード機構</h3>
<p>監査ログは大量のデータを扱うため、効率的なダウンロード機構が必要です。そこで、BigQueryのストリーミング機能を活用し、データを10MBごとに圧縮してクライアントに送信する仕組みを実装しています。</p>
<p>また、ユーザビリティ向上のための工夫として、生ログに含まれる<code>projectId</code>などの単なる識別子を、ストリーミング処理中にアプリケーションのデータベースから取得したプロジェクト情報と結合し、 <code>株式会社プレイド検証環境</code> のようなユーザーが理解しやすい表記に変換しています。</p>
<p>この仕組みは現状は十分に対応できていますが、予期せぬ大量データなどによりエラーが発生した場合は、Datadogにエラーを通知するようにしているため、迅速に対応できるようになっています。</p>
<h3>多層的なセーフティネット</h3>
<p>他プロジェクトのデータが混入するリスクを最小化するため、複数のセーフティネットを設けています。</p>
<p>まず、テーブル関数のセキュリティ監視として、Cloud Scheduler と Cloud Run 関数を組み合わせ、定期的にテーブル関数にアクセスして返されるデータを検証しています。他プロジェクトのデータが検出された場合は、即時 Datadog のアラートが発報される仕組みです。</p>
<p>さらに、ユーザーがデータをダウンロードするストーリミング処理にも、BigQueryで二重チェックを行い、他プロジェクトのログが含まれていないことを確認しています。万一の混入が検出された場合は、ダウンロード処理を中止する安全機構を導入しています。</p>
<h3>継続的なサービス監視</h3>
<p>監査ログは機能的な性質上、月に一回ダウンロードされるなど、日常的に頻繁に使用される機能ではありません。そのため、問題が長期間気づかれず放置されてしまうリスクがあります。この課題に対応するため、<a href="https://www.datadoghq.com/ja/dg/apm/synthetics/synthetic-monitoring/">Datadog Synthetics (外形監視ツール)</a>を活用して、画面から定期的にダウンロードを行い実際にファイルがダウンロードできるかのチェックしています。</p>
<p>これにより、実際のユーザーが機能を使用する前に問題を発見し、迅速に対応することができる体制を整えています。</p>
<h3>テーブル関数のバージョン管理</h3>
<p>監査ログのカラム構成や形式は、プロダクトの進化に合わせて変更される可能性があります。変更があった場合でも、既存のシステムやユーザーの利用を妨げないために、テーブル関数にはバージョン管理機能を導入しています。</p>
<p>マッピング定義に<code>version</code>パラメータを指定することで、新しいバージョンのテーブル関数を追加しつつ、既存のバージョンも並行して維持できます。これにより、ユーザーは自身のニーズに合わせたバージョンを選択できるようになり、互換性を保ちながら監査ログを変更させることができるようになっています。</p>
<h2>まとめ</h2>
<hr>
<p>監査ログの抽出基盤は、セキュリティとユーザビリティのバランスを取りながら、開発者が容易に実装・拡張できる設計を目指しています。多層構造のテーブル関数、自動生成の仕組み、複数のセーフティネットにより、安全かつ柔軟な監査ログ提供を実現しています。</p>
<p>マルチプロダクト環境では、新しいプロダクトの追加や既存プロダクトの変更が頻繁に発生しますが、この基盤により、各プロダクトチームは複雑なセキュリティ実装をほとんど意識せずに、安全に監査ログを拡張できます。プロダクト間の監査ログの一貫性を保ちながらも、それぞれのプロダクト特有の情報を柔軟に取り込める設計が、マルチプロダクト戦略を支える重要な要素となっています。</p>
<p>今後も新たな要件やプロダクトの追加に対応しながら、監査ログ基盤の進化を続けていく予定です。また、さらなる活用方法として、機密情報を適切に除去した上で社内の調査・分析用途に監査ログを活用することも検討しています。例えば、長期間使用されていないアカウントの洗い出しやプロダクト使用状況分析などを通じて、セキュリティの強化やサービス改善に繋げていくことが可能です。このように監査ログは単なる記録としてだけでなく、データドリブンな意思決定を支える貴重な情報源となる可能性を秘めています。</p>


マルチプロダクト環境における監査ログ抽出基盤のアーキテクチャと技術的な工夫を解説。BigQueryのテーブル関数を活用し、「安全性」と「開発のしやすさ」を両立する設計思想、自動生成の仕組み、運用時の工夫を紹介します。

監査ログ抽出基盤の設計と実装：BigQueryテーブル関数による安全性と柔軟性の両立

マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装 - 抽出編

<h1>はじめに</h1>
<p>こんにちは。プレイドのKARTE Messageチームでエンジニアをしている林(<a href="https://x.com/smoothbronco">Twitter</a>)です。</p>
<p>この記事では、動的にSQLを生成する機能の実装を無事故で改善し、その後の開発スピードを向上させたことについてお話しします。</p>
<h1>KARTE Messageについて</h1>
<p><a href="https://karte.io/package/message/">KARTE Message</a>は、メール・アプリプッシュ・LINEなどのチャネルからエンドユーザーにパーソナライズした配信を効率化したMAツールです。</p>
<p><a href="https://tech.plaid.co.jp/karte_message_mass_delivery_architecture">メール配信サービスの運用について紹介している記事</a> があるので、こちらもぜひ併せてご覧ください。</p>
<h2>配信対象抽出機能について</h2>
<p>KARTE Messageでは、SQLが書けないマーケターでもGUIベースでメールやLINEの配信対象を抽出できるための機能を提供しています。</p>
<p>配信対象はデータ統合・利活用プラットフォームである<a href="https://developers.karte.io/docs/about-datahub">KARTE Datahub</a>内のテーブルまたはクエリをベースにしており、「リスト」と呼びます。</p>
<p>リストには配信対象のメールアドレスやユーザーID、クーポンコード等のコンテンツに埋め込むデータが入っています。</p>
<p>たとえば、会員マスタのうちGOLDランクの会員にだけメールを送りたい場合は、以下のような操作で対象を絞り込むことができます。ある対象を除外する、パーソナライズした値をコンテンツに埋め込む、施策内で1ユーザーに対してx回まで配信する、といったこともこの機能で実現しています。</p>
<p>※ データはすべてダミーです。</p>
<p><img src="https://ik.imagekit.io/plaid/ab4a4133-596b-42e1-986a-164fa2a444fb/merge_list.webp" alt="merge_list.webp"></p>
<p>配信対象抽出の裏側では、クライアントの設定した値から動的にSQLを生成しています。</p>
<p>先ほどのGOLD会員の例では、以下のようなSQLを生成します。</p>
<pre><code class="language-sql">WITH result AS (
	WITH master_{list_id} AS (
		-- &quot;【デモ】マスターデータ_メール&quot;のクエリ
		SELECT * FROM demo_master_mail
	),
	subset_{list_id} AS (
		-- &quot;gold会員&quot;のクエリ
		SELECT * FROM demo_master_mail WHERE rank = 'gold'
	),
	merge_list AS (
		WITH master AS (
			SELECT * FROM master_{list_id}
		),
		subset AS (
			SELECT user_id FROM subset_{list_id}
		)
		SELECT
			master.user_id AS user_id,
			master.email AS target
		FROM master
		LEFT JOIN subset ON master.user_id = subset.user_id
		WHERE subset.user_id IS NOT NULL
	)
	-- (中略)
)
SELECT * FROM result;
</code></pre>
<p>このSQLは配信する時とクライアントが対象ユーザーをプレビューする時にKARTE Datahubのテーブルに対してクエリします。</p>
<p>対象抽出のデータ結合に用いるキーはユーザーIDか配信先 (メールアドレスやLINE ID) を使っており、ユーザーIDのカラムがある場合はユーザーIDで結合します。</p>
<p>クライアントの持っているデータによってはユーザーIDカラムのないデータもあるので、その場合は配信先のカラムで結合します。</p>
<p>また、一部のユーザーIDがnullになっていることもあります。</p>
<h2>改善前の課題</h2>
<p>たとえば以下のようなケースだと、メールアドレスが一致していても一部でuser_idがnullになっている場合はパーソナライズする値が落ちてしまいます。</p>
<p><img src="https://ik.imagekit.io/plaid/acd9c458-90cd-404f-a92d-bc3f94f36254/user_id_null.png" alt="user_id_null.png"></p>
<p>このようなケースを含め、配信対象抽出機能を改善する前は以下のような課題がありました。</p>
<ul>
<li>データに関する課題
<ul>
<li>targetやuser_idという一般的な名前が予約語になっており、クライアントの設定次第でカラム名が衝突する</li>
<li>user_idがnullableなので、対象抽出やパーソナライズする値を結合する際にレコードが落ちる場合がある</li>
</ul>
</li>
<li>ロジックに関する課題
<ul>
<li>配信時のクエリとプレビュー時のクエリを返すロジックの共通化ができておらず、出力に差分が生じてしまう</li>
<li>コードが複雑で処理の分割がうまくできておらず、キャッチアップコストが高い</li>
</ul>
</li>
</ul>
<p>配信対象抽出機能はKARTE Messageの中でもコアになる機能であることや、今後も頻繁にアップデートがかかることが想定される機能でした。この状態のまま運用していくと予期せぬバグやインシデントを起こしかねないので、機能全体に手をいれることにしました。</p>
<h2>やったこと</h2>
<p>以下2つのアプローチを取って行いました。</p>
<ol>
<li>リストの元データを view table にし、クエリするときは view table を参照する</li>
<li>既存の仕様からデータモデルを再定義し、コードをまるっと作り替える</li>
</ol>
<p>1つ目に関しては、view tableにすることでクライアントのデータに一定の前提を設けられるので、データに関する課題を解決することができると考えました。</p>
<p>2つ目に関しては、仕様が明確だったこと、既存のコードに対してテストが不十分だったことなどから、改めてデータモデルから作り替えた方がメンテナブルになるだろうと考えました。</p>
<h3>view tableにする対応について</h3>
<p>先に、viewのクエリを示します。</p>
<pre><code class="language-sql">SELECT
  *,
  cast(
    ifnull(
      cast(`user_id` as string),
      concat('null_embedded_', `email`)
    ) as string
  ) as masspush_user_id,
  cast(`mail` as string) as masspush_target,
FROM
  (
    -- リストの元データのクエリ
    SELECT
      *
    FROM
      demo_master_mail
  )
</code></pre>
<p>ポイントは2つです。</p>
<ul>
<li>予約語はクライアントが設定する可能性が限りなく低い命名にする</li>
<li>user_idがnullの時は<code>null_embedded_{配信先}</code> で埋める</li>
</ul>
<p>こうすることで、カラム名が重複することや最終的に配信対象が抜け落ちてしまうことが減りました。リストの元データのクエリは数百〜数千行になることもあるので、最終的なクエリをシンプルに保つことができるようにもなりました。</p>
<p>移行する中で難しかったのが、viewのクエリが参照するデータの鮮度を保つことです。</p>
<p>リストの中には、「先月10,000円以上購入した人」や「30分前にカゴ落ちした人」などの相対日時を条件に含むものがあります。これらは絶対日時に変換してクエリにしているので、配信やプレビューが実行される直前でviewのクエリを更新する必要がありました。</p>
<p>また、KARTE DatahubはBigQuery上にテーブルを保持しています。BigQueryのテーブル更新オペレーションは10秒で最大5つまでというクォータがあるので、都度viewを更新するのは現実的ではありません。</p>
<p>そこで、以下のような実装で更新オペレーションを極力減らすことにしました。</p>
<pre><code class="language-tsx">export const updateListViewQueryIfBaseSQLModified = async (
	baseSQL: string;
	list: List;
) =&gt; {
  const tableName = createTableName(list);
  const cachedQueryHash = await findCachedQueryHash(tableName);
  const newQueryHash = hashQuery(baseSQL);
  // 最新のqueryとcacheしたqueryのhashが一致してれば処理を終える
  if (cachedQueryHash === newQueryHash) {
    return;
  } else {
    // BigQueryに問い合わせてviewのqueryを比較する
    const isEqualBaseSQL = await compareViewToBaseSQL({
      list_id: list.id,
      baseSQL: baseSQL,
    });
    // queryが異なればviewのqueryを更新する
    if (!isEqualBaseSQL) {
      const viewQuery = buildQuery(list, baseSQL);
      await updateView(viewQuery, list.id);
    }
    // table名をkeyに、queryのhashをvalueにしたcacheを保存する
    await cacheQueryHash({ key: tableName, query: baseSQL });
  }
}
</code></pre>
<p>まず、BigQueryにリクエストする手前にcacheを挟むようにしました。同じリストを使い回して同時刻に複数個の配信を実行するクライアントは多いです。このようなケースはcacheのおかげでBigQueryへのリクエストを減らすことができました。</p>
<p>次のステップでは、BigQueryに問い合わせて最新のviewのqueryを取得し、比較するようにしました。テーブル取得のクォータは更新に比べて制約が緩いので、更新前に最終チェックをしています。</p>
<p>このようなステップを踏むことで、配信が集中する時間帯でもクォータを超えることなくviewのクエリを最新の状態に保つことができました。</p>
<h3>コードの作り替えについて</h3>
<p>コードの作り替えはTDDライクに行いました。まず仕様からテストケースを起こし、そのテストケースに従ってテストが通るようにコードを書くようにすることで、仕様の抜け漏れやエッジケースの見落としなどがないかを確認しながら進めることができました。</p>
<p>また、リリースに関してはview table対応とは別で行う、一部のテナントから段階的に行うなど、万が一問題があったときの影響範囲を最小限に抑えながら進めました。</p>
<h2>結果</h2>
<p>かなり大規模かつ問題が起きた時のリスクが大きい修正でしたが、配信に影響なくすべてリリースすることができました。</p>
<p>またこのリリース後、キャッチアップコストが大幅に減り、開発工数がより正確に見積れるようになりました。新しくチームに入ってきたエンジニアの方が新規に機能拡張をすることになった時も、キャッチアップが大変という感覚は無かったそうです。改善前に比べてテストも充実する形になったので、変更を加える際の影響範囲やエッジケースのバグ取りこぼしも見えやすくなりました。</p>
<p>課題の種類をデータとロジックに分けて、それぞれを解決するアプローチにしたことでシンプルになったと個人的には思っています。</p>
<h2>最後に</h2>
<p>私が所属するKARTE Messageチームでは、大量配信を支える配信基盤の改善や、より良いMAツールにしていくための機能開発など、まだまだやりたいことがたくさんあります。</p>
<p>少しでもこのような領域に興味を持ってくださった方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。応募待ってます！</p>


非エンジニアでも直感的に動的なSQLを生成できる、GUIのノーコードツールの改善方法の紹介

動的にSQLを生成する複雑なロジックに立ち向かい、開発スピードを向上させた話

<p>こんにちは！プレイドでエンジニアをしている土佐といいます。</p>
<p>先日、社内で「生成AI」をテーマにしたLightning Talk（LT）会が開催されました！🎉プレイドだけでなく、グループ会社のRightTouchメンバーも集結し、総勢なんと約80名が参加する、とっても賑やかなオンラインイベントになりました。</p>
<p>ここ数ヶ月、社内でもCursorやCline、Vertex AI経由のGPTモデルなど、さまざまな生成AIツールの活用がどんどん進んできて、「お、そろそろ各チームで溜まってきた知見や『こんなことやってみた！』をシェアする良いタイミングじゃない？」ということで、今回のLT会が企画されたんです。</p>
<p>この記事では、当日の熱気や発表の面白さ、そして私たちが感じた「これから」の可能性を、少しでも皆さんにお届けできればと思います。LT会の雰囲気や学びが伝わると嬉しいです！</p>
<h2><strong>当日の熱気：オンラインでも伝わる一体感！</strong></h2>
<p>会場はオンライン。それぞれの場所から参加する形でしたが、画面越しにも伝わる熱気…！🔥 発表が始まると、みんな真剣な表情で聞き入り、Slackのスレッドも質問や感想、「なるほど！」「それ面白い！」といったコメントで、めちゃくちゃ盛り上がっていました。</p>
<h2><strong>発表ハイライト 🚀</strong></h2>
<p>今回のLT会では、本当に多種多様なテーマで10件の発表がありました。どれも興味深く、刺激的な内容ばかりでした！すべての発表をダイジェストでご紹介します。</p>
<ul>
<li><strong>「採用面談の日程調整をAIにやってもらうワークフローを構築しました」</strong>
<ul>
<li>候補者と複数面接官の複雑なカレンダー調整を、Zapier AIとDifyを駆使して自動化！ Slackから使える「Google Calendar 日程提案くん」で、面倒な調整業務をスマートに解決する実用的な工夫が光りました。</li>
<li>詳細な記事はこちら
<ul>
<li><a href="https://note.com/kantetsu/n/n00958cea908d">https://note.com/kantetsu/n/n00958cea908d</a></li>
</ul>
</li>
</ul>
</li>
<li><strong>「お客さんの商品データを検索するMCPサーバー作ってみた」</strong>
<ul>
<li>通常のキーワード検索だけでなく、ベクトル検索で&quot;似ている商品&quot;も提案できるAPIサーバーを自作。ユーザーの「見つからない…」を減らす、既存技術を組み合わせた価値創造の好例でした。</li>
</ul>
</li>
<li><strong>「Cline + ChatGPT 4o 画像生成を使ったOSS開発をしてみた」</strong>
<ul>
<li>自作OSS「Gunshi」の開発で、Clineによるコーディング支援やドキュメント生成、ChatGPT 4oによるロゴ・OGP画像作成までAIを活用！ 開発プロセス全体でのAI活用スタイルが新鮮でした。</li>
<li><a href="https://gunshi.dev/">https://gunshi.dev/</a></li>
</ul>
</li>
<li><strong>「生成AIにサポートサイトドキュメントを書かせて公開してみた」</strong>
<ul>
<li>Cursor等のAIツールを使い、コードベースからサポートサイトのドキュメントを効率的に生成・公開。人間には手間のかかる表作成などもAIに任せる、実践的なノウハウが共有されました。</li>
</ul>
</li>
<li><strong>「ボランティアのイベント告知サイトの更新をClineを使ってほぼ自動化した件」</strong>
<ul>
<li>ボランティアで運営するWordPressサイトの更新作業を、Cline、RPA、ChatGPT生成HTMLで見事に自動化！ Gutenberg記法を活用することで、ビジュアルエディタとの互換性を持たせる工夫を行い、大幅な効率アップを実現した、技術による社会貢献の素敵な事例でした。</li>
</ul>
</li>
<li><strong>「AI開発基盤を作ってみた」</strong>
<ul>
<li>AI機能をより簡単に開発できる基盤を開発中。AIエージェント開発の知見集約や再利用性を高める土台作りのお話にワクワクしました。</li>
</ul>
</li>
<li><strong>「code-bugsというCLIツールを作った」</strong>
<ul>
<li>複数ファイルにまたがる定型的なコード修正を、AIが自動で行ってくれるCLIツール「code-bugs」を開発。簡単なレシピで面倒な作業を効率化する、開発者の頼もしい味方になりそうです！</li>
</ul>
</li>
<li><strong>「AI Agentにセキュリティレビューをやってもらう」</strong>
<ul>
<li>Copilot AgentやCursorにセキュリティルールを学習させ、コードレビューを補助させる試み。AIをセキュリティチェックの「心強い相棒」として活用する可能性が示されました。</li>
<li>詳細な記事はこちら
<ul>
<li><a href="https://tech.plaid.co.jp/security-review-by-ai-agent-101">https://tech.plaid.co.jp/security-review-by-ai-agent-101</a></li>
</ul>
</li>
</ul>
</li>
<li><strong>「誰でもできるvibe-coding」</strong>
<ul>
<li>エンジニア以外の職種の方がAIで機能を実装！顧客解像度の高い人が直接開発できる可能性と、レビュー負荷軽減のためのプロセス改善（仕様レビュー、PR分割）というリアルな試行錯誤が共有されました。</li>
</ul>
</li>
<li><strong>「Codatumで組織サーベイの分析にLLMによる要約を埋め込んでみた」</strong>
<ul>
<li>BigQueryとVertex AIを連携し、SQL関数 <code>ML.GENERATE_TEXT</code> を活用して従業員サーベイの大量の自由記述回答をグループ別に要約。SQLだけで高度なテキスト分析を実現するパワフルな活用事例でした。</li>
<li>Codatumとは
<ul>
<li><a href="https://codatum.jp/">https://codatum.jp/</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h2><strong>LT会を終えて：見えてきた景色と、これからの私たち</strong></h2>
<p>本当に刺激的なLT会でした！</p>
<p>個人的に最も印象的だったのは、「誰でもできるvibe-coding」の発表です。プロダクトやお客様に一番近いメンバーが、AIを使って直接価値を生み出せる。これって、開発のあり方やスピード感を根本から変える可能性を秘めていると感じました。</p>
<p>もちろん、「じゃあ、私たちソフトウェアエンジニアの価値ってどこにあるんだっけ？」という問いも同時に生まれます。AIがコードを書けるようになった今、私たちはより本質的な課題解決や、アーキテクチャ設計、そしてAIを最大限に活用するための環境構築といった領域で、さらに価値を発揮していく必要があるのかもしれません。今回のLT会は、そんなことを考える素晴らしいきっかけになりました。</p>
<p>プレイドでは、**「技術はトレンドを追うためではなく、長期的なインパクトと組織的な再現性を生み出す原動力である」**と考えています。今回のLT会で見られた多様なチャレンジは、まさにその思想を現場レベルで体現しているように感じました。</p>
<p>単に「生成AIが流行っているから使う」のではなく、「<strong>どうすれば顧客への価値提供や、私たちの働き方を本質的に良くできるか？</strong>」という視点で、みんなが主体的にAIと向き合い、試行錯誤を楽しんでいることがわかったイベントでした。</p>
<p>参考</p>
<p><a href="https://blog.plaid.co.jp/n/nb08d947606f3">https://blog.plaid.co.jp/n/nb08d947606f3</a></p>
<h2><strong>おわりに：<strong>プレイド</strong>のAI環境</strong></h2>
<p>実は、あまり大々的には言っていませんが、プレイドでは、エンジニアは <strong>Cursor、Cline、Vertex AI経由の各種モデルといった生成AIツールを、かなり自由に試せる環境</strong>が整っています。これ、個人的にはものすごい「福利厚生」だなと思っていて…（だって、個人で契約したら、日に数万円かかることもありますからね！）</p>
<p><strong>「生産性のための環境投資は死ぬほど安い」</strong> というのがプレイドのエンジニアのマインドセットの一つ。セキュリティには最大限配慮しつつも、これからも価値創出につながる新しい技術は積極的に取り入れていくんだろうな、と感じています。</p>
<p>そんなプレイドでは、一緒に未来のプロダクトを作るソフトウェアエンジニアを絶賛募集中です！</p>
<p>今回のLT会のような、技術への探求心や「やってみよう！」の精神を大切にする環境に興味のある方は、ぜひ採用ページを覗いてみてくださいね。</p>
<p>👉 <strong>プレイド採用ページ：</strong> <a href="https://recruit.plaid.co.jp/product">https://recruit.plaid.co.jp/product</a></p>
<p>最後まで読んでいただき、ありがとうございました！</p>
<p>P.S. このブログ記事も、実はGoogle MeetのGemini議事録とGemini 2.5 Proの力を借りて、構成案から執筆までサポートしてもらいました！</p>


プレイド社内で開催された生成AIのLT会レポート。グループ会社RightTouchも参加し、CursorやVertex AI経由GPT等の活用事例や開発知見を共有。当日の発表をサマリでお伝えします

生成AI、どう使う？ プレイド社内LT会で活用のヒントを探ってみた！

継続的なセキュリティ対策をするために脅威分析をしました

<p>プレイドのエンジニア兼ハンター <a href="https://github.com/algas">@algas</a> です。<br>
この記事では Privacy Sandbox の中でも Web 広告に関連する Edge Computing の技術を紹介します。<br>
Ad Selection (広告の選択) の技術である <a href="https://github.com/michaelkleber/turtledove">TURTLEDOVE</a> と <a href="https://github.com/jkarlin/floc">FLoC</a> が <a href="https://www.chromium.org/Home/chromium-privacy/privacy-sandbox">Privacy Sandbox</a> で提案されています。<br>
この2つは個人を特定するデータをブラウザから送信せずに興味の似ているユーザの大規模なグループに広告を配信する技術です。<br>
TURTLEDOVE はブラウザで広告オークションを行う仕組みで、FLoC はブラウザで広告の興味モデルを学習させるグルーピングの仕組みです。<br>
どちらの技術もブラウザから個人を特定するデータを送らないという目的があります。</p>
<h2>ブラウザから個人を特定するデータを送信したくない3つの理由</h2>
<p>なぜブラウザから個人を特定するデータを送信しない仕組みが必要なのでしょうか？<br>
これには大きく3つの理由があります。</p>
<ol>
<li>
<p>プライバシーの保護<br>
ここ数年で GDPR のように企業が必要以上に個人を特定するデータを集めないようにする世界的な流れがより強まっています。データの取り扱いを正しく行えない企業には厳しい罰則や社会的な批判が強まることは避けれません。不要なデータを企業が持たなければ問題も起こりません。</p>
</li>
<li>
<p>ユーザが自分のデータ利用を制御できない<br>
これまではユーザを同定するためなどにブラウザの Cookie を使っていましたが、最近では情報漏えいを防ぐために Cookie を使わない方針になってきています。Cookie の代替として fingerprinting などの技術が一部の Web サイトで使われています。しかし、これらの技術にはユーザが制御できないという問題があります。個人を特定するデータがブラウザの外に出なければ制御できない対象もなくなります。</p>
</li>
<li>
<p>個人端末やブラウザの性能向上<br>
多くの Web ユーザはスマートフォンのブラウザからサイトにアクセスします。スマートフォンやブラウザの性能は日々向上しているのでサーバで処理しなくてもブラウザ側でできることが増えてきました。ブラウザでデータを処理することができればサーバやネットワークの負荷を減らすことができます。</p>
</li>
</ol>
<h2>技術要素</h2>
<h3>TURTLEDOVE</h3>
<p><a href="https://github.com/michaelkleber/turtledove">https://github.com/michaelkleber/turtledove</a><br>
TURTLEDOVE は Privacy Sandbox が提案するブラウザでの広告オークションの仕組みです。</p>
<p>Web広告の表示に重要な以下の2つのデータがあります。</p>
<ol>
<li>
<p>興味データ<br>
ウェブサイトの訪問者が何に興味を持っているかのデータです。<br>
このデータに基づいてどんな種類の広告を出すか決定されます。</p>
</li>
<li>
<p>アドオークションの勝者<br>
アドオークションというWeb広告のオークションでどの広告を表示するかが決められます。<br>
アドオークションの勝者が広告を出すことができます。<br>
アドオークションの詳細は <a href="https://support.google.com/adsense/answer/160525?hl=ja">広告オークションについて</a> を参照してください。</p>
</li>
</ol>
<p>これまではサイト運営や広告サーバがこの2つのデータを保持していました。</p>
<p>TURTLEDOVE の提案はこれらのデータをサーバではなくブラウザで処理してしまうように変更することです。<br>
ブラウザでデータを処理することによって訪問者のプライバシーを保護することにつながります。<br>
広告主は訪問者の興味に基づいて広告を出すが、他の情報との結びつけができなくなります。<br>
同様にウェブサイトや広告ネットワークは訪問者の興味について学習できません。</p>
<p>TURTLEDOVE は &quot;Two Uncorrelated Requests, Then Locally-Executed Decision On Victory&quot; の略語です。<br>
Two Uncorrelated Requests は「コンテンツ連動広告」と「広告主が特定した興味」の2つのデータを意味しています。<br>
前者は広告を表示するページのURLが含まれているデータ、後者は興味のデータのみで行動履歴と紐付けできないようになっています。<br>
Then Locally-Executed Decision On Victory は勝利した広告をアドネットワークがブラウザに表示することを意味しています。<br>
ただしこの判定はブラウザ内でローカルに実行されてブラウザの外に情報を送ることができません。</p>
<p>サーバからブラウザに広告データの扱いを移行することでプライバシーの保護以外にもメリットがあります。<br>
広告主が &quot;interest group&quot; をどう作って使っているかの透明性を確保できることやグループへの所属時間を制限できることです。<br>
ここで interest group は「広告主やアドネットワークがある種の広告に興味を持っていると信じている」人々の集合のことをいいます。</p>
<p>TURTLEDOVE の目的は主に以下の3つです。</p>
<ol>
<li>
<p>広告効果を改善したい<br>
サイト訪問者が興味を持つ広告を見続けられるようにします。<br>
嫌いな種類の広告を見なくていいようにします。</p>
</li>
<li>
<p>グルーピングの透明性を確保したい<br>
訪問者の興味を広告配信者がなぜ知っているのかに答えられるようにします。<br>
広告のターゲティングを止められるようにします。</p>
</li>
<li>
<p>プライバシーを保障したい<br>
広告主が訪問者の興味について学習できないようにします。<br>
ウェブサイトが interest group について学習できないようにします。</p>
</li>
</ol>
<p>広告が表示される流れは以下のとおりです。</p>
<ol>
<li>ブラウザが interest group に加入する<br>
ブラウザが特定の interest group に一定期間参加するAPIリクエストを広告主が実行します。オリジンはサイト所有者と同じウィンドウかiframeから呼び出されます。</li>
<li>2つの無相関リクエスト<br>
contextual リクエスト<br>
interest group リクエスト</li>
<li>オンデバイスオークション<br>
レスポンスには広告、メタデータ(広告の複数回利用の制限)、ローカル入札のためのオブジェクト、入札関数が含まれます。</li>
<li>オークションに勝った広告を表示する</li>
</ol>
<h3>FLoC</h3>
<p><a href="https://github.com/jkarlin/floc">https://github.com/jkarlin/floc</a><br>
Federated Learning of Cohorts (FLoC) は Privacy Sandbox が提案するブラウザによる興味ベース観測の仕組みです。<br>
企業が個人の閲覧履歴を観測するのに代わって、興味が似ている人々のグループ(cohort or flock)の動きを観測します。</p>
<p>典型的なWeb広告は3つのカテゴリを元に何を出すか決めています。</p>
<ol>
<li>
<p>ファーストパーティーとコンテンツ情報<br>
どのページに広告を出すか<br>
例：「バイクのWebページにこの広告を出そう」</p>
</li>
<li>
<p>広告を見ようとしている人の興味についての一般的な情報<br>
どういう人に広告を出すか<br>
例：「クラシック音楽好きのためのこの広告を見せよう」</p>
</li>
<li>
<p>閲覧者が取った直前の特定アクション<br>
何をした人に広告を出すか<br>
例：「カートに入れた靴のクーポンを出そう」</p>
</li>
</ol>
<p>人々の興味関心はWebの閲覧履歴を観測することで推測できます。もしサーバではなくブラウザで似たような興味関心を持つ人をグループ化できれば、特定の個人の閲覧履歴を集めることなく興味ベースの広告を出すことができるようになります。<br>
この仕組みを実現するのが FLoC です。<br>
FLoC は興味が似ている人々を集めて機械学習でラベルを生成します。このラベルを元にグループ化することで個人的すぎる情報を開示せずに大きなクラスタを形成することができます。<br>
広告配信側にはラベルしか伝わらないのでプライバシーを保護できます。</p>
<p>FLoC のキー(ラベル)をflockと呼びます。flock は短い文字列で表現され数千人で共有されます。個人の閲覧履歴はブラウザで切り離されます。ブラウザはユーザの行動によって flock を更新することがあります。</p>
<p>ブラウザはサイトの訪問履歴に基づくflockを開発するために機械学習アルゴリズムを使います。</p>
<ul>
<li>訪れたサイトのURL、ページのコンテンツなど</li>
<li>Web履歴を含む入力データがブラウザ内にだけ存在して外部にアップロードされないこと</li>
<li>ブラウザは差分プライバシーのような他の匿名化手法も利用することでさらにプライバシーを保護できます</li>
<li>flock の数が十分に小さいことで詳細な情報を運べなくします</li>
</ul>
<h2>関連技術</h2>
<p>TURTLEDOVE と FLoC 以外の技術を簡単に紹介します。</p>
<h3>Federated Learning</h3>
<p>Federated Learning とはエッジコンピューティングで機械学習を行う手法のことです。<br>
一般的な機械学習では大規模な中央サーバにデータを集約してモデルの学習をしますが、Federated Learning ではスマートフォンのような末端の端末でモデルの学習をします。</p>
<p>個人の行動履歴が直接クラウドに送信されず、各端末で学習されたモデルデータのみがクラウドに送信されて共有モデルの改善に使われます。<br>
たとえば Android 向けソフトウェアキーボード GBoard で Federated Learning が使われています。<br>
<a href="https://ai.googleblog.com/2017/04/federated-learning-collaborative.html">https://ai.googleblog.com/2017/04/federated-learning-collaborative.html</a></p>
<h3>差分プライバシー</h3>
<p>差分プライバシー (Differential Privacy) は公開された統計量に対してプライバシーの保護が十分であるかどうかを定義する指標のことです。<br>
差分プライバシーは利用者が持っている背景知識やアルゴリズムに関わらずに統計量のプライバシー安全性を保証します。</p>
<p>なぜ公開された統計量のプライバシー保護には差分プライバシーが必要なのでしょうか。<br>
公開された統計量の閲覧者においては攻撃者と一般データ利用者を区別できないので鍵の共有を使って完全秘匿性を実現することはできません。<br>
攻撃者にも見える形で完全秘匿性を達成すると公開した統計量が無意味(完全なランダムと同じ)になります。<br>
したがって弱い秘匿性の実現が必要となります。<br>
その弱い秘匿性の実現方法の1つが差分プライバシーです。</p>
<p>差分プライバシーには「ε-差分プライバシー」と「(ε, δ)-差分プライバシー」の2つの定義があります。<br>
詳しくは <a href="https://www.jstage.jst.go.jp/article/isciesci/63/2/63_58/_pdf/-char/ja">差分プライバシーとは何か</a> などを参照してください。</p>
<h2>参考文献</h2>
<ul>
<li><a href="https://www.chromium.org/Home/chromium-privacy/privacy-sandbox">https://www.chromium.org/Home/chromium-privacy/privacy-sandbox</a></li>
<li><a href="https://web.dev/digging-into-the-privacy-sandbox/">https://web.dev/digging-into-the-privacy-sandbox/</a></li>
<li><a href="https://github.com/michaelkleber/turtledove">https://github.com/michaelkleber/turtledove</a></li>
<li><a href="https://github.com/jkarlin/floc">https://github.com/jkarlin/floc</a></li>
<li><a href="https://security.googleblog.com/2019/06/helping-organizations-do-more-without-collecting-more-data.html">https://security.googleblog.com/2019/06/helping-organizations-do-more-without-collecting-more-data.html</a></li>
<li><a href="https://blog.chromium.org/2019/08/potential-uses-for-privacy-sandbox.html">https://blog.chromium.org/2019/08/potential-uses-for-privacy-sandbox.html</a></li>
<li><a href="https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html">https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html</a></li>
<li><a href="https://blog.chromium.org/2019/11/making-new-experiences-possible-on-web.html">https://blog.chromium.org/2019/11/making-new-experiences-possible-on-web.html</a></li>
<li><a href="https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html">https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html</a></li>
<li><a href="https://www.blog.google/products/chrome/building-a-more-private-web/">https://www.blog.google/products/chrome/building-a-more-private-web/</a></li>
<li><a href="https://ai.googleblog.com/2017/04/federated-learning-collaborative.html">https://ai.googleblog.com/2017/04/federated-learning-collaborative.html</a></li>
<li><a href="https://federated.withgoogle.com/">https://federated.withgoogle.com/</a></li>
<li><a href="https://www.jstage.jst.go.jp/article/isciesci/63/2/63_58/_pdf/-char/ja">https://www.jstage.jst.go.jp/article/isciesci/63/2/63_58/_pdf/-char/ja</a></li>
<li><a href="https://www.kspub.co.jp/book/detail/1529199.html">https://www.kspub.co.jp/book/detail/1529199.html</a></li>
</ul>
<h2>まとめ</h2>
<p>この記事では PrivacySandbox の中からWeb広告に関する Edge Computing の技術である TURTLEDOVE と FLoC について解説しました。54また関連技術として Federated Learning と差分プライバシーを簡単に紹介しました。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、Webの未来を作りたいエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


Privacy Sandbox, Ad Selection, Web Browser, Edge Computing, FLoC, TURTLEDOVE,  Federated Learning, Differential Privacy

PrivacySandboxにおけるWeb広告のEdgeComputing技術 | PLAID engineer blog

Privacy Sandbox における Web 広告の Edge Computing 技術

<p>こんにちは、エンジニアの <a href="https://twitter.com/tikson">@tik-son</a> <a href="https://twitter.com/kargo113">@kargo</a>  です。02020/06/09 - 2020/06/11 に行われた <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital">Google Cloud Day: Digital</a> に 弊社2名で「Multi Cloud」「ML」というテーマでそれぞれ登壇してきました。</p>
<p>こちらのブログでもその内容を簡単にまとめておきます。</p>
<h1>「Google Cloud Day: Digital 基調講演」</h1>
<p>カスタマー エンジニア 技術部長の佐藤 聖規さんから、Container Based MultiCloud を実現する手段として、我々がAnthos GKE on AWS を利用し始めたことを</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d66e5d06-7109-4834-980c-64e922323ff5/----------2020-06-09-11.14.15-2-------1.png" alt=""></p>
<p>また、Developer Advocate の佐藤 一憲さんからは我々のGCP のML 活用のOverview とKARTE の紹介をして頂きました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b16b0bcb-8ddf-4431-ad58-7ca186d88b42/----------2020-06-09-11.25.17-2------2-1.png" alt=""></p>
<p>そしてKeyNote で取り上げていただいた2つのトピックについて、それぞれ発表してきました。</p>
<h1>「PLAID’s Journey with multi cloud」</h1>
<p>こちらは  <a href="https://twitter.com/tikson">@tik-son</a> よりご紹介致しました。1我々が提供するKARTEは2015年にローンチされ、2016年頃からVm Based MultiCloud になり、現在はContainer Based MultiCloud に取り組んでいるのですが、そのローンチから現在に至るまでのアーキテクチャの変遷をご紹介しました。</p>
<p>Container Based MultiCloud を実現する手段として、<a href="https://cloud.google.com/blog/ja/topics/anthos/anthos-for-aws-is-now-ga">2020 /4/23に発表されたAnthos GKE on AWS</a> の利用を開始しており、発表の中でAnthos GKE on AWS を使ってみての話もしております。</p>
<p>発表については <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital/watch?talk=d1-appdev04">YouTube Live</a> でご覧いただけます。2また、<a href="https://speakerdeck.com/tikson/plaids-journey-with-multi-cloud-10128526-d75f-41de-98ec-27025f8d35a9">SpeakerDeck</a> に資料もアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。</p>
<script async class="speakerdeck-embed" data-id="bdb90a12b7864ba4b5925e5bf7a52d1d" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>「AI Platform で実現する ML Pipeline」</h1>
<p>こちらは <a href="https://twitter.com/kargo113">@kargo</a> よりご紹介致しました。</p>
<p>私たちが実現するコンセプトは、大量のリアルタイムデータからパターンを発見するMLシステムと人にしかできない思考と発想を継続的に統合するEnd-to-EndのML Platformです。</p>
<p>これを実現するにあたり、以下の3つの課題がありました。</p>
<ul>
<li>パイプラインの実行環境の統一</li>
<li>学習環境のスケーラビリティ</li>
<li>継続的インテグレーション</li>
</ul>
<p>この課題をそれぞれ</p>
<ul>
<li>AI Platform Pipeline</li>
<li>AI Platform Training</li>
<li>Github Actions</li>
</ul>
<p>の導入によって解決しました。<br>
さらに、今後の展望として</p>
<ul>
<li>リアルタイム基盤</li>
<li>カスタマイズ性</li>
<li>強化学習基盤</li>
</ul>
<p>を構築し、ML Platform の拡充を図ってまいります。</p>
<p>全ての詳細は <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital/watch?talk=d3-ml05">YouTube Live</a> よりご覧頂けます。3同様にこちらも <a href="https://speakerdeck.com/kargo113/googleclouddaydigital-plaid-mlpipeline-on-aiplatform">SpeakerDeck</a> に資料をアップロードしているのでお急ぎの方はこちらから是非ご覧ください。</p>
<script async class="speakerdeck-embed" data-id="e730d56572474db6832290df749de1be" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>最後に</h1>
<p>今回はcovid-19の影響もあり、オンラインでの登壇となりました。4普段と異なる環境であり、初めは少し戸惑いましたが、ふたをあけてみると、5オフラインでの登壇の時よりも効率的に発表に対する時間を使うことが出来たり、6普段よりも多い800名以上の方にリアルタイムにご覧いただいたり、様々なポジティブな点がありました。</p>
<p>そして、オンライン上の顧客体験を向上させるKARTEを提供する我々としても、この現状を前向きに捉え、さらなる価値を今回登壇の機会を頂いたGoogleさんをはじめとする様々なパートナーの方々と共に提供していきたいと強く感じました。</p>
<p>そんな弊社ではスピード感を持って一緒に開発していく仲間は常に募集しているので、興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！</p>


Google Cloud Day: Digital で「KARTEのMultiCloudアーキテクチャの変遷」と「AI Platform で実現する ML Pipeline」について話してきました

Google Cloud Day: Digital で Anthos と ML について話してきました

Webのプライバシー保護について各社が取り組んでいますが、なかでもGoogleが発表しているのがPrivacy Sandboxです。今回は全体像について読み解きます。

Privacy Sandboxはなにを語るのか - 連載 The Privacy Sandbox | PLAID engineer blog

Privacy Sandboxはなにを語るのか

<p>こんにちは、エンジニアの@tanakoです。</p>
<p>PLAIDでは、CX（顧客体験）プラットフォーム<a href="https://karte.io/">KARTE</a>の機能を iOS / Androidのネイティブアプリから活用できる <a href="https://karte.io/product/app/">KARTE for App</a> のSDK（以降 SDK）をAppチームで開発しています。</p>
<p>さて、Appチームは去る4/7にSDKをOSS化し、ソースコードをGithub上で公開しました 🎉</p>
<ul>
<li><a href="https://github.com/plaidev/karte-ios-sdk">iOSリポジトリ</a></li>
<li><a href="https://github.com/plaidev/karte-android-sdk">Androidリポジトリ</a></li>
</ul>
<p>またOSS化に伴い、SDKをv2（以降 v2）にメジャーアップデートしました。今回は、SDKをOSS化して解決したかった課題や、v2メジャーアップデートの概要、チームとしての取り組みをいくつか紹介します。(この記事は社内勉強会で@wasnotが発表した内容を基に、@tanakoが加筆修正したものです。)</p>
<h2>KARTE for App SDKについて</h2>
<p>前提知識となるSDKについて簡単に説明します。SDKは、イベント送信APIやJavaScriptモジュールを読み込むコンポーネントを内包しており、管理画面で記述されたHTML/CSS/JavaScriptをSDKが管理するWebView（iOSではWKWebView）に読み込むことでアプリ内メッセージを表示できます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24b3914e-72e7-4c6a-a7fe-03abb2acea98/----------0030-12-22-16.27.18-1.png" alt=""></p>
<h2>OSS化の背景</h2>
<p>KARTE SDKは他の一般的な計測SDKと異なり、活用の仕方によっては積極的にアプリのUIに介入できます。また、OSS化以前のv1 SDK（以降v1）はほぼクローズドソースで提供されていたため、自社アプリへの影響を心配する、次のフィードバックがいくつかのクライアントからありました。</p>
<ul>
<li>コードの品質を直接確認できないため導入に不安がある</li>
<li>SDKアップデート時の差分をコードレベルで把握できず影響が読めない</li>
</ul>
<p>これらの不安に対して我々がSDKの品質に問題ないと言ったところで、それを明確に証明する材料はなく説得力も持ちません。</p>
<p>このような<strong>クライアントに安心して利用してもらうため</strong>にも、ソースコードの公開が必要と判断しました。</p>
<h2>OSS化によって提供できる価値</h2>
<p>OSS化するにあたり、利用者に提供できる価値を次のように明文化しました。</p>
<p><strong>安心感の向上</strong></p>
<ul>
<li>SDKの品質に問題がないか確認できる安心感</li>
<li>内部挙動を正確に把握できる安心感</li>
</ul>
<p><strong>信頼性の向上</strong></p>
<ul>
<li>第三者が開発に参加することによる信頼性の向上</li>
<li>多数の開発者の目に触れる（問題のあるコードは速やかに報告され修正されやすい）</li>
</ul>
<p><strong>透明性の向上</strong></p>
<ul>
<li>開発プロセスの見える化</li>
<li>コードの変更経緯が追える</li>
</ul>
<p>これらの価値提供でクライアントの不安は払拭できる一方で、単純にOSS化するだけでは、次に挙げる価値を直接提供することはできません。</p>
<p><strong>OSS化だけでは提供できない価値</strong></p>
<ul>
<li>機能性</li>
<li>拡張性</li>
<li>保守性</li>
</ul>
<h2>OSS化にあたり事前に決めたこと</h2>
<p>えいやでソースコードを公開できれば楽ですが、当然OSS化後も開発は続きます。効果的、効率的にOSSを運用するにあたり次の点を決める必要がありました。それぞれどのような観点で決定したかを紹介します。</p>
<ul>
<li>ライセンスの選定</li>
<li>開発・リリースフローの検討</li>
<li>バージョニングポリシーの変更</li>
</ul>
<h3>ライセンスの選定</h3>
<p>OSSとしてソースコードを公開するにあたり、コードのライセンスについて検討・選定しました。MIT、Apache 2.0、BSDや独自ライセンスなどが候補に挙がりましたが、社内有識者やリーガルチームと相談・議論し、条項の読み合わせを行なった上で、 次の理由で<a href="http://www.apache.org/licenses/LICENSE-2.0">Apache 2.0 License</a>を採用しました。</p>
<ul>
<li><a href="https://opensource.org/">OSI</a>の承認ライセンス</li>
<li>利用率の高さ（非コピーレフトだとMITの次点）</li>
<li>特許紛争に関する特記事項の存在</li>
</ul>
<p>特に特許紛争に関する特記事項が記載されていることはクライアントに安心して利用して頂く上で重要なポイントです。</p>
<p>ライセンスの検討にあたっては、「<a href="https://www.amazon.co.jp/OSS%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E3%81%AE%E6%95%99%E7%A7%91%E6%9B%B8-%E4%B8%8A%E7%94%B0-%E7%90%86/dp/4297100355">OSSライセンスの教科書</a>」を参考にしました。「OSSマトリョーシカ問題（OSS内で利用するOSSが競合するライセンスを持っている状態）」という言葉を知り、事前にSDKが依存するOSSについて精査できたのもこの本のおかげです。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3f5ef028-d97b-4d82-ac79-be19ea1ba4cd/----------2020-04-23-20.04.44.png" /><figcaption>上田 理 (2018)．　OSSライセンスの教科書，図9.2 OSSマトリョーシカ（OSSの中にOSSが入っている）</figcaption></figure>
<h3>開発・リリースフローの検討</h3>
<p>開発中の新機能や特定クライアントのissue等の開示は難しいため、当面はそれらの開発プロセスはPrivateにすることにしています。適切に公開範囲をコントロールするため、開発・リリースフローを次のリポジトリ・CI構成で行うことにしました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/27bdb86e-1762-44f1-8243-e5927af06ea7/----------2020-05-08-18.45.29.png" alt=""></p>
<p>Publicリポジトリではソースコードの公開だけでなく、issueやPRの公開・受付も行います。また、OSS化することを優先したため、当初PRの受付はバグ修正に限定しています。機能追加のPRは受け入れ体制が整い次第少しづつ受け付ける方針としています。体制が整った段階で<a href="https://github.com/plaidev/karte-ios-sdk/blob/master/CONTRIBUTING.md">CONTRIBUTING.md</a>を更新する予定です。</p>
<h3>バージョニングポリシーの変更</h3>
<p>v1では次の運用でバージョンアップを行っていましたが、この運用ではIFに破壊的な変更があるかどうか利用者側から影響範囲が分かりません。</p>
<ul>
<li>微修正はpatchバージョン</li>
<li>機能追加などはminorバージョン</li>
<li>iOS/Android SDKのバージョンは揃える</li>
</ul>
<p>OSS化するv2からは、バージョンアップがアプリケーションに与える影響を把握できるように、<strong>セマンティック バージョニング 2.0.0</strong>（以降 SemVer）に従うことにしました。これにより、バージョンアップが後方互換性を保った変更なのか、破壊的な変更なのか利用者からわかりやすくなります。</p>
<p>また、SemVerでメジャーバージョンの更新条件は自明となりますが、<a href="https://semver.org/lang/ja/#spec-item-7">マイナーレベルのバージョニング</a>の解釈に曖昧な点が残っていました。</p>
<blockquote>
<p>マイナーバージョン Y （x.Y.z | x &gt; 0）は...プライベートコード内での新しい機能の追加や改善を取り込んだ場合は、上げてもよいです（MAY）。その際にパッチレベルの変更も含めてもよいです（MAY）。</p>
</blockquote>
<p>これについては、<a href="https://ja.reactjs.org/docs/faq-versioning.html#minors-versus-patches">Reactのバージョニングポリシー</a>などを参考にチームで議論し次のように決定しています。</p>
<p><strong>緊急性の高い不具合</strong><br>
即修正してリリースしなければならない問題については、patchバージョンを上げてリリースする。この場合は master ブランチから hotfix ブランチを切ってリリースする流れとなる。</p>
<p><strong>緊急性の低い不具合（考慮漏れ・仕様バグなど）</strong><br>
minorバージョンを上げてリリースする。2通常のリリースフローでリリースする流れとなる。</p>
<p>バージョニングポリシーを明確化することで、迷いが減り迅速なリリースが期待できます。</p>
<h2>v2 SDK（メジャーアップデート）で実施したこと</h2>
<p>v1 SDKは、モノリシックなモジュールに多くの機能が詰め込まれており技術的負債が溜まっていました。また、利用者にとっての機能拡張性も十分に提供できているとは言えない状態でした。そのため、OSS化を良い機会と捉え、公開インターフェース及び内部実装の再設計を行い、保守性、拡張性などを高め長期的なSDKの品質維持が容易になるようにv1 SDKに対して非互換なアップデート（v2へのメジャーアップデート）を行う判断をしました。</p>
<h3>モジュール化</h3>
<p>v1では複数の機能が一つのモノリシックなモジュール内に詰め込まれていましたが、v2では各機能単位にモジュールを分割しました。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f2c4b3d6-3f24-464a-b598-409c1ff5f353/----------2020-04-23-15.14.22.png" /><figcaption>モノリシックなv1、機能毎にモジュール分割したv2</figcaption></figure>
<p>モジュール化には次のメリット・デメリットがあると考えましたが、デメリットを加味しても<strong>利用者が要件に応じた必要最低限のモジュールを選択できること、SDKの機能追加や拡張がしやすい状態に保つこと</strong>は非常に重要だと考えました。</p>
<p><strong>モジュール化のメリット</strong></p>
<ul>
<li>要件に必要な機能だけをリンクして利用可能</li>
<li>可読性の向上</li>
<li>バグやデグレの影響範囲分離・回避</li>
<li>機能追加が容易（サードパーティによるモジュール追加も可能）</li>
</ul>
<p><strong>モジュール化のデメリット</strong></p>
<ul>
<li>一部モジュール間連携用のAPI公開が必要</li>
<li>クライアントがどのモジュールをimportするか判断が必要</li>
<li>全モジュール利用時のバイナリサイズは拡大する傾向</li>
<li>リリース等の作業が煩雑化</li>
</ul>
<p><strong>連携の方法について</strong></p>
<p>モジュール分割により、モジュールが完全に独立して動くようになったわけではありません。各機能のモジュールはCoreモジュールに依存しており、Coreとその他のモジュールを連携させるための作業が必要になります。</p>
<p>この連携作業において、ツールによっては明示的な連携コードの実装が必要です。v2では、<strong>より簡単にSDKを導入できるようにモジュールがリンクされていれば自動的に連携</strong>するようになります。具体的にはCoreモジュールに各モジュールをlistenerとして登録し、各イベントを受け取る方式となります。尚、モジュールの自動登録には、各プラットフォームごとの機能を使用しています。</p>
<p><strong>iOSでのモジュール連携内部実装</strong></p>
<p>iOSではクラスがランタイムに追加された時に呼ばれるメソッド(<a href="https://developer.apple.com/documentation/objectivec/nsobject/1418815-load">load</a>)があり、各モジュールのクラスがロードされたタイミングで、Coreモジュールにクラスを登録できます。リンクされたクラスは基本的に全てロードされます。</p>
<pre><code class="language-obj-c">@implementation KRTInAppMessagingLoader

+ (void)load
{
    [KRTInAppMessaging _krt_load];
}

@end

</code></pre>
<p><a href="https://github.com/plaidev/karte-ios-sdk/blob/6bd7e70836b94deb2823d22b7868b917b38d8f1b/KarteInAppMessaging/InAppMessagingLoader.m#L24-L31">Objective-CのloadからSwiftのload用関数を呼び出す</a></p>
<pre><code class="language-Swift">@objc(KRTInAppMessaging)
public class InAppMessaging: NSObject {
    ...
    @objc
    public class func _krt_load() {
        KarteApp.register(library: self)
    }
    ...
 }
</code></pre>
<p><a href="https://github.com/plaidev/karte-ios-sdk/blob/6bd7e70836b94deb2823d22b7868b917b38d8f1b/KarteInAppMessaging/InAppMessaging.swift#L48-L53">Swift側でのモジュールの登録</a></p>
<p><strong>Android (JVM)でのモジュール連携内部実装</strong></p>
<p>JVMは基本的に初期状態ではリンクされたクラスはロードされず、呼び出し時に初めてロードされるため、iOSと同じアプローチは使えません（lazy load）。</p>
<p>JVMのClassLoaderにはリンクしたjar内の決められたファイルを参照する仕組みがあり、そちらを利用することで動的にリンクされたモジュールのロード・登録が可能です。</p>
<pre><code class="language-kotlin">val libraries = ServiceLoader.load(Library::class.java)
libraries.forEach { library -&gt;
    register(library)
    library.configure(self)
}
</code></pre>
<p><a href="https://github.com/plaidev/karte-android-sdk/blob/0e74ddf40b17d253e658ea69b337a5ee1f74f937/core/src/main/java/io/karte/android/KarteApp.kt#L238-L243">ServiceLoaderを使用したモジュールの登録</a></p>
<h3>開発言語の変更</h3>
<p>iOS / Android共に、メインの実装言語を各プラットフォームのよりモダンな言語に変更しました。iOSは Objective-C から Swiftへ、Androidは JavaからKotlinに変更しています。</p>
<p>言語変更のメリットを次のように考えています。</p>
<ul>
<li>可読性の向上</li>
<li>言語の安全性向上</li>
<li>メンテナンス性の向上</li>
<li>言語背景が（ある程度）似ているため、今までよりもプラットフォーム間の共通点が多い</li>
</ul>
<p>一方デメリットは次の通りです。</p>
<ul>
<li>自由度の低下（安全性とトレードオフ）</li>
<li>バイナリサイズの膨張や呼び出しコスト増大</li>
<li>レガシーな開発環境のアプリでは、余計なものが増えてしまう</li>
</ul>
<p>デメリットはレガシーな開発環境に限定されており、近年では完全にレガシーな環境のアプリは少ないと判断しました。</p>
<p>また、PLAIDではチームやプラットフォームの垣根なくコードを書くことが多いため、<strong>言語仕様が（ある程度）近いことによるメリットは大きい</strong>と感じています。</p>
<h3>リファレンス自動生成</h3>
<p>v1では、Developer Portal（Karteを利用する開発者向けのドキュメント置き場）のAPIリファレンスを、手動でメンテナンスしていました。</p>
<p>この方式は更新漏れでコードとドキュメントに乖離が生じやすい上に、バージョン毎の対応関係もわからずメンテナンスコストが高い状態でした。</p>
<p>v2からは、ドキュメンテーションコメントをソースコード内に記載し、<strong>リファレンスを自動生成することで、コードとドキュメントの乖離が起きにくくしました</strong>。iOSは<a href="https://github.com/realm/jazzy">realm/jazzy</a>、Androidは<a href="https://github.com/Kotlin/dokka">Kotlin/dokka</a>でドキュメントを生成しています。</p>
<p>また、バージョン毎にリファレンスが生成されるようになり、対応関係がより明確になりました。リファレンスは<a href="https://github.com/plaidev/karte-sdk-docs">GitHubのリポジトリ</a>にPushして、<a href="https://plaidev.github.io/karte-sdk-docs/ios/latest/KarteCore/">iOS</a> / <a href="https://plaidev.github.io/karte-sdk-docs/android/core/latest/">Android</a>ともにGithub Pagesを利用して公開しています。</p>
<p>v2では、ここで紹介した他にも、<a href="https://developers.karte.io/docs/support-policy-ios-sdk-v2">サポートポリシー</a>の刷新や新機能追加などを多く盛り込みました。興味があるかたは、ぜひ<a href="https://developers.karte.io/docs/release-notes-ios-sdk-v2">リリースノート</a>をご覧ください</p>
<h2>OSS化とv2リリースを同時進行したことによる効果</h2>
<p>v2へのメジャーアップデートとOSS化を同時にリリースしたことで、結果として「OSS化だけでは提供できない価値」である「機能性」「拡張性」「保守性」を付与できました。</p>
<p>これにより「<strong>SDK利用者の開発体験</strong>」全体を向上させることができインパクトのあるリリースになったのではないかと考えています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24a49205-2570-45b6-97ae-57a40d569e89/----------2020-04-23-23.38.32.png" alt=""></p>
<h2>おわりに</h2>
<p>簡単にSDKをOSS化した背景、v2アップデートの概要、チームで取り組んだことを紹介しました。</p>
<p>まだまだ、OSS運用のノウハウは溜まっておらず、英語のみでのメンテナンスや、他開発者とのコラボレーション方法の整備に関してもスタート地点であり、その他にも多くの課題が残っています。</p>
<p>引き続き、透明性が高く開発者が安心して使えるSDKを提供するために改善を続けていきたいと思います。</p>


OSSのライセンス、バージョニング、リリースフローの検討と背景、v2メジャーアップデート

KARTE for App SDKのOSS化によるDeveloper Experience向上への取り組み

BigQueryのリソース配分最適化のため、プロジェクトへのコミットメントの割り当てパターンや、スロット消費の多いクエリの見つけ方などについて調査した結果をまとめてみました

6,000スロットを使うBigQueryのリソース配分最適化への挑戦

GitHub Actions を使って継続的ローカライゼーションをスクラッチから構築した話 | PLAID engineer blog

GitHub Actions を使って継続的ローカライゼーションをスクラッチから構築した話

npmのprivate registryからGitHub Packages Registryに移行する

Dockerfile効率化のベストプラクティスを、リードタイム(CI/CDの実行時間)を短縮し開発生産性を向上させる為に行うべき事という観点でまとめました。
1.Docker Daemonへの転送ファイル削減
2.Docker Imageのサイズ削減
3.cacheの有効活用

Docker Buildにおけるリードタイム短縮のための3つの改善ポイント | PLAID engineer blog

Docker Buildにおけるリードタイム短縮のための3つの改善ポイント

2019年10月から2020年2月まで開発チームで取り組んだアンケートフォーム(β版)のリリースまでのリアルな道のりを記しています。エンジニア、デザイナー、プロダクトマネージャーにはぜひ読んで欲しい内容です。

KARTEのアンケートフォーム(β版)公開までの道のり

Engineer Blog

Recent Article