「全社で『可用性99%』『精度90%』を決めれば安心」――数値だけで会議を終わらせると、本番で画面表示のズレ、PDFの欠落、問い合わせ一次対応の遅延といった現場負荷が噴出します。本稿は、情シスと現場が部署横断でAIを導入する際に、会議で今すぐ決めるべき項目、PoCでの合否基準、問い合わせ→恒久対応までの実務テンプレを、現場で使える具体ルールに落とし込む実務ハンドブックです。
要点（本文を読んで得られる判断）
横断導入に必要なSLAは「可用性／精度の数値」ではなく、ユースケースごとに次の4軸で定義することが重要です：影響（誰にどれだけ迷惑か）、検出可能性（いつどう気づけるか）、責任（誰が対処するか）、頻度／スケール（どれだけ頻発するか）。本文を読めば、初回キックオフで議事録に書くべき3項目、PoCで要求すべきサンプル数・合否基準、実務で運用できるチケット仕様まで持ち帰れます。
全社SLAの誤解を壊す：数値目標だけで安心してはいけない理由
結論：可用性や精度の数値は補助線にすぎません。まず会議で「主要影響ケース上位3」と「どの手段で検出するか」を決め、それに沿って数値や閾値を決めること。検出手段が決まらないSLAは意味を持ちません。
短い論拠
「精度90%」は母集団内での割合を示すにすぎず、検出手段がユーザー通報のみなら残り10%は野放しになります。現場は数式では動かず、「誰が」「いつ」「どの証跡で」問題を確認できるかで動くため、検出方法と証跡を先に定義する必要があります。
検出ルールの実装例
- チャットボット：料金表示フィールドは正規表現で検査（例：金額フィールドの簡易正規表現 → ^\d{1,3}(,\d{3})*(\.\d{2})?$）。フィールド不一致や未マッチで自動フラグを立て、短時間にクレームが増加したら即通知する。
- 画面↔PDF突合：請求金額・契約番号の文字列ハッシュを夜次バッチで突合。突合失敗率が0.5%を超えたら朝一で業務に報告し、3件以上連続発生で自動チケットを作成する。
- レンダリング異常：PDF生成のログに「status=failed」またはレンダリング時間>2sのエントリが連続したら一次対応者へSlack通知＋自動チケットを作成する。
短い失敗ケース：チャットボット誤案内
- 発生：料金説明フォーマット変更で誤金額表示
- 検出失敗：ユーザー通報のみで気づき、24時間でクレーム12件発生
- 改善ポイント：顧客接点は「正規表現検査＋自動閾値アラート」を必須化すべきだった
現場での線引き：検出が「ユーザー通報しかない」かつ「発生頻度が高い」ユースケースは拡大導入から除外するか、自動検知が実装されるまで本番投入を延期する。
判断軸の整理：影響・検出・責任・頻度で優先度を決める
結論：各ユースケースを「影響」「検出可能性」「責任」「頻度」の4軸で定量化し、スコア順にSLAの深掘り項目（復旧時間・代替手順・検出ルール・責任者）を決めよ。手順があれば費用対効果を踏まえた優先度付けが再現可能になります。
具体手順（実務フォーマット）
- 各軸を1–5で評価（低1〜高5）。例：影響＝顧客迷惑度(1–5)、業務停止度(1–5)、法的リスク(1–5)を合算して影響スコア化。
- 検出可能性はカテゴリ化：自動検知(5)／定期突合(3)／ユーザー通報のみ(1)。
- 頻度は「想定月間発生回数」＋「1回当たりの影響スケール」で定義（例：月10回・顧客単位で重大→頻度高×影響大）。
- 責任は人物名で書く（一次対応者、修正権限者、承認者）。これを満たさないユースケースはスコアを下げる。
- 最終的に重み付け合成スコアを算出（推奨ウェイト例：影響0.4／検出0.3／頻度0.2／責任0.1）。組織で調整可。
適用例
- チャット（顧客接点）：影響5／検出2（通報依存）／頻度4 → 高優先で自動検知・即時対応ルールを付与
- 内部帳票：影響2／検出4（定期突合で把握）／頻度2 → 夜間バッチで検知し、翌営業日に恒久対応で良し
現場での線引き：検出可能性が低く頻度が高いユースケースは拡大導入対象から外すか、導入条件として自動検出を必須にする。
PoCと承認ワークフロー：必ず検証・合否判定する具体項目
結論：PoCはAPIレスポンス確認で終わらせず、「入力→画面→PDF/帳票→問い合わせ対応」まで一連で検査基準化して合否判定する。定量的な閾値は統計的根拠を付けて決めよ。
サンプル数と統計的根拠（実務ガイド）
- プロポーション（一致率）を評価する際の概算式：n ≈ p(1−p) * (Z/Δ)^2。Zは信頼水準（95%→1.96）、Δは許容誤差（絶対値）。
- 実例：一致率目標99.5%（許容誤差±0.5%、95%信頼）なら n ≈ 0.995×0.005×(1.96/0.005)^2 ≈ 約760サンプル。→PoCで「200件合格」は統計的に不十分。
- 目安：99.5%±0.5%を求めるなら700–800、99%±1%なら約380、95%±2%なら約456のサンプル数が必要。入力パターン（長文・特殊文字等）で層化サンプリングすること。
PoCチェックリスト（必須）
- 代表入力ケースと異常入力（長文・特殊文字・欠損）を層化してサンプルを抽出
- 画面／PDF突合：APIレスポンスの主要フィールド（status, amount, contract_id）とPDFの同フィールドの一致率を算出。合格基準は事前に統計的目標（例：一致率≥99.5%±許容誤差）を定義
- 問い合わせ模擬：サービスデスクが想定問合せを実測で処理（例：50件以上）し、一次対応時間の中央値とエスカレーション率を測定
- 致命的不一致ルール：請求金額など致命的項目がPoCで1件でも発生したら不合格とする（事前合意）
- 承認ワークフロー：PoC責任者→業務責任者→情シスの三者承認。例外は書面で残す
短い失敗ケース：PDF欠落（PoC判定ミス）
- 状況：PoCで200件のサンプルだけを検査し、APIレスポンスは正常のため合格と判断 → 本番で2000件中14件でPDFレイアウト崩れ
- 学び：APIだけで判断せず、PDFの目視突合を合否条件に入れ、サンプル数は統計根拠で決める
現場での線引き：PoC合格条件に「画面/PDF突合」「層化サンプルでの再現性確認」「一次対応時間の実測閾値」を必須とし、これらを満たさないユースケースは本番移行を凍結する。
問い合わせ対応と現場合意の実務ハンドブック
結論：問い合わせ受領から恒久対応まで、必須項目をテンプレ化すれば現場合意は短時間でまとまる。受領→一次対応→暫定対応→恒久対応を明確なSLAで回せば再発を減らせます。
必須の受け付けフォーマット（JSONスキーマ例）
{
"ticket_id": "自動発番 (string)",
"reported_at": "ISO8601 timestamp",
"reporter_user_id": "string",
"service": "例: chatbot/payment (string)",
"severity": "low|medium|high|critical",
"screenshots": [
{"filename":"s1.png","resolution":"widthxheight","note":"省略可"}
],
"reproduction_steps": "入力値・操作順（テキスト）",
"input_payload": {"request_id":"string","body":"..."},
"related_logs": {"api_request_id":"string","response_code":int,"pdf_id":"string","log_snippet":"..."},
"impact": {"customer_affected":true,"business_stop":false,"estimated_count":12},
"attachments": ["pdf","csv","その他"],
"handled_by": "一次対応者(名前)"
}
必須／任意の運用ルール（短く）
- 必須項目：reproduction_steps、related_logs.api_request_id、screenshots（1点以上・解像度>=1024×768推奨）
- 任意項目：追加ログ、Full trace（大きい場合は別ストレージに保存してリンクを添付）
- 運用ルール：必須項目が無いチケットは「未調査」として扱い、一次対応SLAの対象外とする
初動SLA（テンプレ）
- 受領：自動発番でチケット化し、受領通知を即送信
- 一次対応：受領後4時間以内に連絡。severity=high/criticalは1時間以内に暫定指示
- 暫定対応：巻き戻し・手動回避・注意喚起等で24–72時間以内に実施基準を示す
- 恒久対応：原因特定→修正案提示→業務承認→リリース。修正権限者と承認ラインをチケットに明記
- エスカレーション：一次対応者→情シス運用リーダー→業務責任者→経営（高影響）
短い失敗例：受け付け不備で調査停止
- 状況：チケットに再現手順やログが添付されず調査が止まる
- 結果：暫定対応のみで根本原因不明のまま再発
- 学び：必須フォーマットを守らないチケットは調査開始しない運用を徹底する
現場での線引き：受け付けフォーマットが満たされない問い合わせは「未調査」として扱い、一次対応SLAの対象外にして調査効率を担保する。
SLAテンプレートと初動チェックリスト：会議で決める3項目＋PoC判定の3観点
結論：会議で即決すべき「3項目」とPoCでの合否判定「3観点」をテンプレ化すれば、初動が止まらない。議事録冒頭に書いて持ち帰ること。
会議で即決する3項目（必須）
- 主要影響ケース（上位3）例：顧客請求誤表示／重要契約PDF欠落／チャット誤案内
- 検出方法（誰が、どのログ・突合で検出するか）例：HTML↔PDFフィールド突合（夜次）、APIエラー監視、正規表現によるフィールド検査
- 一次対応者（名前と暫定決定権）例：山田（サービスデスク、暫定措置実行権）
PoC合否の3観点（必須）
- 画面／PDF突合：層化サンプルで主要フィールドの一致率が事前定義の統計目標を満たすか（サンプル数は目標精度に応じて算出）
- 再現性：問題が再現可能で再現手順が明文化されているか（再現率の目標も定義）
- 一次対応時間：想定問合せに対して一次対応が目標時間内に実行可能か（実測で確認）
SLA議論チェックリスト（会議用）
- 検出方法（ログ項目名・突合周期・アラート閾値）を明記
- 閾値（定量）例：突合失敗率0.5%／APIエラー率0.1%などは検出手段とサンプル数根拠とセットで提示
- 復旧時間（RTO）例：高影響1時間／中影響24時間／低影響72時間
- 代替手順：手動フロー・巻き戻し手順の文書化
- 責任者：一次対応者・修正権限者・承認ライン（人物名）
- ログ保持期間とアクセス方法（証跡確保）
- 通知先：自動通知のチャネルと担当者
現場での線引き：会議で即決する3項目が揃わないユースケースは拡大導入対象から外す。これが最速でリスクを制御する現場ルールです。
まとめ
導入判断（短く明確に）：AI横断導入のSLAは数値だけでは不十分です。影響・検出可能性・責任・頻度の4軸でユースケース別に定義し、PoC合否は画面／PDF突合・再現性・一次対応時間を統計根拠を添えて判定し、三者承認（PoC責任者→業務責任者→情シス）で進めてください。
小さく始める順番（初動チェックリスト）：
- 横断キックオフで即決：主要影響ケース（上位3）、検出方法（誰がどのログで検出するか）、一次対応者（名前と権限）を議事録冒頭に書く。
- PoC設計：代表入力・異常入力を層化サンプリング、画面目視・PDF突合を必須にし、合否基準（誤り検出率・再現性・一次対応時間）を統計的に定義する（サンプル数は目標精度に応じて算出）。
- 運用設計：受け付けテンプレート（JSONスキーマ）、一次応答SLA（例：4時間応答・高影響1時間）、エスカレーションライン、ログ保持期間を決める。
見送る条件（この条件が満たせないなら拡大導入を見送る）
- 検出方法が確立できず、ユーザー通報に依存していて発生頻度が高い場合
- PoCで画面／PDFの突合が統計的に担保できていない、または不具合の再現性が確立されていない場合
- 一次対応者や修正権限が未定で、エスカレーションルールが整備されていない場合
最後に一歩：今日の会議で必ず持ち帰る3つは「主要影響ケース上位3」「検出方法（誰がどのログで検出するか）」「一次対応者（名前と権限）」。これらが決まれば、SLAの数値は現場要件に合わせて初めて意味を持ちます。議事録の冒頭にこの3点を書いて帰る——それが本番で記憶に残るSLA設計の最短距離です。
関連リンク：
コメント