はじめに この記事は メドレー夏のブログリレー 2025 21 日目の記事です。 医療プラットフォーム本部 プラットフォーム開発室 SRE グループの山田です。 医療機関向け SaaS である CLINICS の安定稼働とシステム信頼性の向上に取り組んでいます。 SREグループは開発組織全体の中でも比較的少人数のチームです。 そのため、腰を据えて事業やプロダクトに中長期的な価値を生む時間を作るためにも、トイルの削減に力を入れています。 繰り返し作業や自動化が可能なタスクを効率化する上で、AWS Step Functionsは非常に強力なサービスです。 本記事では、AWS Step Functions を活用し、1000を超えるデータベースのマイグレーション作業を自動化した事例を題材に、Step Functionsの 実践的な活用方法（tips） についてご紹介します。 メンテナンス作業のおおまかなワークフロー DBのバックアップ（スナップショットを作成） DBマイグレーションを実施 マイグレ後のDBスキーマチェック ECS Task（アプリケーション）のデプロイ 完了/失敗通知を飛ばす 更新手順としてはごく一般的なワークフローかと思います。 しかし、手順2で大量のデータベースをどのようにして夜間で更新しきるのかが課題となりました。 プロダクトの成長とともにデータベースの数が増えていくという特性上、なるべく変更管理の手間がかからない仕組みを導入しなくてはなりません。 Step Functions を用いたアプローチ SREチームでは上述した課題に対して Step Functions によるメンテナンスを自動化することにしました。 AWS Step Functions とは？ ここでは、詳細な説明は割愛しますが、AWS Step Functions は複数のAWSリソースやサービスを統合してワークフローを構築するためのサービスです。 lambda で実装するには処理が複雑だったり処理時間が15分以上かかる場合、Step Functionsが選択肢となります。 （AWS Step Functions は最大1年実行が可能） 1. Map ステートを活用する Map ステートは同一ワークフローに異なる入力を与えてタスクを並列実行する（動的並列処理）機能です。 Map ステートに与える入力を増やす/減らすことでワークフローを変更することなく並列実行するタスクをスケールさせることができます。 これにより、大量のDBマイグレーションを同時に実行しメンテナンス時間の短縮をしただけでなく、変更に強いワークフローを構築することができました。 ワークフローの処理内容 各ブランチのマイグレーションタスクがどのDBのマイグレーションを実施するのかリストを作成（画像では3並列なので1 Taskあたり約333DBのマイグレーションを実行するように振り分け） 複数のECS Taskを立ち上げてマイグレーションを実施 DBスキーマをチェックして問題ないか確認 ※各ステートごとにlambdaを用意すると管理しづらくマイグレーション処理も15分以上かかるため、メンテナンス作業用のコンテナイメージを別途、用意しています。 2. .sync を用いてDBマイグレーション完了まで待機させる Step Functions では通常サービスを呼び出すと次のステートへ遷移しますが、 .sync を用いることでジョブが完了するまで状態遷移を待機させることができます。 "更新対象のDBリストを作成": { "Type": "Task", "Next": "DBマイグレーションを実行", "Resource": "arn:aws:states:::ecs:runTask.sync", "Arguments": { /* 省略 */ }, "Catch": [ { "ErrorEquals": [ "States.ALL" ], "Next": "更新処理の失敗を通知" } ] }, 上記のように記述することで、更新対象のデータベースリストを作成するECS Taskが終了しないと、次のステート「DBマイグレーションを実行」へ遷移しないようになります。 ジョブ完了状態のポーリングは DescribeTasks , ChoiceState , WaitState の組み合わせでも可能ですが、Step Functions は状態遷移回数によってサービス利用料が計算されるため、コスト的に優しくありません。 ただし、すべてのAWSサービスで .sync が利用できるわけではないので注意が必要です。 参考： 最適化されたサービスと Step Functions の統合 実装時に意識したこと 1. ビジュアルエディタを活用する AWS Step Functions のワークフローはJSON形式で定義する宣言型の Amazon States Language (ASL) で記述します。 シンプルなワークフローであればASLで書かれたワークフローを読むのもそこまで苦ではありませんが、分岐が複数あったり複雑なワークフローだと辛くなってきます。 そこで、役立つのがビジュアルエディタです。 Step Functions のビジュアルエディタにはデザインモードとコードモードが存在します。 デザインモードを活用することで、ワークフローの構造をビジュアルで確認することができます。 デザインモード ドラッグ＆ドロップでアクションやフローを配置してワークフローの構築ができます。 コードを書く必要がなく直感的に操作することができます。 コードモード ASLでワークフローを編集することができます。 他のStep Functionsワークフローをコピペして組み込んだりする時には便利です。 ASLの構文エラーはエディタから確認することができるので、間違いに気がつくことはできます。 2. TestState API を使い倒す ワークフローを構成する各ステートは TestState API で単体テストが可能です。 特に参照系APIの戻り値をテストしたりJSONataのような書き慣れないクエリ構文のチェックに利用します。 ただし、処理完了するまで待機する .sync やコールバックが返却されるまでStep Functionsが待機する .waitForTaskToken といったステートはTestState APIをサポートしていないため、その場合は .sync や .waitForTaskToken を外して検証します。 まとめ 本記事では、Step Functions を活用した運用トイル削減の取り組みとそこで得たTipsについて紹介しました。 少人数のSREチームにおいて、手作業による運用コストの削減は重要な課題です。 Step Functions を使用することで、以下の成果を得ることができました： 定量的効果 : 月6時間、年間72時間の工数削減 定性的効果 : ヒューマンエラーの排除と心理的負荷の軽減 組織的効果 : より価値の高い業務への時間投入が可能 特に、視覚的なワークフロー管理機能により、チーム全体での理解と保守性が向上したことは、持続可能な運用自動化において重要な要素でした。 今後も、運用業務の中で反復的に実施している作業を見つけ出し、Step Functions をはじめとしたAWSサービスを活用した自動化に取り組んでいきます。 これにより、SREとしてのCLINICSの安定性と信頼性をさらに向上させていきたいと考えています。 次回は、医療プラットフォーム本部 桶谷さん・小島さんの、「生成AI時代に向けて、開発効率10xを支えるリリース戦略の見直し」です。お楽しみに。 メドレーではエンジニアを積極採用中です！ メドレーでは、SREをはじめ「医療ヘルスケアの未来」を共に創っていくエンジニアを大募集中です！少しでもご興味をお持ちいただけましたらぜひ、ご応募お待ちしております！ 株式会社メドレー エンジニア の求人一覧 株式会社メドレー エンジニア の求人一覧です。| HRMOS hrmos.co ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

こんにちは、人材プラットフォーム本部CTO室の奥澤です。2025年9月、株式会社メドレーに入社して人材プラットフォーム本部へ配属されました。メドレーの人材プラットフォーム本部では既に複数のモバイルアプリを開発していますが、モバイルアプリ開発をさらに加速させていくためにジョインしました。 さて、9月に入って8月ほどの暑さはなくなり、夏の終わりを感じています。そして例年、自分にとって暑い夏の終わりと秋の始まりを告げるイベントである、DroidKaigiに今年も参加してきました！DroidKaigiは、日本国内で最大級のAndroidに関するカンファレンスです。 株式会社メドレーは、2025年9月10日から12日にかけて開催された、DroidKaigi 2025にSupporters Sponsorとして協賛しました。メドレーでは2021年からDroidKaigiに協賛しており、今年で5回目の協賛となっています。メドレーでは、DroidKaigiなどの技術カンファレンスへ継続的に協賛し、技術コミュニティを支援しています。 本記事では、DroidKaigi 2025の会場の様子と共に、印象に残ったセッションを紹介します。 会場の様子 DroidKaigi 2025は、ベルサール渋谷ガーデンで開催されました。DroidKaigi 2023から同じ会場で開催されています。今年も元気に会場にやってきました。 地下1階に設けられたコミュニケーションエリアには、協賛している各企業のブースが出展されていました。ブースを周り、各企業の話を聞いて歩くのはカンファレンスの大きな楽しみですね。それぞれの会社 / アプリの取り組みについて学び、さらに中の人に詳しい話を聞くことができるのは良いですね。 今年も気合いを入れてスタンプラリーをコンプリートしました。大量にノベルティもいただいたので、家族へのお土産になりました。全部のノベルティが嬉しいものですが、特に印象に残ったノベルティは、株式会社TVer様のタンブラー（かっこいい）、KINTOテクノロジーズ株式会社様のコースター（かわいい）、株式会社メルカリ様のキーキャップ（さっそく使ってます）でした。 セッションの様子 私がリアルタイムで聴講したセッションの中で、印象に残ったいくつかのセッションとその感想を紹介します。 共有と分離 ─ Compose Multiplatform “本番導入” の設計指針 Kotlin Multiplatform（KMP）は、ここ数年で盛り上がっているクロスプラットフォーム技術で、ロジックをプラットフォーム間で共通化することができるものです。さらに、Compose Multiplatform（CMP）を用いることで、UIも共通化することができます。KMP / CMP、あるいはクロスプラットフォーム技術において、OSの境界をどう引くか？をいかに設計すれば少人数で生産性高くアプリを開発できるのか、という点に興味を持ちました。 本セッションでは、KMP / CMPとそのエコシステムの現状・限界を見極めながら、その本番導入を進めていった過程とその結果を発表されていました。最終的に約90%のソースコードをOS間で共有することができたそうですが、ネイティブで提供できる高品質な触り心地と、ソースコードの共有によって実装効率の向上を両立できた点は素晴らしいですね。 共有と分離 ─ Compose Multiplatform “本番導入” の設計指針 Kotlin Multiplatform (KMP) は、ネットワーク通信やドメインロジックを Android / iOS で共通化し、Compose Multiplatform (CMP) はそのうえ UI までを共通化します。両者を組み合わせれば、アプリの大部分を単一のコードベースで開発できることが大きな魅力です。 ところが実プロダクトへの導入に踏み出すと ・使いたいライブラリや SDK が KMP に非対応 ・OS 固有の API を直接呼びたい ・一部の画面をネイティブ UI でリッチに作り込みたい といった理由で、 ”共有できない領域” が必ず現れます。 本セッションでは、Android と iOS のエンジニアが共同登壇し、 ・プラットフォーム間でコードのどこを共有し、どこを分離するのか ・開発速度 × ユーザ体験 を両立させる設計・実装パターン を具体例とともに紹介します。実際に CMP を採用して半年弱で Android / iOS 両アプリをリリースしたプロダクトを題材に解説します。 予定しているトピック： ・共有の最前線 　CMP + KMP 対応ライブラリの活用でどこまで共通化できるか ・分離のテクニック 　・Kotlin × Swift の DI 設計 　・KMP に非対応の SDK の安全な統合 　・CMP + ネイティブ UI のハイブリッド実装 ・両プラットフォーム視点で見る落とし穴と回避策 CMP 導入で必ずぶつかる ”共有できない領域” を見極め、必要に応じてコードを切り離すための指針をお伝えします。 2025.droidkaigi.jp スマホ新法って何？１２月施行？アプリビジネスに影響あるの？ 2025年12月18日に施行される、「スマートフォンにおいて利用される特定ソフトウェアに係る競争の促進に関する法律」、いわゆるスマホ新法またはスマホ法について、公正取引委員会の方のセッションがありました。スマホ法の趣旨、スマホ法の施行によって何が変わるのか、スマホ法の施行によるアプリデベロッパーへの影響など、わかりやすく説明いただきました。 規制対象となる指定事業者に属していないエンジニアにおいても、スマホ法の施行によって今後どのようなことが起こっていくのか？しっかり理解しておいた方が良さそうだと感じました。セッションに参加したことで興味・理解が深まりました。 スマホ新法って何？１２月施行？アプリビジネスに影響あるの？ 今年１２月に施行が予定されている新しい法律、スマホソフトウェア競争促進法（スマホ新法）。 この法律がアプリビジネスにどのような影響を与えるのか、エンジニアのみなさまにどんな関係があるのか、公正取引委員会の担当者が解説します。 例えば、 ・OS機能（通信機能等）の利用可能性の向上 ・新たなアプリストアの登場など決済手段の多様化 ・ウェブサイト等のアプリ外での商品提供の拡大 ・ソフトウェアの切替え時におけるデータ移転の円滑化 ・ユーザーによるブラウザや検索サービスの選択の促進 などなど、これから見込まれる「変化」について説明します。 2025.droidkaigi.jp Surviving Network Failures: Building Resilient Offline-First Flutter Apps モバイル端末はネットワークが不安定な場所で使われることも多々あります。ネットワークが不安定な状況においてもアプリを使い続けられることは、ユーザーの体験として非常に重要であると考えます。そのためには、「オフラインファースト」でアプリの体験を設計することが必要になり、同時にオフラインファーストな体験を実現するための技術的な戦略も描く必要があります。 このセッションでは、オフラインファーストなアプリの体験を実現するためのUX / 技術的な戦略を提案しています。サンプルコードはFlutter / Dartですが、おおまかな内容はフレームワークによらず参考にできるものでした。セッションの内容については触れませんが、オフラインファーストでアプリの体験 / アーキテクチャを設計するためのガイドラインとなるセッションだったと感じています。 Surviving Network Failures: Building Resilient Offline-First Flutter Apps What happens when your app loses internet, does it gracefully adapt, or does it leave users frustrated? In a world where connectivity is unpredictable, building offline-first apps isn’t just a feature; it’s a necessity. In this talk, we’ll explore battle-tested strategies to keep your Flutter app running smoothly, even in airplane mode. You’ll learn: Caching Like a Pro – Choosing between SQLite, Hive, Isar, or ObjectBox for local data storage. Syncing Without Breaking Things – Ensuring data consistency with background sync techniques. Handling Conflicts Gracefully – Avoiding data loss when multiple devices update the same record. Background Tasks & Work Managers – Keeping data fresh even when the app isn’t open. By the end of this session, you'll walk away with practical solutions to handle network failures, data synchronization, and seamless user experiences, whether your app is used in the subway, remote villages, or just a bad Wi-Fi zone. 2025.droidkaigi.jp 最後に 2025年9月10日から12日にかけて開催されたDroidKaigi 2025に参加してきました。Androidに関わる企業・人々が一堂に会するお祭りとして、楽しく、そして学びの多いイベントでした。主催者・スタッフ・登壇者・協賛企業など、関係者に感謝しつつ、弊社メドレーでもイベントや技術コミュニティを盛り上げていきたいと改めて思いました。 メドレーでは、カンファレンスへのスポンサーの他にも、イベントの開催などを通じて技術とコミュニティに貢献しています。 メドレーではエンジニアを積極採用中です！ メドレーではテクノロジーを活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。モバイルアプリ開発の専門性を活かした医療ヘルスケア領域の課題解決に興味がある方は、ぜひカジュアル面談にお越しください！ Flutterエンジニア／人材プラットフォーム本部 | 株式会社メドレー Flutterエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co iOSアプリケーションエンジニア／CLINICS（総合医療アプリ） | 株式会社メドレー iOSアプリケーションエンジニア／CLINICS（総合医療アプリ）（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co Androidアプリケーションエンジニア／CLINICS（総合医療アプリ） | 株式会社メドレー Androidアプリケーションエンジニア／CLINICS（総合医療アプリ）（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co

こんにちは、人材プラットフォーム本部CTO室の奥澤です。2025年9月、株式会社メドレーに入社して人材プラットフォーム本部へ配属されました。メドレーの人材プラットフォーム本部では既に複数のモバイルアプリを開発していますが、モバイルアプリ開発をさらに加速させていくためにジョインしました。 さて、9月に入って8月ほどの暑さはなくなり、夏の終わりを感じています。そして例年、自分にとって暑い夏の終わりと秋の始まりを告げるイベントである、DroidKaigiに今年も参加してきました！DroidKaigiは、日本国内で最大級のAndroidに関するカンファレンスです。 株式会社メドレーは、2025年9月10日から12日にかけて開催された、DroidKaigi 2025にSupporters Sponsorとして協賛しました。メドレーでは2021年からDroidKaigiに協賛しており、今年で5回目の協賛となっています。メドレーでは、DroidKaigiなどの技術カンファレンスへ継続的に協賛し、技術コミュニティを支援しています。 本記事では、DroidKaigi 2025の会場の様子と共に、印象に残ったセッションを紹介します。 会場の様子 DroidKaigi 2025は、ベルサール渋谷ガーデンで開催されました。DroidKaigi 2023から同じ会場で開催されています。今年も元気に会場にやってきました。 地下1階に設けられたコミュニケーションエリアには、協賛している各企業のブースが出展されていました。ブースを周り、各企業の話を聞いて歩くのはカンファレンスの大きな楽しみですね。それぞれの会社 / アプリの取り組みについて学び、さらに中の人に詳しい話を聞くことができるのは良いですね。 今年も気合いを入れてスタンプラリーをコンプリートしました。大量にノベルティもいただいたので、家族へのお土産になりました。全部のノベルティが嬉しいものですが、特に印象に残ったノベルティは、株式会社TVer様のタンブラー（かっこいい）、KINTOテクノロジーズ株式会社様のコースター（かわいい）、株式会社メルカリ様のキーキャップ（さっそく使ってます）でした。 セッションの様子 私がリアルタイムで聴講したセッションの中で、印象に残ったいくつかのセッションとその感想を紹介します。 共有と分離 ─ Compose Multiplatform “本番導入” の設計指針 Kotlin Multiplatform（KMP）は、ここ数年で盛り上がっているクロスプラットフォーム技術で、ロジックをプラットフォーム間で共通化することができるものです。さらに、Compose Multiplatform（CMP）を用いることで、UIも共通化することができます。KMP / CMP、あるいはクロスプラットフォーム技術において、OSの境界をどう引くか？をいかに設計すれば少人数で生産性高くアプリを開発できるのか、という点に興味を持ちました。 本セッションでは、KMP / CMPとそのエコシステムの現状・限界を見極めながら、その本番導入を進めていった過程とその結果を発表されていました。最終的に約90%のソースコードをOS間で共有することができたそうですが、ネイティブで提供できる高品質な触り心地と、ソースコードの共有によって実装効率の向上を両立できた点は素晴らしいですね。 共有と分離 ─ Compose Multiplatform “本番導入” の設計指針 Kotlin Multiplatform (KMP) は、ネットワーク通信やドメインロジックを Android / iOS で共通化し、Compose Multiplatform (CMP) はそのうえ UI までを共通化します。両者を組み合わせれば、アプリの大部分を単一のコードベースで開発できることが大きな魅力です。 ところが実プロダクトへの導入に踏み出すと ・使いたいライブラリや SDK が KMP に非対応 ・OS 固有の API を直接呼びたい ・一部の画面をネイティブ UI でリッチに作り込みたい といった理由で、 ”共有できない領域” が必ず現れます。 本セッションでは、Android と iOS のエンジニアが共同登壇し、 ・プラットフォーム間でコードのどこを共有し、どこを分離するのか ・開発速度 × ユーザ体験 を両立させる設計・実装パターン を具体例とともに紹介します。実際に CMP を採用して半年弱で Android / iOS 両アプリをリリースしたプロダクトを題材に解説します。 予定しているトピック： ・共有の最前線 　CMP + KMP 対応ライブラリの活用でどこまで共通化できるか ・分離のテクニック 　・Kotlin × Swift の DI 設計 　・KMP に非対応の SDK の安全な統合 　・CMP + ネイティブ UI のハイブリッド実装 ・両プラットフォーム視点で見る落とし穴と回避策 CMP 導入で必ずぶつかる ”共有できない領域” を見極め、必要に応じてコードを切り離すための指針をお伝えします。 2025.droidkaigi.jp スマホ新法って何？１２月施行？アプリビジネスに影響あるの？ 2025年12月18日に施行される、「スマートフォンにおいて利用される特定ソフトウェアに係る競争の促進に関する法律」、いわゆるスマホ新法またはスマホ法について、公正取引委員会の方のセッションがありました。スマホ法の趣旨、スマホ法の施行によって何が変わるのか、スマホ法の施行によるアプリデベロッパーへの影響など、わかりやすく説明いただきました。 規制対象となる指定事業者に属していないエンジニアにおいても、スマホ法の施行によって今後どのようなことが起こっていくのか？しっかり理解しておいた方が良さそうだと感じました。セッションに参加したことで興味・理解が深まりました。 スマホ新法って何？１２月施行？アプリビジネスに影響あるの？ 今年１２月に施行が予定されている新しい法律、スマホソフトウェア競争促進法（スマホ新法）。 この法律がアプリビジネスにどのような影響を与えるのか、エンジニアのみなさまにどんな関係があるのか、公正取引委員会の担当者が解説します。 例えば、 ・OS機能（通信機能等）の利用可能性の向上 ・新たなアプリストアの登場など決済手段の多様化 ・ウェブサイト等のアプリ外での商品提供の拡大 ・ソフトウェアの切替え時におけるデータ移転の円滑化 ・ユーザーによるブラウザや検索サービスの選択の促進 などなど、これから見込まれる「変化」について説明します。 2025.droidkaigi.jp Surviving Network Failures: Building Resilient Offline-First Flutter Apps モバイル端末はネットワークが不安定な場所で使われることも多々あります。ネットワークが不安定な状況においてもアプリを使い続けられることは、ユーザーの体験として非常に重要であると考えます。そのためには、「オフラインファースト」でアプリの体験を設計することが必要になり、同時にオフラインファーストな体験を実現するための技術的な戦略も描く必要があります。 このセッションでは、オフラインファーストなアプリの体験を実現するためのUX / 技術的な戦略を提案しています。サンプルコードはFlutter / Dartですが、おおまかな内容はフレームワークによらず参考にできるものでした。セッションの内容については触れませんが、オフラインファーストでアプリの体験 / アーキテクチャを設計するためのガイドラインとなるセッションだったと感じています。 Surviving Network Failures: Building Resilient Offline-First Flutter Apps What happens when your app loses internet, does it gracefully adapt, or does it leave users frustrated? In a world where connectivity is unpredictable, building offline-first apps isn’t just a feature; it’s a necessity. In this talk, we’ll explore battle-tested strategies to keep your Flutter app running smoothly, even in airplane mode. You’ll learn: Caching Like a Pro – Choosing between SQLite, Hive, Isar, or ObjectBox for local data storage. Syncing Without Breaking Things – Ensuring data consistency with background sync techniques. Handling Conflicts Gracefully – Avoiding data loss when multiple devices update the same record. Background Tasks & Work Managers – Keeping data fresh even when the app isn’t open. By the end of this session, you'll walk away with practical solutions to handle network failures, data synchronization, and seamless user experiences, whether your app is used in the subway, remote villages, or just a bad Wi-Fi zone. 2025.droidkaigi.jp 最後に 2025年9月10日から12日にかけて開催されたDroidKaigi 2025に参加してきました。Androidに関わる企業・人々が一堂に会するお祭りとして、楽しく、そして学びの多いイベントでした。主催者・スタッフ・登壇者・協賛企業など、関係者に感謝しつつ、弊社メドレーでもイベントや技術コミュニティを盛り上げていきたいと改めて思いました。 メドレーでは、カンファレンスへのスポンサーの他にも、イベントの開催などを通じて技術とコミュニティに貢献しています。 メドレーではエンジニアを積極採用中です！ メドレーではテクノロジーを活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。モバイルアプリ開発の専門性を活かした医療ヘルスケア領域の課題解決に興味がある方は、ぜひカジュアル面談にお越しください！ hrmos.co hrmos.co iOSアプリケーションエンジニア／melmo（総合医療アプリ） | 株式会社メドレー iOSアプリケーションエンジニア／melmo（総合医療アプリ）（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co Androidアプリケーションエンジニア／melmo（総合医療アプリ） | 株式会社メドレー Androidアプリケーションエンジニア／melmo（総合医療アプリ）（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co

こちらの記事は「 MEDLEY Summer Tech Blog Relay 」の18日目の記事です🎉 今週はFY25新卒エンジニアの4人が連続して記事をお届けします！ はじめに 株式会社メドレーに 2025 年 4 月に新卒入社した、平林です。 医療プラットフォームの歯科診療所事業部でソフトウェアエンジニアをしており、クラウド歯科業務支援システム「Dentis」を開発しています。 皆さんは病院や歯科医院で診察を受けた後、窓口で料金を支払っていると思います。ご存じの方も多いかもしれませんが、ここで払う料金は医療機関の収入の一部に過ぎません。 残りの診療報酬は患者が加入している保険組合（保険者）から支払われることになっており、医療機関は毎月患者に行った診療をまとめた書類（診療報酬請求書、通称レセプト）を作成して支払基金（国保の場合は国民健康保険団体連合会）に請求します。 以下は、社会保険に加入している患者の診療報酬請求の流れです。 支払基金ってどんなところ？｜社会保険診療報酬支払基金 www.ssk.or.jp このレセプトをコンピューターを使って自動で作成してくれるのが、レセプトコンピューター（レセコン）です。 今回は、このレセプトについて学習するために、レセプトビューアを作ってみました。 ソースコードは以下で公開しています。 GitHub - avaice/dental-uke-reader Contribute to avaice/dental-uke-reader development by creating an account on GitHub. github.com 電子レセプトについて レセプトには、紙レセプトと電子レセプトの2種類があります。元々は紙レセプトのみでしたが、現在はそれをデータ化した電子レセプトが主流となっています。 電子レセプトはCSVライクなカンマ区切りのフォーマットとなっており、UKEという拡張子で保存されます。 以下は、一般的な電子レセプトの例です。※データは架空の情報です UK,2,13,3,1234567,,メドレークリニック,202201,0117,00 IR,2,13,3,1234567,,202201,03-1234-5678,0117 RE,4,3318,202112,歯科　太郎,1,19400808,,,20210609,1,,,29,,123456/8,,,,,,,,,,シカタロウ, HO,39141320,,２３５７２４４９,2,1279,,,,,,,, JD,1,,,,,,,,1,,,,,,,,,,,,,,1,,,,,,,,, MF,00,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, HS,,,101700101500101400101300101200101100102100102200102300102400102500102600102700104800104500104400104300104200104100103100103200103300103400103500103700,5234009,,,,,,,, SS,12,1,301001610,,,CA062,,CA045,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,57,2,,,,,,,,1,,,,,,,,,,,,,,1,,,,,,,,, (...以下省略) GO,116,155332,99 一見よくわからないデータですが、社会保険診療報酬支払基金のWebページには「オンライン又は光ディスク等による 請求に係る記録条件仕様（歯科用）」（以下、仕様書）が公開されているので、それを見ながら読み進めていきます。 電子レセプトの作成｜社会保険診療報酬支払基金 www.ssk.or.jp 1列目には「UK」と書いてあります。これはレコード識別情報です。 レコード識別情報の一覧は、以下のとおりです。 値 レコードの種類 データの一例 UK 受付情報レコード 審査支払機関・医療機関コード・都道府県など IR 医療機関情報レコード 医療機関コード・連絡先・請求年月など RE レセプト共通レコード 患者（被保険者）の名前・性別など HO 保険者レコード 保険者番号・合計点数など KO 公費レコード 負担者番号公費負担者番号など SN 資格確認レコード 負担者種別や受給者番号など JD 受診日等レコード 日別の受診等区分など MF 窓口負担額レコード 高額療養費の扱いなど HS 傷病名部位レコード 傷病名コード・部位の 歯式コード など SS 歯科診療行為レコード 診療識別・歯科診療行為コードなど SI 診療行為レコード 医科診療行為コードなど IY 医薬品レコード 診療で使用した医薬品・院内で処方した医薬品など TO 特定器材レコード 特定器材コードなど CO コメントレコード 診療識別・コメントコードなど SJ 症状詳記レコード 症状詳記（診療内容が明確でない場合などに記録する）など GO 診療報酬請求書レコード 総件数など この値によってこの行がどんな情報を含んでいるのか判別することができます。 今回はUK（受付情報レコード）だけ見てみましょう。仕様書と照らし合わせると、以下の内容であることが分かります。 値 説明 備考 1 審査支払機関 1: 社会保険診療報酬支払基金、2: 国民健康保険団体連合会 13 都道府県コード 総務省が定める都道府県コード( URL ) 16: 富山県 3 点数表種別 点数表種別 3: 歯科 他にも、1: 医科, 4: 調剤など 1234567 医療機関コード 医療機関コード (空欄) 予備エリア メドレークリニック 地方厚生（支）局長に届け出た名称 20文字を超える場合は、決まっている省略名称になる 202201 請求年月 レセプトが請求される年月。例: 2022年1月 0117 施設基準届出コード 2文字区切りで解釈される。01:補管（クラウン・ブリッジ維持管理料）17:歯科初診料 00 マルチボリューム識別情報 フロッピーディスクなど容量の少ない媒体を使用する際、レセプト情報が複数のファイルに分割されている場合に、そのファイルの順番を示す このような形で各行を読んでいくと、電子レセプトが示している内容が分かります。 レセプトの読み方がなんとなく分かったので、次は実際にこれを読み込むプログラムを作ります。 CSVを読み込んでパースする 電子レセプトはShift-JISで記録されているので、文字コードを指定して読み込みます。 const loadFile = ( file ) => new Promise (( resolve , reject ) => { const reader = new FileReader (); reader . onload = ( e ) => { const text = e . target ?. result ; if ( typeof text !== "string" ) { reject ( new Error ( "Failed to load the file" )); return ; } resolve ( text ); }; reader . onerror = () => { reject ( new Error ( "Failed to read the file" )); }; reader . readAsText ( file , "shift-jis" ); }); 読み込んだあとは、UKEデータをパースします。 CSVのパースは考慮することが多くエンジニア泣かせで有名ですが、UKEの仕様は非常にシンプルなので簡単にパースできます。 （以下は、一部抜粋です） 符号名称 図形記号 用途 コンマ , 項目の区切りを表現する 引用符 " 使用しない 改行コード \n レコードの区切りを表現する const csv = await loadFile ( file ); const receipts = csv . trim () . split ( " \n " ) . map (( line ) => line . split ( "," )); 項目の説明を表示する 行ごとのレコードと列番号を渡すと説明が返ってくるロジックを作ります。 説明情報は、社会保険診療報酬支払基金のWebページに公開されている「電子レセプトの作成手引き」を参考にします。 「電子レセプトの作成手引き」はPDFで公開されているデータですが、 markitdown を使ってマークダウンに変換し作業スペースに置くことで、CursorやClaude Codeといった開発支援ツールを活用して効率的に実装を進めることができました。 GitHub - microsoft/markitdown: Python tool for converting files and office documents to Markdown. Python tool for converting files and office documents to Markdown. - microsoft/markitdown github.com export type RecordType = { index : number ; data : string []; }; export const explain = ( record : RecordType ) => { switch ( record . identification ) { case "UK" : return explainUK ( record ); case "IR" : return explainIR ( record ); // ...省略 default : return null ; } }; 値によって説明が変わる内容もあるので、動的に説明文を作れるようにしました。 const explainUK : ((( record : RecordType ) => string ) | string )[] = [ "この行が受付情報レコードであることを示します" , ( record ) => `審査支払機関を示します。値「 ${ record . data [ record . index ] } 」は「 ${ getShiharaiKikan ( record . data [ record . index ]) } 」です` , // ...省略 ]; マスターファイルから情報を取得する UKEの中にはそのまま解釈できる内容だけでなく、診療行為コードや医薬品コードのような別のデータ（マスターファイル）を参照しないと内容がわからないものがあります。 マスターファイルや仕様は、厚生労働省がWebで公開してくれています。 診療報酬情報提供サービス shinryohoshu.mhlw.go.jp マスターファイルは電子レセプトと仕様の違うCSVで、以下のような仕様になっています。 項目間の区切り文字は「,」（カンマ）とする。 各項目の値は、モード（「数字」、「英数」及び「漢字」）に関わらず、引用符「”」（ダブルクォーテーション）を前後に付す。 最大バイトは引用符「“」を除いたバイト数であり、小数部がある値は、小数点及び小数以降の数字を含む。 ０バイトの文字列（Null）の場合は、引用符「“」を続けて記録する。 値をダブルクォーテーションで囲むとのことなので、値の中のカンマを許容する仕様である可能性があります。愚直に1文字ずつ処理します。 // const csv = 生のCSVデータ; const lines = csv . split ( " \n " ); const records : Record < string , string >[] = []; const shobyomeiMasterHeaders = [ "変更区分" , "マスター種別" , "傷病名コード" , /** 以下省略... */ ]; for ( const line of lines ) { const record : Record < string , string > = {}; let charIndex = 0 ; let columnIndex = 0 ; let inQuotes = false ; let buffer = "" ; while ( charIndex < line . length ) { const char = line [ charIndex ]; if ( char === '"' ) { inQuotes = ! inQuotes ; } else if ( char === ',' && ! inQuotes ) { // カンマ区切り、かつ引用符の外 record [ shobyomeiMasterHeaders [ columnIndex ]] = buffer ; columnIndex ++; buffer = "" ; } else { // それ以外はバッファに追加 buffer += char ; } charIndex ++; } if ( buffer . length > 0 ) { record [ shobyomeiMasterHeaders [ columnIndex ]] = buffer ; } // データベースへの保存 await saveToDatabase ( "shobyomei" , record . 傷病名コード , [ record ]); } マスターファイルは全部で20MB程度あり、毎回処理していたら時間がかかってしまうので、indexedDBに展開しました。 これで、診療行為コードや医薬品コードを基にマスターの内容を参照できるようになりました。 ここで一つ気をつけなければいけないのは、医薬品コードの情報には有効期限があるということです。 該当するレコードの診療日が、変更年月日〜廃止年月日の間であることを確認する必要があります。例えば2015年のレセプトから情報を得たいのであれば、2015年時点のマスターファイルを参照する必要があります。 そのため、時系列に合った複数バージョンのマスターを保持できる設計にするために、キーに対してデータは配列で持つようにしました。 表としてレンダリングする UKEのパーサーと情報の取得処理が書けたので、表としてレンダリングします。 type CellPosition = { x : number ; y : number }; const UKERenderer = ({ uke }: { uke : string [][] }) => { const [ activeCell , setActiveCell ] = useState < CellPosition | null >( null ); const handleClickCell = ( x : number , y : number ) => setActiveCell ({ x , y }); const isActiveCell = ( x : number , y : number ) => activeCell && activeCell . x === x && activeCell . y === y ; return uke . map (( row , y ) => ( < Row key = { `row- ${ y } ` } > { row . map (( value , x ) => ( < Cell key = { `cell- ${ x } ` } onClick = { () => handleClickCell ( x , y ) } active = { isActiveCell ( x , y ) } description = { explain ({ index: x , data: row }) } > { value } </ Cell > )) } </ Row > )); }; 実際に開発したもの 実際に開発したものは、今まで解説したコードをベースに機能や処理を付け加えています。 開発してみて 以前は、テキストエディターを使って目視でマスターファイルの内容を照らし合わせており確認作業が大変でしたが、今回作った電子レセプトビューアによって、正しくレセプトが出力されているかの確認が行いやすくなりました。 また、自分自身も電子レセプトの仕様を学んだことで、業務で行っていることが少しずつ分かるようになってきました！ おわりに 今回は、歯科の電子レセプトを理解するために、電子レセプトビューアを開発しました。 私たちソフトウェアエンジニアは、普段医療に関するシステムの話をあまり目にすることは少ないですが、意外と仕様やデータが一般にも公開されており、手軽に触れてみることができます。 この記事を読んで、医療ITに興味を持ってくださる方がいれば幸いです！ 次は、新卒エンジニア4人目の池田さんです！お楽しみに！！

この記事は 「 MEDLEY Summer Tech Blog Relay 」 15 日目の記事です。 はじめに こんにちは！人材プラットフォーム本部プロダクト開発部の小泉( @kzmkt )です。 医療介護従事者向けの求人メディア「 ジョブメドレー 」開発チームの一員として、主にフロントエンドのエンジニアをしています。 今回、2025年10月の利用規約改定に備えて、 利用規約ページを刷新 しました。 → 改定版周知のための利用規約ページはこちら ジョブメドレーは「 誰でも使える 」サービスを目指してデザインリニューアルのプロジェクトに取り組んでいます。 → 「誰でも使える」ように、アクセシビリティ向上に向けて取り組んだこと この記事では取り組みの背景、具体的な開発プロセスとソフトウェアエンジニアリングについて、プロジェクトメンバーの話も交えて紹介させていただきます。 今回のプロジェクトでは利用規約を読みやすくするために、総合的な観点が必要だったので、法務担当・外部弁護士・デザイン部・開発チームの共同プロジェクトとして進めました。 利用規約を刷新する理由 利用規約刷新の具体的な背景と課題について、事業企画室の小松さんとデザイン部の佐竹さんにお話を伺いました。 事業企画室 小松さんのコメント ジョブメドレーの利用規約は、あらゆるケースを想定した抽象的で抜け漏れのない規定が必要となります。 そうした文章はともすると、冗長で専門的な用語が多用されるため、誰にとっても読みやすいものとはいえません。 また、サービス規模にあわせて最適な状態に改定してきたものの、運営が15年にもなると複雑でわかりやすいとはいえない規約となっていました。 今回の取り組みでは、わかりづらさを解消し、誰にとってもわかりやすい利用規約を目指すため、以下のような対応を実施しました。 冗長な文章を箇条書きや表形式に変更する 条文が適用されたときの具体例を記載する 「〜を承諾するものとします」や「〜に帰属するものとします」など、法律的な言い回しを可能な限り平易なものに変更する 章立ても含めた規約の構成をすべて見直す デザイン部 佐竹さんのコメント 旧デザインの課題 デザインの視点から見た旧デザインの課題は大きく3つあります。 情報構造が不明瞭で、ページ全体の流れをつかみにくい 文字サイズや太さに強弱がなく、重要な情報を見つけづらい 装飾的な補助要素がなく、内容を直感的に理解しにくい 新デザインでの解決策 新デザインでは、 読む負担を減らし、内容を把握しやすい表現 を意識しました。 適切な余白を設け、テキストをブロック単位で整理 目次を追加し、見出しサイズを最適化することで、章や節の構造を一目で把握しやすく改善 キーワードをフォントウェイトで強調し、重要情報を直感的に理解可能に イラストを追加し、複雑な内容をサポート。長文の合間に配置することで、読解のストレスを軽減 背景色付きの注釈で補足説明や注意事項を目立たせ、必要な情報をすぐに把握できるように ジョブメドレーは2009年11月にサービスを開始しました。 サービスが成長していく中で法改正以外でも利用規約を更新し続けており、その時々では最善を尽くしてきたものの、たび重なる改定により、結果として複雑で読みにくい利用規約になってきてしまっていました。 そのため、今回の改定で全面的に見直しを行い、よりわかりやすい構成と内容に改定することにしました。 使用技術と開発プロセス ここからは分かりやすい利用規約の実現及び「 誰でも使える 」ジョブメドレーの実現に向けた、 アクセシビリティに配慮した開発 について紹介します。 ジョブメドレーにはさまざまな開発チームがあり、各チームが並行して機能開発や改善を進めています。多様なチーム構成の中では、チーム間の違いに加えて、企画者・デザイナー・エンジニアなどポジション毎でも、アクセシビリティに関する知見のレベルは様々です。 また、現在は協力会社のサポートを受けながらアクセシビリティに配慮した開発を進めており、今後のアクセシビティ対応の内製化に向けて、 ジョブメドレーのエンジニア全員が「誰でも使える」を「誰でも作れる」ようにする 必要があります。 今回は以下のプロセスで開発を行いました。 企画・仕様策定 デザイン作成 開発 デザインコンポーネント開発 画面全体の作り込み ロジックの実装 アクセシビリティレビュー QA リリース 監視 運用 今回は「 デザインコンポーネント開発 」および「 アクセシビリティレビュー 」における取り組みの一部をご紹介します。 どの画面でも変わらないアクセシビリティ品質を提供する開発プロセス 今回の利用規約ページでは、デザインコンポーネントとロジック実装を完全に分けて開発しており、デザインコンポーネント開発段階でアクセシビリティに配慮した実装を行っています。 Storybook を用いてアクセシビリティの品質が担保されたコンポーネントを開発し、それらを組み合わせることで各ページを作成しています。 アクセシビリティ勉強会でStorybookの利用方法を共有 ジョブメドレー開発チームではアクセシビリティ勉強会を実施しており、FigmaのデザインからStorybookを用いたデザインコンポーネント開発を行う際の注意点を紹介しています。 コンポーネント毎にジョブメドレーで目指すアクセシビリティが担保された状態を目標に開発しています。 利用規約ページにおける各項目要素のコンポーネントを作成 今回の利用規約ページでは、各要素に対応したコンポーネントを作成しました。 それぞれのコンポーネントを組み合わせることで、各章や注釈の構造を明確にしています。 ツールやAIによる形式レビューと人による総合的なレビュー アクセシビリティへの配慮は最終的には人の手と目で確認しなければ、本当に必要な対応ができているかを判断することができません。しかし、開発現場では全てを人の手と目で確認することは必ずしも現実的ではありません。 そこで、段階的なレビュープロセスを実施しています。 初期確認 AIによる各コンポーネントの実装およびアクセシビリティのレビュー 既存の実装と類似している箇所の事前自動チェック ページ作成時 ブラウザのアクセシビリティチェックツールによる確認 最終確認 VoiceOverやPC Talkerを用いた実機での確認 ジョブメドレー独自のルール、実際の使用感も含めた人によるレビュー この仕組みによりレビューコストを減らしつつ、 より本質的なアクセシビリティの課題に取り組める ようにしています。 AIによるレビュー ジョブメドレーではAIによるプルリクエストのレビューを行っています。 アクセシビリティ観点だけでなく、開発初期段階におけるレビューとして、既存実装との整合性や単純な実装ミスのチェックはAIに任せています。 この結果、一定の精度をクリアしたものを人間のレビューに回すことになり、負荷を減らしています。 ブラウザのアクセシビリティツールによるチェック ブラウザ拡張ツールの axe DevTools® を用いて、ページのアクセシビリティチェックを実施しています。 これにより基本的なアクセシビリティ課題は自動的に検出することができ、一定の品質を担保できるようにしています。 利用規約ページに合わせた人によるレビュー AIやツールによる自動チェックでは対応しきれない部分について、人によるレビューを行っています。 アクセシビリティに可能な限り配慮しつつ、ジョブメドレー固有のユーザビリティ要件や使用感も担保できる状態を目指してレビューします。 自動化できる部分は事前にAIやツールでチェックしているため、人によるレビューではより本質的で高度な判断が必要な部分に集中することができます。 VoiceOver・PC Talkerを用いた実機確認 実機での読み上げ、タップ操作、キーボード操作の確認を行います。 開発者用の検証ツールと実機では、読み上げや操作に差異が起きる場合があります。 利用者を想定して、実際のPCやスマホ上でも問題のない表現になっているかを改めて確認しています。 サービス体験をより良いものにするために、ウェブサービスは人間だけでなく機械が読みやすい文章にする必要があります。これを マシンリーダビリティ と呼び、読み上げツールがより適切なアウトプットを行うことができ、ユーザ体験が向上します。 アクセシビリティに配慮した開発を行う中で読み上げツールに対応した表現になるようにしています。マシンリーダビリティも担保できる形になっています。 アクセシビリティに配慮したウェブサービスを提供することで、人間だけでなく読み上げツールやAIなどの機械にも扱いやすいサービスを作ることができます。 今回の学び 利用規約の刷新を行う中で様々な気づきがありました。 アクセシビリティに配慮できているウェブサービスであるかどうかは、実際に画面がどのようにHTMLとしてマークアップされるかによって決まります。 そのため、コンポーネント作成段階からアクセシビリティに配慮した開発を進めていくことで、実際の画面を作り込むときのチェックが行いやすくなり、実装者とレビュワーのそれぞれが注力すべき箇所がより明確になります。 コンテンツページのアクセシビリティ 静的コンテンツページでの表示はシンプルですが、ただ純粋に文章を羅列するだけではなく、適切なマークアップが必要になります。 適したHTML表現を行うことで、アクセシビリティに配慮したセマンティックなWebページを作ることができます。 今回、一般的なページの開発ではあまり見かけないHTMLタグも使用しています。 HTMLタグ 説明 <small> : 附随コメント要素 HTML4.1では小さい文字を表現するものでしたが、HTML5ではスタイルの表現とは独立して、著作権表示や法的表記のような、注釈や小さく表示される文を表す仕様に変わっています。 <address> : 連絡先要素 個人、団体、組織の連絡先情報を提供していることを示しています。 利用規約の各要素に明確に意味を持たせることを意図して使用しています。 WCAG2.1 AAAへの配慮 ジョブメドレーではWCAG2.1の適合レベルAおよびAAに配慮した、Webサービス作りを行っています。 今回の利用規約の刷新において、結果的にWCAG 2.1 AAA（ 日本語版: WCAG 2.1 ）にも一部配慮したページになりました。 基準名 達成基準 対応内容 達成基準 2.4.10 : セクション見出し セクション見出しを用いて、コンテンツが整理されている。 各セクションで <h1>~<h6> タグを使用して、内容や項目を明確に示す見出しを作成 達成基準 3.1.5 : 読解レベル （ ※達成途中 ） 固有名詞や題名を取り除いた状態で、テキストが前期中等教育レベルを超えた読解力を必要とする場合は、補足コンテンツ又は前期中等教育レベルを超えた読解力を必要としない版が利用できる。 文章全体として、簡潔な文章となっており、前期中等教育レベルでおおよそ読解できる状態 ※ 今回の利用規約刷新では、達成基準 3.1.5 読解レベルを目指していますが、まだ完全に平易なものにはなっておらず改善の余地があります。 この達成基準を目指して改善を重ねていければと思います。 まとめ 今回の利用規約刷新では、「 多くの人にとって読みやすい 」利用規約ページとなるように、これまで以上に、丁寧なアクセシビリティに配慮したページを作成しました。 また、開発チームにもさまざまな知見が溜まりました。 アクセシビリティに配慮した開発に終わりはなく、今後も続いていきます。 ジョブメドレーでは全てのチームがアクセシビリティに配慮したプロダクト作りを行い、これまで以上に「 誰でも使える 」ジョブメドレーを目指して行きます。 We Are Hiring! 最後まで読んでいただきありがとうございます！ メドレーでは一緒にプロダクト開発をしていただけるエンジニア・デザイナー・ディレクターを募集中です。 少しでも興味を持っていただけましたら、ぜひカジュアル面談でお待ちしています！ 🤝 募集一覧 🗣️ カジュアル面談 「 Medley Summer Tech Blog Relay 」 16 日目は、医療プラットフォーム本部の山田さんの記事です！

この記事は「 MEDLEY Summer Tech Blog Relay 」11 日目の記事です。 はじめに こんにちは、メドレーでAI推進している人材プラットフォーム本部 VPoE の倉林( @terukura )です。 前回の記事「 AI for All - 全社でAI活用を推進する取り組み 」でお伝えした通り、メドレーでは「AI for All」を合言葉に、全社的なAI活用を推進しています。あれから約4ヶ月が経過し、プロダクト開発チームにおけるAI活用は大きく前進しました。 本記事では、メドレーのプロダクト開発におけるAI活用の現在地を、具体的な数値とともに振り返ってみます。 AI活用に関する発表では、制度としての一人n万円の支援制度、全社Cursor/Claude Max Plan導入、全社でn億円の投資などマクロな数字が注目されがちですが、本記事ではなるべく実際にどのツールをどれくらい使っているのか、具体的な利用状況を公開している例は意外と少ないため、皆様の参考になれば幸いです。 1〜2週間ごとに新しい技術やツールが登場する昨今、最適解はないと感じています。各社の状況や文化に合わせ変化に強い組織を作ることが重要だと考えています。あくまで一つの事例として、メドレーの取り組みをご紹介します。 メドレーのプロダクト開発におけるAI活用の方針 メドレーでは、以下の3つの方針を軸にAI活用を進めています。 1. ツールに縛られない柔軟な選定 特定のAIツールやサービスに固執せず、AI技術やモデルの進化に合わせて最適なツールを選定しています。例えば、コーディング支援ツールだけでも複数のオプションを並行して検証し、用途や開発者の好みに応じて使い分けています。 2. 継続的なモニタリングと改善 導入して終わりではなく、日々の利用状況や生産性向上の効果を定量的にモニタリングし、PDCAサイクルを回しています。月次でROIを評価し、効果が薄いツールは見直しを行います。 3. 開発プロセスへの深い統合 GitHub ActionsでのAIレビュー自動化、監視/アラートへのAI組み込みなど、開発プロセスの各段階にAIを統合しています。これにより、エンジニアが意識せずともAIの恩恵を受けられる環境を構築しています。 現在メドレーで利用・検証中の主なAIツール・サービス 2025年9月時点 で、メドレーでは以下のAIツール・サービスを主に活用しています。 コーディング支援ツール Claude Code、Cursor、Devin、Codex、GitHub Copilot、Gemini CLI AIモデルプロバイダー Google Vertex AI、Azure OpenAI、AWS Bedrock、Anthropic API、OpenAI API、BytePlus ModelArk ワークフロー・自動化 Dify、n8n コードレビュー支援 Claude Code Action、CodeRabbit、GitHub Copilot Review、Devin Review チャット・汎用AI ChatGPT Team、Claude Team 、Gemini その他のツール Langfuse、NotebookLM、Dia、Perplexity、Snyk、Mastra 数値でみる主な利用状況 Claude CodeについてはパワーユーザーはMax Plan、その他の利用者向けにはVertex AI経由で提供 GPT-5の登場により徐々にCodex CLIの利用も増加傾向（TeamPlan/ProPlan） 利用ModelとしてはClaude Sonnetの割合が高い、次点でOpus・GPT（Claude Max Plan ユーザー除く） Difyについては徐々に全従業員が触れ合うツールになりつつある、Model+Prompot+フローの検証利用としても拡大中 トータルで350-400万円/月　くらいがコスト観点での現在地 生産性への影響、FourKeysの変化などはまた次の機会に詳細を共有させていただければと思っています。 今後の展望 AI駆動開発（AI-Driven Development）への移行 AIが開発の中心となる新しいパラダイムへの移行を目指します。 自然言語での要件定義から実装までの自動化 AIエージェントの本格導入・開発 AIによるUI/UX設計・プロトタイピング AIによるアーキテクチャ設計の提案・レビュー CI/CDパイプラインとの深い統合 QA自動化 パフォーマンス最適化の自動実行 インシデント対応・管理の自動化 今回は主にプロダクト開発におけるAI活用の現在地点を利用状況を元に振り返ってみました。 「同じような利用状況の方」、「もっと活用している方」、「まだまだ未活用で活用方法を聞きたい方」 など ぜひ詳細など情報交換させていただければと思います。 直近はMEDLEY AI CLOUDの発表や、今回のMEDLEY Summer Tech Blog RelayでのAI関連の記事など AI関連の発信もどしどし行っていますので、ぜひ興味をもっていただければと思います。 MEDLEY AI CLOUD MEDLEY Summer Tech Blog Relay：組織で育てるAI活用テスト設計の仕組み MEDLEY Summer Tech Blog Relay：Claude Codeで「Context left until auto-compact: 15%」が出たときの対処法 MEDLEY Summer Tech Blog Relay：データ戦略グループにおけるcontext engineeringの取り組み 明日の「MEDLEY Summer Tech Blog Relay」の記事は、デザイナーの近藤さんです！ We’re hiring! メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーのエンジニア組織・AI活用についてお話します！ 「メドレーのエンジニア組織・AI活用についてお話します！」- 倉林 昭和さん pitta.me

この記事は メドレー夏のブログリレー 2025 6 日目の記事です。 はじめに こんにちは、医療プラットフォーム本部データ戦略グループの安東です。 データ戦略グループでは、データ基盤の構築から可視化、分析、ダッシュボード作成まで担い、データ活用を促進することで事業成長と医療ヘルスケアの未来に貢献することをミッションにしています。 そのため、日々データを扱う業務をしているのですが、最近チームでこんな議論がありました。 「AI を用いてデータ分析する際にテーブルのメタデータだけでなく、ビジネスロジックや過去の分析知見、議論の文脈まで理解させることが大切だよね。」 皆さんのデータアナリスト組織でも、AI を活用したデータ分析で同じような課題を感じることはないでしょうか。 当社もデータ分析の生産性を高めるため、Cursor や ClaudeCode といった AI ツールを積極的に活用しています。 その過程で、データアナリストに新たな価値提供の機会が広がっていると感じており、その鍵となるのが「 context engineering 」と考えています。 context engineering とは、 AI がタスクを達成できるように、適切な知識・ツール・求める出力形式を提供することです。（参考： The rise of “context engineering” ） 今回は、「Analytics Knowledge as Code」という形で、分析における context engineering の取り組みについてお話しします。 なお、Analytics Knowledge as Code の考えは、AWS Summit で紹介されていた「 AI Agent 時代のソフトウェア開発の型 〜 Everything as Code で叡智を伝える 〜 」の内容を参考にしています。 AI によって変わる分析の風景 生成 AI の登場で、SQL の記述、前処理、集計、可視化といったデータ分析作業の多くが効率化できるようになりました。 では、すべての分析業務が AI に置き換えられるでしょうか？ 少なくとも現時点では、分析業務にはグラデーションがあり、AI に置き換え可能な領域とそうでない領域に分かれると思います。 下図のように、分析要求の複雑性によって、データ分析における AI と人間の役割が分かれてきています。 単純なデータ抽出やレポート作成は、BI ツールによるセルフサービスで十分です。やや複雑な要件も、AI Agent で対応できつつあります。 しかし、複雑性の高い分析では ステークホルダーと議論しながら曖昧な要件を明確にし、分析の定義、解決する問いのディスカッションを通じて、意思決定を支援 することが求められます。 事業部と認識を揃えつつ、丁寧な合意形成も欠かせません。 この領域のデータアナリストには、 課題を主体的に定義し、その内容に即した最適な分析アプローチを設計する力が、核心的な価値として求められるようになってきています。 データ分析は過去・現在のコンテキストが重要 ここで重要なのは、企業での分析は一度きりの独立したタスクではないということです。過去の分析結果や現在の議論状況に依存する性質を持っています。 例えば、解約率の分析を行う際には、単に数値の変化を見るだけでは不十分です。 過去の解約要因、顧客セグメントの特性、競合サービスの動向、外部環境の変化 といったコンテキストがあってこそ、意味のある洞察が得られます。 一例ですが、メドレーのような医療ヘルスケア領域では、以下のような特殊な文脈が重要になるケースもあります： 診療報酬改定: 制度変更が事業指標に与える影響 季節性: 疾病の流行期や健康診断シーズンなど医療特有のパターン 規制環境: 関連省庁のガイドラインの変更等 業界慣習: 医療における事業者の意思決定プロセスの変化 こうした 蓄積された文脈（コンテキスト）があってこそ、質の高い分析が可能になります 。 しかし、モデルは自動的に賢くなっていく一方で、このコンテキストの整備は人間に委ねられています。 リソースは有限なので、求められる品質やビジネス要件を満たして期日までに意思決定を行うためには、AI が効率的に活用できるよう適切なコンテキストを整備することが不可欠です。 Analytics Knowledge as Code：なぜ今、この考え方が重要なのか そのため、分析ナレッジを「コード化」する Analytics Knowledge as Code の取り組みを始めています。その背景には 3 つの課題があります。 1. 分析による意思決定過程のナレッジ共有の課題 多くの分析組織では、事業部に専属のデータアナリストが配置される体制を取っているケースが多いと思います。 この体制では、各事業の データ構造の知識や成り立ち、過去の分析インサイト が、一人のデータアナリストに集中しがちです。 当社でもデータ分析チーム全体として、共通知見を蓄積することに課題があります。 2. AI には人間向けドキュメントだけでは不十分 社内 Wiki や分析ドキュメントは人間が読むことを前提としていますが、 AI が効率的に参照・活用するには構造化された情報が必要 です。 特に重要なのは、コンテキストエンジニアリングにおいて、AI に広範囲を探索させるよりも、 探索させる空間を狭くして、その空間内の情報の質を高めるアプローチの方がより期待に沿った応答を返してくれる という点です。 そのため、データ分析における AI が参照するナレッジは共通化して、品質の高い状態を管理する価値が高いと考えています。 3. 再利用性と保守性の担保 ナレッジは日々更新されていくため、継続的に更新し、信頼できる状態を担保する必要があります。 ソフトウェア開発のように、 バージョン管理、レビュープロセス、継続的な改善 を分析ナレッジにも適用することで、組織全体の分析品質を向上させることが必要になります。 コンテキストを「コード」として管理する手法 Analytics Knowledge as Code は、データ分析における知識やノウハウを、ソフトウェア開発のコードと同様に管理・共有する考えです。 管理する方法として、 GitHub リポジトリを活用したナレッジ管理 により、以下の要素を実現します。 データカタログやプロンプトエンジニアリングでは難しい領域をカバーします。 項目 内容 分析ナレッジの保守 分析結果のテンプレート化による標準化、バージョン管理による変更履歴の追跡 ビジネスロジックの反映 対象の分析がどのようなビジネスモデル、ロジックなのか理解させる お手本 SQL や分析手法の例示 AI にゼロから判断させずに、参考になる SQL や分析パターンを参照させる 過去分析の知識 過去の分析議論過程や意思決定の内容を参照させる Analytics Knowledge as Code のイメージ：GitHub リポジトリに分析ナレッジ蓄積 私たちは分析プロジェクトごとに、上図のような構成で、ナレッジを GitHub リポジトリで管理する取り組みを始めています。 これにより次回の分析では、過去のナレッジをベースに、条件の検討や定義のズレによるコミュニケーションエラーを減らすことができています。 今後、メンバーに変更があった際にも、過去の分析上の判断根拠を理解した上で分析に取り組めるようになることを目指しています。 MCP を活用したコンテキスト補完 ナレッジリポジトリと MCP を組み合わせることで、AI が分析時に過去の知見を参照できるようにしています。 この取り組みにおいて重要なのは、「人間が決めて、AI が分析を実行する」という以下のような役割分担です 項目 内容 問題定義 データアナリストがステークホルダーと協力して課題を明確化 分析実行 AI が SQL 生成、前処理、基本統計の処理、可視化といった分析ワークフローの実施 結果解釈 データアナリストが主導し、AI が集計結果から解釈を支援 意思決定 最終的な判断は必ず人間が行う このような役割分担を実現するために、AI が効率的に動作するための 意思決定過程の言語化と構造化された文脈の共有 が不可欠になります。 そのため、私たちは以下の要素も体系的に管理することを目指しています： 項目 内容 ドメイン知識 医療業界特有の制約や業界慣習 ステークホルダー情報 各事業部のビジネス戦略、ロードマップ、意思決定軸 過去のプロジェクトの意思決定履歴 会議の議事録や議論の文脈 データ定義と品質ルール テーブル構造やデータの具体的な使い方 これにより、データアナリストが持つドメイン知識を組織の資産として活用し、より質の高い分析を効率的に行えるようになることを想定しています。 AI とデータアナリストの役割分担 AI はデータ集計やクロス集計といった処理を得意とし、膨大な情報を効率的に整理することができます。 一方で、「何を解くべきか」という問いを立てたり、仮説検証の結果をどう意思決定につなげるかといった部分は、人間だからこそ担える役割 です。 単純な集計や事象確認は AI に任せることでスピードと効率を得られますが、複雑なテーマでは過去の分析や議論、外部環境を踏まえて設計し、ステークホルダーと議論しながら最適な進め方を探る必要があります。 ときには分析にかけるコストと成果を比較し、データ分析以外の手段を選ぶ判断も求められます。 つまり、AI は「効率的に分析を実行する力」、データアナリストは「問いを設定し意思決定へ橋渡しする力」を発揮することで、それぞれが補い合いながら最大の価値を生み出していく と考えます。 AI × 人間のベストな協働を目指して Analytics Knowledge as Code は、こうした新時代のデータアナリストに求められる能力を組織レベルで実現するための取り組みです。 LLM のモデルは今後も性能が向上していきますが、コンテキストの整備は組織が担う必要があります。 AI エディタや GitHub Copilot などのツールにより、従来はエンジニアの専門領域だったコードやリポジトリの管理の障壁は大幅に下がっていると感じています。 「なぜそれが必要なのか」「どう組織の価値に繋がるのか」 を理解し、積極的に取り組む姿勢があれば、どのようなデータ分析組織でも始められると思います。 AI が正しく・早くデータ分析を遂行するための context engineering の整備が、これからのデータ組織に求められる役割の一つと言えるでしょう。 メドレーでは今後も、医療・ヘルスケア領域における課題解決に向けて、こうした AI × データ分析の発展に取り組んでいきます。 同じような取り組みを検討されている組織の方々と、ぜひ知見を共有できればと思います。 We’re hiring! メドレーの医療プラットフォーム本部のデータ戦略グループでは、AI 時代の新しいデータ分析にチャレンジしたいデータアナリスト・データエンジニアを募集しています。Analytics Knowledge as Code の実践や、医療ヘルスケア領域でのデータ活用にご興味をお持ちの方は、ぜひお気軽にお声がけください！ 参考 The rise of "context engineering" Header image from Dex Horthy on Twitter. Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task. Most of the time when an agent is not performing reliably the underlying cause is that the blog.langchain.com pages.awscloud.com pages.awscloud.com Medley Summer Tech Blog Relay 7 日目は、人材プラットフォーム本部の山邉さんの記事です！

はじめに こんにちは。医療プラットフォーム本部 プラットフォーム開発室の島谷です。メドレーでは 2019 年から新卒エンジニアの採用を続けており、毎年新卒向けエンジニア研修を実施しています。 本記事では、2025 年に実施した新卒研修の設計思想とプログラムの全体像をご紹介します。メドレーで働くことに関心のある学生の方はもちろん、私たちの開発文化に興味のあるエンジニアの方にも、メドレーという会社の雰囲気が伝わる内容になれば幸いです。 新卒研修の目的 私たちが大切にしているのは、単なるスキルの習得にとどまらず、「課題にどう向き合うか」「どのように学び、成長していくか」といった姿勢やマインドセットを身につけてもらうことです。 新卒研修のミッションは、エンジニアとして必要な基礎技術と、問題解決に欠かせない考え方を習得し、配属後に高い成果を発揮するための土台を築くことにあります。研修では「技術的な基礎力」と「問題解決力」を重点的に養い、配属後すぐに開発を進められる状態を目指します。 もっとも、研修期間だけで一人前のエンジニアになることは難しく、だからこそ長いキャリアを通じて自ら成長し続ける姿勢が欠かせません。そうした背景があるからこそ、私たちはスキル以上に「成長し続けるための姿勢やマインドセット」を大切にしています。 研修の全体像 今年の新卒研修は、大きく 4 つのステップで構成されています。 まず社会人として必要なビジネススキルとマインドを身に付け、技術的な基礎を作り、そのうえで実務としての開発を体験し、最後に成果発表会で振り返りを行い今後の成長へつなげる。学びを段階的に深めていく一連の流れを設計しています。 期間と研修全体の流れ HC 研修、外部研修 人事部が実施する内製の HC（Human Capital） 研修と、外部研修を実施しました。HC 研修では、社会人に必要な基本動作（報連相や PDCA）やマインド（ニーズを理解しニーズに応える）の基本を習得してもらい、外部研修では、より体験的な演習を通じて社会人としての自覚を持つきっかけとしました。 基礎研修 エンジニアに求められる 横断的な基礎知識の習得、深く学び続ける姿勢の醸成、チームで成果を出すためのコミュニケーション能力の向上 を目的としています。 フロントエンド（TypeScript/React）、バックエンド（Ruby on Rails）、インフラやミドルウェア（データベース、AWS）など幅広い領域を実践形式で扱いました。 加えて、CTO・VPoE による事業説明や、メドレーでエンジニアとして働くうえでの心構えを学ぶセッションも実施。QA チームやデザインチームからは、それぞれの取り組みを共有してもらい、組織全体での開発の在り方についても学んでもらいました。今年は新たな取り組みとして、AI 活用に関する講義も行っています。 VPoE 山﨑さんによる講義の様子 事業部 OJT、開発 OJT 事業部 OJT では、複数の事業部でビジネスの理解を深め、現場業務を体験します。現場社員とのコミュニケーションを通じて、エンジニアへの期待やその期待の裏側にある状況の一端を理解し、顧客志向を育みます。 開発 OJT では基礎研修で身につけた知識やスキルを実際の開発現場で活かすフェーズです。既存プロダクトの開発チームに加わり、実務としての開発を体験します。 成果発表会 研修の集大成として、これまでの学びや開発 OJT での取り組みを整理し発表してもらいました。 メンター制度 研修を支える仕組みとして、今年も一人ひとりにメンターをつける「メンター制度」を実施しました。研修本体での学びを補い、成長をより加速させることを目的としています。 研修期間中は毎日、日報を書いてもらっています。その日取り組んだことや学んだことを弊社の行動原則（ Our Essentials ）に基づき整理し、読み手を意識した文章にまとめることがルールです。日報はメンターが必ず目を通し、毎日フィードバックを行いました。やりとりの内容は、技術的な疑問点への対応だけでなく、課題への向き合い方や物事の捉え方といった長期的な成長につながる視点を与えることを意識してもらっています。短期的な知識の提供ではなく、将来にわたって役立つ考え方を養うことを重視しました。 さらに、週次では 1on1 を実施し、振り返りの場を設けました。目標や課題を言語化し、メドレーの行動規範の観点から自らの振る舞いを点検。翌週に試す具体的な一手へと落とし込むことで、実践的な成長サイクルを回しました。もちろん、真面目な内容だけでなく、砕けた相談も自由にできる場とし、安心して取り組める環境づくりも大切にしています。 日報に対するフィードバックの様子 研修の詳細 HC 研修、外部研修 HC 研修では、社会人に求められるビジネスマナーやキャリアマインド、ロジカルシンキング、コミュニケーション能力などのポータブルスキルを学びました。座学だけでなく、ワークショップを行うことでメドレーグループの他職種の新卒とも交流も行いました。最終日はチーム対抗の寸劇を行うことで、一人ひとりの発言力を高め、一体感を生み出すことができました。 外部研修では、講師が顧客役を演じたり、チームを企業に見立てた競争環境で取り組んだりと、実際の現場に近いハイプレッシャーな状況を体験しました。その中で、適切なコミュニケーションやチームワークの大切さを実感し、成果につなげるプロセスを学ぶことを目指しました。 基礎研修 基礎研修は、実際にプロダクト開発に携わっているメドレーのエンジニアが、教材づくりから講師までを担当します。単なる知識の習得にとどまらず、判断の背景や根拠を言語化し、他者に伝わる形で残すことまで含めて学ぶことを大切にしています。 全体を通して繰り返し伝えられていたことは、「課題を終わらせること自体を目的にしない」ということです。わからない点をそのままにせず、ドキュメント・実装・計測結果を往復しながら自分の言葉で理解し直す。この姿勢を身につけることが、研修を通じて最も大事にしている部分です。 ここでは主要な研修内容を紹介します。 TypeScript/ React この研修では、フロントエンド開発の基礎として TypeScript と React を扱いました。TypeScript の型システムなどの言語仕様を理解したうえで、React のコンポーネント設計、状態管理、フック　などの基礎を学びます。 演習課題は Pull Request 形式で提出し、背景や選択肢、判断理由を文章にまとめたうえでコードレビューを受ける流れとしました。これにより、単に技術を学ぶだけでなく、技術を深く掘り下げる姿勢や、GitHub を使った開発フロー、レビューを通じたテキストコミュニケーションを実践的に身につけることを狙いとしています。 データベース（DB） 次に、データベースの基礎を幅広く学びました。テーブル設計や ER 図、リレーションの理解に加え、実際にクエリを書く演習として「クエリ 100 本ノック」に挑戦。WHERE や JOIN といった開発や分析で頻出する構文を身につけました。さらに、クエリ実行計画の読み方やインデックス設計など、パフォーマンスチューニングにも取り組みました。長期的な保守性や変更容易性、パフォーマンスを意識しながらデータベースを扱うための基礎を、実践的に学ぶ内容です。 アプリケーション開発実践 フロントエンドとバックエンドをつなげた実践的な開発演習として、Rails on Rails で API を実装し、React で SPA（Single Page Application）を構築する研修を行いました。フードデリバリーサービス（Uber Eats のようなアプリ）を題材に、決められた要件定義から設計、開発、テストまでを一気通貫で経験します。 ここでは、TypeScript/React 研修で身につけた基礎を応用しながら、実際にプロダクトとして動くアプリケーションを作り上げることに挑戦しました。仕様の整理からテスト設計までを通じて、フロントエンドとバックエンドを横断的に理解し、開発に必要な実践力を養うことが目的です。 Docker / AWS 最後に、インフラ領域の基礎として Docker と AWS を扱いました。メドレーでは AWS を中心に利用しているため、実際にアプリケーションを AWS 上にデプロイし、動作させるところまでを体験します。可用性やスケーラビリティを考慮したシステム構築に加え、ログ、監視、アラート設定といった運用面も含めて一通り設定。さらに簡易的に負荷をかけ、スケールアウトやアラートが正しく機能するかを検証しました。単に作るだけでなく、安定的に運用できる状態にすることの重要性を学ぶハンズオンとなっています。 事業部 OJT、開発 OJT 基礎研修を終えたあとは、現場社員から研修を受ける事業部 OJT に取り組みました。事業部によって取り組む内容は異なりますが、市場環境やミッション、今後の方向性を理解することから始まり、Sales や Customer support の業務の一部を体感します。 その後は、既存プロダクトの開発現場に加わり、実際の開発を体験する OJT に取り組みました。ここでは、抽象度の高い課題に対して自ら問題を整理し、解決に向けた手順を考え、周囲と協調しながら前に進める力が求められます。 開発の過程では、リリースに至るまでの一連のプロセスを経験します。わからないことを適切に言語化して周囲に伝え、協力を得ながら課題を乗り越えることも重要なポイントです。 今年の OJT で取り組まれていたタスクをいくつかピックアップしてみます。 デザインシステムの MCP サーバー構築 顧客向け管理画面の UI/UX 改善 電子カルテにおける書類作成機能の改善 患者向け通知機能の UX 改善 タスクを進める中では、先輩エンジニアから様々な観点でフィードバックを受けます。これまで自分になかった視点や考え方に触れることで、新卒メンバーは大きな学びを得ていた様子でした。 成果発表会 研修の締めくくりとして行ったのが成果発表会です。ここでは、研修や OJT を通じて学んだこと、自身の成長・変化を自分の言葉で整理し、周囲に伝える力を養うことを目的としています。単に振り返るだけでなく、学びを言語化して共有することで、個人の経験をチーム全体の資産へと昇華させる場でもあります。 当日は、CTO や VPoE、メンター、配属先のマネージャーなど、研修に関わった多くのメンバーが参加しました。 新卒の皆さんは緊張した面持ちでしたが、先輩たちから温かいフィードバックや応援の言葉が寄せられ、会場は和やかな雰囲気に包まれていました。 各 VP の皆様を始め、関わった方々からコメントいただきました まとめ 研修という限られた期間の中で、一人前のエンジニアとしての力をすべて身につけることは容易ではありません。だからこそ、この期間を通じて「これから成長していくための土台」を築いてもらうことを大切にしてきました。本番はここから始まります。 新卒の皆さんには、これからは仲間として実際の開発現場で活躍しながら、さらに経験を積み重ねていくことを期待しています。私たちのミッションである 「医療ヘルスケアの未来をつくる」 を実現するために、それぞれが力を発揮し、共に歩んでいけることを心から楽しみにしています。 We’re hiring! サマーインターン参加者募集中！ メドレーでは、この夏に開催するエンジニア向けサマーインターンの参加者を募集しています。 実際のプロダクト開発を体験しながら、エンジニアとしての成長につながる機会を提供します。 「まずは話だけ聞いてみたい」「雰囲気を知りたい」という方に向けて、カジュアル面談も実施しています。少しでも興味をお持ちの方は、お気軽にご応募ください。 募集はこちら サマーインターン（エンジニア新卒） / 株式会社メドレー 株式会社メドレーはサマーインターン（エンジニア新卒）を採用しています。 open.talentio.com 中途採用も積極募集中！ また、エンジニアをはじめとした中途採用も積極的に行っています。 ヘルスケアの未来を一緒につくる仲間を幅広く募集していますので、ぜひこちらもご覧ください。 中途採用の募集一覧はこちら 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

この記事は メドレー夏のブログリレー2025 5日目の記事です。 はじめに こんにちは！メドレーでDevRelをしている重田です。 突然ですが、転職先を探す時に実際に働く環境や雰囲気って気になりますよね？ この記事では、メドレーのエンジニアが普段どんな環境で仕事をしているのかを写真メインでご紹介します！ 「メドレーのオフィスで働きたい！」「働くイメージが持てた！」と思っていただけたら嬉しいです🙌 では、早速オフィスツアースタートです📣 🏢 私たちが働くオフィス 私たちのオフィスは日比谷線 六本木駅直結の六本木ヒルズ森タワーの12階と13階にあります。 詳細は以下記事でご紹介しています🙋‍♀️ メドレーオフィス（13階）へのアクセスと入館方法のご案内 [六本木ヒルズ森タワー]メドレーのオフィスを初披露 🏙️外観 六本木ヒルズ森タワーは54F建て、高さ238メートルの超高層オフィスビルです。 上を見上げる高さで、たまに見ると「おお〜〜都会だ！」となり背筋が伸びます。笑 🏥13階 エンジニアの中でも医療プラットフォームのプロダクト開発エンジニアやコーポレートITのメンバーが13階で働いています。 エントランス（受付） 13階のエントランスは清潔感のある白の壁に温かみのある木目調の床です。 憩いスペース 約100席と、広々したスペースです。テーブル席の他、ソファもあるのでゆったりと過ごせます。 カウンターには賞状などが飾られています。 🏥12階 エンジニアの中でも人材プラットフォームのプロダクト開発エンジニアが12階で働いています。 憩いスペース こちらは今年の春に増設されたスペースです！ ランチだけではなく、1on1やチームミーティングでも大活躍のスペースです。 ボックス席にはディスプレイが付いており、チームミーティングの際に役立ちます。 ゆっくりしたいときはこの席がおすすめです🍵 東京タワーを眺めて仕事ができるのは六本木、そして12階に位置する特権です🗼 憩いスペース入口には弊社プロダクトを体験できるコーナーがあります。 また、自動販売機2台・コーヒー販売機2台・食品自動販売機1台・冷蔵庫が完備されています☕️ 小腹が減った時の救世主🙏コンビニに行くのが面倒な時に大活躍です！ 持参/購入したお弁当を温められるのも嬉しいポイント💡 🏥共通 会議室 会議室は50室以上あり、来客専用・社内専用の会議室が分かれています。 ✨メドレーのカルチャー「クリーンデスクポリシー」に込められた想い メドレーが大切にしているカルチャーのひとつに「クリーンデスクポリシー」があります。これはデスクの上には仕事道具以外置かない、帰宅時にはモニタ・キーボード・マウス以外は全て片付けるというルールのことです。 「クリーンデスクポリシー」は代表の瀧口が 「佐藤可士和の超整理術」 という本から影響を受け、創業時から大切にしているカルチャーです。なぜ「クリーンデスクポリシー」が大切なのか、瀧口が社内で共有している資料から引用してご紹介します。 整理整頓には、視点が必要です。複雑なものであれば、それぞれの因果関係を見抜き、何が大切なのかの優先順位をつけることが必要です。「頭で理解しているつもりのこと」と「身体に染み付いて実践できること」には大きな隔たりがあります。実践への近道は、たった一つの象徴的なことを徹底することではないでしょうか。 例えば、この記事 「日本電産が赤字会社を速攻で再生できたワケ」 の「組織体質を変える一番の早道は」を読んでみてください。整理・整頓・清潔・躾（自主的な）を徹底して、営業回数を増やせば成功すると書いています。 そもそも仕事机は、仕事をするためのものです。クリーンデスクというのは整理整頓ができる組織であることの象徴です。このような背景で、クリーンデスクポリシーは僕にとって、大切にしたい考え方なのです。 実際、社員の机は常に整理されています。 また、過去にも「クリーンデスクポリシー」に触れているのでぜひご覧いただけると嬉しいです！ [六本木ヒルズ森タワー]メドレーのオフィスを初披露 📚スキルアップ支援やライフステージに合わせた柔軟な働き方を実現 この記事では主にエンジニアの制度をご紹介します！ 支援制度 社内勉強会支援 社内で勉強会を開催する際の飲食補助が出ます！ 書籍購入の補助 会社の費用で購入可！ ※資産管理の観点から電子書籍は除く 資格取得支援 AWS認定試験・Ruby技術認定試験を会社の費用で受験可！ ※一定条件あり カンファレンス参加費用の補助 RubyKaigi などの外部カンファレンスへ会社の費用で参加可！ 制度を利用する際は、以下のようにSlackで申請をしています。 希望PC・モニター・アーロンチェアの貸与 エンジニアの方には希望PCとモニターが貸与されます。 基本的にはスペックも自由に選べます🙆‍♀️ 湾曲型モニター また、希望者にはアーロンチェアも用意しています。 アーロンチェア 働く環境 よくある質問をもとにご紹介します！ Q. 勤務時間は決まっていますか？ A. 開発職では裁量労働制を採用しており、多くの社員は事業部の稼働時間に合わせて10:00～19:00で勤務しています。 一方で、子育て中の社員については、勤務時間中に一時的に離席するなど、個々の状況に応じた柔軟な体制をとっています。 Q. 出社とリモートの頻度はどのぐらいですか？ A. エンジニア/デザイナーの場合は週2出社、週3リモートをベースにしています。 こちらも勤務時間と同様、体調やご家庭の事情など、柔軟に対応できる体制になっています。 Q. キャリアロールはどのようになっていますか？ A. 「スペシャリスト」と「マネジメント」の2つに大別されます。事業責任者のロールも存在しますが、役職ではなく、一つのロールとして位置づけています。 Q. 担当するプロダクトは決まっていますか？ A. エージェントからのご紹介時・スカウトをお送りする際などにプロダクトを限定している場合もありますが、基本的には選考を通じて皆様のご希望や志向、スキルスタックなども合わせてご提案・ご相談しながら決めています。 イベントでも大活躍のオフィス メドレーでは定期的にイベントを開催したり、オフィスを他社様や外部コミュニティのイベント会場として提供したりしています。 こちらは5月にリンケージ社とヘンリー社と開催したイベント、 HealthTech Meetup の様子です。 Roppongi.rb 、 Omotesando.rb の会場としても定期的にご利用いただいています🙌 🍀最後に 最後までご覧いただきありがとうございました！ メドレーで働くイメージはつきましたでしょうか!? 直近では、以下のイベントを開催予定です！ 少しでもご興味のある方は、ぜひイベントを機にオフィスにいらしてください！ご参加お待ちしております✨ 9/4(木)19:30 Omotesando.rb#113 9/5(金)19:00 【有料プランユーザー限定×オフライン】MagicPodユーザーミートアップ We’re hiring 最後まで読んでいただきありがとうございます！ メドレーでは、一緒に働く仲間を大募集中です👫 少しでも興味を持っていただけましたら、ぜひカジュアル面談でお待ちしています！ 🤝 募集一覧 🗣️ カジュアル面談 Medley Summer Tech Blog Relay 6 日目は、医療プラットフォーム本部の安東(Andō)さんの記事です！ それでは良い週末をお過ごしください！

こんにちは！メドレーでDevRelをしている重田です。 今年も暑い日が続いていますがいかがお過ごしですか？ メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 8/25(月)〜9/26(金)まで毎日異なるメンバーが技術やエンジニアリング、個人開発など幅広いテーマでテックブログを公開していきます！ 本記事にて毎日ブログを追記更新していくので、ぜひお楽しみください✨ ※土日祝を除く ブログリレーカレンダー 🗓️第1週(8/25~8/29) Day1：SRE屋のひとりごと（玉井） Day2：AIで実現する10x時代の組織学習型QA（小島） Day3：Lambda@Edgeを使った画像リサイズ配信の構築記録（森川） Day4：Design→Codeの現実解を考える（中村） Day5：メドレーエンジニアの働く環境をご紹介（重田） 🗓️第2週(9/1~9/5) Day6：データアナリストの分析プロセスにおけるAI活用（安東） Day7：データの何かについて（山邊） Day8：事業部=>QAにジョブチェンジしてみた話（内堀） Day9：OpenSearchについて（仮）（山下） Day10：WACATE2025夏に参加した話（井津） 🗓️第3週(9/8~9/12) Day11：エンジニア組織におけるAI活用状況とモニタリング（仮）（倉林） Day12：デザイナーは何考えながらデザイン作ってるのか書きます（仮）（近藤） Day13：TBD（稲村） Day14：医療PFマーケティングアセットについて書きます（進） Day15：DRの話 or 何か（小泉） 🗓️第4週(9/16~9/19) Day16：TBD（山田） Day17：GraphQL ruby読んでみた（仮）（川原） Day18：歯科向け電子レセプトビューアを作ってみた（平林） Day19：Playwright * デザインシステムMCPを使って楽したい (仮)（池田） 🗓️第5週(9/22~9/26) Day20：生成AIを使用してバグを効率的に解消した話(仮)（山下） Day21：CLINICS負荷試験の話かSLO運用について話します（山田） Day22：生成AI時代に向けて、開発効率10xを支えるリリース戦略の見直し（桶谷・小島） Day23： TBD（前田） 🍉We’re hiring! メドレーでは、「医療ヘルスケアの未来をつくる」仲間を大募集しています！ 少しでも興味をお持ちいただけましたら、ぜひ、カジュアル面談にお越しください🙌 メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp Medley Engineer Entrance Book この度は株式会社メドレーに興味をお寄せいただきありがとうございます。本資料は、メドレーへの転職をご検討いただいている皆様に、当社をより深くご理解いただくために作成いたしました。 medley-inc.notion.site

はじめに こんにちは！ 医療プラットフォーム本部 プラットフォーム開発室 SRE グループの山田です。 医療機関向け SaaS である CLINICS の安定稼働とシステム信頼性の向上に取り組んでいます。 メドレーは 7 月 11 日、12 日に TOC 有明 （東京都江東区）で開催された SRE NEXT 2025 に LOGO Sponsor として協賛しました！ SRE NEXT は、信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスです。 医療プラットフォーム本部 SRE グループは発足して間もないため、他社のさまざまな挑戦や SRE プラクティスを学ぶべく、私を含め数名のエンジニアが参加し、たくさんの方々と交流させていただきました。 本レポートでは、SRE NEXT 2025 の会場や企業ブースの様子、そして発表の内容についてご紹介します。 会場の様子 SRE NEXT 2025 は、オンラインとオフラインのハイブリッド形式で開催されました。 50 を超える企業の協賛のもと、740 名もの SRE エンジニアが現地に参加しました。 広々とした会場 企業ブースも多数出展しており、SRE にまつわるアンケートや SRE プラクティスの紹介など非常に面白かったです。 株式会社タイミー様のブースにお邪魔させていただきました 2 日目の最後には懇親会も催され、様々な SRE エンジニアの方と交流することができました。 懇親会の様子 発表の様子 どのセッションも大変興味深かったのですが、特に印象深かった下記のセッションについてご紹介します。 Day1: SRE 不在の開発チームが障害対応と 向き合った 100 日間 Day2: 伴走から自律へ：形式知へと導く SRE イネーブリングによる、プロダクトチームの信頼性オーナーシップ向上 Day2: Four Keys から始める信頼性の改善 SRE 不在の開発チームが障害対応と 向き合った 100 日間 (Loglass 勝丸真さん) 引用元: speakerdeck.com カスタマーサクセスチームからのフィードバックをきっかけに、インシデント対応の改善に取り組んだ際の課題と、その解決策が紹介されました。 開発チームが障害対応に直面する中で、エンジニアによって対応品質にばらつきがあり、カスタマーサクセスチームから「障害対応がスムーズに進まない」「全体の体制や連絡手段が曖昧」といったフィードバックを受けるという課題があったとのことです。特に、あるエンジニアは単純な修正作業のみを行う一方で、別のエンジニアは影響範囲の特定やカスタマーサクセスへの回避策伝達まで含めた包括的な対応を実施するなど、対応者によって大きな差が生じていました。 そこで、専任のインシデントコマンダーチームを編成し、全エンジニアによるローテーション制から専門化による品質向上を図るアプローチへ切り替えたことが説明されました。また、障害対応フローの明確化とシンプル化、インシデントレベルの再定義、外部ツール「Warroom」の導入による自動記録・AI 要約機能の活用についても具体的な手法が紹介されました。 さらに、プロジェクトの推進においてはプロセス整備だけでなく、ビジネスチームやプロダクトチームとの継続的な対話を重視し、「なぜこの変更が必要なのか」という背景を丁寧に共有することで組織全体の理解を深め、技術的なベストプラクティスとビジネス要求のギャップを埋めていく文化づくりの重要性も解説されていました。 所感 このセッションで特に印象的だったのは、教科書的なベストプラクティスをそのまま適用するのではなく、現場の実情に合わせて大胆な割り切りを行っていた点です。中でも、「全エンジニアがインシデントコマンダーになる」という理想を一旦捨て、あえて属人化を許容して専門チームを作るという判断は、実践が進んでいるからこその現実的な選択だと感じました。 CLINICS SRE でも、理想的なインシデント対応体制を構築しようとする際に、全エンジニアのスキルレベルやモチベーションのばらつきという現実的な課題に直面することがあります。この発表から学んだのは、完璧な体制を目指すよりも、まずは実効性のある仕組みを作り上げることの重要性です。専門チームによる安定した対応基盤があってこそ、その後の全体的なスキル向上や体制の民主化が可能になるのだと理解しました。 また、プロセス整備だけでは解決できない人間関係や組織文化の課題に対し、継続的な対話を通じて理解を深めていく姿勢も非常に参考になりました。CLINICS でも、開発チームや事業部との間で、障害対応時の連携や認識に齟齬が生じることは少なくありません。この発表から学んだ対話を重ねることが重要であるという点は、今後の SRE の取り組みに活かしていきたいと思います。 現場の泥臭い課題に真摯に向き合い、組織として解決策を模索する姿勢は、同じような課題に取り組む SRE チームにとって大きな学びとなる発表でした。 伴走から自律へ：形式知へと導く SRE イネーブリングによる、プロダクトチームの信頼性オーナーシップ向上　（ビズリーチ 佐々木康徳さん） 引用元: speakerdeck.com このセッションでは、WAF 運用をプロダクトチームへイネーブリングするにあたり、SECI モデルに基づいて実践された事例が紹介されました。 具体的には、共同化、表出化、連結化、内面化の 4 つのプロセスを通じて、SRE が持つ暗黙知を段階的にプロダクトチームに移転し、チームのオーナーシップを醸成する具体的な方法が示されました。 この取り組みにより、WAF 運用をプロダクトチームへ移管できただけでなく、プロダクト開発チームのオーナーシップ向上やコミュニケーションの効率化といった効果も得られたと説明されていました。 所感 このセッションで、SECI モデルという概念を初めて知りました。 私自身、暗黙知から他者への暗黙知のプロセスを飛ばしていきなりドキュメント化（表出化）から始めたり、連結化まで進めずに終わってしまったりと、SECI モデルの観点から見ると不完全な取り組みでイネーブリングに失敗した経験があります。そのため、今回の発表は非常に納得感があり、共感を深く覚えました。 今後、CLINICS SRE でも SECI モデルを意識した開発チームへのイネーブリングを進めていきたいと考えています。 Four Keys から始める信頼性の改善　（DMM 尾崎耕太さん） 引用元: speakerdeck.com このセッションは、Four Keys (チーム生産性を可視化することを目的とした指標のこと) を軸に DevOps 文化を作り、その結果としてユーザにとって魅力的で信頼されるプロダクトを提供することを目指す戦略を取ることで、信頼性の改善を進めたという事例と導入効果について紹介されました。 信頼性指標である SLI/SLO やエラーバジェットは、機能開発チームにとって理解しにくく、日々の開発サイクルに組み込みにくいという課題がありました。そこで、より開発プロセスに近く、チームがオーナーシップを持ちやすい Four Keys を採用。これを軸に DevOps 文化を醸成することで、段階的に信頼性を獲得するというアプローチをとったと説明されています。 その結果、Four Keys の数値が改善しただけでなく、プロダクト開発チームが自律的に変化に取り組むようになったという大きな効果があったと紹介されていました。 所感 最も印象的だったのは、「指標の改善が目的ではなく、その先の状態が目標」という考え方です。指標を取るのは気づきを得て、アクションに繋げるためのものであるため、「指標を改善すること」にこだわりすぎない方が良いという話には深く共感できました。数値の向上に注力するあまり、なぜその指標を見ているのかという根本的な目的を見失ってしまうことは、実際の現場でもよく起こりがちな問題です。 CLINICS でも SLO 運用を行っていますが、この考え方は非常に参考になりました。SLO の数値を改善することに集中してしまい、そもそもなぜ SLO を設定しているのか、SLO 運用を通じて何を実現したいのかという本質的な目的を見失わないよう気をつけたいと思います。 SLO 運用をした先に SRE チームが何を目指しているのか、サービスの信頼性向上によってどのような価値をユーザーや事業に提供したいのかという意識を、開発チームにもさらに伝えられるようにしたいと感じました。 また、開発チームがオーナーシップを持って変化に取り組んでいることが重要という点も非常に納得できました。具体的な成果よりも、開発チーム自身が主体的に改善活動を推進していることの方が本質的な価値があるという考え方は、持続可能な改善文化を構築する上で欠かせない要素だと思います。 実践面で特に参考になったのは、単純に Four Keys を導入するのではなく、プロダクト開発チームと対話してアクションに繋げられるように Keys を詳細化している点です。開発者が「なぜ悪化したのか」「どの活動が効果的だったのか」を理解できるよう工夫している取り組みは、実際の現場での指標活用を考える上で非常に実用的なアプローチだと感じました。 さいごに 他社のさまざまな挑戦や SRE プラクティスを学べただけでなく、たくさんの方々と交流することができて刺激的な 2 日間でした。 来年も 7 月 10 日、11 日に TOC 有明 での開催を予定しているそうです。 メドレーは今後も SRE NEXT だけでなく、他の技術イベントやコミュニティの発展を積極的に支援し、参加、貢献していきます。 運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございました！ メドレーではエンジニアを積極採用中です！ エンジニアを積極採用中です メドレーでは、「医療ヘルスケアの未来」を共に創っていく SRE エンジニアを積極的に採用しています。 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 募集の一覧 https://www.medley.jp/jobs/ ※カジュアル面談ご希望の際は、<その他> にてその旨をご記載ください

はじめに こんにちは！ 医療プラットフォーム本部 プラットフォーム開発室 SRE グループの山田です。 医療機関向け SaaS である CLINICS の安定稼働とシステム信頼性の向上に取り組んでいます。 メドレーは 7 月 11 日、12 日に TOC 有明 （東京都江東区）で開催された SRE NEXT 2025 に LOGO Sponsor として協賛しました！ SRE NEXT は、信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスです。 医療プラットフォーム本部 SRE グループは発足して間もないため、他社のさまざまな挑戦や SRE プラクティスを学ぶべく、私を含め数名のエンジニアが参加し、たくさんの方々と交流させていただきました。 本レポートでは、SRE NEXT 2025 の会場や企業ブースの様子、そして発表の内容についてご紹介します。 会場の様子 SRE NEXT 2025 は、オンラインとオフラインのハイブリッド形式で開催されました。 50 を超える企業の協賛のもと、740 名もの SRE エンジニアが現地に参加しました。 広々とした会場 企業ブースも多数出展しており、SRE にまつわるアンケートや SRE プラクティスの紹介など非常に面白かったです。 株式会社タイミー様のブースにお邪魔させていただきました 2 日目の最後には懇親会も催され、様々な SRE エンジニアの方と交流することができました。 懇親会の様子 発表の様子 どのセッションも大変興味深かったのですが、特に印象深かった下記のセッションについてご紹介します。 Day1: SRE 不在の開発チームが障害対応と 向き合った 100 日間 Day2: 伴走から自律へ：形式知へと導く SRE イネーブリングによる、プロダクトチームの信頼性オーナーシップ向上 Day2: Four Keys から始める信頼性の改善 SRE 不在の開発チームが障害対応と 向き合った 100 日間 (Loglass 勝丸真さん) 引用元: speakerdeck.com カスタマーサクセスチームからのフィードバックをきっかけに、インシデント対応の改善に取り組んだ際の課題と、その解決策が紹介されました。 開発チームが障害対応に直面する中で、エンジニアによって対応品質にばらつきがあり、カスタマーサクセスチームから「障害対応がスムーズに進まない」「全体の体制や連絡手段が曖昧」といったフィードバックを受けるという課題があったとのことです。特に、あるエンジニアは単純な修正作業のみを行う一方で、別のエンジニアは影響範囲の特定やカスタマーサクセスへの回避策伝達まで含めた包括的な対応を実施するなど、対応者によって大きな差が生じていました。 そこで、専任のインシデントコマンダーチームを編成し、全エンジニアによるローテーション制から専門化による品質向上を図るアプローチへ切り替えたことが説明されました。また、障害対応フローの明確化とシンプル化、インシデントレベルの再定義、外部ツール「Warroom」の導入による自動記録・AI 要約機能の活用についても具体的な手法が紹介されました。 さらに、プロジェクトの推進においてはプロセス整備だけでなく、ビジネスチームやプロダクトチームとの継続的な対話を重視し、「なぜこの変更が必要なのか」という背景を丁寧に共有することで組織全体の理解を深め、技術的なベストプラクティスとビジネス要求のギャップを埋めていく文化づくりの重要性も解説されていました。 所感 このセッションで特に印象的だったのは、教科書的なベストプラクティスをそのまま適用するのではなく、現場の実情に合わせて大胆な割り切りを行っていた点です。中でも、「全エンジニアがインシデントコマンダーになる」という理想を一旦捨て、あえて属人化を許容して専門チームを作るという判断は、実践が進んでいるからこその現実的な選択だと感じました。 CLINICS SRE でも、理想的なインシデント対応体制を構築しようとする際に、全エンジニアのスキルレベルやモチベーションのばらつきという現実的な課題に直面することがあります。この発表から学んだのは、完璧な体制を目指すよりも、まずは実効性のある仕組みを作り上げることの重要性です。専門チームによる安定した対応基盤があってこそ、その後の全体的なスキル向上や体制の民主化が可能になるのだと理解しました。 また、プロセス整備だけでは解決できない人間関係や組織文化の課題に対し、継続的な対話を通じて理解を深めていく姿勢も非常に参考になりました。CLINICS でも、開発チームや事業部との間で、障害対応時の連携や認識に齟齬が生じることは少なくありません。この発表から学んだ対話を重ねることが重要であるという点は、今後の SRE の取り組みに活かしていきたいと思います。 現場の泥臭い課題に真摯に向き合い、組織として解決策を模索する姿勢は、同じような課題に取り組む SRE チームにとって大きな学びとなる発表でした。 伴走から自律へ：形式知へと導く SRE イネーブリングによる、プロダクトチームの信頼性オーナーシップ向上　（ビズリーチ 佐々木康徳さん） 引用元: speakerdeck.com このセッションでは、WAF 運用をプロダクトチームへイネーブリングするにあたり、SECI モデルに基づいて実践された事例が紹介されました。 具体的には、共同化、表出化、連結化、内面化の 4 つのプロセスを通じて、SRE が持つ暗黙知を段階的にプロダクトチームに移転し、チームのオーナーシップを醸成する具体的な方法が示されました。 この取り組みにより、WAF 運用をプロダクトチームへ移管できただけでなく、プロダクト開発チームのオーナーシップ向上やコミュニケーションの効率化といった効果も得られたと説明されていました。 所感 このセッションで、SECI モデルという概念を初めて知りました。 私自身、暗黙知から他者への暗黙知のプロセスを飛ばしていきなりドキュメント化（表出化）から始めたり、連結化まで進めずに終わってしまったりと、SECI モデルの観点から見ると不完全な取り組みでイネーブリングに失敗した経験があります。そのため、今回の発表は非常に納得感があり、共感を深く覚えました。 今後、CLINICS SRE でも SECI モデルを意識した開発チームへのイネーブリングを進めていきたいと考えています。 Four Keys から始める信頼性の改善　（DMM 尾崎耕太さん） 引用元: speakerdeck.com このセッションは、Four Keys (チーム生産性を可視化することを目的とした指標のこと) を軸に DevOps 文化を作り、その結果としてユーザにとって魅力的で信頼されるプロダクトを提供することを目指す戦略を取ることで、信頼性の改善を進めたという事例と導入効果について紹介されました。 信頼性指標である SLI/SLO やエラーバジェットは、機能開発チームにとって理解しにくく、日々の開発サイクルに組み込みにくいという課題がありました。そこで、より開発プロセスに近く、チームがオーナーシップを持ちやすい Four Keys を採用。これを軸に DevOps 文化を醸成することで、段階的に信頼性を獲得するというアプローチをとったと説明されています。 その結果、Four Keys の数値が改善しただけでなく、プロダクト開発チームが自律的に変化に取り組むようになったという大きな効果があったと紹介されていました。 所感 最も印象的だったのは、「指標の改善が目的ではなく、その先の状態が目標」という考え方です。指標を取るのは気づきを得て、アクションに繋げるためのものであるため、「指標を改善すること」にこだわりすぎない方が良いという話には深く共感できました。数値の向上に注力するあまり、なぜその指標を見ているのかという根本的な目的を見失ってしまうことは、実際の現場でもよく起こりがちな問題です。 CLINICS でも SLO 運用を行っていますが、この考え方は非常に参考になりました。SLO の数値を改善することに集中してしまい、そもそもなぜ SLO を設定しているのか、SLO 運用を通じて何を実現したいのかという本質的な目的を見失わないよう気をつけたいと思います。 SLO 運用をした先に SRE チームが何を目指しているのか、サービスの信頼性向上によってどのような価値をユーザーや事業に提供したいのかという意識を、開発チームにもさらに伝えられるようにしたいと感じました。 また、開発チームがオーナーシップを持って変化に取り組んでいることが重要という点も非常に納得できました。具体的な成果よりも、開発チーム自身が主体的に改善活動を推進していることの方が本質的な価値があるという考え方は、持続可能な改善文化を構築する上で欠かせない要素だと思います。 実践面で特に参考になったのは、単純に Four Keys を導入するのではなく、プロダクト開発チームと対話してアクションに繋げられるように Keys を詳細化している点です。開発者が「なぜ悪化したのか」「どの活動が効果的だったのか」を理解できるよう工夫している取り組みは、実際の現場での指標活用を考える上で非常に実用的なアプローチだと感じました。 さいごに 他社のさまざまな挑戦や SRE プラクティスを学べただけでなく、たくさんの方々と交流することができて刺激的な 2 日間でした。 来年も 7 月 10 日、11 日に TOC 有明 での開催を予定しているそうです。 メドレーは今後も SRE NEXT だけでなく、他の技術イベントやコミュニティの発展を積極的に支援し、参加、貢献していきます。 運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございました！ メドレーではエンジニアを積極採用中です！ エンジニアを積極採用中です メドレーでは、「医療ヘルスケアの未来」を共に創っていく SRE エンジニアを積極的に採用しています。 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 募集の一覧 https://www.medley.jp/jobs/ ※カジュアル面談ご希望の際は、<その他> にてその旨をご記載ください

こんにちは。医療プラットフォーム本部の日下（ @mkusaka ）です。 私の所属する統合基盤チームでは、医療プラットフォームの複数のシステムを支えるサービス群を運用しています。 これまではユーザーへの影響を最小限に抑えるため、リリース作業を深夜や早朝に限定していましたが、その結果として運用チームへの負担増やリリースタイミングの制約といった課題が生じていました。 こうした課題を解決し、日中でも安全かつ段階的にリリースを行うため、統合基盤に Blue/Green デプロイメントを導入しました。今回はその詳細を紹介します。 統合基盤コンポーネントの紹介 統合基盤チームでは、患者と医療機関の双方に使われる医療システムの根幹を支える重要な基盤の開発・運用を行っています。 管理するコンポーネントは、「医療機関向け」と「患者向け」の 2 つに分類できます。 「医療機関向け」機能は、 Pharms 、 Dentis 、 CLINICS などの各サービス間でコミュニケーションのハブとして機能し、イベントの配信を行います。 一方、「患者向け」機能としては、 総合医療アプリ CLINICS から送られたリクエストを適切なサービスに振り分けるゲートウェイの役割を担っています。 このようなアーキテクチャを採用した背景には、医療プラットフォームが複数のプロダクト（Pharms、Dentis、CLINICS など）を統合的に運用する必要があるという背景があります。 医療機関向けには、いずれか一方のシステムの状態に他方が引きずられない構成とすることで、各医療機関の業務システムの可用性を最大限高めるという狙いがあります。 一方、患者向けには、複数の医療機関向けシステムに対して共通のアプリからアクセスできるようにするため、患者情報の一元管理や統一された認証基盤の整備が不可欠です。これにより、患者にとってシームレスな体験を実現し、より効率的で質の高い医療サービスの提供を目指しています。 つまり、統合基盤が管理するこれらのコンポーネントに障害が発生すると、サービス間にまたがる業務だけでなく、患者向けのサービス提供にも影響が及ぶため、高い可用性が求められています。 Blue/Green デプロイメント導入の目的 統合基盤の各サービスは、AWS ECS（Elastic Container Service）上で運用されています。これまでは、運用のシンプルさからローリングデプロイを採用していました。しかしこの手法では、デプロイが開始されると新バージョンが一斉に展開されてしまうため、問題発生時の影響範囲が広く、迅速なロールバックも難しいという課題がありました。 こうした課題への対策として、Blue/Green デプロイメントを導入することを決定しました。 Blue/Green デプロイメントとは、新旧 2 つの環境（Blue と Green）を用意し、新バージョンを片方に展開した後、徐々にトラフィックを移行していく方法です。これにより、致命的な問題やパフォーマンスの劣化を早期に発見し、迅速なロールバックが可能になります。 Blue/Green デプロイメントの要件と独自実装の選択 システムを Blue/Green デプロイする際に、大きく分けて 2 つの考慮事項がありました。 1 つ目は 2 つの明確な検証フェーズを設けることです。 致命的なエラー検出フェーズ ：新環境に約 10%のトラフィックを流し、システムの安定性を確認。 負荷時のパフォーマンス検証フェーズ ：新環境に約 50%のトラフィックを流し、負荷によるパフォーマンスの劣化を確認。 これら 2 つのフェーズを明確に設け、十分な検証時間を取ることで、より高い自信をもってリリース作業を進めることが可能になると考えました。 2 つ目は非同期処理を担当する Worker サービスを新旧の環境それぞれで用意することです。 Worker サービスでは、ジョブが SQS（Simple Queue Service）キューに投入されてから実際に処理されるまでタイムラグがあります。その間に新しい環境へ切り替えが行われると、旧環境のジョブが新環境の Worker によって処理され、データの不整合が起きる可能性があります。このリスクを防ぐため、Blue と Green の環境それぞれに独立した SQS キューを用意し、それぞれのジョブが確実に自環境の Worker で処理を完了する形式を取ることとしました。 ECS には CodeDeploy を利用した標準的な Blue/Green の段階的デプロイ戦略として、Canary デプロイ（一部のトラフィックで検証後、一気に切り替え）や Linear デプロイ（一定割合ずつ徐々に適用）が提供されています。しかし、私たちが求めるようなトラフィック調整にはこれらの手法が十分に適しておらず、また SQS を分離するための Blue 環境/Green 環境どちらかを判定するような仕組みが整備されていないようだったので、内製化することとしました。 採用した構成 自前の Blue/Green デプロイを実現するため、以下の構成を採用しました。 ALB（Application Load Balancer）の weighted target groups を利用して、トラフィックを柔軟に調整しています。 ECS 環境は Blue/Green のそれぞれが並行稼働し、SQS は各環境ごとに独立したキューを設けます。 新バージョンは Green 環境として起動し、初期状態では Blue 環境（現行バージョン）がすべてのトラフィックを処理します。その後、Green 環境へのトラフィックを 10%、50%と段階的に増やしながら、各段階でメトリクスの監視を行います。 10%の段階で致命的なエラーがないことを確認し、50%の段階で負荷時のパフォーマンスに問題ないと判断されたら、最終的にすべてのトラフィックを Green 環境へ切り替えます（100%）。 また、各種ステップは承認操作やロールバックも含めて CI 上で完結するように整備を行うことで、デプロイの複雑性も抑えています。 実装サンプル Terraform と AWS CLI を組み合わせて実装しています。 ALB の weighted routing 設定（Terraform） resource "aws_lb_listener_rule" "weighted_routing" { listener_arn = aws_lb_listener. https . arn action { type = "forward" forward { target_group { arn = aws_lb_target_group. app_blue . arn weight = 100 # 初期状態では Blue が 100% } target_group { arn = aws_lb_target_group. app_green . arn weight = 0 # Green は 0% } } } # AWS CLI で weight を動的に調整するため、Terraform での変更を無視 lifecycle { ignore_changes = [ action ] } } トラフィック配分の変更（AWS CLI） デプロイ時のトラフィック配分は、AWS CLI を使用して動的に変更します。実際の運用では、Green の weight を指定すると Blue が自動的に 100 - Green になるように調整しています： # Green の weight を指定して Blue/Green の配分を設定 # 例：GREEN_WEIGHT=10 の場合、Blue=90、Green=10 に自動計算 set-weight: @aws elbv2 modify-rule \ --rule-arn $( LISTENER_RULE_ARN ) \ --actions '[{ "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "$(BLUE_TG_ARN)", "Weight": ' $$ (( 100 - $( GREEN_WEIGHT ))) ' }, { "TargetGroupArn": "$(GREEN_TG_ARN)", "Weight": ' $( GREEN_WEIGHT ) ' } ] } }]' デプロイフロー 実際のデプロイでは、以下のような手順で段階的にトラフィックを移行します： # 1. Green 環境へのデプロイ make app-green.deploy TAG= $( NEW_VERSION ) # 2. トラフィックを段階的に移行 make set-weight GREEN_WEIGHT= 10 # 10% を Green へ make set-weight GREEN_WEIGHT= 50 # 50% を Green へ make set-weight GREEN_WEIGHT= 100 # 100% を Green へ（切り替え完了） # 3. 問題が発生した場合のロールバック make set-weight GREEN_WEIGHT= 0 # すべてのトラフィックを Blue へ戻す この実装により、段階的なリリースと問題発生時の迅速なロールバックが可能になっています。 導入後の効果 Blue/Green デプロイメント導入後、深夜のリリース作業がなくなり、運用チームの負担が大幅に軽減されました。また日中であってもリスクを最小限に抑えたリリースが実現でき、問題が発生した場合にも迅速にロールバックできるようになったため、システムの安定性を犠牲にすることなくリリースを行えるようになりました。 まとめ 今回は、医療システム統合基盤における Blue/Green デプロイメントの導入事例を紹介しました。 医療システムには高い可用性が求められる中、従来のローリングデプロイでは段階的なリリースや迅速なロールバックが困難で、深夜作業が必須となっていました。 Blue/Green デプロイメントの導入により、以下を実現しました： ALB の weighted target groups を活用した段階的トラフィック移行（10%→50%→100%）により品質を確認しながらのリリース進行 Worker サービス用の SQS キューを環境ごとに分離し、データ不整合を防止 深夜作業を廃止し、日中でも安全にリリース作業を実施可能に 今後も医療システムに求められる高可用性を維持しながら、開発効率の向上を目指し、継続的な改善を進めていきます。 We’re hiring 統合基盤チームでは、医療システムの根幹を支える重要な基盤の開発・運用を行っています。 今回紹介したような Blue/Green デプロイメントの実装をはじめ、高可用性が求められるシステムにおいて、技術的な課題に向き合いながら医療現場と患者体験の向上に貢献できる環境があります。 医療の未来をエンジニアリングで支えることに興味がある方のご応募をお待ちしています。 患者統合基盤 Webエンジニア / 株式会社メドレー 株式会社メドレーは患者統合基盤 Webエンジニアを採用しています。 open.talentio.com 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療プラットフォーム本部の日下（ @mkusaka ）です。 私の所属する統合基盤チームでは、医療プラットフォームの複数のシステムを支えるサービス群を運用しています。 これまではユーザーへの影響を最小限に抑えるため、リリース作業を深夜や早朝に限定していましたが、その結果として運用チームへの負担増やリリースタイミングの制約といった課題が生じていました。 こうした課題を解決し、日中でも安全かつ段階的にリリースを行うため、統合基盤に Blue/Green デプロイメントを導入しました。今回はその詳細を紹介します。 統合基盤コンポーネントの紹介 統合基盤チームでは、患者と医療機関の双方に使われる医療システムの根幹を支える重要な基盤の開発・運用を行っています。 管理するコンポーネントは、「医療機関向け」と「患者向け」の 2 つに分類できます。 「医療機関向け」機能は、 Pharms 、 Dentis 、 CLINICS などの各サービス間でコミュニケーションのハブとして機能し、イベントの配信を行います。 一方、「患者向け」機能としては、 総合医療アプリ CLINICS から送られたリクエストを適切なサービスに振り分けるゲートウェイの役割を担っています。 このようなアーキテクチャを採用した背景には、医療プラットフォームが複数のプロダクト（Pharms、Dentis、CLINICS など）を統合的に運用する必要があるという背景があります。 医療機関向けには、いずれか一方のシステムの状態に他方が引きずられない構成とすることで、各医療機関の業務システムの可用性を最大限高めるという狙いがあります。 一方、患者向けには、複数の医療機関向けシステムに対して共通のアプリからアクセスできるようにするため、患者情報の一元管理や統一された認証基盤の整備が不可欠です。これにより、患者にとってシームレスな体験を実現し、より効率的で質の高い医療サービスの提供を目指しています。 つまり、統合基盤が管理するこれらのコンポーネントに障害が発生すると、サービス間にまたがる業務だけでなく、患者向けのサービス提供にも影響が及ぶため、高い可用性が求められています。 Blue/Green デプロイメント導入の目的 統合基盤の各サービスは、AWS ECS（Elastic Container Service）上で運用されています。これまでは、運用のシンプルさからローリングデプロイを採用していました。しかしこの手法では、デプロイが開始されると新バージョンが一斉に展開されてしまうため、問題発生時の影響範囲が広く、迅速なロールバックも難しいという課題がありました。 こうした課題への対策として、Blue/Green デプロイメントを導入することを決定しました。 Blue/Green デプロイメントとは、新旧 2 つの環境（Blue と Green）を用意し、新バージョンを片方に展開した後、徐々にトラフィックを移行していく方法です。これにより、致命的な問題やパフォーマンスの劣化を早期に発見し、迅速なロールバックが可能になります。 Blue/Green デプロイメントの要件と独自実装の選択 システムを Blue/Green デプロイする際に、大きく分けて 2 つの考慮事項がありました。 1 つ目は 2 つの明確な検証フェーズを設けることです。 致命的なエラー検出フェーズ ：新環境に約 10%のトラフィックを流し、システムの安定性を確認。 負荷時のパフォーマンス検証フェーズ ：新環境に約 50%のトラフィックを流し、負荷によるパフォーマンスの劣化を確認。 これら 2 つのフェーズを明確に設け、十分な検証時間を取ることで、より高い自信をもってリリース作業を進めることが可能になると考えました。 2 つ目は非同期処理を担当する Worker サービスを新旧の環境それぞれで用意することです。 Worker サービスでは、ジョブが SQS（Simple Queue Service）キューに投入されてから実際に処理されるまでタイムラグがあります。その間に新しい環境へ切り替えが行われると、旧環境のジョブが新環境の Worker によって処理され、データの不整合が起きる可能性があります。このリスクを防ぐため、Blue と Green の環境それぞれに独立した SQS キューを用意し、それぞれのジョブが確実に自環境の Worker で処理を完了する形式を取ることとしました。 ECS には CodeDeploy を利用した標準的な Blue/Green の段階的デプロイ戦略として、Canary デプロイ（一部のトラフィックで検証後、一気に切り替え）や Linear デプロイ（一定割合ずつ徐々に適用）が提供されています。しかし、私たちが求めるようなトラフィック調整にはこれらの手法が十分に適しておらず、また SQS を分離するための Blue 環境/Green 環境どちらかを判定するような仕組みが整備されていないようだったので、内製化することとしました。 採用した構成 自前の Blue/Green デプロイを実現するため、以下の構成を採用しました。 ALB（Application Load Balancer）の weighted target groups を利用して、トラフィックを柔軟に調整しています。 ECS 環境は Blue/Green のそれぞれが並行稼働し、SQS は各環境ごとに独立したキューを設けます。 新バージョンは Green 環境として起動し、初期状態では Blue 環境（現行バージョン）がすべてのトラフィックを処理します。その後、Green 環境へのトラフィックを 10%、50%と段階的に増やしながら、各段階でメトリクスの監視を行います。 10%の段階で致命的なエラーがないことを確認し、50%の段階で負荷時のパフォーマンスに問題ないと判断されたら、最終的にすべてのトラフィックを Green 環境へ切り替えます（100%）。 また、各種ステップは承認操作やロールバックも含めて CI 上で完結するように整備を行うことで、デプロイの複雑性も抑えています。 実装サンプル Terraform と AWS CLI を組み合わせて実装しています。 ALB の weighted routing 設定（Terraform） resource "aws_lb_listener_rule" "weighted_routing" { listener_arn = aws_lb_listener. https . arn action { type = "forward" forward { target_group { arn = aws_lb_target_group. app_blue . arn weight = 100 # 初期状態では Blue が 100% } target_group { arn = aws_lb_target_group. app_green . arn weight = 0 # Green は 0% } } } # AWS CLI で weight を動的に調整するため、Terraform での変更を無視 lifecycle { ignore_changes = [ action ] } } トラフィック配分の変更（AWS CLI） デプロイ時のトラフィック配分は、AWS CLI を使用して動的に変更します。実際の運用では、Green の weight を指定すると Blue が自動的に 100 - Green になるように調整しています： # Green の weight を指定して Blue/Green の配分を設定 # 例：GREEN_WEIGHT=10 の場合、Blue=90、Green=10 に自動計算 set-weight: @aws elbv2 modify-rule \ --rule-arn $( LISTENER_RULE_ARN ) \ --actions '[{ "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "$(BLUE_TG_ARN)", "Weight": ' $$ (( 100 - $( GREEN_WEIGHT ))) ' }, { "TargetGroupArn": "$(GREEN_TG_ARN)", "Weight": ' $( GREEN_WEIGHT ) ' } ] } }]' デプロイフロー 実際のデプロイでは、以下のような手順で段階的にトラフィックを移行します： # 1. Green 環境へのデプロイ make app-green.deploy TAG= $( NEW_VERSION ) # 2. トラフィックを段階的に移行 make set-weight GREEN_WEIGHT= 10 # 10% を Green へ make set-weight GREEN_WEIGHT= 50 # 50% を Green へ make set-weight GREEN_WEIGHT= 100 # 100% を Green へ（切り替え完了） # 3. 問題が発生した場合のロールバック make set-weight GREEN_WEIGHT= 0 # すべてのトラフィックを Blue へ戻す この実装により、段階的なリリースと問題発生時の迅速なロールバックが可能になっています。 導入後の効果 Blue/Green デプロイメント導入後、深夜のリリース作業がなくなり、運用チームの負担が大幅に軽減されました。また日中であってもリスクを最小限に抑えたリリースが実現でき、問題が発生した場合にも迅速にロールバックできるようになったため、システムの安定性を犠牲にすることなくリリースを行えるようになりました。 まとめ 今回は、医療システム統合基盤における Blue/Green デプロイメントの導入事例を紹介しました。 医療システムには高い可用性が求められる中、従来のローリングデプロイでは段階的なリリースや迅速なロールバックが困難で、深夜作業が必須となっていました。 Blue/Green デプロイメントの導入により、以下を実現しました： ALB の weighted target groups を活用した段階的トラフィック移行（10%→50%→100%）により品質を確認しながらのリリース進行 Worker サービス用の SQS キューを環境ごとに分離し、データ不整合を防止 深夜作業を廃止し、日中でも安全にリリース作業を実施可能に 今後も医療システムに求められる高可用性を維持しながら、開発効率の向上を目指し、継続的な改善を進めていきます。 We’re hiring 統合基盤チームでは、医療システムの根幹を支える重要な基盤の開発・運用を行っています。 今回紹介したような Blue/Green デプロイメントの実装をはじめ、高可用性が求められるシステムにおいて、技術的な課題に向き合いながら医療現場と患者体験の向上に貢献できる環境があります。 医療の未来をエンジニアリングで支えることに興味がある方のご応募をお待ちしています。 患者統合基盤 Webエンジニア / 株式会社メドレー 株式会社メドレーは患者統合基盤 Webエンジニアを採用しています。 open.talentio.com 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは！ 人材プラットフォーム本部プロダクト統括部プロダクト開発部アカデミー開発グループ所属の城間（シロマ）です。 私は 2024 年 4 月に新卒エンジニアとして入社し、現在はオンライン動画研修サービス「 ジョブメドレーアカデミー 」の新規プロダクト開発に携わっています。 先日、5 月 23 日、24 日に東京都千代田区のベルサール神田にて開催された TSKaigi 2025 にメドレーは Silver Sponsor として協賛しました！ TypeScript をテーマにしたこの大規模なカンファレンスには、多様なバックグラウンドを持つ TypeScript エンジニアが全国から集結。 惜しくもブースの抽選には外れてしまいましたが、私も含め弊社からは数名のエンジニアが現地参加し、多くの素晴らしい出会いと学びがありました。 今回は、当日の会場の様子や印象に残ったセッション、そして今、私が感じていることを中心にご紹介します！ 会場の熱気と「型にとらわれない」エンジニアたちの交流 今年の TSKaigi 2025 は 2 日間とも天候に恵まれ、 61 もの企業スポンサーと「TypeScript を扱う型にとらわれないエンジニア」が集結し、会場は終日、熱気と活気に満ち溢れていました。 場内の様子 スポンサーボード 2 日間に渡り、合計 3 会場でセッションや LT が盛んに行われ、時には立ち見の人が出るほどに盛況していました。 参加者同士でテーマに対してトークする OST（Open Space Technology） や、夜の豪華な懇親会では、セッションでは聞けないような深掘りした技術の話や、各社の開発文化に関する交流が盛んに行われ、当日はおよそ 50 名以上のエンジニアの方々と色々なお話をさせていただきました。 OST のテーマ 懇親会の様子 TypeScript ケーキ また、今回参加者に配布された公式グッズは、TSKaigi のオリジナル T シャツやトートバッグに加え、各企業が工夫を凝らした遊び心あふれるグッズで盛りだくさんでした。 特に、今回ブース出展のあった 19 社全てを周るスタンプラリー では、全てのスタンプを集めることで豪華景品が当たる抽選に参加でき、会場の賑わいに一役買っていました。 公式ノベルティ（一部） スタンプラリー 印象に残ったセッション：AI エージェント全盛の時代と TypeScript の可能性 どのセッションも非常に興味深く、時には理解が追いつかないほど最先端の内容でしたが、特に今の私が行う開発と照らし合わせて印象に残ったセッションをいくつかご紹介します。 Day1: AI Coding Agent Enablement in TypeScript 引用元: AI Coding Agents Enablement in TypeScript - Speaker Deck 概要 このセッションでは、人間による介入を最小限に抑え、AI エージェントが大規模な作業をどのように「自走」して実行させるかについて深く掘り下げられました。 なぜ自走が難しいのか？その主な要因は AI エージェントが「任意の TypeScript」のようなあまりにも広い「解空間」で動くため、精度が低くなってしまうためです。 すなわち AI エージェントの精度を高めるためには 「可能な限り解空間を絞る」 ことが基本方針であり、会社やプロジェクト固有の規約、ドメイン知識、デザインなどに基づいて適切に制約を与える重要性が何度も強調されていました。 その解空間を絞る具体的なアプローチとして 「コンテキスト注入」 と 「機械的検査とフィードバック」 の 2 つが挙げられました。 コンテキスト注入 : ドキュメント、規約、ドメイン知識などを LLM にインプットし、「解空間の定義」を与えること。特に TypeScript コード自体をドキュメントとして育てることが、コンテキスト注入に役立つ。 機械的検査とフィードバック : LLM が生成したコードが定義された解空間から外れていないか、型チェック、Linter、自動テストといった古典的な手法で検査し、NG の場合はエージェントにフィードバックして解空間へと押し戻すように促す。Linter は次にやるべきアクションを提示しやすく、決定的である点が非常に有効である。 また、TypeScript 開発における型の役割についても興味深い見解がありました。現状、型によってコード生成の精度が上がるという定量的な根拠はまだないものの、「解空間に押し戻す」ためのエージェントへの入力（フィードバック）としては役立つ可能性は大いにあるとのこと。AI はまだ高度な型解決が苦手なので、人間がドメインモデルや関数のシグネチャ（型定義）をしっかり書き、その後の実装をエージェントに任せるアプローチが有効であるという話は、非常に現実的で納得感がありました。 最後に、 「エコシステムの未来 - Speed is King」 という言葉が印象的でした。これは、AI エージェントのコード生成が加速すると、開発プロセス全体の速度がボトルネックとなることを示唆しています。具体的には、人間がコードを 30 分かけて書く時代には 1 分程度の静的解析は許容範囲でしたが、AI が同じコードをわずか 30 秒で書くようになると同じ 1 分間の静的解析は AI の作業時間に対して相対的に非常に長く、無視できないボトルネックになるということです。さらにクラウド型エージェントではチャットごとにコンテナが作成される仕組みが主流であり、その際にパッケージマネージャの速度がボトルネックになります。また、AI エージェントによるコード生産量が爆発的に増加すれば、デプロイの機会も増えるためビルド（バンドラー）の速度もボトルネックとして顕在化し、加えて将来的に LLM がコードを生成するタイミング（デコーディング時）ごとに型制約を守ろうとする「制約付きデコーディング」のようなアプローチが進めば、型チェッカーがボトルネックになる可能性も指摘されていました。故に、ツールチェイン全体の高速化が今後より重要になるという示唆は、将来的な開発環境を考える上で非常に重要な視点だと感じました。 Day2: TS 特化 Cline プログラミング 引用元: tskaigi.mizchi.workers.dev 概要 このセッションでは、LLM を活用した「Cline Agentic Coding」の全般について、特に TypeScript に特化した実践的なプロンプトのコツが紹介されました。 まず冒頭に うまくいくうまくいくプロンプトのコツ として、以下が挙げられていました。 書きすぎない（再現性ある範囲で詠唱破棄） 執拗に出力例を例示する 両立条件の矛盾を避ける 規模感に合わせて厳しくする また特に強調されていたのは、 テスト駆動開発（Test Driven Development） の重要性です。コード生成時に対応するユニットテストを常に生成し、コード修正時にはテストがパスすることを確認することで、AI エージェントの自己修復能力を高め、放置しても完成する高品質なコードに繋がるとのことでした。 その他にも、次のような実践的なプロンプトの一例が紹介されていました。 コメントによる自己記述 : 各ファイルの冒頭にコメントで仕様を記述することで、再修正時のコード解釈の一貫性を保つ In Source Testing : 実装と同じファイルにユニットテストを書くことで、コメント・実装・テストを三位一体で管理する types.ts にドメイン型を集約 : 中規模以上のプロジェクトでは src/types.ts にドメインモデルを集約し、SSoT（Single Source of Truth）とすることで、ファイル間の整合性を保ち read_file の頻度を減らす TS + 関数型ドメインモデリング : 状態の発散を抑えるために class を使わず関数による実装を優先し、代数的データ型でドメインをモデリングする ファイル配置規則の明記 : モノレポなどのファイル配置規則を明記することで、タスクごとのエージェントの推測コストを減らす 詳細指示を docs/*.md に分割 : 大規模プロジェクトでは無関係な指示によるノイズを減らすために、詳細な指示をドキュメントファイルに分割し、必要に応じて参照させる カバレッジに基づくテストの自動生成 : vitest でカバレッジを計測し、最もカバレッジが上がるテストコードを AI に考察・追加させる 機械的なマイグレーション : lodash の削除や類似 API を持つライブラリへの置き換えなど、面倒なマイグレーション作業を AI に自動化させる URL を読む能力 : URL の内容を読み込ませ、要約・保存させることで、Deep Research 的な挙動を可能にする 一方で、 うまくいかないプロンプト のパターンもいくつか示唆されました。 型だけで設計しようとする : ほぼ確実に無視され、抽象的な設計能力は期待できない 非同期例外処理が下手 : 思考停止気味に try-catch で握り潰しがちで、大規模開発で破綻の原因となる 環境構築が下手 : ゼロショットでの環境構築は発散しやすく、手数が仇となり環境を破壊する可能性がある モジュールインターフェースが発散 : 実装次第で全て export してしまい、モジュール間の契約が肥大化・破綻する 「ある」のがよくない（チェーホフの銃の法則） : 無関係なリソースを読み込ませると、それを使うことに固執し、大規模コードではノイズになる デバッグログを食いすぎる : 自身が生成したプリントデバッグでコンテキストウィンドウを消費し、デバッグコードを放置しがちである 結論として、現状の LLM はコーディングが下手であり、低品質なコードで設計が破綻し自滅する傾向があるとの見解でした。特に、リファクタリングの指針がなく、不要コードの判定やモジュール視点での API 設計が苦手で、ユーザー側でリファクタリングしても元の低品質なコードに書き戻すこともあるという少し厳しい評価が下されていました。 しかし TypeScript と LLM の組み合わせには良い点も多く、GitHub の公開コードが豊富で学習量が多いこと、安全性よりも表現力を選んだピーキーな型システムが自然言語と対応した型のモデリングをしやすいこと、豊富な静的解析手段とユーザー層の厚さがあることなどが挙げられていました。 現時点でのベストプラクティスとしては、PoC/プロトタイプのコード生成（1 ファイル完結 800 行以内が目安）に活用し、人間によるインターフェース設計、失敗パターンのプロンプトへの反映、成功するパターンのドキュメント化、そしてこちらでも Lint ルールの整備についての言及がありました。 そして最後にテスト駆動開発や LLM の得意領域・発達段階を予測する技術、プロンプトエンジニアリングの重要性の増加など Agentic Coding によるプログラミング自体の変質と不変である点について説明され締めくくられました。 感想 これらのセッションを通して、私が携わる新規プロダクト開発において、 実践できている部分 と 改善の余地がある部分 が明確になりました。 実践できている点として、全社的に積極的に利用している AI エディタ「Cursor」のプロジェクトルールや自立型 AI エージェント「Devin」の knowledge には、プロジェクトごとに解空間を明確にするコンテキストを与えています。これは、「AI Coding Agent Enablement in TypeScript」で述べられていた「コンテキスト注入」と「解空間を絞る」という考え方に合致していると感じました。また、コードと仕様を記述したドキュメントを同じリポジトリ内で管理し、開発を進めている点も、AI へのコンテキスト注入に貢献していると言えるでしょう。 開発フローにおいても、AI の特性を踏まえた工夫を凝らしています。「AI Coding Agent Enablement in TypeScript」で言及があった「3 回くらいループした末に any とかキャストで誤魔化しがち」という点に対し、例えば API 開発では、まず仕様やテストケースのドキュメントをコードベースと同じファイル内に記述し、次に Request や Response Body を zod を用いて厳密に型を記述します。これらをエンジニアがレビューした後、テストデータのセットアップや記法などをエンジニアが整え、残りを AI で実装を進めます。さらにアプリケーションコードの実装においても、用意したユニットテストが通過するという制約の元 AI に実装させることにより、型解決などに AI エージェントが費やす時間が最小化され、 実装フェーズの開発工数を大幅に短縮することに成功 しています。 mizchi さんのセッションで言及のあったテスト駆動開発（Test Driven Development）のスキルは今後もより重要になっていくでしょう。しかし、もう少し先の未来では、弊社メドレーが大切にしている価値観（Our Essential）の一つである「 ドキュメントドリブン 」に倣い、 ドキュメントドリブン開発（Document Driven Development） のスキルがより重要になっていくのではないか、と私は考えています。 具体的なイメージ さらに「Speed is King」の思想を体現するために、Linter と Formatter には Biome、パッケージマネージャーには Bun を採用するなどツールチェインの速度にはかなりシビアな意思決定をしており、より AI エージェントが生産的に活動できるような体制を整えています。 一方で、 改善の余地がある点 も明確になりました。特に双方のセッションで強調されていた「機械的検査とフィードバック」の継続的な改善、すなわち Linter については開発初期から現在に至るまであまり積極的に更新できていないと痛感しています。AI に与えるフィードバックをその場での単発のもので終わらせるのではなく、（人間と同じように）再発防止策を考えさせるように Linter を定期的にアップデートし、より決定的で高速に AI エージェントが機能するような環境をより一層整備していきます。 さいごに TypeScript の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 メドレーは今後も TSKaigi だけでなく、他の技術イベントやコミュニティの発展を積極的に支援し、参加、貢献していきます。 過去にスポンサーとして協賛した技術カンファレンスの参加レポート記事はこちら！ RubyKaigi 2025 参加レポート - Platinum Sponsor として協賛しました！ | MEDLEY Developer Portal はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 1... developer.medley.jp pmconf 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。医療プラットフォーム本部で Product Manager をしている佐藤です。2024 年 5 月にメドレーにジョインし、医療機関向けプロダクト開発に奔走しています。社内では ”papa”、家では”おじさん”と呼ばれ可愛がら... developer.medley.jp JSConf JP 2024に プレミアムスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田(@Shige0096)です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上... developer.medley.jp DroidKaigi 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催され... developer.medley.jp TSKaigi 2025 の運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございました！ メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 TypeScript を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp ※カジュアル面談ご希望の際は、<その他> にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト統括部プロダクト開発部アカデミー開発グループ所属の城間（シロマ）です。 私は 2024 年 4 月に新卒エンジニアとして入社し、現在はオンライン動画研修サービス「 ジョブメドレーアカデミー 」の新規プロダクト開発に携わっています。 先日、5 月 23 日、24 日に東京都千代田区のベルサール神田にて開催された TSKaigi 2025 にメドレーは Silver Sponsor として協賛しました！ TypeScript をテーマにしたこの大規模なカンファレンスには、多様なバックグラウンドを持つ TypeScript エンジニアが全国から集結。 惜しくもブースの抽選には外れてしまいましたが、私も含め弊社からは数名のエンジニアが現地参加し、多くの素晴らしい出会いと学びがありました。 今回は、当日の会場の様子や印象に残ったセッション、そして今、私が感じていることを中心にご紹介します！ 会場の熱気と「型にとらわれない」エンジニアたちの交流 今年の TSKaigi 2025 は 2 日間とも天候に恵まれ、 61 もの企業スポンサーと「TypeScript を扱う型にとらわれないエンジニア」が集結し、会場は終日、熱気と活気に満ち溢れていました。 場内の様子 スポンサーボード 2 日間に渡り、合計 3 会場でセッションや LT が盛んに行われ、時には立ち見の人が出るほどに盛況していました。 参加者同士でテーマに対してトークする OST（Open Space Technology） や、夜の豪華な懇親会では、セッションでは聞けないような深掘りした技術の話や、各社の開発文化に関する交流が盛んに行われ、当日はおよそ 50 名以上のエンジニアの方々と色々なお話をさせていただきました。 OST のテーマ 懇親会の様子 TypeScript ケーキ また、今回参加者に配布された公式グッズは、TSKaigi のオリジナル T シャツやトートバッグに加え、各企業が工夫を凝らした遊び心あふれるグッズで盛りだくさんでした。 特に、今回ブース出展のあった 19 社全てを周るスタンプラリー では、全てのスタンプを集めることで豪華景品が当たる抽選に参加でき、会場の賑わいに一役買っていました。 公式ノベルティ（一部） スタンプラリー 印象に残ったセッション：AI エージェント全盛の時代と TypeScript の可能性 どのセッションも非常に興味深く、時には理解が追いつかないほど最先端の内容でしたが、特に今の私が行う開発と照らし合わせて印象に残ったセッションをいくつかご紹介します。 Day1: AI Coding Agent Enablement in TypeScript 引用元: AI Coding Agents Enablement in TypeScript - Speaker Deck 概要 このセッションでは、人間による介入を最小限に抑え、AI エージェントが大規模な作業をどのように「自走」して実行させるかについて深く掘り下げられました。 なぜ自走が難しいのか？その主な要因は AI エージェントが「任意の TypeScript」のようなあまりにも広い「解空間」で動くため、精度が低くなってしまうためです。 すなわち AI エージェントの精度を高めるためには 「可能な限り解空間を絞る」 ことが基本方針であり、会社やプロジェクト固有の規約、ドメイン知識、デザインなどに基づいて適切に制約を与える重要性が何度も強調されていました。 その解空間を絞る具体的なアプローチとして 「コンテキスト注入」 と 「機械的検査とフィードバック」 の 2 つが挙げられました。 コンテキスト注入 : ドキュメント、規約、ドメイン知識などを LLM にインプットし、「解空間の定義」を与えること。特に TypeScript コード自体をドキュメントとして育てることが、コンテキスト注入に役立つ。 機械的検査とフィードバック : LLM が生成したコードが定義された解空間から外れていないか、型チェック、Linter、自動テストといった古典的な手法で検査し、NG の場合はエージェントにフィードバックして解空間へと押し戻すように促す。Linter は次にやるべきアクションを提示しやすく、決定的である点が非常に有効である。 また、TypeScript 開発における型の役割についても興味深い見解がありました。現状、型によってコード生成の精度が上がるという定量的な根拠はまだないものの、「解空間に押し戻す」ためのエージェントへの入力（フィードバック）としては役立つ可能性は大いにあるとのこと。AI はまだ高度な型解決が苦手なので、人間がドメインモデルや関数のシグネチャ（型定義）をしっかり書き、その後の実装をエージェントに任せるアプローチが有効であるという話は、非常に現実的で納得感がありました。 最後に、 「エコシステムの未来 - Speed is King」 という言葉が印象的でした。これは、AI エージェントのコード生成が加速すると、開発プロセス全体の速度がボトルネックとなることを示唆しています。具体的には、人間がコードを 30 分かけて書く時代には 1 分程度の静的解析は許容範囲でしたが、AI が同じコードをわずか 30 秒で書くようになると同じ 1 分間の静的解析は AI の作業時間に対して相対的に非常に長く、無視できないボトルネックになるということです。さらにクラウド型エージェントではチャットごとにコンテナが作成される仕組みが主流であり、その際にパッケージマネージャの速度がボトルネックになります。また、AI エージェントによるコード生産量が爆発的に増加すれば、デプロイの機会も増えるためビルド（バンドラー）の速度もボトルネックとして顕在化し、加えて将来的に LLM がコードを生成するタイミング（デコーディング時）ごとに型制約を守ろうとする「制約付きデコーディング」のようなアプローチが進めば、型チェッカーがボトルネックになる可能性も指摘されていました。故に、ツールチェイン全体の高速化が今後より重要になるという示唆は、将来的な開発環境を考える上で非常に重要な視点だと感じました。 Day2: TS 特化 Cline プログラミング 引用元: tskaigi.mizchi.workers.dev 概要 このセッションでは、LLM を活用した「Cline Agentic Coding」の全般について、特に TypeScript に特化した実践的なプロンプトのコツが紹介されました。 まず冒頭に うまくいくうまくいくプロンプトのコツ として、以下が挙げられていました。 書きすぎない（再現性ある範囲で詠唱破棄） 執拗に出力例を例示する 両立条件の矛盾を避ける 規模感に合わせて厳しくする また特に強調されていたのは、 テスト駆動開発（Test Driven Development） の重要性です。コード生成時に対応するユニットテストを常に生成し、コード修正時にはテストがパスすることを確認することで、AI エージェントの自己修復能力を高め、放置しても完成する高品質なコードに繋がるとのことでした。 その他にも、次のような実践的なプロンプトの一例が紹介されていました。 コメントによる自己記述 : 各ファイルの冒頭にコメントで仕様を記述することで、再修正時のコード解釈の一貫性を保つ In Source Testing : 実装と同じファイルにユニットテストを書くことで、コメント・実装・テストを三位一体で管理する types.ts にドメイン型を集約 : 中規模以上のプロジェクトでは src/types.ts にドメインモデルを集約し、SSoT（Single Source of Truth）とすることで、ファイル間の整合性を保ち read_file の頻度を減らす TS + 関数型ドメインモデリング : 状態の発散を抑えるために class を使わず関数による実装を優先し、代数的データ型でドメインをモデリングする ファイル配置規則の明記 : モノレポなどのファイル配置規則を明記することで、タスクごとのエージェントの推測コストを減らす 詳細指示を docs/*.md に分割 : 大規模プロジェクトでは無関係な指示によるノイズを減らすために、詳細な指示をドキュメントファイルに分割し、必要に応じて参照させる カバレッジに基づくテストの自動生成 : vitest でカバレッジを計測し、最もカバレッジが上がるテストコードを AI に考察・追加させる 機械的なマイグレーション : lodash の削除や類似 API を持つライブラリへの置き換えなど、面倒なマイグレーション作業を AI に自動化させる URL を読む能力 : URL の内容を読み込ませ、要約・保存させることで、Deep Research 的な挙動を可能にする 一方で、 うまくいかないプロンプト のパターンもいくつか示唆されました。 型だけで設計しようとする : ほぼ確実に無視され、抽象的な設計能力は期待できない 非同期例外処理が下手 : 思考停止気味に try-catch で握り潰しがちで、大規模開発で破綻の原因となる 環境構築が下手 : ゼロショットでの環境構築は発散しやすく、手数が仇となり環境を破壊する可能性がある モジュールインターフェースが発散 : 実装次第で全て export してしまい、モジュール間の契約が肥大化・破綻する 「ある」のがよくない（チェーホフの銃の法則） : 無関係なリソースを読み込ませると、それを使うことに固執し、大規模コードではノイズになる デバッグログを食いすぎる : 自身が生成したプリントデバッグでコンテキストウィンドウを消費し、デバッグコードを放置しがちである 結論として、現状の LLM はコーディングが下手であり、低品質なコードで設計が破綻し自滅する傾向があるとの見解でした。特に、リファクタリングの指針がなく、不要コードの判定やモジュール視点での API 設計が苦手で、ユーザー側でリファクタリングしても元の低品質なコードに書き戻すこともあるという少し厳しい評価が下されていました。 しかし TypeScript と LLM の組み合わせには良い点も多く、GitHub の公開コードが豊富で学習量が多いこと、安全性よりも表現力を選んだピーキーな型システムが自然言語と対応した型のモデリングをしやすいこと、豊富な静的解析手段とユーザー層の厚さがあることなどが挙げられていました。 現時点でのベストプラクティスとしては、PoC/プロトタイプのコード生成（1 ファイル完結 800 行以内が目安）に活用し、人間によるインターフェース設計、失敗パターンのプロンプトへの反映、成功するパターンのドキュメント化、そしてこちらでも Lint ルールの整備についての言及がありました。 そして最後にテスト駆動開発や LLM の得意領域・発達段階を予測する技術、プロンプトエンジニアリングの重要性の増加など Agentic Coding によるプログラミング自体の変質と不変である点について説明され締めくくられました。 感想 これらのセッションを通して、私が携わる新規プロダクト開発において、 実践できている部分 と 改善の余地がある部分 が明確になりました。 実践できている点として、全社的に積極的に利用している AI エディタ「Cursor」のプロジェクトルールや自立型 AI エージェント「Devin」の knowledge には、プロジェクトごとに解空間を明確にするコンテキストを与えています。これは、「AI Coding Agent Enablement in TypeScript」で述べられていた「コンテキスト注入」と「解空間を絞る」という考え方に合致していると感じました。また、コードと仕様を記述したドキュメントを同じリポジトリ内で管理し、開発を進めている点も、AI へのコンテキスト注入に貢献していると言えるでしょう。 開発フローにおいても、AI の特性を踏まえた工夫を凝らしています。「AI Coding Agent Enablement in TypeScript」で言及があった「3 回くらいループした末に any とかキャストで誤魔化しがち」という点に対し、例えば API 開発では、まず仕様やテストケースのドキュメントをコードベースと同じファイル内に記述し、次に Request や Response Body を zod を用いて厳密に型を記述します。これらをエンジニアがレビューした後、テストデータのセットアップや記法などをエンジニアが整え、残りを AI で実装を進めます。さらにアプリケーションコードの実装においても、用意したユニットテストが通過するという制約の元 AI に実装させることにより、型解決などに AI エージェントが費やす時間が最小化され、 実装フェーズの開発工数を大幅に短縮することに成功 しています。 mizchi さんのセッションで言及のあったテスト駆動開発（Test Driven Development）のスキルは今後もより重要になっていくでしょう。しかし、もう少し先の未来では、弊社メドレーが大切にしている価値観（Our Essential）の一つである「 ドキュメントドリブン 」に倣い、 ドキュメントドリブン開発（Document Driven Development） のスキルがより重要になっていくのではないか、と私は考えています。 具体的なイメージ さらに「Speed is King」の思想を体現するために、Linter と Formatter には Biome、パッケージマネージャーには Bun を採用するなどツールチェインの速度にはかなりシビアな意思決定をしており、より AI エージェントが生産的に活動できるような体制を整えています。 一方で、 改善の余地がある点 も明確になりました。特に双方のセッションで強調されていた「機械的検査とフィードバック」の継続的な改善、すなわち Linter については開発初期から現在に至るまであまり積極的に更新できていないと痛感しています。AI に与えるフィードバックをその場での単発のもので終わらせるのではなく、（人間と同じように）再発防止策を考えさせるように Linter を定期的にアップデートし、より決定的で高速に AI エージェントが機能するような環境をより一層整備していきます。 さいごに TypeScript の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 メドレーは今後も TSKaigi だけでなく、他の技術イベントやコミュニティの発展を積極的に支援し、参加、貢献していきます。 過去にスポンサーとして協賛した技術カンファレンスの参加レポート記事はこちら！ RubyKaigi 2025 参加レポート - Platinum Sponsor として協賛しました！ | MEDLEY Developer Portal はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 1... developer.medley.jp pmconf 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。医療プラットフォーム本部で Product Manager をしている佐藤です。2024 年 5 月にメドレーにジョインし、医療機関向けプロダクト開発に奔走しています。社内では ”papa”、家では”おじさん”と呼ばれ可愛がら... developer.medley.jp JSConf JP 2024に プレミアムスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田(@Shige0096)です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上... developer.medley.jp DroidKaigi 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催され... developer.medley.jp TSKaigi 2025 の運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございました！ メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 TypeScript を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp ※カジュアル面談ご希望の際は、<その他> にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト統括部プロダクト開発部アカデミー開発グループ所属の城間（シロマ）です。 私は 2024 年 4 月に新卒エンジニアとして入社し、現在はオンライン動画研修サービス「 ジョブメドレーアカデミー 」の新規プロダクト開発に携わっています。 先日、5 月 23 日、24 日に東京都千代田区のベルサール神田にて開催された TSKaigi 2025 にメドレーは Silver Sponsor として協賛しました！ TypeScript をテーマにしたこの大規模なカンファレンスには、多様なバックグラウンドを持つ TypeScript エンジニアが全国から集結。 惜しくもブースの抽選には外れてしまいましたが、私も含め弊社からは数名のエンジニアが現地参加し、多くの素晴らしい出会いと学びがありました。 今回は、当日の会場の様子や印象に残ったセッション、そして今、私が感じていることを中心にご紹介します！ 会場の熱気と「型にとらわれない」エンジニアたちの交流 今年の TSKaigi 2025 は 2 日間とも天候に恵まれ、 61 もの企業スポンサーと「TypeScript を扱う型にとらわれないエンジニア」が集結し、会場は終日、熱気と活気に満ち溢れていました。 場内の様子 スポンサーボード 2 日間に渡り、合計 3 会場でセッションや LT が盛んに行われ、時には立ち見の人が出るほどに盛況していました。 参加者同士でテーマに対してトークする OST（Open Space Technology） や、夜の豪華な懇親会では、セッションでは聞けないような深掘りした技術の話や、各社の開発文化に関する交流が盛んに行われ、当日はおよそ 50 名以上のエンジニアの方々と色々なお話をさせていただきました。 OST のテーマ 懇親会の様子 TypeScript ケーキ また、今回参加者に配布された公式グッズは、TSKaigi のオリジナル T シャツやトートバッグに加え、各企業が工夫を凝らした遊び心あふれるグッズで盛りだくさんでした。 特に、今回ブース出展のあった 19 社全てを周るスタンプラリー では、全てのスタンプを集めることで豪華景品が当たる抽選に参加でき、会場の賑わいに一役買っていました。 公式ノベルティ（一部） スタンプラリー 印象に残ったセッション：AI エージェント全盛の時代と TypeScript の可能性 どのセッションも非常に興味深く、時には理解が追いつかないほど最先端の内容でしたが、特に今の私が行う開発と照らし合わせて印象に残ったセッションをいくつかご紹介します。 Day1: AI Coding Agent Enablement in TypeScript 引用元: AI Coding Agents Enablement in TypeScript - Speaker Deck 概要 このセッションでは、人間による介入を最小限に抑え、AI エージェントが大規模な作業をどのように「自走」して実行させるかについて深く掘り下げられました。 なぜ自走が難しいのか？その主な要因は AI エージェントが「任意の TypeScript」のようなあまりにも広い「解空間」で動くため、精度が低くなってしまうためです。 すなわち AI エージェントの精度を高めるためには 「可能な限り解空間を絞る」 ことが基本方針であり、会社やプロジェクト固有の規約、ドメイン知識、デザインなどに基づいて適切に制約を与える重要性が何度も強調されていました。 その解空間を絞る具体的なアプローチとして 「コンテキスト注入」 と 「機械的検査とフィードバック」 の 2 つが挙げられました。 コンテキスト注入 : ドキュメント、規約、ドメイン知識などを LLM にインプットし、「解空間の定義」を与えること。特に TypeScript コード自体をドキュメントとして育てることが、コンテキスト注入に役立つ。 機械的検査とフィードバック : LLM が生成したコードが定義された解空間から外れていないか、型チェック、Linter、自動テストといった古典的な手法で検査し、NG の場合はエージェントにフィードバックして解空間へと押し戻すように促す。Linter は次にやるべきアクションを提示しやすく、決定的である点が非常に有効である。 また、TypeScript 開発における型の役割についても興味深い見解がありました。現状、型によってコード生成の精度が上がるという定量的な根拠はまだないものの、「解空間に押し戻す」ためのエージェントへの入力（フィードバック）としては役立つ可能性は大いにあるとのこと。AI はまだ高度な型解決が苦手なので、人間がドメインモデルや関数のシグネチャ（型定義）をしっかり書き、その後の実装をエージェントに任せるアプローチが有効であるという話は、非常に現実的で納得感がありました。 最後に、 「エコシステムの未来 - Speed is King」 という言葉が印象的でした。これは、AI エージェントのコード生成が加速すると、開発プロセス全体の速度がボトルネックとなることを示唆しています。具体的には、人間がコードを 30 分かけて書く時代には 1 分程度の静的解析は許容範囲でしたが、AI が同じコードをわずか 30 秒で書くようになると同じ 1 分間の静的解析は AI の作業時間に対して相対的に非常に長く、無視できないボトルネックになるということです。さらにクラウド型エージェントではチャットごとにコンテナが作成される仕組みが主流であり、その際にパッケージマネージャの速度がボトルネックになります。また、AI エージェントによるコード生産量が爆発的に増加すれば、デプロイの機会も増えるためビルド（バンドラー）の速度もボトルネックとして顕在化し、加えて将来的に LLM がコードを生成するタイミング（デコーディング時）ごとに型制約を守ろうとする「制約付きデコーディング」のようなアプローチが進めば、型チェッカーがボトルネックになる可能性も指摘されていました。故に、ツールチェイン全体の高速化が今後より重要になるという示唆は、将来的な開発環境を考える上で非常に重要な視点だと感じました。 Day2: TS 特化 Cline プログラミング 引用元: tskaigi.mizchi.workers.dev 概要 このセッションでは、LLM を活用した「Cline Agentic Coding」の全般について、特に TypeScript に特化した実践的なプロンプトのコツが紹介されました。 まず冒頭に うまくいくうまくいくプロンプトのコツ として、以下が挙げられていました。 書きすぎない（再現性ある範囲で詠唱破棄） 執拗に出力例を例示する 両立条件の矛盾を避ける 規模感に合わせて厳しくする また特に強調されていたのは、 テスト駆動開発（Test Driven Development） の重要性です。コード生成時に対応するユニットテストを常に生成し、コード修正時にはテストがパスすることを確認することで、AI エージェントの自己修復能力を高め、放置しても完成する高品質なコードに繋がるとのことでした。 その他にも、次のような実践的なプロンプトの一例が紹介されていました。 コメントによる自己記述 : 各ファイルの冒頭にコメントで仕様を記述することで、再修正時のコード解釈の一貫性を保つ In Source Testing : 実装と同じファイルにユニットテストを書くことで、コメント・実装・テストを三位一体で管理する types.ts にドメイン型を集約 : 中規模以上のプロジェクトでは src/types.ts にドメインモデルを集約し、SSoT（Single Source of Truth）とすることで、ファイル間の整合性を保ち read_file の頻度を減らす TS + 関数型ドメインモデリング : 状態の発散を抑えるために class を使わず関数による実装を優先し、代数的データ型でドメインをモデリングする ファイル配置規則の明記 : モノレポなどのファイル配置規則を明記することで、タスクごとのエージェントの推測コストを減らす 詳細指示を docs/*.md に分割 : 大規模プロジェクトでは無関係な指示によるノイズを減らすために、詳細な指示をドキュメントファイルに分割し、必要に応じて参照させる カバレッジに基づくテストの自動生成 : vitest でカバレッジを計測し、最もカバレッジが上がるテストコードを AI に考察・追加させる 機械的なマイグレーション : lodash の削除や類似 API を持つライブラリへの置き換えなど、面倒なマイグレーション作業を AI に自動化させる URL を読む能力 : URL の内容を読み込ませ、要約・保存させることで、Deep Research 的な挙動を可能にする 一方で、 うまくいかないプロンプト のパターンもいくつか示唆されました。 型だけで設計しようとする : ほぼ確実に無視され、抽象的な設計能力は期待できない 非同期例外処理が下手 : 思考停止気味に try-catch で握り潰しがちで、大規模開発で破綻の原因となる 環境構築が下手 : ゼロショットでの環境構築は発散しやすく、手数が仇となり環境を破壊する可能性がある モジュールインターフェースが発散 : 実装次第で全て export してしまい、モジュール間の契約が肥大化・破綻する 「ある」のがよくない（チェーホフの銃の法則） : 無関係なリソースを読み込ませると、それを使うことに固執し、大規模コードではノイズになる デバッグログを食いすぎる : 自身が生成したプリントデバッグでコンテキストウィンドウを消費し、デバッグコードを放置しがちである 結論として、現状の LLM はコーディングが下手であり、低品質なコードで設計が破綻し自滅する傾向があるとの見解でした。特に、リファクタリングの指針がなく、不要コードの判定やモジュール視点での API 設計が苦手で、ユーザー側でリファクタリングしても元の低品質なコードに書き戻すこともあるという少し厳しい評価が下されていました。 しかし TypeScript と LLM の組み合わせには良い点も多く、GitHub の公開コードが豊富で学習量が多いこと、安全性よりも表現力を選んだピーキーな型システムが自然言語と対応した型のモデリングをしやすいこと、豊富な静的解析手段とユーザー層の厚さがあることなどが挙げられていました。 現時点でのベストプラクティスとしては、PoC/プロトタイプのコード生成（1 ファイル完結 800 行以内が目安）に活用し、人間によるインターフェース設計、失敗パターンのプロンプトへの反映、成功するパターンのドキュメント化、そしてこちらでも Lint ルールの整備についての言及がありました。 そして最後にテスト駆動開発や LLM の得意領域・発達段階を予測する技術、プロンプトエンジニアリングの重要性の増加など Agentic Coding によるプログラミング自体の変質と不変である点について説明され締めくくられました。 感想 これらのセッションを通して、私が携わる新規プロダクト開発において、 実践できている部分 と 改善の余地がある部分 が明確になりました。 実践できている点として、全社的に積極的に利用している AI エディタ「Cursor」のプロジェクトルールや自立型 AI エージェント「Devin」の knowledge には、プロジェクトごとに解空間を明確にするコンテキストを与えています。これは、「AI Coding Agent Enablement in TypeScript」で述べられていた「コンテキスト注入」と「解空間を絞る」という考え方に合致していると感じました。また、コードと仕様を記述したドキュメントを同じリポジトリ内で管理し、開発を進めている点も、AI へのコンテキスト注入に貢献していると言えるでしょう。 開発フローにおいても、AI の特性を踏まえた工夫を凝らしています。「AI Coding Agent Enablement in TypeScript」で言及があった「3 回くらいループした末に any とかキャストで誤魔化しがち」という点に対し、例えば API 開発では、まず仕様やテストケースのドキュメントをコードベースと同じファイル内に記述し、次に Request や Response Body を zod を用いて厳密に型を記述します。これらをエンジニアがレビューした後、テストデータのセットアップや記法などをエンジニアが整え、残りを AI で実装を進めます。さらにアプリケーションコードの実装においても、用意したユニットテストが通過するという制約の元 AI に実装させることにより、型解決などに AI エージェントが費やす時間が最小化され、 実装フェーズの開発工数を大幅に短縮することに成功 しています。 mizchi さんのセッションで言及のあったテスト駆動開発（Test Driven Development）のスキルは今後もより重要になっていくでしょう。しかし、もう少し先の未来では、弊社メドレーが大切にしている価値観（Our Essential）の一つである「 ドキュメントドリブン 」に倣い、 ドキュメントドリブン開発（Document Driven Development） のスキルがより重要になっていくのではないか、と私は考えています。 具体的なイメージ さらに「Speed is King」の思想を体現するために、Linter と Formatter には Biome、パッケージマネージャーには Bun を採用するなどツールチェインの速度にはかなりシビアな意思決定をしており、より AI エージェントが生産的に活動できるような体制を整えています。 一方で、 改善の余地がある点 も明確になりました。特に双方のセッションで強調されていた「機械的検査とフィードバック」の継続的な改善、すなわち Linter については開発初期から現在に至るまであまり積極的に更新できていないと痛感しています。AI に与えるフィードバックをその場での単発のもので終わらせるのではなく、（人間と同じように）再発防止策を考えさせるように Linter を定期的にアップデートし、より決定的で高速に AI エージェントが機能するような環境をより一層整備していきます。 さいごに TypeScript の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 メドレーは今後も TSKaigi だけでなく、他の技術イベントやコミュニティの発展を積極的に支援し、参加、貢献していきます。 過去にスポンサーとして協賛した技術カンファレンスの参加レポート記事はこちら！ RubyKaigi 2025 参加レポート - Platinum Sponsor として協賛しました！ | MEDLEY Developer Portal はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 1... developer.medley.jp pmconf 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。医療プラットフォーム本部で Product Manager をしている佐藤です。2024 年 5 月にメドレーにジョインし、医療機関向けプロダクト開発に奔走しています。社内では ”papa”、家では”おじさん”と呼ばれ可愛がら... developer.medley.jp JSConf JP 2024に プレミアムスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田(@Shige0096)です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上... developer.medley.jp DroidKaigi 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催され... developer.medley.jp TSKaigi 2025 の運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございました！ メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 TypeScript を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp ※カジュアル面談ご希望の際は、<その他> にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト統括部プロダクト開発部アカデミー開発グループ所属の城間（シロマ）です。 私は 2024 年 4 月に新卒エンジニアとして入社し、現在はオンライン動画研修サービス「 ジョブメドレーアカデミー 」の新規プロダクト開発に携わっています。 先日、5 月 23 日、24 日に東京都千代田区のベルサール神田にて開催された TSKaigi 2025 にメドレーは Silver Sponsor として協賛しました！ TypeScript をテーマにしたこの大規模なカンファレンスには、多様なバックグラウンドを持つ TypeScript エンジニアが全国から集結。 惜しくもブースの抽選には外れてしまいましたが、私も含め弊社からは数名のエンジニアが現地参加し、多くの素晴らしい出会いと学びがありました。 今回は、当日の会場の様子や印象に残ったセッション、そして今、私が感じていることを中心にご紹介します！ 会場の熱気と「型にとらわれない」エンジニアたちの交流 今年の TSKaigi 2025 は 2 日間とも天候に恵まれ、 61 もの企業スポンサーと「TypeScript を扱う型にとらわれないエンジニア」が集結し、会場は終日、熱気と活気に満ち溢れていました。 場内の様子 スポンサーボード 2 日間に渡り、合計 3 会場でセッションや LT が盛んに行われ、時には立ち見の人が出るほどに盛況していました。 参加者同士でテーマに対してトークする OST（Open Space Technology） や、夜の豪華な懇親会では、セッションでは聞けないような深掘りした技術の話や、各社の開発文化に関する交流が盛んに行われ、当日はおよそ 50 名以上のエンジニアの方々と色々なお話をさせていただきました。 OST のテーマ 懇親会の様子 TypeScript ケーキ また、今回参加者に配布された公式グッズは、TSKaigi のオリジナル T シャツやトートバッグに加え、各企業が工夫を凝らした遊び心あふれるグッズで盛りだくさんでした。 特に、今回ブース出展のあった 19 社全てを周るスタンプラリー では、全てのスタンプを集めることで豪華景品が当たる抽選に参加でき、会場の賑わいに一役買っていました。 公式ノベルティ（一部） スタンプラリー 印象に残ったセッション：AI エージェント全盛の時代と TypeScript の可能性 どのセッションも非常に興味深く、時には理解が追いつかないほど最先端の内容でしたが、特に今の私が行う開発と照らし合わせて印象に残ったセッションをいくつかご紹介します。 Day1: AI Coding Agent Enablement in TypeScript 引用元: AI Coding Agents Enablement in TypeScript - Speaker Deck 概要 このセッションでは、人間による介入を最小限に抑え、AI エージェントが大規模な作業をどのように「自走」して実行させるかについて深く掘り下げられました。 なぜ自走が難しいのか？その主な要因は AI エージェントが「任意の TypeScript」のようなあまりにも広い「解空間」で動くため、精度が低くなってしまうためです。 すなわち AI エージェントの精度を高めるためには 「可能な限り解空間を絞る」 ことが基本方針であり、会社やプロジェクト固有の規約、ドメイン知識、デザインなどに基づいて適切に制約を与える重要性が何度も強調されていました。 その解空間を絞る具体的なアプローチとして 「コンテキスト注入」 と 「機械的検査とフィードバック」 の 2 つが挙げられました。 コンテキスト注入 : ドキュメント、規約、ドメイン知識などを LLM にインプットし、「解空間の定義」を与えること。特に TypeScript コード自体をドキュメントとして育てることが、コンテキスト注入に役立つ。 機械的検査とフィードバック : LLM が生成したコードが定義された解空間から外れていないか、型チェック、Linter、自動テストといった古典的な手法で検査し、NG の場合はエージェントにフィードバックして解空間へと押し戻すように促す。Linter は次にやるべきアクションを提示しやすく、決定的である点が非常に有効である。 また、TypeScript 開発における型の役割についても興味深い見解がありました。現状、型によってコード生成の精度が上がるという定量的な根拠はまだないものの、「解空間に押し戻す」ためのエージェントへの入力（フィードバック）としては役立つ可能性は大いにあるとのこと。AI はまだ高度な型解決が苦手なので、人間がドメインモデルや関数のシグネチャ（型定義）をしっかり書き、その後の実装をエージェントに任せるアプローチが有効であるという話は、非常に現実的で納得感がありました。 最後に、 「エコシステムの未来 - Speed is King」 という言葉が印象的でした。これは、AI エージェントのコード生成が加速すると、開発プロセス全体の速度がボトルネックとなることを示唆しています。具体的には、人間がコードを 30 分かけて書く時代には 1 分程度の静的解析は許容範囲でしたが、AI が同じコードをわずか 30 秒で書くようになると同じ 1 分間の静的解析は AI の作業時間に対して相対的に非常に長く、無視できないボトルネックになるということです。さらにクラウド型エージェントではチャットごとにコンテナが作成される仕組みが主流であり、その際にパッケージマネージャの速度がボトルネックになります。また、AI エージェントによるコード生産量が爆発的に増加すれば、デプロイの機会も増えるためビルド（バンドラー）の速度もボトルネックとして顕在化し、加えて将来的に LLM がコードを生成するタイミング（デコーディング時）ごとに型制約を守ろうとする「制約付きデコーディング」のようなアプローチが進めば、型チェッカーがボトルネックになる可能性も指摘されていました。故に、ツールチェイン全体の高速化が今後より重要になるという示唆は、将来的な開発環境を考える上で非常に重要な視点だと感じました。 Day2: TS 特化 Cline プログラミング 引用元: tskaigi.mizchi.workers.dev 概要 このセッションでは、LLM を活用した「Cline Agentic Coding」の全般について、特に TypeScript に特化した実践的なプロンプトのコツが紹介されました。 まず冒頭に うまくいくうまくいくプロンプトのコツ として、以下が挙げられていました。 書きすぎない（再現性ある範囲で詠唱破棄） 執拗に出力例を例示する 両立条件の矛盾を避ける 規模感に合わせて厳しくする また特に強調されていたのは、 テスト駆動開発（Test Driven Development） の重要性です。コード生成時に対応するユニットテストを常に生成し、コード修正時にはテストがパスすることを確認することで、AI エージェントの自己修復能力を高め、放置しても完成する高品質なコードに繋がるとのことでした。 その他にも、次のような実践的なプロンプトの一例が紹介されていました。 コメントによる自己記述 : 各ファイルの冒頭にコメントで仕様を記述することで、再修正時のコード解釈の一貫性を保つ In Source Testing : 実装と同じファイルにユニットテストを書くことで、コメント・実装・テストを三位一体で管理する types.ts にドメイン型を集約 : 中規模以上のプロジェクトでは src/types.ts にドメインモデルを集約し、SSoT（Single Source of Truth）とすることで、ファイル間の整合性を保ち read_file の頻度を減らす TS + 関数型ドメインモデリング : 状態の発散を抑えるために class を使わず関数による実装を優先し、代数的データ型でドメインをモデリングする ファイル配置規則の明記 : モノレポなどのファイル配置規則を明記することで、タスクごとのエージェントの推測コストを減らす 詳細指示を docs/*.md に分割 : 大規模プロジェクトでは無関係な指示によるノイズを減らすために、詳細な指示をドキュメントファイルに分割し、必要に応じて参照させる カバレッジに基づくテストの自動生成 : vitest でカバレッジを計測し、最もカバレッジが上がるテストコードを AI に考察・追加させる 機械的なマイグレーション : lodash の削除や類似 API を持つライブラリへの置き換えなど、面倒なマイグレーション作業を AI に自動化させる URL を読む能力 : URL の内容を読み込ませ、要約・保存させることで、Deep Research 的な挙動を可能にする 一方で、 うまくいかないプロンプト のパターンもいくつか示唆されました。 型だけで設計しようとする : ほぼ確実に無視され、抽象的な設計能力は期待できない 非同期例外処理が下手 : 思考停止気味に try-catch で握り潰しがちで、大規模開発で破綻の原因となる 環境構築が下手 : ゼロショットでの環境構築は発散しやすく、手数が仇となり環境を破壊する可能性がある モジュールインターフェースが発散 : 実装次第で全て export してしまい、モジュール間の契約が肥大化・破綻する 「ある」のがよくない（チェーホフの銃の法則） : 無関係なリソースを読み込ませると、それを使うことに固執し、大規模コードではノイズになる デバッグログを食いすぎる : 自身が生成したプリントデバッグでコンテキストウィンドウを消費し、デバッグコードを放置しがちである 結論として、現状の LLM はコーディングが下手であり、低品質なコードで設計が破綻し自滅する傾向があるとの見解でした。特に、リファクタリングの指針がなく、不要コードの判定やモジュール視点での API 設計が苦手で、ユーザー側でリファクタリングしても元の低品質なコードに書き戻すこともあるという少し厳しい評価が下されていました。 しかし TypeScript と LLM の組み合わせには良い点も多く、GitHub の公開コードが豊富で学習量が多いこと、安全性よりも表現力を選んだピーキーな型システムが自然言語と対応した型のモデリングをしやすいこと、豊富な静的解析手段とユーザー層の厚さがあることなどが挙げられていました。 現時点でのベストプラクティスとしては、PoC/プロトタイプのコード生成（1 ファイル完結 800 行以内が目安）に活用し、人間によるインターフェース設計、失敗パターンのプロンプトへの反映、成功するパターンのドキュメント化、そしてこちらでも Lint ルールの整備についての言及がありました。 そして最後にテスト駆動開発や LLM の得意領域・発達段階を予測する技術、プロンプトエンジニアリングの重要性の増加など Agentic Coding によるプログラミング自体の変質と不変である点について説明され締めくくられました。 感想 これらのセッションを通して、私が携わる新規プロダクト開発において、 実践できている部分 と 改善の余地がある部分 が明確になりました。 実践できている点として、全社的に積極的に利用している AI エディタ「Cursor」のプロジェクトルールや自立型 AI エージェント「Devin」の knowledge には、プロジェクトごとに解空間を明確にするコンテキストを与えています。これは、「AI Coding Agent Enablement in TypeScript」で述べられていた「コンテキスト注入」と「解空間を絞る」という考え方に合致していると感じました。また、コードと仕様を記述したドキュメントを同じリポジトリ内で管理し、開発を進めている点も、AI へのコンテキスト注入に貢献していると言えるでしょう。 開発フローにおいても、AI の特性を踏まえた工夫を凝らしています。「AI Coding Agent Enablement in TypeScript」で言及があった「3 回くらいループした末に any とかキャストで誤魔化しがち」という点に対し、例えば API 開発では、まず仕様やテストケースのドキュメントをコードベースと同じファイル内に記述し、次に Request や Response Body を zod を用いて厳密に型を記述します。これらをエンジニアがレビューした後、テストデータのセットアップや記法などをエンジニアが整え、残りを AI で実装を進めます。さらにアプリケーションコードの実装においても、用意したユニットテストが通過するという制約の元 AI に実装させることにより、型解決などに AI エージェントが費やす時間が最小化され、 実装フェーズの開発工数を大幅に短縮することに成功 しています。 mizchi さんのセッションで言及のあったテスト駆動開発（Test Driven Development）のスキルは今後もより重要になっていくでしょう。しかし、もう少し先の未来では、弊社メドレーが大切にしている価値観（Our Essential）の一つである「 ドキュメントドリブン 」に倣い、 ドキュメントドリブン開発（Document Driven Development） のスキルがより重要になっていくのではないか、と私は考えています。 具体的なイメージ さらに「Speed is King」の思想を体現するために、Linter と Formatter には Biome、パッケージマネージャーには Bun を採用するなどツールチェインの速度にはかなりシビアな意思決定をしており、より AI エージェントが生産的に活動できるような体制を整えています。 一方で、 改善の余地がある点 も明確になりました。特に双方のセッションで強調されていた「機械的検査とフィードバック」の継続的な改善、すなわち Linter については開発初期から現在に至るまであまり積極的に更新できていないと痛感しています。AI に与えるフィードバックをその場での単発のもので終わらせるのではなく、（人間と同じように）再発防止策を考えさせるように Linter を定期的にアップデートし、より決定的で高速に AI エージェントが機能するような環境をより一層整備していきます。 さいごに TypeScript の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 メドレーは今後も TSKaigi だけでなく、他の技術イベントやコミュニティの発展を積極的に支援し、参加、貢献していきます。 過去にスポンサーとして協賛した技術カンファレンスの参加レポート記事はこちら！ RubyKaigi 2025 参加レポート - Platinum Sponsor として協賛しました！ | MEDLEY Developer Portal はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 1... developer.medley.jp pmconf 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。医療プラットフォーム本部で Product Manager をしている佐藤です。2024 年 5 月にメドレーにジョインし、医療機関向けプロダクト開発に奔走しています。社内では ”papa”、家では”おじさん”と呼ばれ可愛がら... developer.medley.jp JSConf JP 2024に プレミアムスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田(@Shige0096)です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上... developer.medley.jp DroidKaigi 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催され... developer.medley.jp TSKaigi 2025 の運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございました！ メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 TypeScript を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp ※カジュアル面談ご希望の際は、<その他> にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト統括部プロダクト開発部アカデミー開発グループ所属の城間（シロマ）です。 私は 2024 年 4 月に新卒エンジニアとして入社し、現在はオンライン動画研修サービス「 ジョブメドレーアカデミー 」の新規プロダクト開発に携わっています。 先日、5 月 23 日、24 日に東京都千代田区のベルサール神田にて開催された TSKaigi 2025 にメドレーは Silver Sponsor として協賛しました！ TypeScript をテーマにしたこの大規模なカンファレンスには、多様なバックグラウンドを持つ TypeScript エンジニアが全国から集結。 惜しくもブースの抽選には外れてしまいましたが、私も含め弊社からは数名のエンジニアが現地参加し、多くの素晴らしい出会いと学びがありました。 今回は、当日の会場の様子や印象に残ったセッション、そして今、私が感じていることを中心にご紹介します！ 会場の熱気と「型にとらわれない」エンジニアたちの交流 今年の TSKaigi 2025 は 2 日間とも天候に恵まれ、 61 もの企業スポンサーと「TypeScript を扱う型にとらわれないエンジニア」が集結し、会場は終日、熱気と活気に満ち溢れていました。 場内の様子 スポンサーボード 2 日間に渡り、合計 3 会場でセッションや LT が盛んに行われ、時には立ち見の人が出るほどに盛況していました。 参加者同士でテーマに対してトークする OST（Open Space Technology） や、夜の豪華な懇親会では、セッションでは聞けないような深掘りした技術の話や、各社の開発文化に関する交流が盛んに行われ、当日はおよそ 50 名以上のエンジニアの方々と色々なお話をさせていただきました。 OST のテーマ 懇親会の様子 TypeScript ケーキ また、今回参加者に配布された公式グッズは、TSKaigi のオリジナル T シャツやトートバッグに加え、各企業が工夫を凝らした遊び心あふれるグッズで盛りだくさんでした。 特に、今回ブース出展のあった 19 社全てを周るスタンプラリー では、全てのスタンプを集めることで豪華景品が当たる抽選に参加でき、会場の賑わいに一役買っていました。 公式ノベルティ（一部） スタンプラリー 印象に残ったセッション：AI エージェント全盛の時代と TypeScript の可能性 どのセッションも非常に興味深く、時には理解が追いつかないほど最先端の内容でしたが、特に今の私が行う開発と照らし合わせて印象に残ったセッションをいくつかご紹介します。 Day1: AI Coding Agent Enablement in TypeScript 引用元: AI Coding Agents Enablement in TypeScript - Speaker Deck 概要 このセッションでは、人間による介入を最小限に抑え、AI エージェントが大規模な作業をどのように「自走」して実行させるかについて深く掘り下げられました。 なぜ自走が難しいのか？その主な要因は AI エージェントが「任意の TypeScript」のようなあまりにも広い「解空間」で動くため、精度が低くなってしまうためです。 すなわち AI エージェントの精度を高めるためには 「可能な限り解空間を絞る」 ことが基本方針であり、会社やプロジェクト固有の規約、ドメイン知識、デザインなどに基づいて適切に制約を与える重要性が何度も強調されていました。 その解空間を絞る具体的なアプローチとして 「コンテキスト注入」 と 「機械的検査とフィードバック」 の 2 つが挙げられました。 コンテキスト注入 : ドキュメント、規約、ドメイン知識などを LLM にインプットし、「解空間の定義」を与えること。特に TypeScript コード自体をドキュメントとして育てることが、コンテキスト注入に役立つ。 機械的検査とフィードバック : LLM が生成したコードが定義された解空間から外れていないか、型チェック、Linter、自動テストといった古典的な手法で検査し、NG の場合はエージェントにフィードバックして解空間へと押し戻すように促す。Linter は次にやるべきアクションを提示しやすく、決定的である点が非常に有効である。 また、TypeScript 開発における型の役割についても興味深い見解がありました。現状、型によってコード生成の精度が上がるという定量的な根拠はまだないものの、「解空間に押し戻す」ためのエージェントへの入力（フィードバック）としては役立つ可能性は大いにあるとのこと。AI はまだ高度な型解決が苦手なので、人間がドメインモデルや関数のシグネチャ（型定義）をしっかり書き、その後の実装をエージェントに任せるアプローチが有効であるという話は、非常に現実的で納得感がありました。 最後に、 「エコシステムの未来 - Speed is King」 という言葉が印象的でした。これは、AI エージェントのコード生成が加速すると、開発プロセス全体の速度がボトルネックとなることを示唆しています。具体的には、人間がコードを 30 分かけて書く時代には 1 分程度の静的解析は許容範囲でしたが、AI が同じコードをわずか 30 秒で書くようになると同じ 1 分間の静的解析は AI の作業時間に対して相対的に非常に長く、無視できないボトルネックになるということです。さらにクラウド型エージェントではチャットごとにコンテナが作成される仕組みが主流であり、その際にパッケージマネージャの速度がボトルネックになります。また、AI エージェントによるコード生産量が爆発的に増加すれば、デプロイの機会も増えるためビルド（バンドラー）の速度もボトルネックとして顕在化し、加えて将来的に LLM がコードを生成するタイミング（デコーディング時）ごとに型制約を守ろうとする「制約付きデコーディング」のようなアプローチが進めば、型チェッカーがボトルネックになる可能性も指摘されていました。故に、ツールチェイン全体の高速化が今後より重要になるという示唆は、将来的な開発環境を考える上で非常に重要な視点だと感じました。 Day2: TS 特化 Cline プログラミング 引用元: tskaigi.mizchi.workers.dev 概要 このセッションでは、LLM を活用した「Cline Agentic Coding」の全般について、特に TypeScript に特化した実践的なプロンプトのコツが紹介されました。 まず冒頭に うまくいくうまくいくプロンプトのコツ として、以下が挙げられていました。 書きすぎない（再現性ある範囲で詠唱破棄） 執拗に出力例を例示する 両立条件の矛盾を避ける 規模感に合わせて厳しくする また特に強調されていたのは、 テスト駆動開発（Test Driven Development） の重要性です。コード生成時に対応するユニットテストを常に生成し、コード修正時にはテストがパスすることを確認することで、AI エージェントの自己修復能力を高め、放置しても完成する高品質なコードに繋がるとのことでした。 その他にも、次のような実践的なプロンプトの一例が紹介されていました。 コメントによる自己記述 : 各ファイルの冒頭にコメントで仕様を記述することで、再修正時のコード解釈の一貫性を保つ In Source Testing : 実装と同じファイルにユニットテストを書くことで、コメント・実装・テストを三位一体で管理する types.ts にドメイン型を集約 : 中規模以上のプロジェクトでは src/types.ts にドメインモデルを集約し、SSoT（Single Source of Truth）とすることで、ファイル間の整合性を保ち read_file の頻度を減らす TS + 関数型ドメインモデリング : 状態の発散を抑えるために class を使わず関数による実装を優先し、代数的データ型でドメインをモデリングする ファイル配置規則の明記 : モノレポなどのファイル配置規則を明記することで、タスクごとのエージェントの推測コストを減らす 詳細指示を docs/*.md に分割 : 大規模プロジェクトでは無関係な指示によるノイズを減らすために、詳細な指示をドキュメントファイルに分割し、必要に応じて参照させる カバレッジに基づくテストの自動生成 : vitest でカバレッジを計測し、最もカバレッジが上がるテストコードを AI に考察・追加させる 機械的なマイグレーション : lodash の削除や類似 API を持つライブラリへの置き換えなど、面倒なマイグレーション作業を AI に自動化させる URL を読む能力 : URL の内容を読み込ませ、要約・保存させることで、Deep Research 的な挙動を可能にする 一方で、 うまくいかないプロンプト のパターンもいくつか示唆されました。 型だけで設計しようとする : ほぼ確実に無視され、抽象的な設計能力は期待できない 非同期例外処理が下手 : 思考停止気味に try-catch で握り潰しがちで、大規模開発で破綻の原因となる 環境構築が下手 : ゼロショットでの環境構築は発散しやすく、手数が仇となり環境を破壊する可能性がある モジュールインターフェースが発散 : 実装次第で全て export してしまい、モジュール間の契約が肥大化・破綻する 「ある」のがよくない（チェーホフの銃の法則） : 無関係なリソースを読み込ませると、それを使うことに固執し、大規模コードではノイズになる デバッグログを食いすぎる : 自身が生成したプリントデバッグでコンテキストウィンドウを消費し、デバッグコードを放置しがちである 結論として、現状の LLM はコーディングが下手であり、低品質なコードで設計が破綻し自滅する傾向があるとの見解でした。特に、リファクタリングの指針がなく、不要コードの判定やモジュール視点での API 設計が苦手で、ユーザー側でリファクタリングしても元の低品質なコードに書き戻すこともあるという少し厳しい評価が下されていました。 しかし TypeScript と LLM の組み合わせには良い点も多く、GitHub の公開コードが豊富で学習量が多いこと、安全性よりも表現力を選んだピーキーな型システムが自然言語と対応した型のモデリングをしやすいこと、豊富な静的解析手段とユーザー層の厚さがあることなどが挙げられていました。 現時点でのベストプラクティスとしては、PoC/プロトタイプのコード生成（1 ファイル完結 800 行以内が目安）に活用し、人間によるインターフェース設計、失敗パターンのプロンプトへの反映、成功するパターンのドキュメント化、そしてこちらでも Lint ルールの整備についての言及がありました。 そして最後にテスト駆動開発や LLM の得意領域・発達段階を予測する技術、プロンプトエンジニアリングの重要性の増加など Agentic Coding によるプログラミング自体の変質と不変である点について説明され締めくくられました。 感想 これらのセッションを通して、私が携わる新規プロダクト開発において、 実践できている部分 と 改善の余地がある部分 が明確になりました。 実践できている点として、全社的に積極的に利用している AI エディタ「Cursor」のプロジェクトルールや自立型 AI エージェント「Devin」の knowledge には、プロジェクトごとに解空間を明確にするコンテキストを与えています。これは、「AI Coding Agent Enablement in TypeScript」で述べられていた「コンテキスト注入」と「解空間を絞る」という考え方に合致していると感じました。また、コードと仕様を記述したドキュメントを同じリポジトリ内で管理し、開発を進めている点も、AI へのコンテキスト注入に貢献していると言えるでしょう。 開発フローにおいても、AI の特性を踏まえた工夫を凝らしています。「AI Coding Agent Enablement in TypeScript」で言及があった「3 回くらいループした末に any とかキャストで誤魔化しがち」という点に対し、例えば API 開発では、まず仕様やテストケースのドキュメントをコードベースと同じファイル内に記述し、次に Request や Response Body を zod を用いて厳密に型を記述します。これらをエンジニアがレビューした後、テストデータのセットアップや記法などをエンジニアが整え、残りを AI で実装を進めます。さらにアプリケーションコードの実装においても、用意したユニットテストが通過するという制約の元 AI に実装させることにより、型解決などに AI エージェントが費やす時間が最小化され、 実装フェーズの開発工数を大幅に短縮することに成功 しています。 mizchi さんのセッションで言及のあったテスト駆動開発（Test Driven Development）のスキルは今後もより重要になっていくでしょう。しかし、もう少し先の未来では、弊社メドレーが大切にしている価値観（Our Essential）の一つである「 ドキュメントドリブン 」に倣い、 ドキュメントドリブン開発（Document Driven Development） のスキルがより重要になっていくのではないか、と私は考えています。 具体的なイメージ さらに「Speed is King」の思想を体現するために、Linter と Formatter には Biome、パッケージマネージャーには Bun を採用するなどツールチェインの速度にはかなりシビアな意思決定をしており、より AI エージェントが生産的に活動できるような体制を整えています。 一方で、 改善の余地がある点 も明確になりました。特に双方のセッションで強調されていた「機械的検査とフィードバック」の継続的な改善、すなわち Linter については開発初期から現在に至るまであまり積極的に更新できていないと痛感しています。AI に与えるフィードバックをその場での単発のもので終わらせるのではなく、（人間と同じように）再発防止策を考えさせるように Linter を定期的にアップデートし、より決定的で高速に AI エージェントが機能するような環境をより一層整備していきます。 さいごに TypeScript の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 メドレーは今後も TSKaigi だけでなく、他の技術イベントやコミュニティの発展を積極的に支援し、参加、貢献していきます。 過去にスポンサーとして協賛した技術カンファレンスの参加レポート記事はこちら！ RubyKaigi 2025 参加レポート - Platinum Sponsor として協賛しました！ | MEDLEY Developer Portal はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 1... developer.medley.jp pmconf 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。医療プラットフォーム本部で Product Manager をしている佐藤です。2024 年 5 月にメドレーにジョインし、医療機関向けプロダクト開発に奔走しています。社内では ”papa”、家では”おじさん”と呼ばれ可愛がら... developer.medley.jp JSConf JP 2024に プレミアムスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田(@Shige0096)です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上... developer.medley.jp DroidKaigi 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催され... developer.medley.jp TSKaigi 2025 の運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございました！ メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 TypeScript を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp ※カジュアル面談ご希望の際は、<その他> にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト統括部プロダクト開発部アカデミー開発グループ所属の城間（シロマ）です。 私は 2024 年 4 月に新卒エンジニアとして入社し、現在はオンライン動画研修サービス「 ジョブメドレーアカデミー 」の新規プロダクト開発に携わっています。 先日、5 月 23 日、24 日に東京都千代田区のベルサール神田にて開催された TSKaigi 2025 にメドレーは Silver Sponsor として協賛しました！ TypeScript をテーマにしたこの大規模なカンファレンスには、多様なバックグラウンドを持つ TypeScript エンジニアが全国から集結。 惜しくもブースの抽選には外れてしまいましたが、私も含め弊社からは数名のエンジニアが現地参加し、多くの素晴らしい出会いと学びがありました。 今回は、当日の会場の様子や印象に残ったセッション、そして今、私が感じていることを中心にご紹介します！ 会場の熱気と「型にとらわれない」エンジニアたちの交流 今年の TSKaigi 2025 は 2 日間とも天候に恵まれ、 61 もの企業スポンサーと「TypeScript を扱う型にとらわれないエンジニア」が集結し、会場は終日、熱気と活気に満ち溢れていました。 場内の様子 スポンサーボード 2 日間に渡り、合計 3 会場でセッションや LT が盛んに行われ、時には立ち見の人が出るほどに盛況していました。 参加者同士でテーマに対してトークする OST（Open Space Technology） や、夜の豪華な懇親会では、セッションでは聞けないような深掘りした技術の話や、各社の開発文化に関する交流が盛んに行われ、当日はおよそ 50 名以上のエンジニアの方々と色々なお話をさせていただきました。 OST のテーマ 懇親会の様子 TypeScript ケーキ また、今回参加者に配布された公式グッズは、TSKaigi のオリジナル T シャツやトートバッグに加え、各企業が工夫を凝らした遊び心あふれるグッズで盛りだくさんでした。 特に、今回ブース出展のあった 19 社全てを周るスタンプラリー では、全てのスタンプを集めることで豪華景品が当たる抽選に参加でき、会場の賑わいに一役買っていました。 公式ノベルティ（一部） スタンプラリー 印象に残ったセッション：AI エージェント全盛の時代と TypeScript の可能性 どのセッションも非常に興味深く、時には理解が追いつかないほど最先端の内容でしたが、特に今の私が行う開発と照らし合わせて印象に残ったセッションをいくつかご紹介します。 Day1: AI Coding Agent Enablement in TypeScript 引用元: AI Coding Agents Enablement in TypeScript - Speaker Deck 概要 このセッションでは、人間による介入を最小限に抑え、AI エージェントが大規模な作業をどのように「自走」して実行させるかについて深く掘り下げられました。 なぜ自走が難しいのか？その主な要因は AI エージェントが「任意の TypeScript」のようなあまりにも広い「解空間」で動くため、精度が低くなってしまうためです。 すなわち AI エージェントの精度を高めるためには 「可能な限り解空間を絞る」 ことが基本方針であり、会社やプロジェクト固有の規約、ドメイン知識、デザインなどに基づいて適切に制約を与える重要性が何度も強調されていました。 その解空間を絞る具体的なアプローチとして 「コンテキスト注入」 と 「機械的検査とフィードバック」 の 2 つが挙げられました。 コンテキスト注入 : ドキュメント、規約、ドメイン知識などを LLM にインプットし、「解空間の定義」を与えること。特に TypeScript コード自体をドキュメントとして育てることが、コンテキスト注入に役立つ。 機械的検査とフィードバック : LLM が生成したコードが定義された解空間から外れていないか、型チェック、Linter、自動テストといった古典的な手法で検査し、NG の場合はエージェントにフィードバックして解空間へと押し戻すように促す。Linter は次にやるべきアクションを提示しやすく、決定的である点が非常に有効である。 また、TypeScript 開発における型の役割についても興味深い見解がありました。現状、型によってコード生成の精度が上がるという定量的な根拠はまだないものの、「解空間に押し戻す」ためのエージェントへの入力（フィードバック）としては役立つ可能性は大いにあるとのこと。AI はまだ高度な型解決が苦手なので、人間がドメインモデルや関数のシグネチャ（型定義）をしっかり書き、その後の実装をエージェントに任せるアプローチが有効であるという話は、非常に現実的で納得感がありました。 最後に、 「エコシステムの未来 - Speed is King」 という言葉が印象的でした。これは、AI エージェントのコード生成が加速すると、開発プロセス全体の速度がボトルネックとなることを示唆しています。具体的には、人間がコードを 30 分かけて書く時代には 1 分程度の静的解析は許容範囲でしたが、AI が同じコードをわずか 30 秒で書くようになると同じ 1 分間の静的解析は AI の作業時間に対して相対的に非常に長く、無視できないボトルネックになるということです。さらにクラウド型エージェントではチャットごとにコンテナが作成される仕組みが主流であり、その際にパッケージマネージャの速度がボトルネックになります。また、AI エージェントによるコード生産量が爆発的に増加すれば、デプロイの機会も増えるためビルド（バンドラー）の速度もボトルネックとして顕在化し、加えて将来的に LLM がコードを生成するタイミング（デコーディング時）ごとに型制約を守ろうとする「制約付きデコーディング」のようなアプローチが進めば、型チェッカーがボトルネックになる可能性も指摘されていました。故に、ツールチェイン全体の高速化が今後より重要になるという示唆は、将来的な開発環境を考える上で非常に重要な視点だと感じました。 Day2: TS 特化 Cline プログラミング 引用元: tskaigi.mizchi.workers.dev 概要 このセッションでは、LLM を活用した「Cline Agentic Coding」の全般について、特に TypeScript に特化した実践的なプロンプトのコツが紹介されました。 まず冒頭に うまくいくうまくいくプロンプトのコツ として、以下が挙げられていました。 書きすぎない（再現性ある範囲で詠唱破棄） 執拗に出力例を例示する 両立条件の矛盾を避ける 規模感に合わせて厳しくする また特に強調されていたのは、 テスト駆動開発（Test Driven Development） の重要性です。コード生成時に対応するユニットテストを常に生成し、コード修正時にはテストがパスすることを確認することで、AI エージェントの自己修復能力を高め、放置しても完成する高品質なコードに繋がるとのことでした。 その他にも、次のような実践的なプロンプトの一例が紹介されていました。 コメントによる自己記述 : 各ファイルの冒頭にコメントで仕様を記述することで、再修正時のコード解釈の一貫性を保つ In Source Testing : 実装と同じファイルにユニットテストを書くことで、コメント・実装・テストを三位一体で管理する types.ts にドメイン型を集約 : 中規模以上のプロジェクトでは src/types.ts にドメインモデルを集約し、SSoT（Single Source of Truth）とすることで、ファイル間の整合性を保ち read_file の頻度を減らす TS + 関数型ドメインモデリング : 状態の発散を抑えるために class を使わず関数による実装を優先し、代数的データ型でドメインをモデリングする ファイル配置規則の明記 : モノレポなどのファイル配置規則を明記することで、タスクごとのエージェントの推測コストを減らす 詳細指示を docs/*.md に分割 : 大規模プロジェクトでは無関係な指示によるノイズを減らすために、詳細な指示をドキュメントファイルに分割し、必要に応じて参照させる カバレッジに基づくテストの自動生成 : vitest でカバレッジを計測し、最もカバレッジが上がるテストコードを AI に考察・追加させる 機械的なマイグレーション : lodash の削除や類似 API を持つライブラリへの置き換えなど、面倒なマイグレーション作業を AI に自動化させる URL を読む能力 : URL の内容を読み込ませ、要約・保存させることで、Deep Research 的な挙動を可能にする 一方で、 うまくいかないプロンプト のパターンもいくつか示唆されました。 型だけで設計しようとする : ほぼ確実に無視され、抽象的な設計能力は期待できない 非同期例外処理が下手 : 思考停止気味に try-catch で握り潰しがちで、大規模開発で破綻の原因となる 環境構築が下手 : ゼロショットでの環境構築は発散しやすく、手数が仇となり環境を破壊する可能性がある モジュールインターフェースが発散 : 実装次第で全て export してしまい、モジュール間の契約が肥大化・破綻する 「ある」のがよくない（チェーホフの銃の法則） : 無関係なリソースを読み込ませると、それを使うことに固執し、大規模コードではノイズになる デバッグログを食いすぎる : 自身が生成したプリントデバッグでコンテキストウィンドウを消費し、デバッグコードを放置しがちである 結論として、現状の LLM はコーディングが下手であり、低品質なコードで設計が破綻し自滅する傾向があるとの見解でした。特に、リファクタリングの指針がなく、不要コードの判定やモジュール視点での API 設計が苦手で、ユーザー側でリファクタリングしても元の低品質なコードに書き戻すこともあるという少し厳しい評価が下されていました。 しかし TypeScript と LLM の組み合わせには良い点も多く、GitHub の公開コードが豊富で学習量が多いこと、安全性よりも表現力を選んだピーキーな型システムが自然言語と対応した型のモデリングをしやすいこと、豊富な静的解析手段とユーザー層の厚さがあることなどが挙げられていました。 現時点でのベストプラクティスとしては、PoC/プロトタイプのコード生成（1 ファイル完結 800 行以内が目安）に活用し、人間によるインターフェース設計、失敗パターンのプロンプトへの反映、成功するパターンのドキュメント化、そしてこちらでも Lint ルールの整備についての言及がありました。 そして最後にテスト駆動開発や LLM の得意領域・発達段階を予測する技術、プロンプトエンジニアリングの重要性の増加など Agentic Coding によるプログラミング自体の変質と不変である点について説明され締めくくられました。 感想 これらのセッションを通して、私が携わる新規プロダクト開発において、 実践できている部分 と 改善の余地がある部分 が明確になりました。 実践できている点として、全社的に積極的に利用している AI エディタ「Cursor」のプロジェクトルールや自立型 AI エージェント「Devin」の knowledge には、プロジェクトごとに解空間を明確にするコンテキストを与えています。これは、「AI Coding Agent Enablement in TypeScript」で述べられていた「コンテキスト注入」と「解空間を絞る」という考え方に合致していると感じました。また、コードと仕様を記述したドキュメントを同じリポジトリ内で管理し、開発を進めている点も、AI へのコンテキスト注入に貢献していると言えるでしょう。 開発フローにおいても、AI の特性を踏まえた工夫を凝らしています。「AI Coding Agent Enablement in TypeScript」で言及があった「3 回くらいループした末に any とかキャストで誤魔化しがち」という点に対し、例えば API 開発では、まず仕様やテストケースのドキュメントをコードベースと同じファイル内に記述し、次に Request や Response Body を zod を用いて厳密に型を記述します。これらをエンジニアがレビューした後、テストデータのセットアップや記法などをエンジニアが整え、残りを AI で実装を進めます。さらにアプリケーションコードの実装においても、用意したユニットテストが通過するという制約の元 AI に実装させることにより、型解決などに AI エージェントが費やす時間が最小化され、 実装フェーズの開発工数を大幅に短縮することに成功 しています。 mizchi さんのセッションで言及のあったテスト駆動開発（Test Driven Development）のスキルは今後もより重要になっていくでしょう。しかし、もう少し先の未来では、弊社メドレーが大切にしている価値観（Our Essential）の一つである「 ドキュメントドリブン 」に倣い、 ドキュメントドリブン開発（Document Driven Development） のスキルがより重要になっていくのではないか、と私は考えています。 具体的なイメージ さらに「Speed is King」の思想を体現するために、Linter と Formatter には Biome、パッケージマネージャーには Bun を採用するなどツールチェインの速度にはかなりシビアな意思決定をしており、より AI エージェントが生産的に活動できるような体制を整えています。 一方で、 改善の余地がある点 も明確になりました。特に双方のセッションで強調されていた「機械的検査とフィードバック」の継続的な改善、すなわち Linter については開発初期から現在に至るまであまり積極的に更新できていないと痛感しています。AI に与えるフィードバックをその場での単発のもので終わらせるのではなく、（人間と同じように）再発防止策を考えさせるように Linter を定期的にアップデートし、より決定的で高速に AI エージェントが機能するような環境をより一層整備していきます。 さいごに TypeScript の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 メドレーは今後も TSKaigi だけでなく、他の技術イベントやコミュニティの発展を積極的に支援し、参加、貢献していきます。 過去にスポンサーとして協賛した技術カンファレンスの参加レポート記事はこちら！ RubyKaigi 2025 参加レポート - Platinum Sponsor として協賛しました！ | MEDLEY Developer Portal はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 1... developer.medley.jp pmconf 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。医療プラットフォーム本部で Product Manager をしている佐藤です。2024 年 5 月にメドレーにジョインし、医療機関向けプロダクト開発に奔走しています。社内では ”papa”、家では”おじさん”と呼ばれ可愛がら... developer.medley.jp JSConf JP 2024に プレミアムスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田(@Shige0096)です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上... developer.medley.jp DroidKaigi 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催され... developer.medley.jp TSKaigi 2025 の運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございました！ メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 TypeScript を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp ※カジュアル面談ご希望の際は、<その他> にてその旨をご記載ください