はじめに リアルタイム性の高いマルチプレイヤーゲームは、複数のプレイヤーの入力を集約し、ゲームの状態を一貫させて全員へ配信する仕組みを必要とします。この仕組みの一つに、権威あるサーバーがゲームの状態を管理する専用ゲームサーバー (Dedicated Game Server) 方式があります。対戦の公平性やチート対策、多人数の同時接続が求められるタイトルでは、専用ゲームサーバー方式が広く採られています。この方式では、マッチメイキング、ゲームサーバーの割り当て、セッション終了後のサーバー回収といったライフサイクル管理が必要になり、そのオーケストレーション基盤をどう構築・運用するかが設計上の大きなテーマとなります。 AWS で専用ゲームサーバーをホストする主な選択肢は、マネージドサービスの Amazon GameLift Servers を利用するか、 Amazon Elastic Compute Cloud (EC2) や Amazon Elastic Container Service (ECS) 、 Amazon Elastic Kubernetes Service (EKS) 上でセルフホストするかの 2 つです。GameLift Servers はインフラ構築・運用の大部分を担いますが、要件によってはより柔軟な制御が必要な場合があり、 Agones の利用が選択肢の一つとなります。Agones はオープンソースの専用ゲームサーバーホスティング向け製品で、Amazon EKS 上にデプロイでき、柔軟性を享受しつつ専用ゲームサーバーの構成を簡素化できます。しかし Kubernetes 基盤の運用は避けられず、Agones の運用には一定の負荷が存在しました。 2024 年 12 月に一般提供が始まった Amazon EKS Auto Mode は、Kubernetes の構築・運用負担を低減する機能です。Agones の基盤となる EKS クラスタで EKS Auto Mode を利用できれば、専用ゲームサーバーを柔軟かつ簡素に構築・運用できます。ただし EKS Auto Mode にはいくつかの制約もあります。 本記事では、EKS Auto Mode の制約が Agones の特性を阻害しないようにするための設計方針を紹介します。 Agones リソースの概要 本記事の内容に関連する Agones カスタムリソースについて説明します。 GameServer： プレイヤーが接続するゲームサーバープログラムが動作する Pod にあたるリソースです。状態を持ち、Ready 状態はゲーム開始可能で待機している状態、Allocated 状態はゲームプレイのためにリソースが確保された状態を表します。 Fleet： GameServer のまとまりを管理するためのリソースです。常に起動しておくべき GameServer リソースの数を指定でき、Fleet Autoscaler リソースによるスケーリング制御も可能です。 GameServer Allocation： ゲームプレイのために GameServer リソースを選択し確保する操作を行うリソースです。この操作により選択された GameServer リソースは Ready 状態から Allocated 状態となります。 コントローラ系リソース： Agones の機能を実現・制御するためのリソース群です。 EKS Auto Mode と Agones の共存における課題 EKS Auto Mode は、クラスタのノード管理を AWS の責任範囲で自動化します。例えば Karpenter をベースとしたノードのプロビジョニング・スケーリング・入れ替え、Bottlerocket による最適化された OS、各種アドオンのマネージド管理といった機能により、Kubernetes の運用を大幅に簡素化できます。 一方、ユーザー側で設定できる範囲が狭まるというトレードオフがあります。Agones の基盤として特に考慮が必要なのは、EKS Auto Mode が以下の目的のために自動で行うノードの中断です。 Consolidation： 稼働中の Pod が少ないノードを終了し、利用率の高いノードへ Pod を集約してコストを最適化する。 Drift： NodePool や NodeClass の設定変更、AMI の更新などに追従してノードを入れ替える。 Expiration： セキュリティ維持のため、一定期間が経過したノードを強制的に入れ替える。 Interruption： Spot Instance の中断通知やハードウェア障害などに応じてノードを終了する。 ※EKS Auto Mode の長期実行ワークロードでの扱いについては、builders.flash 記事「 Amazon EKS Auto Mode のノード自動更新を Deep Dive する 」もあわせて参照ください。 いずれの中断でも、対象ノード上の Pod へ SIGTERM が発行されます。Agones上で動かすような専用ゲームサーバーには「プレイ中のゲームセッションを中断させない」という強い制約があるため、対策をしないとプレイ中のゲームサーバーが強制終了されるリスクがあります。 EKS Auto Mode と Agones を共存させる設定のポイント そこで、Agones のコントローラ系とゲームプレイ中のサーバープログラムをノードの中断から保護する仕組みを、次の 6 つのポイントで構成します。以降、それぞれのポイントについて、実際の設定ファイル ( nodepools.yaml / fleet.yaml / agones-values.yaml ) を引用しながら、具体的な実装方法を説明します。 Point # 対象 内容 Point 1 共通 NodePool の expireAfter 、 terminationGracePeriod を適切に設定する Point 2 GameServer GameServer の Pod の terminationGracePeriodSeconds をゲームの最大持続時間より長い値に設定する Point 3 GameServer GameServer 上で動くサーバーアプリで、適切なシグナルハンドリングを実装する Point 4 GameServer Eviction を許可してノードの自動最適化を機能させる ( spec.eviction.safe: Always ) Point 5 コントローラ系 Agones コントローラ系と GameServer が配置される NodePool を分ける Point 6 コントローラ系 agones-allocator と agones-ping の PDB を有効にする Point 1 (共通) ：NodePool の expireAfter / terminationGracePeriod を適切に設定する EKS Auto Mode では、ノードは必ずいつか中断されます。特に Expiration はノード生存期間最大21日の制約があり、必ず発生します。この expireAfter の値と、ノードが強制的に中断されるまでの猶予期間である terminationGracePeriod を、ワークロード特性に合わせて NodePool に設定することが起点になります。 NodePool とは、Karpenter ベースのノード管理機能で、Pod の要求に応じてインスタンスを自動的にプロビジョニング・スケーリングし、クラスターのコンピュートリソースを柔軟に管理するための仕組みです。 設定にあたっては、次の関係を守るようにしてください。 terminationGracePeriod は、後述する Pod の terminationGracePeriodSeconds より長く設定する (ノードが強制削除される前に、Pod が Graceful に終了しきるようにするため) 。 expireAfter + terminationGracePeriod の合計は最大 21 日に収める (EKS Auto Mode の制約) 。 また disruption.budgets の nodes: "10%" （NodePool Disruption Budgets: NDB）により、同時に中断処理へ入るノード数を全体の 10 % に制限し、一斉中断の影響を抑えます。 consolidationPolicy: WhenEmpty については Point 4 で触れます。 Point 1 を踏まえた NodePool の設定例は次の通りです（ nodepools.yaml ）。 # GameServer 用 NodePool apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: agones-worker spec: template: spec: # Point 1: ゲームセッション時間を考慮して設定 # terminationGracePeriod は Pod の terminationGracePeriodSeconds より長くすること expireAfter: 336h # 14日 terminationGracePeriod: 4h # expireAfter + terminationGracePeriod が21日(504h)に収まるように disruption: consolidationPolicy: WhenEmpty consolidateAfter: 30s budgets: - nodes: "10%" Point 2（GameServer）：Pod の terminationGracePeriodSeconds をゲーム最大持続時間より長く設定する ノードが中断され Pod に SIGTERM が発行されてから、Pod が強制終了（SIGKILL）されるまでの猶予が terminationGracePeriodSeconds です。この値をゲームの最大持続時間より長く設定することで、進行中のゲームが途中で強制終了されることを防ぎます。 terminationGracePeriodSeconds は Pod リソースの設定値ですが、Agones では GameServer リソース定義内で設定することになります。また GameServer の制御は Fleet で行うことが一般的なため、ここでは Fleet の設定例を次の通り示します ( fleet.yaml ) apiVersion: "agones.dev/v1" kind: Fleet metadata: name: simple-game-server-fleet spec: replicas: 3 template: spec: # ... (省略) template: spec: # Point 2: ゲームセッション最大持続時間 + バッファより長い値を設定 # 例: ゲーム最大30min + クリーンアップ5min = 35min = 2100sec terminationGracePeriodSeconds: 2100 ゲームセッション 1 つの最大持続時間に、クリーンアップ処理のバッファを加えた値を設定します。Point 1 の terminationGracePeriod (ノード側の猶予) を、この terminationGracePeriodSeconds (Pod 側の猶予) より長く設定することで、 terminationGracePeriod > terminationGracePeriodSeconds > ゲーム最大持続時間 の関係が成立し、プレイ中のゲームを保護できます。 まとめると、 以下を満たすように各パラメータを設定すればよいことになります。 NodePool の terminationGracePeriod > Pod の terminationGracePeriodSeconds > ゲームの最大持続時間 NodePool の expireAfter は自由 ( terminationGracePeriod との合計は 21 日以下) Point 3 (GameServer) ：適切なシグナルハンドリングを実装する Point 1・2 で猶予期間を確保しても、SIGTERM を受け取ったサーバープログラムが適切に振る舞わなければ、ゲームサーバーは安全に終了できません。GameServer 上で動くサーバープログラムでは、SIGTERM を受信したときに次の動作を実装します。 Allocated 状態 (ゲーム進行中) ：進行中のゲームの終了を待ち、クリーンアップ処理を行った後に Agones SDK の sdk.Shutdown() を呼び出す。 Ready 状態 (待機中) ：新規 Allocation を防ぐため、即時 sdk.Shutdown() を呼び出す。 この実装により、ノード中断のシグナルを受けても、進行中のゲームを守りつつ、待機中のサーバーは速やかに退去できます。 Point 4 (GameServer) ：Eviction を許可してノードの自動最適化を機能させる ( spec.eviction.safe: Always ) Point 1〜3 でプレイ中のゲームを保護できたら、次に Agones の spec.eviction.safe を Always に設定し、EKS Auto Mode によるノードの自動最適化を機能させます ( fleet.yaml ) 。 spec: template: spec: # Point 4: eviction.safe を Always に設定 # Karpenter の Drift/Consolidation/Expiration 時に Graceful な Eviction を許可する eviction: safe: Always spec.eviction.safe は、各 GameServer の Pod に対して Agones が内部的に作成する PDB ( maxUnavailable: 0% ) を有効化するかどうかを制御します。デフォルトの Never の場合、常に eviction をブロックする動きとなります。 (表は https://agones.dev/site/docs/advanced/controlling-disruption/ より) Never のままでは、この PDB がすべての Eviction をブロックし、EKS Auto Mode 環境で次の問題が発生します。 Karpenter が Consolidation / Drift を試みても Pod に SIGTERM が発行されず退去しないため、Cordon 状態のノードが既存 Pod ごと残り続け、コスト効率が悪化する。 Drift (AMI 更新) が PDB にブロックされ、セキュリティパッチの適用が遅延する。 上記の動作の結果、近い時間帯に起動した全ノード上の Pod が Expiration まで生存し続け、それらの Pod が近い時間帯に一斉に SIGKILL されるリスクが生じる。 Always を設定すると Agones のネイティブ PDB が無効化され、Eviction が許可されます。Pod が稼働中のノードでも Drift による AMI 自動更新と、Expiration 時の Graceful なノード入れ替えが機能するようになります (Never ではこれらが PDB にブロックされます) 。プレイ中のゲームの保護は Point 1〜3 で確保した猶予期間とシグナルハンドリングが担保するため、Always にしても進行中のゲームが即座に切断されることはありません。 Always の設定でも安全に運用する目的で、Point 1 で設定した consolidationPolicy: WhenEmpty (Pod が残っているノードでは Consolidation を発動させない) と NDB ( nodes: "10%" 、同時中断ノード数の制限) を補完策として組み合わせます。Always は Drift / Expiration を有効に機能させる一方、Consolidation まで WhenEmptyOrUnderutilized にすると稼働中 Pod のあるノードも集約対象となりゲームサーバーが頻繁に Evict され得るため、Consolidation は WhenEmpty に絞り、空ノードの回収のみに留めます。Agones の Fleet 設定 spec.scheduling の値はデフォルトで Packed となっており、できるだけ既に GameServer が動作しているノードに新規 GameServer を起動するようにスケジュールするため、 WhenEmpty の設定でも十分なコスト最適化効果が見込めます。 Point 5 (コントローラ系) ：Agones コントローラ系と GameServer の NodePool を分ける Point 1 で設定した expireAfter / terminationGracePeriod は NodePool 単位の設定です。Agones のコントローラ系 (controller / extensions / allocator / ping) と GameServer では、必要な猶予期間が異なります。 コントローラ系： 短時間の再起動が許容されるため、長期安定稼働を優先しつつ猶予は比較的短くてよい。 GameServer： ゲーム最大持続時間に対応した長い猶予 ( terminationGracePeriod ) が必要。 そこで、コントローラ系用と GameServer 用で NodePool を分離します ( nodepools.yaml ) 。 # コントローラ用 NodePool apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: agones-controller spec: template: metadata: labels: agones-role: controller # ラベルで役割を区別 spec: # コントローラは長期安定稼働を優先 expireAfter: 336h # 14日 terminationGracePeriod: 72h # 3日 --- # GameServer 用 NodePool (Point 1 で前掲) # labels: agones-role: gameserver / terminationGracePeriod: 4h そのうえで、GameServer 側は Fleet の nodeSelector で GameServer 用 NodePool を指定します ( fleet.yaml ) 。 template: spec: # Point 5: GameServer 用 NodePool にスケジュール nodeSelector: agones-role: gameserver コントローラ系は、Agones の Helm Values で nodeSelector を指定し、コントローラ用 NodePool に配置します ( agones-values.yaml ) 。 agones: controller: # Point 5: コントローラ用 NodePool にスケジュール nodeSelector: agones-role: controller extensions: nodeSelector: agones-role: controller allocator: nodeSelector: agones-role: controller ping: nodeSelector: agones-role: controller これにより、それぞれのワークロード特性に合った猶予期間を両立できます。 Point 6 (コントローラ系) ：agones-allocator と agones-ping の PDB を有効にする 前述の通り EKS Auto Mode ではいつか必ずノードの中断が発生するため、Agones のコントローラ系サービスでも可用性維持のための設定が重要です。agones-allocator (ゲームサーバーの割り当てリクエストを受け付けるサービス) と agones-ping (レイテンシー計測用サービス) はデフォルトで PDB が無効のため、ノードが中断されてもこれらが全停止しないよう、PDB を有効化します ( agones-values.yaml ) 。 agones: allocator: replicas: 3 # Point 6: allocator の PDB を有効化 pdb: enabled: true minAvailable: 1 ping: replicas: 2 # Point 6: ping の PDB を有効化 pdb: enabled: true minAvailable: 1 minAvailable: 1 により、ノード中断時にも最低 1 レプリカが稼働し続けることを保証し、コントロールプレーンの可用性を維持します。 なお、agones-controller, agones-extensions はデフォルトで PDB が有効となっています。 さらに安定した運用のための補足 (レアケースへの対処) Point 1〜6 の設計により、通常のノード中断からのゲームサーバー保護を実現できます。さらに安定した運用のためには、次のレアケースへの対処も検討ポイントになります。いずれも各実装に依存するため、必要に応じて検討してください。 GameServerAllocation のレースコンディション Ready 状態の GameServer が SIGTERM を受信した直後から Shutdown 完了までの間に、GameServerAllocation によって Allocate される可能性がゼロではありません。これが起こると、プレイヤーが接続するころには Allocate された GameServer が既に停止しておりエラーとなるリスクがあります。以下はこれを防ぐ方法の例です。 GameServer にあらかじめラベル ( allocationblock=false 等) を付与し、GameServerAllocation 側でそのラベルを持つ Pod のみを対象とする設定を行う。SIGTERM 受信時には即座にラベルを外す。ラベル削除後も一定時間待機し、その間に Allocate された場合はゲームを継続し、終了後に Shutdown する。 起動中 Pod への SIGTERM 発行時のハンドリング不可 コンテナ起動中 (Starting / ContainerCreating) に SIGTERM が発行されると、アプリケーション側でハンドリングできず、GameServer は正常に起動し Ready 状態となる一方、 Pod は terminationGracePeriodSeconds 経過後に停止してしまう動作となり、ゲームを保護できません。これを防ぐには以下の方法が例として挙げられます。 対策例 1： GameServer にあらかじめラベル (allocationblock=false 等) を付与し、GameServerAllocation 側でそのラベルを持つ Pod のみを対象とする設定を行う。外部コントローラで Pod の deletionTimestamp を監視し、非 null、つまり削除予定がある状態なら、前述の Allocation 用ラベルを外し、新規 Allocation を防ぐ。 対策例 2： イメージサイズの削減・DaemonSet 等による事前 pullといった方法で起動時間短縮を図り、発生確率を最小化する。 まとめ 本記事では、Agones の基盤に EKS Auto Mode を採用する際、ノードの自動中断からゲームサーバーを保護する設計を 6 つのポイントで紹介しました。専用ゲームサーバーのセルフホストで、Agones の柔軟性を活かしつつ EKS Auto Mode で運用管理をシンプルにするには、EKS Auto Mode のノード中断と Agones のゲームサーバーライフサイクルの競合を解消する設計が鍵になります。 本記事で紹介した Point 1〜6 の設計パターンと実装例 ( nodepools.yaml / fleet.yaml / agones-values.yaml ) が、EKS Auto Mode 上での Agones 導入を検討する方の参考になれば幸いです。

本記事は 2025 年 7 月 18 日に公開された Edwin Sandanaraj、Charlie Lee、Billy Rowell、Khi Pin Chua、Rajesh Sukumaran による “ Benchmarking PacBio whole genome sequencing variant pipeline analysis with AWS HealthOmics workflows ” を翻訳したものです。 ゲノム研究が医療とポピュレーションヘルス (集団全体の健康) の最前線を切り拓き続ける中で、複雑なゲノム領域の解読、構造バリアントの同定、そして遺伝的多様性の大規模な理解には、ロングリードシーケンシングがますます不可欠になっています。 PacBio HiFi シーケンシングは、高精度かつ長いリードを生成するため、包括的な全ゲノムシーケンシング (WGS) に適しています。 大規模なロングリード WGS 解析を実行するには、スケーラブルでセキュア、かつ本番運用に耐える計算環境が必要です。 AWS HealthOmics はまさにこの用途に特化して構築されており、バイオインフォマティシャンはコンテナ化されたワークフローの実行と大量のゲノムデータの処理を、高い信頼性と柔軟性をもって行えます。 PacBio と AWS HealthOmics ワークフローの統合 アーキテクチャは、大規模ゲノミクスプログラムの中核として機能してきました。この実装により、セキュアかつ効率的なデータ処理を実現しながら、大規模な解析結果の提供を効率化できます。HealthOmics の堅牢なセキュリティとスケーラブルなインフラストラクチャを活用することで、PacBio ワークフローは大規模なロングリードシーケンシングデータを処理しつつ、国家的なヘルスケア施策に求められるデータガバナンス基準を維持できます。こうした実際の運用実績は、HealthOmics が PacBio の全国的な精密医療プログラムをエンタープライズ級の信頼性とパフォーマンスで支えられることを示しています。 本ガイドでは、PacBio の WGS バリアントパイプライン を AWS HealthOmics 上で実装する方法を紹介し、広範なベンチマークに基づく大規模かつコスト効率の高いデプロイに向けたパフォーマンス最適化の知見とエビデンスに基づく推奨事項をお伝えします。 PacBio HiFi シーケンシングは、典型的には 15〜25 キロ塩基のロングリードを、高い塩基精度 (塩基の 90 パーセントが Q30 を上回る) で生成します。この組み合わせにより、研究者は反復領域や GC (Guanine-Cytosine) リッチな領域を網羅し、ハプロタイプを正確にフェージング (決定) し、ショートリード技術では見落とされがちな構造バリアントを検出できます。ロングリードシーケンシング解析の代表的な用途は次のとおりです。 一塩基バリアント (SNV) および小規模な挿入・欠失 (indel) – 塩基レベルの変化や複数塩基にわたる小さな変異 構造バリアントの発見 – 大規模な挿入、欠失、再構成を塩基レベルの精度で解読 ハプロタイプのフェージング – 長いハプロタイプブロックにわたって、バリアントを母方または父方のアレルに割り当て 複雑な遺伝子座のアセンブリ – 疾患関連遺伝子座における反復配列や遺伝子重複を解き明かす De novo アセンブリ とパンゲノム構築 – 集団特有の多様性を反映した、高品質で連続性の高いゲノムアセンブリの生成 DNA メチル化 – ゲノム全体の CpG サイトにおける 5-メチルシトシン (5mCpG) マークから、活性領域や不活性領域を同定 PacBio HiFi WGS バリアントパイプラインの技術概要 PacBio の WGS バリアントパイプラインは Workflow Description Language (WDL) で定義されており、二次解析と三次解析に向けたモジュール式かつコンテナ化されたソリューションを提供します。このパイプラインには、HiFi アライメントツールに加え、SNV、小規模な挿入・欠失、コピー数バリアント (CNV)、構造バリアント (SV) 向けに設計されたバリアントコーラーが組み込まれています。さらに、タンデムリピート (TR) のジェノタイピング、セグメント重複領域内の遺伝子の型判定 (遺伝子タイピング)、バリアントのハプロタイプへのフェージング、コンセンサス 5mCpG 確率の推定などの機能も備えています。マルチサンプルのコホートに対しては、小規模バリアントと構造バリアントの両方に対するジョイントコーリング (joint-calling) を提供します。包括的なアノテーションツールは、小規模バリアントと構造バリアントの両方に対応します。ヒト HiFi データを解析するステップは次のとおりです。 リードアライメント – HiFi リード向けに最適化されたマッパーおよびアライナーである pbmm2 を用いて、ロングリードをリファレンスゲノムにアライメントします。このアライナーはスプリットマッピングや大きなギャップを効率的に扱えるため、構造バリアントやセグメント重複を正確にマッピングするうえで重要です。出力は、下流処理向けの豊富なメタデータを含む、ソート済み・インデックス付きの Binary Alignment Map (BAM) ファイルです。 SNV と小規模バリアントのコール – SNV および小規模な挿入・欠失の検出には、HiFi リードに特化して学習させたバリアントコーラー ( DeepVariant ) を使用します。ロングリードデータのエラープロファイルとリード特性に合わせて調整された 機械学習 (ML) モデルを適用することで、マッピングが難しい領域でも偽陽性率の低い高信頼のバリアントコールを生成します。 構造バリアントの検出 – このステップでは、リードシグネチャとアライメントパターンを比較して、欠失、挿入、逆位、転座などの大規模なゲノム変化を同定します。PacBio の構造バリアントコーラー ( pbsv ) はロングリードデータ向けに設計されており、ショートリードのアプローチでは見落とされがちな複雑なブレークポイント、タンデムリピート、マルチアレリック (multi-allelic) なイベントを検出できます。 重複領域のバリアント – Paraphase は、遺伝子ファミリーのリードを単一のリファレンスコピーへ再アライメントしてハプロタイプを同定することで、セグメント重複領域における小規模バリアントをコールします。 タンデムリピートバリアントコーラー – Tandem repeat genotyping tool (TRGT) は、HiFi リードにおけるタンデムリピートの変動 (多型) を解析・ジェノタイピングします。リピート長 (サイズ) に基づく標準的なジェノタイピングに加えて、配列組成、リピートのモザイク性、CpG メチル化パターンの包括的な解析、そしてリピートをスパンするリードの視覚的表現も提供します。 フェージングとハプロタイプの決定 – 下流の解釈をサポートするため、ワークフローにはバリアントをハプロタイプに割り当てるフェージングステップが含まれています。 HiPhase は HiFi リードのロングレンジ情報を活用し、数十キロ塩基にわたるハプロタイプブロックを決定することで、臨床および集団ゲノミクスの文脈における解釈性を向上させます。 5mCpG 検出 – pb-CpG-tools は、アライメント済みの HiFi リードから、CpG に対するハプロタイプ特異的なサイトメチル化確率を生成します。 コホートレベルのジェノタイピング (任意) – 複数サンプルのコホートに対しては、 glnexus と pbsv を用いたジョイントジェノタイピング (joint-genotyping) のステップを追加することで、サンプル間のバリアントコールを整合させることができます。 アノテーション – パイプラインには 2 つのアノテーションツール、 slivar と svpack が含まれており、小規模バリアントと構造バリアントに対する包括的なアノテーションを提供します。 ワークフローは 7 つの主要なステップで構成されています (次のアーキテクチャ図の 1〜7 に対応)。 HiFi-WGS パイプラインを AWS CloudFormation にデプロイし、コンテナの移行をトリガーします。 AWS Lambda 関数が AWS CodeBuild をオーケストレーションし、コンテナ処理を行います。 未アライメントの BAM (unaligned BAM / uBAM) ファイルから Amazon Simple Storage Service (Amazon S3) への入力データフロー。 Amazon CloudWatch によるパイプライン実行のモニタリング。 Amazon EventBridge を用いたイベント駆動のワークフロー管理。 出力用 S3 バケットへの結果の保存。 HealthOmics ツールによるパフォーマンス分析で、コストと利用状況を追跡。 このサーバーレスかつマネージドなアーキテクチャは、運用可視性と最適化機能を備えた、スケーラブルかつコスト効率の高いゲノムデータ処理を提供します。 図 1: AWS HealthOmics WGS パイプラインのワークフローと統合ポイントを示すアーキテクチャ図 大規模運用における AWS HealthOmics 上の PacBio WGS バリアントパイプライン AWS HealthOmics は、パイプラインのデプロイと実行を管理し、インフラストラクチャ、コンテナオーケストレーション、WDL のサポートを担当します。各タスクはカスタマイズ可能なリソースを持つコンテナ化ジョブとして実行され、依存関係の管理、そして AWS Identity and Access Management (IAM) によって権限管理された Amazon S3 でのデータストレージを扱います。ワークフローの入力、出力、ログは、HealthOmics コンソールと Amazon CloudWatch を通じて追跡可能です。 AWS HealthOmics 上の WGS パイプラインのソリューションのデプロイは HiFi-human-WGS-WDL v2.1.2 に基づいており、ゲノム解析への無駄のないアプローチを提供します。CloudFormation ソリューションスタックのデプロイでは、Docker イメージの移行を自動化し、 Amazon Elastic Container Registry (Amazon ECR) のポリシーと HealthOmics ワークフロー用 IAM ロールを設定します。パイプラインは次のステップに従います。 aws-samples リポジトリ の CloudFormation テンプレートは、必要な Docker イメージを適切な権限とともに ECR のプライベートリポジトリへ移行する AWS スタックを構築します。このカスタマイズ可能なスタックは、HealthOmics サービスが必要とする S3 バケットと ECR イメージに対して、最小権限アクセスの原則に沿うよう調整できます。 スタックは Docker イメージの移行に CodeBuild を利用します。パイプライン操作を進める前に、CodeBuild プロジェクトが SUCCEEDED ステータスに達しているかを確認してください。 未アライメントの HiFi BAM ファイルは、Amazon S3 または HealthOmics シーケンスストア に保存します。どちらも互換性がありますが、HealthOmics シーケンスストアはゲノミクス固有の追加機能と、よりよいメタデータ管理を提供します。本実装では、PacBio の リファレンスデータリソース と、検証用の HG002 の公開 HiFi データセットを使用しています。 HiFi-human-WGS-WDL リポジトリをクローンし、Docker イメージが選択したパイプラインバージョンと一致することを確認します (テンプレートは v2.1.2 用に構成されています)。別のバージョンを使う場合は、CloudFormation テンプレート内のイメージハッシュ値を調整してください。バリアント解析パイプラインのワークフローパラメーターを作成するには、 aws-samples リポジトリで提供されているサンプルテンプレートを利用します。 HealthOmics は複数サンプルの並列処理を可能にします。マネージドサービスとして、実行の投入を処理し、通知や下流のパイプライントリガーのために Amazon EventBridge と統合します。Amazon EventBridge ルールの構成例 については、 AWS ブログ を参照してください。 HealthOmics ワークフローは、パイプラインの進捗モニタリングのために CloudWatch と統合されます。ワークフローログは CloudWatch ストリームで確認でき、出力用 S3 バケットへコピーされ、サンプル追跡のために実行 ID ごとに整理されます。 HealthOmics run_analyzer ツールは、サンプル単位で詳細なコストとリソース利用状況の知見を提供し、最適なインスタンスタイプを推奨します。本記事のベンチマーク結果はこれらの分析に基づいています。 aws-healthomics-tools は pypi 経由でインストールするか、後述の手順に従ってください。 HealthOmics プライベートワークフローで PacBio WGS バリアントパイプラインを作成・実行する方法 CloudFormation スタックは、PacBio WGS バリアントパイプライン解析に必要な Docker イメージの作成を自動化します。 PacBio WGS analysis with HealthOmics workflows に記載された手順に従ってください。PacBio WGS バリアントパイプラインのプライベートワークフローを作成する主な手順は次のとおりです。 PacBio リポジトリ から HiFi-human-WGS-WDL v2.1.2 リポジトリをダウンロードするか、 PacBio リポジトリ から任意のバージョンをダウンロードします。バージョンによっては、CloudFormation テンプレートの Docker パスを修正する必要があります。 CloudFormation デプロイの前提条件として、Lambda 関数が操作を実行するための AWS Key Management Service (AWS KMS) キーと、 Amazon Virtual Private Cloud (Amazon VPC) 接続内の 2 つの利用可能なパブリックサブネットを作成する必要があります。ポート 443 経由の HTTPS インバウンドトラフィックを許可する自己参照型のセキュリティグループを作成してください。 パイプラインの評価 実行完了後、 run_analyzer ツールを使用して計算利用状況とコストを評価します。 pip install aws-healthomics-tools aws-healthomics-tools run_analyzer <RUN_ID> -o Pacbio-WGS-run_analyser_outputs.csv エンドツーエンドのパイプライン HiFi 解析のベンチマーク結果 PacBio の公開データセットである HG002 HiFi データセットを用いて、米国東部 (バージニア北部) us-east-1 AWS リージョン における HealthOmics 上でさまざまな最適化戦略を検証しました。WGS バリアント解析パイプラインには、1 CPU から 64 CPU、最大 256 GB の RAM まで、リソース要求が幅広いタスクが含まれます。HealthOmics は計算リソースを動的にプロビジョニングします。最も負荷の高いタスクである DeepVariant によるバリアントコールは、HiFi リードでは 64 CPU と 239 GB RAM を必要とし、GPU アクセラレーションも利用可能です。本ベンチマークでは、タスクアクセラレーターによるコストパフォーマンス最適化と、パイプライン性能に対するストレージタイプの影響に焦点を当て、本番運用に最適な構成の確立を目指しました。 最も要求の高いタスクは、 pbmm2 によるリードアライメントと DeepVariant によるバリアントコールでした。DeepVariant の処理を、複数の GPU アクセラレーター (NVIDIA Tesla T4 (omics.g4)、NVIDIA Tesla A10G (omics.g5)、NVIDIA L4 (omics.g6)) で評価しました。これらは、静的および動的な HealthOmics の実行ストレージ (static / dynamic run storage) を用いた CPU ベースのアクセラレーション (omics.m) と比較してベンチマークしています。 最適な構成は NVIDIA Tesla A10G を搭載した omics.g5.2xlarge で、動的ファイルストレージを利用してパイプラインを 8.67 時間・21.26 ドルの計算コストで完了しました。DeepVariant 用の GPU コンテナは、CPU ベースの構成と比較して 21.3 パーセントのコスト削減と 8.5 パーセントの高速化を実現し、パフォーマンスとコスト効率の両面で明確なメリットを示しました。 ストレージ構成の分析では、NVIDIA Tesla T4 (omics.g4) と L4 (omics.g6) のインスタンスは動的ストレージから大きな恩恵を受ける一方で、標準的な omics インスタンスと Tesla A10G (omics.g5) インスタンスはストレージタイプ間の差がほとんどないことが分かりました。これは、ストレージ最適化戦略をインスタンスごとに検討すべきであることを示唆しています。 HealthOmics の run_analyzer ツールでは、Tesla A10G と静的ストレージの組み合わせで 19.15 ドルまでコスト最適化できる可能性が示されました。この分析により、いくつかのタスクでメモリ割り当てを最適化できる余地があることが明らかになりました。pbmm2 アライナーは 64 GB、DeepVariant の make_examples は 16 GB、pbsv_call は 16 GB、DeepVariant の postprocess_variants は 8 vCPU と 64 GB、hiphase は 32 GB で動作できます。ただし、これらの要件はシーケンシング深度や遺伝的多様性によって変動し得ることに注意が必要です。遺伝的多様性の高い集団では、リファレンスに対して相対的により多くのバリアントが検出される傾向があるためです。特にバリアント数に応じてスケールする場面では、PacBio のデフォルトの計算リソース要件が依然として必須となります。 次の棒グラフでは、分析結果を 3 つのパネルで示しています。実行時間 (時間)、実際のコスト (ドル)、そして run_analyzer の推奨事項を適用した後の最適コスト (ドル) です。NVIDIA Tesla A10G と静的ストレージの組み合わせは、19.15 ドルという最良の最適コストを示すと同時に、8.67 時間という競争力のあるランタイム性能も維持しています。この最適コストは、HealthOmics ツール run_analyzer が推奨する計算構成を用いることで達成可能です。 図 2: AWS HealthOmics 上の WGS バリアント解析パイプラインにおける、アクセラレーター種別とストレージ構成別の価格性能比較 AWS HealthOmics は、ゲノムデータに不可欠な堅牢なセキュリティフレームワークを提供し、HIPAA、GDPR、ISO 27001 などの規制に沿った包括的な対策を実装しています。これには、エンドツーエンドの暗号化、KMS キー、ロールベースのアクセス制御、セキュアなロギングと監査が含まれます。この高度なセキュリティアーキテクチャにより、組織はゲノム解析ワークフローをスケールさせながら、厳格なデータガバナンスとプライバシー基準を遵守できます。これにより、HealthOmics は規制要件を守りつつ、機密性の高いデータを大規模に扱うのに適したサービスとなっています。 まとめ 本分析では、PacBio の HiFi WGS バリアント解析パイプラインを AWS HealthOmics 上に実装し、パフォーマンスとコストの大幅な最適化を達成しました。GPU アクセラレーション、特に NVIDIA Tesla A10G (omics.g5.2xlarge) は、CPU ベースの構成と比較して 21.3 パーセントのコスト削減と 8.5 パーセント高速なパイプライン完了を実現しました。評価では、NVIDIA Tesla T4 と L4 のインスタンスは動的ストレージから恩恵を受け、Tesla A10G はストレージタイプにかかわらず安定した性能を維持することが分かりました。HealthOmics の run_analyzer ツールにより、適切なリソース割り当てを通じて、Tesla A10G と静的ストレージを組み合わせた 19.15 ドルの最適コスト構成を特定できました。HealthOmics のリソースを動的にプロビジョニングする能力と、HIPAA、GDPR、ISO 27001 に準拠した堅牢なセキュリティフレームワークが組み合わさることで、機密性の高いゲノムデータを大規模に処理するのに適しています。これらの知見は、厳格なデータガバナンスとプライバシー基準を維持しながら、効率的でセキュア、かつスケーラブルなゲノム解析ワークフローを実装するための貴重な指針となります。 始め方 PacBio HiFi データを大規模に解析するには、次を参照してください。 PacBio のオープンソース HiFi-human-WGS-WDL パイプライン を活用する AWS HealthOmics がどのようにセキュアかつスケーラブルなゲノム解析を実現するかを学ぶ サポートやカスタマイズされたワークショップのご依頼は、 AWS Genomics チームまでお問い合わせください 著者について Edwin Sandanaraj Edwin は AWS のゲノミクスソリューションアーキテクトです。神経腫瘍学で博士号を取得し、ヘルスケアゲノミクスのデータ管理と解析で 20 年を超える経験を持ち、アジア太平洋・日本地域における精密ゲノミクスの取り組みを加速するために豊富な知見を提供しています。臨床ゲノミクスとマルチオミクスをクラウドベースのソリューションで組み合わせ、精密医療を加速することに情熱を注いでいます。 Charlie Lee Charlie は AWS におけるアジア太平洋・日本地域のゲノミクス業界リードで、バイオインフォマティクスに軸足を置く計算機科学の博士号を持っています。バイオインフォマティクス、ゲノミクス、分子診断で 20 年以上の経験を持つ業界リーダーであり、最先端のシーケンシング技術とクラウドコンピューティングをゲノミクスに活用し、研究の加速とヘルスケアの改善に情熱を注いでいます。 Billy Rowell Billy は PacBio のシニアスタッフバイオインフォマティクスサイエンティストで、遺伝学とゲノミクスの研究に 25 年以上の経験を持っています。バリアントコールと希少疾患研究に向けた高性能計算 (HPC) およびマルチクラウドワークフローの開発をリードしています。 Khi Pin Chua Dr. Khi Pin は PacBio の計算生物学グループのサイエンティストです。彼の仕事は、PacBio の HiFi シーケンシングデータから新しい生物学的知見を引き出すための革新的なツールと解析ワークフローの開発に集中しています。PacBio の最先端のロングリードシーケンシング技術を、特にがんゲノミクスなどの分野で高度なゲノミクス応用に活用する研究者や臨床医の広いネットワークと協働しています。 Rajesh Sukumaran Rajesh は AWS のアジア太平洋・日本地域を担当する HealthTech (ヘルステクノロジー) のシニアパートナーマネージャーです。ヘルスケアとテクノロジーの分野で 20 年以上の経験を持ち、AWS パートナーと協働してヘルスケアの変革を推進するソリューションを提供しています。熱意あるヘルスケア起業家であり、コンピューターエンジニアでもある Rajesh は、INSEAD で MBA を取得しています。 翻訳は Solutions Architect の吉村が担当いたしました。

本記事は 2026 年 6 月 3 日に公開された Edwin Sandanaraj、Dr. Charlie Lee、Maruthi Alamuru による “ Accelerating life sciences research with Kiro: A unified AI interface to 100+ open source databases ” を翻訳したものです。 ライフサイエンス分野の研究者は、データ統合という根深い課題に直面しています。たとえば、体細胞変異を創薬可能な標的と結びつけるといった 1 つの調査だけでも、遺伝子のコンテキストを得るために National Center for Biotechnology Information (NCBI) 、臨床的意義を確認するために ClinVar 、タンパク質の機能を確認するために UniProt 、構造データを得るために Protein Data Bank (PDB) 、相互作用パートナーを確認するために STRING 、化合物の生物活性を確認するために ChEMBL に問い合わせる必要があるかもしれません。それぞれのデータベースには独自の API、認証方式、データ形式、レート制限があります。研究者は数十のブラウザタブを行き来しながらコンテキストを切り替えるか、API が変更されるたびに壊れるカスタムスクリプトを書くかを強いられているのが現状です。 本記事では、 Kiro for Life Sciences を紹介します。これは Kiro power パッケージ で、Kiro を 24 の科学分野にわたる 100 以上のデータベースを横断する統合研究インターフェースへと変貌させます。ポータルでもダッシュボードでもなく、研究者が自然言語で質問を投げると、権威ある情報源から直接引き出された構造化・相互参照された回答を得られる AI アシスト開発環境です。 データサイロが発見のスピードを鈍らせる BRCA1 のバリアントを研究する計算生物学者は、昨今、次のような作業を行う必要があるかもしれません。 NCBI Gene で基本的なアノテーションを検索する。 UniProt からアミノ酸配列を取得する。 ClinVar で病的バリアントを確認する。 PDB または AlphaFold で立体構造を調べる。 STRING で相互作用パートナーを探す。 疾患との関連を調べるために OMIM と相互参照する。 集団における頻度を確認するために gnomAD を調べる。 そのパスウェイを標的とする化合物を ChEMBL で検索する。 これで 1 つの遺伝子につき、8 つのデータベース、8 つの認証フロー、8 種類の結果フォーマットです。これがバリアントごと、プロジェクトごとに積み重なっていきます。認知負荷は非常に大きく、重要なクロスリファレンスを見落とすリスクも現実的な問題として存在します。 ソリューション概要: Kiro for Life Sciences Kiro for Life Sciences は、Kiro power とモジュラーな Model Context Protocol (MCP) サーバーを組み合わせたアーキテクチャを採用しています。中心となる power がハブとして機能し、オンボーディングダッシュボード、検索可能なリソースカタログ、認証情報マネージャー、ドメインスキル、ガイド付きワークフローを提供します。実際のデータベース接続は、独立してデプロイ・設定可能な 24 のドメイン特化 MCP サーバーが担当します。 このソリューションは、次の主要なアーキテクチャ設計判断に基づいて構築されています。 設計上のモジュール性 – 必要なサーバーだけをインストールできます。プロテオミクス研究室に生態学用サーバーは不要です。各サーバーは独立した Python パッケージとして提供されます。 認証情報の一元管理 – API キーは mcp.json に一度設定するだけです。認証情報マネージャーがトークンの更新、レート制限、エクスポネンシャルバックオフを用いたリトライロジックを処理します。 データベース横断検索 – 1 つの質問を投げるだけで、複数のデータベースから同時に回答を得られます。手動でのオーケストレーションは不要です。 カバー範囲の全体像 次の表は、各ドメインにおいてどのデータベースやツールがカバー範囲となっているかを示しています。 ドメイン データベースおよびツール ツール数 ゲノミクスおよびシーケンシング NCBI、Ensembl、ClinVar、gnomAD、 COSMIC 、 dbSNP 、 ENCODE 、 GEO 、 SRA 、 DDBJ 、 1000 Genomes 18 プロテオミクス UniProt、 InterPro 、STRING、PRIDE、 neXtProt 8 構造生物学 PDB、 AlphaFold DB 、 CATH 、 SCOP 6 臨床および製薬 OMIM、 DrugBank 、ChEMBL、 PharmGKB 、 OpenTargets 、 ClinicalTrials.gov 、 FDA FAERS 10 ケモインフォマティクス PubChem 、 ChemSpider 、 RDKit 、 SwissDock 8 免疫学 IEDB 、 ImmPort 、 IMGT 、 abYsis 4 微生物学およびメタゲノミクス SILVA 、 QIIME 2 、 MG-RAST 、 BV-BRC 、 CARD 8 パスウェイおよび相互作用 KEGG 、 Reactome 、 BioCyc 、 WikiPathways 、 IntAct 7 生態学および環境 GBIF 、 IUCN 、 iNaturalist 、 BOLD 、 MGnify 7 分子生物学 BLAST 、 Primer3 、 HMMER 、 REBASE 、 Clustal Omega 9 その他 14 以上のドメイン 神経科学、細胞生物学、メタボロミクス、エピゲノミクス、イメージング、農業、ヘルスケア、バイオバンキング、パイプライン、データ標準、AI/ML 50 以上 合計 100 以上のデータベースおよびツール 250 以上 仕組み このインターフェースは、1 つのクエリに対して複数のデータベースから回答を返すよう設計されています。使い始めるには、まず Kiro に次のように尋ねます。 TP53 を研究しています。UniProt から配列を取得し、PDB で実験的に決定された構造を探し、AlphaFold で予測構造を確認し、STRING から相互作用パートナーを取得し、InterPro からドメイン構造を表示してください。 Kiro は 5 つのデータベースへ並列にクエリを発行し、統合されたタンパク質プロファイルを返します。スクリプトを書く必要も、タブを切り替える必要も、フォーマットの調整も不要です。 データベース横断検索インテリジェンス データベース横断検索機能は、インストール済みの MCP サーバーに並列クエリをオーケストレーションし、結果の自動集約とグレースフルデグラデーションを行います。 検索タイプ 並列で問い合わせるデータベース gene NCBI Gene、UniProt、Ensembl、ClinVar、OMIM、Gene Ontology、KEGG、Reactome drug DrugBank、ChEMBL、PharmGKB、OpenTargets、PubChem、 HMDB 、CARD protein UniProt、PDB、AlphaFold DB、InterPro、STRING、neXtProt、 ESM species GBIF、IUCN Red List、BOLD、iNaturalist、NCBI Taxonomy、MGnify metabolite HMDB、MetaboLights、METLIN、MassBank、PubChem、KEGG cell_type CellxGene、Single Cell Expression Atlas、Cell Atlas、Allen Brain Atlas ガイド付きのマルチステップワークフロー power には 16 個の steering ファイルが含まれています。これらは、ワークスペースのファイルパターンに基づいて自動的に有効化される、段階的なワークフローガイドです。 バリアントコーリングパイプライン – AWS HealthOmics を通じて、体細胞または生殖細胞系列のバリアントコーリングをセットアップして実行します。 遺伝子と疾患の関連 – ClinVar を OMIM および HPO と相互参照し、バリアントから表現型までを網羅したマップを構築します。 化合物スクリーニング – PubChem で候補を検索し、RDKit で記述子を計算し、ZINC でフィルタリングした上で、分子ドッキングまで実施します。 プライマー設計とクローニング – Primer3 でプライマーを設計し、PrimerBLAST で特異性を検証し、制限酵素解析を行い、最終的なコンストラクトを構築します。 マイクロバイオーム解析 – SILVA を用いて分類群を割り当て、QIIME 2 で多様性を評価し、CARD で薬剤耐性遺伝子をプロファイリングします。 これらはドキュメントページではありません。Kiro が段階的に手順を辿って実行する実行可能ガイドであり、適切なツールを適切な順序で呼び出します。 ベストプラクティスを内包したドメインスキル 10 個のドメインスキルは、作業内容に応じて有効化されるコンテキスト対応のガイダンスを提供します。 バイオインフォマティクスファイル形式 – FASTA、FASTQ、BAM、VCF、GFF、BED の取り扱いパターン ゲノミクスパイプラインのベストプラクティス – 再現性のあるワークフローのための WDL、Nextflow、CWL の設計パターン データコンプライアンス – HIPAA、GDPR、GxP、MIAME、MINSEQE の要件 臨床インターオペラビリティ – FHIR、HL7、OMOP CDM の統合パターン ケモインフォマティクス – SMILES または InChI の取り扱い、Lipinski の法則、SAR 解析 パイプラインを書いているときには、Kiro は慣例を知っています。患者データを扱っているときには、コンプライアンス要件を知っています。 例: 1 セッションでバリアントから創薬標的まで 現実的な研究セッションはこのような形になります。研究者が質問を投げると、ツールが適切なデータベースから自動的に情報を引き出し、回答を返します。 ClinVar で EGFR の病的バリアントを検索してください : 臨床的意義付きのバリアント ID を返します。 PDB から EGFR のタンパク質構造を取得してください : 分解能と手法を含む 1M17 を返します。 ChEMBL における EGFR と薬剤の既知の相互作用を教えてください : 化合物の生物活性データを返します。 OpenTargets で EGFR の疾患関連を確認してください : がん種を横断したスコア付きの関連情報を返します。 このリード化合物の ADMET 特性を予測してください : 溶解度、BBB 透過性、CYP450 の予測を返します。 受容体 1M17 とこのリガンドの SMILES でドッキングジョブを投入してください : 結合親和性と相互作用する残基を返します。 研究者は 1 回の会話の中で 6 つのステップを踏み、6 つのデータベースを検索しました。コンテキストの切り替えも、フォーマット変換も、認証情報の切り替えも不要です。 何が違うのか Galaxy や UCSC Genome Browser のような Web ポータルは強力ですが、特定のドメインに特化しています。1 つのインターフェースで 24 の分野にまたがることはできません。Kiro for Life Sciences は、ライフサイエンスの全ドメインを横断する統合体験を、IDE の内部から直接利用できる形で提供します。 Biopython のようなスクリプトライブラリはプログラマティックなアクセスを提供しますが、データベースごとに統合コードを書き、メンテナンスする必要があります。Kiro が API 呼び出し、ページング、エラー処理、レート制限を処理するため、研究者は配管作業ではなくサイエンスに集中できます。 汎用の AI アシスタントは生物学について議論できますが、データベースに対してライブクエリを実行することはできません。Kiro は認証済みで構造化された API 呼び出しを行い、機械可読な結果、つまり訓練コーパスからの要約ではない実データを返します。 このソリューションが提供する独自の価値は、研究者が平易な言葉で質問を投げられる点にあります。Kiro が問い合わせるべきデータベースを判断し、並列で呼び出しを実行し、認証やリトライを処理し、統合された結果を、コードを書いたりパイプラインを実行したりデータを解析したりする環境と同じ場所で返します。 計算科学者のためのアーキテクチャ 各 MCP サーバーは、非同期 HTTP クライアント、エクスポネンシャルバックオフ、構造化されたエラー処理を備えた、独立した Python パッケージとして構築されています。共通の基盤パッケージである life-sciences-common が、すべてのサーバーが継承する HTTP クライアント、リトライロジック、エラー分類を提供するため、あらゆるドメインで一貫した挙動が保証されます。 サーバーは uvx を使って実行可能で、Docker コンテナやインフラストラクチャの管理は不要です。バンドルマニフェストは 24 のサーバーすべてを宣言的に記述しており、ステータスの確認やセットアップの構成を容易にします。Hypothesis を用いたプロパティベーステストが、エッジケースにも耐える堅牢性を提供し、予期せぬ入力に対してもツールが正しく動作するという安心感を与えます。 大規模な計算処理については、AWS HealthOmics 統合により、独自のクラスタインフラストラクチャを管理することなく、nf-core、WDL、CWL のパイプラインを実行できます。 このソリューションは、複数の分野の研究者に次のようなメリットをもたらします。 データベース API ごとにラッパースクリプトを保守しているバイオインフォマティシャンは、その定型コードを廃止し、統合レイヤーを Kiro に任せられます。複数のデータソースを横断して発見を相互参照する必要のある計算生物学者は、これまで 6 つものツールの出力をつなぎ合わせなければ実現できなかったことを、1 回の会話でこなせるようになります。 臨床研究者は、解析環境を離れることなくバリアントを疾患、そして薬剤へとマッピングできるため、調査の一連の流れを 1 か所に集約できます。タンパク質構造を調べたり、プライマーを設計したりしたい実験系の科学者は、もはやプログラマティックな API を学ぶ必要はなく、自然言語で尋ねるだけで済みます。 研究チームにとっては、データベースへの問い合わせを共有・再現可能なアプローチで行えることが、全員が同じツール群から作業できることを意味し、共同研究にありがちな「私のマシンでは動くのに」問題を軽減します。 導入手順 power をインストールし、対象ドメインの MCP サーバーを構成して、質問を始めるだけです。オンボーディングダッシュボードには、利用可能なもの、認証情報が必要なもの、すぐに使えるものが表示されます。 次のコードブロックは mcp.json の設定例です。 { "mcpServers": { "life-sciences-genomics": { "command": "uvx", "args": ["life-sciences-genomics"], "env": { "NCBI_API_KEY": "your-ncbi-api-key" } }, "life-sciences-proteomics": { "command": "uvx", "args": ["life-sciences-proteomics"] }, "life-sciences-structural": { "command": "uvx", "args": ["life-sciences-structural"] } } } 結果として、3 つのサーバーが構成され、1 つのチャットインターフェースから NCBI、Ensembl、ClinVar、UniProt、PDB、AlphaFold のほか、さらに十数個のデータベースへすでにクエリを実行できるようになっています。 まとめ ライフサイエンス研究が抱えているのは計算能力の問題ではなく、統合の問題です。データは何百ものデータベースにわたって存在しています。課題は、それらに効率的にアクセスし、正しく相互参照し、しかもプロジェクトごとにカスタムの統合レイヤーを構築せずに実現することです。 Kiro for Life Sciences は、1 つのインターフェース、一元化された認証情報、そして研究者が遺伝子からバリアント、構造、創薬標的、臨床試験まで、数日ではなく数分で辿り着ける 1 つの場所を提供することで、その統合コストを解消します。データベースは引き続き唯一の情報源であり、Kiro が唯一のアクセスポイントとなります。始めるには、24 の MCP サーバー、スキル、steering ファイル、設定例をすべて含む完全な power パッケージを GitHub でご覧ください。 著者について Edwin Sandanaraj Edwin は Amazon Web Services (AWS) のシニアソリューションアーキテクトです。神経腫瘍学の博士号を持ち、ヘルスケアゲノミクスのデータ管理と解析において 20 年以上の経験を持つ彼は、豊富な知識でアジアパシフィックおよび日本における精密ゲノム医療の取り組みの加速を支援しています。クラウドベースのソリューションを活用した個別化医療の推進を目的に、臨床ゲノミクスとマルチオミクスに強い関心を寄せています。 Dr. Charlie Lee Charlie Lee は AWS のアジアパシフィックおよび日本におけるゲノミクス業界リードで、バイオインフォマティクスを専門とするコンピューターサイエンスの博士号を持っています。バイオインフォマティクス、ゲノミクス、分子診断の分野で 20 年以上の経験を持つ業界リーダーであり、最先端のシーケンシング技術とクラウドコンピューティングによるゲノミクスを通じて、研究の加速とヘルスケアの向上に情熱を注いでいます。 Maruthi Alamuru Maruthi は AWS Healthcare and Life Sciences 業界担当のメンバーです。15 年以上にわたり、ライフサイエンスおよびヘルスケア企業が最先端テクノロジーと実世界の成果とのギャップを埋めるのを支援してきました。これにより企業は、創薬の加速、患者体験の再構築、そして生命を変える治療法や製品をこれまでにない速さで市場に届けることができるようになっています。 翻訳は Solutions Architect の吉村が担当いたしました。