【Human-Centered AI｜Day 9/10】安全なデフォルト、コンプライアンス、Just Culture
AI導入後に人を責めるのではなく、最初から人を守る仕組みをつくる
AIを導入した後に問題が起きると、組織はしばしば人に問いを向ける。なぜ確認しなかったのか。なぜAIの誤りに気づかなかったのか。なぜ止めなかったのか。なぜ手順を守らなかったのか。だが、その前に問うべきことがある。その仕組みは、人が安全に判断できるように設計されていたのか、という問いである。
AIは誤った提案を行うことがある。不確実な情報を、あたかも確実であるかのように提示することもある。しかも実際の利用者は、忙しく、疲れており、複数の仕事を同時に抱え、時間制約の中で判断している。この現実を無視したまま、最後に利用者だけへ責任を集中させるのであれば、それはHuman-Centered AIとは言えない。NISTのAI Risk Management Framework（AI RMF）が示すように、AIは単なる技術ではなく、人間、組織、運用文脈を含む社会技術的システム（socio-technical system）として設計・統治されるべき対象である [1]。
本稿では、人を守るAI導入設計の基盤として、三つの要素を論じる。すなわち、Safe Defaults、Compliance by Design、Just Cultureである。これらはそれぞれ独立した概念ではあるが、実務上は相互補完的に機能する。安全な初期設定だけでは不十分であり、ルールが業務フローへ組み込まれていなければ回避行動が生じる。また、問題発生時に学習より非難が優先されれば、リスクは見えなくなる。したがって、Human-Centered AIに必要なのは、人が間違えないことを期待することではなく、人もAIも間違えうることを前提に、重大事故へつながりにくい設計と、失敗から学べる文化を組み込むことである。
1. Safe Defaults
何もしなくても、安全側に倒れる設計
Safe Defaultsとは、利用者が毎回完璧に判断しなくても、システムが初期状態として安全側に倒れるよう設計されていることを指す。これは古典的なセキュリティ設計原則でもあり、近年ではCISAの Secure by Design / Secure by Default の考え方として改めて強調されている [2]。CISAは、セキュリティ設定の複雑さを顧客の問題にしてはならず、もっとも重要な保護策は追加の努力なしに最初から有効であるべきだと論じている [2]。
AI導入において、この発想は特に重要である。たとえば、高リスク処理は自動実行しない、不確実性が高い場合は停止する、外部公開や送金のような高影響操作には追加確認を要求する、機密情報へのアクセスを最小権限に制限する、重要操作には取消可能な時間を設ける、AI出力をそのまま本番環境へ反映しない、といった設計がそれに当たる。重要なのは、「危険な操作を簡単にし、安全な操作を面倒にする」設計を避けることである。安全な選択が最も自然で、最も簡単な選択になっていれば、利用者の注意力や根性だけに依存しなくて済む。
この点は、人間中心設計の観点からも正当化できる。Zurkoら以来のユーザ中心セキュリティ研究は、ユーザが常に正しく安全な選択を行うと仮定するのではなく、安全な使い方が自然に選ばれる設計を目指すべきだと主張してきた [3]。したがってSafe Defaultsの核心は、「安全を利用者の努力に依存させないこと」にある。
2. Compliance by Design
守るべきルールを、仕事の流れに組み込む
コンプライアンスは、規程を作成し、読ませ、理解させれば達成されるものではない。実際の職場では、人は複数のシステムを使い、期限に追われ、成果を求められながら意思決定を行っている。そのような環境で、「規程を覚え、毎回それを思い出し、正しく判断してください」と要求することは、現実の人間行動を無視している。
Beautementらの Compliance Budget の議論は、この問題をよく説明している。人はセキュリティやコンプライアンスのために無限の時間、注意、努力を払えるわけではない。各人には、追加的な手間や不便を受け入れられる限界、すなわち「予算」があり、それを超えると順守行動は弱まり、回避や形骸化が起こる [4]。また、Stantonらの研究が示す security fatigue も、繰り返し安全判断を求められることで、人が諦め、回避し、リスクを過小評価し、判断を避けるようになることを示している [5]。つまり、コンプライアンス違反の少なくない部分は、悪意ではなく、設計が人間の運用現実と噛み合っていないことから生じる。
ここでいう Compliance by Design とは、守るべきルールを、利用者の記憶や意志力に依存させるのではなく、システムと業務フローの中へ組み込む設計思想である。たとえば、利用可能なAIツールを明示する、入力禁止情報を画面上で示す、機密情報の入力を検知して警告する、高リスク用途を自動的に専門部署へ回す、承認・記録・レビューをワークフローに統合する、AI利用目的と判断履歴をログとして残す、例外申請経路を明確にする、といった実装が考えられる。
重要なのは、違反が起きたときに「利用者が規程を読んでいなかった」で終わらせないことである。なぜ、その危険な操作が容易だったのか。なぜ、正しい手順の方が使いにくかったのか。なぜ、相談先や例外申請の経路が見えなかったのか。コンプライアンス違反は、しばしば設計の失敗でもある。したがって、Human-Centered AIにおけるコンプライアンスは、文書化された規程の存在だけではなく、それが実際の仕事の流れに埋め込まれているかどうかによって評価されるべきである [4], [5]。
3. Just Culture
個人を責める前に、行動が生まれた条件を学ぶ
Just Cultureは、失敗を無条件に許す文化ではない。また、意図的な違反や重大な無謀行為、悪意ある行動まで不問にする考え方でもない。そうではなく、人の行動そのものと、その行動を生み出した条件とを区別して考える文化である。Dekkerが論じるように、Just Cultureの要点は、結果として起きた失敗から学習する能力を維持することであり、そのためには、人々が報告したときに不公正な扱いを受けると感じないことが不可欠である [6]。
この視点は、AI導入後の問題分析において極めて重要である。たとえば、従業員が未承認の生成AIへ業務情報を入力したとする。そのとき、組織がただちに「ルール違反」とラベル付けして処分だけを行えば、短期的には統制しているように見えるかもしれない。しかし長期的には、同様の逸脱は地下化する。Kirlapposらが論じた shadow security の研究も、現場の人々が業務上の必要や使いにくさゆえに非公式な回避行動を取ること、そしてその非順守の理解こそが有効なセキュリティ改善の基礎になることを示している [7]。
Just Cultureでは、単に「誰が悪かったか」を問うのではなく、なぜその行動がその状況では合理的に見えたのかを問う。正規ツールは使いやすかったのか。必要な機能を提供していたのか。ルールは理解可能だったのか。納期や業務量に無理はなかったのか。管理職は非公式利用を黙認していなかったか。相談しても支援が得られない状況ではなかったか。こうした問いを通じて初めて、個人の判断の問題と、組織設計の問題とを分けて考えることができる [6], [7]。
Just Cultureが必要なのは、人に優しくするためだけではない。問題を早く可視化し、近接事故や小さな逸脱から学び、重大事故の前に改善するためである。非難が強い環境では、人は失敗を隠し、誤使用を黙り、危険挙動を共有しなくなる。その結果、組織は学習の機会を失う。したがってJust Cultureは、倫理の問題であると同時に、リスク感知と組織学習のためのガバナンス原則でもある。
4. 「Human-in-the-loop」だけでは人を守れない
AIの最終段階に人間を置けば安全になる、という発想は広く見られる。しかし、これはしばしば誤解を含んでいる。人間が最後に確認していても、判断材料が見えない、処理量が多すぎる、止める権限がない、期限が短すぎる、AIの推奨に反対しにくい、失敗時の責任だけを負わされる、といった条件下では、その人間は安全装置ではない。むしろ、システムの欠陥を最後に吸収させられる存在である。
AI RMFや関連研究が繰り返し示すのは、人間の関与は「存在するかどうか」ではなく、意味ある関与として設計されているかどうかが重要だという点である [1]。言い換えれば、人間を最後に置くことよりも、人間が失敗しても重大事故になりにくい設計を先に行うべきである。Safe Defaultsはそのための第一の防壁であり、Compliance by Designはルール逸脱を起こりにくくし、Just Cultureは逸脱や失敗からの学習を可能にする。Human-in-the-loopは、それらを補完する一要素にすぎない。
5. 三つは連動している
Safe Defaultsだけでは、すべてのリスクを防げない。
Compliance by Designだけでは、現場がルールを回避することがある。
Just Cultureだけでは、危険な操作そのものを防止できない。
だからこそ、三つは連動していなければならない。
Safe Defaults は、危険な行動がそのまま重大事故へつながらないようにする。
Compliance by Design は、守るべきルールを実際の仕事の流れへ組み込む。
Just Culture は、問題発生時に個人攻撃ではなく、学習と改善につなげる。
この三つがそろって初めて、人は安全にAIを使い、問題を早く報告し、組織も継続的に改善できる。Human-Centered AIとは、人間が強くなければ成立しない仕組みではない。むしろ、人間の限界、疲労、迷い、回避行動、沈黙の可能性まで織り込んだうえで、それでも安全と学習が成立するよう設計されたシステムなのである [1], [4], [6]。
6. 具体例：生成AIへの機密情報入力
たとえば、従業員が顧客情報を外部の生成AIへ入力してしまったとする。人だけを責める組織であれば、「ルール違反をした従業員を処分する」で終わるかもしれない。しかし、Human-Centered AIの観点では、それだけでは不十分である。
Safe Defaultsの観点からは、機密情報入力を検知できなかったのか、外部AIへのアクセス制限は可能だったのか、承認済みAIを標準設定として提供できなかったのかを問う必要がある。Compliance by Designの観点からは、利用可能ツールが明確だったか、入力禁止情報が画面上で確認できたか、例外利用申請経路があったか、ログや監査証跡が残っていたかを確認すべきである。Just Cultureの観点からは、なぜその人が外部AIを使ったのか、正規ツールでは仕事ができなかったのか、納期や負荷が過剰ではなかったか、同じ行動を取っている人が他にもいないかを調べる必要がある。処分の要否とは別に、仕組みの改善責任が必ず存在する。
7. 具体例：AIによる誤ったセキュリティ判断
別の例として、AIが正常通信を攻撃と誤判定し、担当者がシステムを停止してしまった場合を考える。このときも、「なぜ担当者はAIを信じたのか」だけでは不十分である。確認すべきは、AIの不確実性が表示されていたか、反対証拠が見えていたか、停止前の追加確認が必要な設計だったか、影響の大きいシステムにSafe Defaultがあったか、担当者は相談や保留ができたか、過去にAIへ異議を唱えた人が責められていなかったか、である。
人の判断を改善するには、人だけを見るのではなく、判断を取り囲むシステム全体を見る必要がある。ここにHuman-Centered AIの本質がある。
8. HCCSが考えるAI導入後の責任
AI導入後に事故が起きたとき、最後に操作した人だけを責任者にしてはならない。問うべき対象はもっと広い。AIを選定した人、利用目的を決めた人、デフォルト設定を決めた人、業務フローを設計した人、リスクを承認した人、教育や支援体制を整えた人、そして現場で最終行動を行った人である。
責任そのものを消すことはできない。しかし、その責任をもっとも弱い立場の利用者へ集中させるのではなく、設計、導入、運用の全体へ適切に分配することが必要である。これこそが、Just CultureとAIガバナンスを接続する視点である。
9. 最後に
人間は、いつか間違える。
AIも、いつか間違える。
重要なのは、どちらも間違えないことを前提にすることではない。
間違いが起きたときに、それが重大事故へつながりにくい仕組みを最初からつくることである。
Human-Centered AIとは、
AI導入後に人を責めることではない。
最初から人を守るガードレールと、
問題から学べる文化を設計することである。
安全なデフォルト。
仕事の流れに組み込まれたコンプライアンス。
失敗を隠さず、組織学習へ変えるJust Culture。
この三つが、人とAIの双方が失敗しうる現実を前提とした、持続可能なAIガバナンスを支える。
あなたの組織は、AI利用者に「間違えないこと」を求めているだろうか。
それとも、間違いが起きても人と組織を守れる仕組みを設計しているだろうか。
参考文献
[1] E. Tabassi, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)," NIST AI 100-1, National Institute of Standards and Technology, Jan. 2023. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
[2] Cybersecurity and Infrastructure Security Agency, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default, Oct. 2023. [Online]. Available: https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf
[3] M. E. Zurko and R. T. Simon, "User-centered security," in Proceedings of the 1996 Workshop on New Security Paradigms, 1996, pp. 27-33. [Online]. Available: https://dl.acm.org/doi/pdf/10.1145/304851.304859
[4] A. Beautement, M. A. Sasse, and M. Wonham, "The compliance budget: Managing security behaviour in organisations," in Proc. New Security Paradigms Workshop (NSPW), 2008, pp. 47-58. [Online]. Available: https://www.nspw.org/papers/2008/nspw2008-beautement.pdf
[5] B. Stanton, M. F. Theofanos, S. S. Prettyman, and S. Furman, "Security fatigue," IT Professional, vol. 18, no. 5, pp. 26-32, 2016. [Online]. Available: https://csrc.nist.gov/pubs/journal/2016/09/security-fatigue/final
[6] S. W. A. Dekker, "Just culture: Who gets to draw the line?," Cognition, Technology & Work, vol. 11, pp. 177-185, 2009. [Online]. Available: http://kajabi-storefronts-production.s3.amazonaws.com/sites/3839/themes/2147871170/downloads/SjaeWrbjSmenkl4Nok8Z_JustCultureCTW.pdf
[7] I. Kirlappos, S. Parkin, and M. A. Sasse, "Learning from 'Shadow Security': Why understanding non-compliance provides the basis for effective security," 2014. [Online]. Available: https://discovery.ucl.ac.uk/id/eprint/1424472/1/Kirlappos et al. - 2014 - Learning from "Shadow Security" Why understanding.pdf