Claude Media
FISCが示す金融機関のAI利活用と安全対策の考え方

FISCが示す金融機関のAI利活用と安全対策の考え方

FISCの考察が挙げる情報漏洩・シャドーIT・ハルシネーションの課題と対応策を、金融機関がClaudeを導入する際の設定にどう落とし込めるか整理しました。

金融機関がClaudeを業務に入れるとき、FISC(金融情報システムセンター)の考察が最初に突きつけるのは「30日監視保有」を理解しているか、という点です。標準仕様で入出力が30日残る生成AIサービスは多く、Anthropicも例外ではありません。ZDR(Zero Data Retention)を契約すれば消える、と考えたくなりますが、最上位モデルのFableとMythosはZDRのままでは使えない設計です。なおMythosは承認パートナー向けの限定提供で、一般の金融機関が選べるのはFable系です。この記事ではFISCの「金融機関によるAIの業務への利活用に関する安全対策の観点からの考察」(2024年9月24日公表)の課題を、Anthropicの公式ドキュメントと突き合わせます。そのうえで、どこまでが設定で、どこからが金融機関側の運用なのかを切り分けます。業界団体側の実践事例集はFDUA生成AIガイドラインに見る金融機関のガバナンス設計で扱っています。

FISCの考察は何を課題としているか

FISCは金融機関等コンピュータシステムの安全対策基準を策定してきた団体で、考察もリスク管理や監査の目線で書かれています。2023年12月に会員向けの「暫定的考察」を出し、そこに「AI事業者ガイドライン」の公表(2024年4月)や会員企業との議論を加えて、対象を生成AIからAI全般へ広げたのが今回の版です。会員以外にも公開されているため、ベンダー選定や社内規程づくりの根拠として引用しやすい資料です。

くらべる

FISCが分ける2軸6課題

3課題

情報セキュリティ面

情報漏洩・仕様や設定等・モニタリング。プロンプトが機械学習に使われて意図せず出力されること、サービス仕様と利用者側設定の理解不足、常時監視を人手で行えないことが論点です。

3課題

倫理面

虚偽情報の生成・人権侵害・説明力と納得感。ハルシネーション、誤って入力した個人情報にまつわる偽の出力、回答に至る過程を検証できないことが論点です。

6課題のうち、導入判断に直結するのは情報セキュリティ面です。FISCは、サービスの利用形態によっては、セキュリティ対策やデータ取扱いを個別に設定できないことがあると指摘しています。その要件を満たせないなら「生成AIにおいて機密性が高い情報を取り扱うことは適当ではない」というのが結論です。つまり、設定できない形態には機密情報を入れない、という線引きが先にあります。

「30日監視保有」はClaudeでどう扱われるか

FISCは脚注で「30日監視保有」を、事業者のLLMが標準仕様として悪用監視のために入出力データを30日間保有する仕組み、と定義しています。あわせて、入力データが機械学習される標準設定を、学習させない設定(オプトアウト)に変えられることも脚注で述べています。金融機関の担当者はこの2点を、利用するサービスごとに確認する必要があります。

Claude APIでの答えはZDRです。ZDRの契約下では、APIレスポンスを返した後にAnthropicがプロンプトと生成結果を保管(at rest)しません。ただし管理コンソールのスイッチではなく、Anthropicの営業窓口に申請して組織ごとに有効化してもらう契約で、新しい組織を作るたびに個別の有効化が要ります。同じアカウント配下の別組織には自動で広がりません。

ここで見落としやすい例外が3つあります。いずれもAnthropicの「API and data retention」ページに書かれた条件です。

くらべる

ZDRが効く範囲と効かない範囲

契約・有効化が前提

ZDRが及ぶ

Claude APIのMessagesとToken Counting(対象機能のみ)。Commercial組織のAPIキーで使うClaude Code。Claude Platform on AWS(依頼ベースで有効化)。

別の確認が要る

ZDRが及ばない

Claude Console(プレイグラウンド含む)、Claude Managed Agents、Free・Pro・Maxの個人プラン、TeamsとEnterpriseの製品画面。サードパーティ連携と、コード実行ツール(コンテナのデータは最大30日保持)も対象外です。

1つ目の例外は、最上位モデルです。Claude Fable 5.1・Claude Mythos 5.1・Claude Fable 5・Claude Mythos 5は「Covered Models」に指定されています。これらは少なくとも30日のデータ保持が必須で、Anthropicが明示的に認めない限りZDRでは使えません。保持要件を満たさない組織からFable 5へリクエストを送ると、invalid_request_error の400が返ります。メッセージは次のとおりです。

In order to access this model, your organization or workspace must have data retention enabled.

FISCの文脈では、モデルを最上位に上げた途端に30日保有が復活する、と読み替えられます。

ZDR契約の組織が最上位モデルを使いたい場合は、ワークスペース単位で30日保持を有効にします。手順は、Claude Console > Settings > Workspacesで対象ワークスペースを選び、Privacy controlsタブを開く形です。この上書きはそのワークスペースだけに効き、ほかのワークスペースはゼロ保持のままです。機密度の高い業務と最上位モデルを使う業務を、ワークスペース単位で分ける設計が前提になります。

2つ目は、TeamsとEnterpriseの製品画面がZDRの対象外という点です。唯一の例外はEnterprise上のClaude Codeで、別のZDRが用意されていますが、適格なEnterpriseアカウントに限られ、Anthropicによる個別の有効化が要ります。APIキー経由のClaude CodeにZDRが及ぶ場合も、メトリクスログを有効にしていると利用統計などの生産性データは対象外で、保持されることがあります。

3つ目は、ZDRやHIPAAの契約があっても、Anthropicが法令上必要な場合にデータを保持することがある点です。自動のトラストアンドセーフティ検知でフラグが立った場合は、入出力を最大2年保持しえます。ゼロ保持の例外を契約書の文言として確認しておくと、監査で説明しやすくなります。ZDRとHIPAA readinessの違いはClaude APIのZDRとHIPAAのデータ保持ポリシー比較で扱っています。

FISCが挙げる「クラウド環境のリージョン(海外/国内)」は、まずデータ処理者が誰かで分かれます。Claude API・Claude Platform on AWS・Claude in Microsoft Foundryでは、Anthropicがデータ処理者です。Amazon BedrockとGoogle Cloudでは、クラウド事業者が処理者になります。Covered Modelsの30日保持は、この2経路でも変わらず、Bedrockなどでは保持データがクラウド事業者の環境内に留まります。Anthropicがデータ処理者になる経路では、推論の場所を決める inference_geo は既定の global と米国限定の us の2値だけです。保存場所を決めるworkspace geoも us しかなく、日本を指定する設定はありません。Amazon BedrockとGoogle Cloudでは、推論リージョンはエンドポイントURLや推論プロファイルで決まります。国内処理を求める場合は、こちらの経路で使うリージョンを選ぶことになります。ワークスペースgeoの詳細はClaudeのワークスペースgeoと日本のデータ所在で扱っています。

シャドーITとモニタリング:止められない前提でどう組むか

FISCは、組織の許可なく職員が生成AIを業務に使う「シャドーIT」を、管理と統制がとれなくなり、情報漏洩のリスクが高まるため適当ではないとしています。Claudeでこの論点に当たるのは、技術設定より先に、個人プランの業務利用の扱いです。Free・Pro・Maxの個人プランはZDRの対象外で、ブラウザやデスクトップ、モバイルアプリ、Claude Codeのどれから使っても同じです。法人契約の外で業務情報が動いた時点で、前節の整理は全部外れます。

FISCの対応策にも該当する一文があります。「AIサービス等の内容を踏まえ、AIサービス等の職員等の利用可否、利用形態を明確にする」です。使ってよいサービスを指定する規程を先に置き、そのうえで利用状況を見られる契約形態を選ぶ順序になります。

利用状況の把握には、Compliance APIとActivity Feedがあります。Claude EnterpriseとClaude Consoleの顧客がプログラムから組織のアクティビティを取得できる仕組みで、認証・チャット・ファイル・プロジェクト・管理操作の記録が対象です。Activity Feedは発生から1分以内に検索でき、6年間保持されます。ただし記録は有効化した時点から始まり、さかのぼっては取得できません。導入前に有効化しておかないと、あとから「誰がいつ使ったか」を証明できなくなります。

もう一つ、FISCの視点で重要なのがZDRとの関係です。Compliance APIは、ZDRが有効になっているローカルセッションを取得しません。ゼロ保持を選ぶことは、Anthropic側にログを残さないことでもあるため、監査用の記録を自社側で持つ設計とセットで考える必要があります。逆にZDRを使わないローカルセッション(CoworkやClaude Codeなど)は、既定で6年保存されます(組織で保持期間を設定していればその期間)。

FISCは、プロンプト・学習データ・回答のそれぞれを常時モニタリングすることが望ましいとしつつ、「人手による十分なモニタリングは困難」と認めています。考察欄では、職員が機密情報を気軽に入力しがちな点を踏まえ、サービスの利用形態や運用形態を検討する必要があるとしています。ログを取れること自体は条件を満たす第一歩にすぎず、全件を人が読む運用は成立しません。入力前のテンプレート化やフィルタリング、機密性の高い業務を入力対象から外す判断を、利用形態の設計として先に決める形になります。

ハルシネーションと説明力:ツールに任せられない部分

FISCが倫理面の対応として挙げるのは、回答の根拠を参照元の明示などで人間が目で見て分かるようにすること、そして回答が正当か、ハルシネーションではないかを入念に確認することです。前者は、依頼文に「根拠となる箇所を示す」と指定し、人が原典と突き合わせる運用で実現できます。後者は、どのツールを選んでも金融機関側に残る責任です。

FISCの「適切な利用・運用管理」には、確認の観点が3つ挙がっています。①安全性・公平性・正確性・多様性・包摂性を欠く可能性、②著作権や知的財産権、業法上の免許・資格に関わる法令違反や権利侵害を含む可能性、③正当性を確認できないハルシネーションの可能性です。与信判断や顧客向け文面の下書きにClaudeを使う場合、レビュー工程でこの3点を別々に確認する設計になります。①と③は事実と表現の確認、②は法務・コンプライアンスの確認と、担当が分かれるためです。

もう一つ、見落としやすいのがデータの品質です。FISCは、AIにとってデータが重要な役割を果たすため、正確で整合的であること、定期的に更新されていること、内容や機密度に応じた管理方法が定められていることを求めています。社内文書を読ませるRAG型の運用では、元の文書の更新が止まっていれば、回答もそのまま古くなります。

FISCの事例分類からClaudeの導入範囲を決める

考察は利活用事例を8件に分けています。事例1〜3は予測・提案・決定を行う「従来型AI」で、住宅ローン審査と法人向けオンライン融資の与信判断、カードローンの申込予測、保険金の不正請求検知です。事例4〜8が「生成AI」で、事例4が業務文書やメール文案の作成支援・翻訳・要約・コード生成、事例5がテンプレートやボタンを備えたプロンプトの定型化、事例6が社内情報データベースと連携するRAGです。

事例7(ファインチューニング)と事例8(音声・画像・動画を組み合わせるマルチモーダル)は、公表時点で将来の利用可能性を見極める実証実験段階にあり、実際の取り組みは僅少と明記されています。つまり、金融機関で実運用に近いのは事例4〜6で、Claudeの導入範囲もそこから始めるのが現実的です。与信判断のような従来型AIの領域は、生成AIの導入とは別の統制設計が要ります。

4分類の対応策を導入手順に置き換える

FISCは金融機関の対応策を、①AI利活用に係る方針策定及び態勢整備、②AIの適切な利用・運用管理、③AIに係る安全対策、④AIに係る教育・注意喚起等の4つに分けています。これをClaudeの導入に当てはめると、設定の確認と規程づくりの順序が決まります。

手順

導入前に決める5つのこと

  1. 1

    業務ごとの利用形態を決める

    方針策定(①)に当たる作業です。どの業務をClaude Enterprise、Claude API、Claude Codeのどれで扱うかを分け、個人プランの業務利用を禁止する規程を置きます。

  2. 2

    機密度ごとにZDRと30日保持を割り当てる

    安全対策(③)に当たる作業です。ZDRが必要な業務と、Fable・Mythos系を使うために30日保持を許容する業務をワークスペース単位で分けます。

  3. 3

    監査記録の置き場所を決める

    Compliance APIを導入前に有効化し、ZDRを選ぶローカルセッションの記録は自社側で持つ設計にします。

  4. 4

    生成結果のレビュー工程を定める

    運用管理(②)に当たる作業です。前節の3観点を、誰がどの段階で確認するかを規定します。

  5. 5

    職員向けの教育を継続する

    教育(④)は技術設定で代替できない領域です。学習への利用有無と、機密情報を入力するリスクを研修で共有します。

FISCは対応策の末尾で、技術・リスク管理に関する情報が頻繁に更新されうることに留意し、教育を一度で終えず継続するよう求めています。Claudeのモデルや保持要件も更新されるため、規程の見直し周期を決めておく必要があります。2024年9月の公表時点でFISCは、安全対策基準・解説書へのAI関連項目の追加を今年度中に行う予定としていました。この予定は、2025年3月の安全対策基準・解説書 第13版で実施されました。AI・生成AIの安全対策を示す基準小項目が新設され、2026年3月の第14版でも、官公庁や業界団体のAIガイドラインを踏まえた改訂が加わっています。考察は課題の整理、基準・解説書は監査で参照される基準項目、という分担で読むと使いやすくなります。金融機関のClaude活用実務全般は金融業界のClaude活用ガイド、導入事例の横断比較はClaude金融導入事例で扱っています。

まとめ

ZDRだけでは「30日保有」の論点は閉じません。最上位のFable・Mythos系は30日保持が前提で、TeamsとEnterpriseの画面はZDR対象外、フラグが立てば最大2年残りうるからです。業務ごとに、どの契約形態とモデルの組み合わせを許すかを先に表にして、その範囲を超える利用をシャドーITとして扱う、という整理が使えます。

この記事を共有:XはてブLinkedIn