はてなブックマーク

はじめに こんにちは。Musubi Insightチームでエンジニアをしている中村です。 Musubi Insightでは、SaaS型のE2Eテストツール mabl で14のテストを運用していましたが、認証の安定性やコード管理の面でいくつか課題がありました。 昨今のフロントエンド開発では Claude Code などのAIエージェントと Playwright MCP を組み合わせ、コード修正から動作確認までをPlaywrightベースで回すワークフローが選択肢として広がりつつあります。こうした背景もあり、チームでPlaywrightへの移行を進めることになりました。 本記事では、移行にあたってのテストアーキテクチャの設計と実装パターン、移行の進め方について紹介します。 Musubi Insightについて Musubi Insightは薬局向けのBIツールで、処方データや薬歴データを集計・

長い前置き おはようございます。カケハシのPE新規サービス開発チームというところでソフトウェアエンジニアをやっているogijunこと荻野です。最近この技術ブログはAIの話題が多めなので、ここから言語オタク語りが始まってしまうのはいいのか？とか思いますが、かまわず書きたいと思います。 前置きとして、わたしたちのチームではその名の通り新規事業のプロトタイプをよくやってます。その際には、なるべくサクサク実装して仮説検証を短いサイクルで回すために、社内の既にあるいろいろなプロダクト基盤を間借りしながら機能追加をさせてもらって実験を繰り返しています。 なので、気がつくと多数あるカケハシプロダクトの統一されていない環境、たとえば TypeScript も Python も触るし、Python だけをとっても FastAPI / Django / Pyramid (!) などなど多岐にわたって触ることに

はじめに こんにちは。Pocket Musubi開発チームでSREをやっている石井です。 突然ですがみなさん、問い合わせ対応してますか？　大変ですよね。 ではもうひとつ。対応のあとにちゃんと記録を残せてますか？ 私はできてませんでした。 調査後には散らかったメモと、Slackのスレが１つ残るだけです。来月の私がそれを読んでも、きっと何をやって、どう解決したのか全然わからないと思います。 対応することも大変なのですが、対応の後もかなり大変。 「また同じ問い合わせが来たとき困るから記録残さないと」「ナレッジにまとめないと」。頭ではきちんとわかっている。わかってるけど手こずった問い合わせほど対応後にはもうヘトヘトで書く気力がない。通常業務の合間に割り込みで対応してるから、書く時間もない。でも問い合わせの負荷を減らすために、「書かないと」と心では思いつつ、結局そのまま放置。そして放置した分だけ心に

カケハシでの社内講演に、さくらインターネット株式会社の藤原俊一郎氏（@fujiwara）をお招きしました。「パフォーマンスチューニングのために普段からできること」というタイトルで、具体的な失敗談や現場の思考プロセス、そしてチューニングの本質についてお話しいただきました。 社内向けの場ではありましたが、貴重なお話をお伺いできたため、ご本人の許可を得て外部向けにまとめました。 当日は、前半を講演編、後半を対談編として構成し、対談パートにはカケハシのテックリードである松山も参加しました。 講演編：「パフォーマンスチューニングのために普段からできること」 なぜパフォーマンス問題は突然「死」を呼ぶのか グラフが改善したりISUCONで勝ったりする瞬間は「ものすごく楽しい」ものですが、一方で現在進行形でサービスが死んでいる状況は「めっちゃ楽しくない」ものです。長年育てたサービスが落ちることは、「自分の

Pocket Musubi開発チームで開発ディレクターをしている松本です。 前回の記事「既存システムへの仕様駆動開発ツールの選定・導入・運用」では、Pocket MusubiチームのOpenSpecを用いた仕様駆動開発の取り組みをご紹介しました。OpenSpecは仕様駆動開発を支援するツールで、ツールの詳細や選定の背景については前回記事をご参照ください。 上述の記事で紹介されている仕様駆動開発により、仕様をSingle Source of Truth（信頼できる唯一の情報源）で管理できるようになったことで、生成AIを用いた次なる効率化の兆しが見えてきました。それがQAフェーズの効率化です。 本記事では、Pocket MusubiチームのQAメンバーと取り組んだ、仕様書からテストケースを自動生成する仕組みについて紹介します。 取り組みの背景 Pocket Musubi開発チームは体制面でスケ

生成AI研究開発チームのainoyaです。 生成AIを活用したコーディングが当たり前の日常になってきた昨今ですが、その強大な力と引き換えに、開発の現場に影を落とす課題も増えてきました。 これまでは考えられなかった速度でコードが生成される一方で、それを受け止める人間の側には「レビュー疲れ」という弊害が生じています。コーディングの速度が上がった結果、人によるレビューの負荷が過剰になりつつあるのです。また、AIが生成するコードの質も無視できない問題です。仕様を満たし動作はするものの、あくまで「その場しのぎ」の実装に留まり、長期的な保守性を損ねたり、チームの実装方針にそぐわないスタイルが紛れ込んだりすることで、コードベースが徐々にカオス化していく懸念があります。 これらは「AI疲れ」として広く認知され始めていますが、放置すればチームの認知負荷はいたずらに消費されるばかりです。コードの出力量は増えた

はじめに こんにちは、カケハシでHoE(Head of Engineer)をやっている小田中です。2023年10月に入社してから、はや2年。「日本の医療体験をしなやかにする」を実現するための濃密な日々は自分自身を大きく成長させてくれている、と日々実感しています。今年のアドベントカレンダーでは、「マネージャーがボトルネックにならないチームづくり」をテーマに筆を執りました。 エンジニアリングマネージャーに求められること カケハシでは、エンジニアリングマネージャー（以下、EM）に期待することをCTOのゆのんさんが言語化してくれています。 正しい方法で短期的な事業成果を追求する チームの活動に明確な意思決定を行う チームの活動を説明できる状態を保つ Disagree and Commitの姿勢で臨む 属人化を避け、仕組みで解決する 個人の強みを引き出して活かす パフォーマンスについて明確なフィード

こちらの記事は カケハシ Advent Calendar 2025 の 16日目の記事になります。 はじめに Pocket Musubiチームでソフトウェアエンジニアをしている牧野です。 私たちのチームでは、既存システムへの機能追加のプロジェクトにおいて仕様駆動開発（Specification-Driven Development）を行っています。 本記事では、ツールの導入検討から実際の運用、チーム全体での学習プロセスまでを具体的に紹介します。 仕様駆動開発とは 仕様駆動開発は、仕様書(spec)を起点として開発を進める手法です。仕様書をSingle Source of Truth（信頼できる唯一の情報源）として扱い、そこから一貫性のある成果物(設計書、タスクリスト、コード等))を導出することで、仕様と実装の乖離を防ぎます。 AIを活用したコーディングが一般的になる中で、この仕様駆動開発の

こちらの記事は カケハシ Advent Calendar 2025 の 14日目の記事になります。 はじめに こんにちは、kosuiこと岩佐 幸翠(@kosui_me)(id:kosui_me)です。カケハシで認証基盤・ライセンス基盤・組織階層基盤などのプラットフォームシステムを開発・運用する認証・権限管理基盤チームのテックリードをしています。 認証・権限管理基盤チームではサーバサイドTypeScriptにて基盤システムを開発・運用し、利便性にフォーカスしたTypeScriptの型システムをうまく活用しながら、堅牢で拡張性の高いシステムを目指しています。以下の記事もぜひご覧ください。 課題 TypeScriptでテストを書いていると、事前に定義したダミーデータを使おうとして型検査エラーになることがあります。 例えば、 ダミーユーザーのメールアドレス dummyUser.email を参照し

はじめに こんにちは、PocketMusubiチームでエンジニアをしている南光です。 こちらの記事は カケハシ Advent Calendar 2025 の 9日目の記事になります。 さて、Datadogのモニター（アラート）設定、こんな経験はありませんか？ 「閾値、とりあえず10件にしておくか...」 「この設定、なんでこの値なんだっけ？」 「レビューで指摘したいけど、自分も正解がわからない」 監視設定には明確な正解がありません。サービスの特性、運用体制、SLAによって適切な値は変わります。そのため、設定が属人化し、レビューも「なんとなくOK」になりがちです。 この問題を解決するために、2つのアプローチを組み合わせました。 Terraform管理 - モニター設定をコード化してレビュー可能にする Claude Codeとの対話 - 設定の根拠を言語化する 本記事では、このアプローチを使っ

こちらの記事は カケハシ Advent Calendar 2025 の 4日目の記事になります。 はじめに 生成AI研究開発(GenAI)チームでソフトウェアエンジニアをしている坂尾です。 私たちのチームでは、生成 AI を利用したサービスを開発しています。このサービスでは、Google の Gemini や AWS の Bedrock など、外部 LLM サービスを利用しています。 なお、外部 LLM サービスの利用にあたっては、カケハシでは社内ガイドラインに基づいた厳格なガバナンス体制を設けています。具体的には、CoE（Center of Excellence）組織を中心に、学習データへの業務情報利用の禁止、セキュリティ要件の確認、利用規約の検証など、複数の観点から審査を実施しています。詳しくは、こちらの記事で紹介していますので、ご関心のある方はぜひご覧ください。 外部の LLM サー

こんにちは、椎葉です。カケハシでVPoT(VP of Technology)をやっています。今日は、僕が使っているCursorのカスタムコマンドを2つ紹介します。 カケハシではコーディングエージェントとして、Cursor、Claude Code、GitHub Copilot、そしてDevinを利用できます。その中で僕はメインではCursorを使用しています。最近だと、Cursorを使ってTerraformによるAWSのインフラ構築をやっていて、便利だなーと思っています。 そんな日々の作業の中で、コミットとプルリクエストの作成をよく実施しているので、その2つをCursorのカスタムコマンドとして登録してみました。まだまだブラッシュアップ中ですが、わりと便利に利用できているので紹介します。 Cursorのコマンド Cursorの「コマンド」とは再利用可能なプロンプト定義です。チャットウィンドウ

こんにちは、カケハシのCTOのゆのん(id:yunon_phys)です。カケハシではEngineering Manager（EM）に期待することを、特にリーダーシップとチームマネジメントの側面にフォーカスして言語化し、行動や言動に対して組織全体として一貫性のあるようにしています。本記事では、その期待することを社外公開用にリライトしたものです。 組織によって文化や価値観は異なりますが、EMに求められる役割について一つの視点として参考にしていただければ幸いです。 1. 正しい方法で短期的な事業成果を追求する 「正しい」という言葉の定義はコンテキストによって変わりますが、ここでは誰かが理不尽な思いをすることがない、フェアである、カケハシのバリューの1つである高潔さを保つといった意味を想定しています。組織における公的な存在として、EMは信念を持って行動する必要があります。 事業成果を最初に挙げてい

「このライブラリのサポートいつまでだっけ？」「Lambda ランタイムの EOL っていつだったかな？」 システム運用をしていると、こんな疑問がよく浮かびますよね。サービス・ライブラリの EOL を皆さんはどうやって管理しているでしょうか。 なぜEOLチェックが重要なのか EOL（End of Life）を放置すると、セキュリティ・運用・ビジネスのリスクが高まります。 セキュリティ: サポート終了によりセキュリティパッチが止まり、新規脆弱性が修正されなくなる可能性があります。 運用: サポート切れでトラブル対応が困難になり、互換性やテストコストが増えます。 ビジネス: インシデントやサービス停止は機会損失や信頼低下につながります。 EOL と脆弱性の違い EOL（End of Life）と脆弱性は混同しやすいので簡潔に違いを示します。 EOL（End of Life）: ソフトウェアやサー

はじめに こんにちは。カケハシで開発ディレクターをしている笹尾です。 こちらの記事は『Musubi AI 在庫管理開発チームの品質向上ハンドブック』の PDF 版公開の記事となります。 (ダウンロードのリンクは記事の後半にあります) 今回公開するハンドブックはMusubi AI 在庫管理開発チームが日々のプロダクト開発・保守・運用の中で実際に利用・実践している取り組みをまとめたものです。一部にカケハシ特有の状況に基づいた記述もありますが具体的なプロダクト情報は最小限に留めて記載されています。 この中で私たちがどのように 「状態ゴール」 を意識し、アジャイルかつリーンに「フローを重視する」姿勢で取り組んできたか。特に「不確実性を優先的に排除する活動」を通じて、いかに「顧客利益と業務運用を中心に」価値を最大化してきたかなど、多くのチームにとって参考になる内容だと思います。 また、このハンドブッ

こちらはKAKEHASHI Tech Blogでございますが、技術イベントで配布するノベルティに関連する内容ということでご紹介をさせていただきます。カケハシは「日本の医療体験を、しなやかに。」をミッションに掲げ、患者さんのための薬局づくりのパートナーとして複合プロダクトで薬局DXをトータルサポートしているヘルステックスタートアップです。 ここ1年ほどはカンファレンスや勉強会などの技術イベントにおいて、「コーヒースポンサー」として高品質なコーヒーの提供を行っていることでも知られています。 今回は、カケハシがスポンサーする技術イベントのスポンサーブースでお配りするドリップバッグコーヒー「カケハシブレンド」の、ご家庭で実践できる美味しい淹れ方をご紹介します。 ※違う豆にはなりますがデカフェ版もご用意しています カケハシがなぜコーヒースポンサーを続けているのかは、こちらのエントリをご参照ください。

こんにちは、患者向けサービス開発チームでエンジニアをしている種岡です。 カケハシでは社内で生成AIを活用した取り組みが活発に行われています。 生成AIは、もはや単なる効率化ツールではありません。ユーザーへ最速で価値を届けるための「強力な相棒」です。 本記事では生成AIを活用し、仕様検討からプロトタイプ作成までを高速で実現した事例を、具体的な手順を交えてご紹介します。 新規事業開発における３つの課題 所属しているチームは新規事業開発ということもあり、以下の課題に直面することが多いです。 変わりやすい要件 : 日々の情報収集で仕様が固まらず、開発着手のタイミングを見極めるのが難しい 技術課題へのリスク : 実際に開発してみないと、どこに技術的な難所があるか分からない 不正確な見積もり : 前例がないため、工数の見積もりが大きくブレやすい 高い不確実性への対策としてのプロトタイプ開発 チームでは

はじめに こんにちは、岩佐 幸翠(@kosui_me)です。カケハシで認証基盤・ライセンス基盤・組織階層基盤などのプラットフォームシステムを開発・運用する認証権限基盤チームのテックリードをしています。 TypeScriptのクラス構文は、一見するとJavaやC#などの言語と非常に似ていますが、その背景にあるJavaScriptの特性により、振る舞いに重要な違いが存在します。これらの違いを理解することは、これまでの経験を活かしつつ、TypeScriptで堅牢なアプリケーションを構築する上で非常に重要です。 本記事では、主にJavaやC#など、クラスベースの静的型付け言語に慣れ親しんだエンジニアの方々を対象に、TypeScriptでクラスを扱う際に特に留意すべきポイントを解説します。さらに、クラスを用いない関数型のアプローチについても触れ、TypeScriptにおけるドメインモデリングの多様な

1. はじめに こんにちは。生成AI研究開発チームでAIエージェントの開発をしているNokogiri（@nkgrnkgr）です。 薬局向け業務システムMusubiはAngular製のWebアプリケーションです。このMusubi上で動作するAIアシスタント機能をReactで開発することになりました。Angular製の親アプリケーション（Musubi）とReact製の子アプリケーション（AIアシスタント）という異なるフレームワークが共存する特殊なアーキテクチャとなったため、両者の通信にはカスタムイベントを採用しています。 この記事では、TypeScriptの型システムを活用してカスタムイベント通信を安全に実装し、テスト可能にした方法を紹介します。実装の中で工夫した点やハマったポイントを共有することで、同じようにカスタムイベントを使おうとしている方の参考になれば幸いです。 2. 型定義で通信仕様

こんにちは、椎葉です。カケハシでVPoT（VP of Technology）をやっています。技術的な視点で現場と経営をつなぐ活動の一つとして、実際にチームに入って開発業務をサポートしています。今日はその中のひとつの事例を紹介します。 Pocket Musubiチーム 今年の6月からPocket Musubiチームのみんなと一緒に開発業務に取り組んでいます。Pocket Musubiは、薬局と患者さんをつなぐ「服薬フォローシステム」です。Musubi電子薬歴と並んで、カケハシの中でも主要なプロダクトのひとつになっています。 チームはエンジニア5名、SRE2名、QAエンジニア3名をはじめとした10数名のメンバーで構成されており、少人数でさまざまな案件を進めています。そんなチームが少し悩んでいそうだったので、サポートへ入ることにしました。 「いいチームだなぁ」 最初の1スプリントは、デイリースク

はじめに 生成AI研究開発チームでソフトウェアエンジニアをしている坂尾です。 カケハシでは製品として生成AIを活用するのはもちろんですが、業務の中でも活発に生成AIを利用しています。今回は、生成AIを活用して内部ツールを効率的に開発した事例をご紹介します。 内部ツール開発のジレンマ 開発や運用作業をする上で、管理画面などの内部ツールの開発をすることも多々あります。例えば、運用するための管理画面やfeature flagを設定するデバッグ機能などです。 しかし、これらは「あれば便利」だよねというものも多く、直接的な利益を生むわけではないため、以下のような課題があります： エンジニアリングリソースは製品の開発に集中させたいため、優先度が下がりがち 工数が取れていざ取り掛かろうとした時にはモチベーションが下がってしまいがち コードは書いた瞬間から負債となるため、最低限にしたい。必要なものを見極め

はじめに 処方箋データ連携チームでエンジニアをしている岩佐（孝浩）です。 カケハシには「岩佐」さんが複数名在籍しており、社内では「わささん」と呼ばれています。 私が所属する処方箋データ連携チームでは、これまで Slack App を用いて社内管理画面を構築・運用してきました。 しかし、運用を続ける中でいくつかの課題が明らかになってきたため、現在は Lambda Web Adapter を利用した Web アプリケーションへの移行を進めています。 本投稿では、Slack App から Web アプリケーションへの移行に至った背景と、移行前後のシステム構成についてご紹介します。 移行の背景 Slack App 選定の経緯 Slack App の構築当初、私はまだカケハシに入社していませんでしたが、チームのメンバーからのヒアリングによると、以下のような理由から Slack App が選定されたよ

ヘルステックスタートアップであるカケハシは、シリーズDで累計150億円の資金調達を実施しました。 カケハシ、約140億円のシリーズDラウンドを実施 | 株式会社カケハシのプレスリリース ベンチャーデットを活用した資金調達を実施 | 株式会社カケハシ - 日本の医療体験を、しなやかに。 プレスリリースにもあるように、新技術への投資や事業推進を見据えた人材への投資を積極的に実施します。組織基盤の強化やプロダクトの拡充による当社プラットフォームの拡大を加速し、次世代ヘルスケアの推進を通じた日本の医療課題解決を目指します。 難しい、でも誰かがやらなきゃいけない医療という社会課題の解決 少子高齢化が進むにつれて、日本の医療需要は増加の一途をたどっています。それに伴い、国の財政構造における社会保障費の割合は膨らむ一方。解決の見えないこうした財政構造の課題を背景に、国民皆保険制度を基盤とする日本の医療制

カケハシでの社内講演に、株式会社一休 執行役員CTOの伊藤直也氏をお招きしました。同社がどのようにレガシーシステムから脱却し、事業リスクを抑えながらRust/Go/TypeScriptを使い分けてきたのかお話を伺いました。社内向けの場ではありましたが、非常に有意義だったためご本人の許可を得て外部向けにまとめました。 当日は、医療変革プラットフォーマーを目指すカケハシのチーフアーキテクトである木村彰宏との対談形式でお話を伺い、ファシリテーターはカケハシのテックリードである松山が務めました。 松山： 本日は宜しくお願いします。まず、一休での関数型プログラミングの導入の背景についてお聞かせください。 伊藤： 実は、最初から TypeScript による関数型プログラミングを目指していたわけではなく、結果的にそうなったという方が近いです。参照透過性などへの強いこだわりよりも、「型がちゃんと効いてる

こんにちは、椎葉です。2025年3月にVPoT(VP of Technology)に就任しました。しなやかな医療体験の実現に向けて、カケハシの技術全体を見ながら取り組んでいきます。今回は、どうしてVPoTという役割が生まれたのか、実際に何をやっているかについてお話しします。 先週、CTOの湯前とチーフアーキテクトの木村とのインタビュー記事が公開されましたので、こちらも合わせてご覧ください。 なぜVPoTという役割が生まれたのか カケハシにはCTOがいるのに、なぜVPoTという役割を新たに作ったのでしょうか。それは、CTO湯前の「現場の感覚をもっと経営につなぎたい」という思いからです。 湯前は開発組織の代表として、技術的な視点で企業価値を最大化させることにミッションを持っています。そのために、社外や他部署との連携、組織づくりなど開発組織内の運営、そしてカケハシの技術全体を前進させる役割を担っ

こんにちは、技術広報の櫛井です。 カケハシではカンファレンスや勉強会などの技術イベントにおいて、「コーヒースポンサー」として高品質なコーヒーの提供を行ってきました。 カケハシは「日本の医療体験を、しなやかに。」をミッションに掲げ、患者さんのための薬局づくりのパートナーとして複合プロダクトで薬局DXをトータルサポートしているヘルステックスタートアップです。 カケハシがコーヒースポンサーにこだわっている理由、どのように実現しているのかをこのエントリではご紹介したいと思います。 人と人をつなぐ、コミュニケーションのきっかけに 私たちが技術イベントでコーヒーを提供する最大の目的は、参加者同士の交流を促進することにあります。コーヒーを手にすることで自然と会話が生まれ、異なる分野の専門家同士が出会い、新たなアイデアが生まれる場を創出しています。 イベントの休憩時間やセッションの合間。緊張感の中で思考を

はじめに こんにちは。 電子薬歴 Musubi の基盤開発チームで SRE を担当している大山です。 カケハシでは生成 AI の活用を丁寧に推進しています。 具体的な体制や方針については🗒️ 薬局DXをリードするカケハシは社内で生成AIをどのように活用しているのか?をご参照ください。 Musubi SRE チームでも生成 AI を導入し、業務効率化や生産性向上に大きな効果を感じています。最初は「便利そう」という印象でしたが、今では「活用しない選択肢はない」と考えるほどインパクトがありました。本記事では、生成 AI を活用した具体的な事例を 4 点ご紹介します。 対象となる読者 SRE がどのように生成 AI を活用しているのか知りたい方 Devin や Cursor を Terraform で使うとどう嬉しいのか興味がある方 NotebookLM で AWS ドキュメントを読み合わせると

ユーザー理解って大変 こんにちは。データが好きすぎる梶村です。 カケハシで薬局向けの在庫管理発注システムである「AI在庫管理」というプロダクトのPdMをしています。 プロダクト開発ではユーザー理解が一番大事だと分かっていても、実際に取り組むのは本当に大変です。薬局向けのプロダクトでは、店舗によって医薬品の在庫管理の運用や発注判断はさまざまであり、定性的にさまざまな店舗の方にヒアリングさせていただきながら、定量的に機能の利用状況を調査していくのは大変な作業です。 一方でPdMがヒアリングできる店舗や業務は限定的なので、営業やCSが認識している薬局の温度感とずれが生じてしまうと、「開発チームはユーザーを理解しているのか？」という信頼感にも影響してしまいます。 そんな中で生成AIやさまざまなツールを活用しながらユーザー・プロダクト理解を実現する取り組みを紹介したいと思います！（PRD/PBIの自