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://twitter.com/kargo113">@kargo</a> @nichimu です。KARTEのDatahubというプロダクトに携わっており、KARTEのデータ及びお客様のデータを活用したプロダクトの開発を行っています。<br>
今回は、KARTEにおいて活用しているコンテナネイティブのワークフロー基盤であるKubeflow Pipelineの組み込みについての概要をご紹介したいと思います。</p>
<h1>Kubeflow とは</h1>
<p>ここ数年でMLOpsという言葉が浸透するようになり、機械学習の実運用についての具体例がたくさん見受けられるようになりました。<br>
<a href="https://www.kubeflow.org/docs/about/kubeflow/">Kubeflow</a> はそのような機械学習の実運用をスムーズに行うためのオープンソースのプラットフォームです。Kubernetes上で動作することを前提とされているので、GKEやEKS、オンプレミスのKubernetes基盤にデプロイすることができます。直近では最新のv1.0が公開されているようにかなりのスピードで発展してきており、コミュニティも盛んです。<br>
Kubeflowは様々な機能がありますが、今回はその中でも Kubeflow Pipeline というコンテナのワークフロー基盤を活用した事例についてご紹介していきます。<br>
Kubeflow Pipelineの基本的な使い方についてはそれだけで1つのブログが書けるボリュームですので、以下の内容では使い方については触れません。それを前提とした上で、活用方法について述べていきます。基本的な使い方は<a href="https://www.kubeflow.org/docs/about/kubeflow/">ドキュメント</a>がわかりやすいので是非ともご参考にして頂ければと思います。</p>
<h1>Components について</h1>
<p>弊社では、KARTEに蓄積されたデータを用いて、クラスタリング・需要予測・レコメンデーション・購買予測・不正検知など様々な取り組みを行っています。<br>
Kubeflow Pipelineで動かすPipelineは大きく分けて</p>
<ul>
<li>学習用パイプライン</li>
<li>推論用パイプライン</li>
</ul>
<p>の2つがあります。これらを各タスクごとに管理しています。</p>
<p>各タスクごとにコンポーネントはなるべく共通化したく、<a href="https://www.tensorflow.org/tfx">TFX</a> の概念を大いに参考にさせて頂きました。TFXは機械学習タスクに必要なコンポーネントが丁寧に抽象化されており、今回は以下の図のようなコンポーネントを参考にしました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2149e535-f318-4b6a-ba94-70c8adc5bb2d/tfx.svg" alt=""></p>
<p>実際に学習用パイプラインで構築したコンポーネントは</p>
<ul>
<li>ExampleGen</li>
<li>SchemaGen</li>
<li>Transform</li>
<li>Trainer</li>
<li>Evaluator</li>
<li>Pusher</li>
</ul>
<p>の6つです。</p>
<p>ExampleGenでは、BQにある膨大なデータからクエリによりデータを抽出<br>
SchemaGenでは、抽出したデータのスキーマを自動で判定<br>
Transformでは、LabelEncorder等により前処理を実行<br>
Trainerでは、GridSearch等を用いて最適なモデルの学習<br>
Evaluatorでは、学習済モデルの評価を行い、モデルの妥当性を検証<br>
Pusherでは、評価されたモデルをデプロイする<br>
といった実装になっています。<br>
これらをPipelineとして単純に直列に以下の図のように繋いでいます。<br>
各コンポーネントでのデータの受け渡しはGCSを用いており、データのPATHを受け渡すようにしています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5ae769ac-5242-4cba-a50c-a349015431de/kubeflow-1.svg" alt=""></p>
<p>推論パイプラインでは、<br>
ExampleGen, SchemaGen, Transformerまでは同様で、これにデプロイしたモデルを用いたPredictorというコンポーネントを直列に繋いで推論を行っています。</p>
<p>また、直列で繋いでいる理由として大量のリソースを消費するものに関しては、各コンポーネント内で外部にジョブを投げているからです。</p>
<p>例えば、ExampleGenにおいてはApache Beam SDKを用いて実装しているので、大規模分散処理に関してはDafaflow上で実行することが可能です。さらに、Trainerにおいても、学習ジョブはAI Platform Trainingで実行しているため、こちらも大規模並列学習が可能になっています。<br>
つまり、Kubeflow Pipelineをデプロイしているクラスタのリソースは最小で、必要に応じて外部のマネージメントサービスを活用することで、簡単なタスクから複雑なタスクまで幅広く対応できるようになっています。</p>
<h1>Pipelines SDK の活用</h1>
<p>Kubeflow Pipeline には <a href="https://www.kubeflow.org/docs/pipelines/sdk/sdk-overview/">Pipeline SDK</a> と呼ばれるものも用意されており、外部からでも簡単にパイプラインの実行や管理ができるようになっています。これを活用しフロントエンドと連携をしています。<br>
例えば、</p>
<pre><code>client = kfp.Client(
    host=&quot;YOUR_KUBEFLOW_HOST&quot;, 
    client_id=&quot;OAUTH_CLIENT_ID&quot;
)
res = client.run_pipeline(
    experiment_id=&quot;YOUR_EXPERIMENT_ID&quot;,
    job_name=&quot;JOB_NAME&quot;,
    pipeline_id=&quot;PIPELINE_ID&quot;,
    params=&quot;ARGUMENTS&quot;,
)

</code></pre>
<p>といったように指定したパイプラインの実行ができます。<br>
paramsに任意の引数を渡すことで柔軟にパイプラインの実行が可能です。</p>
<p>wait_for_run_completionやget_runメソッドも用意されているので、パイプラインの実行状況を確認することも容易です。</p>
<p>補足ですが、私たちの環境ではCloudIAP認証を用いているため、client_idが必要です。また、実行するサービスアカウントにIAP で保護されたウェブアプリ ユーザーという権限を付与する必要がある点にも注意が必要です。</p>
<h1>フロント画面との連携</h1>
<p>KARTEの管理画面で使用している技術を簡単に述べると、フロント: Vue.js、バックエンド: Node.js、DB: MongoDBで構成されています。<br>
管理画面から任意のパラメータを入力し、Kubeflow Pipelineのパイプライン処理を実行をさせた上で、モデルの結果はいつでも管理画面から取得できる状態にしたいというのが今回の要件です。</p>
<p>現状、Pipeline SDKにはpythonのものしかなく、バックエンドがNode.jsであるKARTEで使おうと思うと、Node.jsにあるPython-shellを使用するかFlask等を使ってRESTの口をつくるかの2通りありました。<br>
その中で、我々は、新たにPythonベースのコンテナをGKEに立てて、Node.jsベースのコンテナとkubeflow clusterの橋渡しとなるようなinternalなAPIとして用いる方針をとりました。<br>
PythonベースのコンテナでPipeline SDKを使えるようにすることで、KARTE管理画面からKubeflow Pipelineを実行できるようにしました。</p>
<p>また、PipelineのジョブパラメータはMongoDBに保存しておくことで、いつでもKARTE管理画面からジョブの実行結果を確認できるようにしました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f84d0fa8-a21d-4fd4-8975-c8d3c24297d7/backend.png" alt=""></p>
<p>このようにKARTEの管理画面からも簡単に任意のパラメーターでパイプラインを実行し、結果を取得することが可能です。</p>
<p>こういったSDKもきちんと用意されており、連携も簡単にできる点も素晴らしいですね。</p>
<h1>今後の課題</h1>
<h4>サービスアカウント問題</h4>
<p>現状のKubeflow Pipelineの仕組みではパイプラインをKubeflowにデプロイする段階でSecretをコードで指定する仕組みになっています</p>
<pre><code>dsl.ContainerOp(
    name=&quot;NAME&quot;,
    image=&quot;IMAGE&quot;,
    command=[&quot;COMMAND&quot;],
    arguments=[&quot;ARGUMENTS&quot;],
)
.apply(gcp.use_gcp_secret(&quot;user-gcp-sa&quot;))

</code></pre>
<p>そのため、実行するパイプラインごとに引数等でサービスアカウントを指定することができません。こちらも柔軟に変更できた方が権限管理は非常に便利になるのですが、現状は未対応なので場合によっては裏側で色々と権限管理を頑張る必要性が出てきます。</p>
<h4>Kubeflow? TFX? AIPlatform?</h4>
<p>少し余談にはなりますが、このあたりきちんと使い分けられている方は少ないのではないでしょうか。<br>
Kubeflowはドキュメントにしたがってデプロイするとやや大きめなMachineTypeでNodePoolが作成され、GPU Node Poolも作成されます。つまり、このクラスタ内のリソースを使うのだろうと思っていたのですが、exampleを見ると Data Proc や AI Platform にジョブを投げているものもあります。さらに、TFXではTensoflow Transformerというものがあり、これはDataFlowにジョブを投げるものとなっています。こうなってくるとかなりややこしく、結局どういう構成がベストプラクティスなのかが見えづらい状況です。<br>
あくまで私たちの仕組みでは、Kubeflow Pipeline自体のリソースは最小限に、コンポーネントの各ジョブは外部リソースを使ってスケールさせるという選択肢をとったに過ぎないので、この内容がみなさまの実際のケースに沿って最適な選択の一助となれば幸いです。</p>


KARTEにおけるフロントエンドと連携させたKubeflow Pipelineの活用方法について解説します

KARTEにおけるKubeflow Pipelineの活用 | PLAID engineer blog

KARTEにおけるKubeflow Pipelineの活用

2019年以降、Slack APIがどのように変化し何に注意すべきかについてご紹介します。主にBlock Kit、Modal、Home tabなどSlack上での新しい表現や、Granular permissionsと呼ばれる新しい権限モデルへの対応方法について詳しく説明しています。

2020年のSlack App開発者が知るべき最新のSlack API仕様 | PLAID engineer blog

2020年のSlack App開発者が知るべき最新のSlack API仕様

<p>こんにちは、エンジニアの <a href="https://github.com/komukomo">@komukomo</a> です。2020/01/30 に行われた <a href="https://inthecloud.withgoogle.com/anthos-day-2001/register.html">Google Cloud Anthos Day</a> に 「GKEにおけるセキュリティ対策と運用」というタイトルで登壇させていただいので、こちらのブログでもその内容を簡単にまとめておきます。（他の登壇者の方の資料も<a href="https://inthecloud.withgoogle.com/anthos-day-2001/register.html">公式サイト</a>にて公開されています）</p>
<hr>
<p>我々が開発している <a href="https://karte.io/">KARTE</a> ではユーザの行動データを扱っており、その中にはセンシティブなデータも含まれているので KARTE を開発する上ではセキュリティというのは重要なトピックです。ということで今回お話したのはセキュリティに関する内容で、直接プロダクトの KARTE とは関係ないのですが、</p>
<ul>
<li>GKE でのセキュリティに関する考え方</li>
</ul>
<p>と、個別機能の紹介とユーザ目線での注意点や感想ということで</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/sandbox/">GKE Sandbox</a></li>
<li><a href="https://cloud.google.com/binary-authorization/">Binary Authorization</a></li>
<li><a href="https://cloud.google.com/anthos/config-management/">Anthos Config Management</a></li>
</ul>
<p>について発表してきました。内容としては、これからGoogle Kubernetes Engine (GKE) を導入しようとしている方や運用しはじめの方、機能の概要を知りたい方向けのお話となっています。</p>
<p>こちらにスライドとざっくりお話した内容を載せておきます。</p>
<script async class="speakerdeck-embed" data-id="b9e34200315a473fae23b66f07ca4168" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>GKEにおけるセキュリティ対策</h1>
<p>最初のトピックは GKE でのセキュリティ対策の話で、中身を省いて結論のみ書いてしまうと、</p>
<ul>
<li>ユーザの管理範囲と Google の管理範囲を意識しましょう</li>
<li>まずは GKE 公式のドキュメントにそって運用していきましょう</li>
</ul>
<p>ということで基本的すぎる感じになってしまいましたが、それでも重要なことだとは思うので、ここにも当日紹介したドキュメントのリンクを貼っておきます。</p>
<p>GKE の記事:</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/concepts/security-overview">Security overview</a></li>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster">Hardening your cluster's security</a></li>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/security-bulletins">Security bulletins</a></li>
</ul>
<p>こちらは GKE に限らず、Kuberentes の記事:</p>
<ul>
<li><a href="https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/">9 Kubernetes Security Best Practices Everyone Must Follow</a></li>
<li><a href="https://kubernetes.io/blog/2016/08/security-best-practices-kubernetes-deployment/">Security Best Practices for Kubernetes Deployment</a></li>
</ul>
<p>以降は個別の GKE の機能のお話です。</p>
<h1>GKE Sandbox</h1>
<p><a href="https://cloud.google.com/kubernetes-engine/sandbox/">GKE Sandbox</a> は、信頼できないワークロードをクラスタで動かすようなケースで有用な機能です。<br>
内部では <a href="https://gvisor.dev/">gVisor</a> が使われていますが、この仕組みは使う前にざっくりとでも中身を知っておくとといろいろと判断する上で役に立ちます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/69ebe27d-0498-4443-96bb-bc1888ce20d6/Screen-Shot-2020-01-31-at-13.11.04.png" alt="Screen-Shot-2020-01-31-at-13.11.04"></p>
<p>gVisor では kernel の System Call をインターセプトして、kernel の機能を emulation するようなレイヤを実装しています。（さらっと書きましたが、なかなか凄まじい実装です。コードは<a href="https://github.com/google/gvisor">こちら</a>。）<br>
このようなレイヤを実装することで、コンテナは System Call を直接実行できなくなり、Host はセキュリティを考慮して制限された System Call のみ処理するようになるので、kernel の脆弱性を悪用するような攻撃から Host を守ることができます。</p>
<p>この gVisor をGKE上で使えるようになっているのが、 GKE Sandbox です。</p>
<h2>注意点</h2>
<p>使用する上で気をつけておくとよさそうと感じたのは、互換性、パフォーマンス、gVisor の責任範囲についてです。</p>
<h3>互換性</h3>
<p>kernel の機能を emulation している部分があるので、そもそも使いたい機能が使えるかはまず確認しておくとよいかと思います。GKE Sandbox にも gVisor にも互換性に関するドキュメントがあるので両方読んでおくと確実かと思います。</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods?hl=en#limitations-incompatible">(GKE Sandbox) Incompatible features</a></li>
<li><a href="https://gvisor.dev/docs/user_guide/compatibility/">(gVisor) Compatibility</a></li>
</ul>
<p>自分は GKE Sandbox を最初試したとき <a href="https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/">Port Forward</a> が使えないということを知らずにデバッグしようとしていて、無駄に調査に時間をかけてしまいました😅</p>
<h3>パフォーマンス</h3>
<p>こちらもgVisorがSystem Callをemulationしているため gVisor を使うとそのワークロードのパフォーマンスが劣化する可能性があります。逆にいうと、System Call を激しく使わない数値計算のようなワークロードはそれほど影響はないと考えられます。<br>
実際に GKE Sandbox を使う場合にはもちろんその時に計測するかと思いますが <a href="https://gvisor.dev/docs/architecture_guide/performance/">gVisor のPerformance Guide</a> もあるのでこちらも参考になるかと思います。</p>
<h3>gVisorの責任範囲</h3>
<p>仕組みをしっていれば当たり前の話かもしれませんが、gVisor を使えばサンドボックス化は完璧、というものではありません。例えば Pod 間通信の制御をするなら別途設定が必要です。自社でサンドボックスのような基盤が必要なサービスを運用する場合は、gVisor の挙動を把握した上で適宜必要なレイヤーの制限をかけていく必要があります。<br>
gVisor がどのような目的で作られ、どのような脅威を軽減するのかについては <a href="https://gvisor.dev/docs/architecture_guide/security/">Security Model</a> に詳しく書かれています。</p>
<h1>Binary Authorization</h1>
<p>次の話は<a href="https://cloud.google.com/binary-authorization/">Binary Authorization</a>。こちらは信頼できるイメージのみがデプロイされることを保証できる機能です。クラスタでBinary Authorization を有効にすると、Pod 作成の前に Policy のチェックが入ります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/66682698-9e64-4edf-8df2-0d15a91021ce/Screen-Shot-2020-01-31-at-13.35.02.png" alt="Screen-Shot-2020-01-31-at-13.35.02"></p>
<p>Policy の設定としては image の Path のホワイトリストの他、 <a href="https://cloud.google.com/binary-authorization/docs/making-attestations">attestation</a> という概念があるので、信頼できる検証者によって検証されたイメージのみ許可、といった設定が可能です。（※発表スライド内では&quot;署名&quot;と書いてしまっていますが、英語では attest なので多分&quot;証明&quot;、&quot;検証&quot;という訳の方が正しいですね。）</p>
<p>設定可能な <a href="https://cloud.google.com/binary-authorization/docs/policy-yaml-reference">Policyの仕様</a> はとてもシンプルなので、ざっと<a href="https://cloud.google.com/binary-authorization/docs/example-policies">設定例</a> と合わせて読めばすぐに把握できるかと思います。</p>
<p>運用時は、いろいろと例外的な状況も発生するかと思いますが、Dry Run（Policyチェックしてログは出すが制限しない）や、Break Glass（ Policy を無視してデプロイできるようにするannotation）という機能もあり、こういった運用時の考慮もされています。</p>
<h2>注意点・感想</h2>
<p>Binary Authorization の注意点としては、PolicyはGCPのプロジェクトごとで、クラスタごとの設定はある程度できるのですが Namespaceごとの細かい設定はできません。そのため、大きなクラスタで複数チームを Namespace で管理している場合は Policy 設定が難しいかもしれません。</p>
<p>ちなみに Mercari さんではGKEのBinary Authorizationではなく、その内部で使われている<a href="https://github.com/grafeas/kritis">kritis</a> を<a href="https://tech.mercari.com/entry/2019/12/23/084839">自社でフォークして使用している</a>とのことです。</p>
<p>また、「何かを強制する」機能全般に言えることですが、Dry Run や Break Glass の機能があるとはいえ、管理するProjectが大きくなればなるほど導入が大変になるものです。（有効化したものの全対応が難しくいつまでたっても dryrun 状態...のように）<br>
導入するつもりなら早めに、迷っているなら修正が難しくなる前に判断するのがよいかと思います。</p>
<h1>Anthos Config Management</h1>
<p>最後に<a href="https://cloud.google.com/anthos/config-management/">Anthos Config Management</a> （以下、ACM）。こちらは、セキュリティというよりは運用の話ですが、Namespace や RoleBinding など様々な設定を管理するための機能です。</p>
<p>ACMはいわゆる <a href="https://www.weave.works/blog/what-is-gitops-really">GitOps</a> で クラスタの設定管理をするツールで、クラスタに ACM のオペレータを入れておくと、そのオペレータが指定した Git Repository と同期し設定をクラスタに反映してくれます。（ちなみに、とくに管理可能なオブジェクトの制限は今の所ないようで Namespace や RoleBinding だけでなく、Deployment や Service でも同期してくれます。そのため ACM でアプリケーションのようなものもデプロイ可能ですが、反映の順序は考慮されないそうなのであくまでも設定系のオブジェクトのみにしておいた方が良さそうです。）</p>
<p>単一クラスタ、単一 Namespace しか扱っていない場合はさほどありがたみはないかもしれませんが、複数クラスタ、Namespace を運用していて、似たようなポリシーを全体に適用したいケースなどに有用かと思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24dbe497-853a-4a1a-8f86-e14c60707833/Screen-Shot-2020-01-31-at-13.35.41.png" alt="Screen-Shot-2020-01-31-at-13.35.41"></p>
<p>Git Repository との同期だけであればその他の <a href="https://fluxcd.io/">flux</a> や <a href="https://argoproj.github.io/">argo</a> などでも可能かとは思いますが、ディレクトリの階層構造でNamespace に階層構造のようなものを持たせられる、という点は特徴的です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/13096746-712c-4544-b2bb-5a1dcdd9754b/Screen-Shot-2020-01-31-at-13.35.49.png" alt="Screen-Shot-2020-01-31-at-13.35.49"></p>
<p>例えば ACM で管理するポリシーの Repository を上の図のようなディレクトリ構成（緑は何らかのk8sオブジェクトのyaml、オレンジは Namespace の yaml とします）にした場合、Namespace が3つ (audit, service-a, service-b) 作成され、<code>all-policy</code> は全てのNamespace に反映、<code>app-policy</code>は <code>service-a</code>と<code>service-b</code>の Namespace にのみ反映、といった挙動になります。</p>
<p>ちなみに ACM の他にも、こういった階層構造を使うというアイデアはあるようです。<br>
https://github.com/kubernetes-sigs/multi-tenancy</p>
<h2>感想</h2>
<p>ACM は仕組みも動作もシンプルなので、Anthos を使っていてクラスタ、Namespace が複数あるような環境ならば入れておいて特に損はなさそうかなと感じました。ACM の導入についても、既に多くのクラスタにいろいろな設定をいれて管理していたとしても、ACM 管理用の repository に対象のyamlを入れてそのオブジェクトが管理対象になる（ <code>configmanagement.gke.io/managed: enabled</code> という annotation がつきます）のを待つだけなのでそこまで大変ではなさそうです。</p>
<h2>Policy Controller</h2>
<p>ACM の基本的な機能は以上なのですが、追加オプションとして、 <a href="https://cloud.google.com/anthos-config-management/docs/concepts/policy-controller">Policy Controller</a> という機能もついており、こちらは <a href="https://github.com/open-policy-agent/gatekeeper">Gatekeeper</a> を使ったポリシーの Enforcer です。（ACM の機能とは全く別機能のような気がしますが、現状 ACM の中の機能として提供されていたのでおまけとして紹介しています。）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0099943d-6ac9-4d92-aa5f-74580eafe43e/Screen-Shot-2020-01-31-at-14.49.23.png" alt="Screen-Shot-2020-01-31-at-14.49.23"></p>
<p>例えば <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/">PodSecurityPolicy</a> の場合は、「特権コンテナ禁止」といった特定の条件の制限ができるかと思いますが、こちらは任意の Kind の field をチェックできるため柔軟に設定をすることが可能です。公式の例では、Ingress の domain に重複がないか、Namespace に特定の prefix がついているか、などをチェックするサンプルがありました。</p>
<p>何をどう制限するか、というのは <a href="https://www.openpolicyagent.org/docs/latest/policy-reference/">Rego</a> という言語で書くことになるのですが、<a href="https://cloud.google.com/anthos-config-management/docs/how-to/creating-constraints-and-templates">よく使うテンプレートは予め用意されている</a>ので Rego を知らなくてもある程度使うことができます。</p>
<h1>最後に</h1>
<p>Google Cloud Anthos Dayで話したGKEのセキュリティとその周りの機能の紹介でした。Kuberentes も GKE でも次々と新機能がでてくるので追っていくのは大変ですが、全てのユースケースで必要なものではないものも多いので、しっかりそれぞれの機能を把握した上で適切に運用していきたいですね。</p>
<hr>
<h1>おまけ</h1>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c94b1c36-a2d1-45ee-ae26-2b5bd16a8c2f/anthosday-plaid.jpg" alt="anthosday-plaid"><br>
<a href="https://github.com/MasayaAoyama">@amsy810</a> さんに撮っていただいた写真。ありがとうございます👍</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/aab76dea-068f-413c-832b-cfdbaa6baac5/20200130A_L260.jpg" alt="20200130A_L260"><br>
こちらは Google Cloud Anthos Day 後の懇親会。Googler、登壇者、スポンサー、様々なAnthos/k8sな人たちと話しました。これからのさらなる盛り上がりを感じたとともに、我々もどんどんアップデートしていかないとと感じました！...ということで、スピード感を持って一緒に開発していく仲間は常に募集しているので、興味のある方は<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>


2020/01/30 に行われた Google Cloud Anthos Day に 「GKEにおけるセキュリティ対策と運用」というタイトルで登壇させていただいので、こちらのブログでもその内容を簡単にまとめておきます。

Google Cloud Anthos DayでGKEのセキュリティ対策と運用について話してきました | PLAID engineer blog

Google Cloud Anthos DayでGKEのセキュリティ対策と運用について話してきました

<p>こんにちは。プレイドで2019年8月から現在までDevインターンとして働いている大矢です。2020年4月からは正社員として働く予定です。<br>
この記事では、プレイドのインターンでどんなことをしたか、何を学んだか、そして入社を決めた理由について書いていきたいと思います。</p>
<h1>はじめに</h1>
<p>簡単に自己紹介をします。僕は大学では情報工学を専攻していて、自然言語処理の研究をしています。<br>
2019年の8月からプレイドでインターンを始めて、週4日程度で通い、今月で約半年になります。<br>
プレイドでインターンをする以前にも、他社のインターンでWebアプリの開発をしたり、自然言語処理の技術を使った開発をする機会は何度かありました。研究が落ち着いた頃、開発経験を積みたいと思いインターンを探していました。</p>
<h1>インターンを始めるまで</h1>
<p>プレイドのインターンの求人（ <a href="https://www.wantedly.com/projects/387546">https://www.wantedly.com/projects/387546</a> ）には</p>
<ul>
<li>求められるレベルが非常に高い</li>
<li>圧倒的に成長できる</li>
<li>社員と同じチームで働くことができる</li>
</ul>
<p>というように書いてあり、求められるレベルが非常に高いことにビビりつつも、ちょっと背伸びした環境にいたほうが成長できるということはなんとなく知っていたので、面接を受けてみることにしました。面接では、プレイドのインターンの制度について聞いたのが印象に残っています。<br>
プレイドに参加したインターン生は、インターン担当の社員、メンターと数ヶ月おきに面談を行います。面談までの期間の成果や働き方をみて、継続が難しいと判断された場合には契約の更新が行われない場合がある、というものです。<br>
最初は戸惑いましたが、この制度はとても良いものだと思いました。まず、求人に書いてあった「求められるレベルが非常に高い」「圧倒的に成長できる」に対する説得力が格段に上がりました。求人にこのようなことを書いてある会社は他にもありますが、この会社で働けば確実に成長できるなと感じました。<br>
また、自分にとっても良い刺激になるなと考えました。3ヶ月おきに評価があるため、それまで気が緩むことなく常に全力で働ける。そして契約の更新が行われた場合には、一定の自信になりますし、更新が行われなかった場合にも、学生なので生活に困るということはないし、挫折を味わうことで成長につながるのではないかと思いました。<br>
つまり、インターン生にとってもこの制度はプラスだと思い、インターンに参加することを決めました。</p>
<h1>インターンでやった仕事</h1>
<p>プレイドでは、エンジニアのチームは1チーム1〜5人程度に分かれ、そのチームで2〜3ヶ月の期間（フォーカスと呼びます）目標を立てて開発をしていきます。僕は、入社してから1ヶ月間はAPIチームというチームで働いていたのですが、フォーカスの区切りのタイミングで基盤チームというところを希望し、行かせてもらうことができました。<br>
それぞれのチームでやった仕事について紹介したいと思います。</p>
<h3>APIチームでの仕事</h3>
<p>インターンに参加して初めに与えられたタスクは、KARTEが提供する、開発者向けのAPIを開発するというものです。社員が取り組むような実践的で非常にやりがいのある仕事であると同時に、このタスクに関してはほとんど仕様が決まっていなかったので、僕にとってはチャレンジングな仕事でした。また、Node.js や Mongo DB についても全く経験がなかったため、技術的にも初めての状態でした。<br>
実際に取り組み始めてみると、そもそもKARTEのことをもっと知らないと、仕様を決めることもできないと感じました。以前に参加したインターンでは、仕様が決まったタスクが渡されることがほとんどだったので、そのプロダクトについて詳しくなくても、ある程度はできてしまうものでした。<br>
KARTEについて学ぶには、KARTE Dojo という、わかりやすい動画が用意されています。僕はその動画を見て、KARTEとはどんなもので、どういう機能がよく使われているのかということを理解しました。とは言っても、実際のユーザがどのように使っているか、APIにどのようなニーズがあるかまではわからないので、社員と相談しながら仕様を決めていきました。<br>
結果的に、無事に1つのAPIの実装を終えることができました。</p>
<h3>基盤チームでの仕事</h3>
<p>ちょうどフォーカスの区切りの頃、モノリシックなKARTEのシステムをマイクロサービス化するということを主に行なっているチーム（基盤チーム）があり、僕はとても興味を惹かれたので、9月からは基盤チームにジョインすることになりました。基盤チームでは他にも、開発環境をよくするための取り組みや、既存のサービスのパフォーマンスを改善するための取り組みを色々と行なっています。<br>
僕はチームとしてこのような仕事に打ち込めることが非常に有意義だと思いました。なぜなら、APIの開発をしていた時に、テストの不便さや、開発環境のパフォーマンスの悪さを感じつつも、目の前の仕事を早くこなさなければという気持ちが優先してしまい、具体的な改善作業をするには至らなかったからです。<br>
基盤チームでは、いろいろな事をしましたが、今は主にテストの改善をしています。まずは、不安定なテストを計測する仕組みを導入しました。 具体的には、github に push するたびにCircle CI で実行されるテストの結果を、Google BigQuery に送り、Google Data Portal で可視化しました。この可視化により、e2e（エンドツーエンド）テストの不安定なシナリオを特定できるようになったり、「不安定な気がする」ではなく「何%の確率で落ちているから不安定だ」と数値で示せるようになりました。<br>
また、不安定なテストにはある程度共通の原因があることもわかりました。改善については、テストケースに一つ一つ修正を入れていくというよりかは、今あるテストを壊して、不安定になる原因を排除しつつ作り直すというような方針で進めています。<br>
不安定なテストは開発スピードに大きく影響するため、非常にやりがいがあり責任のある仕事だと感じています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/23177920-367c-4182-a4ee-8db534cf03f7/photo1.jpg" alt="photo1"></p>
<h1>インターンで感じたこと、学んだこと</h1>
<h3>仕事の進め方について</h3>
<p>インターンでも社員と同様に信頼して仕事を任せてもらえているという実感がありました。<br>
APIチームで開発をしているときに、プレイドで初めての仕事だったため、わからないことはどんどん質問するようにしていました。これまでのインターンやアルバイトなどで、そのように指導されていたからです。とにかく早く成果物を完成させるということに、重きを置きすぎていました。しかし、プレイドで仕事を始めて1〜2週間ほど経った時、メンターから「遠回りしても、自分一人で解ける範囲を増やすためにもっと時間を使って良いよ」という言葉をいただきました。<br>
実際にこのことを意識しながら仕事をしてみると、より解ける範囲が増えていくことに気づきました。問題に直面したとしても、次に何をするべきか考え、手を動かすことができました。<br>
こうして、自分が解ける範囲がどんどん増えて行くことを実感し、仕事が楽しく感じましたし、自信にもなりました。<br>
この時に、メンターが、インターン生が作る成果物だけでなく、インターン生の成長にも大きな価値があるという風に意識しているのだと感じました。</p>
<h3>APIについて</h3>
<p>APIチームでは、仕様を考えていく際に色々なことを学びました。<br>
APIはKARTEでできないことを外でしてもらうためのサービスなので、既存の管理画面からGUIで操作が可能なことを提供しても意味がありません。自分なりに、KARTEのユーザだったらどうするか、ということを意識しました。また、サービスの内部で使っているAPIは、仕様を変更した時の影響範囲が把握できるため、変更が難しくありません。しかし、外部のAPIの場合には多数のユーザがそのAPIをすでに利用している可能性があるため、破壊的な変更をすることが困難になります。そのため、APIにどのような機能を持たせるかは非常に慎重に検討する必要があり、必要最低限の機能を備えるのが良いということを学びました。</p>
<h3>基盤（テスト）について</h3>
<p>基盤チームでは、主にテストの改善をしていて、技術的に学ぶことが非常に多かったです。<br>
テストにも何種類かあり、ユニットテスト、システムテスト、e2eテストなどがあります。僕は初め、e2eテストをたくさん作れば、コスパよく網羅的にシステムのテストができるとなんとなく思っていました。<br>
しかし実際には、e2eテストはもろく、不安定になりやすいもので、テスト対象のシステムのソースコードが同じでも、成功するときもあれば失敗するときもあるといったものでした。そのため、外部の環境になるべく依存しないテストを多く作り、e2eテストはシステムのコアな部分を守る必要最小限のものにするのが理想的であるということを学びました。</p>
<h1>プレイドへの新卒入社を決めた理由</h1>
<p>入社を決めた理由はいくつかありますが、プレイドの文化には特に良い印象を持ちました。<br>
例えばプレイドには「承認より謝罪」という文化があります。<br>
これは、「自分で考えてやるべきと思ったことは、誰かの承認を得なくても、とりあえずやってみて良い」というようなものです。他にも色々な文化があるのですが、多くの文化に共通する考えがあると思っています。それは、「なるべくポジティブに考えたり、人のポジティブな側面を信じる方が、トータルで得られるメリットが大きい」というような考えです。<br>
「承認より謝罪」の文化の話でいうと、承認を得るために余計なことを考える必要がなかったり、失敗したとしてもそこから得られる学びがあって、それと比較したら失敗することによるデメリットは（多くの場合は）小さい、といった考え方になると思います。<br>
実際にプレイドに来て、このような考え方がプラスだと実感できた場面はいくつもありました。APIチームでメンターから「遠回りしても良いよ」という風に言われて実践してみたときもそうでした。このような文化のある会社で働けることは、自分の人生にとってプラスだと思いました。<br>
正直、僕はプレイドから内定をいただいたときに、こんな優秀な人たちの中でやっていけるのだろうかと考えました。僕にはすぐに人と比較してしまったり、自信をなくしてしまったりしてしまう癖がありました。でも、最近はそんなこと考えても時間の無駄だなと思っています。優秀なメンバーと一緒に働けることは自分の成長に大きなプラスになりますし、たまに自信をなくすくらいがちょうど良いと考えています。<br>
入社してからは今以上に多くの困難があると思いますが、成長の機会と捉えて、前向きに働いていきたいと思います。</p>
<h1>最後に</h1>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<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>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/76095c7b-50a0-4ae7-af87-8b346f0d0c69/photo2.jpg" alt="photo2"></p>


プレイドのインターンで学んだことと、入社を決めた理由  | PLAID engineer blog

プレイドのインターンで学んだことと、入社を決めた理由

<p>エンジニアの<a href="https://twitter.com/jumpei_ikegami">池上</a>です。<br>
私の横着によってイベントから1ヶ月以上経ってしまいましたが、2019/12/11(水)に、ラクスルさんとの共同主催で「Vue.js for 2020」というイベントを開催しました！</p>
<p><a href="https://plaidtech.connpass.com/event/153623/">【PLAID × ラクスル】Vue.js for 2020 - connpass</a></p>
<p>会場はプレイドのオフィスを使い、LTや、スポンサーブース、懇親会など盛りだくさんの内容でした。</p>
<p>イベントの詳細については下記のイベントページからご覧いただけますが、<a href="https://twitter.com/takepepe">takepepe</a>さんによる<a href="https://github.com/takefumi-yoshii/vuex-guardian">vue-guardian</a>の実装に関する30分間のセッションがあったり、スポンサー企業を主催2社も含めて6社取ってブースを設けてもらったり、お祭り感のあるイベントになりました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3e4e5ec4-0b6e-487f-ad42-b9b9ef7a362f/plaid_booth.jpg" alt="plaid_booth"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f052e23b-556f-44f7-b184-6ba6fb2db86c/raksul_booth.jpg" alt="raksul_booth"></p>
<p>運営自ら楽しみすぎて写真を全く撮っていなかったですが、懇親会もとても盛り上がりました！（なぜかピザとお寿司の写真だけあったので貼りますw）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0094c3e5-1130-4c48-b210-97548b9a6c3a/pizza.jpg" alt="pizza"></p>
<p>登壇内容の詳細等については、ラクスルさんのエンジニアブログに詳細にまとまっていたので、こちらも合わせてご覧ください！</p>
<p><a href="https://tech.raksul.com/2020/01/07/vue-for-2020-event-report/">【PLAID × ラクスル】Vue.js for 2020 イベント開催レポート | Raksul ENGINEERING</a></p>
<p>イベントレポートは以上です！<br>
今後もプレイドとして、他の会社さんと共同で技術系のイベントを開催し、技術コミュニティに貢献していきたいと考えています。面白そうな話があれば、ぜひ<a href="https://twitter.com/jumpei_ikegami">池上</a>などプレイドメンバーまでご相談くださいー。</p>
<hr>
<p>ちなみに、プレイドでは、Vue.jsを0系の頃からゴリゴリ使って大規模アプリケーションを作っています。プレイドで働くことに興味がある方がもしいたら、<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>


2019/12/11(水)に、ラクスルさんとの共同主催で「Vue.js for 2020」というイベントを開催しました！会場はプレイドのオフィスを使い、LTやtakepepeさんのセッション、スポンサーブース、懇親会など盛りだくさんの内容でした。

Vue.jsに関するイベントをラクスルさんと共催しました！ | PLAID engineer blog

Vue.jsに関するイベントをラクスルさんと共催しました！

<p>Microservicesは面白い。ほとんどすべて必要なことはそこに書かれているように思う（言い過ぎ）。<a href="https://martinfowler.com/articles/microservices.html">https://martinfowler.com/articles/microservices.html</a> 訳 <a href="http://kimitok.hateblo.jp/entry/2014/11/09/211820">http://kimitok.hateblo.jp/entry/2014/11/09/211820</a></p>
<p>&quot;適切に&quot; 分離し、&quot;適切に&quot; それらの間の依存さえ解決出来れば、コンポーネントを個別で管理し運用し、進化させ続けることが出来る。開発チームは自分達の関心範囲が明確になり、集中しビジネスレベルで責任を持つことさえできる。</p>
<p>ただし、多分 &quot;適切な&quot; 人が読んだら、に限る。これは半分言葉だけの問題で、&quot;マイクロ&quot; と &quot;サービス&quot; が共に少しミスリーディングなせいか、現実問題どのように切ったらいいかがよくわからないからだ。</p>
<p><code>Self Contained Systems</code> は正直単なる Microservices の具体的解釈の一つ（ほぼAlias）に過ぎないと思うが、明示的に1レイヤー増やしていること（Microservicesでは暗黙的なだけ）で、事業の進め方や組織ポリシーを反映させやすく、扱いやすい気がしている。その割に知られていない気がしているのでご紹介。</p>
<h2>Self Contained Systems</h2>
<p>詳しくは下記を参照。<br>
<a href="https://speakerdeck.com/rstrangh/self-contained-systems-1">https://speakerdeck.com/rstrangh/self-contained-systems-1</a> だいたい書いてあるスライド<br>
<a href="https://scs-architecture.org">https://scs-architecture.org</a> 本丸のサイト<br>
<a href="https://www.infoq.com/articles/scs-microservices-done-right/">https://www.infoq.com/articles/scs-microservices-done-right/</a> infoqの記事</p>
<p>ざっくり言えば、Microservice を複数束ねたもの （+ 必要であればFront/Api） を SCS: Self Contained System と呼び、それらをTeamにAssignしよう、というもの。<a href="https://micro-frontends-japanese.org/">Microfrontends</a> に親しい人にはそちらの解釈に近いように感じるかもしれない。Frontも含まれないものも表現できる意味で少し適用しやすい。（front側はurlベースでの協調がメイン。基本url切っちゃおうということ）</p>
<p>イメージ（別にモノレポの制約とかはない）</p>
<ul>
<li>repo
<ul>
<li>system1 = product1 (Teamにassign）
<ul>
<li>service1.1</li>
<li>service1.2</li>
<li>...</li>
<li>api</li>
</ul>
</li>
<li>system2
<ul>
<li>service2.1</li>
<li>service2.2</li>
<li>...</li>
<li>front</li>
</ul>
</li>
<li>...</li>
</ul>
</li>
</ul>
<p>System間は通常のMicorservicesと同様に、単純なRestやEvent BusをVersion管理して依存を切る。<br>
System内はコードを直接依存させても良いし、versionを意識せず開発し、Deployはsystemの粒度で同期して行われることを想定する。（Canaryを使いたいケースでは使えば良い）versionを意識した開発は気が滅入る。できうる限り考慮したくない。<br>
ある意味、SCSsの一つのSystemは、<code>多少構造化されている小さいMonolith</code> だと言える。Monolithの良さは凝集性に、デメリットはスケール性にあるが、一つのTeamを小さく=一つのSystemを小さくする制約が付けられれば、良い点だけが享受できる。</p>
<p>Systemそのものの考え方はそれで良いとして、ここでの最大の関心は、Systemの境界、ひいてはTeamの境界をどう引くか、というところにある。</p>
<h2>Teamをどのように機能させたいかと、Systemの切り方</h2>
<p>Teamの境界をどう考えるか、は <code>Teamをどのように機能させたいか</code> と関連している。これは多くの場合、事業構造/組織ポリシーそのものと関連している。（つまり、それぞれの企業ごとに別の解がある）（注1）</p>
<p>例えば、Plaidの場合は（少し特殊なところかもしれないが、）事業のベースを抽象度が少し高い設計をする代わりに、その具現化のために、メンバーの発想力とモチベーションを生かすことを想定している。また間違いによるエラーの許容度も高く設計していて、大きく、素早く開発サイクルを回すことをちょっとした競合差分として設定している。そのため、Teamに対してサービスレベルでの意識を持ってもらう構造になること、できうる限り大きい幅広の範囲で裁量がわたるような構造にすることが、組織ポリシーとしても重要で、それは事業構造から来ている。</p>
<p>具体的には、Designer/Business/Developer が1Teamで動けるようにして、Featureよりもなるべく大きい Productを持つようにし（Productと呼ばないケースも多いが）、アーキテクト設計から、クライアント提供方針、（必要であれば）価格/コスト、マーケティングまでをある程度裁量を持たせる粒度で切る必要がある。<br>
その時、1Productのサイズは、その1Team（Plaidの場合TeamのサイズはDeveloperのみでは2~5人程度を目安）が1サイクル（Plaidの場合2~3ヶ月）でまわせるサイズを考える。これは提供できるものの制約にもなるが、それがそのままSystemの単位になる。</p>
<p>これはPlaidにおけるSystemの切り方の一つの例（注2）だが、もちろん他にも色々考えられる。</p>
<p>例えば、安定性/障害耐性等が高まることが事業構造上競争優位になるような場合、なるべく小さく、（SCSsのように一気通貫性を高めAgilityを上げるのではなく）職能によるレイヤーで切って固く進めた方が良いかもしれない。</p>
<p>結局次のような質問に答えつつ、Systemの粒度をまず決める必要がある。</p>
<ul>
<li>チームのサイズをどのくらいが適切と考えるか</li>
<li>事業構造とTeamの機能のさせ方をどう考えるか</li>
<li>事業フェーズをどのように考えるか</li>
</ul>
<p>注1: 個人的にはこれも <code>逆</code> と書くのはミスリーディングだな、という気がしているけれど、business architecture → org structure  = system architecture を目指す 逆コンウェイ戦略 といいたいことは多分同じ。</p>
<blockquote>
<p>'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture <a href="https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver">https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver</a></p>
</blockquote>
<p>注2:<br>
もちろん、System Architecture寄り (DDDとか) の切り方に引っ張られた方が良い場合もある。というか結構ある。そこら辺は、、柔軟に判断するw</p>
<h2>終わり</h2>
<p>結局systemっていう言葉を導入しただけなので、なんてこともないが、microserviceそのものを使っていると多分悩んだであろうところが、ある程度社内で悩まずに進めている。正直結構うまくハマっている好例だと思うので、誰かの参考になれば。</p>
<p>CI/CD戦略とかk8sの使い方とか、モノレポとかversion管理とか、そこの具体が当然また面白いところではあるし、実際に進めているところのHard thingsとかがまた面白いところだと思うが、そこは基盤チームの誰かが書くと思う &amp; 弊社に来てくれればいくらでも説明しますので、気軽に遊びに来てくれれば良いんじゃないかと思います。</p>


Self Contained Systemsの紹介 | PLAID engineer blog

Self Contained Systemsの紹介

<p>エンジニアの mizchi です。本記事は plaid advent calendar の 8日目になります。</p>
<p>フロントエンドに携わる人なら、フロントエンド開発にまつわるものは、ブラウザの中で開発が完結するはずだ、と考えたことがないでしょうか。僕は個人的にブラウザ上で開発が完結すべきであって、技術的にも不可能ではない、と思っています。これは開発環境と実行環境が同じであるべきという <a href="https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%A9%E3%83%B3%E3%83%BB%E3%82%B1%E3%82%A4">アラン・ケイ</a> の Smalltalk と同じ発想です。</p>
<p>筆者はブラウザ上で Git/GitHub の操作ができる <a href="https://nedi.app/">https://nedi.app/</a> というエディタを作成したり、そこから markdown のプレビューだけを高速化したり <a href="https://mdbuf.netlify.com/">https://mdbuf.netlify.com/</a> というMarkdown プレビューツールを作ったり、最近は <a href="https://relaxed-franklin-8384b4.netlify.com/">https://relaxed-franklin-8384b4.netlify.com/</a> (名前はまだない)という開発ツールを趣味半分仕事半分で作っています。PWA、オフラインキャッシュ、 WebWorker、node ツールチェインが発達した今なら、これが可能なのではないか？ ということで、その環境を試作した話です。</p>
<h2>ゴール: フロントエンドでフロントエンドをビルドする</h2>
<p>ブラウザ上でフロントエンドが開発できると、何が嬉しいでしょうか。まず、ブラウザさえあればよいので、開発構築が容易になります。特にプログラミング教育では、いかに最初の一歩を踏ませるかが大事で、その上で視覚的なインパクトが伴うフロントエンドや、ゲームエンジンは特に入門向きだと思っています。(HTML/JS/CSS が入門向けの環境かどうかは、Web 開発以外の観点で議論の余地があると思いますが…)</p>
<p>また、開発者向けの実用的な側面でも、現代の GUI の開発は、ビルドに伴うファイル転送とプレビューなどの必要で発生している各種 IO への負荷が大きい問題を解決できる可能性があります。今までは書き出すしかなかったメモリ上の中間状態を引っこ抜いたり、プロセス的な距離が近くなるので開発ツールの効率を考え直したり、そのための差分検知のあり方が大きく変わるはずです。</p>
<p>ツールとプレビューがセットになった環境があると、動かせるコードのシェアが容易になります。ReactNative の開発者ならば、 <a href="https://snack.expo.io/">https://snack.expo.io/</a> で簡単なコードのシェアをしたことがあるのではないでしょうか。</p>
<p>というわけで、フロントエンドでフロントエンドをビルドする、またはその開発ツールについて考えると、次のテーマが浮かび上がってきます。</p>
<ul>
<li>永続層: ファイルシステム</li>
<li>ツールチェインの解決</li>
<li>ネイティブプラグイン</li>
<li>エディタ</li>
</ul>
<h2>永続層: ファイルシステム</h2>
<p>現実には永続化とファイルストレージの問題があります。手軽な永続層として使われる localStorage は単なる KVS、しかも同期ブロッキングな API なので、プログラミングで大量のデータを扱うには不向きで、 IndexedDb は非同期で高速ですが、 <strong>ホスト OS の空き容量サイズが一定値を下回ると消える可能性がある</strong> という挙動で実装されてあることが多く、現実に発動することは稀ですが、大容量を扱う可能性があるものとしては、完璧に信頼できるストレージではありません。</p>
<p>仮想ファイルシステムは、一旦は揮発する開発環境として扱う、という従来のブラウザツールによくあるポリシーを採用するのは不可能ではないのですが、 2019 年現在、 <a href="https://wicg.github.io/native-file-system/">Native File System</a> という API が提案され、Chrome で開発者フラグを建てると使うことができます。これに活路が見いだせるかも？と期待しています。</p>
<p>これは、限定的なホスト環境へのファイル読み書き機能です。この機能を使って、一旦はブラウザストレージに書き込んだものを、単一ファイルへの内部状態の書き出しを実装すれば、非効率とはいえ、ホスト環境のディスクへの永続化が可能です。まだ試していないですが、簡易なファイルソケットとして実装すれば、双方向の RPC も実装できるかもしれません。(となるとブラウザ単独で完結するという旨味もなくなるんですけどね…)</p>
<p>Native FileSystem 現在は単体ファイルの Read or Write, またはディレクトリの Read のパーミッションしかないのですが、 単体ファイルへの Read &amp; Write や、ディレクトリへの Read &amp; Write パーミッションがあると、使い勝手の良いブラウザ開発環境のストレージが実装できる可能性があります。</p>
<p>とはいえ、歴史的にはブラウザからのファイルシステムへのアクセスは、 ActiveX 経由の悪意あるディスクトラバースとして悪用された過去があるので、セキュリティ的に危険な機能です。慎重に議論されて実装される必要があるとは思っています。</p>
<p>参考:</p>
<ul>
<li><a href="https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria">ブラウザーのストレージ制限と削除基準 - Web API | MDN</a></li>
<li><a href="https://www.html5rocks.com/ja/tutorials/offline/quota-research/#toc-chrome">モダンブラウザのストレージ容量と調査方法まとめ - HTML5 Rocks</a></li>
<li><a href="https://mizchi.hatenablog.com/entry/2019/09/08/090057">Chrome(Canary) の Native File System API で ローカルファイルの読み書きをする - mizchi's blog</a></li>
</ul>
<h2>プリプロセス | バンドリングの課題</h2>
<p>永続ストレージ問題は(問題はあるものの)解決されたとして、次に立ちふさがるのは現代のフロントエンドツールチェインです。</p>
<p>node.js 向けのツールチェインは、古くから isomorhic や universal javascript という概念があるのですが、多くはブラウザ向けに動くように調整された shim と一緒にビルドすることが可能です。</p>
<p><a href="https://qiita.com/kyrieleison/items/4ac5bcc331aee6394440">Universal / Isomorphic JavaScript について - Qiita</a></p>
<p>しかし、ここに標準ライブラリの net や fs といったモジュールを使うと話がややこしくなります。素朴な http 通信に限ったとしても、ブラウザはアクセス先に CORS の制約を受けます。このため、特にプロキシなどを用意しない場合、 CDN ぐらいしかアクセスできません。こうなると npm から tar.gz を落とす、といった、npm/yarn のツールチェインの入り口が閉じられてしまいます。</p>
<p>fs もブラウザ環境での永続層を想定しない結果として、 fs のよく使われるポリフィルは存在しません。一応、 <a href="https://github.com/jvilk/BrowserFS">https://github.com/jvilk/BrowserFS</a> という IndexedDb をバックエンドにできるツールがあるのですが、あまり現代的ではない古い設計なのと、素朴な read &amp; write を行うだけで、シーケンシャルなファイルアクセスができず、とても遅いです。</p>
<p>この結果、 React や Vue のような、フレームワークのランタイムは比較的に簡単に扱うことが可能なのですが、ブラウザでパースできない JSX や Vue SFC を扱うためのツールチェインをブラウザ側にもってくるのが、ひと手間かかります。具体的には、ユニバーサル性を謳うどのツールも、ツールチェインの依存のどこかで fs を無意識に依存のどこかで含んでいて、それらをモック化しつつビルドするのは、一手間かかります。</p>
<p>ライブラリのコアがブラウザでも動くことを謳いながら、ツールチェインのどこかで Isomorphism が失われるのは他の環境でもよく発生します。例えば eslint のプラグイン や textlint のプラグインは、外部ファイル参照の解決に fs を使いに行くものが多いので、ここをなんらかのインメモリキャッシュに差し替えたりしなければなりません。逆に言うと、それさえすれば動くものも多いです。</p>
<h2>解決策: CDN</h2>
<p>Proxy を設置しない場合、 CDN でフロントエンドのツールを引っ張ってくる必要があるのですが、幸いなことに便利な CDN がいくつかあります。</p>
<ul>
<li><a href="https://www.jsdelivr.com/">https://www.jsdelivr.com/</a> npm のファイルへの CDN</li>
<li><a href="https://unpkg.com/">https://unpkg.com/</a> npm へのファイルへの commonjs でビルドしたものを返してくれる CDN</li>
<li><a href="https://www.pika.dev/cdn">https://www.pika.dev/cdn</a> npm へのファイルのうち、 package.module で ESM でビルドしたものを返してくれる CDN</li>
</ul>
<p>内部パスやカスタムローダーで特殊なファイルを解決する際は jsdelivr, module が指定されていたら pika.dev, それ以外は unpkg などの使い分けすると効率よく引っ張ってこれそうです。 npm は unpublish が特別な場合を除いてできないので、一度引っ張ってきたらローカルキャッシュに入れてしまっても構わないはず。</p>
<h2>ネイティブプラグインの問題: WebAssembly は使えるか?</h2>
<p>フロントエンドでフロントエンドを開発しようとすると次に問題になるのはネイティブプラグインです。有名所で、 node-sass などが C で書かれた libsass でコンパイルされたプラグインですね。</p>
<p>現代のフロントエンドは、 その為の開発ツールは基本的に JS で書かれてはいるのですが、またそうではないものも wasm で提供されるようになりはじめています。例えば <a href="https://github.com/kkos/oniguruma">正規表現エンジンの oniguruma</a> は Atom などで使われ、Sublime や Atom や VSCode で連綿と引き継がれてきた使われる共通の TextMate 仕様のコードハイライト定義で使われていたのですが、これが <a href="https://github.com/NeekSandhu/onigasm">NeekSandhu/onigasm: Oniguruma regex library on the web using WebAssembly</a> という wasm 版 oniguruma が提供されるようになったことで、 VSCode Online のウェブ版のビルドが実現されています。</p>
<p>とはいえビルドサイズが膨らむことが多く、PWA のオフラインキャッシュと組み合わせてロード時間を短縮する必要があったりします。</p>
<p>wasm のパッケージを登録できる <a href="https://wapm.io/">https://wapm.io/</a> を眺めていると、想像していたより幅広いツールが日々ビルドされています。(使い物になるかはともかく…)</p>
<p>最近登録されたものを見てると、 wasi でファイルシステムが触れるようになったのが大きいですね。jq の wasm ビルドがあったり、極端なものだと、 wasm でビルドされた python があったりします。</p>
<ul>
<li><a href="https://wasi.dev/">WASI |</a></li>
<li><a href="https://wapm.io/package/jq">https://wapm.io/package/jq</a></li>
<li><a href="https://wapm.io/package/python">https://wapm.io/package/python</a></li>
</ul>
<p>とはいえ wasi も結局ブラウザで使うにはモックかインメモリキャッシュに差し替える必要があるので、これらはだいぶ辛そう…</p>
<h2>というわけで、作ってみた</h2>
<p>決めたこと</p>
<ul>
<li>超巨大ファイルストレージは扱わない(超巨大ファイルを扱うための git 組み込みもしない)</li>
<li>FS も複雑なものを扱わない想定でフラットに展開する</li>
<li>ブラウザ上で動く rollup コンパイラでインメモリに展開し、ライブラリは CDN から引く</li>
<li>エディタは vscode で実績がある monaco-editor で、 TypeScript を編集してフロントエンドのコードをプレビューする、という単目的なツール</li>
</ul>
<p>できたのがこれ</p>
<p>URL: <a href="https://relaxed-franklin-8384b4.netlify.com/">https://relaxed-franklin-8384b4.netlify.com/</a></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/70c48f8c-2a80-4900-a271-91adcc5f78bf/b4d3778564f04badf9b6562a331b256a.png" alt=""></p>
<p>ソースコード <a href="https://github.com/mizchi/bundle-on-browser">https://github.com/mizchi/bundle-on-browser</a></p>
<p>注意: 読み込みが遅いしバギーです。リロードで動かなかったりしたら、 DevTool &gt; Application &gt; Clear Site Data でキャッシュを破棄してください。</p>
<p>ドラッグアンドドロップできる可変レイアウトは <a href="https://github.com/mizchi/react-unite">https://github.com/mizchi/react-unite</a> という昔作った Unity 風のレイアウトシステムを引っ張り出しました。タブが他のペーンに移動できたりして楽しいと思います。</p>
<p>lodash, preact, react, vue, svelte で動作確認をしています。(workspace タブの preset を見てみてください)</p>
<p>CDN の一回目の読み込みは遅いですが、二回目以降はキャッシュされて早いです。これによって、ブラウザ上でバンドルしてるにも関わらず、十分高速なプレビューが実現できています。</p>
<p>NativeFileSysetem が有効になっているならば、 Cmd+S で現在のファイルシステムのダンプを示す json を保存でき、Cmd+O でそれを読み込むことができます。</p>
<h2>ブラウザ上のコンパイラの実装について</h2>
<p><a href="https://github.com/mizchi/web-compiler">https://github.com/mizchi/web-compiler</a> では、 ブラウザ上で動く rollup に、以下の機能を組み込んで、それ自体がブラウザで動くようにバンドラをコンパイルしました（ややこしい）</p>
<ul>
<li>ESM のバンドル</li>
<li>typescript の読み込み(tsx の解決)</li>
<li>npm のバージョンの解決</li>
<li>CDN からのファイル実体の解決</li>
<li>svelte の読み込み(なんとなく)</li>
<li>terser による minify</li>
</ul>
<p>その結果、4MB あって読み込みが重くなってしまったのですが、ブラウザでもサーバーでも、<code>npm install @mizchi/web-compiler</code> で次のコードが動くようになりました。</p>
<pre><code class="language-js">import { compile } from &quot;@mizchi/web-compiler&quot;;
const pkg = {
  dependencies: {
    &quot;lodash.flatten&quot;: &quot;*&quot;
  }
};

const code = `export default 1`;
const out = await compile({
  entry: &quot;/index.js&quot;,
  files: {
    &quot;/index.js&quot;: code
  },
  pkg,
  tsConfig: `{
    compilerOptions: {
      target: &quot;es5&quot;
    }
  }`
});
console.log(out);
</code></pre>
<p>ファイルシステム上の絶対パスと、そのエントリーと、解決すべきパッケージの dependencies が書かれた package.json と、その tsconfig.json です。これらを仮想 FS として、足りないものは CDN から引いています。</p>
<p>rollup のプラグインの規約がとてもわかり易いので、ハックしやすかったです。 <code>rollup(...).generate()</code> はブラウザ環境で動くことを知っていれば、あとは何でもできると思います。</p>
<h2>エディタ</h2>
<p>VSCode で使われてる monaco-editor を使っています。</p>
<p><a href="https://github.com/microsoft/monaco-editor">https://github.com/microsoft/monaco-editor</a></p>
<p>VSCode は electron(node) への依存が極力切り離されているので、ブラウザで起動可能なビルドが作れます。(<a href="https://github.com/microsoft/vscode/blob/master/scripts/code-web.js">https://github.com/microsoft/vscode/blob/master/scripts/code-web.js</a> を参照)</p>
<p>試してみたところ、永続層が実装されていないのでインメモリで揮発してしまうのですが、ここを実装すると任意のバックエンドの VSCode が作れそうでした。</p>
<p>ここまでわかったので、さらに VSCode をハックして monaco 上で TypeScript の設定を読んだり、仮想 FS 上で TS の補完を扱ったりできたり、といったものを実装したのですが、それについては別途 12/9 の ginza.js で話す予定です。</p>
<p><a href="https://ginzajs.connpass.com/event/154596/">Ginza.js#7 - connpass</a></p>
<h2>未来</h2>
<p>現状、フロントエンド開発すべてを Web に移す、といったことはまだ無理ですが、用途を絞れば、たとえば用途特化のオーサリング環境や学習用の開発環境などとしては十分実用的なものが作れると思います。</p>
<p>PWA によってオフラインツールが作りやすくなった今、みなさんも思い思いのエディタを自作してみてはいかがでしょうか。以上、フロントエンドでフロントエンドをビルドする話でした。</p>


フロントエンドでフロントエンドをビルドする

<p>こんにちは、monoi &amp; komukomo &amp; tik-sonです。<br>
11/18-11/21にかけてサンディエゴで開催された <a href="https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/">KubeCon + CloudNativeCon North America 2019</a>に参加してきたので、その様子をご紹介したいと思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a7eaaca0-b5f9-470d-ae8d-2235c892f22a/image--5-.png" alt="image--5-"><br>
サンディエゴの景色。めちゃくちゃ過ごしやすい気候でした。</p>
<h2>Anthos Day</h2>
<p>メインカンファレンス前日のDay Zeroには、様々な企業がイベントを開催していました。<br>
私たちはその中でAnthos Dayに参加しました。</p>
<p><a href="https://cloud.google.com/anthos">Anthos</a>はGoogle Cloudが開発しているプラットフォームで、特定のクラウドに依存しないアプリケーション開発・実行環境を提供しています。<br>
例えば<a href="https://cloud.google.com/kubernetes-engine">GKE</a>をオンプレミスで動かすサービスなどを提供しています。</p>
<p>&quot;Anthos Day&quot;と言いつつも意外とGKE本体についてのアップデートの発表もあり、GKEユーザーである私たちに有意義な内容が多かったです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/04915593-5d9b-476e-95c0-7f84dc02b3f1/image--6-.png" alt="image--6-"><br>
Anthos Dayでのセッション</p>
<h2>日本人交流会</h2>
<p>Day Zeroの夜には<a href="https://kubecon-jp.connpass.com/event/145278/">日本人交流会</a>が開催されました。<br>
一昨年は30人程度だった参加者も今年は150人ほどまで増えたようで、ここからもKubernetesの盛り上がりが感じられました。</p>
<p>Kubernetesの知見を持った多くの方と情報交換ができ、また日本に帰ってからも継続できる繋がりを作ることができたのは非常に良かったです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/02e6efd5-5802-438b-b5fb-5ae77ceb1c05/image--7-.png" alt="image--7-"></p>
<h2>Kubecon開幕</h2>
<p>今年のKubeconには1万人以上が参加していたようで、会場は熱気に包まれていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3b5d72ae-a5a4-4e4f-b29f-69b6c058e7e0/image--8-.png" alt="image--8-"></p>
<p>Kubernetesのユーザーというより、Kubernetesシステムまわりの開発者やプラットフォーム提供者によるセッションが多かったです。<br>
データベースやログ・監視系、セキュリティやサービスメッシュなどをはじめとした、あらゆる分野のプレイヤーがKubernetesエコシステムに参加しており、Kubernetesの柔軟性や拡張性の高さを感じるとともに、エコシステムの広げ方のうまさも改めて感じました。</p>
<p>意外なところでは、米国では金融機関や政府もKubernetesやCI/CDのオートメーションなどを活用したモダンなアーキテクチャを構築している事例も発表されてました。<br>
また、オンプレミスで運用している事例も多かったことも驚きました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9ace13e0-de61-491f-9b1b-f4091d3d1ace/image--9-.png" alt="image--9-"><br>
会場には卓球台やレトロなゲームマシンもありました</p>
<h2>Anthos / GKEのPMとのミーティング</h2>
<p>Anthos / GKEの機能に関するフィードバックや、高速にスケールアウトすることが求められるKARTEにおいてKubernetesをどのように使うべきかなどに関してディスカッションしました。<br>
アーキテクチャの構成に関する事例や内部仕様、自分たちが気づいていなかった他機能との連携など、公式ドキュメントを見るだけでは得にくいような情報も得ることができ大変有意義でした。</p>
<p>ミーティング後には、<a href="/google-cloud-next-tokyo-19/">毎度恒例</a>のPLAIDオリジナルの漢字Tシャツをプレゼントし喜んでいただけました。（笑）</p>
<h2>まとめ</h2>
<p>KubeConに参加した中で、PLAID社員がどのような動きをしていたかについて紹介いたしました。<br>
セッションの内容自体はWebで公開されているものが多いですが、どのようなセッションが人気で何に対して盛り上がっているのかを体感したり、実際に開発者やユーザと交流したりできたため、多少コストは高め（フライト時間は往復で約1日..!）ですが、意味のある時間を過ごすことができたかと思います。機会があればまた参加したいと思います。</p>
<h2>最後に</h2>
<p>PLAIDではKubernetesなどのインフラの特性をフルに生かし、魅力的なプロダクトを作るエンジニアを募集しております。もし興味があれば、<a href="https://www.wantedly.com/projects/234957">こちら</a>からカジュアルに話を聞きに来てください！<br>
また、エンジニアだけではなく、KARTEの技術的・機能的サポートを行うプロダクトスペシャリストも募集しております。プロダクトスペシャリストに関しては、<a href="https://www.wantedly.com/projects/332135">こちら</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>


KubeCon in San Diegoに参加してきました！

KubeCon in San Diegoに参加してきました！ | PLAID engineer blog

Our seeking to stable k8s deployment.

<p><a href="https://qiita.com/advent-calendar/2019/plaid">PLAID Advent Calendar 2019</a> 3日目担当の <a href="https://twitter.com/algas">@algas</a> です。今年は量子コンピュータを個人的に勉強しています。最近では量子スプレマシーが話題になりましたね。会社の業務では量子コンピュータを直接使っているわけではないので今のところは完全に個人の趣味です。ソフトエンジニアとして生きていれば遠くない将来に業務で量子コンピュータを使うこともあると思っています。</p>
<h2>概要</h2>
<p>本記事では Google の論文 <a href="https://www.nature.com/articles/s41534-019-0141-3.pdf">“Universal Quantum Control through Deep Reinforcement Learning”</a> の中で使われている技術とそれが必要な背景を解説したいと思います。論文自体の内容に関する考察までは本記事では扱いません。論文の概要は <a href="https://ai.googleblog.com/2019/10/improving-quantum-computation-with.html">Google AI Blog &quot;Improving Quantum Computation with Classical Machine Learning&quot;</a> でも紹介されています。</p>
<h2>対象読者</h2>
<p>量子コンピュータや機械学習に多少の知見がある読者を対象とします。アドベントカレンダーのネタなのにそんなに軽くないです。それぞれの技術の専門家の方はぜひ元論文を読んでみてください。</p>
<h2>背景</h2>
<p>現状の量子コンピュータを使って実用的な問題を解くための主な課題として以下の3つがあります。</p>
<ol>
<li>量子ビット数が少ない<br>
量子ビットの数が多いほど高い精度の計算や多くのパターンの組み合わせの計算ができるようになります。</li>
<li>量子状態を維持できる時間が短い<br>
量子コンピュータで問題を解いている間は量子状態を維持する必要があります。<br>
量子状態を長い間維持できる方がより複雑な問題を解くことができます。</li>
<li>ノイズやエラーのために信頼性が高くない<br>
古典コンピュータではノイズの除去やエラー訂正が実用上で十分なレベルに達しています。<br>
それに比べて量子計算でのエラー訂正は簡単ではありません。量子状態を維持する時間が短いので大規模計算で訂正処理をするのが困難です。量子ビットを測定すると量子状態が壊れるので測定せずに訂正する方法が必要です。</li>
</ol>
<p>この3つ目の課題を解くのが紹介する論文の手法です。</p>
<h2>論文の解説</h2>
<h3>量子コンピュータのノイズ</h3>
<p>量子コンピュータのノイズには主に以下の２つがあります。</p>
<ol>
<li>量子ビット自体への干渉
<ul>
<li>量子コンピュータでは量子ビットに情報が保持されます。光子や音量子が量子ビットの近くを通ることによって量子力学的に干渉することがあります。</li>
<li>量子ビットの値を確定するためには「測定」する必要があります。測定の精度によって量子ビットの値が間違っていることがあります。</li>
</ul>
</li>
<li>量子ビットを制御する道具によるノイズ
<ul>
<li>量子ビットが載ってる物理基板の電気信号や電磁場によってアナログのノイズが混じってしまうことがあります。</li>
<li>熱によるホワイトノイズ以外にも、外部の電波源、DAコンバータなどもノイズの発生源になります。</li>
</ul>
</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ba139dd5-672d-4e91-956e-9a5ec344c666/57f6b41cba3d6eafb00633637f064550-png.png" alt="ノイズの図"></p>
<h3>論文の概要</h3>
<p>量子コンピュータのノイズ問題を解決するために「深層強化学習を使った新しい量子制御フレームワーク」を作りました、という内容の論文です。<br>
フレームワークの応用用途には以下があります。</p>
<ul>
<li>量子シミュレーション</li>
<li>量子化学</li>
<li>量子スプレマシー</li>
</ul>
<p>量子計算中の情報の漏れがノイズの主な原因の1つです。理論的には情報の漏れを完全に予測できればノイズを改善できます。量子コンピュータ全部をシミュレーションできればこれが実現できます。しかし現実的には量子コンピュータ全部をシミュレーションするのは計算効率の問題や大規模な計算においては難しいので完全には予測できません。その代わりに物理モデルを改良することで量子計算のいくつかのパラメータを最適化してノイズを減らすことができます。</p>
<h3>論文の結論</h3>
<p>既存の手法の確率勾配降下法(SGD)よりも桁違いで良い結果が得られたそうです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a9dac92a-2c98-4f71-afd0-e51469b438b2/fcf78285bc840c1f345fd76fdaf599b9-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 4)"></p>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 4)</p>
</blockquote>
<h3>On-Policy Trusted-region Deep Reinforcement Learning</h3>
<p>深層強化学習の図です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/13ee3c26-1495-4af7-8148-f4ff5f349d9e/571328050131bfec2920c9d5bb86e4e4-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 1)"></p>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 1)</p>
</blockquote>
<p>深層強化学習の技術については以下によくまとめられています。本記事と合わせてお読みください。<br>
<a href="https://qiita.com/shionhonda/items/ec05aade07b5bea78081">深層強化学習アルゴリズムまとめ</a></p>
<ul>
<li>深層学習(Deep Learning)<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/df1bac60-9d83-4662-97f3-6d069eab6166/efc3e5c080b5b8fb30e96b5fbf22c1df-png.png" alt="DeepLearning"></li>
<li>強化学習(Reinforcement Learning)<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/436aea15-bd98-45ad-be1e-f77e2966da05/a487c561028d9bf9783570645d39d350-png.png" alt="a487c561028d9bf9783570645d39d350-png"></li>
<li>深層強化学習(Deep Reinforcement Learning)<br>
= 深層学習(Deep Learning) + 強化学習(Reinforcement Learning)<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cc5e3a4d-9001-4d76-aa8c-31a145ad6c9d/f09e4543ebfe850c4b2daa220cb1b97b-png.png" alt="f09e4543ebfe850c4b2daa220cb1b97b-png"></li>
</ul>
<blockquote>
<p><a href="http://people.csail.mit.edu/hongzi/content/publications/DeepRM-HotNets16.pdf">http://people.csail.mit.edu/hongzi/content/publications/DeepRM-HotNets16.pdf</a></p>
</blockquote>
<ul>
<li>Trust Region Policy Optimization<br>
論文: <a href="https://arxiv.org/pdf/1502.05477.pdf">https://arxiv.org/pdf/1502.05477.pdf</a><br>
解説記事: <a href="https://medium.com/@jonathan_hui/rl-trust-region-policy-optimization-trpo-explained-a6ee04eeeee9">RL — Trust Region Policy Optimization (TRPO) Explained</a><br>
信頼できる領域内にステップを抑えることで状態の急激な悪化を防ぎます。急な勾配を崖に例えると、崖を飛び降りない手法といえます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/605a19c8-0032-4b80-ba8f-e8092362973b/----------2019-12-02-17.15.43.png" alt="崖から飛び降りない図"></li>
</ul>
<blockquote>
<p><a href="https://medium.com/@jonathan_hui/rl-trust-region-policy-optimization-trpo-explained-a6ee04eeeee9">https://medium.com/@jonathan_hui/rl-trust-region-policy-optimization-trpo-explained-a6ee04eeeee9</a></p>
</blockquote>
<ul>
<li>On-Policy<br>
解説記事: <a href="https://qiita.com/ABmushi/items/83a639506fcbc4050ce8">強化学習のOn-PolicyとOff-Policy</a><br>
現在の方策(Policy)に則って(on)将来の行動が選択されることを前提に学習します。崖の近くの道が選ばれにくくなります。On-Policy とは逆に方策に依存しない Off-Policy もあります。</li>
<li>Policy Neural Network<br>
解説記事: <a href="https://towardsdatascience.com/policy-networks-vs-value-networks-in-reinforcement-learning-da2776056ad2">Policy Networks vs Value Networks in Reinforcement Learning</a><br>
現在の方策(Policy)を改善するのが目的です。行動空間が高次元でも連続でも使えます。確率論的な方策も学習できます。局所解に陥りやすく評価が非効率的であるというデメリットもあります。</li>
<li>Value Neural Network<br>
最適行動価値(Value)関数を推定するのが目的です。局所解には陥りにくいアルゴリズムもあります。行動空間が高次元の場合には計算負荷が大きくなります。</li>
<li>確率勾配降下法(Stochastic Gradient Descent Method)<br>
解説記事: <a href="https://postd.cc/optimizing-gradient-descent/">勾配降下法の最適化アルゴリズムを概観する</a><br>
目的関数を最小化する問題を解く方法の1つです。局所解に陥りにくいメリットと最適解をいつまでも得られない可能性があるデメリットを持ちます。</li>
</ul>
<h3>Quantum Unitary Gate</h3>
<p>量子回路図です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/352383d0-03df-4b28-8d76-a93872a44ae8/b0028cd46b91048d89f779df10bfcdb8-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 2)"></p>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 2)</p>
</blockquote>
<p>量子コンピュータに知見がない方は以下も合わせてお読みください。<br>
<a href="https://www.slideshare.net/techblogyahoo/ss-138380151">ゲート方式量子コンピュータの概要</a><br>
<a href="https://en.wikipedia.org/wiki/Quantum_logic_gate">Quantum logic gate</a></p>
<ul>
<li>量子ビット(qubit)<br>
古典ビットは0か1の2つの状態しかありません。量子ビットは測定した時に初めて値が確定し、その状態によって確率的に0か1のどちらかの値になります。複数回測定するとその出現確率の状態に近づきます。
<ul>
<li>古典ビットの「0」: 0が100%測定される状態<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/89e4b213-6b8e-4c21-b5a8-6f7d3459ff2c/ket0-2.png" alt="ket0"></li>
<li>古典ビットの「1」: 1が100%測定される状態<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9a7885ef-f000-4459-8eb8-a8ed076fe6e5/ket1-2.png" alt="ket1"></li>
<li>一般的な量子1ビット<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/af71b94d-f1c5-4da3-ad69-0deefdf30da5/qubit1-2.png" alt="qubit1"></li>
<li>ブロッホ球:量子ビットの状態を仮想的に表した球<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e9594ab5-73d9-4f1d-9608-62543a689458/quantum_gates_bloch_sphere.png" alt="bloch-sphere"></li>
</ul>
</li>
<li>量子ゲート演算の基本
<ul>
<li>nビット量子ゲート演算<br>
2^n x 2^n の行列=ゲート( U )を 2^n 要素のベクトル = 量子nビットに作用させます。</li>
<li>1ビットの場合には以下の式で書けます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/35eab83e-6b2c-42f7-a79b-79edc54648f1/quantum1_u_gate.png" alt="quantum1_u_gate"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e7f633ef-3745-4a0e-99ac-7770757e24de/quantum1_u-1.png" alt="quantum1_u"></li>
</ul>
</li>
<li>1ビット量子ゲート
<ul>
<li>RYゲート: ブロッホ球のY軸の周りに位相をθだけ変化させます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ddc4adf9-d2b9-42cb-bc16-755dbf9dc023/ry-gate-1.png" alt="ry-gate"></li>
<li>RZゲート: ブロッホ球のZ軸の周りに位相をθだけ変化させます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c0bbdf6c-6650-41e0-8a10-4ad3fe7f45ce/rz-gate-1.png" alt="rz-gate"></li>
</ul>
</li>
<li>2ビット量子ゲート
<ul>
<li>CNOT(Controlled Not)ゲート: コントロールビット(下図の上側のビット)が1の時だけターゲットビット(下図の下側のビット)の値を反転させます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/114d84fa-5c20-4ff6-b3dc-c5b02c4c6f27/cnot-gate-1.png" alt="cnot-gate"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/96cdff24-43c8-4f7e-bc5c-1d68d0cfea75/cnot-circuit.png" alt="cnot-circuit"></li>
<li>SWAPゲート: 2つのビットの値を交換します。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bbd5349e-a253-429b-af9f-5791bf45754d/swap-gate-1.png" alt="swap-gate"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ac550bb8-01b2-40be-a472-58deaf0a553f/swap-circuit.png" alt="swap-circuit"></li>
</ul>
</li>
<li>Quantum Unitary Gate
<ul>
<li>たとえば簡単のために α=π/4,γ=π/4 と仮定すると、U は以下のような演算になります。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/aa05c59b-70fc-405f-86ec-409a6acf6333/ui-simple.png" alt="ui-simple"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7bfbc15b-d980-48c1-9e5a-d03e22ef0318/rz0.png" alt="rz0"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2e4ec040-3d83-4165-a3c9-3118cb82094c/rz1.png" alt="rz1"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/14929f10-dc99-47ee-b8d9-02e7048c96ea/ui-result.png" alt="ui-result"><br>
SWAPゲートと一緒になります。ちょっと簡単にしすぎました。</li>
<li>論文による測定結果<br>
α を横軸にして γ=π/2,π/6,π/3 の場合の単位時間あたりのゲート実行時間を縦軸にした図です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f72780d3-32fd-4f72-bd30-0bebabd94ce8/5dacd6723662c60dec0d909e5a2f9c6a-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Figure 3)"></li>
</ul>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Figure 3)</p>
</blockquote>
</li>
</ul>
<h2>本記事のまとめ</h2>
<p>量子コンピュータの直近の主な課題の1つであるノイズ問題を改善する手法を提案する論文の背景と論文内に登場する技術を紹介しました。背景の状況や要素技術が理解できると論文の内容にも興味を持てるのではないでしょうか。</p>
<h2>参考文献</h2>
<ul>
<li><a href="https://www.nature.com/articles/s41534-019-0141-3.pdf">“Universal Quantum Control through Deep Reinforcement Learning”</a></li>
<li><a href="https://ai.googleblog.com/2019/10/improving-quantum-computation-with.html">&quot;Improving Quantum Computation with Classical Machine Learning&quot;</a></li>
<li><a href="https://www.shoeisha.co.jp/book/detail/9784798159928">現場で使える! Python深層強化学習入門 強化学習と深層学習による探索と制御</a></li>
<li><a href="https://book.mynavi.jp/ec/products/detail/id=90706">つくりながら学ぶ! 深層強化学習 PyTorchによる実践プログラミング</a></li>
<li><a href="https://www.shoeisha.co.jp/book/detail/9784798157467">絵で見てわかる量子コンピュータの仕組み</a></li>
</ul>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</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>


PLAID Advent Calendar 2019 3日目 論文 “Universal Quantum Control through Deep Reinforcement Learning” の背景と要素技術の解説

深層強化学習は量子猫の夢を見るか？ | PLAID engineer blog

深層強化学習は量子猫の夢を見るか？

Engineer Blog

Recent Article