Engineer Blog

Anri Nakamura

Kakemu Fujii

Kento Kaseda

Reo Hakuta

Erika Sakurai

erikasakurai

Takaharu Nakamura

Daichi Hachisuka

Louis Avondet

Sota Sato

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

KARTEのマイクロサービス環境でのAI基盤設計を解説。Mastraを核に「まず集中」を採用し、Tool/Storage設計、Memory/Streamingの実践と運用知見を紹介。

マイクロサービスアーキテクチャにおける Mastra を活用した AI 基盤設計

3ヶ月の開発インターンで取り組んだタスクや、そこから得た学びについて紹介します。

プレイドインターン体験記：管理画面から配信基盤までを横断した機能開発

<p>こんにちは、 プレイドでソフトウェア開発者をしているtakurintonです。</p>
<p>プレイドは、2025年10月25日(土)に開催された<a href="https://vuefes.jp/2025/">Vue Fes Japan 2025</a>にゴールドスポンサー、学生支援スポンサーとして協賛しました。</p>
<p>当日はブースの出展に加え、プレイドのユニークな技術とインターンの紹介をさせていただきました。</p>
<h2>ブースの紹介</h2>
<p>プレイドは大規模データを扱う会社である一方で、配信を誰でも簡単に行うことができるUIにも力を入れています。</p>
<p>ブースではフロントエンドの以下のトピックに関するアンケートを実施しました。</p>
<ul>
<li>型、どうしてる？</li>
<li>CSSは何派？</li>
<li>1番重要視するのは？</li>
<li>UI状態管理は？</li>
<li>ビルド&amp;Dev環境を教えて！</li>
<li>推しパッケージマネージャーは？</li>
</ul>
<p>プロダクトの歴史的背景や、場合によっては意思決定者の好みが出る話題で、さまざまなバックグラウンドの方の話や事情を聞くことができ、大変学びになりました。</p>
<p>また、併せて今回のVue Fes Japan 2025に向けて作成した冊子や、プレイドのリアルタイム解析基盤や内製OLAP DBについて技術評論社様と作成した冊子などを配布しました。</p>
<p><img src="https://ik.imagekit.io/plaid/e93f049b-91b9-4a6b-9360-97552fc1f36c/IMG_2541.jpg" alt="Vue Fes Japan 2025の株式会社プレイドのブースの様子。パンフレットやモニター、アンケートボードが並べられている。"></p>
<h2>セッションの感想</h2>
<p>同じ学生支援スポンサーで登壇されていたお二方のセッションの感想を書いていきたいと思います。</p>
<p>お二方とも大変ユニークで面白く、それぞれの抱えている課題について端的に発表されていることが印象的でした。</p>
<h3><a href="https://vuefes.jp/2025/sponsors/lycorp"><strong>LINE公式アカウントの技術スタックと開発の裏側</strong></a></h3>
<p>LINEヤフー株式会社の佐野友亮さんの発表です。</p>
<p>LINE公式アカウントのプラットフォームを題材に、デザインシステムの取り組みについてお話しされていました。<br>
デザインシステムの中核部分はWeb Componentsで実装されており、それをReactやVue.jsなど複数のライブラリへ適用できる仕組みになっているとのことでした。具体的には、CEMというツールを用いて中間表現を生成し、ReactやVue.js向けのコンポーネントはその生成物を配布する形を取ることで、メンテナンス対象をWeb Components部分に集約している構成が紹介されていました。</p>
<p>Web Componentsを本番環境で活用している事例は個人的に初めてで、以前から関心を持っていたテーマだったこともあり、とても学びの多い内容でした。</p>
<h3><a href="https://vuefes.jp/2025/sponsors/studio"><strong>Vue.jsを8年間使ってきた会社が今考えていること</strong></a></h3>
<p>Studio株式会社の齊藤広野さんの発表です。</p>
<p>Vue.jsを1系の頃から8年間にわたって活用されており、その間にコード量は7年間で13倍に増加していたそうです。発表では、大規模アプリケーションにおけるStore設計の重要性を、単一責任の原則や依存性逆転の原則を題材に、具体的なサンプルコードを交えて丁寧に解説されていました。</p>
<p>また、プロジェクトのデータ構造がボトルネックとなり、パフォーマンスが大きく低下していたアプリケーションをマイグレーションする難しさや、その過程で発生した不具合から得た知見をもとに改善へとつなげていく姿勢が印象的でした。実践的かつ学びの多い内容だったと思います。</p>
<h2>スポンサーセッション</h2>
<p><a href="https://vuefes.jp/2025/sponsors/plaid">プレイドのユニークな技術とインターンのリアル</a></p>
<p>弊社のスポンサーセッションでは、プレイドが提供するKARTEの紹介をはじめ、開発文化やユニークな技術についての紹介を行いました。また、途中では<a href="https://blocks.karte.io/">KARTE Blocks</a>のデモを挟みながら、実際の画面や配信についても触れました。</p>
<p>フロントエンドという領域から離れてしまいましたが、リアルタイム解析基盤や内製しているOLAP DBについての紹介も行いました。</p>
<p>セッション後にブースに立ち寄ってくださった方々からは技術面の面白さを感想としてお伝えいただいたり、時には議論に発展したりと、大変学びになる時間になりました。</p>
<p>よろしければ登壇資料もご覧ください。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="プレイドのユニークな技術とインターンのリアル" src="https://speakerdeck.com/player/0ee327d57ec64e71b058a9a777c71d51" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h2>おわりに</h2>
<p>Vue Fes Japan 2025では主にフロントエンドの分野に深い知見をお持ちの方が多く参加されており、自分自身その領域への知見や経験が足りないと感じていたのでさまざまなお話を聞くことができ大変有意義な時間になりました。</p>
<p>最後になりますが、素晴らしいカンファレンスを主催・運営してくださった皆様、本当にありがとうございました！また、ブースの出展に携わった皆様、登壇者・参加者の皆様も本当にお疲れ様でした！</p>
<p>来年のVue Fes Japanも楽しみです。</p>


プレイドはVue Fes Japan 2025にゴールドスポンサー、学生支援スポンサーとして参加しました。セッションの感想やブースの運営についてレポートとして紹介します。

Vue Fes Japan 2025レポート | 現地で感じた技術の熱とつながり

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


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

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

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


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

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

<p>こんにちは！エンジニアの@tik-son, @ikemonnとMLエンジニアの@nichimuです。</p>
<p>本日ついに待望の<a href="https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot">GKE Autopilotがリリース</a>されましたね！<br>
この記事では、GKE Autopilot上で動いているリアルタイム推論基盤でなぜ我々がGKE Autopilotを利用することにしたのかについてお話しします。</p>
<h1>MLリアルタイム推論基盤とは</h1>
<p>リアルタイム推論基盤とは、機械学習のモデルを使用して、リアルタイムに推論が行える基盤のことです。<br>
このリアルタイム推論基盤を用いることで、</p>
<ul>
<li>エンドユーザーがsession内で電話するかを予測する</li>
<li>エンドユーザーが会員登録を行ったsession内で資料請求をするか予測する</li>
</ul>
<p>のように数秒-数分後にエンドユーザーがどんな状態であるかなどを予測することが実現可能になります。<br>
この基盤はまだ絶賛開発中で誰もが簡単に使える状態になっていないのですが、このブログを読んで何かビジネス課題を解決したい！という方がいましたら、ぜひ、弊社までお問い合わせください！という宣伝はさておき、さっそく本題に入っていきます。</p>
<p>リアルタイム推論基盤のデータの流れとしては、以下のようになります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3f4c8102-da2d-4ba7-987f-339b82717b88/realtime_inference.png" alt="realtime_inference"></p>
<ol>
<li>エンドユーザーがwebやapp上で何かしらの行動を行い、Event DataをKARTEのリアルタイム解析/アクション基盤 (Not ML) に送信する</li>
<li>リアルタイム解析/アクション基盤に送られたEvent Dataをリアルタイム推論基盤 (ML) にCloud Pub/Subを通じて送信する</li>
<li>Cloud Dataflow上でEvent Dataに関する以下の処理を行う
<ol>
<li>Event Dataを整形して、生ログとしてCloud Spanner<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup>に保存する</li>
<li>Event Dataをfilterして、推論用APIへの推論トリガーをCloud Pub/Subを通じて投げる</li>
</ol>
</li>
<li>推論用API (Cloud Run) で、機械学習モデル<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup>を用いた推論を行い、推論結果をCloud Bigtableに書き込む</li>
<li>Cloud Bigtableに書き込まれた推論結果をコア基盤から読み込み、クーポンなどのActionを配信する</li>
</ol>
<p>今回、GKE Autopilotを使用した部分としては、図の赤枠で囲ってある推論用内部API componentになります。<br>
GKE Autopilotがローンチされるまでは、compute resourceとしてCloud Runを使用しており、以下でどのようにしてGKE Autopilotを使うようになったかをお話してまいります。</p>
<h1>推論用内部API の要件と抱える課題</h1>
<p>さて、推論用内部API として、Cloud Runを使用していると記述しましたが、推論用内部API の要件としては以下になります。</p>
<ol>
<li>以下を実現するため、自由度高くコードを書くことができるDocker Imageベースでデプロイできること
<ul>
<li>Cloud Pub/Subから推論トリガーを受け取り、予測を開始する</li>
<li>生ログデータをCloud Spannerから取得する</li>
<li>Pythonで書かれた機械学習のモデルを使って、予測を行う</li>
<li>Cloud Bigtableに予測結果を書き込む</li>
</ul>
</li>
<li>リアルタイム解析/アクション基盤に組み込んで使用するため、システムとして高スケーラビリティや高可用性などのシステムとしての強さがあること</li>
<li>基盤における運用/開発ではなく、モデルの作成やデータの活用など、MLエンジニアが本質的な価値にフォーカスする状態を作れること</li>
</ol>
<p>当初、これらの要件を満たすために、色々とベンチマークをした結果Cloud Runを使用していましたが、以下の課題がありました。</p>
<ul>
<li>Service Accountでの制御はかけているものの、CloudRunの仕様でCloudRun自体に外部IPを持たせないといけないため、セキリュティ的に綺麗な設計ではない</li>
<li>Cloud Pub/Subで推論トリガーを受け取るときにPush型を使用するが、Push型でのError Handlingが難しいので、なるべくPull型で扱いたい</li>
</ul>
<p>この課題はGKEを利用することで解決できるのですが、</p>
<blockquote>
<ol start="3">
<li>基盤における運用/開発ではなく、モデルの作成やデータの活用など、MLエンジニアが本質的な価値にフォーカスする状態を作れること</li>
</ol>
</blockquote>
<p>この要件と先程述べた課題とのバランスが難しく、最終的にはMLエンジニアがGKEのインフラレイヤーを管理/運用する大変さを鑑みて、課題に目をつぶりCloud Runを利用している状況でした。</p>
<h1>GKE Autopilotとは？</h1>
<p>そういった課題をかかえたところ、我々にとってちょうどいい塩梅のProductが発表されました。それが<a href="https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview">GKE Autopilot</a>です。<br>
GKE Autopilotとは、GKEの新しいmodeです。(従来のGKEはGKE Standard)<br>
Control Planeに加えて、Nodeの管理もGoogleのSREが行ってくれるので、クラスター管理の運用コストを下げることができます。さらに、SLAも提供されているので、Nodeの可用性やサイジング、スケーリングなどを気にすることなく、GKEを利用することができます。GKE Autopilotでは、ワークロードに応じて自動で裏側のHWをプロビジョニングするので、サービスやアプリケーションの開発に専念することができます。</p>
<p>特徴は下記です。</p>
<ul>
<li>NodeもGoogleが管理してくれる</li>
<li>ユーザーのワークロードにもとづいてリソースがプロビジョニングされる</li>
<li>Podに対してもSLAが設定されている</li>
<li>Podレベルで課金される</li>
<li>ユーザーのプロジェクト内でclusterが構築される(他のユーザとリソースを共有しない)</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b23f1257-08bb-44af-833f-ab67e42db6da/gkeauto.png" alt="gkeauto"><br>
<a href="https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot">https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot</a></p>
<p>また、GKE Autopilotでは下記のようなよく使われるワークロードやツールがサポートされており(一部今後サポート予定)で、様々なユースケースで活用できます。</p>
<ul>
<li>Stateless web app</li>
<li>Custom Database (StatefulSet)</li>
<li>Long-running batch job (Job)</li>
<li>DaemonSets that don’t violate GKE Autopilot rules</li>
<li>Add-ons: Cloud Run for Anthos, Istio</li>
<li>Machine Learning (GPU, TPU)</li>
<li>Tools and ecosystem - for example, Helm charts that don’t violates GKE Autopilot rules</li>
</ul>
<p>さらに、下記のような設定も利用できるため、使い勝手としても限りなくGKEに近い自由度があります。</p>
<ul>
<li>高可用性: Regional, Regular Release Channel, Auto-Update, Auto-Repair, Surge Upgrade</li>
<li>スケーリング: HPA, VPA, NAP</li>
<li>ネットワーク: Private clusters, VPC Native (alias IP), IP-friendly (limit cluster size/ pods per node), setup Cloud NAT</li>
<li>セキュリティー: Workload Identity, Shielded Nodes, Secure-boot-disk, etc</li>
</ul>
<p>以下のように、manifestの書き方もGKEのmanifestとほぼ同様に書くことができます。</p>
<pre><code class="language-yaml">apiVersion: &quot;apps/v1&quot;
kind: &quot;Deployment&quot;
metadata:
  name: &quot;plaid-test&quot;
  namespace: &quot;plaid&quot;
  labels:
    app: &quot;plaid-test&quot;
spec:
  replicas: 3
  selector:
    matchLabels:
      app: &quot;plaid-test&quot;
  template:
    metadata:
      labels:
        app: &quot;plaid-test&quot;
    spec:
      serviceAccountName: gke-auto
      containers:
      - name: &quot;realtime-inference&quot;
        image: &quot;gcr.io/plaid-test/realtime-inference:latest&quot;
        resources:
          requests:
            memory: &quot;6Gi&quot;
            cpu: &quot;2&quot;
          limits:
            memory: &quot;6Gi&quot;
            cpu: &quot;2&quot;
</code></pre>
<p>くわしくは<a href="https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview#limits">GKE Autopilotのドキュメント</a>をご確認ください。</p>
<h1>GKE Autopilotの導入</h1>
<p>GKE Autopilot導入は、KARTEのリアルタイム解析/アクション基盤を作っているエンジニア、MLリアルタイム推論基盤を作っているエンジニアの両方で検証をしながら進めていきました。<br>
<code>推論用内部APIの要件と抱える課題</code> でお話した要件と課題をほぼ満たせることとなり、productionのworkloadで現在稼働しているのですが、その中で以下のようなPros/Consを感じました。</p>
<h2>リアルタイム解析/アクション基盤を作っているインフラエンジニアが感じたこと</h2>
<ul>
<li>Pros
<ul>
<li>クラスタのインフラレイヤーをGoogleが管理してくれるので運用が楽そう。(productionの運用は本日から始めるので、実際の恩恵を受けるのはこれからだと思っている)</li>
</ul>
</li>
<li>Cons
<ul>
<li>vpc native cluser前提なので、正しく設計/構築するには、利用するip range/NAT等のNWインフラの知識が必要になり、アプリケーションエンジニアだけでは現状難しそう。(privateなNW通信を行わない、vpc NWはdefaultでcloud pubsubでコンポーネント間を通信するというようなシステムであれば、NWを意識しなくていいので構築は楽かもしれない)</li>
<li>preemptible vmに対応していない</li>
<li>基本GKEなので、GKEで出来ないことはできない。例えば、clusterレベルのスケールアウトがGKEより速いなどはない。(厳密にはこれはConsではないとは思うが、マネージドサービスである期待をこめて、一応書いておく)</li>
</ul>
</li>
</ul>
<h2>MLリアルタイム推論基盤を作っているMLエンジニアが感じたこと</h2>
<ul>
<li>Pros
<ul>
<li>manifestにresourcesのlimitsとrequestsを記述するだけで、MLエンジニアが欲しいマシンリソースが簡単に用意でき、運用まで期待できる</li>
<li>リソースはCloudRunと異なり、動き続ける前提なのでPub/SubのPull型を簡単に扱うことができる</li>
<li>インフラの柔軟性を担保しつつ、運用を考えなくていいのはいい。開発が捗る。</li>
</ul>
</li>
<li>Cons
<ul>
<li>MLリアルタイム推論基盤で今後利用したい、GPUがまだサポートされていない</li>
</ul>
</li>
</ul>
<h1>まとめ</h1>
<p>GKE Autopilotは銀の弾丸ではないので、インフラエンジニアからすると微妙な部分が少し多めに見えてしまうのですが、このProductのポイントはそこではなく、 <code>ある程度柔軟なインフラが必要だけど運用までは面倒見きれないようなユースケースに絶妙にハマる</code> ということだと実際使ってみて強く感じました。<br>
(くわしくは<a href="https://medium.com/google-cloud-jp/gke-autopilot-87f8458ccf74">Google CloudのKazuuさんのブログ</a>をご確認ください)</p>
<p>Consで書いたことはGCPのことなので、GA後にすぐに対応してもらえるだろうと勝手に期待しています(笑)<br>
また、privateなvpc内通信が必要にならないよう、cloud pubsubなどでシステム間を疎にして設計していけば、GKE Autopilotの恩恵をより受けやすくなるのではないかとも感じました。もちろん、システム間のやり取りが大量なものはprivateなvpc通信前提で作る方がコストが安くなるとは思いますが、このあたりはトレードオフになると思うので上手く見極めながら設計していくといいと思われます。<br>
我々も今後はこのあたりを意識しながら上手くGKE Autopilotなどを駆使し、システムを作っていきたいと思います。</p>
<h1>最後に</h1>
<p>プレイドではGKE Autopilotのような新しい技術をうまく使い、面白いProductを開発していきたいエンジニア（インターンも！）を募集しています。<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><a href=""></a></p>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p>Cloud SpannerにEvent Dataを書き込んでいる理由としては、以下の２つの理由があります。(1. 機械学習のモデルを使用した推論ではエンドユーザーの過去の情報も必要だが、Event Dataには過去の情報はあまり含まれていないため、過去の情報も保持しておく必要がある, 2. 機械学習のモデルを作成する際にはBigQueryにSQLを投げて特徴量作成の試行錯誤をするため、推論時もSQLがかけるDBだと相性がよい) <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn2" class="footnote-item"><p>機械学習のモデルの作成やデプロイなどは、AI Platform NotebookやAI Platform Pipelinesを使用して行っています。 <a href="#fnref2" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


本日ついに待望のGKE Autopilotがリリースされましたね！
この記事では、GKE Autopilot上で動いているリアルタイム推論基盤でなぜ我々がGKE Autopilotを利用することにしたのかについてお話しします。

GKE Autopilotで作るMLリアルタイム推論基盤 | PLAID engineer blog

GKE Autopilotで作るMLリアルタイム推論基盤

<p>PLAIDでエンジニアをしている@kantetsuです。</p>
<p>現在はKARTEの<a href="https://cxclip.karte.io/product/userstory_renewal/">ユーザーを知る</a>画面のリニューアルや改善を主に行なっています👨‍💻</p>
<p>PLAIDでは、ここ数年デザイナーとエンジニアが一緒のチームとなり、デザイナーも機能公開に携わるようになって、機能を公開するプロセスが仕組み化されてきました🤖</p>
<p>例えば、シナリオテストやユーザビリティテストもここ最近では定着してきました（以前に書いた<a href="/release_survey_form/">KARTEのアンケートフォーム（β版）公開までの道のり</a>でも一部触れています）。</p>
<p>このような王道のテストをやりつつも、実は機能を公開するまでの手順でKARTEや社内ツールを用いたユニークな改善方法があるので、今回この場を借りて共有したいと思い、執筆しました✍️</p>
<h1>KARTEとは</h1>
<p>どのような改善方法があるのかを紹介する前に「KARTEって何なのか？」を説明させてください。ここをすっ飛ばしちゃうと、あとでよく分からないことになりそうなので🙏</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/86be2ac0-77b2-41a5-a4a0-8d449ad32ee6/insight.png" /><figcaption>https://karte.io をチェック！</figcaption></figure>
<p><a href="https://karte.io/">KARTE</a>では、サイトに計測タグを貼ることによって、ユーザーの行動解析をします。そのサイトでのエンドユーザーの一つ一つの行動（これをKARTEの中ではイベントと言う）をクライアントさんはKARTEの管理画面内で見ることができます。その中でエンドユーザーの行動を見れるのはもちろん、エンドユーザーに配信するアクションの編集やライブ・レポートの閲覧などができます。</p>
<h2>KARTEでイベントを発火させてユーザーを観察する</h2>
<p>KARTEでクライアントさんがどの画面でどのような行動をしているか見るために、実はKARTEの管理画面ではKARTEのタグを入れています。</p>
<p>で、これをどう開発で利用しているかというと、画面のリニューアルや改善をした際に「この週にどのくらいの人が保存ボタンを押したのか」「この日にどのくらいモーダルが開かれたのか」をKARTEのイベントを発火させることで観測しています📊</p>
<p>私たちのチームでは開発後にデザイナーがどの機能が使われているかを下記のようにリストアップして、それらを計測できるようにソースコードに計測のコードを入れていきます👨‍💻</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/387a6d83-2aed-46c0-b95f-27cdcd023eca/----------2020-11-02-23.03.02.png" /><figcaption>取りたい指標をリストアップしています</figcaption></figure>
<p>そして、実際にイベントが発火すると、KARTEのイベント画面やストーリー画面に表示され、「誰がどのタイミングで、どのくらいの人が〇〇ボタンを押したのか」などがKARTEで見ることができました👏</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e2546b14-22f4-427d-81a6-b115a5c86575/event.png" /><figcaption>計測されるとイベント画面に発生数と発生したユーザーと時刻が表示されます</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6b8bb35e-5289-431b-893c-7ff5600489e5/story.png" /><figcaption>もっと解像度高く見たい場合はストーリー画面で見ることもあります</figcaption></figure>
<p>一部のメンバーは<a href="https://mode.com/">Mode</a>を使って、SQLを書くことでこれらのイベントをより細かく集計もして、定期的にslackに通知してチームにシェアしています。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cecae12e-cadf-4a1b-a8f2-a719fc540693/mode.png" /><figcaption>実際に発生したイベントをModeで集計したレポート</figcaption></figure>
<h2>KARTE Liveで管理画面をどのように利用しているか見てみる</h2>
<p>KARTEの管理画面ではKARTE Liveによって可視化しているので、クライアントさんがどのように管理画面を使っているのかを視覚的に見ています。</p>
<p>例えば、新画面をリリースした場合にその新画面にクライアントさんがアクセスしたら、社内のSlackに「〇〇さんがこの画面にアクセスしました」っていう通知を飛ばして、その人のストーリーに飛んで、<a href="https://karte.io/product/live/">KARTE Live</a>を開いて見てみます👀</p>
<p>これによって、自分たちの新画面で想定された使い方をされているのか、画面上で戸惑っている部分はあるのかを実際の画面を通して見ることができます。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/060017a7-e3f4-4ae3-9263-8d9bf68f23f7/image.png" /><figcaption>KARTEを使った通知の仕組み</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/76db6004-25b1-438a-8ba5-b98d7ef10777/s_DE66FBEA70BB0CBF23B9F0B5499DD68BB499403C478D678EB3C5F0DE92B2B6F9_1604482900676_slack.png" /><figcaption>該当ユーザーが通知され、チーム内で会話しています</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c01c4e69-a9eb-4a1e-b2f9-75d68921cadd/----------2020-11-04-19.30.33.png" /><figcaption>KARTE Liveでユーザーの動きをもっと強烈に見て、改善に繋げています</figcaption></figure>
<p>自分たちのチームはユーザーを知る画面をKARTEを使ってまさに「ユーザーを知る」ことで改善しています！</p>
<p>手前味噌ですが、KARTEは画面の改善にも強力なサービスでもあると思っています🚀</p>
<h2>KARTEの管理画面にコメントして、Issueに起票する</h2>
<p>今までのはKARTEを利用したKARTEの管理画面の改善方法を紹介しましたが、社内ツールもKARTEを進化させています💪</p>
<p>下記の二つのアプリを使っています。（これら二つはPLAIDの社内アプリなので外部公開していないので悪しからず…🙇‍♂️）</p>
<p>自分たちのチームではチーム内で自分たちの開発した画面を触って、バグのある箇所やユーザビリティが低い箇所にP Appでコメントしていくぽちぽち会を実施しました👨‍💻</p>
<p>P Appを使うことでブラウザ上でどこに誰がコメントしているのかを簡単に見ることができ、また簡単に投稿もできます。そして、Slack上でもその要素の画像も添えて投稿されるので、Slackにフィードバックを集約もすることができます。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1b643170-3092-4e50-8bdb-1550744fc9b7/slack2-2.png" /><figcaption>P AppにコメントされるとSlackにも同期される</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/679a0414-0e56-40bf-9477-be8b20167734/image-1.png" /><figcaption>サイト上の要素にコメントできるP App</figcaption></figure>
<p>そして、PLAIDでは基本的にはGitHubのIssueに起票してから開発するので、先ほどP Appで投稿されたSlackの投稿をS Appを使ってIssueにします。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e9de211c-2f3b-4ac0-a912-96f3debb8a91/image-2.png" /><figcaption>さっきP Appで投稿された投稿をSlack上でIssue化するS App</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fd9d488b-b897-4959-8295-857d0a4dd161/----------2020-11-04-18.51.33.png" /><figcaption>Issueのタイトルを記入して、Issueを作るボタンを押すと該当のレポジトリにIssueが起票される</figcaption></figure>
<p>これによって、画面でおかしいと思った箇所を逐一スクショしてSlackやGitHubに共有する手間がなく、シームレスにIssueにあげることにできました👏</p>
<h2>最後に</h2>
<p>今回はKARTEの開発ではPLAIDだからこそ、KARTEだからこそできる管理画面の観察方法や改善方法を紹介しました😊</p>
<p>もし他のチームで使われている改善方法があったり、新しい改善術があれば、別の機会で紹介したいと思います！</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。0詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。</p>


PLAIDでは機能公開する際にユーザビリティテストなどを行なっていますが、それとは別にKARTEの機能や社内ツールを用いたユニークな改善方法を行なっているので、それらをご紹介します！

PLAID流プロダクト改善術をお見せします！

<p>みなさんごきげんよう、Engineerの @tik-son です。02020-10-28に開催された<a href="https://pages.awscloud.com/SaaS_Svrless_EventBridge_seminar.html">&quot;ビジネスにアジリティーをもたらす「SaaS + サーバーレス」&quot;</a>というイベントに<br>
<strong>&quot;User State Driven System with Amazon EventBridge &amp; KARTE&quot;</strong> というテーマで登壇してきました。</p>
<p>PLAIDは2020年1月ごろから<a href="https://aws.amazon.com/jp/blogs/news/new-jp-eventbridge-partners/">EventBridgeのSaaS Partner</a>であり、KARTEのActionの一つとしてEventBridgeが選択できます。<br>
今回のセミナーではEventBridgeを活用したUser State Driven Systemということで、３つの連携例などについてお話しました。</p>
<ul>
<li>ユーザの状態に応じた電話サポート(KARTE × Amazon Connect)</li>
<li>自由記述アンケート分析 (KARTE × Amazon Comprehend)</li>
<li>プロアクティブCall (KARTE × Amazon Connect × shopify)</li>
</ul>
<p>詳細についてはスライドをご覧いただければと思います。</p>
<script async class="speakerdeck-embed" data-id="ac3b373bbd2a47e6b084eb9e90a98a70" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>このセミナーではPLAIDの他には以下のS(P)aaS Providerが、それぞれ異なる切り口でEventBridgeについて話をされておりました。<br>
我々はEventBridgeのユーザでもあるのでそういう観点でも色々と勉強になったとともに、これからのEventBridgeのさらなる盛り上がりも感じ取ることできるセミナーでした。</p>
<ul>
<li>Auth0 株式会社</li>
<li>Datadog Japan 合同会社</li>
<li>Game Server Services 株式会社</li>
<li>株式会社はてな</li>
<li>Shopify Japan 株式会社</li>
</ul>
<p>*2020/11/17 追記 AWS Blogにも取り上げていただいたので他の方の発表内容などの詳細を知りたい方はぜひここちらもご覧ください。<a href="https://aws.amazon.com/jp/blogs/news/saas_serverless_eventbridge_seminar/">https://aws.amazon.com/jp/blogs/news/saas_serverless_eventbridge_seminar/</a></p>
<h2>最後に</h2>
<p>発表の中でも話しましたが、KARTEとEventBridge(AWS)で出来ること / 可能性というのはまだまだ未探索なので、面白いことを思いついたり何かフィードバック等ある方は是非コメントなどをいただければと思います。<br>
また、このような連携を通じて、KARTEの新たな価値を作り上げていく仲間も募集しています。興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！</p>


"User State Driven System with Amazon EventBridge & KARTE" というテーマで、"ビジネスにアジリティーをもたらす「SaaS + サーバーレス」"というイベントに登壇してきました

User State Driven System with Amazon EventBridge & KARTE について話してきました | PLAID engineer blog

User State Driven System with Amazon EventBridge & KARTE について話してきました

<p>フロントエンド/Node.js エンジニアの mizchi です。plaid では新しい分析エンジンのフロントエンド側の技術的な仕様を考えたり、それを実装したりしています。趣味として社内の他のプロダクトのパフォーマンスを勝手に測って、貼り付けていくこともあります。</p>
<p>plaid のエンジニア組織には「組」という制度があって、メインとなるプロダクト以外にも、そのテーマで会社横断で活動するグループがあり、最低一つ所属することが奨励されています。例えばセキュリティ組、バグトリアージ組、Tech 勉強会組などがあります。</p>
<p>最近になって パフォーマンス組を新設しました。これは主にフロントエンドのパフォーマンスを調査して、各プロダクトにその改善を促すグループです。</p>
<p>plaid のフロントエンドは PaaS としての外向けのサードパーティスクリプトと、その管理画面があるのですが、サードパーティの方はパフォーマンスも計測しているのですが、管理画面の方は歴史が長く設計変更も多々あり、富豪的な感じになってしまっています。</p>
<p>これを改善するためにいくつか調査を行い、実際にいくつかは修正したのですが、本質的には「組織的なパフォーマンス意識」を向上させる必要がある、という結論になりました。組織としてのパフォーマンスを意識できないと、目の前の問題を解決したとして、いずれ再発します。(これはセキュリティなどでも同様ですね)</p>
<p>そこで、その文化の改善のために、まず社内のプロダクトをテーマにハッカソンの開催を開催してみよう、という話になりました。</p>
<h2>開催の経緯</h2>
<p>とある日の slack のスレッドの自分とデザイナーの高橋さんの会話。</p>
<p>mizchi 「ところで Baisu (社内の CSS ガイドライン兼モック) むちゃくちゃ重くないですか」</p>
<p>高橋「めちゃ重いですよね」</p>
<p>mizchi 「なんで重いんだろう… JS でした」</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a087da95-c435-4fd2-abfd-38e3a72107b2/hev.png" alt=""></p>
<p>高橋「モック環境だから色んなライブラリとか試すのにいれまくってるからか！なるほど」</p>
<p>mizchi 「ここパフォチュのお題によさそう。lighthouse で高得点出した人が優勝」</p>
<p>mizchi 「壊しても悲しむのが高橋さんだけってのがパフォチュ向き」</p>
<p>見ていた同僚が突然テザーサイトを作成</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1a3f2fe0-1e1b-444a-abd2-752765626970/aaf620d4154ddc6357cdb16485c6987a.png" alt=""></p>
<p>開催決定！</p>
<p>mizchi「業務時間使って開催しますね」</p>
<p>nashibao(CPO)「どんどんやっていけ」</p>
<h2>真面目な話</h2>
<p>社内のワークフローでは、社内のモノレポの一部の baisu というプロダクトで vue.js のモックページを作成し、それを元に各プロダクトで実装が行われています。</p>
<p>このワークフローの抱える問題として、 baisu の抱えるパフォーマンス上の問題は、そのままプロダクトに引き継がれてしまいます。実際いくつかパフォーマンス上の問題として表出していました。</p>
<p>ここでの改善は、そのまま管理画面やその他のページの改修にそのまま活かせます。プロダクトに直接コミットするより、まず同じ問題を抱えたモックページをチューニングすることで、心理的な負荷を減らしつつ大胆なアプローチを取れるはずだ、と考えました。</p>
<h2>まず自分で解いてみた</h2>
<p>前提として、この baisu というのは、基本的に vue.js + vue-router で構築された SPA です。html-webpack-plugin と webpack, webpack-dev-server で起動し、本番は静的サイトとして superstatic 上で動作します。</p>
<p><a href="https://github.com/firebase/superstatic">firebase/superstatic: Superstatic: a static file server for fancy apps.</a></p>
<p>そもそも問題として適当かどうかを測るため、自分でまず自分がチューニングしつつ問題を洗い出しました。</p>
<ul>
<li>チャンク分割の前に面倒だったのが、babel6 =&gt; 7 のアップグレードだったので、ここで詰まっては本質的ではないので babel 7 へ更新</li>
<li>webpack も dynamic import が使いづらいバージョンだったのを最新版に更新</li>
</ul>
<p>その上で発生している問題の洗い出し。</p>
<ul>
<li>大量のルーティングあるにも関わらず、チャンク分割がなされずに、単一の js として出力されてる</li>
<li>moment の locale をすべて読みこんでいる</li>
<li>vue 用のビューライブラリで、 element-ui というライブラリのコンポーネントを、使うかどうかに関わらず全部読み込んでいる</li>
<li>apexcharts という重いチャートライブラリを全画面で読み込んでいる</li>
<li>fontawesome の全アイコンフォントを読み込んでいる</li>
</ul>
<p>これによって、適当なお題だと判断。あえて放置して本番を迎えました。</p>
<h2>開催告知</h2>
<ul>
<li>社内勉強会で他社のハッカソンのお題に対する解法を解説 <a href="https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-%E5%87%BA%E9%A1%8C%E3%81%AE%E3%81%AD%E3%82%89%E3%81%84%E3%81%A8%E8%A7%A3%E8%AA%AC">https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-出題のねらいと解説</a></li>
<li><a href="https://www.amazon.co.jp/dp/B07JJ344WK/ref=dp-kindle-redirect?_encoding=UTF8&amp;btkr=1">超速本の布教</a></li>
</ul>
<p>弊社は 2 ヶ月に一回チームを入れ替えるのですが、その入れ替え期で比較的締め切りなどがない余裕があるタイミングで開催しました。事前に「業務時間を使って参加していいよ、ただしチームの同意はとってね」という周知をしました。</p>
<h2>レギュレーションとスコアサーバーの実装</h2>
<ul>
<li>baisu/app のビルド結果を競う</li>
<li>npm run bundleAnalyze した後の npm run evaluation で localhost:8080 にサーバーを起動</li>
<li>計測サーバーの実装を clone して localhost:8080 のスコアを計測</li>
<li>UI が大幅に壊れている場合は計測対象外とする</li>
</ul>
<p>周知した方向性として、「計測対象となるページの個別の最適化は避けて、できるだけ一般的な、マージしたいと思えるような実装で解いてね(それでもスコアは十分伸びるので)」という感じに。</p>
<p>計測用スクリプトはこんな感じ。</p>
<pre><code class="language-js">const fs = require('fs');
const path = require('path');
const lighthouse = require('lighthouse');
const chromeLauncher = require('chrome-launcher');

const TARGET_URLS = [
    &quot;http://localhost:8080/&quot;,
    &quot;http://localhost:8080/user/story/&quot;,
    &quot;http://localhost:8080/karte/wizard/&quot;,
    &quot;http://localhost:8080/organization/&quot;,
    &quot;http://localhost:8080/account/register/&quot;,
];
const metricsLighthouse = async (chrome, url) =&gt; {
    const options = { logLevel: 'error', output: 'html', onlyCategories: ['performance'], port: chrome.port };
    const runnerResult = await lighthouse(url, options);
    const filename = url.replace(&quot;http://localhost:8080/&quot;, &quot;&quot;).replace(/\//g, &quot;_&quot;);
    const reportHtml = runnerResult.report;
    fs.writeFileSync(`report_${filename}.html`, reportHtml);
    return {
        url,
        score: runnerResult.lhr.categories.performance.score * 100,
        totalByte: runnerResult.lhr.audits[&quot;total-byte-weight&quot;].numericValue
    }
};

(async () =&gt; {
    const chrome = await chromeLauncher.launch({ chromeFlags: ['--headless'] });
    try {
        const results = [];
        for (const url of TARGET_URLS) {
            const result = await metricsLighthouse(chrome, url);
            results.push(result);
        }
        const totalScore = results.reduce((total, result) =&gt; {
            return total + result.score;
        }, 0);
        const totalByte = results.reduce((total, result) =&gt; {
            return total + result.totalByte;
        }, 0);
        console.log(`Total score: ${totalScore}`);
        console.log(`Total bytes: ${totalByte} bytes`);
        console.table(results);
    } finally {
        await chrome.kill();
    }
})();

</code></pre>
<p>要は lighthouse の Performance のスコアです。</p>
<h2>開催</h2>
<ul>
<li>カレンダーで 14:00~19:30 を確保</li>
<li>14:00 に zoom のオンラインミーティングでレギュレーションの説明</li>
<li>18:30 に終了。最終ビルドのスコアを自己申告してもらう。</li>
<li>参加者一人ずつ、PullRequest を見ながらやったことの紹介。全員で講評。</li>
</ul>
<h2>結果</h2>
<ul>
<li>事前の周知の甲斐あって、ほぼ全員が router の lazy load の実装を完了 80mb =&gt; 16mb</li>
<li>ほぼ全員が momment の未使用 locale を削除</li>
<li>半数が element-ui をなんらかの形で未使用コードのドロップを実装</li>
<li>ほぼ全員が fontawesome の最適化に挑むも、削れた人は一部だけ</li>
<li>apexcharts を問題視した人はいたが、アプリケーションコードに手を入れないといけないので放置</li>
</ul>
<p>ほぼ全員が 80mb を 10mb 付近まで削っていたのですが、最終的に優勝したのは、 html-webpack-plugin の吐くコードを書き換えた人で defer にしたことで、lighthouse のスコアが上がった、新卒一年目の <a href="https://github.com/kosukeoya">kosukeoya</a> でした。</p>
<p>kosukeoya 曰く、「自分はフロントエンドのパフォーマンスチューニングは初めてだったが、事前資料として共有されたサイバーエージェントのハッカソンでの最適化を上から順になぞった」ということで、あの資料やっぱ有効だったんだなぁという感じに。</p>
<p><a href="https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-%E5%87%BA%E9%A1%8C%E3%81%AE%E3%81%AD%E3%82%89%E3%81%84%E3%81%A8%E8%A7%A3%E8%AA%AC">https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-出題のねらいと解説</a></p>
<h2>参加者の声</h2>
<ul>
<li>webpack-bundle-analyzer がリポジトリに組み込まれていたので、普段は意識しないものを意識できた</li>
<li>やってよかった。いろいろなテクニックにふれる機会があった</li>
<li>フロントエンドの経験値が少なく、直し方はまだ難しく感じるが、問題の見つけ方がわかるようになったのが大きい</li>
<li>最適化ははじめてだったが、コスパよくできる場所があるのがわかった</li>
<li>ベストプラクティスはそんなに難しくなく、知ってれば日常的に採用できるコードが多い</li>
<li>競プロ的な感じ(小難しい解法)かと思ったら普通に一番いいコードが一番効く</li>
<li>(baisu そのものの感想) そもそもうちにこんな数のモックページがあったのか</li>
</ul>
<p><a href="https://www.npmjs.com/package/webpack-bundle-analyzer">webpack-bundle-analyzer - npm</a></p>
<h2>技術的な感想 / 得られた教訓</h2>
<ul>
<li>vue.use 使ってしまうと最適化が難しい</li>
<li>fontawesome が強敵</li>
<li>jquery 消そうとして時間がかかった</li>
<li>chunk に名前つけた方がデバッグしやすい</li>
<li>chunk いっぱい吐くとグラデーションが綺麗</li>
<li>高橋さんの PC のメモリ節約できて嬉しい！</li>
</ul>
<p>きれいな webpack chunk の様子です</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f241e3fb-755b-42c1-9736-9870c2b0a1bc/a11849230c29ee02f649700750dfcae1.jpg" alt="baisu [11 Sep 2020 at 18:25] - Gyazo"></p>
<h2>講評中に見つかった、プロダクトに活かせそうなものの</h2>
<ul>
<li>superstatic の compression(gzip) を有効にする(なってなかった)</li>
<li>JS によって挿入される css で呼ばれる webfont を &lt;link rel=preload ...&gt; で先読みすると、 適用時のガタツキがなくなり、layout junk が減って LCP のスコアがよくなる</li>
</ul>
<p>この辺やらないとわからなかった気がします。</p>
<h2>運営してみての感想 / 反省</h2>
<p>プロダクトと同じ構成のモックの読み込み改善というお題がよかったと思います。そのまま業務にフィードバックできるので、明日からやっていけそう、みたいな声が多かったです。</p>
<p>そもそもルーティングのチャンク分割、 lazyload にたどり着いてくれないとその後の改善がないのが心配だったんですが、参加者全員、そこはたどり着いていました。ハッカソン中に時間経過でヒントを小出ししたのも、何もできない人が出なくてよかったかなと思います。</p>
<p>反省として、最終的な script の defer 属性によるスコア差については、今回のお題ではやや評価が難しいところがあります。なぜなら、baisu は js を読み込まないと画面に何も表示されない、SSR なしの SPA なので、エントリポイントの同期/非同期は、結果的なユーザー体験にあまり影響がありません。</p>
<p>まあ、スコアサーバーの機嫌を読むのもコンテストの一部ということだと思うので、これはこれで良いと思います。ただ html-webpack-plugin の吐くコードに手を入れる、というのは気づきづらかったですね。</p>
<p>人が集まりやすい事前準備をして、告知の反応も多かったんですが、やはり業務時間を使う心理的な抵抗からか人が集まりづらく、想定の半分ぐらいでした。ここは次にもっと工夫したいと思います。</p>
<p>社内プロダクトの改善という他社で再現性があるか微妙なテーマではあり、これも外に出せないのが申し訳ないんですが、似たようなモックと課題をもつような会社では開催できるのではないでしょうか。そもそも実プロダクトを対象にしてもいいと思います。</p>
<h2>Hiring</h2>
<p>plaid では webpack chunk を 1byte でも絞り込みたいという人を募集しています。</p>
<h2>参考にした先行事例</h2>
<ul>
<li><a href="https://www.cyberagent.co.jp/careers/students/career_event/detail/id=24500">https://www.cyberagent.co.jp/careers/students/career_event/detail/id=24500</a></li>
<li><a href="https://techkondo.com/2020/03/13/recuruit-speed-hackathon/">https://techkondo.com/2020/03/13/recuruit-speed-hackathon/</a></li>
</ul>


社内でフロントエンドのパフォーマンスチューニングコンテストを開催した

<p>みなさん、こんにちは。CTO の @makinoy です。02020-09-08の<a href="https://event.cloudnativedays.jp/cndt2020">CloudNative Days Tokyo 2020</a>のに<a href="https://event.cloudnativedays.jp/cndt2020/talks/46">「急速な成長を加速させるアーキテクチャ〜オープンテクノロジー・マルチクラウドの活用〜</a>」というタイトルで登壇してきました。</p>
<p>我々も非常にお世話になっている<a href="https://www.amazon.co.jp/dp/4295009792">Kubernetes完全ガイド</a>の著者である<a href="https://twitter.com/amsy810">青山真也さん</a>にお声がけいただき、今回の登壇の機会をいただきました。1素晴らしい機会をいただきありがとうございました！</p>
<h3>「急速な成長を加速させるアーキテクチャ」</h3>
<p>このKeynoteでは、k8sなどCloud Native オープンテクノロジーを活用して、どのようにプロダクトの急速な成長を、単に支えただけでなく<strong>加速</strong>したのかについて、これまでのアーキテクチャの変遷を踏まえて、考え方をご紹介しました。</p>
<p>話したかったポイントとしては、なるべく自分たちでやることを減らして技術の力を利用する、その時に、技術的な”良さ”を鵜呑みするのではなく、なぜその技術を導入するか、組織やプロダクトの状態を考えて導入していくことが、ビジネスを含めたプロダクトとしてのハイスケーラビリティを実現するのではないかと考えている、ということです。</p>
<script async class="speakerdeck-embed" data-id="d2bf4f81df504279b3133bc198d36dc9" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>動画は<a href="https://event.cloudnativedays.jp/cndt2020/talks/46">CNDT公式サイト</a>からご覧いただけます。</p>
<p>アーキテクチャーの変遷に関して詳しくは、 <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital">Google Cloud Day: Digital</a>  で @tik-son の「 <a href="https://speakerdeck.com/tikson/plaids-journey-with-multi-cloud-10128526-d75f-41de-98ec-27025f8d35a9">PLAID’s Journey with multi cloud</a> 」を、2k8sに移行した話に関して詳しくは @kumokumo の「<a href="https://speakerdeck.com/komukomo/migrating-to-microservices">Migrating to Microservices - Speaker Deck</a>」を参考にして下さい。</p>
<h2>Toolスポンサーとして</h2>
<p>もしかするとCNDTのイベントページを見てお気づきの方もいらっしゃったかもしれませんが、実は今回のCNDT 2020 Tokyo ではPLAID がTool スポンサーとして協力させていただいてます。3具体的には CNDTのイベントページでKARTEが導入されているのですが、みなさまWeb接客を受けましたでしょうか？後日、KARTEで取得したデータを分析した情報なども公開されるようなので、楽しみにしていてください！</p>
<p>今回の登壇の中でもお話しましたが、我々としてはこのようにOpen Technologyの恩恵を受けるだけでなく還元もしていきたいと考えており、KARTEを通じて今回のCNDTでの皆様の体験向上に繋がっていれば幸いです！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/05c7f4f0-c9b4-45f0-aa69-e673e828d3bf/image.png" alt=""></p>
<h2>最後に</h2>
<p>Cloud Native オープンテクノロジーをフルに活用して、KARTEを一緒に作り上げていく仲間は常に募集しています。興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！</p>


CloudNative Days Tokyo 2020のKeynoteに登壇してきました

 CloudNative Days Tokyo 2020のKeynoteに登壇してきました | PLAID engineer blog

悩みに悩んだ Kubernetes Secrets の管理方法、External Secrets を選んだ理由 | PLAID engineer blog

悩みに悩んだ Kubernetes Secrets の管理方法、External Secrets を選んだ理由

<p>こんにちは。エンジニアの@ikemonnです。02019/11/13に<a href="https://www.wantedly.com/companies/datadog/post_articles/196576">Datadog Summit Tokyo</a>で「マルチクラウドな大規模サービスKARTEを支えるDatadog」というテーマで登壇してきました。</p>
<p>(イベント終了後にブログを書いた気でいましたが、書いていなかったのでその振り返りです。)</p>
<p>KARTEは下記のような特徴のサービスです。</p>
<ul>
<li>マルチテナント</li>
<li>低レイテンシ―/高負荷</li>
<li>大規模システム</li>
<li>マルチクラウド構成</li>
</ul>
<p>こういった特徴のKARTEをどのように運用コストを抑えて監視しているかについて話しました。1Datadogを例として話していますが、他の監視ツールを使っていても活かせる内容だと考えていますので、ぜひご覧ください！</p>
<script async class="speakerdeck-embed" data-id="47b0e8337a5b469ca6d08394d8c06bc1" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h2>概要</h2>
<p>KARTEは下記の特性を持った低レイテンシ―/高負荷なサービスです。</p>
<ul>
<li>秒間トラッキングイベント数 105,000 event(2020年3月時点)</li>
<li>ユーザの解析から最適なアクションを返すまで0.x秒以内</li>
</ul>
<p>インフラはGCP/AWSで構成されており、SREチーム2-3名で運用しています。2(マルチクラウド化への変遷については<a href="/google-cloud-day-digital-2020/">こちら</a> )</p>
<p>上記のサービスの特徴とインフラの特徴を踏まえて、KARTEでは監視ツールとして<a href="https://www.datadoghq.com/ja/">Datadog</a>を愛用しています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fd5819b5-5273-4850-b9e0-1f8e33e9b1f1/-2020-07-28-12.34.02.png" alt=""></p>
<p>そして、下記のポイントを抑えて監視をすることで少人数での運用を実現しています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8ab451db-f95a-484c-9d3a-7494ed750a50/-2020-07-28-12.34.20.png" alt=""></p>
<p>Datadogにすべて集約</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ddf68fd8-672b-4f81-b320-1ecc3d67f766/-2020-07-28-12.58.07.png" alt=""></p>
<p>3Custom Metricsの積極活用</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bb00499a-a8df-45e0-805e-70c246738ba6/-2020-07-28-12.58.18.png" alt=""></p>
<p>4Layerを分けたDashboard</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c36eeb7b-2233-466c-807b-d0a2425348f3/-2020-07-28-12.58.30.png" alt=""></p>
<p>このようにKARTE、マルチクラウドインフラ、Datadogの相性を考えながら最適な運用方法を日々模索しています。</p>
<p>より具体的な内容について知りたい方はぜひスライドや動画をご覧ください！</p>
<script async class="speakerdeck-embed" data-id="47b0e8337a5b469ca6d08394d8c06bc1" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<iframe width="612" height="344" src="https://www.youtube.com/embed/_Z4HBiwODbc?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
<h3></h3>
<h2>最後に</h2>
<p>マルチクラウド構成、高負荷低レイテンシーなKARTEのインフラを一緒に支えていく仲間は常に募集しています！興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！</p>


こんにちは。エンジニアの@ikemonnです。2019/11/13にDatadog Summit Tokyoで「マルチクラウドな大規模サービスKARTEを支えるDatadog」というテーマで登壇してきました。

Datadog Summit Tokyoに登壇しました！| PLAID engineer blog

Datadog Summit Tokyoに登壇しました！

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

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


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

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

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

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


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

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

Engineer Blog

Recent Article