はてなブックマーク

はじめに こんにちは！LegalOn Technologiesでプロダクトマネージャーを務めている天野です。 CTOオフィスの時武が、先日以下のブログで宣言した通り、私たちはAI駆動開発を取り入れて日々プロダクト開発に取り組んでいます。 tech.legalforce.co.jp 今回は開発だけでなく、プロダクトマネージャーの視点からCursorをどう活用しているか、リアルな事例をシェアしたいと思います！ 世の中にはたくさんの素晴らしい活用例がありますが、正直なところ、AIツールは期待通りに動かないこともしばしば…あると思います。 成功事例ばかりではなく、私たちが実際に直面している「理想と現実のギャップ」と、それをどう乗り越えてCursorを活用しているかをお話しします。「あるある！それ、うちでもそうなのよ！」と思っていただければありがたいです。 ここからは、当社が企業の法務業務全般をAI

はじめに こんにちは。株式会社LegalOn TechnologiesでSoftware Engineer（Frontend）として働いている川島です。 突然ですが、組織が急成長するに伴ってメンバーの多様性が増し、以前のような阿吽の呼吸が通用しなくなったり、価値観や考え方の食い違いによる衝突が頻発した際にどう対処したらいいかわからなかったり…。こうした課題に直面している企業は多いのではないでしょうか。 私たちLegalOn Technologiesにおいても、開発組織のメンバーが2025年7月現在で200名を超え、上記の課題に直面しています。この課題を乗り越え、全員が同じ方向を向いて開発に邁進するために、開発組織が重視すべき価値観や振る舞いを言語化した「LegalOn Technologies Developers Compass」を作成しました。ぜひ以下のリンクからご覧ください！ spe

はじめに 株式会社LegalOn Technologiesでアナリティクスエンジニアをしている鈴木です。 データ活用の現場では、メタデータの品質が分析や開発の効率を大きく左右します。特に、データベースのカラム定義（description）は、データの意味や使い方を理解する上で重要な役割を果たしています。 今回は、Gemini（生成AI）を活用してBigQueryのテーブルdescriptionを半自動補完する取り組みについてご紹介します。この施策により、データの可視性・可読性が向上し、チーム全体のデータ活用効率が改善されました。 現在の環境 現在のデータウェアハウスを取り巻く環境は以下の構成となっています。 BigQuery上のデータマートを効率的にデータモデリングするツールとしてdbtを採用している dbtにより、dl（データレイク）・dwh（データウェアハウス）・dm（データマート）の

こんにちは、株式会社LegalOn Technologiesでソフトウェアエンジニアをしている高橋です。 LegalOn Technologiesでは、日本の法務分野における自然言語処理（NLP）のための包括的なベンチマークデータセット、LegalRikaiを作成しています。LegalRikaiは日本法に特化したさまざまなタスクを含むベンチマークデータセットで、法務NLPベンチマークデータセットの現状における重要なギャップを埋めることを目的としています。 LegalRikai作成の背景と目的 近年、大規模言語モデル（LLM）の登場により、リーガルテックを含む様々な分野が大きく前進しました。しかし、これらのモデルは主に英語の一般知識を評価するために設計されたベンチマークデータセットを用いて評価されることが多く、英語で高い性能を発揮すれば、他の言語や分野でも高い能力を発揮できるという前提につな

検索・推薦チームの浅野です。 2/13~2/14 に開催された Developers Summit 2025（通称デブサミ）に公募枠で登壇させていただきました。発表資料は以下です。 このブログでは、登壇に至った経緯や、発表で伝えたかったこと、さらにコミュニケーションについて学びたい方向けの書籍などをご紹介します。 登壇の経緯 昨年開催された Developers Summit 2024 では、運営の方から弊社の渡辺にお声がかかり、生成AIをテーマに登壇しました。 それから1年経過し、デブサミ2025 のテーマと登壇者募集の情報が公開されていたことから、弊社広報より公募枠に応募しないかと私に声がかかりました。 私が昨年書いたブログの内容が、様々な職種や立場の方から反響をいただいていたことから、 Developers Summit 2025 のテーマ「ひろがるエンジニアリング」とマッチするので

こんにちは、株式会社LegalOn TechnologiesでPlatform Engineerをしている杉田（@toshi0607）です。 先日、CloudNative Days Winter 2024で「50以上のマイクロサービスを支えるアプリケーションプラットフォームの設計・構築の後悔と進化」と題し、LegalOn TechnologiesにけるPlatform Engineeringの取り組みについてお話してきました。前編では、「LegalOn Cloud」を短期間でリリースするために行った工夫と後悔を紹介しました。この記事では、Platform Engineering Advent Calendar 2024の25日目の記事として登壇内容の後半部分を書き起こします。 マルチプロダクト・リージョンを支えるプラットフォームへの進化のための取り組み ここからはアプリケーションプラットフ

こんにちは、株式会社LegalOn TechnologiesでPlatform Engineerをしている杉田（@toshi0607）です。 先日、CloudNative Days Winter 2024で「50以上のマイクロサービスを支えるアプリケーションプラットフォームの設計・構築の後悔と進化」と題し、LegalOn TechnologiesにおけるPlatform Engineeringの取り組みについてお話してきました。この記事では、Platform Engineering Advent Calendar 2024の23日目の記事として登壇内容の前半部分を書き起こします。 Introduction 自己紹介 杉田寿憲と申します。社会人大学院生としてコンピューターサイエンスを学びながら、LegalOn Technologiesという会社でPlatform Engineerをしています

はじめに こんにちは。株式会社LegalOn Technologies データマネジメントチームでアナリティクスエンジニアをしております、須賀です。 この記事は、datatech-jp Advent Calendar 2024 *1 の19日目の記事として執筆されました。 想定読者 ダッシュボード作成に関与する依頼者・開発者 データを活用するすべての方々 作成済みのダッシュボードや登録済みのメタデータを利用し、自発的にデータ活用している方 プロダクトを開発するエンジニア 集計目的を満たす上で、データの仕様に問題がないか質問を受けたことのある方 ダッシュボードを利用・開発時によく発生する課題 ダッシュボードの利用者・開発者の方で、以下のような経験をされた方は多いのではないでしょうか？ 利用者の方 ダッシュボード上の数値がどんな集計定義で可視化されているのか分からない 必要なデータが、既に分析

こんにちは、LegalOn Technologies 検索・推薦チームの志水と勝田です。 我々のチームではこの1年をかけてチームビルディングやアジャイル開発に繋がる様々な手法や施策を試し、その成果が徐々に出てきました。今日はその過程を紹介いたします。時間がかかっても必ず成果は出ると思うので、似た取り組みをしようとされている方はぜひ参考にしてみてください！ はじめに 2024年春、「LegalOn Cloud」がリリースされました。これまでの開発では、各機能に専任メンバーを割り当て、定期的な情報共有や技術的な相談を行う方式を採用していました。この開発スタイルは、開発内容が明確な状況下で高いパフォーマンスを発揮していました。しかし、属人性の解消や、不確実な状況への柔軟な対応のため、より効率的でスケーラブルな開発スタイルを追求する必要性が生じました。 検索・推薦チームは全員がフルリモートで働いて

こんにちは。LegalOn Technologies 検索・推薦チームの浅野（@takuya_b / @takuya_a）です。 先日、社内のプロダクトマネージャー（以下、PdM）を主な対象として、検索推薦技術の入門講座を開催しました。このたび、その資料を公開します。 資料の概要 この講座では、検索推薦技術とその周辺について、概要をざっくり理解できるように努めました。技術的詳細、とくに具体的なアルゴリズムにはあまり立ち入らず、できるだけ平易なことばで説明したつもりです。なお、広範な範囲を扱うため、各回1時間（質疑応答込み）で、3回に分けて実施しました。 公開した資料は、PdM だけでなく、エンジニアリングマネージャー（EM）やソフトウェアエンジニアの方々にも読んでいただけると嬉しいです。 以下は、各回で扱ったトピックです。 第1回 全体概要と検索技術入門・・・資料P3~ 検索・推薦とはなに

はじめに こんにちは、株式会社 LegalOn Technologies 検索・推薦チーム エンジニア の 勝田 (WinField95)です。この記事では、先日実施した検索・推薦チームの社内ハッカソンについてレポートします。 「よし、みんなで楽しく開発合宿！」と行きたいところですが、なんと予算0円です。 急遽ハッカソンを企画したため、残念ながら予算を確保できていませんでした。 しかし、予算がないからといって開発合宿ができないわけではありません。遠方での合宿は難しいものの、やる気さえあればハッカソンは可能です。そこで、チームメンバー全員が通常業務を効率よく終わらせ、生み出した2日間を使ってハッカソンを実施しました。 社内ハッカソンを行う意義 ハッカソン（Hackathon）とは、「ハック（Hack）」と「マラソン（Marathon）」を組み合わせた言葉で、短期間で集中的に開発に取り組むイベ

LegalOn Technologiesで検索・推薦エンジニアをやっております宮里（smiyazato）です。 9/14-9/16の三連休に軽井沢で開催された情報科学若手の会で、スポンサーとして発表してきたのでその報告を致します。 情報科学若手の会とは 情報処理学会のプログラミングシンポジウム委員会が主催している合宿形式のイベントで、年1回あります。57回目なのでそのくらいの歴史があるらしいです。 若手の会と名がついていますが年齢制限とかはなく、参加者40名前後の中で、新卒4年目27歳の私が大体上位5分の1ラインくらいに見えました（勝手な肌感）。 合宿の中では、情報科学に関連する発表がいくつか行われ、発表外でも親睦を深めるイベントがあります。分野の縛りは多分あまりなく、基本的にカジュアルかつ内容が濃い雰囲気です。 そして 画像の通り、参加後にブログを書く、そういう伝統があります。 スピード

はじめに こんにちは。LegalOn Technologies 検索・推薦チームの臼井（jusui）です。 私たちのチームは、LegalOn Technologies が提供する主要サービス—「LegalOn Cloud」、「LegalForce」、「LegalForceキャビネ」—の検索・推薦システムの開発と運用を担当しています。 2024年7月に当チームから「Dataflow 実践開発セットアップ」を公開しました。 tech.legalforce.co.jp 今回は、2024年4月から提供開始した弊社の新サービス「LegalOn Cloud」の初回リリースに向けて開発した Indexing pipeline とその後の改善についてご紹介します。具体的には、Cloud Pub/Sub と Cloud Dataflow を活用した Indexing pipeline の開発により、Elas

こんにちは、LegalOn Technologiesで検索エンジニアをしている志水(@banbiossa)です。 食事つきの勉強会を開催する際に、学び目的ではなく飲食目的、いわゆる「タダ飯狙い」の方に遭遇したという声を最近多く聞きます。 この「タダ飯狙い」や不審者の対策にむけて、リーガルテック企業ならではの取り組みとして、参加規約のひな形を準備しました。 本記事では、取り組むまでに至った経緯や過程、ひな形の詳細、協力してくれた方々についてご紹介できればと思います。 勉強会の治安の悪化 弁護士ドットコム社の記事 検索技術勉強会における実体験 勉強会用・参加規約のひな形 ひな形本文 ひな形とは？ 活用方法について ひな形の活用 勉強会の運営 勉強会用・参加規約ひな形プロジェクトの全容 シャッフルランチでCTOに投げかける 法務・法務開発の巻き込み ドラフト→レビュー→公開 ひな形作成時の想定

はじめに 本記事では、Datadog の設定方法を解説しながら、どのようにフロントエンド開発に活用できるかを話していきます。Datadog とは SaaS 型で提供されている監視サービスです。システムやアプリケーションの監視ができ、収集したログを分析するのに役立つ機能をたくさん提供しています。 こんにちは、株式会社LegalOn Technologiesで Software Engineer（Frontend）をしている山越 ( @yukishinonomeIT ) です。弊社では2024年4月に『LegalOn Cloud』というプロダクトを提供開始しました。Datadog は既存のプロダクトでも使っていたので、この新しいプロダクトでも活用することになりました。そこで、『LegalOn Cloud』における Datadog の運用を担当することになったので、実際にどのような活用をしている

こんにちは、LegalOn Technologies検索・推薦チームの志水です。 私たちのチームでは Elasticsearch へのデータのインデキシングをCloud PubSub を queue として挟んで非同期にしており、その処理にDataflowを活用しています。Dataflow(=Google managed Apache Beam) はサーバーレスでスケーラブルなデータ処理を得意としています。 Python を用いたDataflowの活用については、例えばこちらの記事が網羅的です。 この記事では似たような観点に加え、Docker上で動かす工夫やintegration testの工夫も合わせて書いていければと思います。 全体像 パッケージ構成 pyproject.toml (Poetry) Pipeline Integration test DoFnのテスト DirectRun

こんにちは、LegalOn Technologiesでエンジニアをしている神田（@kampersanda）です。 本記事では、Jaccard係数に基づく類似文書検索の高速化技法を解説し、契約書検索での実験結果を報告します。 背景と目的 共起に基づく類似文書検索の必要性 契約書検索での注意点 本記事の目的 準備 表記 Jaccard係数 Overlap係数との関係 問題設定 線形探索による解法 高速化の方針 Length Filtering Position Filtering 高速化のための要素順序 アルゴリズム 転置索引を使った解法 基本的なアイデア Prefix Filteringに基づくトークンの絞り込み 高速化のための要素順序 アルゴリズム 実験 データセット 統計量 Length Filterの検出率に関する結果 検索時間に関する結果 おわりに メンバー募集中!! 背景と目的 共

はじめに こんにちは。株式会社LegalOn Technologies でエンジニアをしております、勝田(@WinField95)です。この記事は、情報検索・検索技術 Advent Calendar 2023 の 20日目の記事として執筆されました。 この記事では、ANTLR[1]を使用したシンプルなクエリ構文の解析を行う検索クエリパーサーの生成と、解析結果から Elasticsearch の Query DSL[2]への変換までのプロセスと簡単な実装を紹介します。実務では、要求に応じて複雑なクエリ構文の文法定義が必要になる場合もありますが、この記事ではなるべく簡単なクエリ構文を取り扱います。解説で使用するコードは、この GitHub のリポジトリで公開しますので、参考にしてみてください。また、Search Engineering Tech Talk 2023 Winter では、この記事

こんにちは、LegalOn Technologies Researchで研究員をしている神田（@kampersanda）です。 弊社では、検索チーム主催でセマンティック検索とベクトル検索に関する社内勉強会を定期的に実施しています。この勉強会では、技術に関心のあるエンジニアが有志で議題を持ち寄り、知識共有を行っています。 その成果のひとつとして、文埋め込み技術であるSimCSEのチュートリアル資料を作成し、以下に公開しました。 github.com この資料はNotebookとして作成されており、SimCSEの学習から評価までの一連の動作を簡単に試して頂くことができます。また、コードの各パートには詳細なコメントや引用を付与しています。 本記事では、資料作成の目的や方法などを簡単に紹介します。チュートリアルの内容については、Notebookをご参照ください。 SimCSEの概要 SimCSEは

はじめに 株式会社LegalOn Technologies でデータエンジニアリングをしている 田中 晶 です。 LegalOn Technologies では、データドリブンな意思決定をするために、データ分析基盤や BI ツールの整備を行い、プロダクトに関わる多くの社員がデータを活用できる状態を維持し、さらなる活用を目指しています。 過去の啓蒙活動や整備の甲斐もあり、現在弊社で利用しているBIツールである Looker のライセンスは多くの社員に付与されており、またその活用も専門職だけでなく、営業部門の活用率も高いという利用率の計測結果も出ているほどです。 このように活用されているデータ分析基盤ですが、より高いデータの利活用水準を目指すためには、利用者や用途に関して、長期的に柔軟な利用状況の分析を行う必要がでてきました。 そこで幅広く Looker の活用度を測定するために使用状況やパフ

こんにちは。LegalOn TechnologiesでCTOを務めている深川といいます。 もし私がどういう人なのか気になる方がいましたら、私のことは以下の弊社オープン社内報でも記載していますので、よかったらこちらの記事をご覧いただければと思います。 https://now.legalontech.jp/n/n36b23e19f7b0 エンジニア組織の運営は人数が増えていくにつれて加速度的に難易度があがります。その中でも、エンジニアリングマネージャーにとって常に頭を悩ませるものが人事評価制度です。特に、評価基準については、公正かつ納得感があり、それでいて属人化しない評価基準を作り上げるのは至難の業です。 弊社も例に漏れずエンジニアのグレード評価基準に課題を感じていたため、2022年10月にエンジニアグレード評価基準の刷新を行いました。そこから約10か月が経過し、徐々に刷新の効果や課題が見えて

こんにちは、株式会社LegalOn TechnologiesでCSIRTのリーダーを務めている今成と申します。 本記事では、LegalOn Technologies（以下 LegalOn）におけるCSIRTのセキュリティインシデント対応に係るプロセスおよび管理方法を、体系的に整理した事例をご紹介します。企業のセキュリティ担当者の方々に、セキュリティインシデント対応の事前準備という観点で、参考になる情報を記載しています。ぜひ最後までお読みください。 世の中の動き 近年は多くのセキュリティ関連のニュースが報じられており、サイバー攻撃の手法が多様化・巧妙化していることが伺えます。また、働き方改革やCOVID-19への対応から企業のワークスタイルが変化したことにより、環境変化に伴うセキュリティリスクについても新たな課題が浮上してきています。 このような動向を踏まえ、2023年3月に「サイバーセキュ

こんにちは、SRE&プラットフォームグループの和田です。LegalOn Technologiesでは、2019年4月に「LegalForce」、2021年1月に「LegalForceキャビネ」を正式リリースして以来、毎月機能アップデートをしています。また、リリース初期段階では予期できなかった技術的な課題に対処するために、バックエンドやインフラの改善も進めています。このような取り組みの中で、DBスキーマの更新も多数発生してきました。「LegalForce」では、シーケンシャルなDBスキーマ管理を採用していましたが、運用面での懸念が顕在化していました。一方、「LegalForceキャビネ」は、NoSQLからRDBMSへの移行計画の真っ只中で、将来的なDBスキーマ管理方法のプランを練っていました。 こういった文脈において今回は「LegalForce」と「LegalForceキャビネ」製品のCI/

こんにちは！ 株式会社LegalOn TechnologiesのLegalForceキャビネ開発部SET（Software Engineer in Test）のひきもち（@rmochioo）です。 昨年8月に入社し、LegalForceキャビネのAPIテスト、自動E2Eテストなどの自動テストの導入、QA業務まで幅広く携わっております。 APIテストに関しては先日、記事出ていますのでご興味があれば見ていただければと思います。 tech.legalforce.co.jp LegalForceキャビネではE2Eテストの自動化ツールとしてmablを利用していましたが、この度Playwrightへの移行を行いました。 現在LegalForceキャビネで運用しているE2Eテストは全てPlaywrightで実行されており、リリース可否判断やQA環境でのマニュアルテストのサポートとして利用されています。

初めに こんにちは、株式会社 LegalOn Technologies の LegalForceキャビネ開発部でテックリードを務めている横道と申します。 私たちのプロダクト、「LegalForceキャビネ(以下キャビネ)」では Google Firebase を使用しています。 この Google Firebase を、実際のプロダクト開発と運用で使用した際に生じた課題と対応ついて、「Firebase 使用上の注意 Functions 編」「同 Firestore 編」の 2 つに分けてお送りします。 今回は Functions 編として、Firebase Functions を使ったプロダクトが、規模の増大と機能が増加していった際に、どのような課題が生じ、そしてどのような対応を行ったかを共有します。 スタートした段階では、キャビネの開発チームも小さく、サービス自体もどれくらい普及するのか

こんにちは、株式会社LegalOn Technologies の検索・推薦チームでエンジニアをしている、佐藤です。 弊社では LegalForce という製品で、お客様がアップロードした契約書を条文単位で検索ができる、条文検索機能を提供しています。 条文検索では既に契約書本文の Query Auto Completion (クエリ自動補完, 以下 QAC)が提供されており (*1)、今回は契約書のタイトルやファイル名などで絞り込み検索を行う際に利用される QAC の開発を行いました。 本記事では今回開発した QAC を実現する上で課題となった QAC データの更新について、継続的な更新を行うために検討したシステム設計や運用方法を紹介したいと思います。 (*1) 別の記事で詳しく紹介されています。 目次 絞り込み検索のための QAC QAC データ更新における課題 Completion 更新

こんにちは、株式会社LegalOn TechnologiesのLegalForceキャビネ開発部でQAリードを務めている島根（@shimashima35）と申します。 QAというとマニュアルテストが中心かと思われるかもしれません。確かにマニュアルテストはQAの業務の一部ではありますが、「質とスピードの両立」つまりプロダクト品質の高さとリリーススピードの両立を目指すため自動テストの導入もおこなっています。 今回はLegalForceキャビネのバックエンドに対するAPIテストを実装した話をご紹介します。 APIテストとは まず最初にAPIテストについて説明します。 APIテストの概要 APIテストとはWeb APIの外形的な仕様を満たしているかを HTTP(S)を用いてテストすることです。バックエンドのコントローラーに対するユニットテストとは以下の点が異なります。 HTTP(S)を経由する デ

こんにちは。株式会社LegalOn Technologies でエンジニアをしている赤部です。 自然言語処理をしていると、単語の出現回数を数えたり、単語と何らかのデータを紐付けたりすることが頻繁に必要になります。これらのことを簡単に行える、最も一般的でよく知られたデータ構造はハッシュマップではないでしょうか？ プログラミング言語 Rust では、標準ライブラリの std::collections::HashMap を用いればハッシュマップを簡単に導入できます。しかし、場合によっては標準ライブラリの HashMap ではなく hashbrown クレートを利用したほうが、シンプルに効率的なコードを実装できるかもしれません。 この記事では、まず hashbrown クレートを紹介し、コード例とともに hashbrown クレートの使いどころを紹介します。 hashbrown クレート Rust