米Google傘下のGoogle DeepMindは10月23日（現地時間）、AI生成テキストを識別する技術「SynthID Text」を発表した。デジタルウォーターマーク（電子透かし）技術を用いて、AIが生成したテキストに人間の目には見えない特殊な印を埋め込むことで、そのテキストがAIによって生成されたものかどうかを判別することを可能にする。
Google DeepMind、AI生成テキスト判別向け透かし「SynthID Text」リリース - ITmedia NEWS
同社は昨年8月には、Imagenで生成した画像向けの電子透かし「SynthID」をリリースしている。
Google DeepMind、AI生成テキスト判別向け透かし「SynthID Text」リリース - ITmedia NEWS
⇧ とりあえず、
アメリカのライス大学（Rice University）に所属するリチャード・G・バラニューク氏ら研究チームは、生成AIモデルが合成データを学習して新たな合成データを生成するループが生じると、生成される合成データの品質はどんどん劣化していくと報告しました。
⇧ 上記サイト様で紹介されている事象の回避策は用意できたということなんですかね？
By the way、
インドの数学者、シュリニヴァーサ・ラマヌジャンは、32年という短い生涯の中で3900以上の恒等式や方程式をまとめており、「インドの魔術師」の異名を取ったことで知られています。ラマヌジャンの数多くの数学的発見は、当時の数学界を驚かせただけでなく現代の数学者にも依然として大きな影響を与えています。
32歳で没したインドの天才数学者ラマヌジャンの研究結果は現代でもなおさまざまな分野で応用されている - GIGAZINE
⇧ ラマヌジャンが享年32歳だったというのが衝撃なんだが...
天才っているんだなぁ...
Azureのリソースに対する要求をAzure Resource Managerが一元管理してるのは分かったのだが...
公式のドキュメントによると、
一貫性のある管理レイヤー
ユーザーが Azure API、ツール、または SDK のいずれかを介して要求を送信すると、その要求はリソース マネージャーによって受信されます。 要求は、認証および承認された後、適切な Azure サービスに転送されます。 すべての要求は同じ API を介して処理されるため、すべての異なるツールで一貫した結果と機能が得られます。
Azure Resource Manager の概要 - Azure Resource Manager | Microsoft Learn
次の図は、Azure 要求の処理において Azure Resource Manager が果たす役割を示しています。
Azure Resource Manager の概要 - Azure Resource Manager | Microsoft Learn
⇧ とあり、「Azure Resource Manager」というものが内部的に、Azureリソースへのアクセスを一元管理していますと。
この内、アプリケーションなどから、Azureリソースの用意してるAPIを利用するとなった場合は、
- SDKs
Java、C#、JavaScript、Python、etc... - Rest clients
curl
などによるアクセスの方法が用意されていそうなのだが、当然、APIを誰でも実行できてしまうのは宜しくないので、APIを利用するための「認証」が必要ですと。
ところが、APIを利用するための認証方法として、Azureで用意されているものにどんなものがあるのか皆目見当が付きませんと...
Azureの用意しているREST APIを利用するための認証方法の全量、情報の在り処が分かり辛い
で、Azureの公式のドキュメントで「REST API」のページを確認すると、
クライアント アプリケーションを Microsoft Entra ID に登録する
ほとんどの Azure サービス (Azure Resource Manager プロバイダーやクラシック デプロイ モデルなど) では、サービスの API を呼び出す前に、クライアント コードで有効な資格情報で認証する必要があります。
認証は、Microsoft Entra IDによってさまざまなアクター間で調整され、認証の証明としてクライアントにアクセス トークンを提供します。 その後、トークンは、後続の REST API 要求の HTTP 承認ヘッダーで Azure サービスに送信されます。 トークンの 要求 はサービスに情報を提供し、クライアントを検証し、必要な承認を実行できるようにします。
⇧ とあり、少なくとも、
で、「認証」の方法が大きく分けて2つあるように思えますと。
マネージド ID REST API リファレンス
Azure リソースのマネージド ID は、Azure Active Directory で自動的に管理される ID を Azure サービスに提供します。 この ID を使用して、コードに資格情報が含まれていなくても、Azure AD の認証をサポートする任意のサービスに認証することができます。
⇧ とあり、まずもって、分類がおかしいよね...
普通に考えたら、
でドキュメントを、「認証方法」の全量の観点で分類・整理するべきな気がするんだが...
ちなみに、
ワークロード ID とは
ワークロード ID とは、他のサービスやリソースを認証してアクセスするためにソフトウェア ワークロード (アプリケーション、サービス、スクリプト、コンテナーなど) に割り当てる ID です。 この用語は業界全体で一貫していませんが、通常、ワークロード ID は、一部のシステムでソフトウェア エンティティを認証するために必要になるものです。
たとえば、GitHub Actions から Azure サブスクリプションにアクセスするには、それらのサブスクリプションにアクセスできるワークロード ID がアクションに必要です。 ワークロード ID は、Amazon S3 バケットへの読み取り専用アクセスを持つ EC2 インスタンスにアタッチされた AWS サービス ロールである場合もあります。
⇧ とあって、わけが分からないのだが、
⇧ 上記サイト様にある情報を、ザックリまとめると、
| No | 認証方法 | 認証情報 | 内容 |
|---|---|---|---|
| 1 | マネージド ID | 証明書 | オンプレミス環境から利用不可 |
| 2 | サービスプリンシパル | クライアントID ※1 | オンプレミス環境から利用可能 |
| クライアントシークレット ※1 | |||
| 証明書 |
※1 「クライアントID」、「クライアントシークレット」はセット。つまり、「クライアントID」と「クライアントシークレット」を認証情報とするか、「証明書」を認証情報とするか。後述になるが、正確には、「クライアントID」と「クライアントシークレット」を認証情報とする場合は、他にも情報が必要。
⇧ ということになるんかね。
で、「サービスプリンシパル」はというと、
サービス プリンシパルは、特定のテナント内のグローバル アプリケーション オブジェクトのローカル表現、つまりアプリケーション インスタンスです。 アプリケーション オブジェクトは、アプリケーションが使用されるすべてのテナントで、サービス プリンシパル オブジェクトを作成するためのテンプレートとして使用されます。 サービス プリンシパル オブジェクトには、特定のテナント内でアプリが実際に実行できること、アプリにアクセスできるユーザー、アプリからアクセスできるリソースを定義します。
⇧ うむ、全く分からん。
というか、「マネージド ID」は『特別な種類の「サービスプリンシパル」』って話になっとるし...
で、「アプリケーション」はというと、
アプリケーションは、アプリケーション オブジェクトによって定義される抽象エンティティ (テンプレート) です。 アプリケーション オブジェクトは、すべてのテナントにわたって使用するためのアプリケーションのグローバルな表現です。 アプリケーション オブジェクトでは、トークンの発行方法、アプリケーションがアクセスする必要があるリソース、アプリケーションが実行できるアクションが記述されます。
⇧ うむ、全く分からん。
アプリケーションの登録
ID およびアクセス管理の機能を Microsoft Entra ID に委任するには、アプリケーションを Microsoft Entra テナントに登録する必要があります。 アプリケーションを Microsoft Entra ID に登録するとき、アプリケーションの ID 構成を作成します。これによって Microsoft Entra ID との統合が可能になります。
Microsoft Entra ID のアプリケーションとサービス プリンシパル - Microsoft identity platform | Microsoft Learn
⇧ 兎に角、「Microsoft Entra ID」に登録するものを「アプリケーション」と言うらしく、「アプリケーション」を登録することで、初めて「サービスプリンシパル」が生成されるらしい。
何と言うか、絶望的に分かり辛いし、絶望的に「ファインダビリティ」が低過ぎて、ドキュメントの構成については、再考してもらいたいところですな...
「サービスプリンシパル」によるREST APIを利用するための認証
で、結局のところ、AzureにおけるREST APIを利用するための「認証方法」の全量が全くもって分からないのだが、オンプレミス環境から利用できるのは「サービスプリンシパル」による「認証」しか受け付けないらしいので、
トークンを取得する
アプリケーションに必要な承認を獲得後、API のアクセス トークンの取得を開始します。 クライアント資格情報の許可を使用してトークンを取得するには、/token Microsoft ID プラットフォームに POST 要求を送信します。 以下のようにいくつかの異なるケースがあります。
https://learn.microsoft.com/ja-jp/entra/identity-platform/v2-oauth2-client-creds-grant-flow
⇧ 上記の「認証」を利用する形になるらしい。
で、『共有シークレットを使ったアクセス トークン要求』の例を見ると、
最初のケース:共有シークレットを使ったアクセス トークン要求
# Replace {tenant} with your tenant!
curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d 'client_id=00001111-aaaa-2222-bbbb-3333cccc4444&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=A1bC2dE3f...&grant_type=client_credentials' 'https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token'
https://learn.microsoft.com/ja-jp/entra/identity-platform/v2-oauth2-client-creds-grant-flow
⇧ とあるのだが、「scope」に何を設定すれば良いのかがよく分からない...
「Microsoft Graghの場合」と言っているのなら、何故、その他のリソースの設定できる一覧の参照先を載せないのか...
『同意に関するドキュメント』のリンク先のページを見てみたが、
.default スコープ
scope={resource-identifier}/.default を使用することは、機能的には v1.0 エンドポイントの resource={resource-identifier} と同じです (ここで、{resource-identifier} は API の識別子 URI であり、たとえば Microsoft Graph の場合は https://graph.microsoft.com)。
https://learn.microsoft.com/ja-jp/entra/identity-platform/scopes-oidc#the-default-scope
⇧ いや、「Microsoft Graph」以外の設定の仕方を教えて欲しいんだわ...
「{resource-identifier}」の一覧ページの参照先を載せてくれれば良いのに、何故、載せないのか...
「Microsoft Graph」以外は使ってはいけないのかと疑心暗鬼に陥るからして、「Microsoft Graph」以外も利用できるのあるならば、「Microsoft Graph」以外に設定できる「{resource-identifier}」の一覧について、ドキュメントに説明を載せて欲しいんだが...
追記：↓ ここから
何やら、
クライアント資格情報の付与フローと .default
クライアント サービス内のクライアント資格情報要求には scope={resource}/.default を含める "必要があります"。 ここで、{resource} はアプリが呼び出す予定の Web API であり、アクセス トークンを取得する必要があります。
https://learn.microsoft.com/ja-jp/entra/identity-platform/scopes-oidc#the-default-scope
⇧『共有シークレットを使ったアクセス トークン要求』の場合は、「{resource}」になるらしいのだが、どちらにしろ、設定できる値の一覧は載せてくれていないんだわ...
あと、ハマりポイントとしては、
⇧ scopeの値は、エスケープ処理が必要になるっぽい。
例えば、「Azure Key Vault」のREST APIを利用するための認証のアクセストークンを取得する場合であれば、
■エスケープ処理前：「Azure Key Vault」のREST APIを利用するための認証のアクセストークンを取得する際のscopeの{resource}
scope=https://vault.azure.net/.default
■エスケープ処理後：「Azure Key Vault」のREST APIを利用するための認証のアクセストークンを取得する際のscopeの{resource}
scope=https%3A%2F%2Fvault.azure.net%2F.default
⇧ という感じで、エスケープ処理した値を設定する必要があると。
「{resource-identifier}」と「{resource}」の違いもよく分からんし、相も変わらずMicrosoftのドキュメントはカオスだなぁ...
追記：↑ ここまで
Microsoftのドキュメントから正確な情報を探すのに、どれだけ不毛な時間を費やさなければならないのか...
たらい回しにされた挙句、解決できる情報に辿り着くことが滅多に無いからして、徒労感しか残らない...
ちなみに、
⇧ 何か、エンドポイントがバグってるって話が出てるんだが...
「パトラッシュ、疲れたろう？」
「僕も疲れたんだ。なんだか、とても眠いんだ。」
毎度モヤモヤ感が半端ない…
今回はこのへんで。
