Claude Code × 金融業界｜規制準拠を自動化しながらFinTech開発を加速させる実践手法

金融システムの開発チームがClaude Codeを検討するとき、最初に立ちはだかるのは技術的な課題ではなく「そもそも使って良いのか」という組織判断です。FISC安全対策基準、PCI DSS、金融庁の各種ガイドライン、自社の情報セキュリティポリシー——これらを整理しないままPoC（概念実証）を始めると、セキュリティ部門から差し戻されるか、最悪の場合インシデントにつながります。

本記事では、金融業界の規制環境を前提条件として織り込んだうえで、Claude Codeを実務に組み込むための具体的な手法を解説します。テスト自動化やドキュメント生成といった「何に使うか」だけでなく、CLAUDE.mdでの規制準拠ルール定義、Bedrock閉域構成の設計判断、監査証跡の残し方まで、開発チームが実際に手を動かすレベルの情報を提供します。

金融開発における制約の全体像 — 技術選定以前の問題

金融業界でAI開発支援ツールを導入する場合、「技術的にできるか」ではなく「組織として許容されるか」が最初のハードルです。

金融システムの開発に関わる規制・ガイドラインは複数の層で構成されています。開発チームとしてまず把握すべきは、それぞれがClaude Codeの利用にどう影響するかという点です。

規制レイヤーとClaude Codeへの影響

規制・基準	Claude Code利用への影響	対応方針
FISC安全対策基準	外部サービスへのデータ送信に関する要件	Bedrock VPCエンドポイント構成で経路を制御
PCI DSS	カード会員データの取扱い制限	カード情報を含むコードをClaude Codeの対象外にする
金融庁AIガイドライン	AI利用の説明責任・管理体制	人間によるレビュー必須のワークフロー設計
各社セキュリティポリシー	ツール導入の承認プロセス	情報セキュリティ部門との事前協議

ここで重要なのは、これらの制約を「導入を阻む壁」として捉えるのではなく、Claude Codeの適用スコープを明確に区切るためのフレームワークとして活用することです。「何に使えないか」が明確になれば、逆に「何に安全に使えるか」もはっきりします。

CLAUDE.mdで規制準拠ルールを定義する

金融開発でClaude Codeを運用する場合、CLAUDE.mdに規制由来の禁止事項を明記しておくことで、Claude Codeの出力段階でリスクを低減できます。

# CLAUDE.md（金融システムプロジェクト例）

## セキュリティ制約
- 本番環境のDB接続情報、APIキー、証明書情報をコード内に含めない
- テストデータには実在の口座番号・取引情報を使用しない
- PCI DSS対象のカード会員データ処理モジュールは変更対象外

## 監査対応
- すべてのコミットメッセージに変更理由を記載する
- AI生成コードには `// generated-by: claude-code` コメントを付与する
- PRの説明文に、Claude Codeが生成した範囲を明記する

## コーディング規約
- 金利計算ロジックには必ず小数点以下の精度指定を含める
- BigDecimalを使用し、浮動小数点演算は禁止
- 日付処理はjava.time（Java）またはdayjs（TypeScript）を使用

このCLAUDE.mdがあるだけで、Claude Codeが金利計算にfloatを使ったり、テストデータに実在しそうな口座番号パターンを生成したりするリスクが大幅に下がります。規制対応のかなりの部分は、CLAUDE.mdの設計品質に依存するという認識を持つことが出発点です。

規制準拠テストの自動生成 — Before/After

テストコードは本番データを含まず、かつ規制準拠の検証を自動化できるため、金融業界で最も導入障壁が低い活用領域です。

金融システムのテストが難しいのは、テストケース自体に業界固有の知識が必要だからです。たとえば、為替レート計算のテストでは、通貨ペアごとの小数点精度、祝日カレンダー、市場クローズ時の処理、タイムゾーンの扱いなど、ドメイン固有の条件を網羅する必要があります。

Before: 手動テスト作成（従来）

開発者が仕様書を読み、テストケースを1つずつ作成。為替計算モジュールのテストに2〜3日を要し、それでもエッジケースの漏れが後日発覚するケースが頻発していました。

After: Claude Codeによるテスト生成

CLAUDE.mdに金融ドメインの制約を定義し、Claude Codeに対象モジュールを読ませることで、以下のテストが自動生成されます。

• 精度テスト: 通貨ペアごとの小数点桁数が仕様どおりか
• 境界値テスト: レート=0、負の値、極端に大きい値での挙動
• 祝日・市場クローズ: 非営業日に約定処理が実行されないことの検証
• タイムゾーン: UTC/JST変換時にレート適用日がずれないことの検証
• 丸め処理: 切り上げ・切り捨て・銀行家丸めの各モードの検証

# CLAUDE.md に追加する金融テスト指示

## テスト生成ルール
- 為替計算は必ず以下の通貨ペアでテストする: USD/JPY, EUR/USD, GBP/JPY
- 金額計算のテストではBigDecimalの精度を明示する（scale=6以上）
- 非営業日判定はJPX休業日カレンダー2026年版を参照する
- 小数点丸めのテストは ROUND_HALF_EVEN（銀行家丸め）を既定とする

所要時間は2〜3日から数時間に短縮され、しかもエッジケースの網羅率が向上しました。ただし、生成されたテストケースの妥当性は、ドメイン知識を持つ開発者が必ずレビューするというフローは省略できません。

COBOLドキュメント自動生成 — 退職するベテランの知識をコードから逆引きする

COBOLで構築された基幹システムの仕様理解は、金融業界において「技術負債」ではなく「事業継続リスク」のレベルです。

メガバンク、地方銀行、保険会社の基幹系システムには、30年以上前に構築されたCOBOLプログラムが現役で稼働しています。当時の開発者の大半は退職済みで、仕様は「コードそのもの」にしか残っていない。新しく配属された開発者が、数万行のCOBOLプログラムを読み解くまでに半年以上かかることも珍しくありません。

Claude CodeによるCOBOLドキュメント生成の実際

Claude CodeにCOBOLのソースファイルを読み込ませると、以下のドキュメントが生成できます。

IDENTIFICATION DIVISION / ENVIRONMENT DIVISIONの要約: プログラム名、作成日、依存ファイル、SPECIAL-NAMESの設定を一覧化。

DATA DIVISIONの構造化: WORKING-STORAGE SECTIONの変数を、用途別にグルーピングしてテーブル形式で出力。PIC句の意味（桁数、符号、小数点位置）を日本語で補足。

PROCEDURE DIVISIONの処理フロー: 各SECTION・PARAGRAPHの処理を自然言語で記述し、PERFORM文・CALL文の呼び出し関係をツリー構造で表現。

重要な注意点: Claude Codeが生成するCOBOLドキュメントは、あくまで「理解を加速するためのたたき台」です。特に以下の点は人間によるレビューが不可欠です。

• COPY句で取り込まれる外部定義の内容（Claude Codeはファイル単体しか見えない場合がある）
• JCLとの連携部分（バッチスケジュール、ファイル割り当て）
• DB2やIMSのデータベースアクセス部分の業務的な意味

CLAUDE.mdでCOBOL読解の精度を上げる

# CLAUDE.md（COBOL基幹系ドキュメント化プロジェクト）

## COBOL固有の指示
- PIC句の解説では、桁数・小数点・符号の実務的な意味を日本語で補足する
- PERFORM THRU の範囲を明示する
- EVALUATE文はswitch-case形式で整理する
- COPY句の参照先ファイルがある場合は、別途読み込んで統合する
- コメント行（* 始まり）に含まれる日本語メモは仕様情報として扱う

## 出力形式
- Markdown形式で出力する
- 変数一覧はテーブル形式にする
- 処理フローは番号付きリストで記述する

AWS Bedrock閉域構成の設計 — セキュリティ部門を説得する技術的根拠

金融機関のセキュリティ部門を説得するには、「安全です」ではなく「データ経路がこうなっている」という技術的事実が必要です。

Anthropic APIを直接利用する場合、データはインターネット経由でAnthropicのサーバーに送信されます。金融機関のセキュリティポリシー上、これを許容できるケースは限定的です。AWS Bedrock経由の構成であれば、以下の技術的根拠でセキュリティ部門との協議を進められます。

構成のポイント

データ経路: 開発環境 → VPCエンドポイント → AWS Bedrock API。インターネットゲートウェイを経由しないため、データが社外ネットワークに出ることはありません。

データ保持: Bedrock経由の場合、入出力データはAWSの利用規約に基づいて処理され、モデルのトレーニングには使用されません。これはAWSのサービス利用規約で明文化されています。

監査ログ: CloudTrailでAPIの呼び出しログを取得でき、「誰が・いつ・どのモデルを・どのリージョンで使ったか」を記録できます。既存のAWS監査基盤にそのまま組み込めます。

アクセス制御: IAMポリシーで、特定のIAMロール・IPアドレス範囲からのみBedrock APIを呼び出せるように制限できます。

Claude CodeのBedrock接続設定

Claude Codeは環境変数でAPIの接続先を切り替えられるため、開発者の操作感は変わりません。

export CLAUDE_CODE_USE_BEDROCK=1
export ANTHROPIC_MODEL=us.anthropic.claude-sonnet-4-20250514
export AWS_REGION=ap-northeast-1
export AWS_PROFILE=finance-dev

この設定をチーム共有の.envrc（direnv）で管理すれば、プロジェクトディレクトリに入った瞬間に自動的にBedrock構成が適用されます。開発者が接続先を意識する必要がなくなる設計にすることが、運用上のミスを防ぐポイントです。

監査証跡の設計 — 「AIが書いたコード」のトレーサビリティ

金融システムでは「誰が書いたか」だけでなく「どのような指示でAIが生成したか」までが監査対象になり得ます。

Claude Codeが生成・修正したコードのトレーサビリティを確保するために、以下の運用設計を推奨します。

Gitコミットレベルの証跡

# CLAUDE.md に追加する監査証跡ルール

## コミットルール
- Claude Codeが生成・修正したコードのコミットには `[ai-generated]` プレフィックスを付ける
- コミットメッセージの本文に、Claude Codeへの指示内容の要約を記載する
- Co-Authored-Byトレーラーを付与する

実際のコミットメッセージ例:

[ai-generated] fix: 為替レート計算の丸め処理をFISC基準に準拠

Claude Codeへの指示: 為替レート計算モジュールの丸め処理を
ROUND_HALF_EVENに統一し、通貨ペアごとの小数点精度を
ISO 4217に準拠させる。

Co-Authored-By: Claude Code <noreply@anthropic.com>

PRレビューレベルの証跡

PRの説明文テンプレートに以下のセクションを設けます。

• AI利用有無: このPRにClaude Codeが生成したコードが含まれるか
• AI生成範囲: どのファイル・関数がAI生成か
• 人間レビュー観点: ドメインロジックの正確性、セキュリティ要件の充足、精度要件の充足

定期監査への対応

四半期ごとの内部監査や外部監査に備え、以下のデータを蓄積しておく運用が望ましいです。

• Claude Code APIの呼び出しログ（CloudTrail経由）
• AI生成コードを含むPRの一覧と、レビュー結果
• AI生成コードに起因するインシデント・バグの有無

導入ロードマップ — 4フェーズで組織に浸透させる

金融機関でのClaude Code導入は、技術検証だけでなく組織の承認プロセスも含めた計画が必要です。

フェーズ1（1〜2か月）: セキュリティ評価とPoC準備

• Bedrock閉域構成の技術検証
• 情報セキュリティ部門・コンプライアンス部門への説明資料作成
• 対象プロジェクトとスコープの選定（テスト生成のみ）
• CLAUDE.mdの初期版作成

フェーズ2（2〜3か月）: 限定チームでのPoC

• 開発チーム2〜3名でテスト生成を実施
• 生成されたテストの品質・精度を定量評価
• 監査証跡の運用フローを確立
• セキュリティ部門への中間報告

フェーズ3（4〜6か月）: スコープ拡大

• ドキュメント生成（COBOL含む）を追加
• API仕様書の自動生成を追加
• PRレビュー支援の試行
• 効果測定レポートの作成（テストカバレッジ向上率、工数削減率）

フェーズ4（7か月目以降）: 本格運用と横展開

• 複数プロジェクトへの展開
• 社内ガイドラインの策定・公開
• 新規プロジェクトでのデフォルトツールとして位置づけ
• 定期的な効果計測と改善

各フェーズ間で、セキュリティ部門・コンプライアンス部門のゲートレビューを挟むことが必須です。これをスキップすると、後から全面的な見直しを求められるリスクがあります。

金融開発チームがCLAUDE.mdに書くべき項目チェックリスト

最後に、金融開発チームのCLAUDE.mdに含めるべき項目を整理します。

カテゴリ	項目例
セキュリティ	本番接続情報の禁止、PCI DSS対象スコープの明示
精度要件	BigDecimal使用の強制、丸めモードの指定
テスト	ダミーデータの生成ルール、必須テストパターン
監査	コミットメッセージ形式、AI生成コード表記
ドメイン	業務用語集、規制名称の正式表記
禁止事項	float/double禁止、console.log禁止、本番API直接呼び出し禁止

まとめ — 規制を「設計制約」として活用する

金融業界でのClaude Code導入は、規制対応のオーバーヘッドがある分、CLAUDE.mdの設計、データ経路の構成、監査証跡の運用を最初から設計に組み込む必要があります。しかし、これらを一度確立すれば、テスト自動化・ドキュメント生成・コードレビュー支援の効果は他業界以上に大きくなります。金融システムは正確性の要求が厳しい分、AIによるテスト網羅やドキュメント整備の恩恵が直接的に品質向上につながるためです。

最初の一歩は、Bedrock閉域構成の技術検証とCLAUDE.mdの規制ルール定義です。この2つが揃えば、セキュリティ部門との協議を具体的な技術情報をもとに進められます。

Claude Codeの全体像については Claude Code完全ガイド を、セキュリティ構成の詳細は Claude Codeのセキュリティと企業導入 を参照してください。