Amazon Nova Act を HIPAA Eligible な医療ワークフローで使う方法

まず結論

医療またはライフサイエンスのチームが、ePHI を含む反復的なブラウザ作業をすでに行っているなら、AWS の 2026-05-21 発表により、Amazon Nova Act は HIPAA スコープのワークロードで検討できる選択肢になった。ただし、ブラウザエージェントが自動的に準拠するわけではない。必要な AWS 契約があり、ワークロードを正しく設定した場合に使える、という意味だ。

最初の展開では、Nova Act を保険資格確認、請求ステータス確認、紹介ステータス確認、ポータルへのデータ入力のような狭く反復的なワークフローだけに使う。1 つのワークフロー、1 つのアカウント境界、1 つのレビューキュー、1 つのログ設計から始める。オープンエンドな医療判断、患者向け助言、多数のシステムをまたぐ無人操作が必要なタスクでは、Nova Act から始めない。

2026-05-22 時点で、安全な展開順序は次の通り。

1. AWS Business Associate Addendum と HIPAA アカウント設定を確認する
2. プレイグラウンドと API キーの試作では、合成データまたは非識別化データだけを使う
3. 開始条件と停止条件が明確なブラウザワークフローを 1 つ選ぶ
4. 本番実行前に least-privilege IAM、暗号化、監査ログを整える
5. 例外、失敗した実行、機微な後続アクションには人間のレビューを必須にする
6. 非本番または低リスクのキューで信頼性を示してから範囲を広げる

2026-05-21 に何が変わったか

2026-05-21、AWS は Amazon Nova Act is now HIPAA eligible と発表し、このサービスは AWS HIPAA Eligible Services Reference に掲載された。医療チームにとって重要な変更はここだ。アカウントが AWS Business Associate Addendum (BAA) でカバーされ、顧客が HIPAA 要件に沿ってワークロードを設定すれば、Nova Act を HIPAA スコープの AWS ワークロードで使える。

実務上の境界は見出しより狭い。ブラウザベースの AI エージェントは HIPAA スコープの AWS アーキテクチャ内に置けるようになった。一方で、AWS の Shared Responsibility Model では、認証、データの扱い、アプリケーション設定、運用上の統制は引き続き顧客の責任になる。

Nova Act が実際にすること

AWS は Amazon Nova Act を、ブラウザ自動化エージェントの集まりを構築、管理するサービスとして説明している。このサービスは本番 UI ワークフローを処理し、自然言語タスクと Python コードを組み合わせ、必要に応じて人間の監督者にエスカレーションし、API 呼び出し、remote MCP、エージェント型フレームワークと統合できる。

本当のボトルネックが、きれいな内部 API ではなく Web ポータルや UI 駆動のシステムに残っているときに Nova Act を使う。

ワークフローが次の形なら、Nova Act を検討できる。

• ブラウザベースのポータルを開く
• 正しい記録またはタスクを見つける
• あるシステムから項目を読む
• 別のシステムに項目を入力する
• 送信またはステータス取得を行う
• 状態が不明なときに停止またはエスカレーションする

医療データを含むという理由だけで Nova Act を使わない。人間がすでにかなり反復的に実行しているブラウザワークフローである場合に使う。

HIPAA Eligibility が最も効く場面

AWS の公式発表は、予約スケジュール、保険資格確認、事前承認、請求ステータス確認、不服申し立て、償還追跡、紹介などの医療ワークフローを挙げている。これらは、反復的で UI に依存し、完全手動のコストが高いことが多いため、最初の候補になりやすい。

最初の試験導入での主な利益は、安定した API ベースの自動化がないシステムで、引き継ぎとコピー貼り付け作業を減らすことだ。

Nova Act を最初に使うなら、次の性質をすべて持つワークフローを選ぶ。

チームがワークフローを境界のあるチェックリストとして説明できないなら、Nova Act は最初のエージェントとしてはおそらく不適切だ。

HIPAA Eligibility が変えないこと

“HIPAA eligible” を “safe by default” や “compliant by default” と読まない。HIPAA Eligible Services Reference は、顧客が HIPAA 要件に沿ってサービスを設定する必要があると明記している。AWS の Shared Responsibility Model も同じ境界を示している。AWS はクラウド基盤を保護し、顧客は自分たちのデータの扱い、認証統制、アプリケーション設定、運用手順に責任を持つ。

Nova Act について言えば、AWS の発表は次を自動で決めてくれない。

• どのアカウントと環境が ePHI を扱えるか
• どの ID がワークフローを開始、検査、変更できるか
• エージェントがどのデータを読み、保存し、書き出せるか
• 完了前に人間の承認が必要なアクションはどれか
• ログ、シークレット、実行成果物をどう保持し、保護するか

これらが未決なら、サービスが eligible になっただけで実験から本番に進めない。

最初のワークフローを作る前に確認すること

実際の患者関連ワークロードが Nova Act に触れる前に、次の前提を確認する。

AWS の今回の getting-started guidance は、ePHI を含むワークロードを go live する前に、BAA プロセス、Nova Act security documentation review、IAM、KMS、CloudTrail、AWS Well-Architected Tool による設計レビューを挙げている。Nova Act では、短いプレイグラウンドテストを HIPAA 試験導入と見なさない。プレイグラウンドと API キー経路はインターフェースを学ぶには便利だが、ePHI を含む実行は BAA とセキュリティチームが承認した AWS アカウント、ID、ログ境界の中で動かす。

安全な最初のワークフローを選ぶ

より単純なポータル作業をまだ自動化していないなら、事前承認の提出から始めない。判断面が最小のワークフローから始める。

最初のワークフローは 5 条件を満たすものにする。

1. 1 つのオペレーターチームがすでに標準チェックリストに従っている
2. 関わるポータルは 1 つか 2 つ
3. 実行開始前に必須項目がすべて分かっている
4. 最終結果はステータス取得、ドラフト作成、キュー振り分けであり、不可逆の取引は最初の実行の外に置く
5. 人間が 1 分以内に結果をレビューできる

最初の展開に向く例：

• 保険資格確認
• 請求ステータス収集
• 紹介ステータス確認
• 内部スタッフ向けの予約枠確認
• payer ポータルから構造化ステータスデータを内部キューに抽出する

最初の展開で避ける例：

• 患者向け助言を作るもの
• 医療上の必要性を判断するワークフロー
• レビューなしで最終的な治療または請求判断を提出するアクション
• 各サイトが頻繁に変わり fallback がない複数ポータルの流れ

実際に試せる最小 Nova Act ワークフロー

最初の医療試験導入では、Nova Act の表面積を小さくする。1 セッション、1 ポータル、1 つの act() 目標、4 つの出力状態に絞る。AWS の Nova Act ドキュメント はワークフローをセッション内の act() statements と Python orchestration と定義しているため、最初の本番に近いワークフローは賢く見える前にレビュー可能であるべきだ。

Web プレイグラウンドや IDE extension でワークフロー契約を試作できるが、使うデータは合成データまたは非識別化データだけにする。real ePHI が実行に現れる前に、そのワークフローを HIPAA スコープのアカウントとログ設計に属する AWS IAM/デプロイ済みサービス経路へ移す。

初期の act() 指示はここまで狭くできる。

Open the assigned payer portal with the approved workflow account, use only the search fields supplied by the controlled workflow input, capture eligibility status, plan name, and effective date, and stop immediately if the returned record does not match the expected identifiers, MFA is requested outside the approved flow, or the page layout no longer matches the reviewed path.

ワークフロー結果はチャット返答ではなく契約として扱う。示例出力はこれくらい小さくてよい。

{
  "status": "needs_review",
  "capturedFields": {
    "eligibilityStatus": "active",
    "planName": "example-plan",
    "effectiveDate": "2026-05-01"
  },
  "exceptionReason": "manual_review_required",
  "reviewRequired": true
}

構築前に停止条件と出力 schema を定義できないなら、そのワークフローは最初の HIPAA スコープ試験導入には広すぎる。

省略してはいけないデータ境界

Nova Act のデータ処理には専用チェックリストが必要だ。ブラウザエージェントは API 連携にはない成果物を作るからだ。2026-05-22 時点で、AWS の Nova Act 暗号化ドキュメント は Agent Trajectory を一時データと説明しており、入力プロンプト、訪問ページのスクリーンショット、エージェント応答を含む場合がある。

HIPAA スコープ実行の前に、次の境界を設定する。

Nova Act は HIPAA スコープ作業にまだ使える。最初の設計では、モデル信頼性を議論する前に、プロンプト、スクリーンショット、成果物、ログに現れる情報を最小化する。

実用的な Nova Act 展開パターン

最初の本番に近い展開では、エージェントは反復的な中間部分を担当し、人間は承認と例外を担当する。

最初の展開を次のようにモデル化する。

医療では、より大きな失敗モードは静かなズレだ。誤った患者コンテキスト、古いポータル前提、不完全な監査証拠がそれに当たる。

ePHI を扱うブラウザエージェントのガードレール

ワークフローが ePHI に触れる可能性があるなら、最初の設計は保守的にする。

最初の設計に次のガードレールを入れる。

• 専用の HIPAA スコープ AWS アカウントまたは環境境界を使う
• ワークフローを指定ポータルと指定タスク種別に限定する
• 実行に必要な最小項目だけを渡す
• 可能な限り患者識別子を act() テキストや他の自由記述指示に入れない
• ページ状態が見慣れないときの明確な停止条件を求める
• 未承認の宛先への自由なデータ書き出しをブロックする
• ワークフロー開始、承認、例外、最終結果を記録する
• 認証情報とシークレットはワークフローコードに埋め込まず、標準 AWS 統制でローテーションする

Nova Act が魅力的なのは、同じワークフロー内で自然言語と Python を組み合わせられるからだ。その柔軟性は有用だが、チームはワークフローのどこが決定的で、どこでモデルに即興判断を許しているかをレビューする必要がある。HIPAA スコープ作業では即興判断の余地をできるだけ小さくする。

Nova Act が従来型 RPA より良い場面

従来型 RPA ツールより Nova Act を優先するのは、狭い条件に限る。ワークフローが壊れやすいセレクターには変動しすぎて UI 自動化が壊れやすい一方、人間が明確な目標とエスカレーション規則を定義できる程度には構造化されている場合だ。

スクリプト中心の自動化より Nova Act を選ぶ条件：

• ポータル画面が頻繁に変わり、壊れやすいセレクターの維持コストが高い
• スタッフが API ではなく見えている UI コンテキストから作業している
• ワークフローに必要なのは軽い解釈で、深い領域判断ではない
• 成功、失敗、エスカレーション状態を明確に定義できる

従来型の連携またはルールエンジンを選ぶ条件：

• システムに安定した API がすでにある
• タスクが決定的で、LLM なしでも簡単にモデル化できる
• コンプライアンスポリシーが最小限のモデル利用範囲を要求している
• ブラウザ実行のコストが単純な API 呼び出しに見合わない

2026-05-22 時点で、Amazon Nova pricing page は Nova Act ワークフロー実行時間をエージェント時間課金として示し、人間の入力を待っている時間は課金されないとしている。これは予算見積もりの材料にとどめる。高リスクワークフローを自動化する理由にはしない。安定 API がより安く、より少ない成果物でタスクを終えられるなら、そこから始める。

Amazon Connect Health が合う場合

Nova Act はブラウザエージェントの選択肢だ。実際の目的が、より大きな医療コンタクトセンター、EHR 連携、患者アクセスワークフローであるなら、ブラウザ自動化を設計に押し込む前に Amazon Connect Health と比較する。

最初のアーキテクチャレビューでは次の切り分けを使う。

一時停止すべきレッドフラッグ

テスト中に次が出たら展開を止める。

• オペレーターが正確なワークフロー境界に合意できない
• 同じタスクに、書面化されていない判断が頻繁に必要になる
• ポータルごとに同じ項目の解釈が変わる
• チームに例外キューの担当者がいない
• ログが不完全、またはすぐレビューできない
• 唯一の成功指標が “demo ではよく見えた” になっている

これらはまずプロセスの問題だ。Nova Act はそれを解決せず、増幅する。

14日間の試験計画

最初の 2 週間は狭く保つ。

1〜3日目：コンプライアンスと範囲

• BAA と HIPAA アカウント設定を確認する
• Nova Act の region fit と環境境界を確認する
• 書面化されたチェックリストとエスカレーション経路があるワークフローを 1 つ選ぶ
• 試験導入が絶対にしないことを定義する

4〜7日目：ワークフロー構築と dry run

• テストデータまたは低リスクデータでブラウザワークフローを実装する
• success、failed、needs_review、portal_changed などの構造化出力を定義する
• 量を増やしたテストの前にログ記録とレビュアーアクセスを追加する
• 例外を見えないところで回避せず、すべて記録する

8〜11日目：監督付き実地試験

• 低リスクタスクで小さなバッチを実行する
• 処理時間、失敗理由、レビュアー工数を手作業プロセスと比較する
• 失敗がポータル変更、入力不足、弱いワークフロー境界のどれから来ているかをレビューする

12〜14日目：続行または停止の判断

• ワークフローが境界明確でレビュー可能な場合だけ拡張する
• プロセスがまだ文書化されていない判断に依存しているなら停止する
• 最良の結果が部分自動化と手作業完了の組み合わせなら再設計する

拡張前にハードゲートを使う。

提出がまだ人間の判断に依存するなら、最初の本番リリースはデータ取得またはステータス取得で止める。

FAQ

Amazon Nova Act は今、自動的に HIPAA に準拠するのか？

いいえ。2026-05-22 時点で、AWS は Nova Act を HIPAA eligible としている。これは AWS のコンプライアンス枠組みの下で HIPAA スコープのワークロードに使えるという意味だ。組織はアカウント、アクセス制御、ログ、暗号化、運用プロセスを正しく設定する必要がある。

医療チームに最適な最初の Nova Act ワークフローは？

安定したチェックリストと回復可能な失敗モードがすでにある反復的なブラウザワークフローから始める。保険資格確認、請求ステータス確認、紹介ステータス確認などが該当する。最初の展開ではオープンエンドな臨床または財務判断ワークフローを避ける。

Nova Act は規制対象ワークフローの人間のオペレーターを置き換えるべきか？

いいえ。より安全なモデルは監督付き自動化だ。エージェントには反復的なブラウザ作業を任せ、人間が承認、例外、ポリシー上重要な判断を担当する。

いつ Nova Act を使わないべきか？

タスクに安定 API がすでにある場合、1 つの誤操作が許容できない法務または患者リスクを生む場合、またはチームが明確な停止条件と例外キューをまだ定義できない場合、Nova Act から始めない。

Nova Act playground で実患者データをテストできるか？

最初の医療展開では、できない。Playground と API キー経路では合成データまたは非識別化データを使う。real ePHI は IAM、ログ、データ保持、レビュアー統制が承認された後、BAA-covered AWS アカウント経路にだけ置く。

検証メモ

公式ソースを 2026-05-22 に確認：

• AWS Machine Learning Blog: Amazon Nova Act is now HIPAA eligible
• AWS Docs: What is Amazon Nova Act?
• AWS Docs: Getting started with Amazon Nova Act
• AWS Docs: Data protection in Amazon Nova Act
• AWS Docs: Encryption at rest in Amazon Nova Act
• AWS Docs: Logging Amazon Nova Act API calls with AWS CloudTrail
• AWS Compliance: HIPAA Eligible Services Reference
• AWS Compliance: Shared Responsibility Model
• AWS Pricing: Amazon Nova pricing
• AWS: Amazon Connect Health