Claude HIPAA自動設定、日本の医療AI導入条件

Anthropic は 2026年7月14日の Claude release notes で、Claude 組織の HIPAA configuration を self-serve にしたと発表した。対象は Claude Enterprise と Claude Platform API の両方で、eligible admin が Business Associate Agreement、つまり BAA を確認し、implementation guide をダウンロードし、HIPAA configuration を一つの flow で有効化できる。

これは米国 HIPAA の話なので、日本企業には遠く見えるかもしれない。しかし実務上は、医療、ヘルスケア、保険、製薬、臨床研究、健康データを扱う AI サービスにとって重要な更新である。Claude を患者情報や健康情報の処理に使う場合、単に「高性能なモデルを使う」ではなく、契約、対象機能、ログ、データ入力範囲、外部ツール接続を分けて設計する必要があるからだ。

今回の更新は、Claude Compliance API統合 や Claude Access TransparencyとCMEK保全 と同じ流れにある。Claude は、生成機能だけでなく、企業が監査・契約・データ保護を説明するための管理面を広げている。さらに Claude Enterprise管理API と組み合わせると、誰に HIPAA-ready な環境を使わせ、どの組織を一般用途と分けるかが実務課題になる。

事実: 7月14日に何が変わったか

Claude Help Center の release notes は、HIPAA configuration for Claude organizations が self-serve になったと説明している。従来のように営業・契約窓口だけで進めるのではなく、対象となる管理者が、Claude Enterprise と Claude Platform API それぞれで HIPAA readiness を管理できるようになったという位置づけである。

Enterprise 向けの記事では、HIPAA-ready Enterprise plans は Enterprise plan の組織向け機能であり、protected health information、PHI を Claude で処理する組織が使うものと説明されている。対象として想定されるのは、healthcare providers、health plans、healthcare data processors、その business associates である。BAA、機能、safeguards を含み、組織の HIPAA compliance requirements を支える設計だとされている。

API 側の documentation では、HIPAA readiness は Claude API で PHI を処理するための arrangement として説明されている。signed BAA と HIPAA-enabled organization が前提で、eligible organizations は Claude Console から BAA を確認・実行し、HIPAA readiness を直接有効化できる。これは API を使う自社アプリ、医療事務支援、保険審査、研究支援プロダクトに関係する。

もう一つ重要なのは、有効化の重さだ。API documentation は、HIPAA readiness を有効にすると organization level で適用され、管理者が後から無効化できないと説明している。つまり、試しに押して戻す設定ではない。日本企業が検証する場合でも、本番組織、検証組織、一般用途組織を分けてから有効化するべきである。

事実: EnterpriseとAPIで対象範囲が違う

Claude Enterprise と Claude API は、同じ「Claude」でも運用面が違う。Enterprise は従業員が Claude の画面、プロジェクト、ファイル、組織設定を使う場に近い。API は自社アプリや業務システムから Claude を呼び出す基盤に近い。HIPAA-ready の意味も、この二つで確認点が変わる。

API documentation は、HIPAA readiness が Claude API の eligible features に適用されると説明している。一方で、consumer products、Console / Workbench での PHI 処理、partner-operated platforms、Claude Platform on AWS、Microsoft Foundry、third-party integrations、Claude Code、beta features などは対象外または条件付きで扱われる。API は非対象機能を含む request を 400 error で止める設計も説明している。

Enterprise 向けの記事でも、すべての Claude 関連機能が同じように覆われるわけではない。Claude Code の Team / Enterprise plan 記事は、HIPAA-ready Enterprise plan に含まれる seat で Claude Code を使えるが、Claude Code は HIPAA-ready offering の対象外だと明記している。医療系スタートアップや病院グループが、開発者向け Claude Code と医療情報を扱う Claude Enterprise を同じアカウント感覚で混ぜると、契約上の前提を誤る。

Anthropic の healthcare and life sciences 発表では、Claude for Healthcare が HIPAA-ready products を通じて医療目的で使える tools and resources として紹介されていた。今回の self-serve 化は、その医療・ライフサイエンス向けの導入を管理者が進めやすくする更新だと読める。ただし「医療に使える」と「どの機能でも PHI を入れてよい」は別である。

分析: 日本ではHIPAAより患者情報統制が焦点になる

ここからは分析である。

日本企業にとって HIPAA は直接の国内法ではない。だが、米国患者データ、米国法人、米国医療機関との共同事業、米国向けヘルステック SaaS、グローバル製薬の臨床業務に関わるなら、BAA と HIPAA-ready environment は商談や監査で現実の論点になる。日本から米国向け医療 AI を作る企業にとっては、モデル選定のチェックリストに入る。

国内向けだけでも意味はある。患者情報、健康診断データ、服薬履歴、相談内容、介護記録、保険請求情報、研究参加者データは、AI に入れてよいかを慎重に分ける必要がある。HIPAA-ready の self-serve flow は米国制度向けだが、「契約を結ぶ」「対象機能を限定する」「非対象機能を止める」「PHI の置き場所を決める」という設計は、日本の医療・ヘルスケア AI にもそのまま参考になる。

特に、医療現場では「文章を要約するだけ」「問い合わせを分類するだけ」「診療補助ではない」と説明しても、入力に患者情報が含まれるならデータ保護の問題は残る。Claude の HIPAA readiness は、モデルの医療判断能力を保証するものではなく、PHI を扱うための契約・技術・運用の枠組みである。診断、治療方針、薬剤選択、保険判断を AI が単独で決めてよいという意味ではない。

したがって、日本企業が見るべきポイントは、HIPAA という名前より、医療 AI の「処理環境を一般用途から分ける」ことだ。一般業務の Claude、開発者の Claude Code、医療情報を扱う Claude Enterprise / API、クラウド provider 経由の Bedrock や Vertex AI を同じ承認でまとめない。ここを分けないと、監査時にどのデータがどの契約・機能・ログに載ったのか説明しにくくなる。

実務: 有効化前に分ける四つの境界

第一に、organization を分ける。API documentation は、HIPAA readiness が organization level で適用されると説明している。一般用途と PHI 用途を同じ organization に混ぜると、対象外機能の制限、開発者の利便性、監査ログ、請求、権限管理がぶつかる。PHI を扱う API access と、通常の開発・実験用 access は別 organization にするのが現実的だ。

第二に、機能を分ける。Claude API の feature eligibility table では、Messages API の一部機能は HIPAA eligible でも、Agent Skills、Batch processing、Claude Managed Agents、Code execution、Files API、MCP connector などは対象外として整理されている。医療 AI の設計では、便利な agentic 機能を先に積むのではなく、PHI を入れる request path で許される機能だけを明示する必要がある。

第三に、ユーザーとロールを分ける。Enterprise で HIPAA-ready offering を使うなら、誰が有効化できるのか、誰が PHI を含む project に入れるのか、誰が connector を設定できるのかを決める。ここは Claude Enterprise管理API の棚卸しと接続する。医療情報を扱うユーザー、一般部門ユーザー、開発者、外部委託先、監査担当を同じ group に入れるべきではない。

第四に、ログと監査を分ける。HIPAA-ready であることと、事故時に説明できることは同じではない。誰が PHI を入れたか、どの API key が使われたか、どの feature が拒否されたか、どの管理者が BAA を受け入れたか、どのデータが外部 tool に渡ったかを記録する必要がある。ここは Claude Compliance API統合 の DLP / SIEM / Purview 連携の論点と重なる。

注意点: Claude Codeと外部ツールを混ぜない

今回の更新で最も誤解しやすいのは、Claude Enterprise の seat に含まれる機能をすべて HIPAA-ready と見なしてしまうことだ。Claude Code は Enterprise seat で使える場合があるが、HIPAA-ready offering の対象外と説明されている。医療系プロダクトの開発リポジトリに PHI を含む fixture、ログ、スクリーンショット、問い合わせ本文が混ざる場合、Claude Code の利用可否は別途判断が必要になる。

API でも同じだ。Code execution、MCP connector、Managed Agents、Batch processing、Files API のような便利機能は、PHI を扱う本番 request path では対象外になり得る。AI エージェントが業務システムや外部サービスへ接続する設計では、どの tool が PHI を見るのか、どの transcript が保存されるのか、どの external service が data processor になるのかを確認しなければならない。

さらに、Claude Cowork や Microsoft 365 connector のような業務操作系機能とも分けて読む必要がある。Claude CoworkとM365書き込み権限 で整理したように、AI がメール、予定、ファイルを操作できるようになると、データ保護だけでなく誤操作や承認証跡が問題になる。医療情報を扱う部門では、read-only connector と write action の境界をさらに厳しく切るべきだ。

まとめ

Claude の HIPAA self-serve configuration は、医療向けの小さな管理画面更新ではない。Anthropic が Claude Enterprise と Claude API を、PHI を扱う組織向けの契約・機能制限・管理 flow に載せやすくした更新である。

日本企業が見るべきポイントは、米国 HIPAA 対応の有無だけではない。患者情報や健康データを AI に入れる場合、一般用途の organization、開発者向け Claude Code、PHI 用 API、外部 connector、監査ログを分けられるかが導入条件になる。self-serve で有効化しやすくなったからこそ、有効化前に組織、機能、ロール、ログの境界を決めるべきである。

出典

• Release notes - Claude Help Center, 2026-07-14
• HIPAA-ready Enterprise plans - Claude Help Center
• API and data retention - Claude Platform Docs
• Use Claude Code with your Team or Enterprise plan - Claude Help Center
• Advancing Claude in healthcare and the life sciences - Anthropic, 2026-01-11