オンライン掲示板のRedditでは、「私の新しい趣味：AIがMicrosoftの従業員を徐々に狂わせていく様子を見る」と題する投稿が話題となり、「AIが『直しました』と言い、人間が『いいえ、まだ壊れています』と言い、AIが変更を加えて『問題ありません、直りました』と言い、さらに数回繰り返すところが気に入っています」といったコメントや、「残念なことに、私もまさにこのパターンに従う人間の開発者と一緒に働いたことがあります」とのコメントのほか、「問題は、今後10年間でモデルが実際に改善され、実現可能になるという確かな証拠がないことです。
「AIがMicrosoftの従業員を徐々に狂わせていく様子を見るのが趣味」というネットユーザーの投稿が話題に - GIGAZINE
テストと研究はともかく、製品に導入するのは全く別物です。大手ソフトウェア企業は、株主の利益を満足させるために運営されています」など、未完成で不確かな製品を公開することに異議を唱えるコメントが付けられました。
「AIがMicrosoftの従業員を徐々に狂わせていく様子を見るのが趣味」というネットユーザーの投稿が話題に - GIGAZINE
なお、GitHub Copilotのコーディングエージェントは有料サービスのCopilot Pro+およびCopilot Enterpriseの契約者に提供されており、GitHub CLIだけでなくiOSとAndroidのGitHub Mobileユーザーも利用できるようになります。記事作成時点ではあくまでパブリックプレビュー版であり、今後機能の改善が期待されます。
「AIがMicrosoftの従業員を徐々に狂わせていく様子を見るのが趣味」というネットユーザーの投稿が話題に - GIGAZINE
⇧ ユーザーを「人柱」にしているってことですね...
「幻覚（ハルシネーション）」の問題が無くならない以上、人手による「ソースコード」の「動作検証」が必要なのだが、「Microsoft」側で「品質保証（QA：Quality Assurance）」は為されないということですかね...
とりあえず、
◆AI支援の落とし穴
上級エンジニアがAIツールで開発をしている様子をながめると、まるで魔法のようですが、よく見るとAIの提案をそのまま受け入れているのではなく、常に次のような作業を行っていることがわかります。
Googleのエンジニアが語るAI支援コーディングの「70％問題」、AIが生産性を爆上げしたのになぜ製品は改善されない？ - GIGAZINE
・生成されたコードをよりコンパクトで的を絞ったモジュールへとリファクタリングする。
・AIが見逃したエッジケース、つまり極端な事例への処理を追加する。
・包括的なエラー処理の追加。
・型定義とインターフェースの強化。
・アーキテクチャー上の判断の吟味。
Googleのエンジニアが語るAI支援コーディングの「70％問題」、AIが生産性を爆上げしたのになぜ製品は改善されない？ - GIGAZINE
⇧ 最終的には、人間が頑張る必要があるわけだ。
にもかかわらず、
AIが高度なコードを生成するようになったことで、顧客管理ソフトウェアを手がけるSalesforceのCEOが「AI導入が成功したので今年はエンジニアを雇わない」と発言したり、半導体大手・NVIDIAのCEOが「AIがコードを書くのでもうプログラミングを学ぶ必要はない」と発言したりして物議を醸している一方、AIツール自身はユーザーにプログラミングを学ぶよう提言しています。
AIがすべてのプログラミングコードを生成するようになるので「コーディングを学ぶのは時間の無駄」とReplitのCEOが答える - GIGAZINE
AIによって置き換えられる人間の技能を巡るビジネスリーダーたちの議論に、知識のない人でもプロンプトを入れるだけでアプリを作れるAIを開発したスタートアップ・ReplitのCEOの発言が加わりました。
AIがすべてのプログラミングコードを生成するようになるので「コーディングを学ぶのは時間の無駄」とReplitのCEOが答える - GIGAZINE
⇧ 上記のように「経営層」の頭の中はお花畑といった感じで、乖離が凄まじいのよね...
まぁ、会社の業績が傾いたとしても「経営層」の責任なので、自由にしたら良いのだが...
Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）同士の接続方式は大きく分けて2つらしいが...
ネットの情報で上位表示された「Microsoft」の公式のドキュメントによると、
高可用性 VNet 間接続
同じアクティブ/アクティブ構成を Azure VNet 間接続にも適用できます。 各仮想ネットワークにアクティブ/アクティブ VPN ゲートウェイを作成してから、両方を接続して、2 つの VNet 間に 4 つのトンネルが存在する同じフル メッシュ接続を構成できます。 これを次の図に示します。
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-highlyavailable
■Azure Virtual Network Peering
⇧ 上記の2つの方式が「Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）」間の接続方式らしい。
とりあえず、
- Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）同士の接続方式
のような分類になるようだ。
ややこしいのは、
ExpressRoute は、オンプレミスと Azure のネットワークをインターネットを介さずに直接接続するためのサービスです。
ExpressRoute 回線 (ExpressRoute Circuit) と呼ばれる Azure リソースを作成し、その中にピアリング情報を構成することで利用できます。
https://jpaztech.github.io/blog/network/considerations-of-microsoft-peering/
接続先に応じて下記 2 種類のピアリング種類が用意されており、ひとつの ExpressRoute 回線上に両ピアリングを同時に構成することもできます。
- Private Peering: 仮想ネットワークとの接続 (Azure 上の Private IP 帯との接続)
- Microsoft Peering: Azure のパブリック サービス / O365 との接続 (Azure のパブリック IP 帯との接続)
https://jpaztech.github.io/blog/network/considerations-of-microsoft-peering/
※ 以前はこの他に Public Peering と呼ばれる種別もありましたが、現在は Microsoft Peering に統合されています。
https://jpaztech.github.io/blog/network/considerations-of-microsoft-peering/
⇧ とあり、
- オンプレミス環境
- Azure環境の各々のサービス
間の接続の場合は、「Microsoft Peering」という接続方式になるらしい。
用語を整理すると、次の通りです。
- Microsoft Enterprise Edge (MSEE): Azure 側のエッジ ルーター
- Privider Edge (PE): プロバイダー側のエッジ ルーター
- Customer Edge (CE): お客様拠点のエッジ ルーター
https://jpaztech.github.io/blog/network/considerations-of-microsoft-peering/
⇧ 上図のような接続が為されているようだ。
まとめると、「Azure」における「ピアリング」は、
| No | 接続方式 | 必須Azure リソース | 内容 |
|---|---|---|---|
| 1 | 仮想ネットワーク ピアリング | Azure VNet | 同じ Azure リージョン内の仮想ネットワークを接続します。 |
| 2 | グローバル仮想ネットワーク ピアリング | Azure VNet | Azure リージョン間で仮想ネットワークを接続します。 |
| 3 | Private Peering | Azure ExpressRoute | 仮想ネットワークとの接続 (Azure 上の Private IP 帯との接続) |
| 4 | Microsoft Peering | Azure ExpressRoute | Azure のパブリック サービス / O365 との接続 (Azure のパブリック IP 帯との接続) |
と言った分類になるようだ。
と言っても、「Microsoft」のドキュメントが相変わらず情報が散逸しているので、Google検索で上位表示されていないだけで、他にも情報があるのかもしれないのだが…
とは言え、情報が1ページに集約されていない時点で、ドキュメントとしては欠陥がある気がしてしまうのだが...
Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）同士の接続方式を整理してみる
で、詳細については、
⇧ 本職のインフラエンジニアの方がまとめてくださっていたのだが、「ピアリング」には、
- Hub virtual network
- Spoke virtual networks
という概念が関係してくるようだ。
公式のドキュメントによると、
⇧ 上図のようなネットワーク構成概要図の例があって、
- Hub virtual network
- Spoke virtual networks
という用語が出てきますと。
■Hub virtual network（ハブ仮想ネットワーク）
Hub virtual network - The hub virtual network hosts shared Azure services. Workloads hosted in the spoke virtual networks can use these services. The hub virtual network is the central point of connectivity for cross-premises networks. The hub contains your primary point of egress and provides a mechanism to connect one spoke to another in situations where cross virtual network traffic is needed.
https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke
ハブ仮想ネットワーク - ハブ仮想ネットワークは、共有 Azure サービスをホストします。 スポーク仮想ネットワークでホストされているワークロードでは、これらのサービスを使用できます。 ハブ仮想ネットワークは、クロスプレミス ネットワークへの接続の中心となるポイントです。 ハブには主要なエグレス ポイントが含まれており、仮想ネットワーク間トラフィックが必要な状況でスポークを別のスポークに接続するメカニズムを提供します。
https://learn.microsoft.com/ja-jp/azure/architecture/networking/architecture/hub-spoke
■Spoke virtual networks（スポーク仮想ネットワーク）
Spoke virtual networks - Spoke virtual networks isolate and manage workloads separately in each spoke. Each workload can include multiple tiers, with multiple subnets connected through Azure load balancers. Spokes can exist in different subscriptions and represent different environments, such as production and non-production. One workload could even spread across multiple spokes.
https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke
In most scenarios, a spoke should only be peered to a single hub network and that hub network should be in the same region as the spoke.
https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke
スポーク仮想ネットワーク - スポーク仮想ネットワークは、各スポークでワークロードを個別に分離および管理します。 各ワークロードには、Azure ロード バランサーを介して接続された複数のサブネットを持つ、複数の階層が含まれる場合があります。 スポークは、異なるサブスクリプションに存在し、運用環境や非運用など、さまざまな環境を表すことができます。 1 つのワークロードが複数のスポークに分散する可能性があります。
https://learn.microsoft.com/ja-jp/azure/architecture/networking/architecture/hub-spoke
ほとんどのシナリオでは、スポークは 1 つのハブ ネットワークにのみピアリングする必要があり、そのハブ ネットワークはスポークと同じリージョンに存在する必要があります。
https://learn.microsoft.com/ja-jp/azure/architecture/networking/architecture/hub-spoke
■Virtual network cross-connectivity（仮想ネットワーク間接続）
Virtual network cross-connectivity - Virtual network connectivity is the path in which one isolated virtual network can communicate with another through a control mechanism. The control mechanism enforces permissions and allowed direction of communications between networks. A hub will provide an option to support select cross-network connections to flow through the centralized network.
https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke
仮想ネットワーク間接続 - 仮想ネットワーク接続は、分離された仮想ネットワークが制御メカニズムを介して別の仮想ネットワークと通信できるパスです。 制御メカニズムは、ネットワーク間の通信のアクセス許可と許可された方向を強制します。 ハブには、一元化されたネットワークを流れるネットワーク間接続の選択をサポートするオプションが用意されています。
https://learn.microsoft.com/ja-jp/azure/architecture/networking/architecture/hub-spoke
⇧ 具体的な接続部分が「ブラックボックス」過ぎるのだが、
Azure Virtual Network は、Azure のプライベート ネットワークの基本的な構成要素です。 Virtual Network により、Azure VM などのさまざまな Azure リソースが、他の Azure リソース、クロスプレミス ネットワーク、インターネットと安全に通信することができます。
https://learn.microsoft.com/ja-jp/azure/architecture/networking/architecture/hub-spoke
このアーキテクチャでは、仮想ネットワーク間の非推移的で待機時間の短い 接続であるピアリング接続を 使用して、仮想ネットワークをハブに接続します。 ピアリングされた仮想ネットワークは、ルーターを必要とせずに Azure バックボーン経由でトラフィックを交換できます。 ハブスポーク アーキテクチャでは、仮想ネットワークを相互に直接ピアリングすることは最小限であり、特殊なシナリオ用に予約されています。
https://learn.microsoft.com/ja-jp/azure/architecture/networking/architecture/hub-spoke
⇧ とあり、「ピアリング」を確立する部分の説明が一切無い...
異なるネットワーク間の接続を確立する方法について、ChatGPT氏に質問してみたところ、以下のような回答が返ってきた。
■物理
🔌 物理ネットワーク間の接続に必要な機器
異なる物理ネットワーク（例：社内LANとインターネット、または本社と支社）を接続するには、以下のような機器が必要です。
■仮想
🧱 仮想ネットワーク間の接続に必要な機器・構成
仮想ネットワーク（VLAN、VPC、仮想マシンのネットワークなど）間を接続するには、ソフトウェアベースの機器やサービスを用います。
う～む、『物理』だろうが「仮想」だろうが、大元は何某かの機器によって「ネットワーク」の接続を確立しているとは思うんだが...
そうでないと、
- 通信元
- 通信先
が複数存在した場合に、各々に適切な通信がルーティングされないといったことが起こりそうだものね...
とりあえず、
- Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）同士の接続方式
が全量かと思っていたのだが、
⇧ 上記のように「Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）」同士の接続というわけでは無さそうなのだが、「Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）」間で通信する方法はあるようだ。
片方の「Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）」しか図に表れていないのだが、右側も何某かの「Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）」に属している気がするので...
「Micorosoft」のドキュメント、相変わらず整備されていなくて情報が散逸しているからして、「ファインダビリティ（Findability）」の欠片もないのが一向に改善されないのよな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
