はてなブックマーク

AI・機械学習チームの髙橋です。 みなさま、コーディングライフいかがお過ごしでしょうか。 エムスリーでは、昨年初夏頃からエンジニアに対してClaude Codeの業務における無制限使用が解禁されています。 現在ではほぼすべてのエンジニアが普段からClaude Codeを利用し、AIレビューやチーム内でのプラグインによるSkill共有が進んでいます！ ということで今回は、以前の突撃！ 隣のキーボード M3 2024 - エムスリーテックブログのスピンオフとして、エムスリーのエンジニアメンバーが実際に利用している便利なClaude Codeのカスタマイズを募集し、紹介します！ 例のしゃもじ 前置き：Claude Codeのカスタマイズとは Claude Codeではエージェントに対してユーザ・プロジェクト固有の指示や制約を与えることができます。 昨今はSkillsが特に話題となっていますが、こ

この記事はエムスリー Advent Calendar 2025 16日目の記事です。 こんにちは、AI・機械学習チームの須藤です。 現在は、BigQuery上のデータを自然言語で分析できる社内向けプロダクトを開発しています。本記事では、AIに正しくデータを分析してもらうために工夫したテーブル設計戦略について紹介します。 データ分析の民主化 AIがデータ分析する際に起こり得る問題 JOINと行増殖のリスク 解決策：AIのための「非正規化」 分析専用のOne Big Tableを用意する JOINを物理的に排除する 注意点 データの整合性 コストとパフォーマンスのトレードオフ まとめ We are hiring! データ分析の民主化 昨今、AIエージェントの活用が進んでいます。これまでのAIはチャット相手としての側面が強かったですが、MCP（Model Context Protocol）*1な

皆さん、DSLを作ることってありますか？ 複雑な設定が可能な社内ツールを作るとき、 「DSLを許容したら自由度が上がって素敵では？」 と思うこと、ありますよね。 私個人としては、エンジニア向けのインタフェースとして、DSLで社内ツールを作ると、作る当時は楽しいものの、複雑なことを許容する分保守性に問題がでてくるデメリットも有り、近年は設定はyamlで書ける範囲にすることが多いです。 一方で、非エンジニア向けに、ロジックをビジュアルなDSLで提供できたら良いなってこともありませんか。 例えばjoinとfilterのみに絞ったデータ集計ツールを作りたい、行動Aをしたあとに行動Bをした一部のユーザーにキャンペーンメールを送りたい、などのロジックを安全にかつ柔軟に提供したいというシーンです。 ビジュアルで書けるって範囲にすれば、複雑度も一定の範囲になるのでありかなと思ってます。 こういう、ロジック

こんにちは、AI・機械学習チームの髙橋です。 この記事はエムスリー Advent Calendar 2025 22日目の記事です。前日は同じAI・機械学習チームの鴨田さんによる LLMによって非定形の会話ログを価値あるFAQデータにする話 - エムスリーテックブログでした。 迎賓館赤坂離宮の噴水: 並列処理で射出された水が中央で集約される様子はまるでGPUで行われる行列演算のよう？ はじめに ChatGPTが発表された2022年11月30日から3年が経過し、それからというものLLMの話を聞かない日はない世界になりました。 今日ではCoding Agent無しでは生きていけない、という読者も多いのではないでしょうか。私もそのうちのひとりです。 さて、ベンチマークや実用上のパフォーマンスといった面では、日進月歩凄まじい進展を見せているLLMですが、その能力のコアにあたる部分は3年経っても驚くほ

はじめに 本記事は、M3 Advent Calendar 2025 20日目の記事です。 Unit3の星川 (@oboenikui) です。 Unit3では、主に医学書の電子書籍サービスや、医師の開業サポート、会員優待などのサービスを担当しています。 弊社ではチャットツールとしてSlackを使用しており、日々の業務で発生する申請や依頼といった定型作業は、Slackワークフローを使用することが多いです。 Slackワークフローをあまり触ったことがない方は、もしかすると「簡単なフォームを作って投稿を作成するツール」という認識で止まっているかもしれません。 しかし現在のワークフローは、簡易的なノーコードツールと言っても過言ではないほど、様々なパターンに対応した便利なツールへと進化しています。 この記事では、Slackワークフローの基本から、その真価を発揮する発展的な使い方まで、実用的な例を交えて

AI・機械学習チームの北川です。 この記事はエムスリー Advent Calendar 2025の17日目の記事です。 16日目は須藤さんのAIに正しく分析してもらうためのテーブル設計戦略でした。 猫も２種類に増えました。猫もそれぞれ性格が違ってそれぞれの良さがありますよねー はじめに 以前、BigQuery用のLanguage Server(bqls)を自作した話を書きました。 このbqlsは、GoogleのzetasqlをベースにしたBigQuery専用のLSPで、Web UIでは遅く感じていた補完をNeovimなどのエディタで快適に使えるようにしたものです。 github.com zetasqlの強みは、SQLをパースするだけでなく、カラムの型情報なども一緒に提供してくれる点にあります。 しかし、運用していく中で大きな課題が見えてきました。 それは、SQLにバグがあるとパースできない

記事のイメージ画像を gemini に生成させたもの 本記事はエムスリー Advent Calendar 2025 15 日目の記事です。 OCaml が好きです。 元々好きでしたが、バージョン 5 からはマルチコア対応が入り、更に好きな要素が増えました。 それは前回も紹介した Algebraic Effects and Handlers という新機能です。 新しい機能はそれだけで心躍るものですが、使い方が十分周知されていないのも事実です。 「なんでもできる」と前回紹介した通り、今回はこのなんでもできる機能が実用的な機能であることを見ていきます。 はじめに そもそも Algebraic Effects and Handlers とは まずはただの例外機構 戻ってくる、とは Effect Handler 実用 Algebraic Effects and Handlers ロギング DB I/

本記事は、M3 Advent Calendar 2025 14日目の記事です。 はじめまして。エンジニアグループ、コンシューマーチームの松本と申します。 今回は、「継続 - Continuation」の本質を理解し、Promiseやasync/awaitでは解決できない課題を明らかにした上で、それを乗り越えるEffect Systemについて解説します。 「継続 - Continuation」とは？ コールバック関数は継続そのもの 継続と非同期処理、副作用 継続の課題：コールバック地獄 継続渡しスタイル（Continuation-Passing Style, CPS） CPSの問題点：継続のネスト 継続の合成：Promise と async/await Promise（継続を合成する） async/await 継続だけでは解決できない課題 課題1: どんなエラーが発生しうるか、型から分から

こんにちは。AI・機械学習チームの苅野です。 このブログはエムスリー Advent Calendar 2025 10 日目の記事です。API と Batch でリポジトリが分かれているプロダクトを 1 つのリポジトリに統合しようと考えて検証を行い、 「既存リポジトリで git mv してから merge --allow-unrelated-histories する」 方法を採用することに決めました。 git filter-repo など他の手法も検証しましたが、この方法だと 「Commit ID を変えずに（過去の PR リンク等を維持したまま）、--follow オプションでファイル移動前の履歴も追える」 ため、この方針で統合を進める予定です。 具体的な検証過程と手順を以下に紹介します。 リポジトリを 1 つに統合したかった理由 まとめて変更を加えることができる API の integr

この記事はエムスリー Advent Calendar 2025 9日目の記事です。 デジスマチームの小島(@jiko_21)です。 TSKaigiの次の日に行った近江町市場での新鮮な牡蠣とのどぐろ。おいしかったです。 今回は自分が趣味で実装しているhtml-typeというプロジェクトにて行っている、HTMLタグの持つルールをTypeScriptの型として表現する方法について紹介します。 html-typeについて どのようにHTMLタグを型として表現しているか そもそもどうしてHTMLタグを型として表現したいのか HTMLタグとしてのセマンティクス違反を表現 まずは型でHTMLのタグそのものを表現してみる <p>タグ内部の<div>タグを制限する セマンティクス違反をわかりやすくする 最後に We are Hiring! エンジニア採用ページはこちら エンジニア新卒採用サイト！ ！ カジュ

この記事はエムスリー Advent Calendar 2025 5日目の記事です。 エムスリーエンジニアリングG コンシューマーチームの松原です。 Rails アプリケーション開発で型が欲しいと思ったことありますか？ 正直なところ、筆者はそれほど必要ないと考えていました。日々開発・運用している Rails アプリケーションの中には10年選手のものもあり、コードベースの勘所もほぼ把握できている状態だったためです。 しかし、ここ最近は TypeScript で開発されているプロジェクトに触れて型のメリットを実感し、型があった方が嬉しいことの方が多いかもしれないと感じています。 ここ半年ほどを振り返ってみても、型があれば防げたであろう問題に大小合わせると数回以上は遭遇しており、型導入による恩恵がコストを上回る可能性が高いのではないかと考えるようになりました。 また生成 AI が出力するコードにも

エムスリー Advent Calendar 2025 4 日目の記事です。 クラウド型電子カルテのデジカル開発チームで色々なことをやっている井上 (@wtr_in) です。一年を通して伊藤園の天然ミネラル麦茶を愛飲していますが、最近どうも味が変わった気がしています。（しませんか？） さて、すでに当ブログでも過去に何人か記事を書いていますが、弊社では GitLab Server から GitHub Enterprise Cloud への移行を進めています。 www.m3tech.blog デジカルチームでもリポジトリごとに順次移行を進めていますが、その際に GitHub Actions を使って Pull Request のマージ方式を間違えないための仕組みを作ったので、その内容を紹介します。 先に3行でまとめ 抱えていた課題 前提: PR を Squash マージしたい そして生まれる人間

この記事はエムスリー Advent Calendar 2025 3日目の記事です。 こんにちは、エンジニアリンググループ マルチデバイスチームの藤原です。 皆さんはQuine（クワイン）をご存知でしょうか。 Quineとは、「自身のソースコードと完全に同じ文字列を出力するプログラム」のことです。 今回紹介するのは、引数でアスキーアートの形が変わるSwift製Quineです。一見難解なコードの裏にあるロジックを、フローチャートを使って紐解いていきます。 Swift Quine：M3のすがた 変身する実行結果：M3Tのすがたへ 隠されたメッセージ：「M3T」とは？ データの解剖：「テンプレート」と「設計図」の秘密 1. 骨組みを作る「テンプレート」 2. 形を決める「設計図」 全体フローチャート：データ参照の切り替え モードによる参照データの変化 アスキーアート生成 おわりに We are h

この記事はエムスリー Advent Calendar 2025 2日目 兼 マネジメントチームブログリレー9日目の記事です。 こんにちは、エンジニアリンググループ General Manager 兼 基盤チームリーダーの横本(@yokomotod)です。 今回はgoroutineについての自由研究です。 「軽量」「何万個も作れる」「並行処理が簡単に書ける」...そんなgoroutineの裏側はどうなっているんでしょうか。 なぜOSスレッドより「軽い」の？ グリーンスレッドとは違うの？ なぜパフォーマンスが高いと言われるの？ この記事では、goroutineのようなランタイムをRustで自作することで、これらの疑問に答えることを目指しました。 ソースコードの全体は以下のリポジトリで公開しています。 github.com なぜRust？ OSスレッドは重い、のおさらい グリーンスレッドを作って

こんにちは。エンジニアリンググループGMで、データ基盤チームリーダーの木田です。この記事はマネジメントチームブログリレー6日目の記事です。 前回は藤原さんの Claude Codeを手懐けてAndroidアプリ高速リファクタリング でした。 はじめに 今年、エンジニアリンググループでは、オンプレミスのOracleデータベース環境からのクラウド移行をはじめ、多くのデータ移行プロジェクトをチーム横断で推進して来ました。また、データ基盤チームではBigQuery上で稼働しているデータ処理バッチをdbtに移行する取り組みも進みました。活動の一端はこのテックブログでもご紹介してきました。 www.m3tech.blog www.m3tech.blog www.m3tech.blog こうしたデータ移行プロジェクトにおいては、データを互換性を保ちつつ新しいシステムへ移行した際に移行前後でデータの内容が

エンジニアリンググループ GM 兼 QA チームリーダーの窪田です。 本日はマネジメントチームブログリレー4日目として、現在取り組んでいる自動テストを Playwright で構築するチャレンジについてお話しします。 背景 エムスリーでは E2E の自動テストを、リリース前の基本動作チェックや開発直後のセルフ動作チェックなどで活用しています。これまでもブログで紹介してきましたが、メンバー全員で自動テストに取り組むためにプログラミングスキルにあまり依存しないローコードツールを活用してきました。 www.m3tech.blog www.m3tech.blog www.m3tech.blog また、昨年度より QA メンバーだけでなくエンジニアリンググループのメンバー全員で品質確保の活動に取り組む「全員QA」の方針を掲げています。開発メンバーにも自動テスト開発・保守を担ってもらうといった観点で言

週末に訪れたゴルフコース はじめに M3の岩佐(@bloody_snow)です。 最近は M3 Technologies にてM3グループ各社のエンジニアリング支援をメインで担当しています。エムスリーキャリア株式会社と株式会社イーウェルで取締役を勤めていますので、興味のある方はこれらの会社もよろしくお願いいたします。 M3ではリモートワークをメインとしているため、ネットワークの品質が業務効率に直結します。長らく市販のルーターを用いていたのですが、同時接続台数が増えるとパケットロスや通信速度低下が発生するなど、安定性に課題を感じていました。 もちろん最新のハイエンド家庭用ルーターに買い替えれば手っ取り早く解決します。ただ、せっかくなのでこの機会にそこそこの性能を持つシングルボードコンピュータをルーター化し、Wi-Fi は専用の Wi-Fi 7 アクセスポイントに任せる構成にチャレンジしてみま

エムスリーエンジニアリンググループ、データ基盤チームの石塚です。 この記事はデータ基盤チーム & Unit9（エビデンス創出プロダクトチーム） ブログリレー5日目の記事です。前回は三浦さんの 「SQL課題：月の集合を連続した期間の集合にまとめてください」でした。 エムスリーが提供するサービスの中には、今も一部でオンプレミス環境のOracleを活用しているシステムがあります。私たちは、これらのシステムについてもコスト効率やメンテナンス性をさらに向上させるため、Oracleへの依存を段階的に減らしていくプロジェクトを進めています。 このプロジェクトを推進する上で、「そもそも、どのシステムがどれくらいOracleを参照しているのか？」という実態の正確な把握が大きな課題となりました。特に、SQLを解析してどのテーブルに、誰が、いつアクセスしたかを観測し、Oracleへの依存度を正確に測定する必要が

データ基盤チーム & Unit9（エビデンス創出プロダクトチーム）ブログリレー 4日目は、SQLプログラミングのお話をお届けします。Unit9エンジニアの三浦[記事一覧 ]です。昨日は木田さんの『巨大テーブルにインデックスを追加したい、Flywayで』でした。 今回の課題はタイトル通り、月の集合（たとえば、ユーザーがアクティブであった月の集合）から「何年何月から何年何月まで連続していた（アクティブだった）」という期間の集合に変換せよというものです。連続した期間ってのがまとまっていると判定で便利な局面があるんですよね。具体的にどう役に立つかは後述しますが、大変に実用を意識したデータ基盤プログラミング課題であります。 さて私自身がややこしいコードの書かれた記事を見るとコード部分を読み流してしまいがちなので偉そうなことが言えないのですが、やはりプログラミング課題の解説はコードを精読してこそです

エムスリーエンジニアリンググループGMで、データ基盤チームの木田です。 この記事はデータ基盤チーム & Unit9（エビデンス創出プロダクトチーム） ブログリレー3日目の記事です。前回は橋口さんの データ整備の「曖昧さ」に立ち向かう、ドメインエキスパートと協業するための実践的Tipsでした。 本日は、既存のPostgreSQLのさるテーブル (レコード数 100億超) に対して、差分データをSQLで抽出してBigQueryに連携するための索引追加をしたときの経験を元に、PostgreSQLの巨大テーブルに対してFlywayを使用してインデックスを安全に追加する方法についていくつかのテクニックを紹介します。 背景 ナイーブな実装の問題点 CREATE INDEX CONCURRENTLYの使用 Flywayから実行する時の注意点 タイムアウトへの対処 一時領域不足 インデックスサイズを抑える

データ基盤チームの橋口です。この記事はデータ基盤チーム & Unit9（エビデンス創出プロダクトチーム）ブログリレー2日目の記事です。 昨日は坂元さんの『冴えたClaude Codeの育て方（50本のSQLをdbt化した話）』でした。 私の所属するチームでは、社内のデータ活用サポート（データマート作成、分析支援など）を重要な業務の1つとしており、関連部門と一緒にプロジェクトを進める機会も多くあります。 関連部門とプロジェクトを進めていく中で、私は技術的な課題と同じくらい、ステークホルダーといかに上手く協業するかが大事だと学んできました。 なぜなら、データ利活用は「ビジネス課題の特定」から「どのデータを使うかの判断」、「技術的な実装」、「関係者との合意形成」まで幅広く、1人ですべてをカバーすることが難しい領域だからです。 本記事では、私が日々の業務で学習した、ステークホルダーとの協業を円滑に

システムを運用していると時折直面するのが「移行作業」です。 新しい技術に触れられるのは楽しいです。一方、大量のコードの書き換えはちょっと辛いですよね。単純な置換で済めばよいのですが、そううまくはいかないことがほとんどです。 今回はこの書き換えを Claude Code を活用して楽に、精度良く実施したお話です。 データ基盤チーム/Unit9（エビデンス創出プロダクトチーム）エンジニアの坂元です。このブログはデータ基盤チーム/Unit9 ブログリレー 1 日目の記事です。 背景 はじめの一歩 独り立ち そして検証も… できたこと 残った課題 細かい工夫 全文読んでから対応すること セルフレビューしてもらう まとめ We are hiring! 背景 エムスリーのデータ基盤（BigQuery）上では数多のデータパイプラインが稼働しています。今回はそのうちの一部を dbt (data build

この記事はコンシューマーチームブログリレー5日目の記事です。 こんにちは。エムスリーのコンシューマーチームエンジニアの園田です。 以前のポストにもあるように、エムスリーでは GitLab から GitHub EE へ移行しています。 www.m3tech.blog コンシューマーチームで管理している GitLab リポジトリも、いくつか GitHub に移行しました。当然ですが、GitLab CI の CI/CD パイプラインは GitHub Actions に置き換える必要があります。移行前は「GitLab でできることは GitHub でもできるんでしょ？」と軽く考えていたのですが、実際に移行を進めてみると、想定外の制限や落とし穴に数多く遭遇しました。 本稿では、GitLab CI から GitHub Actions へ移行する際に直面したいくつかの課題と、それぞれの解決策を共有します

この記事はコンシューマーチームブログリレー4日目の記事です。 エムスリーエンジニアリングG コンシューマーチームの松原です。 今回はここ半年ほど開発支援として使っていた AI エージェントについて振り返ります。 自分の使い方としてはバリバリに使いこなしているわけではなく人並みに使っているというレベル感です。 それでも AI エージェントに助けられていると感じることがいくつもあったので、この記事でいくつか紹介したいと思います。 使用ツールの紹介 使っている AI エージェントですが、初期の頃は Cline を使っていて、Claude Code が盛り上がってきてからはほぼ Claude Code を使い続けています。その他にもチーム内では Devin が使われていたりして、様々なことに AI が使われてくるようになってきました。 当初は AI エージェントとのやりとりにのめり込みがちで、細か

本記事は、コンシューマーチームブログリレー 3日目です。 はじめまして。エンジニアグループ、コンシューマーチームの松本と申します。 本記事では、社内で開発・利用している内部ツールのフロントエンドを CoffeeScript + Backbone.js の構成から TypeScript + React の構成に置き換えた時の知見を共有できればと思います。 早速ですがまずは宣伝から 弊チームでは AskDoctors というサービスを開発しております。 「病気・症状のお悩みを実際の医師に聞ける」というサービスで、１つの質問に複数の医師から意見を伺うことができるサービスとなっております。実在の医師から意見をもらうことができるので、悩み事があればぜひ相談してください。 早速ですがまずは宣伝から 背景 当時は最先端だったAltJS 役目を終えたCoffeeScript 作業の手順 CoffeeScr

こんにちは。エンジニアグループQA （Quality Assurance） チームの中塚です。 この記事はコンシューマーチームブログリレー 2日目の記事です。QAエンジニアがリスク洗い出しをサポートする取り組みの事例をご紹介します。 はじめに エムスリーでは、チーム全員で品質保証に取り組む考え方のもと、QAエンジニア以外のメンバーも品質保証に積極的に取り組むチャレンジをしています（この取り組みを社内では「全員QA」と呼んでいます） ちなみに取り組み内容についてはこちらの記事でより詳しく紹介しておりますので、ご興味のある方はぜひ読んでいただけますと幸いです。 www.m3tech.blog この取り組みには次のような狙いがあります。 開発と品質保証を担当エンジニアが一貫して行えることでリリースを早くできる 今はQAエンジニアのフルアサインができていても、将来的に新プロジェクトの立ち上げ時にア

こんにちは。エンジニアリンググループ プロダクト支援チームでプロダクトマネージャーをしている中村です。 既存プロダクトを担当しているPdMにとって、どうやって次の非連続な成長（＝Step Change）を起こせるかというのは、重要な課題だと思います。 私はこれまでPdMとして、既存プロダクトのグロースに携わることが多く、KPIを伸ばすためにデータ分析をし、仮説検証をしながらプロダクトを連続的に成長させる（KPIを120%〜130%伸ばす）経験を積んできました。さらにPdMとしてより事業成長に貢献するためには、次の非連続な成長（KPIを2倍にするなど）を生み出したいと考えていました。 そんな時に、ある担当プロダクトにおいて、主要KPIを2倍に伸ばすというミッションに取り組む機会を得ました。CPO山崎と一緒に主要KPIを2倍に伸ばすためのチャレンジに取り組む中で、超一流のPdMがどのようにデー

はじめに エムスリーテクノロジーズの永江 (@yukinagae)です。 最近はAIエージェントを使った開発が当たり前になってきました。CLIだけでもClaude Code / Gemini CLI / Codex CLI など多くのツールが登場し、開発効率の向上を日々実感しています。実際、Claude Codeを使うと趣味開発のスピードが数倍に上がり、1週間かかるものが数時間で完成することもあります。 さらに、コーディング用途だけでなくDia / Comet / Gemini in Chrome といった、ブラウザとAIが一体化したツールも次々と登場しています。エンジニアリング以外の業務効率化も、これから一段と加速していきそうです。 自分自身もプライベートでDiaを使い始め、その便利さを感じ始めています。そこで試しに、Chrome拡張でDiaのようにサイドパネルからAIを使えるプロトタイ