2026年03月08日の技術動向

クラウドVM性能/価格比較 2026 — AMD EPYC Turin（Zen 5）が他CPUを明確に引き離す

7プロバイダー・44VMタイプという過去最大規模のベンチマークで、AMD EPYC Turin（Zen 5世代）が性能/価格比において他CPUを明確な差で上回った。

このベンチマークは2025年10月から開始され、2026年1月時点の価格を基準にしている。対象はAWS・GCP・Azureを含む7プロバイダーで、x86（Intel・AMD）とARM系を含む44VMタイプを2vCPU構成で比較した。比較の統一条件は「2GB/vCPU・30GB SSD」だ。

今回新たにテストされたCPUは5種類ある。AMD EPYC Turin（Zen 5）、Intel Granite Rapids、Google Axion（ARM）、Azure Cobalt 100（ARM）、Ampere AmpereOne M（ARM）だ。

AWSのC8aインスタンスで動くEPYC TurinはSMTが無効化されており、2vCPUで物理コア1つをフルに使える。SMT有効のIntel・AMD系インスタンスでは2vCPU＝1コア2スレッドになるため、シングルスレッド性能が重要なワークロードでは構成の違いが結果に直結する。

【補足】SMT（Simultaneous Multi-Threading）とは、1つの物理コアで2つのスレッドを同時実行する技術（IntelではHyper-Threading）。コアのリソースを共有するため、スレッドあたりの実効性能は物理コア専有時より低下する。C8aのSMT無効構成は「2vCPU＝物理コア1つ独占」を意味し、整数演算やレイテンシ重視のベンチマークで有利に働く。

方法論上の変更点が2つある。GCPの「100%継続利用割引」を今回は除外した。長期契約前提の価格であり、他プロバイダーのオンデマンド価格との直接比較を歪めると判断されたためだ。また、同一インスタンスタイプでもリージョンによってパフォーマンスが異なるケースが大手3社でも確認されたため、AWS・GCP・Azureについてもリージョン間の性能範囲をレンジとして記録するよう変更した。

旧世代CPUを避けるべき理由は単なる性能差ではない。旧世代は電力効率が低いためプロバイダーの運用コストが高くなり、「性能が低いのに価格は高い」という逆転現象が起きる。コスト最適化の観点では、CPU世代の選択が最初の判断基準になる。

ARM系インスタンスの多様化も進んでいる。Google Axion、Azure Cobalt 100、Ampere AmpereOne Mがそれぞれ独自設計で登場しており、AWSがGraviton系で先行した動きを他プロバイダーが独自シリコンで追いかける構図が鮮明になった。

IANA tzdb — ブリティッシュコロンビア州の恒久サマータイム移行がコミットとして記録される

タイムゾーンデータベース（IANA tzdb）は世界中のソフトウェアが依存するインフラだ。ブリティッシュコロンビア州が恒久的なサマータイムへの移行を決定したことで、このデータベースの実態が改めて注目された。

この政策変更はGitHub上のeggert/tzリポジトリへのコミットとして反映されており、NEWSファイルで確認できる。tzdbがGitHubで管理されるようになったことで、変更の追跡が以前より格段に容易になった。以前はメーリングリストとtarballの配布のみだったため、変更の追跡には手間がかかった。

tzdbの北米ファイル（northamerica）には、タイムゾーン定義データだけでなく政治的決定の経緯が詳細に記録されている。1947年のサマータイム批判の引用から第二次世界大戦中のイギリスの「ダブルサマータイム」まで、人間の社会的決定がそのまま技術仕様として固定されてきた歴史が読める。

タイムゾーンが「難しい」とされる理由は技術的複雑さだけではない。政治的決定、戦時立法、地域の慣習、宗教的慣行、鉄道の標準化運動など、人間の社会的決定の積み重ねがそのまま技術的仕様として固定されている。tzdbのコメントはその経緯を記録する一次資料としての役割も担っている。

tzdbはArthur David Olsonが1986年頃に始め、現在はIANAが管理している。LinuxのほぼすべてのディストリビューションやmacOS、各種プログラミング言語のランタイムがこのデータベースに依存している。2011年にはOlsonが引退を表明し、一時的に配布が停止する騒動もあった。

ブリティッシュコロンビア州のような恒久的サマータイムへの移行は北米各地で議論が続いている。アメリカでも「Sunshine Protection Act」が繰り返し提出されており、可決されれば大規模なtzdb更新が必要になる。

NanoClaw — AIエージェントをDockerコンテナに隔離してOpenClawのセキュリティ問題に対処

各AIエージェントを独立したDockerコンテナに閉じ込めるNanoClawが登場した。OpenClawが抱えるエージェント間のセキュリティ境界の欠如という問題への実装レベルの回答だ。

NanoClawでは、エージェントループは他のエージェントの存在を知らない状態で始まり、明示的に教えたリソースだけにアクセスできる。あるエージェントが侵害されても横展開が起きない構造になる。

OpenClawとの本質的な違いは構成方法にある。OpenClawが大きな設定ファイルとモノリスで動くのに対し、NanoClawは必要なコードと適切なClaudeスキルだけで構成される。Claudeがエージェントのコードを外部から編集・修正する設計で、コードベースを小さく保てる。「コードが安価になった今、この設計は理にかなっている」という評価は、LLMによるコード生成コストの低下が設計思想を変えつつある現状を示している。

実際のセットアップでは、Claudeがコンテナとホストのフォルダマッピングを自己修正する場面があった。著者がログを転送すると、Claudeはエラーを解析してマッピングを修正し、コンテナを再起動した。Claudeが「エージェント」を自分とは別の存在として扱い、コンテナ内部の状態を外部から操作する構造を自然に維持した点が注目される。

WhatsApp連携にはBaileys経由でWhatsApp WebのWebSocketデータを読み取る方式が使われているが、Metaが明示的に禁止しており、アカウントが監視・制限対象になる。

【警告】Baileysを使ったWhatsApp自動化はMeta利用規約違反であり、アカウントの一時停止・永久BAN・法的措置のリスクがある。本番環境や重要なアカウントへの適用は推奨されない。著者がSlack連携を選択した理由もここにある。著者はSlack連携を選択した。Slack APIでのトークン取得はSocket Modeの有効化、ボットイベントの購読、OAuthスコープの設定と手順が多く、経験者向けの作業量だ。

マルチエージェントシステムの普及に伴い、エージェント間の信頼境界をどう設計するかが2024〜2025年の主要な課題になっている。OpenClawのような初期実装では、エージェントが同一プロセス空間やネットワーク上で動作し、一つのエージェントへのプロンプトインジェクション攻撃が他のエージェントに波及するリスクがある。

Claudeが自分自身のコードとインフラ設定を修正するパターンが定着すると、「エージェントのデバッグはエージェントにやらせる」という運用モデルが広がる。ただし、ログの転送や問題の切り分けは依然として人間の判断が必要で、完全自律には至っていない。

OSSとAI — AI生成スロップがメンテナーに集積し、cURLは8時間で16件の無効報告を受けた

AIがOSSのメンテナーを静かに疲弊させている。表面上は「コントリビューションが増えた」ように見えるが、中身はAI生成のスロップで、その後始末をメンテナーが一人で抱えている。

【補足】「スロップ（slop）」：AIが生成した、表面上は体裁が整っているが内容が不正確・無意味・検証されていないコンテンツを指す俗語。コードレビューやバグ報告の文脈では、AIが自動生成した根拠の薄い報告や、コピーペーストされた未検証のパッチを指すことが多い。

Linux Foundation Members SummitでAWS Head of Open Source StrategyのStormy Petersが警鐘を鳴らした。AIはOSSを「殺す」わけではないが、プロジェクトが数十年依拠してきた社会的・経済的な前提を急速に崩している、という指摘だ。

Peters自身が当初懸念していたのは「AIで3秒生成できるコードをわざわざupstreamに送る人がいなくなる」という貢献意欲の低下だった。実際に起きたのは逆だった。開発者たちはAI生成コードを躊躇なく送りつけてくる。問題は、送った本人がそのコードを理解していないことだ。「誰かに説明しろと言われても、簡略化しろと言われても、自分にはできない。プロジェクトのメンテナーにとっても、何が起きているか把握しにくい」とPetersは述べた。

cURLの事例がこの構造を端的に示している。cURLは60億台以上のデバイスに搭載されており、セキュリティバウンティプログラムで6年間に約9万ドルを支払い、80件超の脆弱性を修正してきた。AIアシスト型のバウンティハンティングが登場した途端、8時間で16件の報告が届いた。有効なものはゼロだった。cURLの作者Daniel Stenbergはすでに公開の場でAIスロップによるセキュリティ業務の混乱を訴えている。

生産性への影響も想定とは逆方向だ。Petersが引用した研究では、AI活用で生産性向上が期待されたにもかかわらず、経験豊富なエンジニア（＝メンテナー層）は19%遅くなった。「ほぼ完成しているコードを何度も見直し、微調整する時間」がボトルネックになる。AI生成コードは通常の1.7倍の問題を含む傾向があるという数値も示された。

構造的に何が起きているかはこうだ。「コードを書く・問題を解く」という楽しい部分は、知識が浅くてもAIで素早くこなせる人に移った。「直す・整合させる・維持する」という報われにくい部分だけがメンテナーに集積している。

ガバナンス側の対応は始まっている。Gentoo Linux、NetBSD、QEMUはAI利用を全面禁止した。Fedora Linuxは責任ある利用を条件に受け入れる立場を取る。

【補足】各プロジェクトの方針の背景：GentooとNetBSDはライセンス上の懸念（AI学習データの著作権問題）も禁止理由の一つとして挙げている。QEMUはコードレビュー負荷の増大を主因とする。Fedoraの「責任ある利用」方針は、生成物の著作権帰属と品質保証を貢献者が担保することを条件としている。ただしPetersは「禁止しても、ほとんどの人はAIを使ったと開示しない」と指摘する。ルールの執行が技術的に困難なため、禁止令は形骸化しやすい。

OSSプロジェクトのメンテナー不足はAIが登場する以前から深刻だった。Log4Shell（2021年）やxz utils事件（2024年）は、少人数のボランティアが世界規模のインフラを支えている現実を露わにした。

【補足】xz utils事件（2024年）：圧縮ライブラリxzのメンテナーが長期にわたるソーシャルエンジニアリングによって悪意ある貢献者に乗っ取られ、SSHデーモンにバックドアが仕込まれかけた事件。単独メンテナーが燃え尽き症候群に陥った隙を突かれた点で、メンテナー不足の脆弱性を象徴するケースとして広く引用される。そこにAI生成コードの大量流入が重なった。コントリビューターの「量」は増えたように見えるが、メンテナーの「負荷」は非線形に増加している。

GitHubのCopilotやCursorが普及したことで、コードを書くコストは急激に下がった。一方でコードをレビューし、長期的に維持するコストは下がっていない。この非対称性がメンテナー層への集中を生んでいる。

今日の傾向

AWSのC8aインスタンス（EPYC Turin搭載）が44VMタイプ中で性能/価格比トップに立ち、Google AxionとAzure Cobalt 100がARM系として追う構図が2026年のクラウドVM市場の現状だ。x86一強だった時代の終わりが数値として可視化された。

NanoClawがOpenClawのセキュリティ問題に対してDockerコンテナ隔離で応答し、Claudeがコンテナのフォルダマッピングを自己修正するワークフローが実用段階に入った。「エージェントのデバッグはエージェントにやらせる」運用モデルが具体的な実装として登場した日だ。

Stormy PetersがLinux Foundation Members Summitでcurl（60億台搭載・6年間9万ドルのバウンティ実績）を引用しながらAIスロップ問題を提起し、Gentoo Linux・NetBSD・QEMUが禁止、Fedora Linuxが条件付き容認という対応の分岐が明確になった。メンテナー層が19%遅くなるという数値と、AI生成コードが通常の1.7倍の問題を含むという数値が、OSSガバナンス議論の具体的な根拠として流通し始めた。

ブリティッシュコロンビア州の恒久サマータイム移行がeggert/tzリポジトリへのコミットとして記録された。Sunshine Protection Actが可決されれば同様の大規模更新が必要になる。IANAが管理するtzdbへの依存がLinux全ディストリビューション・macOS・各言語ランタイムに及ぶ以上、北米の政治的決定が世界中のシステムに直接波及する構造は変わっていない。

参照記事

記録日: 2026-03-08