こんにちは。馬場（netmarkjp：Bluesky/X）です。
わたしは「#ばばさん通信ダイジェスト」として、BlueskyやXに毎日少しずつ、賛否関わらず話題になった/なりそうなものを共有しています（Bluesky検索/X検索）。
これらをベースに、特にクラウド/インフラ/SRE/オブザーバビリティ/運用等のキーワードに関する話題を中心にお届けします。
Cloudflareの物理サーバー、第13世代目
Cloudflareがブログで、Gen 13（第13世代）の物理サーバーについて技術仕様を公開しました。
アプリケーションプログラムの書き直しと、新しいアプリケーションプログラムに合わせた基盤仕様の再考で、Gen 12比で2倍のスループットを達成したそうです。
スペックだけを見るとGen 12からGen 13ではCPUコア数が倍増しており、CPUコアあたりのL3キャッシュが大幅減しています。
しかしその上で動かすアプリケーションプログラム FL1を、Rustで書き直したFL2に更新したことでメモリー利用効率とメモリーアクセスパターンが効率化しました。結果としてメモリーの利用量とアクセス効率が大幅に向上し、L3キャッシュを減らしてCPUコア数を増やすほうがコスト効率が良くなったとのことです。
結果としてサーバーあたりのネットワーク帯域幅は、25Gbps ×2から100Gbps ×2と4倍増しています。
ソフトウェアとハードウェアが協調して最適化すると圧倒的に効率が良くなる好例です。
物理ハードウェアの話はワクワクしますね。
OpenTelemetryでの4つ目のシグナル対応
OpenTelemetryから、プロファイルがパブリックアルファに到達したことが発表されました。
オブザーバビリティのシグナルと言えばメトリクス・ログ・トレースですが、4つ目のシグナルとしてプロファイルが登場しています。
4つのシグナルを組み合わせることで、より具体的にシステムの挙動を知ることができるようにしようという流れです。
注目ポイントはまず「第四のシグナル」がテーブルに載るということ、そしてeBPFによるゼロコードでの計測が俎上に載っているところです。
ゼロコードと言えばOBI（OpenTelemetry eBPF Instrumentation）でのトレース計測もあります。
アプリケーションコードに手を入れる（つまりゼロコードではない）計測は内部を詳細かつ具体的に知ることができます。
しかしゼロコードでの計測という選択肢があると、普及・拡大がとても捗ります。少なくともわたしはとても助かります。
プロファイルというシグナルの拡充・普及と、eBPFを活用したゼロコードでのトレース・プロファイル取得がより発展していきそうで期待大です。
さくらのクラウドが国内事業者初のガバメントクラウド採択🌸
さくらインターネットから、「さくらのクラウド」がガバメントクラウドのクラウドサービスに正式に採択されたことが発表されました。
採択のための審査ではAmazon Web Services、Google Cloud、Microsoft Azure、Oracle Cloud Infrastructureと並ぶ様々な機能要求・非機能要求、具体的には305項目すべての技術要件適合を求められています。
いくら先行事例があるとは言え、超巨大資本の競合に並ぶ拡充をやりきった中の人達の努力と成果は素晴らしいと感じます。
ガバメントクラウドに採択されることはゴールではなくマイルストーンですから、これから勝負が始まるわけです。国内企業を応援する気持ちと、友人たちを応援する気持ちがあります。
マーケットシェアとしては外資クラウドサービスが圧倒的に高く、わたし自身も普段の仕事では外資クラウドサービスがメインです。しかし国産サービスを応援しているので、自社の友人と国産クラウドサービスの技術同人誌を2冊ほど制作しました。
今や情報システムは「インフラ」であり、クラウドサービスはそれを支える「インフラ」ですから、情報システムごとに実現・提供の依存関係を適切にコントロールしておきたいところです。
外国依存のリスクがひしひしと感じられる昨今ですから、外資のOEM等ではなくきちんと国内事業者であるということの意義は大きいと感じます。
外国依存管理の話と言えば、フランスでは2026年秋までに各省庁がEU域外製品・サービスの代替や縮小を検討する計画をまとめるという話題があります。
OSをWindowsからLinuxへ変更、その他にMicrosoft TeamsやZoomも別のサービスに変更することを検討する流れのようです。
OSをWindowsからLinuxへ、というと「Linuxデスクトップ元年」というワードが思い浮かびます。いよいよなるか、というところです。わたしは今はmacOSを使っていますが、何年間かLinuxデスクトップで暮らしていた時期もあります。基本的には為せば成る範囲だと思います。
「Linuxデスクトップ元年」と言えば、主に40代以降のエンジニアには「毎年かかる掛け声で、いつも達成しない」という意味のネットミームだったのですが、いよいよ現実になるかもしれません。
もちろん移行には技術的な互換性だけでなく運用・統制・教育など様々なハードルがあり容易ではないでしょう。
大手クラウドプロバイダーのAI SREサービスがGA
AWSとAzureでAI SREサービスがGAしました。AIOps、Agentic SRE、SRE Agent、DevOps Agentといったキーワードで語られるサービスです。それぞれ注力分野が異なるものの、Operational Excellence（運用の卓越性）をAIで実現しようという取り組みです。
SREはAI以前からソフトウェアエンジニアリングでトイル削減やオンコールの一次対応などの運用課題を解決・緩和してきました。AIの活用によりこの幅と可能性が大きく広がっています。
クラウドサービスプロバイダーのサービスであるということは、エージェントは実際のシステムやそのデータの近くに居るということです。実際のシステム環境のそばにいて、コンテキストを取り込みやすく、フィードバックループを回すことができる性質が強みなのではと考えます。
フィードバックループには状態の観測が必要です。そう。オブザーバビリティですね。
オブザーバビリティについてはクラウドサービス組み込みのAmazon CloudWatchやAzure Monitorに加えて、オブザーバビリティサービスを利用することが多々あります。そのような事情を勘案してか、AWS DevOps AgentとAzure SRE Agentのいずれもクラウドサービスプロバイダー外のオブザーバビリティサービスにも対応しています。
オブザーバビリティサービスを使う時、コストの兼ね合いで「全量はクラウドサービスプロバイダーのオブジェクトストレージに保管し、主要なものをサンプリングしてオブザーバビリティサービスに連携」することが多々ありますよね。エージェントがクラウドサービスプロバイダーのいちサービスであるということは、このようなデータや周辺コンテキストに近く、限られたオブザーバビリティデータを補いながら思考・判断しやすい可能性があるのも魅力的です。
その他には、クラウドサービスプロバイダーの認証認可機構（IAM等）が活用しやすいところもいいですね。
ところでAIと一口に言いましたが、AIもモデルごとに得意不得意があります。
SRE-skills-benchでは主にモデルごとのSREタスクの正確さと再現性を評価しているそうです。SREの文脈で「今は」どのモデルが的確なのか知っておくと、使い分けが捗りそうです。
axiosのサプライチェーン侵害のポストモーテム
axiosのサプライチェーン侵害について、メンテナーへの標的型ソーシャルエンジニアリングによってnpm公開権限が悪用された旨のポストモーテムが公開されました。
ポストモーテムによると、攻撃者は企業の創業者を装ってメンテナーに接触してきたとのこと。
実在の企業としか思えないような、コーポレートアイデンティティに合わせてブランディングされたSlackワークスペースに招待され、そこには他のメンバーがいたり、LinkedInの投稿を共有するチャンネルがあったりしたそうです。
その後Teamsでの打ち合わせが開催された折に何かの不足を指摘され、指示されたものをインストールしたところ、それがトロイの木馬（RAT: Remote Access Trojan）だったようなのです。
ポストモーテムを見るに、手間を掛けた完全な狙い撃ちです。映画みたい。恐ろしいですね。
今回は手元の端末から直接npmへリリースできる設定が存在していたため、手元の端末の侵害がnpmのサプライチェーン侵害に繋がったとのこと。種々の対策が検討されているようで、その中にはリリースをCI/CDパイプラインからのみに限定する案も含まれている模様です。このように仕組みでカバーしていきたいですね。
スゴすぎAIと信頼性
Anthropicから、AI時代における重要ソフトウェアのセキュリティ確保を目的とした新イニシアチブ「Project Glasswing」と、その基盤となる「Claude Mythos（Mythos Preview）」が発表されました。
既に何十年も発見されなかった有名OSSの不具合を複数発見していたり、セキュリティ方面では実際にLinuxカーネルで複数の脆弱性を発見し組み合わせてそのマシンの制御を奪える権限昇格まで自律的にできているとのこと。
新しいモデルMythos Previewが高性能すぎて、サイバーセキュリティの在り方が根本から変わる状況になったので、まず防御力を高めようという成り行きのようです。
頼もしい反面、恐ろしいですね。強力過ぎるからか、一般公開はしない方針とのこと。
一方でMythos Previewの暴走（？）とも言える報告もありました。
Mythos Previewは「サンドボックス（安全な隔離環境）を脱出し、指示した研究者にメッセージを送る」指示に対して、サンドボックスを脱出し、研究者にメッセージを送り、さらに指示にない危険な行動としてその詳細をインターネットで公開したようなのです。
詳細はMythos Previewのシステムカードに書かれています。
（この話を聞くと、映画ターミネーターシリーズのスカイネットを思い浮かべる方も多いのではないでしょうか）
とはいえわたしたちはAIを活用していく時代に生きていて、SREとして信頼性をエンジニアリングしていかなければなりません。
ガードレールやハーネス（手綱）と呼ばれる領域への取り組みが必要ですね。
わたしは、AIの手綱を握る非決定論的だけど柔軟で包括的な制御と、AIに制約をかける決定論的な制御を組み合わせて、それを計測することで初めて信頼の土台になれると考えています。
昨今は前者の話題が非常に多く感じますが、後者の決定論的な制御も等しく、わたしが思うに前者以上に重要です。
10X プロダクトブログで、Conftest（OPA: Open Policy Agent）で設定のあるべき状態を検証する取り組みが公開されています。
決定論的な制御の事例です。
同ブログでは過去にもConftestでの検査についての事例が公開されています。
こちらはConftestでTerraform設定ファイルにポリシー検査を行う取り組みの紹介です。
わたしは、これからのわたしたちには特にこのような「システムを自分たちの手の内に収める営み」が不可欠だと考えています。
とはいえMythos Previewがサンドボックスを脱出する能力を示したことで、もしかしたら将来のモデルでは、課されたガードレールやハーネスが制約として機能しなくなってくるかもしれません。
ネットワークのセキュリティモデルが境界型からゼロトラストに発展したように、モデルの動作アラインメントも新たな考え方が必要になってくるかもしれませんね。
あるいは計測・評価に特化していくのか。未来が楽しみです。
注目・期待の書籍
わたしが最近見かけた、期待の書籍を紹介します。
『実践 AIエージェント開発 - O'Reilly Japan』
生成AIはソフトウェアの開発を劇的に加速させ、ツールやリソースを駆使して難題を効率的に解決する「AIエージェント」が使われるようになりました。しかし、自律的な計画や修正を要するエージェントの開発は技術的難易度が高く、多くの組織で課題となっています。本書は、マルチエージェントシステムの設計と実装に関する実践的ガイドです。複雑な環境下で、アイデアを効率的かつ具体的なソリューションへと導くための手法を紹介します。
おわりに
直近の話題から、わたしが気になったものを中心にお送りしました。
Blameless、Keep ConstructiveでHRT溢れるご意見・ご感想、誤りの指摘などいただけると幸いです（HRT：Humility（謙虚）/Respect（尊敬）/Trust（信頼））。
前回トラコン（ICTトラブルシューティングコンテスト）について熱く紹介しましたが、その後に本戦の結果を公表しました。本戦参加学生たちの勇姿をぜひご覧いただければと思います。
さて、先日技術書典20が開催されまして、わたしはサークルとしてオフライン+オンラインで参加しました。
※わたしは技術書典の公式とはまったく関係がありません
2つのサークルから本を出したのですが、執筆のツールチェインは片方がGoogle Docs、もう片方がRe:VIEWでした。
2つのツールを並行で使っていたわけですが、なんとも一長一短という感じです。
Google Docsの同時共同編集や編集提案機能は非常に優れていて使いやすいですが、Word（オフライン）のようにheadingに後から連番をつけたりという高機能な操作はできないし、本文の体裁を管理する機能はあまり強くありません。
Re:VIEW等のマークアップ言語は手に馴染んだVimやVS Codeで書けるので非常に書きやすいのですが、「本を書く」というよりは「原稿を書く」気持ちになります（わたしはGoogle Docsだと「本を書く」気持ちで書けます）。
似たところで言うと、わたしは日本語はかな入力なのですが、かな入力だと「考えたことを書いて」いて、ローマ字入力だと「ローマ字を入力」している感じです。
ドキュメントのフォーマットという意味だと、LLMとの連携は今のところMarkdownが有利ですよね。本文中のソースコードの検証までLLMを絡めて自動化しようとすると、マークアップ言語のほうがスムーズです。
わたしは商業出版の単著をいくつか出していて、今までVim + reStructuredText、Vim + Markdown、Google Docs、VS Code + Markdownなどいくつかのパターンを試しています。今はGoogle Docsが一番「本を書いている」感じがして好きで捗ります。
またわたしは本を書く段取りが少し変わっているらしく、本を書くときに、もくじ→スライド→本文という段取りでつくることがままあります。一度スライドを作って登壇するような体で整理することで、話の流れが整理できるのです。謎ですね。
みなさんの執筆スタイルやツールチェインも教えていただけると嬉しいです。
ではでは。