医療系サイトのGCP IAM権限設計をClaude Codeで点検する: 個人情報を触らせない境界

クリニックの問い合わせフォームを直そうとしたら、制作会社、予約システム、広告運用者、院内スタッフの誰がGCPのどこまで見られるのか分からない。フォームのCSV、通知メール、Cloud Runの環境変数、ログ、問い合わせ履歴が同じ担当者の記憶に寄っています。

この記事では、医療系サイトのGCP IAMをClaude Codeで棚卸しし、個人情報を触らせない境界を作る流れを書きます。狙いは派手なクラウド構成ではありません。患者さんの名前、電話番号、相談内容、予約希望日が、不要な担当者やAIエージェントに流れない状態へ戻すことです。

この記事の要点

• 医療系サイトでは、問い合わせフォーム、予約フォーム、ログ、通知メール、管理画面の境界を先に分けます。

• Claude Codeには、IAMロール一覧、サービスアカウント、ログ出力先、環境変数、権限変更の差分表を作らせます。

• 人が見る範囲は、個人情報の該当性、院内ルール、委託先との契約、患者対応、公開前承認です。

• Google CloudのIAM、サービスアカウント、Cloud Audit Logs、Sensitive Data Protectionを、点検の材料として使います。

• ROIは、権限棚卸し時間、問い合わせCSVの閲覧者数、ログに残る個人情報の件数、公開前レビューの戻り回数で見ます。

現場で起きる失敗シーン

医療系サイトで怖いのは、フォームの画面だけきれいで、裏側の権限が古いまま残っている状態です。開院時に作った外部制作会社のOwner権限、退職した担当者のGoogleアカウント、広告代理店に渡した共有メール、検証用に作ったサービスアカウントが、そのまま残ります。

もうひとつの失敗は、ログを軽く見ることです。問い合わせフォームのエラー調査で、氏名、電話番号、相談内容、予約希望日を丸ごとログへ出すと、Cloud Loggingを見る人まで個人情報に触れます。GCP IAMで画面の権限を絞っても、ログやエクスポート先が抜け道になります。

参考にする公式情報は、Google CloudのIAMを安全に使うガイド、サービスアカウントのベストプラクティス、Cloud Audit Logs、Data Access audit logs、Sensitive Data Protection、個人情報保護委員会の医療・介護分野ガイダンスです。この記事は法務判断の代わりではなく、技術棚卸しの手順として読んでください。

• Google Cloud: Use IAM securely

• Google Cloud: Best practices for using service accounts securely

• Google Cloud: Cloud Audit Logs overview

• Google Cloud: Enable Data Access audit logs

• Google Cloud: Sensitive Data Protection overview

• 個人情報保護委員会: 医療・介護関係事業者向けガイダンス

業務フロー: 問い合わせフォームから権限を逆算する

最初に見るのはIAM画面ではありません。医療系サイトなら、患者さんが触るフォーム、院内に届くメール、予約システム、CRM、Google Cloudのログ、バックアップCSVを並べます。誰が何を見るかを、画面単位で書き出します。

たとえば、美容皮膚科の初回相談フォームなら、入力項目は名前、メール、電話、希望メニュー、相談内容、希望日時です。この時点で、制作会社が必要なのはフォームのHTMLと送信処理の修正であり、相談内容の本文を見る必要はありません。

次に、GCP側の資源を並べます。Cloud Run、Cloud Functions、Cloud Storage、Secret Manager、Cloud Logging、BigQuery、Pub/Sub、Cloud Build、ドメイン管理、通知用メールのどこにフォーム情報が触れるかを線でつなぎます。ここで初めてIAMロールを見ます。

| 見るもの | 棚卸しする項目 | 人が確認する点 |

| --- | --- | --- |

| 問い合わせフォーム | 入力項目、送信先、確認画面 | 相談内容が必要以上に長くないか |

| Cloud Run / Functions | 実行サービスアカウント、環境変数 | 個人情報をログへ出していないか |

| Cloud Logging | 閲覧者、保存期間、Data Access logs | 誰がログを読む必要があるか |

| Secret Manager | 通知APIキー、メール認証情報 | 制作担当者へ平文で渡していないか |

| BigQuery / CSV | 保存項目、閲覧者、エクスポート | 広告運用者が患者情報を見ないか |

医療系サイトでは、権限を「作業が早いから広めにする」で決めると後で戻せません。まず閲覧だけ、次に編集、最後に管理者権限という順で分けます。Google Cloud IAMの基本は、必要な人とサービスアカウントに、必要なロールだけを渡す考え方です。

Claude Codeに任せる範囲と人が見る範囲

Claude Codeに任せる範囲は、証拠を集めて表にする作業です。プロジェクト内のIAM policy、サービスアカウント一覧、Cloud Runの環境変数名、ログ出力箇所、TerraformやYAML、README、運用メモを読ませて、誰が何に触れるかを表にします。

人が見る範囲は、個人情報の判断と院内の承認です。問い合わせ本文が診療情報に近いか、広告代理店が見るべき範囲か、制作会社に本番ログを見せるか、患者対応の履歴をどこまで残すかは、院長、事務長、委託先責任者が決めます。

AIエージェントの権限も同じです。Claude CodeやCodexにGCPの資格情報を渡す前に、読み取り専用の棚卸し用権限、検証環境だけの権限、承認後にだけ使うデプロイ権限を分けます。Google CloudのIAM新機能でも、エージェントのアクセス管理と最小権限が話題になっています。医療系サイトでは、流行だから使うより、触らせない境界を先に決める方が合います。

3つのUse case

Use case 1: 退職者と外部委託先のIAMを棚卸しする

• 入力: gcloud projects get-iam-policyの出力、サービスアカウント一覧、制作会社と広告代理店の作業範囲、退職者リスト。

• 出力: メンバー、ロール、用途、最終確認日、削除候補、院内確認者を持つ棚卸し表。

• 人の確認: 削除してよいか、委託契約上必要な権限か、患者情報に触れる画面かを院内責任者が見る。

このUse caseでは、Claude CodeにIAM policyを読ませて、roles/owner、roles/editor、広すぎるカスタムロール、用途不明のサービスアカウントを抽出させます。出力は「消すべき」と断定させず、「確認が必要」に寄せます。

Use case 2: 問い合わせフォームのログに個人情報が出ていないか見る

• 入力: フォーム送信処理のコード、loggerの行、Cloud Loggingのサンプル、エラー通知メール。

• 出力: ログに出している項目、マスク候補、削除候補、調査時だけ必要な情報の一覧。

• 人の確認: 氏名、電話番号、相談内容、症状説明、希望日時をログに残す必要があるかを決める。

エラー調査用ログは便利ですが、医療系サイトでは危険な抜け道になります。Claude Codeには、console.log、logger.info、JSON.stringify(request.body) のような行を拾わせ、患者情報をそのまま出している箇所を表にします。

Use case 3: AIエージェント用の読み取り専用点検ルートを作る

• 入力: 調査対象のリポジトリ、GCPプロジェクトID、読み取りが必要なリソース、触らせないデータのリスト。

• 出力: 読み取り専用で足りる作業、検証環境だけで行う作業、人の承認が必要な作業を分けた実行計画。

• 人の確認: Claude Codeへ渡す資格情報、実行コマンド、出力ファイル、削除対象、デプロイ対象を作業前に見る。

AIエージェントに最初から管理者権限を渡すと、作業は速く見えます。ただ、医療系サイトでは速さより境界が先です。読み取り、検証、変更、公開を分け、変更系コマンドは人の承認後にします。

コピペで使えるプロンプト

あなたは医療系サイトのGCP IAM棚卸し担当です。目的は、患者さんの個人情報を不要な担当者、外部委託先、AIエージェントに触らせない境界を作ることです。



対象:

- GCP IAM policy

- サービスアカウント一覧

- Cloud Run / Cloud Functions / Cloud Build の設定

- Secret Managerの参照箇所

- Cloud Loggingへ出しているログ行

- 問い合わせフォーム、予約フォーム、通知メール、CSV出力



作ってほしいもの:

1. メンバー、ロール、用途、触れる個人情報、確認者を持つ棚卸し表

2. roles/owner、roles/editor、用途不明のサービスアカウント、退職者、外部委託先の確認リスト

3. ログに出している個人情報候補と、マスクまたは削除の修正案

4. Claude Codeに任せる範囲、人が承認する範囲、触らせない範囲の3列表

5. 変更コマンドは実行せず、まず差分案だけ出す



制約:

- 医療判断や法務判断を断定しない

- 個人情報らしき値を本文に再掲しない

- 実行前に人の承認が必要な操作を明記する

- 主CTAは /training/ にする

動く確認コード

下のNode.jsコードは、IAM棚卸し表の下書きをチェックします。実際のGCPへ接続するコードではありません。まずCSVやJSONへ落とした棚卸しを、広すぎる権限、用途不明、個人情報接触の有無で確認する用途です。

const iamRows = [

  { member: "[email protected]", role: "roles/owner", purpose: "院内責任者", touchesPatientData: true, reviewer: "院長" },

  { member: "[email protected]", role: "roles/editor", purpose: "LP修正", touchesPatientData: true, reviewer: "" },

  { member: "serviceAccount:[email protected]", role: "roles/secretmanager.secretAccessor", purpose: "フォーム送信", touchesPatientData: false, reviewer: "事務長" }

];



const broadRoles = new Set(["roles/owner", "roles/editor"]);

const findings = iamRows.flatMap((row) => {

  const issues = [];

  if (broadRoles.has(row.role) && row.member !== "[email protected]") {

    issues.push("広すぎる基本ロールを確認する");

  }

  if (!row.purpose || row.purpose.length < 3) {

    issues.push("用途が空に近い");

  }

  if (row.touchesPatientData && !row.reviewer) {

    issues.push("個人情報に触れるのに確認者が空");

  }

  return issues.map((issue) => ({ member: row.member, role: row.role, issue }));

});



if (findings.length > 0) {

  console.table(findings);

  process.exitCode = 1;

} else {

  console.log("Medical site IAM draft passed the first review.");

}

実行例は、medical-iam-check.mjs として保存し、node medical-iam-check.mjs です。出力に [email protected] が出たら、制作会社の権限をLP修正に必要な範囲へ落とせないか確認します。

Pitfall: AIに権限整理を頼んだのに個人情報を広げる落とし穴

原因: Claude Codeに「GCPを見て直して」とだけ頼むと、AIは作業の完了を急ぎ、ログ、CSV、Secret、フォーム本文まで広く読みに行く計画を出すことがあります。医療系サイトでは、その時点で設計が逆です。

直し方: 先に触らせないものを列挙します。患者名、電話番号、相談本文、予約希望日、管理画面の本番データ、通知メール本文は、原則として本文へ貼らない。必要なら、列名だけ、件数だけ、マスク済みサンプルだけを渡します。

もうひとつの落とし穴は、サービスアカウントを人間の代わりに扱うことです。サービスアカウントはアプリや処理が使うIDです。誰が使うか分からない鍵ファイルをローカルPCに置くと、退職者アカウントより追いづらくなります。鍵を増やす前に、実行環境のID、権限、ログ、承認者を分けます。

よくある質問

Q. 医療系サイトでもClaude Codeにコードを読ませてよいですか。

A. リポジトリのコード、設定名、権限表は読ませやすい対象です。ただし、本番の問い合わせ本文、患者名、電話番号、相談内容を貼る前に、院内ルールと委託先の扱いを確認してください。

Q. roles/editorを外すだけで十分ですか。

A. それだけでは足りません。ログ、Secret、CSV、BigQuery、通知メール、バックアップ、CI/CDの権限も見ます。広いロールを外しても、別の経路で個人情報を読める場合があります。

Q. Data Access audit logsは必ず有効にすべきですか。

A. どのログを有効にするかは、費用、保存期間、監査の必要性を見て決めます。医療系サイトでは、誰が何を読んだかを追う設計が欲しいため、Cloud Audit LogsとData Access audit logsの対象を確認します。

Q. 相談導線は無料PDFではなく研修ですか。

A. はい。権限、個人情報、委託先、ログ、公開承認が絡む記事は、読者の会社ごとに前提が違います。主CTAは研修・相談へ寄せます。

相談へ進むなら

ClaudeCodeLabの研修・相談では、医療系サイトの問い合わせフォーム、GCP IAM、ログ、Secret、サービスアカウント、制作会社との作業範囲を一緒に棚卸しできます。今日やるなら、まずGCP IAMのメンバー一覧を出し、roles/owner、roles/editor、用途不明のサービスアカウント、退職者、外部委託先だけを赤く塗ってください。

実際に試した結果

この記事では、frontmatter、本文文字数、公式リンク、Use case 3本、入力・出力・人の確認、コードフェンス、/training/へのCTAを確認しました。確認コードはNode.jsで構文を通し、広すぎるロールと確認者なしの行を検出するところまで見ました。医療や法務の判断は本文で断定せず、院内責任者が確認する前提として残しました。