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会で活用のヒントを探ってみた！

KARTEのロゴ刷新に至った経緯やデザインプロセスについてお伝えします！

刷新したKARTEロゴのプロセス公開 ー プロダクトが目指す理想像から始めるアプローチ | PLAID engineer blog

刷新したKARTEロゴのプロセス公開 ー プロダクトが目指す理想像から始めるアプローチ

<p>おはようございます！プレイドのエンジニアの <a href="https://twitter.com/jumpei_ikegami">@jumpei_ikegami</a> です。<br>
趣味はポッドキャスト配信です。</p>
<p>さて、プレイドでは定期的に、開発チームで合宿に行っています。</p>
<p>(過去の開発合宿のブログ記事は下記）</p>
<p><a href="http://blog-plaid.com/event/2772/">2016年:秋</a></p>
<p><a href="/plaid-developpers-camp-2017-spring/">2017年:春</a></p>
<p>今回は、開発フォーカスの区切りということで、前フォーカスの振り返り、4月以降の新チーム体制でのフォーカス、プロダクトの見せ方などについて、議論を深めてきました。</p>
<p>開発をしない開発合宿も珍しいと思いますが、目の前の開発業務を離れて、長期的な視野で開発の仕方や、何をするべきかを見つめ直すことで、本当にやるべき仕事にフォーカスできるようになります。</p>
<p>特に、<a href="/software-development-not-start-from-shu/">先日のエンジニアブログ記事</a>で弊社kadoppeが書いていた、「『常にゼロベースで考えて進む』プレイドの文化」が、議論の中にも表れていました。</p>
<p>そんな開発チーム合宿の様子を、写真多めでお送りします。</p>
<h1>五反田発、館山行き貸切バス</h1>
<p>館山の合宿先までは、オフィスのある五反田から貸切バスで移動しました。</p>
<p>バスの写真は、私が寝ぼけていたのでありません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5e8fb80a-ae61-455a-af07-e722a3f393cd/010-2.jpg" alt=""><br>
（途中のサービスエリアで食べた、「つみれ汁:¥200」と、「ふきのとうの天ぷら:¥50」）</p>
<p>お酒が無いのが不思議です。</p>
<p>車内では、遠足気分を高めるための駄菓子の配給がありました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1a37dd1e-d700-42ad-b9c1-bef6a1f0573b/020-2.jpg" alt=""><br>
(宿に着いてから「ソースせんべい」を食べる、ぐろっちさん)</p>
<h1>海の見える宿</h1>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cf8baae9-a779-4953-9634-11eb1c205532/030-1.jpg" alt=""></p>
<p>今回は、千葉県館山市、房総半島の南の端にある「<a href="https://tateyama-retreat.jp/">館山リトリート</a>」という宿にお世話になりました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/68720b41-1492-4546-8ba8-e91932fae1d7/040-2.jpg" alt=""></p>
<p>議論に使った大広間からも、海が見えました。</p>
<p>考えに詰まったら大海原をみながら頭を整理することができました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/22d452a0-ffb7-47b8-85c4-9132b17c34a1/043-1.jpg" alt=""></p>
<p>食事は自分たちで準備するスタイルで、広々としたキッチンを自由に使えます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cc1ae859-d3bd-40e0-b4c3-49cd063ec2ee/045.jpg" alt=""></p>
<h1>ゼロベースで議論！議論！議論！</h1>
<p>合宿のコンテンツは、ひたすら議論を重ねるものでした。</p>
<p>主な内容は4つありました。</p>
<h2>未来のユーザーに、KARTEをどのように見せる？</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/23b7183b-23a9-4614-a915-7627c592c3a8/050.jpg" alt=""></p>
<p>「<a href="https://karte.io/">KARTE</a>のキャッチコピーを考える」という題材を通して、未来のKARTEユーザーにどんなメッセージを伝えたいかを考えました。</p>
<p>出た意見をいくつか挙げます。</p>
<ul>
<li>KARTEを単なるツールとしてではなく、プラットフォームとして見せていくべき</li>
<li>要望への「最適化」では足りない。それを知った上で、どう期待を超えていくか？</li>
<li>クライアント企業の指標を上げるだけではなく、その先のエンドユーザーを幸せにすることを含めて見せ方を考えたい。是即ち「愛」</li>
</ul>
<p>開発チームの仕事は、ただプロダクトを作って終わりではありません。<br>
自分たちが作っているプロダクトがどのようにユーザーに届けられるのか、という点についても関心が高いのが、プレイドの開発チームのよいところだと感じました。</p>
<h2>チーム間の連携、どうすればうまくいく？</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3640d85d-416a-4dc6-a5cd-d9d31267dfdb/060.jpg" alt=""></p>
<p>これまで、開発内の別チームや、ビジネス側のチームとの連携などがうまくいかなかったことで、手戻りが発生したり、ユーザーへのデリバリー方法に問題が生じたりしました。</p>
<p>そこで、「チーム間連携」というテーマで、理想・課題・解決策を挙げるために議論しました。</p>
<p>出た意見をいくつか挙げます。</p>
<ul>
<li>理想は、「スタンドプレーから生じるチームワーク」</li>
<li>チームを固定化せずに、ビジネスメンバーも巻き込んで流動的に変えていく</li>
<li>生産性を優先すると、社内で情報格差が生じてカオスになる。それをある程度許容すべき。ルールを作るのではなく、そういうカオスな状況でもパフォーマンスを出せるメンバーを増やしていく方が建設的</li>
</ul>
<p>「チーム間連携」という話だと、「定例ミーティングしよう！」というような安易な話になりがちです。<br>
それを超えて、さらに深い議論に発展していたのが、印象的でした。</p>
<p>プレイドには「常にゼロベースで考える」以外にも、「ルールをなるべく作らない」という文化があります。今回の議論も、ルールではなく、マインドやチームのあり方の話で課題を解決しようとするところに、「らしさ」が出ていました。</p>
<h2>コーヒーブレイク</h2>
<p>休憩時間では、コーヒー好きが集まるプレイドらしく、コーヒーミルを持ち込んで、コーヒーを飲むメンバーもいました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/705d5c03-7111-4b1e-bece-7e74b01ea541/070.jpg" alt=""><br>
(ハッピーターン」を取りに来た、デザイナーのミギーさん)</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2b9eb2ad-e8c2-46db-8418-ecf2ef85ff3e/080.jpg" alt=""><br>
(カメラを向けると、わざとらしい笑顔を向けてくる、ぐろっちさんと、ノブくん)</p>
<p>全く外に出る時間はありませんでしたが、昼間の天気も最高でした！<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/08c6cf6d-e1c3-45bd-9261-d249b0b55700/090.jpg" alt=""></p>
<h2>新しいチームでのミッションどうしよう？</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/320f652e-821e-49ba-a0f5-cf3a5ad302bd/100.jpg" alt=""></p>
<p>4月から開発チームの再編があり、最初の3ヶ月で行うミッションの言語化、状態目標の設定、注力issueの洗い出し、などを行いました。</p>
<p>PLAIDには固定的な「部署」という概念はなく、定期的にチーム構成が再編されます。<br>
それによって、ナレッジが蛸壺化しにくくなったり、個人が色々な役割を担えるようになります。</p>
<p>開発チームも同様で、機能の多いKARTEの中でも、定期的に自分が開発を担当する機能が変わっていきます。</p>
<p>この議論では、前のチームでのやり方に捉われず、そもそもどんな課題を解決するべきか？を「ゼロベース」で考えていきました。</p>
<p>私はBizDevチームというビジネスサイドのチームに属しているのですが、「開発チームが作った機能のデリバリーに関して課題があり、その整備に注力していこう」という目線合わせができてよかったです。</p>
<h2>前フォーカスどうだった？</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9b6f792f-35a1-426e-8286-857fc92ad9fd/110.jpg" alt=""><br>
(CTOが買って飲まなかった「プロテインドリンク」をみんなで勝手に飲んでいる図)</p>
<p>最後に前回のフォーカスについて、その進め方のKeepとProblemをみんなで挙げていきました。</p>
<p>出た意見をいくつか挙げます。</p>
<ul>
<li>Keep
<ul>
<li>作り始めたものを一回壊して、ゼロから作り直すことで、本当に良いものができた</li>
<li>「既存機能の改善」を束ねて大きくリリースしたのは、ただ新機能を出すより難しいことができた</li>
<li>チームが自律的にパラレルで動けるようになった</li>
<li>1人でやるよりもチームでやることで、より良いものができた実感がある</li>
</ul>
</li>
<li>Problem
<ul>
<li>差し込みタスクでスイッチングコストがかかった</li>
<li>もっと細かい粒度でリリースして、反応を見ながら開発しても良かった</li>
<li>チームの壁が厚く似たようなものを別で作ってしまったので、もっと流動的に人の入れ替えがあると良かった</li>
<li>不安定なテストがあるなど、フォーカス外のissueが放置されがちで、負債が溜まってしまった</li>
</ul>
</li>
</ul>
<p>この議論についても、結果として、「新しいルール作ろう！」ではなく、「次に同じ状況になったらもっとうまくできる！」という実感の共有をできたのが、良かったと思いました。</p>
<p>次に似たような課題に直面するときも、チームメンバーやプロダクトの状況はそのときとは違うかもしれません。<br>
無批判にルールを当てはめるのではなく、その都度「全力で考える」という前提を置いた上で、その考えるための材料を、この議論で洗い出せたと思います。</p>
<h1>うまい魚に、うまい酒</h1>
<p>議論の合間の食事も、みんなで楽しみました。</p>
<p>1日目の夜は、豪勢に鯛のあら汁と寿司でした。<br>
寿司には、「ストロング・ゼロ」がよく合います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f7e8c85f-a71a-414b-a8c0-7e9d1ce06a31/120.jpg" alt=""></p>
<p>一日中議論をしても、飲み会の話題は尽きません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9b190878-dacf-49c9-9f36-5eb0c99582f3/130-1.jpg" alt=""></p>
<p>期待のルーキー、カンテの悪酔いに、先輩藤川くんも苦笑い。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18de3482-98db-424d-bf9b-2ba505576086/135.jpg" alt=""></p>
<p>2日目の朝から、余った寿司を食べました。箸がなかったので、まさかのスプーンです。<br>
寿司は昼まで余ったので、夢の「3食お寿司のすしざんまい生活」が実現しました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/58f58376-5fc2-46c8-8f64-56aa9dc73d8b/140-1.jpg" alt=""></p>
<p>2日目の昼は、なんと海鮮鍋でした。<br>
このシズル感。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/73a2f0aa-8395-4c20-92f9-27e8b27fa2c5/150-1.jpg" alt=""></p>
<p>鍋にすると、こうなります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5a4dbb25-68cc-4721-a775-77225a2a81d2/160.jpg" alt=""></p>
<h1>アクアラインを通って五反田へ</h1>
<p>2日間の日程も、あっという間に過ぎました。</p>
<p>帰りも、バスでアクアラインを通って東京に帰りました。</p>
<p>この日は強風が吹いていて、途中の「<a href="https://www.umihotaru.com/">海ほたる</a>」では階段を登っている途中で吹き飛ばされるかと思いました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2a1f54dd-515d-4c6e-b694-2eede764e709/170.jpg" alt=""></p>
<p>バスでは、一部のメンバーが余った「ストロング・ゼロ」で宴会をしていました。私も2本目を空けるまでは記憶がありました。</p>
<p>思えば、この合宿で何本の「ストロング・ゼロ」を飲んだのだろう。プレイドの文化は、「常にゼロベースで考える」こと。昼に「ゼロベース」の議論を重ねて、夜に「ストロング・ゼロ」を飲み明かす。これが本当の......「ストロング・ゼロ・ベース思考」？？</p>
<p>......ふと、目を開くと、そこはいつもの五反田の街でした。</p>
<p>ということで、合宿で持ち帰ったアイデアを、ここ五反田のオフィスから実現していきます！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5cd766d1-f9ac-4d98-ab5f-f0654af798c3/180.jpg" alt=""></p>
<h4>最後に</h4>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニアやインターンを募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><br>
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</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>


開発チームで、千葉県館山市に合宿に行って来ました！開発の節目ということで、KARTEをどう見せていくか、何にフォーカスすべきかなど、1泊2日に�

1泊2日ぶっ通しで議論する開発合宿をしに、館山に行ってきました！ | PLAID engineer blog

1泊2日ゼロベースで議論する開発合宿@館山に行ってきました！

<p>こんにちは、はじめまして。プレイドの @kadoppe です。</p>
<p>2017年4月に入社したエンジニアです。この記事を書いている時点のプレイド歴は11ヶ月です。</p>
<p>この記事では、自分が個人的に最近大事だと考えている『「型を守る」ことから始めないソフトウェア開発」』というトピックについて書いてみようと思います。</p>
<p>技術成分が少なめの内容ですが、こういうことを考えているエンジニアもいるんだよ、ということで興味がある方はご覧ください。</p>
<h1>５行まとめ</h1>
<p>少し長いので5行で内容をまとめます。</p>
<ul>
<li>「守破離」というソフトウェア開発の技術・方法論を効果的に学ぶための考え方がある。</li>
<li>「型を守る」ことから始めるソフトウェア開発は、問題を解決する上で最適・最速ではない可能性がある。</li>
<li>「型を守る」「型を破る」「型を離れる」のどこから始めるべきか、問題の内容や、プロダクト・チームの状態を考慮した上で決めるべき（最初から型破りでいい＝型を守ることから始めないソフトウェア開発）</li>
<li>「常にゼロベースで考えて進む」プレイドの文化において、型を守ることから始めないソフトウェア開発は進めやすい、というか自然とそう考えさせられる力学が働いている。</li>
<li>僕にとっての「プレイドの良いところ・好きなところ」はそういうところ。</li>
</ul>
<h1>守・破・離 〜 shu ha ri 〜</h1>
<p>唐突ですが、みなさん「守破離」について知ってますか？</p>
<p>「守破離」とは、ソフトウェア開発の技術・方法論を効果的に学ぶための考え方の一つです。本来は日本の合気道に由来する、武術を学ぶ際の考え方ですが、日本に止まらず世界的に使われています。</p>
<p>この考え方の中では、人が技術や知識を得るまでには、「守（型を守る）」「破（型を破る）」「離（型から離れる）」の３つの段階を経るとされています。</p>
<blockquote>
<p><strong>守</strong>：最初の段階では、学習者は師の教えを正確に模写する。理論についてあれこれ考えずに、その作法に集中する。作法が複数ある場合でも、師の教えをただ忠実に守る。</p>
<p><strong>破</strong>：この段階では、学習者は新しいことに手を出す。基本的な実践を身に着けたなら、技術の裏にある原則や理論を学んでいく。また、他の師からも学び、得たものを自身の実践に採り入れていく。</p>
<p><strong>離</strong>：この段階では、学習者は、自身の実践を通じて、他者から学んでいく。自身の手法を生み出し、学んだことを自身の環境に適応させていく。</p>
</blockquote>
<p>引用元: <a href="http://bliki-ja.github.io/ShuHaRi/">守破離</a></p>
<p>この３つの段階に従うことで、効果的に技術や方法論を身に付けることができ、最終的には分野でイノベーションを起こすことができるようになる、という考え方です。</p>
<p>非常にわかりやすいので、個人的にはとても好きです。前職でもこの考え方は凄く大事にした上で、新しいやり方や方法論などをチームに取り入れたりしていました。</p>
<h1>ソフトウェア開発における型</h1>
<p>では、ソフトウェア開発における型とは何でしょうか。</p>
<p>ソフトウェア開発を進めていく中で、プロダクトやチーム、エンジニアは、日々様々な種類の幅広い問題に直面します。</p>
<p>世の中にはそういった問題に対する解決策が、事例やフレームワーク、あるいは開発プロセスとして、書籍やWeb上の記事といった形で、広く一般に公開されています。</p>
<p>例えば、以下のようなものが例として挙げられます。</p>
<ul>
<li>アジャイル開発手法やウォーターフォールモデルといった開発手法</li>
<li>スクラムのようなフレームワーク</li>
<li><a href="https://www.amazon.co.jp/dp/B00G9QJ1ZO/">組織パターン</a>のような書籍にまとめられているパターンランゲージ</li>
<li><a href="https://12factor.net/ja/">The Twelve-Factor App</a> のような方法論</li>
<li>ブログの記事に記載されている小さな tips</li>
<li>etc.</li>
</ul>
<p>大きさや粒度は違えど、これらは全て、ソフトウェア開発において発生した何らかの問題に対する解決策です。このような解決策が「ソフトウェア開発における型」だと考えます。</p>
<h1>「型を守る」ことから始めることをあえて批判的に捉える</h1>
<p>突然何を言っているんだという感じではありますが、プレイドという新しい環境にジョインしてから、プレイドの文化や雰囲気に触れて、今までの自分の仕事のやり方や考え方を見つめ直す機会があったので、色々考えたのです。</p>
<p>上に紹介した「守・破・離」という考え方では、「守」から始めることが「良し」とされていると捉えることができます。しかし、「型を守る」ことから始めることが常に正しいとはいえないと思います。</p>
<p>ここでは、こじつけかもしれませんが、型を守ることから始めることを、あえて批判的に捉えてみます。</p>
<h2>思考停止では？</h2>
<p>「型を守る」＝「理論についてあれこれ考えずに、その作法に集中する。」で本当にいいんでしょうか。その理論は自分たちが抱えている問題に対して本当に正しく、適切なものなのでしょうか。</p>
<p>そもそも正しい理論を教えてくれる「師」なんて存在するのでしょうか？そもそも正しい理論なんて存在するのでしょうか？</p>
<p>一般的な解決策を信じきって、自分たちが直面している個別の問題に適用してしまってもいいのでしょうか。</p>
<h2>問題に対してその解決策は最適解か？</h2>
<p>同じように見える問題でも、その問題が発生した環境や背景、プロダクトやチームが違えば、本質的には違う問題です。</p>
<p>問題が違えばそれに最適な解決策も異なるはず。なので、そこから生まれる結果も最適なものではない可能性があります。</p>
<p>その前提の上で、「作法が複数ある場合でも、師の教えをただ忠実に守る。」のは本当に正しいアプローチなんでしょうか。</p>
<p>問題が少しは改善するかもしれません。でも、実はそれは局所最適解で、本当の最適解には気づけないまま、時間が過ぎていってしまうかもしれません。</p>
<p>最初から、自分たちの直面した問題に対して、ゼロベースでフルカスタマイズされた解決策を適用する。そのために問題をしっかり認識・分析することが、問題を最適に近い形で解決するための近道なのではないでしょうか。</p>
<h2>時間がかかりすぎないか？</h2>
<p>「守」から始めたとして、では「破」「離」にたどり着くまでにはどのくらいの時間がかかるのでしょうか。</p>
<p>例えば「スクラム」の例を挙げてみると、とあるスクラムコーチ曰く、スクラムをはじめたばかりのチームが「守」のフェーズが終わるまでに短くても「3ヶ月くらいかかる」とのことでした。</p>
<p>でも、自分たちにその時間的余裕はあるのでしょうか。ユーザーや市場は待ってくれるのでしょうか。「破」や「離」にたどり着く頃には会社はプロダクトはどうなっているのでしょうか。</p>
<p>最初はとりあえず始めてみて、そこで得られたフィードバックをもとに、あとで調整しながら最適に持っていく方法もあります。</p>
<p>問題を解決するまでにフィードバックループは何度か回すことになると思いますが、「守」から始めることで、少なくとも一回は余分に多くフィードバックループを回すことになってしまいます。</p>
<p>その1回を許容できる時間的余裕が、自分たちにはあるんでしょうか。</p>
<h1>「型を守る」ことから始めないソフトウェア開発</h1>
<p>ここまでで、言いたかったのは『「型を守る」ことから始めるソフトウェア開発は、問題を解決する上で最適・最速ではない可能性がある』ということです。「型を守る」ことから始めることが正しいときもありますが、必ずしもそうとは限りません。</p>
<p>大切なのは以下の2点だと思います。</p>
<ul>
<li>自分たちが直面している問題を、自分たち固有のものだと捉えて、問題についてしっかり認識した上で正しく理解すること。</li>
<li>問題に直面しているプロダクトやチーム、個人の状態（問題に対する習熟度、背景、環境など）を正しく理解すること。</li>
</ul>
<p>その上で、</p>
<ul>
<li>世の中に一般的に公開されている解決策をまずはそのまま適用してみるのか（＝型を守る）</li>
<li>それを参考に少しカスタマイズした上で試してみるのか（＝型を破る）</li>
<li>ゼロからフルスクラッチで自分たちだけの解決策を考えて適用してみるのか（＝型を離れる）、</li>
</ul>
<p>その時々に応じて最適だと考えられる選択肢を取ることが重要だと考えています。</p>
<p>これが『「型を守る」ことから始めないソフトウェア開発』です。最初から型破りでもいいんです。</p>
<p>これが自分たちが最適かつ最速に問題解決に近づくためのアプローチだと思いますし、個人的には凄く重要なポイントだと考えています。</p>
<h1>え、そんなの当たり前のことでしょ？</h1>
<p>ここまで書いた内容を眺めてみると「当たり前のこと / 誰でも気付いていること」を書いてるいるなぁと思いますし、ここまで読んでいただいている方も同じ感想をお持ちかと思います。</p>
<p>ですが、僕の経験上、</p>
<ul>
<li>ついつい思考停止した上で「型を守る」ことから始めてしまう</li>
<li>問題をしっかり認識・理解することよりも、先に解決策ありきで物事を進めようとしてしまう</li>
</ul>
<p>といった罠が、ソフトウェア開発に日々取り組む中で、いろんな場所に仕掛けられているような気がしています。「型を守る」ことに引っ張られる、そういう力学や雰囲気が自然と当たり前のように存在しているような。</p>
<p>「型を守る」ことから始めることや、解決策ありきで物事を進める方が、圧倒的に楽です。考えることの量がとても少ないです。一般的な解決策の方が、ゼロベースでフルカスタマイズした解決策よりも、周りの人が理解しやすかったりします。</p>
<p>人間は弱いものなので、気を抜くと、どうしても楽な方に引っ張られてしまいます。</p>
<p>だからこそ、楽ではないが、本質的なアプローチが取ることは難しいことだと思いますし、それがやりやすい環境がもしあるとするならば、それ自体凄く価値のあることだと思います。</p>
<h1>「常にゼロベースで考えて進む」</h1>
<p>プレイドのコーポレートサイトに、エンジニアリングチームの文化について書かれているページがあり、そこには以下のような記述があります。</p>
<blockquote>
<p><strong>カオスと問題を楽しむ</strong><br>
フレームややり方は決めずに、常にゼロベースで考えて進むのが重要であり何より面白い作業だと考えています。</p>
</blockquote>
<p>このように、プレイドには「フレームややり方は決めずに、常にゼロベースで考えて進む」ことを良しとする文化があります。</p>
<p>僕がすごく共感していて、実際にプレイドで仕事をする上で「良い」と感じているのが、この「常にゼロベースで考えて進む」という考え方・スタンスです。プレイドには多様なメンバーが所属していますが、ベースとしてこの考え方が根付いているように感じます。</p>
<p>そして、これによって『「型を守る」ことから始めないソフトウェア開発』がとてもやりやすくなっているように思います。意識しなくても気づいたら、そういう方向に思考が向いているというか、自然とそうなっているというか。</p>
<p>型（フレームややり方）を最初から作らずに、まずは問題をしっかり認識・理解した上で、自分たちにとって最適なやり方を作っていく。自然とそういう思考になるような、力学や雰囲気がプレイドには存在しています。</p>
<p>仮にそういう力学や雰囲気がないと、ついつい「フレームややり方」ありきで問題を解決しにいってしまうのではないでしょうか。</p>
<h1>大変だけど、楽しいし、価値があること</h1>
<p>ゼロベースで考えることはとても大変ことです。自分たちのプロダクトやチーム、個人のことを真剣に見つめ直す必要があります。辛くなる時ももしかしたらあるかもしれません。</p>
<p>ゼロベースで考えたことで、スピードがもの凄く遅くなっていては元も子もありません。フルスクラッチで解決策を考えるとはいえ、時間をかけすぎてはいけない、そういったプレッシャーの中で物事を考える必要があります。</p>
<p>それでも、その思考のプロセスが楽しいのです。これまでたくさんは使ってこなかった脳の部分をたくさん使う感じがします。</p>
<p>それが自分自身を成長させますし、何より、プロダクトやチームが抱えている問題を本質的に解決するための近道であり、さらには長期的なプロダクトの成長やユーザーへの価値向上に繋がると信じています。</p>
<p>それができる環境で僕は今働いていて、こうやって言葉を並べるだけではなく、自分の仕事をどんどん価値に繋げていきたいと、日々取り組んでいます。</p>
<h1>おわりに</h1>
<p>最近、「プレイドで働く上で楽しいこと、良かったことはなんですか？」と社外の人に質問される機会が何度かあったのですが、毎回上に書いたようなことを答えています。</p>
<p>具体的なエピソードを書いていないですが、それはまた別の機会に紹介できればと思います。</p>
<p>なお、この記事の内容は、あくまでも、僕個人の考え、僕個人から見たプレイドについての考えです。</p>
<p>プレイドのエンジニアチームは、幅広いスキル・バックグラウンド・ビジョンを持った多様なエンジニアで構成されており、なので、全然違うことを考えているエンジニアもいます。</p>
<p>この記事では、こういうことを考えているエンジニアもいますよ、という一例を紹介しました。</p>
<hr>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><br>
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</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 engineer blog

「型を守る」ことから始めないソフトウェア開発 ー 常にゼロベースで考える

<p>みなさん、ごきげんよう。プレイドの@tik-sonです。</p>
<p>現在、PLAIDエンジニア陣で<a href="https://codezine.jp/article/corner/711">CodeZineで連載</a>をしているのですが、<br>
今回は<a href="https://codezine.jp/article/detail/10674">KARTEを支える監視構成についての記事を書きました。</a></p>
<p>記事のリード文で紹介しているように、シビアな要件が求められる、大規模解析サービスの監視のポイントや、構成などを書いているので、是非とも御覧ください！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0c95bcdc-12bd-491a-baff-7aa28c0af6ed/image--2--2.png" alt="image"><br>
<a href="https://codezine.jp/article/detail/10674">大規模解析サービスを支える監視サービスと監視構成のポイント</a></p>


12.5億UUを解析するKARTEを支える監視構成について記事を書きました。

12.5億UUを解析する大規模解析サービスの監視構成 | PLAID engineer blog

12.5億UUを解析する大規模解析サービスの監視構成

<p>みなさん、ごきげんよう。プレイドの竹村(a.k.a. tik-son)です。<br>
2018/2/15,16に雅叙園東京で開催された <a href="http://event.shoeisha.jp/devsumi/20180215/">Developers Summit 2018</a>にて<a href="http://event.shoeisha.jp/devsumi/20180215/session/1621/">「マルチクラウドで構築する大規模解析サービス～戦略とポイントについて」</a> というテーマで登壇してきました。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dbe903fb-d3a5-46e2-ab12-5babcac9292c/Image-uploaded-from-iOS.jpg" alt="Image uploaded from iOS.jpg (2.7 MB)"></p>
<h1>発表内容</h1>
<p>最近、「マルチクラウド」という言葉をよく聞くようになりましたが、まだ世の中には具体的な話があまり出ていないなと感じていたので、「マルチクラウドでの構築/運用でのポイント」を出来る限り実例ベースでお話しました。<br>
<strong>6000events/secの負荷</strong>  を <strong>0.x秒で解析する</strong> KARTEの構築/運用を通して培ったマルチクラウドでの様々なノウハウが詰まっているので是非ともご覧いただければと思います。<br>
発表資料はこちらです。</p>
<div>
<script async class="speakerdeck-embed" data-id="d87b6e822d0149bb89f11cd50e18c9e6" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>この発表内容については、<a href="https://classmethod.jp/">クラスメソッド</a>さんにかなりいい感じにまとめてもらっているので、こちらもご覧いただければ理解を更に深めていただけると思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/51d7d4df-1512-4fae-b6bf-2f64e376da35/image.png" alt="image.png (211.4 kB)"></p>
<p><a href="https://dev.classmethod.jp/cloud/aws/devsumi2018-multicloud/">「ほんまに運用できるの？」毎秒6000イベントをミリsec対応するウェブサービスを、マルチクラウドで構築した話を聞いてきた #devsumi</a><br>
(タイトルが関西弁感出てるのは、関西弁で発表したからなのだろうか)</p>
<blockquote>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4f8b255c-b57b-4be9-90b5-1e1391884a7c/image--1-.png" alt="image.png (91.9 kB)"></p>
</blockquote>
<p>発表者冥利に尽きるありがたいお言葉もいただいております。</p>
<h1>デブサミに登壇してみて</h1>
<p>かなり大きな会場、たくさんの方に来場いただいたので、楽しく発表させていただくことができました。<br>
色々と喋りすぎてしまって、最後の方は結構時間がギリギリだったのはここだけの話です。<br>
また、Ask the speakerのコーナーでも来場者の方々と色々と質問、意見交換などをさせていただき、とても有意義な時間でした。<br>
お声がけをいただいた翔泳社さんを初め、デブサミ運営に携わっている皆様ありがとうございました。</p>
<p>一方で、来場いただいたようなDeveloperの方々には、KARTEって自分が思っていた以上に知られていないんだなと痛感し、このようなカンファレンスやTechBlogを通してもっとガンガン外部に発信することの重要性を感じました。<br>
KARTE内ではマルチクラウドをはじめとした、外に発信できる面白い取り組み/ノウハウがたくさんあるので、今後もこのTechBlogなどで積極的に発信していきたいと思います。</p>
<h1>最後に</h1>
<p>プレイドでは、今回お話したようなマルチクラウドインフラをガッツリ触って成長させたい！というエンジニアを募集しています。<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>
</div>


Developers Summit 2018にて「マルチクラウドで構築する大規模解析サービス～戦略とポイントについて」話してきました。

Developers Summit 2018に登壇してきました #devsumi |  PLAID engineer blog

Developers Summit 2018に登壇してきました #devsumi

ビッグデータよりストリームデータの時代！KARTEのリアルタイム解析でも使われているストリーム処理について学んでみる。

ストリーム処理を１からKappa Architectreまで学ぶ | PLAID engineer blog

ストリーム処理を１からKappa Architectreまで学ぶ

<p>こんにちは、プレイドの @makinoy です。<br>
久しぶりのBlog投稿です。書こうとして止めていた記事はひとまず置いといて今回新しく一つ記事を書くことにしました。<br>
テーマはNapa.jsを使ってJavaScriptでmulti-threadingをやってみる、です。</p>
<h4>背景</h4>
<p>フロントエンドからバックエンドまで含めて考えると、KARTEのコードの大部分はJavaScriptで書かれています。その理由の大半は、特にフロントエンドよりの話が多く、Angular.js, React.js, Vue.jsに代表されるWebフレームワークの著しい発展や、V8のパフォーマンスの進化、Node.jsやNPMなどその周辺のモジュールのエコシステムの充実が大きいと思います。</p>
<p>KARTE的には、スキーマレスな構造データを扱えることが特徴の一つなので、その周辺の操作に関しては動的言語が適しているというポイントもあります。それに、加えアーキテクチャ的な特徴から、解析処理とWeb上でのアクションがワンセットになっているということもあり、バックエンドでもフロントエンド実行されるデータの中身を評価する必要があったりします。そういう理由から、かなりCPUインテンシブな処理をJavaScriptで書き、その上で動しているの多いのが特徴です。（一部のコードはJavaやPythonを使っています。）</p>
<p>バックエンドのコードはNode.jsを使ってJavaScriptを実行しています。Node.jsは1 workerに対して1プロセスを割り当て、1CPUでイベントループを回すことによって処理します。(詳しくはこちら <a href="https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/">https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/</a>) I/Oインテンシブな処理が多いWebサーバーなどの場合、workerに対してスレッド割り当てるよりは、I/O待ちのプロセスに新規リクエストを処理させることで、コンテクストスイッチが少なくて高速です。</p>
<p>ですが、KARTEのように、Webのリクエスト処理中に解析処理も行うアプリケーションにとってみると、1 worker - 1 CPUの制約が少々ボトルネックになってくるという課題があります。基本的には、Node.jsのworkerを増やせばスループット的には問題ないと思います。ただ、KARTEの<strong>0.x秒で解析処理を終わらせリクエストを処理する</strong>ということを考えると、安定的に低レスポンスで処理しなればなりません。そうすると、どこかのCPU処理がたまたま多くリソースを使うと、その処理の影響が同じworkerの処理にも影響が出てしまいます。これを避けるには、自分でCPU処理を分割する、スレッドを使ってOSのスケジューラーに任せるなどの必要があります。あらかじめ自分でCPU処理を分割するのは大変なので、スレッドを使う方が楽です。ですがNode.js上では、JavaScriptのプログラムからスレッドを使うことはできません。</p>
<p>結構悩んでいる問題なので、背景がちょっと長くなってしまいました…<br>
つまり、JavaScript(Node.js)でスレッドが必要となるポイントは</p>
<ol>
<li>JavaScript便利</li>
<li>Node.jsとNPMが便利</li>
<li>でもNode.jsは基本的にI/Oインテンシブな処理に向いてる</li>
<li>CPUインテンシブな処理を効率的にしたいのでスレッドを使いたい</li>
</ol>
<p>という感じでしょうか。</p>
<p>そんな中、マイクロソフトが、CPUインテンシブな処理をJavaScriptでmulti-threadingを使って実現する仕組みであるNapa.js (<a href="https://github.com/Microsoft/napajs">https://github.com/Microsoft/napajs</a>) を作ったみたいなので、調べてみました。なぜ名前がNapaなのかは調べてません。Napa valleryのNapa? Nodeっぽいから？</p>
<h4>モチベーション</h4>
<p>Napa.jsも同様にJavaScriptの柔軟さとNode.jsがバックエンドとして使っているV8のパフォーマンスが高い点に着目して、さらにC++のハイパフォーマンス要素が融合すれば次の段階に進化できることを目指して作られてます。開発者が、C++とJavaScriptの利点をダイナミックにバランスをとっていけることを目指していて、例えば最初はJavaScriptで始め、固まってきたらC++に移していくようなことが気軽にできるになることを目指しています。</p>
<p>開発者のDaiyi Pengは4つのポイントの実現が重要だと言ってます。</p>
<ol>
<li>アルゴリズム上で素早くやり取り(反復)ができる。</li>
<li>マルチコアの利点を活かす</li>
<li>Workerが構造データを共有メモリでシェア</li>
<li>スレッド間の通信コストを最小にして可能な限り粒度が細かい並列処理を行う</li>
</ol>
<p>これを現時点でNode.jsで実現しようとすると、JavaScriptのasync関数としてC++のコードを使えるようにするか、Node.jsが持つclusterモジュールを使うかです。一つ目は、1を満たせず。二つ目は、3を満たせません。プロセスが別れてしまうと、データを受け渡すのにヒープメモリを使うことができないので、大変です。clusterモジュールを使う場合は、プロセス間通信を使ってデータをやり取りする必要があるので、worker間のデータのやり取りにコストがかかります。</p>
<h4>概要</h4>
<p>Napa.jsの設計概念と構成要素を紹介します。</p>
<h5>ゾーン (Zone)</h5>
<p>すべてのマルチスレッドワーカーは、ポリシー定義したりや実際にJavaScriptを実行するゾーン (zone)と呼ばれるものに属します。１プロセスに対して、複数のJavaScriptワーカーで構成されたゾーンが複数紐付きます。</p>
<p>ゾーンの中ではワーカーは同じコードをロードし、同じ<code>broadcast</code>や<code>execute</code>リクエスト（後で説明）を受け取り処理します。ゾーン内の一つのワーカーに対して選択的にリクエストを出すことはできません。一方で、異なるゾーンのワーカーどうしは非対称的です。アプリケーションは、複数のゾーンを異なるポリシーや目的のワークロードのために使い分けます。</p>
<h6>Napa zoneとNode zone</h6>
<p>ゾーンには2タイプあります。<strong>Napa zone</strong>と<strong>Node zone</strong>の二つです。Napa zoneは、切り離されたV8上のNapa.jsが管理するJavaScriptワーカーで構成されるゾーンです。Napa zoneではNode.jsのAPIが制限されています。Node zoneは、Node.jsのイベントループ上の仮想のゾーンで、Node.jsのAPIが全て使えます。Napa zoneは重いタスクをこなし、一方でNode zoneはIO処理やNode.jsのAPIを利用する、という形で互いに補完し合います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4280fa81-7c8f-4669-ab22-84e1f080a678/a.png" alt="a.png (37.6 kB)"></p>
<h5>BroadcastとExecute</h5>
<p>ゾーン上ではBroadcastとExecuteという二つのオペレーションを実行できます。</p>
<p>Broadcastはすべてのワーカーの状態を変更するコードを走らせます。その実行が成功したか失敗したかをPromise経由で受け取ることができます。起動やあらかじめキャッシュを作っておくなどするときに使います。</p>
<p>Executeはワーカーの状態を変更しないでコードを走らせます。実際にタスクを実行するときはこちらを使用し、Promise経由で計算結果を受け取ることができます。</p>
<h5>オブジェクト転送</h5>
<p>V8は、複数の分離したメモリ空間でJavaScriptを走らせるように作られていません。なので、ヒープメモリは、それぞれで管理する必要があり、値を別のV8に渡すには、シリアライズ/デシリアライズ(marshall/unmarshall)する必要があります。なので、オブジェクトのペイロードのサイズや複雑性は、通信効率に大きな影響を与えます。</p>
<h6>Transportable型</h6>
<p>Transportable（トランスポート可能な）な型は、他のV8に渡すことができ、ワーカー間で透過的なJavaScriptの型です。broadcastやexecuteの引数として渡すことができ、ワーカー間の共有オブジェクトにset/getで渡すこともできます。</p>
<p>Transportable型は、1. JavaScriptのプリミティブ、2.Transportableインタフェースを実装したオブジェクト(Typescript)、3.これらのコンポジットでできているArrayとオブジェクト、4. undefinedです。</p>
<h5>ワーカー間ストレージ</h5>
<p>Store APIはJavaScriptのワーカー間でtransportableな型を共有するために必要なAPIです。<code>store.set</code>するとそのプロセスのヒープにJSONでシリアライズされ保存され、すべてのスレッドは<code>store.get</code>でシリアライズして受け取ることができます。</p>
<p>参照カウントされているので自動でGCされるようです。Worker間でメモリがシェアされたとしても、GCがある言語上でGCがない部分でデータを自分で管理しようとすると大変です。</p>
<h5>メモリ管理</h5>
<p>APIとしてnapajsメモリを触れるものも用意してあるようです。ポインタを表す<code>Handle</code>、 Native Objectをワーカー間でシェアできる<code>Shareable</code>、メモリを確保する<code>Allocator</code>が用意されいるようですが、詳細に関してはあまり記述が無いです。</p>
<h5>C++モジュール</h5>
<p>Node.jsと同様にC++を使ったモジュールを作成できるようになるみたいですが、APIの詳細はまだ固まっていないようです。</p>
<h4>試してみる</h4>
<p>では実際に試してみましょう。</p>
<h5>インストール</h5>
<pre><code class="language-shell">npm install napajs
</code></pre>
<h5>実行</h5>
<h6>ゾーンの作成</h6>
<pre><code class="language-js">const napajs = require('napajs');
const zone = napajs.zone.create('simple-zone', {wokers: 8});
</code></pre>
<h6>Nodeゾーンにアクセス</h6>
<pre><code class="language-js">const node_zone = napajs.zone.node;
</code></pre>
<h6>boradcastしてexecute</h6>
<pre><code class="language-js">function f() {
  console.log('hi');
}
// fを定義
zone.broadcast(f.toString());
// 定義したfを実行
zone.execute(() =&gt; { f() });
// &gt; hi
</code></pre>
<h6>transportableかチェック</h6>
<pre><code class="language-js">napajs.transport.isTransportable(undefined)
// &gt; true
// napajs.transport.isTransportable(null)
// TypeError. bug
napajs.transport.isTransportable({a:1})
// &gt; true
napajs.transport.isTransportable({a:1, b:/regexp/})
// &gt; false
</code></pre>
<h6>marshall / unmarshall</h6>
<pre><code class="language-js">var jsonPayload = transport.marshall([1, 'string'], context);
console.log(jsonPayload);
// [1,&quot;string&quot;]
napajs.transport.unmarshall(jsonPayload, context);
// &gt; [ 1, 'string' ]
</code></pre>
<h6>store</h6>
<pre><code class="language-js">var zone = napajs.zone.create('zone1');
var store = napajs.store.create('store1');

store.set('key1', { 
    a: 1, 
};

zone.execute(() =&gt; {
    var store = global.napa.store.get('store1'); // globalにnapaが定義されている
    console.log(JSON.stringify(store.get('key1')));
});
// &gt; {&quot;a&quot;;1}
</code></pre>
<h5>フィボナッチ数列を計算する</h5>
<p>並列計算の例ではみんな大好きフィボナッチ</p>
<pre><code class="language-js">var napa = require(&quot;napajs&quot;);
var zone = napa.zone.create('zone', { workers: 4 });

function fibonacci(n) {
    if (n &lt;= 1) {
        return n;
    }

    var p1 = zone.execute(&quot;&quot;, &quot;fibonacci&quot;, [n - 1]);
    var p2 = zone.execute(&quot;&quot;, &quot;fibonacci&quot;, [n - 2]);

    return Promise.all([p1, p2]).then(([result1, result2]) =&gt; {
        return result1.value + result2.value;
    });
}

function run(n) {
    var start = Date.now();

    return zone.execute('', &quot;fibonacci&quot;, [n])
        .then(result =&gt; {
            console.log(n, result.value, Date.now() - start);
            return result.value;
        });
}

// 初期化
zone.broadcast(' \
    var napa = require(&quot;napajs&quot;); \
    var zone = napa.zone.get(&quot;zone&quot;); \
');
zone.broadcast(fibonacci.toString());

// 実行
run(10)
.then(() =&gt; run(11))
.then(() =&gt; run(12))
.then(() =&gt; run(13))
.then(() =&gt; run(14))
.then(() =&gt; run(15))
.then(() =&gt; run(16))
.then(() =&gt; run(17))
.then(() =&gt; run(18))
.then(() =&gt; run(19))
.then(() =&gt; run(20))
.then(() =&gt; run(21))
.then(() =&gt; run(22))
</code></pre>
<p>上のコードをworkers:1, 2, 4で計算したら、手元のMac( 2.5 GHz Intel Core i7 4 cores)フィボナッチ数22がそれぞれ、3.7 sec, 1.8 sec, 1.3 sec程度で計算ができ、CPUコアを有効に使えてるることがわかりました。かなり粒度が細かい並列実行ですが、オーバーヘッドも少なさそうです。</p>
<h4>まとめ</h4>
<p>JavaScriptでmulti-threadingするNapa.jsについて、それが(PLAIDにとっても)必要となる背景から、その概要について、まとめてみました。まだ、bugがあったりして生まれたて感があるようですが、threadを使った並列化コードをシンプルに書くことができて非常に使えそうな印象があります。このような技術を使って、データ解析のようなCPUインテンシブな処理もJavaScriptでメンテナンスできるようになると嬉しいですね。</p>
<h4>参考</h4>
<p><a href="https://github.com/Microsoft/napajs/wiki">https://github.com/Microsoft/napajs/wiki</a><br>
<a href="https://github.com/Microsoft/napajs/wiki/introduction">https://github.com/Microsoft/napajs/wiki/introduction</a><br>
<a href="https://github.com/Microsoft/napajs/wiki/why-napa.js">https://github.com/Microsoft/napajs/wiki/why-napa.js</a><br>
<a href="https://github.com/Microsoft/napajs/tree/master/examples/tutorial/recursive-fibonacci">https://github.com/Microsoft/napajs/tree/master/examples/tutorial/recursive-fibonacci</a><br>
<a href="https://www.linkedin.com/pulse/napajs-multi-threaded-javascript-runtime-daiyi-peng/">https://www.linkedin.com/pulse/napajs-multi-threaded-javascript-runtime-daiyi-peng/</a></p>
<h4>最後に</h4>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><br>
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</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>


今回の記事のテーマはNapa.jsを使ってJavaScriptでmulti-threadingをやってみる、です。

MicrosoftのNapa.jsでJavaScriptをマルチスレッド化する | PLAID engineer blog

MicrosoftのNapa.jsでJavaScriptをマルチスレッド化する

<p>こんにちは。エンジニアの@elcih17です。<br>
<a href="/webdb-forum-2016/">この記事</a>を書いた頃はインターンでしたが、現在は新卒エンジニアとして日々奮闘しています。</p>
<p>最近、APIの設計に関することを調べていたら「GraphQL」という言葉をよく見かけました。<br>
API用の技術として注目されているそうで、<strong>REST APIの次のパラダイムだ</strong>という意見もあるようです。</p>
<p>どんな技術なのかとても気になり<a href="https://www.howtographql.com/">HOW TO GRAPHQL</a>のチュートリアルと簡単な実装をしてみたら、なんとなくGraphQLのことがわかったので書いてみます。</p>
<p><strong>実装例</strong></p>
<ul>
<li>バックエンド (express-graphql) <a href="https://github.com/elcih17/graphql-example/tree/master/graphql-server">graphql-server</a></li>
<li>フロントエンド (vue-apollo) <a href="https://github.com/elcih17/graphql-example/tree/master/vue-apollo">vue-apollo-example</a></li>
</ul>
<h2><a href="http://graphql.org/">GraphQL</a> とは</h2>
<ul>
<li>API用のクエリ言語</li>
</ul>
<h2>特徴</h2>
<ul>
<li>シングルエンドポイント</li>
<li><strong>複数のリソース</strong>の欲しいデータを<strong>1リクエスト</strong>で取得できる</li>
<li>スキーマ定義と型システム</li>
</ul>
<h2>機能</h2>
<h3>Query</h3>
<p>RESTにおけるGET</p>
<p><strong>idが&quot;1&quot;のユーザーの名前と年齢を取得する</strong>GraphQLは次のように書けます。</p>
<pre><code class="language-graphql">query {
  user(id:&quot;1&quot;) {
    name
    age
  }
}
</code></pre>
<p>response</p>
<pre><code class="language-json">{
  &quot;data&quot;: {
    &quot;user&quot;: {
      &quot;name&quot;: &quot;elcih17&quot;,
      &quot;age&quot;: 22
    }
  }
}
</code></pre>
<h3>Mutation</h3>
<p>RESTにおけるPOST、PUT、DELETE</p>
<p><strong>新規ユーザーを作成する</strong>GraphQLは次のように書けます。</p>
<pre><code class="language-graphql">mutation {
  createUser(id: &quot;2&quot;, name: &quot;KARTE&quot;, age:2) {
    name
    age
  }
}
</code></pre>
<p>response</p>
<pre><code class="language-json">{
  &quot;data&quot;: {
    &quot;user&quot;: {
      &quot;id&quot;: &quot;2&quot;,
      &quot;name&quot;: &quot;KARTE&quot;,
      &quot;age&quot;: 2
    }
  }
}
</code></pre>
<h3>Subscription</h3>
<p>QueryとMutationの実行をsubscribeできる</p>
<p>試してないので詳しくはわかりませんが、データの更新を受け取って何かしたいときに使えそうです。</p>
<h2>GraphQLの何が良いのか</h2>
<ul>
<li>不要なデータの取得と無駄なリクエストを防げる</li>
<li>スキーマと型定義によってAPIが提供する機能が明確になる</li>
<li><a href="https://github.com/graphql/graphiql">GraphiQL</a>が便利</li>
</ul>
<h3>不要なデータの取得と無駄なリクエストを防げる</h3>
<p><strong>複数のリソースの欲しいデータを1リクエストで取得できる</strong> ので無駄が無くなります。<br>
例えば、<strong>あるユーザーの名前と投稿記事タイトルと記事についたコメントを取得する</strong>ケースを考えてみます。</p>
<p><strong>RESTの場合</strong></p>
<ol>
<li><code>GET /users/:id</code></li>
<li><code>GET /users/:id/posts</code></li>
<li><code>GET /posts/:id/comments</code></li>
<li>取得したデータからそれぞれ名前、記事のタイトル、コメントを抽出します</li>
</ol>
<p><strong>GraphQLの場合</strong></p>
<ol>
<li><code>/graphql</code>に対し下記のようなクエリをリクエストします</li>
</ol>
<p>必要なデータのみ取得しているのでデータを抽出する必要はありません</p>
<pre><code class="language-graphql">query {
  user(id: &quot;1&quot;) {
    name
    posts {
      title
        comments {
        content
      }
    }
  }
}
</code></pre>
<h3>スキーマと型定義によってAPIが提供する機能が明確になる</h3>
<ul>
<li>入出力と型を定義することによって何が出来るかかが分かりやすい</li>
<li>後述するGraphiQLで見ることが出来るAPIドキュメントはスキーマ定義から自動生成される</li>
</ul>
<h3><a href="https://github.com/graphql/graphiql">GraphiQL</a>が便利</h3>
<ul>
<li>GraphQLのIDE</li>
<li>APIドキュメントの閲覧とクエリの実行ができる</li>
<li>デバッグがしやすい
<ul>
<li>クエリをサクサク試せる</li>
<li>エラーメッセージがわかりやすい</li>
</ul>
</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/34e38b86-2c72-4147-ad5b-1217475aeb62/----------2017-08-28-23.37.56.png" alt=""></p>
<h2>GraphQLサーバーの例(express-graphql)</h2>
<p>Query、Mutationの機能紹介で例示したクエリを実行可能にするための実装はこのようになります</p>
<p><strong>GraphQLスキーマの定義 (GraphQLの入出力と型定義)</strong></p>
<ul>
<li><code>!</code>は<code>required</code></li>
</ul>
<pre><code class="language-graphql">type Query {
  user(id: String!): User! // relation
}
type Mutation {
  createUser(id: String!, name: String!, age: Int!): User // relation
}
type User {
  id: String!
  name: String!
  age: Int!
}
</code></pre>
<p><strong>リゾルバ関数の実装 (GraphQLとバックエンド処理のマッピング)</strong></p>
<pre><code class="language-js">const users = [
  {
    id: '1',
    name: 'elcih17',
    age: 22
  }
]
const resolvers = {
  Query: {
    user: (root, {id}) =&gt; {
      return users.find(user =&gt; user.id === id)
    }
  },
  Mutation: {
    createUser: (root, args) =&gt; {
      const {id, name, age} = args
      const newUser = {id, name, age}
      users.push(newUser)
      return newUser
    }
  }
};
</code></pre>
<h4>GraphQLオブジェクトとrelation(関連づけ)を使う</h4>
<p>標準のオブジェクトタイプ(<code>Query</code> 、<code>Mutation</code>、<code>Subscription</code>)以外にも独自のオブジェクトを定義できます。<br>
また、定義したオブジェクト同士のrelationが可能です。</p>
<p><strong>スキーマ</strong></p>
<pre><code class="language-graphql">type User {
  name: String!
  posts: [Post]
}
type Post {
   author: User!
   title: String!
}
</code></pre>
<p>relationを使えば次のようなクエリを受け取った際にデータを構築するのが簡単になります。</p>
<pre><code class="language-graphql">query {
  user(id: &quot;1&quot;) {
    posts {
      title
    }
  }
}
</code></pre>
<p><strong>リゾルバ (データの構築)</strong></p>
<pre><code class="language-js">Query: {
 user: (root, args) =&gt; {
    const {id} = args
    return users.find(user =&gt; user.id === id)
 }
},
User: {
  posts: (author) =&gt; {
    const {id} = author
    return posts.filter(post =&gt; post.author_id === id)
  }
}
</code></pre>
<p>GraphQLクエリの実行の流れについては<a href="https://dev-blog.apollodata.com/graphql-explained-5844742f195e">この記事</a>が分かりやすいです。</p>
<p><a href="https://github.com/elcih17/graphql-example/tree/master/graphql-server">実装例</a>ではMongoDBに接続して実装してみました。</p>
<p><strong>所感</strong></p>
<ul>
<li>GraphiQLのおかげでデバッグがしやすくて良い</li>
<li>GraphQLのスキーマ定義とDBのスキーマ定義が二重管理になって面倒
<ul>
<li>DBのスキーマからGraphQLスキーマを生成するようなライブラリが出てくれば楽になるかも</li>
</ul>
</li>
</ul>
<h2>フロントエンドGraphQL</h2>
<p>現在、GraphQLを扱うためのClientに <a href="http://dev.apollodata.com/">Apollo</a> と <a href="https://facebook.github.io/relay/">Relay</a> があります。</p>
<p>RelayはReact用に構築されていてApolloはそのほかのフレームワークにも対応しているようです。<br>
React + Apolloという組み合わせもあるので、Reactを使っている人はRelayとApolloを比べてみても面白いかもしれません。</p>
<p>今回は<a href="https://github.com/Akryum/vue-apollo">vue-apollo</a>を使うためにApolloを使用してみました。</p>
<p>一部実装例を載せておきます。</p>
<p>src/main.js</p>
<pre><code class="language-js">import 'isomorphic-fetch'

import Vue from 'vue'
import {ApolloClient, createNetworkInterface} from 'apollo-client'
import VueApollo from 'vue-apollo'
import App from './App.vue'

const uri = 'http://localhost:3000/graphql'
const networkInterface = createNetworkInterface({
  uri,
  transportBatching: true,
})

Vue.use(VueApollo)

const apolloClient = new ApolloClient({networkInterface})
const apolloProvider = new VueApollo({
  defaultClient: apolloClient,
})

new Vue({
  el: '#app',
  apolloProvider,
  render: h =&gt; h(App),
})
</code></pre>
<p>src/App.vue</p>
<pre><code class="language-html">&lt;!-- template --&gt;

&lt;div id=&quot;app&quot;&gt;
  &lt;h1&gt; Vue Apollo Example &lt;/h1&gt;
  &lt;p&gt;{{hello}}&lt;/p&gt;

  &lt;label&gt;name&lt;/label&gt;
  &lt;input type=&quot;text&quot; v-model=&quot;userName&quot;&gt;

  &lt;label&gt;age&lt;/label&gt;
  &lt;input type=&quot;number&quot; v-model=&quot;userAge&quot;&gt;

  &lt;a href=&quot;#&quot; @click=&quot;createUser&quot;&gt;createUser&lt;/a&gt;

  &lt;div v-if=&quot;createdUser&quot;&gt;
    &lt;p&gt;User created!&lt;/p&gt;
    &lt;p&gt;name: {{createdUser.name}}&lt;/p&gt;
    &lt;p&gt;age: {{createdUser.age}}&lt;/p&gt;
  &lt;/div&gt;
&lt;/div&gt;
</code></pre>
<pre><code class="language-js">// script

import gql from 'graphql-tag';

const helloGQL = gql`
  query {
    hello
  }
`;
const createUserGQL = gql`
  mutation ($userName: String!, $userAge: Int!){
    createUser(name: $userName, age: $userAge) {
      _id
      name
      age
    }
  }
`
export default {
  name: 'app',
  data() {
    return {
      hello: '',
      userName: '',
      userAge: '',
      createdUser: null
    };
  },
  apollo: {
    hello: {
      query: helloGQL,
    }
  },
  methods: {
    createUser() {
      this.$apollo.mutate({
        mutation: createUserGQL,
        variables: {
          userName: this.userName,
          userAge: this.userAge
        }
      }).then(res =&gt; {
        this.createdUser = res.data.createUser
      }).catch(err =&gt; {
        console.error(err);
      })
    }
  }
};
</code></pre>
<p>詳細は<a href="https://github.com/elcih17/graphql-example/tree/master/vue-apollo">実装例</a>をご覧ください。</p>
<p><strong>所感</strong></p>
<ul>
<li>欲しいデータだけを1リクエストで取得できるのは確かに良さそう
<ul>
<li>しかし、rootのデータを取得してロジックで整形みたいなことをするとRESTとあまり変わらない</li>
<li>不要なデータ取得と無駄なリクエストを実際に減らせるかは使用者次第という感じ</li>
</ul>
</li>
<li>エンドポイント × GraphQLクエリの分だけ管理が必要なので複雑になってくるとツラそう</li>
</ul>
<h2>プロダクションで使えるか？</h2>
<p>現在プロダクション環境でGraphQL APIを運用しているサービスはGithub、Coursera、Twitterなどがあるようです。<br>
Githubの<a href="https://developer.github.com/v4/">GraphQL API v4</a>を見る限り、運用の仕組みを作れば十分使えそうな気がします。</p>
<p>プロダクションで運用・提供するに当たって考慮する必要がありそうなこと</p>
<ul>
<li>バックエンド
<ul>
<li>クエリ(スキーマ)のライフサイクル管理
<ul>
<li>deprecatedフィールドなど</li>
</ul>
</li>
<li>クエリのキャッシュ管理
<ul>
<li><a href="http://graphql.org/learn/caching/">フィールドにGlobal Unique IDを持たせる方法など</a>があるようです</li>
</ul>
</li>
<li>セキュリティ
<ul>
<li>巨大なクエリ、複雑なクエリへの対策
<ul>
<li>タイムアウト処理</li>
<li>クエリの実行回数制限</li>
<li>1クエリのfield数制限</li>
<li>1クエリのネスト(深さ)制限</li>
</ul>
</li>
<li>Githubの<a href="(https://developer.github.com/v4/guides/resource-limitations/)">Rate limits</a>が参考になります</li>
</ul>
</li>
</ul>
</li>
<li>フロントエンド
<ul>
<li>クエリが自由にかけて属人性が高い</li>
<li>規約が必要になることもあるかも？</li>
</ul>
</li>
</ul>
<h2>まとめ</h2>
<ul>
<li>クエリが直感的に書ける
<ul>
<li>必要なデータだけをリクエストできるので分かりやすい</li>
<li>自由に書けるので複雑なクエリをリクエストされるリスクもある</li>
</ul>
</li>
<li>GraphiQLが便利</li>
<li>不要なデータ取得、無駄なリクエストを減らせるのは大きなメリット</li>
<li>プロダクションで運用する際にはセキュリティ対策は必須</li>
</ul>
<p>以上で説明を終わります。</p>
<p>GraphQLについて少しはわかっていただけたでしょうか？<br>
今回紹介できなかった機能を使えばもっと色々とできて面白そうなので興味のある方はぜひ試してみてください。</p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit.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>


API用の技術として注目されている「GraphQL」をexpress + Vueで実装して試してみました！


express-graphql + vue-apollo で GraphQLを試してみた | PLAID engineer blog

express-graphql + vue-apollo で GraphQLを試してみた

<p>こんにちは、お久しぶりです、プレイドの @makinoy です。ブログ記事を書こう書こうと思い、2,3記事下書きを残しながらも、最後まで書き終えられていません。</p>
<p>そんな中、今日からPLAIDエンジニア陣でCodeZineで連載をはじめまして、ブログを書かずに連載の第一回の記事を書いてしまいました。そのうち、またブログの記事を書きたいと思います。</p>
<p>今回の連載は、**”大規模解析サービスを支えるGCP活用事例”**というタイトルで、GCPの利用例を中心に大量のデータをリアルタイムに捌くKARTEの裏側の話が中心です。</p>
<p>第一回の今回は、GCPがどういう役割を果たしているかという全体的な話を**”大規模データ解析サービス実現のために、Google Cloud Platformが果たす役割”**というタイトルで書きました。いろんな人に読んでもらうために、少々GCPの広告のようなタイトルになってますが、中身は前提知識そこまでなく8割ぐらい読める内容を書いたつもりです。ぜひ、読んでいただければと思います。記事はこちら。</p>
<p><a href="http://codezine.jp/article/detail/10350">大規模データ解析サービス実現のために、Google Cloud Platformが果たす役割</a></p>
<p>次回以降も、なかなか良い感じに濃い内容になりそうなので、ぜひ読み続けていただければと思います。</p>


今回の連載は、”大規模解析サービスを支えるGCP活用事例”というタイトルで、GCPの利用例を中心に大量のデータをリアルタイムに捌くKARTEの裏側...

CodeZineで、解析サービスの裏側とGCPについて連載はじめました

<p>こんにちは、PLAIDのエンジニアの池上 a.k.a. gami(@jumpei_ikegami) です。</p>
<p>好きなブキは、「プロモデラーMG」です。</p>
<p>さて今回は、仕事で調査用の「Chrome拡張機能」を作ったので、「Chromeデベロッパーツール」に「独自ツール」を追加するための手順について紹介したいと思います。</p>
<h1>Chromeデベロッパーツール、使っていますか？</h1>
<p>弊社では、「<a href="https://karte.io/">KARTE</a>」というサービスを開発しています。</p>
<p>「KARTE」の主な機能として、サイトにJavaScriptのタグを埋め込んでもらい、サイト上からユーザーの行動履歴や属性情報を取得し、それに応じたコンテンツをサイト上に配信するというものがあります。</p>
<p>しかし、「KARTE」の「タグ」が正しく設置されていないと、ユーザーの情報が取得できず、コンテンツの配信が思ったようにできないことがあります。</p>
<p>そんなときは、「Chromeデベロッパーツール」を使って、お客様のサイトで「KARTE」が動作しない原因を調査します。</p>
<p>例えば、「Elementsタブ」では、サイトのHTMLを見て、実際にscriptタグでJavaScriptの「タグ」が埋まっているかを確認できます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6a87df74-810b-4245-b832-c2155a579030/----------2017-08-14-4.47.14.png" alt=""></p>
<p>JavaScriptのオブジェクトがページ上から参照できるようになっているかは、「Consoleタブ」でそのオブジェクトを実際に参照してみるとわかります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fce82a31-ebc1-4d72-9ab0-afae7bca9c35/----------2017-08-14-4.51.50.png" alt=""></p>
<p>また、サーバーとの間の通信内容を追いたい場合は、「Networkタブ」から見ることができます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7b56e220-563c-4056-9231-a7c0cde0edbc/----------2017-08-14-4.46.36.png" alt=""></p>
<p>これらを駆使して、サイト上のあらゆる情報にアクセスすることができます。</p>
<p>フロント寄りのWebエンジニアであれば、サイトの状態を可視化するために「Chromeデベロッパーツール」など、ブラウザの「開発者向け機能」を使う機会は多いと思います。</p>
<h1>Chromeデベロッパーツールでは物足りない！</h1>
<p>しかし、「Chromeデベロッパーツール」がデフォルトで提供する機能だけでは物足りなくなることがあります。</p>
<p>当たり前ですが、「Chromeデベロッパーツール」は、どんなWebサイトでも使える機能だけが入っており、中立的に作られています。</p>
<p>しかし、「KARTE」の「タグ」が正しく設置されているかの調査であれば、「ブラウザ」と「KARTEのサーバー」との間の通信有無だけが可視化されれば事足ります。</p>
<p>あわよくば、「KARTEのサーバー」との間の通信内容だけを見やすく表示することができれば、さらに便利になります。</p>
<p>こうしたニーズに応えるために、「Google Chrome」では、デベロッパーツールを拡張して、独自のタブを追加することができます。</p>
<h1>デベロッパーツール拡張の例</h1>
<p>「Chromeデベロッパーツール拡張機能」の例としては、Web系のフレームワークに関するものが多くあるようです。</p>
<p>例えば、弊社でも使っている「Vue.js」にも、「<a href="https://chrome.google.com/webstore/detail/vuejs-devtools/nhdogjmejiglipccpnnnanhbledajbpd?hl=ja">Vue.js devtools</a>」というChrome拡張が用意されています。</p>
<p>インストールすると、「Vue.js」を使っているサイトで機能がアクティブになり、デベロッパーツールに「Vue」というタブが追加されます。</p>
<p>「Vue」タブの中では、サイトで検知された「Vue」のバージョンや、「Vue Component」の中身が、可視化されます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b9b39063-78ed-4394-85c3-44a62fff53f8/----------2017-08-14-5.15.29.png" alt=""></p>
<p>他にも、Googleが公開している「<a href="https://developer.chrome.com/devtools/docs/extensions-gallery">Featured DevTools Extensions</a>」のページを見ると、「React」、「Angular」、「Rails」、「jQuery」などでも同様のツールがあるようです。</p>
<h1>KARTEデベロッパー向けツールを作った</h1>
<p>これらの例を参考に、「KARTE」の「タグ」が正常に発火しているかを調査するための「Chromeデベロッパーツール拡張機能」を作りました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5f50e51f-6074-490f-bb0b-02b51affba46/----------2017-08-14-5.30.51.png" alt=""></p>
<p>「KARTE」のサーバーとの間の通信を監視し、ユーザー情報に当たる部分のみを取得して「KARTEタブ」の中に表示しています。</p>
<p>タブ内のUI制御には、「Vue.js」を使っています。</p>
<p>残念ながらソースコードは非公開なので、以下では「Chromeデベロッパーツール拡張機能」の簡単なサンプルを作ってみます。</p>
<h1>Twitter検出ツールを作ってみる</h1>
<p>ここでは、「Chromeデベロッパーツール拡張機能」の作り方を紹介しながら、サイト上にTwitterの「埋め込みTL」や「Followボタン」が設置されているかどうかを瞬時に見極めるツールを、「Chromeデベロッパーツール」内に作ってみます。</p>
<h2>ステップ1. ディレクトリ作成</h2>
<p>「Chrome拡張機能」に読み込ませるディレクトリを作成します。</p>
<p><code>$ mkdir chrome-extension-sample</code></p>
<p><code>$ cd chrome-extension-sample</code></p>
<p>以下、全てのファイルは<code>chrome-extension-sample</code>ディレクトリ直下に置いていきます。</p>
<h2>ステップ2. デベロッパーツールにタブを追加する</h2>
<p>次に、デベロッパーツールに独自タブを追加します。</p>
<p>以下が、Googleの公式概念図です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3fe1d071-7f95-41a5-b36e-7adb52e9a779/devtools-extension.png" alt=""></p>
<p>（出典: https://developer.chrome.com/extensions/devtools ）</p>
<p>これを見ると、「DevTools page」に「Panel」が複数格納されていることがわかります。<br>
この「Panel」一つ一つが、「Chromeデベロッパーツール」内のタブとして表示されます。</p>
<p>まず、<code>manifest.json</code>という名前でjsonファイルを作成し、以下のように記述します。</p>
<pre><code class="language-json">{
  &quot;name&quot;: &quot;Twitter Detector&quot;,
  &quot;manifest_version&quot;: 2,
  &quot;version&quot;: &quot;1&quot;,
  &quot;devtools_page&quot;: &quot;devtools.html&quot;
}
</code></pre>
<p>ここでは、「Chrome拡張機能」としての設定を記述します。<br>
<code>devtools_page</code>の値に指定した<code>devtools.html</code>が、DevTools pageのエントリーポイントになります。</p>
<p>manifest.jsonの詳しい仕様については、<a href="https://developer.chrome.com/extensions/manifest">Manifest File Format</a>を参照してください。</p>
<p>次に、<code>manifest.json</code>で指定した<code>devtools.html</code>を、以下の内容で作成します。</p>
<pre><code class="language-html">&lt;!DOCTYPE html&gt;
&lt;html&gt;
  &lt;head&gt;
    &lt;script src=&quot;./devtools.js&quot;&gt;&lt;/script&gt;
  &lt;/head&gt;
  &lt;body&gt;
  &lt;/body&gt;
&lt;/html&gt;
</code></pre>
<p>そして、<code>devtools.html</code>内で読み込んだ<code>devtools.js</code>を、以下の内容で作成します。</p>
<pre><code class="language-js">chrome.devtools.panels.create(
  &quot;TWDetector&quot;,
  &quot;&quot;, // icon画像を指定できる
  &quot;./panel.html&quot;,
  (panel) =&gt; {} // callback
);
</code></pre>
<p>ここでは、chromeのAPIを使って、<code>TWDetector</code>という名称のPanelを新たに追加しています。</p>
<p>具体的には、ChromeのAPIである「<a href="https://developer.chrome.com/extensions/devtools_panels#method-create">chrome.devtools.panels.create</a>」に対して、第一引数に「Panel」の名前を、第三引数に「Panel」表示用htmlファイル名を渡します。</p>
<p>最後に、<code>devtools.js</code>内で指定した、<code>panel.html</code>(「Panel」用のhtmlファイル)を以下の内容で作成します。</p>
<pre><code class="language-html">&lt;!DOCTYPE html&gt;
&lt;html&gt;
  &lt;head&gt;
    &lt;meta charset=&quot;utf-8&quot;&gt;
  &lt;/head&gt;
  &lt;body&gt;
    &lt;h1&gt;Twitter Detactor&lt;/h1&gt;
    &lt;h2 id=&quot;message&quot;&gt;&lt;/h2&gt;
    &lt;script src=&quot;./panel.js&quot;&gt;&lt;/script&gt;
  &lt;/body&gt;
&lt;/html&gt;
</code></pre>
<p>h2タグ内には、後でメッセージを表示させます。</p>
<p>ここまでできたら、試しにChromeに読み込ませて見ます。</p>
<p>アドレスバーに <code>chrome://extensions/</code> と入力し、「Chrome拡張機能」の「設定画面」に移動します。</p>
<p>右上の「デベロッパーモード」にチェックを付け、「パッケージ化されていない拡張機能を読み込む」ボタンから、「chrome-extension-sampleディレクトリ」を読み込むます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dfc41cf6-6ad2-4540-bb77-a76f60cfd20c/----------2017-08-14-11.26.11.png" alt=""></p>
<p>その後、<a href="https://plaid.co.jp/">適当なページ</a>に遷移して、「Chromeデベロッパーツール」を開きます。</p>
<p>作業が全てうまくいっていれば、一瞬遅れて「TWDetectorタブ」が追加されます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/aa608450-572b-45c7-a016-96ee800fdca6/----------2017-08-14-6.16.21.png" alt=""></p>
<p>ここまでで、無事に「Chromeデベロッパーツール」内に自由にカスタマイズできる領域を作ることに成功しました。<br>
あとは、ここを好きなようにいじっていきます。</p>
<h2>ステップ3. ログを出す</h2>
<p>「Panel」の表示を作っていく前に、「Chromeデベロッパーツール」内から、Consoleにログを出してみます。</p>
<p>まず、<code>panel.html</code>内で読み込んだ<code>panel.js</code>を、以下の内容で作成します。</p>
<pre><code class="language-js">console.warn(&quot;hoge&quot;);
</code></pre>
<p>コードの変更を再読み込みするには、デベロッパーツールを一度閉じてから開き直します。</p>
<p>早速、「TWDetectorタブ」の横にある「Consoleタブ」を開いて、logを確認しましょう。</p>
<p>はい、何も出ていません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/89795e24-31f9-4a5d-a30e-e71e91d06b9b/----------2017-08-14-6.28.57.png" alt=""></p>
<p>実は、ここで見ている「Consoleタブ」は「対象のWebページ」に対するコンソールであり、「Chromeデベロッパーツール」それ自体に対するコンソールは別の場所にあります。</p>
<p>そのコンソールを見るためには、「Chromeデベロッパーツール」を「別ウィンドウで表示」(&quot;Undock into separate window&quot;)し、表示されたそのウィンドウに対して、更にデベロッパーツールを開きます。</p>
<p>Macでは、「TWDetectorタブ」を開いているデベロッパーツールを別Windowにし、そのWindowをアクティブにした状態で、</p>
<ul>
<li>表示 &gt; 開発 /管理 &gt; デベロッパー ツール</li>
</ul>
<p>を選択します。<br>
ショートカットキーでも表示させることができます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6dc2cdc7-407c-44e9-9dca-802a200e824b/----------2017-08-14-6.24.25.png" alt=""></p>
<p>実際に表示をしてみると、問題なくlogがはき出されていることが確認できます。</p>
<h2>ステップ4. Twitterのサーバーへのリクエストを検知する</h2>
<p>いよいよ、実際の機能を追加していきます。</p>
<p>簡単な機能として、デベロッパーツールの「Networkタブ」に出ているようなブラウザからのリクエストの内容を監視し、urlに「twitter」と含まれている場合だけメッセージを画面に表示してみます。</p>
<p><code>panel.js</code>に、以下の記述を追加します。</p>
<pre><code class="language-js">chrome.devtools.network.onRequestFinished.addListener((req) =&gt; {
  const url = req.request.url;
  if (url.indexOf(&quot;twitter&quot;) !== -1) {
    console.log(`req:${JSON.stringify(req)}`); // ついでに、requestの内容をconsoleに表示
    document.getElementById(&quot;message&quot;).innerText = &quot;このサイトから、Twitterの香りがするでゲソ&quot;;
  }
});
</code></pre>
<p>ブラウザからのリクエストを検知して処理を行うには、Chromeが提供する「<a href="https://developer.chrome.com/extensions/devtools_network#event-onRequestFinished">chrome.devtools.network.onRequestFinished</a>イベント」に対して、「イベントリスナー」を追加します。</p>
<p>外部リクエストが発生する度に、「イベントリスナー」に登録した関数の引数に、検知したリクエストの内容が渡されて実行されます。</p>
<p>デベロッパーツールを再読み込みしてみると、「Panel」にメッセージが表示され、Twitterのサーバーへのリクエスト内容がConsoleに出力されました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/15c13779-6c79-49cc-a92f-0bd0a88da749/----------2017-08-14-7.04.05.png" alt=""></p>
<h2>ステップ5. 画面更新時の処理を追加する</h2>
<p>実際にこのツールを使う場合は、デベロッパーツールを開いたまま、色々なサイトを回遊して「Twitterの香りがするページ」を探したくなるでしょう。</p>
<p>そのため、画面遷移時に「Panel」内のメッセージをクリアする処理を追加します。</p>
<pre><code class="language-js">// リクエスト終了時（ステップ4で記述）
chrome.devtools.network.onRequestFinished.addListener((req) =&gt; {
  const url = req.request.url;
  if (url.indexOf(&quot;twitter&quot;) !== -1) {
    console.log(`req:${JSON.stringify(req)}`);
    document.getElementById(&quot;message&quot;).innerText = &quot;このサイトから、Twitterの香りがするでゲソ&quot;;
  }
});
// 画面更新時や、画面遷移時（本ステップで追加）
chrome.devtools.network.onNavigated.addListener((url) =&gt; {
    document.getElementById(&quot;message&quot;).innerText = &quot;&quot;;
    console.clear();
  }
);
</code></pre>
<p>画面遷移時の処理は、「<a href="https://developer.chrome.com/extensions/devtools_network#event-onNavigated">chrome.devtools.network.onNavigated</a>イベント」に対して、「イベントリスナー」を追加します。</p>
<p>ついでに、Consoleに出力していた内容も、「<a href="https://developers.google.com/web/tools/chrome-devtools/console/console-reference?hl=ja#clear">console.clear()</a>」を使って綺麗にしています。</p>
<h2>ステップ6. 動作の確認</h2>
<p>最後に、作成したツールの動作を確認します。</p>
<p>例えば、一見するとTwitterを使っているかわからない「<a href="https://karte.io/">KARTE</a>」のサイトを、「TWDetectorタブ」を開いたまま見てみます。</p>
<p>作成したツールに問題がなければ、「Panel」内に「Twitterの香りがするでゲソ」と表示されます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4b17444a-d40e-45d7-95af-0b34b96fe643/----------2017-08-14-7.15.32.png" alt=""></p>
<p>ページをスクロールしてみると、実際に「<a href="https://twitter.com/karte_io">KARTEの公式Twitterアカウント</a>」のツイートが埋め込まれていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/16bc5819-b360-43ac-9f58-2487df50c564/----------2017-08-14-7.17.08-1.png" alt=""></p>
<p>このように、このサイトがTwitterの「埋め込みTL」や「Followボタン」を設置しているかを、一瞬で知ることができます。</p>
<p>試しに、Twitterの香りがしない「<a href="https://www.google.co.jp/">google.co.jp</a>」を見てみると、何も反応しないことがわかります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2cb098a3-fdca-4e57-a2f4-ec52c925e5d4/----------2017-08-14-7.15.00.png" alt=""></p>
<p>このように、「Chromeデベロッパーツール」を拡張すれば、自分だけの便利ツールを簡単に作ることができます。</p>
<p>この記事をお読みの皆さんも、便利ツールや面白ツールを、自分の「Chromeデベロッパーツール」に追加してみてはいかがでしょうか？</p>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム<a href="https://karte.io/">「KARTE」</a>を運営する<a href="https://plaid.co.jp/">PLAID</a>では、オフィスで「スプラトゥーン2」をしていても怒られないような職場で働きたいエンジニア社員やインターンを募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><br>
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</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>


Chromeデベロッパーツールに独自機能を追加する方法を、6つのステップに分けて解説しました！

Chromeデベロッパーツールに独自機能を追加する6つのステップ  | PLAID engineer blog

Chromeデベロッパーツールに独自機能を追加する6つのステップ

Engineer Blog

Recent Article

刷新したKARTEロゴのプロセス公開ープロダクトが目指す理想像から始めるアプローチ

1泊2日ゼロベースで議論する開発合宿@館山に行ってきました！

「型を守る」ことから始めないソフトウェア開発ー常にゼロベースで考える

12.5億UUを解析する大規模解析サービスの監視構成

Developers Summit 2018に登壇してきました #devsumi

ストリーム処理を１からKappa Architectreまで学ぶ

MicrosoftのNapa.jsでJavaScriptをマルチスレッド化する

express-graphql + vue-apollo で GraphQLを試してみた

CodeZineで、解析サービスの裏側とGCPについて連載はじめました

Chromeデベロッパーツールに独自機能を追加する6つのステップ

Popular Articles

Popular Tags

Archives

Writers

Recent Article

刷新したKARTEロゴのプロセス公開 ー プロダクトが目指す理想像から始めるアプローチ

1泊2日ゼロベースで議論する開発合宿@館山に行ってきました！

「型を守る」ことから始めないソフトウェア開発 ー 常にゼロベースで考える

12.5億UUを解析する大規模解析サービスの監視構成

Developers Summit 2018に登壇してきました #devsumi

ストリーム処理を１からKappa Architectreまで学ぶ

MicrosoftのNapa.jsでJavaScriptをマルチスレッド化する

express-graphql + vue-apollo で GraphQLを試してみた

CodeZineで、解析サービスの裏側とGCPについて連載はじめました

Chromeデベロッパーツールに独自機能を追加する6つのステップ

Popular Articles

Popular Tags

Archives

Writers

刷新したKARTEロゴのプロセス公開ープロダクトが目指す理想像から始めるアプローチ

「型を守る」ことから始めないソフトウェア開発ー常にゼロベースで考える