mybook

ユースケース:金融 — リアルタイム不正検知システムの構築

最大の案件が舞い込む

ソウタが Slack の通知に気づいたのは、金曜日の夕方だった。

カイからのDMに、短いメッセージが並んでいた。

「来週月曜、10時に臨時ミーティング。みずほ第一銀行の案件が降ってきた。ソウタがリードFDEだ」

みずほ第一銀行——国内トップ3のメガバンク。ソウタがこれまで担当してきたのは、社員数200〜500人規模の中堅テック企業ばかりだった。メガバンクはまるで別の世界だ。

月曜日、カイはホワイトボードの前に立っていた。

「緊張してるか?」

「正直、はい」ソウタは素直に答えた。「今までの案件とは規模が違いすぎます。年間取引量2億件って、1秒あたり6,000件以上ですよね。ShopFlowのEC案件とは桁が3つ違う」

「規模は違う。でも FDE の動き方は同じだ」カイは静かに言った。「ディスカバリーで課題を掘り、PoC で価値を証明し、デモで意思決定者を動かし、本番で成果を出す。このサイクルは変わらない。変わるのは、各フェーズで求められる精度と、失敗したときの影響の大きさだ」

カイの目が鋭くなった。

「金融は特別な業界だ。間違いが起きたとき、『バグでした、すみません』では済まない。金融庁が出てくる。新聞に載る。顧客の人生が変わる。だから、今日はこの案件の全体像を一緒に設計する」

WARNING

金融業界の FDE 案件では、技術的な正しさだけでなく「規制準拠」と「監査証跡」が常に求められる。コードの1行1行に「なぜこう書いたか」を説明できる状態を保つ必要がある。


顧客プロフィール

カイがホワイトボードに書き出した顧客の概要は、ソウタの想像を超えていた。

みずほ第一銀行の現状

項目
年間取引量2億件(ピーク時 12,000 TPS)
既存不正検知バッチ処理(1日1回、夜間実行)
検知遅延平均24時間
誤検知率(False Positive)15%
年間不正被害額30億円
不正調査チーム40名(うち20名が誤検知の確認作業)

「1日遅れで不正を検知しても、もうお金は海外に送金されている。つまり検知はできても回収ができない」カイが説明した。「先方が Arclight AI に期待しているのは、リアルタイムで取引を評価して、不正の疑いがある取引をその場で止めること」

ステークホルダーマップ

「エンタープライズ案件で最初にやることは?」

「ステークホルダーの特定ですね」ソウタは第8章で学んだ MEDDIC を思い出した。

Loading diagram...

「田中CTOが技術面の最終決裁者。ただし、セキュリティに関わるシステム変更は山田CISOの承認が必須。そして実際にシステムを使うのは佐藤さん率いるリスク管理部の40名だ」

カイが付け加えた。「MEDDIC でいうと、田中CTOが Economic Buyer、山田CISOが技術面の Decision Criteria を握っている。佐藤さんが Champion になってくれるかどうかが、この案件の鍵だ」

INFO

エンタープライズ案件では、技術的な意思決定者とビジネス上の意思決定者が異なることが多い。FDE は両方の言語で話せる必要がある。CTO には「レイテンシ50ms以下」、CFO には「年間25億円の損失回避」と、同じ価値を異なる言葉で伝える。


ディスカバリーフェーズ

SPIN を金融ドメインに適用する

ソウタは第5章で学んだ SPIN フレームワークを頭の中で組み立てながら、ディスカバリーコールに臨んだ。相手はリスク管理部長の佐藤さんだ。

カイが事前にアドバイスしていた。「金融の人間は数字で話す。感覚的な表現は信用されない。すべてを定量的に語れ」

以下は、ソウタが実施したディスカバリーコールの要約だ。

S(状況質問)

ソウタ:「現在の不正検知システムでは、1日の取引データをどのタイミングで処理されていますか?」

佐藤:「夜間バッチです。21時に当日分を集計して、翌朝6時にレポートが出ます。調査チームは朝8時からそのレポートを確認して、怪しい取引をピックアップしています」

P(問題質問)

ソウタ:「朝8時にレポートを確認するということは、前日の午前中の不正取引は、検知まで最大20時間以上かかる計算になりますね。その間に被害が拡大したケースはありますか?」

佐藤:「ありますよ。先月も海外送金の連続不正があって、朝のレポートで気づいたときには既に4件、合計2,800万円が送金済みでした。1件目の取引の時点で止められていれば、被害は700万円で済んだはずです」

I(影響質問)

ソウタ:「年間で見たとき、このタイムラグが原因で回収不能になった被害額はどのくらいですか?」

佐藤:「昨年度は約28億円です。検知自体はできていても、回収が間に合わないケースが全体の83%を占めています」

N(解決価値質問)

ソウタ:「もし取引の発生から100ミリ秒以内にリスク判定ができて、高リスク取引を自動で一時停止できたとしたら、どのくらいの被害を防げると見積もれますか?」

佐藤:「……正直、それが実現できるなら、回収不能だった28億円の大半を止められる可能性があります。ただ、本当にそんな速度で処理できるんですか?」

カイが後で振り返った。「最後の佐藤さんの質問——『本当にできるんですか?』——これが出たら勝ちだ。相手が自分から可能性に興味を持ち始めている。この瞬間を作れるかどうかが、ディスカバリーの成否を分ける」

現行アーキテクチャの把握

ソウタはディスカバリーで聞き出した情報をもとに、現行システムの構成を整理した。

Loading diagram...

「全部が直列で、リアルタイム性がゼロだ」ソウタは図を見て呟いた。

「そう。だからこそ Arclight AI の出番がある」カイが頷いた。「ただし、勘定系を触ることは絶対にない。金融の勘定系は聖域だ。我々は横から取引データのストリームを受け取って、リアルタイムにスコアリングする。そして結果だけを返す」

WARNING

金融系システムで「勘定系を直接変更する」提案は絶対にしない。勘定系は数十年の歴史を持つ基幹システムであり、変更には数ヶ月の監査プロセスが必要。FDE が提案すべきは、既存システムに影響を与えないサイドカー型のアーキテクチャだ。

Pain-to-Value マトリクス

ソウタはディスカバリーの結果を一枚の表にまとめた。

課題痛みの度合いビジネスインパクトArclight で解決可能か
検知遅延(24h)極大年間28億円の損失可能(リアルタイム推論)
誤検知率15%調査員20名分の工数浪費可能(MLモデル精度向上)
ルールの手動更新新手口への対応に2週間可能(モデル再学習)
監査レポート手動作成月40時間の作業部分的(ログ自動集約)

「上の2つ——検知遅延と誤検知率——これが PoC で証明すべきコアバリューだ」カイが指差した。


PoC フェーズ

SMART 成功基準の設計

ソウタは第7章で学んだ PoC 設計の原則に従い、佐藤さんと一緒に成功基準を定義した。

基準指標目標値測定方法
Specificエンドツーエンドのレイテンシ100ms 以下p99 レイテンシ計測
MeasurableFalse Positive Rate5% 以下過去3ヶ月の取引データで検証
Achievable既存システムとの並行稼働勘定系に影響なし並行稼働時のパフォーマンス監視
Relevant不正検知率(Recall)95% 以上既知の不正パターンでテスト
Time-boundPoC 期間2週間日次チェックポイント

「2週間は短いですね」ソウタが不安を口にした。

「短い方がいい」カイが即答した。「金融機関のPoC が長引くと、途中でステークホルダーが変わったり、別の優先案件が割り込んでくる。2週間で結果を出して、そのまま意思決定に持ち込むのがベストだ」

PoC アーキテクチャ

Loading diagram...

「勘定系からは Change Data Capture でリアルタイムに取引イベントを Kinesis に流す。Rails API がそのストリームを受けて、SageMaker 上のモデルでスコアリングする。高リスクと判定されたら即座に通知を飛ばし、すべてのログは S3 に保存して監査に備える」

Transaction モデルとリスクスコアリング

# app/models/transaction.rb
class Transaction < ApplicationRecord
  belongs_to :account
  has_one :risk_assessment, dependent: :destroy
 
  enum :status, {
    pending:   0,
    approved:  1,
    flagged:   2,
    blocked:   3,
    reviewed:  4
  }
 
  scope :high_risk, -> { joins(:risk_assessment).where("risk_assessments.score >= ?", 0.8) }
  scope :recent, -> { where("created_at >= ?", 1.hour.ago) }
 
  validates :amount, presence: true, numericality: { greater_than: 0 }
  validates :currency, presence: true, inclusion: { in: %w[JPY USD EUR GBP] }
  validates :source_account, :destination_account, presence: true
 
  def velocity_score
    recent_count = account.transactions.where("created_at >= ?", 1.hour.ago).count
    recent_total = account.transactions.where("created_at >= ?", 1.hour.ago).sum(:amount)
 
    {
      count_per_hour: recent_count,
      total_per_hour: recent_total,
      exceeds_threshold: recent_count > 10 || recent_total > 1_000_000
    }
  end
end
# app/models/risk_assessment.rb
class RiskAssessment < ApplicationRecord
  belongs_to :transaction
 
  validates :score, presence: true, numericality: { in: 0.0..1.0 }
  validates :model_version, presence: true
 
  def high_risk?
    score >= 0.8
  end
 
  def medium_risk?
    score >= 0.5 && score < 0.8
  end
end

FraudDetectionService

# app/services/fraud_detection_service.rb
class FraudDetectionService
  RISK_THRESHOLD_HIGH = 0.8
  RISK_THRESHOLD_MEDIUM = 0.5
 
  def initialize(transaction)
    @transaction = transaction
    @client = Aws::SageMakerRuntime::Client.new(region: "ap-northeast-1")
  end
 
  def evaluate
    start_time = Process.clock_gettime(Process::CLOCK_MONOTONIC)
 
    features = build_feature_vector
    ml_score = invoke_ml_model(features)
    rule_score = apply_rule_engine
    combined_score = combine_scores(ml_score, rule_score)
 
    elapsed_ms = ((Process.clock_gettime(Process::CLOCK_MONOTONIC) - start_time) * 1000).round(2)
 
    assessment = @transaction.create_risk_assessment!(
      score: combined_score,
      ml_score: ml_score,
      rule_score: rule_score,
      model_version: ENV.fetch("MODEL_VERSION", "v1.0"),
      latency_ms: elapsed_ms,
      features: features.to_json
    )
 
    take_action(assessment)
    assessment
  end
 
  private
 
  def build_feature_vector
    velocity = @transaction.velocity_score
 
    {
      amount: @transaction.amount,
      currency: @transaction.currency,
      hour_of_day: @transaction.created_at.hour,
      day_of_week: @transaction.created_at.wday,
      is_international: @transaction.source_account[0..1] != @transaction.destination_account[0..1],
      velocity_count: velocity[:count_per_hour],
      velocity_total: velocity[:total_per_hour],
      account_age_days: @transaction.account.created_at.to_date.mjd - Date.today.mjd
    }
  end
 
  def invoke_ml_model(features)
    response = @client.invoke_endpoint(
      endpoint_name: ENV.fetch("SAGEMAKER_ENDPOINT"),
      content_type: "application/json",
      body: { features: features.values }.to_json
    )
 
    JSON.parse(response.body.read)["score"]
  rescue Aws::SageMakerRuntime::Errors::ServiceError => e
    Rails.logger.error("[FraudDetection] SageMaker error: #{e.message}")
    fallback_score(features)
  end
 
  def apply_rule_engine
    score = 0.0
 
    # ルール1: 深夜の高額送金
    if @transaction.created_at.hour.between?(0, 5) && @transaction.amount > 500_000
      score += 0.3
    end
 
    # ルール2: 新規口座からの大量送金
    if @transaction.account.created_at > 30.days.ago && @transaction.amount > 1_000_000
      score += 0.4
    end
 
    # ルール3: 短時間の連続取引
    if @transaction.velocity_score[:exceeds_threshold]
      score += 0.3
    end
 
    [score, 1.0].min
  end
 
  def combine_scores(ml_score, rule_score)
    # ML モデル 70%、ルールエンジン 30% の重み付け
    (ml_score * 0.7 + rule_score * 0.3).round(4)
  end
 
  def fallback_score(features)
    # SageMaker 障害時はルールベースにフォールバック
    Rails.logger.warn("[FraudDetection] Using fallback scoring")
    apply_rule_engine
  end
 
  def take_action(assessment)
    case
    when assessment.high_risk?
      @transaction.update!(status: :blocked)
      FraudAlertJob.perform_later(@transaction.id, severity: :critical)
    when assessment.medium_risk?
      @transaction.update!(status: :flagged)
      FraudAlertJob.perform_later(@transaction.id, severity: :warning)
    else
      @transaction.update!(status: :approved)
    end
  end
end

INFO

ML モデルが障害を起こした場合のフォールバック戦略は金融システムでは必須。SageMaker が応答しなくても、ルールベースのスコアリングで最低限の防御を維持する。「MLが死んだら全取引素通り」は絶対に許されない。

リアルタイム通知システム

# app/jobs/fraud_alert_job.rb
class FraudAlertJob < ApplicationJob
  queue_as :critical
 
  retry_on StandardError, wait: :polynomially_longer, attempts: 5
 
  def perform(transaction_id, severity:)
    transaction = Transaction.find(transaction_id)
    assessment = transaction.risk_assessment
 
    # Webhook 通知(みずほ第一銀行の監視システムへ)
    payload = {
      event: "fraud_alert",
      transaction_id: transaction.id,
      account_id: transaction.account_id,
      amount: transaction.amount,
      currency: transaction.currency,
      risk_score: assessment.score,
      severity: severity,
      timestamp: Time.current.iso8601,
      model_version: assessment.model_version
    }
 
    response = Faraday.post(
      ENV.fetch("BANK_WEBHOOK_URL"),
      payload.to_json,
      {
        "Content-Type" => "application/json",
        "X-Signature" => generate_hmac(payload),
        "X-Timestamp" => Time.current.to_i.to_s
      }
    )
 
    unless response.success?
      Rails.logger.error("[FraudAlert] Webhook failed: #{response.status}")
      raise "Webhook delivery failed with status #{response.status}"
    end
 
    AuditLog.create!(
      event_type: "fraud_alert_sent",
      payload: payload.to_json,
      response_status: response.status
    )
  end
 
  private
 
  def generate_hmac(payload)
    OpenSSL::HMAC.hexdigest(
      "SHA256",
      ENV.fetch("WEBHOOK_SECRET"),
      payload.to_json
    )
  end
end

2週間の PoC タイムライン

タスクチェックポイント
Day 1-2環境構築、CDC パイプライン接続テストデータの疎通確認
Day 3-4ML モデルデプロイ、API 実装単体レイテンシ計測
Day 5-6ルールエンジン実装、結合テストエンドツーエンド処理確認
Day 7-8過去データでの精度検証False Positive Rate 測定
Day 9負荷テスト(12,000 TPS)p99 レイテンシ確認
Day 10フォールバック・障害テストSageMaker 障害時の動作確認
Day 11-12並行稼働テスト勘定系への影響ゼロを確認
Day 13結果取りまとめ、デモ準備成功基準の達成判定
Day 14経営層向けデモGo/No-Go 判定

ソウタは毎朝9時に佐藤さんと15分のスタンドアップを行い、進捗と課題を共有した。Day 9 の負荷テストで p99 レイテンシが 120ms に跳ねたとき、すぐにボトルネックを特定して SageMaker のインスタンスサイズを調整し、翌日には 68ms まで改善した。

「問題が起きたこと自体は悪くない。問題を24時間以内に解決して、翌日の朝会で報告したこと——それが信頼を作る」カイが評価した。


デモ&プレゼン

経営層に見せる「Wow Moment」

Day 14、ソウタは取締役会議室に立っていた。目の前には田中CTO、山田CISO、佐藤リスク管理部長、そしてCFOの鈴木さんまでいた。

カイが前夜に叩き込んだアドバイスが頭の中で響いていた。

「技術者向けのデモと経営層向けのデモはまったく別物だ。技術者にはアーキテクチャ図とレイテンシのグラフを見せればいい。でも経営層が知りたいのは3つだけ。『いくら儲かるのか』『リスクは何か』『いつから効果が出るのか』」

ソウタはデモを3幕構成で設計した。

第1幕:現状の痛み(2分)

「昨年度、不正取引による被害額は30億円。うち28億円は、検知の遅延が原因で回収できませんでした」——佐藤さんから聞いた数字をそのまま使う。自社の数字だから、経営層は他人事ではいられない。

第2幕:Wow Moment(5分)

ソウタはライブデモを実行した。画面にはリアルタイムの取引ダッシュボードが映っている。

「今から、実際に不正取引をシミュレートします」

ソウタがボタンを押すと、画面上で新規口座から深夜帯に100万円の海外送金が発生した。0.05秒後、取引がオレンジ色にハイライトされ「BLOCKED — Risk Score: 0.92」と表示された。同時に、佐藤さんのデモ用端末に通知が飛んだ。

「50ミリ秒です。バッチ処理の24時間と比較して、170万倍速くなりました」

会議室が一瞬、静まり返った。CFOの鈴木さんが身を乗り出した。

第3幕:ROI(3分)

「PoC の結果、過去3ヶ月の実データに対して検知率95.3%、誤検知率3.2%を達成しました。年間の損失回避額は推定25億円。導入コストと運用コストを差し引いても、初年度で10倍以上のROIが見込めます」

INFO

経営層向けデモの鉄則:最初に痛みを思い出させ、次に解決策を目の前で見せ、最後に数字で投資判断の材料を提供する。技術的な詳細は聞かれたら答えればいい。自分から語るのは「価値」だけ。

質疑応答で信頼を勝ち取る

山田CISOが質問した。「ML モデルが間違った判定を出した場合、責任の所在はどうなりますか?」

ソウタは落ち着いて答えた。「すべての判定には監査ログが残ります。モデルのバージョン、入力特徴量、スコアの算出根拠がすべて S3 に保存されています。また、高リスク判定による取引ブロックは一時停止であり、最終判断はオペレータが行う運用設計になっています」

田中CTOも聞いた。「勘定系への影響は?」

「PoC 期間中、12日間の並行稼働で勘定系のパフォーマンスに影響はゼロでした。CDC による読み取りのみで、書き込みは一切行いません」

鈴木CFOが最後に聞いた。「いつから効果が出ますか?」

「本番導入から1ヶ月以内に効果が見え始めます。3ヶ月で安定稼働に入り、6ヶ月後に年間効果を正式に測定できます」


本番デプロイ

フェーズドマイグレーション戦略

デモの翌週、Go の判定が出た。ソウタは本番導入の設計に入った。

カイが釘を刺した。「金融システムのビッグバンリリースは自殺行為だ。段階的に移行する」

Loading diagram...

Phase 1(2週間):監視モード——リアルタイムシステムは動かすが、取引をブロックしない。既存バッチシステムと結果を比較して精度を検証する。

Phase 2(2週間):並行判定——リアルタイムシステムがアラートを出し始めるが、ブロック判断は人間が行う。オペレータが判定精度を体感する。

Phase 3(4週間):段階移行——低リスクカテゴリから順にリアルタイムシステムに判定を委譲する。ATM取引から始めて、振込、海外送金と段階的に拡大。

Phase 4(2週間):完全移行——全取引カテゴリがリアルタイムシステムで処理される。バッチシステムはバックアップとして残す。

金融規制対応

ソウタは金融庁のガイドラインと PCI DSS の要件を整理した。

規制要件対応策
金融庁 AI ガイドラインモデルの判定根拠を説明可能にする(特徴量の重要度ログ)
PCI DSS 要件3カード番号はトークン化して保存、平文は一切保持しない
PCI DSS 要件10すべてのアクセスを監査ログに記録、90日間保持
個人情報保護法取引データの匿名化、アクセス権限の最小化
FISC 安全対策基準障害時のフォールバック、RTO 5分以内
# app/services/compliance/audit_logger.rb
module Compliance
  class AuditLogger
    def self.log(event_type:, actor:, resource:, details: {})
      AuditLog.create!(
        event_type: event_type,
        actor_id: actor.id,
        actor_type: actor.class.name,
        resource_id: resource.id,
        resource_type: resource.class.name,
        details: details.to_json,
        ip_address: Current.ip_address,
        timestamp: Time.current,
        checksum: generate_checksum(event_type, actor, resource, details)
      )
    end
 
    def self.generate_checksum(event_type, actor, resource, details)
      data = "#{event_type}:#{actor.id}:#{resource.id}:#{details.to_json}:#{Time.current.to_i}"
      Digest::SHA256.hexdigest(data)
    end
  end
end

WARNING

金融システムの監査ログは、改ざん検知のためにチェックサムを付与する。「ログを書きました」だけでは不十分で、「ログが改ざんされていないことを証明できる」状態にする必要がある。

インシデントレスポンス計画

ソウタは第14章で学んだインシデント対応の原則を、金融システム向けにカスタマイズした。

レベル条件対応エスカレーション先
P1システム全停止即時フォールバック、5分以内復旧CTO + CISO + Arclight SRE
P2誤検知率が10%超過モデルロールバックリスク管理部長 + Arclight FDE
P3レイテンシ劣化(500ms超)スケールアウト、調査開始Arclight FDE
P4単一ノード障害自動フェイルオーバー自動通知のみ

「P1 のとき、最初にやることは何だ?」カイが聞いた。

「バッチシステムへの切り戻しです。復旧より先に、被害の拡大を止める」

「正解。金融では『直す前に止める』が鉄則だ」


成果測定

本番稼働から3ヶ月後、ソウタは佐藤さんと一緒に成果レポートをまとめた。

Before / After

指標BeforeAfter改善率
検知レイテンシ24時間50ms(p99)170万倍
誤検知率15%3.2%79%減
不正検知率72%95.3%32%向上
年間損失回避額25億円
調査チーム工数40名22名(18名を他業務へ)45%削減

ROI 計算

項目金額
年間損失回避25億円
人件費削減(18名分)1.8億円
年間効果合計26.8億円
初期導入コスト1.2億円
年間運用コスト0.6億円
初年度 ROI1,389%

ソウタが佐藤さんに結果を見せたとき、佐藤さんは静かにこう言った。

「ソウタさん、3ヶ月前にディスカバリーで『本当にできるんですか?』と聞いたことを覚えていますか。あの質問をした自分が恥ずかしいです」

「いえ、あの質問があったから、僕たちは PoC の成功基準を厳密に設計できました。あの懐疑的な姿勢こそが、プロジェクトを成功に導いたんです」

INFO

FDE の成果測定は「技術指標」と「ビジネス指標」の両方を提示する。技術者にはレイテンシと精度を、経営層には損失回避額と ROI を。同じ成果を異なるレンズで見せることで、組織全体の合意を形成する。


振り返りと学び

案件がひと段落した金曜日の夕方、ソウタとカイは近所のカフェにいた。

「金融の案件を通じて、何が一番変わった?」カイがコーヒーを啜りながら聞いた。

ソウタは少し考えてから答えた。

「技術力だけでは足りないと、本当の意味で理解しました。規制を理解すること、ステークホルダーの力関係を読むこと、経営層の言語で話すこと——全部がセットで初めて FDE の仕事が成立するんだと」

「他には?」

「Phase 2 で現場のオペレータと一緒に誤検知を1件1件確認した時間が、一番価値がありました。佐藤さんのチームが『このシステムなら信用できる』と言ってくれたのは、精度が高いからじゃなくて、僕たちが現場に寄り添って一緒に改善したからだと思います」

カイが微笑んだ。「規制産業での FDE の仕事は、他の業界の2倍しんどい。でも、成功したときのインパクトも2倍だ。28億円の損失を止めるシステムを、2週間の PoC から始めて形にした。これがFDEの醍醐味だ」

カイが最後に付け加えた。

「もう一つ。今回の案件で一番大事だったのは、勘定系を触らなかったことだ。やらないことを決める判断力——これが規制産業で信頼を得る最大のポイントだ。できることを見せるより、やらないことを明言する方が、金融の人間には刺さる」


実践演習

演習1:ディスカバリー質問を設計せよ

保険会社「ジャパンライフ保険」が、保険金請求の不正検知を自動化したいと問い合わせてきた。SPIN フレームワークに基づいて、ディスカバリーコールで使う質問を各カテゴリ3問、計12問設計せよ。

  • S(状況):現在の請求審査プロセスの流れ、審査にかかる時間、自動化の現状
  • P(問題):誤払いの頻度、審査のボトルネック、顧客からのクレーム
  • I(影響):年間の誤払い金額、審査遅延による解約率、コンプライアンスリスク
  • N(解決価値):リアルタイム審査が可能になった場合の効果を相手に語らせる

演習2:MEDDIC スコアリングを完成させよ

以下の情報をもとに、みずほ第一銀行案件の MEDDIC スコアリングシートを埋めよ。

要素問いこの案件での回答
Metrics成功の定量指標は?(自分で考えよ)
Economic Buyer最終決裁者は誰?(本章から特定せよ)
Decision Criteria採用基準は?(技術・ビジネス両面で)
Decision Process決裁のプロセスは?(本章の流れから推測せよ)
Identify Pain核心的な痛みは?(ディスカバリーから抽出せよ)
Champion社内推進者は誰?(本章から特定せよ)

演習3:インシデント対応のエスカレーションプランを作成せよ

以下のシナリオに対するエスカレーションプランを作成せよ。

シナリオ: 本番稼働中、ML モデルの更新デプロイ後に誤検知率が15%に急増。正常な取引が大量にブロックされ、ATM での引き出しが全国的に遅延している。

以下の観点で回答すること:

  1. 最初の15分で何をするか
  2. 誰に、どの順番で連絡するか
  3. 暫定対応と恒久対応をどう分けるか
  4. 事後のポストモーテムで何を報告するか

INFO

金融ユースケースの核心:FDE は技術者であると同時に、規制の翻訳者であり、ビジネス価値の証明者である。ディスカバリーで課題を定量化し、PoC で価値を証明し、フェーズドデプロイでリスクを管理し、成果を数字で語る。この一連のサイクルを高い精度で回せることが、エンタープライズ FDE の真の実力だ。