Hello Tech

AutoReserve 等を開発する株式会社ハローのテックブログです。スタートアップの最前線から本質的な価値を届けるための技術を紹介します。

Web高速化1「メンバーを巻き込み、分析基盤を整える」

2023年もあと少しです。スパッと区切りをつけるよりも2024年にバトンを渡すような過ごし方をしたいなと思い、この記事を書き始めました。

2023年はAutoReserveにとって飛躍の年でした。海外レストランの予約開始をはじめとする多くの機能をリリースし、プレスリリースも多く出し、ユーザー数の大台を突破しました。

また飲食店向けに提供しているAutoReserve for Restaurantも今年大きな成長を遂げました。今年だけで30以上もの飲食店さまにご協力いただき導入事例を掲載させていただきました。

しかしその代償もありました。多くの機能をリリースし大きな成長を遂げた筋肉痛として「ページスピードの遅さ」が露見しました。さまざまな機能をスピーディにリリースしながらページスピードを高い水準で維持するのは至難の業です。

夏頃にオーガニック流入を増やすためにSEO周りの改善を始めたところ、ページスピードの遅さが原因の一つであることに気がつきました。Core Web VitalsがSEOの評価に影響し始めたからです(2021年5月より)。

「Webのページスピードを上げよう!」というWeb界隈の流れは2017年くらいから始まったと記憶しています。

俳優 阿部寛のホームページや、デベロッパーフォーラムのdev.toというサイトがいかに速いかを説明するのにPage Speed Insightsが使われて注目されました。

当時はデベロッパーならではの話題であったのが、「何秒遅くなると離脱率がx倍悪化する」というユーザービリティ観点にシフトし、Core Web Vitalsの登場によりSEOに直結するまでになりました。

参考: ページの読み込み時間が 1 秒から 10 秒に増加すると、モバイル サイト訪問者が直帰する確率は123%増加します

www.thinkwithgoogle.com

今や「Webサイトの表示速度はプロダクトチーム、会社として見過ごすことができない指標」となりました。

そこでハローではWeb高速化プロジェクトが立ち上がり、約5ヶ月間集中してサイトを速くする施策をし続けました。

正直なところその道のりは決して順風満帆なものではなく、「もうやれることないよ〜」と何度も壁に当たり、スコアもうなぎ登りになったわけではありませんでした。

それでも、CLSの対策(後述)をしたことでローディングUIが大幅に改善し、サイトのスピードが改善されたことで操作のサクサク感も大幅に増したと自信をもって言えます。

今年1年「ハローとしてどのようにWebの高速化に取り組み、どのような成果が得られたか」を書いていきます。1つの記事でとても収まるものではないので、いくつかの記事に分けて書いていきたいと思います。

まず今回の記事では「チーム全体でページスピードを意識し続ける」ことを念頭に、AutoReserveのページスピードの過去と現在をチームメンバー全員が正しく把握できるデータ基盤を整えた話をします。

エンジニアだけでなくプロダクトオーナーやPM、SEO担当の方などプロダクトに関わる方皆さんに見ていただけたらなと思っております。

Page Speed Insights・Lighthouse・Core Web Vitalsの理解

Web高速化をチームとして追おう!となりいろいろ調べていくと、この3つのワードが出てくるかと思います。

それぞれ何を指しているかを理解すると、今後混乱が防げるかと思うので簡単に説明します。

Lighthouse

Webサイトのページを評価するためのツールです。LighthouseはChrome Extensionを通して使うことができ、Page SpeedだけでなくアクセシビリティやSEOなどの分析をすることができます。

Lighthouseの「パフォーマンス」とPage Speed Insightsのスコアはほぼイコールですが、実行環境が異なります。Lighthouseは実行するPC、Page Speed Insightsは一般的なユーザーの環境を再現しています。

Lighthouseの「パフォーマンス」とPage Speed Insightsのスコアがイコールであると思っていればokです。

Page Speed Insights

Page Speed Insightsは、Webサイトのページスピードを100点満点で表すもっともメジャーな環境です。

Page Speed Insightsには5つの指標FCP, SI, LCP, TBT, CLSがあり、それぞれに配点が振り分けられています。最初の表示がめちゃくちゃ早くても、ロード完了が遅ければそれだけ減点されますし、どれだけ早くてもCLSが最悪なら75点以上獲得できないようになっています。

PSIは現在バージョン10であり、FCP 10点、SI 10点、LCP 25点、TBT 30点、CLS 25点となっています。

各指標に閾値が設定されており、例えばFCP 500ms以下なら10点、1440msなら6点というようにスコアに応じて点数が決定します。

Lighthouse v10における重みづけ

それぞれの指標が何を表しているのかについては、Googleが記事を出しているのでそちらを参照してください。

Lighthouse performance scoring  |  Chrome for Developers

Page Speed Insightsの点数改善は、CLSのみ全く別のアプローチとなっており、それ以外の指標は「表示を早くする」ことに注力すれば改善します。

ドキュメントには「FCP を改善する方法」「LCPを改善する方法」というように、それぞれの指標に対するアプローチが記載されています。

実際に指標と睨めっこしてみると、FCP, SI, LCP, TBTはともに相関関係にあり、「FCPだけを改善する」というよりは「○◯した結果FCPとLCPに良い影響があった」というような経過がありました。よって「この指標を改善するために◯◯をします」というアプローチをするよりも、「改善できるところを洗い出しそれをやった結果、あの指標が改善しました」みたいな流れになるのが自然かと思いました。

次の記事では「CLSを満点にするためにやったこと」、その次の記事では「表示を速くするためにやったこと」をお話しします。

Core Web Vitals

Core Web Vitals は、ページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性に関する実際のユーザー エクスペリエンスを測定する一連の指標です。検索結果でのランキングを上げ、全般的に優れたユーザー エクスペリエンスを提供できるよう、サイト所有者の皆様には、Core Web Vitals を改善することを強くおすすめします。Core Web Vitals は、その他のページ エクスペリエンス要素とともに、Google のコア ランキング システムがランキングを決定する際に考慮する要素です。(Core Web Vitals と Google 検索の検索結果について より)

Core Web VitalsはLCP、CLS、FID(2024年3月からINPになるので、今からやるならINPを意識したほうがよい)の3つの要素から構成されます。Page Speed Insightsの数値を改善することがイコールCore Web Vitalsの結果を改善することにつながると考えて良いです。

しかしながら両者には大きな違いがあります。それは「実際のユーザーの行動データを参照しているかどうか」です。

Core Web Vitalsは実際のユーザーの行動データをもとに算出されます。これはChrome UX Reportを参照すればよくわかります。Core Web Vitalsはユーザーのネットワーク環境・デバイスのスペック等様々な要因が絡みます。それに対しPage Speed Insightsは、実際のユーザー環境の中でもごく一般的な環境を想定した仮想的な環境のもと実行されます。

最近のPage Speed Insightsでは、上部にCore Web Vitalsの指標、その下にPage Speed Insightsの計測結果が表示されるようになりました。

チーム全体でページスピードを意識するために必要な認識

ハローで高速化プロジェクトを進めるにあたり、ロール問わず知っておいた方がよい知識がいくつかあると実感しました。

中でも大切なものをピックアップして残しておきます。

①スタートが30点以下の場合、点数を上げるのは容易なことではない

Lighthouse Scoring Calculator というものがあります。これを使うと、たとえば「FCP 2,145msのときFCPは何点になるのか?」といったことをシミュレーションすることができます。以下は各指標の簡易的な配点表です。

Percentage First Contentful Paint (10) Speed Index (10) Largest Contentful Paint (25) Total Blocking Time (30)
100% 1,000 1,000 1,000 0
90% 1,800 3,387 2,500 200
80% 2,145 4,074 2,938 292
70% 2,434 4,654 3,300 383
60% 2,712 5,215 3,645 483
50% 3,000 5,800 4,000 600
40% 3,319 6,451 4,389 746
30% 3,697 7,228 4,848 941
20% 4,196 8,258 5,447 1,235
10% 5,000 9,933 6,400 1,800
0% 6,000 12,000 8,000 3,000

Largest Contentful Paintの列を例にとると、1,000ms以下で100%の25点、3,300msで70%の17.5点を獲得できることが分かります。80%から40%の間は約350msで区切られていますが、40%未満になるとその間隔が広くなります。

8,000msより遅い場合は1点も獲得できません。高速化プロジェクト発足時、AutoReserveのLCPは20,000msでした。13,600msも短縮して6400msにしないと点数をもらえないことを意味しています。

0点から100点は決して等間隔ではなく、ざっくり以下のように道のりの辛さが分かれると思っています。

めちゃ大変: 0-30 or 40

頑張ればすぐに結果が出る: 40-80

大変: 80-100

私はこの現状を見て「点数を上げてみせます!」とはとても言えず、「今現在あまりにも遅いのでちょっとやそっとの改善では点数が動きません。点数ではなく秒数の改善を見てほしいです、そっちの方が健康的です」と正直に言いました。(ちなみにプロジェクト開始直後のAutoReserveは5~10点くらいでした)

もしページスピード改善プロジェクトを牽引することになったときは、現状把握を正しく行い、現実的な目標を立てることがとても大切です。一歩ずつ進め、ページスピードが着々と改善していくことをチーム全体で共有し実感していくことが、パフォーマンスを意識したプロダクト開発文化の醸成につながると思っています。

②Core Web Vitalsの改善はタイムラグがある

「Page Speed InsightsとCore Web Vitalsは実行環境が異なる」ということを上段で述べましたが、決定的な違いは結果の即時性にあります。

上段で述べたようにPage Speed Insightsはリアルタイムの計測ですが、Core Web Vitalsはユーザーの行動に基づいて集計されます。そのため結果の反映にラグがあります。

Core Web Vitalsの結果を見る方法は2通りあります。1. Chrome UX Report2. Google Search Consoleの2つです。

Chrome UX Reportは月次でのレポーティングのみなのでリアルタイムさは皆無、Google Search ConsoleはCore Web Vitalsに問題ありなURLの数と、グループごと(URLのパターンによって自動で分別される)の数値しか分かりません。

そのためページスピードの改善経過を正しく把握するには、Page Speed Insightsの結果を追い続けるのが一番です。

しかしながらSEOの担当者は、SEOに直接影響しているCore Web Vitalsの経過を知りたいはずです。Core Web Vitalsの経過を高頻度で把握するには、現状ではChrome UX Report APIを使うのが一番です。下記に記載したGoogle Apps ScriptのコードでChrome UX Report APIも扱っているので参考にしてみてください。

③UI変更の必要がありうる

これは特にCLSに関する話ですが、デザインの変更なしではCLSの改善が進まない場合があります。ということはデザイナーやPMを巻き込んだ改善になる可能性が高いです。

CLSについては https://web.dev/articles/cls?hl=ja を参照してください。

例えばファーストビュー(ロード時に一番最初に表示される領域)に、「ある特定のユーザーグループにだけ動的にバナーを出したい」場合です。CLSはロード開始時とロード終了時のUIのズレを数値化したものです。

CLSの改善方法は「動的コンテンツの表示領域をあらかじめ確保しておく」ことです。単純にその領域を空白にしておくだけでも良いですし、より洗練されたユーザー体験を提供ためにローディングスケルトンを用意するのも良いです(次の記事で詳しく触れます)。しかしこの例のような不確定要素には対応できません。

今回のケースで完全にCLSを改善するためには、「バナーそのものを取り除く」か「別のバナーを表示して、バナー領域が使われない可能性をなくす」対応が必要です。

AutoReserveのレストランページも同様の問題を抱えていました。レストランページの最上部にて、画像が存在する場合は表示するが、存在しない場合は表示しないという実装をしていました。これはCLSに大きな影響を与えます。

AutoReserveが持っているレストラン情報において画像があるレストランは約半数でした。画像があるページの方がリッチなページと捉えられることが多いため、画像部分にスケルトンを実装する方向にしました。画像ありページのCLSは死守しようというわけです。

このように、CLSを改善するためにはエンジニアだけでなくデザイナーやPMを巻き込んで進行することでお互い納得のいく選択をすることができると感じました。

④同一URLグループ内のページ全て改善しないとCore Web Vitalsに改善が見られない

上述のレストランページにおける画像スケルトン対応ですが、画像なしのページはCLSが悪いままなので、No Image画像を表示したいと思いました。

しかしこの時点では対応しませんでした。No Image画像を表示することがデザイン的に好ましくないという声が上がったためです。

CLS改善の経過を見守ると、Core Web Vitals上のCLSは思ったほど改善しませんでした。下記は月毎のCLSのOK割合を示したものです。緑色のGoodの割合が増えるほど良いCLSのページが存在することを示します。反映までのタイムラグがあるので気長に待っていましたが、約10%程度しか改善しませんでした。

Core Web VitalsはURLのグループごとで判定されます。今回改善を行ったのはレストランページなので、CLSがGoodとPoorのページが同一グループに分類されます。明確な理由は分かりませんでしたが、同一グループ内でGoodとPoorが混在する場合は悪い方に引っ張られるのかなと感じました。このままではあまり良くないのではないかと話し合い、No Image画像の表示を決定しました。

No Image画像の実装後明らかにCLSが改善したため、「同一URLグループ内のページ全て改善しないとCore Web Vitalsに改善が見られない」という仮説は一定の信憑性が得られたといってよいと思います。

Page Speed InsightsとCore Web Vitalsの数値を可視化する

ここからは実際に分析環境を作っていきます。データを集計するためのコードは下記に記載したので、基本的にぽちぽちしてれば出来上がるはずですのでぜひ試してみてください!

Page Speed Insights API・Google Spread Sheet・Google Apps Script・Looker Studio(旧Google Data Portal)の4つを使い、デイリーで重要ページのPage Speedを可視化していきます。

1. 事前準備

この可視化プロジェクトは無料で完結しますが、Page Speed Insights・Core Web VitalsのAPIを使うためにそれぞれのAPIキーが必要です。以下のリンクを参照し、APIキーを取得してください。

それぞれのAPIキーはGoogle Cloudプロジェクトに紐づくため、必要に応じてプロジェクトを作成する必要があります。クレジットカード等の登録は必要なく、無料で取得可能です。詳しくは下記のドキュメントを参照してください。

2. Page Speed insightsの結果をGoogle Spread Sheetに出力する

「Google Apps Scriptで、Page Speed Insights APIをfetchしその結果をSpread Sheetに入れる」という流れを作ります。基本的に以下をコピペすれば使うことができます。

// type定義が長くなったのでここでは割愛します。詳しくはリポジトリを参照してください。

const PAGE_SPEED_INSIGHTS_API_ROOT =
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed'
const API_KEY = 'YOUR_PAGESPEED_API_KEY' // https://developers.google.com/speed/docs/insights/v5/get-started?hl=ja#APIKey を参照

各シートのヘッダーを定義しておく
const INITIAL_COLUMN_NAMES = [
  '日付',
  'Performance',
  'FCP score',
  'SI score',
  'LCP score',
  'TBT score',
  'CLS score',
  'FCP time(ms)',
  'SI time(ms)',
  'LCP time(ms)',
  'TBT time(ms)',
  'CLS value',
]

const CORE_WEB_VITALS_API_ROOT = 'https://chromeuxreport.googleapis.com/v1/records:queryRecord' // https://developer.chrome.com/docs/crux/api?hl=ja#crux-api-keyを参照
const CORE_WEB_VITALS_API_KEY = 'YOUR_CORE_WEB_VITALS_API_KEY'

class SpreadSheet {
  private spreadsheet: GoogleAppsScript.Spreadsheet.Spreadsheet

  constructor() {
    this.spreadsheet = SpreadsheetApp.getActiveSpreadsheet()
  }

  get urlListSheet() {
    return this.spreadsheet.getSheetByName('URLs')
  }

  sheetByName(name: string) {
    const sheet = this.spreadsheet.getSheetByName(name)

    if (sheet != null) {
      return sheet
    }

    const newSheet = this.spreadsheet.insertSheet(name)

    // newSheetの一行目に初期値を入れる
    const range = newSheet.getRange(1, 1, 1, INITIAL_COLUMN_NAMES.length)
    range.setValues([INITIAL_COLUMN_NAMES])

    return newSheet
  }
}

const getTargetUrls = () => {
  const spreadsheet = new SpreadSheet()
  const sheet = spreadsheet.urlListSheet

  if (sheet == null) {
    return []
  }

  // シート「URLs」のA,B列の値を取得
  const range = sheet.getRange(1, 1, sheet.getLastRow(), 2)

  return range.getValues().map((v) => ({
    name: v[0] as string,
    url: v[1] as string,
  }))
}

const getPageSpeedResults3Times = (url: string): PageSpeedModel[] => {
  // UrlFetchAppのfetchAllを使い、3回fetchし、その平均値を取得する
  Logger.log(`3 times fetch ${url}`)

  const responses = UrlFetchApp.fetchAll([
    `${PAGE_SPEED_INSIGHTS_API_ROOT}?url=${url}&category=performance&strategy=mobile&key=${API_KEY}`,
    `${PAGE_SPEED_INSIGHTS_API_ROOT}?url=${url}&category=performance&strategy=mobile&key=${API_KEY}`,
    `${PAGE_SPEED_INSIGHTS_API_ROOT}?url=${url}&category=performance&strategy=mobile&key=${API_KEY}`,
  ])

  return responses.map((v) => JSON.parse(v.getContentText()) as PageSpeedModel)
}

const getPageSpeedResult = (url: string): PageSpeedModel => {
  Logger.log(`fetch once ${url}`)
  const response = UrlFetchApp.fetch(
    `${PAGE_SPEED_INSIGHTS_API_ROOT}?url=${url}&category=performance&strategy=mobile&key=${API_KEY}`,
    {}
  )

  const pagespeedResult = JSON.parse(
    response.getContentText()
  ) as PageSpeedModel

  return pagespeedResult
}

const getCoreWebVitals = () => {
  // Core Web Vitalsのレポートはドメインごとに生成されます。対象のwebsiteに書き換えてください
  const origin = 'https://autoreserve.com'

  Logger.log(`fetch ${origin} as core web vitals`)

  const spreadSheet = new SpreadSheet()
  const sheet = spreadSheet.sheetByName('Core Web Vitals')

  const body = {
    origin,
    "formFactor": "PHONE"
  }

  const options = {
    method: 'post' as any,
    contentType: 'application/json',
    payload: JSON.stringify(body)
  }

  // POST APIを実行
  const response = UrlFetchApp.fetch(`${CORE_WEB_VITALS_API_ROOT}?key=${CORE_WEB_VITALS_API_KEY}`, options)
  const corewebVitals = JSON.parse(response.getContentText()) as TCoreWebVitals

  const { metrics } = corewebVitals.record

  const date = new Date()
    .toLocaleDateString('ja-JP', {
      year: 'numeric',
      month: '2-digit',
      day: '2-digit',
    })
    .split('/')
    .join('/')

  Logger.log(metrics.first_contentful_paint)

  const values = {
    fcp: metrics.first_contentful_paint.percentiles.p75,
    fid: metrics.first_input_delay.percentiles.p75,
    inp: metrics.interaction_to_next_paint.percentiles.p75,
    lcp: metrics.largest_contentful_paint.percentiles.p75,
    cls: metrics.cumulative_layout_shift.percentiles.p75,
    ttfb: metrics.experimental_time_to_first_byte.percentiles.p75,
    fcpGreen: metrics.first_contentful_paint.histogram[0].density,
    fcpYellow: metrics.first_contentful_paint.histogram[1].density,
    fcpRed: metrics.first_contentful_paint.histogram[2].density,
    fidGreen: metrics.first_input_delay.histogram[0].density,
    fidYellow: metrics.first_input_delay.histogram[1].density,
    fidRed: metrics.first_input_delay.histogram[2].density,
    inpGreen: metrics.interaction_to_next_paint.histogram[0].density,
    inpYellow: metrics.interaction_to_next_paint.histogram[1].density,
    inpRed: metrics.interaction_to_next_paint.histogram[2].density,
    lcpGreen: metrics.largest_contentful_paint.histogram[0].density,
    lcpYellow: metrics.largest_contentful_paint.histogram[1].density,
    lcpRed: metrics.largest_contentful_paint.histogram[2].density,
    clsGreen: metrics.cumulative_layout_shift.histogram[0].density,
    clsYellow: metrics.cumulative_layout_shift.histogram[1].density,
    clsRed: metrics.cumulative_layout_shift.histogram[2].density,
    ttfbGreen: metrics.experimental_time_to_first_byte.histogram[0].density,
    ttfbYellow: metrics.experimental_time_to_first_byte.histogram[1].density,
    ttfbRed: metrics.experimental_time_to_first_byte.histogram[2].density,
  }

  // valuesをシート最後の行に追加
  sheet.appendRow(
    Object.values({
      date,
      ...values,
    })
  )
}

function batch() {
  const spreadSheet = new SpreadSheet()

  // 検査対象のURL一覧を取得
  const urlList = getTargetUrls()

  urlList.forEach((v, index) => {
    const sheet = spreadSheet.sheetByName(v.name)

    const isAutoReserveUrl = v.url.includes('autoreserve.com')

    const date = new Date()
      .toLocaleDateString('ja-JP', {
        year: 'numeric',
        month: '2-digit',
        day: '2-digit',
      })
      .split('/')
      .join('/')

    let values: TValue

    // 私たちはベンチマークとするサイトも記載している。3回の平均値を取るのは、私たちのページのみ
    if (isAutoReserveUrl) {
      const pagespeedResults = getPageSpeedResults3Times(v.url)

      const vArray: TValue[] = []
      pagespeedResults.forEach((result) => {
        const { categories, audits } = result.lighthouseResult

        vArray.push({
          performance: (categories.performance.score * 100).toFixed(0),
          fcpScore: (
            audits['first-contentful-paint'].score *
            categories.performance.auditRefs.filter(
              (v) => v.id === 'first-contentful-paint'
            )[0].weight
          ).toFixed(1),
          siScore: (
            audits['speed-index'].score *
            categories.performance.auditRefs.filter(
              (v) => v.id === 'speed-index'
            )[0].weight
          ).toFixed(1),
          lcpScore: (
            audits['largest-contentful-paint'].score *
            categories.performance.auditRefs.filter(
              (v) => v.id === 'largest-contentful-paint'
            )[0].weight
          ).toFixed(1),
          tbtScore: (
            audits['total-blocking-time'].score *
            categories.performance.auditRefs.filter(
              (v) => v.id === 'total-blocking-time'
            )[0].weight
          ).toFixed(1),
          clsScore: (
            audits['cumulative-layout-shift'].score *
            categories.performance.auditRefs.filter(
              (v) => v.id === 'cumulative-layout-shift'
            )[0].weight
          ).toFixed(1),
          fcpTime: audits['first-contentful-paint'].numericValue.toFixed(1),
          siTime: audits['speed-index'].numericValue.toFixed(1),
          lcpTime: audits['largest-contentful-paint'].numericValue.toFixed(1),
          tbtTime: audits['total-blocking-time'].numericValue.toFixed(1),
          clsValue: audits['cumulative-layout-shift'].numericValue.toFixed(1),
        })
      })

      // vArrayのkeyそれぞれの平均値を計算。vArray.lengthで割る
      values = {
        performance: (
          vArray.reduce((acc, cur) => acc + parseInt(cur.performance), 0) /
          vArray.length
        ).toFixed(0),
        fcpScore: (
          vArray.reduce((acc, cur) => acc + parseFloat(cur.fcpScore), 0) /
          vArray.length
        ).toFixed(1),
        siScore: (
          vArray.reduce((acc, cur) => acc + parseFloat(cur.siScore), 0) /
          vArray.length
        ).toFixed(1),
        lcpScore: (
          vArray.reduce((acc, cur) => acc + parseFloat(cur.lcpScore), 0) /
          vArray.length
        ).toFixed(1),
        tbtScore: (
          vArray.reduce((acc, cur) => acc + parseFloat(cur.tbtScore), 0) /
          vArray.length
        ).toFixed(1),
        clsScore: (
          vArray.reduce((acc, cur) => acc + parseFloat(cur.clsScore), 0) /
          vArray.length
        ).toFixed(1),
        fcpTime: (
          vArray.reduce((acc, cur) => acc + parseFloat(cur.fcpTime), 0) /
          vArray.length
        ).toFixed(1),
        siTime: (
          vArray.reduce((acc, cur) => acc + parseFloat(cur.siTime), 0) /
          vArray.length
        ).toFixed(1),
        lcpTime: (
          vArray.reduce((acc, cur) => acc + parseFloat(cur.lcpTime), 0) /
          vArray.length
        ).toFixed(1),
        tbtTime: (
          vArray.reduce((acc, cur) => acc + parseFloat(cur.tbtTime), 0) /
          vArray.length
        ).toFixed(1),
        clsValue: (
          vArray.reduce((acc, cur) => acc + parseFloat(cur.clsValue), 0) /
          vArray.length
        ).toFixed(1),
      }
    } else {
      const pagespeedResult = getPageSpeedResult(v.url)

      const { categories, audits } = pagespeedResult.lighthouseResult

      values = {
        performance: (categories.performance.score * 100).toFixed(0),
        fcpScore: (
          audits['first-contentful-paint'].score *
          categories.performance.auditRefs.filter(
            (v) => v.id === 'first-contentful-paint'
          )[0].weight
        ).toFixed(1),
        siScore: (
          audits['speed-index'].score *
          categories.performance.auditRefs.filter(
            (v) => v.id === 'speed-index'
          )[0].weight
        ).toFixed(1),
        lcpScore: (
          audits['largest-contentful-paint'].score *
          categories.performance.auditRefs.filter(
            (v) => v.id === 'largest-contentful-paint'
          )[0].weight
        ).toFixed(1),
        tbtScore: (
          audits['total-blocking-time'].score *
          categories.performance.auditRefs.filter(
            (v) => v.id === 'total-blocking-time'
          )[0].weight
        ).toFixed(1),
        clsScore: (
          audits['cumulative-layout-shift'].score *
          categories.performance.auditRefs.filter(
            (v) => v.id === 'cumulative-layout-shift'
          )[0].weight
        ).toFixed(1),
        fcpTime: audits['first-contentful-paint'].numericValue.toFixed(1),
        siTime: audits['speed-index'].numericValue.toFixed(1),
        lcpTime: audits['largest-contentful-paint'].numericValue.toFixed(1),
        tbtTime: audits['total-blocking-time'].numericValue.toFixed(1),
        clsValue: audits['cumulative-layout-shift'].numericValue.toFixed(1),
      }

    }

    // valuesをシート最後の行に追加
    sheet.appendRow(
      Object.values({
        date,
        ...values,
      })
    )

    Logger.log(`${v.name} score ${values.performance}`)
    Logger.log(`Done: ${index + 1} / ${urlList.length}`)
  })
}

実装にあたり、Google Apps Scirptのオンラインエディタでコーディングするのはいろいろとやりづらいので、Clasp(TypeScriptをGoogle Apps Scriptにcompileするなどできる)を使って、TypeScriptの恩恵を受けながら実装しました。

Claspを使うとローカルのプロジェクトとGoogle Apps Script, Spread Sheetを紐づけたりできるので、ローカルからpushするだけでリリースが完了します。

Google Apps Scriptにはスケジューリング機能があるため(これがめちゃ便利)、毎日1時に実行するように設定してください。


以下READMEの抜粋です。

準備

npm install -g @google/clasp

Claspの準備

Spreadsheetを作成するGoogleアカウントを選択します

clasp login

このプロジェクトに紐づいたSheetを作成します

clasp create --type sheets

Install deps

yarn

反映

(tscしなくても勝手にトランスパイルしてくれます)

yarn push

データを集めたいURLをSpread Sheetに入力する

  • URLsという名前のシートを作成します
  • A列に名前、B列にURLを入力してください
TOP https://autoreserve.com/ja/
ホーム https://autoreserve.com/ja/jp
検索 https://autoreserve.com/ja/?keyword=%E6%96%B0%E5%AE%BF%E9%A7%85
レストラン詳細 https://autoreserve.com/ja/restaurants/ygJncRkni7pVoBoMWHXg

A列の名前でシートが作成され、そのシートにB列のURLの結果が挿入されるようになります。

Apps Scriptにスケジュールトリガーをつける

画面左のメニューから「トリガー」を選択、トリガー一覧画面を表示し「トリガーを追加」をクリック。

以下のように入力して保存してください。

  • 実行する関数 batch
  • 実行するデプロイを選択 Head
  • イベントのソースを選択 時間主導型
  • 時間ベースのトリガーのタイプを選択 日付ベースのタイマー
  • 時刻を選択 午前0時 ~ 1時

これでスケジュールの設定は完了です。

詳しくはリポジトリを参照してください。https://github.com/hello-ai/pagespeed_aggregator

3. Looker Studioでデータを可視化する

Google Spread Sheetに貯められたデータを可視化するために使います。無料で使うことができます。

下記に私たちが実際に作ったレポートテンプレートを公開しているのでぜひみてみてください(データはサンプルのものを使っています)。

https://lookerstudio.google.com/u/0/reporting/93ddda7c-74b7-4c7a-9024-dd4e2dd00a7a/page/Ud4WD

また、上記「2. Page Speed insightsの結果をGoogle Spread Sheetに出力する」を完了していれば、皆さんのデータをすぐに可視化することも可能です。簡単な手順をご説明します。

①サンプルレポートのPreviewを表示する

下記を開いてください

https://lookerstudio.google.com/u/0/reporting/93ddda7c-74b7-4c7a-9024-dd4e2dd00a7a/page/Ud4WD/preview

②「自分のデータを使用」をクリック

③データソースを自分のSpread Sheetに置き換える

実際に自分が使っているデータに置き換えてグラフやテーブルを表示することができます。私たちはAutoReserveの4ページを対象にしているので、その4ページ(A~Dにあたる)とCore Web Vitalsのシートを選択してデータを置換してください。

④「編集して共有」をクリック

すべてのデータソースを自分たちのものに切り替えたら「編集して共有」をクリックしてください。そうすると、皆さんのデータソースが適用された「Sample Page Speed Report」のレポートが作成されます!「Sample Page Speed Report のコピー」というレポート名になるはずなので任意の名前に変えてください。

これで皆さん専用のPage Speed Reportの完成です。

AutoReserveのチームではこのレポートを見ながら改善の経過を辿り、大きな変化があったところでどのような変更が加えられたかをチェックしています。

「コミットごとにPage Speed InsightsのAPIを叩いて可視化する」ようなことも考えたのですが、それほど頻繁な変化があるわけでもないので日時のレポートにとどめています。

ページスピードに大きな影響を及ぼすJavaScriptのBundle Sizeのチェックはコミットごとに行っています。こちらについては次の次の記事で詳しく触れていきます。


今回は「メンバーを巻き込み、分析基盤を整える」をテーマに、ページスピード周りの解説や、チームメンバー全員が知っておくべき周辺知識、ページスピードレポートの作成まで触れました。皆さんのプロダクトがよりよくより速いものになるための参考になれば幸いです。最後までご覧いただきましてありがとうございました。

ハローではAutoReserveのページスピードを100点に近づけるために力を貸してくれるエンジニアを募集しています。

採用情報 - 株式会社ハロー

ファイルベースのルーティングによるReact Native開発の未来

javascripter です。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。

ハローでは、開発効率の最大化のため継続的に新しい技術を取り入れています。 今回は、AutoReserveのReact Native製アプリにExpo Routerという、Next.jsのファイルベースのルーティングに似たルーターのライブラリを導入した事例を紹介します。

作業時点でのExpo Routerの最新版stableがv1だったため、解説もv1についてになります。現在はExpo Routerはv2がリリースされているため、最新版では一部、記事での解説と異なる可能性があります。

AutoReserveアプリの技術スタック

AutoReserveのネイティブアプリはReact Nativeで書かれており、またウェブ版は、Reactで書かれています。 今回はReact Native製のアプリについて詳しく説明します。

AutoReserveで主に使っている技術は

  • React Native
  • Expo(React Nativeのライブラリやクラウド上のマネージドなサービスを提供するライブラリ・フレームワーク)
    • 高品質で継続的にメンテナンスされているReact Nativeのライブラリ集
    • EASというアプリのビルド、証明書の管理からOTAによるコードの即時配信が可能なマネージドサービス
    • Expo Prebuildというコードによるネイティブコードの自動生成の仕組み
      • AutoReserveではネイティブコードの生成・設定から変更、管理までを全てJSのコードで行なっています。
    • などがあります。
    • その他、AutoReserveではExpoのエコシステムを最大限活用し常に最新のReact Nativeのバージョンに追随できるようにしています。
  • react-navigation

です。

react-navigationとは

AutoReserveではルーティングや画面遷移はreact-navigationを使用しています。

react-navigationのルーティングの定義はReact Routerなどに似ており、Reactのコンポーネントを使用して各画面を定義するようになっています。

ルーティング定義の例:

const Stack = createNativeStackNavigator();

function App() {
  return (
    <NavigationContainer>
      <Stack.Navigator>
        <Stack.Screen name="Home" component={HomeScreen} />
      </Stack.Navigator>
    </NavigationContainer>
  );
}

export default App;

Expo Routerとはなにか

Expo RouterはExpoが新しく出したreact-navigationをベースにしたルーティングライブラリで、主な特徴としてルーティングの定義を全てファイルベースで行い、対応するURLが自動で定義されるということが挙げられます。

URLベースのルーティングを用いる利点としては、下記があります。

  • URLベースのルーティング定義のため各画面への遷移を文字列のみで表現できる
    • 画面の定義がディープリンクと1:1で対応します。
    • 全ての画面遷移をURLとして表現できるため、テストなども非常に書きやすいです。通常の遷移もURLベースで行われるため、Deep LinkがSingle Source Truthとして機能し、テストと実際の使用時の乖離も発生しません。
  • 画面に関連したレイアウトもファイルベースで静的に予測可能な形で定義されているため、画面単位での自動でBundle Splittingを行うことができる(Async Routesと呼ばれる機能)
  • 画面遷移を型安全に行える
    • 次期バージョンのExpo Router v2からはファイル構造を元にリンクに自動で型がつくようになります(Typed Routesと呼ばれる機能)。
      • 存在しない画面への遷移などを静的に型検査できるようになります。

Expo Routerの概要

ファイル構造の例を挙げると、

src/
  app/
    index.tsx
    (auth)
      (tabs)
        (home, account)/
          index.tsx
          account.tsx
          users
            [userId].tsx.tsx
          _layout.tsx
        _layout.tsx
    sign_in/
      index.tsx
    _layout.tsx

このような形になり、_layout.tsxファイルでそのディレクトリで使用するレイアウト定義(スタック、タブなど)を行い、account.tsxなどそれ以外のファイル名で画面定義と同時にルーティング定義を行うことができます。

また、(auth)などと括弧の付いたディレクトリは、ディレクトリ名をURLに露出させずレイアウト定義を行いたい場合に使用します。

各画面にはDeep Link用のURLが自動で付加され

/
/account
/users/:userId
/sign_in

といった遷移先が自動で定義されます。

Next.jsのファイルベースのルーティングとよく似ていますが、ネイティブアプリ特有の要件として、同時にレンダリングされる画面が複数あるということが挙げられます。例えば、スタックベースのルーティングでは、前の画面とpushした先の次の画面がスタックされ、閉じた時も前の画面の入力状態・スクロール位置を維持したまま元の画面に戻ることが可能になっています。

画面遷移で複数画面が同時にメモリ上に存在する例

Expo Routerを導入する大きなメリットとして、全ての画面に対してDeep Linkを自動で生成できるということが挙げられます。

例えば、素のReact Navigationではlinkingというオブジェクトを用いて、画面のルーティングと別にDeep Linkを定義する必要があります。

例:

const config = {
  screens: {
    Home: 'home',
    UserShow: 'users/:userId',
    SignIn: 'sign_in'
  },
};

const linking = {
  prefixes: ['https://example.com', 'example://'],
  config,
};

function App() {
  return (
    <NavigationContainer linking={linking} fallback={<Text>Loading...</Text>}>
      <Stack.Navigator>
        <Stack.Screen name="Home" component={HomeScreen} />
        <Stack.Screen name="UserShow" component={UserShowScreen} />
      </Stack.Navigator>
    </NavigationContainer>
  );
}

コンポーネントベースで定義したルーティングとは別にlinkingでそれぞれの画面に対応するURLを定義しないといけません。

この仕組みの問題点は下記のとおりです。

  • 画面を定義するたびにlinkingオブジェクトも同時に更新する必要があるため、メンテナンスが大変
  • 型安全にDeep Linkを定義できない
    • ルーティングの定義が動的になっているため、ディープリンクが正しい画面を指しているかなどを型的に安全に保証することが仕組み上難しい
  • スタックがネストした画面や、タブへの遷移の場合など、linkingオブジェクトが複雑
  • どのような遷移パターンで画面に到達することができるのかぱっと見で把握することが難しい

Expo Routerを用いると、ディレクトリを見るだけでどのような画面が定義されてるかわかるだけでなく、全ての画面にURLが割り振られるようになるため、Deep Linkの定義漏れがなくなります。

またWebと同様に、画面のパラメータをURLのパラメータとして付加することができます。各パラメータは文字列として渡ってくるため、Webアプリケーションとほとんど同様の仕組みになると思うとわかりやすいと思います。

const router = useRouter()
const params = useLocalSearchParams()

const userId = Numeber(params['userId'])

const onPressUserFollowing = (userId: number) => {
  router.push(`/users/${userId}/following`)
}

return <User userId={userId}>

AutoReserveへの導入

AutoReserveのコードベースはかなり大きく、画面は90個近くあります。 このため、Expo Routerの導入もかなり大規模になりました。

画面定義:

PR:

Expo Router導入のPR

移行作業

具体的に移行で必要になった作業は下記の通りです。

  • 各画面のURLの定義を行う
    • app/ディレクトリ以下に、アプリで使用している全ての画面定義のファイルを作成する。
      • 既存のDeep Linkの定義とのURLの互換性を保ったまま、Deep Linkとして定義されていなかった画面定義も全て行う。
  • レイアウトの定義を行う
    • スタックのレイアウト定義、タブの定義、モーダルの定義、各画面のタイトルの定義の移植などに加え、非認証時のログイン画面へのリダイレクトなどもURLベースへ書き換える。
      • (auth)以下のディレクトリ内で非認証状態であれば/sign_inにリダイレクトさせるなど。
  • 各画面への遷移の変更
    • navigationオブジェクトを用いて画面名を指定して遷移していた部分をURLベースに書き換える必要がある。
      • これが一番分量が多く大変。
navigation.navigate('UserShow', { userId })
// --> Expo Routerを導入後
router.push(`/users/${userId}`)

難しかった箇所

タブ内での画面遷移と、タブを非表示にして全画面で遷移する構造をExpo Routerで表現するのが特に難しかった箇所として挙げられます。

例えば、AutoReserveにはホームタブとアカウントタブなどがあり、ホームタブからレストラン詳細画面に遷移した場合は、タブは非表示になりレストラン詳細画面が全画面で表示されます。 一方で、アカウント詳細画面から予約一覧画面に遷移した場合など、タブが表示されたまま、タブ内で表示される画面があります。

タブ内の遷移

まず、一つ目の問題として、現在のタブ内で画面を開くことがExpo Routerでは簡単にできないという問題がありました。

/*
(tabs)/
  (home, account)/
    index.tsx
    account.tsx
    users/
      [userId].tsx
*/
// /(tabs)/(home)タブ内(ホーム画面)にいる場合:
// (tabs)/(home)/users/:userIdに遷移させたい
router.push(`/users/${userId}`)
// 一方、/(tabs)/(account)タブ内(アカウント画面)にいる場合、
// (tabs)/(account)/users/:userIdに遷移させたい
router.push(`/users/${userId}`)

AutoReserveではホーム画面内からも、各ユーザの画面に到達することができ、またアカウント画面からもユーザ画面にたどっていくことができます。

この場合、単純に/users/:userIdに遷移させると、Expo Routerでは最初にマッチしたルートに遷移する仕様なため、常にホームタブ内で開かれてしまいます。

/(tabs)/(home)/users/:userIdなど、括弧を含めたパスを指定することで指定したタブ内で開くことができますが、ユーザ画面はホーム画面、アカウント画面など複数のタブで再利用される画面のため、ハードコーディングすることができない、という問題がありました。

このため、AutoReserveでは、現在いるタブを元に自動でprefixをつけるという仕組みを導入しました。

function useRouter() {
  const segments = useSegments() // ['(tabs)', '(account)', 'account']など表示している画面のパスが配列として返ってくる
  const router = useExpoRouter()
  return {
    push: (href) => {
      // hrefにオブジェクトが渡ってくる場合などの対応は省略
      let prefix = ''
      // ホームタブ内にいる場合は自動でprefixをつける
      if (segments.include('(home)')) {
        prefix = '/(tabs)/(home)`
      } // ...その他のタブの場合
      router.push(`${prefix}/${href}`)
    },
    // ...
  }
}

タブ内全画面の遷移

元々、素のReact Navigationではタブを非表示にし全画面で表示する画面は、タブの外側に別のNavigatorとして定義していました。

function Top() {
  return <Stack.Navigator>
    {/* ... */}
  </Stack.Navigator>
}

function Tabs() {
  return <Tab.Navigator>
      {/* ... */}
  </Tab.Navigator>
}

function App() {
  return <Stack>
    <Stack.Screen component={Top} />
    <Stack.Screen component={Tabs} />
  </Stack>
}

同じ構造をexpo-routerで表現した場合:

(top)/
  restaurants/
    [restaurantId].tsx
(tabs)/
  (home,account)
    users/
      [userId].tsx

expo-routerを用いた場合も同様の構造として表現しようとしたのですが、この構造をexpo-routerで用いた場合、いくつか問題が発生しました。 まず、(top)以下と、/(tabs)/(home)/restaurants/:restaurantIdの両方に同時にルートを定義する方法がない点。(home, account)などとしてhome, accountの両方に同時にルートを定義することはできますが、階層の異なったルートに同時に定義する方法は見当たりませんでした。

このため、この構造で書く場合、top以下とtabs以下の両方に大量に画面の定義を重複して書かないといけないことになります。 また、もう一つ大きな問題として、パフォーマンスの問題がありました。

上記構造ではタブからtopに遷移して戻った場合などにStack全体の再レンダリングが走り、非常に重くなるという問題が発生しました。 Expo RouterのissueやDiscussionなども一通り検索し関連したissueなども見つけましたが、現状、解決されていないようです。 このため、AutoReserveでは別の方法を採用しました。具体的には、下記のように、全ての画面定義をタブ内に定義する構造にしました。

(tabs)/
  (home, account)/
    restaurants/
      [restaurantId].tsx
    users/
      [userId].tsx

全画面の画面表示は、下記の方法で実現しています。

// /(tabs)/_layout.tsx
export default TabsLayout() {
  const params = useGlobalSearchParams()
  return <Tabs
    tabBar={() => {
      // 画面のパラメータに____tabBarHiddenがついている場合はタブを隠す
      if (params.__tabBarHidden) return null
      return <CustomTabBar />
    }}
  />
}

// 画面
router.push({
  pathname: `/restaurants/${restaurantId}`,
  params: {
    __tabBarHidden: '1'
  }
})

実際には、全画面の画面表示から遷移する先は常に全画面として表示する必要があるため、アプリ内に定義したuseRouter()のラッパー内で、全画面の場合のパラメータを引き継ぐなどの処理を追加しています。

まとめと今後の展望

AutoReserveではExpo Routerを導入することで、アプリの遷移をNext.jsのようにファイルベースで定義し、全画面にディープリンクを自動で持たせることができるようになりました。 改修自体は合計300ファイル以上、+7035行 / -5448行にわたる変更で、コミット数も154と比較的大規模なリファクタリングとなりました。

今回の改修は機能開発を止めることなく、エンジニア1人で数週間かけて行いました。 今回のExpo Routerの導入の意図としては、開発上のメリットもありますが、プロダクト面での改善も目的としています。

AutoReserveはアプリ版とウェブ版があり、ウェブとReact Nativeアプリのコード共通化による同時展開 という記事で紹介したとおり、大部分の実装の共通化を行なっています。 アプリのDeep Linkのメンテナンスが大変・ウェブとアプリで同一の機能を実現できていないケースがあるなどの理由から、Universal Link(iOSなどで、ウェブ版にアクセスしたときに自動で対応する画面がアプリで開く機能)の導入をやめたという経緯があります。

Expo Routerを導入することで、アプリの実装がウェブに近づき、全ての画面にURL経由でアクセスできるようになります。これにより、Universal Linkの導入など、アプリ・ウェブでのシームレスな切り替えなどユーザ体験の向上が容易に実現できるようになります。

今後の展望としては

  • アプリとウェブのURLを完全に互換性を持たせ、実際にUniversal Linkを有効にする。
  • ウェブ版は現在React Routerを使用しているが、さらに実装の共通化を進めていき、ウェブ版とアプリ版での機能差をなくす といったことが挙げられます。

また、現時点ではまだ可能性の一つでしかありませんが、今後Expo Routerの機能が充実することによって、アプリとウェブ版を完全統合できるようになるかもしれないと考えています。 ハローでは、高速なプロダクト開発と開発体験の追求を愛する本物のエンジニアを募集しています。 少しでも気になる方は気軽に javascripter にDMでお声がけください!

採用情報 - 株式会社ハロー

Twilio Flex による多言語コールセンターシステム構築

uiu です。

株式会社ハローでは AutoReserve を運営していますが、サービスの裏側で飲食店やユーザーのサポートのためコールセンターを運用しています。直近では日本語だけでなく英語等多言語でのカスタマーサポートを提供しています。

昨年、カスタマーサポートが利用するコールシステムを、外部のIP電話サービス(MiiTel) から Twilio Flex を使った内製のコールセンターシステムに切り替えました。

Twilio Flex 製システムを運営し始めてから半年以上経つなかで、カスタマイズの知見などが見えてきたので、今回紹介しようと思います。

背景

カスタマーサポートではIP電話サービスを利用していましたが、当時以下のような課題がありました。

  • サポートの品質向上のため、ダッシュボードでの可視化や分析をしたいができることが限られていた
  • 社内CRMとの連携や自動化をしたいがカスタマイズ性や拡張性が限られていた
  • 将来的に、受電時等に日本語だけでなく英語など多言語に対応できるようにしたいが、そのための機能が不足していた

外部IP電話サービスの契約更新タイミングがあったため、そのタイミングでTwilio Flex を使って社内コールセンターシステムを構築することに踏み切りました。

Twilio Flex を選んだのは以下のような理由でした:

  • ダッシュボードでの分析・可視化など、サポート品質改善のために必要な機能がビルトインで揃っている
  • React でプログラマブルに拡張ができ、API連携することにより細かい部分までカスタマイズできる
  • サービス側ですでに Twilio を活用しており、サービスの挙動との連携が比較的簡単だった

Twilio Flex とは

Twilio Flex はコンタクトセンターシステムです。社内では音声での電話通話でのみ利用しています。

Webブラウザ上で使える架電や受電をするIP電話の機能に加えて、リアルタイムにメンバーの稼働状況を可視化するためのダッシュボード機能などが統合されています。

エンジニア目線での最大の特徴は、React を使ってダッシュボードを拡張できて、大部分の要素がプログラマブルにカスタマイズできる、という点です。

Twilio Flex は Programmable Voice, TaskRouter, Twilio Studio といった Twilio が提供している技術要素、API群から構成されており、ほぼすべてがAPI経由でアクセス可能になっています。

ほぼすべてがAPIの形で提供されていて、やろうと思えばどの要素もカスタマイズ可能なので、コールシステム界のAWSといって過言ではないと思います。

カスタマイズに使う React 環境はモダンな開発環境で、Webフロントエンドの現場で React を書いているエンジニアにとっては馴染みやすい開発環境だと思います。

たとえば、Flex Plugin は以下のようなディレクトリ構造の npm package になっており、Plugin 開発時に使う @twilio/flex-ui 等のライブラリも npm package として提供されています。

カスタマイズ

デフォルト設定だけでも Twilio Flex は十分使えるサービスですが、社内でカスタマイズをすることで使い勝手を大幅に改善することができます。

開発してカスタマイズしている内容について紹介します。

プラグインによるCRM連携

社内CRMを連携して Twilio Flex 内に表示するためにプラグインを開発しました。

以下のような機能を実装しています

  • 架電・受電時に、CRMビューに社内CRMを自動的に表示する
  • 通話時に dual channel で録音する
  • 着信時に呼び出し音を再生する
  • 通話時にサービスDBに通話ログを作成する

いくつかピックアップして詳しく説明します。

CRMを自動的に表示する

架電・受電時に作業内容の対応するCRMの画面を自動的に表示する機能を実装しています。

以前は、問い合わせや電話番号に応じてCRMを手で検索する作業が必要でしたが、自動的に表示されることでその手間を削減できるようになりました。

別ドメインで立てている管理画面を iframe で Flex 内に埋め込む仕組みですが、違和感少なく使えています。

左側が Flex のデフォルト画面で、右側がプラグインで表示している社内管理画面です。

着信時に呼び出し音を再生する

デフォルトでは着信時に呼び出し音が鳴らず、ブラウザの別タブで作業していると着信に気づかない可能性があります。

そのため、着信時にピロピロした音を再生するようにしています。以下記事で書かれている方法と同じですが、Flex plugin 内にJSで着信時に発生するイベントにイベントハンドラーを立てることで実装しています。

FlexプラグインTips(着信時に音を鳴らす) - Qiita

Studio Flow によるノーコード拡張

受電時の挙動をノーコードでも拡張できるのは大きなメリットです。

Studio Flow で様々な条件に応じた分岐をノーコードでポチポチするだけで実装できます。

営業時間外でのメッセージ読み上げ、受電時のSlack通知、言語別のルーティングなどを実装しています。

ドキュメントなどではコードを書いて実現されていることも、工夫すれば Studio Flow で簡単に実装できることもありました。

たとえば、営業時間外の判定では現在時刻の時間部分を取り出し、時差を計算した上で営業時刻の範囲と match するかどうか判定することで分岐を実装できます。

Slack の通知も HTTP Request ウィジェットを使い、incoming webhook URLを設定すればコードを書くことなく実装できます。

TaskRouter による多言語コールセンター化

TaskRouter を組み合わせると、電話をスキルに応じてメンバーに振り分け・ルーティングすることができます。

メンバーに言語スキル(例: 日本語 → ja, 英語 → en )を振り、呼び出し元の電話番号等の情報から対応言語を判断することで、自動的に多言語での対応が可能なコールセンターを実現しています。

TaskRouter の全体像はやや理解に時間がかかる面もありますが、以下の記事を参照すればわかるようにはなると思います:

Twilio Flexの始め方(TaskRouter基礎編) - Qiita

設定操作はAWSやGCPのコンソールをポチポチするような感覚に近いです。

開発 tips

ドキュメント

1点、最初困った点を挙げるなら、公式ドキュメントがわかりやすくはないという点です。

TaskRouter など Flex の構成要素を1つ1つ理解しないと全体像が掴めなかったり、Flex plugin を作る際の API の使い方が十分にドキュメント化されてなかったりして、最初の開発作業では戸惑うことが多かったです。

一般的な開発の際には推奨しませんが、Flex での開発の際には Twilioエバンジェリストの方などが書いている Qiita の記事を読むことをおすすめします。時間を大幅に節約できます。

qiita.com

その他

Twilio Flex はバージョンのアップデートを自分たちで管理できるようになっていますが、早く改善を取り込みたいため自動アップデートをONにしています。

開発時には Dev Phone が便利でした。ローカル開発環境のブラウザから電話をかけることができるので、検証・デバッグ時に便利です。電話料金も自前の携帯電話からかけるのと比べて安いです。

導入効果

当初サポートメンバーがスムーズに利用できるかどうか不安でしたが、大きな問題なく日々利用してもらえています。

ダッシュボードでの可視化・リアルタイムでの稼働状況可視化は特にメリットが大きかったです。これまでできなかった細やかな品質向上に取り組むことができていると感じています。サポートメンバーがリモートで働いている環境では特に大きく活用できると思います。

分析画面は以下のように見れます (公式ドキュメントから引用したスクリーンショット)

見ている指標

サポート品質担保・改善のため、見ている指標・メトリクスは多数ありますが、社内で活用している代表的な指標をピックアップすると以下になります:

  • Wrap up Time - 電話対応後のCRMでの処理時間の Agent(メンバー)ごとの平均時間
  • 架電数 - Agent ごとの架電数

たとえば、Wrap up Time が小さすぎる場合は作業が早いですがちゃんと登録作業を行えてない可能性があります。あくまで数字なので、実際の対応内容も合わせてチェックすることで適切なフィードバックができるようにしています。

その他のコールセンター指標やKPIに関しては以下の記事にも書いてあります:

21+ Call Center Metrics to Track | Twilio

まとめ

今回は Twilio Flex を活用して社内でコールセンターシステムを開発運用している話を紹介しました。

フルリモートでコールセンターを運用しているため、対応品質をチェックしたり、しっかり稼働しているかの確認をする上でレポートは必要不可欠な機能です。良い人が正しく評価されるためにも Flex を活用し、細かいデータが出せることは大変ありがたいと感じています。

Web サービスの表側から見えにくい部分だからこそ、サポートは重要だと考えています。今後も品質向上を技術で支援するために、カスタマイズや連携等の開発を進めていきたいと思っています。

また、導入や運用にあたっては Twilio や KDDI Web Communications の皆さんにサポートして頂きました。ありがとうございました。

ハローではサービスを良くするためにあらゆる技術を尽くすエンジニアを募集しています。

hello.ai

PostgreSQL + Rails へ PgBouncer を導入してDBメモリ使用量を大幅に改善した話

uiu です。ハローでは普段バックエンド開発をメインに担当していますが、創業以来片手間でインフラも担当しています。

ハローでは、少数精鋭のメンバーの意識をプロダクト開発に集中するため、インフラ面では Cloud Run などマネージドなサービスを最大限に活用しています。

今回は、久しぶりにインフラに意識の一部を捧げ、いくつかの眠れない夜を過ごす機会があったので、インフラ面の話について紹介しようと思います。

スタートアップと PostgreSQL

AutoReserve はサービス立ち上げ以来、DB は PostgreSQL、APPサーバーは Ruby on Rails のバックエンド構成で運用してきています。

特に PostgreSQL は立ち上げ以来安心して使い続けられている技術要素です。サービス運用から(ある規模までの)分析まで PostgreSQL だけで回せる点は、少人数でプロダクト開発するスタートアップにとって利点が大きかったと思っています。

また、Rails + PostgreSQL 構成の運用に関しての知見は、GitLab HandbookHeroku など質の高いドキュメントにまとまっていて、困ったときに頼りになることも多いです。

Google Cloud の Cloud SQL for PostgreSQL 上で運用しており、トラフィックに応じてスケールアップすることでこれまでサービスを成長させてきました。

大きいテーブルでは、1億行を超えるレコードを持つテーブルもありますが、Declarative Partitioning などの機能を利用することで問題なく運用できています。

課題

PostgreSQL でサービスをスケールさせていく上で、1点ぶち当たる問題は DB コネクション数の上限に到達することです。

PostgreSQL はベストプラクティスとされるコネクション上限が小さいことで知られており、たとえば Cloud SQL のメモリが100GB以上ある環境でもデフォルト設定では高々 1000 コネクション程度です。

たとえば、オートスケール等でAPPサーバーのインスタンス数が増えたタイミングで、PostgreSQL 側のDBコネクション数の枠が足りなくなり、エラーが発生します。

もちろん Rails 側で connection pooling の仕組みはありますが、1 worker 辺り 1 connection を消費することを考えると一定以上のトラフィックが発生するとコネクションが足りなくなります。

キャッシュすることでスループットを高めるなどのアプリケーション側で対処ができるケースもありますが、write が多いケースでは持続的な解決策ではありません。

AutoReserve でもピークタイムで以下のような問題が発生していました:

  • コネクション上限に到達し、新しいDBコネクションが作れないことにより、一部リクエストがサーバーエラーになる
  • 同時コネクション数が増えることで、メモリ使用率が上がり、それと伴うようにDBプロセスがクラッシュする

当初は max_connections 設定を上げることでエラーを回避していましたが、DBプロセスがクラッシュする等の現象が発生するなど不安定性が増したため、解決になりませんでした。
max_connections 設定を上げるだけで、スループットが下がることを報告している記事 もあります。

PgBouncer 導入

Standalone Connection Pooler として PgBouncer を導入することにしました。

PgBouncer は、DBサーバーやAPPサーバーとは独立したサーバーとして動作します。 APPサーバーからDBに直接コネクションを貼る構成では、APPサーバーの数に比例してコネクション数が増えますが、PgBouncer が中間で connection を保持することでDBサーバーに貼られるコネクション数を一定数に抑えられます。

https://devcenter.heroku.com/articles/best-practices-pgbouncer-configuration より引用

DBとAPPサーバーの間に新しいレイヤーを導入することになるため、PgBouncer 自体の不具合によってシステム全体が不安定性になるリスクがあります。

そのため、当初は導入を先延ばしにしていましたが、他の回避策では思ったような効果がなかったため、デメリットはあったものの PgBouncer の導入をトライすることにしました。

PgBouncer の導入後の効果

当然ですが、導入日(1/20辺り)以降、想定通りコネクション数が一定に抑えられています:

メモリ使用量についても大幅に改善しており、ピークタイムでもメモリ使用率が上がることはなくなりました:

これにより、DBクラッシュ等の大きな問題の頻度も減りました。

特にメモリ使用率については驚くほど改善しました。DB全体の安定性が体感でも増したため、僕個人としても睡眠の質が向上しました。

PgBouncer サーバー自体も現状安定して動作しています。その他、APIレスポンスタイム等のメトリクスが劣化することもなかったため、導入は成功だと言ってよさそうです。

PgBouncer デプロイ

デプロイ構成

以下のような構成でデプロイしています:

  • Managed instance group 上に PgBouncer を docker で複数台立ち上げる
  • internal tcp load balancer で複数台の PgBouncer にAPPサーバーからの接続を分散させる
  • docker image は edoburu/pgbouncer を使用

app サーバーからDBまでの接続は以下のような経路になります:

app → internal tcp load balancer → pgbouncer (複数台) → db

app: Rails アプリケーションサーバー
db: PostgreSQL DB

PgBouncer 設定

transaction pooling mode を利用しています。

今回のケースでは、Rails 側ですでに session pooling を行っているため、transaction pooling mode でなければ効果がありません。

全体の connection が200程度になるように調整しています。

注意点

transaction pooling mode では session に依存する機能は使えないことに注意する必要があります。

advisory locks や prepared statements などの機能を使うことができなくなります。

https://www.pgbouncer.org/features.html#sql-feature-map-for-pooling-modes

Rails では、デフォルトで prepared statements が利用されたり、migration で advisory lock が取得されるため、これらの機能を無効にする必要があります。

そのため、database.yml で以下のように無効にしています:

production: &production
  <<: *default
  # ...
  prepared_statements: false
  advisory_locks: false

prepared statements を無効にすることでクエリに若干のオーバーヘッドが発生することが想定されますが、導入後の影響は軽微でした。

参考リンク

最後に、参考になったリンクをまとめておきます。

connection pooling については以下を参照しました:

www.craigkerstiens.com

devcenter.heroku.com

Rails 開発では GitLab Handbook をお手本としてよく参考にしています。GitLab はフルリモート組織のため、開発ドキュメントが綺麗に整理されており、ドキュメントの書き方自体も学ぶ点が多いです。

docs.gitlab.com

Rails の本番運用でのベストプラクティスについては以下も参考にしています。author が Instacart での運用経験から書いたもので、著者のOSSライブラリを利用したり、アイデアをよく参考にしています。

github.com

まとめ

PostgreSQL のコネクション数上限と不安定性の問題を PgBouncer を導入して解決した事例を紹介しました。

PostgreSQL を長年運用している方にとっては常識的な内容ではあるかもしれませんが、誰かの参考になれば嬉しいです。

これからは、段階に応じて AlloyDB などよりスケーラビリティの高いDBへの乗り換えも計画していく予定です。

これからも開発生産性をMAXに保ちつつサービスを成長させていくために、インフラは極力シンプルに保ち、RDBMSを最大限に活用してプロダクト開発を進めていこうと思ってます。

株式会社ハローでは、シンプルに保つこと、高速にプロダクト開発をすること、を愛するエンジニアを募集しています。
業務委託や副業の形でも募集しているので、話を聞いてみたい方は uiu にぜひ気軽にお声がけください。

hello.ai

React NativeとExpoを活用したネイティブビルド不要のE2Eテストの導入

はじめに

はじめまして、株式会社ハローで業務委託として開発をしている@0906kokiです。 今回の記事では、React Nativeで開発されているAutoReserve for Restaurantsで、Expoを最大限に活かしたE2Eテストの導入実装について書きたいと思います。

背景

飲食店向けにセルフオーダーや予約台帳の機能を提供するAutoReserve for Restaurantsは、React Nativeで開発されております。 今回、AutoReserve for RestaurantsにE2Eを導入した目的に関しては、以下のような点が挙げられます。

  • 手動テストの場合、テストをスキップ or 見逃していたケースがあったので、毎回網羅的にテストできるようにし、QAの質を上げたい
  • 頻繁に本番デプロイできるようにする
  • コミットごとにテストできるようにすることで、QAを待たず事前にデグレを検知できる
  • (今後) ライブラリのアップデートなど、全てのテストが通ったら自動でマージできるようにしていきたい
    • 例えば、react-navigationやreact-native-reanimatedなどの全体に影響あるライブラリのパッチバージョンアップなど

これまでも、AutoReserveなどweb側のプロジェクトにはcypressによるテストが導入されていましたが、ネイティブアプリ側のE2Eテストは導入できていませんでした。

理由として一番大きかったのは、

  • ウェブ側のテストと比べ、アプリ側のテストはネイティブビルドのみで数十分以上かかるため、E2Eテストを回すのに時間がかかり、開発のスピード感が損なわれる

という点です。前提の部分に詳しく記載しましたが、今回、ExpoのOTAリリースの仕組みを取り入れることで、ビルドバイナリを再利用することで上記課題を解決し、ウェブと同じようなスピード感でPRのコミットごとにE2Eテストを走らせることができるようになっています。

前提

今回のE2E実装について詳細をお伝えする前に、AutoReserve for RestaurantsのReact Nativeにおける技術的な前提条件について書きたいと思います。

冒頭に AutoReserve for Restaurantsでは React Nativeを使っていると紹介しましたが、React Nativeの中でも、ExpoのManaged Workflowで開発しており、EAS Buildの仕組みを使ってネイティブビルド、ストアリリース等を行っています。 Expoのワークフロー上で開発しているため、ネイティブモジュールに変更が加わらないJavaScript部分の修正に関しては、OTA (Over The Air Update)で、ストアリリースを通さずにリリースを行っており、逆にネイティブに変更が加わり、ストアリリースが必要な際には、EAS Build を使ってネイティブビルドを走らせてから各ストアへのリリースを行います。また、開発時においてもPR単位でExpoのリリースチャンネルを生成してOTAを走らせるため、PRへのpushごとでのJavaScript部分の動作確認やテストが可能となっております。

いずれの場合も、GitHub Actionsでワークフローは自動化されており、Expoを利用する上でのメリットを最大限に享受している形となっています。

実装内容

これらの技術的な前提を置いた上で、E2E を導入した際の実装内容について書きたいと思います。

今回、E2E のライブラリとして、Detox を使用しました。Detoxを採用した理由としては、非同期処理を内部で監視してflakiness(テストの不安定さ)を回避し、実行の安定性を担保してくれる点や React Native用 E2Eツールとして開発されている点などが挙げられます。 前者に関して補足すると、Detoxには同期の仕組みがあり、アプリのネットワークリクエストやアニメーション、タイマーを監視し、自動で完了を待機してくれるため、テストコード側でsleepなどを入れる必要がなく、高速かつ安定的にテストを走らせることができるそうです。

E2E を CI で実行する上で考えたいこと

CI上でE2Eを実行し、事前にデグレを検出したいので、以下のような条件であることが望ましいです。

  • E2E のセットアップ・実行にかかる時間が短いこと
  • 最新の変更に対する E2E テストであること

E2Eの実行速度が速いこと

CIでは基本的に実行時間に対する課金となるため、E2E自体の実行時間は速ければ速いほどハッピーです(イテレーションを速く回すという意味でも)。

通常Detoxは最初にdetox buildという、シミュレータでテストを実行できるようにするためのネイティブビルドを行い、そこで生成したビルドファイルを元にテストを実行します。

このdetox buildは、普通に行うと約10分 ~20分ほど実行に時間がかかり、それをCIで毎回コミットごとに行うことは避けたいことであります。 なので、今回は事前にシミュレータ用のEAS Buildを実行してビルドファイルを生成しておき、 テスト時はそのビルドファイルをExpo上からフェッチしてシミュレータ用のバイナリから最新のJavaScriptのbundleを読み込み、E2Eを実行することとしました。

EAS Buildした最新のビルド結果のリストは、以下のコマンドで取得できます。

$ eas build:list --status finished --platform ios --distribution simulator --non-interactive --json

※ 吐き出される JSON

[
  {
    "id": "...",
    "status": "FINISHED",
    "platform": "IOS",
    "artifacts": {
      "buildUrl": "ビルドファイルのURL",
      "xcodeBuildLogsUrl": "ログURL"
    },
    "initiatingActor": {
      "id": "...",
      "displayName": "..."
    },
    "project": {
      // ...
    }
    // ...
  }
]

CI上でこのコマンドを実行し、上記のJSONから配列の先頭にある artifacts.buildUrl から最新のシミュレータ用ビルドファイルを取得できます。 そのため、 artifacts.buildUrl をフェッチし、プロジェクト内に配置することで、CIで毎回 detox build を行わず、最新のビルド結果フェッチするだけで E2Eを実行できるようになります。

具体的に、以下が取得するスクリプトとなります。

const axios = require("axios");
const path = require("path");
const { existsSync, writeFileSync } = require("fs");
const { execSync } = require("child_process");

const OUTPUT_TAR_PATH = path.resolve(__dirname, "Sample.tar.gz");
const OUTPUT_SIMULATOR_BUILD_BINARY_PATH = path.resolve(__dirname, ".");

// 最新のシミュレータ用ビルドファイルを取得する
const getLatestSimulatorBuildBinary = async (platform) => {
  if (existsSync(`${OUTPUT_SIMULATOR_BUILD_BINARY_PATH}/Sample.app`)) {
    return;
  }

  try {
    // 最新のシミュレータ用ビルドの結果リストを取得する
    const buildJson = execSync(
      `eas build:list --status finished --platform ${platform} --distribution simulator --non-interactive --json`
    );
    // 最新のシミュレータ用ビルドファイルのURLを取得
    const buildUrl = JSON.parse(buildJson.toString())[0]?.artifacts?.buildUrl;
    const response = await fetchBinary(buildUrl);
    writeFileSync(OUTPUT_TAR_PATH, response.data);

    if (!buildUrl) {
      throw new Error(
        "simulator buildしたバイナリが存在しません。simulator buildを実行して、再度試してください。"
      );
    }

    // Sample.appファイルに展開する
    execSync(
      `tar -xf ${OUTPUT_TAR_PATH} -C ${OUTPUT_SIMULATOR_BUILD_BINARY_PATH} && rm -rf ${OUTPUT_TAR_PATH}`
    );

    return console.log("success: バイナリの取得が完了しました。");
  } catch (e) {
    throw new Error(`error log: ${e}`);
  }
};

const fetchBinary = async (url) => {
  return axios.get(url, {
    responseType: "arraybuffer",
    headers: { Accept: "application/x-tar" },
  });
};

// 一旦iOSのみ
(async () => await getLatestSimulatorBuildBinary("ios"))();

先程書いた通り、このシミュレータ用ビルドファイルは 事前にEAS Buildを行ってExpo上から取得できるようにする必要があるため、beta版のネイティブビルドをCIから作成するタイミングでシミュレータ用ビルドも同時に行っています。 これは、beta版をビルドするタイミングは基本的にJavaScriptのbundle以外のネイティブ部分に変更が入るタイミングで、それに合わせてシミュレータビルドも最新にする必要があるためです。

上記のように、detox build を行わずに、最新のシミュレータビルドしたバイナリを取得する方針にしたことで、約10~20分かかっていた時間が、1分未満(フェッチする時間)に短縮することができました。

最新の変更に対する E2E テストであること

CIを実行するたびにE2Eを実行して事前のデグレを検出したいので、当然ではありますが、最新の変更コミットが含まれたものに対して E2Eを実行させる必要があります。 これを実現する方法として、最新のOTAされた JavaScriptの bundleを取得し、その bundleを元にテストを実行する方法です。

前提での部分でも紹介した通り、AutoReserve for RestaurantsではPRごとに 動作確認ができるようにするため、PR単位でリリースチャンネルを作成してOTAを行っております。Expoでは、リリースチャンネルにOTAされたJavaScriptのbundleUrlを取得することができるため、まずは、そのbundleを取得するために、以下のURLからリリースチャネルごとのマニフェストJSONを取得します。

※ URL

https://exp.host/@sample-org/sample/index.exp?release-channel=${対象PRのリリースチャネル}&runtimeVersion=${アプリのバージョン}

※ 返されるJSON

{
  "ios": {
    "jsEngine": "jsc"
    // ...
  },
  "bundleUrl": "OTAされたJavaScriptのbundleファイルのUrl"
}

Manifestにある bundleUrl はOTAされたJavaScriptのbundleファイルのURLであるので、このURLからbundleを取得します。

フェッチからアプリ起動までの流れとしては、以下のような形となります。

  1. bundleUrlをフェッチする
  2. 1でフェッチした bundleUrlを、development buildのdeepLink URLであるexp+app-slug://expo-development-client/?url=のurlに指定する
  3. 上記deepLinkをアプリ起動後に開くURLとして指定する

スクリプトで見た方が分かりやすいと思うので、テストのbeforeAll時 に実行しているlaunchAndOpenApp関数を下記に記載します。

// リリースチャンネルごとの最新のManifestUrl
// RELEASE_CHANNELはGitHub Actions等で環境変数として取得できるようにする
const LATEST_PUBLISHED_MANIFEST_URL = `https://exp.host/sample/sample/index.exp?release-channel=${process.env.RELEASE_CHANNEL}&runtimeVersion=${appConfig.version}`;

const developmentBundleUrl = (platform: PlatformType): string =>
  `http://localhost:8081/index.bundle?platform=${platform}&dev=true&minify=false&disableOnboarding=1`;

const fetchLatestPublishedBundleUrl = async (): Promise<string> => {
  try {
    const response = await axios.get(LATEST_PUBLISHED_MANIFEST_URL);
    const data = response.data;
    return data.bundleUrl;
  } catch (e) {
    throw new Error(e);
  }
};

// 対象のbundleUrl
const getTargetUrl = async (platform: PlatformType): Promise<string> => {
  if (!!process.env.RELEASE_CHANNEL) {
    return fetchLatestPublishedBundleUrl();
  } else {
    // 開発環境の場合は、ローカルのbundleを参照する
    return developmentBundleUrl(platform);
  }
};

const getDeepLinkUrl = (url) =>
  `sample://expo-development-client/?url=${encodeURIComponent(url)}`;

// 指定したdeepLink先を開く
export const openDeepLinkUrl = async () => {
  // 一旦iOSのみ
  const url = await getTargetUrl("ios");
  await device.openURL({
    url: getDeepLinkUrl(url),
  });
};

// アプリを起動する
export const launchAndOpenApp = async () => {
  await device.launchApp({
    delete: true,
    newInstance: true,
    permissions: {
      notifications: "YES",
    },
  });
  await openDeepLinkUrl();
};

アプリ起動後にCI上であればaxiosを使って最新のOTAされたbundleUrlを取得、開発環境であれば、ローカルのbundleUrlを取得します。 取得できたら、deepLinkのqueryStringにそのURLを指定し、device.openURLでdeepLinkを開きます。

このように、アプリ起動時に最新のbundleを取得してdeepLinkを開く関数を用意することで、常に最新の変更に対してのE2E実行が可能となります。

まとめ

Expoを最大限に活用して、React NativeアプリにE2Eを導入する方法を書きました。まだ導入したばかりであるので、テストケースの作成やログイン周りの制御など探りながら整備していく必要があるものの、E2Eのデメリットである実行時間やアプリならではの最新の変更に対するテスト実行の難しさなどは解決することができました。

ハローでは一緒に働く仲間を募集しています。少しでも気になる方は気軽にお問い合わせください!

ウェブとReact Nativeアプリのコード共通化による同時展開

javascripterです。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。今回の記事では、AutoReserveでおこなっているコード共通化の取り組みについて紹介します。

背景

AutoReserveのネイティブアプリはReact Nativeで書かれており、またウェブ版は、Reactで書かれています。

ウェブ版では、React Native for Webという、React上でReact NativeのコンポネントのAPIを使えるようにするライブラリを使用しています。

React Native for Webを採用したことで、ハローでは現在、エンジニア1人でiOS、Android、ウェブの全てのプラットフォームに同時展開できるようになりました。 また、不具合修正やデザインの修正も、一箇所を修正するだけで同時にできるようになりました。それぞれのプラットフォームでの実装・デザインの乖離が起こりづらいこともメンテナンス性の向上に繋がっています。

今回の記事では、AutoReserveでどのようにアプリとウェブのコードの共通化をおこなっているか説明します。

何を共通化しているのか

以前の記事(なぜNext.jsをやめたのか?)でも軽く紹介していますが、アプリの機能実装を含む、下記のコードを共通化しています。

  • ボタン、チェックボックスなどのUIコンポネント
  • アプリケーション画面のコード
    • レストランの画面
    • 予約の表示画面
    • レストランの予約フォーム画面
  • eslint、prettier、TypeScriptの設定ファイル
  • TypeScriptの型
    • Protocol Buffersで自動生成したAPIの型
  • 定数
    • 色などのテーマの定義 - レスポンシブデザインのbreakpointの幅定義
    • 税率など定数
  • モジュール
    • usePrevious / useStable / useMediaQueryなどよく使うhooks
    • アプリ・ウェブで共通して使えるalert関数の実装

これらのコードを、@hello-ai/ar_sharedという名前でパッケージ化して社内で利用しています。

現在、フロントエンドはmonorepo化を進めており、一部アプリを除き、共通ライブラリの変更とアプリケーションコードの変更をまとめて行えるようになっています。

まだmonorepo化できていないリポジトリに関しては、

  • 共通コードに変更があった場合、GitHub Packagesにnpmパッケージを自動でpublishする
  • 各リポジトリの@hello-ai/ar_sharedの依存関係のバージョンを自動であげる

というGitHub Actionsのアクションを書き、対処しています。パッケージをまたぐ変更が行いやすくなるよう、いずれ全てmonorepoに集約される予定です。

再利用可能なUIライブラリの共通化

まず、再利用可能なUIコンポネント集・hooksなどのモジュールを用意しています。

  • フォーム関連のコンポネント
  • グリッドレイアウトのコンポネント
  • チェックボックス
  • テキスト入力のコンポネント

などです。UIライブラリはドキュメントとしてstorybookを用意しています。

AutoReserveのUIコンポネント集のstorybook

UIコンポネント集を作成する取り組みはよく見かけますが、AutoReserveではさらに一歩進んで、アプリケーションコード自体も共通化しています。

アプリケーションコードの共通化

アプリケーションコードを共通化するには、アプリとウェブのスクロールの仕組みの違いや、ナビゲーションの構造の違いなどを吸収する必要があり、工夫が必要です。この章では、 アプリケーション画面のコードを共通化する方法を紹介します。

先行の取り組みとして、solitoというNext.jsとReact Nativeでの実装の共通化を行うライブラリがあり、一部参考にしていますが、AutoReserveではReact Routerを使っているため、内部で新規ライブラリを実装しています。

共通化しているもの

現在、アプリ、ウェブの両方で共通化しているアプリケーションコードは下記です。

  • アプリケーションの機能画面全体
  • リンク、画面遷移のコード
AutoReserveウェブサイトのレストラン画面
AutoReserve Androidアプリのレストラン画面

ナビゲーションの共通化の仕組み

アプリ、ウェブで使用しているライブラリはそれぞれ異なり

を使用しています。

アプリとウェブの主な構造の違いとして、通常、アプリはhooksを使い現在のスタックに対して画面をpushするという操作を行うのに対して、ウェブはURLによるリンクで遷移するということが挙げられます。

アプリ:

import { useNavigation } from '@react-navigation/native'

function Component() {
  const navigation = useNavigation()
  const onPress = () => {
    navigation.navigate('Restaurant', { restaurantId: restaurantId })
  }
  return <Button onPress={onPress}>レストラン</Button>
}

ウェブ:

import { Link } from 'react-router-dom'

function Component() {
  return <Link href={'/restaurants/xxxx'}>レストラン</Link>
}

ウェブでは、SEOやアクセシビリティの観点から、onClickによる遷移ではなく、必ず<a>要素としてレンダリングされるようにしたい、という要件があります。

これらの遷移の仕組みの違いを吸収するため、AutoReserveでは下記のような仕組みを採用しています。

  • ウェブでは、通常のリンクとなるようurlを指定して遷移
  • アプリではhooksを使用するが、遷移先の指定はdeep linkで行う

共通UIライブラリ側:

import { Platform, Linking, Text } from 'react-native'

const prefix = 'autoreserve://autoreserve'

export function useLinkTo() { // アプリでdeep linkによる遷移を行うhooks
  if (Platform.OS === 'web') {
    return () => {
      throw new Error('useLinkTo is not implemented for web. You should only use it in native.')
    }
  } else {
    return (to) => Linking.openURL(prefix + to)
  }
}

// ウェブではtoでリンク先を指定、アプリではonPressが作動するコンポネント
export function LinkText({ to, onPress, ...rest }) {
  return <Text
    href={to} // webではhrefを指定しリンク化
    onPress={
      Platform.select({
        web: () => React_Router_navigate(to), // React Routerによる遷移
        default: onPress // アプリでは通常のonPressを指定
      })
    }
  />
}

アプリケーションコードでの使用例

function Component() { // 使用例:
  const linkTo = useLinkTo()

  return <LinkText
    to="/restaurants/slug" // toを指定するとウェブでのみリンクになる(アプリでは無視)
    onPress={() => { // onPressはアプリでのみ実行される
      linkTo('/restaurants/1234')
    }}>
    レストランへのリンク
  </LinkText>
}

まとめると、ウェブではリンク、アプリではonPressのイベントハンドラーを渡し、deep linkによる遷移をおこなっているという形になります。

アプリ側ではdeep linkのpathを渡すのではなくonPressを渡すよう実装にした理由は、アプリとウェブでURLのpathnameの構造が一致しておらず、またアプリでは現状deep linkで表現できない遷移がまだあり、JSコードを間に挟めるようescape hatchを用意したかったためです。

スクロール周りの挙動の違いの吸収

また、アプリとウェブで挙動が大きく異なる部分として、スクロール周りがあります。

  • React Nativeのアプリでは<ScrollView>というコンポネントを使用すると任意の箇所を スクロール可能にできる
  • ウェブの場合、ページのスクロールは通常<body>要素によって行われる

例えば、ウェブでbodyの内側のdivoverflow-y: autoを当てメインのスクロール要素にすると、モバイルでURLバーが自動で隠れなくなるなどUX上の問題があるため、基本的には必ずbodyでスクロールを発生させる必要があります。

これらの問題に対処するため、アプリケーションコードの共通化を行う際は、スクロール要素そのものはコンポネントに含めず、内部のコンテンツのみをコンポネント化しています。

共通化部分:

function RestaurantContent(props: RestaurantContentProps) {
  return <View>
    {
      /* レストランページの中身 */
    }
  </View>
}

アプリ:

import { RestaurantContent } from '@hello-ai/ar_shared/...'

function RestaurantScreen() {

  return <View style={{ flex:1 }}>
    <Header /> // ヘッダは上部固定
    <ScrollView style={{ flex: 1 }}>
      <RestaurantContent .../> // レストラン画面の中身だけをスクロール可能に
  </ScrollView>
  </View>
}

ウェブ:

import { RestaurantContent } from '@hello-ai/ar_shared/...'

function RestaurantPage() {
  return <body>
    <Header style={{
      // body全体をスクロール可能にしているためposition: fixedでレイアウト
      position: 'fixed',
      top: 0,
      left:0,
      right: 0
    }}/>
    <View style={{
      marginTop: headerHeight
    }}>
      // レストラン画面の中身はbody内にそのまま広げ
      // bodyでスクロール可能に
      <RestaurantContent .../>
    </View>
  </body>
}

ページ/画面のコンポネント自体はアプリ/ウェブで別に実装し、そこからの共通コンポネント実装を呼び出すようにしています。この方法には

  • ウェブ/アプリで最適なUI構造となるよう構造を変えられる
  • アプリ/ウェブ側から共通ライブラリ側にpropsを渡せるので、プラットフォームの差異がある場合も共通ライブラリ内で分岐せずに済む

といったメリットがあります。

今後の課題

コード共通化の仕組みは途中で導入したため、まだ共通化ができていない箇所がいくつかあります。現時点での課題として

  • ウェブとアプリで、URLパスとdeep linkの構造が一致していないため、リンク先を複数記述する必要がある
  • データ取得のコードをアプリ・ウェブで共通化できていない

があります。

まとめ

React Native for Webを使用し、少人数でiOS, Android, ウェブの全プラットフォームに同時展開できるコード共通化基盤を構築しているという事例を紹介しました。

ハローでは、生産性を追求し、積極的に技術的な挑戦に取り組める本物のエンジニアを募集しています。

少しでも気になる方は気軽に javascripter にDMでお声がけください!

エンジニア採用情報 | Hello, Inc.

電話音声の自動機械判定モデルとサービス活用

はじめまして、Xです!私は普段アメリカのカーネギーメロン大学に在学していて、機械学習関連の研究をしています。ハローでは主に音声と関係する機械学習の開発をしています。

この記事では、AutoReserveの中で機械学習を使っている自動機械判定というコンポーネントについて紹介します。

自動機械判定とは

ご存知の方も多いと思いますが、電話をかけるときに相手が電話に出られないときは留守番につながることがよくあります。その際に自動音声が流れることがよくあります。AutoReserveのサービスでも、自動音声で予約する際によく店側の電話の自動音声につながることが多くあります。そのときに店側に予約を取ることが難しいため、再び時間をおいてから自動音声をかけ直す必要があります。そのため、電話をかけた際に店側が自動音声で出ているのか、店員が実際に出ているのかを知りたいことがたくさんあります。自動機械判定はこれを分類する機械学習のモデルを指します。

先行研究

意外かもしれませんが、音声合成をする研究はかなりメジャーな研究分野である一方で、自動で機械音声かどうかを判別する研究は多くありません。その原因は色々考えられますが、主な原因はこの判定タスクの定義自体がかなり曖昧で、具体的なシナリオによっては難易度が大きく変わるからだと思います。

たとえば、オーディオブックをアナウンサーが読んだ音声と機械が読んだ音声を区別するシナリオであれば、このタスクはかなり難しいと思います。その理由はそもそも音声合成は人間の声を忠実に再現することを目指しているため、よいモデルであればあるほど区別することが難しいです。一例として、発音の韻律を考慮した最近のこの研究では、人間の主観でも機械かどうかを統計的に有意に判定することが難しいです。一方で、私達は店側に電話をかけたときに留守番の自動音声かどうかを判定するシナリオについてですが、幸いこのタスクはかなり簡単な部類に入ります。

機械学習モデル

まずどんなタスクであってもある程度データを集める必要があります。このタスクは前述のようにあまり研究がなされていないもので、既存のデータはありません。そのために私達自身で、AutoReserveのサービスで集めた音声のうち、ランダムに数百個のサンプルを選んで自動かどうかを手でラベリングしました。

次に実際にどうモデリングできるかを考えてみましょう。このタスクは二値分類の問題で、入力された音声に対して、自動音声かどうかを判定します。ここ10年の音声技術分野ではさまざまな深層学習の手法が開発されていますが、どれもある程度の規模なデータセット(数百時間レベル)を想定しているが、われわれのデータセットは数時間程度しかありませんので、大半の深層学習の手法は使えません。最近流行りのself-supervised learningの深層学習の手法では、データセットは小規模で良いケースもありますが、モデルが大きいため、デプロイする際のコスト問題が発生します。

そこで、私達は深層学習ではなく、もっとシンプルな線形モデル(ロジスティック回帰)を使いました。古典的な線形モデルはシンプルでデータ量が比較的に必要としないかわりに、特徴量の選択が重要になってきます。私達は色々な特徴量をつくって実験してみましたが、そのうちから、重要かつ面白い特徴量を3つ取り上げて紹介します。

  • Callee Overlap Feature
  • Noise Feature
  • Duration Feature

Callee Overlap Feature

自動留守番の機械音声の場合、相手を無視して音声が流れます。一方で私たちも自動で予約音声を話しているため、電話の両方で自動音声が同時に流れます。この状況は実際に人が電話に出ている場合では、なかなか起きません、っていうのはこちらの音声を聞いている間はとくになにも話さないことが多いからです。そのため、通話時間のうち、どれだけ音声がかぶっているかを調べることで、相手が機械かどうかのヒントを与えてくれます。私達の実験では、この特徴量だけでもかなりの精度(75%)を達成することができました。

Noise Feature

音声生成に詳しい方なら知っているかもしれませんが、生成された音声は基本的にノイズが少なく、かなりきれいな声で話されています。これは音声のスペクトル図を見てもはっきりわかります。そのため留守番の機械音声ですと、ノイズがほとんど乗りません。一方で店側で人が出ている場合は、店側の環境音がかなり混じっていることが多く、ノイズが多く乗ります。そのため、店側の音声にノイズがどれだけ混じっているかを調べることで、機械音声かどうかがわかるケースも多くあります。

Duration Feature

通話時間の長さからもかなり多くのことがわかります。留守番電話のケースですと、いくつかの決まった留守音声のテンプレートがあって、そのテンプレートが流れ終わると自動的にその秒数で電話が切られるか、あるいはその後ずっとこちらの留守メッセージを聞き続けて、タイムアウトがくるまでにずっと通話するかのパターンが多いです。そのため留守番の通話時間は特徴的な秒数をとっていることが多くあります。この特徴的な秒数をとっているかどうかを調べること(たとえば混合ガウスモデル)で、機械音声かどうかがわかります。

これらの特徴量に加えて、いくつかほかの典型的な特徴量(MFCC特徴量やクラスタリング特徴量など)を組み込んで線形モデルをつくりました。機械学習のライブラリは最近はやりのpytorchではなく、scikit-learnを採用しています。音声の特徴量抽出はpython_speech_featuresというライブラリを使っています。callee overlapの有無はpy-webrtcvadというモデルを改造して判別しています。すべての実装はnumpyベースであるため、軽量に動かすことができます。

下がおおよそのメインクラスの実装になります。モデルを予め訓練してpickle形式に保存しておき、デプロイ時はそれをロードして使います。毎回新しいリクエストに対して判別を行うときに、まず上にあげた特徴量などを計算しておき、線形モデルに入れて判別します。

class AutomaticMachineDetection:

    def __init__(self):

        # sklearnのロジスティック回帰を使います
        self.model = LogisticRegression(C=100)

        # 音声から典型的なMFCC特徴量を抽出するモデルを準備します
        self.pm = create_pm_model("mfcc_hires")

        # クラスタリング特徴量
        self.cluster = BowCluster(100)

    def feature(self, audio):
        """
        音声から特徴量を抽出します。

        :param audio:
        :return:
        """

        # クラスタリング特徴量など
        cluster_feat = self.get_cluster_feature(audio)

        # 上のcallee overlapの特徴量など
        stat_feat = self.get_stats_feature(audio)

        feat = np.concatenate([cluster_feat, stat_feat])

        return feat

    def predict(self, audio_or_wav_path):

        # only use the first channel which is corresponding to the callee audio (The caller side is ignored for now)
        if isinstance(audio_or_wav_path, str) or isinstance(audio_or_wav_path, Path):
            audio = read_wav(audio_or_wav_path, channel=0)
        else:
            audio = audio_or_wav_path

        # 特徴量抽出
        feat = self.feature(audio)

        # 推論
        return self.model.predict([feat])[0]

さまざまなパラメーターや特徴量をチューニングして実験した結果、98%ぐらいの精度を達成することができました。

このタスクのように、機械学習モデルは必ずしも深層学習を使う必要がなく、簡単なモデルで物足りるケースも多々あります。実際に深層学習を使おうとすると、大量のデータを集める必要があるのに加えて、訓練やデプロイする際に多くの計算資源を必要とします。しかし、この簡単なモデルは個人のノートPCで数分程度で訓練することができて、簡単に開発することができます。ただ、シンプルなモデルの性能を最大限に引き出すために、特徴量を注意深く作る必要があります。

まとめ

今回のモデルは線形モデルであるため非常に軽量なインスタンスで動かすことができて、最終的にこのモデルをFlask に乗せて Google Cloud Functions のサーバーレス環境にデプロイしています。自動音声予約の数は増え続けていますが、ほぼメンテなしで安定してスケールしています。ハローの電話料金コストを削減するのに役立っています。

ハローではこのように音声に関する知見を深めて、フロントエンド、バックエンドの開発にとどまらず、これからも音声の機械学習分野で技術開発を続けていきます。