セキュアで、
グローバルに展開する
エンタープライズAI

規模が変えるもの

少人数のチームが作業を自動化するのは、ツールの選定です。組織が同じ作業を自動化するのは、他の業務が依存している業務プロセスの変更です。

投資対効果を魅力的に見せるその処理量は、同時に、気づかれないまま続く体系的な誤りの影響も大きくします。週に二百件を扱う担当者は変化に気づきます。二万件を処理する仕組みは気づきません。監視する仕組みを作っていない限りは。

これは慎重に進めるべきだという話ではありません。影響範囲を一文で説明できる業務を最初に選ぶべきだ、という話です。

最初に着手される領域

大規模な環境で最初の候補になるものは共通しています。処理量が多く、書類が中心で、システムをまたがり、すでに能力に見合わない作業に人が充てられている業務です。

1. 01

   書類中心のバックオフィス

   請求書、申請、契約書、入社手続きの書類。書類として届き、最終的にシステム上の記録になる業務です。

   AIが読み取り、抽出し、分類し、既存の記録と照合したうえで、もともと動くはずだったワークフローに結果を渡します。

   例

   • 請求と入金の突合
   • 申請内容の確認
   • 契約条項の抽出
   • 勘定の照合
   • 例外処理

   エンタープライズの取り組みがここから始まることが多いのは、処理量が把握されており、新しい集計の仕組みなしに前後比較ができるからです。

2. 02

   社内外のサービスデスク

   情報システム部門の窓口も顧客対応も、表現を変えて繰り返される問い合わせを多く抱えています。

   AIは問い合わせを分類し、組織がすでに公開している資料から回答を下書きし、当てはまらないものを担当者に引き継げます。

   例

   • 問い合わせの分類と振り分け
   • 回答の下書き
   • ナレッジからの回答
   • 次の担当者への引き継ぎ要約
3. 03

   部門をまたぐ問い

   課題は定型のレポートではありません。三つのチームが互いにデータを書き出さなければ誰も答えられない、という問いのほうです。

   統制されたデータの上にAIを置けば、それを答えに変えられます。ただし、統制が先に行われていることが条件です。

   • 懸念している条項を含む契約はどれか
   • 同じ顧客が二つのシステムで異なる扱いを受けているのはどこか
   • 規程の改定後、この業務の何が変わったか
   • どの拠点が、どの指標で外れ値なのか
4. 04

   監視、リスク、コンプライアンス

   統制の仕組みは、どのチームも読みきれない量の情報を生み出します。必要なのは、重要なものと単に発生しただけのものを分けることです。

   AIが優先順位をつけ、まとめ、理由を示すことで、担当者は選別ではなく判断に時間を使えます。

   例

   • アラートの選別
   • 規程改定の影響範囲
   • 異常の確認
   • 監査証跡の収集
5. 05

   システム環境そのもの

   レガシーの刷新、テストの整備、ドキュメント、移行。いずれも熟練した集中力を要する一方で機能を生まないため、常に後回しにされます。

   同時に、機械が一次対応し、人が確認するという進め方が特に適した領域でもあります。

   例

   • レガシーコードの解読
   • テストの自動生成
   • 移行作業の支援
   • コードからのドキュメント生成

どこまで任せるか

同じ仕組みでも、任せ方によってリスクは三段階に分かれます。規制や監査のある環境では、その段階を自社だけで決められるとは限りません。

• 定めた範囲内でAIが実行し、すべての判断を記録として残す。
• AIが判断を用意し、指名された担当者が承認する。
• AIが根拠を揃え、判断と実行は人が担う。

目指したい段階ではなく、いまの監査で受け入れられる段階から始めてください。次の段階に進むには証跡をめぐる議論が必要で、証跡は数か月かけて積み上がるものです。

既存の統制がすでに担保していること

大規模組織はAIをまったく新しいガバナンスの課題として扱いがちですが、その多くはそうではありません。問いにはすでに所有者がいます。

• データの区分と保持期間 — 情報ガバナンスがすでに定めています
• アクセス権限と職務分離 — システムごとにすでに定められています
• 変更管理とリリース承認 — すでに定められています
• 委託先の評価とデータ取扱条件 — すでに定められています
• 監査証跡 — すでに定められています

本当に新しいのは、もっと限られた点です。自信を持って誤ることがあり、入力の傾向が変われば挙動も変わり、ルールのようには判断の根拠が読み取れない、という点です。

このように整理すると承認の議論は大幅に短くなります。問いの多くは、組織がすでに答えを出してきたものだと分かるからです。

AIにできないこと

• 二つの部門で見解が割れている業務は解決しません。その不一致をそのまま固定します
• データを整えてはくれません。どれだけ不揃いかを明らかにします
• それ自体が人員を減らすわけではありません。仕事の中身を変えるものです
• ルールのようには説明できません。説明責任が重い判断はルールのまま残すべきです
• プロジェクト体制が解散したあと、担当者がいなければ維持されません

対象範囲を一枚に書き出す

業務責任者、データ所有者、リスク部門のレビュアーが、会議を開かずに承認できる一枚です。一枚に収まらないのであれば、範囲がまだ広すぎます。

• 対象とする工程と、その開始点と終了点
• 読み取り先と書き込み先のシステム
• 行う判断と、行ってはならない判断
• 確信が持てないときに何が起きるか
• パイロット期間中、出力を承認するのは誰か

変更する前に、いまの業務を測る

実際の基準値を取ってください。処理量、所要時間、誤り率、手戻り、費用。関係者の認識ではなく、システムから取得します。

基準値が想定より悪いと判明することは珍しくありません。それは不名誉ではなく、多くの場合、投資判断の根拠を強め、目標を明確にします。

何にも触れさせずに並走させる

最初の導入では何も変更しません。業務はこれまでどおり進み、仕組みは同じ入力でその横を走り、出力が記録されて比較されます。

• 本番の入力を、本番の処理量で
• 月末処理や扱いにくい事例を含む十分な期間
• すべての出力を、それを生んだ入力とともに保存する
• 人の結果との相違は、件数を数えるだけでなく内容を確認する

並走はリスク委員会に示せるもっとも安価な証跡であり、誰にも悪い結果を負わせない唯一の種類の証跡です。

相違をその業務の担当者と一緒に確認する

現場のチームと並んで、仕組みと人の判断が分かれた事例を確認してください。示唆があるのは、明らかな誤りのほうではありません。

• 自信を持って誤っていたのはどこか。それに気づけた人はいたか
• 私たちより的確に処理できている事例はどれか
• 全件確認をやめるには、何が見えている必要があるか
• 精度がどうであれ、自動化すべきでない事例はどれか

後半二つの答えが、そのままリリース基準と恒久的な除外対象になります。いずれもプロジェクト側が決めるより、現場から出たほうが説得力があります。

範囲ではなく、確認の密度から緩める

調整できるつまみは二つです。処理量のどこまでを任せるかと、一件ごとの確認をどこまで行うか。動かすのは一度に一つだけにしてください。

• まずは、すべての出力を人が承認する形から始める
• 確信度の基準を定め、例外のみ承認する形に移す
• 同じ部門内の残りの処理量へ広げる
• 二つ目の部門を検討するのは、そのあと
• 停止手段は情報システム部門だけでなく、業務責任者にも届く場所に置く

二つ目の部門は、新しい連携であり、新しいデータ所有者であり、しばしば新しい規制です。部品を再利用する新規導入として扱ってください。

運用をきちんと引き継ぐ

導入は稼働開始で終わりではありません。プロジェクト体制の外にいる誰かが責任を引き受け、そのために必要なものを持った時点で終わります。

• 技術部門だけでなく、業務側に指名された責任者
• 既存の報告サイクルに乗せた品質指標
• 修正率が動いたときのアラート
• 停止して元に戻す手順の文書
• 中止を決める権限を伴った、見直し日の設定

誰も所有していない仕組みは、正しくなくなったあとも長く動き続けます。失敗したパイロットよりも、そちらのほうが高くつきます。