FDUA生成AIガイドラインに見る金融機関のガバナンス設計

FDUAの生成AIガイドラインは何を定めているのか

FDUA生成AIガイドライン(紹介資料での呼称は「金融生成AIガイドライン」)は、金融データ活用推進協会(FDUA)の生成AIワーキンググループがまとめた業界団体の指針で、法令ではありません。2024年4月の紹介資料では、5つの原則群(21項目)・7つのリスク・ライフサイクル4段階で構成されています。

金融データ活用推進協会(FDUA、Financial Data Utilizing Association、一般社団法人)は、3メガグループ・カード会社・信託銀行・損害保険会社が理事を務める業界団体です。会員は255社(2024年4月19日の会員マップ)で、顧問には前金融庁長官も入っています。

2023年7月に立ち上がった「生成AIワーキンググループ」は、25社が参加します。東京海上ホールディングス・日本生命・日本マイクロソフト・EYストラテジー・アンド・コンサルティング・日鉄ソリューションズが事務局側で、KPMGコンサルティングが全体アドバイザーです。成果物は「金融生成AIガイドライン」と、活用事例を扱う「実務ハンドブック」の二分冊です。

FDUAのガイドラインは第1.0版が公開されています。第1.0版では項目数や章立てが紹介資料と異なる可能性があり、以下の番号と表は、日本銀行のサイトに載る2024年4月19日付の紹介資料に基づきます。資料の冒頭には「本ガイドラインは現在具体検討中のため、以降あくまで現時点の内容」という注記があり、目次にも「(仮)」が付いています。

各社が自社の指針を作るときに使う資料です。総務省・経済産業省の「AI事業者ガイドライン」の共通指針も踏まえつつ、生成AIの特性と金融機関の業務特性(大量のセンシティブデータ、金融規制法)を掛け合わせて作られています。

5原則21項目は何を求めているか

第3章は5つの原則群を置きます。

各項目には「考慮すべき事項例」が付きます。2.2「適正なデータ」は「不用意に顧客情報、機密情報を入力しない」、4.1「追跡可能性」は「AI決定の各プロセスを記録し、監査可能とする」、3.1「安全性」は「サービスと関係ない入力や悪意ある利用を排除する仕組みを構築する」です。技術で受け止められる行動指針が、項目の中に混ざっています。

第4章は、著作権法・個人情報保護法・金融規制法・国内ガイドラインとの対応を示します。後者にはセキュアAIシステム開発ガイドライン、金融庁のモデル・リスク管理原則、FISC(金融情報システムセンター)の「金融機関による生成AIの業務への利活用に関する暫定的考察」が並びます。

生成AIの7つのリスクと「使わない」という対応

第2章は、生成AI特有のリスクを7種類挙げ、対応例を対にしています。

対応例の多くに「利用しない」「用途を限定する」が入っています。効果が見込めても、追跡や説明を担保できない業務には生成AIを当てない判断が、最初から選択肢に含まれています。

活用事例は原則とどう結びつけて書かれているか

ハンドブック第1章は、活用を3段階に分けます。レベル1は個人がChatGPT等を単体利用する段階、レベル2はRAG(検索拡張生成)で社内情報を取り込む段階、レベル3は社外顧客向けのサービス提供です。

事例は「社内業務効率化」「顧客向けサービス」「営業支援」「金融機関に固有の業務」「高度取組み(特化型LLM構築)」の5カテゴリです。事例2「バーチャル顧客を活用した営業スキル向上トレーニング」は、想定リスクを第3章の原則名に紐づけて示しています。

事例概要・期待効果・想定リスク・該当原則の4点をそろえる書き方は、自社の新しいユースケースを検討する際の記載項目にも転用できます。

ライフサイクルの4段階で何を確認するか

第5章は、AIシステムが「意思決定を担うAIをシステム内に包含している」点で他のITシステムと違うとし、企画・AI構築/システム実装・デプロイ・運用/利用の4段階で考慮事項を挙げます。

他のITシステムと分ける特性として、デプロイ後のアップデートが高頻度であること、入力に対する出力を網羅的には確認できないことが挙がっています。クラウド提供のモデルでは更新が提供側の都合で入るので、「デプロイ」の事項は、モデル更新時に既存業務への影響を見る運用として設計する形になります。

原則ごとにClaudeのどの機能が受け皿になるか

FDUAの項目のうち、Claudeの管理機能で技術的に受けられるものと、運用に残るものを並べると次のようになります。対応づけはこの記事の整理で、FDUAの資料にClaudeの機能名は出てきません。

最後の行は、技術で埋まらない項目です。FDUAのリスク表で「人が判断するプロセスの組み込み」が繰り返し出てくるのも、同じ理由によるものです。

追跡可能性は監査ログだけでは足りない

4.1が求めるのは、AI決定の各プロセスを記録して監査可能にすることです。Compliance APIは、Claude Enterpriseの組織とClaude Console(API利用側)の組織に、組織内の活動をプログラムから取得する口を提供します。セキュリティ・法務・コンプライアンス部門が、監査や下流のSIEM(セキュリティ情報イベント管理)連携に使う想定です。

curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/compliance/activities?limit=1" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

返るのはclaude_chat_createdのようなイベントで、actor(誰が)とcreated_at(いつ)を含みます。ただし「操作の記録」と「会話の中身」は別の層で、Enterpriseでは次の3層に分かれます。

FDUAの「AI決定の各プロセスを記録し、監査可能とする」に照らすと、見落としやすいのは取得できない経路のほうです。次の経路は、セッション記録の対象になりません。

• Claude ConsoleのAPIキーで認証したClaude Codeや、Amazon Bedrock・Google Cloud・Microsoft Foundry経由のClaude Code
• Claude Codeのクラウドセッション(クラウドで動くルーティンを含む)。リモートセッションのエンドポイントが返すのはCoworkだけ
• ゼロデータ保持(ZDR)が有効なローカルセッション。一覧から外れ、取得すると404になる
• HIPAA対応を有効にした組織での、CoworkとClaude Code以外のローカルセッション

活動フィードの読み方にも癖があります。claude_chat_viewedのような*_viewedは、Claudeのアプリがサーバーから内容を読み込んだ記録で、人が見たことの証拠にはなりません。ファイル・プロジェクト文書・アーティファクトの活動に付くfilenameとtitleは、2026年9月24日以降、それ以前の記録も含めて常にnull・空文字・省略のいずれかです。名前を知りたいときは、内容を取得するエンドポイントで引き直します。Compliance APIの呼び出し自体もcompliance_api_accessedとして活動フィードに残るので、監査基盤の使われ方も追えます。

Claude Codeを使う金融機関では、アカウントの認証方法で監査の経路が分かれます。Enterpriseアカウントでサインインして使う利用はセッション記録に残り、APIキーやクラウド事業者経由の利用は残りません。後者はClaude Code側のOpenTelemetry(自社の収集基盤にイベントを流す仕組み)で記録する設計になります。

保持の考え方にも注意点があります。チャット・ファイルの内容は組織のclaude.ai保持ポリシーに従い、ユーザーが先に消した分は取得できません。法的保全などで残す必要があるなら、取り込み時に自社のアーカイブへ書き出す前提で設計します。Compliance APIによる削除は即時かつ恒久で、復元の猶予はありません。

記録されるのはやりとりの事実だけで、なぜその回答になったかは残りません。

CMEKで何が自社の管理下に移るか

AWS KMS・Google Cloud KMS・Azure Key Vaultの自社の鍵を使い、Anthropicが一部のデータを暗号化する仕組みがCMEKです。鍵のローテーション・監査・失効を自社で握れ、Anthropicが鍵に対して行う操作は、クラウド事業者側の監査ログに残ります。

FDUAの項目は暗号鍵に触れていません。2.2「適正なデータ」・3.3「プライバシー」との対応は、データの取り扱いを自社で管理するという点で近いと見た、この記事の解釈です。

押さえておく条件は次の6点です。

• 有効化は申し込み制で、Anthropicのアカウント担当に連絡します。すでにリクエストを受けているワークスペースに鍵を付けた場合、反映まで最大1日かかります

• Enterpriseでは組織単位、Claude Platformではワークスペース単位で設定し、鍵の設定は組織のオーナー系ロール(Platformは組織管理者)だけが行えます

• Claude Platform on AWSを除き、現在はUSリージョンのみで、暗号化の処理もUSで行われます。AWSならus-east-2、Google Cloudならus-central1などが推奨です。Claude Platform on AWSはAWS KMSだけに対応し、鍵は同一リージョンの単一リージョン鍵です

• 有効化は恒久で、鍵を失えば暗号化済みのデータは復旧できません。鍵を一度付けたワークスペースは、鍵の取り外しも差し替えもできません

• 保護されるのは有効化後に書き込まれたデータだけです。それ以前のチャットやファイルは、Anthropic管理の鍵のまま再暗号化されません

• 鍵の失効が効くまで最大1時間かかり、その間の処理中のリクエストは成功することがあります

保護の範囲は製品で違います。Enterpriseでは、チャット内容・添付ファイル・プロジェクト添付・CLIのClaude Code・Claude Desktop上のCowork・Chrome拡張・Microsoft 365向けClaudeが対象です。Compliance APIで取得するローカルセッションの記録も鍵で保護され、鍵が使えない間はメッセージ取得が503を返し、メタデータだけが一覧に出ます。一方、アカウントの名前・メールアドレス・プロフィール画像は自社の鍵の対象外です。Claude Platformでは、活動フィード・監査ログ・OTELなどのテレメトリ通信も対象外で、鍵を失効させても監査を続けられる設計になっています。

Claude Codeをゲートウェイやプロキシ(ANTHROPIC_BASE_URLを差し替えた構成)経由で使うと、運用上のテレメトリにはCMEKが効きません。テレメトリの送信を止める環境変数がDISABLE_TELEMETRY=1です。

詳細はCMEKが日本企業の暗号鍵管理要件を満たすかでも扱っています。

入力の段階で止めるにはInference hooks

FDUAの7つのリスクのうち、プロンプトインジェクションの対応例は「厳格な入力規制」です。4.1が記録を求めるのに対し、3.1「安全性」は、サービスと関係ない入力や悪意ある利用を排除する仕組みを求めます。Claude側の候補がInference hooksです。

ClaudeのEnterprise組織向けのベータ機能で、設定にはOwnerかPrimary ownerのorganization:manage権限が要ります。利用者がプロンプトを送ると、Anthropicが会話の記録を組織のAIセキュリティサーバーへHTTPSで送り、許可か拒否の判定を待ちます。拒否されたリクエストはモデルに届きません。応答の待ち時間は既定5秒で、サーバーが応答しないときは、組織が設定した「ブロックする」か「検査せず通す」かで動きます。

運用面の特徴は5つあります。

• フックが作動するのはAnthropicのサーバー側なので、端末への導入は不要です
• Claude Platformの組織は対象外で、Amazon BedrockとGoogle Cloudでも使えません。音声モードは対象外で、画像だけの内容は検査されません
• 現在のイベントはpromptのみで、モデルの応答側を止める仕組みはまだありません
• AIセキュリティサーバーに渡るのは文字として見える会話・ツール呼び出し・添付から抽出したテキストで、ファイルや画像の生データ、システムプロンプトは渡りません
• 拒否は活動フィードにも記録されます。導入は、影響の出ない観測だけのシャドーモード、検査する割合の指定、ロール単位の除外で段階的に進められます

拒否してもclaude.ai上のメッセージ自体は会話に残ります。フックは判定の記録を持つだけで、会話内容の保持は製品側の保持ルールに従うためです。FDUAの対応例が言う「利用しない」を、特定の入力に対してだけ実装する手段と見ると位置づけが分かります。

FISCとの接続

第4章が参照する国内ガイドラインには、FISCの暫定的考察も入っています。FDUAは業界横断の実践的な指針、FISCは金融システムの安全対策という別のレイヤーです。FISCの安全対策基準を踏まえたClaude導入のチェックリストは、FISCが示す金融機関のAI利活用と安全対策の考え方と金融機関のClaude導入とFISCの安全対策チェックリストにあります。

自社の利用形態から逆引きする

どのClaudeを使っているかで、FDUAの4.1・4.2に対する答え方が変わります。

まとめ

APIキー経由のClaude Codeはセッション記録に残らず、CMEKを入れたPlatformではCompliance APIの生データが使えなくなります。どちらも4.1が求める記録の経路か内容が欠けるため、記録をどこで持つかが導入前の論点になります。