ピート・ヘグゼス米国防長官は2月27日（現地時間）、公式Xアカウントで米国防総省（Department of War、以下「DoW」）に対し、米Anthropicを「サプライチェーンリスク」に指定するよう指示したと発表した。これを受けAnthropicは同日、声明を発表し、この措置は法的に不当であり、政府と交渉するあらゆる米国企業にとって危険な前例になるとして、法廷で争う姿勢を明らかにした。
事の発端は、DoWがAI企業に対して安全対策（セーフガード）を撤廃し、軍によるAIの「あらゆる合法的な利用」に同意するよう求めたことにある。Anthropicはこれまで軍への技術提供に協力的だったものの、「米国民の大規模な国内監視」および人間の判断を完全に排除した「完全自律型兵器」へのAI利用の2点については、民主主義の価値観に反し重大な危険をもたらすとして、例外とするよう求めていた。
一方、Anthropic競合の米OpenAIは同日、自社のAIモデルをDoWの機密ネットワークに導入する契約に合意したと発表した。OpenAIもAnthropicと同様に監視や自律型兵器への利用をレッドラインとしていたが、モデルの提供をクラウド環境に限定し、自社の安全対策を維持し続けるという保護を設けることで、DoWとの対立を回避した。
OpenAIのサム・アルトマンCEOはこの合意に際し、DoWに対して「他社にも同じ条件を提示するよう求めている」とした上で、「Anthropicはサプライチェーンリスクに指定されるべきではない」と政府に伝えたとし、法的措置の取り下げと合理的な合意への沈静化を促している。
⇧ う～む...
「軍事利用」に「制約」を設けないのは危険過ぎるのだが...
そもそも、「クラウドサービスプロバイダー」的な「サービス」提供に限定するとして、「責任共有モデル」的に、
- クラウドサービスプロバイダー側の責任範囲
- 利用者側の責任範囲
を明確にしておかないと、「政府組織」による不当な「介入」が多発する「リスク」が増える気がしますが...
まさに、
『1984年』（1984ねん、原題: Nineteen Eighty-Four）または『1984』は、1949年に刊行したイギリスの作家ジョージ・オーウェルのディストピアSF小説。全体主義国家によって分割統治された近未来世界の恐怖を描いている。特に欧米での評価が高く、思想・文学・音楽など様々な分野に今なお多大な影響を与えている近代文学傑作品の一つである。
出版当初から冷戦下の英米で爆発的に売れ、同じくオーウェルが著した『動物農場』やケストラーの『真昼の暗黒』などとともに反全体主義、反共産主義、反集産主義のバイブルとなった。また資本主義国における政府の監視、検閲、権威主義を批判する文脈でも本作がよく引用される。
⇧ 上記のような世界線が訪れる危険がありますと。
昨今は、「カウンターカルチャー」が「機能」しなくなっているのかしら...
カウンターカルチャー（英: counterculture）、対抗文化（たいこうぶんか）とはサブカルチャー（下位文化）の一部であり、その価値観や行動規範が主流社会の文化（メインカルチャー/ハイカルチャー）とは大きく異なり、しばしば主流の文化的慣習に反する文化のこと。
カウンターカルチャーは、メインカルチャーに取って代わる可能性を内包している（英語版：オルタナティブ・カルチャー）。ベトナム反戦運動や性革命は、代表的なカウンターカルチャーだった。カウンターカルチャー運動は若者文化を創造し、1960年後半から1970年代前半に西側諸国で劇的な社会変革を引き起こした。
カウンター・カルチャーと若者の反乱はアメリカだけでなく、イギリスの「スウィンギング・ロンドン」、フランスの「パリ五月革命」、日本の学園紛争など、世界のかなりの国々に拡大していった。
⇧ まぁ、世界的に「先進国」では「少子高齢化」が加速してるらしいので、仮に「カウンターカルチャー」の「運動」が起こったとしても、「若者文化」に発展していかないのかね...
まぁ、他国である「アメリカ」の話なので、「日本」には関係のないことなのかもしれないですが、「自由の国アメリカ」は死につつあるのですかね...
Diagramsでシステム構成概要図を出力できるようだがCIDRとか表現する例が無い...
今更ながら、
⇧ 上記の「Diagrams」という「ライブラリ」の存在を知ったので、試してみようと思ったのですが、「CIDR（Classless Inter-Domain Routing）」とか表現する例が無かったので、「ChatGPT」氏と壁打ちしながら試してみました。
とりあえず、「Diagrams」という「ライブラリ」は、「DaC（Diagram as Code）」という「技術領域」に分類される「ライブラリ」という立ち位置になる模様。
ちなみに、業務では、「Microsoft Azure」をメインに利用しているのですが、
⇧ 上記が「Diagrams」という「ライブラリ」でサポートしている「Microsoft Azure」の「サービス」ということになるみたい。
で、「環境構築」する気力が無かったので、「Google Colaboratory（Colab）」を利用して、「Diagrams」を試してみることにしました。
まずは、「Google Colaboratory（Colab）」を起動して、「+コード」を追加して、必要な
- Linuxのパッケージ
- Google Colaboratory（Colab）は、LinuxディストリビューションがUbuntu
- Pythonのモジュール
をインストールします。
※ Google Colaboratory（Colab）環境でパッケージのインストールする場合は、コマンドの先頭に「!（エクスクラメーションマーク）」を付ける
!sudo apt clean !sudo rm -rf /var/lib/apt/lists/* !sudo apt update
!sudo apt install python3-venv python3-pip graphviz
!pip install diagrams
DiagramsでAzureのリソースで構成されたシステム構成概要図をPNG出力するサンプル
from diagrams import Diagram, Cluster, Edge
from diagrams.azure.network import (
ApplicationGateway,
LoadBalancers,
PublicIpAddresses,
VirtualNetworks,
Subnets,
NetworkInterfaces,
)
from diagrams.azure.compute import VM
from diagrams.azure.databases import AzureDatabasePostgresqlServer
from IPython.display import Image
with Diagram("Azure Network", filename="azure_network_full", show=False):
# VNet
with Cluster("VNet 10.0.0.0/16"):
vnet = VirtualNetworks("vnet-prod")
# Subnet 1: Web系（App Gateway + LB）
with Cluster("Subnet 10.0.1.0/24"):
appgw = ApplicationGateway("app-gateway")
lb = LoadBalancers("load-balancer")
# Subnet 2: Appサーバー
with Cluster("Subnet 10.0.2.0/24"):
nic1 = NetworkInterfaces("nic-app01\n10.0.2.4")
vm1 = VM("app01")
nic1 >> vm1
nic2 = NetworkInterfaces("nic-app02\n10.0.2.5")
vm2 = VM("app02")
nic2 >> vm2
# Subnet 3: DBサーバー（PostgreSQL を公式ノードで表示）
with Cluster("Subnet 10.0.3.0/24"):
pg = AzureDatabasePostgresqlServer("postgres-db\n10.0.3.10")
# Public IP ノード
public_ip_appgw = PublicIpAddresses("20.1.1.10")
public_ip_lb = PublicIpAddresses("20.1.1.11")
# 接続
public_ip_appgw >> Edge(label="Public IP") >> appgw
appgw >> Edge(label="To LB") >> lb
lb >> Edge(label="To App VMs") >> nic1
lb >> Edge(label="To App VMs") >> nic2
vm1 >> Edge(label="DB Conn") >> pg
vm2 >> Edge(label="DB Conn") >> pg
# Jupyter 上で表示
Image("azure_network_full.png")
⇧ と言った感じで、頑張れば、「CIDR（Classless Inter-Domain Routing）」とかも表現できるみたい。
ちなみに、「draw.io」などの「ツール」で利用できる形での「出力」できないか、「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
🔹 実務でおすすめの方法
- 見た目重視なら SVG/PDF 出力 → draw.io に貼り付け
- 編集可能な構造を残したいなら Mermaid 経由で draw.io に変換
- Diagrams のノード・接続情報を JSON 化して XML を生成 するのが最も自由度高いが手間
⇧ 上記にある通りだとすると、「2. 編集可能な構造を残したいなら Mermaid 経由で draw.io に変換」が現実的なのかな...
いずれにしろ、「煩雑」になる模様...
もう1つ、『Diagramsのソースコードの形にリバースエンジニアリングできないか』「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
整理すると、やりたいことはこうですね：
既存の Azure リソース情報（ARM テンプレートや Terraform ファイル）をもとに、Diagrams の Python スクリプトを自動生成してネットワーク図を描きたい
結論として、Diagrams 自体にはそのような自動変換機能はありません。ただし、実現は可能で、いくつかの方法があります。
1️⃣ ARM / Terraform → Diagrams Python コード生成の考え方
- ARM / Terraform を解析
- JSON（ARM）や HCL（Terraform）を Python でパース
- 例: Azure VNet, Subnet, NIC, VM, LB, Application Gateway, Public IP などのリソースを抽出
- リソース間の関係を構造化
- サブネットごとにクラスタ化
- VM → NIC → Subnet の接続
- LB → VM など通信経路も抽出できれば Edge を自動生成
- Diagrams 用 Python を生成
- 文字列テンプレートや jinja2 を使って Python コードを生成
2️⃣ 既存の OSS / ツール
現状、Diagrams 公式や既存 OSS で ARM/Terraform → Diagrams Python 自動生成はありません。 つまり「自作する必要があります」。
- 参考にできるのは Terraform → DOT（Graphviz）変換ツールなど
- そこから Diagrams に変換するスクリプトを自作する感じです
🔹 まとめ
- Diagrams には ARM/Terraform → Python 変換機能はない
- ただし 自作可能：
- Terraform/ARM → JSON/HCL → Python で解析
- リソース・接続情報を抽出
- jinja2 などで Diagrams Python コードを生成
- 生成すれば、自動で Azure ネットワーク図を描ける
流石に、「OSS（Open Source Software）」で、良しなに対応できるわけでは無いですな...
- ARM（Azure Resource Manager）テンプレート
- Terraform テンプレート
- Diagrams ソースコード
などの相互変換に対応していてくれれば文句なしだったのですが、「OSS（Open Source Software）」にそこまで求めるのは酷というものですかね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
