Claudeのstrict tool useとHIPAA/PHI — スキーマに書いてはいけない理由
strict tool useはHIPAA対応ですが、コンパイル済みスキーマは24時間キャッシュされプロンプトと同じPHI保護を受けません。書いてはいけない4箇所と、HIPAA readinessが及ぶ範囲です。
このTipsでできること
医療系のアプリでstrict tool useを使う場合、最初に押さえておきたいのは「HIPAA対応かどうか」ではなく「PHIをどこに書くか」です。strict tool useはHIPAA readinessの対象機能ですが、コンパイル済みのツールスキーマはメッセージ本文とは別枠でキャッシュされ、最大24時間保持されます。この仕組みが、PHIの扱いに直接影響します。具体的にどこにPHIを書いてはいけないのか、そしてHIPAA readinessとZero Data Retention(ZDR)という2つの枠組みがどう違うのかも扱います。
strict tool useとPHIの関係 — なぜスキーマが特別扱いされるか
strict tool useは、input_schemaをコンパイルしてグラマー(文法制約)を生成し、そのグラマーでモデルの出力を制約します。このコンパイル済みグラマーは、メッセージ本文(プロンプトとClaudeの応答)とは別のキャッシュ機構で保持されます。プロンプトとレスポンスがAPIレスポンスを返した時点で保持されない設計になっているのに対し、コンパイル済みスキーマは直近の利用から最大24時間キャッシュされます。同じスキーマを使ったリクエストが来たときに、毎回コンパイルし直さずに済むようにするための最適化です。
キャッシュの目的自体は速度向上であり、悪意のある設計ではありません。ただし、キャッシュされる対象がメッセージ本文と別枠である以上、メッセージ本文に適用されるのと同じ保護がこのキャッシュには及びません。ここがPHIの扱いで問題になります。
PHI(protected health information、保護の対象になる保健情報)は、個人を特定できる健康情報全般を指します。公式ガイドラインは、workspace名・ユーザー情報(氏名・メールアドレス・電話番号)・請求データ・サポートチケットは通常PHIを含まないものとして扱われる、とも明記しています。逆に言えば、患者の氏名・診断名・保険番号・カルテ番号のような値は、メッセージ本文であっても取り扱いに注意が必要なデータであり、スキーマの定義部分に置くのは論外だという位置づけです。
PHIを書いてはいけない4箇所
strict tool useはHIPAA readinessの対象機能です。ただし公式ドキュメントは明確に線を引いています。保護の対象になる保健情報(PHI)を、ツールスキーマの定義に含めてはいけません。具体的には次の4箇所です。
input_schemaのプロパティ名enumの値constの値patternの正規表現
これらはいずれも、スキーマそのものの一部としてグラマーにコンパイルされ、24時間キャッシュの対象になります。たとえば患者の実名をenumの選択肢に埋め込む、疾患名をpatternの正規表現に直接書く、といった設計はこの禁止事項に触れます。
PHIが許されるのは、プロンプトとClaudeの応答というメッセージ本文の中だけです。患者名・診断名・保険番号のような具体的な値は、ツール呼び出しのinput(実行時に生成される値)としてやり取りする分には問題ありません。ユーザーのメッセージやClaudeの応答テキストとして扱う分にも、通常のHIPAAセーフガードが及びます。スキーマの構造(どんなプロパティがあり、どんな型で、どんな選択肢があるか)を定義する部分と、スキーマに従って実際にやり取りされる値は、扱いが違うということです。
具体的には、次のような書き方の違いになります。
{
"properties": {
"patient_name": { "type": "string" },
"diagnosis_code": {
"type": "string",
"enum": ["E11.9", "I10", "山田太郎の糖尿病"]
}
}
}enumの3つ目の選択肢に、特定の患者名を含む値を直接書き込んでいます。これはスキーマの一部としてコンパイル・キャッシュされるため、避ける必要があります。enumに置いてよいのは、ICD-10のような一般に公開された分類コードだけです。患者名のような値はenumの選択肢に置かず、実行時に渡されるpatient_nameの値としてやり取りします。
strict: trueだけでなく構造化出力にも共通する制約
同じ制約は、output_config.formatを使う構造化出力(JSON outputs)にも及びます。Agent SDKの構造化出力でエージェントの最終応答をJSON Schemaに固定する場合も同じです。そのJSON Schema自体が同じグラマーコンパイルパイプラインを通るため、スキーマ側にPHIを書かないという原則が同じように適用されます。両機能は「Claudeの応答形式を固定するか」「ツールの入力形式を固定するか」という適用対象が違うだけです。コンパイル済みスキーマのキャッシュ挙動とPHIの扱いは共通しています。
HIPAA readinessとZDRは別の枠組み
Claude APIのデータ保持には、ZDRとHIPAA readinessという別々の枠組みがあります。
| 枠組み | 何を約束するか | 前提条件 |
|---|---|---|
| Zero Data Retention(ZDR) | 何を約束するかAPIレスポンスを返した後、プロンプトとレスポンスを保存しない | 前提条件Anthropicの営業チームへの申請、組織単位で有効化 |
| HIPAA readiness | 何を約束するか暗号化・アクセス制御・監査ログなど、PHIのライフサイクル全体を通じた広範な安全対策 | 前提条件署名済みのBusiness Associate Agreement(BAA)、Claude Consoleでの組織単位の有効化 |
PHIを扱う組織が必要とするのは、即座の削除ではなく、この広範な安全対策です。公式ドキュメントは「PHIを扱うならHIPAA readinessを使う。ZDRを追加で有効化する必要はない」と明言しています。両者は別の目的を持つ別の枠組みで、どちらか一方を選ぶという単純な話でもありません。ZDRがどの契約形態で有効になるかという範囲の切り分けはClaude Zero Data Retentionが有効になる契約形態の切り分けにまとめてあります。
なお、ZDRとHIPAA readinessはモデルの選択でも交差します。Claude Fable 5.1・Claude Mythos 5.1・Claude Fable 5・Claude Mythos 5は30日間のデータ保持が必須の対象モデルです。Anthropicから明示的な許可がない限り、これらのモデルはZDRの対象になりません。strict tool useをこれらのモデルと組み合わせる場合、ZDR組織であってもワークスペース単位で30日保持を個別に有効化する形になります。この点は、HIPAA readinessの要件と合わせて事前に確認しておきます。
HIPAA readinessが適用されるのはClaude API(api.anthropic.com)そのものです。次は対象外です。
- Claude Consoleのインターフェース経由の利用(Console設定でHIPAA readinessを有効化すること自体はできるが、Console経由でのPHI処理は対象外)
- Claude Platform on AWSとMicrosoft Foundry
- Claude Code
- ベータ機能(feature eligibilityの一覧で明示的に対象と書かれていない限り)
HIPAA非対応の機能を、HIPAA readinessが有効な組織から呼び出そうとすると、APIは400エラーを返してリクエストを止めます。
{
"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が内部的に使っている表現です。公式ドキュメントは別の箇所でZDRの追加有効化は不要としており、この表現もその方針と矛盾しません。
実務での対処
スキーマにPHIを書いてしまっている既存のツール定義があるなら、対処は「4箇所」節の禁止パターンをde-identification済みのコードに置き換えることです。プロパティ名をpatient_name_actualのような実データ寄りの名前からpatient_nameのような一般名に変え、enum・const・patternに埋め込まれた実データを削除して、対応する値はすべて実行時のinput側に移します。
HIPAA readinessが必要なら、Claude API経由の利用に絞ります。Claude ConsoleやClaude Codeでの利用は対象外なので、PHIを扱うワークフローはAPI呼び出しに一本化します。Consoleで動作確認する場合も、確認用のリクエストにPHIを含めず、ダミーデータでスキーマの挙動だけを検証してから本番のAPI呼び出しに切り替える順序にすると、意図せずPHIがConsole経由の処理に混ざるのを防げます。
ツール定義そのものの設計原則(命名・粒度・レスポンス設計)はエージェント向けツール設計の原則で扱っています。PHIを避ける設計は、この一般的な設計原則の上に「スキーマの構造部分に実データを混ぜない」という制約を1つ足すだけで済みます。
まとめ
strict tool useはHIPAA readinessの対象機能ですが、コンパイル済みのツールスキーマはメッセージ本文とは別枠で最大24時間キャッシュされ、プロンプトやレスポンスと同じ保護を受けません。PHIを書いてはいけないのはinput_schemaのプロパティ名・enumの値・constの値・patternの正規表現の4箇所で、PHIが許されるのはメッセージ本文だけです。同じ制約は構造化出力にも共通します。HIPAA readinessとZDRは別の枠組みで、PHIを扱う組織はHIPAA readinessを使い、ZDRを重ねて有効化する必要はありません。適用範囲はClaude APIに限られ、Console・Claude Platform on AWS・Microsoft Foundry・Claude Codeは対象外です。PHIを扱うワークフローを設計するときは、この適用範囲の境界線を先に引いてから、スキーマの構造にPHIが紛れ込んでいないかを最後に確認する順番が、手戻りの少ないやり方です。