はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ https://www.medley.jp/jobs/

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! https://www.medley.jp/jobs/

はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は今年の 3 月にリリースされた Dentis のサブカルテ機能について、開発したメンバーに話を聞いてみました! 対談メンバー紹介 Dentis 開発メンバーの紹介 新居 : よろしくお願いします。早速ですが、メドレーに入社するまでや、入ってからどんな事をしていたのかを話してもらえればと思います。 前田 : CLINICS のリリース前から、ロゴデザインや UI デザインに携わったのがきっかけでメドレーに入社しました。入社してからは、CLINICS アプリや CLINICS カルテ、薬局向けシステム Pharms などのプロダクトをこのメンバーと一緒に開発していました。今は歯科医院向けの Dentis のデザインや企画、プロモーションなどに関わっています。 前田さん 大岡 : ソーシャルゲームを 6~7 年開発していたのですが、人材プラットフォームの CTO である稲本が中学の同級生で、彼の記事を読んだのがきっかけでメドレーに入社しました。入社してからは CLINICS カルテや iOS アプリの開発などをやっていました。その後は前田と同じで Pharms の開発をしてから、現在は Dentis を開発しています。他には電子処方箋の実証事業の開発などもしていたりしました。現在は Web のフロントエンド中心に開発をしています。 大岡さん 宮内 : 元同僚が働いていたので、メドレーにリファラルで入社しました。CLINICS オンライン診療の立ち上げをやった後は他の 2 人と同じで Pharms の開発をして、現在は Dentis の開発という感じです。今は主にサーバサイドの開発を中心に業務をしています。 Dentis について Dentis 誕生まで 新居 : ありがとうございました。では、Dentis についてお聞きしたいのですが、どんなきっかけで作られたサービスなんですか? 前田 : 当初は、CLINICS カルテをベースとした歯科医院向けの予約システムを開発していたのですが、歯科レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）のソースコードを 取得 するタイミングも重なり、予約システムだけではなく、レセコン一体型のシステムとして、本格的に開発をスタートしました。 詳しくは こちらの記事 を参照ください。 新居 : なるほど。そんな形で開発が始まった Dentis ですが、コロナ禍で途中で 作り直していますよね 。再開してからは 1 から開発したんですか? 前田 : はい、CLINICS をベースに開発していたものの、歯科医院へのヒアリングなどを実施、調査をしていくうちに医科と歯科では業務オペレーションが異なり予約システムとしては不十分な機能だったことが判明して。特に予約部分などはコンセプトから考え直して UI を一から作り直しました。 宮内 : 途中で Pharms を開発してリリースしたことにより、そこで使った設計や技術などを応用できたというプラスの側面もあり、再度作り直しています。 Next.js を導入したりなどですね。 大岡 : 以前の Dentis はパイロット版として提供をしていたこともあり、しっかり作り変える後押しになったかもしれないです。 新居 : そうすると開発自体も以前よりも、やりやすくもなったんですね。スムーズに開発できるようになったおかげで、 特許 も取得できる UI ができたわけですね。 Dentis のアーキテクチャについて 新居 : 現在の Dentis のアーキテクチャはどんなものになっているんでしょう。 宮内 : サーバサイドは Rails アプリケーションになっています。そこにプラスして GraphQL を使用しています。フロントエンドは Next.js と Apollo を使って GraphQL にアクセスするという形で全て AWS 上に乗っているという感じですね。 新居 : オーソドックスな構成になっているんですね。何か使いづらいなどはないですか? 大岡 : 使いづらいということはないんですが、フロントエンド側でデータをオーバフェッチしている所があるんで、そこは見直さないといけないと思っているところです。 新居 : フロントエンドの状態管理はどのようにしているんですか? 大岡 : Recoil を使っています。ですが、ライブラリの持続可能性を考えて別の方法に移行したほうがよいなとは考えているところですね…。 サブカルテ機能の開発 サブカルテ機能とは 新居 : では今回のメインの話である サブカルテ 機能について、お話を伺えればと思いますが、そもそもサブカルテとはどんなものなんでしょうか。 前田 : 歯科特有の機能になると思うのですが、カルテに記録しない患者に関する情報、たとえばレントゲンや口腔写真などのファイル管理や文書管理などをデジタル化する機能です。デジタルで管理することで、写真やファイルを保管する場所を確保する必要がなくなり、院内空間を有効活用することもできますよね。また、Dentis にあって他社にない機能としては「アクティビティ」でしょうか。院内のスタッフ間で情報共有ができる機能で、Dentis を活用いただいている歯科医院から好評をいただいている機能のひとつです。 普通は院内でスタッフの情報共有をする場合は、紙カルテなどに直接書き込みするのですが、Slack のようなタイムライン形式で情報共有できリアクションなども取れるようにしているのが「アクティビティ」機能になります。 宮内 : 歯科医院は歯科医師以外にも、歯科衛生士や歯科助手など多数の人達が連携して治療にあたるチーム医療をしているので、このような使い方をしているようです。またサブカルテの内容としては医院独自になっているようなので、Dentis のサブカルテは様々な使い方をリサーチして一般的に使いやすいであろうという形にしています。 新居 : アクティビティなどは、今の形に落ち着くまで機能を考えるのは大変そうですね。 前田 : はい、最初は Markdown を書いていけるような Wiki のような形も考えていたりしたので、タイムライン形式に落ち着くまでは試行錯誤しました。医院のコミュニケーションの仕方によって使用率も違いますが、結構使ってくださっていますね。 大岡 : 画像ファイルにメモなどを残している医院などもあるようで、ワークフローによって使いやすい方を選んでいるようです。 前田 : Dentis は医院のペーパーレス化を促進するプロダクトなので、使い方としては様々ですが紙でのワークフローの感覚でそのまま、もっと便利に使えるという部分を重視しています。 サブカルテ機能の開発背景 新居 : そんなサブカルテ機能ですが、開発しようとなった背景としてはどんなものがあったんでしょうか。 前田 : Dentis では「シームレスにつながる」というのをひとつのコンセプトとして設計しているのですが、予約〜カルテ〜会計まで機能的につなげても、業務フローとしてはどうしても隙間が生じていて、シームレスにつながってない事に気づいたんですよね。院内スタッフ間でのちょっとしたコミュニケーションもデジタルで管理できれば、その隙間を埋め、歯科医院の DX 化を推進できるのではないかと思い、サブカルテの開発を始めました。先程も言ったように、ペーパーレス化を促進という目的にも合致していましたしね。 技術的に難しかった部分 新居 : 技術的に困難なところなどはありましたか? 大岡 : 手書きメモと組写真機能(撮影した口腔内の画像を 5 枚や 10 枚で組み合わせて表示する歯科の画像表示形式)を Chrome と iPad / Mac Safari に対応させるのは難しかったかもしれません。 どれかに対応させると、どれかが上手く表示できないなどがあったので。 宮内 : 画像の表示ライブラリを途中で変更したりしましたよね。 大岡 : 最初は Konva というライブラリだったんですが、ゆっくりペンを動かすと、滑らかな線が書けないという問題が発生しまして…。 Fabric.js を使うように変更しました。 サブカルテ機能を作ったことによるプロダクトへの良い効果 新居 : ありがとうございます。サブカルテ機能は今の形になるまで、どのような検討をしたんでしょうか。 前田 : 元々ファイル管理機能などは既に Dentis であった機能だったんです。そこは活かしつつも、求められる他の機能は何かというところを考えていきながら、様々なサブカルテの活用事例もリサーチしながら、今の形に落ち着いたという感じです。 大岡 : 副産物としては今まで Dentis にはなかった「患者詳細」という画面をこのサブカルテ機能を入れるために拡張していったので、その後のオンライン資格確認などへ展開しやすいという状態になりました。情報設計を見直せたおかげです。 前田 : サブカルテ起点で患者検索もさらに詳細にできたりしたので、そうした副産物も大変良かったです。 サブカルテ機能追加による反響 新居 : 医院からはサブカルテの追加により何か反響はあったんでしょうか。 前田 : ネガティブな意見はあまりないですし、むしろ「追加機能としてこういうのが欲しい」というご意見をいただくので、結構使っていただけていると思います。 宮内 : ちょっと興味深かったのが、承認ボタンが欲しいというご意見がありました。医院のワークフローとして、医師以外の方が行なおうとする処置などを「アクティビティ」上で医師に承認してもらうというフローのようです。すぐに導入できるかというとちょっと分からないのですが。 Dentis チームにマッチするメンバー 新居 : ありがとうございます。最後にそんな Dentis チームで一緒に働いてみたいと思うような方はどんな人でしょうか。 前田 : 高齢化が進んでおり、そろそろ若い人に来てほしいですね（笑） 宮内 : どの領域の開発メンバーでも現在は少人数で運営しているので、入ってほしいなとは思います…。一番欲しいというメンバーでいうと「歯科レセコンに精通した開発者」の方ですかね。 新居 : なかなかハードルが高そうな経験ですね（笑） 本日はありがとうございました! さいごに Dentis のサブカルテ機能の開発について、開発者に聞いてみました。歯科には歯科独自のワークフローがあり、紙の運用が重視されてきた風潮の中で、業務オペレーションをふまえて開発していくユーザーファーストな開発者の発想やそれを実現する技術アプローチなど、とても面白い開発をしているなと話を聞いていて思いました。 Dentis の開発チームはベテラン揃いなので、彼らと肩を並べて働くことで、自身の成長を加速させる絶好の機会になると思います。 Dentis の開発に興味を持った方はぜひご連絡お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は今年の 3 月にリリースされた Dentis のサブカルテ機能について、開発したメンバーに話を聞いてみました! 対談メンバー紹介 Dentis 開発メンバーの紹介 新居 : よろしくお願いします。早速ですが、メドレーに入社するまでや、入ってからどんな事をしていたのかを話してもらえればと思います。 前田 : CLINICS のリリース前から、ロゴデザインや UI デザインに携わったのがきっかけでメドレーに入社しました。入社してからは、CLINICS アプリや CLINICS カルテ、薬局向けシステム Pharms などのプロダクトをこのメンバーと一緒に開発していました。今は歯科医院向けの Dentis のデザインや企画、プロモーションなどに関わっています。 前田さん 大岡 : ソーシャルゲームを 6~7 年開発していたのですが、人材プラットフォームの CTO である稲本が中学の同級生で、彼の記事を読んだのがきっかけでメドレーに入社しました。入社してからは CLINICS カルテや iOS アプリの開発などをやっていました。その後は前田と同じで Pharms の開発をしてから、現在は Dentis を開発しています。他には電子処方箋の実証事業の開発などもしていたりしました。現在は Web のフロントエンド中心に開発をしています。 大岡さん 宮内 : 元同僚が働いていたので、メドレーにリファラルで入社しました。CLINICS オンライン診療の立ち上げをやった後は他の 2 人と同じで Pharms の開発をして、現在は Dentis の開発という感じです。今は主にサーバサイドの開発を中心に業務をしています。 Dentis について Dentis 誕生まで 新居 : ありがとうございました。では、Dentis についてお聞きしたいのですが、どんなきっかけで作られたサービスなんですか? 前田 : 当初は、CLINICS カルテをベースとした歯科医院向けの予約システムを開発していたのですが、歯科レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）のソースコードを 取得 するタイミングも重なり、予約システムだけではなく、レセコン一体型のシステムとして、本格的に開発をスタートしました。 詳しくは こちらの記事 を参照ください。 新居 : なるほど。そんな形で開発が始まった Dentis ですが、コロナ禍で途中で 作り直していますよね 。再開してからは 1 から開発したんですか? 前田 : はい、CLINICS をベースに開発していたものの、歯科医院へのヒアリングなどを実施、調査をしていくうちに医科と歯科では業務オペレーションが異なり予約システムとしては不十分な機能だったことが判明して。特に予約部分などはコンセプトから考え直して UI を一から作り直しました。 宮内 : 途中で Pharms を開発してリリースしたことにより、そこで使った設計や技術などを応用できたというプラスの側面もあり、再度作り直しています。 Next.js を導入したりなどですね。 大岡 : 以前の Dentis はパイロット版として提供をしていたこともあり、しっかり作り変える後押しになったかもしれないです。 新居 : そうすると開発自体も以前よりも、やりやすくもなったんですね。スムーズに開発できるようになったおかげで、 特許 も取得できる UI ができたわけですね。 Dentis のアーキテクチャについて 新居 : 現在の Dentis のアーキテクチャはどんなものになっているんでしょう。 宮内 : サーバサイドは Rails アプリケーションになっています。そこにプラスして GraphQL を使用しています。フロントエンドは Next.js と Apollo を使って GraphQL にアクセスするという形で全て AWS 上に乗っているという感じですね。 新居 : オーソドックスな構成になっているんですね。何か使いづらいなどはないですか? 大岡 : 使いづらいということはないんですが、フロントエンド側でデータをオーバフェッチしている所があるんで、そこは見直さないといけないと思っているところです。 新居 : フロントエンドの状態管理はどのようにしているんですか? 大岡 : Recoil を使っています。ですが、ライブラリの持続可能性を考えて別の方法に移行したほうがよいなとは考えているところですね…。 サブカルテ機能の開発 サブカルテ機能とは 新居 : では今回のメインの話である サブカルテ 機能について、お話を伺えればと思いますが、そもそもサブカルテとはどんなものなんでしょうか。 前田 : 歯科特有の機能になると思うのですが、カルテに記録しない患者に関する情報、たとえばレントゲンや口腔写真などのファイル管理や文書管理などをデジタル化する機能です。デジタルで管理することで、写真やファイルを保管する場所を確保する必要がなくなり、院内空間を有効活用することもできますよね。また、Dentis にあって他社にない機能としては「アクティビティ」でしょうか。院内のスタッフ間で情報共有ができる機能で、Dentis を活用いただいている歯科医院から好評をいただいている機能のひとつです。 普通は院内でスタッフの情報共有をする場合は、紙カルテなどに直接書き込みするのですが、Slack のようなタイムライン形式で情報共有できリアクションなども取れるようにしているのが「アクティビティ」機能になります。 宮内 : 歯科医院は歯科医師以外にも、歯科衛生士や歯科助手など多数の人達が連携して治療にあたるチーム医療をしているので、このような使い方をしているようです。またサブカルテの内容としては医院独自になっているようなので、Dentis のサブカルテは様々な使い方をリサーチして一般的に使いやすいであろうという形にしています。 新居 : アクティビティなどは、今の形に落ち着くまで機能を考えるのは大変そうですね。 前田 : はい、最初は Markdown を書いていけるような Wiki のような形も考えていたりしたので、タイムライン形式に落ち着くまでは試行錯誤しました。医院のコミュニケーションの仕方によって使用率も違いますが、結構使ってくださっていますね。 大岡 : 画像ファイルにメモなどを残している医院などもあるようで、ワークフローによって使いやすい方を選んでいるようです。 前田 : Dentis は医院のペーパーレス化を促進するプロダクトなので、使い方としては様々ですが紙でのワークフローの感覚でそのまま、もっと便利に使えるという部分を重視しています。 サブカルテ機能の開発背景 新居 : そんなサブカルテ機能ですが、開発しようとなった背景としてはどんなものがあったんでしょうか。 前田 : Dentis では「シームレスにつながる」というのをひとつのコンセプトとして設計しているのですが、予約〜カルテ〜会計まで機能的につなげても、業務フローとしてはどうしても隙間が生じていて、シームレスにつながってない事に気づいたんですよね。院内スタッフ間でのちょっとしたコミュニケーションもデジタルで管理できれば、その隙間を埋め、歯科医院の DX 化を推進できるのではないかと思い、サブカルテの開発を始めました。先程も言ったように、ペーパーレス化を促進という目的にも合致していましたしね。 技術的に難しかった部分 新居 : 技術的に困難なところなどはありましたか? 大岡 : 手書きメモと組写真機能(撮影した口腔内の画像を 5 枚や 10 枚で組み合わせて表示する歯科の画像表示形式)を Chrome と iPad / Mac Safari に対応させるのは難しかったかもしれません。 どれかに対応させると、どれかが上手く表示できないなどがあったので。 宮内 : 画像の表示ライブラリを途中で変更したりしましたよね。 大岡 : 最初は Konva というライブラリだったんですが、ゆっくりペンを動かすと、滑らかな線が書けないという問題が発生しまして…。 Fabric.js を使うように変更しました。 サブカルテ機能を作ったことによるプロダクトへの良い効果 新居 : ありがとうございます。サブカルテ機能は今の形になるまで、どのような検討をしたんでしょうか。 前田 : 元々ファイル管理機能などは既に Dentis であった機能だったんです。そこは活かしつつも、求められる他の機能は何かというところを考えていきながら、様々なサブカルテの活用事例もリサーチしながら、今の形に落ち着いたという感じです。 大岡 : 副産物としては今まで Dentis にはなかった「患者詳細」という画面をこのサブカルテ機能を入れるために拡張していったので、その後のオンライン資格確認などへ展開しやすいという状態になりました。情報設計を見直せたおかげです。 前田 : サブカルテ起点で患者検索もさらに詳細にできたりしたので、そうした副産物も大変良かったです。 サブカルテ機能追加による反響 新居 : 医院からはサブカルテの追加により何か反響はあったんでしょうか。 前田 : ネガティブな意見はあまりないですし、むしろ「追加機能としてこういうのが欲しい」というご意見をいただくので、結構使っていただけていると思います。 宮内 : ちょっと興味深かったのが、承認ボタンが欲しいというご意見がありました。医院のワークフローとして、医師以外の方が行なおうとする処置などを「アクティビティ」上で医師に承認してもらうというフローのようです。すぐに導入できるかというとちょっと分からないのですが。 Dentis チームにマッチするメンバー 新居 : ありがとうございます。最後にそんな Dentis チームで一緒に働いてみたいと思うような方はどんな人でしょうか。 前田 : 高齢化が進んでおり、そろそろ若い人に来てほしいですね（笑） 宮内 : どの領域の開発メンバーでも現在は少人数で運営しているので、入ってほしいなとは思います…。一番欲しいというメンバーでいうと「歯科レセコンに精通した開発者」の方ですかね。 新居 : なかなかハードルが高そうな経験ですね（笑） 本日はありがとうございました! さいごに Dentis のサブカルテ機能の開発について、開発者に聞いてみました。歯科には歯科独自のワークフローがあり、紙の運用が重視されてきた風潮の中で、業務オペレーションをふまえて開発していくユーザーファーストな開発者の発想やそれを実現する技術アプローチなど、とても面白い開発をしているなと話を聞いていて思いました。 Dentis の開発チームはベテラン揃いなので、彼らと肩を並べて働くことで、自身の成長を加速させる絶好の機会になると思います。 Dentis の開発に興味を持った方はぜひご連絡お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は今年の 3 月にリリースされた Dentis のサブカルテ機能について、開発したメンバーに話を聞いてみました! 対談メンバー紹介 Dentis 開発メンバーの紹介 新居 : よろしくお願いします。早速ですが、メドレーに入社するまでや、入ってからどんな事をしていたのかを話してもらえればと思います。 前田 : CLINICS のリリース前から、ロゴデザインや UI デザインに携わったのがきっかけでメドレーに入社しました。入社してからは、CLINICS アプリや CLINICS カルテ、薬局向けシステム Pharms などのプロダクトをこのメンバーと一緒に開発していました。今は歯科医院向けの Dentis のデザインや企画、プロモーションなどに関わっています。 前田さん 大岡 : ソーシャルゲームを 6~7 年開発していたのですが、人材プラットフォームの CTO である稲本が中学の同級生で、彼の記事を読んだのがきっかけでメドレーに入社しました。入社してからは CLINICS カルテや iOS アプリの開発などをやっていました。その後は前田と同じで Pharms の開発をしてから、現在は Dentis を開発しています。他には電子処方箋の実証事業の開発などもしていたりしました。現在は Web のフロントエンド中心に開発をしています。 大岡さん 宮内 : 元同僚が働いていたので、メドレーにリファラルで入社しました。CLINICS オンライン診療の立ち上げをやった後は他の 2 人と同じで Pharms の開発をして、現在は Dentis の開発という感じです。今は主にサーバサイドの開発を中心に業務をしています。 Dentis について Dentis 誕生まで 新居 : ありがとうございました。では、Dentis についてお聞きしたいのですが、どんなきっかけで作られたサービスなんですか? 前田 : 当初は、CLINICS カルテをベースとした歯科医院向けの予約システムを開発していたのですが、歯科レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）のソースコードを 取得 するタイミングも重なり、予約システムだけではなく、レセコン一体型のシステムとして、本格的に開発をスタートしました。 詳しくは こちらの記事 を参照ください。 新居 : なるほど。そんな形で開発が始まった Dentis ですが、コロナ禍で途中で 作り直していますよね 。再開してからは 1 から開発したんですか? 前田 : はい、CLINICS をベースに開発していたものの、歯科医院へのヒアリングなどを実施、調査をしていくうちに医科と歯科では業務オペレーションが異なり予約システムとしては不十分な機能だったことが判明して。特に予約部分などはコンセプトから考え直して UI を一から作り直しました。 宮内 : 途中で Pharms を開発してリリースしたことにより、そこで使った設計や技術などを応用できたというプラスの側面もあり、再度作り直しています。 Next.js を導入したりなどですね。 大岡 : 以前の Dentis はパイロット版として提供をしていたこともあり、しっかり作り変える後押しになったかもしれないです。 新居 : そうすると開発自体も以前よりも、やりやすくもなったんですね。スムーズに開発できるようになったおかげで、 特許 も取得できる UI ができたわけですね。 Dentis のアーキテクチャについて 新居 : 現在の Dentis のアーキテクチャはどんなものになっているんでしょう。 宮内 : サーバサイドは Rails アプリケーションになっています。そこにプラスして GraphQL を使用しています。フロントエンドは Next.js と Apollo を使って GraphQL にアクセスするという形で全て AWS 上に乗っているという感じですね。 新居 : オーソドックスな構成になっているんですね。何か使いづらいなどはないですか? 大岡 : 使いづらいということはないんですが、フロントエンド側でデータをオーバフェッチしている所があるんで、そこは見直さないといけないと思っているところです。 新居 : フロントエンドの状態管理はどのようにしているんですか? 大岡 : Recoil を使っています。ですが、ライブラリの持続可能性を考えて別の方法に移行したほうがよいなとは考えているところですね…。 サブカルテ機能の開発 サブカルテ機能とは 新居 : では今回のメインの話である サブカルテ 機能について、お話を伺えればと思いますが、そもそもサブカルテとはどんなものなんでしょうか。 前田 : 歯科特有の機能になると思うのですが、カルテに記録しない患者に関する情報、たとえばレントゲンや口腔写真などのファイル管理や文書管理などをデジタル化する機能です。デジタルで管理することで、写真やファイルを保管する場所を確保する必要がなくなり、院内空間を有効活用することもできますよね。また、Dentis にあって他社にない機能としては「アクティビティ」でしょうか。院内のスタッフ間で情報共有ができる機能で、Dentis を活用いただいている歯科医院から好評をいただいている機能のひとつです。 普通は院内でスタッフの情報共有をする場合は、紙カルテなどに直接書き込みするのですが、Slack のようなタイムライン形式で情報共有できリアクションなども取れるようにしているのが「アクティビティ」機能になります。 宮内 : 歯科医院は歯科医師以外にも、歯科衛生士や歯科助手など多数の人達が連携して治療にあたるチーム医療をしているので、このような使い方をしているようです。またサブカルテの内容としては医院独自になっているようなので、Dentis のサブカルテは様々な使い方をリサーチして一般的に使いやすいであろうという形にしています。 新居 : アクティビティなどは、今の形に落ち着くまで機能を考えるのは大変そうですね。 前田 : はい、最初は Markdown を書いていけるような Wiki のような形も考えていたりしたので、タイムライン形式に落ち着くまでは試行錯誤しました。医院のコミュニケーションの仕方によって使用率も違いますが、結構使ってくださっていますね。 大岡 : 画像ファイルにメモなどを残している医院などもあるようで、ワークフローによって使いやすい方を選んでいるようです。 前田 : Dentis は医院のペーパーレス化を促進するプロダクトなので、使い方としては様々ですが紙でのワークフローの感覚でそのまま、もっと便利に使えるという部分を重視しています。 サブカルテ機能の開発背景 新居 : そんなサブカルテ機能ですが、開発しようとなった背景としてはどんなものがあったんでしょうか。 前田 : Dentis では「シームレスにつながる」というのをひとつのコンセプトとして設計しているのですが、予約〜カルテ〜会計まで機能的につなげても、業務フローとしてはどうしても隙間が生じていて、シームレスにつながってない事に気づいたんですよね。院内スタッフ間でのちょっとしたコミュニケーションもデジタルで管理できれば、その隙間を埋め、歯科医院の DX 化を推進できるのではないかと思い、サブカルテの開発を始めました。先程も言ったように、ペーパーレス化を促進という目的にも合致していましたしね。 技術的に難しかった部分 新居 : 技術的に困難なところなどはありましたか? 大岡 : 手書きメモと組写真機能(撮影した口腔内の画像を 5 枚や 10 枚で組み合わせて表示する歯科の画像表示形式)を Chrome と iPad / Mac Safari に対応させるのは難しかったかもしれません。 どれかに対応させると、どれかが上手く表示できないなどがあったので。 宮内 : 画像の表示ライブラリを途中で変更したりしましたよね。 大岡 : 最初は Konva というライブラリだったんですが、ゆっくりペンを動かすと、滑らかな線が書けないという問題が発生しまして…。 Fabric.js を使うように変更しました。 サブカルテ機能を作ったことによるプロダクトへの良い効果 新居 : ありがとうございます。サブカルテ機能は今の形になるまで、どのような検討をしたんでしょうか。 前田 : 元々ファイル管理機能などは既に Dentis であった機能だったんです。そこは活かしつつも、求められる他の機能は何かというところを考えていきながら、様々なサブカルテの活用事例もリサーチしながら、今の形に落ち着いたという感じです。 大岡 : 副産物としては今まで Dentis にはなかった「患者詳細」という画面をこのサブカルテ機能を入れるために拡張していったので、その後のオンライン資格確認などへ展開しやすいという状態になりました。情報設計を見直せたおかげです。 前田 : サブカルテ起点で患者検索もさらに詳細にできたりしたので、そうした副産物も大変良かったです。 サブカルテ機能追加による反響 新居 : 医院からはサブカルテの追加により何か反響はあったんでしょうか。 前田 : ネガティブな意見はあまりないですし、むしろ「追加機能としてこういうのが欲しい」というご意見をいただくので、結構使っていただけていると思います。 宮内 : ちょっと興味深かったのが、承認ボタンが欲しいというご意見がありました。医院のワークフローとして、医師以外の方が行なおうとする処置などを「アクティビティ」上で医師に承認してもらうというフローのようです。すぐに導入できるかというとちょっと分からないのですが。 Dentis チームにマッチするメンバー 新居 : ありがとうございます。最後にそんな Dentis チームで一緒に働いてみたいと思うような方はどんな人でしょうか。 前田 : 高齢化が進んでおり、そろそろ若い人に来てほしいですね（笑） 宮内 : どの領域の開発メンバーでも現在は少人数で運営しているので、入ってほしいなとは思います…。一番欲しいというメンバーでいうと「歯科レセコンに精通した開発者」の方ですかね。 新居 : なかなかハードルが高そうな経験ですね（笑） 本日はありがとうございました! さいごに Dentis のサブカルテ機能の開発について、開発者に聞いてみました。歯科には歯科独自のワークフローがあり、紙の運用が重視されてきた風潮の中で、業務オペレーションをふまえて開発していくユーザーファーストな開発者の発想やそれを実現する技術アプローチなど、とても面白い開発をしているなと話を聞いていて思いました。 Dentis の開発チームはベテラン揃いなので、彼らと肩を並べて働くことで、自身の成長を加速させる絶好の機会になると思います。 Dentis の開発に興味を持った方はぜひご連絡お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は今年の 3 月にリリースされた Dentis のサブカルテ機能について、開発したメンバーに話を聞いてみました! 対談メンバー紹介 Dentis 開発メンバーの紹介 新居 : よろしくお願いします。早速ですが、メドレーに入社するまでや、入ってからどんな事をしていたのかを話してもらえればと思います。 前田 : CLINICS のリリース前から、ロゴデザインや UI デザインに携わったのがきっかけでメドレーに入社しました。入社してからは、CLINICS アプリや CLINICS カルテ、薬局向けシステム Pharms などのプロダクトをこのメンバーと一緒に開発していました。今は歯科医院向けの Dentis のデザインや企画、プロモーションなどに関わっています。 前田さん 大岡 : ソーシャルゲームを 6~7 年開発していたのですが、人材プラットフォームの CTO である稲本が中学の同級生で、彼の記事を読んだのがきっかけでメドレーに入社しました。入社してからは CLINICS カルテや iOS アプリの開発などをやっていました。その後は前田と同じで Pharms の開発をしてから、現在は Dentis を開発しています。他には電子処方箋の実証事業の開発などもしていたりしました。現在は Web のフロントエンド中心に開発をしています。 大岡さん 宮内 : 元同僚が働いていたので、メドレーにリファラルで入社しました。CLINICS オンライン診療の立ち上げをやった後は他の 2 人と同じで Pharms の開発をして、現在は Dentis の開発という感じです。今は主にサーバサイドの開発を中心に業務をしています。 Dentis について Dentis 誕生まで 新居 : ありがとうございました。では、Dentis についてお聞きしたいのですが、どんなきっかけで作られたサービスなんですか? 前田 : 当初は、CLINICS カルテをベースとした歯科医院向けの予約システムを開発していたのですが、歯科レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）のソースコードを 取得 するタイミングも重なり、予約システムだけではなく、レセコン一体型のシステムとして、本格的に開発をスタートしました。 詳しくは こちらの記事 を参照ください。 新居 : なるほど。そんな形で開発が始まった Dentis ですが、コロナ禍で途中で 作り直していますよね 。再開してからは 1 から開発したんですか? 前田 : はい、CLINICS をベースに開発していたものの、歯科医院へのヒアリングなどを実施、調査をしていくうちに医科と歯科では業務オペレーションが異なり予約システムとしては不十分な機能だったことが判明して。特に予約部分などはコンセプトから考え直して UI を一から作り直しました。 宮内 : 途中で Pharms を開発してリリースしたことにより、そこで使った設計や技術などを応用できたというプラスの側面もあり、再度作り直しています。 Next.js を導入したりなどですね。 大岡 : 以前の Dentis はパイロット版として提供をしていたこともあり、しっかり作り変える後押しになったかもしれないです。 新居 : そうすると開発自体も以前よりも、やりやすくもなったんですね。スムーズに開発できるようになったおかげで、 特許 も取得できる UI ができたわけですね。 Dentis のアーキテクチャについて 新居 : 現在の Dentis のアーキテクチャはどんなものになっているんでしょう。 宮内 : サーバサイドは Rails アプリケーションになっています。そこにプラスして GraphQL を使用しています。フロントエンドは Next.js と Apollo を使って GraphQL にアクセスするという形で全て AWS 上に乗っているという感じですね。 新居 : オーソドックスな構成になっているんですね。何か使いづらいなどはないですか? 大岡 : 使いづらいということはないんですが、フロントエンド側でデータをオーバフェッチしている所があるんで、そこは見直さないといけないと思っているところです。 新居 : フロントエンドの状態管理はどのようにしているんですか? 大岡 : Recoil を使っています。ですが、ライブラリの持続可能性を考えて別の方法に移行したほうがよいなとは考えているところですね…。 サブカルテ機能の開発 サブカルテ機能とは 新居 : では今回のメインの話である サブカルテ 機能について、お話を伺えればと思いますが、そもそもサブカルテとはどんなものなんでしょうか。 前田 : 歯科特有の機能になると思うのですが、カルテに記録しない患者に関する情報、たとえばレントゲンや口腔写真などのファイル管理や文書管理などをデジタル化する機能です。デジタルで管理することで、写真やファイルを保管する場所を確保する必要がなくなり、院内空間を有効活用することもできますよね。また、Dentis にあって他社にない機能としては「アクティビティ」でしょうか。院内のスタッフ間で情報共有ができる機能で、Dentis を活用いただいている歯科医院から好評をいただいている機能のひとつです。 普通は院内でスタッフの情報共有をする場合は、紙カルテなどに直接書き込みするのですが、Slack のようなタイムライン形式で情報共有できリアクションなども取れるようにしているのが「アクティビティ」機能になります。 宮内 : 歯科医院は歯科医師以外にも、歯科衛生士や歯科助手など多数の人達が連携して治療にあたるチーム医療をしているので、このような使い方をしているようです。またサブカルテの内容としては医院独自になっているようなので、Dentis のサブカルテは様々な使い方をリサーチして一般的に使いやすいであろうという形にしています。 新居 : アクティビティなどは、今の形に落ち着くまで機能を考えるのは大変そうですね。 前田 : はい、最初は Markdown を書いていけるような Wiki のような形も考えていたりしたので、タイムライン形式に落ち着くまでは試行錯誤しました。医院のコミュニケーションの仕方によって使用率も違いますが、結構使ってくださっていますね。 大岡 : 画像ファイルにメモなどを残している医院などもあるようで、ワークフローによって使いやすい方を選んでいるようです。 前田 : Dentis は医院のペーパーレス化を促進するプロダクトなので、使い方としては様々ですが紙でのワークフローの感覚でそのまま、もっと便利に使えるという部分を重視しています。 サブカルテ機能の開発背景 新居 : そんなサブカルテ機能ですが、開発しようとなった背景としてはどんなものがあったんでしょうか。 前田 : Dentis では「シームレスにつながる」というのをひとつのコンセプトとして設計しているのですが、予約〜カルテ〜会計まで機能的につなげても、業務フローとしてはどうしても隙間が生じていて、シームレスにつながってない事に気づいたんですよね。院内スタッフ間でのちょっとしたコミュニケーションもデジタルで管理できれば、その隙間を埋め、歯科医院の DX 化を推進できるのではないかと思い、サブカルテの開発を始めました。先程も言ったように、ペーパーレス化を促進という目的にも合致していましたしね。 技術的に難しかった部分 新居 : 技術的に困難なところなどはありましたか? 大岡 : 手書きメモと組写真機能(撮影した口腔内の画像を 5 枚や 10 枚で組み合わせて表示する歯科の画像表示形式)を Chrome と iPad / Mac Safari に対応させるのは難しかったかもしれません。 どれかに対応させると、どれかが上手く表示できないなどがあったので。 宮内 : 画像の表示ライブラリを途中で変更したりしましたよね。 大岡 : 最初は Konva というライブラリだったんですが、ゆっくりペンを動かすと、滑らかな線が書けないという問題が発生しまして…。 Fabric.js を使うように変更しました。 サブカルテ機能を作ったことによるプロダクトへの良い効果 新居 : ありがとうございます。サブカルテ機能は今の形になるまで、どのような検討をしたんでしょうか。 前田 : 元々ファイル管理機能などは既に Dentis であった機能だったんです。そこは活かしつつも、求められる他の機能は何かというところを考えていきながら、様々なサブカルテの活用事例もリサーチしながら、今の形に落ち着いたという感じです。 大岡 : 副産物としては今まで Dentis にはなかった「患者詳細」という画面をこのサブカルテ機能を入れるために拡張していったので、その後のオンライン資格確認などへ展開しやすいという状態になりました。情報設計を見直せたおかげです。 前田 : サブカルテ起点で患者検索もさらに詳細にできたりしたので、そうした副産物も大変良かったです。 サブカルテ機能追加による反響 新居 : 医院からはサブカルテの追加により何か反響はあったんでしょうか。 前田 : ネガティブな意見はあまりないですし、むしろ「追加機能としてこういうのが欲しい」というご意見をいただくので、結構使っていただけていると思います。 宮内 : ちょっと興味深かったのが、承認ボタンが欲しいというご意見がありました。医院のワークフローとして、医師以外の方が行なおうとする処置などを「アクティビティ」上で医師に承認してもらうというフローのようです。すぐに導入できるかというとちょっと分からないのですが。 Dentis チームにマッチするメンバー 新居 : ありがとうございます。最後にそんな Dentis チームで一緒に働いてみたいと思うような方はどんな人でしょうか。 前田 : 高齢化が進んでおり、そろそろ若い人に来てほしいですね（笑） 宮内 : どの領域の開発メンバーでも現在は少人数で運営しているので、入ってほしいなとは思います…。一番欲しいというメンバーでいうと「歯科レセコンに精通した開発者」の方ですかね。 新居 : なかなかハードルが高そうな経験ですね（笑） 本日はありがとうございました! さいごに Dentis のサブカルテ機能の開発について、開発者に聞いてみました。歯科には歯科独自のワークフローがあり、紙の運用が重視されてきた風潮の中で、業務オペレーションをふまえて開発していくユーザーファーストな開発者の発想やそれを実現する技術アプローチなど、とても面白い開発をしているなと話を聞いていて思いました。 Dentis の開発チームはベテラン揃いなので、彼らと肩を並べて働くことで、自身の成長を加速させる絶好の機会になると思います。 Dentis の開発に興味を持った方はぜひご連絡お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp