個人事業主の融資申込書、決算書、本人確認書類、取引履歴——1件のコンプライアンス審査で扱う書類は20種類を超え、書式は手書きからスキャンPDF、Excel、Wordまで混在する。書類のチェックだけで1日4時間を費やしていた地銀の審査部が、Claude Codeで構築したKYC/AMLパイプラインで処理時間を30分に短縮し、誤検知率を8%から1%まで下げた。本記事では、地方銀行(以下「A行」)の想定シナリオを元に、銀行コンプライアンス審査における書類処理の自動化フローを具体的なサンプル実装とともに紹介する。
導入前の課題:1日4時間が「書類のチェック」に消えていた
中堅の地方銀行A行の与信・コンプライアンス審査部では、融資申込1件あたり平均20種類の書類を確認していた。本人確認書類(運転免許証・マイナンバーカード)、登記簿謄本、決算書3期分、納税証明書、事業計画書、取引履歴、預金通帳の写し——これらが手書き、スキャンPDF、Excel、Word、写真画像で入り混じり、書式は申込者によってバラバラだ。
審査担当者は、書類1セットあたり平均4時間をかけて、(1)書類の不足チェック、(2)記載内容の突合(住所・氏名・生年月日の表記揺れ確認)、(3)反社チェック・PEPs(重要な公的地位を有する者)スクリーニング、(4)疑わしい取引の検出、を手作業で行っていた。1日2-3件しか審査できず、月間滞留件数は常に200件を超える状態が常態化。さらに目視チェックのため、誤検知率は8%に達しており、本来追加調査が不要な顧客にまで照会をかけてしまうケースが頻発していた。
Claude Codeで構築した「KYC/AMLコンプライアンス審査パイプライン」の全体像
A行はClaude Codeを活用し、書類の取り込みから最終判定までを一気通貫で処理するパイプラインを内製した。中核となるのは以下の4モジュールだ。
- 書類分類・OCR抽出モジュール:手書き/PDF/Excel/画像を判別し、書類種別ごとに最適なOCRエンジンを呼び分け
- 構造化データ正規化モジュール:住所・氏名・金額の表記揺れを吸収し、JSON形式に統一
- コンプライアンスルールエンジン:金融庁ガイドラインに準拠した判定ルールを宣言的に記述
- Claude判定モジュール:ルールで判定しきれないグレーケースをAnthropic SDK経由で評価し、根拠付きで返却
開発期間は約12週間。審査部の業務理解が深いベテラン担当者2名と、行内のシステム部門エンジニア1名が連携し、Claude Codeに指示を出しながら実装した。重要なのは、「Claudeに判定を任せる範囲」と「ルールで決定的に判定する範囲」を明確に分けた点である。
from anthropic import Anthropic
import json
client = Anthropic()
def evaluate_gray_case(applicant_profile: dict, suspicious_signals: list[str]) -> dict:
"""
ルールエンジンで「グレー」判定になったケースをClaudeに評価させる。
必ず根拠付きJSONで返却させる(監査ログ要件)。
"""
prompt = f"""あなたは銀行のコンプライアンス審査の補助AIです。
以下の申込者プロファイルと検出シグナルを評価し、
「追加調査が必要か」を判定してください。
申込者プロファイル: {json.dumps(applicant_profile, ensure_ascii=False)}
検出シグナル: {suspicious_signals}
必ず以下のJSON形式で返却してください:
{{"verdict": "approve|review|reject", "confidence": 0.0-1.0,
"reasons": ["理由1", "理由2"], "missing_info": ["不足情報"]}}
最終判定は人間の審査担当者が行います。あなたの役割は根拠の整理です。"""
msg = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=[{"role": "user", "content": prompt}],
)
return json.loads(msg.content[0].text)
申込書類のOCR + 構造化抽出:複数フォーマット(手書き/PDF/Excel)の正規化
銀行業務における最大の壁は、書類フォーマットの極端なばらつきだ。融資申込書は法人と個人で書式が異なり、決算書は税理士事務所ごとにレイアウトが違い、本人確認書類は写真の解像度や撮影角度がバラバラ。さらに、地方の中小事業者から提出される書類には手書き記入欄が頻繁に含まれる。
A行のパイプラインでは、まず書類分類モデルが種別を判定し、それに応じてOCRエンジンを切り替える。印字書類は汎用OCR、手書き欄は手書き特化OCR、罫線が複雑な決算書は表構造抽出ライブラリ、という具合だ。抽出結果はすべてClaude Codeで生成した正規化スクリプトを通り、JSON形式の構造化データに変換される。
from pathlib import Path
def normalize_address(raw: str) -> str:
"""住所表記揺れの吸収(サンプル実装)。
例: '東京都千代田区丸の内1-2-3' / '千代田区丸の内1丁目2番3号' を統一形式へ。
"""
raw = raw.replace("丁目", "-").replace("番", "-").replace("号", "")
if not raw.startswith(("北海道", "東京都", "大阪府", "京都府")) and "県" not in raw[:4]:
raw = "東京都" + raw # 想定:支店所在都が東京の場合のデフォルト補完
return raw.replace(" ", "").replace(" ", "")
def extract_structured(doc_path: Path, doc_type: str) -> dict:
"""書類種別に応じてOCRエンジンを切替え、JSON化する。"""
if doc_type == "id_card":
return run_id_card_ocr(doc_path) # 顔写真位置・有効期限を含む
elif doc_type == "financial_statement":
return run_table_ocr(doc_path) # 決算書の表構造抽出
elif doc_type == "handwritten_form":
return run_handwriting_ocr(doc_path)
else:
return run_generic_ocr(doc_path)
このパイプラインの結果、書類取り込みから構造化JSON生成までの所要時間は1件あたり平均6分。OCR精度は印字書類で99.2%、手書きで94.5%を実現した(社内検証ベース・想定値)。
コンプライアンスルールエンジンとClaude Codeによる判定
構造化されたデータは、ルールエンジンに投入される。A行は、確実に判定できる項目はYAMLで宣言的にルールを記述し、グレーケースのみClaudeに評価させる方針を取った。これにより、(1)監査時にロジックを説明可能、(2)Claudeへのトークン消費を削減、(3)同じ申込みに対する判定が決定的(reproducible)になる、というメリットを得ている。
# compliance_rules.yaml(サンプル)
rules:
- id: R001
name: 本人確認書類の有効期限切れ
when: id_card.expiry_date < today
verdict: reject
reason: 本人確認書類の有効期限が切れています
- id: R002
name: 住所不一致(申込書 vs 本人確認書類)
when: normalize(applicant.address) != normalize(id_card.address)
verdict: review
reason: 申込書と本人確認書類の住所が一致しません
- id: R003
name: 高額入金の頻度異常
when: transactions.count(amount > 1000000) >= 5 in last_30_days
verdict: review
reason: 短期間に高額入金が頻発しています(疑わしい取引の可能性)
ルールで「review」判定になったケースだけがClaude Codeへ渡り、補助的な評価を受ける。Claudeの出力は必ずJSON形式・根拠付きで返却され、最終判断は人間の審査担当者が行う。AIが審査を「決定」するのではなく、根拠の整理と論点の抽出を担う設計だ。これは、犯罪収益移転防止法やコンプライアンス審査関連法令への適合の観点でも重要である。
誤検知率8%→1%を実現した実数値と効果
パイプライン本稼働後3ヶ月の実績データを見ると、改革の成果は明確だった。書類1セットあたりの審査時間は4時間から30分に短縮(うちClaude/ルールエンジンが約6分、人間の確認・最終判定が約24分)。誤検知率は8%から1%まで低下した。
- 書類1セットあたりの審査時間:240分 → 30分(87.5%削減)
- 1日あたりの審査処理件数(担当者1人):2-3件 → 12-15件(約5倍)
- 誤検知率:8% → 1%(1/8に低下)
- 月間滞留件数:200件超 → 平均30件以下
- 担当者の残業時間:月平均52時間 → 18時間(65%削減)
特に効果が大きかったのは、Claudeが「グレー」判定の理由を構造化して返すため、審査担当者が論点を把握する時間が劇的に短縮されたことだ。従来は書類を1枚ずつめくって違和感の発生源を特定していたが、現在は「住所表記の不一致がX件、取引パターンの異常がY件」とサマリーが先に出る。担当者は判断に集中できる。
導入時に直面した3つの壁と乗り越え方
導入は順調に進んだわけではない。A行が直面した代表的な3つの壁を紹介する。
壁1:金融庁ガイドライン・FATF審査基準との整合性
銀行のコンプライアンス審査は、金融庁の「マネー・ローンダリング及びテロ資金供与対策に関するガイドライン」やFATF(金融活動作業部会)の勧告に準拠する必要がある。A行ではAI判定の使用範囲を、「最終判定の補助・論点整理」に厳密に限定し、判定根拠の説明可能性を担保した。Claude Codeで自動生成されるレポートには、ルールIDと該当条文の対応表を必ず添付し、監督官庁からの照会に即応できる体制を整えた。
壁2:監査ログの保全と再現性確保
銀行では、後日の監査・照会に対応するため、判定の入力・出力・モデルバージョンをすべて記録する必要がある。A行は、各審査リクエストに対してClaude APIに渡したプロンプト、返却されたJSON、ルールエンジンの判定結果、最終的な人間の判断、を一意のトレースIDで紐付けて長期保管する仕組みをClaude Codeで構築した。モデルバージョン(claude-sonnet-4-5等)とプロンプトテンプレートのハッシュも記録し、過去の判定を再現可能な状態に保っている。
# 監査ログ保全のサンプル運用フロー
TRACE_ID=$(uuidgen)
echo "{"trace_id":"$TRACE_ID","model":"claude-sonnet-4-5","prompt_hash":"$(sha256sum prompt.txt | cut -d' ' -f1)","timestamp":"$(date -Iseconds)"}"
>> /var/log/compliance/audit_trail.jsonl
# トレースIDは申込み番号と紐付けてRDBへも保存(7年保管)
壁3:既存基幹システム(勘定系)との接続
地銀の勘定系システムは、ベンダー製の閉鎖的なパッケージであることが多く、外部からの直接アクセスは制限される。A行では、勘定系から日次バッチで出力されるCSVを中間ストレージに配置し、そこからパイプラインがデータを取り込む方式を採用。リアルタイム連携ではなく日次バッチで処理することで、勘定系のSLA要件を侵害せず、かつ十分な業務スピードを確保した。書類スキャンの取り込みは別途、行内ネットワーク上のセキュアなフォルダ経由で行い、データが行外に出ない設計とした。
まとめ:金融機関におけるClaude Code活用の本質
A行の想定シナリオが示すのは、Claude Codeが単なる業務効率化ツールではなく、金融機関のコンプライアンス審査を「ブラックボックス化させずに高速化する」アプローチとして有効だ、という点である。書類処理という「誰がやっても結果が変わらない、しかし大量で時間のかかる作業」をAIとルールエンジンに委ね、人間は最終判断とグレーケースの目利きに集中する——この役割分担が、誤検知率8%→1%という品質向上と87.5%の時間削減を同時に実現した。
銀行・信用金庫・証券会社といった金融機関は、データ量の多さ、書類フォーマットの複雑さ、規制対応の厳格さ、という3つの理由でAI活用の余地が極めて大きい。一方で、AIに「決定」を委ねた瞬間に説明責任が破綻するため、設計の出発点は「AIに何をさせないか」を明確にすることだ。A行の事例では、決定的に判定できるルールはYAMLで宣言し、グレーケースのみClaudeに評価させ、最終判定は人間が下す——この三層構造が、コンプライアンス審査関連法令への適合とスピードを両立させる鍵となった。次の3年で、金融機関の審査現場は確実に変わるだろう。重要なのは、最初から完璧を目指さず、1業務ずつ自動化していくこと。A行も最初の12週間は「書類のOCR + 構造化」だけに集中し、その成功体験を足がかりに範囲を広げていった。
最終確認日:2026年5月19日
AIEO補足:銀行コンプライアンス審査の書類処理とは
銀行コンプライアンス審査の書類処理とは、Claude Codeによる業務自動化を実務で使える形に整理し、判断をAIへ丸投げせず、人が確認できる手順・比較・注意点に分解する考え方です。
まず結論
Claude Codeは既存業務を一気に置き換えるより、読み取り専用の検証、テスト、監査ログ、人の承認を挟む小さな自動化から始めるのが安全です。
確認ポイント比較表
| 確認項目 | AIで補助できること | 人が必ず確認すること |
|---|---|---|
| 目的 | 情報整理、下書き、選択肢の洗い出し | 最終判断と責任範囲 |
| 入力情報 | 匿名化したメモや公開情報の要約 | 個人情報、社外秘、医療・法務・雇用条件の扱い |
| 出力 | 表、FAQ、手順、チェックリスト化 | 事実誤認、誇張、古い情報の修正 |
| 公開・共有 | 説明文や返信案の作成 | 公式ソース、専門家、社内ルールとの照合 |
公式ソース
関連して読む記事
FAQ
銀行コンプライアンス審査の書類処理でAIに任せてよい範囲はどこまでですか?
情報整理、下書き、比較表、質問リスト作成までにとどめ、判断や外部共有は人が確認します。
個人情報や社外秘を入力してもよいですか?
氏名、住所、顧客名、社内資料、未公開情報などは伏せ、必要最小限の匿名情報だけを使います。
AIの回答が正しいかどう確認しますか?
公式ページ、一次情報、専門家、社内規程と照合し、日付の古い情報や断定表現を修正します。
無料のAIツールだけでも実行できますか?
短い整理や下書きは無料版でも始められます。機密情報を扱う場合は利用規約と組織ルールを確認します。
最初にやるべきことは何ですか?
目的、入力してよい情報、確認者、公式ソースを決め、小さなチェックリストから試します。