【実務・中級編】ビジネスインパクト分析（BIA）とAIの可用性 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

現場の最前線で戦うエンジニア諸君、お疲れ様。
今日は「AIを導入したはいいが、もし明日AIが止まったらどうなるか？」という、経営層も現場も目を背けがちな、しかしエンジニアとしては避けて通れない「ビジネスインパクト分析（BIA）」と、その先にある可用性確保の話をしよう。

多くの開発現場では、AIの推論精度やプロンプトの最適化には血道を上げるが、AIシステムが「ダウンした瞬間」のシミュレーションが甘い。RTO（目標復旧時間）を議論する際、「まあ、クラウドだし落ちないでしょ」という性善説に賭けるのは、セキュリティの専門家からすれば自殺行為に等しい。

AIシステムにおける「見えない停止」というリスク

AIシステムが停止する原因は、単なるサーバーダウンだけではない。攻撃者が狙うのは、「推論サービスの過負荷によるDoS」や「外部APIの依存関係を突いたサービス拒否」だ。

例えば、ユーザーからの入力を受け取ってAIに投げるだけの単純なWebアプリを想像してほしい。ここで、攻撃者が計算コストの高い（＝AIの処理時間を極端に長くさせる）クエリを大量に投げ込んだらどうなるか？ GPUリソースは枯渇し、キューは詰まり、システムは完全にフリーズする。これが「可用性への攻撃」だ。

ビジネスインパクト分析（BIA）の鉄則

AIシステムの可用性を語る際、以下の3つの視点をBIAに組み込んでほしい。

1. AIの劣化モード（Degraded Mode）の定義: AIが応答不能になった際、ルールベースのフォールバック処理に切り替えられるか？
2. RPOの再定義: AIが生成したデータ（ベクトルDBのインデックス等）が失われた際、どの時点まで再学習・再構築が必要か。
3. 依存先APIのタイムアウト戦略: AIモデルが外部API（OpenAIやAnthropic等）に依存している場合、そのAPIが遅延した瞬間に自社システム全体が引きずり込まれない設計になっているか。

実装で守る：サーキットブレーカーによる可用性確保

AIシステムが停止した際にアプリ全体が道連れにならないよう、GoやPythonのバックエンドでは「サーキットブレーカー」を実装するのが定石だ。以下は、Pythonで外部AI推論APIを呼び出す際の、簡易的かつ実用的なセキュア実装サンプルだ。

import time
import requests
from circuitbreaker import circuit  # pip install circuitbreaker

# AI推論APIへの接続設定
# 失敗が連続した場合は即座に遮断し、システム全体の崩壊を防ぐ
@circuit(failure_threshold=3, recovery_timeout=30)
def call_ai_inference_service(payload):
    """
    AI推論サービスを呼び出す。タイムアウトを厳格に設定し、
    サービスがハングアップしてもアプリ全体が停止しないようにする。
    """
    response = requests.post(
        "https://ai-model-endpoint.internal/predict",
        json=payload,
        timeout=2.0  # 2秒以内にレスポンスがなければ即断つ
    )
    response.raise_for_status()
    return response.json()

def get_ai_response(user_input):
    try:
        return call_ai_inference_service({"text": user_input})
    except Exception as e:
        # ログには詳細を残すが、ユーザーには安全なデフォルト値を返す
        print(f"[CRITICAL] AI Service Error: {e}")
        return {"result": "現在AIサービスが混雑しております。しばらくしてからお試しください。"}

インフラレベルでの防御：Nginxによるレートリミット

アプリ側だけでなく、Nginxなどのゲートウェイ層でAIサービスへのアクセスを絞る設定は必須だ。攻撃者がAPIを連打してリソースを枯渇させる手法を防ぐ。

# Nginxの設定ファイル抜粋
# AI推論エンドポイントへのアクセスをIP単位で制限する

limit_req_zone $binary_remote_addr zone=ai_limit:10m rate=5r/s;

server {
    location /api/v1/ai-inference {
        # 1秒間に5リクエストを超えたら429 Too Many Requestsを返す
        limit_req zone=ai_limit burst=10 nodelay;
        
        proxy_pass http://ai_backend;
        # タイムアウトを短く設定し、バックエンドの詰まりを防止
        proxy_read_timeout 3s;
    }
}

最後に：エンジニアが持つべき視点

セキュリティとは、「何を守るか」を決めることだが、可用性とは「何が壊れてもビジネスを継続させるか」を決めることだ。

AIシステムを構築する際は、「AIが動かなくなったとき、ユーザーに何を見せるか」を設計の初期段階で定義してくれ。try-exceptを空にして隠蔽するのは論外だ。攻撃者はエラーメッセージの「間」からシステムの脆弱性を嗅ぎ分けてくる。

BIAは単なる書類仕事じゃない。君たちが書くコードの一行一行が、攻撃に対する盾であり、復旧への最短ルートになる。次回のリリースでは、ぜひ「AIが全滅したときの挙動」をテストケースに入れてみてほしい。それが、プロのエンジニアの仕事だ。