当社がすでに HIPAA コンプライアンスモードを有効化している場合、理論上は Cowork で患者関連の事務作業（具体的なカルテ内容は含まない）を安心して処理できるということですか？
そのような運用は推奨されない。HIPAA コンプライアンスモードを有効化することがカバーするのは Enterprise の Chat インターフェースであり、Cowork には自動的には拡張されない。この点は公式ドキュメントが明確に除外している。ある事務作業について「具体的なカルテ内容は含まない」と考えていても、患者の氏名、予約時間、保険情報といった個人を特定できる情報に触れる瞬間、それはすでに PHI の範疇に入る。そして Cowork はどれだけ主観的にリスクが低いと判断していても、BAA の保護下には一切ない。
より保守的で安全な判断方法は、「この作業が患者を特定できる情報に少しでも触れる可能性があるか」を唯一の判断基準とすることであり、「これは本当のカルテ内容に該当するか」を自分で判断することではない。可能性があると答えが出た場合は、Cowork を使い続けるのではなく、HIPAA コンプライアンスモードを有効化した Chat インターフェースで処理すべきだ。
Cowork が明確に BAA の対象外である以上、Anthropic は Cowork での Covered Models の使用そのものを完全に禁止しているのですか？
完全な禁止ではない。これはあの公式説明の中で誤読されやすい点だ。原文は「Claude Code や Cowork 内で Covered Models を BAA の対象外で使用することはできるが、そこに保護対象保健情報を入力してはならない」と書かれている。つまり利用そのものは許可されており、実際に明確な一線が引かれているのは「PHI を入力する」という特定の行為であって、「Cowork というツールを使うこと」自体ではない。
この区別は実務上重要だ。組織に PHI にまったく触れない一般的なナレッジワーク（社内の会議メモの整理、患者情報を含まない運営レポートの作成など）があれば、それらの作業はこの制約の影響を受けず、引き続き Cowork で問題なく行える。本当に注意が必要なのは、業務内容そのものが患者データに触れるワークフローだ。こうしたワークフローは、どれだけ慎重に扱っていても、データが本質的に PHI である以上、すでに BAA の保護範囲外での開示に該当してしまう。
当社が AWS Bedrock や Google Cloud Vertex AI 経由でデプロイされた Claude を使っている場合、この制約は依然として適用されますか？
この記事で扱っている制約は、Anthropic が直接締結する BAA を指しており、Anthropic 自身のチャネル（1P API、Claude Enterprise）経由で Claude を利用する場合に適用される。組織が AWS Bedrock や Google Cloud Vertex AI 経由で Claude をデプロイしている場合、それはまったく別のコンプライアンス経路をたどっている——データ処理契約は Anthropic と直接ではなく AWS や Google Cloud と締結され、それらのクラウドプラットフォーム自身の HIPAA コンプライアンスの仕組みが適用される。
しかしこれは同時に、次のことも示唆している。Cowork の現在のプロダクトとしての位置づけは、本質的に Anthropic 自身のデスクトップアプリとアカウント体系に紐づいて動作するものだ。組織が AWS Bedrock や Vertex AI のようなサードパーティのクラウドプラットフォーム経由で Claude をデプロイしている場合、それは通常、Cowork というデスクトップエージェント製品そのものではなく、API レベルの統合を利用していることを意味する。言い換えれば、この特定の制約は、クラウドプラットフォーム経由でデプロイしている組織にとってはもともと関連性が限定的である可能性がある。とはいえ、Cowork という特定の製品が自社のデプロイアーキテクチャの下で利用可能かどうか、またどの契約によって規定されるかは、クラウドパートナーまたは Anthropic の営業担当に直接確認することを推奨する。
チームがここ数か月、PHI に触れる可能性のある作業をすでに Cowork で行っていて、今になってこの制約に気づいた場合、どう是正すればよいですか？
まず慌てないこと。最初のステップは、過去の利用状況を正直に棚卸しすることだ——具体的にどのタスクで、どの程度の患者情報が関わっていたか、どのメンバーが操作していたか。この棚卸し作業自体が、印象で推測するのではなく、実際の露出範囲と深刻度を把握する助けになる。組織が Enterprise プランであれば、Compliance API や既存の OpenTelemetry ストリーミング記録を通じて、具体的なタスク内容とタイミングを遡って確認できる。
棚卸しが完了したら、より現実的な次のステップは、組織内のコンプライアンスまたはプライバシー担当部署に相談し、この状況が正式な報告を必要とする事案に該当するかを評価することだ——これはコンプライアンスレベルの判断であり、この記事があなたに代わって結論を出せる部分ではない。同時に、今後 PHI に関わる作業は直ちに HIPAA コンプライアンスモードを有効化した Chat インターフェースに切り替え、「Cowork は患者情報に関わる可能性のあるタスクには使用できない」という境界線をチームに明確に伝え、同じ状況が再発しないようにする。この対応は早ければ早いほど、是正できる余地も通常大きくなる。
あなたの組織が保護対象保健情報（PHI）を扱っているなら、Claude Cowork を使うかどうかを決める前に確認しておくべきことが1つある。どのプランの等級を使っていても、Cowork は現時点で Anthropic の HIPAA 事業提携契約（BAA）の対象外だという点だ。これは Enterprise プランで何らかの設定が有効になっていないという話ではなく、Anthropic 自身のドキュメントが、Cowork はどのような設定であっても BAA の下での対象サービス（Eligible Service）ではないと明確に述べている。本記事では、この一文が具体的に何を意味するのか、そして業務内容が PHI に触れる可能性がある場合にどう対応すべきかを整理する。
Anthropic のドキュメントには、一語一語引用する価値のある一文がある：Cowork はどのような設定であっても BAA の下での対象サービスではない——Claude Code や Cowork 内で Covered Models を BAA の対象外で使用することはできるが、そこに保護対象保健情報を入力してはならない。鍵となるのは「どのような設定であっても」という部分だ。つまり、何らかの設定を調整したり高度なオプションを有効にしたりすることで Cowork を BAA の保護下に入れる方法は存在せず、アーキテクチャのレベルで除外されている。
この点は特に誤解されやすい。HIPAA-ready の Enterprise プランは、Claude の通常のチャット機能については確かにカバーできるからだ——Enterprise のプライマリーオーナーは組織設定の「Data and Privacy」から HIPAA コンプライアンスモードを直接有効化し、BAA を承認できる。有効化後は、通常の Chat インターフェースは標準的なデータ保持ポリシーの下で Covered Models を追加の設定変更なしに使用できる。しかし公式ドキュメントは特に、HIPAA readiness を有効にすること自体は Claude Code や Cowork を一緒に BAA の対象に含めるわけではないと注意を促している——Claude Code は Zero Data Retention（ZDR）を追加で有効化して初めて条件付きでカバーされるが、Cowork は ZDR を有効にしているかどうかに関わらず、完全に対象外のままだ。
Anthropic のドキュメントはこの除外の技術的な根拠を明示していないが、Cowork の実際の動作方法からこの制約の論理を推測することはできる。Cowork はパソコン内のローカルファイルを能動的に読み取り、MCP を介して認可済みの SaaS アプリケーション（Slack、Google Drive、Gmail、Notion、Jira など）に接続するエージェント型の製品だ。それが扱うデータソースは分散しており範囲も広く、どのコンテンツを読み取るかをエージェント自身が自律的に判断する。これは、Claude がユーザーが能動的に貼り付けた内容だけを処理する通常のチャットインターフェースのデータフローとは根本的に異なる。このような能動的でシステム横断的なアクセスアーキテクチャは、HIPAA が求めるデータ処理のコンプライアンス基準を満たすために、より高度な技術的・契約上の複雑さを伴うのが自然であり、これが Anthropic がまだ Cowork を BAA の対象に含めていない背景として妥当な理由と言える。
Claude Code の BAA カバー状況は、有用な対比を提供してくれる。CLI（公式 API コンソールまたは Enterprise OAuth 経由）と Desktop のローカルモードは、Zero Data Retention を有効にすればBAAの対象になり得るが、Desktop のリモートモード、ウェブ版、Code Review、Code Security といった他の形態は引き続き対象外だ。つまり Claude Code にとっての「BAA でカバーされる」は、設定と利用形態次第のスペクトラムであり、全か無かの話ではない。しかし Cowork の状況はより直接的だ——Anthropic 自身の文言は「どのような設定であっても対象サービスではない」であり、Claude Code のような「この設定を有効にすればカバーされる」という経路は存在しない。
これは Cowork がまったく使えないという意味ではない——Claude Code や Cowork 内で Covered Models を使用すること自体は可能で、ただそこに PHI を入力してはいけないだけだ。この一文が引いているのは明確な利用境界線だ。業務内容が患者データ、健康記録、保険情報といった保護対象情報にまったく触れないのであれば、それ以外の一般的なナレッジワークのタスクに Cowork を使うことはこの制約の影響を受けない。しかし業務内容が PHI に触れる可能性がある瞬間——患者の氏名を1つの質問と一緒に Cowork に貼り付けるだけであっても——それはすでに BAA の保護範囲外でのデータ開示に該当し、どれだけ注意深く精密に設定していたかとは無関係だ。
組織が HIPAA の対象事業体（covered entity）またはビジネスアソシエイトである場合、まず最初にすべきことは、チーム内の誰が、どのワークフローで実際に Cowork を使っているかを正直に棚卸しし、それらのワークフローが PHI に触れる可能性があるかどうかを評価することだ。多くの場合、リスクは意図的に患者データを貼り付けることから生じるのではなく、Cowork に会議メモの要約やレポートの作成を頼んだ際に、他の情報と一緒に PHI が偶発的に読み込まれてしまうことから生じる。評価の結果、PHI 露出の可能性が実際にあると判明した場合、より現実的な対応は、そのワークフローを BAA の対象となるインターフェース（HIPAA コンプライアンスモードを有効にした Enterprise Chat など）に戻し、Cowork は PHI にまったく触れない一般的な業務に限定して使うことだ。あるワークフローが安全かどうか確信が持てない場合、最も保守的で誤りの少ない判断は、PHI 露出の可能性を明確に排除できるまでは安全でないと仮定しておくことだ。