投稿者 global-ai-media 
著名なセキュリティ専門家ブルース・シュナイアー氏が、大規模言語モデル（LLM）によるパスワード生成の脆弱性を指摘しました。本稿では、なぜ「賢い」はずのAIが安全な乱数生成に適さないのか、その技術的背景を解説するとともに、日本企業が社内ガイドラインや開発プロセスにおいて留意すべきリスク管理の要点について考察します。
セキュリティの巨人が指摘する「LLMの予測可能性」
暗号技術やセキュリティ分野の世界的権威であるブルース・シュナイアー（Bruce Schneier）氏は、自身のブログにおいて「LLMは予測可能なパスワードを生成する」という興味深い指摘を行いました。彼は、これは単にLLMの問題だけではなく、人間も同様にランダムな文字列を作るのが苦手であることに触れつつ、セキュリティにおける「真のランダム性（エントロピー）」の重要性を再確認しています。
多くの日本企業が業務効率化のために生成AIの導入を急いでいますが、この「LLMはもっともらしい答えを出すのは得意だが、ランダムな答えを出すのは苦手である」という特性は、意外と見落とされがちな盲点です。
なぜLLMは安全なパスワードを作れないのか
技術的な観点から言えば、LLMは基本的に「次に来る確率が最も高い（あるいは妥当な）単語（トークン）」を予測する確率モデルです。LLMはインターネット上の膨大なテキストデータを学習しており、その中には「よくあるパスワードのパターン」や「人間がランダムだと思い込んでいる文字列」が大量に含まれています。
例えば、LLMに「ランダムなパスワードを作って」と指示した場合、学習データ内で頻出する「P@ssw0rd123」や「Xy7#bK9」のような、一見複雑そうでも実は統計的に出現頻度の高い（＝攻撃者にとって推測しやすい）文字列を出力する傾向があります。暗号学的に安全なパスワードには、予測不可能性（高いエントロピー）が求められますが、LLMの「文脈に合わせて最もありそうな答えを出す」という仕組み自体が、この予測不可能性と相反するのです。
開発現場と一般業務における隠れたリスク
この問題は、単に「ChatGPTにパスワードを考えさせない」という単純なルールの徹底だけでは防げない側面があります。特に注意すべきは以下の2つのシナリオです。
第一に、システム開発の現場です。GitHub Copilotなどのコーディングアシスタントが普及する中、エンジニアがテストデータや設定ファイルに必要な「APIキー」や「シークレットキー」の生成をAIに任せてしまうリスクがあります。AIが提案したキーをそのままプロダクション環境で使ってしまった場合、それが学習データ由来の既知の文字列である可能性は否定できません。
第二に、一般社員による「複雑なパスワードポリシー」への対抗策です。日本の多くの組織では、定期的なパスワード変更や複雑な文字種の使用（大文字・小文字・数字・記号の混在など）を従業員に義務付けています。こうした規則に疲弊した従業員が、手っ取り早く条件を満たす文字列を作るために生成AIを利用し、その結果生成された「脆弱なパスワード」を社内システムに設定してしまうケースが懸念されます。
日本企業のAI活用への示唆
以上の議論を踏まえ、日本企業の意思決定者やセキュリティ担当者は、以下の3点を実務に反映させるべきです。
1. 「生成」と「乱数」の明確な区別と教育
従業員に対し、生成AIは「文章やアイデアの生成」には有用ですが、「セキュリティに関わるランダムな値の生成」には不向きであることを教育する必要があります。AIは計算機ではなく、確率論的な言語処理装置であることを理解させることが重要です。
2. 開発プロセスにおけるAI利用ガイドラインの策定
エンジニア向けには、暗号鍵、APIトークン、パスワードなどの機密情報を生成する際に、LLMの提案機能を使用せず、必ず言語標準の暗号学的擬似乱数生成器（CSPRNG）や専用ツール（`pwgen`など）を使用することをルール化すべきです。また、コードレビューのプロセスで、ハードコードされた認証情報がないかを確認する自動化ツールの導入も推奨されます。
3. パスワード管理のあり方の見直し
従業員がAIにパスワード生成を頼りたくなる背景には、人間にとって記憶困難なパスワードポリシーが存在する可能性があります。NIST（米国国立標準技術研究所）などの国際的なガイドラインでも推奨されているように、定期変更の強制を廃止したり、SSO（シングルサインオン）やパスワードマネージャーの導入を組織的に進めたりすることで、従業員個人の判断に依存しない認証基盤を構築することが、AI時代のセキュリティ対策としてより本質的です。