こんにちは。馬場（netmarkjp：Bluesky/X）です。
わたしは「#ばばさん通信ダイジェスト」として、BlueskyやThreadsに毎日少しずつ、賛否関わらず話題になった/なりそうなものを共有しています（Bluesky検索）。
これらをベースに、特にクラウド/インフラ/SRE/オブザーバビリティ/運用等のキーワードに関する話題を中心にお届けします。
distrolessの「らしい」を「確かに」にする好奇心とプロフェッショナリズム
distrolessコンテナイメージを「なんか軽くてセキュアらしい」で終わらせず、中身と実用上の意味を具体的に確認したエントリーです。
scratchだと何が困るのか、distroless/staticだと何が足りていて何が足りないのか、コンテナの中身を展開して探索しています。
素晴らしい好奇心だし、素晴らしいプロフェッショナリズムだと感じます。自分自身が納得するというのもあるけれど、プロフェッショナルとして説明責任を果たせるようになるという意味で、とても価値のある姿勢です。
堅いことを言いましたが、エラーは仕組みと制約を知るためのヒントですから、このように探索していくのは純粋に楽しいものでもあります。「わかる」「できるようになる」は楽しいし面白いですよね。
アプリケーションプログラムが動作するためには、アプリケーションプログラム本体とカーネルの他にも色々なものが必要です。dnf / yum / aptなどのパッケージマネージャーでインストールするような、システムライブラリーやCA証明書、tzdata等は普段あまり意識しませんが、「ないとどうなる」が実際に試せるのは貴重な経験です。
マイクロな環境から、実行時に必要なものだけへ絞り込んだ構成を目指す。そんな「何もないところから厳選して足していく」感覚を体験する切っ掛けになるでしょう。
さらっと「コンテナの中身を展開して」と書きましたが、実はdocker exportするとコンテナのファイルシステムをtarアーカイブで取り出せるので、tarコマンドで展開して中身を確認できるのですよね（ただしボリュームはtarアーカイブに含まれません）。これは仕組みと中身を知ろうとしないと遭遇しない知識なので、知らない方も多いかもしれません。Microsoft Officeのファイル（.docxや.xlsx）が実はZIPアーカイブだというのを、知っている人は知っている、というのと似た感覚があります。
Kubernetesの「わかった」レベルを上げる好奇心とプロフェッショナリズム
Kubernetesを学び始めた著者が、著者曰く「AIの指示通りにただコマンド打つマン」の状態から脱却するために、Podが起動するまでの仕組みを実験で追ったエントリーです。
ローカルの検証環境で、Podをどのノードに割り当てるかを決めるSchedulerを止めてみて、予想通りの挙動になるか確認する、という検証まで踏み込んでいます。
仕組みを知る → ハッピーパスで確認する → 意図通りにカスタマイズできるか検証する、という段取りで仮説検証を重ねており、とても丁寧なアプローチです。
前のエントリーと同様、素晴らしい好奇心だし、「わかる」「できるようになる」は楽しいし面白いものです。それに素晴らしいプロフェッショナリズムだと感じます。自分自身が納得するという意味もありますが、プロフェッショナルとして「なぜそうなるか」を説明できるようになるという意味でも、こういう姿勢はとても価値があります。
どんなジャンルでも、意図通りの挙動を引き出せるようになり、カスタマイズの影響が予測できるようになると、ひとやま越えた感じがしますよね。これは情報処理技術に限った話ではなく、スポーツでの体の動かし方なんかでも同じだと思います。
分散システムのリアルに迫る好奇心とプロフェッショナリズム
実験を通じて、分散システムでよく言われる『ノードが完全に死ぬよりも、中途半端に死んでいるほうが厄介』を、実際に手を動かして実験し、検証したエントリーです。
この実験では、3台構成のクラスターのうち1台で、50%のパケットロスを意図的に発生させています。エントリー内ではこのノードを『ゾンビノード』と呼んでいます。
さて、3台中1台で50%のパケットロスが発生したとき、クラスター全体の応答性能はどうなるでしょうか？ぜひ自分なりに予想を立ててから読んでみてください。可能であれば手元で実験してみると、理解がさらに深まると思います。
こうして実験してみる姿勢は、素直に素晴らしいと感じます。実験してみるというのは、自分が納得するためというのもありますが、「なぜそうなるのか」を説明できるようになることは、プロフェッショナルとしての説明責任を果たすうえでとても重要です。
繰り返しになりますが、ここまでのエントリーと同様に、素晴らしい好奇心とプロフェッショナリズムを感じます。
実務的な観点でも、このテーマは現代のシステム運用に関わるわたしたちには他人事ではありません。どれだけチューニングしてもスループットが上がらないと頭を抱えていたら、実はパケットロスが原因だった、ということは現実に起こりえます。「ネットワークは正常なはず」という思い込み、あるいは「ネットワークは正常なものとして考える」という暗黙に置きがちな前提を疑う価値を示してくれるエントリーです。
Ubuntuの最新LTSがリリース
Ubuntu 26.04 LTS（コードネーム Resolute Raccoon）がリリースされました。LTSは標準で5年サポートなので、2031年4月まで安心して使い続けられます。
これまでのサイクルを考えると、実際にアップグレードを進めるのは自動アップグレードが提供される26.04.1が出てからという方も多いのではないでしょうか。
わたしの個人的な注目ポイントをいくつか挙げると、まずGNOME 50です。コードネームはなんとTokyoです。
次にRust製コアコンポーネントrust-coreutilsの採用です。Rustに全面移行とはいかないようですが、Rust普及の波が感じられます。
そしてTPMを活用したディスク暗号化（FDE: Full Disk Encryption）まわりの整備です。日常使いするときにどうしても不便だった点が改善されそうで嬉しいです。
リリースノートや公式アナウンスに加えて、Ubuntu Japanese Teamのメンバーである、あわしろいくやさんによる解説記事も公開されています。
こういった形で日本語で丁寧に情報発信してくださる方がいるのは、本当にありがたいですし、素直にうれしいですね。
サプライチェーンセキュリティ対策の実践
昨年から猛威を振るっており、直近で特に大きなニュースになっている、サプライチェーン攻撃の対策を「6つの原則」でとりまとめた実践的なエントリーです。
1.『install時任意コード実行を止める』（インストール時の自動実行スクリプトの無効化等）
2.『リリース後の猶予を置く』（cooldown / minimum release age等）
3.『lockfileで完全性を担保する』（バージョン厳格指定、ハッシュ・チェックサム検証、lockfile改ざん防止等）
4.『信頼シグナル(署名・Provenance)を検証する』（デジタル署名検証等）
5.『権限とネットワークを最小化する』（ビルド環境隔離、密封ビルド等）
6.『事後に即応できる状態を保つ』（インシデントレスポンス体制等）
この6つを軸に、npm（JavaScript / TypeScript）、PyPI（Python）、RubyGems（Ruby）、Maven（Java）、Go modules（Go）、Cargo（Rust）等を横断で、実際のコマンドベースで紹介しています。
わたしの観測範囲では3以降が見落とされがち、話題として小さめだと感じていて、対策として気づかれていない・後回しにされやすい印象があります。
またこの話題はnpmが取り上げられることが多いように感じますが、実際にはそれぞれのプログラミング言語のそれぞれのエコシステムで対処しなければならない内容です。
ツールキットやエコシステムによって1〜6の実現可否・実現方法・実現精度が異なってきますから、このように並べて確認できるのはとても助かりますね。
このエントリーは複数のプログラミング言語のエコシステムを横断して、実際のコマンドベースで確認できる点が特に素晴らしいです。特に幅広い言語スタックを扱うことが多いSREにとって重要なエントリーだと感じます。
OpenTelemetryの日本のコミュニティサーベイの結果が公開されました
OpenTelemetryの日本のコミュニティサーベイの結果が公開されました。回答者の60%強が本番運用中、さらに25%強が評価中・テスト中というかなり前のめりな結果でした。このサーベイはコミュニティ経由で実施されたものですから、OpenTelemetryやオブザーバビリティ、クラウドネイティブ技術等に一定以上のアンテナを張っている方を対象とした調査となっています。ICT業界全体の動向を把握するための調査ではない点にご留意ください。
計測対象のテレメトリーシグナルはトレースが93%と最多で、メトリクス71%、ログ60%、プロファイル13%と続きます。
メトリクスやログは従前から選択肢が豊富にあるため、わたしの実感としてもOpenTelemetryが視野に入るきっかけはトレース取得に踏み込む場面が多いです。わたしが知る限り「新たな取り組みとしてトレースを計測・収集することになり、まずトレースだけをOpenTelemetryで扱う」という流れはよくあるパターンで、この結果には素直に納得感があります。
利用しているコレクターはContribコレクターが59%と最多で、Coreコレクターが27%、OCB（OpenTelemetry Collector Builder）を利用したカスタムディストリビューションが同じく27%、そしてADOT（AWS Distro for OpenTelemetry）が7%と続きます。
わたし自身がコレクターを選ぶ時は、利用するエコシステムやプラットフォームに合わせてADOT / Grafana Alloy / Contribコレクターを使い分けることが多いので、こうした結果になるのはよく理解できます。
わたしは、オブザーバビリティを関係者全員の共通言語にするには、テレメトリーデータを広く収集できることと、開かれたオブザーバビリティプラットフォームであることが重要だと考えています。そのためのツールキット・プロトコルとして、OpenTelemetryが現状で最適な選択肢だと思っています。今後のさらなる普及と発展が楽しみです。
EメールのBIMI対応が着々と
NTTドコモが、ドコモから送信するEメールのなりすまし防止対策としてDMARCとBIMIに対応したことを発表しました。
大手キャリアとしてはおっとりという印象を持つ方も多いかもしれませんが、取り組み自体は大歓迎です。
ただ注意したいのは、BIMIが設定されているからといって、そのEメールが攻撃メールではないとは言い切れない点です。ドコモ自身も効果を「送信元がドコモかどうかを視覚的に確認しやすくする」と表現しており、これは正確かつ絶妙な言い回しだと思います。ロゴはあくまでロゴであり、セキュリティ上の安心マークではないということですね。ですからEメールの内容やリンク、添付ファイルへの注意は引き続き必要です。
わたしたちSREとしては、自分が見ているシステムをBIMI対応にするかどうか、するならいつか、というのは悩ましい判断ですよね。コストや優先度の兼ね合いもあって、一概には言えません。
いつの日かEメールにも、HTTPがデファクトだった時代からHTTPSがデファクトになったような変化が訪れるかもしれません。その時にはわたしたちSREはEメールを廃する方向に動くのか、維持する方向に動くのか、変化に適応しなければなりませんね。
X APIの価格改定に伴い、Xへの「ばばさん通信ダイジェスト」配信を終了
2026年4月20日に、X APIの料金体系が改定されました。
わたし自身への影響として特に大きかったのが、URL付き投稿が別価格体系となり、URLなし投稿よりも10倍以上高額になったことです。これをきっかけに、「ばばさん通信ダイジェスト」のXへの配信を終了することにしました。
URL付き投稿には例外扱いの返信種別があるようで、回避策自体はありそうです。ただ以前から、健康・健全な生活に向けた諸々の観点からXの利用を意識的に絞っていたこともあり、そこまではしませんでした。今回の改定はある意味ちょうどいい区切りになりました。
わたしが今後Xを積極的に使う場面があるとすれば、コミュニティイベントなどでXでの交流が指定された場合が中心になりそうです。
わたしのいまのメインはBlueskyで、Threads、Tumblr、Mastodonにも「ばばさん通信ダイジェスト」を配信しています。
一方、情報収集はRSSが軸です。500件弱のフィードから、週におよそ100件弱の記事をピックアップしています。
おわりに
直近の話題から、わたしが気になったものを中心にお送りしました。
Blameless、Keep ConstructiveでHRT溢れるご意見・ご感想、誤りの指摘などいただけると幸いです（HRT：Humility（謙虚）/Respect（尊敬）/Trust（信頼））。
前回トラコン（ICTSC: ICTトラブルシューティングコンテスト）の本戦結果を紹介しましたが、今回は新年度の取り組みが始まったのでお知らせします。
ICTSCは完全ボランティアの任意団体でして、今年度からわたしが会長を務めることになったので、一生懸命宣伝しています。
今回は学生に向けて、勉強会イベントのお知らせです。
ICTトラブルシューティングコンテスト (以降 ICTSC) への出場意思のある学生向けの勉強会イベントです。ICTSC の出題形式や問題内容、求められる技術知識や解決のテクニックを学ぶことができます。さらに、ライトニングトークや懇親会を通じて、参加学生同士が交流し、情報を共有する機会も提供します。
参加資格は『全国の専門学校、高等専修学校、高校、高専、大学、大学院 (博士後期課程修学者を除く) 、短期大学に所属する生徒・学生』『ICTSC2026 への参加を検討している方』の両方を満たす方なので、身近に該当する方がいたらぜひ声を掛けてあげてください。
このICTSCは参加者が学生、運営も学生という珍しいイベントです。運営する学生たちを社会人の実行委員が支える形で10年以上運営してきています。
若者や入門者を育て裾野を広げることは、業界の持続に不可欠だと思って続けております。
賛同いただける方・ご協力いただける方はぜひお声掛けくださいませ。
ではでは。