近年は生物学などの分野でAIを用いた研究が盛んになっており、AIは科学研究を大幅に加速させると期待されています。しかし、AIを用いた研究論文が注目を浴びる一方で、その内容をファクトチェックして膨大な間違いを指摘した論文が無視されていると、サンフランシスコ大学応用データ倫理センター創設者のレイチェル・トーマス氏が指摘しています。
AIを使った科学研究が注目を浴びる一方で膨大な間違いを指摘した「論文のファクトチェック」が無視されている - GIGAZINE
トーマス氏は、「これらの論文は、専門分野外の研究におけるAIの主張を評価することがいかに困難か、あるいは不可能であるかを改めて認識させてくれます」「一見すると印象的な論文のうち、厳密な検証に耐えられるものはどれほどあるのでしょう？数百の酵素予測を確認する作業は、それらを生成したAIモデルを構築する作業ほど華やかではありませんが、むしろより重要な作業です」とコメントしました。
AIを使った科学研究が注目を浴びる一方で膨大な間違いを指摘した「論文のファクトチェック」が無視されている - GIGAZINE
⇧ 何と言うか、「幻覚（ハルシネーション）」の問題が人口に膾炙している以上、論文の査読などは人手に頼らざるを得ない気がしますが、人手が足りないという...
とりあえず、
「疑わしきは罰せず」（うたがわしきはばっせず、ラテン語: in dubio pro reo）とは、刑事裁判において、事実の存否が明確にならないときには被告人にとって有利に扱わなければならないとする法諺である。ラテン語の直訳から「疑わしきは被告人の利益に（疑わしきは被告人の利益に従う）」ともいう
⇧ の思想と同様な仕組みが、論文の査読・評価で機能しているということは信じたいが、膨大な数の論文が存在する以上、「選択回避の法則（決定回避の法則）」は不可避なので、課題解決が難しそうですな...
Azureのサービスを利用したシステム全体を横断的、且つ、一元管理で監視・通知する仕組みは無いということか
「Microsoft Azure」に限らず、「クラウドサービスプロバイダー」の「サービス」を利用して「ソフトウェア開発」をすると、「分散システム」になることあるあるですと。
一般的に、「クラウドサービスプロバイダー」の「サービス」を利用した「システム」の場合、
- IaaS（Infrastructure as a Service）
- PaaS（Platform as a Service）
- SaaS（Software as a Service）
の「サービス」が混在した「システム」の構成になることあるあるだと思います。
昨今は、上記以外の「XaaS」も増えてきているようなので、より一層、複雑さが増していると言っても過言では無いですと。
で、そうなった場合に、各々の「システム」の間の通信について、「システム全体を横断的、且つ、一元管理で監視・通知」したいですと。
なのだが、少なくとも「Microsoft Azure」においては、
⇧ 上記サイト様によりますと、残念ながら、「システム全体を横断的、且つ、一元管理で監視・通知」できる仕組みは用意されていないようだ。
まぁ、
⇧ 上記の記事の時の調査で、「IaaS（Infrastructure as a Service）」間の「監視」に限定した「サービス」とかに止まっている以上、「システム全体を横断的、且つ、一元管理で監視・通知」というのは夢物語という感じですかね...
「クラウドサービスプロバイダー」が提供している「サービス」間で通信が正常に行われたのかの「監視・通知」を一元管理できる仕組みは用意して欲しいお気持ち...
そもそも、「Microsoft Azure」は提供している「サービス」について、
- IaaS（Infrastructure as a Service）
- PaaS（Platform as a Service）
- SaaS（Software as a Service）
の分類がハッキリしていない時点で、「監視・通知」云々以前の問題なのかもしれないですが...
一応、
Azure ランディング ゾーンとは
Azure ランディング ゾーンは、8 つの設計領域にわたる主要な設計原則に準拠した環境です。
https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/ready/landing-zone/
これらの設計原則は、すべてのアプリケーション ポートフォリオに適合し、アプリケーションの移行、最新化、イノベーションを大規模に実現できます。
https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/ready/landing-zone/
Azure ランディング ゾーンでは、サブスクリプションを使用することで、アプリケーション リソースとプラットフォーム リソースが分離されてスケーリングされます。 アプリケーション リソースのサブスクリプションはアプリケーション ランディング ゾーンと呼ばれ、プラットフォーム リソースのサブスクリプションはプラットフォーム ランディング ゾーンと呼ばれます。
https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/ready/landing-zone/
⇧「Azure ランディング ゾーン」なる「Azure」の「サービス」を利用している場合の設計思想が存在するらしいが、「システム全体を横断的、且つ、一元管理で監視・通知」という要件を実現できるのかが分からない...
仮に、「Azure ランディング ゾーン」を導入した場合に、どれほどの「コスト」になるのかサッパリ見えてこないのも問題なのだが、
すべてのクラウド デプロイの種類において、データと ID を所有するのはあなたです。 お客様にはデータと ID、オンプレミス リソース、制御するクラウド コンポーネントを保護する責任があります。 制御するクラウド コンポーネントは、サービスの種類によって異なります。
https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility
デプロイの種類に関係なく、お客様は常に以下に対する責任を負います:
- データ
- エンドポイント
- Account
- アクセス管理
https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility
⇧ やはり、「責任共有モデル」の責任の分担がファジーなのが良くないと思われる。
あとは、「サービス」についての「SLA（Service Level Agreement）」もハッキリしないのよね...
Wikipediaの「サービス水準合意（SLA：Service Level Agreement）」の説明の妥当性が分からないので何とも言えないのだが、
サービス水準合意 (サービスすいじゅんごうい、英: Service Level Agreement、SLA) とは、サービス提供者と顧客の間で結ばれるサービス水準に関する合意である。サービスレベル契約と言われることもある。サービスの特定の要素 (品質、可用性、責任) について、サービス提供者とユーザーの間で合意する。SLAに含まれる最も一般的な要素は、契約で合意されたとおりにサービスを顧客に提供するという点である。
通信サービスやコンピュータ・アプリケーション・サービスなどで、サービスの定義、内容、範囲、品質、達成目標、稼働率などを記述する。SLAでは平均故障間隔 (MTBF)、平均修復時間 (MTTR) などを技術的に定義し、障害報告やクレジットの支払い、責任をもって監視するさまざまなデータレートの報告に責任がある当事者を特定する。
⇧ とある内容を実施しているのであれば、全ての「サービス」間を「横断的、且つ、一元管理で監視・通知」できる仕組みがありそうなものだが...
ちなみに、
サービス水準に関する仕様を記述したものをサービス水準仕様（英: Service Level Specification、SLS）という。
⇧ 上記によると「サービス水準仕様（SLS：Service Level Specification）」なるものがあるらしいのだが、「Microsoft Azure」では見当たらなかった...
よく分からないのだが、「サービス水準仕様（SLS：Service Level Specification）」は無いが「サービス水準合意（SLA：Service Level Agreement）」を強制させられるというのが「Microsoft Azure」が提供している「サービス」の流儀らしい...
普通に考えて「仕様」を把握できて「合意」の判断が下せるとは思うのだが、「Microsoft」のやっていることは、極端な話、
- ステーキ（和牛ランクA5）
- ステーキ（外国産）
- ステーキ（牛ですらない）
の何が提供されるかは分からないけど勘弁してね、だって「サービス水準」の「仕様」として定義していないからね、という行為を平然としているのと同義な気がしている...
「Microsoft」以外の「クラウドサービスプロバイダー」の提供している「サービス」について、どのようになっているのかが分からないのだが、「Microsoft Azure」の提供している「サービス」においては圧倒的に「サービス」の「利用者」が不利な状況が当然となっているというのが解せない...
いずれにしろ、「Azure」の「サービス」として、「システム全体を横断的、且つ、一元管理で監視・通知」できるような仕組みは無さそう...
「Azure」の「サービス」に限らず、「クラウドサービスプロバイダー」の提供する「サービス」は「透明性」が無いこと、この上ないですな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
