2分で読める生成AIのいま Vol.30「プライベートクラウドの2種類と、医療AIの"自作"を考える」

前回のVol.29では、医療情報を扱うAIに求められるセキュリティ要件を整理しました。

「じゃあ、その要件を満たすAI環境を、どうやって作ればいいの？」

今回はそんな問いに向き合ってみます。

今回も医療田さんと機械屋さんの会話でどうぞ。

冒頭のちょっとしたやり取りにも注目です！

＝＝＝＝＝＝

● はじめに：ちょっとした業務連絡？

医療田：

こんにちは、機械屋さん。

。。あれ？なんか今日、雰囲気ちがう？

機械屋：

あ、気づきました？

じつは昨日、髪を切りに行きまして。。

医療田：

あ、、？あ、ほんとだ―。似合うよー。。

うん、それもそうなんだけど。

機械屋：

あ、ああ、このブログのことですか。。

実は今回から、Antigravityというツールを使い始めまして。

医療田：

ん？なにそれ？アンタイグラビティ―、だから、反重力？

機械屋：

Antigravityというのは、Googleが最近発表した、AIを使った開発環境なんです。

AIがプログラミングを手伝ってくれるだけでなく、

タスクの計画から実行まで、かなりの部分を自律的に進めてくれる、という。

医療田：

へー、それは便利そうだね。

ブログの作者も楽になったのかしらねえ。

機械屋：

そうですね、、

そのあたりはまた、「AIエージェント」という概念に絡めて、改めて解説してもらいましょうよ。

医療田：

そうだね、楽しみにしてよっと。

じゃ、本題いきますか！

あ、機械屋さん、、新しい髪形、似合うよ。ほんとに。

機械屋：

。。ほんとですか？ありがとうございます。。(*- -*)

● 前回のおさらい

機械屋：

さて、前回のおさらいですが、

医療情報を扱う生成AIには、以下のような要件が求められる、という話でしたね。

・入力データはAIの学習に使わせない

・データは保存しないか、しても最小限で削除時期を明確に

・データの保存場所や処理場所は国内にする

・通信経路は強力に暗号化し、専用ネットワークでやり取りする

医療田：

うんうん、

"学習させない・保存しない・国内・暗号化と専用ネットワーク"、だったね。

機械屋：

その通りです。

で、今回は、

「この要件を満たすAI環境を、自分たちで構築するとしたら、どうすればいいか？」

という話をしたいと思います。

医療田：

おお、いよいよ実践編だね。

機械屋：

はい。結論から言うと、大きく分けて2つの方法があります。

1つ目が、クラウド基盤上にAPIを使って環境を構築する方法。

2つ目が、オンプレミスで環境を構築する方法。

これらはそれぞれ、

「クラウド型プライベートクラウド」

「オンプレ型プライベートクラウド」

と呼ばれることもあります。

※　この後順番に説明しますが、さきにまとめた表を貼っておきますね。

医療田：

んん。

ごめん機械屋さん、ちょっと待って。

機械屋：

はい、何でしょう？

医療田：

私、まだ「クラウド基盤」っていうのが、ちゃんとわかってないかも。。

AWSとかAzureとか、名前は聞くんだけど。

機械屋：

おっと、そうですよね。

詳細はまた改めてじっくり解説する回を設けたいと思いますが、

ざっくり言うと、こんな感じです：

クラウド基盤というのは、

インターネット上にある、巨大なコンピューター資源のレンタルサービス、

と思ってもらえればいいです。

医療田：

レンタルサービス？

機械屋：

はい。

サーバーとかストレージとか、本来なら自分で機械を買って設置しないといけないものを、

必要な分だけ、必要な期間だけ、借りて使える、というサービスですね。

代表的なのが、

AmazonのAWS、

MicrosoftのAzure、

GoogleのGoogle Cloud、

あたりです。

医療田：

あー、なるほど。

コンピューターを買うんじゃなくて、環境を借りる、ってことか。

機械屋：

そうです、そうです。

で、このクラウド基盤の上に、自分たち専用のAI環境を作る、というのが1つ目の方法です。

医療田：

オッケー、なんとなくイメージできた。続けて！

● クラウド型プライベートクラウド

機械屋：

では、1つ目の「クラウド型プライベートクラウド」について説明しますね。

これは、AWSやAzure、Google Cloudといったクラウド基盤の中に、

"自分たち専用の区画"を作る、というイメージです。

医療田：

自分たち専用の区画？

機械屋：

はい。

たとえば、AWSには「VPC」、Virtual Private Cloudという機能があります。

これを使うと、AWS上に、自分たちだけがアクセスできる仮想的なネットワーク空間を構築できるんです。

医療田：

んー、、

あ、わかった。

巨大なマンション（AWS）の中に、自分たち専用の部屋を借りる、みたいな感じ？

機械屋：

そうです、そうです。まさにそのイメージです。

・壁で仕切られていて、他の住人からは見えない。

・でも、建物自体の管理（電気、水道、セキュリティ）はマンションの管理会社がやってくれる。

そんな感じですね。

医療田：

便利そうだね。

自分たちでサーバーを買わなくていいし。

機械屋：

その通りです。メリットとしては、

・初期コストが低い（サーバー購入不要）

・スケーラビリティがある（必要に応じて拡張できる）

・インフラ管理の負担が軽い

といった点がありますね。

医療田：

ふむふむ。なるほど。

機械屋：

逆にデメリットとしては

・データが物理的には外部（クラウド事業者のデータセンター）にある

・クラウド事業者との契約内容に依存する部分がある

・通信経路のセキュリティ設計が必要

といったところでしょうか。

医療情報を扱う場合、「国内リージョン」を選ぶことや、

「閉域接続」を使うことで、かなりの部分はカバーできます。

ただ、契約や設定を慎重に行う必要がありますね。

● オンプレ型プライベートクラウド

医療田：

じゃあ、もう1つの「オンプレ型プライベートクラウド」は？

機械屋：

こちらは、自分たちの施設内に、物理的なサーバーを置いて、

その上でクラウドのような仮想化環境を構築する、というものです。

医療田：

へええ、なるほど。

、、機械屋さん、しつもーん。

機械屋：

はいはい、何でしょう？

医療田：

物理的なサーバーを病院内に置いて、、

なんで「クラウドのような仮想化環境を構築する」みたいなことが必要なのかな？

サーバーがあるなら、そのまま使えばいいんじゃない？

機械屋：

ははあ、鋭い質問ですね。

これはどちらかというと便宜的なもので、

「複数のサーバー用コンピューターを、1つの大きなコンピューターのように見立てる」

これを「仮想化環境を構築する」のように呼んでいます。

医療田：

ふんふん、それで？

機械屋：

こうすることで、いくつかメリットがあるんですよ。

たとえば、

・コンピューターの資源（CPU、メモリなど）を効率よく配分できる

・「今日はこっちの処理が重いから、こっちに多めに割り当てよう」みたいな調整ができる

・1台のサーバーが故障しても、他のサーバーでカバーしやすい

といった感じですね。

医療田：

あー、なるほど。

バラバラのサーバーを束ねて、柔軟に使えるようにする、ってことか。

機械屋：

その通りです。

で、こうした仕組みは、クラウド基盤でも同じように使われているので、

「クラウドのような仮想化環境」と表現することがあるんです。

医療田：

なるほどね！

じゃあ、オンプレ型のメリット・デメリットも教えて？

機械屋：

はい。

マンションの例えでいうと、オンプレ型は、

「自分で土地を買って、自分で家を建てる」に近いですね。

メリットとしては、

・データが物理的に自分たちの施設内にある（外に出ない）

・ネットワークも完全に自分たちでコントロールできる

・外部事業者への依存が少ない

といった点です。

医療田：

セキュリティ的には最強、って感じ？

機械屋：

理想的に運用できれば、そうですね。

ただ、デメリットもあります。

・初期コストが高い（サーバー購入、設置、電源・空調など）

・運用・保守を自分たちで行う必要がある

・スケーラビリティに限界がある（拡張するにはまた機材を買う）

・専門人材が必要

医療田：

うーん、、なるほどね。

「自分で家を建てる」って、大変だもんね。。

機械屋：

そうなんです。

特に「専門人材が必要」という点は、医療機関にとっては大きなハードルですね。

● 医療AIを院内に自作するとしたら？

医療田：

じゃあさ、実際に

「うちの病院で、医療情報を扱えるAIを自作したい！」

ってなったら、どっちを選べばいいの？

機械屋：

いい質問ですね。

結論から言うと、「どちらが正解」というわけではなく、

組織の状況によって選択が変わります。

医療田：

ふむふむ。

機械屋：

たとえば、

●　クラウド型が向いているケース：

・初期投資を抑えたい

・IT専門人材が少ない

・まずは小さく始めて、様子を見たい

・クラウド事業者との契約で要件を満たせる

●　オンプレ型が向いているケース：

・データを絶対に外部に出したくない（ポリシー上）

・すでにサーバールームやIT人材がいる

・長期的に大規模な運用を想定している

・特殊な要件がある（特定のハードウェアが必要など）

医療田：

なるほどね。。

うちみたいな中規模の病院だと、まずはクラウド型で試してみる、

というのが現実的かもしれないなあ。

機械屋：

そうですね。

最近は、クラウド事業者も医療向けのコンプライアンス対応を強化していますし、

「HIPAA対応」や「3省2ガイドライン対応」を謳ったサービスも増えています。

ただ、いずれにしても、

「契約内容をしっかり確認する」

「設定を適切に行う」

「運用ルールを整備する」

といった、"人間側の準備"が欠かせませんね。

医療田：

AIを導入するって、技術だけの話じゃないんだね。。

機械屋：

その通りです。

技術と、運用と、組織体制。

この3つが揃って、初めて「安全に使える」状態になるんです。

● まとめ

機械屋：

では、今回のポイントをまとめますね。

・医療情報を扱えるAI環境の構築方法は、大きく2つ

　- クラウド型：クラウド基盤上にAPIを使って構築

　- オンプレ型：自施設内に物理サーバーを置いて構築

・クラウド型：初期コスト低、運用負担軽、ただしデータは外部にある

・オンプレ型：データは完全に手元、ただし運用負担が大きい

・どちらを選んでも、契約確認・設定・運用ルール整備が必須

医療田：

ありがとう、機械屋さん。

「クラウド」って一口に言っても、いろいろあるんだね。

機械屋：

そうですね。

次回は、冒頭でちらっと出た「AIエージェント」についても、

掘り下げてみたいと思います。

医療田：

おー、楽しみ！

Antigravityの話も、もっと聞きたいし。

機械屋：

はい、ぜひ＾＾

＝＝＝＝＝＝

●関連記事

・2分で読める生成AIのいま Vol.29「続：データセキュリティから見る生成AIのタイプ」

https://www.youichimachida-ai.com/blog/unh60mwm8k26mxl5vmjt4wd4r1ewgw

・2分で読める生成AIのいま Vol.28「データセキュリティから見る生成AIのタイプ」

https://www.youichimachida-ai.com/blog/2ai-vol28ai

●2分で読める「生成AIのいま」シリーズ。バックナンバーはブログからどうぞ！

https://www.youichimachida-ai.com/blog