Claudeのstrict tool useとHIPAA/PHI — スキーマに書いてはいけない理由

このTipsでできること

医療系のアプリでstrict tool useを使うとき、最初に決めるのは「HIPAA対応かどうか」ではなく「PHIをどこに書くか」です。strict tool useはHIPAA readinessの対象機能ですが、コンパイル済みのツールスキーマはメッセージ本文とは別枠でキャッシュされ、最大24時間保持されます。

扱うのは、PHIを書いてよい場所と書けない場所の線引きです。併用できる機能とできない機能も並べます。さらに、HIPAA readinessとZero Data Retention(ZDR)の違い、有効化後に出るエラーの読み方まで進みます。

スキーマに書いてよい値と、書いてはいけない値

PHI(protected health information、保護対象の保健情報)は、個人を特定できる健康情報全般を指します。strict tool useでは、input_schemaをコンパイルしてグラマー(文法制約)を作り、そのグラマーでモデルの出力を制約します。このグラマーはメッセージ本文とは別に保持されるため、プロンプトやレスポンスと同じPHI保護を受けません。

線引きは「スキーマの構造」と「実行時に流れる値」の違いです。

具体例を見ると違いが分かります。次のスキーマは、enumの3つ目に特定の患者名を含む値を書き込んでいます。

{
  "properties": {
    "patient_name": { "type": "string" },
    "diagnosis_code": {
      "type": "string",
      "enum": ["E11.9", "I10", "山田太郎の糖尿病"]
    }
  }
}

この3つ目の選択肢はスキーマの一部としてコンパイルされ、キャッシュの対象になります。enumの値にPHIは入れません。E11.9のような公開の分類コードは患者固有の情報ではない、という例です。患者名はpatient_nameの実行時の値として渡します。

患者の氏名や診断名のほか、添付ファイルのファイル名やメタデータにもPHIが入りえます。一方、workspace名・ユーザー情報(氏名・メールアドレス・電話番号)・請求データ・サポートチケットは、BAAのもとでPHIを含むとは想定されていない項目です。

構造化出力にも同じ制約がかかる

output_config.formatを使う構造化出力(JSON outputs)も、同じグラマーコンパイルのパイプラインを通ります。Agent SDKの構造化出力でエージェントの最終応答をJSON Schemaに固定する場合も、スキーマ側にPHIを書けない点は同じです。

違いは適用対象だけです。構造化出力は応答の形式を、strict tool useはツールの入力の形式を固定します。

キャッシュの保持期間はほかの保持と何が違うか

保持期間の数字は機能ごとに違い、並ぶと混同しやすいので、先に並べておきます。

スキーマがPHIを含まなければ、このキャッシュは問題になりません。

機能一覧でこの機能のZDRが「Yes」でなく「Yes (qualified)」とされているのも、このためです。プロンプトと出力は保存されませんが、機能が動くために必要な限られた技術データが、短い間だけ保持されるという意味です。ここで言う技術データが、strict tool useではスキーマにあたります。HIPAA側は条件なしの「Yes」です。

同じ組織でstrict tool useと併用できる機能

HIPAA readinessは組織単位で有効になります。strict tool useを組み込む前に、併用したい機能がHIPAAの対象かどうかを見ておくと、後から設計をやり直さずに済みます。

見落としやすいのは、バッチ処理です。大量のカルテ文書をstrict tool useで構造化したくなる場面でも、Batch processingがHIPAA対象外なので、HIPAA readinessの組織ではリクエストが通りません。PHIを含む構造化抽出は、Messages APIを呼び出す形で組みます。

HIPAA readinessとZDRは別の枠組み

Claude APIのデータ保持には、ZDRとHIPAA readinessという別々の枠組みがあります。

PHIを扱う組織に必要なのは、即時の削除よりも広範な安全対策です。公式ドキュメントはPHIを扱うならHIPAA readinessを使うとし、ZDRを重ねて有効化する必要はないとしています。ZDRがどの契約形態で有効になるかは、Claude Zero Data Retentionが有効になる契約形態の切り分けにまとめています。

HIPAA readinessを有効にする流れ

標準のBAAなら、Claude Consoleから自分で有効化できます。個別条件のBAAが必要な組織や、セルフサービスの有効化が使えない組織は、営業チーム経由になります。

同じ組織でHIPAAのワークロードとそうでないワークロードを混在させることはできません。HIPAA readinessが不要な処理は、別の組織に分けます。

Covered Modelsを使うときの注意

Claude Fable 5.1・Claude Mythos 5.1・Claude Fable 5・Claude Mythos 5は、30日間のデータ保持が必須のCovered Modelsです。Anthropicの明示的な許可がない限り、ZDRの対象になりません。

ZDR組織でこれらのモデルを使うには、ワークスペース単位で30日保持を有効にします。有効にしていないワークスペースからFable 5を呼ぶと、次の400エラーが返ります。

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "In order to access this model, your organization or workspace must have data retention enabled."
  }
}

HIPAA readinessが及ぶ範囲と、対象外になる使い方

HIPAA readinessが適用されるのは、Claude API(api.anthropic.com)の対象機能だけです。次の使い方は対象外です。

• Claude Consoleのインターフェース経由の利用(Consoleで有効化はできるが、Console経由でのPHI処理は対象外)
• Claude Free・Pro・Maxのコンシューマー向けプラン
• Amazon BedrockとGoogle CloudのAgent Platform(それぞれのコンプライアンス文書を参照する形になる)
• Claude Platform on AWSとMicrosoft Foundry
• Claude Code
• ベータ機能(機能の対象一覧で明示的に対象とされているものを除く)
• アプリケーションに接続した外部のツール・サービスが処理するデータ

BAAも、対象機能の最終的な根拠になります。APIの自動ブロックは補助で、BAAが正とされています。

非対応の機能を呼んだときのエラー

HIPAA readinessが有効な組織から非対応の機能を呼ぶと、次の形のエラーが返ります。

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "The requested features are not available for HIPAA-regulated organizations without Zero Data Retention: code_execution."
  }
}

エラーメッセージには対象外だった機能名(この例ではcode_execution)が並びます。その機能をリクエストから外して再試行します。メッセージ中の「without Zero Data Retention」はAPI側の言い回しで、対処は変わりません。

例外もあります。クライアント側で実行されるツールの一部は、機能一覧の備考欄に「ブロックされない」と書かれています。たとえばブラウザー操作ツールは、リクエストに含めても弾かれません。ただしHIPAA readinessの対象外のままなので、通ったからといってPHIを流してよいわけではありません。

契約があっても保持が残るケース

HIPAA readinessやZDRを結んでいても、データが完全に残らなくなるわけではありません。法的な要請がある場合と、Anthropicの自動の信頼性・安全性システムがチャットやセッションにフラグを立てた場合は、入力と出力が最大2年保持されることがあります。

PHIを扱う設計では、「プロンプトは保持されない」という前提を絶対のものとして置かず、この例外を含めて社内の説明を組み立てます。

もう1つ、保持の仕組みが別に動く領域があります。Compliance APIで取得できるデータは、独自の保持モデルに従います。HIPAA readinessを有効にした組織では、記録されるのはCoworkとClaude Codeのローカルセッションだけです。トランスクリプトは30日間保存されます。strict tool useのスキーマキャッシュとは別の話ですが、PHIを含む作業を開発者のローカル環境に持ち込むかどうかを決めるときに、押さえておく数字です。

既存のツール定義を見直すとき

スキーマにPHIを書いてしまっている既存のツール定義があるなら、4つの場所を順に点検します。

1. プロパティ名に、患者や症例を特定できる語が入っていないか
2. enumとconstに、実在の患者名・番号・診断メモが入っていないか
3. patternの正規表現に、特定の個人の識別子を直接書いていないか
4. 該当する値を、実行時に渡すinput側へ移せているか

患者名を選択肢に並べていた設計は、type: "string"のプロパティに置き換え、値の検証は呼び出す側のアプリケーションに持たせる、という設計になります。

PHIを扱うワークフローは、Claude API経由の呼び出しに絞ります。Consoleで動作を試すときは、スキーマの挙動の確認にとどめ、PHIを含まないダミーデータを使います。

ツール定義そのものの設計(命名・粒度・レスポンス)は、エージェント向けツール設計の原則で扱っています。PHIを避ける設計は、その上に「スキーマの構造にPHIを置かない」という制約を1つ足すだけです。

まとめ

大量のカルテをBatch processingで処理したい要件と、HIPAA readinessは同じ組織では両立しません。組織を分けるのか、バッチを諦めるのかは、有効化の前に決める論点になります。