こんにちは。Legalscape Co-Founder & CTOの城戸（きど）です。この記事はLegalscape アドベントカレンダー 2021の2日目のエントリです。

今日は私たちの主力プロダクトである「Legalscape」を支える技術スタックについて簡単に説明し、なぜそれを選んだのかを語ることで、これを読んでいるあなたに私たちのチームについて理解を深めていただきたいと思います。

Legalscapeって、何？

Legalscapeは、法務に携わる方々が使うリサーチシステムです。どんな製品なのかについては弊社ブログの過去の記事（はじめまして、Legalscapeです）を見ていただきたいのですが、簡単に言うとWebアプリなので、バックエンド、フロントエンドからなり、裏に検索エンジンやデータベースがあります。これらが全てGoogle Cloud Platform (GCP) 上で構築されています。

では、それぞれのコンポーネントについて詳しく見ていきましょう。

バックエンド

LegalscapeのAPIサーバはTypeScriptで書かれています。確かにそこまでメジャーな選択肢ではありませんが、フロントエンドと型定義などを共通化できますし、TypeScriptの型システムは現実の問題を解くのにちょうど良くできていると感じています（ちゃんと書けばですが）。近年ではfrourioなどフロントエンドとバックエンドを融合するフレームワークなども出現していますし、方向性は間違っていないのではないかなと思っています。

併せて、OpenAPIを使ったスキーマファースト開発っぽいことをしています。具体的には、express-openapi-validatorを使ってAPI定義と具体的な実装を繋ぎこみ、リクエストパラメータがスキーマに従っていることを自動的に検証させたり、Jestとajvを組み合わせて使ってAPIレスポンスがOpenAPIドキュメントに定義されたスキーマに従っていることを検証しています。Jestは導入を検討したときから業界的に主流のテスティングフレームワークですし、ユニットテスト初心者でも比較的書きやすいような気がします。

APIサーバは、GCPのGoogle App Engine上で動かしています。デプロイも簡潔ですし使いやすいです。今のLegalscapeの規模だとみんな大好きKubernetesなどを使って問題を複雑に解く必要はないと思います。

全文検索エンジンにはElasticsearchを採用しました。ひたすら試行錯誤を重ねてちょっとずつちょっとずつ最適化されてきていますが、まだまだチューニングの余地があるのだと思います。こういうの好きな人、うちに来てくれないかなー。楽しいと思うんですけど。

フロントエンド

当然、フロントエンドもTypeScriptで書かれています。フロントエンドフレームワークにはNuxt.js (Vue.js) を採用しました。Vueは優れた学習曲線を持つフレームワークだと思います。パフォーマンス的にも遜色ないのではないでしょうか。

通信部分はもともとそんなに多くなかったこともあり直接レポジトリ層からAxiosを呼び出したりしていましたが、前述のOpenAPIによる自動生成されたコードで徐々に置き換えています。

エンジニアの数も少なくコンポーネントの種類も多くはないためそこまで重要視してはいませんが、アイコンやボタンなどの一部の共有コンポーネントはStorybookで管理しています。サーブにはChromaticを利用して、mainブランチが更新されるたびにCIでデプロイがされるようになっています。これまでのコンポーネントの変更が時系列で見ることができて、実際のStorybookとの行き来も自由にできるので、エンジニアでも気軽に使えて全体が把握しやすくなっています。

フロントエンドは、Firebase Hosting上でサーブしています。人手によるデプロイの場合もCDの場合もツールがきちんと整備されていて楽です。Google Cloud Storageから直接サーブすることも検討したのですが、SPAとの相性の観点でFirebase Hostingに軍配が上がりました。

DWH

DWHとしてBigQueryを利用しています。APIサーバからCloud Loggingを経由してログを取り込んでいます。（取り扱うデータの規模によりますが）低コストでデータウェアハウスを構築できるのはいいですね。こちらについては12/14公開予定の記事で詳しく紹介しようと思いますので、乞うご期待。

その他（開発体験、運用）

先述の通りLegalscapeはGCP上で稼働していますが、VMやLBなど各種リソースをできる限りTerraformのコンフィギュレーションで表現しています。現状のリソース構成がどのようになっているかを把握しやすいですし、変更するときもレビューしやすいです。こちらについても12/9公開予定の記事で詳しく紹介しようと思います。

CI/CDはGitHub Actionsを活用しています。色々なactionsを組み合わせることでワークフローを作れるのが便利です。社内のCI/CD環境はかなり良く整備されていて、stageリリース、canaryリリース、productionリリースなどがストレスなく簡単に自動で行えます。

システムの監視にはGCPのCloud Monitoringを使っています。当たり前ですが、GCPの各種サービスとの相性が良く、監視エージェントなどを導入しなくても勝手にメトリクスを収集できる強みがあります。

終わりに

Legalscapeを支える技術スタックについて、駆け足ではありますが紹介していきました。他にも私たちはこの国の裁判のあり方を変える民事判決のオープンデータ化のプロジェクト（「民事判決のオープンデータ化」とは何で、なぜ必要で、なぜ私たちが関わっているのか）のための実験環境だったり、またLegalscapeに掲載されるデータに対するたくさんの（！）アノテーションツールだったり、色々なシステムを抱えていますが、全部は語りきれません。

この記事を読んで私たちのチームでの開発に興味が湧いた方や、もっと詳しく聞きたい！　という方は、ぜひ採用情報をご覧ください！　カジュアル面談からでも大丈夫ですので、気軽にご連絡いただけるのをお待ちしております。