静的解析で実現した効率的なi18n対応の仕組みづくり

Slide 1

Slide 1 text

Slide 2

Slide 2 text

⽬次 Agenda ● ⾃⼰紹介と会社紹介 ● ESLintを静的解析に置き換えたら実⾏時間が5 分の1に短縮された話 ● 静的解析を活⽤して、⾮エンジニアでもUI チェックを可能にした話 ● i18nを導⼊しても開発効率を損なわない仕組みを構築した話 ● 業界⽤語を学習させたGPTベース機械翻訳をスプレッドシートに組み込んだ話

Slide 3

Slide 3 text

⾃⼰紹介‧会社紹介

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© LayerX Inc.　 5 会社概要会社名株式会社LayerX（レイヤーエックス）代表取締役代表取締役CEO 福島良典代表取締役CTO 松本勇気創業 2018年 8⽉1⽇資本⾦約132.6億円拠点東京本社〒104-0045 東京都中央区築地1-13-1 銀座松⽵スクエア 5階関⻄⽀社〒530-0003 ⼤阪市北区堂島1-1-5 関電不動産梅⽥新道ビル B2F WORKING SWITCH ELK 内中部⽀社〒466-0064 愛知県名古屋市昭和区鶴舞1-2-32 STATION Ai内九州⽀社〒810-0801 福岡県福岡市博多区中洲3-7-24 WeWorkゲイツ福岡 11F 内従業員数 325名（2024年5⽉末時点）関連会社三井物産デジタル‧アセットマネジメント株式会社三井物産、LayerX、三井住友信託銀⾏、SMBC⽇興証券、JA三井リースによる合弁会社株主⼀覧

Slide 6

Slide 6 text

© LayerX Inc.　 6 事業概要「すべての経済活動を、デジタル化する。」をミッションに掲げ、法⼈⽀出管理サービス「バクラク」や企業内業務のデジタル化を⽀援するサービスを提供しています。バクラク事業企業活動のインフラとなる法⼈⽀出管理（BSM）SaaSを開発‧提供 Fintech事業ソフトウェアを駆使したアセットマネジメント‧証券事業を合弁会社にて展開 AI・LLM事業⽂書処理を中⼼とした、LLMの活⽤によるプロセスのリデザイン取得認証 ※IS747702 / ISO27001 は三井物産デジタル‧アセット‧マネジメント事業部以外の組織で認証取得

Slide 7

Slide 7 text

© LayerX Inc.　 7 「バクラク」シリーズラインナップ ‧AIが請求書を５秒でデータ化 ‧仕訳 / 振込データを⾃動作成 ‧電帳法‧インボイス制度にも対応仕訳‧⽀払処理効率化 ‧年会費無料で何枚でも発⾏可 ‧カード利⽤制限で統制を実現 ‧すべての決済で1%以上の還元法⼈カードの発⾏‧管理 ‧帳票の⼀括作成も個別作成も⾃由⾃在 ‧帳票の作成‧稟議‧送付‧保存を⼀本化 ‧レイアウトや項⽬のカスタマイズも可能請求書発⾏ ‧スキャナ保存データも直接取込 ‧AI-OCRが⾃動読取＆データ化 ‧[取引先][取引⽇][取引⾦額]での検索帳票保存‧ストレージ ‧AIが⾒積書‧請求書を５秒でデータ ‧スマホからも申請‧承認OK ‧柔軟な通知設定‧承認の催促機能稟議‧⽀払申請 ‧直感的UIで従業員の負担を軽減 ‧Slack連携で打刻や⾃動リマインド可能 ‧わかりやすい残業 / 休暇管理レポート勤怠管理 ‧AIが領収書を5秒でデータ化 ‧スマホアプリとSlack連携あり ‧領収書の重複申請などミス防⽌機能経費精算

Slide 8

Slide 8 text

ESLintを静的解析に置き換えたら実⾏時間が5分の1に短縮された話

Slide 9

Slide 9 text

© LayerX Inc. 9 ESLintを静的解析に置き換えたら実⾏時間が5分の1に短縮された話 ● 要件 ○ 特定ページに限定してi18n対応を⾏う ● 起こったこと ○ 複雑な画⾯において、条件分岐や依存関係を網羅し全てのコードベースで漏れなくi18n対応を⾏うことが難しかった ○ 依存関係のあるコードベースにのみ翻訳漏れ検証を⾏う必要がある為、全コードベースを検証する既存のESLintを適⽤できなかった ● 対策 ○ 指定されたページのVueコンポーネントファイル及びその依存関係にある「コンポーネント」 ‧「関数」‧「変数」を再帰的に分析し、翻訳関数によって囲まれていない⽇本語リソースを特定するカスタムESLintの実装を⾏った i18n導⼊時に直⾯した課題と対策

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© LayerX Inc. 11 ● 指定されたページから参照されるコードに限定して翻訳漏れがないことを検出するカスタムESLint ルールを実装する ○ 翻訳漏れはt関数で囲われているかで検証 ○ 参照されるコードはコンポーネント‧関数‧変数に限定して、再帰して末端まで検証 ● i18n対応は指定されたページに限定したいので、翻訳すべきコードをページ起点で検索するカスタムESLintの要件 TSKaigi 2024 After Talk より

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© LayerX Inc. 14 ● ts-nodeで実⾏可能なmtsファイルにスクリプトを⽤意し、カスタムESLintを実⾏する ○ 再帰により別ファイルへのアクセスが発⽣するが、デフォルトの出⼒だと元のファイルに対してのエラーとして出⼒されてしまうので、どのファイルに対するエラーなのかが分かるように出⼒結果をカスタマイズする為に、スクリプトを⽤意しました ○ コマンドラインの出⼒結果は「chalk」で⾊をつけてます mtsで⽤意したスクリプトからESLintを実⾏ TSKaigi 2024 After Talk より

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© LayerX Inc. 16 【２】 importがある場合の処理 a. vueファイルのimportがあれば、vueファイルの検証に再帰させる b. tsファイルのimportがあれば、そのtsファイルをASTに変換し、importされている処理を抽出してscriptの検証に再帰させる指定されたページから参照されるコードを再帰的に検索し、翻訳漏れを検知 TSKaigi 2024 After Talk より

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© LayerX Inc. 18 以上がTSKaigi 2024 After Talkにてお話した内容になります。 ● できたこと ○ 翻訳漏れを機械的に検知できるようになった ● 発⽣した問題 ○ PR時にCIで翻訳漏れの検証を実⾏するように設定しましたが、処理時間が⻑く、開発者に負担が発⽣。 ■ Github Actions上 → 約10分 ■ local環境 → 約5分カスタムESLintを実装したその後 ESLintを静的解析に置き換えたら実⾏時間が5分の1に短縮された話

Slide 19

Slide 19 text

© LayerX Inc. 19 ● 重複解析の発⽣ ○ ESLintは起点ファイルごとに解析を⾏うため、複数のファイルで共通のコンポーネントを参照している場合、それぞれの起点ファイルから同じ依存ファイルが再解析されてしまう。 ○ プロジェクトが⼤規模になるほど依存ファイルの重複解析が増加し、実⾏時間が⼤幅に⻑くなる原因となっていた。 ● 訪問済みファイルの管理限界 ○ ESLintでは、起点ファイルごとにスクリプトが実⾏される為、独⽴した訪問済みファイルリストを使⽤しており、共通の依存ファイルでも各起点ファイルから個別に解析が⾏われる。 ○ この仕組みにより、同じファイルが何度も解析され、全体の処理時間が増⼤する要因となっていた。 ESLintでの課題 ESLintを静的解析に置き換えたら実⾏時間が5分の1に短縮された話

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© LayerX Inc. 21 ● ESLintは翻訳漏れ検出には不要なScope Analysisを実⾏するため、処理時間が増⼤していた。 ● 静的解析スクリプトではScope Analysisを省略し、必要な処理にのみ集中することで効率化を実現。 ● ESLintではテンプレートとスクリプトを別々に解析するため、静的解析スクリプトにより統合解析が可能になり、効率的な解析が可能になりました。 ESLintの汎⽤性によるオーバーヘッド ESLintを静的解析に置き換えたら実⾏時間が5分の1に短縮された話

Slide 22

Slide 22 text

© LayerX Inc. 22 ● 時間短縮の成果 ○ ESLint使⽤時：約255秒 → 静的解析スクリプト使⽤時：約54秒（約80%の時間短縮） ○ 重複解析の解消と訪問済み管理のグローバル化により、⼤規模プロジェクトでも再解析を避け、実⾏時間を⼤幅に削減しました。 ● 開発体験の向上 ○ CIやローカルでの検証が迅速化され、開発者がより早くフィードバックを得られる環境が整いました。これにより、デプロイフローが改善され、開発者の負担が軽減しました。実際の効果 ESLintを静的解析に置き換えたら実⾏時間が5分の1に短縮された話

Slide 23

Slide 23 text

© LayerX Inc. 23 ● データ管理の⼯夫によるパフォーマンス向上 ○ 再帰的な解析では、訪問済みファイルの管理と重複排除の⼯夫が⾮常に⼤きな効果を発揮しました。 ○ Scope Analysisなど省略することで、特定⽤途に不要な処理を削減し、静的解析を効率的に実⾏できました。 ● ⽤途特化型スクリプトの強み ○ 汎⽤的なツールよりも特化型スクリプトが特定解析に適しており、プロジェクトのニーズに合わせた効率的な解析が可能となりました。学びと応⽤ ESLintを静的解析に置き換えたら実⾏時間が5分の1に短縮された話

Slide 24

Slide 24 text

静的解析を活⽤して、⾮エンジニアでもUIチェックを可能にした話

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© LayerX Inc. 27 1. 指定されたページから再帰的にコードを辿り、翻訳関数で使われるキーを検出 2. csvファイルに、キーに対して呼び出されている「コンポーネント」と「⼤元のページパス」を保存 3. スプレッドシートとの接続を担っているツールを介して、csvファイルの内容をシートに転記 4. 翻訳辞書シートにキーで突合してページパスからURLを⽣成して表⽰全体のアーキテクチャ静的解析を活⽤して、⾮エンジニアでもUIチェックを可能にした話

Slide 28

Slide 28 text

© LayerX Inc. 28 ● 詳細 ○ 指定されたページから参照されるコードを、末端まで再帰的にアクセスし翻訳関数から呼び出されているキーを検出 ○ csvファイルに、キーに対して呼び出されている「コンポーネント」と「⼤元のページパス」を保存 ● ⾒送った⼿法 ○ 全てのソースコードを検証にかけて、検出されたキーから再帰的に⼤元のページパスを辿る⽅法もあったがコスパ悪いので前項で紹介した指定されたページに依存関係のある処理を検証するスクリプトのアルゴリズムを流⽤しページ起点で検証を⾏った指定されたページから再帰的にコードを辿りキーを検出静的解析を活⽤して、⾮エンジニアでもUIチェックを可能にした話

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

i18nを導⼊しても開発効率を損なわない仕組みを構築した話

Slide 33

Slide 33 text

© LayerX Inc. 33 ここからは余談的なお話になります。i18n対応を実装するにあたって以下のような課題が存在していました。それぞれをどのように改善したかお話させてください。 ● 翻訳関数で存在しないキーや誤ったキーを指定できてしまう。 ● Vueの複数APIスタイルの影響で、翻訳関数の使⽤が統⼀されず、ばらつきが発⽣。 ● 翻訳キーにHTMLタグを含む場合のサニタイズ漏れリスク。 ● 記号を含む⽂⾔のキーの切り出し⽅が実装者によって異なる。 i18n導⼊時の課題 i18nを導⼊しても開発効率を損なわない仕組みを構築した話

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

© LayerX Inc. 37 ● 私たちは翻訳作業をスプレッドシート上で⾮同期で進めていて、それをスクリプトでロードしながらプロダクトに適⽤しています 1. スプレッドシートで定義されているkeyが、t関数のキーの型として当たること 2. スプレッドシートで定義されている翻訳情報に含まれる変数が、t関数の変数の型として当たること 3. 型が当たることにより予測補完が効き開発体験が保証されること要件 TSKaigi 2024 After Talk より

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© LayerX Inc. 41 ● TypeScriptでは、ライブラリの型定義に何かを追加はできても削除はできず、t関数を真に型安全にすることが難しかったです ● そのためpnpmに搭載されているpatchコマンドを使⽤してパッチを当てることで対応しました ○ t関数に関する型定義のコメントアウトを⾏いました ○ pnpm patchはパッケージのコードに対するローカルな変更を容易に⾏える機能です（便利！） patchファイルで元のt関数の定義を削除 TSKaigi 2024 After Talk より

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

© LayerX Inc. 44 以上がTSKaigi 2024 After Talkにてお話した内容になります。翻訳関数のキー指定ミスを防ぐため、型定義を活⽤した厳密なチェックを導⼊することで、誤ったキーの使⽤リスクを無くすことに成功しました。これにより、翻訳精度の向上と効率的な開発環境を実現しています。翻訳関数のキーに誤った値を指定できてしまう課題 i18nを導⼊しても開発効率を損なわない仕組みを構築した話

Slide 45

Slide 45 text

© LayerX Inc. 45 i18nを複数⼈で運⽤するにあたり、ルールが存在していても、実装時に思い出す⼿間や、気づかずに異なる実装をしてしまう可能性がありました。 ● Vueには複数のAPIスタイルがあり、翻訳関数の呼び出し⽅法が実装者によってばらつく。 ● 記号を含む⽂⾔のキーの切り出し⽅が、実装者によって異なってしまう。 ● 翻訳情報にHTMLタグを含む場合、パース処理を忘れてしまうリスクがある。そこで、これらの課題に対してカスタムESLintを導⼊し、実装者が意識せずとも機械的にルールが適⽤される仕組みを整備しました。実装者によるばらつきの発⽣ i18nを導⼊しても開発効率を損なわない仕組みを構築した話

Slide 46

Slide 46 text

© LayerX Inc. 46 ● 環境 ○ Vue.js ■ OptionsAPIとCompositionAPIとScriptSetupが混在している ○ @nuxt/i18n ■ 呼び出せる関数は t() と $t() ● ルール ○ OptionsAPIでは $t() を使⽤すること ○ CompositionAPIとScriptSetupでは t() を使⽤すること翻訳関数のばらつきを防ぐルールの実装 i18nを導⼊しても開発効率を損なわない仕組みを構築した話

Slide 47

Slide 47 text

© LayerX Inc. 47 ● templateタグ内に対する検証 ○ を使っている場合、テンプレート内では"t"関数の使⽤を期待 ○ <script setup>を使っていない場合（Options APIやComposition APIのsetup関数外）、テンプレート内では"$t"関数の使⽤を期待 ○ 指定された関数と異なる関数が使⽤されている場合、エラーとして報告 ● scriptタグ内に対する検証 ○ <script setup>内であれば"t"関数の使⽤を期待 ○ Composition APIのsetup関数内でも、同様に"t"関数の使⽤を期待 ○ それ以外の場所では、"$t"関数の使⽤を期待します。 ○ 間違った関数が使⽤されている場合、エラーとして報告翻訳関数のばらつきを防ぐルールの実装 i18nを導⼊しても開発効率を損なわない仕組みを構築した話

Slide 48

Slide 48 text

Slide 49

Slide 49 text

© LayerX Inc. 49 ● （）で囲まれている⽂⾔ ● ：で終わる⽂⾔ ● ‧で始まる⽂⾔上記のようなパターンでi18nのキーに記号が含まれる場合、⽂⾔の⼆重管理を防ぐために記号をキーに含めない⽅針としました。しかし、このルールを実装者が毎回意識するのは難しいため、カスタムESLintで⾃動的にルールが適⽤される仕組みを整備しました。記号の⼀貫した取扱いルールの実装 i18nを導⼊しても開発効率を損なわない仕組みを構築した話

Slide 50

Slide 50 text

© LayerX Inc. 50 ● キーが先頭に「‧」を含む場合の検証 ○ i18nキーが「‧」で始まる場合、そのキーの⻑さが1⽂字以上であればエラーとして報告 ○ メッセージとして「「‧」は単独のキーとして使⽤してください」というエラーメッセージを表⽰ ● キーが末尾に「：」を含む場合の検証 ○ i18nキーが「：」で終わる場合、そのキーの⻑さが1⽂字以上であればエラーとして報告 ○ メッセージとして「「：」は単独のキーとして使⽤してください」というエラーメッセージを表⽰ ● キーが「（」で始まり「）」で終わる場合の検証 ○ i18nキーが「（」で始まり「）」で終わり、かつ2⽂字以上である場合、エラーとして報告 ○ メッセージとして「「（」と「）」は単独のキーとして使⽤してください」というエラーメッセージを表⽰記号の⼀貫した取扱いルールの実装 i18nを導⼊しても開発効率を損なわない仕組みを構築した話

Slide 51

Slide 51 text

© LayerX Inc. 51 翻訳キーにHTMLタグが含まれる場合、不適切なサニタイズが⾏われていないと、セキュリティリスクや表⽰崩れの原因となります。これを防ぐため、以下のルールを定めました。 ● HTMLタグを含む翻訳キーには、必ず$sanitizeでサニタイズする ● サニタイズ済みの翻訳キーは、v-htmlとともに使⽤するこのルールを⼿動で覚えるのは困難なため、カスタムESLintルールで⾃動チェックを⾏い、機械的にルールを守れるようにしました。 HTMLタグを含む翻訳キーの安全性検証の実装 i18nを導⼊しても開発効率を損なわない仕組みを構築した話

Slide 52

Slide 52 text

© LayerX Inc. 52 ● キーの取得と検証 ○ t関数が呼ばれている場合、その最初の引数がリテラル⽂字列（翻訳キー）であるかを確認 ○ 翻訳キーがリテラル⽂字列であれば、そのキーを使って対応する翻訳値（⽂字列）をi18n ファイルから取得 ● HTMLタグの存在確認 ○ 翻訳値の⽂字列にHTMLタグが含まれているかを判定します。具体的には、正規表現を⽤いて、<や>で囲まれたタグ形式の⽂字列が存在するかをチェック ○ もしHTMLタグが含まれている場合、その翻訳値にはHTMLが含まれていると判断され、サニタイズとv-htmlチェックを⾏う HTMLタグを含む翻訳キーの安全性検証の実装 i18nを導⼊しても開発効率を損なわない仕組みを構築した話

Slide 53

Slide 53 text

© LayerX Inc. 53 ● PR作成時 ○ i18n-check-untranslated ■ 翻訳漏れがないか検証します ○ analyze-i18n-keys ■ 各キーに対する使⽤箇所に変更があるかチェックします ○ （ESLint, TypeCheck） ■ 存在しないキーを呼び出していないか検証します ■ 適切なt関数を使⽤しているか検証します ■ 記号を含むキーを適切に定義できているか検証します ■ 翻訳情報にHTMLタグを含むキーが適切に処理されているか検証しますこれまで登場した仕組みのCIへの導⼊ i18nを導⼊しても開発効率を損なわない仕組みを構築した話

Slide 54

Slide 54 text

Slide 55

Slide 55 text

業界⽤語を学習させたGPTベース機械翻訳をスプレッドシートに組み込んだ話

Slide 56

Slide 56 text

© LayerX Inc. 56 先ほどのお話の中で翻訳を社内外で実施しているというお話をさせていただきました。しかし、開発現場では以下のような課題がありました。 ● 実装を開始する前に翻訳の依頼を出し、その対応を待つ必要があるため、開発スピードが低下してしまう。 ● ドメイン特有の⽤語が多く、⼀般的な翻訳サービスでは⼗分に対応できない。翻訳依頼フローの課題とドメイン⽤語対応の必要性業界⽤語を学習させたGPTベース機械翻訳をスプレッドシートに組み込んだ話

Slide 57

Slide 57 text

Slide 58

Slide 58 text

© LayerX Inc. 58 1. ローカル環境でTypeScriptを使⽤して翻訳スクリプトを実装。業界⽤語は実⾏時にスプレッドシートから読み込み 2. Babelを⽤いてJavaScriptに変換 3. Claspを使⽤しGASへデプロイ 4. スプレッドシートから機械翻訳処理の呼び出し 5. 翻訳結果をスプレッドシートへ書き込み全体のアーキテクチャ業界⽤語を学習させたGPTベース機械翻訳をスプレッドシートに組み込んだ話

Slide 59

Slide 59 text

Slide 60

Slide 60 text

© LayerX Inc. 60 ● Babelを⽤いてTypeScriptを実⾏可能なJavaScriptに変換 ● Claspを⽤いてGAS（ Google Apps Script ）にデプロイ ● Clasp（ Command Line Apps Script ）とは ○ Claspは、GAS プロジェクトをローカル環境で管理し、コードを同期‧デプロイするためのCLIツールです ○ ローカルで作成‧管理したコードをGAS にデプロイして実⾏可能な状態に ○ GASのスクリプト管理やバージョン管理を効率化 GASへのデプロイ業界⽤語を学習させたGPTベース機械翻訳をスプレッドシートに組み込んだ話

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

終わりに

Slide 66

Slide 66 text

© LayerX Inc. 66 We are hiring! LayerX Open Door アカウント登録が一切不要なカジュアル面談を公開しています。・私と雑談してみたい・質問したいことがある・選考に進むか悩んでいるなどなど、お気軽にお申し込みください。公開中の募集ポジションをはじめ、LayerXの各事業部の紹介、社員インタビュー、Podcastなどのリンク集をまとめています。コンテンツも充実しているので転職タイミングじゃなくてもWebサイトに訪問いただけると嬉しいです！ LayerX 採用情報 LayerX 採用情報