Linuxカーネルの内部を知ると、エンジニアリングはもっと面白くなる── インフラ話題8選

こんにちは。馬場（netmarkjp：Bluesky/X）です。

わたしは「#ばばさん通信ダイジェスト」（Bluesky/X）として、BlueskyやXに毎日少しずつ、賛否関わらず話題になった/なりそうなものを共有しています。

これらをベースに、特にクラウド/インフラ/SRE/オブザーバビリティ/運用等のキーワードに関する話題を中心にお届けします。

Linuxカーネルの内部がちょっとでもわかると、エンジニアリングはもっと面白くなる

VA Linuxエンジニアリングで、Linuxカーネルの内部を紹介する『新Linuxカーネル解読室』のエントリーが公開されています。
このシリーズについてエントリーでは次のように語られています。

「Linuxカーネル2.6解読室」（以降、旧版）出版後、Linuxには多くの機能が追加され、エンタープライズ領域をはじめとする様々な場所で使われるようになりました。

それに伴いコードが肥大かつ複雑化し、多くのエンジニアにとって解読不能なブラックボックスとなっています。

世界中のトップエンジニア達の傑作であるLinuxカーネルにメスを入れ、ブラックボックスをこじ開けて、時に好奇心の赴くままにカーネルの世界を解読する「新Linuxカーネル解読室」プロジェクト。

日々お世話になっているLinuxのネットワーク処理の裏側を、実際のカーネルコードを読みながら理解できる、貴重なコンテンツです。

Linux OSを専門としていなくても、Linuxやコンテナーイメージを触っていれば、名前だけは見かけたことがある単語がちょくちょく出てくるのではないでしょうか。

正直なところ難しいなと思うこともあるでしょう。単語がわからなくて辞書が必要ということもあるでしょう。

でも大丈夫です。いまはAIがあるので、解説してもらいながら、読むことができます。

AIだけでいちから学ぶとハルシネーションでトンチンカンなことになるのが怖いですが、このようなしっかりしたコンテンツがあれば自分で軌道修正できるので安心です。

自動化バイアス（AIの回答が正しいと思いがちなバイアス）に流されず、エントリーで裏を取りながら読んでいきましょう。

わたしはエンジニアとして「なんとなく動いている」を「どう動いているかわかる」に変えていくことが、より安全で意図通りなシステム運用につながると思っています。

それに、仕組みがわかると楽しいし嬉しいですよね。ぜひ読んでみてください。

AIエージェントのためのマークダウン形式へのコンテンツ変換

Cloudflareから、AIエージェント向けにHTMLページをMarkdownに変換して配信する「Markdown for Agents」が発表されました。

for Agentsの名のとおり、AIエージェントがWebコンテンツを読みやすいよう、HTMLコンテンツをMarkdownに変換して返す仕組みを紹介しています。

「for Agents」とあるので一見AI時代ならではの新発想に見えるのですが、実はインターフェースはクラシックです。

HTTPリクエストヘッダーのAcceptヘッダーで text/markdown を要求すると、CloudflareのCDNサービスがオリジンのHTMLコンテンツをMarkdown形式に変換して返してくれるというものです。

利用者から見ると、HTTPプロトコルのコンテンツネゴシエーションの仕組みを使っているだけです。HTTPプロトコルの柔軟性を改めて感じさせてくれます。

これはCDNをコンテンツ変換プロキシーとして使っている例ですね。

コンテンツ変換といえば画像フォーマットの変換が思い浮かびます。個人的にはかつてフィーチャーフォン向けにコンテンツ変換を提供するプロキシーサーバーを扱っていた頃のことを思い出しました。

CDNサービスはリバースプロキシーとして振る舞い、リバースプロキシーではコンテンツ変換などいろいろなことができるんだということを改めて実感させてくれる面白い機能です。

ターミナルをいい感じに便利にするためのプロトコルを知る

GhosttyやWezTerm、iTerm2、Terminal.appといったターミナルエミュレーターにおいて、HTMLで言うところの<a>タグのように文字列をクリッカブルなURLとして認識させる方法を紹介したエントリーです。

実装にはOSC8という、広く実装されている仕様が使われています。

OSC（Operating System Command）はターミナルエミュレーターに指示を送るためのエスケープシーケンスの取り決めで、OSC8はその中でもハイパーリンクを扱うための仕様です。

わたし自身OSCはよく使っていて、例えばOSC52を使ってssh接続したホームサーバーのvimでヤンク（コピー）した内容をローカルのmacOSクリップボードに伝搬させたり、OSC11とdirenvを組み合わせてディレクトリーごとにターミナルの背景色を自動で切り替えたりしています。

ちなみにわたしはGhostty、vim、tmuxをよく使っています。tmuxなどのターミナルマルチプレクサーを組み合わせるとエスケープシーケンス伝搬の挙動が変わることがあるのでご留意ください。

ターミナルはこういう低レイヤーの仕組みをちょっと工夫してガラッと体験を変えることができるのが楽しいですよね。

継続的なバージョンアップの意義と、その伝え方

ライブラリや言語のバージョンを継続的にアップグレードし続けることの意義と習慣、伝え方について、ベテランエンジニアの視点から考察したブログエントリーです。

技術的な話としては、最新を追従できる圏内を保って新しい機能・性能・セキュリティ対策等を取り込む観点と、最新からの変更を溜め込まないという観点の2つがあると思っています。

もちろんいずれも良し悪しがあるわけですが、特に前者は議論になりやすいですよね。

わたし個人としては、後者の観点を重視しています。

論理的な説得という意味では、わたしは変更を溜め込むとバージョンをアップデートする時の大変さがどんどん大きくなることに着目して話すことが多いです。

「セキュリティ対策で特定バージョン以上にしなければならないイベントが、予測できないタイミングで発生する」ことを踏まえると、変更の溜め込みは「セキュリティアップデートを適用して本番反映するまでの所要時間」を延ばしやすく、これはセキュリティ対応の遅延リスクを留保して溜め込んでいるように感じられます。

というのも、1回あたりの変更量を小さく保てば、影響範囲の予測がしやすく、問題が起きた時の原因特定もしやすいわけで、（最新とは言わずとも）特定のバージョンにアップデートする行為をスムーズに安全に行うためには、日頃の溜め込み解消が重要というわけです。

だからコツコツやるほうが、トータルのコストもリスクも低いわけです。これはDevOpsの土台を支える考え方のひとつで、バージョン管理や継続的デリバリー、継続的デプロイ、機能フラグといったプラクティスもこの考え方が根っこにありますよね。

コツコツ触れていると心理的な距離も開きにくいと思うので、いざという時の安心感にも繋がります。

このエントリーで面白いのは理屈は言わずもがな「体験的に知っていることをどう言語化して人に伝えるか」という話が軸にあることです。理屈を押さえたうえで、自分の言葉で語ることの大事さ。

固く説明するのか、勢いよく押すのか、論理的な説明だけでなくキャラクターや状況に合わせた表現の選び方そのものも重要だよねという視点が素晴らしいと感じます。

やってやれないことはない。PostgreSQLだけあればよい！？

「いくつものデータベースを管理するのをやめろ、PostgreSQLだけで十分だ」という、なかなか主張の強いサイトが話題になりました。

このWebサイトでは「全文検索、ベクトル検索（AI）、キャッシュ、ドキュメントデータベース（JSON）、時系列データベース、地理情報を扱うデータベース、ジョブスケジューラー、キーバリューストアのすべてをPostgreSQLでカバーできる！」と主張しています。

エッジが効いている感じがします。

サイトにある次のセリフが印象的です。

"USE THE RIGHT TOOL FOR THE RIGHT JOB" IS A TRAP.

気持ちはわかります。

一般的に「適材適所が重要」「ひとつですべての問題を解決できるような、銀の弾丸はない」というのは、システム設計の定説です。しかし、とはいえコンポーネントが増えれば増えるほど依存関係は壊れやすくなり、直列の依存関係が増えると全体の可用性は掛け算で下がりがちで、それをカバーするために高可用性機構が入り……と、複雑さは加速度的に増していきます。

なので「むやみに増やすのもよくない」というのは、これはこれで筋が通った話です。

一方で、もちろん逆に集約することで逆に障害が全体に波及して可用性が落ちるということもあります。

ここでサイトが罠だと主張しているのは、「適材適所を考える時にはデータやシステムの特性だけを見がちだけれども、それを運用するチームの、つまり人間の事情も重要」というところです。

（全体的な主張はさておき）この部分については、適材適所はチームのスキルセット、運用コスト、認知負荷……まで含めて包括的に判断すべきというのはわたしも同意です。

オマケとして。PlanetScaleのブログに「PostgreSQLでビデオカンファレンスを実現する」という技術的PoCのエントリーがありました。なんと、実験としては成立するそうです。

とはいえ、ブログエントリーの結論は……

No! Use WebRTC!

とのこと。ですよね。ここでの結論は「IS A TRAP」というより「USE THE RIGHT TOOL FOR THE RIGHT JOB」ですね。

PlanetScaleの人がPlanetScaleを使って検証した結果として、ここでは包括的な判断としての適材適所は「Use WebRTC」とのことです。

さて、実用性はさておき「ビデオフレームをDBMSに入れて論理レプリケーションでPushして配信する」というのは技術的な好奇心としてはとても面白いです。

もちろんこれは実用を勧めるものではありませんが、「なにがどこまでできるか」を試した実験的な内容です。

インターネットでの動画配信のように、技術的な前提の変化で昔ありえなかったことが当たり前になることはままあります。今後の「常識」がどう変わっていくか楽しみです。

New Relicも日本データセンターを開設でオブザーバビリティのさらなる普及に期待

New Relicが日本データセンター（東京リージョン）の開設を発表しました。2026年7月から全ユーザーが利用可能になる予定とのことです。

これまで金融・医療など業種業態等によってはテレメトリーデータの国外持ち出しが難しい場合があり、オブザーバビリティの実現に制約がかかるケースがありました。

データレジデンシーというやつですね。

New Relicは今回の東京リージョン開設により、データの収集・保存・処理をすべて国内で完結できるようになります。

他の主要プレイヤー、たとえばDatadogは既に日本国内でのデータ保持に対応しており、この流れはオブザーバビリティ業界全体で加速しているようです。

書籍『SREをはじめよう』によると、オブザーバビリティは『Dickersonの信頼性の階層構造』において全体を支える第一層です。

わたしが思うに、オブザーバビリティはシステム信頼性の全体を支える最重要の基盤です。

データがなければデータドリブンでの意思決定はできず、改善のサイクルをうまく回し続けるのが困難になります。

今回のような取り組みによって、オブザーバビリティの導入がより「当たり前」になって普及が加速することを、個人的にとても歓迎しています。

JANOG57 Meetingが開催されました

読者のみなさんはJANOG（ジャノグ）をご存知でしょうか？

JANOG | Information

JANOGとはJApan Network Operators' Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。

JANOGはその名の通り日本のネットワークエンジニアや研究者がたくさん参加している団体で、そのミートアップであるJANOG Meetingはネットワークエンジニアの祭典といった印象を持っています。

わたしの認識ではJANOG MeetingはJANOGの活動の代名詞であり、わたしの周囲では日常会話でJANOG Meetingを指してJANOGと呼ぶことがままあります。

JANOGではミートアップであるJANOG Meetingを年に2回開催しています。

JANOG Meetingは毎回異なるホスト企業がホストとなって開催されます。

JANOG57 Meetingが2026年2月11日（水・祝）～2月13日（金）に開催されました

今回のJANOG57 Meetingのホストはさくらインターネットさんでした。

今回のJANOG57 Meetingは都市部開催ということもあり、参加人数が5,289人 / 1日あたり最大3,882人 / 3日間で延べ9,665人と、ものすごい規模での開催でした。

これでも事前登録が6,000人を超えた時点で受付停止しているとのことで、打ち切っていなければ参加人数はさらに増えていたでしょう。

日本のインターネットの基盤は、このようなたくさんのネットワークエンジニアによって構築・運用されているわけです。

多くのセッションで資料が公開され、またセッションのアーカイブ動画が配信されています。

クラウド〜アプリケーションを主に触っていると耳慣れない用語が多く登場するかもしれませんが、クラウドサービスを利用するだけでは意識することがほとんどないレイヤーに触れてみるのはいかがでしょうか。

よく見てみると、AI/LLM活用やオブザーバビリティなど、ネットワークレイヤーだけでない話題が多くありますよ。

ICTトラブルシューティングコンテスト 2025 本戦が開催されました

2026/3/14（土）、15（日）にICTトラブルシューティングコンテスト 2025の本戦が開催されました。

ICTトラブルシューティングコンテスト（略称: ICTSC/アイシーティーエスシー、トラコン）はサーバー・ネットワークのトラブルシューティングや運用技術を競うコンテストです。

このICTトラブルシューティングコンテストは、情報システムの足回りであるネットワーク機器、ルーティングプロトコル、仮想アプライアンス、VPN、Linux、コンテナー、Kubernetesなどを主な出題範囲としています。

競技参加資格として全国の高校生、大学生、大学院生、専門学校生、高専生を対象としており、学生が同じ学校縛りのチーム単位で競います。

コンテストの勝敗を目的とするだけでなく、チームビルディング、チームメンバーの勧誘/育成等を通じて情報技術の面白さを広めること、同世代・世代間の交流/育成/コミュニティ形成を狙っています。

大きな特徴はコンテストの企画・運営も学生だというところです。

コンテストで出題する問題の作問や検証、コンテストで利用する会場の設営、コンテストで利用する会場の電源配分や電源容量管理、ネットワーク設計・構築や構内配線、Wi-Fi敷設、コンテスト会場で利用する物理サーバークラスターの設計・構築、バックボーン接続等、開催・運営のほとんどを学生自身が企画し・計画し・遂行します。

今回の競技会場横のNOC（ネットワーク・オペレーション・センター）にはサーバーラックが2本設置され、中には協賛企業さまからお借りしたネットワーク機器・サーバー機器がぎっしり詰まっていました。

一次予選（オンライン）、二次予選（オンライン）を経て、このたび本戦がオンサイト（オフライン）で開催されました。

本戦に進出したのは予選上位10チームと推薦枠5チームで、計15チームが現地会場に集い、決戦と相成りました。

問題環境には、主にRJ-45シリアルコンソールケーブルを用いて接続します。
問題によってはRJ-45シリアルコンソールケーブルの用意がなければ解答が不可能です。

本戦ではL1から出題範囲になるので、ネットワーク機器の実機を用いた出題がなされます。

ネットワーク機器の実機を利用した出題があったり、ケーブルを自作する出題があったり、競技中になぜか電源トラブルが発生する仕掛けがあったりと、非常にバラエティに富んだ、かつリアリティのある出題がなされます。

競技参加学生のほとんどは調査・回答にAI（LLM）を利用しており、この一年での圧倒的な変化です。しかしそれでも完答できるわけではなく、基盤技術の難しさを感じます。

採点側としてはAI slopのような回答もあったとのことで、なかなか悩ましいところです。AIはもう不可避ですから、AI利用を前提とした、時代に適応したレギュレーションが必要になりそうです。

わたしはICTSCが始まった時にはもう大人だったので、運営チームのバックにいる大人側のメンバーとして、かれこれ十年以上前から実行委員として（今は常任委員として）運営に関わっています。

今回も大過なく開催できたのは、ひとえに協賛いただいた各社さま、運営にご協力いただいた皆様、参加いただいた皆様、その他陰日向に支えていただいた皆様のお陰です。御礼申し上げます。

閉会式でもお話させていただきましたが、トラコンを続けたい・広めたいと思っています。

それはわたし自身がトラブルシューティングやパフォーマンスチューニングが好きで、その楽しさをより多くの人に味わって欲しいと思っているからです。

加えて、下の世代を、若者や学生を呼び込んで育成できない業界やジャンルは遠からず滅びてしまうと考えているからです。

トラコンを続ける・広めるためには、学生とのつながり、協賛いただける企業さんとのつながり、運営に協力いただける皆さんとのつながりが欠かせません。

ひとまず次回開催は決定していますので、次回以降もぜひよろしくお願いいたします。

もしご興味を持っていただけた方がいらっしゃいましたら、SNSや感想フォーム等なにかしらでご連絡くださいませ。

注目・期待の書籍

わたしが最近見かけた、期待の書籍を紹介します。

『AWS CDK入門―⁠―IaCによる安全・効率的なWebアプリ運用 | 技術評論社』

クラウド上のアプリケーション運用の効率化や信頼性の向上のために、IaC（Infrastracture as Code）の導入の方法や運用の仕方を紹介します。よくありがちな失敗事例に触れながらIaCツールであるAWS CDK（Amazon Cloud Development Kit）を用いた安全で効率的なシステムの運用方法について示します。「システムテストは問題なかったのにいざリリースしたら問題が起きてしまった」のように、単にIaCを単に活用しても本質的な課題の解決になりません。真正面から問題をとらえ、どのように解決したか、実例を挙げながら解説していきます。

『SSD技術概論―⁠―NANDの仕組みを知り、ストレージとしてのSSDの実像を理解する | 技術評論社』

SSD（ソリッドステートドライブ）は目覚ましい早さで普及しました。いまやノートPC、サーバーの中までもSSDが豊富にかつ当たり前のように使用されています。

そんなSSDですが、案外知られていないことがたくさんあります。SDカードやUSBメモリとは似て非なるものですし、HDDと比べて熱や書き込み回数などへの耐性、大容量化や高速化へのアプローチが異なります。

本書ではSSDの基本構造から解説を行い、発展の歴史を紐解きながら、さまざまな技術の謎を解き明かしていきます。「AIブーム」のあおりを受けて価格が高騰している今だからこそ、SSD選択のために必要な知恵や知識を多く凝縮しています。サーバーエンジニアに代表されるインフラ系エンジニア、システム管理者にとって安全な運用のために役立つ知識であることはもちろん、コアなコンピューターユーザーにとっても楽しみながらSSD技術について造詣を深められます。

『責任あるソフトウェアエンジニアリング―現実社会におけるGoogleのケーススタディとともに - O'Reilly Japan』

本書は、AIチャットボットやディープフェイク画像／動画、SNSのフィルターバブル、厳格化するプライバシー規制、気候変動といった課題が渦巻く現代において、ソフトウェアに求められる「正しさ」や「使いやすさ」を超え、社会的な責任を果たすための考え方と実践を解説する一冊です。専門家の助言と、Googleのエンジニア100名以上の知見をもとにした実践的なケーススタディを通じて、現実世界に耐えうる公平性・安全性・倫理性を備えたソフトウェア開発の指針を示します。「責任あるソフトウェアエンジニアリング」の定義と全体像からはじまり、AIにおける公平性、社会的文脈の理解、ソフトウェアが社会にもたらす意図せぬ有害な影響、プライバシーの保護、環境負荷の低減といったテーマを、章ごとに紐解いていきます。また、実践するための組織づくりについてもまとめています。

おわりに

直近の話題から、わたしが気になったものを中心にお送りしました。

Blameless、Keep ConstructiveでHRT溢れるご意見・ご感想、誤りの指摘などいただけると幸いです（いずれもSRE（Site Reliability Engineering）界隈で登場する用語です。Blameless：非難のない、Keep Constructive：建設的であり続ける、HRT：Humility（謙虚）/Respect（尊敬）/Trust（信頼）の頭文字でDevOpsの土台と言われています）。

後半でトラコン（ICTトラブルシューティングコンテスト）について熱く紹介しました。かれこれ10年以上開催していますので、実はあなたの身近に参加経験者がいるかもしれませんよ！

執筆者へのお便り