正規表現すぐ忘れるのでビジュアルプログラミングツールを作った ~ Blocklyで簡単にビジュアルDSL作ろう ~

皆さん、DSLを作ることってありますか？ 複雑な設定が可能な社内ツールを作るとき、 「DSLを許容したら自由度が上がって素敵では？」 と思うこと、ありますよね。 私個人としては、エンジニア向けのインタフェースとして、DSLで社内ツールを作ると、作る当時は楽しいものの、複雑なことを許容する分保守性に問題がでてくるデメリットも有り、近年は設定はyamlで書ける範囲にすることが多いです。

一方で、非エンジニア向けに、ロジックをビジュアルなDSLで提供できたら良いなってこともありませんか。 例えばjoinとfilterのみに絞ったデータ集計ツールを作りたい、行動Aをしたあとに行動Bをした一部のユーザーにキャンペーンメールを送りたい、などのロジックを安全にかつ柔軟に提供したいというシーンです。 ビジュアルで書けるって範囲にすれば、複雑度も一定の範囲になるのでありかなと思ってます。 こういう、ロジックを非エンジニアが書けるツールというのは需要があるものの、そこの作り込みに時間をかけると無限に時間が溶けていきますよね。

そこで今回はビジュアルプログラミングのためのフレームワークBlocklyを使ってUI部分を考えないですむビジュアルDSLに入門してみます。

M3エンジニア大大大募集、にマッチする正規表現を作るビジュアルプログラミング例

NVFP4: 4ビットの浮動小数点でLLMを学習する仕組み

こんにちは、AI・機械学習チームの髙橋です。

この記事はエムスリー Advent Calendar 2025 22日目の記事です。前日は同じAI・機械学習チームの鴨田さんによる LLMによって非定形の会話ログを価値あるFAQデータにする話 - エムスリーテックブログでした。

迎賓館赤坂離宮の噴水: 並列処理で射出された水が中央で集約される様子はまるでGPUで行われる行列演算のよう？

はじめに

ChatGPTが発表された2022年11月30日から3年が経過し、それからというものLLMの話を聞かない日はない世界になりました。 今日ではCoding Agent無しでは生きていけない、という読者も多いのではないでしょうか。私もそのうちのひとりです。

さて、ベンチマークや実用上のパフォーマンスといった面では、日進月歩凄まじい進展を見せているLLMですが、その能力のコアにあたる部分は3年経っても驚くほど変わっていません。

すなわち、

膨大なパラメータのTransformerモデルを膨大なトークンで事前学習させる

ことです。

「膨大」という言葉が重複しましたが、この事前学習にはまさに途方もない演算を処理する必要があります。 例えば1T級のモデルを学習するにはおおまかに10の25~26乗 FLOPs 程度の演算量が必要になります。

B200のカタログスペック (1枚あたり2.5PFLOPs、10の15乗)であっても、100日(8.64×10の6乗秒)で学習をするにはざっくり500~5000枚程度が必要になる計算です。

この途方もない演算を行うべく、数十兆円とも言われるデータセンター投資が行われているわけですが、もし同じGPUの計算量を4倍にできたとしたら数十兆円のコストを1/4にできるわけですから、とんでもないROIになります。

今回はそんな可能性を秘めた4ビット浮動小数点、NVFP4について解説していこうと思います。

LLMによって非定形の会話ログを価値あるFAQデータにする話

AI・機械学習チームの鴨田です。 この記事はエムスリー Advent Calendar 2025の21日目の記事です。 20日目は星川さんのSlackワークフロー使いこなせてる？進化したトリガーとリストで実現するハックでした。

サムネ

TL;DR

• 問い合わせログからFAQ記事を自動生成するパイプラインを構築
• パイプラインはFAQ以外にも応用可能

日々、企業のシステムには膨大な「テキストデータ」が蓄積されています。問い合わせログ、社内チャットツールでの会話、メールでのやり取りなど...これらは「フロー情報」として消費されるか、あるいはDBの肥やしとして眠ったままになりがちです。

そんな中、LLM（大規模言語モデル）の登場により、これらの非構造化データを「ストック情報＝資産」へと変換するコストが劇的に下がりました。

本記事では、私たちが実際に構築・運用しているFAQシステムを事例に、そこで採用したデータ処理パイプラインの詳細と、その汎用的な可能性についてお話しします。

※この記事は2025/8/20(水)に行われたオンラインイベントで発表した内容をブログ化したものです

www.tech-street.jp

Slackワークフロー使いこなせてる？進化したトリガーとリストで実現するハック

はじめに

本記事は、M3 Advent Calendar 2025 20日目の記事です。

Unit3の星川 (@oboenikui) です。 Unit3では、主に医学書の電子書籍サービスや、医師の開業サポート、会員優待などのサービスを担当しています。

弊社ではチャットツールとしてSlackを使用しており、日々の業務で発生する申請や依頼といった定型作業は、Slackワークフローを使用することが多いです。

Slackワークフローをあまり触ったことがない方は、もしかすると「簡単なフォームを作って投稿を作成するツール」という認識で止まっているかもしれません。 しかし現在のワークフローは、簡易的なノーコードツールと言っても過言ではないほど、様々なパターンに対応した便利なツールへと進化しています。

この記事では、Slackワークフローの基本から、その真価を発揮する発展的な使い方まで、実用的な例を交えていくつか紹介します。

すでに基本的な使い方をご存知の方は、「4. Slackワークフローの発展的な利用方法」のセクションからお読みください。

記事執筆期間に構ってほしそうにしてきた飼い猫です。記事内容とは無関係です。

プロダクトマネージャーに商売センスが必要な理由と磨き方

こんにちは。エンジニアリンググループ プロダクト支援チームでPdMをしている中村です。この記事はエムスリー Advent Calendar 2025の19日目の記事です。 18日目は山本さんの「Google Cloud コンテナイメージの脆弱性スキャンを自作 OSS で運用する」でした。

画像はGeminiで生成しました。

はじめに

PdMにとって、担当プロダクトをいかに成長させるかは永遠のテーマであり、最も頭を悩ませる部分ではないでしょうか。私も日々、試行錯誤しながらプロダクトを成長させるための課題解決や新しいアイデアを考えています。そのような中で、CPO山崎に相談すると、議論の核心としてしばしば「商売センス」というキーワードが登場します。 また、社内のPdMが集まるPdM定例でも、商売センスというキーワードは頻繁に話題に上ります。

「プロダクトマネジメント」と「商売センス」。 一見すると距離がありそうなこの2つの言葉ですが、実は切っても切り離せない、PdMにとって非常に重要なスキルだと感じています。特にエムスリー社内で定義されているレベル3のPdM*1を目指すうえでは不可欠なスキルです。

今回は、なぜPdMにとって商売センスがそれほどまでに重要なのか、そしてそのセンスはどうすれば磨くことができるのかについて、私なりの考えと学びを共有します。

*1:ここでは、年間利益 50~100 億を作れるレベルのPdMを指します。詳しくは次の記事をご参照ください。

www.m3tech.blog

Google Cloud コンテナイメージの脆弱性スキャンを自作 OSS で運用する

こんにちは、AI・機械学習チームの山本（@hiro_o918）です。 この記事はエムスリー Advent Calendar 2025 18 日目の記事になります。 17 日目は北川さんの「わたしの Language Server にはパーサーが２種類あんねん」でした。

はじめに

皆さんは脆弱性の検知と対応をどのように行っていますか？

エムスリーでは脆弱性管理ツールを導入することで、コンテナイメージやパッケージの脆弱性スキャンを自動化し、検知された脆弱性への対応をチーム全体で協力して行っています。 しかし、次の記事にもあるように AI チームでは次々にプロダクトを立ち上げているため、スキャン対象の管理など運用コストが増大してしまう課題がありました。

そこで今回は、Google Cloud の Artifact Registry に組み込まれたスキャン機能の利点を最大限に活用し、さらに自作の OSS ツールで運用することで、運用コストを抑えつつ効率的に脆弱性管理と修正プロセスを進められるようになった話を紹介します*1。

*1:ところで、以前まで Google Container Registry と呼ばれていたサービスは 2025 年 3 月 18 日をもって廃止となり、Artifact Registry に統合されました

わたしのLanguage Serverにはパーサーが２種類あんねん

AI・機械学習チームの北川です。 この記事はエムスリー Advent Calendar 2025の17日目の記事です。 16日目は須藤さんのAIに正しく分析してもらうためのテーブル設計戦略でした。

猫も２種類に増えました。猫もそれぞれ性格が違ってそれぞれの良さがありますよねー

はじめに

以前、BigQuery用のLanguage Server(bqls)を自作した話を書きました。 このbqlsは、GoogleのzetasqlをベースにしたBigQuery専用のLSPで、Web UIでは遅く感じていた補完をNeovimなどのエディタで快適に使えるようにしたものです。

github.com

zetasqlの強みは、SQLをパースするだけでなく、カラムの型情報なども一緒に提供してくれる点にあります。 しかし、運用していく中で大きな課題が見えてきました。 それは、SQLにバグがあるとパースできないという点です。

LSPで補完などのリクエストが来る時、たいていそのコードは「壊れています」。 例えば補完を出したいタイミングはユーザーがコードを書いている途中です。 つまり文法的には壊れた状態であることがほとんどです。 前回のブログでは漸次的修正という手法でこの問題に対処しましたが、それでも限界がありました。

この記事では、そんな課題を解決するために導入したtree-sitterと、zetasqlとの適材適所な使い分けについて紹介します。