新章 十二話 後編 機械の速度で守り、人間の責任で設計する（RIS)
後編 機械の速度で守り、人間の責任で設計する
守る側のAI「RIS」は、社会を変えられるのか
### 第一章 その名前を、誰も説明していなかった
「ところで、榊原さん」
会議室の大型モニターに映し出された資料を眺めながら、白石恵が手を挙げた。
「さっきから皆さん、RIS、RISとおっしゃっていますけれど……。
すみません。私、そのRISというものが、まだよく分かっていないんです」
会議室が静かになった。
白石は、情報セキュリティの専門家ではない。
顧客からの問い合わせを受け、システム障害が発生すれば、利用者への説明や復旧後の対応を担当する。
技術者の言葉を、実際にサービスを利用する人々の言葉へ翻訳する。
それが彼女の仕事だった。
だからこそ、彼女の疑問は重要だった。
「AIなんですか。それとも、新しいセキュリティソフトなんですか。
あるいは、今あるセキュリティシステムを全部置き換えるものなんですか？」
榊原玲は、手元の資料を閉じた。
「いい質問です。そこを説明しないまま話を進めてはいけませんね」
彼女はモニターを切り替えた。
そこには、簡単な図が表示された。
左側に「ネットワーク・端末・認証システム」。
中央に「RIS」。
右側に「検知・判断・対応・記録」。
「まず、RISは、私たちが構想している防御AIの仕組みです。
完成して実績が証明された製品という意味ではありません。
これから設計し、実験し、本当に役に立つかどうかを検証しようとしているものです」
「防御AI……」
黒田修一が、言葉を確かめるようにつぶやいた。
「はい。
攻撃する側が自動化された道具を使い、短い時間で大量のアクセスを試みる。
人間が一件ずつ画面を確認してから対応するだけでは、間に合わない場面がある。
そういう問題に対して、機械の処理能力を利用して防御する構想です」
「つまり、AIが攻撃を見つけて、勝手に敵を撃退する？」
黒田の言い方に、榊原は少し笑った。
「その説明だと、格好はいいのですが、危険ですね」
「危険？」
「AIが見つけたものを、全部攻撃だと決めつけたらどうなるでしょう。
普通のお客様がログインを繰り返しただけで、攻撃者と誤認されるかもしれません。
取引先のシステムを危険と判断して通信を遮断すれば、業務が止まります。
病院や物流のシステムだったら、影響はもっと深刻になる可能性があります」
白石がうなずいた。
「守るための仕組みが、利用者に被害を与えてしまうこともあるんですね」
「そうです。
だから、RISは単純な自動迎撃装置ではありません」
榊原はモニターに三つの言葉を表示した。
・見つける。
・判断する。
・被害を広げない。
「第一に、
システムのログや通信の状態、認証の記録など、利用を許可された情報から異常の兆候を見つける。
第二に、
複数の兆候を照らし合わせ、危険度を評価する。第三に、危険の大きさに応じて、あらかじめ定められた範囲で対応する。そして、その判断と対応を記録して、後から検証できるようにする」
佐伯直人が補足した。
「たとえば、いつもと違う場所からログインが試みられた。
それだけなら、旅行中のお客様かもしれません。
でも、短時間に何百回も認証が失敗し、その直後に別のアカウントへのアクセスが始まったら、話が変わってきます」
「一つの出来事だけで判断せず、出来事同士の関係を見るわけですね」
「そうです。
単独では小さな異常でも、組み合わせると危険の兆候になることがあります」
三浦健が腕を組んだ。
「ただし、AIの判断が常に正しいとは限りません。だから、危険度が低ければ監視を続ける。疑わしい場合は追加認証を求める。被害が広がるおそれがある場合は、限定的な通信制限などを実行する。重大な操作には人間の承認を求める。そんな段階的な対応が必要です」
「AIに、何でも自由に決めさせるわけではないんですね」
「むしろ逆です。何を任せ、何を任せないかを、先に人間が決めるんです」
白石は図を見つめた。
「それなら、私にも分かります。RISは人間の代わりに責任を取るものではなく、人間だけでは追いつかない仕事を補うための仕組みなんですね」
「その理解が、出発点です」
榊原はうなずいた。
黒田が、資料の端を指でたたいた。
「よし。では、ここから本題だ。私たちが知りたいのは、RISという名前が格好いいかどうかではない。本当に守れるのかどうかだ」
その言葉を聞いて、佐伯はノートパソコンを開いた。
「それなら、最初に確認しなければならない数字があります」
「どんな数字だ？」
「攻撃の件数ではありません。攻撃を検知してから、被害を抑える処置が完了するまでの時間です」
会議室の議論が、ようやく本当の出発点に立った。
### 第二章 毎秒百三十回という現実
「仮に、毎秒百三十回以上の攻撃の試みが発生している環境を考えてみましょう」
佐伯が説明を始めた。
「この数字は、今回の検討で想定している条件です。あらゆるネットワークに当てはまる普遍的な数字という意味ではありません。それに、攻撃の試みが百三十回あることと、百三十回の侵入が成功することは、まったく違います」
「それでも、人間が一件ずつ確認するのは難しいな」
黒田が言った。
「ええ。毎秒百三十回なら、十秒で千三百回です。人間が一件ずつ内容を読んで判断する方式では、確認する前に次々と事象が積み上がってしまいます」
高瀬美紀が口を挟んだ。
「ただし、現場で本当に困るのは、件数が多いことだけではありません。警告が大量に出ると、その中に本当に危険なものが混じっていても、見落としやすくなるんです」
「警告疲れ、というやつか」
「そうです。毎日、何千件もの警告が届く。大半は無害な動きか、緊急性の低い事象。それでも全部を確認しなければならない。担当者は疲れます。疲れれば、判断の質も落ちる。そこへ、本当に危険な攻撃が紛れ込む」
白石は眉をひそめた。
「守る人が、警告の多さに疲れてしまうんですね」
「人間が弱いからではありません。仕組みが人間の能力を超える量の仕事を押しつけているからです」
高瀬は、そう言い切った。
「だからRISには、単純に警告を増やすのではなく、膨大な情報を整理し、関連する事象をまとめ、危険度に応じて優先順位を付けることを期待しています」
「では、AIが瞬時に判断すればいい？」
黒田の問いに、佐伯は首を横に振った。
「瞬時に判断することだけでは不十分です。判断が速くても、対応が遅ければ意味がありません。検知に〇・一秒、分析に〇・二秒、対応の指示に〇・一秒かかったとしても、その先の通信制御や認証システムが混雑していれば、実際に防御が完了するまで時間がかかります」
「つまり、AIの計算速度だけを測っても意味がない」
「そのとおりです。必要なのは、検知から対応完了までの全体の時間です」
佐伯はホワイトボードに書いた。
**検知 → 分析 → 判断 → 対応指示 → 実際の防御 → 結果の確認**
「この一連の流れを測らなければいけません。さらに、平均時間だけでは足りない。普段は速くても、アクセスが集中したときに極端に遅くなるかもしれないからです」
三浦が付け加えた。
「見逃し率も必要です。誤検知率も必要です。正常な通信をどれだけ誤って止めたか、危険な動きをどれだけ見逃したか。速さと正確さの両方を測る必要があります」
黒田はホワイトボードを見つめた。
「経営会議では、よく『処理速度が十倍になりました』という説明を聞く。しかし、それが実際の防御にどれほど効くのかは、別途確かめなければならないということか」
「そうです。計算が十倍速くなっても、システム全体の処理が十倍速くなるとは限りません。ボトルネックが別の場所にあれば、そこが足を引っ張ります」
榊原は静かに言った。
「RISを作るなら、まず目標を決めるべきです。どの程度の負荷を想定するのか。どれほどの時間で検知し、どこまで自動対応するのか。正常な利用者への影響を、どの範囲に抑えるのか。測定できない目標は、達成したかどうかも判断できません」
黒田はうなずいた。
「分かった。AIを導入したという報告ではなく、何が改善したかを測る。そのための試験計画を作ろう」
### 第三章 Pythonでは追いつけないのか
「次の問題があります」
佐伯は画面を切り替えた。
「RISを実装する場合、どの技術を使うかです」
モニターには、二つの名前が並んだ。
**Python**
**Mojo**
黒田は首をかしげた。
「Pythonは聞いたことがある。AIの開発でよく使われる言語だな。もう一つのMojoは？」
「比較的新しいプログラミング言語です。AIや高性能計算を意識した用途で注目されています。ただし、今回の問題は、どちらの名前が新しいかではありません。どの処理が、どれだけ速く、安定して動くかです」
「Pythonでは、攻撃の速度に追いつけないのではないか」
黒田は率直に尋ねた。
佐伯は、少し考えてから答えた。
「処理の内容によります。Pythonそのものが、あらゆる場面で遅すぎるというわけではありません。Pythonから呼び出す数値計算やAIのライブラリは、内部で高速なネイティブコードを使っていることも多い。通信やディスクへの読み書きが待ち時間の中心なら、プログラミング言語を変えても大きく改善しないかもしれません」
「では、Mojoを使う意味はないのか？」
「いいえ。
計算量の大きい処理や、実測でボトルネックだと分かった部分については、Mojoのような選択肢を検討する価値があります。
ただし、使えば必ず速くなると決めつけることもできません」
榊原が続けた。
「大切なのは、最初からすべてを書き換えようとしないことです。まずPythonなどで、システム全体の仕組みを作る。どの処理に時間がかかっているかを測る。そのうえで、必要な部分だけ別の実装にする。これなら、開発や保守の負担も抑えられます」
三浦が腕を組んだ。
「セキュリティシステムの場合、速ければいいというものでもありません。複雑になりすぎて、誰も仕組みを理解できなくなったら、脆弱性を見つけることも、事故が起きたときに修正することも難しくなります」
「つまり、速さと、保守できることの両方が必要なのか」
「はい。さらに、テストできること、更新できること、担当者が交代しても運用できることも必要です」
高瀬がうなずいた。
「現場では、開発した本人しか直せないシステムが一番怖い。本人が休んだら、誰も触れない。障害が起きても、どこに問題があるのか分からない。それでは守るためのシステムが、新しい弱点になってしまいます」
黒田は、二つの言語名を見比べた。
「経営側は、最新技術を採用したと言いたがる。しかし、最新技術を採用することと、会社が強くなることは同じではないわけだな」
「そうです」
佐伯は答えた。
「Pythonで十分な部分はPythonを使う。
性能が必要な部分は、実測に基づいて最適な方法を選ぶ。Mojoを採用するなら、同じ条件で比較試験をする。処理速度だけでなく、メモリー使用量、安定性、開発のしやすさ、保守の難しさまで確認するべきです」
榊原は最後に、こう付け加えた。
「そして、どの言語を使っても、設計が間違っていれば安全にはなりません。高速なプログラムが、誤った相手を高速に遮断することだってあるのですから」
白石が思わず笑った。
「それは、笑えないですね」
「ええ。だから、笑い話で済むうちに、試験しておくのです」
### 第四章 AIが間違えたとき、誰が止めるのか
「ここまでは、AIが正しく判断することを前提にした話でした」
三浦が、会議室を見回した。
「しかし、実際には、AIが間違える可能性を前提に設計しなければなりません」
「誤検知と見逃し、か」
「はい。誤検知は、危険ではないものを危険だと判断すること。見逃しは、本当に危険なものを危険ではないと判断することです。どちらもゼロにできると約束するべきではありません」
白石は尋ねた。
「では、誤検知を恐れて慎重になりすぎると、今度は本当の攻撃を見逃すのではありませんか？」
「そのとおりです。逆に、見逃しを恐れて何でも遮断すれば、正常な業務まで止まります。だから、単純に一つの数字を最小にすればいいという話ではないんです」
高瀬が、現場の例を挙げた。
「深夜に、普段とは違う端末からログインがあったとします。それだけでアカウントを永久停止するのは行き過ぎです。一方、短時間に大量の認証失敗が発生し、さらに権限の高いアカウントへアクセスしようとしているなら、放置できません」
「危険度に応じて、対応を変える？」
「そうです。記録する。追加認証を求める。アクセスを一時的に制限する。必要に応じて遮断する。重大な操作には人間の承認を求める。状況に応じて、段階を分けるんです」
榊原は、もう一つの条件を挙げた。
「ただし、段階的な対応を設計するだけでは足りません。AIが誤作動したとき、誰が止めるのか。誤ったルールが配布されたとき、どう元に戻すのか。システムを安全な状態に戻す手段が必要です」
「緊急停止ボタンのようなものか」
黒田が言った。
「それも一つです。ただし、停止すればすべて解決するとは限りません。AIを止めた瞬間に防御がなくなってしまうなら、それも危険です。AIが使えないときでも、基本的なアクセス制御や認証などの防御が動き続ける設計にする必要があります」
佐伯がうなずいた。
「RISが停止しても、すべての扉が開いてしまうような設計にはしない。AIは防御を強化する仕組みであって、既存の防御を丸ごと置き換える前提にはしないほうがいい」
「それから、ログです」
三浦が言った。
「AIが何を検知し、どんな情報を根拠に判断し、どの操作を実行したのか。後から確認できるようにする。問題が起きたとき、AIがそう判断したから、で終わらせてはいけません」
白石は、少し不安そうな顔をした。
「でも、AIの判断が複雑すぎて、人間にも理由が分からない場合は？」
「だからこそ、説明できる範囲を増やす設計が必要です。少なくとも、どの情報を使い、どのルールに基づき、どの権限で操作したのかは追跡できるようにする。すべての内部計算を簡単な言葉に直せるとは限りませんが、運用上の責任を追える記録は残せます」
黒田は、椅子にもたれた。
「AIを賢くするだけでは不十分だ。間違えたときの被害を小さくし、間違いを発見し、元に戻せるようにしておく必要がある」
「はい」
榊原は答えた。
「私たちが設計すべきなのは、間違えないと主張するAIではありません。間違いが起きても、被害を限定し、原因を調べ、修正できる仕組みです」
### 第五章 攻撃する側も、進化する
「もう一つ、忘れてはならないことがあります」
三浦が、別の資料を表示した。
「攻撃する側も、自動化されたツールを使います。AIを使って情報を整理したり、攻撃の候補を探したり、作業を効率化したりする可能性があります」
黒田が眉を寄せた。
「つまり、防御側がAIを使い始めたら、攻撃側も同じようにAIを使うということか」
「必ずしも同じ技術を使うとは限りませんが、そうした競争が起きる可能性はあります。こちらが自動化すれば、相手も自動化する。だから、AIを導入しただけで勝てると考えるのは危険です」
佐伯は画面を見つめた。
「攻撃側の動きをすべて予測するのは難しい。未知の脆弱性もあれば、設定ミスもある。人間が意図せず危険な操作をしてしまうこともあります」
「なら、何を目指せばいい？」
黒田が尋ねた。
榊原は、少し間を置いた。
「攻撃を完全に予測することだけを目標にしないことです。侵入を試みられても、重要な情報に簡単には届かない。ある端末が侵害されても、会社全体に被害が広がらない。異常が起きたときに、早く気づき、被害を限定し、復旧できる。そういう構造を作ることです」
高瀬が続けた。
「一つの鍵が盗まれたら、建物のすべての部屋を開けられる。そんな建物にしないことです。部屋ごとに鍵を分ける。必要な人に、必要な範囲だけを許可する。重要な設備は別の区画に置く。ネットワークも同じ考え方で設計できます」
「最小権限の原則、ですね」
佐伯が言った。
「そうです。人間にもAIにも、仕事に必要な権限だけを与える。RISに管理者権限をすべて渡してしまえば、誤判断したときの影響も大きくなります」
三浦は、ホワイトボードに書き加えた。
**侵入を防ぐ。侵入に気づく。被害を限定する。復旧する。**
「この四つを組み合わせる。防御AIは、そのうちの一部を強化するものです。すべてを一つのAIに任せる必要はありません」
白石が言った。
「攻撃を一度も受けない会社を目指すだけではなく、攻撃されても、簡単には倒れない会社を目指すんですね」
「そうです」
榊原はうなずいた。
「防御の強さは、攻撃を一つも通さなかったという記録だけでは測れません。攻撃を受けたときに、何を守り、どれほど早く異常を見つけ、被害をどこまで抑え、どれほど確実に復旧できたか。それも、重要な評価指標です」
### 第六章 AIを守る仕組みも必要だ
「ここで、もう一つの問題が出てきます」
佐伯が言った。
「RISそのものが攻撃されたら、どうするのか」
会議室の空気が、少し変わった。
「防御AIが、攻撃者に操作されたら？」
白石の質問に、三浦が答えた。
「それは、最も避けなければならない事態の一つです。防御システムそのものが侵害されれば、攻撃を見逃したり、正常な通信を遮断したり、誤った設定を配布したりする可能性があります」
「つまり、守るための仕組み自体も守らなければならない」
「そうです。RISだけを特別扱いして、無条件に信頼してはいけません」
榊原は、具体的な対策を説明した。
「まず、RISが使うアカウントの権限を限定します。判断するための権限と、実際にネットワークを変更する権限を分ける。重要な設定変更には承認を必要とする。記録は改ざんされにくい形で保管し、別の担当者も確認できるようにする。異常が起きたら、操作を停止したり、以前の安全な設定に戻したりできるようにします」
「AIが、自分の判断で自分の権限を拡大することは？」
「許してはいけません。必要な権限は、人間が明確な手続きで設定する。AIが自分で自由に権限を増やせる設計にする理由はありません」
黒田は、少し笑った。
「便利さを追い求めると、つい何でも任せたくなる。しかし、任せすぎれば、事故が起きたときに止めることさえ難しくなる」
「そのとおりです」
三浦が答えた。
「特に、防御AIには強い権限を与えたくなります。攻撃を止めるには、通信を遮断したり、アカウントを停止したりする能力が必要になるからです。でも、権限が強いほど、誤作動や侵害が起きたときの被害も大きくなります」
高瀬は、現場の立場から付け加えた。
「自動化する前に、手動で安全に戻す手順も決めておくべきです。緊急時に、誰が何を操作すればよいのか。担当者が交代しても分かるようにしておく。手順書が古くなっていないか、実際に訓練する。それも防御の一部です」
白石はうなずいた。
「AIを導入すること自体が、新しい危険を生む場合もあるんですね」
「はい。だから、AIを導入したから安全になった、とは言えません。AIを含むシステム全体を、どう安全に運用するかが問題なのです」
### 第七章 試験で確かめること
黒田は、ここまでの議論をノートにまとめていた。
「分かった。では、RISを試作するとしよう。どうすれば、役に立つと判断できる？」
佐伯が答えた。
「試験計画を先に作ります。都合のいい条件で動いたというだけでは、実際の環境で役立つかどうか分かりません」
「具体的には？」
「まず、想定する通常時の負荷で試験します。次に、アクセスが集中する負荷で試験する。さらに、通信の遅延や一部の機能停止など、異常な条件でも試します。RISが正常に働く場合だけでなく、働けなくなった場合も確認します」
榊原が補足した。
「そして、評価する項目を決めておきます。検知から対応完了までの時間。危険な動きを見逃す割合。正常な通信を誤って遮断する割合。システム全体の処理能力。メモリーなどの資源使用量。障害時の復旧時間。そして、担当者が運用や修正を続けられるかどうかです」
「全部、数字にするのか？」
「できるものは数字にします。ただし、数字だけで判断できないものもあります。たとえば、担当者が操作を理解できるか、事故時に必要な情報が残っているか。そうした項目も試験の対象にします」
三浦が言った。
「攻撃を模した試験も必要です。ただし、試験環境と本番環境は分ける。いきなり本番システムで強い遮断機能を動かしてはいけません。まず隔離された環境で検証し、次に限定した範囲で試し、問題がないことを確かめながら適用範囲を広げるべきです」
高瀬は、強くうなずいた。
「本番でいきなり試される側は、たまったものではありませんからね。試験中に正常な通信が止まったらどうするのか。復旧担当は誰か。元の設定に戻す方法は何か。そこまで決めてから始めるべきです」
白石が尋ねた。
「もし、試験で思ったような結果が出なかったら？」
黒田はすぐには答えなかった。
経営者としては、失敗という言葉を聞きたくない。投資した以上、成果が出てほしい。社内にも、株主にも、顧客にも、成果を示したい。
しかし、試験で失敗が見つかることと、本番で被害が発生することは違う。
「その場合は、原因を調べる」
黒田は言った。
「目標を達成できなかったのなら、どこが問題だったのかを明らかにする。設計を直す。必要なら、計画を変更する。達成していないのに、達成したことにして導入するわけにはいかない」
榊原は、その答えを聞いて初めて少し安心したような表情を見せた。
「ありがとうございます。RISを試す目的は、導入を正当化することではありません。本当に役に立つかどうかを確かめることです」
「そのために予算を使うのだからな」
黒田は言った。
「失敗を見つけられない試験に、意味はない」
### 第八章 会社は、AI導入を成果と呼ぶのか
会議は、技術の話から経営の話へ移っていった。
「ここまでの話を聞いていると、RISを作るには相当な費用がかかりそうだな」
黒田は率直に言った。
「技術者が必要だ。試験環境も必要だ。運用担当者の教育も必要だ。ログを保管する仕組みも必要になる。さらに、導入した後も、更新や監査を続けなければならない」
「はい。開発費だけでなく、運用費も考える必要があります」
榊原が答えた。
「では、経営会議では何を成果として報告すればいい？」
佐伯は答えた。
「RISを導入した、という事実だけでは足りません。導入前と導入後を比較する必要があります。検知にかかる時間はどれだけ変わったか。担当者が確認する警告の量はどう変わったか。危険な動きを見逃す割合はどうか。正常な利用者への影響は増えていないか。復旧にかかる時間は短くなったか」
「つまり、導入件数ではなく、実際に守る能力が改善したかどうかを見る」
「そうです」
三浦が言った。
「そして、都合のいい指標だけを選んではいけません。警告を減らすことだけを目標にすると、警告を出さないようにすることで数字を改善できてしまうかもしれません。処理速度だけを追えば、慎重な確認を省いてしまうかもしれません。指標は組み合わせて評価する必要があります」
白石が続けた。
「会社の都合で数字をよく見せることが、利用者を守ることより優先されたら、本末転倒ですね」
「そのとおりです」
黒田は深くうなずいた。
「私たちは、AIを導入したという宣伝のために投資するのではない。顧客の情報を守り、サービスを止めず、事故が起きたときに早く復旧するために投資するんだ」
高瀬が言った。
「それなら、現場の人員も忘れないでください。AIを入れれば人間の仕事がなくなる、と考えるのは危険です。むしろ、AIが出した警告を評価し、システムを管理し、異常時に判断する人が必要です」
「人を減らすためのAIではなく、人間が重要な判断に集中できるようにするAI、ということか」
「少なくとも、私たちが目指すべき方向はそうです」
榊原は答えた。
「ただし、それも導入すれば自動的に実現するわけではありません。現場の負担が本当に減ったか、担当者が必要な能力を持てているか、継続して確認する必要があります」
黒田は、会議の議事録に一文を書き加えた。
**RIS導入の成果は、AIを導入したという事実ではなく、防御能力が実際に改善したかどうかで評価する。**
「この一文は、経営会議にも出そう」
彼は言った。
### 第九章 事故が起きたとき、誰が説明するのか
「もう一つ、避けて通れない問題があります」
白石の声は、いつもより静かだった。
「仮にRISが正常な利用者を誤って遮断したとします。そのせいで、お客様が必要なサービスを使えなくなった。あるいは、RISが攻撃を見逃し、顧客情報が流出した。そういうとき、会社は何をするんですか？」
誰も、すぐには答えなかった。
「AIが判断したから仕方がない、では済みませんよね」
白石は続けた。
「お客様にとっては、AIが判断したか、人間が判断したかは、最初の問題ではありません。自分の情報が漏れた。仕事が止まった。生活に影響が出た。その事実があるだけです」
黒田は、視線を落とした。
「そのとおりだ」
「では、誰が責任者になるのか。誰が被害の範囲を調べるのか。誰が利用者に説明するのか。誰が復旧の見通しを伝えるのか。あらかじめ決めておかなければ、事故が起きてから担当部署を探すことになります」
高瀬が言った。
「現場では、事故の直後に判断しなければならないことがたくさんあります。被害が広がっているのか。どのシステムを止めるべきか。どのサービスを優先して復旧させるか。その判断を支える情報と権限が必要です」
三浦が補足した。
「事故後には、記録を調べて原因を明らかにする。どの段階で異常を検知したのか。AIは何を判断したのか。人間はその結果をどう扱ったのか。設計上の問題なのか、運用上の問題なのか、攻撃によるものなのか。原因を区別しなければ、再発を防げません」
佐伯は言った。
「だから、ログは単に保存するだけではなく、調査に使える形にしておく必要があります。時刻を正しく記録する。必要な情報を関連づける。アクセスできる人を限定する。改ざんや消失を防ぐ。そうした設計が必要です」
白石は、全員を見回した。
「そして、利用者への説明です。専門用語を並べるのではなく、何が起きたのか、どの情報に影響があったのか、今何をしているのか、利用者が何をすればよいのか。それを、分かる言葉で伝えてほしいんです」
黒田は、深く息を吐いた。
「私たちは、事故を防ぐ技術の話ばかりしていた。しかし、事故が起きた後の責任も、同じくらい重要なんだな」
「はい」
白石は答えた。
「防御AIを導入するなら、事故対応の体制も一緒に設計してください。AIだけが先に賢くなって、会社の説明責任が置き去りになるのは困ります」
その言葉は、会議室にいた誰の心にも残った。
### 第十章 守るために、何を見てよいのか
「RISがシステムを監視するなら、どこまでの情報を見ることになるのでしょうか」
白石が尋ねた。
「通信の記録、認証の履歴、端末の状態。必要なら、利用者の行動に関する情報も分析することになりますよね」
榊原はうなずいた。
「そうです。ただし、必要だからといって、何でも収集してよいわけではありません」
「セキュリティのためなら、社員の行動を全部記録してもよい、という考え方にはしたくありません」
白石の言葉に、高瀬が同意した。
「監視が強くなりすぎると、現場の人間は常に疑われているように感じます。仕事に必要な確認と、必要以上の監視は区別しなければいけません」
三浦が説明した。
「まず、何のために情報を使うのかを明確にする。その目的に必要な情報だけを扱う。アクセスできる人を限定する。保存期間を決める。別の目的に転用しないためのルールを作る。こうした管理が必要です」
佐伯が続けた。
「可能な場合は、個人を特定しない形で集計した情報を使うことも検討できます。ただし、匿名化すれば必ず安全というわけではありません。ほかの情報と組み合わせると、個人が推測される場合もあります」
「つまり、技術的にできることと、社会的に許されることは別なんですね」
白石が言った。
「そうです」
榊原は答えた。
「RISが優れた防御AIになるためには、攻撃を検知する能力だけでなく、利用者の権利を尊重する設計も必要です。守る対象には、システムだけでなく、そのシステムを使う人々も含まれています」
黒田は、資料を閉じた。
「安全の名目で、何でもできるようにしてしまえば、別の問題が生まれる。守るための権限にも、限界が必要ということだな」
「はい。強い技術ほど、使い方を決めるルールが必要になります」
### 第十一章 小さく始め、確かめながら広げる
会議が始まってから、かなりの時間が経っていた。
黒田は、最後の議題を確認した。
「では、RIS構想を進めるとして、最初に何をするべきだろう」
榊原が答えた。
「いきなり全社のシステムに導入するのではなく、範囲を限定した実証実験から始めるべきです」
「具体的には？」
「まず、守る対象を一つ選びます。どのような攻撃や異常を検知したいのかを決めます。AIが利用できる情報と権限を限定します。そして、試験環境で性能と安全性を確かめます」
佐伯が続けた。
「その段階では、AIが異常を検知しても、実際には通信を遮断せず、判断結果だけを記録する方法も考えられます。これなら、AIがどの程度正しく判断するかを、本番業務への影響を抑えながら評価できます」
三浦が言った。
「ただし、実際に遮断しない試験では、遮断した場合の影響までは分かりません。次の段階で、隔離された環境や限定した対象を使って、対応機能も試験する必要があります」
「段階を分けるわけだな」
黒田が言った。
「はい。検知の精度を確かめる。負荷が高い状態での動作を確かめる。異常時の安全性を確かめる。復旧できることを確かめる。それぞれの段階で、次へ進む条件を決めておきます」
高瀬が強調した。
「そして、現場の担当者を最初から参加させてください。開発チームだけで決めると、実際の運用に合わない仕組みができることがあります。夜間に誰が対応するのか。誤検知が続いたらどうするのか。担当者が休みの日は誰が判断するのか。現場で使える設計にしなければ意味がありません」
白石も言った。
「利用者への影響を確認する人も必要です。正常な利用者が誤って遮断されていないか。サービスが使いにくくなっていないか。事故が起きたときの説明ができるか。そこも評価項目にしてください」
黒田は、全員の意見を聞き終えてから答えた。
「分かった。まずは限定した実証実験を行う。評価項目と中止条件を事前に定める。安全性が確認できなければ、適用範囲を広げない。改善が必要なら修正する。そして、技術部門だけでなく、運用、経営、利用者対応の担当者も評価に加わる」
榊原はうなずいた。
「それなら、RIS構想を、現実の検証へ進められます」
「成功すると約束できるか？」
黒田は尋ねた。
榊原は、はっきりと答えた。
「いいえ。今の段階で成功を約束することはできません。実験してみなければ分からないことがあります。期待どおりの性能が出ないかもしれません。想定していなかった問題が見つかるかもしれません」
黒田は、しばらく黙っていた。
「それでいい」
彼は言った。
「成功すると言い切るために試験するのではない。成功するかどうかを確かめるために試験するんだ」
### 第十二章 それぞれの答え
会議の終わりに、黒田は全員に尋ねた。
「最後に聞きたい。君たちは、RISに何を期待する？」
最初に答えたのは、開発を担当する佐伯だった。
「私は、処理速度と実際の防御能力を結びつけたいと思っています。速いプログラムを作ること自体が目的ではありません。必要な情報を必要な時間内に分析し、正しい判断を支援できる仕組みを作りたい。PythonでもMojoでも、測定して、適した技術を選びます」
次に、三浦が答えた。
「私は、安全性を期待します。ただし、AIが攻撃をすべて見つけることを期待しているわけではありません。侵入されても被害が広がらないこと。誤判断が起きても、すぐに発見できること。権限が限定され、記録が残り、復旧できること。その仕組みを作りたいです」
高瀬は、現場の担当者として答えた。
「私は、現場が本当に助かる仕組みになってほしい。警告を大量に出すだけではなく、何を優先して確認するべきかが分かる。異常が起きたら必要な情報が集まる。担当者が判断しやすくなる。そして、AIが間違えたときにも、現場だけに責任を押しつけない。そこまで実現してほしいです」
白石は、少し考えてから口を開いた。
「私は、利用者が安心してサービスを使えることを期待します。AIが何をしているのか、何を目的に情報を扱っているのか。事故が起きたとき、何が起きたのかを説明してもらえること。技術の都合で、利用者が置き去りにされないこと。それが大切です」
最後に、榊原が答えた。
「私は、RISが防御の考え方を変える可能性に期待しています。人間が一件ずつ対応するだけでは間に合わない部分を、機械の速度で補う。異常を見つけ、判断を支援し、被害を限定する。しかし、AIを万能の存在にしない。権限を限定し、誤りを前提に設計し、人間が検証し続ける。その両方がそろって初めて、役に立つ防御AIになると思います」
全員の言葉を聞き終えた黒田は、窓の外を見た。
「私は経営者として、投資に見合う成果を求める。しかし、これからは、その成果を『AIを導入した』という言葉だけで説明してはいけないと思う」
彼は、ゆっくりと続けた。
「実際に、どれだけ守れるようになったのか。どのような危険が残っているのか。事故が起きたとき、誰が責任を持つのか。その問いに答えられることを、成果と呼ぶべきだろう」
榊原は、静かにうなずいた。
「そう思います」
「では、始めよう。ただし、技術を導入することをゴールにはしない。人を守れる仕組みになったかどうかを、確かめ続けることをゴールにする」
その言葉で、会議は終わった。
しかし、RIS構想の仕事は、ここから始まるのだった。
### エピローグ 機械の速度で守り、人間の責任で設計する
会議の翌週、黒田の机には、実証実験の計画書が置かれていた。
そこには、目標とする検知時間、処理能力、誤検知率、見逃し率、障害時の復旧手順、利用者への影響、権限の範囲、ログの管理方法、そして実験を中止する条件が記されていた。
最後のページには、経営者としての確認欄があった。
黒田は、その欄に署名した。
署名は、成功の保証ではない。
RISが期待どおりに動くという保証でもない。
技術者たちが必ず正しい答えを見つけるという保証でもない。
それは、**確かめることを約束する署名**だった。
性能が足りなければ、原因を調べる。
誤検知が多ければ、設計を見直す。
安全性が確認できなければ、適用範囲を広げない。
問題が起きれば、記録を調べ、原因を明らかにし、利用者に説明する。
そして、技術だけでは解決できない問題が見つかれば、組織の運用や責任分担も見直す。
その一つひとつが、RISを構想から実際の防御へと近づけていく。
窓の向こうでは、いつもどおりの街が動いていた。
人々は、銀行のサービスを利用し、会社のシステムに接続し、買い物をし、連絡を取り合う。
彼らの多くは、自分の情報がどのような仕組みで守られているのかを知らない。
知らなくても、安心して利用できること。
それこそが、守る側の仕事なのかもしれなかった。
AIが速くなることには意味がある。
プログラミング言語が進化することにも意味がある。
自動化によって、人間だけでは処理できない量の情報を扱えるようになることにも意味がある。
しかし、速さそのものが目的になったとき、私たちは大切なものを見失う。
どれほど高速なAIでも、守るべき人々を見誤れば、被害を生む。
どれほど高度な技術でも、運用する人間が仕組みを理解できなければ、事故の原因になる。
どれほど立派な防御システムでも、組織が責任を引き受けなければ、利用者を本当に守ったことにはならない。
だからこそ、必要なのだ。
機械の速度。
技術者の知恵。
現場の経験。
経営者の決断。
そして、利用者の立場から問い続ける人間の声。
それらがそろって初めて、技術は社会を守る力になる。
RISは、魔法の盾ではない。
未来のすべてを予測する存在でもない。
それでも、人間だけでは間に合わない仕事を機械に任せながら、人間が引き受けるべき責任を手放さない。そのための仕組みを、私たちは作ることができるかもしれない。
黒田は、署名を終えた計画書を閉じた。
その表紙には、短い一文が記されていた。
**機械の速度で守り、人間の責任で設計する。**
それは、RISの性能を保証する言葉ではなかった。
RISを開発する人々と、それを導入する組織が、忘れてはならない約束だった。
そして、守らなければならないものは、サーバーでも、プログラムでも、AIそのものでもない。
その向こう側にいる、一人ひとりの人間なのだった。
