金融機関でAIエージェントを導入するなら—権限管理とデータ分離の実装アーキテクチャ（モデルケース）

顧客情報を直接扱う金融機関で AI エージェントを導入する場合、最大の壁は「権限管理」だ。本記事では大手銀行の行内業務支援エージェントをモデルケースとして、JIT 権限付与・データ分離・監査ログの実装アーキテクチャを示す。比較すべき代替案、実装で詰まりやすいポイント、運用で見るべき指標、そして他業界への転用可能性まで含めて整理する。

注意：本記事は、大手銀行の行内向け業務支援エージェントを想定したモデルケースです。特定の金融機関での実績ではなく、規模・数値は設計検討のための想定値です。

1. 想定するプロジェクト

国内の大手銀行が、行内向け業務支援エージェントを構築するケースを想定する。

• 利用者：営業店行員（窓口・後方事務）約 8,000 名（想定）
• 想定ユースケース：顧客対応中の照会、商品案内資料の作成、各種帳票の起票補助
• データソース：顧客マスタ DB、取引履歴 DB、商品マスタ、規程・マニュアル、過去の対応履歴
• 要件：自然言語で質問・指示できるが、行員の権限階層を絶対に超えない

最大の論点は、「便利になるほど、過剰なアクセスのリスクも上がる」 というジレンマだ。

比較すべき 3 案

推奨する案 C のアーキテクチャを、以下で詳述する。

2. 推奨アーキテクチャ

[行員 Alice]
    │
    │  「顧客 C-12345 の今月の取引を教えて」
    ▼
[Layer 1: インテント解析器]
    │  intent: { action: "query_transactions",
    │            customer_id: "C-12345",
    │            period: "2026-03" }
    │  必要スコープ: read:customer:C-12345, read:transaction:C-12345:2026-03
    ▼
[Layer 2: 権限発行ゲートウェイ]
    │  Alice のロール権限と照合 → スコープ内なら JIT トークン発行（30秒）
    │  ↓ Alice の権限を超えていれば「権限不足です」とユーザー通知
    ▼
[Layer 3: エージェント実行]
    │  JIT トークンを添えて顧客 DB / 取引 DB を呼び出し
    ▼
[Layer 4: 監査ログ]
    │  intent / 発行スコープ / 実アクセス / 出力 を構造化保存
    ▼
[行員 Alice に応答]

Layer 1: インテント解析

行員の自然言語入力を、構造化されたインテントに変換する：

{
  "user": "alice@bank.example.com",
  "session_id": "sess-2026-03-12-abc",
  "intent_type": "query_transactions",
  "subject": {
    "customer_id": "C-12345"
  },
  "constraints": {
    "period_start": "2026-03-01",
    "period_end": "2026-03-31"
  },
  "required_scopes": [
    "read:customer:C-12345",
    "read:transaction:C-12345:2026-03"
  ],
  "confidence": 0.94
}

confidence が閾値（例：0.85）を下回る場合、エージェントは行員に 「次のうちどれをご希望ですか？」 と確認を返す。曖昧な質問のまま広い権限で実行することを禁止する設計。

Layer 2: JIT 権限発行

Alice のロール権限と、要求スコープを照合：

• スコープ ⊆ ロール権限 → JIT トークン発行（30 秒）
• スコープ ⊄ ロール権限 → 拒否、「あなたの権限では参照できません」と通知

JIT トークン構造：

{
  "iss": "bank-ai-gateway",
  "sub": "alice@bank.example.com",
  "act": { "sub": "agent:branch-assistant-v1" },
  "intent_id": "intent-2026-03-12-xyz",
  "scope": "read:customer:C-12345 read:transaction:C-12345:2026-03",
  "iat": 1773325391,
  "exp": 1773325421,
  "audit_id": "req-2026-03-12-987"
}

ポイント：

• sub に行員 Alice（責任主体）、act に代理で実行するエージェントを明示（RFC 8693 の actor クレーム）
• scope は RFC 8693 に従いスペース区切りの文字列で表し、ID 単位まで絞る（ワイルドカード read:customer:* は禁止）
• intent_id で監査ログと突合可能

Layer 3: エージェント実行

エージェントは MCP サーバー（顧客 DB ラッパー）に対し、JIT トークン付きで呼び出し。サーバー側はトークンの scope を検証し、許可された ID のみアクセス可能。

万一エージェントが「ついで参照」しようとしても、JIT トークンには C-12345 しか含まれていないので、別顧客のレコードはアクセスエラーになる。

Layer 4: 監査ログ

各リクエストについて以下の 5 点を構造化して保存：

{
  "audit_id": "req-2026-03-12-987",
  "timestamp": "2026-03-12T14:23:11Z",
  "user": "alice@bank.example.com",
  "intent": { "...": "..." },
  "issued_scopes": ["read:customer:C-12345", "..."],
  "actual_accesses": [
    { "resource": "customer:C-12345", "method": "READ", "result": "success" },
    { "resource": "transaction:C-12345:2026-03", "method": "READ", "result": "success" }
  ],
  "agent_response_summary": "...（出力テキストの要約とハッシュ）",
  "anomalies": []
}

anomalies には「インテントとアクセスの乖離」「未発行スコープへのアクセス試行」などが記録され、即時アラートの対象になる。

3. 実装で詰まりやすいポイント

a. インテント解析の精度

汎用の LLM でインテントを抽出する場合は、金融固有の表現（「先日付指定の振込」「予約振込の取消」等）を含む自社の評価データで誤解釈率を測定する必要がある。

→ 行内表現でラベル付きデータを作り、独立した小型の分類モデル（DeBERTa 系など）でインテント分類器を学習させる方法が有効な選択肢になる。精度は必ず自社の評価データで測定し、閾値の設定に反映する。

b. 「曖昧な質問」の UX

「権限不足です」とエラーで返すと行員のフラストレーションが上がる。代わりに：

• なぜできないかを 1 行で説明
• できる代替操作を 1〜2 つ提示
• 必要なら「上長承認の依頼を作成」のリンクを提示

単なるエラー表示より、行員の納得感を高めやすい。

c. 監査ログの量

1 行員あたり 1 日 200 リクエストと仮定すると、200 × 8,000 名 × 30 日 = 約 4,800 万件 / 月になる。

ログを RDB に直接書くと負荷が膨大になるため、次のような構成が考えられる：

• 即時書き込みは Apache Kafka へ
• ストリーム処理で異常検知（リアルタイム）
• バッチで列指向ストレージ（Amazon S3 上の Apache Parquet）に保管
• 監査照会用に Amazon Athena / Trino でクエリ

保管期間は、各社の監査方針・記録保存規程に合わせて決める（金融機関では長期になりやすい）。

d. 「未遂」の重要性

最も重要なシグナルは「AI が見ようとしたが、できなかった」アクセス。これが攻撃や誤動作の早期警報となる。

未遂ログを別カテゴリで集計し、行員ごと・エージェントバージョンごとに分析するとよい。

4. 運用で見るべき指標と設計原則

見るべき指標

• 業務効率：1 行員あたりの日次対応時間、窓口待ち時間
• 安全性：インテントとアクセスの乖離件数、未発行スコープへのアクセス試行（未遂）件数
• 品質：インテント解析の誤判定率、確認質問を返した割合
• 受容性：行員満足度（NPS・CSAT 等）、「権限不足」応答後の離脱率

設計原則

• インテント宣言の精度が全体の品質を決める：ここが曖昧だと下流すべてが緩む
• 行員の「権限超え」を丁寧に断る UX が効く：単なるエラーではなく説明と代替提示
• 監査ログは『未遂』を最重要シグナルとする：成功アクセスより、失敗アクセスのパターンが攻撃検知に効く
• JIT 権限の TTL はできるだけ短くする：業務影響を見ながら、数分から数十秒程度まで短縮を検討する
• インテント解析モデルは独立進化させる：本体 LLM の更新と切り離してリリース可能

5. 適用可能な業界

このパターンは金融に限らず、次の業界に広く転用できる：

共通条件は「個別レコードへのアクセス制御が厳格な業界」で、すなわち「個人を一意に識別できるデータを扱う業界」のほぼ全てに適用できる。

6. 採用すべきでないケース

逆に、このパターンが過剰になるケースもある：

• 公開情報のみを扱う（社外向け FAQ ボット等）
• 個人を特定しない統計データのみ扱う
• 利用者と対象データが完全に同一（個人タスク管理 AI 等）

これらは伝統的な認証 + RBAC で十分。過剰設計は維持コストを跳ね上げるため、要件をしっかり見極める。

7. 採用に向けた最初の一歩

検討中の組織には、次の順序を勧めたい：

1. 対象業務の「最も繊細な質問・指示」を 20 件サンプリング
2. 各サンプルについて、必要な最小スコープを手動で書き出す
3. インテント分類のパターンを抽出
4. 小規模な検証環境で 4 層構成を実装
5. 1 ヶ月のシャドー運用（ログのみ取得、ブロックしない）
6. ブロックモードへ段階移行

最初の 1〜3 を内製で進めるだけで、「JIT を導入すべきかどうか」の判断材料は十分得られる。

同様の構成のご相談、社内 PoC の設計支援については 無料相談 で受け付けています。事業ドメインを伺ったうえで、最小構成と段階的展開の絵を一緒に描きます。