Engineer Blog

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

こんにちは！6月から8月までの3ヶ月間、プレイドでエンジニアインターンとして勤務しておりました伊藤孝太朗です。私は現在、カナダ・バンクーバーにあるブリティッシュコロンビア大学（University of British Columbia, UBC）で学部3年生としてコンピュータサイエンスを専攻しています。このブログでは、私がプレイドでインターンとしてどのような課題に取り組んだか、そこから何を学んだかについてお話しさせていただきたいと思います。

プレイドインターン体験記：エンジニアとしての学びを深めた3ヶ月_プレイドエンジニアブログ

プレイドインターン体験記：エンジニアとしての学びを深めた3ヶ月

長期運用システムにおけるNode.js / npmアップデート工程を紹介します

KARTEの分析システムのNode.jsを16から20にアップデートしました

<p>株式会社プレイドでデザインエンジニアをしている安田です。</p>
<p>この記事では、社内向けに提供しているライブラリの使用状況を把握すべく作成した、プロダクト全体のソースコードを解析して、提供しているモジュールおよびそれを使用しているプロダクトごとに個別に自動集計する仕組みとその実装方法について解説します。</p>
<h2>ライブラリ開発の問題と使用状況の解析</h2>
<p>弊社では、KARTEのプロダクト群全体のデザインシステムである「Sour」を開発しています。その一環として、React製のUIライブラリ「sour-react」を作成し、社内向けのnpmパッケージとして提供しています。現在、sour-reactはKARTEのいくつものプロダクトにおいて採用されており、UI開発に欠かせないものになるほど浸透しています。</p>
<p>作成したライブラリが広く使われるようになるのは喜ばしくもありますが、一方、それに伴って新たな問題が生じることもあります。その一つが、後からの仕様変更、とりわけ破壊的変更が難しくなってしまうことです。</p>
<p>原則的には、できるだけライブラリの破壊的変更を起こさないように開発を進めるべきではあります。しかし、ライブラリの機能が増え続けたり運用期間が長期化したりした結果、いずれその必要に迫られることは多かれ少なかれ避けがたいものです。</p>
<p>もし、ライブラリのユーザー数が少なく、その使用範囲も微々たるものであれば、破壊的変更が発生しても対応は容易です。しかしsour-reactは、数多くのプロダクトのUIにふんだんに組み込まれているため、破壊的変更に伴う影響を軽視できなくなりつつあります。また、破壊的変更に対応するためのユーザー側の労力が大きくなればなるほど、バージョンアップ作業が滞ってしまい、UIの不具合が放置される結果に繋がってしまうこともあります。とはいえ、その影響を必要以上に懸念して、変更すべきものを変更せずに誤魔化し続けるのも不健全です。</p>
<p>そこで、仕様変更に伴う影響範囲を適切に把握すべく、ライブラリの使用状況を解析して可視化する仕組みを作成しました。具体的に言えば、KARTEのすべてのソースコードの中から、sour-reactが読み込まれている箇所を検出して、どのプロダクトからどのモジュールが参照されているかを個別に自動集計するというプログラムを作成しています。これを用いて、マークダウンファイルとして次のような集計結果を出力しています。</p>
<p><img src="https://ik.imagekit.io/plaid/b771e07d-ef2a-4f12-a1cb-05c25b971b8a/1.png" alt="表形式で「Accordion」「AdminLayout」「AutoComplete」などの行が並び、列ごとに数値がそれぞれ表示されている"></p>
<p><img src="https://ik.imagekit.io/plaid/0f570cbc-c10d-414a-9123-a67b638c14e1/2.png" alt="「sour-reactのモジュールごとの集計」という大見出しがあり、「Button (422)」という中見出しに続いて「XXX (140)」という小見出しがある。続いてファイルパスがリストで表示されている"></p>
<p><img src="https://ik.imagekit.io/plaid/02a8f29d-635b-4b2e-99dc-2eb40a111be7/3.png" alt="「sour-reactを利用するパッケージごとの集計」という大見出しがあり、「XXX (1720)」という中見出しに続いて「Button (140)」という小見出しがある。続いてファイルパスがリストで表示されている"></p>
<p>これらの集計はGitHub Actionsによって定期的に自動実行され、毎朝9時になるたび最新の状態にアップデートされるようになっています。</p>
<p>この仕組みによって、実際にモジュールが参照されている箇所や、どのモジュールの使用頻度が高いか、どのプロダクトにおいて積極的に採用されているかなどを、効率的に調査できるようになりました。</p>
<p>一つの活用例としては、不要なモジュールをライブラリから削除するために、この集計結果を参考にして選定したことが挙げられます。Sourにはその歴史的な経緯により、特定のプロダクトでしか使われないような特殊なモジュールや機能が多く含まれていました。それらは本来的には、共有ライブラリとしてではなく、それぞれのプロダクト側のソースコードとして管理されるべきです。とはいえ、すでにライブラリとしての提供を行なってしまっている以上、意図せずそれらが使用されてしまっている可能性もあり、その疑念が晴れない限りは削除してしまうことが必ずしも得策とは言い切れませんでした。そこで、こうした集計結果を参考にすることで、各モジュールの使用状況を正確に把握し、確信を持って安全に変更を行うことができました。</p>
<h2>実装方法の解説</h2>
<p>続いて、先述した仕組みの実装方法について解説します。なお、この記事で紹介する仕組みは、OSSとしてGitHubに公開しています。解説と併せて参照してください。</p>
<p><a href="https://github.com/yuheiy/internal-library-reference-stats">yuheiy/internal-library-reference-stats</a></p>
<p>集計結果の出力形式は次の3種類とします。</p>
<ol>
<li><code>README.md</code>: 横軸がsour-reactのモジュール名、縦軸がプロダクト名になったテーブルを出力する。セルにはそれに対応する参照箇所数を表示する。最終列と最終行には合計値を表示する。</li>
<li><code>by-module-export-name.md</code>: 見出し2がsour-reactのエクスポート名、見出し3がプロダクト名という文書構造になり、参照箇所のファイル一覧がそれに続く。</li>
<li><code>by-user-package.md</code>: 見出し2がプロダクト名、見出し3がsour-reactのエクスポート名という文書構造になり、参照箇所のファイル一覧がそれに続く。</li>
</ol>
<p>処理の流れは主に次のようになります。</p>
<ol>
<li>
<p>KARTEのソースコードを含むGitリポジトリから、拡張子が<code>js,ts,jsx,tsx</code>のいずれかに当たるファイルすべてを読み込む</p>
</li>
<li>
<p>TypeScriptのCompiler APIを使って、sour-reactを読み込むimport文を抽出する</p>
</li>
<li>
<p>import文の形式がnamed importsであれば、そのエクスポートの名前とimport文が出現する行数を取得する</p>
</li>
<li>
<p>named importsの解析結果をフラットな配列としてまとめる</p>
<pre><code class="language-tsx">export type NamedImportsStat = {
  sourcePath: string;
  moduleExportName: string;
  lineRange: LineRange;
};

export function getNamedImportsStats(filePaths: string[]): NamedImportsStats[] {
  // ...
}
</code></pre>
</li>
<li>
<p>解析結果をまとめたものを出力形式に応じて加工して出力する</p>
</li>
</ol>
<p>これらについて、いくつかにポイントを絞って解説します。</p>
<p>まず、ソースコードを解析するに当たって、対象となるソースコードを用意します。この仕組みをGitリポジトリとして管理するのであれば、解析対象のソースコードは<a href="https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E3%82%B5%E3%83%96%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB">サブモジュール</a>として取り込むのがよいでしょう。</p>
<p>それらのソースコードからimport文を抽出するには、ASTを使用するのが最適です。ソースコードからASTを生成するためにはいくつかのやり方がありますが、今回は<a href="https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API">TypeScriptのCompiler API</a>を使用することとします。</p>
<p>sour-reactでは、必要なモジュールを都度named importsによって読み込むことを推奨しています。具体的な使用例は次の通りです。</p>
<pre><code class="language-tsx">import { Button, Tabs } from '@plaidev/sour-react';
</code></pre>
<p>このようなソースコードを解析して、named importsによって読み込まれているエクスポート名と、ソースコード内でimport文が出現する行数を取得します。たとえば次のような実装になります。</p>
<pre><code class="language-tsx">import fs from 'node:fs';
import ts from 'typescript';

type LineRange = {
  start: number;
  end: number;
};

type NamedImports = Record&lt;string, { lineRange: LineRange }&gt;

export function analyzeNamedImports(filePath: string, targetModuleName: string): NamedImports {
  const fileContent = fs.readFileSync(filePath, 'utf8');
  const sourceFile = ts.createSourceFile(filePath, fileContent, ts.ScriptTarget.Latest, true);

  const namedImports: NamedImports = {};

  function visit(node: ts.Node) {
    if (ts.isImportDeclaration(node)) {
      const moduleSpecifier = node.moduleSpecifier.getText().slice(1, -1); // Remove quotes

      if (moduleSpecifier === targetModuleName) {
        const start = sourceFile.getLineAndCharacterOfPosition(node.getStart()).line + 1;
        const end = sourceFile.getLineAndCharacterOfPosition(node.getEnd()).line + 1;
        const lineRange: LineRange = { start, end };

        const importClause = node.importClause;

        if (importClause) {
          if (importClause.namedBindings &amp;&amp; ts.isNamedImports(importClause.namedBindings)) {
            importClause.namedBindings.elements.forEach((element) =&gt; {
              const importName = element.propertyName?.text ?? element.name.text;
              if (!(importName in namedImports)) {
                namedImports[importName] = { lineRange };
              }
            });
          }
        }
      }
    }

    ts.forEachChild(node, visit);
  }

  visit(sourceFile);

  return namedImports;
}
</code></pre>
<p>そして、この結果を後続の処理で扱えるように、フラットな配列としてまとめます。</p>
<pre><code class="language-tsx">import { analyzeNamedImports, type LineRange } from './import-analyzer';

const targetModuleName = '@plaidev/sour-react';

export type NamedImportsStat = {
  sourcePath: string;
  moduleExportName: string;
  lineRange: LineRange;
};

export function getNamedImportsStats(filePaths: string[]) {
  const result: NamedImportsStat[] = [];

  for (const filePath of filePaths) {
    const namedImports = analyzeNamedImports(filePath, targetModuleName);

    for (const [moduleExportName, { lineRange }] of Object.entries(namedImports)) {
      result.push({
        sourcePath: filePath,
        moduleExportName,
        lineRange,
      });
    }
  }

  return result;
}
</code></pre>
<pre><code class="language-tsx">import fg from 'fast-glob';
import { analyzeFiles } from './import-analysis-organizer';

async function main() {
  const filePaths = await fg.glob('internal-library-reference-stats-user-a/**/*.{js,ts,jsx,tsx}');
  const namedImportsStats = getNamedImportsStats(filePaths);
  // ...
}

main().catch((e) =&gt; {
  throw e;
});
</code></pre>
<p>こうして作成した配列を、データの出力形式に応じて分類します。モジュールのエクスポート名とプロダクト名というそれぞれの軸に応じて処理します。</p>
<pre><code class="language-tsx">function groupByModuleExportName(namedImportsStats: NamedImportsStat[]): Map&lt;string, NamedImportsStat[]&gt; {
  // ...
}

function groupByUserPackage(namedImportsStats: NamedImportsStat[]): Map&lt;string, NamedImportsStat[]&gt; {
  // ...
}

const byModuleExportName = groupByModuleExportName(namedImportsStats);
const byUserPackage = groupByUserPackage(namedImportsStats);
</code></pre>
<p>データをプロダクトごとに分類する際には、import文が書かれているファイルがどの<code>package.json</code>に属しているかに基づいて処理します。<a href="https://github.com/sindresorhus/pkg-dir">pkg-dir</a>を使うことで、そのファイルの親に当たる<code>package.json</code>のパスを取得できます。</p>
<pre><code class="language-ts">import path from 'node:path';
import { packageDirectorySync } from 'pkg-dir';

function groupByUserPackage(namedImportsStats: NamedImportsStat[]): Map&lt;string, NamedImportsStat[]&gt; {
  const result = Map.groupBy(namedImportsStats, ({ sourcePath }) =&gt;
    packageDirectorySync({ cwd: path.dirname(sourcePath) })
  );
  // ...
}
</code></pre>
<p>これらのような操作によって、最終的に出力するコンテンツを生成します。実際の処理はやや複雑であるため、説明は割愛します。ご興味があればソースコードを見てみてください。</p>
<p><a href="https://github.com/yuheiy/internal-library-reference-stats/blob/main/scripts/renderers.ts">internal-library-reference-stats/scripts/renderers.ts</a></p>
<p>最後に、これらの処理を定期的に実行させるために、GitHub Actionsのワークフローをセットアップします。ソースコードの解析を行う前に、サブモジュールとsour-reactのバージョンを最新の状態にアップデートするようにします。ワークフローは、日本時間で午前9時になるたび毎日実行されるように設定します。</p>
<pre><code class="language-yaml">name: Auto update

on:
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:

jobs:
  auto-update:
    permissions:
      contents: write
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: true
      - name: Update submodules
        run: git submodule update --remote
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version-file: .nvmrc
          cache: npm
      - name: Install dependencies
        run: |
          npm ci
          npm update @plaidev/sour-react
      - name: Build
        run: npm run build
      - name: Commit changes
        run: |
          git config user.name github-actions[bot]
          git config user.email 41898282+github-actions[bot]@users.noreply.github.com
          git add --all
          git commit -m &quot;Automated build&quot;
          git push
</code></pre>
<h2>internal-library-reference-statsの使い方</h2>
<p><a href="https://github.com/yuheiy/internal-library-reference-stats">internal-library-reference-stats</a>はOSSとして公開されているので、どなたでもご自由に利用することができます。基本的には、次のようにすることで使い始められます。</p>
<ol>
<li>
<p>internal-library-reference-statsをテンプレートリポジトリとして新規リポジトリを作成する</p>
</li>
<li>
<p>作成したGitリポジトリをクローンする。<code>git clone</code>に<code>--recursive</code>フラグを付与するとサブモジュールも併せてクローンできるが、この時点では不要</p>
</li>
<li>
<p>サンプル用のサブモジュールとその設定を削除する</p>
<pre><code class="language-sh">rm -rf user-repositories/*/
rm .gitmodules
git add .
git commit -m &quot;deinit submodules&quot;
</code></pre>
</li>
<li>
<p>解析対象のGitリポジトリをサブモジュールとして追加する</p>
<pre><code class="language-sh">git submodule add https://github.com/&lt;user&gt;/&lt;name&gt; user-repositories/&lt;name&gt;
</code></pre>
</li>
<li>
<p>サブモジュールをクローンするためにトークンが必要であれば、<code>.github/workflows/auto-update.yml</code>でのチェックアウトのステップにトークンを設定する</p>
<pre><code class="language-yml">- name: Checkout
  uses: actions/checkout@v4
  with:
    token: ${{ secrets.GITHUB_ACCESS_TOKEN }}
    submodules: true
</code></pre>
</li>
<li>
<p><code>package.json</code>の<code>name</code>を任意の名前に変更する。これが<code>README.md</code>のタイトルになる</p>
</li>
<li>
<p>解析対象のモジュールをインストールする</p>
<pre><code class="language-sh">npm remove antd
npm install @plaidev/sour-react
</code></pre>
</li>
<li>
<p><code>scripts/config.ts</code>の設定を書き換える</p>
<ul>
<li><code>targetModuleName</code>は解析対象のモジュール名。この記事で言うところの<code>@plaidev/sour-react</code></li>
<li><code>targetModuleTitle</code>は解析対象のモジュールのタイトル。<code>README.md</code>に表示される。<code>targetModuleName</code>と同じでも構わない</li>
<li><code>targetModuleUrl</code>は解析対象のモジュールのURL。<code>README.md</code>からリンクされる</li>
<li><code>userPackageNameMap</code>はプロダクトの表示名。対象となるプロダクトのディレクトリへのパスと、その名前の対応関係を設定する。未設定の場合は、ディレクトリのパスが表示名として出力される。ビルドを実行することで対象ディレクトリを把握できるので、一度ビルドを行ってからの方が設定しやすい</li>
</ul>
</li>
<li>
<p><code>.github/workflows/auto-update.yml</code>でのインストールのステップで、解析対象のモジュールをアップデートするように設定する</p>
<pre><code class="language-yml">- name: Install dependencies
  run: |
    npm ci
    npm install @plaidev/sour-react@latest
</code></pre>
</li>
<li>
<p>依存関係をインストールしてからビルドする。プロダクトの表示名が未設定の場合はディレクトリのパスが出力されるので、別の表示名にしたければ<code>scripts/config.ts</code>で設定する</p>
<pre><code class="language-sh">npm ci
npm run build
</code></pre>
</li>
<li>
<p><code>.github/workflows/auto-update.yml</code>でコメントアウトされた<code>schedule</code>を有効化する</p>
<pre><code class="language-yml">on:
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:
</code></pre>
</li>
<li>
<p>変更をコミットしてプッシュする</p>
</li>
</ol>
<h2>最後に</h2>
<p>ライブラリの使用状況を解析する仕組みについては、ライブラリを開発するエンジニアであれば一度は考えたことがあるかと思いますが、開発コストや実現可能性などの問題により、実際に作成された例はあまり多くはないのではないでしょうか。</p>
<p>今回作成したこの仕組みをオープンソースとして公開することで、みなさんの開発現場においても、使用状況の可視化を実現するための助けになれば幸いです。</p>


プロダクト全体のソースコードを解析して、提供しているモジュールおよびそれを使用しているプロダクトごとに個別に自動集計する仕組みとその実装方法について解説します。

ソースコードを解析して社内向けUIライブラリの使用状況を自動で集計する

<p>ごきげんよう、@tik-son です。</p>
<p>2024年7月25日(木)に開催された <a href="https://techcommunity.microsoft.com/t5/ai-azure-ai-services-blog/openai-s-gpt-4o-mini-now-available-in-api-with-vision/ba-p/4200640">Azure OpenAI Service Dev Day（AOAI Dev Day）</a>にて、「Microsoft の AI 技術をベースに構成される Craft Copilot」というタイトルで登壇してきました。<br>
今回はそのレポートをお届けします。</p>
<h2>イベント概要</h2>
<p>AOAI Dev Day は、Azure OpenAI Service を活用する開発者コミュニティの祭典です。<br>
「開発者が実際のプロジェクトから得た経験や教訓を共有する」という趣旨のもと、実践的なセッションが多く見受けられ、オフライン開催限定ならではの一体感と熱気に包まれていました！</p>
<h2>登壇内容サマリー</h2>
<p>今回の私のセッションでは、プレイドが開発する PaaS である「KARTE Craft」の開発を支援する AI アシスタント「Craft Copilot」の仕組みについて、アーキテクチャや技術選定の背景を交えながら解説しました。</p>
<script defer class="speakerdeck-embed" data-id="b43df62d30944212a86f0c5e92c65d8b" data-ratio="1.7772511848341233" src="//speakerdeck.com/assets/embed.js"></script>
<h3>Craft Copilot とは？</h3>
<p>「Craft Copilot」は、KARTE Craft での開発体験を向上させるために生まれた AI アシスタントです。<br>
現在β版として提供中で、将来的には KARTE Craft を利用する開発者の強力なパートナーとなることを目指しています。</p>
<h3>Craft Copilot の機能</h3>
<p>Craft Copilot は、色々あるのですが、今回の登壇では主要機能である以下の2つの機能についてお話しました。</p>
<ol>
<li><strong>AI によるサイト制作支援</strong><br>
Craft Sites Copilot」機能により、HTML や CSS のコードを書かずに、自然言語の指示やイメージ画像から Web ページを自動生成できます。</li>
<li><strong>Craft のルールを踏まえたコード改善</strong><br>
既存のコードを Craft のルールに沿って自動的に修正できます。</li>
</ol>
<h3>技術スタックの裏側</h3>
<p>Craft Copilot は、Microsoft が提供する Azure OpenAI Service を中心に、Azure の様々なサービスを組み合わせて開発されています。</p>
<p><strong>Azure OpenAI Service (GPT-4o, GPT-4o-mini)</strong></p>
<ul>
<li>自然言語処理の中核を担っており、HTML 生成やコード修正の指示理解、回答生成などを実現しています。</li>
</ul>
<p><strong>Azure AI Search</strong></p>
<ul>
<li>Craft Copilot が参照するドキュメントをベクトル化して保存・検索するために利用しています。</li>
<li>セマンティックハイブリッド検索によって、高精度な検索を実現しています。</li>
</ul>
<p><strong>Azure API Management</strong></p>
<ul>
<li>API の可用性、キャパシティ、メンテナビリティを向上させるために利用しています。</li>
<li>Backend Pool やサーキットブレーカーを活用することで、柔軟な API 運用を実現しています。</li>
</ul>
<h2>登壇を終えて</h2>
<p>今回の AOAI Dev Day では、Craft Copilot のアーキテクチャや Azureサービス利用におけるTips などに対して高い関心を寄せていただき、登壇後に、Ask the Speakerで多くの方とお話ししました。</p>
<p>また、他の登壇者の方々との交流を通して、Azure OpenAI Service を活用したサービス開発の最新動向や、AI 開発における課題や展望を共有することができ、<br>
改めて、Azure OpenAI Service は、開発者にとって大きな可能性を秘めていることを実感しました。</p>
<h2>イベント後のアップデート</h2>
<p>実は、今回の登壇時には OpenAI の GPT-4o-mini を利用していたのですが、先日、<a href="https://techcommunity.microsoft.com/t5/ai-azure-ai-services-blog/openai-s-gpt-4o-mini-now-available-in-api-with-vision/ba-p/4200640">Azure OpenAI Service 版の GPT4o-mini がリリース</a>されたので置き換えました。<br>
このスピード感は開発者としてはありがたいですね。</p>
<p>Craft Copilot はまだβ版ですが、今後も Azure OpenAI Service の最新機能やアップデートを積極的に活用し、より強力な AI アシスタントを目指して、今後も開発を続けていきます。<br>
一緒に改善していきたい人も<a href="https://recruit.plaid.co.jp/requisitions/product-engineer">絶賛募集中</a>です！</p>


2024年7月25日(木)に開催された Azure OpenAI Service Dev Day（AOAI Dev Day）にて、「Microsoft の AI 技術をベースに構成される Craft Copilot」というタイトルで登壇してきました。今回はそのレポートをお届けします。

Azure OpenAI Service Dev Day に登壇しました_プレイドエンジニアブログ

Azure OpenAI Service Dev Day に登壇しました

<h1>はじめに</h1>
<p>こんにちは、プレイドのCore Platformチームに所属している西村です。今回のブログではGCE上でセルフホストしていたMongoDBインスタンスをMongoDB Atlasに移行した際の取り組みについて紹介します。移行に伴う要件や制約を考慮した結果、今回はあえてMongoDB固有の機能を使わずにGKEのJobを使って愚直にデータ移行する方法を採用したので、同じような移行作業を行う場合は参考になれば幸いです。</p>
<h2>背景</h2>
<p>プレイドではDBとして多くの部分で<a href="https://www.mongodb.com/ja-jp/atlas">MongoDB Atlas</a>を使用しています。MongoDB Atlasでは定期的にサポートバージョンが更新され、プレイドでもそれに合わせて適宜バージョンアップ対応を行っています。<a href="https://tech.plaid.co.jp/internship-mongodb-update">前回のバージョンアップ作業</a>は2023年末から2024年3月頃にかけて実施したのですが、そこで長らくGCE上で稼働していた古いバージョンのMongoインスタンスをこの機会にMongoDB Atlasに移行することにしました。</p>
<p>このインスタンスはOplogというKARTEの管理画面の操作履歴を保存しているもの（以降、旧Oplog）で、通常はほとんど参照されないデータなのでこれまでのバージョンアップ作業でも見落とされてしまっていました。しかし今回のバージョンアップでこのインスタンスで稼働しているMongoのバージョン（3.x）と更新後のバージョン（5.x）の互換性がなくなるため、こちらもバージョンアップ対応するかMongoDB Atlasに移行するか選択する必要がありました。今後のバージョンアップ対応や管理の煩雑さを考えて、この機に旧Oplogを廃止してMongoDB Atlas（以降、新Oplog）に移行する判断をしました。</p>
<h2>移行方法の検討</h2>
<p>移行にあたってまず要件を決める必要があります。今回の移行プロジェクトの要件は以下のように定めました。</p>
<ul>
<li>旧Oplogの過去データをすべて新Oplogに移行する</li>
<li>サービスは無停止でデータおよび書き込み先の移行を行う</li>
<li>想定外のトラブルがあってもデータの欠損が極力発生しないようにする</li>
<li>移行完了後に旧Oplogは廃止する</li>
</ul>
<p>上記の要件を満たすために以下の作業を順次実施することにしました。</p>
<ol>
<li>MongoDB Atlasに移行用Clusterを作成する（新Oplog）</li>
<li>旧Oplogの書き込みと同時に新Oplogにもデータを書き込む2重書き込みの仕組みを実装する</li>
<li>2重書き込みが問題なくできていることを確認し、旧Oplogのデータを新Oplogに移行する</li>
<li>データ移行完了後、旧Oplogへの書き込みを停止しインスタンスを破棄する</li>
</ol>
<p>図にすると以下のようなイメージです。<br>
<img src="https://ik.imagekit.io/plaid/ee37750e-63d1-47ac-9991-552cf0506361/migrate-oplog-2.png" alt="migrate-oplog-2.png"></p>
<p>以下ではそれぞれの手順で実施した内容について要点を解説します。</p>
<h3>旧Oplogの書き込みと同時に新Oplogにもデータを書き込む2重書き込みの仕組みを実装する</h3>
<p>DBの移行にあたって必要な作業は主にデータ移行と接続先の変更の2つです。論理的には旧Oplogに書き込んでいる箇所の書き込み先を新しく作成した新Oplogに変更すれば新規に書き込むデータに関しては移行できるはずですが、いきなり接続先を切り替えると不具合があって書き込みができないなどのトラブルが発生した場合にデータが欠損してしまうため、慎重を期すために従来通り旧Oplogへの書き込みをしつつ新たに新Oplogへも同時に書き込む仕組みを実装し、既存の仕組みに影響を与えないようにしました。</p>
<h3>2重書き込みが問題なくできていることを確認し、旧Oplogのデータを新Oplogに移行する</h3>
<p>2重書き込みについては特に大きな問題もなく実装することができました。これは一部のシステムを除いて旧Oplogを書き込む処理は社内の共通ライブラリ経由で実行されており、書き込み先の設定を変えて新Oplogへの書き込み処理を追加するだけで済んだためです。</p>
<p>あとは旧Oplogのデータを移行すれば必要な作業はほぼ終わりだったのですが、データ移行処理がなかなかうまくいかず試行錯誤が必要でした。その試行錯誤について詳しく見る前に、まずはMongoDBで推奨されているデータ移行方法と、なぜ今回それらの方法を採用しなかったのか簡単に説明します。</p>
<h3>MongoDB標準のデータ移行方法</h3>
<p>MongoDB標準のデータ移行方法としてJSON/CSVでの<a href="https://www.mongodb.com/docs/compass/current/import-export/">Import/Export</a>と<a href="https://www.mongodb.com/ja-jp/products/platform/migrate">Live Migration</a>があります。それぞれについて簡単に説明します。</p>
<h4>Import/Export</h4>
<p>Import/Exportは<a href="https://www.mongodb.com/ja-jp/products/tools/compass">MongoDB Compass</a>での操作もしくはCLIでそれぞれに対応したコマンドを実行することでCollectionのデータを指定したフォーマットでExportおよびImportすることができる機能です。前回のMongoバージョンアップ作業で4.x→5.xでも想定外の微妙な挙動の差異があったが今回は3.x→5.xなので動作差分が読めないこと、本番データ量が膨大（約2.3億レコード、500GB以上）で一括Importに懸念があることなどから今回は採用しないことにしました（とはいえ一度試してみてもよかったかも）。</p>
<h4>Live Migration</h4>
<p>Live MigrationはMongoDB Atlasで提供されている機能で、コンソールから設定するだけでオンプレミスも含めて任意の環境からMongoDB AtlasのClusterにデータ移行できるという機能です。Live Migrationではデータ移行中も移行元DBへの読み取りおよび書き込みが可能ですが、別のチームで試してみたところ断続的に常に書き込みが発生しているシステムだとデータ移行が完了できないという特性があり、完全に無停止でデータを移行しきるのは難しいとのことでした。</p>
<p>上記のようにMongoDBの標準的なデータ移行方法では今回の要件を満たすことが難しそうだったため、旧OplogからCursorでデータを取得し新Oplogに書き戻すという愚直な方針を採用することにしました。</p>
<h3>GKEでデータ移行用のJobを実行する</h3>
<p>プレイドではアプリケーションの実行環境として多くの場所でGKEを使用しています。既存のデプロイの仕組みを流用するため、今回はデータ移行用のスクリプトをGKEのJobで実行することにしました。データ移行にあたっては以下の手順で段階的に進めていきました。</p>
<ol>
<li>Dev環境にテスト用Clusterを作成し、少量のデータを移行する</li>
<li>Evaluation環境に移行用Clusterを作成し、Evaluationの旧Oplogのデータを移行する</li>
<li>Production環境に移行用Clusterを作成し、Productionの旧Oplogのデータを移行する</li>
</ol>
<p>以下で各手順で試した内容と結果を説明します。</p>
<h4>Dev環境にテスト用Clusterを作成し、少量のデータを移行する</h4>
<p>まずは旧Oplogから取得した任意のデータを新Oplogに書き込めることを確認するため、Dev環境で作成したテスト用ClusterにEvaluation環境の旧Oplogの1日分のデータを書き込んでみることにしました。データ量としては約5000〜6000レコード程度で、以下のような移行スクリプトで問題なく書き込めることが確認できました（サンプル用に簡略化しています）。</p>
<pre><code class="language-typescript">(async () =&gt; {
  console.log('Start: oplog-migration');
  const oplogGce = OperationLog(...);
  const oplogAtlas = OperationLogAtlas(...);

  // 移行時点以前のデータを抽出する（日付は仮）
  const dateBegin = new Date('2024-04-01T00:00:00.000+00:00');
  const dateEnd = new Date('2024-04-02T00:00:00.000+00:00');
  const cursor = oplogGce.find({ timestamp: { $gte: dateBegin, $lt: dateEnd } }).cursor({ batchSize: 5000 });

  cursor.on('data', (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    oplog.save();
  });

  cursor.on('end', () =&gt; {
    console.log('End: oplog-migration');
  });
})();
</code></pre>
<h4>Evaluation環境に移行用Clusterを作成し、Evaluationの旧Oplogのデータを移行する</h4>
<p>テスト用Clusterへの書き込みが問題なく行えたので次はEvaluationの過去データ（約300万件、5GB程度）を移行するために日付の指定と書き込み先を変えて先ほどのJobを動かしたところOOM(Out Of Memory)エラーが発生するようになりました。</p>
<p>お気づきの方も多いかと思いますが、先ほどのコードではCurosrで取得したデータを1件ずつ書き込んでいたためデータ件数が多くなると書き込み処理が追いつかずOOMが発生してしまいます。今回のケースだと数万件程度処理が進んだ段階でOOMが発生しました。OOMを避けるためバッチサイズごとにバルクで書き込むように修正することでOOMの発生を抑えることができました。</p>
<pre><code class="language-typescript">(async () =&gt; {
  console.log('Start: oplog-migration');
  const oplogGce = OperationLog(...);
  const oplogAtlas = OperationLogAtlas(...);

  // 移行対象のデータを抽出する（日付は仮）
  const date = new Date('2024-04-01T00:00:00.000+00:00');
  const batchSize = 5000;
  const cursor = oplogGce.find({ timestamp: { $lte: date } }).cursor({ batchSize });

  let bulkOps: any[] = [];
  cursor.on('data', async (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    bulkOps.push({ insertOne: { document: oplog } });

    if (bulkOps.length === batchSize) {
      await oplogAtlas.bulkWrite(bulkOps);
      bulkOps = [];
    }
  });

  cursor.on('end', async () =&gt; {
    if (bulkOps.length &gt; 0) {
      await oplogAtlas.bulkWrite(bulkOps);
    }
    console.log('End: oplog-migration');
  });
})();
</code></pre>
<h5>途中でJobが止まる問題が発生</h5>
<p>前項のようにCurosrで取得したデータをバルクでまとめて処理することで安定的にJobを実行することができるようになりましたが、今度は20万件程度のデータを処理した時点で、残りの処理が完了する前にJob自体が終了してしまうという問題に遭遇しました。ここに至るまでにもOOM対策としてヒープメモリを追加したりCPUスペックの強化、 <code>async/await</code> で新Oplogへの書き込み結果を待つなどの試行錯誤をしてきたのですが、エラーログやGKEのメトリクスを見ても特に問題はなく、Jobとしてはすべての処理が完了して正常終了しているように見えました。</p>
<p>原因を調べるために調査用のログを仕込んで観察してみると、どうやら新Oplogへ書き込んでいる箇所のawaitが効いていなさそうだということがわかりました。つまり新Oplogへの書き込み箇所でawaitすることで書き込み処理の完了を待っているつもりだったのですが、Cursorの <code>on('data', ...)</code> はデータがある限り実行され続けてしまうため、新Oplogへの書き込みが完了する前にCursorの読み込みが終わってしまうという状態になっていそうだということがわかりました。</p>
<p>上記の現象の対策として新Oplogへの書き込み中はCursorの読み込みを一時停止し完了後に再開することで、無事に意図通りの挙動にすることができました。最終的なコードは以下のようになりました。</p>
<pre><code class="language-typescript">  let bulkOps: any[] = [];
  cursor.on('data', async (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    bulkOps.push({ insertOne: { document: oplog } });

    if (bulkOps.length === batchSize) {
      cursor.pause();  // 書き込み前にCursorの読み込みを中断
      await oplogAtlas.bulkWrite(bulkOps);
      bulkOps = [];
      cursor.resume();  // 書き込み完了後にCursorの読み込みを再開
    }
  });
</code></pre>
<h4>Production環境に移行用Clusterを作成し、Productionの旧Oplogのデータを移行する</h4>
<p>前項まで見てきたようにいろいろな落とし穴にハマりつつ、なんとか安定的にJobを動かしCursorで逐次的にデータを取得しMongoDB AtlasのClusterに大量データを書き込むという一連の処理を実装することができました。最後の仕上げとしてProduction環境の旧Oplogから新Oplogへのデータ移行Jobを実行して無事に全データを移行することができました。ちなみにProductionのデータは5年以上分、500GB程度ありJobの完了までに27時間程度かかりました。</p>
<h2>まとめ</h2>
<p>本ブログではGCE上で稼働しているMongoDBインスタンスを無停止でMongoDB Atlasに移行した取り組みを紹介しました。今回の取り組みではサービス固有の機能に依存しない汎用的な手法で移行を行ったので、似たような作業をされる場合の一つの方法として参考になれば幸いです。</p>


GCE上でセルフホストしていたMongoDBインスタンスをサービス無停止でMongoDB Atlasに移行した取り組みを紹介します

セルフホストしてるMongoDBをMongoDB Atlasに移行した話_プレイドエンジニアブログ

セルフホストしているMongoDBをMongoDB Atlasに移行した話

<p>エンジニアの石井と申します。</p>
<p>プレイドは2024年7月9日 (火) に開催された <a href="https://www.cnia.io/pek2024/">Platform Engineering Kaigi 2024</a> にゴールドスポンサーとして参加いたしました。スポンサーセッションでは「モノリス開発の名残からの脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と堅牢性を追求した認可基盤刷新の過程と工夫」というタイトルで登壇させていただきました。</p>
<p>かつて <a href="https://karte.io/">KARTE</a> がモノリスだった頃の名残を留めていた認可基盤とその問題点、刷新後のアーキテクチャや安全な移行のために施した工夫などについてお話ししています。</p>
<p>この記事では、発表内容を紹介しつつ、構成上発表に含めなかった内容や当日いただいた質問への返答コメントも一部紹介しています。録画もございますので、発表内容の全体についてはそちらも合わせてご覧ください。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="モノリス開発の名残から脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と 堅牢性を追求した認可基盤刷新の過程と工夫" src="https://speakerdeck.com/player/be7d5d49f7104e4196a52f3b72fb25fb" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.25%;"><iframe title="Platform Engineering Kaigi 2024 トラックB" src="https://www.youtube.com/embed/Hsob6TGTAPo?rel=0&start=21735" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no" allow="accelerometer; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share;"></iframe></div>
<h1>概要</h1>
<p>昨今の KARTE ではマルチプロダクト展開が進んでおり、コードやデータベースは分割されていますが、認可基盤だけは全てのプロダクトで共通のコードを利用していました。これはいくつかの問題を抱えていました。</p>
<p><img src="https://ik.imagekit.io/plaid/899c8100-634a-4bc5-8b06-59869a8ec6b1/express-server.png" alt="express-server.png"></p>
<p>そこで、まずは新たな認可基盤のアーキテクチャについて検討しました。認可基盤を一枚岩のものとして構築するか、あるいは分散させて配置するか、どちらも一長一短があり迷いましたが、最終的には分散させる方針に決定しました。アプリケーションが稼働する Pod それぞれに対して、認可のためのコンテナをサイドカーとして配置しています。</p>
<p><img src="https://ik.imagekit.io/plaid/193ea499-4c4e-4eed-bdf8-6c4fe0ba061c/karte-gateway.png" alt="karte-gateway.png"></p>
<p>認可用のコンテナには、アプリケーションごとに異なる認可の設定を施す必要があります。設定をどのように渡すべきかもいくつか選択肢がありましたが、最終的にはコンテナの中に組み込むことにしました。KARTE のデプロイには GitOps が採用されていますが、それに伴うリポジトリ構成なども考慮した上で、このような結論に至りました。</p>
<p><img src="https://ik.imagekit.io/plaid/17cc665e-3b1f-4051-8818-e05f91b80f40/karte-gateway-simplified-config.png" alt="karte-gateway-simplified-config.png"></p>
<p>KARTE にはエンドユーザー、すなわちプレイドにとってのお客様 (企業) のお客様 (ユーザー) の個人情報が蓄積されています。そのため認可基盤のバグ、特に本来拒絶すべきリクエストを誤って許容してしまうケースが生じないように注意を払いました。従来の認可機構と二重で認可を行いつつ、問題があればアラートが鳴るよう仕込んだ上で、徐々に移行を進めました。</p>
<p><img src="https://ik.imagekit.io/plaid/fa702baf-adcd-4b46-aa7c-0bc7a835df82/authentication-migration-2.png" alt="authentication-migration-2.png"></p>
<p>認可基盤の移行はほぼ完了していますが、運用自体はまだ始まって間もない段階です。現在の形に至るまでの意思決定が適切なものであったかどうかは、今後の過程で検証されていくでしょう。</p>
<h1>おまけ</h1>
<p>時間の都合で今回の発表からは省きましたが、アーキテクチャを検討していた時期には、どのように Pod にサイドカーを入れるのかについても議論がありました。</p>
<p>最初に参考にしたのは Istio です。今回お話しした認可基盤はサービスメッシュとは異なりますが、プロキシとして動作するサイドカーを利用するという点では似通っています。そのため、Istio と同じようなサイドカーインジェクションの仕組みが使えるのではないかと考えました。</p>
<p>しかし検討の末、このやり方は見送ることにしました。もしこれを採用する場合、Kubernetes の Admission Webhook を利用してサイドカーを注入する想定でした。しかし</p>
<ul>
<li>Admission Webhook のための追加実装が必要になる</li>
<li>GitOps によって karte-ops リポジトリの Kubernetes マニフェストと GKE 上で稼働するリソースの同期が取られているが、Admission Webhook が介入するとサイドカーがどこで追加されたものなのかわかりにくくなる</li>
</ul>
<p>という懸念が挙げられました。そして最終的には karte-ops リポジトリのマニフェストに直接サイドカーの設定を追加することになりました。</p>
<p>さて、当日いただいた質問の一つに「認可基盤のサイドカーがない状態でデプロイすることを防ぐ仕組みはあるか」というものがあります。上述の通り、認可基盤のサイドカーは自動ではインジェクションされないため、現時点ではそのリスクがあります。しかしマニフェストに対しては conftest を実施しており、事前に定義したルールに沿った設定になっているかを CI でチェックしています。サイドカーなしのデプロイもこれで検知できるのではないかと考え、検討を進めています。</p>
<h1>最後に</h1>
<p>当日のブースにご来場いただいた皆様、セッションをお聞きいただいた皆様、ありがとうございました。個人的には初の登壇でしたが、貴重な経験をさせていただいたことに感謝申し上げます。</p>
<p>そしてイベントのスタッフの皆様、企画ならびに運営のほどありがとうございました。Platform Engineering というテーマに思いを馳せつつ、さまざまな学びを得ることができる良い機会となりました。</p>
<p>今後のプレイドにとっても Platform Engineering は重要なテーマです。今回の参加で得た学びを活かしつつ、日々の開発に取り組んでまいります。</p>


Platform Engineering Kaigi 2024の登壇者によるレポート記事です。「モノリス開発の名残からの脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と堅牢性を追求した認可基盤刷新の過程と工夫」と題したセッションの発表内容を紹介しています。

Platform Engineering Kaigi 2024登壇レポート_プレイドエンジニアブログ

Platform Engineering Kaigi 2024登壇レポート

インターンシップで全社のMongoDBをアップデートした話

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

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

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

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

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

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

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

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

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

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

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