『診察室の音声をAIが拾った』さくら、AWS-Bedrock、Cloudflareのどれを選ぶか

医療AIの国内保管、契約、越境、ログを一次情報で比較する

7月 30, 2026

外来の問診中、自分で作ったバックエンドAIのマイクが意図せずオンになっていました。診断や治療に使う予定はなく、医師自身の業務を支える仕組みとして作ったものですが、患者さんの名前、症状、服薬歴が文字起こしされ、一部は外部のAI基盤へ送られていました。

これは実例の告白ではなく、医師がAIを自作する時代に十分起こり得る設計事故を置いた思考実験です。

この条件で、現時点の第一候補は Amazon Bedrock です。ただし、東京リージョンに閉じ、クロスリージョン推論を使わず、`data_retention_mode: none` を強制し、本文を保存するモデル呼び出しログを無効にし、患者情報をモデルの手前で止める構成にできる場合に限ります。

さくらのAI Engine は、誤設定しても国外へ出にくい構造では最も強い候補です。一方、公式サイトの「すべて国内クラウドで完結」という説明と、公開約款で契約上確認できる義務の範囲には差があります。国内保管、削除期限、事故時の開示、監査資料、責任上限を個別契約で補えるなら、順位は逆転し得ます。

Cloudflare Workers AI / AI Gateway は、DLPやエッジ実装には魅力があります。しかし、Regional ServicesはWorkersから他サービスへの外向き通信に及ばず、Workers AIの推論を日本国内に固定する根拠にはなりません。患者情報が混ざる可能性のある中核処理には選びません。

そして三社に共通する、さらに重要な判断があります。

クラウドを選ぶ前に、診察音声を取得しない設計へ戻すべきです。

どのベンダーを選んでも、マイクが拾った瞬間の責任は消えません。

「診療に使わない」は免責にならない

個人情報保護委員会は、映像や音声による情報も個人情報に含まれると明示しています。さらに、診療の過程で医療従事者が知り得た身体状況、病状、治療状況などは要配慮個人情報です。患者さんが医師に症状を話す行為と、その会話を常時録音し、文字起こしし、別のバックエンドAIへ送る行為は、同じ説明で済ませるべきではありません。

患者さんが医師へ病歴を話すことは、診療に必要な情報を医療機関が取得することへの同意を通常は含みます。しかし、「医師個人のバックエンドAIが音声を継続取得する」「診療とは別の目的で要約を蓄積する」「外部クラウドで推論する」ことまで、当然に予測できるとは限りません。

したがって、最初に決めるのはモデルではありません。

何のために音声を取得するのか
録音するのか、一時的なストリーム処理だけなのか
誰の管理するシステムへ送るのか
何秒、何日、どのログへ残るのか
患者さんが拒否した時に診療上の不利益がないか

この説明と運用がない状態では、BedrockのZDRも、さくらの国内完結も、CloudflareのDLPも、取得時の問題を解決しません。

クラウドへの処理委託は、利用目的の達成に必要な範囲であれば、直ちに第三者提供になるとは限りません。ただし、委託先の選定、契約、再委託、アクセス、事故対応を確認する責任は残ります。医療情報を扱う事業者向けガイドライン第2.0版も、事業者と医療機関の合意内容、リスクコミュニケーション、SLAを明確にする方向へ改定されています。

取得、委託、国外移転、保存、二次利用は別々の論点です。「国内だからよい」「学習しないからよい」という一文で束ねると、事故の入口を見失います。

まず、音声をAIへ送らない構造を作る

この用途の安全設計は、LLMの選定から始めません。マイクからモデルまでの経路を分解します。

図1は、個人情報保護委員会が求める委託先の監督と、経済産業省ガイドライン第2.0版が重視する合意・リスクコミュニケーション・SLAを、実装時の停止境界へ置き換えたものです。

1. マイクは既定でオフにする

診察室へ入ったら自動的に録音する設計をやめます。患者さんごと、利用目的ごとに明示的に開始し、画面と物理インジケーターの両方で作動中と分かるようにします。バックグラウンド起動、ウェイクワード、OS再起動後の自動復帰も止めます。

2. 生音声は端末内の短時間バッファに置く

音声が必要な場合でも、最初からクラウドへ常時送信しません。端末内の揮発性バッファに限定し、処理失敗時は送信ではなく破棄を選びます。利用目的が成立しない音声を「後で分類するため」に残さないことが重要です。

3. 患者情報の判定をモデルの手前へ置く

氏名、住所、電話番号、診察券番号だけでは足りません。「先週のCTで肺に影があった」「父も同じ病気だった」といった自由文も診療情報です。正規表現だけでなく、固有表現抽出、医療語彙、会話の文脈を組み合わせ、疑わしい入力は送信しないfail-closedにします。

ここで注意したいのは、クラウドのDLPへ原文を送ってから止めても、そのDLP基盤には原文が到達していることです。最初の遮断は端末内または医療機関が管理する境界内で行う必要があります。

4. バックエンドへ渡すのは許可された要約だけにする

患者さんを識別できる情報、病名、薬剤名、検査値を削れば必ず匿名になるわけではありません。稀な疾患、職業、年齢、受診日、地域の組合せで再識別できることがあります。送信許可は「名前を消した」ではなく、用途に必要な最小情報になったかで判定します。

5. 送らなかった事実も記録する

監査ログへ残すのは音声本文ではありません。開始者、目的、同意状態、適用したポリシー、送信可否、遮断理由、送信先リージョン、保持モード、設定変更者を残します。本文を監査のために保存すると、監査機能が新しい漏えい面になります。

三社の比較は、この入口対策を実装した後の話です。

さくらのAI Engineは「国内完結」と「契約」を分けて読む

さくらのAI Engineの公式サイトは、モデルの実行・通信を「すべて国内クラウドで完結」し、外部へのデータ送信がないと説明しています。通常モデルもさくら側でホストされ、クローズドモデルの入力もモデル提供元へ送られないと公式マニュアルに記載されています。

これは大きな利点です。海外リージョンを誤って選ぶ、クロスリージョン用のプロファイルを使う、外部モデルへフォールバックする、といった設定事故を構造的に減らせます。医療機関に専任のクラウド担当者がいない場合、この「誤設定しにくさ」は機能数より価値があります。

一方で、契約を読むと違う景色が見えます。

AI Engineサービス約款第10条は、入力情報を第三者へ提供せず、AIの学習にも利用しないと定めています。ここはWebサイトの説明だけでなく、約款本文に入っている強い部分です。

しかし同じ第10条は、入力・出力を原則保存しないとしながら、保守や障害対応のため「一定期間」保存する場合があると定めています。その期間の日数、削除確認の方法、保存設備の所在地は、公開約款の同条からは確定できません。

さらに、公式サイトの「すべて国内クラウドで完結」に対応する、データの国内保存を義務づける明示的な条項は、公開されたAI Engineサービス約款全13条では確認できませんでした。製品説明が虚偽だと断定する話ではありません。監査質問票へ回答する時に、Webページと契約条項を同じ証拠として扱えないという話です。

ISMAPもサービス単位で見ます。さくらの公式マニュアルに掲載された対象は「さくらのクラウド（IaaS）」で、対象機能の一覧にAI Engineは記載されていません。「さくらがISMAP登録されている」ことを、そのままAI Engineの適合証拠にはできません。

責任条項にも差があります。基本約款第29条は、漏えい、不正アクセスなどの損害について原則免責とし、法人利用者に対する例外的な賠償も、故意または重大な過失に直接起因する通常損害について、当該サービス1か月分の利用料金を上限としています。第30条は、脅威に対する安全性や定常提供を含む保証を否認しています。AI Engineの公式マニュアルもSLAの適用対象外と明記しています。

したがって、さくらを選ぶ条件は明確です。

国内処理・国内保管を個別契約の義務にする
「一定期間」を具体的な日数にする
削除完了を確認できる証跡を得る
事故時の通知期限、ログ開示、再委託先を定める
医療情報ガイドラインへの適合開示書とSLAを得る
責任上限と免責のカーブアウトを交渉する

この六点が書面で閉じるなら、さくらの構造的な国内完結は非常に強い選択肢になります。閉じないなら、「国外へ出にくいが、事故後の立証材料が足りない」という評価です。

Bedrockは設定ではなく、設定を強制できるかで決まる

Amazon Bedrockの強みは、保存、ログ、権限、暗号化、DLP相当の制御を細かく組み合わせられることです。弱みも同じです。選択肢が多いため、正しい設定を一度行うだけでは不十分です。

AWSカスタマーアグリーメント第1.4条は、利用者がコンテンツを保存するAWSリージョンを指定でき、必要な場合や法的命令への対応を除き、選択したリージョンからコンテンツを移動しないと定めています。アマゾンウェブサービスジャパン合同会社が契約当事者であれば、日本法と東京地方裁判所が適用されます。

2026年7月時点のBedrockには、アカウントまたはプロジェクト単位のデータ保持モードがあります。`data_retention_mode: none` では、リクエストとレスポンスをAWSの永続ストレージへ書き込まず、モデル提供者にも共有しません。ZDRに対応しないモデルは呼び出し自体がブロックされるため、「対応していないモデルへ黙って落ちる」より安全です。ただし、利用できるモデルとAPIには制約が生じます。

モデル呼び出しログは既定で無効です。ここを有効にすると、入力と出力をCloudWatch LogsやS3へ保存できます。医療用途では、監査したいという理由で本文ログを有効にし、ZDRの外側に患者情報を残す逆転が起こり得ます。

さらに、Bedrock GuardrailsのPIIマスキングはモデルへ渡る入力を匿名化できますが、モデル呼び出しログが有効な場合、ログのinputにはマスキング前の原文が残ります。Guardrailsのtraceにも一致した原文が含まれます。したがって、Guardrailsを付けたことは「患者情報が保存されない」証拠にはなりません。

Bedrockを選ぶなら、最低でも次の設定を組織ポリシーで固定します。

1. 東京リージョンの直接エンドポイントだけを許可する

2. geographic / cross-Region inference profileを拒否する

3. `data_retention_mode: none` 以外をSCPまたはIAMで拒否する

4. ZDR非対応モデルを利用不可にする

5. モデル呼び出し本文ログを無効にする

6. GuardrailsのPII block / maskを二段目の防御として使う

7. VPC Endpoint、KMS、最小権限IAM、設定変更のCloudTrailを使う

8. 原文を含まない監査イベントを別系統で残す

Guardrailsは確率的な検出です。氏名や住所を見落とすことも、医療文脈を過検出することもあります。第一防御ではなく、端末内遮断を抜けた時の第二防御として使います。

契約上の責任上限は万能ではありません。AWSカスタマーアグリーメント第9.2条の一般的な上限は、原因となったサービスについて直前12か月に支払った金額です。日本の契約当事者には、重大な過失や意図的な不正行為等に関する追加規定がありますが、医療機関が負う説明、報告、復旧の負担がAWSへ移るわけではありません。

Bedrockが第一候補なのは、AWSという名前が大きいからではありません。保持しない、国外へ出さない、原文をログへ残さない、違反する設定を拒否する、という四つを技術と契約の両方から立証しやすいからです。

CloudflareはDLPを得たが、国内推論の問題は残る

Cloudflareの評価は、古い情報のままにしない方がよいです。

AI Gatewayには現在、PII、金融情報、政府識別子、医療情報、独自パターンを検出するDLPがあります。リクエストとレスポンスを検査し、flagまたはblockできます。Workers AIの入力、出力、埋め込みはCustomer Contentとされ、Cloudflareは明示的な同意なしにモデル学習やサービス改善へ使わないと説明しています。

したがって、「CloudflareにはPII対策がない」という比較は現在は誤りです。

それでも、今回の中核処理には選びません。

CloudflareのData Localization SuiteでRegional Servicesを設定すると、対象ホスト名のTLS終端とWorkersコードの実行場所を地域内へ制限できます。しかし公式文書は、Workersから他サービスへの外向きサブリクエストにはRegional Servicesが及ばないと明記しています。Workersコードとsecretも世界中のデータセンターへ配備されます。

つまり、入口のWorkerを地域限定しても、その先のWorkers AI推論まで日本国内に固定されたとは言えません。AI Gatewayで外部モデルへ転送する場合は、Cloudflareに加えて転送先モデルの処理地域、保持、ログも評価対象になります。

DLPにも運用上の注意があります。DLPは原文を検査するため、患者情報をCloudflareへ送る前の遮断にはなりません。医療情報プロファイルを使える契約プラン、誤検知時の動作、ログ保持、キャッシュ、BYOK、Logpushの設定も確認が必要です。

Cloudflareを使うなら役割を限定します。

患者情報を端末内で除去した後のAPIゲートウェイ
認証、レート制限、コスト制御
個人情報を含まない公開情報の検索や要約
DLPによる追加のblock

生音声、文字起こし原文、患者別の診療要約を通す中核データプレーンには置きません。

三社を同じ条件で比較する

比較の前提は、「外来音声に患者情報が混ざる可能性があり、診療判断には使わないが、医師のバックエンドAIへ渡したい」という用途です。モデル性能や価格より、混入を止め、事故後に説明できることを重く見ます。

図2の判断根拠は、さくらの国内完結の説明、Amazon Bedrockのデータ保持、Cloudflare AI GatewayのDLPとWorkersの地域制約です。

取得時の問題を解決するか

さくらのAI Engine: 解決しない
Amazon Bedrock: 解決しない
Cloudflare Workers AI / AI Gateway: 解決しない

国内処理の構造

さくらのAI Engine: 公式説明では国内完結。誤設定耐性が高い
Amazon Bedrock: 東京リージョン直呼びなら国内に閉じやすい。クロスリージョンを拒否する必要
Cloudflare Workers AI / AI Gateway: Workers実行地域は制御可能だが、外向き通信やWorkers AI推論まで日本固定とは言えない

国内保管の契約根拠

さくらのAI Engine: 公開AI Engine約款に明示条項を確認できない
Amazon Bedrock: Customer Agreement 1.4に選択リージョンから移動しない原則
Cloudflare Workers AI / AI Gateway: 日本国内固定の契約根拠を今回の公開資料では確認できない

学習利用・モデル提供者共有

さくらのAI Engine: 約款第10条で入力の学習不使用・第三者不提供
Amazon Bedrock: ZDR `none` なら永続保存・提供者共有なし
Cloudflare Workers AI / AI Gateway: Workers AI docsで学習・サービス改善不使用。ただし契約と機能構成を別途確認

保持

さくらのAI Engine: 保守・障害対応で「一定期間」保存の可能性
Amazon Bedrock: `none` を強制可能。モデルごとの対応差あり
Cloudflare Workers AI / AI Gateway: 明示的なストレージ利用時は保存。Gatewayログ等を別途管理

本文ログ

さくらのAI Engine: 公開資料から利用者側の細かな制御を確認しにくい
Amazon Bedrock: CloudWatch/S3への本文ログを無効化・制御できる
Cloudflare Workers AI / AI Gateway: Gatewayログ、キャッシュ、Logpushを構成ごとに確認

PII / 医療情報の遮断

さくらのAI Engine: 公開比較資料で同等の組込み機能を確認できない
Amazon Bedrock: GuardrailsでPII block / mask。ログ原文には別対策が必要
Cloudflare Workers AI / AI Gateway: AI Gateway DLPで医療情報をblock可能。プランとログを確認

認証・監査資料

さくらのAI Engine: AI Engine自体のISMAP対象を確認できない。適合開示書を要請
Amazon Bedrock: IAM、CloudTrail、Artifact等を組み合わせやすい
Cloudflare Workers AI / AI Gateway: DLP、ログ、BYOKは強いが、医療中核処理の地域証明が弱い

責任・救済

さくらのAI Engine: 漏えい等は原則免責、例外も1か月分上限。SLA対象外
Amazon Bedrock: 一般上限は直前12か月の支払額。個別契約・追加条項を確認
Cloudflare Workers AI / AI Gateway: Enterprise契約、DPA、責任条項の個別精査が必要

運用難度

さくらのAI Engine: 低め。構造で誤設定を減らせる
Amazon Bedrock: 高い。強制ポリシーと継続監査が必要
Cloudflare Workers AI / AI Gateway: 中程度。エッジ、DLP、外部モデルの境界が増える

この用途での判断

さくらのAI Engine: 個別契約が閉じれば有力
Amazon Bedrock: 条件付き第一候補
Cloudflare Workers AI / AI Gateway: 中核処理には不採用

この表は「どのクラウドが安全か」という一般ランキングではありません。

さくらが勝つのは、事故を起こしにくい構造です。

Bedrockが勝つのは、保持、ログ、権限、リージョンを機械的に強制し、監査証拠を作る能力です。

Cloudflareが勝つのは、患者情報を除去した後のエッジ制御とDLPです。

選ぶべき製品は、どの失敗を最も恐れるかで変わります。

すでに音声を拾ってしまった時の順序

事故が疑われる時は、慌ててログを全消去すると調査に必要な証拠まで失います。逆に、調査のために原文を複製すると影響範囲を広げます。

最初に行うのは、次の順序です。

1. 音声取得と外部送信を止める

2. APIキー、キュー、再送、フォールバックを止める

3. 送信先、リージョン、モデル、時刻、保持モード、ログ設定を確定する

4. 原文を増やさず、必要最小限の証拠を隔離する

5. ベンダー側の保持・削除・アクセス状況を確認する

6. 院内の個人情報管理責任者へ直ちに報告する

7. 影響範囲、再発防止、個人情報保護委員会への報告と本人通知の要否を判断する

要配慮個人情報を含む個人データの漏えい等、またはそのおそれは、件数が少なくても報告対象になり得ます。個人情報保護委員会は、内部報告と被害拡大防止、事実調査、影響範囲の特定、再発防止、委員会への報告と本人通知という順序を示しています。

ただし、AIが音声を拾っただけで直ちに法令上の「漏えい」が確定するわけではありません。誰がアクセスできたか、外部事業者がデータを取り扱ったか、永続保存されたか、契約上の委託範囲内かを確認して判断します。だからこそ、送信先と保持状態を再現できる監査イベントが必要です。

読むべきはリージョン図だけではない

前回、Amazon Bedrockの国内クロスリージョン推論とログの盲点を調べた時、推論の場所だけでなく、記録の場所を見る必要があると書きました。

今回は、その先があります。

記録の場所だけでなく、契約の中身を読みます。

さくらの「すべて国内クラウドで完結」は、技術構造として魅力があります。しかし、医療機関が必要とするのは、事故が起きなかった日の安心だけではありません。起きた日の削除、開示、報告、責任、復旧を説明できる書面です。

BedrockのZDRとGuardrailsは強力です。しかし、クロスリージョン推論や本文ログを一人の操作で有効にできるなら、その強さは設定画面の中にしか存在しません。

CloudflareのDLPは進化しました。しかし、入口で見つける機能と、日本国内で処理する保証は別です。

この用途では、まず診察音声を取得しない設計に戻します。その上で、個別契約がない現状ならBedrockを条件付きで選びます。さくらから国内保管、削除期限、事故対応、監査資料、責任範囲を文書で得られたら再評価します。Cloudflareは、患者情報を除去した後の境界に置きます。

医師が自分のAIを作る時代に必要なのは、性能の高いモデルを一つ選ぶことではありません。

患者さんの言葉が、どこから先へ進んではいけないかを、コードと契約の両方で止めることです。

国内処理
保持期間
本文ログ
削除証跡
事故時の通知

このうち一つでも確認できなければ、患者情報を通しません。

これを、この仕組みの停止条件にします。

Masayuki Otawara MD, PhD｜医療AI

このポストについてのディスカッション

もっと続けますか？