Overview
プロジェクト概要
再生医療・細胞培養の研究ラボ向けに、実験管理から凍結在庫の管理までを一通りそろえた、マルチテナント型のWeb SaaSを開発しました。実験管理、機器との連携、データの可視化、凍結在庫の管理、監査ログまでを1つにまとめ、顧客ごとに専用のデータベースを持つ構成で設計しています。
開発期間は2022年8月から2023年7月までの約11か月、体制はPM・デザイナー・フロントエンドエンジニア・バックエンド／インフラエンジニアの4名です。規模は約90画面、約110データモデルです。当社は、バックエンドとインフラを一貫して担当しました。この規模のシステムが破綻しないようデータモデルとバックエンドを設計し、マルチテナントの基盤からAWSでの運用まで、裏側の全体を受け持っています。
※ お客様との守秘義務のため、お客様名・製品名は記載していません。掲載している画面とデータは、説明用に再構成したイメージです。
- 分類
- マルチテナント型のWeb SaaSの開発（大規模な業務システム）
- 開発期間
- 2022年8月〜2023年7月（約11か月）
- 体制
- 4名（PM / デザイナー / フロントエンドエンジニア / バックエンド・インフラエンジニア）
- 規模
- 約90画面 / 約110データモデル
- 利用者
- 再生医療・細胞培養の研究ラボ
- 業種
- 医療・ライフサイエンス
- ロール
- バックエンドの設計・実装 / マルチテナント構成 / ラボ機器データの取り込みと可視化 / 凍結在庫管理 / 監査ログ / 認証・権限 / 多言語対応 / レポート出力 / AWS環境の構築・CI/CD・運用改善
- 技術
- Python / Django / MySQL（Amazon RDS） / AWS EC2 / S3 / CodeBuild / CodeDeploy / SES / Step Functions / API Gateway / python-docx
01 — 導入前の課題
実験はつながっている。でも、記録はつながっていなかった
研究の現場では、記録が別々の場所に散らばりがちです。実験条件は紙のノート、培養の履歴はExcel、機器から出てくる画像や解析結果は個別のフォルダ、凍結保存した検体は別の在庫表、という状態です。「この検体は、どの実験から来たのか」を調べるには、紙 → Excel → フォルダ → 在庫表を順番に確認する必要がありました。そのため、研究の再現性や検体の来歴（トレーサビリティ）を後から追いにくく、監査への対応もしにくいという課題がありました。
- 実験条件は紙のノートに記録
- 培養の履歴はExcelで管理
- 画像・測定結果は個別のフォルダに保存
- 凍結した検体は別の在庫表で管理
02 — 凍結在庫の管理
凍結した検体を、場所も状態も追える
凍結在庫は、保管庫 → ボックス → ロット → バイアルの階層でデータにしました。入庫・出庫は「チケット」という単位で先に登録します。実際に作業するときに、バイアルのQRコードを読み取り、システムに登録されている位置と一致することを確かめてから、状態を確定します。画像の例では、出庫チケットに対して保管庫・ボックス・ロット・バイアルが表示され、QRコードの照合が済んだあとに出庫が確定する流れになっています。入庫・出庫・保管場所の変更は、すべて履歴に残ります。
- 保管庫からバイアルまでを階層で管理
- 入庫・出庫を「チケット」で先に登録
- 作業時にQRコードを読み取り、位置を照合
- 入出庫と保管場所の変更の履歴を記録
開発中の課題と解決
凍結在庫の入出庫の流れと、状態の整合性を保つ
- 課題
- 凍結在庫は、入庫・出庫のたびに「未入庫 → 凍結中 → 出庫済み」という状態が正しく移る必要があります。さらに、QRコードで実際に読み取った位置と、システムに記録されている位置が食い違わないようにする必要がありました。
- 解決
- 入庫・出庫を「チケット」という単位でいったん登録し、実際に作業を行うときにQRコードで位置を照合してから状態を確定させる、2段階の設計にしました。操作ミスによるデータの不整合を防ぎつつ、予約してから実際に作業するという現場の実態にも合わせることができました。
03 — 来歴と監査ログ
誰が、いつ、何を変えたかまで追える
検体ごとに、培養ロットの作成、測定データの登録、凍結処理、保管場所の変更、出庫までを時系列で確認できます。それぞれの操作には担当者と日時が記録され、保管場所の変更のような操作では、変更前と変更後の状態が両方残ります。監査ログは専用のアプリとして作り、CSVで出力できます。あわせて、管理者・担当者・閲覧者などの役割で操作できる範囲を分け、ログインの失敗が続いた場合はアカウントを一時的にロックします。
- 作成から測定・凍結・保管・出庫までを時系列で表示
- 操作ごとに担当者と日時を記録
- 変更前後の状態を丸ごと記録
- 役割による権限管理と、監査ログのCSV出力
開発中の課題と解決
監査ログの記録漏れを防ぎながら、業務の処理の柔軟さを保つ
- 課題
- 監査ログは、すべての操作を自動で記録する方式ではなく、登録・編集・削除・位置の変更・状態の変更といった重要な操作のたびに、その処理のコードから履歴を記録する設計にしました。どの操作をどの細かさで記録するかを柔軟に決められる反面、呼び出しを1つ漏らすと、その操作だけ履歴に残りません。
- 解決
- 凍結在庫、設定の変更、チケットまわりなど、監査の面で重要な操作について、対象ごとに変更前後の状態を丸ごと記録する履歴のテーブルを用意しました。そのうえで、業務の処理の実装と履歴の記録を必ず一緒に実装する進め方を徹底しています。
04 — 1つのSaaSに統合
研究業務を、ひとつのSaaSで支える
実験・培養の管理、機器データの管理、凍結在庫の管理、監査ログと権限の管理、レポート出力を、1つのシステムにまとめました。測定装置が出力するCSVや画像は、共有ストレージ経由で取り込み、細胞数、コンフルエンシー、成長の傾向として整理・可視化します。レポートは、用意したテンプレートに表や画像を差し込んでWordで自動生成でき、CSV・ZIPでのデータ出力にも対応しています。日本語と英語の2言語で使えます。複数のラボが利用するSaaSとして、顧客ごとに専用のデータベースを持たせ、データを構成のレベルで分けました。
- 実験条件と培養履歴を一元管理
- 測定装置のCSV・画像を取り込み、可視化
- Word・CSV・ZIPでのレポート出力
- 顧客ごとの専用データベースと、日本語・英語対応
開発中の課題と解決
顧客ごとの専用データベースへの振り分けを、安全に、一貫して運用する
- 課題
- ログイン時に対象のデータベースを判定し、その後はアプリケーション側のコードで明示的にそのデータベースを指定して問い合わせる設計にしました。単純で動きを追いやすい一方、指定を忘れると、別の顧客のデータを参照・更新してしまう危険があります。
- 解決
- データベースへのアクセスを、できるだけ共通の関数経由に寄せました。レビューでも「対象のデータベースが正しく指定されているか」を必ず確認するようにして、一貫性を保っています。
Scope
担当範囲
要件の整理はPMが、画面の設計とUIデザインはデザイナーが、画面の実装はフロントエンドエンジニアが担当しました。当社は、バックエンドとインフラを一貫して担当しています。
| 工程 | 担当 |
|---|---|
| 要件の整理、進行管理 | PM |
| 画面の設計、UIデザイン | デザイナー |
| フロントエンドの実装 | フロントエンドエンジニア |
| バックエンドの設計・実装（データモデル、業務ロジック） | 当社 |
| マルチテナント構成の設計・実装 | 当社 |
| ラボ機器のデータ（CSV・画像）の取り込みと可視化 | 当社 |
| 凍結在庫管理のデータモデルと業務ロジック | 当社 |
| 監査ログ | 当社 |
| 認証・権限、多言語対応（日本語・英語） | 当社 |
| レポート出力（Word、CSV、ZIP） | 当社 |
| AWS環境の構築、CI/CD、運用改善 | 当社 |
フロントエンドエンジニアとは、APIの仕様やデータの持たせ方をすり合わせながら進めました。
Architecture
使用技術・システム構成
- バックエンド
- Python / Django。業務全般を扱うアプリ、ラボ機器のデータの取り込み用アプリ2本、監査ログ専用アプリの、計4本のDjangoアプリで構成
- データベース
- Amazon RDS 上の MySQL。顧客管理用の共通データベースと、顧客ごとの専用データベース
- マルチテナント
- ログイン時に顧客のデータベースを判定し、その後のすべての問い合わせで、対象のデータベースをアプリケーション側から明示的に指定する独自の実装
- インフラ
- AWS EC2 / Apache。CodeBuildでビルドし、CodeDeployで配置。開発・レビュー・本番の3環境
- ストレージ
- S3をEC2側にファイルシステムとして接続し、静的ファイルと、ラボ機器からの画像・CSVを保存
- その他のAWSサービス
- SES（メール送信） / Step Functions（ストレージ使用量の再計算） / API Gateway・IAM（外部と同期するAPIの保護）
- レポート出力
- python-docxによるWordレポートの自動生成 / CSV・ZIPでのデータ出力
- 多言語対応
- Django標準の国際化の仕組みで、日本語・英語に対応
- 運用のための機能
- 顧客ごとの機能のON/OFFやプランの上限の管理 / 論理削除とゴミ箱・復元 / 画面ごとの検索条件・列の表示の保存
主な技術の選定理由
顧客ごとに専用のデータベース
研究データという機微性の高い情報を扱うため、顧客間のデータを構成のレベルで完全に分けました。
対象のデータベースを、アプリケーション側で明示的に指定
仕組みが単純で、動きを追いやすいためです。一方で指定漏れの危険があるため、共通の関数への集約とレビューで一貫性を保ちました。
入庫・出庫を「チケット」で2段階に
先に登録し、実際の作業のときにQRコードで位置を照合してから状態を確定します。操作ミスによる不整合を防ぎ、現場の作業の実態にも合います。
監査ログを、業務の処理から明示的に記録
どの操作を、どの細かさで記録するかを、業務の処理の中で個別に決められるためです。
Process
開発の進め方
- 1
PMが要件の整理と進行管理を、デザイナーが画面の設計とUIを、フロントエンドエンジニアが画面の実装を担当し、当社がバックエンド、AWSインフラ、CI/CD、運用を担当しました。
- 2
mainブランチを常に動く状態に保ち、機能ごとのブランチで作業し、プルリクエストを出してレビューを経てから統合しました。
- 3
CodeBuildとCodeDeployで、開発・レビュー・本番の3環境に分けて配置する構成にしました。
- 4
テストはDjango標準のテストクライアントを使い、ログインや基本的な登録・更新・削除など、中核となる画面を中心に用意しました。
Quality & Security
品質・セキュリティ・運用
顧客間のデータの分離
顧客ごとに専用のデータベースを持たせ、構成のレベルでデータを分けました。データベースへのアクセスは共通の関数に寄せ、レビューで対象の指定を必ず確認しています。
認証・権限
ログインに一定の回数失敗すると、アカウントを一時的にロックします。管理者・担当者・閲覧者などの役割で、操作の範囲を分けます。
監査ログ
専用のアプリで操作の履歴を記録し、対象ごとに変更前後の状態を残します。CSVで出力できます。
来歴の追跡
凍結在庫は階層とチケットで管理し、QRコードでの位置の照合を経て状態を確定します。
誤操作への備え
論理削除と、ゴミ箱・復元の機能を用意しました。
配置と運用
CodeBuildとCodeDeployのパイプラインで、開発・レビュー・本番の3環境に分けて運用し、改善を続けました。
Results
成果
紙、Excel、個別のフォルダに散らばっていた研究の現場のデータを1つのシステムにまとめ、研究の再現性と検体の来歴を追える基盤として構築しました。
- 実験管理、ラボ機器からのデータの取り込みと可視化、凍結在庫の管理、監査ログ、レポート出力を、1つのシステムに統合しました。
- 顧客ごとに専用のデータベースを持つマルチテナント構成を、AWS上で、開発・レビュー・本番の3環境で運用できる形にしました。
- 保管庫からバイアルまでの階層と、チケットによる入出庫の管理で、凍結した検体の所在と状態を追えるようにしました。
- 規模：約90画面、約110データモデル、URLの経路は200近く、Pythonのコード量は約3万4千行、Djangoアプリ4本。
FAQ
技術面のよくあるご質問
- Q. 顧客ごとのデータはどう分けていますか？
- 顧客ごとに専用のMySQLデータベースを持たせています。ログイン時に顧客管理のテーブルで対象のデータベースを判定し、その後の問い合わせでは、アプリケーション側のコードでそのデータベースを明示的に指定します。
- Q. その方式の弱点には、どう備えましたか？
- 指定を忘れると、別の顧客のデータに触れてしまう危険があります。データベースへのアクセスを共通の関数に寄せ、レビューでも対象の指定を必ず確認する運用で抑えました。
- Q. ラボ機器とはどう連携していますか？
- 測定装置が出力するCSVや画像を、共有ストレージ経由で取り込み、細胞数、コンフルエンシー、成長の傾向として整理・可視化しています。倍加時間などは、装置側や利用者が算出した値を画面から入力する運用です。画像の認識・解析のアルゴリズム自体は、このシステムの範囲には含まれていません。
- Q. 凍結した検体の来歴はどう追えますか？
- 保管庫・ボックス・ロット・バイアルの階層をデータモデルにし、入庫・出庫を「チケット」で管理しています。QRコードで位置を照合してから状態を確定する2段階の設計で、操作ミスによる不整合を防いでいます。
- Q. 監査ログには何が残りますか？
- 登録・編集・削除・位置の変更・状態の変更といった重要な操作について、操作の記録と、対象ごとの変更前後の状態が残ります。CSVで出力できます。
- Q. フロントエンドとはどう連携しましたか？
- PMが整理した要件をもとに、フロントエンドエンジニアとAPIの仕様、応答の形、画面に必要なデータの持たせ方をすり合わせながら進めました。
Tech Stack