生成AIの発達によって誰もが高品質な文章を生成できるようになりましたが、教師が学生のレポートを採点する時や、製品購入時に誰かのレビューを参考にする時など、文章がAI製かどうかを見分けたい場面も存在します。ミシガン大学のAI研究者であるアンブジ・テワリ教授が、AI生成のテキストを検出するシステムの仕組みや課題についてまとめました。
AI透かしを利用した手法は問題を「検出」から「検証」へと変えますが、AIベンダーの協力がなければ実装できないという課題があります。また、ユーザーが何らかの手段でAI透かしを無効化できてしまう場合も役に立たないとのこと。
テワリ氏は、「広い視点で見れば、AI生成テキスト検出器は激化する軍拡競争の一環です。検出器が有効であるためには公開されている必要がありますが、その透明性によってAI側が回避することが可能になります」「結局のところ、検出器のようなツールが決して完璧ではないという事実と共存する方法を学ばなければならないのです」と述べました。
⇧ いや、「AI」が完璧でないことは「幻覚（ハルシネーション）」の問題がある以上、周知の事実だと思うのだが...
肝心の、
『「結局のところ、検出器のようなツールが決して完璧ではないという事実と共存する方法を学ばなければならないのです」と述べました。』
の具体的な対応策を提示して欲しいよね...
Azure StorageアカウントのTLSのバージョンアップ対応が必要らしいが...
何やら、
To meet evolving technology and regulatory needs and align with security best practices, we are removing support for Transport Layer Security (TLS) 1.0 and 1.1 for both existing and new storage accounts in all clouds. TLS 1.2 will be the minimum supported TLS version for Azure Storage starting February 3, 2026.
⇧ とあり、毎度お馴染み、「Microsoft」側の都合による「変更」なのだが、「影響調査」は「ユーザー」側に丸投げですと...
ちなみに、しれっと公式の「ドキュメント」が更新されているようなのだが、
責任の分担
オンプレミスのデータセンターでは、お客様がスタック全体を所有します。 クラウドに移行すると、一部の責任が Microsoft に移ります。 次の図は、スタックのデプロイの種類に応じて、お客様と Microsoft の間の責任の範囲を示しています。
https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility
責任マトリックス
次の表では、スタックの各領域について、お客様と Microsoft の間の責任の分割について詳しく説明します。
https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility
共有責任の説明
お客様と Microsoft の間で一部の責任が共有され、部門はサービス モデルによって異なります。
- アプリケーション - IaaS では、デプロイされたアプリケーションを完全に担当します。 PaaS と SaaS では、Microsoft はアプリケーション スタックの一部を管理しますが、アプリケーションの構成、コード セキュリティ、アクセス制御を担当します。
- ネットワーク制御 - IaaS では、ファイアウォールやネットワークのセグメント化を含むすべてのネットワーク セキュリティを構成します。 PaaS では、Microsoft はベースライン ネットワーク セキュリティを提供しますが、アプリケーション レベルのネットワーク制御を構成します。 SaaS では、Microsoft がネットワーク セキュリティを管理します。
- クライアント デバイス - SaaS シナリオでは、Microsoft が一部のデバイス管理機能を提供する場合がありますが、エンドポイントの保護とコンプライアンスを担当する必要があります。
https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility
⇧ 上記にあるように、「Microsoft」側の都合による「変更」によって被る「影響」は「ユーザー」側で負担する必要があるという...
せめて、「影響範囲」を特定する方法を連携して然るべきな気がするのだが...
とりあえず、
⇧「ストレージアカウント」側の「TLS（Transport Layer Security）」の「バージョン」を確認する方法については説明があった。
一応、「ChatGPT」氏に『「Azure Storageアカウント」の「TLS（Transport Layer Security）」の「バージョン」を確認する方法』について質問してみたところ、以下のような回答が返ってきた。
Azure CLI を使って 複数のストレージアカウントの TLS（最小 TLS バージョン）情報を一覧取得する方法は、CLI の出力に含まれる
minimumTlsVersionプロパティを抜き出す形で実行できます。基本的にはaz storage account listと JMESPath クエリを組み合わせます。Azure
■Azure CLI で一覧として取得
az storage account list \
--query "[].{Name:name, ResourceGroup:resourceGroup, MinimumTlsVersion:minimumTlsVersion}" \
--output table
■グループ／サブスクリプション単位で絞る
az storage account list \
-g MyResourceGroup \
--query "[].{Name:name, MinimumTlsVersion:minimumTlsVersion}" \
--output table
⇧ まぁ、概ね、信じて良さそうではある。
問題は、「クライアント」側なのよね...
流石に、「クライアント」側の「アプリケーション」で「TLS（Transport Layer Security）」の「バージョン」を明示的に指定しているようなことは無いと思うのだが、本当に「影響」が出ない「実装」になっているのかの「確認」が必要になって来るのよね...
ちなみに、
クライアント アプリケーションによって使用される TLS のバージョンを検出する
ストレージ アカウントに対して TLS の最小バージョンを適用すると、それより古いバージョンの TLS を使用してデータを送信するクライアントからの要求が拒否される危険があります。 TLS の最小バージョンの構成がクライアント アプリケーションにどのように影響する可能性があるかを理解するために、Microsoft では、Azure Storage アカウントのログ記録を有効にし、一定期間後にログを分析して、クライアント アプリケーションによって使用される TLS のバージョンを検出することをお勧めします。
Azure Storage アカウントに対する要求をログに記録し、クライアントによって使用される TLS のバージョンを特定するために、Azure Monitor の Azure Storage ログ記録を使用できます。 詳細については、「Azure Storage を監視する」を参照してください。
⇧ 上記の方法だと、対象の「ストレージアカウント」の数が膨大な場合に地獄のような作業になると思うのだが...
仮に、確認が必要な「クライアント」が10000件とかあった場合、どうするんですかね？
「ユーザー」に負担を強いることになるわけなのだが、「Microsoft」はそのあたりどう考えているのだろうか？
まぁ、毎度の如く「ユーザー」のことは全く考慮してくれていないということですかね...
流石が、「Microsoft」安定の不親切さ、且つ、不誠実さ。
過去の対応を見ても、「マイルストーン」が無いという誠に遺憾な状況...
とりあえず、「Microsoft」側の都合を強制するのであれば、事前に「移行計画」としての「マイルストーン」の提示はあって然るべきだと思うのですが...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
